3 Analisis Comparativo TCP - UDP

Editar 0 8

3. Anlisis comparativo: TCP - UDP

Los dos protocolos ms comunes de la capa de Transporte del conjunto
de protocolos TCP/IP son el Protocolo de control de transmisin (TCP) y
el Protocolo de datagramas de usuario (UDP). Ambos protocolos
gestionan la comunicacin de mltiples aplicaciones. Las diferencias
entre ellos son las funciones especficas que cada uno implementa.
TCP vs UDP
TCP

UDP
Orientado a la conexin

Sin conexin

Confiabilidad en la entrega de
mensajes

No se fragmentan los mensajes

No hay reensamblaje ni sincronizacin

Divide los mensajes en datagramas

En caso de error, el mensaje se retransmite
Hace seguimiento del orden (o
secuencia)

Sin acuse de envo

Usa checksums para la deteccin

de errores
Los procedimientos remotos no
son idempotentes
La confiabilidad es prioridad

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)

Los mensajes exceden el tamao

de un paquete UDP

TCP y UDP utilizan el mismo esquema de direccionamiento. Una

direccin IP y un nmero de puerto.
Ventajas de UDP

Ventajas de TCP

No te restringe a un modelo de comunicacin

basado en la conexin, la latencia para el inicio en
aplicaciones distribuidas es mucho menor, al igual que la

El sistema operativo hace todo el trabajo,

el manejo de paquetes de entrada tiene menos
cambios de contexto del kernel al espacio de

sobrecarga del sistema operativo.

usuario y de vuelta, todo el reensamblaje, acuse

de recibo, control de flujo, etc se lleva a cabo por
el kernel.

Todo el control de flujo, los acuses de recibo, el

registro de transacciones, etc. depende de los programas de
TCP garantiza tres cosas: que sus datos
usuario. Adems, slo es necesario implementar y utilizar
las funciones que necesita.
lleguen, que lleguen en orden, y que lleguen sin
duplicaciones.
El receptor de los paquetes UDP los recibe sin
Los routers pueden notar los paquetes
fragmentar, incluyendo los lmites de los bloques.
TCP y los tratan de forma especial. los pueden
almacenar en bfer y los retransmiten.
Broadcast y transmisin multicast estn
disponibles con UDP.
TCP tiene un buen rendimiento relativo a
travs de un mdem o una LAN.

Desventajas de UDP

Desventajas de TCP

No hay garantas con UDP. un paquete puede no

El sistema operativo puede ser
ser entregado, o entregado dos veces o entregado fuera de defectuoso.Puede ser ineficaz, y puede que no se
orden, no se obtiene ningn indicio de esto a menos que el pueda afinar.
programa de escucha en el otro extremo decide decir algo.
TCP es dficil de expandir,se puede
UDP no tiene control de flujo. la implementacin establecer una pocas opciones de socket,pero
es el deber de los programas de usuario.
tiene que tolerar el control de flujo incorporado.
Los routers son muy descuidados con UDP. nunca
TCP puede tener un montn de
se retransmiten si colisionan, y parecen ser la primera cosa caractersticasque no son necesarias, puede
descartada cuando un router est corto de memoria. UDP desperdiciar ancho de banda, tiempo oesfuerzo en
sufre ms prdida de paquetes que TCP.
asegurar cosas que son irrelevantes para la tarea
en cuestin.
TCP no tiene lmites de bloques, debe
crear el suyo.
Los routers de la Internet de hoy en da
estn agotando su memoria, no pueden prestar
mucha atencin a tcp, las asumpsiones de diseo
de TCP se descomponen en este entorno.
TCP tiene rendimiento relativamente
pobre en conexiones de alta latencia, gran ancho
de banda como una conexin por satlite o con
sobrecarga.
TCP no puede ser utilizado para
broadcast o transmisin multicast.

TCP no puede concluir una transmisin

sin todos los datos en movimiento explcitamente
confirmados.

Ventajas de la UDP para la

transferencia de archivos

Desventajas de TCP para la

transferencia de archivos

El control de flujo depende del espacio de usuario;

TCP permite una ventana de un mximo
las ventanas pueden ser infinitas, no existen interrupciones de 64k, y el mecanismo de ACKING significa que
artificiales, la latencia es bien tolerada, y las velocidades la prdida de paquetes no se ha detectado.
mximas solo se pueden forzar por ancho de banda real, a
pesar de que las velocidades reales son elegidas por
Los servidores de transferencia TCP han
acuerdo entre el emisor y el receptor.
de mantener un socket separado (y a menudo un
hilo separado) para cada cliente.
Si recibe una imagen de forma simultnea desde
varios hosts es mucho ms fcil con UDP, como lo es el
El balanceo de carga es crudo y
envo a varios hosts, especialmente si llegan a ser parte del aproximado. Especialmente en las redes locales
mismo grupo broadcast o multicast.
que permiten colisiones, dos transferencias
simultneas de TCP tienen una tendencia a pelear
unas con otras, incluso si el remitente es el
mismo.

2.8 Informacion adicional sobre UDP

Editar 0 8

2.8 Informacin adicional sobre UDP

Si bien UDP es a veces la mejor alternativa para ciertos tipos de
aplicaciones, debido a sus propiedades nicas, presenta algunos retos
para los desarrolladores. Sin embargo,estos retos pueden ser
satisfechos mediante la estructuracin de la transmisin de datos para
superar las limitaciones de UDP. A continuacin se examinan estas
limitaciones y cmo pueden ser superadas.
2.8.1 Falta de entrega garantizada
Los paquetes enviados a travs de UDP pueden perderse en trnsitocada salto adicional entre un router y otro presenta ms retrasos y
aumenta la probabilidad de que un paquete pueda ser descartado
cuando el TTL llega a cero. Adems, los paquetes UDP pueden daarse
operderse si laconexin de red fsica en la que se enrutan se cae.Ya que

los paquetesde Internet son transmitidos a travs deuna red pblica,

integrada por una amplia gama de infraestructuras de red, es probable
que los paquetes se pierdan en algn punto de la conexin.
Por supuesto, en algunas aplicaciones de la prdida de paquetes
individuales puede no tener un efecto notable. Por ejemplo, una
secuencia de vdeo puede perder unos cuantos cuadros de imagen, pero
siempre que la mayora de las tramas lleguen, la prdida es soportable.
Sin embargo, si un archivo se est transfiriendo, entonces el contenido
del archivo se convertir en ilegible, y la prdida de paquetes llega a ser
inaceptable. Si la entrega garantizada es requerida, la mejor alternativa
es evitar la comunicacin basada en paquetes y utilizar un mecanismo
de transporte ms adecuado, como el Transmission Control Protocol
(TCP). No obstante, si el uso de la UDP es pedido, una solucin es que la
parte que recibe los paquetes enve un paquete de
confirmacin(tambin conocido como ACK) de vuelta al remitente. La
ausencia de un ACK indica que el paquete se haperdido y debe ser
retransmitido.
NOTAAlgunos sistemas de transporte enviarn de vuelta un ACK para
paquetes individuales o para una amplia gama de paquetes. A pesar de
que se le aade complejidad, el reconocimiento de una serie de
paquetes hace un uso ms eficiente del ancho de banda. Algunos
sistemas tambin utilizan un paquete de reconocimiento negative (NAK)
para indicar que un paquete especfico se perdi, lo que desencadena
inmediatamente la retransmisin de ese paquete.
2.8.2 Falta de secuencia de paquetes garantizada
Las aplicaciones que requieren el acceso secuencial a los datos (y
seamos sinceros, que equivale a la mayora del software) deben incluir
un nmero de secuencia en el contenido de un paquete datagrama. Si
llega un paquete fuera de orden, puede ser almacenado en buffer hasta
que los paquetes anteriores se han alcanzado. La secuencia aade una
pequea cantidad de complejidad, pero hace un sistema ms fiable,
(siempre sabes con qu paquete ests tratando). Los paquetes
duplicados deben ser desechados, y los paquetes perdidos (debido a la
falta de entrega garantizada) solicitados de nuevo.

2.1 User Datagram Protocol (UDP)

Editar 0 16

2. User Datagram Protocol (UDP)

2.1 Visin general
El protocolo UDP (UserDatagram Protocol) es un protocolo no orientado a
conexin de la capa de transporte del modelo TCP/IP, lo que significa que
nogarantizar ni la entrega de paquetes ni que los paquetes lleguen en orden
secuencial, donde el control sobre el destino final de un paquete UDP recae en
el equipo que lo enva.

Figura N 7: UDP en una red pueden ser poco fiables

Dado la probabilidad de prdida de paquetes de datos, puede parecer extrao

que a nadie se le ocurra utilizar un sistema tan poco fiable, aparentemente
anrquica. De hecho, hay muchas ventajas al usar UDP que pueden no ser
evidentes a primera vista.

UDP puede ser ms eficiente que la entrega garantizada de flujos de

