viernes, 25 de noviembre de 2016

TCP/IP (5): TCP en profundidad


Entradas de la serie -> TCP/IP
ELEMENTOS DE LA CABECERA TCP

El campo de código de operación

En la cabecera, un conjunto de seis bits llamado code bits, indica el tipo de operación que realiza el segmento:
  • URG: Contiene datos urgentes (acelerados), debiendo atenderse al puntero de urgencia que contiene la cabecera.
  • ACK: Contiene asentimientos, debiendo atenderse al campo correspondiente.
  • PSH: Solicitud de operación push (volcado del buffer)
  • RST: Iniciación de la conexión
  • SYN: Sincronización de números de secuencia
  • FIN: Final del flujo de octetos

Datos urgentes o acelerados

Los datos urgentes, también llamados a veces fuera de banda, son aquellos que el programa destino debe atender aún sin haber consumido los octetos que ya están en el flujo (por ejemplo, la solicitud de interrupción de un programa).

El emisor activa el bit URG de la cabecera, e indica el lugar donde se envían los datos urgentes mediante un campo aparte. El software del receptor, al recibir este tipo de segmento, debe interrumpir al programa de usuario y ponerlo en modo urgente.

Tamaño máximo de segmento

Los dos extremos han de ponerse de acuerdo en el tamaño máximo de segmento (MMS) a utilizar. Para ello se usan los campos de opciones de la cabecera.

Si ambas máquinas residen en la misma red, se intentará usar el tamaño que se ajuste a los paquetes de esa red física, mientras que en máquinas de distintas redes se intentará computar la mínima MTU de las redes que hay que atravesar.

Por defecto se escoge un tamaño de 536 octetos, que es el resultado de restarle los encabezados al tamaño por defecto de los datagramas IP (576).

La elección de el MMS es difícil en un entorno de red de redes, resultando crucial para lograr una buena utilización del ancho de banda. Si es demasiado pequeño, el peso de los encabezados aumenta, desperdiciandose ancho de banda; si es demasiado grande, el segmento se puede ver fragmentado en su viaje por redes intermedias, aumentando el riesgo de pérdida.

Cómputo de la suma de verificación (checksum)

El cómputo de la suma de verificación es exactamente el mismo que para el protocolo UDP, con el uso de un pseudo-encabezado.

TEMPORIZACIÓN

Uno de los aspectos más complejos del protocolo TCP, que lo diferencia de muchos otros, es la forma en que maneja la temporización para retransmisión (time-out).

La razón por la que el algoritmo TCP es especial proviene del ambiente de red de redes para el que se ha diseñado. En este entorno, un segmento puede viajar a altísima velocidad (cuando atraviesa sólo una LAN) o bien pasar por varias redes intermedias, variando drásticamente el tiempo de llegada.

A esto ha que sumar el factor del tráfico, que puede provocar sustanciales diferencias incluso en la misma ruta en momentos diferentes.

Se llama tiempo de ida y vuelta (round trip time) de un segmento al tiempo que tarda en llegar a su destino más el que tarda su acuse de recibo en retornar al origen.

Algoritmo adaptable

Con estas premisas, se llega a la conclusión de que es necesario incorporar un tipo de algoritmo que se vaya adaptando dinámicamente a los cambios en los tiempos de ida y vuelta. A esto se le llama algoritmo adaptable de retransmisión.

La recolección de datos para este algoritmo se realiza registrando la hora en la que se envía cada segmento y en la que se recibe su asentimiento. Con estos dos datos, se extrae el denominado muestreo del tiempo de ida y vuelta (round trip sample).

TCP guarda un valor promedio del tiempo de ida y vuelta, que es usado como valor de estimación, y que se va ajustando con la llegada de nuevas muestras. El tipo de fórmula que se suele usar para esto se basa en los siguientes parámetros: La constante a, tomada en el intervalo [0,1), hace que la adaptación a nuevas situaciones se haga más o menos gradualmente. El tiempo estimado de ida y vuelta RTT no se usa directamente como valor de terminación del temporizador, sino que se multiplica por un factor fijo o variable b. El ajuste de este factor es muy importante para evitar retransmisiones innecesarias o retardos excesivos.

En la especificación original de TCP se recomendaba un valor de b=2, aunque con el tiempo se han ido desarrollando mejores estimaciones.

Cálculo de la desviación estimada

El uso de un factor fijo para la obtención del tiempo de expiración no permite una buena adaptación en entornos donde se hay un amplio rango de variación en los retardos.

Para mejorar el algoritmo, en la especificación de 1989 de TCP se propone el cálculo de la denominada desviación estimada que, sin aumentar excesivamente los cómputos a realizar, consigue una mejor estimación del tiempo de expiración.

Aquí, la desviación estimada se basa en unas constantes δρ y η indican qué tan rápidamente afectan las nuevas muestras al tiempo de ida y vuelta, la desviación y el tiempo de expiración estimados, respectivamente.

