Resumen de TCP y UDP

Articulo de referencia

35 ilustraciones: Protocolo de enlace de tres vías de TCP y cuatro manos agitadas que se han preguntado miles de veces. Las preguntas de la entrevista son
fáciles de entender y explican el mecanismo de control de flujo de TCP, y aprenden sobre
el control de congestión de TCP (explicación detallada)

Que es TCP

TCP es un protocolo de comunicación de capa de transporte basado en flujo de bytes, ordenado, confiable y orientado a la conexión .

1. Orientado a la conexión: debe ser "uno a uno" para conectarse. No puede ser como el protocolo UDP que un host puede enviar mensajes a varios hosts al mismo tiempo, es decir, uno a varios no es posible ;
2. Confiable: no importa qué tipo de cambios de enlace se produzcan en el enlace de red, TCP puede garantizar que un mensaje llegue al extremo receptor;
3. Flujo de bytes: los mensajes "no tienen límites", por lo que no importa cuán grandes sean nuestros mensajes, pueden transmitirse. Y el mensaje está " ordenado ". Cuando no se recibe el mensaje "anterior", incluso si recibe el siguiente byte primero, no se puede lanzar a la capa de aplicación para su procesamiento. Al mismo tiempo, el mensaje "duplicado" será procesados ​​y descartados automáticamente.

¿Por qué necesitamos el protocolo TCP? ¿En qué capa funciona TCP?

El protocolo IP en la capa de red no es "confiable" y no garantiza la integridad de los datos. Si necesita garantizar la confiabilidad de los paquetes de datos de red, entonces el protocolo TCP de la capa superior (capa de transporte) es responsable.

Comprensión básica de TCP

TCP proporciona servicios de dúplex completo para la capa de aplicación, lo que significa que los datos se pueden transmitir de forma independiente en dos direcciones.

TCP se comunicará tres veces antes de la transmisión, lo que generalmente se conoce como "protocolo de enlace de tres vías". Cuando los datos se desconectan, debe comunicarse cuatro veces, lo que generalmente se conoce como "cuatro ondas de manos".

1. Número de puerto de origen (16 bits): (junto con la dirección IP del host de origen) identifica un proceso de aplicación del host de origen

2. Número de puerto de destino (16 bits): (junto con la dirección IP del host de destino) identifica un proceso de aplicación del host de destino

3. Sequence number seq (32 bits): el número aleatorio generado por la computadora cuando se establece la conexión se usa como su valor inicial y se transmite al host receptor a través de un paquete SYN. ​​Cada vez que se envían datos, el "número de bytes de datos "es" tamaño acumulado ". Se utiliza para resolver el problema del desorden de paquetes de red .

4. Número de acuse de recibo ack (32 bits): Se refiere al número de serie de los datos recibidos a continuación "esperados". Por lo tanto, el número de secuencia de confirmación debe ser el número de secuencia de bytes de los últimos datos recibidos con éxito más 1. El campo del número de secuencia de confirmación es válido solo cuando el indicador ACK es 1. Una vez que el remitente recibe esta respuesta de confirmación, se puede considerar que los datos anteriores a este número de secuencia se han recibido normalmente. Se utiliza para resolver el problema de no pérdida de paquetes .

5. Longitud del encabezado (4 bits): la longitud del campo opcional es variable, por lo que este valor es necesario para indicar la longitud total del encabezado, que es conveniente para obtener datos (dónde comienzan los datos). Este campo ocupa 4 bits, por lo que TCP tiene un encabezado de 60 bytes como máximo. Sin embargo, no hay un campo opcional y la longitud normal es de 20 bytes.

6. Bits reservados (6 bits): reservados para uso futuro, deben establecerse en

7. Bit de control:

   SYN: número de secuencia de sincronización, 1 significa solicitud de conexión, utilizado para establecer una conexión y sincronizar el número de secuencia (sincronizar)
   ACK: 1 significa que el número de confirmación es válido, 0 significa que el mensaje no contiene información de confirmación y el campo del número de confirmación es ignorado.
   FIN: Usado para liberar la conexión, 1 significa que el remitente no tiene datos para enviar, es decir, cierra el flujo de datos de la parte local.

