sábado, 2 de octubre de 2010

PROTOCOLOS PARA REDES

PROTOCOLOS DE INTERNET.wmv

TRANSMISIONES, FUNCIONES Y DESARROLLO DE TCP/IP

Redirigido desde TCP)
Saltar a navegación, búsqueda
Para otros usos de este término, véase TCP (desambiguación).
Transmission Control Protocol
(TCP Familia: Familia de protocolos de Internet
Función: Transporte confiable y bidireccional de datos .

--------------------------------------------------------------------------------
Ubicación en la pila de protocolos
Aplicación ftp, http, SNMP, DNS, ...
Transporte TCP
Red IP
Enlace Ethernet, Token Ring,
FDDI, ...

--------------------------------------------------------------------------------

Estándares: RFC 793 (1981)

RFC 1323 (1992)


Transmission Control Protocol (en español Protocolo de Control de Transmisión) o TCP, es uno de los protocolos fundamentales en Internet. Fue creado entre los años 1973 y 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 través de las cuales puede enviarse un flujo de datos. El protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo orden en que se transmitieron. También proporciona un mecanismo para distinguir distintas aplicaciones dentro de una misma máquina, a través del concepto de puerto.

TCP da soporte a muchas de las aplicaciones más populares de Internet, incluidas HTTP, SMTP, SSH y FTP.

Información Técnica
TCP es un protocolo de comunicación orientado a conexión y fiable del nivel de transporte, actualmente documentado por IETF en el RFC 793. Es un protocolo de capa 4 según el modelo OSI.

[editar] Funciones de TCP
En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de internet (IP) y la aplicación. Habitualmente, las aplicaciones necesitan que la comunicación sea fiable y, dado que la capa IP aporta un servicio de datagramas no fiable (sin confirmación), TCP añade las funciones necesarias para prestar un servicio que permita que la comunicación entre dos sistemas se efectúe libre de errores, sin pérdidas y con seguridad.

Los servicios provistos por TCP corren en el anfitrión (host) de cualquiera de los extremos de una conexión, no en la red. Por lo tanto, TCP es un protocolo para manejar conexiones de extremo a extremo. Tales conexiones pueden existir a través de una serie de conexiones punto a punto, por lo que estas conexiones extremo-extremo son llamadas circuitos virtuales.




Orientado a la conexión: dos computadoras establecen una conexión para intercambiar datos. Los sistemas de los extremos se sincronizan con el otro para manejar el flujo de paquetes y adaptarse a la congestión de la red.
Operación Full-Dúplex: una conexión TCP es un par de circuitos virtuales, cada uno en una dirección. Sólo los dos sistemas finales sincronizados pueden usar la conexión.
Error Checking: una técnica de checksum es usada para verificar que los paquetes no estén corruptos.
Acknowledgements: sobre recibo de uno o más 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 conexión si el transmisor cree que el receptor no está más en la conexión.
Control de flujo: si el transmisor está desbordando el buffer del receptor por transmitir demasiado rápido, 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 recuperación de Paquetes: el receptor puede pedir la retransmisión de un paquete. Si el paquete no es notificado como recibido (ACK), el transmisor envía de nuevo el paquete.
Los servicios confiables de entrega de datos son críticos para aplicaciones tales como transferencias de archivos (FTP por ejemplo), servicios de bases de datos, proceso de transacciones y otras aplicaciones de misión crítica en las cuales la entrega de cada paquete debe ser garantizada.

[editar] Formato de los Segmentos TCP
En el nivel de transporte, los paquetes de bits que constituyen las unidades de datos de protocolo TCP 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 Puerto Origen Puerto Destino
32 Número de Secuencia
64 Número de Acuse de Recibo (ACK)
96 longitud cabecera TCP Reservado Flags Ventana
128 Suma de Verificación (Checksum) Puntero Urgente
160 Opciones + Relleno (opcional)
224
Datos


Las aplicaciones envían flujos de bytes a la capa TCP para ser enviados a la red. TCP divide el flujo de bytes llegado de la aplicación en segmentos de tamaño apropiado (normalmente esta limitación viene impuesta por la unidad máxima de transferencia (MTU) del nivel de enlace de datos de la red a la que la entidad está asociada) y le añade sus cabeceras. Entonces, TCP pasa el segmento resultante a la capa IP, donde a través de la red, llega a la capa TCP de la entidad destino. TCP comprueba que ningún segmento se ha perdido dando a cada uno un número de secuencia, que es también 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 envío 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 dañados durante el envío 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 través del que se envía.
Puerto destino (16 bits): Identifica el puerto del receptor.
Número de secuencia (32 bits): Sirve para comprobar que ningún segmento se ha perdido, y que llegan en el orden correcto. Su significado varía dependiendo del valor de SYN:
Si el flag SYN está activo (1), entonces este campo indica el número inicial de secuencia (con lo cual el número de secuencia del primer byte de datos será este número de secuencia más uno).
Si el flag SYN no está activo (0), entonces este campo indica el número de secuencia del primer byte de datos.
Número de acuse de recibo (ACK) (32 bits): Si el flag ACK está puesto a activo, entonces en este campo contiene el número de secuencia del siguiente paquete que el receptor espera recibir.
Longitud de la cabecera TCP (4 bits): Especifica el tamaño de la cabecera TCP en palabras de 32-bits. El tamaño mínimo es de 5 palabras, y el máximo es de 15 palabras (lo cual equivale a un tamaño mínimo de 20 bytes y a un máximo de 60 bytes). En inglés el campo se denomina “Data offset”, que literalmente sería algo así como “desplazamiento hasta los datos”, ya que indica cuántos bytes hay entre el inicio del paquete TCP y el inicio de los datos.
Reservado (4 bits): Bits reservados para uso futuro, deberían 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 extensión del protocolo que fue añadida a la cabecera en el RFC 3168. Se utiliza para el control de la congestión en la red.
ECE o “ECN-Echo” (1 bit): Indica que el receptor puede realizar notificaciones ECN. La activación de este flag se realiza durante la negociación en tres pasos para el establecimiento de la conexión. Este flag también fue añadido 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 número de acuse de recibo es válido (si no, es ignorado).
PSH o “push” (1 bit, ver PSH): Activa/desactiva la función 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 aplicación receptora lo antes posible.
RST o “reset” (1 bit, ver Flag RST): Si llega a 1, termina la conexión sin esperar respuesta.
SYN o “synchronize” (1 bit, ver SYN): Activa/desactiva la sincronización de los números de secuencia.
FIN (1 bit, ver FIN): Si se activa es porque no hay más datos a enviar por parte del emisor, esto es, el paquete que lo lleva activo es el último de una conexión.
Ventana (16 bits): Es el tamaño de la ventana de recepción, que especifica el número de bytes que el receptor está actualmente esperando recibir.
Suma de verificación (checksum) (16 bits): Es una suma de verificación 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 número de secuencia que indica el último byte de datos marcados como “urgentes”.
Opciones (número de bits variable): La longitud total del campo de opciones ha de ser múltiplo de una palabra de 32 bits (si es menor, se ha de rellenar al múltiplo más cercano), y el campo que indica la longitud de la cabecera ha de estar ajustado de forma adecuada.
Datos (número 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 aplicación; los protocolos más comunes para los que se usan los datos de un paquete TCP son HTTP, telnet, SSH, FTP, etc.
[editar] Funcionamiento del protocolo en detalle
Las conexiones TCP se componen de tres etapas: establecimiento de conexión, transferencia de datos y fin de la conexión. Para establecer la conexión se usa el procedimiento llamado negociación en tres pasos (3-way handshake). Una negociación en cuatro pasos (4-way handshake) es usada para la desconexión. Durante el establecimiento de la conexión, algunos parámetros como el número de secuencia son configurados para asegurar la entrega ordenada de los datos y la robustez de la comunicación.

[editar] Establecimiento de la conexión (negociación en tres pasos)

Negociación en tres pasos o Three-way handshakeAunque es posible que un par de entidades finales comiencen una conexión entre ellas simultáneamente, normalmente una de ellas abre un socket en un determinado puerto tcp y se queda a la escucha de nuevas conexiones. Es común referirse a esto como apertura pasiva, y determina el lado servidor de una conexión. El lado cliente de una conexión realiza una apertura activa de un puerto enviando un paquete SYN inicial al servidor como parte de la negociación en tres pasos. En el lado del servidor se comprueba si el puerto está abierto, es decir, si existe algún proceso escuchando en ese puerto. En caso de no estarlo, se envía al cliente un paquete de respuesta con el bit RST activado, lo que significa el rechazo del intento de conexión. En caso de que sí se encuentre abierto el puerto, el lado servidor respondería a la petición SYN válida con un paquete SYN/ACK. Finalmente, el cliente debería responderle al servidor con un ACK, completando así la negociación en tres pasos (SYN, SYN/ACK y ACK) y la fase de establecimiento de conexión.

Es interesante notar que existe un número de secuencia generado por cada lado, ayudando de este modo a que no se puedan establecer conexiones falseadas (spoofing).

[editar] Transferencia de datos
Durante la etapa de transferencia de datos, una serie de mecanismos claves determinan la fiabilidad y robustez del protocolo. Entre ellos están incluidos el uso del número de secuencia para ordenar los segmentos TCP recibidos y detectar paquetes duplicados, checksums para detectar errores, y asentimientos y temporizadores para detectar pérdidas y retrasos.

Durante el establecimiento de conexión TCP, los números iniciales de secuencia son intercambiados entre las dos entidades TCP. Estos números 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 aplicación. Siempre hay un par de números de secuencia incluidos en todo segmento TCP, referidos al número de secuencia y al número de asentimiento. Un emisor TCP se refiere a su propio número de secuencia cuando habla de número de secuencia, mientras que con el número de asentimiento se refiere al número 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 través del uso de números de secuencia y asentimiento, TCP puede pasar los segmentos recibidos en el orden correcto dentro del flujo de bytes a la aplicación receptora. Los números de secuencia son de 32 bits (sin signo), que vuelve a cero tras el siguiente byte después del 232-1. Una de las claves para mantener la robustez y la seguridad de las conexiones TCP es la selección del número 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 transmisión del segmento. Se usa la suma en complemento a uno porque el acarreo final de ese método puede ser calculado en cualquier múltiplo de su tamaño (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 cálculos, salvando en algún 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 también cubre los 96 bit de la cabecera que contiene la dirección origen, la dirección destino, el protocolo y el tamaño TCP. Esto proporciona protección contra paquetes mal dirigidos por errores en las direcciones.

El checksum de TCP es una comprobación bastante débil. En niveles de enlace con una alta probabilidad de error de bit quizá requiera una capacidad adicional de corrección/detección de errores de enlace. Si TCP fuese rediseñado hoy, muy probablemente tendría un código de redundancia cíclica (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 tráfico 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 mayoría 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 congestión de la red (la idea es enviar tan rápido como el receptor pueda recibir). Estos mecanismos incluyen el uso de ventana deslizante, que controla que el transmisor mande información dentro de los límites del buffer del receptor, y algoritmos de control de flujo, tales como el algoritmo de Evitación de la Congestión (congestion avoidance), el de comienzo lento (Slow-start), el de retransmisión rápida, el de recuperación rápida (Fast Recovery), y otros.

[editar] Tamaño de ventana TCP
El tamaño de la ventana de recepción TCP es la cantidad de datos recibidos (en bytes) que pueden ser metidos en el buffer de recepción durante la conexión. La entidad emisora puede enviar una cantidad determinada de datos pero antes debe esperar un asentimiento con la actualización del tamaño de ventana por parte del receptor.

Un ejemplo sería el siguiente: un receptor comienza con un tamaño de ventana x y recibe y bytes, entonces su tamaño de ventana será (x - y) y el transmisor sólo podrá mandar paquetes con un tamaño máximo de datos de (x - y) bytes. Los siguientes paquetes recibidos seguirán restando tamaño a la ventana de recepción. Esta situación seguirá así hasta que la aplicación receptora recoja los datos del buffer de recepción. Yes

[editar] Escalado de ventana
Para una mayor eficiencia en redes de gran ancho de banda, debe ser usado un tamaño de ventana mayor. El campo TCP de tamaño de ventana controla el movimiento de datos y está limitado a 16 bits, es decir, a un tamaño 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 opción usada para incrementar el máximo tamaño de ventana desde 65.535 bytes, a 1 Gigabyte.

La opción de escala de ventana TCP es usada solo durante la negociación en tres pasos que constituye el comienzo de la conexión. El valor de la escala representa el número de bits desplazados a la izquierda de los 16 bits que forman el campo del tamaño de ventana. El valor de la escala puede ir desde 0 (sin desplazamiento) hasta 14. Hay que recordar que un número binario desplazado un bit a la izquierda es como multiplicarlo en base decimal por 2.

[editar] Fin de la conexión

Cierre de una conexión según el estándar.La fase de finalización de la conexión usa una negociación en cuatro pasos (four-way handshake), terminando la conexión desde cada lado independientemente. Cuando uno de los dos extremos de la conexión desea parar su "mitad" de conexión transmite un paquete FIN, que el otro interlocutor asentirá con un ACK. Por tanto, una desconexión típica requiere un par de segmentos FIN y ACK desde cada lado de la conexión.

Una conexión 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 conexión no puede enviar más datos pero la otra parte si podrá.

[editar] Puertos TCP
TCP usa el concepto de número de puerto para identificar a las aplicaciones emisoras y receptoras. Cada lado de la conexión TCP tiene asociado un número de puerto (de 16 bits sin signo, con lo que existen 65536 puertos posibles) asignado por la aplicación emisora o receptora. Los puertos son clasificados en tres categorías: bien conocidos, registrados y dinámicos/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 también pueden representar servicios que hayan sido registrados por un tercero (rango de puertos registrados: 1024 al 49151). Los puertos dinámicos/privados también pueden ser usados por las aplicaciones de usuario, pero este caso es menos común. Los puertos dinámicos/privados no tienen significado fuera de la conexión TCP en la que fueron usados (rango de puertos dinámicos/privados: 49152 al 65535, recordemos que el rango total de 2 elevado a la potencia 16, cubre 65536 números, del 0 al 65535)

[editar] Desarrollo de TCP
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 años, ha conservado las operaciones más básicas sin cambios desde el RFC 793, publicado en 1981. El documento RFC 1122 (Host Requirements for Internet Hosts), especifica el número de requisitos de una implementación del protocolo TCP. El RFC 2581 (Control de Congestión TCP) es uno de los más importantes documentos relativos a TCP de los últimos años, describe nuevos algoritmos para evitar la congestión excesiva. En 2001, el RFC 3168 fue escrito para describir la Notificación de Congestión Explícita (ECN), una forma de eludir la congestión con mecanismos de señalización. En los comienzos del siglo XXI, TCP es usado en el 95% de todos los paquetes que circulan por Internet. Entre las aplicaciones más comunes que usan TCP están HTTP/HTTPS (World Wide Web), SMTP/POP3/IMAP (correo electrónico) y FTP (transferencia de ficheros). Su amplia extensión ha sido la prueba para los desarrolladores originales de que su creación estaba excepcionalmente bien hecha.

Recientemente, un nuevo algoritmo de control de congestión fue desarrollado y nombrado como FAST TCP (Fast Active queue management Scalable Transmission Control Protocol) por los científicos de Caltech (California Institute of Technology). Es similar a TCP Vegas en cuanto a que ambos detectan la congestión a partir de los retrasos en las colas que sufren los paquetes al ser enviados a su destino. Todavía hay un debate abierto sobre si éste es un síntoma apropiado para el control de la congestión.

DIFERENCIAS ENTRE LOS PROTOCOLOS TCP Y UDP

El protocolo UDP

UDP es un protocolo no orientado a conexión. Es decir cuando una maquina A envía paquetes a una maquina B, el flujo es unidireccional. La transferencia de datos es realizada sin haber realizado previamente una conexión con la maquina de destino (maquina B), y el destinatario recibirá los datos sin enviar una confirmación al emisor (la maquina A). Esto es debido a que la encapsulación de datos enviada por el protocolo UDP no permite transmitir la información relacionada al emisor. Por ello el destinatario no conocerá al emisor de los datos excepto su IP.
El protocolo TCP

Contrariamente a UDP, el protocolo TCP está orientado a conexión. Cuando una máquina A envía datos a una máquina B, la máquina B es informada de la llegada de datos, y confirma su buena recepción. Aquí interviene el control CRC de datos que se basa en una ecuación matemática que permite verificar la integridad de los datos transmitidos. De este modo, si los datos recibidos son corruptos, el protocolo TCP permite que los destinatarios soliciten al emisor que vuelvan a enviar los datos corruptos.

PROTOCOLOS SMTP, POP3 e IMAP4

Introducción al correo electrónico
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.
El protocolo SMTP
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.

É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.

A continuación se describe una situación en la que se realiza una solicitud para enviar correos a un servidor SMTP:

Al abrir la sesión SMTP, el primer comando que se envía es el comando HELO seguido por un espacio (escrito ) y el nombre de dominio de su equipo (para decir "hola, soy este equipo"), y después validado por Enter (escrito ). 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.
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".
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".
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. El cuerpo del correo electrónico eventualmente contenga algunos de los siguientes encabezados:
Date (Fecha)
Subject (Asunto)
Cc
Bcc (Cco)
From (De)
Si se acepta el comando, el servidor responde con un mensaje "250 OK".
A continuación se describe un ejemplo de transacción entre un cliente (C) y un servidor SMTP (S):
S: 220 smtp.commentcamarche.net SMTP Ready C: EHLO machine1.commentcamarche.net S: 250 smtp.commentcamarche.net C: MAIL FROM: S: 250 OK C: RCPT TO: S: 250 C: RCPT TO: S: 550 No such user here C: DATA S: 354 Start mail input; end with . C: Subject: Hola C: Hola Meandus: C: ¿Cómo andan tus cosas? C: C: ¡Nos vemos pronto! C: . S: 250 C: QUIT R: 221 smtp.commentcamarche.net closing transmission
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:

base64 para archivos adjuntos
quoted-printable (abreviado QP) para caracteres especiales utilizados en el cuerpo del mensaje
Por lo tanto, es posible enviar un correo electrónico utilizando un simple telnet al puerto 25 del servidor SMTP:

telnet smtp.commentcamarche.net 25
(El servidor indicado anteriormente no existe. Intente reemplazar commentcamarche.net por el nombre de dominio de su proveedor de servicios de Internet.
A continuación se brinda un resumen de los principales comandos SMTP:



Comando Ejemplo Descripción
HELO (ahora EHLO) EHLO 193.56.47.125 Identificación que utiliza la dirección IP o el nombre de dominio del equipo remitente
MAIL FROM: MAIL FROM: originator@domain.com Identificación de la dirección del remitente
RCPT TO: RCPT TO: recipient@domain.com Identificación de la dirección del destinatario
DATA DATA message Cuerpo del correo electrónico
QUIT QUIT Salida del servidor SMTP
HELP HELP Lista de comandos SMTP que el servidor admite



Todas las especificaciones del protocolo SMTP se encuentran definidas en RFC 821 (desde abril de 2001, las especificaciones del protocolo SMTP se encuentran definidas en RFC 2821).
El protocolo POP3
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.

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.

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.

A continuación se brinda un resumen de los principales comandos POP2:





Comandos POP2
Comando Descripción
HELLO Identificación que utiliza la dirección IP del equipo remitente
FOLDER Nombre de la bandeja de entrada que se va a consultar
READ Número del mensaje que se va a leer
RETRIEVE Número del mensaje que se va a recoger
SAVE Número del mensaje que se va a guardar
DELETE Número del mensaje que se va a eliminar
QUIT Salida del servidor POP2



A continuación se brinda un resumen de los principales comandos POP3:





Comandos POP3
Comando Descripción
USER identification Este comando permite la autenticación. Debe estar seguido del nombre de usuario, es decir, una cadena de caracteres que identifique al usuario en el servidor. El comando USER debe preceder al comando PASS.
PASS password El comando PASS permite especificar la contraseña del usuario cuyo nombre ha sido especificado por un comando USER previo.
STAT Información acerca de los mensajes del servidor
RETR Número del mensaje que se va a recoger
DELE Número del mensaje que se va a eliminar
LIST [msg] Número del mensaje que se va a mostrar
NOOP Permite mantener la conexión abierta en caso de inactividad
TOP Comando que muestra n líneas del mensaje, cuyo número se da en el argumento. En el caso de una respuesta positiva del servidor, éste enviará de vuelta los encabezados del mensaje, después una línea en blanco y finalmente las primeras n líneas del mensaje.
UIDL [msg] Solicitud al servidor para que envíe una línea que contenga información sobre el mensaje que eventualmente se dará en el argumento. Esta línea contiene una cadena de caracteres denominada unique identifier listing (lista de identificadores únicos) que permite identificar de manera única el mensaje en el servidor, independientemente de la sesión. El argumento opcional es un número relacionado con un mensaje existente en el servidor POP, es decir, un mensaje que no se ha borrado.
QUIT El comando QUIT solicita la salida del servidor POP3. Lleva a la eliminación de todos los mensajes marcados como eliminados y envía el estado de esta acción.



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.

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):

telnet mail.commentcamarche.net 110
(El servidor indicado anteriormente no existe. Intente reemplazar commentcamarche.net por el nombre de dominio de su proveedor de servicios de Internet.)
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


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).
El protocolo IMAP
El protocolo IMAP (Protocolo de acceso a mensajes de Internet) es un protocolo alternativo al de POP3, pero que ofrece más posibilidades:

IMAP permite administrar diversos accesos de manera simultánea
IMAP permite administrar diversas bandejas de entrada
IMAP brinda más criterios que pueden utilizarse para ordenar los correos electrónicos

E:\Protocolos De Redes

Check out this SlideShare Presentation:

¿COMO FUNCIONA LA DESCARGA Y VISIONADO DE PAGINAS WEB?

1. El usuario especifica en el cliente web la dirección URL de la página que desea consultar.
2. El cliente se conecta al servidor web.
3. El cliente solicita la página o el objeto deseado.
4. El servidor se encarga de buscar el documento HTML solicitado por el cliente en su sistema de ficheros, si lo encuentra lo envía y cierra la conexión; en caso de no encontrarlo, le envía un código de error al cliente y cierra la conexión.
5. El cliente interpreta los códigos HTML y muestra la página web al usuario.
6. Se cierra la conexión.
Para cada documento u objeto que se transmite se establece una conexión independiente.

FUNCIONAMIENTO DE LA WEB

¿Cómo funciona la web?
La web funciona siguiendo el modelo cliente-servidor. Un servidor se encarga de prestar el servicio, y un cliente que es quien recibe dicho servicio.

¿Qué es un cliente web?
Es un programa mediante el cual el usuario solicita a un servidor web el envío de información. Esta información se transfiere mediante el protocolo HTTP.

¿Qué información se recibe?
La información que se recibe es un conjunto de documentos de texto codificados en lenguaje HTML. El cliente web debe interpretar estos documentos para mostrárselos al usuario en el formato correspondiente. Cuando la información recibida no es un documento de texto, sino un objeto multimedia que el cliente no sabe interpretar, el propio cliente web debe activar una aplicación externa encargada de gestionarlo.

Clientes web más habituales
Los clientes web más habituales son Microsoft Internet Explorer, Mozilla Firefox y Netscape Navigator.

¿Qué es un servidor web?
Es un programa que está permanentemente escuchando las peticiones de conexión de los clientes mediante el protocolo HTTP.
El funcionamiento del servidor web consiste en buscar el documento HTML solicitado por el cliente en su sistema de ficheros, si lo encuentra lo envía y cierra la conexión; en caso de no encontrarlo, le envía un código de error al cliente y cierra la conexión.

EL HIPERTEXTO Y LA WEB

¿Qué es el hipertexto?
El hipertexto es por definición únicamente texto con enlaces. Los documentos de hipertexto pueden contener enlaces, que no son más que referencias partes del propio documento o a otros documentos. El término hipertexto lo introdujo Ted Nelson en 1965.

El hipertexto supone una ampliación del concepto habitual de texto al permitir que una serie de documentos enlazados unos con otros y posiblemente ubicados en lugares remotos aparezcan formando una unidad.

¿Cómo se establecen las relaciones entre documentos?
Las referencias entre las partes de un documento de hipertexto se establecen mediante enlaces.
El hipertexto da un gran salto con el desarrollo de internet, ya que un documento puede estar físicamente distribuido en distintas máquinas conectadas entre sí. Esta es la idea que da origen a la web.

¿Cuándo se creó la web?
La web fue creada en 1989 por Tim Berners-Lee en el CERN (Ginebra) para compartir información entre grupos de investigadores que se encontraban en diversos lugares del mundo, y lo hicieron por medio del hipertexto.

¿Cuál era la idea originaria de la web?
En la página web del W3C puede conocerse la forma original de la web según Tim Berners-Lee.

Las ideas básicas de la web eran:
• Desaparición de la idea de un servidor único de información mantenido por un equipo de profesionales dedicado.
• Especificación de un mecanismo para localizar de forma unívoca documentos distribuidos geográficamente. Cada documento tiene una dirección llamada URL (Uniform Resource Locutor).
• Una interfaz de usuario uniforme que esconde los detalles de los formatos y protocolos utilizados para la transferencia de la información, simplificando por tanto el acceso a la misma. Los programas que utilizan estas interfaces son los navegadores.
• El elemento básico de la web es la página web, un documento que contiene enlaces de hipertexto a otros documentos relacionados que pueden estar localizados en la propia máquina o en máquinas remotas.
El protocolo de la web especifica un formato para escribir los documentos que forman parte de ella, el HTML ( Hypertext Markup Language).

PROTOCOLOS DE INTERNET

¿Cómo funciona Internet?
Internet es una red formada por miles de redes independientes pertenecientes a instituciones públicas, centros de investigación, empresas privadas y otras organizaciones. Las normas que aseguran la comunicación entre las redes son los denominados protocolos de internet.


¿Qué protocolos existen?
Hay diversos protocolos dependiendo del tipo de comunicación que se establece entre las máquinas. El protocolo HTTP (HyperText Transfer Protocol) es la base de la web, también está el FTP (File Transfer Protocol) para transferencia de archivos o el SMTP y POP para correo.


¿Qué es la web?
La web es un sistema que facilita el acceso a los distintos recursos que ofrece internet a través de una interfaz común basada en el hipertexto. La web se ha hecho enormemente popular con la aparición de unos programas dotados de interfaces gráficas amigables que permiten a cualquier persona acceder a los documentos de la red: son los conocidos navegadores.

PROTOCOLOS DE INTERNET 2

§1 Sinopsis
En la sección 3.1 hemos señalado que las comunicaciones Internet se denominan también comunicaciones TCP/IP debido al nombre de dos de los protocolos más significativos que utilizan, pero que estos no son los únicos. A fin de que el lector pueda tener una idea aproximada de su misión y significado, a continuación se muestra una selección de los más usuales.

§2 Internet Protocol (IP)
Ya hemos señalado que es uno de los protocolos fundamentales de Internet. En el modelo OSI ( 3.1) pertenece a la denominada subcapa de transporte dentro de la capa de Red. Absolutamente todas las aplicaciones de Internet deben usar este protocolo cuya especificación está contenida en RFC 791.

Entre sus responsabilidades se encuentra fragmentar los datos a transmitir que han sido recibidos de la capa superior (de Transporte) en trozos denominados datagramas IP. Estos datagramas son entregados a la capa inferior (de Enlace) donde son empaquetados en cuadros ("Frames") y entregados a la capa que se encarga de controlar el medio físico sobre el que se efectúa la transmisión (capa Física). El proceso es exactamente inverso para los paquetes recibidos. La tabla adjunta muestra el esquema interno de un datagrama IP (tamaño T del campo en bits).

Campo
T
Descripción

VERS
4
Versión de IP utilizada para la creación del datagrama

datagrama

HLEN
4
Longitud de la cabecera (palabras de 32 bits)

SERVICE TYPE
8
Indicador de servicio. Especifica como debe ser interpretado

TOTAL LENGTH
16
Longitud total del datagrama (bytes) [3]

IDENTIFICATION
16
Número generado por el remitente que asegura el correcto ensamblado por el receptor

FLAGS
3
Distintos indicadores. Por ejemplo MORE FLAGS, que indica si el campo ha sido fragmentado (es una porción de un un todo).

FRAGMENT OFFSET
13
Si es un trozo de algo fragmentado, señala la posición del fragmento en el total [4].

TIME TO LIVE
8
Cuantos saltos se espera que viva el datagrama antes de ser destruido, si no ha alcanzado su destino

PROTOCOL
8
Señala el protocolo de alto nivel al que corresponden los datos en la porción de datos del datagrama.

HEADER CHECKSUM
16
Suma de control de la cabecera. Es comprobada en cada punto donde el datagrama es procesado.

SOURCE ADDRESS
32
Dirección IP del remitente

DESTINATION ADDRESS
32
Dirección IP del destinatario.

OPTIONS
Variable
Zona reservada para uso diverso. Generalmente utilidades de chequeo y depuración.

PADDING
Variable
Cierta cantidad de ceros necesarios para que el tamaño de la cabecera sea un múltiplo de 32 bits.



Otra responsabilidad de este protocolo es decidir el camino más adecuado para los datagramas en caso que haya más de uno disponible. Esto es conocido como enrutado ("Routing").

Una característica distintiva de éste protocolo es que cada paquete es enviado como si fuese una entidad independiente de las demás. De forma que IP no mantiene ningún control sobre los detalles de la conexión entre las máquinas que dialogan (el cliente y el servidor). Tampoco garantiza que la transmisión se realice con éxito. Esta función es encomendada a otros protocolos de la cadena.

§3 Internet Control Message Protocol (ICMP)
Es un protocolo que podíamos denominar "auxiliar" de la transmisión, ya que está más orientado a la calidad de la transmisión que a la transmisión en sí misma. Es responsable de generar mensajes cuando ocurren errores en la transmisión. También puede generar mensajes de prueba e informativos sobre la transmisión, incluyendo un modo especial de eco que puede manejarse mediante PING ("Packet Internetwork Goper" Ap.C)

§4 Internet Group Management Protocol (IGMP)
El protocolo IGMP funciona como una extensión del protocolo IP. Se emplea para realizar IP multicast, es decir, cuando el envío de datos a una dirección IP puede alcanzar múltiples servidores de una red y/o a todas las máquinas de una subred. Además de utilizarse para pasar información se utiliza para establecer los miembros de la red, pasar información de los miembros y establecer rutas. Otros muchos protocolos hacen uso de las funciones IGMP dentro de sus especificaciones.

§5 Gateway-to-Gateway Protocol (GGP)
.

§6 Transmission Control Protocol (TCP)
.

§7 Exterior Gateway Protocol (EGP)
.

§8 Interior Gateway Protocol (IGP)
.

§9 User Datagram Protocol (UDP)
Protocolo para transmisiones que pueden permitirse ciertos errores (pérdida de paquetes) a cambio de un incremento en la velocidad. Es aplicado en transmisiones de Video en tiempo real (por ejemplo RealPlayer) que ignora los marcos erróneos y en otras comunicaciones Internet como DNS. Ofrece mucho menos control que TCP , por lo que también ha sido descrito como "Unreliable Datagram Protocol". No puede garantizar el orden de llegada de los paquetes ni tampoco la llegada en sí, sin embargo garantiza menor tiempo de respuesta que TCP. Está descrito en RFC 768.

§10 Dynamic Host Configuration Protocol (DHCP)
Este protocolo permite simplificar la administración de grandes redes IP, permitiendo que los equipos individuales de una red puedan obtener sus datos de configuración desde un servidor especial (servidor DHCP), en especial en aquellas redes en las que no se tiene información exacta sobre los equipos individuales hasta que estos no recaban la información. Es el caso típico de muchos proveedores de servicios de Internet (ISPs) y de redes a las que se conectan portátiles o empleados de forma remota ( 3.6).

§11 HiperText Transfer Protocol (HTTP)
Es el protocolo utilizado para transmitir las páginas Web escritas en lenguaje de marcas de hipertexto HTML ("Hyper Text Markup Languaje" 5.2).

§12 Simple Mail Transfer Protocol (SMTP)
Protocolo encargado de transmitir los mensajes de correo de un servidor a otro. Una vez que los mensajes están en el servidor de destino se utiliza otro protocolo (POP ) para llevarlo a la máquina del cliente final.

§13 Post Office Protocol (POP)
Es el protocolo que permite a un usuario leer el correo que llega a su servidor. Es un protocolo para las comunicaciones Servidor a Usuario. No confundir con SMTP que es un protocolo para transmisiones entre servidores.

Existen tres versiones: POP, POP2, y POP3. Cuando recibimos un e-mail queda almacenado en el servidor hasta que conectamos con él mediante el cliente de correo (un programa) y nos autentificamos (proporcionamos un nombre de usuario y contraseña correctos). Después de esto POP es utilizado para transferir los datos desde el servidor al buzón de correo entrante de nuestra propia máquina. Eventualmente una vez recibida la copia es posible ordenar al servidor que borre los ficheros originales.

Existe otro protocolo que permite manejar el correo en el servidor. Es IMAP (ver), cuya diferencia fundamental con POP es que este último se limita a pasar los mensajes al cliente autenticado, mientras que IMAP pone el control del correo electrónico en manos del servidor.

POP3S es el protocolo de cifrado POP3 mediante SSL ("Secure Sockets Layer").

Nota: SSL es un protocolo propuesto en 1994 por Netscape Communications junto con la primera versión de su navegador Navigator. A pesar de que últimamente se le han encontrado algunas vulnerabilidades, es la opción implantada en la mayoría de servidores Web que requieren sistema de seguridad. Por ejemplo, servicios de comercio o correo electrónico seguros o controlar accesos a servicios de pago basados en la Web. Utiliza un sistema de cifrado y descifrado de datos RSA de clave pública [1]. Mas información en: 6.4 Cifrado y firmas digitales. N.14 El sistema RSA y los intentos para descifrarlo. N.17 La seguridad del Sistema RSA; estado de la cuestión.

§14 File Transfer Protocol (FTP)
El protocolo FTP es uno de los más utilizados en Internet, ya que permite transferir ficheros entre dos máquinas utilizando una conexión Internet. El protocolo dispone de una serie de formas estandarizadas por las que una máquina remota puede crear y cambiar directorios en la máquina local, así como transferir, copiar, mover y borrar ficheros. En realidad FTP utiliza comandos de texto plano para indicar las diversas órdenes, pero existen multitud de programas que simplifican su utilización mediante una interfaz gráfica en la que las operaciones de transferencia se reducen a procesos de cortar y pegar y en las que recorrer el árbol de directorios de la máquina remota es tan fácil como utilizar el navegador en la propia máquina.

Más información en: 8.2 FTP Transferencia de ficheros.

§15 Point to Point Protocol (PPP)
Un protocolo utilizado para enviar paquetes punto-a-punto sobre líneas serie. Es uno de los más utilizados, ya que soporta las comunicaciones sobre líneas telefónicas a través de módem (el módem utiliza una conexión serie). Permite utilizar sobre él otros protocolos de más alto nivel (más cercanos a la capa de Aplicación), como IPX/SPX y TCP/IP. Cuando la comunicación es a través de línea telefónica, pero en vez de ser convencional (RTB) es ADSL ( 7.2), se utiliza una variedad denominada PPPoE (PPP over Ethernet).

PPP también puede ser utilizado sobre conexiones de red distintas de las telefónicas. Windows lo instala cuando se instala un módem o servicio de RAS [2]. Una versión antigua de este protocolo que se utilizaba exclusivamente para conectar a servidores Unix de acceso remoto se denomina SLIP ("Seriar Line IP").

§16 Network News Transfer Protocol (NNTP)
Este protocolo, Creado en 1986 Kantor y Lampsley y descrito en RFC 977, es utilizado para distribuir en Internet un tipo especial de mensajes denominados noticias ("News") entre unas máquinas configuradas como servidores y los clientes (los lectores de las noticias). El sistema constituye un servicio que transfiere diariamente millones de mensajes clasificados por temas denominado Usenet ( 8.4), y cuya importancia en cuanto a la comunicación de ideas y opiniones es solo comparable al servicio de e-mail.

El formato de las noticias (muy parecido al de e-mail), fue definido en RFC 850 por Mark Horton. La versión actual está descrita en RFC 1036. Su diferencia conceptual más importante respecto al e-mail es que en éste, el mensaje es accesible únicamente por su destinatario, mientras que los mensajes de Usenet aparecen en un tablón de anuncios accesible por todos.

NNTP proporciona distribución, consulta, recuperación y exposición de "News" mediante el uso de una transmisión confiable basada en secuencias de noticias relacionadas. NNTP está diseñado de forma que las noticias se almacenan en una base de datos centralizada en un servidor, de manera que los usuarios pueden seleccionar elementos específicos que leer. También se proporciona indización, las referencias cruzadas y la caducidad de mensajes antiguos.

§17 Protocolos de encaminamiento
Son utilizados por herramientas auxiliares cuyo fin último es construir las tablas de ruta ( Ap. A) de los encaminadores ("Routers"). Esta función puede ser realizada manualmente en caso de redes pequeñas, pero es una tarea muy ardua en caso de redes medianas, e imposible en caso de redes extensas (Internet), ya que la tabla de ruta depende de la topología de la red, y esta puede cambiar con relativa frecuencia. Por esta razón, los routers utilizan algoritmos que realizan el análisis de forma automática intercambiando información con otros routers.

Existen varios de estos protocolos según se trate de construir las tablas de redes privadas o externas (Internet). Los primeros son denominados protocolos de enrutamiento interno, el más importante de los cuales es RIP ("Routing Information Protocol") definido en la RFC 1058. Sin embargo es bastante ineficiente porque exige a los routers intercambiar periódicamente tablas completas. Actualmente está siendo reemplazado por OSPF ("Open Shortest Path First") definido en RFC 1583 que es más eficiente.

Para las tablas entre redes independientes se utilizan los protocolos de enrutamiento externo, como EGP ("External Gateway Protocol") y BGP ("Border Gateway Protocol") definido en RFC 1771.

§18 Webografía
Si quiere profundizar el los aspectos técnicos de las comunicaciones IP, la Web de Cisco Systems (líder mundial en fabricación de quipos para comunicación IP) es una fuente inagotable de información.

•Cisco Systems Technology Support www.cisco.com/

VOZ SOBRE PROTOCOLO DE INTERNET

1. Introducción
En el presente artículo damos a conocer información sobre la telefonía VoIP ( Voz transmitida sobre Protocolo de Internet ), la cual permite a los usuarios realizar llamadas de voz y fax sobre conexiones IP ( Internet, Intranets, etc. ).

La Voz transmitida sobre IP ( VoIP ), ya ha estado presente por mucho tiempo en el mercado, pero la aparición de nuevos e innovadores servicios en esta tecnología han hecho realidad la integración de datos y voz, lo cual significa para muchas empresas un ahorro de costos y que las comunicaciones sean más eficientes y efectivas.
2. Definición
La VoIP ( Voz transmitida sobre Protocolo de Internet ) es una tecnología nueva que permite la transmisión de la voz a través de redes IP (Protocolo de Internet) en forma de paquetes de datos.

La VoIP ( Voice over Internet Protocol ) denominada así por sus siglas en inglés, lo que significa Voz transmitida sobre Protocolo de Internet, esta industria se encuentra en una etapa de crecimiento muy rápido, es un hecho que en el año 2010 una gran parte de las llamadas mundiales se basaran en IP ( Protocolo de Internet ).

La Voz transmitida sobre IP es una tecnología que puede ser habilitada mediante una red de datos de conmutación de paquetes, vía el protocolo IP ( Protocolo de Internet ), una importante ventaja de esta tecnología es la transmisión de voz de manera gratuita, ya que esta información viaja a través de la red como datos.

La tecnología de telefonía VoIP (Voz transmitida sobre Protocolo de Internet ) ofrece lo siguiente:

- Acceso a redes corporativas a través de redes integradas de voz y datos.

- Servicios de directorio y de conferencias realizadas en gráficos mediante un sistema llamado sistema de sobremesa.

- Directorios corporativos (Intranet ), con servicio de mensajes.

- Redes Privadas Virtuales y Gateways Virtuales para voz.




[editar]

3. Elementos de la VoIP ( Voz transmitida sobre IP )
a. El cliente

El cliente establece y termina las llamadas realizadas de voz, esta información se codifica, se empaqueta y se transmite a través del micrófono (entrada de información ) del usuario, de la misma forma la información se decodifica y reproduce a través de los altavoces o audifonos (salida de la información).

b. Los Servidores

Los servidores se encargan de manejar operaciones de base de datos, realizado en un tiempo real como en uno fuera de él. Entre estas operaciones se tienen la contabilidad, la recolección, el enrutamiento, la administración y control del servicio, el registro de los usuarios, etc.


c. Los Gateways

Los Gateways brindan un puente de comunicación entre todos los usuarios, su función principal es la de proveer interfaces con la telefonía tradicional adecuada, la cual funcionara como una plataforma para los usuarios (clientes) virtuales.

[editar]

4. Características de VoIP ( Voz transmitida sobre IP )
- VoIP nos permite el control del tráfico que existe en la red.

- Proporciona un enlace a la red de telefonía tradicional.

- Permite una integración con grandes redes de IP ( Protocolo de Internet ) actuales, ya que es independiente en su tipo de red física.




[editar]

5. Ventajas de VoIP
- Una importante ventaja es que no hay que pagarle a las compañías telefónicas por la comunicación.

- Tiene integración sobre la Intranet de la voz como cualquier servicio de la red.

- Existe interoperabilidad de diversos proveedores.

- Tiene independencia en las tecnologías de transporte.

- Tiene menores costos que otras tecnologías.

- VoIP no paga la tarifa de llamadas larga distancia.

[editar]

6. Desventajas de VoIP
- Una desventaja importante es la calidad de la transmisión es un poco inferior a la telefónica, ya que los datos viajan en forma de paquetes, es por eso que se puede tener algunas perdidas de información y demora en la transmisión.

- El problema en si de la VoIP, no es el protocolo si no la red IP, ya que esta no fue pensada para dar algún tipo de garantías.

- Otra desventaja es la latencia , ya que cuando el usuario está hablando y otro usuario está escuchando, no es adecuado tener 200ms (microsegundos) de pausa en la transmisión.

- Cuando se va a utilizar VoIP, se debe controlar el uso de la red para garantizar una transmisión de calidad.

V0Z SOBRE IP

Voz sobre Protocolo de Internet, también llamado Voz IP, VozIP, VoIP (por sus siglas en inglés), es un grupo de recursos que hacen posible que la señal de voz viaje a través de Internet empleando un protocolo IP (Protocolo de Internet). Esto significa que se envía la señal de voz en forma digital, en paquetes, en lugar de enviarla en forma analógica, a través de circuitos utilizables sólo para telefonía como una compañía telefónica convencional o PSTN (sigla de Public Switched Telephone Network, Red Telefónica Pública Conmutada).

Los Protocolos que se usan para enviar las señales de voz sobre la red IP se conocen como protocolos de Voz sobre IP o protocolos IP. Estos pueden verse como aplicaciones comerciales de la "Red experimental de Protocolo de Voz" (1973), inventada por ARPANET.

El tráfico de Voz sobre IP puede circular por cualquier red IP, incluyendo aquellas conectadas a Internet, como por ejemplo las redes de área local (LAN).

Es muy importante diferenciar entre Voz sobre IP (VoIP) y Telefonía sobre IP.

VoIP es el conjunto de normas, dispositivos, protocolos, en definitiva la tecnología que permite comunicar voz sobre el protocolo IP.
Telefonía sobre IP es el servicio telefónico disponible al público, por tanto con numeración E.164, realizado con tecnología de VoIP.

25 AÑOS DEL PROTCOLO TCP/IP

Los protocolos usados en TCP/IP unicamente usados en capas 2 y 3 Acaban de cumplirse 25 años de la transición definitiva de ARPANET a la familia de protocolos de TCP/IP. Este hecho, producido el 1 de enero de 1983, se menciona en el artículo Historia de Internet y existen fuentes en Internet que lo corroboran. Los protocolos en sí son un poco más antiguos. Concretamente, las especificaciones de IP y TCP se publicaron en septiembre de 1981 como RFC 791 y RFC 793.

VENTAJS E INCONVENIENTES

El conjunto TCP/IP está diseñado para enrutar y tiene un grado muy elevado de fiabilidad, es adecuado para redes grandes y medianas, así como en redes empresariales. Se utiliza a nivel mundial para conectarse a Internet y a los servidores web. Es compatible con las herramientas estándar para analizar el funcionamiento de la red.

Un inconveniente de TCP/IP es que es más difícil de configurar y de mantener que NetBEUI o IPX/SPX; además es algo más lento en redes con un volumen de tráfico medio bajo. Sin embargo, puede ser más rápido en redes con un volumen de tráfico grande donde haya que enrutar un gran número de tramas.

El conjunto TCP/IP se utiliza tanto en campus universitarios como en complejos empresariales, en donde utilizan muchos enrutadores y conexiones a mainframe o a ordenadores UNIX, así como también en redes pequeñas o domésticas, e incluso en teléfonos móviles y en domótica.

HIISTORIA DEL PROTCOLO TCP/IP

La Familia de Protocolos de Internet fueron el resultado del trabajo llevado a cabo por la Agencia de Investigación de Proyectos Avanzados de Defensa (DARPA por sus siglas en inglés) a principios de los 70. Después de la construcción de la pionera ARPANET en 1969 DARPA comenzó a trabajar en un gran número de tecnologías de transmisión de datos. En 1972, Robert E. Kahn fue contratado por la Oficina de Técnicas de Procesamiento de Información de DARPA, donde trabajó en la comunicación de paquetes por satélite y por ondas de radio, reconoció el importante valor de la comunicación de estas dos formas. En la primavera de 1973, Vint Cerf, desarrollador del protocolo de ARPANET, Network Control Program(NPC) se unió a Kahn con el objetivo de crear una arquitectura abierta de interconexión y diseñar así la nueva generación de protocolos de ARPANET.

Para el verano de 1973, Kahn y Cerf habían conseguido una remodelación fundamental, donde las diferencias entre los protocolos de red se ocultaban usando un Protocolo de comunicaciones y además, la red dejaba de ser responsable de la fiabilidad de la comunicación, como pasaba en ARPANET , era el host el responsable. Cerf reconoció el mérito de Hubert Zimmerman y Louis Pouzin, creadores de la red CYCLADES, ya que su trabajo estuvo muy influenciado por el diseño de esta red.

Con el papel que realizaban las redes en el proceso de comunicación reducido al mínimo, se convirtió en una posibilidad real comunicar redes diferentes, sin importar las características que éstas tuvieran. Hay un dicho popular sobre el protocolo TCP/IP, que fue el producto final desarrollado por Cerf y Kahn, que dice que este protocolo acabará funcionando incluso entre "dos latas unidas por un cordón". De hecho hay hasta una implementación usando palomas mensajeras, IP sobre palomas mensajeras, que está documentado en RFC 1149. [1] .[2]

Un ordenador denominado router (un nombre que fue después cambiado a gateway, puerta de enlace, para evitar confusiones con otros tipos de Puerta de enlace) esta dotado con una interfaz para cada red, y envía Datagramas de ida y vuelta entre ellos. Los requisitos para estos routers están definidos en el RFC 1812. [3]

Esta idea fue llevada a la práctica de una forma mas detallada por el grupo de investigación que Cerf tenía en Stanford durante el periodo de 1973 a 1974, dando como resultado la primera especificación TCP (Request for Comments 675,) [4] Entonces DARPA fue contratada por BBN Technologies, la Universidad de Stanford, y la University College de Londres para desarrollar versiones operacionales del protocolo en diferentes plataformas de hardware. Se desarrollaron así cuatro versiones diferentes: TCP v1, TCP v2, una tercera dividida en dos TCP v3 y IP v3 en la primavera de 1978, y después se estabilizó la versión TCP/IP v4 — el protocolo estándar que todavía se emplea en Internet.

En 1975, se realizó la primera prueba de comunicación entre dos redes con protocolos TCP/IP entre la Universidad de Stanford y la University College de Londres (UCL). En 1977, se realizó otra prueba de comunicación con un protocolo TCP/IP entre tres redes distintas con ubicaciones en Estados Unidos, Reino Unido y Noruega. Varios prototipos diferentes de protocolos TCP/IP se desarrollaron en múltiples centros de investigación entre los años 1978 y 1983. La migración completa de la red ARPANET al protocolo TCP/IP concluyó oficialmente el día 1 de enero de 1983 cuando los protocolos fueron activados permanentemente.[5]

En marzo de 1982, el Departamento de Defensa de los Estados Unidos declaró al protocolo TCP/IP el estándar para las comunicaciones entre redes militares.[6] En 1985, el Centro de Administración de Internet (Internet Architecture Board IAB por sus siglas en inglés) organizó un Taller de Trabajo de tres días de duración, al que asistieron 250 comerciales promocionando así el protocolo lo que contribuyó a un incremento de su uso comercial.

Kahn y Cerf fueron premiados con la Medalla Presidencial de la Libertad el 10 de noviembre de 2005 por su contribución a la cultura Americana.[7]

FAMILIA DE PROTOCOLOS DE INTERNET

La familia de protocolos de Internet es un conjunto de protocolos de red en los que se basa Internet y que permiten la transmisión de datos entre redes de computadoras. En ocasiones se le denomina conjunto de protocolos TCP/IP, en referencia a los dos protocolos más importantes que la componen: Protocolo de Control de Transmisión (TCP) y Protocolo de Internet (IP), que fueron los dos primeros en definirse, y que son los más utilizados de la familia. Existen tantos protocolos en este conjunto que llegan a ser más de 100 diferentes, entre ellos se encuentra el popular HTTP (HyperText Transfer Protocol), que es el que se utiliza para acceder a las páginas web, además de otros como el ARP (Address Resolution Protocol) para la resolución de direcciones, el FTP (File Transfer Protocol) para transferencia de archivos, y el SMTP (Simple Mail Transfer Protocol) y el POP (Post Office Protocol) para correo electrónico, TELNET para acceder a equipos remotos, entre otros.

El TCP/IP es la base de Internet, y sirve para enlazar computadoras que utilizan diferentes sistemas operativos, incluyendo PC, minicomputadoras y computadoras centrales sobre redes de área local (LAN) y área extensa (WAN).

TCP/IP fue desarrollado y demostrado por primera vez en 1972 por el Departamento de Defensa de los Estados Unidos, ejecutándolo en ARPANET, una red de área extensa de dicho departamento.

La familia de protocolos de Internet puede describirse por analogía con el modelo OSI (Open System Interconnection), que describe los niveles o capas de la pila de protocolos, aunque en la práctica no corresponde exactamente con el modelo en Internet. En una pila de protocolos, cada nivel soluciona una serie de problemas relacionados con la transmisión de datos, y proporciona un servicio bien definido a los niveles más altos. Los niveles superiores son los más cercanos al usuario y tratan con datos más abstractos, dejando a los niveles más bajos la labor de traducir los datos de forma que sean físicamente manipulables.

El modelo de Internet fue diseñado como la solución a un problema práctico de ingeniería.

El modelo OSI, en cambio, fue propuesto como una aproximación teórica y también como una primera fase en la evolución de las redes de ordenadores. Por lo tanto, el modelo OSI es más fácil de entender, pero el modelo TCP/IP es el que realmente se usa. Sirve de ayuda entender el modelo OSI antes de conocer TCP/IP, ya que se aplican los mismos principios, pero son más fáciles de entender en el modelo OSI.

El 1 de enero de 2010 el Protocolo TCP/IP cumplió 27 años.

jueves, 30 de septiembre de 2010