FR Apuntes

Tema-1-FR.
pdf
S_GRND
Fundamentos de Redes
3º Grado en Ingeniería Informática
Escuela Técnica Superior de Ingenierías Informática y de

Telecomunicación
Universidad de Granada
Reservados todos los derechos.

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Tema 1
Introducción a los Fundamentos de Redes
1.1. SISTEMAS DE COMUNICACIÓN Y REDES
Un sistema de comunicación es una infraestructura (hardware y software) que permite el intercambio de
información. Es el conjunto de elementos y dispositivos involucrados en la transmisión de información entre do
puntos remotos (fuente/emisor, destino, canal, transmisor y receptor).
La información es un conjunto de datos con significado. La señal que sirve como soporte de esta se denomina
continente.
Una red (de computadores, de móviles, de dispositivos…) es un sistema de comunicación con sistemas finales
(terminales) autónomos (con capacidad de procesar información) e interconectados que facilita el intercambio
eficaz y transparente de información

Eficaz: Maximizar el uso de los recursos. Cuando usamos la red queremos ser eficaces: conseguir
transmitir a la máxima velocidad con el mínimo retardo.
• Transparente: Queremos que el usuario/la aplicación no lo note. Las aplicaciones son software que
consumen y generan información. Queremos que este consumo y generación de la información sea a
través de la red, pero de forma transparente: es decir, que la aplicación sea ajena a todas las dificultades y
heterogeneidades que hay para hacer ese intercambio de información.
Razones (motivación) para usar redes

• Compartir recursos (hardware y software): base de datos, impresora, Google drive...
• Escalabilidad: La red resuelve problemas con escalabilidad. Consigue soluciones escalables. Un sistema
es escalable cuando sus prestaciones son independientes del volumen o del tamaño al que se aplica.
La red hace los sistemas escalables porque con independencia del volumen las prestaciones siguen siendo las mismas. Esto
es gracia a la red porque permite desplegar bajo demanda recursos redundantes para dar servicios
• Fiabilidad, robustez (frente a fallos) → Duplicidad (redundancia)
• Ahorro de costes (computación distribuida): La red hace que los costes de la computación disminuyan.
Tener los MegaFlops distribuidos es más barato que tenerlos en una CPU.
DNS (Servicio de Dominio de Nombres): Servicio al que le pasas un nombre de dominio y el sistema te devuelve
la IP. Es como una consulta a una base de datos distribuida en el que el campo clave es el nombre del dominio y
el sistema te devuelve la IP. El DNS es un ejemplo de escalable. Es una tecnología que se especificó en los 80
cuando internet era 10³ redes. El DNS se especificó para ese tamaño. Sin haber cambiado esencialmente nada, el
DNS sigue funcionando en la actualidad cuando el número de redes se ha multiplicado por 10⁶ (ahora hay 10⁹) y
sigue funcionando de forma escalable → tarda lo mismo ahora que hace 20 años. Esto es porque los servidores
de DNS están en red, que hace que las cosas sean escalables.
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-6105765
CLASIFICACIÓN:
• Por escala (o cobertura)
◦ LAN (Local Área Network): Redes que abarcan unos pocos kilómetros.
◦ MAN (Metropolitan Área Network) (en desuso): Entre 10 y 30 km. Por ejemplo, la UGR tiene una.
◦ WAN (Wide Área Network): Redes móviles, redes de fibra/ADSL domésticos.
• Por tecnología de transmisión o uso del canal de comunicación
◦ Difusión o canal compartido (Wifi, Redes de Datos Móviles, Bluetooth, etc.): El medio de transmisión
se usa de forma simultánea/concurrente por todos los dispositivos/terminales.
◦ Punto a punto (Fibra, ADSL, etc.): Tecnologías que solo tienen un terminal de origen y otro de destino.
No todos los equipos involucrados en la comunicación son equipos de usuario, es decir, nodos finales, ya que
intervienen otros cuya única finalidad es posibilitar las comunicaciones entre dichos nodos finales, dando lugar
a la subred (que definiremos ahora). Por otro lado, como resultado de la existencia de estos equipos intermediarios,
la comunicación se producirá entre los nodos terminales como resultad de una secuencia de comunicaciones entre
las parejas de equipos involucrados. Así, podemos diferenciar entre:
• Comunicación salto a salto: tienen lugar de forma directa entre cada par de nodos involucrados en la
comunicación entre dos nodos terminales
• Comunicación extremo a extremo: comunicaciones entre los nodos terminales y, habitualmente implican
la participación de nodos que actúan de intermediarios.
ESTRUCTURA Y ELEMENTOS DE UNA RED

• Hosts: sistemas finales (terminales) → tienen capacidad

de procesamiento. Los que generan y consumen
información.
• Subred: infraestructura para el transporte de
información. Internet es la unión de las distintas
subredes (por eso se llama red de redes). Es un conjunto
de elementos que posibilitan la interconexión de los
hosts. La subred está constituida por dos elementos:
◦ Líneas de transmisión: Canales o enlaces de comunicación Pueden ser punto a punto o de canal
compartido
◦ Nodos o elementos de conmutación: elementos que vienen a simplificar la topología
(routers, switches). Son hardware de propósito específico. La misión básica es
posibilitar el transporte de los datos entre el origen y el destino.
Al simplificar con routers probablemente ya no necesitaré n².
1.2. DISEÑO Y ESTANDARIZACIÓN DE REDES

PROBLEMAS A RESOLVER POR LA RED (para que el intercambio sea factible, transparente y eficaz)
Para simplificar la solución de estos problemas se adopta un diseño en capas, lo que equivale a agrupar funciones
o tareas relacionados. Cada capa debe ocuparse de resolver uno o varios de los problemas de forma independiente
a las funcionalidades del resto de capas. Así, tendremos un sistema más modular y flexible.
• ¿Cómo enviar físicamente la información?

◦ Cómo transmitir la información. Cómo se representa internamente la información (los 1s y 0s) para
enviarlos de forma transparente. Los 1s y 0s se representan como señales eléctricas, como una longitud
de onda en la fibra… ¿cómo se transmite? ¿Cómo es el conector para que salgan los bits? Clavija de
4 patas, 8 patas, fibra óptica… PROBLEMAS DE TRANSMISIÓN.
• Compartición del medio. Segmentación de la información.
◦ Las redes de canal compartido tienen un problema: yo tengo que determinar a quien le toca. Si en la
WIFI todo el mundo transmite a la vez, los 1s y 0s se solapan y ya no funciona. Tiene que haber un
mecanismo de acceso al medio → MAC (Medium Access Control). Este último resuelve el acceso al
medio, con especial relevancia en las redes de canal compartido.
si lees esto me debes un besito

• Control de flujo y de errores, salto a salto (routers) y también
extremo a extremo:
◦ FLUJO: Si yo empiezo a dictar muy rápido, tú tienes en tu
cabeza un “buffer” (memoria). Si este se llena, empiezas a
perder información y aquello no funciona correctamente.
El control de flujo tiene que ver con regular el ritmo o la
velocidad de generación con el consumo de información.
Tiene que haber regulación del control de flujo.
◦ ERRORES: La información se puede alterar → envío un 1
y llega un 0. Para que la conexión entre mi cliente y el
servidor sea transparente, alguien tiene que detectar y
corregir errores. Si no, el cliente tendría que comprobar bit a bit que la información recibida es correcta.
Esto sería muy ineficaz. Se hace por bloques de bits. La información se manda bit a bit, pero la
corrección de errores se procesa como unidades de información más grandes (bloques) llamadas
TRAMAS. Asociado a los errores hay un problema de delimitación. Estas tramas tengo que decidir
donde empiezan y donde acaban → esto es delimitar.
La red es un enjambre de routers interconectados -> más de una posibilidad para ir de un lado a otro
• Control de encaminamiento (enrutamiento)
◦ El cliente quiere que la red se encargue de llevar la información y traerla al sitio adecuado. Se hará
minimizando alguna métrica/coste. Se trata de escoger la mejor ruta para llegar al destino; es decir,
coger el menor camino o el de menor retardo. → Problema de eficacia. Queremos hacerlo siempre de
forma eficaz para que al final el cliente disfrute máximo pronto mínimo retardo.

• Control de congestión (de forma eficiente):
◦ La red tiene limitaciones. El flujo era para regular extremo a extremo lo que
tu lees. Pero a veces la propia red tiene limitaciones. Estas
limitaciones hacen que uno no pueda generar todo el tráfico que
quiera. Tiene que haber un mecanismo que regule la carga de red
para evitar que se saturen los recursos porque si no, se bloquea. Hay
que introducir mecanismos que protejan a la red de estas limitaciones
(si no, sucede la congestión) Dos tipos de limitaciones:
▪ Ancho de banda: También se llama velocidad o capacidad de transmisión. Se mide en bits por
segundo.
• Vt (Velocidad de transmisión) < ∞ (es finito) -> no puede transmitir a velocidad infinita
▪ Buffer en los routers: Los routers almacenan y envían en unas unidades que se llaman paquetes.
Almacenar implica consumir unos recursos. El buffer en los routers es finito.
• Buffer < ∞ (es finito)
Los paquetes de entrada se van escalando en el router. Se almacenan y se reenvían.

El tiempo de espera en la cola depende del uso. Hay que evitar esto con un control
de congestión eficiente.
• Entrega ordenada de los mensajes: Los mensajes se transmiten como paquetes y estos pueden llegar
desordenados. Hay que garantizar el orden.
• Gestión del diálogo o turno de palabra: Como en una conversación. Regulación del turno.
• Representación (sintaxis) de los datos: Cómo se representan los datos internamente (la información)
• Significado (semántica) de los datos: Qué significa la información, qué estoy enviando, a quién estoy
enviando…
Conceptos de diseño en redes:

Para resolver esto y ofrecer estas funcionalidades se usó Divide y Vencerás. Se ofrecieron por capas dividiendo
el problema. Es decir, solucionar los problemas en capas. Cada capa hace una funcionalidad y cada una pasa la
información a la siguiente capa.

Esto anterior se llama Modelo de Referencia, que consiste en definir un número
de capas donde a cada capa se le encarga una funcionalidad. Modelo de
referencia = definición de capas + funcionalidades
Principios de diseño para el modelo de referencia

• Funcionalidades distintas deben estar en capas distintas. Consiste en
minimizar el flujo o la interacción entre capas
• Minimizar la interacción y el flujo de información entre capas
ESTÁNDARES INTERNACIONALES
• MODELO OSI (Open System Interconnection) propuesto por la ISO.
Definir un modelo de referencia formalmente con los dos principios de
diseño dividido en siete capas.
Pero en Internet triunfa lo simple. Por ello:

• TCP/IP (Transmission Control Protocol/Internet Protocol). Simplifica mucho. Tiene tres capas. Por
debajo suponemos una red que transmite cosas. Nos vamos a centrar en este estándar a lo largo del curso.
o IETF (Internet Engineering Task Force) es un organismo de estandarización que reguló el Internet
con este (es una Organización sin ánimo de lucro) -> Propuso este estándar. Los acuerdos
democráticos se materializaron en unos documentos en texto y numerados llamados RFC (Request
For Comment)

MODELO OSI
• Capas de salto: implementan funcionalidades/soluciones que implican relaciones salto a salto (router a
router)
o FÍSICA (=TRANSMISIÓN): La unidad de información es el bit. Se trata de transmitir bit a bit la
información. Puede haber errores y esto se hace/resuelve en la capa de enlace.
o ENLACE (=ERRORES/FLUJO/MAC): La unidad de información son las tramas (conjuntos de
bits). El objetivo principal es entregar al receptor de forma fiable todos los datos enviados por el
emisor.
▪ Delimitación de tramas para conocer el principio y el fin de cada bloque de datos
▪ Detecta y corrige errores (control de errores) para conseguir que la información recibida
se corresponda con la emitida en el origen.
▪ Regula el flujo: se persigue evitar que el emisor sature la memoria del buffer.
▪ Resuelve el control del acceso al medio.
o RED (=ENCAMINAMIENTO): La unidad de información es el paquete. Resuelve los problemas
de encontrar la mejor ruta. También se produce el control de congestión: evitar la saturación de la
capacidad de la subred como consecuencia de un tráfico elevado. En esta capa también se lleva a
cabo la interconexión de redes: se posibilita la transmisión de datos entre estaciones finales
situadas en redes distintas.
En definitiva, esta capa pretende hacer que los paquetes sean dirigidos hacia el destino a través de
las diferentes subredes de la forma más eficiente posible.
• Capas de transporte: extremo a extremo; es decir, solo involucran al host destino y origen:
o TRANSPORTE (=CONTROL DE CONGESTIÓN): La unidad de información es el segmento.
Protegerse de las limitaciones. Se trata de autorregular la información que genera para evitar la
congestión de la red. Se realiza un control de flujo y de errores, pero extremo a extremo. Es decir,
la capa de transporte ve la subred como un solo ente (y no un conjunto de nodos y enlaces) sobre
la que los hosts emisor y destino deben controlar que la transmisión se lleva a cabo con éxito.
También ofrece la función de la multiplexación de aplicaciones sobre una misma conexión de red,
es decir, posibilitar varias comunicaciones entre los mismos hosts.
La finalidad básica es la entrega fiable de los segmentos entre el origen y el destino (extremo a
extremo)

o SESIÓN (=DIÁLOGO): Gestionar el turno de palabra en una comunicación entre los hosts.
o PRESENTACIÓN (=SINTÁXIS): Representación de los datos que provienen de la capa superior.
Esta capa permite resolver las heterogeneidades respecto de la representación interna de la
información en cada uno de los hosts exremos.
o SEMÁNTICA (=APLICACIÓN): Servicios finales que se ofrecen al usuario: correo electrónico,
transferencia de ficheros…
Los routers, por tanto, solo tienen 3 capas: las tres capas inferiores, que son salto a salto.
El modelo OSI es útil para explicar las funciones que deben llevarse a cabo en la implementación de una red de
ordenadores. Pero algunas capas están vacías de contenido o desiquilibradas. Por esto, surgió:
MODELO TCP/IP -> Evolución del modelo OSI

Asume que hay una tecnología que me permite enviar información bit a bit. Es
agnóstico de la tecnología. Supone que existe algo que me permite enviar y
recibir paquetes.
Tiene 3 capas, por tanto, es más sencillo.

• Capa de red: La unidad de información es el paquete. Resuelve
problemas de encaminamiento/enrutamiento/fragmentación. Es la única
capa salto a salto.
• Capa de transporte: La unidad de información es el segmento. Control de
congestión, de diálogo, de errores y de flujo. Capa extremo a extremo.
• Capa de aplicación: La unidad de información es el mensaje. Resuelve los
problemas de semántica y sintaxis. Capa extremo a extremo. Incluye servicios
de usuario como ssh, ftp, http…
La interfaz entre la capa de red y la inferior (la que asumimos que existe) es un “driver”. Por esto se dice que
TCP/IP es una red software, de modo que puede implementarse sobre cualquier tecnología de red sin ser
dependiente de ella.
Las funciones hasta la capa de red se implementan tanto en los dispositivos de la subred como en las estaciones
finales (salto a salto), siendo exclusivas de los hosts (extremo a extremo) las funciones relacionadas con las capas
superiores
1.3. TERMINOLOGÍA, CONCEPTOS Y SERVICIOS

MODELO OSI: Comunicación real vs Virtual
¿Cómo fluye la información? Las entidades hablan virtualmente entre sí pero la comunicación real se hace capa
a capa (de superior a inferior) hasta que llega al medio físico. Cada entidad dialoga con su entidad par de forma
virtual.
Para comenzar diremos que, dadas dos capas adyacentes N y N+1, la capa inferior se denomina proveedora de
servicios y la superior usuaria de servicios por cuanto que la capa N ofrece una serie de funciones o prestaciones
(servicios) transparentes para la superior.
• Protocolo: Conjunto de reglas que regulan el intercambio de información virtual entre entidades.
o Habrá un protocolo de información que defina cómo son los mensajes…
o Habrá un protocolo de transporte que defina cómo es la cabecera, qué significa, etc…
• Interfaz: Abstracción que modela la interacción entre capas. Es el punto a través del cual podemos hacer
el intercambio de información real. La comunicación entre dos capas adyacentes se realiza a través de
esta. (Concretamente se hace sobre los llamados puntos de acceso al servicio <SAP>)
o Interfaz socket: Aplicación de intercambio de información con la capa de transporte.
Conjunto de llamadas al sistema y métodos que dan el control al SO y que invocan la funcionalidad
de la capa de transporte (inferior).
• Unidad de datos de servicio <SDU>: Datos manejados por la entidad y que proceden de la capa
inmediatamente superior
• Unidad de datos de protocolo <PDU>: SDU recibida de la capa superior más la cabecera añadida a efectos
de llevar a cabo la función especifica.
• Entidades pares. Aquellas que interaccionan entre si con las reglas que define el protocolo. Es decir, son
las entidades del nivel N en el emisor y en el receptor.
• Entidad de nivel N (N en OSI del 1 = físico al 7 =aplicación): Elemento activo, hardware o software,
existente en la capa N. Cada número de entidad hace referencia al nivel de jerarquía en los esquemas
anteriores.
• Comunicación real: Comunicación vertical entre capas que están al lado. Flujo de información entre

emisor y receptor: intercambio de datos entre capas adyacentes.
• Comunicación virtual: Comunicación horizontal entre entidades pares. La realización de una función dada
implica la colaboración de las entidades pares emisora y receptora. Se añade una serie de información
suplementaria en cada capa, generalmente en forma de cabecera, para permitir una comunicación
coherente entre las entidades pares involucradas. Como esta información es relevante solo para estas
entidades, las cabeceras se irán eliminando al ir pasando los datos a las capas superiores -> encapsulado
de los datos.
• Carga útil: Datos transportados en cada bloque de datos.
• Capa proveedora/usuaria del servicio: En dos capas adyacentes, N y N+1, la capa inferior es la proveedora
de servicios y la superior es la usuaria de servicios ya que la capa N ofrece una serie de funciones o
prestaciones (servicios) transparentes para la superior. Por ejemplo: la física es proveedora del servicio
de transmisión eléctrica sobre el canal respecto de la de enlace, siendo esta la usuaria del servicio.
• Servicio: Conjunto de funcionalidades que ofrece cada capa. Cada capa ofrece una funcionalidad que se
materializa en un servicio.
• Modelo de Referencia: Elección de capas y definición de una funcionalidad para cada capa. Llamamos
modelo de referencia al conjunto de capas definido y a las funciones asociadas a ellas.
• Pila de protocolos: Elegir para cada capa un protocolo
• Arquitectura de red: Modelo de referencia al que le añado una pila de protocolos.
o OSI no es una arquitectura porque en él se definen capas y funciones asociadas, pero no los
protocolos implementados en ellas. TCP/IP si lo es, ya que para cada capa se definen unos
protocolos concretos a considerar.
Arquitectura de red = Modelo de Referencia + Pila de protocolos.
La condición necesaria y suficiente para realizar la transmisión o el intercambio transparente de información es
que los hosts tengan la misma arquitectura de red. Es decir, compartir una arquitectura de red extremo a extremo
garantiza el “intercambio de información transparente” entre hosts.

RETARDOS EN AL COMUNICACIÓN
• Retardo acumulado: Procesamiento que implica moverse de una capa
a otra.
El hecho de moverse de una capa a otra y añadir o quitar las cabeceras implica
un retardo
Problemas del acceso al medio compartido también implican un retardo. El acceso al medio puede estar en
cualquier salto.
Llegamos al primer router
• Procesamiento nodal: Mirar las cabeceras, IP, tomar una decisión de encaminamiento, reenviar…
• Encolado: Tiempo de espera a poder salir/transmitir.
• Transmisión: Los paquetes tienen una longitud (L) que se mide en bits y
las líneas tienen un ancho de banda/velocidad de transmisión que se
miden en bps (bits por segundo) -> Tengo que transmitir L bits en una
velocidad de transmisión.
El tiempo que va desde que sale el primer bit hasta el último, es el tiempo de transmisión. Este está
relacionado con la Velocidad de transmisión xq el paquete tiene una longitud. Es el TIEMPO en
TRANSMITIR.

• Propagación: Hay que recorrer una distancia (D) que se mide en metros
a una velocidad de propagación que se mide en m/s. Es el TIEMPO en
LLEGAR.
El modelo OSI tiene más retardo que el TCP/IP porque tiene más capas. Esto implica tener más cabeceras y por
tanto, mas procesamiento. Ya dijimos que TCP/IP era más simple que OSI.
En resumen, tenemos todos estos tiempos de retardo:

• Tprocesamiento en el origen
• MAC (acceso al medio)
• Tcola *N (routers)
• Ttransmision
• Tpropagacion
• Tprocesamiento en el destino