8. Tamaño de la ventana (16 bits): número de bytes de datos

9. Suma de comprobación (16 bits): esta suma de comprobación se calcula en palabras de 16 bits para todo el segmento del mensaje TCP, incluido el encabezado TCP y los datos TCP. Se utiliza para la verificación de la seguridad de los datos en el extremo receptor.

10. Datos: los datos específicos son opcionales. Cuando se establece una conexión y se termina una conexión, el segmento de mensaje intercambiado por ambas partes solo tiene el encabezado TCP. Si una de las partes no tiene datos para enviar, el encabezado sin datos también se utiliza para confirmar los datos recibidos. En muchos casos de tiempos de espera de procesamiento, también se enviarán segmentos sin ningún dato.

Cómo determinar de forma única una conexión TCP

La dirección de origen + el puerto de origen y la dirección de destino + el puerto de destino pueden determinar de forma única una conexión

Los campos de dirección de origen y dirección de destino (32 bits) están en el encabezado IP, y la función es enviar mensajes al host opuesto a través del protocolo IP.

Los campos del puerto de origen y del puerto de destino (16 bits) están en el encabezado TCP, que le indica al protocolo TCP a qué proceso se debe enviar el mensaje.

Protocolo de enlace de tres vías TCP

1. El primer apretón de manos: el host A envía un código de bits de syn = 1 y genera aleatoriamente un paquete de datos con el número de secuencia = 1234567. El host B lo
   sabe por SYN = 1 y A solicita establecer una conexión;
2. El segundo protocolo de enlace: el host B necesita confirmar la información de conexión después de recibir la solicitud y enviar el número de confirmación = (seq + 1 del host A), syn = 1, ack = 1, generar aleatoriamente el paquete seq = 7654321
3. El tercer apretón de manos: el host A comprueba si el número de confirmación es correcto después de recibirlo, es decir, el primer número de secuencia enviado + 1, y el código de bit ack es 1, si es correcto, el host A enviará otro número de confirmación = ( Seq + 1 del host B), ack = 1, el host B confirma el valor de seq y ack = 1 después de recibirlo, la conexión se establece con éxito.

¿Por qué el número de serie inicial ISN del cliente y del servidor es diferente?

1. Si se reutiliza una conexión fallida, pero el mensaje histórico de la conexión anterior aún permanece en la red, si el número de secuencia es el mismo, entonces es imposible saber si el mensaje es un mensaje histórico o no. Si el mensaje histórico es nuevo Si se recibe la conexión, los datos se corromperán. Por lo tanto, reinicializar un número de secuencia cada vez antes de establecer una conexión es principalmente para que las dos partes en comunicación descarten los segmentos que no pertenecen a la conexión según el número de secuencia.
2. Por otro lado, por seguridad, para evitar que los piratas informáticos falsifiquen paquetes TCP con el mismo número de serie y los reciba la otra parte.

¿Por qué TCP es un protocolo de enlace de tres vías? No dos o cuatro veces

Razón 1 : El protocolo de enlace de tres vías puede garantizar que ambas partes tengan la capacidad de recibir y enviar.

TCP proporciona servicios de dúplex completo para la capa de aplicación, lo que significa que los datos se pueden transmitir de forma independiente en dos direcciones. Ambas partes deben confirmar que la otra parte tiene la capacidad de recibir y enviar.

Razón 2 : Evite las conexiones históricas

El entorno de red es intrincado y complicado. A menudo no es el esperado. El paquete de datos enviado primero llega primero al host de destino. Por el contrario, es muy desordenado. Puede ser desordenado debido a la congestión de la red y otras razones, que haga primero los paquetes de datos antiguos. Para llegar al host de destino, ¿cómo evitar el protocolo de enlace de tres vías de TCP en este caso?

Si se trata de una conexión de apretón de manos de dos vías, es imposible determinar si la conexión actual es una conexión histórica. Para un apretón de manos de tres vías, cuando el cliente (remitente) está a punto de enviar el tercer mensaje, el cliente tiene suficiente contexto para determinar si la conexión actual es una conexión histórica:

