こんにちは、皆さん〜私はあなたの古い友人です: Xiao Zhou ღを守ってください
この記事では、信頼性の高いデータ伝送を保証するためのネットワーク プログラミングにおける TCP 伝送制御プロトコルのメカニズムの1 つである接続管理について説明します。接続を開くための「ハンドシェイク」および「手を振る」操作の実行方法について、この記事で分析します。 ~~
この問題はブロガーのコラムに含まれています: JavaEE_Protect Xiao Zhouღのブログ-CSDN ブログ
プログラミングの初心者に適しており、興味のある友人は他の「JavaEE Basics」を購読して閲覧できます。
さらなるハイライトにご期待ください: 小州を守る ღ *★,°*:.☆(￣▽￣)/$:*.°★*'
1. 前期の振り返り
1.1 TCP メッセージの構造
TCP メッセージを簡単に分析してみます。
シリアル番号と確認番号: 信頼性の高いデータ送信のためにそれぞれ 32 バイナリ ビットを占有し、データ送信の順序が受信の順序と同じであることを保証するために、送信されるバイト ストリームの各バイトに順番に番号が付けられます。シーケンス番号は、現在送信されているデータ パケットのシーケンス番号を表し、確認番号は、次に受信されることが予想されるデータ パケットのシーケンス番号を表します。シリアル番号と確認番号の重要性は、データの送信順序が受信順序と同じであることを保証することです。
フラグ ビット: ACK、SYN、FIN、RST、PSH、URG が含まれ、それぞれ 2 進ビットを占めます。
デフォルトでは 0 に設定されており、1 に設定されている場合は true を意味します。
ACK:データパケットの受信を確認するために使用されます。
SYN:通信当事者が接続を確立したかどうかを判断します。
FIN:接続を閉じるために使用; 0
RST:接続をリセットするために使用されます。
PSH:受信側に、受信バッファに入力する代わりにデータをアプリケーションにすぐにプッシュするよう促すために使用されます。
URG: TCP パケットに緊急データがあることを示すために使用されます。
1.2 確認応答とタイムアウト再送信
確認応答:
受信者が送信者によって送信されたデータを受信すると、TCP ヘッダーを含むフィールド フィードバックが送信者に送信されます。ACK = 1 (バイナリ ビット) は、データを受信したことを示します。
上記のメカニズムには、次の 3 つの状況があります。
1. データは送信プロセス中に直接失われ、データが受信されない場合、受信機はフィードバックを与えることができません。
2. データを受信した後、受信者は送信者にフィードバックを送信しますが、フィードバック メッセージは送信中に失われます。
3. 送信者が一定期間フィードバックを受信しない場合、タイムアウト再送信がトリガーされ、再送信されたデータは失われます
タイムアウト再送信:
送信者が一定時間内に受信者からの確認応答を待たなかった場合、TCP は「。TCP」パケットデータ、このネットワーク通信を終了します。
接続を再確立してネットワーク通信を終了する方法が、この記事の主題です~~
具体的な内容については、ブロガーの以前のブログを参照してください: [TCP プロトコル] メッセージ形式、信頼性の高いデータ送信のメカニズム (1)_Xiao Zhouღ のブログの保護 - CSDN ブログ
2. 接続管理
TCP トランスポート層プロトコル、プロトコル機能: 通信の 2 者間のデータ送信の信頼性を確保します。
保証の重要な要素は確認応答とタイムアウト再送のメカニズムです. 受信者はデータを受信した後, 送信者にフィードバックを返します. このフィードバックは TCP 固定ヘッダーを持つフィールドです. TCP ヘッダーにはフラグビット情報が含まれており, 各フラグはbit はバイナリビットのみを占有するため、TCP ヘッダーのフラグビットに従って、現在の「TCP パケット」の状態を判断できます。
TCP プロトコル通信における 2 者間の接続は、3 ウェイ ハンドシェイクを通じて確立されます。
2.1 スリーウェイハンドシェイク
ハンドシェイク (handshake) とは、二者間の通信、ネットワーク相互作用、送信者と受信者間の 3 つの相互作用を通じて、接続関係が確立されることを指します。接続関係とは、通信の二者がお互いの情報を記録していることを指します。
なぜクライアントとサーバーについて言及するのかというと、私たちの日常の通信では、通信の双方が直接接続を確立するのではなく、まずサーバーとの接続を確立し、情報がサーバーを介して「転送」されるからです。
接続を確立する「意志」はクライアントによって開始される必要があります
クライアントは、接続を確立する要求を示すSYN パケットをサーバーに送信します。
SYNパケットを受信した後、サーバーはSYN+ACKパケットで応答し、接続の確立に同意することを示します。
クライアントはSYN+ACKパケットを受信すると、接続が正常に確立されたことを示すACKパケットで応答します。
SYN: (バイナリ ビット) 1 に設定されると、一方の当事者が他方の当事者への接続を申請したいことを意味します。現在の TCP データグラムが同期メッセージであることを示します。
ACK: バイナリ ビット)、1 を設定するとフィードバックを与え、データの受信を確認することを意味します。現在の TCP データグラムが応答メッセージであることを示します。
2 つの通信当事者間の接続を確立する概略図:
ブロガーはここでこれを使用し、「接続を確立する」ために電話をかけるシーンをシミュレートしました。おそらくそのような呼び出しまでに一定の時間がかかるかもしれませんが、主な目的は、両者の送受信能力を確認することです。通信相手が正常である: 対話プロセスの正常性が確認され、その後の信頼性の高いデータ送信の基礎にもなります。
なぜ 3 ウェイ ハンドシェイクがあるのでしょうか。2 回行うことはできますか、4 回行うことはできますか?
まず、2 回のハンドシェイクでは、一方の相手の送受信機能が正常であることしか確認できません。
複数のハンドシェイクの場合、AYN と ACK を途中で分割して別々に送信することでも検証の目的を達成できますが、TCP データ セグメントをカプセル化してレイヤーごとに分割する必要があるため (TCP/IP 5-レイヤ通信モデル）、2 回送信するため、効率が非常に低くなります。
2.3. 4 つの波
4回手を振ると、通信中の双方が切断されることを意味します。これも素敵な名前です。
切断の「意志」は、クライアントとサーバーの両方によって開始される場合があります。
クライアントは、切断したいことを示すFIN パケットをサーバーに送信します。
FIN パケットを受信した後、サーバーはACK パケットで応答し、切断要求が受信されたことを示します。
次に、サーバーはFIN パケットを送信し、切断に同意します。
クライアントは FIN パケットを受信すると、切断要求が受信されたことを示すACK パケットで応答します。
FIN: (バイナリ ビット) 1 に設定された場合は、一方の当事者が他方の当事者に切断を申請したいことを意味します。現在の TCP データグラムが終了メッセージであることを示します。
2 つの通信当事者間の切断の概略図:
上記の処理により、通信を行っている双方がそれぞれ相手にFIN（終了メッセージ）を送信し、それに対してそれぞれACK（応答メッセージ）を送信することで切断が行われます。
「スリーウェイ ハンドシェイク」を学習すると、SYN + ACK、接続要求 + 確認応答という操作があり、2 つのフラグ ビットを同じ TCP データグラムでフィードバックできるため、 3 つの
ただし、切断時には FIN と ACK が別々に送信されるため、切断には通信当事者間で4 回の。
その理由は、SYN + ACK は両方ともオペレーティング システム カーネルによって完了され、同時にトリガーできるためです。
TCP はトランスポート層プロトコルに属しており、プログラム開発者としては実際にはアプリケーション層の開発に重点を置いていますが、開発には TCP プロトコルに基づくソケット インターフェイス (API) を使用することを選択します。トランスポート層、ネットワーク層、データリンク層、物理層、これらの 4 つの層は実際にはオペレーティング システムによってカプセル化されており、層ごとに呼び出されるため、アプリケーション層はトランスポート層プロトコルによって提供されるインターフェイスを直接使用します。他の内部実装についてはあまり注意を払う必要はありません。
4回手を振る：
ACK と FIN は別のマシンによってトリガーされ、ACK はシステム カーネルによって完了されるため、FIN 切断要求を受信した後、送信者は最初に確認応答を受け取ります。
FIN - 切断はアプリケーション コードによって制御されます。Java ネットワーク プログラミングでは、Socket (インターフェイス) の close() メソッドが呼び出され、 TCP データグラムが送信され、終了メッセージで FIN が 1 に設定されると、FIN がトリガーされます。
たとえば、サーバーはクライアントが終了メッセージを送信したことを検出し、独自に close() メソッドを呼び出し、2 番目の終了メッセージをトリガーします。もちろん、close() メソッドを呼び出すために何を使用するかは、プログラムの記述方法によって異なります。
プログラムが終了メッセージをトリガーする close() を呼び出していない状況について
例:クライアント側のプログラムに close() がまったく記述されていない場合、サーバーはクライアントに終了要求 FIN を送信しますが、サーバーは顧客サービス側からフィードバックされる終了メッセージを受信できません。 。接続を切断することは不可能ですか、いいえ、いいえ
クライアントのプログラムが終了する - プロセスが終了する - アプリケーションが終了する - qq の実行が終了するなどの場合、自動的に「close()」がトリガーされ、プロセスの終了とともにリソースも終了し、システムが回復を制御します。 FINエンドレポートアーツが発動します。この時点で、クライアントの qq アプリケーションは実行されていますが、qq サーバーとの 4 回の wave が終了するまで、TCP 接続は引き続き存在します (オペレーティング システム カーネルによって維持されます)。逆も同様です。
TCP プロトコルは全二重であることに注意してください。つまり、クライアントとサーバーは同時にデータを送受信できます。したがって、切断するときは 4 回手を振る必要があり、オペレーティング システム カーネルは、両方の当事者が確実に切断されたことを確認するために、ウェイブ プロセスを維持します。
さて、ここで、 ネットワーク プログラミングにおける[TCP プロトコル] 接続管理の「スリーウェイ ハンドシェイクとフォーウェイ ウェーブ」の ブロガーが 共有を終了しました。皆さんのお役に立てれば幸いです。批判や修正があれば歓迎します。何か間違っている。
この記事を読んでくださった皆さんに感謝します。これからも楽しいイベントが続きます: 暁州を守る ღ *★,°*:.☆(￣▽￣)/$:*.°★*
あなたに会ったとき、すべての星が私の頭の上に落ちました
...