Tecnologías tcp ip y udp sus diferencias. Protocolos de transferencia de datos TCP y UDP. Modelo de servicio TCP

Protocolo de datagramas de usuario (UDP)(User Datagram Protocol) es un protocolo del estándar TCP/IP, definido en RFC 768, "User Datagram Protocol (UDP)". Se utiliza UDP en lugar de TCP para transportar datos de forma rápida y poco confiable entre hosts TCP/IP.

protocolo UDP proporciona un servicio sin conexión, por lo que UDP no garantiza la entrega ni las comprobaciones de secuencia de ningún datagrama. Anfitrión que necesita comunicación confiable debe usar cualquiera de los dos protocolo TCP o un programa que monitoreará por sí mismo la secuencia de datagramas y confirmará la recepción de cada paquete.

Las aplicaciones urgentes suelen utilizar UDP (datos de vídeo) porque es preferible descartar paquetes en lugar de esperar paquetes retrasados, lo que puede no ser posible en sistemas en tiempo real. Además, la pérdida de uno o más fotogramas al transmitir datos de vídeo a través de UDP no es tan crítica como al transmitir archivos binarios, donde la pérdida de un paquete puede provocar la corrupción de todo el archivo. Otra ventaja del protocolo UDP es que la longitud del encabezado UDP es de 4 bytes, mientras que el protocolo TCP tiene 20 bytes.

Los mensajes UDP se encapsulan y transmiten en datagramas IP.

encabezado UDP

La figura muestra los campos presentes en el encabezado UDP.

• Puerto del remitente: este campo especifica el número de puerto del remitente. Se supone que este valor especifica el puerto al que se enviará una respuesta si es necesario. De lo contrario, el valor debería ser 0. Si el host de origen es un cliente, lo más probable es que el número de puerto sea efímero. Si la fuente es un servidor, entonces su puerto será uno de los "conocidos".
• Puerto del destinatario: este campo es obligatorio y contiene el puerto del destinatario. De manera similar al puerto de origen, si el cliente es el host del destinatario, entonces el número de puerto es efímero; de lo contrario (el servidor es el destinatario) es un "puerto conocido".
• La longitud del datagrama es un campo que especifica la longitud de todo el datagrama (encabezado y datos) en bytes. La longitud mínima es igual a la longitud del encabezado: 8 bytes. Teóricamente, el tamaño máximo de campo es 65535 bytes para un datagrama UDP (8 bytes para encabezado y 65527 para datos). El límite real de longitud de datos cuando se utiliza IPv4 es 65507 (además de los 8 bytes por encabezado UDP, se requieren otros 20 por encabezado IP).
• Suma de comprobación: el campo de suma de comprobación se utiliza para comprobar si hay errores en el encabezado y los datos. Si el transmisor no genera la cantidad, entonces el campo se llena con ceros.

Veamos la estructura del encabezado. UDP mediante el uso analizador de red Tiburón de alambre:

Puertos UDP

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

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 UDP brindan la capacidad de enviar y recibir mensajes UDP. El puerto UDP funciona como una única cola de mensajes para recibir todos los datagramas destinados al programa. indicado por el número puerto de protocolo. Esto significa que los programas UDP pueden recibir más de un mensaje a la vez.

Todos los números de puerto UDP inferiores a 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.

Cada el puerto UDP identificado por un número de puerto reservado o conocido. La siguiente tabla muestra una lista parcial de números de puertos UDP conocidos que utilizan los programas UDP estándar.

Los protocolos de capa de transporte, que siguen en la jerarquía a IP, se utilizan para transferir datos entre procesos de aplicaciones que se ejecutan en nodos de red. Un paquete de datos recibido de un ordenador a otro a través de Internet debe transferirse al proceso manejador, y precisamente para un fin específico. La capa de transporte asume la responsabilidad de esto. Hay dos protocolos principales en esta capa: TCP y UDP.

Definición

tcp — protocolo de transporte Transmisión de datos en redes TCP/IP, que preestablece una conexión a la red.

UDP- un protocolo de transporte que transmite mensajes de datagramas sin necesidad de establecer una conexión en una red IP.

Comparación

La diferencia entre los protocolos TCP y UDP es la llamada "garantía de entrega". TCP requiere una respuesta del cliente a quien se le entregó el paquete de datos, confirmación de entrega, y para ello necesita una conexión preestablecida. Además, el protocolo TCP se considera confiable, mientras que UDP incluso recibió el nombre de “protocolo de datagramas no confiable”. TCP elimina la pérdida de datos, la duplicación y mezcla de paquetes y los retrasos. UDP permite todo esto y no requiere conexión para funcionar. Los procesos que reciben datos vía UDP deben conformarse con lo que reciben, incluso con pérdidas. TCP controla la congestión de la conexión, UDP no controla nada más que la integridad de los datagramas recibidos.