Para hacer los cómputos eficientemente, se recomienda que las constantes δ y ρ tomen valores inversos a potencias de dos, habiendose encontrado que los valores δ=1/23, ρ=1/22 y η=3 consiguen buenos resultados.

Asentimientos ambiguos

La posible presencia de duplicados de segmentos complica el cálculo de las muestras de tiempo de ida y vuelta. Si el temporizador para un segmento expira y éste es retransmitido, será imposible asociar un acuse de recibo con una de las dos o más retransmisiones, produciendose el fenómeno llamado ambigüedad de asentimiento (acknowledgement ambiguity). El resultado es que la muestra de tiempo de ida y vuelta obtenida no es fiable.

No hay una regla que solucione este problema al 100%:

* Asociar siempre los asentimientos con la primera transmisión produce, en situaciones con pérdida frecuente de datagramas, que la estimación de tiempo aumente continuamente.
* Asociar los asentimientos con la última retransmisión puede hacer que la estimación disminuya varias veces por debajo del valor real, provocando retransmisiones inútiles.
Una solución más correcta es el llamado algoritmo de Karn, el cual consiste en simplemente desechar las muestras obtenidas de segmentos retransmitidos.

Es necesario, sin embargo, adaptar este algoritmo para evitar la situación en la que un aumento brusco en los retardos provoque una congelación del valor estimado, al generarse continuas retransmisiones. Para ello, se aplica una anulación de temporizador (timer backoff), consistente en que se aumenta la estimación en un factor g cada vez que hay una retransmisión.

Más detalladamente, el algoritmo de Karn se comporta de la siguiente manera:

* Si se produce una retransmisión, aplicarle un factor de anulación al tiempo de expiración, desvinculándolo del RTT estimado, que no varía.
* No usar las muestras obtenidas de retransmisiones para el cómputo del RTT.
* Sólo cuando se vuelva a obtener una muestra válida, retomar el RTT y recalcularlo extrayendo un nuevo tiempo de expiración.
Este algoritmo, que fue originalmente concebido para redes de radio-paquetes, ha demostrado muy buenos resultados incluso con redes muy inestables.

Temporización y congestionamiento

El congestionamiento es la saturación de datagramas en lugar de la red, normalmente en los gateways. Éstos tienen una capacidad de almacenamiento finita, lo que hace que vayan descartando datagramas en el momento en que se ven saturados.

Los puntos extremos de una comunicación, por lo general, no tienen conocimiento del congestionamiento que ocurre en las redes intermedias, no distinguiéndose del retraso producido por otros factores. Además, los sistemas no orientados a conexión, como IP, no pueden evitar el congestionamiento reservando con antelación espacio en los gateways para cada conexión.

El comportamiento de los protocolos de temporización y retransmisión, como TCP, empeoran las situaciones de congestionamiento, pues responden a los retrasos aumentando más y más el número de datagramas en la red, pudiéndose llegar a la situación denominada colapso por congestionamiento.

Las técnicas recomendadas por el estándar TCP para evitar el congestionamiento son dos:

* Disminución multiplicativa
Se mantiene un segundo tamaño de ventana, llamado ventana de congestionamiento, eligiendose como tamaño efectivo en cada momento el mínimo entre este tamaño y el solicitado por el receptor.

Cuando se pierde un segmento, se reduce a la mitad la ventana de congestionamiento, hasta el mínimo de un segmento.

Para aquellos segmentos que se mantengan dentro de la ventana efectiva, se aplicará una anulación exponencial al temporizador en cada pérdida.

El resultado de esto es que, a medida que aumenta el congestionamiento, se reduce rápidamente el volumen de tráfico, así como la velocidad a que se retransmiten los segmentos perdidos.

* Recuperación de arranque lento
Esta segunda técnica se aplica una vez se ha resuelto el congestionamiento. Para evitar que éste se reproduzca de nuevo rápidamente, el tamaño de la ventana de congestionamiento se va aumentando en sólo un segmento por cada asentimiento recibido correctamente.

Cuando se crea una nueva conexión o se pasa un periodo de congestionamiento, se establece el tamaño inicial de dicha ventana a un segmento, que irá aumentando uno a uno, como se ha explicado.

El desarrollo normal de este algoritmo llevaría, sin embargo, a un aumento exponencial, pues cada bloque de segmentos que se envía duplica en teoría la ventana (un segmento por cada asentimiento). Para que el arranque sea realmente tan lento como se espera, se aplica la siguiente regla:

Al llegar el tamaño de ventana a la mitad del que tenía antes del congestionamiento, el protocolo entra en fase de prevención de congestionamiento. Durante esta fase, se aumenta el tamaño en un solo segmento sólo si, para todos los segmentos de la ventana, se tiene acuses de recibo.

domingo, 20 de noviembre de 2016

TCP/IP (4): La clave se llama confiabilidad (TCP)

TCP es el protocolo que permite a millones de aplicaciones confiar en que miles de millones de paquetes de datos van a llegar a su destino.
Entradas de la serie -> TCP/IP

PROTOCOLO DE CONTROL DE TRANSMISIONES (TCP)

A diferencia de UDP, que no añade nada sustancial a la semántica de entrega no confiable de IP, el Protocolo de Control de Transmisiones (TCP, Transmission Control Protocol) añade la funcionalidad fundamental de la entrega confiable, a cambio de una mayor complejidad.

El diseño de TCP ha sido realizado con gran acierto, manteniendo una separación completa con la red subyacente, o cual permite que pueda ser utilizado con muchos sistemas de entrega, aparte de IP. Su importancia es tal que da nombre, junto con IP, a la familia completa de protocolos TCP/IP, y ha facilitado más que cualquier otro desarrollo la universalización de Internet como red de alcance global. Tiene su origen en los trabajos de Vinton G. Cerf Bob Kahn en la década de 1970. Por ello en muchas ocasiones se ha reconocido a Cerf y Kahn como los "padres" de Internet.

TCP usa el mismo concepto de puerto de protocolo que UDP para implementar el concepto de punto de destino abstracto dentro de una máquina, lo que le permite mantener muchas conexiones en la misma máquina sin mezclarse. Los números de puerto UDP y TCP no se confunden, pues el código de protocolo de la cabecera IP hace que cada protocolo nunca trate con los paquetes del otro.

LA ENTREGA CONFIABLE

Un servicio de entrega confiable se ha de encargar de cinco funciones:

a)    Envío de flujo de datos

Los programas de aplicación normalmente requieren en envío de los datos en forma de flujos de octetos. El servicio de entrega de la máquina destino ha de pasar al proceso receptor exactamente el mismo flujo que se ha transmitido en origen.

Esto evita cualquier tipo de programación adicional en las aplicaciones, ni que éstas conozcan el formato de los paquetes de datos.

b)    Orientación a conexión

Antes de realizarse el envío de los datos, las máquinas implicadas han de negociar la apertura de una conexión o circuito virtual, equivalente al establecimiento de una llamada telefónica, en lugar de tratar por separado el envío de cada segmento.

TCP permite dos formas de abrir una conexión: activa o pasiva. Antes de recibir la petición de conexión, en un extremo se realiza una apertura pasiva en espera de que el otro extremo solicite la entrada mediante una apertura activa. La máquina pasiva establece previamente el puerto en el que va a aceptar conexiones.

c)    Memoria intermedia

Para optimizar el tráfico de red, el software de protocolo ha de recolectar datos suficientes del flujo que genera la aplicación, en una memoria intermedia o buffer, para llenar un segmento razonablemente largo antes de transmitirlo.

Igualmente, se ha de proporcionar un mecanismo push (empuje) que permita que la aplicación fuerce el envío inmediato del contenido del buffer, si fuera necesario. El uso típico de esta característica es en terminales interactivas.

d)    Flujo no estructurado

Los programas de aplicación tienen la responsabilidad de ponerse de acuerdo para entender las fronteras entre registros dentro del flujo de datos; el protocolo de entrega no está obligado a respetar separaciones de registros en las divisiones de paquetes que realiza.

e)    Conexión full-duplex

El servicio de transporte ha de permitir la transmisión concurrente de flujos independientes en ambas direcciones.

IMPLEMENTACIÓN DE LA CONFIABILIDAD

El concepto de asentimiento positivo

La tarea de proporcionar una transferencia confiable sobre un sistema subyacente de entrega no confiable es tarea complicada. La mayor parte de los protocolos existentes hacen uso de la técnica denominada asentimiento positivo con retransmisión.

Un asentimiento positivo implica que el receptor de un mensaje envíe de vuelta al remitente un acuse de recibo (ACK) indicándole que éste ha llegado correctamente. El remitente espera que cada mensaje que envía sea asentido y, en caso de no recibirlo en un tiempo prudencial, lo retransmite.

Esta técnica requiere acciones cuidadosas para controlar las duplicaciones, pues tanto los paquetes como los asentimientos se puede aparecer duplicados. Para controlar esto, se incluyen números de secuencia para que el receptor pueda asociar cada acuse de recibo con su paquete correspondiente y pueda desechar los duplicados.

Técnica de la ventana deslizante

Si el sistema de los asentimientos positivos tuviese que esperar cada acuse de recibo antes de enviar el siguiente paquete, se desperdiciaría una cantidad enorme de ancho de banda.

La técnica conocida como ventana deslizante permite que se envíen varios paquetes seguidos sin esperar asentimientos, optimizando el uso del ancho de banda.

Se establece una ventana de un tamaño fijo, la cual es el marco en el que cabe la máxima cantidad de paquetes que se pueden enviar sin recibir asentimiento. El tamaño de la ventana es proporcional a la memoria intermedia disponible, debido a que cada paquete se ha de mantener en memoria mientras no se haya acusado su recibo, pues puede ser necesaria su retransmisión. Se dice que los paquetes dentro de la ventana están en estado de espera de confirmación (unacknowledged)..

