Protocolos de Red y Transporte

El Protocolo IPv4
Dr. Eduardo de la Cruz Gmez

Contenido

El Datagrama IP
Direccionamiento IPv4
Encapsulacin
Fragmentacin
Protocolo ARP
Protocolo ICMP

El datagrama IPv4
El datagrama IP es la unidad bsica de transferencia
entre un nodo origen y el destino.
Este datagrama viaja en el campo de datos de las
tramas MAC (Ethernet) de las distintas redes que va
atravesando.

Encapsulamiento IP

Encabezado IP
3
0
10
20
0
01234567890123356789012345678901
Tipo de
VERS HLEN
Longitud total
servicio
Desplazamiento de
Bande
Identificacin
ras
fragmento

TTL

Protocolo
CRC cabecera
Direccin IP origen
Direccin IP destino
Opciones IP (si las hay)
Relleno
Datos
...

Campos del datagrama IP

VERS (4 bits). Indica la versin del protocolo IP que se utiliz para crear
el datagrama. Actualmente se utiliza la versin 4 (IPv4) aunque ya se
estn preparando las especificaciones de la siguiente versin, la 6
(IPv6).
HLEN (4 bits). Longitud de la cabecera expresada en mltiplos de 32
bits. El valor mnimo es 5, correspondiente a 160 bits = 20 bytes.
Longitud total (16 bits). Indica la longitud total del datagrama
expresada en bytes. Como el campo tiene 16 bits, la mxima longitud
posible de un datagrama ser de 65535 bytes.
Tipo de servicio (Type Of Service). Los 8 bits de este campo se dividen a
su vez en:
Prioridad (3 bits). Un valor de 0 indica baja prioridad y un valor de 7,
prioridad
mxima.

Calidad de servicio
Los siguientes tres bits indican cmo se prefiere que se
transmita el mensaje, es decir, son sugerencias a los routers
que se encuentren a su paso los cuales pueden tenerlas en
cuenta o no.
Bit D (Delay). Solicita retardos cortos (enviar rpido).
Bit T (Throughput). Solicita un alto rendimiento (enviar mucho en el
menor tiempo posible).
Bit R (Reliability). Solicita que se minimice la probabilidad de que el
datagrama se pierda o resulte daado (enviar bien).
Los siguientes 2 bits no tienen uso.

 Identificador (16 bits). Nmero de secuencia que junto a

la direccin origen, direccin destino y el protocolo
utilizado identifica de manera nica un datagrama en toda
la Red. Si el datagrama fuese fragmentado, todos los
fragmentos llevaran el mismo identificador.
Banderas o indicadores (3 bits). Slo 2 bits de los 3 bits
disponibles estn actualmente utilizados. El bit de Ms
fragmentos (MF) indica que no es el ltimo datagrama. Y
el bit de No fragmentar (NF) prohibe la fragmentacin del
datagrama. Si este bit est activado y en una determinada
red se requiere fragmentar el datagrama, ste no se podr
transmitir y se descartar.

 Desplazamiento de fragmentacin (13 bits). Indica el

lugar en el cual se insertar el fragmento actual dentro del
datagrama completo, medido en unidades de 64 bits. Por
esta razn los campos de datos de todos los fragmentos
menos el ltimo tienen una longitud mltiplo de 64 bits. Si
el paquete no est fragmentado, este campo tiene el valor
de cero.
Tiempo de vida o TTL (8 bits). Nmero mximo de saltos
de encaminadores que puede atravesar el datagrama. En
cada encaminador se resta 1 a este nmero. Cuando
llegue a cero, el datagrama se descarta (tiempo de vida
excedido).

Protocolo (8 bits). Indica el protocolo utilizado en el

campo de datos: 1 para ICMP, 2 para IGMP, 6 para TCP y 17
para UDP.

 CRC cabecera (16 bits). Contiene la suma

de comprobacin de errores slo para la
cabecera del datagrama. La verificacin de
errores de los datos corresponde a las
capas superiores.

Direccin origen (32 bits). Contiene la

direccin IP del origen.
Direccin destino (32 bits). Contiene la
direccin IP del destino.

 Opciones IP. Este campo no es obligatorio y

especifica las distintas opciones solicitadas por el
usuario que enva los datos (generalmente para
pruebas de red y depuracin).
Relleno. Si las opciones IP (en caso de existir) no
ocupan un mltiplo de 32 bits, se completa con
bits adicionales hasta alcanzar el siguiente
mltiplo de 32 bits (recurdese que la longitud de
la cabecera tiene que ser mltiplo de 32 bits).

Direccionamiento IPv4

Direccionamiento IP
Direcciones de nodo (hostid)
Direcciones de red (netid)
Direcciones de subred (subnetid)
Estructura de 32 bits

Ejemplo 1: 142.168.20.1
Ejemplo 2: 192.168.20.1

Clases
El diseo de las clases de redes detienen el
problema del broadcast:

Class A: 1 - 126
Class B: 128 - 191
Class C: 192 - 223
Class D: 224 - 239 (multicasting)
Class E: 240 - 255 (experimental)

Reglas subredes
192. 168. 20. x / 24 red clase C
255. 255. 255. 0
mscara de red clase C

192.168.20.0
direccin de red
192.168.20.1-254 direcciones tiles (254)
192.168.20.255
direccin de broadcast
192.168.20.0-255 direcciones posibles (256)

Ejercicio
El proveedor de servicios de red le otorga un segmento
de una red clase C, por lo que le designa solo 16 redes
posibles. Y 16 nodos posibles por subred.

Anlisis: 192.168.20.x/255.255.255.240
Rango.
0.- 192.168.20.0-15
primera subred posible
1.- 192.168.20.16-30
primera subred til
. ............ ..
14.- 192.168.20.225-238 ultima subred til
15.- 192.168.20.239-255 ultima subred posible

Ejemplo cont
1.- 192.168.20.17-30

primera subred til

0.- 192.168.20.16 primer nodo posible (subnet id)

1.- 192.168.20.17 primer nodo til
.............
14.- 192.168.20.30 ltimo nodo til
15.- 192.168.20.31 ltimo nodo posible (broadcast)

11000000. 10101000. 10100. 11111

Anlisis
16 subredes posibles
16 nodos posibles por subred
16 x 16 = 256 nodos
Subred 0 (16 nodos posibles) se desperdicia.
Subred 15 (16 nodos posibles) se desperdicia.
14 subredes tiles (2 nodos por subred)
desperdicia (14 x 2) = 28 nodos.

Total de desperdicio con una mscara 240 = 60 nodos,

tiles = 196 nodos

Fragmentacin
Las tramas fsicas tienen un campo de datos y que es aqu
donde se transportan los datagramas IP. Sin embargo, este
campo de datos no puede tener una longitud indefinida
debido a que est limitado por el diseo de la red.

El MTU de una red es la mayor cantidad de datos que

puede transportar su trama fsica. El MTU de las redes
Ethernet es 1500 bytes y el de las redes Token-Ring, 8192
bytes.
Esto significa que una red Ethernet nunca podr
transportar un datagrama de ms de 1500 bytes sin
fragmentarlo.

Router
Un encaminador (router) fragmenta un datagrama en
varios si el siguiente tramo de la red por el que tiene que
viajar el datagrama tiene un MTU inferior a la longitud del
datagrama.

 Se desea transmitir un datagrama IP desde A que se

encuentra en la Red 1 hasta B de la Red 3 y que contiene
1400 bytes de datos (1420 bytes en total).
El datagrama no tiene ningn problema en atravesar la Red 1
ya que 1420 < 1500. Sin embargo, no es capaz de atravesar la
red 2 (1420 >= 620).
El encaminador R1 fragmenta el datagrama en el menor
nmero de fragmentos posibles que sean capaces de
atravesar la Red 2.
Cada uno de estos fragmentos es un nuevo datagrama con el
mismo identificador pero distinta informacin en los campos
de Desplazamiento de fragmentacin y MF.