Por otro lado, debido a esta indiscriminación y falta de control, UDP entrega paquetes de datos (datagramas) mucho más rápido, por lo tanto, para aplicaciones diseñadas para un gran ancho de banda y intercambio rápido UDP puede considerarse el protocolo óptimo. Entre ellos se incluyen juegos de red y de navegador, así como programas de visualización de vídeo en streaming y aplicaciones para comunicación por vídeo (o voz): la pérdida de un paquete, total o parcial, no cambia nada, no es necesario repetir la solicitud, pero el la descarga es mucho más rápida. El protocolo TCP, al ser más fiable, se utiliza con éxito incluso en programas de correo, permitiéndole controlar no solo el tráfico, sino también la longitud del mensaje y la velocidad del intercambio de tráfico.

Sitio web de conclusiones

1. TCP garantiza la entrega de paquetes de datos sin cambios, en secuencia y sin pérdidas, UDP no garantiza nada.
2. TCP requiere por adelantado conexión establecida, No se requiere conexión UDP.
3. UDP proporciona más alta velocidad transmisión de datos.
4. TCP es más confiable y controla el proceso de intercambio de datos.
5. Se prefiere UDP para programas que reproducen Transmitiendo video, videofonía y telefonía, juegos en red.

protocolo UDP

Protocolo de datagramas de usuario (UDP) es un protocolo simple, sin conexión y orientado a datagramas que proporciona un servicio de transporte rápido, pero no necesariamente confiable. Admite interacciones de uno a muchos y, por lo tanto, se utiliza a menudo para la transmisión de datagramas de difusión y multidifusión.

El Protocolo de Internet (IP) es el protocolo principal de Internet. El Protocolo de control de transmisión (TCP) y UDP son protocolos de capa de transporte creados sobre un protocolo subyacente.

TCP/IP es un conjunto de protocolos, también llamado Conjunto de Protocolos de Internet, que consta de cuatro capas. Recuerde que TCP/IP no es sólo un protocolo, sino una familia o conjunto de protocolos que consta de otros protocolos de nivel inferior como IP, TCP y UDP. UDP se encuentra en la capa de transporte encima de IP (protocolo capa de red). La capa de transporte proporciona comunicación entre redes a través de puertas de enlace. Utiliza direcciones IP para enviar paquetes de datos a través de Internet u otra red utilizando una variedad de controladores de dispositivos.

Antes de empezar a estudiar trabajo UDP, pasemos a la terminología básica que necesita conocer bien. A continuación definiremos brevemente los principales términos asociados a UDP:

Paquetes

En las comunicaciones de datos, un paquete es una secuencia de dígitos binarios que representan datos y señales de control que se transmiten y conmutan a través del host. Dentro del paquete, esta información se encuentra de acuerdo con un formato especial.

Datagramas

Un datagrama es un paquete de datos único e independiente que contiene suficiente información para viajar desde el origen al destino, por lo que no hay intercambio adicional entre el origen, el destino y el destino. red de transporte no requerido.

MTU ( Transmisión máxima Unidad)

MTU caracteriza capa de enlace y corresponde al número máximo de bytes que se pueden transmitir en un paquete. En otras palabras, la MTU es el paquete más grande que puede transportar un entorno de red determinado. Por ejemplo, Ethernet tiene una MTU fija de 1500 bytes. En UDP, si el tamaño del datagrama es mayor que la MTU, el protocolo IP realiza la fragmentación dividiendo el datagrama en partes más pequeñas (fragmentos) para que cada fragmento sea más pequeño que la MTU.

Puertos

Para hacer coincidir los datos entrantes con un proceso específico que se ejecuta en una computadora, UDP utiliza puertos. UDP reenvía el paquete a la ubicación adecuada utilizando el número de puerto especificado en el encabezado UDP del datagrama. Los puertos están representados por números de 16 bits y, por lo tanto, toman valores que van de 0 a 65 535. Los puertos, que también se denominan puntos finales de conexión lógica, se dividen en tres categorías:

Puertos conocidos: de 0 a 1023

Puertos registrados: de 1024 a 49151

Puertos dinámicos/privados: 49152 a 65535

Tenga en cuenta que los puertos UDP pueden recibir más de un mensaje a la vez. En algunos casos, los servicios TCP y UDP pueden utilizar los mismos números de puerto, como 7 (Echo) o 23 (Telnet).

UDP utiliza los siguientes puertos conocidos:

La lista de puertos UDP y TCP la mantiene la IANA (Autoridad de Números Asignados de Internet).

Direcciones IP

Un datagrama IP consta de direcciones IP de origen y destino de 32 bits. La dirección IP de destino especifica el punto final del datagrama UDP y la dirección IP de origen se utiliza para obtener información sobre quién envió el mensaje. En el destino, los paquetes se filtran y aquellos cuyas direcciones de origen no están incluidas en el conjunto válido de direcciones se descartan sin notificar al remitente.

Una dirección IP de unidifusión identifica de forma única un host en una red, mientras que una dirección IP de multidifusión identifica grupo específico direcciones en la red. Todos los hosts reciben y procesan las direcciones IP de transmisión red local o una subred específica.

TTL

El valor de tiempo de vida o TTL (tiempo de vida) le permite establecer un límite superior en la cantidad de enrutadores a través de los cuales puede pasar un datagrama. El valor TTL evita que los paquetes lleguen bucles sin fin. Lo inicializa el remitente y lo disminuye en uno cada enrutador que procesa el datagrama. Cuando el valor TTL llega a cero, el datagrama se descarta.

correo grupal

La multidifusión es un método abierto basado en estándares para distribuir información idéntica a múltiples usuarios simultáneamente. La multidifusión es la característica principal del protocolo UDP; no es posible con el protocolo TCP. La multidifusión permite la interacción de uno a muchos, por ejemplo haciendo posibles usos como el envío de noticias y correo a múltiples destinatarios, radio por Internet o programas de demostración en tiempo real. El envío en grupo no carga la red tanto como transmisión, ya que los datos se envían a varios usuarios a la vez:

Cómo funciona UDP

Cuando una aplicación basada en UDP envía datos a otro host de la red, UDP les agrega un encabezado de ocho bits que contiene los números de puerto de origen y destino, la longitud total de los datos y una suma de verificación. IP agrega su encabezado encima del datagrama UDP, formando un datagrama IP:

La figura anterior indica que la longitud total del encabezado UDP es de ocho bytes. El tamaño máximo teórico de un datagrama IP es 65.535 bytes. Con 20 bytes de encabezado IP y 8 bytes de encabezado UDP, la longitud de los datos del usuario puede ser de hasta 65.507 bytes. Sin embargo, la mayoría de los programas funcionan con datos. tamaño más pequeño. Por lo tanto, para la mayoría de las aplicaciones, la longitud predeterminada es de aproximadamente 8192 bytes, ya que esta es la cantidad de datos que lee y escribe la red. sistema de archivos(NFS). Puede configurar los tamaños de los buffers de entrada y salida.

La suma de comprobación es necesaria para comprobar si los datos se entregaron correctamente a su destino o si estaban dañados. Cubre tanto el encabezado UDP como los datos. Se utiliza un byte de relleno si el número total de octetos del datagrama es impar. Si la suma de verificación recibida es cero, el destinatario registra un error de suma de verificación y descarta el datagrama. Aunque una suma de comprobación es una característica opcional, siempre se recomienda incluirla.

En el siguiente paso, la capa IP agrega 20 bytes de encabezado, que incluye el TTL, las direcciones IP de origen y destino, y otra información. Esta acción se llama encapsulación de IP.

Como se mencionó anteriormente, el tamaño máximo de paquete es 65.507 bytes. Si el paquete es más grande que el predeterminado Tamaño de MTU, luego la capa IP divide el paquete en segmentos. Estos segmentos se denominan fragmentos y el proceso de dividir los datos en segmentos se llama fragmentación. El encabezado IP contiene toda la información del fragmento.

Cuando la aplicación emisora ​​"arroja" un datagrama a la red, se enruta a la dirección IP de destino especificada en el encabezado IP. Al pasar por un enrutador, el valor del tiempo de vida (TTL) en el encabezado IP se reduce en uno.

Cuando un datagrama llega a un destino y puerto determinados, la capa IP verifica su encabezado para ver si el datagrama está fragmentado. Si es así, el datagrama se ensambla de acuerdo con la información del encabezado. Finalmente capa de aplicación recupera los datos filtrados eliminando el encabezado.

Desventajas de UDP

En comparación con TCP, UDP tiene las siguientes desventajas:

Sin señales de reconocimiento. Antes de enviar un paquete UDP, el lado emisor no intercambia señales de protocolo de enlace con el lado receptor. Por lo tanto, el remitente no tiene forma de saber si el datagrama ha llegado al sistema de destino. Como resultado, UDP no puede garantizar que los datos realmente se entreguen al destino (por ejemplo, si el sistema o la red final no funciona).

Por el contrario, TCP está orientado a la conexión y permite la comunicación entre hosts conectados a la red mediante paquetes. TCP utiliza apretones de manos para verificar que los datos se hayan transportado correctamente.

Usando sesiones. La naturaleza orientada a la conexión de TCP está respaldada por sesiones entre hosts. TCP utiliza un identificador de sesión para realizar un seguimiento de las conexiones entre dos hosts. UDP no admite sesiones debido a su naturaleza sin conexión.

Fiabilidad. UDP no garantiza que solo se entregará una copia de los datos al destinatario. Mandar sistema final gran cantidad de datos, UDP los divide en partes pequeñas. UDP no garantiza que estas piezas se entregarán a su destino en el mismo orden en que fueron creadas en origen. Por el contrario, TCP utiliza números de puerto junto con números seriales y confirmaciones enviadas periódicamente para garantizar la entrega ordenada de los datos.

Seguridad. TCP es más seguro que UDP. En muchas organizaciones, los firewalls y enrutadores no permiten el paso de paquetes UDP. Esto se debe a que los piratas informáticos pueden aprovechar los puertos UDP sin realizar conexiones explícitas.

Control de flujo. EN control UDP no hay flujo y, como resultado, una aplicación UDP mal diseñada puede capturar una porción significativa de banda ancha redes.

Beneficios de la UDP

Comparado con TCP, UDP tiene las siguientes ventajas:

