Redes De Computadora I: Msc. Carlos Bosquez

Redes de Computadora I
MSc. Carlos Bosquez
Ing. Carlos Bosquez - UPS-GYE
Servicios y Protocolos de capa de

Transporte
Contenido
Conceptos (multiplexado, transferencia confiable
o no confiable)
Protocolos de transporte de TCP/IP: TCP y UDP.
Control de congestin de TCP (slow start)
Aplicaciones de capa de transporte
Introduccin
Las redes de datos e Internet brindan soporte a la red humana al
proporcionar la comunicacin continua y confiable entre las personas,
tanto de manera local como alrededor del mundo. En un nico dispositivo,
las personas pueden utilizar varios servicios como e-mails, la Web y la
mensajera instantnea para enviar mensajes o recuperar informacin. Las
aplicaciones como clientes de correo electrnico, exploradores Web y
clientes de mensajera instantnea permiten que las personas utilicen las
computadoras y las redes para enviar mensajes y buscar informacin.
Los datos de cada una de estas aplicaciones se empaquetan, transportan y
entregan al daemon de servidor o aplicacin adecuados en el dispositivo
de destino. Los procesos descritos en la capa de Transporte del modelo
OSI aceptan los datos de la capa de Aplicacin y los preparan para el
direccionamiento en la capa de Red. La capa de Transporte es responsable
de la transferencia de extremo a extremo general de los datos de
aplicacin.
El rol de la capa de transporte

La capa de transporte es responsable de establecer una sesin
de comunicacin temporal entre dos aplicaciones y de
transmitir datos entre ellas. Las aplicaciones generan los datos
que se envan de una aplicacin en un host de origen a una
aplicacin a un host de destino, independientemente del tipo
de host de destino, el tipo de medios a travs de los que
deben viajar los datos, la ruta que toman los datos, la
congestin en un enlace o el tamao de la red. Como se
muestra en la ilustracin, la capa de transporte es el enlace
entre la capa de aplicacin y las capas inferiores que son
responsables de la transmisin a travs de la red.
La capa de transporte proporciona un mtodo para

entregar datos a travs de la red de una manera que
garantiza que estos se puedan volver a unir
correctamente en el extremo receptor. La capa de
transporte permite la segmentacin de datos y
proporciona el control necesario para rearmar estos
segmentos en los distintos streams de comunicacin.
En el protocolo TCP/IP, estos procesos de segmentacin
y rearmado se pueden lograr utilizando dos protocolos
muy diferentes de la capa de transporte: el protocolo
de control de transmisin (TCP) y el protocolo de
datagramas de usuario (UDP).
Rastreo de conversaciones individuales

Cualquier host puede tener mltiples aplicaciones que se estn comunicando a travs de la
red. Cada una de estas aplicaciones se comunicar con una o ms aplicaciones en hosts
remotos. Es responsabilidad de la capa de Transporte mantener los diversos streams de
comunicacin entre estas aplicaciones.
Segmentacin de datos y rearmado de segmentos

Se deben preparar los datos para el envo a travs de los medios en partes manejables. La
mayora de las redes tienen un lmite de la cantidad de datos que se puede incluir en un solo
paquete. Los protocolos de la capa de transporte tienen servicios que segmentan los datos
de aplicacin en bloques de datos de un tamao apropiado (figura 2). Estos servicios incluyen
la encapsulacin necesaria en cada porcin de datos. Se agrega un encabezado a cada bloque
de datos para el rearmado. Este encabezado se utiliza para hacer un seguimiento del stream
de datos.
En el destino, la capa de transporte debe poder reconstruir las porciones de datos en un
stream de datos completo que sea til para la capa de aplicacin. Los protocolos en la capa
de transporte describen cmo se utiliza la informacin del encabezado de dicha capa para
rearmar las porciones de datos en streams para pasarlos a la capa de aplicacin.
Identificacin de las aplicaciones

Puede haber muchas aplicaciones o servicios que se
ejecutan en cada host de la red. Para pasar streams de
datos a las aplicaciones adecuadas, la capa de
transporte debe identificar la aplicacin objetivo
(figura 3). Para lograr esto, la capa de transporte asigna
un identificador a cada aplicacin. Este identificador se
denomina nmero de puerto. A todos los procesos
de software que requieran acceder a la red se les
asigna un nmero de puerto exclusivo en ese host. La
capa de transporte utiliza puertos para identificar la
aplicacin o el servicio.
Los requerimientos de datos varan
Debido a que las distintas aplicaciones poseen distintos requerimientos, existen varios protocolos
de la capa de Transporte. Para algunas aplicaciones, los segmentos deben llegar en una secuencia
especfica de manera que puedan ser procesados en forma exitosa. En algunos casos, todos los
datos deben recibirse para ser utilizados por cualquiera de las mismas. En otros casos, una
aplicacin puede tolerar cierta prdida de datos durante la transmisin a travs de la red.
En las redes convergentes actuales, las aplicaciones con distintas necesidades de transporte pueden
comunicarse en la misma red. Los distintos protocolos de la capa de Transporte poseen distintas
reglas que permiten que los dispositivos gestionen los diversos requerimientos de datos.
Algunos protocolos proporcionan slo las funciones bsicas para la entrega eficiente de las
secciones de datos entre las aplicaciones adecuadas. Estos tipos de protocolos son tiles para
aquellas aplicaciones cuyos datos son sensibles a las demoras.
Otros protocolos de la capa de Transporte describen procesos que brindan funciones adicionales,
como asegurar la entrega confiable entre las aplicaciones. Si bien estas funciones adicionales
proveen una comunicacin ms slida entre aplicaciones de la capa de Transporte, representan la
necesidad de utilizar recursos adicionales y generan un mayor nmero de demandas en la red.
Multiplexacin de conversaciones
El envo de algunos tipos de datos (por ejemplo, un streaming video) a travs de

una red, como un stream completo de comunicacin, podra utilizar todo el ancho
de banda disponible e impedir que se produzcan otras comunicaciones al mismo
tiempo. Tambin dificulta la recuperacin de errores y la retransmisin de datos
daados.
En la ilustracin, se muestra que la segmentacin de los datos en partes ms
pequeas permite que se entrelacen (multiplexen) varias comunicaciones de
distintos usuarios en la misma red. La segmentacin de los datos segn los
protocolos de la capa de transporte tambin proporciona los medios para enviar y
recibir datos cuando se ejecutan varias aplicaciones a la vez en una PC.
Sin la segmentacin, solo podra recibir datos una aplicacin. Por ejemplo, con un
streaming video, los medios se consumiran por completo por ese stream de
comunicacin en lugar de compartirse. No podra recibir correos electrnicos,
chatear por mensajera instantnea o visitar pginas Web mientras mira el video.
Para identificar cada segmento de datos, la capa de transporte agrega al segmento
un encabezado que contiene datos binarios. Este encabezado contiene campos de
bits. Los valores de estos campos permiten que los distintos protocolos de la capa
de transporte lleven a cabo diferentes funciones de administracin de la
comunicacin de datos.
Confiabilidad de la capa de transporte

La capa de transporte tambin es responsable de administrar los
requisitos de confiabilidad de las conversaciones. Las diferentes
aplicaciones tienen diferentes requisitos de confiabilidad de transporte.
IP se ocupa solo de la estructura, el direccionamiento y el enrutamiento
de paquetes. IP no especifica la manera en que se lleva a cabo la entrega o
el transporte de los paquetes.
Los protocolos de transporte especifican la manera en que se transfieren
los mensajes entre los hosts. TCP/IP proporciona dos protocolos de la capa
de transporte: el protocolo de control de transmisin (TCP) y el protocolo
de datagramas de usuario (UDP), como se muestra en la ilustracin. IP
utiliza estos protocolos de transporte para habilitar la comunicacin y la
transferencia de datos entre los hosts.
TCP se considera un protocolo de la capa de transporte confiable y
completo, lo que garantiza que todos los datos lleguen al destino. En
cambio, UDP es un protocolo de la capa de transporte muy simple que no
proporciona confiabilidad.
TCP y 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 Protocolos 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.
Protocolo de datagramas de usuario

(UDP)
UDP es un protocolo simple, sin conexin, descrito en la RFC 768.
Cuenta con la ventaja de proveer la entrega de datos sin utilizar
muchos recursos. Las porciones de comunicacin en UDP se llaman
datagramas. Este protocolo de la capa de Transporte enva estos
datagramas como "mejor intento".
Entre las aplicaciones que utilizan UDP se incluyen:
sistema de nombres de dominios (DNS),
streaming de vdeo, y
Voz sobre IP (VoIP).
Protocolo de control de transmisin

(TCP)
TCP es un protocolo orientado a la conexin, descrito en la RFC 793. TCP
incurre en el uso adicional de recursos para agregar funciones. Las
funciones adicionales especificadas por TCP estn en el mismo orden de
entrega, son de entrega confiable y de control de flujo. Cada segmento de
TCP posee 20 bytes de carga en el encabezado, que encapsulan los datos
de la capa de Aplicacin, mientras que cada segmento UDP slo posee 8
bytes de carga. Ver la figura para obtener una comparacin.
Las aplicaciones que utilizan TCP son:
exploradores Web,
e-mail, y
transferencia de archivos
Direccionamiento del puerto
Identificacin de las conversaciones
Considere el ejemplo anterior de una computadora que recibe y enva e-mails,

mensajes instantneos, pginas Web y llamadas telefnicas VoIP de manera
simultnea.
Los servicios basados en TCP y UDP mantienen un seguimiento de las varias

aplicaciones que se comunican. Para diferenciar los segmentos y datagramas para
cada aplicacin, tanto TCP como UDP cuentan con campos de encabezado que
pueden identificar de manera exclusiva estas aplicaciones. Estos identificadores
nicos son los nmeros de los puertos.
En el encabezado de cada segmento o datagrama hay un puerto de origen y

destino. El nmero de puerto de origen es el nmero para esta comunicacin
asociado con la aplicacin que origina la comunicacin en el host local. El nmero
de puerto de destino es el nmero para esta comunicacin asociado con la
aplicacin de destino en el host remoto.
Los nmeros de puerto se asignan de varias maneras, en funcin de si el mensaje

es una solicitud o una respuesta. Mientras que los procesos en el servidor poseen
nmeros de puertos estticos asignados a ellos, los clientes eligen un nmero de
puerto de forma dinmica para cada conversacin.
Cuando una aplicacin de cliente enva una solicitud a una aplicacin de servidor,
el puerto de destino contenido en el encabezado es el nmero de puerto que se
asigna al daemon de servicio que se ejecuta en el host remoto. El software del
cliente debe conocer el nmero de puerto asociado con el proceso del servidor en
el host remoto. Este nmero de puerto de destino se puede configurar, ya sea de
forma predeterminada o manual. Por ejemplo, cuando una aplicacin de
explorador Web realiza una solicitud a un servidor Web, el explorador utiliza TCP y
el nmero de puerto 80 a menos que se especifique otro valor. Esto sucede porque
el puerto TCP 80 es el puerto predeterminado asignado a aplicaciones de
servidores Web. Muchas aplicaciones comunes tienen asignados puertos
predeterminados.
El puerto de origen del encabezado de un segmento o datagrama de un cliente se

genera de manera aleatoria. Siempre y cuando no entre en conflicto con otros
puertos en uso en el sistema, el cliente puede elegir cualquier nmero de puerto.
El nmero de puerto acta como direccin de retorno para la aplicacin que
realiza la solicitud. La capa de Transporte mantiene un seguimiento de este puerto
y de la aplicacin que gener la solicitud, de manera que cuando se devuelva una
respuesta, pueda ser enviada a la aplicacin correcta. El nmero de puerto de la
aplicacin que realiza la solicitud se utiliza como nmero de puerto de destino en
la respuesta que vuelve del servidor.
La combinacin del nmero de puerto de la capa de Transporte y de la direccin IP

