Hogar › Internet › Vea qué es "TCP" en otros diccionarios. Envío de datos vía TCP. Temporizador de retransmisión

Vea qué es "TCP" en otros diccionarios. Envío de datos vía TCP. Temporizador de retransmisión

Introducción

TCP es un protocolo orientado a la conexión. Antes de que cualquiera de las partes pueda enviar datos a la otra, se debe establecer una conexión entre ellas. En este capítulo, veremos en detalle cómo se establece una conexión TCP y cómo se termina.

Debido a que TCP requiere que se establezca una conexión entre dos extremos para funcionar, se diferencia de los protocolos sin conexión como UDP. Vimos que cuando se usa UDP, cada lado simplemente envía datagramas al otro sin establecer primero una conexión.

Establecer y finalizar una conexión

Para ver qué sucede cuando se establece y finaliza una conexión TCP, ejecutamos el siguiente comando en el sistema svr4:

rvs4% telnet bsdi descartar
Probando 192.82.148.3...
Conectado a bsdi.
El carácter de escape es "^]".
^] ingrese Control, corchete derecho,
Telnet> abandonar para que el cliente Telnet cierre la conexión
Conexión cerrada.

El comando telnet establece una conexión TCP con el host bsdi en el puerto correspondiente al servicio de descarte (Capítulo 1, sección). Este es exactamente el tipo de servicio que necesitamos para ver qué sucede cuando se establece y se interrumpe una conexión, pero sin intercambiar datos.

salida tcpdump

La Figura 18.1 muestra la salida de tcpdump para los segmentos generados por este comando.

1 0.0 svr4.1037 > bsdi.discard: S 1415531521:1415531521 (0)
ganar 4096
2 0,002402 (0,0024) bsdi.discard > svr4.1037: S 1823083521:1823083521 (0)
confirmar 1415531522 ganar 4096

3 0,007224 (0,0048) svr4.1037 > bsdi.descartar: . confirmar 1823083522 ganar 4096
4 4.155441 (4.1482) svr4.1037 > bsdi.discard: F 1415531522:1415531522 (0)
confirmar 1823083522 ganar 4096
5 4.156747 (0.0013) bsdi.discard > svr4.1037: . confirmar 1415531523 ganar 4096
6 4.158144 (0.0014) bsdi.discard > svr4.1037: F 1823083522:1823083522 (0)
confirmar 1415531523 ganar 4096
7 4.180662 (0.0225) svr4.1037 > bsdi.descartar: . confirmar 1823083523 ganar 4096

Figura 18.1 Salida de tcpdump para establecer y deshacer una conexión TCP.

Estos siete segmentos TCP contienen sólo encabezados TCP. No hubo intercambio de datos.

Para segmentos TCP, cada línea de salida comienza con

origen > destino: banderas

donde las banderas son cuatro de los seis bits de bandera del encabezado TCP (). La Figura 18.2 muestra cinco símbolos diferentes que corresponden a banderas y pueden aparecer en el resultado.

	abreviatura de 3 caracteres	Descripción
		números de secuencia de sincronización
		el remitente ha terminado de transmitir datos
		restablecer la conexión
		enviar datos al proceso de recepción lo más rápido posible
		ninguna de las cuatro banderas está configurada

Figura 18.2 Caracteres de bandera generados por tcpdump para bits de bandera en el encabezado TCP.

En este ejemplo vemos las banderas S, F y de puntos. Más adelante aparecerán dos banderas más (R y P). Los otros dos bits de bandera en el encabezado TCP (ACK y URG) se imprimen mediante el comando tcpdump.

Más de uno de los cuatro bits de bandera mostrados en la Figura 18.2 puede estar presente en un solo segmento; sin embargo, normalmente sólo se establece una bandera.

RFC 1025 [Postel 1987] llama a un segmento en el que la combinación máxima de todos los bits de bandera disponibles se establece simultáneamente (SYN, URG, PSH, FIN y 1 byte de datos) un paquete Kamikaze (hay varias otras definiciones de un paquete similar en inglés, concretamente "paquete sucio", "paquete de árbol de Año Nuevo", etc.).

En la línea 1, el campo 1415531521:1415531521 (0) significa que el número de secuencia del paquete es 1415531521 y el número de bytes de datos en el segmento es 0. El comando tcpdump imprime el número de secuencia inicial, dos puntos, el número de secuencia final estimado, y luego el número de bytes de datos entre paréntesis. Es posible ver el número de secuencia final esperado cuando el número de bytes es mayor que 0. El campo aparece (1) si el segmento contiene uno o más bytes de datos de usuario, o (2) si SYN, FIN o RST La bandera está configurada. En las líneas 1, 2, 4 y 6 de la Figura 18.1, este campo aparece porque los bits de bandera están configurados; en este ejemplo no se intercambió ningún dato.

En la línea 2, el campo ack 1415531522 contiene el número de confirmación. Se imprime solo si el indicador ACK está configurado. El campo win 4096 en cada línea de salida muestra el tamaño de la ventana declarado por el remitente. En este ejemplo, donde no hubo comunicación, el tamaño de la ventana se dejó sin cambios y se usó el valor predeterminado de 4096 (cubriremos el tamaño de la ventana TCP en una sección del Capítulo 20).

Y el último campo en el resultado de la Figura 18.1, muestra el tamaño máximo de segmento (MSS - tamaño máximo de segmento), una opción que establece el remitente. El remitente no desea recibir segmentos TCP mayores que este valor. Esto generalmente se hace para evitar la fragmentación (Capítulo 11, sección). Cubriremos el tamaño máximo de segmento en una sección de este capítulo y mostraremos el formato de las distintas opciones de TCP en una sección de este capítulo.

Diagramas de tiempo

La figura 18.3 muestra el diagrama de tiempos correspondiente a este intercambio de paquetes. (Describimos algunas de las características básicas de los diagramas de tiempo cuando vimos por primera vez). Esta figura muestra de qué lado envía los paquetes. También se muestra el resultado del comando tcpdump (imprimió SYN en lugar de S). Este diagrama de tiempo ha eliminado el valor del tamaño de la ventana porque no es relevante para nuestra discusión.

Protocolo de establecimiento de conexión

Ahora volvamos a los detalles del protocolo TCP, que se muestran en la Figura 18.3. Para establecer una conexión TCP, debe:

El solicitante (generalmente llamado cliente) envía un segmento SYN que indica el número de puerto del servidor al que el cliente desea conectarse y el número de secuencia original del cliente (en este ejemplo, ISN, 1415531521). Este es el segmento número 1.
El servidor responde con su segmento SYN que contiene el número de secuencia original del servidor (segmento 2). El servidor también reconoce la llegada del SYN del cliente mediante un ACK (ISN del cliente más uno). Se utiliza un único número de secuencia por SYN.
El cliente debe acusar recibo de la llegada del SYN del servidor mediante un ACK (ISN del servidor más uno, segmento 3).

Estos tres segmentos son suficientes para establecer una conexión. A esto se le suele llamar apretón de manos de tres vías.

Figura 18.3 Diagrama de tiempos de establecimiento y terminación de la conexión.

Se considera que la parte que envía el primer SYN ha activado la conexión (activamente abierta). El otro lado, que recibe el primer SYN y envía el siguiente SYN, participa pasivamente en la apertura de la conexión (apertura pasiva). (En una sección de este capítulo, detallaremos el procedimiento para abrir una conexión, donde ambas partes se consideran activas cuando se establece la conexión).

Cuando cada lado ha enviado su SYN para establecer una conexión, selecciona un Número de secuencia inicial (ISN) para esa conexión. El ISN debe cambiar cada vez, por lo que cada conexión tiene su propio ISN diferente. RFC 793 [Postel 1981c] especifica que el ISN es un contador de 32 bits que se incrementa en uno cada 4 microsegundos. Gracias a los números de secuencia, los paquetes que se retrasan en la red y se entregan más tarde no se perciben como parte de una conexión existente.

¿Cómo se selecciona el número de secuencia? En 4.4BSD (y la mayoría de las implementaciones de Berkeley), el número de secuencia inicial se establece en 1 cuando se inicializa el sistema. Esta práctica no se recomienda en el RFC de requisitos del host. Luego, este valor aumenta en 64000 cada medio segundo y vuelve a 0 cada 9,5 horas. (Esto corresponde a un contador que aumenta en uno cada 8 microsegundos, en lugar de cada 4 microsegundos). Además, cada vez que se establece una conexión, esta variable se incrementa en 64000.

El intervalo de 4,1 segundos entre los segmentos 3 y 4 corresponde al tiempo entre el establecimiento de una conexión y la introducción del comando telnet quit para finalizar la conexión.

Protocolo de desconexión

Para establecer una conexión, se necesitan 3 segmentos y para romperla, 4. Esto se explica por el hecho de que la conexión TCP puede estar en un estado medio cerrado. Dado que una conexión TCP es full-duplex (los datos pueden viajar en cada dirección independientemente de la otra), cada dirección debe cerrarse independientemente de la otra. La regla es que cada parte debe enviar un FIN cuando se complete la transferencia de datos. Cuando TCP recibe un FIN, debe notificar a la aplicación que la parte remota está interrumpiendo la conexión y deja de enviar datos en esa dirección. FIN generalmente se envía como resultado del cierre de la aplicación.

Podemos decir que el lado que cierra la conexión primero (envía el primer FIN) realiza un cierre activo, y el otro lado (que recibió ese FIN) realiza un cierre pasivo. Normalmente, un lado realiza un cierre activo y el otro un cierre pasivo; sin embargo, en una sección de este capítulo veremos que ambos lados pueden realizar un cierre activo.

El segmento número 4 en la Figura 18.3 cierra la conexión y se envía cuando el cliente Telnet deja de funcionar. Esto sucede cuando ingresamos a salir. En este caso, el cliente TCP se ve obligado a enviar FIN, cerrando el flujo de datos del cliente al servidor.

Cuando el servidor recibe el FIN, devuelve un ACK con el número de secuencia recibido más uno (segmento 5). FIN usa un número de secuencia, al igual que SYN. En este punto, el servidor TCP también envía una señal de fin de archivo a la aplicación (para apagar el servidor). Luego, el servidor cierra su conexión, lo que hace que su TCP envíe un FIN (segmento 6), que el cliente debe reconocer (ACK) incrementando el número de secuencia recibido (segmento 7).

La Figura 18.4 muestra un intercambio típico de segmentos al cerrar una conexión. Se omiten los números de secuencia. En esta figura, los FIN se envían debido a que las aplicaciones cierran sus conexiones, mientras que el software TCP genera automáticamente el ACK para estos FIN.

Las conexiones generalmente las establece el cliente, es decir, el primer SYN viaja del cliente al servidor. Sin embargo, cualquiera de las partes puede cerrar activamente la conexión (enviar el primer FIN). Sin embargo, a menudo es el cliente el que determina cuándo se debe cerrar la conexión, ya que el proceso del cliente está controlado en gran medida por el usuario, que ingresa algo como "salir" para cerrar la conexión. En la Figura 18.4, podemos invertir las etiquetas en la parte superior de la figura, llamando al lado izquierdo el servidor y al lado derecho el cliente. Sin embargo, incluso en este caso, todo funcionará exactamente como se muestra en la figura. (El primer ejemplo de la sección del Capítulo 14, por ejemplo, mostró cómo el servidor de hora cierra la conexión).

Figura 18.4 Intercambio normal de segmentos al cerrar una conexión.

Salida tcpdump normal

Dado que la tarea de clasificar una gran cantidad de números de secuencia es bastante compleja, la salida del programa tcpdump contiene los números de secuencia completos solo para los segmentos SYN, y todos los números de secuencia posteriores se muestran como un desplazamiento relativo de los números de secuencia originales. (Para obtener el resultado que se muestra en la Figura 18.1, tuvimos que especificar la opción -S). La salida normal de tcpdump correspondiente a la Figura 18.1 se muestra en la Figura 18.5.

1 0.0 svr4.1037 > bsdi.discard: S 1415531521:1415531521(0)
ganar 4096
2 0,002402 (0,0024) bsdi.discard > svr4.1037: S 1823083521:1823083521(0)
ack 1415531522
ganar 4096
3 0,007224 (0,0048) svr4.1037 > bsdi.descartar: . reconocer 1 ganar 4096
4 4.155441 (4.1482) svr4.1037 > bsdi.discard: F 1:1 (0) ack 1 win 4096
5 4.156747 (0.0013) bsdi.discard > svr4.1037: . ack 2 ganar 4096
6 4.158144 (0.0014) bsdi.discard > svr4.1037: F 1:1 (0) ack 2 win 4096
7 4.180662 (0.0225) svr4.1037 > bsdi.descartar: . ack 2 ganar 4096

Figura 18.5 Salida típica del comando tcpdump correspondiente al establecimiento y terminación de la conexión.

A menos que necesitemos mostrar números de secuencia completos, usaremos esta forma de salida en todos los ejemplos siguientes.

Tiempo de espera al establecer una conexión

Hay varias razones por las que no se puede establecer una conexión. Por ejemplo, el host (servidor) está apagado. Para simular una situación similar, ejecutamos el comando telnet después de desconectar el cable Ethernet del servidor. La Figura 18.6 muestra el resultado del comando tcpdump.

1 0.0 bsdi.1024 >
ganar 4096
2 5.814797 (5.8148) bsdi.1024 > svr4.discard: S 291008001:291008001(0)
ganar 4096
3 29.815436 (24.0006) bsdi.1024 > svr4.discard: S 291008001:291008001(0)
ganar 4096

Figura 18.6 Salida del comando tcpdump para establecer una conexión que ha expirado.

A lo que debe prestar atención en este resultado es a la frecuencia con la que el cliente TCP envía SYN en un intento de establecer una conexión. El segundo segmento se envía 5,8 segundos después del primero y el tercero se envía 24 segundos después del segundo.

Cabe señalar que este ejemplo se ejecutó aproximadamente 38 minutos después de reiniciar el cliente. Por lo tanto, el número de secuencia original correspondiente es 291008001 (aproximadamente 38x60x6400x2). Al comienzo del capítulo dijimos que los sistemas típicos de Berkeley establecen el número de secuencia inicial en 1 y luego lo incrementan en 64000 cada medio segundo.

También cabe señalar que esta es la primera conexión TCP desde que se reinició el sistema, ya que el número de puerto del cliente es 1024.

Sin embargo, la Figura 18.6 no muestra cuánto tiempo el cliente TCP realizó retransmisiones antes de abandonar su intento. Para poder ver estos valores temporales debemos ejecutar el comando telnet de la siguiente manera:

bsdi % fecha ; telnet svr4 descartar; fecha
Jueves 24 de septiembre 16:24:11 MST 1992
Probando 192.82.148.2...
Telnet: No se puede conectar al host remoto: Se agotó el tiempo de conexión
Jueves 24 de septiembre 16:25:27 MST 1992

El tiempo es 76 segundos. La mayoría de los sistemas de Berkeley establecen un límite de tiempo de 75 segundos, tiempo durante el cual se debe establecer una nueva conexión. En la sección del Capítulo 21 veremos que el tercer paquete enviado por el cliente expirará aproximadamente a las 16:25:29, es decir, 48 segundos después de su envío, pero el cliente no dejará de intentarlo después de 75 segundos. .

primera vez

En la figura 18.6, observe que el primer tiempo de espera, 5,8 segundos, está cerca de 6 segundos pero no de 6 segundos, mientras que el segundo tiempo de espera es casi exactamente 24 segundos. Se realizaron diez pruebas más similares, y en cada una de ellas el valor del primer tiempo muerto osciló entre 5,59 segundos y 5,93 segundos. El segundo tiempo muerto, sin embargo, fue siempre de 24,00 segundos.

Esto se debe a que las implementaciones BSD TCP inician un temporizador cada 500 milisegundos. Este temporizador de 500 milisegundos se utiliza para varios tiempos de espera de TCP, los cuales se describirán en los siguientes capítulos. Cuando ingresamos el comando telnet, se configura el temporizador inicial de 6 segundos (12 tics de reloj), sin embargo, puede expirar entre 5,5 y 6 segundos. La figura 18.7 muestra cómo sucede esto.

Figura 18.7 Temporizador TCP de 500 ms.

Dado que el temporizador está configurado en 12 tics, la primera disminución del temporizador puede ocurrir entre 0 y 500 milisegundos después de su configuración. A partir de este momento, el cronómetro disminuye aproximadamente cada 500 milisegundos, pero el primer período de tiempo puede variar. (Usamos la palabra "aproximadamente" porque el tiempo que TCP recibe el control cada 500 milisegundos es aproximado, ya que puede pasar otra interrupción y ser manejada por el núcleo).

Cuando este temporizador de 6 segundos expira en el tic marcado con 0 en la Figura 18.7, el temporizador se reinicia a 24 segundos (48 tics). El próximo temporizador será de 24 segundos porque se configuró en el momento en que el kernel y no el usuario llamó al temporizador TCP de 500 milisegundos.

Campo de tipo de servicio

En la figura 18.6 vemos la expresión. Este es el campo de tipo de servicio (TOS - tipo de servicio) en un datagrama IP (). El cliente Telnet en BSD/386 configura este campo para lograr una latencia mínima.

Tamaño máximo de segmento

El tamaño máximo de segmento (MSS) es el dato más grande que TCP enviará al extremo remoto. Cuando se establece una conexión, cada lado puede anunciar su MSS. Los valores que vimos fueron 1024. El datagrama IP resultante suele ser 40 bytes más grande: 20 bytes asignados para el encabezado TCP y 20 bytes para el encabezado IP.

Algunas publicaciones dicen que esta opción se instala "por acuerdo". En realidad, el acuerdo no se utiliza en este caso. Cuando se establece una conexión, cada lado anuncia el MSS que pretende recibir. (La opción MSS solo se puede usar en el segmento SYN). Si un lado no acepta la opción MSS del otro lado, se usa el tamaño predeterminado de 536 bytes. (En este caso, con un encabezado IP de 20 bytes y un encabezado TCP de 20 bytes, el tamaño del datagrama IP será de 576 bytes).

En general, cuanto más MSS mejor, siempre y cuando no se produzca fragmentación. (Esto no siempre es cierto. Consulte y verifique esto). Los tamaños de segmento más grandes permiten enviar más datos en cada segmento, lo que reduce el costo relativo de los encabezados IP y TCP. Cuando TCP envía un segmento SYN, ya sea cuando una aplicación local desea establecer una conexión o cuando se recibe una solicitud de conexión desde un host remoto, el valor MSS se puede establecer en la MTU de la interfaz saliente menos el tamaño del TCP fijo. y encabezados IP. Para Ethernet, MSS puede tener hasta 1460 bytes. Cuando se utiliza la encapsulación IEEE 802.3 (Capítulo 2, Sección), el MSS puede tener hasta 1452 bytes.

El valor de 1024 que vemos en este capítulo corresponde a conexiones que involucran BSD/386 y SVR4, porque la mayoría de las implementaciones de BSD requieren que el MSS sea un múltiplo de 512. Otros sistemas como SunOS 4.1.3, Solaris 2.2 y AIX 3.2. 2, declare un MSS de 1460 cuando ambos lados estén en la misma Ethernet. Los cálculos proporcionados en [Mogul 1993] muestran que un MSS de 1460 proporciona un mejor rendimiento de Ethernet que un MSS de 1024.

Si la dirección IP de destino es "no local", el MSS generalmente se establece en el valor predeterminado: 536. Si el destino final es local o no local se puede determinar de la siguiente manera. Un destino cuya dirección IP tiene el mismo ID de red y la misma máscara de subred que el remitente es local; un destino cuya dirección IP es completamente diferente de la ID de la red no es local; un destino con el mismo ID de red, pero con una máscara de subred diferente, puede ser local o no local. La mayoría de las implementaciones proporcionan una opción de configuración ( y ) que permite al administrador del sistema especificar qué subredes son locales y cuáles no locales. Establecer esta opción determina el MSS máximo anunciado (que puede ser tan grande como la MTU de la interfaz saliente); de lo contrario, se utiliza el valor predeterminado de 536.

MSS permite al host establecer el tamaño de los datagramas que enviará la parte remota. Si se tiene en cuenta que el host también limita el tamaño de los datagramas que envía, esto evita la fragmentación cuando el host se conecta a una red con una MTU más pequeña.

Imagine nuestro host slip, que tiene un canal SLIP con una MTU de 296, conectado a un enrutador bsdi. La figura 18.8 muestra estos sistemas y el sol anfitrión.

Figura 18.8 Conexión TCP de sun a slip y valores de MSS.

Establecimos una conexión TCP desde Sun hasta Slip y escaneamos los segmentos usando tcpdump. La Figura 18.9 muestra sólo el establecimiento de la conexión (se eliminan las declaraciones de tamaño de ventana).

1 0.0 sun.1093 > descarte.deslizamiento: S 517312000:517312000(0)

2 0,10 (0,00) descarte.deslizamiento > sol.1093: S 509556225:509556225(0)
ack 517312001
3 0,10 (0,00) sol.1093 > descarte.deslizamiento: . ack 1

Figura 18.9 Salida de Tcpdump para establecer una conexión de sol a deslizamiento.

Lo importante a tener en cuenta aquí es que Sun no puede enviar un segmento con un fragmento de datos mayor a 256 bytes, ya que recibió un MSS de 256 (línea 2). Además, dado que Slip sabe que la MTU de la interfaz saliente es 296, incluso si Sun anuncia un MSS de 1460, nunca podrá enviar más de 256 bytes de datos para evitar la fragmentación. Sin embargo, el sistema puede enviar menos datos que el MSS anunciado por la parte remota.

La fragmentación solo se puede evitar de esta manera si el host está conectado directamente a una red con una MTU inferior a 576. Si ambos hosts están conectados a Ethernet y ambos anuncian un MSS de 536, pero la red intermedia tiene una MTU de 296, se producirá fragmentación. La única forma de evitar esto es utilizar el mecanismo de descubrimiento de MTU de transporte (Capítulo 24, sección).

TCP medio cerrado

TCP proporciona la capacidad para que una parte de una conexión deje de transmitir datos pero aún reciba datos de la otra parte. Esto se llama TCP medio cerrado. Como mencionamos anteriormente, no muchas aplicaciones pueden aprovechar esta función.

Para utilizar esta función de interfaz de programación, debe permitir que la aplicación diga: "Terminé de transferir datos, por lo que enviaré un indicador de fin de archivo (FIN) al extremo remoto, pero aún quiero recibir datos del extremo remoto antes de eso." hasta que me envíe una señal de fin de archivo (FIN)".

La API de sockets admite el modo semicerrado si la aplicación llama al cierre con un segundo argumento de 1 en lugar de llamar al cierre. Sin embargo, la mayoría de las aplicaciones cierran conexiones en ambas direcciones llamando a cerrar.

La Figura 18.10 muestra un escenario típico para TCP semicerrado. Hemos mostrado al cliente en el lado izquierdo, él inicia el modo semicerrado, sin embargo, cualquiera de los lados puede hacerlo. Los dos primeros segmentos son iguales: FIN del iniciador, seguido de ACK y FIN del receptor. Sin embargo, el escenario será diferente al de la figura 18.4 porque la parte que recibió la orden de medio cierre aún puede estar enviando datos. Hemos mostrado solo un segmento de datos seguido de un ACK, pero en este caso se puede enviar cualquier cantidad de segmentos de datos. (Cubriremos el intercambio de segmentos de datos y acuses de recibo con más detalle en ). Cuando el extremo que recibió la orden de medio cierre ha realizado una transferencia de datos, cierra su parte de la conexión, lo que provoca que se envíe un FIN, con un indicador de fin de archivo entregado a la aplicación que inició el modo "semicerrado". Cuando se confirma el segundo FIN, la conexión se considera completamente cerrada.

Figura 18.10 TCP en modo medio cerrado.

¿Para qué se puede utilizar el modo semicerrado? Un ejemplo sería el comando Unix rsh(1), que ejecuta un comando en otro sistema. Equipo

sol% clasificación rsh bsdi< datafile

ejecutará el comando sort en el host bsdi, con la entrada estándar del comando rsh leída desde un archivo llamado datafile. El comando rsh crea conexiones TCP entre él y el programa que se ejecutará en el host remoto. rsh entonces funciona de manera bastante simple: el comando copia la entrada estándar (archivo de datos) en la conexión y copia desde la conexión a la salida estándar (nuestra terminal). La figura 18.11 muestra cómo sucede esto. (Recordamos que la conexión TCP es full duplex.)

Figura 18.11 Comando: rsh bsdi sort< datafile.

En el host remoto bsdi, el servidor rshd ejecuta el programa de clasificación de modo que su entrada y salida estándar se dirijan a la conexión TCP. El Capítulo 14 proporciona una descripción detallada de la estructura del proceso Unix involucrado aquí, pero estamos interesados en cómo se usan la conexión TCP y el modo semicerrado TCP.

El programa de clasificación no puede comenzar a generar resultados hasta que se hayan leído todas sus entradas. Todos los datos sin procesar que llegan a través de la conexión desde el cliente rsh al servidor de clasificación se envían al archivo que se va a ordenar. Cuando se alcanza la marca de fin de archivo en la entrada (archivo de datos), el cliente rsh realiza un medio cierre de la conexión TCP. Luego, el servidor de clasificación toma la marca de fin de archivo de su entrada estándar (conexión TCP), clasifica el archivo y escribe el resultado en su salida estándar (conexión TCP). El cliente rsh continúa leyendo la conexión TCP al final y copia el archivo ordenado en su salida estándar.

Sin utilizar el modo medio cerrado, se requiere alguna técnica adicional que permita al cliente decirle al servidor que ha terminado de enviar datos, pero que aún puede recibir datos del servidor. Alternativamente, se deben utilizar dos conexiones, pero se prefiere el modo semicerrado.

Diagrama de estado de transmisión TCP

Hemos descrito varias reglas para establecer y romper una conexión TCP. Estas reglas se recogen en un diagrama de estado de transmisión, que se muestra en la Figura 18.12.

Cabe señalar que este diagrama es un diagrama de estado estándar. Hemos marcado la transferencia normal del cliente con flechas continuas en negrita y la transferencia normal del servidor con flechas punteadas en negrita.

Dos transmisiones que conducen al estado ESTABLECIDO corresponden a abrir una conexión, y dos transmisiones que conducen a un estado ESTABLECIDO corresponden a romper la conexión. El estado ESTABLECIDO ocurre en el momento en que es posible transferir datos entre dos partes en ambas direcciones. Los siguientes capítulos describirán lo que sucede en este estado.

Hemos combinado los cuatro cuadros en la parte inferior izquierda del diagrama dentro de un cuadro de puntos y los hemos etiquetado como "cierre activo". Los otros dos cuadrados (CLOSE_WAIT y LAST_ACK) están unidos por un marco de puntos y etiquetados como "cierre pasivo".

Los nombres de los 11 estados (CLOSED, LISTEN, SYN_SENT, etc.) en esta figura se eligen para que correspondan a los estados generados por el comando netstat. Los nombres de netstat, a su vez, son casi idénticos a los nombres descritos en RFC 793. El estado CERRADO no es realmente un estado, pero es el punto inicial y final del diagrama.

Teóricamente es posible cambiar el estado de LISTEN a SYN_SENT, pero no se admite en las implementaciones de Berkeley.

Y un cambio de estado de SYN_RCVD a LISTEN solo es posible si se ingresó al estado SYN_RCVD desde el estado LISTEN (este es un escenario normal), y no desde el estado SYN_SENT (apertura simultánea). Esto significa que si hicimos una apertura pasiva (ingresamos al estado LISTEN), recibimos un SYN, enviamos un SYN con un ACK (ingresamos al estado RECEIVED_SYN - SYN_RCVD) y luego recibimos un reinicio en lugar de un ACK, el punto final regresa al estado LISTEN. estado y espera a que llegue otra solicitud de conexión.

Figura 18.12 Diagrama de cambio de estado de TCP.

La Figura 18.13 muestra el establecimiento y terminación de una conexión TCP típica. También se detallan los diferentes estados por los que pasan el cliente y el servidor.

Figura 18.13 Estados de TCP correspondientes a la apertura y cierre normal de la conexión.

En la Figura 18.13, asumimos que el cliente del lado izquierdo está realizando una apertura activa y el servidor de la derecha está realizando una apertura pasiva. También mostramos que el cliente está realizando un cierre activo (como mencionamos anteriormente, cualquiera de las partes puede realizar un cierre activo).

Debe rastrear los cambios de estado en la Figura 18.13 utilizando el datagrama de cambio de estado que se muestra en la Figura 18.12 para comprender por qué ocurre un cambio de estado particular.

Estado de espera 2MSL

El estado TIME_WAIT también se denomina a veces estado de espera 2MSL. Cada implementación elige un valor para la vida útil máxima del segmento (MSL - vida útil máxima del segmento). Este es el tiempo máximo que puede existir un segmento en la red antes de ser descartado. Sabemos que este tiempo es limitado porque los segmentos TCP se transmiten a través de datagramas IP y cada datagrama IP tiene un campo TTL que limita su vida útil.

RFC 793 [Postel 1981c] especifica que el MSL debe ser de 2 minutos. En diferentes implementaciones, este valor tiene un valor de 30 segundos, 1 minuto o 2 minutos.

Se dijo que la vida útil de un datagrama IP está limitada por el número de transferencias, no por un temporizador.

Cuando se utiliza MSL, se aplican las siguientes reglas: cuando TCP realiza un cierre activo y envía el último segmento que contiene un acuse de recibo (ACK), la conexión debe permanecer en el estado TIME_WAIT durante un período igual a dos MSL. Esto permite a TCP reenviar el último ACK en caso de que se pierda el primer ACK (en cuyo caso el lado remoto expirará y retransmitirá su FIN final).

Otro propósito de la espera 2MSL es que mientras una conexión TCP espera 2MSL, el par de sockets asignado para esa conexión (dirección IP del cliente, número de puerto del cliente, dirección IP del servidor y número de puerto del servidor) no se puede reutilizar. Esta conexión solo se puede reutilizar cuando expire el tiempo de espera de 2MSL.

Desafortunadamente, la mayoría de las implementaciones (Berkeley es una de ellas) están sujetas a requisitos más estrictos. De forma predeterminada, un número de puerto local no se puede reutilizar siempre que ese número de puerto sea el número de puerto local de un par de sockets que esté en el estado de espera 2MSL. A continuación veremos ejemplos de requisitos generales.

Algunas implementaciones y API proporcionan herramientas que le permiten solucionar estas limitaciones. Utilizando la API de socket, se puede especificar la opción de socket SO_REUSEADDR. Permite a la persona que llama asignarse un número de puerto local que se encuentra en el estado 2MSL; sin embargo, veremos que las reglas TCP no permiten que este número de puerto se use en una conexión que se encuentra en el estado de espera 2MSL.

Cada segmento retrasado que llega a una conexión que se encuentra en el estado de espera 2MSL se descarta. Dado que la conexión está definida por un par de sockets en el estado 2MSL, esta conexión no se puede reutilizar hasta que podamos establecer una nueva conexión. Esto se hace para garantizar que los paquetes tardíos no se acepten como parte de una nueva conexión. (Una conexión se define por un par de enchufes. Una nueva conexión se denomina restauración o reactivación de esa conexión).

Como ya mostramos en la Figura 18.13, el cliente normalmente realiza un cierre activo y entra en modo TIME_WAIT. El servidor normalmente realiza un apagado pasivo y no pasa por el modo TIME_WAIT. Podemos concluir que si apagamos el cliente y lo reiniciamos inmediatamente, este nuevo cliente no podrá usar el mismo número de puerto local. Esto no es un problema ya que los clientes normalmente usan puertos asignados dinámicamente y no les importa qué puerto asignado dinámicamente está actualmente en uso.

Sin embargo, desde el punto de vista del servidor, todo es diferente, ya que los servidores utilizan puertos preconocidos. Si apagamos un servidor que tiene una conexión establecida e intentamos reiniciarlo inmediatamente, el servidor no puede usar su número de puerto previamente conocido como punto final de la conexión, ya que ese número de puerto es parte de la conexión que está en el estado de espera 2MSL. . Por lo tanto, pueden pasar de 1 a 4 minutos antes de que se reinicie el servidor.

Puedes observar un escenario similar usando el programa de calcetines. Iniciamos el servidor, conectamos el cliente y luego apagamos el servidor:

sol% calcetín -v -s 6666
(inicie el cliente en bsdi, que se conectará a este puerto)
conexión al 140.252.13.33.6666 desde 140.252.13.35.1081
^? ingrese el carácter de interrupción para apagar el servidor
sol% calcetín -s 6666 e intente reiniciar inmediatamente el servidor en el mismo puerto
No se puede vincular la dirección local: la dirección ya está en uso.
sol% netstat Intentemos comprobar el estado de la conexión.
Conexiones activas a Internet
Proto Recv-Q Send-Q Dirección local Dirección extranjera (estado)
tcp 0 0 sol.6666 bsdi.1081 TIME_WAIT
muchas lineas eliminadas

Cuando intentamos reiniciar el servidor, el programa arroja un mensaje de error que indica que no puede capturar su número de puerto conocido porque ya está en uso (en el estado de espera 2MSL).

Luego ejecutamos inmediatamente netstat para observar el estado de la conexión y verificar que efectivamente esté en el estado TIME_WAIT.

Si seguimos intentando reiniciar el servidor y vemos el momento en que lo logra, podemos calcular el valor de 2MSL. Para SunOS 4.1.3, SVR4, BSD/386 y AIX 3.2.2, reiniciar el servidor tardará 1 minuto, lo que significa que el MSL es de 30 segundos. En Solaris 2.2, este reinicio del servidor tarda 4 minutos, lo que significa que el MSL es de 2 minutos.

Podemos ver el mismo error generado por el cliente si el cliente intenta apoderarse de un puerto que forma parte de una conexión que está en modo inactivo 2MSL (normalmente el cliente no hace esto):

sol% calcetín -v bsdi eco iniciamos el cliente que se conecta al servidor echo
conectado al 140.252.13.33.1162 al 140.252.13.35.7
hola imprimir esta línea
hola, hace eco desde el servidor
^D ingrese el carácter de fin de archivo para apagar el cliente
sol% calcetín -b1162 bsdi eco
No se puede vincular la dirección local: la dirección ya está en uso.

Cuando se inició el cliente por primera vez, se especificó la opción -v, que le permite ver qué número de puerto local se está utilizando (1162). La segunda vez que iniciamos el cliente, se especificó la opción -b, que le dice al cliente que se asigne un número de puerto local de 1162. Como esperábamos, el cliente no puede hacer esto, ya que este número de puerto es parte de una conexión que es en el estado 2MSL.

Hay una característica del estado de espera 2MSL que debe mencionarse aquí, a la que volveremos cuando hablemos del Protocolo de transferencia de archivos (FTP). Como se mencionó anteriormente, un par de sockets (que consisten en una dirección IP local, un puerto local, una dirección IP remota y un puerto remoto) permanecen en el estado de espera 2MSL. Sin embargo, si bien muchas implementaciones permiten que un proceso reutilice un número de puerto que forma parte de una conexión que está en modo 2MSL (generalmente usando la opción SO_REUSEADDR), es posible que TCP no permita que se cree una nueva conexión con el mismo par de sockets. Esto se puede comprobar mediante el siguiente experimento:

sol% calcetín -v -s 6666 inicio del servidor escuchando en el puerto 6666
(lanzamos el cliente en bsdi, que se conecta a este puerto)
conexión al 140.252.13.33.6666 desde 140.252.13.35.1098
^? ingrese el carácter de interrupción para apagar el servidor
sol% calcetín-b6666 bsdi 1098 iniciamos el cliente con el puerto local 6666
No se puede vincular la dirección local: la dirección ya está en uso.
sol% calcetín -A -b6666 bsdi 1098 Inténtalo de nuevo, esta vez con la opción -A.
error de apertura activa: dirección ya en uso

La primera vez ejecutamos nuestro programa sock como servidor en el puerto 6666 y le conectamos un cliente desde el host bsdi. El número de puerto asignado dinámicamente al cliente es 1098. Cerramos el servidor, por lo que realizó un apagado activo. En este caso, 4 parámetros: 140.252.13.33 (dirección IP local), 6666 (número de puerto local), 140.252.13.35 (dirección IP remota) y 1098 (número de puerto remoto) en el servidor caen en el estado 2MSL.

La segunda vez que ejecutamos este programa como cliente, especificando el número de puerto local 6666, intentó conectarse al host bsdi en el puerto 1098. Cuando intentamos reutilizar el puerto local 6666, se generó un error porque este puerto está en el estado 2MSL. .

Para evitar este error, ejecutamos el programa nuevamente con la opción -A, que habilita la opción SO_REUSEADDR. Esto permitió que el programa se asignara un número de puerto de 6666, pero recibió un error cuando el programa intentó realizar una apertura activa. Incluso si el programa puede asignarse el número de puerto 6666, no podrá crear conexiones al puerto 1098 en el host bsdi porque el par de sockets que define esta conexión está en el estado de espera 2MSL.

¿Qué pasa si intentamos establecer una conexión desde otro host? Primero, debemos reiniciar el servidor en sun con el flag -A, ya que el puerto que necesita (6666) es parte de una conexión que está en estado de espera 2MSL:

sol% calcetín -A -s 6666 iniciar el servidor escuchando en el puerto 6666

Luego, antes de que finalice el estado de espera 2MSL en sun, iniciamos el cliente en bsdi:

bsdi % calcetín -b1098 sol 6666
conectado al 140.252.13.35.1098 al 140.252.13.33.6666

Desafortunadamente, ¡funciona! Esta es una deficiencia de la especificación TCP, pero es compatible con la mayoría de las implementaciones de Berkeley. Estas implementaciones aceptan la llegada de una nueva solicitud de conexión para una conexión que se encuentra en el estado TIME_WAIT si el nuevo número de secuencia es mayor que el último número de secuencia utilizado en la conexión anterior. En este caso, el ISN para la nueva conexión se establece en el último número de secuencia de la conexión anterior más 128000. El apéndice del RFC 1185 muestra las posibles desventajas de esta tecnología.

Esta característica de implementación permite que el cliente y el servidor reutilicen los mismos números de puerto para restablecer con éxito la misma conexión, siempre y cuando el servidor no la haya cerrado activamente. Veremos otro ejemplo del estado de espera de 2MSL en cuando analicemos FTP. Consulte también este capítulo.

Concepto de tiempo tranquilo

El estado de espera 2MSL brinda protección contra paquetes tardíos que pertenecen a conexiones anteriores para que no se interpreten como parte de una nueva conexión que utiliza las mismas direcciones IP y números de puerto locales y remotos. Sin embargo, esto sólo funciona si el host con la conexión en estado 2MSL no ha fallado.

¿Qué pasa si un host con puertos en el estado 2MSL falla, se reinicia durante MSL e inmediatamente establece nuevas conexiones usando las mismas direcciones IP locales y remotas y números de puerto correspondientes a los puertos locales que estaban en el estado 2MSL antes de la falla? En este caso, los segmentos tardíos de una conexión que existía antes del error pueden malinterpretarse como pertenecientes a una nueva conexión creada después del reinicio. Esto puede ocurrir independientemente del número de secuencia inicial que se seleccione después de reiniciar.

Para protegerse contra escenarios no deseados, RFC 793 especifica que TCP no debe crear nuevas conexiones hasta que el MSL caduque después del tiempo de inicio. A esto se le llama tiempo de tranquilidad.

En algunas implementaciones, los hosts esperan incluso más que el tiempo MSL después de un reinicio.

Estado WAIT_AND_CONFIRMATION_FIN (FIN_WAIT_2)

En el estado FIN_WAIT_2 enviamos nuestro FIN y la parte remota lo reconoce. Si no estamos en un estado de conexión medio cerrada, esperamos que la aplicación en el extremo remoto reconozca que se ha recibido el final del archivo, cierre su lado de la conexión y nos envíe un FIN. Solo cuando el proceso en el extremo remoto realice este cierre, nuestro extremo cambiará del modo FIN_WAIT_2 al modo TIME_WAIT.

Esto significa que nuestro lado de la conexión puede permanecer en este modo para siempre. El lado remoto todavía está en el estado CLOSE_WAIT y puede permanecer en ese estado para siempre hasta que la aplicación decida cerrarse.

La mayoría de las implementaciones de Berkeley evitan este tipo de espera para siempre en el estado FIN_WAIT_2 de la siguiente manera. Si la aplicación que realizó el cierre activo realizó un cierre completo en lugar de un cierre medio, lo que indica que está esperando recibir datos, entonces se configura un temporizador. Si la conexión está inactiva durante 10 minutos más 75 segundos, TCP coloca la conexión en modo CERRADO. Los comentarios afirman que dicha característica es incompatible con la especificación del protocolo.

Restablecer segmentos

Mencionamos que hay un bit en el encabezado TCP llamado RST, que significa reinicio. En general, TCP envía una señal de reinicio si los segmentos entrantes no pertenecen a la conexión especificada. (Usamos el término "conexión referenciada", que significa una conexión identificada por una dirección IP de destino y un número de puerto de destino, y una dirección IP de origen y un número de puerto de origen. En RFC 793, esto se denomina "socket".)

Solicitud de conexión en un puerto inexistente

El caso más común en el que se genera un reset es cuando llega una solicitud de conexión y no hay ningún proceso escuchando en el puerto de destino. En el caso de UDP, como vimos en la sección del Capítulo 6, si un datagrama llega a un puerto de destino no utilizado, se genera un error de puerto ICMP inalcanzable. TCP usa reset en su lugar.

Daremos un ejemplo simple usando un cliente Telnet, especificando un número de puerto que no se usa en el destino:

bsdi % telnet svr4 20000 El puerto 20000 no se utiliza.
Probando 140.252.13.34...
Telnet: No se puede conectar al host remoto: Conexión rechazada

Se informa inmediatamente un mensaje de error al cliente Telnet. La Figura 18.14 muestra el intercambio de paquetes correspondiente a este comando.

1 0,0 bsdi.1087 > svr4.20000: S 297416193:297416193(0)
ganar 4096
2 0.003771 (0.0038) svr4.20000 > bsdi.1087: R 0:0 (0) ack 297416194 ganar 0

Figura 18.14 Generando un reset al intentar abrir una conexión a un puerto inexistente.

Los valores que debemos observar con más detalle en esta figura son el campo de número de secuencia y el campo de número de reconocimiento en el reinicio. Dado que el bit de confirmación (ACK) no se estableció en el segmento de llegada, el número de secuencia de reinicio se establece en 0 y el número de confirmación se establece en el número de secuencia inicial (ISN) entrante más el número de bytes de datos en el segmento. Aunque no hay datos reales presentes en el segmento de llegada, el bit SYN lógicamente ocupa 1 byte en el espacio de números de secuencia; Por lo tanto, en este ejemplo, el número de confirmación en el reinicio se establece en ISN más la longitud de los datos (0) más un bit SYN.

Desconexión

En una sección de este capítulo, vimos que el método habitual utilizado para terminar una conexión es que una de las partes envíe un FIN. Esto a veces se denomina liberación ordenada porque el FIN se envía después de que se hayan enviado todos los datos previamente en cola y, por lo general, no se produce ninguna pérdida de datos. Sin embargo, es posible finalizar la conexión enviando un reinicio en lugar de un FIN. A esto a veces se le llama liberación abortiva.

Este tipo de terminación de la conexión le da a la aplicación dos opciones: (1) todos los datos en la cola se pierden y se envía un reinicio inmediatamente, y (2) la parte que recibe el RST puede decir que la parte remota ha cerrado la conexión, en lugar de cerrándolo normalmente. La interfaz de programación de aplicaciones (API) utilizada por la aplicación debe proporcionar una manera de generar dicho reinicio en lugar de un apagado normal.

Podemos ver qué sucede cuando ocurre una rotura como esta usando nuestro programa de calcetines. La API de sockets proporciona esta capacidad utilizando la opción de permanecer al cerrar el socket (SO_LINGER). Especificamos la opción -L con un tiempo de retraso de 0. Esto significa que en lugar del FIN normal, se enviará un reinicio para cerrar la conexión. Nos conectaremos a la versión del servidor del programa sock en svr4:

bsdi % calcetín -L0 svr4 8888 este es el cliente; el servidor se muestra a continuación
Hola Mundo ingrese una línea que será enviada al extremo remoto
^D ingrese el carácter de fin de archivo para apagar el cliente

La Figura 18.15 muestra el resultado del comando tcpdump para este ejemplo. (Hemos eliminado todas las declaraciones de ventana en esta figura ya que no afectan nuestro razonamiento).

1 0,0 bsdi.1099 > svr4.8888: S 671112193:671112193(0)

2 0,004975 (0,0050) svr4,8888 > bsdi.1099: S 3224959489:3224959489(0)
ack 671112194
3 0,006656 (0,0017) bsdi.1099 > svr4.8888: . ack 1
4 4.833073 (4.8264) bsdi.1099 > svr4.8888: P 1:14 (13) reconocimiento 1
5 5.026224 (0.1932) svr4.8888 > bsdi.1099: . responder 14
6 9.527634 (4.5014) bsdi.1099 > svr4.8888: R 14:14 (0) reconocimiento 1

Figura 18.15 Terminar una conexión usando reset (RST) en lugar de FIN.

Las líneas 1 a 3 muestran la configuración de conexión normal. La línea 4 envía la cadena de datos que imprimimos (12 caracteres más la nueva línea de Unix) y la línea 5 recibe un acuse de recibo de que se recibieron los datos.

La línea 6 corresponde a la entrada de fin de archivo (Control-D) que usamos para apagar el cliente. Dado que especificamos una interrupción en lugar de un cierre normal (opción de línea de comando -L0), TCP en bsdi enviará un RST en lugar del FIN habitual. El segmento RST contiene el número de secuencia y el número de confirmación. También tenga en cuenta que el segmento RST no espera una respuesta del extremo remoto; no contiene ningún reconocimiento. El destinatario del reinicio finaliza la conexión e informa a la aplicación que la conexión ha finalizado.

Recibiremos el siguiente error del servidor con dicho intercambio:

rvs4% calcetín -s 8888 ejecutar como servidor, escuchar el puerto 8888
hola mundo esto es lo que envió el cliente
error de lectura: conexión restablecida por igual

Este servidor lee de la red y copia todo lo que recibe en la salida estándar. Normalmente sale después de recibir una señal de fin de archivo de su TCP, sin embargo aquí vemos que recibió un error cuando llegó el RST. El error es exactamente lo que esperábamos: uno de los participantes cerró la conexión.

Definición de una conexión medio abierta

Una conexión TCP se considera medio abierta si un lado ha cerrado o finalizado la conexión sin notificar al otro lado. Esto puede suceder en cualquier momento si falla uno de los dos hosts. Dado que no habrá intentos de transmitir datos a través de una conexión medio abierta durante algún tiempo, una de las partes trabajará hasta que determine que la parte remota ha fallado.

Otra razón por la que puede ocurrir una conexión medio abierta es que el host del cliente se apagó en lugar de cerrar la aplicación del cliente y luego apagar la computadora. Esto sucede cuando, por ejemplo, se inicia un cliente Telnet en una PC y los usuarios apagan la computadora al final de la jornada laboral. Si no se estaban transfiriendo datos cuando se apagó la PC, el servidor nunca sabrá que el cliente ha desaparecido. Cuando el usuario llega a la mañana siguiente, enciende su PC e inicia un nuevo cliente Telnet, se inicia un nuevo servidor en el host del servidor. Debido a esto, pueden aparecer muchas conexiones TCP abiertas en el host del servidor. (En veremos una manera en la que un extremo de una conexión TCP puede determinar que el otro ha desaparecido. Esto se hace usando la opción TCP "keepalive".)

Podemos crear fácilmente una conexión medio abierta. Lanzamos el cliente Telnet en bsdi y nos conectamos al servidor de descarte en svr4. Ingresamos una línea y usamos tcpdump para ver cómo va, luego desconectamos el cable Ethernet del host del servidor y lo reiniciamos. Al hacer esto, simulamos la falla del servidor. (Desconectamos el cable Ethernet antes de reiniciar el servidor para evitar que envíe FIN en una conexión abierta, lo que hacen algunos módulos TCP cuando se apagan). Después de reiniciar el servidor, reconectamos el cable e intentamos enviar otra línea desde el cliente al servidor. Debido a que el servidor se reinició y perdió todos los datos de conexión que existían antes del reinicio, no sabe nada acerca de las conexiones y no sabe a qué conexión pertenecen los segmentos que llegan. En este caso, el lado TCP receptor responde con un reinicio.

bsdi % telnet svr4 descartar lanzamiento del cliente
Probando 140.252.13.34...
Conectado a svr4.
El carácter de escape es "^]".
hola esta línea se envía normalmente
en este punto reiniciamos el servidor host
otra linea se realizó un reinicio en esta ubicación
Conexión cerrada por host extranjero.

La Figura 18.16 muestra la salida de tcpdump para este ejemplo. (Hemos eliminado las declaraciones de ventana, la información del tipo de servicio y las declaraciones MSS del resultado, ya que no afectan nuestro razonamiento).

1 0,0 bsdi.1102 > svr4.discard: S 1591752193:1591752193(0)
2 0,004811 (0,0048) svr4.discard > bsdi.1102: S 26368001:26368001(0)
ack 1591752194
3 0,006516 (0,0017) bsdi.1102 > svr4.discard: . ack 1

4 5.167679 (5.1612) bsdi.1102 > svr4.discard: P 1:11 (10) ack 1
5 5.201662 (0.0340) svr4.discard > bsdi.1102: . responder 11

6 194.909929 (189.7083) bsdi.1102 > svr4.discard: P 11:25 (14) ack 1
7 194.914957 (0.0050) arp quién tiene bsdi tell svr4
8 194.915678 (0.0007) respuesta arp bsdi is-at 0:0:c0:6f:2d:40
9 194.918225 (0.0025) svr4.discard > bsdi.1102: R 26368002:26368002(0)

Figura 18.16 Restablecimiento en respuesta a la llegada de un segmento de datos con una conexión medio abierta.

Las líneas 1 a 3 realizan el establecimiento de conexión normal. En la línea 4, se envía la cadena "hola" (esto se puede traducir aproximadamente como "hola, ahí") al servidor de descarte, en la línea 5 se recibe una confirmación.

En este punto desconectamos el cable Ethernet del svr4, lo reiniciamos y volvemos a conectar el cable. Todo el procedimiento duró aproximadamente 190 segundos. Luego imprimimos la siguiente línea de entrada en el cliente ("otra línea"), y cuando presionamos Retorno, la línea se envió al servidor (línea 6 en la Figura 18.16). Al mismo tiempo, se recibió una respuesta del servidor, sin embargo, desde que se reinició el servidor, su caché ARP está vacía, por lo que en las líneas 7 y 8 vemos la solicitud y respuesta ARP. Luego se envió un reinicio en la línea 9. El cliente recibió un reinicio e informó que el host remoto terminó la conexión. (El último mensaje de salida del cliente Telnet no es tan informativo como podría ser).

Apertura simultánea

Es posible que dos aplicaciones se abran activamente al mismo tiempo. Se debe enviar un SYN desde cada lado y estos SYN deben viajar a través de la red uno hacia el otro. También requiere que cada lado tenga un número de puerto que el otro lado conozca. Esto se llama apertura simultánea.

Por ejemplo, una aplicación en el host A con el puerto local 7777 se abre activamente en el puerto 8888 del host B. Una aplicación en el host B con el puerto local 8888 se abre activamente en el puerto 7777 del host A.

Esto no es lo mismo que conectar un cliente Telnet del Host A a un servidor Telnet en el Host B, mientras que un cliente Telnet del Host B se conecta a un servidor Telnet en el Host A. En este escenario, ambos servidores Telnet realizan una apertura pasiva en lugar de una apertura pasiva. uno activo, mientras que los clientes Telnet se asignan a sí mismos números de puerto asignados dinámicamente, en lugar de puertos que los servidores Telnet remotos conocen de antemano.

TCP está diseñado específicamente para manejar aperturas simultáneas, lo que da como resultado una conexión en lugar de dos. (En otras familias de protocolos, como la capa de transporte OSI, esto crea dos conexiones en lugar de una).

Cuando ocurre un descubrimiento simultáneo, los cambios de estado del protocolo son diferentes de los que se muestran en la Figura 18.13. Ambos extremos envían SYN al mismo tiempo, ingresando al estado SYN_SENT. Cuando cada extremo recibe el SYN, el estado cambia a SYN_RECEIVED (SYN_RCVD) (consulte la Figura 18.12) y cada extremo reenvía el SYN con un reconocimiento de que se ha recibido el SYN. Cuando cada extremo recibe un SYN más un ACK, el estado cambia a ESTABLECIDO. Los cambios de estado se muestran en la Figura 18.17.

Figura 18.17 Intercambio de segmentos durante la apertura simultánea.

La apertura simultánea requiere el intercambio de cuatro segmentos, uno más que un "tres apretones de manos". También tenga en cuenta que no llamamos a un extremo cliente y al otro servidor, porque en este caso ambos actúan como cliente y servidor.

Es posible realizar una apertura simultánea, pero es bastante complicado. Ambos lados deben comenzar aproximadamente al mismo tiempo, de modo que los SYN se superpongan entre sí. En este caso, un tiempo de retorno prolongado entre los dos participantes en la conexión puede ayudar, permitiendo que el SYN se superponga. Para lograr esto, utilizamos el host bsdi como una de las partes de la conexión y el host vangogh.cs.berkeley.edu como la otra parte. Dado que hay un canal SLIP de acceso telefónico entre ellos, el tiempo de retorno debe ser bastante largo (varios cientos de milisegundos) para permitir que SYN se superponga.

Un extremo (bsdi) se asigna el puerto local 8888 (opción de línea de comando -b) y se abre activamente al puerto 7777 del otro host:

bsdi % calcetín -v -b8888 vangogh.cs.berkeley.edu 7777
conectado al 140.252.13.35.8888 al 128.32.130.2.7777
TCP_MAXSEG = 512
Hola Mundo ingresa esta línea
y hola esta línea estaba impresa en el otro extremo
conexión cerrada por par esta es la salida cuando se recibió FIN

El otro extremo se inició aproximadamente al mismo tiempo, se asignó un número de puerto local de 7777 y realizó una apertura activa al puerto 8888:

vangogh% calcetín -v -b7777 bsdi.tuc.noao.edu 8888
conectado al 128.32.130.2.7777 al 140.252.13.35.8888
TCP_MAXSEG = 512
hola mundo esto se entra por el otro extremo
y hola imprimimos esta línea
^D y luego ingresó el carácter de fin de archivo EOF

Especificamos el indicador -v en la línea de comando de sock para verificar las direcciones IP y los números de puerto para cada extremo de las conexiones. Este indicador también imprime el MSS utilizado en cada extremo de la conexión. También imprimimos una línea como entrada en cada extremo, que se envió al extremo remoto y se imprimió allí para asegurarnos de que ambos hosts se "vean" entre sí.

La Figura 18.18 muestra el intercambio de segmentos para esta conexión. (Hemos eliminado algunas opciones TCP nuevas que aparecían en los SYN originales que vinieron de Vangogh, que ejecuta 4.4BSD. Describiremos estas nuevas opciones en una sección de este capítulo). Tenga en cuenta que los dos SYN (líneas 1 y 2) van seguidos de dos SYN con ACK (líneas 3 y 4). En este caso se produce una apertura simultánea.

La línea 5 muestra la cadena ingresada "hola, mundo" que va de bsdi a vangogh con confirmación en la línea 6. Las líneas 7 y 8 corresponden a la cadena "y hola" que va en la otra dirección. Las líneas 9 a 12 muestran un cierre de conexión normal.

La mayoría de las implementaciones de Berkeley no admiten correctamente la apertura simultánea. En estos sistemas, si puedes lograr que los SYN se superpongan, terminarás intercambiando segmentos, cada uno con un SYN y un ACK, en ambas direcciones. La mayoría de las implementaciones no siempre realizan la transición del estado SYN_SENT al estado SYN_RCVD que se muestra en la Figura 18.12.

1 0.0 bsdi.8888 > vangogh.7777: S 91904001:91904001(0)
ganar 4096
2 0,213782 (0,2138) vangogh.7777 > bsdi.8888: S 1058199041:1058199041(0)
ganar 8192
3 0,215399 (0,0016) bsdi.8888 > vangogh.7777: S 91904001:91904001(0)
confirmar 1058199042 ganar 4096

4 0,340405 (0,1250) vangogh.7777 > bsdi.8888: S 1058199041:1058199041(0)
confirmar 91904002 ganar 8192

5 5.633142 (5.2927) bsdi.8888 > vangogh.7777: P 1:14 (13) ack 1 victoria 4096
6 6.100366 (0.4672) vangogh.7777 > bsdi.8888: . ack 14 ganar 8192

7 9.640214 (3.5398) vangogh.7777 > bsdi.8888: P 1:14 (13) ack 14 win 8192
8 9.796417 (0.1562) bsdi.8888 > vangogh.7777: . ack 14 ganar 4096

9 13.060395 (3.2640) vangogh.7777 > bsdi.8888: F 14:14 (0) ack 14 win 8192
10 13.061828 (0.0014) bsdi.8888 > vangogh.7777: . ack 15 ganar 4096
11 13.079769 (0.0179) bsdi.8888 > vangogh.7777: F 14:14 (0) ack 15 win 4096
12 13.299940 (0.2202) vangogh.7777 > bsdi.8888: . reconocer 15 ganar 8192

Figura 18.18 Intercambio de segmentos durante la apertura simultánea.

Cierre simultáneo

Como dijimos anteriormente, en un lado (a menudo, pero no siempre, el lado del cliente) se realiza un cierre activo y se envía el primer FIN. También es posible que ambas partes realicen un cierre activo, ya que TCP permite cierres simultáneos.

En términos de la Figura 18.12, ambos extremos pasan del estado ESTABLECIDO al estado FIN_WAIT_1 cuando la aplicación indica que se debe cerrar. Al mismo tiempo, ambos envían FIN, que puede encontrarse en algún lugar de la red. Cuando se recibe FIN, cada extremo pasa del estado FIN_WAIT_1 al estado CLOSING y envía un ACK final desde cada extremo. Cuando cada extremo recibe el ACK final, el estado cambia a TIME_WAIT. La figura 18.19 muestra los cambios de estado.

Figura 18.19 Intercambio de segmentos durante el cierre simultáneo.

Con el cierre simultáneo se intercambia el mismo número de paquetes que con el cierre normal.

El encabezado TCP puede contener opciones (). Las únicas opciones definidas en la especificación TCP original son: fin de la lista de opciones, ninguna operación y tamaño máximo de segmento. Vimos en nuestros ejemplos la opción MSS en casi todos los segmentos SYN.

Los RFC más nuevos, como el RFC 1323, definen opciones TCP adicionales, la mayoría de las cuales solo se encuentran en implementaciones posteriores. (Describiremos las nuevas opciones en .) La Figura 18.20 muestra el formato de las opciones TCP actuales, las descritas en RFC 793 y RFC 1323.

Figura 18.20 Opciones de TCP.

Cada opción comienza con un tipo de 1 byte (kind), que indica el tipo de opción. Las opciones cuyo tipo es 0 y 1 ocupan 1 byte. Otras opciones tienen una longitud de (len) bytes que sigue al byte de tipo. La longitud es la longitud total, incluidos los bytes de tipo y longitud.

Se agregó una opción Sin operación (NOP) para permitir que el remitente complete campos que deben ser múltiplos de 4 bytes. Si establecemos una conexión TCP desde un sistema 4.4BSD, en el segmento SYN inicial se pueden ver las siguientes opciones usando tcpdump:

La opción MSS está configurada en 512, seguida de NOP y luego la opción de tamaño de ventana. La primera opción NOP se utiliza para rellenar la opción de tamaño de ventana de 3 bytes a 4 bytes. De manera similar, una opción de marca de tiempo de 10 bytes está precedida por dos NOP para ocupar 12 bytes.

Las otras cuatro opciones, que tienen un tipo de 4, 5, 6 y 7, se denominan opciones ACK selectivas y opciones de eco. No los hemos mostrado en la Figura 18.20 porque la opción de eco ha sido reemplazada por una opción de marca de tiempo, y los ACK selectivos, tal como se definen actualmente, aún están en discusión y no se incluyeron en RFC 1323. Cabe señalar que la propuesta T/TCP para transacciones TCP (sección del Capítulo 24) especifica tres opciones más con tipos iguales a 11, 12 y 13.

Implementación de un servidor TCP

En la sección del Capítulo 1, dijimos que la mayoría de los servidores TCP son concurrentes. Cuando llega una solicitud para establecer una nueva conexión al servidor, éste acepta la conexión e inicia un nuevo proceso que atenderá al nuevo cliente. Dependiendo del sistema operativo, se utilizan diferentes métodos para crear un nuevo servidor. En los sistemas Unix, se crea un nuevo proceso utilizando la función fork.

Necesitamos discutir cómo interactúa TCP con servidores concurrentes. Me gustaría responder la siguiente pregunta: ¿cómo se procesan los números de puerto cuando el servidor recibe una solicitud de una nueva conexión de un cliente y qué sucede si llegan varias solicitudes de conexión al mismo tiempo?

Números de puerto del servidor TCP

Podemos saber cómo TCP maneja los números de puerto mirando cualquier servidor TCP. Veamos un servidor Telnet usando el comando netstat. El siguiente resultado es para sistemas que no tienen conexiones Telnet activas. (Hemos eliminado todas las líneas excepto la que muestra el servidor Telnet).

sol% netstat -a -n -finet
Conexiones activas a Internet (incluidos servidores)
Proto Recv-Q Send-Q Dirección local Dirección extranjera (estado)
tcp 0 0 *.23 *.* ESCUCHA

El indicador -a informa sobre todos los puntos finales de la red, no solo aquellos en el estado ESTABLECIDO. El indicador -n imprime direcciones IP en notación decimal numérica en lugar de usar DNS para convertir direcciones en nombres, e imprime números de puerto numéricos (como 23) en lugar de imprimir nombres de servicios (en este caso Telnet). La opción -finet informa solo puntos finales TCP y UDP.

La dirección local se genera como *.23, donde el asterisco normalmente se denomina comodín o metacarácter. Esto significa que se aceptará una solicitud de conexión entrante (SYN) desde cualquier interfaz local. Si un host tiene múltiples interfaces, podríamos especificar una dirección IP específica como la dirección IP local (una de las direcciones IP del host), y solo se atenderán las solicitudes de conexión aceptadas desde esa interfaz. (Veremos cómo se hace esto más adelante en esta sección). El puerto local es 23, que es un puerto conocido para Telnet.

La dirección remota se muestra como *.*, lo que significa que la dirección IP remota y el número de puerto remoto aún no se conocen porque el punto final está en estado ESCUCHA, esperando que llegue la solicitud de conexión.

Ahora estamos iniciando un cliente Telnet en el host slip (140.252.13.65), que se conectará a este servidor. Aquí están las líneas de salida correspondientes del comando netstat:

tcp 0 0 140.252.13.33.23 140.252.13.65.1029 ESTABLECIDO
tcp 0 0 *.23 *.* ESCUCHA

La primera línea para el puerto 23 es la conexión establecida (ESTABLECIDA). Para esta conexión, se completan los cuatro elementos de las direcciones local y remota: la dirección IP local y el número de puerto, y la dirección IP remota y el número de puerto. La dirección IP local corresponde a la interfaz a la que llegó la solicitud de conexión (interfaz Ethernet, 140.252.13.33).

El punto final permaneció en el estado LISTEN. Este es el punto final que utiliza el servidor concurrente para aceptar solicitudes de conexión que llegarán en el futuro. En este caso, el módulo TCP que reside en el kernel creó un nuevo punto final en el estado ESTABLECIDO cuando llegó y fue aceptada la solicitud de conexión entrante. Tenga en cuenta también que el número de puerto para una conexión que está en estado ESTABLECIDO no ha cambiado: es 23, el mismo que para un punto final que está en estado ESCUCHA.

Ahora estamos iniciando otro cliente Telnet desde el mismo cliente (resbalón) en este servidor. La salida correspondiente del comando netstat se vería así:

