Tema 8.docx
Document Details
Uploaded by Oganesson93
Universidad de Valladolid
Tags
Related
- Lecture 6 - TCP/IP Protocols and Architectures PDF
- CompTIA NetPlus N1000-081-2-1 OSI and TCP/IP Models PDF
- Unit 3 - Network Protocols (TCP/IP, SMTP) PDF
- Ch2_COM204-Computer-Networks PDF
- Computer Networks and Data Comuncation-LEC4 PDF
- Computer Networks and Data Communication - LEC5 TCP/IP Protocol Suite PDF
Full Transcript
**Tema 8. Protocolos TCP/IP de aplicación: descripción, formato de los paquetes y flujo de mensajes para FTP, TFTP, SNMP, SMTP, DNS, HTTP** Los protocolos de aplicación TCP/IP son un conjunto de reglas que especifican cómo los programas de aplicación deben comunicarse a través de una red de computa...
**Tema 8. Protocolos TCP/IP de aplicación: descripción, formato de los paquetes y flujo de mensajes para FTP, TFTP, SNMP, SMTP, DNS, HTTP** Los protocolos de aplicación TCP/IP son un conjunto de reglas que especifican cómo los programas de aplicación deben comunicarse a través de una red de computadoras utilizando el protocolo de Internet (IP). Algunos de los protocolos de aplicación más comunes son FTP, TFTP, SNMP, SMTP, DNS y HTTP. 1. **FTP (File Transfer Protocol)** FTP es un protocolo de transferencia de archivos (FTP, por sus siglas en inglés), que se utiliza para la transferencia de archivos entre un cliente y un servidor. Necesita del protocolo TCP confiable de la capa de transporte para su ejecución. FTP permite: - Acceso interactivo: aunque FTP está diseñado para utilizarse a través de otros programas, proporciona una interfaz interactiva que permite a los usuarios interactuar fácilmente con los servidores remotos. Por ejemplo, un usuario puede pedir la lista de ficheros de un directorio del servidor remoto. - Especificación de formato: Permite al usuario especificar el tipo y formato de los datos almacenados. Ejemplo, un usuario puede especificar que un fichero contiene datos binarios o de texto. - Control de la autenticación: requiere que los usuarios se identifiquen en la máquina remota con un usuario y contraseña. El servidor denegará el acceso a usuarios no autorizados. El protocolo FTP utiliza dos canales de comunicación simultáneos: 1. Una conexión de control: La conexión de control se establece en el puerto 21 del servidor. En esta conexión el cliente envía comandos y el servidor devuelve respuestas con la situación. 2. Una conexión de datos: La conexión de datos, por otro lado, se establece por defecto por el puerto 20 (esto se puede cambiar en la configuración del servidor) y se utiliza para la transferencia real de los datos. El formato de los mensajes en FTP se divide en dos tipos: comandos y respuestas. Los comandos son enviados desde el cliente al servidor para solicitar una acción específica, como la descarga de un archivo. Las respuestas son enviadas desde el servidor al cliente en respuesta a un comando, y contienen información sobre el éxito o el fracaso de la acción solicitada. El flujo de mensajes en FTP se inicia con la conexión de control, donde el cliente se conecta al puerto 21 del servidor FTP y se autentica con un nombre de usuario y una contraseña. A continuación, el cliente envía comandos al servidor, como \"LIST\" para obtener una lista de archivos disponibles para descargar. El servidor responde con una respuesta que contiene información sobre los archivos disponibles. Cuando el cliente desea descargar un archivo, envía un comando \"RETR\" del protocolo al servidor, y el servidor responde con una conexión de datos en un puerto diferente para transmitir el archivo (por defecto el 20). Para almacenar un fichero en el servidor el comando es "STOR". Una vez finalizada la transferencia de archivos, el cliente envía un comando \"QUIT\" al servidor para cerrar la conexión de control. La conexión de datos se cierra automáticamente después de que se haya completado la transferencia de archivos. 2. **TFTP (Trivial File Transfer Protocol)** TFTP es un protocolo simplificado de transferencia de archivos que se utiliza para transferir archivos pequeños entre computadoras en una red. Se diseñó para aplicaciones que no necesitan interacciones complejas entre cliente y servidor y no utiliza autenticación. Al contrario que FTP, TFTP no necesita servicio de transporte confiable por eso utiliza UDP en la capa de transporte y utiliza tiempos límite y retransmisión para asegurar que los datos lleguen a destino. Por este motivo generalmente se usa para transferir archivos de arranque o archivos de configuración entre máquinas en una configuración local. Debido a su diseño simple, los usuarios rara vez lo utilizan de forma interactiva en una red informática. El formato del mensaje TFTP consta de un encabezado seguido de los datos. En el encabezado, el primer campo representa el tipo de operación que se está realizando, mientras que el segundo campo representa el número de bloque de datos. Los tipos de operación posibles son: 1. solicitud de lectura (RRQ - Read Request) 2. solicitud de escritura (WRQ - Write Request) 3. datos (DATA) 4. confirmación (ACK - Acknowledgement) 5. error (ERROR) El campo de número de bloque se utiliza para identificar el orden de los mensajes durante la transferencia de datos. En el caso de las solicitudes de lectura y escritura, el número de bloque se establece en cero. Para los mensajes de datos, el número de bloque comienza en 1 y se incrementa en 1 con cada mensaje enviado. En el mensaje de confirmación se envía en número de bloque que se ha recibido. Después del encabezado, los datos del mensaje contienen los datos reales que se están transfiriendo. [Solicitud de lectura]: el cliente envía una solicitud de lectura (RRQ) al servidor. El servidor responde con un mensaje de ACK (Acknowledgment) o ERR (Error) dependiendo del éxito o fracaso de la solicitud. Si la solicitud es aceptada, el servidor envía los datos del archivo en mensajes tipo DATA de tamaño fijo. El cliente responde con un mensaje de ACK para confirmar la recepción de cada paquete de datos. [Solicitud de escritura]: el cliente envía solicitud de escritura (WRQ) al servidor y el servidor envía mensajes de ACK o ERR en respuesta. Si la solicitud es aceptada, el cliente envía mensajes con los datos al servidor y el servidor responde con mensajes de ACK para confirmar la recepción de cada mensaje. 3. **SNMP (Simple Network Management Protocol)** SNMP es un protocolo estándar de aplicación para la gestión de redes y dispositivos de red, como routers, switches y servidores. - [Administrador SNMP]: El administrador SNMP es el sistema central que se utiliza para monitorear la red SNMP. Un administrador SNMP es responsable de comunicarse con los dispositivos a través de sus agentes para consultarlos, obtener respuestas, establecer variables en ellos y reconoce eventos de ellos. - [Dispositivos administrados]: Un dispositivo administrado es una entidad de red compatible con SNMP que gestiona el administrador de SNMP. Por lo general, estos son enrutadores, conmutadores, impresoras o dispositivos inalámbricos. - [Agente SNMP]: Un agente SNMP es un programa software que está empaquetado dentro del dispositivo de red y que responde a las consultas del administrador SNMP para proporcionar el estado y las estadísticas sobre el dispositivo de red. Para ello cada agente SNMP mantiene una base de datos de información (MIB) que describe los parámetros del dispositivo administrado. Los agentes SNMP desempeñan la función más importante en la administración. - [MIB de SNMP]: Cada agente SNMP mantiene una base de datos de información que describe los parámetros del dispositivo que administra. Utiliza una estructura en árbol para almacenar la información. Una MIB viene se mantiene actualizada entre el agente y el administrador. Para realizar las operaciones básicas de administración el protocolo SNMP utiliza un servicio no orientado a la conexión (UDP) para enviar un pequeño grupo de mensajes (PDU's) entre los administradores y agentes. - GET: Una solicitud enviada por el administrador SNMP al dispositivo administrado. Al realizar el comando GET, se recuperan uno o más valores del dispositivo administrado. - GET NEXT: Al igual que el comando GET, GET NEXT recupera el valor del próximo OID en el árbol de MIB. - GET BULK: Se utiliza para recuperar datos masivos de una tabla de MIB grande. - SET: Utilizado por los administradores para modificar o asignar el valor del dispositivo administrado. - TRAP: A diferencia de los comandos anteriores, que se inician desde el administrador, los agentes inician el comando TRAPS. TRAP es una señal enviada al administrador por el agente cuando se producen eventos. - INFORM: Es similar a TRAP en cuanto a que lo inicia el agente, pero a diferencia de TRAP, INFORM incluye una confirmación del administrador una vez que recibe el mensaje. - RESPONSE: Se utiliza para devolver los valores o la señal de las acciones dirigidas por el gerente. Existen tres versiones de SNMP: SNMPv1, SNMPv2c y SNMPv3. 4. **SMTP (Simple Mail Transfer Protocol)** SMTP es un protocolo utilizado para enviar correos electrónicos entre servidores de correo electrónico y entre cliente-servidor. Cuando se envía un correo electrónico a través de un cliente de correo electrónico, el correo va desde cliente de correo hasta el servidor de correo correspondiente utilizando el protocolo SMTP. El servidor de correo se encargará de enviarlo a servidor de correo del destinatario y el cliente utilizará los protocolos POP o IMAP para descargarlo del servidor al cliente. SMTP utiliza el protocolo orientado a conexión TCP para garantizar que se entreguen todos los correos electrónicos. El diálogo entre un cliente SMTP y un servidor SMTP se basa en un conjunto de comandos enviados por el cliente SMTP, que son palabras en formato texto ASCII legibles con facilidad y unos códigos de respuesta numéricos seguidos de un texto que explica dicho código, que son enviados por el servidor SMTP. El flujo de mensajes típico para SMTP (Simple Mail Transfer Protocol) se puede resumir en varias fases: 1. El cliente SMTP establece una conexión TCP (Transmission Control Protocol) con el servidor SMTP en el puerto 25. Si la conexión es exitosa, el servidor responde con un mensaje de bienvenida o uno de rechazo de servicio. 2. El cliente envía un mensaje de saludo (HELO) al servidor SMTP. El servidor contesta con un mensaje de saludo. 3. El cliente envía el comando MAIL FROM. Como argumento de esta orden se puede pasar la dirección de correo al que el servidor notificará cualquier fallo en el envío del correo (Por ejemplo, MAIL FROM:\). Luego si el servidor comprueba que el origen es válido, el servidor responde "250 OK". 4. El cliente envía el comando RCPT TO:\ para indicar a quien se quiere enviar el correo. Se pueden mandar tantas órdenes RCPT como destinatarios del correo queramos. Por cada destinatario, el servidor contestará "250 OK" o bien "550 No such user here", si no encuentra al destinatario. 5. El siguiente comando del cliente será DATA, para indicar el comienzo del mensaje, este finalizará cuando haya una línea únicamente con un punto. El servidor contesta con el inicio de la recepción y especifica que el texto del correo electrónico debe cerrarse con un punto (\".\"). 6. El cliente envía el mensaje de correo electrónico que consta de dos partes: - Cabecera: en el ejemplo las tres primeras líneas del mensaje son la cabecera. En ellas se usan unas palabras clave para definir los campos del mensaje. Estos campos ayudan a los clientes de correo a organizarlos y mostrarlos. Los más típicos son subject (asunto), from (emisor) y to (receptor). Estos dos últimos campos no hay que confundirlos con las órdenes MAIL FROM y RCPT TO, que pertenecen al protocolo, pero no al formato del mensaje. - Cuerpo del mensaje: es el mensaje propiamente dicho. En el SMTP básico está compuesto únicamente por texto, y finalizado con una línea en la que el único carácter es un punto. 7. Tras el envío, el cliente, si no tiene que enviar más correos, con la orden QUIT corta la conexión. **DNS** DNS es un protocolo utilizado para resolver nombres de dominio en direcciones IP y viceversa. DNS se basa en un modelo cliente-servidor, donde el cliente envía una solicitud de resolución de nombre de dominio al servidor DNS y el servidor responde con la dirección IP correspondiente. \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- [Recursos (Resources):] Son los elementos, servicios o grupos que puede haber dentro un dominio. Se diferencian varias \'clases\' de recursos que se identifican por unas pocas letras: A, NS, MX, CNAME,... Cada recurso, al igual que los dominios, tiene un nombre de longitud variable. Un host común que posea un nombre y una dirección IP será considerado como un recurso de clase \'A\'. Un ejemplo muy común de recurso de clase \'A\' son los servidores web, a los que se les suele asignar el nombre \'www\'. Ejemplo: La cadena \'www.uva.es\' hace referencia a un recurso clase \'A\' llamado \'www\' que se encuentra en el dominio \'uva.es\' (en realidad son 2 dominios: \'uva\' que es un subdominio de \'es\' y el propio dominio \'es\'). El servidor DNS almacena diferentes tipos de registros de recursos utilizados para resolver nombres de su zona de autoridad. Estos registros contienen el nombre, la dirección y el tipo de registro. Como vimos antes los tipos de registros pueden ser: - A: una dirección de dispositivo final. - Nombre: nombre del equipo - Valor: dirección IP - NS: - Nombre: dominio (ej: uva.es) - Valor: nombre del servidor autoritativo para este dominio - CNAME: el nombre canónico para un alias: - Nombre: alias de algún nombre "canónico" (real) - Valor: nombre canónico - MX: registro de intercambio de correos; asigna un nombre de dominio a una lista de servidores de intercambio de correo para ese dominio. \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- Existen un gran número de servidores DNS organizados jerárquicamente y distribuidos por todo el mundo. Tres tipos de servidores: - Servidores raíz - Servidores de dominio de nivel superior (Top-Level Domain, TLD) - Servidores autoritativos [Servidores raíz]: las zonas raíz de DNS se encuentran en la parte superior de la jerarquía de administración de DNS. Los servidores de nombres de DNS que operan dentro de la zona raíz se denominan «servidores raíz». Estos servidores pueden responder a las consultas de cualquier registro almacenado en la zona raíz o en la caché de esta, o bien derivar las solicitudes al servidor TLD adecuado cuando no hay registros en caché disponibles. [Servidores TLD]: estos servidores de nombres se encuentran un nivel por debajo de los servidores raíz en la jerarquía de DNS. La información de todos los nombres de dominio que comparten una extensión común (.com,.net,.org, etc.) se mantiene en un servidor de nombres TLD. Responderá con la dirección del servidor de nombres autorizado para el nombre de dominio buscado. [Servidores autoritativos]: normalmente, la última parada en la búsqueda de una dirección IP--- se sitúan en la parte inferior de la jerarquía de DNS. Cada nombre de dominio será proporcionado por un servidor de nombres autoritativo. Administrados por la propia organización o por algún proveedor de servicios. [Servidores DNS locales]: No pertenecen estrictamente a la jerarquía. Cuando los hosts hacen una petición DNS, la envían a estos servidores locales. Se pueden hacer dos tipos de consultas: - [Consulta iterativa]: Los servidores DNS a los que se pregunta devuelven el nombre de otro servidor DNS al que preguntar "No puedo resolver ese nombre, pregunte a este servidor". - [Consulta recursiva]: El servidor DNS al que se pregunta es el encargado de resolver el nombre. ![Diagrama Descripción generada automáticamente](media/image2.png) **Formato de los mensajes** El [protocolo DNS](https://es.wikipedia.org/wiki/Sistema_de_nombres_de_dominio) establece las normas y reglas en base a las cuales dialogan los clientes y servidores DNS. El protocolo de transporte usado es generalmente es UDP, pero se podría utilizar TCP. El cliente y el servidor utilizan el mismo formato de mensaje para las preguntas que para las respuestas. El formato de un mensaje DNS es el siguiente: Respuesta, autoridad y adicional solo relleno en caso de respuestas. - Encabezado: tiene una longitud fija y contiene un identificador que sirve para relacionar las preguntas con las respuestas, luego hay una serie de indicadores que permiten distinguir diferentes condiciones del mensaje (por ejemplo, si el mensaje es de pregunta o de respuesta, si el cliente ha solicitado recursión y si la tiene concedida del servidor,...) y las longitudes de los campos que se incluyen en las secciones siguientes a la cabecera. - Pregunta: Incluye la consulta a realizar indicando el tipo de registro solicitado y su nombre. Por ejemplo, si buscamos la dirección IP de un host preguntaremos por un registro de tipo A y daremos el nombre del host: [[www.uva.es]](http://www.uva.es). - Respuesta: el servidor DNS responde con el registro completo solicitado. Siguiendo con el ejemplo anterior, en esta sección el servidor DNS devuelve el registro completo solicitado, que sería la dirección IP asociada a [[www.uva.es]](http://www.uva.es). - Autoridad: los nombres de los servidores autoritativos del domino. Un servidor DNS autoritativo es aquel que tiene una respuesta en su base de datos local para un dominio. - Adicional: proporciona información adicional, como, por ejemplo, las direcciones IP de los servidores anteriores. [[https://www.youtube.com/watch?v=XTCtEbRaueU]](https://www.youtube.com/watch?v=XTCtEbRaueU) **HTTP** Uno de los protocolos más populares de esta capa es el Protocolo de Transferencia de Hipertexto (HTTP), utilizado para la transferencia de datos en la World Wide Web. HTTP es un protocolo sin estado basado en peticiones y respuestas, donde un cliente envía una petición a un servidor y este responde con una respuesta. Cada par petición (cliente)-respuesta (servidor), el servidor cierra inmediatamente la conexión. Utilizada TCP como protocolo de transporte. La identificación de recursos siempre se hace por medio de URI. HTTP es un protocolo centrado en URI, los recursos son los objetos lógicos a los que les mandamos mensajes. Los recursos no pueden ser directamente accedidos ni modificados. En vez de eso, trabajamos con representaciones de ellos. Cada petición y respuesta se envía en un paquete llamado mensaje HTTP, que tiene un formato específico y se componen de líneas escritas en texto plano (ASCII). El formato de un mensaje HTTP: [Mensajes de Petición] Los mensajes de petición están formados por tres partes: - Línea inicial de petición. Incluye: - Método utilizado (GET, POST,\...). - La parte relativa al servidor de la URL o la URL completa si la conexión se establece con un servidor proxy. - Versión del protocolo utilizada (opcional). Los clientes y servidores actuales usan HTTP/1.1 - Línea/s de cabecera: - Conjunto de pares nombre:valor denominados cabeceras que determinan cómo será procesada la petición por parte del servidor. - Si no hay cabeceras se envía un 0. - Cada cabecera se muestra en una línea, es decir, las cabeceras se terminan con CR-LF. - Detrás de la última cabecera se envía una línea en blanco. - Cuerpo del mensaje (opcional). Contiene parámetros o ficheros a enviar al servidor. ![](media/image4.png) [Mensajes de Respuesta] Los mensajes de respuesta están también formados por tres partes: - Línea inicial de respuesta (línea de estado) - Versión HTTP utilizada. - Código de estado o código de error que informa al cliente de cómo ha sido procesada la petición. Por ejemplo, el código 200 indica que la petición se ha procesado correctamente y que el recurso correspondiente se envía al cliente. - Texto explicativo del código del estado o error. - Línea/s de cabecera - Conjunto de pares nombre:valor denominados cabeceras que describen los datos y la forma en que son enviados al cliente. - Si no hay cabeceras se envía un 0. - Cada cabecera se muestra en una línea, es decir, las cabeceras se terminan con CR-LF. - Detrás de la última cabecera se envía una línea en blanco. - Cuerpo del mensaje (opcional). Queda determinado por el tipo de recursos solicitado. - Método GET: Es el método más utilizado y se emplea para obtener cualquier tipo de información del servidor. Se invoca cuando se introduce una URL en el navegador, cuando se pincha sobre un hiperenlace o cuando se envía un formulario GET. Permite enviar parámetros al servidor en la URI (o URL) (conocidos como Query String). - Método POST: Se emplea para solicitar al servidor que acepte información que se adjunta en una petición. Las peticiones POST envían el cuerpo del mensaje y en él se incluyen los parámetros y los datos que se consideren. Los parámetros no son visibles, por lo tanto, en la URL. - Método OPTIONS: Para solicitar al servidor información sobre las opciones de comunicación disponibles de un recurso determinado. - Método HEAD: Para recuperar las cabeceras de una página web. Similar a GET pero el servidor devuelve cabeceras. Usado para implementar caches de navegadores, informar al usuario del tamaño del recurso antes de intentar recuperarlo, etc. - Método PUT: Para enviar recursos (subir) al servidor. Por seguridad no es habitual que los servidores web permitan subir recursos usando el método PUT. - Método DELETE: Para eliminar recursos del servidor. Por seguridad no es habitual que los servidores web permitan subir recursos usando el método DELETE. - Método TRACE: Para trazar la ruta de una petición a través de proxies y cortafuegos.Usado para depurar errores en redes complejas. El flujo de mensajes HTTP comienza cuando un cliente envía una solicitud a un servidor. El servidor recibe la solicitud, procesa la petición y envía una respuesta al cliente. El cliente puede entonces decidir si solicitar más información o terminar la comunicación.