upt

 Análisis comparativo: TCP - UDP

Los dos protocolos más comunes de la capa de Transporte del conjunto de protocolos TCP/IP son el Protocolo de control de transmisión (TCP) y el Protocolo de datagramas de usuario (UDP). Ambos protocolos gestionan la comunicación de múltiples aplicaciones. Las diferencias entre ellos son las funciones específicas que cada uno implementa.
TCP vs UDP

TCP	UDP
Orientado a la conexión Confiabilidad en la entrega de mensajes Divide los mensajes en datagramas Hace seguimiento del orden (o secuencia) Usa checksums para la detección de errores Los procedimientos remotos no son idempotentes La confiabilidad es prioridad Los mensajes exceden el tamaño de un paquete UDP	Sin conexión No se fragmentan los mensajes No hay reensamblaje ni sincronización En caso de error, el mensaje se retransmite Sin acuse de envío Los procedimientos remotos son idempotentes Los mensajes del servidor y el cliente entran completamente dentro de un paquete El servidor maneja multiples clientes (UDP no tiene estados)

TCP y UDP utilizan el mismo esquema de direccionamiento. Una dirección IP y un número de puerto.

Ventajas de UDP No te restringe a un modelo de comunicación basado en la conexión, la latencia para el inicio en aplicaciones distribuidas es mucho menor, al igual que la sobrecarga del sistema operativo. Todo el control de flujo, los acuses de recibo, el registro de transacciones, etc. depende de los programas de usuario. Además, sólo es necesario implementar y utilizar las funciones que necesita. El receptor de los paquetes UDP los recibe sin fragmentar, incluyendo los límites de los bloques. Broadcast y transmisión multicast están disponibles con UDP.	Ventajas de TCP El sistema operativo hace todo el trabajo, el manejo de paquetes de entrada tiene menos cambios de contexto del kernel al espacio de usuario y de vuelta, todo el reensamblaje, acuse de recibo, control de flujo, etc se lleva a cabo por el kernel. TCP garantiza tres cosas: que sus datos lleguen, que lleguen en orden, y que lleguen sin duplicaciones. Los routers pueden notar los paquetes TCP y los tratan de forma especial. los pueden almacenar en búfer y los retransmiten. TCP tiene un buen rendimiento relativo a través de un módem o una LAN.
Desventajas de UDP No hay garantías con UDP. un paquete puede no ser entregado, o entregado dos veces o entregado fuera de orden, no se obtiene ningún indicio de esto a menos que el programa de escucha en el otro extremo decide decir algo. UDP no tiene control de flujo. la implementación es el deber de los programas de usuario. Los routers son muy descuidados con UDP. nunca se retransmiten si colisionan, y parecen ser la primera cosa descartada cuando un router está corto de memoria. UDP sufre más pérdida de paquetes que TCP.	Desventajas de TCP El sistema operativo puede ser defectuoso.Puede ser ineficaz, y puede que no se pueda afinar. TCP es díficil de expandir,se puede establecer una pocas opciones de socket,pero tiene que tolerar el control de flujo incorporado. TCP puede tener un montón de característicasque no son necesarias, puede desperdiciar ancho de banda, tiempo oesfuerzo en asegurar cosas que son irrelevantes para la tarea en cuestión. TCP no tiene límites de bloques, debe crear el suyo. Los routers de la Internet de hoy en día están agotando su memoria, no pueden prestar mucha atención a tcp, las asumpsiones de diseño de TCP se descomponen en este entorno. TCP tiene rendimiento relativamente pobre en conexiones de alta latencia, gran ancho de banda como una conexión por satélite o con sobrecarga. TCP no puede ser utilizado para broadcast o transmisión multicast. TCP no puede concluir una transmisión sin todos los datos en movimiento explícitamente confirmados.
Ventajas de la UDP para la transferencia de archivos El control de flujo depende del espacio de usuario; las ventanas pueden ser infinitas, no existen interrupciones artificiales, la latencia es bien tolerada, y las velocidades máximas solo se pueden forzar por ancho de banda real, a pesar de que las velocidades reales son elegidas por acuerdo entre el emisor y el receptor. Si recibe una imagen de forma simultánea desde varios hosts es mucho más fácil con UDP, como lo es el envío a varios hosts, especialmente si llegan a ser parte del mismo grupo broadcast o multicast.	Desventajas de TCP para la transferencia de archivos TCP permite una ventana de un máximo de 64k, y el mecanismo de ACKING significa que la pérdida de paquetes no se ha detectado. Los servidores de transferencia TCP han de mantener un socket separado (y a menudo un hilo separado) para cada cliente. El balanceo de carga es crudo y aproximado. Especialmente en las redes locales que permiten colisiones, dos transferencias simultáneas de TCP tienen una tendencia a pelear unas con otras, incluso si el remitente es el mismo.

Diferencias entre protocolos de transporte TCP y UDP

Dentro del Modelo OSI, la capa de transporte (capa 4) tiene como función principal aceptar los datos enviados por las capas superiores, dividirlos en pequeñas partes si es necesario, y pasarlos a la capa de red, también se asegura que lleguen correctamente al otro lado de la comunicación.

Existen dos mecanismos o protocolos dentro de esta capa de transporte, el protocolo TCP (Transfer Control Protocol) y UDP (User Datagram Protocol).

TCP es un protocolo de transporte orientado a conexión, por ejemplo servicios como Telnet, FTP y SSH utilizan el protocolo TCP, ya que están orientados a conexión, la estación de trabajo A y la estación de trabajo B establecen comunicación/conexión. Al establecerse la comunicación entre las dos estaciones de trabajo, se asegura que el flujo de datos entre ellas sea fiable, asegurandose de que los datos llegan correctamente del emisor al destinatario, en el orden estipulado y completos.

Un ejemplo adapatado a la vida real y de forma muy básica de conexión TCP, podría ser la de una llamada telefónica, el sujeto A llama al sujeto B, hasta que B no coge el teléfono, la conexión no es aceptada, y cuando uno de los dos sujetos dice adiós, la conexión se da por finalizada.

UDP por el contrario es un protocolo en el que no hay conexión. Una estación de trabajo A envía datos a la estación de trabajo B de forma unidireccional, no establece previa conexión con ella, por lo que los datos son enviados sin saber si van a ser recibidos correctamente, en orden, completos, etc.

Como podréis imaginar, este protocolo de transporte es muchísimo menos fiable que TCP, suele ser utilizado para aplicaciones de streaming (video o audio) ya que en estas es más importante la recepción rápida de los datos que la verificación de los mismos, lo mismo sucede con los servicios DNS, aplicacion simple de tipo petición/respuesta.

Estas son las diferencias a un nivel muy básico de TCP y UDP, os recomiendo revisar este manual de administración de redes o la familia de protocolos de Internet si queréis profundizar en el tema.

Escalado de ventana

Como el campo de ventana no puede expandirse se usa un factor de escalado. La escala de ventana TCP (TCP window scale) es una opción usada para incrementar el máximo tamaño de ventana desde 65.535 bytes, a 1 Gigabyte.

La opción de escala de ventana TCP es usada solo durante la negociación en tres pasos que constituye el comienzo de la conexión. El valor de la escala representa el número de bits desplazados a la izquierda de los 16 bits que forman el campo del tamaño de ventana. El valor de la escala puede ir desde 0 (sin desplazamiento) hasta 14. Hay que recordar que un número binario desplazado un bit a la izquierda es como multiplicarlo en base decimal por 2.

Fin de la conexión

La fase de finalización de la conexión usa una negociación en cuatro pasos (four-way handshake), terminando la conexión desde cada lado independientemente. Cuando uno de los dos extremos de la conexión desea parar su "mitad" de conexión transmite un paquete FIN, que el otro interlocutor asentirá con un ACK. Por tanto, una desconexión típica requiere un par de segmentos FIN y ACK desde cada lado de la conexión.

Una conexión puede estar "medio abierta" en el caso de que uno de los lados la finalice pero el otro no. El lado que ha dado por finalizada la conexión no puede enviar más datos pero la otra parte si podrá.

Puertos TCP

TCP usa el concepto de número de puerto para identificar a las aplicaciones emisoras y receptoras. Cada lado de la conexión TCP tiene asociado un número de puerto (de 16 bits sin signo, con lo que existen 65536 puertos posibles) asignado por la aplicación emisora o receptora. Los puertos son clasificados en tres categorías: bien conocidos, registrados y dinámicos/privados. Los puertos bien conocidos son asignados por la Internet Assigned Numbers Authority (IANA), van del 0 al 1023 y son usados normalmente por el sistema o por procesos con privilegios. Las aplicaciones que usan este tipo de puertos son ejecutadas como servidores y se quedan a la escucha de conexiones. Algunos ejemplos son: FTP (21), SSH (22), Telnet (23), SMTP (25) y HTTP (80). Los puertos registrados son normalmente empleados por las aplicaciones de usuario de forma temporal cuando conectan con los servidores, pero también pueden representar servicios que hayan sido registrados por un tercero (rango de puertos registrados: 1024 al 49151). Los puertos dinámicos/privados también pueden ser usados por las aplicaciones de usuario, pero este caso es menos común. Los puertos dinámicos/privados no tienen significado fuera de la conexión TCP en la que fueron usados (rango de puertos dinámicos/privados: 49152 al 65535, recordemos que el rango total de 2 elevado a la potencia 16, cubre 65536 números, del 0 al 65535).

Desarrollo de TCP

TCP es un protocolo muy desarrollado y complejo. Sin embargo, mientras mejoras significativas han sido propuestas y llevadas a cabo a lo largo de los años, ha conservado las operaciones más básicas sin cambios desde el publicado en 1981. El documento (Host Requirements for Internet Hosts), especifica el número de requisitos de una implementación del protocolo TCP. El  (Control de Congestión TCP) es uno de los más importantes documentos relativos a TCP de los últimos años, describe nuevos algoritmos para evitar la congestión excesiva. En 2001, el  fue escrito para describir la Notificación de Congestión Explícita (ECN), una forma de eludir la congestión con mecanismos de señalización. En los comienzos del siglo XXI, TCP es usado en el 95% de todos los paquetes que circulan por Internet. Entre las aplicaciones más comunes que usan TCP están HTTP/HTTPS (World Wide Web), SMTP/POP3/IMAP (correo electrónico) y FTP (transferencia de ficheros). Su amplia extensión ha sido la prueba para los desarrolladores originales de que su creación estaba excepcionalmente bien hecha.

Recientemente, un nuevo algoritmo de control de congestión fue desarrollado y nombrado como FAST TCP (Fast Active queue management Scalable Transmission Control Protocol) por los científicos de Caltech (California Institute of Technology). Es similar a TCP Vegas en cuanto a que ambos detectan la congestión a partir de los retrasos en las colas que sufren los paquetes al ser enviados a su destino. Todavía hay un debate abierto sobre si éste es un síntoma apropiado para el control de la congestión.

Protocolo UDP

La descripción completa del protocolo UDP se encuentra en el documento o su 

User Datagram Protocol (UDP) es un protocolo del nivel de transporte basado en el intercambio de datagramas. Permite el envío de datagramas a través de la red sin que se haya establecido previamente una conexión, ya que el propio datagrama incorpora suficiente información de direccionamiento en su cabecera. Tampoco tiene confirmación ni control de flujo, por lo que los paquetes pueden adelantarse unos a otros; y tampoco se sabe si ha llegado correctamente, ya que no hay confirmación de entrega o recepción. Su uso principal es para protocolos como DHCP, BOOTP, DNS y demás protocolos en los que el intercambio de paquetes de la conexión/desconexión son mayores, o no son rentables con respecto a la información transmitida, así como para la transmisión de audio y vídeo en tiempo real, donde no es posible realizar retransmisiones por los estrictos requisitos de retardo que se tiene en estos casos.

Descripción

User Datagram Protocol (UDP) es un protocolo mínimo de nivel de transporte orientado a mensajes documentado en el RFC 768 de la IETF.

En la familia de protocolos de Internet UDP proporciona una sencilla interfaz entre la capa de red y la capa de aplicación. UDP no otorga garantías para la entrega de sus mensajes y el origen UDP no retiene estados de los mensajes UDP que han sido enviados a la red. UDP sólo añade multiplexado de aplicación y suma de verificación de la cabecera y la carga útil. Cualquier tipo de garantías para la transmisión de la información deben ser implementadas en capas superiores.

