• El modelo TCP/IP:

El TCP/IP o TRANSPORT CONTROL PROTOCOL más que un protocolo es un conjunto de protocolos. Se ha convertido en el estándar de intercomunicación de redes de área extensa y es el único protocolo de enlace y transporte permitido en Internet.

La idea general de conectar una red con ordenadores diferentes partió de las investigaciones llevadas a cabo en la Defense Advanced Research Projects Agency (DARPA). En el ámbito de esta investigación, DARPA desarrollo el conjunto de protocolos TCP/IP para establecer comunicaciones entre redes e implantó una red que recibió el nombre de ARPAnet, que más tarde se convirtió en Internet. El conjunto de protocolos TCP/IP define los formatos y normas utilizados en la transmisión y recepción de información con independencia de cualquier tipo de hardware determinado u organización de red. A pesar de los protocolos se desarrollaron para la internet, TCP/IP se ha convertido en el estándar de hecho ya que muchas organizaciones publicas y privadas lo utilizan para su conectividad.

El éxito inicial de TCP/IP fue debido a su inclusión en las diferentes variedades del sistema operativo UNIX y fue impulsado porque su implantación resulta más cómoda y económica que los protocolos equivalentes. TCP/IP emplea un modelo de enrutamiento basado en "datagramas" (paquetes) en lugar de circuitos virtuales. TCP/IP brinda a los arquitectos de sistemas e ingenieros de comunicaciones una independencia del hardware utilizado.

• TCP/IP lleva asociado una serie de conceptos a aclarar:

• Hosts: son cada uno de los dispositivos conectados a la red. Un host puede ser un servidor, un puesto de la red, un servidor de impresoras, un router, etc.

• Dirección: es un código que identifica a cada dispositivo dentro de la red.

• Red: Conjunto de hosts agrupados bajo una misma dirección de red.

• Subred: conjunto de hosts dentro de una red.

• Conjunto de protocolos TCP/IP:

En líneas generales, el conjunto de protocolos TCP/IP se corresponde con el modelo de comunicaciones de red definido por la International Organization for Standardization (ISO). Este modelo se denomina modelo de referencia Interconexión de sistemas abiertos (OSI). El modelo OSI describe un sistema de redes ideal que permite establecer una comunicación entre procesos de capas distintas y fáciles de identificar. En el host, las capas prestan servicios a capas superiores y reciben servicios de capas inferiores. La siguiente figura muestra las siete capas del modelo de referencia OSI y su correspondencia general con las capas del conjunto de protocolos TCP/IP.

Modelo de referencia OSI y las capas de TCP/IP correspondientes:

Nivel Función Protocolo

Telnet

FTP

TFTP

SMTP

DNS

1

2

TCP		UPD
IP	ICPM			RIP OSPF EGP
					ARP	RARP

Ethernet

Token Ring

Otros medios

El sistema para determinar capas permite a los programadores concentrar sus esfuerzos en las funciones de una capa determinada. No es necesario que creen todo los mecanismos para enviar información a lo largo de la red. Sólo tienen que saber los servicios que el software debe proporcionar a la capa superior, los servicios que las capas inferiores pueden proporcionar al software y qué protocolos del conjunto proporcionan estos servicios.

A continuación se enumeran los protocolos más comunes del conjunto de protocolos TCP/IP y los servicios que proporcionan.

Protocolos TCP/IP	Servicio
Protocolo Internet (IP)	Proporciona servicios para la entrega de paquetes (encaminamiento) entre nodos.
Protocolo de control de mensaje Internet (ICMP)	Regula la transmisión de mensajes de error y control entre los host y las gateways.
Protocolo de resolución de direcciones (ARP)	Asigna direcciones Internet a direcciones físicas.
Protocolo de resolución de direcciones invertidas (RARP)	Asigna direcciones físicas a direcciones Internet.
Protocolo de control de transmisión (TCP)	Proporciona servicios de envío de flujos fiables entre los clientes.
Protocolo de datagrama de usuario (UDP)	Proporciona servicio de entrega de datagramas no fiable entre clientes.
Protocolo de transferencia de archivos (FTP)	Proporciona servicios de nivel de aplicación para la transferencia de archivos.
TELNET	Proporciona un método de emulación de terminal.
Protocolo de información de encaminamiento (RIP)	Permite el intercambio de información de encamina-miento de vectores de distancia entre routers.
Protocolo Abrir la vía más corta primero (OPSF)	Permite el intercambio de información de encamina-miento de estado del enlace entre routers.
Protocolo Gateway externo (EGP)	Permite el intercambio de información de encamina-miento entre routers externos.

• Descripción general del uso de TCP/IP :

Las aplicaciones que se desarrollan con TCP/IP, normalmente, usan varios protocolos del conjunto. La suma de las capas del conjunto de protocolos se conoce también como el stack de protocolo. Las aplicaciones definidas por el usuario se comunican con la capa superior del conjunto de protocolos. La capa de nivel superior del protocolo del computador de origen traspasa la información a las capas inferiores del stack, que a su vez la pasan a la red física. La red física traspasa la información al ordenador de destino. Las capas inferiores del stack de protocolo del ordenador de destino pasan la información a las capas superiores, que a su vez la pasan a la aplicación de destino.

Cada capa del conjunto de protocolos TCP/IP tiene varias funciones; estas funciones son independientes de las otras capas. No obstante, cada capa espera recibir determinados servicios de la capa inferior y cada capa proporciona ciertos servicios a la capa superior.

La siguiente figura muestra las diferentes capas del conjunto TCP/IP. Cada capa del stack de protocolo del ordenador de origen se comunica con la misma capa del ordenador de destino. Las capas que se encuentran al mismo nivel en el ordenador de origen y de destino son pares. Asimismo, la aplicación del ordenador de origen y la del de destino también son pares. Desde el punto de vista del usuario o programador, la transferencia de paquetes se efectúa directamente de una capa par a otra.

Capas de los protocolos TCP/IP:

El proceso que utiliza una aplicación para transferir el contenido de un archivo es el siguiente:

La capa de la aplicación envía un flujo de bytes a la capa de transporte del ordenador de origen.

La capa de transporte divide el flujo en segmentos TCP, asigna un encabezado con un número de secuencia al segmento en cuestión y transmite este segmento a la capa de Internet (IP). Se calcula la suma de comprobación.

La capa de IP crea un paquete con parte de los datos que contiene el segmento TCP. La capa de IP añade al paquete un encabezado que indica las direcciones IP de origen y de destino. Esta capa también determina la dirección física del ordenador de destino o los ordenadores que actúan como intermediarios hasta el host de destino. Entonces, envía el paquete y la dirección física a la capa de enlace de datos. Se vuelve a calcular la suma de comprobación.

La capa de enlace de datos transmite el paquete IP en la sección de datos de una trama de enlace de datos al ordenador de destino. Si el ordenador de destino actúa como intermediario, el paso 3 volverá a repetirse hasta que se alcance el destino final.

Cuando se alcanza el ordenador de destino, la capa de enlace de datos descarta el encabezado del enlace y envía el paquete IP a la capa de IP.

La capa de IP verifica el encabezado del paquete. Si la suma de comprobación del encabezado no coincide con la calculada por dicha capa, el paquete se ignora.

Si las sumas coinciden, la capa IP descarta el encabezado y envía el segmento TCP a la capa TCP correspondiente. Esta capa comprueba el número de secuencia para determinar si el segmento, es el segmento correcto de la secuencia.

La capa TCP calcula una suma de comprobación para los datos y el encabezado TCP. Si la suma no coincide con la suma transmitida con el encabezado, la capa TCP descarta el segmento. Si la suma coincide y el segmento está en la secuencia correcta, la capa TCP envía un reconocimiento al ordenador de destino.

La capa TCP descarta el encabezado TCP y transfiere los bytes del segmento que acaba de recibir a la aplicación.

La aplicación que se encuentra en el ordenador de destino recibe un flujo de bytes como si estuviera conectado directamente a la aplicación del ordenador de origen.

• Propiedades del TCP:

Las Propiedades que suministra el TCP al nivel de Aplicación son:

• Orientado a ristras de caracteres: No recibe de su nivel superior (el Nivel de Aplicación) mensajes troceados, sino una ristra de caracteres que debe enviar completa al destino. El usuario origen envía un mensaje (ristra de caracteres) al TCP y quiere que éste la haga llegar al usuario destino. Si es necesario dividir esta ristra en trozos para su transmisión, esto será totalmente transparente a los usuarios.

La unidad de transmisión de cara al programa de aplicación es un byte; la unidad de transmisión manda byte a byte y el protocolo de transporte los va recogiendo y luego los manda en un paquete.

• Utiliza conexión en Circuitos Virtuales. Antes de empezar la transmisión de datos, se tienen que poner de acuerdo los programas de aplicación de los 2 extremos. Uno solicita la conexión, el otro la acepta, y una vez solicitada y aceptada, queda establecida la conexión, y comienza la transmisión de datos:

• Establecimiento de la conexión.

• Transferencia de datos.

• Liberación de conexión.

• Transferencia "Bufferada" . Los datos no se van mandando según son enviados desde el Nivel de Aplicación al Protocolo de Transporte ( que como vemos se envían byte a byte). El protocolo de transporte va almacenando los datos, construye un paquete con un número determinado de bytes y lo manda. No se envía un paquete hasta que no alcanza un tamaño mínimo, llenando con datos de un mismo programa de aplicación o de varios ( por motivos de eficiencia).

• Ristras no estructuradas.

1) Los números de secuencia están asociados a cada byte.

2) Cada byte posee un número de secuencia.

3) Cada byte dentro de un paquete posee un nº de secuencia que lo identifica.

No existe una estructuración para la transferencia.

• Conexión full-duplex.

Para implementar la fiabilidad el TCP emplea el mecanismo de VENTANA DESLIZANTE. Es decir, para evitar que los paquetes se pierdan o sean duplicados al destino, se establece la necesidad de un reconocimiento desde el receptor por cada paquete enviado.

Además el emisor activa un timer por cada paquete enviado, tal que si en un tiempo determinado no recibe el reconocimiento asociado, retransmite el paquete. Este método supone que el emisor debe guardar el paquete enviado hasta que el receptor reconozca que le ha llegado, y pueda eliminarlo del buffer.

Una primera aproximación sería:

Este mecanismo no está orientado a paquetes, sino a octetos, se envía un octeto y se espera su reconocimiento. No se envía un byte hasta que no se ha reconocido el anterior.

Esta 1ª aproximación se dice que es de ventana de tamaño igual a 1, ya que el emisor envía un paquete y no envía otro hasta que recibe el reconocimiento del receptor de que lo ha recibido correctamente. Si el tiempo de transmisión es elevado, el emisor puede estar mucho tiempo en espera y la conexión está siendo infrautilizada. Es una aproximación ineficiente.

En una siguiente aproximación en la que el tamaño de la ventana es mayor que uno, se pueden enviar tantos paquetes como el ancho de la ventana y esperar sus reconocimientos, a medida que estos van llegando se rueda la ventana (al llegar el recogimiento de un paquete, se borra este del buffer del emisor y puede ocupar su puesto un nuevo paquete que será enviado, conservando su copia en el buffer en espera de su reconocimiento).

En la figura anterior sólo se contempla la transmisión en un sentido (half-duplex) con una estación emisora y otra receptora; pero se puede desarrollar transmisión full-duplex (permitido por TCP) por lo tanto cada una de las estaciones tendrá una ventana de transmisión enviando paquetes de datos a la otra estación y reconociendo los paquetes recibidos.

Cada estación tiene asociado un timer a cada Paquete que ha enviado. Si éste expira antes de que le llegue el reconocimiento de la otra estación, el paquete es retransmitido. Esto puede suceder por 2 motivos:

Pérdida de un paquete.

b) Pérdida de un reconocimiento.

En cualquiera de los 2 casos se retransmite el paquete.

El problema que nos aparece ahora es la aparición de paquetes de datos duplicados, bien por la pérdida del reconocimiento, bien por la pérdida temporal de un paquete de datos y su posterior recuperación.

Para resolver el problema se añade un número de secuencia a cada paquete de datos.

En este caso, por ejemplo, el receptor recibe un paquete de datos con número de secuencia 1 y envía el reconocimiento de haberío recibido; tiempo después vuelve a recibir un paquete con el número de secuencia 1 e interpreta que se ha perdido su reconocimiento, vuelve a transmitir el reconocimiento de que le ha llegado el paquete 1.

Conclusión : la pérdida de un paquete se resuelve con el envío de un reconocimiento por parte del receptor, y el problema de paquetes duplicados con el nº de secuencia que identifican a cada paquete de datos.

Un problema de esta aproximación es que el emisor exige que los paquetes de datos que envía le sean reconocidos uno a uno, y no rueda la ventana ( elimina de sus buffers un paquete de datos, haciendo sitio para otro ) hasta que este, el primer paquete enviado, no se ha confirmado puntualmente, siendo necesaria la retransmisión en el caso de que se pierda un reconocimiento.

Una mejora a este planteamiento es que el receptor no reconoce explícitamente el número de paquete que le ha llegado, sino que lleva un contador indicando el siguiente número de secuencia que espera recibir. Cuando le llega un paquete con número de secuencia X, le envía un mensaje indicando al emisor que el siguiente número de secuencia esperado es el X+l, Reconociendo implícitamente que le han llegado correctamente todos los paquetes con número de secuencia menores. Con este planteamiento, la pérdida de un reconocimiento no siempre implica la retransmisión de un paquete.

- Fácil de implementar : con un contador adicional. Cada estación lleva dos contadores:

- Nº de secuencia de sus paquetes de datos.

- N2 de secuencia del siguiente paquete a recibir.

Una desventaja de este mecanismo es lo que sucede si un paquete se pierde:

Al receptor le llegan paquetes con numero de secuencia mayor que 2, que va almacenando pero que no puede reconocer (reconocerla implícitamente que le ha llegado el paquete 2, lo que es falso). Expirará el timer asociado al reconocimiento del paquete 2 y éste será retransmitido por el emisor nuevamente.

Como hemos dicho, al receptor le pueden llegar paquetes fuera de orden que almacenará en sus buffers.

• Formato de los paquetes TCP.

Un paquete TCP va dentro del campo de datos del paquete IP.

Su formato es :

0 4 10 16 24 31

PUERTO ORIGEN			PUERTO DESTINO
Nº DE SECUENCIA
Nº DE RECONOCIMIENTO
HLEN	RESERVADO	BITS COD.	VENTANA
OPCIONES ( si las hay)				PADDING
DATOS

- Identificadores de los puertos origen y destino, de 16 bits cada uno. El identificador de las máquinas que se comunican va en el paquete IP.

- Número de secuencia del paquete,

- Número de reconocimiento, al ser full-duplex afecta a la transferencia en el otro sentido: "piggv-backing". Nº del siguiente byte que espera recibir.

- Longitud de la cabecera, (4 bits), que puede variar debido al campo opciones.

- Bits de Código, (6 bits), codifican el tipo de paquete TCP.

- Ventana, indica el nº de créditos concedidos al otro extremo, es decir, el nº de bytes que el extremo remoto le puede enviar.

- Checksum, control de errores.

- Puntero urgente .

- Paddiq, para completar el paquete a una longitud múltiplo de 32 bits.

• Función del campo CODE BITS.

El TCP irá recibiendo byte a byte del nivel de aplicación, pero retarda la transmisión de los bytes individuales, para construir un dataqrama de un tamaño determinado y mandarlo. A través del campo Code-Bits se puede indicar al TCP qué tipo de paquete es el que se manda, Este campo consta de 6 bits ( flags) , cada uno de ellos tiene un significado, y nos da una información sobre el paquete. Los nombres de estos bits son :

- URG.

- ACK.

- PSH.

- RST.

- SYN.

- FIN.

Estos flags indican :

- URG Mensaje Urgente. Da validez al campo de puntero de datos urgentes. Un paquete de este tipo se salta el control de flujo normal del protocolo. El puntero dice donde acaban los datos urgentes, que deben estar al principio y no al final. Es equivalente a los datos acelerados del nivel de transporte de ISO. Por ejemplo: si el nivel de aplicación está mandando octetos al TCP, y éste los está recogiendo para construir un paquete mayor, y de pronto el nivel de aplicación envía unos datos urgentes, el TCP envía estos últimos inmediatamente, saltándose a los otros que están esperando para construir un paquete (información que debe recibir el receptor urgentemente) .

-ACK (Reconocimiento). Indica que el campo de reconocimiento está activo. Esto se utiliza cuando se emplean los paquetes de datos para enviar los reconocimientos al otro extremo. Se inspecciona este flag para saber si el campo de reconocimiento tiene el mismo valor que el último paquete que llegó o tiene un nuevo valor.

-PSH (Push). Solicitud de que este mensaje se emita sin espera. El nivel de aplicación lo que hace es mandar bytes al TCP y en cualquier momento puede enviar un byte que indica un push (porque el programa de aplicación ya no tiene más bytes que enviar). Lo que hace que el TCP deje de esperar por más bytes del nivel de aplicación y con los que tiene construye un paquete y lo envía. La diferencia con el primer bit estudiado es que el PSH no altera el orden de los bytes a transmitir, en el mismo orden que recibe los bytes el TCP, los transmite. Un ejemplo de su uso son las conexiones interactivas donde son pocos los datos que hay que transmitir cada vez.

-RST (Reset). Petición de resetear la conexión.

-SYN (Sincronización). Sincronizar los números de secuencia.

-FIN (Fin). Marcador de que no existen más datos.

• Tamaño máximo de segmento:

En una interred se pueden comunicar estaciones de redes diferentes que pueden tener paquetes de tamaño diferente, así que si un paquete que se está transmitiendo no se acopla al tamaño físico del nivel de red de la siguiente red, tendrá que ser fragmentado. La fragmentación de paquetes añade algunos problemas y la tasa de errores a la hora de entregar una información depende del número de paquetes que se transmitan, a mayor número de paquetes la probabilidad de que alguno de ellos se pierda es mayor (cada uno de ellos puede sufrir un encaminamiento distinto a través de redes distintas). Y es el TCP el que debe encargarse de los posibles errores de transmisión.

La unidad de transferencia entre el software TCP de dos máquinas se llama segmento no todos los segmentos enviados a través de una conexión tienen que ser del mismo tamaño, pero ambos extremos deben coincidir en el tamaño máximo permitido. Así que para el TCP es necesaria la negociación entre los dos extremos de la conexión del tamaño máximo de los segmentos, esta oscilación se realiza a través del camino opción visto antes. En este sentido si por algún motivo se conoce el conjunto de redes que van a atravesar los mensajes que se van a transmitir entre dos sistemas informáticos, se puede intentar determinar el tamaño máximo adecuado.

Por ejemplo tomar como tamaño máximo de segmento el tamaño de segmento más pequeño de todas las redes por las que deba pasar, de esta forma todos los mensajes que se transmiten a nivel de transporte caben en la unidad IP más pequeña de todo el conjunto de redes, y no será necesaria la fragmentación.

En cualquier caso debemos tener en cuenta la eficiencia, que se calcula con la relación:

D / (D + H)

siendo D el tamaño de los datos y H el tamaño de la cabecera.

Sí el tamaño es pequeño la eficiencia del sistema cae ya que los distintos encabezamientos tendrían casi más peso que los datos. Si el tamaño es grande también disminuye la eficiencia porque existirá una mayor fragmentación elevándose la probabilidad de perdida de algún fragmento.

La filosofía que se sigue en el TCP para la elección del tamaño máximo es la siguiente:

-Si los S.I. están en la misma red se toma el tamaño de paquete de esa red.

-Si los S.I. están en diferentes redes se recomienda un tamaño de 536 (el tamaño por defecto de un datagrama IP., 5/6, menos la suma de los tamaños estándar de las cabeceras IP y TCP, 40).

El objetivo que estamos buscando es encontrar el tamaño óptimo, aquel en el que el datagrama IP que soporta al segmento TCP no necesite fragmentación. Las dificultades en encontrarlo son:

• TCP no incluye un mecanismo para ello. No define ningún tipo de algoritmo para intentar detectar el tamaño óptimo de forma que la eficiencia del protocolo se la mayor posible.

• TCP establece una conexión entre dos puntos pero eso no quiere decir que los datos vayan a seguir todos la misma ruta. No es el concepto de C.V. de X.25 donde la ruta siempre la misma, aquí las pasarelas pueden cambiar la ruta dinámicamente.

• Éste tamaño óptimo depende del tamaño de los encabezamientos de los protocolos de los niveles inferiores. Si las redes que atraviesa son todas del mismo tipo entonces los encabezamientos serán del mismo tamaño, sino pueden ser distintos.

• Cálculo del checksum

El checksum se utiliza para verificar la integridad de los datos.

El cálculo del checksum es el mecanismo de control que se sigue prácticamente en todas las redes y consiste en utilizar un polinomio que se aplica sobre el paquete TCP, o sobre el paquete correspondiente en otro caso, que genera una serie de valores que constituirán el campo checksum. (Esto ocurre en el emisor) . Mediante el mismo polinomio el receptor comprueba que el paquete recibido ha llegado intacto.

0 4 10 16 24 31

SOURCHE PORT			DESTINATION PORT
SEQUENCE UMBER
ACKNOWLEDGEMENT NUMBER
HLEN	RESERVED	CODE BITS	WINDOW
CHECKSUM			URGENT POINTER
OPTIONS (IF ANY)				PADDING
DATA
...........

Si aplicamos el cálculo del checksum al paquete TCP de la figura anterior podremos testear que no hay errores en cuanto al paquete TCP que se envía, pero el TCP va sobre el protocolo IP y este protocolo no garantiza que los paquetes lleguen libres de errores. Un caso típico indetectable seria que la dirección fuente se hubiese cambiado debido a algún tipo de error en la línea durante su trayecto al destino. Cuando el paquete llega al destino y este envíe el reconocimiento, el reconocimiento no llegará al sistema informativo fuente al haberse cambiado su dirección.

Para prevenir este tipo de errores se añade al paquete o segmento TCP un pseudoencabezamiento que contiene la dirección fuente IP, la dirección destino IP, el protocolo que usa TCP, la longitud del segmento TCP y los ceros necesarios para que el segmento sea múltiplo de 16 bits. El checksum ahora se realiza sobre el pseudoencabezamiento y sobre el antiguo paquete TCP. De esta manera se testea, no solo que el paquete llegue intacto sino que las direcciones sean correctas.

0 8 16 31

SOURCE IP ADDRESS
DESTINATION IP ADDRESS
ZERO	PROTOCOL	TCP LENGTH

El campo "Protocolo" indica al destino, que el paquete que recibió no pertenece a un protocolo distinto del que él estaba esperando. E1 receptor extrae la información necesaria para el pseudoencabezamiento del datagrama IP que llevaba el segmento y lo incluirá en el cálculo del checksum para verificar que el segmento ha llegado intacto al destino correcto.

• Reconocimientos y Retransmisiones

El mecanismo de control de Paquetes por parte del TCP es el mecanismo típico de reconocimientos y retransmisión. Debido a que los paquetes TCP no son de longitud fija, los reconocimientos se refieren a bytes e indican cual es el siguiente byte que se espera recibir. Como los segmentos viajan en datagramas IP, se pueden perder o llegar fuera de orden al receptor; para reordenarlos el receptor utiliza el número de secuencia de los mismos. En algún momento, el receptor puede haber reconstruido 0 o más bytes continuos, pero puede tener piezas del segmento que hayan llegado fuera de orden. El reconocimiento especifica un número mayor que el byte de mayor orden del segmento antiguo recibido.

Este esquema tiene una serie de ventajas e inconvenientes:

Ventajas:

• Los reconocimientos son fáciles de generar, ya que consiste simplemente en contar el número de bytes que nos hallan llevado en orden y colocar este valor más 1 en el campo de reconocimiento del siguiente paquete a enviar.

• Las pérdidas de reconocimiento no suponen siempre retransmisión de paquetes.

Si se envían el paquete 1 y el paquete 2, al llegar ambos paquetes al receptor, este envía el reconocimiento 1 y después el reconocimiento 2.Si se pierde el reconocimiento 1 pero, sin embargo, llega al emisor el reconocimiento 2 de vencer el timer del paquete 1,quedarán reconocidos los dos paquetes. Con lo cual la pérdida del reconocimiento 1 no fuerza la retransmisión del paquete 1.

Desventajas:

¿Qué ocurre si lo que se pierde es un paquete o un segmento?

El emisor no recibe información sobre las transmisiones que le han llegado correctamente al receptor, sino sobre una posición inicial de esa transmisión.

Supóngase que llega el paquete 1 al receptor y este envía al emisor el reconocimiento de este paquete. El paquete 2 se pierde y luego llegan el paquete 3 y el paquete 4. El receptor enviará continuamente el reconocimiento 1 indicando que espera el siguiente byte correspondiente al paquete 2, ya que no podrá enlazar el resto de los paquetes que le han llegado fuera de orden. Debido a que el TCP puede trabajar en interred, a pesar de llegarle al emisor continuos reconocimientos indicándole que el byte que espera es del paquete 2, el emisor no puede suponer que este paquete se haya perdido hasta que venza su timer ya que puede ser que el paquete haya seguido una ruta diferente v más larga que la de los reconocimientos. El emisor ha de esperar a que venza el timer del paquete y durante ese tiempo la red estará inactiva.

• El receptor almacena los paquetes 3 y 4, pero espera que llegue el 2, con lo que puede ocurrir un bloqueo.

• Timeout y retransmisión:

Como otros protocolos el TCP espera que el destino envíe reconocimientos siempre que reciba con éxito nuevos bytes del segmento, el TCP inicia un timer y espera por el reconocimiento. si el timer expira antes de que los datos del segmento hayan sido reconocidos, TCP supone que se perdió el segmento o llegó erróneo y lo retransmite.

El algoritmo de retransmisión de TCP es diferente de los algoritmos usados en otros protocolos de red interred. En una interred los paquetes y los reconocimientos viajan a diferentes velocidades dependiendo de las redes por las que pasen diferentes velocidades dependiendo de las redes por las que pasen e individualmente pueden seguir rutas distintas. Además, el nivel de congestión de dichas redes puede retrasar el paso de los paquetes por ellos. Por lo que es complicado fijar un valor para el timer, ya que el tiempo requerido para que un segmento viaje al destino y regrese el reconocimiento al emisor varia de un instante a otro.

La gráfica siguiente refleja el muestreo sobre 100 paquetes sucesivos que se envían entre dos extremos y las cruces marcan el tiempo que tarda cada paquete en llegar al extremo opuesto y devolver el reconocimiento.

Como vemos, medidas de tiempo son muy dispares, por lo que el valor del timer no puede ser fijo. Si fuera fijo, tendríamos 2 opciones:

1- Colocar un timer muy bajo que darla lugar a retransmisiones continuas de los paquetes, ya que vence el timer incluso antes de que llene el paquete al otro extremo. Esto daría lugar, además, a una sobrecarga en la red.

2- Colocar un timer muy alto que podría suponer una parada del emisor en el sentido de que se le acaben los bytes a transcribir y tenga que esperar mucho tiempo para que se de un timeout y darse cuenta de que ha llegado un paquete erróneo al destino o darse cuenta de que no ha llegado.

Para solucionar este problema se ha desarrollado un algoritmo de retransmisión adaptativa. El TCP controla el rendimiento de cada transmisión y deduce valores razonables para los timeout. A medida que cambia el rendimiento de la conexión, el TCP adapta el timeout a ese cambio. El TCP recoge el tiempo en el que se envía cada segmento y el tiempo en el que llega el reconocimiento de ese segmento.

De ambos valores calcula el tiempo estimado de transmisión-reconocimiento (RTT) que es una medida ponderada del último valor RTT obtenido y de los valores anteriores.

RTT = (  * ODL RTT ) + ((1 - ) + NEW-ROUND_TRIP_SAMPLE)

Variando el valor del parámetro  , se le dará más peso a los últimos valores estimados del timeout o a los valores estimados anteriormente.

Si elegimos un valor para  cercano a 1, la media ponderada se hace inmune a cambios que duran poco tiempo (por ejemplo, un segmento simple que encuentra un gran retraso).

Si por el contrario, elegimos un valor para  cercano a cero hacemos que la media ponderada responda muy rápidamente a cambios en el retraso. Por lo que el valor de  dará lugar a que se espere bastante tiempo antes de reorganizar el timeout o a que ante el más mínimo cambio se requiera el tiempo del timeout.

 ---- > 1 ;cambios suaves

 ---- > 0 ;cambios bruscos.

Para calcular el valor del timeout, la estimación del tiempo de transición-reconocimiento (RTT) se multiplica por un cierto  que, según estudios realizados, su valor se aproxima a dos.

Timeout =  + RTT = 2 + RTT

• La medida del RTT

Para medir el tiempo de RTT se resta el tiempo en el que se envía el segmento menos el tiempo en el que se recibe el reconocimiento. Pero este cálculo no funciona cuando hay retransmisiones. Por ejemplo, el TCP forma un segmento, lo pone en un datagrama y lo envía. Si suponemos que el tiempo de timeout es bajo, el timer expira antes de que llegue el reconocimiento y el TCP envía el segmento de nuevo en un segundo datagrama. Como, ambos datagramas llevaban el mismo segmento de datos, el emisor no tiene forma de saber si el reconocimiento que le llega corresponde al datagrama original o al retransmitido.

Esto se reconoce como ambigüedad de reconocimientos. (véase la siguiente figura.)

Posibles medidas de RTT

Otro caso puede suceder cuando el primer paquete que se envíe se pierda. El timer expira y se envía de nuevo el paquete para el que obtendremos el reconocimiento. (véase la siguiente figura).

Posibles medidas de RTT

El problema es que no se sabe a que paquete asignar el reconocimiento, al primero enviado o al retransmitido. Cualquiera de las dos asignaciones daría lugar a una estimación errónea para el timeout.

Para solucionar este problema se ha desarrollado el algoritmo de Karn.

Este algoritmo consiste en ignorar los tiempos de los segmentos retransmitidos y utilizar la estrategia de backoof para los segmentos retransmitidos.

Para reconocimientos no ambiguos (reconocimientos de segmentos que han sido enviados una sola vez) se calcula el tiempo de transmisión reconocimiento (RTT) según vimos antes. Cuando ocurre una retransmisión, se calcula el nuevo timeout como:

nuevo-timeout = r + timeout-antiguo donde r = 2

Cada vez que el timer expira y causa una retransmisión, el TCP incrementa el timeout. Para evitar que el timeout sea muy alto, se coloca un limite superior para el mismo. Este límite superior será el mayor de los retardos a través de cualquier camino de la interred.

• Control de la congestión:

Puede parecer que el software del TCP solo está diseñado para considerar la interacción entre los dos extremos de una conexión y los retrasos de comunicación entre esos extremos. Pero en la práctica el TCP debe actuar también sobre la congestión en la interred.

La congestión se debe a un gran retraso causado por una sobrecarga de datagramas en uno o mas puntos de conexión (Por ejemplo, pasarela). Cuando ocurre una congestión, por ejemplo cuando a una pasarela le llega excesivo tráfico, se incrementan los retrasos y la pasarela admite los paquetes y los encola hasta que los pueda emitir. cada pasarela tiene una capacidad de almacenamiento finita y los datagramas tienen que competir por ese almacenamiento. Si la cola de la pasarela se llena los siguientes paquetes que lleguen se tendrán que rechazar. Al ser rechazados, expira el timer de dichos paquetes en el emisor y volverán a retransmitiese. Esto dará lugar a un aumento en la congestión y a un aumento del retardo.

El ciclo es el siguiente: aparece congestión y aumenta el retardo, al aumentar el retardo expiran los timeout y se producen retransmisiones. Estas retransmisiones darán lugar a una mayor congestión que a su vez originará mayor retardo hasta que finalmente tenga lugar un colapso en la interred de forma que se quedará totalmente bloqueada.

La solución idónea a este Problema es reducir la velocidad de transmisión. Pero el emisor no es capaz de saber que hay congestión en la red, él simplemente observa que los paquetes se están perdiendo, pero no sabe la causa. El TCP ha implementado dos técnicas para que el emisor reduzca la velocidad de transmisión cuando ocurren retrasos, son la Slow-start y Multiplicative-decrease.

Como dijimos anteriormente, para cada conexión el TCP debe recordar el tamaño de ventana receptora (número de bytes que puede aceptar el receptor) . Para controlar la congestión, el TCP mantiene un segundo límite que es la ventana de congestión, que es el número de bytes que se pueden introducir en la red debido a la congestión. En cada momento el TCP calcula el tamaño de esta ventana como:

Ventana-permitia = mín. (Anuncio receptor, ventana-congestión)

Cuando no hay congestión, la ventana e congestión es del mismo tamaño que la ventana del receptor y se pueden introducir en la red tantos bytes como permita la ventana del receptor. Cuando hay congestión, se reduce la ventana de congestión lo que hace reducir el tráfico que el TCP inyectará en la conexión.

Para estimar el tamaño de la ventana de congestión se utilizan las técnicas:

• Multiplicative-decrease: cada vez que hay pérdida de un segmento, la ventana de congestión se divide por dos (hasta, llegar a un mínimo de un segmento) y se reduce la velocidad de transmisión, La idea consiste en proporcionar una reducción rápida de tráfico de forma que las pasarelas tengan tiempo de emitir los datagramas que continúan en sus colas.

Para recuperarse cuando acaba la congestión y volver a reestablecer la velocidad de tráfico normal se aplica la siguiente técnica:

• Slow start: siempre que comienza el tráfico en una nueva conexión o que se incrementa después de un periodo de congestión, se inicializa la ventana de congestión al segmento y cada vez que llega un reconocimiento de un paquete que se ha enviado, se incrementa en 1 su tamaño.

Para evitar que la ventana de congestión crezca demasiado en el caso de que no haya congestión en la interred y de lugar a una congestión adicional, el TCP añade una restricción adicional. Una vez que la ventana de congestión alcance la mitad de su tamaño original, se incrementa en 1 solo cuando todos los segmentos de la ventana hayan sido reconocidos. A esto se le denomina fase de evitación de la congestión.

• Establecimiento de la conexión.

Para establecer una conexión, el protocolo de transporte se basa en el Handshake modo 3.

Ejemplo:

- El TCP del transmisor (Estación 1) que desea establecer una conexión transmite un SYN con un número de secuencia x hacia el receptor (Estación 2).

- El receptor (Estación 2) contesta con otro SYN con su número de secuencia Y además de reconocerle el paquete antes recibido indicándole el próximo número de secuencia que espera de la estación 1.

- Por último, el transmisor le reconoce al receptor el número de secuencia Y indicándole que espera el paquete Y+1.

- En este punto la conexión ha quedado establecida la conexión y ya puede comenzar la transmisión de datos en ambos sentidos.

El handshake modo 3 es pera ambas estaciones necesario y suficiente para una correcta sincronización y establecimiento de la conexión. Recordando que TCP trabaja sobre un servicio de entrega de paquetes poco fiable, los mensajes pueden ser perdidos, retrasados, duplicados o entregados en desorden. Por este motivo, y sólo por este, el protocolo debe usar un mecanismo de timeout y retransmitir las peticiones perdidas. De esta forma crecen los problemas ya que las retransmisiones y las peticiones originales pueden llegar en el proceso de establecimiento de la conexión, durante la transmisión de datos o durante la desconexión. Con el Handshake modo 3 estos problemas quedan resueltos ya que durante el establecimiento de la conexión existe un intercambio de números de secuencia entre ambas estaciones.

El handshake modo 3 ofrece dos funciones importantes:

- Garantiza que ambos puntos de conexión están dispuestos para transferir datos.

- Permite que ambos acuerden los números de secuencia iniciales.

• Cierre de la conexión:

El cierre de la conexión sigue un esquema de Handshake modo 3 modificado.

• Proceso de cierre :

- Cuando un datagrama de aplicación termina de transmitir datos, comunica al TCP que cierre la conexión en este sentido (Recordar que la comunicación es full duplex y la otra estación aun puede seguir enviando datos).

- Para cerrar la conexión en un sentido TCP opera del siguiente modo:

Transmite aquellos datos pendientes.

Espera los reconocimientos

Envía un paquete de FIN.

- Aunque haya cerrado la conexión debe seguir enviando los reconocimientos de los paquetes que recibe.

- Cuando la estación remota termine de transmitir datos enviará un FIN y esperará el reconocimiento.

- Finalmente la conexión seda definitivamente cerrada.

• Diferencias entre el proceso de establecimiento y cierre de una conexión:

• Primero se manda el primer FIN.

• Antes del segundo FIN:

• TCP envía un reconocimiento e informa a la aplicación que se van a cerrar las conexiones y que no ha sido por error.

• Se produce un periodo de espera para confirmar el fin pudiendo existir un posible time out.

• Por último cuando el programa de aplicación cierra por fin las peticiones se produce el segundo FIN.

- Se manda el último reconocimiento.

• Reset de una conexión:

Algunas condiciones anormales obligan a que un programa de aplicación o el software de la red rompan una conexión. Por esto, TCP da la facilidad de resetear ante estas condiciones anormales. Para resetear una conexión :

- Un extremo inicia la terminación enviando un segmento con el bit RST activado en el campo CODE.

- El otro extremo responde al reset abortando inmediatamente la conexión.

- El TCP informa al programa de aplicación que se ha producido un reset.

• Definición de reset:

Reset = Aborto inmediato de una conexión.

Esto significa que la transferencia en ambas direcciones cesa inmediatamente y los recursos (buffers etc.)quedan liberados.

• Direccionamiento IP:

El protocolo IP establece un sistema de direcciones que identifica a cada host de forma única. Todos los equipos y dispositivos de comunicaciones en una red TCP/IP han de tener una dirección IP única para poder establecerse la comunicación.

Cada vez que se envía un paquete a la red ésta determina el camino que seguirá hasta su destino.
La dirección IP es un número de 4 bytes (32bits) que se representa como 4 enteros entre 0 y 255.

Cada dirección IP de 4 bytes se divide en dos partes:
Una porción de la red, que identifica la red.
Una porción del Host, que identifica el nodo.

Las direcciones IP se dividen en tres clases según los dos bits más importantes de los cuatro primeros bytes. Esto se hace para que los routers puedan extraer la porción de la red de la dirección de manera eficiente.

A pesar de la clase de dirección, todos los nodos de una red única comparten la misma porción de la red; cada nodo tiene una porción única.

Dirección IP de un host 194.224.78.16

Para facilitar el encaminamiento de los datagramas las direcciones de IP se agrupan en redes. Una red es un grupo de direcciones IP que tienen en común una parte de su dirección. La dirección IP anterior hace referencia al host número 16 de la red 194.224.78.0

Dirección IP de una red 194.224.78.0

Por convenio la dirección de una red se obtiene a partir de los bits que tiene en común todas las direcciones de ella, con los demás bits puestos a cero. Dado que cada dirección IP se compone de 4 números enteros entre 0 y 255, la red comprende todas las direcciones desde 194.224.78.1 hasta 194.224.78.254. El número 0 se reserva para el número de la red y el número 255 es la dirección de difusión de la red, cualquier datagrama enviado a la dirección de difusión será recibido y procesado por todos los hosts de la red.

Existen unas clases de redes predeterminadas:

Red de Clase A 10.0.0.0 16.777.214 Hosts

Red de Clase B 10.88.0.0. 65.534 Hosts

Red de Clase C 10.88.221.0. 254 Hosts

Cada dirección tiene una máscara que se determina en función de la dirección de la red. Para conocer, con exactitud, que parte de la dirección corresponde a la dirección de la red y que parte pertenece a la dirección del host, es necesario ver la máscara.

Dirección Red Máscara Rango Hosts

Red de Clase A 10.0.0.0 255.0.0.0 16.777.214 Hosts

Red de Clase B 144.102.0.0. 255.255.0.0 65.534 Hosts

Red de Clase C 194.224.78.0. 255.255.255.0 254 Hosts

• Direcciones de Clase A

Una dirección IP de la clase A consiste en una porción de la red de un byte seguido por una porción del Host de 3 bytes. El bit de mayor orden del byte de la porción de red se define siempre a 0. Por lo tanto se dispondrán de un total de 126 redes de la Clase A (1 a 126) y con más de 16 millones de nodos por red, (las redes entre 0 y 127 están reservadas) .

Por ejemplo, n = dirección de red y h = dirección de host

Clase A 0nnnnnnn.hhhhhhhh.hhhhhhhh.hhhhhhhh

• Direcciones de Clase B

Una dirección IP de la clase B consiste en una porción de la red de dos bytes seguido por una porción del Host de 2 bytes. Los dos bits de orden superior de la porción de red se definen siempre a 10. Por lo tanto se dispondrán de aproximadamente 16.000 redes de la Clase B (desde 128.x a 191.x) y con más de 65.000 nodos por red.

Por ejemplo, n = dirección de red y h = dirección de host

Clase A 10nnnnnn.nnnnnnnn.hhhhhhhh.hhhhhhhh

• Direcciones de Clase C

Una dirección IP de la clase C consiste en una porción de la red de tres bytes seguido por una porción del Host de 1 bytes. Los tres bits de orden superior de la porción de red se definen siempre a 110. Por lo tanto se dispondrán de aproximadamente 2 millones de redes de la Clase C (desde 192.x.x a 223.x.x) y con 254 nodos por red.

Por ejemplo, n = dirección de red y h = dirección de host

Clase A 10nnnnnn.nnnnnnnn.nnnnnnnn.hhhhhhhh

Existen empresas y grupos de usuarios cuyas necesidades no llegan a los 254 hosts. Para atender las necesidades de estos grupos mas reducidos se crean subredes que segmentan las clases A, B o C.

Dirección Red Máscara 1er Host Ultimo Host

194.224.78.0 255.255.255.0 194.224.78.1 194.224.78.254

194.224.78.128 255.255.255.128 194.224.78.129 194.224.78.254

194.224.78.240 255.255.255.254 194.224.78.241 194.224.78.242

• Direcciones IP Reservadas

Las reglas de direccionamiento IP reservan los siguientes tipos de direcciones IP para propósitos especiales:

• Direcciones de la red: Estas son las direcciones IP en las que la porción del Host está definida por ceros. Por ejemplo la dirección 129.47.0.0 es la dirección o numero de red correspondiente a una red Clase B.

• Direcciones de difusión general: Son direcciones en las que la porción del Host está definida en todos (255). Un paquete con una dirección de difusión general se destina a todos los nodos de la red. Por norma general, ningún nodo tiene asignado una porción del Host formada sólo por unos.

• Direcciones de retorno de bucle. La dirección de la red 127.0.0.0, y todas las direcciones del Host en la red, por ejemplo, 127.0.0.1, son reservadas.

• Direcciones reservadas: Son direcciones en las que la porción de red está formada por ceros o todos (255)

• Creación de subredes:

Una red Internet (en una dirección de la red Internet única) puede dividirse en una o más redes más pequeñas. En la parte inferior están listadas algunas de las razones para dividir la red:

