16TCP 628KB May 16 2016 05:03:54 PM

UDPUDP-TCP
Protocolo UDP – User Datagram Protocol
• UDP es un protocolo de transporte estándar que se define en la RFC 768 - "User
Datagram Protocol“. Campo IP Protocol: 17.
• Toda implementación TCP/IP que no se use exclusivamente para ruteo incluye
UDP.
• Para IP, UDP es básicamente una interfaz de aplicación. No añade fiabilidad,
control de flujo o recuperación de errores a IP. Simplemente sirve como
"multiplexor/ demultiplexor" para enviar y recibir datagramas, usando los puertos
para dirigir los datagramas.
• UDP suministra un mecanismo para que una aplicación envíe un datagrama a
otra. Se considera que la capa de UDP es muy sencilla y en consecuencia tiene
poco "overhead", pero requiere que la aplicación se responsabilice de la
recuperación de errores y demás cuestiones que hagan a la confiabilidad en la Tx.
• Las aplicaciones que envían datagramas a un host necesitan identificar un
objetivo más específico que la dirección IP, ya que los datagramas suelen dirigirse
a procesos concretos y no a todo el sistema. UDP permite hacer esto al hacer uso
de los puertos. Concepto de socket.
Ports TCP/UDP
• Un puerto es un número de 16 bits que identifica en un host el proceso que está
asociado a un datagrama. Existen dos tipos de puertos:
• Puertos Bien-conocidos("well-known"): Identifican a los servidores estándar, por
ejemplo Telnet usa el puerto 23. Los puertos bien-conocidos se hallan en el rango de 1
a 1023. La mayoría de los servidores requieren sólo un único puerto. Una excepción
es el servidor BOOTP que usa dos: el 67 y el 68 para Cliente y Servidor. La razón de
ser de los puertos bien-conocidos es permitir a los clientes encontrar a los servidores
sin necesidad de información de configuración. Los números de los puertos bienconocidos se definen en STD 2 - Números asignados de Internet("Assigned Internet
Numbers").
• Puertos Efímeros: Los clientes no necesitan puertos bien-conocidos porque inician la
comunicación con los servidores y los datagramas UDP enviados al servidor contienen
su número de puerto. El host en funcionamiento proporciona un puerto a cada proceso
cliente mientras este lo necesite. Los números de puertos efímeros tienen valores
mayores de 1023, por lo general en el rango de 1024 a 5000. Un cliente puede usar
cualquier número en ese rango, siempre que la combinación <protocolo de transporte,
dirección IP, número de puerto> sea unívoca .
• El esquema se sostiene para TCP, aunque sus puertos son totalmente
independientes de los de UDP. Normalmente, un servidor usará TCP o UDP, aunque
hay excepciones. Por ejemplo, el DNS usa tanto el puerto 53 de UDP como el 53 de
TCP.
Ports TCP/UDP
• En este sitio se puede encontrar un listado de ports bien conocidos:
http://www.iss.net/security_center/advice/Exploits/Ports/default.htm
• Clickeando sobre cada número se obtendrá una breve explicación de la
aplicación referenciada.
• Algunas aplicaciones pueden funcionar sobre UDP o TCP con el mismo número
de puerto.
• Existen puertos bien conocidos por encima de 1023, por ejemplo el puerto 8080
queda reservado como puerto alternativo para un servidor web Apache.
• Existen programas que permiten determinar cuáles puertos se encuentran
¨abiertos¨ (en estado LISTEN, preparados para recibir requerimientos) en una
máquina y lo hacen a través de una red. El sentido puede deberse al montaje de
un ataque: una vez descubiertos los puertos abiertos, se pueden buscar
vulnerabilidades para atacar la máquina objetivo.
Protocolo UDP
• Cada datagrama UDP se envía encapsulado en un sólo datagrama de IP. Aunque el
datagrama IP se fragmente durante la transmisión, la implementación de IP que lo
reciba lo reensamblará antes de pasárselo a la capa de UDP.
• Todas las implementaciones de IP deben aceptar datagramas de 576 bytes, lo que
significa que si se supone un tamaño máximo de 60 bytes para la cabecera IP, queda
un tamaño de 516 bytes para el datagrama UDP, aceptado por todas las
implementaciones. Muchas implementaciones aceptan datagramas más grandes, pero
no es algo que esté garantizado.
• El datagrama UDP tiene una cabecera de 8 bytes:
Puerto origen: puerto del proceso que envía el datagrama.
Puerto destino: puerto destino en el host de destino.
Longitud: en bytes del mismo datagrama de usuario, incluyendo la cabecera.
Checksum: campo opcional consistente en el complemento a uno de 16 bits de la
suma en complemento a uno de una pseudocabecera IP, la cabecera UDP y los datos
del datagrama UDP. La pseudocabecera IP contiene las direcciones IP de origen y
destino, el protocolo y la longitud del datagrama UDP.
Protocolo UDP. Pseudoheader para Checksum
Protocolo UDP - Aplicaciones
• La API (Application Interface) ofrecida por UDP se describe en el en RFC 768.
• Proporciona:
Creación de nuevos puertos para la recepción.
Operación de recepción que devuelve los bytes de datos recibidos y una indicación del
puerto y la dirección IP de origen.
Operación de envío que tiene como parámetros los datos, los puertos de origen y
destino y las direcciones IP.
• La forma en que se implementa esto queda a elección del cada distribuidor.
• Recordar que IP y UDP no proporcionan una entrega garantizada, control de flujo ni
recuperación de errores, así que estos deberán ser implementados por la aplicación.
Aplicaciones estándar que usan UDP son:
TFTP("Trivial File Transfer Protocol")
DNS("Domain Name System")
RPC("Remote Procedure Call"), usado por el NFS("Network File System")
NCS("Network Computing System")
SNMP("Simple Network Management Protocol")
Protocolo UDP - Aplicaciones
• Algunas aplicaciones, tales como TFTP agregan mecanismos rudimentarios para dar
confiabilidad a la Tx.
Streaming media: Requiere poseer velocidad de CPU y BW suficiente para soportar
las velocidades requeridas. También exige crear caminos de baja latencia en el SO
para evitar el buffer underrun (buffer llenándose de datos a menor velocidad que
cuando se vacía al ser leído). Por ejemplo radios en Internet. UDP + protocolos QoS
Real-time multiplayer games Adaptable UDP / TCP
VoIP: Emplean protocolos de sesión para controlar la conexión y desconexión de
una llamada, junto con codecs de audio para codificar voz y poder Tx sobre una red IP
(algunas implementaciones se basan en voz comprimida de ancho de banda angosto
y otras soportan estéreo de alta fidelidad). RTP + UDP
• Las aplicaciones que necesariamente requieran confiabilidad deben usar TCP.
• TRACERT, TRACEROUTE
Protocolo TCP – Transmission Control Protocol
Existen distintos tipos de redes con distintos modos de funcionamiento: de
conmutación de circuitos, de conmutación de paquetes, orientado a la conexión,
sin conexión. Cada tipo de red lleva asociado una serie de protocolos, pero por
encima de la capa de red existen los llamados protocolos de aplicación y otros
que le dan soporte.
Los protocolos de capa de transporte ocultan a las aplicaciones los servicios
proporcionados por las capas de red, proporcionando servicios independientes de
los servicios de red.
En la arquitectura TCP/IP existen TCP (Transmission Control Protocol) y UDP
(User Datagram Protocol). TCP proporciona un servicio orientado a la conexión.
UDP proporciona un servicio sin conexión. Utilizar uno u otro depende de los
requisitos de la aplicación en cuestión.
Protocolo TCP
TCP y UDP corren como procesos / aplicaciones dentro del núcleo del SO o a
veces como paquetes de librerías enlazados a la aplicación.
La mayoría de las aplicaciones en red se basan en el paradigma Cliente Servidor.
TCP proporciona confiabilidad al servicio de best effort ofrecido por IP:
UDP proporciona un servicio sin conexión no confiable, válido para aquellas
aplicaciones para los cuales resulta aceptable.
Utilizar uno u otro depende de los requisitos de la aplicación en cuestión. De
todas maneras la comunicación es end-to-end.
Debe haber una forma en que ambos protocolos, TCP y UDP, distingan las
diversas aplicaciones que sobre ellos se apoyan. Esta funcionalidad se expresa
en un campo de la cabecera de ambos que consiste en los números de puerto,
tanto fuente como destino.
En general, del lado de la aplicación Cliente, el número de puerto tiene un
significado local, asignándose un nuevo número cada vez que un Cliente solicita
una transferencia. A estos números de puerto clientes se los denomina, por ello,
puertos efímeros. Normalmente van del 1024 al 5000.
Los números de puerto de los Servidores, por el contrario, son fijos y se
denominan puertos bien conocidos. Normalmente van del 1 al 1023 (por ejemplo
FTP 21)
Protocolo TCP
TCP ofrece un servicio bidireccional para transferencia de datos confiable.
Los datos en TCP se transmiten en segmentos cuyo tamaño depende de la MTU
(Maximum Transmission Unit) (MSS, Maximum Segment Size). Cada vez que
TCP transmite un segmento inicia un timer y se espera un ACK del otro extremo.
Si no lo recibe, inicia una retransmisión. Se denomina a esta estrategia de
timeout y retransmisión. Cada segmento debe ser reconocido mediante un ACK,
pero esto puede realizarse de manera acumulativa.
Existe un checksum a nivel de (header+datos) TCP que es del tipo end-to-end. Si
en recepción se perciben errores, se descarta el segmento y no se transmite ACK.
Para contrarrestar la posible llegada de segmentos fuera de orden, TCP debe
contar con alguna información extra para reordenamiento.
TCP además debe ser capaz de descartar duplicados (por pérdida de ACK y
retransmisión).
Un mecanismo de control de flujo permite acomodar diferencias entre tamaños de
buffer y velocidad entre los extremos en comunicación.
A pesar que las aplicaciones poseen estructuras definidas, la misma es
transparente al protocolo TCP, cuyos extremos de comunicación tratan el flujo de
datos como un flujo de bytes. Se referencia a esta propiedad como orientado al
stream de bytes.
Se incluye un mecanismo de control de congestión.
Protocolo TCP - SOCKETS
Sockets permite la comunicación entre dos procesos diferentes en la misma o en
diferentes máquinas.
S trata de una forma de comunicación entre computadoras que utiliza el concepto
de file descriptors de Unix. En Unix toda acción del tipo I/O se realiza leyendo o
escribiendo un file descriptor. El file descriptor es un entero asociado con un
archivo abierto que puede ser una conexión de red, un archivo de texto o un
terminal.
Para un programador se trata de un concepto de bajo nivel ya que los comandos
del tipo read() y write() funcionan con sockets de la misma manera que lo hacen
con archivos o pipes. La diferencia entre sockets y los file descriptors normales se
establece en la creación del socket y en la incorporación de operaciones
especiales para control del socket.
Un Socket de Unix se usa en aplicaciones C-S. La mayoría de las aplicaciones
tipo FTP, SMTP, POP3, etc. usan Sockets para establecer conexión entre C y S.
Existen 4 tipos de Sockets pero sólo 2 son los más usados. Se supone que los
procesos se comunican sólo entre sockets del mismo tipo.
Stream Sockets: Entrega en red garantizada y en orden. Se usa TCP para Tx
datos. Si la entrega no es posibe, el Tx recibe un indicador de error. Los registros
de datos no tienen límites.
Datagram Sockets: Entrega en red no garantizada. Son sin conexión, se
construye un paquete y sencillamente se Tx. Usan UDP.
Protocolo TCP. Tipos de S y C
Iterative Server: Es el más sencillo. Se atiende un C por vez. Luego de completar
un requerimiento se atiende otro C. El segundo C debe esperar que el S se
desocupe.
Concurrent Servers: Este tipo permite correr múltiples procesos y servir varios
requerimientos a la vez. La forma más sencilla de hacerlo en Unix es por medio
de fork que abre un proceso child para manejar cada C por separado.
Las llamadas al sistema para establecer una conexión son diferentes para C y
para S, pero ambas incluyen la construcción básica de un socket. Ambos
procesos establecen sus propios sockets.
Del lado Cliente, se crea un socket con la llamada al sistema socket(). Se conecta
el socket a la dirección del S con la llamada al sistema connect(). Se Tx y Rx
datos con las llamadas al sistema read() y write().
Del lado Server se crea un socket con la llamada al sistema socket(). Se asocia el
socket a una dirección con la llamada al sistema bind(). En Internet un socket de
S tiene una dirección que consiste en un número de puerto en la máquina host.
Se escuchan conexiones con la llamada al sistema listen(). Se aceptan
conexiones con accept(). Esta llamada típicamente se bloquea hasta que un C se
conecta con el S. Se Tx y Rx datos con las llamadas al sistema read() y write().
Protocolo TCP. Tipos de S y C
Primitivas socket de Unix Berkeley. Se
trata de un conjunto de llamadas al
SO
que
constituyen
un
API
(Application Program Interface) para la
pila TCP/IP que subyace.
Los procesos de aplicación de usuario
(AP`s) que se comunicarán, primero
crean un canal de comunicación entre
el AP propiamente dicho y la entidad
local TCP. Este canal se denomina
socket o punto terminal.
Si se trata de una AP tipo Servidor,
esta enviará una secuencia de
llamadas a primitivas : socket(), bind(),
listen(), accept(). Cada llamada lleva
asociado un conjunto de parámetros,
un valor o más de salida y un código
de error.
Por su parte el AP Cliente envía una
primitiva socket() para crear un nuevo
socket para establecer una conexión.
A continuación editará un connect()
Protocolo TCP. Primitivas S
La primitiva socket() crea el socket y lleva asociados parámetros para determinar
el tipo de servicio (flujo de datos confiable), el protocolo (TCP), el formato de
direcciones (Internet).
Una vez creado el socket y asignados buffers de memoria para Tx y Rx, la
primitiva devuelve al AP un descriptor de socket para que se utilice luego en las
siguientes llamadas a primitivas.
A continuación la AP debe ligar el socket a una dirección, para eso se llama a la
primitiva bind() que lleva como parámetros el descriptor de socket y la dirección
del socket (dirección IP + Nº de port). Esta última es la dirección que la AP desea
asignar al socket que se acaba de crear. La llamada bind() devuelve un código de
error o éxito.
Para instruir al socket que atienda las llamadas entrantes se utiliza la llamada
listen() con parámetros descriptor de socket y longitud máxima de cola, permite
crear una cola para atender las solicitudes realizadas a la AP Servidora. Como la
anterior, devuelve un código de éxito o de error
Para aceptar llamadas entrantes, la primitiva accept() coloca a la AP Servidora en
modo bloqueado en espera de solicitudes provenientes de clientes TCP. Tiene
como parámetros el descriptor y la dirección del socket. Como la anterior,
devuelve un código de éxito o de error.
La secuencia socket(), bind(), listen() y acept() se conoce como apertura pasiva.
Protocolo TCP. Primitivas C
Por su parte el AP Cliente envía una primitiva socket() para crear un nuevo socket
para establecer una conexión. A continuación editará un connect() con
parámetros descriptor del socket, nº de puerto local, nº de puerto destino,
dirección IP destino, precedencia (TOS, se transfiere al protocolo IP), datos
opcionales (ejemplo nombre de usuario y contraseña). Luego de esta llamada la
AP pasa a estado bloqueado mientras que el protocolo TCP local inicia el
establecimiento de una conexión con el Servidor.
Las primitivas socket() y connect() constituyen una apertura activa.
Protocolo TCP. Primitivas C-S
Tanto el TCP Cliente como el Servidor pueden soportar múltiples conexiones al
mismo tiempo para distintos clientes.
Existe un registro de conexión que permite distinguir entre ellas.
El registro de conexión incluye un identificador (par de sockets), MSS, Nº de
Secuencia Inicial usado en cada sentido, Valor de precedencia, Tamaño de la
Ventana para Control de Flujo y variables de estado asociadas al funcionamiento
del propio protocolo.
Cuando la AP Servidora recibe la solicitud de una nueva conexión, se desbloquea
y crea una nueva instancia de sí misma por si tuviera que atender otras
conexiones. Esto se realiza con la primitiva fork() que crea un nuevo socket entre
la nueva instancia de AP y el protocolo TCP local. El proceso padre regresa al
estado bloqueado a la espera de nuevas solicitudes.
Recién en este punto las AP`s Cliente y Servidor pueden comenzar a intercambiar
datos en ambos sentidos con las primitivas send() y receive().
Protocolo TCP. Primitivas C-S
Cada socket se haya asociado a un buffer de Tx y otro de Rx. Generalmente
el buffer de Rx se utiliza para reordenar los datos antes de entregarlo a la AP
correspondiente. Send() coloca datos en el buffer de Tx del socket para que
la entidad local TCP los lea. Los parámetros incluyen descriptor del socket,
puntero al buffer que contiene el bloque de datos y su longitud en bytes (que
luego no tiene por qué volcarse en un único segmento).
Existe un parámetro asociado a la primitiva send(), denominado bit de push,
mediante el cual el AP local puede solicitar la entrega inmediata del bloque.
Existe también un bit de urgente que se utiliza en aplicaciones interactivas
(por ejemplo AP usuario abortando cálculo remoto) donde se envía el
comando urgente con el bit activado. El TCP local lo Tx junto con los datos
pendientes y detiene el envío de nuevos datos. El TCP remoto lo recibe e
interrumpe al AP que lee los datos marcados para actuar en consecuencia.
La primitiva close() o shutdown() se utilizan para liberar cada extremo de la
conexión: los registros de conexión se borran y la instancia creada por fork()
también.
Protocolo TCP. Header
Protocolo TCP. Header
Source Port /Destination Port: Nº puerto de 16 bits del proceso que origina/es
destinatario del segmento en el dispositivo fuente/destino. Si es Cliente será
efímero, si es Servidor será bien conocido.
El conjunto (Nº de puerto, Dirección IP) en cada extremo se denomina socket.
Un par de sockets identifican unívocamente una conexión TCP.
Sequence Number: Corresponde al número del primer byte de datos en el
segmento. Se refiere a la posición que ocupa en el stream de bytes original. Se
trata de un campo de 32 bits. En el mensaje original, de establecimiento de la
conexión (segmento SYN), el Nº de Secuencia lleva el ISN (Initial Sequence
Number) que corresponde al lado de la fuente de la conexión TCP. El primer byte
de datos llevará el Nº de Secuencia (ISN +1).
Acknowledgment Number: Cuando el bit de ACK está en 1, el segmento se
toma como un acknowledgment (aunque además puede transportar datos) y este
campo contiene el Nº de Secuencia que el generador del segmento está
esperando que le llegue desde el otro extremo. Es decir este número se
corresponde al número del último byte recibido bien más uno. Luego de
establecerse una conexión, el bit de ACK de cualquier segmento será 1 y el
número de ACK representará un campo importante para el seguimiento del flujo
de datos.
Protocolo TCP. Header
Como TCP provee un servicio full duplex a las aplicaciones, pueden existir
datos viajando en ambas direcciones de manera independiente. Esto significa que
cada extremo llevará su propio Nº de Secuencia de los segmentos que se han Tx
y de aquellos que se hayan Rx.
En el protocolo TCP original no había forma de reconocer segmentos de datos
específicos. De esta forma es posible que existan ACK`s duplicados, que se
asocian a situaciones donde los segmentos llegan fuera de orden.
Data Offset: Especifica la cantidad de palabras de 32 bits que conforman el
header TCP, es decir multiplicado por 4 dará la cantidad de bytes del header. Es
necesario pues TCP cuenta con un campo de opciones. La longitud mínima del
header es de 4 (20 bytes) y la máxima es de 15 (60 bytes). Existen 20 bytes de
header fijo, lo cual implica un máximo de 40 bytes para opciones.
Protocolo TCP. Header
El campo de flags o bits de control consta de las siguientes banderas:
URG: Cuando está en alto significa que se ha invocado una transferencia
prioritaria para los datos encapsulados. En este caso el valor del puntero urgente
tiene validez.
ACK: En alto implica que debe tomarse el segmento como un ACK e interpretar el
campo Ack Number como el Nº de Secuencia próximo que se espera recibir.
PSH: Cuando está en alto se solicita al protocolo TCP en Rx que se suba lo más
rápido posible estos datos a la Aplicación receptora.
RST: Se coloca en alto cuando el Tx encuentra un problema y desea resetear la
conexión.
SYN: Bit encendido indicando que se está en la fase inicial de la conexión, en la
que deben sincronizarse los Nº de Secuencia (ISN) para establecer la conexión.
FIN: Cuando está en alto indica el cierre de la conexión solicitado por cualquiera
de los extremos.
Protocolo TCP. Header
Existe una extensión de los protocolos IP y TCP, del año 2001, definida en la RFC
3168, conocida como Explicit Congestion Notification (ECN).
ECN permite la notificación end-to-end de una situación de congestión en la red,
para evitar la pérdida de paquetes. Se trata de un mecanismo opcional que sólo
se puede usar si ambos extremos de la conexión lo soportan y la red también.
Básicamente, un router que entienda ECN, en vez de descartar un paquete,
marcará su header para anunciar la situación de congestión. El que Rx el
paquete, avisará al que Tx, para que reduzca su velocidad de transmisión.
El soporte de ECN sobre TCP es mediante flags.
El flag Nonce Sum (NS), se usa a modo de protección contra el ocultamiento
accidental o malicioso de paquetes marcados por el TCP Tx.
Los flags ECN-Echo (ECE) y Congestion Window Reduced (CWR) se usan para
avisar al Tx una indicación de congestión y para reocnocer (ACK) que el aviso fue
recibido.
Protocolo TCP. Header
Window: Indica el número de bytes de datos que el que envía el segmento está
dispuesto a aceptar de una sola vez desde el otro extremo. Generalmente se
asocia al tamaño del buffer de Rx. Este valor es ventana de Rx en el que lo envía,
que se corresponde a la ventana de Tx del que lo Rx. Se interpreta como la
cantidad de bytes, especificando como el primero el que se escribe en el campo
Ack Number, que el Rx puede aceptar en este momento.
Checksum: Un campo de 16 bits para protección de integridad calculado sobre el
datagrama completo + una pseudo header especial.
Urgent Pointer: Usado en conjunto con el flag URG, contiene un offset positivo
que debe sumarse al Nº de Secuencia para indicar la posición del último byte de
datos urgentes.
Opciones: campo variable.
Datos: no hay en SYN. Puede no haber en FIN. Si no hay datos para Tx se puede
Tx ACK solamente.
TCP Pseudo Header
TCP Pseudo Header
El Checksum protege de errores, aunque viola la tradicional arquitectura
OSI:
Entrega incorrecta de segmentos por errores en la dirección destino.
Protocolo incorrecto.
Longitud de Segmento incorrecta.
Lo interesante es que se provee esta protección extra sin necesidad de
enviar los campos del pseudoheader.
La desventaja es que el cálculo lleva más tiempo y recursos, aunque hoy
día eso no resulta en un problema. Al momento de idear el protocolo las
líneas eran mucho más ruidosas y valía la pena el esfuerzo.
TCP Opciones
Las opciones contempladas en el RFC 793 son:
• No operation: Para que el header se pueda rellenar a múltiplos de 4
bytes en el campo de opciones.
• Maximum Segment Size
TCP Opciones
Protocolo TCP. Inicio de Conexión
Hemos dicho que TCP es un protocolo orientado a la conexión.
Antes de poder intercambiar datos es necesario levantar una conexión entre los
dispositivos que se desean comunicar.
El procedimiento se conoce como establecimiento de la conexión e implica el
intercambio de mensajes que hacen que el ambos dispositivos pasen de un
estado (CLOSED) a un estado de operación normal (ESTABLISHED).
Cliente y Servidor se contactan a través de estos mensajes. Este último no sabe
a cuál Cliente atenderá antes que se cumpla esta fase.
Se necesita sincronizar los Nºs de Secuencia entre extremos, esto es cada uno
debe hacer saber al otro su ISN.
Se podrían intercambiar otros parámetros interesantes en el inicio de la
conexión.
Protocolo TCP. Inicio de Conexión
En caso de que sí se
encuentre abierto el puerto, el
lado servidor respondería a la
petición SYN válida con un
paquete SYN/ACK.
Normalmente una de las aplicaciones abre un
socket sobre un puerto TCP y se queda en
estado de LISTEN (apertura pasiva-S).
El lado cliente de una conexión realiza una
apertura activa de un puerto enviando un
segmento SYN inicial al servidor como parte de
la negociación en tres pasos.
En el lado del servidor se comprueba si el puerto
está abierto, es decir, si existe algún proceso
escuchando en ese puerto. En caso de no
estarlo, se envía al cliente un paquete de
respuesta con el bit RST activado, lo que
significa el rechazo del intento de conexión.
Finalmente, el cliente debería responderle al servidor con un ACK, completando así
la negociación en tres pasos (SYN, SYN/ACK y ACK) y la fase de establecimiento de
conexión. Es interesante notar que existe un número de secuencia generado por
cada lado, ayudando de este modo a que no se puedan establecer conexiones
falseadas (spoof)
Protocolo TCP. Timeout en Inicio
• Muchas veces la conexión no puede ser establecida. Por ejemplo si el
Servidor está caído no habrá contestación. Esto se puede simular en una
LAN desconectando el cable de la máquina Servidora antes de editar el
comando telnet.
• Lo interesante de notar es cada cuánto tiempo el cliente TCP intenta
enviar un SYN para establecer la conexión y por cuánto tiempo insiste hasta
declarar la conexión como no posible. Estos tiempos los maneja el SO.
• MSS: La máxima cantidad de datos que TCP puede enviar al otro extremo.
El tamaño del datagrama IP es 40 bytes mayor que el MSS (20 del header IP
+ 20 del header TCP). ¿Qué valores de MSS observaremos comúnmente en
una LAN?
Protocolo TCP. Inicio de Conexión
• Existe un Timer de
timeout asociado con la
Tx del primer segmento
SYN,
es
decir
al
establecer la sesión TCP.
• Empieza el timeout
cuando se Tx el SYN. Su
valor es de 75 seg.
• Si no se Rx respuesta
dentro de ese tiempo, se
aborta la conexión.
Protocolo TCP. Fin de Conexión
Protocolo TCP. Fin de Conexión
Protocolo TCP. Inicio y Fin
TCP Half Close
TCP permite terminar a un extremo mientras aún se Rx datos. En este
caso la aplicación debe cerrar con shutdown, no con close
TCP. Diagrama de Transición de Estados
LISTEN
SYN_SENT
SYN_RCVD
ESTABLISHED
ESTABLISHED
TCP. Diagrama de Transición de Estados
Servidor
Cliente
TCP. Diagrama de Transición de Estados
active close FIN_WAIT_1
pasive close CLOSE_WAIT
FIN_WAIT_2
App close LAST_ACK
TIME_WAIT
Timer 2MSL
CLOSED
FIN N
ack N+1
TCP. Diagrama de Transición de Estados
FIN_WAIT_2: El estado tiene asociado un Timer (10 min 75 seg) cuyo propósito
es evitar que la conexión quede en este estado para siempre si el otro extremo
llegara a caer, ya que todavía no ha enviado el FIN de cierre.
TIME_WAIT: Se ha recibido el FIN pero se asocia al mismo un Timer puesto que
el extremo que entra en este estado ha enviado un ACK en respuesta al segmento
FIN recibido del otro extremo y no sabe si este ACK fue entregado de manera
exitosa. El otro extremo podría ReTx el segmento FIN y este segundo segmento
FIN podría retrasarse en la red.
Si se permitiera que la conexión pasara al estado de CLOSED directamente,
entonces otro par de procesos de aplicaciones podrían aparecer, abrir la misma
conexión y el segmento FIN retrasado de la encarnación previa de la conexión
terminaría la encarnación nueva.
El timeout en este caso se ajusta a 2MSL (Maximum Segment Lifetime). Los
valores de implementación comunes de MSL son 30 seg,1 min ó 2 min.
TCP. Diagrama de Transición de Estados
TCP. Encarnaciones
En el estado TIME_WAIT se dispara un clock 2MSL. MSL significa
Maximum Segment Life.
La vida máxima de un segmento encapsulado en IP queda limitada por el
TTL. La RFC 793 fija el MSL en 2´.
El clock asegura la ReTx si se pierde el último ACK, pues el otro extremo
hará timeout y Retransmitirá el FIN.
Tampoco puede re-usarse el par de sockets durante este tiempo. De esta
forma se asegura que una nueva conexión usará otro par de sockets. Se
denominan encarnaciones a nuevas instancias de una conexión (usa el
mismo par de sockets).
El timer 2MSL asegura que segmentos retrasados de una encarnación
anterior de esta conexión no puedan ser malinterpretados como
pertenecientes a la actual por que si aparecen estos segmentos, los mismos
se descartan.
Problema de FIN_WAIT_2: El C ha Tx FIN y Rx Ack ¿Qué pasa si la
Aplicación Servidor no cierra? Podemos quedarnos esperando toda la
vida… Por este motivo muchas implementaciones setean un timer y pasan a
CLOSED cuando el mismo se agota (10 min 75 seg).
TCP. Flag de Push
Mientras que las aplicaciones manejan la velocidad y el momento con que
envían datos a TCP, no pueden controlar ni la velocidad ni el tiempo con
que TCP los envía a la red.
En el caso de Tx grandes archivos esto no sería un problema mientras TCP
acumule los datos en buffer y los vaya Tx a medida que la red ¨lo permita¨.
En el caso de una aplicación interactiva, no se desea que TCP acumule
los datos, sino que los Tx de inmediato pues de este modo la interactividad
sí tiene sentido.
En otras aplicaciones tipo Cliente Servidor se precisa lo mismo.
Para manejar esas situaciones se incluyó el flag de PUSH.
Cuando se invoca esta funcionalidad, TCP creará un segmento o varios que
contenga los datos en espera y los transmitirá con el flag de PUSH en alto.
Los límites de los mensajes quedan aún en manos de las aplicaciones.
En la práctica se suele encender el flag de PUSH cuando se vacía el buffer
de Tx.
Flag URG.
Para usarlo al Tx, el proceso que necesita enviar datos urgente habilita la
función y Tx los datos al módulo TCP. Este crea un segmento especial con
el flag de URG en 1.
También coloca en el Urgent Pointer un offset que apunta al último byte de
datos urgentes. Por ejemplo, si el segmento contiene 400 bytes de datos
urgentes seguidos de 200 bytes de datos comunes, el puntero se ajustará
en 400, que se empiezan a contar a partir del Nº de Secuencia.
Al Rx un segmento con el flag URG en 1, se analiza el Urgent Pointer y así
se determina la ubicación de los datos urgentes para entregárselos al
proceso con la indicación de que los datos fueron marcados como URG por
el Tx. El resto de los datos del segmento se procesa normalmente.
De este modo se sobrepasa sobre cualquier otro dato de menor prioridad
que ya haya sido puesto en cola para su Tx.
TCP. Segmento con Flag Reset
Lo edita un host cuando llega un pedido de conexión a un port que no tiene
un Servidor en LISTEN.
¿Qué pasaría si la comunicación se hace sobre UDP?
Una liberación abortiva se termina con RST. Una liberación ordenada con
FIN.
TCP. Segmento con Flag Reset
Lo edita un host cuando llega un pedido de conexión a un port que no tiene
un Servidor en LISTEN.
¿Qué pasaría si la comunicación se hace sobre UDP?
Una liberación abortiva se termina con RST. Una liberación ordenada con
FIN.
TCP. Conexiones Half Open
Si un extremo cae, el otro puede no enterarse.
Puede ser un problema distraer recursos en mantener conexiones que en
realidad no existen. Opción keepalive.
Ejemplo:
a) Conectar un C telnet a un S al port discard.
b) Desconectar el cable del S y reboot (simulando su caída).
c) Conectar el cable y tratar de Tx datos desde el C.
d) Observar protocolos involucrados.
TCP. Diseño de Servidores
Servidores Concurrentes: Cuando se acepta una conexión, se invoca un
nuevo proceso para el manejo del C. (fork o threads).
Se puede observar con netstat lo que sucede con el port del lado S.
Si no hay conexión: LISTEN. Cuando hay conexión: LISTEN (una línea),
ESTABLISHED (por cada cliente).
Observar los pares de sockets desde el mismo C.
¿Qué pasa si llegan nuevos requerimientos mientras el S está creando un
nuevo proceso o el SO está atendiendo otras prioridades?. Existe una cola de
longitud fija de conexiones que han sido aceptadas por TCP (3-way completo)
pero todavía la App no las ha aceptado. La App especifica un límite a dicha
cola, se conoce con el nombre de backlog. Antes de aceptar una nueva
conexión, TCP debe consultar este valor de backlog. Si hay lugar, la acepta.
Sino, ignora el SYN y, si la cola se vacía por que el S la atiende, TCP podría
aceptar la conexión más tarde.
Esto no afecta el número total de conexiones establecidas permitidas.
Puede suceder que TCP acepte conexiones que la App no desee. En este
caso la App puede rechazar por FIN o RST.
Bibliografía
TCP/IP Illustrated, Volumen 1 The protocols
W. Richard Stevens
Chapter 17, Chapter 18