TCP/IP を使用した 3 方向ハンドシェイクの説明
この記事では、TCP 接続を開始または終了するときに、クライアントとサーバー間の伝送制御プロトコル (TCP) の 3 方向ハンドシェイク プロセスについて説明します。
適用対象: Windows Server 2012 R2
元の KB 番号: 172983
概要
この記事は、伝送制御プロトコル/インターネット プロトコル (TCP/IP) に精通している対象ユーザーを対象としています。 TCP 接続を開始または終了するときのクライアントとサーバーの間の TCP 3 方向ハンドシェイクのプロセスについて説明します。
詳細
TCP/IP トランスポート プロトコルの TCP レベルは、接続指向です。 接続指向とは、データを送信する前に、信頼できる接続を取得して確認する必要があることを意味します。 TCP レベルのデータ転送、接続の確立、および接続終了は、プロセス全体を制御する特定の制御パラメーターを維持します。 制御ビットを次に示します。
URG: 緊急ポインター フィールドが有効
ACK: 受信確認フィールドの有意性
PSH: プッシュ関数
RST: 接続をリセットする
SYN: シーケンス番号を同期する
FIN: 送信者からのデータはこれ以上ありません
3 方向ハンドシェイクが行われるシナリオは 2 つあります。
接続の確立 (アクティブなオープン)
接続の終了 (アクティブなクローズ)
次のサンプル情報は、ネットワーク モニター キャプチャから取得されました。 Network Monitor は、Microsoft Systems Management Server から取得できるプロトコル アナライザーです。
接続の確立
次のシーケンスは、確立されている TCP 接続のプロセスを示しています。
フレーム 1:
最初のフレームでわかるように、クライアント NTW3 は SYN セグメント (TCP ....S.) を送信します。 これは、シーケンス番号を同期するためのサーバーへの要求です。 初期シーケンス番号 (ISN) を指定します。 ISN は 1 ずつインクリメントされ (8221821+1=8221822)、サーバーに送信されます。 接続を開始するには、クライアントとサーバーが互いのシーケンス番号を同期する必要があります。 最大セグメント サイズ (MSS) を設定するオプションもあります。これは長さ (len: 4) によって定義されます。 このオプションは、送信者が受信する MSS を通信します。 受信確認フィールド (ack: 0) は、3 方向ハンドシェイクの最初の部分であるため、0 に設定されます。
1 2.0785 NTW3 --> BDC3 TCP ....S., len: 4, seq: 8221822-8221825, ack: 0,
win: 8192, src: 1037 dst: 139 (NBT Session) NTW3 --> BDC3 IP
TCP: ....S., len: 4, seq: 8221822-8221825, ack: 0, win: 8192, src: 1037
dst: 139 (NBT Session)
TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 8221822 (0x7D747E)
TCP: Acknowledgement Number = 0 (0x0)
TCP: Data Offset = 24 (0x18)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x02 : ....S.
TCP: ..0..... = No urgent data
TCP: ...0.... = Acknowledgement field not significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......1. = Synchronize sequence numbers
TCP: .......0 = No Fin
TCP: Window = 8192 (0x2000)
TCP: Checksum = 0xF213
TCP: Urgent Pointer = 0 (0x0)
TCP: Options
TCP: Option Kind (Maximum Segment Size) = 2 (0x2)
TCP: Option Length = 4 (0x4)
TCP: Option Value = 1460 (0x5B4)
TCP: Frame Padding
00000: 02 60 8C 9E 18 8B 02 60 8C 3B 85 C1 08 00 45 00 .`.....`.;....E.
00010: 00 2C 0D 01 40 00 80 06 E1 4B 83 6B 02 D6 83 6B .,..@....K.k...k
00020: 02 D3 04 0D 00 8B 00 7D 74 7E 00 00 00 00 60 02 .......}t~....`.
00030: 20 00 F2 13 00 00 02 04 05 B4 20 20 .........
フレーム 2:
2 番目のフレームに示すように、サーバー BDC3 は ACK セグメントと SYN セグメント (TCP .A..S.) を送信します。 このセグメントでは、サーバーは同期のためのクライアントの要求を認識しています。 一方、サーバーはシーケンス番号の同期要求もクライアントに送信しています。 このセグメントには大きな違いが 1 つあります。 サーバーは、受信確認番号 (8221823) をクライアントに送信します。 受信確認は、ACK がクライアントによって開始された SYN に固有であることをクライアントに証明するだけです。 クライアントの要求を確認するプロセスにより、サーバーはクライアントのシーケンス番号を 1 ずつインクリメントし、それを受信確認番号として使用できます。
2 2.0786 BDC3 --> NTW3 TCP .A..S., len: 4, seq: 1109645-1109648, ack:
8221823, win: 8760, src: 139 (NBT Session) dst: 1037 BDC3 --> NTW3 IP
TCP: .A..S., len: 4, seq: 1109645-1109648, ack: 8221823, win: 8760,
src: 139 (NBT Session) dst: 1037
TCP: Source Port = NETBIOS Session Service
TCP: Destination Port = 0x040D
TCP: Sequence Number = 1109645 (0x10EE8D)
TCP: Acknowledgement Number = 8221823 (0x7D747F)
TCP: Data Offset = 24 (0x18)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x12 : .A..S.
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......1. = Synchronize sequence numbers
TCP: .......0 = No Fin
TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x012D
TCP: Urgent Pointer = 0 (0x0)
TCP: Options
TCP: Option Kind (Maximum Segment Size) = 2 (0x2)
TCP: Option Length = 4 (0x4)
TCP: Option Value = 1460 (0x5B4)
TCP: Frame Padding
00000: 02 60 8C 3B 85 C1 02 60 8C 9E 18 8B 08 00 45 00 .`.;...`......E.
00010: 00 2C 5B 00 40 00 80 06 93 4C 83 6B 02 D3 83 6B .,[.@....L.k...k
00020: 02 D6 00 8B 04 0D 00 10 EE 8D 00 7D 74 7F 60 12 ...........}t`.
00030: 22 38 01 2D 00 00 02 04 05 B4 20 20 "8.-......
フレーム 3:
3 番目のフレームでわかるように、クライアントは ACK セグメント (TCP .A....) を送信します。 このセグメントでは、クライアントはサーバーからの同期要求を認識しています。 クライアントは、受信確認番号を提供する際に実装されたのと同じアルゴリズムを使用します。 クライアントがサーバーの同期要求を受信確認すると、信頼性の高い接続と 3 方向ハンドシェイクを確立するプロセスが完了します。
3 2.787 NTW3 --> BDC3 TCP .A...., len: 0, seq: 8221823-8221823, ack:
1109646, win: 8760, src: 1037 dst: 139 (NBT Session) NTW3 --> BDC3 IP
TCP: .A...., len: 0, seq: 8221823-8221823, ack: 1109646, win: 8760,
src: 1037 dst: 139 (NBT Session)
TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 8221823 (0x7D747F)
TCP: Acknowledgement Number = 1109646 (0x10EE8E)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x10 : .A....
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = No Fin
TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x18EA
TCP: Urgent Pointer = 0 (0x0)
TCP: Frame Padding
00000: 02 60 8C 9E 18 8B 02 60 8C 3B 85 C1 08 00 45 00 .`.....`.;....E.
00010: 00 28 0E 01 40 00 80 06 E0 4F 83 6B 02 D6 83 6B .(..@....O.k...k
00020: 02 D3 04 0D 00 8B 00 7D 74 7F 00 10 EE 8E 50 10 .......}t....P.
00030: 22 38 18 EA 00 00 20 20 20 20 20 20 "8....
接続の終了
3 方向ハンドシェイクでは 3 つのパケットのみをネットワーク メディア経由で送信する必要がありますが、この信頼性の高い接続の終了は 4 つのパケットを送信する必要があります。 TCP 接続は全二重であるため (データは互いに独立して各方向に流れる可能性があります)、各方向は個別に終了する必要があります。
フレーム 4:
フレームのこのセッションでは、ACK (TCP .A...F) を伴う FIN を送信しているクライアントが表示されます。 このセグメントには、2 つの基本的な機能があります。 最初に、FIN パラメーターが設定されると、送信するデータがなくなったことをサーバーに通知します。 2 つ目は、ACK は、確立した特定の接続を識別する上で不可欠です。
4 16.0279 NTW3 --> BDC3 TCP .A...F, len: 0, seq: 8221823-8221823,
ack:3462835714, win: 8760, src: 2337 dst: 139 (NBT Session) NTW3 --> BDC3
IP
TCP: .A...F, len: 0, seq: 8221823-8221823, ack: 1109646, win: 8760, src:
1037 dst: 139 (NBT Session)
TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 8221823 (0x7D747F)
TCP: Acknowledgement Number = 1109646 (0x10EE8E)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x11 : .A...F
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......1 = No more data from sender
TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x236C
TCP: Urgent Pointer = 0 (0x0)
00000: 00 20 AF 47 93 58 00 A0 C9 22 F5 39 08 00 45 00 . .G.X...".9..E.
00010: 00 28 9B F5 40 00 80 06 21 4A C0 5E DE 7B C0 5E .(..@...!J.^.{.^
00020: DE 57 09 21 05 48 0B 20 96 AC CE 66 AE 02 50 11 .W.!.H. ...f..P.
00030: 22 38 23 6C 00 00 "8#l..
フレーム 5:
このフレームでは、クライアントから送信された FIN をサーバーが認識する以外に特別なものは表示されません。
5 16.0281 BDC3 --> NTW3 TCP .A...., len: 0, seq: 1109646-1109646,
ack: 8221824, win:28672, src: 139 dst: 2337 (NBT Session) BDC3 --> NTW3
IP
TCP: .A...., len: 0, seq: 1109646-1109646, ack: 8221824, win:28672, src:
139 dst: 2337 (NBT Session)
TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 1109646 (0x10EE8E)
TCP: Acknowledgement Number = 8221824 (0x7D7480)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x10 : .A....
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = No Fin
TCP: Window = 28672 (0x7000)
TCP: Checksum = 0xD5A3
TCP: Urgent Pointer = 0 (0x0)
TCP: Frame Padding
00000: 00 A0 C9 22 F5 39 08 00 02 03 BA 84 08 00 45 00 ...".9........E.
00010: 00 28 D2 82 00 00 3F 06 6B BD C0 5E DE 57 C0 5E .(....?.k..^.W.^
00020: DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 10 .{.H.!.f... ..P.
00030: 70 00 D5 A3 00 00 90 00 01 00 86 00 p...........
フレーム 6:
クライアント コンピューターから FIN を受信すると、サーバーは ACK を実行します。 TCP によって 2 台のコンピューター間の接続が確立されていても、接続は互いに独立しています。 そのため、サーバーは FIN (TCP .A...F) もクライアントに送信する必要があります。
6 17.0085 BDC3 --> NTW3 TCP .A...F, len: 0, seq: 1109646-1109646, ack:
8221824, win:28672, src: 139 dst: 2337 (NBT Session) BDC3 --> NTW3 IP
TCP: .A...F, len: 0, seq: 1109646-1109646, ack: 8221824, win:28672, src:
139 dst: 2337 (NBT Session)
TCP: Source Port = 0x0548
TCP: Destination Port = 0x0921
TCP: Sequence Number = 1109646 (0x10EE8E)
TCP: Acknowledgement Number = 8221824 (0x7D7480)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x11 : .A...F
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......1 = No more data from sender
TCP: Window = 28672 (0x7000)
TCP: Checksum = 0xD5A2
TCP: Urgent Pointer = 0 (0x0)
TCP: Frame Padding
00000: 00 A0 C9 22 F5 39 08 00 02 03 BA 84 08 00 45 00 ...".9........E.
00010: 00 28 D2 94 00 00 3F 06 6B AB C0 5E DE 57 C0 5E .(....?.k..^.W.^
00020: DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 11 .{.H.!.f... ..P.
00030: 70 00 D5 A2 00 00 02 04 05 B4 86 00 p...........
フレーム 7:
クライアントは、サーバーの FIN を ACK し、シーケンス番号を 1 ずつインクリメントすることで、サーバーと同じ形式で応答します。
7 17.0085 NTW3 --> BDC3 TCP .A...., len: 0, seq: 8221824-8221824, ack:
1109647, win: 8760, src: 2337 dst: 139 (NBT Session) NTW3 --> BDC3 IP
TCP: .A...., len: 0, seq: 8221824-8221824, ack: 1109647, win: 8760, src:
2337 dst: 139 (NBT Session)
TCP: Source Port = 0x0921
TCP: Destination Port = 0x0548
TCP: Sequence Number = 8221824 (0x7D7480)
TCP: Acknowledgement Number = 1109647 (0x10EE8F)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x10 : .A....
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = No Fin
TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x236B
TCP: Urgent Pointer = 0 (0x0)
00000: 00 20 AF 47 93 58 00 A0 C9 22 F5 39 08 00 45 00 . .G.X...".9..E.
00010: 00 28 BA F5 40 00 80 06 02 4A C0 5E DE 7B C0 5E .(..@....J.^.{.^
00020: DE 57 09 21 05 48 0B 20 96 AD CE 66 AE 03 50 10 .W.!.H. ...f..P.
00030: 22 38 23 6B 00 00 "8#k..
サーバーからの FIN 通知を ACK するクライアントは、TCP 接続の正常なクローズを識別します。
関連情報
RFC 793 を取得します。
RFC は、次のようにインターネット経由で取得できます。
すべての RFC の用紙コピーは、NIC から個別に、またはサブスクリプションベースで入手できます (詳細については、 にお問い合わせください NIC@NIC.DDN.MIL)。 オンライン コピーは、rfc/rfc####.txt または rfc/rfc####.PS として NIC.DDN.MIL から FTP または Kermit を介して使用できます (#### は先頭のゼロのない RFC 番号です)。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示