Red de computadoras (4) -Protocolo de capa de transporte-TCP y UDP

La capa de transporte se encuentra en la cuarta capa del protocolo de cinco capas. La capa de transporte proporciona servicios generales a la capa de aplicación superior. El propósito general significa que múltiples procesos de aplicación pueden utilizar el mismo protocolo de capa de transporte. La capa de transporte es responsable de proporcionar servicios generales de transmisión de datos para la comunicación entre dos hosts. La capa de transporte tiene las funciones de demultiplexación y multiplexación. Multiplexación significa que varias aplicaciones utilizan el mismo servicio de capa de transporte. Entregar información desde la capa de red a diferentes aplicaciones

Hay principalmente dos protocolos en la capa de transporte:

• TCP: Protocolo de control de transmisión, que proporciona un protocolo de transmisión de datos confiable y orientado a la conexión.
• UDP: Protocolo de datagramas de usuario, que proporciona un servicio de transmisión de datos sin conexión y con el mejor esfuerzo, pero no garantiza la confiabilidad.

Este artículo se centra en los dos protocolos UDP y TCP

Uno, UDP

El nombre completo de 用户数据包协议(User Datagram Protocol)UDP es , UDP proporciona una forma para que las aplicaciones envíen paquetes de datos IP encapsulados sin establecer una conexión. UDP solo agrega algunas funciones a los datagramas IP, a saber, demultiplexación, multiplexación y errores. La función de detección, aunque tiene errores detección, no tiene capacidad de recuperación ni mecanismo de retransmisión, por lo que no es confiable

1.1 Características de UDP

• UDP是无连接的, Es decir, no hay necesidad de establecer una conexión antes de enviar datos, y no hay liberación de conexión después de enviar datos, lo que reduce la sobrecarga de establecer y liberar la conexión.
• UDP尽最大努力交付，是没有连接状态的, Es decir, no se garantiza una entrega confiable, por lo que el host no necesita mantener un estado complejo
• UDP是面向报文的, UDP está orientado a mensajes, es decir, encapsula directamente los mensajes de la capa de aplicación, y la sobrecarga del encabezado del paquete es pequeña
• 速度快Según las características anteriores, la velocidad de UDP es muy rápida y el propósito es garantizar el tiempo real

Dos, TCP

Como protocolo de capa de transporte, TCP se considera más que UDP. TCP es un protocolo orientado a la conexión que proporciona una transmisión confiable, mientras que el TCP orientado a la conexión requiere tres apretones de manos y cuatro manos agitadas para confirmar y liberar la conexión. Para proporcionar una transmisión confiable, hay debe ser deslizante El mecanismo de la ventana está garantizado por el número de confirmación del número de serie, capaz de controlar el flujo y la congestión, etc.

2.1 Características de TCP

• TCP是面向连接的, Lo que significa que la conexión se establece y se libera cada vez que se comunica
• TCP提供可靠传输, Datos transmitidos a través de TCP, sin error, sin pérdida, sin duplicación
• TCP提供全双工通信, TCP permite que los procesos de aplicación de ambas partes se comuniquen en cualquier momento. Tanto el receptor como el remitente de TCP están configurados con un búfer para almacenar temporalmente los datos recibidos o enviados.
• 面向字节流Aunque los datos de la capa de aplicación son un bloque de datos, TCP solo trata estos datos como una serie de flujos de bytes no estructurados.

2.2 El primer formato de mensaje de TCP

TCP está orientado a bytes, pero los datos específicos enviados siguen siendo un segmento de mensaje, y la función de cada campo en el encabezado del segmento de mensaje refleja todas las funciones de TCP. A continuación, se presentan algunos de los segmentos de datos de mensaje más utilizados

• Puerto de origen y puerto de destino: el puerto de origen y el puerto de destino ocupan 2 bytes cada uno. Estos dos campos se utilizan para demultiplexar y multiplexar para marcar el número de puerto del proceso, que se puede empaquetar y desempaquetar al recibir o enviar

