EntradaAplicación tcp ip cliente servidor. Programación de red - TCP
Aplicación cliente-servidor en el socket de transmisión TCP
En el siguiente ejemplo, usamos TCP para proporcionar flujos de bytes bidireccionales ordenados y confiables. Construyamos una aplicación completa que incluye un cliente y un servidor. Primero demostramos cómo construir un servidor en sockets de transmisión TCP y luego una aplicación cliente para probar nuestro servidor.
El siguiente programa crea un servidor que recibe solicitudes de conexión de los clientes. El servidor se construye sincrónicamente, por lo tanto, la ejecución del hilo se bloquea hasta que el servidor acepta conectarse con el cliente. Esta aplicación muestra un servidor simple que responde a un cliente. El cliente finaliza la conexión enviando un mensaje al servidor.
Servidor TCP
La creación de la estructura del servidor se muestra en el siguiente diagrama funcional:
Aquí está el código completo para el programa SocketServer.cs:
// SocketServer.cs usando System; usando System.Text; usando System.Net; utilizando System.Net.Sockets; namespace SocketServer (class Program (static void Main (string args) (// Establecer el punto final local para el socket IPHostEntry ipHost = Dns.GetHostEntry ("localhost"); IPAddress ipAddr = ipHost.AddressList; IPEndPoint ipEndPoint = new IPEndPoint (ipAddr, 11); // Cree un Tcp / Ip Socket sListener = new Socket (ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp); // Asigne el socket al punto final local y escuche los sockets entrantes try (sListener.Bind (ipEndPoint ); sListener. Listen (10); // Empiece a escuchar conexiones while (true) (Console.WriteLine ("Esperando una conexión en el puerto (0)", ipEndPoint); // El programa se detiene, esperando una conexión entrante Socket handler = sListener.Accept (); string data = null; // Esperamos a que un cliente intentara conectarse con nosotros byte bytes = new byte; int bytesRec = handler.Receive (bytes); data + = Encoding.UTF8.GetString (bytes, 0, bytesRec); // Mostrar datos en la consola Console.Write ("Received texto: "+ datos +" \ n \ n "); // Enviar una respuesta al cliente \ string reply = "Gracias por la solicitud en" + data.Length.ToString () + "characters"; byte msg = Encoding.UTF8.GetBytes (respuesta); handler.Send (msg); if (data.IndexOf ("
Echemos un vistazo a la estructura de este programa.
El primer paso es establecer un punto final local para el socket. Antes de abrir un socket para escuchar las conexiones, debe preparar una dirección de punto final local para él. La dirección única para el servicio TCP / IP se determina mediante la combinación de la dirección IP del host con el número de puerto del servicio que crea el punto final para el servicio.
La clase Dns proporciona métodos que devuelven información sobre las direcciones de red admitidas por un dispositivo en una red local. Si un dispositivo LAN tiene más de una dirección de red, la clase Dns devuelve información sobre todas las direcciones de red y la aplicación debe seleccionar una dirección adecuada de la matriz para servir.
Cree un IPEndPoint para el servidor combinando la primera dirección IP de host del método Dns.Resolve () con el número de puerto:
IPHostEntry ipHost = Dns.GetHostEntry ("localhost"); IPAddress ipAddr = ipHost.AddressList; IPEndPoint ipEndPoint = nuevo IPEndPoint (ipAddr, 11000);
Aquí, la clase IPEndPoint representa localhost en el puerto 11000. A continuación, cree un socket de flujo con una nueva instancia de la clase Socket. Con un punto final local configurado para escuchar conexiones, se puede crear un socket:
Socket sListener = nuevo Socket (ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
Enumeración DirecciónFamilia especifica los esquemas de direccionamiento que una instancia de la clase Socket puede usar para resolver una dirección.
En el parámetro Tipo de enchufe hay sockets TCP y UDP. En él se pueden definir, entre otras cosas, los siguientes valores:
DgramSoporta datagramas. El valor de Dgram requiere que especifique Udp para el tipo de protocolo e InterNetwork en el parámetro de familia de direcciones.
CrudoAdmite el acceso al protocolo de transporte subyacente.
ArroyoAdmite tomas de transmisión. El valor de Stream requiere que se especifique Tcp para el tipo de protocolo.
El tercer y último parámetro define el tipo de protocolo requerido para el socket. En el parámetro Tipo de protocolo puede especificar los siguientes valores más importantes: Tcp, Udp, Ip, Raw.
El siguiente paso debería ser asignar el socket usando el método Unir ()... Cuando el constructor abre un socket, no se le asigna ningún nombre, solo se reserva un descriptor. Se llama al método Bind () para asignar un nombre al socket del servidor. Para que el socket del cliente pueda identificar el socket de transmisión de TCP, el programa del servidor debe nombrar su socket:
SListener.Bind (ipEndPoint);
El método Bind () vincula el socket al punto final local. Debe llamar al método Bind () antes de cualquier intento de llamar a los métodos Listen () y Accept ().
Ahora, después de haber creado un socket y asociado un nombre con él, puede escuchar los mensajes entrantes usando el método Escucha ()... En un estado de escucha, el socket esperará los intentos de conexión entrantes:
SListener.Listen (10);
El parámetro define reserva que especifica el número máximo de conexiones pendientes en la cola. En el código dado, el valor del parámetro permite acumular hasta diez conexiones en la cola.
En el estado de escucha, uno debe estar listo para dar su consentimiento a la conexión con el cliente, para lo cual se utiliza el método. Aceptar ()... Este método obtiene una conexión de cliente y completa los enlaces de nombre de cliente / servidor. El método Accept () bloquea el hilo de la persona que llama hasta que llega una conexión.
El método Accept () recupera la primera solicitud de conexión de la cola de solicitudes pendientes y crea un nuevo socket para manejarla. Aunque se crea el nuevo socket, el socket original continúa escuchando y puede ser multiproceso para recibir múltiples solicitudes de conexión de los clientes. Ninguna aplicación de servidor debería cerrar el conector de escucha. Debería seguir funcionando junto con los sockets creados por el método Accept para manejar las solicitudes entrantes de los clientes.
While (true) (Console.WriteLine ("Esperando una conexión en el puerto (0)", ipEndPoint); // El programa se detiene, esperando una conexión entrante Socket handler = sListener.Accept ();
Una vez que el cliente y el servidor han establecido una conexión entre ellos, puede enviar y recibir mensajes utilizando los métodos Enviar () y Recibir () Clase de enchufe.
El método Send () escribe datos salientes en el socket al que se establece la conexión. El método Receive () lee los datos entrantes en un socket de transmisión. En un sistema basado en TCP, se debe establecer una conexión entre los sockets antes de ejecutar los métodos Send () y Receive (). El protocolo exacto entre las dos entidades que interactúan debe determinarse con anticipación para que las aplicaciones cliente y servidor no se bloqueen entre sí, sin saber quién debe enviar sus datos primero.
Cuando se completa el intercambio de datos entre el servidor y el cliente, debe cerrar la conexión utilizando los métodos Apagar () y Cerrar ():
Handler.Shutdown (SocketShutdown.Both); handler.Close ();
SocketShutdown es una enumeración que contiene tres valores para detener: Ambos- deja de enviar y recibir datos por el zócalo, Recibir- deja de recibir datos en el socket, y Enviar- deja de enviar datos por el zócalo.
El socket se cierra cuando se llama al método Close (), que también establece la propiedad Connected del socket en falso.
Cliente en TCP
Las funciones utilizadas para crear una aplicación cliente se parecen más o menos a una aplicación de servidor. Al igual que con el servidor, se utilizan los mismos métodos para determinar el punto final, crear una instancia del socket, enviar y recibir datos y cerrar el socket.
TCP se integra naturalmente en el entorno cliente / servidor (consulte la Figura 10.1). Aplicación de servidor escucha(escuchar) solicitudes de conexión entrantes. Por ejemplo, los servicios WWW, File Transfer o Terminal Access escuchan las solicitudes de los clientes. La comunicación en TCP se inicia mediante las subrutinas correspondientes, que inician la conexión con el servidor (consulte el capítulo 21 sobre la interfaz de programación de sockets).
Arroz. 10.1. El cliente llama al servidor.
En realidad, el cliente puede ser otro servidor. Por ejemplo, los servidores de correo pueden conectarse a otros servidores de correo para reenviar mensajes Correo electrónico entre computadoras.
10.2 Conceptos de TCP
¿De qué forma las aplicaciones deben enviar datos a través de TCP? ¿Cómo transfiere TCP datos a IP? ¿Cómo identifican los protocolos TCP de envío y recepción la conexión entre las aplicaciones y los elementos de datos necesarios para implementarla? Todas estas preguntas se responden en las siguientes secciones, que describen conceptos básicos de TCP.
10.2.1 Flujos de datos de entrada y salida
Conceptual el modelo de conexión asume que la aplicación envía un flujo de datos a la aplicación del mismo nivel. Al mismo tiempo, puede recibir un flujo de datos de su socio de conexión. TCP proporciona duplex completo modo de funcionamiento (dúplex completo) en el que simultáneamente dos corrientes datos (ver Figura 10.2).
Arroz. 10.2. Las aplicaciones intercambian flujos de datos.
10.2.2 Segmentos
TCP puede transformar el flujo de datos que sale de la aplicación en un formato adecuado para colocarlo en datagramas. ¿Cómo?
La aplicación transmite datos en TCP, y este protocolo los coloca en búfer de salida(enviar búfer). A continuación, TCP corta fragmentos de datos del búfer y los envía, agregando un encabezado (en este caso, segmentos- segmento). En la Fig. 10.3 muestra cómo los datos búfer de salida TCP está empaquetado en segmentos. TCP transmite el segmento a IP para su entrega como un datagrama separado. Empacar los datos en fragmentos de la longitud correcta asegura que los datos se envíen de manera eficiente, por lo que TCP esperará hasta que aparezca la cantidad correspondiente de datos en el búfer de salida antes de crear un segmento.
Arroz. 10,3 Creando un segmento TCP
10.2.3 Expulsión
Sin embargo, a menudo es imposible aplicar grandes cantidades de datos a aplicaciones del mundo real. Por ejemplo, cuando un programa cliente de usuario final inicia una sesión interactiva con un servidor remoto, entonces el usuario solo ingresa comandos (seguido de presionar la tecla Regreso).
El programa cliente del usuario necesita TCP para saber cómo enviar datos al host remoto y hacerlo de inmediato. En este caso, utilice expulsión(empujar).
Si observa las operaciones en una sesión interactiva, puede encontrar muchos segmentos con pocos datos y, lo que es más, se pueden encontrar protuberancias en casi todos los segmentos de datos. Sin embargo, la inserción no debe aplicarse durante las transferencias de archivos (excepto en el último segmento), y TCP podrá empaquetar datos en segmentos de la manera más eficiente.
10.2.4 Datos urgentes
El modelo de reenvío de aplicaciones asume la aplicación de un flujo ordenado de bytes que viaja al destino. Refiriéndose nuevamente al ejemplo de sesión interactiva, suponga que el usuario presionó la tecla atención(atención) o rotura(interrumpir). La aplicación remota debe poder omitir los bytes que interfieren y responder a la pulsación de tecla lo antes posible.
Mecanismo datos urgentes(datos urgentes) marca la información especial en el segmento como urgente. Con esto, TCP informa a su par que el segmento contiene datos urgentes y puede indicar dónde está. El socio debe enviar esta información a la aplicación de destino lo antes posible.
10.2.5 Puertos de aplicación
El cliente debe identificar el servicio al que quiere acceder. Esto se hace mediante la especificación de la dirección IP del servicio del host y su número de puerto TCP. Al igual que con UDP, los números de puerto TCP varían de 0 a 65535. Los puertos en el rango de 0 a 1023 se denominan conocidos y se utilizan para acceder a servicios estándar.
En la Tabla 10.1 se muestran varios ejemplos de puertos conocidos y sus aplicaciones correspondientes. Servicios Descarte(puerto 9) y chargen(puerto 19) son las versiones TCP de los servicios que ya conocemos de UDP. Recuerde que el tráfico del puerto 9 de TCP está completamente aislado del tráfico del puerto 9 de UDP.
Cuadro 10.1 Puertos TCP comúnmente conocidos y sus aplicaciones correspondientes
| Puerto | Solicitud | Descripción |
|---|---|---|
| 9 | Descarte | Cancelar todos los datos entrantes |
| 19 | Chargen | Generador de símbolos. Intercambio de flujo de caracteres |
| 20 | Datos FTP | Puerto de reenvío de datos FTP |
| 21 | FTP | Puerto para conversación FTP |
| 23 | TELNET | Puerto para registro Telnet remoto |
| 25 | SMTP | Puerto SMTP |
| 110 | POP3 | Obtención del servicio de correo para computadoras personales |
| 119 | NNTP | Acceso a noticias online |
¿Qué pasa con los puertos utilizados por los clientes? En casos raros, el cliente no trabaja a través de un puerto conocido. Pero en tales situaciones, al querer abrir una conexión, a menudo le pide al sistema operativo que le asigne un puerto no utilizado y sin reservas. Al final de la conexión, el cliente está obligado a devolver este puerto, después de lo cual el puerto puede ser reutilizado por otro cliente. Dado que hay más de 63.000 puertos TCP en el grupo de números no reservados, se pueden ignorar los límites de puertos del cliente.
10.2.6 direcciones de socket
Como ya sabemos, la combinación de dirección IP y puerto de comunicación se llama enchufe. Una conexión TCP está completamente identificada por la dirección de socket en cada extremo de esa conexión. En la Fig. 10.4 muestra una conexión entre un cliente en el socket (128.36.1.24, puerto = 3358) y un servidor en el socket (130.42.88.22, puerto = 21).
Arroz. 10.4. Direcciones de socket
Cada encabezado de datagrama contiene las direcciones IP de origen y destino. Más adelante se verá que los números de puerto de origen y destino se indican en el encabezado del segmento TCP.
Normalmente, un servidor es capaz de gestionar varios clientes al mismo tiempo. Las direcciones de socket únicas de un servidor se asignan simultáneamente a todos sus clientes (consulte la Figura 10.5).
Arroz. 10.5. Varios clientes conectados a direcciones de socket del servidor
Debido a que un datagrama contiene un segmento de conexión TCP identificado por direcciones IP y puertos, es muy fácil para un servidor realizar un seguimiento de múltiples conexiones de clientes.
10.3 Mecanismo de confiabilidad del TCP
En esta sección, veremos el mecanismo TCP utilizado para entregar datos de manera confiable mientras se mantiene el orden de reenvío y se evita la pérdida o la duplicación.
10.3.1 Numeración y confirmación
TCP utiliza numeración y reconocimiento (ACK) para garantizar una transferencia de datos confiable. El esquema de numeración de TCP es algo inusual: cada conexión reenviada octeto se considera que tiene un número secuencial. El encabezado del segmento TCP contiene el número de secuencia el primer octeto de datos de este segmento.
El receptor debe acusar recibo de los datos. Si no llega ningún ACK dentro del intervalo de tiempo de espera, los datos se retransmiten. Este método se llama reconocimiento positivo con relé(reconocimiento positivo con retransmisión).
Receiver TCP monitorea de cerca los números de secuencia entrantes para garantizar que los datos se reciban de manera consistente y que no falten partes. Dado que los ACK se pueden perder o retrasar aleatoriamente, los segmentos duplicados pueden llegar al destinatario. Los números de secuencia le permiten identificar datos duplicados que luego se descartan.
En la Fig. 10.6 muestra una vista simplificada del tiempo de espera y la retransmisión de TCP.
Arroz. 10.6. Timeout y retransmisión en TCP
10.3.2 Campos de puerto, secuencia y ACK en el encabezado TCP
Como se muestra en la fig. 10.7, los primeros campos del encabezado TCP proporcionan espacio para los puertos de origen y destino, el número de secuencia del primer byte de datos incrustados y un ACK igual al número de secuencia. Siguiente byte esperado en el otro extremo. En otras palabras, si TCP recibe todos los bytes hasta el 30 de su par, este campo tendrá un valor de 31, lo que indica el segmento a reenviar.
Arroz. 10,7. Valores iniciales en campos de encabezado TCP
Cabe señalar un pequeño detalle. Suponga que TCP ha enviado bytes de 1 a 50 o más, no hay datos para enviar. Si se reciben datos de un socio, TCP está obligado a acusar recibo, para lo cual enviará un encabezado sin datos conectados a él. Naturalmente, este encabezado contiene el valor ACK. El campo de secuencia contiene el valor 51, es decir el número del siguiente byte que pretende enviar TCP. Cuando TCP envía los siguientes datos, el nuevo encabezado TCP también tendrá un valor de 51 en el campo de secuencia.
10.4 Establecimiento de una conexión
¿Cómo se conectan las dos aplicaciones entre sí? Antes de la comunicación, cada uno de ellos llama a una subrutina para formar un bloque de memoria que se utilizará para almacenar los parámetros TCP e IP de esta conexión, por ejemplo, direcciones de socket, número de secuencia actual, valor inicial de la vida útil, etc.
La aplicación del servidor espera a que aparezca un cliente que, queriendo acceder al servidor, emite una solicitud de compuesto(conectar) identificando la dirección IP y el puerto del servidor.
Hay una peculiaridad técnica. Cada lado comienza la numeración de cada byte no con uno, sino con número de secuencia aleatorio(a continuación descubriremos por qué se hace esto). La especificación original aconseja: generar un número de secuencia inicial basado en un temporizador externo de 32 bits que se incrementa aproximadamente cada 4 μs.
10.4.1 Script de conexión
El procedimiento de conexión a menudo se denomina protocolo de enlace de tres vías porque se intercambian tres mensajes (SYN, SYN y ACK) para establecer una conexión.
Durante la configuración de la conexión, los socios intercambian tres datos importantes:
1. La cantidad de espacio en el búfer para recibir datos
2. La cantidad máxima de datos transportados en el segmento entrante
3. Número de secuencia inicial utilizado para datos salientes
Tenga en cuenta que cada lado aplica las operaciones 1 y 2 para indicar los límites dentro de los cuales operará la otra parte. Una computadora personal puede tener un búfer de recepción pequeño y una supercomputadora puede tener un búfer enorme. Estructura de la memoria computadora personal puede limitar los fragmentos de datos entrantes a 1 KB, y la supercomputadora se controla con grandes segmentos.
La capacidad de controlar cómo la otra parte envía datos es una propiedad importante para la escalabilidad de TCP / IP.
En la Fig. 10.8 muestra un ejemplo de un script de conexión. Se presentan números secuenciales iniciales muy simples para no abrumar el dibujo. Tenga en cuenta que en esta figura, el cliente puede recibir segmentos más grandes que el servidor.
Arroz. 10,8. Establecer una conexión
Se realizan las siguientes operaciones:
1. El servidor se inicializa y está listo para conectarse a los clientes (este estado se denomina pasivo abierto).
2. El cliente solicita a TCP que abra una conexión con el servidor en la dirección IP y el puerto especificados (este estado se denomina activo abierto).
3. El cliente TCP recibe el número de secuencia inicial (en este ejemplo, 1000) y envía segmento de sincronización(sincronizar segmento - SYN). Este segmento lleva el número de secuencia, el tamaño de la ventana de recepción (4K) y el segmento más grande que el cliente puede aceptar (1460 bytes).
4. Cuando llega un SYN, el servidor TCP recibe mía número de secuencia inicial (3000). Envía un segmento SYN que contiene un número de secuencia inicial (3000), ACK 1001 (lo que significa que el primer byte enviado por el cliente tiene el número 1001), el tamaño de la ventana de recepción (4K) y el segmento más grande que el servidor puede recibir (1024 bytes ).
5. El cliente TCP, habiendo recibido un mensaje SYN / ACK del servidor, devuelve ACK 3001 (el primer byte de los datos enviados por el servidor debe numerarse 3001).
6. El cliente TCP indica a su aplicación que abra una conexión.
7. El servidor TCP, habiendo recibido un mensaje ACK del cliente TCP, informa a su aplicación sobre la apertura de la conexión.
El cliente y el servidor anuncian sus reglas para los datos recibidos, sincronizan sus números de secuencia y están listos para intercambiar datos. La especificación TCP también permite otro escenario (no muy exitoso) en el que las aplicaciones del mismo nivel se abren de forma activa y simultánea.
10.4.2 Configuración de los valores de los parámetros de IP
La solicitud de conexión de la aplicación también puede especificar parámetros para los datagramas IP que llevarán los datos para esa conexión. Si no se especifica ningún valor de parámetro específico, se utiliza el valor predeterminado.
Por ejemplo, una aplicación puede seleccionar el valor deseado para la prioridad de IP o el tipo de servicio. Dado que cada una de las partes conectadas establece independientemente su propia prioridad y tipo de servicio, en teoría, estos valores pueden diferir para diferentes direcciones de los flujos de datos. Como regla, en la práctica, se utilizan los mismos valores para cada sentido de intercambio.
Cuando una aplicación usa opciones de seguridad para agencias gubernamentales o militares, cada uno de los puntos finales de conexión debe usar los mismos niveles de seguridad, o no se establecerá la conexión.
10.5 Transferencia de datos
La transferencia de datos comienza después de completar la confirmación de tres pasos de la creación de la conexión (ver Fig. 10.9). El estándar TCP permite que se incluyan datos normales en segmentos de acuse de recibo, pero no se entregarán a la aplicación hasta que se complete la conexión. Para facilitar la numeración, se utilizan mensajes de 1000 bytes. Cada segmento de encabezado TCP tiene un campo ACK que identifica el número de secuencia del byte que se espera recibir del par en la conexión..
Arroz. 10,9. Flujo de datos simple y ACK
El primer segmento enviado por el cliente contiene bytes de 1001 a 2000. Su campo ACK debe contener un valor de 3001, que indica el número de secuencia del byte que se supone que se recibe del servidor.
El servidor responde al cliente con un segmento que contiene 1000 bytes de datos (comenzando en 3001). Su campo ACK de encabezado TCP indicará que los bytes 1001 a 2000 ya se han recibido correctamente, por lo que el siguiente número de secuencia de segmento esperado debería ser 2001.
Luego, el cliente envía segmentos que comienzan con los bytes 2001, 3001 y 4001 en ese orden. Tenga en cuenta que el cliente no espera un ACK después de cada uno de los segmentos enviados. Los datos se envían al socio hasta que se llena su espacio de búfer (veremos a continuación que el destinatario puede indicar con mucha precisión la cantidad de datos que se le envían).
El servidor conserva ancho de banda utilizando un solo ACK para indicar el reenvío exitoso de todos los segmentos.
En la Fig. 10.10 muestra la transferencia de datos cuando se pierde el primer segmento. Cuando expira el tiempo de espera, el segmento se retransmite. Tenga en cuenta que al recibir el segmento perdido, el receptor envía un ACK confirmando que ambos segmentos fueron enviados.
Arroz. 10.10. Pérdida y retransmisión de datos
10.6 Cerrar una conexión
La terminación normal de una conexión se logra utilizando el mismo procedimiento de triple protocolo de enlace que al abrir una conexión. Cada una de las partes puede comenzar a cerrar la conexión en el siguiente escenario:
A:
B:"Bien".
V:"Yo también terminé el trabajo".
A:"Bien".
El siguiente escenario también es aceptable (aunque rara vez se usa):
A:"Ya terminé. No hay más datos para enviar".
V:"Bien. Sin embargo, hay algunos datos ..."
V:"Yo también terminé el trabajo".
A:"Bien".
En el siguiente ejemplo, la conexión cierra el servidor, como suele ser el caso de las comunicaciones cliente / servidor. En este caso, después de que el usuario ingrese a la sesión telnet logout manda el servidor inicia una solicitud para cerrar la conexión. En la situación mostrada en la Fig. 10.11, se realizan las siguientes acciones:
1. Una aplicación en el servidor le dice a TCP que cierre la conexión.
2. El servidor TCP envía un segmento final (FIN) informando a su par que no hay más datos para enviar.
3. El TCP del cliente envía un ACK en el segmento FIN.
4. El TCP del cliente le dice a su aplicación que el servidor quiere cerrar la conexión.
5. La aplicación cliente le dice a su TCP que cierre la conexión.
6. El TCP del cliente envía un mensaje FIN.
7. El servidor TCP recibe el FIN del cliente y responde con un mensaje ACK.
8. El servidor TCP indica a su aplicación que cierre la conexión.
Arroz. 10.11. Cerrar una conexión
Ambos lados pueden comenzar a cerrar al mismo tiempo. En este caso, el cierre normal de la conexión se completa después de que cada socio envía un mensaje ACK.
10.6.1 Terminación abrupta
Cada una de las partes puede solicitar un cierre brusco de la conexión. Esto es aceptable cuando una aplicación desea terminar una conexión o cuando TCP encuentra un problema de comunicación serio que no puede resolver por sí solo. La terminación abrupta se solicita enviando uno o más mensajes de reinicio al par, como lo indica una bandera específica en el encabezado TCP.
10.7 Control de flujo
El receptor TCP se carga con el flujo de datos entrante y determina cuánta información puede recibir. Esta limitación afecta al remitente de TCP. La explicación a continuación para este mecanismo es conceptual y los desarrolladores pueden implementarlo de diferentes maneras en sus productos.
Durante la configuración de la conexión, cada socio asigna espacio para el búfer de entrada de la conexión y notifica al otro lado de esto. Normalmente, el tamaño del búfer se expresa como un número entero de tamaños máximos de segmento.
El flujo de datos ingresa al búfer de entrada y se almacena allí antes de enviarse a la aplicación (determinado por el puerto TCP). En la Fig. 10.12 muestra un búfer de entrada capaz de aceptar 4 KB.
Arroz. 10.12. Ventana de recepción del búfer de entrada
El espacio del búfer se llena a medida que llegan los datos. Cuando la aplicación receptora obtiene datos del búfer, el espacio liberado queda disponible para nuevos datos entrantes.
10.7.1 Ventana de recepción
Recibiendo ventana(ventana de recepción): cualquier espacio en el búfer de entrada que aún no esté ocupado por datos. Los datos permanecen en el búfer de entrada hasta que los consume la aplicación de destino. ¿Por qué la aplicación no recoge los datos de inmediato?
Un escenario simple ayudará a responder esta pregunta. Suponga que un cliente ha subido un archivo a un servidor FTP que se ejecuta en una computadora multiusuario muy ocupada. El programa FTP debe leer los datos del búfer y escribirlos en el disco. Cuando el servidor está realizando operaciones de E / S de disco, el programa espera a que se completen esas operaciones. En este momento, puede iniciarse otro programa (por ejemplo, según un horario) y mientras el programa FTP se inicia de nuevo, los siguientes datos ya llegarán al búfer.
La ventana de recepción se expande desde el último byte reconocido hasta el final del búfer. En la Fig. 10.12 primero, todo el búfer está disponible y, por lo tanto, está disponible una ventana de recepción de 4 KB. Cuando llegue el primer KB, la ventana de recepción se reducirá a 3 KB (por simplicidad, asumiremos que cada segmento es de 1 KB, aunque en la práctica este valor varía en función de las necesidades de la aplicación). La llegada de los siguientes dos segmentos de 1 KB reducirá la ventana de recepción a 1 KB.
Cada ACK enviado por el receptor contiene información sobre el estado actual de la ventana de recepción, dependiendo de qué flujo de datos desde la fuente esté regulado.
En su mayor parte, el tamaño del búfer de entrada se establece en el momento del inicio de la conexión, aunque el estándar TCP no especifica cómo manejar este búfer. El búfer de entrada puede crecer o reducirse para proporcionar retroalimentación al remitente.
¿Qué sucede si un segmento entrante se puede colocar en la ventana de recepción, pero no llegó en orden? Generalmente se asume que todas las implementaciones almacenan los datos entrantes en la ventana de recepción y envían un acuse de recibo (ACK) solo para un bloque contiguo completo de varios segmentos. Este es el método correcto, porque de lo contrario, descartar datos fuera de orden degradará significativamente el rendimiento.
10.7.2 Ventana Enviar
Un sistema que transmite datos debe realizar un seguimiento de dos características: cuántos datos ya se han enviado y reconocido, y el tamaño actual de la ventana de recepción del destinatario. Activo espacio de despacho(espacio de envío) se expande desde el primer octeto no reconocido a la izquierda de la ventana de recepción actual. Parte ventana usado por mandar, indica cuántos datos adicionales se pueden enviar al socio.
El número de secuencia inicial y el tamaño inicial de la ventana de recepción se establecen durante la configuración de la conexión. Arroz. 10.13 ilustra algunas de las características del mecanismo de transferencia de datos.
1. El remitente comienza con una ventana de envío de 4 KB.
2. El remitente envía 1 KB. Se conserva una copia de estos datos hasta que se recibe un acuse de recibo (ACK), ya que es posible que sea necesario retransmitirlo.
3. Llega el mensaje ACK para el primer KB y se envían los siguientes 2 KB de datos. El resultado se muestra en la tercera parte desde la parte superior de la Fig. 10.13. El almacenamiento de 2 KB continúa.
4. Finalmente, llega un ACK para todos los datos transmitidos (es decir, todos los recibidos por el receptor). ACK restaura el tamaño de la ventana de envío a 4K.
Arroz. 10.13. Enviar ventana
Cabe señalar varias características interesantes:
S El remitente no espera un ACK para cada uno de los segmentos de datos que envía. La única limitación de transferencia es el tamaño de la ventana de recepción (por ejemplo, el remitente solo debe enviar segmentos de un solo byte de 4K).
S Suponga que el remitente envía datos en varios segmentos muy cortos (por ejemplo, 80 bytes). En este caso, los datos se pueden reformatear para una transmisión más eficiente (por ejemplo, en un solo segmento).
10.8 Encabezado TCP
En la Fig. 10.14 muestra el formato del segmento (encabezado y datos TCP). El encabezado comienza con los ID de puerto de origen y destino. Siguiente campo siguiente número de serie(número de secuencia) indica la posición en el flujo de datos salientes que ocupa este segmento. Campo ACK(acuse de recibo) contiene información sobre el siguiente segmento que se espera que aparezca en el flujo de datos de entrada.
Arroz. 10.14. Segmento TCP
Hay seis banderas:
Campo sesgo de datos(Desplazamiento de datos) contiene el tamaño del encabezado TCP en palabras de 32 bits. El encabezado TCP debe terminar en un límite de 32 bits.
10.8.1 Opción para tamaño máximo de segmento
Parámetro "tamaño máximo de segmento"(tamaño máximo de segmento - MSS) se utiliza para anunciar la mayor cantidad de datos que puede recibir y procesar el sistema. Sin embargo, el título es algo inexacto. Generalmente en TCP segmento tratado como encabezado más datos. pero tamaño máximo de segmento definido como:
El datagrama más grande que puede aceptar es 40
En otras palabras, el MSS refleja la mayor carga útil en el receptor con una longitud de encabezados TCP e IP de 20 bytes. Si alguna Opciones extra, su longitud debe restarse del tamaño total. Por tanto, la cantidad de datos que se pueden enviar en un segmento se define como:
Valor declarado de MSS + 40 - (suma de las longitudes de los encabezados de TCP e IP)
Los pares suelen intercambiar valores MSS en los mensajes SYN iniciales cuando se abre una conexión. Si el sistema no anuncia un tamaño máximo de segmento, se utiliza el valor predeterminado de 536 bytes.
El tamaño del segmento máximo se codifica con un preámbulo de 2 bytes seguido de un valor de 2 bytes, es decir, el valor más grande será 2 16 -1 (65 535 bytes).
MSS impone un límite estricto a los datos enviados a TCP: el receptor no podrá procesar valores grandes. Sin embargo, el remitente está usando segmentos. menor, porque la MTU a lo largo de la ruta también se determina para la conexión.
10.8.2 Uso de campos de encabezado en una solicitud de conexión
El primer segmento enviado para abrir una conexión tiene un indicador SYN de 1 y un indicador ACK de 0. El SYN inicial es el único un segmento que tiene un campo ACK de 0. Tenga en cuenta que la seguridad utiliza esta función para detectar solicitudes entrantes para una sesión TCP.
Campo número de serie contiene número de secuencia inicial(número de secuencia inicial), campo ventana - tamaño inicial ventana de recepción. El único parámetro de TCP actualmente definido es el tamaño máximo de segmento (cuando no se especifica, el valor predeterminado es 536 bytes) que TCP espera recibir. Este valor tiene una longitud de 32 bits y generalmente está presente en la solicitud de conexión en el campo opciones(Opción). El encabezado TCP que contiene el valor MSS tiene una longitud de 24 bytes.
10.8.3 Uso de campos de encabezado en la respuesta de conexión
En una respuesta de habilitación a una solicitud de conexión, ambos indicadores (SYN y ACK) son iguales a 1. El sistema que responde indica el número de secuencia inicial en el campo correspondiente y el tamaño de la ventana de recepción en el campo. Ventana. Talla máxima segmento que el destinatario desea utilizar se encuentra generalmente en la respuesta a la solicitud de conexión (en el opciones). Este valor puede ser diferente del valor de la parte que solicita la conexión, es decir se pueden utilizar dos valores diferentes.
Una solicitud de conexión se puede rechazar especificando un indicador de reinicio (RST) con un valor de 1 en la respuesta.
10.8.4 Selección del número de secuencia inicial
La especificación TCP asume que durante el establecimiento de la conexión, cada parte elige número de secuencia inicial(al valor actual del temporizador interno de 32 bits). ¿Cómo se hace esto?
Imagínese lo que sucede cuando el sistema falla. Digamos que el usuario abrió una conexión justo antes del bloqueo y envió una pequeña cantidad de datos. Después de la recuperación, el sistema ya no recuerda nada de lo que se hizo antes del bloqueo, incluidas las conexiones que ya se están ejecutando y los números de puerto asignados. El usuario restablece la conexión. Los números de puerto no coinciden con las asignaciones originales y es posible que algunos de ellos ya estén en uso por otras conexiones establecidas unos segundos antes del bloqueo.
Por lo tanto, el otro lado al final de la conexión puede no saber que su socio sufrió un colapso y su trabajo fue restaurado. Todo esto conducirá a serias interrupciones, especialmente cuando se necesita mucho tiempo para que los datos antiguos viajen a través de la red y se mezclen con los datos de la conexión recién creada. La selección del temporizador del nuevo comienzo elimina estos problemas. Los datos antiguos tendrán una numeración diferente al rango de números de secuencia de la nueva conexión. Los piratas informáticos, cuando falsifican la dirección IP de origen de un host confiable, intentan obtener acceso a las computadoras especificando un número de secuencia inicial predecible en el mensaje. La función hash criptográfica basada en claves internas sirve la mejor manera para seleccionar números de semillas seguros.
10.8.5 Uso común de campos
Al preparar el encabezado TCP para la transmisión, el número de secuencia del primer octeto de los datos transmitidos se indica en el campo numero secuencial(Secuencia de números).
El siguiente número de octeto esperado del socio de conexión se ingresa en el campo confirmación(Número de acuse de recibo) cuando el bit ACK se establece en 1. Campo ventana(Ventana) es para el tamaño actual de la ventana de recepción. Este campo contiene el número de bytes del número de confirmación que se pueden aceptar... Tenga en cuenta que este valor permite un control preciso del flujo de datos. Con este valor, el socio indica el estado real de la ventana de recepción durante la sesión de intercambio.
Si la aplicación apunta a una operación de inserción de TCP, entonces el indicador PUSH se establece en 1. El TCP receptor DEBE responder a este indicador entregando rápidamente datos a la aplicación tan pronto como el remitente quiera enviarlos.
La bandera URGENTE, si se pone a 1, implica transferencia de datos urgentes, y el puntero correspondiente DEBE referirse al último octeto de datos urgentes. Un uso típico de los datos urgentes es enviar señales de cancelación o interrupción desde el terminal.
Los datos urgentes a menudo se denominan información fuera de banda(fuera de banda). Sin embargo, este término es inexacto. Los datos acelerados se envían en un flujo TCP regular, aunque algunas implementaciones pueden tener mecanismos especiales para decirle a la aplicación que reciba datos urgentes, y la aplicación debe verificar el contenido de los datos urgentes antes de que lleguen todos los bytes del mensaje.
El indicador RESET se establece en 1 para cancelar la conexión. El mismo indicador se establece en la respuesta cuando llega un segmento que no está asociado con ninguna de las conexiones TCP actuales.
FIN se establece en 1 para los mensajes de cierre de conexión.
10.8.6 Suma de comprobación
La suma de comprobación de IP es solo para el encabezado de IP, y la suma de comprobación de TCP se calcula para todo el segmento, así como para el pseudoencabezado generado a partir de la cabecera de IP. Al calcular la suma de comprobación de TCP, el campo correspondiente se establece en 0. En la fig. 10.15 muestra un pseudoencabezado muy similar al utilizado en la suma de comprobación UDP.
Arroz. 10.15. El campo de pseudo-encabezado se incluye en la suma de comprobación de TCP
La longitud del TCP se calcula sumando la longitud del encabezado TCP con la longitud de los datos. La suma de comprobación de TCP es obligatorio, no como UDP. El receptor calcula primero la suma de comprobación del segmento recibido y luego la compara con el contenido del campo de suma de comprobación del encabezado TCP. Si los valores no coinciden, el segmento se descarta.
10.9 Ejemplo de segmento TCP
Arroz. 10.16, protocolo del analizador Oledor por Network General, es una secuencia de segmentos TCP. Los primeros tres segmentos establecen una conexión entre el cliente y el servidor. Telnet... El último segmento lleva 12 bytes de datos.
Arroz. 10.16. Visualización del encabezado TCP por Sniffer Analyzer
Analizador Oledor traduce la mayoría de los valores a decimal. Sin embargo, los valores de las banderas se emiten como hexadecimales. La bandera con el valor 12 es 010010. La suma de comprobación también se muestra en forma hexadecimal.
10.10 Soporte de sesión
10.10.1 Sondeo de ventanas
Un emisor rápido y un receptor lento pueden formar una ventana de recepción de 0 bytes. Este resultado se llama cerrando la ventana(Cerrar ventana). Cuando hay espacio libre para actualizar el tamaño de la ventana de recepción, se utiliza ACK. Sin embargo, si dicho mensaje se pierde, ambas partes deberán esperar indefinidamente.
Para evitar esta situación, el remitente establece temporizador almacenado(temporizador persistente) cuando la ventana está cerrada. El valor del temporizador es el tiempo de espera de retransmisión. Al final del temporizador, se envía un segmento al socio ventana que suena(sonda de ventana; algunas implementaciones también incluyen datos). El sondeo hace que el par devuelva un ACK que informa el estado actual de la ventana.
Si la ventana todavía tiene un tamaño cero, el valor del temporizador almacenado se duplica. Este proceso se repite hasta que el temporizador alcanza un máximo de 60 segundos. TCP continuará enviando mensajes de sondeo cada 60 segundos, hasta que se abra la ventana, hasta que el usuario finalice el proceso o hasta que se agote el tiempo de espera de la aplicación.
10.11 Cerrar sesión
10.11.1 Tiempo de espera
El socio de conexión puede fallar o interrumpirse por completo debido a una puerta de enlace o un fallo de comunicación. Existen varios mecanismos para evitar que TCP vuelva a enviar datos.
Al alcanzar el primer umbral para la retransmisión (retransmisión), TCP indica a IP que verifique el enrutador fallido y al mismo tiempo informa a la aplicación del problema. TCP continúa enviando datos hasta que se alcanza el segundo valor límite y solo entonces termina la conexión.
Por supuesto, antes de que esto suceda, puede llegar un mensaje ICMP indicando que el destino es inalcanzable por alguna razón. En algunas implementaciones, incluso entonces, TCP seguirá intentando llegar al destino hasta que expire el intervalo de tiempo de espera (después de lo cual el problema puede solucionarse). A continuación, se informa a la aplicación que el destino es inalcanzable.
La aplicación puede establecer su propio tiempo de espera de entrega de datos y realizar sus propias operaciones al final de este intervalo. La conexión suele estar desconectada.
10.11.2 Mantener la conexión
Cuando una conexión incompleta tiene datos para transferir durante mucho tiempo, obtiene el estado inactivo. Durante un período de inactividad, puede ocurrir una caída o interrupción de la red lineas fisicas comunicación. Tan pronto como la red vuelva a estar operativa, los socios continuarán intercambiando datos sin interrumpir la sesión de comunicación. Esta estrategia estaba en consonancia con los requisitos del Departamento de Defensa.
Sin embargo, cualquier conexión, activa o inactiva, ocupa mucha memoria de la computadora. Algunos administradores necesitan devolver los recursos no utilizados a los sistemas. Por lo tanto, muchas implementaciones de TCP pueden enviar un mensaje sobre manteniendo la conexión(mantener vivo) probando conexiones inactivas. Estos mensajes se envían periódicamente al socio para verificar su existencia en la red. Los mensajes ACK deben recibirse como respuesta. El uso de mensajes keepalive es opcional. Si el sistema tiene esta capacidad, la aplicación puede cancelarla por sus propios medios. Periodo estimado defecto¡el tiempo de espera para mantener una conexión es de dos horas completas!
Recuerde que la aplicación puede configurar su propio temporizador, según el cual, a su propio nivel, decidirá terminar la conexión.
10.12 Rendimiento
¿Qué tan eficiente es TCP? Muchos factores afectan el rendimiento de los recursos, de los cuales la memoria y el ancho de banda son los principales (consulte la Figura 10.17).
Arroz. 10.17. Factores de rendimiento de TCP
El ancho de banda y la latencia en la red física en uso limitarán severamente el ancho de banda. La mala calidad de la transferencia de datos da como resultado un gran volumen de datagramas caídos, lo que provoca la retransmisión y, como resultado, reduce la eficiencia del ancho de banda.
El lado receptor debe proporcionar suficiente espacio de búfer para permitir que el remitente envíe datos sin interrupción. Esto es especialmente importante para las redes de alta latencia en las que hay un intervalo de tiempo prolongado entre el envío de datos y la recepción de un ACK (y cuando se negocia un tamaño de ventana). Para mantener un flujo de datos estable desde la fuente, el lado receptor debe tener una ventana de al menos el producto del ancho de banda y el retraso.
Por ejemplo, si la fuente puede enviar datos a una velocidad de 10,000 bytes / s, y tarda 2 segundos en devolver un ACK, entonces, en el otro lado, debe proporcionar una ventana de recepción de al menos 20,000 bytes; de lo contrario, el flujo de datos no será continuo. Un búfer de recepción de 10.000 bytes reducirá el rendimiento a la mitad.
Otro factor importante para el rendimiento es la capacidad del anfitrión para responder a eventos de alta prioridad y ejecutar rápidamente cambio de contexto, es decir. complete algunas operaciones y cambie a otras. El host puede admitir de forma interactiva varios usuarios locales, por lotes procesos de fondo y decenas de simultaneos conexiones de comunicacion... El cambio de contexto permite que todas estas operaciones sean atendidas mientras se oculta la carga en el sistema. Las implementaciones que integran TCP / IP con el kernel del sistema operativo pueden reducir significativamente la sobrecarga de usar el cambio de contexto.
Se requieren recursos de la CPU de la computadora para procesar los encabezados TCP. Si el procesador no puede calcular rápidamente sumas de comprobación, ralentizará la velocidad de transferencia de datos a través de la red.
Además, los desarrolladores deberían considerar facilitar la configuración de los parámetros TCP para que el administrador de la red pueda personalizarlos para que se adapten a sus requisitos locales. Por ejemplo, la capacidad de ajustar el tamaño del búfer para el ancho de banda y la latencia de la red mejorará drásticamente el rendimiento. Desafortunadamente, muchas implementaciones no prestan suficiente atención a este problema y codifican los parámetros de comunicación.
Supongamos que el entorno de la red es perfecto: hay suficientes recursos y el cambio de contexto es más rápido de lo que los vaqueros sacan sus revólveres. ¿Conseguirás un rendimiento excelente?
No siempre. La calidad del desarrollo de software TCP también es importante. Se han diagnosticado y resuelto muchos problemas de rendimiento a lo largo de los años en varias implementaciones de TCP. Podemos suponer que lo mejor será software, que cumple con RFC 1122, que define los requisitos para la capa de comunicación de los hosts de Internet.
Igualmente importante es la excepción y la aplicación de los algoritmos de Jacobson, Kern y Partridge (estos interesantes algoritmos se comentarán a continuación).
Los desarrolladores de software pueden obtener importantes beneficios al crear programas que eliminen transferencias innecesarias de pequeñas cantidades de datos y tengan temporizadores integrados para liberar recursos de red que no se utilizan actualmente.
10.13 Algoritmos para mejorar el rendimiento
Pasando a la parte bastante compleja de TCP, veremos los mecanismos para mejorar el rendimiento y resolver los cuellos de botella del ancho de banda. En esta sección se tratan los siguientes problemas:
■ Comienzo lento(inicio lento) evita que una gran proporción del tráfico de red se utilice para una nueva sesión, lo que puede generar gastos generales.
■ Recuperación de síndrome de la ventana tonta(síndrome de la ventana tonta) evita que las aplicaciones mal diseñadas sobrecarguen la red con mensajes.
■ ACK retrasado(ACK retardado) reduce la congestión al reducir el número de mensajes de confirmación de envío independientes.
■ Tiempo de espera de retransmisión calculado(tiempo de espera de retransmisión informática) se basa en la negociación del tiempo de sesión en tiempo real, lo que reduce las retransmisiones innecesarias, pero no provoca grandes retrasos en los intercambios de datos realmente necesarios.
■ Ralentizar el reenvío de TCP cuando sobrecargas en la red permite a los enrutadores volver a su modo original y compartir recursos de red para todas las sesiones.
■ Envío ACK duplicados(ACK duplicado) cuando se recibe un segmento fuera de secuencia, permite que los pares lo reenvíen antes de que se agote el tiempo de espera.
10.13.1 Inicio lento
Si todos los electrodomésticos se encienden al mismo tiempo en casa, se producirá una sobrecarga de la red eléctrica. V Red de computadorascomienzo lento evita que se fundan los fusibles de red.
Una nueva conexión que desencadena instantáneamente la transferencia de grandes cantidades de datos en una red ya cargada puede generar problemas. La idea detrás del inicio lento es asegurar que la nueva conexión tenga un inicio exitoso mientras aumenta lentamente la velocidad de transferencia de datos de acuerdo con la carga real en la red. El remitente está limitado por el tamaño de la ventana de carga, no por la gran ventana de recepción.
Ventana de carga(ventana de congestión) comienza con un tamaño de 1 segmento. Para cada segmento con un ACK recibido con éxito, la ventana de carga aumenta en 1 segmento siempre que siga siendo más pequeña que la ventana de recepción. Si la red no está sobrecargada, la ventana de carga alcanzará gradualmente el tamaño de la ventana de recepción. En condiciones normales de reenvío, estas ventanas tendrán el mismo tamaño.
Tenga en cuenta que el inicio lento no es tan lento. Después del primer ACK, el tamaño de la ventana de carga es igual a 2 segmentos, y después de recibir con éxito un ACK para dos segmentos, el tamaño puede aumentar a 8 segmentos. En otras palabras, el tamaño de la ventana crece exponencialmente.
Suponga que en lugar de recibir un ACK, se ha producido una situación de tiempo de espera. El comportamiento de la ventana de carga en este caso se analiza a continuación.
10.13.2 Síndrome de la ventana despistada
En las primeras implementaciones de TCP / IP, los desarrolladores se enfrentaron al fenómeno síndrome de la ventana tonta(Síndrome de la ventana tonta - SWS), que apareció con bastante frecuencia. Para comprender los eventos que tienen lugar, considere el siguiente escenario, que conduce a consecuencias indeseables, pero es bastante posible:
1. La aplicación de envío envía datos rápidamente.
2. La aplicación receptora lee 1 byte de datos del búfer de entrada (es decir, lentamente).
3. El búfer de entrada se llena rápidamente después de la lectura.
4. La aplicación receptora lee 1 byte y TCP envía un ACK que significa "Tengo espacio libre para 1 byte de datos".
5. La aplicación emisora envía un paquete TCP de 1 byte a través de la red.
6. El TCP receptor envía un ACK que significa "Gracias. He recibido un paquete y no tengo más espacio libre".
7. La aplicación receptora vuelve a leer 1 byte y envía un ACK, y todo el proceso se repite.
Una aplicación de recepción lenta espera mucho tiempo a que lleguen los datos y constantemente empuja la información recibida hacia el borde izquierdo de la ventana, realizando una operación completamente inútil que genera tráfico adicional en línea.
Las situaciones de la vida real, por supuesto, no son tan extremas. Un emisor rápido y un receptor lento intercambiarán pequeños fragmentos de datos (en relación con el tamaño máximo del segmento) y cambiarán una ventana de recepción casi completa. En la Fig. 10.18 muestra las condiciones para la aparición del síndrome de la "ventana tonta".
Arroz. 10.18. Reciba búfer de ventana con un espacio libre muy pequeño
Este problema no es difícil de resolver. Tan pronto como la ventana de recepción se reduce menos que el tamaño de destino dado, TCP comienza a engañar al remitente. En esta situación, TCP no debe apuntar al remitente a adicional espacio en la ventana cuando la aplicación receptora lee datos del búfer en pequeños fragmentos. En cambio, los recursos liberados deben mantenerse en secreto para el remitente hasta que haya suficientes. El tamaño recomendado es un segmento, a menos que todo el búfer de entrada contenga un solo segmento (en el último caso, se utiliza un tamaño igual a la mitad del búfer). El tamaño de destino que debe informar TCP se puede expresar como:
mínimo (1/2 búfer de entrada, tamaño máximo de segmento)
TCP comienza a hacer trampa cuando el tamaño de la ventana es menor que este tamaño, y dirá la verdad cuando el tamaño de la ventana no sea menor que el valor obtenido por la fórmula. Tenga en cuenta que no hay ningún daño para el remitente porque la aplicación receptora aún no podría procesar la mayoría de los datos que espera.
La solución propuesta se puede verificar fácilmente en el caso anterior con una salida ACK para cada uno de los bytes recibidos. El mismo método también es adecuado para el caso en el que el búfer de entrada puede almacenar varios segmentos (como suele ser el caso en la práctica). El remitente rápido llenará el búfer de entrada, pero el receptor indicará que no tiene espacio libre para acomodar la información y no abrirá este recurso hasta que su tamaño alcance todo el segmento.
10.13.3 Algoritmo de Nagle
El remitente debe, independientemente del destinatario, excluir la transmisión de segmentos muy cortos, acumulando datos antes de enviar. El algoritmo de Nagle implementa una idea muy simple para reducir la cantidad de datagramas cortos enviados a través de la red.
El algoritmo recomienda retrasar la transferencia de datos (y presionar) esperando el ACK de los datos transmitidos previamente. Los datos acumulados se envían después de recibir un ACK sobre una pieza de información enviada previamente, o después de recibir datos del tamaño de un segmento completo para su envío, o después de que expira un tiempo de espera. Este algoritmo no debe usarse para aplicaciones en tiempo real que necesitan enviar datos lo más rápido posible.
10.13.4 ACK retrasado
Otro mecanismo de mejora del rendimiento es el método de retardo ACK. La reducción del número de ACK reduce la cantidad de ancho de banda que se puede utilizar para reenviar otro tráfico. Si el par TCP retrasa un poco el envío del ACK, entonces:
■ Puede reconocer la recepción de múltiples segmentos con un ACK.
■ La aplicación receptora puede recibir cierta cantidad de datos dentro del intervalo de tiempo de espera; el encabezado de salida se puede incluir en el ACK y no necesita generar un mensaje por separado.
Para evitar retrasos al enviar un flujo de segmentos de tamaño completo (por ejemplo, al intercambiar archivos), se debe enviar un ACK al menos por cada segundo segmento completo.
Muchas implementaciones utilizan un tiempo de espera de 200 ms. Pero el ACK retrasado no ralentiza el tipo de cambio. Cuando llega un segmento corto, todavía hay suficiente espacio libre en el búfer de entrada para recibir nuevos datos y el remitente puede continuar enviando (además, la retransmisión suele ser mucho más lenta). Si llega un segmento completo, debe responderlo con un mensaje ACK en el mismo segundo.
10.13.5 Tiempo de espera de retransmisión
Después de enviar el segmento, TCP establece un temporizador y monitorea la llegada del ACK. Si no se recibe ningún ACK dentro del período de tiempo de espera, TCP retransmite el segmento (relé). Sin embargo, ¿cuál debería ser el período de tiempo muerto?
Si es demasiado corto, el remitente llenará la red con reenvíos de segmentos innecesarios que duplican la información ya enviada. Un tiempo de espera demasiado largo evitará que arregle rápidamente los segmentos que son realmente malos durante la transferencia, lo que reducirá el rendimiento.
¿Cómo elijo la cantidad de tiempo adecuada para un tiempo de espera? Un valor que es bueno para una LAN de alta velocidad no es bueno para una conexión remota de múltiples accesos. Esto significa que el principio de "un valor para todas las condiciones" es claramente inadecuado. Además, incluso para una conexión específica existente, las condiciones de la red pueden cambiar y los retrasos pueden aumentar o disminuir.
Algoritmos de Jacobson, Kern y Partridge (descritos en artículos , Van Jacobson y Mejora de las estimaciones de tiempo de ida y vuelta en protocolos de transporte fiables, Karn y Partridge) permiten que TCP se adapte a las condiciones cambiantes de la red. Estos algoritmos se recomiendan para su uso en nuevas implementaciones. Los cubriremos brevemente a continuación.
El sentido común dicta que la mejor base para estimar el tiempo de espera correcto para una conexión en particular puede ser Tiempo del ciclo(tiempo de ida y vuelta) como el intervalo entre el envío de datos y la recepción de la confirmación de su recepción.
Se pueden obtener buenas decisiones para las siguientes cantidades a partir de estadísticas básicas (consulte la Figura 10.19) que pueden ayudarlo a calcular el tiempo de espera. Sin embargo, no confíe en promedios, ya que más de la mitad de las estimaciones serán mayores que el promedio. Al observar un par de desviaciones, puede obtener estimaciones más correctas, teniendo en cuenta la distribución normal y reduciendo el tiempo de espera de retransmisión demasiado largo.
Arroz. 10.19. Distribución de tiempos de ciclo
No es necesario realizar una gran cantidad de cálculos para obtener estimaciones matemáticas formales de las desviaciones. Se pueden utilizar estimaciones aproximadas basadas en el valor absoluto de la diferencia entre el último valor y la estimación promedio:
Última desviación = | Último ciclo - Promedio |
Otro factor a considerar al calcular el tiempo de espera correcto es el cambio en el tiempo de ciclo debido a las condiciones actuales de la red. Lo que sucedió en la web en el último minuto es más importante que lo que sucedió hace una hora.
Suponga que está calculando un promedio de ciclo para una sesión muy larga. A pesar de que inicialmente la red se cargó ligeramente y determinamos 1000 valores pequeños, luego hubo un aumento en el tráfico con un aumento significativo en la latencia.
Por ejemplo, si 1000 valores dieron un promedio de 170 unidades, pero luego se midieron 50 valores con un promedio de 282, entonces el promedio actual será:
170 × 1000/1050 + 282 × 50/1050 = 175
Más razonable sería el valor tiempo de ciclo suavizado(Tiempo de ida y vuelta suavizado - SRTT), que tiene en cuenta la prioridad de los valores posteriores:
Nuevo SRTT = (1 - α) × (antiguo SRTT) + α × Valor del último ciclo
El valor α está entre 0 y 1. Incrementar un da como resultado una mayor influencia del tiempo de ciclo actual en el promedio suavizado. Dado que las computadoras pueden dividir rápidamente por potencias de 2 desplazando números binarios a la derecha, α siempre se elige para que sea (1/2) n (generalmente 1/8), por lo que:
SRTT nuevo = 7/8 × SRTT antiguo + 1/8 × Tiempo del último ciclo
La Tabla 10.2 muestra cómo la fórmula para SRTT se ajusta al valor actual de SRTT de 230 cuando un cambio en la condición de la red da como resultado un aumento progresivo en el tiempo del ciclo (asumiendo que no ocurre el tiempo de espera). Los valores de la columna 3 se utilizan como los valores de la columna 1 para línea siguiente tablas (es decir, como el antiguo SRTT).
Cuadro 10.2 Calcular el tiempo de ciclo suavizado
| SRTT antiguo | RTT más reciente | (7/8) × (SRTT antiguo) + (1/8) × (RTT) |
|---|---|---|
| 230.00 | 294 | 238.00 |
| 238.00 | 264 | 241.25 |
| 241.25 | 340 | 253.59 |
| 253.59 | 246 | 252.64 |
| 252.64 | 201 | 246.19 |
| 246.19 | 340 | 257.92 |
| 257.92 | 272 | 259.68 |
| 259.68 | 311 | 266.10 |
| 266.10 | 282 | 268.09 |
| 268.09 | 246 | 265.33 |
| 265.33 | 304 | 270.16 |
| 270.16 | 308 | 274.89 |
| 274.89 | 230 | 269.28 |
| 269.28 | 328 | 276.62 |
| 276.62 | 266 | 275.29 |
| 275.29 | 257 | 273.00 |
| 273.00 | 305 | 277.00 |
Ahora viene la cuestión de elegir un valor para el tiempo de espera de retransmisión. El análisis de los tiempos de ciclo revela una desviación significativa de estos valores del promedio actual. Tiene sentido establecer un límite para la magnitud de las desviaciones (desviaciones). Los valores buenos para el tiempo de espera de retransmisión (llamado Retransmission TimeOut - RTO en los estándares RFC) se dan mediante la siguiente fórmula con una restricción de desviación suavizada (SDEV):
T = Tiempo de espera de retransmisión = SRTT + 2 × SDEV
T = SRTT + 4 × SDEV
Para calcular SDEV, primero determine el valor absoluto de la desviación actual:
DEV = | Tiempo del último ciclo: SRTT antiguo |
Luego, la fórmula de suavizado se usa para tener en cuenta el último valor:
Nuevo SDEV = 3/4 × antiguo SDEV + 1/4 × DEV
Queda una pregunta: ¿cuáles son los valores iniciales? Recomendado:
Tiempo de espera inicial = 3 s
SRTT inicial = 0
SDEV inicial = 1,5 s
Van Jacobson definió un algoritmo rápido que calcula el tiempo de espera de retransmisión de manera muy eficiente.
10.13.6 Estadísticas de ejemplo
¿Qué tan bien funcionará el tiempo de espera calculado anteriormente? Se observaron ganancias de rendimiento significativas cuando se realizó el valor resultante. Un ejemplo serían las estadísticas del equipo. netstat recibido en el sistema tigger- un servidor de Internet al que acceden muchos hosts de todo el mundo.
1510769 paquetes (314955304 bytes) recibidos en secuencia
Sistema tigger se retransmitieron menos del 2,5% de los segmentos de datos TCP. Para un millón y medio de segmentos de datos entrantes (el resto son mensajes ACK puros), solo se duplicó el 0,6%. Debe tenerse en cuenta que el nivel de pérdida en los datos de entrada corresponde aproximadamente al nivel de los segmentos de salida. Por tanto, el tráfico de retransmisión inútil constituye aproximadamente el 0,6% del tráfico total.
10.13.7 Cálculos después del reenvío
Las fórmulas anteriores utilizan el valor del tiempo de ciclo como el intervalo entre el envío de un segmento y la recepción de un acuse de recibo. Sin embargo, suponga que no se recibe ningún acuse de recibo durante el período de tiempo de espera y los datos deben volver a enviarse.
El algoritmo de Kern asume que el tiempo de ciclo no debe cambiarse en este caso. El valor actual suavizado del tiempo de ciclo y desviación suavizada conservan sus valores hasta que se reciba un acuse de recibo para enviar un determinado segmento sin reenviarlo. En este punto, los cálculos se reanudan en función de los valores guardados y las nuevas mediciones.
10.13.8 Acciones posteriores a la retransmisión
Pero, ¿qué sucede antes de que se reciba la confirmación? Después de la retransmisión, el comportamiento de TCP cambia radicalmente, principalmente debido a la pérdida de datos debido a la congestión de la red. Por tanto, la reacción al reenvío de datos será:
■ Reducir la velocidad de reenvío
■ Reducir la congestión de la red al reducir el tráfico general.
10.13.9 Frenado exponencial
Después de la retransmisión, el intervalo de tiempo de espera se duplica. Sin embargo, ¿qué sucede si el temporizador se desborda nuevamente? Los datos se enviarán nuevamente y el período de retransmisión se duplicará nuevamente. Este proceso se llama desaceleración exponencial(retroceso exponencial).
Si persiste el fallo de la red, el tiempo de espera se duplicará hasta que se alcance el valor máximo preestablecido (normalmente 1 minuto). Solo se puede enviar un segmento después del tiempo de espera. El tiempo de espera también ocurre cuando se excede el valor predeterminado para el número de transferencias de datos sin recibir un ACK.
10.13.10 Reducir la congestión al reducir la cantidad de datos enviados a través de la red
Reducir la cantidad de datos transferidos es algo más complejo que los mecanismos discutidos anteriormente. Comienza a funcionar, como el inicio lento ya mencionado. Pero, dado que se establece un límite para el nivel de tráfico, que inicialmente puede generar problemas, el tipo de cambio en realidad se ralentizará debido a un aumento en el tamaño de la ventana de carga para un segmento. Debe establecer valores de borde para reducir realmente la velocidad de carga. Primero, se calcula el umbral de peligro:
Límite - 1/2 mínimo (ventana de carga actual, ventana de recepción del socio)
Si el valor obtenido es más de dos segmentos, se usa como límite. De lo contrario, el borde se establece en dos segmentos. Un algoritmo de recuperación completo requiere:
■ Establezca el tamaño de la ventana de carga en un segmento.
S Para cada ACK recibido, aumente la ventana de carga en un segmento hasta que se alcance el límite (muy parecido a un mecanismo de inicio lento).
■ Luego, con cada ACK recibido, agregue un valor más pequeño a la ventana de carga, que se selecciona en función de la tasa de aumento en un segmento para el tiempo del ciclo (el aumento se calcula como MSS / N, donde N es el tamaño del ventana de carga en segmentos).
Un escenario ideal podría simplificar el trabajo del mecanismo de recuperación. Suponga que la ventana de recepción del socio (y la ventana de carga actual) era de 8 segmentos antes de que se detectara el tiempo de espera, y el límite se definió como 4 segmentos. Si la aplicación receptora lee instantáneamente datos del búfer, la ventana de recepción permanece en 8 segmentos.
■ Se envía 1 segmento (ventana de carga = 1 segmento).
■ ACK recibido: se envían 2 segmentos.
■ ACK para 2 segmentos recibidos: se envían 4 segmentos (límite alcanzado).
■ ACK recibido para 4 segmentos. Se envían 5 segmentos.
■ ACK recibido por 5 segmentos. Se envían 6 segmentos.
■ ACK recibido para 6 segmentos. Se envían 7 segmentos.
■ ACK recibido para 7 segmentos. Se envían 8 segmentos (la ventana de carga vuelve a tener el mismo tamaño que la ventana de recepción).
Dado que se requiere el reconocimiento de todos los datos enviados durante el tiempo de espera de retransmisión, el proceso continúa hasta que la ventana de carga alcanza el tamaño de la ventana de recepción. Los eventos que tienen lugar se muestran en la Fig. 10.20. El tamaño de la ventana aumenta exponencialmente, duplicándose durante el período de inicio lento, y al alcanzar el límite, aumenta linealmente.
Arroz. 10.20. Limitar la tasa de transferencia durante la congestión
10.13.11 ACK duplicados
En algunas implementaciones, se utiliza una característica opcional: la denominada reenvío rápido(retransmisión rápida): para acelerar la retransmisión de datos en determinadas condiciones. Su idea principal está relacionada con el envío de ACK adicionales por parte del receptor, lo que indica un vacío en los datos recibidos.
Al recibir un segmento fuera de orden, el receptor envía un ACK apuntando al primer byte. perdió datos (ver Figura 10.21).
Arroz. 10.21. ACK duplicados
El remitente no retransmite instantáneamente los datos porque IP normalmente puede entregar datos al destinatario sin una secuencia de envío. Pero cuando se reciben varios ACK adicionales para datos duplicados (por ejemplo, tres), el segmento faltante se enviará sin esperar a que expire el tiempo de espera.
Tenga en cuenta que cada ACK duplicado indica la recepción de un segmento de datos. Varios ACK duplicados le permiten saber que la red es capaz de entregar suficientes datos y, por lo tanto, no está sobrecargada. Como parte del algoritmo general, se realiza una pequeña reducción en el tamaño de la ventana de carga con un aumento real del tráfico de la red. En este caso, no se aplica el proceso de cambio de tamaño radical al restaurar el trabajo.
Según el estándar Requisitos del anfitrión(requisitos del host) TCP debe hacer el mismo inicio lento que se describe anteriormente al apagar la fuente (extinción de la fuente). Sin embargo, informar de esto no está dirigido ni es efectivo porque la conexión que recibe este mensaje puede no generar demasiado tráfico. Especificación actual Requisitos del enrutador(requisitos del enrutador) indica que los enrutadores no debe enviar mensajes sobre la supresión de la fuente.
10.13.13 Estadísticas de TCP
Finalmente, echemos un vistazo a los mensajes estadísticos del comando netstat, para ver muchos de los mecanismos descritos anteriormente en funcionamiento.
Los segmentos se denominan paquetes.879137 paquetes de datos (226966295 bytes)
21815 paquetes de datos (8100927 bytes) retransmitidosReenvío.
132957 paquetes solo ack (104216 retrasados)Observamos una gran cantidad
ACK retrasado.
Sonda de apertura de la ventanatamaño cero.
Estos son mensajes SYN y FIN.762469 acks (para 226904227 bytes)Alerta de paquetes que llegan
fuera de secuencia.
1510769 paquetes (314955304 bytes)
9006 paquetes completamente duplicados (867042 bytes)El resultado del tiempo de espera cuando el real
entrega de datos.
74 paquetes con algo de dup. datos (12193 bytes engañados)Para una mayor eficiencia
algunos de los datos se volvieron a empaquetar para incluir bytes adicionales cuando se volvieron a enviar.
13452 paquetes fuera de orden (2515087 bytes)
530 paquetes (8551 bytes) de datos después de la ventanaQuizás este dato fue
incluido en los mensajes de detección.
402 paquetes recibidos después del cierreEstas son reposiciones de seguimiento
enviando.
108 descartados por sumas de verificación incorrectasSuma de comprobación TCP no válida.
0 descartado por campos de desplazamiento de encabezado incorrectos
7 descartado porque el paquete es demasiado corto
14677 conexiones establecidas (incluidas aceptaciones)
18929 conexiones cerradas (incluidas 643 caídas)
4100 conexiones embrionarias caídas
572187 segmentos actualizados rtt (de 587397 intentos)Intentos de cambio fallidos
el tiempo del ciclo, porque el ACK no tuvo tiempo de llegar antes de que expire el tiempo de espera,
26 conexiones caídas por rexmit timeoutIntentos posteriores fallidos
reenvío, que indica una conexión perdida.
Tiempo de espera de sondeoventana cero.
Tiempos de espera de pagoconexión rota.
472 conexiones caídas por keepalive
10.14 Cumplimiento de los requisitos del desarrollador
El estándar TCP actual requiere que las implementaciones se adhieran a un procedimiento de inicio lento al inicializar una conexión y utilicen los algoritmos Kern y Jacobson para estimar el tiempo de espera de retransmisión y administrar la carga. Las pruebas han demostrado que estos mecanismos conducen a mejoras significativas en el rendimiento.
¿Qué sucede si instala un sistema que no cumple con estos estándares? No podrá proporcionar un rendimiento adecuado para sus propios usuarios y será un vecino deficiente para otros sistemas de la red, lo que evitará que se restaure el funcionamiento normal después de una congestión temporal y generará un tráfico excesivo que resultará en la pérdida de datagramas.
10.15 Barreras al desempeño
TCP ha demostrado su flexibilidad, operando en redes con tasas de cambio de cientos o millones de bits por segundo. Este protocolo ha permitido obtener buenos resultados en los redes de área local con topologías Ethernet, Token-Ring y Fiber Distributed Data Interface (FDDI), y para enlaces de baja velocidad o enlaces de larga distancia (como enlaces por satélite).
TCP está diseñado para responder a condiciones extremas como la congestión de la red. Sin embargo, la versión actual del protocolo tiene características que limitan el rendimiento en tecnologías prometedoras que ofrecen un ancho de banda de cientos y miles de megabytes. Para comprender los problemas que surgen, considere un ejemplo simple (aunque poco realista).
Suponga que al mover un archivo entre dos sistemas, desea intercambiar un flujo continuo de la manera más eficiente posible. Asumamos que:
■ El tamaño máximo del segmento de destino es 1 KB.
■ Ventana de recepción: 4 Kbytes.
■ El ancho de banda permite enviar dos segmentos en 1 segundo.
■ La aplicación receptora consume datos a medida que llegan.
Los mensajes S ACK llegan en 2 segundos.
El remitente puede enviar datos de forma continua. Después de todo, cuando el volumen asignado a la ventana está lleno, llega un ACK que permite el envío de otro segmento:
Después de 2 s:
RECIBIR ACK DE SEGMENTO 1, PUEDE ENVIAR SEGMENTO 5.
RECIBIR ACK DEL SEGMENTO 2, PUEDE ENVIAR EL SEGMENTO 6.
RECIBIR RECUERDO DEL SEGMENTO 3, PUEDE ENVIAR EL SEGMENTO 7.
RECIBIR ACK DEL SEGMENTO 4, PUEDE ENVIAR EL SEGMENTO 8.
Después de otros 2 s:
RECIBIR ACK DEL SEGMENTO 5, PUEDE ENVIAR EL SEGMENTO 9.
Si la ventana de recepción fuera de solo 2 KB, el remitente tendría que esperar un segundo de cada dos antes de enviar los siguientes datos. De hecho, para mantener un flujo continuo de datos, la ventana de recepción debe ser al menos:
Ventana = Ancho de banda × Tiempo de ciclo
Aunque el ejemplo es algo exagerado (para proporcionar números más simples), la ventana pequeña puede generar problemas con las conexiones satelitales de alta latencia.
Ahora echemos un vistazo a lo que sucede con las conexiones de alta velocidad. Por ejemplo, si el ancho de banda y la tasa de transferencia se miden a 10 millones de bits por segundo, pero el tiempo de ciclo es de 100 ms (1/10 de segundo), entonces, para un flujo continuo, la ventana de recepción debe almacenar al menos 1,000,000 de bits, es decir ... 125.000 bytes. Pero el número más grande que se puede escribir en el campo de encabezado de una ventana de recepción de TCP es 65.536.
Otro problema ocurre a altas velocidades de transmisión, ya que los números de secuencia se agotan muy rápidamente. Si la conexión puede transferir datos a una velocidad de 4 GB / s, los números de secuencia deben actualizarse cada segundo. No será posible distinguir entre datagramas duplicados antiguos que se han retrasado más de un segundo mientras navegaban por Internet a partir de datos nuevos y frescos.
Se están realizando nuevas investigaciones para mejorar TCP / IP y eliminar las barreras mencionadas.
10.16 funciones TCP
Este capítulo se centra en las muchas características de TCP. Los principales se enumeran a continuación:
■ Vinculación de puertos a conexiones
■ Inicialización de conexiones mediante confirmación de 3 pasos
■ Realiza un inicio lento para evitar la congestión de la red.
■ Segmentación de datos en tránsito
■ Numeración de datos
■ Manejo de segmentos duplicados entrantes
■ Cálculo de sumas de comprobación
■ Regulación del flujo de datos a través de la ventana de recepción y la ventana de envío.
■ Terminar una conexión la forma establecida
■ Terminar la conexión
■ Reenvío de datos urgentes
■ Confirmación positiva de reenvío
■ Cálculo del tiempo de espera de retransmisión
■ Reducción del tráfico de retorno durante la congestión de la red.
■ Alarma por llegada de segmento fuera de servicio
■ Detectando el cierre de la ventana receptora
10.17 estados de TCP
Una conexión TCP pasa por varias etapas: la conexión se establece mediante el intercambio de mensajes, luego se envían los datos y luego se cierra la conexión mediante el intercambio de mensajes especiales. Cada paso en el trabajo de la conexión corresponde a un cierto condición esta conexión. El software TCP en cada extremo de la conexión monitorea continuamente Estado actual el otro lado de la conexión.
A continuación, veremos brevemente una transición de estado típica del servidor y el cliente ubicados en diferentes extremos de la conexión. No pretendemos dar una descripción exhaustiva de todos los estados posibles al transferir datos. Se encuentra en RFC 793 y en Requisitos del anfitrión.
Durante el establecimiento de conexiones, el servidor y el cliente pasan por secuencias de estados similares. Los estados del servidor se muestran en la Tabla 10.3 y los estados del cliente se muestran en la Tabla 10.4.
Cuadro 10.3 Secuencia de estado del servidor
| Estado del servidor | Evento | Descripción |
|---|---|---|
| CERRADO (cerrado) | Un estado ficticio antes de iniciar una conexión. | |
| Apertura pasiva por aplicación de servidor. | ||
| ESCUCHAR (seguimiento) | El servidor está esperando una conexión de cliente. | |
| El servidor TCP recibe un SYN y envía un SYN / ACK. | El servidor recibió un SYN y envió un SYN / ACK. Va a esperar ACK. | |
| SYN-RECIBIDO | El servidor TCP recibe el ACK. | |
| ESTABLECIDO (instalado) | ACK recibido, conexión abierta. |
Cuadro 10.4 Secuencia de estado del cliente
Si los socios intentaran simultáneamente establecer una conexión entre ellos (lo que ocurre muy raramente), cada uno pasaría por los estados CERRADO, SINCRONIZADO, SINCRONIZADO Y ESTABLECIDO.
Los extremos de la conexión permanecen en el estado ESTABLECIDO hasta que uno de los lados inicia clausura conexiones enviando un segmento FIN. Durante un cierre normal, la fiesta que inicia ese cierre pasa por los estados que se muestran en la Tabla 10.5. Su pareja pasa por los estados que se muestran en la tabla 10.6.
Cuadro 10.5 Secuencia de estado de la parte que cierra la conexión
| Estados del lado de cierre | Evento | Descripción |
|---|---|---|
| ESTABLECIDO | Aplicación local pide cerrar la conexión. | |
| TCP envía FIN / ACK. | ||
| FIN-WAIT-1 | La parte de cobertura espera la respuesta del socio. Recuerde que es posible que aún lleguen nuevos datos del socio. | |
| TCP recibe ACK. | ||
| FIN-WAIT-2 | El lado de cierre ha recibido un ACK del socio, pero el FIN aún no ha llegado. El lado de cierre espera un FIN, aceptando los datos entrantes. | |
| TCP recibe FIN / ACK. | ||
| Envía ACK. | ||
| TIEMPO DE ESPERA | La conexión se mantiene en un estado indeterminado para permitir que lleguen o descarten datos duplicados o FIN duplicados que aún existen en la red. El período de espera es el doble de la vida útil máxima estimada del segmento. | |
| CERRADO |
Cuadro 10.6 Secuencia de estados asociados para cerrar una conexión
| Estado de socio | Evento | Descripción |
|---|---|---|
| ESTABLECIDO | TCP recibe FIN / ACK. | |
| CERRAR-ESPERAR | FIN ha llegado. | |
| TCP envía ACK. | ||
| TCP espera a que su aplicación cierre la conexión. En este punto, la aplicación puede enviar una gran cantidad de datos. | ||
| La aplicación local inicia el cierre de la conexión. | ||
| TCP envía FIN / ACK. | ||
| ÚLTIMO ACK | TCP está esperando el ACK final. | |
| TCP recibe ACK. | ||
| CERRADO | Se eliminó toda la información de conexión. |
10.17.1 Análisis de los estados de la conexión TCP
Mando netstat -an le permite comprobar el estado actual de la conexión. Las conexiones en los estados se muestran a continuación escuchar, puesta en marcha, establecido, cierre y Tiempo de espera.
Tenga en cuenta que el número de puerto de conexión aparece al final de cada dirección local y externa. Puede ver que hay tráfico TCP para las colas de entrada y salida.
Pro Recv-Q Send-Q Dirección local Dirección extranjera (estado)
Tcp 0 0 128.121.50.145.25 128.252.223.5.1526 SYN_RCVD
Tcp 0 0128.121.50.145.25 148.79.160.65.3368 ESTABLECIDO
Tcp 0 0127.0.0.1.1339 127.0.0.1.111 TIME_WAIT
Tcp 0438128.121.50.145.23 130.132.57.246.2219 ESTABLECIDO
Tcp 0 0128.121.50.145.25 192.5.5.1.4022 TIME_WAIT
Tcp 0 0128.121.50.145.25 141.218.1.100.3968 TIME_WAIT
Tcp 0848128.121.50.145.23 192.67.236.10.1050 ESTABLECIDO
Tcp 0 0128.121.50.145.1082 128.121.50.141.6000 ESTABLECIDO
Tcp 0 0128.121.50.145.1022 128.121.50.141.1017 ESTABLECIDO
Tcp 0 0128.121.50.145.514 128.121.50.141.1020 CLOSE_WAIT
Tcp 0 1152128.121.50.145.119 192.67.239.23.3572 ESTABLECIDO
Tcp 0 0128.121.50.145.1070 192.41.171.5.119 TIME_WAIT
Tcp 579 4096128.121.50.145.119 204.143.19.30.1884 ESTABLECIDO
Tcp 0 0128.121.50.145.119 192.67.243.13.3704 ESTABLECIDO
Tcp 0 53128.121.50.145.119 192.67.236.218.2018 FIN_WAIT_1
Tcp 0 0128.121.50.145.119 192.67.239.14.1545 ESTABLECIDO
10.18 Notas de implementación
Desde el principio, TCP fue diseñado para interoperar equipos de red de diferentes fabricantes. La especificación TCP no especifica exactamente cómo deberían funcionar las estructuras de implementación internas. Estas preguntas se dejan para que los desarrolladores encuentren los mejores mecanismos para cada implementación específica.
Incluso RFC 1122 (documento Requisitos de host: requisitos del anfitrión) deja suficiente espacio para la variación. Cada una de las funciones implementadas está marcada con un cierto nivel de compatibilidad:
■ MAYO (permitido)
■ NO DEBE
Desafortunadamente, a veces hay productos que no implementan los requisitos MUST. Como resultado, los usuarios experimentan inconvenientes en la degradación del rendimiento.
Algunas buenas prácticas de implementación no se consideran en los estándares. Por ejemplo, es posible mejorar la seguridad limitando el uso de puertos conocidos por los procesos del sistema privilegiado, si en el local sistema operativo este método es compatible. Para maximizar el rendimiento, las implementaciones deben tener la menor cantidad posible de copias y movimientos de datos enviados o recuperados.
API estándar indefinido(así como la política de seguridad), para que haya un campo de actividad libre para experimentar con diferentes kits herramientas de software... Sin embargo, esto puede resultar en el uso de diferentes API en cada plataforma y evitará que el software de la aplicación se mueva entre plataformas.
De hecho, los desarrolladores basan sus kits de herramientas en la API de Socket de Berkeley. La importancia de la interfaz de programación ha aumentado con la llegada de WINSock (Windows Socket), que ha dado lugar a un rápido aumento de nuevas aplicaciones para sistemas de escritorio que podría ejecutarse sobre cualquier interfaz WINSock compatible con la pila TCP / IP.
10.19 Lecturas adicionales
El estándar TCP original se define en RFC 793. Las actualizaciones, correcciones y requisitos de interoperabilidad se tratan en RFC 1122. Kern (Kash) y Partridge (Partridge) publicaron un artículo Mejora de las estimaciones de viajes de ida y vuelta en protocolos de transporte fiables En la revista Actas del ACM SIGCOMM 1987. El artículo de Jacobson Evitación y control de la congestión apareció en Actas del Taller ACM SIGCOMM 1988. Jacobson también ha publicado varios RFC que revisan los algoritmos de mejora del rendimiento.
Viajando por protocolos de red.
TCP y UDP son ambos protocolos capa de transporte... UDP es un protocolo sin conexión con entrega de paquetes no segura. TCP (Protocolo de control de transmisión) es un protocolo orientado a la conexión con entrega de paquetes garantizada. Primero hay un apretón de manos (Hola. | Hola. | ¿Charlemos? | Vamos.), Después de lo cual la conexión se considera establecida. Además, los paquetes se envían de un lado a otro a través de esta conexión (hay una conversación) y se comprueba si el paquete ha llegado al destinatario. Si el paquete se pierde, o llegó, pero con un poco de suma de comprobación, se envía de nuevo ("repetir, no se escuchó"). Por lo tanto, TCP es más confiable, pero es más complicado desde el punto de vista de la implementación y, por lo tanto, requiere más reloj / memoria, lo que no es lo menos importante para los microcontroladores. Los ejemplos de protocolos de aplicación que utilizan TCP incluyen FTP, HTTP, SMTP y muchos otros.
TL; DR
HTTP (Protocolo de transferencia de hipertexto) es un protocolo de aplicación a través del cual el servidor envía páginas a nuestro navegador. HTTP ahora es omnipresente en La red mundial para obtener información de sitios web. La imagen muestra una luz en un microcontrolador con un sistema operativo a bordo, en el que los colores se configuran a través del navegador.
El protocolo HTTP es textual y bastante simple. En realidad, así es como se ve el método GET, enviado por la utilidad netcat a la dirección IPv6 local del servidor con luces:
~ $ nc fe80 :: 200: e2ff: fe58: b66b% mazko 80< El método HTTP suele ser una palabra inglesa corta, en mayúsculas, que distingue entre mayúsculas y minúsculas. Cada servidor debe admitir al menos los métodos GET y HEAD. Además de los métodos GET y HEAD, a menudo se utilizan los métodos POST, PUT y DELETE. El método GET se utiliza para solicitar el contenido del recurso especificado, en nuestro caso aquí GET / b HTTP / 1.0 donde la ruta / b es responsable del color (azul). Respuesta del servidor: HTTP / 1.0 200 OK Servidor: Contiki / 2.4 http://www.sics.se/contiki/ Conexión: cerrar Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Caduca: 0 Contenido- tipo: texto / html El rojo está APAGADO El verde está APAGADO El azul está encendido
El código de estado (tenemos 200) es parte de la primera línea de la respuesta del servidor. Es un número entero de tres dígitos. El primer dígito indica la clase de la condición. El código de respuesta suele ir seguido de una frase explicativa en inglés, separada por un espacio, que explica a la persona el motivo de esta respuesta en particular. En nuestro caso, el servidor funcionó sin errores, todo en un montón (OK).
Tanto la solicitud como la respuesta contienen encabezados (cada línea es un campo de encabezado separado, el par nombre-valor está separado por dos puntos). Los encabezados terminan con una línea vacía, después de la cual pueden ir los datos.
Mi navegador se niega a abrir la dirección IPv6 local, por lo que se escribe una dirección adicional en el firmware del microcontrolador y también se debe asignar el mismo prefijo a la interfaz de red virtual del simulador:
~ $ sudo ip addr add abcd :: 1/64 dev mazko # linux ~ $ netsh interface ipv6 set address mazko abcd :: 1 # windows ~ $ curl http: //
Los servidores que implementan estos protocolos en la red corporativa proporcionan al cliente una dirección IP, puerta de enlace, máscara de red, servidores de nombres e incluso una impresora. Los usuarios no necesitan configurar manualmente sus hosts para utilizar la red.
El sistema operativo QNX Neutrino implementa otro protocolo plug-and-play llamado AutoIP, que es un proyecto del comité de autoconfiguración del IETF. Este protocolo se utiliza en redes pequeñas para asignar direcciones IP a hosts que son de enlace local. El protocolo AutoIP determina de forma independiente la dirección IP local al canal, utilizando un esquema de negociación con otros hosts y sin contactar a un servidor central.
Usando el protocolo PPPoE
PPPoE son las siglas de Point-to-Point Protocol over Ethernet. Este protocolo encapsula datos para su transmisión a través de una red Ethernet en puente.
PPPoE es una especificación para conectar usuarios de Ethernet a Internet a través de una conexión de banda ancha, como una línea alquilada, un dispositivo inalámbrico o un módem por cable. El uso de PPPoE y un módem de banda ancha proporciona a los usuarios de la red informática local acceso individual autenticado a redes de datos de alta velocidad.
PPPoE combina Ethernet con PPP para crear de manera eficiente una conexión separada a un servidor remoto para cada usuario. El control de acceso, la contabilidad de conexiones y la selección del proveedor de servicios son específicos del usuario, no específicos del host. La ventaja de este enfoque es que ni la compañía telefónica ni el proveedor de servicios de Internet están obligados a proporcionar ningún apoyo especial para ello.
A diferencia de las conexiones de acceso telefónico, las conexiones de módem de cable y DSL siempre están activas. Dado que la conexión física a un proveedor de servicios remoto es compartida por varios usuarios, se necesita un método de contabilidad que registre los remitentes y destinos del tráfico y cobre a los usuarios. PPPoE permite a un usuario y un host remoto que participan en una comunicación conocer las direcciones de red de cada uno durante un intercambio inicial llamado detección(descubrimiento). Una vez que se ha establecido una sesión entre un usuario individual y un sitio remoto (como un proveedor de servicios de Internet), se puede monitorear la sesión para detectar acumulaciones. En muchos hogares, hoteles y corporaciones, el acceso a Internet se comparte a través de líneas de abonados digitales que utilizan tecnología Ethernet y PPPoE.
Una conexión PPPoE consta de un cliente y un servidor. El cliente y el servidor funcionan utilizando cualquier interfaz que se acerque a las especificaciones de Ethernet. Esta interfaz se utiliza para emitir direcciones IP a los clientes, vinculando esas direcciones IP a los usuarios y, opcionalmente, a las estaciones de trabajo, en lugar de la autenticación exclusiva de la estación de trabajo. El servidor PPPoE crea una conexión punto a punto para cada cliente.
Establecimiento de una sesión PPPoE
Para crear una sesión PPPoE, debe utilizar el serviciopppoed... Móduloio-pkt- * nProporciona servicios de protocolo PPPoE. Primero necesitas correrio-pkt- *conconductor adecuado... Ejemplo: