Ejemplos de protocolos de red Capa 1: Nivel fsico o Cable coaxial o UTP categora 5, categoria 5e, categoria 6, categoria 6a Cable

de fibra ptica, Cable de par trenzado, Microondas, Radio, RS-232. Capa 2: Nivel de enlace de datos o Ethernet, Fast Ethernet, Gigabit Ethernet, Token Ring, FDDI, ATM, HDLC.,cdp Capa 3: Nivel de red o ARP, RARP, IP (IPv4, IPv6), X.25, ICMP, IGMP, NetBEUI, IPX, Appletalk. Capa 4: Nivel de transporte o TCP, UDP, SPX. Capa 5: Nivel de sesin o NetBIOS, RPC, SSL. Capa 6: Nivel de presentacin o ASN.1. Capa 7: Nivel de aplicacin o SNMP, SMTP, NNTP, FTP, SSH, HTTP, SMB/CIFS, NFS, Telnet, IRC, POP3, IMAP, LDAP. Protocolos comunes IP (Internet Protocol) UDP (User Datagram Protocol) TCP (Transmission Control Protocol) DHCP (Dynamic Host Configuration Protocol) HTTP (Hypertext Transfer Protocol) FTP (File Transfer Protocol) Telnet (Telnet Remote Protocol) SSH (Secure Shell Remote Protocol) POP3 (Post Office Protocol 3) SMTP (Simple Mail Transfer Protocol) IMAP (Internet Message Access Protocol) SOAP (Simple Object Access Protocol) PPP (Point-to-Point Protocol) STP (Spanning Tree Protocol) SUPER (Supreme Perpetued Resudict)

Protocolo de Internet Internet Protocol (IP) Familia: Funcin: Familia de protocolos de Internet Envo de paquetes de datos tanto a nivel local como a travs de redes. IPv6

ltima versin:

Ubicacin en la pila de protocolos Aplicacin http, ftp, DNS, ... Transporte TCP, UDP, ... Red IP Enlace Ethernet, Token Ring, FDDI, ...

Estndares:

RFC 791 (1981) RFC 2460 (IPv6, 1998)

El Protocolo de Internet (IP, de sus siglas en ingls Internet Protocol) es un protocolo no orientado a conexin usado tanto por el origen como por el destino para la comunicacin de datos a travs de una red de paquetes conmutados. Los datos en una red basada en IP son enviados en bloques conocidos como paquetes o datagramas (en el protocolo IP estos trminos se suelen usar indistintamente). En particular, en IP no se necesita ninguna configuracin antes de que un equipo intente enviar paquetes a otro con el que no se haba comunicado antes. El Protocolo de Internet provee un servicio de datagramas no fiable (tambin llamado del mejor esfuerzo (best effort), lo har lo mejor posible pero garantizando poco). IP no provee ningn mecanismo para determinar si un paquete alcanza o no su destino y nicamente proporciona seguridad (mediante checksums o sumas de comprobacin) de sus cabeceras y no de los datos transmitidos. Por ejemplo, al no garantizar nada sobre la recepcin del paquete, ste podra llegar daado, en otro orden con respecto a otros

paquetes, duplicado o simplemente no llegar. Si se necesita fiabilidad, sta es proporcionada por los protocolos de la capa de transporte, como TCP. Si la informacin a transmitir ("datagramas") supera el tamao mximo "negociado" (MTU) en el tramo de red por el que va a circular podr ser dividida en paquetes ms pequeos, y reensamblada luego cuando sea necesario. Estos fragmentos podrn ir cada uno por un camino diferente dependiendo de como estn de congestionadas las rutas en cada momento. Las cabeceras IP contienen las direcciones de las mquinas de origen y destino (direcciones IP), direcciones que sern usadas por los conmutadores de paquetes (switches) y los enrutadores (routers) para decidir el tramo de red por el que reenviarn los paquetes. El IP es el elemento comn en la Internet de hoy. El actual y ms popular protocolo de red es IPv4. IPv6 es el sucesor propuesto de IPv4; poco a poco Internet est agotando las direcciones disponibles por lo que IPv6 utiliza direcciones de fuente y destino de 128 bits (lo cual asigna a cada milmetro cuadrado de la superficie de la Tierra la colosal cifra de 670.000 millones de direcciones IP), muchas ms direcciones que las que provee IPv4 con 32 bits. Las versiones de la 0 a la 3 estn reservadas o no fueron usadas. La versin 5 fue usada para un protocolo experimental. Otros nmeros han sido asignados, usualmente para protocolos experimentales, pero no han sido muy extendidos.

User Datagram Protocol (Redirigido desde UDP) Saltar a navegacin, bsqueda Para otros usos de este trmino, vase UDP (desambiguacin). User Datagram Protocol (UDP) Familia: Funcin: Familia de protocolos de Internet Intercambio de datagramas a travs de una red.

Ubicacin en la pila de protocolos Aplicacin DNS, DHCP, NTP, ... Transporte UDP Red IP Enlace Ethernet, Token Ring, FDDI, ...

Estndares:

RFC 768 (1980)

User Datagram Protocol (UDP) es un protocolo del nivel de transporte basado en el intercambio de datagramas. Permite el envo de datagramas a travs de la red sin que se haya establecido previamente una conexin, ya que el propio datagrama incorpora suficiente informacin de direccionamiento en su cabecera. Tampoco tiene confirmacin ni control de flujo, por lo que los paquetes pueden adelantarse unos a otros; y tampoco se sabe si ha llegado correctamente, ya que no hay confirmacin de entrega o recepcin. Su uso principal es para protocolos como DHCP, BOOTP, DNS y dems protocolos en los que el intercambio de paquetes de la conexin/desconexin son mayores, o no son rentables con respecto a la informacin transmitida, as como para la transmisin de audio y vdeo en tiempo real, donde no es posible realizar retransmisiones por los estrictos requisitos de retardo que se tiene en estos casos. Descripcin tcnica [editar] User Datagram Protocol (UDP) es un protocolo mnimo de nivel de transporte orientado a mensajes documentado en el RFC 768 de la IETF. En la familia de protocolos de Internet UDP proporciona una sencilla interfaz entre la capa de red y la capa de aplicacin. UDP no otorga garantas para la

entrega de sus mensajes y el origen UDP no retiene estados de los mensajes UDP que han sido enviados a la red. UDP slo aade multiplexado de aplicacin y suma de verificacin de la cabecera y la carga til. Cualquier tipo de garantas para la transmisin de la informacin deben ser implementadas en capas superiores. + 0 Bits 0 - 15 Puerto origen 16 - 31 Puerto destino

32 Longitud del Mensaje Suma de verificacin 64 Datos

La cabecera UDP consta de 4 campos de los cuales 2 son opcionales (con fondo rojo en la tabla). Los campos de los puertos fuente y destino son campos de 16 bits que identifican el proceso de origen y recepcin. Ya que UDP carece de un servidor de estado y el origen UDP no solicita respuestas, el puerto origen es opcional. En caso de no ser utilizado, el puerto origen debe ser puesto a cero. A los campos del puerto destino le sigue un campo obligatorio que indica el tamao en bytes del datagrama UDP incluidos los datos. El valor mnimo es de 8 bytes. El campo de la cabecera restante es una suma de comprobacin de 16 bits que abarca la cabecera, los datos y una pseudocabecera con las IP origen y destino, el protocolo, la longitud del datagrama y 0's hasta completar un mltiplo de 16. pero no los datos. El checksum tambin es opcional, aunque generalmente se utiliza en la prctica. El protocolo UDP se utiliza por ejemplo cuando se necesita transmitir voz o vdeo y resulta ms importante transmitir con velocidad que garantizar el hecho de que lleguen absolutamente todos los bytes. Puertos [editar] UDP utiliza puertos para permitir la comunicacin entre aplicaciones. El campo de puerto tiene una longitud de 16 bits, por lo que el rango de valores vlidos va de 0 a 65.535. El puerto 0 est reservado, pero es un valor permitido como puerto origen si el proceso emisor no espera recibir mensajes como respuesta. Los puertos 1 a 1023 se llaman puertos "bien conocidos" y en sistemas operativos tipo Unix enlazar con uno de estos puertos requiere acceso como superusuario. Los puertos 1024 a 49.151 son puertos registrados. Los puertos 49.152 a 65.535 son puertos efmeros y son utilizados como puertos temporales, sobre todo por los clientes al comunicarse con los servidores.

Transmission Control Protocol

Transmission Control Protocol (TCP) Familia: Funcin: Familia de protocolos de Internet Transporte confiable y bidireccional de datos .

Ubicacin en la pila de protocolos Aplicacin ftp, http, SNMP, DNS, ... Transporte TCP Red IP Enlace Ethernet, Token Ring, FDDI, ...

Estndares:

RFC 793 (1981) RFC 1323 (1992)

TCP (Transmission-Control-Protocol, en espaol Protocolo de Control de Transmisin) es uno de los protocolos fundamentales en Internet. Fue creado entre los aos 1973 - 1974 por Vint Cerf y Robert Kahn. Muchos programas dentro de una red de datos compuesta por computadoras pueden usar TCP para crear conexiones entre ellos a travs de las cuales puede enviarse un flujo de datos. El protocolo garantiza que los datos sern entregados en su destino sin errores y en el mismo orden en que se transmitieron. Tambin proporciona un mecanismo para distinguir distintas aplicaciones dentro de una misma mquina, a travs del concepto de puerto. TCP da soporte a muchas de las aplicaciones ms populares de Internet, incluidas HTTP, SMTP, SSH y FTP. Informacin Tcnica [editar] TCP es un protocolo de comunicacin orientado a conexin y fiable del nivel de transporte, actualmente documentado por IETF en el RFC 793. Es un protocolo de capa 4 segn el modelo OSI.

Funciones de TCP [editar] En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de internet (IP) y la aplicacin. Habitualmente, las aplicaciones necesitan que la comunicacin sea fiable y, dado que la capa IP aporta un servicio de datagramas no fiable (sin confirmacin), TCP aade las funciones necesarias para prestar un servicio que permita que la comunicacin entre dos sistemas se efecte libre de errores, sin prdidas y con seguridad. Los servicios provistos por TCP corren en el anfitrin (host) de cualquiera de los extremos de una conexin, no en la red. Por lo tanto, TCP es un protocolo para manejar conexiones de extremo a extremo. Tales conexiones pueden existir a travs de una serie de conexiones punto a punto, por lo que estas conexiones extremo-extremo son llamadas circuitos virtuales. Las caractersticas del TCP son: Orientado a la conexin: dos computadoras establecen una conexin para intercambiar datos. Los sistemas de los extremos se sincronizan con el otro para manejar el flujo de paquetes y adaptarse a la congestin de la red. Operacin Full-Duplex: una conexin TCP es un par de circuitos virtuales, cada uno en una direccin. Slo los dos sistemas finales sincronizados pueden usar la conexin. Error Checking: una tcnica de checksum es usada para verificar que los paquetes no estn corruptos. Acknowledgements: sobre recibo de uno o ms paquetes, el receptor regresa un acknowledgement (reconocimiento) al transmisor indicando que recibi los paquetes. Si los paquetes no son notificados, el transmisor puede reenviar los paquetes o terminar la conexin si el transmisor cree que el receptor no est ms en la conexin. Flow Control: si el transmisor est desbordando el buffer del receptor por transmitir demasiado rpido, el receptor descarta paquetes. Los acknowledgement fallidos que llegan al transmisor le alertan para bajar la tasa de transferencia o dejar de transmitir. Servicio de recuperacin de Paquetes: el receptor puede pedir la retransmisin de un paquete. Si el paquete no es notificado como recibido (ACK), el transmisor enva de nuevo el paquete. Los servicios confiables de entrega de datos son crticos para aplicaciones tales como transferencias de archivos (FTP por ejemplo), servicios de bases de datos, proceso de transacciones y otras aplicaciones de misin crtica en las cuales la entrega de cada paquete debe ser garantizada. Formato de los Segmentos TCP [editar]