Proto Recv-Q Send-Q Dirección local Dirección extranjera (estado)
tcp 0 0 140.252.13.33.23 140.252.13.65.1030 ESTABLECIDO
tcp 0 0 140.252.13.33.23 140.252.13.65.1029 ESTABLECIDO
tcp 0 0 *.23 *.* ESCUCHA

Ahora vemos dos conexiones establecidas (ESTABLECIDAS) desde el mismo host al mismo servidor. Ambos tienen un número de puerto local de 23. Esto no es un problema para TCP, ya que los números de puerto remoto son diferentes. Deben ser diferentes porque cada cliente Telnet usa un puerto asignado dinámicamente, y por la definición de un puerto asignado dinámicamente sabemos que solo un puerto que no está actualmente en uso en el host (slip) puede asignarse dinámicamente.

Este ejemplo muestra que TCP demultiplexa los segmentos entrantes utilizando los cuatro valores que se comparan con las direcciones local y remota: dirección IP de destino, número de puerto de destino, dirección IP de origen y número de puerto de origen. TCP no puede determinar qué proceso recibió el segmento entrante mirando solo el número de puerto de destino. Además, solo uno de los tres puntos finales en el puerto 23, que está en estado LISTEN, acepta solicitudes de conexión entrantes. Los puntos finales en el estado ESTABLECIDO no pueden recibir segmentos SYN y un punto final en el estado LISTEN no puede recibir segmentos de datos.

Ahora estamos iniciando otro cliente Telnet desde el host Solaris, que irá a través del canal SLIP de Sun, en lugar de a través de Ethernet.

Proto Recv-Q Send-Q Dirección local Dirección extranjera (estado)
tcp 0 0 140.252.1.29.23 140.252.1.32.34603 ESTABLECIDO
tcp 0 0 140.252.13.33.23 140.252.13.65.1030 ESTABLECIDO
tcp 0 0 140.252.13.33.23 140.252.13.65.1029 ESTABLECIDO
tcp 0 0 *.23 *.* ESCUCHA

La dirección IP local para la primera conexión establecida (ESTABLECIDA) ahora coincide con la dirección de la interfaz del canal SLIP en el host de interfaz múltiple Sun (140.252.1.29).

Limitar las direcciones IP locales

Podemos ver lo que sucede cuando el servidor no utiliza comodines como direcciones IP locales, sino que establece una dirección de interfaz local específica. Si proporcionamos una dirección IP (o nombre de host) a nuestro programa sock cuando lo usamos como servidor, esa dirección IP se convierte en la dirección IP local del punto final de escucha. Por ejemplo

sol% calcetín -s 140.252.1.29 8888

restringe este servidor solo a conexiones provenientes de la interfaz SLIP (140.252.1.29). La salida del comando netstat mostrará lo siguiente:

Proto Recv-Q Send-Q Dirección local Dirección extranjera (estado)

Si nos conectamos a este servidor mediante un canal SLIP desde el host solaris, funcionará.

Proto Recv-Q Send-Q Dirección local Dirección extranjera (estado)
tcp 0 0 140.252.1.29.8888 140.252.1.32.34614 ESTABLECIDO
tcp 0 0 140.252.1.29.8888 *.* ESCUCHA

Sin embargo, si intentamos conectarnos a este servidor desde el host a través de Ethernet (140.252.13), el módulo TCP no aceptará la solicitud de conexión. Si miramos usando tcpdump, veremos que se recibe una respuesta RST en SYN, como se muestra en la Figura 18.21.

1 0,0 bsdi.1026 > sol.8888: S 3657920001:3657920001(0)
ganar 4096
2 0.000859 (0.0009) sun.8888 > bsdi.1026: R 0:0 (0) ack 3657920002 win 0

Figura 18.21 Limitación de solicitudes de conexión según la dirección IP local del servidor.

Una aplicación que se ejecuta en el servidor nunca verá una solicitud de conexión; la restricción la lleva a cabo el módulo TCP en el kernel en función de la dirección IP local especificada por la aplicación.

Restricción de dirección IP remota

En la sección del Capítulo 11, vimos que un servidor UDP puede determinar una dirección IP remota y un número de puerto, además de la dirección IP local y el número de puerto especificados. Las funciones de interfaz especificadas en RFC 793 permiten que el servidor realice una apertura pasiva basada en un socket remoto completamente especificado (en cuyo caso se espera una solicitud de apertura activa de un cliente específico) o un socket remoto no especificado (en cuyo caso se espera una solicitud de conexión de Se espera cualquier cliente).

Desafortunadamente, la mayoría de las API no ofrecen dichas capacidades. El servidor debe dejar el socket remoto sin instancias, esperando que llegue una conexión y luego verificando la dirección IP y el número de puerto del cliente.

La figura 18.22 muestra los tres tipos de direcciones y las relaciones dirección-puerto que un servidor TCP puede establecer por sí mismo. En todos los casos, lport es el puerto conocido del servidor y localIP debe ser la dirección IP de la interfaz local. El orden en que aparecen las tres filas en la tabla corresponde al orden en el que el módulo TCP intenta determinar qué punto final local aceptará una solicitud de conexión entrante. Primero se prueba la primera fila de la tabla (si se admite) y luego se prueban en último lugar las especificaciones restantes (la última fila con direcciones IP especificadas como comodines).

Figura 18.22 Especificación de direcciones IP y números de puerto locales y remotos para el servidor TCP.

Cola de solicitud de conexión entrante

Un servidor concurrente inicia un nuevo proceso que atiende a cada cliente, por lo que el servidor de escucha siempre debe estar listo para manejar la siguiente solicitud de conexión entrante. Ésta es la razón principal por la que se utilizan servidores competitivos. Sin embargo, es posible que lleguen varias solicitudes de conexión justo cuando el servidor de escucha está creando un nuevo proceso o mientras el sistema operativo está ocupado procesando otro proceso de mayor prioridad. ¿Cómo maneja TCP estas solicitudes de conexión entrantes mientras la aplicación de escucha está ocupada?

Las implementaciones de Berkeley utilizan las siguientes reglas.

Cada punto final de escucha tiene una cola de conexiones de longitud fija que puede ser aceptada por TCP (el "apretón de enlace tres veces" está completo) pero que aún no ha sido aceptada por la aplicación. Tenga cuidado de distinguir entre aceptar una conexión TCP y colocarla en una cola, y una aplicación que acepta conexiones de esa cola.
La aplicación especifica un límite o límite para esta cola, lo que generalmente se denomina trabajo pendiente. Este límite debe estar en el rango de 0 a 5. (La mayoría de las aplicaciones especifican un valor máximo de 5).
Cuando llega una solicitud de conexión (segmento SYN), TCP analiza la cantidad actual de conexiones actualmente en cola para ese punto final de escucha y determina si la conexión puede aceptarse. Esperamos que el valor de backlog especificado por la aplicación sea el máximo, es decir, el número máximo de conexiones permitidas en cola para ese punto, aunque esto no es muy sencillo. La Figura 18.23 muestra la relación entre el valor del trabajo pendiente y el número máximo real de conexiones que se pueden poner en cola en los sistemas tradicionales de Berkeley y Solaris 2.2.

valor del trabajo pendiente

Número máximo de conexiones en cola

BSD tradicional

Figura 18.23 Número máximo de conexiones aceptadas para un punto final de escucha.

Recuerde que este valor de acumulación solo indica la cantidad máxima de conexiones en cola para un único punto final de escucha, todas las cuales ya han sido aceptadas por TCP y están esperando ser aceptadas por la aplicación. El valor del trabajo pendiente no tiene ningún efecto sobre la cantidad máxima de conexiones que puede establecer el sistema o la cantidad de clientes que un servidor simultáneo puede atender.

Los valores de Solaris en esta figura son exactamente los que esperaríamos. Los valores tradicionales para BSD (por alguna razón desconocida) son iguales al valor del trabajo pendiente multiplicado por 3 dividido por 2 más 1.
Si hay espacio en la cola para un punto final de escucha determinado para una nueva conexión (consulte la Figura 18.23), el módulo TCP reconoce (ACK) el SYN entrante y establece la conexión. La aplicación del servidor con el punto final de escucha no verá esta nueva conexión hasta que se reciba el tercer segmento del "apretón de enlace tres veces". Alternativamente, el cliente puede considerar que el servidor está listo para aceptar datos cuando la apertura activa del cliente se haya completado exitosamente, antes de que se notifique a la aplicación del servidor sobre la nueva conexión. (Si esto sucede, el servidor TCP simplemente pondrá en cola los datos entrantes).
Si no hay suficiente espacio para poner en cola una nueva conexión, TCP simplemente ignora el SYN recibido. No se envía nada en respuesta (ni siquiera se envía el segmento RST). Si el servidor de escucha no puede negarse a aceptar algunas conexiones ya aceptadas que han llenado la cola hasta su capacidad, la apertura activa del cliente expirará.

Podemos ver este script usando el programa sock. Ejecutémoslo con una nueva opción (-O) que nos indica que hagamos una pausa después de crear un punto final de escucha, antes de aceptar cualquier solicitud de conexión. Si luego iniciamos varios clientes durante esta pausa, el servidor se verá obligado a poner en cola las conexiones aceptadas y veremos qué sucede usando el comando tcpdump.

bsdi % calcetín -s -v -q1 -O30 5555

La opción -q1 establece el trabajo pendiente del punto final de escucha en 1, lo que en un sistema BSD tradicional correspondería a dos solicitudes de conexión (Figura 18.23). La opción -O30 hace que el programa entre en "suspensión" durante 30 segundos antes de aceptar cualquier conexión del cliente. Esto nos da 30 segundos para iniciar algunos clientes que llenarán la cola. Estamos iniciando cuatro clientes en Host Sun.

La Figura 18.24 muestra la salida del programa tcpdump, esta salida comienza con el primer SYN del primer cliente. (Hemos eliminado las declaraciones de tamaño de ventana y las declaraciones de MSS. También hemos resaltado los números de puerto del cliente en negrita cuando se establece una conexión TCP: un "apretón de manos tres veces").

La primera solicitud de conexión del cliente, proveniente del puerto 1090, es recibida por el módulo TCP (segmentos 1-3). El módulo TCP también acepta la segunda solicitud de conexión del cliente en el puerto 1091 (segmentos 4-6). La aplicación del servidor todavía está inactiva y no ha aceptado ninguna conexión. Todo lo realizado lo realizó el módulo TCP en el kernel. También cabe señalar que dos clientes realizaron con éxito una apertura activa, es decir, el "apretón de manos tres veces" se completó con éxito.

1 0,0 sol. 1090 > bsdi.7777: S 1617152000:1617152000(0)
2 0,002310 (0,0023) bsdi.7777 > sol. 1090 : S 4164096001:4164096001(0)
3 0,003098 (0,0008) sol. 1090 >bsdi.7777: . ack 1617152001
ack 1
4 4.291007 (4.2879) sol. 1091 > bsdi.7777: S 1617792000:1617792000(0)
5 4.293349 (0.0023) bsdi.7777 > dom. 1091 : S 4164672001:4164672001(0)
ack 1617792001
6 4,294167 (0,0008) sol. 1091 >bsdi.7777: . ack 1
7 7.131981 (2.8378) sol.1092 >
8 10.556787 (3.4248) sol.1093 > bsdi.7777: S 1618688000:1618688000(0)
9 12.695916 (2.1391) sol.1092 > bsdi.7777: S 1618176000:1618176000(0)
10 16.195772 (3.4999) sol.1093 >
11 24.695571 (8.4998) sol.1092 > bsdi.7777: S 1618176000:1618176000(0)
12 28.195454 (3.4999) sol. 1093 > bsdi.7777: S 1618688000:1618688000(0)
13 28.197810 (0.0024) bsdi.7777 > dom. 1093 : S 4167808001:4167808001(0)
14 28,198639 (0,0008) sol. 1093 >bsdi.7777: . ack 1618688001
ack 1
15 48.694931 (20.4963) sol. 1092 > bsdi.7777: S 1618176000:1618176000(0)
16 48.697292 (0.0024) bsdi.7777 > sol. 1092 : S 4170496001:4170496001(0)
ack 1618176001
17 48,698145 (0,0009) sol. 1092 >bsdi.7777: . ack 1

Figura 18.24 Salida de tcpdump para ver un ejemplo de uso del trabajo pendiente.

Intentamos iniciar un tercer cliente en el segmento 7 (puerto 1092) y un cuarto en el segmento 8 (puerto 1093). TCP ignoró ambos SYN porque la cola para ese punto final de escucha estaba llena. Ambos clientes retransmitieron sus SYN en los segmentos 9, 10, 11, 12 y 15. Se acepta la tercera retransmisión del cuarto cliente (segmentos 12-14) porque la pausa de 30 segundos del servidor finalizó y el servidor interrumpió dos conexiones que fueron aceptadas. .limpiar la cola. (La razón por la que esto sucedió es que esta conexión fue aceptada por el servidor en el momento 28.19, y no en un momento mayor que 30; esto sucedió porque tomó unos segundos iniciar el primer cliente [segmento 1, hora de inicio en la salida] después del inicio del servidor.) También se recibe la cuarta retransmisión del tercer cliente (segmentos 15-17). El servidor acepta la conexión del cuarto cliente (puerto 1093) antes que la conexión del tercer cliente (puerto 1092) debido al tiempo transcurrido entre el final del tiempo de espera de 30 segundos y la retransmisión del cliente.

Podríamos esperar que la aplicación procese la cola de conexiones aceptadas de acuerdo con el principio FIFO (primero en entrar, primero en salir). Por lo tanto, después de que TCP aceptó una aplicación en los puertos 1090 y 1091, esperaríamos que la aplicación recibiera una conexión primero en el puerto 1090 y luego una conexión en el puerto 1091. Sin embargo, hay un error en la mayoría de las implementaciones de Berkeley que resulta en el uso del orden LIFO. (el último en entrar, el primero en salir). Los fabricantes han intentado muchas veces corregir este error, pero todavía existe en sistemas como SunOS 4.1.3.

TCP ignora el SYN entrante cuando la cola está llena y no responde usando RST debido a un error. Normalmente, la cola está llena porque la aplicación o el sistema operativo está ocupado, por lo que la aplicación no puede procesar las conexiones entrantes. Esta condición puede cambiar en un corto período de tiempo. Sin embargo, si el servidor TCP respondió con un reinicio, la apertura activa del cliente se interrumpirá (esto es exactamente lo que sucederá si el servidor no se ha iniciado). Dado que se ignora el SYN, el cliente TCP se verá obligado a retransmitir el SYN más tarde, con la esperanza de que haya espacio en la cola para una nueva conexión.

Llegados a este punto es necesario comentar otro detalle muy importante, que está presente en casi todas las implementaciones TCP/IP. Es que TCP acepta una solicitud de conexión entrante (SYN) si hay espacio en la cola. En este caso, la aplicación no puede ver de quién proviene la solicitud (dirección IP de origen y número de puerto de origen). TCP no requiere esto, es solo una técnica general utilizada en las implementaciones. Si una API, como TLI (sección del Capítulo 1), notifica a una aplicación que ha llegado una solicitud de conexión y le permite elegir si acepta o no la conexión, entonces, cuando se usa TCP, ocurre que cuando la aplicación es Le dijeron que acaba de llegar una conexión, en realidad TCP ya ha completado el "apretón de manos tres veces". En otras capas de transporte, es posible distinguir entre conexiones entrantes y recibidas (capa de transporte OSI), pero TCP no proporciona esta característica.

Solaris 2.2 proporciona una opción que impide que TCP acepte una solicitud de conexión entrante hasta que la aplicación lo permita (tcp_eager_listeners en la sección E de la aplicación).

Este comportamiento también significa que el servidor TCP no puede provocar la interrupción de la apertura de un cliente activo. Cuando una conexión de un nuevo cliente llega a la aplicación del servidor, el "protocolo de enlace de tres vías" de TCP ya se ha completado y el descubrimiento activo del cliente se ha completado con éxito. Si el servidor luego mira la dirección IP y el número de puerto del cliente y decide que no quiere atender a ese cliente, todos los servidores pueden simplemente cerrar la conexión (lo que enviará un FIN) o restablecer la conexión (lo que enviará un RST). . En cualquier caso, el cliente asumirá que todo está bien con el servidor, ya que la apertura activa se ha completado y, muy posiblemente, ya haya enviado algún tipo de solicitud al servidor.