No se ha establecido ninguna conexión. UDP es un protocolo sin conexión, por lo que elimina la sobrecarga asociada al establecimiento de conexiones. Dado que UDP no utiliza apretones de manos, también se evitan retrasos en la conexión. Esta es la razón por la que DNS favorece UDP sobre TCP: DNS sería mucho más lento si se ejecutara sobre TCP.

Velocidad. UDP es más rápido que TCP. Por este motivo, muchas aplicaciones prefieren UDP a TCP. Las mismas características que hacen que TCP sea más robusto (como las señales de protocolo de enlace) también lo ralentizan.

Diversidad topológica. UDP admite comunicaciones uno a uno y uno a muchos, mientras que TCP solo admite comunicaciones uno a uno.

Gastos generales. Trabajar con TCP significa una mayor sobrecarga; la sobrecarga impuesta por UDP es significativamente menor. TCP utiliza muchos más recursos en comparación con UDP Sistema operativo, y como consecuencia, en entornos donde los servidores atienden a muchos clientes simultáneamente, UDP se usa ampliamente.

Tamaño del encabezado. Para cada paquete, el encabezado UDP tiene solo ocho bytes de largo, mientras que TCP tiene encabezados de 20 bytes y, por lo tanto, UDP consume menos ancho de banda de la red.

Protocolo de datagramas de usuario - UDP

protocolo UDP es uno de los dos protocolos de capa de transporte utilizados en la pila de protocolos TCP/IP. UDP permite que un programa de aplicación transmita sus mensajes a través de una red con una sobrecarga mínima asociada con la conversión de protocolos de capa de aplicación a IP. Sin embargo, al mismo tiempo, programa de aplicación El mismo debe encargarse de confirmar que el mensaje fue entregado a su destino. El encabezado del datagrama (mensaje) UDP se parece al que se muestra en la Figura 2.10.

Arroz. 2.10. Estructura del encabezado del mensaje UDP

La unidad de datos del protocolo UDP se denomina paquete UDP o datagrama de usuario. Un paquete UDP consta de un encabezado y un campo de datos que contiene el paquete de la capa de aplicación. El encabezado tiene un formato simple y consta de cuatro campos de dos bytes:

Puerto de origen UDP: número de puerto del proceso de envío,

Puerto de destino UDP: número de puerto del proceso del destinatario,

Longitud del mensaje UDP: longitud del paquete UDP en bytes,

Suma de comprobación UDP: suma de comprobación del paquete UDP

No se deben completar todos los campos de un paquete UDP. Si el datagrama enviado no espera una respuesta, entonces se pueden colocar ceros en lugar de la dirección del remitente. También puede negarse a calcular la suma de verificación, pero tenga en cuenta que el protocolo IP calcula la suma de verificación solo para el encabezado del paquete IP, ignorando el campo de datos.

Los puertos en el encabezado definen el protocolo UDP como un multiplexor que permite recopilar y enviar mensajes de aplicaciones a la capa de protocolo. En este caso, la aplicación utiliza puerto específico. Las aplicaciones que se comunican a través de la red pueden utilizar diferentes puertos, lo que se refleja en el encabezado del paquete. En total se pueden definir 216 puertos diferentes. Los primeros 256 puertos están asignados a los llamados "servicios conocidos", entre los que se incluye, por ejemplo, el puerto UDP 53, que está asignado al servicio DNS.

Campo Longitud Determina la longitud total del mensaje. Campo Suma de comprobación Sirve para controlar la integridad de los datos. Aplicación que utiliza protocolo UDP debe cuidar la integridad de los datos analizando los campos Suma de comprobación y Longitud. Además, al intercambiar datos a través de UDP, el propio programa de aplicación debe encargarse de controlar la entrega de datos al destinatario. Normalmente, esto se logra intercambiando confirmaciones de entrega entre programas de aplicación.

Mayoría servicios conocidos Los basados ​​en UDP son el servicio de nombres de dominio BIND y el sistema de archivos distribuido NFS. Volviendo al ejemplo de traceroute, este programa también utiliza transporte UDP. En realidad es el mensaje UDP el que se envía a la red, pero utiliza un puerto que no tiene servicio, por lo que se genera un paquete ICMP, que detecta la falta de servicio en la máquina receptora cuando finalmente el paquete llega a la red. máquina de destino.

Protocolo de control de transferencia: TCP

Si para una aplicación es importante controlar la calidad de la transmisión de datos a través de la red, en este caso se utiliza el protocolo TCP. Este protocolo también se denomina protocolo confiable, orientado a la conexión y orientado al flujo. Antes de discutir estas propiedades del protocolo, consideremos el formato del datagrama transmitido a través de la red (Figura 2.11). Según esta estructura, TCP, al igual que UDP, tiene puertos. Los primeros 256 puertos se asignan a WKS, los puertos 256 a 1024 se asignan a servicios Unix y el resto se puede utilizar a su discreción. en el campo Secuencia de números el número de paquete se define en la secuencia de paquetes que constituye el mensaje completo, seguido de un campo de reconocimiento Número de conocimiento y otra información de control.

Arroz. 2.11. Estructura del paquete TCP