SERVICIOS
Un servicio es cada funcionalidad que ofrece una capa a su capa superior. Podemos clasificarlos en distintos tipos:
• Orientado a conexión (SOC): Implica que antes de hacer el intercambio de
información entre entidades, ambas se tienen que poner de acuerdo y establecer
un estado en común -> tienen que dialogar/establecer una
conexión/sincronizarse. Una vez hecho esto intercambian datos.
1. Establecimiento de la conexión: negocian y ponen el estado común
2. Se lleva a cabo la transmisión de la información
3. Se cierra la conexión
Por ejemplo: voz por teléfono.
• No orientado a conexión (SNOC): Directamente las entidades pueden intercambiar datos sin necesidad
de dialogar o negociar. Se envían de forma directa los datos sin tener en cuenta que el otro esté disponible.
(Por ejemplo: buzones físicos de correo).
Esta clasificación está presente en todos los niveles/capas.
o Confirmados (fiables): Exigen del otro extremo/entidad una retroalimentación de

cómo ha ido el intercambio de datos -> confirmación,
Por ejemplo, el control de errores y flujo.
o No confirmados (no fiables): No exigen esa retroalimentación.
La capa de transporte tiene dos protocolos

a) UDP: No orientado a conexión y no confirmado
b) TCP: Orientado a conexión y confirmado
Primitiva de servicio: cada uno de los procesos elementales en que se desarrolla un servicio. Existen cuatro,
empleándose todas ellas en el desarrollo de un SOC y solo las dos primeras en uno SNOC:
• Solicitud: Requerimiento de servicio por parte de un solicitante (emisor). Por ejemplo: marcar el número
de teléfono.
• Indicación: Recepción de la solicitud en el destino. Por ejemplo: el ring del teléfono.
• Respuesta: si el destino acepta el servicio, responde a la solicitud. Por ejemplo: descolgar el teléfono por
parte del receptor
• Confirmación: De forma análoga a la Indicación, es la recepción de la respuesta en el emisor. Por ejemplo:
el hecho de que el emisor se percate de que el terminal ha sido descolgado en el otro extremo.
1.4. INTERNET: TOPOLOGÍA Y DIRECCIONAMIENTO

Internet es una interconexión de redes (muchas de ellas propietarias < de empresas >).
TOPOLOGÍA: Se pueden identificar a grandes rasgos 3 niveles:

1) Intranet (Ethernet-WiFi) de usuario: Despliegues que normalmente son propiedad del usuario (la de la
UGR o las redes domésticas por ejemplo). Es donde están los hosts que consumen y generan información.
Zona pública + Zona privada.
2) Redes de acceso del Internet Service Provider (ISP): Tienen tecnologías varias (xDSL, RDSI, FTTH, etc)
y pertenecen a un operador.
3) Redes troncales (ATM, SDH, SONET, MPLS): Otro tipo de negocios ajenos a los operadores de antes.
Son de grandes operadores de telecomunicaciones.
¿Cómo puedo hacer uso de las redes al pagar a un operador?

Hay dos tipos de acuerdo que definen las relaciones entre los operadores:
• Peering: Acuerdos de igual a igual -> Intercambio de información mutuo sin contraprestación económica.
• Tránsito: Relaciones a cambio de dinero por la que una entidad ofrece su infraestructura para que la use.

Podemos clasificar los operadores en 3 categorías
• Tier 1: Compañías que tienen tales infraestructuras
(son tan grandes) que pueden acceder a cualquier IP
del mundo por su propia infraestructura o por acuerdo
de peering (sin pagar).
• Tier 2: Empresas muy grandes que para ir a algunas
IPs utilizan peering pero para otras necesitan tránsito
(pagar)
• Tier 3: Operadores que para alcanzar cualquier IP
tienen que usar tránsito.
Puntos neutros: Infraestructuras que se despliegan por el planeta y son puntos de intercambio de tránsito -> para
que los operadores intercambien tráfico entre sí. También se llaman PoP (Point of Presence) ó IXP (Internet
eXchange Point)

El usuario hace click en la URL -> el navegador pasa el control al SO a través de la interfaz.
DIRECCIONAMIENTO
Direccionar es dotar de una metodología para
identificar entidades. En cada capa hay un esquema
de direccionamiento. En cada capa tendré que ver de
quién viene o a quién va la información.
¿Cómo identificamos de quién viene o a quién van las unidades de datos? Con los esquemas de direccionamiento
de cada capa.
• Capa de aplicación: URL. http://www.du-ac.in/index.html (nombrede dominio: du-ac.in)
• Capa de transporte: Puertos. Son números que identifican el proceso origen y el proceso destino.
o Hay puertos origen y puertos destino.
o Hay servicios que tienen su puerto
▪ HTTP -> 80
▪ DNS -> 53
• Capa de red: Dirección IP: 32 bits que identifica a los hosts.
Origen: 192.168.1.10
Destino: 69.162.68.236

Tema 2 - Apuntes
S_GRND

Telecomunicación

Tema 2
Capa de Red
2.1. INTRODUCCIÓN
Antes de nada recordemos el esquema de TCP/IP:

Las funciones y servicios de la capa de red en TCP/IP son:
• El objetivo fundamental de la capa de red en Internet es la interconexión de redes, con independencia de
la tecnología subyacente.
• Conmutación: acción de cursar tráfico entre los nodos de la red; es decir, cómo usan los nodos de la red
el tráfico.
• Encaminamiento: encontrar/determinar la mejor ruta hasta el destino. Cómo hacer que llegue la
información al destino de la mejor forma posible.
• En el modelo OSI también hay una capa de red muy parecida porque también realiza el encaminamiento,
pero en OSI también se realiza el control de congestión en esta capa.
Ejemplos de protocolos de red:

 X.25
 IP: Es el protocolo que permite la interconexión de las redes. Recordemos que la capa de red es salto a
salto, por eso el Modelo de Referencia de los routers se basa en la capa de red.
2.2. CONMUTACIÓN
Recordemos: la red está formada por una serie de líneas de comunicación y los distintos nodos (routers).
La conmutación es la acción de cursar tráfico para establecer o determinar un camino que permita transmitir
información extremo a extremo. Existen diferentes tecnologías de conmutación:
 Conmutación de Circuitos
 Conmutación de paquetes: datagramas o circuitos virtuales.
CONMUTACIÓN DE CIRCUITOS
Se establece una conexión previa a la transferencia de la información entre las estaciones finales origen y destino.
Una vez establecida la conexión, todos los datos que forman el mensaje se transmiten de forma secuencial
siguiendo la misma ruta o circuito. Una vez concluida la comunicación, se cierra la conexión.
o Está vinculada a la telefonía/voz.
o Es un servicio orientado a conexión. Exige un establecimiento de conexión previo a la transmisión.
o Se hacía de forma manual: Los operadores conmutaban manualmente. Fue evolucionando hasta
digitalizarse.
o Pasos:
1. Conexión: elección de la ruta origen-destino a seguir por el mensaje, lo que implica reservar los
recursos necesarios.
2. Transmisión: intercambio de datos entre las estaciones finales de origen y destino, de forma secuencial
y siguiendo la ruta fijada en el paso previo.
3. Desconexión: Liberación de los recursos de la subred asociados a la conexión utilizada.
o Ventajas:
✓ La transmisión se realiza en tiempo real una vez hecha la conmutación. No hay retardo, solo se
tarda el tiempo de propagación, pero no el modal ni el de procesamiento.
✓ Recursos dedicados: Asignación permanente de los recursos, el circuito se mantiene durante toda
la sesión.
✓ No hay contención: no hay contienda para acceder al medio
✓ El circuito es fijo: No hay decisiones de encaminamiento una vez establecido. Es decir, las
decisiones de encaminamiento son solo al principio, después no.
✓ Simplicidad en la gestión de los nodos intermedios
o Desventajas:
 Retraso en el inicio de la comunicación. Es decir, en el establecimiento de la llamada.

 En ocasiones hay un uso no eficiente de los recursos. Se consumen los recursos con independencia
de si los estoy utilizando o no.
 Poca tolerancia a fallos
 El circuito es fijo. No se reajusta la ruta de comunicación y por tanto hay poca flexibilidad para
adaptarse a los cambios.
CONMUTACIÓN DE PAQUETES
En este esquema el mensaje no se transfiere secuencialmente como
una sola unidad sino en trozos llamados “paquetes”, los cuales se
retransmiten nodo a noso hasta llegar al destino.
o Envió en unidades de datos (paquetes) independientes: Los

nodos de conmutación procesan las unidades de datos
(paquetes) de forma independiente (no hay concepto de
conexión, no es SOC. Cada paquete se procesa
independientemente).
o No hay conexión origen-destino previa a la transmisión.
o En cada salto: almacenamiento y re-envío (STORE AND
FORWARD): Los paquetes van router a router y se
almacenan, se inspeccionan y se reenvían.
o Cada paquete tiene que tener una cabecera donde
identificamos al origen y al destino (sus direcciones). En base
a ese destino cada router decide la ruta del encaminamiento -> toma la decisión de por donde ir. Esto se
hace salto a salto y paquete a paquete porque si de repente un router está muy lleno/ocupado, podemos
cambiar la ruta/camino.
o Los paquetes pueden seguir rutas diferentes y llegar desordenados. (en la conmutación de circuitos, sin
embargo, siguen la misma decisión de encaminamiento <que implica menos retraso>; es decir, todos
siguen el mismo camino <como una tubería>).

CONMUTACIÓN DE PAQUETES CON CIRCUITOS VIRTUALES
Es un tipo de conmutación que está entre la de Paquetes y la de Circuitos. Era algo intermedio.
o Había que establecer la conexión (SOC) pero utilizando un híbrido enviando paquete a paquete.
o Pasos: (i) Conexión, (ii) Transmisión, (iii) Desconexión
o Usado en redes ATM (tecnología en desuso para redes troncales)
o No hay asignación de recursos como en la conmutación de circuitos.
2.3. EL PROTOCOLO IP
El protocolo IP es el especificado en Internet para operar entre las entidades de la capa de red.
Recordemos: Los mensajes de la aplicación se van a encapsular en segmentos utilizando TCP -> a su vez se
encapsulan en paquetes con el protocolo IP -> a su vez se encapsulan salto a salto a más bajo nivel.
IPv4.
• Es un protocolo para la interconexión de redes (también llamadas subredes). Su objetivo es la
interconexión de redes con independencia de la tecnología subyacente y sin exigirle nada.
• Resuelve el encaminamiento en Internet: encontrar la ruta para llegar al destino. Gracias a las cabeceras
se va determinando salto a salto y paquete a paquete por donde se envían de forma independiente
(normalmente la ruta de ida y de vuelta son distintas).
• El espacio de direcciones no era suficientemente grande. Por eso surgió IPv6, pero mayoritariamente, por
razones de coste, se suele utilizar IPv4.

TABLA DE ENCAMINAMIENTO
DESTINO SALTO SIGUIENTE etc…
….. ……
Así, cuando llega un paquete, se consulta, se toma el destino y se elige el salto siguiente en base a ello.
• Es un protocolo salto a salto. Involucra a hosts y routers.

• Ofrece un servicio no orientado a conexión (SNOC) y no fiable.
o No hay negociación o “handshake”, no hay una conexión lógica entre las entidades (no hay una
“tubería” de encaminamiento). Internet funciona como una conmutación de paquetes y los
paquetes funcionan de forma independiente)
o No tiene mecanismos para detectar y corregir errores, controlar el flujo/congestión…
• La unidad de datos (paquete) de IP se denomina datagrama = cabecera + datos
(datos = segmento para la capa de transporte)

Los datos los produce la capa de transporte para la capa de red -> le da igual

• IP es un protocolo de máximo esfuerzo (best-effort) o buena voluntad: los datagramas se pueden perder,
duplicar, retrasar o llegar desordenados. El protocolo IP hace lo que puede e intenta que los paquetes
lleguen salto a salto consultando la tabla de encaminamiento. Pero hay errores y problemas. La capa de
transporte resolverá esto.
• Gestiona la fragmentación: Adaptar el tamaño del datagrama a las diferentes Maximum Transfer Units
(MTUs) de las subredes necesarias hasta llegar al destino. Se trata de adaptarse al tamaño de la red. Las
tramas pueden ir cambiando de tecnología salto a salto o tener distinto tamaño. Por eso, puede ocurrir que
tenga que hacer fragmentación porque no cabe la información.
___________________________________________________
Cada entidad IP se identifica con su dirección IP (32 bits).
Internet adopta un direccionamiento jerárquico que simplifica las tablas de routing (enroutamiento).
Las direcciones IP tienen dos partes bien diferenciadas.

• Una parte identifica a la subred

• La otra parte identifica al host dentro de la subred
Jerárquico porque este esquema de direccionamiento nos permite jerarquizar las tablas de encaminamiento y
simplificarla. (con identificar como destino a la red, con una única entrada, identifico todos los hosts que están
en esa red)
Cada subred tiene un identificador (prefijo) único en la intranet (para direcciones privadas) o en internet (para
públicas).
Intranets: Infraestructura de red, subred y routers que usan direccionamiento privado. Una intranet puede ser más
compleja (no solo el wifi de casa). Cada prefijo de red es único en la intranet.
Internet: igual pero direccionamiento público.
Hay IPs que son privadas y otras que son públicas.

• Privadas: Únicas en Internet y las asigna una entidad centralizadora
• Públicas: Pueden asignarlas el usuario a su criterio y se pueden repetir. Sirven para funcionar dentro de la
intranet.
El operador le pone una IP pública hacia afuera al router. En la WiFi habrá una privada que se asignará a cada
host al criterio del usuario.

Cada dispositivo tiene un identificador único en la intranet.
La máscara de red es un patrón de 1s que determina qué bits pertenecen al identificador de subred. Cada dirección
IP tiene asociada una. Me indica qué bits pertenecen al prefijo de red y qué bits al host.
• Dirección IP → 200.47.4.112 = 11001000.00011011.0000100.01110000
• Máscara → 255.255.255.0 = 11111111.11111111.11111111.00000000
La máscara se puede representar de forma compacta, por ejemplo 200.27.4.112/24 (24 unos)
Dada una IP, para obtener la dirección o identificador de la subred, se realiza una operación lógica &. Con una
operación AND puedo hallar la dirección de la subred → Las subredes se identifican con la parte de los hosts
todo a 0s.
200.27.4.112 = 11001000.00011011.00000100.01110000
& &

255.255.255.0 = 11111111.11111111.11111111.00000000
Subred → 200.27.4.0 = 11001000.00011011.00000100.00000000
SUBRED
Podemos considerar Internet como un conjunto de subredes
interconectadas.
¿Qué es una subred? Líneas de transmisión e
infraestructuras que permiten la conexión directa de
dispositivos IP sin intermediarios (router). Es decir, entre
ellos no hay un router.
SWITCH VS ROUTER
¿Qué es un switch? Es un hardware de propósito específico que
permite interconectar dispositivos en capa 2, la capa de enlace. (del
modelo OSI). Es decir, basan su decisión de reenvío en valores
almacenados en los campos de la trama de la capa de enlace. →
interconecta dispositivos sin asignarles IP
Unir o conectar dispositivos en red. No proporciona por si solo
conectividad con otras redes ni con Internet.
¿Qué es un router? Es un hardware de propósito específico que permite interconectar dispositivos en capa 3, la
capa de red (del modelo OSI). Basan su decisión de reenvío en los valores almacenados en los campos de la
cabecera del datagrama de la capa de red.
Para determinar las subredes corto las líneas que entran y salen de los dispositivos host y del router. Es decir,
hay que separar cada interfaz de los hosts y routers, creando redes aisladas. Dichas redes aisladas se
corresponden con las subredes.
¿Quién tiene direcciones IP? Los hosts y los routers tienen 1 dirección IP por cada interfaz. Los switches operan
en cada 2 → No tienen direcciones IP

¿Cómo se elige la máscara? Según el número de dispositivos previsibles en la subred, tal que se ajusta para no
desaprovechar direcciones. Recuérdese: cada subred tiene un identificador único en nuestra intranet
(direcciones privadas) o en internet (públicas). Se debe elegir ajustándolo lo máximo posible. Una buena
asignación ajusta la máscara al máximo. (menor número de ceros que permita tener el mejor número de host
posibles para nosotros).
Dirección IP → 200.27.4.112 = 11001000.00011011.00000100.01110000

Máscara → 255.255.255.0 = 11111111.11111111.11111111.00000000
#ceros
# dispositivos = 2 – 2 → ej. 8 ceros (/24) permite 254 dispositivos.
➢ El -2 viene de que la primera (000…0) y la última (111…1) están reservadas.
Por ejemplo en la subred 200.27.4.0/24 no se pueden asignar como id de dispositivo:
o 200.27.4.0 = 11001000.00011011.00000100.00000000 → Reservada (subred)
o 200.27.4.255 = 11001000.00011011.00000100.11111111 → Reservada (difusión → enviar
paquetes que vayan a todos)
En cambio todos estos si:
o 200.27.4.1 = 11001000.00011011.00000100.00000001 → Dispositivo 1
o …
o 200.27.4.254 = 11001000.00011011.00000100.11111110 → Dispositivo 254

DIRECCIONES PÚBLICAS VS PRIVADAS
Direcciones públicas (identificador único en internet).
➢ Tienen un prefijo úinico en Internet. Son únicas.
No se repiten. Cada dirección se asigna a sólo 1
dispositivo en toda la Internet global.
➢ Se asignan centralizadamente. Hay una autoridad
centralizada que se encarga de gestionar el
reparto y la asignación de direcciones IP
(ICANN). En España el responsable de
asignarlas es red.es
Direcciones privadas (identificador único en la intranet).
➢ Solo sirven para tráfico dentro de las intranets
➢ Se pueden repetir en distintas intranets.
➢ Las asigna el usuario según su criterio.
➢ No están gestionadas de forma centralizada
Hay direcciones privadas reservadas:

 10.0.0.0/8 → de 10.0.0.0 a 10.255.255.255
 172.16.0.0/16 → de 172.16.0.0 a 172.31.255.255
 192.168.0.0/24 → de 192.168.0.0 a 192.168.255.255
Recordemos: La IP tiene 32 bits. Una parte es el prefijo de red que identifica unívocamente a la red y otra parte

es para el host, que identifica al dispositivo.
DIRECCIONES IPV4: CLASES

La ICANN a la hora de asignar direcciones preguntaba a las
entidades el tamaño que iba a tener. En función del tamaño
(número de hosts), se le daba una clase u otra.
Los host y los routers tienen una IP por cada una de sus
interfaces.
32 bits, notación decimal con puntos. Ejemplo:
192.168.212.60
Originariamente se definieron 5 clases de direcciones IP.
Clases A,B,C → Jerárquicas a dos niveles:
Identificador de subred + identificador de dispositivo (host)
 Clase A: mask \8 → Redes muy grandes. 0.0.0.0 – 127.255.255.255 → 128 redes * 16.777.216 hosts.
 Clase B: mask \16 → 128.0.0.0 – 191.255.255.255 → 16.384 redes * 65.536 hosts
 Clase C: mask \24 → 192.0.0.0 – 223.255.255.255 → 2.097.152 redes * 256 hosts
 Clase D: Es especial. Es un espacio reservado para redes multicast. → 224.0.0.0 – 239.255.255.255
Multicast: Funcionalidad que permite hacer direccionamiento a muchos.
Con unicast un frame de vídeo (por ejemplo) tendría que duplicarse (el mismo paquete) tantas veces como
usuarios lo necesiten.

Multicast: Metodología tal que con un solo paquete que tenga la IP destino multicast en la ruta que es común me
ahorro mucho tráfico. Puedo enviar más fácilmente paquetes a muchos. Los routers tienen que saber cuándo
enviar el paquete por todos los lados.
 Clase E → 240.0.0.0 → 255.255.255.255 → usos futuros.
Hemos visto clases con un montón de hosts. Esto era muy rígido y se ha ido abandonando (se sigue utilizando la
nomenclatura) y ahora es algo móvil/flexible.
La UGR, por ejemplo, tiene 15000 hosts. → Es muy pequeño para B y muy grande para C.
Reglas especiales:
#ceros
o Número de dispositivos en cada red: # dispositivos = 2 –2
o Recordemos que el -2 es porque hay dos combinaciones que no se pueden usar → están reservados:
▪ Host = 00…0 → identifica a una red, no es una dirección origen, no se usa para dispositivos.
▪ Host = 11…1 → difusión en la red especificada, es una dirección destino, no se usa para
dispositivos.
▪ Además, como recordatorio, también está reservada la dirección 127.0.0.0 → autobucle
(loopback): para que la pila de protocolos arranque tenga ¿pila? o no.
Reserva de direcciones privadas (creo que no es importante)

Clase A → 10.0.0.0 → 1 red privada clase A
Clase B → 172.16.0.0 – 172.31.0.0 → 16 redes privadas clase B

Clase C → 192.168.0.0 – 192.168.255.0 → 256 redes privadas clase C
NAT (“NETWORK ADDRESS TRANSLATION)

Si se pueden repetir direcciones, ¿cómo funciona la transmisión de la información? Aparece el concepto de
Intranet.
Intranet: Infraestructura/conjunto de redes que isa exclusivamente direccionamiento privado.
Internet, en cambio, es de direccionamiento público.
¿Cómo desde direcciones privadas puedo acceder a direcciones públicas? En la conexión entre el intranet y el
internet, hay al menos un router de acceso, el cual realiza NAT.
NAT es un método para reasignar un espacio de direcciones IP (típicamente privadas) a otro (públicas)
modificando la dirección IP de los paquetes mientras se retransmiten a través de un router
Se trata de transmitir la dirección privada en la pública: para que cuando conteste el servidor destino sepa a donde
enviar. Luego, cuando vuelve, tiene que deshacer la IP destino y modificarla.

En el uso habitual, el router NAT reemplaza las direcciones IP
privadas origen salientes por direcciones públicas, y al revés con las entrantes.
Para ello, el NAT usa una “Tabla de Traducciones”, que con la ayuda de una reasignación de puertos, permite
deshacer los cambios en el tráfico entrante. Esto de forma dinámica y automática.
IP Intranet Puerto origen IP Pública Puerto público
RECORDEMOS.
Puertos: Cómo se identifican los procesos a nivel de transporte. Sirven para identificar de quién viene y a quién
va la información en capa de transporte. Se usan para el NAT también.
¿Pueden funcionar de fuera a dentro?

No puede ser de forma automática. Tiene que ser de forma estática porque la tabla o la construimos a mano o no
va a poder deshacer la IP pública. → abrir puertos.
De hecho, en las redes privadas no se pueden poner servicios públicos a menos que mapees a mano.

IMPORTANTE: No se suelen instalar servidores (detrás de un NAT) con direcciones privadas, pues no serían
accesibles desde el exterior Una posible solución es usar STUN (Session Traversal Utilities for NAT): protocolo
cliente/servidor que permite a clientes NAT encontrar su dirección IP pública, el tipo de NAT en el que se
encuentra y el puerto asociado en la tabla de NAT con el puerto local.
Entonces… ¿cómo funcionan aplicaciones como Whatsapp desde una IP privada?
Whatsapp despliega el servicio de directorio.
Cada vez que mando un whatsapp, se manda el mensaje al servicio de directorio, que tiene:
Teléfono IP Puerto
630808080 145.30.30.30
220202020 210.150.150.150

El NAT en el router mapea el puerto origen en la tabla de traducciones a uno disponible (p.e el 30000). Cuanto
tu amigo quiere enviarte un mensaje, consulta el servicio del directorio (quñé IP tiene X teléfono).
1º Hay un mensaje registro: cuando arrancas whatsapp mandas un mensaje a un servidor en la IP Pública.
Se lo envío desde mi IP privada. Pasa al NAT, (dentro-fuera). Mapea el puerto (P:1000 IP: 192.168.1.33 mapeo
a P:30000 IP:210.150.150.150)
Cuando mi amigo hace algo similar, antes de enviarme el mensaje pregunta al servicio de directorio la IP y el
puerto de mi teléfono (destino) → El NAT se encargará de traducirlo de nuevo.
Una de las tareas del administrador de red es asignar direcciones. La ICCAM o red.es es la que da al administrador
un espacio de direcciones y él tiene que gestionarlo y asignarlas.
Longitud de la máscara óptima: Tiene que estar ajustada al máximo tal que se desperdicie el menor número de
direcciones. Cuando decides el número de amplitud de la máscara, estás predeterminando el número de hosts que
habrá: el administrador tendrá que hacer una predicción
Ejercicio: Asignar direcciones

Supongamos 3 subredes corporativas con 30 dispositivos cada una.
Usaremos direcciones privadas 192.168.0.0
Supongamos una subred de acceso con direccionamiento público (asignado por el ISP)

Subredes corporativas: 30 dispositivos, direcciones privadas 192.168.0.0 → 2𝑛 − 2 ≥ 30 → 𝑛 ≥ 5 → 5 ceros →
máscara /27
• A → 192.168.0.[000 | 00000] /27 → 192.168.0.0 /27
• B →192.168.0. [001 | 00000] /27 → 192.178.0.32 /27

• C → 192.168.0. [010 | 00000] /27 → 192.178.0.64 /27
Subred de acceso: dirección pública (ISP) → 2𝑛 − 2 ≥ 2 → 22 − 2 ≥ 2 → 2 ceros → máscara /30

Por ejemplo:
• 150.214.190.[000000 | 00] /30 → 150.214.190.0 /30
Para los dispositivos de la subred de acceso usaremos 01 y 10 → el 00 y 11 no se usan, están reservados.

• 150.214.190.[000000 | 01] /30 → 150.214.190.1 /30
• 150.214.190.[000000 | 10] /30 → 150.214.190.2 /30
El segundo criterio es simplificar las tablas de encaminamiento. (El primero es minimizar las IPs no utilizadas)

ENRUTAMIENTO
Encontrar el mejor camino para llevar la información (paquete a paquete) de un origen a un destino dado.
Se realiza paquete a paquete y salto a salto, en función de la IP destino del paquete y de las tablas de
encaminamiento residentes en cada uno de las entidades IP (host origen y routers). Es decir, el input para la
decisión consta de la IP destino y la tabla de encaminamiento. Cogerá esto salto a salto cada vez que coja un
paquete para llegar al destino.
En cada salto IP hay un procedimiento de store & forward (Almacenamiento & Retransmisión)
TABLAS DE ENCAMINAMIENTO
Modos de encaminamiento:
• Directo: Aquellas que implican que no hay un intermediario. Rutas entre hosts que están directamente
conectados a la misma red. Por ejemplo: H1-R1 o H1-H2
• No directo: Rutas que implican el uso de uno o más intermediarios. Por ejemplo H1-H5
Cada dispositivo (host o router) tiene una tabla de encaminamiento.

Un router suele estar en varias redes distintas, un host suele estar en solo una red.
Al consultar la tabla, en caso de conflicto, se elige la ruta con la máscara más larga.
El default no es obligatorio, pero simplifica mucho las tablas.
En el siguiente dibujo vemos 4 subredes → cada una tiene su propio prefijo de red
o 192.100.13
o 192.100.12
o 192.100.15
o 150.100.0

Siempre hay una dirección especial → 127.0.0.1 → loopback → Ya lo hemos comentado, se pone para tener
alguna IP al iniciar y así el SO pueda arrancar.
En el destino se colocan los hosts (puertos finales) o redes.

En el Gateway, también llamado “Pasarela” o “Salto siguiente” se coloca la IP a la que tengo que enviar para
llegar al destino. El salto siguiente, tanto para loopback como para las rutas siguientes que están conectadas
directamente a R1 es *. → Esto es porque no hay salto siguiente → no hay un intermediario.
En destino se pone default para identificar a cualquier otro destino → máscara /0.
Cuando una IP destino coincide con más de una fila, se elige la máscara más larga → Por eso Default tiene la
máscara 0.0.0.0 → Así es la última opción. Es decir, cuando hay más de una coincidencia en el destino, se coge
la que tenga la máscara más específica/explícita (la más grande).
Toda entidad IP (host o router) tiene una tabla de encaminamiento.
_______________
Tabla de encaminamiento de H1
Destino Gateway Mask IP
127.0.0.1 * 32 lo
192.100.13.0 * 24 eth0
default 192.100.13.129 0 eth0
Las IPs (destino y origen), una vez que envío un paquete, router a router no cambien. Lo que cambian son las
direcciones físicas (MAC). Cuando por ejemplo va de H1 a H5 en cada salto se cambia la MAC origen y destino,
pero las IP origen y destino NO CAMBIAN.
Si no hay fragmentación y no hay “traducción de direcciones” (NAT), el datagrama (salvo el TTL, las opciones
y el campo de comprobación) no se modifica en el camino.
Proceso de encaminamiento en los nodos IP (salto a salto) por cada datagrama:
• Se extrae la dirección destino: IP_DESTINO del datagrama
• Por cada entrada i de la tabal de encaminamiento con i=1,…,N, se calcula
o IPi = IP_DESTINO AND(&) MÁSCARA_i
AND de IP Destino con la máscara y comparo. Me quedo con la que coincida y sea más específico.
• Si IPi==Di (campo destino de la tabla de encaminamiento) y si es routing directo (*) → reenviar el
datagrama al destino final por la interfaz I_i
• Si hay varias coincidencias, se elige el destino Di con la máscara más larga
• Si se ha barrido toda la tabla y no hay coincidencia con ninguna fila → error (posible mensaje ICMP)
• Para encapsular el datagrama en la trama física correspondiente, se debe consultar la tabla ARP (más

adelante la veremos) y en caso de no conocer la dirección física se envía un broadcast con protocolo ARP
para obtener la dirección física.
EJERCICIO: DISEÑAR MANUALMENTE LA TABLA DE ENCAMINAMIENTO EN R2 → 3 PASOS

PASOS PARA HACER UNA TABLA DE ENCAMINAMIENTO
1. Incorporamos las redes directamente conectadas
2. Si queremos, ponemos el default
3. Añadir todas las entradas adicionales necesarias
R2 por tanto tendría:
• loopback
• 3 entradas directamente conectadas
• 1 default a fuera
• 1 entrada indirecta (porque no usa el default para si misma)

RX
180.180.180.2
180.180.180.1
EJERCICIO 7. Imagine una situación donde
hay cinco routers RA-RE. RA, RB y RC se
.1
conectan cada uno a una red local A, B y C,
siendo cada router única puerta de enlace de
cada red. RA, RB y RD están conectados .3 .2
entre sí a través de un switch. RC, RD y RE
están conectados entre sí a través de un
switch. RE se conecta a Internet a través de
la puerta de acceso especificada por el ISP.
Especifique tablas de encaminamiento en los
routers. Asigne a voluntad las direcciones IP
e interfaces necesarias
Hay 6 redes (en rojo en el dibujo)

TABLA DE RE:
DESTINO GATEWAY MÁSCARA INTERFAZ
127.0.0.1 * /32 lo
180.180.180.0 * /30 ethN
192.168.0.0 * /24 ethS
Default 180.180.180.2 /0 ethN
192.168.4.0 192.168.0.2 /24 ethS

En las conexiones punto a punto se utiliza la máscara /30.
Ahora por la izquierda:
Como podemos observar, las tres usan el mismo camino topológico (RD). Podemos agregar/hacer agregación de
ruta en lugar de poner todas las entradas. Por tanto, cambio la máscara a /22.
Por tanto, añado a la tabla anterior:

192.168.2.0 192.168.0.3 /22 ethS
Podría poner en el destino “192.168.0.0” porque todas en sus 22 primeros bits es la misma.
Hay dos 192.168.0.0 → una con /24 y otra con /22.
Con una única entrada, me resuelve el problema.

El administrador ha decidido asignar IPs conjuntas para que sean agregables.

TABLAS DE ENCAMINAMIENTO DE RX

127.0.0.1 * /32 lo
(otras a las que estén --- -- --
conectadas)
180.180.180.0 * /24 ethS
Default - /0 -
192.168.0.0 180.180.180.1 /21 ethS
Hemos agregado las 4. Al agregar /21 hay que tener cuidado porque estoy suponiendo al agregarlas que las otras

IPs (que me sobran) ya no las puedo utilizar en otro lado. (por ejemplo, la .5, .6 y la .7)
Si tuviésemos esta subred, ya no podría agregar /21 porque tengo esa IP (192.168.5.0) → A la hora de asignar
IPs tenemos que adaptarnos al tamaño e intentar que sean agregables.
Siempre empezaremos asignando la red más gorda. (con la máscara más corta)
Tenemos que tener en cuenta que no todas las IPs van a tener la misma máscara.

SISTEMAS AUTÓNOMOS
Para facilitar la administración y aumentar la escalabilidad Internet se jerarquiza en Sistemas Autónomos. Un
sistema autónomo es un conjunto de redes y routers administrados conjuntamente por una única autoridad que
define cómo es el intercambio de tablas (routing interno) dentro del SA. → Su routing y sus tablas de
encaminamiento las voy a gestionar/administrar de forma unificada.
En cada SA existe un router, denominado router exterior, responsable de informar a los otros SAs sobre las redes
accesibles a través del SA.
Cada SA se identifica por un entero de 16 bits (desde 2007 son 32 bits). Por ejemplo Rediris = AS766

Puedo ver Internet como un conjunto de sistemas autónomos interconectados. Cualquier ruta en Internet la puedo
ver a dos niveles (= hay dos niveles de routing): Sistemas autónomos (sucesión de SSAA para llegar a un destino)
y routers dentro de los Sistemas Autónomos (cómo atravieso un SA).
La UGR no es un SA. Rediris SÍ es un SA. Google (todos sus servidores por el mundo) SÍ es un SA.
ROUTING ENTRE SSAA

Los SSAA tienen que interactuar entre sí → Mediante el Border Gateway Protocol (BGP)
Hay una norma única que define el diálogo (el intercambio de información entre SSAA → qué redes tienes tu,
por cuáles hay que pasar, etc).
Protocolo para el intercambio de tablas: Protocolo EGP → Norma única en Internet Todos los “routers exteriores”
usan el protocolo único en Internet: BGP
ROUTING INTERNO EN SSAA

Dentro del SA los routers dialogan entre sí para intercambiarse información y para que las tablas se modifiquen
de forma automática → se autoconfiguran las tablas de encaminamiento.
Ejemplos de protocolos IGP: RIP, OSPF, HELLO, IS-IS- IGRP, EIGRP
Protocolo para el intercambio de tablas: IGP (El administrador tiene libertad para elegir el intercambio de tablas
entre los routers dentro del SA)
RIP (ROUTING INFORMATION PROTOCOL)
Es un protocolo dentro del SA. Es un protocolo de la capa de aplicación (opera sobre UDP puerto 520) → Los
datos se encapsulan en UDP (protocolo de la capa de transporte), que a su vez se encapsula en IP.
IP UDP RIP
Puerto = 520
224.0.0.9
Clase D → multicast
RIP utiliza como IP destino 224.0.0.9 (IP reservada) con un puerto destino 520 (reservado) de tal forma que los
routers pueden intercambiar información entre ellos para configurar las tablas.
En RIP es fundamental #saltos → se pretende minimizar el número de saltos. Para esto se utiliza la
técnica/algoritmo del vector distancia (métrica basada en número de saltos). Periódicamente (por defecto cada 30
segundos) cada router envía a todos sus vecinos (dirección multicast 224.0.0.9) todos los destinos y a cuánto
coste están. A su vez recibe de todos sus vecinos el coste de todos los destinos.
De entre ellos, para un destino dado en la tabla de encaminamiento, se selecciona como salto siguiente (gateway)
el vecino que anuncie el menor coste a ese destino, actualizando la métrica para ese destino, sumando 1 al coste
anunciado. Es decir: A partir de ahí, si soy R para ir a x escojo el de menor coste (+1 por el salto adicional desde
R hasta el vecino).
RIP tarda en propagar la información cuando hay muchos routers. Problema: las malas noticias tardan en Reservados todos los derechos.
propagarse.
Otro problema: Cuenta de la convergencia lenta y la cuenta al infinito.
Imaginemos un Sistema Autónomo con 3 routers
(RED 1,0), (RED 1,1), (RED 1,2)
Imaginemos que la interfaz entre Red 1 y R1 se rompe. R1 ha aprende que aunque se le ha roto el enlace, tiene
un camino por R2 para ir a la red 1 de coste 2. R2 aprende de R3 que tiene un camino por R3 de coste 3, etc.
Pasa esto constantemente hasta el infinito. Puede haber bucles. Esto no lo hace aconsejable.

SOLUCIONES:
• Split Horizon: Transmisión del horizonte. Prohibo o impido anunciar destinos por el mismo camino que
utilizaría para llegar a ese destino.
o Solución con problemas. Por ejemplo en la siguiente topología no impide que no aparezcan bucles.
• Hold down: Ignorar cuando he detectado un error/rotura de enlace, durante un tiempo (2 o 3 minutos)
ignoro todos los anuncios que me lleguen relativos a destinos que yo conociera a través de esa línea que
se ha roto.
• Poison reverse: Cuando detecto una rotura, meter un mensaje explícito que diga: Lo que hayas aprendido
de mi relativo a ese destino, olvídalo.
Para ver más detalles de la implementación en Linux: man routed (routed es un demonio)
Por tanto, vemos que RIP tiene problemas que nos obligan a ver una alternativa:

OPEN SHORT-PATH FIRST
• Comunica a todos los destinos sobre el coste de todos sus vecinos (es parecido a RIP pero diferente). Se
informa a todos sobre el coste de los vecinos. Informa a ∀destinos el coste de ∀ vecinos.
• Todos los routers pueden construir un grafo etiquetado de coste en el enlace. A partir del grafo se aplica
Dijkstra.
• Basado en estado del enlace (coste α 1 / velocidad del enlace). En RIP la métrica/coste es el número de
saltos, mientras que aquí en OSPF el coste es 1/Vt (inversamente proporcional a Vt)
• Resuelve algunos problemas de inestabilidad de RIP.
• Permite rutas alternativas y balanceo de carga.
• OSPF incluye como novedades la posibilidad de tener distintas para un destino rutas (rutas alternativas),
mecanismos para balancear la carga (repartir el tráfico).
• Para ser escalable define áreas independientes → Divide el Sistema Autónomo en áreas para hacer la cosa
más escalable. Así, jerarquizamos e introduciendo distintas áreas hacemos posible que un posible
problema de escalabilidad se reduzca a subconjuntos más pequeños.
• Minimiza difusión mediante routers designados en canales compartidos
• Mensajes: hello, database description, link status Request/update/ack

Ejemplo para RIP y OSPF
Formato de datagrama
¿Cómo es la sintáxis de las cabeceras IP?

Recordemos: el mensaje se encapsula en una cabecera
UDP/TCP, que su vez se encapsula en una cabecera IP.

El datagrama IP suele ir sobre una tecnología en capa 2 → La trama Ethernet.
IPv4 → 32 bits de direcciones.
La cabecera puede ser de longitud variable (opciones y relleno no se suelen usar) → Lo normal es que sea 20Bytes.
CAMPOS DEL DATAGRAMA

V: Versión
LC: Longitud de cabecera
TS: Tipo de servicio. Fijar la prioridad de los datagramas. Con DSCP ahora: Etiquetar distintos datagramas y que
se le de distinto tratamiento.
TOTAL LENGTH: Longitud total en Bytes. Puede ser hasta 216 Bytes (64 Bytes). Los datagramas pueden tener
hasta 64 Bytes.
TTL: Time To Live. Los algoritmos RIP pueden tener problemas → bucles de routing (p.e)
Es un contador decreciente. Todos los paquetes cuando se metan en la red se ponen en 255 (todo a 1 (8bits)) en
el destino.
Recordemos: STORE AND FORWARD consiste en almacenar, esperar y reenviarse
TTL se decrementa también por el tiempo que pasa en la cola (no solo por los saltos). Si un datagrama tiene el
TTL a 0, el router lo descarta por ser muy antiguo.

Protocolo: Cómo se interpretan los datos que van dentro. (si es TCP, UDP…). Me sirve para identificar qué va
dentro.
Comprobación: Dotarse de un mecanismo para detectar cuando haya problemas.
Cojo los bits de la cabecera y los pongo en grupos de 16 en 16. Hago una operación lógica de paridad → XOR

Head IP →
Resultado del XOR → checksum

Bit a bit y columna a columna hago un XOR de
las palabras de la cabecera.
El campo de comprobación, por tanto, permite detectar cualquier número impar de errores → Si pasa, lo
descartamos.
El destino hace una operación igual de lo que recibe y lo compara con ese campo (que se calculó en el destino).
Si no es igual, hay algún error.
IP Origen e IP Destino: Son obviamente esenciales
El datagrama se encapsula salto a salto en función de la tecnología (ADSL, fibra…). La arquitectura TCP/IP es
agnóstica a lo que haya por debajo → Pero tengo que tomar algunas decisiones.
No conozco la trama física → IP solo conoce el

primer salto.
• ¿Con qué tamaño genero los saltos?
Cada salto se caracteriza por una magnitud física → MTU (Maximum Transfer Unit). El tamaño máximo del
datagrama es 216 -1 Bytes
El origen pone el tamaño según la MTU del primer salto → pero de repente se encuentra un MTU distinto en otro
salto (disminución de MTU). Para ello se usa la fragmentación IPv4:
• Tamaño máximo del datagrama 216-1 = 65.535bytes
• Es necesario adaptarse a la MTU (Maximum Transfer Unit) de cada subred
• El ensamblado solo se puede hacer en el destino final → ahí es donde sabemos que van a llegar todos los
fragmentos.
Llega un datagrama con MTU 4200 Bytes (20+4180) y se encuentra con un Ehernet

que tiene 1500 Bytes de MTU → Problema → Se hace una fragmentación → De ahí
los 3 campos que nos saltamos “Identificación”, “I” y “Desplazamiento”
Identificación: Número de datagrama (el origen lo va aumentando)
Indicadores (I):
 Bit Don’t Fragment: Prohibe/Impide que se frafmente
 Bit More Fragments: Vale 1 en todos los fragmentos excepto el último
Desplazamiento: Posición del fragmento respecto al tamaño del datagrama original.
El bit MF solo vale 0 en el ultimo fragmento. Si se dividiese un fragmento en

subfragmentos solo se pondría a 0 el ultimo subfragmento del ultimo fragmento.
2.4. ASOCIACIÓN CON CAPA DE ENLACE: EL PROTOCOLO ARP

DIRECCIONES MAC
Tras la redirección IP → Enviar a la MAC del siguiente nodo.

El modelo de referencia es agnóstico de la red subyacente. Solo tiene en cuenta las capas de red, transporte y
aplicación. Lo de abajo le da igual. Pero vamos a ver cómo funciona un poco.
Tras consultar la tabla de encaminamiento → enviar el datagrama a la dirección Medium Access Control (MAC)
del siguiente nodo. Se usan en redes Ehernet (cableadas) y WiFi.
Formato de las direcciones MAC → 6 bytes: HH-HH-HH-HH-HH-HH → (p.e 00-24-21-A8-F7-6A)
Las direcciones MAC son únicas (identifican unívocamente a las tarjetas de red o a cada host), asignadas por
IEEE en lotes de 224 para cada fabricante. El prefijo (24 primeros bits) es del fabricante y cada uno va asignando
los otros 24bits.
Las MAC origen y destino van cambiando.
Existe definida una dirección de difusión (broadcast) FF-FF-FF-FF-FF-FF. De esta forma podemos
mandar/enviar trama a todos los destinos de la red.

Protocolo: Address Resolution Protocol (ARP) → Obtener la dirección MAC a partir de la IP.
Nos ayuda a resolver esta pregunta: Dada una IP, ¿cómo consigo la MAC?
Hago un broadcast (a todos) y pregunto cuál es la MAC de la IP → le contestan.

Se hace con la TABLA ARP (esta se almacena localmente).
IP MAC Timer
Se va registando la asocación IP-MAC →
Timer: Refresco → descarto la entrada si no la uso.

Con el comando “arp -a” puedo ver la tabla.
Protocolo: Reverse ARP (RARP) → Obtener la IP a partir de la MAC

FORMATO ARP
HTipo → Hardware | PTipo →
Protocolo
2.5. EL PROTOCOLO ICMP (Internet Control Message Protocol)
Se transporta en IP. Informa sobre situaciones de error en IP → es un protocolo de señalización.
Sirve, por tanto, para informar/enviar información de señalización → datos que tienen que ver
con el control de lo que está pasando (diagnósticos, errores, eventos que ayudan a funciona…).
Suelen ir (excepto eco y solicitudes) hacia el origen del datagrama IP original.
ICMP se encapsula en IP → IP ICMP
La cabecera es de 32 bits. Incluye la cabecera

del datagrama que ha disparado el mensaje
Tiene 3 campos:
• Tipo (8 bits): tipo de mensaje
• Código (8 bits): subtipo de mensaje
• Comprobación (16 bits): checksum
Informan sobre eventos que han podido pasar.

Mensajes ICMP:
o Solicitud de eco: Detectar la alcanzabilidad de
diferentes datos (“ping {IP}”)
o Tiempo de vida excedido (TTL): Si TTL = 0, se
descarta.
o Destino inalcanzable: Tabla de encaminamiento
sin entrada para un destino

AUTOCONFIGURACIÓN DE LA CAPA DE RED (DHCP)
DHCP es un protocolo que usa UDP, que a su vez usa IP y a su vez se encapsula en la capa
subyacente de la que el protocol IP es agnóstico.
? IP UDP DHCP
DHCP sirve para configurar dinámicamente el networking de cualquier equipo/dispositivo de

forma automática. Tiene un puerto reservado: el 67. El servidor DHCP va escuchando por este
puerto.
Entro en una WiFi. Habrá una máquina escuchando el puerto 67 y respondiendo a las
necesidades.
El host (cliente DHCP) genera y envía el mensaje “DHC Discover” en broadcast:

o IP origen: 0.0.0.0 (no tenemos todavía)
o IP destino: 255.255.255.255 (broadcast)
o Puerto origen: 68
o Puerto destino: 67
Este mensaje llega a todo el mundo. En concreto al servidor.
El servidor mira la tabla y responde con la oferta → mensaje “DHC Offer”
o IP origen: la del servidor
o IP destino: 255.255.255.255 (broadcast)
o Su dirección IP: la que sea
o Tiempo de vida: “Te la presto durante este tiempo”. La que sea.
Luego el cliente solicita una dirección IP con mensaje DHCPRequest y el servidor le envía la
dirección IP con el mensaje DHCP ack.
De esta forma el cliente se autoconfigura.

Tema-3-FR.pdf
S_GRND

Telecomunicación

Tema 3
Capa de Transporte
3.1. INTRODUCCIÓN
En la capa de transporte hay dos alternativas. Ciertas aplicaciones usarán un protocolo de los dos siguiente y
harán la elección basándose en criterios de diseño:
• UDP: Es un protocolo sencillo. Tiene dificultades en el envío y en la recepción de mensajes
• TCP: Es un protocolo con gran complejidad. Tiene más retardos.
Funciones y servicios de la capa de transporte:

 Ofrece una comunicación extremo a extremo (end to end). De hecho, es la primera capa extremo a extremo.
o IP ofrecía routing y la fragmentación SALTO A SALTO pero ahora nos metemos en capa END to
END: Las entidades origen y destino hablan/se comunican virtualmente entre sí.

 Realiza la multiplexación/demultiplexación de aplicaciones → Puerto.
o En capa de transporte se identifican las entidades con el puerto. El puerto indica a quién va y de
quién viene la información. Es un número de 16 bits.
Protocolo UDP:
 Realiza la multiplexación/demultiplexación de aplicaciones.
 Ofrece un servicio
o no orientado a conexión. Parecido a correo por buzón.
o no fiable (sin recuperación de errores). Es decir, hay muchos problemas y no tiene código/recursos
para mitigar los problemas que más abajo puede tener IP.
Protocolo TCP
 Realiza la multiplexación/demultiplexación de aplicaciones.
 Ofrece un servicio
o orientado a conexión. Parecido a la comunicación por teléfono,
o fiable
o que incluye
▪ control de errores y flujo
▪ control de la conexión
▪ control de la congestión
TCP tiene además extensiones de las que hablaremos más adelante.
3.2. PROTOCOLO UDP
UDP = User Datagram Protocol. Se especificó en los años 70.
Ofrece un servicio/funcionalidad best-effort (de buena voluntad) (igual que IP). Hace lo que puede. No tiene
mecanismos explícitos para detectar errores, controlar el flujo, ordenar paquetes…
Recordemos que IP es vulnerable estas eventualidades. UDP no añade mucho más. UDP empieza a enviar la
información sin comprobar nada. Cada unidad de datos de UDP se envía de forma independiente.
• Es un servicio no orientado a conexión: no hand-shaking, no hay retardos de establecimiento, cada TPDU

(unidad de protocolo de datos) es independiente.
• Resulta en un servicio no fiable: puede haber pérdidas.
• No hay garantías de entrega ordenada
• No hay control de congestión, No hay control de flujo: entrega tan rápida como se pueda.
Entonces, ¿qué ofrece?

La multiplexación: identificar de quién viene y a quién va la información.
Los mensajes se encapsulan en UDP, que a su vez se encapsulan en IP y a su vez de la tecnología subyacente.
¿Cómo lo hace? Una posibilidad es usar como metodología para identificar a las aplicaciones el PID.
Problema: no es universal. En cada máquina es distinto. No sirve. Es algo muy local. El SO es el que da el PID a

los procesos.
Utilizamos por tanto el puerto para identificar de quién viene a quién va la información.
Cabecera:
➢ 16 bits de quién viene (puerto origen)
➢ 16 bits a quién va (puerto destino)
➢ 16 bits: cuántos bytes ocupa (cabecera + datos). 216 B= 64KBytes → Podemos tener hasta unidades de
datos de 216 B/64KB
➢ 16 bits de comprobación: checksum. Ponemos todas las palabras de 16 bits y se realiza una operación de
paridad (XOR, p.e). El resultado de esta operación por columnas se escribe en ese campo. Cuando llega
al destino, hace una operación similar y compara por si hay alguna diferencia con el campo checksum.
En el cómputo de checksum se incluye una pseudocabecera. En esta se incluye la IP origen y la IP destino
y otros campos. Esto se hace para detectar errores en el NAT → Las IPs destinos y origen no cambian
salvo que haya NAT (se pasa de IP privada a pública o al revés). Es decir, esto se realiza para tener un
nivel de control. Puede haber errores/inconsistencias en la tabla de traducción de NAT. Así, detecta estos
errores.

Multiplexación/demultiplexación: el objetivo es transportar las TPDU al proceso correcto. Para ello se usan los
puertos:
PUERTOS
Números enteros de 2Bytes que identifican al proceso origen y al proceso destino.
Existen puertos preasignados con servicios normalizados → Los que están por debajo de 1024. Se usan para
identificar servicios que conocemos como
A partir del 1024, los puertos están libres para el desarrollador.
¿Para qué sirve entonces UDP si solo añade esto? Para aplicaciones tolerantes a errores y exigentes respecto al
retardo. Solo implementa checksum para esto. UDP no tiene mecanismos de retroalimentación
Por tanto, UDP se usa frecuentemente para aplicaciones multimedia que son tolerantes a fallos y muy sensibles a
los retardos (no admiten recuperaciones de errores). No hay tiempo para detectar errores. Puede perderse un

frame/fragmento de video/audio.
A la unidad de datos de UDP se le llama datagrama de usuario. Es parecido a IP si nos fijamos, hereda la palabra
datagrama porque añade muy poco a IP.
3.3. PROTOCOLO TCP

Lo que nos interesa (lo importante) es qué cosas resuelve y cómo las resuelve.
Características principales del TCP:

• Ofrece un servicio punto a punto. No sirve para comunicaciones multicast (de uno a muchos). Solo se
puede usar en conexiones de uno a uno.
Recordemos que hay datagramas IP de clase D: direcciones que son multicast. Para esto no se puede usar
TCP ya que solo se puede para unicast, no para multicast.
• Implica un servicio orientado a conexión (exige un estado común entre el emisor y el receptor: “hand-
shaking”. Es decir, las dos entidades (origen y destino) tienen que establecer un estado en común o
negociar antes de intercambiarse datos). Lo hace en 3 fases:
o Establecimiento de la conexión
o Intercambio de los datos
o Liberar recursos cerrando la conexión
• Garantiza la entrega ordenada de las secuencias de bytes generadas por la aplicación (“stream oriented”).
La conexión TCP es como una tubería de extremo a extremo tal que garantiza que la aplicación recibe el
mensaje de forma ordenada (el 1º que entra es el 1º que sale).
Esto lo hace a pesar de que por debajo esté IP (ya sabemos que IP lo hace de forma desordenada).

Es decir, TCP hace que la aplicación vea IP como una tubería. Sale sin errores, con control de lfujo y de
congestión y de forma ordenada
Como hemos dicho, garantiza la entrega ordenada, enfocado a los stream – secuencia de bytes.
TCP se encarga de corregir y resolver los problemas.
• Opera en transmisión full-duplex. Se puede enviar en ambos sentidos y simultáneamente (se puede enviar
y recibir a la vez).
• Incluye mecanismos de detección y recuperación de errores (ARQ) con confirmaciones positivas ACKs
(acumulativas) y “timeouts” adaptables. Detecta y recupera errores de la siguiente forma:

TCP
SEGMENTO
(en UDP se llamaba datagrama de usuario)
Si está bien, el otro extremo envía un segmento de confirmación (ACK). Arrancamos un timer → confianza de
que transcurrido un tiempo me llegue el ACK.
Puede ocurrir que se pierda/descarte. El temporizador alcanzará un valor preestablecido, generando un mensaje:
TIMEOUT. Este mensaje indica que ha habido un problema y reenvía el mensaje.

Recordemos que los objetivos eran transparencia y… eficacia
Lo anterior tiene que ser eficaz. Si el timeout es muy grande (tengo que esperar mucho tiempo para darme cuenta),
estoy perdiendo muchos recursos → poco eficaz. Si el timeout es pequeño, puedo hacer retransmisiones
innecesarias.
El timeout, por tanto, es crítico para la eficacia del protocolo. ¿Cuál es el timeout óptimo? Es una situación
variable/impredecible. Solución adaptable: TCP se va adaptando a la red. El timeout saltará de forma adaptable.
ACK también se llaman acumulativos → puedo hacer ACK que pueda ---- más de un segmento para ----
• Ofrece un servicio fiable → control de congestión y control de flujo con ventanas deslizantes con tamaño
máximo adaptable
• Usa la técnica de Incorporación de confirmaciones (“piggybacking”)
• Para mejorar su eficacia TCP se ADAPTA a las condiciones de la red DINÁMICAMENTE. Es todo muy
adaptable, dependiendo de la dinámica o de las condiciones de la red. No es fijo.

Funcionalidades de TCP:
o Multiplexación/demultiplexación de aplicaciones
o Control de la conexión (establecimiento y cierre)
o Control de errores y de flujo
o Control de congestión
Las TDPUs de TCP se denominan segmentos TCP. Cada segmento TCP se encapsula en un paquete IP
(denominado datagrama)
CABECERA DE TCP:
Cada segmento TCP tiene una cabecera de 20 Bytes por lo menos. Me ayuda a implementar las funcionalidades.
*no es obligatorio sabérselo*
o Puerto origen y puerto destino para identificar de quien viene y a quién va la información.
o Número de secuencia: Numera los segmentos para asegurarme que vaya ordenado (IP lo mandaba de
forma desordenada).
La app genera mensajes → numera los segmentos como una cuenta creciente de Bytes.
Como envío datos en un sentido, aprovecho la cabecera para confirmar en el otro sentido. Así es eficaz.
Bits:
U: Urgentes. Se pone ON cuando quiere forzar que la entrega no sea ordenada. Hay situaciones en las que es
necesario un mecanismo que permita enviar datos de forma ordenada y romper con la disciplina de entrega
ordenada de los datos. 3 o 4 bytes del puntero de datos urgentes mándalos saltándole.
A: ACK. No siempre tenemos cosas que confirmar. Para determinar si el segmento confirma en sentido contrario
(ON) o no (OFF)
P: PUSH. Mecanismo para que algún extremo de la tubería vacíe el buffer que implica TCP
R: RESET. Cuando hay algún tipo de problema, para evitar dificultades o bloqueos, se utiliza RESET para volver
al estado inicial

S: SINCRONIZACION. Establecer la llamada/conexión, se envía el bit a ON para hacer un “ring”.
F: FIN. Liberar los recursos y cerrar la conexión.
Fijémonos el fuerte acoplamiento entre cliente y servidor.
MULTIPLEXACIÓN/DEMULTIPLEXACIÓN
La multiplexación/demultiplexación de aplicaciones tiene como objetivo transportar las TPDUs (segmentos TCP)
al proceso correcto. Para ello se usan los puertos → números enteros de 2 bytes que identifican al proceso origen
y al proceso destino.
Existen puertos preasignados con servicios normalizados:
Otros puertos (>1024) están a libre disposición del desarrollador.

Cada “conexión TCP” se identifica por: puerto e IP origen y puerto e IP destino.

CONTROL DE LA CONEXIÓN
TCP ofrece un servicio orientado a conexión. La conexión implica que el TCP de un extremo se tiene que poner
de acuerdo con el otro extremo → se tienen que sincronizar, utilizando IP.
El intercambio de información tiene tres fases:

1. Establecimiento de la conexión (sincronizar # de secuencia y reservar recursos).
2. Intercambio de datos (full-duplex).
3. Cierre de la conexión (liberar recursos)
¿Es posible garantizar un establecimiento/cierre fiable de la conexión sobre un servicio (IP) no fiable? Es decir,
¿es posible que establezcan esa llamada sin fisuras a través de un servicio que no resuelve las fisuras como IP?
NO
No hay forma de sincronizar dos procesos utilizando TCP. TCP hace esto arriesgándose.
Establecimiento de la conexión: three-way-handshake

Handshake: Enviando segmentos sin datos permite sincronizar al emisor y receptor.
Existen dos roles:

• Rol de cliente: hace la apertura activa. “El Ring” → dice “oye, resérvame x que voy a hacer una conexión”.
• Rol de servidor: hace la apertura pasiva. Está escuchando en un puerto hasta que le llega la petición.

Debilidades:
 No es infalible. Cualquier mensaje se puede perder. Necesito protegerme. → TIMER
 Reserva condicional de recursos → Vulnerable a ataques de denegación de servicio (DOS)
o Muchos clientes piden conexión y los da incondicionalmente
 Los segmentos pueden llegar desordenados, los almacena temporalmente para ordenarlos y esto consume
memoria.
En TCP, si llega el segmento 3 sin el 1 y el 2, lo almacena esperando a que lleguen ellos.

En las conexiones TCP hay una ventana en el emisor donde se almacenan bytes para una copia temporal, y otra
venta en el receptor esperando.
Estas ventanas tienen que estar sincronizadas en el servidor tal que cuando envío un segmento el número de
secuencia debe ser el que espera → con el receptor se ordenan a partir de este.

ESTABLECIMIENTO DE LA CONEXIÓN. NÚMEROS DE SECUENCIA
• El número de secuencia es un campo de 32 bits que cuenta bytes en módulo 232 (el contador se da la vuelta
cuando llega al valor máximo).
• El número de secuencia no empieza normalmente en 0, sino en un valor denominado ISN (Initial Sequence
Number) elegido “teóricamente” al azar, para evitar confusiones con solicitudes anteriores.
• El ISN es elegido por el sistema (cliente o servidor). El estándar sugiere utilizar un contador entero
incrementando en 1 cada 4 μs aproximadamente. En este caso el contador se da la vuelta (y el ISN
reaparece) al cabo de 4horas y 46 minutos.
• El mecanismo de selección de los ISN es suficientemente fiable para proteger de coincidencias, pero no
es un mecanismo de protección frente a sabotajes. Es muy fácil averiguar el ISN de una conexión e
interceptarla suplantando a alguno de los dos participantes.
• TCP incrementa el número de secuencia de cada segmento según los bytes que tenía el segmento anterior,
con una sola excepción: los flags SYN y FIN incrementan en 1 el número de secuencia.
• Los segmentos ACK (sin datos) no incrementan el número de secuencia
CASO SIN INCIDENCIAS (NORMAL):

El emisor manda el mensaje diciendo que el número de secuencia es el 100. El receptor lo confirma enviando un
ACK = 101 (confirmar lo enviado hasta el 101) al otro sentido con un número de secuencia 300 (desde la otra
ventana del receptor (la de emisión). Este mensaje ACK llega al emisor a su ventana de recepción. Luego, este
reenvía el mensaje/información.

CASO DE CONEXIÓN SIMULTÁNEA:
Puede ocurrir que ambas entidades hagan un RING simultáneamente. Esto lo prevé el protocolo. Se acepta.
CASO CON SYN RETRASADOS Y DUPLICADOS
Puede ocurrir que un mensaje se retrase → Para ello está el timeout
Recordemos la utilidad de:

• Ventana de Emisión: Para guardar copias temporales de lo que envías por si no llega bien.
• Ventana de Recepción: Por si los segmentos llegan desordenados. Zona de memoria reservada para admitir
esas recepciones desordenadas.
Ambos extremos son emisores y receptores a la vez.
CIERRE DE LA CONEXIÓN: CASO NORMAL
En algún momento tienen que cerrar la conexión
y liberar los recursos.
Quien haya terminado primero, envía una
solicitud de cierre con el flag FIN a 1. Si el otro
ha terminado también, enviará un paquete con
FIN a 1.
- Solicito Cierre
- Confirmo y solicito cierre
- Confirmo.
Hay otras posibilidades de cierre de la conexión

(lo veremos en el diagrama de estados siguiente).
METODOLOGÍA PARA LA DESCRIPCIÓN FORMAL DE PROTOCOLOS

Es una herramienta para describir un protocolo (es trascendental a TCP).
AUTÓMATA DE ESTADOS FINITOS

Los estados representan situaciones en la dinámica/evolución del protocolo.
Las transiciones representan cuando se ha recibido/transmitido un evento.
Pero por debajo está IP → pueden perderse o retrasarse los datos
Cliente y servidor arrancan en CLOSED.

CONTROL DE ERRORES
El objetivo es mejorar el rendimiento mediante una ventana deslizante. El control de errores utiliza un esquema
ARQ con confirmaciones positivas y acumulativas.
Campos involucrados:
• Campo secuencia: offset (en bytes) dentro del mensaje
• Campo acuse: número de byte esperado en el receptor
• Bit A (ACK) del campo de control
• Campo comprobación: checksum de todo el segmento y sudo de pseudocabecera TCP:
La imagen de la izquierda representa la evolución normal.
Pero todo el tiempo (desde que sale el ultimo bit de A hasta que

llega el ACK desde B) estamos desaprovechando recursos.
Para solucionar esto, se envían más de un paquete para que sea eficaz → por eso los
segmentos tienen que ir numerados. Y por eso también tenemos una ventana que los
almacena.
Si un segmento no llega bien, el timer (temporizador) (no llega el ACK) provocará

un timeout y se volverá a enviar el paquete.
Si llega bien (llegó el AFK de 1), no tiene que almacenarlo en memoria y desplazará
la ventana de emisión → En el receptor se pasa a la aplicación el segmento y se
desplaza la ventana de recepción.
El timeout por tanto, es un punto clave para la eficacia. ¿Cuál es el timeout adecuado? Debe ser mayor que el
tiempo de ida y vuelta (RTT) pero, ¿cuánto?
• TIMEOUT GRANDE: Reacción lenta a pérdida de segmentos → Baja eficacia. El emisor tarda en
descubrir pérdida/retraso.
• TIMEOUT PEQUEÑO: Timeouts prematuros → Retransmisiones innecesarias. Puede haber reenvíos
innecesarios.
Tenemos que elegirlo adecuadamente.

El timeout es grande o pequeño respecto al ping (tiempo de ida y vuelta, RTT) y este último es variable (un
paquete puede enviarse a 100 y otro a 250, por ejemplo). En la imagen de abajo vemos como evoluciona el ping
en una conexión entre dos puntos.
Para situaciones cambiantes la mejor solución es adaptarse dinámicamente.

ESCENARIOS DE RETRANSMISIÓN

GENERACIÓN DE ACKS
1º Evento: Llega un evento que implica que llega un segmento ordenado.
• TCP debería confirmarlo → Espera hasta 500msg para confirmar de dos en dos.
• El segmento coincide con el límite inferior y llega ordenadamente.
Receptor:
2º Llega un evento ordenado pero tiene pendiente un ACK retrasado. Se envía un único ACK acumulativo y de
esta forma todo lo recibido hasta ahí queda confirmado. Así cuando va todo bien, TCP va confirmando de dos
en dos eventos: Llega, espera, llega, confirma y así sucesivamente.
3º Evento: Llega un segmento desordenado. Se almacena temporalmente y se confirma lo que puede. Se con-
firma duplicadamente lo que se puede. → ACK duplicado
4º Evento: Llega un segmento que completa una discontinuidad → Se confirma ese y el siguiente y se desplaza
la ventana de congestión.

ESTIMACIÓN DE LOS TIMEOUTS
Media móvil → Paquete a paquete tendremos que ir sabiendo cómo va el tiempo de ida
y vuelta (PING o RTT < round trip times>). Segmento a segmento lo podemos medir
El RTT suavizado es una suma ponderada del RTTMedido (actual) y el anterior.

Vamos a estimar un RTTNuevo=RTTMedido*α+(1- α)*RTTviejo (α es constante).
Si α → 1, doy importancia a RTTMedido

Si α → 0, doy importancia a RTTAnterior
Se escoge siempre α=0.875
Segmento a segmento podemos obtener una

estimación del timeout con RTTNuevo+4*desviación
Problema de ACKs repetidos: ambigüedad en la interpretación

El control de errores funciona en distintos escenarios. El ACK apunta siempre al Byte siguiente para decir que
hasta ahí acepta.
Los ACKs se pueden perder. Cuando ocurre esto, repetimos y volvemos enviar el segmento.
Cuando llega una repetición del segmento lo ignora (la ventana ignora peticiones de segmentos que no estén
dentro) ya que la ventana se ha desplazado.

Cuando se confirma dos veces, la ventana se desplaza dos veces. Un timeout prematuro puede causar que se
reenvíe la petición y la ventana lo ignore porque se ha desplazado dos veces.
Solución: Algoritmo de Karn, actualizar el RTT sólo para los no ambiguos, pero si hay que repetir un segmento
duplicar el timeout:
¿Qué pasa cuando hay un timeout? Puede ser que el ACK corresponda a un segmento u a otro. Lo que hacemos
es multiplicar por dos el timeout actual para evitar una posible mala interpretación.
CONTROL DE FLUJO
Procedimiento para evitar que el emisor sature al receptor con el envío de demasiada información y/o demasiado
rápido. Es un mecanismo de regulación.
El problema del flujo es: Si el emisor escribe muy rápido y el receptor va leyendo más lento, el buffer se llena y
se perderá información. Para evitar saturar el servidor, se utiliza el esquema crediticio.
El control de flujo es un esquema crediticio: el receptor informa al emisor sobre los bytes autorizados a emitir sin
esperar respuesta. El receptor manda la disponibilidad (“puedo 4K, 1K, 0K…) → Da permiso según la
disponibilidad.
Es un esquema de retroalimentación extremo a extremo.

Informa sobre un campo: WIN (¨ventana) → Ahí dirá lo que tiene disponibles.
Se utiliza el campo ventana:
Ventana útil del emisor = ventana ofertada receptor – bytes de tránsito
Si envío más de lo que puede, bloqueo y quedo esperando lo que falta por enviar (lo demás si se envía).

¿Alguna debilidad en el control de flujo? Tras un bloqueo,
cuando hay una liberación el ACK se puede perder → Se
quedarían los dos extremos bloqueados. En la imagen de
arriba, imaginemos que se pierde el anuncio de
WIN=20148 (el penúltimo mensaje). Se bloquearía.
¿Cómo lo evitamos? Mediante un temporizador de
persistencia.
El temporizador de persistencia/timer consiste en lo

siguiente: Cuando me llega WIN0, bloqueo y cuando
pasa un tiempo reenvío el mensaje.
Posible problema: Síndrome de la ventana tonta si se utilizan segmentos muy pequeños.

Si dicto muy rápido y escribes muy lento, tu me das de crédito (posibilidad de enviar) un byte y yo te mando
otro… Muy lento.
Se soluciona con la ventana optimista: no enviando crédito (no informando de que me queda espacio libre)
mientras no sea suficiente.
Es posible hacer entregas “no ordenadas”: Bit U, campo puntero
Solicitar una entrega inmediata a la aplicación: bit P

CONTROL DE CONGESTIÓN
• La red tiene recursos limitados. Si todo sale a la vez, surge la congestión.
• Es un problema debido a la insuficiencia de recursos (la capacidad o velocidad de transmisión de las líneas
y el buffer en routers y hosts no son infinitos).
o Recursos:
▪ Capacidad ≡ VT ≡ BW (bps) < ∞ (es finito)
▪ Capacidad de almacenamiento en routers ≡ Buffer < ∞ (es finito)
• Es un problema diferente al control del flujo: el control de congestión es para proteger a la red debido a
sus limitaciones Se trata de regular el tráfico. La red tiene capacidades finitas. Necesitamos un mecanismo
que regule el tráfico. La congestión es un mecanismo para proteger los recursos de la red. Pero queremos
que sea eficaz (que maximice los recursos), imparcial (justo) y estable (que no oscile).
• ¿Cómo regula información TCP para proteger los recursos de la red? Con la ventana de congestión
(cantidad/tamaño máximo de bytes que el emisor puede generar). El control de congestión se realiza
limitando la ventana de congestión (CongWin). → En un momento dado los bytes que se pueden enviar
es el mínimo de la ventana de congestión y de recepción. TCP hace prueba error. Empieza poco a poco
para ver cómo va la cosa). (La ventana de congestión empieza permitiendo un segmento.)

• Puede tener naturaleza adelante-atrás, aunque en IP no
• Los episodios de congestión se manifiestan en retrasos en las ACKs y/o pérdidas de segmentos,
dependiendo del nivel de severidad del episodio
• Solución extremo a extremo: en el emisor limitar de forma adaptable el tráfico generado para evitar
pérdidas, pero siendo eficaz
• La limitación se hace mediante una aproximación conservadora: limitando el tamaño de la ventana de
emisión.
• ¿Qué es el producto BandWidth-Delay (RTT)? ¿Por qué es importante?
Procedimiento de prueba y error

En el emisor se utilizan dos ventana y un umbral
Podemos enviar el mínimo de la ventana del control de flujo (del receptor) y de la de congestión.
MMS → Maximum Segment Size (en Bytes)
Vamos a dividir la ventana en segmentos.
La ventana de congestión se encuentra en el emisor.

TAM máximo: límite de segmentos que puedo enviar sin que me llegue confirmación. Son los bytes que puedo
enviar
Dos formas de comportarse:
• Mientras TAM ventana < umbral
o Zona de inicio lento
o Envía un segmento y nos paramos (congwin=1).
o Por cada ACK recibido aumento la ventana de congestión en un MSS.
Va creciendo exponencialmente

• Si CongWin > umbral
o Voy a crecer más lento → Zona de prevención de congestión
o Cuando recibo todos los ACKs aumento en 1
o Por ejemplo: Envío 8 segmentos, recibo los 8 ACKs y CongWin = 9
Va creciendo de forma lineal

El timeout es síntoma de congestión.
Cuando se produce un timeout se pone la ventana de congestión a 1 (CongWin = 1) y el umbral se pone a la mitad
El TCP se sintoniza con syscontrol (sysctl). Hay una ventana de congestión por cada conexión TCP.

3.4. EXTENSIONES TCP
EXTENSIONES TCP
TCP se define con múltiples “sabores”. Los sabores son las distintas formas en las que podemos gestionar la
ventana de congestión.
• RENO →Si 3 ACKs duplicados → baja la ventana de congestión
• TCPCubic → Linux lo utiliza en las últimas versiones. Utiliza una función cúbica
o Depende del tiempo transcurrido desde el último timeout (la ventana va creciendo respecto a eso).
Los diferentes sabores no afectan a la interoperabilidad entre los extremos.

Recordemos que hay un campo opcional (muy poco usado) en la cabecera TCP: Opciones que se negocian en el
establecimiento de la conexión. Estas son varias:
• Ventana escalada: El establecer la conexión si los dos procesos (emisor y receptor) están de acuerdo, se
negocian un factor de escala que permite multiplicar los créditos que te doy por ese factor. Opción TCP
en segmentos SYN: Hasta 214 * 216 bytes = 230 bytes autorizados. = 1 GB. → COMO MÁXIMO!
Recordemos que en la ventana de control de flujo el crédito máximo que me pueden dar es 2 16 Bytes =
64KBytes. Antes esto era suficientemente grande, pero la cosa cambia ahora con tanta velocidad de
transmisión y el mismo tamaño de ventana.
• Estimación RTT: Recordemos que cada vez que enviamos un segmento ponemos en marcha el reloj.
Podemos negociar un time-stamp (sello de tiempo) en la cabecera del segmento y cuando vuelve el ACK
no hace falta consultar el reloj sino comparar los tiempos
• PAWS (“Protect Against Wrapped Sequence numbers”). Sello de tiempo y rechazo de segmentos
duplicados.
• SACKS (“ACKs selectivos”).

Tema-4-FR.pdf
S_GRND

Telecomunicación

Tema 4
Seguridad en Redes
4.1. INTRODUCCIÓN
Recordemos: tenemos una arquitectura en capas donde la
app se encapsula en tramas, las tramas en IPs, etc.
La seguridad es un problema a tratar.
La seguridad es un problema multidimensional → Afecta

a varios aspectos.
¿Cuándo es una red segura? ¿Cuándo se garantiza? Una red de comunicaciones es segura cuando se garantizan
todos los aspectos. No hay protocolos ni redes 100% seguros.

Los aspectos son:
• Confidencialidad/privacidad: El contenido de la información es comprensible sólo por entidades
autorizadas.
• Autenticación: Las entidades son quien dicen ser. Garantía feaciente sin fisuras de la identidad → de que
A es A.
• Control de Accesos: Los servicios están accesibles sólo a entidades autorizadas. Se trata de garantizar de
forma feaciente (sin fisuras). No es tanto la información sino el servicio en sí (DHCP, RIP, SSH…) →
Quiero que solo se puedan acceder a través de las entidades autorizadas.
• No repudio o irrenunciabilidad: el sistema impide la renuncia de la autoría de una determinada acción. Si
no puede repudiar la autoría de algo, sería caótico.
• Integridad: Garantizar que el sistema detecta todas las alteraciones (intencionadas o no) de la información.
Es imposible evitar las alteraciones pero sí que podemos detectarlas
• Disponibilidad: El sistema mantiene las prestaciones de los servicios con independencia de la demanda.
Cuando podemos garantizar todo esto, el sistema parece seguro. NUNCA AL 100%
¿En qué nivel se debe situar la seguridad? En TODOS… Hay que poner seguridad en todos los lados de la
arquitectura por capas. El grado/nivel de seguridad lo fija el punto más débil.
Ataque de seguridad: Cualquier acción intencionada o no (errores) que menoscaba o pone en entredicho
cualquiera de los aspectos de seguridad mencionados anteriormente.
Tipos de ataques:
• Sniffing: Ataques/vulneración de la confidencialidad. Escuchas a la información (husmear).
• Spoofing: Suplantación de la identidad de entidades. Ataques a la autenticación.
o Pishing: Captura de información una vez hecho spoofing
• Man in the middle: hombre en medio. Ataques de interceptación
• Distributed Denial Of Service (DDoS): Denegación de servicio distribuido. Ataques a la disponibilidad.
Por ejemplo, el Flooding (inundación)
• Malware: Software malintencionado: Troyanos, gusanos, spyware, backdoors, rookits, ransomware,
keyloggers…
MECANISMOS DE SEGURIDAD
• De prevención: anticiparnos al ataque (intencionado o no). Nos centraremos en estos
o Mecanismos de autenticación e identificación
o Mecanismos de control de acceso.
o Mecanismos de separación (física, temporal, lógica, criptográfica y fragmentación).
o Mecanismos de seguridad en las comunicaciones (cifrado de la información).
• De detección: Poner herramientas de inspección
o IDS (Intruder Detection System): Software de análisis. Hace monitorización del tráfico y detecta
anomalías yeventos sospechosos.
• De recuperación: Una vez que hemos sufrido el ataque.
o Copias de seguridad (backups)
o Mecanismos de análisis forense: averiguar alcance, las actividades del intruso en el sistema y cómo
entró.
HERRAMIENTAS PARA LA SEGURIDAD

 Cifrado (simétrico y asimétrico)
 Autenticación con clave secreta (reto-respuesta)
 Intercambio de Diffie-Hellman(establecimiento de clave secreta)
 Funciones Hash. Hash Message Authentication Code(HMAC).
 Firma Digital.
 Certificados digitales.

4.2. CIFRADO (SIMÉTRICO Y ASIMÉTRICO)
Se trata de realizar un intercambio de información sin que un tercero conozca/acceda a la información.
Está basado en la criptografía y es un procedimiento utilizado para garantizar la confidencialidad → Restringir
el acceso a terceros no deseados.
Se trata de transformar el texto plano/claro P a través de un algoritmo o mecanismo tal que este proceso es
irreversible a menos que conozcamos una información: la clave. Como resultado, obtendremos el texto cifrado,C.
P → EK(P) = C donde K es la clave y E es un algoritmo
Si no conoces la clave, no puedes cifrar/descrifrar la información. Se basa en la existencia de unalgoritmode

cifrado/descifrado, normalmente conocido EK() y DK’() . La dificultad reside en la existencia de unas claves de
cifrado (K) y descifrado (K ́) desconocidas.
El descrifrado se trata de, utilizando una clave recuperamos la información inicial. DK’(C)=P donde K’ es la clave
y D el algoritmo.
Tipos de cifrado:
 Cifrado simétrico o con clave secreta: K=K’.
o Computacionalmente son más fáciles (menos costosos)
 Cifrado asimétrico o con clave pública/privada. KPUB/KPRIV.
o Más complicados (más costosos).
o Más robustos/fuertes/difíciles de “vulnerar”.

CIFRADO SIMÉTRICO, ALGORITMOS DE CLAVE SECRETA:
Existe una sola clave para cifrar y descifrar (k=k’)
DES (“Data Encryption Standard”): Estándar que se acordó como norma. Fue especificado en el 75 por IBM y
propuso un algoritmo de cifrado simétrico. Este algoritmo es considerado no seguro.
Cuando se encuentra alguna metodología que reduzca el espacio de búsqueda por fuerza bruta en cualquier orden
de magnitud, es no seguro. P.e 56 bits → 256 claves → voy probando una a una. Si alguien ve la forma de reducir
de 256 a 245, es no seguro.
Pese a no ser seguro, se sigue usando.
DES coje el texto plano. Los agrupa en bloques de 64 bits. Hace operaciones con la clave. Sale una cadena de 64
bits.
Para descifrar, DES aplica la clave al revés. Se cogen los subconjuntos de la clave en orden inverso. Por eso se
llama cifrado simétrico.

DES: Es un esquema de sustitución monoalfabético. Entra un símbolo y sale otro.
Esto es lo que hace DES

Los esquemas de sustitución monoalfabético no son robustos.
En el ejemplo anterior hay 26*25*24*…*2*1 = 26! Sustituciones posibles.
¿Cómo se reduce la complejidad para reducir el espacio de opciones posibles? Adopto la hipótesis de que es
castellano.
La letra más posible por estadística es la “e” en el castellano. Cojo el texto cifrado y veo el que más se repite. Por
ejemplo la “c”. Tengo ese conocimiento a priori. Ahora son 25!. Porque supongo que esa letra es la “e”
Podríamos aplicar la misma hipótesis con la segunda más utilizada y así sucesivamente.
¿Cómo mejorar esa debilidad?

• DES Encadenado: Para evitar que DES sea un algoritmo de sustitución. Intentar que el símbolo de salida
no solo dependa del símbolo inicial sino de la historia pasada.

DES Doble: Pasar de 56 bits a 112 bits. Dos cifrados consecutivos. Cifro con una clave y vuelvo a cifrar → más
robusto.
DES Triple: 168 BITS. Cifrado, descifrado y cifrado con tres claves.
Existen alternativas seguras a DES:
IDEA (“International Data Encryption Algorithm”)
Simétrico: misma clave para cifrar y para descifrar. Claves de 128 bits. Opera en tiempo real

Los algoritmos de cifrado simétrico son muy rápidos, eficientes y tienen muy poca carga. Pero no son tan robustos
como los de cifrado asimétrico:
CIFRADO ASIMÉTRICO, ALGORITMOS DE CLAVE PÚBLICA/PRIVADA

Consiste en la asociación para cada usuario/entidad de dos claves: una clave pública y otra clave privada.
A→{KPUB / KPRIV}
Conocida la clave pública es computacionalmente imposible averiguar la privada.

Caves diferentes para cifrar y descifrar:
Cifrar → C = EKpub-B(P)
Descifrar → DKpriv-B(C)=DKpriv-B(DKpub-B(P)) = P
Si A quiere enviarle un texto a B cifrado, A lo cifra con la clave pública del destino (B), Como la pública es
conocida por todo el mundo, no hay problema. B es el único que conoce la clave privada que aplicada a la
información cifrada con la clave pública, recupera la información sin cifrar (la descifra). Solo lo puede hacer B.
A→B
KPUB-B(P) → KPRIV-B(KPUB-B(P)) = P

¿Y si envíamos C = EKpriv-A(P)? ¿Sirve como autenticación?
A→ B
KPRIV-A → KPUB-A(KPRIV-A(P)) = P
De esta forma podemos autenticar al origen Sabemos que A es A
Para ello tenemos que garantizar de forma feaciente que A está asociado a su clave pública (A→ KPUB-A) →
CERTIFICADO DIGITAL (asociación feaciente de tu identidad con tu clave pública)
Pero… ¿cómo se generan las llaves públicas y privadas?

RSA
Elegimos p y q primos grandes (> 101000).
Construimos dos funciones: n=(p*q) y z=(p-1)*(q-1) → función de Euler
Elegimos un d primo respecto a z.
Calculamos e tal que e.d mod z = 1 (algoritmo de Euclides)
Kpub = (e,n) y Kpriv = (d,n), de modo que:
C = pe mod n
P = Cd mod n

Ejemplo:
En resumen, tenemos dos tipos de cifrado:

• Ksecreta → eficaz computacionalmente y utilizada mucho para protocolos
• Kpub/Kpriv → menos eficaz pero más robusto.
4.3. AUTENTICACIÓN CON CLAVE SECRETA (RETO-RESPUESTA)

Autenticar consiste en verificar de forma fehaciente (sin fisuras) la identidad de las entidades involucradas. “A
es quien dice ser”. A puede ser un usuario, aplicación, puerto, IP, MAC…
Autenticar no es [login/password] → es identificar. No es autenticar porque no es de forma fehaciente y segura.

→ Por repetición se puede adivinar. No es nada seguro el password.
A <-----> KPUB_A (A está vinculada con su clave pública) → Certificado digital (lo veremos más adelante).
Hipótesis: ∃KAB → secreta R es random.

Suponemos que existe una clave secreta conocida solo por A y B que me va a ayudar por un protocolo que A sepa
que B es B. → Reto respuesta. Es un procedimiento de autenticación y cifrado basado en clave respuesta.
A le dice a B que es A. B reenvía un número aleatorio y le reta a que

cifre X mensaje que solo él conoce. A cifra y se lo pasa a B. También
le pasa otro número aleatorio como reto para que B cifre. B cifra y
compara con lo recibido de A. Además, envía el mensaje cifrado a A
(el reto que le propuso al final)
Aquí no hay repetición. Está protegida porque hay un rango de tiempo.
¿Es posible simplificar el procedimiento a 3 mensajes? Si:
A le dice a B que es A y le manda el reto

B responde diciendo que Es B, le manda el reto cifrado y le deja su reto
A le responde con el reto cifrado
¿Esto es vulnerable a un ataque por Reflexión? Si.
Coje el reto cifrado y cierra la sesión engañando a B.
Solución: Usar espacios de retos disjuntos. Es decir, que los random sean disjuntos.

------> Retos pares
<------ Retos impares
Recomendación: Usar nonces: Solo se puede usar una vez → Información de un solo uso.
Si introduzco en mis intercambios los nonces, evito ataques por repetición.
Los timestamps son un buen candidato (marca de tiempo).
4.4. INTERCAMBIO DE DIFFIE-HELLMAN (ESTABLECIMIENTO DE

CLAVE SECRETA)
¿Seríamos capaces de intercambiar información a voces sin que nadie se entere de la clave secreta? Elijo 3
números: x, n y g
Envío n, g y gx mod n a B
B elige un número → Coge el tercer número y lo eleva a su número elegido (y) → Clave secreta
→ Devuelve gy mod n
Yo cojo ese número y lo elevo a x. → Clave secreta
El intercambio de Diffie-Hellman: Permite establecer una clave secreta entre dos entidades a través de un canal
no seguro.

No se puede averiguar, es computacionalmente imposible. La gente sabe los dos primeros números, pero no eñ
último.
Debilidad: Nos permite establecer una clave secreta con el otro extremo, pero es susceptible a “Ataques man-in-
the-middle:
Alguien se interpone en medio → Posible ataque de spoofing.
Solución: Funciona bien si tenemos autenticado al otro extremo. Si no hay autenticación previa, este intercambio
se ve comprometido
Para autenticar hemos visto que necesitamos una clave secreta por reto-respuesta, pero para ella necesitamos
Diffie-Hellman. Pero además para Diffie-Hellman necesitamos autenticación. Entramos en un bucle pero
veremos que hay alternativas.

4.5. FUNCIONES HASH. HASH MESSAGE AUTHENTICATION CODE
(HMAC)
Transformación de un texto de entrada de cualquier longitud a un hash o compendio. Son funciones
unidireccionales (irreversibles) de cálculo sencillo.
Texto de entrada (M) de longitud variable.

M → H(M) siendo H(M) de longitud fija (256 o 512 bits)
Imposible obtener M a partir de su resumen H(M)
Invulnerables/Robustos a ataques de colisión. Dado M es
imposible encontrar M’ / M≠M’ y H(M) = H(M’); es decir,
es imposible encontrar un texto diferente con el mismo hash.
Ejemplos de funciones HASH: MD5, SHA-1, SHA-512
Las funciones Hash se usan para garantizar integridad + autenticación.
Integridad: Si tengo un texto, el sistema me garantiza que cualquier alteración al transmitirse se notifique.

Le añado algo al mensaje para garantizar su integridad (concateno una clave secreta que tengo con el destino y
el texto). Cualquier alteración de M, intencionada o no, se detecta gracias a que el destinatario hace el hash de
H(K|M’) y lo compara.
Hash Message Authentication Code (HMAC): M+H(K|M) pero para evitar ataques de extensión se usa M+H(K
| H(K|M)).: Se les concatenan más cosas para evitar ataques de extensión

➔ M’ tal que sea igual el hash
MD5 (“Message Digest 5”)

Proceso (resumen de 128 bits)
Relleno 100..0 de longitud máxima 448 bits
Adición de campo de longitud de 64 bits
División del mensaje en bloques de 512 bits
Procesamiento secuencial por bloques

SHA-1 (“Secure Hash Algorithm 1”)
Proceso (resumen de 160 bits)
Relleno de 100..0 de longitud máxima 448 bits
Adición de campo de longitud de 64 bits
División del mensaje en bloques de 512 bits
Procesamiento secuencial por bloques

4.6. FIRMA DIGITAL
Objetivos de la firma digital:
El receptor pueda autenticar al emisor (el firmante).
No hay repudio (irrenunciabilidad): Una vez que firmo no puedo decir que no he firmado.
El emisor (el firmante) tenga garantías de no falsificación (integridad) por parte del destinatario. Que no se altere
lo que firmo por el destinatario.
Firma digital con clave secreta. Hipótesis: existe una entidad de confianza,
responsable, no vulnerable: Big brother:
Cada entidad tiene una Ksecreta con el big brother y el big brother tiene una clave
secreta que sólo él conoce.
Queremos cifrar un texto plano P

t → nonce | RA → random
¿El emisor tiene garantía de que se envía la información de forma segura? ¿Se garantizan los 3 objetivos? Sí
CON CLAVE ASIMÉTRICA. DOBLE CIFRADO:
Uno para proporcionar privacidad, con KPUB_B
Otro, previo, para autenticación, con KPRIV_A
Para firmar, enviar KPUB_B (KPRIV_A (T)) →
En el receptor KPUB_A (KPRIV_B (KPUB_B (KPRIV_A (T)))) = T

A y B tienen sus claves públicas y privadas. A va a firmar a B un texto T
¿Cumple los 3 objetivos?

• ¿Autenticado A? Si, por la Kpriv_A. Necesitamos que A esté asociado a su Kpub. (A -----> KPUB_A)
Alguien tiene que garantizarme esto → certificado digital. Se trata de cifrar por una autoridad (policía) la
asociación. → KPRIV_POLICIA (A -----> KPUB_A)
• ¿No repudio de A? Si. Si A niega que lo ha firmado, el destinatario coge lo recibido y lo lleva a la policía.
B descifra KPUB_B y mira KPRIV_A(T) → prueba de que A ha firmado ese texto porque B no lo puede hacer.
• Integridad: Si alguien ha cambiado el texto en el otro lado, voy a la policía y le piden al otro extremo lo
que le ha llegado y mira. KPRIV_A(T) → prueba de que A ha firmado ese texto.
Las tres propiedades se garantizan gracias al certificado digital y al doble cifrado.

Debilidad: para garantizar el no repudio, se necesita garantizar la asociación fehaciente e indisoluble de la
“identidad A” con su “clave pública KPUB_A” (A<----> KPUB_A). Esto se consigue con un certificado digital.
Pero hay una vulnerabilidad: No impide/No tiene mecanismos para el ataque de denuncia falsa de robo de clave.
Es decir, digo que alguien me ha robado la clave. La seguridad llega hasta aquí. Estas denuncias son imposibles
de vencer.
4.7. CERTIFICADOS DIGITALES

Para garantizar que la asociación A--->KPUB_A (identidad ----> clave pública) sea fehaciente, necesitamos una
autoridad que la cifre: El certificado digital.
KPUB_AUT ( KPRIV_AUT ( A,KPUB_A )
CERTIFICADO DIGITAL
Se necesita la intervención de una Autoridad de Certificación (AC):

• El usuario obtiene sus claves pública y privada.
• Éste envía una solicitud, firmada digitalmente, a la AC indicando su identidad y su clave pública.
• AC comprueba la firma y emite el certificado solicitado:
o Identidad de AC, identidad del usuario, clave pública del usuario y otros datos como, por ejemplo,

el período de validez del certificado.
o Todo ello se firma digitalmente con la clave privada de AC con objeto de que el certificado no
pueda falsificarse.
En la administración hay una serie de estándares/formato de certificados. En concreto, la norma x509, reconocida
en la administración española.
AC reconocidas:
• ACE
• CAMERFIRMA
• CERES
• VeriSign
CAMPOS DE UN CERTIFICADO X509

Field Explanation
Version Número de versión de X509
Número de serie Identificador único usado por la AC
Firma Firma de certificado (autoridad)
Editor Nombre del CA definido por X509
Periodo de Periodo de tiempo en el que el certificado es válido.
validez Te víncula a tu clave pública durante un tiempo
Sujeto La entidad cuya clave pública está siendo certificada
Clave pública La llave pública y los algoritmos que usa

4.8. PROTOCOLOS SEGUROS: IMPLEMENTACIÓN DE MECANISMOS
DE SEGURIDAD
¿Cómo se usa todo lo que hemos visto?
En cuanto a seguridad, tenemos 2 tipos:
• Seguridad perimetral: Limitar el tráfico para entrar o salir a través de las premisas fijadas. Se hace con:
o Firewall: una serie de reglas que se activan
o Sistema de detección de intrusiones (IDS) y de respuesta (IRS): Mecanismo que inspecciona el
tráfico y en base a un repertorio de reglas o a un mecanismo de entrenamiento, son capaces de
detectar anomalías o patrones extraños en el tráfico y reaccionar/responder a estos.
• Seguridad en Protocolos (¿Dónde poner la seguridad?):
¿En qué parte de la arquitectura debemos poner la seguridad? En todas las capas.

¿Qué pasa si a nivel de aplicación hago una conexión MUY SEGURA? ¿Tiene sentido poner seguridad en
las capas de abajo? SI ¿Y al revés? TAMBIEN.
La seguridad tiene que estar en las 3 capas. ¿Cómo lo hacemos?:
o CAPA DE APLICACIÓN:
➢ Pretty Good Privacy (PGP): Framework/Estándar/Iniciativa para enviar y recibir correo seguro.
Ahora es opensource.
Cogemos el mensaje original y se hace un hash con MD5. Eso se cifra con la clave privada. El hash
cifrado junto con el texto plano original se comprime. A esto se le cifra con un algoritmo de clave
secreta (IDEA). Envía la clave secreta cifrada con la clave pública del destino al propio destino (Esto
es porque la KPUB/PRIV se usan para cifrar cosas pequeñas <p.e la clave secreta>). Todo esto lo cifra en
base 64.

¿Están garantizados los 3 objetivos?
✓ ¿Autenticado A? Si, por la Kpriv_A. Necesitamos que A esté asociado a su Kpub. (A -----> KPUB_A)
o Alguien tiene que garantizarme esto → certificado digital. Se trata de cifrar por una autoridad
(policía) la asociación. → KPRIV_POLICIA (A -----> KPUB_A)
✓ ¿No repudio de A? Si. Si A niega que lo ha firmado, el destinatario coge lo recibido y lo lleva a la policía.
B descifra KPUB_B y mira KPRIV_A(T) → prueba de que A ha firmado ese texto porque B no lo puede hacer.
✓ Integridad: Si alguien ha cambiado el texto en el otro lado, voy a la policía y le piden al otro extremo lo
que le ha llegado y mira. KPRIV_A(T) → prueba de que A ha firmado ese texto.
➢ Secure Shell (SSH): acceso remoto seguro. Es una mejora de telnet

➢ DNSSEC:DNS tiene una versión segura definiendo los registros con unas claves para firmar.
Es un DNS con RR (RRSIG, DNSKEY) para firmar las respuestas
o CAPA DE TRANSPORTE:
➢ Transport Secure Layer (TSL) (antes SSL) → Versión segura de TCP.

TLS = Handshake (negociar) + Record Protocol (operación).
TLS → Confidencialidad (KSECRETA negociada) + Autenticación (para el server por defecto con
KPÚBLICA) + integridad (con HMAC)
▪ HTTPS (HTPP = TLS), IMAPS, SSL-POP, VPN.
▪ Es un ecosistema de protocolos. Son 4 protocolos:
➔ La aplicación (HTTP) la encapsulo en TLS y a su vez esto se encapsula en

TCP.
El SSL Record Protocol encapsula los protocolos y ofrece un canal seguro con privacidad, autenticación e
integridad.
Antes, en toda sesión que vaya a usar TLS, se usa SSL HandShake protocol,
Vamos a usar un intermediario TLS:
• Para que extremo a extremo hagan una negociación del algoritmo del cifrado (para dar
flexibilidad), de la función hash….
• Autentica al servidor usando su certificado. El cliente
autentifica al servidor enviando todo con el certificado. El
cliente autentica al servidor con X.509
o KPRIV_AUT(Server, KPUB_SERVER)
• El cliente genera claves de sesión:
o Aleatorias cifrada con KPUB_S ERVER (como en PGP)
o Diffie-Hellman
ASSERT PROTOCOL: Informa sobre errores en la sesión

Change Cipher Espec Protocol: Para notificar cambios en el cifrado
SSL RECORD PROTOCOL
Los mensajes de la aplicación se trocean. Cada trozo se comprime. Se genera un hash (HMAC) y el compendio
se combina con el mensaje. Se encripta. Se transmite.
Con SSL se autentica al servidor, no al cliente.
o CAPA DE RED: IPSec (VPN): Su objetivo es garantizar autenticación, integridad y (opcionalmente)

privacidad a nivel IP. Son tres procedimientos:
1. Establecimiento de una asociación de seguridad
• Protocolo IKE (Internet Key Exchange)
• Objetivo: establecimiento de la clave secreta (/de sesión) entre dos entidades IP. Se hace
mediante Diffie-Hellman. Establecer un vínculo entre dos entidades mediante una clave de
sesión.
• Antes se necesita autenticación previa con el certificado digital del cliente y servidor. Esto
es para evitar el ataque de persona en medio (Man in the middle).
• Es simplex: La asociación de seguridad tiene un único sentido. Permite establecer una
clave secreta en una dirección → asociación en un sentido (por ejemplo del cliente al
servidor sólo, o al revés).
• Se identifica con la IP origen + Security Parameter Index (32 bits).
• Vulnera el carácter NO orientado a conexión de IP.
2. Garantizar la autenticación e integridad de los datos:
• Protocolo de “Cabeceras de autenticación”. Es como una versión ligera del IPSec. Parte de
que ya tenemos la clave secreta del 1º.

3. (Opcional) Garantizar la autenticación e integridad y privacidad de los datos:
• Protocolo de “Encapsulado de seguridad de la carga”. Para el punto anterior se puede
utilizar esto. Es una versión más completa y robusta que, además, garantiza la seguridad
(cifra).
En IPSec hay dos modos de operación:

 Modo Transporte: La asociación se hace extremo a extremo entre el host origen y host destino. Garantizar
extremo a extremo la sesión. Todo va cifrado extremo a extremo (del host origen al host destino) → Las
IPs son de los hosts terminales.
 Modo túnel: La asociación se hace entre dos routers intermediarios. La parte segura es la de Internet. Se
crea una nueva cabecera, se mete la cabecera de ese IPSEC para integridad y ¿autenticación?
VPN → Establecer una conexión con IPSec

Tema 5 - Apuntes
S_GRND

Telecomunicación

Tema 5
Servicios y Protocolos de Aplicación en Internet
5.1. INTRODUCCIÓN A LAS APLICACIONES DE RED
Estamos en la primera capa de TCP/IP

CLIENTE-SERVIDOR → Lo usa la mayoría
Servidor
• Siempre en funcionamiento (standlone) → proceso que está escuchando en un
puerto de forma pasiva.
• Los servicios se montan en IP públicas y permanentes.
• Agrupados en granjas (actualmente).
o Cloud computing → Los servicios se montan en granjas que se instancian a
demanda.
Clientes:
• Funcionando de forma intermitente: Los usuarios los crean o los matan
cuando vean.
• Pueden tener IP dinámica y privada
• Se comunican con el servidor pero no entre sí
Otras relaciones: publish/subscribe → últimamente en crecimiento. Son

relaciones más peer-to-peer.
Una entidad manifiesta su interés de suscribirse a una información y la
otra ofrece esta información. Hay un espacio de datos donde hay ciertas
entidades que publican en ese espacio de datos y otras que consumen
información de ese espacio.
Proceso cliente: Proceso que inicia la comunicación

Proceso Servidor: Proceso que espera a ser contactado (IP permanente & pública)
¿Cómo las aplicaciones (del cliente o del servidor) hacen uso de los servicios del sistema operativo? A través de
la interfaz socket. Esta interfaz es básicamente una API → conjunto de métodos/llamadas al sistema que permite
a las apps hacer uso de los servicios de transporte.
El proceso envía/recibe mensajes a/desde su socket. Para recibir mensajes un proceso debe tener un identificador
(IP + puerto).
Por ejemplo: Servidor web Gaia.cs.umass.edu
Dirección IP: 128.110.245.12
Puerto: 80
El precedente del socket: Gestión I/O del SO → Utiliza el paradigma Open/Read/Write/Close
Necesitamos un mecanismo que permita que la aplicación pueda abrir, cerrar, leer, escribir una conexión a un
proceso remoto. Eso hace la API → Incorporando un nuevo elemento: el socket.
El socket es un descriptor de una transmisión a través del cual la aplicación puede enviar y/o recibir información
hacia/o desde otro proceso de aplicación. Es una puerta de acceso (metafóricamente) entre la aplicación y los
servicios de transporte. A partir de este concepto se procede de la misma forma: abro descriptor, escribo y leo, y
cierro el descriptor. Generalizamos el concepto de I/O del SO con el concepto socket. Es como leer/escribir al
proceso remoto.
En la práctica, un SOCKET es una variable

tipo puntero a una estructura. Su contenido es
una posición de memoria y esta posición está

estructurada en una serie de campos que me
describen la transmisión.
• IP Local
• IP Remota Así identifico la transmisión
• Puerto local
• Puerto Remoto
El campo servicio indica si el socket va a usar TCP, UDP, directamente al datagrama, directamente a la capa
subyacente…
Para estimar los retardos (tiempos) en cola de un servidor, se usa la teoría de colas. (no entraremos en esto).
¿Qué es y qué define un protocolo?

Un protocolo de aplicación es aquel que define un conjunto de mensajes, reglas, tipo de servicio…
• Tipo de servicio:
o Orientado o no orientado a conexión
o Realimentado (confirmado) o no.
• Tipo de mensaje: por ejemplo Request (solicitud) o response (respuesta)
• Sintáxis:
o Definición y estructura de “campos en el mensaje”. Es la definición normal de los distintos campos
del mensaje. Hay protocolos orientados a texto (HTTP) frente a no orientados a texto (en binario)
(DNS). Tendencia: usar formato Type-Length-Value
• Semántica: Significado de los campos (para qué sirve cada uno)
• Reglas: Cuándo y para qué las entidades envían o responden mensajes

CLASIFICACIÓN/TIPOS DE PROTOCOLOS
 Dominio público: no tienen derechos de propiedad intelectual (HTTP, DNS, telnet, SMTP, SSH…). Su
especificación no tiene copyright. Se establecen en organismos de estandarización normalmente. Están
definidos en RFCs.
 Propietarios: Protocolos que ciertas entidades (empresas, personas…) especifican para dar solución a
ciertas necesidades (Skype, whatsapp, Netflix…) No están aprobados por ningún organismo.
Antes de la segunda clasificación, tenemos que aclarar que la información que se intercambian se clasifica en:
o Información de control: si hablamos del teléfono, es el número del destino. Si hablamos de HTTP, son las
cabeceras. Es la información necesaria para configurar/usar el servicio.
o Información de datos: si hablamos del teléfono, es la propia voz. Si hablamos de HTTP, es la página web,
el contenido. Son los propios datos.
 In-band: Usan un único canal/conexión para enviar tanto la información de control como de datos. Por
ejemplo, el teléfono (tanto la voz como el número de destino) y HTTP (tanto la cabecera como el
contenido).
 Out-band: Usan una conexión para información de control y otra para datos. Por ejemplo, FTP usa el
puerto 21 para la información de control y el 20 para los datos
♠ Stateless: no implican una vinculación (estado en común entre el cliente y servidor). El servidor ni tiene
que saber la traza del cliente (por donde ha pasado su histórico). En cualquier momento se puede generar
cualquier solicitud/respuesta. El conjunto de solicitudes/respuestas no dependen de un estado. Por

ejemplo: HTTP
♠ State-full: Sí exige un estado. El server va guardando una traza, una historia. El conjunto de respuestas SÍ
depende de un estado → se acuerda de quién eres y hasta que no cambies de estado no responde. Por
ejemplo: el login
Para servicios orientados a conexión (SOC):

♣ Persistentes: Deja abierta la conexión para servir/solicitar más de un objeto. Pueden solicitarse y recibirse
varios. Por ejemplo: HTTP
♣ No persistentes: Cada objeto tiene que abrir una conexión nueva
Tendencia: hacer los protocolos flexibles con:

➢ Una cabecera fija
➢ Una serie de “trozos” (obligatorios y opcionales).
Los trozos pueden incluir una cabecera específica más una serie de datos en forma de parámetros:
▪ Parámetros fijos: en orden
▪ Parámetros de longitud variable u opcionales.
▪ Para los parámetros se usa Formato TLV (Type-Length-Variable).

Características/requisitos de las aplicaciones:
• Tolerancia a pérdidas de datos (errores): Algunas
apps (ej., audio) pueden tolerar algunas pérdida de
datos; otras (ej. FTP, telnet, HTTP) requieren
transferencia 100% fiable (sin errores ni pérdidas).
• Exigencia de requisitos temporales: Algunas apps denominadas inelásticas (ej., telefonía Internet, juegos
interactivos) requieren retardo (latencia) acotado para ser efectivas, otras aplicaciones no.
• Demanda de ancho de banda (tasa de transmisión o throughput ): Algunas apps requieren envío de datos
a una tasa determinada (p. ejemplo un codec de vídeo), otras no
• Nivel de seguridad: Los requisitos de seguridad para las distintas apps son muy variables (Encriptación,
autenticación, no repudio, integridad...)
• Conclusión: las distintas aplicaciones tienen requisitos HETEROGÉNEOS

Servicio TCP:
• Orientado a conexión
• Transporte fiable con control de errores
• Control de flujo
• Control de congestión
Servicio UDP:
• No orientado a conexión
• Transporte no fiable
• Sin control de flujo
• Sin control de congestión
• ¿Para qué existe UDP?
TCP y UDP (capa de transporte) al ser usuarios del protocolo IP (capa de red) no garantizan Calidad de Servicio
(QoS), es decir:
• El retardo NO está acotado
• Las fluctuaciones en el retardo NO están acotadas
• No hay una velocidad de transmisión mínima garantizada
• No hay una probabilidad de pérdidas acotada
Tampoco hay garantías de seguridad.

5.2. SERVICIO DE NOMBRES DE DOMINIO (DNS)
Internet, en la capa de red para realizar el encaminamiento necesita las direcciones IP. Los usuarios prefieren usar
“nombres de dominio” (hay más de 300*106). Domain Name System (DNS) es un servicio que ofrece un servicio
fundamental: básicamente realiza la traducción de nombres de dominio a direcciones IP (resolución de nombres).
www.ugr.es <-------> 150.214.204.25
Esta traducción la hace el DNS. Es un protocolo de cliente-servidor que permite resolver los nombres.
El espacio de nombres de dominio tiene una estructura jerárquica en forma de árbol centrada en el dominio raíz
(root) “.”:
Parte_local.dominio_niveln. … .dominio_nivel2.dominio_nivel1
A los dominios del nivel 1 se les denomina Top Level Domians (TLD) (.com .es .edu etc)
El dominio raíz (“.”) está gestionado centralizadamente por el ICANN (Internet Corporation for Assigned Names
and Numbers; www.ican.org). ICANN delega la gestión de algunos dominios TLD a centros regionales.

Dado un dominio (www.ugr.es → es más comercial/amigable), necesitamos algo que traduzca ese nombre de
dominio en una dirección IP para hacer la comunicación. Se consigue invocando el servicio DNS. Contiene una
base de datos con más de tres millones de registros (IPs). Resolver un nombre es obtener la IP asociada. El árbol
nos da una nueva visión del espacio de nombres del dominio.
Inicialmente fueron definidos los siguientes Top Level Domains:

❖ .com → organizaciones comerciales
❖ .edu → instituciones educativas, como universidades, de EEUU.
❖ .gov → instituciones gubernamentales estadounidenses
❖ .mil → grupos militares de estados unidos
❖ .net → proveedores de Internet
❖ .org → organizaciones diversas diferentes de las anteriores
❖ .arpa → propósitos exclusivos de infraestructura de Internet
❖ .int → organizaciones establecidas por tratados internacionales entre gobiernos
❖ .xy → indicativos de la zona geográfica (ej. es (España); pt (portugal); jp (Japón)...
DNS es un protocolo de aplicación para el acceso a una base de datos distribuida con una gestión distribuida. El
objetivo es resolver los nombres mediante el acceso a una base de datos distribuida. La base de datos está
gestionada por 3 niveles de servidores, asociados al árbol de nombres de dominio:
♠ Servidores raíz “.” (root servers)
♠ Top-Level Domain (TLD servers)
♠ Servidores Locales (Local servers)
Todo equipo (toda entidad en internet/IP) tiene un proceso local llamado “Internet Resolver”. Este gestiona una
caché local. Si en jcp.ugr.es nos preguntamos: ¿IP de www.google.com?
1. Consulta al “resolver” local (caché). Lo primero que hacemos al realizar una resolución es preguntar al
Internet Resolver → si lo tengo localmente, mejor. Me ahorro el proceso siguiente.
2. Lo normal es que no lo tenga. Si no hay respuesta, se le pregunta a su Local Server.
¿Cómo se conoce su IP? Por configuración, toda entidad IP sabe su
DNS.
o Configuración manual
o Configuración automática → DHCP
3. El server local puede:
• Saber la respuesta: si es responsable de ese nombre de dominio o si la sabe por caché (se va anotando
lo aprendido)
• No saber la respuesta: interviene la estructura de directorios para ayudar
a resolver. → El Local Server lo traslada al raíz (servidor asociado al
nombre raíz del árbol de nombres de dominio).
o Si lo sabe, lo devuelve
o Si no lo sabe, hace análisis → translada la
pregunta al TLD (en nuestro caso, es .com así
que se lo pregunta a .com).
4. Puede ocurrir que .com:

• Lo conozca: Lo responde
• No lo conozca: Se lo pasa a .google
Así sucesivamente
Hay dos tipos de resoluciones:

 Resolución recursiva: Los participantes forman una cadena en la que
están involucrados hasta que no devuelve la respuesta.
o X pregunta a A.
o A pregunta a B.
Inconveniente: Implica durante toda la resolución a todos los servidores.
Ventaja: Las cachés se pueden actualizar → la respuesta que le
devuelven se va almacenando.
 Resolución iterativa:
o X pregunta a A.
o A dice: ¡NO! Pregúntale a B.
o X pregunta a B.
Inconveniente: Las cachés no se pueden actualizar
Ventaja: Menos consumo de los servidores
 Resolución mixta: Combinación de los dos anteriores (imagen de la

derecha).
Para mejorar las prestaciones se usan las cachés.

API Socket tiene una función/método que se le pasa como argumento un nombre de dominio y devuelve la IP:
gethostbyname(“domain”). De esta forma se resuelve el nombre desde la interfaz socket.
La función anterior es una llamada al sistema. Le damos el control al Sistema Operativo. El resolver empieza a
mirar en la caché. Si no lo tiene, consulta al local server… y sigue sucesivamente como hemos explicado
anteriormente.
Las consultas y respuestas entre el host local y el DNS las define el protocolo DNS.
Se trata de una relación cliente-servidor con repertorio/sintaxis/semántica de mensajes.
Todo esto tiene un punto débil: cuello de botella en el root. Todas las resoluciones que no conozcan los local
servers pasan por él. Luego veremos la solución de escalabilidad.
CONCEPTOS Y GESTIÓN DE LA BASE DE DATOS

La base de datos es distribuida y jerárquica.
• El sistema DNS está formado por un conjunto de servidores cooperativos, organizados en árbol, que
almacenan parcialmente la base de datos, denominada BIND (Berkeley Internet Name Domain) (grafo de
la imagen)
• Cada servidor es responsable de lo que se denomina una ZONA.
• Una zona es el conjunto (completo) de nombres de dominio completo (por debajo de un nodo en el árbol
de nombres de dominio) de los que un servidor tiene toda la información y es su autoridad. Cada zona
tiene un servidor autoridad, que es el responsable de conocer todo lo que haya debajo de su nodo en el
árbol. → Obligación de conocer todos los registros.
• La autoridad puede delegarse jerárquicamente a otros servidores (hijos). Se libra de la obligación de
conocer parte de nombres de dominio.

→ Ahora .es no es el responsable de conocer los nombres de dominio del nodo ugr. → UGR asume
el papel de autoridad para su zona → .es se olvida de lo de la izquierda de UGR.
Cuando se crea un nombre de dominio, la autoridad tiene la obligación de conocerlo.
La autoridad tiene también la obligación de conocer la base de datos de su zona.
• Delegar autoridad de una zona implica ceder la gestión y responsabilidad de la misma al servidor
correspondiente.
• En cada zona hay servidores:
o primarios (almacenan una copia master de la base de datos en discos locales). Son aquellos que
obtiene la base de datos de disco. Copia master → el primario de UGR carga toda su base de datos
de disco.
o secundarios (obtienen la base de datos por transferencia). Servidores que obtienen la copia de la
base de datos por transferencia. Consulta por DNS toda la BD al primario.
Ambos son autoridad
Volvamos al cuello de botella. Parece que el raíz está en todas las resoluciones del mundo. El raíz tiene delegada
la autoridad a cada Top Level Domain. Cada vez que se crea uno, lo delega. Translada la pregunta al Top Level
Domain solamente. Pero sigue siendo un cuello de botella.
• Además, existe un servicio de cache para mejorar prestaciones.
• Para garantizar escalabilidad existen 13 servidores raíz (Root Servers) (identificados de A a M) múltiples
instancias (réplicas con la misma IP) repartidas por el mundo. El root-server F (y otros) tiene un servidor
en Madrid (Espanix: punto neutro)
• Cuando un cliente (a través de un resolver local ) solicita una resolución de nombres a su servidor, puede
ocurrir:

 Respuesta CON autoridad: el servidor tiene autoridad sobre la zona en la que se encuentra el nombre
solicitado y devuelve la dirección IP.
 Respuesta SIN autoridad: el servidor no tiene autoridad sobre la zona en la que se encuentra el nombre
solicitado, pero lo tiene en la cache.
 No conoce la respuesta: el servidor preguntará a otros servidores de forma recursiva o iterativa.
Normalmente se “eleva” la petición a uno de los servidores raíz. En cada zona hay servidores
¿CÓMO ES LA BASE DE DATOS DNS?

La base de datos se almacena en ficheros de texto (txt) en los primarios y en ficheros denominados zone files.
Contienen todos los registros de la zona. Cada zone file contiene registros denominados Resource Record.
Cada zone file define un TTL (Time to Live): tiempo de validez de los RRs en cache.
Cada RR contiene:
• Nombre del dominio: nombre del dominio al que se refiere el RR.
• Clase: en Internet siempre IN.
• Tipo: Tipo de registro. No solo se le asocia una IP a un nombre de dominio. Se le pueden asociar muchas
otras cosas.
o SOA Registro (Start Of Authority) con la autoridad de la zona.
o NS Registro que contiene un servidor de nombres.
o A Registro que define una dirección IPv4.
o MX Registro que define un servidor de correo electrónico.
o CNAME Registro que define el nombre canónico de un nombre de dominio.
o HINFO Información del tipo de máquina y sistema operativo.
o TXT Información del dominio.
o PTR Registro que contiene un nombre de dominio (para resoluciones inversas)
• Valor: Contenido que depende del campo tipo
o Si tipo = address, en valor tengo una IP
o Si tipo = SOA, digo quién es la autoridad para la zona de ese nombre de dominio.
o Si tipo = MX (mail exchange): nombre de dominio que es el servidor de correo para un
determinado dominio.

Cuando el cliente de correo me quiere enviar un correo, el cliente hace una consulta DNS. El server le responderá
con el MX asociada al dominio. Hay más nombres de dominio (HW, SO, gestión de firmas, claves…)
DUSKEY → Clave pública
RRSIG → Registro de firma. Firma con la clave privada del servidor.
Existe una base de datos asociada de resolución inversa para traducir direcciones IP en nombres de dominio. (in-
addr.arpa). Los registros PTR son aquellos donde se guarda la info al revés. Dada una IP, ¿cuál es su nombre de
dominio? Las direcciones IP se pueden ver también como un árbol.
En los registros PTR se almacena en el campo valor el nombre de dominio asociado a una IP.
Cuando un cliente DNS quiere obtener el nombre de dominio correspondiente a una IP por ejemplo 1.2.3.4, hace
una resolución inversa, preguntando el RR tipo PTR asociado a 4.3.2.1.in-addr.arpa.
DNS es un protocolo cliente-servidor. Los servers siempre están en el puerto 54. Pueden ir encapsulados con
UDP (normalmente) o con TCP (para respuestas grandes > 512 bytes).
El puerto 53 siempre está abierto → Vulnerabilidad → Web cautivas.

Es un protocolo que no es orientado a texto. Los campos de la sintaxis de las resoluciones son:
El campo parámetro tiene:

• 1 bit que dice si es respuesta o
consulta.
• Otro bit con autoridad o no.
• Otro bit con recursión o sin ella
(iterativa).
• Otro de consulta directa o
inversa (pregunto por un
dominio dando una IP).
named: proceso que permite poner el server en marcha

nslookup: herramienta para el diagnóstico.
5.3. LA NAVEGACIÓN WEB (HTTP)

Es un protocolo orientado a texto.
Una página web es un fichero con información formado por objetos: contenido en HTML, imágenes JPEG, GIFs,
Java applets, contenido de audio, vídeo…
Cada objeto se direcciona/identifica por una URL.:
Todos los campos son opcionales excepto el dominio.

El campo ESQUEMA es para las palabras claves (http, ftp, file, news…)
Las webs se sirven con una relación cliente (navegador) – servidor. El protocolo con el que se responden las
solicitudes es HTTP. Es decir, las páginas webs se sirven con el protocolo HTTP (Hyper Text Transfer Protocol)
en el que se adopta el modelo cliente-servidor.
• Cliente: browser que solicita, recibe y muestra objetos webs
• Servidor: envía objetos web en respuesta a peticiones
Las páginas son un conjunto de recursos/objetos. Este contenido puede ser estático o dinámico. Por eso, las
páginas web pueden ser:
• Estáticas: contenido fijo/invariable
• Dinámicas: contenido variable
Las páginas dinámicas pueden proporcionar contenido variable:
 Usando lenguajes de scripting en el cliente: JavaScript, Flash, etc.
 Usando lenguajes de scripting en el servidor: PHP, Perl, Ruby, Python… Se utilizan incrustando etiquetas
dentro de la página web. Cuando el cliente solicita esa página web, el servidor web interpreta estas
etiquetas para realizar acciones en el servidor generando contenido dinámico. Por ejemplo, insertando
información de una base de datos.
CARACTERÍSTICAS DEL PROTOCOLO HTTP
 Usa los servicios de TCP (S.O.C.) en el puerto 80. La lógica del cliente y servidor son muy sencillos.
Todo lo resuelve/soluciona TCP.
o Implica el inicio de una conexión TCP, envío de mensajes HTTP y cierra de la conexión TCP.
 HTTP es stateless → El protocolo no define estados. No hay acoplamiento entre cliente y servidor. para
simplificar la interacción del usuario usa Cookies, las cuales modelan una historia de estados. Así se emula

el statefull.
o El servidor no mantiene información sobre las peticiones de los clientes (su estado) y así ahorra
recursos, aunque hace más compleja la interacción
 HTTP es un protocolo in-band: en la misma conexión va la información de datos y de control.
 Es orientado a texto: se puede leer → ASCI
 Existen dos tipos de servidores HTTP:
o No Persistente (HTTP/v1.0): Se envía únicamente un objeto en cada conexión TCP.
o Persistente (HTTP/v1.1): Pueden enviarse múltiples objetos sobre una única conexión TCP entre
cliente y servidor.
MENSAJES HTTP. EVENTOS

1. El cliente HTTP (navegador) solicita un objeto identificado por su URL, en el ejemplo
www.pradogrado2122.ugr.es/course/view.php. Según la configuración del servidor, si no se especifíca
nada, por defecto se sirve el fichero index.html. El cliente hace un análisis del nombre de dominio. No
puede resolver.
2. El cliente consulta al resolver de DNS por la dirección IP de pradogrado2122.ugr.es
3. DNS contesta con la IP de pradogrado2122
4. El cliente abre una conexión TCP al puerto 80 de esa IP (3 bandas)
5. El cliente envía una petición “GET /pages/universidad/…” (más otra información adicional: cabeceras,
cookies, variables, etc, porque es in-band <todo en la misma conexión>).
6. El servidor responde enviando el fichero “index.html” por la misma conexión TCP. (Full-Duplex → en
ambos sentidos)-
7. Al usar TCP el cliente y servidor de HTTP reciben un servicio orientado a conexión, fiable, sin errores,
con control de flujo, con control de congestión, etc. Es decir, una comunicación TRANSPARENTE y
FIABLE porque por debajo está TCP.
8. Si es persistente se siguen solicitando objetos de la página (“GET…) por la conexión.
9. Se cierra la conexión TCP y se liberan recursos en el servidor y cliente.
10. El cliente visualiza el contenido.

1a. El cliente HTTP inicia la conexión TCP al
servidor HTTP (proceso) en www.ugr.es en el
puerto 80 (segmento SYNC de TCP sin datos)
1b. El servidor HTTP acepta la conexión y
solicita al cliente abrir la conexión (SYNC+ACK)
1c. El cliente confirma (ACK)

2. El cliente HTTP envía Request message
para el objeto
3. El servidor HTTP devuelve la respuesta
4. Si es persistente → Envío de más objetos por la misma con3exión TCP

5. Cierre de conexión TCP (liberación de recursos)
6. Nuevas conexiones TCP
TIPOS DE MENSAJES HTTP Y SINTAXIS

Las solicitudes y las respuestas tienen un formato fijo.
HTTP define dos tipos de mensaje (request, response):

• HTTP Request message (solicitudes del cliente al servidor):
Línea del mensaje: MÉTODO PATH HTTP/VERSION

En la cabecera podemos ver varios campos. El host es dónde se encuentra el objeto. Esto se le pasará al
gethostbyname (al DNS)
Cuerpo del mensaje: para algunos métodos puede tener variables y su valor
• HTTP response message: (respuestas del servidor al cliente):

Línea del mensaje: HTTP/VERSION Codigo Numérico FraseIndicativa/Explicativa

MÉTODOS
Acciones solicitadas por los clientes en los Request messages:
• OPTIONS: Solicitud de información sobre las opciones disponibles. Es una forma de preguntar por parte
del cliente al servidor qué métodos soporta.
• GET: solicitud de un recurso (puede ser condicional). Solicita el recurso pasado como argumento.
• HEAD: igual que GET, pero el servidor no devuelve el cuerpo, solo cabeceras.
• POST: Solicitud al servidor para que acepte y subordine a la URL especificada, los datos incluidos en la
solicitud. Es como el GET pero subordina una serie de variables que van en el cuerpo de la solicitud. En
el cuerpo del mensaje tendrá variable-valor, variable-valor. Así se logra ocultar.
CÓDIGOS DE RESPUESTA
• 1xx indican mensajes exclusivamente informativos
• 2xx indican algún tipo de éxito
• 3xx redirección al cliente a otra URL
• 4xx indican un error
• 5xx indican un error
CABECERAS (47 request headers y 49 respnse headers)
From: , User-Agent: , Content-Type: , Content-Length: , …
Variables predefinidas en las que se puede personalizar/configurar las solicitudes y respuestas.
Las cabeceras más comunes para peticiones y respuestas son:
 Content-Type: descripción MIME de la información contenida en este mensaje. Identifica el

cuerpo/campo de datos de la solicitud/respuesta.
MIME: Extensión o mejora que se le hizo al correo para incluir cabeceras que permitan incluir contenido distinto
al texto.
 Content-Length: longitud en bytes de los datos enviados, expresado en base decimal

 Content-Encoding: formato de codificación de los datos enviados en este mensaje. Sirve, por ejemplo,
para enviar datos comprimidos o encriptados. Cómo se ha codificado el contenido. Por ejemplo, base64
que es útil para enviar binario en forma de carácter.
 Date: fecha local de la operación. Deben incluir la zona horaria en que reside el sistema que genera la
operación. No existe un formato único en las fechas.
Las cabeceras sólo para peticiones del cliente:
♣ Accept: campo opcional que contiene una lista de tipos MIME aceptados por el cliente. El cliente puede
indicar aquí los tipos MIME (formatos) que soporta.
♣ Authorization: clave de acceso que envía un cliente para acceder a un recurso de uso protegido o limitado.
La información incluye el formato de autorización empleado, seguido de la clave de acceso propiamente
dicha. La explicación se incluye más adelante.
♣ From: campo opcional que contiene la dirección de correo electrónico del usuario del cliente Web que
realiza el acceso. Básicamente es para indicar la dirección de correo del cliente.
♣ If-Modified-Since: Permite realizar operaciones GET condicionales, en función de si la fecha de
modificación del objeto requerido es anterior o posterior a la fecha proporcionada. Puede ser utilizada por
los sistemas de almacenamiento temporal de páginas. Es equivalente a realizar un HEAD seguido de un
GET normal. Es para solicitudes condicionales o condicionadas. Nos será útil para la caché.
♣ Referer: Contiene la URL del documento desde donde se ha activado este enlace. De esta forma, un
servidor puede informar al creador de ese documento de cambios o actualizaciones en los enlaces que
contiene. No todos los clientes lo envían. Identificar desde dónde se ha activado la petición (poco uso).
♣ User-Agent: Cadena que identifica el tipo y versión del cliente que realiza la petición. . (cadena que
identifica al cliente). Por ejemplo, los Browsers de Netscape envían cadenas del tipo User-Agent:
Mozilla/3.0 (WinNT; 1)

Las cabeceras para respuestas del servidor HTTP:
♠ Allow: informa de los comandos HTTP opcionales que se pueden aplicar sobre el objeto al que se
refiere esta respuesta. En definitiva, son los comandos que el servidor soporta. Por ejemplo, Allow:
GET, POST…
♠ Expires: Fecha de expiración del objeto enviado. Los sistemas de caché deben descartar las posibles
copias del objeto pasada esta fecha. Por ejemplo, Expires: Thu, 12 Jan 97 00:00:00 GMT+1. No todos
los sistemas lo envían
♠ Last-modified: fecha local de modificación del objeto devuelto. Se puede corresponder con la fecha
de modificación de un fichero en disco, o, para información generada dinámicamente desde una base
de datos, con la fecha de modificación del registro de datos correspondiente.
WEB CACHÉ
Objetivo: reducir el tráfico generado sin implicar servir contenido desactualizado.
El usuario configura el navegador para que todas las solicitudes se
cursen por el proxy/cache
La cache puede residir en el propio ordenador del usuario

EL navegador enviará todos los requerimientos HTTP al cache
Si objeto está en la cache: se retorna el objeto local
Si no, la cache solicita el objeto desde al servidor destino, actualiza
la cache con el objeto, y sirve el objeto al cliente
Podemos intentar reducir el tráfico hacia afuera
Cliente 1 hace una petición. Pasa la solicitud por el proxy. El proxy consulta su caché. En primer lugar, estará
vacía y hace la petición al servidor. Cuando responde el servidor, la respuesta pasará por esa caché.
Ejemplo de una respuesta típica de un servidor configurado para gestionar caches:
La respuesta tiene las cabeceras posibles de la imagen. El campo

ETag permite que podamos gestionar la caché.
Las cabeceras se asocian al fichero en la cache local
El objeto se guarda en la caché con esos atributos. El cliente lo que hace es solicitar el mismo recurso. El get pasa
por el proxy y ve que en su caché tiene ese → con los atributos marcados en rojo. Para mejorar/reducir el tráfico,
realiza una consulta condicional
Cuando llega al servidor pueden ocurrir dos cosas:

• No ha cambiado: Se ahorra el consumo de datos que podría ocasionar. El proxy coge el recurso de la
caché y lo devuelve al cliente.
• Ha cambiado: Hace la solicitud condicional y cuando le devuelven el objeto lo almacena en la caché y lo
devuelve al cliente.
Objetivo: reducir el tráfico si la caché tiene una versión

actualizada del objeto.
La caché solicita el objeto condicionado a la fecha de la copia
local, usando:
If-modified-since:
<date> ó
If-None-Match:
“686897696ª7c876b7e”

El servidor responde sin el objeto si la copia de la caché está
actualizada:
HTTP/1.0 304 Not Modified
En base al E-tag, si no hay un matching…. ¿?
Así evita el uso innecesario de tráfico externo.
La mayoría de los navegadores tienen una caché,
COOKIES
Son pequeños ficheros de texto que se intercambian los clientes y servidores HTTP, para solucionar una de las
principales deficiencias del protocolo: la falta de información de estado entre dos transacciones. Fueron
introducidas por Netscape y ahora han sido estandarizadas. Se utilizan para solucionar/paliar el carácter state-less
del protocolo (sería horrible si fuese stateless realmente). El estado está local en el cliente.
• La primera vez que un usuario accede a un determinado documento de un servidor, éste proporciona una
cookie que contiene datos que relacionarán posteriores operaciones.
• El cliente almacena la cookie en su sistema para usarla después. En los futuros accesos a este servidor, el
navegador podrá proporcionar la cookie original, que servirá de nexo entre este acceso y los anteriores.
• Todo este proceso se realiza automáticamente, sin intervención del usuario.
Una cookie es simplemente una serie de líneas de texto, con pares variables/valor. Existe un conjunto predefinido
de nombres de variable, necesarias para el correcto funcionamiento de las cookies. Las variables predefinidas
son:
➢ Cookies: Conjunto de direcciones Internet para el que es válida la cookie. Ámbito donde se aplica la
cookie (conjunto de direcciones válidas para una cookie). Se puede dar una dirección única
(www.mitienda.es) o un rango (.netscape.com).
➢ Path: Fija el subconjunto de URLs para las que sirve esta cookie.
➢ Version: Permite seleccionar entre diferentes versiones del modelo de cookies.
➢ Expires: Fecha de expiración de la información. Si no se incluye, los datos son descartados al finalizar la
sesión con el cliente Web.

El server puede poner las variables que quiera. Un servidor envía los diferentes campos de una cookie con la
nueva cabecera HTTP Set-Cookie
SetCookie: Domain=www.unica.es; Path=/; Nombre=Luis; Expires Fri, 15-Jul-97 12:00:00 GMT
Cuando se accede a una URL que verifica el par dominio/path registrado, el cliente enviará automáticamente la
información de los diferentes campos de la cookie con la nueva cabecera HTTP Cookie:
Cuando el cliente hace el GET, el server responde con OK y con las cookies (una cabecera con unas variables).

En siguientes interacciones entre el browser y alguna URL que tenemos en las cookies, en la cabecera pondrá
todas esas variables valor.
El servidor no recuerda al cliente. Es el cliente quien almacena localmente la información.
ACCESO RESTRINGIDO
HTTP no es seguro (habría que utilizar TLS para que lo fuese), pero incluye cabeceras (WWW-Authenticate y
Authorization) para restringir el acceso a recursos.
Es vulnerable a ataques por repetición.

WWW-Authenticate: <type> real=<real>[, charset=”UTF-8”]
Authorization: <type> <credentials>
<credentials>: Lo normal es que si <type> es BASIC, incluya el username:password codificado en BASE 64.
5.4. EL CORREO ELECTRÓNICO (SMTP/IMAP/POP3)

➢ Hay dos tipos de componentes/elementos bien diferenciados:
o MUA (Mail User Agent): Agente de usuario / Cliente de correo.
o MTA((Mail Server o Mail Transfer Agent): Servidor de correo.
o Protocolo de envío:
▪ Simple Mail Transfer Protocol (SMTP)
o Protocolos de descarga (o lectura):
▪ POP3, IMAP, HTTP
➢ Agente de usuario (MUA):
o Server que se ejecuta en la infraestructura del usuario. Se
ejecuta a demanda del usuario.
o Compone, crea, edita, administra y lee mensajes de correo
del buzón. Es la interfaz con el sistema Ej. Outlook,
Thunderbird, etc. El navegador también, pero no se
recomienda porque la funcionalidad no es tan buena.
➢ Servidor de correo (MTA)
o Reenvía mensajes salientes y almacena en buzones los
mensajes entrantes de cada usuario. Permite desacoplar

temporalmente a remitente y destinatario.
La arquitectura es así para desacoplar los clientes temporalmente.
POP3/IMAP: Se descargará la información con uno de esos protocolos → para la lectura (interactuar con mi
buzón).
Se trata de desacoplar temporalmente al remitente del destinatario. Es decir, que no tengan que estar
simultáneamente disponibles.
SMTP
Es un protocolo para el envío.
➢ Desde MUA hasta MTA
➢ Desde MTA hasta MTA.
“sendmail” es un popular agente de transporte de correo (MTA) en Internet, cuya tarea es encaminar los mensajes
o correos de forma que estos lleguen a su destino. Soporta muchos tipos de métodos de entrega, incluyendo SMTP.

Características de SMTP:
➢ Se implementa en cliente y en servidor mediante dos programas (incluidos ambos en cada mail server):
o Cliente SMTP: se ejecuta en el mail server (MTA) que está enviando correo
o Servidor SMTP: se ejecuta en el mail server (MTA) que está recibiendo correo.
➢ Usa TCP, por tanto, es fiable. El server siempre está en el puerto 25.
➢ Es un protocolo orientado a texto.
➢ SMTP es un protocolo orientado a conexión.
➢ Es In-Band (todo va por la misma conexión. Por la misma conexión vamos a leer y escribir todos los datos
del correo y también toda la información de control
➢ Es state-full: Los servidores si se acuerdan del cliente. Define estados. Depende de un estado.
➢ Implica 3 fases:
o Handshaking (“saludo”)
o Transferencia de mensajes
o Cierre
➢ La interacción entre el cliente y el servidor SMTP se realiza mediante comandos/respuesta:
o Solicitudes/comandos: texto ASCII

o Respuestas: código de estado (numérico) y frase explicativa
Inicialmente los mensajes estaban codificados en ASCII de 7 bits. Con la definición posterior de las extensiones
MIME se puede enviar ASCII de 8 bits y formatos enriquecidos.
PASOS EN EL ENVÍO/RECEPCIÓN DE CORREO

1) El usuario origen compone mediante su Agente de Usuario (MUA) un mensaje dirigido a la dirección de correo
del usuario destino. Es decir, compone el mensaje del correo en la MUA y rellena campos de la cabecera (destino
asunto…)
2) Se envía con SMTP (ó HTTP) el mensaje al servidor de correo (MTA) del usuario origen que lo sitúa en la
cola de mensajes salientes.
MUA abre una conexión TCP al puerto 25 y comienza el diálogo con SMTP. La MUA sabe la IP de su MTA por
configuración manual (Se lo pongo a mano cuando configuro la MUA: “Oye, tu server es X”). El correo se
almacena en el spool (cola de salida) del MTA. Entonces el MTA se convierte en cliente. ¿Cómo sabe cuál es el
server destino? Con una consulta DNS → ¿Qué hay a la derecha del @? Por ejemplo: pepe@ugr.es → ugr.es.
Consulta del DNS: RR (type=MX). Tras la consulta, se obtiene el nombre de dominio del servidor.
3) El cliente SMTP abre una conexión TCP con el servidor de correo (MTA) (obtenido por DNS) del usuario
destino.
4) El cliente SMTP envía el mensaje sobre la conexión TCP
5) El servidor de correo del usuario destino ubica el mensaje en el mailbox del usuario destino
6) El usuario destino invoca su Agente de Usuario (MUA) para leer el mensaje utilizando POP3, IMAP ó HTTP
En cuanto a la sintáxis de SMTP, es tipo texto.
Los mensajes del cliente al servidor se pueden emular lanzando un telnet
al servidor con puerto 25
Statefull: el protocolo exige una serie de estados y hasta que no los defines no te deja enviar ciertos mensajes
como DATA.
S: 220 smtp1.ugr.es
C: HELO ugr.es
S: 250 smtp1.ugr.es
C: MAIL FROM: uno@ugr.es
S: 250 Ok
C: RCPT TO: dos@ugr.es
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: Correo estúpido
C: Tengo ganas de enviarte un correo...
C: ¿Te importa si lo hago?
C: .
S: 250 Ok: queued as KJSADHFFWDF
C: QUIT

S: 221 By
Comandos obligatorios para salir del handshake:
➢ MAIL FROM: uno@ugr.es → No hay comprobación. Solo debe tener una @ → es la única verificación.
Esto hace que pueda enviar un correo como psanchez@lamoncloa.es.
➢ Enviar a quién va con RCPT TO dos@ugr.es → Si estoy en una MTA este nombre de dominio (ugr.es)
me va a determinar si soy el intermediario o el destinatario.
o Si coincide con el que administro, almaceno en buzón.
o Si no, lo pongo en el spool
Cuando terminamos de redactar, se indica con una línea con un punto.
COMANDOS SMTP: CLIENTE → Palabras claves/comandos que el cliente puede enviar

CÓDIGOS DE RESPUESTA SMTP: SERVIDOR → Códigos numéricos provistos.
De la siguiente tabla, debemos sabernos qué hace cada centena de códigos (los 400 y 500 para errores. Los 200
para respuestas válidas <creo>)
EXTENSIONES MIME
¿Cómo usamos SMTP para enviar texto enriquecido? Con las cabeceras MIME. Nada cambia respecto a la
arquitectura de correo anterior.
Son una mejora para sportar, no solo ASCI de 7 bits, sino el envío de binario, audio, vídeo, etc por correo.
Las extensiones de MIME van encaminadas a 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
MIME está especificado en seis RFCs.
¿Cómo se almacena un correo en el spool/buzón? En ASCII. No confundir los mensajes del protocolo con el
formato de almacenamiento de los mensajes.
Las líneas de cabecera me indica de quien y a quién va la información, el asunto del correo, etc… Los saca por
protocolo (los mensajes que hemos visto anteriormente entre S y C).
Por ejemplo, un fichero en JPEG lo haría como en la imagen. Content-Transfer-Encoding: base 64 para enviar
el jpeg en binario.

CABECERAS DE MENSAJES MIME
CONTENT-TYPE: TIPOS Y SUBTIPOS
La lista inicial de tipos y subtipos es:

CONTENT-TYPE: TIPO APPLICATION
Application es un tipo general para los formatos que requieren procesamiento externo no cubierto por ninguno
de los otros tipos.
• Octet-stream: es una secuencia de bytes no interpretados, tal que a su recepción, un agente de usuario
debería presentarla en la pantalla sugiriendo al usuario que se copie en un archivo y solicitando un nombre
de archivo.
• Postscript: lenguaje PostScript de Adobe System. Aunque un agente de usuario puede llamar a un
intérprete PostScript externo para visualizarlo, hacerlo no estará exento de riesgos al ser PostScript un
lenguaje de programación completo.
CONTENT-TYPE: TIPO MESSAGE

Message permite que un mensaje esté encapsulado por completo dentro de otro. Este esquema es útil para reenviar
correo electrónico.
• RFC822: se utiliza cuando se encapsula un mensaje RFC822 completo en un mensaje exterior
• Partial: hace posible dividir un mensaje encapsulado en pedazos y enviarlos por separado. Los parámetros
hacen posible ensamblar correctamente todas las partes en el destino. Por ejemplo 1/3, 2/3, 3/3
• External-body: puede usarse para mensajes muy grandes, como películas de vídeo. En lugar de incluir el
archivo mpeg en el mensaje, se da una dirección de FTP y el agente de usuario del receptor puede
obtenerlo a través de la red cuando se requiera.

