IP reference

Referencia Técnica de Redes, Protocolos, Modelo OSI, TCP/IP, y otras tecnologías.

Three-way handshake

Posted by Luis R. en 2009/03/30

del artículo de Microsoft:
Explanation of the Three-Way Handshake via TCP/IP

El nivel del protocolo de transporte comprendido en TCP (transport control protocol) es orientado a conexión; lo que significa que antes de poder transmitir datos, se debe obtener una conexión confiable y reconocida (con acknowledge). Las transmisiones de datos a nivel TCP, los establecimientos de conexión y terminación de conexión, mantienen parámetros específicos de control que gobiernan el proceso completo. Los bits de control son:

  • URG: Urgent Pointer field significant
  • ACK: Acknowledgement field significant
  • PSH: Push Function
  • RST: Reset the connection
  • SYN: Synchronize sequence numbers
  • FIN: No more data from sender

Hay dos escenarios donde un proceso de three-way handshake tendrá lugar:

  • Estableciendo una conexión (apertura activa)
  • Terminando una conexión (cierre activo)

La información de muestra fue obtenida de un captura de un Monitor de red (analizador de protocolos que puede obtenerse de un Microsoft Systems Management Server).

Estableciendo una conexión

La siguiente secuencia muestra el proceso de una conexión de TCP siendo establecida:

Frame1:

Como podemos ver en el primer frame, el cliente NTW3 envía un segmento SYN (TCP…S); esto es una petición al servidor para sincronizar los números de secuencia. Especifica el número de secuencia inicial (ISN) que se incrementa por 1 (8221821+1=8221822) y es enviado al servidor. Para iniciar una conexión, el cliente y el servidor deben sincronizar sus respectivos números de secuencia. También hay una opción para el tamaño máximo de segmento (MSS) que debe acordarse, y se define en la longitud (length, len: 4). Esta opción comunica el tamaño máximo de segmento que el transmisor quiere recibir. El campo de reconocimiento o acuse de recibo (acknowledge, ack: 0) se fija en cero porque es la primera parte del proceso de three-way handshake.

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                .........


Frame 2:

En el segundo frame, el servidor BDC3 envía un ACK y un SYN en este segmento (TCP .A..S.) En este segmento el servidor está acusando de recibida la petición del cliente para sincronizar. Al mismo tiempo, el servidor también envía su petición al cliente para sincronizar sus números de secuencia. Hay una diferencia importante en este segmento. El servidor transmite un número de acuse (acknowledgement number 8221823) al cliente. El acknowledgement es sólo la prueba para que el cliente sepa que el ACK es la respuesta al SYN que el cliente inició. El proceso de acuse de recibo que el cliente requirió permite al servidor incrementar el número de secuencia del cliente por uno y lo usa como su número de acknowledgement.

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.-......

Frame 3:
En el tercer frame, el cliente envía un ACK en el segmento (TCP .A….) y el cliente está confirmando la petición del servidor para sincronizar. El cliente usa el mismo algoritmo que el servidor implementó para dar un número de confirmación. La confirmación del cliente está completando el proceso de establecer una conexión confiable, a través del Three-Way Handshake.

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....


Terminando una conexión

Aunque el proceso three-way handshake solo requiere 3 paquetes para ser transmitido sobre nuestro medio de red, la terminación de esta conexión confiable necesitará la transmisión de 4 paquetes. Debido a que una conexión TCP es Full Duplex (fluye información en cada dirección de manera independiente de la otra) cada dirección debe ser terminada de manera independiente.

Frame 4
En esta sesión de frames, podemos ver alcliente enviando un FIN que es acompañado por un ACK (TCP.A…F) Este segmento tiene dos funciones básicas; primero, cuando el parámetro FIN es fijado, informará al servidor que no hay más datos que enviar; segundo, el ACK es esencial para identificar la conexión específica que ellos establecieron.

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..

Frame 5:
Aquí no se ve nada especial, excepto el servidor confirmando el FIN que envió el cliente.

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...........

Frame 6
Después de recibir el paquete FIN desde el cliente, el servidor confirmará. Aún cuando TCP ha establecido conexiones entre esas dos computadoras, las conexiones son aún independientes una de otra; así que el servidor debe transmitir también un paquete FIN (TCP .A…F) al cliente.

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...........

Frame 7
El cliente responde en la misma manera que el servidor, confirmando el paquete de FIN que recibió e incrementando el número de secuencia por 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..

El cliente confirmando la notificación de FIN del servidor identifica el cierre de una conexión de TCP.

Para mayor información, referirse al RFC793, el cual describe a fondo el proceso estandarizado de establecimiento de conexión de TCP.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: