TCPに関するウィキペディアの記事は、TCPセグメントを転送するIPパケットが失われることがあり、TCPが「失われたデータの再送信を要求する」ことを示しています。
失われたデータの再送信を要求するためのルールは正確には何ですか?再送信要求はどのくらいの頻度で実行されますか?数に上限はありますか?IPパケットが欠落したときに一部が欠落したTCPセグメント全体を忘れるように、クライアントがサーバーに指示する機能はありますか?
TCPに関するウィキペディアの記事は、TCPセグメントを転送するIPパケットが失われることがあり、TCPが「失われたデータの再送信を要求する」ことを示しています。
失われたデータの再送信を要求するためのルールは正確には何ですか?再送信要求はどのくらいの頻度で実行されますか?数に上限はありますか?IPパケットが欠落したときに一部が欠落したTCPセグメント全体を忘れるように、クライアントがサーバーに指示する機能はありますか?
失われたデータの再送信を要求するためのルールは正確には何ですか?
受信者は再送信を要求しません。送信者は、クライアントに送信されたバイト範囲のACKを待機し、受信されなかった場合は、特定の間隔の後にパケットを再送信します。これはARQ(自動再送要求)です。これを実装する方法はいくつかあります。
Stop-and-wait ARQ
Go-Back-N ARQ
Selective Repeat ARQ
RFC3366で詳しく説明されています。
再送信要求はどのくらいの頻度で実行されますか?
再送信回数と試行回数は、標準では強制されていません。オペレーティングシステムによって実装方法は異なりますが、方法は固定されています。(おそらくOSのフィンガープリントを作成する方法の1つですか?)
タイムアウトは、RTT(ラウンドトリップ時間)時間で測定されます。ただし、 3つの重複ACKが受信されると起動する高速再送信のため、これはあまり必要ありません。
数に上限はありますか?
はいあります。特定の回数の再試行の後、ホストは「ダウン」していると見なされ、送信者はTCP接続を断念して切断します。
IPパケットが欠落したときに一部が欠落したTCPセグメント全体を忘れるように、クライアントがサーバーに指示する機能はありますか?
重要なのは信頼できるコミュニケーションです。クライアントにある部分を忘れてもらいたいのなら、そもそもTCPを使用しないでしょう。(おそらくUDP?)
再送信の決まった時間はありません。単純な実装では、RTT(ラウンドトリップ時間)を見積もり、その2倍の時間にデータを送信するためのACKが受信されなかった場合は、再送信します。
その後、待機時間が2倍になり、応答がない場合はもう一度再送信します。リンス。繰り返す。
より洗練されたシステムは、ACKにかかる時間をより正確に推定し、どのデータが失われたかを正確に推測します。
肝心なのは、いつ再送信するかについての厳格なルールはないということです。それは実装次第です。 すべての再送信は、受信者からの応答の欠如に基づいて、送信者によってのみトリガーされます。
TCPがデータをドロップすることはないので、サーバーが一部のセグメントを忘れる必要があることを示す方法はありません。