1. Si se trata de una conexión histórica (el número de serie expiró o se agotó el tiempo de espera), el mensaje enviado en el tercer protocolo de enlace es un mensaje RST para terminar la conexión histórica;
2. Si no es una conexión histórica, el mensaje enviado por tercera vez es un mensaje ACK y las partes de la comunicación establecerán una conexión con éxito;

Razón 3 : sincronizar los números de serie iniciales de ambas partes

Ambas partes de la comunicación del protocolo TCP deben mantener un "número de serie". El número de serie es un factor clave para una transmisión confiable. Su función:

1. El receptor puede eliminar datos duplicados;
2. El receptor puede recibir en orden según el número de secuencia del paquete de datos;
3. Puede identificar cuál de los paquetes de datos enviados ha sido recibido por la otra parte;

Se puede ver que el número de secuencia ocupa un papel muy importante en la conexión TCP, por lo que cuando el cliente envía un mensaje SYN con el "número de secuencia inicial", el servidor debe devolver un mensaje de respuesta ACK, indicando que el mensaje SYN del cliente Después de ser recibido con éxito por el servidor, cuando el servidor envía el "número de serie inicial" al cliente, todavía tiene que obtener la respuesta del cliente. De esta manera, los números de serie iniciales de ambas partes se pueden sincronizar de forma fiable.

El protocolo de enlace de cuatro vías puede sincronizar los números de secuencia de inicialización de ambas partes de forma fiable, pero dado que el segundo y el tercer paso se pueden optimizar en un solo paso, se convierte en un "protocolo de enlace de tres vías".

El apretón de manos solo garantiza que el número de serie inicial de una de las partes pueda ser recibido con éxito por la otra parte, y no hay forma de garantizar que el número de serie inicial de ambas partes se pueda confirmar y recibir.

resumen

Cuando TCP establece una conexión, el protocolo de enlace de tres vías puede garantizar que ambas partes tengan la capacidad de recibir y enviar, evitar el establecimiento de conexiones históricas y ayudar a ambas partes a sincronizar el número de secuencia de inicialización.

El número de secuencia puede garantizar que los paquetes de datos no se repitan, descarten y transmitan en orden.

Razones para no utilizar el "apretón de manos de dos":

1. Es imposible garantizar que ambas partes tengan la capacidad de recibir y enviar, evitar el establecimiento de conexiones históricas y sincronizar de manera confiable los números de serie de ambas partes;

Razones para no utilizar el "apretón de manos de cuatro vías":

1. El protocolo de enlace de tres vías es teóricamente el establecimiento de conexión menos confiable, por lo que no es necesario utilizar más tiempos de comunicación.

Comprensión básica de UDP

UDP no proporciona un mecanismo de control complicado y utiliza IP para proporcionar un servicio de comunicación "sin conexión".

El protocolo UDP es realmente simple, el encabezado tiene solo 8 bytes (64 bits) y el formato del encabezado UDP es el siguiente:

1. Puertos de destino y origen: principalmente para indicarle al protocolo UDP a qué proceso debe enviarse el mensaje.
2. Longitud del paquete: este campo almacena la suma de la longitud del encabezado UDP y la longitud de los datos.
3. Checksum: Checksum está diseñado para proporcionar encabezados y datos UDP confiables.

La diferencia entre TCP y UDP

1. conexión

   TCP es un protocolo de capa de transporte orientado a la conexión y se debe establecer una conexión antes de la transmisión de datos.
   UDP no necesita estar conectado y transmite datos inmediatamente.

2. Objeto de servicio

   TCP es un servicio de dos puntos uno a uno, es decir, una conexión tiene solo dos puntos finales.
   UDP admite comunicación interactiva uno a uno, uno a muchos y muchos a muchos

3. fiabilidad

   TCP entrega datos de manera confiable y los datos pueden llegar en secuencia sin errores, pérdida, repetición y orden.
   UDP es una entrega de mejor esfuerzo y no garantiza una entrega confiable de datos.

