¿Qué es un paquete TCP?
Lo conceptual es lo siguiente: En pocas palabras, es un protocolo de control de transmisión (TCP) de fuente de datos enviado por un protocolo de transmisión
protocolo TCP maestro para implementar un protocolo altamente. Protocolo confiable de transmisión de conmutación de paquetes entre hosts. Este artículo describirá los estándares del protocolo y algunos métodos de implementación. Debido a que las redes informáticas son indispensables en la sociedad moderna, el protocolo TCP completa la comunicación principalmente cuando la red no es confiable. Puede ser particularmente útil para los militares, pero también es adecuado para los sectores gubernamentales y comerciales. TCP es un protocolo confiable de extremo a extremo orientado a la conexión. Admite una variedad de aplicaciones web. TCP no tiene muchos requisitos para los servicios de capa inferior. Supone que la capa inferior solo puede proporcionar servicios de datagramas no confiables y puede ejecutarse en una red compuesta por una variedad de hardware. La siguiente figura muestra la posición de TCP en la estructura jerárquica. Su capa inferior es el protocolo IP. TCP puede transmitir datos de diferentes tamaños según los servicios proporcionados por el protocolo IP. En varias redes Teleport.
La parte superior de TCP es el programa de aplicación y la parte inferior es el protocolo IP. La interfaz de la capa superior incluye una serie de llamadas similares a las interrupciones del sistema operativo. Para aplicaciones de capa superior, TCP debería poder transmitir datos de forma asíncrona. Suponemos que la interfaz inferior es la interfaz del protocolo IP. Para lograr una transmisión de datos confiable orientada a la conexión en redes no confiables, TCP debe resolver los problemas de confiabilidad y control de flujo. Debe poder proporcionar múltiples interfaces para aplicaciones de capa superior y proporcionar datos a múltiples aplicaciones al mismo tiempo. El problema de la conexión debe resolverse para que TCP pueda denominarse orientado a la conexión. Finalmente, TCP también debe poder resolver el problema de la seguridad de la comunicación.
El entorno de red incluye redes conectadas por gateways (u otros dispositivos). La red puede ser una red de área local o alguna red de área metropolitana o red de área amplia, pero no importa cuáles sean, deben estar basadas. sobre conmutación de paquetes. Los diferentes protocolos en el host tienen diferentes números de puerto y un par de procesos se comunican a través de este número de puerto. Esta comunicación no incluye operaciones de E/S dentro de la computadora, solo operaciones realizadas en la red. Las computadoras de la red se consideran nodos de origen y destino para la transmisión de paquetes. En particular, cabe señalar que diferentes procesos en la computadora pueden comunicarse al mismo tiempo. En este caso, utilizarán números de puerto para distinguirlos y los datos enviados al proceso A no serán recibidos por el proceso B.
Para transmitir datos, el proceso llamará a TCP y transmitirá los datos y los parámetros correspondientes a TCP. Luego, TCP transmitirá los datos al TCP de destino. Por supuesto, esto se hace empaquetando el paquete TCP. en el paquete IP y cargarlo a través de la red Entregado. El TCP receptor se comunicará con la aplicación de la capa superior después de recibir los datos, y TCP garantizará la exactitud del orden de los datos recibidos. Aunque es posible que el protocolo subyacente no garantice que el orden sea correcto. Lo que hay que explicar aquí es que después de recibir este paquete, la puerta de enlace lo descomprimirá para ver si ha llegado al destino. De lo contrario, qué ruta se debe tomar para llegar al destino. Después de tomar la decisión, la puerta de enlace lo hará. Las condiciones del protocolo dentro de la red empaquetarán nuevamente el paquete TCP y lo transmitirán. Si es necesario, el paquete se dividirá nuevamente en varios segmentos antes de transmitirlo. Este proceso de inspección de desembarque es un proceso que requiere mucho tiempo. De lo anterior podemos ver el proceso básico de transmisión TCP. Por supuesto, el proceso específico puede ser mucho más complicado.
En un host que implementa TCP, TCP puede considerarse como un módulo, que no es muy diferente del sistema de archivos. TCP también puede llamar a algunas funciones del sistema operativo y no trata directamente con la red. controla la red. La tarea se completa mediante un módulo de controlador de dispositivo especializado. TCP simplemente llama a la interfaz IP e IP proporciona a TCP todos los servicios que TCP necesita. Podemos ver la estructura del protocolo TCP más claramente en la siguiente figura.
Como se mencionó anteriormente, las conexiones TCP son confiables y el orden en el que se transmiten los paquetes de datos está garantizado por un número de secuencia. El paquete de respuesta también incluye un número de secuencia, lo que indica que el receptor está listo para recibir un paquete con este número de secuencia.
Cuando TCP transmite un paquete de datos, también coloca el paquete de datos en la cola de retransmisión e inicia el contador. Si recibe información de confirmación sobre el paquete, lo elimina de la cola. Si el temporizador se agota, necesita reenviar este paquete. . Tenga en cuenta que el acuse de recibo devuelto por TCP no garantiza que el destinatario final haya recibido los datos. Esta responsabilidad recae en el destinatario.
Cada canal utilizado para transmitir TCP tiene una etiqueta de puerto. Debido a que esta etiqueta está determinada por cada terminal TCP, TCP puede no ser único. Para garantizar la unicidad de este valor, se debe utilizar una dirección de red. La combinación con el número de puerto logra el propósito de una identificación única. A esto lo llamamos socket. Una conexión se identifica por los sockets en ambos extremos de la conexión. El socket local puede comunicarse con diferentes sockets externos.
Una conexión se establece enviando el comando OPEN y los parámetros del socket externo al puerto local. TCP devuelve un nombre para marcar la conexión si el usuario necesita usar este nombre para marcar la conexión en el futuro. Para guardar la información de esta conexión, asumimos que existe algo llamado Bloque de control de transmisión (TCB). El comando OPEN también especifica si el establecimiento de esta conexión es una solicitud activa o una solicitud de espera pasiva. A continuación cubriremos las funciones específicas. Los segmentos TCP se transmiten en forma de datagramas de Internet. El encabezado IP transmite diferentes campos de información, incluidas las direcciones de origen y destino. El encabezado TCP sigue al encabezado de Internet y proporciona información específica del protocolo TCP. La siguiente figura es el diagrama de formato del encabezado TCP:
Puerto de origen: 16 bits
Puerto de destino: 16 bits
Código de secuencia: 32 bits, cuando SYN; aparece, El código de secuencia es en realidad el código de secuencia inicial (ISN), y el primer byte de datos es ISN 1.
Código de confirmación: 32 bits, si el bit de control ACK está configurado, este valor indica que está listo; para recibir el código de secuencia del paquete
Desplazamiento de datos: 4 bits, que indica dónde comienzan los datos
Reservado: 6 bits, estos bits deben ser 0;
Bits de control: 6 bits;
Ventana: 16 bits;
Bit de verificación: 16 bits
Puntero de prioridad: 16 bits, apuntando al; back es prioridad Bytes de datos;
Opción: la longitud es variable; pero la longitud debe registrarse en bytes; veremos el contenido específico de la opción junto con el comando específico; >
Relleno: longitud variable, relleno El contenido debe ser 0, esto es para garantizar que la combinación del encabezado y el desplazamiento al comienzo de los datos pueda ser divisible por 32
Ya hemos dicho que existe una cosa TCB. TCB almacena variables que incluyen el remitente, el socket del receptor y los punteros del búfer de envío y recepción del usuario.
Además de estas, existen algunas variables relacionadas con el envío y recepción de números de secuencia:
Envío de variables de secuencia
SND.UNA - envío no confirmado
SND.NXT - enviando el siguiente A
SND.WND - Enviar ventana
SND.UP - Enviar puntero de prioridad
SND.WL1 - Número de secuencia de segmento utilizado para la última actualización de la ventana
p>
SND.WL2 - Número de confirmación de segmento utilizado para la última actualización de la ventana
ISS - Número de secuencia de envío inicial
Recibir número de secuencia
p>
RCV.NXT - Recibir siguiente
RCV.WND - Recibir siguiente
RCV.UP - Recibir puntero de prioridad
IRS - Número de secuencia de recepción inicial
La siguiente figura le ayudará a comprender la relación entre las variables de secuencia de envío:
Variable de segmento actual
SEG.SEQ - número de secuencia del segmento
SEG.ACK - Indicador de reconocimiento del segmento
SEG.LEN - Longitud del segmento
SEG.WND - Ventana del segmento
SEG.UP - Puntero urgente de segmento
SEG.PRC - Prioridad de segmento
El proceso de conexión está representado por una serie de estados, estos estados son: LISTEN, SYN -ENVIADO, SINCRONIZADO, ESTABLECIDO, FIN-ESPERA-1, FIN-ESPERA-2, CIERRE-ESPERA, CIERRE, ÚLTIMO-ACK, TIEMPO-ESPERA y CERRADO. CERRADO significa que no hay conexión y el significado de cada estado es el siguiente:
ESCUCHAR - escucha las solicitudes de conexión desde el puerto TCP remoto
SYN-SENT - espera una; conexión coincidente después de enviar una solicitud de conexión
SYN-RECEIVED: esperando la confirmación de la solicitud de conexión después de recibir y enviar una solicitud de conexión
ESTABLECIDA: representa una conexión abierta y datos; se puede transferir al usuario
FIN-WAIT-1: espera una solicitud de interrupción de la conexión desde el TCP remoto o el reconocimiento de una solicitud de interrupción de la conexión anterior
FIN-WAIT; -2 - Esperar una solicitud de interrupción de la conexión desde el TCP remoto
CLOSE-WAIT - Esperando una solicitud de interrupción de la conexión desde el usuario local
CLOSING - Esperando el TCP remoto; para confirmar la interrupción de la conexión
LAST- ACK - Espere el reconocimiento de la solicitud de interrupción de la conexión enviada originalmente al TCP remoto
TIME-WAIT - Espere el tiempo suficiente para garantizar; que el TCP remoto recibe el reconocimiento de la solicitud de interrupción de la conexión
CERRADO: no hay estado de conexión
El proceso de conexión TCP es una transición de estado. la llamada del usuario: ABRIR, ENVIAR, RECIBIR, CERRAR, ABORTAR y ESTADO los segmentos de datos transmitidos, especialmente aquellos que incluyen los siguientes segmentos de datos marcados SYN, ACK, RST y FIN, así como el tiempo de espera, todo lo anterior cambiará el TCP; estado.
La siguiente figura muestra la transición de los estados de TCP, pero esta figura no incluye situaciones de error ni manejo de errores. No considere esta figura como una explicación general.
3.3. Número de secuencia
Ten en cuenta que los bytes que enviamos en la conexión TCP tienen un número de secuencia. Al estar numerados se puede confirmar su recepción.
La confirmación del número de secuencia es acumulativa, es decir, si el usuario recibe el mensaje de confirmación para X, significa que se han recibido los datos anteriores a X (excluyendo X). Los bytes de cada segmento están organizados de esta manera: el primer byte viene después del encabezado, en este orden. Debemos recordar que el espacio de secuencia real es limitado, aunque es grande, todavía es limitado. Su rango es de 0 a 2 elevado a la potencia de 32 menos 1. Creo que aquellos que están familiarizados con la programación deben saber por qué necesitamos usar 2 elevado a 32 como módulo al calcular si dos segmentos son consecutivos. Los tipos de operaciones de comparación de números de secuencia que TCP debe realizar incluyen lo siguiente:
(a) Determinar algunos números de secuencia enviados pero no confirmados
(b) Determinar que se han recibido todas las secuencias;
(c) Determine el número de secuencia que debe incluirse en el siguiente segmento.
Para recibir una confirmación de los datos enviados, TCP debe realizar la siguiente operación de comparación al procesar la confirmación:
SND.UNA = el número de secuencia confirmado más antiguo
<; p>SND.NXT = El siguiente número de secuencia a enviar;SEG.ACK = Recibir confirmación de TCP y recibir el siguiente número de secuencia esperado por TCP;
SEG.SEQ = el; primer número de secuencia de un segmento de datos;
SEG.LEN = el número de bytes incluidos en el segmento de datos
SEG.SEQ SEG.LEN-1 = el número de bytes en; el segmento de datos El último número de serie.
Tenga en cuenta la siguiente relación:
SND.UNA lt; SEG.ACK =lt; SND.NXT
Si el número de secuencia de un segmento de datos es menor o igual que El valor del número de confirmación, luego se confirma todo el segmento de datos. La siguiente operación de comparación es necesaria al recibir datos:
RCV.NXT = número de secuencia esperado y el borde más bajo de la ventana de recepción
RCV.NXT RCV.WND-1 = el; último número de secuencia y el borde más alto de la ventana de recepción;
SEG.SEQ = el primer número de secuencia recibido
SEG.SEQ SEG.LEN-1 = recibido El último número de secuencia;
Las cantidades anteriores tienen la siguiente relación:
RCV.NXT =lt; SEG.SEQ lt; RCV.NXT RCV .WND o RCV. NXT =lt; SEG.SEQ SEG.LEN-1 lt; RCV.NXT RCV.WND
La primera parte de la prueba es verificar si el comienzo del segmento de datos está dentro de la ventana de recepción, Sección La segunda parte es verificar si la parte final del segmento de datos también está dentro de la ventana de recepción; pasar cualquiera de las dos comprobaciones anteriores significa que incluye los datos requeridos por la ventana.
La situación real será más complicada, porque hay una ventana cero y una longitud de segmento de datos cero, por lo que tenemos las siguientes cuatro situaciones:
Longitud del segmento
Ventana de recepción
Prueba
0
0
SEG.SEQ = RCV.NXT
0
gt ; 0
RCV.NXT =lt; SEG.SEQ lt; RCV.NXT RCV.WND
gt; > Inaceptable
gt; 0
gt;
RCV.NXT =lt; SEG.SEQ lt; =lt; SEG.SEQ SEG.LEN-1 lt; RCV.NXT RCV.WND
Tenga en cuenta que el tamaño de la ventana de recepción puede ser cero. Cuando la ventana es cero, solo se usa para. recibir información ACK, por lo que para un TCP, puede usar una ventana de tamaño cero para recibir datos mientras envía datos. Incluso si el tamaño de la ventana de recepción es cero, TCP debe procesar los campos RST y URG de todos los mensajes recibidos.
También utilizamos el conteo para proteger cierta información de control específica. Esto se logra mediante el uso implícito de algunas etiquetas de control para permitir que el segmento de datos se retransmita (o reconozca) de manera confiable. La información de control no se transfiere en el espacio de datos del segmento, por lo que debemos utilizar números de secuencia especificados implícitamente para el control. SYN y FIN son cantidades de control que deben protegerse. Estas dos cantidades de control solo se utilizan cuando la conexión está abierta y cerrada. SYN se considera los datos entre los primeros datos reales y FIN son los datos después de los últimos datos reales. La longitud del segmento (SEG.LEN) incluye datos y espacio de número de secuencia. Si ocurre SYN, SEG.SEQ es el número de secuencia de SYN.
Selección del número de secuencia inicial
El protocolo no impone restricciones a la reutilización de una conexión específica. Una conexión está definida por un par de enchufes. Una nueva instancia de conexión se define como otra reanudación de la conexión, lo que plantea la pregunta: ¿Qué pasa si TCP determina que se obtuvieron múltiples segmentos de datos de otra reanudación de la conexión anterior? Este problema es particularmente notable cuando una conexión se abre y se cierra rápidamente, o se cierra por razones de memoria y luego se vuelve a establecer rápidamente.
Para evitar confusiones, los usuarios deben evitar reanudar el uso de una conexión y causar confusión en el número de secuencia. Debemos garantizar la exactitud del número de secuencia, incluso si TCP falla y no sabemos cuál era el número de secuencia anterior, debemos garantizar la exactitud del número de secuencia. Cuando se crea una nueva conexión, se genera un nuevo generador de Número de secuencia inicial (ISN), que se utiliza para seleccionar un nuevo ISN de 32 bits. El generador está relacionado con el byte de orden inferior del reloj de 32 bits. La frecuencia de actualización del byte de orden inferior es de aproximadamente 4 microsegundos, por lo que el tiempo del ciclo ISN es de aproximadamente 4,55 horas. Por lo tanto, establecemos la vida útil máxima (MSL) del paquete de red en menos de 4,55 horas, por lo que podemos considerar que el ISN es único. Para cada conexión, hay un número de secuencia de envío y un número de secuencia de recepción. El número de secuencia de envío inicial (ISS) lo selecciona el TCP de envío y el número de secuencia de recepción inicial se genera durante el proceso de establecimiento de la conexión.
Para que la conexión se conecte o se inicialice, los dos TCP deben estar sincronizados con el número de secuencia inicial de cada uno. Esto se hace intercambiando un bit de control SYN y el número de secuencia inicial. A los segmentos de datos con SYN los llamamos "SYN". El proceso de adquisición de sincronización no se repetirá aquí. Cada parte debe enviar su propio número de serie y devolver una confirmación del número de serie de la otra parte.
1) A --gt; B SYN Nuestro número de serie es X
2) A lt; B ACK Nuestro número de serie está confirmado
3 ) A lt; -- B SYN El número de serie de la otra parte es Y
4) A --gt B ACK Confirme el número de serie de la otra parte
Pasos 2 y 3 anteriores; Los pasos se pueden fusionar y convertirse en 3 fases, por lo que podemos llamarlo un apretón de manos de tres mensajes. Este proceso es necesario porque el número de secuencia no está asociado con el reloj global y TCP también puede tener diferentes mecanismos para seleccionar el ISN. El receptor que recibe el primer SYN no tiene forma de saber si el segmento se retrasó a menos que recuerde el número de secuencia más reciente utilizado en la conexión (lo cual generalmente no es posible), por lo que debe pedirle confirmación al remitente.
Para garantizar que la confirmación obtenida por TCP sea generada por el segmento recién enviado, en lugar del segmento de datos antiguo que aún está en la red, TCP debe permanecer en silencio dentro del tiempo MSL. En este artículo, asumimos que MSL = 2 horas. Esto se debe a necesidades de ingeniería. Si el usuario considera que está bien, puede cambiar el MSL. Tenga en cuenta que si se reinicia TCP mientras el número de secuencia en la memoria está en uso, no es necesario esperar, pero debe confirmar que el número de secuencia utilizado es mayor que el que se utiliza actualmente.
Si un host falla sin retener ningún número de secuencia, no DEBE emitir ningún segmento de datos dentro del tiempo MSL. Esta situación se explicará a continuación. No es necesario que la implementación de TCP cumpla con este requisito, pero esto hará que los datos antiguos se reciban como datos nuevos y los datos nuevos se rechacen como datos antiguos.
Cada vez que se forma un segmento de datos y se ingresa en la cola de salida, TCP le asigna un valor en el espacio de secuencia. Tanto los algoritmos de secuencia como de detección de réplicas múltiples en TCP se basan en este espacio de direcciones. No existirán más de 2 a 32 paquetes de energía en la cola de salida antes de que la otra parte los envíe o reciba. Se eliminarán todos los segmentos de datos redundantes. Sin esta disposición, a varios segmentos de datos se les asignaría el mismo número de secuencia, lo que provocaría confusión. Hay tantos números de secuencia en el segmento de datos como bytes en el segmento de datos.
En circunstancias normales, TCP retiene el siguiente número de secuencia que se enviará y el número de secuencia más antiguo que aún no se ha confirmado. No lo vuelva a utilizar sin confirmación. Esto tendrá algunos riesgos, por lo que. Para este propósito, el espacio de secuencia es muy grande. Para una red de 2 M, se necesitan 4,5 horas para agotar el espacio de secuencia, porque el tiempo máximo de supervivencia posible de un segmento de datos es solo una décima de segundo, lo que deja suficiente espacio, y en una red de 100 M, se necesitan 5,4 minutos. Aunque es un poco menos, todavía está bien.
Si no se deja espacio para guardar el número de secuencia al implementar TCP, es posible que no sea posible borrar los paquetes sobrantes. Por lo tanto, se recomienda que este tipo de implementación de TCP espere el tiempo de MSL después del error. para que Asegúrese de que se eliminen los paquetes redundantes. Esta situación también puede ocurrir a veces en implementaciones TCP que conservan números de secuencia. Esto crea un problema si el host falla repentinamente mientras TCP selecciona un número de secuencia que está siendo utilizado por otra conexión TCP. La esencia del problema es que el host no sabe cuánto tiempo ha estado inactivo ni si las réplicas redundantes todavía están en la red.
La forma de solucionar este problema es esperar el tiempo de MSL. Si no lo hace, correrá el riesgo de que la otra parte reciba datos incorrectamente. El tiempo de espera también se denomina "tiempo de silencio". . El implementador puede permitir que el usuario elija si desea esperar, pero el usuario no tiene que esperar el tiempo MSL pase lo que pase.
3.4. Establecimiento de una conexión
Se utiliza un protocolo de enlace de tres mensajes para establecer una conexión. No importa si ambas partes envían SYN al mismo tiempo. Ambas partes encontrarán que no hay confirmación en este SYN, por lo que conocerán esta situación. En términos generales, se debe enviar un segmento de "reinicio" para resolver esta situación. . El protocolo de enlace de tres mensajes reduce la posibilidad de que se produzca un error en la conexión. El siguiente es un ejemplo. Los corchetes angulares son el contenido y las etiquetas en el segmento de datos. No hay mucho más que decir.
En la línea 2, TCP A envía un número de secuencia de inicialización SYN, lo que indica que quiere usar el número de secuencia 100; en la línea 3, TCP B da una confirmación y espera el número de secuencia de A con el número de secuencia; 101 Segmento de datos; en la línea 4, TCP A da una confirmación, y en la línea 5, también da una confirmación y envía algunos datos. Tenga en cuenta que el número de secuencia en la línea 4 es el mismo que el de la línea 5, porque la información ACK. no está ocupado Número de serie dentro del espacio del número de serie. La situación en la que se generan solicitudes al mismo tiempo es la que se muestra en la siguiente figura, que es un poco más complicada.
La razón principal para utilizar el protocolo de enlace de tres mensajes es evitar el uso de segmentos de datos caducados. Para ello es necesario introducir un nuevo mensaje de control, RESET. Si el TCP receptor maneja el estado asíncrono, vuelve al estado LISTEN después de recibir RESET. Si TCP maneja los siguientes estados: ESTABLECIDO, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK y TIME-WAIT, abandona la conexión y pasa al usuario. Explicaremos esta última situación en detalle a continuación.
A través del ejemplo anterior, podemos ver cómo la conexión TCP se recupera de la interferencia de segmentos de datos caducados. Tenga en cuenta el RST (señal RESET) en las líneas 4 y 5.
Conexiones medio abiertas y otros estados anormales
Si una parte cierra la conexión sin pasar a la otra parte, o las dos partes fallan y no están sincronizadas, lo llamamos medio abierto. estado de conexión abierta. La conexión se RESTABLECE automáticamente cuando una de las partes intenta enviar datos. Sin embargo, después de todo, esta situación es anormal. Debe manejarse en consecuencia. Si la conexión en A se ha cerrado, B no lo sabe. Cuando B quiera enviar datos a A, recibirá una señal RESET, lo que indica que la conexión TCP es incorrecta y que la conexión actual debe finalizarse.
Supongamos que el TCP de A falla cuando dos procesos A y B se comunican entre sí. A depende del sistema operativo para admitir la existencia de TCP. Generalmente, un mecanismo de recuperación funcionará en este caso. Es posible que desee comenzar a trabajar desde el punto de recuperación. De esta manera, A puede intentar ABRIR la conexión y luego transmitir datos sobre la conexión que cree que todavía está abierta. En este momento, A recibirá el mensaje de error "No hay conexión abierta" del TCP local (es decir, de A). . El TCP de A enviará un segmento de datos que incluye SYN. El siguiente ejemplo mostrará este proceso:
En el ejemplo anterior, la información recibida por la Parte A no confirmó nada. En este momento, la Parte A descubrió que había un problema, por lo que envió el control RST. mensaje. Otra situación ocurre cuando A falla, pero B aún intenta enviar datos. El siguiente ejemplo puede representar esta situación. Tenga en cuenta que en la línea 2, A está confundido acerca de la información enviada por B.
En el siguiente ejemplo, las partes A y B tienen conexiones pasivas, las cuales están esperando información SYN. El paquete caducado se envía a la Parte B, lo que hace que la Parte B responda. Sin embargo, la Parte A, que recibió la respuesta, encuentra que algo anda mal y envía información de control RST, y la Parte B regresa al estado ESCUCHA pasiva.
En la realidad, existen demasiadas situaciones. A continuación enumeramos algunas reglas para generar información de control RST: Normalmente, RST se genera cuando la información recibida no es la información esperada. Si no está seguro, no envíe información de control RST fácilmente. Hay tres tipos de situaciones:
Si la conexión ya no existe y el mensaje enviado no es RST, entonces se debe devolver RST. Si desea denegar SYN a conexiones inexistentes, puede utilizar este método. Si el mensaje entrante tiene un campo ACK, el mensaje RST devuelto puede obtener el número de secuencia del campo ACK. Si no existe tal campo, el número de secuencia RST se establece en 0. El campo ACK se configura como la suma de la secuencia. número y la longitud del segmento de llegada. La conexión todavía está en estado CERRADO.
Si la conexión está en estado asincrónico (LISTEN, SYN-SENT, SYN-RECEIVED), y el acuse de recibo recibido es un acuse de recibo de un paquete no enviado o el nivel de seguridad del segmento de datos recibido no lo permite Requisitos de conexión Cuando las fases son consistentes, se envía RST.
Si no se reconoce el SYN y la prioridad del segmento de datos recibido es mayor que la prioridad requerida, entonces aumente la prioridad local (con el permiso del usuario y del sistema por adelantado) o envíe RST si el segmento de datos recibido es; la prioridad es menor que la prioridad requerida, se considera una coincidencia. Por supuesto, si la otra parte descubre que la prioridad es incorrecta y aumenta la prioridad, y aumenta la prioridad en el siguiente paquete, no se considera una coincidencia. Si la conexión ha entrado en SYN, la prioridad del segmento de datos recibido debe ser la misma que la prioridad local; de lo contrario, se envía RST. Si el mensaje entrante tiene un campo ACK, el mensaje RST devuelto puede obtener el número de secuencia del campo ACK. Si no existe tal campo, el número de secuencia RST se establece en 0. El campo ACK se configura como la suma de la secuencia. número y la longitud del segmento de llegada. La conexión sigue en el mismo estado que antes.
Si la conexión está en un estado sincronizado (ESTABLECIDO, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), cualquier número de secuencia más allá del ventana de recepción Todos los segmentos de datos producen los siguientes resultados: se envía un segmento de datos de confirmación vacío, que incluye el número de secuencia enviado actualmente y también incluye un reconocimiento que indica el número de secuencia del siguiente segmento de datos que desea recibir, y la conexión permanece en su estado original. Si se debe al nivel de seguridad, prioridad y otros problemas, envíe la señal RST y entre en el estado CERRADO.