• Número de secuencia: el número de secuencia ocupa 4 bytes, que es un total de 2 ^ 32 números de secuencia. Cuando se agota el número de secuencia, puede numerarse desde 0. El flujo de bytes enviado en cada conexión TCP debe numerarse en secuencia. El flujo de bytes completo es El número de inicio debe determinarse cuando se establece la conexión

• Número de confirmación: El número de confirmación ocupa 4 bytes. Es el número de secuencia del primer byte de datos que se espera que reciba el siguiente segmento de mensaje de la otra parte. Es decir, si el número de confirmación es N, significa que los datos anteriores N-1 es todo recibo confirmado

• Reconocer ACK: el campo es válido solo cuando ACK = 1. TCP estipula que ACK = 1 debe establecerse después de que se establezca la conexión

• SYN síncrono: se utiliza para la sincronización cuando se establece la conexión. Cuando SYN = 1 y ACK = 0, indica que se trata de un segmento de solicitud de conexión. Si la otra parte acepta establecer una conexión, enviará SYN = 1 y ACK en el datagrama de respuesta. = 1

• Terminar FIN: se usa para liberar una conexión, cuando FIN = 1, indica que la conexión debe liberarse

• Ventana: ocupa 2 bytes y se refiere a la ventana de recepción del receptor. El valor de la ventana le dice al remitente: la cantidad máxima de datos que se pueden enviar esta vez, por lo que la ventana se utiliza como base para la ventana de envío del remitente

2.3 Principio del protocolo ARQ de transmisión confiable

自动重传请求(ARQ)Es un protocolo de corrección de errores para la capa de enlace de datos y la capa de transporte en el modelo OSI. A través de los dos mecanismos de confirmación y tiempo de espera, se puede realizar una transmisión de información confiable sobre la base de servicios no confiables. ARQ incluye ARQ de parada de espera y ARQ continuo protocolos

Deja de esperar el protocolo ARQ

1) Sin errores

Envíe y envíe el paquete de datos, el receptor lo recibe dentro del tiempo especificado, responde a la confirmación y envía y envía el siguiente paquete de datos nuevamente

2) Algo salió mal

Cuando B encuentra un error al recibir M1, B no notifica a A que ha recibido un mensaje de error.También es posible que M1 se pierda durante la transmisión y B no envíe ningún mensaje. Esto es ARQ estipula que mientras A no reciba el mensaje de confirmación de B dentro de un cierto período de tiempo, se requiere una retransmisión de tiempo de espera.

Para lograr la retransmisión de tiempo de espera, el remitente debe configurar un temporizador de retransmisión de tiempo de espera, y el tiempo del temporizador de retransmisión de tiempo de espera debe ser más largo que el tiempo de ida y vuelta del paquete de datos. El remitente también debe hacer una copia de seguridad de los paquetes enviados. para retransmitir, y cada paquete de datos debe estar numerado, para confirmar qué segmento no se envía correctamente

3) Confirmar perdido y confirmado tarde

• Confirmación perdida: el mensaje de confirmación se perdió durante la transmisión. Cuando A envía M1 a B, B recibe M1 y envía un mensaje de acuse de recibo, pero el mensaje de acuse de recibo se pierde durante la transmisión. Cuando expira el tiempo de espera del temporizador de retransmisión, A reenvía M1 y B debería recibirlo. Hacer: ①Recibir pero descartar M1 , no entregar a la capa superior ②Vuelva a enviar el mensaje de confirmación, no porque se haya enviado la confirmación de M1 no se enviará
• La confirmación llega tarde: el mensaje de confirmación se atasca en el proceso de transmisión. De manera similar, cuando A no recibe el mensaje de confirmación de B dentro del tiempo permitido por el temporizador de retransmisión de tiempo de espera, debe retransmitir a M1. Después de que el mismo B reciba Need to descarte M1 y vuelva a enviar el mensaje de confirmación, y A puede recibir el mensaje de confirmación atascado en este momento y luego descartarlo directamente

Protocolo ARQ continuo

