3

TCP とソケットの詳細なメカニズムはよくわかりません。

1 つのクライアントが TCP 経由でサーバーに接続し、データをサーバーに送信します。送信速度が処理速度よりもはるかに速い場合はどうなりますか? たとえば、クライアントが 1 秒あたり 1 MiB を送信しても、サーバーが 1 秒あたり 1 KiB しか処理できない場合、システム メモリ クラッシュが発生しますか?

ソケット API に受信バッファ サイズの設定があることは知っています。

  1. バッファ サイズを設定したが、データがフラッディングしている場合はどうすればよいですか?
  2. 受信バッファ サイズを設定しないとどうなりますか?
4

3 に答える 3

6

つまり、サーバーが 1 秒あたり 1k しか処理できない場合、クライアントは 1 秒あたり 1M を送信する機会を得られません。これには 2 つの理由があります。

  • TCP にはスロー スタート メカニズムがあります
  • TCP にはウィンドウ メカニズムがあり、TCP 接続の各側が常に相手側に受信能力をアドバタイズします。

クライアントがアドバタイズされたウィンドウ サイズを超えるデータを送信しても意味がありません。これは、サーバーが最初にウィンドウ サイズ外のセグメントをすべてドロップするため、クライアントはウィンドウ サイズを無視した場合に再送信する必要があるためです。ウィンドウサイズ。

バッファはさまざまなレイヤーに配置されています。ソケット オプションで設定できるバッファはソケット レベルのバッファであり、TCP ウィンドウ サイズを直接制御することはできません。これらのバッファを設定しない場合、ソケット レベルでデフォルトのバッファ サイズが取得されます。TCP は、ウィンドウ サイズ内にある順不同のパケットが受信されるかどうかに応じてキューイングします。順序どおりのデータを受信すると、ソケット レベルがトリガーされ、データがソケット レベル バッファにプッシュされ、使用可能なスペースの量だけプッシュされます。TCP が受信したすべてのデータをソケット バッファにプッシュできない場合、これは TCP ウィンドウ サイズを計算するアルゴリズムに影響を与えます。この計算メカニズムは、TCP バッファに残っているバイト数に基づいています。

サーバーもクライアントも、誰もクラッシュしません。

高速で送信できるクライアント側では、TCP がサーバーのアドバタイズされたウィンドウ サイズに基づいて、ネットワーク上に多くのデータを送信できないことがわかるため、同様のことが起こります。そのため、クライアントの送信バッファがいっぱいになります。満杯の場合、クライアント ソケットは送信時にブロックするか (ブロッキング モード)、ブロックすることを示すエラー メッセージを返します (非ブロッキング モード)。

したがって、これは何が起こるかを説明するだけではなく、なぜそれらのことが起こるのか、どのように実装されるのかについても説明しようとしました。

于 2015-05-24T14:29:28.563 に答える
2

送信速度が処理速度よりもはるかに速い場合はどうなりますか? たとえば、クライアントが 1 秒あたり 1 MiB を送信しても、サーバーは 1 秒あたり 1 KiB しか処理できない場合…</p>

送信者がブロック モードの場合、受信者より先に進みすぎるとブロックされます。

ノンブロッキング モードの場合は、 send()-1 を返しますerrno == EAGAIN/EWOULDBLOCK.

システムメモリのクラッシュを引き起こしますか?

いいえ。

ソケット API に受信バッファ サイズの設定があることは知っています。

  1. バッファ サイズを設定したが、データがフラッディングしている場合はどうすればよいですか?

受信ホストは、受信バッファがいっぱいになると、送信を停止するように送信者に指示します。

  1. 受信バッファ サイズを設定しないとどうなりますか?

デフォルトのサイズになります。

于 2015-05-24T08:18:52.197 に答える