ソケットをフラッシュするとはどういう意味ですか？
まるでファイルのように読み書きする方法を除いて、ソケットについてはあまりよく知りません。ソケットセレクターの使い方について少し知っています。ソケットをフラッシュする必要がある理由がわかりません。そこで実際に何が起こっていますか？ビットは、メモリ内のどこかに押し出されるまでたまりませんか？私はソケットについてオンラインでいくつかのことを読みましたが、それはすべて非常に抽象的なレベルの高いものです。
ここで実際に何が起こっていますか？
ネットワークソケットへの書き込みとデータの送信には、ある程度のオーバーヘッドが伴います。バイトがソケットに入るたびにデータが送信された場合、実際のデータのバイトごとに40バイト以上のTCPヘッダーが返されます。（TCPソケットです。他のソケットは異なる値を持ちます。）このような非効率を回避するために、ソケットはローカルバッファを維持します。これは通常1000バイトをやや超えます。そのバッファがいっぱいになると、ヘッダーはデータを包み、パケットは宛先に送信されます。
多くの場合、各パケットをすぐに送信する必要はありません。ファイルを転送する場合、初期データはファイルの最終データなしでは役に立たない可能性があるため、これはうまく機能します。ただし、データをすぐに送信する必要がある場合は、バッファをフラッシュすると、まだ送信されていないデータが送信されます。
ソケットを閉じると、残りのデータが自動的にフラッシュされるため、閉じる前にフラッシュする必要はありません。
ソケットを実際にフラッシュすることはできません。
（From ソケットにデータをバッファーに強制的に送信させるにはどうすればよいですか？ ）
強制することはできません。限目。 TCPは、いつデータを送信できるかを決定します。今、通常、TCPソケットでwrite（）を呼び出すと、
TCPは確かにセグメントを送信しますが、これを強制する方法や保証はありません。 TCPが送信しない理由はたくさんあります
セグメント：閉じたウィンドウとNagleアルゴリズムは、
すぐに頭に浮かぶ。
完全な投稿を読んでください。それはかなり詳細で、私にとって多くのことを明確にしました。
Nagleのアルゴリズムは、ソケットでよく使用されます。簡単に言うと、送信するデータの量が少なくなるまで待機します。問題は、データのパケットを送信する際の送信待ち時間とオーバーヘッドコストのバランスをとることです。
ヘッダーは（ほとんど）固定サイズであるため、データペイロードが大きいほど、無駄な帯域幅が小さくなります。さらに、中間システムには一般に、全体的なデータレートではなく、パケットレートにより大きく基づくパフォーマンス制限があります。
ソケットプログラミングにはフラッシュを使用していません。設定できるモードがいくつかあることを覚えています。ストリーム指向の送信では、送信される小さなパケットの数を減らします。ただし、sendall（）を使用して、バッファー内のすべてが送信されることを確認します。
Shutdown（）関数は、スプールダウンするときに非常に役立ちます。もちろん、あなたはmustぶらぶらしたくない場合はclose（）呼び出しを使用します。
詳細については、 Beejのガイド を参照してください。