Protocolos de comunicación

En la actualidad contamos con muchos protocolos de comunicación comerciales con los cuales muchas veces aun sin darnos cuenta, los utilizamos, nos ayudan a hacer tareas como lo son el Internet, una transferencia por módem o una simple comunicación a un servicio en línea inteligente de algún banco (BITAL).

A continuación menciono y explico varios de estos protocolos, estos son los más importantes y/o comerciales hoy día:

o    FTP

o    HTTP

o    IPX/SPX

o    NFS

o    POP3

o    SCP

o    TCP/IP

 

 

FTP File transfer Protocol, Protocolo de Transferencia de Archivos

El objetivo principal de este protocolo son varios puntos, promover el compartir archivos entre computadoras (programas y/o datos), alentar al uso remoto de las computadoras, y transferir datos de una forma segura y optima por computadora. FTP mas que para ser usado por un usuario directamente es para que los programas lo usen entre ellos para comunicarse.

Con este tipo de forma de hacer las cosas le ayudamos muchísmo al usuario a despreocuparse si el tiene contacto con macrocomputadoras, micro, mini o simples PC’s, gracias a un protocolo como este, no se necesita saber mucho y se logra lo que se quiere.

FTP ha ido evolucionando demasiado en todos estos años desde que se creo, este empezó en 1971 con un modelo de transferencia llamado RFC 141 en M.I.T.. Fue hasta después de muchas revisiones que llegó a RFC 265 cuando ya se le considero un protocolo de transferencia de archivos completa entre HOSTs (servidores de archivos) de ARPHANET. Finalmente un documento declarando un FTP oficial se publico cuando se llego a RFC 454.

Por Julio de 1973 muchos cambios había sufrido ya el FTP, pero siempre conservo la estructura principal desde el principio.

Al final de la edición de RFC 765 se incluyeron algunos de los que son ahora los comandos de este protocolo:

CDUP

Change to Parent Directory

SMNT

Structure Mount

STOU

Store Unique

RMD

Remove Directory

MKD

Make Directory

PWD

Print Directory

SYST

System

 

Alguna de la terminología usada en este protocolo son las siguientes definiciones:

ASCII Solo se usan todos los caracteres dentro de los 8 bits en su valor bajo

Access controls Este sirve para hablar a cerca de los privilegios (derechos en la red) de cada usuario tanto en archivos como en dispositivos.

Data connection Habla de cuando hay una comunicación Full Duplex entre dos computadoras.

DTP Proceso de la transferencia.

Error Recovery Este es un procedimiento que le permite al usuario en algunos casos recuperar información perdida en el proceso de transferencia.

 

Existen tres tipos de datos en la transferencia por FTP, tipo ASCII, EBCDIC e IMAGEN.

El tipo ASCII, es el mas común en el protocolo FTP, este se usa cuando se transfieren archivos de texto, la computadora que envía (sender), debe convertir cualquiera que sea su estructura de archivos interna, debe convertir sus datos al formato genérico de 8 bits, y el que recibe (receiver) lo debe convertir de nuevo a su formato propio.

El tipo EBCDIC es el mas eficiente cuando ambos el que recibe y el que envía lo usan como formato propio, este tipo se representa también en 8 bits pero de forma EBCDIC. Lo único en lo que cambian es en la forma de reconocer los códigos de los caracteres.

El formato de IMAGEN es cuando se empaca todo lo que se quiere enviar en cadenas seguidas de paquetes de 8 bits, esto es no importa el formato en que internamente se maneje la información, cuando se va a enviar se tiene que hacer una conversión de 8 bits en 8 bits y cuando el que recibe tiene todo el paquete, el mismo de be codificarlos de nuevo para que la transmisión sea completada.

En la estructura de datos en FTP se consideran tres tipos diferentes de archivos:

File - structure donde no hay estructuras internas y el archivo es considerado una secuencia continua de bytes

Record - structure donde los archivos contienen puros registros igualitos en estructura

Page - structure donde los archivos contienen paginas enteras indexadas separadas.

