TCP, es decir, Protocolo de Control de Transmisión, Protocolo de Control de Transmisión. Como su nombre indica, es necesario tener un control detallado sobre la transmisión de datos.

Formato de segmento de protocolo TCP

Número de puerto de origen/destino: Indica de qué proceso provienen los datos y a qué proceso van;
número de serie de 32 bits/número de confirmación de 32 bits: descripción detallada más adelante;
Longitud del encabezado TCP de 4 bits: indica cuántos bits de 32 bits (cuántos 4 bytes) tiene el encabezado TCP, por lo que la longitud máxima del encabezado TCP es 15 * 4 = 60
6 bits de bandera:

URG: si el puntero urgente es válido
ACK: si el número de confirmación es válido
PSH: solicite a la aplicación final receptora que lea los datos del búfer TCP inmediatamente
RST: la otra parte solicita restablecer la conexión; llamamos al segmento que lleva la bandera RST un segmento de reinicio
SYN: Solicitud para establecer una conexión; llamamos al identificador SYN un segmento de sincronización
FIN: Notifica a la otra parte que el extremo local está a punto de cerrarse Llamamos al segmento final que lleva la bandera FIN

Tamaño de ventana de 16 bits: más sobre eso más adelante
Suma de verificación de 16 bits: relleno en el extremo de envío, verificación de CRC. Si la verificación del extremo receptor falla, se considera que hay un problema con los datos. La suma de verificación aquí incluye no solo el encabezado TCP, sino también la parte de datos TCP.
Puntero urgente de 16 bits: identifica qué parte de los datos son datos urgentes;
Opción de encabezado de 40 bytes: ignorada temporalmente;

Principio TCP

El mecanismo de control proporcionado por TCP para la transmisión de datos se refleja principalmente en dos aspectos: seguridad y eficiencia.

Estos mecanismos son similares al principio de diseño de subprocesos múltiples: bajo la premisa de garantizar la seguridad de la transmisión de datos, mejorar la eficiencia de transmisión tanto como sea posible.

Mecanismo de respuesta de acuse de recibo (mecanismo de seguridad)

TCP numera cada byte de datos. es el número de serie.

Cada ACK tiene un número de secuencia de confirmación correspondiente, lo que significa decirle al remitente qué datos he recibido, dónde empezar a enviar la próxima vez.

Mecanismo de retransmisión de tiempo de espera (mecanismo de seguridad)

Después de que el host A envía datos a B, es posible que los datos no lleguen al host B debido a la congestión de la red y otras razones;
Si el host A no recibe un acuse de recibo de B dentro de un intervalo de tiempo específico, volverá a enviar;

Sin embargo, el host A no recibió el reconocimiento de B, también puede deberse a que se perdió el ACK;

Entonces, el host B recibirá una gran cantidad de datos duplicados. Luego, el protocolo TCP debe poder identificar esos paquetes como paquetes duplicados y descartar los duplicados.

En este momento, podemos usar el número de serie mencionado anteriormente para lograr fácilmente el efecto de deduplicación.

Entonces, ¿cómo determinar si el tiempo de espera?

Lo ideal es encontrar un tiempo mínimo para garantizar que "la respuesta de confirmación debe devolverse dentro de este tiempo".
Sin embargo, la duración de este tiempo varía según los diferentes entornos de red.
Si el tiempo de espera es demasiado largo, afectará la eficiencia general de la retransmisión;
Si el tiempo de espera es demasiado corto, es posible que se envíen paquetes repetidos con frecuencia;

Para garantizar una comunicación de alto rendimiento en cualquier entorno, TCP calcula dinámicamente el período máximo de tiempo de espera.

En Linux (lo mismo ocurre con BSD Unix y Windows), el tiempo de espera se controla con una unidad de 500 ms, y el tiempo de espera para cada retransmisión de tiempo de espera es un múltiplo entero de 500 ms.
Si aún no hay respuesta después de retransmitir una vez, espere 2*500ms antes de retransmitir.
Si aún no hay respuesta, espere 4*500ms para la retransmisión. Y así sucesivamente, aumentando exponencialmente.
Después de acumular una cierta cantidad de retransmisiones, TCP considera que la red o el host del mismo nivel es anormal y cierra la conexión a la fuerza.