• Usar varios medios. Puede ser imposible, inconveniente o demasiado caro conectar todos los nodos en un medio de la red única cuando estos nodos están demasiado lejos o conectados a un medio diferente.

• Reducir la congestión. El tráfico entre nodos en una red única usa un ancho de banda de la red. Como resultado, se requieren más anchos de banda cuando el usuario tiene más nodos. La división de los nodos en varias redes reduce el número de nodos de la red. Si los nodos de una red de tamaño pequeño se comunican principalmente con otros nodos de la misma red, el nivel de congestión se reduce.

• Reducir el uso del CPU. La reducción del uso de CPU los nodos conectados es similar a la reducción de la congestión. Más nodos en la red causan más difusiones generales en la red. Incluso si una difusión general no se envía a un nodo en particular, cada nodo de una red debe reaccionar ante la misma antes de decidir si debe aceptar o descartarse.

• Aislar una red. La división de una red de mayor tamaño en redes más pequeñas, limita el impacto de uno de los problemas de la red sobre otra. Entre estos problemas se pueden incluir el error de hardware de la red, como una interconexión Ethernet abierta, o errores de software, como una operación de emisión confusa.

• Mejorar el nivel de seguridad. En un medio de red de difusión general como es Ethernet, cada nodo de una red tiene acceso a todos los paquetes enviados a la misma. Si se permite sólo un tráfico de red sensitivo en una red, otros monitores de red pueden evitar el acceso a éste tipo de tráfico.

• Hacer uso eficiente del espacio de la dirección IP. Si está asignando un número de red Clase A o B y tiene varias redes físicas pequeñas, puede dividir el espacio de dirección IP en varias subredes IP y asignarles redes físicas individuales. Con el uso de este método, no necesita conseguir más números de redes IP por cada red física.

• Máscaras y direcciones de subredes:

Cada subred funciona como si fuera una red independiente. Para redes remotas, sin embargo, las subredes aparecen colectivamente como redes discretas y únicas. Esto significa que la red local sólo necesita una dirección de red IP y estas redes remotas no necesitan poner atención en la ubicación de un nodo en una subred particular.

La comunicación entre un nodo en una subred local y un nodo en una subred diferente es parecida a la comunicación entre nodos de dos redes diferentes. Para un usuario, el encaminamiento entre subredes es transparente. Internamente, el software IP reconoce cualquier dirección IP que esté destinada a una subred y envía estos paquetes al router de la misma.

Al igual que en la comunicación entre redes, la información del encaminamiento para la comunicación de la subred entre subredes se mantiene en la tabla de encaminamiento (por IP) para cada nodo o router. Sin embargo, en el caso de las subredes, dicha información está formada por la dirección de la red y la dirección de la subred.

Cuando una red se distribuye en varias subredes, la porción del Host de la dirección IP se divide en dos partes, al igual que la dirección IP se divide en dos partes (4 bytes en total). La porción de la dirección del Host especifica la subred de la red IP y el nodo de dicha subred.

Por ejemplo, si una red tiene la porción de la dirección de la red Clase B 129.47, el resto de dicha dirección se puede dividir en direcciones de subred y del Host. Esta división está controlada por la red

local a fin de obtener una mayor flexibilidad en el funcionamiento de la red a nivel local. Por ejemplo, la

dirección de subred puede contener cuatro bits de los dos bytes restantes. Esto permite 15 subredes, cada una con 4094 nodos. En otro ejemplo, la dirección de la subred puede contener ocho bits, lo que permite usar 254 subredes (una dirección de subred de todos los unos no es válida), cada una con 254 nodos.

Una máscara de subredes indica cómo se divide la porción del Host de una dirección IP en direcciones de subredes y porciones de dirección del Host local. La máscara de la red está representada por un número de 32 bits en el que las porciones de dirección de red y subred están formadas por una dirección IP completa y todas las del Host por ceros. Por ejemplo, con una porción de la dirección de la red IP de Clase B de 129.47 y una dirección de la subred de 4 bits, la máscara de subred constará de 20 unos y 12 ceros. En resumen, una máscara de subred amplía la porción de la dirección de la red de una dirección IP local. La siguiente figura muestra ejemplos de direcciones de redes IP, la relación con la máscara de subred y con la correspondiente subred.

• Protocolo DNS (Servicio de Nombres de Dominio).

El servicio de nombres de dominios es un servicio de directorios basado en una base de datos distribuida.

La función básica del servicio de nombres de dominios es la de facilitar el acceso a los recursos y servicios de Internet a través de nombres fácilmente recordables, en lugar de direcciones numéricas. Establece además un nivel de dirección que permite cambiar servicios de una máquina a otra o distribuir la carga de acceso a varios servidores sin necesidad de redistribuir o cambiar la dirección numérica.

• Protocolo UDP (User Datagram Protocol):

El protocolo IP proporciona tres definiciones muy importantes:

• Define la unidad básica para la transferencia de datos utilizada a través de una red TCP/IP

• Realiza la función de ruteo, indicando por donde deben ser enviados los datos.

• Incluye un conjunto de reglas que define cuando los paquetes enviados por la red deben ser descartados. Define las condiciones de error en el envío y recepción de paquetes.

DATOS

La unidad de datos en TCP/IP se denomina datagrama y consta de un encabezado y de un área de datos. La cabecera del datagrama lleva una serie de datos como son las direcciones IP del emisor como del receptor, así como unos indicadores de tipo de servicio, protocolo y tiempo de vida. La red física trata al datagrama como si fuera un dato incluyendo la cabecera dentro de la parte de datos de la trama.

TCP/IP por lo tanto es capaz de transmitir datagramas IP entre hosts, donde cada datagrama es enviado a través de la red, basándose en la dirección IP del destino. En el Protocolo Internet, una dirección hace referencia a un host, pero no hace ninguna distinción respecto a que usuario o que aplicación recibirá el datagrama. El protocolo UDP es el que se encarga de distinguir entre los diferentes destinos que un datagrama puede tener en un mismo host, permitiendo a varias aplicaciones que se ejecutan en una misma computadora envíen y reciban datagramas de forma independientes. El UDP proporciona puertos de protocolos utilizados para distinguir a que aplicación se dirige un datagrama.

• Protocolo TCP (Transmision Control Protocol):

El protocolo de control de transmisión especifica el formato de los datos y los acuse de recibo que intercambian dos computadoras para lograr una transferencia confiable, así como los procedimientos que la computadora utiliza para asegurarse que los datos llegan de una manera correcta. Al mismo tiempo especifica como el software distingue el destino correcto dentro de los posibles destinos dentro de una misma máquina. También especifica cómo dos computadoras inician una transferencia de flujo TCP y como se ponen de acuerdo cuando se completa.

• Protocolo ARP y RARP (Adressing Resolution Protocol / Reverse Adressing Resolution Protocol)

El protocolo de asociación de direcciones ARP se encarga de convertir las direcciones IP de 32 bits en direcciones físicas, éste proporciona un mecanismo razonablemente eficaz y fácil de mantener. El mecanismo es el siguiente, cuando una estación A quiere conectar con una estación B con dirección IP BIP, esta emite por difusión un paquete especial que pide a B que responda con su dirección física BFS. Todas las estaciones incluyendo a B reciben la solicitud pero sólo B reconoce su propia IP y envía una respuesta que contiene su dirección física. Cuando A recibe la respuesta utiliza la dirección física para enviar el datagrama directamente a B.