Breves conclusiones

Antes de que dos procesos puedan comunicarse mediante TCP, deben establecer una conexión entre sí. Cuando se complete el trabajo entre ellos, la conexión debe romperse. Este capítulo detalla cómo se establece una conexión mediante el "apretón de enlace de tres saltos" y cómo se interrumpe mediante el protocolo de enlace de cuatro saltos.

Usamos tcpdump para mostrar todos los campos en el encabezado TCP. También analizamos cómo se puede agotar el tiempo de espera de una conexión establecida, cómo se restablece una conexión, qué sucede con una conexión medio abierta y cómo TCP proporciona un modo medio cerrado, apertura y cierre simultáneos.

Para comprender el funcionamiento de TCP, es necesario considerar el diagrama de estado fundamental de TCP. Hemos analizado punto por punto cómo se establece y finaliza una conexión y qué cambios de estado se producen durante este proceso. También vimos cómo los servidores TCP establecen conexiones TCP.

Las conexiones TCP se identifican de forma única mediante 4 parámetros: dirección IP local, número de puerto local, dirección IP remota y número de puerto remoto. Si la conexión se interrumpe, un lado aún debe recordar la conexión, en cuyo caso decimos que el modo TIME_WAIT está vigente. La regla establece que esta parte puede realizar una apertura activa ingresando a este modo después de que haya expirado el doble del tiempo MSL aceptado para esta implementación.

Ceremonias

En la sección dijimos que el número de secuencia inicial (ISN) generalmente se establece en 1 y se incrementa en 64000 cada medio segundo y cada vez que hay una apertura activa. Esto significa que los tres dígitos menos significativos del ISN siempre serán 001. Sin embargo, en la figura 18.3, estos tres dígitos más bajos para cada dirección son 521. ¿Cómo sucedió esto?
En la Figura 18.15, imprimimos 12 caracteres, pero vimos que TCP envió 13 bytes. En la Figura 18.16, imprimimos 8 caracteres, pero TCP envió 10 bytes. ¿Por qué se agregó 1 byte en el primer caso y 2 bytes en el segundo?
¿Cuál es la diferencia entre una conexión medio abierta y una conexión medio cerrada?
Si iniciamos el programa sock como servidor y luego interrumpimos su funcionamiento (sin clientes conectados), podemos reiniciar inmediatamente el servidor. Esto significa que no estará en el estado de espera 2MSL. Explique esto en términos de un diagrama de transición de estados.
En la sección mostramos que un cliente no puede reutilizar el mismo número de puerto local mientras el puerto sea parte de una conexión en el estado de espera 2MSL. Sin embargo, si ejecutamos el programa sock dos veces seguidas como cliente que se conecta al servidor de hora, podemos usar el mismo número de puerto local. Además, podemos crear una nueva conexión que estará en estado de espera 2MSL. ¿Cómo sucede esto?
sol% calcetín -v bsdi durante el día

Miércoles 7 de julio 07:54:51 1993
conexión cerrada por par
sol% calcetín -v -b1163 bsdi durante el día reutilizar el mismo número de puerto local
conectado al 140.252.13.33.1163 al 140.252.13.35.13
Miércoles 7 de julio 07:55:01 1993
conexión cerrada por par
Al final de la sección, cuando describimos el estado FIN_WAIT_2, indicamos que la mayoría de las implementaciones harán la transición de la conexión de este estado al estado CERRADO si la aplicación ha completado un apagado completo (no medio cerrado) después de aproximadamente 11 minutos. Si el otro lado (en el estado CLOSE_WAIT) espera 12 minutos antes de realizar el cierre (enviar su FIN), ¿qué recibirá su TCP en respuesta al FIN?
¿Qué parte de una conversación telefónica hace la apertura activa y cuál la apertura pasiva? ¿Es posible la apertura simultánea? ¿Es posible cerrar al mismo tiempo?
En la Figura 18.6 no vimos la solicitud ARP ni la respuesta ARP. Sin embargo, la dirección de hardware del host svr4 debe estar en la caché ARP bsdi. ¿Qué cambiará en esta imagen si este elemento no está en el caché ARP?
Explique el siguiente resultado del comando tcpdump. Compárelo con la figura 18.13.
1 0.0 solaris.32990 > bsdi.discard: S 40140288:40140288 (0)
ganar 8760
2 0,003295 (0,0033) bsdi.discard > solaris.32990: S 4208081409:4208081409 (0)
confirmar 40140289 ganar 4096

3 0.419991 (0.4167) solaris.32990 > bsdi.discard: P 1:257 (256) ack 1 win 9216
4 0.449852 (0.0299) solaris.32990 > bsdi.discard: F 257:257 (0) ack 1 win 9216
5 0,451965 (0,0021) bsdi.discard > solaris.32990: . reconocer 258 ganar 3840
6 0.464569 (0.0126) bsdi.discard > solaris.32990: F 1:1 (0) ack 258 win 4096
7 0,720031 (0,2555) solaris.32990 > bsdi.discard: . ack 2 ganar 9216
¿Por qué el servidor de la Figura 18.4 no combinaría el ACK del FIN del cliente con su propio FIN, reduciendo así el número de segmentos a tres?
En la Figura 18.16, ¿por qué el número de secuencia RST es 26368002?
Dígame, ¿la solicitud de TCP a la capa de enlace para su MTU se basa en el principio de capas?

Capa de transporte

La tarea de la capa de transporte es transferir datos entre varias aplicaciones que se ejecutan en todos los nodos de la red. Una vez que el paquete se entrega a través de IP a la computadora receptora, los datos deben enviarse a un proceso de destinatario especial. Cada computadora puede ejecutar múltiples procesos y una aplicación puede tener múltiples puntos de entrada, actuando como destino para paquetes de datos.

Los paquetes que llegan a la capa de transporte del sistema operativo se organizan en múltiples colas en los puntos de entrada de varias aplicaciones. En la terminología TCP/IP, estos puntos de entrada se denominan puertos.

Protocolo de control de transmisión

Protocolo de control de transmisión(TCP) (Protocolo de control de transmisión) es un protocolo obligatorio del estándar TCP/IP, definido en RFC 793, "Protocolo de control de transmisión (TCP)".

tcp es un protocolo de capa de transporte que proporciona transporte (transmisión) de un flujo de datos, siendo necesario establecer primero una conexión, garantizando así la confianza en la integridad de los datos recibidos, y también realiza una solicitud repetida de datos en caso de pérdida de datos. o corrupción. Además, el protocolo TCP monitorea los paquetes duplicados y, si los detecta, los destruye.

A diferencia del protocolo UDP, garantiza la integridad de los datos transmitidos y la confirmación por parte del remitente de los resultados de la transferencia. Se utiliza en transferencias de archivos donde la pérdida de un paquete puede dañar todo el archivo.

TCP logra su confiabilidad mediante:

Los datos de la aplicación se dividen en bloques de cierto tamaño que se enviarán.
Cuando TCP envía un segmento, configura un temporizador y espera a que llegue una confirmación de ese segmento desde el extremo remoto. Si no se recibe un acuse de recibo después de transcurrido el tiempo, el segmento se retransmite.
Cuando TCP recibe datos del lado remoto de la conexión, envía un acuse de recibo. Este acuse de recibo no se envía inmediatamente, sino que suele retrasarse una fracción de segundo.
TCP calcula una suma de comprobación para su encabezado y datos. Se trata de una suma de comprobación calculada en los extremos de la conexión, cuyo objetivo es detectar cualquier cambio en los datos durante la transmisión. Si un segmento llega con una suma de comprobación incorrecta, TCP lo descarta y no se genera ninguna confirmación. (Se espera que el remitente expire el tiempo de espera y retransmita).
Dado que los segmentos TCP se transmiten como datagramas IP y los datagramas IP pueden llegar aleatoriamente, los segmentos TCP también pueden llegar aleatoriamente. Después de recibir los datos, TCP puede volver a secuenciarlos según sea necesario, de modo que la aplicación reciba los datos en el orden correcto.
Dado que un datagrama IP se puede duplicar, el TCP receptor debe descartar los datos duplicados.
TCP proporciona control de flujo. Cada lado de una conexión TCP tiene un espacio de búfer específico. TCP en el extremo receptor permite que el extremo remoto envíe datos solo si el destinatario puede guardarlos en un búfer. Esto evita que los hosts lentos desborden sus buffers con hosts rápidos.

El número de secuencia tiene dos propósitos:

Si se establece el indicador SYN, entonces este es el valor inicial del número de secuencia: ISN (Número de secuencia inicial), y el primer byte de datos que se transmitirá en el siguiente paquete tendrá un número de secuencia igual a ISN + 1.
De lo contrario, si no se establece SYN, el primer byte de datos transmitido en un paquete determinado tiene este número de secuencia.

Número de acuse de recibo: si el indicador ACK está configurado, este campo contiene el número de secuencia que espera el destinatario la próxima vez. Marca este segmento como confirmación de recepción.
La longitud del encabezado se especifica en palabras de 32 bits.
El tamaño de la ventana es la cantidad de bytes que el destinatario está dispuesto a aceptar sin confirmación.
Suma de comprobación: incluye pseudoencabezado, encabezado y datos.
Indicador de urgencia: indica el último byte de datos urgentes al que se debe responder de inmediato.
URG: indicador de urgencia, incluye el campo "Indicador de urgencia" si =0, entonces el campo se ignora.
ACK: indicador de confirmación, incluye el campo "Número de reconocimiento", si =0 entonces el campo se ignora.
PSH: la bandera requiere una operación de inserción, el módulo TCP debe transferir urgentemente el paquete al programa.
RST: indicador de interrupción de conexión, utilizado para rechazar una conexión
SYN: indicador de sincronización de número de secuencia, utilizado al establecer una conexión.
FIN: indicador de fin de transmisión desde el lado del remitente

Veamos la estructura del encabezado. tcp usando el analizador de red Wireshark:

Puertos TCP

Dado que se pueden ejecutar varios programas en la misma computadora, para entregar un paquete TCP a un programa específico, se utiliza el identificador único o número de puerto de cada programa.

Número de puerto es un número condicional de 16 bits del 1 al 65535 que indica para qué programa está destinado el paquete.

Los puertos TCP utilizan un puerto de software específico para entregar datos transmitidos mediante el Protocolo de control de transmisión (TCP). Los puertos TCP son más complejos y funcionan de manera diferente a los puertos UDP. Si bien un puerto UDP actúa como una única cola de mensajes y como punto de entrada para una conexión UDP, el punto de entrada final para todas las conexiones TCP es una conexión única. Cada conexión TCP se identifica de forma única mediante dos puntos de entrada.

Cada puerto de servidor TCP individual puede ofrecer acceso compartido a múltiples conexiones porque todas las conexiones TCP se identifican mediante dos valores: una dirección IP y un puerto TCP (socket).

Todos los números de puerto TCP menores que 1024 están reservados y registrados con la Autoridad de Números Asignados de Internet (IANA).

Los números de puerto UDP y TCP no se superponen.

Los programas TCP utilizan números de puerto reservados o conocidos, como se muestra en la siguiente figura.

Establecer una conexión TCP

Veamos ahora cómo se establecen las conexiones TCP. Supongamos que un proceso que se ejecuta en un host quiere establecer una conexión con otro proceso en otro host. Recuerde que el host que inicia la conexión se llama "cliente", mientras que el otro host se llama "servidor".

Antes de transmitir cualquier dato, según el protocolo TCP, las partes deben establecer una conexión. La conexión se establece en tres etapas (proceso TCP "triple handshake").

El solicitante (generalmente llamado cliente) envía un segmento SYN que indica el número de puerto del servidor al que el cliente desea conectarse y el número de secuencia original (ISN) del cliente.
El servidor responde con su segmento SYN que contiene el número de secuencia original del servidor. El servidor también reconoce la llegada del SYN del cliente mediante ACK (ISN + 1). Se utiliza un número de secuencia por SYN.
El cliente debe acusar recibo de la llegada de un SYN del servidor con sus segmentos SYN que contienen el número de secuencia original del cliente (ISN+1) y utilizando un ACK (ISN+1). El bit SYN se establece en 0 porque se establece la conexión.

Una vez establecida la conexión TCP, estos dos hosts pueden transmitir datos entre sí, dado que la conexión TCP es full-duplex, pueden transmitir datos simultáneamente.

Protocolo de control de transmisión (TCP)(Protocolo de control de transmisión) es uno de los principales protocolos de red de Internet, diseñado para controlar la transmisión de datos en redes y subredes TCP/IP.

Realiza las funciones del protocolo de capa de transporte del modelo OSI.

TCP es un mecanismo de transporte que proporciona un flujo de datos con una conexión preestablecida, brindando así confianza en la confiabilidad de los datos recibidos, volviendo a solicitar datos en caso de pérdida de datos y eliminando la duplicación al recibir dos copias del mismo paquete. . A diferencia de UDP, garantiza la integridad de los datos transmitidos y notifica al remitente los resultados de la transferencia.

Al transferir de una computadora a otra a través de Internet, TCP opera en la capa superior entre dos sistemas finales, como un navegador y un servidor web. TCP también transfiere de manera confiable un flujo de bytes de un programa en alguna computadora a otro programa en otra computadora. Los programas de correo electrónico y de intercambio de archivos utilizan TCP. TCP controla la longitud del mensaje, la tasa de intercambio de mensajes y el tráfico de red.

El protocolo TCP se ejecuta directamente sobre el protocolo IP (capa de transporte) y utiliza el protocolo IP potencialmente poco fiable para transportar sus bloques de datos. La confiabilidad de la transmisión de datos mediante el protocolo TCP se logra debido a que se basa en el establecimiento de conexiones lógicas entre procesos que interactúan. Mientras los programas TCP sigan funcionando correctamente y la red compuesta no se haya dividido en partes inconexas, los errores en la transmisión de datos a nivel del protocolo IP no afectarán la correcta recepción de los datos.

El protocolo IP es utilizado por el protocolo TCP como transporte. Antes de enviar sus bloques de datos, TCP los envuelve en un paquete IP. Cuando es necesario, el protocolo IP realiza cualquier fragmentación y reensamblaje de los bloques de datos TCP necesarios para la transmisión y entrega a través de múltiples redes y puertas de enlace intermedias.

Características del protocolo TCP:

Antes de transmitir datos, el protocolo establece una conexión.

Transmisión full duplex - hay 2 canales lógicos - entrada y salida

Fiabilidad: los datos se transmitirán uno por uno y se espera la confirmación de recepción por parte del destinatario. Si no se recibe dicha notificación, se reenvía el segmento TCP. En el extremo receptor, se descartan los segmentos duplicados.

TCP trata los datos como un flujo de bytes

Control de flujo de remitente y receptor

Estructura del segmento TCP: IP | tcp| datos IP = 20 bytes; datos TCP+ = 65515 bytes; => datos = 65515 – 20 = 65495 bytes

Estructura del encabezado TCP:

Puerto remitente

Puerto de destino

Número de secuencia

Número de confirmación

Compensación de datos

Reservado

Suma de comprobación

Indicador de importancia

Banderas (bits de control):

Este campo contiene indicadores de 6 bits:

URG- Campo " Puntero importancia" involucrado ( El campo de puntero urgente es significativo)

ACK- Campo "Número de confirmación" involucrado ( El campo de reconocimiento es significativo.)

P.S.H. - (Empujar función) indica al receptor que envíe los datos acumulados en el búfer de recepción a la aplicación del usuario

primero- Terminar conexiones, restablecer el búfer (borrar el búfer) ( Reiniciar el conexión)

SINC- Sincronización de números de secuencia ( Sincronizar secuencia números)

ALETA(final, bit): la bandera, cuando está configurada, indica la finalización de la conexión ( ALETA poco usado para conexión terminación).

Aunque también existen implementaciones de TCP en el contexto de la aplicación.

Encabezado del segmento TCP

Encabezado del segmento TCP

Poco	0 - 3	4 - 9	10 - 15	16 - 31
0	Puerto de origen			puerto de destino
32	Número de secuencia
64	Número de confirmación
96	Compensación de datos	Reservado	Banderas	Tamaño de ventana
128	Suma de comprobación			Indicador de importancia
160	Opciones (opcionales, pero casi siempre utilizadas)
160/192+	Datos

