インタビュアー: Socket TCP はどのように切断するのですか?

• まえがき

• ソケットとは何ですか?

• ソケットの実行プロセス

• TCP に基づく

• UDP に基づく

• ##Socket TCP が接続を確立する方法

#スリーウェイ ハンドシェイクはどのソケット関数で行われますか?

ソケット TCP はどのように切断されますか?
#第 4 波の後に 2MSL まで待つ理由

##序文

インターネットのことになると、誰もが間違いなく TCP、UDP、HTTP、スリーハンドル 4 ウェーブなどを思い浮かべるでしょう。しかし、ソケットのことになると、誰もが少し混乱するかもしれません。ネットワークで使われるソケットって何? ? ソケットとは何ですか?なぜネットワークは Socket から切り離せないのでしょうか?

Socket とは何ですか?

Socket は実際にはソケットです。Socket についてほとんどの人が理解しているのは、単純なネットワーク通信を実装できるということですが、"何問題は具体的に解決されますか? 実際の効果は何ですか? ソケットが表示されるのはなぜですか?"

ソケットは実際には

"アプリケーション層 A にありますトランスポート層とトランスポート層の間の製品です. トランスポート層の多くの複雑な操作をいくつかの単純なインターフェイスにカプセル化し, アプリケーション層がそれらを呼び出してネットワーク内のプロセス通信を実現できるようにします. ソケットはポート通信用に開発されました. このツールは詳細です低レベル。

ソケットは実際には食器洗い機に似ています。その機能は食器を洗うこと (ネットワーク通信) です。これがないと、食器を手動で洗う必要がある場合があります (トランスポート層とアプリケーション層を手動で呼び出す)。 API 間の相互接続)、しかしこれを使用すると、スイッチをクリックして期間を調整するだけで済みます (API をカプセル化)。必要ありませんが、それがなければ皿を洗うだけです (アプリケーション層とトランスポート間の対話)レイヤー）は非常に面倒になります。

#完全なネットワーク通信は、物理トランスポート層のネットワーク ケーブルとネットワーク カードを経由する必要があります。ネットワーク トランスポート層の IP プロトコルは、どのマシンがコンピュータ システム内でさまざまなプロセスを実行するかという問題を解決するために、

「ネットワーク カード内のネットワーク データがどのプロセスのためのものであるかを識別する」

、これが実際に Socket が解決するように設計されているものです。

ソケットは 「TCP/IP または UDP/IP プロトコルのカプセル化」 です。ソケット自体は実際には呼び出し側インターフェイスです。このインターフェイスを使用すると、ネットワーク アプリケーションを開発するときに、下層の実装方法を気にする必要がなくなり、開発の難易度が軽減されます。

#ソケット実行プロセス

TCP に基づく

Server

• socket(): ソケットの作成を示し、最下層はソケットを表すファイル記述子を生成します
• bind(): サービスのバインドに使用されるポートとアドレスは、クライアントが接続するときに指定する必要があるため、通常はここで固定されます。
• listen():バインディングが完了すると、listen はこのポートのデータ パケットをリッスンします
• accept(): これはスイッチに相当し、準備ができており要求を受け入れることができることを示します。ただし、クライアントが正常に接続するまでブロックされます。
• read(): クライアントによって送信されたコンテンツを読み取ります
• write ():クライアントは返されるデータを書き込みます
• close(): 切断、
  「4 回振る」

##Client

socket(): ソケットの作成を示し、最下層はソケットを表すファイル記述子を生成します
connet(): 指定されたアドレスに接続することを示します。その前に、独自のポートがランダムに作成されます。TCP の
• 「ここからスリーウェイ ハンドシェイクが始まります」
write(): クライアントは、送信するデータを書き込みます。
• #read(): クライアントは、サーバーから返されたデータを読み取ります。 Data
• close(): 切断、
「4 回手を振る」
• 、切断情報をクライアントに送信

UDP に基づく

ここでは詳細については説明しません。フローチャートから、

UDP はステートレスであるため、サーバーへの接続がなく、Recvfrom() メソッドを呼び出した後にクライアントのリクエストを受信し、完了するまでブロックされることがわかります。

Socket TCP が接続を確立する方法

Socket がサーバー アドレスをバインドした後、サーバーとの接続の確立が開始されます。接続は実際には有名な 3 回のハンドシェイクです

• 最初のハンドシェイク: A の TCP プロセスは送信制御ブロック TCB を作成し、接続要求セグメントを B に送信します。次に、同期ビット SYN を 1 に設定し、初期シーケンス番号 seq=x を選択すると、クライアント A は SYN-SENT (同期送信済み) 状態になります。
• 2 回目のハンドシェイク: B は接続要求セグメントを受信し、接続の確立に同意すると、A に確認を送信します。確認メッセージセグメントでは、同期ビット SYN=1、確認ビット ACK=1、確認番号 ack=x 1、初期シーケンス番号 seq=y も自身で選択されます。 SYN-RCVID 状態。
• 3 回目のハンドシェイク: A は B の確認を受信した後、B に確認を送信します。確認メッセージ ACK=1、確認番号 ack=y 1。この時点で、A は ESTAB-LISHED 状態になります。 B も A の確認を受け取ると、ESTAB-LISHED 状態に入ります。接続が確立されました。

