FR Tema3

Tema 3: Protocolos de la capa de
transporte.
Bibliografa recomendada:
1.
2.
CISCO, unidad 4
Computer Networking: A Top Down Approach, 5th edition. Jim Kurose, Keith
Ross Addison-Wesley, 2010. (Tema 3)
3.
TCP/IP Protocol Suite, fourth edition, Behrouz A. Forouzan, McGraw-Hill, 2010

(Temas 13, 14, 15)
Fundamentos de Redes de Computadores
Tema 3: Protocolos de la capa de transporte
Tema 3: Protocolos de la capa de transporte.

Objetivos de aprendizaje:
Explicar la necesidad de la capa de Transporte.
Identificar la funcin de la capa de Transporte a medida que
provee la transferencia de datos de extremo a extremo
entre las aplicaciones.
Describir las funciones de dos protocolos TCP/IP de la capa
de transporte: TCP y UDP.
Explicar las funciones clave de la capa de Transporte
incluyendo confiabilidad, direccionamiento de puerto y
segmentacin.
Explicar cmo cada TCP y UDP maneja las funciones
clave.
Identificar cundo es apropiado usar TCP o UDP y proveer
ejemplos de aplicaciones que usan cada protocolo.

Contenidos de aprendizaje:
3.1.- Funcionalidades de la capa de transporte
3.2.- Protocolo UDP: Comunicacin con baja
sobrecarga
3.3.- Protocolo TCP: Comunicacin con confiabilidad
3.4.- Administracin de sesiones TCP
3.1. - Propsito de la capa de transporte

El nivel 4 es una conexin lgica
entre los extremos de una red.
Ofrece servicios de transporte
desde un host a un destino.
Este servicio se denomina a
veces como un servicio de
extremo a extremo.
Dispone de dos protocolos
principales:
1. TCP Protocolo de Control
de Transmisin.
2. UDP -Protocolo de Datagramas de Usuario

Tambin: SCTP Stream Control Transmission Protocol (Multimedia)
Nos vamos a centrar en la capa que:

Segmenta los datos.
Crea e inserta el encabezado, ya sea para el protocolo
TCP o el protocolo UDP.

Las responsabilidades principales que debe cumplir
son:
seguimiento de la comunicacin individual entre
aplicaciones en los hosts origen y destino,
segmentacin de datos y gestin de cada porcin,
reensamble de segmentos en flujos de datos de
aplicacin, e
identificacin de las diferentes aplicaciones.
Realizacin de control de flujo entre los usuarios finales.
Activacin de la recuperacin de errores.
Inicio de una sesin.
3.1. Comunicaciones proceso a proceso:

IP es responsable de la comunicacin entre hosts. IP
entrega el mensaje al host destino.
El mensaje debe ser cogido por el proceso adecuado. Aqu
es donde acta un protocolo de transporte.
El protocolo de transporte tiene la responsabilidad de
entregar el mensaje al proceso adecuado.
3.1. TCP y UDP. Direccionamiento del puerto
Algunos puertos se reservan tanto en TCP como en

UDP, aunque las aplicaciones slo pueden soportar
uno de ellos.
Tres agrupaciones de tipos de puertos:
Puertos bien conocidos (0 a 1023).
Puertos Registrados (1024 a 49151).
Puertos Privados y/o Dinmicos (49152 a 65535).

Normalmente lo procesos siguen un modelo cliente-servidor.
Como se explic en el tema 2 (capa de aplicacin), los
procesos hacen uso de un nmero de puerto.

Socket:
Determina unvocamente un proceso (ver captulo clienteservidor)
El host (IP)
El proceso (Puerto)
Protocolo de transporte.
Para utilizar los servicios de la capa de transporte se

necesitan dos sockets uno del cliente y otro del servidor
conectados.
La informacin del socket aparece en las cabeceras de la
capa de transporte y de la capa de red. Ver la siguiente
figura.
10
11
12

IP origen
Puerto
origen
IP destino
Puerto destino
TCP/UDP
Dir. Socket origen

Dir. Socket
destino
Estado
conexin
Comando netstat a n
13
3.1 TCP y UDP. Direccionamiento del puerto
Cabecera
de un
paquete IP
En la capa internet TCP/IP:

La cabecera del paquete IP tiene un campo
Protocolo que especifica si el segmento es TPC o
UDP.
14
3.1 TCP y UDP. Direccionamiento del puerto
Cabecera de
paquete IP
Cuando un paquete se encapsula en la Capa de Red, se

codifica para identificar la fuente del paquete (TCP UDP).
15
3.1 Encapsulado y desencapsulado

Encapsulado: lo realiza el emisor.
Cuando un proceso tiene un mensaje para enviar, se lo pasa a la
capa de transporte junto a los dos sockets conectados e informacin
adicional.
Transporte: la capa de transporte aade una cabecera y lo enva a la
capa de red.
Desencapsulado: lo realiza el receptor.

Al llegar el paquete a la capa de transporte del receptor, se elimina la
cabecera y se enva el mensaje al proceso de la capa de aplicacin.
16
3.1 Encapsulado y desencapsulado
17
3.1. Multiplexado y demultiplexado

Multiplexado: La capa de trasporte recibe paquetes de ms de un
proceso.
Demultiplexado: La capa de trasporte entrega paquetes a ms de un
proceso.
18
3.1. Servicios orientados y no orientados a conexin

No orientados a conexin:
Segn la capa en las que estemos tiene distinto significado.
En la capa de transporte (C.T):
No orientado a conexin: los paquetes son independientes unos de
otros. No hay control de flujo, error ni de congestin. Si se necesita
lo pondr la capa de aplicacin en sus datos.
En la capa de red:
No orientado a conexin: los datagramas pueden seguir caminos
distintos por la red.
19

No orientados a conexin:
20

Servicios orientados a conexin y no orientados a
conexin:
Orientados a conexin:
Se establece una conexin entre origen y destino.
Se envan datos
Se cierra la conexin.
En la C.T:
Slo se ven afectados los hosts finales.
Pueden implementar control de flujo, error y congestin.
Puede ejecutarse sobre protocolos de la capa de red orientados o no
a conexin.
En la capa de red:
Coordinacin entre los host finales y todos los dispositivos
intermedios para que todos los paquetes sigan el mismo camino.
21

C.T. orientada a conexin:
En el ejemplo la capa de red es no orientada a conexin.
Packet 2
22

UDP
TCP
Aplicaciones diferentes tienen requerimientos

diferentes.
Se han desarrollado protocolos diferentes para
satisfacerlos.
23
3.1. TCP y UDP (cabeceras)
24
3.1. TCP y UDP (cabeceras)

Cabecera TCP
(20 bytes)
Cabecera UDP
(8 bytes)
25
3.1. Protocolo de datagramas de usuario (UDP)

Cabecera UDP
(8 bytes)
Aplicaciones Ejemplo
Protocolo sin conexin,
Las porciones de
comunicacin en UDP se
llaman datagramas.
Baja sobrecarga
Sistema de nombres de dominio

(DNS)
Juegos en linea
Voz sobre IP (VoIP)
Protocolo de Configuracin
Dinmica de Host (DHCP)
Protocolo Trivial de Transferencia de
Ficheros (TFTP)
26
3.1. Protocolo de control de transmisin (TCP)

Cabecera TCP
(20 bytes)
Aplicaciones Ejemplo
Orientado a la conexin
P. de Transferencia de Hipertexto
Entrega confiable
(HTTP)
P. de Transferencia de Ficheros (FTP)
Chequeo de Errores
Telnet
Control de flujo
P. de Transferencia de Mensajes
Simples (SMTP)
27

sobrecarga
28
3.2.- Protocolo UDP
29
3.2.- Protocolo UDP