El protocolo ARQ continuo puede proporcionar la utilización del canal, y el envío y el envío mantienen una ventana de envío de 5, por ejemplo, lo que significa que el remitente puede enviar 5 datagramas consecutivos a la vez sin esperar la confirmación de la otra parte. El receptor adopta el método de confirmación acumulativa, y solo necesita enviar la última secuencia de mensajes de confirmación, entonces el remitente piensa que el receptor ha recibido todos los mensajes antes del número de secuencia, como enviar y enviar un mensaje con un número de secuencia de 1-5, y el receptor solo necesita enviar un mensaje de reconocimiento con el número de secuencia 5, y el remitente cree que el receptor recibió correctamente el segmento 1-5

La ventaja de utilizar el método anterior es que la tasa de utilización del canal es alta y es fácil de realizar. La desventaja es que no puede reflejar al remitente toda la información del paquete que el receptor ha recibido correctamente. Por ejemplo, el remitente ha enviado 5 paquetes, y el receptor ha perdido el tercer paquete., Solo se pueden confirmar los dos primeros paquetes, y el remitente tiene que retransmitir los tres paquetes siguientes. Esto se llama Go-Back-N (back N)

2.4 Control de flujo y ventana deslizante

Para lograr una velocidad de transmisión rápida, se deben requerir los esfuerzos conjuntos del remitente y el receptor. Sin embargo, si el transmisor es demasiado rápido y el receptor llega demasiado tarde para recibir, se requiere control de flujo y el control de flujo se logra mediante ventanas deslizantes .Es el campo de ventana en el formato de mensaje. El campo de ventana en el mensaje de confirmación enviado por el receptor se puede utilizar para controlar el tamaño de la ventana del remitente, lo que afecta la velocidad de envío del remitente.

Únase al remitente y envíe un mensaje de reconocimiento con una ventana de 0 al receptor, que le dice al remitente que no se pueden enviar más datos. Aquí consideramos una situación. Si el búfer del receptor puede recibir nuevos datos después de un período de tiempo. El remitente envía un mensaje con un valor de ventana de rwnd = 100, pero este mensaje se pierde, lo que provoca que el remitente espere al receptor, provocando un fenómeno de interbloqueo. Para solucionar este problema, TCP para cada conexión es Siempre que el remitente reciba una notificación de ventana cero, el temporizador se iniciará. Cuando el temporizador expire, se enviará un mensaje de sonda. Luego, el receptor confirmará y dará el valor de la ventana actual. Causó un punto muerto

2.5 Control de congestión

El control de la congestión es para evitar que se inyecten datos excesivos en la red, de modo que los enrutadores o enlaces de la red no se sobrecarguen. El control de la congestión es un proceso global que involucra a todos los hosts, enrutadores, etc. Por el contrario, lo que debe hacer el control de flujo es el control de punto a punto, y lo que debe hacer el control de flujo es suprimir la velocidad de envío del remitente para que el receptor pueda venir y recibir

Para controlar la congestión, el remitente TCP mantiene una variable de ventana de la ventana de congestión (cwnd). El tamaño de la ventana de control de congestión depende del grado de congestión de la red y cambia dinámicamente. El remitente crea su propia ventana de envío, la ventana de congestión y el receptor. El más pequeño de la ventana de recepción

Hay cuatro algoritmos para el control de la congestión de TCP, inicio lento, prevención de congestión, recuperación rápida y retransmisión rápida, que se presentan a continuación junto con la siguiente figura

