Curso de
Redes Computadores 1
Tema 4
Protocolos a Nivel de Capa de
Aplicación
Objetivos de la clase
Objetivo General
● Mostrar las características generales de protocolos de la capa de aplicación
Objetivos específicos
● Dar nociones informales de aspectos que se deben considerar al diseñar un protocolo, en particular protocolos de capa de aplicación
● Describir algunos de los protocolos más usados de la capa de aplicación (HTTP y SMTP)
Agenda
● Conceptos básicos de protocolos
● Paradigmas y servicios asociados a los protocolos en capa de aplicación
● Ejemplo de un protocolos en la capa de aplicación
● HTTP (Web)
● eMail – SMTP POP IMAP RFC822
Conceptos básicos de protocolos
Protocolos
● Problema: Conseguir que todos los usuarios hablen el mismo lenguaje.
● Protocolo:
● Es el conjunto de normas y reglas, organizadas, sin ambigüedad y convenidas de mutuo acuerdo entre todos los participantes en una comunicación.
● Su misión es:
● hacer que la comunicación entre computadoras de una red sea posible.
Elementos Claves de un Protocolo
Para que dos entidades se comuniquen con éxito, se requiere que hablen el mismo idioma. Para ello las entidades deben seguir una serie de convenciones mutuamente aceptadas a fin de saber:
● Qué se comunica Semántica incluye aspectos de:
● Información de control para la coordinación
● Datos
● Manejo de errores
● Cómo se comunica Sintaxis incluye aspectos de:
● Formato de los datos
● Niveles de señal
● Cuándo se comunica Timing (Temporización)
● Sincronización de velocidades
● Secuenciación
Elementos de Estandarización
Especificación del protocolo
● Dos entidades en la misma capa en sistemas diferentes cooperan e interactúan por medio del protocolo
● Las especificaciones del
protocolo deben ser precisas
● Formato de la unidad de datos
● Semántica de todos los campos
● Secuencia permitida de PDUs
Elementos de Estandarización
Definición del servicio
● Se necesita normalizaciones para los servicios que cada capa ofrece a la capa
superior contigua
● Descripción funcional de qué servicios está
proporcionando
● No especifica cómo se
proporcionan los servicios
Elementos de Estandarización
Direccionamiento: cada capa suministra a las entidades en la capa superior contigua.
● Las entidades se
identifican mediante SAP
● Un NSAP(NetworkSAP) indica una entidad de transporte que es
usuaria del servicio de
red
Bases del Modelo de capas
● Cada capa del modelo tiene sus funciones
● Se definen protocolos para cada capa de
manera que la capa C de una maquina pueda
comunicarse con la capa C de otra maquina
Capas
Aplicación HTTP, SMTP, FTP, DNS Transporte TCP, UDP, RTP, SCTP
Internet Para redes TCP/IP es el IP
Enlace Ethernet, Token Ring, PPP, HDLC, Frame Relay, RDSI, ATM, IEEE 802.11, FDDI
Físico medio físico, y técnicas de codificación
Aspectos a considerar en un Protocolo a nivel de Aplicación
● Identificar los actores participantes en la comunicación.
● Quién tiene y quién requiere la información del sistema.
● Identificar cuál es el rol de cada uno de los actores participantes ( cliente, servidor,
cliente/servidor, pares o peer-to-peer).
● Como se van a identificar o diferenciar, unos de otros, estos actores en el sistema
(direccionamiento)
Aspectos a considerar en un Protocolo a nivel de Aplicación
Cuales son las necesidades de información de la aplicación.
● Cómo es el esquema de comunicación que debe ocurrir entre los actores:
● Quien habla primero, quien escucha, quien habla luego, etc.
● Hay sólo una pregunta y una respuesta, la interacción incluye una secuencia de requerimientos y respuestas encadenados, se pide una confirmación de cada mensaje o una confirmación
global.
● Cuál o cuáles son las secuencias correctas de comunicación
● Qué hacer cuando se rompe una secuencia correcta de comunicación.
● Qué debe ocurrir en el caso que se interrumpa una comunicación.
● Qué debe ocurrir en el caso que una comunicación no pueda establecerse.
¿Qué otros aspectos se deben considerar?
● La información que se requiera comunicar
● Tipo
● Tamaño
● Cardinalidad
● Así como las condiciones que deben cumplir
● Formato, rango de valores
Protocolo de aplicación
Protocolos de Aplicación comunes son:
● HTTP: es el Protocolo de Transferencia de Hipertexto (en inglés HyperText Transfer Protocol).
● FTP: es el Protocolo de Transferencia de Archivos(en inglés File Transfer Protocol).
● SMTP: es el Protocolo de Transferencia de Correo(en inglés Simple Mail Transfer Protocol).
● NNTP: es el Protocolo de Transferencia de Red de Noticias(en inglés Network News Transfer Protocol).
● IRC: es el Chat Basado en Internet(en inglés Internet Relay Chat).
Protocolos de Aplicación
● Facilitan la comunicación entre una aplicación y un servidor.
● Contemplan las siguientes actividades:
● Abrir y cerrar conexiones.
● Hacer y satisfacer peticiones de servicio.
● Manejar e informar de errores.
● Tienden a ser orientados a bytes
● Tamaño de los campos puede ser fijo o
variable.
Paradigmas y servicios asociados a los protocolos en la capa de
aplicación
Paradigma Cliente-Servidor
Las aplicaciones de red típicas tienen dos partes:
Cliente:
● Inicia el contacto con el servidor (“habla primero”)
● Normalmente solicita servicios desde el servidor,
● Web: el cliente está implementado en el browser; e-mail: en el lector de correo
aplicación transporte enlacered
física
aplicación transporte enlacered
física
solicitud
respuesta
Servidor:
● Proporciona el servicio solicitado por el cliente
● ejemplo, el servidor Web envía la página web solicitada, el servidor de correo
entrega el mensaje de correo
Direccionamiento de procesos:
● Para que un proceso reciba mensajes, este debe tener un identificador
● Cualquier nodo en Internet tiene una dirección IP única (32 bits en IPv4, 128 bits en IPv6)
● Pregunta: ¿es suficiente con la dirección IP para
identificar los procesos?
● Respuesta: No. Muchos
procesos pueden ejecutarse en el mismo host
● El identificador de un proceso en Internet incluye tanto la
dirección IP como el número de puerto
asociado con el proceso dentro del host.
● Ejemplos de números de puerto “bien
conocidos”:
● Servidor HTTP: 80
● Servidor de correo: 25
¿Qué servicios de transporte requiere una aplicación?
● Pérdida de
datos
● Algunas aplicaciones (por ejemplo, audio) pueden
tolerar alguna pérdida otras aplicaciones (ftp, telnet) requieren una confiabilidad del 100% al transferir
datos
Control preciso de tiempo
● Algunas aplicaciones
(telefonía Internet, juegos interactivos) requieren
poco retardo para que sean “efectivas”
Ancho de Banda
● Algunas aplicaciones (multimedia) requieren un mínimo en la
cantidad de ancho de banda para ser
“efectivas”
● otras aplicaciones
(“aplicaciones elásticas”) utilizan el ancho de
banda que encuentren
Requerimientos de servicios de transporte de aplicaciones comunes
Aplicación Transferencia de archivos Correo Documentos web audio/video en tiempo real audio/video almacenado Juegos interactivos Mensajería instantánea
Pérdida de Datos No
No No
Tolerante Tolerante Tolerante No
Ancho de Banda elástico
elástico elástico
audio: 5kbps-1Mbps video:10kbps-5Mbps El mismo anterior Algunos kbps
elástico
Sensitiva al tiempo
no no no
sí, 100’s ms sí, pocos s sí, 100’s ms sí y no
Servicios de los protocolos de transporte de Internet
Servicio de TCP:
● Orientado a conexión: se debe establecer una conexión entre los procesos cliente y servidor
● Transporte confiable entre el proceso emisor y el proceso receptor
● Control de flujo: el emisor no debe “saturar” al receptor
● Control de congestión: el emisor debe moderarse cuando la red esté “sobrecargada”
● No ofrece: ni control de
tiempos, ni garantiza un mínimo ancho de banda
Servicio de UDP:
● Transferencia de datos no confiable entre el proceso emisor y el receptor
● NO ofrece:
establecimiento de conexión,
confiabilidad, control de flujo, control de
congestión, control de tiempo, o garantía de ancho de banda
mínimo
HTTP
Protocolo HTTP
● Es el protocolo de red que se utiliza para transferir los archivos (llamados recursos) que forman parte de la World Wide Web. Ya sean estos archivos HTML,
imágenes, sonidos, etc...
● Propuesto por Tim Berners-Lee en 1989
● HTTP es el protocolo utilizado para intercambio de información entre clientes Web (ej. Mozilla Firefox) y servidores HTTP (ej. Apache)
● Conexión TCP puerto 80 que escucha pasivamente.
● Actualmente versión HTTP/1.1
● HTTP/1.0 ver RFC 1945 y HTTP/1.1 ver RFC 2616
● Más información: http://www.w3.org/protocols
HTTP - HyperText Transfer Protocol
● Normalmente HTTP utiliza a TCP como medio de transporte.
● HTTP se utiliza para transferir Recursos, no solo archivos.
● Un recurso es un trozo de información que puede identificarse a través de un URL.
● La clase más común de recursos son los
archivos, pero también pueden ser datos
generados dinámicamente.
Web y HTTP
Algunos términos
● Una página Web consta de objetos
● Los objetos pueden ser un archivo HTML, una imagen JPEG, un applet Java, un archivo de audio,…
● Una página Web consta de un archivo HTML base que incluye diversos objetos referenciados
● Cada objeto se direcciona con un URL
● Ejemplo de un URL:
www.algunsitio.edu:80/algunaFacultad/pic.gif Nombre del host Nombre del path
http://
Protocolo
Panorámica de HTTP
HTTP: Protocolo de Transferencia de HiperTexto
● Es el protocolo de la capa de aplicación para el Web
● Usa el modelo cliente/servidor
● Cliente: browser o
navegador que solicita, recibe y muestra los objetos Web
● Servidor: Servidor www que envía objetos en respuesta a las
solicitudes del browser
● HTTP 1.0: RFC 1945
● HTTP 1.1: RFC 2068
PC ejecutando IE Explorer
Servidor ejecutando El servidor Web
Apache Mac ejecutando
Netscape Navigator
Panorámica de HTTP (continuación)
Utiliza TCP:
• El cliente inicia la conexión TCP (crea el socket) al
servidor, puerto 80
• El servidor acepta la conexión TCP solicitada por cliente
• Los mensajes HTTP
(mensajes del protocolo de la capa de aplicación) se intercambian entre el
browser (cliente HTTP) y el servidor Web (servidor HTTP)
• Se cierra la conexión TCP
HTTP es “stateless”
• El servidor no
mantiene información sobre las solicitudes anteriores del cliente
¡Los protocolos que mantienen información de estado son complejos!
• La historia pasada (estado) debe guardarse
• Si el servidor o el cliente fallan, sus “imágenes” del estado de la sesión pueden ser
inconsistentes y deben
“reconciliarse”
NOTA
Funcionamiento de HTTP
Funcionamiento
1. El cliente realiza una petición o apertura activa (request) al servidor (puerto 80, por defecto)
2. Solicita la transacción ( request ) con HTTP: GET, POST, HEAD, PUT, …
3. El servidor envía la respuesta ( response ) en HTML
4. Se cierra la conexión (en HTTP/1.0)
Ejemplo de transacción HTTP
• El navegador solicita recurso
• Se determina el URL
• Se resuelve la IP (DNS)
• Se establece conexión TCP con puerto 80 de la IP destino
• Se transmite el método GET
<URI> <protocolo>
(/archivo.html HTTP/1.1)
• El servidor responde (según extensiones MIME y RFCs)
• Se cierra la conexión (HTTP 1.0)
• Se presenta el recurso en el
“navegador” Uniform Resource Identifier (URI) es una cadena de caracteres usada para identificar o nombrar un recurso en la Internet.
Mensajes HTTP
• Dos tipos de mensajes usando ASCII (texto plano):
• Request (Solicitud)
• Response (Respuesta)
• Solicitudes HTTP/1.0
Mensajes HTTP
Respuestas HTTP/1.0
Mensajes HTTP
Ejemplo real de mensajes HTTP
Mensajes HTTP
● Códigos de estado:
● Identificador del estado de la petición.
● Los envía el servidor web como respuesta.
● Entero de 3 dígitos:
1xx: Informativos.
2xx: Operación realizada con éxito.
3xx: Redireccionan al cliente a otra URL.
4xx: Error del cliente.
5xx: Error del servidor.
● Los más usuales:
● 200 OK: solicitud exitosa, la respuesta va en el cuerpo.
● 404 Not Found: el recursos no existe.
● 303 See Other: el recurso se ha movido a otra URL (ver Header Location).
● 500 Server Error: error interno del servidor.
Mensajes HTTP
• Métodos:
• Operaciones que se pueden solicitar a un servidor.
• Existen 3 métodos distintos:
• GET: Se utiliza para recoger cualquier tipo de información del servidor. Esta información va en el cuerpo de la
respuesta.
• HEAD: Solicita información sobre un objeto (fichero). Es igual que GET, pero la información va contenida en la cabecera de la respuesta. NUNCA TIENEN CUERPO.
• POST: Se utiliza para enviar información al servidor, por ejemplo los datos contenidos en un formulario.
HTTP / 1.1
• El protocolo HTTP/1.1 es ligeramente diferente a su precedente:
• Conexiones persistentes vs no-persistentes.
• Posibilidad de cerrar la conexión cuando se desee.
• Nuevos métodos como PUT, DELETE, OPTIONS.
• Nuevas cabeceras.
Conexiones HTTP
HTTP no persistente
• Al menos un objeto es enviado sobre una
conexión TCP.
• HTTP/1.0 utiliza HTTP no persistente
HTTP persistente
• Multiples objetos pueden ser enviados sobre una misma conexión TCP entre el cliente y el servidor.
• HTTP/1.1, por omisión, utiliza conexiones
persistentes
HTTP No persistente
Supongamos que el usuario ingresa el URL
www.algunsitio.edu/algunaFacultad/index.html 1a. El cliente HTTP inicia la conexión
TCPal servidor HTTP (el proceso) en www.algunsitio.edu en el puerto 80
2. El cliente HTTP envía un
request message (que contiene el URL) hacia su socket de
conexión TCP. El mensaje indica que el cliente desea el objeto algunaFacultad/index.html
1b. El servidor HTTP en el host www.algunsitio.edu espera conexiones TCP en el puerto 80. Cuando “acepta” una conexión, notifica al cliente
3. El servidor HTTP recibe el
mensaje de solicitud, construye un response message que
contiene el objeto solicitado, y envía el mensaje hacia su
socket
tiempo
(contiene texto, referencia a 10 imágenes jpeg)
HTTP No persistente (cont.)
5. El cliente HTTP recibe el mensaje de repuesta que contiene el
archivo html, muestra el html. Al recorrer el archivo html encuentra 10 objetos jpeg referenciados
6. Los pasos 1 a 5 se repiten para cada uno de los 10 objetos jpeg
4. El servidor HTTP cierra la conexión TCP.
tiempo
Modelamiento del tiempo de respuesta
Definición de RRT: tiempo para enviar un pequeño paquete y que este viaje desde el cliente hasta el servidor y que regrese.
Tiempo de respuesta:
• Un RTT para iniciar la conexión TCP
• Un RTT para la solicitud HTTP y para que los primeros bytes de la respuesta HTTP regresen
• Tiempo de transmisión del archivo
tiempo para transmitir archivo Inicia Conexión
TCP RTT solicita archivo
RTT
archivo recibido
tiempo tiempo
total = 2RTT+tiempo de transmisión
HTTP Persistente
Aspectos de HTTP No persistente:
• requiere 2 RTTs por objeto
• El OS debe trabajar y asignar los recursos del host para cada conexión TCP
• En ocasiones un browser abre
conexiones TCP paralelas para traer los objetos referenciados
• HTTP persistente
• El servidor deja la conexión abierta después de enviar el mensaje de respuesta
• Los mensajes HTTP que siguen entre el cliente/servidor son enviados sobre la misma conexión TCP
Persistencia sin pipelining:
• El cliente emite una nueva solictud sólo cuando la respuesta anterior ha sido recibida
• Se requiere un RTT para cada objeto referenciado
Persistencia con pipelining:
• Por omisión en HTTP/1.1
• El cliente envía una solicitud tan pronto como encuentra un objeto referenciado
• Se requiere apenas como un RTT para TODOS los objetos referenciados
Mensaje de solicitud HTTP
• HTTP tiene dos tipos de mensajes: request, response
• Mensaje de solicitud:
• ASCII (formato legible para nosotros)
GET /algundir/pagina.html HTTP/1.1 Host: www.algunsitio.edu
User-agent: Mozilla/4.0 Connection: close
Accept-language:fr
(“carriage return, line feed” adicional) Línea de solicitud
(comandos GET, POST, HEAD)
Líneas de encabezado
“Carriage return, line feed”
Indica el final del mensaje
Mensaje de solicitud HTTP: formato
general
Enviando datos al servidor desde un formulario HTML
Usando el método POST:
• Las páginas web incluyen a menudo formularios
para ingresar datos
• Los datos ingresados en el formulario son
“subidos” o enviados al servidor a través del cuerpo del mensaje (Entity Body)
Usando el URL:
• Utiliza el método GET
• Los datos ingresados son
enviados en el campo del URL de la línea de solicitud
www.algunsitio.com/busqueda?nombre=arcesio&apellido=net
Tipos de métodos
HTTP/1.0
• GET
• POST
• HEAD
• Hace una consulta al servidor sobre las
características del objeto, pero no transfiere el objeto
HTTP/1.1
• GET, POST, HEAD
• PUT
• Envía un archivo en el
cuerpo del mensaje al path especificado en el URL
• DELETE
• Borra el archivo
especificado en el URL
Mensaje de respuesta de HTTP
HTTP/1.1 200 OK Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821 Content-Type: text/html
datos datos datos datos datos ...
Línea de estado (código de estado del Protocolo, frase de estado)
Líneas de encabezado
datos, es decir, archivo HTML
solicitado
Códigos de estado de HTTP
• 200 OK
• Solicitud exitosa, el objeto solicitado va en este mensaje
301 Moved Permanently
• El objeto solicitado fue movido, la nueva ubicación se especifica posteriormente en este mensaje (Location:)
400 Bad Request
• El mensaje de solicitud no fue entendido por el servidor
404 Not Found
• El documento solicitado no se encontró en este servidor
505 HTTP Version Not Supported
Se usan en la primera línea del mensaje de respuesta del servidor->cliente. Ejemplos:
Conexión HTTP (cliente) hecha “a mano”
1. Conéctese, a través de telnet al puerto 80, a su sitio Web favorito:
Abre una conexión TCP al puerto 80 (puerto “bien conocido” de HTTP) en www.arcesio.net.
Cualquier cosa que se digite será enviada Al puerto 80 en www.arcesio.net
telnet www.arcesio.net 80
2. Digite una solicitud de HTTP con el método GET:
GET /index.html HTTP/1.0 Al digitar esto (y oprimir <ENTER>
dos veces), se enviará
esta solicitud HTTP mínima
(pero completa) al servidor HTTP
3. ¡Observe el mensaje de respuesta enviado por el servidor HTTP!
• Arquitectura de un sistema de correo electrónico
• SMTP
• POP3
• IMAP
• RFC 822
Arquitectura del sistema de correo
• Funciones (o servicios) del sistema de correo:
• edición de mensajes
• Transferencia de mensajes
• generación de informes
• Subsistemas
Agentes de transferencia
(demonios)
• de distribución
(SMTP, ESMTP)
• de entrega final
(POP3, IMAP)
Agentes de transferencia
Estos agentes se clasifican en:
• de distribución:
• SMTP (Simple Mail Transfer Protocol) RFC 821
• SMTP extendido (ESMTP) RFC 1425
• de entrega final: que permita al usuario gestionar su correo a través de una máquina remota
• POP3 (Post Office Protocol) RFC 1225
• IMAP (Interactive Mail Access Protocol) RFC 1064
Protocolos de entrega final de usuario
PC emisor PC receptor
Agente de transferencia
(SMTP)
Agente de usuario
Internet
Problema: acceso no permanente a Internet
• a través de un ISP
• PC servidor
conexión permanente
Protocolos de entrega final de usuario
Problema: obtener correo del buzón Solución: un buzón en el servidor
PC emisor
Agente de transferencia
(SMTP)
Internet
Servidor
(con buzón) conexión permanente
PC receptor
Agente de usuario
conexión NO permanente
POP3
Solución: POP3
Agentes de transferencia de distribución (SMTP) El SMTP
• protocolo sencillo cliente/servidor
• formato ASCII
• Establecer comunicación TCP al puerto 25
Correo electrónico
Tres componentes principales:
• Agentes de usuario
• Servidores de correo
• Protocolo simple de transferencia de correo: SMTP
Agente de usuario
• Conocido como “lector de correo”
• Permite elaborar, editar y leer mensajes de correo.
• Ejemplos: Eudora, Outlook, elm, Netscape Messanger
• Recupera los mensajes colocados en el servidor
SMTP
Buzón del usuario
Cola de mensajes salientes servidor de
correo
Agente de usuario
SMTP SMTP
Agente de usuario
Agente de usuario
Agente de usuario
servidor de correo
Agente de usuario
Agente de usuario
servidor de correo
Correo electrónico: servidores de correo
Servidores de correo
• Buzón contiene los mensajes que han llegado para el usuario
• Cola de mensajes mensajes de correo salientes (para ser
enviados)
• Protocolo SMTP usado entre los servidores de correo para enviar los mensajes
• Un programa se comporta como cliente SMTP cuando
envia correo a otro servidor de correo
• Un programa se comporta
como “servidor” cuando recibe correo de otro programa de correo.
SMTP
Buzón del usuario
Cola de mensajes salientes servidor de
correo
Agente de usuario
SMTP SMTP
Agente de usuario
Agente de usuario
Agente de usuario
servidor de correo
Agente de usuario
Agente de usuario
servidor de correo
Correo electrónico: SMTP [RFC 2821]
• Utiliza TCP para transferir confiablemente mensajes de correo desde el cliente al servidor, utiliza el puerto 25
• Transferencia directa: entre el servidor que envía y el servidor que recibe
• La transferencia tiene tres fases
• handshaking (saludo)
• Transferencia de los mensajes
• cierre
• Interacción comando/respuesta
• Comandos: texto ASCII
• Respuesta: códigos de estado y frase
• Los mensajes deben estar en ASCII de 7 bits
servidor de
correo servidor de
correo
Escenario: Alicia envía un mensaje a Beto
1) Alicia utiliza su agente de usuario para elaborar un mensaje para
[email protected] 2) El agente de usuario de Alicia
envía el mensaje a “su servidor de correo”; el mensaje es
colocado en la cola de mensajes 3) El lado “Cliente” de SMTP abre
una conexión TCP con el servidor de correo de Beto
4) El lado “cliente” de SMTP envía el mensaje de alicia sobre la conexión TCP
5) El servidor de correo de Beto coloca el mensaje en el buzón de Beto
6) Beto invoca su agente de
usuario para leer los mensajes
1
2 3 4 5 6
Agente de usuario Agente de
usuario
Agentes de transferencia de
distribución (SMTP) : protocolo
El servidor comienza por enviar una línea de texto que proporciona su identidad e indica si está preparado o no para recibir correo:
a.- Si no lo está, el cliente libera la conexión y lo intenta después.
b.- Si está dispuesto a aceptar correo electrónico, el cliente anuncia de quién viene el mensaje, y a quién está dirigido. Si existe tal destinatario en el destino, el servidor da al cliente permiso para enviar el mensaje. Entonces el cliente envía el mensaje y el servidor genera un acuse de recibo. Si existe más correo electrónico también se envía ahora. Una vez que todo el correo ha sido intercambiado en ambas direcciones, se libera la conexión.
Comandos SMTP: cliente
Comando Descripción
HELO Identifica el remitente al destinatario.
MAIL FROM: Identifica una transacción de correo e identifica al emisor.
RCPT TO: Se utiliza para identificar un destinatario individual . Si se necesita identificar múltiples destinatarios es necesario repetir el comando.
DATA Permite enviar una serie de líneas de texto. El tamaño máximo de una línea es de 1.000 caracteres. Cada línea va seguida de un retorno de carro y avance de
línea <CR><LF>. La última línea debe llevar únicamente el carácter punto “.”
seguido de <CR><LF>.
RSET Aborta la transacción de correo actual.
NOOP No operación. Indica al extremo que envíe una respuesta positiva . Keepalives
QUIT Pide al otro extremo que envíe una respuesta positiva y cierre la conexión.
VRFY Pide al receptor que confirme que un nombre identifica a un destinatario válido
EXPN Pide al receptor la confirmación de una lista de correo y que devuelva los nombres de los usuarios de dicha lista.
HELP Pide al otro extremo información sobre los comandos disponibles
TURN El emisor pide que se inviertan los papeles , para poder actuar como receptor.
El receptor puede negarse a dicha petición.
SOML Si el destinatario está conectado, entrega el mensaje directamente al terminal, en caso contrario lo entrega como correo convencional.
SAML Entrega del mensaje en el buzón del destinatario. En caso de estar conectado también lo hace al terminal.
SEND Si el destinatario está conectado, entrega el mensaje directamente al terminal.
Códigos de respuesta SMTP:
servidor
Código Descripción
211 Estado del sistema.
214 Mensaje de ayuda.
220 Servicio preparado.
221 Servicio cerrando el canal de transmisión.
250 Solicitud completada con éxito.
251 Usuario no local, se enviará a <dirección de reenvío>
354 Introduzca el texto, finalice con <CR><LF>.<CR><LF>.
421 Servicio no disponible.
450 Solicitud de correo no ejecutada, servicio no disponible (buzón ocupado).
451 Acción no ejecutada, error local de procesamiento.
452 Acción no ejecutada, insuficiente espacio de almacenamiento en el sistema.
500 Error de sintaxis, comando no reconocido.
501 Error de sintaxis. P.ej contestación de SMTP a ESMTP 502 Comando no implementado.
503 Secuencia de comandos errónea.
504 Parámetro no implementado.
550 Solicitud no ejecutada, buzón no disponible.
551 Usuario no local, pruebe <dirección de reenvío>. Si no se tiene cuenta 552 Acción de correo solicitada abortada.
553 Solicitud no realizada (error de sintaxis).
554 Fallo en la transacción.
Ejemplo del uso de comandos SMTP
Ejemplo de la interacción SMTP
S: 220 hamburger.edu C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <[email protected]>
S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]>
S: 250 [email protected] ... Recipient ok C: DATA
S: 354 Enter mail, end with "." on a line by itself C: ¿Te gusta la salsa de tomate?
C: ¿y los pepinillos?
C: .
S: 250 Message accepted for delivery C: QUIT
S: 221 hamburger.edu closing connection
C -> S C <- S C -> S C <- S C -> S C <- S C -> S C <- S C -> S C <- S
C -> S C <- S C -> S C <- S
Interacción SMTP hecha “a mano” :
• telnet nombre_servidor 25
• Se observa el código 220 como respuesta del servidor
• Se digitan los comandos HELO, MAIL FROM, RCPT TO, DATA, QUIT
Lo anterior le permite enviar un mensaje de correo electrónico sin utilizar el cliente de correo
SMTP: palabras finales
• SMTP utiliza conexiones
persistentes (como el HTTP persistente)
• SMTP obliga a que el mensaje (encabezado & cuerpo) estén en ASCII de 7 bits
• El servidor SMTP utiliza CRLF.CRLF para “decir”
donde está el final del mensaje
Comparación con HTTP:
• HTTP: protocolo pull (halar)
• SMTP: protocolo push (empujar)
• Los dos protocolos interactuan mediante
comandos/respuestas en ASCII y códigos de status
• HTTP: cada objeto se
“encapsula” en su propio mensaje de respuesta
• SMTP: multiples objectos se envían en un mensaje
“multiparte”
Formato del mensaje de correo
SMTP: protocolo para intercambio de mensajes de correo
RFC 822: estándar para el
formato de mensajes de texto:
• Líneas de header, es decir,
• To:
• From:
• Subject:
• ¡Son diferentes a los comandos SMTP!
• Cuerpo (body)
• Es el “mensaje”, sólo permite caracteres ASCII
header
body
Línea en blanco
Formato del mensaje: extensiones para multimedia
• MIME: Multimedia Internet Mail Extension, RFC 2045, 2056
• Líneas adicionales en el header del mensaje declaran contenido tipo MIME
From: [email protected] To: [email protected]
Subject: Imagen de un crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64 Content-Type: image/jpeg
base64 encoded data ...
...
...base64 encoded data Tipo de dato
multimedia, subtipo, parámetro de declaración Método utilizado para codificar datos
Versión de MIME
Datos codificados
Tipos MIME
Content-Type: tipo/subtipo; parámetros
Text
• Ejemplo de subtipos: plain, html
Image
• Ejemplo de subtipos : jpeg, gif
Audio
• Ejemplo de subtipos: midi, mp3
Video
• Ejemplo de subtipos: mpeg, quicktime
Application
• Datos que deben ser
procesados por el cliente antes de “poderse ver”
• Ejemplo de subtipos:
msword, octet-stream
Tipo Multipart
From: [email protected] To: [email protected]
Subject: Imagen de un crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPart
Hola Beto, por favor encuentra la imagen de una crepe.
--StartOfNextPart
Content-Transfer-Encoding: base64 Content-Type: image/jpeg
base64 encoded data ...
...
...base64 encoded data --StartOfNextPart
¿te gustaría tener la receta?
Protocolos de acceso al correo
• SMTP: entrega al servidor de correo del receptor
• Protocolo de acceso al correo: recupera los mensajes desde el servidor
• POP: Post Office Protocol [RFC 1939]
• autorización (agente <-->servidor) y descarga los mensajes
• IMAP: Internet Mail Access Protocol [RFC 1730]
• Más características (más complejo)
• manipulación de los mensajes almacenados en el servidor
• HTTP: Hotmail , Yahoo! Mail, Gmail, etc.
Servidor de correo del remitente
Agente de usuario
SMTP SMTP Protocolo de
Acceso
Servidor de correo del destinatario
Agente de usuario
Protocolos de entrega final de usuario
El correo entrante en un cliente se puede realizar básicamente a través de los siguientes protocolos:
POP3 (Post Office Protocol) RFC 1225 RFC 1939 tiene comandos para que un usuario establezca una sesión (USER y PASS), la termine (QUIT), obtenga mensajes (RETR) y los borre (DELE). El protocolo mismo consiste en texto ASCII y se asemeja a SMTP. El objetivo del POP3 es obtener correo electrónico del buzón remoto y almacenarlo en la máquina local del usuario para su lectura posterior.
Puerto 110. Existen versiones actualmente, que ya permiten no descargar el correo del buzón como IMAP.
IMAP (Interactive Mail Access Protocol) RFC 1064 RFC 2060. La idea en que se basa IMAP es que el servidor de correo electrónico mantenga un depósito central al que puede accederse desde cualquier máquina. Por tanto, a diferencia del POP3, no copia el correo electrónico en la máquina personal del usuario dado que el usuario puede tener varias computadoras para consultar el correo, y observa si sus correos han sido leídos con anterioridad. Puerto 143.
Protocolo POP3
Fase de autorización
• Comandos del cliente:
• user: nombre de usuario
• pass: la clave
• Respuestas del servidor
• +OK
• -ERR
Fase de transacción, cliente:
• list: lista los números de los mensajes
• retr: recupera el mensaje por el número
• dele: borra el mensaje
• quit: termina la sesión
C: list S: 1 498 S: 2 912 S: .
C: retr 1
S: <message 1 contents>
S: .
C: dele 1 C: retr 2
S: <message 1 contents>
S: .
C: dele 2 C: quit
S: +OK POP3 server signing off
S: +OK POP3 server ready C: user beto
S: +OK
C: pass goloso
S: +OK user successfully logged on
POP3 e IMAP
Más sobre POP3
• El ejemplo anterior utiliza el modo “descargue y borre”.
• Beto no puede volver a leer un mensaje si se cambia de cliente
• “Descargue y guarde”:
copias de los mensajes en diferentes clientes
• POP3 no mantiene
información de sesiones anteriores (stateless)
IMAP
• Mantiene todos los mensajes en el mismo lugar: el
servidor
• Permite al usuario que
organice sus mensajes en
´carpetas
• IMAP mantiene información de estado de sesiones
anteriores:
• Nombres de carpetas y
“correspondencia” entre la identificación de los
mensajes y el nombre de las carpetas
Formato de los mensajes RFC 822
Los mensajes con formato RFC 822 están formados por una envoltura primitiva
(descrita en el RFC 821), algunos campos de cabecera, una línea en blanco, y el cuerpo del mensaje . Cada campo de cabecera
consiste en una sola línea de texto ASCII que
contiene el nombre del campo, dos puntos (:)
y, para la mayoría de los campos un valor.
Formato de los mensajes RFC 822
Cabecera Descripción
To: Direcciones de email de los destinatarios primarios.
Cc: Direcciones de email de los destinatarios secundarios. En términos de entrega no existe diferencia con los destinatarios primarios.
Bcc: Direcciones de email de las copias al carbón ciegas. Es como el campo anterior excepto que esta línea se borra de todas las copias enviadas a los destinatarios primarios y secundarios.
From: Persona o personas que crearon el mensaje.
Sender: Dirección de correo del remitente. Puede omitirse si es igual al campo anterior.
Received: Línea agregada por cada agente de transferencia en la ruta. La línea contiene la identidad del agente, la fecha y hora de recepción del mensaje y otra información que puede servir para detectar fallos en el sistema de enrutamiento. Se añaden apiladas en la cabecera, a medida que se intercambia el email.
Return-Path: Puede usarse para identificar una trayectoria de regreso al remitente.
Campos principales del RFC822:
Formato de los mensajes RFC 822
Además, los mensajes RFC 822 pueden contener una variedad de campos auxiliares de cabecera usados por los agentes de usuario o los destinatarios.
Cabecera Descripción
Date: Fecha y hora de envío del mensaje.
Reply-To: Se usa cuando la persona que escribió el mensaje y la que lo envió no desean ver la respuesta.
Message-Id: Número único para referencia posterior a este mensaje. Suele estar compuesto por un número y la dirección de email completa del usuario que lo manda.
In-Reply-To: Identificador del mensaje al que éste corresponde.
References: Otros identificadores de mensaje.
Keywords: Claves seleccionadas por el usuario.
Subject: Resumen corto del mensaje para exhibir en una línea.
El RFC 822 explícitamente indica que los usuarios pueden inventar cabeceras nuevas para uso privado siempre y cuando comiencen con la cadena X-.
Lo que yo he enviado
To:
CC:
BCC:
From:
Date:
Subject:
X-cabeceras de uso privado:
Lo que yo he recibido
No está el campo BCC (o CCO)
Multa de 600 euros por dejar a la vista 42 direcciones de correo electrónico
Cuidado al mandar mensajes masivos: utiliza el campo CCO
“Da igual que sea un despiste, pero todo aquel que en una actividad que no sea doméstica o personal deje a la vista las direcciones de correo electrónico de sus destinatarios está cometiendo una infracción multada hasta con 60.101,21 euros por la Ley Orgánica de
Protección de Datos (LOPD)”
Noticia del 23 de febrero de 2007
Domain Name System
•
Metodo de Computadores en Internet usado paramapear direcciones IP relacionadas con nombres de dominios.
•
Computadores usan Direcciones IP para localizar un sitio, pero es muy difícil para un usuario recordar los números IP de todas las direcciones que usamos, es por eso que los DNS surgen como la opción de nombres de los dominios, pero estos nombres necesitan sertraducidos dentro de direcciones IP.
Domain Name System
• DNS (Domain Name Server) (RFC1034, RFC1035)
• Establece una correspondencia entre nombres y direcciones IP.
• Consiste en una base de datos distribuida por toda la Internet.
• Se gestiona de forma descentralizada
• El esquema de distribución es jerárquico
• Es fácil de usar en las aplicaciones (gethostbyname())
• Se crea un espacio de nombres es global
Modelo de Información de DNS
• Jerárquico en árbol invertido
• Base de datos de información de dominios (DIB)
sanson.dit.upm.es
Funcionamiento de un DNS
ISP
DNS de ISP
1:¿IP de www.uv.es?
Servidores DNS Raíz “.” Servidores DNS “es.”
Servidores DNS “uv.es.”
(147.156.1.1 alias gong)
2:¿IP de www.uv.es?
3: No lo sé. Pregúntale a “es.”
4:¿IP de www.uv.es?
5: No lo sé. Pregúntale a “uv.es.”
6:¿IP de www.uv.es?
7: www.uv.es es alias, 147.156.1.4
8: www.uv.es es alias, 147.156.1.4
Operación del DNS
• DNS es una implementación de una base de datos distribuida.
• Para cada dominio existe un servidor primario y varios secundarios.
Esto permite control local sobre segmentos específicos de la base de datos.
• Para ccTLD (Country code top-level domain) es recomendable que por lo menos uno de los servidores secundarios esté fuera del país. Ver RFC-2182.
• La palabra clave es DELEGACIÓN.
• Todos los dominios son delegados por el servidor raiz.
• Cada dominio mantiene una base de datos que convierte nombres en direcciones de IP (archivos de zona).
• También mantiene una tabla de resolución inversa donde dada un dirección de IP se puede obtener un nombre (archivos de resolución inversa).
• Ambas tablas son manejadas por un servidor de nombres (BIND), el cual contesta a las solicitudes sobre el dominio de usuarios en toda la red.
Dynamic Host Configuration
Protocol (DHCP)
Asignación Dinámica de direcciones IP
• La asignación dinámica de direcciones IP es deseable por varias razones:
• Las direcciones IP son asignada según la demanda
• Se evita la configuración manual de las direcciones IP
• Soporta la movilidad de laptops
Soluciones para la asignación dinámica de direcciones IP
• Reverse Address Resolution Protocol (RARP)
• Trabaja de forma similar a ARP
• Se envia un mensaje de Broadcast con un requerimiento o solicitud de la dirección IP asociada a una dirección MAC dada.
• El servidor RARP responde con una dirección IP
• Sólo se asigna una dirección IP (no el default gateway o la máscara de la subred)
RARP
Ethernet MAC address
(48 bit) IP address ARP
(32 bit)
BOOTP
• BOOTstrap Protocol (BOOTP)
• Proviene de 1985
• Los Host pueden configurar sus parámetros IP a momento de boot (inicialización del equipo).
• Se brindan 3 servicios.
• Asignación de direcciones IP.
• Detección de direcciones IP para un equipo servidor.
• Se especifica el nombre del archivo a ser cargado y ejecutado por la máquinas clientes (boot file name)
• No se requiere solamente de la asignación de una dirección IP, también se requiere del default gateway, la máscara de la
subred, etc.
• Se envia un mensaje UDP (UDP Port 67 (server) and 68 (host))
DHCP
• Dynamic Host Configuration Protocol (DHCP)
• Desde 1993
• Es una extensión de BOOTP.
• Utiliza los mismos números de puerto que BOOTP
• Extensiones:
• Soportas alojamiento temporal (“leases”) de direcciones IP
• Un cliente DHCP puede adquirir todos los parámetros de configuración IP que necesite para operar.
• DHCP es el mecanismo preferido para la asignación de direcciones IP .
• DHCP puede interoperar con clientes BOOTP.
Interacción de BOOTP
• BOOTP puede ser usado
para bajar una imágenes en memoria para máquinas sin disco (diskless
workstations)
• La Asignación de
direcciones IP a hosts es estática
Argon
00:a0:24:71:e4:44 BOOTP Server
BOOTP Request 00:a0:24:71:e4:44 Sent to 255.255.255.255
Argon 128.143.137.144
00:a0:24:71:e4:44 DHCP Server
BOOTP Response:
IP address: 128.143.137.144 Server IP address: 128.143.137.100 Boot file name: filename
(a) (b)
(c)
Interacción de DHCP (simplificada)
Argon 128.143.137.144
00:a0:24:71:e4:44 DHCP Server
DHCP Response:
IP address: 128.143.137.144 Default gateway: 128.143.137.1 Netmask: 255.255.0.0
Formato de los mensajes BOOTP/DHCP
Number of Seconds
OpCode Hardware Type
Your IP address
Unused (in BOOTP) Flags (in DHCP)
Gateway IP address Client IP address
Server IP address
Hardware Address
Length Hop Count
Server host name (64 bytes) Client hardware address (16 bytes)
Boot file name (128 bytes) Transaction ID
Options
BOOTP/DHCP
• OpCode: 1 (Request), 2(Reply)
• Nota: El tipo de los mensajes DHCP es enviado en una opción
• Hardware Type: 1 (para Ethernet)
• Hardware address length: 6 (para Ethernet)
• Hop count: Establecido en 0 por el cliente
• Transaction ID: Integer (usado para establecer una correspondencia entre el reply y el response)
• Seconds: número de of segundos desde que el cliente inicio el último proceso de boot
• Client IP address, Your IP address, server IP address,
Gateway IP address, client hardware address, server host name, boot file name:
el cliente llena esta información con lo que tenga, el resto lo deja en blanco.
DHCP Message Type
• El tipo de mensaje es enviado como una opcion.
Value Message Type
1 DHCPDISCOVER
2 DHCPOFFER
3 DHCPREQUEST
4 DHCPDECLINE
5 DHCPACK
6 DHCPNAK
7 DHCPRELEASE
8 DHCPINFORM