Responsabilidades de un protocolo de transporte
TCP/IP:
Crear una comunicacin proceso-a-proceso.
Establecer un mecanismo de control de error y de flujo
a nivel de transporte.
UDP realiza estas tareas a un nivel mnimo:
No hay control de flujo ni reconocimiento de los paquetes recibidos.
Si UDP detecta un error en el paquete recibido lo descarta sin decir
nada.
UDP es no orientado a conexin. El mensaje que recibe

de los procesos debe ser lo suficientemente pequeo
para que quepa en un paquete UDP ya que UDP no lo
fragmentar.
UDP slo recibe la unidad de datos de un proceso y lo
entrega al receptor de una forma no segura.
30
3.2.- Protocolo UDP

Si UDP slo aade a IP la comunicacin
proceso-a-proceso en vez de host-a-host y el
chequeo de errores es muy pobre, Por qu
quieren utilizarlo algunos procesos?
Porque es un protocolo muy simple que tiene unas
sobrecargas mnimas.
Si un proceso quiere enviar un mensaje pequeo sin
tener mucho cuidado en la seguridad, usa UDP.
Enviar un mensaje pequeo con UDP necesita menos
interaccin entre el emisor y el receptor que si se
enva con TCP.
31
3.2.- UDP: Comunicacin entre procesos

Nmero de puerto:
32

Direcciones IP versus
nmeros de puerto:
33

Puertos bien conocidos para UDP
Puerto
7
9
11
13
17
19
53
67
68
69
111
123
161
162
Protocolo
Echo
Discard
Users
Daytime
Quote
Chargen
Nameserver
Bootps
Bootpc
TFTP
RPC
NTP
SNMP
SNMP
Descripcin
Devuelve el datagrama recibido al emisor
Descarta cualquier datagrama recibido
Usuarios activos
Devuelve la fecha y la hora
Devuelve la cuota del dia.
Devuelve una cadena de caracteres
Servicio de nombres del dominio
Puerto del servidor para obtener informacin de arranque
Puerto del cliente para obtener infomacin de arranque
Protocolo trivial de transferencia de ficheros
Llamada a procedimiento remoto
Protocolo de tiempo de red
Protocolo simple de gestin de red
Protocolo simple de gestin de red (trap)
34
3.2.- UDP: Datagramas de usuario

Los paquetes UDP reciben el nombre de datagramas de
usuario. Tiene un tamao fijo de cabecera de 8 bytes.
35

Los campos de la cabecera son los siguientes:
Nmero de puerto fuente: Es el nmero del puerto
usado por el proceso en el host fuente.
Nmero de puerto destino: Es el nmero de puerto
usado por el proceso que se encuentra en el host
destino.
Longitud: Define la longitud total del datagrama,
cabecera ms datos. La longitud de los datos puede ser
de 0 a 65,507 = 65,535-20 (cabecera IP) - 8 (cabecera
UDP).
Checksum: Se calcula de todo el datagrama. Se
discutir en la siguiente seccin.
36

Ejemplo:
Se muestra un volcado de un encabezado UDP en formato
hexadecimal.
a. Cual es el nmero de puerto fuente?

b. Cual es el nmero de puerto destino?
c. Cual es el la longitud del datagrama de usuario?
d. Cual es el la longitud de los datos?
e. Es un paquete dirigido por un cliente a un servidor o
viceversa?
f. Cual es el proceso cliente?
37
3.2.- UDP: Datagramas de usuario. Checksum

El clculo del checksum en UDP incorpora
datos que no pertenecen al datagrama de
usuario. Se tienen en cuenta tres secciones:
la pseudocabecera, la cabecera UDP y los
datos que provienen de la capa de
aplicacin.
La pseudocabecera no se transmite y se
construye de forma temporal para aadir un
mejor control de error en el checksum.
38
39

Si el checksum no incluye la pseudocabecera el
datagrama de usuario puede llegar correctamente.
Sin embargo si la cabecera IP se deteriora
(debera haberse modificado tambin el checksum
IP que slo contempla la cabecera IP), podra
entregarse al host errneo.
En la pseudocabecera se aade el protocolo para
asegurar que el paquete pertenece a UDP (= 17) y
ser entregado a UDP.
40
Clculo del checksum en el emisor:

1. Aadir la pseudocabecera al datagrama de usuario
UDP.
2. Rellenar el campo de checksum con ceros.
3. Dividir en secciones de 16 bits.
4. Si el nmero total de bytes no es par, aadir bytes de
relleno a cero.
5. Sumar todas las secciones en complemento a uno.
6. Complementar el resultado e insertarlo en el campo de
checksum.
7. Quitar la pseudocabecera y los bytes de relleno.
8. Entregar el datagrama de usuario UDP al software IP
para su encapsulado.
41
Clculo del checksum en el receptor:

1.
2.
3.
4.
5.
6.
Aadir la pseudocabecera al datagrama de usuario UDP.

Si es necesario aadir bytes de relleno a cero.
Dividir en secciones de 16 bits.
Sumar todas las secciones en complemento a uno.
Complementar el resultado.
Si el resultado es cero, quitar la pseudocabecera y los
bytes de relleno. En otro caso descartar el datagrama de
usuario.
42

Ejemplo de checksum con 7 bytes de datos:
Uso opcional del checksum:

Si no se usa el checksum, se pone a cero.
Si da la casualidad que la suma es cero al complementarse da
menos cero (todo a unos) por lo que siempre se sabe si se est
usando el checksum o no.
43
3.2.- UDP: Operacin UDP

UDP usa conceptos de la capa de transporte que
sern explicados brevemente aqu y que se
ampliarn en el apartado sobre TCP.
Servicios no orientados a conexin:
Cada datagrama de usuario se enva de forma
independiente por lo que pueden viajar por
caminos diferentes.
Los datagramas de usuario no se numeran.
Los datos enviados a UDP deben ser lo
suficientemente pequeos para caber en un
datagrama de usuario ya que UDP no trocea los
datos.
44

Control de flujo y de error:
No existe control de flujo y por lo tanto ningn
mecanismo de ventanas.
No existe un mecanismo de control de errores,
excepto por el checksum. El receptor no sabe si el
mensaje se ha perdido o duplicado. Si el receptor
detecta un error de checksum descarta el datagrama
de usuario sin decir nada.
Si se requieren control de flujo y de error deben ser
proporcionados por los procesos que usan UDP.
Encapsulacin y desencapsulacin:
Ver la siguiente figura.
45
3.2.- UDP: Operacin UDP: Encapsulacin
46

Encapsulacin:
Cuando un proceso tiene un mensaje para enviar a
travs de UDP, pasa a UDP el mensaje junto con su
longitud y un par de direcciones de socket (IP + puerto).
UDP construye el datagama de usuario y se lo pasa a IP.
IP construye el datagrama poniendo como protocolo el
17 para indicar que es UDP y se lo pasa a la capa de
enlace.
La capa de enlace lo encapsula en un frame y lo enva
por la capa fsica.
La capa fsica codifica los bits en seales elctricas u
pticas y las enva.
47

Desencapsulacin:
El inverso chequeando los datos en cada capa
para ver si tienen error.
Cuando llega a la capa IP ve el protocolo 17 y se
lo manda a UDP.
UDP manda los datos del datagrama de usuario y
la direccin del socket emisor a la aplicacin
determinada.
La direccin del socket emisor se manda al
proceso receptor por si este necesita responder
al mensaje recibido.
48
3.2.- UDP: Operacin UDP: Multiplexado

Multiplexado y demultiplexado:
Un host que ejecuta TCP/IP slo tiene un UDP, pero
posiblemente varios procesos que quieren usar los servicios
de UDP. Para manejar esta situacin UDP multiplexa y
demultiplexa.
Multiplexado:
UDP acepta mensajes de diferentes procesos, diferencindolos
por el nmero de puerto asignado.
Despus de aadir la cabecera, UDP pasa el datagrama de
usuario a IP.
Demultiplexado:
UDP recibe los datagramas de IP. Despus del chequeo de error
y quitar la cabecera, UDP entrega cada mensaje al proceso
apropiado basndose en su nmero de puerto.
49
3.2.- UDP: Operacin UDP: Multiplexado
50
3.2.- UDP: Operacin UDP: Encolado

Encolado:
Hemos hablado de puertos sin discutir su implementacin.
Cada puerto tiene asociada una o dos colas:
51

Encolado en cliente (cont):
El el cliente, cuando comienza el proceso, pide al SO un
nmero de puerto.
Algunas implementaciones crean una cola de salida y otra
de entrada mientras otras slo crean la de entrada.
Incluso si un proceso quiere comunicarse con varios
procesos slo obtiene un nmero de puerto y eventualmente
una cola de entrada y otra de salida.
Las colas existen mientras lo haga el proceso que las
origin.
El proceso cliente puede enviar mensajes a la cola de salida
a travs del puerto fuente especificado en la peticin al SO.
UDP coge los mensajes de la cola de salida uno a uno y
despus de aadirles la cabecera los entrega al software IP.
52

Encolado en cliente (cont):
La cola de salida puede llenarse. En este caso el SO indica
al proceso que espere antes de enviar ms mensajes.
Cuando un mensaje llega para un cliente, UDP chequea si
la cola de llegada asociada a ese puerto fue creada.
Si la cola de llegada est creada, UDP enva el datagrama
de usuario recibido al final de la cola.
Si la cola de llegada no est creada o est creada y llena, el
datagrama de usuario se descarta y UDP pide a ICMP que
mande un mensaje de puerto inalcanzable al servidor.
53

Encolado en servidor (cont):
Existen diferentes tipos de servidores que utilizan
mecanismos diferentes.
El ms simple pide una cola de entrada y otra de salida
cuando empieza a ejecutarse y las colas permanecen
activas mientras lo haga el servidor.
Cuando llega un mensaje al servidor UDP chequea si existe
la cola de llegada y si no es as, se descarta el datagrama
de usuario y se pide a ICMP que mande un mensaje puerto
inalcanzable al cliente.
Todos los mensajes para un servidor, aunque vengan de
diferentes clientes van a la misma cola de entrada. Si la cola
est llena se descarta el datagrama de usuario y se pide a
ICMP que mande un mensaje puerto inalcanzable al cliente.
54

Encolado en servidor (cont):
Cuando el servidor quiere responder al cliente,
enva un mensaje a la cola de salida usando el
puerto fuente especificado en la peticin.
UDP coge los mensajes de la cola de salida uno a
uno y despus de aadirles la cabecera los entrega
al software IP.
La cola de salida puede llenarse. En este caso el
SO indica al proceso que espere antes de enviar
ms mensajes.
55
3.2.- UDP: Uso de UDP

UDP es bueno para procesos que requieren una
comunicacin simple de pregunta-respuesta.
UDP es bueno para procesos con mecanismos de
control de flujo y de error internos. Por ejemplo TFTP.
UDP es un buen protocolo de transporte para multicast
y broadcast.
UDP se usa por procesos de administracin como
SNMP.
UDP se usa por los protocolos de actualizacin de
rutas como RIP.
56
3.2.- UDP: Aplicaciones de UDP
58

Ejemplo 1:
DNS usa UDP porque un cliente necesita enviar una
pregunta corta al servidor y recibir una respuesta corta.
Tanto la pregunta como la respuesta cabe en un datagrama
de usuario.
Como solo se necesita un mensaje en cada direccin no es
necesario establecer un servicio orientado a conexin.
Ejemplo 2:
SMTP no puede usar UDP ya que los correos pueden
contener imgenes que no caben en un datagrama de
usuario, por lo que hay que usar varios datagramas que
pueden llegar fuera de orden y deben ser ordenados por la
aplicacin. Para quitar estos problemas a la aplicacin es
mejor usar un protocolo orientado a conexin con control de
flujo y de errores como TCP.
59

Ejemplo 3:
Si estamos viendo video en tiempo real. Es mejor dejar de
ver un trozo por que se ha perdido o era corrupto que
reenviar los trozas perdidos, lo que puede causar la
desincronizacin de toda la emisin. Aqu es mejor usar
UDP.
60
3.2.- UDP: Diseo de UDP

Se presenta un modelo simplificado sin chequeo de
error ni validacin de paquetes.
El software UDP tiene cinco componentes:
Tabla de control de bloques.

Colas de entrada.
Mdulo de control de bloques.
Mdulo de entrada.
Mdulo de salida.
Estos mdulos se muestran en la siguiente figura
61
62

Tabla de control de bloques:
Se usa en nuestro diseo para saber que puertos estn abiertos.
Cada entrada tiene cuatro campos:
Estado:
Libre.
En uso.
Id del proceso.
Nmero de puerto.
Nmero de cola correspondiente.
Colas de entrada:
En nuestro diseo se usa un conjunto de colas de entrada, una por cada
proceso. No se usarn colas de salida.
63

Mdulo de control de bloques:
Es el responsable de la administracin de la tabla de control de
bloques.
Cuando un proceso comienza, pide un nmero de puerto al SO
(bien conocido para los servidores y efmero para los clientes).
Una vez obtenido pasa el Id del proceso y el nmero de puerto
al mdulo de control de bloques para crear una entrada en la
tabla de control de bloques.
Este mdulo no crea las colas por lo que deja el campo de cola
a cero.
No se ha incluido qu hacer cuando la tabla est llena. Se deja
como ejercicio.
64

Mdulo de control de bloques:
Recibe: un Id de proceso y un nmero de puerto.
1. Busca en la la tabla de control de bloques una entrada = libre.
2. Si no se encuentra
2.2 Borrar una entrada usando una estrategia predefinida.
3. Crear una nueva entrada con estado = en uso
4. Introducir el Id del proceso y el nmero de puerto.
5. Return.
65

Mdulo de entrada:
Recibe: un datagrama de usuario de IP.
1. Busca en la la tabla de control de bloques la entrada
correspondiente.
2. Si la encuentra
2.1 Chequea el campo con el nmero de cola para ver si
est creada.
2.2 Si no lo est
2.2.1 Crea la cola
2.3 Encola los datos en la cola correspondiente.
3. Si no encuentra la entrada
3.1 Pide al mdulo ICMP que enve un mensaje de
puerto inalcanzable.
3.2 Descartar el datagrama.
4. Return.
66

Mdulo de salida:
Recibe: datos e informacin de un proceso.
1. Crea un datagrama de usuario UDP.
2. Enviar el datagrama de usuario.
3. Return.
67
3.2.- UDP: Diseo de UDP. Ejemplos

Estado inicial:
Estado
En uso
En uso
Libre
En uso
Libre
Id. proceso
2,345
3,422
N puerto
52,010
52,011
N cola
34
4,652
52,012
38
Llega un datagrama para el puerto 52,012

La tabla queda igual
68

Estado
En uso
En uso
Libre
En uso
Libre
Id. proceso
2,345
3,422
N puerto
52,010
52,011
N cola
34
4,652
52,012
38
Se crea el proceso 4,978 y se le asigna el puerto 52,014

Estado
En uso
En uso
En uso
En uso
Libre
Id. proceso
2,345
3,422
N puerto
52,010
52,011
4,978
52,014
4,652
52,012
N cola
34
38
69

Estado
En uso
En uso
En uso
En uso
Libre
Id. proceso
2,345
3,422
N puerto
52,010
52,011
4,978
52,014
4,652
52,012
N cola
34
38

Estado
En uso
En uso
En uso
En uso
Libre
Id. proceso
2,345
3,422
N puerto
52,010
52,011
4,978
52,014
4,652
52,012
N cola
34
43
38
70

Estado
En uso
En uso
En uso
En uso
Libre
Id. proceso
2,345
3,422
N puerto
52,010
52,011
4,978
52,014
4,652
52,012
N cola
34
43
38

Se descarta y se manda un mensaje ICMP.
Un proceso necesita enviar un datagrama de usuario
Lo entrega al mdulo de salida y este le aade la
cabecera y lo enva.
71

sobrecarga
72
3.3. Protocolo TCP
73
3.3. Protocolo TCP

Responsabilidades de TCP:
Crear una comunicacin proceso-a-proceso. TCP usa los nmeros de
puerto para realizar esto.
Crear un mecanismo de control de flujo y de errores a nivel de
transporte.
Es responsabilidad del TCP emisor:
Establecer una conexin con el receptor.
Trocear los mensajes de la capa superior en unidades
transportables.
Numerar esas unidades y enviarlas una a una.
Es responsabilidad del TCP receptor:
Esperar a que todas las unidades pertenecientes al mismo
mensaje lleguen.
Chequear lo posibles errores y pasar el mensaje al proceso
correspondiente.
Cerrar la conexin cuando la comunicacin concluye.
75
3.3. Protocolo TCP: Comunicacin proceso a proceso

La responsabilidad de IP es hacer llegar el mensaje al host
correcto y la de TCP al proceso correcto.
Todo lo mencionado sobre UDP sobre puertos, procesos cliente y

servidor y direcciones de socket, funciona de igual forma para TCP.
76
77

Puertos bien conocidos para TCP
Puerto
7
9
11
13
17
19
20
21
23
25
53
67
79
80
111
Protocolo
Echo
Discard
Users
Daytime
Quote
Chargen
FTP, Data
FTP, Control
TELNET
SMTP
Nameserver
BOOTP
Finger
HTTP
RPC
Descripcin
Devuelve el datagrama recibido al emisor
Descarta cualquier datagrama recibido
Usuarios activos
Devuelve la fecha y la hora
Devuelve la cuota del da.
Devuelve una cadena de caracteres
File Transfer Protocol, (Data connection)
File Transfer Protocol, (Control connection)
Terminal Network
Simple Mail Transfer Protocol
Servicio de nombres del dominio
Protocolo de arranque
Finger
Hypertext Transfer Protocol
Llamada a procedimiento remoto
78
3.3. Protocolo TCP: Servicios TCP

TCP ofrece servicios que no son ofrecidos por UDP:
Servicio de stream de datos:
El TCP emisor acepta un stream de caracteres del
programa de aplicacin emisor, crea paquetes del tamao
adecuado, llamados segmentos, y los enva por la red.
El TCP receptor, recibe los segmentos, extrae los datos
de ellos, los ordena si llegan desordenados y los entrega
como un stream de caracteres al programa de aplicacin
receptor.
Se usan buffers para almacenar los datos de la aplicacin
emisora y para almacenar los datos para la aplicacin
receptora.
79

Servicio de stream de datos (cont):
La aplicacin emisora entrega los datos a la velocidad que
se crean, escribindolos en el buffer del emisor. Ejemplos:
La escritura en la lnea de comandos se enva carcter a
carcter.
Si los datos vienen de un fichero se entregan al TCP
emisor lnea a lnea o bloque a bloque.
TCP no crea un segmento cada vez que se escribe en el
buffer aunque la aplicacin puede pedir su creacin
mediante un flush. TCP puede aceptar o no la peticin.
El receptor TCP recibe los segmentos y los almacena en el
buffer de recepcin. La aplicacin receptora lee datos de ese
buffer, pero no tiene que leer todos los datos de un
segmento en una lectura ya que su velocidad de lectura
puede ser menor que la de recepcin.
80
81
Segment N
Segment 1
82

Servicio full-Duplex:
Los datos pueden viajar en ambos sentidos a la vez.
Si no hay datos se enva slo el ACK.
Servicio Seguro:
Usa el mecanismo de ACKs para chequear una
recepcin segura y correcta.
83

Ejemplo
Supongamos que una conexin TCP se est transfiriendo un
archivo de 5000 bytes. El primer byte est numerado 10.001.
Cules son los nmeros de secuencia para cada segmento, si los
datos se envan en cinco segmentos, cada uno con 1.000 bytes?
Solucin
A continuacin se muestra el nmero de secuencia para
cada segmento:
84
3.3. Protocolo TCP: Segmento

Unidad de transferencia entre dos dispositivos que usan TCP.
Tiene el siguiente formato:
85

La cabecera tiene 20 bytes si no hay opciones y hasta 60
bytes con opciones. Los campos son:
Nmero de puerto fuente: 16 bits.
Nmero de puerto destino: 16 bits.
Nmero de secuencia: 32 bits. Define el nmero
asignado al primer byte de este segmento. Al iniciar una
conexin se genera un nmero aleatorio llamado
nmero de secuencia inicial (ISN), que normalmente es
diferente en cada direccin. Por ejemplo, si el ISN es
2,367 y se manda un segmento que contiene 1,000
bytes, el nmero de secuencia es el 2.369 ya que el
2,367 y 2,368 se usan en el establecimiento de
conexin. Si el segundo segmento lleva 500 bytes, su
nmero de secuencia es el 3,369 y as sucesivamente.
86

Nmero de ACK: 32 bits. Si el receptor recibe el byte x correctamente,
manda x+1 como nmero de ACK.
HLEN: 4 bits que definen el nmero de palabras de 4 bytes en la
cabecera. Su valor puede estar entre 5 y 15.
Reservado: 6 bits reservados para uso futuro.
Control: Este campo define 6 bits o campos de control:
URG = Datos urgentes (no ignorar en receptor).
ACK = Segmento contiene Ack
PUSH = Segmento enviado mediante un push.
RESET = Fin anmalo de la transmisin.
SYN = Sincronizacin de nm. de secuencia.
FIN = Fin de la transmisin.
87

Tamao de ventana: 16 bits. Determina el tamao de la
ventana deslizante (sliding window), en bytes, que debe
mantener la otra parte. El tamao mximo es de 65,535
bytes.
Checksum: Se calcula de igual forma que en UDP, pero
aqu es obligatorio rellenar el campo.
Puntero de urgencia:16 bits. Slo es vlido si el flag de
urgente est activado. Se usa cuando el segmento
contiene datos urgentes. Contiene el nmero de bytes que
hay que sumar a la secuencia para obtener el nmero del
ltimo byte urgente. Se ver su funcionamiento.
Opciones: Se tienen hasta 40 bytes de opciones.
88
89

sobrecarga
90
3.4.- Administracin de sesiones TCP: Conexin

TCP es un protocolo orientado a conexin.
Crea un camino virtual desde la fuente al
destino.
Todos los segmentos pertenecientes al
mismo mensaje siguen este camino virtual.
La transmisin orientada a conexin se
consigue mediante dos procedimientos:
Establecimiento de conexin
Terminacin de conexin
91

Client
process
Client transport
layer
Time
Time
Server transport Server

layer
process
Time
Time
92
Establecimiento de conexin:
TCP transmite datos en modo full-duplex.
Antes de transmitir la informacin cada parte debe iniciar
la comunicacin y obtener la aprobacin de la otra parte.
Se realizan cuatro acciones antes de que las dos partes,
llamadas aqu A y B, puedan enviar datos:
1. A enva un segmento para anunciar su deseo de
conexin que incluye la informacin de inicio sobre el
trfico de A a B.
2. B enva un segmento para confirmar la peticin de A.
3. B enva un segmento que incluye su informacin de
inicio sobre el trfico de B a A.
4. A enva un segmento para confirmar la peticin de B.
Los pasos dos y tres se pueden combinar en uno.
93

Three-way handshaking:
El establecimiento de conexin descrito anteriormente se
denomina Tree-way handshaking.
En este procedimiento una aplicacin , llamada cliente,
quiere realizar una conexin con otra aplicacin, llamada
servidor, usando TCP como protocolo de la capa de
transporte.
Antes del procedimiento Tree-way handshaking el
programa servidor indica a TCP que est listo para aceptar
una conexin. Eso se conoce como una peticin de una
apertura pasiva.
El programa cliente hace una peticin de apertura activa
TCP y le comunica que quiere conectarse con un servidor
particular.
Es entonces cuando puede comenzar el procedimiento
handshaking.
FundamentosThree-way
de Redes de Computadores
94
1. El cliente enva un segmento SYN que incluye los puertos origen y
destino por lo que se especifica claramente el servidor destino al
que se quiere conectar. Tambin contiene el nmero de inicio de
secuencia (ISN). Como opciones pueden incluirse el tamao
mximo de segmento (MSS) que puede recibirse del servidor o el
factor de escala, si se necesitan ventanas mayores. No se incluye
ningn ACK, ni se define el tamao de la ventana. Definir el tamao
de la ventana slo tiene sentido cuando se enva un ACK.
2. El servidor enva un segmento SYN con ACK. Se define tambin el
tamao de la ventana del cliente. Incluye el ISN del servidor y
opcionalmente el MSS y el factor de escala.
3. El cliente enva un segmento ACK y se define el tamao de la
ventana del servidor. El segmento puede incluir datos.
4. Puede ocurrir que ambos realicen una apertura activa. En este
caso ambos TCPs emiten un segmento SYN+ACK.
95
3.4: Conexin: Three-way handshaking:
Quiero conectarme y aqu est mi

primer nmero de secuencia.
96
OK.Aqu est mi primer nmero de

secuencia. He aadido 1 a tu ISN (n
sec) como reconocimiento. Espero
que ste sea tu prximo nmero de
secuencia.
1
97
OK.Aqu est el siguiente segmento

con el nmero de secuencia que
esperas. He aadido 1 a tu ISN como
reconocimiento. Espero que ste sea
tu prximo nmero de secuencia.
1
98
Un segmento SYN SYN+ACK no puede transportar datos pero consume un

nmero de secuencia
Un segmento ACK, si no transporta datos, no consume nmero de secuencia.
99
1
2
3
Slo se muestran
parte de las
cabeceras TCP
100
3.4.- Administracin de sesiones TCP: Terminacin
Terminacin de conexin:
Cualquiera de las dos partes puede cerrar una conexin.
Cuando la conexin en una direccin se cierra, la otra
parte puede seguir enviando datos.
Por lo tanto se necesitan cuatro acciones antes de cerrar
la conexin:
1. A enva un segmento indicando que desea terminar la
conexin.
2. B enva un segmento con ACK confirmando la
terminacin. B puede seguir enviando datos a A.
3. Cuando B termina de enviar datos enva un segmento
indicando que desea terminar la conexin.
4. A manda un segmento con ACK confirmando a B la
terminacin.
101

Four-way handshaking:
102

La terminacin de conexin descrito anteriormente
se denomina Four-way handshaking.
En este procedimiento la aplicacin, normalmente el
cliente, quiere terminar una conexin. Esto se
conoce como peticin de cerrado activo.
Despus de recibir la peticin de cerrado activo el
TCP cliente cierra la conexin en la direccin clienteservidor.
Cuando la aplicacin servidor termina de enviar
datos en la direccin servidor-cliente, pide a su TCP
que cierre la conexin. Esta suele ser una peticin
de cerrado pasivo.
103

1 El cliente TCP enva un segmento FIN.
2 El servidor TCP enva un segmento con ACK
para confirmar la recepcin del FIN.
3 El servidor puede seguir enviando datos en la
direccin servidor-cliente. Cuando termina
enva un segmento FIN.
4 El cliente TCP enva un segmento con ACK
para confirmar la recepcin del FIN.
104
seq:7000
ack:7001
Un segmento FIN FIN+ACK no puede transportar datos pero consume un

nmero de secuencia
Un segmento ACK, si no transporta datos, no consume nmero de secuencia.
105
3.4.- Terminacin: Four-way handshaking
106
3.4.- Terminacin: Three-way handshaking
107
3.4.- Administracin de sesiones TCP: Restablecimiento

Restablecer la conexin:
TCP puede pedir que se restablezca la conexin, lo
que significa que la conexin actual se destruye. Esto
puede ocurrir en tres casos:
TCP ha pedido la conexin a un puerto
inexistente. La otra parte enva un segmento
RESET para anular la peticin.
TCP quiere abortar la conexin debido a una
situacin anormal por lo que enva un segmento
RESET.
Un TCP puede notar que la otra parte est inactiva
por un periodo de tiempo largo, por lo que enva
un segmento RESET para destruir la conexin.
108
3.4.- Intercambio de datos
Recordar que la capa de transporte debe

reensamblar los segmentos en el orden correcto.
109
Se usan juntos para

confirmar la recepcin de
los datos
5
5
11
11
110
Reconocimiento
esperado
ACU=SEC+
tamaodatos
1
5
5
11
11
El tamao de los datos se define en la ventana de datos

111
3.4.- Intercambio de datos. Tamao de la ventana

Con un tamao de ventana de 10, cada segmento lleva slo diez bytes de datos y debe ser reconocido antes de
que otro segmento se transmita.
Tamao de la ventana:
La cantidad de datos que pueden ser enviados antes de requerir el reconocimiento.
Determinado por el campo Window de la cabecera.
112
113

Cantidad de datos
que se pueden
enviar sin
reconocimiento.
El tamao inicial de la
ventana se determina
durante el protocolo
three-way handshake.
114
3.4.- Control de flujo

Control de flujo
Define la cantidad de datos que el emisor puede
enviar antes de recibir un ACK del receptor. Casos
extremos:
Enviar un byte y esperar al ACK antes de enviar el
siguiente. Para grandes distancias el rendimiento
sera muy pobre.
Enviar todos los datos y esperar el ACK al final.
Puede saturar al receptor y si se pierden datos, se
reciben fuera de orden o errneos el emisor slo
lo sabe al final.
TCP usa la ventana deslizante (sliding window) que
slo permite al emisor enviar los datos definidos por
una ventana.
115

Sliding window: Ej. Tamao 10 y ACK del 3 llega
cuando envi el 7.
116

Sliding window: Ej. Tamao 10 y ACK del 3 llega
cuando envi el 7.
117

Sliding window:
El emisor no tiene por qu enviar toda la ventana.
El receptor puede enviar ACKs en cualquier
momento.
En TCP el tamao puede ser variable:
El receptor puede establecer otro tamao en
cada segmento con ACK. Ej se reconoce la
recepcin del byte 3,000 y se establece el
nuevo tamao de ventana a 200. Entonces el
emisor puede enviar hasta el byte 3,200.
118

Incremento del tamao de la ventana:
119

Decremento del tamao de la ventana: No se puede
decrementar de forma que retroceda el lmite superior de
la ventana del emisor.
120

Sliding window, manejo de la ventana:
Como determina el receptor el tamao de la
ventana?
Normalmente es el espacio libre en el buffer TCP de
recepcin.
En la siguiente figura se supone que el TCP emisor
tiene un buffer muy grande con datos y el del receptor
es de 4k.
Durante el establecimiento de la conexin se
determina el tamao de la ventana a 4k.
El emisor manda 4k. El receptor los reconoce y pone
la ventana a 0.
Cuando se libera buffer del receptor se manda el
mismo ACK con el nuevo tamao de ventana.
121
122
3.4.- Control de flujo: ventanas

Ventanas de envo y recepcin:
Antes de discutir la transferencia de datos en TCP y los
temas tales como el flujo, el error, y el control de la
congestin, se describen las ventanas que se utilizan en
TCP. TCP utiliza dos ventanas (ventana de envo y ventana
de recepcin) para cada direccin de la transferencia de
datos, lo que significa cuatro ventanas para una
comunicacin bidireccional. Para hacer que la simple
discusin, hacemos una suposicin de que la comunicacin
es slo unidireccional, la comunicacin bidireccional se
puede inferir el uso de dos comunicaciones
unidireccionales.
123
3.4.- Control de flujo: ventana de envo
124
3.4.- Control de flujo: ventana de recepcin
125
3.4.- Control de flujo: Ejemplo
Suponemos
slo
comunicacin
unidireccional
del cliente al
servidor. Por
eso slo hay
una ventana en
cada lado
126
3.4.- Control de error

Incluye mecanismos para detectar segmentos
corrompidos, perdidos, fuera de orden o duplicados.
Tambin incluye mecanismos para corregir los errores
despus de que han sido detectados.
Deteccin y correccin de errores:
Se realiza con las siguientes herramientas:
Checksum.
ACK.
Time-out.
Si el segmento est corrupto se descarta. TCP usa
ACK para confirmar la recepcin de segmentos no
corruptos. TCP no usa ACK negativos. Si ocurre un
time-out sin que se confirme un segmento, se
considera que est corrupto o se perdi y por lo tanto
hay que retransmitirlo.
127

Deteccin y correccin de errores (cont):
Segmento corrupto:
La siguiente figura muestra un ejemplo de segmento
corrupto que llega al receptor.
El emisor manda los segmentos 1 a 3, cada uno de 200
bytes.
El nmero de secuencia comienza en 1,201 en el
segmento 1.
El receptor confirma los segmentos 1 y 2 con ACK
1,601 y detecta error en el segmento 3.
Cuando expira el time-out en el emisor, este
retransmite de nuevo el segmento 3 y ahora si es
confirmado por el receptor.
128
129

Segmento perdido:
La siguiente figura muestra un ejemplo de
segmento perdido.
La situacin es la misma que la del segmento
corrupto.
El segmento corrupto es descartado por el
receptor y el segmento perdido es descartado por
algn nodo intermedio y nunca llega al destino.
130
131

Segmento duplicado:
Puede crearse en el emisor cuando la confirmacin de
recepcin de un segmento no llega antes del time-out.
Cuando el receptor recibe un segmento con el mismo
nmero de secuencia simplemente lo descarta.
Segmento fuera de orden:
Los segmentos pueden llegar desordenados porque TCP
usa los servicios de IP que no es orientado a conexin.
El receptor no confirma la recepcin de un segmento fuera
de orden hasta que no se hayan recibido los que le
preceden. Si se retrasa el ACK, puede provocar
retransmisin en el emisor con lo que se recibirn
duplicados.
132
3.4.- Control de error. Ejemplo 1
133
3.4.- Control de error. Ejemplo 2. Retransmisin Rpida
134

Prdida de ACK:
La siguiente figura muestra la prdida de un ACK.
El emisor ni siquiera se da cuenta que se ha
perdido el ACK.
TCP usa un sistema de reconocimiento
acumulativo, es decir, cada ACK confirma todos
los bytes recibidos hasta el byte especificado.
135
136
137
3.4.- Control de error. Ejemplo 3. Correccin mediante el

reenvo de un segmento
138
3.4.- Relojes TCP

TCP usa los cuatro relojes mostrados en la figura:
Tiempo de retransmisin:
Cuando TCP enva un segmento, crea un reloj para
controlar su retransmisin. Pueden ocurrir dos
situaciones:
El ACK llega antes de que expire el tiempo: Se
destruye el reloj.
Expira el tiempo antes de que llegue el ACK: Se
retransmite el segmento y se restablece el tiempo.
139
3.4.- Control de error. Ejemplo 2. Retransmisin Rpida
140
3.4.- Administracin de sesiones TCP: Relojes TCP
Tiempo de retransmisin (cont):

Clculo del tiempo de retransmisin:
TCP no puede usar los mismos tiempos de retransmisin para
todas las conexiones ya que depender de la velocidad de las
mismas.
Incluso para la misma conexin el tiempo de retransmisin puede
no ser fijo ya que la transmisin puede tener diferentes velocidades
durante la conexin.
El time-out de retransmisin se basa en el RTT. Normalmente se
establece como 2 x RTT.
Actualizacin del RTT:
El RTT puede obtenerse mediante la marca de tiempo mencionada
anteriormente o enviando un segmento, inicia un reloj y se mide lo
que tarda en llegar el ACK. Como cada segmento tiene un RTT, el
calculo del time-out del siguiente segmento se actualiza con la
siguiente frmula:
RTT = x RTT previo + (1-) RTT actual.
141

Tiempo de retransmisin (cont):
Actualizacin del RTT(cont):
RTT = x RTT previo + (1-) RTT actual.
El valor de es normalmente 90. Por lo tanto el nuevo RTT tiene un
peso del 10% y el antiguo del 90%.
Algoritmo de Karn:
Que pasa si se retransmite un segmento y llega el ACK?
No se sabe si el ACK es el del original o el del retransmitido.
Karn establece una solucin simple. No se actualiza el RTT con los
tiempos de los segmentos retransmitidos.
Tiempo de persistencia:
Ambos, emisor y receptor pueden quedar bloqueados cuando el
receptor manda un ACK con tamao de ventana a cero y se pierde
el ACK que aumenta la ventana. Esto es debido a que no se
confirma la recepcin de ACK.
142

Tiempo de persistencia (cont):
Para evitar este interbloqueo, cuando se recibe un ACK
con tamao de ventana a cero se inicia un reloj de
persistencia. Si este expira, el emisor enva un segmento
especial llamado prueba.
El segmento de prueba tiene un solo byte con nmero de
secuencia y nunca se reconoce su recepcin ni interviene
en el nmero de secuencia de los datos reales. Sirve slo
para indicar el receptor que debe reenviar el ACK que
incrementa el tamao de la ventana.
El tiempo de persistencia es igual al del retransmisin.
Cada vez que se vuelve a enviar un paquete de prueba el
tiempo de persistencia se duplica hasta llegar a un umbral
que suele ser 60sg donde siempre se envan los paquetes
de prueba cada 60sg.
143

Tiempo de actividad:
Se usa en algunas implementaciones para evitar las conexiones
con tiempos largos sin comunicacin datos. Como el caso en el
que el receptor se cuelga.
Cada vez que el emisor recibe un segmento del receptor se inicia
el reloj.
El time-out es normalmente de dos horas.
Si despus de dos horas no se recibe nada del receptor, se
manda un segmento de prueba. Si no hay respuesta despus de
10 pruebas espaciadas en 75 sg, se termina la conexin.
Tiempo de espera:
Se usa despus de terminar una conexin.
Est motivado porque pueden haberse duplicado el segmento con
el flag FIN activado.
El valor de este temporizador es normalmente de dos veces el
tiempo esperado de un segmento.
144
3.4.- Diagrama de transicin de estados
TCP se implementa como una mquina de estados finitos.

Estado
Descripcin
CLOSED
No hay conexin.
LISTEN
El servidor espera llamadas del cliente.
SYN-SENT
Enviada peticin de conexin. Esperando respuesta.
SYN-RCVD
Recibida peticin de conexin.
ESTABLISHED
Conexin establecida.
FIN-WAIT-1
La aplicacin a pedido el cierre de la conexin.
FIN-WAIT-2
La otra parte ha aceptado cerrar la conexin.
CLOSING
Ambas partes han decidido cerrar simultneamente.
TIME-WAIT
Esperar que los segmentos retransmitidos mueran.
CLOSE-WAIT
El servidor espera a la aplicacin para cerrar.
LAST-ACK
El servidor espera el ltimo ACK.
145

En el siguiente diagrama se representan:
Estados: valos.
Transiciones: lneas.
Cada lnea tiene dos cadenas separadas por /. La
primera es la entrada que recibe TCP y la segunda
la salida de TCP.
El diagrama representa al servidor y al cliente:
Lneas punteadas al servidor.
Lneas slidas al cliente.
Lneas delgadas representan situaciones inusuales.
146
Diagrama del cliente: (En cada punto se supone en el anterior).

El cliente puede estar en los estados CLOSED, SYN-SENT,
ESTABLISHED, FIN-WAIT1, FIN-WAIT-2 y TIME-WAIT.
El cliente comienza en el estado CLOSED.
El TCP puede recibir una peticin de apertura activa de la aplicacin
cliente. Enva un segmento SYN al TCP servidor y pasa al estado
SYN-SENT.
El TCP puede recibir un SYN+ACK del TCP servidor. Entonces enva
un segmento ACK y pasa al estado ESTABLISHED.
El TCP puede recibir una peticin de terminacin de la aplicacin
cliente. Enva un segmento FIN y pasa al estado FIN-WAIT-1.
Cuando el TCP recibe el ACK del TCP servidor pasa al estado FINWAIT-2. La conexin se cierra en esa direccin.
Si el cliente recibe un segmento FIN, pasa al estado TIME-WAIT.
En TIME-WAIT inicia un temporizador eliminando los FIN duplicados
que lleguen. Cuando expira pasa al estado CLOSED.
147

Diagrama del servidor:
(En cada punto se supone en el anterior).
Aunque puede estar en los 11 estados, en una operacin normal est

en los estados: CLOSED, LISTEN, SYN-RCVD, ESTABLISHED,
CLOSE-WAIT y LAST-ACK.
El servidor TCP empieza en el estado CLOSED.
Si el TCP recibe una apertura pasiva se pone en el estado LISTEN.
Si recibe un SYN del cliente, manda un SYN+ACK al cliente y se pone
en estado SYN-RCVD.
Si recibe un ACK del cliente se pone en el estado ESTABLISHED.
Si recibe un FIN, puede enviar un ACK y pasar al estado CLOSEWAIT.
El servidor TCP espera en este estado hasta recibir una peticin de
cerrar del programa servidor. Entonces enva un FIN al cliente y pasa
al estado LAST-ACK.
El servidor espera el ltimo segmento ACK y pasa al estado CLOSED.
148
149
CLIENTE
SERVIDOR
150
151
3.4.- Control de congestin

Un paquete enviado por el emisor puede pasar por varios
routers antes de llegar al receptor.
Los routers tienen una capacidad de almacenamiento
limitada.
Si un router recibe paquetes ms rpido de lo que los puede
procesar, puede ocurrir una congestin y pueden eliminarse
algunos paquetes.
Los paquetes no legan al receptor, por lo que este no enva
el correspondiente ACK.
El servidor debe retransmitir los paquetes perdidos,
pudiendo crear mayor congestin.
El receptor poda disminuir el tamao de la ventana del
emisor pero slo en los paquetes ACK, que ahora no llegan.
152

La perdida de paquetes en la red tambin puede hacer que el emisor
que reduzca su ventana de transmisin.
El emisor tiene dos variables:
Tamao de la ventana notificada por el receptor.
Tamao de la ventana de congestin.
El tamao usado es el menor de los dos.
Para determinar el tamao de la ventana de congestin TCP usa las
siguientes estrategias:
Incremento: Inicialmente el tamao de la ventana es el MSS
(Tamao mximo de segmento). Cada vez que se recibe un ACK la
ventana se incrementa exponencialmente: 2 MSS (manda dos
segmentos), 4 MSS, 8 MSS, etc, hasta llegar a un umbral, la mitad
del tamao mximo de la ventana permitido. Al llegar al umbral tiene
un incremento aditivo de un MSS cada vez que se reciba un ACK.
Decremento: Si no se reciben ACK, normalmente es porque se han
perdido los segmentos. En este caso, el emisor reduce su ventana
de congestin a la mitad, pudiendo llegar a ser 1 MSS.
153
Figure 15.34
Slow start, exponential increase
1
cwnd
RTT
2
cwnd
RTT
4
cwnd
RTT
8
cwnd
154
Figure 15.35
Congestion avoidance, additive increase
155
156
3.4.- Operacin TCP: Encapsulado

Encapsulado y desencapsulado:
157
3.4.- Operacin TCP: Encolado

Colas:
158
3.4.- Operacin TCP: Multiplexado

Multiplexado y demultiplexado:
159
3.4.- Operacin TCP: Push de datos

Push de los datos:
Existen buffers entre la aplicacin y el TCP emisor y
entre la aplicacin y el TCP receptor.
Normalmente TCP no manda un segmento hasta que no
haya suficientes bytes para mandar.
La aplicacin cliente puede pedir a TCP que realice un
push, de forma que TCP no espera a que haya
suficientes bytes para crear un segmento.
En el segmento generado, TCP activa el bit PSH,
indicando que los datos deben entregarse a la aplicacin
servidora lo antes posible.
Las implementaciones de TCP actuales pueden atender
las peticiones de push o no.
160
3.4.- Operacin TCP: Datos urgentes

Datos urgentes:
Cuando llegan los datos al receptor, estos se presentan a
la aplicacin como un stream de caracteres, donde cada
byte tiene su posicin en el stream.
Existen ocasiones donde es necesario enviar a la
aplicacin caracteres fuera de orden. Ejemplo:
El emisor est enviando datos al receptor.
Cuando se reciben los resultados se observa son errneos por
lo que se decide cancelar el proceso con Control+C. Estos dos
caracteres se almacenaran al final de los datos y seran
entregados a la aplicacin despus de que todos los datos
hayan sido procesados.
Solucin: Enviar un segmento con el bit URG activado. Los datos
urgentes se almacenan al principio del segmento y el campo de
puntero de urgencia apunta al ltimo byte urgente.
Al llegar los datos urgentes, el TCP destino los entrega a la
aplicacin fuera de orden.
161
3.4.- Diseo TCP
TCP es un protocolo complejo, con servicio stream, orientado a

conexin, que usa un diagrama de estados, con control de error
y flujo, lo que representa ms de 10,000 lneas de cdigo.
Se presenta un modelo simplificado donde se han omitido
detalles como el manejo y chequeo de error y validacin de
paquetes.
En nuestro diseo TCP tiene los siguientes componentes:
Una tabla de bloques de control de la transmisin.
Un conjunto de temporizadores.
Un mdulo principal.
Un mdulo de procesado de entradas
La parte de diseo es un
material adicional a los
Un mdulo de procesado de salidas.
Objetivos de la asignatura
162
3.4.- Diseo TCP
Todos los derechos reservados. The McGraw-Hill Companies o CISCO Systems

Fundamentos de Redes de ComputadoresInc.
163
163
3.4.- Diseo TCP
Tabla de bloques de control de la transmisin:

Almacena informacin de cada conexin. Tiene los siguientes campos:
Estado: Estado de la transmisin, de acuerdo con el diagrama de
estados.
Proceso: El proceso que usa esta conexin en esta mquina,
como cliente o servidor.
IP local. Puerto local. IP remota. Puerto remoto.
Interfaz.
Ventana local: Puede tener varios subcampos conteniendo
informacin sobre la ventana en el TCP local.
Ventana Remota.
Nmero de secuencia de envo.
Numero de secuencia de recepcin.
Nmero de ACK enviado.
RTT: pueden usarse varios valores para almacenar esta
informacin.
Valores de time-out: retransmisin, persistencia, actividad y
espera.
Tamao del buffer.
Puntero del buffer.
164
3.4.- Diseo TCP
Temporizadores:
Como se indic, TCP necesita varios temporizadores.
Mdulo principal:
Recibe: Un segmento TCP, un mensaje de la aplicacin o un evento de timeout.
1 Buscar en la tabla de bloques de control de transmisin (TCB).
2 Si el correspondiente TCB no se ha encontrado
2.1Crear un TCP con el estado CLOSED
3 Encontrar el estado en la entrada TCB
4 switch (estado)
CLOSED: (no hay conexin)
Si se recibe un mensaje de apertura pasiva de la aplicacin
Cambiar el estado a LISTEN
Si se recibe un mensaje de apertura activa de la aplicacin
Enviar un segmento SYN
Cambiar el estado a SYN_SENT
Si se recibe cualquier segmento
Enviar un segmento RST
Si se recibe cualquier otro mensaje
Emitir un mensaje de error
return
165
3.4.- Diseo TCP
Mdulo principal (cont):

LISTEN: (El servidor espera llamadas del cliente)
Si se recibe un mensaje enviar datos de la aplicacin
Enviar un segmento SYN
Cambiar el estado a SYN-SENT
Si se recibe un segmento SYN
Enviar un segmento SYN+ACK
Cambiar el estado a SYN+RCVD
Si se recibe otro tipo de mensaje o segmento
Emitir un mensaje de error.
Return
SYN-SENT: (Se ha enviado una peticin de conexin, esperando el ACK)
Si time-out
Cambiar el estado a CLOSE
Si se recibe un segmento SYN
Enviar un segmento SYN+ACK
Cambiar el estado a SYN+RCVD
166
3.4.- Diseo TCP

Si se recibe un segmento SYN+ACK
Enviar un segmento ACK
Cambiar el estado a ESTABLISHED
Si se recibe otro mensaje o segmento
return
SYN-RCVD: (Se ha recibido una peticin de conexin)
Si se recibe un segmento ACK
Cambiar el estado a ESTABLISHED
Si time-out
Enviar un segmento RST.
Cambiar el estado a CLOSED
Si se recibe un mensaje cerrar conexin de la aplicacin
Enviar un segmento FIN
Cambiar el estado a FIN-WAIT-1
167
3.4.- Diseo TCP

Si se recibe un segmento RST
Cambiar el estado a LISTEN
Si llega otro mensaje o segmento
Return
ESTABLISHED: (Se ha establecido la conexin)
Si llega un segmento FIN
Cambiar el estado a CLOSE-WAIT
Si se recibe un mensaje de cerrar conexin de la aplicacin
Si se recibe un segmento RST o SYN
Entregar un mensaje de error
Si se recibe un segmento de datos o ACK
Llamar al mdulo de entrada.
168
3.4.- Diseo TCP

Si se recibe un mensaje enviar datos de la aplicacin
Llamar al mdulo de salida
return
FIN-WAIT-1: (La aplicacin ha pedido el cierre de la conexin)
Si se recibe un segmento FIN
Cambiar el estaco a CLOSING
Si se recibe un segmento FIN+ACK
Cambiar el estado a TIME-WAIT
Si se recibe un segmento ACK
Si se recibe otro tipo de segmento o mensaje
return
169
3.4.- Diseo TCP

FIN-WAIT-2: (La otra parte ha aceptado el cierre de conexin)
Si se recibe un segmento FIN
Cambiar el estaco a TIME-WAIT
return
CLOSING:
(Ambas partes han decidido cerrar la conexin
simultneamente)
Si se recibe un ACK
Cambiar el estado a TIME-WAIT
Si se recibe otro tipo de segmento o mensaje
Return
TIME-WAIT: (Esperar que los segmentos retransmitidos mueran)
Si time-out
Cambiar el estaco a CLOSED
return
170
3.4.- Diseo TCP

CLOSE-WAIT: (El servidor espera a la aplicacin para cerrar)
Si se recibe un mensaje cerrar conexin de la
aplicacin
Cambiar el estado a LAST-ACK
return
LAST-ACK: (El servidor est esperando el ltimo ACK)
Si se recibe un ACK
Cambiar el estado a CLOSED
return
171
4.4.- Diseo TCP
Mdulo de procesado de entradas:

Maneja todos los detalles necesarios para procesar los datos o ACKs
recibidos cuando el TCP est en el estado ESTABLISHED.
Este mdulo enva un ACK si es necesario, se encarga de comunicar el
tamao de la ventana, realiza el chequeo de error, etc.
Mdulo de procesado de salidas:

Maneja todos loa detalles para enviar los datos recibidos por la
aplicacin cuando TCP est en el modo ESTABLISHED.
Este modulo se encarga de gestionar los temporizadores de
retransmisin, persistencia, etc.
El modo de disear este mdulo es mediante un pequeo diagrama de
transiciones.
172

FR Tema3

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

FR Tema3

Caricato da

Copyright:

Formati disponibili

Tema 3: Protocolos de la capa de

TCP/IP Protocol Suite, fourth edition, Behrouz A. Forouzan, McGraw-Hill, 2010

Fundamentos de Redes de Computadores

Tema 3: Protocolos de la capa de transporte

Tema 3: Protocolos de la capa de transporte.

Tema 3: Protocolos de la capa de transporte

Tema 3: Protocolos de la capa de transporte.

Fundamentos de Redes de Computadores

Tema 3: Protocolos de la capa de transporte

3.1. - Propsito de la capa de transporte

2. UDP -Protocolo de Datagramas de Usuario

Tema 3: Protocolos de la capa de transporte

3.1. - Propsito de la capa de transporte

Nos vamos a centrar en la capa que:

Tema 3: Protocolos de la capa de transporte

3.1. - Propsito de la capa de transporte

Tema 3: Protocolos de la capa de transporte

3.1. Comunicaciones proceso a proceso:

Fundamentos de Redes de Computadores

Tema 3: Protocolos de la capa de transporte

3.1. TCP y UDP. Direccionamiento del puerto

Algunos puertos se reservan tanto en TCP como en

Tema 3: Protocolos de la capa de transporte

3.1. TCP y UDP. Direccionamiento del puerto

Fundamentos de Redes de Computadores

Tema 3: Protocolos de la capa de transporte

3.1. TCP y UDP. Direccionamiento del puerto

Para utilizar los servicios de la capa de transporte se

Fundamentos de Redes de Computadores

Tema 3: Protocolos de la capa de transporte

3.1. TCP y UDP. Direccionamiento del puerto

Fundamentos de Redes de Computadores

Tema 3: Protocolos de la capa de transporte

3.1. TCP y UDP. Direccionamiento del puerto

Fundamentos de Redes de Computadores

Tema 3: Protocolos de la capa de transporte

3.1. TCP y UDP. Direccionamiento del puerto

Dir. Socket origen

Tema 3: Protocolos de la capa de transporte

3.1 TCP y UDP. Direccionamiento del puerto

En la capa internet TCP/IP:

Tema 3: Protocolos de la capa de transporte

3.1 TCP y UDP. Direccionamiento del puerto

Cuando un paquete se encapsula en la Capa de Red, se

Tema 3: Protocolos de la capa de transporte

3.1 Encapsulado y desencapsulado

Desencapsulado: lo realiza el receptor.

Fundamentos de Redes de Computadores

Tema 3: Protocolos de la capa de transporte

3.1 Encapsulado y desencapsulado

Fundamentos de Redes de Computadores

Tema 3: Protocolos de la capa de transporte

3.1. Multiplexado y demultiplexado

Fundamentos de Redes de Computadores

Tema 3: Protocolos de la capa de transporte

3.1. Servicios orientados y no orientados a conexin

Fundamentos de Redes de Computadores

Tema 3: Protocolos de la capa de transporte

3.1. Servicios orientados y no orientados a conexin

Fundamentos de Redes de Computadores

Tema 3: Protocolos de la capa de transporte

3.1. Servicios orientados y no orientados a conexin

Tema 3: Protocolos de la capa de transporte