datos de. Si la cantidad de datos es pequea y los datos se envan con
frecuencia, tiene sentido usarla para evitar la sobrecarga de entrega
garantizada.

A diferencia de TCP, que establecen una conexin, UDP causa menos

gastos generales. Si la cantidad de datos que se envan es pequea y los datos
se envan con frecuencia, la sobrecarga de establecer una conexin no puede
valer la pena. UDP puede ser preferible en este caso, sobre todo si se envan
los datos de un gran nmero de mquinas a una central, en cuyo caso la suma
total de todas estas conexiones pueden provocar una sobrecarga considerable.

Las aplicaciones en tiempo real pueden ser candidatos para usar UDP, ya
que hay menos retrasos debido a la comprobacin de errores y control de flujo
de TCP. Los Paquetes UDP pueden ser utilizados para saturar el ancho de
banda disponible para ofrecer grandes cantidades de datos. Adems, si se
pierden algunos datos, pueden ser sustituidos por el siguiente grupo de
paquetes con informacin actualizada, eliminando la necesidad de volver a
enviar los datos antiguos.

Los sockets UDP puede recibir datos de ms de un host. Si hay varias

mquinasdebe haber comunicacin, entonces UDP puede ser ms conveniente
que otros mecanismos como TCP.

Algunos protocolos de red especificar UDP como mecanismo de

transporte, que requiriendo su uso.

Un socket es una referencia indirecta a un puerto particular usada por el

proceso receptor en la mquina receptora.
El envo de datagramas es similar a enviar una carta a travs del servicio
postal: El orden de salida no es importante y no est garantizado, y cada
mensaje es independiente de cualquier otro.
En las comunicaciones basadas en datagramas como las UDP, el paquete de
datagramas contiene el nmero de puerto de su destino y el UDP encamina el
paquete a la aplicacin apropiada. Como en la figura N 8

Figura N 8: Comunicacin basada en datagramasUn datagrama enviado mediante

UDP es trasmitido desde un proceso emisor a un proceso receptor sin

reconocimiento o recomprobaciones. Si tiene lugar un fallo, el mensaje puede
no llegar. Un datagrama es transmitido entre procesos cuando un proceso lo
enva y otro proceso lo recibe. Cualquier proceso que necesite enviar o recibir
mensajes debe en primer lugar crear un socket a una direccin de Internet y
un puerto local. Un servidor enlazar ese socket a un puerto servidor - uno que
se hace conocido a los clientes de manera que puedan enviar mensajes al
mismo. Un cliente enlaza su socket a cualquier puerto local libre. El mtodo
receptor devuelve la direccin de Internet y el puerto del emisor, adems del
mensaje, permitiendo a los receptores enviar una respuesta.

Figura N 9: un servidor utiliza dos sockets: uno para aceptar la conexin y el otro para enviar /
receptor

Las clases Java para establecer comunicaciones mediante datagramas son:

java.net.DatagramPacket

java.net.DatagramSocket

2.2 Clase DatagramPacket

Editar 0 17

2 User Datagram Protocol (UDP)

2.2 Clase DatagramPacket
La clase DatagramPacket representa un paquete de datos destinados a
la transmisin mediante el uso de UDP. Los paquetes son contenedores
de una pequea secuencia de bytes, e incluyen informacin de
direccionamiento, como una direccin IP y un puerto.

Figura N 10: DatagramPacket

El significado de los datos almacenados en un DatagramPacket est

determinado por su contexto. Cuando un DatagramPacket se ha ledo
desde un socket UDP, la direccin IP del paquete representa la direccin
del remitente (lo mismo con el nmero de puerto). Sin embargo, cuando
un DatagramPacket es usado para enviar un paquete UDP, la direccin
IP almacenada en DatagramPacket representa la direccin del
destinatario (lo mismo con el nmero de puerto). Esta inversin de
sentido es importante Recuerde uno no querr enviar un paquete de
regreso a uno mismo.

2.2.1 Creando un DatagramPacket

Hay dos razones para crear un nuevo DatagramPacket:
I. Para enviar datos a una mquina remota usando UDP
II. Para recibir los datos enviados por una mquina remota usando UDP
La clase DatagramPacket proporciona un constructor que permite crear
instancias de un array de bytes para el mensaje, la longitud del
mensaje, la direccin Internet y el puerto local del socket de destino, de
la siguiente forma:
Constructores
La eleccin del constructor DatagramPacket es determinada por su
finalidad.
Cada constructor requiere la especificacin de un conjunto de bytes, el
cual se utilizar para almacenar el contenido del paquete UDP, y la
longitud del paquete de datos.
Para crear un DatagramPacket para la recepcin de paquetes UDP
entrantes, el siguiente constructor debe ser
usado:DatagramPacket(byte[] buffer, int length).Por
ejemplo:DatagramPacket packet = new DatagramPacket(new byte[256],
256);
Para enviar un DatagramPacket a una mquina remota, es preferible
utilizar el siguientes constructor:DatagramPacket(byte[] buffer, int
length, InetAddress dest_addr, int dest_port).Por ejemplo:InetAddress
addr = InetAddress.getByName("192.168.0.1")DatagramPacket packet
= new DatagramPacket ( new byte[128], 128, addr, 2000);
2.2.2 Usando un DatagramPacketLa clase DatagramPacket
proporciona algunos mtodos importantes que permiten a: la direccin
remota, puerto remoto, los datos (como un bytes de array), y la
longitud del paquete puedan ser recuperado. A partir de JDK 1.1, hay
tambin mtodos para modificar estos, a travs de un mtodo set
correspondiente. Esto significa que uno recibepaquetes que puedan ser
reutilizados. Por ejemplo, el contenido de un paquete puede ser
reemplazado y enviado de vuelta al remitente. Esto ahorra el tener que
reiniciar la informacin de direccionamiento, la direccin y el puerto del
paquete que ya est establecido en el remitente.
Mtodos

InetAddress getAddress() - devuelve la direccin IP desde que

unDatagramPacket fue enviado, o (si el paquete va a ser enviado a una
mquina remota), la direccin IP de destino.

byte [] getData () - devuelve el contenido de la DatagramPacket,

representado como una matriz de bytes.

int getLength int () - devuelve la longitud de los datos

almacenados en un DatagramPacket. Esto puede ser menor que el
tamao real del bfer de datos

int getPort () - devuelve el nmero de puerto desde donde se

envi un DatagramPacket, o (si el paquete va a ser enviado a una
mquina remota), el nmero de puerto de destino.

void setAddress (InetAddress addr) - asigna una nueva direccin

de destino a un DatagramPacket.

void setData (byte [] buffer) - asigna un buffer de datos nuevos a

la DatagramPacket.

void SetLength (int length) - asigna una nueva longitud de

la DatagramPacket.

Void setPort (int port) - asigna un puerto de destino a un

nuevo DatagramPacket.

2.3 Clase DatagramSocket

Editar 0 9

2.3 Clase DatagramSocket

La clase DatagramSocket proporciona acceso a un socket UDP, lo que
permite que los paquetes UDP puedan ser enviados y recibidos. Un
DatagramPacket se utiliza para representar un paquete UDP, y debe ser
creado antes de recibir los paquetes. El mismo DatagramSocket puede
ser usado para recibir los paquetes tanto como para enviarlos.
Sin embargo, las operaciones de lectura son de bloqueo, lo que significa
que la aplicacincontinuara esperando hasta que llega un paquete. Ya
que los paquetes UDP no garantizan la entrega, esto puede causar que
una aplicacin se detenga si el remitente no vuelva a enviar los
paquetes. Ya que los paquetes UDP no garantizan la entrega, esto puede
originar que una aplicacin se detenga si el remitente no vuelva a enviar

los paquetes.
2.3.1 Creando un DatagramSocketA DatagramSocket puede ser
utilizado para enviar y recibir paquetes. Cada DatagramSocket se une a
un puerto en la mquina local, el cual es usado para dirigir a los
paquetes. El nmero de puerto necesita no ser el mismo nmero de la
mquina remota, pero si la aplicacin es un servidor UDP, se suelen
elegir un nmero de puerto especfico. Si el DatagramSocket est
destinado a ser un cliente, yno necesita que se una a un nmero de
puerto especfico, un constructor en blanco puede ser especificado.
Constructor
Para crear un DatagramSocket cliente, el siguiente constructor es
usado:
DatagramSocket () throws java.net.SocketException.
Para crear un server Datagram Socket, el siguiente constructor es
usado: que toma como parmetro el puerto al que el servicio UDP ser
obligado:
DatagramSocket (int puerto) throws java.net.SocketException
2.3.2 Usando un DatagramSocketDatagramSocket se utiliza para
recibir los paquetes UDP entrantes y salientes para enviar paquetes UDP.
Proporciona mtodos para enviar y recibir paquetes, as tambin como
especificar un valor de tiempo de espera cuando nonblocking I/O est
utilizando, para inspeccionar y modificar el mximo tamao de los
paquetes UDP, y cerca del zcalo.
Mtodos

void close () - cierra un socket, y se desliga del puerto local.

void connect (InetAddress remote_addr remote_port int)

restringe el acceso a la direccin especificada a distancia y el puerto. La
designacin es un trmino equivocado, ya que UDP en realidad no crear
una "conexin" entre una mquina y otra. Sin embargo, si este mtodo
se utiliza, hace que las excepciones que se produce si se intenta enviar
paquetes a,o leer los paquetes de cualquier otro host y el puerto a los
especificados.

void disconnect() - desconecta el DatagramSocket.

InetAddress getInetAddress () - Devuelve la direccin remota a la
que el socket est conectado, o null si no existe ninguna tal conexin.

int getPort () - devuelve el puerto remoto al que est conectado el

socket, o -1 si no existe dicha conexin.

InetAddress getLocalAddress () - devuelve la direccin local a la

que el socket esta enlazado.

int getLocalPort () - devuelve el puerto local al que est enlazado

el conector.

int getReceiveBufferSize () throws java.net.SocketException

devuelve el tamao mximo del bfer utilizado para los paquetes UDP
entrantes.

int getSendBufferSize () throws java.net.SocketException devuelve el tamao mximo de bfer utilizado para paquetes UDP
salientes.

getSoTimeout int () throws java.net.SocketException - devuelve el

valor de la opcin de conector de tiempo de espera. Este valor se utiliza
para determinar el nmero de milisegundos que una operacin de
lectura bloqueara antes de lanzar un java.io.InterruptedIOException. De
manera predeterminada, este valor ser igual a cero, lo que indica que
el bloqueo de E / S se utilizar.

void receive (DatagramPacket packet)) throws

java.io.IOException- lee un paquete UDP y almacena el contenido en el
paquete especificado. La direccin y el puerto.

2.5 Enviar paquetes UDP

Editar 0 8

2.5 Enviar paquetes UDP

La misma interfaz (DatagramSocket) empleada para recibir paquetes UDP
tambin se utiliza para enviarlos. Cuando se enva un paquete, la aplicacin
debe crear un DatagramPacket, establecer la direccin y el puerto de la
informacin, y escribir los datos destinados a la transmisin a su array de
bytes. Si est respondiendo a un paquete recibido, la direccin y la informacin
del puerto ya estar almacenada, y slo los datosnecesitan ser sobrescritos.
Una vez que el paquete est listo para la transmisin, el mtodo de envo
deDatagramSocket es invocado, y un paquete UDP se enva.

El siguiente fragmento de cdigo ilustra este proceso:

DatagramSocket socket = new DatagramSocket(2000);

DatagramPacket packet = new DatagramPacket (new byte[256], 256);
packet.setAddress ( InetAddress.getByName ( somehost ) );
packet.setPort ( 2000 );
boolean finished = false;
while !finished )
{
// Escribir datos en el buffer del paquete
.........
socket.send (packet);
/ / Hacer otra cosa, como leer los paquetes, o revisar para
/ / ver si hay ms paquetes a enviar
.........
}

socket.close();

TCP: Est diseado para enrutar y tiene un grado muy elevado de

confiabilidad por parte de seguridad al enviar y recibir informacin,
es adecuado para redes grandes y medianas, as como en redes
empresariales.
UDP: esta oriantado a la transmisin de tramas, este es muy felxible
y no se preocupa por el orden en que lleguen los paquetes, como
analoga, se puede comparar como correo nacional, se envian los
paquetes pero estos pueden llegar en distintos tiempos, sin importar
que se hayan enviado al mismo tiempo.
TCP, UDP y los protocolos relacionados permiten que una gran variedad
de sistemas computacionales heterogneos (es decir, sistemas

computacionales con diferentes procesadores y sistemas operativos) se

comuniquen unos con otros.

Protocolos de capa de transporte TCP/IP (inicio de

TCP/UDP)
Publicado por Enrique Perez en mircoles, enero 29, 2014

Esto es solo introduccin, ya estn en el horno los captulos subsiguientes, pero quera darles un
adelanto. Adems me cay en las manos un artculo muy completo sobre traceroute, que esta por
salir en unos das (son varios artculos de hecho ... como "mashup" ). Pues eso, provecho y hasta el
siguiente.
Protocolos de la capa de transporte TCP / IP.
Las tres primeras capas del modelo de referencia OSI - la capa fsica, la de enlace de datos y la de
red - son capas muy importantes para la comprensin de cmo funcionan las redes. La capa fsica
mueve los bits a travs de cables; la capa de enlace de datos mueve tramas en una red, la capa de red
mueve datagramas en una interconexin de redes. Tomadas en su conjunto, son las partes de la pila
de protocolos responsables de las "tuercas y tornillos" reales del proceso de llevar datos de un lugar
a otro.
Inmediatamente por encima de stas tenemos la cuarta capa del modelo de referencia OSI: la capa
de transporte, llamada la capa de transporte host-to-host en el modelo TCP/IP. Esta capa es
interesante, ya que reside en el mismo centro arquitectnico del modelo. Por consiguiente,
representa un importante punto de transicin entre las capas asociadas al hardware ubicadas por
debajo de ella que hacen el "trabajo sucio", y las capas que estn por encima, mas orientadas al
software y por ende mas abstractas.
Los protocolos que operan en la capa de transporte estn a cargo de proporcionar varios servicios
importantes para que las aplicaciones de software en las capas superiores trabajen a travs de una
interconexin de redes. Por lo general son responsables de permitir los procesos de establecer y
mantener conexiones entre servicios de software en mquinas posiblemente distantes. Quizs lo
ms importante, sirven de puente entre las necesidades de muchas aplicaciones de capas superiores
de enviar datos de forma fiable sin tener que preocuparse por la correccin de errores, la prdida de
datos o la gestin de flujo, y la capa de red protocolos, que a menudo son poco fiables y no se ocupan
de los acuses de recibo. Los protocolos de capa de transporte estn a menudo estrechamente
vinculados a los protocolos de capa de red directamente debajo de ellos, y son diseados
especficamente para atender funciones de las que estos ltimos no se ocupan.
En esta seccin describiremos protocolos de capa de transporte y las tecnologas conexas utilizadas
en el protocolo TCP / IP Hay dos protocolos principales de esta capa, el Protocolo de Control de
Transmisin (Transmission Control Protocol TCP) y el Protocolo de datagramas de usuario (User
Datagram Protocol UDP). Tambin se discute cmo en la capa de transporte se realiza una clase de
direccionamiento en TCP / IP en forma de puertos y sockets.

Nota: Puede parecer extrao que aqu solo haya una subseccin, la que cubre TCP y
UDP. Este es un resultado del hecho de que la gua de TCP / IP es un extracto de una
referencia de redes ms grandes.
Protocolo de Control de Transmisin (TCP) y el Protocolo de datagramas de usuario
(UDP)
TCP / IP es el conjunto de protocolos de interconexin ms importantes del mundo, es la base para
el Internet, y el "lenguaje" hablado por la gran mayora de los ordenadores conectados en red del
mundo. TCP / IP incluye un gran conjunto de protocolos que operan en la capa de red y por encima.
La suite en su conjunto est anclada a la capa tres en el Protocolo de Internet (IP), el que muchas
personas consideran el protocolo ms importante en el mundo de las redes.
Por supuesto, hay una cierta distancia arquitectnica entre la capa de red y las aplicaciones que se
ejecutan en las capas por encima. A pesar de que IP es el protocolo que lleva a cabo la mayor parte
de las funciones necesarias para realizar una interconexin de redes, este no incluye muchas
capacidades que son requeridas por las aplicaciones. En TCP / IP estas tareas son realizadas por un
par de protocolos que operan en la capa de transporte: el Protocolo de Control de Transmisin
(Transmission Control Protocol TCP) y el Protocolo de datagramas de usuario (User Datagram
Protocol UDP).
De estos dos, TCP recibe, con mucho, la mayor atencin. Es el protocolo de capa de transporte que
se asocia ms con TCP / IP, y, bueno, su nombre est ah, "iluminado". Tambin es el protocolo de
transporte utilizado por muchas de las aplicaciones ms populares de Internet, mientras que UDP
va segundo en la facturacin. Sin embargo, TCP y UDP son realmente pares que juegan el mismo
papel en TCP / IP. Funcionan de manera muy diferente y ofrecen diferentes ventajas y desventajas a
las aplicaciones que los utilizan, lo que los hace importantes a ambos para la suite de protocolos
como un todo. Los dos protocolos tambin tienen ciertas reas de similitud, lo que hace que sea ms
eficiente describirlos a ambos en la misma subseccin, destacando su caractersticas y mtodos de
operacin compartidos, as como en los que divergen.
En esta seccin proporciono un examen detallado de los dos protocolos de la capa de transporte
TCP/IP: El Protocolo de Control de Transmisin (TCP) y el Protocolo de datagramas de usuario
(UDP). Empiezo con una breve descripcin de la funcin de estos dos protocolos en el conjunto de
protocolos TCP / IP, y una discusin sobre por qu son importantes. Describo el mtodo que
emplean los protocolos para el direccionamiento, y el uso de puertos y sockets en la capa de
transporte. Luego tenemos dos secciones detalladas para cada uno de ellos UDP y TCP. Concluyo
con un resumen rpido y una comparacin de ambos.
Incidentalmente, he descrito UDP antes que TCP por una sencilla razn: es ms simple. UDP opera
ms como un protocolo clsico basado en mensajes, y de hecho, es ms similar a IP en s de lo que
es TCP. Esta es la misma razn por la que la seccin en TCP es mucho mayor que la que cubre UDP:
TCP es mucho ms complejo y hace mucho ms que UDP.
Generalidades y rol general de TCP y UDP en la pila TCP / IP.
La capa de transporte en una suite de protocolos es responsable de un conjunto especfico de
funciones. Por esta razn, se podra esperar que la suite TCP / IP tuviera un nico protocolo de
transporte que llevara a cabo esas funciones, as como IP es el protocolo ncleo en la capa de red. Es
una curiosidad, entonces, que haya dos protocolos de capa de transporte diferentes ampliamente
utilizados en TCP / IP. Esta disposicin es probablemente uno de los mejores ejemplos del poder de
la disposicin de los protocolos en capas, y por tanto, un ejemplo de que vali la pena todo el tiempo
que pas aprendiendo a entender ese molesto modelo de referencia OSI.
Diferentes Requisitos de la capa de transporte de TCP / IP.
Vamos a empezar con una mirada hacia atrs en la capa tres. En mi visin general de las
caractersticas clave de funcionamiento del Protocolo de Internet, describ varias limitaciones

importantes de cmo funciona el protocolo IP. La ms importante de estas limitaciones es el hecho

de que el protocolo IP es un protocolo no orientado a conexin. Los datos se envan a travs de una
red IP sin antes establecer una conexin, utilizando un esquema del "mejor esfuerzo". Los
mensajes suelen llegar a donde tienen que ir, pero no hay garantas, y el remitente por lo general
ni siquiera sabe si los datos llegaron a su destino.
Estas caractersticas presentan problemas graves desde el punto de vista del software. Muchos, si no
la mayora, las aplicaciones tienen que ser capaces de contar con el hecho de que los datos que
envan llegarn a su destino sin prdidas o errores. Tambin requieren que la conexin entre dos
dispositivos sea gestionada de forma automtica, manejando apropiadamente cuando sea necesario
problemas como la congestin y control de flujo. A menos que se proporcione algn mecanismo
para esto en las capas ms bajas, cada aplicacin necesitara ocuparse de estos asuntos, lo que sera
una duplicacin de esfuerzo excesiva.
De hecho, se podra argumentar que el establecimiento de conexiones, el aseguramiento de la
fiabilidad y el manejo retransmisiones, buffering y flujo de datos son tan importantes que hubiera
sido mejor simplemente incluir estas habilidades directamente en el Protocolo de Internet IP.
Curiosamente, ese fue exactamente el caso en los primeros das de TCP / IP."En el principio" no era
ms que un solo protocolo llamado "TCP", que combinaba las funciones del Protocolo de Internet
con la fiabilidad y las caractersticas de gestin de sesiones que acabamos de mencionar.
Sin embargo, hay un gran problema con esto. El establecimiento de conexiones, el aseguramiento de
la confiabilidad, la gestin y el de control de flujo y los acuses de recibo y retransmisiones: todos
stos tienen un costo: el tiempo y ancho de banda. La construccin de todas estas capacidades en un
nico protocolo que abarque las capas tres y cuatro significara que todas las aplicaciones
percibiran no solo las ventajas de fiabilidad, sino tambin los costos. Mientras que esto estara bien
para muchas aplicaciones, hay otras que no necesitan tanto la fiabilidad, y "no pueden permitirse" la
sobrecarga necesaria para proporcionarla.

La solucin: dos protocolos de transporte muy diferentes.

La solucin a este problema era simple: dejar que la capa de red (IP) se encargara del movimiento
bsico de datos sobre una interconexin de redes, y definir dos protocolos en la capa de transporte.
Uno podra proporcionar un amplio conjunto de servicios para aquellas aplicaciones que necesiten
esa funcionalidad, en el entendimiento de que se requieren algunos gastos para lograrlo. El otro
sera simple, proporcionando pocas funcionalidades desde la perspectiva clsica de las funciones de
capa cuatro, pero sera rpido y fcil de usar. De ah el resultado de dos protocolos de capa de
transporte en TCP/IP:
Protocolo de Control de Transmisin (TCP): Un protocolo de transporte fiable
orientado a conexin y con todas las funciones para las aplicaciones TCP / IP. TCP provee
direccionamiento de capa de transporte al permitir que mltiples aplicaciones de software utilicen
simultneamente una nica direccin IP. Permite que un par de dispositivos establezcan una
conexin virtual y, a continuacin intercambien datos bidireccionalmente. Las transmisiones se
gestionan mediante un sistema especial de ventana deslizante, con deteccin y el reenvo
automtico de las transmisiones no reconocidas. La funcionalidad adicional permite manejar el
flujo de datos entre dispositivos y resolver las circunstancias especiales.
Protocolo de datagramas de usuario (UDP): Un protocolo de transporte muy simple
que proporciona direccionamiento a nivel de capa de transporte como TCP, pero no mucho mas que
eso. UDP es poco ms que un protocolo "contenedor" (wrapper) que provee un medio para que las
aplicaciones accedan al protocolo IP. No est orientado a conexin, las transmisiones no son fiables,
y los datos se pueden perder.
Para emplear una analoga, TCP es un sedn de alto rendimiento totalmente de lujo con chfer
seguimiento por satlite y sistemas sistema de navegacin. Ofrece un montn de lujos, un buen
rendimiento y confort. Esto prcticamente garantiza que usted va a llegar a donde tiene que ir sin
ningn problema, y cualquier inquietud que surja se podr corregir. Por el contrario, UDP es un
coche de carreras bsico. Su objetivo es la simplicidad y la velocidad, la velocidad, la velocidad, todo

lo dems es secundario. Probablemente llegues a donde necesitas ir, pero bueno, los coches de
carreras puede ser fastidiosos de operar.

Concepto clave: Para adaptarse a las diferentes necesidades de transporte de las

muchas aplicaciones TCP / IP, existen dos protocolos en la capa de transporte TCP / IP.
El Protocolo de Control de Transmisin (TCP) es un protocolo con todas las funciones,
orientado a conexin que proporciona la entrega segura de los datos, mientras gestiona
del flujo de trfico y maneja problemas como la congestin y la prdida de transmisin.
El protocolo de datagramas de usuario (UDP), en contraste, es un protocolo mucho ms
sencillo que se concentra solamente en la entrega de datos, para maximizar la velocidad
de la comunicacin cuando no se requieren las caractersticas de TCP.
Generalidades y rol general de TCP y UDP en la pila TCP / IP.
Aplicaciones de TCP y UDP.

Tener dos protocolos de capa de transporte con fortalezas y debilidades complementarias

proporciona una gran flexibilidad a los creadores de software de red:
Aplicaciones TCP: La mayora de las aplicaciones "tpicas" necesitan la fiabilidad y otros
servicios prestados por TCP, y no se preocupan por la prdida de una pequea cantidad de
prestaciones a la sobrecarga. Por ejemplo, la mayora de las aplicaciones que transfieren archivos
importantes o datos entre mquinas utilizan TCP, ya que la prdida de cualquier parte del archivo
inutiliza totalmente la aplicacin. Los ejemplos incluyen aplicaciones conocidas como el Protocolo
de transferencia de hipertexto (Hypertext Transfer Protocol HTTP) utilizado por la World Wide
Web (WWW), el protocolo de transferencia de archivos (File Transfer Protocol FTP) y el Protocolo
simple de transferencia de correo (Simple Mail Transfer Protocol SMTP). Describo las aplicaciones
TCP con ms detalle en la seccin TCP.
Aplicaciones UDP: Estoy seguro de que usted est pensando: "a qu tipo de aplicacin
no le importa si sus datos llegan o no, y por qu iba yo a querer usarla?" Puede que se sorprenda:
UDP es utilizado por una gran cantidad de protocolos TCP / IP. UDP es un buen partido para su
aplicacin en dos circunstancias. La primera es cuando la aplicacin no le importa si algunos de los
datos se pierde, el streaming de vdeo o multimedia es un buen ejemplo, ya que si pierde algunos
bytes de datos ni siquiera se dar cuenta. La otra es cuando la propia aplicacin elige proporcionar
algn otro mecanismo para compensar la falta de funcionalidad en UDP. Las aplicaciones que
envan pequeas cantidades de datos, por ejemplo, a menudo utilizan UDP en el supuesto de que si
se enva una peticin y una respuesta no es recibida, el cliente slo enviar una nueva solicitud
despus. Esto proporciona suficiente fiabilidad sin la sobrecarga aadida de una conexin
TCP.Discuto algunas aplicaciones UDP comunes en la seccin UDP.

Concepto clave: La mayora de las aplicaciones clsicas, especialmente las que envan
mensajes o archivos, requieren que los datos se entregan de manera fiable, y por lo
tanto utilizan TCP para el transporte. Las aplicaciones que utilizan UDP son por lo
general aquellas en las que la prdida de una pequea cantidad de datos no es un
problema, o que utilizan sus propios procedimientos especficos para hacer frente a los
problemas potenciales de entrega que TCP maneja en general.
En las siguientes secciones vamos a examinar en primer lugar el esquema comn de
direccionamiento en la capa de transporte utilizado por TCP y UDP, y luego veremos cada uno de
los dos protocolos en detalle. A continuacin de estas secciones haremos una comparacin que le
ayudar a entender de un vistazo dnde estn las diferencias entre TCP y UDP. Por cierto, si quiere
un buen ejemplo del "mundo real" de por qu ambos protocolos son valiosos, considere el
transporte de mensajes bajo el Sistema de Nombres de Dominio (DNS), que en realidad utiliza UDP
para ciertos tipos de comunicacin y TCP para otros.

Antes de dejar el tema de la comparacin de UDP y TCP, quiero sealar explcitamente que a pesar
de que TCP se describe a menudo como ms lento que UDP, esta es una medida relativa. TCP es un
protocolo muy bien escrito que es capaz de ejecutar transferencias de datos de alta eficiencia. Slo
es lento en comparacin con UDP debido a la sobrecarga de crear y administrar las conexiones. La
diferencia puede ser importante, pero no es enorme, as que tenlo en cuenta.

Caractersticas del protocolo UDP

El protocolo UDP (Protocolo de datagrama de usuario) es un protocolo no orientado a
conexin de lacapa de transporte del modelo TCP/IP. Este protocolo es muy simple ya que no
proporciona deteccin de errores (no es un protocolo orientado a conexin).
Por lo tanto, el encabezado del segmento UDP es muy simple:

datos
(longitud variable).

Significado de los diferentes campos

Puerto de origen: es el nmero de puerto relacionado con la aplicacin del remitente

del segmento UDP. Este campo representa una direccin de respuesta para el destinatario.
Por lo tanto, este campo es opcional. Esto significa que si el puerto de origen no est
especificado, los 16 bits de este campo se pondrn en cero. En este caso, el destinatario
no podr responder (lo cual no es estrictamente necesario, en particular para mensajes
unidireccionales).

Puerto de destino: este campo contiene el puerto correspondiente a la aplicacin del

equipo receptor al que se enva.

Longitud: este campo especifica la longitud total del segmento, con el encabezado
incluido. Sin embargo, el encabezado tiene una longitud de 4 x 16 bits (que es 8 x 8 bits),
por lo tanto la longitud del campo es necesariamente superior o igual a 8 bytes.

Suma de comprobacin: es una suma de comprobacin realizada de manera tal que

permita controlar la integridad del segmento.

Protocolo TCP
US ES DE FR IT BR

Septiembre 2015

Las caractersticas del protocolo TCP

TCP (que significa Protocolo de Control de Transmisin) es uno de los principales protocolos
de la capa de transporte del modelo TCP/IP. En el nivel de aplicacin, posibilita la
administracin de datos que vienen del nivel ms bajo del modelo, o van hacia l, (es decir, el
protocolo IP). Cuando se proporcionan los datos al protocolo IP, los agrupa en datagramas IP,
fijando el campo del protocolo en 6 (para que sepa con anticipacin que el protocolo es TCP).
TCP es un protocolo orientado a conexin, es decir, que permite que dos mquinas que estn
comunicadas
controlen
el
estado
de
la
transmisin.
Las principales caractersticas del protocolo TCP son las siguientes:

TCP permite colocar los datagramas nuevamente en orden cuando vienen del
protocolo IP.
TCP permite que el monitoreo del flujo de los datos y as evita la saturacin de la red.

TCP permite que los datos se formen en segmentos de longitud variada para
"entregarlos" al protocolo IP.

TCP permite multiplexar los datos, es decir, que la informacin que viene de diferentes
fuentes (por ejemplo, aplicaciones) en la misma lnea pueda circular simultneamente.

Por ltimo, TCP permite comenzar y finalizar la comunicacin amablemente.

El objetivo de TCP
Con el uso del protocolo TCP, las aplicaciones pueden comunicarse en forma segura (gracias
al sistema de acuse de recibo del protocolo TCP) independientemente de las capas inferiores.
Esto significa que los routers (que funcionan en la capa de Internet) slo tienen que enviar los
datos en forma de datagramas, sin preocuparse con el monitoreo de datos porque esta
funcin la cumple la capa de transporte (o ms especficamente el protocolo TCP).
Durante una comunicacin usando el protocolo TCP, las dos mquinas deben establecer una
conexin. La mquina emisora (la que solicita la conexin) se llama cliente, y la mquina
receptora se llama servidor. Por eso es que decimos que estamos en un entorno ClienteServidor.
Las mquinas de dicho entorno se comunican en modo en lnea, es decir, que la
comunicacin se realiza en ambas direcciones.

Para posibilitar la comunicacin y que funcionen bien todos los controles que la acompaan,
los datos se agrupan; es decir, que se agrega un encabezado a los paquetes de datos que
permitirn sincronizar las transmisiones y garantizar su recepcin.
Otra funcin del TCP es la capacidad de controlar la velocidad de los datos usando su
capacidad para emitir mensajes de tamao variable. Estos mensajes se llaman segmentos.

La funcin multiplexin
TCP posibilita la realizacin de una tarea importante: multiplexar/demultiplexar; es decir
transmitir datos desde diversas aplicaciones en la misma lnea o, en otras palabras, ordenar la
informacin que llega en paralelo.

Estas operaciones se realizan empleando el concepto de puertos (o conexiones), es decir, un

nmero vinculado a un tipo de aplicacin que, cuando se combina con una direccin de IP,
permite determinar en forma exclusiva una aplicacin que se ejecuta en una mquina
determinada.

El formato de los datos en TCP

Un segmento TCP est formado de la siguiente manera:
<td
URG <td
ACK <td
PSH <td
RST <td
SYN <td
FIN</td
</td
</td
</td

</td
</td

01234567891 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Puerto de origen

Puerto de destino
Nmero de secuencia
Nmero de acuse de recibo

Marge Reservado
n
de
datos

Ventana

Suma de control

Puntero urgente

Opciones

Relleno
Datos

Significado de los diferentes campos:

Puerto de origen (16 bits): Puerto relacionado con la aplicacin en curso en la

mquina origen

Puerto de destino (16 bits): Puerto relacionado con la aplicacin en curso en la

mquina destino

Nmero de secuencia (32 bits): Cuando el indicador SYN est fijado en 0, el nmero
de secuencia es el de la primera palabra del segmento actual.
Cuando SYN est fijado en 1, el nmero de secuencia es igual al nmero de secuencia
inicial utilizado para sincronizar los nmeros de secuencia (ISN).

Nmero de acuse de recibo (32 bits): El nmero de acuse de recibo, tambin

llamado nmero de descargo se relaciona con el nmero (secuencia) del ltimo segmento
esperado y no el nmero del ltimo segmento recibido.

Margen de datos (4 bits): Esto permite ubicar el inicio de los datos en el paquete.
Aqu, el margen es fundamental porque el campo opcin es de tamao variable.

Reservado (6 bits): Un campo que actualmente no est en uso pero se proporciona

para el uso futuro.

Indicadores (6x1 bit): Los indicadores representan informacin adicional:

URG: Si este indicador est fijado en 1, el paquete se debe procesar en
forma urgente.
ACK: Si este indicador est fijado en 1, el paquete es un acuse de recibo.

PSH (PUSH): Si este indicador est fijado en 1, el paquete opera de

acuerdo con el mtodo PUSH.

RST: Si este indicador est fijado en 1, se restablece la conexin.

SYN: El indicador SYN de TCP indica un pedido para establecer una
conexin.

FIN: Si este indicador est fijado en 1, se interrumpe la conexin.

Ventana (16 bits): Campo que permite saber la cantidad de bytes que el receptor
desea recibir sin acuse de recibo.

Suma de control (CRC): La suma de control se realiza tomando la suma del campo
de datos del encabezado para poder verificar la integridad del encabezado.

Puntero urgente (16 bits): Indica el nmero de secuencia despus del cual la
informacin se torna urgente.

Opciones (tamao variable): Diversas opciones

Relleno: Espacio restante despus de que las opciones se rellenan con ceros para
tener una longitud que sea mltiplo de 32 bits.

Confiabilidad de las transferencias

El protocolo TCP permite garantizar la transferencia de datos confiable, a pesar de que usa el
protocolo IP, que no incluye ningn monitoreo de la entrega de datagramas.
De hecho, el protocolo TCP tiene un sistema de acuse de recibo que permite al cliente y al
servidor
garantizar
la
recepcin
mutua
de
datos.
Cuando se emite un segmento, se lo vincula a un nmero de secuencia. Con la recepcin de
un segmento de datos, la mquina receptora devolver un segmento de datos donde el
indicador ACK est fijado en 1 (para poder indicar que es un acuse de recibo) acompaado
por un nmero de acuse de recibo que equivale al nmero de secuencia anterior.

Adems, usando un temporizador que comienza con la recepcin del segmento en el nivel de
la mquina originadora, el segmento se reenva cuando ha transcurrido el tiempo permitido, ya
que en este caso la mquina originadora considera que el segmento est perdido.

Sin embargo, si el segmento no est perdido y llega a destino, la mquina receptora lo sabr,
gracias al nmero de secuencia, que es un duplicado, y slo retendr el ltimo segmento que
lleg a destino.

Cmo establecer una conexin

Considerando que este proceso de comunicacin, que se produce con la transmisin y el
acuse de recibo de datos, se basa en un nmero de secuencia, las mquinas originadora y
receptora (cliente y servidor) deben conocer el nmero de secuencia inicial de la otra
mquina.
La conexin establecida entre las dos aplicaciones a menudo se realiza siguiendo el siguiente
esquema:

Los puertos TCP deben estar abiertos.

La aplicacin en el servidor es pasiva, es decir, que la aplicacin escucha y espera

una conexin.
La aplicacin del cliente realiza un pedido de conexin al servidor en el lugar donde la
aplicacin es abierta pasiva. La aplicacin del cliente se considera "abierta activa".

Las dos mquinas deben sincronizar sus secuencias usando un mecanismo comnmente
llamadonegociacin en tres pasos que tambin se encuentra durante el cierre de la sesin.
Este dilogo posibilita el inicio de la comunicacin porque se realiza en tres etapas, como su
nombre lo indica:

En la primera etapa, la mquina originadora (el cliente) transmite un segmento donde

el indicador SYN est fijado en 1 (para indicar que es un segmento de sincronizacin), con
nmero de secuencia N llamado nmero de secuencia inicial del cliente.

En la segunda etapa, la mquina receptora (el servidor) recibe el segmento inicial que
viene del cliente y luego le enva un acuse de recibo, que es un segmento en el que el
indicador ACK est fijado en 1 y el indicador SYN est fijado en 1 (porque es nuevamente
una sincronizacin). Este segmento incluye el nmero de secuencia de esta mquina (el
servidor), que es el nmero de secuencia inicial para el cliente. El campo ms importante

en este segmento es el de acuse de recibo que contiene el nmero de secuencia inicial del
cliente incrementado en 1.

Por ltimo, el cliente transmite un acuse de recibo, que es un segmento en el que el

indicador ACK est fijado en 1 y el indicador SYN est fijado en 0 (ya no es un segmento
de sincronizacin). Su nmero de secuencia est incrementado y el acuse de recibo
representa el nmero de secuencia inicial del servidor incrementado en 1.

Despus de esta secuencia con tres intercambios, las dos mquinas estn sincronizadas y la
comunicacin puede comenzar.
Existe una tcnica de piratera llamada falsificacin de IP, que permite corromper este enlace
de aprobacin con fines maliciosos.

Mtodo de ventana corrediza

En muchos casos, es posible limitar la cantidad de acuses de recibo con el fin de aliviar el
trfico en la red. Esto se logra fijando un nmero de secuencia despus del cual se requiera
un acuse de recibo. Este nmero en realidad se guarda en el campo ventana del encabezado
TCP/IP.
Este mtodo se llama efectivamente el "el mtodo de la ventana corrediza" porque, en cierta
medida, se define una serie de secuencias que no necesitan acuses de recibo y que se
desplaza a medida que se reciben los acuses de recibo.

Adems, el tamao de esta ventana no es fijo. De hecho, el servidor puede incluir el tamao
de la ventana que considera ms apropiado en sus acuses de recibo guardndolo en el
campo ventana. De este modo, cuando el acuse de recibo indica un pedido para aumentar la
ventana, el cliente se desplazar al borde derecho de la ventana.

Por el contrario, en el caso de una reduccin, el cliente no desplazar el borde derecho de la

ventana hacia la izquierda sino que esperar que avance el borde izquierdo (al llegar los
acuses de recibo).

Cmo terminar una conexin

El cliente puede pedir que se termine una conexin del mismo modo que el servidor.
Para terminar una conexin se procede de la siguiente manera:

Una de las mquinas enva un segmento con el indicador FIN fijado en 1, y la

aplicacin se autocoloca en estado de espera, es decir que deja de recibir el segmento
actual e ignora los siguientes.
Despus de recibir este segmento, la otra mquina enva un acuse de recibo con el
indicadorFIN fijado en 1 y sigue enviando los segmentos en curso. Despus de esto, la
mquina informa a la aplicacin que se ha recibido un segmento FIN y luego enva un
segmento FIN a la otra mquina, que cierra la conexin.

Protocolo UDP El protocolo User Datagram Protocol (UDP) proporciona un

servicio de entrega de datagramas sin conexion y no confiable, utilizando el
protocolo IP como el protocolo subyacente. Proporciona puertos para distinguir
entre las aplicaciones, de un mismo anfitrion: cada mensaje contiene el nume
ro de puerto destino, as como el de origen. Un programa de aplicacion que
utiliza UDP debe responsabilizarse por los problemas en la comunicacion: p
erdida, retraso, duplicacion y desorden en la entrega de datagramas. El
formato de la cabecera UDP se muestra en la figura 1.8. La cabecera es muy
simple solo consta de la direccion de los puertos UDP de origen y destino, la
longitud del mensaje UDP y una suma de verificacion que es opcional. Si la
aplicacion decide utilizar la suma de verificacion se debe utilizar una pseudo
cabecera, figura 1.9, para realizar el calculo de la misma. La pseudo cabecera
se usa solo para calcular la suma de verificacion, no se incluye al enviar el
mensaje. Esta incluye las 1.9 Protocolo TCP 17 direccin IP destino 0 cero
protocolo 15 16 31 longitud UDP direccin IP origen Figura 1.9: Pseudo

cabecera UDP direcciones IP del origen y del destino, el numero de protocolo y

la longitud del datagrama UDP sin incluir la longitud de la misma pseudo
cabecera. El nume ro asignado al protocolo UDP es 0x11, y es usado tanto en
la pseudo cabecera UDP como en la cabecera IP. En este trabajo el protocolo
UDP se usa junto con las extensiones multidifusion para transmitir los datos
de las lecturas de los sensores inalambricos a traves de internet. Vease el
captulo 5. 1.9. Protocolo TCP El Transmission Control Protocol (TCP), es un
protocolo orientado a conexion, con- fiable de extremo a extremo y disenado
para encajar en una jerarqua de protocolos que soporten mult iples
aplicaciones de red. Provee una comunicacion confiable entre procesos de
anfitriones en redes distintas pero interconectadas entre s. TCP asume muy
poco sobre la confiabilidad de los protocolos de niveles inferiores. De hecho
con obtener un datagrama de las capas inferiores es suficiente. TCP es capaz
de transferir un flujo continuo de bytes en cada direccion entre sus usuarios,
empaquetando el flujo en segmentos de un tamano apropiado para su
transmision. El tamano de los segmentos esta limitado por la unidad m
axima de transmision de la capa de acceso a la red, que en el caso de
ethernet es de 1500 bytes. Los paquetes resultantes se pasan al protocolo IP
para su entrega a traves de internet. Para asegurar que los paquetes no se
pierdan en el camino, y evitar que lleguen en desorden, TCP le asigna a cada
paquete un numero de secuencia. El receptor puede con este numero
reacomodar los segmentos y reconstruir el flujo. En un momento dado el
receptor tendra cero o mas bytes reconstruidos desde el inicio del flujo. Por
los bytes bien recibidos, el receptor enva un acuse de recibo especificando el
nume ro de secuencia del siguiente byte que espera recibir. Cada vez que se
enva un segmento, el TCP inicia un temporizador y espera un acuse de recibo.
Si se termina el tiempo antes de que se acusen de recibidos los datos del
segmento, el TCP asume que el segmento se perdio o se corrompio y lo
retransmite. El TCP provee al receptor de una forma de gobernar la cantidad de
datos que enva el emisor. Esto lo hace mediante el uso de la ventana
deslizable. Supongase que un anfitrion tiene lista una secuencia de paquetes
para transmitir y que el receptor de los mismo le ha anunciado una ventana de
8 paquetes. Esto significa que el anfitrion enviara hasta 8 paquetes y
esperara un acuse de recibo por todos. La ventana indica la cantidad aceptable
de bytes que el emisor puede transmitir sin esperar un acuse de recibo. Este
concepto hace que la transmision de flujo sea eficiente. Si TCP utilizase un
esquema simple de acuse de recibo positivo, (una ventana de 1 paquete)
ocupara un gran ancho de banda de red, debido a que retrasara el envo de
un nuevo paquete hasta que reciba un acuse del paquete anterior. 18 Captulo
1: Introduccion a TCP/IP protocolo 0 cero 15 16 31 longitud TCP direccin IP
destino direccin IP origen Figura 1.10: Pseudo cabecera TCP Los acuses de
recibo, ACKs, no se generan inmediatamente despues de recibir un segmento
debido al algoritmo de los ACKs retrasados. Este algoritmo retarda el envo
del ACK durante un tiempo, alrededor de 300 ms1. Este retraso, aunque a
primera vista parezca un tope maximo de la velocidad de transferencia, es en
realidad una optimizacion que permite reducir el trafico y mejorar el
desempeno. Por ejemplo si durante la espera se reciben nuevos datos, con un

solo ACK se pueden reconocer todos los datos recibidos. Una desventaja de los
ACKs retrasados es que si el receptor tarda mucho en enviar un ACK, el emisor
podra retransmitir el segmento y con ello generar mas trafico del necesario.
Los datos recibidos en el receptor se almacenan en un bufer de memoria y son
pasados al protocolo de mayor nivel (la aplicacion) cuando el emisor emplea
la funcion push. Esta funcion obliga al modulo TCP a entregar los datos
inmediatamente a la aplicacion. La funcion garantiza que los datos se
transferiran, pero no garantiza una frontera. Por ello las aplicaciones deben
estar de acuerdo en un formato antes de iniciar una conexion. La abstraccion
fundamental de TCP es la conexion y no el puerto de protocolo. Las
conexiones se identifican por medio de un par de puntos extremos. Un punto
extremo es un par de numeros enteros (anfitrion, puerto), en donde anfitrion
es la direccion IP de un anfitrion y puerto es el puerto TCP en dicho anfitrion.
Por ejemplo el punto extremo (192.168.1.150,80) se refiere al puerto 80 en la
maquina con direccion IP 192.168.1.150. Como el TCP identifica una conexi
on por el par de puntos extremos, varias conexiones en la misma maquina
pueden compartir un numero de puerto TCP. Las conexiones proporcionadas
por TCP se conocen como full duplex. Desde el punto de vista de un proceso de
aplicacion, una conexion full duplex consiste en dos flujos independientes
que se mueven en direcciones opuestas, sin ninguna interaccion aparente. La
ventaja de una conexion full duplex es que el software subyacente de
protocolo puede enviar en los datagramas informacion de control al origen,
llevando datos en la direccion opuesta. Este procedimiento reduce el trafico
en la red. Otra caracterstica de TCP es que provee los medios para
comunicarle al receptor de los datos que en algun punto mas lejano en el
flujo de datos que el receptor este leyendo, hay datos urgentes. El TCP no
define lo que el usuario debe hacer al ser notificado de que hay datos urgentes
pendientes, la nocion general es que el receptor debe tomar las acciones
necesarias para procesar los datos urgentes lo mas rapido posible. La
cabecera de TCP se muestra en la figura 1.11. A diferencia de UDP, el calculo
de la suma de verificacion es obligatoria en TCP, y al semejanza de TCP tambi
en se utiliza una pseudo cabecera, figura 1.10, para realizar el calculo del
checksum. La pseudo cabecera contiene las direcciones IP del emisor y
receptor, el numero de protocolo, y la longitud de la cabecera TCP mas los
datos (sin contar la longitud de la pseudo cabecera). 1Este tiempo es solo una
aproximacion y su valor real se calcula de acuerdo al trafico que detecta el
receptor de los segmentos 1.9 Protocolo TCP 19 banderas nmero de secuencia
puerto destino ventana checksum puntero urgente offset reservado opciones 0
15 16 31 puerto origen acuse de recibo Puerto origen (16 bits). El puerto de
origen. Puerto destino (16 bits). El puerto de destino. Numero de secuencia
(32 bits). El numero de secuencia del primer byte de datos en este segmento
(excepto cuando la bandera SYN esta presente). Si la bandera SYN esta
presente el numero de secuencia corresponde al numero de secuencia inicial
(ISN), y el primer byte de datos tiene la secuencia ISN+1. Acuse de recibo (32
bits). Si la bandera ACK esta presente, este campo contiene el siguiente valor
de numero de secuencia que el emisor del segmento espera recibir. Una vez
que la conexion esta establecida, siempre se enva. Offset de datos (4 bits)

El numero de palabras de 32 bits de la cabecera. Indica en donde comienzan

los datos. La longitud de la cabecera TCP, aun con opciones incluidas, siempre
es un multiplo de 32 bits. Reservado (6 bits). Reservado para uso futuro. Debe
valer cero. Banderas (6 bits). Cuando estas banderas estan verificadas, su
significado es el siguiente: URG: el campo del puntero urgente tiene
significado. ACK: el campo del acuse de recibo tiene significado. PSH: Efectuar
la funcion push. RST: Reajustar la conexion. SYN: Sincronizar los nume ros
de secuencia. FIN: El emisor no enviara mas datos. Ventana (16 bits). El
nume ro de bytes de datos, comenzado con el segmento indicado en el
campo de acuse, que el emisor de este segmento puede aceptar. Checksum
(16 bits). La suma de verificacion del segmento TCP. Puntero urgente (16 bits).
Este campo indica el valor actual del puntero urgente como un offset positivo
desde el numero de secuencia en este segmento. El puntero senala al nu
mero de secuencia del siguiente byte de los datos urgentes. Opciones
(longitud variable). Las opciones pueden ocupar espacio al final de la cabecera
TCP y su longitud es un multi plo de 8 bits. Todas las opciones se incluyen al
calcular la suma de verificacion. Figura 1.11: Formato de la cabecera TCP 20
Captulo 1: Introduccion a TCP/IP El algoritmo de la suma de verificacion es
el mismo que para la cabecera IP. Se calcula utilizando el valor 0x0000 en el
campo de checksum y comenzando en la pseudo cabecera hasta el ultimo
byte de datos. En la cabecera se aprecia un campo de opciones. El TCP define
varios parametros opcionales que se pueden incluir en la cabecera, si la
aplicacion requiere hacer uso de ellas. Una de las opciones mas importante
es el tamano maximo de segmento MSS, la cual ocupa 16 bits. Si esta opci
on esta presente, indica el tamano maximo de segmento que puede recibir
el emisor del mismo. Este campo solo se enva al establecer la conexion. Si
no esta presente, entonces se asume que el MSS es 536 bytes. Finalmente
cabe mencionar que el nume ro de protocolo que se usa en la cabecera IP
para encapsular al protocolo TCP es 0x06. 1.9.1. Etapas de una conexion TCP
En terminos generales una conexion TCP atraviesa por tres etapas:
establecimiento de la conexion, transferencia de datos y cierre de la conexi
on. Establecimiento de la conexion Para establecer una conexion, el TCP
utiliza un saludo de 3 etapas (3-way handshake). El procedimiento es iniciado,
normalmente, por un punto extremo y contestado por otro. El caso mas
sencillo se muestra en la figura 1.12. Establecido Recepcin de SYN Establecido
Envo de SYN Establecido Establecido A B Figura 1.12: Saludo basico de 3
etapas de TCP El primer segmento del saludo se identifica porque esta
verificada la bandera SYN. El segundo mensaje tiene verificados las banderas
SYN y ACK, indicando el acuse del primer segmento como el hecho de que se
continua con el saludo. El ultimo segmento del saludo es solo un acuse de
recibo y se usa para indicar que ambos extremos estan de acuerdo en
establecer la conexion. El saludo realiza dos funciones importantes: garantiza
que ambos lados esten listos para transferir datos y permite a las partes
acordar el ISN. Cada extremo selecciona un ISN aleatorio. En la figura 1.12, el
extremo A escogio el ISN=100, mientras que B escogio ISN=300. El ISN no
puede comenzar siempre con el mismo valor, en el documento RFC1122 [8] se
sugiere escoger el ISN basado en la lectura del reloj de la maquina. Ademas

de ponerse de acuerdo en el ISN, ambos extremos anuncian su MSS. 1.9

Protocolo TCP 21 Transferencia de datos Una vez que la conexion esta
establecida, la comunicacion se da por el intercambio de segmentos. Dado
que los segmentos se pueden perder por errores en la transmision o congesti
on de la red, el TCP hace retransmisiones (despues de un tiempo fuera) para
asegurar la entrega de cada segmento. Cada entidad mantiene un registro con
los numeros de secuencia que debe usar, y otro con los numeros de
secuencia que espera recibir. El cierre de la conexion implica una funcion
push y la llegada de un segmento con la bandera FIN verificada. Cierre de la
conexion En esta fase se usa un saludo de 4 etapas (4-way handshake), con
cada lado terminando independientemente. Cuando un extremo desea
terminar la conexion, enva un paquete con la bandera FIN verificada que el
otro extremo acusa de recibido enviando un segmento ACK. closed A B
finwait2 finwait1 timewait lastack closewait closed 2MSL Figura
1.13: Cierre de conexion basico de 4 etapas de TCP Por lo tanto, un cierre t
pico requiere un par de segmentos FIN y ACK desde cada extremo, como en
la figura 1.13. Una conexion puede estar medio abierta, este es el caso en
que un extremo ha cerrado pero el otro no. El lado que ha terminado no puede
enviar mas datos por la conexion, mientras que el otro si puede. Cabe
mencionar que las banderas SYN y FIN ocupan un lugar en el espacio de nu
mero de secuencia. Cuando estas banderas se transmiten el nume ro de
secuencia del emisor se incrementa en 1. 1.9.2. Maquina de estados TCP La
operacion de TCP se puede explicar mejor mediante el uso de una maquina
de estados. La figura 1.14 muestra la maquina de estados TCP, donde los
estados se muestran como un cuadrado redondeado y las transiciones como
flechas entre los estados. 22 Captulo 1: Introduccion a TCP/IP TCP/IP State
Transition Diagram (RFC793) Gordon McKinney (10 Feb 2004) A connection
progresses through a series of states during its lifetime (listed below). CLOSED
is fictional because it represents the state when there is no TCB, and therefore,
no connection. Briefly the meanings of the states are: LISTEN represents
waiting for a connection request from any remote TCP and port. SYN-SENT
represents waiting for a matching connection request after having sent a
connection request. SYN-RECEIVED represents waiting for a confirming
connection request acknowledgment after having both received and sent a
connection request. ESTABLISHED represents an open connection, data
received can be delivered to the user. The normal state for the data transfer
phase of the connection. FIN-WAIT-1 represents waiting for a connection
termination request from the remote TCP, or an acknowledgment of the
connection termination request previously sent. FIN-WAIT-2 represents waiting
for a connection termination request from the remote TCP. CLOSE-WAIT
represents waiting for a connection termination request from the local user.
CLOSING represents waiting for a connection termination request
acknowledgment from the remote TCP. LAST-ACK represents waiting for an
acknowledgment of the connection termination request previously sent to the
remote TCP (which includes an acknowledgment of its connection termination
request). TIME-WAIT represents waiting for enough time to pass to be sure the
remote TCP received the acknowledgment of its connection termination

request. CLOSED represents no connection state at all. A TCP connection

progresses from one state to another in response to events. The events are the
user calls, OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS; the incoming
segments, particularly those containing the SYN, ACK, RST and FIN flags; and
timeouts. CLOSED LISTEN SYN_RCVD SYN_SENT ESTABLISHED FIN_WAIT_1
CLOSE_WAIT FIN_WAIT_2 CLOSING TIME_WAIT LAST_ACK data transfer state
starting point 2MSL timeout passive open active open simultaneous close appl:
passive open send: appl: send: SYN active open appl: send: SYN send data
recv: SYN; send: SYN, ACK recv: RST timeout send: RST recv: SYN send: SYN,
ACK simultaneous open recv: SYN, ACK send: ACK appl: close send: FIN recv:
ACK send: recv: FIN send: ACK recv: ACK send: recv: FIN, ACK send: ACK recv:
ACK send: appl: close send: FIN recv: FIN send: ACK recv: FIN send: ACK appl:
close send: FIN appl: close or timeout recv: ACK send: active close passive
close normal transitions for client normal transitions for server appl: state
transitions taken when application issues operation recv: state transitions taken
when segment received send: what is sent for this transition TCP state
transition diagram. Reprinted from TCP/IP Illustrated, Volume 2: The
Implementation by Gary R. Wright and W. Richard Stevens, Copyright 1995
by Addison-Wesley Publishing Company, Inc. Figura 1.14: Diagrama de estados
de TCP Una conexion atraviesa por varios de los estados mostrados en la
figura 1.14, estos se describen a continuacion: LISTEN Representa la espera
de una solicitud conexion desde otro punto extremo. SYN-SENT Representa
esperar por una conexion despues de haber enviado la solicitud de conexi
on. SYN-RECEIVED Representa esperar el acuse de la confirmacion de conexi
on, despues de haber recibido y enviado la peticion de conexion. 1.10
Ethernet 23 ESTABLISHED Representa una conexion abierta, los datos se
pueden entregar al usuario. El estado normal para realizar conexiones. FINWAIT-1 Representa la espera de la solicitud de cierre de conexion del otro
punto extremo, o el acuse de la peticion de cierre enviada con anterioridad.
FIN-WAIT-2 Representa la espera por una solicitud de cierre del otro punto
extremo. CLOSE-WAIT Representa la espera por una solicitud de cierre de
usuario local. CLOSING Representa la espera el acuse de la solicitud de cierre
del otro punto extremo. LAST-ACK Representa la espera el acuse de la solicitud
de cierre enviada al otro punto extremo. TIME-WAIT Representa la espera de un
tiempo suficiente para asegurar que el otro punto extremo haya recibido el
acuse de la solicitud de cierre. CLOSED Representa un estado en el que no hay
conexion. 1.10. Ethernet En la capa de acceso a la red se encuentra Ethernet.
Ethernet (IEEE 802.3) es una especificacion de cableado y senalizacion para
redes de area local. Los nodos de la red se conectan entre s utilizando una
topologa en estrella o en bus. Las velocidades de transmision estandares
para ethernet son 10 Mbps, 100 Mbps, y 1 Gbps. En una red ethernet un nodo
se comunica con otros enviando paquetes, estos paquetes llegan a todos los
nodos de la red. En cada paquete se especifica el nodo destino utilizando una
direccion y solo el nodo que tiene la direccion indicada procesara el
paquete. Cada dispositivo conectado a una red ethernet se identifica con una
direccion de 6 bytes llamada direccion ethernet. La direccion ethernet tambi
en se conoce como direccion MAC (Media Access Control). La direccion esta

asignada por el fabricante del dispositivo y a su vez, el rango de direcciones

asignado a los fabricantes es controlado por la IEEE. Cuando una direccion
ethernet contiene todos sus bits en 1 se conoce como direccion broadcast. Un
paquete que tenga como destino la direccion broadcast sera procesado por
todos los nodos de la red. En una red ethernet solo un nodo transmite a la vez.
Si dos nodos transmiten al mismo tiempo se provoca una colision en donde los
paquetes se pierden. Ethernet utiliza el mecanismo de control Carrier Sense
Multiple Access with Collision Detection (CSMA/CD) para detectar colisiones y
recuperarse de las mismas. Cuando se detecta una colision se llevan a cabo
los siguientes pasos: 1. El nodo escucha el canal antes de transmitir para
determinar si otro nodo esta transmitiendo. 2. Cuando el nodo determina que
el canal esta libre comienza a transmitir el paquete. Si dos nodos detectan el
canal libre al mismo tiempo se provocara una colision. 3. Mientras el nodo est
a transmitiendo el paquete tambien esta escuchando si se produce una
colision. 24 Captulo 1: Introduccion a TCP/IP 4. Si se deteca una colision los
nodos involucrados dejan de transmitir. 5. Los nodos reintetaran la transmisi
on despues de un tiempo de espera logartmico. Este proceso se repite
hasta que se logra transmitir el paquete, en un maximo de 16 intentos, al
diecisieteavo intento se descarta el paquete. Existen dos tipos de formatos de
paquetes ethernet: Ethernet II y IEEE 802.3. Estos se muestran en las figuras
1.15 y 1.16 respectivamente. Para identificar el tipo de paquete utilizado en
una red, se lee la palabra formada por los bytes 13 y 14. Si esta es menor que
1500 el formato es 802.3 y si es mayor es Ethernet II. bytes: 6 6 2 461500 4
MAC destino MAC origen tipo datos CRC Figura 1.15: Formato de paquete
Ethernet II bytes: MAC destino MAC origen datos CRC control origen SAP
destino SAP longitud 6 6 2 1 1 1 431497 4 Figura 1.16: Formato de paquete
IEEE 802.3 En este trabajo se utilizo el formato Ethernet II, por ser el mas
utilizado. Partiendo de este formato, el tamano mnimo de un paquete es 64
bytes, en este se pueden transferir 48 bytes de datos. Si se requiere transferir
menos de 48 bytes, se agregan bytes de relleno hasta lograr 48. Por otra parte,
el tamano maximo de un paquete Ethernet II es de 1518 bytes, lo que
permite hasta 1500 bytes de datos. Finalmente, la unidad maxima de
transmision (MTU) es el numero maximo de datos que se pueden transmitir
en un solo paquete es de 1500 bytes para una red ethernet. Cabe mencionar
que al generar un paquete ethernet, la cola del mismo (el CRC) es generada
por el hardware controlador de ethernet y no por el software del sistema de c
omputo que genera el paquete