Protocolo TCP[editar]

completa del protocolo TCP se encuentra en el documento RFC793 o su traducción al español. TCP
(Transmission-Control-Protocol, en español Protocolo de Control de Transmisión) es de los
protocolos fundamentales en Internet. Fue creado entre los años 1973 - 1974 por Vint Cerf y
Robert Kahn.

Muchos programas dentro de una red de datos compuesta por computadoras pueden usar TCP
para crear conexiones entre ellos a través de las cuales puede enviarse un flujo de datos. El
protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo orden
en que se transmitieron. También proporciona un mecanismo para distinguir distintas aplicaciones
dentro de una misma máquina, a través del concepto de puerto.

TCP da soporte a muchas de las aplicaciones más populares de Internet, incluidas HTTP, SMTP, SSH
y FTP.

TCP es un protocolo de comunicación orientado a conexión y fiable del nivel de transporte,

actualmente documentado por IETF en el RFC 793. Es un protocolo de capa 4 según el modelo OSI.

Funciones de TCP

En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de internet (IP) y la
aplicación. Habitualmente, las aplicaciones necesitan que la comunicación sea fiable y, dado que la
capa IP aporta un servicio de datagramas no fiable (sin confirmación), TCP añade las funciones
necesarias para prestar un servicio que permita que la comunicación entre dos sistemas se efectúe
libre de errores, sin pérdidas y con seguridad.

Los servicios provistos por TCP corren en el anfitrión (host) de cualquiera de los extremos de una
conexión, no en la red. Por lo tanto, TCP es un protocolo para manejar conexiones de extremo a
extremo. Tales conexiones pueden existir a través de una serie de conexiones punto a punto, por
lo que estas conexiones extremo-extremo son llamadas circuitos virtuales. Las características del
TCP son:
Orientado a la conexión: dos computadoras establecen una conexión para intercambiar datos. Los
sistemas de los extremos se sincronizan con el otro para manejar el flujo de paquetes y adaptarse
a la congestión de la red.

Operación Full-Duplex: una conexión TCP es un par de circuitos virtuales, cada uno en una
dirección. Sólo los dos sistemas finales sincronizados pueden usar la conexión.

Error Checking: una técnica de checksum es usada para verificar que los paquetes no estén
corruptos.

Acknowledgements: sobre recibo de uno o más paquetes, el receptor regresa un

acknowledgement (reconocimiento) al transmisor indicando que recibió los paquetes. Si los
paquetes no son notificados, el transmisor puede reenviar los paquetes o terminar la conexión si
el transmisor cree que el receptor no está más en la conexión.

Flow Control: si el transmisor está desbordando el buffer del receptor por transmitir demasiado
rápido, el receptor descarta paquetes. Los acknowledgement fallidos que llegan al transmisor le
alertan para bajar la tasa de transferencia o dejar de transmitir.

Servicio de recuperación de Paquetes: el receptor puede pedir la retransmisión de un paquete. Si

el paquete no es notificado como recibido (ACK), el transmisor envía de nuevo el paquete.

Los servicios confiables de entrega de datos son críticos para aplicaciones tales como
transferencias de archivos (FTP por ejemplo), servicios de bases de datos, proceso de
transacciones y otras aplicaciones de misión crítica en las cuales la entrega de cada paquete debe
ser garantizada.

Formato de los Segmentos TCP

En el nivel de transporte, los paquetes de bits que constituyen las unidades de datos de protocolo
o PDU ('Protocol Data Unit') se llaman "segmentos". El formato de los segmentos TCP se muestra
en el siguiente esquema:

+ Bits 0 - 3 4-7 8 - 15 16 - 31

0 Puerto Origen Puerto Destino

32 Número de Secuencia

64 Número de Acuse de Recibo (ACK)

96 longitud cabecera TCP Reservado Flags Ventana

128 Suma de Verificación (Checksum) Puntero Urgente

160 Opciones + Relleno (opcional)

224

Datos

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 RFC 793, publicado en 1981. El documento RFC 1122 (Host
Requirements for Internet Hosts), especifica el número de requisitos de una implementación del
protocolo TCP. El RFC 2581 (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 RFC 3168 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[editar]

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

al español.
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.

Ejemplo en python

El siguiente ejemplo muestra cómo usar el protocolo UDP para una comunicación cliente/servidor:

Servidor:

import socket

PUERTO = 10000

BUFLEN = 512
server = [Link](socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)

[Link](('', PUERTO))

while True:

(message, address) = [Link](BUFLEN)

print 'Recibiendo paquete desde %s:%d' % (address[0], address[1])

print 'Dato: %s' % message

Cliente (Cambia "[Link]" por la dirección IP del servidor):

import socket

IP_SERVIDOR = '[Link]'

PUERTO_SERVIDOR = 10000

client = [Link](socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)

for i in range(3):

print 'Enviando paquete %d' % i

message = 'Este es el paquete %d' % i

[Link](message, (IP_SERVIDOR, PUERTO_SERVIDOR))

[Link]()

Ejemplo en C++

El siguiente ejemplo muestra cómo usar el protocolo UDP para una comunicación cliente/servidor:
Servidor:

#include <winsock.h>

#pragma comment(lib,"ws2_32.lib")

int main()

WSADATA wsaData;

SOCKET RecvSocket;

sockaddr_in RecvAddr;

int Puerto = 2345;

char RecvBuf[1024];

int BufLen = 1024;

sockaddr_in SenderAddr;

int SenderAddrSize = sizeof(SenderAddr);

WSAStartup(MAKEWORD(2,2), &wsaData);

RecvSocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

RecvAddr.sin_family = AF_INET;

RecvAddr.sin_port = htons(Puerto);

RecvAddr.sin_addr.s_addr = INADDR_ANY;

bind(RecvSocket, (SOCKADDR *) &RecvAddr, sizeof(RecvAddr));

recvfrom(RecvSocket,RecvBuf, BufLen,0,(SOCKADDR *)&SenderAddr,&SenderAddrSize);

printf("%s\n",RecvBuf);

closesocket(RecvSocket);
 WSACleanup();

Cliente (Cambia "[Link]" por la dirección IP del servidor):

#include <winsock.h>

#pragma comment(lib,"ws2_32.lib")

int main()

WSADATA wsaData;

SOCKET SendSocket;

sockaddr_in RecvAddr;

int Puerto = 2345;

char ip[] = "[Link]";

char SendBuf[] = "Hola!!!!";

WSAStartup(MAKEWORD(2,2), &wsaData);

SendSocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

RecvAddr.sin_family = AF_INET;

RecvAddr.sin_port = htons(Puerto);

RecvAddr.sin_addr.s_addr = inet_addr(ip);

sendto(SendSocket,SendBuf,strlen(SendBuf)+1,0,(SOCKADDR *)
&RecvAddr,sizeof(RecvAddr));

WSACleanup();

Comparativa entre UDP y TCP[editar]

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.

Transmisión de vídeo y voz[editar]

UDP es generalmente el protocolo usado en la transmisión de vídeo y voz a través de una red. Esto
es porque no hay tiempo para enviar de nuevo paquetes perdidos cuando se está escuchando a
alguien o viendo un vídeo en tiempo real.

Ya que tanto TCP como UDP circulan por la misma red, en muchos casos ocurre que el aumento
del tráfico UDP daña el correcto funcionamiento de las aplicaciones TCP. Por defecto, TCP pasa a
un segundo lugar para dejar a los datos en tiempo real usar la mayor parte del ancho de banda. El
problema es que ambos son importantes para la mayor parte de las aplicaciones, por lo que
encontrar el equilibrio entre ambos es crucial.

Lista de puertos UDP[editar]

Números de puerto bien conocidos usados por TCP y UDP. También se añade algún otro puerto no
asignado oficialmente por IANA, pero de interés general dado el uso extendido que le da alguna
aplicación.
Puerto/protocolo Descripción

n/d / GRE GRE (protocolo IP 47) Enrutamiento y acceso remoto

n/d / ESP IPSec ESP (protocolo IP 50) Enrutamiento y acceso remoto

n/d / AH IPSec AH (protocolo IP 51) Enrutamiento y acceso remoto

1/tcp Multiplexor TCP

7/tcp Protocolo Echo (Eco) Reponde con eco a llamadas remotas

7/udp Protocolo Echo (Eco) Reponde con eco a llamadas remotas

9/tcp Protocolo Discard Elimina cualquier dato que recibe

9/udp Protocolo Discard Elimina cualquier dato que recibe

13/tcp Protocolo Daytime Fecha y hora actuales

17/tcp Quote of the Day (Cita del Día)

19/tcp Protocolo Chargen Generador de caractéres

19/udp Protocolo Chargen Generador de caractéres

20/tcp FTP File Transfer Protocol (Protocolo de Transferencia de Ficheros) - datos

21/tcp FTP File Transfer Protocol (Protocolo de Transferencia de Ficheros) - control

22/tcp SSH, scp, SFTP

23/tcp Telnet comunicaciones de texto inseguras

25/tcp SMTP Simple Mail Transfer Protocol (Protocolo Simple de Transferencia de Correo)

37/tcp time

43/tcp nicname

53/tcp DNS Domain Name System (Sistema de Nombres de Dominio)

53/udp DNS Domain Name System (Sistema de Nombres de Dominio)

67/udp BOOTP BootStrap Protocol (Server), también usado por DHCP

68/udp BOOTP BootStrap Protocol (Client), también usado por DHCP

69/udp TFTP Trivial File Transfer Protocol (Protocolo Trivial de Transferencia de Ficheros)
70/tcp Gopher

79/tcp Finger

80/tcp HTTP HyperText Transfer Protocol (Protocolo de Transferencia de HiperTexto) (WWW)

88/tcp Kerberos Agente de autenticación

110/tcpPOP3 Post Office Protocol (E-mail)

111/tcpsunrpc

113/tcpident (auth) antiguo sistema de identificación

119/tcpNNTP usado en los grupos de noticias de usenet

123/udp NTP Protocolo de sincronización de tiempo

123/tcpNTP Protocolo de sincronización de tiempo

135/tcpepmap

137/tcpNetBIOS Servicio de nombres

137/udp NetBIOS Servicio de nombres

138/tcpNetBIOS Servicio de envío de datagramas

138/udp NetBIOS Servicio de envío de datagramas

139/tcpNetBIOS Servicio de sesiones

139/udp NetBIOS Servicio de sesiones

143/tcpIMAP4 Internet Message Access Protocol (E-mail)

161/tcpSNMP Simple Network Management Protocol

161/udp SNMP Simple Network Management Protocol

162/tcpSNMP-trap

162/udp SNMP-trap

177/tcpXDMCP Protocolo de gestión de displays en X11

177/udp XDMCP Protocolo de gestión de displays en X11

389/tcpLDAP Protocolo de acceso ligero a Bases de Datos

389/udp LDAP Protocolo de acceso ligero a Bases de Datos

443/tcpHTTPS/SSL usado para la transferencia segura de páginas web

445/tcpMicrosoft-DS (Active Directory, compartición en Windows, gusano Sasser, Agobot)

445/udp Microsoft-DS compartición de ficheros

500/udp IPSec ISAKMP, Autoridad de Seguridad Local

512/tcpexec

513/tcplogin

514/udp syslog usado para logs del sistema

520/udp RIP

591/tcpFileMaker 6.0 (alternativa para HTTP, ver puerto 80)

631/tcpCUPS sistema de impresión de Unix

666/tcpidentificación de Doom para jugar sobre TCP

993/tcpIMAP4 sobre SSL (E-mail)

995/tcpPOP3 sobre SSL (E-mail)

1080/tcp SOCKS Proxy

1337/tcp suele usarse en máquinas comprometidas o infectadas

1352/tcp IBM Lotus Notes/Domino RCP

1433/tcp Microsoft-SQL-Server

1434/tcp Microsoft-SQL-Monitor

1434/udp Microsoft-SQL-Monitor

1494/tcp Citrix MetaFrame Cliente ICA

1512/tcp WINS

1521/tcp Oracle listener por defecto

1701/udp Enrutamiento y Acceso Remoto para VPN con L2TP.

1723/tcp Enrutamiento y Acceso Remoto para VPN con PPTP.

1761/tcp Novell Zenworks Remote Control utility

1863/tcp MSN Messenger

1935/??? FMS Flash Media Server

2049/tcp NFS Archivos del sistema de red

2082/tcp CPanel puerto por defecto

2086/tcp Web Host Manager puerto por defecto

2427/upd Cisco MGCP

3030/tcp NetPanzer

3030/upd NetPanzer

3128/tcp HTTP usado por web caches y por defecto en Squid cache

3128/tcp NDL-AAS

3306/tcp MySQL sistema de gestión de bases de datos

3389/tcp RDP (Remote Desktop Protocol)

3396/tcp Novell agente de impresión NDPS

3690/tcp Subversion (sistema de control de versiones)

4662/tcp eMule (aplicación de compartición de ficheros)

4672/udp eMule (aplicación de compartición de ficheros)

4899/tcp RAdmin (Remote Administrator), herramienta de administración remota

(normalmente troyanos)

5000/tcp Universal plug-and-play

5060/udp Session Initiation Protocol (SIP)

5190/tcp AOL y AOL Instant Messenger

5222/tcp XMPP/Jabber conexión de cliente

5223/tcp XMPP/Jabber puerto por defecto para conexiones de cliente SSL

5269/tcp XMPP/Jabber conexión de servidor

5432/tcp PostgreSQL sistema de gestión de bases de datos

5517/tcp Setiqueue proyecto SETI@Home

5631/tcp PC-Anywhere protocolo de escritorio remoto

5632/udp PC-Anywhere protocolo de escritorio remoto

5400/tcp VNC protocolo de escritorio remoto (usado sobre HTTP)

5500/tcp VNC protocolo de escritorio remoto (usado sobre HTTP)

5600/tcp VNC protocolo de escritorio remoto (usado sobre HTTP)

5700/tcp VNC protocolo de escritorio remoto (usado sobre HTTP)

5800/tcp VNC protocolo de escritorio remoto (usado sobre HTTP)

5900/tcp VNC protocolo de escritorio remoto (conexión normal)

6000/tcp X11 usado para X-windows

6112/udp Blizzard

6129/tcp Dameware Software conexión remota

6346/tcp Gnutella compartición de ficheros (Limewire, etc.)

6347/udp Gnutella

6348/udp Gnutella

6349/udp Gnutella

6350/udp Gnutella

6355/udp Gnutella

6667/tcp IRC IRCU Internet Relay Chat

6881/tcp BitTorrent puerto por defecto

6969/tcp BitTorrent puerto de tracker

7100/tcp Servidor de Fuentes X11

7100/udp Servidor de Fuentes X11

8000/tcp iRDMI por lo general, usado erróneamente en sustitución de 8080. También

utilizado en el servidor de streaming ShoutCast.

8080/tcp HTTP HTTP-ALT ver puerto 80. Tomcat lo usa como puerto por defecto.

8118/tcp privoxy

9009/tcp Pichat peer-to-peer chat server

9898/tcp Gusano Dabber (troyano/virus)

10000/tcp Webmin (Administración remota web)

19226/tcp Panda SecurityPuerto de comunicaciones de Panda Agent. Protocolo

TCP[editar]
completa del protocolo TCP se encuentra en el documento RFC793 o su traducción al
español. TCP (Transmission-Control-Protocol, en español Protocolo de Control de
Transmisión) es de los protocolos fundamentales en Internet. Fue creado entre los años 1973
- 1974 por Vint Cerf y Robert Kahn.

Muchos programas dentro de una red de datos compuesta por computadoras pueden usar
TCP para crear conexiones entre ellos a través de las cuales puede enviarse un flujo de datos.
El protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo
orden en que se transmitieron. También proporciona un mecanismo para distinguir distintas
aplicaciones dentro de una misma máquina, a través del concepto de puerto.

TCP da soporte a muchas de las aplicaciones más populares de Internet, incluidas HTTP,
SMTP, SSH y FTP.

TCP es un protocolo de comunicación orientado a conexión y fiable del nivel de transporte,

actualmente documentado por IETF en el RFC 793. Es un protocolo de capa 4 según el
modelo OSI.

Funciones de TCP

En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de internet (IP) y
la aplicación. Habitualmente, las aplicaciones necesitan que la comunicación sea fiable y,
dado que la capa IP aporta un servicio de datagramas no fiable (sin confirmación), TCP añade
las funciones necesarias para prestar un servicio que permita que la comunicación entre dos
sistemas se efectúe libre de errores, sin pérdidas y con seguridad.

Los servicios provistos por TCP corren en el anfitrión (host) de cualquiera de los extremos de
una conexión, no en la red. Por lo tanto, TCP es un protocolo para manejar conexiones de
extremo a extremo. Tales conexiones pueden existir a través de una serie de conexiones
punto a punto, por lo que estas conexiones extremo-extremo son llamadas circuitos virtuales.
Las características del TCP son:

 Orientado a la conexión: dos computadoras establecen una conexión para intercambiar

datos. Los sistemas de los extremos se sincronizan con el otro para manejar el flujo de
paquetes y adaptarse a la congestión de la red.
 Operación Full-Duplex: una conexión TCP es un par de circuitos virtuales, cada uno en
una dirección. Sólo los dos sistemas finales sincronizados pueden usar la conexión.
 Error Checking: una técnica de checksum es usada para verificar que los paquetes no
estén corruptos.
 Acknowledgements: sobre recibo de uno o más paquetes, el receptor regresa un
acknowledgement (reconocimiento) al transmisor indicando que recibió los paquetes. Si
los paquetes no son notificados, el transmisor puede reenviar los paquetes o terminar la
conexión si el transmisor cree que el receptor no está más en la conexión.
 Flow Control: si el transmisor está desbordando el buffer del receptor por transmitir
demasiado rápido, el receptor descarta paquetes. Los acknowledgement fallidos que
llegan al transmisor le alertan para bajar la tasa de transferencia o dejar de transmitir.
 Servicio de recuperación de Paquetes: el receptor puede pedir la retransmisión de un
paquete. Si el paquete no es notificado como recibido (ACK), el transmisor envía de nuevo
el paquete.

Los servicios confiables de entrega de datos son críticos para aplicaciones tales como
transferencias de archivos (FTP por ejemplo), servicios de bases de datos, proceso de
transacciones y otras aplicaciones de misión crítica en las cuales la entrega de cada paquete
debe ser garantizada.

Formato de los Segmentos TCP

En el nivel de transporte, los paquetes de bits que constituyen las unidades de datos de
protocolo o PDU ('Protocol Data Unit') se llaman "segmentos". El formato de los segmentos
TCP se muestra en el siguiente esquema:

+ Bits 0 - 3 4-7 8 - 15 16 - 31

0 Puerto Origen Puerto Destino

32 Número de Secuencia

64 Número de Acuse de Recibo (ACK)

longitud
96 cabecera Reservado Flags Ventana
TCP
 128 Suma de Verificación (Checksum) Puntero Urgente

160 Opciones + Relleno (opcional)

224 Datos

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 RFC 793, publicado en 1981. El
documento RFC 1122 (Host Requirements for Internet Hosts), especifica el número de
requisitos de una implementación del protocolo TCP. El RFC 2581 (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 RFC 3168 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[editar]
La descripción completa del protocolo UDP se encuentra en el documento RFC768 o
su traducción al español.

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.

Ejemplo en python

El siguiente ejemplo muestra cómo usar el protocolo UDP para una comunicación
cliente/servidor:

Servidor:

import socket

PUERTO = 10000
BUFLEN = 512

server = [Link](socket.AF_INET, socket.SOCK_DGRAM,

socket.IPPROTO_UDP)
[Link](('', PUERTO))

while True:
(message, address) = [Link](BUFLEN)
print 'Recibiendo paquete desde %s:%d' % (address[0], address[1])
print 'Dato: %s' % message

Cliente (Cambia "[Link]" por la dirección IP del servidor):

import socket

IP_SERVIDOR = '[Link]'
PUERTO_SERVIDOR = 10000

client = [Link](socket.AF_INET, socket.SOCK_DGRAM,

socket.IPPROTO_UDP)

for i in range(3):
print 'Enviando paquete %d' % i
message = 'Este es el paquete %d' % i
[Link](message, (IP_SERVIDOR, PUERTO_SERVIDOR))
[Link]()

Ejemplo en C++

El siguiente ejemplo muestra cómo usar el protocolo UDP para una comunicación
cliente/servidor:

Servidor:

#include <winsock.h>
#pragma comment(lib,"ws2_32.lib")

int main()
{
WSADATA wsaData;
SOCKET RecvSocket;
sockaddr_in RecvAddr;
int Puerto = 2345;
char RecvBuf[1024];
int BufLen = 1024;
sockaddr_in SenderAddr;
int SenderAddrSize = sizeof(SenderAddr);
WSAStartup(MAKEWORD(2,2), &wsaData);
RecvSocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
RecvAddr.sin_family = AF_INET;
RecvAddr.sin_port = htons(Puerto);
RecvAddr.sin_addr.s_addr = INADDR_ANY;
bind(RecvSocket, (SOCKADDR *) &RecvAddr, sizeof(RecvAddr));
recvfrom(RecvSocket,RecvBuf, BufLen,0,(SOCKADDR
*)&SenderAddr,&SenderAddrSize);
printf("%s\n",RecvBuf);
closesocket(RecvSocket);
WSACleanup();
}

Cliente (Cambia "[Link]" por la dirección IP del servidor):

#include <winsock.h>
#pragma comment(lib,"ws2_32.lib")
int main()
{
WSADATA wsaData;
SOCKET SendSocket;
sockaddr_in RecvAddr;
int Puerto = 2345;
char ip[] = "[Link]";
char SendBuf[] = "Hola!!!!";
WSAStartup(MAKEWORD(2,2), &wsaData);
SendSocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
RecvAddr.sin_family = AF_INET;
RecvAddr.sin_port = htons(Puerto);
RecvAddr.sin_addr.s_addr = inet_addr(ip);
sendto(SendSocket,SendBuf,strlen(SendBuf)+1,0,(SOCKADDR *)
&RecvAddr,sizeof(RecvAddr));
WSACleanup();
}

Comparativa entre UDP y TCP[editar]

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.
Transmisión de vídeo y voz[editar]

UDP es generalmente el protocolo usado en la transmisión de vídeo y voz a través de

una red. Esto es porque no hay tiempo para enviar de nuevo paquetes perdidos
cuando se está escuchando a alguien o viendo un vídeo en tiempo real.

Ya que tanto TCP como UDP circulan por la misma red, en muchos casos ocurre que
el aumento del tráfico UDP daña el correcto funcionamiento de las aplicaciones TCP.
Por defecto, TCP pasa a un segundo lugar para dejar a los datos en tiempo real usar
la mayor parte del ancho de banda. El problema es que ambos son importantes para
la mayor parte de las aplicaciones, por lo que encontrar el equilibrio entre ambos es
crucial.

Lista de puertos UDP[editar]

Números de puerto bien conocidos usados por TCP y UDP. También se añade algún
otro puerto no asignado oficialmente por IANA, pero de interés general dado el uso
extendido que le da alguna aplicación.

Puerto/
Descripción
protocolo

n/d / GRE GRE (protocolo IP 47) Enrutamiento y acceso remoto

n/d / ESP IPSec ESP (protocolo IP 50) Enrutamiento y acceso remoto

n/d / AH IPSec AH (protocolo IP 51) Enrutamiento y acceso remoto

1/tcp Multiplexor TCP

7/tcp Protocolo Echo (Eco) Reponde con eco a llamadas remotas

7/udp Protocolo Echo (Eco) Reponde con eco a llamadas remotas

9/tcp Protocolo Discard Elimina cualquier dato que recibe

9/udp Protocolo Discard Elimina cualquier dato que recibe

13/tcp Protocolo Daytime Fecha y hora actuales

17/tcp Quote of the Day (Cita del Día)

19/tcp Protocolo Chargen Generador de caractéres

19/udp Protocolo Chargen Generador de caractéres

 FTP File Transfer Protocol (Protocolo de Transferencia de Ficheros) -
20/tcp
datos

FTP File Transfer Protocol (Protocolo de Transferencia de Ficheros) -

21/tcp
control

22/tcp SSH, scp, SFTP

23/tcp Telnet comunicaciones de texto inseguras

SMTP Simple Mail Transfer Protocol (Protocolo Simple de Transferencia

25/tcp
de Correo)

37/tcp time

43/tcp nicname

53/tcp DNS Domain Name System (Sistema de Nombres de Dominio)

53/udp DNS Domain Name System (Sistema de Nombres de Dominio)

67/udp BOOTP BootStrap Protocol (Server), también usado por DHCP

68/udp BOOTP BootStrap Protocol (Client), también usado por DHCP

TFTP Trivial File Transfer Protocol (Protocolo Trivial de Transferencia de

69/udp
Ficheros)

70/tcp Gopher

79/tcp Finger

HTTP HyperText Transfer Protocol (Protocolo de Transferencia de

80/tcp
HiperTexto) (WWW)

88/tcp Kerberos Agente de autenticación

110/tcp POP3 Post Office Protocol (E-mail)

111/tcp sunrpc

113/tcp ident (auth) antiguo sistema de identificación

119/tcp NNTP usado en los grupos de noticias de usenet

123/udp NTP Protocolo de sincronización de tiempo

123/tcp NTP Protocolo de sincronización de tiempo

135/tcp epmap

137/tcp NetBIOS Servicio de nombres

137/udp NetBIOS Servicio de nombres

138/tcp NetBIOS Servicio de envío de datagramas

138/udp NetBIOS Servicio de envío de datagramas

139/tcp NetBIOS Servicio de sesiones

139/udp NetBIOS Servicio de sesiones

143/tcp IMAP4 Internet Message Access Protocol (E-mail)

161/tcp SNMP Simple Network Management Protocol

161/udp SNMP Simple Network Management Protocol

162/tcp SNMP-trap

162/udp SNMP-trap

177/tcp XDMCP Protocolo de gestión de displays en X11

177/udp XDMCP Protocolo de gestión de displays en X11

389/tcp LDAP Protocolo de acceso ligero a Bases de Datos

389/udp LDAP Protocolo de acceso ligero a Bases de Datos

443/tcp HTTPS/SSL usado para la transferencia segura de páginas web

Microsoft-DS (Active Directory, compartición en Windows, gusano Sasser,

445/tcp
Agobot)

445/udp Microsoft-DS compartición de ficheros

500/udp IPSec ISAKMP, Autoridad de Seguridad Local

512/tcp exec

513/tcp login

514/udp syslog usado para logs del sistema

520/udp RIP

591/tcp FileMaker 6.0 (alternativa para HTTP, ver puerto 80)

631/tcp CUPS sistema de impresión de Unix

666/tcp identificación de Doom para jugar sobre TCP

993/tcp IMAP4 sobre SSL (E-mail)

995/tcp POP3 sobre SSL (E-mail)

1080/tcp SOCKS Proxy

1337/tcp suele usarse en máquinas comprometidas o infectadas

1352/tcp IBM Lotus Notes/Domino RCP

1433/tcp Microsoft-SQL-Server
1434/tcp Microsoft-SQL-Monitor

1434/udp Microsoft-SQL-Monitor

1494/tcp Citrix MetaFrame Cliente ICA

1512/tcp WINS

1521/tcp Oracle listener por defecto

1701/udp Enrutamiento y Acceso Remoto para VPN con L2TP.

1723/tcp Enrutamiento y Acceso Remoto para VPN con PPTP.

1761/tcp Novell Zenworks Remote Control utility

1863/tcp MSN Messenger

1935/??? FMS Flash Media Server

2049/tcp NFS Archivos del sistema de red

2082/tcp CPanel puerto por defecto

2086/tcp Web Host Manager puerto por defecto

2427/upd Cisco MGCP

3030/tcp NetPanzer

3030/upd NetPanzer

3128/tcp HTTP usado por web caches y por defecto en Squid cache

3128/tcp NDL-AAS

3306/tcp MySQL sistema de gestión de bases de datos

3389/tcp RDP (Remote Desktop Protocol)

3396/tcp Novell agente de impresión NDPS

3690/tcp Subversion (sistema de control de versiones)

4662/tcp eMule (aplicación de compartición de ficheros)

4672/udp eMule (aplicación de compartición de ficheros)

RAdmin (Remote Administrator), herramienta de administración remota

4899/tcp
(normalmente troyanos)

5000/tcp Universal plug-and-play

5060/udp Session Initiation Protocol (SIP)

5190/tcp AOL y AOL Instant Messenger

5222/tcp XMPP/Jabber conexión de cliente

5223/tcp XMPP/Jabber puerto por defecto para conexiones de cliente SSL

5269/tcp XMPP/Jabber conexión de servidor

5432/tcp PostgreSQL sistema de gestión de bases de datos

5517/tcp Setiqueue proyecto SETI@Home

5631/tcp PC-Anywhere protocolo de escritorio remoto

5632/udp PC-Anywhere protocolo de escritorio remoto

5400/tcp VNC protocolo de escritorio remoto (usado sobre HTTP)

5500/tcp VNC protocolo de escritorio remoto (usado sobre HTTP)

5600/tcp VNC protocolo de escritorio remoto (usado sobre HTTP)

5700/tcp VNC protocolo de escritorio remoto (usado sobre HTTP)

5800/tcp VNC protocolo de escritorio remoto (usado sobre HTTP)

5900/tcp VNC protocolo de escritorio remoto (conexión normal)

6000/tcp X11 usado para X-windows

6112/udp Blizzard

6129/tcp Dameware Software conexión remota

6346/tcp Gnutella compartición de ficheros (Limewire, etc.)

6347/udp Gnutella

6348/udp Gnutella

6349/udp Gnutella

6350/udp Gnutella

6355/udp Gnutella

6667/tcp IRC IRCU Internet Relay Chat

6881/tcp BitTorrent puerto por defecto

6969/tcp BitTorrent puerto de tracker

7100/tcp Servidor de Fuentes X11

7100/udp Servidor de Fuentes X11

iRDMI por lo general, usado erróneamente en sustitución de 8080.

8000/tcp
También utilizado en el servidor de streaming ShoutCast.

8080/tcp HTTP HTTP-ALT ver puerto 80. Tomcat lo usa como puerto por defecto.

8118/tcp privoxy
 9009/tcp Pichat peer-to-peer chat server

9898/tcp Gusano Dabber (troyano/virus)

10000/tcp Webmin (Administración remota web)

19226/tcp Panda SecurityPuerto de comunicaciones de Panda Agent.

12345/tcp NetBus en:NetBus (troyano/virus)

Back Orifice herramienta de administración remota (por lo general

31337/tcp
troyanos)

12345/tcp NetBus en:NetBus (troyano/virus)

31337/tcp Back Orifice herramienta de administración remota (por lo general troyanos)