RARP es el protocolo inverso de asociación de direcciones, se usa con el fin de que los dispositivos sin dirección asignada puedan obtenerla de un servidor de direcciones de la red. El proceso es similar al del protocolo ARP, sólo que en este caso se recibe respuesta de todos los servidores RARP, aunque sólo se necesite una contestación. La principal ventaja de tener más de un servidor RARP en una red es la de hacer el sistema más confiable, ya que si uno falla siempre puede activarse otro para dar este servicio. El inconveniente de tener varios servidores RARP en una red es que cuando se produce las respuestas a una petición RARP se sobrecarga la red con las respuestas de los servidores.

• Protocolo SNMP (Simple Network Management Protocol):

El protocolo SNMP tiene como función el proporcionar a los administradores de la red, las herramientas necesarias para depurar problemas, controlar rutas y localizar computadoras que no cumplan los protocolos.

En una red TCP/IP, los routers son los conmutadores activos que los administradores necesitan para las funciones de revisión y control. Dado que los routers conectan redes heterogéneas, los protocolos para la administración de red operan en el nivel de aplicación y se comunican mediante los protocolos de nivel de transporte del TCP/IP. Un Router con administración debe conservar el control y los estados de información que el administrador puede necesitar. Por ejemplo mantiene estadísticas del estado de sus puertos de red, del tráfico que entra y sale, de los datagramas eliminados y de los mensajes de error generados. Aún cuando permite al administrador acceder a estas estadísticas, SNMP no especifica qué datos se pueden acceder. Un estándar fuera de SNMP es el que especifica los detalles. Conocido como Management Information Base (MIB), es el estándar que especifica los elementos de los datos de que un host o un router deben conservar y las operaciones permitidas en cada uno.

• Aplicaciones TCP/IP, servicios en Internet :

• Puertos

Cada host en internet tiene una dirección única, esto significa, que todos los usuarios que desean conectar con un determinado ordenador han de dirigirse a la misma dirección. Dado el gran número de usuarios conectados a Internet, es probable que cualquier host con un servicio popular sea accedido por múltiples usuarios de forma simultánea. También es frecuente encontrar que un solo ordenador con una dirección IP se hace responsable de diversas tareas o servicios como Correo Electrónico, Servicio de Páginas Web, Servicio de transferencia de Ficheros, etc. Necesitamos un método para distinguir los flujos de información de cada tarea, usuario y servicio. Para este fin se ha definido el puerto en la especificación del protocolo TCP.

Cada servicio como Web, Correo, FTP, o DNS, tiene un puerto asignado. Cada comunicación con una dirección IP de dirige al puerto predeterminado en función de la aplicación.

Protocolo Puerto Por Defecto

FTP 21

SMTP 25

HTTP 80

POP 110

Si deseamos establecer una sesión de transferencia de ficheros, a través de protocolo FTP nuestro programa ha de dirigirse al puerto 21.

• Correo Electrónico

El correo electrónico, es un sistema que permite la transmisión e intercambio de mensajes en un formato informatizado.

Cada receptor de correo tiene una dirección única que le identifica en la red. Conociendo su dirección cualquier usuario de Internet en cualquier parte del mundo puede enviar un mensaje con la misma facilidad que envía un mensaje a otro usuario en su red local. Las direcciones de correo electrónico están divididas en dos partes separadas por el carácter arroba "@":

Identificación de usuario Nombre Internet del servicio de correo electrónico para el dominio

“eya swin.net”

• SMTP

EL protocolo SMTP es el estándar para la distribución de correo electrónico en Internet. Es un protocolo orientado a texto que utiliza los servicios de TCP/IP para recibir correo desde un cliente y para transferir mensajes desde un servidor a otro de forma fiable.

Si un mensaje va destinado a varios receptores en un servidor de correo, el emisor enviará un solo mensaje al servidor de destino. Al recibir un mensaje de correo el servidor SMTP hace una copia de este para cada destinatario en la lista de distribución.

• POP

El Protocolo de Oficina Postal define el diálogo entre un servidor de correo y la aplicación de correo electrónico. Al recibir los mensajes el servidor de correo los almacena en buzones privados para cada usuario. POP permite que un Agente de Usuario (UA) acceda al buzón, descargue todos los mensajes pendientes y después borrarlos.

• HTTP

El protocolo de transferencia de Hipertexto es el pegamento que une el World Wide Web. El servicio HTTP en un host permite que usuarios a distancia puedan acceder a los ficheros que almacena si éstos conocen su dirección exacta. El protocolo HTTP define un sistema de direcciones basado en Localizadores Uniformes de Recursos (URL). El URL de un recurso indica el protocolo o servicio que se emplea para ser accedido, la dirección del host donde se encuentra el recurso, y la ubicación del recurso dentro del host. Por ejemplo:

La información hypertexto se almacena en formato HTML. Se refiere a cada fichero como "página". El "Browser" es el programa de usuario que conecta con el servidor mediante HTTP e interpreta la página HTML antes de mostrarla al usuario.

• FTP

FTP es el protocolo de transferencia de fichero de TCP/IP, permite tanto enviar como recibir ficheros desde o hacia un servidor FTP. Las principales características de FTP son:

• El acceso interactivo: mediante el cual se puede solicitar al servidor un listado de ficheros.

• Especificación del formato de los ficheros almacenados

• Control de autentificación.

• TELNET

El conjunto de protocolos TCP/IP incluye un protocolo de terminal remoto sencillo, llamado TELNET, el cual permite a un usuario establecer una conexión TCP con un servidor de acceso a otro. TELNET transfiere después las pulsaciones de teclado directamente desde el teclado del usuario a la computadora remota como si hubieran sido hechos en un teclado unido a la máquina remota.

Modelo de referencia OSI Suite o Conjunto de protocolos TCP/IP

Físico

Enlace de datos

Red

Transporte

Sesión

Presentación

Aplicación

Paq 1

Adc 1

Paq 2

Adc 2

Receptor

Emisor

Paq 1

Paq 2

Adc 1

Paq 3

Se libera buffer 1

Adc 2

Adc 3

Se libera buffer 2

Se libera buffer 3

Paq 1

Paq 1

Adc 1

Adc 1

Paq 1

Adc 1

Paq 1

Receptor

Emisor

Paq 1

Paq 1

Esperado 2

Paq 2

Esperado 3

Receptor

Emisor

Paq 3

Paq 2

Paq 1

Paq 2

Paq 1

Ack 1

Ack 2

Ack 1

Paq 2

Paq 1

Paq 3

Paq 4

Paq 1

Ack 1

Paq 2

Paq 1

Paq 2

Ack 1

Send SYN seq=x

Receive SYN segment

Send SYN seq=y, ACK x+1

Receive SYN + ACK segment

Send ACK Y+1

Receive ACK segment

Receive FIN segment

Send ack x+1

Send FIN seq=x

Receive ACK segment

Send FIN, ACK x+1

Receive FIN +ACK segment

Send ACK y+1

Receive ACK segment

Datos útiles

Cabecera

7

3

4

6

5

Host de origen

Host de destino

Aplicación

Aplicación

Mensajes

o flujos

Transporte

Transporte

Datagramas

(UPD) o

segmentos (TCP)

Internet

Internet

Datagramas IP

Interfaz de red

Interfaz de red

Tramas de red

Hardware de red

Información de dirección y control

de flujo