Tema 2

Administracin de redes y servidores
rea de Ingeniera de Sistemas

Profesores: Carlos Elvira Izurrategui Javier Rico Azagra
Profesor: Carlos Elvira Izurrategui
ndice
1. 2. 3. 4. 5. 6. 7.
La capa de transporte y sus servicios. Multiplexacin y demultiplexacion. Transporte sin conexin: UDP. Principios de un servicio de transferencia de datos fiable. Transporte orientado a la conexin: TCP. Principios de control de congestin. Mecanismo de control de congestin de TCP.
ndice
1.
2. 3. 4. 5. 6. 7.
La capa de transporte y sus servicios.

Multiplexacin y demultiplexacion. Transporte sin conexin: UDP. Principios de un servicio de transferencia de datos fiable. Transporte orientado a la conexin: TCP. Principios de control de congestin. Mecanismo de control de congestin de TCP.
La capa de transporte y sus servicios

Protocolo de capa de transporte proporciona una comunicacin lgica entre procesos de aplicacin.
Semejante a tener los 2 host conectados entre s. Pueden estar los 2 hosts en cualquier sitio, conectados por distintos tipos de enlaces entre routers y switches. Los procesos de aplicacin utilizan la comunicacin lgica (transporte) para enviarse mensajes entre s, sin preocuparse de la infraestructura fsica. Los protocolos de capa de transporte estn implementados en los sistemas terminales (no en los routers). PDUs de capa de transporte: segmentos. En el lado emisor:
Convierte y divide los mensajes procedentes de un proceso de aplicacin en segmentos. Aade cabecera del segmento. Pasa el segmento a la capa de red (paquete o datagrama), que se enva al destino.
La capa de transporte y sus servicios

En el lado emisor:
Convierte y divide los mensajes procedentes de un proceso de aplicacin en segmentos. Aade cabecera del segmento. Pasa el segmento a la capa de red (paquete o datagrama), que se enva al destino.
aplicacin transport Red enlace fsca
n -e nd le ca gi lo d t or sp an tr
En el lado receptor:
La capa de red extrae el segmento de la capa de transporte del datagrama recibido. Los sube a la capa de transporte y se procesa. Se ponen los datos del segmento a disposicin del proceso de la aplicacin receptor.
aplicacin transport red Enlace Fsica
Relaciones entre capas de transporte y red

Capa de transporte: proporciona una comunicacin lgica entre procesos que se ejecutan en hosts distintos.
Analoga: 6 nios enviando cartas a sus 4 primos Sus servicios estn procesos = nios restringidos por el protocolo de red Mensajes app. = (retardos, BW). cartas en sobres Tambin puede ofrecer servicios que no hosts = casas ofrezca el protocolo de la capa de red Protocolo trans = subyacente. Ana y Pedro Capa de red: proporciona una Protocolo capa de comunicacin lgica entre hosts red= servicio postal
La capa de transporte en Internet

UDP (User Datagram Protocol): proporciona un servicio sin conexin no fiable a la aplicacin que le invoca. TCP (Transmissin Control Protocol): proporciona un servicio con conexin fiable. Capa de red con IP (Internet Protocol): proporciona un servicio de entrega de mejor esfuerzo.
Hace lo que puede. No garantiza la entrega (servicio no fiable)
aplicacin transport red Enlace fsica
red Enlace fsica
n -e nd le ca gi lo
red Enlace fsica red Enlace fsica red Enlace fsica red Enlace fsica red Enlace fsica
d t or sp an tr
aplicacin transport red Enlace fsica
ndice
1. 2.
3. 4. 5. 6. 7.
La capa de transporte y sus servicios. Multiplexacin y demultiplexacion.

Transporte sin conexin: UDP. Principios de un servicio de transferencia de datos fiable. Transporte orientado a la conexin: TCP. Principios de control de congestin. Mecanismo de control de congestin de TCP.
Multiplexacin y demultiplexacin
Demultiplexado en host rec.: Entrega de segmentos recibidos a su socket
= socket aplicacin P3 transporte red enlace fsica = proceso P1 P1 aplicacin transporte red enlace fsica P2 P4 aplicacin transporte red enlace fsica
Multiplexado en host emi.: Reune datos de mltiplies sockets, los encapsulndolos con la cabecera creando el segmento
host 1
host 2
host 3
Demultiplexacin. Funcionamiento
Host receptor recibe paquete o datagrama IP.
Cada datagrama tiene IP origen e IP destino. Cada datagrama lleva un segmento de capa de transporte. Cada segmento tiene un puerto origen y un puerto destino. 32 bits puerto or. # puerto dest #
otros campos de cabecera
El host receptor usa la IP y el puerto para colocar cada en su socket.

Las tcnicas de multiplexacin y demultiplexacin son necesarias siempre que un nico protocolo de una capa sea utilizado por varios protocolos de la capa superior.
Ejemplo: HTTP, FTP, SMTP usan TCP.
datos de aplicacin (mensajes)
Formato segmento TCP/UDP
Multiplexado-demultiplexado sin conexin

Creacin de socket UDP en un host (Java):
DatagramSocket mySocket0 = new DatagramSocket(); DatagramSocket mySocket1 = new DatagramSocket(12534);
Un socket UDP socket posee la dupla que lo identifica: (dest IP address, dest port number) En la capa de transporte se encapsula la dupla a los datos de aplicacin. La capa de transporte pasa el segmento a la capa de red: encapsula el segmento con cabecera (IP origen+IP destino).
IP hace el mximo esfuerzo por entregar el segmento al host receptor (pero IP no garantiza).
En el host receptor:
Se examina el nmero de puerto destino indicado en el segmento. Y se entrega el segmento a su socket correspondiente (con ese nmero de puerto). Al mismo socket destino pueden llegar informacin procedente de datagramas con IPs origen distintas y/o segmentos con puertos origen distintos.
Multiplexado-demultiplexado sin conexin

DatagramSocket serverSocket = new DatagramSocket(6428);
P2
P3
P1 P1
SP: 6428 DP: 9157 SP: 9157
SP: 6428 DP: 5775 SP: 5775
cliente IP: A
DP: 6428
servidor IP: C
DP: 6428
cliente
IP:B
SP suministra dato de retorno

Multiplexado-demultiplexado con conexin

Socket TCP queda identificado por 4 elementos: SP (source port), DP (destinatio port), SIP (source IP), DIP (destination IP). Cuando un segmento llega a un host se emplean los 4 valores para dirigir (demultiplexar) el segmento al socket adecuado. 2 segmentos TCP entrantes con IPs de origen o n puertos distintos se dirigen a sockets diferentes. Salvo el segmento
La aplicacin del servidor con TCP tiene un socket de acogida en espera de solicitudes de establecimiento de conexin procedente de clientes en un puerto dado. El cliente TCP genera segmento de establecimiento de conexin:
Socket socketcliente = new Socket(nombreHostServidor,#port);
TCP que transporta la solicitud original del establecimiento de la conexin.
Solicitud de establecimiento de conexin: segmento TCP con #port y conjunto especial de bits de establecimiento de conexin en la cabecera TCP. Tambin se genera en el cliente un socket TCP para intercambiar datos. Al llegar la sol. de establecimiento de conexin al servidor, localiza el proceso (daemon) en el servidor que espera a aceptar la conexin. El proceso servidor crea un nuevo socket:
Socket socketConexion = socketAcogida.accept();
Multiplexado-demultiplexado con conexin

La capa de transporte en el servidor anota los 4 campos (SP, DP, SIP, DIP). El socket de conexin recin creado queda identificado por los 4 valores.. Todos los segmentos que lleguen despus con estos mismos 4 valores, entrarn por este socket para intercambiar datos entre cliente y servidor.
Un host servidor puede dar soporte a muchos sockets TCP simultneos, y cada uno de ellos queda identificado por los 4 valores.
P1 P4 P5 P6
SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 SP: 9157
P2
P1 P3
Cliente IP: A
DP: 80 S-IP: A D-IP:C
Servidor IP: C
DP: 80 S-IP: B D-IP:C
Cliente
IP:B
TCP en servidores web

Ejemplo: servidor web Apache. Puerto 80. Los clientes navegadores envan todos los segmentos (de establecimiento de conexin y de transporte de mensajes solicitud HTTP) al servidor, todos lo hacen por puerto 80.
El servidor los diferencia segn la IP de origen y puerto origen.
Los servidores web actuales utilizan un proceso y crean una hebra (subproceso) con un nuevo socket de conexin para cada conexin de un cliente.
Este tipo de servidores pueden tener muchos sockets de conexin (distintos identificadores) asociados al mismo proceso.
Si el cliente y el servidor utilizan conexiones persistentes, se intercambian los mensajes por el mismo socket. Si el cliente y el servidor utilizan conexiones no persistentes, cada mensaje solicitud/respuesta necesita abrir/cerrar una conexin TCP.
Esto puede afectar al rendimiento del servidor.

Ejemplo: servidor web Apache. Puerto 80. Los clientes navegadores envan todos los segmentos (de establecimiento de conexin y de transporte de mensajes solicitud HTTP) al servidor, todos lo hacen por puerto 80.
El servidor los diferencia segn la IP de origen y puerto origen.
Los servidores web actuales utilizan un proceso y crean una hebra (subproceso) con un nuevo socket de conexin para cada conexin de un cliente.
Este tipo de servidores pueden tener muchos sockets de conexin (distintos identificadores) asociados al mismo proceso.
Si el cliente y el servidor utilizan conexiones persistentes, se intercambian los mensajes por el mismo socket. Si el cliente y el servidor utilizan conexiones no persistentes, cada mensaje solicitud/respuesta necesita abrir/cerrar una conexin TCP.
Esto puede afectar al rendimiento del servidor.
P1
P4
SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 SP: 9157
P2
P1 P3
Cliente IP: A
DP: 80 S-IP: A D-IP:C
Servidor IP: C
DP: 80 S-IP: B D-IP:C
Cliente
IP:B
ndice
1. 2.
La capa de transporte y sus servicios. Multiplexacin y demultiplexacion.
3.
4. 5. 6. 7.
Transporte sin conexin: UDP.

Principios de un servicio de transferencia de datos fiable. Transporte orientado a la conexin: TCP. Principios de control de congestin. Mecanismo de control de congestin de TCP.
Transporte sin conexin UDP

Protocolo de transporte simple y poco sofisticado (vacuo). UDP: RFC 768. Realiza:
Funcin de multiplexacin y demultiplexacin.
Toma los mensajes del proceso aplicacin.
Encapsula los puertos origen y destino. Aade informacin (2 campos) de comprobacin de errores.
La capa de red encapsula el segmento en un datagrama (paquete) IP. Con el mejor esfuerzo entrega el segmento al host receptor.
UDP no tiene fase de establecimiento de conexin previa al envo del segmento con mensaje de aplicacin. Protocolo sin conexin. Ejemplos: DNS (53), RIP (520). Ventajas de UDP frente a TCP:
Mejor control en el nivel de aplicacin sobre qu datos se envan y cundo.
Se enva los datos de aplicacin empaquetados y se entregan directamente a capa de aplicacin. TCP no lo hace ya que tiene un mecanismo de control de congestin que regula el flujo.
Transporte sin conexin UDP

Ventajas de UDP frente a TCP:
Sin establecimiento de conexin.
TCP lleva un establecimiento de conexin en 3 fases (genera retardo).
Sin informacin de estado de la conexin.

TCP mantiene informacin del estado de la conexin en los sistemas terminales.
Buffers de recepcin y de envo. Parmetros de control de congestin. Parmetros de nmero de secuencia y nmero de reconocimiento.
Puede suponer problema se congestin en la red. Ejemplo: reproduccin masiva de vdeo a alta velocidad. -> Desbordamiento de paquetes en la cola de los routers. Prdidas de paquetes. No todos los emisores UDP llegarn a su destino. Emisores UDP pueden hacer disminuir mucho la velocidad de transmisin en los emisores TCP (estrangulamiento de sesiones TCP)
Poca sobrecarga debida a la cabecera de los paquetes.

Segmentos UCP contienen cabeceras de 8 bytes. TCP posee 20 bytess.
Una aplicacin puede disponer de servicio fiable de transferencia de datos trabajando con UDP.
Ojo: aadiendo los mecanismos de fiabilidad en la propia aplicacin
Transporte UDP. Estructura del segmento
32 bits Longitud, en bytes de segmento UDT, incluyendo cabecera Port# origen Port# destino longitud checksum
Datos de aplicacin (mensage)
Formato de segmento UDP
Transporte UDP. Checksum

Checksum (suma de comprobacin): mecanismo de deteccin de errores (OJO: no de correccin).
Se utiliza para determinar si los bits contenidos en el segmento UDP han sido alterados al desplazarse desde el origen al destino (seales de ruido en los enlaces, procesamiento en el router)
Funcionamiento del checksum:

En el emisor se calcula el complemento a 1 de las suma (con acarreo) de todas las palabras de 16 bits (RFC 1071) Igual en el receptor. Se suma al receptor el checksum.
Debe salir 1111.1111 (16 bits a uno) Si algn bit es cero -> error.
Porqe usar checksum en capa de transporte?

Hay protocolos de capa de enlace (Ethernet) que tambin los lleva, pero hay otros protocolos que no. Adems aunque exista comprobacin de error en el enlace, puede haber error en el almacenamiento del segmento en memoria (del router). Se cumple el principio terminal a terminal en el diseo de sistemas: las funcionalidades deben implementarse terminal a terminal, de forma que las funciones incluidas en los niveles inferiores pueden ser redundantes o escasamente tiles si se comparan con el coste de proporcionarlas en un nivel superior
ndice
1. 2. 3.
La capa de transporte y sus servicios. Multiplexacin y demultiplexacion. Transporte sin conexin: UDP.
4.
5. 6. 7.
Principios de un servicio de transferencia de datos fiable.

Transporte orientado a la conexin: TCP. Principios de control de congestin. Mecanismo de control de congestin de TCP.
Servicio de transferencia de datos fiable.

Un servicio de transferencia de datos fiable puede aparecer en capa de transporte, capa de enlace y en capa de aplicacin. Es uno de los problemas que ms afectan a las redes de computadores. Modelo de abstraccin del servicio. El protocolo implementa el modelo.
Se proporciona a las entidades de la capa superior un canal fiable por el cual pueden enviar los datos Los protocolos de las capas inferiores pueden ser no fiables, por lo que se complica el modelo y la implementacin. Diseo incremental en ambos lados emisor y receptor.

Implementacin del modelo.
El lado emisor es invocado desde la capa superior. El lado receptor es llamado desde una capa inferior.
Se utilizan funciones o procedimientos con parmetros (informacin, paquetes, segmentos, datos).

Rdt_send(): reliable_send) Deliver_data() Rdt_rcv(): reliable receive Udt_send(): unreliable send

rdt_send(): llamada desde capa superior, (ej.: aplic.). Pasar los datos a entregar en el receptor deliver_data(): llamada por rdt para repartir datos a capa sup.
Emisor
Receptor
udt_send(): llamada por rdt, para transferir paquetes al canal no fiable.
rdt_rcv(): llamada cuando llega un paquete en el lado receptor del canal
Construccin del protocolo.

Considerar transferencia de datos unidireccional (simplex). La realidad es full-duplex (bidireccional). En cada lado crear una FSM (Finite-State Machine)
Crculo: estados Flechas: transiciones. Leyendas: eventos y acciones.
Evento que origina la transicin de estado Acciones cuando tiene lugar el suceso
Estado: situacin del sistema en un instante dado. El estado siguiente est determinado por un nuevo evento
Estado 1
evento acciones
Estado 2
Construccin del protocolo. Rdt 1.0

Canal subyacente fiable:
Sin prdida de datos. Sin errores.
Lado emisor acepta datos de la capa superior a travs del suceso rdt_send(datos). Crea un paquete con datos packet=make_pkt(data) y enva un paquete al canal udt_send(packet). Lado receptor recibe un paquete del canal subyacente a travs del suceso rdt_rcv(packet). Crea un paquete con datos packet=make_pkt(data) y enva un paquete al canal udt_send(packet).
rdt_send(data) packet = make_pkt(data) udt_send(packet)
Esperar una llamada de abajo
Esperar una llamada de arriba
rdt_rcv(packet) extract (packet,data) deliver_data(data)
Emisor
Receptor

Protocolo simple. No hay diferencia entre unidad de datos y paquete. Todo el flujo va del emisor al receptor (no hay realimentacin). El receptor puede recibir los datos tan rpido como el emisor los enva. No hay necesidad de solicitar ralentizacin al emisor.

Modelo ms realista supone canal subyacente con posibilidad de corrupcin de bits. Analoga: escenario de dictado de mensajes
Reconocimiento positivo: De acuerdo. Reconocimiento negativo: Por favor, repita Mensajes o seales de control que permiten al receptor hacer saber al emisor que se ha recibido paquetes con o sin errores.
Protocolos ARQ (Automatic Repeat ReQuest). Deben disponer de 3 capacidades adicionales.

Deteccin de errores, en el receptor.
Recordar comprobacin de errores en UDP. Tcnicas mltiples para detectar y/o corregir errores. Se aaden bits adicionales a los datos originales.
Realimentacin del receptor, al emisor.

Respuestas de acuse de recibo positivo: ACK (acknowledgement). Respuestas de acuse de recibo negativo: NAK (negative ACK). Con un seal binaria: 1 ACK; 0 NAK.
Retransmisin: paquete con errores ser transmitido de nuevo por el emisor.
Protocolo de parada y espera (stop-and-wait-protocol).

El emisor no puede recibir ms datos de capa superior, no puede ocurrir mientras espera un ACK o NAK, y salga de ese estado. Justificacin de la necesidad de 2 estados distintos en el emisor

rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK
receptor
rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
emisor
Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)
Construccin del protocolo. Rdt 2.0 con error

rdt_rcv(rcvpkt) && corrupt(rcvpkt)

udt_send(NAK)
En el estado wait for ACK or NAK Rdt2.0 no puede obtener ms datos de la capa superior. Protocolos de parada y espera Stop-and-wait protocol
Construccin del protocolo. Rdt 2.0 sin error

rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK)
Construccin del protocolo. Rdt 2.0 fallos

Y si el paquete ACK o NAK se corrompe? Tres posibilidades:
Recordar escenario de dictado de mensajes. E1: mensaje. R: `de acuerdo`, `por favor repita`. Corruptos. E2: cmo dice? Problemas: R en distinguir E1 y E2; E2 puede estar corrupto. Aadir bits para detectar y corregir errores. No se soluciona la prdida de paquetes. E reenva el paquete de datos al R al recibir un ACK o NAK alterado. Problema: paquetes duplicados en el canal E-R. El receptor no sabe si el ACK o NAK llega al E. No sabe si el paquete contiene datos nuevos o es una retransmisin del ltimo paquete.
Solucin aplicada: aadir campo nuevo que numere los paquetes de datos (Nmero de secuencia).
El receptor comprueba el nmero de secuencia para ver si el paquete contiene datos nuevos o es una retransmisin. El protocolo de stop-and-wait utiliza un bit en el numero de secuencia. Si el bit mantiene el valor: retransmisin de paquete. Si el bit conmuta (desplazamiento a izquierdas): nuevo paquete.
Protocolo Rdt2.1:
Posee el doble de estados que rdt2.0. El protocolo refleja si el paquete que enva el E o el que recibe el R incluye un nmero de secuencia 1 o 0.

rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) &&
Wait for call 0 from above Wait for ACK or NAK 0
( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

Wait for ACK or NAK 1
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpkt)
Wait for call 1 from above
rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) Wait for 0 from below Wait for 1 from below rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

En el emisor:
Se aade el num. sec. en el pkt. Este num. sec. puede tomar valores 1 o 0. Debe comprobar si ACK o NAK estn corruptos.
El receptor:
Debe comprobar si el paquete recibido est duplicado.
El propio estado indica si est esperando un 0 o un 1 en num. sec.
Construccin del protocolo. Rdt 2.2 Misma funcionalidad que rdt2.1. Solo utiliza ACKs En el receptor:
En lugar de enviar un NAK, enva 2 respuestas ACKs. Incluye el nmero de secuencia del paquete que est siendo confirmado. make_pkt(ACK, 1, checksum)
En el emisor:
Recibe 2 repuestas ACKs consecutivas y duplicadas; equivale a corrupto. Comprueba el num sec del paquete que est siendo confirmado.
isACK(rcvpqt,1).

rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || Wait for Wait for isACK(rcvpkt,1) ) ACK call 0 from 0 udt_send(sndpkt) above
sender FSM fragment
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)
Wait for 0 from below
receiver FSM fragment
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK,1, chksum) udt_send(sndpkt)
Construccin del protocolo. Rdt 3.0 Canal subyacente puede perder paquetes (normal el redes).
Cmo detectar la prdida de paquetes. Pueden ser paquetes de datos o paquetes ACK. Solucin con temporizadores. Qu hacer cuando se pierde un paquete.
Solucin a la prdida de paquetes.

El emisor debe esperar el tiempo suficiente como para estar seguro de que se ha perdido un paquete. Al menos el emisor debe esperar un RTT (ms tiempo de procesamiento en el receptor).
Es un tiempo muy difcil de estimar. El protocolo debe detectar la prdida cuanto antes sea posible. Mtodo: el emisor adopta un mtodo que selecciona juiciosamente un intervalo de tiempo tal que sea probable que el paquete se pierda (no es seguro la prdida). Profesor: Carlos Elvira Izurrategui
Construccin del protocolo. Rdt 3.0 Solucin qu hacer ante la prdida?.

La retransmisin. El emisor retransmite el paquete si dentro del tiempo establecido (temporizado) no ha recibido un ACK.
Nota: se introduce la posibilidad de paquetes de datos duplicados en el canal.

Solucionado con rdt2.2.
Para el emisor la retransmisin es la solucin para todo.

Ante la prdida de un paquete de datos. Ante la prdida de un mensaje ACK. Ante un retardo excesivo (en la red) de un paquete de datos o ACK.
Temporizacin: con un temporizador de cuenta descendente (hacia atrs).

rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer Wait for call 0from above Wait for ACK0 rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )
rdt_rcv(rcvpkt)
timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop_timer
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) stop_timer Wait for ACK1 rdt_send(data) Wait for call 1 from above
timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) )
rdt_rcv(rcvpkt)
sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer
Construccin del protocolo. Rdt 3.0 El emisor en algn momento:

Debe inicial la temporizacin. Debe responder a una interrupcin del temporizador. Detener el temporizador.
Protocolo de bit alternante: ya que los nmeros de secuencia alternan valores entre 0 y 1.
Construccin del protocolo. Rdt 3.0 Rendimiento de rdt 3.0.

Ej: emisor y receptor enlazados con:
Enlace de 1GB (109 bits).
RTT=30 ms. => tprop=15ms. Paquete de 8000bits.
d trans
L 8000bits = = = 8 s 9 R 10 bps
El ltimo bit del paquete llega al receptor tras t=RTT/2+dtrans=15.008 ms Supongo que dtrans del paquete ACK es despreciable (paquete pequeo), y el receptor enva ACK tan pronto como recibe el ltimo bit de datos. El ltimo bit del paquete llega al receptor tras t=RTT+dtrans=30.008 ms
Construccin del protocolo. Rdt 3.0 Rendimiento de rdt 3.0.

Ej: Observar que:
El emisor transmite en dtrans=8 s. El emisor tiene que esperar para emitir el siguiente paquete t=RTT+dtrans=30.8 ms Se define la tasa de utilizacin o de uso del canal: fraccin de tiempo que el emisor est transmitiendo mientras est el canal ocupado: .008 L/R U = = 0.00027 = emisor 30.008 RTT + L / R microsec Supone una tasa efectiva de 267kbps (frente al Gbps). Desaprovechamiento Se han despreciado tiempos de procesamientos de protocolos de capa inferior, retardos de routers intermedios => peor rendimiento.
Rendimiento del protocolo rdt 3.0

emisor Trans. del bit1 del pqt1; t=0 Trans. del bit ltimo. pqt1 , t = L / R Llega el bit1 del pqt1 Llega el ltimo bit del pqt1 Envo de mensaje ACK receptor
RTT
Llega mensaje ACK, Envo siguiente pqt, t = RTT + L / R
emisor
L/R RTT + L / R
.008
30.008
= 0.00027
microsec
Rendimiento del protocolo pipelining

emisor
Trans. del bit1 del pqt1; t=0 Trans. del bit ltimo. pqt1 , t = L / R
receptor
RTT
Llega el bit1 del pqt1 Llega el ltimo bit del pqt1. ACK Llega el ltimo bit del pqt2. ACK Llega el ltimo bit del pqt3. ACK
Llega mensaje ACK, Envo siguiente pqt, t = RTT + L / R
Aumento del rendimiento Factor de 3
emisor
3*L/R RTT + L / R
.024
30.008
= 0.0008
microsecon
Protocolos pipelining.
Procesamiento en cadena de varios paquetes, en lugar de stop-and-wait de cada paquete.
El emisor enva varios paquetes sin esperar sus respectivos ACKs.
Consecuencias sobre los protocolos de transferencia de datos fiables:

Se incrementa el rango de nmeros de secuencia (mltiples pqt. con sus retransmisiones coexisten en el canal). Buffer en el lado emisor con pqt. transmitidos y no reconocidos. Tambin buffer en el receptor. Rangos y buffers dependen de mtodo para recuperar errores con pipelinig. GBN (Go-Back-N). SR (Selective Repeat)
Protocolo Retroceder N (GBN) Go-Back-N: el emisor transmite simultneamente N paquetes sin tener que esperar a ser reconocidos.
Tamao de ventana N: nmero mximo de paquetes no reconocidos. Paquetes transmitidos y reconocidos: [0 base-1]. Paquetes transmitidos y no reconocidos: [base signumsec-1]. Paquetes que pueden ser transmitidos (si hay datos de capa superior): [signumsec base+N]
Protocolo Retroceder N (GBN)

N: rango de nmero de secuencia permitidos en cada instante. Bits para el rango k. Rango [0 2k-1] Al evolucionar GBN los rangos de secuencia N se desplazan hacia adelante: Protocolo de ventana deslizante. Lmites finitos de N. Razones:
Control de flujo. Control de congestin TCP.
Implementacin de GBN en FMS ampliada.

Basado en reconocimientos ACK. No emplea NAK. Aade variables base y signumbase. Aade buffer al emisor.
Protocolo Retroceder N (GBN) El emisor opera:

Si la ventana no est llena crea y enva pqts. Caso contrario la capa superior lo volver a intentar posteriormente (sincronizacin con flag). El reconocimiento ACK es acumulativo: para todos los pqts con un num. sec. <= N. Un suceso de fin de temporizacin (pqt perdido o retardado), obliga al emisor a reenviar todos los paquetes transmitidos y no reconocidos.
Retroceso de ventana: Retroceder N. Un nico temporizador, para pqts transmitidos pero no reconocidos.
Si se recibe un ACK, reinicia el temporizador. Si no hay pqts no reconocidos, se detiene el temporizador.


rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data) timeout start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) udt_send(sndpkt[nextseqnum-1])
base=1 nextseqnum=1
Wait
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer

El receptor opera:
Si llega un pqt con nmero de secuencia n correcto y en orden, se enva ACKn y entrega sus datos a la capa superior. Confirmaciones acumulativas del protocolo GBN. En el resto de casos, el receptor descarte el pqt. y reenva un ACK para el pqt recibido en orden ms reciente. Descarta pqts que llegan fuera de orden. Razones de simplificacin del protocolo Slo necesita numsecesperado No hay necesidad de buffer en el receptor.
default udt_send(sndpkt) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++
Wait expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum)
Protocolo Repeticin selectiva (SR) GBN plantea problemas con:

Tamaos de ventana grandes. Producto ancho de banda-retardo grande Retransmisin innecesaria de pqt perdido Dictado de mensaje: repetir frase de 1000 palabras por prdida de 1 palabra.
SR: retransmite slo aquellos pqts que se sospeche que llegaron al receptor con error (corrupto o perdido).
Necesidad de que el receptor confirme individualmente que paquetes ha recibido. Tamao de ventana N. El receptor confirma un pqt correcto aunque est fuera de orden.
Protocolo Repeticin selectiva (SR)

Se emplea mltiples temporizadores (hardware) contra la prdida de paquetes. Slo se retrasmite paquete perdido por fin de su temporizacin. El receptor confirma un pqt correcto aunque est fuera de orden. Buffer en el receptor: almacena los pqts recibidos fuera de orden (hasta completar los que faltan).

emisor data from above :
if next available seq # in window, send pkt
receptor pkt n in [rcvbase,

rcvbase+N-1]
r r r
timeout(n):
resend pkt n, restart timer
ACK(n) in
[sendbase,sendbase+N]:
mark pkt n as received if n smallest unACKed pkt, advance window base to next unACKed seq #
send ACK(n) out-of-order: buffer in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt
[rcvbase-N,rcvbase1]
pkt n in
r
ACK(n) ignore
otherwise:
r

Problemas con los tamaos de ventana y rango de nmeros de secuencia.
2 escenarios distintos que el receptor no distingue.
N secuencia: 0,1,2,3 (2 bits). Tamao de ventana: 3
Solucin: tamao de ventana < = tamao de espacio de n sec.
El tamao de ventana debe ser menor o igual que la mitad del tamao del espacio de n de sec.
ndice
1. 2. 3. 4.
La capa de transporte y sus servicios. Multiplexacin y demultiplexacion. Transporte sin conexin: UDP. Principios de un servicio de transferencia de datos fiable.
5.
6. 7.
Transporte orientado a la conexin: TCP.

Principios de control de congestin. Mecanismo de control de congestin de TCP.
TCP
Protocolo de capa de transporte de Internet, fiable y orientado a la conexin. Principios: mecanismos de deteccin de errores, retransmisiones, reconocimientos acumulativos, temporizadores, n de secuencia y de reconocimiento. RFCs: 793, 1122, 1323, 2018, 2581. Conexin TCP: proporciona servicio full-duplex (bidireccionalidad, simultaneidad). Conexin punto a punto (unicast). No es posible multidifusin (multicast, broadcast). Orientado a la conexin: establecimiento de la comunicacin con segmentos preliminares (inicializacin de variables de estado TCP y buffers).
Se ejecuta en sistemas terminales (procesos servidor y cliente). No se ejecuta en equipos de red (routers, etc).
Socket socketCliente = new Socket(nombrehost,NmeroPuerto);
Establecimiento de conexin: Acuerdo en tres fases.

Cliente enva segmento TCP especial al servidor (sin carga). Servidor responde segmento TCP especial al cliente (sin carga). Cliente enva nuevo segmento TCP especial al servidor (con carga til de datos)
TCP
socket door application writes data TCP send buffer
segment
application reads data TCP receive buffer
socket door
Establecida la conexin se intercambian datos el cliente-servidor.

El cliente pasa flujo de datos a travs del socket a TCP del cliente. TCP cliente los lleva al buffer de emisin.
Fragmenta (divide) los datos y los enva encapsulados en el segmento. Tamao de los fragmentos de datos? Mximo valor posible MSS: Maximun Segment Size.
Condicionado por la longitud de la trama ms larga de la capa de enlace que el host local puede enviar (MTU: Maximun Transmission Unit) MTUs de 1460, 536, 512 bytes.
RFC dice: debe transmitir esos datos en segmentos (enunciado ambiguo de RFC 793). Cliente TCP encapsula fragmento de datos formando segmento TCP. Los segmentos se pasan a la capa de red, donde se encapsulan formando paquetes/datagramas IP en la capa de red. Etc.
TCP servidor recibe segmento en el otro extremo y lo lleva al buffer recepcin. Cada conexin TCP posee buffers, variables y socket a un Profesor: Carlos Elvira proceso en un host origen y lo mismo en el host destino. Izurrategui
ndice
1. 2. 3. 4.
5.

1. 2. 3. 4.
Estructura de TCP Transferencia de datos fiable Control del flujo Gestin de la conexin
6. 7.
TCP. Estructura
Consta de:
Datos: fragmento de datos de aplicacin.
Limitado a MSS.
Cabecera: normalmente de 20 bytes.

Puede tener tamao variable. Utilizando:
Campo opciones de cabecera: tamao variable. Se utiliza cuando se negocia el MSS o como un factor de escala de ventana en redes de alta velocidad. RFCs 854 y 1323. Campo longitud de cabecera: 4 bits. Define el tamao de opciones. Si es = 0 cabecera estndar de 20 bytes. Campo Indicadores (flags): 6 bits. ACK: segmento contiene un reconocimiento para un segmento que ha sido recibido correctamente. RST, SYN y FIN: establecimiento y cierre de conexiones. PSH: indica que el receptor deber pasar los datos a la capa superior inmediatamente. URG: los datos del segmento son urgentes (marcados desde la capa de aplicacin del emisor). Apuntados por el campo puntero de datos urgentes Puntero de datos urgentes
TCP. Estructura
32 bits URG: datos urgentes (no muy usado) ACK: ACK # vlido PSH: pasar datos ya (no muy usado) RST, SYN, FIN: Bits de establecimiento y cierre de la conexin
port # origen
port # destino
nmero de secuencia nmero de reconocimiento

long no UA P R S F cab used
contaje de los bytes de datos (no segmentos!) # bytes que el receptor est dispuesto a aceptar
ventana recepcin Ptr. datos urgentes
checksum
Opciones (longitud variable)
Checksum de Internet (igual que UDP)
Datos de aplicacin (longitud variable)
TCP. Nmeros de secuencia y reconocim. TCP percibe los datos como un flujo de bytes no estructurado pero ordenado.
El nmero de secuencia: hace referencia al flujo de bytes transferido (1 byte del flujo).
Ejemplo: archivo de 500000bytes con MSS de 1000 bytes.=> 500 segmentos.
1 segmento con num. sec= 0. 2 segmento con num. sec= 1000. Etc.
El nmero de reconocimiento incluye el nmero de secuencia del siguiente byte que espera recibir.
Considerar full-duplex y host A y B. Ejemplo1: A ha recibido de B bytes [0 539].
Siguiente segmento de A a B incluir num. Rec=540.
TCP. Nmeros de secuencia y reconocim.

Ej1: A ha recibido de B bytes [0 539].
Siguiente segmento de A a B incluir num. Rec=540.
Ej2: A ha recibido de B bytes [0 539] y [900 1000].

Siguiente segmento de A a B incluir num. Rec=540. TCP slo confirma bytes hasta encontrar prdidas Reconocimiento acumulativo.
Ej3: A ha recibido de B bytes [900 1000] y luego [0 539] (desorden en la llegada).

OJO. RFC no imponen nada; existen opciones: Receptor descarta bytes del segmentos fuera de orden. Receptor mantiene bytes no ordenados hasta que lleguen el resto (rellenar huecos). Mtodo utilizado en la realidad: eficiencia en la red.
TCP. Ejemplo en Telnet

Telnet (RFC 854): conexin remota Host B Host A trabajando bajo TCP. Usuario Sec=4 2, AC K=79, Es iterativa con escribe datos = C host reconoce C eco de (ACK) la caracteres. recepcin Cada carcter C de C, y s= , dato atraviesa la red 43 devuelve ACK= =79, 2 veces. Sec eco C El reconocimiento reconoce host est (ACK) la Sec=4 3, ACK superpuesto al recepcin =80 segmento de del eco datos de C
tiempo Escenario simple de telnet
TCP. Estimacin del RTT y temporizacin. TCP con prdida de segmentos utiliza retransmisin controlada con temporizadores.
Tiempos de temporizacin?
Si se definen tiempos cortos => timeout.
Retransmisiones innecesarias.
Si se definen tiempos largos =>

Reacciones lentas ante prdidas.
Mayores que los RTT de la conexin.

RTT vara => estimacin.
Estimacin del tiempo de ida y vuelta

RTTMuestra para un segmento: tiempo que transcurre desde que se enva un segmento (pasa a capa IP), hasta que se recibe su correspondiente reconocimiento.
TCP. Estimacin del RTT y temporizacin.

Las implementaciones TCP toman una sla medida de RTTMuestra de un solo segmento transmitido (no coge retransisiones) pero no reconocido. Se toma nuevo valor cada RTT segundos aproximadamente. RTTMuestra flucta de un segmento a otro. => valores atpicos. Valor RTT tpico: estimar algn valor promedio de los valores RTTMuestra:
RTTEstimado = (1- )* RTTEstimado + *RTTMuestra
Combinacin ponderada del valor anterior RTTEstimado y RTTMuestra. =0.125.

RTTEstimado = 0.875* RTTEstimado +0.125*RTTMuestra
Media mvil exponencialmente ponderada EWMA (Exponential Weight Moving Average). La influencia de las muestras pasadas decrece exponencialmente

RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
350
300
RTT (milliseconds)
250
200
150
100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds) SampleRTT Estimated RTT

Medida de la variabilidad de RTT a travs de la estimacin de la desviacin tpica RTTMuestra de RTTEstimado:
RTTDesv = (1- )* RTTDesv + * |RTTMuestra-RTTEstimado|
Es una media EWMA de la diferencia entre RTTMuestra y RTTEstimado. Si RTTMuestra tienen poca fluctuacin RTTDesv pequeo. Si RTTMuestra tienen gran fluctuacin RTTDesv grande. Valores recomendados =0.25
TCP. Estimacin del RTT y temporizacin. Valor del intervalo de temporizacin.

Mayores que los RTTEstimado. Caso contrario
Retransmisiones innecesarias.
Si se definen muy por encima de RTTEstimado =>

Reacciones lentas ante prdidas.
Tomar RTTEstimado + margen.

Margen grande cuando RTTDesv grande. Margen pequeo cuando RTTDesv pequeo.
Intervalo de temporizacin:
IntervaloFinTemporizacin = RTTEstimado + 4 * RTTDesv
ndice
1. 2. 3. 4.
5.

1. 2. 3. 4.
6. 7.
Transferencia de datos fiable en TCP

Capa de red de Internet no es fiable:
No garantiza la entrega de datagramas (prdidas en cola del router) Tampoco su orden (segn camino escogido). Ni la integridad en sus datos (corruptos por ruido o por mal almacenamiento en memoria).
Los segmentos transportados en estos paquetes pueden sufrir estos problemas. TCP proporciona un servicio de transferencia de datos fiable sobre el servicio de mejor esfuerzo (no fiable) de IP.
Garantiza que el flujo de datos que un proceso extrae del buffer de recepcin TCP no est corrupto. No contiene huecos (prdidas de segmentos), ni duplicados. Est en orden, tal y como lo enva el extremo emisor.
Tcnicas de la transferencia de datos fiable:

Procesamiento de mltiples segmentos en cadena (pipelining). Reconocimientos acumulados. Retransmisiones realizadas cuando:
Hay final de temporizacin. Reconocimiento duplicados.
Pero OJO: slo un nico temporizador de retransmisin, incluso aunque haya varios segmentos trasmitidos y an no reconocidos. (RFC 2988).
Transferencia de datos fiable en TCP Funcionamiento de TCP. Hay 3 eventos importantes en el emisor relacionados con la transmisin y retransmisin de datos.
Datos recibidos desde la aplicacin. Acciones
Crear segmento TCP con #numsec=SigNumSec. Si (timer no se est ejecutando) IniciarTemporizador.
El temporizador est asociado al segmento no reconocido ms antiguo.
Pasar segmento a IP. SigNumSec=SigNumSec+longitud(datos)
Fin de temporizacin. Acciones

Retransmitir segmento aun no reconocido con #numsec ms pequeo (antiguo). IniciarTemporizador.
Transferencia de datos fiable en TCP

Llegada de un reconocimiento ACKi. Acciones
Si(i>BaseEmision){ BaseEmision=i Si (existen actualmente segmentos no reconocidos) Iniciar temporizador }
SigNumSec = NumeroSecuenciaIncial BaseEmision = NumeroSecuenciaIncial loop (siempre) { switch(evento) evento: datos recibidos de la aplicacin de la capa superior crear segmento TCP con nmero de secuencia SigNumSec si (el temporizador no se est ejecutando actualmente) iniciar temporizador pasar segmento a IP SigNumSec = SigNumSec + longitud(datos) evento: fin de temporizacin del temporizador retransmitir el segmento aun no reconocideo con el nmero de secuencia ms pequeo iniciar temporizador evento: ACK recibido, con valor de campo ACK igual a i si (i > BaseEmision) { BaseEmision = i si (existen actualmente segmentos aun no reconocidos) iniciar temporizador } } /* fin buble */
TCP fiable. Escenarios

Host A
Sec=9 2, 8 b yt
Host B
es dat os
00
Host A
Host B
fin temporizacin
=1 ACK
Sec=92 timeout
Sec=9 2, 8 b ytes d atos Sec= 100, 20 by tes d atos

00 0 =1 CK CK=12 A A
perdido
Seq=9 2, 8 b yt es da tos
Sec=92 timeout
=100 ACK
BaseEmision = 100 BaseEmision = 120
Sec=9 2, 8 b yt
es dat os
20 K=1 AC
BaseEmisin = 100
BaseEmision = 120
tiempo Escenario de prdida de ACK
tiempo Fin temporizacin antes de tiempo

TCP fiable. Escenarios

Host A
Sec=9 2, 8 b yt
Host B
es dat os
timeout
Sec=1 00, 20 b
Perdido
BaseEmisin = 120
120 CK= A
100 CK= A ytes d atos
tiempo Escenario de ACK acumulado
TCP fiable. Intervalos de temporizacin

Intervalos de temporizacin:
Datos recibidos desde la aplicacin. Acciones
IniciarTemporizador.
IntervaloFindeTemporizacion = f(RTTEstimado, RTTDesv).
Fin de temporizacin.
IntervaloFindeTemporizacion =2 * timoValorIntervaloFindeTemporizacin. Se trata de propocionar mecanismo simple de control de congestin congesti
Llegada de un reconocimiento ACK. Acciones

IntervaloFindeTemporizacion = f(RTTEstimado, RTTDesv).
TCP fiable. Generacin de ACKs

Generacin de ACKs en TCP: FRC 1122 y 2581 Accin del receptor TCP Evento en el receptor
Llegada de un segmento en orden con el nmero de secuencia esperado. Todos los datos hasta el nmero de secuencia esperado ya han sido reconocidos Llegada de un segmento en orden con el nmero de secuencia esperado. Hay otro segmento en orden esperando la transmisin de un ACK Llegada de un segmento desordenado con un nmero de secuencia ms alto que el esperado. Se detecta un hueco ACK retardado. Esperar hasta 500 ms la llegada otro segmento en orden. Si el siguiente segmento En orden no llega en este intervalo, enviar ACK.
Enviar inmediatamente un nico ACK acumulado, reconociendo ambos segmentos ordenados
Enviar inmediatamente un ACK duplicado indicando el nmero de secuencia del siguiente byte esperado (lmite inferior del hueco) reconociendo ambos segmentos ordenados. Enviar inmediatamente un ACK, suponiendo que el segmento comienza en el lmite inferior del hueco.
Llegada de un segmento que completa parcial o totalmente el hueco existente en los datos recibidos
TCP fiable. Retransmisiones rpidas

Retransmisiones: cuando surge fin de temporizacin (timeout). Intervalo timeout grande provoca un retardo en la retransmisin entre los 2 terminales. Solucin: ACKs duplicados provocan retransmisiones rpidas.
El receptor detecta llegada de segmento desordenado con nmero de secuencia superior al esperado => hay un hueco en la ventana (falta un segmento)
No se utilizan NAK, sino ACKs duplicados. Un ACK duplicado es un ACK que vuelve a reconocer un segmento para el que el emisor ya ha recibido un reconocimiento anterior.
El emisor suele enviar varios segmentos juntos (pipelining) y, si pierde uno, recibir muchos ACKs duplicado seguidos. Si se recibe 3 ACKs duplicado => el emisor realiza una retransmisin rpida (RFC 2581)
TCP fiable. Retransmisiones rpidas

Si se recibe 3 ACKs duplicado => el emisor realiza una retransmisin rpida (RFC 2581)
Host A Host B
El emisor no necesita esperar la finalizacin de la temporizacin (timeout).

evento: ACK recibido, con valor de campo ACK igual a i si (i > BaseEmision) { BaseEmision = i si (existen actualmente segmentos aun no reconocidos) iniciar temporizador } sino { /* ACK duplicado para un segmento ya reconocido */ incrementar el nmero de mensajes ACK duplicados recibidos para i si (nmero de ACKs duplicados recibidos para I = 3) /* Se detecta retransmisin rpica */ reenviar el segmento con nmero de secuencia I }
timeout
reenv ia
r 2 nd s egme nto
tiempo
TCP fiable. GBN o RS?

Semejanzas con GBN.
TCP tiene reconocimientos acumulados. Los segmentos correctamente recibidos, pero fuera de orden, no son reconocidos individualmente por el receptor.. El emisor necesita:
Nmero de secuencia del segmento ms antiguo: BaseEmisin. Nmero de secuencia del siguiente byte que se va a enviar: SigNumSec.
Implementaciones TCP almacenan en buffer recepcin segmentos correctos fuera de orden.

Ej: se enva segmentos 1..N y se pierde ACKn, pero los ACKN1 restantes llegan al emisor antes de sus timeout.
GBN retransmitira paquetes n, n+1,..N. TCP retransmite paquete n (OJO: si el ACKn+1 no llega antes que su correspondiente timeout) .
RFC 2018: reconocimiento selectivo de TCP.

Permite a un receptor TCP reconocer segmentos no ordenados TCP de forma selectiva, sin hacer reconocimiento acumulado del ltimo segmento recibido OK y en orden.
ndice
1. 2. 3. 4.
5.

1. 2. 3. 4.
6. 7.
TCP. Control de flujo.

TCP dispone de un buffer de recepcin en cada lado de la conexin..
Si TCP recibe segmentos correctos y en orden los coloca en el BufferRecepcin. OJO: el proceso aplicacin receptor no tiene porqu leer estos segmentos inmediatamente.
Puede estar ocupada haciendo otras tareas/procesos.
Problema: si la aplicacin no lee los segmentos en un breve plazo el BufferRecepcin lo llena el emisor rpido.
Solucin: utilizar el servicio de control de flujo. Es un servicio de adaptacin de velocidades; velocidad que transmite la aplicacin emisor frente a la velocidad que recoge la aplicacin receptor.
Distinto concepto que control de congestin: el emisor se atasca por problemas (de congestin) de la red.

Mecanismo de control de flujo en TCP:
Variable VentanaRecepcin dinmica en el tiempo: proporciona al emisor una idea del espacio libre en el BufferRecepcin.
TCP full-duplex. El emisor de cada lado de la conexin posee VentanaRecepcin distinta.

Ej: Host emisor A enviando archivo grande al host receptor B por TCP.
Host receptor B asigna BufferRecepcin a conexin TCP. Variable UltimoByteLeido: n ltimo byte del flujo de datos del buffer ledo por el proceso de aplicacin del host B. Variable UltimoByteRecibido: n del ltimo byte del flujo de datos que ha llegado desde la red y se ha almacenado en el BufferRecepcin del host B.
UltimoByteRecibido - UltimoByteLeido <= BufferRecepcin VentanaRecepcin = BufferRecepcin [UltimoByteRecibido- UltimoByteLeido]
El valor de VentanaRecepcion es un campo de la cabecera TCP que permite al host receptor B informar al emisor A del espacio libre.
Inicialmente se cumple: VentanaRecepcin = BufferRecepcin. A su vez el emisor crea variables UltimoByteEnviado y UltimoByteReconocido. El host emisor A se debe asegurar durante la conexin que:
UltimoByteEnviado - UltimoByteReconocido <= VentanaRecepcin
Problema: Suponer el buffer recepcin lleno => VentanaRecepcion = 0, y B no tiene nada que enviar a A.
Proceso de aplicacin B vaca el buffer y TCP no enva nuevos segmentos a A con valores de VentanaRecepcin. Host A no es informado de que hay espacio en el buffer de recepcin de B (situacin de bloqueo de transmisin). Especificacin TCP requiere al host A que contina enviando segmentos con un byte de datos cuando la longitud de ventana de recepcin de B es cero.
UDP no proporciona control de flujo:

Transmisin de segmentos UDP desde proceso de aplicacin emisor en host A a un proceso en host B.
UDP almacenar los segmentos en el buffer de tamao finito antesala del socket. El proceso receptor lee un segmento completo cada vez. Si el proceso receptor no lee los segmentos del buffer lo suficientemente rpido, se desbordar y se descartarn los siguientes.
ndice
1. 2. 3. 4.
5.

1. 2. 3. 4.
6. 7.
TCP. Gestin de la conexin.
Importancia de la conexin:
Puede aumentar el retardo percibido por los usuarios. Ataques de red por inundacin va SYN.
Pasos en el establecimiento de conexin:

A/. TCP cliente enva un segmento TCP especial (segmento SYN).
No contiene datos de aplicacin. Cabecera. Bit SYN =1. Cliente selecciona de forma aleatoria el nmero de secuencia inicial: cliente_nsi
B/. El servidor extrae dicho segmento SYN del datagrama, asigna variables y buffers TCP a la conexin, y enva un segmento (SYNACK) de conexin concedida TCP.
TCP. Establecimiento de la conexin.

No contiene datos de aplicacin. Cabecera. Bit SYN =1. Cabecera. Nmero de reconocimiento=cliente_nsi+1. Servidor selecciona de forma aleatoria el nmero de secuencia inicial: servidor_nsi
C/. El cliente recibe el segmento SYNACK, asigna buffers y variables a la conexin, y vuelve a enviar otro segmento confirmando al servidor la conexin concedida.
Si puede contener datos de aplicacin. Cabecera. Bit SYN =0. Nmero reconocimiento:servidor_nsi+1. Nmero de secuencia: cliente_nsi+1.
Acuerdo de tres fases: A/. B/. y C/.

Socket clientSocket = new Socket("hostname","port number"); Socket connectionSocket = welcomeSocket.accept();
TCP. Establecimiento de la conexin. Acuerdo de tres fases: A/. B/. y C/.

Socket clientSocket = new Socket("hostname","po rt number"); Socket connectionSocket = welcomeSocket.accept( );
Sol conex
cliente
servidor
SYN= 1, sec =clien te_
nsi
Conex. Conce.
ACK
si, or_n id serv sec= e_nsi+1 =1 , SYN k=client ac
SYN= 0, se ack=s c=cliente_n s ervido r_nsi+ i+1 a
TCP. Cierre de la conexin.

Pasos:
1. Cliente enva segmento especial FIN al servidor.
cliente
cerrar
servidor
FIN
FIN= 1.
2. Servidor reconoce el segmento FIN al cliente. 3. El servidor enva segmento especial FIN al cliente.
ACK FIN
cerrrar
Tiempo espera
FIN = 1.
4. El cliente reconoce la desconexin al servidor.
ACK
Se liberan recursos.
cerrado
clientSocket.close();
Escenario con servidor que recibe segmento TCP con puerto o IP que no se corresponde con los sockets activos:
El host enva al origen un segmento especial de reinicio.
RST = 1.
No tengo socket para ese segmento, no lo reenves
Explorar puertos con nmap:

Enviar segmento SYN al puerto deseado. 3 posibles respuestas:
Origen recibe segmento TCP SYNACK: hay aplicacin activa con TCP en ese puerto (puerto abierto). Origen recibe un TCP RST: no hay aplicacin activa en ese puerto (puerto no bloqueado por cortafuegos). Origen no recibe nada. (puerto bloqueado por cortafuegos)
ndice
1. 2. 3. 4. 5.
La capa de transporte y sus servicios. Multiplexacin y demultiplexacion. Transporte sin conexin: UDP. Principios de un servicio de transferencia de datos fiable. Transporte orientado a la conexin: TCP.
1. 2. 3. 4.
6.
7.
Principios de control de congestin.

Mecanismo de control de congestin de TCP.
Principios de control de congestin

Desbordamiento de buffers de routers provocan congestin en la red prdidas de paquetes en la red, y retardos en la transmisin de paquetes.
La retransmisin de paquetes de TCP se ocupa de paliar la congestin de red, pero no soluciona la causa que origina la congestin. Tratamiento de la causa de la congestin con mecanismos que regulen el trfico de los emisores.
Es un problema principal a estudiar en las redes de comunicaciones. Comprender la congestin de red.

Entender el rendimiento en las aplicaciones de red. Estudiar mtodos para evitar la congestin. Mtodos para reaccionar ante la congestin.
Causas y costes de la congestin Estudio de la congestin en escenarios con complejidad creciente.

Estudio de causas y coste.
Escenario 1: 2 emisores, 1 router con buffers de capacidad ilimitada.

2 hosts A y B que comparten un enlace de salida del router, tansmitiendo ambos a in bytes/s. Protocolo de transporte simple sin recuperacin de errores (no retransmite), ni hay control de flujo ni de congestin. Ignorar sobrecarga adicional debida a las cabeceras de capa de transporte e inferiores.
Causas y costes de la congestin
Escenario 1: 2 emisores, 1 router con buffers de capacidad ilimitada.

Enlace de salida del router compartido con capacidad R. Buffers de capacidad ilimitadas
Host A
in : datos originales
out
Host B
Buffers del enlace de salida compartidos no limitados

Retardos crecen al aproximar a R/2. En la transmisin R/2, nmero medio de paquetes en cola no limitada, retardo infinito. Coste de la red congestionada: grandes retardos de cola experimentados cuando la tasa de llegada de los paqutes se aproxima a la capacidad del enlace
Escenario 2: 2 emisores, 1 router con buffers finitos de capacidad.

Los paquetes se descartarn cuando el buffer est lleno. Conexin fiable (retransmisin)
Host A
in : datos originales 'in : datos originales ms retardos retransmitidos
out
Host B
Buffers del enlace de salida compartidos y con capacidad finita
Causas y costes de la congestin Escenario 2:

Velocidad de transmisin de datos originales. Velocidad de transmisin de segmentos (datos originales y retransmisiones)en capa de transporte: carga ofrecida. Hay 3 casos:
1. Host A slo enva si el buffer no est lleno (hiptesis no real de que sabe como est el buffer). in = in = out.
Rendimiento ideal: todo lo que se enva se recibe (no hay prdidas de paquetes).
2. Host A retransmite si sabe con seguridad que el paquete se perdi (hiptesis exagerada).
Observar en carga ofrecida R/2 se cumple: Velocidad transmisin:05R Velocidad de datos recibidos: 0,333R. Velocidad de datos retransmitidos: 0.166R

Costes de la red congestionada: el emisor
tiene que realizar retransmisiones para compensar paquetes descartados (perdidos) a causa de un desbordamiento en el buffer.
3. El emisor puede alcanzar el fin de la temporizacin prematuro y retransmitir un paquete retardado en cola que no se ha perdido todava.
Al receptor puede llegar original y retransmisin. Slo necesita uno de ellos. Se desperdicia la transmisin o retransmisin. Coste de la red congestionada: retransmisiones innecesarias del emisor causadas por retardos largos pueden llevar a que el route utilice ancho de banda del enlace para copias innecesarias.
R/2
R/2
R/2
R/3
out
out
out
R/2
R/4
in
R/2
in
in
R/2
a.
b.
c.
Escenario 3: 4 emisores, 4 routers con buffers finitos y rutas con varios saltos
Rutas solapadas con 2 saltos. Protocolo fiable con mecanismo de fin de temporizacin/retranmisin
Host A
in : datos originales
out
'in : datos originales ms retardos retransmitidos

Buffers del enlace de salida compartidos y con capacidad finita
Host B
Escenario 3:
Todos tienen valores in, in y todos los enlaces tienen capacidad R [B/s]. Analizar conexin de Host A al C (comparte ruta con Host B al D y routers R1 y R2).
Para pequeos in difcil desbordar buffer.
out= in (tasa transf. = carga ofrecida).
in provocan out
Para grandes in se desbordan buffers.

Conexiones A-C y B-D compiten en el router R2. Si trfico intenso B-D es mucho mayor que A-C la tasa de transf. out tiende a cero. Decrece la tasa de trans. con la carga ofrecida. Se desperdicia trabajo del router R1
Escenario 3:
Coste de descartar un paquete a causa de la congestin de red: Cuando un paquete se descarta a lo largo de una ruta, la capacidad de transmisin empleada en cada uno de los enlaces anteriores para encaminar dicho paquete hasta el punto en el que se ha descartado termina por desperdiciarse
Mtodos para controlar la congestin
Mtodos comunes para controlar la congestin:

Segn si la capa de red aporta ayuda a la capa de transporte con propsitos de controlar la congestin
1. Control de congestin terminal a terminal.
La presencia de congestin en la red se debe inferir en los sistemas terminales segn el comportamiento observado en la red (prdida de paquetes). Ejemplo: TCP.
2. Control de congestin asistido por la red.

Los componentes (routers) de red realimentan al emisor con informacin (bit) explcita del estado de congestin de la red.
Mtodos para controlar la congestin

Ej.: arquitecturas SNA (IBM) y DECnet (DEC). Redes ATM con ABR (Available bitrate). 2 formas de realimentar la informacin al emisor: Realimentacin directa desde un router al emisor. Notificacin de paquete de asfixia o bloqueo (chocket packet). Estoy congestionada Marcado de congestin en un campo en un paquete que se trasmite en un canal al pasar por el router. Tarda al menos un RTT.
Control de congestin en redes ATM Redes ATM: control de congestin en el servicio ABR (available bit-rate).
ATM emplea circuitos virtuales para la conmutacin de paquetes. Cada dispositivo de conmutacin a lo largo de la ruta mantiene el estado del circuito virtual seleccionado entre el origen y el destino. Un dispositivo de conmutacin puede conocer el comportamiento de cada emisor individual (velocidad media de transmisin). Se consigue control de congestin asistido por red. ABR es un servicio de transferencia de datos elstico.
Red poco cargada, ABR aprovecha todo el BW Red congestionada, ABD reduce velocidad.
Control de congestin en redes ATM

Terminos: Dispositivo de conmutacin: routers. Celdas: paquetes
De datos y de gestin de recursos (celdas RM) intercaladas. 1 celda RM intercalada cada 32 celdas de datos. Parmetro de intercalado configurable Celdas RM: transportan informacin de control de congestin: Entre dispositivos hosts terminales (realimentacin de receptor). Y dispositivos de red (realimentacin directa de red).

BITs CI (Congestion Indication) y NI (No increase): bits de una celda RM. Dispositivo de conmutacin pone NI =1; congestin leve. Dispositivo de conmutacin pone CI =1; congestin severa. El host destino reenva celda RM al emisor. Campo ER (Explicit Rate) de 16 bits en celda RM. Dispositivo de conmutacin puede reducir su valor al crecer su congestin. Es un indicador de velocidad mnima soportable de todos los dispositivos de conmutacin en la ruta entre origen y destino.
Un emisor ajusta su velocidad segn los valores recibidos de CI, NI y EFCI en las celdas RM.
Algoritmos de ajuste complejos.

Mtodo de control de congestin ABR: basado en la velocidad.
El emisor calcula la velocidad mxima a la que puede transmitir y se adapta (autoregula). Mecanismos de sealizacin utilizados.
Bit EFCI (Explicit Forward Congestion Indication): bit en una celda de datos que indica congestion en la red al host destino. Este bit lo activan los dispositivos de conmutacin (congestionado). Este bit lo analizan los destinatarios. Si EFCI =1. Provoca en una celda RM poner su bit (Indicador de congestin) CI = 1. Se devuelve la celda RM al emisor. BITs CI (Congestion Indication) y NI (No increase): bits de una celda RM. Dispositivo de conmutacin pone NI =1; congestin leve. Dispositivo de conmutacin pone CI =1; congestin severa.
ndice
1. 2. 3. 4. 5.
La capa de transporte y sus servicios. Multiplexacin y demultiplexacion. Transporte sin conexin: UDP. Principios de un servicio de transferencia de datos fiable. Transporte orientado a la conexin: TCP.
1. 2. 3. 4.
6.
Principios de control de congestin.
7.
Mecanismo de control de congestin de TCP.
Control de congestin en TCP Control de congestin terminal a terminal (sin ayuda de red). Mtodo: cada emisor limita su velocidad de transferencia de trfico en funcin de la congestin percibida.
Emisor percibe que existe congestin; reduce su velocidad de transmisin. Caso contrario la aumenta.
Cmo limita el emisor TCP la velocidad a la que enva el trfico? Cmo percibe el emisor que existe congestin en la ruta? Qu algoritmo emplea el emisor para variar su velocidad de transmisin?
Control de congestin en TCP Mtodo del emisor TCP para limitar la velocidad de transmisin.
Recordar que:
En cada lado de la conexin existen buffers de emisin, recepcin Existe variables (BufferRecepcin, UltimoByteRecibido, etc).
Nueva variable VentanaCongestin: impone al emisor una restriccin sobre su velocidad de transferencia: la cantidad de datos no reconocidos no puede exceder el mnimo de entre VentanaCongestin y VentanaRecepcin.
UltimoByteLeido-UltimoByteReconocido <= min{VentanaCongestin, VentanaRecepcin}
Limita la cantidad de datos reconocidos por el emisor; de forma indirecta su velocidad de transmisin.
Control de congestin en TCP

Observar que para el emisor:
Vtrans =VentanaCongestion/RTT. Ajuste de VentanaCongestion, control de Vtrans.
Mtodo para el que perciba el emisor TCP congestin en la red.

Congestin severa en la red: varios buffers de los routers en la ruta sufren desbordamiento (prdidas de paquetes). Recordar que:
Prdida de paquete (suceso FinTemporizacin o 3 ACKs duplicados). No hay congestin de red => emisor recibir segmentos con reconocimiento de datos originales (no duplicados ni perdidos).

La velocidad de llegada de estos ACKs de datos originales permite regular VentanaCongestion Velocidad baja retardo de red o enlace con BW bajo => No aumentar VentanaCongestion. Velocidad alta no hay retardo o BWenlace alto => Aumenta VentanaCongestion.
TCP es auto-temporizado: utiliza sus propios reconocimientos para provocar (temporizar) sus incrementos de VentanaCongestion.
Principios del mecanismo de ajuste de VentanaCongestion:

Un segmento perdido => congestin; la velocidad del emisor TCP debe reducirse. Un segmento que ha sido reconocido=> no hay congestin; la velocidad del emisor TCP debe aumentarse.

Tanteo del ancho de banda: aumentar la velocidad de transmisin hasta provocar prdidas, y reducir as velocidad de nuevo.
Detalles del algoritmo de control de congestin de TCP [Jacobson 1988]:
Arranque lento (slow start). Evitacin de la congestin (congestion avoidance). Recuperacin rpida (fast recovery). Se corta el crecimiento exponencial, al detectar prdida de paquete. Se actualiza VentanaCongestion con un valor de la mitad del valor anterior.
Algoritmo de congestin. Arranque lento Arranque lento: al iniciar conexin TCP, valor de VentanaCongestin=1MSS.
Velocidad de transmisin: 1MSS/RTT. Se incrementa en 1 unidad en cada reconocimiento transmitido. Valores: 1, 2, 4, Exponencial. Se duplica en cada RTT. La velocidad inicial baja (de aqu el nombre) y crece exponencialmente. La finalizacin del crecimiento se da:
Prdida de paquete => VentanaCongestin=1 Variable umbral del arranque lento: se actualiza al valor VentanaCongestin/2.
Se termina arranque lento y se pasa a la etapa evitacin de la congestin.
Algoritmo de congestin. Arranque lento

3 paquetes ACK duplicados (retransmisin rpida).
Se entra en la etapa de recuperacin rpida.
RTT
Host A
Host B
one segm ent
Orgenes del arranque lento: Jacobson 1988.
two segm ents
four segm ents
time
Algoritmo de congestin. Evitacin de la . Evitacin de la congestin

VentanaCongestin/2 (desde arranque lento)
Valor de VentanaCongestin+1. Incremento lineal.

Mtodo ms conservador.
Implementacin ms habitual:
VentanaCongestin=MSS/VentanaCongestin
Parada del crecimiento lineal:

En caso de final de temporizacin:
VentanaCongestin=1. Umbral=VentanaCongestin/2.
En caso de 3 ACKs duplicados.

VentanaCongestin=(VentanaCongestin/2)+3. Umbral=VentanaCongestin/2. Paso a estado de recuperacin rpida.
Algoritmo de congestin. Recuperacin rpid Recuperacin rpida.

Se entra desde arranque lento o evitacin de la congestin + 3 ACKs duplicados. VentanaCongestin+1(MSS) por cada ACK duplicado recibido de un segmento que causo la entrada en recuperacin. Se finaliza:
Llegada de 1 ACK del segmento que falte. Si se produce un fin de temporizacin, se pasa a arranque lento.
VentanaCongestin=1 Umbral=VentanaCongestin/2.
Recuperacin rpida: mecanismo TCP recomendado (RFC 2581).

Algoritmo de congestin. Recuperacin rpid Recuperacin rpida.

TCP Tahoe:
VentanaCongestin=1. Arranque lento.
TCP Reno incorpora recuperacin rpida.
Control de congestin TCP

State Slow Start (SS) Event ACK receipt for previously unacked data ACK receipt for previously unacked data Loss event detected by triple duplicate ACK Timeout TCP Sender Action CongWin = CongWin + MSS, If (CongWin > Threshold) set state to Congestion Avoidance CongWin = CongWin+MSS * (MSS/CongWin) Commentary Resulting in a doubling of CongWin every RTT
Congestion Avoidance (CA) SS or CA
Additive increase, resulting in increase of CongWin by 1 MSS every RTT Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS. Enter slow start
Threshold = CongWin/2, CongWin = Threshold, Set state to Congestion Avoidance Threshold = CongWin/2, CongWin = 1 MSS, Set state to Slow Start Increment duplicate ACK count for segment being acked
SS or CA
SS or CA
Duplicate ACK
CongWin and Threshold not changed
Control de congestin TCP Control de congestin AIMD (Additive-Increase MultiplicativeDecrease).

Evitacin de congestin.
Crecimiento lineal (aditivo) de
VentanaCongestin.
Final de etapa:
Decrecimiento multiplicativo.
Diente de sierra: tanteo del ancho de banda.
Variantes de Reno (RFC 3782; RFC 2018). TCP Vegas: evita congestin manteniendo buena tasa de transferencia:
Tasa de transferencia TCP Cul es la tasa de transferencia media (velocidad media) de una conexin de larga duracin?.
Valor medio del diente de sierra.
Ignorar fases de arranque lento.
Tamao de Ventana: W. Velocidad media de transmisin = W/RTT TCP incrementa W en 1 MSS cada RTT hasta que se de una prdida. Suponiendo RTT y W constantes durante la conexin:
Velocidad de transmisin vara entre W/(2RTT) y W/RTT.
Tasa de transferencia media de una conexin = 0.75W/RTT

Evolucin y futuro de congestin en TCP Control de congestin original (RFC 2581). Evolucin de TCP: altas velocidades de aplicaciones de computacin reticular.
Ejemplo: TCP con segmento de 1500 bytes; RTT de 100ms; conexin 10Gbps.
W= 119304 segmentos Si se pierden?
Tasa de transferencia media=
Si deseo mantener la tasa media de transferencia perdindose una fraccin L de los transmitidos. 1.22 MSS Probabilidad de prdidas: 2 10-10 RTT L 1 prdida cada 5000000000 segmentos
Nuevos TCP en estos entornos.


Tema 2

Cargado por

Copyright:

Formatos disponibles

Tema 2

Cargado por

Información del documento

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?

Copyright:

Formatos disponibles

Tema 2

Cargado por

Copyright:

Formatos disponibles

Administracin de redes y servidores

rea de Ingeniera de Sistemas

Profesor: Carlos Elvira Izurrategui

Profesor: Carlos Elvira Izurrategui

La capa de transporte y sus servicios.

Profesor: Carlos Elvira Izurrategui

La capa de transporte y sus servicios

Profesor: Carlos Elvira Izurrategui

La capa de transporte y sus servicios

aplicacin transport red Enlace Fsica

Profesor: Carlos Elvira Izurrategui

Relaciones entre capas de transporte y red

La capa de transporte en Internet

red Enlace fsica

La capa de transporte y sus servicios. Multiplexacin y demultiplexacion.

Profesor: Carlos Elvira Izurrategui

otros campos de cabecera

El host receptor usa la IP y el puerto para colocar cada en su socket.

datos de aplicacin (mensajes)

Formato segmento TCP/UDP

Profesor: Carlos Elvira Izurrategui

Multiplexado-demultiplexado sin conexin

Multiplexado-demultiplexado sin conexin

SP: 6428 DP: 9157 SP: 9157

SP: 6428 DP: 5775 SP: 5775

SP suministra dato de retorno

Multiplexado-demultiplexado con conexin

TCP que transporta la solicitud original del establecimiento de la conexin.

Profesor: Carlos Elvira Izurrategui

Multiplexado-demultiplexado con conexin

DP: 80 S-IP: A D-IP:C

DP: 80 S-IP: B D-IP:C

Profesor: Carlos Elvira Izurrategui

TCP en servidores web

Profesor: Carlos Elvira Izurrategui

TCP en servidores web

Profesor: Carlos Elvira Izurrategui

TCP en servidores web

DP: 80 S-IP: A D-IP:C

DP: 80 S-IP: B D-IP:C

Profesor: Carlos Elvira Izurrategui

La capa de transporte y sus servicios. Multiplexacin y demultiplexacion.

Transporte sin conexin: UDP.

Profesor: Carlos Elvira Izurrategui

Transporte sin conexin UDP

Profesor: Carlos Elvira Izurrategui

Transporte sin conexin UDP

Sin informacin de estado de la conexin.

Poca sobrecarga debida a la cabecera de los paquetes.

Profesor: Carlos Elvira Izurrategui

Transporte UDP. Estructura del segmento

Datos de aplicacin (mensage)

Formato de segmento UDP

Profesor: Carlos Elvira Izurrategui

Transporte UDP. Checksum

Funcionamiento del checksum:

Porqe usar checksum en capa de transporte?

Principios de un servicio de transferencia de datos fiable.

Profesor: Carlos Elvira Izurrategui