Redes y Comunicaciones - Exámen final

Capítulo 1 - Redes de computadoras e internet.

Una red es un conjunto de dispositivos interconectados entre sí, a fin de poder establecer
comunicaciones entre ellos. El objetivo de lograr esta comunicación, es poder compartir
recursos, información y servicios. Estos beneficios que traen las redes permiten, en muchos
casos, una importante reducción de tiempo (por ejemplo, podemos comparar el sistema de
correo electrónico con el envío de cartas tradicional), como así también mayor confianza en
que las acciones solicitadas se podrán llevar a cabo.

Básicamente podemos decir que los componentes básicos de un sistema de información

son:

- Fuente (Software).
- Emisor/Transmisor (Hardware).
- Medio de transmisión y dispositivos intermedios (Hardware).
- Procesos intermedios que tratan la información (Software y Hardware).
- Receptor (Hardware).
- Destino (Software).
- Otros: Protocolos (Software), Información, mensaje transmitido (Software).
- Señal de Información, materialización del mensaje sobre el medio (Hardware).

¿Qué es Internet? (Sección 1.1 del libro)

Internet es la red de dispositivos interconectados mas grande que existe actualmente. Su

nombre proviene de las palabras “redes interconectadas”, lo cual nos dice mucho. Es
pública y descentralizada, y actualmente sigue el modelo “TCP/IP”. Los dispositivos
interconectados gracias a la red se conocen como “host”, los cuales normalmente no se
conectan directamente entre sí, sino que normalmente se usa algún tipo de dispositivo para
este fin. La tasa de transmisión se denomina “ancho de banda” y se mide en bits por
segundo.

Básicamente, cuando dos procesos que corren en distintos dispositivos quieren

comunicarse entre sí, la información fluye desde un host a otro. El camino que hace la
información entre los dos host normalmente se llama “ruta”. (Una aclaración importante es
que los procesos que corren en el mismo equipo y quieren comunicarse entre sí, usan
funciones del sistema operativo del dispositivo en cuestión).

Internet usa el método de comunicación “conmutación de paquetes”, en lugar de la otra

opción conocida como “conmutación de circuitos”.

Acceso residencial a la red

Cuando un usuario quiere tener acceso a internet, normalmente contacta a un ISP (Internet
Service Provider). Estos proveedores de internet suelen entregar Módems, el cual es un
aparato que convierte señales digitales que salen de la computadora a analógicas,
permitiendo el uso de redes telefónicas o de cable para lograr comunicación entre
dispositivos.

Hay dos tipos de acceso residencial a banda ancha: Línea de suscriptor digital (DSL) y
Cable híbrido de fibra y coaxial (HFC).

DLS es un servicio que usa el cableado telefónico, que básicamente nos brinda un canal de
subida de datos, un canal de bajada de datos, y el propio servicio telefónico. Ofrece un
canal punto a punto entre el módem y el ISP, y por ende su velocidad no se ve afectada por
otros usuarios de la red.

HFC es un servicio extensión al de televisión por cable. Normalmente ofrecen mayor

velocidad que las tecnologías DSL, aunque en este caso el canal por el que viaja la
información es compartido. Esto quiere decir que si muchos usuarios del servicio están, por
ejemplo, descargado archivos MP3, la red va a responder mas lento. Pasa lo mismo en el
canal de subida. La razón de la baja de velocidad es las colisiones que se van a dar entre
los distintos paquetes que viajan por la red.

De forma general, los medios de acceso a internet son:

- Satelital: usan antenas parabólicas que captan la señal de satélites de
comunicación.
- Cable: usado por compañías que ofrecen teléfono y televisión.
- Eléctrica: usa la red eléctrica.
- ADSL: usa cable de cobre tradicional para proporcionar canales de subida,
recepción de datos, y un canal de voz.
- Banda ancha móvil: internet sin cable, como 3G o 4G.

Conmutación de paquetes - Conmutación de circuitos.

La conmutación de paquetes es una técnica en la cual, los distintos paquetes que viajan
desde un host emisor a un destino no tienen porqué seguir una misma ruta. Cada paquete
va a tener información de origen y destino (entre otras cosas), la cual es usada por cada
dispositivo de la red para poder guiar el paquete hacia su destino final.
En esta técnica, el camino no está reservado para una única comunicación entre host (a
diferencia de conmutación de circuitos), lo cual permite que el camino sea usado mas
eficientemente, y el procesamiento que debe hacer cada dispositivo de la red para decidir
qué camino debe seguir la información influye en la performance de la comunicación. Por
esta razón, este tipo de técnica no es la ideal para servicios que requieren comunicación en
tiempo real, como videoconferencias o llamadas telefónicas.
Sin embargo, como ventaja tenemos que esta técnica responde mejor a problemas en el
canal de comunicación, simplemente derivando los paquetes en otra dirección hacia su
destino final.

La conmutación de circuitos por su parte es una técnica que se basa en la reserva de canal
entre dispositivos origen y destino. De esta forma, se establece una comunicación previa al
envío del primer “trozo” de información, para que todos los dispositivos intermedios se
pongan “de acuerdo” respecto a la ruta que va a seguir la información. Con el canal
reservado, la información fluye más rápidamente, beneficiando a las aplicaciones de tiempo
real, porque se reduce el retardo en cada nodo de la red. Sin embargo, el camino no está
aprovechado en todo momento, y al tener una ruta en específico, es mas difícil responder a
problemas como caída de algún nodo.

¿Que es un protocolo? (Sección 1.1.3 del libro)

Un protocolo especifica un conjunto de reglas que los participantes de la comunicación

deben entender y respetar, para que la comunicación se pueda llevar a cabo. Podemos
decir que lo que se busca es “hablar el mismo idioma”.

Un protocolo nos puede especificar el tamaño máximo de información que se puede enviar
por vez, el orden de los mensajes intercambiados, la sintaxis y semántica de cada mensaje,
y otras ventajas como por ejemplo control de errores, control de congestión.

Los distintos protocolos están implementados en las distintas componentes que forman
parte de una comunicación.

Las computadoras que ejecutan distintos sistemas operativos pueden comunicarse entre sí
porque siguen los mismos protocolos.

RFC - Request For Comments

Son documentos técnicos, en donde se definen protocolos, conceptos, métodos y

programas de internet. Todo RFC tiene asociado un número determinado y un título, y no
existen “nuevas versiones de un RFC”, sino que se crean nuevos documentos (con una
nueva numeración), que dejan obsoletos a anteriores.
Muchos RFC han llegado a ser estándares de internet. Otros son ampliamente usados, pero
no han llegado a ser estándares dado que normalmente los escritores de RFC no se
esfuerzan por estandarizarlos, sino que buscan un continuo desarrollo de nuevas ideas.

Protocolos de red propietarios

En el comienzo de las redes, distintas empresas y universidades habían diseñado sus

propias redes, para las cuales, los hosts que formaban parte de ellas, tenían que respetar
una serie de “reglas” (protocolos) que permitiría que se comuniquen entre sí.
Si bien esto trajo importantes ventajas (básicamente cumplian los objetivos básicos de las
redes anteriormente descritos), pronto empezó a existir la necesidad de que las distintas
redes se puedan comunicar entre sí. Por ejemplo, las grandes empresas, con sucursales en
distintos puntos geográficos, comenzaron a necesitar que todas sus computadoras tengan
la posibilidad de comunicarse.

Esto dió como resultado que las redes se empiecen a interconectar entre sí. Sin embargo,
este fue un punto de conflicto, y punto clave finalmente para el desarrollo de internet: las
redes de distintas empresas o universidades no eran compatibles entre sí, lo cual llevó a
pensar en la idea de especificar protocolos en común, que todo aquel que quiera acceder a
la red deba respetar.

Modelos basados en capas

La gran cantidad de componentes de una red genera complejidad, y se requieren modelos
de organización: Layering. El modelo en capas se propuso inicialmente como un modelo
teórico, que traería las siguientes ventanas:

- Reduce la complejidad, dividiéndola en componentes reusables.

- Mayor facilidad para implementar cambios, debido a que las distintas capas se
comunican entre sí en puntos clave (interfaces). Si una capa A sufre modificaciones,
pero su interfaz no cambia, el resto de las capas no va a enterarse de ningún cambio
y por ende, no tendrá que realizar ninguna modificación.
- Es mas fácil de aprender, y mas fácil de enseñar, gracias a su organización.
- Las capas de arriba usan servicios de las de arriba.
- Las capas de abajo ocultan la complejidad: abstracción.
- Facilita el crecimiento de la red, asegurando interoperabilidad entre los
componentes.

La idea básica es que una capa X que

funciona en un dispositivo, se pueda
comunicar con la misma capa X que corre en
otro dispositivo, los cuales tienen aplicaciones
que se comunican entre sí. A esto se llama
“Comunicación entre capas peer-to-peer”.

El modelo OSI

Fue el primer modelo en capas

ampliamente conocido. Se presentó
como un modelo teórico, aunque hay
implementaciones. Gracias al modelo
OSI, fue posible que host creados por
distintas compañías se pueden
comunicar.
La idea básica es que haya una división
en capas, donde cada capa tiene
asociado un conjunto de protocolos, los
cuales por supuesto, todo dispositivo de
red que implemente dicha capa, tiene
que conocer.

El modelo TCP/IP
Es el modelo en capas que se usa actualmente en internet. Está basado en el modelo OSI y
por ende, cada capa tiene asociado un conjunto de protocolos y tiene una función
específica, tal como se describe en el modelo OSI.

Los modelos TCP/IP y OSI presentan una serie de similitudes y diferencias:

- Si bien ambos se dividen en capas, el modelo TCP/IP combina a la “Capa de

aplicación”, “Capa de presentación” y “Capa de sesión” en su propia “Capa de
aplicación”. Por ende, el funcionamiento de ambas es muy distinto.
- Ambos modelos tienen capa de transporte y capa de red, aunque en TCP/IP, el
equivalente a “Capa de red” se llama “Capa de internet”.
- La idea de ambos es usar conmutación de paquetes.

P2P

Es un tipo de arquitectura en el que los distintos dispositivos que desean comunicarse no

requieren de un servidor central. La idea es que los equipos se puedan comunicar entre sí.
“P2P” es una tecnología asociada arquitectura de aplicaciones, y no a funcionamiento de
aplicaciones en si. Sin embargo, a veces se la llama “intercambio de archivos”, ya que es el
tipo de aplicación que mas ampliamente usa este tipo de comunicación. También se usa en
tecnologías como por ejemplo Skype.

Su ventaja principal es su buena performance, debido a que la comunicación es directa

entre dos puntos, en lugar de centralizar el tráfico de la red en servidores que puedan verse
sobrecargados por la cantidad de solicitudes y responder con lentitud.

Clasificación de redes

Las redes se pueden clasificar por cobertura, abiertas o privadas, topología física, medio de
conexión, entre otros.

Clasificación por cobertura:

 - Red de área local (LAN): son redes relativamente pequeñas, que se usan para
conectar equipos que comparten un mismo lugar físico, por ejemplo una casa o un
edificio.
- Red de área metropolitana (MAN): son redes de un tamaño mayor al anterior, pero
también tienen tamaño limitado. Por ejemplo, se puede usar para interconectar
diferentes redes LAN de distintos edificios de una misma empresa, en una misma
ciudad.
- Red de área amplia (WAN): redes de área geográfica extensa.
- Red de almacenamiento (SAN): se usa para interconectar servidores, redes de
discos, etc. La idea es no afectar las redes que usan los usuarios.
- Redes de área personal (PAN): se usa para que una persona pueda comunicarse
con dispositivos cercanos. Un ejemplo clásico es el bluetooth.

Clasificación por abierta o privada:

- Internet: es una red pública global.

- Intranet: red privada que usa tecnología de Internet.
- Extranet: red privada virtualizada sobre enlaces WAN. Un buen ejemplo es VPN
(Virtual Private Network).

Clasificación por topología física:

- Red conmutadora de circuitos.

- Red conmutadora de paquetes.

Clasificación por medio de conexión:

- Servicios orientados a la conexión. Por ejemplo “circuitos virtuales”.

- Servicios no orientados a la conexión. Por ejemplo “red de datagramas”.

Capítulo 2 - Capa de aplicación

La capa de aplicación es la primera capa del protocolo TCP/IP (de arriba hacia abajo), o
también llamada “capa 5”. Su función es brindar a las aplicaciones (de usuario o no) la
posibilidad de acceder a los servicios de la red, comunicándose con las demás capas y
usando sus servicios para tal fin. La capa de aplicación dispone de una serie de protocolos
ampliamente usados, como son HTTP, DNS, protocolos de correo electrónico, entre otros.
Es importante aclarar que los usuarios de aplicaciones no interactúan directamente con el
nivel de aplicación, sino que es la propia aplicación la que interactúa con los servicios de
esta capa.

Cada protocolo de capa de aplicación ofrece distintos servicios, que pueden tomarse como
parte de las aplicaciones que los utilizan.
El desarrollo de aplicaciones de red implica escribir programas que se ejecuten en distintas
máquinas pero que puedan comunicarse entre sí para resolver un problema.

La arquitectura mas ampliamente usada es la “Cliente - Servidor”. En esta arquitectura

tenemos dos procesos: un cliente activo y un servidor pasivo. El cliente le hará solicitudes a
un servidor, que deberá estar disponible para resolver las solicitudes. Dicho de otra manera,
el servidor actúa bajo demanda del cliente. Un servidor puede atender solicitudes de
múltiples clientes.

Procesos que se comunican a través de la red

Es importante notar, que en un host puede haber múltiples aplicaciones que tienen la
necesidad de comunicarse con procesos que corren en otras máquinas. Para esto, cada
proceso que tiene la posibilidad de usar la red va a tener asignados “Sockets”. Los sockets
pueden verse como puertas a través de las cuales, las aplicaciones envían y reciben
información. Por ejemplo, una aplicación que desea enviar información a la red, deja dicha
información en su socket, y confía en la infraestructura del otro lado, la cual se debería
encargar de transportar dicha información hasta su destino.

Un socket es también conocido como API (Interfaz de programación de aplicaciones), ya

que es una interfaz entre las aplicaciones y la red (específicamente, es una interfaz entre la
Capa de Aplicación y la Capa de Transporte). Del lado del programador, se pueden elegir
protocolos y se pueden establecer parámetros.

El direccionamiento entre procesos se da gracias a que los equipos en los que corren los
procesos están identificados con una dirección IP, la cual es una dirección que identifica
unívocamente un dispositivo en la red. Sin embargo, como fue dicho antes, podríamos tener
varios procesos corriendo en la misma máquina. Para esto es que se usan los números de
puerto, con los cuales finalmente se identifican los sockets.

Agente de usuario

Un agente de usuario es un agente de software que se encarga de brindar servicios a los

usuarios, y resolver sus solicitudes. Podemos decir que es una interfaz entre el usuario y la
aplicación de red. Un ejemplo clásico de agente de usuario es un navegador web.

Servicios que necesita una aplicación

Las aplicaciones suelen necesitar de ciertos servicios básicos, aunque algunas necesitan
más servicios que otras. Básicamente podemos hablar de:

- Entrega fiable: el servicio debería poder garantizar que la información enviada llegue
a destino, completa y sin errores. Las aplicaciones de tiempo real suelen tolerar
cierta pérdida, ya que, por ejemplo, no es relevante para una aplicación de
videoconferencias retransmitir un píxel de una imagen que ya se mostró y
lógicamente no se volverá a mostrar.
- Ancho de banda: se refiere a que un servicios brinde un mínimo de ancho de banda.
Las aplicaciones mas exigentes en este aspecto suelen ser las de tiempo real.
 - Temporización: las aplicaciones deberían brindar su servicio en el menor tiempo
posible. Otra vez, las aplicaciones de tiempo real son las mas exigentes, dado que
requieren que la información fluya rápidamente y poder ser reflejadas en el equipo
destino casi instantáneamente.
- Seguridad: cuestiones de cifrado de información, para asegurar que ningún agente
malintencionado capte e interprete la información. También se puede necesitar
autenticación.

Servicios proporcionados por la capa de transporte

La capa de transporte tiene dos protocolos ampliamente conocidos: TCP y UDP. Ambos
ofrecen la posibilidad de transportar la información de un host a otro, pero cada uno ofrece
distintos servicios y prestaciones, y es decisión del programador de la aplicación cuál de
estos dos protocolos utilizar.

TCP: es un protocolo de la capa de transporte que se caracteriza por ser orientado a la

conexión, ofrecer un servicio de entrega fiable, control de flujo y de congestión, control de
errores, entre otros servicios. No es posible para TCP garantizar la tasa de envío, ni los
retardos.

UDP: es el otro protocolo ampliamente conocido de la capa de transporte. Básicamente,