CONTENT-TYPE: MULTIPART
Multipart es para enviar distintas partes en un fichero. Permite que un mensaje contenga más de una parte, con el
comienzo y el fin de cada parte claramente delimitados.
• Mixed consiste en enviar distintos objetos separados por una cadena de texto. Permite que cada parte sea
diferente.
• Alternative: cada parte contiene el mismo mensaje, pero expresado en un medio o codificación diferente.
• Parallel: se usa cuando todas las partes deben “verse” simultáneamente. Por ejemplo, en los canales de
audio y video de las películas
• Digest: se usa cuando se juntan muchos mensajes en un mensaje compuesto
Ejemplo Multipart/Mixed
PROTOCOLOS DE ACCESO: POP3

➢ Se utiliza cuando el destinatario descarga.
➢ Abre una conexión TCP en el puerto 110. El servidor está esperando por ahí a peticiones de MUA.
➢ Es orientado a texto.
➢ Es full-state
➢ Tiene tres fases:
o Fase de autorización: obligada. Hasta que no lo haga el servidor no va a hacer caso. El protocolo
no va a permitir enviar comandos determinados. Esto se debe a que es statefull.
▪ Comandos del cliente:
• User: nombre de usuario
• Pass: contraseña
▪ Respuestas del servidor
• +OK
• -ERR
o Fase de transacción
▪ Comandos del cliente
• List: lista mensajes por número. Tantas líneas como tengamos.
• Retr: obtiene mensajes por número
• Dele: borra
• Quit
o Fase de actualización del servidor (tras desconexión)
Es un protocolo muy básico. Se utiliza relativamente poco.
COMANDOS:

POP 3 no permite gestionar directorios en el buzón. POP3 no asocia un estado a los correos (contestado, leído,
sin abrir…)
GMAIL usa ---------------------------------------------------------------------→
PROTOCOLO DE ACCESO IMAP

Ventajas de IMAP4:
➢ Permite organización en carpetas en el lado del servidor (MTA). Es decir, permite una estructura de
directorios.
➢ Para ello, mantiene información entre sesiones (asociando flags a los mensajes). Las flages permiten
gestionar el estado de los correos.
➢ POP cuando cierra la sesión borra todo lo descargado o leído para liberar recursos. IMAP no, permite
acceder desde varios clientes al buzón porque se guardan en el servidor. (POP también lo permite pero en
modo descargar y guardar)
➢ Permite la descarga de parte de los mensajes
IMAP4 también es orientado a texto.
Ventajas de WebMAIL:
▪ Organización total en el servidor y accesible desde cualquier cliente con HTTP
▪ Seguridad: uso extendido de HTTPS.
*ejemplos en transparencias*´

LISTADO DE PUERTOS RELACIONADOS CON E-MAIL Y SUS VERSIONES SEGURAS
 POP3 - port 110
 IMAP - port 143
 SMTP - port 25
 HTTP - port 80
 Secure SMTP (SSMTP) - port 465
 Secure IMAP (IMAP4-SSL) - port 585
 IMAP4 over SSL (IMAPS) - port 993
 Secure POP3 (SSL-POP) - port 995
5.5. APLICACIONES MULTIMEDIA

IP se diseñó para enviar correo, telnet, web… Jamás se pensó para enviar contenido con estrictos requisitos de
calidad de servicio (ancho de banda, velocidad de transmisión, retardo, etc). Estos requisitos los exigen algunas
aplicaciones.
IP es una tecnología de convergencia. Se está convirtiendo en una tecnología que sirve para enviar cualquier tipo
de tráfico, incluso el contenido con requisitos estrictos. Muchos servicios están migrando a IP (teléfono, por
ejemplo, que tiene requisitos para los
que IP no estuvo diseñado)

Aplicaciones multimedia: audio, video, juegos, real-time….
Calidad de servicio. (QoS): capacidad de ofrecer el rendimiento requerido para una aplicación.
IP ofrece mejor esfuerzo (best effort): sin garantías de QoS
IP ha mejorado para garantizar extremo a extremo los requisitos que exigen las aplicaciones.
Tipos de aplicaciones:
• Flujo de audio y vídeo (streaming) almacenado → por ejemplo, Youtube
• Flujo de audio y vídeo en vivo → por ejemplo, emisoras de radio o IPTV
• Audio y vídeo interactivo → por ejemplo, Skype
Características fundamentales:
• Elevado ancho de banda
• Tolerantes relativamente a la pérdida de datos
• Exigen Delay (retardo) acotado.
• Exigen Jitter (fluctuación de retardo) acotado
• Se pueden beneficiar de usar direcciones multicast (direcciones destino de grupo).
Se le ha añadido a IP calidad de servicio. ¿Cómo? Añadiendo componentes a los routers.

Por ejemplo, un clasificador. Al tráfico de voz, por ejemplo, le da un trato distinto que a otro.


FR Apuntes

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

FR Apuntes

Cargado por

Copyright:

Formatos disponibles

Tema-1-FR.

3º Grado en Ingeniería Informática

Escuela Técnica Superior de Ingenierías Informática y de

Reservados todos los derechos.

Reservados todos los derechos.

Razones (motivación) para usar redes

ESTRUCTURA Y ELEMENTOS DE UNA RED

Reservados todos los derechos.

1.2. DISEÑO Y ESTANDARIZACIÓN DE REDES

• ¿Cómo enviar físicamente la información?

si lees esto me debes un besito

Reservados todos los derechos.

Los paquetes de entrada se van escalando en el router. Se almacenan y se reenvían.

Conceptos de diseño en redes:

si lees esto me debes un besito

Principios de diseño para el modelo de referencia

Pero en Internet triunfa lo simple. Por ello:

Reservados todos los derechos.

si lees esto me debes un besito

MODELO TCP/IP -> Evolución del modelo OSI

Reservados todos los derechos.

1.3. TERMINOLOGÍA, CONCEPTOS Y SERVICIOS

Reservados todos los derechos.

si lees esto me debes un besito

• Encolado: Tiempo de espera a poder salir/transmitir.

Reservados todos los derechos.

En resumen, tenemos todos estos tiempos de retardo:

si lees esto me debes un besito

o Confirmados (fiables): Exigen del otro extremo/entidad una retroalimentación de

La capa de transporte tiene dos protocolos

Reservados todos los derechos.

1.4. INTERNET: TOPOLOGÍA Y DIRECCIONAMIENTO

TOPOLOGÍA: Se pueden identificar a grandes rasgos 3 niveles:

¿Cómo puedo hacer uso de las redes al pagar a un operador?

si lees esto me debes un besito

Reservados todos los derechos.

Reservados todos los derechos.

si lees esto me debes un besito

3º Grado en Ingeniería Informática

Escuela Técnica Superior de Ingenierías Informática y de

Reservados todos los derechos.

Reservados todos los derechos.

Ejemplos de protocolos de red:

Reservados todos los derechos.

o Envió en unidades de datos (paquetes) independientes: Los

si lees esto me debes un besito

Reservados todos los derechos.

• Es un protocolo salto a salto. Involucra a hosts y routers.

(datos = segmento para la capa de transporte)

si lees esto me debes un besito

Las direcciones IP tienen dos partes bien diferenciadas.

Reservados todos los derechos.

Hay IPs que son privadas y otras que son públicas.

si lees esto me debes un besito

Reservados todos los derechos.

Reservados todos los derechos.

Dirección IP → 200.27.4.112 = 11001000.00011011.00000100.01110000

si lees esto me debes un besito

Hay direcciones privadas reservadas:

Reservados todos los derechos.

DIRECCIONES IPV4: CLASES

si lees esto me debes un besito

Reserva de direcciones privadas (creo que no es importante)

Reservados todos los derechos.