Servicios de red

1. IBM Tivoli NetView
Página: 14/92
Información confidencial - propiedad intelectual de
5 Aplicación
Ej. HTTP, FTP, DNS
(protocolos de enrutamiento como BGP y RIP, que por varias
razones funcionen sobre TCP y UDP respectivamente, son
considerados parte del nivel de red)
4 Transporte
Ej. TCP, UDP, RTP, SCTP
(protocolos de enrutamiento como OSPF, que funcionen
sobre IP, son considerados parte del nivel de red)
3 Interred
Para TCP/IP este es el Protocolo de Internet (IP)
(protocolos requeridos como ICMP e IGMP funcionan sobre
IP, pero todavía se pueden considerar parte del nivel de red;
ARP no funciona sobre IP
2 Enlace Ej. Ethernet, Token Ring, etc.
1 Físico Ej. medio físico, y técnicas de codificación, T1, E1
Fig. 2. 1 Capas del modelo TCP/IP
El nivel Físico
El nivel físico describe las características físicas de la comunicación, como las convenciones
sobre la naturaleza del medio usado para la comunicación (como las comunicaciones por
cable, fibra óptica o radio), y todo lo relativo a los detalles como los conectores, código de
canales y modulación, potencias de señal, longitudes de onda, sincronización y
temporización y distancias máximas. La familia de protocolos de Internet no cubre el nivel
físico de ninguna red.
El nivel de Enlace de datos
El nivel de enlace de datos especifica como son transportados los paquetes sobre el nivel
físico, incluido los delimitadores (patrones de bits concretos que marcan el comienzo y el fin
de cada trama). Ethernet, por ejemplo, incluye campos en la cabecera de la trama que
especifican que máquina o máquinas de la red son las destinatarias de la trama. Ejemplos de
protocolos de nivel de enlace de datos son Ethernet, Wireless Ethernet, SLIP, Token Ring y
ATM.
PPP es un poco más complejo y originalmente fue diseñado como un protocolo separado
que funcionaba sobre otro nivel de enlace, HDLC/SDLC.
Este nivel es a veces subdividido en Control de enlace lógico (Logical Link Control) y Control
de acceso al medio (Media Access Control)....
El nivel de Interred

2. IBM Tivoli NetView
Página: 15/92
Información confidencial - propiedad intelectual de Grupo
Como fue definido originalmente, el nivel de red soluciona el problema de conseguir
transportar paquetes a través de una red sencilla. Ejemplos de protocolos son X.25 y
Host/IMP Protocol de ARPANET.
Con la llegada del concepto de Interred, nuevas funcionalidades fueron añadidas a este nivel,
basadas en el intercambio de datos entre una red origen y una red destino. Generalmente
esto incluye un enrutamiento de paquetes a través de una red de redes, conocidada como
Internet.
El nivel de Transporte
Los protocolos del nivel de transporte pueden solucionar problemas como la fiabilidad y la
seguridad de que los datos llegan en el orden correcto. En el conjunto de protocolos TCP/IP,
los protocolos de transporte también determinan a que aplicación van destinados los datos.
Los protocolos de enrutamiento dinámico que técnicamente encajan en el conjunto de
protocolos TCP/IP (ya que funcionan sobre IP) son generalmente considerados parte del
nivel de red; un ejemplo es OSPF (protocolo IP número 89).
Esta es una de las principales diferencias con UDP, y puede convertirse en una desventaja
en flujos en tiempo real (muy sensibles a la variación del retardo) o aplicaciones de
enrutamiento con porcentajes altos de pérdida en el nivel de interred.
UDP (protocolo IP número 17) es un protocolo de datagramas sin conexión. Es un protocolo
no fiable (best effort al igual que IP) - no porque sea particularmente malo, sino porque no
verifica que los paquetes lleguen a su destino, y no da garantías de que lleguen en orden. Si
una aplicación requiere estas características, debe llevarlas a cabo por sí misma o usar TCP.
UDP es usado normalmente para aplicaciones de streaming (audio, video, etc) donde la
llegada a tiempo de los paquetes es más importante que la fiabilidad, o para aplicaciones
simples de tipo petición/respuesta como el servicio DNS, donde la sobrecarga de las
cabeceras que aportan la fiabilidad es desproporcionada para el tamaño de los paquetes.
El nivel de Aplicación
El nivel de aplicación es el nivel que los programas más comunes utilizan para comunicarse
a través de una red con otros programas. Los procesos que acontecen en este nivel son
aplicaciones específicas que pasan los datos al nivel de aplicación en el formato que
internamente use el programa y es codificado de acuerdo con un protocolo estándar.
Algunos programas específicos se considera que se ejecutan en este nivel. Proporcionan
servicios que directamente trabajan con las aplicaciones de usuario. Estos programas y sus
correspondientes protocolos incluyen a HTTP (HyperText Transfer Protocol), FTP
(Transferencia de archivos), SMTP (correo electrónico), SSH (login remoto seguro), DNS
(Resolución de nombres de dominio) y a muchos otros.
Una vez que los datos de la aplicación han sido codificados en un protocolo estándar del
nivel de aplicación son pasados hacia abajo al siguiente nivel de la pila de protocolos TCP/IP.

3. IBM Tivoli NetView
Página: 16/92
Información confidencial - propiedad intelectual de
En el nivel de transporte, las aplicaciones normalmente hacen uso de TCP y UDP, y son
habitualmente asociados a un número de puerto bien conocido (well-known port). Los
puertos fueron asignados originalmente por la IANA.
2.3 FIABILIDAD
¿Cómo es posible enviar información fiable basándose en un protocolo no fiable? Es decir, si
los datagramas que transportan los segmentos TCP se pueden perder, ¿cómo pueden llegar
los datos de las aplicaciones de forma correcta al destino?
La respuesta a esta pregunta es sencilla: cada vez que llega un mensaje se devuelve una
confirmación (acknowledgement) para que el emisor sepa que ha llegado correctamente. Si
no le llega esta confirmación pasado un cierto tiempo, el emisor reenvía el mensaje.
Veamos a continuación la manera más sencilla (aunque ineficiente) de proporcionar una
comunicación fiable. El emisor envía un dato, arranca su temporizador y espera su
confirmación (ACK). Si recibe su ACK antes de agotar el temporizador, envía el siguiente
dato. Si se agota el temporizador antes de recibir el ACK, reenvía el mensaje. Los siguientes
esquemas representan este comportamiento:
Fig. 2. 2 Esquema de Comunicación 1

4. IBM Tivoli NetView
Página: 17/92
Información confidencial - propiedad intelectual de Grupo
Fig. 2. 3 Esquema de Comunicación 2
Este esquema es perfectamente válido aunque muy ineficiente debido a que sólo se utiliza
un sentido de la comunicación a la vez y el canal está desaprovechado la mayor parte del
tiempo. Para solucionar este problema se utiliza un protocolo de ventana deslizante, que se
resume en el siguiente esquema. Los mensajes y las confirmaciones van numerados y el
emisor puede enviar más de un mensaje antes de haber recibido todas las confirmaciones
anteriores.
2.4 CONEXIONES
Una conexión son dos pares dirección IP:puerto. No puede haber dos conexiones iguales en
un mismo instante en toda la Red. Aunque bien es posible que un mismo ordenador tenga
dos conexiones distintas y simultáneas utilizando un mismo puerto. El protocolo TCP utiliza el
concepto de conexión para identificar las transmisiones. En el siguiente ejemplo se han
creado tres conexiones. Las dos primeras son al mismo servidor Web (puerto 80) y la tercera
a un servidor de FTP (puerto 21).

5. IBM Tivoli NetView
Página: 18/92
Información confidencial - propiedad intelectual de
Fig. 2. 4 Apertura pasiva y Activa
Para que se pueda crear una conexión, el extremo del servidor debe hacer una apertura
pasiva del puerto (escuchar su puerto y quedar a la espera de conexiones) y el cliente, una
apertura activa en el puerto del servidor (conectarse con el puerto de un determinado
servidor).
2.5 FORMATO DEL SEGMENTO TCP
Ya hemos comentado que el flujo de bytes que produce una determinada aplicación se divide
en uno o más segmentos TCP para su transmisión. Cada uno de estos segmentos viaja en el
campo de datos de un datagrama IP. Para facilitar el control de flujo de la información los
bytes de la aplicación se numeran. De esta manera, cada segmento indica en su cabecera el
primer byte que transporta. Las confirmaciones o acuses de recibo (ACK) representan el
siguiente byte que se espera recibir (y no el número de segmento recibido, ya que éste no
existe).
0 10 20 30
0 1 2 3 4 5 6 7 8 9 0 1 2 3 3 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Puerto TCP origen Puerto TCP destino
Número de secuencia
Número de acuse de recibo
HLEN Reservado Bits código Ventana
Suma de verificación Puntero de urgencia
Opciones (si las hay) Relleno
Datos
...
Fig. 2. 5 Formato de Trama de TCP