El puerto de origen (SOURS PORT) ocupa 2 bytes, identifica el proceso de envío;

El puerto de destino (PUERTO DE DESTINO) ocupa 2 bytes, identifica el proceso destinatario;

El número de secuencia (NÚMERO DE SECUENCIA) ocupa 4 bytes, indica el número de bytes, que determina el desplazamiento del segmento en relación con el flujo de datos enviados;

El número confirmado (NÚMERO DE RECONOCIMIENTO) ocupa 4 bytes, contiene el número máximo de bytes en el segmento recibido, incrementado en uno; es este valor el que se utiliza como recibo;

La longitud del encabezado (HLEN) tiene 4 bits e indica la longitud del encabezado del segmento TCP, medida en palabras de 32 bits. La longitud del encabezado no es fija y puede variar según los valores establecidos en el campo Opciones;

Reserva (RESERVADO) ocupa 6 bits, el campo está reservado para uso posterior;

Los bits de código (CODE BITS) ocupan 6 bits y contienen información de servicio sobre el tipo de un segmento determinado, especificado estableciendo los bits correspondientes de este campo en uno:

URG - mensaje urgente;

ACK: recibo del segmento recibido;

PSH: solicitud para enviar un mensaje sin esperar a que se llene el búfer;

RST: solicitud para restablecer la conexión;

SYN: mensaje utilizado para sincronizar contadores de datos transmitidos al establecer una conexión;

FIN es una señal de que el lado transmisor ha alcanzado el último byte en el flujo de datos transmitido.

Una ventana (VENTANA) ocupa 2 bytes, contiene el valor declarado del tamaño de la ventana en bytes;

La suma de comprobación (CHECKSUM) ocupa 2 bytes y se calcula por segmento;

El puntero urgente (URGENT POINTER) ocupa 2 bytes, se utiliza junto con el bit del código URG, indica el final de los datos que deben recibirse con urgencia, a pesar del desbordamiento del buffer;

OPCIONES: este campo tiene una longitud variable y puede estar ausente por completo, el tamaño máximo de campo es 3 bytes; se utiliza para resolver problemas auxiliares, por ejemplo, al elegir el tamaño máximo de segmento;

PADDING, un relleno de longitud variable, es un campo ficticio que se utiliza para llevar el tamaño del encabezado a un número entero de palabras de 32 bits.

La confiabilidad de TCP radica en el hecho de que la fuente de datos repite el envío a menos que reciba confirmación del destinatario dentro de un cierto período de tiempo de que se recibió con éxito. Este mecanismo se llama Conciencia Positiva con Retransmisión (PAR). Como definimos anteriormente, la unidad de transmisión (paquete de datos, mensaje, etc.) en términos de TCP se llama segmento. Hay un campo de suma de verificación en el encabezado TCP. Si los datos se dañan durante la transmisión, entonces suma de control un módulo que extrae segmentos TCP de paquetes IP puede determinar esto. El paquete dañado se destruye y no se envía nada a la fuente. Si los datos no estaban dañados, pasan a través del ensamblado de mensajes de la aplicación y se envía un acuse de recibo a la fuente.

La orientación de la conexión está determinada por el hecho de que antes de enviar un segmento de datos, los módulos TCP de origen y destino intercambian información de control. Este intercambio se llama apretón de manos(literalmente "apretón de manos"). TCP utiliza un apretón de manos de tres fases:

El origen establece una conexión con el destino enviándole un paquete con el indicador Sincronizar números de secuencia (SYN). El número en la secuencia identifica el número de paquete en el mensaje de aplicación. No tiene que ser 0 o uno. Pero todos los demás números lo utilizarán como base, lo que permitirá recoger los paquetes en en el orden correcto;

El destinatario responde con un número en el campo de acuse de recibo SYN que corresponde a establecido por la fuente número. Además, el campo “número en secuencia” también puede indicar el número solicitado por la fuente;

La fuente confirma que ha aceptado el segmento de destino y envía el primer dato.

Gráficamente este proceso se presenta en la Figura 2.12.

Arroz. 2.12. Establecer una conexión TCP

Una vez establecida la conexión, la fuente envía datos al destinatario y espera su confirmación de que se han recibido, luego envía los datos nuevamente, etc., hasta que finaliza el mensaje. El mensaje finaliza cuando el bit FIN se establece en el campo de banderas, lo que significa "no más datos".

La naturaleza de transmisión del protocolo está determinada por el hecho de que SYN determina el número inicial para contar los bytes transmitidos, no los paquetes. Esto significa que si SYN se configuró en 0 y se transmitieron 200 bytes, entonces el número establecido en el siguiente paquete será 201, no 2.

Está claro que la naturaleza del streaming del protocolo y la exigencia de confirmar la recepción de los datos plantean el problema de la velocidad de transferencia de datos. Para solucionar este problema, utilice una “ventana” - un campo - ventana. La idea de utilizar Window es bastante simple: transmitir datos sin esperar la confirmación de su recepción. Esto significa que la fuente transmite una cierta cantidad de datos igual a una ventana sin esperar la confirmación de su recepción, y luego detiene la transmisión y espera la confirmación. Si recibe confirmación solo para una parte de los datos transmitidos, comenzará a transmitir una nueva parte a partir del número siguiente al confirmado. Esto se muestra gráficamente en la Figura 2.13.

