TCP RSTパケットを受信すると、ホストは、リモートホストによってすでにACKされているがソケットを使用してアプリケーションプロセスによって読み取られていない受信バッファ内の残りのデータをすべて破棄しますか？TCP RSTはホストに受信バッファをドロップさせますか？
他のホストが何も言わなくてもすぐにソケットを閉じるのは危険ですか（リソースを節約するなど）。例えばもしそれが相手方に私がすでに送ったデータを失うことになるかもしれないが、彼はまだ読んでいない。
RSTは一般的に回避され、完全な双方向通信の失敗を示しますか、または上記の例のように接続切断を一方向に強制的に強制するのは比較的安全な方法ですか？
ソケット上のアプリケーションレベルclose(2)は、RSTを生成しませんが、反対側に送信されるFINパケットを生成します。その結果、通常の4方向接続が切断されます。 RSTは、存在しないTCP接続をターゲットとするパケットに応答して、ネットワークスタックによって生成されます。
一方、ソケットを閉じても、もう一方の面に書き込みデータが残っている場合は、次のsend(2)はEPIPEとなります。
上記を念頭において、明示的な「ログアウト」または「切断」メッセージを含むTCPの上に独自のプロトコルを設計する方がずっと優れています。
これは必ずしもRSTを生成するとは限りませんが、ソケットの受信バッファに未読データがある場合は間違いありません。私は現在、タイムアウトが期限切れになるか、ソケットを閉じる前に相手がFINを送ったことを意味するreadによって0が返されるまで、常にバッファを使い切っています。私の2番目のリンクで詳しく説明しています。 – lxgr
はい、これらはよく知られている優れたリソースであり、自分で見つけたことは素晴らしいです。そこから引用するには： "... CLOSEが呼び出された後に新しいデータが受信された場合、そのTCPはRSTを送信してデータが失われたことを示すべきです（SHOULD）。サーバーが接続の終了を閉じた後に、クライアントからデータを送信します。それが問題です。だからあなたはより高いレベルのプロトコルが必要です。 –
私は、彼らはデータの損失が、その場合には十分に可能であることを示している、話題のいくつかの素晴らしい説明を見つけた： http://blog.olivierlanglois.net/index.php/2010/02/06/tcp_rst_flag_subtleties
http://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliableもトピックに関するいくつかのより多くの情報を与え、そして私は」ソリューションを提供しています私のコードで使用されています。これまでのところ、サーバーアプリケーションから送信されたRSTは見られませんでした。
RSTパケット（本質的に接続を閉じる）を送信すると、受信バッファに何が起こるかは推測できます*実装に依存* –
公正なポイント - 私は最悪の場合に興味があると言います。バッファ内のデータは廃棄されます。それはどんなホストでも現実的に起こりますか？ – lxgr
@Ixgr受信しているRSTパケットでバッファがフラッシュされるのではないかと疑います。しかし、それが本当に事実かどうかはわかりません。私はあなたがそれを試す必要があると思います。私は、受信側のアプリケーションが内部にあるものを受け取るという意味で、バッファが空になると言います。再び、推測だけは分かりません。 –