En un primer momento, se pueden transmitir todos los paquetes que caben en la ventana sin asentimiento. En el momento de recibir un acuse de recibo, la ventana se desliza para alcanzar el siguiente paquete y poder enviarlo. Al mismo tiempo, el deslizamiento saca fuera el paquete que se ha asentido, el cual no es necesario mantenerlo más en memoria.

Con un tamaño de ventana suficientemente ajustado a la capacidad de la red, es posible eliminar cualquier tiempo muerto, obteniéndose la velocidad máxima de entrega.
Diagrama de la ventana deslizante
Los tres estados en que puede estar un paquete son:

* Los paquetes que están a un lado de la ventana aún no se han transmitido.
* Al otro lado, los paquetes están enviados y confirmada su recepción.
* Dentro de la ventana, los paquetes han sido enviados, pero están a la espera de ser confirmados. Un temporizador controla su retransmisión en un intervalo razonable.
Detalles del mecanismo de ventana deslizante de TCP

La implementación que TCP hace del mecanismo de la ventana deslizante, además de dar confiabilidad a la comunicación, integra el control de flujo, de manera que el receptor pueda restringir el envío de datos según el espacio que tenga disponible y su capacidad de procesamiento.

Se mantienen ventanas separadas para el flujo de entrada y el de salida, para que así sean totalmente independientes (full-duplex). Por tanto, en una conexión hay cuatro ventanas implicadas: dos en cada extremo.

El trabajo se realiza a nivel de octeto, no por segmentos ni paquetes. Los octetos del flujo de datos se ordenan de manera secuencial, guardando el transmisor tres punteros asociados con cada conexión:

* Un apuntador marca el extremo izquierdo de la ventana, separando los octetos que están pendientes de acuse de recibo de los que ya han sido asentidos.
* Otro apuntador marca el extremo derecho de la ventana, definiendo el octeto más alto que se puede enviar sin recibir más asentimientos.
* Un puntero intermedio indica la frontera entre los octetos que efectivamente se han enviado y los que no.
Una diferencia importante con la definición tradicional de ventana deslizante es que en TCP el tamaño de la ventana es variable. Esto se hace para adaptarse a los cambios en la capacidad de recepción del otro extremo (control de flujo). Un campo en la cabecera TCP de los asentimientos informa de cuántos octetos está preparado para aceptar el receptor en el próximo envío , lo cual permite redimensionar la ventana.

Debido a lo variable del tamaño de los segmentos y de la ventana, los acuses de recibo indican posiciones en el flujo de octetos, sin referirse a datagramas o segmentos completos. El receptor indica en el campo de asentimiento de la cabecera la posición siguiente a la parte de flujo que ha logrado reconstruir completamente, es decir, el número de secuencia del siguiente octeto que espera recibir.

A este tipo de acuse de recibo se le llama acumulativo, pues informa sobre la cantidad de flujo contiguo que ha acumulado el receptor. Su uso tiene las siguientes ventajas:

* Los asentimientos son fáciles de generar.
* No hay ambigüedad posible sobre la información que es asentida.
* La pérdida de algunos asentimientos no fuerzan necesariamente la retransmisión.
A pesar de estas ventajas, este esquema es menos eficiente que otros, pues el receptor no obtiene información sobre las transmisiones exitosas que aún no han producido un bloque contiguo. Esto puede hacer que se retransmitan segmentos inútilmente o bien no se use toda la capacidad de la ventana, según se tome una estrategia pesimista u optimista, respectivamente.

sábado, 12 de noviembre de 2016

TCP/IP (3): Ese desconocido llamado UDP

De los tres protocolos fundamentales de Internet, UDP es el más desconocido, pero imprescindible en la red de redes.

Entradas de la serie -> TCP/IP

PROTOCOLO DE DATAGRAMAS DE USUARIO (UDP)
El protocolo UDP es el sustituto de TCP como protocolo de transporte, cuando no se requiere una entrega confiable. En determinadas aplicaciones, lo importante es que los datos lleguen cuanto antes, aunque esto signifique que se pierdan algunos. En ese caso, se usa UDP en lugar de TCP.

UDP utiliza el protocolo IP subyacente para transportar un mensaje de una máquina a otra, proporcionando la misma semántica de entrega sin conexión y no confiable. No genera asentimientos, no controla el flujo ni ordena los mensajes entrantes. El único trabajo que añade a el de IP es la identificación de los procesos dentro de las máquinas origen y destino, extremos finales de la comunicación, además del cómputo de la suma de verificación (checksum).
IDENTIFICACIÓN DEL PROCESO DESTINO
Parece evidente que el destinatario final de un mensaje enviado es un proceso corriendo en la máquina destino. Ésta normalmente estará corriendo muchos procesos al mismo tiempo, por lo que es necesario identificar al destinatario de cada mensaje.
Especificar un identificador de proceso (PID) en particular en una máquina remota como destino final de un datagrama no es muy buena idea. Varias son las complicaciones:
* Los procesos se crean y destruyen contínuamente de manera dinámica.
* El transmisor rara vez conoce el funcionamiento interno de la otra máquina para identificar los procesos en ella.
* El receptor puede necesitar reemplazar el proceso que está recibiendo una comunicación por otro (p.e. un proceso hijo), sin necesidad de reestablecerla o informar al otro extremo.
* Se necesita acceder a los servicios de una máquina sin conocer internamente los procesos que los proporcionan.
* Un proceso puede necesitar tener abiertas varias conexiones de red, necesitandose alguna forma de seleccionarlas.
Debido a estos inconvenientes, es necesario dejar de pensar en los procesos como destinos finales y establecer unos puntos abstractos de destino, llamados puertos de protocolo.
En la mayoría de los sistemas operativos se proporciona un acceso síncrono a los puertos de protocolo, es decir, el proceso que intenta extraer datos del puerto antes de la llegada de éstos queda bloqueado en espera de ellos. En combinación con este mecanismo, se cuenta con un buffer de memoria intermedia que guarda los datos que van llegando y aún no han sido leídos por el proceso cliente.
Para establecer una comunicación, por tanto, el transmisor necesitará conocer, además de la dirección IP de la máquina destino, el número de puerto donde desea enviar los datos. Los números de los puertos origen y destino de cada datagrama van en la cabecera UDP (o TCP).
Para identificar unívocamente a un flujo de datos en particular son necesarios los dos pares dirección IP/puerto de origen y destino.
FORMATO DE LA CABECERA UDP
A los mensajes UDP se les llama datagramas de usuario.

Cabecera UDP
Este esquema muestra los campos de la cabecera, que tienen 16 bits cada uno. Entre ellos hay una suma de verificación (checksum) de tal manera que se puede controlar si el datagrama ha llegado intacto. Aunque este campo es opcional (se puede hacer 0), es casi obligado su uso, pues es la única manera de hacer esta comprobación. Recuérdese que el checksum de IP sólo se refiere a los campos de su cabecera y que la verificación que se pueda hacer a nivel de enlace sólo tiene sentido dentro de la misma red.
El campo puerto origen se empareja con la dirección IP de origen (de la cabecera IP) y el puerto destino con la dirección IP de destino. A todos los efectos, estos cuatro campos son los que identifican unívocamente una comunicación entre dos máquinas dentro de la red de redes.
El campo de longitud incluye los octetos del encabezado.
Pseudo-cabecera de comprobación
La forma de computar la suma de verificación de UDP es algo extraña. Se intenta que el checksum sirva no sólo para detectar errores, sino para comprobar que el datagrama ha llegado al destino donde fue enviado.
Para comprobarlo no basta con mirar los números de puerto de la cabecera UDP, pues éstos no diferencian unas máquinas de otras. Es necesario incluir las direcciones IP dentro de la suma de verificación, aun cuando éstas no forman parte del datagrama UDP.
Para resolver esta aparente contradicción, la máquina origen monta una pseudo-cabecera que incluye:
* Direcciones IP de origen y destino
* Un octeto 0 de relleno, para alinear en palabras de 32 bits.
* El código de 8 bits del protocolo según el estándar IP (17 para UDP).
* Un campo de 16 bits para la longitud del datagrama (sin incluir el pseudo-encabezado).
Esta información debe coincidir con la de la cabecera IP.
Una vez montada la pseudo-cabecera, se pone a cero el campo checksum de la cabecera UDP, se computa la suma del pseudo-cabecera, la cabecera y el paquete de datos en complemento de 16 bits y se almacena en dicho campo. La pseudo-cabecera no se transmite realmente, y es desechada.
Cuando el datagrama llega a su destino, la máquina receptora debe volver al construir el pseudo-encabezado usando la información de la cabecera IP y comprobar la suma de verificación.
Observese que este truco es una clara violación de la arquitectura en capas, que se ha hecho por motivos puramente prácticos. Esto hace que UDP dependa claramente de IP y más concretamente del formato de su cabecera, lo cual es muy criticable.
APLICACIONES DE UDP
UDP se usa en Internet para dar soporte a protocolos administrativos, poco conocidos por el gran público, pero imprescindibles para el funcionamiento de la red de redes:
* DNS: El sistema de nombres de dominio.
* DHCP: El protocolo que asigna direcciones IP a los dispositivos.
* SNMP, RIP, etc: Protocolos para la gestión interna de la red.

jueves, 3 de noviembre de 2016

TCP/IP (2): Funcionamiento básico

Entradas de la serie -> TCP/IP
El libro clásico e imprescindible.

FUNCIONAMIENTO BÁSICO
1) EL NIVEL TCP
TCP (Protocolo de Control de Transmisiones) se encarga de:
  • Dividir el mensaje en datagramas.
  • Reenviar los datagramas que se pierdan.
  • Reensamblarlos en su orden correcto.
