TCP / IPストリームソケットサービスのクライアントが、データをバッファ（当然、アプリケーションバッファについて話している）に移動して操作するよりも速くデータをサービスに送信する可能性のあるシナリオを説明したいと思いますrecv。
それで、基本的に、そのようなシナリオでは何が起こりますか？
明らかに、ユーザーアプリケーションである私のサービスの下にあるある種のサービスは、着信ストリームを受信し、「recv」を発行するまでどこかに保存する必要がありますよね？最も確かにオペレーティングシステム。
古い質問を再開したくありませんが、この一見明白な質問に対する答えが見つからないようです。
TCP はフロー制御を提供します。TCP スタック (送信側と受信側の両方) は、一部のデータをバッファすることができます。これは通常、OS カーネルで行われます。
受信者のバッファーがいっぱいになると、送信者はそれを認識し、それ以上のデータの送信を停止します。最終的には、スペースが再び利用可能になるまで、送信側のアプリケーションがブロックされます (または、それ以上のデータを送信できなくなります)。
簡単に説明すると、送信されるすべての TCP パケット (セグメント) には、バッファリングできるデータのサイズ (ウィンドウ サイズ) が含まれます。これは、バッファーがいっぱいになったために受信者が破棄することなく、送信できるデータ量を相手側が常に知っていることを意味します。ウィンドウ サイズが 0 になると、バッファがいっぱいになり、それ以上データが送信されなくなります (送信側がブロックされている場合は、send()呼び出しがブロックされます)。tcp ウィンドウがまだ 0 であるかどうかを調べるための手順があるため、送信を再開できます。データが消費されたとき。
ここにもう少し詳細があります
これは、データ バッファー (受信データ用のものを含む) を維持するネットワーク ドライバー スタックです。バッファーがいっぱいになると、結果として生じる TCP パケットがドロップされ、クライアントはデータを送信しようとしてスタックします。これについては、こちらとこちらでもう少し詳しく説明しています。