Arroz. 2.13. Mecanismo de transmisión de datos TCP

EN en este ejemplo la ventana está configurada en 250 bytes de ancho. Esto significa que el segmento actual es un segmento con un desplazamiento SYN de 250 bytes. Sin embargo, después de transmitir la ventana completa, el módulo TCP de origen recibió un acuse de recibo para recibir solo los primeros 100 bytes. Por tanto, la transferencia comenzará desde 101 bytes y no desde 251.

Así, hemos examinado todas las propiedades básicas del protocolo TCP. Sólo queda nombrar las aplicaciones más famosas que utiliza TCP para el intercambio de datos. Esto es principalmente TELNET y FTP, así como protocolo HTTP cual es el corazon Mundial Web.

Interrumpamos un poco la conversación sobre protocolos y dirijamos nuestra atención a un componente tan importante de todo el sistema TCP/IP como las direcciones IP.

Me gusta mucho toda la serie de artículos y además siempre quise probarme como traductor. Tal vez, desarrolladores experimentados El artículo parecerá demasiado obvio, pero me parece que será útil en cualquier caso.

Hola, mi nombre es Glenn Fiedler y le doy la bienvenida al primer artículo de mi libro en línea, Programación de redes para desarrolladores de juegos.

En este artículo comenzaremos con lo más aspectos basicos programación de red- recibir y transmitir datos a través de la red. Recibir y transmitir datos es la principal y más parte simple de toda la gama de tareas que realizan los programadores de redes, pero a menudo es difícil determinar qué camino es mejor tomar. Presta suficiente atención a esta parte: si tienes un malentendido, ¡puede tener consecuencias nefastas para tu juego multijugador más adelante!

Probablemente ya haya oído algo sobre los sockets y quizás sepa que vienen en dos tipos principales: TCP y UDP. Lo primero que debes decidir al desarrollar un juego multijugador es qué tipo de sockets usar: ¿TCP, UDP o ambos?

La elección del tipo de socket depende completamente del género del juego que estés desarrollando. EN este ciclo artículos, asumiré que estás escribiendo un juego de acción, como Halo, Battlefield 1942, Quake, Unreal, CounterStrike, Team Fortress, etc.

Ahora analizaremos más de cerca las propiedades de cada tipo de enchufe (teniendo en cuenta que estamos desarrollando un juego de estilo acción) y profundizaremos un poco más en los detalles de cómo funciona Internet. Después revisión detallada opción correcta¡será obvio!

TCP significa "protocolo de control de transmisión" e IP significa "protocolo de Internet". Juntos sustentan casi todo lo que usted hace en línea, desde la navegación web hasta IRC y las comunicaciones por correo electrónico, todo funcionando en TCP/IP.

Si alguna vez ha utilizado sockets TCP, debe saber que TCP es un protocolo que utiliza el principio de una conexión confiable. Esto significa que establece una conexión entre dos computadoras y luego envía datos entre ellas, como si estuviera escribiendo información en un archivo en una computadora y leyéndola del mismo archivo en otra.

En este caso, la conexión se considera confiable y consistente, es decir, se garantiza que toda la información que envía llegará al destinatario en el mismo orden en que fue enviada. También conexión TCP puede considerarse un flujo continuo de datos: el propio protocolo se encarga de dividir los datos en paquetes y enviarlos a través de la red.

Una vez más: todo es tan sencillo como escribir o leer un archivo de forma normal. ¡Watson elemental!

Pero esta facilidad de uso es completamente diferente de lo que realmente sucede "bajo el capó", en un nivel inferior: el nivel del protocolo IP.

En este nivel no existe el concepto de conexión; en cambio, paquetes individuales transmitido de una computadora a otra. Puedes pensar en este proceso como pasar una nota de una persona a otra en una habitación llena de gente: al final la nota llega a la persona adecuada, pero al mismo tiempo pasa por muchas manos.

Sin embargo, no hay garantía de que la nota llegue al destinatario. El remitente simplemente envía una nota con la esperanza de que llegue, pero ni siquiera sabe si el mensaje ha llegado o no, hasta que el destinatario decide responder.
Naturalmente, en realidad todo es un poco más complicado, ya que el ordenador emisor no conoce la secuencia exacta de ordenadores de la red a través de los cuales se debe transmitir el paquete para que llegue lo más rápido posible. A veces, IP transmite múltiples copias del mismo paquete, que pueden tomar caminos diferentes para llegar al destino y es probable que lleguen en momentos diferentes.

¿Qué pasa si queremos transferir información entre computadoras no en un estilo de lectura/escritura de archivos, sino enviando y recibiendo paquetes individuales directamente?

Bueno, podemos hacer esto usando UDP. UDP significa "protocolo de datagramas de usuario" y se ejecuta sobre IP (como TCP), pero en lugar de agregar una gran cantidad de funciones, es solo un pequeño complemento a IP.