Mecanismo de gestión de conexión (mecanismo de seguridad)

En circunstancias normales, TCP necesita pasar por tres protocolos de enlace para establecer una conexión y agitar cuatro veces para desconectarse.

Transición de estado del servidor:

[CERRADO -> LISTEN] El servidor entra en estado LISTEN después de llamar a listen, esperando que el cliente se conecte;
[LISTEN -> SYN_RCVD] Una vez que se supervisa la solicitud de conexión (segmento de sincronización), la conexión se coloca en la cola de espera del kernel y se envía un mensaje de confirmación SYN al cliente.
[SYN_RCVD -> ESTABLECIDO] Una vez que el servidor recibe el mensaje de confirmación del cliente, ingresa al estado ESTABLECIDO y puede leer y escribir datos.
[ESTABLECIDO -> CLOSE_WAIT] Cuando el cliente cierra activamente la conexión (llamando a cerrar), el servidor recibirá el segmento final y devolverá el segmento de confirmación e ingresará CLOSE_WAIT;
[CLOSE_WAIT -> LAST_ACK] Después de ingresar CLOSE_WAIT, significa que el servidor está listo para cerrar la conexión (los datos anteriores deben procesarse); cuando el servidor realmente llame para cerrar la conexión, enviará un FIN al cliente , y en este momento el servidor entra en el estado LAST_ACK, esperando la llegada del último ACK (este ACK es la confirmación de recepción de FIN por parte del cliente)
[LAST_ACK -> CLOSED] El servidor ha recibido el ACK para FIN y cierra completamente la conexión.

Transición de estado del cliente:

[CERRADO -> SYN_SENT] Las llamadas del cliente se conectan para enviar un segmento de sincronización;
[SYN_SENT -> ESTABLECIDO] Si la llamada de conexión es exitosa, ingresará al estado ESTABLECIDO y comenzará a leer y escribir datos;
[ESTABLECIDO -> FIN_WAIT_1] Cuando el cliente llama activamente a cerrar, envía un segmento final al servidor e ingresa FIN_WAIT_1 al mismo tiempo;
[FIN_WAIT_1 -> FIN_WAIT_2] Después de recibir la confirmación del servidor del segmento final, el cliente ingresa a FIN_WAIT_2 y comienza a esperar el segmento final del servidor;
[FIN_WAIT_2 -> TIME_WAIT] El cliente recibe el segmento final del servidor, ingresa TIME_WAIT y envía LAST_ACK;
[TIME_WAIT -> CLOSED] El cliente esperará un tiempo de 2MSL (vida máxima del segmento, vida útil máxima del mensaje) antes de ingresar al estado CERRADO.

La siguiente figura es un resumen de las transiciones de estado de TCP:

La línea de puntos más gruesa indica el cambio de estado del servidor;
La línea sólida más gruesa indica el cambio de estado del cliente;
CERRADO es un punto de partida hipotético, no un estado real;

Sobre "medio cerrado", ejemplo de novio y novia rompiendo

TIEMPO DE ESPERA

MSL es la duración máxima de un mensaje TCP, por lo que si TIME_WAIT persiste durante 2MSL, puede garantizar que los segmentos de mensajes retrasados o no recibidos en ambas direcciones de transmisión hayan desaparecido (de lo contrario, el servidor se reinicia inmediatamente y puede recibir mensajes de datos tardíos del anterior). proceso, pero es probable que estos datos sean incorrectos);
Al mismo tiempo, también se garantiza teóricamente que el último mensaje llegue de forma fiable (suponiendo que se pierda el último ACK, el servidor volverá a enviar un FIN. En este momento, aunque el proceso del cliente se ha ido, la conexión TCP sigue ahí). , y el LAST_ACK aún se puede reenviar);

CLOSE_WAIT

