La Capa de Transporte-2 PDF

Universidad Científica del Perú Facultad de Ciencias e Ingeniería
Sistemas de Comunicación de Datos

LA CAPA DE TRANSPORTE
INTRODUCCIÓN
El modelo de trasporte constituye el núcleo del modelo OSI. Los protocolos de este nivel de
encargan de la entrega de datos desde un programa de aplicación situado en un dispositivo a
otro programa de aplicación situado en otro dispositivo. Más importante aún, actúan como un
enlace entre protocolos de los niveles superiores (sesión, presentación y de aplicación) y los
servicios ofrecidos por los niveles inferiores (de red, de enlace de datos y físico). Los niveles
superiores pueden utilizar los servicios del nivel de transporte para interactuar con la red sin
tener que interactuar o preocuparse directamente con la existencia de niveles inferiores. Para
que esta separación sea posible, el nivel de transporte es independiente de la red física.
En este contexto, la capa de transporte del modelo TCP/IP posee dos protocolos: TCP y UDP.
TCP (Transmisión Control Protocol) es un protocolo orientado a la conexión y confiable. UDP
(User Datagram Protocol) es un protocolo no orientado a la conexión y no confiable. Algunos
autores señalan que UDP es sólo una extensión de IP. Se discutirá ello posteriormente.
TCP es un protocolo que proporciona una conexión confiable de extremo a extremo (E2E)
Tanto éste como su colega UDP se encapsulan en el protocolo IP, el cual, como ya se ha
mencionado en el módulo anterior, es un protocolo no orientado a la conexión y no confiable,
basado en la política del best effort. TCP surge entonces como una alternativa que soluciona el
problema de la ausencia de una conexión confiable entre los dos extremos que establecen una
comunicación.
SERVICIOS DEL NIVEL DE TRANSPORTE
Para comprender mejor el papel del nivel de transporte, es útil visualizar una Internet formada
por variedad de redes físicas diferentes como las LAN, MAN o WAN mostradas en la Fig. 5.1
Estas redes se conectan para permitir el transporte de datos desde una computadora de una
red a otra computadora situada en otra red. Cuando la transmisión se transfiere de red a red,
los datos pueden ser encapsulados en diferentes tipos y longitudes de paquetes.
Las funciones del nivel de enlace o de red de una red pueden fraccionar los datos en
segmentos más pequeños para que entren en un tamaño de paquete o trama más limitado,
mientras que las funciones paritarias de otra red pueden enlazar varios segmentos juntos en un
único gran paquete. No importa que transformaciones deban realizarse; sin embargo, los datos
deben llegar a su destino en su formato original.
Ing. Jorge Danilo Jara Vela Página 1

Los protocolos de los niveles superiores son ajenos a problemas o características de las redes
físicas, por lo que sólo tiene que desarrollarse un pequeño software de nivel superior. Para los
niveles superiores, las redes físicas individuales son la simple nube homogénea, que de alguna
forma toma los datos y los entrega a su destino de forma segura. Por ejemplo, incluso si en una
Internet se sustituye una red Ethernet por una red en anillo con paso de testigo, los niveles
superiores son ajenos a este cambio. El nivel de transporte ofrece esta transparencia.
Los servicios del nivel de transporte son implementados por un protocolo de transporte utilizado
entre dos entidades de transporte (Fig. 5.2)
Los servicios ofrecidos son similares a los ofrecidos por el nivel de enlace de datos. El nivel de
enlace de datos, sin embargo, está diseñado para ofrecer sus servicios dentro de una única
red, mientras que el nivel de transporte ofrece los servicios a lo largo de un conjunto de redes
interconectadas.
El nivel de enlace de datos controla el nivel físico, mientras que el nivel de transporte controla
los tres niveles inferiores (Fig. 5.3).

Los servicios ofrecidos por los protocolos de nivel de transporte se pueden dividir en
cinco amplias categorías y son:
 entrega extremo a extremo

 direccionamiento
 entrega fiable
 control de flujo y
 multiplexación
Entrega extremo a extremo
El nivel de red se encarga de la entrega extremo a extremo de paquetes individuales, pero no

ve ninguna relación entre estos paquetes, incluso aunque pertenezcan al mismo mensaje.
Trata a cada paquete como una entidad. El nivel de transporte, por otro lado, se asegura de
que el mensaje entero (no sólo un paquete) llegue intacto. De esta forma, se encarga de la
entrega de extremo a extremo (origen a destino) de un mensaje entero.
Direccionamiento
El nivel de transporte interactúa con las funciones del nivel de sesión. Sin embargo, muchos
protocolos (como pilas de protocolos, que significa grupos de protocolos que interactúan en
niveles diferentes) combinan protocolos de nivel de sesión, presentación y aplicación. En estos
casos, la entrega a funciones de nivel de sesión es, en realidad, la entrega a una aplicación.
Por ello, la comunicación tiene lugar no solo de una máquina a otra máquina, sino de una
aplicación a otra aplicación. Los datos generados por una aplicación de una máquina deben ser
recibidos no sólo por la otra máquina, sino por la aplicación correcta dentro de la máquina.
En la mayoría de los cados, por tanto, terminamos con la comunicación entre muchas a
muchas entidades, denominadas puntos de acceso al servicio (véase Fig. 5.4). Pero, ¿cómo se
identifica la red qué punto de acceso a servicio en una estación está comunicándose con qué
punto de acceso a servicio en otra estación?
Para asegurar la entrega precisa de un punto de acceso a servicio a otro, se necesita otro nivel
de direccionamiento además de los utilizados en los niveles de red y enlace de datos. Los
protocolos de nivel de enlace de datos necesitan conocer que dos computadoras dentro de una
red se están comunicando. Los protocolos de nivel de red necesitan conocer que dos
computadoras dentro de Internet se están comunicando. Pero en el nivel de transporte, el
protocolo necesita conocer qué protocolos de nivel superior se están comunicando.

Entrega fiable
En el nivel de transporte, la entrega fiable tiene cuatro aspectos: control de errores, control de
secuencia, control de pérdidas y control de duplicación.
 Control de errores
Cuando se transfieren datos, el principal objetivo de la fiabilidad es el control de errores. Como

se dijo anteriormente, los datos deben ser entregados a su destino en la misma forma en la que
se originaron en el origen. Mientras que en el transporte de datos físicos, una entrega libre de
errores al 100 por 100 es probablemente imposible, los protocolos de nivel de transporte están
diseñados para que esta probabilidad sea lo más cercana posible. Los mecanismos para el
tratamiento de errores en este nivel se basan en la detección de errores y en la retransmisión.
Este manejo de errores normalmente se realiza por algoritmos implementados en software,
tales como suma de comprobación.
Pero si tenemos que tratar errores en el nivel de enlace de datos, ¿por qué se necesita
el nivel de transporte? Las funciones del nivel de enlace de datos garantizan la entrega
libre de errores nodo a nodo para cada enlace. Sin embargo, la fiabilidad nodo a nodo
no asegura la fiabilidad extremo a extremo. La Fig. 5.5 muestra una situación en la que
un error introducido no puede ser tratado por los controles de error que realiza el nivel
de enlace de datos. En la Fig. 5.5, el nivel de enlace de datos se encarga de que los
paquetes que pasan de una red a otra se encuentren libres de errores. Pero se
introduce un error cuando el paquete es procesado dentro de los encaminadores. Este
error no será detectado por las funciones que sólo comprueban que no se hayan
introducido errores entre el comienzo y el fin de ese enlace. En nivel de transporte
debe, por tanto, hacer su propia comprobación extremo a extremo para estar seguro de
que el paquete ha llegado tal y como fue enviado por el origen.
 Control de secuencia
El segundo aspecto de la fiabilidad implementada por el nivel de transporte es el control

de secuencia. En el extremo emisor, el nivel de transporte es responsable de asegurar
que las unidades de datos recibidas desde los niveles superiores son utilizables por los
niveles inferiores. El extremo receptor, debe encargarse de asegurar que los distintos
trozos de una transmisión son reensamblados correctamente.

 Segmentación y concatenación
Cuando el tamaño de la unidad de datos recibida desde el nivel superior es demasiado

grande para el datagrama utilizado en el nivel de red y la trama del nivel de enlace de
datos, el nivel de transporte la divide en bloques más pequeños. El proceso de división
se denomina segmentación. Cuando, por otro lado, el tamaño de las unidades de datos
que pertenecen a una misma sesión es tan pequeño que varias de ellas caben en un
único datagrama o trama, el protocolo de transporte las combina en una única unidad
de datos. El proceso de combinación se denomina concatenación.
 Número de secuencia
La mayor parte de los servicios de nivel de transporte añaden un número de secuencia

al final de cada segmento. Si la unidad de datos más grande ha sido segmentada, los
números indican el orden para el reensamblado. Si varias unidades más han sido
concatenadas, los números indican el final de cada subunidad y permiten ser
separadas de forma más precisa en el destino. Además, cada segmento transporta un
campo que indica si el segmento es el final de una transmisión o aún quedan más
segmentos.
Imagine una situación en la que un cliente de un banco envía un mensaje al banco para
ordenar que primero transfiera 5000 euros desde una cuenta corriente de otro cliente.
Imagínese lo que ocurriría si las dos partes del mensaje fueran recibidas fuera de orden
(Fig. 5.6).
Desde el punto de vista del emisor y del receptor, no es importante en qué orden viajen
los distintos trozos de la transmisión. Lo que es importante es que se reensamblen de
forma adecuada en el destino, de igual forma en la que las piezas de su coche llegan a
la cadena de montaje, sino que lo que quiere es que estén montadas adecuadamente
cuando a usted le entreguen el coche.

 Control de perdidas
El tercer aspecto de la fiabilidad cubierto por el nivel de transporte es el control de

pérdidas. El nivel de transporte se asegura de que todos los trozos de una transmisión
lleguen a su destino, no sólo unos cuantos. Cuando los datos han sido segmentados
para la entrega, algunos segmentos pueden perderse durante el tránsito (Fig. 5.7). Los
números de secuencia permiten al receptor identificar cualquier segmento perdido y
solicitar que sea reenviado.
 Control de duplicados
El cuarto aspecto de la fiabilidad cubierto por el nivel de transporte es el control de

duplicados. Las funciones del nivel de transporte deben garantizar que ningún
segmento de datos llegue al sistema receptor duplicado. Al igual que permiten
identificar los paquetes perdidos, los números de secuencia también permiten al
receptor identificar y descartar los segmentos duplicados.
La duplicación puede parecer un problema trivial, pero puede tener importantes

