republica bolivariana de venezuela ministerio del poder popular

REPUBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA DEFENSA
UNIVERSIDAD NACIONAL EXPERIMENTAL DE LA FUERZA ARMANDA
UNEFA NUCLEO ZULIA SEDE EL MILAGRO
MARACAIBO, ESTADO ZULIA
REALIZADO POR:
SOTO GARCÍA, LUIS MANUEL
C.I.: 19550568
SECCIÓN: 08 ISI M01
PROFESOR: ING. JOSE PARRA
MARCAIBO, FEBRERO DEL 2012
ARQUITECTURA TCP/IP
TCP/IP (Protocolo de Control de Transmisión/Protocolo de Internet) es un conjunto
de protocolos que definen cómo se intercambian todas las transmisiones a través de
cualquier grupo de redes interconectadas
El primer modelo de protocolo en capas para comunicaciones de internetwork se
creó a principios de la década de los setenta y se conoce con el nombre de modelo de
Internet. Define cuatro categorías de funciones que deben tener lugar para que las
comunicaciones sean exitosas. La arquitectura de la suite de protocolos TCP/IP sigue la
estructura de este modelo. Por esto, es común que al modelo de Internet se lo conozca
como modelo TCP/IP.
La mayoría de los modelos de protocolos describen un stack de protocolos
específicos del proveedor. Sin embargo, puesto que el modelo TCP/IP es un estándar
abierto, una compañía no controla la definición del modelo. Las definiciones del estándar
y los protocolos TCP/IP se explican en un foro público y se definen en un conjunto de
documentos disponibles al público. Estos documentos se denominan Solicitudes de
comentarios (RFCS). Contienen las especificaciones formales de los protocolos de
comunicación de datos y los recursos que describen el uso de los protocolos.
Las RFC (Solicitudes de comentarios) también contienen documentos técnicos y
organizacionales sobre Internet, incluyendo las especificaciones técnicas y los documentos
de las políticas producidos por el Grupo de trabajo de ingeniería de Internet (IETF).
COMPARACION ENTRE EL MODELO OSI Y EL MODELO TCP/IP
Los protocolos que forman la suite de protocolos TCP/IP pueden describirse en
términos del modelo de referencia OSI. En el modelo OSI, la capa Acceso a la red y la capa
Aplicación del modelo TCP/IP están subdivididas para describir funciones discretas que
deben producirse en estas capas.
En la capa Acceso a la red, la suite de protocolos TCP/IP no especifica cuáles
protocolos utilizar cuando se transmite por un medio físico; sólo describe la transferencia
desde la capa de Internet a los protocolos de red física. Las Capas OSI 1 y 2 analizan los
procedimientos necesarios para tener acceso a los medios y los medios físicos para enviar
datos por una red.
Los paralelos clave entre dos modelos de red se producen en las Capas 3 y 4 del
modelo OSI. La Capa 3 del modelo OSI, la capa Red, se utiliza casi universalmente para
analizar y documentar el rango de los procesos que se producen en todas las redes de
datos para direccionar y enrutar mensajes a través de una internetwork. El Protocolo de
Internet (IP) es el protocolo de la suite TCP/IP que incluye la funcionalidad descrita en la
Capa 3.
La Capa 4, la capa Transporte del modelo OSI, con frecuencia se utiliza para
describir servicios o funciones generales que administran conversaciones individuales
entre los hosts de origen y de destino. Estas funciones incluyen acuse de recibo,
recuperación de errores y secuenciamiento. En esta capa, los protocolos TCP/IP, Protocolo
de control de transmisión (TCP) y Protocolo de datagramas de usuario (UDP) proporcionan
la funcionalidad necesaria.
La capa de aplicación TCP/IP incluye una cantidad de protocolos que proporcionan
funcionalidad específica para una variedad de aplicaciones de usuario final. Las Capas 5, 6
y 7 del modelo OSI se utilizan como referencias para proveedores y programadores de
software de aplicación para fabricar productos que necesitan acceder a las redes para
establecer comunicaciones.
DIRECIONAMIENTO IP
Además de la dirección física (en la interfaz de red) que identifica al dispositivo
individual, Internet requiere una convención en el direccionamiento: una dirección que
identifique la conexión de una estación a la red, Cada dirección Internet consta de 4 bytes
(32 bits) que definen tres campos: la clase, el identificador de la red y el identificador de la
estación. Estas partes son de longitud variable dependiendo de las clases de direcciones.
DATAGRAMAS IP
Hay dos formas de encaminar los paquetes en una red conmutación de paquetes.
Estas son: datagrama y circuito virtual. En la técnica de datagrama cada paquete se trata
de forma independiente, conteniendo cada uno la dirección de destino. La red puede
encaminar (mediante un router) cada fragmento hacia el Equipo Terminal de Datos (ETD)
receptor por rutas distintas. Esto no garantiza que los paquetes lleguen en el orden
adecuado ni que todos lleguen al destino.
Protocolos basados en datagramas: IPX, UDP, IPoAC, CL. Los datagramas tienen
cabida en los servicios de red no orientados a la conexión (como por ejemplo UDP o
Protocolo de Datagrama de Usuario). Los datagramas IP son las unidades principales de
información de Internet. Los términos trama, mensaje, paquete de red y segmento
también se usan para describir las agrupaciones de información lógica en las diversas
capas del modelo de referencia OSI y en los diversos círculos tecnológicos.
La estructura de un datagrama es: cabecera y datos. Un datagrama tiene
una cabecera que contiene una información de direcciones de la capa de red.
Los encaminadores examinan la dirección de destino de la cabecera, para dirigir los
datagramas al destino.
Internet es una red de datagramas. La conmutación de los paquetes puede ser
orientada a conexión y no orientada a conexión. En el caso orientado a conexión,
el protocolo utilizado para transporte es TCP. TCP garantiza que todos los datos lleguen
correctamente y en orden. En el caso no orientado a conexión, el protocolo utilizado para
transporte es UDP. UDP no tiene ninguna garantía.Sin embargo esta propiedad de los
UDP; es básicamente, la que hacen tan preferido los protocolos SNMP (Simple Network
Management Protocol), aportandole la baja carga a la red que posee y su absoluta
independencia al hardware entre los que facilita el intercambio de información. Opción
que debe aumentar en el tiempo, si tenemos en cuenta que las primeras versiones de los
SNMP datan de la era de los microprocesadores de 8 bits.
CORREO ELECTRONICO
Correo electrónico (correo-e, conocido también como e-mail ), es un servicio de
red que permite a los usuarios enviar y recibir mensajes y archivos rápidamente (también
denominados mensajes electrónicos o cartas electrónicas)
mediante
sistemas
de
comunicación electrónicos. Principalmente se usa este nombre para denominar al sistema
que provee este servicio en Internet, mediante el protocolo SMTP, aunque por extensión
también puede verse aplicado a sistemas análogos que usen otras tecnologías. Por medio
de mensajes de correo electrónico se puede enviar, no solamente texto, sino todo tipo de
documentos digitales. Su eficiencia, conveniencia y bajo coste están logrando que el
correo electrónico desplace al correo ordinario para muchos usos habituales.
El correo electrónico antecede a la Internet, y de hecho, para que ésta pudiera ser
creada, fue una herramienta crucial. En una demostración del MIT (Massachusetts
Institute of Technology) de 1961, se exhibió un sistema que permitía a varios usuarios
ingresar a una IBM 7094 desde terminales remotas, y así guardar archivos en el disco. Esto
hizo posibles nuevas formas de compartir información. El correo electrónico comenzó a
utilizarse en 1965 en una supercomputadora de tiempo compartido y, para 1966, se había
extendido rápidamente para utilizarse en las redes de computadoras.
En 1971, Ray Tomlinson incorporó el uso de la arroba (@). Eligió la arroba como
divisor entre el usuario y la computadora en la que se aloja la casilla de correo porque no
existía la arroba en ningún nombre ni apellido. En inglés la arroba se lee «at» (en). Así,
fulano@máquina.com se lee fulano en máquina punto com. El nombre correo
electrónico proviene de la analogía con el correo postal: ambos sirven para enviar y recibir
mensajes, y se utilizan "buzones" intermedios (servidores), en donde los mensajes se
guardan temporalmente antes de dirigirse a su destino, y antes de que el destinatario los
revise.
Principales protocolos usados en el correo electrónico:




MIME
SMTP
POP3
IMAP
ARQUITECTURA X.400
Es un estándar conforme al Modelo de interconexión de sistemas abiertos OSI,
para el intercambio de correo electrónico (por entonces se llamaban Mensajes
Interpersonales o IPMs) desarrollado por el ITU-T (por entonces llamado CCITT) con el
beneplácito del ISO desde el año 1984 .
Como le pasó a la mayor parte de los estándares OSI del Nivel de aplicación no
soportó la competencia con el protocolo similar Internet, en este caso el SMTP. El correo
X.400 llegó a tener una base de usuarios relativamente amplia, especialmente en Europa,
sobre todo en entornos corporativos y de investigación. El modelo de correo era más
robusto y completo que el equivalente de Internet. Su sistema de direcciones de correo,
basado en X.500, era demasiado complicado para la época, aunque muchísimo más
potente. Como todos los estándares OSI, este era el recomendado/soportado por las
compañías telefónicas (por la época y en Europa casi todas eran monopolios estatales)
que ofertaban unas tarifas de conexión excesivas. Un poco por todo ello el estándar OSI
no tuvo gran aceptación. No obstante aún se usa el correo X.400 en algunas aplicaciones
sectoriales que requieran mayor seguridad e integridad (como aplicaciones militares), y es
el modelo que hay por debajo de aplicaciones relativamente populares como Lotus Notes.
La primera versión de X.400 es de 1984 (el Libro Rojo), se revisó en profundidad
en 1988 (Libro Azul). Se le añadieron nuevas funciones en 1992 (Libro Blanco), y en
sucesivas actualizaciones. Los principales protocolos de X.400 eran: P1 para comunicación
entre MTA's (las "estafetas electrónicas"), P3 entre agentes de usuario (UA, osea el
programa de correo electrónico del usuario final) y MTA, y P7 entre UA y almacenes de
mensajes. Se definieron protocolos conceptuales para la comunicación entre UAs, a pesar
de que esto no podía darse directamente, usando P1 y P3 como canal fiable. Este
protocolo se llamó P2 en Libro Rojo y P22 en el Libro Azul.
Algunas características sobresalientes de X.400 eran la separación entre contenido
y "sobre", las direcciones estructuradas, la posibilidad de contenido multimedia
(en MIME) y el tratamiento integral del cifrado y autentificación. Dado que las operadoras
de X.400 eran las Telefónicas se describieron pasarelas hacia otros servicios como el télex,
el fax o el correo ordinario. El hecho de que requiriera control centralizado, puede que
tenga que ver con el hecho de que no tuviera mucho éxito.
ARQUITECTURA SMTP (SIMPLE MAIL TRANSFER PROTOCOL)
Simple Mail Transfer Protocol (SMTP) Protocolo Simple de Transferencia de Correo,
es un protocolo de la capa de aplicación.Protocolo de red basado en textos utilizados para
el intercambio de mensajes de correo electrónico entre computadoras u otros dispositivos
(PDA's, teléfonos móviles, etc.). Está definido en el RFC 2821 y es un estándar oficial de
Internet.
SMTP se basa en el modelo cliente-servidor, donde un cliente envía un mensaje a
uno o varios receptores. La comunicación entre el cliente y el servidor consiste
enteramente en líneas de texto compuestas por caracteres ASCII. El tamaño máximo
permitido para estas líneas es de 1000 caracteres.
Las respuestas del servidor constan de un código numérico de tres dígitos, seguido
de un texto explicativo. El número va dirigido a un procesado automático de la respuesta
por autómata, mientras que el texto permite que un humano interprete la respuesta. En
el protocolo SMTP todas las órdenes, réplicas o datos son líneas de texto, delimitadas por
el carácter <CRLF>. Todas las réplicas tienen un código numérico al comienzo de la línea.
En el conjunto de protocolos TCP/IP, el SMTP va por encima del TCP, usando
normalmente el puerto 25 en el servidor para establecer la conexión.
RESUMEN SIMPLE DEL FUNCIONAMIENTO DEL PROTOCOLO SMTP
 Cuando un cliente establece una conexión con el servidor SMTP, espera a que éste
envíe un mensaje “220 Service ready” o “421 Service non available”
 Se envía un HELO desde el cliente. Con ello el servidor se identifica. Esto puede
usarse para comprobar si se conectó con el servidor SMTP correcto.
 El cliente comienza la transacción del correo con la orden MAIL FROM. Como
argumento de esta orden se puede pasar la dirección de correo al que el servidor
notificará cualquier fallo en el envío del correo (Por ejemplo, MAIL
FROM:<fuente@host0>). Luego si el servidor comprueba que el origen es valido, el
servidor responde “250 OK”.
 Ya le hemos dicho al servidor que queremos mandar un correo, ahora hay que
comunicarle a quien. La orden para esto es RCPT TO:<destino@host>. Se pueden
mandar tantas órdenes RCPT como destinatarios del correo queramos. Por cada
destinatario, el servidor contestará “250 OK” o bien “550 No such user here”, si no
encuentra al destinatario.
 Una vez enviados todos los RCPT, el cliente envía una orden DATA para indicar que
a continuación se envían los contenidos del mensaje. El servidor responde “354
Start mail input, end with <CRLF>.<CRLF>” Esto indica al cliente como ha de
notificar el fin del mensaje.
 Ahora el cliente envía el cuerpo del mensaje, línea a línea. Una vez finalizado, se
termina con un <CRLF>.<CRLF> (la última línea será un punto), a lo que el servidor
contestará “250 OK”, o un mensaje de error apropiado.
 Tras el envío, el cliente, si no tiene que enviar más correos, con la
orden QUIT corta la conexión. También puede usar la orden TURN, con lo que el
cliente pasa a ser el servidor, y el servidor se convierte en cliente. Finalmente, si
tiene más mensajes que enviar, repite el proceso hasta completarlos.
Puede que el servidor SMTP soporte las extensiones definidas en el RFC 1651, en
este caso, la orden HELO puede ser sustituida por la orden EHLO, con lo que el servidor
contestará con una lista de las extensiones admitidas. Si el servidor no soporta las
extensiones, contestará con un mensaje "500 Syntax error, command unrecognized".
EN EL EJEMPLO PUEDEN VERSE LAS ÓRDENES BÁSICAS DE SMTP:

HELO, para abrir una sesión con el servidor

MAIL FROM, para indicar quien envía el mensaje

RCPT TO, para indicar el destinatario del mensaje

DATA, para indicar el comienzo del mensaje, éste finalizará cuando haya una línea
únicamente con un punto.

QUIT, para cerrar la sesión

RSET Aborta la transacción en curso y borra todos los registros.

SEND Inicia una transacción en la cual el mensaje se entrega a una terminal.

SOML El mensaje se entrega a un terminal o a un buzón.

SAML El mensaje se entrega a un terminal y a un buzón.

VRFY Solicita al servidor la verificación del argumento.

EXPN Solicita al servidor la confirmación del argumento.

HELP Permite solicitar información sobre un comando.

NOOP Se emplea para reiniciar los temporizadores.

TURN Solicita al servidor que intercambien los papeles.
De los tres dígitos del código numérico, el primero indica la categoría de la respuesta,
estando definidas las siguientes categorías:
2XX, la operación solicitada mediante el comando anterior ha sido concluida con
éxito
 3XX, la orden ha sido aceptada, pero el servidor esta pendiente de que el cliente le
envíe nuevos datos para terminar la operación
 4XX, para una respuesta de error, pero se espera a que se repita la instrucción
 5XX, para indicar una condición de error permanente, por lo que no debe repetirse
la orden

Una vez que el servidor recibe el mensaje finalizado con un punto puede
almacenarlo si es para un destinatario que pertenece a su dominio, o bien retransmitirlo a
otro servidor para que finalmente llegue a un servidor del dominio del receptor.
MODELO CLIENTE – SERVIDOR
Cuando la gente intenta acceder a información en sus dispositivos, ya sean éstos
una computadora personal o portátil, un PDA, teléfono celular o cualquier otro dispositivo
conectado a la red, los datos pueden no estar físicamente almacenados en sus
dispositivos. Si así fuere, se debe solicitar al dispositivo que contiene los datos, permiso
para acceder a esa información.
En el modelo cliente-servidor, el dispositivo que solicita información se denomina
cliente y el dispositivo que responde a la solicitud se denomina servidor. Los procesos de
cliente y servidor se consideran una parte de la capa de Aplicación. El cliente comienza el
intercambio solicitando los datos al servidor, que responde enviando uno o más streams
de datos al cliente. Los protocolos de capa de Aplicación describen el formato de las
solicitudes y respuestas entre clientes y servidores. Además de la transferencia real de
datos, este intercambio puede requerir de información adicional, como la autenticación
del usuario y la identificación de un archivo de datos a transferir.
Un ejemplo de una red cliente/servidor es un entorno corporativo donde los
empleados utilizan un servidor de e-mail de la empresa para enviar, recibir y almacenar emails. El cliente de correo electrónico en la computadora de un empleado emite una
solicitud al servidor de e-mail para un mensaje no leído. El servidor responde enviando el
e-mail solicitado al cliente.
Aunque los datos generalmente se describen como un flujo del servidor al cliente,
algunos datos siempre fluyen del cliente al servidor. El flujo de datos puede ser el mismo
en ambas direcciones o inclusive ser mayor en la dirección que va del cliente al servidor.
Por ejemplo, un cliente puede transferir un archivo al servidor con fines de
almacenamiento. La transferencia de datos de un cliente a un servidor se conoce como
subida y la de los datos de un servidor a un cliente, descarga.
En un contexto general de redes, cualquier dispositivo que responde a una
solicitud de aplicaciones de cliente funciona como un servidor. Un servidor generalmente
es una computadora que contiene información para ser compartida con muchos sistemas
de cliente. Por ejemplo, páginas Web, documentos, bases de datos, imágenes, archivos de
audio y vídeo pueden almacenarse en un servidor y enviarse a los clientes que lo solicitan.
En otros casos, como una impresora de red, el servidor de impresión envía las solicitudes
de impresión del cliente a la impresora específica.
Diferentes tipos de aplicaciones del servidor tienen diferentes requerimientos para
el acceso de clientes. Algunos servidores pueden requerir de autenticación de la
información de cuenta del usuario para verificar si el usuario tiene permiso para acceder a
los datos solicitados o para utilizar una operación en particular. Dichos servidores deben
contar con una lista central de cuentas de usuarios y autorizaciones, o permisos (para
operaciones y acceso a datos) otorgados a cada usuario. Cuando se utiliza un cliente FTP,
por ejemplo, si usted solicita subir datos al servidor FTP, se le puede dar permiso para
escribir su carpeta personal pero no para leer otros archivos del sitio.
En una red cliente-servidor, el servidor ejecuta un servicio o proceso, a veces
denominado daemon de servidor. Al igual que la mayoría de los servicios, los daemons
generalmente se ejecutan en segundo plano y no se encuentran bajo control directo del
usuario. Los daemons se describen como servidores que "escuchan" una solicitud del
cliente, porque están programados para responder cada vez que el servidor recibe una
solicitud para el servicio proporcionado por el daemon. Cuando un daemon "escucha" una
solicitud de un cliente, intercambia los mensajes adecuados con el cliente, según lo
requerido por su protocolo, y procede a enviar los datos solicitados al cliente en el
formato correspondiente.
MASCARAS DE SUB REDES
La máscara de red es una combinación de bits que sirve para delimitar el ámbito de
una red de computadoras. Su función es indicar a los dispositivos qué parte de la dirección
IP es el número de la red, incluyendo la subred, y qué parte es la correspondiente al host.
FUNCIONAMIENTO
Básicamente, mediante la máscara de red una computadora (principalmente
la puerta de enlace, router...) podrá saber si debe enviar los datos dentro o fuera de las
redes. Por ejemplo, si el router tiene la dirección IP 192.168.1.1 y máscara de red
255.255.255.0, entiende que todo lo que se envía a una dirección IP que empiece por
192.168.1 va para la red local y todo lo que va a otras direcciones IP, para afuera (internet,
otra red local mayor...).
Supongamos que tenemos un rango de direcciones IP desde 10.0.0.0 hasta
10.255.255.255. Si todas ellas formaran parte de la misma red, su máscara de red sería:
255.0.0.0. También se puede escribir como 10.0.0.0/8
Como una máscara consiste en una seguidilla de unos consecutivos, y luego ceros
(si los hay), los números permitidos para representar la secuencia son los siguientes: 0,
128, 192, 224, 240, 248, 252, 254 y 255.
La representación utilizada se define colocando en 1 todos los bits de red (máscara
natural) y en el caso de subredes, se coloca en 1 los bits de red y los bits de host usados
por las subredes. Así, en esta forma de representación (10.0.0.0/8) el 8 sería la cantidad
de bits puestos a 1 que contiene la máscara en binario, comenzando desde la izquierda.
Para el ejemplo dado (/8), sería 11111111.00000000.00000000.00000000 y en su
representación en decimal sería 255.0.0.0.
Una máscara de red representada en binario son 4 octetos de bits
(11111111.11111111.11111111.11111111).
EJEMPLO
 8bit x 4 octetos = 32 bit. (11111111.11111111.11111111.11111111 =
255.255.255.255)
 8bit x 3 octetos = 24 bit. (11111111.11111111.11111111.00000000 =
255.255.255.0)
 8bit x 2 octetos = 16 bit. (11111111.11111111.00000000.00000000 = 255.255.0.0)
 8bit x 1 octetos = 8 bit. (11111111.00000000.00000000.00000000 = 255.0.0.0)
En el ejemplo 10.0.0.0/8, según lo explicado anteriormente, indicaría que la máscara de
red es 255.0.0.0
Las máscaras de redes , se utilizan como validación de direcciones realizando una
operación AND lógica entre la dirección IP y la máscara para validar al equipo, lo cual
permite realizar una verificación de la dirección de la Red y con un OR y la máscara negada
se obtiene la dirección del broadcasting.
TABLA DE MÁSCARAS DE RED
MÁSCARAS DE RED
Binario
Decimal
CIDR Nº HOSTs
Clase
11111111.11111111.11111111.11111111 255.255.255.255 /32 1
11111111.11111111.11111111.11111110 255.255.255.254 /31 2
11111111.11111111.11111111.11111100 255.255.255.252 /30 4
11111111.11111111.11111111.11111000 255.255.255.248 /29 8
11111111.11111111.11111111.11110000 255.255.255.240 /28 16
11111111.11111111.11111111.11100000 255.255.255.224 /27 32
11111111.11111111.11111111.11000000 255.255.255.192 /26 64
11111111.11111111.11111111.10000000 255.255.255.128 /25 128
11111111.11111111.11111111.00000000 255.255.255.0
/24 256
11111111.11111111.11111110.00000000 255.255.254.0
/23 512
11111111.11111111.11111100.00000000 255.255.252.0
/22 1024
11111111.11111111.11111000.00000000 255.255.248.0
/21 2048
11111111.11111111.11110000.00000000 255.255.240.0
/20 4096
11111111.11111111.11100000.00000000 255.255.224.0
/19 8192
11111111.11111111.11000000.00000000 255.255.192.0
/18 16384
11111111.11111111.10000000.00000000 255.255.128.0
/17 32768
11111111.11111111.00000000.00000000 255.255.0.0
/16 65536
11111111.11111110.00000000.00000000 255.254.0.0
/15 131072
11111111.11111100.00000000.00000000 255.252.0.0
/14 262144
11111111.11111000.00000000.00000000 255.248.0.0
/13 524288
11111111.11110000.00000000.00000000 255.240.0.0
/12 1048576
11111111.11100000.00000000.00000000 255.224.0.0
/11 2097152
11111111.11000000.00000000.00000000 255.192.0.0
/10 4194304
11111111.10000000.00000000.00000000 255.128.0.0
/9
8388608
11111111.00000000.00000000.00000000 255.0.0.0
/8
16777216
11111110.00000000.00000000.00000000 254.0.0.0
/7
33554432
11111100.00000000.00000000.00000000 252.0.0.0
/6
67108864
11111000.00000000.00000000.00000000 248.0.0.0
/5
134217728
C
B
A
11110000.00000000.00000000.00000000 240.0.0.0
/4
268435456
11100000.00000000.00000000.00000000 224.0.0.0
/3
536870912
11000000.00000000.00000000.00000000 192.0.0.0
/2
1073741824
10000000.00000000.00000000.00000000 128.0.0.0
/1
2147483648
00000000.00000000.00000000.00000000 0.
/0
4294967296
Las máscaras 255.0.0.0 (clase A), 255.255.0.0 (clase B) y 255.255.255.0 (clase C)
suelen ser suficientes para la mayoría de las redes privadas. Sin embargo, las redes más
pequeñas que podemos formar con estas máscaras son de 254 hosts y para el caso de
direcciones públicas, su contratación tiene un coste alto. Por esta razón suele ser habitual
dividir las redes públicas de clase C en subredes más pequeñas. A continuación se
muestran las posibles divisiones de una red de clase C. La división de una red en subredes
se conoce como Subnetting.
CLASES DE MÁSCARAS EN SUBREDES
Clase Bits IP Subred IP Broadcast
Máscara en decimal CIDR
A
0
0.0.0.0
127.255.255.255 255.0.0.0
/8
B
10
128.0.0.0 191.255.255.255 255.255.0.0
C
110 192.0.0.0 223.255.255.255 255.255.255.0
/24
D
1110 224.0.0.0 239.255.255.255 sin definir
sin definir
E
1111 240.0.0.0 255.255.255.254 sin definir
sin definir
/16
PROTOCOLOS POP (POST OFFICE PROTOCOL)
En informática se utiliza el Post Office Protocol (POP3, Protocolo de la oficina de
correo) en clientes locales de correo para obtener los mensajes de correo electrónico
almacenados en un servidor remoto. Es un protocolo de nivel de aplicación en el Modelo
OSI.
Las versiones del protocolo POP (informalmente conocido como POP1) y POP2 se
han hecho obsoletas debido a las últimas versiones de POP3. En general cuando uno se
refiere al término POP, nos referimos a POP3 dentro del contexto de protocolos de correo
electrónico.
POP3 está diseñado para recibir correo, no para enviarlo; le permite a los usuarios
con conexiones intermitentes o muy lentas (tales como las conexiones por módem),
descargar su correo electrónico mientras tienen conexión y revisarlo posteriormente
incluso estando desconectados. Cabe mencionar que la mayoría de los clientes de correo
incluyen la opción dedejar los mensajes en el servidor, de manera tal que, un cliente que
utilice POP3 se conecta, obtiene todos los mensajes, los almacena en la computadora del
usuario como mensajes nuevos, los elimina del servidor y finalmente se desconecta. En
contraste, el protocolo IMAP permite los modos de operación conectado y desconectado.
Los clientes de correo electrónico que utilizan IMAP dejan por lo general los
mensajes en el servidor hasta que el usuario los elimina directamente. Esto y otros
factores hacen que la operación de IMAP permita a múltiples clientes acceder al mismo
buzón de correo. La mayoría de los clientes de correo electrónico soportan POP3 ó IMAP;
sin embargo, solo unos cuantos proveedores de internet ofrecen IMAP como valor
agregado de sus servicios.
PROTOCOLOS IMAP (INTERNET MESSAGE ACCESS PROTOCOL)
Internet Message Access Protocol, o su acrónimo IMAP, es un protocolo de red de
acceso a mensajes electrónicos almacenados en un servidor. Mediante IMAP se puede
tener acceso al correo electrónico desde cualquier equipo que tenga una conexión a
Internet. IMAP tiene varias ventajas sobre POP, que es el otro protocolo empleado para
obtener correo desde un servidor. Por ejemplo, es posible especificar en IMAP carpetas
del lado servidor. Por otro lado, es más complejo que POP ya que permite visualizar los
mensajes de manera remota y no descargando los mensajes como lo hace POP.
IMAP y POP3 (Post Office Protocol versión 3) son los dos protocolos que
prevalecen en la obtención de correo electrónico. Todos los servidores y clientes de email
están virtualmente soportados por ambos, aunque en algunos casos hay algunas
interfaces específicas del fabricante típicamente propietarias. Por ejemplo, los protocolos
propietarios utilizados entre el cliente Microsoft Outlook y su servidor Microsoft Exchange
Server o el cliente Lotus Notes de IBM y el servidor Domino. Sin embargo, estos productos
también soportan interoperabilidad con IMAP y POP3 con otros clientes y servidores. La
versión actual de IMAP, IMAP versión 4 revisión 1 (IMAP4rev1), está definida por el RFC
3501.
IMAP fue diseñado como una moderna alternativa a POP por Mark Crispin en el
año 1986. ver web. Fundamentalmente, los dos protocolos les permiten a los clientes de
correo acceder a los mensajes almacenados en un servidor de correo.
Ya sea empleando POP3 o IMAP4 para obtener los mensajes, los clientes
utilizan SMTP para enviar mensajes. Los clientes de correo electrónico son comúnmente
denominados clientes POP o IMAP, pero en ambos casos se utiliza SMTP.
La mayoría de los clientes de correo utilizan LDAP para sus servicios de directorio.
IMAP es utilizado frecuentemente en redes grandes; por ejemplo los sistemas de
correo de un campus. IMAP les permite a los usuarios acceder a los nuevos mensajes
instantáneamente en sus computadoras, ya que el correo está almacenado en la red. Con
POP3 los usuarios tendrían que descargar el email a sus computadoras o accederlo vía
web. Ambos métodos toman más tiempo de lo que le tomaría a IMAP, y se tiene que
descargar el email nuevo o refrescar la página para ver los nuevos mensajes.
VENTAJAS SOBRE POP3
Algunas de las características importantes que diferencian a IMAP y POP3 son:
 Respaldo para los modos de operación en línea y fuera de línea: Al utilizar POP3,
los clientes se conectan brevemente al servidor de correo, solamente el tiempo
que les tome descargar los nuevos mensajes. Al utilizar IMAP, los clientes
permanecen conectados el tiempo que su interfaz permanezca activa y descargan
los mensajes bajo demanda. Esta manera de trabajar de IMAP puede dar tiempos
de respuesta más rápidos para usuarios que tienen una gran cantidad de mensajes
o mensajes grandes.
 Respaldo para la conexión de múltiples clientes simultáneos a un mismo
destinatario: El protocolo POP3 supone que el cliente conectado es el único dueño
de una cuenta de correo. En contraste, el protocolo IMAP4 permite accesos
simultáneos a múltiples clientes y proporciona ciertos mecanismos a los clientes
para que se detecten los cambios hechos a un buzón de correo por otro cliente
concurrentemente conectado.
 Respaldo para acceso a partes MIME de los mensajes y obtención parcial: Casi
todo el correo electrónico de Internet es transmitido en formato MIME. El
protocolo IMAP4 les permite a los clientes obtener separadamente cualquier parte
MIME individual, así como obtener porciones de las partes individuales o los
mensajes completos. Es más seguro.
 Respaldo para que la información de estado del mensaje se mantenga en el
servidor: A través de la utilización de señales definidas en el protocolo IMAP4 de
los clientes, se puede vigilar el estado del mensaje, por ejemplo, si el mensaje ha
sido o no leído, respondido o eliminado. Estas señales se almacenan en el servidor,
de manera que varios clientes conectados al mismo correo en diferente tiempo
pueden detectar los cambios hechos por otros clientes.
 Respaldo para accesos múltiples a los buzones de correo en el servidor: Los
clientes de IMAP4 pueden crear, renombrar o eliminar correo (por lo general
presentado como carpetas al usuario) del servidor, y mover mensajes entre
cuentas de correo. El soporte para múltiples buzones de correo también le permite
al servidor proporcionar acceso a los directorios públicos y compartidos.
 Respaldo para búsquedas de parte del servidor: IMAP4 proporciona un
mecanismo para que los clientes pidan al servidor que busque mensajes de
acuerdo a una cierta variedad de criterios. Este mecanismo evita que los clientes
descarguen todos los mensajes de su buzón de correo, agilizando, de esta manera,
las búsquedas.
 Respaldo para un mecanismo de extensión definido: Como reflejo de la
experiencia en versiones anteriores de los protocolos de Internet, IMAP define un
mecanismo explícito mediante el cual puede ser extendido. Se han propuesto
muchas extensiones de IMAP4 y son de uso común. Un ejemplo de extensión es
el IMAP IDLE, que sirve para que el servidor avise al cliente cuando ha llegado un
nuevo mensaje de correo y éstos se sincronicen. Sin esta extensión, para realizar la
misma tarea, el cliente debería contactar periódicamente al servidor para ver si
hay mensajes nuevos.
ESTRUCTURA Y CODIFICACION DE MENSAJES MIME (MULTIPURPOSE INTERNET MAIL
EXTENSIONS)
Multipurpose Internet Mail Extensions o MIME (en español "extensiones
multipropósito de correo de internet") son una serie de convenciones o especificaciones
dirigidas al intercambio a través de Internet de todo tipo de archivos (texto, audio, vídeo,
etc.) de forma transparente para el usuario. Una parte importante del MIME está
dedicada a mejorar las posibilidades de transferencia de texto en distintos idiomas y
alfabetos. En sentido general las extensiones de MIME van encaminadas a soportar:

Texto en conjuntos de caracteres distintos de US-ASCII;

adjuntos que no son de tipo texto;

cuerpos de mensajes con múltiples partes (multi-part);

información de encabezados con conjuntos de caracteres distintos de ASCII.
Prácticamente todos los mensajes de correo electrónico escritos por personas
en Internet y una proporción considerable de estos mensajes generados automáticamente
son transmitidos en formato MIME a través de SMTP. Los mensajes de correo electrónico
en Internet están tan cercanamente asociados con el SMTP y MIME que usualmente se les
llama mensaje SMTP/MIME.
En 1991 la IETF (Grupo de Trabajo en Ingeniería de Internet, Internet Engineering
Task Force en inglés) comenzó a desarrollar esta norma y desde 1994 todas las
extensiones MIME están especificadas de forma detallada en diversos documentos
oficiales disponibles en Internet.
MIME está especificado en seis Request for Comments o RFC (en español "solicitud
de comentarios): RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 y RFC 2077.
Los tipos de contenido definidos por el estándar MIME tienen gran importancia
también fuera del contexto de los mensajes electrónicos. Ejemplo de esto son
algunos protocolos de redtales como HTTP de la Web. HTTP requiere que los datos sean
transmitidos en un contexto de mensajes tipo e-mail aunque los datos pueden no ser un
e-mail propiamente dicho.
En la actualidad ningún programa de correo electrónico o navegador de Internet
puede considerarse completo si no acepta MIME en sus diferentes facetas (texto y
formatos de archivo).
El protocolo básico de transmisión de mensajes electrónicos de Internet soporta
solo caracteres ASCII de 7 bit (véase también 8BITMIME). Esto limita los mensajes de
correo electrónico, ya que incluyen solo caracteres suficientes para escribir en un número
reducido de lenguajes, principalmente Inglés. Otros lenguajes basados en el Alfabeto
latino es adicionalmente un componente fundamental en protocolos de comunicación
como HTTP, el que requiere que los datos sean transmitidos como un e-mail aunque los
datos pueden no ser un e-mail propiamente dicho. Los clientes de correo y los servidores
de correo convierten automáticamente desde ya formato MIME cuando envían o reciben
(SMTP/MIME) e-mails.
CONTENT-TRANSFER-ENCODING
En Junio de 1992, MIME (RFC 1341 queda obsoleta por la nueva RFC 2045) define
un conjunto de métodos para representar datos binarios usando texto ASCII. El
encabezado MIME content-transfer-encoding: indica el método que ha sido usado. La RFC
y la lista de IANA definen los siguientes valores los cuales no son sensibles a mayúsculas y
minúsculas:

Adecuados para usar con SMTP:
 7BIT — soporta hasta 998 octetos por línea de código; los caracteres están
en el rango entre 1 - 127 con CR y LF (códigos 13 y 10 respectivamente) que
sólo pueden aparecer como parte de un fin de línea CRLF. Este es el valor
implícito para este encabezado.
QUOTED PRINTABLE — usado para codificar secuencias arbitrarias de
octetos de forma que satisfaga las reglas de 7bit. Fue diseñado para ser
eficiente y en la mayoría de los casos legible para un humano cuando es
usado con datos de texto que consisten primariamente en caracteres del
conjunto US-ASCII y que también contengan porciones de bytes con valores
que están fuera de ese rango.
 BASE64 — usado para codificar secuencias arbitrarias de octetos de forma
que satisfaga las reglas de 7bit. Tiene una sobrecarga fija al ejecutar el
algoritmo y tiene el propósito de ser usado con datos que no sean de texto
o textos que contengan pocos valores dentro del rango de ASCII.
 Adecuado para usar con servidores SMTP que soporten 8BITMIME extensiones
SMTP:
 8BIT — soporta hasta 998 octetos por línea de código, los caracteres están
en el rango entre 1..256 con CR y LF (códigos 13 y 10 respectivamente) que
sólo pueden aparecer como parte de un fin de línea CRLF.


Adecuados sólo para usar con servidores SMTP que soporten la extensión SMTP
BINARYMIME (RFC 3030):

BINARY — cualquier secuencia de octetos.
No existe una codificación definida explícitamente para enviar datos binarios
arbitrarios a través de un transporte SMTP con las extensiones 8BITMIME. Por tanto
base64 o quoted-printable (con sus ineficiencias asociadas) tienen que ser usadas aún.
Estas restricciones no se aplican a otros usos de MIME como son Servicios Web con
adjuntos MIME o MTOM.