En el nivel de transporte, los paquetes de bits que constituyen las unidades de datos de protocolo o PDU ('Protocol Data Unit') se llaman "segmentos". El formato de los segmentos TCP se muestra en el siguiente esquema: Bits 0 3

4-7

8 - 15

16 - 31

0 32 64

Puerto Origen Nmero de Secuencia

Puerto Destino

Nmero de Acuse de Recibo (ACK) longitud cabecera Reservado TCP

96

Flags

Ventana

128 160

Suma de Verificacin (Checksum)

Puntero Urgente

Opciones + Relleno (opcional)

224

Datos

Las aplicaciones envan flujos de bytes a la capa TCP para ser enviados a la red. TCP divide el flujo de bytes llegado de la aplicacin en segmentos de tamao apropiado (normalmente esta limitacin viene impuesta por la unidad mxima de transferencia (MTU) del nivel de enlace de datos de la red a la que la entidad est asociada) y le aade sus cabeceras. Entonces, TCP pasa el segmento resultante a la capa IP, donde a travs de la red, llega a la capa TCP de la entidad destino. TCP comprueba que ningn segmento se ha perdido dando a cada uno un nmero de secuencia, que es tambin usado para asegurarse de que los paquetes han llegado a la entidad destino en el orden correcto. TCP devuelve un asentimiento por bytes que han sido recibidos correctamente; un temporizador en la entidad origen del envo causar un timeout si el asentimiento no es recibido en un tiempo razonable, y el (presuntamente desaparecido) paquete ser entonces retransmitido. TCP revisa que no haya bytes daados durante el envo usando un checksum; es calculado por el emisor en cada paquete antes de ser enviado, y comprobado por el receptor. Puerto de origen (16 bits): Identifica el puerto a travs del que se enva.

Puerto destino (16 bits): Identifica el puerto del receptor. Nmero de secuencia (32 bits): Sirve para comprobar que ningn segmento se ha perdido, y que llegan en el orden correcto. Su significado vara dependiendo del valor de SYN: Si el flag SYN est activo (1), entonces este campo indica el nmero inicial de secuencia (con lo cual el nmero de secuencia del primer byte de datos ser este nmero de secuencia ms uno). Si el flag SYN no est activo (0), entonces este campo indica el nmero de secuencia del primer byte de datos. Nmero de acuse de recibo (ACK) (32 bits): Si el flag ACK est puesto a activo, entonces en este campo contiene el nmero de secuencia del siguiente paquete que el receptor espera recibir. Longitud de la cabecera TCP (4 bits): Especifica el tamao de la cabecera TCP en palabras de 32-bits. El tamao mnimo es de 5 palabras, y el mximo es de 15 palabras (lo cual equivale a un tamao mnimo de 20 bytes y a un mximo de 60 bytes). En ingls el campo se denomina Data offset, que literalmente sera algo as como desplazamiento hasta los datos, ya que indica cuntos bytes hay entre el inicio del paquete TCP y el inicio de los datos. Reservado (4 bits): Bits reservados para uso futuro, deberan ser puestos a cero. Bits de control (flags) (8 bits): Son 8 flags o banderas. Cada una indica activa con un 1 o inactiva con un 0. CWR o Congestion Window Reduced (1 bit): Este flag se activa (se pone a 1) por parte del emisor para indicar que ha recibido un paquete TCP con el flag ECE activado. El flag ECE es una extensin del protocolo que fue aadida a la cabecera en el RFC 3168. Se utiliza para el control de la congestin en la red. ECE o ECN-Echo (1 bit): Indica que el receptor puede realizar notificaciones ECN. La activacin de este flag se realiza durante la negociacin en tres pasos para el establecimiento de la conexin. Este flag tambin fue aadido a la cabecera en el RFC 3168. URG o urgent (1 bit, ver URG): Si est activo significa que el campo Urgente es significativo, si no, el valor de este campo es ignorado. ACK o acknowledge (1 bit, ver ACK): Si est activo entonces el campo con el nmero de acuse de recibo es vlido (si no, es ignorado). PSH o push (1 bit, ver PSH): Activa/desactiva la funcin que hace que los datos de ese segmento y los datos que hayan sido almacenados anteriormente en el buffer del receptor deben ser transferidos a la aplicacin receptora lo antes posible. RST o reset (1 bit, ver Flag RST): Si llega a 1, termina la conexin sin esperar respuesta.

SYN o synchronize (1 bit, ver SYN): Activa/desactiva la sincronizacin de los nmeros de secuencia. FIN (1 bit, ver FIN): Si se activa es porque no hay ms datos a enviar por parte del emisor, esto es, el paquete que lo lleva activo es el ltimo de una conexin. Ventana (16 bits): Es el tamao de la ventana de recepcin, que especifica el nmero de bytes que el receptor est actualmente esperando recibir. Suma de verificacin (checksum) (16 bits): Es una suma de verificacin utilizada para comprobar si hay errores tanto en la cabecera como en los datos. Puntero urgente (16 bits): Si el flag URG est activado, entonces este campo indica el desplazamiento respecto al nmero de secuencia que indica el ltimo byte de datos marcados como urgentes. Opciones (nmero de bits variable): La longitud total del campo de opciones ha de ser mltiplo de una palabra de 32 bits (si es menor, se ha de rellenar al mltiplo ms cercano), y el campo que indica la longitud de la cabecera ha de estar ajustado de forma adecuada. Datos (nmero de bits variable): No forma parte de la cabecera, es la carga (payload), la parte con los datos del paquete TCP. Pueden ser datos de cualquier protocolo de nivel superior en el nivel de aplicacin; los protocolos ms comunes para los que se usan los datos de un paquete TCP son HTTP, telnet, SSH, FTP, etctera. Funcionamiento del protocolo en detalle Las conexiones TCP se componen de tres etapas: establecimiento de conexin, transferencia de datos y fin de la conexin. Para establecer la conexin se usa el procedimiento llamado negociacin en tres pasos (3-way handshake). Una negociacin en cuatro pasos (4-way handshake) es usada para la desconexin. Durante el establecimiento de la conexin, algunos parmetros como el nmero de secuencia son configurados para asegurar la entrega ordenada de los datos y la robustez de la comunicacin. Establecimiento de la conexin (negociacin en tres pasos)

Negociacin en tres pasos o Three-way handshake Aunque es posible que un par de entidades finales comiencen una conexin entre ellas simultneamente, normalmente una de ellas abre un socket en un determinado puerto tcp y se queda a la escucha de nuevas conexiones. Es comn referirse a esto como apertura pasiva, y determina el lado servidor de una conexin. El lado cliente de una conexin realiza una apertura activa de un puerto enviando un paquete SYN inicial al servidor como parte de la negociacin en tres pasos. En el lado del servidor se comprueba si el puerto est abierto, es decir, si existe algn proceso escuchando en ese puerto. En caso de no estarlo, se enva al cliente un paquete de respuesta con el bit RST activado, lo que significa el rechazo del intento de conexin. En caso de que s se encuentre abierto el puerto, el lado servidor respondera a la peticin SYN vlida con un paquete SYN/ACK. Finalmente, el cliente debera responderle al servidor con un ACK, completando as la negociacin en tres pasos (SYN, SYN/ACK y ACK) y la fase de establecimiento de conexin. Es interesante notar que existe un nmero de secuencia generado por cada lado, ayudando de este modo a que no se puedan establecer conexiones falseadas (spoofing). Transferencia de datos Durante la etapa de transferencia de datos, una serie de mecanismos claves determinan la fiabilidad y robustez del protocolo. Entre ellos estn incluidos el uso del nmero de secuencia para ordenar los segmentos TCP recibidos y detectar paquetes duplicados, checksums para detectar errores, y asentimientos y temporizadores para detectar prdidas y retrasos. Durante el establecimiento de conexin TCP, los nmeros iniciales de secuencia son intercambiados entre las dos entidades TCP. Estos nmeros de

secuencia son usados para identificar los datos dentro del flujo de bytes, y poder identificar (y contar) los bytes de los datos de la aplicacin. Siempre hay un par de nmeros de secuencia incluidos en todo segmento TCP, referidos al nmero de secuencia y al nmero de asentimiento. Un emisor TCP se refiere a su propio nmero de secuencia cuando habla de nmero de secuencia, mientras que con el nmero de asentimiento se refiere al nmero de secuencia del receptor. Para mantener la fiabilidad, un receptor asiente los segmentos TCP indicando que ha recibido una parte del flujo continuo de bytes. Una mejora de TCP, llamada asentimiento selectivo (SACK, Selective Acknowledgement) permite a un receptor TCP asentir los datos que se han recibido de tal forma que el remitente solo retransmita los segmentos de datos que faltan. A travs del uso de nmeros de secuencia y asentimiento, TCP puede pasar los segmentos recibidos en el orden correcto dentro del flujo de bytes a la aplicacin receptora. Los nmeros de secuencia son de 32 bits (sin signo), que vuelve a cero tras el siguiente byte despus del 2 32-1. Una de las claves para mantener la robustez y la seguridad de las conexiones TCP es la seleccin del nmero inicial de secuencia (ISN, Initial Sequence Number). Un checksum de 16 bits, consistente en el complemento a uno de la suma en complemento a uno del contenido de la cabecera y datos del segmento TCP, es calculado por el emisor, e incluido en la transmisin del segmento. Se usa la suma en complemento a uno porque el acarreo final de ese mtodo puede ser calculado en cualquier mltiplo de su tamao (16-bit, 32-bit, 64-bit...) y el resultado, una vez plegado, ser el mismo. El receptor TCP recalcula el checksum sobre las cabeceras y datos recibidos. El complemento es usado para que el receptor no tenga que poner a cero el campo del checksum de la cabecera antes de hacer los clculos, salvando en algn lugar el valor del checksum recibido; en vez de eso, el receptor simplemente calcula la suma en complemento a uno con el checksum incluido, y el resultado debe ser igual a 0. Si es as, se asume que el segmento ha llegado intacto y sin errores. Hay que fijarse en que el checksum de TCP tambin cubre los 96 bit de la cabecera que contiene la direccin origen, la direccin destino, el protocolo y el tamao TCP. Esto proporciona proteccin contra paquetes mal dirigidos por errores en las direcciones. El checksum de TCP es una comprobacin bastante dbil. En niveles de enlace con una alta probabilidad de error de bit quiz requiera una capacidad adicional de correccin/deteccin de errores de enlace. Si TCP fuese rediseado hoy, muy probablemente tendra un cdigo de redundancia cclica (CRC) para control de errores en vez del actual checksum. La debilidad del checksum est parcialmente compensada por el extendido uso de un CRC en el nivel de enlace, bajo TCP e IP, como el usado en el PPP o en Ethernet. Sin embargo, esto no significa que el checksum de 16 bits es redundante: sorprendentemente, inspecciones sobre el trfico de Internet han mostrado que son comunes los errores de software y hardware [cita requerida] que introducen errores en los paquetes protegidos con un CRC, y que el checksum de 16 bits de TCP detecta la mayora de estos errores simples.

Los asentimientos (ACKs o Acknowledgments) de los datos enviados o la falta de ellos, son usados por los emisores para interpretar las condiciones de la red entre el emisor y receptor TCP. Unido a los temporizadores, los emisores y receptores TCP pueden alterar el comportamiento del movimiento de datos. TCP usa una serie de mecanismos para conseguir un alto rendimiento y evitar la congestin de la red (la idea es enviar tan rpido como el receptor pueda recibir). Estos mecanismos incluyen el uso de ventana deslizante, que controla que el transmisor mande informacin dentro de los lmites del buffer del receptor, y algoritmos de control de flujo, tales como el algoritmo de Evitacin de la Congestin (congestion avoidance), el de comienzo lento (Slow-start), el de retransmisin rpida, el de recuperacin rpida (Fast Recovery), y otros. Tamao de ventana TCP El tamao de la ventana de recepcin TCP es la cantidad de datos recibidos (en bytes) que pueden ser metidos en el buffer de recepcin durante la conexin. La entidad emisora puede enviar una cantidad determinada de datos pero antes debe esperar un asentimiento con la actualizacin del tamao de ventana por parte del receptor. Un ejemplo sera el siguiente: un receptor comienza con un tamao de ventana x y recibe y bytes, entonces su tamao de ventana ser (x - y) y el transmisor slo podr mandar paquetes con un tamao mximo de datos de (x - y) bytes. Los siguientes paquetes recibidos seguirn restando tamao a la ventana de recepcin. Esta situacin seguir as hasta que la aplicacin receptora recoja los datos del buffer de recepcin. Escalado de ventana Para una mayor eficiencia en redes de gran ancho de banda, debe ser usado un tamao de ventana mayor. El campo TCP de tamao de ventana controla el movimiento de datos y est limitado a 16 bits, es decir, a un tamao de ventana de 65.535 bytes. Como el campo de ventana no puede expandirse se usa un factor de escalado. La escala de ventana TCP (TCP window scale) es una opcin usada para incrementar el mximo tamao de ventana desde 65.535 bytes, a 1 Gigabyte. La opcin de escala de ventana TCP es usada solo durante la negociacin en tres pasos que constituye el comienzo de la conexin. El valor de la escala representa el nmero de bits desplazados a la izquierda de los 16 bits que forman el campo del tamao de ventana. El valor de la escala puede ir desde 0 (sin desplazamiento) hasta 14. Hay que recordar que un nmero binario desplazado un bit a la izquierda es como multiplicarlo en base decimal por 2. Fin de la conexin

Cierre de una conexin segn el estndar La fase de finalizacin de la conexin usa una negociacin en cuatro pasos (four-way handshake), terminando la conexin desde cada lado independientemente. Cuando uno de los dos extremos de la conexin desea parar su "mitad" de conexin transmite un paquete FIN, que el otro interlocutor asentir con un ACK. Por tanto, una desconexin tpica requiere un par de segmentos FIN y ACK desde cada lado de la conexin. Una conexin puede estar "medio abierta" en el caso de que uno de los lados la finalice pero el otro no. El lado que ha dado por finalizada la conexin no puede enviar ms datos pero la otra parte si podr. Puertos TCP [editar] TCP usa el concepto de nmero de puerto para identificar a las aplicaciones emisoras y receptoras. Cada lado de la conexin TCP tiene asociado un nmero de puerto (de 16 bits sin signo, con lo que existen 65536 puertos posibles) asignado por la aplicacin emisora o receptora. Los puertos son clasificados en tres categoras: bien conocidos, registrados y dinmicos/privados. Los puertos bien conocidos son asignados por la Internet Assigned Numbers Authority (IANA), van del 0 al 1023 y son usados normalmente por el sistema o por procesos con privilegios. Las aplicaciones que usan este tipo de puertos son ejecutadas como servidores y se quedan a la escucha de conexiones. Algunos ejemplos son: FTP (21), SSH (22), Telnet (23), SMTP (25) y HTTP (80). Los puertos registrados son normalmente empleados por las aplicaciones de usuario de forma temporal cuando conectan con los servidores, pero tambin pueden representar servicios que hayan sido registrados por un tercero (rango de puertos registrados: 1024 al 49151). Los puertos dinmicos/privados tambin pueden ser usados por las aplicaciones de usuario, pero este caso es menos comn. Los puertos dinmicos/privados no tienen significado fuera de la conexin TCP en la que fueron usados (rango de puertos dinmicos/privados: 49152 al 65535, recordemos que el rango total de 2 elevado a la potencia 16, cubre 65536 nmeros, del 0 al 65535) Desarrollo de TCP [editar]

TCP es un protocolo muy desarrollado y complejo. Sin embargo, mientras mejoras significativas han sido propuestas y llevadas a cabo a lo largo de los aos, ha conservado las operaciones ms bsicas sin cambios desde el RFC 793, publicado en 1981. El documento RFC 1122 (Host Requirements for Internet Hosts), especifica el nmero de requisitos de una implementacin del protocolo TCP. El RFC 2581 (Control de Congestin TCP) es uno de los ms importantes documentos relativos a TCP de los ltimos aos, describe nuevos algoritmos para evitar la congestin excesiva. En 2001, el RFC 3168 fue escrito para describir la Notificacin de Congestin Explcita (ECN), una forma de eludir la congestin con mecanismos de sealizacin. En los comienzos del siglo XXI, TCP es usado en el 95% de todos los paquetes que circulan por Internet. Entre las aplicaciones ms comunes que usan TCP estn HTTP/HTTPS (World Wide Web), SMTP/POP3/IMAP (correo electrnico) y FTP (transferencia de ficheros). Su amplia extensin ha sido la prueba para los desarrolladores originales de que su creacin estaba excepcionalmente bien hecha. Recientemente, un nuevo algoritmo de control de congestin fue desarrollado y nombrado como FAST TCP (Fast Active queue management Scalable Transmission Control Protocol) por los cientficos de Caltech (California Institute of Technology). Es similar a TCP Vegas en cuanto a que ambos detectan la congestin a partir de los retrasos en las colas que sufren los paquetes al ser enviados a su destino. Todava hay un debate abierto sobre si ste es un sntoma apropiado para el control de la congestin.

Dynamic Host Configuration Protocol Dynamic Host Configuration Protocol (DHCP) Familia: Funcin: Puertos: Familia de protocolos de Internet Configuracin automtica de parmetros de red 67/UDP (Servidor) 68/UDP (Cliente) Ubicacin en la pila de protocolos Aplicacin DHCP Transporte UDP Red IP Estndares: RFC 2131 (1997)

DHCP (sigla en ingls de Dynamic Host Configuration Protocol - Protocolo Configuracin Dinmica de Servidor) es un protocolo de red que permite a los nodos de una red IP obtener sus parmetros de configuracin automticamente. Se trata de un protocolo de tipo cliente/servidor en el que generalmente un servidor posee una lista de direcciones IP dinmicas y las va asignando a los clientes conforme stas van estando libres, sabiendo en todo momento quin ha estado en posesin de esa IP, cunto tiempo la ha tenido y a quin se la ha asignado despus. Caractersticas Provee los parmetros de configuracin a las computadoras conectadas a la red informtica con la pila de protocolos TCP/IP (Mscara de red, puerta de enlace y otros) y tambin incluyen mecanismos de asignacin de direcciones IP. Este protocolo se public en octubre de 1993, estando documentado actualmente en la RFC 2131. Para IPv6 se publica el RFC 3315. Asignacin de direcciones IP Sin DHCP, cada direccin IP debe configurarse manualmente en cada computadora y, si la computadora se mueve a otra subred, se debe configurar otra direccin IP diferente. El DHCP le permite al administrador supervisar y distribuir de forma centralizada las direcciones IP necesarias y,

automticamente, asignar y enviar una nueva IP si fuera el caso en la computadora es conectada en un lugar diferente de la red. El protocolo DHCP incluye tres mtodos de asignacin de direcciones IP: Asignacin manual o esttica: Asigna una direccin IP a una mquina determinada. Se suele utilizar cuando se quiere controlar la asignacin de direccin IP a cada cliente, y evitar, tambin, que se conecten clientes no identificados. Asignacin automtica: Asigna una direccin IP de forma permanente a una mquina cliente la primera vez que hace la solicitud al servidor DHCP y hasta que el cliente la libera. Se suele utilizar cuando el nmero de clientes no vara demasiado. Asignacin dinmica: el nico mtodo que permite la reutilizacin dinmica de las direcciones IP. El administrador de la red determina un rango de direcciones IP y cada computadora conectada a la red est configurada para solicitar su direccin IP al servidor cuando la tarjeta de interfaz de red se inicializa. El procedimiento usa un concepto muy simple en un intervalo de tiempo controlable. Esto facilita la instalacin de nuevas mquinas clientes a la red.

Algunas implementaciones de DHCP pueden actualizar el DNS asociado con los servidores para reflejar las nuevas direcciones IP mediante el protocolo de actualizacin de DNS establecido en RFC 2136 (Ingls). El DHCP es una alternativa a otros protocolos de gestin de direcciones IP de red, como el BOOTP (Bootstrap Protocol). DHCP es un protocolo ms avanzado, pero ambos son los usados normalmente. En Windows 98 o posterior, cuando el DHCP es incapaz de asignar una direccin IP, se utiliza un proceso llamado "Automatic Private Internet Protocol Addressing". Parmetros configurables Un servidor DHCP puede proveer de una configuracin opcional a la computadora cliente. Dichas opciones estn definidas en RFC 2132 (Ingls) Lista de opciones configurables: Direccin del servidor DNS Nombre DNS Puerta de enlace de la direccin IP Direccin de Publicacin Masiva (broadcast address) Mscara de subred

