TCP es uno de los principales protocolos de Internet. Este artículo presenta sus conocimientos básicos.
1. El papel del protocolo TCP
Internet consiste en un conjunto de acuerdos. TCP es solo una de estas capas, con su propia división del trabajo.
(Descripción de la imagen: TCP es el protocolo de capa superior del protocolo Ethernet y el protocolo IP, y también el protocolo de capa inferior del protocolo de capa de aplicación.) El protocolo Ethernet de capa inferior (Ethernet) especifica cómo las señales electrónicas forman paquetes y resuelve la subred Comunicación interna punto a punto.
(Descripción de la imagen: El protocolo Ethernet resuelve la comunicación punto a punto de la red de área local.) Sin embargo, el protocolo Ethernet no puede resolver cómo se comunican varias LAN entre sí. Esto se resuelve mediante el protocolo IP.
(Descripción de la imagen: el protocolo IP puede conectar varias LAN). El protocolo IP define un conjunto de sus propias reglas de dirección, llamadas direcciones IP. Implementa la función de enrutamiento, permitiendo que el host A de una red de área local envíe mensajes al host B de otra red de área local.
(Descripción de la imagen: el enrutador se basa en el protocolo IP. Las LAN están conectadas por enrutadores). El principio de enrutamiento es simple. Todos los enrutadores en el mercado tienen muchos puertos de red detrás de ellos y se deben conectar varios cables de red. Hay una tabla de enrutamiento dentro del enrutador, que estipula que la dirección IP del segmento A sale para salir uno, y la dirección del segmento B sale para salir dos ... A través de este conjunto de "señales de guía", se envían los paquetes de datos.
(Descripción de la imagen: la tabla de enrutamiento de esta máquina indica la interfaz a la que se envían los paquetes de datos de diferentes destinos IP). El protocolo IP es solo un protocolo de dirección y no garantiza la integridad del paquete de datos. Si el enrutador pierde paquetes (por ejemplo, el búfer está lleno, se perderán los nuevos paquetes entrantes), debe encontrar qué paquete se perdió y cómo reenviarlo. Esto depende del protocolo TCP. En pocas palabras, la función del protocolo TCP es garantizar la integridad y fiabilidad de la comunicación de datos y evitar la pérdida de paquetes.
Segundo, el tamaño del paquete TCP
El tamaño del paquete de Ethernet (paquete) es fijo, inicialmente de 1518 bytes, y luego aumentado a 1522 bytes. Entre ellos, 1500 bytes son la carga útil y 22 bytes son la información principal. El paquete de datos IP está en la carga útil del paquete de datos Ethernet. También tiene su propia información de encabezado, que requiere al menos 20 bytes, por lo que la carga del paquete de datos IP es como máximo 1480 bytes.
(Descripción de la imagen: los paquetes IP están en paquetes Ethernet y los paquetes TCP están en paquetes IP). Los paquetes TCP están en la carga útil de los paquetes IP. Requiere al menos 20 bytes de información de encabezado, por lo que la carga máxima de paquetes TCP es 1480-20 = 1460 bytes. Dado que los protocolos IP y TCP a menudo tienen información de encabezado adicional, la carga TCP es en realidad alrededor de 1400 bytes. Por lo tanto, un mensaje de 1500 bytes requiere dos paquetes TCP. Una mejora importante del protocolo HTTP / 2 es comprimir la información del encabezado del protocolo HTTP, de modo que una solicitud HTTP se pueda colocar en un paquete TCP en lugar de dividirse en múltiples, lo que aumenta la velocidad.
(Descripción de la imagen: la carga de los paquetes de datos Ethernet es de 1500 bytes, y la carga de los paquetes de datos TCP es de aproximadamente 1400 bytes).
3. El número del paquete TCP (SEQ)
Un paquete de 1400 bytes, que luego envía una gran cantidad de datos a la vez, debe dividirse en múltiples paquetes. Por ejemplo, un archivo de 10 MB debe enviar más de 7.100 paquetes. Al enviar, el protocolo TCP asigna cada número de secuencia (SEQ para abreviar) para que la parte receptora pueda restaurarlo en orden. En caso de pérdida de paquetes, también puede saber qué paquete se perdió. El número del primer paquete es un número aleatorio. Para facilitar la comprensión, aquí se llama paquete 1. Suponiendo que la longitud de la carga útil de este paquete es de 100 bytes, se puede deducir que el número del siguiente paquete debe ser 101. Esto significa que cada paquete puede obtener dos números: su propio número y el número del siguiente paquete. El destinatario entonces sabe en qué orden deben restaurarse a sus archivos originales.
(Descripción de la imagen: el número de paquete actual es 45943 y el siguiente número de paquete es 46183, lo que muestra que la carga de este paquete es de 240 bytes).
4. Ensamblaje de paquetes TCP
Después de recibir el paquete de datos TCP, el sistema operativo restaura el ensamblaje. La aplicación no procesa directamente los paquetes TCP. Para las aplicaciones, no se preocupe por los detalles de la comunicación de datos. A menos que la línea sea anormal, siempre se reciben los datos completos. Los datos requeridos por la aplicación se colocan en un paquete TCP y tienen su propio formato (como el protocolo HTTP). TCP no proporciona ningún mecanismo para indicar el tamaño del archivo original, que se especifica mediante el protocolo de capa de aplicación. Por ejemplo, el protocolo HTTP tiene un encabezado Content-Length, que indica el tamaño del cuerpo de información. Para el sistema operativo, es recibir continuamente paquetes TCP y ensamblarlos en orden, hay muchos en un paquete. El sistema operativo no procesará los datos en el paquete TCP. Una vez que los paquetes TCP estén ensamblados, transfiéralos a la aplicación. Hay un parámetro de puerto en el paquete TCP, que se utiliza para especificar la aplicación que se reenviará al puerto.
(Descripción de la imagen: el sistema transfiere los datos ensamblados a la aplicación correspondiente de acuerdo con el puerto en el paquete TCP. En la figura anterior, el puerto 21 es el servidor FTP, el puerto 25 es el servicio SMTP y el puerto 80 es el servidor web). Después de recibir los datos originales ensamblados, tomando un navegador como ejemplo, leerá un dato correctamente de acuerdo con el campo Contenido-Longitud del protocolo HTTP. Esto también significa que una sola comunicación TCP puede incluir múltiples comunicaciones HTTP.
Cinco, inicio lento y ACK
El servidor envía paquetes de datos, por supuesto, cuanto antes mejor, es mejor enviarlos todos a la vez. Sin embargo, si se envía demasiado rápido, existe la posibilidad de pérdida de paquetes. Muchos factores, como el ancho de banda pequeño, los enrutadores sobrecalentados y los desbordamientos del búfer pueden causar la pérdida de paquetes. Si la línea no es buena, cuanto más rápido la envíe, más perderá. El estado más ideal es alcanzar la tasa más alta si la línea lo permite. Pero, ¿cómo sabemos cuál es la tasa ideal de la línea de la otra parte? La respuesta es intentarlo lentamente. Para lograr la unidad de eficiencia y confiabilidad, el protocolo TCP ha diseñado un mecanismo de inicio lento. Al principio, la transmisión es lenta, y luego la velocidad se ajusta de acuerdo con la situación de pérdida de paquetes: si el paquete no se pierde, la velocidad de transmisión se acelera; si el paquete se pierde, la velocidad de transmisión se reduce. Se configura en el kernel de Linux (constante TCP_INIT_CWND). Cuando se inicia la comunicación, el remitente envía 10 paquetes a la vez, es decir, el tamaño de la "ventana de envío" es 10. Luego pare, espere la confirmación del receptor y luego continúe enviando. Por defecto, el receptor envía un mensaje de confirmación cada vez que recibe dos paquetes TCP. "Acuse de recibo" en inglés es acuse de recibo, por lo que este mensaje de confirmación se abrevia ACK. ACK lleva dos mensajes.
Espere recibir el siguiente número de paquete
La capacidad restante de la ventana de recepción del receptor
El remitente tiene estas dos informaciones, más el último número del paquete de datos que ha enviado, adivinará la velocidad de recepción aproximada del receptor, reduciendo o aumentando así la velocidad de envío. Esto se llama la "ventana de envío", y el tamaño de esta ventana es variable.
(Descripción de la imagen: cada ACK lleva el número del siguiente paquete y la capacidad restante de la ventana de recepción. Ambas partes enviarán ACK.) Tenga en cuenta que, dado que la comunicación TCP es bidireccional, ambas partes deben enviar ACK. Es probable que los tamaños de las ventanas de las dos partes sean diferentes. Y ACK es solo unos pocos campos simples, generalmente combinados con datos y enviados en un paquete de datos.
(Descripción de la imagen: hay 4 comunicaciones en la imagen de arriba. En la primera comunicación, el número de paquete de datos enviado por el host A al host B es 1, y la longitud es de 100 bytes. Por lo tanto, la segunda vez que el número ACK del host B es 1 + 100 = 101, el número de paquete del host A en la tercera comunicación también es 101. Del mismo modo, el número de paquete enviado desde el host B al host A en la segunda comunicación es 1, y la longitud es de 200 bytes, por lo que el host A ACK en la tercera comunicación Es 201, y el número de paquete del host B en la cuarta comunicación también es 201.) Incluso para una conexión con un gran ancho de banda y una buena línea, TCP siempre intenta lentamente desde 10 paquetes. Alcanzar la tasa de transmisión más alta. Este es el inicio lento de TCP.
6. Pérdida de procesamiento de paquetes de datos.
El protocolo TCP puede garantizar la integridad de la comunicación de datos, ¿cómo se hace esto? Como se mencionó anteriormente, cada paquete lleva el número del siguiente paquete. Si no se recibe el siguiente paquete, el número ACK no cambiará. Por ejemplo, ahora he recibido el paquete No. 4, pero no he recibido el paquete No. 5. ACK se grabará, esperando recibir el paquete No. 5. Después de un período de tiempo, se recibe el paquete 5, luego la siguiente ronda de ACK actualizará el número. Si el paquete 5 todavía no se recibe, pero se reciben los paquetes 6 o 7, el número en el ACK no cambiará y el paquete 5 siempre se muestra. Esto dará como resultado una gran cantidad de contenido duplicado ACK. Si el remitente descubre que ha recibido tres ACK repetidos consecutivos, o si no ha recibido ningún ACK después del tiempo de espera, confirmará la pérdida del paquete, es decir, el paquete 5 se pierde y luego enviará este paquete nuevamente. A través de este mecanismo, TCP garantiza que no habrá pérdida de paquetes.
(Descripción de la imagen: el Host B no recibe el paquete No. 100, enviará continuamente el mismo ACK, lo que activará al Host A para reenviar el paquete No. 100.)