• Inicio lento: cuando el host comienza a enviar datos, no está claro el grado de congestión en la red. Si se inyecta una gran cantidad de datos en la red en este momento, puede causar congestión, por lo que se recomienda un algoritmo de inicio lento. adoptado, de pequeño a pequeño Aumentar en gran medida el tamaño del valor de la ventana. Y establezca un umbral de inicio lento ssthresh, y el valor de la ventana se duplicará después de cada ronda de propagación en la fase de inicio lento
• Evitación de la congestión: cuando el valor de la ventana actual alcanza el umbral de inicio lento, comience a utilizar el algoritmo para evitar la congestión. La idea del algoritmo para evitar la congestión es aumentar lentamente el valor de la ventana y aumentar en 1 después de cada ventana de tiempo RTT, que es aumentar de acuerdo con una ley lineal. Según la figura, cuando el valor de la ventana llega a 24, se produce una nueva situación y se ha agotado el tiempo de espera. En este momento, el remitente considera que hay congestión, por lo que el valor de la ventana actual cwnd = 1, el umbral de inicio completo ssthresh = 24/2 = 12, y se reinicia el inicio lento. Algoritmos y algoritmos de control de congestión
• Retransmisión rápida y recuperación rápida: el algoritmo de retransmisión rápida requiere que el receptor no lleve a cabo una confirmación piggyback, sino que confirme inmediatamente. Cuando el remitente recibe tres mensajes de confirmación seguidos, el remitente sabe que un determinado mensaje no se envía. la retransmisión rápida se utiliza inmediatamente para reenviar el paquete de datos perdido, y el algoritmo de recuperación rápida se realiza al mismo tiempo para cambiar la ventana actual cwnd a la mitad de la anterior.

El diagrama de flujo anterior es el siguiente:

2.6 Gestión de conexiones: protocolo de enlace de tres vías

Se ha mencionado muchas veces que TCP está orientado a la conexión, por lo que el establecimiento y la liberación de la conexión son necesarios. Hablemos del proceso de establecimiento de la conexión TCP.

En el ciclo de vida de un establecimiento de conexión TCP, hay un total de los siguientes estados:

• LISTEN: Esperando una conexión de cualquier TCP remoto
• SYN-SEND: Esperando una solicitud de conexión coincidente después de enviar una solicitud de conexión
• SYN-RECEIVED: Indica que se ha recibido la solicitud de conexión y está esperando la confirmación de conexión, que es el estado del segundo protocolo de enlace
• ESTAB-LISHED: Indica que la conexión se ha creado correctamente y los datos se pueden transferir

La figura anterior es un diagrama esquemático de una conexión de protocolo de enlace de tres vías. TCP estipula que cuando un cliente inicia una solicitud de conexión, no puede enviar datos pero consume un número de serie. Analicemos el proceso anterior:

1. El cliente envía activamente una solicitud de conexión al servidor. El encabezado de la solicitud es SYN = 1 en la misma parte, y se selecciona un número de secuencia inicial seq. El segmento SYN no puede transportar datos y solo consume un número de secuencia. En este momento, el cliente ingresa al SYN-SENDestado

2. Una vez que el servidor recibe la solicitud del cliente para iniciar una conexión, debe confirmar el mensaje del cliente. En el segmento del mensaje de confirmación, es necesario configurar SYN y ACK. Al mismo tiempo, envía un número de confirmación y también elige una inicial número de secuencia para sí mismo. El segmento de texto tampoco puede transportar datos, necesita consumir un número de serie y el servidor ingresa al mismo tiempoSYN-RECEIVED

3. Una vez que el cliente recibe el mensaje de confirmación, también debe dar un mensaje de conexión de confirmación. El mensaje de conexión de confirmación encuentra el ACK = 1 y el número de secuencia es x + 1. Este mensaje puede transportar datos y el cliente ingresaESTAB-LISHED

4. El servidor también entra después de recibir el mensaje de confirmaciónESTAB-LISHED

Analice nuevamente el proceso del protocolo de enlace de tres vías. De hecho, el proceso de establecer una solicitud de conexión es para que la otra parte sepa su estado primero, es decir, para asegurarse de que el envío y la recepción de la otra parte sean normales:

• El primer apretón de manos: el cliente no puede confirmar nada, el servidor confirma: la otra parte envía normalmente y el receptor es normal
• El segundo apretón de manos: el cliente confirma: la recepción y el envío son normales, el otro envío y la recepción también son normales, el servidor confirma: el otro envío es normal y la recepción es normal
• El tercer apretón de manos: el cliente confirma: la recepción y el envío son normales, el otro envío y la recepción también son normales, el servidor confirma: la recepción y el envío son normales, el otro envío y la recepción también son normales

Entonces se necesitan tres apretones de manos, y uno es indispensable

