TCPハーフオープン接続とTCPハーフクローズ接続とは

TCPハーフオープン接続とTCPハーフクローズ接続の違いは何かを理解しようとしています。

この投稿は、半分閉じた接続で展開します。ハーフオープン接続については、KContreauの正しい説明を参照してください。

ハーフクローズ接続とは何ですか？または：それはバグではなく、機能です！

すべてのTCP接続は、互いに独立して閉じられる2つのハーフ接続で構成されます。したがって、一方の端がFINを送信する場合、もう一方の端はそのFINを（FIN + ACKする代わりに）ACKするだけで、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）によると、TCPストリームをI / Oリダイレクトしたいという要望が、この機能を導入する動機でした。FIN ackがEOFの役割を果たすか、EOFとして変換されるようにします。したがって、基本的には、FINが「リクエストの終了」を通知するアプリケーションレイヤー上で、即興のリクエスト/レスポンススタイルのインタラクションを簡単に作成できる機能です。

TCPが接続を確立すると、ハンドシェイクが行われるため、保証されていると見なされます。

1. 開始コンピューターは接続要求を送信し、SYNを送信します
2. 応答しているコンピューターは要求を許可し、SYN-ACKで応答します
3. 開始コンピューターは確認応答を送信し、ACKで応答します

その時点で接続が確立され、データが流れ始めます。対照的に、UDPパケットは保証されておらず、到着することを期待して送信されます。

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment

公式には、RFCによると、ハーフオープンTCP接続は、確立された接続の片側がクラッシュし、接続が終了したという通知を送信しなかったときです。これは、今日の一般的な使用法ではありません。

非公式に、初期接続を参照できる場合、これは確立されているプロセスの接続です。

http://en.wikipedia.org/wiki/Embryonic_connection

ハーフクローズは、その非公式の定義の反対です。コンピューターが確立された接続を切断している途中の状態です。

他の人は、ハーフオープン接続とハーフクローズ接続が実際に何であるかを説明するのにかなりまともな仕事をしましたが、ハーフオープン接続のアイデアは、それらが問題であるという文脈でしばしば検索されます。

インターネットには、「ハーフオープン」または「ハーフクローズド」という用語が何を表すべきかについての議論がありますが、私が知る限り、用語は単なる意味論です。「ハーフオープン」接続は「問題」であり、「ハーフクローズ」は、ファイルのダウンロードがハーフクローズ状態で終了する前に送信ストリームを閉じることで送信ストリームを閉じることができる設計機能であると言う人もいます（他のユーザーが説明したように）。

ただし、もう1つは「問題」についてです。TCP接続を開くには3ウェイハンドシェイクが必要で、閉じるには4ウェイハンドシェイクが必要です。

TCPには、クライアントに送信される最終FINパケットがルーター/ネットワークによってドロップされる可能性があるという脆弱性があり、実際の意図は接続を完全に閉じることであった場合、接続は半分開いています。このアプローチおよび類似のアプローチは、多くの帯域幅を必要とせず、サーバーの実装に応じて貴重なハンドル、ソケット、およびスレッドを使い果たす可能性があるため、サービス拒否攻撃の一般的なタイプでしたが、実世界でも発生する可能性があります粗悪な無線通信事業者のおかげで、周波数が増加しています。

オペレーティングシステムは、特定の時間にオペレーティングシステムに存在できるハーフオープン/クローズ接続の数を制限し、接続を維持できる最大時間を導入することにより、ハーフオープンDDoS攻撃に対抗する試みを行いました。ハーフオープン/クローズ状態。最後に、個人的に確認しましたが、Windowsの制限時間はかなり長かった（思い出すと2日です）。

この状態は、TCPキープアライブのオプションの性質によってさらに悪化します。TCPキープアライブは、完全に実装された場合、デッド/ゾンビ接続を検出するためのプロトコルレベル（アプリケーションレベルではなく）ソリューションとして意図されたものです。しかし、TCPが設計されたとき、帯域幅は現在よりもかなり貴重であり、TCPの必須のキープアライブタイマーがあまりにも「おしゃべり」であるという懸念がありました。したがって、キープアライブはオプションであり、通常は使用されず、RFC1122に準拠したルーターによる送信が保証されていません。だから...シナリオを検出/処理するためにTCPレイヤーでキープアライブを有効にしても、トラフィックが世界中を移動するときに、一部のルーターがキープアライブパケットをドロップしていることがわかります...テストする可能性のあるもう1つのまれなシナリオ。

ハーフオープン接続は、特にTCPベースのサーバーを作成するコーダーにエンジニアリング上の少しの課題をもたらします。特に、高負荷時、および通常は運用サーバー上で、意図せずにランダムに表示される可能性があるためです。アルファ/ベータテスト段階では気づきにくい。私の経験では、1日あたり250万の接続を処理するサーバーで40,000に1回の接続で発生することがわかりましたが、これらの数は、トラフィック条件とサーバーとクライアント間のインターネットの各区間のトラフィック条件によって異なります。

エンジニアとして、まれに発生するライブのデプロイ済みサーバーでのみ発生する問題を追跡することは困難な場合があるため、TCPサーバーコードを記述する際にこのまれな接続状態をシミュレートして、サーバーがどのように反応するかを分析することが重要ですこの状況に直面しました。たとえば、TCPサーバーが静的な数のワーカースレッドを使用している場合、たとえば実稼働環境に展開するときに、それらすべてがゾンビ接続によって消費されることがあります。接続に大量の作業メモリが必要な場合、最終結果はメモリリークのように見える可能性があります。などなど

100％実行可能なキープアライブソリューションがなければ、TCPはユーザー層に任せて、ハーフオープン/クローズ接続の処理方法を決定します。そのため、コードには、検出、タイムアウト、およびクリーンアップのための計画/メカニズムが必要です。この状態が発生したときにリソースを増やす...つまり...これはあなたが発明したプロトコルであり、プログラマが通常使用する多くの（悪い）オープン標準の1つではないと仮定しています。もちろん、私はHTTPなどのプロトコルについて言及していますが、これはTCP上でのみ実行されます。これらのプロトコルは、このプログラマーの意見では非常に過大評価されています。

TCPの弱点とHTTP / Webトラフィックの送信に対する不幸な人気を認識して、スマート企業は代替品を模索しています。たとえば、GoogleはHTTPをUDPで送信するQUICと呼ばれるプロトコルを試しました。TSCPと呼ばれるオープンプロトコルもあります。ただし、これらのプロトコルはどれも広く採用されていません。

原則として、独自のUDPベースのプロトコルで排他的に通信するために、独自のサーバーをすべて構築します。しかし、UDPはあなたが思っているよりもトリッキーであり、私は常により速く、よりスマートに、より低いレイテンシーで、より低い輻輳になるように微調整しているように感じます... ）

TCP接続終了の最良の説明

TCP 3ウェイハンドシェイクプロセスでは、SYNビットセグメントを使用してTransmission Control Protocol（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/

半分閉じた接続はサーバーとクライアントの一端が接続を終えるつもりであるとき確立されるプロセスです。TCPは接続指向プロセスであるため、特定のアプリケーション用に各ソケットが開かれます。TCPでは、アプリケーションを終了するプレッシャーはありません。したがって、接続指向のプロセスは待ち信号で終了を延ばします。これは、TCP（接続）でハーフクローズと呼ばれます