Protocolos de internet

15,179 views

Published on

Protocolos de Internet y Caracteristicas principales y aquellos que son los mas utilizados.

Published in: Education, Technology
5 Comments
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
15,179
On SlideShare
0
From Embeds
0
Number of Embeds
172
Actions
Shares
0
Downloads
409
Comments
5
Likes
0
Embeds 0
No embeds

No notes for slide

Protocolos de internet

  1. 1. Protocolos de internet<br />
  2. 2. Definición<br />La definición del término protocolo es importantísimo. En la vida real, los protocolos son un conjunto de hábitos y procedimientos utilizados en las relaciones interpersonales. Cuando es usado bajo el contexto de redes de comunicación el termino protocolo tiene un significado similar pero a un nivel mas especifico, esto es, un protocolo de red es un conjunto de reglas, secuencias, formatos de mensajes y procedimientos bien detallados que posibilitan la transferencia de datos entre dos o mas sistemas de computación.<br />            De manera similar, un protocolo de red (incluyendo todos los protocolos de internet) es el termino utilizado para describir como los sistemas de computación se comunican con otros a nivel de bit y de byte.<br />
  3. 3. Tipos de Protocolo<br />Protocolos de bajo nivel<br />* IP, Direcciones IP<br />Su función es transmitir trozos de data de un sistema a otro, la información mas importante que requiere IP, es la dirección de los sistemas de computación que IP utiliza para transmitir y recibir data.<br />El término mas familiar para una localización en internet es “dirección”, cada sistema en internet tiene dirección. Esta dirección es llamada dirección IP, existen dos formatos para una dirección IP. Uno es interno, cada computadora en internet utiliza una dirección IP compuesta por 4 números, un ejemplo es ‘198.137.231.1’. Sin embargo como es mas fácil para las personas recordar nombres que numero, se tiene el otro formato que corresponde a nombres de direcciones IP.<br />
  4. 4. Tipos de Protocolo<br />* TCP Y UDP<br />            En general se ha explicado como los sistemas se comunican a bajo nivel utilizando direcciones IP tanto en el formato numérico como en el formato de nombres para identificar la misma. IP no suministra mas capacidades que enviar y recibir trozos de data se requiere mucho mas que eso, en este sentido aparecen TCP Y UDP. TCP (Protocolo de Control de Transmisión) suministra una conexión virtual entre dos sistemas (lo que significa que pueden existir muchas conexiones físicas a partir de una conexión virtual), con ciertas garantías en los trozos de datos (llamados paquetes) que son transmitidos entre los sistemas. Dos garantías son: la retransmisión de los paquetes que son borrados (por problemas en la red) y la otra es que los paquetes son recibidos en el mismo orden en que son enviados. La tercera garantía es que cada paquete recibido tiene exactamente el mismo contenido que el paquete enviado.<br />
  5. 5. Tipos de Protocolo<br />Algunos aplicaciones utilizan un protocolo distinto que corre encima de IP, este es llamado UDP (Protocolo de Datagramas de Usuarios). UDP envía un paquete de data a la vez (llamado datagrama) a otros sistemas y no suministra una conexión virtual como lo hace TCP, asimismo UDP no provee las mismas garantías que tiene TCP, esto significa que puede darse el caso de que los paquetes se pierdan o bien no sean reconstruidos en la forma adecuada.<br />            La utilidad de utilizar UDP en vez de TCP,  Si UDP no es confiable, esta se basa en que TCP tiene un alto solapamiento en la conexión comparado con UDP, lo que hace que TCP sea mas lento que UDP. Para aplicaciones donde la velocidad de ejecución es mas importante que la confiabilidad, UDP tiene mas sentido. Algunos ejemplos incluye audio y video en la internet y algunas aplicaciones telefónicas.<br />
  6. 6. Tipos de Protocolo<br />* SLIP Y PPP<br />            En los casos en que una aplicación de internet esta corriendo sobre sistemas conectados a una LAN, probablemente estos están utilizando IP sobre una red ETHERNET o Token Ring, con una conexión de internet dedicada (esclava).<br />            Tanto SLIP como PPP utilizan IP para enviar data sobre líneas dedicadas. SLIP es la abreviatura de Líneas seriales IP y PPP es el nombre corto de Protocolo de Punto a Punto. Ambos toman la data y los paquetes de IP para que así estos puedan ser enviados sobre modem en líneas dedicadas.<br />
  7. 7. Tipos de Protocolo<br />Protocolos de Aplicación de internet<br />* FTP y Telnet<br />            FTP (Protocolo de transferencia de archivos) permite bajar y colocar archivos en la internet. Para bajar un archivo en un sistema de computación es necesario correr una aplicación cliente de FTP que se conecta al servidor FTP y procede a bajar el archivo de su correspondiente directorio o carpeta.<br />            Telnet es una vía para realizar una conexión remota a otro sistema en la red. Un servidor telnet debe estar corriendo en el sistema remoto y un cliente de telnet debe estar corriendo en el sistema local. Los sistema operativos típicos para servidores telnet son unís, Windows nt etc.<br />
  8. 8. Tipos de Protocolo<br />* HTTP<br />            Es el protocolo primario de www. Cuando un navegador se conecta a un servidor web, este usa http para recibir paginas web,  http tiene la capacidad para transferir paginas web, gráficos y muchos otros tipos de medios usados en internet.<br />* Internet,  Correo electrónico<br />            El correo electrónico utiliza un protocolo llamado SMTP (Protocolo de transferencia de correo simple) una aplicación cliente de correo electrónico es utilizado para enviar y recibir mensajes y esta se comunica con un servidor SMTP el cual esta fuera y se encarga de enviar los mensajes y tomar la responsabilidad de tomar estos. Una dirección de correo electrónico esta compuesta de dos partes: el nombre del usuario y la dirección del servidor, un ejemplo cduran@consisint.com.<br />
  9. 9. Protocolo IP<br />La función del protocolo IP<br />El protocolo IP es parte de la capa de Internet del conjunto de protocolos TCP/IP. Es uno de los protocolos de Internet más importantes ya que permite el desarrollo y transporte de datagramas de IP (paquetes de datos), aunque sin garantizar su "entrega". En realidad, el protocolo IP procesa datagramas de IP de manera independiente al definir su representación, ruta y envío. <br />El protocolo IP determina el destinatario del mensaje mediante 3 campos: <br />el campo de dirección IP: Dirección del equipo;<br />
  10. 10. Protocolo IP<br />el campo de máscara de subred: una máscara de subred le permite al protocolo IP establecer la parte de la dirección IP que se relaciona con la red;<br />el campo de pasarela predeterminada: le permite al protocolo de Internet saber a qué equipo enviar un datagrama, si el equipo de destino no se encuentra en la red de área local.<br />
  11. 11. Protocolo IP<br />Datagramas<br />Los datos circulan en Internet en forma de datagramas (también conocidos como paquetes). Los datagramas son datos encapsulados, es decir, datos a los que se les agrega un encabezado que contiene información sobre su transporte (como la dirección IP de destino). <br />Los routers analizan (y eventualmente modifican) los datos contenidos en un datagrama para que puedan transitar. <br />
  12. 12. Protocolo IP<br />A continuación se indica cómo se ve un datagrama: <br />
  13. 13. Protocolo IP<br />A continuación se indican los significados de los diferentes campos: <br />Versión (4 bits): es la versión del protocolo IP que se está utilizando (actualmente se utiliza la versión 4 IPv4) para verificar la validez del datagrama. Está codificado en 4 bits.<br />Longitud del encabezado o IHL por Internet Header Length (Longitud del encabezado de Internet) (4 bits): es la cantidad de palabras de 32 bits que componen el encabezado (Importante: el valor mínimo es 5). Este campo está codificado en 4 bits.<br />
  14. 14. Protocolo IP<br />Tipo de servicio (8 bits): indica la forma en la que se debe procesar el datagrama.<br />Longitud total (16 bits): indica el tamaño total del datagrama en bytes. El tamaño de este campo es de 2 bytes, por lo tanto el tamaño total del datagrama no puede exceder los 65536 bytes. Si se lo utiliza junto con el tamaño del encabezado, este campo permite determinar dónde se encuentran los datos.<br />Identificación, indicadores y margen del fragmento son campos que permiten la fragmentación de datagramas. Esto se explica a continuación.<br />
  15. 15. Protocolo IP<br />TTL o Tiempo de vida (8 bits): este campo especifica el número máximo de routers por los que puede pasar un datagrama. Por lo tanto, este campo disminuye con cada paso por un router y cuando alcanza el valor crítico de 0, el router destruye el datagrama. Esto evita que la red se sobrecargue de datagramas perdidos.<br />Protocolo (8 bits): este campo, en notación decimal, permite saber de qué protocolo proviene el datagrama. <br />ICMP 1<br />IGMP: 2<br />TCP: 6<br />UDP: 17<br />
  16. 16. Protocolo IP<br />Suma de comprobación del encabezado (16 bits): este campo contiene un valor codificado en 16 bits que permite controlar la integridad del encabezado para establecer si se ha modificado durante la transmisión. La suma de comprobación es la suma de todas las palabras de 16 bits del encabezado (se excluye el campo suma de comprobación). Esto se realiza de tal modo que cuando se suman los campos de encabezado (suma de comprobación inclusive), se obtenga un número con todos los bits en 1.<br />Dirección IP de origen (32 bits): Este campo representa la dirección IP del equipo remitente y permite que el destinatario responda.<br />Dirección IP de destino (32 bits): dirección IP del destinatario del mensaje.<br />
  17. 17. Protocolo IP<br />Fragmentación de datagramas de IP<br />Como se ha visto anteriormente, el tamaño máximo de un datagrama es de 65536 bytes. Sin embargo, este valor nunca es alcanzado porque las redes no tienen suficiente capacidad para enviar paquetes tan grandes. Además, las redes en Internet utilizan diferentes tecnologías por lo tanto el tamaño máximo de un datagrama varía según el tipo de red.El tamaño máximo de una trama se denomina MTU (Unidad de transmisión máxima). El datagrama se fragmentará si es más grande que la MTU de la red. <br />
  18. 18. Protocolo IP<br />La fragmentación del datagrama se lleva a cabo a nivel de router, es decir, durante la transición de una red con una MTU grande a una red con una MTU más pequeña. Si el datagrama es demasiado grande para pasar por la red, el router lo fragmentará, es decir, lo dividirá en fragmentos más pequeños que la MTU de la red, de manera tal que el tamaño del fragmento sea un múltiplo de 8 bytes. <br />
  19. 19. Protocolo IP<br />El router enviará estos fragmentos de manera independiente y los volverá a encapsular (agregar un encabezado a cada fragmento) para tener en cuenta el nuevo tamaño del fragmento. Además, el router agrega información para que el equipo receptor pueda rearmar los fragmentos en el orden correcto. Sin embargo, no hay nada que indique que los fragmentos llegarán en el orden correcto, ya que se enrutan de manera independiente. <br />
  20. 20. Protocolo IP<br />Para tener en cuenta la fragmentación, cada datagrama cuenta con diversos campos que permiten su rearmado: <br />campo Margen del fragmento (13 bits): campo que brinda la posición del comienzo del fragmento en el datagrama inicial. La unidad de medida para este campo es 8 bytes (el primer fragmento tiene un valor cero);<br />campo Identificación (16 bits): número asignado a cada fragmento para permitir el rearmado;<br />campo Longitud total (16 bits): esto se vuelve a calcular para cada fragmento; campo Indicador (3 bits): está compuesto de tres bits: <br />
  21. 21. Protocolo IP<br />Enrutamiento IP<br />El enrutamiento IP es una parte integral de la capa de Internet del conjunto TCP/IP. El enrutamiento consiste en asegurar el enrutamiento de un datagrama de IP a través de la red por la ruta más corta. A esta función la llevan a cabo los equipos denominados routers, es decir, equipos que conectan al menos dos redes. <br />
  22. 22. Protocolo TCP<br />Las características del protocolo TCP<br />TCP (que significa Protocolo de Control de Transmisión) es uno de los principales protocolos de la capa de transporte del modelo TCP/IP. En el nivel de aplicación, posibilita la administración de datos que vienen del nivel más bajo del modelo, o van hacia él, (es decir, el protocolo IP). Cuando se proporcionan los datos al protocolo IP, los agrupa en datagramas IP, fijando el campo del protocolo en 6 (para que sepa con anticipación que el protocolo es TCP). TCP es un protocolo orientado a conexión, es decir, que permite que dos máquinas que están comunicadas controlen el estado de la transmisión. <br />
  23. 23. Protocolo TCP<br />Las principales características del protocolo TCP son las siguientes: <br />TCP permite colocar los datagramas nuevamente en orden cuando vienen del protocolo IP.<br />TCP permite que el monitoreo del flujo de los datos y así evita la saturación de la red.<br />TCP permite que los datos se formen en segmentos de longitud variada para "entregarlos" al protocolo IP.<br />TCP permite multiplexar los datos, es decir, que la información que viene de diferentes fuentes (por ejemplo, aplicaciones) en la misma línea pueda circular simultáneamente.<br />Por último, TCP permite comenzar y finalizar la comunicación amablemente. <br />
  24. 24. Protocolo TCP<br />El objetivo de TCP<br />Con el uso del protocolo TCP, las aplicaciones pueden comunicarse en forma segura (gracias al sistema de acuse de recibo del protocolo TCP) independientemente de las capas inferiores. Esto significa que los routers (que funcionan en la capa de Internet) sólo tienen que enviar los datos en forma de datagramas, sin preocuparse con el monitoreo de datos porque esta función la cumple la capa de transporte (o más específicamente el protocolo TCP). <br />Durante una comunicación usando el protocolo TCP, las dos máquinas deben establecer una conexión. La máquina emisora (la que solicita la conexión) se llama cliente, y la máquina receptora se llama servidor. <br />
  25. 25. Protocolo TCP<br />Por eso es que decimos que estamos en un entorno Cliente-Servidor. Las máquinas de dicho entorno se comunican en modo en línea, es decir, que la comunicación se realiza en ambas direcciones. <br />Para posibilitar la comunicación y que funcionen bien todos los controles que la acompañan, los datos se agrupan; es decir, que se agrega un encabezado a los paquetes de datos que permitirán sincronizar las transmisiones y garantizar su recepción. <br />Otra función del TCP es la capacidad de controlar la velocidad de los datos usando su capacidad para emitir mensajes de tamaño variable. Estos mensajes se llaman segmentos. <br />
  26. 26. Protocolo TCP<br />La función multiplexión<br />TCP posibilita la realización de una tarea importante: multiplexar/demultiplexar; es decir transmitir datos desde diversas aplicaciones en la misma línea o, en otras palabras, ordenar la información que llega en paralelo. <br />
  27. 27. Protocolo TCP<br />Equipo A<br />Equipo B<br />multiplexacion<br />demultiplexacion<br />
  28. 28. Protocolo TCP<br />Estas operaciones se realizan empleando el concepto de puertos (o conexiones), es decir, un número vinculado a un tipo de aplicación que, cuando se combina con una dirección de IP, permite determinar en forma exclusiva una aplicación que se ejecuta en una máquina determinada. <br />
  29. 29. Protocolo TCP<br />El formato de los datos en TCP<br />Un segmento TCP está formado de la siguiente manera: <br />
  30. 30. Protocolo TCP<br />Significado de los diferentes campos: <br />Puerto de origen (16 bits): Puerto relacionado con la aplicación en curso en la máquina origen<br />Puerto de destino (16 bits): Puerto relacionado con la aplicación en curso en la máquina destino<br />Número de secuencia (32 bits): Cuando el indicador SYN está fijado en 0, el número de secuencia es el de la primera palabra del segmento actual. Cuando SYN está fijado en 1, el número de secuencia es igual al número de secuencia inicial utilizado para sincronizar los números de secuencia (ISN).<br />
  31. 31. Protocolo TCP<br />Número de acuse de recibo (32 bits): El número de acuse de recibo, también llamado número de descargo se relaciona con el número (secuencia) del último segmento esperado y no el número del último segmento recibido.<br />Margen de datos (4 bits): Esto permite ubicar el inicio de los datos en el paquete. Aquí, el margen es fundamental porque el campo opción es de tamaño variable. Reservado (6 bits): Un campo que actualmente no está en uso pero se proporciona para el uso futuro. Indicadores (6x1 bit): Los indicadores representan información adicional: <br />
  32. 32. Protocolo TCP<br />URG: Si este indicador está fijado en 1, el paquete se debe procesar en forma urgente.<br />ACK: Si este indicador está fijado en 1, el paquete es un acuse de recibo.<br />PSH (PUSH): Si este indicador está fijado en 1, el paquete opera de acuerdo con el método PUSH.<br />RST: Si este indicador está fijado en 1, se restablece la conexión.<br />SYN: El indicador SYN de TCP indica un pedido para establecer una conexión.<br />FIN: Si este indicador está fijado en 1, se interrumpe la conexión.<br />
  33. 33. Protocolo TCP<br />Ventana (16 bits): Campo que permite saber la cantidad de bytes que el receptor desea recibir sin acuse de recibo. <br />Suma de control (CRC): La suma de control se realiza tomando la suma del campo de datos del encabezado para poder verificar la integridad del encabezado. <br />Puntero urgente (16 bits): Indica el número de secuencia después del cual la información se torna urgente. Opciones (tamaño variable): Diversas opciones <br />Relleno: Espacio restante después de que las opciones se rellenan con ceros para tener una longitud que sea múltiplo de 32 bits.<br />
  34. 34. Protocolo TCP<br />Confiabilidad de las transferencias<br />El protocolo TCP permite garantizar la transferencia de datos confiable, a pesar de que usa el protocolo IP, que no incluye ningún monitoreo de la entrega de datagramas. <br />De hecho, el protocolo TCP tiene un sistema de acuse de recibo que permite al cliente y al servidor garantizar la recepción mutua de datos. Cuando se emite un segmento, se lo vincula a un número de secuencia. Con la recepción de un segmento de datos, la máquina receptora devolverá un segmento de datos donde el indicador ACK esté fijado en 1 (para poder indicar que es un acuse de recibo) acompañado por un número de acuse de recibo que equivale al número de secuencia anterior. <br />
  35. 35. Protocolo TCP<br />Segmento 1<br />ACK 1<br />Sistema de <br />Recepción<br />Sistema de <br />Trasmisión<br />Segmento 2<br />
  36. 36. Protocolo TCP<br />Además, usando un temporizador que comienza con la recepción del segmento en el nivel de la máquina originadora, el segmento se reenvía cuando ha transcurrido el tiempo permitido, ya que en este caso la máquina originadora considera que el segmento está perdido.<br />
  37. 37. Protocolo TCP<br />Segmento 1<br />Segmento 1<br />Sistema de <br />Recepción<br />Sistema de <br />Trasmisión<br />ACK 1<br />
  38. 38. Protocolo TCP<br />Sin embargo, si el segmento no está perdido y llega a destino, la máquina receptora lo sabrá, gracias al número de secuencia, que es un duplicado, y sólo retendrá el último segmento que llegó a destino.<br />
  39. 39. Protocolo TCP<br />Cómo establecer una conexión<br />Considerando que este proceso de comunicación, que se produce con la transmisión y el acuse de recibo de datos, se basa en un número de secuencia, las máquinas originadora y receptora (cliente y servidor) deben conocer el número de secuencia inicial de la otra máquina. <br />La conexión establecida entre las dos aplicaciones a menudo se realiza siguiendo el siguiente esquema: <br />Los puertos TCP deben estar abiertos.<br />
  40. 40. Protocolo TCP<br />La aplicación en el servidor es pasiva, es decir, que la aplicación escucha y espera una conexión.<br />La aplicación del cliente realiza un pedido de conexión al servidor en el lugar donde la aplicación es abierta pasiva. La aplicación del cliente se considera "abierta activa".<br />Las dos máquinas deben sincronizar sus secuencias usando un mecanismo comúnmente llamado negociación en tres pasos que también se encuentra durante el cierre de la sesión. <br />
  41. 41. Protocolo TCP<br />Este diálogo posibilita el inicio de la comunicación porque se realiza en tres etapas, como su nombre lo indica: <br />En la primera etapa, la máquina originadora (el cliente) transmite un segmento donde el indicador SYN está fijado en 1 (para indicar que es un segmento de sincronización), con número de secuencia N llamado número de secuencia inicial del cliente.<br />
  42. 42. Protocolo TCP<br />En la segunda etapa, la máquina receptora (el servidor) recibe el segmento inicial que viene del cliente y luego le envía un acuse de recibo, que es un segmento en el que el indicador ACK está fijado en 1 y el indicador SYN está fijado en 1 (porque es nuevamente una sincronización). Este segmento incluye el número de secuencia de esta máquina (el servidor), que es el número de secuencia inicial para el cliente. El campo más importante en este segmento es el de acuse de recibo que contiene el número de secuencia inicial del cliente incrementado en 1.<br />
  43. 43. Protocolo TCP<br />Por último, el cliente transmite un acuse de recibo, que es un segmento en el que el indicador ACK está fijado en 1 y el indicador SYN está fijado en 0 (ya no es un segmento de sincronización). Su número de secuencia está incrementado y el acuse de recibo representa el número de secuencia inicial del servidor incrementado en 1.<br />
  44. 44. Protocolo TCP<br />SYN<br />Secuencia = C<br />SYN<br />ACK = C+1<br />Secuencia = S<br />Receptor<br />Emisor<br />ACK = S+1<br />Secuencia = C+1<br />
  45. 45. Protocolo TCP<br />Después de esta secuencia con tres intercambios, las dos máquinas están sincronizadas y la comunicación puede comenzar. <br />Existe una técnica de piratería llamada falsificación de IP, que permite corromper este enlace de aprobación con fines maliciosos. <br />
  46. 46. Protocolo TCP<br />Método de ventana corrediza<br />En muchos casos, es posible limitar la cantidad de acuses de recibo con el fin de aliviar el tráfico en la red. Esto se logra fijando un número de secuencia después del cual se requiera un acuse de recibo. Este número en realidad se guarda en el campo ventana del encabezado TCP/IP. <br />Este método se llama efectivamente el "el método de la ventana corrediza" porque, en cierta medida, se define una serie de secuencias que no necesitan acuses de recibo y que se desplaza a medida que se reciben los acuses de recibo. <br />
  47. 47. Protocolo TCP<br />123456789<br />Sistema de <br />Recepción<br />Sistema de <br />Trasmisión<br />
  48. 48. Protocolo TCP<br />Además, el tamaño de esta ventana no es fijo. De hecho, el servidor puede incluir el tamaño de la ventana que considera más apropiado en sus acuses de recibo guardándolo en el campo ventana. De este modo, cuando el acuse de recibo indica un pedido para aumentar la ventana, el cliente se desplazará al borde derecho de la ventana.<br />123456789<br />
  49. 49. Protocolo TCP<br />Por el contrario, en el caso de una reducción, el cliente no desplazará el borde derecho de la ventana hacia la izquierda sino que esperará que avance el borde izquierdo (al llegar los acuses de recibo).<br />123456789<br />
  50. 50. Protocolo TCP<br />Cómo terminar una conexión<br />El cliente puede pedir que se termine una conexión del mismo modo que el servidor. Para terminar una conexión se procede de la siguiente manera: <br />Una de las máquinas envía un segmento con el indicador FIN fijado en 1, y la aplicación se autocoloca en estado de espera, es decir que deja de recibir el segmento actual e ignora los siguientes.<br />
  51. 51. Protocolo TCP<br />Después de recibir este segmento, la otra máquina envía un acuse de recibo con el indicador FIN fijado en 1 y sigue enviando los segmentos en curso. Después de esto, la máquina informa a la aplicación que se ha recibido un segmento FIN y luego envía un segmento FIN a la otra máquina, que cierra la conexión.<br />
  52. 52. Protocolo UDP<br />El protocolo UDP (Protocolo de datagrama de usuario) es un protocolo no orientado a conexión de la capa de transporte del modelo TCP/IP. Este protocolo es muy simple ya que no proporciona detección de errores (no es un protocolo orientado a conexión). <br />Por lo tanto, el encabezado del segmento UDP es muy simple: <br />
  53. 53. Protocolo UDP<br />Significado de los diferentes campos<br />Puerto de origen: es el número de puerto relacionado con la aplicación del remitente del segmento UDP. Este campo representa una dirección de respuesta para el destinatario. Por lo tanto, este campo es opcional. Esto significa que si el puerto de origen no está especificado, los 16 bits de este campo se pondrán en cero. En este caso, el destinatario no podrá responder (lo cual no es estrictamente necesario, en particular para mensajes unidireccionales).<br />
  54. 54. Protocolo UDP<br />Puerto de destino: este campo contiene el puerto correspondiente a la aplicación del equipo receptor al que se envía.<br />Longitud: este campo especifica la longitud total del segmento, con el encabezado incluido. Sin embargo, el encabezado tiene una longitud de 4 x 16 bits (que es 8 x 8 bits), por lo tanto la longitud del campo es necesariamente superior o igual a 8 bytes.<br />Suma de comprobación: es una suma de comprobación realizada de manera tal que permita controlar la integridad del segmento.<br />
  55. 55. Protocolo FTP<br />El protocolo FTP (Protocolo de transferencia de archivos) es, como su nombre lo indica, un protocolo para transferir archivos. <br />La implementación del FTP se remonta a 1971 cuando se desarrolló un sistema de transferencia de archivos (descrito en RFC141) entre equipos del Instituto Tecnológico de Massachusetts (MIT, Massachusetts Institute of Technology). Desde entonces, diversos documentos de RFC (petición de comentarios) han mejorado el protocolo básico, pero las innovaciones más importantes se llevaron a cabo en julio de 1973. <br />Actualmente, el protocolo FTP está definido por RFC 959 (Protocolo de transferencia de archivos (FTP) - Especificaciones). <br />
  56. 56. Protocolo FTP<br />La función del protocolo FTP<br />El protocolo FTP define la manera en que los datos deben ser transferidos a través de una red TCP/IP. <br />El objetivo del protocolo FTP es: <br />permitir que equipos remotos puedan compartir archivos <br />permitir la independencia entre los sistemas de archivo del equipo del cliente y del equipo del servidor <br />permitir una transferencia de datos eficaz <br />
  57. 57. Protocolo FTP<br />El modelo FTP<br />El protocolo FTP está incluido dentro del modelo cliente-servidor, es decir, un equipo envía órdenes (el cliente) y el otro espera solicitudes para llevar a cabo acciones (el servidor). <br />Durante una conexión FTP, se encuentran abiertos dos canales de transmisión: <br />Un canal de comandos (canal de control) <br />Un canal de datos<br />
  58. 58. Protocolo FTP<br />Usuario<br />SERVIDOR<br />CLIENTE<br />Canal de Control<br />GUI<br />Comandos<br />De respuesta<br />Cliente <br />PI<br />Servidor<br />PI<br />Usuario DTP<br />Servidor <br />De DTP<br />Canal de Datos<br />Sistema de Archivos<br />Sistema de Archivos<br />
  59. 59. Protocolo FTP<br />Por lo tanto, el cliente y el servidor cuentan con dos procesos que permiten la administración de estos dos tipos de información: <br />DTP (Proceso de transferencia de datos) es el proceso encargado de establecer la conexión y de administrar el canal de datos. El DTP del lado del servidor se denomina SERVIDOR DE DTP y el DTP del lado del cliente se denomina USUARIO DE DTP. <br />PI (Intérprete de protocolo) interpreta el protocolo y permite que el DTP pueda ser controlado mediante los comandos recibidos a través del canal de control. <br />
  60. 60. Protocolo FTP<br />Esto es diferente en el cliente y el servidor:<br />El SERVIDOR PI es responsable de escuchar los comandos que provienen de un USUARIO PI a través del canal de control en un puerto de datos, de establecer la conexión para el canal de control, de recibir los comandos FTP del USUARIO PI a través de éste, de responderles y de ejecutar el SERVIDOR DE DTP. <br />El USUARIO PI es responsable de establecer la conexión con el servidor FTP, de enviar los comandos FTP, de recibir respuestas del SERVIDOR PI y de controlar al USUARIO DE DTP, si fuera necesario. <br />
  61. 61. Protocolo FTP<br />Cuando un cliente FTP se conecta con un servidor FTP, el USUARIO PI inicia la conexión con el servidor de acuerdo con el protocolo Telnet. El cliente envía comandos FTP al servidor, el servidor los interpreta, ejecuta su DTP y después envía una respuesta estándar. Una vez que se establece la conexión, el servidor PI proporciona el puerto por el cual se enviarán los datos al Cliente DTP. El cliente DTP escucha el puerto especificado para los datos provenientes del servidor.<br />
  62. 62. Protocolo FTP<br />Es importante tener en cuenta que, debido a que los puertos de control y de datos son canales separados, es posible enviar comandos desde un equipo y recibir datos en otro. Entonces, por ejemplo, es posible transferir datos entre dos servidores FTP mediante el paso indirecto por un cliente para enviar instrucciones de control y la transferencia de información entre dos procesos del servidor conectados en el puerto correcto. <br />
  63. 63. Protocolo FTP<br />CLIENTE<br />Servidor <br />PI<br />Servidor DTP<br />SERVIDOR<br />SERVIDOR<br />Canal de Control<br />Servidor <br />PI<br />Servidor<br />PI<br />Servidor DTP<br />Servidor <br />De DTP<br />Canal de Datos<br />Sistema de Archivos<br />Sistema de Archivos<br />
  64. 64. Protocolo FTP<br />En esta configuración, el protocolo indica que los canales de control deben permanecer abiertos durante la transferencia de datos. De este modo, un servidor puede detener una transmisión si el canal de control es interrumpido durante la transmisión. <br />
  65. 65. Protocolo FTP<br />Los comandos FTP<br />Toda comunicación que se realice en el canal de control sigue las recomendaciones del protocolo Telnet. Por lo tanto, los comandos FTP son cadenas de caracteres Telnet (en código NVT-ASCII) que finalizan con el código de final de línea Telnet (es decir, la secuencia <CR>+<LF>, Retorno de carro seguido del carácter Avance de línea indicado como <CRLF>). Si el comando FTP tiene un parámetro, éste se separa del comando con un espacio (<SP>). <br />
  66. 66. Protocolo FTP<br />Los comandos FTP hacen posible especificar: <br />El puerto utilizado <br />El método de transferencia de datos <br />La estructura de datos <br />La naturaleza de la acción que se va a realizar (Recuperar, Enumerar, Almacenar, etc.) <br />Existen tres tipos de comandos FTP diferentes: <br />Comandos de control de acceso <br />Comandos de parámetros de transferencia <br />Comandos de servicio FTP <br />
  67. 67. Protocolo FTP<br />
  68. 68. Protocolo FTP<br />
  69. 69. Protocolo FTP<br />
  70. 70. Protocolo FTP<br />
  71. 71. Protocolo FTP<br />
  72. 72. Protocolo FTP<br />Las respuestas FTP<br />Las respuestas FTP garantizan la sincronización entre el cliente y el servidor FTP. Por lo tanto, por cada comando enviado por el cliente, el servidor eventualmente llevará a cabo una acción y sistemáticamente enviará una respuesta. <br />Las respuestas están compuestas por un código de 3 dígitos que indica la manera en la que el comando enviado por el cliente ha sido procesado. Sin embargo, debido a que el código de 3 dígitos resulta difícil de leer para las personas, está acompañado de texto (cadena de caracteres Telnet separada del código numérico por un espacio). <br />
  73. 73. Protocolo FTP<br />Los códigos de respuesta están compuestos por 3 números, cuyos significados son los siguientes: <br />El primer número indica el estatuto de la respuesta (exitosa o fallida) <br />El segundo número indica a qué se refiere la respuesta. <br />El tercer número brinda un significado más específico (relacionado con cada segundo dígito). <br />
  74. 74. Protocolo FTP<br />
  75. 75. Protocolo FTP<br />
  76. 76. Protocolo Telnet<br />El protocolo Telnet es un protocolo de Internet estándar que permite conectar terminales y aplicaciones en Internet. El protocolo proporciona reglas básicas que permiten vincular a un cliente (sistema compuesto de una pantalla y un teclado) con un intérprete de comandos (del lado del servidor). <br />El protocolo Telnet se aplica en una conexión TCP para enviar datos en formato ASCII codificados en 8 bits, entre los cuales se encuentran secuencias de verificación Telnet. Por lo tanto, brinda un sistema de comunicación orientado bidireccional (semidúplex) codificado en 8 bits y fácil de implementar. <br />
  77. 77. Protocolo Telnet<br />El protocolo Telnet se basa en tres conceptos básicos: <br />el paradigma Terminal virtual de red (NVT); <br />el principio de opciones negociadas; <br />las reglas de negociación. <br />Éste es un protocolo base, al que se le aplican otros protocolos del conjunto TCP/IP (FTP, SMTP, POP3, etc.). Las especificaciones Telnet no mencionan la autenticación porque Telnet se encuentra totalmente separado de las aplicaciones que lo utilizan (el protocolo FTP define una secuencia de autenticación sobre Telnet). Además, el protocolo Telnet no es un protocolo de transferencia de datos seguro, ya que los datos que transmite circulan en la red como texto sin codificar (de manera no cifrada)<br />
  78. 78. Protocolo Telnet<br />Telnet para conectar un host remoto a un equipo que funciona como servidor, a este protocolo se le asigna el puerto 23. <br />Excepto por las opciones asociadas y las reglas de negociación, las especificaciones del protocolo Telnet son básicas. La transmisión de datos a través de Telnet consiste sólo en transmitir bytes en el flujo TCP (el protocolo Telnet especifica que los datos deben agruparse de manera predeterminada —esto es, si ninguna opción especifica lo contrario— en un búfer antes de enviarse. Específicamente, esto significa que de manera predeterminada los datos se envían línea por línea). Cuando se transmite el byte 255, el byte siguiente debe interpretarse como un comando. <br />
  79. 79. Protocolo Telnet<br />Por lo tanto, el byte 255 se denomina IAC (Interpretar como comando). Los comandos se describen más adelante en este documento. <br />Las especificaciones básicas del protocolo Telnet se encuentran disponibles en la RFC (petición de comentarios) 854, mientras que las distintas opciones están descriptas en la RFC 855 hasta la RFC 861. <br />
  80. 80. Protocolo Telnet<br />
  81. 81. Protocolo Telnet<br />La noción de terminal virtual<br />Cuando surgió Internet, la red (ARPANET) estaba compuesta de equipos cuyas configuraciones eran muy poco homogéneas (teclados, juegos de caracteres, resoluciones, longitud de las líneas visualizadas). Además, las sesiones de los terminales también tenían su propia manera de controlar el flujo de datos entrante/saliente. <br />Por lo tanto, en lugar de crear adaptadores para cada tipo de terminal, para que pudiera haber interoperabilidad entre estos sistemas, se decidió desarrollar una interfaz estándar denominada NVT (Terminal virtual de red). <br />
  82. 82. Protocolo Telnet<br />Así, se proporcionó una base de comunicación estándar, compuesta de: <br />caracteres ASCII de 7 bits, a los cuales se les agrega el código ASCII extendido; <br />tres caracteres de control; <br />cinco caracteres de control opcionales; <br />un juego de señales de control básicas. <br />Por lo tanto, el protocolo Telnet consiste en crear una abstracción del terminal que permita a cualquier host (cliente o servidor) comunicarse con otro host sin conocer sus características. <br />
  83. 83. Protocolo Telnet<br />El principio de opciones negociadas<br />Las especificaciones del protocolo Telnet permiten tener en cuenta el hecho de que ciertos terminales ofrecen servicios adicionales, no definidos en las especificaciones básicas (pero de acuerdo con las especificaciones), para poder utilizar funciones avanzadas. Estas funcionalidades se reflejan como opciones. Por lo tanto, el protocolo Telnet ofrece un sistema de negociaciones de opciones que permite el uso de funciones avanzadas en forma de opciones, en ambos lados, al iniciar solicitudes para su autorización desde el sistema remoto. <br />
  84. 84. Protocolo Telnet<br />Las opciones de Telnet afectan por separado cada dirección del canal de datos. Entonces, cada parte puede negociar las opciones, es decir, definir las opciones que: <br />desea usar (DO); <br />se niega a usar (DON'T); <br />desea que la otra parte utilice (WILL); <br />se niega a que la otra parte utilice (WON'T). <br />De esta manera, cada parte puede enviar una solicitud para utilizar una opción. La otra parte debe responder si acepta o no el uso de la opción. Cuando la solicitud se refiere a la desactivación de una opción, el destinatario de la solicitud no debe rechazarla para ser completamente compatible con el modelo NVT. <br />
  85. 85. Protocolo Telnet<br />Existen 255 códigos de opción. De todas maneras, el protocolo Telnet proporciona un espacio de dirección que permite describir nuevas opciones. La RFC (petición de comentarios) 855 explica cómo documentar una nueva opción. <br />
  86. 86. Protocolo Telnet<br />Las reglas de negociación<br />Las reglas de negociación para las opciones permiten evitar situaciones de enrollo automático (por ejemplo, cuando una de las partes envía solicitudes de negociación de opciones a cada confirmación de la otra parte). <br />Las solicitudes sólo deben enviarse en el momento de un cambio de modo. <br />Cuando una de las partes recibe la solicitud de cambio de modo, sólo debe confirmar su recepción si todavía no se encuentra en el modo apropiado. <br />Sólo debe insertarse una solicitud en el flujo de datos en el lugar en el que surte efecto. <br />
  87. 87. Protocolo Telnet<br />Caracteres de control de salida<br />Los siguientes caracteres son comandos que permiten controlar la visualización del terminal virtual de red: <br />Así, se define el comando CRLF, compuesto de dos comandos CR y LF uno después del otro (en cualquier orden). Esto permite ubicar el cursor en el extremo izquierdo de la línea siguiente. <br />
  88. 88. Protocolo Telnet<br />Caracteres de control opcionales<br />Los caracteres anteriores son los únicos (entre los 128 caracteres del código ASCII básico y los 128 caracteres del código ASCII extendido) que tienen un significado particular para el terminal virtual de red. Los siguientes caracteres pueden tener un significado en un terminal virtual de red, pero no se utilizan necesariamente. <br />
  89. 89. Protocolo Telnet<br />
  90. 90. Protocolo Telnet<br />Caracteres de control de sesión<br />Los siguientes caracteres son comandos que permiten controlar la sesión Telnet. Para que puedan interpretarse como tal, estos comandos deben estar precedidos por el carácter de escape IAC (Interpretar como comando). Si estos bytes se transmiten sin estar precedidos por el carácter IAC, se procesarán como caracteres simples. Para transmitir el carácter IAC, este mismo debe estar precedido por un carácter de escape. En otras palabras, debe estar duplicado. <br />Los comandos relacionados con una negociación de opciones deben estar seguidos de un byte que especifique la opción. Estos comandos permiten interrumpir señales, eliminar información en el caché del terminal, etc. <br />
  91. 91. Protocolo Telnet<br />
  92. 92. Protocolo Telnet<br />
  93. 93. Protocolo HTTP<br />Introducción al protocolo HTTP<br />Desde 1990, el protocolo HTTP (Protocolo de transferencia de hipertexto) es el protocolo más utilizado en Internet. La versión 0.9 sólo tenía la finalidad de transferir los datos a través de Internet (en particular páginas Web escritas en HTML). La versión 1.0 del protocolo (la más utilizada) permite la transferencia de mensajes con encabezados que describen el contenido de los mensajes mediante la codificación MIME. <br />El propósito del protocolo HTTP es permitir la transferencia de archivos (principalmente, en formato HTML). entre un navegador (el cliente) y un servidor web (denominado, entre otros, httpd en equipos UNIX) localizado mediante una cadena de caracteres denominada dirección URL. <br />
  94. 94. Protocolo HTTP<br />Comunicación entre el navegador y el servidor<br />La comunicación entre el navegador y el servidor se lleva a cabo en dos etapas: <br />El navegador realiza una solicitud HTTP<br />El servidor procesa la solicitud y después envía una respuesta HTTP<br />
  95. 95. Protocolo HTTP<br />Protocolos TCP/IP<br />Ubicación de archivo<br />Solicitudes<br />Decodificación<br />Envío de<br /> encabezados HTTP<br />Envío de encabezados de respuesta HTTP<br />Creación de encabezados de formato<br />Servidor WEB<br />Cliente (Navegador)<br />
  96. 96. Protocolo HTTP<br />En realidad, la comunicación se realiza en más etapas si se considera el procesamiento de la solicitud en el servidor. Dado que sólo nos ocupamos del protocolo HTTP, no se explicará la parte del procesamiento en el servidor en esta sección del artículo. Si este tema les interesa, puede consultar el articulo sobre el tratamiento de CGI.<br />
  97. 97. Protocolo HTTP<br />Solicitud HTTP<br />Una solicitud HTTP es un conjunto de líneas que el navegador envía al servidor. Incluye: <br />Una línea de solicitud: es una línea que especifica el tipo de documento solicitado, el método que se aplicará y la versión del protocolo utilizada. La línea está formada por tres elementos que deben estar separados por un espacio: <br />el método<br />la dirección URL<br />la versión del protocolo utilizada por el cliente (por lo general, HTTP/1.0)<br />
  98. 98. Protocolo HTTP<br />Los campos del encabezado de solicitud: es un conjunto de líneas opcionales que permiten aportar información adicional sobre la solicitud y/o el cliente (navegador, sistema operativo, etc.). Cada una de estas líneas está formada por un nombre que describe el tipo de encabezado, seguido de dos puntos (:) y el valor del encabezado.<br />El cuerpo de la solicitud: es un conjunto de líneas opcionales que deben estar separadas de las líneas precedentes por una línea en blanco y, por ejemplo, permiten que se envíen datos por un comando POST durante la transmisión de datos al servidor utilizando un formulario. <br />
  99. 99. Protocolo HTTP<br />Por lo tanto, una solicitud HTTP posee la siguiente sintaxis (<crlf> significa retorno de carro y avance de línea): <br />MÉTODO VERSIÓN URL<crlf>ENCABEZADO: Valor<crlf>. . . ENCABEZADO: Valor<crlf>Línea en blanco <crlf>CUERPO DE LA SOLICITUD<br />A continuación se encuentra un ejemplo de una solicitud HTTP: <br />GET http://es.kioskea.net HTTP/1.0 Accept : Text/html If-Modified-Since : Saturday, 15-January-2000 14:37:11 GMT User-Agent : Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)<br />
  100. 100. Protocolo HTTP<br />
  101. 101.
  102. 102.
  103. 103. Respuesta HTTP<br />Una respuesta HTTP es un conjunto de líneas que el servidor envía al navegador. Está constituida por: Incluye: <br />Una línea de estado: es una línea que especifica la versión del protocolo utilizada y el estado de la solicitud en proceso mediante un texto explicativo y un código. La línea está compuesta por tres elementos que deben estar separados por un espacio: La línea está formada por tres elementos que deben estar separados por un espacio: <br />la versión del protocolo utilizada<br />el código de estado<br />el significado del código<br />
  104. 104. Los campos del encabezado de respuesta: es un conjunto de líneas opcionales que permiten aportar información adicional sobre la respuesta y/o el servidor. Cada una de estas líneas está compuesta por un nombre que califica el tipo de encabezado, seguido por dos puntos (:) y por el valor del encabezado Cada una de estas líneas está formada por un nombre que describe el tipo de encabezado, seguido de dos puntos (:) y el valor del encabezado.<br />El cuerpo de la respuesta: contiene el documento solicitado<br />
  105. 105. Por lo tanto, una respuesta HTTP posee la siguiente sintaxis (<crlf> significa retorno de carro y avance de línea): <br />VERSIÓN-HTTP CÓDIGO EXPLICACIÓN <crlf>ENCABEZADO: Valor<crlf>. . . ENCABEZADO: Valor<crlf>Línea en blanco <crlf>CUERPO DE LA RESPUESTA A continuación se encuentra un ejemplo de una respuesta HTTP: <br />HTTP/1.0 200 OK Date: Sat, 15 Jan 2000 14:37:12 GMT Server : Microsoft-IIS/2.0 Content-Type : text/HTML Content-Length : 1245 Last-Modified : Fri, 14 Jan 2000 08:25:13 GMT<br />
  106. 106.
  107. 107. Los códigos de respuesta<br />Son los códigos que se ven cuando el navegador no puede mostrar la página solicitada. El código de respuesta está formado por tres dígitos: el primero indica el estado y los dos siguientes explican la naturaleza exacta del error. <br />
  108. 108.
  109. 109.
  110. 110.
  111. 111.
  112. 112. Correo Electrónico<br />Introducción al correo electrónico<br />El correo electrónico es considerado el servicio más utilizado de Internet. Por lo tanto, la serie de protocolos TCP/IP ofrece una gama de protocolos que permiten una fácil administración del enrutamiento del correo electrónico a través de la red. <br />
  113. 113. Protocolo SMTP<br />El protocolo SMTP (Protocolo simple de transferencia de correo) es el protocolo estándar que permite la transferencia de correo de un servidor a otro mediante una conexión punto a punto. <br />Éste es un protocolo que funciona en línea, encapsulado en una trama TCP/IP. El correo se envía directamente al servidor de correo del destinatario. El protocolo SMTP funciona con comandos de textos enviados al servidor SMTP (al puerto 25 de manera predeterminada). A cada comando enviado por el cliente (validado por la cadena de caracteres ASCII CR/LF, que equivale a presionar la tecla Enter) le sigue una respuesta del servidor SMTP compuesta por un número y un mensaje descriptivo. <br />
  114. 114. Protocolo SMTP<br />A continuación se describe una situación en la que se realiza una solicitud para enviar correos a un servidor SMTP: <br />Al abrir la sesión SMTP, el primer comando que se envía es el comando HELO seguido por un espacio (escrito <SP>) y el nombre de dominio de su equipo (para decir "hola, soy este equipo"), y después validado por Enter (escrito <CRLF>). Desde abril de 2001, las especificaciones para el protocolo SMTP, definidas en RFC 2821, indican que el comando HELO sea remplazado por el comando EHLO. <br />El segundo comando es "MAIL FROM:" seguido de la dirección de correo electrónico del remitente. Si se acepta el comando, el servidor responde con un mensaje "250 OK". <br />
  115. 115. Protocolo SMTP<br />El siguiente comando es "RCPT TO:" seguido de la dirección de correo electrónico del destinatario. Si se acepta el comando, el servidor responde con un mensaje "250 OK". <br />El comando DATA es la tercera etapa para enviar un correo electrónico. Anuncia el comienzo del cuerpo del mensaje. Si se acepta el comando, el servidor responde con un mensaje intermediario numerado 354 que indica que puede iniciarse el envío del cuerpo del mensaje y considera el conjunto de líneas siguientes hasta el final del mensaje indicado con una línea que contiene sólo un punto. <br />
  116. 116. Protocolo SMTP<br />El cuerpo del correo electrónico eventualmente contenga algunos de los siguientes encabezados: <br />Date (Fecha)<br />Subject (Asunto)<br />Cc<br />Bcc (Cco)<br />From (De)<br />Si se acepta el comando, el servidor responde con un mensaje "250 OK". <br />
  117. 117. Protocolo SMTP<br />A continuación se describe un ejemplo de transacción entre un cliente (C) y un servidor SMTP (S): <br />S: 220 smtp.commentcamarche.net SMTP Ready C: EHLO machine1.commentcamarche.net S: 250 smtp.commentcamarche.net C: MAIL FROM:<webmaster@commentcamarche.net> S: 250 OK C: RCPT TO:<meandus@meandus.net> S: 250 C: RCPT TO:<tittom@tittom.fr> S: 550 No such user here C: DATA S: 354 Start mail input; end with <CRLF>.<CRLF> C: Subject: Hola C: Hola Meandus: C: ¿Cómo andan tus cosas? C: C: ¡Nos vemos pronto! C: <CRLF>.<CRLF> S: 250 C: QUIT R: 221 smtp.commentcamarche.net closing transmission<br />
  118. 118. Protocolo SMTP<br />Las especificaciones básicas del protocolo SMTP indican que todos los caracteres enviados están codificados mediante el código ASCII de 7 bits y que el 8º bit sea explícitamente cero. Por lo tanto, para enviar caracteres acentuados es necesario recurrir a algoritmos que se encuentren dentro de las especificaciones MIME: <br />base64 para archivos adjuntos <br />quoted-printable (abreviado QP) para caracteres especiales utilizados en el cuerpo del mensaje <br />Por lo tanto, es posible enviar un correo electrónico utilizando un simple telnet al puerto 25 del servidor SMTP: <br />telnet smtp.commentcamarche.net 25<br />(El servidor indicado anteriormente no existe. Intente reemplazar commentcamarche.net por el nombre de dominio de su proveedor de servicios de Internet. <br />
  119. 119. Protocolo SMTP<br />A continuación se brinda un resumen de los principales comandos SMTP: <br />
  120. 120. Protocolo POP<br />El protocolo POP (Protocolo de oficina de correos), como su nombre lo indica, permite recoger el correo electrónico en un servidor remoto (servidor POP). Es necesario para las personas que no están permanentemente conectadas a Internet, ya que así pueden consultar sus correos electrónicos recibidos sin que ellos estén conectados. <br />Existen dos versiones principales de este protocolo, POP2 y POP3, a los que se le asignan los puertos 109 y 110 respectivamente, y que funcionan utilizando comandos de texto radicalmente diferentes. <br />
  121. 121. Protocolo POP<br />Al igual que con el protocolo SMTP, el protocolo POP (POP2 y POP3) funciona con comandos de texto enviados al servidor POP. Cada uno de estos comandos enviados por el cliente (validados por la cadena CR/LF) está compuesto por una palabra clave, posiblemente acompañada por uno o varios argumentos, y está seguido por una respuesta del servidor POP compuesta por un número y un mensaje descriptivo. <br />
  122. 122. Protocolo POP<br />A continuación se brinda un resumen de los principales comandos POP2: <br />
  123. 123. Protocolo POP<br />A continuación se brinda un resumen de los principales comandos POP3<br />
  124. 124. Protocolo POP<br />
  125. 125. Protocolo POP<br />Por lo tanto, el protocolo POP3 administra la autenticación utilizando el nombre de usuario y la contraseña. Sin embargo, esto no es seguro, ya que las contraseñas, al igual que los correos electrónicos, circulan por la red como texto sin codificar (de manera no cifrada). En realidad, según RFC 1939, es posible cifrar la contraseña utilizando un algoritmo MD5 y beneficiarse de una autenticación segura. Sin embargo, debido a que este comando es opcional, pocos servidores lo implementan. Además, el protocolo POP3 bloquea las bandejas de entrada durante el acceso, lo que significa que es imposible que dos usuarios accedan de manera simultánea a la misma bandeja de entrada. <br />
  126. 126. Protocolo POP<br />De la misma manera que es posible enviar un correo electrónico utilizando telnet, también es posible acceder al correo entrante utilizando un simple telnet por el puerto del servidor POP (110 de manera predeterminada): <br />telnet mail.commentcamarche.net 110<br />(El servidor indicado anteriormente no existe. Intente reemplazar commentcamarche.net por el nombre de dominio de su proveedor de servicios de Internet.) <br />
  127. 127. Protocolo POP<br />S: +OK mail.commentcamarche.net POP3 service S: (Netscape Messaging Server 4.15 Patch 6 (built Mar 31 2001)) C: USER jeff S: +OK Name is a valid mailbox C: PASS password S: +OK Maildrop ready C: STAT S: +OK 2 0 C: TOP 1 5 S: Subject: Hola S: Hola Meandus: S: ¿Cómo andan tus cosas? S: S: ¡Nos vemos pronto! C: QUIT S: +OK<br />La visualización de datos que se obtiene depende del cliente Telnet que esté utilizando. Según su cliente Telnet, puede ser necesario activar la opción echo local (eco local).<br />
  128. 128. Protocolo IMAP<br />El protocolo IMAP (Protocolo de acceso a mensajes de Internet) es un protocolo alternativo al de POP3, pero que ofrece más posibilidades: <br />IMAP permite administrar diversos accesos de manera simultánea <br />IMAP permite administrar diversas bandejas de entrada <br />IMAP brinda más criterios que pueden utilizarse para ordenar los correos electrónicos <br />
  129. 129. FIN DEL TEMA<br />

×