この投稿は、半分閉じた接続を拡張します。ハーフオープン接続については、KContreauの正しい説明を参照してください。
ハーフクローズ接続とは何ですか？または：バグではありません-機能です！
すべてのTCP接続は、相互に独立して閉じられる2つのハーフ接続で構成されます。したがって、一方の端がFINを送信した場合、もう一方の端は（FIN +の代わりに）そのFINにACKするだけですACK-ing）、FIN送信側に送信するデータがあることを通知します。そのため、両端はESTABLISHED以外の安定したデータ転送状態になります。つまり、FIN_WAIT_2（受信側の場合）とCLOSE_WAIT（このような接続は半分閉じていると言われ、TCPは実際にはこれらのシナリオをサポートするように設計されているため、半分閉じた接続はTCP機能です。
ハーフクローズ接続の歴史
RFC 793は「ハーフクローズド」という用語に言及することなく生のメカニズムのみを説明していますが、RFC 1122はセクション4.2.2.13でその問題について詳しく説明しています。一体誰がその機能を必要としているのか疑問に思うかもしれません。 TCPの設計者もUnixシステムにTCP/IPを実装し、すべてのUnixユーザーと同様に、I/Oリダイレクションが大好きでした。W。Stevensによると（TCP/IPの図解、セクション18.5） I/Oリダイレクトへの欲求TCPストリームは、この機能を導入する動機でした。これにより、FIN ackがEOFの役割を果たすか、またはEOFとして変換できるようになります。したがって、基本的には、 FINが「リクエストの終了」を通知するアプリケーションレイヤー上で即座にリクエスト/レスポンススタイルの対話を作成します。
他の人は、実際にどのようなハーフオープンおよびハーフクローズ接続を記述するかについてかなりまともな仕事をしましたareですが、ハーフオープン接続のアイデアは、それらが問題。
「ハーフオープン」または「ハーフクローズド」という用語が何を表すべきかについてはインターネット上で議論がありますが、私に関する限り、用語は単なる意味論です。 「ハーフオープン」接続は「問題」であると言う人もいますが、「ハーフクローズ」は、ファイルのダウンロードがハーフクローズ状態で完了する前に送信ストリームを閉じることによって送信ストリームを閉じることができる設計機能です（他のユーザーが説明したように）。
ただし、もう1つについては、「問題」：TCP接続を開くには3ウェイハンドシェイク、それを閉じるには4ウェイハンドシェイクが必要です。
TCPには、クライアントに送信された最後のFINパケットがルーター/ネットワークによってドロップされる可能性があるという脆弱性があり、実際に接続を完全に閉じることが意図されていた場合、接続が半オープンになります。これと同様のアプローチは、多くの帯域幅を必要とせず、サーバーの実装に応じて貴重なハンドル、ソケット、スレッドを使い果たす可能性があるため、サービス拒否攻撃の一般的なタイプですが、現実の世界でも発生する可能性がありますお粗末な無線通信事業者のおかげで周波数が増加しています。
オペレーティングシステムは、特定の時間にオペレーティングシステムに存在できるハーフオープン/クローズ接続の数を制限し、接続を維持できる最大時間を導入することにより、ハーフオープンDDoS攻撃に対抗する試みを行いましたハーフオープン/クローズ状態。最後に個人的に確認したのですが、Windowsの制限時間はかなり高かった（覚えていれば2日間）。
この条件は、TCPキープアライブのオプションの性質によってさらに悪化します。完全に実装されている場合、アプリケーションレベルではなくプロトコルレベルの）デッド/ゾンビ接続を検出するソリューションとして意図されていました。しかし、TCPが設計されたとき、帯域幅は現在よりもかなり貴重であり、TCPのマンダトリーキープアライブタイマーがあまりにも「おしゃべり」です。したがって、キープアライブはオプションであり、一般的には使用されず、RFC1122に従ってルーターによって送信されることが保証されていません。したがって、キープアライブをTCP =シナリオを検出/処理しようとしてレイヤーを作成すると、トラフィックが世界中を移動するときに、一部のルーターがキープアライブパケットをドロップしている可能性があります...テストする別のまれなシナリオが作成される可能性があります。
ハーフオープン接続は、TCPベースのサーバーを作成するプログラマーにとって、特に高負荷時や、通常は運用サーバー上で、意図せずにランダムに表示される可能性があるため、技術的な課題が少し発生します。アルファ/ベータテスト段階では気づきにくい。私の経験では、1日あたり250万の接続を処理するサーバーでは、40,000分の1の接続で発生することがわかりましたが、これらの数値は、サーバーとクライアント間のインターネットのすべてのレッグのトラフィック状況やトラフィック状況によって異なります。 。
エンジニアとして、まれに発生する問題を追跡し、展開されたライブサーバーでのみ追跡することは困難な場合があるため、TCP serverを書き込むときに、このまれな接続状態をシミュレートすることが重要です。この状況に直面したときにサーバーがどのように反応するかを分析するコード。たとえば、TCPサーバーが静的な数のワーカースレッドを使用している場合、ゾンビ接続によって消費されたすべてのスレッドが見つかります。たとえば、本番環境にデプロイします。接続に大量の作業メモリが必要な場合、最終結果はメモリリークなどに似ている可能性があります。
100％実行可能なキープアライブソリューションがない場合TCPは、それをユーザー層に任せて、ハーフオープン/クローズ接続の処理方法を決定するため、コードには以下の計画/メカニズムが必要です。この状態が発生したときにリソースを検出、タイムアウト、およびクリーンアップします...つまり...これはあなたが発明したプロトコルであり、プログラマーが通常使用する多くの（悪い）オープンスタンダードの1つではないと仮定します。 TCPだけで実行されるHTTPなどのプロトコルを指します。これらのプロトコルは、このプログラマーの意見では非常に過大評価されています。
TCPの弱点と、HTTP/Webトラフィックを送信することの不運な人気を認識し、スマート企業は代替品を模索しようとしました。たとえば、GoogleはHTTPを介してHTTPを送信するQUICと呼ばれるプロトコルを実験しましたUDP。TSCPと呼ばれるオープンプロトコルもありますが、これらのプロトコルはどれも広く採用されていません。
原則として、私は自分のすべてのサーバーを構築して、自分のUDPベースのプロトコルで排他的に通信します。 UDPはあなたが思っているよりもトリッキーであり、私は常にそれをより速く、よりスマートで、より低いレイテンシ、より低い輻輳に微調整しているように感じます...しかし、少なくともハーフオープン接続に対処する必要はもうありません。 ）
TCPが接続を確立すると、ハンドシェイクが行われるため、接続が保証されていると見なされます。
- 開始コンピューターは接続要求を送信し、SYNを送信します
- 応答するコンピューターが要求を許可し、SYN-ACKで応答する
- 開始コンピューターは確認応答を送信し、ACKで応答します
その時点で接続が確立され、データが流れ始めます。対照的に、UDPパケットは保証されず、そこに到達することを期待して送信されるだけです。
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment
RFCによると、正式には、ハーフオープンTCP接続は、確立された接続の片側がクラッシュし、接続が終了しているという通知を送信しなかった場合です。これは一般的な使用法ではありません。今日。
非公式には、確立中の接続である初期接続を参照できる場合。
ハーフクローズは、その非公式の定義の反対です。コンピュータが確立された接続を切断している途中のどこかである状態です。
TCP接続終了の最良の説明
TCP 3-wayハンドシェイクプロセスで、SYNビットセグメントを使用して伝送制御プロトコル（TCP）でクライアントとサーバー間の接続を確立する方法を調査しました。この記事では、TCPクライアントとサーバー間の接続を閉じます。ここでは、FINビットが1に設定されているサーバーにビットセグメントを送信する必要もあります。
11 
メカニズムの仕組みTCP：
Step 1 (FIN From Client) – Suppose that the client application decides it wants to close the connection. (Note that the server could also choose to close the connection). This causes the client send a TCP segment with the FIN bit set to 1 to server and to enter the FIN_WAIT_1 state. While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment (ACK).
Step 2 (ACK From Server) – When Server received FIN bit segment from Sender (Client), Server Immediately send acknowledgement (ACK) segment to the Sender (Client).
Step 3 (Client waiting) – While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment. When it receives this segment, the client enters the FIN_WAIT_2 state. While in the FIN_WAIT_2 state, the client waits for another segment from the server with the FIN bit set to 1.
Step 4 (FIN from Server) – Server sends FIN bit segment to the Sender(Client) after some time when Server send the ACK segment (because of some closing process in the Server).
Step 5 (ACK from Client) – When Client receive FIN bit segment from the Server, the client acknowledges the server’s segment and enters the TIME_WAIT state. The TIME_WAIT state lets the client resend the final acknowledgment in case the ACK is lost.The time spent by client in the TIME_WAIT state is depend on their implementation, but their typical values are 30 seconds, 1 minute, and 2 minutes. After the wait, the connection formally closes and all resources on the client side (including port numbers and buffer data) are released.
詳細： https://www.geeksforgeeks.org/tcp-connection-termination/