UDPUDPUDPUDP----TCPTCPTCPTCP

Protocolo UDP User Datagram Protocol

UDP es un protocolo de transporte estndar que se define en la RFC 768 - "UserDatagram Protocol. Campo IP Protocol: 17. Toda implementacin TCP/IP que no se use exclusivamente para ruteo incluyeUDP. Para IP, UDP es bsicamente una interfaz de aplicacin. No aade fiabilidad,control de flujo o recuperacin de errores a IP. Simplemente sirve comocontrol de flujo o recuperacin de errores a IP. Simplemente sirve como"multiplexor/ demultiplexor" para enviar y recibir datagramas, usando los puertospara dirigir los datagramas. UDP suministra un mecanismo para que una aplicacin enve un datagrama aotra. Se considera que la capa de UDP es muy sencilla y en consecuencia tienepoco "overhead", pero requiere que la aplicacin se responsabilice de larecuperacin de errores y dems cuestiones que hagan a la confiabilidad en la Tx. Las aplicaciones que envan datagramas a un host necesitan identificar unobjetivo ms especfico que la direccin IP, ya que los datagramas suelen dirigirsea procesos concretos y no a todo el sistema. UDP permite hacer esto al hacer usode los puertos. Concepto de socket.

Ports TCP/UDP Un puerto es un nmero de 16 bits que identifica en un host el proceso que estasociado a un datagrama. Existen dos tipos de puertos: Puertos Bien-conocidos("well-known"): Identifican a los servidores estndar, porejemplo Telnet usa el puerto 23. Los puertos bien-conocidos se hallan en el rango de 1a 1023. La mayora de los servidores requieren slo un nico puerto. Una excepcines el servidor BOOTP que usa dos: el 67 y el 68 para Cliente y Servidor. La razn deser de los puertos bien-conocidos es permitir a los clientes encontrar a los servidoressin necesidad de informacin de configuracin. Los nmeros de los puertos bien-conocidos se definen en STD 2 - Nmeros asignados de Internet("Assigned Internetconocidos se definen en STD 2 - Nmeros asignados de Internet("Assigned InternetNumbers"). Puertos Efmeros: Los clientes no necesitan puertos bien-conocidos porque inician lacomunicacin con los servidores y los datagramas UDP enviados al servidor contienensu nmero de puerto. El host en funcionamiento proporciona un puerto a cada procesocliente mientras este lo necesite. Los nmeros de puertos efmeros tienen valoresmayores de 1023, por lo general en el rango de 1024 a 5000. Un cliente puede usarcualquier nmero en ese rango, siempre que la combinacin sea unvoca . El esquema se sostiene para TCP, aunque sus puertos son totalmenteindependientes de los de UDP. Normalmente, un servidor usar TCP o UDP, aunquehay excepciones. Por ejemplo, el DNS usa tanto el puerto 53 de UDP como el 53 deTCP.

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 nmero se obtendr una breve explicacin de laaplicacin referenciada.

Algunas aplicaciones pueden funcionar sobre UDP o TCP con el mismo nmerode puerto.de puerto.

Existen puertos bien conocidos por encima de 1023, por ejemplo el puerto 8080queda reservado como puerto alternativo para un servidor web Apache.

Existen programas que permiten determinar cules puertos se encuentranabiertos (en estado LISTEN, preparados para recibir requerimientos) en unamquina y lo hacen a travs de una red. El sentido puede deberse al montaje deun ataque: una vez descubiertos los puertos abiertos, se pueden buscarvulnerabilidades para atacar la mquina objetivo.

Protocolo UDP

Cada datagrama UDP se enva encapsulado en un slo datagrama de IP. Aunque eldatagrama IP se fragmente durante la transmisin, la implementacin de IP que loreciba lo reensamblar antes de pasrselo a la capa de UDP. Todas las implementaciones de IP deben aceptar datagramas de 576 bytes, lo quesignifica que si se supone un tamao mximo de 60 bytes para la cabecera IP, quedaun tamao de 516 bytes para el datagrama UDP, aceptado por todas lasimplementaciones. Muchas implementaciones aceptan datagramas ms grandes, perono es algo que est garantizado.no es algo que est garantizado. El datagrama UDP tiene una cabecera de 8 bytes:Puerto origen: puerto del proceso que enva 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 lasuma en complemento a uno de una pseudocabecera IP, la cabecera UDP y los datosdel datagrama UDP. La pseudocabecera IP contiene las direcciones IP de origen ydestino, 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:Creacin de nuevos puertos para la recepcin.Operacin de recepcin que devuelve los bytes de datos recibidos y una indicacin delpuerto y la direccin IP de origen.Operacin de envo que tiene como parmetros los datos, los puertos de origen ydestino y las direcciones IP. La forma en que se implementa esto queda a eleccin del cada distribuidor. Recordar que IP y UDP no proporcionan una entrega garantizada, control de flujo ni Recordar que IP y UDP no proporcionan una entrega garantizada, control de flujo nirecuperacin de errores, as que estos debern ser implementados por la aplicacin.Aplicaciones estndar 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 darconfiabilidad a la Tx.

Streaming media: Requiere poseer velocidad de CPU y BW suficiente para soportarlas velocidades requeridas. Tambin exige crear caminos de baja latencia en el SOpara evitar el buffer underrun (buffer llenndose de datos a menor velocidad quecuando se vaca al ser ledo). Por ejemplo radios en Internet. UDP + protocolos QoSReal-time multiplayer games Adaptable UDP / TCPReal-time multiplayer games Adaptable UDP / TCP VoIP: Emplean protocolos de sesin para controlar la conexin y desconexin deuna 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 angostoy otras soportan estreo 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: deconmutacin de circuitos, de conmutacin de paquetes, orientado a la conexin,sin conexin. Cada tipo de red lleva asociado una serie de protocolos, pero porencima de la capa de red existen los llamados protocolos de aplicacin y otrosque le dan soporte.

Los protocolos de capa de transporte ocultan a las aplicaciones los servicios Los protocolos de capa de transporte ocultan a las aplicaciones los serviciosproporcionados por las capas de red, proporcionando servicios independientes delos 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 conexin.UDP proporciona un servicio sin conexin. Utilizar uno u otro depende de losrequisitos de la aplicacin en cuestin.

Protocolo TCP TCP y UDP corren como procesos / aplicaciones dentro del ncleo del SO o a

veces como paquetes de libreras enlazados a la aplicacin. La mayora 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 conexin no confiable, vlido para aquellas

aplicaciones para los cuales resulta aceptable. Utilizar uno u otro depende de los requisitos de la aplicacin en cuestin. De

todas maneras la comunicacin es end-to-end.todas maneras la comunicacin es end-to-end.

Debe haber una forma en que ambos protocolos, TCP y UDP, distingan lasdiversas aplicaciones que sobre ellos se apoyan. Esta funcionalidad se expresaen un campo de la cabecera de ambos que consiste en los nmeros de puerto,tanto fuente como destino.

En general, del lado de la aplicacin Cliente, el nmero de puerto tiene unsignificado local, asignndose un nuevo nmero cada vez que un Cliente solicitauna transferencia. A estos nmeros de puerto clientes se los denomina, por ello,puertos efmeros. Normalmente van del 1024 al 5000.

Los nmeros de puerto de los Servidores, por el contrario, son fijos y sedenominan puertos bien conocidos. Normalmente van del 1 al 1023 (por ejemploFTP 21)

Protocolo TCP

TCP ofrece un servicio bidireccional para transferencia de datos confiable. Los datos en TCP se transmiten en segmentos cuyo tamao depende de la MTU

(Maximum Transmission Unit) (MSS, Maximum Segment Size). Cada vez queTCP transmite un segmento inicia un timer y se espera un ACK del otro extremo.Si no lo recibe, inicia una retransmisin. Se denomina a esta estrategia detimeout y retransmisin. 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. Sien recepcin se perciben errores, se descarta el segmento y no se transmite ACK.en recepcin se perciben errores, se descarta el segmento y no se transmite ACK.

Para contrarrestar la posible llegada de segmentos fuera de orden, TCP debecontar con alguna informacin extra para reordenamiento.

TCP adems debe ser capaz de descartar duplicados (por prdida de ACK yretransmisin).

Un mecanismo de control de flujo permite acomodar diferencias entre tamaos debuffer y velocidad entre los extremos en comunicacin.

A pesar que las aplicaciones poseen estructuras definidas, la misma estransparente al protocolo TCP, cuyos extremos de comunicacin tratan el flujo dedatos como un flujo de bytes. Se referencia a esta propiedad como orientado alstream de bytes.

Se incluye un mecanismo de control de congestin.

Protocolo TCP - SOCKETS Sockets permite la comunicacin entre dos procesos diferentes en la misma o en

diferentes mquinas. S trata de una forma de comunicacin entre computadoras que utiliza el concepto

de file descriptors de Unix. En Unix toda accin del tipo I/O se realiza leyendo oescribiendo un file descriptor. El file descriptor es un entero asociado con unarchivo abierto que puede ser una conexin de red, un archivo de texto o unterminal.

Para un programador se trata de un concepto de bajo nivel ya que los comandosdel tipo read() y write() funcionan con sockets de la misma manera que lo hacencon archivos o pipes. La diferencia entre sockets y los file descriptors normales secon archivos o pipes. La diferencia entre sockets y los file descriptors normales seestablece en la creacin del socket y en la incorporacin de operacionesespeciales para control del socket.

Un Socket de Unix se usa en aplicaciones C-S. La mayora de las aplicacionestipo FTP, SMTP, POP3, etc. usan Sockets para establecer conexin entre C y S.

Existen 4 tipos de Sockets pero slo 2 son los ms usados. Se supone que losprocesos se comunican slo entre sockets del mismo tipo.

Stream Sockets: Entrega en red garantizada y en orden. Se usa TCP para Txdatos. Si la entrega no es posibe, el Tx recibe un indicador de error. Los registrosde datos no tienen lmites.

Datagram Sockets: Entrega en red no garantizada. Son sin conexin, seconstruye un paquete y sencillamente se Tx. Usan UDP.

Protocolo TCP. Tipos de S y C Iterative Server: Es el ms sencillo. Se atiende un C por vez. Luego de completar

un requerimiento se atiende otro C. El segundo C debe esperar que el S sedesocupe.

Concurrent Servers: Este tipo permite correr mltiples procesos y servir variosrequerimientos a la vez. La forma ms sencilla de hacerlo en Unix es por mediode fork que abre un proceso child para manejar cada C por separado.

Las llamadas al sistema para establecer una conexin son diferentes para C ypara S, pero ambas incluyen la construccin bsica de un socket. Ambosprocesos establecen sus propios sockets.Del lado Cliente, se crea un socket con la llamada al sistema socket(). Se conecta Del lado Cliente, se crea un socket con la llamada al sistema socket(). Se conectael socket a la direccin del S con la llamada al sistema connect(). Se Tx y Rxdatos con las llamadas al sistema read() y write().

Del lado Server se crea un socket con la llamada al sistema socket(). Se asocia elsocket a una direccin con la llamada al sistema bind(). En Internet un socket deS tiene una direccin que consiste en un nmero de puerto en la mquina host.Se escuchan conexiones con la llamada al sistema listen(). Se aceptanconexiones con accept(). Esta llamada tpicamente se bloquea hasta que un C seconecta 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 alSO que constituyen un API(Application Program Interface) para lapila TCP/IP que subyace.

Los procesos de aplicacin de usuario(AP`s) que se comunicarn, primerocrean un canal de comunicacin entreel AP propiamente dicho y la entidadlocal TCP. Este canal se denominalocal TCP. Este canal se denominasocket o punto terminal.

Si se trata de una AP tipo Servidor,esta enviar una secuencia dellamadas a primitivas : socket(), bind(),listen(), accept(). Cada llamada llevaasociado un conjunto de parmetros,un valor o ms de salida y un cdigode error.

Por su parte el AP Cliente enva unaprimitiva socket() para crear un nuevosocket para establecer una conexin.A continuacin editar un connect()

Protocolo TCP. Primitivas S La primitiva socket() crea el socket y lleva asociados parmetros 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 continuacin la AP debe ligar el socket a una direccin, para eso se llama a la primitiva bind() que lleva como parmetros el descriptor de socket y la direccin primitiva bind() que lleva como parmetros el descriptor de socket y la direccin del socket (direccin IP + N de port). Esta ltima es la direccin que la AP desea asignar al socket que se acaba de crear. La llamada bind() devuelve un cdigo de error o xito.

Para instruir al socket que atienda las llamadas entrantes se utiliza la llamada listen() con parmetros descriptor de socket y longitud mxima de cola, permite crear una cola para atender las solicitudes realizadas a la AP Servidora. Como la anterior, devuelve un cdigo 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 parmetros el descriptor y la direccin del socket. Como la anterior, devuelve un cdigo 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 enva una primitiva socket() para crear un nuevo socketpara establecer una conexin. A continuacin editar un connect() conparmetros descriptor del socket, n de puerto local, n de puerto destino,direccin IP destino, precedencia (TOS, se transfiere al protocolo IP), datosopcionales (ejemplo nombre de usuario y contrasea). Luego de esta llamada laAP pasa a estado bloqueado mientras que el protocolo TCP local inicia elestablecimiento de una conexin con el Servidor.establecimiento de una conexin 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 mltiples conexiones al

mismo tiempo para distintos clientes. Existe un registro de conexin que permite distinguir entre ellas.

El registro de conexin incluye un identificador (par de sockets), MSS, N deSecuencia Inicial usado en cada sentido, Valor de precedencia, Tamao de laVentana para Control de Flujo y variables de estado asociadas al funcionamientoVentana para Control de Flujo y variables de estado asociadas al funcionamientodel propio protocolo.

Cuando la AP Servidora recibe la solicitud de una nueva conexin, se desbloqueay crea una nueva instancia de s misma por si tuviera que atender otrasconexiones. Esto se realiza con la primitiva fork() que crea un nuevo socket entrela nueva instancia de AP y el protocolo TCP local. El proceso padre regresa alestado bloqueado a la espera de nuevas solicitudes.

Recin en este punto las AP`s Cliente y Servidor pueden comenzar a intercambiardatos 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. Generalmenteel buffer de Rx se utiliza para reordenar los datos antes de entregarlo a la APcorrespondiente. Send() coloca datos en el buffer de Tx del socket para quela entidad local TCP los lea. Los parmetros incluyen descriptor del socket,puntero al buffer que contiene el bloque de datos y su longitud en bytes (queluego no tiene por qu volcarse en un nico segmento).

Existe un parmetro asociado a la primitiva send(), denominado bit de push,mediante el cual el AP local puede solicitar la entrega inmediata del bloque.Existe tambin un bit de urgente que se utiliza en aplicaciones interactivas(por ejemplo AP usuario abortando clculo remoto) donde se enva elcomando urgente con el bit activado. El TCP local lo Tx junto con los datospendientes y detiene el envo de nuevos datos. El TCP remoto lo recibe einterrumpe al AP que lee los datos marcados para actuar en consecuencia.

La primitiva close() o shutdown() se utilizan para liberar cada extremo de laconexin: los registros de conexin se borran y la instancia creada por fork()tambin.

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 serefmero, si es Servidor ser bien conocido.

El conjunto (N de puerto, Direccin IP) en cada extremo se denomina socket. Un par de sockets identifican unvocamente una conexin TCP. Sequence Number: Corresponde al nmero del primer byte de datos en el

segmento. Se refiere a la posicin que ocupa en el stream de bytes original. Setrata de un campo de 32 bits. En el mensaje original, de establecimiento de latrata de un campo de 32 bits. En el mensaje original, de establecimiento de laconexin (segmento SYN), el N de Secuencia lleva el ISN (Initial SequenceNumber) que corresponde al lado de la fuente de la conexin TCP. El primer bytede datos llevar el N de Secuencia (ISN +1).

Acknowledgment Number: Cuando el bit de ACK est en 1, el segmento setoma como un acknowledgment (aunque adems puede transportar datos) y estecampo contiene el N de Secuencia que el generador del segmento estesperando que le llegue desde el otro extremo. Es decir este nmero secorresponde al nmero del ltimo byte recibido bien ms uno. Luego deestablecerse una conexin, el bit de ACK de cualquier segmento ser 1 y elnmero de ACK representar un campo importante para el seguimiento del flujode 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 quecada extremo llevar su propio N de Secuencia de los segmentos que se han Txy de aquellos que se hayan Rx.

En el protocolo TCP original no haba forma de reconocer segmentos de datosespecficos. De esta forma es posible que existan ACK`s duplicados, que seespecficos. De esta forma es posible que existan ACK`s duplicados, que seasocian a situaciones donde los segmentos llegan fuera de orden.

Data Offset: Especifica la cantidad de palabras de 32 bits que conforman elheader TCP, es decir multiplicado por 4 dar la cantidad de bytes del header. Esnecesario pues TCP cuenta con un campo de opciones. La longitud mnima delheader es de 4 (20 bytes) y la mxima es de 15 (60 bytes). Existen 20 bytes deheader fijo, lo cual implica un mximo 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 transferenciaprioritaria para los datos encapsulados. En este caso el valor del puntero urgentetiene validez.ACK: En alto implica que debe tomarse el segmento como un ACK e interpretar el ACK: En alto implica que debe tomarse el segmento como un ACK e interpretar elcampo Ack Number como el N de Secuencia prximo que se espera recibir.

PSH: Cuando est en alto se solicita al protocolo TCP en Rx que se suba lo msrpido posible estos datos a la Aplicacin receptora.

RST: Se coloca en alto cuando el Tx encuentra un problema y desea resetear laconexin.

SYN: Bit encendido indicando que se est en la fase inicial de la conexin, en laque deben sincronizarse los N de Secuencia (ISN) para establecer la conexin.

FIN: Cuando est en alto indica el cierre de la conexin solicitado por cualquierade los extremos.

Protocolo TCP. Header Existe una extensin de los protocolos IP y TCP, del ao 2001, definida en la RFC

3168, conocida como Explicit Congestion Notification (ECN). ECN permite la notificacin end-to-end de una situacin de congestin en la red,

para evitar la prdida de paquetes. Se trata de un mecanismo opcional que slose puede usar si ambos extremos de la conexin lo soportan y la red tambin.

Bsicamente, un router que entienda ECN, en vez de descartar un paquete,marcar su header para anunciar la situacin de congestin. El que Rx elmarcar su header para anunciar la situacin de congestin. El que Rx elpaquete, avisar al que Tx, para que reduzca su velocidad de transmisin.

El soporte de ECN sobre TCP es mediante flags. El flag Nonce Sum (NS), se usa a modo de proteccin 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 indicacin de congestin y para reocnocer (ACK) que el aviso fuerecibido.

Protocolo TCP. Header Window: Indica el nmero de bytes de datos que el que enva el segmento est

dispuesto a aceptar de una sola vez desde el otro extremo. Generalmente seasocia al tamao del buffer de Rx. Este valor es ventana de Rx en el que lo enva,que se corresponde a la ventana de Tx del que lo Rx. Se interpreta como lacantidad de bytes, especificando como el primero el que se escribe en el campoAck Number, que el Rx puede aceptar en este momento.

Checksum: Un campo de 16 bits para proteccin de integridad calculado sobre el Checksum: Un campo de 16 bits para proteccin de integridad calculado sobre eldatagrama completo + una pseudo header especial.

Urgent Pointer: Usado en conjunto con el flag URG, contiene un offset positivoque debe sumarse al N de Secuencia para indicar la posicin del ltimo byte dedatos 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 direccin destino. Protocolo incorrecto.

Longitud de Segmento incorrecta. Longitud de Segmento incorrecta. Lo interesante es que se provee esta proteccin extra sin necesidad de

enviar los campos del pseudoheader. La desventaja es que el clculo lleva ms tiempo y recursos, aunque hoy

da eso no resulta en un problema. Al momento de idear el protocolo las lneas eran mucho ms ruidosas y vala la pena el esfuerzo.

TCP OpcionesLas opciones contempladas en el RFC 793 son:

No operation: Para que el header se pueda rellenar a mltiplos de 4 bytes en el campo de opciones.

Maximum Segment Size

TCP Opciones

Protocolo TCP. Inicio de Conexin Hemos dicho que TCP es un protocolo orientado a la conexin.

Antes de poder intercambiar datos es necesario levantar una conexin entre losdispositivos que se desean comunicar.

El procedimiento se conoce como establecimiento de la conexin e implica elintercambio de mensajes que hacen que el ambos dispositivos pasen de unintercambio de mensajes que hacen que el ambos dispositivos pasen de unestado (CLOSED) a un estado de operacin normal (ESTABLISHED).

Cliente y Servidor se contactan a travs de estos mensajes. Este ltimo no sabea cul Cliente atender antes que se cumpla esta fase.

Se necesita sincronizar los Ns de Secuencia entre extremos, esto es cada unodebe hacer saber al otro su ISN.

Se podran intercambiar otros parmetros interesantes en el inicio de laconexin.

Protocolo TCP. Inicio de ConexinNormalmente una de las aplicaciones abre unsocket sobre un puerto TCP y se queda enestado de LISTEN (apertura pasiva-S).El lado cliente de una conexin realiza unaapertura activa de un puerto enviando unsegmento SYN inicial al servidor como parte dela negociacin en tres pasos.En el lado del servidor se comprueba si el puertoest abierto, es decir, si existe algn procesoest abierto, es decir, si existe algn procesoescuchando en ese puerto. En caso de noestarlo, se enva al cliente un paquete derespuesta con el bit RST activado, lo quesignifica el rechazo del intento de conexin.

En caso de que s seencuentre abierto el puerto, ellado servidor respondera a lapeticin SYN vlida con unpaquete SYN/ACK.

Finalmente, el cliente debera responderle al servidor con un ACK, completando asla negociacin en tres pasos (SYN, SYN/ACK y ACK) y la fase de establecimiento deconexin. Es interesante notar que existe un nmero de secuencia generado porcada lado, ayudando de este modo a que no se puedan establecer conexionesfalseadas (spoof)

Protocolo TCP. Timeout en Inicio Muchas veces la conexin no puede ser establecida. Por ejemplo si elServidor est cado no habr contestacin. Esto se puede simular en unaLAN desconectando el cable de la mquina Servidora antes de editar elcomando telnet. Lo interesante de notar es cada cunto tiempo el cliente TCP intentaenviar un SYN para establecer la conexin y por cunto tiempo insiste hastadeclarar la conexin como no posible. Estos tiempos los maneja el SO.

MSS: La mxima cantidad de datos que TCP puede enviar al otro extremo.El tamao del datagrama IP es 40 bytes mayor que el MSS (20 del header IP+ 20 del header TCP). Qu valores de MSS observaremos comnmente enuna LAN?

Protocolo TCP. Inicio de Conexin

Existe un Timer detimeout asociado con laTx del primer segmentoSYN, es decir alestablecer la sesin TCP.establecer la sesin TCP. Empieza el timeoutcuando se Tx el SYN. Suvalor es de 75 seg. Si no se Rx respuestadentro de ese tiempo, seaborta la conexin.

Protocolo TCP. Fin de Conexin

Protocolo TCP. Fin de Conexin

Protocolo TCP. Inicio y Fin

TCP Half Close

TCP permite terminar a un extremo mientras an se Rx datos. En este caso la aplicacin debe cerrar con shutdown, no con close

TCP. Diagrama de Transicin de Estados

SYN_SENTSYN_RCVD

LISTEN

SYN_SENTSYN_RCVD

ESTABLISHEDESTABLISHED

TCP. Diagrama de Transicin de Estados

ServidorCliente

TCP. Diagrama de Transicin de Estados

active close FIN_WAIT_1pasive close CLOSE_WAIT

FIN_WAIT_2 App close LAST_ACKTIME_WAIT

CLOSED

Timer 2MSL

FIN N

ack N+1

TCP. Diagrama de Transicin de EstadosFIN_WAIT_2: El estado tiene asociado un Timer (10 min 75 seg) cuyo propsitoes evitar que la conexin quede en este estado para siempre si el otro extremollegara a caer, ya que todava no ha enviado el FIN de cierre.

TIME_WAIT: Se ha recibido el FIN pero se asocia al mismo un Timer puesto queel extremo que entra en este estado ha enviado un ACK en respuesta al segmentoFIN recibido del otro extremo y no sabe si este ACK fue entregado de maneraexitosa. El otro extremo podra ReTx el segmento FIN y este segundo segmentoexitosa. El otro extremo podra ReTx el segmento FIN y este segundo segmentoFIN podra retrasarse en la red.Si se permitiera que la conexin pasara al estado de CLOSED directamente,entonces otro par de procesos de aplicaciones podran aparecer, abrir la mismaconexin y el segmento FIN retrasado de la encarnacin previa de la conexinterminara la encarnacin nueva.El timeout en este caso se ajusta a 2MSL (Maximum Segment Lifetime). Losvalores de implementacin comunes de MSL son 30 seg,1 min 2 min.

TCP. Diagrama de Transicin de Estados

TCP. Encarnaciones En el estado TIME_WAIT se dispara un clock 2MSL. MSL significa

Maximum Segment Life.

La vida mxima de un segmento encapsulado en IP queda limitada por elTTL. La RFC 793 fija el MSL en 2.

El clock asegura la ReTx si se pierde el ltimo ACK, pues el otro extremohar timeout y Retransmitir el FIN.

Tampoco puede re-usarse el par de sockets durante este tiempo. De estaforma se asegura que una nueva conexin usar otro par de sockets. Sedenominan encarnaciones a nuevas instancias de una conexin (usa elmismo par de sockets).

El timer 2MSL asegura que segmentos retrasados de una encarnacinanterior de esta conexin no puedan ser malinterpretados comopertenecientes a la actual por que si aparecen estos segmentos, los mismosse descartan.

Problema de FIN_WAIT_2: El C ha Tx FIN y Rx Ack Qu pasa si laAplicacin Servidor no cierra? Podemos quedarnos esperando toda lavida Por este motivo muchas implementaciones setean un timer y pasan aCLOSED 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

envan datos a TCP, no pueden controlar ni la velocidad ni el tiempo conque TCP los enva a la red.

En el caso de Tx grandes archivos esto no sera un problema mientras TCPacumule los datos en buffer y los vaya Tx a medida que la red lo permita.

En el caso de una aplicacin interactiva, no se desea que TCP acumulelos datos, sino que los Tx de inmediato pues de este modo la interactividads 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 quecontenga los datos en espera y los transmitir con el flag de PUSH en alto.

Los lmites de los mensajes quedan an en manos de las aplicaciones.

En la prctica se suele encender el flag de PUSH cuando se vaca el bufferde Tx.

Flag URG. Para usarlo al Tx, el proceso que necesita enviar datos urgente habilita la

funcin y Tx los datos al mdulo TCP. Este crea un segmento especial conel flag de URG en 1.

Tambin coloca en el Urgent Pointer un offset que apunta al ltimo byte dedatos urgentes. Por ejemplo, si el segmento contiene 400 bytes de datosurgentes seguidos de 200 bytes de datos comunes, el puntero se ajustaren 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 asse determina la ubicacin de los datos urgentes para entregrselos alse determina la ubicacin de los datos urgentes para entregrselos alproceso con la indicacin de que los datos fueron marcados como URG porel Tx. El resto de los datos del segmento se procesa normalmente.

De este modo se sobrepasa sobre cualquier otro dato de menor prioridadque ya haya sido puesto en cola para su Tx.

TCP. Segmento con Flag Reset Lo edita un host cuando llega un pedido de conexin a un port que no tiene

un Servidor en LISTEN. Qu pasara si la comunicacin se hace sobre UDP? Una liberacin abortiva se termina con RST. Una liberacin ordenada con

FIN.

TCP. Segmento con Flag Reset Lo edita un host cuando llega un pedido de conexin a un port que no tiene

un Servidor en LISTEN. Qu pasara si la comunicacin se hace sobre UDP? Una liberacin abortiva se termina con RST. Una liberacin 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. Opcin keepalive. Ejemplo: a) Conectar un C telnet a un S al port discard.b) Desconectar el cable del S y reboot (simulando su cada).c) Conectar el cable y tratar de Tx datos desde el C.d) Observar protocolos involucrados.

TCP. Diseo de Servidores Servidores Concurrentes: Cuando se acepta una conexin, 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 conexin: LISTEN. Cuando hay conexin: LISTEN (una lnea),ESTABLISHED (por cada cliente).

Observar los pares de sockets desde el mismo C.

Qu pasa si llegan nuevos requerimientos mientras el S est creando unnuevo proceso o el SO est atendiendo otras prioridades?. Existe una cola delongitud fija de conexiones que han sido aceptadas por TCP (3-way completo)pero todava la App no las ha aceptado. La App especifica un lmite a dichacola, se conoce con el nombre de backlog. Antes de aceptar una nuevaconexin, TCP debe consultar este valor de backlog. Si hay lugar, la acepta.Sino, ignora el SYN y, si la cola se vaca por que el S la atiende, TCP podraaceptar la conexin ms tarde.

Esto no afecta el nmero 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.

Bibliografa TCP/IP Illustrated, Volumen 1 The protocolsW. Richard StevensChapter 17, Chapter 18