Al establecer una conexión por FTP se debe tomar en cuenta que el mecanismo de transferencia consiste en colocar bien la transferencia de datos en los puertos adecuados y al concluir la conexión estos puertos deben ser cerrados adecuadamente. El tamaño de transferencia es de 8 bits, en ambos. El que va a transferir, debe escuchar desde el puerto hasta que el comando enviado sea recibido y este será el que de la dirección de la transferencia. Una vez recibido el comando y establecido una transferencia del servidor a que solicita se inicializa la comunicación de la transferencia para verificar la conexión, esta es una cabecera con un formato específico, después de esto se comienza a enviar las tramas de 8 bits sin importar el tipo de datos que sea (antes mencionado), y al finalizar se envía otra trama cabecera ya establecida confirmando la transferencia completada.

Existen tres modos de transferencia en FTP

 

Algunos de los comandos mas usados en FTP son los siguientes:

Comandos de acceso

USER NAME (USER)

PASSWORD (PASS

ACCOUNT (ACCT)

CHANGE WORKING DIRECTORY (CWD)

CHANGE TO PARENT DIRECTORY (CDUP)

REINITIALIZE (REIN)

LOGOUT (QUIT)

Comandos de transferencia

DATA PORT (PORT)

PASSIVE (PASV)

FILE STRUCTURE (STRU)

TRANSFER MODE (MODE)

Comandos de servicio

RETRIEVE (RETR)

STORE (STOR)

STORE UNIQUE (STOU)

APPEND (with create) (APPE)

ALLOCATE (ALLO)

RENAME TO (RNTO)

ABORT (ABOR)

DELETE (DELE)

REMOVE DIRECTORY (RMD)

MAKE DIRECTORY (MKD)

PRINT WORKING DIRECTORY (PWD)

LIST (LIST)

HELP (HELP)

Algunos de los códigos usados en la transferencia son los siguientes, estos códigos no son mas que mensajes enviados por el protocolo:

Códigos normales

Códigos de mensajes con operaciones numéricas

 

Ir al Principio

 

HTTP Hyper Text Transfer Protocol, Protocolo para la transferencia  de hipertextos

 

El protocolo para la transferencia de hipertextos es para todos los sistemas de información distribuidos que tengan la necesidad de mostrar la información y pasarla por una comunicación normal haciendo uso de las ligas de este lenguaje. La primera versión de este lenguaje (HTTP 0.9) se uso desde 1990.

El Protocolo fue implementado inicialmente para WWW en 1991 como una iniciativa de software y se denominó HTTP 0.9. El protocolo completo fue definido en 1992 e implementado en marzo de 1993.

El protocolo como todos tiene una propia terminología, a continuación la menciono:

Conexión Es el circuito virtual establecido entre dos programas en una red de comunicación con el proceso de una simple comunicación.

Mensaje Esta es la unidad básica de un protocolo HTTP, estos consisten en una secuencia estructurada que es transmitida siempre entre los programas.

Cliente Es el programa que hace la llamada al servidor y es el que atiende en toda la transmisión la trama de los mensajes.

Servidor El que presta el servicio en la RED.

Proxy Un programa intermedio que actúa sobre los dos, el servidor y el cliente.

 

 

Ir al Principio

IPX/SPX Internetwork Packet Exchange, Sequence Packet Exchange

 

Este es un protocolo usado y registrado por la compañía mundial de redes Novell®

 

Ir al Principio

NFS Network file system, Sistema de archivos de RED

 

NFS es un sistema distribuido para archivos, este es para las redes heterogéneas, con este protocolo, el usuario solo ve un directorio cuando esta dentro de la red, claro que tiene ramas dentro pero no puede ver mas arriba de el nivel en el que se entra, tal ves los archivos dentro de esta estructura del directorio ni siquiera esta en la misma computadora.

 

Ir al Principio

POP3 Post office protocol version 3

 

Este es netamente un protocolo para la administración de correo en Internet.

En algunos nodos menores de Internet normalmente es poco práctico mantener un sistema de transporte de mensajes (MTS). Por ejemplo, es posible que una estación de trabajo no tenga recursos suficientes (espacio en disco, entre otros) para permitir que un servidor de SMTP [RFC821] y un sistema local asociado de entrega de correo estén residentes y continuamente en ejecución. De forma similar, puede ser caro (o incluso imposible) mantener una computadora personal interconectada a una red tipo IP durante grandes cantidades de tiempo (el nodo carece el recurso conocido como "connectivity").

A pesar de esto, a menudo es muy útil poder administrar correo sobre estos nodos, y frecuentemente soportan un user agent (UA) (agente de usuario) para ayudar en las tareas de manejo de correo. Para resolver el problema, un nodo que sí sea capaz de soportar un MTS ofrecerá a estos nodos menos dotados un servicio de maildrop. Se entiende por maildrop, el "lugar" en el sistema con el MTS donde el correo es almacenado para que los otros nodos puedan trabajar con él sin necesidad de mantener su propio MTS. El Protocolo de oficina de correos - Versión 3 (POP3) está destinado a permitir que una estación de trabajo acceda dinámicamente a un maildrop en un host servidor de forma útil y eficiente. Esto significa que el protocolo POP3 se usa para permitir a una estación de trabajo recobrar correo que el servidor tiene almacenado.

POP3 no está destinado a proveer de extensas operaciones de manipulación de correo sobre el servidor; normalmente, el correo es transmitido y entonces borrado. IMAP4 es un protocolo más avanzado y complejo y es tratado en [RFC1730] y revisado en [RFC 2060].

De aquí en adelante el termino (host) cliente se refiere a un host haciendo uso del servicio POP3 y host servidor al que ofrece este servicio. Inicialmente, el host servidor comienza el servicio POP3 leyendo el puerto 110 TCP. Cuando un host cliente desea de hacer uso del servicio, establece una conexión TCP con el host servidor. Cuando la conexión se establece, el servidor POP3 envía un saludo. Entonces, el cliente y el servidor de POP3 intercambian comandos y respuestas respectivamente hasta que la conexión se cierra o es abortada.

Los comandos en el POP3 consisten en una palabra clave (keyword), posiblemente seguida de uno o más argumentos. Todos los comandos terminan con un par CRLF. Las palabras clave y los argumentos consisten en caracteres ASCII imprimibles. Las palabras clave y los argumentos están cada uno separados por un único carácter de espacio. Las palabras clave son de una longitud de tres o cuatro caracteres, mientras que cada argumento puede ser de hasta 40 caracteres de longitud.

Las respuestas en el POP3 consisten de un indicador de estado y una palabra clave posiblemente seguida de información adicional. Todas las respuestas acaban en un par CLRF. Las respuestas pueden ser de hasta 512 caracteres de longitud, incluyendo el CRLF de terminación. También existen dos indicadores de estado: positivo o afirmativo ("+OK") y negativo ("-ERR"). Los servidores deben enviar el "+OK" y el "-ERR" en mayúsculas.

Las respuestas a ciertos comandos son multilínea (una respuesta compuesta de varias líneas). En estos casos, que se indican claramente más adelante, después de enviar la primera línea de la respuesta y un CRLF, se envía cualquier línea adicional, cada una terminada en un par CRLF. Cuando todas las líneas de la respuesta han sido enviadas, se envía una línea final, que consiste en un octeto de terminación (en decimal 046,".") Y un par CRLF. Si alguna línea de la respuesta multilínea comienza con el octeto de terminación, se ponen bytes de relleno precedidos por el byte de terminación en esa línea de la respuesta. De aquí en adelante una respuesta multilínea termina con los cinco bytes "CRLF.CRLF". Al examinar una respuesta multilínea, el cliente comprueba si la línea comienza con el byte de terminación. Si es así y si siguen otros bytes a excepción del CRLF, el primer byte de la línea (el byte de terminación) es ignorado. De este modo si el CRLF sigue inmediatamente al carácter de terminación, entonces la respuesta desde el servidor POP termina y la línea conteniendo "CRLF " no es considerada como parte de la respuesta multilínea.

Una sesión POP3 progresa a través de una serie de estados a lo largo de su vida. Una vez la conexión TCP ha sido abierta y el servidor de POP3 ha enviado el "saludo" (línea especial que se utiliza cuando se establece la conexión), la sesión entra en el estado de autorización (AUTHORIZATION). En este estado, el cliente debe identificarse al servidor de POP3. Una vez el cliente ha hecho esto satisfactoriamente, el servidor adquiere los recursos asociados al maildrop del cliente, y la sesión entra en el estado de transacción (TRANSACTION). En este estado, el cliente realiza una serie de solicitudes al servidor de POP3. Cuando el cliente ha emitido el comando de finalización (QUIT), la sesión entra en el estado de actualización (UPDATE). En este estado, el servidor de POP3 libera cualesquiera recursos adquiridos durante el estado de transición, "dice adiós" y la conexión TCP se cierra.

Un servidor debe responder a comandos no reconocidos, no implementados, o sintácticamente incorrectos con un indicador negativo de estado (respuesta negativa). También debe responder con un indicador negativo de estado cuando la sesión se encuentra en un estado incorrecto. No hay un método general para que el cliente distinga entre un servidor que no implementa un comando opcional y un servidor que no esta dispuesto o es incapaz de procesar el comando.

Un servidor de POP3 puede disponer de un temporizador o cronómetro de inactividad (autologout inactivity timer). Tal cronómetro debe ser de por lo menos 10 minutos de duración. La recepción de cualquier comando desde el cliente durante este intervalo reinicia la cuenta de este cronómetro. Cuando el cronómetro llega a los diez minutos, la sesión no entra en el estado de actualización. Entonces, el servidor debería cerrar la conexión TCP sin eliminar ningún mensaje y sin enviar ninguna respuesta al cliente.

 

USER nombre

Argumentos: una cadena identificando un mailbox, el cual solo tiene significado para el servidor

Restricciones: solo puede darse en el estado de autorización después del saludo o de los comandos USER o PASS sin éxito.

Definición: Para autentificar usando la combinación de los comandos USER y PASS, el cliente debe primero emitir el comando USER. Si el servidor responde afirmativamente (+OK), entonces el cliente puede responder con el comando PASS para completar la autentificación, o el comando QUIT para finalizar con la conexión. Si el servidor responde negativamente (-ERR) al comando USER, el cliente puede emitir un nuevo comando de autenticación o bien el comando QUIT.

El servidor puede devolver una respuesta afirmativa incluso a pesar de que no exista ningún mailbox. El servidor puede devolver una respuesta negativa si el mailbox existe, pero no permitir la autenticación.

 

PASS cadena

Argumentos: palabra de acceso al mailbox

Restricciones: solo puede darse en el estado de autorización inmediatamente después de un comando USER satisfactorio.

Definición: Cuando el cliente el comando PASS, el servidor utiliza el par de argumentos de los comandos USER y PASS para determinar si al cliente se le debe dar acceso al maildrop apropiado.

Ya que el comando PASS tiene exactamente un argumento, un servidor de POP3 puede tratar los espacios como parte del password en lugar de cómo separadores de argumentos.

 

APOP nombre digest

Argumentos: una cadena identificando un mailbox y una cadena digest MD5

Restricciones: solo puede darse en el estado de autorización después del saludo o de los comandos USER o PASS sin éxito.

Definición: Normalmente, cada sesión POP3 comienza con intercambio USER/PASS. Esto tiene como resultado una clave de acceso específica enviada a través de la red. Para un uso intermitente del POP3, no conlleva un riesgo considerable. Sin embargo, muchas implementaciones de cliente POP3 conectan al servidor regularmente para comprobar si hay correo nuevo. Además, el intervalo de iniciación de la sesión puede ser del orden de 5 minutos. Por lo tanto, el riesgo de que la clave de acceso sea capturada es alto.

Se requiere un método alternativo de autenticación que no implique el envío de claves de acceso a través de la red. Esta funcionalidad la proporciona el comando APOP.

Un servidor que implemente el comando APOP incluirá una marca de tiempo (timestamp) en sus "saludos". La sintaxis de la marca de tiempo corresponde al "msg-id" en la RFC 882 (actualizada por RFC 973 y después por RFC 1982), y debe ser diferente cada vez que el servidor envía un saludo. Por ejemplo, en una implementación UNIX en la cual un proceso UNIX separado es el encargado de cada instancia de servidor, la sintaxis de la marca de tiempo podría ser: process-ID.clock@hostname, donde process ID es el valor decimal del PID del proceso, clock es el valor decimal del reloj del sistema, y hostname es el nombre de dominio del host donde el servidor está funcionando.

El cliente recibe esta marca de tiempo y emite un comando APOP. El parámetro nombre tiene el mismo significado que el parámetro nombre del comando USER. EL parámetro digest se calcula aplicando el algoritmo MD5 (RFC 1321) a una cadena consistente en una marca de tiempo (incluyendo <) seguido de un secreto compartido. Este secreto compartido es una cadena conocida solo por el cliente y el servidor. Se debe tener un gran cuidado para prevenir una revelación no autorizada del secreto, ya que su conocimiento puede permitir a cualquier entidad hacerse pasar por el usuario. El parámetro digest es un valor de 16 bytes que se envía en formato hexadecimal, utilizando caracteres ASCII en minúsculas.

Cuando el servidor recibe el comando APOP, verifica el digest proporcionado. Si el digest es correcto, el servidor envía una respuesta afirmativa y la sesión entra en el estado de transacción. Si no, envía una respuesta negativa y la sesión permanece en el estado de autorización.

Notar que conforme incrementa la longitud de los secretos compartidos, aumenta la dificultad de derivarlos. Como tales, los secretos compartidos deben ser cadenas largas (considerablemente más largas que el ejemplo de 8 caracteres mostrado abajo).

 

 

AUTH mecanismo

Argumentos: una cadena que identifique un mecanismo de autenticación IMAP4 (definición en IMAP4-AUTH).

Restricciones: sólo puede darse en el estado de autorización.

Definición: El comando AUTH se refiere a un mecanismo de autenticación al servidor por parte del cliente. Si el servidor soporta este mecanismo, lleva a cabo el protocolo para la identificación del usuario. Opcionalmente, también procede con un mecanismo de protección para las subsiguientes interacciones del protocolo. Si este mecanismo de autentificación no es soportado, el servidor debería rechazar el comando AUTH enviando una respuesta negativa.

El protocolo de autentificación consiste en una serie de cuestiones por parte del servidor y de unas respuestas del cliente, específicas de este mecanismo de autentificación. Una pregunta del servidor, es una línea que consiste en un carácter "+" seguido de un espacio y una cadena codificada en base 64. La respuesta del cliente es una línea que contiene otra cadena codificada en base 64. Si el cliente desea cancelar la autentificación, debe emitir una línea con un único "*". Si el servidor la recibe, rechazará el comando AUTH.

Un mecanismo de protección proporciona integridad y privacidad a la sesión del protocolo. Si se utiliza un mecanismo de protección, este será aplicado a todos los datos que se envíen en la conexión. El mecanismo de protección tiene efecto inmediatamente después de que un CLRF concluya con el proceso de autenticación del cliente y de la respuesta positiva del servidor. Una vez el mecanismo de protección se hace efectivo, el flujo de bytes de comandos y respuestas se procesa en buffers de ciphertext (texto cifrado). Cada buffer es transferido en la conexión como un flujo de bytes seguidos de un campo de 4 bytes que representan la longitud de los siguientes datos. La longitud máxima de los bufferes de ciphertext se define en el mecanismo de protección.

No es necesario que el servidor soporte algún mecanismo de autentificación, y tampoco es necesario que los mecanismos de autentificación soporten mecanismos de protección. Si un comando AUTH falla, la sesión permanece en el estado de autorización y el cliente puede probar con otro AUTH o bien con otro mecanismo como la combinación USER/PASS, o el comando APOP. En otras palabras, el cliente puede pedir tipos de autentificación en orden decreciente de preferencia, con USER/PASS o APOP como últimos recursos.

SI el cliente completa la autentificación satisfactoriamente, el servidor de POP3 emite una respuesta afirmativa y se entra en el estado de transacción.

TOP mensaje

Argumentos: un número de mensaje, que si aparece no se puede referir a ningún mensaje marcado como borrado; y un número no negativo de líneas.

Restricciones: solo puede darse en el estado de transacción.

Definición: Si el servidor emite una respuesta positiva, entonces ésta es multilínea. Después del +OK inicial, el servidor envía las cabeceras del mensaje, la línea en blanco separando las cabeceras del cuerpo, y luego el número de líneas del cuerpo del mensaje.

Si el número de líneas requeridas por el cliente es mayor del número de líneas del cuerpo, el servidor envía el mensaje entero.

UIDL [mensaje]

Argumentos: un número de mensaje opcional. Si está presente no debe referirse a un mensaje marcado como borrado.

Restricciones: solo puede darse en el estado de transacción.

Definición: Si se da un argumento, el servidor emite una respuesta afirmativa con una línea que contiene información del mensaje. Esta línea se llama unique-id listing.

Si no se da ningún argumento y el servidor emite una respuesta afirmativa, la respuesta dada es multilínea. Después del +OK inicial, por cada mensaje en el maildrop, el servidor responde con una línea con información de ese mensaje.

Para simplificar el análisis, todos los servidores deben tener un mismo formato de unique-id listing, que consiste en el número de mensaje, un espacio y el unique-id del mensaje. Después no hay mas información.

El unique-id listing de un mensaje es una cadena arbitraria determinada por el servidor, que consiste en 70 caracteres entre 0x21 y 0x7E (hexadecimal), los cuales identifican únicamente un mensaje en el maildrop y los cuales permanecen a lo largo de las distintas sesiones. Esta persistencia es requerida incluso si la sesión termina sin entrar en el estado de actualización. El servidor nunca debería rehusar el unique-id en un maildrop dado a lo largo de todo el tiempo de existencia de la entidad que usa el unique-id.

Mientras que generalmente es preferible para implementaciones de servidor almacenar los unique-id en el maildrop, la especificación tiene la intención de permitir que los unique-id sean calculados como trozos del mensaje. Los clientes deberían de ser capaces de manejar una situación en la que se den dos copias idénticas de un mensaje en un maildrop con el mismo unique-id

 

Ir al Principio

SCP Simple Communication Protocol

 

Este es un simple protocolo que deja al servidor y al cliente tener múltiples conversaciones sobre una TCP normal, esto como es evidente declara que el protocolo SCP necesita montarse sobre el SCP, Este protocolo esta diseñado para ser simple de implementar.

El servicio principal de este protocolo es el control del dialogo entre el servidor y el cliente, administrando sus conversaciones y agilizadas en un alto porcentaje, este protocolo le permite a cualquiera de los dos (servidor cliente) establecer una sesión virtual sobre la normal.

La descripción de un formato de comunicación en las cabeceras enviadas por la red es la siguiente:

 

 

Ir al Principio

 

TCP/IP Transfer Communication Protocol / Internet Protocol

 

El TCP/IP es un conjunto de protocolos de comunicación, es decir de convenciones particulares, creadas para permitir la colaboración y la partición de recursos entre más ordenadores conectados entre sí en la que está definida como red o network. Internet es en absoluto la más grande entre todas las redes existentes, debido a que logra conectar entre sí ordenadores personales y redes de menor amplitud en todo el mundo. Sobre Internet, de hecho, puede usted encontrar en conexión los ordenadores de instituciones del gobierno, militares, universidades y empresas privadas. Lo que permite a máquinas tan distintas por hardware y por prestaciones, comunicar entre sí de manera casi transparente, es el, TCP/IP, el cual constituye un tipo de 'lenguaje universal' comprendido y utilizado por todas las máquinas que cooperan en red.

Vamos a empezar con algunas definiciones de base. El nombre más apropiado para indicar este conjunto de protocolos, es Internet protocol suite, es decir colección de protocolos de Internet. El TCP y el IP son dos protocolos que pertenecen a esta colección.

Puesto que éstos son también los protocolos más conocidos, ha entrado en el uso común llamar TCP/IP a toda la familia, aunque en algunas ocasiones una generalización parecida pueda resultar un error. Como quiera que se llame, el TCP/IP representa una familia de protocolos, proveen a la gestión de las funciones de bajo nivel, que son necesarias para la mayoría de las aplicaciones. El TCP y el IP pertenecen a los protocolos de bajo nivel. Sobre esta base, se desarrollan otros protocolos que gestionan funciones particulares, como la transferencia de ficheros, el envío del correo electrónico, la conexión remota, el control de los usuarios que se han conectado a la red en un momento específico, condividir impresoras y de programas aplicativos, y algo más.

Todo esto está generalmente simplificado en un modelo cliente/servidor, en el cual el servidor se identifica con el ordenador que proporciona un servicio específico, a través del network, (por ejemplo el (sitio FTP de VOL FTP es un servidor de ficheros y de informaciones sobre cómo utilizarlos de la manera mejor) y en el cual el término cliente se identifica con el ordenador que explota este servicio, aunque con la palabra cliente incluya también aquellos programas que uno utiliza para tener acceso a estos mismos servicios (por ejemplo el Tiber y el Netscape son dos clientes típicos para tener acceso a las páginas del WWW).

 

El TCP/IP es un conjunto de protocolos 'a capas' o, si se prefiere, 'a niveles'.

Para entender qué significa todo lo anterior pongamos un ejemplo sencillo. Imaginemos que se tiene que enviar correo a través de Internet. Lo primero que se necesita es definir un protocolo específico para el correo, o sea, un conjunto de reglas unívocamente reconocidas por todos los ordenadores conectados en red.

Dicho protocolo tendrá la tarea de coger la carta que hay que enviar, añadirle el emisor y el destinatario y enviarla a quien corresponda. Esto último es la tarea del protocolo específico de gestión del correo, que podría ser comparado al de una persona a la que un amigo muy ocupado le deja una carta y ella se encarga de ponerla en el sobre, escribir los datos de expedición y echarla al correo.

Evidentemente, si sólo existiese esta figura la carta se quedaría eternamente en el buzón sin que nadie se preocupase de hacerla llegar a su destino. Sin embargo, nuestro amigo muy ocupado tendría suerte ya que existe una camioneta del servicio de correos que dos veces al día vacía el buzón y transporta las cartas que allí encuentra a un lugar donde serán clasificadas y diferenciadas; allí su preciosísima carta será cuidada y mimada hasta que llegue al buzón del destinatario.

Para continuar con el paralelismo del ejemplo, diremos que el TCP/IP representa el sistema de transporte de Internet. En particular, el TCP se preocupa de 'empaquetar' bien todos los datos que le son suministrados por los protocolos de nivel superior; es posible que los subdivida en más partes si resultasen demasiado largos para un solo envío en red; asimismo recuerda lo que ha sido enviado, se acuerda de volver a enviarlo en el caso en que se hubiera perdido y controla que todo se realice de forma transparente para el usuario.

Ya que este tipo de operaciones es de uso general y es necesario tanto para enviar correo como para enviar ficheros u otras cosas, se ha pensado en hacer un protocolo propio, que pueda ser utilizado por muchos otros. Es precisamente por este motivo por lo que hemos definido protocolo de bajo nivel.

El TCP, sin embargo, no es el protocolo de nivel más bajo desde el momento en que éste utiliza el IP para realizar determinadas acciones. De hecho, a pesar de que el TCP sea muy utilizado, existen protocolos que prefieren no usarlo y que para funcionar sólo necesitan las funciones que puede ofrecer incluso el más humilde IP.

Este tipo de organización 'a capas' permite una gran eficiencia y un menor gasto de recursos.

Para terminar con un ejemplo, el envío de un mensaje de correo electrónico a través de Internet utiliza un sistema compuesto por cuatro capas:

Un protocolo de alto nivel específico para el correo 2.El protocolo TCP que es utilizado también por otros protocolos de alto nivel 3.El protocolo IP que se ocupa de la específica tarea de tomar los paquetes y enviarles a su destino 4.El protocolo del hardware específico, que se utiliza para la transmisión y la recepción de los datos

A este punto se nos aparece claro el motivo por el que el conjunto de los protocolos de Internet es llamado genéricamente TCP/IP. De hecho, estos son los protocolos más utilizados y de los que sólo pueden prescindir muy pocos protocolos de un nivel más alto.

Antes de terminar esta exposición general sobre el funcionamiento del TCP/IP es necesario introducir el concepto de datagrama (datagram), que representa cada uno de los paquetes de informaciones que es enviado a través de la red. Como ya hemos dicho antes, un conjunto de informaciones demasiado largo que es subdividido en paquetes más pequeños, precisamente llamados datagrama, que viajan individualmente en la red. Esto significa que si un fichero que se debe enviar es subdividido en 10 datagramas secuenciales, no está dicho que el cuarto llegue antes que el séptimo, desde el momento en que éste puede perderse o tomar un camino equivocado. Será una tarea de los diversos protocolos el hacer que dicho paquete sea enviado nuevamente y colocado en el correcto orden secuencial a su llegada a destinación.

Y ahora, para evitar los ataques de los "puristas" diremos que a pesar de que los términos datagrama y paquete son muy a menudo utilizados como sinónimos, en realidad existe una diferencia. Mientras el datagrama es específico del TCP/IP y representa la mínima unidad lógica utilizable por los diversos protocolos, el paquete es una entidad física bien presente para quien administra una red de tipo Ethernet. En el caso, por lo demás muy frecuente, que en un paquete viaje un solo datagrama, la diferencia es sólo teórica pero existen también específicas configuraciones hardware de red que utilizan paquetes de dimensión menor respecto a la del datagrama individual. Entonces sucede que un datagrama se descompone en más paquetes durante el envío a la red específica y que sea recompuesto a su llegada, de forma absolutamente transparente respecto al mismo datagrama que... 'no se da cuenta' de haber sido descompuesto y luego recompuesto. Es evidente cómo en dicha situación los términos paquete y datagrama no coinciden. Es una buena medida, por tanto, acostumbrarse a utilizar el término datagrama cuando se habla del TCP/IP.