de la capa de Red asignada al host identifica de manera exclusiva un proceso en
particular que se ejecuta en un dispositivo host especfico. Esta combinacin se
denomina socket. Eventualmente, los trminos nmero de puerto y socket se
utilizan en forma indistinta. En el contexto de este curso, el trmino socket hace
referencia slo a la combinacin exclusiva de direccin IP y nmero de puerto. Un
par de sockets, que consiste en las direcciones IP y los nmeros de puerto de
origen y de destino, tambin es exclusivo e identifica la conversacin entre dos
hosts.
Por ejemplo, una solicitud de pgina Web HTTP

que se enva a un servidor Web (puerto 80) y que
se ejecuta en un host con una direccin IPv4 de
Capa 3 192.168.1.20 ser destinada al socket
192.168.1.20:80.
Si el explorador Web que solicita la pgina Web
se ejecuta en el host 192.168.100.48 y el nmero
de puerto dinmico asignado al explorador Web
es 49.152, el socket para la pgina Web ser
192.168.100.48:49152.
La Autoridad de nmeros asignados de Internet (IANA) asigna nmeros de puerto. IANA es un

organismo de estndares responsable de la asignacin de varias normas de direccionamiento.
Existen distintos tipos de nmeros de puerto:
Puertos bien conocidos (Nmeros del 0 al 1 023): estos nmeros se reservan para servicios y
aplicaciones. Por lo general, se utilizan para aplicaciones como HTTP (servidor Web), POP3/SMTP
(servidor de e-mail) y Telnet. Al definir estos puertos conocidos para las aplicaciones del servidor,
las aplicaciones del cliente pueden ser programadas para solicitar una conexin a un puerto
especfico y su servicio asociado.
Puertos Registrados (Nmeros 1024 al 49151): estos nmeros de puertos estn asignados a
procesos o aplicaciones del usuario. Estos procesos son principalmente aplicaciones individuales
que el usuario elige instalar en lugar de aplicaciones comunes que recibira un puerto bien
conocido. Cuando no se utilizan para un recurso del servidor, estos puertos tambin pueden
utilizarse si un usuario los selecciona de manera dinmica como puerto de origen.
Puertos dinmicos o privados (Nmeros del 49 152 al 65 535): tambin conocidos

como puertos efmeros, suelen asignarse de manera dinmica a aplicaciones de
cliente cuando se inicia una conexin. No es muy comn que un cliente se conecte
a un servicio utilizando un puerto dinmico o privado (aunque algunos programas
que comparten archivos punto a punto lo hacen).
Utilizacin de los dos protocolos TCP y UDP
Algunas aplicaciones pueden utilizar los dos protocolos: TCP y UDP. Por ejemplo, el
bajo gasto de UDP permite que DNS atienda rpidamente varias solicitudes de
clientes. Sin embargo, a veces el envo de la informacin solicitada puede requerir
la confiabilidad de TCP. En este caso, el nmero 53 de puerto conocido es utilizado
por ambos protocolos con este servicio.
Enlaces
Se puede encontrar un lista actual de

http://www.iana.org/assignments/port-numbers.
nmeros
de
puertos
en
A veces es necesario conocer las conexiones TCP activas que estn

abiertas y en ejecucin en el host de red. Netstat es una utilidad de red
importante que puede usarse para verificar esas conexiones. Netstat
indica el protocolo en uso, la direccin y el nmero de puerto locales, la
direccin y el nmero de puerto ajenos y el estado de la conexin.
Las conexiones TCP no descritas pueden representar una importante
amenaza a la seguridad. Esto se debe a que pueden indicar que algo o
alguien est conectado al host local. Adems, las conexiones TCP
innecesarias pueden consumir recursos valiosos del sistema y por lo tanto
disminuir el rendimiento del host. Netstat debe utilizarse para determinar
las conexiones abiertas de un host cuando el rendimiento parece estar
comprometido.
Existen muchas opciones tiles para el comando netstat.
Segmentacin y reensamblaje
Algunas aplicaciones transmiten grandes cantidades de datos; en
algunos casos, varios gigabytes. Resultara poco prctico enviar
todos estos datos en una sola gran seccin. No puede transmitirse
ningn otro trfico de red mientras se envan estos datos. Una gran
seccin de datos puede tardar minutos y hasta horas en enviarse.
Adems, si hubiera algn error, el archivo de datos completo se
perdera o tendra que ser reenviado. Los dispositivos de red no
cuentan con buffers de memoria lo suficientemente grandes como
para almacenar esa cantidad de datos durante la transmisin o
recepcin. El lmite vara en funcin de la tecnologa de la red y del
medio fsico especfico que se utiliza.
Dividir los datos de aplicacin en secciones garantiza que los datos
se transmitan dentro de los lmites del medio y que los datos de
distintas aplicaciones puedan ser multiplexados en el medio.
TCP y UDP gestionan la segmentacin de forma distinta.
Con TCP, cada encabezado de segmento contiene un nmero de secuencia. Este

nmero de secuencia permite que las funciones de la capa de Transporte del host
de destino reensamblen los segmentos en el mismo orden en el que fueron
transmitidos. Esto asegura que la aplicacin de destino cuente con los datos en la
forma exacta en la que se enviaron.
A pesar de que los servicios que utilizan UDP tambin rastrean las conversaciones
entre aplicaciones, no tienen en cuenta el orden en el que se transmiti la
informacin ni el mantenimiento de la conexin. No existe nmero de secuencia
en el encabezado UDP. UDP es un diseo simple y genera menos carga que TCP, lo
que produce una transferencia de datos ms rpida.
La informacin puede llegar en un orden distinto al que fue transmitida, ya que los
paquetes pueden tomar diversas rutas a travs de la red. Una aplicacin que utiliza
UDP debe tolerar el hecho de que los datos no lleguen en el orden en el que
fueron enviados.
TCP
La confiabilidad de la comunicacin TCP se lleva a cabo utilizando sesiones
orientadas a la conexin. Antes de que un host que utiliza TCP enve datos
a otro host, la capa de Transporte inicia un proceso para crear una
conexin con el destino. Esta conexin permite el rastreo de una sesin o
stream de comunicacin entre los hosts. Este proceso asegura que cada
host tenga conocimiento de la comunicacin y se prepare. Una
conversacin TCP completa requiere el establecimiento de una sesin
entre los hosts en ambas direcciones.
Luego de establecida la sesin, el destino enva acuses de recibo al origen

por los segmentos que recibe. Estos acuses de recibo forman la base de la
confiabilidad dentro de la sesin TCP. Cuando el origen recibe un acuse de
recibo, reconoce que los datos se han entregado con xito y puede dejar
de rastrearlos. Si el origen no recibe el acuse de recibo dentro de un
tiempo predeterminado, retransmite esos datos al destino.
Parte de la carga adicional que genera el uso de TCP es el

trfico de red generado por los acuses de recibo y las
retransmisiones. El establecimiento de las sesiones genera
cargas en forma de segmentos adicionales intercambiados.
Tambin existen cargas adicionales en los hosts
individuales, generadas por la necesidad de mantener un
seguimiento de los segmentos que esperan acuse de recibo
y por el proceso de retransmisin.
Esta confiabilidad se logra contando con campos en el
segmento TCP, cada uno con una funcin especfica, como
se muestra en la figura. Estos campos se explicarn ms
adelante en esta seccin.
Procesos del servidor TCP
Los procesos de aplicacin se ejecutan en servidores. Estos procesos esperan hasta que un cliente
inicie comunicacin con una solicitud de informacin o de otros servicios.
Cada proceso de aplicacin que se ejecuta en el servidor es configurado por el administrador del
sistema para utilizar un nmero de puerto, de forma predeterminada o manual. Un servidor
individual no puede tener dos servicios asignados al mismo nmero de puerto dentro de los
mismos servicios de la capa de Transporte. Un host que ejecuta una aplicacin de servidor Web y
una de transferencia de archivos no puede configurar ambas para utilizar el mismo puerto (por
ejemplo, el puerto TCP 8.080). Cuando una aplicacin de servidor activa se asigna a un puerto
especfico, este puerto se considera "abierto" para el servidor. Esto significa que la capa de
Transporte acepta y procesa segmentos direccionados a ese puerto. Toda solicitud entrante de un
cliente direccionada al socket correcto es aceptada y los datos se envan a la aplicacin del servidor.
Pueden existir varios puertos simultneos abiertos en un servidor, uno para cada aplicacin de
servidor activa. Es comn que un servidor provea ms de un servicio, como un servidor Web y un
servidor FTP, al mismo tiempo.
Una manera de mejorar la seguridad en un servidor es restringir el acceso al servidor a slo
aquellos puertos asociados con los servicios y aplicaciones accesibles a solicitantes autorizados.
La figura muestra la asignacin tpica de puertos de origen y destino en operaciones de cliente o

servidor TCP.
Establecimiento y finalizacin de la
conexin TCP
Cuando dos hosts se comunican utilizando TCP, se establece una conexin antes de
que puedan intercambiarse los datos. Luego de que se completa la comunicacin,
se cierran las sesiones y la conexin finaliza. Los mecanismos de conexin y de
sesin habilitan la funcin de confiabilidad de TCP.
El host rastrea cada segmento de datos dentro de una sesin e intercambia
informacin sobre los datos recibidos por cada host a travs de la informacin del
encabezado TCP.
Cada conexin representa dos streams de comunicacin de una va o sesiones.
Para establecer la conexin los hosts realizan un intercambio de seales de tres
vas. Los bits de control en el encabezado TCP indican el progreso y estado de la
conexin. Enlace de tres vas:
Establece que el dispositivo de destino est presente en la red.
Verifica que el dispositivo de destino tenga un servicio activo y est aceptando las
peticiones en el nmero de puerto de destino que el cliente que lo inicia intente
usar para la sesin.
Informa al dispositivo de destino que el cliente de origen intenta establecer una
sesin de comunicacin en ese nmero de puerto.
En conexiones TCP, el host que brinde el servicio como cliente inicia la sesin al
servidor. Los tres pasos para el establecimiento de una conexin TCP son:
1. El cliente que inicia la conexin enva un segmento que contiene un valor de

secuencia inicial, que acta como solicitud para el servidor para comenzar una
sesin de comunicacin.
2. El servidor responde con un segmento que contiene un valor de reconocimiento

igual al valor de secuencia recibido ms 1, adems de su propio valor de secuencia
de sincronizacin. El valor es uno mayor que el nmero de secuencia porque el
ACK es siempre el prximo Byte u Octeto esperado. Este valor de reconocimiento
permite al cliente unir la respuesta al segmento original que fue enviado al
servidor.
3. El cliente que inicia la conexin responde con un valor de reconocimiento igual

al valor de secuencia que recibi ms uno. Esto completa el proceso de
establecimiento de la conexin.
Para entender el proceso de enlace de tres vas, es importante observar los distintos valores
que intercambian los dos hosts. Dentro del encabezado del segmento TCP, existen seis
campos de 1 bit que contienen informacin de control utilizada para gestionar los procesos
de TCP. Estos campos son los siguientes:
URG: Urgente campo de sealizador significativo,

ACK: Campo significativo de acuse de recibo,
PSH: Funcin de empuje,
RST: Reconfiguracin de la conexin,
SYN: Sincronizar nmeros de secuencia,
FIN: No hay ms datos desde el emisor.
A estos campos se los denomina sealadores porque el valor de uno de estos campos es slo
de 1 bit, entonces tiene slo dos valores: 1 0. Si el valor del bit se establece en 1, indica la
informacin de control que contiene el segmento.
Si se utiliza un proceso de cuatro pasos, los sealizadores se intercambian para finalizar la

conexin TCP.
Protocolo TCP de enlace de tres vias
Un cliente TCP comienza el enlace de tres vas enviando un segmento con el

sealizador de control SYN (Sincronizar nmeros de secuencia) establecido,
indicando un valor inicial en el campo de nmero de secuencia del encabezado.
Este valor inicial para el nmero de secuencia, conocido como nmero de
secuencia inicial (ISN), se elige de manera aleatoria y se utiliza para comenzar a
rastrear el flujo de datos desde el cliente al servidor para esta sesin. El ISN en el
encabezado de cada segmento se incrementa en uno por cada byte de datos
enviados desde el cliente hacia el servidor mientras contina la conversacin de
datos.
Como se muestra en la figura, el resultado de un analizador de protocolos muestra

el sealizador de control SYN y el nmero de secuencia relativa.
Se establece el sealizador de control SYN y el nmero de secuencia relativa en 0.

A pesar de que el analizador de protocolos en el grfico indica los valores relativos
para los nmeros de secuencia y de acuse de recibo, los valores reales son
nmeros binarios de 32 bits. Se pueden determinar los nmeros reales enviados
en los encabezados de los segmentos examinando el panel de bytes del paquete.
Aqu se pueden ver los cuatro bytes representados en hexadecimal.
El servidor TCP necesita reconocer la recepcin del segmento SYN del cliente para establecer la
sesin de cliente a servidor. Para hacerlo, el servidor enva un segmento al cliente con el
sealizador ACK establecido indicando que el nmero de acuse de recibo es significativo. Con este
sealizador establecido en el segmento, el cliente interpreta esto como acuse de recibo de que el
servidor ha recibido el SYN del cliente TCP.
El valor del nmero de campo del acuse de recibo es igual al nmero de secuencia inicial del cliente
ms 1. Esto establece una sesin desde el cliente al servidor. El sealizador ACK permanecer
establecido para mantener el equilibrio de la sesin. Cabe recordar que la conversacin entre el
cliente y el servidor est compuesta en realidad por dos sesiones de una va: una del cliente al
servidor y la otra del servidor al cliente. En este segundo paso del enlace de tres vas, el servidor
debe iniciar la respuesta del servidor al cliente. Para comenzar esta sesin, el servidor utiliza el
sealizador SYN de la misma manera en que lo hizo el cliente. Establece el sealizador de control
SYN en el encabezado para establecer una sesin del servidor al cliente. El sealizador SYN indica
que el valor inicial del campo de nmero de secuencia se encuentra en el encabezado. Este valor se
utilizar para rastrear el flujo de datos en esta sesin del servidor al cliente.
Como se muestra en la figura, el resultado del analizador de protocolos muestra que estn
establecidos los sealizadores de control ACK y SYN y se muestran los nmeros relativos de
secuencia y reconocimiento.
Por ltimo, el cliente TCP responde con un segmento que contiene un ACK que acta como
respuesta al SYN de TCP enviado por el servidor. No existen datos de usuario en este segmento. El
valor del campo nmero de acuse de recibo contiene uno ms que el nmero de secuencia inicial
recibido del servidor. Una vez establecidas ambas sesiones entre el cliente y el servidor, todos los
segmentos adicionales que se intercambien en la comunicacin tendrn establecido el sealizador
ACK.
Como se muestra en la figura, el resultado del analizador de protocolos muestra el sealizador de

control ACK establecido y se muestran los nmeros relativos de secuencia y reconocimiento.
Se puede aadir seguridad a la red de datos de la siguiente manera:

denegar el establecimiento de sesiones TCP,
slo permitir sesiones para ser establecidas por servicios especficos, o
slo permitir trfico como parte de sesiones ya establecidas.
Esta segurdiad puede implementarse para todas las sesiones o slo para las sesiones seleccionadas.
Terminacin de las sesiones TCP
Para cerrar la conexin se debe establecer el sealizador de control FIN (Finalizar) en el encabezado
del segmento. Para finalizar todas las sesiones TCP de una va, se utiliza un enlace de dos vas, que
consta de un segmento FIN y un segmento ACK. Por lo tanto, para terminar una conversacin
simple admitida por TCP, se requieren cuatro intercambios para finalizar ambas sesiones.
Nota: En esta explicacin se usan los trminos cliente y servidor como referencia por simplicidad
pero la finalizacin del proceso puede ser iniciada por cualquiera de los dos hosts que completen la
sesin:
1. Cuando el cliente no tiene ms datos para enviar al stream, enva un segmento con el sealizador
FIN establecido.
2.El servidor enva un ACK para acusar recibo de Fin y terminar la sesin del cliente al servidor.
3. El servidor enva un FIN al cliente para finalizar la sesin del servidor al cliente.
4. El cliente responde con un ACK para dar acuse de recibo de FIN desde el servidor.
Cuando la finalizacin de sesin del cliente no tiene ms datos para transferir, establece el
sealizador FIN en el encabezado de un segmento. Luego, el servidor finaliza la conexin y enva un
segmento normal que contiene datos con el sealizador ACK establecido utilizando el nmero de
acuse de recibo, confirmando as que se han recibido todos los bytes de datos. Cuando se produce
el acuse de recibo de todos los segmentos, se cierra la sesin.
La sesin en la otra direccin se cierra mediante el mismo proceso. El receptor indica que no
existen ms datos para enviar estableciendo el sealizador FIN en el encabezado del segmento
enviado al origen. Un acuse de recibo de retorno confirma que todos los bytes de datos han sido
recibidos y, por lo tanto, se ha cerrado la sesin.
Como se muestra en la figura, los sealizadores de control FIN y ACK se establecen en el

encabezado del segmento, cerrando por lo tanto la sesin HTTP.
Tambin es posible terminar la conexin mediante un enlace de tres vas. Cuando el cliente no
posee ms datos para enviar, enva un sealizador FIN al servidor. Si el servidor tampoco tiene ms
datos para enviar, puede responder con los sealizadores FIN y ACK, combinando dos pasos en uno.
El cliente responde con un ACK.
Reensamblaje de segmentos TCP

