Documente Academic
Documente Profesional
Documente Cultură
Capa de Transporte
La capa de transporte brinda comunicacin lgica entre procesos de de aplicacin que se ejecutan
en host diferentes.
Capa de red: Protocolo IP, es best effort, enva los segmentos pero no garantiza la entrega
ni la integridad de los datos.
TCP, ofrece mltiples servicios, transferencia de datos fiables mediante tcnicas de control
de flujo, nmeros de secuencia, mensajes de reconocimiento y temporizadores, adems
de mecanismos de control de congestin.
Multiplexacin: Reunir los fragmentos de datos en el host de origen desde los diferentes
sockets, encapsulando cada fragmento con la informacin de cabecera y asi crear los
segmentos y pasarlos a la capa de red.
Los nmeros de puertos son de 16 bits en el rango de 0 a 65535, del 0 al 1023 se conocen
como puertos bien conocidos y son restringidos.
Proceso general de demultiplexacin: cada socket del host se puede asignar a un nmero
de puerto y, al llegar un segmento al host, la capa de transporte examina el nmero de
puerto de destino contenido en el segmento y lo enva al socket correspondiente, luego
los datos del segmento pasan a travs del socket y se entregan al proceso asociado.
La capa de transporte crea un segmento con el puerto de origen y el puerto de destino, entonces
en cada host ocurre la multiplexacin y demultiplexacin segn el socket con el puerto UDP
asignado de destino o origen. Por qu es necesario que se ponga el puerto de origen? Para que si
el host receptor desee devolver el segmento sepa a donde enviarlo.
A diferencia del socket UDP, el socket TCP se identifica por una tupla de 4 elementos: IP de origen,
puerto de origen, IP de destino, puerto de destino.
El cliente TCP genera una segmento de establecimiento de conexin, este es enviado al servidor,
el cual recibe el segmento e identifica el puerto de destino y asigna un socket al proceso, adems
tambin identifica los 4 elementos que contiene, y los relaciona a este socke8t de conexin, es
entonces cuando ya se podr enviar datos entre estos. Cada socket tiene asignado una nica tupla
de los 4 elementos.
El texto hace nfasis en la manera en que se establecen las conexiones cliente servidor, hace
referencia al termino HTTP persistente y no persistente, persistente es cuando se establece la
conexin de cliente servidor y se pueden transmitir todos los objetos o mensajes a travs del
mismo socket, pero cuando es no persistente, para cada peticin/respuesta (osea para cada
mensaje o objeto) se crea un nuevo socket, y esto ltimo genera poca eficiencia.
Se dice que es un protocolo sin conexin porque no establece conexin entre emisor y receptor
antes de enviar el segmento a la capa de red.
El proceso de UDP es simple, nunca toca IP, el que se encarga de comunicarse con IP es la capa de
aplicacin, UDP recpciona estos datos obtenidos por la capa de aplicacin y coloca puerto de
origen y destino para hacer el servicio de multiplexacin/demultiplexacin, aade 2 pequeos
campos ms y enva el segmento resultante a la capa de red, la capa de red lo encapsula en un
datagrama IP y hace el mayor esfuerzo por entregar el ssegmento al host receptor.
Y luego de que llega, si es que llega, se encarga de enviar al proceso segn el puerto de destino.
Por qu preferir UDP en vez de TCP? Si todo parece indicar que UDP no parece ser para nada
efectivo, las ventajas de usar UDP son:
TCP empieza cada vez ms a desplazar a UDP, si bien es cierto que muchas aplicaciones
multimedia, de videoconferencias, telefnica, etc, utilizan UDP por su velocidad, ya se estn
viendo cosas que algunas que usan TCP.
Es posible que se puede transmitir datos de manera fiable usando UDP, y esto se consigue
incorporando caractersticas de fiabilidad a la aplicacin en si, es algo complicado pero da
ENORMES ventajas, ya que no tendra las restricciones de velocidad de transmisin impuestas por
TCP.
Esta es la estructura:
La cabecera UDP solo tiene 4 campos y cada uno con 2 bytes, como ya se mencion :el host de
destino utiliza el puerto para asociarlo al proceso adecuado.
Sirve para detectar si el segmento UDP ha sido alterado durante la transmisin. En el lado emisor,
UDP calcula el complemento a 1 de todas las palabras de 16 bits del segmento acarreando
cualquier desbordamiento obtenido durante la operacin de suma, sobre el bit de menor peso.
Es mejor que lo entiendan (los que leen esto) con el ejemplo del libro:
Como se produjo desbordamiento el 1 pas al bit de menor peso (osea el de la derecha), luego se
saca complemento a 1 de este resultado y se obtiene la suma de comprobacin, luego el receptor
suma este valor con las otras 3 palabras y tiene que salir 11111111111111, si no, es que hay error.
Es porque no es seguro que todos los encales presenten control de errores, adems el error se
puede producir luego que la capa de enlace termine su trabajo, osea se puede producir errores de
bit cuando el segmento se almacena en la memoria del router.
UDP al detectar error, simplemente descarta el segmento o lo enva a la aplicacin junto con una
advertencia. AQU TERMINA UDP.
Uno de los principales problemas es que si bien se puede tener una transferecnai de datos fiables
en la capa de transporte (TCP), en las capas inferiores tal vez no presenten este servicio, como en
de red terminal terminal no fiable (IP).
Durante lo que sigue del capitulo solo se explicara todo desde la perspectiva unidireccional,
porque la bidireccional es mas complicada de entender.
A continuacin se irn mostrando los protocolos, hasta llegar a uno que no tiene defectos.
Transferencia de datos fiable sobre un canal totalmente fiable: rdt 1.0 (reialable data transfer)
Se muestran maquinas de estados finitos (FSM), en este caso solo tienen 1 estado, el suceso que
provoca la transicin se pondr encima de la lnea horizontal y los sucesos que provoca, debajo de
la lnea horizontal.
Para este caso el receptor no necesitar de realimentacin ya que dispone de un canal totalmente
fiable, y adems la velocidad con la que el receptor recibe el mensaje es igual a la que el emisor
enva asi que tampoco habr problemas con eso. Es un caso ideal en realidad, ms que todo el
autor lo usa para dar detalles de como funcionarn los procesos de las maquinas de estados que
mostrar.
Transferencia de datos fiables sobre un canal con errores de bit rdt 2.0
Este es un caso ms real en donde el canal presenta errores y corrompe el paquete de datos, en
este caso se relizan los procesos como cuando una persona esta hablando por telfono con otra y
cuando entiende algo dice: ok si, ok esta bien, pero cuando no entiende dice: que? Puedes
repetir?, lo mismo ocurre aqu, cuando no se enva correctamente un paquete este enva
automticamente un ARQ, mediante protocolos ARQ (automatic repeat reQuest) en estos
protocolos se necesitan 3 capcacidades de de protocolos adicionales para gestionar la deteccin
de errores de bit:
- Deteccin de errores: Se necesita saber que hubo error, esto si tiene UDP, para esto se
hace que el emisor envie unos datos adicionales al paquete que enva para el cculo
de suma de comprobacin de paquete de datos rdt 2.0
- Realimentacin del receptor: para que el emisor sepa que su paquete se envio con
errores necesita que el receptor le diga algo, para esto son el ACK y NAK (ACUSE DE
RECIBO POSITVO Y NEGATIVO), estos paquetes solo necesitan 1 bit, osea 0 para NAK y
1 PARA ACK.
- Retransmisin: su nombre lo dice, cuando el paquete tiene error, el receptor debe
retransmitir.
Bueno resulta que el emisor recibe los datos de la capa superior y los empaqueta junto con la
suma de comprobacin y los enva, es entonces cuando pasa a otro estado, en donde solo se pone
a esperar el ACK o NAK, si recibe el ACK recin pasa a su estado anterior donde puede recibir
datos, por el contrario solo estar esperando a que el receptor envie NAK o ACK, esto se le llama
protocolo de parada y espera (stop and wait protocol), obviamente si recibe un NAK tendr que
retransmitir el ltimo paquete recibido.
Por parte del receptor si recibe bien el paquete manda un ACK al emisor y extrae el paquete
entrga los datos, si recibe mal enva un NAK.
Para esto se crean un temporizador con un promedio razonable de tiempo en que el paquete
puede perderse, el emisor inicia su temporizador al enviar el paquete, si no recibe el ACK/NSK, en
el tiempo indicado, vuelve a mandar el paquete, en este caso hay la posibilidad de que haya
duplicado de paquetes enviados (en caso no se haya perdido el paquete sino solo se haya
demorado un poco ms), pero con las respuestas ACK 0 o ACK1 (0 y 1 los nmeros de secuencias
mencionados anteriomente), se puede determinar el duplicado y el sistema continuar
funcionando normalmente.
A este tipo de protocolos se les llama de bit alternante, (por sus numros de secuncia 0 y 1).
3.4.2. Protocolo de transferencia de datos fiable con procesamiento en cadena (GBN)
El protocolo rdt3.0 es muy bueno, pero lo malo es que es un protocolo de parada y espera, y esto
afecta el rendimiento, para laas redes de alta velocidad actuales.
En vez de estar esperando a que el paquete se envie y llegue la respuesta del ACK, se puede enviar
paquetes simultneamente.
Esto implica algunas cosas adicionales como que se necesitar un rango mayor de nmeros de
secuencia, y que los buffer del emisor y receptor van a almacenar mas de un paquete.
Estas implicancias dependern de como responde el protocolo a las perdidas o retrasos excesivos
de paquetes, para ayudar en la recuperacin de errores en los procesamiento en cadena se
utilizan: Retroceder N y la repeticin selectiva.
3.4.3 Retroceder N
Este protocolo puede transmitir varios paquetes sin necesidad de ser reconocidos, pero tiene un
lmite, N, al cual se le llama ventana, este grafico resume todo:
Se asigna como base al numero de paquete mas antiguo no reconocido y signumsec como el
numero de secuencia mas pequeo no enviado. A partir de aqu se definen 4 rangos de nmeros
de secuencia (los mostrados en Clave del grfico).
A este protocolo se le llama de ventana deslizante, porque cada que los paquetes vayan
reconocindose y enviando otros la ventana se desplaza hacia adelante.
Con reconocidos se refiere a los respondidos con un ACK por parte del receptor.
Una caracterstica importante en este protocolo es que no recibe paquetes en desorden, los
descarta, por ejemplo si se pierde el paquete con nro de secuencia 2, no va a recibir el 3 4 y 5
hasta que el emisor no vuelva a enviar y que el receptor reciba satisfactoriamente este paquete.
El protocolo GBN, como se puede notar tiene un gran punto en contra y es que por el hecho de no
aceptar paquetes en desorden genera muchas retransmisiones, ocasionando muchas
transmisiones innecesarias.
Este protocolo SR, subsana esto, cada vez que el receptor detecte que se perdi un paquete y esta
recibiendo en desorden, los guarda en un buffer, y manda un aviso al emisor de cual es el paquete
que se perdi, entonces el emisor solo manda el paquete perdido y cuando el receptor lo recibe
bien, recin procesa los otros paquetes.
3.5. TCP
NUMERO DE RECONOCIMIENTO:
Todos los segmentos que llegan procedentes del host B tienen un nmero de secuencia para los
datos que fluyen de B a A. El nmero de reconocimiento que el host A incluye en su segmento es el
nmero de secuencia del siguiente byte que el host A est esperando del host B.
Suponga que el host A ha recibido todos los bytes numerados de 0 a 535 procedentes de B y
suponga tambin que est enviando un segmento al host B. El host A est esperando al 536 y todos
los bytes que le siguen del flujo de datos del host B. Por tanto, el host A incluye 536 en el campo
nmero de reconocimiento del segmento que enva a B.
PROTOCOLO TELNET
Se ejecuta sobre tcp y permite el inicio de sesin remotos. cada vez que un cliente teclee un
carcter este viaja al receptor y luego regresa al cliente para su visualizacin
Tcp utiliza un temporizador para recuperarse de la perdida de segmentos ,pero no se sabe cunto
tiene que ser ese tiempo necesario para afirmar que un segmento se ha perdido o daado.
PARA poder ponderar los rtt de cada conexin tcp en el tiempo se utiliza LA EWMA (
MEDIA MOVIL EXPONCENCIALMENTE PONDERADA) con eso recolectamos un RTTestimado
El intervalo que debe usarse para el fin de temporizacin TCP tiene que ser mayor que el
rttestimado sino se producen retrasmisiones innecesarias pero tampoco muy mayor q el
rttestimado puesto que se tendra que esperar mucho para la restrasmision de un
segmento perdido o corrompido .
Tcp crea un servicio de trasnferencia de datos fiable sobre el servicio de mejro esfuerzo de
ip,logrando que los segmentos que lleguen a los buffers de recepcin TCP no se hayan perdido
,corrompido y que lleguen en orden.
El protocolo TCP solo utiliza un temporizador para todo el flujo de datos trasnmitido y ya no para
cada segmento ya que esto genera un sobrecarga a la red
-Los datos son recibidos de la capa de aplicacin ,se encapsula en ip y se llevan a la red
- si sucede el fin de temporizacion,tcp retrasmite el segmento que ha causado dicho fin de la
temporizacion
-la llegada de un semneto de reconocimiento ACK,TCP usa una RECOCIMIENTOS ACUMULATIVOS:
EJEMPLO SI EL ACK= 98 SIGNIFICA QUE HA RECIBIDO CORRECTAMENTE DESDE EL NUMERO INICIO
DE SECUENCIA HASTA EL 98AVO BIT
RECONOCIMIENTO ACUMULATIVO:
TCP brinda un servicio de control de flujo a los procesos de las aplicaciones para que no desborden
el buffer del receptor ,adapta la velocidad a la q el emiso esta trasmitiendo a la velocidad con la
que la aplicacin esta leyendo los datos )
Para ello utiliza una ventana de recpcion que le indica cuanto espacio disponible hay en el buffer
de recepcin
Udp no implmenta ningn servicio de control de flujo
ACUERDO DE 3 FASES :
1er paso CLIENTE TCP enva un segmento especial al SERVIDOR TCP ,este segmento especial no
tiene datos pero tiene un bit SYN PUESTO A 1
2 DO PASO : Cuando llega el segmento SYN al receptor este asigna los buffer y las variables tcp y
enva un segmento de respuesta indicando que se ha establecido la conexin
(SEGMENTO SYNACK)
3ER PASO : el emisor al recibir el segmento SYNACK asigna tambin buffer y variables a la
conexin,el emiso enva otro segmento confirmando la conexin
En los segmentos enviados despus el bit SYN esta puesto a 0
Completados los 3 pasos ya se puede comenzar a trasmitir los segmentos que contienen los datos
Cuando se quiere abadonar una conexio el emisor manda un segmento especial con un bit FIN
puesto a 1 ,asimismo el servidor responde con otro segmento con bit FIN PUESTO A 1 confirmando
la desconexin del servidor
Utilizado en atm
3.7 MECANISMO DE CONTROL DE CONGESTION DE TCP