4. Control de congestión, control de flujo

   TCP tiene mecanismos de control de flujo y control de congestión para garantizar la seguridad de la transmisión de datos.
   UDP no. Incluso si la red está muy congestionada, no afectará la velocidad de envío de UDP.

5. Cabeza arriba

   La longitud del encabezado TCP es más larga y habrá una cierta cantidad de sobrecarga. El encabezado es de 20 bytes cuando no se usa el campo "opción", y será más largo si se usa el campo "opción".
   El encabezado UDP tiene solo 8 bytes, es fijo y la sobrecarga es pequeña.

6. método de transferencia

   TCP es streaming, sin fronteras, pero garantiza orden y fiabilidad.
   UDP es una transmisión de paquete por paquete. Hay límites, pero puede ocurrir pérdida de paquetes y desorden.

7. Los fragmentos son diferentes (no muy comprensivos)

   Si el tamaño de los datos de TCP es mayor que el tamaño de MSS, se fragmentará en la capa de transporte. Una vez que el host de destino los reciba, también ensamblará los paquetes de TCP en la capa de transporte. Si un fragmento se pierde en el medio, solo el el fragmento faltante necesita ser transmitido.

   Si el tamaño de los datos UDP es mayor que el tamaño de la MTU, se fragmentará en la capa IP. Una vez que el host de destino los reciba, reunirá los datos en la capa IP y luego los transmitirá a la capa de transporte. Sin embargo, si un El fragmento se pierde a la mitad, será necesario Retransmitir todos los paquetes de datos, por lo que la eficiencia de transmisión es muy baja, por lo que generalmente los paquetes UDP deben ser más pequeños que MTU.

¿Por qué el encabezado UDP no tiene un campo de "longitud de encabezado", pero el encabezado TCP tiene un campo de "longitud de encabezado"?

La razón es que TCP tiene un campo de "opción" de longitud variable, mientras que la longitud del encabezado UDP no cambia y no hay necesidad de un campo más para registrar la longitud del encabezado UDP.

Se perdió la conexión TCP

La desconexión de TCP tarda cuatro veces. Esto se debe a la mitad del cierre de TCP. Debido a que la conexión TCP es full-duplex (es decir, los datos se pueden transmitir en ambas direcciones al mismo tiempo), cada dirección debe cerrarse por separado cuando está cerrada. Este cierre unidireccional se denomina semicerrado. Cuando una de las partes completa su tarea de envío de datos, envía un FIN para notificar a la otra parte que
la conexión en esta dirección terminará . La parte que se apaga primero ejecutará el apagado activo y la otra parte ejecutará el apagado pasivo.

1. Cierre la conexión del cliente al servidor: Primero, el cliente A envía un FIN para cerrar la transmisión de datos del cliente al servidor, y luego espera la confirmación del servidor. El indicador de terminación bit FIN = 1, el número de secuencia seq = u
2. Cuando el servidor recibe este FIN, envía un ACK con el número de acuse de recibo más 1 para el número de secuencia recibido. El cliente A recibe el acuse de recibo para verificar si es correcto (u + 1) y cerrar la conexión correctamente.
3. Cerrar la conexión del servidor al cliente: también envía un FIN al cliente.
4. Después de recibir el FIN, el segmento de cliente envía una confirmación de mensaje ACK y establece el número de secuencia de confirmación seq al número de secuencia recibido más 1.
   
   Una vez que el host A envía el FIN, entra en el estado de espera de terminación. Después de que el servidor B recibe el segmento del mensaje de liberación de conexión del host A, envía inmediatamente un acuse de recibo al host A y, a continuación, el servidor B entra en el estado de espera cerrada. En este momento , el proceso del servidor TCP informa a la capa superior El proceso de aplicación y, por lo tanto, la conexión de A a B se libera. En este momento, está "medio cerrado". Es decir, A no se puede enviar a
   B, pero B se puede enviar a A.

En este momento, si B no tiene ningún datagrama para enviar a A, su proceso de aplicación notificará a TCP que libere la conexión, y luego lo enviará al segmento de liberación de conexión A, y esperará la confirmación. Después de que A envía la confirmación, entra en tiempo de espera.Tenga en cuenta que la conexión TCP no se ha liberado en este momento y luego espera el 2MSL establecido por el temporizador antes de que A entre en el estado cerrado.