El tamaño máximo del datagrama se establece al iniciar la conexión. La forma más fácil de hacerlo es que cada extremo indique el datagrama mayor que es capaz de manejar, eligiéndose el menor de ellos.
TCP deja en manos de IP un datagrama y su destinatario, siendo trabajo de éste último su transmisión. Usa un mecanismo llamado demultiplexación, que consiste en que cada datagrama "sabe" a qué conexión pertenece gracias a la información contenida en una serie de cabeceras, que se van conteniendo unas a las otras, a medida que va pasando por las manos de los diferentes protocolos y niveles.
La CABECERA TCP tiene los siguientes campos:
Cabecera TCP

Su significado es el siguiente:
  • Puertos (ports) de origen y destino: Son números que identifican cada "conversación" que mantiene un mismo nodo. Gracias a esta diferenciación, una misma máquina puede estar enviando y recibiendo varios flujos de información al mismo tiempo sin mezclarse. Un datagrama tiene que saber a qué número de puerto pertenece en origen y a cuál en destino. Una conexión es identificada unívocamente por los dos pares dirección IP/puerto TCP de origen y destino.
  • Número secuencial (sequence number): Sirve para mantener el orden de los datagramas, y así poder reordenarlos en destino. No se numeran los datagramas, sino los octetos transmitidos. P.e. si el tamaño del datagrama es 500, el primero se numera 0, el segundo 500, el tercero 1000, y así sucesivamente.
  • Checksum: La suma de todos los octetos del datagrama sirve para el control de errores.
  • Número de acuse de recibo (acknowledgement): Por cada datagrama recibido, el destinatario devuelve un datagrama con el número de confirmación, que es el número secuencial del que acaba de recibir. Si en origen no se recibe confirmación de un determinado datagrama en un tiempo razonable, se reenvía.
  • Desplazamiento al área de datos (HLEN): Indica al mismo tiempo el tamaño de la cabecera y el desplazamiento (offset), medido en múltiplos de 32 bits, hacia el lugar donde empiezan los datos. Este campo ocupa sólo tres bits.
  • Banderas de operación (Code bits): Estos seis bits diferencian entre varios tipos de datagramas (datos, asentimientos, solicitud de conexión, etc.)
  • Ventana (Window): Indica la cantidad de información que es capaz de absorber de golpe el destinatario, en forma de un número de 16 bits. El nodo origen sabe así cuántos datagramas seguidos puede enviar sin recibir confirmación. Se suele usar el mismo datagrama que el del número de confirmación, de tal manera que, a medida que se van confirmando los datagramas, el nodo origen va sabiendo la cantidad de información que puede ir enviando.
  • Puntero de urgencias (Urgent pointer): Cuando se envían órdenes de interrupción, o cualquier otra información que deba atenderse de inmediato, este puntero señala el lugar donde se encuentra, de manera que se salte inmediatamente a ella. Se usa en eventos asíncronos. Una de las banderas de operación se activa en estos casos.
  • El campo de opciones es de tamaño variable, rellenándose hasta ocupar 32 bits.
2) EL NIVEL IP
El trabajo de IP consiste únicamente en encontrar el camino y enviar el datagrama. No se preocupa ni de la información que contiene, ni de la cabecera TCP, ni de su relación con otros datagramas. Sólo tiene que saber la dirección IP a la que debe enviarlo. IP añade su propia cabecera, que contiene información que servirá a los gateways y otros sistemas que el datagrama vaya encontrando por el camino. Su formato es el de la figura.
Cabecera IP
El significado de los campos es:
  • Versión (VERS, 4 bits): Identifica la versión del protocolo IP que se utilizó para generar el datagrama. Así se evita que los equipos puedan malinterpretar el contenido de los campos al cambiar de estándar. La versión que mostramos aquí es la 4.
  • Longitud del encabezado (IHL o HLEN, 4 bits): Está medida en palabras de 32 bits. El formato más común es el de 5 palabras (el de la figura), pero puede aparecer opcionalmente una palabra más, llamada opciones IP. Si las opciones que se incluyen no completan 32 bits, se pone un campo de relleno.
  • Tipo de servicio (TOS, 8 bits): Especifica cómo debe manejarse el datagrama. Tiene subcampos que indican la prioridad y el grado de confiabilidad, retardo y capacidad que se requieren para la entrega de el datagrama. Se debe entender esta solicitud como simples indicaciones para los algoritmos de ruteo que ayuden para la selección de una ruta entre varias posibles. Una red de redes nunca garantiza el tipo de servicio solicitado.
  • Longitud total (16 bits): La longitud del datagrama, incluídos la cabecera y los datos. Los 16 bits de este campo limitan la longitud máxima posible de un datagrama IP a 65535 bytes.
  • Identificador (16 bits): Es un número entero que sirve para identificar los trozos de un datagrama fragmentado. Todos los trozos de un datagrama determinado tienen el mismo identificador.
  • Direcciones de origen y destino (Source and destination addresses): Son las direcciones IP (32 bits) de los nodos de origen y de destino. La primera sirve para que el destinatario reconozca el origen del datagrama; la segunda para el posible reenvío por gateways intermedias.
  • Número de protocolo (Protocol number): Identifica el protocolo de alto nivel que ha generado el datagrama. Éste suele ser TCP, pero, como ya se ha explicado, IP puede trabajar para diferentes protocolos, o incluso directamente con las aplicaciones. Este campo, básicamente sirve para que el receptor pueda interpretar correctamente el formato de la información que va encapsulada en el área de datos del datagrama.
  • Checksum (16 bits): Suma para control de errores. El propio campo checksum no entra en la suma (se toma como cero). IP y TCP tienen cada uno su propio checksum, que les permite realizar más eficientemente el control de errores. De hecho, el checksum IP sólo computa los campos de la cabecera IP, y deja a los protocolos de alto nivel la tarea de mantener su propio cómputo.
  • Indicadores y offset de fragmento (Flags and fragment offset): Cuando, en su recorrido, un datagrama se divide en varios fragmentos, estos campos permiten recomponerlo correctamente. Esto suele ocurrir cuando atraviesa redes que no pueden manejar datagramas de su tamaño.
  • Tiempo de vida (Time to live): Es un contador (en segundos) que se va decrementando a medida que pasa por diferentes sistemas. Cuando llega a cero, se considera que ha entrado en un bucle, y se descarta. Esto no es normal que llegue a ocurrir, pero se implementa esta protección para asegurar cualquier tipo de contingencia.
