私の理解では、tcp プロトコルのパフォーマンスは RTT (往復時間) によって制限されます。クライアントがサーバーにメッセージを送信する場合、確認応答を待ってから、シーケンス内の次のメッセージを送信する必要があります。これは、RTT が 250 ミリ秒のリンクにいる場合、1 秒あたり 4 メッセージに制限されることを意味します。これは、多くのアプリケーションにとって非常に遅く、データ転送速度を著しく妨げます。
この制限を回避するには、どのような方法がありますか?
クライアントがサーバーにメッセージを送信する場合、確認応答を待ってから、シーケンス内の次のメッセージを送信する必要があります。
それは正しくありません。遅延および選択的 ACK などがあります。
これは、RTT が 250 ミリ秒のリンクにいる場合、1 秒あたり 4 メッセージに制限されることを意味します。
いいえ、そうではありません。
実際のボトルネックは、リンクの帯域幅と遅延の積です。両端のソケット送受信バッファが少なくともこの製品と等しいことを確認してください。
RTT は、パケットが送信バッファーから追い出されるまでの約 250 ミリ秒のレイテンシーを通知するだけです。送信バッファが十分に大きい場合、最大帯域幅からプロトコル オーバーヘッドを差し引いた双方向通信を妨げるものは何もありません。
エラー訂正が必要ない場合 (つまり、メッセージの到着が遅すぎると意味がない場合)、UDP の使用を検討してください。
私が正しく理解していれば。プロトコルは、次の要求メッセージを送信する前に、ピアからの応答メッセージを待機します。その場合、RTT はあなたが言うように速度を制限します (1 秒あたり 4 メッセージ)。
プロトコルの仕様がそのような待機を要求する場合、プロトコルの設計は不適切です。
そうでない場合は、応答メッセージを待つ前にいくつかのメッセージをピアに送信することで、パフォーマンスを向上させることができます。そうすれば、RTT が高くてもそれほど遅くなることはありません。