En términos generales, para una gran cantidad de estados CLOSE_WAIT en el servidor, la razón es que el servidor no cerró el zócalo correctamente, lo que provocó que cuatro manos agitadas no se completaran correctamente. Esto es un error. Simplemente agregue el cierre correspondiente para resolver el problema.

Ventana corredera (mecanismo de eficiencia)

Justo ahora discutimos la estrategia de respuesta de acuse de recibo.Por cada segmento de datos enviado, se debe dar una respuesta de confirmación ACK. Después de recibir el ACK, se envía el siguiente segmento de datos. Esto tiene una desventaja relativamente grande, es decir, un bajo rendimiento. Especialmente cuando el tiempo de ida y vuelta de los datos es largo.

Dado que el rendimiento de este método de envío y recepción es bajo, podemos mejorar mucho el rendimiento enviando varios datos a la vez (de hecho, el tiempo de espera de varios segmentos se superpone).

El tamaño de la ventana se refiere al valor máximo que puede continuar enviando datos sin esperar un reconocimiento. El tamaño de la ventana en la figura anterior es de 4000 bytes (cuatro segmentos).
Al enviar los primeros cuatro segmentos, no necesita esperar ningún ACK, solo envíelo directamente;
Después de recibir el primer ACK, la ventana deslizante retrocede y continúa enviando los datos del quinto segmento, y así sucesivamente;
Para mantener esta ventana deslizante, el kernel del sistema operativo necesita crear un búfer de envío para registrar qué datos no se han respondido actualmente; solo los datos que han sido respondidos se pueden eliminar del búfer;
Cuanto mayor sea la ventana, mayor será el rendimiento de la red;

Entonces, si hay una pérdida de paquetes, ¿cómo retransmitir? Aquí se discuten dos situaciones.

Situación 1 : El paquete de datos ha llegado, pero se pierde el ACK.

En este caso, no importa si se pierde parte del ACK, porque puede ser confirmado por el ACK posterior;

Caso 2 : El paquete de datos se pierde directamente.

Cuando se pierde un determinado segmento, el remitente siempre recibirá ACK como 1001, como recordarle al remitente "Quiero 1001";
Si el host emisor recibe la misma respuesta "1001" tres veces consecutivas, volverá a enviar los datos correspondientes 1001 - 2000;
En este momento, después de que el extremo receptor recibe 1001, el ACK devuelto nuevamente es 7001 (porque 2001 - 7000). El extremo receptor lo ha recibido antes y se coloca en el búfer de recepción del kernel del sistema operativo del extremo receptor. ;

Este mecanismo se denomina "control de retransmisión de alta velocidad" (también llamado "retransmisión rápida").

Control de Flujo (Mecanismo de Seguridad)

La velocidad a la que el extremo receptor puede procesar datos es limitada. Si el extremo emisor envía demasiado rápido, el búfer del extremo receptor se llena. Si el extremo emisor continúa enviando en este momento, provocará la pérdida de paquetes, lo que provocará una serie de reacciones en cadena, como pérdida de paquetes y retransmisión.

Por lo tanto, TCP admite la determinación de la velocidad de envío del extremo emisor de acuerdo con la capacidad de procesamiento del extremo receptor. Este mecanismo se denomina control de flujo (Flow Control);

El extremo receptor coloca el tamaño del búfer que puede recibir en el campo "tamaño de ventana" en el encabezado TCP y notifica al extremo emisor a través del extremo ACK;
Cuanto mayor sea el campo de tamaño de la ventana, mayor será el rendimiento de la red;
Una vez que el extremo receptor descubre que su búfer está casi lleno, establecerá el tamaño de la ventana en un valor más pequeño y notificará al extremo emisor;
Después de que el remitente reciba esta ventana, reducirá su velocidad de envío;
Si el búfer del receptor está lleno, la ventana se establecerá en 0; en este momento, el remitente ya no enviará datos, pero debe enviar periódicamente un segmento de datos de detección de ventana, para que el receptor pueda decirle al remitente el tamaño de la ventana. .