Puerto de origen

Número de secuencia

El número de secuencia tiene dos propósitos:

Si se establece el indicador SYN, entonces este es el valor inicial del número de secuencia: ISN (Número de secuencia inicial), y el primer byte de datos que se transmitirá en el siguiente paquete tendrá un número de secuencia igual a ISN + 1.
De lo contrario, si no se establece SYN, el primer byte de datos transmitido en un paquete determinado tiene este número de secuencia.

Dado que un flujo TCP generalmente puede ser más largo que el número de estados distintos de este campo, todas las operaciones con el número de secuencia deben realizarse en módulo 2^32. Esto impone una limitación práctica al uso de TCP. Si la velocidad de transmisión del sistema de comunicación es tal que el desbordamiento del número de secuencia ocurre durante el MSL (vida útil máxima del segmento), entonces pueden aparecer en la red dos segmentos con el mismo número, pertenecientes a diferentes partes de la transmisión, y el receptor recibir datos incorrectos.

Número de confirmación

Si el indicador ACK está configurado, este campo contiene el número de secuencia que espera el destinatario la próxima vez. Marca este segmento como confirmación de recepción.

Compensación de datos

Este campo especifica el tamaño del encabezado del paquete TCP en palabras de 4 bytes (4 octetos). El tamaño mínimo es de 5 palabras y el máximo es de 15, que son 20 y 60 bytes respectivamente. El desplazamiento se calcula desde el principio del encabezado TCP.

Reservado

Reservado (6 bits) para uso futuro y debe establecerse en cero. De ellos, dos (5º y 6º) ya han sido definidos:

C.W.R.(Ventana de congestión reducida): campo "Ventana de congestión reducida": el remitente establece el indicador para indicar que se recibió un paquete con el indicador ECE establecido (RFC 3168).
CEPE(ECN-Echo): campo Eco de ECN: indica que este nodo es capaz de realizar ECN (notificación explícita de congestión) e indicar al remitente sobre la congestión de la red (RFC 3168).

Banderas (bits de control)

Este campo contiene indicadores de 6 bits:

URG- Campo "Índice de importancia" involucrado (inglés) El campo de puntero urgente es significativo )
ACK- Campo "Número de confirmación" involucrado (inglés) El campo de reconocimiento es significativo. )
P.S.H.- (Inglés) Función de empuje) indica al receptor que envíe los datos acumulados en el búfer de recepción a la aplicación del usuario
primero- Romper conexiones, restablecer buffer (borrar buffer) (ing. Restablecer la conexión)
SINC- Sincronización del número de secuencia Sincronizar números de secuencia)
ALETA(Inglés) final, bit): la bandera, cuando está configurada, indica la finalización de la conexión (ing. Bit FIN utilizado para la terminación de la conexión ).

Ventana

Este campo contiene un número que especifica, en bytes, el tamaño de los datos que el remitente está dispuesto a aceptar.

Pseudotítulo

El encabezado TCP no contiene información sobre las direcciones del remitente y del destinatario, por lo que incluso si el puerto del destinatario coincide, es imposible decir con certeza que el mensaje llegó al lugar correcto. Dado que el objetivo del protocolo TCP es la entrega fiable de mensajes, este punto es de fundamental importancia. Este problema podría solucionarse de diferentes maneras. La más obvia es agregar información sobre la dirección de destino al encabezado TCP, pero esto, en primer lugar, conduce a la duplicación de información, lo que reduce la proporción de información útil transportada por el segmento TCP y, en segundo lugar, viola el principio de encapsulación de el modelo OSI. Por lo tanto, los desarrolladores del protocolo tomaron una ruta diferente y utilizaron un pseudoencabezado adicional:

Pseudoencabezado TCP IPv4

Pseudoencabezado TCP IPv6

Protocolo/Protocolo de nivel superior (siguiente encabezado): contiene el valor 6 (000000110 en binario, 0x6 en hexadecimal): identificador del protocolo TCP.
Longitud del segmento TCP (longitud TCP): contiene la longitud del segmento TCP en bytes (encabezado TCP + datos; la longitud del pseudoencabezado no se tiene en cuenta).

El pseudoencabezado no está incluido en el segmento TCP. Se utiliza para calcular una suma de verificación antes de enviar un mensaje y cuando se recibe (el destinatario construye su pseudoencabezado usando la dirección del host del que proviene el mensaje y su propia dirección, y luego calcula la suma de verificación).

Suma de comprobación

El campo de suma de comprobación es el complemento de 16 bits de la suma de todas las palabras de 16 bits del encabezado (incluido el pseudoencabezado) y los datos. Si el segmento para el cual se calcula la suma de verificación tiene una longitud que no es un múltiplo de 16 bits, entonces la longitud del segmento se aumenta a un múltiplo de 16 agregando bits de relleno de cero a la derecha. Los bits de relleno (0) no se transmiten en el mensaje y sólo sirven para calcular la suma de comprobación. Al calcular la suma de verificación, se supone que el valor del campo de suma de verificación es 0.

Indicador de importancia

El valor de 16 bits del desplazamiento positivo del número de secuencia en este segmento. Este campo especifica el número de secuencia del octeto que finaliza los datos urgentes. El campo se tiene en cuenta solo para paquetes con el indicador URG configurado.

Opciones

Puede utilizarse en algunos casos para ampliar el protocolo. A veces se utiliza para realizar pruebas. Por el momento, las opciones casi siempre incluyen 2 bytes NOP (en este caso 0x01) y 10 bytes especificando marcas de tiempo. Puede calcular la longitud del campo de opción utilizando el valor del campo de compensación.

Mecanismo del protocolo

A diferencia de la alternativa tradicional, UDP, que puede comenzar a transmitir paquetes inmediatamente, TCP establece conexiones que deben crearse antes de transmitir datos. Una conexión TCP se puede dividir en 3 etapas:

Estableciendo una conexión
Transferencia de datos
Terminando la conexión

Estados de sesión TCP

Estados de sesión TCP
CERRADO	El estado inicial del nodo. realmente ficticio
ESCUCHAR	El servidor espera solicitudes de conexión del cliente.
SINCRONIZADO	El cliente envió una solicitud al servidor para establecer una conexión y está esperando una respuesta.
SINCRONIZADO	El servidor recibió una solicitud de conexión, envió una solicitud de respuesta y está esperando confirmación.
ESTABLECIDO	Conexión establecida, transferencia de datos en curso
FIN-ESPERAR-1	Una de las partes (llamémoslo nodo-1) completa la conexión enviando un segmento con el indicador FIN
ESPERAR CERCA	El otro lado (nodo-2) ingresa a este estado enviando, a su vez, un segmento ACK y continúa la transmisión unidireccional.
FIN-ESPERAR-2	El nodo 1 recibe ACK, continúa leyendo y espera recibir un segmento con el indicador FIN
ÚLTIMO ACK	El nodo 2 finaliza la transmisión y envía el segmento con el indicador FIN
TIEMPO DE ESPERA	El nodo 1 recibió un segmento con el indicador FIN, envió un segmento con el indicador ACK y espera 2*MSL segundos antes de cerrar finalmente la conexión.
CIERRE	Ambos lados iniciaron el cierre de la conexión al mismo tiempo: después de enviar un segmento con el indicador FIN, el nodo 1 también recibe un segmento FIN, envía un ACK y espera un segmento ACK (acuse de recibo de su solicitud de desconexión)

Estableciendo una conexión

El proceso de inicio de una sesión TCP, denominado "apretón de manos", consta de 3 pasos.

1. Un cliente que pretende establecer una conexión envía un segmento con un número de secuencia y un indicador SYN al servidor.

El servidor recibe el segmento, recuerda el número de secuencia e intenta crear un socket (búferes y estructuras de memoria de control) para servir al nuevo cliente.
- Si tiene éxito, el servidor envía al cliente un segmento con un número de secuencia y los indicadores SYN y ACK, y entra en el estado SYN-RECEIVED.
- En caso de falla, el servidor envía al cliente un segmento con el indicador RST.

2. Si el cliente recibe un segmento con el indicador SYN, recuerda el número de secuencia y envía el segmento con el indicador ACK.

Si también recibe el indicador ACK al mismo tiempo (lo que suele suceder), entonces ingresa al estado ESTABLECIDO.
Si el cliente recibe un segmento con el indicador RST, deja de intentar conectarse.
Si el cliente no recibe respuesta en 10 segundos, repite el proceso de conexión nuevamente.

3. Si el servidor en el estado SYN-RECEIVED recibe un segmento con el indicador ACK, pasa al estado ESTABLECIDO.

De lo contrario, después de un tiempo de espera, cierra el socket y pasa al estado CERRADO.

El proceso se denomina “apretón de manos de tres vías” porque aunque es posible establecer una conexión utilizando 4 segmentos (SYN al servidor, ACK al cliente, SYN al cliente, ACK al servidor), en la práctica, se necesitan 3 segmentos. utilizado para ahorrar tiempo.

Ejemplo de una aprobación básica de 3 pasos:

TCP A TCP B 1. ESCUCHA CERRADA 2. SYN-SENT --> --> SYN-RECIBIDO 3. ESTABLECIDO<-- <-- SYN-RECEIVED 4. ESTABLISHED --> --> ESTABLECIDO 5. ESTABLECIDO<-- <-- ESTABLISHED

En la línea 2, TCP A comienza a enviar un segmento SYN que indica el uso de números de secuencia, comenzando con 100. En la línea 3, TCP B envía un SYN y un reconocimiento del SYN recibido a TCP A. Tenga en cuenta que el campo de reconocimiento indica que TCP B está esperando que se reciba el número de secuencia 101, confirmando el número SYN 100.

En la línea 4, TCP A responde con un segmento vacío con un ACK para el segmento SYN de TCP B; en la línea 5, TCP B envía algunos datos. Tenga en cuenta que el número de secuencia del segmento en la línea 5 es el mismo que el número en la línea 4, ya que el ACK no ocupa espacio de número de secuencia (si lo hace, tendrá que confirmar los reconocimientos: ¡ACK por ACK!).

Transferencia de datos

Al intercambiar datos, el receptor utiliza el número de secuencia contenido en los segmentos recibidos para restaurar su orden original. El receptor notifica al lado emisor el número de secuencia de bytes hasta el cual recibió correctamente los datos, incluyéndolo en el campo "número de reconocimiento". Se ignoran todos los datos recibidos dentro del rango de secuencias confirmadas. Si el segmento recibido contiene un número de secuencia mayor al esperado, los datos del segmento se almacenan en el búfer, pero el número de secuencia confirmado no cambia. Si posteriormente se recibe un segmento correspondiente al número de secuencia esperado, el orden de los datos se restaurará automáticamente en función de los números de secuencia de los segmentos.

Para garantizar que el lado emisor no envíe más datos de los que el receptor puede procesar, TCP contiene controles de flujo. Para hacer esto, use el campo "ventana". En los segmentos enviados desde el receptor al lado transmisor, el tamaño actual del búfer de recepción se indica en el campo "ventana". El lado emisor mantiene el tamaño de la ventana y no envía más datos de los indicados por el receptor. Si el receptor ha especificado un tamaño de ventana de cero, entonces no se transmiten datos hacia ese nodo hasta que el receptor informe un tamaño de ventana mayor.

En algunos casos, la aplicación emisora puede solicitar explícitamente que los datos se envíen en secuencia a la aplicación receptora sin almacenarlos en el búfer. Para ello se utiliza la bandera PSH. Si se detecta el indicador PSH en el segmento recibido, la implementación de TCP devuelve todos los datos actualmente almacenados en el buffer a la aplicación receptora. Push se utiliza, por ejemplo, en aplicaciones interactivas. En los terminales de red no tiene sentido esperar la entrada del usuario después de haber terminado de escribir un comando. Por lo tanto, el último segmento que contiene el comando debe contener el indicador PSH para que la aplicación del lado receptor pueda comenzar a ejecutarlo.

Terminando la conexión

La terminación de una conexión se puede considerar en tres pasos:

Envío de los indicadores FIN y ACK al servidor desde el cliente para completar la conexión.
El servidor envía los indicadores de respuesta del cliente ACK, FIN, lo que indica que la conexión está cerrada.
Después de recibir estos indicadores, el cliente cierra la conexión y envía un ACK al servidor para confirmar que la conexión está cerrada.

Problemas conocidos

Tamaño máximo de segmento

TCP requiere un tamaño de segmento máximo (MSS) explícito si se realiza una conexión virtual a través de un segmento de red donde el tamaño de unidad máximo (MTU) es menor que el MTU de Ethernet estándar (1500 bytes).

En protocolos de tunelización como GRE, IPIP y PPPoE, la MTU del túnel es más pequeña que la estándar, por lo que el tamaño máximo del segmento TCP tiene una longitud de paquete mayor que la MTU. Dado que la fragmentación está prohibida en la gran mayoría de los casos, dichos paquetes se descartan.

La manifestación de este problema parece ser conexiones "colgadas". En este caso, la "congelación" puede ocurrir en momentos arbitrarios, es decir, cuando el remitente utilizó segmentos más largos que el tamaño permitido.

Para resolver este problema, los enrutadores usan reglas de Firewall que agregan un parámetro MSS a todos los paquetes que inician conexiones para que el remitente use segmentos de un tamaño válido.

MSS también se puede controlar mediante la configuración del sistema operativo.

Detección de errores durante la transmisión de datos.

Aunque el protocolo realiza una verificación de suma de verificación en cada segmento, el algoritmo utilizado se considera débil. Así, en 2008, un error en la transmisión de un bit que no fue detectado por las herramientas de red provocó el cierre de los servidores del sistema de Amazon Web Services.

En general, se recomienda que las aplicaciones de red distribuidas utilicen software adicional para garantizar la integridad de la información transmitida.

Ataques de protocolo

Artículo principal: Ataques a TCP

Las deficiencias del protocolo se manifiestan en ataques teóricos y prácticos exitosos, en los que un atacante puede obtener acceso a los datos transmitidos, hacerse pasar por la otra parte o dejar el sistema inoperable.

Implementación

Exención del cálculo de la suma de control

Muchas implementaciones de la pila TCP/IP brindan la capacidad de utilizar soporte de hardware para calcular automáticamente una suma de verificación en el adaptador de red antes de la transmisión a la red o después de la recepción de la red para su verificación. Esto puede liberar al sistema operativo del uso de valiosos ciclos de procesador al calcular la suma de comprobación.

Esta característica puede hacer que los analizadores de tráfico que interceptan los paquetes salientes antes de enviarlos al adaptador de red y no sean conscientes de delegar cálculos de suma de verificación al adaptador de red informen un error de suma de verificación en los paquetes salientes.

Ver también

Campo de golf

RFC 793 - Protocolo de control de transmisión

Literatura

Terry Ogletree. Modernización y reparación de redes = Actualización y Reparación de Redes. - 4ª ed. - M.: “Williams”, 2005. - P. 1328. - ISBN 0-7897-2817-6
Douglas Kamer. Redes TCP/IP, Volumen 1. Principios, Protocolos y Estructura = Interconexión con TCP/IP, Vol. 1: Principios, Protocolos y Arquitectura. - M.: “Williams”, 2003. - P. 880. - ISBN 0-13-018380-6

Andrey Robachevsky, Sergey Nemnyugin, Olga Stesik. Sistema operativo UNIX. - 2ª ed. - "BHV-Petersburgo", 2007. - P. 656. -

El funcionamiento de Internet global se basa en un conjunto (pila) de protocolos TCP/IP. Pero estos términos parecen complejos sólo a primera vista. De hecho Pila de protocolo TCP/IP es un conjunto simple de reglas para el intercambio de información, y usted conoce bien estas reglas, aunque probablemente no lo sepa. Sí, así es exactamente; esencialmente, no hay nada nuevo en los principios subyacentes a los protocolos TCP/IP: todo lo nuevo es viejo olvidado.

Una persona puede aprender de dos maneras:

