TCP異常クローズの概要


再投稿元:http://jeffchen.cn/?p = 776
ゲームのテスト中に、ソケットエラーが頻繁に発生することが判明しました。ゲームサーバーのテスト時に通常考慮されるケースは次のとおりです。
クライアントが失敗し、サーバー側が失敗します。
1。
ケース:クライアントクライアントプログラムが正常に実行されている場合は、ネットワークケーブルを抜き、クライアントプログラムを
強制終了します。目的:クライアントのクラッシュをシミュレートするには、システムが突然再起動する、ネットワークケーブルが緩む、ネットワーク
が利用できないなどです。結論:この場合、サーバープログラムは異常を検出せず、最後に「タイムアウト」を待ってからTCP接続を切断します。

2.
ケース:クライアントプログラムは通常、大量のデータパケットを送信した後、ソケットを閉じてプロセスを終了します(またはプロセスを終了しません)。
目的:メッセージの送信後にクライアントが正常に終了する状況をシミュレートします。
結論:Inこの場合、サーバープログラムはすべてのメッセージを正常に受信でき、最終的に「PeerClosed」(Recvはゼロを返します)メッセージを受信します。

3.
ケース:クライアントプログラムは、大量のデータパケットを送信した後、ソケットを閉じず
プロセスを直接終了します。目的:クライアントプログラムが終了し、ソケットを閉じるのを忘れた場合(プロセスを介してプロセスを終了するなど)をシミュレートします。Windowsウィンドウの閉じるアイコンですが、通常の終了処理などを行うために対応する閉じるイベントをキャプチャしていません。)
結論:この場合、サーバープログラムはいくつかのTCPメッセージを受信し、「104:ピアによる接続リセット」を受信できます( Linuxの場合)または「10054:既存の接続がリモートホストによって強制的に閉じられました」(Windows)エラー

4.
ケース:クライアントプログラムが大量のデータパケットを送信したときにプロセスを直接
強制終了する目的:クライアントプログラムのクラッシュをシミュレートするか、プロセスを異常な方法で終了する(Linuxまたはタスクでの「kill-9」など)プロセス
を強制終了するWindowsのマネージャー)状況結論:この場合、サーバープログラムはすぐにエラー「104:ピアによって接続がリセットされました」(Linuxの場合)または「10054:既存の接続がリモートホストによって強制的に閉じられました」( Windowsの場合)

5.
ケース:クライアントプログラムは通常、大量のデータパケットを送信した後、ソケットを閉じてプロセスを終了します(またはプロセスを終了しません)。
目的:クライアントが通常ソケットを閉じることをシミュレートするために、サーバーはメッセージをに送信します。 TCPピアが閉じていることを確認する前にクライアント。状況の
結論:この場合、サーバープログラムはいくつかのTCPメッセージを送受信した後、「32:パイプの破損」(Linuxの場合)または「10053:確立された接続がによって中止されました」を生成します。ホストマシンのソフトウェア」(Windows)エラー

概要:
ソケットを閉じるのを忘れた後にTCP接続プロセスが終了した場合、プログラムがクラッシュした場合、またはプロセスが異常終了した場合(Windowsクライアント)、TCP接続の反対のプロセスで「104:ピアによる接続のリセット」が生成されます( Linuxの場合)または「10054:既存の接続がリモートホストによって強制的に閉じられました」(Windowsの場合)エラー

TCP接続プロセスマシンがクラッシュしたり、システムが突然再起動したり、ネットワークケーブルが緩んだり、ネットワークが切断されたりすると、接続されたピアプロセスは異常を検出せず、最後に「タイムアウト」を待ってからTCP接続を切断します。

TCP接続プロセスがソケットを正常に閉じるとき、ピアプロセスはTCPクローズイベントがチェックされる前にTCPにメッセージを送信し、送信メッセージは「32:壊れたパイプ」(Linuxの場合)または「10053:確立された「接続はホストマシンのソフトウェアによって中止されました」(Windowsの場合)エラー

サーバーに障害が発生し、クライアントは次のようになり
ます。1。
サーバーがソケットを閉じ、クライアントがデータを送信します。
目的:TCPピアプロセスがソケットを閉じたことをテストするために、ローカルプロセスは接続が閉じられたことを検出しませんでした。
結論最後に送信されメッセージの:最初のパケットは正常に送信できますが、2番目のパケットは失敗しました。エラーコードは「10053:確立された接続がホストマシンのソフトウェアによって中止されました」(Windowsの場合)または「32:壊れたパイプ、「SIGPIPE信号を受信しました」(Linuxの場合)エラー

