すべての接続でTCPキープアライブを有効にする必要があります。現在、テストケースの結果に苦労しています。これは、最初のキープアライブプローブがいつ送信されるのか本当にわからないためです。 。Linuxのtcp_keepalive_time
のドキュメントで以下を読みました。
最後に送信されたデータパケット(単純なACKはデータとは見なされません)と最初のキープアライブプローブの間の間隔。接続がキープアライブを必要とするようにマークされた後、このカウンタはこれ以上使用されません
他のいくつかのソースは、これが接続がアイドル状態のときであると述べていますが、これはこれが何を意味するかをさらに定義していません。再送信を検討するとき、「最後に送信されたデータパケット」が実際には何を意味するのか不思議に思っているので、これについてのより正式な定義を見つけるためにスティーブンスを調べました。
私のテストケースでは、データがサーバーからクライアントにかなり高速でのみ送信される接続を使用しています。キープアライブをテストするために、クライアントのNICのケーブルを取り外しました。これで、ネットワークスタックがデータを送信しようとし、再送信状態に入るが、キープアライブプローブが送信されないことがわかります。キープアライブプローブが再送信中に送信されないことは正しいですか?
データがサーバーからクライアントにかなり高速で送信されるだけの接続があります。
その後、キープアライブは表示されません。キープアライブは、「通信の沈黙」があるときに送信されます。 RFC1122 には、キープアライブに関するいくつかの説明があります。
「キープアライブ」メカニズムは、接続のもう一方の端を定期的にプローブします接続がアイドル状態の場合(送信するデータがない場合でも)
あなたの質問に戻ります:
他のいくつかのソースは、これが接続がアイドル状態のときであると述べていますが、これはこれが何を意味するかをさらに定義していません。
TCPはピアが "hoy!still alive?"を突く前に待機する時間です。
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
つまり、TCP接続を使用していて、それはすばらしいことです。しかし、過去2時間、送信するものは何もありませんでした。接続を想定することは理にかなっていますか?はまだ生きていますか?真ん中のすべてのミドルボックスがまだ接続についての状態を持っていると想定することは理にかなっていますか?意見は異なり、キープアライブはRFC793の一部ではありません。
TCP仕様には、キープアライブメカニズムが含まれていない可能性があります。(1)一時的なインターネット障害時に完全に良好な接続が切断される;(2)不要な帯域幅を消費する(「誰も使用していない場合」接続、それがまだ良いかどうか誰が気にしますか?」)
キープアライブをテストするために、クライアントのNICのケーブルを取り外しました。
これはキープアライブのテストではありません。これは、TCPの再送信戦略をテストしています。つまり、TCPがメッセージを送信しようとする回数と頻度です。Linuxのボックスでは、これは(可能性が高い)テストになります net.ipv4.tcp_retries2
:
Alive TCP接続を強制終了する前に再試行する回数。RFC1122は制限が100秒より長くなければならないことを示しています。数値が小さすぎます。デフォルト値15はRTOに応じて13〜30分に対応します。
しかし RFC5482-TCPユーザータイムアウトオプション は、それに影響を与えるより多くの方法を提供します。
TCPユーザータイムアウトは、接続が強制的に閉じられる前に、送信されたデータが確認応答されないままでいられる期間を制御します。
質問に戻る:
キープアライブプローブが再送信中に送信されないことは正しいですか
それは理にかなっています:TCPはすでに他のピアからの応答を引き出そうとしているため、空のキープアライブは不必要です。
TCP_KEEPCNT
キープアライブプローブの最大数TCPは、接続をドロップする前に送信する必要があります。
TCP_KEEPIDLE
ソケットオプションSO_KEEPALIVE
がこのソケットで設定されている場合、接続がアイドル状態を維持する必要がある時間(秒)がTCPがキープアライブプローブの送信を開始する前に
TCP_KEEPINTVL
個々のキープアライブプローブ間の時間(秒単位)
TCP_USER_TIMEOUT
TCPが接続を強制的に閉じるまでに、送信されたデータが確認応答されないままになる最大時間(ミリ秒)。
したがって、たとえば、アプリケーションはこのオプションを使用して、接続がない場合に接続が存続する時間を決定できます(NICの取り外しの例と同様)。例えば。クライアントが戻ってくると信じる理由がある場合(おそらく、ラップトップのふたを閉じたか、ワイヤレスアクセスが不安定ですか?)、タイムアウトを12時間に指定しても、戻ってきても接続は機能します。