UDP agrega pocos servicios a la capa de red subyacente. Se encarga de agregar
información de cabecera, como puertos origen y destino, checksum, y enviar el paquete a la
red. No es necesario un establecimiento de la conexión, no es un servicio que garantice
entrega fiable, control de flujo, ni tampoco de congestión. Respecto al uso del checksum,
será responsabilidad de la aplicación, no de UDP.

Ni UDP ni TCP garantizar la temporización.

La web y HTTP

HTTP es un protocolo de la capa de aplicación, llamado protocolo de transferencia de

hipertexto, encargado de facilitar a los usuarios la posibilidad de navegar por la web.
Cuando un usuario navega por la web, normalmente usa un agente de usuario web (un
navegador) que se encarga de “traducir” las solicitudes de usuario a un lenguaje técnico,
entendido por el protocolo HTTP, y de enviar las solicitudes a la red. Existen distintas
versiones de HTTP, entre ellas la 1.0, 1.1 y 2.0. HTTP no tiene memoria de estado (para
reducir su complejidad), y para solucionar esto se utilizan cookies.

HTTP sigue una arquitectura cliente servidor, donde los clientes son los navegadores, y los
servidores se esforzarán por atender solicitudes de muchos clientes. Hay dos tipos de
mensajes HTTP: request y response.

HTTP está muy relacionado con HTML (lenguaje de marcas de hipertexto) el cual presenta
documentos de texto plano con una cierta estructura que es fácilmente entendida por los
navegadores, y por eso, las páginas web suelen tener este formato. Normalmente cuando
uno realiza una solicitud HTTP en el contexto de una página web, está solicitando un objeto
HTML, aunque también pueden solicitarse otros objetos, como imágenes, archivos XML,
entre otros.
Estos objetos solicitados por HTTP están identificados en la web por una dirección URI, la
cual se divide en dos partes:

Así entonces es posible identificar un documento de forma unívoca en la red. El nombre de

la máquina, con la ayuda del protocolo DNS se transformará en una dirección IP
(identificador único de un host en la red), y el nombre de la ruta identificará el objeto dentro
de dicha máquina.

HTTP por defecto trabaja con el puerto 80 del lado del servidor. Cada vez que un cliente va
a establecer una conexión, crea un socket con un número de puerto origen mayor a 1023 y
puerto destino 80. El servidor tendrá que tener un socket escuchando en el puerto 80, y al
llegar la petición tendrá que hacer una ramificación, para poder atender al nuevo cliente,
pero también dejando el puerto 80 libre para atender otras solicitudes.

Conexiones persistentes y no persistentes

Una conexión persistente es aquella que se establece, y puede permanecer en estado

“establecida” por un cierto tiempo N, en el cual los host pueden enviarse varios objetos. Por
el contrario, las conexiones no persistentes son aquellas que solo permiten en flujo de un
objeto por cada conexión, de manera que si se solicitan varios objetos, será necesario
establecer la conexión varias veces (tantas como objetos haya).

HTML trabaja con el protocolo TCP de la capa de transporte, el cual es capaz de usar
conexiones persistentes.
Como dijimos, HTTP tiene distintas versiones, y cada una de ellas trabaja de una manera
específica.

HTTP 1.0 por defecto trabaja con conexiones no persistentes (a menos que se le
especifique la opción “keep-alive”), lo cual puede ser engorroso para páginas con muchos
objetos a descargar. Es importante notar en este punto, que el uso mas común de HTTP es
a través de un navegador web. Cuando un navegador web vé etiquetas <link> o <img> en
un documento HTML, sabe que son referencias a otro objeto y que sin ese objeto, la página
se vería “incompleta”. Por eso, los navegadores suelen realizar peticiones HTTP de forma
automática al ver ese tipo de referencias. El problema radica en que si un navegador tiene
que establecer muchas veces la conexión, la performance termina viéndose perjudicada.

RTT: tiempo de ida y vuelta de una solicitud y su respectivo resultado.

Teniendo eso en mente, podemos afirmar que una conexión HTTP 1.0 consume:
- 1 RTT para establecer la conexión.
- 1 RTT para realizar la petición.
 - El tiempo total sería entonces: 2 RTT + tiempo necesario para que viaje el elemento.

Con HTTP 1.1 este problema fue solucionado. Las conexiones por defecto son persistentes,
de manera que no es necesario establecer la conexión cada vez que se quiere descargar
otro objeto. Sin embargo esto también tiene sus contras: es inseguro dejar abierta la
conexión, y si se deja abierta de manera innecesaria consume recursos. Mas allá de eso, la
ventaja en tiempo suele ser mucha. Por ejemplo, para descargar 10 objetos de una página
será necesaria solo una conexión TCP (se utiliza solo 1 RTT). Varias páginas web que
residan en el mismo servidor se pueden enviar al mismo cliente. La conexión normalmente
es cerrada por el servidor si no se usó durante un cierto tiempo. Para aumentar la velocidad
se puede usar pipelining.

Si un cliente y servidor ejecutan distintas versiones de HTTP, uno la 1.0 y otro la 1.1, la
conexión se podrá lograr como conexión no persistente.

La otra versión de HTTP anteriormente nombrada es HTTP 2.0.

HTTP 2.0 reemplaza la manera anterior de HTTP de transportar la información, pero no es
un cambio completo: conserva métodos y semántica. La principal diferencia con las
anteriores versiones es que es un protocolo binario en lugar de texto (ASCII), lo que resulta
mas eficiente. También multiplexa varios request (pide varios objetos) en una petición en
lugar de ser una secuencia ordenada y bloqueante, y utiliza una conexión para pedir/traer
datos en paralelo. Lo bueno es que viaja menos información innecesaria, ya que para todas
las peticiones de objetos que puede hacer en una request, la información de control como
cookies o dirección de host viaja una sola vez.
HTTP 2 no puede interactuar con las anteriores versiones de HTTP.

Relación entre HTTP y DNS

DNS es un protocolo de capa de aplicación que, entre otras tareas, se encarga de realizar la
correspondencia entre un nombre de dominio y su respectiva dirección IP. Esta función
principal de DNS está alentada por el simple hecho de que para una persona es mas fácil
recordar “google.com” que “192.273.5.67” (por ejemplo). El protocolo DNS será explicado
con mayor detalle mas adelante.

Como HTTP se usa normalmente respondiendo a solicitudes de usuario, donde por ejemplo
tenemos un usuario que quiere consultar la página “google.com”, es muy importante la
relación entre HTTP y DNS. El agente de usuario (el navegador) solicitará al módulo DNS
que nos devuelva la IP donde se aloja la página solicitada por el cliente. Una vez obtenida
dicha dirección, sí es posible realizar las peticiones por los objetos en particular.

El problema de las direcciones IP crece al saber que hay muchísimas páginas web que los
usuarios frecuentan, con lo cual recordar todas esas IP se hace bastante difícil, pero mas
difícil aún si agregamos que las IP no son estáticas: cada cierto tiempo suelen cambiar, con
lo cual todo lo memorizado no sirve.

Por eso, HTTP sin apoyarse en DNS sería inviable.

Comandos HTTP
HTTP tiene distintos comandos que sirven para solicitar distintas funciones del protocolo. El
formato es:

En caso de enviar información se pueden usar dos formas:

- La mas segura y recomendada, es enviar la información en el cuerpo del mensaje
HTTP. De esta forma, se garantiza mayor seguridad. (POST)
- La menos segura sería enviar la información en variables que formen parte de la
URL de la línea de requerimiento. Esta forma tiene la restricción de que la
información no puede ocupar más de 256 bytes. (GET).

Los métodos que pueden usarse en una request son:

- GET: nos sirve para hacer solicitudes por un recurso. No debería ser usado para
enviar información.
- POST: trabaja de igual forma que GET, pero envía la información en el cuerpo de la
solicitud.
- HEAD: trabaja de igual manera que el GET, pero sólo devuelve las líneas de
encabezado.
- PUT: sirve para subir contenido. Normalmente los servidores de hosting no lo tienen
habilitado, por seguridad.
- DELETE: elimina el recurso especificado. Tampoco suele estar habilitado en los
servidores de hosting.

El formato de una respuesta HTTP es:

Los códigos de estado podemos clasificarlos en:

- 1XX: Informativos (no utilizados actualmente)

- 2XX: Éxito
- 3XX: Redirecciones
- 4XX: Error de cliente
- 5XX: Error de servidor.

Autorización y Cookies

Hoy en dia es muy común encontrar sistemas que requieran un nombre de usuario y
contraseña para acceder a una página, y poder navegar a través de ella. Esto básicamente
es: el servidor solo responde solicitudes a usuarios (agentes de usuario) que puedan
demostrar que están autorizados para realizar dichas solicitudes.

Sin embargo, como fue dicho antes, HTTP es un protocolo sin estado: no conserva ninguna
información entre distintas solicitudes y por ende, a priori si un usuario inicia sesión, en la
próxima petición que haga, el servidor va a desconocer que dicho usuario ya inició su
sesión. Para solucionar esto, se utilizan las cookies.

Las cookies representan un componente importante en la web, que está presente en 4

lugares: HTTP request, HTTP response, navegador web y servidor web. Lo controversial de
ellas es que debe ser almacenada en el navegador web del usuario, con lo cual puede
obtener mucha información que luego las empresas podrían vender a otras.

La idea sería que por ejemplo, un usuario inicie una sesión en un sistema. Dicho sistema va
a crear en su memoria información asociada, como una relación entre nombre de usuario y
un identificador único (cookie). En la HTTP response, el servidor añade una línea “set-
cookie: cookie1” lo cual indica al navegador que tiene que almacenar dicha información. El
mensaje completo de “set-cookie” sería:

“Set-Cookie:”
“Nombre=valor;” -> Nombre de la cookie y valor
“Expires=fecha;” -> Fecha de caducidad
“Path=camino;” -> Camino
“Domain=dominio;” -> Dominio
“Secure” -> sólo se transmite sobre canales seguros (HTTPS).

Con dicha información el navegador cuando haga una HTTP request por una URL en
particular, va a ver si tiene alguna cookie
que en su “path” tenga dicha URL. Si hay
coincidencia, incluye el valor de cookie en
la petición. Cuando llega al servidor, el
servidor va a comparar dicho valor de
cookie con los valores que tiene
almacenados, y si hay coincidencia,
responde satisfactoriamente.
Web caching - Servidores proxy

Por segundo puede haber infinidad de solicitudes HTTP, lo cual de alguna manera afecta a
la red, por la sobrecarga de información viajando en un momento dado. Para solucionar
esto, se pensó en la posibilidad de que existan servidores que almacenen información que
pasa por ellos, de manera que puedan responder a solicitudes sin que lleguen éstas a hacer
gran recorrido en la red.

Típicamente un usuario tiene su servidor proxy en su ISP, y las solicitudes viajan hacia él
inicialmente. Si este servidor tiene la información que está siendo solicitada, podrá
responder él la petición y de esta forma se ahorran tiempo y recursos. Es importante notar
que el servidor web actúa como cliente y como servidor. Actúa como servidor en el caso
anteriormente visto, pero en caso de no poder responder la solicitud, actúa como cliente,
buscando en la web el recurso solicitado. Una vez que lo obtiene, es común que lo
almacene en su propia memoria, para poder responder él por dicho recurso en un futuro
cercano.

Para usar este tipo de estrategia es que existe

el GET condicional. La idea básica es salir a
buscar un recurso sólo si es necesario.
Cuando un cliente realiza una solicitud a su
servidor caché, éste usa get condicionales
para comunicarse con el servidor que ofrece
el servicio en cuestión, y ver si puede
responder o no con la información que ya
tenía almacenada (en caso de tenerla, obvio).
Para esto se usan tanto el encabezado “If-
modified-since”, y el Etag. “If-modified-since”
pide el recurso si fué modificado desde la
última vez que la información quedó guardada
en el servidor caché. E-tag es un identificador
para una versión específica de un recurso (si
un recurso en una URL dada cambia, el valor
de Etag debe ser regenerado).

HTTPS

Es un protocolo usado para transferir información de manera segura. Nace de la unión de

dos protocolos de capa de aplicación: HTTP y SSL. La idea es que tanto el emisor como el
receptor de las solicitudes HTTP sepan que hay un servicio de seguridad, el cual encriptará
la información, y que ambos sepan con qué algoritmo desencriptarla. El objetivo es que la
información no pueda ser interceptada mientras navega por la web y leída por algún agente
indeseado.

HTTPS usa el puerto 443 del lado del servidor.

Pasando en limpio, la idea de HTTPS es lograr:
- Privacidad de la información.
- Autenticación.
- Integridad de los datos.

Como se dijo antes, SSL es un protocolo por si mismo y se lo podría ubicar en la “Capa de
Presentación” del modelo OSI. Puede combinarse su uso con otros protocolos, como FTPS,
IMAPS, entre otros.

Transferencia de archivos: HTTP, FTP y TFTP

El protocolo históricamente usado para transferencia de archivos es FTP. Sin embargo, vale
aclarar que actualmente FTP es usado solo para transferencia de archivos grandes y está
empezando a perder terreno hace tiempo contra HTTP (si bien HTTP se usa en mayor
medida para contenido web, es un protocolo de transferencia de archivos en general). Las
mayores diferencias entre HTTP y FTP es que HTTP no mantiene estado en el servidor, y
que FTP envía la información de control por un canal aparte, mientras que HTTP lo manda
como cabeceras.

Ahora, hablando de FTP específicamente, tenemos que decir que tenemos dos protocolos
que tienen una misma idea como base: FTP y TFTP.

FTP

Es un protocolo de capa de aplicación cuyo fin es la transferencia de información. FTP

utiliza dos conexiones: una conexión de datos y una conexión de control (una de las
principales diferencias con HTTP, ya que HTTP envía la información de control como
cabecera de las peticiones). También tiene dos versiones: activo y pasivo. Utiliza el
protocolo TCP de capa de transporte.

Cuando un usuario quiere iniciar una conexión FTP, establece la conexión de control hacia
el puerto 21 del servidor, y envía su información de autenticación. En caso de ser válida
dicha información, el servidor va a dar la conexión como establecida. Otra diferencia con
HTTP es que FTP mantiene estado de usuario (HTTP necesita de cookies).

La diferencia entre FTP activo y FTP pasivo radica en la conexión de datos:

- Modo activo: luego de que se estableció la conexión de control, el cliente la usa para
especificarle al servidor en que puerto va a escuchar la conexión de datos.
Básicamente, le envía un mensaje con el comando “PORT”, donde indica dicho
número de puerto. Al llegar esta información al servidor, el servidor establecerá la
conexión de datos, desde su puerto 20 hacia el puerto indicado por el cliente. El uso
de este modo está desalentado porque tiene grandes problemas de seguridad para
el cliente, al dejarlo con un puerto abierto a la espera de recibir conexiones. Por
 esto, los firewall suelen evitar este tipo de conexiones, lo cual representó un
problema para FTP.
- Modo pasivo: para solucionar el problema anterior, se creó este modo. Una vez
establecida la conexión de control, el cliente la usa para enviar un comando PASV al
servidor, indicando que usará el modo pasivo. Como respuesta, el servidor le indica
en qué número de puerto (mayor a 1023) lo escuchará, y será responsabilidad del
cliente iniciar la conexión.

Es importante destacar que la información viaja en formato ASCII de 7 bits. También es

importante saber que la conexión de datos no es persistente: al viajar un elemento la
conexión se cierra, y para transportar un nuevo dato la conexión debe ser establecida
nuevamente.
Normalmente los servidores FTP no permiten realizar casi ninguna acción hasta que el
usuario no haya ingresado su nombre de usuario y contraseña. Sin embargo, existen
servidores anónimos que permiten al usuario realizar ciertas solicitudes, por ejemplo listado
de información, y subir algún archivo a algún directorio en particular. Vale aclarar que estos
servidores anónimos tienen el acceso restringido para estos usuarios que no se autentican:
recién al estar autenticados pueden hacer uso completo de los servicios FTP del servidor.

Los comandos son enviados como texto ASCII vía el canal de control, los puertos utilizados
son (servidor 21, cliente > 1023).

- USER username: utilizado para enviar la identificación de usuario al servidor.

- PASS password: utilizado para enviar la palabra clave al servidor.
- LIST: retorna la lista de archivos del directorio actual, la lista de archivos es enviada
sobre una conexión de datos (nueva y no persistente). Además de los puertos de
control mencionados, se utilizan los siguientes puertos para transferir los datos:
servidor 20 y cliente > 1023 si utiliza el modo activo. Servidor > 1023 y cliente >1023
si el modo utilizado es el pasivo.
- RETR filename: baja un archivo (gets), el archivo también se manda sobre una
conexión de datos. Puertos utilizados para transferir los datos, idem anterior.
- STOR filename: almacena (puts) archivo en host remoto. Puertos utilizados para
transferir los datos, idem anterior.

TFTP: Trivial file transfer protocol

Suele usarse para transferir archivos pequeños. A diferencia de TFTP usa UDP (en el
puerto 69). Debido a esto, no hay definición formal de sesión, cliente y servidor, aunque se
considera servidor a quien abre el puerto 69 y cliente a quien se conecta.
Tiene 5 comandos: Read, Write, ACK (necesario porque usa UDP), Error y Data. Tiene
muchas menos funciones que FTP (por ejemplo, no puede listar archivos almacenados en
el servidor).
No tiene sistema de seguridad.
Usa una única conexión, a diferencia de FTP que utiliza dos.

Servicio de correo electrónico

El correo electrónico es un servicio que existe desde los comienzos de las redes.
Inicialmente fue planteado como un medio de transmisión de texto desde un origen a un
destino, aunque en la actualidad también se puede enviar información multimedia, como
videos, audio e imágenes.

Los tres componentes básicos de este servicio son: SMTP, agentes de usuario y servidores
de correo. La estructura básica es la siguiente:

Cuando un usuario usa un MUA (agente de usuario de correo electrónico) con el fin de
enviar un correo, este agente de usuario normalmente conoce a los servidores de correo
para su dominio. En este momento, el agente de usuario de correo realiza una consulta
DNS por el registro A del servidor de correo. Una vez obtenida dicha dirección IP, se usa su
LMTA (Local Mail Transport Agent), quien usa a su vez el protocolo SMTP para enviar el
correo hasta su servidor destino.

Los servidores SMTP son comúnmente conocidos como MTA (Agente de transporte de
correo). Cuando un correo llega a un servidor MTA, éste lo almacena en su buffer hasta que
llegue la oportunidad de poder enviarlo. Cuando llega dicho momento, el servidor lee la
dirección destino del correo, y en caso de no ser el mismo nombre de dominio, realiza una
consulta DNS por el registro MX para el nombre de dominio en cuestión (por ejemplo, si el
mail se envía a “hola@gmail.com”, consultará por los servidores de correo de gmail. Una
vez obtenida la lista de servidores de correo, elegirá el servidor de correo de mayor
prioridad, y establecerá la conexión TCP con dicho servidor. Una vez establecida la
conexión con el MTA del receptor del email, el mail será enviado.
Una vez que el correo llega al MTA destino, éste le delega la tarea al MDA (Mail Delivery
Agent) de que eventualmente el mail pueda ser leído por el destinatario. Básicamente el
MTA entrega el mail al MDA (será un servidor POP3 o IMAP).

Eventualmente, el receptor de dicho mail se conectará usando su agente de correo a su

MDA para poder leer los mails. Para esto, el MUA realizará una consulta DNS por el registro
A de su servidor de mayor prioridad, y una vez obtenida la dirección IP, ejecutará con el
protocolo POP3 o IMAP para comunicarse con dicho servidor, según corresponda. Para
proteger la información personal, los MDA normalmente están protegidos con nombre de
usuario y contraseña.
Protocolos de correo electrónico

Los protocolos de correo electrónico fueron nombrados anteriormente, pero ahora serán
explicados en profundidad. Son SMTP, POP3 e IMAP.

SMTP

Es el principal protocolo de correo electrónico. Usa el servicio fiable TCP de transferencia

de datos. Los servidores que ejecutan SMTP a menudo ejecutan tanto como cliente o como
servidor: ejecutan como servidor cuando un usuario envía un correo que deben almacenar,
y ejecutan como cliente cuando se comunican con otro servidor SMTP para enviarle un
mail.

Es un protocolo muy antiguo, que tiene una restricción que afecta claramente hoy en día: el
formato del email tiene que respetar ASCII de 7 bits. Esto en su momento fue lógico, en la
década de los 80, porque no se pensaba en enviar video o voz por un mail, pero hoy en día
es una restricción que tuvo que ser solucionada con MIME. Vale aclarar que los datos
multimedia hoy en día están en formato binario, y tienen que ser transformados a ASCII de
7 bits para ser transmitidos.

Es importante observar que SMTP normalmente no usa servidores intermedios entre MTAs.
La conexión entre estos servidores es “punto a punto”.
SMTP usa conexiones persistentes: si el servidor SMTP origen tiene mas de un correo que
enviar al mismo servidor SMTP destino, los enviará por la misma conexión TCP. Para cada
mensaje, el cliente comienza cada proceso con un nuevo MAIL FROM: crepes.fr, que
delimita el final del mensaje con un punto y realiza QUIT solo después de que todos los
mensajes hayan sido enviados.
Puede o no requerir autenticación, y puede o no trabajar de forma segura.

POP: Post Office Protocol

Es un protocolo relativamente sencillo. Para empezar, no mantiene el estado en el servidor:

distintas conexiones POP son totalmente independientes. Esto afecta en que por ejemplo
no tiene manejo de carpetas para ordenar los mails en el servidor. Tampoco ofrece la
posibilidad de descargar partes del mensaje: o se descarga todo, o no se descarga nada.
Tiene la particularidad de que posee dos modos de trabajo, los cuales son “descarga-
almacenamiento” y “descarga-borrado”. La opción por defecto es “descarga-borrado”, lo
cual indica que los MUA descargarán los correos desde el servidor hacia el equipo local, y
los eliminarán del servidor. Como ventaja, tiene que luego de descargar el correo, no
necesitamos el servicio de internet para accederlo. Además, no tenemos que preocuparnos
por el espacio ocupado en el servidor. Como desventaja, no podemos leer un mismo correo
desde diferentes equipos, ya que no permanecen en el servidor.
Es común hablar de que POP tiene 3 fases:
- Autenticación: el usuario envía su nombre de usuario y contraseña.
- Transacción: el usuario puede marcar mails para borrado, y solicitar la descarga de
mails. También es en esta fase que se pueden enviar mails.
- Actualización: se produce después del comando QUIT. En este momento se
eliminan los mails marcados para borrado.

IMAP

Es un protocolo que ofrece muchas mas funcionalidades que POP. Sin embargo, también
es bastante mas costoso. IMAP como principal ventaja es que mantiene el estado en el
servidor, por lo que es posible organizar los mails en carpeta, marcarlos o desmarcarlos
como “leídos”, entre otras ventajas.
Otra ventaja es que se puede usar desde dispositivos diferentes, ya que no descarga los
mails al host del usuario. También permite al agente de usuario de correo obtener partes de
mensajes (por ejemplo, solo el encabezado), a fin de ahorrar ancho de banda (al leer el
encabezado, el usuario puede decidir no leer el mail y por ende no solicitará todo el correo).

Como desventajas, es un servicio mucho mas pesado que POP, obligando a mantener la
conexión abierta hasta que se termine de consultar, y además siempre requiere internet
para acceder a leer los correos. También hay que tener en cuenta que el espacio en el
servidor es limitado, por lo cual tendríamos que eliminar correos con cierta frecuencia.

La decisión sobre usar IMAP o POP3 dependen de cada usuario. Ambos cumplen la tarea
básica de forma correcta.

MIME: Extensiones multipropósito de correo de Internet

Son una serie de convenciones dirigidas al intercambio a través de internet de todo tipo de
archivos (texto, audio, video, etc) de forma transparente para el usuario. Una parte
importante de MIME está dedicada a mejorar las posibilidades de transferencia de texto en
distintos alfabetos.

MIME permite soportar:

- Texto en conjuntos de caracteres distintos de US-ASCII.
- Adjuntos que no son de tipo texto.
- Cuerpos de mensajes con múltiples partes (multi-part).
- Información de encabezados con conjuntos de caracteres distintos de ASCII.

Los mensajes de correo electrónico usan MIME para solucionar la restricción de ASCII de 7
bits como formato de transporte de información. Dos ejemplos son:

Es importante aclarar que MIME puede ser usado en HTTP, SMTP, POP3 e IMAP.

Comparación entre SMTP y HTTP

Ambos se usan para transferir archivos de un host a otro. También ofrecen la posibilidad de
conexiones persistentes (desde HTTP 1.1).
Las diferencias son:
- HTTP es un protocolo de demanda. La conexión es iniciada por la máquina que
quiere recibir el archivo. SMTP es un protocolo de oferta.
- SMTP requiere que cada mensaje esté en ASCII de 7 bits. En HTTP no existe tal
restricción.
- HTTP encapsula cada objeto en su propio mensaje HTTP de respuesta. SMTP
reúne todos los objetos en un mensaje.

DNS (Domain Name Server)

Es un protocolo de capa de aplicación que sirve para:

- Resolver nombres mnemotécnicos en direcciones IP.

- Alias de host.
- Alias de correo electrónico.
- Resolución de reversos.

No trabaja sobre texto ASCII.

Además de ser un protocolo, DNS tiene soporte en una enorme infraestructura de

servidores, los cuales pueden verse como una base de datos organizada de manera
jerárquica y descentralizada, ubicada en distintas partes del mundo. La información
almacenada en dichas bases de datos es la que será consultada por el protocolo DNS.
Como ventaja de esta distribución descentralizada, tenemos que no hay un único punto de
consulta (lo cual disminuiría mucho la performance), único punto de error, y único punto de
consulta que puede resultar lejano para muchos puntos del planeta.

El protocolo DNS se ejecuta sobre UDP, en el puerto 53 de los servidores. También usa
TCP en casos en donde la respuesta consume más de 512 bytes, y en la transferencia de
zona (AXFR).
Como característica de DNS podemos decir que no es un protocolo que se use
“directamente” por el usuario, sino que es usado por otros protocolos, por ejemplo HTTP.

El funcionamiento básico y mas común consiste en que la aplicación cliente invocará DNS,
especificando el nombre de host que debe ser traducido a dirección IP. La solicitud DNS
será atendida por distintos servidores DNS en la jerarquía de servidores, y en caso de éxito,
se le devolverá al cliente la información solicitada.

Tenemos 4 tipos de servidores:

- Servidores locales de nombres: los ISP tienen un servidor DNS local, el cual se
encarga de tareas de cacheo de información, y de resolver -dentro de lo posible- las
consultas generadas por el cliente. Los clientes encaminarán su consulta DNS en
primer lugar al servidor DNS local.
- Servidores raíz de nombres: cuando un servidor local no puede responder a las
solicitudes del cliente por no tener información cacheada, debe salir a consultar a
 otros servidores. Actualmente existen 13 servidores de este tipo en el mundo,
etiquetados de la A a la M, donde 7 de esos están replicados en distintas partes del
mundo. La idea de que estos servidores estén en diferentes partes del mundo es
para descentralizar la información y lograr un tiempo de respuesta DNS
relativamente rápido a cualquier lugar del mundo. La limitación de 13 servidores se
da por la restricción de UDP de 512 bytes.
- Servidores autorizados de dominio: son servidores que fueron autorizados a
responder por ciertas zonas. Por ejemplo, en la red UNLP hay un servidor autorizado
a responder por “unlp”. Si hubiera una página por ejemplo “redes.unlp”, dicho
servidor de la universidad debería conocer la dirección IP del servidor de dicha
página.
- Open Name Servers: servidores DNS que funcionan como locales para cualquier
cliente. Por ejemplo 8.8.8.8, de Google.

Las consultas DNS pueden ser recursivas o iterativas:

- Recursivas: son aquellas que obligan al receptor de la consulta a responder
efectivamente o informar error. Estando obligado a responder efectivamente o
informar error, el servidor puede pedir ayuda de otros servidores DNS que conozca
para poder responder correctamente.
- Iterativa: son aquellas que obligan al receptor a responder como mejor pueda.
Puede no responder nada útil, la información en sí, o una lista de uno o mas
servidores a los cuales seguir consultando.

Hablando específicamente de la jerarquía de servidores, tenemos:

- Root server: servidor de nombre de dominio que sabe dónde están los servidores de
nombres autorizados para cada una de las zonas de más alto nivel en internet. Su
tarea principal es delegar la atención de las solicitudes DNS hacia los servidores de
alto nivel conocidos como TLD.
- TLD: se pueden dividir en tres grandes grupos:
- GTLD: son dominios genéricos, como “.com”, “.net”, “.org”, entre otros.
- CCTLD: son dominios administrados por países, los cuales a su vez pueden
delegar la administración a otras entidades. Ejemplos claros son “.ar”, “.cl”,
entre otros.
- .arpa-TLD: es un dominio especial usado internamente por el sistema DNS
para resolver reversos (dada una dirección IP, devolverá su nombre).
- Servidores autorizados: puede hacer cambios en la zona y es el que tiene la última
versión de los registros.
Vale aclarar que los servidores locales de nombres no entran en la jerarquía, debido
a que su función mas típica es responder según la información que tengan en caché,
y en caso de no tener dicha información, saldrán a buscar a la jerarquía de
servidores. Sin embargo, un servidor DNS local puede ser autoritativo para una
zona, y en tal caso, entra en la clasificación como servidor autorizado.

Delegación de subdominios/zonas
Los nombres de dominio tienen una estructura jerárquica. Tienen la forma
“www.redes.unlp.edu.ar.”, y de derecha a izquierda se puede ir desglosando la red,
encontrando delegaciones para ciertas zonas.
Analizando dicha dirección, vemos que un DNS local tendría que consultar a un root server
(en caso de no tener la información cacheada) por toda la dirección. Probablemente el root
server conozca el servidor autoritario para el dominio “.ar”, y nos responderá la dirección de
éste. A su vez, dicho servidor (o alguno de una lista devuelta, en caso de obtener mas de un
resultado), el servidor DNS local le consultará por toda la dirección, y como respuesta mas
básica nos podría responder la dirección del servidor autoritario para el dominio “.edu” (o
nada en caso de no conocerla). Así se seguiría desglosando la información hasta llegar a
dar con el servidor autoritario para dicho nombre de dominio.

Con este sencillo ejemplo podemos ver que los servidores DNS van delegando ciertas
zonas (por ejemplo, “.ar” es una zona, y “.edu” es otra). La delegación consiste en
seleccionar un servidor como autorizado para dicha zona, y conocer ahora la dirección IP de
dicho servidor, para poder responder en caso de alguna solicitud que nos llegue (sería algo
como “para una dirección “.ar”, preguntale a este servidor: direccionEjemplo”).

El resolver

Es un conjunto de rutinas (un módulo) que se encarga de solucionar las consultas DNS, a
solicitud del cliente. Por ende este módulo no es un servicio activo, sino que es una
biblioteca de funciones que se usan conjuntamente con la aplicación.

Existen dos tipos de resolver: los que no realizan ninguna función de catching (llamado Stub
Resolver), que usan para cacheo el servidor DNS local, y los que sí realizan función de
cacheo (llamados Smart Resolver), que funciona en cada equipo como si fuera un servidor
local y permite realizar algunas funciones extra.

Registros DNS y ejemplos de uso

Los servidores DNS almacenan la información con la que trabajan en una base de datos
local. Estas bases de datos pueden tener distintos tipos de información, organizados en
registros RR. Dentro de internet, el tipo de registro que nos interesa es el de clase “Internet”
(IN).

Tenemos 9 registros DNS:

● A
● AAAA
● PTR
● SRV
● MX
● NS
● TXT
● SOA
● CNAME
Registro A: se usa para traducción de nombres de dominio. Cuando hacemos una consulta
DNS para obtener una dirección IP, consultamos por este registro. Pueden existir varios
registros A para un determinado nombre. Esto se usa, por ejemplo, para hacer balance de

carga.

Registro PTR: se usa para mapear direcciones IP a nombres de dominio. Es el inverso al

registro A. Son usados con el dominio especial in-addr.arpa.

Es importante destacar que los

registros PTR deben estar en un
subárbol separado (llamado in-
addr.arpa). Esto se debe a que la
búsqueda se realiza usando la
dirección IP y no el nombre, y
dada la estructura clásica de las
direcciones IP, dada una
dirección no es posible
determinar en qué zona está
asignada. El árbol de reversos
organiza las direcciones por
octeto de las direcciones IP,
generando un árbol como el
siguiente:

Registros CNAME: son registros que se utilizan cuando un nombre de dominio se vuelve
engorroso de recordar, por ser complicados. El CNAME funciona como un alias, que da un
nuevo nombre, con intención de que sea mas simple y fácil de recordar por las personas.
Si no existiera el CNAME, se podría lograr el mismo efecto con varios registros A:

Registros MX: Son registros utilizados para almacenar los servidores de correo para un
nombre dado. Al decir esto hablamos de servidores SMTP, encargados de recibir correo.
Gracias a esto, las direcciones de correo no necesitan contener especificación del servidor
completo de mail, sino que alcanza con indicar solo el dominio. Al consultar por el registro
MX podría retornar una lista, que básicamente hará distribución de carga. Cada servidor
tendrá asociado un número que se conoce como prioridad (menor número, mayor
prioridad), y los agentes de correo eligen siempre el servidor de correo de mayor prioridad
para enviar el mail. Una curiosidad sobre esto, es que si el servidor primario está fuera de
servicio, un servidor secundario lo almacenará y esperará hasta poder entregarle él mismo
el correo al servidor primario. Si pasara un cierto tiempo en el cual el correo no puede ser
enviado porque el servidor primario sigue sin responder, se le responde al cliente un
mensaje que indica que el correo no pudo ser enviado.

Registros NS: son los registros nameserver. Nos dicen que servidores están autorizados a
responder para una determinada zona. Pueden existir varios servidores, pero no tienen
asociado ningún tipo de prioridad: cualquiera puede responder. En estos casos, donde hay
varios, es donde se usan servidores primarios y secundarios. Típicamente ante algún
cambio en los registros, el servidor primario informará a los secundarios del cambio, y se
realizará la transferencia de zona a todos los secundarios, usando el protocolo TCP. Junto
con el registro NS se recomienda tener asociado un registro A que nos informe la IP de
dicho servidor autoritario. Estos registros se conocen como GLUE RECORDS y se usan con
el fin de ahorrar consultas DNS (si recibimos un nombre de servidor autoritario,
normalmente después haremos una consulta para saber su dirección IP (registro A)).
Registros SOA: son para indicar comienzo de autoridad. Existe uno por cada zona o
subzona. Especifica los parámetros globales para todos los registros del dominio o zona.

Registros AAAA: equivalente al registro A, pero para direcciones IPV6.

Registros SRV: “servicio”. Se utiliza para la definición de un servicio TPC en el que opera el
dominio.

Registros TXT: significa “texto”. Esta sintaxis de DNS permite que los administradores
inserten texto en el registro DNS. A menudo se utiliza para denotar hechos o información
sobre el dominio.

Por ejemplo, cuando un usuario usa indirectamente HTTP para poder visitar una página
web, podría usar DNS para consultar los registros A, CNAME y NS. Así mismo, cuando un
servidor SMTP desea enviar un correo a otro servidor SMTP, podría usar DNS para
consultar registros MX, A y NS.

Archivo hosts

En Linux normalmente se ubica en /etc/hosts. En Windows, en

\WINDOWS\system32\drivers\etc\hosts. Antes de que exista el servicio DNS, la resolución
de nombres a direcciones IP se hacía en este archivo, el cual era mantenido por humanos y
descargado por el servicio FTP. Las actualizaciones no eran muy frecuentes, y obligaba a
mantener las direcciones IP estáticas.

Con el crecimiento de internet este archivo se volvió inviable, de manera que hubo que
pensar en una solución (esa solución fue DNS).

Sin embargo, el archivo sigue existiendo. Normalmente se usa para restringir visitas a
ciertas páginas web.

Capítulo 3 - Capa de Transporte

La capa de transporte es la capa número 4 de la pila de protocolos TCP/IP. Su tarea es
lograr una comunicación entre dos procesos que requieran usar la red para poder
comunicarse entre sí. Por ende, es una comunicación lógica entre procesos. Los dos
protocolos ampliamente conocidos de la capa de transporte son TCP y UDP.

El término “datagrama” para la capa de transporte se usa cuando usamos UDP. El término
“segmento” se usa cuando usamos TCP. Para evitar confusiones, se dice que el PDU de
esta capa es el segmento.

La información mas importante que se coloca en el encabezado de cualquier protocolo de

capa de transporte es el número de puerto origen y destino. Esto se usa para la tarea de
multiplexación y demultiplexación:
En el host origen, los procesos que desean enviar información a la red (o realizar
solicitudes) utilizan la capa de aplicación para acceder a los servicios de red. La capa de
aplicación deja la información en los sockets asignados a cada proceso, los cuales están
identificados con un número único dentro del host: un número de puerto. La capa de
transporte tiene que realizar en este punto la tarea de multiplexación. Esto es, debe reunir
los fragmentos de información proveniente de distintos sockets y encapsularlos en
segmentos de la capa de transporte, y pasarlos a la capa de red para que eventualmente
puedan llegar a su destino.
En el host destino, una vez que llegan los paquetes, la capa de transporte toma los
segmentos provenientes de la capa de red y verifica el número de puerto destino. Es así
que identifica sin problemas al socket al cual debe transmitirle la información recibida, y así
poder completar la comunicación lógica entre procesos. Esta tarea realizada en el host
destino se denomina demultiplexación.

Para la tarea de multiplexación y demultiplexación es elemental utilizar los números de

puerto, y es importante aclarar que estos números van desde 0 hasta 65535. También vale
aclarar que los puertos entre 0 y 1023 son llamados “puertos bien conocidos” y no deberían
usarse, ya que son usados por protocolos bien conocidos de la capa de aplicación.

Principios de transferencia fiable de datos

Los protocolos de capa de transporte trabajan sobre el protocolo de capa de red IP, el cual
no ofrece un servicio de transferencia de datos fiable, no garantiza integridad de los datos,
ni tampoco que lleguen en orden.

Los protocolos de capa de transporte pueden usar distintas alternativas para crear un
servicio fiable. UDP opta por no ser un servicio fiable, buscando mayor performance. En
lugar de eso TCP sí busca ser un servicio fiable.

Ser un servicio fiable implica asegurar que la información llegue a destino correctamente, en
orden, sin pérdidas ni datos corrompidos. Existen 3 elementos principales en la transmisión
y retransmisión de un emisor TCP: la recepción de datos desde la aplicación que se
encuentra por encima, el final del tiempo marcado por el temporizador, y la recepción de un
ACK.
Tras la ocurrencia del primer evento principal, TCP recibe datos de aplicación, los
encapsula en un segmento y lo pasa a la siguiente capa. En este momento puede poner a
correr un temporizador, si es que no hay ninguno ya corriendo.
En caso de que un temporizador finalice sin la llegada de un acuse de recibo, TCP volverá a
transmitir el segmento. En este caso TCP vuelve a arrancar el temporizador.
Cuando llega un ACK, TCP compara el valor del ACK con una variable propia llamada
“BaseEnvio”, la cual representa el número de byte mas antiguo por reconocer. Como TCP
usa reconocimientos acumulados, con la llegada del ACK se pueden estar reconociendo
varios segmentos que han sido transmitidos y aún no reconocidos. En este punto, si todavía
existen segmentos no reconocidos, reinicia el timer.

ARQ: AUTOMATIC REPEAT REQUEST

Es un protocolo usado para el control de errores en la transmisión de datos, garantizando la

integridad de los mismos. Suele usarse en sistemas que no actúan en tiempo real, dado que
un paquete que no llega en tiempo y forma difícilmente sea útil después.
La técnica se basa en el reenvío de información cuando se detectan errores, y para eso se
usan los señalizadores ACK y NACK. Si el emisor no recibe ACK para el tiempo
establecido, retransmite el segmento.
Servicios que brinda ARQ son:
- Detección de errores: el receptor debe detectar que se produjo un error de bit.
- Realimentación del receptor: el receptor le avisa al emisor que el paquete llegó.
- Retransmisión: todo paquete que ha sido recibido con error será retransmitido por el
emisor.

Algunos protocolos ARQ muy conocidos son Stop-And-Wait, Go-Back-N y Selective Repeat.

STOP-AND-WAIT

El emisor se encarga de enviar segmentos, para los cuales requiere su correspondiente

ACK antes de enviar el próximo. Esto provoca que no se aproveche el ancho de banda,
dado que el emisor quedará a la espera de un ACK en momentos en los cuales podría
enviar más segmentos, en caso de tenerlos. Es un protocolo sin pipelining. La otra opción
para poder volver a enviar un segmento es que se venza el timeout.
Para solucionar este problema de performance, se pueden
considerar los siguientes protocolos ARQ.

GO-BACK-N

Es un protocolo del tipo “retroceder N”, donde el emisor puede

transmitir varios paquetes sin necesitar su correspondiente
ACK. El máximo número de paquetes que puede transmitir sin
recibir ACK es N. La idea es usar ACK acumulativos. Utiliza
pipelining.

El rango de números de secuencia permitidos para los

paquetes transmitidos pero aún no reconocidos se puede ver
como una ventana deslizante de tamaño N, sobre el rango de números de secuencia. Por
eso este protocolo suele ser conocido como “protocolo de ventana deslizante”.

- Acción del emisor:

- Invocación desde arriba: cuando quiere enviar un paquete, primero
comprueba si la ventana está llena. En caso de poder transmitir, encapsula la
información de capa de aplicación en su segmento y la pasa a la capa de
red. En caso de no poder transmitir la devuelve a la capa de aplicación.
- Recepción de un ACK: la recepción de un ACK puede validar uno o varios
segmentos que han sido enviados y aún no reconocidos.
- Evento de fin de tiempo: en tal caso, el paquete perdido y todos los
siguientes deben ser retransmitidos.

- Acción del receptor: si se recibe correctamente y en orden el paquete con el número

de secuencia N, envía un ACK para el paquete N y entrega la porción de datos del
paquete a la capa superior. En otro caso, descarta el paquete y reenvía el ACK
correspondiente al paquete mas reciente recibido en orden. Descarga paquetes que
no lleguen en orden ya que no posee capacidad de almacenamiento.

SELECTIVE REPEAT
Resuelve el problema de GO-BACK-N de tener que retransmitir
paquetes que han llegado correctamente de manera
innecesaria (si la ventana en GBN es muy grande, un simple
error causa la retransmisión de un gran número de paquetes).
Para esto, va a requerir un reconocimiento por cada paquete
que llega correctamente, en lugar de usar ACK acumulativos. A
su vez, usa buffers en los cuales la información puede ser
almacenada hasta ser leída por la aplicación. Utiliza pipelining.

Gracias a la manera de trabajar de esta técnica, solo los

paquetes sospechosos de llegar corrompidos serán
retransmitidos (el receptor solicitará la retransmisión solamente
de ese paquete en cuestión). Tanto el emisor como el receptor
deben manejar una ventana de tamaño iguales para limitar el
número de paquetes pendientes de reconocimiento.

SR tiene una restricción con respecto al tamaño de la ventana: el tamaño de esta

debe ser menor o igual que la mitad del tamaño del espacio de números de secuencia.
Esto se debe a que la ventana se implementa como un buffer circular, entonces se
podría dar la situación en que el receptor no puede determinar si para un número de
secuencia X, se trata del segmento X o el segmento X + Y (donde Y es una vuelta completa
en el buffer circular). Esta situación se da cuando se pierden mensajes de ACK dirigidos al
emisor.

Normalmente se dice que TCP es un híbrido entre SELECTIVE REPEAT y GBN.

UDP
Es el protocolo de capa de transporte mas elemental. Cumple con la tarea básica de lograr
la comunicación lógica entre procesos anteriormente descrita (lo hace con la multiplexación
y demultiplexación), y se asegura de brindar la posibilidad (a la aplicación) de realizar un
chequeo de errores. Podemos afirmar entonces que UDP no añade prácticamente nada a
IP.
Características destacables:
- Se dice que UDP es un servicio sin conexión, debido a que no hay acuerdo entre los
host previo al envío del segmento. Muchos servicios, como DNS ven esto como una
ventaja en performance, y por eso deciden utilizarlo.
- No es un servicio confiable. No garantiza que los paquetes lleguen en orden, no
corrompidos, ni tampoco garantiza que efectivamente lleguen. Esto hace además
que se lo considere un protocolo sin estado, y la razón mas especifica es que como
no proporciona ninguno de los servicios previamente dichos, no requiere almacenar
variables en ninguno de los host que participan en la comunicación. Por esta razón,
UDP puede soportar mas clientes activos que los servidores TCP.
- Tiene poca sobrecarga en la cabecera. Al añadir poca información (puertos origen y
destino, longitud y checksum), la cabecera UDP pesa solo 8 bytes.
- Mas control a nivel de aplicación sobre cuándo y qué datos son enviados. Al no
proporcionar mecanismos de retransmisión en caso de error, y otros servicios
ofrecidos por TCP, el resultado es que la aplicación tiene el control total de la
información que viaja por la red. Esto es por que el protocolo UDP no toma
decisiones sobre información a enviar: lo único que UDP envía a la red es lo que la
aplicación dejó en la capa de aplicación.

Las aplicaciones de tiempo real se basan en esas características para elegir a UDP como
protocolo a utilizar de la capa de transporte. Esto es porque por ejemplo, no es relevante
retransmitir un píxel en una conversación por videollamada, para un cuadro de video que ya
fué transmitido. Es decir, las aplicaciones que requieren mayor velocidad y soportan cierta
pérdida, eligen UDP por su performance superior.

Formato del segmento UDP

- Los puertos se usan para

multiplexación o
demultiplexación.
- El checksum se calcula
separando los bytes en cadenas
de 16 bits y los suma. Al
resultado de esa suma le calcula
el complemento a1. También el
campo podría tener el valor 0,
que indica que no se calculó el
checksum.
- Cada uno de los campos tiene 2
bytes.
MULTICAST

La técnica de multidifusión consiste en el envío de información a la red a múltiples destinos

simultáneamente, enviando los mensajes sobre los enlaces solo una vez, y creando copias
de la información cuando los enlaces se dividen. En oposición a multicast, las técnicas
unicast son punto a punto. También existe la técnica broadcast, que trabaja enviándole
información a todos los nodos de una red.

Es aconsejable usarla cuando se quiere brindar un mensaje a un conjunto de nodos de la

red, donde ese conjunto no representa el total de nodos de la red (es decir, existen grupos
de multicast, donde todos los nodos sí van a recibir los segmentos enviados). Para hacer
esto, unicast debería enviar múltiples veces el segmento, lo cual resulta inadecuado.
Broadcast por su parte, enviaría los segmentos a todos los nodos de la red, lo cual sería un
desperdicio de recursos.

Las conexiones multicast utilizan UDP, ya que no es un servicio punto a punto, ni tampoco
orientado a la conexión.

TCP

Es el otro protocolo de capa de transporte ampliamente utilizado. A diferencia de UDP,

ofrece varios servicios adicionales que lo hacen un protocolo confiable. Es un protocolo
orientado a la conexión, ya que los host antes de comenzar a enviarse información deben
establecer una conexión previa y cierta información de control debe fluir entre ellos.
Esta información de control queda almacenada en ambos host, ya que TCP solo actúa en
los sistemas finales. Como parte de este establecimiento de conexión, cada host reserva
variables de estado.

Una conexión TCP proporciona una conexión full-duplex, lo cual quiere decir que dados dos
host A y B que tienen una conexión TCP establecida, los datos pueden viajar de A a B, o de
B a A. La conexión es punto a punto.

El establecimiento de la conexión TCP se denomina saludo de tres vías:

- Paso 1. Un cliente TCP comienza el enlace de tres vías enviando un segmento con
el señalizador de control SYN (Sincronizar números de secuencia) establecido,
indicando un valor inicial en el campo de número de secuencia del encabezado. Este
valor inicial para el número de secuencia, conocido como número de secuencia
inicial (ISN), se elige de manera aleatoria y se utiliza para comenzar a rastrear el
flujo de datos desde el cliente al servidor para esta sesión. Este segmento no tiene
carga útil.
- Paso 2. El servidor TCP necesita reconocer la recepción del segmento SYN del
cliente para establecer la sesión de cliente a servidor. Para hacerlo, el servidor envía
un segmento al cliente con el señalizador ACK establecido indicando que el número
de acuse de recibo es significativo. El valor del campo número de acuse de recibo
 contiene uno más que el número de secuencia inicial (es decir, ACK = SEQ_SV + 1)
recibido del cliente. Con este señalizador establecido en el segmento, el cliente
interpreta esto como acuse de recibo de que el servidor ha recibido el SYN del
cliente TCP. El servidor manda su propio SYN. Este segmento no tiene carga útil.
- Paso 3. Por último, el cliente TCP responde con un segmento que contiene un ACK
que actúa como respuesta al SYN de TCP enviado por el servidor. Pueden no existir
datos de usuario en este segmento. El valor del campo número de acuse de recibo
contiene uno más que el número de secuencia inicial (es decir, ACK = SEQ_SV + 1)
recibido del servidor. Una vez establecidas ambas sesiones entre el cliente y el
servidor, todos los segmentos adicionales que se intercambien en la comunicación
tendrán establecido el señalizador ACK. Este segmento podría tener carga útil.

Es importante hablar de los estados de la conexión durante el saludo de tres vías:

- Antes del paso 1, el servidor está en estado LISTEN.
- Luego del paso 1, el cliente queda en estado SYN SENT.
- Luego del paso 2, el servidor queda en estado SYN RCVD.
- Luego del paso 3, ambos están en estado ESTABLISHED. Vale aclarar que la
conexión en estado ESTABLISHED se da entre el cliente y el servidor, pero el
servidor mantiene su puerto escuchando, es decir, tiene un proceso que mantiene
una conexión establecida, y otro puerto que sigue escuchando.

Además de establecer variables de estado durante el saludo de tres vías, TCP destina
buffers. Luego, por ejemplo, el buffer de salida es usado cuando la capa de aplicación deja
datos que deben salir a la red en su socket: TCP toma los datos y los deja en el buffer de
salida. Luego, de tiempo en tiempo, TCP toma trozos de información del buffer para
encapsularlos y enviarlos. La cantidad máxima de datos que puede ser tomada y colocada
en un segmento está limitada por el MSS (máximo tamaño del segmento, haciendo
referencia solo a los datos (no a la cabecera)). El valor de MSS depende de la
implementación de TCP.
Los segmentos pasan hacia abajo en la capa de red, donde son encapsulados por
datagramas IP.
Cuando llega un segmento del otro extremo, los datos son depositados en el buffer de
recepción de la conexión. La aplicación lee el flujo de datos desde este buffer.

ESTRUCTURA DEL SEGMENTO TCP

Los campos puerto origen y destino identifican a los puntos terminales locales de la
conexión. El campo longitud de cabecera indica la cantidad de palabras de 32 bits
contenidas en el header TCP. Esta información es necesaria porque el campo opciones es
de longitud variable y por ende, la cabecera es de longitud variable. Los 6 flags son:
- URG: vale 1 cuando hay datos urgentes. Está asociado con el “Urg data pointer”, el
cual indica un desplazamiento hasta el comienzo de los datos urgentes.
- SYN: es el flag que se usa en el establecimiento de la conexión.
- ACK: se usa para indicar que el campo de acuse de recibo es válido.
- FYN: se usa para liberar una conexión, especificando que el transmisor no tiene mas
información que transmitir. Aún después de usar este flag, la conexión puede quedar
abierta para que, quien mandó FYN, pueda seguir recibiendo información.
- PSH: indica datos empujados. Se solicita atentamente al receptor que por favor pase
de inmediato el segmento a la aplicación. Se usa en conjunto con URG.
- RST: se usa para restablecer la conexión que se ha confundido debido a caída de
host u otra razón. También se usa para rechazar segmentos no válidos. Por último,
cuando un emisor envía un mensaje con TCP hacia un puerto que no está
escuchando, recibirá un segmento con este flag puesto a 1.

El tamaño de ventana indica cuántos bytes se pueden mandar después del byte de acuse
de recibo. El valor 0 es legal.
El checksum es una suma de comprobación similar a UDP.
Los campos “sequence number” y “acknowledgement number” (indica próximo byte
esperado) desempeñan su función normal.

CONTROL DE FLUJO

La idea de este mecanismo es no desbordar al otro extremo de la comunicación, debido a

enviarle información mas rápidamente de la que puede procesarla. El problema radica en
que el buffer de recepción, por supuesto, no es ilimitado y ante esto, se puede dar el caso
en que lleguen segmentos y no haya lugar disponible para almacenarlos hasta ser leídos
por la aplicación. En este caso, el segmento será descartado. Que el segmento sea
descartado, implica para TCP (que proporciona transferencia fiable de datos) la
retransmisión de dicho segmento. El problema está en que si lo retransmite a la misma
velocidad, es posible que también sea descartado, y el problema aumenta pensando que
muchos segmentos pueden tener ese problema.
Vale aclarar que TCP coloca segmentos en el buffer que ya se sabe que no tienen errores.

TCP proporciona el control de flujo haciendo que el emisor mantenga una variable llamada
“VentanaRecepcion”, la cual representa la cantidad de espacio disponible en el buffer del
receptor. Recordar que la conexión es full duplex y por ende, ambos lados de la conexión
disponen de esta variable para este fin.

La idea entonces es que, como TCP tiene que, al menos, confirmar los datos que le han
llegado de manera correcta realice un cálculo del espacio disponible de su ventana de
recepción y se la informe al host emisor.
Dicho cálculo se realiza usando las variables “UltimoByteLeido” y “UltimoByteRecibido”,
donde la primera hace referencia a datos ya leídos por la aplicación y la segunda se refiere
al último byte que ha llegado.
Notar que: UltimoByteRecibido - UltimoByteLeido <= BufferRecepcion. En este caso el
buffer no será desbordado.
El valor de la ventana será:
VentanaRecepcion = BufferRecepcion - (UltimoByteRecibido - UltimoByteLeido).

Como dijimos, el valor de ventana de recepción será enviado al emisor. Pero el emisor
también tiene que hacer cálculos, los cuales son justamente para no desbordar el buffer.
Para esto, el emisor cuenta con las variables “UltimoByteEnviado” y
“UltimoByteReconocido”, cuyos usos son obvios por sus nombres.
La idea es que UltimoByteEnviado - UltimoByteReconocido <= VentanaRecepcion.

Vale aclarar que siempre el receptor puede hacer disminuir o incrementar el valor de
VentanaRecepcion.
Puede darse el caso de que la ventana de recepción sea 0. En tal caso, el emisor no podría
enviar más información al receptor. Pero dado esto, podría darse el caso que el emisor
tenga mas información para enviar, y como el receptor no tiene ningún paquete que
enviarle, nunca se entere que el valor de VentanaRecepcion cambió. Por esto, TCP exige al
emisor seguir enviando segmentos al receptor. El segmento enviado será de 1 byte de
cuerpo, y la idea es que sea descartado por el receptor hasta que haya espacio en el buffer
y pueda recibir dicho segmento. Una vez que lo puede recibir, va a enviar un ACK por dicho
segmento, y con un valor de ventana actualizado, lo cual va a provocar que el emisor pueda
seguir enviando los datos que habían quedado pendientes.

APROXIMACIONES AL CONTROL DE CONGESTIÓN

El control de congestión sirve para evitar sobrecargar la red.

Existen dos enfoques para proporcionar este tipo de control:

- Control de congestión entre extremos: donde la capa de red no proporciona ninguna

información acerca del tráfico actual de la red, como para que TCP pueda usar dicha
información para regular la velocidad con la que manda segmentos a la red. La
presencia de congestión entonces debe ser inferida por los sistemas finales que
mantienen el estado TCP, basándose por ejemplo en retrasos y pérdidas. Ante la
 detección de pérdidas de paquetes o fin de tiempo de espera, TCP debería disminuir
el valor de una variable “VentanaCongestion”, para disminuir el tráfico enviado.

- Control de la congestión asistido por la red: es un enfoque en que los componentes

de la red (routers) pueden proporcionar información a los host sobre el estado de la
red respecto a la congestión. Esto se puede hacer con un mensaje ICMP especial,
que veremos mas adelante, que implica que el router que detecta congestión le
envíe ese mensaje ICMP especial al host emisor. También se podría marcar el
segmento con un bit especial, y dejarlo pasar. Cuando llegue al receptor, el receptor
vería este bit especial y le enviaria un segmento TCP al emisor que diga “la red está
congestionada, disminuí la velocidad”.

CONTROL DE CONGESTIÓN TCP

TCP utiliza el control de congestión de extremo a extremo, ya que la capa IP no proporciona

ninguna información acerca del estado de la red.

Cada emisor limita la tasa a la que envía tráfico en su conexión en función de la congestión
de red que percibe. Si un emisor ve que existe poca congestión entre él y el destino, puede
incrementar su tasa de emisión. Por el contrario, si el emisor vé que hay congestión, debe
disminuir su tasa de emisión.

Para esto, además de las variables descritas que usa TCP para control de flujo, usa una
variable llamada “VentanaCongestion”, donde la idea de la misma es imponer una
restricción sobre la tasa de emisión de TCP.

Concretamente, la cantidad de datos pendientes de reconocimiento en el emisor no puede

exceder del mínimo entre VentanaCongestion y VentanaRecepcion. Es decir:
UltimoByteLeido - UltimoByteReconocido <= min {VentanaCongestion, VentanaRecepcion}

Para explicar control de congestión, vamos a ignorar la restricción de VentanaRecepcion.

El algoritmo de control de congestión de TCP consta de tres partes: arranque lento,
evitación de la congestión y recuperación rápida.

ARRANQUE LENTO

Inicialmente TCP restringe la cantidad de información que puede enviar por cada RTT a
1MSS. Es decir, VentanaCongestion = 1 MSS. La idea es que con cada RTT que pase, el
valor de VentanaCongestion se vaya duplicando por cada RTT. Vale aclarar, que el RTT se
da entre el envío de un segmento, y la recepción de su respectivo ACK.
Este crecimiento exponencial puede frenar por tres motivos:
1. Si se produce una pérdida de paquete, señalado por un fin de temporización, se
establece la ventana en 1 MSS y se vuelve a iniciar la fase de arranque lento.
También se define una segunda variable llamada umbral, cuyo valor será setteado
como umbral = VentanaCongestion / 2. Es decir, el valor de umbral será igual al
valor anterior de VentanaCongestion, para la cual no hubo pérdida de paquete.
2. Si el valor de VentanaCongestion llega a ser igual a umbral, se pasa al modo de
“evitación de la congestión”.
 3. Si se reciben 3 ACK duplicados, TCP resuelve esto con una retransmisión rápida y
entra en “recuperación rápida”. El valor de umbral pasa a ser VentanaCongestion/2,
y VentanaCongestion = umbral + 3.

EVITACIÓN DE LA CONGESTIÓN

En este estado, en lugar de duplicar el valor de VentanaCongestion por cada RTT, lo que se
hace es aumentar en 1 el valor de la ventana por cada RTT.
El crecimiento lineal debe terminar cuando:
1. Se produce una pérdida de paquete, indicada por un fin de temporización. En este
caso se establece el valor de la ventana en 1 MSS, el valor de umbral =
VentanaCongestion / 2, y se pasa a “arranque lento”.
2. Si se reciben 3 ACK duplicados, TCP realiza una retransmisión rápida y entra en
“recuperación rápida”. El valor de umbral pasa a ser VentanaCongestion/2, y
VentanaCongestion = umbral + 3.

RECUPERACIÓN RÁPIDA

En esta fase, TCP aumenta en 1 MSS por cada ACK duplicado del paquete que obligó a
TCP a entrar en este estado. Se sale de este modo si:
1. Llega un ACK para el paquete que se había perdido. En este caso, se pasa a
“evitación de la congestión”.
2. Si se produce un fin de temporización, se pasa al modo de “arranque lento”. umbral
= VentanaCongestion / 2 y VentanaCongestion = 1 MSS.
CIERRE DE CONEXIÓN TCP

Además de establecer conexión para enviar los datos, después hay que cerrar la conexión.
Para esto, en lugar de usar los flags SYN / ACK, se usan los flags FIN / ACK. FIN y SYN no
llevan datos. A modo de reconocimiento se toma como si fuera un byte.
Podemos observar que en este caso también se utiliza el flag ACK para confirmar.

Es importante aclarar que la conexión es full-duplex y por ende debe cerrarse de ambos
lados. Por ende, podemos decir que cada lado tiene que hacer una “half-close” (media
finalización). Si un proceso cierra la conexión, aún puede seguir recibiendo información, lo
cual justamente se usa para cerrar la sesión del otro lado también. Cuando el otro lado
envíe una señal de FIN, la conexión se cerrará totalmente.

El proceso de cierre de conexión puede tener 3 o 4 pasos:

A diferencia del saludo de tres vías, las dos partes tienen que cerrar sesión. Ambas
partes van a mandar un FIN (osea, cliente y servidor), y tiene que haber un ACK para las
dos partes.
- Tiene 3 pasos en caso de: El primero manda FIN. El segundo manda el ACK
correspondiente a dicho FIN, y también manda su propio FIN. Finalmente el primero
manda un ACK, correspondiente al FIN del paso 2.
- Tiene 4 pasos en caso de: El primero manda FIN. El segundo manda el ACK
correspondiente a dicho FIN. Cuando está listo para cerrar la sesión, manda su
 propio FIN. Finalmente el primero manda un ACK, correspondiente al FIN del paso
3.

El fin lo puede arrancar tanto el sv como el cliente. Si el cliente manda FIN, cuando llega el
mensaje, la capa de transporte lo desempaqueta, ve que hay un pedido de cierre de
conexión, entonces pasa la información a la aplicación subyacente. Cuando la aplicación
está lista, recién ahí le dice a la capa de transporte que también solicite el fin de conexión.
Va a depender de la aplicación (que tan rápido actúe), ver si en el segundo paso se manda
solo ACK o también se manda FIN.

PROGRAMACIÓN SOBRE SOCKETS

Un socket se lo puede ver como una interfaz entre la capa de aplicación y la capa de
transporte.

Los sockets tienen que ser programados explícitamente por el usuario. Tienen que ser
creados por el usuario. Al momento de la creación se puede asociar un puerto aleatorio (va
a ser mayor a 1024), o puede ser uno especificado por el programador (si el puerto ya está
reservado, entonces no se va a poder).

Cuando una persona crea un socket, puede crear distintos tipos de sockets: TCP y UDP.
En UDP el socket se identifica por IP del receptor y puerto destino. Hacia un mismo socket,
UDP puede recibir distintos paquetes que provienen de distintos orígenes.

En TCP un socket receptor va a estar definida tanto por IP del emisor y receptor y número
de puerto emisor y receptor. Cuando se intenta crear una conexión TCP, durante el
segundo paso del saludo de tres vías, el servidor crea un nuevo socket (un nuevo hilo) para
que este socket mantenga la conexión establecida que se está pidiendo, y el puerto que
estaba en estado “LISTEN” pueda seguir escuchando por nuevas conexiones.
La manera de trabajar de TCP resulta mucho mas “pesada” para el servidor. Sobretodo si
se establecen 10 conexiones no persistentes, donde la cantidad de sockets creados para
una comunicación, es 1 por cada objeto que se va a transmitir. Por esta razón es mucho
mejor usar conexiones persistentes.

INFORMACIÓN ADICIONAL

Dos ejemplos de opciones que se pueden negociar son:

- Información que sirve para el control de flujo (RcvWindow o Ventana de Recepción). Que
representa el tamaño en bytes que el receptor está dispuesto a recibir sin que se produzcan
desbordamiento de buffers.

- Buffer y los tamaños de segmentos máximos (MMS) son otras de las opciones que se
pueden negociar en una conexión TCP. Este tamaño depende de la implementación de
TCP que hagan los sistemas operativos de los host que intervienen en la comunicación.

Capítulo 4 - Capa de Red

La capa de red es la tercera capa de la pila de protocolos TCP/IP. Su tarea es mover los
paquetes de host a host. Podemos afirmar que tiene dos funciones básicas:

- Encaminamiento (routing): determinar la ruta tomada por los paquetes desde su

origen a su destino, utilizando algoritmos de ruteo para decidir el mejor camino a
seguir. Naturalmente, el mejor camino a seguir será aquel que tenga menor retardo
hasta llegar a destino.
- Reenvío: cuando un paquete llega a un router, el router debe decidir por cuál de sus
interfaces enviarlo, para que llegue a su destino.

Si bien esas son las funciones principales que podemos ver en internet, la capa de red tiene
una tercer función principal, la cual se denomina “establecimiento de llamada”. Se usa para
las redes de circuitos virtuales, y la idea es que se reserve el camino antes de que
empiecen a fluir los paquetes desde su origen a su destino.

El protocolo usado por internet es IP. Cada componente de internet que tenga capa de red,
tiene que saber trabajar con el protocolo IP. Vale aclarar que no solo los host emisor y
destino implementan dicha capa, otro elemento importante es el router (sobre quien recae la
tarea de reenviar los datagramas que llegan desde un enlace de entrada, hacia un enlace
de salida, usando su tabla de reenvío) y switches.
Así como los protocolos de capa de transporte agregan información de cabecera, donde lo
mas destacado es las direcciones de puerto, lo mas destacado de la información agregada
por IP es las direcciones IP origen y destino.
Consideremos ahora algunos de los posibles servicios que podría garantizar la capa de red:

- Entrega garantizada.
- Entrega garantizada con retardo limitado: No solo garantiza la entrega del paquete,
sino que tendrá un límite de retardo especificado de host a host.
- Entrega de los paquetes en orden.
- Ancho de banda mínimo garantizado.
- Fluctuación máxima garantizada.
- Servicios de seguridad.

Ahora, hay que afirmar que la capa de red proporciona un único servicio de mejor esfuerzo.
Esto quiere decir que la temporización no está garantizada, tampoco está garantizado que
los paquetes se reciban en el orden en que fueron enviados y tampoco se garantiza la
entrega de paquetes transmitidos.

Comparación entre red de datagramas y red de circuito virtual

Una red de circuito virtual se comporta al estilo de una red telefónica. Hay 3 fases:
- Establecimiento del CV: el emisor contacta con la capa de red, especifica la
dirección del receptor y espera que se establezca el CV. La capa de red determina la
ruta completa entre ambos host, lo cual suele implicar la actualización de las tablas
de ruteo de los routers del camino. También durante esta fase es que el camino
queda reservado.
- Transferencia del dato: con el camino establecido, la información fluye entre los host.
- Descarte del CV: una vez que terminó de fluir la información, ya no es necesario que
el camino siga reservado. En este momento la capa de red informa al otro extremo
de la conexión sobre el final de la conexión, y se vuelven a actualizar las tablas de
ruteo de los routers del camino.

Vale destacar que a diferencia del establecimiento de conexión TCP, en el caso de los CV,
los routers son conscientes de la existencia la conexión. Los mensajes enviados para el
establecimiento o cierre de conexión se denominan “mensajes de señalización”.

Por otro lado, con una red de datagramas, cada vez que un host desea enviar un paquete a
un host destino, tiene que establecer la dirección destino y depositarlo en la red, sin
necesidad de establecer ningún tipo de conexión previa. Los routers no guardan ningún tipo
de información asociada al camino, sino que cada router, al recibir un paquete, debe
examinar su tabla de ruteo y decidir porque puerta de enlace lo envía. Además, en la
conmutación de paquetes los distintos paquetes que tienen un mismo origen y destino
pueden no seguir el mismo camino y es por eso que todos requieren tener la información de
destino.
Los routers utilizan la tabla de reenvío usando la coincidencia de prefijo. La idea básica es
que un router va a tener distintas redes en cada uno de sus enlaces, que básicamente son
las entradas en su tabla, y el paquete que llega va a tener una dirección destino. El router
usa esa dirección de destino y lo compara con las entradas de su tabla. En caso de
coincidencia de los primeros K bits entre alguna red directamente conectada y la dirección
destino del paquete, entonces envía el paquete por dicho enlace de salida.
Puede ser que varias entradas en la tabla tengan coincidencia en el prefijo de las
direcciones y en tal caso, se aplica la regla de coincidencia con el prefijo mas largo.

La tabla de enrutamiento crece a medida que pasan nuevos paquetes por la entrada del
router. Si la dirección de red destino era hasta el momento desconocida, se agrega una
entrada en la tabla. Vale aclarar que esta tabla está en cada puerto de entrada, en lugar de
ser una tabla general para el router. De esta forma la decisión de reenvío puede tomarse
localmente en cada puerto.

Una última aclaración sobre los routers, es que cada enlace tiene asociada un buffer de
recepción. A medida que estas colas crecen, el espacio disponible en el buffer del router
terminará agotándose y se producirá una pérdida de paquetes, debido a que al no haber
lugar disponible para almacenamiento, los mismos debe ser descartado.

PROTOCOLO DE INTERNET (IP): REENVÍO Y DIRECCIONAMIENTO EN INTERNET

Actualmente hay dos versiones de IP en uso, IPv4 e IPv6.

La capa de red tiene tres componentes básicos:

- IP
- El componente de enrutamiento
- El protocolo de información de control y de errores, ICMP.

El formato de un datagrama IPv4 es:

Las direcciones IPv4 tienen 32 bits de longitud, lo cual nos da un total de 2^32 direcciones
IP posibles. Como se dijo antes, una parte de la dirección se puede destinar a identificar
red, y una parte a host. Para identificar qué bits son de red y qué bits son de host, se usa el
concepto de máscara de subred. La máscara indica cuántos bits se toman como dirección
de red.

FRAGMENTACIÓN DEL DATAGRAMA IP

Algunos protocolos de capa de enlace pueden transportar mas información que otros
(Ethernet por ejemplo puede transportar hasta 1500 bytes de datos). La cantidad de datos
que una trama de la capa de enlace puede transportar se conoce como unidad máxima de
transmisión (MTU).

Puesto que cada datagrama IP se encapsula dentro de una trama de la capa de enlace para
ir de un router al siguiente, la MTU del protocolo de la capa de enlace impone un límite
estricto a la longitud del datagrama IP. El problema de esto es que cada uno de los enlaces
existentes a lo largo de la ruta entre el emisor y el destino pueden usar diferentes protocolos
de capa de enlace, y por ende, tener MTU distintos.

La solución que da IP a esto es la posibilidad de que un router fragmente la información en

trozos mas chicos, con el fin de poder seguir avanzando. Vale aclarar que la cabecera IP
tiene un campo “No fragmentar”, que si está puesto a 1, se indica que los routers no deben
fragmentar el datagrama: directamente lo descartan. La razón de esto es que el receptor no
sabe desfragmentar.

Para la fragmentación, son importantes: ID, corrimiento y bit indicador de fin. Con el número
de identificación, identificamos todos los fragmentos que eran parte de un mismo
datagrama. Con el corrimiento podemos ir viendo en qué posición del datagrama IP original
encaja el fragmento. Con el bit indicador, si está puesto a 0 y los anteriores están en 1,
significa que ese fragmento es el último.

DIRECCIONAMIENTO IP Y CLASES

Inicialmente se asignaban direcciones basadas en clases a las redes. Sin embargo, esto
agotó rápidamente tanto a las redes de clase A como a las redes de clase B. También es
destacable la diferencia entre la cantidad de host direccionables entre las distintas redes, lo
cual implica que por ejemplo, para una red, una dirección de red de clase C puede ser
chica, pero una de clase B puede ser extremadamente grande, desperdiciando así muchas
direcciones.
MOTIVACIÓN PARA SUBNETTING

Se hizo evidente que la asignación basada en clases era ineficiente para la asignación de
direcciones de red. Por ello se pensó una estrategia para reducir al mínimo el desperdicio
de direcciones IP y fue así como se creó el concepto de subnetting.
Básicamente, la división en subredes plantea que si una red de clase desperdicia muchas
direcciones IP entonces la misma sea dividida en N subredes más pequeñas que
aprovechen mejor el espacio de direccionamiento.

Con el uso de redes con clases, la máscara estaba implícita en la dirección de clase, pues
se conocía a priori los bits para red y los bits para host. Cuando se creó el concepto de
subredes también se les asoció una máscara de subred, que resultó de utilizar algunos bits
de hosts para crear subredes y de esta manera obtener varias subredes con menos hosts
cada una.

CIDR: ENRUTAMIENTO ENTRE DOMINIOS SIN CLASE

El concepto de CIDR (classless inter-domain routing) se definió en la RFC 1519 como una
estrategia para frenar algunos problemas que se habían comenzado a manifestar con el
crecimiento de Internet. Los mismos son:
- Agotamiento del espacio de direcciones de clase B.
- Crecimiento de las tablas de enrutamiento más allá de la capacidad del software y
hardware disponibles.
- Eventual agotamiento de las direcciones IP en general.

CIDR consiste básicamente en permitir máscaras de subred de longitud variable (VLSM)

para optimizar la asignación de direcciones IP y utilizar resumen de rutas para disminuir el
tamaño de las tablas de enrutamiento.

La técnica de VLSM (variable-length subnet masking) consiste en realizar divisiones en

subredes con máscaras de longitud variable y es otra de las técnicas surgidas para frenar el
agotamiento de direcciones IPv4. Básicamente, VLSM sugiere hacer varios niveles de
división en redes para lograr máscaras más óptimas para cada una de las subredes que se
necesiten.

Los pasos para dividir en subredes utilizando VLSM son:

● Subnetear para la red con mayor cantidad de hosts.

● De las subredes obtenidas, asignar todas las que se puedan con el menor
desperdicio posible.
● Si aún quedan segmentos de red sin una subred asignada volver al paso 1.

CÓMO OBTENER UNA DIRECCIÓN DE HOST: DHCP

Las direcciones de host se pueden configurar manualmente, o se pueden configurar con el

Protocolo de configuración dinámica de host (DHCP).
Este protocolo permite a un host obtener automáticamente una dirección IP. Un
administrador de red puede configurar DHCP para que dado un host, cada vez que se
conecte a la red, siempre se le asigne la misma dirección IP, o un host puede tener
asignada una dirección IP temporal que será diferente cada vez que el host se conecte a la
red. Además de la dirección de host, DHCP también permite que el host nuevo en la red
obtenga su máscara de subred, la dirección del router de primer salto y la dirección de su
DNS local.

DHCP es un protocolo plug-and-play (conectar y funcionar).

El uso típico de este protocolo es en redes donde los host se conectan y desconectan con
mucha frecuencia. A medida que los host se unen a la red y salen de ella, el servidor DHCP
necesita actualizar su lista de direcciones IP disponibles. Cada vez que un host se une a la
red, el servidor DHCP asigna una dirección arbitraria de su conjunto actual de direcciones
disponibles; cada vez que un host abandona la red, su dirección es devuelta al conjunto.

En el caso mas simple, cada subred tendrá un servidor DHCP (puede tener mas). Si no hay
ningún servidor DHCP, es necesario un agente de retransmisión DHCP (normalmente el
router) que conozca la dirección de un servidor DHCP para dicha red.

DHCP es un protocolo de 4 pasos:

- Descubrimiento del servidor DHCP. Se hace con un mensaje de descubrimiento
DHCP, que envía un cliente dentro de un paquete UDP al puerto 67. El paquete
UDP se encapsula en un datagrama IP. El cliente DHCP crea un datagrama IP que
contiene su mensaje de descubrimiento DHCP junto con una dirección IP de difusión
255.255.255.255 y una dirección IP de origen de “este host” igual a 0.0.0.0. El cliente
DHCP pasa el datagrama IP a la capa de enlace, la cual difunde esta trama a todos
los nodos conectados a la subred.
- Ofertas del servidor DHCP. Un servidor recibe un mensaje de descubrimiento DHCP
y responde con un mensaje de oferta DHCP, que se difunde a todos los nodos de la
red usando denuevo la dirección IP de difusión 255.255.255.255 (no puede
responder directamente al cliente porque el cliente no tiene dirección IP aún). Si hay
varios servidores DHCP, el cliente recibirá mas de un mensaje de oferta, y debe
elegir uno. Los mensajes de oferta tienen el ID de transacción del mensaje de
descubrimiento recibido, la IP propuesta para el cliente, la máscara de red, y el
tiempo de arrendamiento de la dirección IP (normalmente horas o días).
- Solicitud DHCP: el cliente recién llegado seleccionará entre las ofertas de servidor y
responderá la oferta seleccionada con un mensaje de solicitud DHCP devolviendo
los parámetros de configuración.
- ACK DHCP: el servidor responde al mensaje anterior del cliente con este mensaje,
que confirma los parámetros solicitados.

El cliente tiene asignada ahora la dirección IP en cuestión. Antes de que el tiempo se venza,
puede solicitar una extensión de este tiempo.

TRADUCCIÓN DE DIRECCIONES DE RED (NAT)

El crecimiento de la demanda de direcciones IPv4 se dió con la llegada de múltiples
dispositivos que pueden conectarse a internet. Debido a esto, ahora cualquier red necesita
de una gran cantidad de direcciones IP para todos los dispositivos que, potencialmente,
podría albergar.

El problema es que las direcciones IPv4 se están agotando, y como parte de la solución a
este problema, se puede usar NAT. ¿Para qué sirve?

- Sirve para ahorrar direcciones IPv4 públicas.

- Para transformar direcciones privadas en direcciones públicas. De esta forma es
posible conectar un host de una red privada con otro host de otra red privada (a
través del router NAT).
- Se puede utilizar el router como intermediario (da una sensación de “seguridad”,
aunque no siempre es verdad).

Consiste en convertir en tiempo real las direcciones utilizadas en los paquetes

transportados. Su uso mas común es permitir utilizar direcciones privadas para acceder a
internet.
Un router NAT cambia la dirección origen de cada paquete de salida y dependiendo del
método, también cambia el puerto origen, para que sea único. Estas traducciones se
almacenan en una tabla, para recordar qué dirección y puerto le corresponde a cada
dispositivo cliente y así saber donde deben regresar los paquetes de respuesta.

Las formas de funcionamiento NAT son:

- NAT básico:
- Estática: la dirección IP privada se traduce a una IP pública, que siempre es
la misma. Esto le permite a un host, como un servidor web, tener una
dirección IP de red privada pero aún así ser visible en Internet.
- Dinámica: es un tipo de NAT en la que la dirección IP privada se mapea a
una IP pública basándose en una tabla de direcciones IP registradas
(públicas). Es decir, cuando un nuevo dispositivo necesita una IP pública
para salir a la red, el router NAT revisa la tabla y le asigna una IP que todavía
no esté en uso. Requiere un conjunto de redes públicas para ir asignando.
- NAPT (Network Address Port Translation) (también, y más comúnmente denominada
PAT): Se utilizan los puertos de los protocolos u otros valores como ICMP Identifier
para resolver el mapeo. Se intenta conservar el puerto origen, pero si está ocupado
se asigna otro. La tabla entonces tiene una relación entre IP pública y número de
puerto público, e IP privada y número de puerto privado.

Entonces, el router NAT oculta los detalles de la red doméstica al mundo exterior.
Vale aclarar, que el router NAT obtiene su dirección del servidor DHCP y a su vez, la red
privada obtiene sus direcciones gracias a que el router NAT ejecuta un servidor DHCP.

La RFC 1918 se relaciona con NAT, porque NAT permite transformar direcciones privadas
en públicas. Esta RFC especifica rangos de direcciones privadas por clases (IPv4):
PROTOCOLO DE MENSAJES DE CONTROL EN INTERNET (ICMP)

Se emplea en hosts, routers y pasarelas para comunicar información de la capa de red de

uno a otro. El uso mas común de ICMP es el de informes de error.

ICMP suele considerarse parte de IP, pero arquitectónicamente se halla justo sobre IP,
dado que los paquetes ICMP viajan en el interior de los paquetes IP. Cuando un host recibe
un paquete IP donde se especifica ICMP como protocolo de capa superior, este
demultiplexa el paquete a ICMP, de la misma forma que demultiplexaría un paquete a TCP
o UDP.

Los mensajes ICMP tienen un campo tipo y un campo de código. También cuentan con los
8 primeros bytes del datagrama IP que provocó el envío del mensaje ICMP en primer lugar.

Un mensaje curioso de ICMP es el de apaciguamiento de la señal, que no suele usarse. Su

propósito original era proporcionar un control de congestión, permitiendo que un router
congestionado enviara este mensaje al host emisor, pidiéndole que reduzca su tasa de
transmisión. Este mensaje no se usa porque TCP tiene su propio mecanismo de control.
El comando ping nos permite saber el tiempo exacto que tardan los paquetes de datos en ir
y volver a través de la red, desde nuestra PC a un host remoto. Se suele utilizar digitando
en la línea de comandos “ping + ip_destino”.

Con el comando traceroute podemos trazar una ruta desde un host a cualquier otro host del
mundo. Usa UDP, y un número de puerto destino poco probable. La idea es usar el TTL, el
cual nos indica la cantidad de saltos que puede realizar un paquete. El cliente enviará
muchos paquetes, cada cual con un valor de TTL mayor al anterior, con la idea de que el
paquete esté un paso mas cerca del destino. Cada vez que el paquete pasa por un router,
el router decrementa el valor de TTL. Si llega a 0, entonces el router descarta el datagrama
y envía un mensaje al cliente con un mensaje ICMP tipo 11, código 0. Cuando el paquete
llegue a destino, tendrá su TTL en 0, y es esperable que el puerto destino no coincida con
un puerto UDP en estado Listen. En ese caso, el host destino enviará un mensaje ICMP tipo
3, código 3, y el host cliente sabrá que efectivamente el paquete llegó a destino.

IPv6

El espacio de direcciones de IPv4 se estaba agotando (necesitó de técnicas como CIDR y

NAT). Para resolver esto, se desarrolló IPv6.

Los cambios mas importantes introducidos en IPv6 son evidentes en el formato de su

datagrama:
- Capacidades ampliadas de direccionamiento. El tamaño de la dirección es de 128
bits, muy por encima de los 32 de IPv4.
- Cabecera de 40 bytes simplificada. Permite un procesamiento mas rápido del
datagrama IP.
- Prioridad y etiquetado del flujo: permite etiquetar paquetes que pertenecen a
determinados flujos para los que el emisor solicita un tratamiento especial, como un
servicio en tiempo real o una calidad de servicio no predeterminados.

Las diferencias mas grandes con IPv4 son:

- Fragmentación/Reensamblado: IPv6 no permite la fragmentación ni el reensamblado
en routers intermedios; estas operaciones solo pueden ser realizadas por el origen y
el destino. Si un router recibe un datagrama IPv6 y es demasiado largo para ser
reenviado por un enlace de salida, el router simplemente lo descarta y envía de
 vuelta al emisor un mensaje de error ICMPv6 “paquete demasiado grande”. Se
eliminaron por el consumo excesivo de tiempo.
- Suma de comprobación de cabecera: Esta funcionalidad ya era suficientemente
redundante en la capa de red y podía eliminarse. Recordar que dado que la
cabecera de IPv4 tiene un campo TTL (similar al campo Límite de Saltos de IPv6), la
suma de comprobación de cabecera de IPv4 necesitaba ser recalculada en cada
router, lo cual era muy costoso.
- Opciones: ya no hay campo opciones. En su lugar, el campo opciones es una de las
posibles siguientes cabeceras apuntadas desde dentro de la cabecera IPv6. Es
decir, al igual que las cabeceras de TCP o UDP pueden ser la siguiente cabecera,
también puede serlo un campo de opciones.

En el documento RFC 4443 se ha definido una nueva versión de ICMP para IPv6. Además de
reorganizar las definiciones de tipos y códigos ICMP existentes, ICMPv6 también añadió nuevos tipos
y códigos requeridos por la nueva funcionalidad de IPv6, entre los que se incluyen el tipo “Paquete
demasiado grande” y el código de error “Opciones IPv6 no reconocidas”. Además, ICMPv6 incluye la
funcionalidad del Protocolo de gestión de grupos de Internet (IGMP, Internet Group Management
Protocol) que se emplea para gestionar el modo en que un host se une a un grupo de multidifusión y
lo abandona, anteriormente era un protocolo separado de ICMP en IPv4.

RUTEO EN INTERNET

El ruteo se refiere a la tarea de la red de determinar un camino entre un par de host que
quieren comunicarse.

Es esencial hablar del router. Es un dispositivo de capa de red encargado de interconectar

redes, lo cual quiere decir que para que dos host que están en redes distintas puedan
comunicarse necesitan la ayuda de un router.
Las principales funciones del router son:
- Determinar el camino de un paquete entre un host y otro.
- Dado un conjunto de routers con enlaces entre ellos, debe encontrar un buen
camino (de coste mínimo).

Existen 3 maneras de clasificar a los algoritmos de ruteo:

La primer clasificación los divide en algoritmos estáticos o dinámicos:

- Los algoritmos estáticos son aquellos donde las rutas cambian muy lentamente en el
tiempo. A menudo el cambio es por intervención humana.
- Los algoritmos dinámicos son aquellos que pueden responder al estado actual de la
red, cambios en la topología, y cambios en los costes de los enlaces. Si bien son
mejores que los estáticos en el sentido de resolución de problemas que se puedan
presentar, tienen problemas de bucles de rutado y oscilación entre rutas.

La segunda clasificación nos habla de algoritmos sensibles o no a la carga:

 - Un algoritmo sensible a carga, es aquel que puede tomar decisiones sobre las rutas
a seguir por los paquetes, en base a la cantidad de tráfico. Si se ve que hay
congestión en un determinado punto, se puede optar por enviar el paquete por otro
camino, a fin de evitar que la congestión en ese punto aumente.
- Los algoritmos de internet de hoy en día son insensibles a la carga, ya que el coste
de un enlace no suele reflejar su nivel de congestión actual.

La tercer y última clasificación, es sobre algoritmos globales o descentralizados:

- Un algoritmo global es aquel que toma las decisiones en base a su conocimiento

completo de la red. Para esto, el algoritmo toma como entradas la conectividad entre
todos los nodos y el coste de los enlaces (notar que debe obtener esta información
antes de comenzar el cálculo).
- Un algoritmo descentralizado es aquel realiza los cálculos de forma distribuida,
asíncrona, e iterativa. Tiene su nombre porque ningún nodo tiene la información de
toda la red para realizar los cálculos, sino que cada nodo calcula en base a sus
vecinos e informa a los demás de estas distancias. Así, todos los nodos terminan
usando la información propia y la enviada por sus vecinos para poder establecer una
tabla que contiene el camino mínimo hacia todos los nodos.

En este punto, podemos hablar del “Algoritmo de estado de enlaces” y

“Algoritmo de vector distancia

ALGORITMO DE ESTADO DE ENLACES

Algoritmo de ruteo global, en donde la topología de la red y el coste de todos los enlaces
son conocidos. Esto se logra haciendo que nada nodo difunda paquetes del estado de los
enlaces a todos los demás nodos de la red, con cada paquete de estado de enlace
conteniendo las entidades y los
costes de sus enlaces conectados.
Este algoritmo también se
denomina algoritmo de Dijkstra.
Básicamente calcula la ruta de
coste mínimo desde un nodo a
todos los demás nodos de la red.
Es iterativo y tiene la propiedad de
que después de la k-ésima iteración
del algoritmo, se conocen las rutas
de coste mínimo hacia k nodos de
destino y entre las rutas de coste
mínimo a todo los nodos de destino,
estas k rutas tendrán los k costes
mas pequeños. La complejidad de
este algoritmo es de O(n^2).

ALGORITMO DE VECTOR
DISTANCIAS
Es un algoritmo de ruteo descentralizado. Es distribuido porque ningún nodo tiene
conocimientos de toda la red y en su lugar, recibe cierta información de uno o mas vecinos.
Es iterativo porque este proceso continúa hasta que no se intercambia mas información
entre los vecinos, y es asíncrono porque no precisa que los nodos operen al unísono.
La estructura de datos de este algoritmo es la tabla de distancias, que se mantiene en cada
nodo. La tabla dispone de una fila para cada destino de la red y de una columna para cada
uno de sus vecinos. Básicamente, cada nodo debe conocer el coste del camino hacia sus
vecinos. Una vez que lo conoce, debe informar a los demás. También debe aceptar la
información de los demás nodos y actualizar su tabla de caminos mínimos si es necesario.

ENRUTAMIENTO EN INTERNET Y SISTEMAS AUTÓNOMOS

Es un conjunto de redes (teniendo en cuenta los distintos dispositivos que pueden

conformar una red) bajo la misma administración, y que utilizan un protocolo de pasarela
interno (IGP) o combinación de IGP para rutear internamente. Casa SA debe tener un
número identificador, solucionar los problemas de escala, y autoridad administrativa.

Un SA realiza su propia gestión del tráfico que interno, y del que fluye hacia otros sistemas
autónomos.

Todos los routers que forman parte del mismo sistema autónomo ejecutan el mismo
algoritmo de ruteo y tienen información de los otros routers. Los algoritmos de ruteo internos
son conocidos como Intra-Autónomo. Los algoritmos de ruteo entre sistemas autónomos se
denominan Inter-Autónomo.

Los SA permiten el ruteo jerárquico, lo cual significa que una dirección IP puede ser dividida
en dos partes: una dirección de red, y una dirección de host (dos niveles de jerarquía de
ruteo). Los gateways usan únicamente la parte de red hasta que un datagrama IP llega a un
gateway que puede entregar el paquete directamente al host. También permiten subredes,
lo cual agrega mas niveles a la jerarquía de ruteo.

Las ventajas de tener un sistema autónomo son:

- Escala: según crece el número de routers, las sobrecargas debidas al cálculo,

almacenamiento y comunicación de la información de rutado se vuelven prohibitivas.
- Autonomía administrativa: Para que cada entidad pueda operar sus routers
libremente (ejemplo ejecutar el algoritmo de rutado que desee) u ocultar aspectos de
la organización interna de sus redes al exterior.

Cada SA se conecta a un router de borde que los conecta a otros. Para la conexión entre
sistemas autónomos se suele usar algún algoritmo EGP (Exterior Gateway Protocol).

RUTADO INTRA-SISTEMA: RIP Y OSPF

RIP: PROTOCOLO DE INFORMACIÓN DE RUTADO

Es un protocolo de vector distancias. Usa el recuento de saltos como métrica de coste,
es decir que cada enlace tiene coste 1. El coste máximo del camino está limitado a 15, por
lo que se limita el alcance de RIP a SA que tengan un diámetro de 15 saltos o menos.

Las actualizaciones de ruteo se intercambian entre vecinos cada 30 segundos

aproximadamente, empleando lo que se llama “mensaje de respuesta RIP”. Este mensaje
contiene una lista de hasta 25 redes destinos dentro del SA, así como también la distancia
del emisor a cada una de esas redes. Los mensajes de respuesta también se conocen
como anuncios RIP.
Si un router no tiene noticia de algún vecino en 180 segundos, considerará que el vecino ya
no está al alcance (por ejemplo, por un enlace caído). Cuando esto ocurre, RIP modifica la
tabla de encaminamiento local y propaga esta información enviando anuncios RIP a sus
routers activos.

También es posible que un router pida información a su vecino sobre el coste hacia cierto
destino, mediante un mensaje de petición RIP.

Los mensajes de petición y respuesta viajan sobre UDP, al puerto 520.

OSPF: PRIMERO EL CAMINO ABIERTO MAS CORTO.

OSPF fue pensado para ser el sucesor de RIP y por eso tiene varias características
avanzadas.
Es un protocolo de estado de enlaces, en el cual la información fluye y los caminos
mínimos son decididos gracias al algoritmo de Dijkstra. Al usar este algoritmo, cada nodo
necesita crear un grafo del sistema autónomo completo. Cada red entonces va a usar
Dijkstra para hacer un árbol de caminos mínimos hacia todas las redes del SA, que va a
usar después para su tabla de caminos mínimos.

El administrador de la red puede decidir cómo manejar el peso de los enlaces: puede decidir
por ejemplo poner todos a 1, y que el coste del camino sea igual al número de saltos.

Cada router difunde información a todos los nodos de la red cuando quiere que haya algún
cambio (por ejemplo, un cambio de coste). Los mensajes OSPF van sobre IP, que envuelve
un paquete OSPF, lo cual nos indica que este algoritmo tiene también su propio protocolo
de transmisión de información que debe asegurarse de lograr una transferencia de datos
fiable.
Algunos avances de OSPF son:
- Seguridad en todos los intercambios de información. Solo los routers fiables van a
poder acceder a la información enviada por OSPF, gracias a un sistema de
autenticación.
- Múltiples caminos con el mismo coste. Se refiere a que cuando hay varios caminos
con el mismo coste, OSPF elegirá al azar, con el fin de no sobrecargar una zona de
la red.
- Soporte integrado para rutado por unidifusión o multidifusión.
- Soporte en la jerarquía de un único dominio de rutado.
Los SA se pueden configurar en áreas. Cada área puede ejecutar su propio algoritmo de
estado de enlaces OSPF, donde cada router difunde su estado de enlaces al resto de los
routers de esa área. Los detalles internos de cada área son invisibles desde afuera. El
rutado intra-área involucra solo a aquellos routers de la misma área.
Además, el SA configura un área como “Área troncal”, cuya función primordial es enrutar el
tráfico entre el resto de las áreas del SA.

INFORMACIÓN ADICIONAL

Una computadora puede calcular su dirección IPv6 a partir de su MAC (No usa protocolo ARP)

La dirección MAC es un identificador de 48 bits (6 bloques de dos caracteres hexadecimales (4 bits))

que corresponde de forma única a una tarjeta de red. Es única para cada dispositivo.
Existen distintas categorías de direcciones IP en IPv6. Una de estas categorías es las link-local. Una
dirección IPv6 calculada a partir de una MAC es una de tipo link-local, y solo se pueden usar para
comunicaciones dentro de una subred local. Los routers no enrutan paquetes con direcciones de
enlace local. En IPv6 las direcciones de enlace local son necesarias para el funcionamiento de varios
componentes del protocolo.
Las direcciones de enlace local IPv6 tienen la forma: FE80::X/64.

Para convertir las MAC en IPv6, se usa el proceso EUI-64, el cual consta de los siguientes pasos:

Las MAC tienen 48 bits. Los primeros 24 son OUI (identificador único de organización), y los
últimos 24 son identificador de dispositivo.

● Paso 1: Dividir la dirección MAC entre el OUI y el identificador de dispositivo

● Paso 2: Insertar el valor hexadecimal FFFE, que en formato binario es: 1111 1111 1111
1110. Esto representa los restantes 16 bits para completar la dirección de 64 bits. (La MAC
tiene 48 + 16 = 64).
● Paso 3: Convertir los primeros dos valores hexadecimales del OUI a binario e invertir el bit
U/L (séptimo bit) En este ejemplo, el 0 en el bit 7 se cambia a 1.

Las direcciones IPv6 se clasifican en: unicast, anycast y multicast.

- Una dirección unicast identifica a un único interfaz de red. El protocolo de internet entrega los
paquetes enviados a una dirección unicast al interfaz específico.
- Una dirección anycast es asignada a un grupo de interfaces, normalmente de nodos
diferentes. Un paquete enviado a una dirección anycast se entrega únicamente a uno de los
miembros, típicamente el host de menos coste. Cualquier dirección unicast puede usarse
como anycast (la única diferencia, es que las anycast son varias).
- Las multicast son usadas por múltiples interfaces también. Consiguen esta dirección
participando de un grupo de multidifusión (multicast) entre los routers de la red. Un paquete
enviado a una dirección multicast es entregado a todos los interfaces que se hayan unido al
grupo multicast correspondiente. En IPv6 no hay broadcast, se usa multicast (ff01::1, que es
“all nodes”). Los primeros dos dígitos hexadecimales son FF.

Dentro de la categoría unicast, existen:

- Link local: equivalentes a IP privadas en IPv4. El prefijo es FE80::/10. No pueden ser
encaminadas en routers fuera del segmento local. Los primeros 10 bits (por eso el /10) se
usan para formar FF8, los siguientes bits tienen valores 0, consiguiendo que el prefijo de red
sea el mismo para todas las direcciones locales y por tanto, no sea enrutable.
FE80:0000:0000:0000:0000:0000:0000:0000/10 → Porción de red.
 Los últimos 64 bits son la porción de nodo, la cual se forma con EUI-64 (explicado
previamente).
- Site local: también equivalentes a las IPv4 privadas. Pueden ser encaminadas fuera del
segmento local, pero no hacia internet. El prefijo es FEC0::/10. El procedimiento es el mismo
que las link-local.
- Global: equivalentes a las públicas de IPv4. Pueden ser encaminadas a través de la red.
Tienen un valor hexadecimal de 2xxx, con una máscara /3.

Para multicast, los cuatros bits menos significativos del segundo octeto de una dirección multicast
(ff0X::) identifican el ámbito, es decir, hasta dónde se propaga el tráfico multicast. Los ámbitos
definidos actualmente son:

La idea será que cada host pueda autoconfigurar su dirección IPv6 sin usar DHCP. Para esto,
usando EUI-64 genera los 64 bits menos significativos de su dirección IP, y usar la dirección de red
(enviada periódicamente por el router) como 64 bits mas significativos. La unión, me genera una
dirección IPv6 de 128 bits.
TABLAS DE ENRUTAMIENTO

Los routers tienen mas de una interfaz de salida, las cuales van a estar conectadas a una red. A su
vez, esta red puede tener dispositivos como hub o switches, los cuales a su vez pueden tener
distintas redes conectadas.

Los routers tienen tablas de enrutamiento, las cuales contienen la información necesaria para que el
router tome las decisiones de reenvío de paquetes hacia la red de destino, utilizando la información
de asociación entre la red y el siguiente salto. Esta tabla está en la memoria RAM del router.

Según lo visto en la materia, las tablas tienen 4 campos:

Destino Gateway Máscara de red Interfaz de salida

Es la red a la cual Es el lugar al que Máscara de la Placa de red por la

quiero llegar. La ruta tengo que enviar el dirección destino. que sale el paquete.
por defecto es la datagrama para llegar En un router hay
0.0.0.0, y es a donde a ese “destino”. varias, en una
se mandan los Normalmente van computadora hay
paquetes que no direcciones de menos.
tienen ruta específica, interfaces de router
lo cual normalmente que me conectan con
se usa para internet. una determinada red.
El destino 0.0.0.0 me
indica que estoy en la
misma red a la cual
quiero enviarle
información (no hace
falta ningún
intermediario).

En la tabla se ponen las redes conectadas directamente, y las formas de llegar a otras redes. Lo que
hacemos en la práctica es enrutamiento estático.

El enrutamiento estático es viable cuando hay pocas máquinas en la red. Cualquier cambio requiere
intervención humana.
El enrutamiento dinámico se usa para grandes redes. A priori, no requiere intervención humana.

Las máquinas conectadas a redes tienen tablas de ruteo (aunque no tengan acceso a internet, ya
que deben comunicarse con los demás nodos de la red), las cuales tienen al menos dos entradas:
- Entrada con un destino 0.0.0.0 y un gateway en particular, que indica a donde mando los
paquetes cuando el destino no está en mi tabla de ruteo.
- Entrada con un destino particular y el gateway 0.0.0.0, que indica que ya estoy en la red con
la cual me quiero comunicar.

Capítulo 5 - Capa de Enlace

La capa de enlace es la responsable de transferir datagramas hacia el otro lado de un

enlace determinado. El protocolo de la capa de enlace define el formato de los paquetes
que se intercambian entre los nodos en los extremos de ese enlace, como también las
acciones a tomar por esos nodos cuando se envían y reciben paquetes.

Al analizar la capa de enlace, nos encontramos con que hay dos tipos de canales
fundamentalmente distintos de la capa de enlace. El primer tipo está compuesto por los
canales de difusión. En un canal de difusión hay muchos hosts conectados a un mismo
canal de comunicaciones, por lo que se hace necesario utilizar lo que se denomina un
protocolo de acceso al medio para coordinar las transmisiones y evitar que las tramas
transmitidas colisionen. El segundo tipo de canal de la capa de enlace es el canal de
comunicaciones punto a punto, como el que existe entre dos routers o entre un módem de
acceso telefónico residencial y el router de un ISP. La coordinación del acceso a un enlace
punto a punto es trivial, pero sigue habiendo problemas importantes relativos al entramado,
a la transferencia de datos fiable, a la detección de errores y al control de flujo.

Un protocolo de la capa de enlace tiene el trabajo de mover un datagrama de la capa de red

sobre un solo enlace del camino. Esto quiere decir que un datagrama puede ser
transportado por protocolos de capa de enlace diferentes a lo largo del camino desde el
host origen al host destino.

Los posibles servicios que puede ofrecer un protocolo de capa de enlace son:

- Acceso al medio y framing: los datagramas de la capa de red deben ser

encapsulados en frames de la cama de enlace antes de transmitirlos por el enlace.
Un frame (también llamados marcos o tramas) consiste en un cuerpo (donde va el
datagrama IP) y una cabecera.
- Transmisión confiable: las tramas que atraviesen el enlace llegarán al destino sin
errores.
- Control de flujo: se busca evitar que el emisor bombardee al receptor.
- Detección de errores: un nodo receptor puede interpretar incorrectamente un bit en
un frame como un cero cuando se ha transmitido un uno (o al revés). Estos errores
son introducidos por la atenuación de la señal y ruido electromagnético. Para esto, el
emisor setea bits de detección de errores en el frame, que serán usados por el
receptor. Este servicio se implementa por hardware.
- Corrección de errores: además de detectar los errores, los puede corregir.
- Half-duplex y full-duplex.

Como puede verse, muchos de los servicios posiblemente proporcionados por la capa de
enlace son similares a los proporcionados por TCP.

En su mayor parte, la capa de enlace se implementa en un adaptador de red (NIC), la cual

implementa muchos de los servicios de esta capa. El corazón de la tarjeta adaptador de red
es el controlador de la capa de enlace, que normalmente es un único chip de propósito
específico.

Si la capa de enlace realiza detección de errores, entonces será el controlador del emisor
quien se encargue de configurar los bits de detección de errores en la cabecera de la trama,
mientras que el controlador del receptor llevará a cabo la detección de errores. Si la capa de
enlace realiza control de flujo, entonces los controladores del emisor y del receptor
intercambian información de control de flujo de modo que el emisor envíe las tramas a una
velocidad que el receptor sea capaz de aceptar.

En el lado receptor, el software de la capa de enlace responde a las interrupciones

procedentes del controlador (por ejemplo, debidas a la recepción de una o más tramas), se
encarga de gestionar las condiciones de error y pasa el datagrama hacia la capa de red. Por
tanto, la capa de enlace es una combinación de hardware y software.

DETECCIÓN DE ERRORES

- SUMA DE COMPROBACIÓN

El objetivo es detectar errores, al igual que la capa de Transporte. En general no es

utilizado ya que no es potente.

- BITS DE PARIDAD
Los códigos de paridad se usan en telecomunicaciones para detectar, y en algunos casos
corregir, errores en la transmisión. Para ellos se añade en origen un bit extra llamado bit de
paridad a los n bits que forman el carácter original.
Este valor del bit de paridad se determina de forma que el número total de bits 1 a transmitir
sea par (código de paridad par) o impar (código de paridad impar).
Así, para el código de paridad par, el número de unos contando el caracter original y el
bit de paridad tiene que ser par. Por lo tanto, el bit de paridad PAR será un 0 si el número
total de unos a transmitir es par y un 1 para un número impar de unos.
Por el contrario, para el código de paridad impar, el número de unos contando el
caracter original y el bit de paridad ha de ser impar. De esta forma, el bit de paridad
IMPAR será un 0 si el número total de unos es impar y un 1 para un número par de unos.
Normalmente el bit de paridad se añade a la izquierda del caracter original.
- DETECCIÓN DE REDUNDANCIA CÍCLICA
Idea: enviar los datos originales más un FCS que me permita decir si los datos
llegaron correctamente. Se supone que antes de la transferencia tanto el receptor como el
emisor deben pactar cuál será el Generador, secuencia de bits que se usará para dividir el
msj y comprobar.

Para enviar:
1. Se obtiene la longitud del FCS, será la longitud del Generador menos 1
2. Se le agregan tantos ceros como sea la longitud del FCS al final del msj a transmitir
3. Se divide esa nueva secuencia de bits con los ceros agregados POR el Generador,
haciendo esta operación en módulo a 2, por lo que no interesan los carries al restar
y se usa XOR en la resta (da 1 cuando los bits que se están operando son distintos,
y 0 cuando son iguales)
4. Se obtiene el resto de esa división, el cual serà el FCS.
5. Se envían los datos originales reemplazando los ceros concatenados anteriormente
por el FCS.

Para verificar la info recibida:

 1. Como se que me llegó un msj mas un FCS, divido todo eso por el Generador y la
división me debe dejar un resto = a 0. Si no es así, hubo error.

Video explicativo: https://www.youtube.com/watch?v=Fz6b1t8sr10

ARP: ADDRESS RESOLUTION PROTOCOL

Dado que existen tanto las direcciones de la capa de red como las direcciones de la capa
de enlace, surge la necesidad de una traducción entre ellas. Cada host y cada router de una
red LAN tienen un módulo ARP.

ARP resuelve una dirección IP en una dirección LAN (o también llamada MAC). Es
importante aclarar que el módulo ARP solo resuelve direcciones IP para los nodos de una
misma LAN. Si un módulo ARP en Buenos Aires intentara solucionar una dirección de
Córdoba, el módulo ARP devolvería error.

El módulo ARP de cada nodo tiene una tabla ARP en su memoria RAM, la cual tiene una
relación entre dirección IP, dirección MAC y un TTL asociado que indica cuando la entrada
será borrada de la tabla. Un tiempo de espera típico son 20 minutos.

La tabla se irá llenando con este tipo de relaciones IP - MAC a medida que fluyan tramas
entre el nodo dueño de la tabla en cuestión. Es decir, la tabla puede no tener registros para
host de la misma red.

ARP se utiliza en 4 casos referentes a la comunicación entre 2 hosts:

1. Cuando 2 hosts están en la misma red y uno quiere enviar un paquete a otro.
2. Cuando 2 host están sobre redes diferentes y deben usar un gateway/router para
alcanzar otro host.
3. Cuando un router necesita enviar un paquete a un host a través de otro router.
4. Cuando un router necesita enviar un paquete a un host de la misma red.

Existen dos casos distintos de uso del protocolo ARP cuando la MAC no se encuentra en la
tabla:
- El primer caso es cuando un host se quiere comunicar con otro de la misma LAN,
pero no tiene en su tabla ARP la relación entre IP - MAC del receptor. En este caso
se averigua la MAC con una consulta ARP al broadcast físico indicando la IP, y el
adaptador que reconoce la IP destino responde (de forma unicast) con su MAC, que
es agregada a la tabla del emisor.
- El segundo caso es cuando se quiere enviar un paquete fuera de la red. En este
caso se envía el frame al gateway, que luego continúa retransmitiéndolo. El
datagrama en el interior del frame contiene la IP del destino, pero el frame contiene
la MAC del gateway (si no la conoce, utiliza ARP para solicitarla). Al enviarse el
frame, es recibido por el router, sube a su capa de red y al ver una IP destino distinta
de la suya, vuelve a bajar a enlace para ser retransmitida al próximo router que
 corresponda según la tabla de ruteo. Eventualmente un router conocerá al equipo
destino, y le enviará el datagrama con la MAC correcta -si no la conoce, utiliza ARP-.

Para ver si la máquina está en la misma LAN, se usa el proceso ANDing:

Primero, el host de origen compara (AND) su propia dirección IP con su propia máscara de
subred. El resultado de ANDing es la identificación de la red en la que reside el host de
origen. Entonces compara las direcciones IP de destino con su propia máscara de subred.
El resultado del segundo ANDing será la red en la que está el host de destino. Si la
dirección de la red de origen y la dirección de la red de destino son iguales, se pueden
comunicar directamente. Si los resultados son distintos, están en diferentes redes o
subredes, y necesitarán comunicarse a través de routers, o puede que no sean capaces de
comunicarse.

IDENTIFICACIÓN DE DOS MÓDULOS EN UNA RED ETHERNET

Las máquinas en una red Ethernet se identifican con su número de MAC, que es único por
adaptador. Estas direcciones son de 48 bits de longitud, donde los 3 bytes mas
significativos son para identificar al fabricante, y los 3 bytes menos significativos son para
identificar la placa. Vale aclarar que esta dirección es única, y es portable (es decir, aunque
el equipo cambie de red, su dirección MAC será la misma, a diferencia de IP).

La dirección Broadcast de esta capa es la FF:FF:FF:FF.

ETHERNET Y ALGORITMOS DE ACCESO AL MEDIO

Tenemos 3 grandes clases de algoritmos de acceso al medio:

- Particionado de canal.
- Protocolos de arbitraje. Divide el canal en pequeñas piezas. Luego asigna
cada pieza a un nodo para su uso exclusivo. Es una estrategia estática y es
equitativo.
- Acceso randómico/aleatorio.
- El canal no se divide sino que un nodo puede usarlo y transmitir a toda
velocidad. No existe, a priori, coordinación entre nodos y por ende permite
colisiones. Es necesario recuperarse de las colisiones. Estrategia dinámica.
Los protocolos de acceso randómico especifican cómo detectar colisiones y
como recuperarse. Ejemplos claros son ALOHA, CSMA, CSMA/CD.
- Toma de turnos.
- Los nodos toman turnos, pero los nodos con mas tramas para enviar podrían
tomar turnos más largos. Es una estrategia dinámica. Estrategias de reserva
o centralizada. Intenta tomar lo mejor de “particionado de canal” y de “acceso
randómico”. Dos ejemplos son Token-Passing (un canal compartido, y un
nodo puede transmitir datos cuando tiene el token. La idea es que los nodos
de la red formen un anillo circular donde el “token” va cambiando de
poseedor, y cada nodo puede elegir usarlo para transmitir información, o
pasarlo al siguiente nodo si no desea transmitir información.), y el otro
 ejemplo es Maestro Esclavo (hay un maestro que indica los turnos a los
esclavos).

Como se dijo anteriormente, las máquinas en una red Ethernet se identifican por su número
de MAC.

Ethernet se suele utilizar en una red LAN cableada. Se comporta como un medio
compartido, es decir, un solo dispositivo puede transmitir con éxito por vez, y cada uno es
responsable de la detección de colisiones y de la retransmisión. Si dos nodos transmiten a
la vez, habrá una colisión de la que deben recuperarse. Para evitarlo, deben coordinarse.

Una colisión es una situación que se da en la que dos tramas “chocan” y la información se
mezcla, de manera que ningún receptor puede utilizar la información que le llega.

Algoritmo CSMA/CD:

Los nodos de una LAN Ethernet están interconectados por un canal de difusión, por lo que
cuando un adaptador transmite un marco, todos los adaptadores de la LAN reciben el
marco. Ethernet utiliza un algoritmo de acceso múltiple CSMA/CD.

- Se comprueba el estado del canal antes de iniciar una transmisión.

- Si el canal está libre, se transmite de inmediato. Caso contrario, se espera a que
esté libre.
- Mientras se transmite, comprueba si se produce una colisión.
- Si se produce una colisión, interrumpe la transmisión.

Vale aclarar, que CSMA es muy similar a CSMA/CD. La diferencia entre ambos es que
CSMA/CD detecta mientras transmite, a ver si recibe una señal por parte de otro nodo y en
tal caso, para de transmitir y envía a los demás nodos de esta situación, para que los
demás también paren de transmitir. Luego, espera un tiempo random para volver a
transmitir el paquete. En CSMA, esto no se da.

TRAMA ETHERNET

El preámbulo indica el inicio de la trama y tienen el objeto de que el dispositivo que lo recibe
detecte una nueva trama y se sincronicen los relojes
El “Tipo” indica qué protocolo de capa de red se está utilizando (no siempre se usa IP).
Ethernet no es un servicio confiable. No es orientado a la conexión, y si bien detecta
errores, no puede retransmitir.

DOMINIOS DE COLISIÓN Y DOMINIOS DE BROADCAST

Un dominio de colisión es un segmento físico de una red donde es posible que las tramas
puedan "colisionar" (interferir) con otros.
A medida que aumenta el número de nodos que pueden transmitir en un segmento de red,
aumentan las posibilidades de que dos de ellos transmitan a la vez. Esta transmisión
simultánea ocasiona una interferencia entre las señales de ambos nodos, que se conoce
como colisión. Conforme aumenta el número de colisiones disminuye el rendimiento de la
red.

Los switches, bridges y routers dividen los dominios de colisión.

(Las tablas de switches tienen dos campos, dirección MAC de la PC y PUERTO que me
comunica con dicha PC. Las entradas se van a ir llenando cuando fluya el tráfico ARP. Para
esto es que nos sirve saber de qué capa es cada dispositivo, nos permite saber con qué
datos trabaja.)

Un dominio de difusión (broadcast domain) es el área lógica en una red de computadoras

en la que cualquier computadora conectada a la red puede transmitir directamente a
cualquier otra computadora en el dominio sin precisar ningún dispositivo de
encaminamiento, dado que comparten la misma subred, dirección de puerta de enlace y
están en la misma red de área local (LAN) o VLAN (predeterminada o instalada).

De forma más específica, es un área de una red de computadoras, formada por todas las
computadoras y dispositivos de red que se pueden alcanzar enviando una trama a la
dirección de difusión de la capa de enlace de datos.

Los routers dividen los dominios de broadcast.

Dispositivo Capa

NIC (tarjeta de red) Capa de enlace

Repetidor Capa física

HUB Capa física

Switch Capa de enlace

Router Capa de red

Bridge Capa de enlace

HUB

Básicamente es repetidor. Por cada bit que recibe por cada enlace de entrada, copia la
información y reenvía la copia por los enlaces que posee. No tiene mecanismos para
prevenir colisiones.

SWITCH - BRIDGE

Son dispositivos un poco mas inteligentes que el hub. A partir de una trama, ambos tienen
que llevarla hacia el enlace correspondiente. Ambos cuentan con una tabla MAC con la que
hacen la asociación para decidir por que enlace reenviar el paquete. Si no tienen
información en la tabla, transmiten la información como Broadcast.

El bridge es un dispositivo que hace la conmutación a nivel de software. La idea de este

dispositivo es unir distintas redes y por ende no tiene tantas puertas de enlace. Tiene
buffers que se usan para almacenar los bits que van llegando desde un determinado enlace,
y cuando termina de llegar toda la trama, la reenvía por un enlace de salida (lo cual genera
retardo) (esta técnica se llama store-and-forward). Son invisibles a protocolos de capa de
enlace.

El switch es un dispositivo mas potente. Permite conectar múltiples enlaces de forma

directa. La conmutación se hace con hardware, por ende es más rápido y mas eficiente.
Pueden configurarse en modo store-and-forward o cut-through (comienza a enviar el frame
ni bien reconoce la MAC destino).

PPP: PROTOCOLO PUNTO A PUNTO

Es típicamente el protocolo de elección para un enlace telefónico para host residenciales.

Es indudablemente uno de los protocolos de enlace de datos desplegados mas
ampliamente hoy en día.
Es un protocolo de enlace de datos, que conecta directamente dos nodos. El enlace sobre
el que funciona PPP puede ser una línea de módem telefónico, un enlace SONET/SDH, una
conexión X.25 o un circuito ISDN.