¿Por qué TCP necesita saludar cuatro veces?

Se puede ver en el proceso anterior que el servidor generalmente necesita esperar a que se complete la transmisión y el procesamiento de datos, por lo que el ACK y FIN del servidor generalmente se envían por separado, que es una vez más que el protocolo de enlace de tres vías.

Por qué el tiempo de espera TIME_WAIT es 2MSL

MSL es la duración máxima del segmento y el tiempo máximo de supervivencia de un mensaje> = el tiempo de propagación de una transmisión de datos.

Si la parte de cierre pasiva no recibe el último mensaje ACK de la desconexión, activará una retransmisión de tiempo de espera del mensaje Fin. Después de que la otra parte reciba el FIN, volverá a enviar un ACK a la parte de cierre pasiva.
Hay exactamente 2 MSL dentro y fuera.

El tiempo de 2MSL comienza cuando el cliente envía ACK después de recibir FIN. Si dentro del tiempo de TIEMPO DE ESPERA, porque el ACK del cliente no ha sido transmitido al servidor, y el cliente recibe el mensaje FIN retransmitido por el servidor, el tiempo 2MSL se contará nuevamente.

Flujo de control de TCP

Fenómeno: cuando la velocidad a la que el originador envía datos es mayor que la velocidad a la que el receptor procesa los datos, el receptor no procesa los datos a tiempo y el espacio del búfer de datos del receptor se llenará con el tiempo. En este momento, el remitente aún envía datos y el receptor los perderá, lo que provocará un desperdicio de recursos de red.

el término:

接收窗口：接收方的缓存区的剩余空间；
发送窗口：发送方的发送数据大小；

Solución: el receptor volverá a su propio tamaño de ventana de recepción cada vez que reciba datos, y el remitente ajustará la ventana de envío de acuerdo con el tamaño de la ventana de recepción para mantener el equilibrio entre la recepción y el envío.

Consulte el artículo detallado, explicación fácil de entender, mecanismo de control de flujo de TCP, para averiguarlo

Control de congestión TCP

Fenómeno: La demanda de un determinado recurso en la red supera la parte disponible que el recurso puede proporcionar y el rendimiento de la red se deteriorará, situación que se denomina congestión de la red. El ancho de banda, los búferes y los procesadores en los nodos de conmutación son todos recursos de la red. Si la congestión ocurre sin control, el rendimiento de toda la red disminuirá a medida que aumenta la carga de entrada.

el término:

拥塞窗口（cwnd/swnd）：发送方发送报文的数量。不是固定值，初始1，没有发生拥塞前cwnd变大，发生拥塞后cwnd变小。
慢开始门限（ssthresh）：一个状态变量，用于控制 拥塞窗口 增值的阈值
	cwnd < ssthresh ：使用 慢开始 增长cwnd 的值
	cwnd > ssthresh ： 改用 拥塞控制 增长cwnd 的值
	cwnd = ssthresh ：慢开始/拥塞控制 增长cwnd 的值
慢开始：每个传输轮次，按指数（乘2）增长 cwnd 的值。
拥塞控制：每个传输轮次，按线性（加1）增长 cwnd 的值。
快重传：尽快的重传（连续收到3个重复确认），不用等到超时重传。
快恢复：发送拥塞后cwnd 不是变成1，而是 = 拥塞值/2 向下取整。

Solución: cuando el

remitente comienza a generar datos, es 1 mensaje. Después de recibir el mensaje de confirmación, no hay problema con la verificación. Después de cada ronda de transmisión, la ventana de congestión aumenta rápidamente por el ** algoritmo de inicio lento (multiplicado por 2) . Cuando se alcanza el umbral de inicio lento, la ventana de congestión aumenta lentamente de acuerdo con el algoritmo para evitar la congestión (más uno) **. Si se produce una congestión (tiempo de espera de retransmisión), se denomina algoritmo de recuperación rápida que ajusta la ventana de congestión y el valor de congestión del umbral de inicio lento = / 2 redondeado hacia abajo, entonces se producen los datos.