La cabecera UDP consta de 4 campos de los cuales 2 son opcionales (con fondo rojo en la tabla). Los campos de los puertos fuente y destino son campos de 16 bits que identifican el proceso de origen y recepción. Ya que UDP carece de un servidor de estado y el origen UDP no solicita respuestas, el puerto origen es opcional. En caso de no ser utilizado, el puerto origen debe ser puesto a cero. A los campos del puerto destino le sigue un campo obligatorio que indica el tamaño en bytes del datagrama UDP incluidos los datos. El valor mínimo es de 8 bytes. El campo de la cabecera restante es una suma de comprobación de 16 bits que abarca la cabecera, los datos y una pseudo-cabecera con las IP origen y destino, el protocolo, la longitud del datagrama y 0's hasta completar un múltiplo de 16. pero no los datos. El checksum también es opcional, aunque generalmente se utiliza en la práctica.

El protocolo UDP se utiliza por ejemplo cuando se necesita transmitir voz o vídeo y resulta más importante transmitir con velocidad que garantizar el hecho de que lleguen absolutamente todos los bytes.

Puertos

UDP utiliza puertos para permitir la comunicación entre aplicaciones. El campo de puerto tiene una longitud de 16 bits, por lo que el rango de valores válidos va de 0 a 65.535. El puerto 0 está reservado, pero es un valor permitido como puerto origen si el proceso emisor no espera recibir mensajes como respuesta.

Los puertos 1 a 1023 se llaman puertos "bien conocidos" y en sistemas operativos tipo Unix enlazar con uno de estos puertos requiere acceso como superusuario.

Los puertos 1024 a 49.151 son puertos registrados.

Los puertos 49.152 a 65.535 son puertos efímeros y son utilizados como puertos temporales, sobre todo por los clientes al comunicarse con los servidores.

udp

Datos

Las aplicaciones envían flujos de bytes a la capa TCP para ser enviados a la red. TCP divide el flujo de bytes llegado de la aplicación en segmentos de tamaño apropiado (normalmente esta limitación viene impuesta por la unidad máxima de transferencia (MTU) del nivel de enlace de datos de la red a la que la entidad está asociada) y le añade sus cabeceras. Entonces, TCP pasa el segmento resultante a la capa IP, donde a través de la red, llega a la capa TCP de la entidad destino. TCP comprueba que ningún segmento se ha perdido dando a cada uno un número de secuencia, que es también usado para asegurarse de que los paquetes han llegado a la entidad destino en el orden correcto. TCP devuelve un asentimiento por bytes que han sido recibidos correctamente; un temporizador en la entidad origen del envío causará un timeout si el asentimiento no es recibido en un tiempo razonable, y el (presuntamente desaparecido) paquete será entonces retransmitido. TCP revisa que no haya bytes dañados durante el envío usando un checksum; es calculado por el emisor en cada paquete antes de ser enviado, y comprobado por el receptor.

• Puerto de origen (16 bits): Identifica el puerto a través del que se envía.
• Puerto destino (16 bits): Identifica el puerto del receptor.
• Número de secuencia (32 bits): Sirve para comprobar que ningún segmento se ha perdido, y que llegan en el orden correcto. Su significado varía dependiendo del valor de SYN:
• Si el flag SYN está activo (1), entonces este campo indica el número inicial de secuencia (con lo cual el número de secuencia del primer byte de datos será este número de secuencia más uno).
• Si el flag SYN no está activo (0), entonces este campo indica el número de secuencia del primer byte de datos.
• Número de acuse de recibo (ACK) (32 bits): Si el flag ACK está puesto a activo, entonces en este campo contiene el número de secuencia del siguiente paquete que el receptor espera recibir.
• Longitud de la cabecera TCP (4 bits): Especifica el tamaño de la cabecera TCP en palabras de 32-bits. El tamaño mínimo es de 5 palabras, y el máximo es de 15 palabras (lo cual equivale a un tamaño mínimo de 20 bytes y a un máximo de 60 bytes). En inglés el campo se denomina “Data offset”, que literalmente sería algo así como “desplazamiento hasta los datos”, ya que indica cuántos bytes hay entre el inicio del paquete TCP y el inicio de los datos.
• Reservado (4 bits): Bits reservados para uso futuro, deberían ser puestos a cero.
• Bits de control (flags) (8 bits): Son 8 flags o banderas. Cada una indica “activa” con un 1 o “inactiva” con un 0.

• CWR o “Congestion Window Reduced” (1 bit): Este flag se activa (se pone a 1) por parte del emisor para indicar que ha recibido un paquete TCP con el flag ECE activado. El flag ECE es una extensión del protocolo que fue añadida a la cabecera en el RFC 3168. Se utiliza para el control de la congestión en la red.
• ECE o “ECN-Echo” (1 bit): Indica que el receptor puede realizar notificaciones ECN. La activación de este flag se realiza durante la negociación en tres pasos para el establecimiento de la conexión. Este flag también fue añadido a la cabecera en el RFC 3168.
• URG o “urgent” (1 bit, ver URG): Si está activo significa que el campo “Urgente” es significativo, si no, el valor de este campo es ignorado.
• ACK o “acknowledge” (1 bit, ver ACK): Si está activo entonces el campo con el número de acuse de recibo es válido (si no, es ignorado).
• PSH o “push” (1 bit, ver PSH): Activa/desactiva la función que hace que los datos de ese segmento y los datos que hayan sido almacenados anteriormente en el buffer del receptor deben ser transferidos a la aplicación receptora lo antes posible.
• RST o “reset” (1 bit, ver Flag RST): Si llega a 1, termina la conexión sin esperar respuesta.
• SYN o “synchronize” (1 bit, ver SYN): Activa/desactiva la sincronización de los números de secuencia.
• FIN (1 bit, ver FIN): Si se activa es porque no hay más datos a enviar por parte del emisor, esto es, el paquete que lo lleva activo es el último de una conexión.

• Ventana (16 bits): Es el tamaño de la ventana de recepción, que especifica el número de bytes que el receptor está actualmente esperando recibir.
• Suma de verificación (checksum) (16 bits): Es una suma de verificación utilizada para comprobar si hay errores tanto en la cabecera como en los datos.
• Puntero urgente (16 bits): Si el flag URG está activado, entonces este campo indica el desplazamiento respecto al número de secuencia que indica el último byte de datos marcados como “urgentes”.
• Opciones (número de bits variable): La longitud total del campo de opciones ha de ser múltiplo de una palabra de 32 bits (si es menor, se ha de rellenar al múltiplo más cercano), y el campo que indica la longitud de la cabecera ha de estar ajustado de forma adecuada.
• Datos (número de bits variable): No forma parte de la cabecera, es la carga (payload), la parte con los datos del paquete TCP. Pueden ser datos de cualquier protocolo de nivel superior en el nivel de aplicación; los protocolos más comunes para los que se usan los datos de un paquete TCP son HTTP, telnet, SSH, FTP, etcétera.

Detalles del funcionamiento

Las conexiones TCP se componen de tres etapas: establecimiento de conexión, transferencia de datos y fin de la conexión. Para establecer la conexión se usa el procedimiento llamado negociación en tres pasos (3-way handshake). Una negociación en cuatro pasos (4-way handshake) es usada para la desconexión. Durante el establecimiento de la conexión, algunos parámetros como el número de secuencia son configurados para asegurar la entrega ordenada de los datos y la robustez de la comunicación.

Negociación en tres pasos o Three-way handshake

Establecimiento de la negociación

Aunque es posible que un par de entidades finales comiencen una conexión entre ellas simultáneamente, normalmente una de ellas abre un socket en un determinado puerto tcp y se queda a la escucha de nuevas conexiones. Es común referirse a esto como apertura pasiva, y determina el lado servidor de una conexión. El lado cliente de una conexión realiza una apertura activa de un puerto enviando un paquete SYN inicial al servidor como parte de la negociación en tres pasos. En el lado del servidor se comprueba si el puerto está abierto, es decir, si existe algún proceso escuchando en ese puerto. En caso de no estarlo, se envía al cliente un paquete de respuesta con el bit RST activado, lo que significa el rechazo del intento de conexión. En caso de que sí se encuentre abierto el puerto, el lado servidor respondería a la petición SYN válida con un paquete SYN/ACK. Finalmente, el cliente debería responderle al servidor con un ACK, completando así la negociación en tres pasos (SYN, SYN/ACK y ACK) y la fase de establecimiento de conexión.

Transferencia de datos

Durante la etapa de transferencia de datos, una serie de mecanismos claves determinan la fiabilidad y robustez del protocolo. Entre ellos están incluidos el uso del número de secuencia para ordenar los segmentos TCP recibidos y detectar paquetes duplicados, checksums para detectar errores, y asentimientos y temporizadores para detectar pérdidas y retrasos.

Durante el establecimiento de conexión TCP, los números iniciales de secuencia son intercambiados entre las dos entidades TCP. Estos números de secuencia son usados para identificar los datos dentro del flujo de bytes, y poder identificar (y contar) los bytes de los datos de la aplicación. Siempre hay un par de números de secuencia incluidos en todo segmento TCP, referidos al número de secuencia y al número de asentimiento. Un emisor TCP se refiere a su propio número de secuencia cuando habla de número de secuencia, mientras que con el número de asentimiento se refiere al número de secuencia del receptor. Para mantener la fiabilidad, un receptor asiente los segmentos TCP indicando que ha recibido una parte del flujo continuo de bytes. Una mejora de TCP, llamada asentimiento selectivo (SACK, Selective Acknowledgement) permite a un receptor TCP asentir los datos que se han recibido de tal forma que el remitente solo retransmita los segmentos de datos que faltan.

A través del uso de números de secuencia y asentimiento, TCP puede pasar los segmentos recibidos en el orden correcto dentro del flujo de bytes a la aplicación receptora. Los números de secuencia son de 32 bits (sin signo), que vuelve a cero tras el siguiente byte después del 232-1. Una de las claves para mantener la robustez y la seguridad de las conexiones TCP es la selección del número inicial de secuencia (ISN, Initial Sequence Number).

Un checksum de 16 bits, consistente en el complemento a uno de la suma en complemento a uno del contenido de la cabecera y datos del segmento TCP, es calculado por el emisor, e incluido en la transmisión del segmento. Se usa la suma en complemento a uno porque el acarreo final de ese método puede ser calculado en cualquier múltiplo de su tamaño (16-bit, 32-bit, 64-bit...) y el resultado, una vez plegado, será el mismo. El receptor TCP recalcula el checksum sobre las cabeceras y datos recibidos. El complemento es usado para que el receptor no tenga que poner a cero el campo del checksum de la cabecera antes de hacer los cálculos, salvando en algún lugar el valor del checksum recibido; en vez de eso, el receptor simplemente calcula la suma en complemento a uno con el checksum incluido, y el resultado debe ser igual a 0. Si es así, se asume que el segmento ha llegado intacto y sin errores.

Hay que fijarse en que el checksum de TCP también cubre los 96 bit de la cabecera que contiene la dirección origen, la dirección destino, el protocolo y el tamaño TCP. Esto proporciona protección contra paquetes mal dirigidos por errores en las direcciones.

El checksum de TCP es una comprobación bastante débil. En niveles de enlace con una alta probabilidad de error de bit quizá requiera una capacidad adicional de corrección/detección de errores de enlace. Si TCP fuese rediseñado hoy, muy probablemente tendría un código de redundancia cíclica (CRC) para control de errores en vez del actual checksum. La debilidad del checksum está parcialmente compensada por el extendido uso de un CRC en el nivel de enlace, bajo TCP e IP, como el usado en el PPP o en Ethernet. Sin embargo, esto no significa que el checksum de 16 bits es redundante: sorprendentemente, inspecciones sobre el tráfico de Internet han mostrado que son comunes los errores de software y hardware[cita requerida] que introducen errores en los paquetes protegidos con un CRC, y que el checksum de 16 bits de TCP detecta la mayoría de estos errores simples.

Los asentimientos (ACKs o Acknowledgments) de los datos enviados o la falta de ellos, son usados por los emisores para interpretar las condiciones de la red entre el emisor y receptor TCP. Unido a los temporizadores, los emisores y receptores TCP pueden alterar el comportamiento del movimiento de datos. TCP usa una serie de mecanismos para conseguir un alto rendimiento y evitar la congestión de la red (la idea es enviar tan rápido como el receptor pueda recibir). Estos mecanismos incluyen el uso de ventana deslizante, que controla que el transmisor mande información dentro de los límites del buffer del receptor, y algoritmos de control de flujo, tales como el algoritmo de Evitación de la Congestión (congestion avoidance), el de comienzo lento (Slow-start), el de retransmisión rápida, el de recuperación rápida (Fast Recovery), y otros.

Es interesante notar que existe un número de secuencia generado por cada lado, ayudando de este modo a que no se puedan establecer conexiones falseadas (spoofing).

Tamaño de ventana

El tamaño de la ventana de recepción TCP es la cantidad de datos recibidos (en bytes) que pueden ser metidos en el buffer de recepción durante la conexión. La entidad emisora puede enviar una cantidad determinada de datos pero antes debe esperar un asentimiento con la actualización del tamaño de ventana por parte del receptor.

Un ejemplo sería el siguiente: un receptor comienza con un tamaño de ventana x y recibe y bytes, entonces su tamaño de ventana será (x - y) y el transmisor sólo podrá mandar paquetes con un tamaño máximo de datos de (x - y) bytes. Los siguientes paquetes recibidos seguirán restando tamaño a la ventana de recepción. Esta situación seguirá así hasta que la aplicación receptora recoja los datos del buffer de recepción. Para una mayor eficiencia en redes de gran ancho de banda, debe ser usado un tamaño de ventana mayor. El campo TCP de tamaño de ventana controla el movimiento de datos y está limitado a 16 bits, es decir, a un tamaño de ventana de 65.535 bytes.

Escalado de ventana

Como el campo de ventana no puede expandirse se usa un factor de escalado. La escala de ventana TCP (TCP window scale) es una opción usada para incrementar el máximo tamaño de ventana desde 65.535 bytes, a 1 Gigabyte.

La opción de escala de ventana TCP es usada solo durante la negociación en tres pasos que constituye el comienzo de la conexión. El valor de la escala representa el número de bits desplazados a la izquierda de los 16 bits que forman el campo del tamaño de ventana. El valor de la escala puede ir desde 0 (sin desplazamiento) hasta 14. Hay que recordar que un número binario desplazado un bit a la izquierda es como multiplicarlo en base decimal por 2.

Fin de la conexión

La fase de finalización de la conexión usa una negociación en cuatro pasos (four-way handshake), terminando la conexión desde cada lado independientemente. Cuando uno de los dos extremos de la conexión desea parar su "mitad" de conexión transmite un paquete FIN, que el otro interlocutor asentirá con un ACK. Por tanto, una desconexión típica requiere un par de segmentos FIN y ACK desde cada lado de la conexión.

Una conexión puede estar "medio abierta" en el caso de que uno de los lados la finalice pero el otro no. El lado que ha dado por finalizada la conexión no puede enviar más datos pero la otra parte si podrá.

Puertos TCP

TCP usa el concepto de número de puerto para identificar a las aplicaciones emisoras y receptoras. Cada lado de la conexión TCP tiene asociado un número de puerto (de 16 bits sin signo, con lo que existen 65536 puertos posibles) asignado por la aplicación emisora o receptora. Los puertos son clasificados en tres categorías: bien conocidos, registrados y dinámicos/privados. Los puertos bien conocidos son asignados por la Internet Assigned Numbers Authority (IANA), van del 0 al 1023 y son usados normalmente por el sistema o por procesos con privilegios. Las aplicaciones que usan este tipo de puertos son ejecutadas como servidores y se quedan a la escucha de conexiones. Algunos ejemplos son: FTP (21), SSH (22), Telnet (23), SMTP (25) y HTTP (80). Los puertos registrados son normalmente empleados por las aplicaciones de usuario de forma temporal cuando conectan con los servidores, pero también pueden representar servicios que hayan sido registrados por un tercero (rango de puertos registrados: 1024 al 49151). Los puertos dinámicos/privados también pueden ser usados por las aplicaciones de usuario, pero este caso es menos común. Los puertos dinámicos/privados no tienen significado fuera de la conexión TCP en la que fueron usados (rango de puertos dinámicos/privados: 49152 al 65535, recordemos que el rango total de 2 elevado a la potencia 16, cubre 65536 números, del 0 al 65535).

Desarrollo de TCP

TCP es un protocolo muy desarrollado y complejo. Sin embargo, mientras mejoras significativas han sido propuestas y llevadas a cabo a lo largo de los años, ha conservado las operaciones más básicas sin cambios desde el  publicado en 1981. El documento(Host Requirements for Internet Hosts), especifica el número de requisitos de una implementación del protocolo TCP. El (Control de Congestión TCP) es uno de los más importantes documentos relativos a TCP de los últimos años, describe nuevos algoritmos para evitar la congestión excesiva. En 2001, el  fue escrito para describir la Notificación de Congestión Explícita (ECN), una forma de eludir la congestión con mecanismos de señalización. En los comienzos del siglo XXI, TCP es usado en el 95% de todos los paquetes que circulan por Internet. Entre las aplicaciones más comunes que usan TCP están HTTP/HTTPS (World Wide Web), SMTP/POP3/IMAP (correo electrónico) y FTP (transferencia de ficheros). Su amplia extensión ha sido la prueba para los desarrolladores originales de que su creación estaba excepcionalmente bien hecha.

Recientemente, un nuevo algoritmo de control de congestión fue desarrollado y nombrado como FAST TCP (Fast Active queue management Scalable Transmission Control Protocol) por los científicos de Caltech (California Institute of Technology). Es similar a TCP Vegas en cuanto a que ambos detectan la congestión a partir de los retrasos en las colas que sufren los paquetes al ser enviados a su destino. Todavía hay un debate abierto sobre si éste es un síntoma apropiado para el control de la congestión.

tpd

UDP es un protocolo estándar con número 6 de STD. Este protocolo se describe en el RFC 768 - Protocolo de Datagrama de Usuario. Este protocolo se recomienda, pero en la práctica cada implementación TCP/IP que no se use exclusivamente para encaminamiento incluirán UDP.
UDP es básicamente una interfaz de aplicación para IP. No soporta confiabilidad, control de flujo o recuperación de errores para IP. Simplemente sirve como "multiplexor/demultiplexor" para enviar y recibir datagramas, usando puertos para dirigir los datagramas como se muestra en la figura adjunta. Se pueden encontrar más detalles sobre puertos en Puertos y Sockets.
UDP proporciona un mecanismo para que una aplicación envíe un datagrama a otra. La capa UDP es sumamente delgada por lo que tiene pocas sobrecargas, pero requiere que la aplicación sea responsable de la recuperación de errores y demás características no soportadas.

Puertos

El concepto de puerto se trató anteriormente en Puertos y Sockets.
Las aplicaciones que envían datagramas hacia un host necesitan identificar el destino, siendo éste más especiífico que la dirección IP, ya que los datagramas están dirigidos normalmente a ciertos procesos y no al sistema completo. UDP proporciona este mecanismo usando puertos.
Un puerto es un número de 16 bits que identifica qué proceso de un host está asociado con un cierto datagrama. Hay dos tipos de puerto:

bien-conocidos

Estos puertos pertenecen a servidores estándares, por ejemplo TELNET usa el puerto 23. El rango de este tipo de puerto está comprendido entre 1 y 1023. Los números de puertos bien-conocidos son típicamente impares porque los primeros sistemas usaban el concepto de puerto como una pareja de puertos impar/par para operaciones duplex. La mayoría de los servidores requieren sólo un puerto. Una excepción es el servidor BOOTP que usa dos: el 67 y el 68 (ver Protocolo BOOTstrap - BOOTP).

El motivo de la utilización de los puertos bien-conocidos es permitir a los clientes tener la capacidad de encontrar servidores sin información de configuración. Los números de dichos puertos están definidos en STD 2 - Números de Internet Asignados.

efímeros

Los clientes no necesitan números de puertos bien-conocidos porque inician la comunicación con servidores y el número de puerto que usan ya está contenido en los datagramas UDP enviados al servidor. Cada proceso del cliente está localizado en un número de puerto mientras el host lo necesite y se esté ejecutando. Los números de puerto efímeros tienen valores mayores que 1023, normalmente en el rango de 1024 a 5000. Un cliente puede usar cualquier número localizado dentro de dicho rango, mientras que la combinación de <protocolo de transporte, dirección IP, número de puerto> es única.

Nota: TCP también usa números de puerto con los mismos valores. Estos puertos son bastante independientes. Normalmente, un servidor usará TCP o UDP, pero hay excepciones. Por ejemplo, los servidores de Nombres de Dominio (ver Sistema de Nombre de Dominio (DNS)) usan ambos, puerto UDP 53 y puerto TCP 53.