Fragmento 1: Long. total = 620 bytes; Desp = 0; MF=1

Fragmento 2: Long. total = 620 bytes; Desp = 600; MF=1
Fragmento 3: Long. total = 220 bytes; Desp = 1200; MF=0

 Qu hace el encaminador R2? No reensambla, encamina

cada uno de los tres datagramas hasta la Red 3.
Cuando B reciba los fragmentos, recompondr el
datagrama original.
Observemos que los encaminadores intermedios no
reensamblan los fragmentos ya que esto supondra una
carga de trabajo adicional, a parte de memorias
temporales.
El nodo destino puede recibir los fragmentos en distinto
orden y que esto no supone ningn problema para el
reensamblado del datagrama original.

 Si el datagrama del ejemplo tuviese a 1 su bit de NF

(no fragmentar), no hubiera podido llegar a su
destino debido a que la Red 2 no es capaz de
atravesarla sin una fragmentacin previa.
El encaminador R1 descartara el datagrama.

Protocolo ARP
Dentro de una misma red fsica, las mquinas se
comunican envindose tramas fsicas. Estas tramas
van dirigidas a una mquina con una determinada
direccin fsica.
Observemos que las tramas Ethernet contienen un
campo con la direccin fsica de la mquina destino
(48 bits).

 El problema que se nos plantea es cmo podemos

conocer la direccin fsica de la mquina destino. Lo nico
que nosotros sabemos del destino es su direccin IP.
Necesitamos por tanto obtener la direccin fsica de un PC
a partir de su direccin IP.
Esto es justamente la misin del protocolo ARP (Address
Resolution Protocol, protocolo de resolucin de
direcciones).

 Se desea enviar un mensaje desde la mquina A con

direccin 194.18.133.5 a la mquina B con direccin
194.18.133.1.

Sin embargo la trama fsica, que es lo que realmente

se enva por el cable, necesita conocer la direccin
fsica del destino.

 El protocolo ARP funciona de la siguiente manera: A

enva un mensaje a todas las mquinas de su red
preguntando "Cul es la direccin fsica de la
mquina con direccin IP 194.18.133.1?".
La mquina con direccin 194.18.133.1 advierte que
la pregunta est dirigida a ella y responde a A con su
direccin fsica (A3.BB.05.33.12.99). Entonces, A
enva el mensaje a R.

 Observemos que las preguntas ARP son de difusin

(se envan a todas las mquinas). Estas preguntas
llevan adems la direccin IP y direccin fsica de la
mquina que pregunta.
La respuesta se enva directamente a la mquina que
formul la pregunta.

Tabla ARP (Cache ARP)

Cada computadora almacena una tabla de direcciones IP y
direcciones fsicas. Cada vez que formula una pregunta ARP y
le responden, inserta una nueva entrada a su tabla.

La primera vez que A quiera enviar un mensaje a B tendr

que difundir previamente una pregunta ARP. Sin embargo, las
siguientes veces que A enve mensajes a B ya no ser
necesario realizar nuevas preguntas, ya que A habr
almacenado en su tabla la direccin fsica de B.

Sin embargo, para evitar incongruencias en la red debido a

posibles cambios de direcciones IP o adaptadores de red, se
asigna un tiempo de vida de cierto nmero de segundos a
cada entrada de la tabla. Cuando se agote el tiempo de vida
de una entrada, sta ser eliminada de la tabla.

 Las tablas ARP reducen el trfico de la red al evitar

preguntas ARP innecesarias. Pensemos ahora en
distintas maneras para mejorar el rendimiento de la
red. Despus de una pregunta ARP, el destino conoce
las direcciones IP y fsica del origen.
Por lo tanto, podra insertar la correspondiente
entrada en su tabla. Pero no slo eso, sino que todas
las estaciones de la red escuchan la pregunta ARP:
podran insertar tambin las correspondientes
entradas en sus tablas.

Campos ARP
Hardware address space. Especifica el tipo de
hardware; ejemplos son Ethernet o Packet Radio
Net.
Protocol address space. Especifica el tipo de
protocolo, el mismo que en el campo de tipo
EtherType en la cabecera de IEEE 802.
Hardware address length. Especifica la longitud(en
bytes) de la direccin hardware del paquete.
Protocol address length. Especifica la longitud(en
bytes) de las direcciones del protocolo en el
paquete. Para IP ser de 4.

Operation code. Especifica si se trata de una

peticin(1) o una respuesta ARP (2).
Source/target hardware address. Contiene las
direcciones fsica hardware. En IEEE 802.3 son
direcciones de 48 bits.

Source/target protocol address. Contiene las

direcciones del protocolo. En TCP/IP son
direcciones IP de 32 bits.

Protocolo ICMP
Debido a que el protocolo IP no es fiable, los
datagramas pueden perderse o llegar defectuosos a
su destino.

El protocolo ICMP (Internet Control Message

Protocol, protocolo de mensajes de control y error)
se encarga de indicar al origen que su mensaje no ha
llegado correctamente.

 Protocolo IGMP. El protocolo IGMP (Internet

Group Management Protocol, protocolo de
administracin de grupos de Internet) es el
equivalente al ICMP pero entre
encaminadores.
ICMP nicamente informa al origen.

 Pero no slo se encarga de notificar los errores, sino

que tambin transporta distintos mensajes de
control.

Por ejemplo, si un encaminador no es capaz de

soportar la velocidad que le impone el nodo origen le
enviar un mensaje de control pidindole que
reduzca su velocidad.

 El protocolo ICMP nicamente informa de

distintas incidencias en la red pero no toma
ninguna decisin. Esto ser responsabilidad de las
capas superiores.
Los mensajes ICMP viajan en el campo de datos
de un datagrama IP.

Mensajes ICMP
Pero como el protocolo IP no es fiable, puede
darse el caso de que un mensaje ICMP se pierda o
se dae. Sin embargo, si esto llegase a ocurrir no
se crear un nuevo mensaje ICMP sino que el
primero se descartar sin ms.

Tipos de mensajes ICMP

Un ejemplo:
Cuando un nodo A solicita un eco a un nodo B, le
est enviando un mensaje del tipo 8 y le est
pidiendo que le confirme que este mensaje le ha
llegado correctamente contestando con un nuevo
mensaje de respuesta de eco.
Si al nodo A le llega la respuesta, esto significa que la
comunicacin entre el origen y el destino es correcta.

 Ms concretamente estamos probando que

nuestro nodo y el nodo B son capaces de enviar y
recibir correctamente datagramas IP; es decir, los
protocolos, adaptadores de red y cableado
funcionan correctamente.

Y adems existen rutas vlidas entre el origen y el

destino.
La orden Ping enva mensajes de solicitud de eco
e informa de las respuestas.

La capa de Transporte

La capa de transporte
Puertos
UDP
TCP

Transporte
La capa de red transfiere datagramas entre dos
nodos a travs de la red utilizando como
identificadores las direcciones IP.
La capa de transporte aade la nocin de puerto para
distinguir entre los muchos destinos dentro de un
mismo host.
No es suficiente con indicar la direccin IP del
destino, adems hay que especificar la aplicacin que
recoger el mensaje.

 Cada aplicacin que est esperando un mensaje

utiliza un nmero de puerto distinto; ms
concretamente, la aplicacin est a la espera de un
mensaje en un puerto determinado (escuchando un
puerto).
Pero no slo se utilizan los puertos para la recepcin
de mensajes, tambin para el envo: todos los
mensajes que enve una PC debe hacerlo a travs de
uno de sus puertos

 El siguiente diagrama representa una

transmisin entre el nodo 194.35.133.5 y el
135.22.8.165.
El primero utiliza su puerto 1256 y el
segundo, el 80.

 La capa de transporte transmite mensajes entre las aplicaciones de

dos PCs. Por ejemplo, entre nuestro navegador de pginas Web y un
servidor de pginas Web, o entre nuestro programa de correo
electrnico y un servidor de correo.

Puertos
Un nodo puede estar conectado con distintos servidores a la
vez; por ejemplo, con un servidor de noticias y un servidor de
correo.
Para distinguir las distintas conexiones dentro de un mismo
computador se utilizan los puertos.
Un puerto es un nmero de 16 bits, por lo que existen 65536
puertos en cada computador.
Las aplicaciones utilizan estos puertos para recibir y transmitir
mensajes.

Nmeros de puertos
Los nmeros de puerto de las aplicaciones cliente
son asignados dinmicamente y generalmente son
superiores al 1024.
Cuando una aplicacin cliente quiere comunicarse
con un servidor, busca un nmero de puerto libre y
lo utiliza.
En cambio, las aplicaciones servidoras utilizan unos
nmeros de puerto prefijados: son los llamados
puertos well-known (bien conocidos).

 Estos puertos estn definidos en el RFC 1700 y

se pueden consultar en:
http://www.faqs.org/rfcs/rfc1700.html.

A continuacin se enumeran los puertos wellknown ms usuales:

 Los puertos tienen una memoria intermedia

(buffer) situada entre los programas de aplicacin
y la red.
De tal forma que las aplicaciones transmiten la
informacin a los puertos. Aqu se va
almacenando hasta que pueda enviarse por la
red.
Una vez que pueda transmitirse, la informacin
ir llegando al puerto destino donde se ir
guardando hasta que la aplicacin est preparada
para recibirla.

Protocolos de capa de transporte

Los dos protocolos principales de la capa de
transporte son UDP y TCP.
El primero ofrece una transferencias de
mensajes no fiable y no orientada a conexin
y el segundo, una transferencia fiable y
orientada a conexin.

Protocolo UDP
El protocolo UDP (User Datagram Protocol,
protocolo de datagrama de usuario)
proporciona una comunicacin muy sencilla
entre las aplicaciones de dos computadores.

 UDP es:
No orientado a conexin. No se establece una
conexin previa con el otro extremo para transmitir
un mensaje UDP. Los mensajes se envan sin ms y
stos pueden duplicarse o llegar desordenados al
destino

No fiable. Los mensajes UDP se pueden perder o

llegar daados.

 UDP utiliza el protocolo IP para transportar sus

mensajes. No aade ninguna mejora en la calidad de
la transferencia; aunque s incorpora los puertos
origen y destino en su formato de mensaje.
Las aplicaciones (y no el protocolo UDP) debern
programarse teniendo en cuenta que la informacin
puede no llegar de forma correcta.

Encabezado UDP
3
0
10
20
0
01234567890123356789012345678901
Puerto UDP origen
Puerto UDP destino
Longitud mensaje UDP
Suma verificacin UDP
Datos
...

Campos del encabezado UDP

Puerto UDP de origen (16 bits, opcional). Nmero de
puerto de la mquina origen.
Puerto UDP de destino (16 bits). Nmero de puerto
de la mquina destino.
Longitud del mensaje UDP (16 bits). Especifica la
longitud medida en bytes del mensaje UDP
incluyendo la cabecera. La longitud mnima es de 8
bytes.

 Suma de verificacin UDP (16 bits, opcional). Suma de

comprobacin de errores del mensaje. Para su clculo se
utiliza una pseudo-cabecera que tambin incluye las
direcciones IP origen y destino. Para conocer estos datos,
el protocolo UDP debe interactuar con el protocolo IP.
Datos. Aqu viajan los datos que se envan las
aplicaciones. Los mismos datos que enva la aplicacin
origen son recibidos por la aplicacin destino despus de
atravesar toda la Red de redes.

El protocolo TCP
El protocolo TCP (Transmission Control Protocol,
protocolo de control de transmisin) est basado en
IP que es no fiable y no orientado a conexin, y sin
embargo es:
Orientado a conexin. Es necesario establecer una
conexin previa entre las dos mquinas antes de
poder transmitir ningn dato. A travs de esta
conexin los datos llegarn siempre a la aplicacin
destino de forma ordenada y sin duplicados.
Finalmente, es necesario cerrar la conexin.
Fiable. La informacin que enva el emisor llega de
forma correcta al destino.

 El protocolo TCP permite una comunicacin fiable

