¿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 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 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).

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

Etiqueta:	Descripción:
Edu	Instituciones educativas
Gov	Instituciones gubernamentales
Int	Organizaciones internacionales
Mil	Grupos militares
Net	Centros de soporte de red
Org	Organizaciones sin ánimo de lucro
Arts	Organizaciones culturales
Firm	Negocios o empresas
Info	Proveedores de servicios de información
Nom	Nomenclaturas personales
Rec	organizaciones recreativas y de entretenimiento
Store	Negocios que ofrecen bienes para comprar
Web	Organizaciones relacionadas con la web
Com	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.

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.

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	Valor Decimal	Significado Asignado
NUL	0	No hay operación (sin efecto en la salida)
BEL	7	Sonido audible/señal visible (sin movimiento)
BS	8	Movimiento a la izquierda de un caracter
HT	9	Movimiento a la derecha al siguente tab
LF	10	Movimiento hacia abajo (vertical)a la sig. linea
VT	11	Movimiento hacia abajo al sig. Tab vertical
FF	12	Movimiento hacia arriba a la siguiente página
CR	13	Movimiento hacia la izquierda en la línea presente
Otro control	-	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		Significado
IP	(Interrup Process)	Interrupción del proceso (termina de correrse el programa)
AO	(Abort Output)	Salida abortada (se descarta cualquier salida de búfer)
AYT	(Are you there)	Estas ahí (prueba si el servidor responde)
EC	(Erase Carácter)	Borra carácter (borra el carácter previo)
EL	(Erase Line)	Borra línea (borra toda la línea actual)
SYNCH	(Synchronize)	Sincroniza (Despeja la trayectoria de datos hasta que el punto de datos TCP es urgente, pero interpreta comandos)
BRK	(Break)	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.

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.

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

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.

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

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