Resecuenciamiento de segmentos al orden transmitido
Cuando los servicios envan datos utilizando TCP, los segmentos pueden
llegar a destinos desordenados. Para que el receptor comprenda el
mensaje original, los datos en estos segmentos se reensamblan en el
orden original. Para lograr esto, se asignan nmeros de secuencia en el
encabezado de cada paquete.
Durante la configuracin de la sesin, se establece un nmero de
secuencia inicial (ISN). Este nmero de secuencia inicial representa el valor
de inicio para los bytes de esta sesin que se transmitirn a la aplicacin
receptora. A medida que se transmiten los datos durante la sesin, el
nmero de secuencia se incrementa en el nmero de bytes que se han
transmitido. Este rastreo de bytes de datos permite que cada segmento se
identifique y se enve acuse de recibo de manera exclusiva. Se pueden
identificar segmentos perdidos.
Los nmeros de secuencia de segmento permiten la

confiabilidad indicando cmo reensamblar y reordenar
los segmentos recibidos, como se muestra en la figura.
El proceso TCP receptor coloca los datos del segmento
en un bfer de recepcin. Los segmentos se colocan en
el orden de nmero de secuencia adecuado y se pasa a
la capa de Aplicacin cuando son reensamblados.
Todos los segmentos que llegan con nmeros de
secuencia no contiguos se mantienen para su
procesamiento posterior. Luego, se procesan los
segmentos cuando llegan con los bytes perdidos.
Acuse de recibo TCP con uso de

ventanas
Una de las funciones de TCP es asegurar que cada segmento llegue a su destino. Los servicios TCP
en el host de destino envan a la aplicacin de origen un acuse de recibo de los datos recibidos.
El nmero de secuencia y el nmero de acuse de recibo del encabezado del segmento se utilizan
para confirmar la recepcin de los bytes de datos contenidos en los segmentos. El nmero de
secuencia es el nmero relativo de bytes que ha sido transmitido en esta sesin ms 1 (que es el
nmero del primer byte de datos en el segmento actual). TCP utiliza el nmero de reconocimiento
en segmentos que se vuelven a enviar al origen para indicar el prximo byte de esta sesin que
espera el receptor. Esto se llama acuse de recibo de expectativa.
Se le informa al origen que el destino ha recibido todos los bytes de este stream de datos, pero sin
incluir, el byte especificado por el nmero de acuse de recibo. Se espera que el host emisor enve
un segmento que utiliza un nmero de secuencia igual al nmero de acuse de recibo.
Recuerde que cada conexin se representa en realidad por dos sesiones de una va. Los nmeros de
secuencia y de acuse de recibo se intercambian en ambas direcciones.
En el ejemplo de la figura, el host en la izquierda enva datos al host de la derecha. Enva un

segmento que contiene 10 bytes de datos para esta sesin y un nmero de secuencia igual a 1 en el
encabezado.
El host receptor de la derecha recibe el segmento en la Capa 4 y determina que el nmero de

secuencia es 1 y que posee 10 bytes de datos. Luego el host enva un segmento de vuelta al host de
la izquierda para acusar recibo de estos datos. En este segmento, el host establece el nmero de
acuse de recibo en 11 para indicar que el prximo byte de datos que espera recibir en esta sesin
es el byte nmero 11.
Cuando el host emisor de la izquierda recibe este acuse de recibo, puede enviar el prximo
segmento que contiene datos para esta sesin a partir del byte 11.
Observando este ejemplo, si el host emisor tuviera que esperar el acuse de recibo por la recepcin
de cada uno de los 10 bytes, la red estara demasiado sobrecargada. Para reducir la sobrecarga de
estos acuses de recibo, los segmentos de datos mltiples pueden enviarse previamente y ser
reconocidos con un mensaje TCP simple en la direccin opuesta. Este reconocimiento contiene un
nmero de acuse de recibo en base al nmero total de bytes recibidos en la sesin.
Por ejemplo, si se comienza con un nmero de secuencia 2000, si se reciben 10 segmentos de 1000
bytes cada uno, se devolver al origen un nmero de reconocimiento igual a 12001.
Retransmisin de TCP
Manejo de la prdida de segmentos
Por ptimo que sea el diseo de una red, siempre se producirn prdidas
ocasionales de datos. Por lo tanto, TCP cuenta con mtodos para gestionar
dichas prdidas de segmentos. Entre los mismos existe un mecanismo
para retransmitir segmentos con datos no reconocidos.
Un servicio de host de destino que utiliza TCP, por lo general slo reconoce
datos para secuencias de bytes contiguas. Si uno o ms segmentos se
pierden, slo se acusa recibo de los datos de los segmentos que
completan el stream.
Por ejemplo, si se reciben los segmentos con nmeros de secuencia de
1500 a 3000 y de 3400 a 3500, el nmero de acuse de recibo ser 3001.
Esto sucede porque existen segmentos con nmeros de secuencia de 3001
a 3399 que no se recibieron.
Cuando TCP en el host de origen no recibe un acuse de recibo pasado un tiempo predeterminado,
volver al ltimo nmero de acuse de recibo que recibi y retransmitir los datos a partir de ste.
El proceso de retransmisin no es especificado por RFC, sino que depende de la implementacin de

TCP en particular.
Para una implementacin de TCP tpica, un host puede transmitir un segmento, colocar una copia
del segmento en una cola de retransmisin e iniciar un temporizador. Cuando se recibe el acuse de
recibo de los datos, se elimina el segmento de la cola. Si no se recibe el acuse de recibo antes de
que el temporizador venza, el segmento es retransmitido.
La animacin demuestra la retransmisin de segmentos perdidos.
Los hosts actuales tambin suelen emplear una funcin opcional llamada Acuses de recibo
selectivos. Si ambos hosts admiten el Acuse de recibo selectivo, es posible que el destino reconozca
los bytes de segmentos discontinuos y el host slo necesitar retransmitir los datos perdidos.
Control de congestin de TCP: Como

minimizar la prdida de segmentos.
Control del flujo
TCP tambin provee mecanismos para el control del flujo. El control del flujo
contribuye con la confiabilidad de la transmisin TCP ajustando la tasa efectiva de
flujo de datos entre los dos servicios de la sesin. Cuando el origen advierte que se
recibi la cantidad de datos especificados en los segmentos, puede continuar
enviando ms datos para esta sesin.
El campo Tamao de la ventana en el encabezado TCP especifica la cantidad de

datos que puede transmitirse antes de que se reciba el acuse de recibo. El tamao
de la ventana inicial se determina durante el comienzo de la sesin a travs del
enlace de tres vas.
El mecanismo de retroalimentacin de TCP ajusta la tasa de transmisin de datos

efectiva al flujo mximo que la red y el dispositivo de destino pueden soportar sin
sufrir prdidas. TCP intenta gestionar la tasa de transmisin de manera que todos
los datos se reciban y se reduzcan las retransmisiones.
Ver la figura para obtener una representacin simplificada del tamao de

la ventana y los acuses de recibo. En este ejemplo, el tamao de la
ventana inicial para una sesin TCP representada se establece en 3000
bytes. Cuando el emisor transmite 3000 bytes, espera por un acuse de
recibo de los mismos antes de transmitir ms segmentos para esta sesin.
Una vez que el emisor ha recibido este acuse de recibo del receptor, ya
puede transmitir 3000 bytes adicionales.
Durante la demora en la recepcin del acuse de recibo, el emisor no
enviar ningn segmento adicional para esta sesin. En los perodos en los
que la red est congestionada o los recursos del host receptor estn
exigidos, la demora puede aumentar. A medida que aumenta esta demora,
disminuye la tasa de transmisin efectiva de los datos para esta sesin. La
disminucin de la tasa de datos ayuda a reducir la contencin de recursos.
Reduccin del tamao de la ventana
Otra forma de controlar el flujo de datos es utilizar tamaos dinmicos de ventana. Cuando los
recursos de la red son limitados, TCP puede reducir el tamao de la ventana para lograr que los
segmentos recibidos sean reconocidos con mayor frecuencia. Esto disminuye de manera efectiva la
tasa de transmisin, ya que el origen espera que los datos sean recibidos con ms frecuencia.
El host receptor TCP enva el valor del tamao de la ventana al TCP emisor para indicar el nmero
de bytes que est preparado para recibir como parte de la sesin. Si el destino necesita disminuir la
tasa de comunicacin debido a limitaciones de memoria del bfer, puede enviar un valor de
tamao de la ventana menor al origen como parte de un acuse de recibo.
Como se muestra en la figura, si un host de recepcin sufre una congestin, puede responder al
host emisor con un segmento con el tamao de la ventana reducido. En este grfico, se produjo la
prdida de uno de los segmentos. El receptor cambi el campo ventana en el encabezado de los
mensajes devueltos en esta conversacin de 3000 a 1500. Esto hizo que el emisor redujera el
tamao de la ventana a 1500.
Despus de perodos de transmisin sin prdidas de datos o recursos limitados, el receptor

comenzar a aumentar el tamao de la ventana. Esto reduce la sobrecarga de la red, ya que se
requiere enviar menos acuses de recibo. El tamao de la ventana continuar aumentando hasta
que haya prdida de datos, lo que producir una disminucin del tamao de la ventana.
Estas disminuciones y aumentos dinmicos del tamao de la ventana representan un proceso

continuo en TCP, que determina el tamao de la ventana ptimo para cada sesin TCP. En redes
altamente eficientes, los tamaos de la ventana pueden ser muy grandes porque no se pierden
datos. En redes donde se est estresando la infraestructura subyacente, el tamao de la ventana
probablemente permanecer pequeo.
Enlaces
Detalles de las varias caractersticas de administracin de la congestin de TCP se pueden encontrar

en RFC 2581.
http://www.ietf.org/rfc/rfc2581.txt
UDP: Baja sobrecarga vs.

Confiabilidad
UDP es un protocolo simple que provee las funciones bsicas de la capa de Transporte. Genera
mucho menos sobrecarga que TCP, ya que no es orientado a la conexin y no cuenta con los
sofisticados mecanismos de retransmisin, secuenciacin y control del flujo.
Esto no significa que las aplicaciones que utilizan UDP no sean confiables. Slo quiere decir que
estas funciones no son contempladas por el protocolo de la capa de Transporte y deben
implementarse aparte, si fuera necesario.
Pese a que es relativamente baja la cantidad total de trfico UDP que puede encontrarse en una red
tpica, entre los protocolos principales de la capa de Aplicacin que utilizan UDP se incluyen:
sistema de denominacin de dominio (DNS),
protocolo simple de administracin de red (SNMP),
protocolo de configuracin dinmica de host (DHCP),
protocolo de informacin de enrutamiento (RIP),
protocolo trivial de transferencia de archivos (TFTP), y
juegos en lnea.
Algunas aplicaciones como los juegos en lnea o VoIP

pueden tolerar algunas prdida de datos. Si estas
aplicaciones utilizaran TCP, experimentaran largas
demoras, ya que TCP detecta la prdida de datos y los
retransmite. Estas demoras seran ms perjudiciales para la
aplicacin que las pequeas prdidas de datos. Algunas
aplicaciones, como DNS, simplemente reintentan enviar la
solicitud si no obtienen respuesta y, por lo tanto, no
necesitan TCP para garantizar la entrega del mensaje.
La baja sobrecarga de UDP lo hacen deseable para dichas
aplicaciones.
Reensamblaje de Datagramas
Ya que UDP opera sin conexin, las sesiones no se establecen antes de que se lleve a cabo la
comunicacin, como sucede con TCP. Se dice que UDP es basado en transacciones. En otras
palabras, cuando una aplicacin posee datos para enviar, simplemente los enva.
Muchas aplicaciones que utilizan UDP envan pequeas cantidades de datos que pueden ocupar un
segmento. Sin embargo, algunas aplicaciones enviarn cantidades mayores de datos que deben
dividirse en varios segmentos. La PDU de UDP se conoce como datagrama, pese a que los trminos
segmento y datagrama a veces se utilizan de manera indistinta para describir una PDU de la capa de
Transporte.
Cuando se envan mltiples datagramas a un destino, los mismos pueden tomar rutas distintas y
llegar en el orden incorrecto. UDP no mantiene un seguimiento de los nmeros de secuencia de la
manera en que lo hace TCP. UDP no puede reordenar los datagramas en el orden de la transmisin.
Ver la figura.
Por lo tanto, UDP simplemente reensambla los datos en el orden en que se recibieron y los enva a
la aplicacin. Si la secuencia de los datos es importante para la aplicacin, la misma deber
identificar la secuencia adecuada de datos y determinar cmo procesarlos.
Procesos y solicitudes del servidor

UDP
Al igual que las aplicaciones basadas en TCP, a las aplicaciones de servidor

basadas en UDP se les asigna nmeros de puerto bien conocidos o registrados.
Cuando se ejecutan estas aplicaciones o procesos, aceptan los datos que
coincidan con el nmero de puerto asignado. Cuando UDP recibe un datagrama
destinado a uno de esos puertos, enva los datos de aplicacin a la aplicacin
adecuada en base a su nmero de puerto.
Procesos de cliente UDP
Como en TCP, la comunicacin cliente/servidor se inicia por una aplicacin cliente que solicita datos
de un proceso del servidor. El proceso de cliente UDP selecciona al azar un nmero de puerto del
rango dinmico de nmeros de puerto y lo utiliza como puerto de origen para la conversacin. El
puerto de destino por lo general ser el nmero de puerto bien conocido o registrado asignado al
proceso del servidor.
Los nmeros de puerto de origen seleccionados al azar colaboran con la seguridad. Si existe un
patrn predecible para la seleccin del puerto de destino, un intruso puede simular el acceso a un
cliente de manera ms sencilla intentando conectarse al nmero de puerto que tenga mayor
posibilidad de estar abierto.
Ya que no se crean sesiones con UDP, tan pronto como los datos estn listos para ser enviados y los
puertos estn identificados, UDP puede formar el datagrama y enviarlo a la capa de Red para
direccionamiento y envo a la red.
Cabe recordar que una vez que el cliente ha elegido los puertos de origen y destino, estos mismos
puertos se utilizarn en el encabezado de todos los datagramas que se utilicen en la transaccin.
Para la devolucin de datos del servidor al cliente, se invierten los nmeros de puerto de origen y
destino en el encabezado del datagrama.
Referencias
Cisco CCNA1 Exploration Capitulo 3
Manual de Laboratorio Cisco CNNA1

Idioma

¡Te damos la bienvenida a Scribd!

Redes De Computadora I: Msc. Carlos Bosquez

Cargado por

Información del documento

Descripción:

Fecha en que fue cargado

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Descripción:

Copyright:

Formatos disponibles

Redes De Computadora I: Msc. Carlos Bosquez

Título original:

Cargado por

Descripción:

Copyright:

Formatos disponibles

Títulos relacionados

Redes de Computadora I

MSc. Carlos Bosquez

Ing. Carlos Bosquez - UPS-GYE

Servicios y Protocolos de capa de

Ing. Carlos Bosquez - UPS-GYE

Ing. Carlos Bosquez - UPS-GYE

Ing. Carlos Bosquez - UPS-GYE

El rol de la capa de transporte

Ing. Carlos Bosquez - UPS-GYE

La capa de transporte proporciona un mtodo para

Ing. Carlos Bosquez - UPS-GYE

Ing. Carlos Bosquez - UPS-GYE

Rastreo de conversaciones individuales

Segmentacin de datos y rearmado de segmentos

Ing. Carlos Bosquez - UPS-GYE

Ing. Carlos Bosquez - UPS-GYE

Ing. Carlos Bosquez - UPS-GYE

Identificacin de las aplicaciones

Ing. Carlos Bosquez - UPS-GYE

Los requerimientos de datos varan

Ing. Carlos Bosquez - UPS-GYE

Ing. Carlos Bosquez - UPS-GYE

El envo de algunos tipos de datos (por ejemplo, un streaming video) a travs de

Ing. Carlos Bosquez - UPS-GYE

Confiabilidad de la capa de transporte

Ing. Carlos Bosquez - UPS-GYE

Ing. Carlos Bosquez - UPS-GYE

Protocolo de datagramas de usuario

Ing. Carlos Bosquez - UPS-GYE

Protocolo de control de transmisin

Ing. Carlos Bosquez - UPS-GYE

Ing. Carlos Bosquez - UPS-GYE

Direccionamiento del puerto

Identificacin de las conversaciones

Considere el ejemplo anterior de una computadora que recibe y enva e-mails,

Los servicios basados en TCP y UDP mantienen un seguimiento de las varias

En el encabezado de cada segmento o datagrama hay un puerto de origen y

Ing. Carlos Bosquez - UPS-GYE

Los nmeros de puerto se asignan de varias maneras, en funcin de si el mensaje

Ing. Carlos Bosquez - UPS-GYE

El puerto de origen del encabezado de un segmento o datagrama de un cliente se

La combinacin del nmero de puerto de la capa de Transporte y de la direccin IP

Por ejemplo, una solicitud de pgina Web HTTP

Ing. Carlos Bosquez - UPS-GYE

La Autoridad de nmeros asignados de Internet (IANA) asigna nmeros de puerto. IANA es un

Existen distintos tipos de nmeros de puerto:

Ing. Carlos Bosquez - UPS-GYE

Puertos dinmicos o privados (Nmeros del 49 152 al 65 535): tambin conocidos

Utilizacin de los dos protocolos TCP y UDP

Se puede encontrar un lista actual de

Ing. Carlos Bosquez - UPS-GYE

Ing. Carlos Bosquez - UPS-GYE

Ing. Carlos Bosquez - UPS-GYE

A veces es necesario conocer las conexiones TCP activas que estn

Ing. Carlos Bosquez - UPS-GYE