consecuencias. Imagine que el cliente del banco envía un mensaje indicando al banco
que transfiera 5000 euros desde su cuenta a la de Juan. ¿Qué ocurre si se duplica este
mensaje? Véase la Fig. 5.8

 Control de flujo
Al igual que el nivel de enlace de datos, el nivel de transporte es responsable del

control de flujo. Sin embargo, el control de flujo en este nivel se realiza extremo a
extremo en lugar de enlace a enlace. El control de flujo en el nivel de transporte
también utiliza protocolo de ventana deslizante. Sin embargo, la ventana en el nivel de
transporte puede variar en tamaño según la ocupación del buffer.
Con una ventana de tamaño variable, la cantidad de datos real que la ventana puede
almacenar es negociable. En la mayoría de los casos, el control del tamaño de la
ventana es competencia del receptor. El receptor, en su paquete de confirmación,
puede especificar que el tamaño de la ventana se ha incrementado (o disminuido, pero
en la mayoría de los protocolos no permiten disminuir el tamaño). En la mayoría de los
casos, las ventanas deslizantes en el nivel de transporte se basan en el número de
bytes que el receptor puede almacenar en lugar del número de tramas. Un par de
entidades que se comunican utilizan un buffer de 'x' bytes que puede almacenar 'y'
tramas.
Se utiliza una ventana deslizante para hacer que la transmisión de los datos sea más
eficiente, así como para controlar el flujo de datos de forma que el receptor no se
sature. Las ventanas deslizantes utilizadas en el nivel de transporte están normalmente
orientadas a byte en lugar de a tramas.
A continuación se citan algunos puntos relacionados con las ventanas deslizantes en el

nivel de transporte:
 El emisor no tiene que enviar los datos de la ventana completa.

 Una confirmación puede expandir el tamaño de la ventana de acuerdo al número
de secuencia del segmento de datos confirmados.
 El tamaño de la ventana puede ser incrementado o disminuido por el receptor.
 El receptor puede enviar una confirmación en cualquier instante.

Para hacer frente a la variabilidad en tamaños, las ventanas deslizantes del nivel de
transporte utilizan tres punteros (que actúan como barreras virtuales) para identificar el
buffer (Fig. 5.9). La barrera de la izquierda se mueve hacia la derecha cuando se recibe
una confirmación. La barrera central se mueve a la derecha cuando se envían datos.
La barrera de la derecha se mueve a la izquierda para fijar el tamaño de la ventana. Si
se recibe una confirmación y el tamaño de la ventana no cambia, esta tercera barrera
se mueve a la derecha para mantener constante el tamaño de la ventana (debido a que
la barrera de la izquierda se ha movido a la derecha). Por ejemplo, si se confirman
cinco bytes y el tamaño de la ventana no cambia, entonces la barrera de la izquierda se
mueve a la derecha cinco bytes, reduciendo la ventana, por lo que la barrera de la
izquierda se mueve a la derecha cinco bytes para que el tamaño de la ventana
permanezca constante. Si se confirman 5 bytes pero el receptor también incrementa el
tamaño de la ventana en 10 bytes, la barrera de la derecha debe moverse 15 bytes a la
derecha para alojar el nuevo tamaño.
 Multiplexación
Para mejorar la eficiencia de la transmisión, el nivel de transporte tiene la opción de

multiplexar. La multiplexación en este nivel se lleva a cabo de dos formas: hacia arriba,
lo que significa que varias conexiones del nivel de transporte utilizan la misma conexión
de red, o hacia abajo, lo que significa que una conexión de nivel de transporte utiliza
varias conexiones de red (Fig. 5.10).
o Multiplexación hacia arriba

El nivel de transporte utiliza circuitos virtuales basados en los servicios de los tres
niveles inferiores. Normalmente, las redes subyacentes cobran por cada conexión
de un circuito virtual. Para hacer más efectivo el coste del establecimiento de un
circuito, el nivel de transporte puede enviar varias transmisiones para un mismo
destino por el mismo camino utilizando multiplexación hacia arriba. Esto significa
que si el protocolo de red subyacente tiene altas prestaciones, por ejemplo en el
rango de 1 Gbps, y el usuario puede crear datos sólo en el rango de los Mbps,
varios usuarios pueden compartir una conexión de red.
o Multiplexación hacia abajo

Permite al nivel de transporte separar una única conexión entre varios caminos
diferentes para mejorar el rendimiento (velocidad de la entrega). Esta opción es útil
cuando la red subyacente es lenta o tiene baja capacidad. Por ejemplo, algunos
protocolos de nivel de red tienen restricciones sobre los números de secuencia que
pueden ser manejados. X.25 utiliza un código de numeración de tres bits, por lo que
los números de secuencia están restringidos en el rango de 0 a7 (sólo ocho
paquetes pueden ser enviados antes que se requiera una confirmación). En este
caso, el rendimiento puede ser inaceptablemente bajo. Para resolver este problema,
el nivel de transporte puede optar por utilizar más de un circuito virtual del nivel de
red para mejorar el rendimiento. Enviando varios segmentos de datos a la vez, la
entrega en más rápida (Fig. 5.10)

CONEXIÓN
La entrega extremo a extremo puede llevarse a cabo de dos formas: con conexión o sin
conexión. De estos dos, el modo orientado a conexión establece un circuito virtual o camino a
través de Internet entre el emisor y el receptor. Todos los paquetes que pertenecen a un mismo
mensaje son enviados por este mismo camino. El empleo de un único camino para el mensaje
entero facilita el proceso de confirmación y retransmisión de tramas perdidas o dañadas. Los
servicios orientados a conexión, por tanto, se consideran generalmente como fiables.
La transmisión orientada a conexión consta de tres pasos: establecimiento de conexión,

transferencia de datos y terminación de la conexión.
 Establecimiento de la conexión
Antes de que un dispositivo pueda enviar datos a otro, el dispositivo que inicia
la transmisión debe determinar en primer lugar la disponibilidad del otro para
intercambiar los datos y debe encontrar un camino en la red a través del cual
enviar los datos. Esta etapa se conoce como establecimiento de conexión (Fig.
5.11)
El establecimiento de la conexión requiere tres acciones que se denominan
diálogo en tres partes:
o La computadora que solicita la conexión envía un paquete de petición de
conexión al receptor.
o La computadora receptora devuelve un paquete de confirmación a la
computadora que realiza la solicitud.
o La computadora que realiza la solicitud devuelve un paquete para
confirmar la confirmación.
 Terminación de la conexión

Una vez que todos los datos han sido transferidos, la conexión se debe
terminar (Fig. 5.12). La terminación de la conexión también requiere un diálogo
en tres partes:
o La computadora solicitante envía un paquete de desconexión.

o La computadora receptora confirma el paquete de desconexión.
o La computadora solicitante confirma el paquete de confirmación
TRANSMISSION CONTROL PROTOCOL (TCP)
Cuestiones previas
TCP vio la luz gracias al RFC 793. El lector recordará que IP nació en un RFC anterior pero
cercano, el 791. Tanto TCP como IP fueron definidos el 01 de septiembre de 1981.
Específicamente en el caso de TCP, el protocolo evolucionó, dando origen al RFC 1122, al
RFC 1323 y a muchos otros más recientes. IP también evolucionó, pero dio el gran salto recién
con el RFC 2460, que marca el origen del Ipv6 en 1998.
¿Cómo accede una aplicación a TCP?
El lector posiblemente se vea abrumado con esta pregunta. Tal vez la interrogante idónea sería
¿CUÁLES SON LAS APLICACIONES QUE ACCEDEN A TCP? Incluso el lector más lego ha
tenido oportunidad de manejar personalmente aplicaciones: accede a su página web desde la
comodidad de su escritorio; posiblemente ha accedido a una PC remota empleando TELNET o
incluso ha configurado un router empleando esta aplicación, o tal vez ha realizado una
transferencia de archivos entre dos laptops de la oficina utilizando FTP, etc.
Las aplicaciones se basan en protocolos. Entre los protocolos de aplicación que hacen uso de
TCP (es decir, se encapsulan en TCP) se tienen los siguientes: BGP, FTP, HTTP, SMTP,
TELNET, MIME, etc.

Ahora es buen momento para describir cómo accede una aplicación a TCP. Cuando un
proceso de aplicación, o más sencillamente, una aplicación desarrollándose en un host desea
establecer conexión con otra aplicación que se lleva a cabo en otro host, la capa de aplicación
de la máquina transmisora y de la receptora deben definir puntos terminales denominados
SOCKETS. El lector se preguntará ¿y por qué los SOCKETS? Los SOCKETS son los puntos
que permiten a las aplicaciones acceder al servicio TCP cuando éstas requieren encapsularse
en dicho protocolo. Dicho en buen romance, la interfaz o la puerta de entrada entre la capa de
aplicación y la capa de transporte se denomina SOCKET. Por el momento, la atención estará
centrada sólo en TCP.
Cada SOCKET posee un número o una dirección de SOCKET, la cual está constituida por la
dirección IP del host y un número de 16 bits local a ese host, denominado PUERTO. En TCP,
PUERTO es el nombre de un TSAP (TRANSPORT SERVICE ACCESS POINT) Para obtener el
servicio TCP, debe establecerse explícitamente una conexión entre el SOCKET de la máquina
transmisora y el SOCKET de la máquina receptora. Para complementar esta parte, recordar
que SOCKET es un concepto lógico ligado a Informática.
Un SOCKET puede emplearse para varias conexiones al mismo tiempo. En otras palabras, dos
o más conexiones pueden confluir en un mismo SOCKET. Por otro lado, las conexiones se
identifican exclusivamente con los números de SOCKET de los dos host, o sea, (SOCKET 1,
SOCKET 2).
Los PUERTOS 0 al 255 se denominan WELL-KNOWN PORTS y se reservan para servicios

estándar. Un ejemplo de servicio estándar es el FTP. Cuando un host desee establecer una
conexión FTP para transferir un archivo a otro host, en primer lugar deberá establecer una
conexión con el PUERTO 21 del host remoto y así acceder a su DAEMON o PROCESO
REENTRANTE en español, de FTP.
Toda conexión TCP es dúplex integral y punto a punto. Dúplex integral quiere decir que la
comunicación puede fluir simultáneamente en ambos sentidos. Punto a punto se refiere a que
las conexiones se estructuran sólo de extremo a extremo, o expresado de otra manera, sólo
entre dos puntos terminales. TCP ignora de qué se trata la multitransmisión y la difusión.
Una conexión TCP está constituida por una corriente de BYTES, no de MENSAJES. Los límites
de mensajes no se conservan de extremo a extremo. Por ejemplo, si una aplicación genera
cuatro mensajes de 512 bytes cada uno, TCP puede llevarlos a la aplicación de destino
respetando los límites originales de los mensajes, como también puede llevarlos como dos
mensajes de 1024 bytes o como un solo mensaje de 2048 bytes. El lector debe recordar que
en el modelo TCP/IP la capa de aplicación y la de transporte intercambian mensajes. Asunto
aparte es si TCP respeta el formato de separación original de los mensajes o no para llevarlos
a la aplicación de destino. En conclusión, la aplicación receptora no tiene forma de enterarse
acerca de cuántas partes poseía el mensaje original. No tiene tampoco porqué saberlo. La
capa de aplicación, por cierto, se abstrae de lo que ocurre en la de transporte. Cuando un
usuario abre su página web favorita detalles como éstos no le interesan en lo más mínimo.
Los lectores que en cuanto a conocimientos consideren aventajar con creces a los encargados
de elaborar este material, posiblemente estén familiarizados con UNIX. Por ejemplo, en el caso
de un usuario UNIX éste no tiene forma de saber si el mensaje original fue enviado por TCP,
bloque por bloque, byte por byte, o de una sola ráfaga. Y siguiendo la política de la abstracción
de capas, si a la capa de aplicación no le interesa lo mencionado, mucho menos a la capa de
transporte le interesará el tipo de dato que transporta. TCP sólo se interesará en la información
de su cabecera, de la cual se hablará más adelante.

Cuando una aplicación envía datos a TCP, éste puede decidir si enviarlos de inmediato o
almacenarlos en un buffer a la espera de más información que enviar. Sin embargo, si lo
desea, la aplicación puede negociar con TCP este punto. Supóngase que el lector es experto
configurando ROUTERS y se encuentra realizando una sesión TELNET desde su computadora
portátil hacia un ROUTER para efectuar algunos cambios en este dispositivo. Desde luego,
cuando el que configura envíe un comando al ROUTER, para, por ejemplo, obtener información
acerca de la dirección IP del puerto WAN que enlaza el ROUTER con otro ubicado en la central
de operaciones, el que configura desea saber en tiempo real, vale decir, obtener en ese mismo
instante, la información deseada. Es en ocasiones como ésta que la aplicación debe negociar
con TCP (más aun, se trata de una aplicación TELNET) para que éste envíe de inmediato el
pedido de información al ROUTER. Ya en el terreno de los tecnicismos, la aplicación emplea un
FLAG en la cabecera TCP denominado PUSH para ordenar a TCP no tomarse la molestia de
aguardar por más información, sino de enviarla inmediatamente. A manera de comentario final,
configurar un ROUTER mediante TELNET es un ingenioso ardid cuando el ROUTER niega
cualquier posibilidad de acceso físico, debido quizá a que no existen puertos LAN libres y
desconectar éstos, sólo para complacer al que configura, representaría una locura.
¿Y si para acelerar las cosas se empleara siempre el FLAG PUSH? A priori podría pensarse en
acelerar la descarga de una página web desde un servidor remoto ordenando la aplicación de
usuario al TCP acelerar el pedido. De igual modo, algo parecido debe efectuar la aplicación en
el lado del servidor. Las aplicaciones pueden exigir todo lo que deseen, pero aún no se ha
inventado, al parecer, un protocolo que les recuerde que Internet posee limitaciones. Una
limitación práctica, ya que se ha hablado de ROUTERS, es el encolamiento que tiene lugar en
estos dispositivos, ya que no sólo se las tienen que arreglar con el paquete del apresurado
usuario que solicita su página web, sino con paquetes de toda índole, tal vez miles de éstos.
TCP resuelve fácilmente este asunto. Si el mensaje llegó, por ejemplo, en cuatro partes, y cada
una desea encapsularse en TCP con el FLAG PUSH activo, TCP considera las cosas y de
observar que el TCP del servidor web remoto no puede responder con rapidez (posiblemente
los ROUTERS están de malas leyendo miles de cabeceras y enrutando miles de paquetes),
efectúa una negociación entre las capas pares y el TCP emisor toma la decisión de juntar en un
solo datagrama IP todos los fragmentos del mensaje y enviarlos en cuanto los ROUTERS se
encuentren en condiciones de atender al datagrama IP. El ejemplo propuesto es algo empírico
pero ilustra de manera práctica el empleo del FLAG PUSH. Sin embargo, este ejemplo es
propicio para señalar que una de las funciones más importantes de TCP es llevar a cabo el
control de flujo, es decir, evitar que un emisor rápido sature a uno lento. Se deja la
interpretación en manos del lector.
Funcionamiento del protocolo TCP
Como ya se ha mencionado, un proceso TCP en un host emisor toma de manera

independiente una decisión acerca de sí respetar el formato del mensaje proveniente de la
aplicación y enviarlo como un bloque o segmentarlo. En cualquier caso, TCP debe tener en
cuenta que los segmentos del mensaje deberán encapsularse en IP, y por lo tanto, el tamaño
total de la cabecera y los datos de TCP no deberán exceder los 65535 bytes que puede
transportar como máximo el paquete IP.
En la próxima sección se estudiarán en detalle los campos que constituyen la cabecera TCP, la
cual consta de 20 bytes. El objetivo, por el momento, es esbozar el funcionamiento de TCP
para luego entrar en los detalles técnicos de la cabecera.
Sin embargo, se debe tener en cuenta que si bien el paquete IP soporta 65535 bytes en total,
las redes poseen un parámetro denominado MTU (MAXIMUM TRANSFER UNIT) Supóngase
que un dispositivo de red desea enviar los datagramas IP a través de una red ETHERNET, la
cual posee un MTU de 1500 bytes. De este modo, IP deberá fragmentar la información en
datagramas de 1500 bytes (cabecera y datos de IP) con los que la capa de interfaz de red
formará las tramas ETHERNET que serán enviadas al medio físico.

En este punto el lector se preguntará por qué se ha mencionado todo este proceso. Muy
sencillo.
Por que la fragmentación introduce cabeceras que empobrecen la relación CONTROL /

DATOS, lo que hace ineficiente la red. Se introducen tantas cabeceras como segmentos del
mensaje original cree TCP, tantas también como datagramas estructure IP y así
sucesivamente. TCP debe estar preparado para lidiar con una situación como ésta y tomar la
mejor decisión.
El protocolo básico empleado por TCP es el de ventana corrediza. Cuando un proceso TCP en
el extremo emisor envía la información al proceso TCP en el receptor inicia un temporizador; el
receptor deberá generar un acuse de recibo en el que solicite el siguiente segmento del
mensaje, incorporando de paso datos, de ser necesario. Si el temporizador del transmisor
expira antes de recibirse el acuse de recibo, se reenvía el segmento. Resulta evidente que TCP
al emplear como protocolo básico el de ventana corrediza, desempeña como una de sus más
importantes funciones el control de flujo.
El funcionamiento de TCP parece sencillo. El lector que desee simplificar las cosas ya habrá
inferido que TCP posee dos funciones esenciales: la primera, establecer una conexión
confiable E2E, y la segunda, llevar a cabo el control de flujo de dicha conexión.
Sin embargo, Internet es un escenario donde pululan los problemas. El primer embrollo surge
por default, vale decir, que cae por su propio peso: TCP, un protocolo orientado a la conexión y
confiable, debe encapsularse en IP, el cual no es orientado a la conexión y mucho menos
confiable. Esto se traduce en las siguientes dificultades que deberá arrostrar TCP: los paquetes
que viajan por la red lo hacen de manera independiente, así que unos llegarán pero otros no.
Podría suceder que el receptor emita un acuse de recibo de un paquete, pero no pueda hacer
lo propio con otro que jamás llegó. Puede ocurrir que los acuses se extravíen en el camino,
provocando la retransmisión de duplicados y un largo etc. TCP debe estar preparado para
resolver estos problemas de manera eficiente.
La cabecera TCP
La cabecera TCP posee una longitud fija de 20 bytes, la cual puede estar seguida de opciones
de cabecera si las hay. La longitud máxima de la parte de datos es de 65495 bytes. En
resumen, un segmento TCP tiene como longitud fija 65515 bytes. Ahora se realizará el análisis
de la cabecera TCP campo por campo (véase Fig. 5.13).

Descripción de los Campos
o PUERTO DE ORIGEN Y PUERTO DE DESTINO (SOURCE PORT AND DESTINATION

PORT):
Identifican los puntos terminales locales de una conexión. Cada host puede elegir por
cuenta propia sus propios números de puerto a partir del 256. El número de puerto consta
de 16 bits, y junto con la dirección IP del host (32 bits) identifican el número de SOCKET,
el cual posee 48 bits.
o NÚMERO DE SECUENCIA Y NÚMERO DE RECONOCIMIENTO (SEQUENCE NUMBER

AND ACKNOWLEDGEMENT):
El número de secuencia identifica el número de segmento enviado. El número de

reconocimiento especifica el siguiente segmento esperado y no el correctamente recibido.
Ambos poseen 32 bits.
o LONGITUD DE CABECERA TCP (TCP HEADER LENGTH):
Indica el número de palabras de 32 bits que conforman la cabecera. De este modo, si este
campo indica que la longitud de la cabecera es de 5, entonces ésta posee (5 x 4 bytes) =
20 bytes. Recordar que debido a la existencia del campo opciones la longitud de la
cabecera puede variar.
A continuación de este campo viene uno de 06 bits vacío. Se utilizará en el futuro de tener
que realizar modificaciones en el diseño de la cabecera TCP original.
o FLAG URG:
El lector familiarizado con UNIX posiblemente haya utilizado la interrupción de un cómputo

remoto para enviar datos urgentes al receptor. Los lectores acostumbrados en cuestiones
de más bajo nivel como ASSEMBLER tal vez recuerden con nostalgia la famosa INT 21H.
Aunque actualmente la programación orientada a objetos es el paradigma bajo el cual se
rige la programación moderna, no está demás hacer un poco de historia para presentar a
este FLAG URG (FLAG URGENT) de tan sólo 1 bit como todos los FLAGS que se verán
también. FLAG URG libra a TCP de realizar las funciones de interrupción dejando esto en
manos de la aplicación. Con la interrupción, la aplicación detiene a TCP, le ordena que
envíe rápidamente lo que tiene entre manos y a continuación se procede a enviar los
datos urgentes. Una vez que esto concluye, todo vuelve a la normalidad. Por otro lado, si
FLAG URG parece a los ojos del lector bisoño un campo obsoleto, recuérdese que TCP
nació en 1981. Han transcurrido ya 28 años.
o FLAG ACK (ACKNOWLEDGE):
Si se encuentra en 1 quiere decir que el número de reconocimiento o de acuse de recibo

es válido. De estar en cero, se interpreta que el segmento no posee un acuse de recibo,
por lo que se ignora el campo del mismo nombre.
o FLAG PSH:
Cuando este FLAG se encuentra activo, el receptor está obligado a entregar de inmediato
el mensaje a la aplicación y no guardarlo en un buffer.
o FLAG RST:
Se emplea para restablecer una conexión que ha experimentado problemas debido a

desperfectos en la red (host caído u otra razón) Sirve para rechazar un segmento no
válido o puede interpretarse como un intento de abrir una conexión.

o FLAG SYN:
Utilizado para establecer una conexión. Cuando el emisor solicita establecer una conexión
SYN = 1 y ACK = 0, ya que no existe acuse. De aceptar el receptor, éste responde con
SYN = 1 y ACK = 1.
o TAMAÑO DE VENTANA (WINDOW SIZE):
Mediante este campo TCP lleva a cabo el control de flujo. El tamaño de la ventana es
variable, pero como máximo es de 16 bits. A través de la negociación entre el emisor y el
receptor, éste puede indicarle al emisor con un 0 en este campo que los datos llegaron,
hasta el último enviado, correctamente, pero no desea más datos por el momento pero. De
cambiar de opinión, el receptor envía un tamaño de ventana específico para proseguir la
comunicación.
o SUMA DE COMPROBACIÓN (CHECKSUM):
Mediante este campo se lleva a cabo el chequeo de la cabecera, los datos y la cabecera
ficticia TCP, que se explicará más adelante. (Ver Fig. 5.14)
Cuando tiene lugar la suma de comprobación, el campo con el mismo nombre es puesto a
cero, y de ser la longitud de los datos un número de bytes impar, entonces se rellena con
un byte cero. Luego, el algoritmo de comprobación suma todas las palabras de 16 bits en
complemento a 1 y después obtiene el complemento a uno de la suma. De este modo, al
efectuar el cálculo del segmento completo (cabecera y datos) la suma de comprobación
debe ser cero.
Ya que se ha mencionado a la cabecera ficticia, se mencionará que ésta sólo aparece

cuando se realiza la suma de comprobación, incluyéndose en dicho chequeo. Tal como
puede observarse, posee dos campos de 32 bits cada uno en donde se especifican las
direcciones IP de origen y destino, el tipo de protocolo (TCP = 6) y la longitud de la
cabecera. Básicamente, la cabecera ficticia es un ardid conceptual pero existente que se
emplea sólo en el chequeo de errores. En realidad, el lector minucioso se escandalizará al
hablar de direcciones IP en la capa de transporte, y no le falta razón.
o OPCIONES (OPTIONS):
Este campo se diseñó con la finalidad de tener una alternativa de agregar características
extra a la cabecera. Fundamentalmente permite refinar la negociación entre los hosts al
momento de definir el tamaño de los segmentos que se intercambiarán. De este modo,
cada host propone el tamaño máximo de segmento que podrá aceptar, “ganando” la
negociación quien propone el menor tamaño. Claro está que emplear segmentos grandes
favorece el rendimiento de la red, puesto que la relación datos / control es mayor, o dicho
de otra manera, en un segmento grande el tamaño de la cabecera (20 bytes) es
“despreciable” si se le compara a la parte de datos, la cual como mínimo debe ser de
536 bytes. De este modo, TCP podrá enviar paquetes a la capa de red con un

tamaño mínimo de 556 bytes. Recordar más bien que no todos los hosts podrán
aceptar segmentos grandes.
USER DATAGRAM PROTOCOL (UDP)
El UDP ofrece encapsular los mensajes de determinadas aplicaciones (por ejemplo,

TFTP, SNMP y DNS) en paquetes IP sin la necesidad de establecer, utilizar y liberar
una conexión. Por ello, se dice que UDP es un protocolo no orientado a la conexión y
no confiable. Un ejemplo clave de empleo de UDP es el mecanismo cliente – servidor
que del cual tal vez muchos de los lectores ya tendrán referencias. Y por cierto, si
alguno de los lectores ha quedado intrigado acerca de lo que significa TFTP, se le
adelanta que es el Trivial File Transfer Protocol. El TFTP se emplea, por ejemplo, para
“cargar” el IOS (Sistema Operativo) a los routers CISCO, aunque para ello trabaja en
equipo junto con el Hyperterminal de Windows.
Cabecera UDP
Un segmento UDP posee una cabecera de 8 bytes y otra parte restante de datos. La
cabecera UDP posee cuatro campos (Fig. 5.15), los que se analizarán a continuación.
 PUERTO DE ORIGEN Y PUERTO DE DESTINO:
Cumplen la misma función que en TCP, vale decir, identificar los puntos terminales
de las máquinas de origen y destino. Cada uno de estos campos posee 16 bits de
longitud.
El campo puerto de origen es opcional, o sea, puede asignársele un valor de cero.

Obviamente, el capo puerto de destino sí es obligatorio.
 LONGITUD UDP:
Especifica la longitud total del mensaje UDP, es decir, el tamaño de la cabecera y

de los datos. Puesto que este campo posee 16 bits, la longitud máxima del mensaje
UDP que podrá encapsularse en el paquete IP será de 65535 – 20 – 8 = 65507
bytes.
 SUMA DE COMPROBACIÓN:
Posee una longitud de 16 bits. Opera de la misma manera que en TCP, es decir,
calculando el complemento a uno de la suma en complemento a uno de la longitud
de la cabecera ficticia, de la cabecera UDP y sus datos, rellenándose con ceros de
ser necesario para completar los dos octetos. La suma de verificación es opcional y

si toma valor 0 es que no se computó. El fundamento es el mismo que en IP: el
complemento a uno de la suma de los complementos a uno de 16 bits pero a
diferencia de IP no sólo incluye la cabecera, sino también la carga de pago.
La cabecera sobre la que se realiza la suma de verificación no es la que se

transmite, sino una ficticia que toma la siguiente forma:

La Capa de Transporte-2 PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

La Capa de Transporte-2 PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Universidad Científica del Perú Facultad de Ciencias e Ingeniería

Sistemas de Comunicación de Datos

SERVICIOS DEL NIVEL DE TRANSPORTE

Ing. Jorge Danilo Jara Vela Página 1

Ing. Jorge Danilo Jara Vela Página 2

 entrega extremo a extremo

Entrega extremo a extremo

El nivel de red se encarga de la entrega extremo a extremo de paquetes individuales, pero no

Ing. Jorge Danilo Jara Vela Página 3

Cuando se transfieren datos, el principal objetivo de la fiabilidad es el control de errores. Como

El segundo aspecto de la fiabilidad implementada por el nivel de transporte es el control

Ing. Jorge Danilo Jara Vela Página 4

Cuando el tamaño de la unidad de datos recibida desde el nivel superior es demasiado

La mayor parte de los servicios de nivel de transporte añaden un número de secuencia

Ing. Jorge Danilo Jara Vela Página 5

El tercer aspecto de la fiabilidad cubierto por el nivel de transporte es el control de

El cuarto aspecto de la fiabilidad cubierto por el nivel de transporte es el control de

La duplicación puede parecer un problema trivial, pero puede tener importantes

Ing. Jorge Danilo Jara Vela Página 6

Al igual que el nivel de enlace de datos, el nivel de transporte es responsable del

A continuación se citan algunos puntos relacionados con las ventanas deslizantes en el

 El emisor no tiene que enviar los datos de la ventana completa.

Ing. Jorge Danilo Jara Vela Página 7

Para mejorar la eficiencia de la transmisión, el nivel de transporte tiene la opción de

o Multiplexación hacia arriba

o Multiplexación hacia abajo

Ing. Jorge Danilo Jara Vela Página 8

La transmisión orientada a conexión consta de tres pasos: establecimiento de conexión,

Ing. Jorge Danilo Jara Vela Página 9

o La computadora solicitante envía un paquete de desconexión.

TRANSMISSION CONTROL PROTOCOL (TCP)

¿Cómo accede una aplicación a TCP?

Ing. Jorge Danilo Jara Vela Página 10

Los PUERTOS 0 al 255 se denominan WELL-KNOWN PORTS y se reservan para servicios

Ing. Jorge Danilo Jara Vela Página 11

Funcionamiento del protocolo TCP

Como ya se ha mencionado, un proceso TCP en un host emisor toma de manera

Ing. Jorge Danilo Jara Vela Página 12

Por que la fragmentación introduce cabeceras que empobrecen la relación CONTROL /

Ing. Jorge Danilo Jara Vela Página 13

o PUERTO DE ORIGEN Y PUERTO DE DESTINO (SOURCE PORT AND DESTINATION

o NÚMERO DE SECUENCIA Y NÚMERO DE RECONOCIMIENTO (SEQUENCE NUMBER

El número de secuencia identifica el número de segmento enviado. El número de

o LONGITUD DE CABECERA TCP (TCP HEADER LENGTH):

El lector familiarizado con UNIX posiblemente haya utilizado la interrupción de un cómputo

o FLAG ACK (ACKNOWLEDGE):

Si se encuentra en 1 quiere decir que el número de reconocimiento o de acuse de recibo

Se emplea para restablecer una conexión que ha experimentado problemas debido a

Ing. Jorge Danilo Jara Vela Página 14

o TAMAÑO DE VENTANA (WINDOW SIZE):

o SUMA DE COMPROBACIÓN (CHECKSUM):

Ya que se ha mencionado a la cabecera ficticia, se mencionará que ésta sólo aparece

Ing. Jorge Danilo Jara Vela Página 15

USER DATAGRAM PROTOCOL (UDP)

El UDP ofrece encapsular los mensajes de determinadas aplicaciones (por ejemplo,

 PUERTO DE ORIGEN Y PUERTO DE DESTINO:

El campo puerto de origen es opcional, o sea, puede asignársele un valor de cero.

Especifica la longitud total del mensaje UDP, es decir, el tamaño de la cabecera y

Ing. Jorge Danilo Jara Vela Página 16

La cabecera sobre la que se realiza la suma de verificación no es la que se

Ing. Jorge Danilo Jara Vela Página 17

Anda mungkin juga menyukai