¿Por qué devolver SYN y ACK?

El SYN se envía de vuelta en el segundo apretón de manos. El propósito es decirle al cliente que el mensaje que recibí es efectivamente el mensaje que usted envió y no otra persona. La corrección de las partes de la comunicación debe ser que los mensajes enviados entre sí sean correctos, por lo que el propósito de devolver ACK es también probar que el canal entre los dos es correcto.

2.7 Gestión de conexiones: cuatro ondas

Existen los siguientes estados en el ciclo de vida de cierre de una conexión TCP:

• FIN-WAIT-1: Significa esperar la solicitud de terminación de la conexión del TCP remoto o esperar la solicitud de terminación de la conexión enviada previamente
• FIN-WAIT-2: Representa la espera de la solicitud de terminación de la conexión desde TCP remoto.
• CLOSE-WAIT: Indica la espera de la solicitud de terminación de la conexión del usuario local.
• CLOSING: Representa la espera de la confirmación de la solicitud de terminación de la conexión del TCP remoto.
• LAST-ACK: Indica que está esperando la confirmación de la solicitud de terminación de la conexión enviada previamente al TCP remoto.
• TIME-WAIT: Significa esperar el tiempo suficiente para asegurarse de que el TCP remoto reciba su solicitud de confirmación de finalización de la conexión.
• CLOSE: Indica que la conexión se ha cerrado, no hay estado de conexión

1. La aplicación cliente envía un segmento de mensaje de solicitud para liberar la conexión y cierra activamente la conexión. El encabezado del segmento de mensaje FIN = 1, no contiene datos, donde seq = u, y el cliente ingresaFIN-WAIT-1
2. Una vez que el servidor recibe el mensaje de liberación de conexión del cliente, envía un mensaje de respuesta de acuse de recibo, donde ACK = 1, genera su propio número de serie y, a continuación, el host del servidor ingresaCLOSE-WAIT
3. Una vez que el cliente recibe el mensaje de confirmación del servidor, ingresa al FIN-WAIT-2estado y espera a que el servidor envíe un segmento de mensaje para liberar la conexión.En este momento, la conexión del cliente al servidor se ha liberado.
4. Cuando el host del servidor no tiene datos para enviar, el host del servidor envía un segmento de solicitud de desconexión donde ACK = 1, FIN = 1, donde seq no es necesariamente v porque los datos pueden enviarse en el medio. Después de enviar la solicitud, el servidor DentroLAST-ACK
5. Después de que el cliente recibe la solicitud de desconexión de conexión enviada por el servidor, el cliente debe dar una respuesta y luego ingresar al TIME-WAITestado. En este momento, la conexión no se ha cerrado y el cliente ingresará después de que haya pasado el tiempo 2MSL.CLOSE

El motivo de la necesidad de saludar cuatro veces es que cualquiera de las partes puede enviar una solicitud para liberar la conexión una vez finalizada la transmisión de datos. Cuando la otra parte confirma, entra en el estado semicerrado. Cuando la otra parte no tiene datos enviar, la solicitud de liberación de conexión se emite de nuevo. Por lo tanto, es necesario cuatro veces

El cliente necesita dar una respuesta y luego ingresar al TIME-WAITestado, en este momento no se ha cerrado la conexión, el cliente ingresará luego de transcurrido el tiempo 2MSL.CLOSE

El motivo de la necesidad de saludar cuatro veces es que cualquiera de las partes puede enviar una solicitud para liberar la conexión una vez finalizada la transmisión de datos. Cuando la otra parte confirma, entra en el estado semicerrado. Cuando la otra parte no tiene datos enviar, la solicitud de liberación de conexión se emite de nuevo. Por lo tanto, es necesario cuatro veces

La razón por la que el cliente necesita esperar 2MSL arriba es: ①Para asegurar que la última respuesta pueda llegar al servidor, ②para evitar segmentos de mensajes no válidos, después de esperar el tiempo de 2MSL, puede garantizar que todos los segmentos de mensaje dentro de la duración de esta conexión es de la red desaparece