Tiempo mximo de espera del ARP (Protocolo de Resolucin de Direcciones segn siglas en ingls) MTU (Unidad de Transferencia Mxima segn siglas en ingls) para la interfaz Servidores NIS (Servicio de Informacin de Red segn siglas en ingls) Dominios NIS Servidores NTP (Protocolo de Tiempo de Red segn siglas en ingls)) Servidor SMTP Servidor TFTP Nombre del servidor WINS Implementaciones Microsoft introdujo el DHCP en sus Servidores NT con la versin 3.5 de Windows NT a finales de 1994. A pesar de que la llamaron una nueva funcin no fue inventada por ellos. El Consorcio de Software de Internet (ISC: Internet Software Consortium) public distribuciones de DHCP para Unix con la versin 1.0.0 del ISC DHCP Server el 6 de diciembre de 1997 y una versin (2.0) que se adaptaba mejor al RFC el da 22 de junio de 1999. Se puede encontrar el software en http://www.isc.org/sw/dhcp/ Otras implementaciones importantes incluyen: Cisco: un servidor DHCP habilitado en Cisco IOS 12.0 en el mes de febrero de 1999 Sun: aadi el soporte para DHCP a su sistema operativo Solaris el 8 de julio de 2001. Adems, varios routers incluyen soporte DHCP para redes de hasta 255 computadoras.

Anatoma del protocolo

Esquema de una sesin tpica DHCP (Autoridad de Nmeros Asignados en Internet segn siglas en ingls) en BOOTP: 67/UDP para las computadoras servidor y 68/UDP para los clientes. DHCP Discovery [editar] El cliente enva un paquete DHCPDISCOVER. Las direcciones IP origen y destino de dicho paquete sern 0.0.0.0 y 255.255.255.255 (broadcast) respectivamente. El servidor almacena los campos del paquete CHADDR (direccin Ethernet origen, MAC) y el de identificacin del cliente.

Hypertext Transfer Protocol

Hyper text Transfer Protocol (HTTP) Familia: Funcin: ltima versin: Puertos: Familia de protocolos de Internet Transferencia de hipertexto 1.2 80/TCP

Ubicacin en la pila de protocolos Aplicacin HTTP Transporte TCP Red IP

El protocolo de transferencia de hipertexto (HTTP, HyperText Transfer Protocol) es el protocolo usado en cada transaccin de la Web (WWW). HTTP fue desarrollado por el consorcio W3C y la IETF, colaboracin que culmin en 1999 con la publicacin de una serie de RFC, siendo el ms importante de ellos el RFC 2616, que especifica la versin 1.1. HTTP define la sintaxis y la semntica que utilizan los elementos software de la arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema peticin-respuesta entre un cliente y un servidor. Al cliente que efecta la peticin (un navegador o un spider) se lo conoce como "user agent" (agente del usuario). A la informacin transmitida se la llama recurso y se la identifica mediante un URL. Los recursos pueden ser archivos, el resultado de la ejecucin de un programa, una consulta a una base de datos, la traduccin automtica de un documento, etc. HTTP es un protocolo sin estado, es decir, que no guarda ninguna informacin sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es informacin que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la nocin de "sesin", y tambin permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado. Transacciones HTTP

Una transaccin HTTP est formada por un encabezado seguido, opcionalmente, por una lnea en blanco y algn dato. El encabezado especificar cosas como la accin requerida del servidor, o el tipo de dato retornado, o el cdigo de estado. El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al protocolo. Estos campos permiten que se enve informacin descriptiva en la transaccin, permitiendo as la autenticacin, cifrado e identificacin de usuario. Un encabezado es un bloque de datos que precede a la informacin propiamente dicha, por lo que muchas veces se hace referencia a l como metadato porque tiene datos sobre los datos. Si se reciben lneas de encabezado del cliente, el servidor las coloca en las variables de ambiente de CGI con el prefijo HTTP_ seguido del nombre del encabezado. Cualquier carcter guin ( - ) del nombre del encabezado se convierte a caracteres "_". El servidor puede excluir cualquier encabezado que ya est procesado, como Authorization, Content-type y Content-length. El servidor puede elegir excluir alguno o todos los encabezados si incluirlos excede algn lmite del ambiente de sistema. Ejemplos de esto son las variables HTTP_ACCEPT y HTTP_USER_AGENT. HTTP_ACCEPT . Los tipos MIME que el cliente aceptar, dado los encabezados HTTP. Otros protocolos quizs necesiten obtener esta informacin de otro lugar. Los elementos de esta lista deben estar separados por una coma, como lo dice la especificacin HTTP: tipo, tipo. HTTP_USER_AGENT . El navegador que utiliza el cliente para realizar la peticin. El formato general para esta variable es: software/versin biblioteca/versin. El servidor enva al cliente: Un cdigo de estado que indica si la peticin fue correcta o no. Los cdigos de error tpicos indican que el archivo solicitado no se encontr, que la peticin no se realiz de forma correcta o que se requiere autenticacin para acceder al archivo. La informacin propiamente dicha. Como HTTP permite enviar documentos de todo tipo y formato, es ideal para transmitir multimedia, como grficos, audio y video. Esta libertad es una de las mayores ventajas de HTTP. Informacin sobre el objeto que se retorna. Ten en cuenta que la lista no es una lista completa de los campos de encabezado y que algunos de ellos slo tienen sentido en una direccin. Versiones

HTTP ha pasado por mltiples versiones del protocolo, muchas de las cuales son compatibles con las anteriores. El RFC 2145 describe el uso de los nmeros de versin de HTTP. El cliente le dice al servidor al principio de la peticin la versin que usa, y el servidor usa la misma o una anterior en su respuesta. 0.9 Obsoleta. Soporta slo un comando, GET, y adems no especifica el nmero de versin HTTP. No soporta cabeceras. Como esta versin no soporta POST, el cliente no puede enviarle mucha informacin al servidor. HTTP/1.0 (mayo 1996) Esta es la primera revisin del protocolo que especifica su versin en las comunicaciones, y todava se usa ampliamente, sobre todo en servidores proxy. HTTP/1.1 (junio 1999)1 2 Versin actual; las conexiones persistentes estn activadas por defecto y funcionan bien con los proxies. Tambin permite al cliente enviar mltiples peticiones a la vez (pipelining) lo que hace posible eliminar el tiempo de Round-Trip delay por cada peticin. HTTP/1.2 Los primeros borradores de 1995 del documento PEP an Extension Mechanism for HTTP (el cul propone el Protocolo de Extensin de Protocolo, abreviado PEP) los hizo el World Wide Web Consortium y se envi al Internet Engineering Task Force. El PEP inicialmente estaba destinado a convertirse en un rango distintivo de HTTP/1.2. 3 En borradores posteriores, sin embargo, se elimin la referencia a HTTP/1.2. El RFC 2774 (experimental), HTTP Extension Framework, incluye en gran medida a PEP. Se public en febrero de 2000.

PROTOCOLO TELNET Telnet Familia: Funcin: Puertos: Familia de protocolos de Internet Protocolo cliente/servidor 23/TCP

Ubicacin en la pila de protocolos Aplicacin Telnet Transporte TCP Red IP Telnet (TELecommunication NETwork) es el nombre de un protocolo de red (y del programa informtico que implementa el cliente), que sirve para acceder mediante una red a otra mquina, para manejarla remotamente como si estuviramos sentados delante de ella. Para que la conexin funcione, como en todos los servicios de Internet, la mquina a la que se acceda debe tener un programa especial que reciba y gestione las conexiones. El puerto que se utiliza generalmente es el 23. Funcionamiento Telnet slo sirve para acceder en modo terminal, es decir, sin grficos, pero fue una herramienta muy til para arreglar fallos a distancia, sin necesidad de estar fsicamente en el mismo sitio que la mquina que los tena. Tambin se usaba para consultar datos a distancia, como datos personales en mquinas accesibles por red, informacin bibliogrfica, etc. Aparte de estos usos, en general telnet se ha utilizado (y an hoy se puede utilizar en su variante SSH) para abrir una sesin con una mquina UNIX, de modo que mltiples usuarios con cuenta en la mquina, se conectan, abren sesin y pueden trabajar utilizando esa mquina. Es una forma muy usual de trabajar con sistemas UNIX. Problemas de seguridad y SSH Su mayor problema es de seguridad, ya que todos los nombres de usuario y contraseas necesarias para entrar en las mquinas viajan por la red como texto plano (cadenas de texto sin cifrar). Esto facilita que cualquiera que espe el trfico de la red pueda obtener los nombres de usuario y contraseas, y as acceder l tambin a todas esas mquinas. Por esta razn dej de usarse, casi totalmente, hace unos aos, cuando apareci y se populariz el SSH, que