##ソケットのどの機能でスリーウェイ ハンドシェイクが発生しますか?

• クライアントが connect を呼び出すと、接続リクエストがトリガーされ、SYN シグナルがサーバーに送信されます。この時点で、connect はブロッキング状態になります。
• サーバーは接続リクエスト、つまり SYN の受信を監視し、accept 関数を呼び出してそれを受信し、ブロッキング状態に入ります。その前に、ソケット、バインド、およびリッスン関数の使用を最大限に試みます。 ; その後、関連する syn 信号と ack 信号を返します
• Customer 端末はサーバーから情報を受信します。この時点で接続が完了し、ブロッキング状態が解除され、ack が返されます。信号がサーバーに送信されます
• サーバーは確認応答を受信し、ブロックを受け入れ、接続を完了します

接続が確立された後、 connect() が実行され、サーバーはクライアントにデータを送信できるようになります。

#Socket TCP の切断方法

• ##第一波: A 接続解放メッセージの最初のセグメント、終了制御ビット FIN を送信します。セグメント ヘッダーに =1、およびシーケンス番号 seq=u (A の前に送信されたデータの最後のシーケンス番号に 1 を加えたものに等しい); その後、A は FIN-WAIT-1 (終了待機 1) 状態に入り、B のメッセージを待ちます。確認。
• 第 2 の波: B は、A の接続解放メッセージ セグメントを受信した後、すぐに確認メッセージ セグメント、確認番号 ack=u 1、シーケンス番号 seq=v (と等しい) を送信します。 B 以前に送信したデータの最後のシーケンス番号が 1 増加し、B は CLOSE-WAIT (クローズ待機) 状態に入ります。
• 第 3 の波: A は、B の確認メッセージ セグメントを受信した後、FIN-WAIT-2 (終了待機 2) 状態に入り、B が接続解放メッセージ セグメントを送信するのを待ち続けます。 ;
• B に送信するデータがない場合、B は接続解放メッセージ セグメントを A に送信します。セグメント ヘッダーの終了制御ビット FIN=1 とシーケンス番号 seq=w (一部のデータはセミクローズ状態で送信される場合があります)、確認番号 ack=u 1 の場合、B は LAST-ACK (最終確認) 状態に入り、A の確認を待ちます。
• 4 番目の波: A は B の接続解放メッセージ セグメントを受信し、確認を送信します。確認セグメント内の確認ビット ACK=1、確認番号 ack=w 1、シリアル番号 seq=u 1; その後、A は TIME-WAIT (時間待ち) 状態になります。 B が再度確認セグメントを受信すると、B は CLOSED 状態になります。

なぜ第 4 波後の 2MSL まで待たなければならないのですか?

まず第一に、 2MSL はクライアントからです (A) FIN 受信後、ACK を送信した時点でタイミングが開始されます。 TIME-WAIT 時間以内にクライアント (A) の ACK がサーバー (B) に送信されず、サーバー (B) が再送信した FIN メッセージをクライアント (A) が受信した場合、2MSL 時間はリセットします。 2MSL を待つ理由は次のとおりです。

• 1. 元の接続データ パケットが失われます
• B がそのパケットを受信しない場合、タイムアウト後に FiN が再送信された場合、A は再送信された FIN を再度受信し、再度 ACK を送信します。
• B が自身の ACK を受信した場合、何も送信しません。その他のメッセージ

最後のウェーブの後、A は B が自分のメッセージを受信したかどうか知りません。 ACK を含め、A は上記の両方の状況を待機する必要があります。最悪のシナリオに対処するには、2 つの状況の待機時間の最大値を取得する必要があります。最悪のシナリオは、ACK メッセージの最大生存時間に移行することです。 (MSL) 受信 FIN メッセージの最大生存時間 (MSL)。これは正確に 2MSL であり、元の接続されたデータ パケットがネットワークから消えるのに十分な時間です。

• 2. サーバーが ACK を受信できることを確認し、接続を正しく閉じます。

この ACK が失われる可能性があるため、サーバーがエラーを引き起こす可能性があります。 FIN-ACKメッセージを確認してください。クライアントが 2MSL を待たずに、ACK を送信した直後にクローズを解放すると仮定すると、ACK が失われると、サーバーは正常にクローズ接続状態に入ることができなくなります。

以上がインタビュアー: Socket TCP はどのように切断するのですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。