2.
サーバーはTCPにデータを送信した後
にソケットを閉じ、クライアントは別のデータパケットを送信してから、メッセージを受信します。目的:TCPピアプロセスがデータを送信した後にソケットが閉じられ、ローカルプロセスがデータを送信していないことをテストします。接続が閉じられたことを検出しました。メッセージのパケットを送信してから、メッセージを受信します。
結論:クライアントはデータの最初のパケットを正常に送信できます(これにより、サーバーはRSTパケット<パケット検証>を送信します)。クライアントはRecvに移動します。これは、WindowsおよびLinuxプログラム用です。次のようなさまざまな症状があり
ます。Windowsクライアントプログラム:Recvが失敗し、エラーコードは「10053:確立された接続がホストマシンのソフトウェアによって中止されました」
Linuxクライアントプログラム:すべてのメッセージパケットは正常に受信でき、最終的には正常に受信できます。反対側がメッセージを閉じます(これはウィンドウの下と同じではありません)

3.
サーバー
はTCP受信バッファーに未受信データがあるときにソケットを閉じ、クライアントはパケットを受信します。目的:TCP受信バッファーに未受信データがあるときにソケットが閉じられるかどうかをテストするには、反対のプロセスが正常かどうか?
結論:この場合、サーバーは通常のFINパケット(パケットをキャプチャすることで証明されています)の代わりにRSTパケットを反対側に送信します。これにより、クライアントが早くなります(RSTパケット)。受信)「10054:既存の接続がリモートホストによって強制的に閉じられました」(Windowsの場合)または「104:ピアによって接続がリセットされました」(Linuxの場合)というエラーが表示されました。

概要:
TCP接続のピアプロセスがソケットを閉じたとき、ローカルプロセスがデータを再度送信すると、最初のパケットを正常に送信できます(ただし、ピアはRSTパケット
を送信します):データを送信し続ける場合後で失敗し、エラーコードは「10053:アン確立された接続は、ホストマシンのソフトウェアによって中止されました」です(Windowsで)または:(Linuxで)「32 SIGPIPE信号を受信している間、壊れたパイプ」エラー;
その後、あなたの場合データを受信します。Windowsでは10053のエラーが報告されますが、Linuxでは通常のシャットダウンメッセージが受信されます。

TCP接続のローカル受信バッファーに未受信データがまだあり、ソケットが閉じている場合、ローカルTCPは通常のFINパケットではなくRSTパケットを反対側に送信します。これにより、反対側が早期に処理されます( RSTパケットは通常のデータパケットよりも早く受信されます)、エラー「10054:既存の接続がリモートホストによって強制的に閉じられました」(Windowsの場合)または「104:ピアによって接続がリセットされました」(Linuxの場合)が受信されます。


再投稿元:http://jeffchen.cn/?p = 776
ゲームのテスト中に、ソケットエラーが頻繁に発生することが判明しました。ゲームサーバーのテスト時に通常考慮されるケースは次のとおりです。
クライアントが失敗し、サーバー側が失敗します。
1。
ケース:クライアントクライアントプログラムが正常に実行されている場合は、ネットワークケーブルを抜き、クライアントプログラムを
強制終了します。目的:クライアントのクラッシュをシミュレートするには、システムが突然再起動する、ネットワークケーブルが緩む、ネットワーク
が利用できないなどです。結論:この場合、サーバープログラムは異常を検出せず、最後に「タイムアウト」を待ってからTCP接続を切断します。

2.
ケース:クライアントプログラムは通常、大量のデータパケットを送信した後、ソケットを閉じてプロセスを終了します(またはプロセスを終了しません)。
目的:メッセージの送信後にクライアントが正常に終了する状況をシミュレートします。
結論:Inこの場合、サーバープログラムはすべてのメッセージを正常に受信でき、最終的に「PeerClosed」(Recvはゼロを返します)メッセージを受信します。

3.
ケース:クライアントプログラムは、大量のデータパケットを送信した後、ソケットを閉じず
プロセスを直接終了します。目的:クライアントプログラムが終了し、ソケットを閉じるのを忘れた場合(プロセスを介してプロセスを終了するなど)をシミュレートします。Windowsウィンドウの閉じるアイコンですが、通常の終了処理などを行うために対応する閉じるイベントをキャプチャしていません。)
結論:この場合、サーバープログラムはいくつかのTCPメッセージを受信し、「104:ピアによる接続リセット」を受信できます( Linuxの場合)または「10054:既存の接続がリモートホストによって強制的に閉じられました」(Windows)エラー

4.
ケース:クライアントプログラムが大量のデータパケットを送信したときにプロセスを直接
強制終了する目的:クライアントプログラムのクラッシュをシミュレートするか、プロセスを異常な方法で終了する(Linuxまたはタスクでの「kill-9」など)プロセス
を強制終了するWindowsのマネージャー)状況結論:この場合、サーバープログラムはすぐにエラー「104:ピアによって接続がリセットされました」(Linuxの場合)または「10054:既存の接続がリモートホストによって強制的に閉じられました」( Windowsの場合)

5.
ケース:クライアントプログラムは通常、大量のデータパケットを送信した後、ソケットを閉じてプロセスを終了します(またはプロセスを終了しません)。
目的:クライアントが通常ソケットを閉じることをシミュレートするために、サーバーはメッセージをに送信します。 TCPピアが閉じていることを確認する前にクライアント。状況の
結論:この場合、サーバープログラムはいくつかのTCPメッセージを送受信した後、「32:パイプの破損」(Linuxの場合)または「10053:確立された接続がによって中止されました」を生成します。ホストマシンのソフトウェア」(Windows)エラー

概要:
ソケットを閉じるのを忘れた後にTCP接続プロセスが終了した場合、プログラムがクラッシュした場合、またはプロセスが異常終了した場合(Windowsクライアント)、TCP接続の反対のプロセスで「104:ピアによる接続のリセット」が生成されます( Linuxの場合)または「10054:既存の接続がリモートホストによって強制的に閉じられました」(Windowsの場合)エラー

TCP接続プロセスマシンがクラッシュしたり、システムが突然再起動したり、ネットワークケーブルが緩んだり、ネットワークが切断されたりすると、接続されたピアプロセスは異常を検出せず、最後に「タイムアウト」を待ってからTCP接続を切断します。

TCP接続プロセスがソケットを正常に閉じるとき、ピアプロセスはTCPクローズイベントがチェックされる前にTCPにメッセージを送信し、送信メッセージは「32:壊れたパイプ」(Linuxの場合)または「10053:確立された「接続はホストマシンのソフトウェアによって中止されました」(Windowsの場合)エラー

サーバーに障害が発生し、クライアントは次のようになり
ます。1。
サーバーがソケットを閉じ、クライアントがデータを送信します。
目的:TCPピアプロセスがソケットを閉じたことをテストするために、ローカルプロセスは接続が閉じられたことを検出しませんでした。
結論最後に送信されメッセージの:最初のパケットは正常に送信できますが、2番目のパケットは失敗しました。エラーコードは「10053:確立された接続がホストマシンのソフトウェアによって中止されました」(Windowsの場合)または「32:壊れたパイプ、「SIGPIPE信号を受信しました」(Linuxの場合)エラー

2.
サーバーはTCPにデータを送信した後
にソケットを閉じ、クライアントは別のデータパケットを送信してから、メッセージを受信します。目的:TCPピアプロセスがデータを送信した後にソケットが閉じられ、ローカルプロセスがデータを送信していないことをテストします。接続が閉じられたことを検出しました。メッセージのパケットを送信してから、メッセージを受信します。
結論:クライアントはデータの最初のパケットを正常に送信できます(これにより、サーバーはRSTパケット<パケット検証>を送信します)。クライアントはRecvに移動します。これは、WindowsおよびLinuxプログラム用です。次のようなさまざまな症状があり
ます。Windowsクライアントプログラム:Recvが失敗し、エラーコードは「10053:確立された接続がホストマシンのソフトウェアによって中止されました」
Linuxクライアントプログラム:すべてのメッセージパケットは正常に受信でき、最終的には正常に受信できます。反対側がメッセージを閉じます(これはウィンドウの下と同じではありません)

3.
サーバー
はTCP受信バッファーに未受信データがあるときにソケットを閉じ、クライアントはパケットを受信します。目的:TCP受信バッファーに未受信データがあるときにソケットが閉じられるかどうかをテストするには、反対のプロセスが正常かどうか?
結論:この場合、サーバーは通常のFINパケット(パケットをキャプチャすることで証明されています)の代わりにRSTパケットを反対側に送信します。これにより、クライアントが早くなります(RSTパケット)。受信)「10054:既存の接続がリモートホストによって強制的に閉じられました」(Windowsの場合)または「104:ピアによって接続がリセットされました」(Linuxの場合)というエラーが表示されました。

概要:
TCP接続のピアプロセスがソケットを閉じたとき、ローカルプロセスがデータを再度送信すると、最初のパケットを正常に送信できます(ただし、ピアはRSTパケット
を送信します):データを送信し続ける場合後で失敗し、エラーコードは「10053:アン確立された接続は、ホストマシンのソフトウェアによって中止されました」です(Windowsで)または:(Linuxで)「32 SIGPIPE信号を受信している間、壊れたパイプ」エラー;
その後、あなたの場合データを受信します。Windowsでは10053のエラーが報告されますが、Linuxでは通常のシャットダウンメッセージが受信されます。

TCP接続のローカル受信バッファーに未受信データがまだあり、ソケットが閉じている場合、ローカルTCPは通常のFINパケットではなくRSTパケットを反対側に送信します。これにより、反対側が早期に処理されます( RSTパケットは通常のデータパケットよりも早く受信されます)、エラー「10054:既存の接続がリモートホストによって強制的に閉じられました」(Windowsの場合)または「104:ピアによって接続がリセットされました」(Linuxの場合)が受信されます。

おすすめ

転載: blog.csdn.net/bosszhao20190517/article/details/114997997