El protocolo establece específicamente el orden de los bits. Esto es importante, porque en una red de redes formada por millones de ordenadores, hay diferentes formas de representar internamente los números binarios. En general hay dos formas de hacerlo, con el octeto menos significativo en la dirección más baja de memoria, o bien con el octeto más significativo primero. Como la cabecera de los paquetes que se transmiten en la red contiene valores binarios que hay que interpretar correctamente, se ha de imponer un estándar, y dejar a cada nodo la tarea de reconvertirlo a su representación interna.
En los protocolos TCP/IP se ha establecido la norma de transmitir primero los bits más significativos (big endian).
Cuando se reciben los paquetes en destino, las diferentes capas deben actuar a la inversa, desmontando sus cabeceras, y reordenando paquetes y datagramas. El proceso que se sigue es el siguiente:
Nivel IP:
* Elimina la cabecera IP, comprobando el checksum.
* Según el número de protocolo, le pasa el datagrama a TCP, u otro al que le corresponda.
Nivel TCP:
* Elimina la cabecera TCP, comprobando el checksum.
* Retorna datagramas de confirmación aceptando o rehusando los diferentes datagramas.
* Reoganiza el mensaje según el orden marcado por los números de secuencia.

4) EL NIVEL DE APLICACION
Mientras que los protocolos básicos que se han visto se encargan de la transmisión, encaminamiento y reconstrucción de los mensajes, los protocolos de aplicación son los que permiten al usuario abrir conexiones remotas, pedir ficheros, enviar correo electrónico, etc.
Los niveles básicos que hemos visto se encargan de las tareas de transporte de los datos, proporcionando al nivel de aplicación una corriente de bytes, para que las aplicaciones la utilicen como si se tratara de una línea telefónica o un terminal.
Establecimiento de la conexión
La mayoría de los sistemas tienen programas especializados que actúan de servidores a la llamada de sistemas remotos (FTP, mail, etc.). Cuando un sistema se conecta con otro, necesita alguna manera de especificar con qué servidor quiere hablar. Para ello se establecen los llamados accesos predeterminados (well-known sockets), que no son más que determinados números de puerto que se reservan para cada servidor. Así, p.e., el puerto 21 se reserva siempre para el servidor FTP. Si existen varias conexiones FTP simultáneas, sólo se diferencian por el par dirección IP/puerto de destino (de cada máquina remota conectada), siendo el mismo puerto (el 21) en el servidor. El puerto asignado por la máquina remota no está predeterminado, y siempre será diferente a cualquier otro que tenga esa misma máquina en conexión. Generalmente, elegirá un número aleatorio superior a 1024 (es lo que se llama puerto anónimo). El servidor pedirá siempre a la máquina remota que escoja e identifique el puerto que está usando.
Las direcciones IP están en la cabecera IP, mientras que los puertos están en la cabecera TCP. Estos cuatro números en conjunto sirven para identificar unívocamente el datagrama.
Intercambio de comandos y datos
Una vez establecida la conexión, existen tres formas de trabajar a nivel de aplicación:
a) Una vez las máquinas se han identificado mutuamente y han asignado los correspondientes puertos, el nivel de aplicación comienza a funcionar intercambiando mensajes que pueden ser comandos (palabras humanas al estilo de los lenguajes de programación), o bien datos. Los datos y los comandos se diferencian sólo por el contexto. El receptor sabe que lo que está recibiendo son datos porque el último comando que vió fue "Comienza el envío de datos". Una marca especial localiza el final de los datos (p.e., en mail se usa un punto al comienzo de una línea).
b) Algunas aplicaciones (como FTP) usan conexiones diferentes para datos y para comandos. En el momento en que FTP comienza a transferir un fichero, abre una conexión con nuevos números de puerto, dejando activa la anterior para permitir que se envíen comandos mientras dure la transmisión (p.e. para abortarla).
c) Las aplicaciones de tipo terminal (como telnet) establecen una sóla conexión donde, por defecto, se envían datos. Un carácter especial sirve para "incrustar" comandos tras él. Si este carácter se llegara a teclear en la terminal, se enviaría dos veces para así dejar claro que no se trata de un comando.
Un trabajo fundamental que debe hacer el nivel de aplicación es adaptar las particularidades de los sistemas (códigos, saltos de línea, etc.), para así permitir el intercambio de información entre sistemas diferentes. TCP e IP no se preocupan de ello, sólo envían octetos tal y como se los proporcionan. Los estándares establecidos marcan las conexiones tipo para cada aplicación, de tal manera que siempre puedan conectarse dos sistemas totalmente diferentes. Sin embargo, se da libertad para que sistemas parecidos puedan ponerse de acuerdo para usar normas comunes más eficaces. Los estándares más comunes son:
* Código ASCII para la representación de caracteres.
* Las nuevas líneas se abren con un retorno de carro seguido de un salto de línea (esto se suele llamar "net ASCII").
* Las conexiones de terminal son half-duplex con eco local.
Un ejemplo de funcionamiento: SMTP (mail)
El estándar SMTP (Simple Mail Transfer Protocol) puede servir de ejemplo de cómo funcionan en general las aplicaciones de red.
SMTP asume la existencia de unas direcciones de mail al estilo usuario@máquina. La máquina que quiere enviar un mensaje, abre una conexión con el servidor de la máquina destinataria, usando el puerto 25 como acceso predeterminado. Se identifica él mismo, identifica al usuario que envía el mensaje, y al destinatario (recipiente). Luego envía el mensaje, siguiendo un esquema de cabecera identificativa, una línea en blanco y texto de mensaje, terminando con un punto al principio de una línea. Si un mensaje llegase a contener dicho punto, se envía el punto dos veces.
Los comandos son de texto normal, facilitando así el seguimiento de las conexiones. Los mensajes de respuesta del servidor van precedidos de un número que los hace identificables por el programa. La parte textual de éstos es para las personas, aunque a veces puede ser usada parte de ésta por el protocolo. Los números de los mensajes están pensados para que baste, en la mayor parte de los casos, con leer el primer dígito. Los mensajes que empiezan por 2 indican éxito; los que empiezan por 3 señalan que se espera una determinada acción; 4 indica errores "temporales", que se pueden subsanar y reintentar la transmisión; el 5 indica errores permanentes.
Un ejemplo de diálogo usando SMTP: Envío de un mensaje de lopez@inca.example.com a perez@lince.example.com:
220 lince.example.com SMTP Service at 9 May 95 18:20:35 EDT
HELO inca.example.com
250 lince.example.com - Hello, inca.example.com
MAIL From:<lopez@inca.example.com>
250 MAIL accepted
RCPT To:<perez@lince.example.com>
250 Recipient accepted
DATA
354 Start mail input; end with <CRLF>.<CRLF>
Date: Sat, 6 May 95 11:11:11 EDT
From: lopez@inca.example.com
To: perez@lince.example.com
Subject: Reunion
Te propongo una reunion a las 16:00 horas, proximo jueves
Saludos.
.
250 OK
QUIT
221 lince.example.com Service closing transmission channel
5) PROTOCOLOS QUE SUSTITUYEN A TCP
Existen casos en los que no vale la pena usar las complejas estructuras de TCP, cuando la información que se va a intercambiar cabe en un sólo datagrama. No es necesario un protocolo tan complejo. Un ejemplo típico son las búsquedas de direcciones a partir de nombres Internet (DNS). La máquina que hace la pregunta sólo manda el nombre a buscar, y el servidor de nombres no retorna más que la dirección correspondiente.
UDP (User datagram protocol) está diseñado para aplicaciones que no necesitan enviar mensajes de más de un datagrama. Sustituye a TCP, encajando exactamente en el hueco que deja éste: coloca su cabecera y pasa la información a IP (el cual pondrá el número de protocolo de UDP en su cabecera, en vez del de TCP). No divide el mensaje en datagramas, ni tampoco controla si el mensaje llega a su destino.
ICMP (Internet control message protocol) se usa para enviar mensajes de error, o de otro tipo. Es usado por el propio software TCP/IP (más que por otro tipo de aplicaciones) para comunicarse, por ejemplo, un fallo en la conexión. Es aún más simple que UDP, y también maneja mensajes de un sólo datagrama, y ni siquiera usa números de puerto.