puede describirse como una versin cifrada de telnet -actualmente se puede cifrar toda la comunicacin del protocolo durante el establecimiento de sesin (RFC correspondiente, en ingls- si cliente y servidor lo permiten, aunque no se tienen ciertas funcionalidad extra disponibles en SSH). Telnet en la actualidad Hoy en da este protocolo tambin se usa para acceder a los BBS, que inicialmente eran accesibles nicamente con un mdem a travs de la lnea telefnica. Para acceder a un BBS mediante telnet es necesario un cliente que d soporte a grficos ANSI y protocolos de transferencia de ficheros. Los grficos ANSI son muy usados entre los BBS. Con los protocolos de transferencia de ficheros (el ms comn y el que mejor funciona es el ZModem) podrs enviar y recibir ficheros del BBS, ya sean programas o juegos o ya sea el correo del BBS (correo local, de FidoNet u otras redes). Algunos clientes de telnet (que soportan grficos ANSI y protocolos de transferencias de ficheros como Zmodem y otros) son mTelnet!, NetRunner, Putty, Zoc, etc.. Manejo bsico de telnet Para iniciar una sesin con un intrprete de comandos de otro ordenador, puede emplear el comando telnet seguido del nombre o la direccin IP de la mquina en la que desea trabajar, por ejemplo si desea conectarse a la mquina purpura.micolegio.edu.com deber teclear telnet purpura.micolegio.edu.com, y para conectarse con la direccin IP 1.2.3.4 deber utilizar telnet 1.2.3.4. Una vez conectado, podr ingresar el nombre de usuario y contrasea remoto para iniciar una sesin en modo texto a modo de consola virtual (ver Lectura Sistema de usuarios y manejo de clave). La informacin que transmita (incluyendo su clave) no ser protegida o cifrada y podra ser vista en otros computadores por los que se transite la informacin (la captura de estos datos se realiza con un packet sniffer. Una alternativa ms segura para telnet, pero que requiere ms recursos del computador, es SSH. Este cifra la informacin antes de transmitirla, autentica la mquina a la cual se conecta y puede emplear mecanismos de autenticacin de usuarios ms seguros. Actualmente hay sitios para hackers, en los que se entra por telnet y se van sacando las password para ir pasando de nivel, ese uso de telnet aun es vigente. Seguridad Hay tres razones principales por las que el telnet no se recomienda para los sistemas modernos desde el punto de vista de la seguridad:

Los dominios de uso general del telnet tienen varias vulnerabilidades descubiertas sobre los aos, y varias ms que podran an existir. Telnet, por defecto, no cifra ninguno de los datos enviados sobre la conexin (contraseas inclusive), as que es fcil interferir y grabar las comunicaciones, y utilizar la contrasea ms adelante para propsitos maliciosos. Telnet carece de un esquema de autentificacin que permita asegurar que la comunicacin est siendo realizada entre los dos anfitriones deseados, y no interceptada entre ellos. Dnde no utilizarlo? En ambientes donde es importante la seguridad, por ejemplo en el Internet pblico, telnet no debe ser utilizado. Las sesiones de telnet no son cifradas. Esto significa que cualquiera que tiene acceso a cualquier router, switch, o gateway localizado en la red entre los dos anfitriones donde se est utilizando telnet puede interceptar los paquetes de telnet que pasan cerca y obtener fcilmente la informacin de la conexin y de la contrasea (y cualquier otra cosa que se mecanografa) con cualesquiera de varias utilidades comunes como tcpdump y Wireshark. Estos defectos han causado el abandono y depreciacin del protocolo telnet rpidamente, a favor de un protocolo ms seguro y ms funcional llamado SSH, lanzado en 1995. SSH provee de toda la funcionalidad presente en telnet, la adicin del cifrado fuerte para evitar que los datos sensibles tales como contraseas sean interceptados, y de la autentificacin mediante llave pblica, para asegurarse de que el computador remoto es realmente quin dice ser. Los expertos en seguridad computacional, tal como el instituto de SANS, y los miembros del newsgroup de comp.os.linux.security recomiendan que el uso del telnet para las conexiones remotas debera ser descontinuado bajo cualquier circunstancia normal. Cuando el telnet fue desarrollado inicialmente en 1969, la mayora de los usuarios de computadoras en red estaban en los servicios informticos de instituciones acadmicas, o en grandes instalaciones de investigacin privadas y del gobierno. En este ambiente, la seguridad no era una preocupacin y solo se convirti en una preocupacin despus de la explosin del ancho de banda de los aos 90. Con la subida exponencial del nmero de gente con el acceso al Internet, y por la extensin, el nmero de gente que procura crackear los servidores de otra gente, telnet podra no ser recomendado para ser utilizado en redes con conectividad a Internet.

PROTOCOLO SSH Secure Shell (SSH) Familia: Funcin: Familia de protocolos de Internet Acceso remoto a computadoras en forma cifrada 22/TCP

Puertos:

Ubicacin en la pila de protocolos Aplicacin SSH Transporte TCP Red IP (IPv4 y IPv6) SSH (Secure SHell, en espaol: intrprete de rdenes segura) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a mquinas remotas a travs de una red. Permite manejar por completo la computadora mediante un intrprete de comandos, y tambin puede redirigir el trfico de X para poder ejecutar programas grficos si tenemos un Servidor X (en sistemas Unix y Windows) corriendo. Adems de la conexin a otros dispositivos, SSH nos permite copiar datos de forma segura (tanto ficheros sueltos como simular sesiones FTP cifradas), gestionar claves RSA para no escribir claves al conectar a los dispositivos y pasar los datos de cualquier otra aplicacin por un canal seguro tunelizado mediante SSH. Seguridad SSH trabaja de forma similar a como se hace con telnet La diferencia principal es que SSH usa tcnicas de cifrado que hacen que la informacin que viaja por el medio de comunicacin vaya de manera no legible y ninguna tercera persona pueda descubrir el usuario y contrasea de la conexin ni lo que se escribe durante toda la sesin; aunque es posible atacar este tipo de sistemas por medio de ataques de REPLAY y manipular as la informacin entre destinos. Historia Al principio slo existan los r-commands, que eran los basados en el programa rlogin, el cual funciona de una forma similar a telnet.

La primera versin del protocolo y el programa eran libres y los cre un finlands llamado Tatu Ylnen, pero su licencia fue cambiando y termin apareciendo la compaa SSH Communications Security, que lo ofreca gratuitamente para uso domstico y acadmico, pero exiga el pago a otras empresas. En el ao 1997 (dos aos despus de que se creara la primera versin) se propuso como borrador en la IETF. A principios de 1999 se empez a escribir una versin que se convertira en la implementacin libre por excelencia, la de OpenBSD, llamada OpenSSH.

PROTOCOLO POP3 En informtica se utiliza el Post Office Protocol (POP3, Protocolo de la oficina de correo) en clientes locales de correo para obtener los mensajes de correo electrnico almacenados en un servidor remoto. Es un protocolo de nivel de aplicacin en el Modelo OSI. Post Office Protocol (POP3) Familia: Funcin: Familia de protocolos de Internet Obtencin de mensajes de correo electrnico en clientes locales. 110/TCP 995/TCP (Cifrado)

Puertos:

Ubicacin en la pila de protocolos Aplicacin POP3 Transporte TCP Red IP (IPv4 y IPv6) Resumen Las versiones del protocolo POP (informalmente conocido como POP1) y POP2 se han hecho obsoletas debido a las ltimas versiones de POP3. En general cuando uno se refiere al trmino POP, nos referimos a POP3 dentro del contexto de protocolos de correo electrnico. Caractersticas POP3 est diseado para recibir correo, no para enviarlo; le permite a los usuarios con conexiones intermitentes muy lentas (tales como las conexiones por mdem), descargar su correo electrnico mientras tienen conexin y revisarlo posteriormente incluso estando desconectados. Cabe mencionar que la mayora de los clientes de correo incluyen la opcin de dejar los mensajes en el servidor, de manera tal que, un cliente que utilice POP3 se conecta, obtiene todos los mensajes, los almacena en la computadora del usuario como mensajes nuevos, los elimina del servidor y finalmente se desconecta. En contraste, el protocolo IMAP permite los modos de operacin conectado y desconectado. Los clientes de correo electrnico que utilizan IMAP dejan por lo general los mensajes en el servidor hasta que el usuario los elimina directamente. Esto y

otros factores hacen que la operacin de IMAP permita a mltiples clientes acceder al mismo buzn de correo. La mayora de los clientes de correo electrnico soportan POP3 IMAP; sin embargo, solo unos cuantos proveedores de internet ofrecen IMAP como valor agregado de sus servicios. Los clientes que utilizan la opcin dejar mensajes en el servidor por lo general utilizan la orden UIDL ('Unique IDentification Listing). La mayora de las rdenes de POP3 identifican los mensajes dependiendo de su nmero ordinal del servidor de correo. Esto genera problemas al momento que un cliente pretende dejar los mensajes en el servidor, ya que los mensajes con nmero cambian de una conexin al servidor a otra. Por ejemplo un buzn de correo contena 5 mensajes en la ltima conexin, despus otro cliente elimina el mensaje nmero 3, el siguiente usuario se topar con que los ltimos dos mensajes estn decrementados en uno. El UIDL proporciona un mecanismo que evita los problemas de numeracin. El servidor le asigna una cadena de caracteres nica y permanente al mensaje. Cuando un cliente de correo compatible con POP3 se conecta al servidor utiliza la orden UIDL para obtener el mapeo del identificador de mensaje. De esta manera el cliente puede utilizar ese mapeo para determinar qu mensajes hay que descargar y cules hay que guardar al momento de la descarga. Al igual que otros viejos protocolos de internet, POP3 utilizaba un mecanismo de firmado sin cifrado. La transmisin de contraseas de POP3 en texto plano an se da. En la actualidad POP3 cuenta con diversos mtodos de autenticacin que ofrecen una diversa gama de niveles de proteccin contra los accesos ilegales al buzn de correo de los usuarios. Uno de estos es APOP, el cual utiliza funciones MD5 para evitar los ataques de contraseas. Mozilla, Eudora, Novell Evolution as como Mozilla Thunderbird implementan funciones APOP rdenes Para establecer una conexin a un servidor POP, el cliente de correo abre una conexin TCP en el puerto 110 del servidor. Cuando la conexin se ha establecido, el servidor POP enva al cliente POP una invitacin y despus las dos mquinas se envan entre s otras rdenes y respuestas que se especifican en el protocolo. Como parte de esta comunicacin, al cliente POP se le pide que se autentifique (Estado de autenticacin), donde el nombre de usuario y la contrasea del usuario se envan al servidor POP. Si la autenticacin es correcta, el cliente POP pasa al Estado de transaccin, en este estado se pueden utilizar rdenes LIST, RETR y DELE para mostrar, descargar y eliminar mensajes del servidor, respectivamente. Los mensajes definidos para su eliminacin no se quitan realmente del servidor hasta que el cliente POP enva la orden QUIT para terminar la sesin. En ese momento, el servidor POP pasa al Estado de actualizacin, fase en la que se eliminan los mensajes marcados y se limpian todos los recursos restantes de la sesin. Es posible conectarse manualmente al servidor POP3 haciendo Telnet al puerto 110. Es muy til cuando envan un mensaje con un fichero muy largo que no se quiere recibir.

USER <nombre> Identificacin de usuario (Solo se realiza una vez). PASS <password> Enva la clave del servidor. STAT Da el nmero de mensajes no borrados en el buzn y su longitud total. LIST Muestra todo los mensajes no borrados con su longitud. RETR <nmero> Solicita el envo del mensaje especificando el nmero (no se borra del buzn). TOP <nmero> <lneas> Muestra la cabecera y el nmero de lneas requerido del mensaje especificando el nmero. DELE <nmero> Borra el mensaje especificando el nmero. RSET Recupera los mensajes borrados (en la conexin actual). UIDL <nmero> Devuelve una cadena identificatoria del mensaje persistente a travs de las sesiones. Si no se especifica <nmero> se devuelve una lista con los nmeros de mensajes y su cadena identificatoria de los mensajes no borrados. QUIT Salir. Ventajas La ventaja con otros protocolos es que entre servidor-cliente no se tienen que enviar tantas rdenes para la comunicacin entre ellos. El protocolo POP tambin funciona adecuadamente si no se utiliza una conexin constante a Internet o a la red que contiene el servidor de correo.

SMTP Simple Mail Transfer Simple Mail Transfer Protocol (SMTP) Protocolo Simple de Transferencia de Correo, es un protocolo de la capa de aplicacin. Protocolo de red basado en texto utilizado para el intercambio de mensajes de correo electrnico entre computadoras u otros dispositivos (PDA's, telfonos mviles, etc.). Est definido en el RFC 2821 y es un estndar oficial de Internet.1 Simple Mail Transfer Protocol (SMTP) Familia: Funcin: Puertos: Familia de protocolos de Internet Envo de mensajes de correo electrnico 25/TCP 587/TCP (Alternativo para clientes de correo) 465/TCP (SMTPS) Ubicacin en la pila de protocolos Aplicacin SMTP Transporte TCP Red IP (IPv4 y IPv6) Historia En 1982 se dise el primer sistema para intercambiar correos electrnicos en ARPANET, definido en los Request for comments RFC 821 y RFC 822. La primera de ellas define este protocolo y la segunda el formato del mensaje que este protocolo deba transportar. Con el tiempo se ha convertido en uno de los protocolos ms usados en internet. Para adaptarse a las nuevas necesidades surgidas por el crecimiento y popularidad de internet se han hecho varias ampliaciones a este protocolo, como poder enviar texto con formato. Funcionamiento SMTP se basa en el modelo cliente-servidor, donde un cliente enva un mensaje a uno o varios receptores. La comunicacin entre el cliente y el servidor consiste enteramente en lneas de texto compuestas por caracteres ASCII. El tamao mximo permitido para estas lneas es de 1000 caracteres.

Las respuestas del servidor constan de un cdigo numrico de tres digitos, seguido de un texto explicativo. El nmero va dirigido a un procesado automtico de la respuesta por autmata, mientras que el texto permite que un humano interprete la respuesta. En el protocolo SMTP todas las rdenes, rplicas o datos son lneas de texto, delimitadas por el carcter <CRLF>. Todas las rplicas tienen un cdigo numrico al comienzo de la lnea. En el conjunto de protocolos TCP/IP, el SMTP va por encima del TCP, usando normalmente el puerto 25 en el servidor para establecer la conexin. Resumen simple del funcionamiento del protocolo SMTP Cuando un cliente establece una conexin con el servidor SMTP, espera a que ste enve un mensaje 220 Service ready o 421 Service non available Se enva un HELO desde el cliente. Con ello el servidor se identifica. Esto puede usarse para comprobar si se conect con el servidor SMTP correcto. El cliente comienza la transaccin del correo con la orden MAIL FROM. Como argumento de esta orden se puede pasar la direccin de correo al que el servidor notificar cualquier fallo en el envo del correo (Por ejemplo, MAIL FROM:<fuente@host0>). Luego si el servidor comprueba que el origen es valido, el servidor responde 250 OK. Ya le hemos dicho al servidor que queremos mandar un correo, ahora hay que comunicarle a quien. La orden para esto es RCPT TO:<destino@host>. 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. Una vez enviados todos los RCPT, el cliente enva una orden DATA para indicar que a continuacin se envan los contenidos del mensaje. El servidor responde 354 Start mail input, end with <CRLF>.<CRLF> Esto indica al cliente como ha de notificar el fin del mensaje. Ahora el cliente enva el cuerpo del mensaje, lnea a lnea. Una vez finalizado, se termina con un <CRLF>.<CRLF> (la ltima lnea ser un punto), a lo que el servidor contestar 250 OK, o un mensaje de error apropiado. Tras el envo, el cliente, si no tiene que enviar ms correos, con la orden QUIT corta la conexin. Tambin puede usar la orden TURN, con lo que el cliente pasa a ser el servidor, y el servidor se convierte en cliente. Finalmente, si tiene ms mensajes que enviar, repite el proceso hasta completarlos.

Puede que el servidor SMTP soporte las extensiones definidas en el RFC 1651, en este caso, la orden HELO puede ser sustituida por la orden EHLO, con lo que el servidor contestar con una lista de las extensiones admitidas. Si el servidor no soporta las extensiones, contestar con un mensaje "500 Syntax error, command unrecognized". En el ejemplo pueden verse las rdenes bsicas de SMTP: HELO, para abrir una sesin con el servidor MAIL FROM, para indicar quien enva el mensaje RCPT TO, para indicar el destinatario del mensaje DATA, para indicar el comienzo del mensaje, ste finalizar cuando haya una lnea nicamente con un punto. QUIT, para cerrar la sesin RSET Aborta la transaccin en curso y borra todos los registros. SEND Inicia una transaccin en la cual el mensaje se entrega a una terminal. SOML El mensaje se entrega a un terminal o a un buzon. SAML El mensaje se entrega a un terminal y a un buzon. VRFY Solicita al servidor la verificacin del argumento. EXPN Solicita al servidor la confirmacin del argumento. HELP Permite solicitar informacin sobre un comando. NOOP Se emplea para reiniciar los temporizadores. TURN Solicita al servidor que intercambien los paquetes. De los tres dgitos del cdigo numrico, el primero indica la categora de la respuesta, estando definidas las siguientes categoras: 2XX, la operacin solicitada mediante el comando anterior ha sido concluida con xito 3XX, la orden ha sido aceptada, pero el servidor esta pendiente de que el cliente le enve nuevos datos para terminar la operacin 4XX, para una respuesta de error, pero se espera a que se repita la instruccin 5XX, para indicar una condicin de error permanente, por lo que no debe repetirse la orden Una vez que el servidor recibe el mensaje finalizado con un punto puede almacenarlo si es para un destinatario que pertenece a su dominio, o bien retransmitirlo a otro servidor para que finalmente llegue a un servidor del dominio del receptor. Ejemplo de una comunicacin SMTP En primer lugar se ha de establecer una conexin entre el emisor (cliente) y el receptor (servidor). Esto puede hacerse automticamente con un programa cliente de correo o mediante un cliente telnet. En el siguiente ejemplo se muestra una conexin tpica. Se nombra con la letra C al cliente y con S al servidor.

S: 220 Servidor ESMTP C: HELO miequipo.midominio.com S: 250 Hello, please meet you C: MAIL FROM: yo@midominio.com S: 250 Ok C: RCPT TO: destinatario@sudominio.com S: 250 Ok C: DATA S: 354 End data with <CR><LF>.<CR><LF> C: Subject: Campo de asunto C: From: yo@midominio.com C: To: destinatario@sudominio.com C: C: Hola, C: Esto es una prueba. C: Adis. C: C: . S: 250 Ok: queued as 12345 C: quit S: 221 Bye Formato del mensaje Como se muestra en el ejemplo anterior, el mensaje es enviado por el cliente despus de que ste manda la orden DATA al servidor. El mensaje est compuesto por dos partes: Cabecera: en el ejemplo las tres primeras lneas del mensaje son la cabecera. En ellas se usan unas palabras clave para definir los campos del mensaje. stos campos ayudan a los clientes de correo a organizarlos y mostrarlos. Los ms tpicos son subject (asunto), from (emisor) y to (receptor). stos 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 bsico est compuesto nicamente por texto, y finalizado con una lnea en la que el nico carcter es un punto. Seguridad y spam Una de las limitaciones del SMTP original es que no facilita mtodos de autenticacin a los emisores, as que se defini la extensin SMTP-AUTH. A pesar de esto, el spam es an el mayor problema. No se cree que las extensiones sean una forma prctica para prevenirlo. Internet Mail 2000 es una de las propuestas para reemplazarlo. Especificaciones

Ejemplo de transferencia de mensajes SMTP Las lneas precedidas de <<"C:">> corresponden a comandos emitidos por el cliente y las que comienzan con <<"S:">> son las consiguientes respuestas que devuelve el servidor. S: <en espera de conexin TCP en el puerto 25> c: <abre la conexin con el servidor> s:220 beta.gov Simple Mail Transfer Service ready c:HELO <alpha.edu> s:250 beta.gov c:MAIL from : <smith@alpha.edu> s:250 OK c:RCPT TO: <jones@beta.edu> s:250 OK c:RCPT TO: <green@beta.edu> s:550 No such user here c:DATA s:354 Inicio de la entrada del mail; finaliza con <CRLF>.<CRLF> c:.... se enva el contenido del mensaje (cabecera y cuerpo)... s:<CRLF>.<CRLF> s:250 OK c:QUIT s:221 beta.gov Service closing transmition channel Conexin al inicio del protocolo Cuando se emplea el protocolo TCP el servidor SMTP escucha permanentemente al puerto 25, en espera de algn cliente que desea enviarlo. El protocolo de aplicacin SMTP inicia el comando HELO, seguido de la identificacin del cliente, el servidor lo acepta con un cdigo <<250 OK>>.

Envo de mensajes Una vez iniciado el protocolo, se realiza el envo de mensajes desde el cliente al servidor, mediante el siguiente proceso Envo del sobre En primer lugar se transmite la direccin del buzon del origen del mensaje, el comando es el MAIL FROM y si el servidor acepta enva el mensaje 250 OK. Luego se transmite la direccin de destino, mediante el comando RCPT TO y el servidor confirma con 250 OK, pero si el destinatario no existe se enva 550 Failure. Envo del contenido del mensaje El cliente informa al servidor de que va a enviar el mensaje mendiante el comando DATA, si el servidor est dispuesto enva 354, todas las lneas que el cliente enva a partir de este momento se consideran parte del contenido del mensaje, al final del mensaje se considera enviando el <<.>>, cuando el servidor recibe el fin del mensaje confirma con 250 OK, Cierre de la conexin Una vez enviado todos los mensajes, el cliente puede cerrar la conexin mediante el comando QUIT, caso contrario la mquina que recibi los mensajes sea quien las enve con el comando TURN, el servidor confirma con 250 OK, dando una seccin que se inicia con el comando HELO.

IMAP Internet Message Access Protocol, o su acrnimo IMAP, es un protocolo de red de acceso a mensajes electrnicos almacenados en un servidor. Mediante IMAP se puede tener acceso al correo electrnico desde cualquier equipo que tenga una conexin a Internet. IMAP tiene varias ventajas sobre POP, que es el otro protocolo empleado para obtener correo desde un servidor. Por ejemplo, es posible especificar en IMAP carpetas del lado servidor. Por otro lado, es ms complejo que POP ya que permite visualizar los mensajes de manera remota y no descargando los mensajes como lo hace POP. Internet Message Access Protocol (IMAP) Familia: Funcin: Puertos: Familia de protocolos de Internet acceso a correo electrnico 143/TCP 220/TCP (IMAP3) 993/TCP (IMAPS)

Ubicacin en la pila de protocolos Aplicacin IMAP Transporte TCP Red IP Introduccin IMAP y POP3 (Post Office Protocol versin 3) son los dos protocolos que prevalecen en la obtencin de correo electrnico. Todos los servidores y clientes de email estn virtualmente soportados por ambos, aunque en algunos casos hay algunas interfaces especficas del fabricante tpicamente propietarias. Por ejemplo, los protocolos propietarios utilizados entre el cliente Microsoft Outlook y su servidor Microsoft Exchange Server o el cliente Lotus Notes de IBM y el servidor Domino. Sin embargo, estos productos tambin soportan interoperabilidad con IMAP y POP3 con otros clientes y servidores. La versin actual de IMAP, IMAP versin 4 revisin 1 (IMAP4rev1), est definida por el RFC 3501. IMAP fue diseado como una moderna alternativa a POP por Mark Crispin en el ao 1986. ver web. Fundamentalmente, los dos protocolos le permiten a los clientes de correo acceder a los mensajes almacenados en un servidor de correo.

Ya sea empleando POP3 o IMAP4 para obtener los mensajes, los clientes utilizan SMTP para enviar mensajes. Los clientes de correo electrnico son comnmente denominados clientes POP o IMAP, pero en ambos casos se utiliza SMTP. La mayora de los clientes de correo utilizan LDAP para sus servicios de directorio. IMAP es utilizado frecuentemente en redes grandes; por ejemplo los sistemas de correo de un campus. IMAP le permite a los usuarios acceder a los nuevos mensajes instantneamente en sus computadoras, ya que el correo est almacenado en la red. Con POP3 los usuarios tendran que descargar el email a sus computadoras o accederlo va web. Ambos mtodos toman ms tiempo de lo que le tomara a IMAP, y se tiene que descargar el email nuevo o refrescar la pgina para ver los nuevos mensajes. De manera contraria a otros protocolos de Internet, IMAP4 permite mecanismos nativos de cifrado. Tambin est disponible la transmisin de contraseas en texto plano. Ventajas sobre POP3 Algunas de las caractersticas importantes que diferencian a IMAP y POP3 son: Respaldo para los modos de operacin en lnea y fuera de lnea Al utilizar POP3, los clientes se conectan brevemente al servidor de correo, solamente el tiempo que les tome descargar los nuevos mensajes. Al utilizar IMAP, los clientes permanecen conectados el tiempo que su interfaz permanezca activa y descargan los mensajes bajo demanda. Esta manera de trabajar de IMAP puede dar tiempos de respuesta ms rpidos para usuarios que tienen una gran cantidad de mensajes o mensajes grandes. Respaldo para la conexin de mltiples clientes simultneos a un mismo destinatario El protocolo POP3 supone que el cliente conectado es el nico dueo de una cuenta de correo. En contraste, el protocolo IMAP4 permite accesos simultneos a mltiples clientes y proporciona ciertos mecanismos a los clientes para que se detecten los cambios hechos a un mailbox por otro cliente concurrentemente conectado. Respaldo para acceso a partes MIME de los mensajes y obtencin parcial Casi todo el correo electrnico de Internet es transmitido en formato MIME. El protocolo IMAP4 le permite a los clientes obtener separadamente cualquier parte MIME individual, as como obtener porciones de las partes individuales o los mensajes completos. Es mas seguro.

Respaldo para que la informacin de estado del mensaje se mantenga en el servidor A travs de la utilizacin de seales definidas en el protocolo IMAP4 de los clientes, se puede vigilar el estado del mensaje, por ejemplo, si el mensaje ha sido o no ledo, respondido o eliminado. Estas seales se almacenan en el servidor, de manera que varios clientes conectados al mismo correo en diferente tiempo pueden detectar los cambios hechos por otros clientes. Respaldo para accesos mltiples a los buzones de correo en el servidor Los clientes de IMAP4 pueden crear, renombrar o eliminar correo (por lo general presentado como carpetas al usuario) del servidor, y mover mensajes entre cuentas de correo. El soporte para mltiples buzones de correo tambin le permite al servidor proporcionar acceso a los directorios pblicos y compartidos. Respaldo para bsquedas de parte del servidor IMAP4 proporciona un mecanismo para que los clientes pidan al servidor que busque mensajes de acuerdo a una cierta variedad de criterios. Este mecanismo evita que los clientes descarguen todos los mensajes de su buzn de correo, agilizando, de esta manera, las bsquedas. Respaldo para un mecanismo de extensin definido Como reflejo de la experiencia en versiones anteriores de los protocolos de Internet, IMAP define un mecanismo explcito mediante el cual puede ser extendido. Se han propuesto muchas extensiones de IMAP4 y son de uso comn. Un ejemplo de extensin es el IMAP IDLE, que sirve para que el servidor avise al cliente cuando ha llegado un nuevo mensaje de correo y stos se sincronicen. Sin esta extensin, para realizar la misma tarea, el cliente debera contactar peridicamente al servidor para ver si hay mensajes nuevos.

PROTOCOLO SOAP SOAP (siglas de Simple Object Access Protocol) es un protocolo estndar que define cmo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. Este protocolo deriva de un protocolo creado por David Winer en 1998, llamado XML-RPC. SOAP fue creado por Microsoft, IBM y otros y est actualmente bajo el auspicio de la W3C. Es uno de los protocolos utilizados en los servicios Web. SOAP sobre correo electrnico Los desarrolladores de aplicaciones hoy en da, pueden utilizar la infraestructura de correo electrnico de Internet para transmitir mensajes SOAP ya sean como mensajes de correo electrnico de texto o como adjuntos. Los ejemplos que se muestran a continuacin muestran un modo de transmitir mensajes SOAP, y deben ser tomados como el modo estndar de hacerlo. Las especificaciones SOAP Versin 1.2 no especifican tal vnculo. Sin embargo, existe una Nota W3C no-normativa [SOAP Email Binding] que describe un vnculo de SOAP con el correo electrnico, su propsito principal es comenzar a demostrar la aplicacin de la Infraestructura general de Vnculos con el Protocolo SOAP. El Ejemplo muestra el mensaje de peticin de reserva de viaje del Ejemplo 1 transportado como un mensaje de correo electrnico entre un agente de usuario remitente y un agente de usuario destinatario. Est implcito que el nodo destinatario tiene capacidad para entender SOAP, por lo que se enva el mensaje de correo electrnico para su procesamiento. (Se asume que tambin el nodo remitente puede manejar errores SOAP que pudiera recibir en la respuesta o correlacionar cualesquiera mensajes SOAP recibidos en respuesta a ste). Ejemplo De: a.oyvind@miempresa.example.com A: reservas@empresaviajes.example.org Asunto: Viaje a LA Fecha: Thu, 29 Nov 2001 13:20:00 EST Message-Id: <EE492E16A090090276D208424960C0C@miempresa.example.com> Content-Type: application/soap+xml <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <m:reserva xmlns:m="[[http://www.mouta.com.ar]]" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <m:referencia>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:referencia> <m:fechaYHora>2001-11-29T13:20:00.000-05:00</m:fechaYHora> </m:reserva> <n:pasajero xmlns:n="http://miempresa.example.com/empleados" env:role="http://www.w3.org/2003/05/soap-envelope/role/next"

env:mustUnderstand="true"> <n:nombre>ke Jgvan yvind</n:nombre> </n:pasajero > </env:Header> <env:Body> <p:itinerario xmlns:p="http://empresaviajes.example.org/reserva/viaje"> <p:ida> <p:salida>Nueva York</p:salida> <p:llegada>Los Angeles</p:llegada> <p:fechaSalida>2001-12-14</p:fechaSalida> <p:horaSalida>ltima hora de la tarde</p:horaSalida> <p:preferenciaAsiento>pasillo</p:preferenciaAsiento> </p:ida> <p:vuelta> <p:salida>Los Angeles</p:salida> <p:llegada>Nueva York</p:llegada> <p:fechaSalida>2001-12-20</p:fechaSalida> <p:horaSalida>media-maana</p:horaSalida> <p:preferenciaAsiento /> </p:vuelta> </p:itinerario> <q:alojamiento xmlns:q="http://empresaviajes.example.org/reserva/hoteles"> <q:preferencia>ninguna</q:preferencia> </q:alojamiento> </env:Body> </env:Envelope>Mensaje SOAP del Ejemplo 1 transportado como un mensaje SMTP El encabezado del Ejemplo tiene la forma estndar de [RFC 2822] para mensajes de correo electrnico. Aunque el correo electrnico es un intercambio de mensajes en un solo sentido, y no se da ninguna garanta de entrega, infraestructuras como la de la especificacin Simple Mail Transport Protocol (SMTP) ofrecen un mecanismo de notificacin de entrega que, en el caso de SMTP, se denominan Delivery Status Notification (DSN) [Notificacin de Estado de Entrega] y Message Disposition Notification (MDN) [Notificacin de Disposicin de Mensaje]. Estas notificaciones toman la forma de mensajes de correo electrnico enviados a la direccin de correo electrnico especificada en el encabezamiento del mensaje de correo. Las aplicaciones, as como los usuarios finales del correo, pueden utilizar estos mecanismos para proporcionar el estado de una transmisin de correo electrnico, pero estos, si existiesen, seran notificaciones al nivel SMTP. El desarrollador de aplicaciones debe comprender completamente las capacidad y limitaciones de estas notificaciones de entrega o el riesgo de asumir que haya existido una entrega del mensaje con xito cuando podra no haberse producido. Los mensajes de estado de entrega SMTP son separados del procesamiento del mensaje en la capa SOAP. Las respuestas SOAP resultantes a los datos SOAP sern devueltas a travs de un mensaje de correo electrnico nuevo que

podra tener o no un enlace con el mensaje de la peticin original al nivel SMTP. El uso del encabezado In-reply-to: [En-respuesta-a] segn [RFC 2822] puede conseguir una correlacin al nivel SMTP, pero no implica necesariamente una correlacin al nivel SOAP. Ejemplos de mensajes SOAP Como ejemplo se muestra la forma en que un cliente solicitara informacin de un producto a un proveedor de servicios Web: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <getProductDetails xmlns="http://warehouse.example.com/ws"> <productId>827635</productId> </getProductDetails> </soap:Body> </soap:Envelope>

Y esta sera la respuesta del proveedor: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <getProductDetailsResponse xmlns="http://warehouse.example.com/ws"> <getProductDetailsResult> <productName>Toptimate 3-Piece Set</productName> <productId>827635</productId> <description>3-Piece luggage set. Black Polyester.</description> <price>96.50</price> <inStock>true</inStock> </getProductDetailsResult> </getProductDetailsResponse> </soap:Body> </soap:Envelope> A pesar de no ser la nica opcin posible, HTTP fue elegido como protocolo de transporte por sus ventajas, para lidiar con cortafuegos, por ejemplo. Otros protocolos como GIOP/IIOP o DCOM (utilizados en CORBA, RMI y DCOM) suelen ser repelidos por estos cortafuegos.

PROTOCOLO PPT Point-to-point Protocol, es decir, Protocolo punto a punto, es un protocolo de nivel de enlace estandarizado en el documento RFC 1661. Por tanto, se trata de un protocolo asociado a la pila TCP/IP de uso en Internet. Ms conocido por su acrnimo: PPP. Point to Point Protocol (PPP) Familia: Funcin: Protocolos de enlace punto a punto Transmisin de datagramas IP no estndar en lneas serie.

Ubicacin en la pila de protocolos Aplicacin FTP, SMTP, HTTP, DNS, ... Transporte TCP o UDP Red IP Enlace PPP Descripcin El protocolo PPP permite establecer una comunicacin a nivel de enlace entre dos computadoras. Generalmente, se utiliza para establecer la conexin a Internet de un particular con su proveedor de acceso a travs de un mdem telefnico. Ocasionalmente tambin es utilizado sobre conexiones de banda ancha (como PPPoE o PPPoA). Adems del simple transporte de datos, PPP facilita dos funciones importantes: Autenticacin. Generalmente mediante una clave de acceso. Asignacin dinmica de IP. Los proveedores de acceso cuentan con un nmero limitado de direcciones IP y cuentan con ms clientes que direcciones. Naturalmente, no todos los clientes se conectan al mismo tiempo. As, es posible asignar una direccin IP a cada cliente en el momento en que se conectan al proveedor. La direccin IP se conserva hasta que termina la conexin por PPP. Posteriormente, puede ser asignada a otro cliente. PPP tambin tiene otros usos, por ejemplo, se utiliza para establecer la comunicacin entre un mdem ADSL y la pasarela ATM del operador de telecomunicaciones. Tambin se ha venido utilizando para conectar a trabajadores desplazados (p. ej. ordenador porttil) con sus oficinas a travs de

un centro de acceso remoto de su empresa. Aunque est aplicacin se est abandonando en favor de las redes privadas virtuales, ms seguras. Trama PPP Una trama PPP esta basada en HDLC.1 Tiene un mnimo de 6 bytes y un mximo indeterminado. La trama HDLC con PPP es:

Bandera Direccin Control Protocolo

Datos

FCS Bandera

0x7e

0xFF

0x03

2 bytes

Longitud variable. 2o4 Puede llevar bytes relleno.

0x7e

Nota: 0x7e son 8 bits en notacin hexadecimal, ver Hexadecimal para ms informacin. La direccin siempre es 0xFF que es la direccin de difusin estandar de todos los destinos. En PPP no hay direcciones individuales de cada estacin dado que slo hay dos. El campo control vale 0x03, que corresponde con tramas de usuario no nmeradas en HDLC. Estos dos campos se pueden eliminar si se negocia en LCP "Address-and-Control-Field-Compression" (ACFC, compresin de los campos de direccin y control). Los identificadores de protocolo estn especificados en el RFC 1661. Los ms importantes son: 0x0021 para IP. 0xc021 para LCP. 0xc023 para PAP. 0xc223 para CHAP. El campo FCS (Frame Check Sequence) es una secuencia de comprobacin de trama. Se utiliza para detectar errores en la transmisin de la trama. El transmisor calcula el CRC del contenido de la trama y lo coloca en el campo FCS. El receptor calcula el CRC de la trama que recibe y lo compara con el valor que hay en el FCS. Si los valores son distintos, hay bits errneos en la trama, por lo que se descarta. Si el campo FCS es de 2 bytes se usa un CRC de 16 bits. Si el campo FCS es de 4 bytes, se usa un CRC de 32 bits. Funcionamiento

Protocolo PPP. PPP consta de las siguientes fases: 1. Establecimiento de conexin. Durante esta fase, una computadora contacta con la otra y negocian los parmetros relativos al enlace usando el protocolo LCP. Este protocolo es una parte fundamental de PPP y por ello estn definidos en el mismo RFC. Usando LCP se negocia el mtodo de autenticacin que se va a utilizar, el tamao de los datagramas, nmeros mgicos para usar durante la autenticacin,... 2. Autenticacin. No es obligatorio. Existen dos protocolos de autenticacin. El ms bsico e inseguro es PAP, aunque no se recomienda dado que manda el nombre de usuario y la contrasea en claro. Un mtodo ms avanzado y preferido por muchos ISPs es CHAP, en el cual la contrasea se manda cifrada. 3. Configuracin de red. En esta fase se negocian parmetros dependientes del protocolo de red que se est usando. PPP puede llevar muchos protocolos de red al mismo tiempo y es necesario configurar individualmente cada uno de estos protocolos. Para configurar un protocolo de red se usa el protocolo NCP correspondiente. Por ejemplo, si la red es IP, se usa el protocolo IPCP para asignar la direccin IP del cliente y sus servidores DNS. 4. Transmisin. Durante esta fase se manda y recibe la informacin de red. LCP se encarga de comprobar que la lnea est activa durante periodos de inactividad. Obsrvese que PPP no proporciona cifrado de datos. 5. Terminacin. La conexin puede ser finalizada en cualquier momento y por cualquier motivo. PPP tiene todas las propiedades de un protocolo de nivel de enlace:

Garanta de recepcin. Recepcin ordenada Uso del puerto 53 para conexin bidireccional de sockets. PPP versus SLIP El protocolo SLIP cumple la misma funcin que PPP, pero se trata de un protocolo mucho ms anticuado. Las ventajas de PPP sobre SLIP son: Permite la conexin tanto mediante lneas sncronas como asncronas. Permite la asignacin dinmica de direcciones IP en ambos extremos de la conexin. Permite el transporte de varios protocolos de red sobre l (SLIP solamente permite IP). Implementa un mecanismo de control de red NCP. Usado tambin en Redes Neuronales Artificiales (RNA). Suelen estar almacenados en contenedores Enterprise Java Bean (EJB) [cita requerida] . Implementado en los puentes H con transistores NPN (Puente de WeatStone)[cita requerida]. El protocolo PPP se puede usar tambin para crear Redes Privadas Virtuales (RPV) tanto cifradas como no cifradas, pero si se desea cifrado, se debe implementar por debajo de PPP.

PROTOCOLO STP Spanning Tree Protocol (SmmTPr) es un protocolo de red de nivel 2 de la capa OSI, (nivel de enlace de datos). Est basado en un algoritmo diseado por Radia Perlman mientras trabajaba para DEC. Hay 2 versiones del STP: la original (DEC STP) y la estandarizada por el IEEE (IEEE 802.1D), que no son compatibles entre s. En la actualidad, se recomienda utilizar la versin estandarizada por el IEEE. Su funcin es la de gestionar la presencia de bucles en topologas de red debido a la existencia de enlaces redundantes (necesarios en muchos casos para garantizar la disponibilidad de las conexiones). El protocolo permite a los dispositivos de interconexin activar o desactivar automticamente los enlaces de conexin, de forma que se garantice que la topologa est libre de bucles. STP es transparente a las estaciones de usuario. Los bucles infinitos ocurren cuando hay rutas alternativas hacia una misma mquina o segmento de red de destino. Estas rutas alternativas son necesarias para proporcionar redundancia, ofreciendo una mayor fiabilidad. Si existen varios enlaces, en el caso que uno falle, otro enlace puede seguir soportando el trfico de la red. Los problemas aparecen cuando utilizamos dispositivos de interconexin de nivel de enlace, como un puente de red o un conmutador de paquetes. Cuando hay bucles en la topologa de red, los dispositivos de interconexin de nivel de enlace reenvan indefinidamente las tramas Broadcast y multicast, al no existir ningn campo TTL (Time To Live, Tiempo de Vida) en la Capa 2, tal y como ocurre en la Capa 3. Se consume entonces una gran cantidad de ancho de banda, y en muchos caso la red queda inutilizada. Un router, por el contrario, s podra evitar este tipo de reenvos indefinidos. La solucin consiste en permitir la existencia de enlaces fsicos redundantes, pero creando una topologa lgica libre de bucles. STP permite solamente una trayectoria activa a la vez entre dos dispositivos de la red (esto previene los bucles) pero mantiene los caminos redundantes como reserva, para activarlos en caso de que el camino inicial falle. Si la configuracin de STP cambia, o si un segmento en la red redundante llega a ser inalcanzable, el algoritmo reconfigura los enlaces y restablece la conectividad, activando uno de los enlaces de reserva. Si el protocolo falla, es posible que ambas conexiones estn activas simultneamente, lo que podran dar lugar a un bucle de trfico infinito en la LAN. Existen mltiples variantes del Spaning Tree Protocol, debido principalmente al tiempo que tarda el algoritmo utilizado en converger. Una de estas variantes es el Rapid Spanning Tree Protocol El rbol de expansin (Spanning tree) permanece vigente hasta que ocurre un cambio en la topologa, situacin que el protocolo es capaz de detectar de forma automtica. El mximo tiempo de duracin del rbol de expansin es de

cinco minutos. Cuando ocurre uno de estos cambios, el puente raz actual redefine la topologa del rbol de expansin o se elige un nuevo puente raz. Funcionamiento Este algoritmo cambia una red fsica con forma de malla, en la que existen bucles, por una red lgica en rbol en la que no existe ningn bucle. Los puentes se comunican mediante mensajes de configuracin llamados Bridge Protocol Data Units (B.P.D.U). El protocolo establece identificadores por puente y elige el que tiene la prioridad ms alta (el nmero ms bajo de prioridad numrica), como el puente raz. Este puente raz establecer el camino de menor coste para todas las redes; cada puerto tiene un parmetro configurable: el Span path cost. Despus, entre todos los puentes que conectan un segmento de red, se elige un puente designado, el de menor coste (en el caso que haya mismo coste en dos puentes, se elige el que tenga el menor identificador "direccion MAC"), para transmitir las tramas hacia la raz. En este puente designado, el puerto que conecta con el segmento, es el puerto designado y el que ofrece un camino de menor coste hacia la raz, el puerto raz. Todos los dems puertos y caminos son bloqueados, esto es en un estado ya estacionario de funcionamiento. Eleccin del puente raz La primera decisin que toman todos los switches de la red es identificar el puente raz ya que esto afectar al flujo de trfico. Cuando un switch se enciende, supone que es el switch raz y enva las BPDU que contienen la direccin MAC de s mismo tanto en el BID raz como emisor. Cada switch reemplaza los BID de raz ms alta por BID de raz ms baja en las BPDU que se envan. Todos los switches reciben las BPDU y determinan que el switch que cuyo valor de BID raz es el ms bajo ser el puente raz. El administrador de red puede establecer la prioridad de switch en un valor ms pequeo que el del valor por defecto (32768), lo que hace que el BID sea ms pequeo. Esto slo se debe implementar cuando se tiene un conocimiento profundo del flujo de trfico en la red. Eleccin de los puertos raz Una vez elegido el puente raz hay que calcular el puerto raz para los otros puentes que no son raz. Para cada puente se calcula de igual manera, cual de los puertos del puente tiene menor coste al puente raz, ese ser el puerto raz de ese puente. Eleccin de los puertos designados Una vez elegido el puente raz y los puertos raz de los otros puentes pasamos a calcular los puertos designados de cada LAN, que ser el que le lleva al menor coste al puente raz. Si hubiese empate se elige por el ID ms bajo.

Puertos bloqueados Aquellos puertos que no sean elegidos como raz ni como designados deben bloquearse. Mantenimiento del Spanning Tree El cambio en la topologa puede ocurrir de dos formas: El puerto se desactiva o se bloquea El puerto pasa de estar bloqueado o desactivado a activado Cuando se detecta un cambio el switch notifica al puente raz dicho cambio y entonces el puente raz enva por broadcast dicha cambio. Para ello, se introduce una BPDU especial denominada notificacin de cambio en la topologa (TCN). Cuando un switch necesita avisar acerca de un cambio en la topologa, comienza a enviar TCN en su puerto raz. La TCN es una BPDU muy simple que no contiene informacin y se enva durante el intervalo de tiempo de saludo. El switch que recibe la TCN se denomina puente designado y realiza el acuse de recibo mediante el envo inmediato de una BPDU normal con el bit de acuse de recibo de cambio en la topologa (TCA). Este intercambio contina hasta que el puente raz responde. Estado de los puertos Los estado en los que puede estar un puerto son los siguientes: Bloqueo: En este estado slo se pueden recibir BPDU's. Las tramas de datos se descartan y no se actualizan las tablas de direcciones MAC (mac-address-table). Escucha: A este estado se llega desde Bloqueo. En este estado, los switches determinan si existe alguna otra ruta hacia el puente raz. En el caso que la nueva ruta tenga un coste mayor, se vuelve al estado de Bloqueo. Las tramas de datos se descartan y no se actualizan las tablas ARP. Se procesan las BPDU. Aprendizaje: A este estado se llega desde Escucha. Las tramas de datos se descartan pero ya se actualizan las tablas de direcciones MAC (aqu es donde se aprenden por primera vez). Se procesan las BPDU. Envo: A este estado se llega desde Aprendizaje. Las tramas de datos se envan y se actualizan las tablas de direcciones MAC (mac-addresstable). Se procesan las BPDU. Desactivado: A este estado se llega desde cualquier otro. Se produce cuando un administrador deshabilita el puerto o ste falla. No se procesan las BPDU. Prximamente estar el nuevo protocolo 802.11t que ser mucho ms rpido que este. enero 2010