A través de una estúpida memorización formal de métodos formulaicos para resolver problemas estándar (que es lo que ahora se enseña principalmente en la escuela). Esta formación es ineficaz. Seguramente ha visto el pánico y la total impotencia de un contador al cambiar la versión del software de oficina, con el más mínimo cambio en la secuencia de clics del mouse necesarios para realizar acciones familiares. ¿O alguna vez has visto a una persona caer en estupor al cambiar la interfaz del escritorio?
A través de la comprensión de la esencia de los problemas, fenómenos y patrones. A través de la comprensión principios construyendo tal o cual sistema. En este caso, tener conocimientos enciclopédicos no juega un papel importante: la información que falta es fácil de encontrar. Lo principal es saber qué buscar. Y esto no requiere un conocimiento formal del tema, sino una comprensión de la esencia.

En este artículo, propongo tomar el segundo camino, ya que comprender los principios subyacentes a Internet le permitirá sentirse seguro y libre en Internet: resolver rápidamente los problemas que surjan, formular correctamente los problemas y comunicarse con confianza con el soporte técnico.

Entonces comencemos.

Los principios de funcionamiento de los protocolos de Internet TCP/IP son muy simples y se parecen mucho al trabajo de nuestro servicio postal soviético.

Recuerda cómo funciona nuestro correo regular. Primero, escribe una carta en una hoja de papel, luego la mete en un sobre, lo cierra, escribe las direcciones del remitente y del destinatario en el reverso del sobre y luego lo lleva a la oficina de correos más cercana. A continuación, la carta pasa a través de una cadena de oficinas de correos hasta la oficina de correos más cercana del destinatario, desde donde el cartero la entrega en la dirección especificada por el destinatario y la deposita en su buzón (con su número de apartamento) o la entrega personalmente. Eso es todo, la carta ha llegado al destinatario. Cuando el destinatario de la carta quiera responderte, intercambiará las direcciones del destinatario y del remitente en su carta de respuesta, y la carta te será enviada a lo largo de la misma cadena, pero en la dirección opuesta.

El sobre de la carta dirá algo como esto:

Dirección del remitente: De quien: Ivanov Ivan Ivanovich Dónde: Ivanteevka, calle. Bolshaya, 8, apto. 25 Dirección del destinatario: A quien: Petrov Petr Petrovich Dónde: Moscú, calle Usachevsky, 105, apto. 110

Ahora estamos listos para considerar la interacción de computadoras y aplicaciones en Internet (y también en la red local). Tenga en cuenta que la analogía con el correo ordinario será casi completa.

Cada computadora (también conocida como nodo, host) en Internet también tiene una dirección única, que se denomina dirección IP (dirección de protocolo de Internet), por ejemplo: 195.34.32.116. Una dirección IP consta de cuatro números decimales (0 a 255) separados por un punto. Pero conocer sólo la dirección IP del ordenador no es suficiente, porque... En última instancia, no son los propios ordenadores los que intercambian información, sino las aplicaciones que se ejecutan en ellos. Y varias aplicaciones pueden ejecutarse simultáneamente en una computadora (por ejemplo, un servidor de correo, un servidor web, etc.). Para entregar una carta en papel normal, no basta con saber sólo la dirección de la casa, también es necesario saber el número del apartamento. Además, cada aplicación de software tiene un número similar llamado número de puerto. La mayoría de las aplicaciones de servidor tienen números estándar, por ejemplo: un servicio de correo electrónico está vinculado al puerto número 25 (también dicen: "escucha" el puerto, recibe mensajes en él), un servicio web está vinculado al puerto 80, FTP al puerto 21 , etcétera.

Así, tenemos la siguiente analogía casi completa con nuestra dirección postal habitual:

"dirección de la casa" = "IP de la computadora" "número de apartamento" = "número de puerto"

En las redes informáticas que funcionan con protocolos TCP/IP, se utiliza un análogo de una carta en papel en un sobre. bolsa de plastico, que contiene los datos reales transmitidos y la información de la dirección: la dirección del remitente y la dirección del destinatario, por ejemplo:

Dirección de origen: IP: 82.146.49.55 Puerto: 2049 Dirección del destinatario (Dirección de destino): IP: 195.34.32.116 Puerto: 53 Detalles del paquete: ...

Por supuesto, los paquetes también contienen información sobre el servicio, pero esto no es importante para entender la esencia.

Tenga en cuenta la combinación: "Dirección IP y número de puerto" - llamado "enchufe".

En nuestro ejemplo, enviamos un paquete desde el socket 82.146.49.55:2049 al socket 195.34.32.116:53, es decir el paquete irá a una computadora con una dirección IP 195.34.32.116, al puerto 53. Y el puerto 53 corresponde a un servidor de reconocimiento de nombres (servidor DNS), que recibirá este paquete. Conociendo la dirección del remitente, este servidor podrá, tras procesar nuestra petición, formar un paquete de respuesta que irá en dirección opuesta al socket del remitente 82.146.49.55:2049, que para el servidor DNS será el socket del destinatario.

Como regla general, la interacción se lleva a cabo según el esquema "cliente-servidor": el "cliente" solicita cierta información (por ejemplo, una página de un sitio web), el servidor acepta la solicitud, la procesa y envía el resultado. Los números de puerto de las aplicaciones del servidor son bien conocidos, por ejemplo: el servidor de correo SMTP escucha en el puerto 25, el servidor POP3 que permite leer el correo de tus buzones escucha en el puerto 110, el servidor web escucha en el puerto 80, etc.

La mayoría de los programas en una computadora doméstica son clientes, por ejemplo, el cliente de correo electrónico Outlook, IE, los navegadores web Firefox, etc.

Los números de puerto en el cliente no son fijos como los del servidor, sino que el sistema operativo los asigna dinámicamente. Los puertos de servidor fijos suelen tener números hasta 1024 (pero hay excepciones) y los puertos de cliente comienzan después de 1024.

La repetición es la madre de la enseñanza: IP es la dirección de una computadora (nodo, host) en la red y el puerto es el número de una aplicación específica que se ejecuta en esta computadora.

Sin embargo, a una persona le resulta difícil recordar las direcciones IP digitales; es mucho más conveniente trabajar con nombres alfabéticos. Después de todo, es mucho más fácil recordar una palabra que un conjunto de números. Esto ya está hecho: cualquier dirección IP digital se puede asociar con un nombre alfanumérico. Como resultado, por ejemplo, en lugar de 82.146.49.55, puede utilizar el nombre. Y el servicio de nombres de dominio (DNS) (Sistema de nombres de dominio) se encarga de la conversión del nombre de dominio a una dirección IP digital.

Echemos un vistazo más de cerca a cómo funciona esto. Su ISP, ya sea explícitamente (en papel, para la configuración manual de la conexión) o implícitamente (mediante la configuración automática de la conexión), le proporciona la dirección IP del servidor de nombres (DNS). En una computadora con esta dirección IP hay una aplicación (servidor de nombres) ejecutándose que conoce todos los nombres de dominio en Internet y sus correspondientes direcciones IP digitales. El servidor DNS "escucha" el puerto 53, acepta solicitudes y emite respuestas, por ejemplo:

Solicitud desde nuestra computadora: "¿Qué dirección IP corresponde al nombre www.sitio?" Respuesta del servidor: "82.146.49.55".

Ahora veamos qué sucede cuando escribe el nombre de dominio (URL) de este sitio () en su navegador y hace clic , en respuesta del servidor web usted recibe una página de este sitio.

Por ejemplo:

Dirección IP de nuestra computadora: 91.76.65.216 Navegador: Internet Explorer (IE), Servidor DNS (stream): 195.34.32.116 (el suyo puede ser diferente), La página que queremos abrir: www.site.

Escriba el nombre de dominio en la barra de direcciones del navegador y haga clic en . A continuación, el sistema operativo realiza aproximadamente las siguientes acciones:

Se envía una solicitud (más precisamente, un paquete con una solicitud) al servidor DNS en el socket 195.34.32.116:53. Como comentamos anteriormente, el puerto 53 corresponde al servidor DNS, una aplicación que resuelve nombres. Y el servidor DNS, después de procesar nuestra solicitud, devuelve la dirección IP que coincide con el nombre ingresado.

El diálogo es algo como esto:

¿Qué dirección IP corresponde al nombre? www.sitio? - 82.146.49.55 .

A continuación, nuestra computadora establece una conexión con el puerto. 80 computadora 82.146.49.55 y envía una solicitud (paquete de solicitud) para recibir la página. El puerto 80 corresponde al servidor web. El puerto 80 no suele estar escrito en la barra de direcciones del navegador, porque... se utiliza de forma predeterminada, pero también se puede especificar explícitamente después de los dos puntos - .

Al recibir nuestra solicitud, el servidor web la procesa y nos envía una página en varios paquetes en HTML, un lenguaje de marcado de texto que el navegador entiende.

Nuestro navegador, al recibir la página, la muestra. Como resultado, vemos la página principal de este sitio en la pantalla.

¿Por qué necesitamos entender estos principios?

Por ejemplo, notó un comportamiento extraño en su computadora: actividad extraña en la red, ralentizaciones, etc. ¿Qué hacer? Abra la consola (haga clic en el botón "Inicio" - "Ejecutar" - escriba cmd - "Aceptar"). En la consola escribimos el comando netstat -an y haga clic . Esta utilidad mostrará una lista de conexiones establecidas entre los sockets de nuestra computadora y los sockets de hosts remotos. Si vemos algunas direcciones IP extranjeras en la columna "Dirección externa" y el puerto número 25 después de los dos puntos, ¿qué podría significar esto? (¿Recuerda que el puerto 25 corresponde al servidor de correo?) Esto significa que su computadora ha establecido una conexión con algún servidor (servidores) de correo y está enviando algunas cartas a través de él. Y si su cliente de correo electrónico (Outlook, por ejemplo) no se está ejecutando en este momento y todavía hay muchas conexiones de este tipo en el puerto 25, entonces probablemente haya un virus en su computadora que envía spam en su nombre o reenvía su crédito. números de tarjetas junto con contraseñas a los atacantes.

Además, es necesario comprender los principios de Internet para configurar correctamente un firewall (en otras palabras, un firewall :)). Este programa (que a menudo viene con un antivirus) está diseñado para filtrar paquetes: "amigos" y "enemigos". Deja pasar a los tuyos, no dejes entrar a extraños. Por ejemplo, si su firewall le dice que alguien quiere establecer una conexión a algún puerto de su computadora. ¿Permitir o negar?

Y lo más importante, este conocimiento es extremadamente útil a la hora de comunicarse con el soporte técnico.

Finalmente, aquí hay una lista de puertos que probablemente encontrará:

135-139 - Windows utiliza estos puertos para acceder a recursos informáticos compartidos: carpetas, impresoras. No abra estos puertos al exterior, es decir. a la red local regional e Internet. Deben cerrarse con un firewall. Además, si en la red local no ve nada en el entorno de red o no es visible, probablemente esto se deba al hecho de que el firewall ha bloqueado estos puertos. Por tanto, estos puertos deben estar abiertos para la red local, pero cerrados para Internet. 21 - puerto ftp servidor. 25 - puerto postal SMTP servidor. Su cliente de correo electrónico envía cartas a través de él. La dirección IP del servidor SMTP y su puerto (25) deben especificarse en la configuración de su cliente de correo. 110 - puerto POP3 servidor. A través de él, su cliente de correo recoge las cartas de su buzón. La dirección IP del servidor POP3 y su puerto (110) también deben especificarse en la configuración de su cliente de correo. 80 - puerto WEB-servidores. 3128, 8080 - servidores proxy (configurados en la configuración del navegador).

Varias direcciones IP especiales:

127.0.0.1 es localhost, la dirección del sistema local, es decir. dirección local de su computadora. 0.0.0.0: así es como se designan todas las direcciones IP. 192.168.xxx.xxx: direcciones que se pueden utilizar arbitrariamente en redes locales; no se utilizan en Internet global. Son únicos sólo dentro de la red local. Puede utilizar direcciones de este rango a su discreción, por ejemplo, para crear una red doméstica o de oficina.

¿Cuál es la máscara de subred y la puerta de enlace predeterminada (enrutador, enrutador)?

(Estos parámetros se configuran en la configuración de conexión de red).

Es sencillo. Las computadoras están conectadas a redes locales. En una red local, las computadoras se "ven" directamente sólo entre sí. Las redes locales están conectadas entre sí a través de puertas de enlace (enrutadores, enrutadores). La máscara de subred está diseñada para determinar si la computadora del destinatario pertenece a la misma red local o no. Si la computadora receptora pertenece a la misma red que la computadora emisora, entonces el paquete se le envía directamente; de lo contrario, el paquete se envía a la puerta de enlace predeterminada, que luego, utilizando rutas que conoce, transmite el paquete a otra red, es decir. a otra oficina de correos (por analogía con la oficina de correos soviética).

Finalmente, veamos qué significan estos términos poco claros:

TCP/IP es el nombre de un conjunto de protocolos de red. De hecho, el paquete transmitido pasa por varias capas. (Como en el correo: primero escribes una carta, luego la metes en un sobre con dirección, luego el correo le pone un sello, etc.).

IP El protocolo es el llamado protocolo de capa de red. La tarea de este nivel es entregar paquetes IP desde la computadora del remitente a la computadora del destinatario. Además de los datos en sí, los paquetes de este nivel tienen una dirección IP de origen y una dirección IP de destinatario. Los números de puerto no se utilizan a nivel de red. ¿Qué puerto, es decir? Este paquete está dirigido a la aplicación; en este nivel se desconoce si este paquete se entregó o se perdió; esta no es su tarea, es la tarea de la capa de transporte.

TCP y UDP Se trata de protocolos de la llamada capa de transporte. La capa de transporte se encuentra por encima de la capa de red. En este nivel, se agregan al paquete un puerto de origen y un puerto de destino.

tcp Es un protocolo orientado a conexión con entrega de paquetes garantizada. Primero, se intercambian paquetes especiales para establecer una conexión, se produce algo así como un apretón de manos (-Hola. -Hola. -¿Charlamos? -Vamos.). Además, los paquetes se envían y reciben a través de esta conexión (hay una conversación en curso) y se verifica si el paquete ha llegado al destinatario. Si el paquete no se recibe, se envía nuevamente (“repito, no escuché”).

UDP es un protocolo sin conexión con entrega de paquetes no garantizada. (Como: gritaron algo, pero te escucharon o no, no importa).

Por encima de la capa de transporte está la capa de aplicación. En este nivel, protocolos como http, ftp etc. Por ejemplo, HTTP y FTP utilizan el protocolo TCP confiable, y el servidor DNS funciona a través del protocolo UDP no confiable.

¿Cómo ver las conexiones actuales?

Las conexiones actuales se pueden ver usando el comando

netstat-an

(el parámetro n especifica mostrar direcciones IP en lugar de nombres de dominio).

Este comando se ejecuta así:

“Inicio” - “Ejecutar” - escriba cmd - “Aceptar”. En la consola que aparece (ventana negra), escriba el comando netstat -an y haga clic en . El resultado será una lista de conexiones establecidas entre los enchufes de nuestra computadora y los nodos remotos.

Por ejemplo obtenemos:

Conexiones activas

Nombre	dirección local	dirección externa	Estado
tcp	0.0.0.0:135	0.0.0.0:0	ESCUCHANDO
tcp	91.76.65.216:139	0.0.0.0:0	ESCUCHANDO
tcp	91.76.65.216:1719	212.58.226.20:80	ESTABLECIDO
tcp	91.76.65.216:1720	212.58.226.20:80	ESTABLECIDO
tcp	91.76.65.216:1723	212.58.227.138:80	CLOSE_WAIT
tcp	91.76.65.216:1724	212.58.226.8:80	ESTABLECIDO

...

En este ejemplo, 0.0.0.0:135 significa que nuestra computadora escucha (ESCUCHA) el puerto 135 en todas sus direcciones IP y está lista para aceptar conexiones de cualquier persona en ella (0.0.0.0:0) a través del protocolo TCP.

91.76.65.216:139: nuestra computadora escucha el puerto 139 en su dirección IP 91.76.65.216.

La tercera línea significa que la conexión ya está establecida (ESTABLECIDA) entre nuestra máquina (91.76.65.216:1719) y la remota (212.58.226.20:80). El puerto 80 significa que nuestra máquina realizó una solicitud al servidor web (de hecho, tengo páginas abiertas en el navegador).

En futuros artículos veremos cómo aplicar este conocimiento, p.e.

Popular en la categoría: