F R C T: Undamentos DE Edes APA DE Ransporte

FUNDAMENTOS DE REDES
CAPA DE TRANSPORTE
Daniel Barragán C.
daniel.barragan@correounivalle.edu.co
Lunes y Miércoles 3:00 pm a 5:00 pm – Edificio 331 Oficina 2114
Escuela de Ingeniería de Sistemas y Computación.

Fundamentos de Redes
Capa de transporte
http://eisc.univalle.edu.co/cursos/web/ver/750001M/7

Agenda
• Introducción
• Servicios de la Capa de Transporte
• Multiplexación de Aplicaciones
• UDP (User Datagram Protocol)
• TCP (Transmission Control Protocol)

Introducción
Proporciona una comunicación lógica entre aplicaciones. Desde
el punto de vista de las aplicaciones es como si estuvieran
conectadas físicamente aunque se encuentren en distintos
lugares del planeta

Servicios
La capa de transporte provee los siguientes servicios:
• Multiplexación de aplicaciones
• Detección de error
• Servicio orientados y no orientados a conexión
• Entrega confiable: confirmaciones de envió y recepción
• Control de flujo: monitoreo de buffers en emisor y receptor
• Control de congestión

Multiplexación de Aplicaciones
Capa de red
IP se encarga de la comunicación de equipo a equipo. IP no
entrega información entre aplicaciones.

Capa de transporte
La capa de transporte extiende la comunicación proporcionada
por la capa de red para proporcionar conexión entre aplicaciones

La capa de transporte recibe los segmentos de información de la
capa de red y se encarga de entregarlos a la aplicación apropiada

A cada aplicación se le asocia un numero de puerto, de esta
manera se tiene una identificación única de las aplicaciones
x 3306
y 80
z 22

Los puertos del 0 al 1023 se consideran puertos reservados. Los
puertos del 1024 al 65535 son puertos de propósito general
x 3306
y 80
z 22

Segmento de información
Los segmentos de información de la capa de transporte incluyen
información del puerto origen y puerto destino de la
comunicación

UDP
User Datagram Protocol
Protocolo No Orientado a Conexión.

UDP
Generalidades
• No hay establecimiento de la conexión. Los datos se envían
directamente sin negociar la comunicación
• No se guarda estado de la conexión. No se guarda información
para el control de flujo o confirmación
• Tiene una longitud de 64 bits (8 bytes) que se adicionan al
mensaje de la capa de aplicación
• La tasa de envío de información es variable y depende del
estado de la red (congestión)
• Provee detección de error (no recuperación)

UDP
Aplicaciones
Aplicación Protocolo en la capa de Protocolo en la capa de

aplicación transporte
Remote file server NFS UDP
Streaming multimedia Propietary UDP
Internet telephony Propietary UDP
Network management SNMP UDP
Routing Protocol RIP UDP
Name Translation DNS UDP

UDP
DNS ( Mensaje de aplicación vía UDP )
Cuando se requiere resolver un nombre de dominio ocurre lo
siguiente:
1. Se crea un mensaje de solicitud DNS

2. UDP adiciona una cabecera al mensaje y forma un segmento UDP
3. Se encapsula el segmento UDP en un datagrama IP
4. Se envía el datagrama IP a un servidor de nombres (DNS)
5. De no haber respuesta se intenta con otros servidores (DNS)

UDP
Estructura
El segmento de información UDP posee una cabecera de 4
campos, cada una de ellas compuesta por 16bits
source port destination port

length UDP checksum
data
32bits

UDP
Estructura
source port y destination port: son usadas para multiplexar
información hacia las aplicaciones de la capa superior
length: longitud del segmento UDP en bytes
UDP cheksum: empleado para detección de error

UDP
Detección de Error
El checksum de UDP proporciona detección de error. El
checksum se calcula por medio de la suma de los campos de la
cabecera del segmento UDP (también algunos campos de la
cabecera IP) y el complemento a uno del resultado de la suma

UDP
Detección de Error
El checksum de UDP proporciona detección de error. El
checksum se calcula por medio de la suma de los campos de la
cabecera del segmento UDP (también algunos campos de la
cabecera IP) y el complemento a uno del resultado de la suma
Pregunta: ¿Si existen protocolos en la capa de enlace como

Ethernet que realizan detección y corrección de error por que
UDP proporciona un mecanismo para detección de error?

UDP
Detección de Error (Ejemplo)
En el emisor
Contenido Cabecera UDP (1) 0110011001100110

Suma Cabecera en el emisor (1,2) 1011101110111011
Suma Cabecera en el emisor (1,2,3) 1100101011001010
Complemento a Uno 0011010100110101
Se transmite 0011010100110101

UDP
Detección de Error (Ejemplo)
En el receptor
Se recibe 0011010100110101
Suma Cabecera en el receptor (1,2,3) 1100101011001010
Suma de Comprobación 1111111111111111

UDP
Problema:
¿Cual es el valor del checksum que se transmite?

Suma Cabecera en el emisor (1,2)
Suma Cabecera en el emisor (1,2,3)
Complemento a Uno
Se transmite

UDP
Solución:
¿Cual es el valor del checksum que se transmite?

Suma Cabecera en el emisor (1,2) 1011101110111100
Suma Cabecera en el emisor (1,2,3) 1100011011001010
Complemento a Uno 0011100100110101
Se transmite 0011100100110101

TCP
Transmission Control Protocol
Protocolo Orientado a Conexión

TCP
Generalidades
• Hay establecimiento de la conexión. Los datos se envían una
vez se negocia la comunicación
• Se guarda estado de la conexión. Se guarda información para
el control de flujo o confirmación
• Tiene una longitud de 160 bits (20 bytes) que se adicionan al
mensaje de la capa de aplicación

TCP
Generalidades
• Es un protocolo punto a punto (no soporta multicasting)
• Es un protocolo full-duplex
• Provee detección de error (no recuperación)
• Puede tener en transito múltiples segmentos de datos sin
haber recibido confirmación (Pipelining)

TCP
Aplicaciones
Aplicación Protocolo en la capa de Protocolo en la capa de

aplicación transporte
Electronic mail SMTP TCP
Remote Terminal Access Telnet TCP
Web HTTP TCP
File Transfer FTP TCP

TCP
Estructura
source port destination port
sequence number
acknowledgement number
u a p r s f
header unused r c s s y i
rcvr window size
length g k h t n n
internet cheksum ptr to urgent data

options
data
32 bits
TCP
Estructura
source port y destination port: son usadas para multiplexar
información hacia las aplicaciones de la capa superior
sequence number y acknowledgement number: empleados
para implementar transferencia de datos confiable
window size: es empleado para indicar el numero de bytes que
el receptor esta dispuesto a aceptar
header length: longitud de la cabecera en unidades de 32 bits
options: es usado cuando se negocia el MSS y en redes de alta
velocidad para incrementar el tamaño de la ventana

TCP
Three-way handshake
La comunicación en TCP involucra un emisor (proceso cliente) y
receptor (proceso servidor). En el establecimiento de la conexión
se dan tres pasos.

TCP
Three-way handshake

TCP
Three-way handshake
1. El emisor envía un segmento especial con el bit SYN = 1 y un

numero de secuencia inicial seq = client_isn
2. El receptor envía un segmento especial con el bit ACK = 1 y
SYN = 1, envía una confirmación ack = client_isn + 1 y envía
su propio número de secuencia inicial seq = server_isn
3. El emisor envía un segmento especial con el bit ACK = 1,
envía un seq = client_isn +1 y ack = server_isn + 1

TCP
Transmisión de Información
1. El cliente envía un flujo de datos a través de un socket

TCP
2. TCP direcciona estos datos a un buffer.

TCP
3. TCP toma una cantidad MSS (Maximum Segment Size) de

bytes del buffer. MSS es comúnmente de 1500, 536, 512
bytes
TCP
4. TCP adiciona una cabecera TCP y entrega el segmento de

información TCP (datos + cabecera) a la capa de red

TCP
Nota: Si el tamaño de la información es superior al tamaño del

MSS se realizan varios envíos

TCP
¿Cual seria el tamaño del segmento TCP (datos+cabecera), para
una cabecera TCP sin opciones?

TCP
Números de Secuencia y Confirmación
La información esta conformada por un flujo de bytes
Cada byte esta asociado a un numero que indica su posición en
el flujo de información
El número de secuencia corresponde a la posición del byte que
inicia cada segmento

TCP
A partir de la gráfica se observa que para el segmento 1, el
número de secuencia que emplea el emisor es 0
Para el segmento 2 el número de secuencia es 1000
Para el segmento 3 el número de secuencia es 2000

TCP
El número de confirmación corresponde al siguiente byte del
flujo de datos que se espera recibir
Las confirmaciones TCP son acumulativas ( si se pierde el ack del
segmento1 pero se recibe el ack del segmento 2, se asume que
el receptor recibió el segmento 1 y 2)

TCP
A partir de la gráfica para confirmar que se ha recibido el
segmento 1 con los bytes desde el 0 hasta el 999, el receptor
envía el número de confirmación 1000

TCP
Problema:
Por medio de un grafico represente el envío de segmentos TCP
en una conexión de Telnet. Tenga en cuenta que un emisor envía
el carácter C y el receptor realiza un eco del carácter C. Emplee
como número de secuencia el 42 y como número de
confirmación 79
Nota: Telnet envía un solo carácter por cada transmisión

TCP

TCP
Transferencia Confiable
Para analizar la transferencia confiable en TCP se deben tener en
cuenta los siguientes aspectos:
• TCP divide la información de la aplicación en segmentos de
acuerdo al valor del MSS
• TCP inicia un temporizador de cuenta regresiva (timeout) con
cada envío de un segmento de información
• TCP recibe mensajes de confirmación por cada segmento que
recibe el receptor.

TCP
TCP inicia un temporizador de cuenta regresiva (timeout) con
cada envío de un segmento de información. Cuando el
temporizador expira y no se ha recibido confirmación del
receptor, se realiza un reenvió del segmento de información

TCP

TCP
Los números de confirmación en TCP (acknowledgement
number) son acumulativos. Si se pierde una confirmación de
recepción pero se recibe la que corresponde a un segmento
posterior, es debido a que el receptor recibió ambas
correctamente

TCP

TCP

TCP
El RFC 0793 correspondiente a TCP no especifica la acción a
realizar cuando se reciben segmentos fuera de orden. Es
decisión del desarrollador descartar los paquetes fuera de orden
o almacenarlos temporalmente y reordenar al obtener los
segmentos faltantes

TCP

TCP
Recomendaciones ACK (RFC 2581, RFC 1122)

TCP
Control de Flujo
El servicio de control de flujo de TCP permite evitar la saturación
del buffer del receptor.

TCP
Control de Flujo
TCP provee control de flujo a través de una variable en el emisor
llamada ventana del receptor

TCP
Control de Flujo
• En el receptor:
LastByteRcvd - LastByteRead <= RcvBuffer
RcvWindow = RcvBuffer – (LastByteRcvd – LastByteRead)

TCP
Control de Flujo
• En el emisor:
LastByteSend – LastByAcked <= RcvWindow

TCP
Control de Flujo
El valor del temporizador (timeout) de un segmento de datos se
debe calcular en relación al RTT (Round Trip Time) de acuerdo a
las siguientes consideraciones:
• No debe ser mucho mas corto que el RTT
• No debe ser mucho mas grande que el RTT

TCP
Control de Flujo
El valor del temporizador (timeout) de un segmento de datos se
debe calcular en relación al RTT (Round Trip Time) de acuerdo a
las siguientes consideraciones:
• No debe ser mucho mas corto que el RTT

– Genera retransmisiones innecesarias
• No debe ser mucho mas grande que el RTT
– Generar retardos amplios en la retransmisión

TCP
Control de Flujo
EstimatedRTT = (1-x)EstimatedRTT + x SampleRTT

TCP
Control de Flujo
Timeout = EstimatedRTT + 4*Deviation

Deviation = (1-x) Deviation + x | SampleRTT – EstimatedRTT |

TCP
Control de Flujo
Un valor comúnmente usado para x es 0.1

TCP
Control de Congestión
TCP provee mecanismos para el control de la congestión en la
red. La congestión en la red se produce cuando la cantidad de
información a enviar es cercana ó excede la capacidad del canal
de comunicación

Bibliografía
Computer Networking: A Top-Down Approach
Sexta Edición (2012)
James F. Kurose and Keith W. Ross
Using Snort and Ethereal to Master The 8 Layers Of An Insecure

Network
Primera Edición (2006)
Michael Gregg, Stephen Watkins, George Mays, Chris
Ries, Ronald M. Bandes, Brandon Franklin

Enlaces Adicionales
Herramientas
http://nmap.org/
http://www.hping.org/
http://drjohnstechtalk.com/blog/2012/06/compiling-hping-on-centos/
Páginas WEB
http://nmap.org/movies/
http://lamiradadelreplicante.com/2011/12/17/detectar-intrusos-en-la-red-
con-nmap-a-lo-trinity/
http://lamiradadelreplicante.com/2012/01/24/ataque-ddos-syn-flood-con-
hping3/

Asesorías
daniel.barragan@correounivalle.edu.co
Edificio 331 – Oficina 2114
Lunes y Miércoles 3:00 pm – 5:00 pm


F R C T: Undamentos DE Edes APA DE Ransporte

Cargado por

Copyright:

Formatos disponibles

F R C T: Undamentos DE Edes APA DE Ransporte

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

F R C T: Undamentos DE Edes APA DE Ransporte

Cargado por

Copyright:

Formatos disponibles

FUNDAMENTOS DE REDES

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Aplicación Protocolo en la capa de Protocolo en la capa de

Escuela de Ingeniería de Sistemas y Computación.

1. Se crea un mensaje de solicitud DNS

Escuela de Ingeniería de Sistemas y Computación.

source port destination port

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Pregunta: ¿Si existen protocolos en la capa de enlace como

Escuela de Ingeniería de Sistemas y Computación.

Contenido Cabecera UDP (1) 0110011001100110

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Contenido Cabecera UDP (1) 0110011001100111

Escuela de Ingeniería de Sistemas y Computación.

Contenido Cabecera UDP (1) 0110011001100111

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Aplicación Protocolo en la capa de Protocolo en la capa de

Escuela de Ingeniería de Sistemas y Computación.

internet cheksum ptr to urgent data

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

1. El emisor envía un segmento especial con el bit SYN = 1 y un

Escuela de Ingeniería de Sistemas y Computación.

1. El cliente envía un flujo de datos a través de un socket

Escuela de Ingeniería de Sistemas y Computación.

2. TCP direcciona estos datos a un buffer.

Escuela de Ingeniería de Sistemas y Computación.

3. TCP toma una cantidad MSS (Maximum Segment Size) de

4. TCP adiciona una cabecera TCP y entrega el segmento de

Escuela de Ingeniería de Sistemas y Computación.

Nota: Si el tamaño de la información es superior al tamaño del

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.

Nota: Telnet envía un solo carácter por cada transmisión

Escuela de Ingeniería de Sistemas y Computación.

Escuela de Ingeniería de Sistemas y Computación.