Usando UDP, podemos enviar un paquete a una dirección IP específica (por ejemplo, 112.140.20.10) y a un puerto (por ejemplo, 52423), y se transmitirá de computadora a computadora hasta que llegue a su destino (o se pierda en el camino). forma).

Al mismo tiempo, en el lado del receptor simplemente nos sentamos y esperamos, escuchando un determinado puerto (52423 en nuestro caso), y cuando llega un paquete de alguien (recuerde que no se utilizan conexiones), recibimos una notificación al respecto con la dirección y el puerto de la computadora emisora, el tamaño del paquete y luego podemos leer los datos de este paquete.

El protocolo UDP no garantiza la entrega de datos. En la práctica, la mayoría de los paquetes, por supuesto, llegan, pero siempre hay una pérdida de alrededor del 1-5% y, a veces, hay períodos de tiempo en los que los paquetes no llegan (recuerde que entre el remitente y el destinatario puede haber haber miles de computadoras, en cualquiera de las cuales puede fallar o averiarse).

Además, UDP no garantiza el orden en que se entregan los paquetes. Puede enviar cinco paquetes en orden (1, 2, 3, 4, 5), pero es posible que lleguen en un orden completamente diferente (por ejemplo, 3, 1, 2, 5, 4). Nuevamente, en la práctica, lo más probable es que lleguen Llega en el orden correcto la mayor parte del tiempo, ¡pero no puedes confiar en eso!

Finalmente, aunque UDP no aporta mucho a IP, sí garantiza una cosa. Si reenvía un paquete, llegará completo o no llegará en absoluto. Entonces, si envía un paquete de 256 bytes a otra computadora, entonces no puede recibir solo los primeros 100 bytes del paquete; debe recibir los 256 bytes. Esto es realmente lo único que garantiza el protocolo UDP: todo lo demás recae sobre sus hombros.

Entonces necesitamos decidir si usar TCP o Conectores UDP? Echemos un vistazo a sus propiedades:

• Utiliza el principio de conexión.
• Garantiza la entrega y el tiempo de entrega.
• Divide automáticamente la información en paquetes.
• Garantiza que los datos no se envíen con demasiada intensidad (control del flujo de datos)
• Fácil de usar, como escribir/leer desde un archivo

UDP:

• No utiliza el principio de conexión; deberá implementarlo manualmente
• No garantiza la entrega y el orden de entrega de los paquetes: ¡pueden llegar en el orden incorrecto, con duplicados o no llegar en absoluto!
• Debe dividir manualmente los datos en paquetes y enviarlos.
• Debe tener cuidado de no enviar datos con demasiada intensidad.
• Si se pierde un paquete, debe rastrearlo de alguna manera y, si es necesario, reenviarlo

Con tal lista, la solución parece obvia: TCP implementa todas las funciones que necesitamos y es más fácil de usar, mientras que usar UDP promete hemorroides al escribir todo manualmente, desde cero. Entonces usamos TCP, ¿verdad?

Pero no.

Usar TCP es probablemente el peor error que puedes cometer al desarrollar un juego multijugador. Para entender por qué, veamos qué hace que TCP sea tan fácil de usar.

Cómo funciona TCP

Tanto TCP como UDP funcionan sobre IP, pero en realidad son completamente diferentes. UDP se comporta de manera muy similar a IP, mientras que TCP abstrae al usuario de todos los problemas de paquetes, haciendo que la interacción sea similar a leer/escribir en un archivo.

Entonces ¿Cómo lo hace él?

En primer lugar, TCP utiliza una abstracción de flujo de datos: simplemente puede escribir bytes de datos en ese flujo y TCP se asegurará de que llegue a su destino. Debido a que IP transmite datos en paquetes y TCP se ejecuta sobre IP, TCP debe dividir el flujo de entrada del usuario en paquetes individuales. Entonces, dentro de TCP, cierta lógica recopila datos en una cola y, cuando hay suficientes, forma un paquete y lo envía al destino.

Este comportamiento podría suponer un problema para nuestro juego multijugador si necesitamos transferir paquetes muy pequeños. Puede suceder que TCP decida no transmitir nuestros datos hasta que haya suficientes para formar un paquete. cierto tamaño(digamos más de cien bytes). Y esto - Un gran problema, porque es necesario transferir datos del cliente (pulsaciones de teclas del jugador) al servidor lo más rápido posible, y si hay retrasos debido al almacenamiento en búfer de datos por parte del protocolo, entonces el juego no será el más agradable para el jugador en el lado del cliente. En este caso, la actualización de los objetos del juego se producirá con retraso y en raras ocasiones, mientras que necesitamos actualizar los objetos a tiempo y con frecuencia.

TCP tiene una opción para solucionar este problema: "TCP_NODELAY". Le dice al protocolo que no espere a que los datos se acumulen en la cola de envío, sino que los envíe inmediatamente.

Desafortunadamente, incluso con esta opción instalada, TCP tiene muchos problemas cuando se usa en juegos en línea.

La raíz de todos los problemas radica en la forma en que TCP maneja los paquetes perdidos o desordenados, creando la ilusión de una conexión confiable y consistente.

