サーバーがハングアップしました。クライアントの TCP 接続はまだ残っていますか?

作者：小林コーディング

コンピューターのステレオタイプのエッセイ Web サイト: https://xiaolincoding.com

皆さんこんにちは、シャオリンです。

「サーバーがハングする」が「サーバープロセスがクラッシュする」を指す場合、サーバープロセスがクラッシュすると、カーネルは FIN メッセージを送信し、クライアントに 4 回手を振ります。

しかし、「サーバーがハングアップする」が「サーバーホストがダウンしている」という意味であれば、手を振った人はいないでしょう。また、クライアントがデータを送信するかどうかにも依存しますか?

クライアントがデータを送信する場合、サーバーが存在しないため、クライアントのデータパケットは時間の経過とともに再送信され、再送信の回数が特定のしきい値に達すると、TCP 接続が切断されます。
クライアントがデータを送信しない場合は、クライアントが TCP キープアライブメカニズムを有効にしているかどうかを確認してください。
- 有効になっている場合、クライアントは、一定期間後にサーバーの TCP 接続が存在しないことを検出した後、独自の TCP 接続を切断します。
- 有効にしない場合、クライアントの TCP 接続は常に存在し、切断されません。

上記は要約された回答です。以下で詳しく説明しましょう。

サーバープロセスがクラッシュすると、クライアントはどうなりますか?

TCP 接続情報はカーネルによって維持されるため、サーバープロセスがクラッシュした場合、カーネルはプロセスのすべての TCP 接続リソースを再利用する必要があります。そのため、カーネルは最初の FIN メッセージを送信し、その後のウェーブプロセスもカーネルの完了はプロセスの参加を必要としないため、サーバープロセスが終了しても、クライアントとの TCP 4 ウェイウェーブプロセスを完了することができます。

また、kill -9 コマンドを使用してプロセスのクラッシュをシミュレートする実験を行ったところ、プロセスを強制終了した後、サーバーが FIN メッセージを送信し、クライアントに 4 回手を振ることがわかりました。

サーバーホストがダウンした後、クライアントはどうなりますか?

サーバー側のホストが突然電源を失う場合、これはサーバー側のホストがダウンしている場合です。

サーバーホストがダウンした場合、クライアントと4回手を振る方法がないため、サーバーホストがダウンした瞬間に、クライアントはサーバーホストがダウンしたことをすぐに認識できません。後続のデータ相互作用は存在しなくなります。

したがって、次の 2 つのケースについて説明する必要があります。

サーバーホストがダウンした後、クライアントはデータを送信します。
サーバーホストがダウンすると、クライアントはデータを送信しなくなります。

サーバーホストがダウンした後、クライアントがデータを送信する場合

サーバーホストがダウンした後、クライアントはデータパケットを送信しますが、応答を取得できないため、一定時間待機した後、クライアントはタイムアウト再送信メカニズムをトリガーして、応答を受信していないデータパケットを再送信します。

再送信の回数が特定のしきい値に達すると、カーネルは TCP 接続に問題があると判断し、ソケットインターフェイスを介して TCP 接続に問題があることをアプリケーションに通知するため、クライアントの TCP 接続は切断されました。

TCP データパケットは何回再送信されますか?

Linux システムでは、次の図に示すように、tcp_retries2 という構成項目が提供され、デフォルト値は 15 です。

このカーネルパラメータは、TCP 接続が確立されたときのタイムアウト再送信の最大数を制御します。

ただし、tcp_retries2 は 15 回設定されますが、これは、15 回の TCP タイムアウト再送信後にアプリケーションが TCP 接続を終了するように通知されることを意味するものではありません. カーネルは、tcp_retries2 によって設定された値に従ってタイムアウトを計算します (tcp_retries2 =15 の場合、計算されたタイムアウト = 924600 ミリ秒)、再送信間隔がこのタイムアウトを超えると、しきい値を超えたと見なされ、再送信が停止され、TCP 接続が切断されます。

オーバータイム再送信のプロセスでは、各ラウンドのタイムアウト時間 (RTO) が乗算されます. たとえば、RTO の最初のラウンドが 200 ミリ秒の場合、RTO の 2 番目のラウンドは 400 ミリ秒で、RTO の 3 番目のラウンドは 800 ミリ秒です。ミリ秒など。

RTO は RTT (パケットのラウンドトリップ時間) に基づいて計算されます. RTT が大きいほど、計算される RTO は大きくなります. 数回の再送信の後、すぐに上記のタイムアウト値に達します.

たとえば、tcp_retries2 =15 の場合、計算されたタイムアウト = 924600 ミリ秒の場合、合計再送信間隔がタイムアウトに達すると、再送信が停止し、TCP 接続が切断されます。

RTT が比較的小さい場合、RTO の初期値は下限の 200ms にほぼ等しい、つまり最初のラウンドのタイムアウト時間は 200ms です. タイムアウトの合計時間は 924600 ms であるため、示されている現象はわずか 15 回の再送信でタイムアウト値を超えたため、TCP 接続が切断されました
RTT が比較的大きい場合、RTO の初期値が 1000 ミリ秒、つまり最初のラウンドのタイムアウト期間が 1 秒であると計算された場合、15 回再送信する必要はまったくなく、合計再送信間隔は 924600 ミリ秒を超えます。

最小 RTO と最大 RTO は、Linux カーネルで定義されています。

#define TCP_RTO_MAX ((unsigned)(120*HZ))
#define TCP_RTO_MIN ((unsigned)(HZ/5))

Linux 2.6+ は 1000 ミリ秒の HZ を使用するため、TCP_RTO_MIN約 200 ミリ秒TCP_RTO_MAXは約 120 秒です。

tcp_retriesに設定されていて15、RTT が比較的小さい場合、RTO の初期値は下限の 200ms にほぼ等しくなります。切断された TCP 接続. 各ラウンドの RTO 増加関係は、次のシートのとおりです。

サーバーホストがダウンした後、クライアントがデータを送信していない場合

サーバーホストが送信した後、クライアントがデータを送信していない場合は、TCP キープアライブメカニズム (TCP キープアライブメカニズム) が有効になっているかどうかによって異なります。

TCP キープアライブメカニズムが有効になっていない場合、サーバーホストがデータの送信に失敗した後にクライアントがデータを送信しない場合、クライアントの TCP 接続は常に存在するため、TCP キープアライブメカニズムが使用されていない時点を知ることができます。 2 つの当事者がデータを送信しない場合、一方の当事者の TCP 接続が ESTABLISHED 状態であっても、他方の当事者の TCP 接続が正常でなければならないという意味ではありません。

また、 TCP キープアライブメカニズムがオンになっている場合、サーバーホストがダウンを送信した後、クライアントがデータを送信しなくても、しばらくすると、TCP はサーバーが稼働しているかどうかを検出するために検出メッセージを送信します。

ピアが正常に動作している場合。TCP キープアライブ検出メッセージがピアに送信されると、ピアは正常に応答するため、TCP キープアライブ時間はリセットされ、次の TCP キープアライブ時間の到着を待ちます。
ピアホストがクラッシュした場合、または他の理由でピアに到達できない場合。TCPキープアライブ検出メッセージがピアに送信されると、応答がなく、応答がありません.数回続けて、キープアライブ検出の数に達した後、TCPはTCP接続が切断されたことを報告します.

したがって、TCP キープアライブメカニズムは、2 つの当事者間でデータ交換がないときにパケットを検出することによって、相手の TCP 接続が生きているかどうかを判断できます。

TCPキープアライブメカニズムとは正確には何ですか?

TCP キープアライブメカニズムの原理は次のとおりです。

期間を定義します。この期間中に接続関連のアクティビティがない場合、TCP キープアライブメカニズムが動作を開始します。1 回おきの間隔で、プローブメッセージが送信されます。プローブメッセージにはほとんどデータが含まれていません。数回連続して検出メッセージに対する応答がない場合、現在の TCP 接続が切断されていると見なされ、システムカーネルは上位層のアプリケーションにエラーメッセージを通知します。

Linux カーネルには、キープアライブ時間、キープアライブ検出の数、およびキープアライブ検出の時間間隔を設定する対応するパラメーターがあります。デフォルト値は次のとおりです。

net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75  
net.ipv4.tcp_keepalive_probes=9

各パラメータの意味は次のとおりです。

tcp_keepalive_time=7200: キープアライブ時間が 7200 秒 (2 時間) であることを示します。つまり、2 時間以内に接続関連のアクティビティがない場合、キープアライブメカニズムがアクティブになります。
tcp_keepalive_intvl=75: 各検出間の間隔が 75 秒であることを示します。
tcp_keepalive_probes=9: 9回検出しても応答がなく、相手が到達不能と判断したため、この接続を切断したことを意味します。

つまり、Linux システムでは、「切断された」接続を見つけるのに少なくとも 2 時間 11 分 15 秒かかります。

アプリケーションが TCP キープアライブメカニズムを使用したい場合は、有効にするためにソケットインターフェイスを介してSO_KEEPALIVEオプション. 設定されていない場合、TCP キープアライブメカニズムは使用できません.

TCP キープアライブメカニズムの検出時間が長すぎませんか?

はい、少し長いです。

TCP キープアライブはTCP 層 (カーネル状態)によって実装され、TCP トランスポートプロトコルに基づくすべてのプログラムの包括的なソリューションです。

実際、私たちのアプリケーション層は、それ自体で一連の検出メカニズムを実装できます。これにより、相手が生きているかどうかを比較的短時間で検出できます。

たとえば、Web サービスソフトウェアは通常、HTTP 持続接続のタイムアウト期間を指定するkeepalive_timeoutパラメータ。HTTP ロング接続のタイムアウト期間が 60 秒に設定されている場合、Web サービスソフトウェアはタイマーを開始します. クライアントが最後の HTTP 要求から 60 秒以内に新しい要求を開始しない場合、タイマーの時間が経過すると、コールバック関数がトリガーされ、接続が解放されます。

要約する

サーバーが存在しないためにクライアントがデータを送信する場合、クライアントのデータパケットは時間をかけて再送信され、再送信間隔の合計が特定のしきい値に達すると (カーネルは tcp_retries2 によって設定された値に基づいてしきい値を計算します)、 TCP 接続を開きます。
クライアントがデータを送信しない場合は、クライアントが TCP キープアライブメカニズムを有効にしているかどうかを確認してください。
- If enabled, the client will trigger the TCP keepalive mechanism when there are no data interacts for a period of time to detect the other party of the other party. 相手の存在を検出した場合、クライアントは自身の TCP 接続を切断します。
- 有効にしない場合、クライアントの TCP 接続は常に存在し、ESTABLISHED 状態のままになります。

もう 1 つの非常に興味深い質問があります。「ネットワークケーブルを数秒間抜いてから、もう一度差し込んでみてください。元の TCP 接続はまだ存在しますか? 」以前にも書いたので、次の記事を参照してください。数秒後、元の TCP 接続はまだ存在しますか?

以上！

その他のウェブ記事

ウェブサイト: www.xiaolincoding.com
ウェブサイト: xiaolincoding.com

ネットワークの基本:

HTTP 記事:

TCP 記事:

IP 記事:

学習経験: