Está en la página 1de 8

Servicios Documentales en Red

Las capa de transporte en Internet

Tema 4: La capa de transporte en Internet.


4.1 Introduccin.
Como ya hemos comentado existen, bsicamente, dos protocolos de transporte
en Internet: TCP y UDP. TCP (Tranport Control Protocol) es un protocolo fiable,
orientado a conexin y con control de flujo, mientras que UDP (User Datagram
Protocol) es no fiable (sin confirmacin) no orientado a conexin y sin control de flujo.
La unidad de transferencia (Tranfer Protocol Data Unit) de TCP se denomina segmento,
mientras que la de UDP se denomina mensaje o tambin datagrama UDP.
TCP prev una comunicacin full dplex punto a punto entre dos ordenadores,
no hay soporte para trfico multicast, esto es, el envo de unos datos a un grupo de
ordenadores. En UDP la comunicacin es simplex (aunque obviamente un datagrama
UDP puede ser respondido por el receptor con otro); adems, en UDP es posible el
trfico multicast o broadcast. Como protocolo, TCP es mucho ms complejo que UDP.
4.2 Concepto de puerto en TCP/UDP.
El nivel de transporte debe ofrecer algn mecanismo que permita distinguir de
forma unvoca a que aplicacin van dirigidos los datos, este mecanismo se conoce con
el nombre de TSAP. En TCP/UDP los TSAPs son los denominados ports o puertos.
En sentido estricto una conexin entre dos entidades usuarias del nivel de
transporte queda identificada por los TSAPs en los que conectan cada una (podemos
pensar en el TSAP como el conector telefnico, diramos entonces que una
conversacin telefnica queda perfectamente especificada por los nmeros de telfono
de las dos rosetas donde estn enchufados los aparatos con los que se est hablando). Un
TSAP en Internet est especificado por:
Direccin donde conecta el nivel de red: direccin IP de los dos ordenadores.
Direccin donde conecta el nivel de transporte (campo protocolo del datagrama
IP): normalmente TCP (ya que UDP al ser no orientado a conexin no puede
establecer conexiones).
Direccin donde conecta el nivel de aplicacin: esto es el puerto.
Dado que la conexin en el nivel de transporte siempre se suele realizar con el
protocolo TCP este dato es innecesario y se suele omitir. Sin embargo en un mismo
ordenador un nmero de puerto puede ser utilizado simultneamente por una aplicacin
para UDP y por otra para TCP sin conflictos, ya que son TSAPs diferentes.
As pues, una conexin de dos entidades usuarias del nivel de transporte se
especifica por la combinacin:

_____________________________________________________________________________________
Biblioteconoma y Documentacin
43

Servicios Documentales en Red

Las capa de transporte en Internet

Direccin IP host 1 + port host 1 + direccin IP host 2 + port host 2


El puerto es un nmero entero entre 0 y 65535. Por convenio los nmeros 0 a
1023 estn reservados para el uso de servicios estndar, por lo que se les denomina
puertos bien conocidos o well-known ports. Cualquier nmero por encima de 1023
est disponible para ser utilizado libremente por los usuarios. Los valores de los puertos
bien conocidos se encuentran recogidos en el RFC Assigned Internet Numbers (en estos
momentos el RFC 1700). Algunos ejemplos aparecen en la siguiente tabla:
Puerto
9
19
20
21
23
25
110
119

Aplicacin
Descripcin
Discard
Descarta todos los datos recibidos (para pruebas)
Chargen
Intercambia cadenas de caracteres (para pruebas)
FTP-Data
Transferencia de datos FTP
FTP
Dilogo en transferencia FTP
TELNET
Acceso remoto
SMTP
Correo electrnico
POP3
Servidor de correo
TNP
News
Figura 4.2.1: Algunos ejemplos de puertos de TCP.

Por ejemplo, supongamos que cinco usuarios del ordenador de direccin IP


134.123.1.2 inician una sesin de conexin remota hacia el ordenador de direccin
221.198.34.21; cada uno de ellos ejecutar en su ordenador un programa cliente
(generalmente Telnet) que abrir una conexin con el otro; las conexiones establecidas
podran ser por ejemplo:
(134.123.1.2,1024) con (221.198.34.21,23)
(134.123.1.2,1025) con (221.198.34.21,23)
(134.123.1.2,1026) con (221.198.34.21,23)
(134.123.1.2,1030) con (221.198.34.21,23)
(134.123.1.2,1031) con (221.198.34.21,23)
Donde hemos empleado la notacin (direccin IP, puerto). Obsrvese que la
asignacin de puertos para los clientes se hace por simple orden de llegada a partir del
primer nmero de puerto no reservado. En el servidor todas las conexiones utilizan el
puerto 23 (pues todas acceden al mismo proceso, el servidor Telnet); en cambio en el
cliente cada usuario es un proceso diferente y utiliza un puerto distinto. La combinacin
(direccin IP, puerto) se denomina socket.
Complicando aun ms nuestro ejemplo anterior podramos imaginar que el
ordenador cliente estuviera multihomed, es decir que tuviera por ejemplo dos
interfaces fsicas, y por tanto tuviera dos direcciones IP; los usuarios podran utilizar
ambas interfaces alternativamente, por lo que las conexiones podran ser por ejemplo:
(134.123.1.2,1024) con (221.198.34.21,23)
(134.123.1.3,1024) con (221.198.34.21,23)
(134.123.1.2,1025) con (221.198.34.21,23)
(134.123.1.3,1025) con (221.198.34.21,23)
(134.123.1.2,1030) con (221.198.34.21,23)
_____________________________________________________________________________________
Biblioteconoma y Documentacin
44

Servicios Documentales en Red

Las capa de transporte en Internet

Por ltimo diremos que el ordenador cliente podra, de forma simultanea a las
sesiones Telnet abiertas, enviar datagramas UDP al ordenador B; aqu, aunque no se
establece una conexin (pues se trata de un servicio CLNS) hay un puerto de origen y
uno de destino; los datagramas podran tener como puerto de origen el 1024 y de
destino el 23; esto no causara ninguna ambigedad, ya que el campo protocolo del
datagrama IP diferenciara ambos tipos de paquetes, y los entregara al servicio
correspondiente en el nivel de transporte del receptor.
4.3 El protocolo TCP.
El intercambio de segmentos en TCP se desarrolla de acuerdo con un protocolo
de ventana deslizante del tipo que hemos visto, con un nmero de secuencia de 32 bits.
El nmero de secuencia cuenta los bytes transmitidos, por lo que la secuencia se reinicia
cada 4 GB transmitidos (equivalentes a 4,3 minutos en una lnea ATM de 155 Mbps,
suponiendo que toda la capacidad til de la lnea se utilizara para una esa conexin
TCP).
TCP utiliza ACK piggybacked, por lo que en el campo de cabecera de cada
segmento hay previstos dos campos de 32 bits, uno para el nmero de secuencia y otro
para el nmero de ACK. El campo nmero de secuencia indica el nme ro del primer
byte transmitido dentro de ese segmento. El campo ACK indica el nmero del primer
byte que se espera recibir en el siguiente segmento (o sea, el siguiente byte que se
espera recibir, siguiendo el estilo del campo 'next' en HDLC). En la prctica el ACK
piggybacked no se aprovecha casi nunca ya que la mayora de las aplicaciones estn
diseadas de forma que la informacin se enva de forma asimtrica; normalmente es
necesario que el TCP receptor enve peridicamente segmentos vacos con el nico fin
de informar al emisor que los datos han sido recibidos.
El mecanismo normal de funcionamiento de TCP es retroceso n, aunque tambin
puede utilizarse repeticin selectiva si las dos entidades participantes lo soportan.
El tamao de ventana es variable y depende como ya hemos visto del espacio de
buffers disponible en el receptor. En la cabecera normal de TCP el campo previsto es de
16 bits, dando as un tamao de ventana mximo de 64KBytes.
La cabecera de un segmento TCP tiene la siguiente estructura:
0

10

16

31

Puerto TCP origen

Puerto TCP destino


Nmero de secuencia
Nmero de reconocimiento

long c

Reservado

Cdigo

Suma de comprobacin

Tamao de ventana
Puntero de datos urgentes

Opciones TCP (0 o ms palabras)


Datos (opcional)

Figura 4.3.1: Estructura del Segmento TCP.


_____________________________________________________________________________________
Biblioteconoma y Documentacin
45

Servicios Documentales en Red

Las capa de transporte en Internet

Puerto origen y puerto destino identifican los puertos que se van a utilizar en
cada ordenador para comunicar con las aplicaciones que intercambian datos.
Nmero de secuencia indica el nmero de secuencia que corresponde en la
conexin al primer byte que se enva en el campo datos.
Nmero de ACK indica el nmero de secuencia del prximo segmento que se
espera recibir del otro lado.
Longitud de cabecera TCP especifica la longitud en palabras de 32 bits, excluido
el campo datos (el campo opciones hace que dicha longitud pueda variar).
A continuacin hay 6 bits no utilizados, seguidos por seis indicadores o cdigos
de un bit cada uno:
URG (urgent): sirve para indicar que el segmento contiene datos urgentes; en ese
caso el campo puntero de datos urgentes contiene la direccin donde terminan
stos.
ACK (acknowledgement): indica que en este segmento el campo Nmero de
ACK contiene el nmero del prximo byte que se espera recibir. En la prctica
el bit ACK esta a 1 siempre, excepto en el primer segmento enviado por el host
que inicia la conexin.
PSH (push): indica que el segmento contiene datos PUSHed, es decir, que deben
ser enviados rpidamente a la aplicacin correspondiente, sin esperar a acumular
varios segmentos.
RST (reset): se usa para indicar que se ha detectado un error de cualquier tipo;
por ejemplo una terminacin unilateral de una conexin o que se ha recibido un
segmento con un valor inadecuado del nmero de secuencia o nmero de ACK.
SYN (synchronize): est puesto slo en el primer mensaje enviado por cada lado
en el inicio de la conexin.
FIN (finish): indica que no se tienen ms datos que enviar y que se quiere cerrar
la conexin. Para que una conexin se cierre de manera normal cada host ha de
enviar un segmento con el bit FIN puesto.
Tamao de ventana indica la cantidad de bytes que se est dispuesto a aceptar
del otro lado en cada momento. Se supone que se garantiza una cantidad suficiente de
espacio en buffers. Mediante este parmetro el receptor establece un control de flujo
sobre el caudal de datos que puede enviar el emisor.
Checksum sirve para detectar errores en el segmento recibido; estos podran ser
debidos a errores de transmisin no detectados, a fallos en los equipos (por ejemplo en
los routers) o a problemas en el software (por ejemplo reensamblado incorrecto de
fragmentos). Recordemos que el datagrama IP contena un checksum, pero aquel solo
comprenda la informacin de cabecera (y adems ese checksum desaparece en IPv6).
El algoritmo utilizado en TCP es el mismo que el de IP: sumar todos los campos de 16
_____________________________________________________________________________________
Biblioteconoma y Documentacin
46

Servicios Documentales en Red

Las capa de transporte en Internet

bits usando aritmtica de complemento a 1 y calcular el complemento a 1 del resultado,


pero en este caso el checksum se hace sobre todo el segmento, incluidos los datos, no
slo sobre la informacin de cabecera. Para el clculo del checksum se antepone al
segmento una pseudocabecera que incluye la direccin IP de origen y destino, y la
longitud del segmento. La pseudocabecera (as denominada porque slo se utiliza en el
clculo, pero no forma parte del segmento) permite a TCP comprobar que no ha habido
errores en la transmisin a nivel IP (detectar por ejemplo cuando un segmento ha sido
entregado al ordenador equivocado).
Puntero de datos urgentes indica el final de stos, ya que el segmento podra
contener datos no urgentes. TCP no marca el principio de los datos urgentes, es
responsabilidad de la aplicacin averiguarlo.
El campo opciones habilita un mecanismo por el cual es posible incluir
extensione s al protocolo. Entre las ms interesantes se encuentran las siguientes:

Tamao mximo de segmento

Uso de repeticin selectiva (en vez de retroceso n)

Uso de NAK (acuse de recibo negativo en caso de no recepcin de un segmento)

Uso de ventana extendida (mayor de 64 KBytes)

4.3.1 Flujo de datos en TCP.


Los segmentos, al viajar en datagramas IP, pueden llegar en cualquier orden,
perderse, llegar duplicados, etc. Es responsabilidad de TCP resolver todos estos
problemas y generar un flujo de bits fiable a nivel de aplicacin. En ningn caso viajar
en un mismo datagrama ms de un segmento. Tampoco se combinarn nunca en un
segmento datos provenientes de dos conexiones TCP diferentes.
Las aplicaciones que comunican haciendo uso de los servicios TCP no tienen
conciencia de la existencia de segmentos o datagramas. Para ellas la comunicacin se
realiza como un flujo continuo de bits (stream), como si hubiera un hilo fsico que las
comunicara. Si desean que la informacin sea transmitida a la aplicacin receptora en
mensajes discretos debern incluir los delimitadores adecuados, ya que no hay ninguna
garanta de que TCP genere un segmento por cada mensaje recibido de la aplicacin,
TCP puede tomarse la libertad de agrupar o separar los datos recibidos de la aplicacin
segn le convenga; por ejemplo, podra decidir agrupar los datos recibidos en varios
mensajes de la aplicacin para crear segmentos de tamao mayor y usar as de manera
ms eficiente la red.
Para poder enviar datos prioritarios y responder ante situaciones urgentes TCP
dispone de dos mecanismos extraordinarios por los que las aplicaciones le pueden
indicar su deseo de enviar rpidamente datos al otro extremo.
Uno de ellos es el denominado indicador PUSH. Cuando una aplicacin desea
que los datos entregados a TCP salgan enseguida, sin esperar ms datos de la aplicacin,
_____________________________________________________________________________________
Biblioteconoma y Documentacin
47

Servicios Documentales en Red

Las capa de transporte en Internet

lo indica poniendo a 1 el indicador PUSH; este indicador se utiliza por ejemplo cuando
en una sesin Telnet el usuario pulsa la tecla return, o cuando en una trasferencia FTP
se enva el ltimo segmento; en estos casos si no se utilizara PUSH se correra el riesgo
de que TCP se quedara esperando ms datos de la aplicacin para as construir un
segmento mayor y usar la red de manera mas eficiente.
El otro mecanismo de envo rpido de datos se denomina datos urgentes, y como
su nombre indica es an ms expeditivo. Por ejemplo en una sesin telnet se utiliza este
procedimiento para enviar los caracteres DEL, CTRL-C, o cuando se pulsa la tecla
BREAK o ATTN. En estos casos no solo se desea enviar cuanto antes los caracteres
recin tecleados, sino que se quiere que estos pasen por delante de cualesquiera otros
que hubiera pendientes de enviar a la aplicacin y se le entreguen a sta sin esperar a
que los solicite (por ejemplo para abortar una ejecucin en marcha cuando sta no
espera leer datos). Cuando un segmento contiene datos urgentes se indica esta condicin
mediante un bit indicador (flag) especial.
4.4 El protocolo UDP.
A veces se prefiere que el nivel de transporte preste un servicio ms sencillo, no
orientado a conexin y no fiable (por no fiable queremos decir que no confirma o no
acusa recibo de las TPDUs enviadas). Existen muchas razones que pueden motivar esta
preferencia, por ejemplo:

El tipo de aplicacin no requiere una fiabilidad total, y no podra tolerar el


retardo producido por ACKs, retransmisiones y todo el complejo proceso de
clculos que desarrolla TCP; este es el caso por ejemplo en la transmisin de
vdeo o audio en tiempo real.

La aplicacin por su propia naturaleza requiere nicamente el envo de uno o


dos mensajes, por ejemplo aplicaciones de sincronizacin de relojes, consultas
al servidor de nombres, mensajes de gestin de la red, etc.; en estos casos no se
considera rentable el costo en recursos que supone establecer una conexin TCP,
es preferible lanzar de nuevo el mensaje si ste no ha llegado.

Se desea hacer envos multidestino (multicast o broadcast); esto slo es posible


con un protocolo no orientado a conexin, ya que por su propia naturaleza los
protocolos orientados a conexin son punto a punto.

El protocolo UDP de Internet es un servicio no orientado a conexin. Entre las


aplicaciones que utilizan UDP se encuentran TFTP (Trivial File Transfer Protocol),
DNS (Domain Name Server), SNMP (Simple Network Management Protocol), NTP
(Network Time Protocol) y NFS (Network File System), etc.
Las TPDUs intercambiadas por UDP se denominan mensajes o datagramas
UDP, lo cual da una idea de la naturaleza del protocolo. Recordemos que el valor 17 en
el campo protocolo del datagrama IP identifica un mensaje UDP.

_____________________________________________________________________________________
Biblioteconoma y Documentacin
48

Servicios Documentales en Red

Las capa de transporte en Internet

Una caracterstica importante de UDP es que puede ser utilizado por


aplicaciones que necesitan soporte de trfico multicast o broadcast. Con TCP esto no es
posible debido a la naturaleza punto a punto, orie ntada a conexin del protocolo.
UDP no suministra ningn mecanismo de control de flujo o congestin. Cuando
lo que se enva es nicamente un mensaje (por ejemplo una consulta al DNS) esto es
innecesario, ya que presumiblemente un mensaje aislado no crear problemas de
congestin y ser siempre aceptado en destino (y de no ser as el mismo problema
habra habido con TCP para el inicio de la conexin). Si se van a enviar mensajes
mltiples, por ejemplo vdeo o audio en tiempo real, se debern tomar las medidas
adecuadas para asegurar la capacidad suficiente en la red (uso de RSVP por ejemplo) y
evitar la congestin no excediendo lo solicitado en el momento de hacer la reserva (en
estos casos se suele conocer con bastante aproximacin el trfico que se va a introducir
en la red).
En caso de congestin en la red o saturacin del receptor los datagramas IP
correspondientes a mensajes UDP sern descartados por la red sin informar por ningn
mecanismo al emisor, ni al receptor. En algunos se contemplan a nivel de aplicacin
mecanismos de control que permiten al receptor detectar si se producen prdidas,
informando al emisor para que baje el ritmo de emisin si se rebasa un umbral
determinado.
De forma similar a los segmentos TCP, los mensajes UDP se dirigen a la
aplicacin adecuada mediante el puerto de destino, especificado en la cabecera.
Anlogamente a TCP los puertos UDP son nmeros entre 0 y 65535, pero aun en el
caso de coincidir en nmero son TSAPs diferentes a los de TCP, como ya hemos
comentado antes. Como en TCP, los valores por debajo de 1024 estn reservados para
los puertos bien conocidos (well-known ports), aunque su significado es diferente. A
continuacin reproducimos una lista de los puertos UDP ms utilizados:
Puerto
7
9
13
17
19
53
68
68
69
111
123
161
162

Aplicacin
Echo
Discard
Daytime
Quote
Chargen
Nameserver
Bootps

Descripcin
Devuelve el datagrama al emisor
Descarta el datagrama
Devuelve la hora del dia
Devuelve una frase del dia
Generador de caracteres
Servidor de nombres de dominio
Puerto servidor utilizado para enviar informacin
configuracin
Bootpc
Puerto cliente utilizado para recibir informacin
configuracin
TFTP
Trivial File Transfer Protocol
SunRPC
Sun Remote Procedure Call
NTP
Network Time Protocol
SNMP
Usado para recibir consultas de gestin de la red
SNMP-trap Usado para recibir avisos de problemas en la red
Figura 4.4.1: Algunos ejemplos de puertos UDP.

de
de

La estructura de un mensaje UDP, mucho ms sencilla que la de un segmento


TCP, es la siguiente:
_____________________________________________________________________________________
Biblioteconoma y Documentacin
49

Servicios Documentales en Red

Las capa de transporte en Internet

16

31

Puerto origen UDP

Puerto destino UDP

Longitud de mensaje

Suma de comprobacin
Datos (opcional)

Figura 4.3.2: Estructura del segmento UDP.


Puerto origen especifica el puerto de la aplicacin que genera el mensaje. Este
valdr normalmente cero, salvo que la aplicacin solicite una respuesta.
Puerto destino especifica el puerto de la aplicacin a la que va dirigido el
mensaje.
Longitud indica la longitud del mensaje, incluyendo los campos de cabecera.
Checksum: el uso de este campo en UDP es opcional; cuando se enva
informacin en tiempo real (audio o vdeo digitalizado) su uso puede omitirse. Para el
clculo se aplica el mismo algoritmo que en TCP (suma complemento a 1 de todo el
mensaje dividido en campos de 16 bits, y complemento a 1 del resultado). En el clculo
se utiliza todo el mensaje, incluida la cabecera y se antepone una pseudocabecera igual
a la utilizada en TCP (con la direccin IP de origen, de destino y la longitud del
mensaje) de forma que se verifica que sean correctos los datos y la informacin de
control (puertos, direcciones IP, etc.) incluidos los datos fundamentales de la cabecera
IP. Si la verificacin del checksum en el receptor da error el mensaje es simplemente
descartado sin notificarlo al nivel de aplicacin ni al emisor.
Datos contiene los datos a transmitir. Un mensaje UDP ha de estar contenido
necesariamente en un datagrama IP, lo cual fija la longitud mxima de este campo. El
funcionamiento del protocolo UDP esta explicado en el RFC 768.

_____________________________________________________________________________________
Biblioteconoma y Documentacin
50

También podría gustarte