entre dos aplicaciones. De esta forma, las
aplicaciones que lo utilicen no tienen que
preocuparse de la integridad de la informacin: dan
por hecho que todo lo que reciben es correcto.
El flujo de datos entre una aplicacin y otra viajan
por un circuito virtual (rutas IP).

 Esto significa que los datagramas IP que transportan

los mensajes siguen rutas diferentes aunque el
protocolo TCP logr la ilusin de que existe un nico
circuito por el que viajan todos los bytes uno detrs
de otro (algo as como una tubera entre el origen y
el destino).
Para que esta comunicacin pueda ser posible es
necesario abrir previamente una conexin.

 Esta conexin garantiza que los todos los

datos lleguen correctamente de forma
ordenada y sin duplicados.

La unidad de datos del protocolo es el byte, de

tal forma que la aplicacin origen enva bytes
y la aplicacin destino recibe estos bytes.

 Sin embargo, cada byte no se enva inmediatamente

despus de ser generado por la aplicacin, sino que
se espera a que haya una cierta cantidad de bytes, se
agrupan en un segmento y se enva el segmento
completo.
Para ello son necesarias unas memorias intermedias
o buffers.

 Cada uno de estos segmentos viaja en el campo de

datos de un datagrama IP. Si el segmento es muy
grande ser necesario fragmentar el datagrama, con
la consiguiente prdida de rendimiento; y si es muy
pequeo, se estarn enviando ms cabeceras que
datos.
Por consiguiente, es importante elegir el mayor
tamao de segmento posible que no provoque
fragmentacin.

 El protocolo TCP enva un flujo de informacin no

estructurado. Esto significa que los datos no tienen
ningn formato, son nicamente los bytes que una
aplicacin enva a otra. Ambas aplicaciones
debern ponerse de acuerdo para comprender la
informacin que se estn enviando.
Cada vez que se abre una conexin, se crea un
canal de comunicacin bidireccional en el que
ambas aplicaciones pueden enviar y recibir
informacin, es decir, una conexin es full-dplex

Confiabilidad TCP
Cmo es posible enviar informacin
basndose en un protocolo no fiable?

fiable

Es decir, si los datagramas que transportan los

segmentos TCP se pueden perder, cmo pueden
llegar los datos de las aplicaciones de forma correcta
al destino?

 La respuesta a esta pregunta es: cada vez que llega

un mensaje se devuelve una confirmacin
(acknowledgement) para que el emisor sepa que ha
llegado correctamente.
Si no le llega esta confirmacin pasado un cierto
tiempo, el emisor reenva el mensaje.

Ejemplo
El emisor enva un dato, arranca su temporizador y
espera su confirmacin (ACK).
Si recibe su ACK antes de agotar el temporizador,
enva el siguiente dato. Si se agota el temporizador
antes de recibir el ACK, reenva el mensaje.

ACK

Not ACK

 Este esquema es perfectamente vlido aunque muy

ineficiente debido a que slo se utiliza un sentido de
la comunicacin a la vez y el canal est
desaprovechado la mayor parte del tiempo.
Para solucionar este problema se utiliza un protocolo
de ventana deslizante, que se resume en el siguiente
esquema:

 Los mensajes y las confirmaciones van numerados y

el emisor puede enviar ms de un mensaje antes de
haber recibido todas las confirmaciones anteriores

Conexiones
Una conexin son dos pares direccin IP : puerto.
No puede haber dos conexiones iguales en un
mismo instante en toda la Red. Aunque bien es
posible que un mismo nodo tenga dos conexiones
distintas y simultneas utilizando un mismo puerto.
El protocolo TCP utiliza el concepto de conexin
para identificar las transmisiones.

 En el siguiente ejemplo se han creado tres

conexiones. Las dos primeras son al mismo
servidor Web (puerto 80) y la tercera a un servidor
de FTP (puerto 21).

Nodo 1
Nodo2
194.35.133.5:1256 135.22.8.165:80
184.42.15.16:1305 135.22.8.165:80
184.42.15.16:1323 135.22.10.15:21

 Para que se pueda crear una conexin, el

extremo del servidor debe hacer una apertura
pasiva del puerto (escuchar su puerto y quedar a
la espera de conexiones) y el cliente, una
apertura activa en el puerto del servidor
(conectarse con el puerto de un determinado
servidor).
Nota: El comando NetStat muestra las conexiones abiertas en un nodo, as como

estadsticas de los distintos protocolos de Internet.

Formato TCP
El flujo de bytes que produce una determinada aplicacin se
divide en uno o ms segmentos TCP para su transmisin.

Cada uno de estos segmentos viaja en el campo de datos de

un datagrama IP. Para facilitar el control de flujo de la
informacin los bytes de la aplicacin se numeran.

De esta manera, cada segmento indica en su cabecera el

primer byte que transporta. Las confirmaciones o acuses de
recibo (ACK) representan el siguiente byte que se espera
recibir (y no el nmero de segmento recibido, ya que ste no
existe).

Encabezado TCP
3
0
01234567890123356789012345678901
Puerto TCP origen
Puerto TCP destino
Nmero de secuencia
Nmero de acuse de recibo
Reservad
Bits
HLEN
Ventana
o
cdigo
Suma de verificacin
Puntero de urgencia
Opciones (si las hay)
Relleno
Datos
...
0

10

20

Campos TCP
Puerto fuente (16 bits). Puerto de la mquina origen.
Al igual que el puerto destino es necesario para
identificar la conexin actual.
Puerto destino (16 bits). Puerto de la mquina
destino.
Nmero de secuencia (32 bits). Indica el nmero de
secuencia del primer byte que trasporta el segmento.

 Nmero de acuse de recibo (32 bits). Indica el

nmero de secuencia del siguiente byte que se
espera recibir. Con este campo se indica al otro
extremo de la conexin que los bytes anteriores
se han recibido correctamente.
HLEN (4 bits). Longitud de la cabecera medida en
mltiplos de 32 bits (4 bytes). El valor mnimo de
este campo es 5, que corresponde a un segmento
sin datos (20 bytes).

 Reservado (6 bits). Bits reservados para un posible

uso futuro.
Bits de cdigo o indicadores (6 bits). Los bits de
cdigo determinan el propsito y contenido del
segmento. A continuacin se explica el significado de
cada uno de estos bits (mostrados de izquierda a
derecha) si est a 1.
URG. El campo Puntero de urgencia contiene
informacin vlida

 ACK. El campo Nmero de acuse de recibo contiene

informacin vlida, es decir, el segmento actual lleva
un ACK. Observemos que un mismo segmento puede
transportar los datos de un sentido y las
confirmaciones del otro sentido de la comunicacin.
PSH. La aplicacin ha solicitado una operacin push
(enviar los datos existentes en la memoria temporal
sin esperar a completar el segmento).

RST. Interrupcin de la conexin actual.

 SYN. Sincronizacin de los nmeros de secuencia.

Se utiliza al crear una conexin para indicar al otro
extremo cual va a ser el primer nmero de
secuencia con el que va a comenzar a transmitir
(veremos que no tiene porqu ser el cero).
FIN. Indica al otro extremo que la aplicacin ya no
tiene ms datos para enviar. Se utiliza para
solicitar el cierre de la conexin actual.
Ventana (16 bits). Nmero de bytes que el emisor
del segmento est dispuesto a aceptar por parte
del destino.

 Suma de verificacin (24 bits). Suma de

comprobacin de errores del segmento actual. Para
su clculo se utiliza una pseudo-cabecera que
tambin incluye las direcciones IP origen y destino.
Puntero de urgencia (8 bits). Se utiliza cuando se
estn enviando datos urgentes que tienen preferencia
sobre todos los dems e indica el siguiente byte del
campo Datos que sigue a los datos urgentes. Esto le
permite al destino identificar donde terminan los
datos urgentes. Ntese que un mismo segmento
puede contener tanto datos urgentes (al principio)
como normales (despus de los urgentes).

 Opciones (variable). Si est presente nicamente se

define una opcin: el tamao mximo de segmento
que ser aceptado.

Relleno. Se utiliza para que la longitud de la cabecera

sea mltiplo de 32 bits.
Datos. Informacin que enva la aplicacin.

Saludo de 3 vas

Antes de transmitir cualquier informacin

utilizando el protocolo TCP es necesario abrir una
conexin.
Un extremo hace una apertura pasiva y el otro,
una apertura activa.
El mecanismo utilizado para establecer una
conexin consta de tres vas.

Tres vas

Secuencia
1.

La mquina que quiere iniciar la conexin hace una apertura

activa enviando al otro extremo un mensaje que tenga el bit
SYN activado. Le informa adems del primer nmero de
secuencia que utilizar para enviar sus mensajes.

2.

La mquina receptora (un servidor generalmente) recibe el

segmento con el bit SYN activado y devuelve la
correspondiente confirmacin. Si desea abrir la conexin,
activa el bit SYN del segmento e informa de su primer nmero
de secuencia. Deja abierta la conexin por su extremo.

3. La primera mquina recibe el segmento y enva su

confirmacin. A partir de este momento puede
enviar datos al otro extremo. Abre la conexin por
su extremo.
4. La mquina receptora recibe la confirmacin y
entiende que el otro extremo ha abierto ya su
conexin. A partir de este momento puede enviar
ella tambin datos. La conexin ha quedado
abierta en los dos sentidos.

 Observamos que son necesarios 3

segmentos para que ambas mquinas
abran sus conexiones y sepan que la otra
tambin est preparada

Nmeros de secuencia
Se utilizan nmeros de secuencia distintos
para cada sentido de la comunicacin. Como
hemos visto el primer nmero para cada
sentido se acuerda al establecer la
comunicacin. Cada extremo se inventa un
nmero aleatorio y enva ste como inicio de
secuencia.

 Observamos que los nmeros de secuencia no

comienzan entonces en el cero. Por qu se procede
as? Uno de los motivos es para evitar conflictos:
supongamos que la conexin en un nodo se
interrumpe nada ms empezar y se crea una nueva.
Si ambas han empezado en el cero es posible que el
receptor entienda que la segunda conexin es una
continuacin de la primera (si utilizan los mismos
puertos).

Cierre de conexin
Cuando una aplicacin ya no tiene ms datos
que transferir, el procedimiento normal es
cerrar la conexin utilizando una variacin del
mecanismo de 3 vas explicado anteriormente

Ejemplo de un cierre de conexin

 El mecanismo de cierre es algo ms

complicado que el de establecimiento de
conexin debido a que las conexiones son fullduplex y es necesario cerrar cada uno de los
dos sentidos de forma independiente.

Secuencia de cierre de conexin

1.

La mquina que ya no tiene ms datos que transferir, enva un

segmento con el bit FIN activado y cierra el sentido de envo. Sin
embargo, el sentido de recepcin de la conexin sigue todava
abierto.

2.

La mquina receptora recibe el segmento con el bit FIN activado

y devuelve la correspondiente confirmacin. Pero no cierra
inmediatamente el otro sentido de la conexin sino que informa
a la aplicacin de la peticin de cierre. Aqu se produce un lapso
de tiempo hasta que la aplicacin decide cerrar el otro sentido de
la conexin.

3. La primera mquina recibe el segmento ACK.

4. Cuando la mquina receptora toma la decisin
de cerrar el otro sentido de la comunicacin,
enva un segmento con el bit FIN activado y
cierra la conexin.

5. La primera mquina recibe el segmento FIN y enva

el correspondiente ACK. Observemos que aunque
haya cerrado su sentido de la conexin sigue
devolviendo las confirmaciones.
6. La mquina receptora recibe el segmento ACK.

FIN

Gracias por su atencin