Cómo TCP garantiza la confiabilidad de la conexión

Durante la transmisión, TCP divide el flujo de datos en paquetes individuales, los envía a través de la red utilizando el protocolo IP poco confiable y luego los reconstruye desde la computadora receptora. Paquetes recibidos flujo original.

¿Pero qué pasa si uno de los paquetes no llega? ¿O si los paquetes llegan desordenados o duplicados?

Sin profundizar demasiado en los detalles de cómo funciona TCP (y este es un tema realmente muy complejo; puede leerlo en TCP/IP ilustrado), el proceso se ve así: TCP envía un paquete, determina que el paquete no llegó y reenvía el mismo paquete al destinatario. Los paquetes duplicados se eliminan por parte del destinatario y los paquetes que llegan desordenados se reordenan para que todo esté como debe ser: de manera confiable y en orden.

El problema es que cuando TCP “sincroniza” el flujo de datos de esta manera, si se pierde un paquete, la transmisión se detiene hasta que el paquete perdido se reenvía (y el destino lo recibe). Si llegan nuevos datos mientras espera, se pondrán en cola y no podrá leerlos hasta que llegue el paquete perdido. ¿Cuánto tiempo se tarda en reenviar un paquete? Se necesita al menos el tiempo de ida y vuelta del paquete (cuando TCP determina qué paquete reenviar), más el tiempo para volver a entregar el paquete perdido. Entonces, si el ping entre computadoras es de 125 ms, retransmisión El paquete tardará aproximadamente un quinto de segundo y, en el peor de los casos, hasta medio segundo (imagínese si de repente también se pierde el paquete recién enviado). ¡Veselukha!

Por qué nunca deberías usar TCP para juegos multijugador

El problema con el uso de TCP en juegos en línea es que, a diferencia de los navegadores, Correo electrónico y otras aplicaciones, los juegos dependen de la interacción en tiempo real. Para muchos aspectos del juego, como las teclas presionadas por el usuario y la posición de los jugadores en el juego, no importa lo que sucedió hace un segundo, sino solo el estado más actual. mundo de juegos.

Veamos un ejemplo sencillo de un juego multijugador, como un juego de disparos en 3D. parte de la red El juego está estructurado de manera muy simple: en cada iteración del ciclo del juego, el cliente envía al servidor una descripción de todas las acciones del jugador (teclas presionadas, posición del mouse, etc.), y en cada iteración el servidor procesa estos datos, actualiza el modelo. del mundo del juego y envía las posiciones actuales de los objetos al mundo del cliente para que dibuje un nuevo marco para el jugador.

Entonces, en nuestro juego, si un paquete se pierde mientras se transmite a través de la red, el juego se detiene y espera hasta que el paquete se vuelva a entregar. En el lado del cliente, los objetos del juego se congelan y en el servidor, los jugadores tampoco pueden moverse ni disparar porque el servidor no puede aceptar nuevos paquetes. Cuando finalmente llega el paquete perdido, contiene información obsoleta que ya no es relevante. Además, después de esto, también llegan todos aquellos paquetes que se han acumulado en la cola durante el tiempo de espera, y todos deben procesarse en una iteración del bucle. ¡Completa confusión!

Desafortunadamente, no hay manera de cambiar este comportamiento de TCP, y no es necesario hacerlo, ya que ese es el significado de TCP. Esta es una necesidad para que la transmisión de datos a través de Internet sea un flujo de datos confiable y consistente.
Pero no necesitamos un flujo de datos confiable y consistente.

Necesitamos que los datos lleguen del cliente al servidor lo más rápido posible y no queremos esperar a que se reenvíen.
Es por eso que nunca debes usar TCP para juegos multijugador.

¡Pero espera! ¿Por qué no puedo utilizar UDP y TCP juntos?

Para los datos del juego en tiempo real, como los clics de los usuarios y el estado del mundo del juego, solo son importantes los datos más actuales, pero para otros tipos de datos, como los conjuntos de comandos enviados de una computadora a otra, la confiabilidad y coherencia del canal. puede ser muy importante.

Por supuesto, es tentador utilizar UDP para la entrada del usuario y datos del estado mundial, y TCP para datos cuya entrega se debe garantizar. Quizás incluso estés pensando que podrías crear múltiples “hilos” de comandos, por ejemplo, uno para cargar niveles y otro para comandos de IA. Estás pensando: "No necesito equipos de IA esperando en fila si se pierde el paquete de datos para cargar un nivel, ¡porque no tienen ninguna relación!". EN en este caso tienes razón y puedes decidir crear por Conector TCP para cada flujo de comando.

A primera vista, esto gran idea. Pero el problema es que, dado que TCP y UDP se ejecutan sobre IP, los paquetes de ambos protocolos se afectarán entre sí, ya en el nivel de IP. Cómo se manifestará exactamente este efecto es una cuestión muy compleja y está relacionada con los mecanismos de confiabilidad en TCP. Pero, en cualquier caso, tenga en cuenta que el uso de TCP suele provocar una mayor pérdida de paquetes UDP. Si quieres saber más sobre esto, puedes leer