¿Cómo le dice el extremo receptor al extremo emisor el tamaño de la ventana? Recuerde que en nuestro encabezado TCP, hay un campo de ventana de 16 bits , que almacena la información del tamaño de la ventana;

Entonces, aquí viene la pregunta, el número de 16 dígitos puede representar un máximo de 65535, entonces, ¿la ventana TCP máxima es de 65535 bytes?

De hecho, la opción de 40 bytes del encabezado TCP también incluye un factor de expansión de ventana M, y el tamaño real de la ventana es el valor del campo de la ventana desplazado a la izquierda por M bits;

Control de congestión (mecanismo de seguridad)

Aunque TCP tiene el gran asesino de la ventana deslizante, puede enviar una gran cantidad de datos de manera eficiente y confiable. Pero aún puede causar problemas si envía una gran cantidad de datos en la etapa inicial.

Debido a que hay muchas computadoras en la red, el estado actual de la red puede estar relativamente congestionado. Es probable que el envío de una gran cantidad de datos precipitadamente sin conocer el estado actual de la red empeore las cosas.

TCP introduce un mecanismo de inicio lento , que primero envía una pequeña cantidad de datos, explora la ruta, descubre el estado actual de congestión de la red y luego decide qué tan rápido transmitir los datos;

Aquí se introduce un concepto como la ventana de congestión
Cuando comience el envío, defina el tamaño de la ventana de congestión como 1;
Cada vez que se recibe una respuesta ACK, la ventana de congestión se incrementa en 1;
Cada vez que se envía un paquete de datos, compare la ventana de congestión con el tamaño de la ventana devuelto por el host receptor y tome el valor más pequeño como la ventana de envío real;

La tasa de crecimiento de la ventana de congestión como la anterior es exponencial. "Inicio lento" simplemente significa un crecimiento lento al principio, pero muy rápido.

Para no crecer tan rápido, la ventana de congestión no puede simplemente duplicarse.
Aquí se introduce un umbral llamado inicio lento.
Cuando la ventana de congestión supera este umbral, ya no crece exponencialmente, sino que crece linealmente

Cuando TCP comienza a iniciarse, el umbral de inicio lento es igual al valor máximo de la ventana;
En cada retransmisión de tiempo de espera, el umbral de inicio lento se convertirá en la mitad del valor original y la ventana de congestión se establecerá nuevamente en 1;

Una pequeña cantidad de pérdida de paquetes, solo activamos la retransmisión por tiempo de espera, una gran cantidad de pérdida de paquetes, creemos que la red está congestionada;

Cuando se inicia la comunicación TCP, el rendimiento de la red aumentará gradualmente; a medida que la red se congestione, el rendimiento disminuirá inmediatamente;

El control de congestión, en última instancia, es un compromiso de que el protocolo TCP quiere transmitir datos a la otra parte lo más rápido posible, pero también evita causar demasiada presión en la red.

El proceso de control de congestión de TCP es como el sentimiento de amor apasionado

Respuesta Retrasada (Mecanismo de Eficiencia)

Si el host que recibe los datos devuelve una respuesta ACK inmediatamente, la ventana devuelta en este momento puede ser relativamente pequeña.

Suponga que el búfer del extremo receptor es 1M. Recibió 500 000 datos a la vez; si responde de inmediato, la ventana devuelta es de 500 000;
Pero, de hecho, la velocidad de procesamiento del extremo de procesamiento puede ser muy rápida, y se consumirán 500 K datos del búfer en 10 ms;
En este caso, el procesamiento en el extremo receptor está lejos de llegar a su límite, incluso si la ventana se amplía, aún puede manejarlo;
Si el extremo receptor espera un momento antes de responder, por ejemplo, espera 200 ms antes de responder, entonces el tamaño de ventana devuelto en este momento es 1 M;
Es importante recordar que cuanto mayor sea la ventana, mayor será el rendimiento de la red y más eficiente será la transferencia. Nuestro objetivo es maximizar la eficiencia de la transmisión y garantizar que la red no esté congestionada;

Entonces, ¿pueden retrasarse todos los paquetes en respuesta? Ciertamente no;

Límite de cantidad: responde cada N paquetes;
Límite de tiempo: Responda una vez cuando se exceda el tiempo máximo de demora;

El número específico y el tiempo de espera varían según el sistema operativo; generalmente, N es 2 y el tiempo de espera es de 200 ms;

Piggybacking (mecanismo de eficiencia)

Con base en la respuesta demorada, encontramos que en muchos casos, el servidor del cliente también "envía y recibe" en la capa de aplicación. Significa que el cliente dijo "¿Cómo estás?" al servidor, y el servidor devolverá un "Bien, gracias" al cliente;

Luego, en este momento, el ACK puede hacer autostop y enviarlo de regreso al cliente junto con la respuesta del servidor de "Bien, gracias".

Otras características: flujo de bytes orientado, búfer, límites de tamaño

Cree un socket TCP y cree un búfer de envío y un búfer de recepción en el kernel al mismo tiempo ;

Al llamar a escribir, los datos se escribirán primero en el búfer de envío;
Si la cantidad de bytes enviados es demasiado larga, se dividirá en varios paquetes TCP y se enviará;
Si el número de bytes enviados es demasiado corto, esperará en el búfer hasta que el búfer tenga casi la misma longitud, o lo enviará en otros momentos adecuados;
Al recibir datos, los datos también llegan al búfer de recepción del kernel desde el controlador de la tarjeta de red;
Luego, la aplicación puede llamar a leer para obtener datos del búfer de recepción;
Por otro lado, una conexión TCP tiene un búfer de envío y un búfer de recepción, por lo que para esta conexión, los datos se pueden leer o escribir. Este concepto se llama dúplex completo.

Debido a la existencia del búfer, la lectura y escritura del programa TCP no necesita coincidir una por una, por ejemplo:

Al escribir 100 bytes de datos, puede llamar a escribir una vez para escribir 100 bytes, o puede llamar a escribir 100 veces para escribir un byte a la vez;
Al leer 100 bytes de datos, no hay necesidad de considerar cómo escribirlos. Puede leer 100 bytes a la vez, o puede leer un byte a la vez y repetir 100 veces;

problema de la bolsa pegajosa

En primer lugar, debe quedar claro que el "paquete" en el problema del paquete adhesivo se refiere al paquete de datos de la capa de aplicación.
En el encabezado del protocolo de TCP, no hay un campo como "longitud del paquete" como UDP, pero hay un campo como el número de secuencia.
Desde la perspectiva de la capa de transporte, TCP viene uno por uno. Póngalos en el búfer de acuerdo con el número de secuencia.
Desde la perspectiva de la capa de aplicación, lo que ve es solo una serie de datos de bytes continuos.
Luego, el programa de aplicación ve una serie de datos de bytes de este tipo y no sabe qué parte comenzar desde qué parte, es un paquete de datos de capa de aplicación completo.

Entonces, ¿cómo evitar el problema de la bolsa pegajosa? En el análisis final, es una oración para aclarar el límite entre los dos paquetes .

Para un paquete de longitud fija, asegúrese de que se lea en un tamaño fijo cada vez; por ejemplo, la estructura de solicitud anterior tiene un tamaño fijo, luego se puede leer secuencialmente desde el comienzo del búfer de acuerdo con el tamaño de (Solicitud) ;
Para paquetes de longitud variable, puede especificar un campo para la longitud total del paquete en el encabezado del paquete, para que sepa la posición final del paquete;
Para paquetes de longitud variable, también puede usar un separador claro entre paquetes (el protocolo de la capa de aplicación lo determina el propio programador, siempre que el separador no entre en conflicto con el texto);

Pensando : Para el protocolo UDP, ¿existe también un "problema de paquete adhesivo"?

Para UDP, si la capa superior no ha entregado datos, la longitud del paquete UDP todavía está allí. Al mismo tiempo, UDP entrega datos a la capa de aplicación uno por uno. Hay límites de datos muy claros.
Desde la perspectiva de la capa de aplicación, cuando se usa UDP, se recibe o no un mensaje UDP completo. No habrá una situación de "mitad".

excepción TCP

Terminación del proceso: la terminación del proceso liberará el descriptor del archivo y todavía se puede enviar FIN. No es diferente de un apagado normal.

Reinicio de la máquina: igual que la finalización del proceso.

La máquina está apagada/el cable de red está desconectado: el extremo receptor piensa que la conexión todavía está allí, una vez que el extremo receptor tiene una operación de escritura y descubre que la conexión ya no está allí, se restablecerá. Incluso si no hay una operación de escritura, el propio TCP tiene un temporizador de mantenimiento de conexión incorporado, que periódicamente preguntará si la otra parte todavía está allí. Si la otra parte no está allí, la conexión también se liberará.

Además, algunos protocolos de la capa de aplicación también tienen algunos de estos mecanismos de detección. Por ejemplo, en la conexión larga HTTP, el estado de la otra parte también se verificará periódicamente. Por ejemplo, QQ intentará volver a conectarse regularmente después de que se desconecte QQ.

Resumen de TCP

¿Por qué TCP es tan complicado? Porque es necesario asegurar la fiabilidad y al mismo tiempo mejorar el rendimiento tanto como sea posible.

fiabilidad:

suma de control
Número de serie (llega secuencialmente)
respuesta de confirmación
tiempo de espera reenviar
gestión de conexiones
control de flujo
control de congestión

Mejorar el rendimiento:

ventana deslizante
retransmisión rápida
respuesta tardía
a cuestas

otro:

Temporizadores (temporizador de retransmisión de tiempo de espera, temporizador de mantenimiento, temporizador TIME_WAIT, etc.)

Basado en el protocolo de capa de aplicación TCP

HTTP
HTTPS
SSH
Telnet
FTP
SMTP

Por supuesto, también incluye el protocolo de capa de aplicación personalizado cuando escribe su propio programa TCP;

protocolo UDP

Formato final del protocolo UDP

Longitud UDP de 16 bits, que indica la longitud máxima de todo el datagrama (encabezado UDP + datos UDP);
Si la suma de verificación es incorrecta, se descartará directamente;

Características de UDP

El proceso de transmisión UDP es similar al envío de una carta.

sin conexión

Si conoce la IP y el número de puerto del par, puede transmitir directamente sin establecer una conexión;

Faltón

Sin ningún mecanismo de seguridad, después de que el remitente envía el datagrama, si el segmento no se puede enviar a la otra parte debido a una falla en la red, la capa de protocolo UDP no devolverá ningún mensaje de error a la capa de aplicación;

Orientado a datagramas

La capa de aplicación envía el UDP la longitud del mensaje, y el UDP lo envía tal cual, sin dividir ni fusionar;

Transferir 100 bytes de datos con UDP:

Si el extremo emisor envía 100 bytes a la vez, entonces el extremo receptor también debe recibir 100 bytes a la vez; en lugar de recibir 10 veces en un bucle, se reciben 10 bytes cada vez.

zona de amortiguamiento

UDP solo tiene búfer de recepción y no tiene búfer de envío:

UDP no tiene un búfer de envío real . Los datos enviados se entregarán directamente al kernel, y el kernel pasará los datos al protocolo de capa de red para las acciones de transmisión posteriores;
UDP tiene un búfer de recepción, pero este búfer de recepción no puede garantizar que el orden de los mensajes UDP recibidos sea coherente con el orden de envío de los mensajes UDP; si el búfer está lleno, los datos UDP que llegan se descartarán;

Los sockets UDP pueden leer y escribir, este concepto se denomina dúplex completo .

tamaño limitado

Hay una longitud máxima de 16 bits en el encabezado del protocolo UDP. Es decir, la longitud máxima de datos que puede transmitir un UDP es de 64K (incluida la cabecera UDP).

Protocolo de capa de aplicación basado en UDP

NFS: sistema de archivos de red
TFTP: protocolo trivial de transferencia de archivos
DHCP: protocolo de configuración de host dinámico
BOOTP: Protocolo de arranque (para arranque de dispositivo sin disco)
DNS: Protocolo de resolución de nombres de dominio

Por supuesto, también incluye el protocolo de capa de aplicación personalizado cuando escribe el programa UDP usted mismo.

Comparación TCP/UDP

Dijimos que TCP es una conexión confiable, entonces, ¿TCP es necesariamente mejor que UDP? Las ventajas y desventajas entre TCP y UDP no se pueden comparar de manera simple y absoluta

Cuando se usa TCP para una transmisión confiable, se aplica a escenarios como la transferencia de archivos y la actualización de estado importante;
UDP se usa en campos de comunicación que requieren transmisión de alta velocidad y rendimiento en tiempo real, por ejemplo, QQ temprano, transmisión de video, etc. Además, UDP se puede utilizar para la transmisión;

En el análisis final, tanto TCP como UDP son herramientas para programadores. Cuándo usarlos y cómo usarlos debe determinarse de acuerdo con los escenarios de demanda específicos.

Protocolos clave de capa de red

Determine una ruta adecuada en un entorno de red complejo.

protocolo IP

El formato del encabezado del protocolo es el siguiente:

Número de versión de 4 dígitos (versión): especifica la versión del protocolo IP, que es 4 para IPv4.
Longitud del encabezado de 4 bits (longitud del encabezado): la longitud del encabezado IP es de 32 bits, es decir, la cantidad de bytes de longitud * 4. 4 bits significa que el número máximo es 15, por lo que la longitud máxima del encabezado IP es de 60 bytes.
Tipo de servicio de 8 bits (Tipo de servicio): campo de prioridad de 3 bits (obsoleto), campo TOS de 4 bits y campo reservado de 1 bit (debe establecerse en 0). Los TOS de 4 bits representan respectivamente: retraso mínimo, rendimiento máximo, confiabilidad más alta y costo mínimo. Estos cuatro entran en conflicto entre sí, y solo se puede elegir uno. Para aplicaciones como ssh/telnet, la latencia mínima es más importante; para programas como ftp, el rendimiento máximo es más importante.
Longitud total de 16 bits (longitud total): cuántos bytes ocupa el datagrama IP en su conjunto.
Identificación de 16 bits (id): identifica de forma única el mensaje enviado por el host. Si el paquete IP está fragmentado en la capa de enlace de datos, la identificación en cada fragmento es la misma.
Campo de bandera de 3 bits: el primer bit está reservado (reservado significa que no se usa ahora, pero se puede usar en el futuro si aún no lo he descubierto). Si el segundo bit es 1, la fragmentación está prohibida.En este momento, si la longitud del paquete excede la MTU, el módulo IP descartará el paquete. El tercer bit significa "más fragmentos". Si está fragmentado, el último fragmento se establece en 0 y los demás en 1. Similar a una etiqueta de cierre.
Offset de fragmento de 13 bits (framegament offset): Es el desplazamiento del fragmento relativo al comienzo del paquete IP original. De hecho, indica dónde se encuentra el fragmento actual en el mensaje original. El número real de bytes compensados se obtiene con este valor * 8. Por lo tanto, a excepción del último mensaje, la longitud de otros mensajes debe ser un número entero múltiplo de 8 (de lo contrario, los mensajes no son continuos).
Tiempo de vida de 8 bits (Time To Live, TTL): el número máximo de saltos para que un datagrama llegue a su destino. Generalmente 64. Cada vez que se pasa una ruta, TTL -= 1, hasta llegar a 0, se descarta. Este campo se utiliza principalmente para evitar bucles de enrutamiento. Protocolo de 8 bits: Indica el tipo de protocolo de la capa superior.
Suma de verificación del encabezado de 16 bits: use CRC para verificar si el encabezado está dañado.
Dirección de origen de 32 bits y dirección de destino de 32 bits: indicar el remitente y el destinatario.

Protocolos clave de capa de transporte y capa de red de principios de red

Protocolos clave de la capa de transporte

Protocolo TCP