Protocolo TCP/IP (Transmission Control Protocol Internet Protocol)

¿QUÉ ES TCP/IP?
Es un protocolo de comunicaciones que se basa en software utilizado en redes. Aunque el nombre TCP/IP
implica que el ámbito total del producto es la combinación de dos protocolos − protocolo de control de
transmisión − (transmission control protocol) y protocolo Internet (Internet protocol) , el término TCP/IP no
es una entidad única que combina dos protocolos, sino un conjunto de programas de software más grande que
proporciona servicios de red, como registro de entrada remoto, transferencia de archivos remota y correo
electrónico. TCP/IP ofrece un método de transferir información de una máquina a otra. Un protocolo de
comunicaciones debe manejar los errores en la transmisión, administrar el encaminamiento y entrega de los
datos, así como controlar la transmisión real mediante el uso de señales de estado predeterminadas. TCP/IP se
ocupa de todo lo anterior.Muchas grandes redes han sido implementadas con estos protocolos, incluyendo
DARPA Internet "Defense Advanced Research Projects Agency Internet", en español, Red de la Agencia de
Investigación de Proyectos Avanzados de Defensa. De igual forma, una gran variedad de universidades,
agencias gubernamentales y empresas de ordenadores, están conectadas mediante los protocolos TCP/IP.
Cualquier máquina de la red puede comunicarse con otra distinta y esta conectividad permite enlazar redes
físicamente independientes en una red virtual llamada Internet. Las máquinas en Internet son denominadas
"hosts" o nodos.
TCP/IP proporciona la base para muchos servicios útiles, incluyendo correo electrónico, transferencia de
ficheros y login remoto.
El correo electrónico está diseñado para transmitir ficheros de texto pequeños. Las utilidades de transferencia
sirven para transferir ficheros muy grandes que contengan programas o datos. También pueden proporcionar
chequeos de seguridad controlando las transferencias.
El login remoto permite a los usuarios de un ordenador acceder a una máquina remota y llevar a cabo una
sesión interactiva.
¿COMO NACIO?
Internet fue propuesta originalmente por la precursora de DARPA, la agencia de proyectos de investigación
avanzada de la defensa (advanced research projets agency, ARPA), con una forma de probar la viabilidad de
las redes de conmutación de paquetes. (Cuando el enfoque de ARPA se volvió de naturaleza militar, se
cambio el nombre. Durante su estadía en el proyecto, ARPA previo una red de líneas rentadas conectadas por
nodos de conmutación. La red se denominó ARPAnet y los nodos se conocieron como procesadores de
Mensajes de Internet (IMPs).
ARPAnet inicialmente está formada pro cuatro IMPs. En 1971 ARPAnet entró en servicio normal. Las
máquinas utilizaron ARPAnet mediante la conexión a un IMP y utilizando el protocolo "1822" (Número del
documento técnico que describía el sistema).
Una necesidad comunmente reconocida era la capacidad de transferir archivos de una máquina a otra, así
como la capacidad de aceptar registro de entrada remoto no podían ser realizados hasta que se implementaron
en un protocolo conocido como Programa de Control de Red (Network Control Program, NCP) que cumplía
con estos requisitos. Más adelante, a través de FTP (Protocolo de Transferencia de Archivo, File Transfer
Protocol) se añadió el correo electrónico y junto con el registro y la transferencia de archivos remotos de
NCP, se conformaron los servicios de ARPAnet.
Al llegar 1973 resultaba claro que NCP era incapaz de manejar el volumen de tráfico y la nueva funcionalidad
propuesta. Se inició un proyecto con el objetivo de desarrollar un nuevo protocolo. El nacimiento de TCP/IP y
1
las arquitecturas de las compuertas fueron propuesto por primera vez en 1974. El artículo publicado por Cerf y
Kahn describía un sistema que incluía un protocolo de aplicación estandarizada, que también utilizaba
confirmaciones de extremo a extremo.
También, proponían conectividad universal a través de la red. Estas dos ideas eran radicales en un mundo de
hardware y software propietarios, porque permitirían que cualquier tipo de plataforma participara en la red. El
protocolo fue creado y se conoció como TCP/IP.
1−NIVELES DE TCP/IP:
El modelo de protocolo TCP/IP esta estructurado en un serie de niveles o capas al igual que el OSI,
coincidiendo con este en funciones salvo en la capa de aplicación.
1−Capa física (cobre, fibra optica...).
2−Capa de enlace (Ethernet,..).
3−Capa de red (IP, ICMP).
4−Capa de transporte (TCP,UDP).
A continuación viene la capa de aplicación que en TCP/IP es unica y su correspondencia en el modelo OSI
englobaria tres:capa de sesion, de presentación y de aplkicacion.
5−Capa de aplicación ( SMTP, http, TELNET, FTP,...).
En esta es donde centraremos nuestra de aquí en adelante.
CAPA DE APLICACIÓN EN EL CONJUNTO DE PROTOCOLOS TCP/IP:
Los programas de aplicación que gestionan y hacen funcionar internet siguen el modelo
CLIENTE−SERVIDOR siendo sus elementos:
−Un programa cliente(en la maquina local).
−Un programa servidor(en una maquina remota).
Cliente/servidor describe la relación entre dos programas de ordenador en la cual uno de ellos, el cliente, hace
una solicitud de servicio de otro programa, el servidor, quien cumple la solicitud. Aunque la idea
cliente/servidor puede usarse en programas dentro de un mismo ordenador, es una idea más importante en una
red. En ella, el modelo cliente/servidor proporciona una forma conveniente de interconectar programas que se
distribuyen eficientemente por varias ubicaciones. Las transacciones de ordenador que usan el modelo
cliente/servidor son muy variadas. Por ejemplo, para revisar nuestra cuenta de banco desde nuestro ordenador,
un programa cliente en nuestra máquina envía nuestra solicitud a un programa servidor en el banco. Ese
programa puede, a su vez, reexpedir la solicitud a su propio programa cliente que envía una solicitud a un
servidor de base de datos en otro ordenador del banco para obtener nuestro saldo. El saldo es enviado al
cliente del banco, que a su vez se lo sirve de vuelta al cliente en nuestro ordenador personal, que despliega la
información para que la veamos
En el modelo usual cliente/servidor un servidor se activa y espera las solicitudes de los clientes.
Habitualmente, programas cliente múltiples comparten los servicios de un programa servidor común. Tanto
los programas cliente como los servidores son con frecuencia parte de un programa o aplicación mayores. Con
relación a Internet, nuestro navegador de la Red es un programa cliente que solicita servicios (el envío de
2
páginas web o archivos) de un servidor web (que técnicamente se llama un servidor de Protocolo de
Transporte de Hipertexto, Hypertext Transport Protocol o HTTP) en otro ordenador en algún lugar de
Internet. De modo similar, nuestro ordenador con TCP/IP instalado nos permite hacer solicitudes de cliente
para recibir archivos de servidores de Protocolo de Transferencia de Archivos (File Transfer Protocol, FTP)
en otros ordenadores de Internet. Otros modelos de relación entre programas incluían el maestro/esclavo, en el
que un programa estaba a cargo de todos los demás programas, e igual−a−igual, donde cualquiera de dos
programas puede iniciar una transacción.
2−CONEXIÓN TCP/IP(BOOTP y DHCP):
Toda computadora debe tener para estar conectada a una internet(modelo Cliente/Servidor) TCP/IP la
siguiente información:
−Su dirección IP.
−Su mascara de red.
−La dirección IP del encaminador.
−La dirección IP de un servidor de nombres.
Esta información se almacena en un archivo de configuración y se accede nada mas arrancar.
¿Y si esa computadora se arranca por primera vez o no tiene disco? El SO y el software de red podrían
almacenarse en la ROM pero los tres elementos antes mencionados son totalmente desconocidos a la hora del
montaje del terminal. Ahí entra el protocolo de arranque o BOOTP.
El protocolo BOOTP se utiliza para efectuar arranques remotos en redes IP. Permite que una pila de IP
mínima sin información de configuración, típicamente almacenada en la ROM, obtenga información
suficiente para comenzar el proceso de descargar el código de arranque necesario. . BOOTP no define como
se realiza esta descarga, pero habitualmente se emplea TFTP
El proceso BOOTP implica los siguientes pasos:
• El cliente determina su propia dirección hardware; esta suele estar en una ROM del hardware.
• El cliente BOOTP envía su dirección hardware en un datagrama UDP(protocolo de datagrama de usuario)
al servidor. El contenido completo de este datagrama se muestra en Figura − Formato de mensaje de
BOOTP. Si el cliente conoce su dirección IP y/o la dirección del servidor, debería usarlas, pero en general
los clientes BOOTP carecen de configuración IP en absoluto. Si el cliente desconoce su dirección IP,
emplea la 0.0.0.0. Si desconoce la dirección IP del servidor, utiliza la dirección de broadcast
limitado(255.255.255.255). El número del puerto UDP es el 67.
• El servidor recibe el datagrama y busca la dirección hardware del cliente en su fichero de configuración,
que contiene la dirección IP del cliente. El servidor rellena los campos restantes del datagrama UDPy se lo
devuelve al cliente usando el puerto 68. Hay tres métodos posibles para hacer esto:
Si el cliente conoce su propia dirección IP(incluida en la solicitud BOOTP), entonces el servidor devuelve
directamente el datagrama a esa dirección. Es probable que la caché de ARP (tabla donde se guardan las
direcciones físicas IP entre terminales) en la pila de protocolos del servidor desconozca la dirección hardware
correspondiente a esa dirección IP. Se hará uso de ARP para determinarla del modo habitual (el protocolo
ARP protocolo de resolución de direcciones es responsable de convertir las direcciones IP a direcciones de red
físicas).
3
Si el cliente desconoce su propia dirección IP(0.0.0.0 la solicitud BOOTP), entonces el servidor se ocupa de
averiguarla con su propia caché de ARP. El servidor no puede usar ARP para resolver la dirección hardware
del cliente porque el cliente no sabe su dirección IP y por lo tanto no puede responder a una petición ARP. Es
el problema de la pescadilla que se muerde la cola. Hay dos soluciones posibles:
Si el servidor tiene un mecanismo para actualizar directamente su propia caché ARP sin usar ARP, lo utiliza y
envía directamente el datagrama.
Si el servidor no puede actualizar su propia caché, debe enviar una respuesta en forma de broadcast.
Cuando reciba la respuesta, el cliente BOOTP grabará su dirección IP(permitiéndole responder a peticiones
ARP) y comenzará el proceso de arranque. El proceso de arranque completo reemplaza la pila mínima de IP
usada por BOOTP y TFTP por una pila IP normal transferida como parte del fichero de arranque, que
contiene la configuración correcta para el cliente.
Pero ..¿Y si la computadora cambia de un red física a otra o quiere cambiar de IP de manera temporal?.
BOOTP no es un protocolo de configuración dinámico dado que el enlace entre IP y dirección física es
estático y fijado en una tabla hasta que el administrador lo cambie. Para ello utilizamos el protocolo de
configuración dinámica de estación DHCP.
DHCP utiliza tres mecanismos para la asignación de direcciones:
a− Asignación automática: La cual DHCP asigna una dirección IP permanente a un cliente.
b− Asignación dinámica: DHCP asigna una dirección IP a un cliente por periodo de tiempo específico, o un
periodo de tiempo especificado por el cliente. Este mecanismo es el único de los tres que permite
automáticamente re usar direcciones que no están siendo más necesitadas por un cliente al cual fue asignada,
por lo tanto este mecanismo es útil para asignar una dirección a un cliente que estará temporalmente
conectado a la red o para compartir un grupo limitado de direcciones IP de un conjunto de clientes que no
necesitan direcciones IP permanentes.
c− Asignación manual: La dirección IP de un cliente es asignado por el administrador de la red y DHCP solo
es utilizado para transmitir la dirección asignada al cliente. Este mecanismo es usado para corregir errores en
redes que por alguna razón no usan DHCP.
El formato de los mensajes DHCP está basado en el formato de mensajes BOOTP. Desde el punto de vista del
cliente, DHCP es una extensión del mecanismo BOOTP. Este comportamiento permite a clientes BOOTP
existentes ínteroperar con servidores DHCP sin requerir cambios en la inicialización del software del cliente.
3−SISTEMA DE NOMBRES DE DOMINIO(DNS):
Se trata de un protocolo que se puede utilizar en plataformas diferentes y que hace mas amigable internet
asignando nombres a las direcciones IP.En principio DNS funciona en la manera siguiente: Para traducir un
nombre de dirección un programa llama a un procedimiento de resolución. Esto manda un paquete de UDP al
servidor local de DNS, que busca la dirección IP usando el nombre. La vuelve al procedimiento de resolución,
que la vuelva al programa.
En internet se pueden encontrar tres tipos de dominios:
• Genericos: definen estaciones de acuerdo con su actividad o funcionamiento, estos son:
P.e: www.google.com
4
Etiqueta:
Edu
Gov
Int
Mil
Net
Org
Arts
Firm
Info
Nom
Rec
Store
Web
Com
Descripción:
Instituciones educativas
Instituciones gubernamentales
Organizaciones internacionales
Grupos militares
Centros de soporte de red
Organizaciones sin ánimo de lucro
Organizaciones culturales
Negocios o empresas
Proveedores de servicios de información
Nomenclaturas personales
organizaciones recreativas y de entretenimiento
Negocios que ofrecen bienes para comprar
Organizaciones relacionadas con la web
Organizaciones comerciales
• De paises: utiliza abreviaturas de los nombres de los paises de 2 caracteres, las etiquetas de segundo
nivel(separadas por un punto) pueden ser organizaciones o designaciones nacionales.
P.e: www.postal.ca.us
• Inversos: Se utilizan para proyectar una dirección en un nombre, o para pedir la traducción.
P.e: www.121.56.78.789.in−addr.arpa
Cuando especificamos un nombre de dominio en Telnet, finger. Gopher, FTP, o en una sesión Web, la propia
sesión no comienza hasta que el nombre del dominio es traducido a una dirección IP. Esta traducción es la
labor de los Servidores de nombres de Dominio (DNS) o como es más normal, de una serie de servidores DNS
en la cual un servidor pregunta a otro hasta que la IP correcta es alcanzada.
¿Cómo funcionan los servidores DNS?
El servicio de Servidor DNS es un servicio de resolución de nombres que convierte el nombre FQDN a su
correspondiente dirección IP.
DNS utiliza un modelo cliente/servidor, en el cual los servidores DNS (servidores de nombres) contienen
información acerca de la base de datos DNS y la ponen a disposición de los clientes.
Los servidores de nombres DNS resuelven los nombres interpretando la información de la red, para encontrar
una dirección IP específica. Por ejemplo, el proceso de resolución de icesi.edu.co pude esbozarse en los
siguientes pasos:
• El cliente pasa una pregunta a su servidor de nombres local.
• El servidor local de nombres, envía una solicitud iterativa a uno de los servidores raíz de DNS, pidiéndole
que resuelva el FQDN. El servidor raíz devuelve una referencia de los servidores de nombres encargados
del dominio DNS co.
• El servidor local de nombres, envía una solicitud iterativa a uno de los servidores especificados en el paso
anterior, el cual devuelve una referencia de los servidores de nombres encargados del dominio edu.
5
• El servidor local de nombres, envía una solicitud iterativa a uno de los servidores especificados en el punto
anterior.
El servidor de nombres del dominio edu, pasa la parte icesi del nombre DNS a su servidor local WINS para
que la resuelva, y una vez hecho esto, la dirección empieza a devolverse sobre los servidores anteriores hasta
llegar al cliente.
4−TELNET:
El protocolo TELNET se trata de un programa Cliente/Servidor de uso general que proporciona una interfaz
estandarizada, a través de la cual un programa de un host(el cliente de TELNET) puede acceder a los recursos
y aplicaciones de otro host (el servidor de TELNET) como si el cliente fuera una terminal local conectada al
servidor.
Asi Telnet se basa en tres servicios básicos:
1− El primero, define una terminal virtual de red (network virtual terminal) que proporciona una
interfaz estándar para los sistemas remotos. Los programas clientes no tienen que comprender los
detalles de todos los sistemas remotos, se construyen para utilizarse con la interfaz estándar.
2− En el segundo, Telnet incluye un mecanismo que permite al cliente y al servidor negociar opciones,
asimismo proporciona un conjunto de opciones estándar (por ejemplo, una de las opciones controla si
los datos que se transfieren a través de la conexión se valen del conjunto de caracteres ASCII estándar
de siete bits o de un conjunto de caracteres de ocho bits).
3− Por ultimo, Telnet trata con ambos extremos de la conexión de manera simétrica. En particular, Telnet no
fuerza la entrada de cliente para que ésta provenga de un teclado, ni al cliente para que muestre su salida en
una pantalla. De esta manera, Telnet permite que cualquier programa se convierta en cliente, además,
cualquier extremo puede negociar las opciones.
Por supuesto, TELNET se puede usar tanto en LANs como en WANs.
Asi podemos tener dos tipos de conexiones:
• Conexión local(conexión a un sistema de tiempo compartido local): Si nos ponemos en una estacion de
trabajo que ejecuta un emulador de terminales , los caracteres que pulsemos seran mandados al controlador
de terminal y de este al SO , el cual, ejecutara las ordenes recibidas respecto a los programas o aplicaciones
deseados.
La unica pega sera la utilización de caracteres especiales para acciones del SO que deben conocer igualmente
el emulador de terminales y el controlador de terminal en las redes remotas.
• Conexión remota: Aquí se utilizan cliente y servidor de TELNET. Los caracteres que pulsamos son
enviados por el SO local (no los interpreta) y de este al cliente TELNET que los transforma en una serie de
caracteres denominados caracteres de terminal virtual de red(NVT) y los entrega a la pila TCP/IP local..
Las ordenes o texto en formato NVT llegan a la pila de la maquina TCP/IP remota . Donde pasan por el SO y
llegan al servidor TELNET, que cambia los caracteres por otros entendibles por la computadora remota. Estos
no llegan directamente al SO (no esta preparado para entender ni recibir TELNET) sino que son traducidos
por un controlador de pseudoterminales que hace que parezcan que vienen del propio terminal, de ahí al SO y
este llama o ejecuta las aplicaciones.
6
El NVT:
Para adaptar la heterogeneidad, Telnet define cómo deben mandarse las secuencias de datos y comandos a
través de Internet. La definición se conoce como Network Virtual Terminal (Terminal virtual de red o NVT).
El software del servidor traduce los datos y comandos que acaban de llegar de formato NVT al formato
que el sistema remoto requiera. Para devolver los datos, el servidor remoto traduce del formato de una
máquina remota a NVT y el cliente local traduce del formato NVT al formato de la máquina local.
La definición del formato NVT es bastante clara. Toda comunicación comprende un conjunto de
octetos de 8 bits. Al arrancar, NVT utiliza la representación estándar de 7 bits de USASCII para los
datos y reserva los octetos con el conjunto de bits de alto orden para las secuencias de comandos. El
conjunto de caracteres USASCII incluye 95 caracteres que tienen gráficas imprimibles (por ejemplo,
letras, dígitos y signos de puntuación) as como 33 códigos de control. A todos los caracteres imprimibles
se les asigna el mismo significado que el conjunto de caracteres estándar de USASCII. El estándar NVT
define las implantaciones para los caracteres de control, como se puede observar en la siguiente figura.
Código de
Control ASCII
NUL
BEL
BS
HT
LF
VT
FF
CR
Otro control
Valor
Decimal
0
7
8
9
10
11
12
13
−
Significado Asignado
No hay operación (sin efecto en la salida)
Sonido audible/señal visible (sin movimiento)
Movimiento a la izquierda de un caracter
Movimiento a la derecha al siguente tab
Movimiento hacia abajo (vertical)a la sig. linea
Movimiento hacia abajo al sig. Tab vertical
Movimiento hacia arriba a la siguiente página
Movimiento hacia la izquierda en la línea presente
Sin operación (sin efecto en la salida)
Además de la interpretación de caracteres de control del cuadro, NVT define la terminación de línea
estándar como una secuencia de dos caracteres: CR−LF. Cuando un usuario pulsa la tecla que
corresponde a fin de línea en la terminal local (por ejemplo, ENTER O RETORNO), el cliente Telnet
debe transformarla en CR−LF para su transmisión. El servidor Telnet traduce a CR−LF en la
secuencia de caracteres apropiadas de fin de línea para la máquina remota.La mayor parte de los
sistemas proporciona un mecanismo que permite a los usuarios terminar con un programa que se está
corriendo. Por lo general, el sistema operativo local enlaza dichos mecanismos a una tecla o secuencia
de pulsaciones de teclas en particular.
NVT de Telnet adapta las funciones de control mediante la definición de cómo se transmiten de cliente
a servidor. Conceptualmente, pensamos en NVT como entrada de aceptación de un teclado que puede
generar más de 128 caracteres. Suponemos que el teclado del usuario tiene teclas virtuales
(imaginarias)que corresponden a las funciones que que normalmente se utilizan para el procesamiento
de control. Por ejemplo, NVT define una tecla de interrupción conceptual que pide la terminación de
un programa.
Señal
IP
AO
AYT
(Interrup Process)
(Abort Output)
(Are you there)
Significado
Interrupción del proceso (termina de correrse el programa)
Salida abortada (se descarta cualquier salida de búfer)
Estas ahí (prueba si el servidor responde)
7
EC
EL
(Erase Carácter)
(Erase Line)
SYNCH
(Synchronize)
BRK
(Break)
Borra carácter (borra el carácter previo)
Borra línea (borra toda la línea actual)
Sincroniza (Despeja la trayectoria de datos hasta que el
punto de datos TCP es urgente, pero interpreta comandos)
Pausa (tecla de pausa o señal de atención)
Los diseñadores de NVT eligieron mantener a los comandos separados del conjunto de caracteres ASCI
normales por dos razones. En primer lugar, definir las funciones de control de manera separada
significa que Telnet tiene una mayor flexibilidad. Puede transferir todas las funciones de control
posibles en ASCII entre el cliente y el servidor así como también todas las funciones de control posibles.
En segundo lugar, mediante la separación de señales de los datos normales, NVT permite que el cliente
especifique las señales de manera no ambigua, nunca hay confusión acerca de si un carácter de entrada
se debera tratar como dato o como función de control.
Para transferir las funciones de control a traves de la conexión TCP, Telnet las codifica mediante la
secuencia de escape. Una secuencia de escape se vale de un octeto reservado para indicar que sigue a
continuación un octeto de código de control. En Telnet, el octeto reservado que inicia una secuencia de
escape se conoce como el octeto interpret as command (interpretar como comando o IAC).
5− PROTOCOLO DE TRANSFERENCIA DE ARCHIVOS(FTP):
Es el estandar proporcionado por el protocolo TCP/IP para la transferencia de datos entre cliente y
servidor que puede producirse en cualquier dirección( el cliente puede enviar o pedir un fichero al
servidor).
Descripción de FTP :
Se emplean dos conexiones: la primera es para el login y sigue el protocolo TELNET y la segunda es
para gestionar la transferencia de datos. Como es necesario hacer un login en el host remoto, el usuario
debe tener un nombre de usuario y un password para acceder a ficheros y a directorios. El usuario que
inicia la conexión asume la función de cliente, mientras que el host remoto adopta la función de
servidor
En ambos extremos del enlace, la aplicación FTP se construye con intérprete de protocolo(PI), un
proceso de transferencia de datos, y una interfaz de usuarioLa interfaz de usuario se comunica con el
PI, que está a cargo del control de la conexión. Este intérprete de protocolo ha de comunicar la
información necesaria a su propio sistema de archivos.
En el otro extremo de la conexión, el PI, además de su función de responder al protocolo TELNET, ha
de iniciar la conexión de datos. Durante la transferencia de ficheros, los DTPs se ocupan de gestionar la
transferencia de datos. Una vez que la operación del usuario se ha completado, el PI ha de cerrar la
conexión de control.
FTP ANONIMO:
La comunicación por ftp anónimo es una forma de conectarse a los servidores de ficheros de Internet sin
necesidad de poseer un login,o que significa que permiten el acceso público a los ficheros de algunos
directorios. Existen muchos servidores públicos que admiten conexiones ftp anónimas llamados ftp−sites.
Estos servidores se dedican a distribuir software de dominio público y shareware para cualquier tipo de
ordenador o sistema operativo existente.
8
5−PROTOCOLO SENCILLO DE TRANSFERENCIA DE CORREO ELECTRÓNICO(SMTP):
Este protocolo es el estándar de10 Internet para el intercambio de correo electrónico. SMTP necesita que el
sistema de transmisión ponga a su disposición un canal de comunicación fiable y con entrega ordenada de
paquetes, con lo cual, el uso del protocolo TCP en la capa de transporte, es lo adecuado. Para que dos sistemas
intercambien correo mediante el protocolo SMTP, no es necesario que exista una conexión interactiva, ya que
este protocolo usa métodos de almacenamiento y reenvío de mensajes.
Son tres los protocolos que se aplican a un correo de esta clase. El termino SMTP
Surge uno de los protocolos petrtenecientes al grupo de protocolos involucrados en el envío de correo
electrónico. Los tres protocolos son:
·Un estándar para el intercambio de correo entre dos computadores (RFC 821), el cual especifica el protocolo
usado para enviar correo entre "host" TCP/IP. Este estándar es SMTP.
·Un estándar del formato del mensaje de correo, contenido en dos RFC:
−RFC 822 describe la sintaxis del campoo de título o cabecera del correo
electrónico y describe la interpretación del grupo de campos de la cabecera.
−RFC 1049 describe como un conjunto de otros tipos de documentos, que tengan
texto ASCII, y que pueden ser usados en el cuerpo del correo electrónico.
El nombre del protocolo oficial para este estándar es MAIL.
·Un estándar para el "routing" de "mail" usando el sistema de nombres de
dominio, descrito en RFC 974. El nombre oficial del protocolo para este
estándar es DNS−MX.
Modo de Comunicación SMTP
Cuando un servidor de SMTP, requiere transmitir un mensaje a otro servidor SMTP,
el emisor (servidor que inicia la sesión SMTP) establece una conexión con el
receptor (servidor que recibe petición de establecer sesión SMTP). Esta conexión
es unidireccional, es decir, el emisor puede enviar correo al receptor, pero
durante esa conexión, el receptor no puede enviar correo al emisor. Si el receptor
tiene que enviar correo al emisor, tiene que esperar a que finalice la conexión
establecida y establecer otra en sentido contrario, cambiando los papeles de emisor
y receptor. Una vez establecida la conexión, el emisor envía comandos y mensajes.
9
Los mensajes pueden tener como destino el receptor o un intermediario para llegar
a un destino más lejano. El receptor puede enviar al emisor respuestas y códigos de
estado. Los comandos son cadenas de caracteres que se pueden entender fácilmente y
las respuestas son códigos numéricos seguidos de una explicación del código.
Por lo señalado, SMTP (RFC 821) está basado en entrega "end−to−end". Esto es
diferente del principio guardar y enviar común en muchos sistemas de mensajería
electrónica, donde el mensaje puede pasar a través de un numero de maquinas
intermediarias su camino al destino final.
Existen aplicaciones que permiten intercambiar correo entre el sistema de
mensajería electrónica TCP/IP SMTP y el sistema de correo localmente usado.
Estas aplicaciones son llamadas "Gateways" de correo ("Gateways") o "Bridges"
de correo. Enviar correo a través de un "Gateway" puede alterar la entrega
"end−to−end". El protocolo SMTP solo puede garantizar la entrega al "Gateway"
y no al destino final que está localizado más allá de la red TCP/IP. Cuando el
"Gateway" es usado, la transmisión SMTP "end−to−end" se realiza en varias partes,
de "host" a "Gateway", "Gateway" a "host" o "Gateway" a "Gateway". El comportamiento
más allá del "Gateway" no está especificado por SMTP.
En este modelo de comunicación en primera instancia un usuario establece la
petición de enviar un mensaje a través de correo electrónico, luego el Emisor
SMTP establece una conexión de dos hilos con el Receptor SMTP. El Receptor
SMTP puede ser la destinación última o un intermediario, como es el caso del
"Gateway". El Emisor SMTP genera comandos que son contestados por el Receptor SMTP.
Flujo de Transferencia de los Mensajes de Correo Electrónico:
Aunque los comandos y respuestas son estrictamente definidos por el protocolo,
el intercambio de ellos entre emisor y receptor resultar fácil de comprender.
Todo intercambio de comandos/respuesta/datos (líneas de texto) son delimitados
10
por un CRLF, para facilitar la compresión del protocolo SMTP. Toda respuesta tiene un código numérico al
principio de la línea.
El ejemplo de trasferencia se detalla a continuación:
El Emisor SMTP establece una conexión TCP con el destino SMTP y luego
espera que el servidor envíe un 220 Servicio de lectura de mensaje o un 421
Servicio de mensaje no habilitado, esto ultimo, cuando la destinación está
temporalmente inhabilitada para procesar el mensaje.
·HELO (Es una abreviación de "hello") es enviado para que el receptor identifique
si el Emisor SMTP está enviando su nombre de dominio. El Emisor SMTP puede usarlo
para verificar si contactó la destinación SMTP correcta. Si el Emisor SMTP soporta
Extensión de Servicios ("Service Extensions") SMTP, como está definido en RFC 1651
(Extensión de Servicios es explicada en detalle en la subseccion 2.1.4), puede
sustituir por un comando EHELO el comando HELO. El Receptor SMTP que no soporta
Extensión de Servicios, responde con una sintaxis de error 500, que es un comando
de mensaje no reconocido. El Emisor SMTP debe entonces reintentar con HELO, o si
el emisor no puede transmitir el mensaje sin uno o más de los comandos que son
propios de Extensión de Servicios, éste debe enviar un mensaje QUIT.
·Si el Receptor SMTP soporta Extensión de Servicios, responde con un mensaje
multilínea 250 OK, que incluye una lista de extensión de servicios que soporta.
·El Emisor SMTP, luego de recibir este comando 250 OK, inicializa la transferencia
del mensaje enviando el comando MAIL al Receptor SMTP. Este comando contiene el
"reverse−path" (habitualmente se utiliza para el envío del nombre de dominio del
emisor) que puede ser usado para reportar errores. Esta " reverse−path" puede contener
más que solamente el nombre de dominio de usuario (del emisor), en adición, éste
puede contener una lista de "host" de la ruta. Ejemplo de esto es cuando se pasa
por un "Bridge" o cuando se provee explícitamente información de la ruta en la
dirección de destino. Si el Receptor SMTP acepta responde con un 250 OK.
11
·El segundo paso del intercambio de mensajes a través de correo electrónico, consiste
en proveer al servidor SMTP la destinación para el mensaje. Se realiza enviando uno
o más comandos RCPT TO:forward−path. Cada uno de estos envíos es contestado por
parte del Receptor SMTP con un 250 OK, si la destinación es conocida por el servidor,
o un 550 NO, si tal usuario no es conocido.
·Cuando todos los comandos RCPT son enviados, el Emisor SMTP emite un comando
DATA para notificar al Receptor SMTP que el contenido del mensaje será el siguiente
envío. El Receptor SMTP responde con 354 Start mail input, end with CRLF CRLF.
Esta secuencia final es la que el Emisor SMTP utiliza cuando termina el envío de
datos del mensaje a transferir.
·El cliente ahora envía las líneas de datos, una a una, finalizando con la secuencia
CRLF.CRLF, secuencia que el Receptor SMTP responde con un 250 OK o un mensaje de
error si es que algo ha fallado.
·Luego se tienen algunas opciones:
−El Emisor SMTP no tiene más mensajes qque enviar, por lo que se finaliza la
conexión con un comando QUIT, a lo cual el Receptor SMTP responde con 221 Service
closing transmission channel.
−Si el Emisor SMTP no tiene más mensajees que enviar, pero quiere recibir mensajes
del otro extremo. Este envía el comando TURN. Los dos extremos de la comunicación
SMTP ahora cambian roles de Emisor/Receptor y el nuevo Emisor SMTP (Anterior
Receptor SMTP) puede enviar mensajes partiendo del paso 3 del esquema mostrado
en la Fig. 2−3a.
−Si el Emisor SMTP tiene otro mensaje ppara enviar retorna al paso 3 y envía un
comando MAIL.
6−El PROTOCOLO SENCILLO DE GESTION DE RED(SNMP):
El modelo SNMP de una red administrada consta de cuatro componentes:
12
1− Nodos administrativos.
2− Estaciones administradas.
3− Información de administración.
4− Un protocolo de administración.
Los nodos administrativos pueden ser hosts, enrutadores, puentes, impresoras u otros dispositivos capaces de
comunicar información de estado al mundo exterior. Para ser administrado directamente por el SNMP, un
nodo debe ser capaz de ejecutar un proceso de administración SNMP, llamado agente SNMP. Todas las
computadoras cumplen este requisito, al igual que una cantidad creciente de puentes, enrutadores y
dispositivos periféricos diseñados para uso en redes. Cada agente mantiene una base de datos local de
variables que describen su estado e historia y que afectan su operación.
La administración de la red se hace desde estaciones administradoras, que son, de hecho, computadoras de
propósito general que ejecutan un software de administración especial. La estación administradora contiene
uno o más procesos que se comunican con los agentes a través de la red, emitiendo comandos y recibiendo
respuestas. En este diseño, toda la inteligencia está en las estaciones administradoras, a fin de mantener a los
agentes tan sencillos como sea posible y minimizar su impacto sobre los dispositivos en los que se ejecutan.
Muchas estaciones administradoras tienen una interfaz gráfica de usuario para que el administrador de la red
pueda inspeccionar el estado de la red y emprenda acciones cuando se requieran.
Muchas redes reales son de varios proveedores, con hosts de uno o más fabricantes, puentes y enrutadores de
otras compañías e impresoras de otros fabricantes. A fin de permitir que una estación administradora hable
con estos componentes diversos, la naturaleza de la información mantenida por todos los dispositivos debe
especificarse rígidamente. Hacer que la estación administradora pregunte a un enrutador su tasa de pérdida de
paquetes no es de utilidad si el enrutador no lleva el registro de su tasa de pérdidas. Por tanto, el SNMP
describe (con riguroso detalle) la información exacta de cada tipo de agente que tiene que administrar y el
formato con que éste tiene que proporcionarle los datos. La parte más grande del modelo SNMP es la
definición de quién tiene que llevar el registro de qué y cómo se comunica esta información.
Muy brevemente cada dispositivo mantiene una o más variables que describen su estado. En la documentación
del SNMP, estas variables se llaman objetos. El conjunto de todos los objetos posibles de una red se da en la
estructura de datos llamada MIB (Management Information Base, Base de Información de Administración).
La estación administradora interactúa con los agentes usando el protocolo SNMP. Este protocolo permite a la
estación administradora consultar el estado de los objetos locales de un agente, y cambiarlo de ser necesario.
La mayor parte del SNMP consiste en este tipo de comunicación consulta−respuesta.
Sin embargo, a veces ocurren sucesos no planeados. Los nodos administrativos pueden caerse y volver a
activarse, las líneas pueden desactivarse y levantarse de nuevo, pueden ocurrir congestiones, etc. Cada suceso
significativo se define en un módulo MIB. Cuando un agente nota que ha ocurrido un suceso significativo, de
inmediato lo informa a todas las estaciones administradoras de su lista de configuración. Este informe se
llama interrupción SNMP. El informe en general sencillamente indica que ha ocurrido un suceso; es
responsabilidad de la estación administradora emitir consultas para averiguar los detalles. Dado que la
comunicación entre los nodos administrativos no es confiable, algunas estaciones administradoras de todas
maneras sondean ocasionalmente cada nodo administrado, buscando sucesos inusuales.
Este modelo supone que cada nodo administrado es capaz de ejecutar un agente SNMP internamente. Los
dispositivos más viejos y los dispositivos no contemplados para usarse en redes podrían no tener esa
capacidad. Para manejarlos, el SNMP define un agente apoderado, es decir un agente que supervisa uno o más
13
dispositivos no SNMP y se comunica con la estación administradora a nombre de ellos.
Por último, la seguridad y la validación de identificación desempeñan un papel preponderante en el SNMP.
Una estación administradora también tiene la capacidad de aprender mucho sobre cada nodo que está bajo su
control, y también puede apagarlos todos. Por tanto, es de gran importancia que los agentes están convencidos
de que las consultas supuestamente originadas por la estación administradora realmente vienen de dicha
estación.
7−EL WORLD WIDE WEB(WWW):
El World Wide Web es un sistema gobal de hipertexto desarrollado inicialmente en 1989 por Tim Berners Lee
en el Laboratorio Europeo de Física de Partículas, ("European Laboratory for Particle Physics, CERN") en
Suiza
El protocolo estándar de comunicaciones entre servidores y clientes Web es el HTTP("Hypertext Transfer
Protocol"), que es un borrador de estándar de Internet. El HTTP es un protocolo orientado a objetos genérico
y sin estado. El IETF ha establecido un grupo de trabajo para mejorar su eficacia. Los navegadores pueden
usar además otros protocolos como el FTP, Gopher, WAIS y NNTP ("Network News Transfer Protocol") por
ejemplo. Por ello, no hace falta un cliente determinado para conseguir acceso a todos estos otros recursos que
también están disponibles en la red. El modo en que los navegadores pueden diferenciar entre todos estos
protocolos y qué protocolos son los que soportan se explica posteriormente en esta sección.
Una transacción HTTP consiste básicamente en:
Conexión
El establecimiento de una conexión del cliente con el servidor. El puerto TCP/IP 80 es el puerto bien
conocido, pero el URL puede especificar otros puertos no reservados.
Solicitud
El envío por parte del cliente de un mensaje de solicitud al servidor.
Respuesta
El envío por parte del servidor de una respuesta al cliente.
Cierre
El cierre de la conexión por parte del cliente y el servidor.
Para una descripción más detallada de HTT, remitirse a los documentos del grupo de trabajo del IETF.
El lenguaje estándar de marcas para documentos Web es HTML ("Hypertext Markup Language"), que es un
borrador de estándar de Internet y actualmente varios grupos de trabajo del IETF están trabajando en él.
HTMP es una aplicación de SGML("Standard Generalized Markup Language"). Para crear un documento
Web hay que usar las marcas HTML que constituyen la estructura lógica del documento, por ejemplo,
cabeceras, listas y párrafos. Aquí se muestran algunas marcas para definir enlaces a otros documentos o para
embeber una imagen en el texto.
Todos los documentos, imágenes, clips de audio o de vídeo se denomina recurso Web Para identificar el
método de acceso a estos recursos el Web emplea URLs("(Uniform Resource Locators). URL es un protocolo
14
estándar de Internet y se puede encontrar en el RFC 1738. El contexto global para construir nuevos esquemas
para codificar nombres y direcciones de objetos en Internet se describe en el RFC informacional 1630. Este
RFC acuña el término URI(Universal Resource Identifiers) como un modelo más teórico para diseñar estos
esquemas. Los URIs que se refieren a una dirección objeto(dirección IP e información de la ruta de
acceso)mapeados a un método de acceso conocido usando un protocolo de red existente como HTTP o FTP se
conocen como URLs. Por lo tanto, un URL es una forma específica de un URI
Hay tres formas de acceder a la Web:
a− Usar un navegador . Es la mejor opción, aunque la LAN debe tener acceso a Internet. En la mayoría de los
casos estas redes no tienen acceso directo a Internet, sino que se conectan a través de un cortafuegos. En este
caso hay que especificar un servidor SOCKS o un proxy en el que el host se registra para obtener el acceso.
Otra forma de conectarse es con el protocolo SLIP.
b− Usar un navegador en una máquina a la que se tiene acceso por TELNET.
c− Acceder la Web por E−mail.
CAPA
DE APLICACIÓN
DEL MODELO
TCP/IP
15