Diferencias entre TCP y UDP

La forma mas rápida de diferenciar entre estos tipos de Protocolos, es indicar que UDP no posee control de sesión, o lo que es lo mismo, que este protocolo es inseguro y se utiliza solo para los casos en cuales no nos importa si el paquete llega o se pierde por el camino.

Detalle pedido prestado desde WIKIPEDIA

  • UDP: proporciona un nivel de transporte no fiable de datagramas, ya que apenas añade la información necesaria para la comunicación extremo a extremo al paquete que envía al nivel inferior. Lo utilizan aplicaciones como NFS (Network File System) y RCP (comando para copiar ficheros entre ordenadores remotos), pero sobre todo se emplea en tareas de control y en la transmisión de audio y vídeo a través de una red. No introduce retardos para establecer una conexión, no mantiene estado de conexión alguno y no realiza seguimiento de estos parámetros. Así, un servidor dedicado a una aplicación particular puede soportar más clientes activos cuando la aplicación corre sobre UDP en lugar de sobre TCP.
  • TCP: es el protocolo que proporciona un transporte fiable de flujo de bits entre aplicaciones. Está pensado para poder enviar grandes cantidades de información de forma fiable, liberando al programador de la dificultad de gestionar la fiabilidad de la conexión (retransmisiones, pérdida de paquetes, orden en el que llegan los paquetes, duplicados de paquetes…) que gestiona el propio protocolo. Pero la complejidad de la gestión de la fiabilidad tiene un coste en eficiencia, ya que para llevar a cabo las gestiones anteriores se tiene que añadir bastante información a los paquetes que enviar. Debido a que los paquetes para enviar tienen un tamaño máximo, cuanta más información añada el protocolo para su gestión, menos información que proviene de la aplicación podrá contener ese paquete (el segmento TCP tiene una sobrecarga de 20 bytes en cada segmento, mientras que UDP solo añade 8 bytes). Por eso, cuando es más importante la velocidad que la fiabilidad, se utiliza UDP. En cambio, TCP asegura la recepción en destino de la información para transmitir.

En la comunicación TCP se ven involucrados varios flujos de datos.

EVENT DIAGRAM

Host A envía un paquete TCP SYNchronize al Host B

Host B recibe el SYN

Host B envia un SYNchronize-ACKnowledgement

Host A recibe el SYN-ACK

Host A envía un ACKnowledge

Host B recibe el ACK
La conexión TCP se ha establecido (TCP ESTABLISHED).

tcp three-way handshake,syn,syn-ack,ack

Cuando cerremos una sesión el flujo es diferente.

300px-Fin_de_conexión_TCP.svg

Campos de la cabecera TCP

Screen Shot 2014-01-23 at 1.00.07 PM

  • Puerto origen (16 bits): Identifica el puerto emisor.
  • Puerto destino (16 bits): Identifica el puerto receptor.

Estos dos valores identifican la aplicación receptora y la emisora, junto con las direcciones IP del emisor y receptor identifican de forma unívoca cada conexión. La combinación de una dirección IP y un puerto es llamado socket. Es el par de sockets (dirección IP + puerto del emisor y dirección IP+ puerto del receptor) emisor y receptor el que especifica los dos puntos finales que unívocamente se corresponden con cada conexión TCP en internet.

  • Número de secuencia (32 bits): Identifica el byte del flujo de datos enviado por el emisor TCP al receptor TCP que representa el primer byte de datos del segmento.

Si consideramos un flujo de bytes unidireccional entre las dos aplicaciones, TCP numera cada byte con un número de secuencia. Este número de secuencia es de 32 bits sin signo que retorna a 0 al llegar a 232 -1.

Cuando una conexión está siendo establecida el flag SYN se activa y el campo del número de secuencia contiene el ISN (initial sequence number) elegido por el host para esa conexión. El número de secuencia del primer byte de datos será el ISN+1 ya que el flag SYN consume un número de secuencia.

  • Número de acuse de recibo (32 bits): Contiene el valor del siguiente número de secuencia que el emisor del segmento espera recibir.

Una vez que la conexión ha sido establecida, este número se envía siempre y se valida con el flag ACK activado. Enviar ACKs no cuesta nada ya que el campo de acuse de recibo siempre forma parte de la cabecera, al igual que el flag ACK. TCP se puede describir como un protocolo sin asentimientos selectivos o negativos ya que el número de asentimiento en la cabecera TCP significa que se han recibido correctamente los bytes anteriores pero no se incluye ese byte.

No se pueden asentir partes selectivas del flujo de datos (suponiendo que no estamos usando la opción SACK de asentimientos selectivos). Por ejemplo si se reciben correctamente los bytes 1-1024 y el siguiente segmento contiene los bytes 2049-3072, el receptor no puede asentir este último segmento. Todo lo que puede enviar es un ACK con 1025 como número de asentimiento, al igual que si llega el segmento 1025-2048 pero con un error de cheksum.

  • Longitud de cabecera (4 bits): especifica el tamaño de la cabecera en palabras de 32 bits.

Es requerido porque la longitud del campo “opciones” es variable. Por lo tanto el tamaño máximo de la cabecera está limitado a 60 bytes, mientras que sin “opciones” el tamaño normal será de 20 bytes. A este campo también se le suele llamar “data offset” por el hecho de que es la diferencia en bytes desde el principio del segmento hasta el comienzo de los datos.

  • Reservado (3 bits): para uso futuro. Debe estar a 0.
  • Flags (9 bits):
  • NS (1 bit): ECN-nonce concealment protection. Para proteger frente a paquetes accidentales o maliciosos que se aprovechan del control de congestión para ganar ancho de banda de la red.
  • CWR (1bit): Congestion Window Reduced. El flag se activa por el host emisor para indicar que ha recibido un segmento TCP con el flag ECE activado y ha respondido con el mecanismo de control de congestión.
  • ECE (1 bit): Para dar indicaciones sobre congestión.
  • URG (1 bit): Indica que el campo del puntero urgente es válido.
  • ACK (1 bit): Indica que el campo de asentimiento es válido. Todos lo paquetes enviados después del paquete SYN inicial deben tener activo este flag.
  • PSH (1 bit): Push. El receptor debe pasar los datos a la aplicación tan pronto como sea posible.
  • RST (1 bit): Reset. Reinicia la conexión.
  • SYN (1 bit): Synchronice. Sincroniza los números de secuencia para iniciar la conexión.
  • FIN (1 bit): El emisor finaliza el envío de datos.
  • Tamaño de ventana (16 bits): Tamaño de la ventana de recepción que especifica el número máximo de bytes que pueden ser metidos en el buffer de recepción o dicho de otro modo, el número máximo de bytes pendientes de asentimiento.
  • Suma de verificación (16 bits): Checksum utilizado para la comprobación de errores tanto en la cabecera como en los datos.
  • Puntero urgente (16 bits): Cantidad de bytes desde el número de secuencia que indica el lugar donde acaban los datos urgentes.
  • Opciones: Para poder añadir características no cubiertas por la cabecera fija.
  • Relleno: Se utiliza para asegurarse que la cabecera acaba con un tamaño múltiplo de 32 bits.

Hablando de TCP podríamos poner un ejemplo de interlocución como es el caso de DHCP

220px-DHCP_session_en.svg

Por ejemplo es útil tener en cuenta como se compone un paquete IP (En muchas entrevistas de trabajo pueden preguntarlo, y siempre es bueno tener un mapa a mano)

imag2

Image2755

Y también es útil tener un listado de los diferentes estados de TCP

imag32

Leave a Reply

Your email address will not be published. Required fields are marked *