1.

Conceptos Básicos en Internet

Historia de Internet
La historia de Internet se remonta al temprano desarrollo de las redes de comunicación.
La idea de una red de ordenadores diseñada para permitir la comunicación general entre
usuarios de varias computadoras sea tanto desarrollos tecnológicos como la fusión de
la infraestructura de la red ya existente y los sistemas de telecomunicaciones. La primera
descripción documentada acerca de las interacciones sociales que podrían ser propiciadas
a través del networking (trabajo en red) está contenida en una serie de memorandos
escritos por J.C.R. Licklider, del Massachusetts Institute of Technology, en agosto de 1962,
en los cuales Licklider discute sobre su concepto de Galactic Network (Red Galáctica).
Las más antiguas versiones de estas ideas aparecieron a finales de los años cincuenta.
Implementaciones prácticas de estos conceptos empezaron a finales de los ochenta y a lo
largo de los noventa. En la década de 1980, tecnologías que reconoceríamos como las
bases de la moderna Internet, empezaron a expandirse por todo el mundo. En los noventa
se introdujo la World Wide Web (WWW), que se hizo común.
La infraestructura de Internet se esparció por el mundo, para crear la moderna red mundial
de computadoras que hoy conocemos. Atravesó los países occidentales e intentó una
penetración en los países en desarrollo, creando un acceso mundial a información y
comunicación sin precedentes, pero también una brecha digital en el acceso a esta nueva
infraestructura. Internet también alteró la economía del mundo entero, incluyendo las
implicaciones económicas de la burbuja de las .com.
Un pionero fundamental en lo que se refiere a una red mundial, J.C.R. Licklider,
comprendió la necesidad de una red mundial, según consta en su documento de enero,
1960, «Man-Computer Symbiosis» («Simbiosis Hombre-Computadora»).

Una red de muchos [ordenadores], conectados mediante líneas de

comunicación de banda ancha" las cuales proporcionan "las funciones
que existen hoy en día de las bibliotecas junto con anticipados avances
en el guardado y adquisición de información y [otras] funciones
simbióticas.
J.C.R Licklider
En octubre de 1962, Licklider fue nombrado jefe de la oficina de procesado de
información DARPA, y empezó a formar un grupo informal dentro del DARPA del
Departamento de Defensa de los Estados Unidos para investigaciones sobre ordenadores
más avanzadas. Como parte del papel de la oficina de procesado de información, se
instalaron tres terminales de redes:

 una para la System Development Corporation en Santa Mónica,

 otra para el Proyecto Genie en la Universidad de California (Berkeley) y
 otra para el proyecto Multics en el Instituto Tecnológico de Massachusetts.

La necesidad de Licklider de redes se haría evidente por los problemas que esto causó.

Para cada una de estas tres terminales, tenía tres diferentes juegos de
comandos de usuario. Por tanto, si estaba hablando en red con alguien
en la S.D.C. y quería hablar con alguien que conocía en Berkeley o en el
M.I.T. sobre esto, tenía que irme de la terminal de la S.C.D., pasar y
registrarme en la otra terminal para contactar con él.
Dije, es obvio lo que hay que hacer: si tienes esas tres terminales,
debería haber una terminal que fuese a donde sea que quisieras ir y en
donde tengas interactividad. Esa idea es el ARPANet.
Robert W. Taylor, co-escritor, junto con Licklider, de "The Computer as a Communications
Device" (El Ordenador como un Dispositivo de Comunicación), en una entrevista con
el New York Times
Como principal problema en lo que se refiere a las interconexiones está el conectar
diferentes redes físicas para formar una sola red lógica. Durante la década de 1960, varios
grupos trabajaron en el concepto de la conmutación de paquetes. Un paquete es un grupo
de información que consta de dos partes:

 los datos propiamente dichos y

 la información de control,

en la que está especificado la ruta a seguir a lo largo de la red hasta el destino del
paquete. Mil octetos es el límite de longitud superior de los paquetes, y si la longitud es
mayor el mensaje se fragmenta en otros paquetes. Normalmente se considera que Donald
Davies (National Physical Laboratory), Paul Baran (Rand Corporation) y Leonard Kleinrock
(MIT) lo han inventado simultáneamente.

Cronología
Año Evento
La compañía BELL crea el primer módem que permitía transmitir datos binarios
1958
sobre una línea telefónica simple.
Leonard Kleinrock del Massachusetts Institute of Technology publica una primera
1961
teoría sobre la utilización de la conmutación de paquetes para transferir datos.
Inicio de investigaciones por parte de ARPA, una agencia del ministerio
1962 estadounidense de defensa, donde J.C.R. Licklider defiende exitosamente sus
ideas relativas a una red global de computadoras.
Leonard Kleinrock del MIT publica un libro sobre la comunicación por
1964
conmutación de paquetes para implementar una red.
1967 Primera conferencia sobre ARPANET
Conexión de las primeras computadoras entre 4 universidades estadounidenses a
1969
través de la Interface Message Processor de Leonard Kleinrock
23 computadoras son conectadas a ARPANET. Envío del primer correo por Ray
1971
Tomlinson.
Nacimiento del InterNetworking Working Group, organización encargada de
1972
administrar Internet.
1973 Inglaterra y Noruega se adhieren a Internet, cada una con una computadora.
1979 Creación de los NewsGroups (foros de discusión) por estudiantes americanos.
1982 Definición del protocolo TCP/IP y de la palabra «Internet»
1983 Primer servidor de nombres de sitios.
1984 1000 computadoras conectadas.
1987 10000 computadoras conectadas.
1989 100000 computadoras conectadas.
1990 Desaparición de ARPANET
1991 Se anuncia públicamente la World Wide Web
1992 1 millón de computadoras conectadas.
Aparición del navegador web NCSA Mosaic
1993
Primer buscador de la historia, Wandex servía como un índice de páginas web.1
1996 10 millones de computadoras conectadas.
2000 Explosión de la Burbuja.com
2009 Primer sitio web que permitió la interacción táctil.
Inicios de Internet
Los inicios de Internet nos remontan a los años 60. En plena guerra fría, Estados Unidos
crea una red exclusivamente militar, con el objetivo de que, en el hipotético caso de un
ataque ruso, se pudiera tener acceso a la información militar desde cualquier punto del
país. Este red se creó en 1969 y se llamó ARPANET. En principio, la red contaba con 4
ordenadores distribuidos entre distintas universidades del país. Dos años después, ya
contaba con unos 40 ordenadores conectados. Tanto fue el crecimiento de la red que su
sistema de comunicación se quedó obsoleto. Entonces dos investigadores crearon el
Protocolo TCP/IP, que se convirtió en el estándar de comunicaciones dentro de las redes
informáticas (actualmente seguimos utilizando dicho protocolo).
ARPANET siguió creciendo y abriéndose al mundo, y cualquier persona con fines
académicos o de investigación podía tener acceso a la red. Las funciones militares se
desligaron de ARPANET y fueron a parar a MILNET, una nueva red creada por los
Estados Unidos. La NSF (National Science Fundation) crea su propia red informática
llamada NSFNET, que más tarde absorbe a ARPANET, creando así una gran red con
propósitos científicos y académicos. El desarrollo de las redes fue abismal, y se crean
nuevas redes de libre acceso que más tarde se unen a NSFNET, formando el embrión de
lo que hoy conocemos como INTERNET.
En 1985 la Internet ya era una tecnología establecida, aunque conocida por unos pocos. El
autor William Gibson hizo una revelación: el término «ciberespacio». En ese tiempo la red
era básicamente textual, así que el autor se basó en los videojuegos. Con el tiempo la
palabra «ciberespacio» terminó por ser sinónimo de Internet. El desarrollo de NSFNET fue
tal que hacia el año 1990 ya contaba con alrededor de 100 000 servidores.
En el Centro Europeo de Investigaciones Nucleares (CERN), Tim Berners Lee dirigía la
búsqueda de un sistema de almacenamiento y recuperación de datos. Berners Lee retomó
la idea de Ted Nelson (un proyecto llamado «Xanadú») de usar hipervínculos. Robert
Caillau quien cooperó con el proyecto, cuenta que en 1990 deciden ponerle un nombre al
sistema y lo llamaron World Wide Web (WWW) o telaraña mundial.
La nueva fórmula permitía vincular información en forma lógica y a través de las redes. El
contenido se programaba en un lenguaje de hipertexto con «etiquetas» que asignaban una
función a cada parte del contenido. Luego, un programa de computación, un intérprete, era
capaz de leer esas etiquetas para despeglar la información. Ese intérprete sería conocido
como «navegador» o «browser».
En 1993 Marc Andreesen produjo la primera versión del navegador «Mosaic», que permitió
acceder con mayor naturalidad a la WWW. La interfaz gráfica iba más allá de lo previsto y
la facilidad con la que podía manejarse el programa abría la red a los legos. Poco
después, Andreesen encabezó la creación del programa Netscape.
A partir de entonces, Internet comenzó a crecer más rápido que otro medio de
comunicación, convirtiéndose en lo que hoy todos conocemos.
Algunos de los servicios disponibles en Internet aparte de la WEB son el acceso remoto a
otras máquinas (SSH y telnet), transferencia de archivos (FTP), correo electrónico (SMTP),
conversaciones en línea (IMSN MESSENGER, ICQ, YIM, AOL, jabber), transmisión de
archivos (P2P, P2M, descarga directa), etc.
Podemos definir a Internet como una «red de redes», es decir, una red que no sólo
interconecta computadoras, sino que interconecta redes de computadoras entre sí. Una
red de computadoras es un conjunto de máquinas que se comunican a través de algún
medio (cable coaxial, fibra óptica, radiofrecuencia, líneas telefónicas, etc.) con el objeto de
compartir recursos.
De esta manera, Internet sirve de enlace entre redes más pequeñas y permite ampliar su
cobertura al hacerlas parte de una "red global". Esta red global tiene la característica de
que utiliza un lenguaje común que garantiza la intercomunicación de los diferentes
participantes; este lenguaje común o protocolo (un protocolo es el lenguaje que utilizan las
computadoras al compartir recursos) se conoce como TCP/IP.
Así pues, Internet es la «red de redes» que utiliza TCP/IP como su protocolo de
comunicación.
Internet es un acrónimo de INTERconected NETworks (Redes interconectadas). Para
otros, Internet es un acrónimo del inglés INTERnational NET, que traducido al español
sería Red Mundial.
El TCP/IP es la base de Internet que sirve para enlazar computadoras que utilizan
diferentes sistemas operativos, incluyendo PC, minicomputadoras y computadoras
centrales sobre redes de área local y área extensa. TCP/IP fue desarrollado y demostrado
por primera vez en 1972 por el departamento de defensa de los Estados Unidos,
ejecutándolo en ARPANET, una red de área extensa del departamento de defensa.

Uso y cultura

Email y Usenet—El crecimiento de los foros de texto

Se suele considerar el correo electrónico como la aplicación asesina de Internet; aunque
realmente, el e-mail ya existía antes de Internet y fue una herramienta crucial en su
creación. Empezó en 1965 como una aplicación de ordenadores centrales a tiempo
compartido para que múltiples usuarios pudieran comunicarse. Aunque la historia no es
clara, entre los primeros sistemas en tener una facilidad así se encuentran Q32, de SDC's,
y CTSS del MIT.10
La red de computadoras de ARPANET hizo una gran contribución en la evolución del
correo electrónico. Existe un informe que indica transferencias de e-mail entre sistemas
experimentales poco después de su creación. Ray Tomlinson inició el uso del
signo @ para separar los nombres del usuario y su máquina, en 1971.
Se desarrollaron protocolos para transmitir el correo electrónico entre grupos de
ordenadores centrales a tiempo compartido sobre otros sistemas de transmisión,
como UUCP y el sistema de e-mail VNET, de IBM. El correo electrónico podía pasarse así
entre un gran número de redes, incluyendo ARPANET, BITNET y NSFNET, así como a
hosts conectados directamente a otros sitios vía UUCP.
Además, UUCPnet trajo una manera de publicar archivos de texto que se pudieran leer por
varios otros. El software News, desarrollado por Steve Daniels y Tom Truscott en 1979 se
usarían para distribuir noticias mensajes como tablones de anuncios. Esto evolucionó
rápidamente a los grupos de discusión con un gran rango de contenidos. En ARPANET y
NSFNET, concretamente en en la lista de correo de sflovers se crearon grupos de
discusión similares por medio de listas de correo, que discutían asuntos técnicos y otros
temas, como la ciencia ficción.

Una biblioteca mundial—Del Gopher a la WWW

A medida que Internet creció durante los años 1980 y principios de los años 1990, mucha
gente se dio cuenta de la creciente necesidad de poder encontrar y organizar ficheros e
información. Los proyectos como Gopher, WAIS, y la FTP Archive list intentaron crear
maneras de organizar datos distribuidos. Desafortunadamente, estos proyectos se
quedaron cortos en poder alojar todos los tipos de datos existentes y en poder crecer sin
cuellos de botella.
Uno de los paradigmas de interfaz de usuario más prometedores durante este periodo fue
el hipertexto. La tecnología había sido inspirada por el «Memex» de Vannevar Bush y
desarrollado a través de la investigación de Ted Nelson en el Proyecto Xanadu y la
investigación de Douglas Engelbart en el NLS. Muchos pequeños sistemas de hipertexto
propios se habían creado anteriormente, como el HyperCard de Apple Computer.

Berners-Lee usó esta NeXTcube en el CERN, y fue el primer servidor web del mundo.
En 1991, Tim Berners-Lee fue el primero en desarrollar un implementación basada en red
de concepto de hipertexto. Esto fue después de que Berners-Lee hubiera propuesto
repetidamente su idea a las comunidades de hipertexto e Internet en varias conferencias
sin acogerse—nadie lo implementaría por él. Trabajando en el CERN, Berners-Lee quería
una manera de compartir información sobre su investigación. Liberando su implementación
para el uso público, se aseguró que la tecnología se extendería. Posteriormente, Gopher
se convirtió en la primera interfaz de hipertexto comúnmente utilizada en Internet. Aunque
las opciones del menú Gopher eran ejemplos de hipertexto, éstas no fueron comúnmente
percibidas de esta manera. Unos de los primeros populares navegadores web, modelado
después de HyperCard, fue ViolaWWW.
Los expertos generalmente están de acuerdo, sin embargo, que el punto decisivo para la
World Wide Web comenzó con la introducción de Mosaic en 1993, un navegador web con
interfaz gráfica desarrollado por un equipo en el National Center for Supercomputing
Applications en la Universidad de Illinois en Urbana-Champaign (NCSA-UIUC), liderado
por Marc Andreessen. Los fondos para Mosaic vinieron desde la High-Performance
Computing and Communications Initiative, el programa de ayudas High Performance
Computing and Communication Act of 1991iniciado por el entonces senador Al Gore. De
hecho, la interfaz gráfica de Mosaic pronto se hizo más popular que Gopher, que en ese
momento estaba principalmente basado en texto, y la WWW se convirtió en la interfaz
preferida para acceder a Internet.
Mosaic fue finalmente suplantado en 1994 por Netscape Navigator de Andreessen, que
reemplazó a Mosaic como el navegador web más popular en el mundo. La competencia de
Internet Explorer y una variedad de otros navegadores casi lo ha sustituido
completamente. Otro acontecimiento importante celebrado el 11 de enero de 1994,
fue The Superhighway Summit en la Sala Royce de la UCLA. Esta fue la «primera
conferencia pública que agrupó a todos los principales líderes de la industria, el gobierno y
académicos en el campo [y] también comenzó el diálogo nacional sobre la Autopista de la
información y sus implicaciones.»

Encontrando lo que necesitas—El buscador

Incluso antes de la World Wide Web, hubo buscadores que intentaron organizar Internet.
El primero de estos fue Archie de la Universidad McGill en 1990, seguido en 1991 por
WAIS y Gopher. Los tres sistemas fueron anteriores a la invención de la World Wide Web
pero todos continuaron indexando la Web y el resto de Internet durante varios años
después de que apareciera la Web. A 2006, aún hay servidores Gopher, aunque hay
muchos más servidores web.
A medida que la Web creció, se crearon los buscadores y los directorios web para localizar
las páginas en la Web y permitir a las personas encontrar cosas. El primer buscador web
completamente de texto fue WebCrawler en 1994. Antes de WebCrawler, sólo se podían
buscar títulos de páginas web. Otro de los primeros buscadores, Lycos, fue creado en
1993 como un proyecto universitario, y fue el primero en conseguir éxito comercial.
Durantes los últimos años de 1990, tanto los directorios web como los buscadores web
eran populares—Yahoo! (fundado en 1995) y AltaVista (fundado en 1995) fueron los
respectivos líderes de la industria.
Por agosto de 2001, el modelo de directorios había comenzado a ceder ante el de
buscadores, mostrando el surgimiento de Google (fundado en 1998), que había
desarrollado nuevos enfoques para el ordenamiento por relevancia. El modelo de
directorios, aunque aún está disponible comúnmente, es menos utilizado que los
buscadores.
El tamaño de las bases de datos, que había sido sido una característica
de marketing significativa durante los primeros años de la década de 2000, fue igualmente
sustituido por el énfasis en el ordenamiento por relevancia, los métodos con los cuales los
buscadores intentan colocar los mejores resultados primero. El ordenamiento por
relevancia se convirtió por primera vez en una cuestión importante alrededor de 1996,
cuando se hizo evidente que no era práctico revisar listas completas de resultados. Por
consiguiente, los algoritmos para el ordenamiento por relevancia se han ido mejorando
continuamente. El método PageRank de Google para ordenar los resultados ha recibido la
mayoría de la prensa, pero todos los principales buscadores refinan continuamente sus
metodologías de ordenamiento con el objetivo de mejorar el orden de los resultados. En
2006, la posición en los buscadores es más importante que nunca, tanto que la industria
ha desarrollado («posicionadores en buscadores») para ayudar a los desarrolladores web
a mejorar su posición en el buscador, y se ha desarrollado un cuerpo entero de
jurisprudencia alrededor de cuestiones que afectan al posicionamiento en los buscadores,
como el uso de marcas registradas en metatags. La venta de posiciones en buscadores
por algunos buscadores ha creado también controversia entre bibliotecarios y defensores
de los consumidores.

La burbuja .com
El repentino bajo precio para llegar a millones de personas en el mundo, y la posibilidad de
vender y saber de la gente a que se vendía en el mismo momento, prometió cambiar el
dogma de negocio establecido en la publicidad, las ventas por correo, CRM, y muchas
más áreas. La web fue una nueva aplicación rompedora—podía juntar compradores y
vendedores sin relación previa de manera fluida y con bajo coste. Los visionarios alrededor
del mundo desarrollaron nuevos modelos de negocio, y se dirigieron a su capitalista de
riesgo más cercano. Por supuesto una proporción de los nuevos empresarios tenían
realmente talento en la administración de empresas y las ventas y crecieron; pero la
mayoría eran simplemente gente con ideas, y no gestionaron el influjo de capital
prudentemente. Además, muchos planes de negocios .com estaban fundamentados sobre
el supuesto que usando Internet, evitarían los canales de distribución de los negocios
existentes y por tanto no tendrían que competir con ellos; cuando los negocios
establecidos con fuertes marcas desarrollaron su propia presencia en Internet, estas
esperanzas fueron destrozadas, y los recién llegados quedaron abandonados en su
negocio intentando romper los mercados dominados por negocios más grandes y
establecidos. Muchos no tuvieron la capacidad de hacerlo.
La burbuja .com estalló el 10 de marzo de 2000, cuando el índice NASDAQ compuesto
fuertemente por valores tecnológicos hizo su máximo en 5048,62 (máximo intradía
5132,52), más del doble de su valor un año anterior. Para 2001, la deflación de la burbuja
estaba yendo a toda velocidad. La mayoría de las .com había cerrado el negocio, después
de haber quemado todo su capital riesgo, a menudo sin ni siquiera tener un beneficio
bruto.

El futuro
Existe actualmente un debate en torno a si Internet continuará manteniendo las
características que ha presentado hasta hoy (en particular su carácter global y abierto).
Algunos autores subrayan que desde principios de la década de 2010 los fenómenos
ligados a Internet han comenzado a localizarse fuertemente, lo que puede devenir en una
pluralidad de redes que poco a poco desplazaría a la red madre unitaria. La historia del
Internet ha sido un proceso rico que se caracteriza por su carácter innovador, considerado
como un instrumento de enorme importancia para los ciudadanos y el propio gobierno, el
Internet ha pasado de un instrumento primeramente utilizado en el ámbito de las
universidades para el mundo y ha contribuido significativamente para el desarrollo de
todas las otras áreas de las Ciencias.
Tecnología de Internet

Enrutamiento y capas de servicio

Gráfica del encapsulamiento en paquetes de datos.

Paquetes de Internet de varios provedores.

Los Proveedores de Servicios de Internet (ISP) conectan a clientes, quienes representan la
parte más baja en la jerarquía de enrutamiento, con otros clientes de otros ISP a través de
capas de red más altas o del mismo nivel. En lo alto de la jerarquía de enrutamiento están
las redes de capa 1, grandes compañías de telecomunicaciones que intercambian tráfico
directamente con otras a través de acuerdos de interconexión. Redes de capa 2 y de más
bajo nivel compran tráfico de Internet de otros proveedores para alcanzar al menos
algunas partes del Internet mundial, aunque también pueden participar en la interconexión.
Un ISP puede usar un único proveedor para la conectividad o
implementar multihomingpara conseguir redundancia y balanceo de carga. Los puntos
neutros tienen las cargas más importantes de tráfico y tienen conexiones físicas a
múltiples ISP.
Los ordenadores y routers utilizan las tablas de enrutamiento para dirigir los paquetes IP
entre las máquinas conectadas localmente. Las tablas pueden ser construidas de forma
manual o automáticamente a través de DHCP para un equipo individual o un protocolo de
enrutamiento para los routers de sí mismos. En un solo homed situaciones, una ruta por
defecto por lo general apunta hacia "arriba" hacia un ISP proporciona el transporte. De
más alto nivel de los ISP utilizan el Border Gateway Protocol para solucionar rutas de
acceso a un determinado rango de direcciones IP a través de las complejas conexiones de
la Internet global.
Las instituciones académicas, las grandes empresas, gobiernos y otras organizaciones
pueden realizar el mismo papel que los ISP, con la participación en el intercambio de
tráfico y tránsito de la compra en nombre de sus redes internas de las computadoras
individuales. Las redes de investigación tienden a interconectarse en subredes grandes
como GEANT, GLORIAD, Internet2, y de investigación nacional del Reino Unido y la red
de la educación, Janet. Estos a su vez se construyen alrededor de las redes más
pequeñas (véase la lista de organizaciones académicas de redes informáticas).

No todas las redes de ordenadores están conectados a Internet. Por ejemplo, algunos
clasificados los sitios web de los Estados sólo son accesibles desde redes seguras
independientes.

(IP)Internet Protocol
Internet Protocol (en español 'Protocolo de Internet') o IP es un protocolo de
comunicación de datos digitales clasificado funcionalmente en la Capa de Red según el
modelo internacional OSI.
Su función principal es el uso bidireccional en origen o destino de comunicación para
transmitir datos mediante un protocolo no orientado a conexión que transfiere paquetes
conmutados a través de distintas redes físicas previamente enlazadas según la norma OSI
de enlace de datos.

Descripción funcional
El diseño del protocolo IP se realizó presuponiendo que la entrega de los paquetes de
datos sería no confiable. Por ello, IP tratará de realizarla del mejor modo posible, mediante
técnicas de encaminamiento, sin garantías de alcanzar el destino final pero tratando de
buscar la mejor ruta entre las conocidas por la máquina que esté usando IP.
Los datos en una red basada en IP son enviados en bloques conocidos como paquetes o
datagramas (en el protocolo IP estos términos se suelen usar indistintamente). En
particular, en IP no se necesita ninguna configuración antes de que un equipo intente
enviar paquetes a otro con el que no se había comunicado antes.
IP provee un servicio de datagramas no fiable (también llamado del "mejor esfuerzo": lo
hará lo mejor posible, pero garantizando poco). IP no provee ningún mecanismo para
determinar si un paquete alcanza o no su destino y únicamente proporciona seguridad
(mediante checksums o sumas de comprobación) de sus cabeceras y no de los datos
transmitidos. Por ejemplo, al no garantizar nada sobre la recepción del paquete, éste
podría llegar dañado, en otro orden con respecto a otros paquetes, duplicado o
simplemente no llegar. Si se necesita fiabilidad, ésta es proporcionada por los protocolos
de la capa de transporte, como TCP. Las cabeceras IP contienen las direcciones de las
máquinas de origen y destino (direcciones IP), direcciones que serán usadas por los
enrutadores (routers) para decidir el tramo de red por el que reenviarán los paquetes. El IP
es el elemento común en el Internet de hoy. El actual y más popular protocolo de red es
IPv4. IPv6 es el sucesor propuesto de IPv4; poco a poco Internet está agotando las
direcciones disponibles por lo que IPv6 utiliza direcciones de fuente y destino de 128 bits,
muchas más direcciones que las que provee IPv4 con 32 bits. Las versiones de la 0 a la 3
están reservadas o no fueron usadas. La versión 5 fue usada para un protocolo
experimental. Otros números han sido asignados, usualmente para protocolos
experimentales, pero no han sido muy extendidos.
Si la información a transmitir ("datagramas") supera el tamaño máximo "negociado" (MTU)
en el tramo de red por el que va a circular podrá ser dividida en paquetes más pequeños, y
reensamblada luego cuando sea necesario. Estos fragmentos podrán ir cada uno por un
camino diferente dependiendo de como estén de congestionadas las rutas en cada
momento.
Las cabeceras IP contienen las direcciones de las máquinas de origen y destino
(direcciones IP), direcciones que serán usadas por los enrutadores (routers) para decidir el
tramo de red por el que reenviarán los paquetes.1

Direccionamiento IP y enrutamiento
Quizás los aspectos más complejos de IP son el direccionamiento y el enrutamiento. El
direccionamiento se refiere a la forma como se asigna una dirección IP y cómo se dividen
y se agrupan subredes de equipos.
El enrutamiento consiste en encontrar un camino que conecte una red con otra y, aunque
es llevado a cabo por todos los equipos, es realizado principalmente por routers, que no
son más que computadoras especializadas en recibir y enviar paquetes por diferentes
interfaces de red, así como proporcionar opciones de seguridad, redundancia de caminos
y eficiencia en la utilización de los recursos.

Dirección IP
Una dirección IP es un número que identifica de manera lógica y jerárquicamente a
una interfaz de un dispositivo (habitualmente una computadora) dentro de una red que
utilice el protocolo de Internet (Internet Protocol), que corresponde al nivel de red o nivel 3
del modelo de referencia OSI. Dicho número no se ha de confundir con la dirección
MAC que es un número físico que es asignado a la tarjeta o dispositivo de red (viene
impuesta por el fabricante), mientras que la dirección IP se puede cambiar.
El usuario al conectarse desde su hogar a Internet utiliza una dirección IP. Esta dirección
puede cambiar al reconectar. A la posibilidad de cambio de dirección de la IP se
denomina dirección IP dinámica. Existe un protocolo para asignar direcciones IP dinámicas
llamado DHCP (Dynamic Host Configuration Protocol).
Los sitios de Internet que por su naturaleza necesitan estar permanentemente conectados,
generalmente tienen una dirección IP fija (IP fija o IP estática); es decir, no cambia con el
tiempo. Los servidores de correo, dns, ftp públicos, servidores web, conviene que tengan
una dirección IP fija o estática, ya que de esta forma se facilita su ubicación.
Las máquinas manipulan y jerarquizan la información de forma numérica, y son altamente
eficientes para hacerlo y ubicar direcciones IP. Sin embargo, los seres humanos debemos
utilizar otra notación más fácil de recordar y utilizar, por ello las direcciones IP pueden
utilizar un sinónimo, llamado nombre de dominio (Domain Name), para convertir los
nombres de dominio en direcciones IP, se utiliza la resolución de nombres de
dominio DNS.

Enrutamiento
En comunicaciones, el encaminamiento (a veces conocido por el
anglicismo ruteo o enrutamiento) es el mecanismo por el que en una red los paquetes de
información se hacen llegar desde su origen a su destino final, siguiendo un camino o ruta
a través de la red. En una red grande o en un conjunto de redes interconectadas el camino
a seguir hasta llegar al destino final puede suponer transitar por muchos nodos
intermedios.
Asociado al encaminamiento existe el concepto de métrica, que es una medida de lo
"bueno" que es usar un camino determinado. La métrica puede estar asociada a distintas
magnitudes: distancia, coste, retardo de transmisión, número de saltos, etc., o incluso a
una combinación de varias magnitudes. Si la métrica es el retardo, es mejor un camino
cuyo retardo total sea menor que el de otro. Lo ideal en una red es conseguir el
encaminamiento óptimo: tener caminos de distancia (o coste, o retardo, o la magnitud que
sea, según la métrica) mínimos. Típicamente el encaminamiento es una función
implantada en la capa 3 (capa de red) del modelo de referencia OSI.

(TCP)Transmission Control Protocol

Transmission Control Protocol (TCP) o Protocolo de Control de Transmisión, es uno
de los protocolos fundamentales en Internet. Fue creado entre los años 1973 y 1974
por Vint Cerf y Robert Kahn.
Muchos programas dentro de una red de datos compuesta por redes de computadoras,
pueden usar TCP para crear “conexiones” entre sí a través de las cuales puede enviarse
un flujo de datos. El protocolo garantiza que los datos serán entregados en su destino sin
errores y en el mismo orden en que se transmitieron. También proporciona un mecanismo
para distinguir distintas aplicaciones dentro de una misma máquina, a través del concepto
de puerto.
TCP da soporte a muchas de las aplicaciones más populares de Internet (navegadores,
intercambio de ficheros, clientes FTP, etc.) y protocolos de aplicación HTTP, SMTP, SSH y
FTP.

Objetivos de TCP
Con el uso de protocolo TCP, las aplicaciones pueden comunicarse en forma segura
(gracias al de acuse de recibo -ACK- del protocolo TCP) independientemente de las capas
inferiores. Esto significa que los routers (que funcionan en la capa de Internet) sólo tiene
que enviar los datos en forma de datagrama, sin preocuparse con el monitoreo de datos
porque esta función la cumple la capa de transporte (o más específicamente el protocolo
TCP).

Información técnica
TCP es usado en gran parte de las comunicaciones de datos. Por ejemplo, gran parte de
las comunicaciones que tienen lugar en Internet emplean TCP.

Funciones de TCP
En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de
internet (IP) y la aplicación. Muchas veces las aplicaciones necesitan que la comunicación
a través de la red sea confiable. Para ello se implementa el protocolo TCP que asegura
que los datos que emite el cliente sean recibidos por el servidor sin errores y en el mismo
orden que fueron emitidos, a pesar de trabajar con los servicios de la capa IP, la cual no es
confiable. Es un protocolo orientado a la conexión, ya que el cliente y el servidor deben de
anunciarse y aceptar la conexión antes de comenzar a transmitir los datos a ese usuario
que debe recibirlos.

Características del TCP

 Permite colocar los datagramas nuevamente en orden cuando vienen del protocolo IP.
 Permite el monitoreo del flujo de los datos y así evita la saturación de la red.
 Permite que los datos se formen en segmentos de longitud variada para "entregarlos"
al protocolo IP.
 Permite multiplexar los datos, es decir, que la información que viene de diferentes
fuentes (por ejemplo, aplicaciones) en la misma línea pueda circular simultáneamente.
 Por último, permite comenzar y finalizar la comunicación amablemente.

Formato de los segmentos TCP

En el nivel de transporte, los paquetes de bits que constituyen las unidades de datos de
protocolo TCP se llaman "segmentos". El formato de los segmentos TCP se muestra en el
esquema segmento TCP.

Funcionamiento del protocolo en detalle

Las conexiones TCP se componen de tres etapas:

1. establecimiento de conexión,
2. transferencia de datos, y
3. fin de la conexión.

Para establecer la conexión se usa el procedimiento llamado “negociación en tres pasos”

(3-way handshake). Para la desconexión se usa una “negociación en cuatro pasos” (4-way
handshake). Durante el establecimiento de la conexión, se configuran algunos parámetros
tales como el número de secuencia con el fin de asegurar la entrega ordenada de los
datos y la robustez de la comunicación.

Establecimiento de la conexión (negociación en tres

pasos)
 Negociación en tres pasos o Three-way handshake

Aunque es posible que un par de entidades finales comiencen una conexión entre ellas
simultáneamente, normalmente una de ellas abre un socket en un determinado puerto
TCP y se queda a la escucha de nuevas conexiones. Es común referirse a esto como
apertura pasiva, y determina el lado servidor de una conexión. El lado cliente de una
conexión realiza una apertura activa de un puerto enviando un paquete SYN inicial al
servidor como parte de la negociación en tres pasos. En el lado del servidor (este receptor
también puede ser una PC o alguna estación terminal) se comprueba si el puerto está
abierto, es decir, si existe algún proceso escuchando en ese puerto, pues se debe verificar
que el dispositivo de destino tenga este servicio activo y esté aceptando peticiones en el
número de puerto que el cliente intenta usar para la sesión. En caso de no estarlo, se
envía al cliente un paquete de respuesta con el bit RST activado, lo que significa el
rechazo del intento de conexión. En caso de que sí se encuentre abierto el puerto, el lado
servidor respondería a la petición SYN válida con un paquete SYN/ACK. Finalmente, el
cliente debería responderle al servidor con un ACK, completando así la negociación en
tres pasos (SYN, SYN/ACK y ACK) y la fase de establecimiento de conexión. Es
interesante notar que existe un número de secuencia generado por cada lado, ayudando
de este modo a que no se puedan establecer conexiones falseadas (spoofing).

Transferencia de datos
Durante la etapa de transferencia de datos, una serie de mecanismos claves determinan la
fiabilidad y robustez del protocolo. Entre ellos están incluidos el uso del número de
secuencia para ordenar los segmentos TCP recibidos y detectar paquetes
duplicados, checksums para detectar errores, y asentimientos y temporizadores para
detectar pérdidas y retrasos.
Durante el establecimiento de conexión TCP, los “números iniciales de secuencia” son
intercambiados entre las dos entidades TCP. Estos números de secuencia son usados
para identificar los datos dentro del flujo de bytes, y poder identificar (y contar) los bytes de
los datos de la aplicación. Siempre hay un par de números de secuencia incluidos en todo
segmento TCP, referidos al número de secuencia y al número de asentimiento. Un
emisor TCP se refiere a su propio número de secuencia cuando habla de número de
secuencia, mientras que con el número de asentimiento se refiere al número de secuencia
del receptor. Para mantener la fiabilidad, un receptor asiente los segmentos TCP indicando
que ha recibido una parte del flujo continuo de bytes. Una mejora de TCP, llamada
asentimiento selectivo (Selective Acknowledgement, SACK) permite a un receptor TCP
asentir los datos que se han recibido de tal forma que el remitente solo retransmita los
segmentos de datos que faltan.
A través del uso de números de secuencia y asentimiento, TCP puede pasar los
segmentos recibidos en el orden correcto dentro del flujo de bytes a la aplicación
receptora. Los números de secuencia son de 32 bits (sin signo), que vuelve a cero tras el
siguiente byte después del 232-1. Una de las claves para mantener la robustez y la
seguridad de las conexiones TCP es la selección del número inicial de secuencia (Initial
Sequence Number, ISN).
Un checksum de 16 bits, consistente en el complemento a uno de la suma en
complemento a uno del contenido de la cabecera y datos del segmento TCP, es calculado
por el emisor, e incluido en la transmisión del segmento. Se usa la suma en complemento
a uno porque el acarreo final de ese método puede ser calculado en cualquier múltiplo de
su tamaño (16-bit, 32-bit, 64-bit...) y el resultado, una vez plegado, será el mismo. El
receptor TCP recalcula el checksum sobre las cabeceras y datos recibidos. El
complemento es usado para que el receptor no tenga que poner a cero el campo
del checksum de la cabecera antes de hacer los cálculos, salvando en algún lugar el valor
del checksum recibido; en vez de eso, el receptor simplemente calcula la suma en
complemento a uno con el checksum incluido, y el resultado debe ser igual a 0. Si es así,
se asume que el segmento ha llegado intacto y sin errores.
Hay que fijarse en que el checksum de TCP también cubre los 96 bit de la cabecera que
contiene la dirección origen, la dirección destino, el protocolo y el tamaño TCP. Esto
proporciona protección contra paquetes mal dirigidos por errores en las direcciones.
El checksum de TCP es una comprobación bastante débil. En niveles de enlace con una
alta probabilidad de error de bit quizá requiera una capacidad adicional de
corrección/detección de errores de enlace. Si TCP fuese rediseñado hoy, muy
probablemente tendría un código de redundancia cíclica (CRC) para control de errores en
vez del actual checksum. La debilidad del checksum está parcialmente compensada por el
extendido uso de un CRC en el nivel de enlace, bajo TCP e IP, como el usado en el PPP o
en Ethernet. Sin embargo, esto no significa que el checksum de 16 bits es redundante:
sorprendentemente, inspecciones sobre el tráfico de Internet han mostrado que son
comunes los errores de software y hardware que introducen errores en los paquetes
protegidos con un CRC, y que el checksum de 16 bits de TCP detecta la mayoría de estos
errores simples.
Los asentimientos (ACK o Acknowledgments) de los datos enviados o la falta de ellos, son
usados por los emisores para interpretar las condiciones de la red entre el emisor y
receptor TCP. Unido a los temporizadores, los emisores y receptores TCP pueden alterar
el comportamiento del movimiento de datos. TCP usa una serie de mecanismos para
conseguir un alto rendimiento y evitar la congestión de la red (la idea es enviar tan rápido
como el receptor pueda recibir). Estos mecanismos incluyen el uso de ventana deslizante,
que controla que el transmisor mande información dentro de los límites del búfer del
receptor, y algoritmos de control de flujo, tales como el algoritmo de evitación de la
congestión (congestion avoidance), el de comienzo lento (slow-start), el de retransmisión
rápida, el de recuperación rápida (fast recovery), y otros.

Control de flujo
TCP usa control de flujo para evitar que un emisor envíe datos de forma más rápida de la
que el receptor puede recibirlos y procesarlos. El control de flujo es un mecanismo
esencial en redes en las que se comunican computadoras con distintas velocidades de
transferencia. Por ejemplo, si una PC envía datos a un dispositivo móvil que procesa los
datos de forma lenta, el dispositivo móvil debe regular el flujo de datos.
TCP usa una ventana deslizante para el control de flujo. En cada segmento TCP, el
receptor especifica en el campo receive window la cantidad de bytes que puede almacenar
en el búfer para esa conexión. El emisor puede enviar datos hasta esa cantidad. Para
poder enviar más datos debe esperar que el receptor le envíe un ACK con un nuevo valor
de ventana.

Tamaño de ventana TCP

El tamaño de la ventana de recepción TCP es la cantidad de datos recibidos (en bytes)
que pueden ser metidos en el búfer de recepción durante la conexión. La entidad emisora
puede enviar una cantidad determinada de datos pero antes debe esperar un asentimiento
con la actualización del tamaño de ventana por parte del receptor.
Un ejemplo sería el siguiente: un receptor comienza con un tamaño de ventana X y
recibe Y bytes, entonces su tamaño de ventana será (X - Y) y el transmisor sólo podrá
mandar paquetes con un tamaño máximo de datos de (X - Y) bytes. Los siguientes
paquetes recibidos seguirán restando tamaño a la ventana de recepción. Esta situación
seguirá así hasta que la aplicación receptora recoja los datos del búfer de recepción.
Escalado de ventana
Para una mayor eficiencia en redes de gran ancho de banda, debe ser usado un tamaño
de ventana mayor. El campo TCP de tamaño de ventana controla el movimiento de datos y
está limitado a 16 bits, es decir, a un tamaño de ventana de 65.535 bytes.
Como el campo de ventana no puede expandirse se usa un factor de escalado. La escala
de ventana TCP (TCP window scale) es una opción usada para incrementar el máximo
tamaño de ventana desde 65.535 bytes, a 1 Gigabyte.
La opción de escala de ventana TCP es usada solo durante la negociación en tres pasos
que constituye el comienzo de la conexión. El valor de la escala representa el número de
bits desplazados a la izquierda de los 16 bits que forman el campo del tamaño de ventana.
El valor de la escala puede ir desde 0 (sin desplazamiento) hasta 14. Hay que recordar
que un número binario desplazado un bit a la izquierda es como multiplicarlo en base
decimal por 2.

Fin de la conexión

Cierre de una conexión según el estándar.

La fase de finalización de la conexión utiliza una negociación en cuatro pasos (four-way
handshake), terminando la conexión desde cada lado independientemente. Sin embargo,
es posible realizar la finalización de la conexión en 3 fases; enviando el segmento FIN y el
ACK en uno solo.2Cuando uno de los dos extremos de la conexión desea parar su "mitad"
de conexión transmite un segmento con el flag FIN en 1, que el otro interlocutor asentirá
con un ACK. Por tanto, una desconexión típica requiere un par de segmentos FIN y ACK
desde cada lado de la conexión.
Una conexión puede estar "medio abierta" en el caso de que uno de los lados la finalice
pero el otro no. El lado que ha dado por finalizada la conexión no puede enviar más datos
pero la otra parte si podrá.

Puertos TCP
TCP usa el concepto de número de puerto para identificar a las aplicaciones emisoras y
receptoras. Cada lado de la conexión TCP tiene asociado un número de puerto (de 16 bits
sin signo, con lo que existen 65536 puertos posibles) asignado por la aplicación emisora o
receptora. Los puertos son clasificados en tres categorías:
 1. bien conocidos,
2. registrados, y
3. dinámicos/privados.

Los puertos bien conocidos son asignados por la Internet Assigned Numbers
Authority (IANA), van del 0 al 1023 y son usados normalmente por el sistema o por
procesos con privilegios.3 Las aplicaciones que usan este tipo de puertos son ejecutadas
como servidores y se quedan a la escucha de conexiones. Algunos ejemplos son: FTP
(21), SSH (22), Telnet (23), SMTP (25) y HTTP (80).
Los puertos registrados son normalmente empleados por las aplicaciones de usuario de
forma temporal cuando conectan con los servidores, pero también pueden representar
servicios que hayan sido registrados por un tercero (rango de puertos registrados: 1024 al
49151).
Los puertos dinámicos/privados también pueden ser usados por las aplicaciones de
usuario, pero este caso es menos común. Los puertos dinámicos/privados no tienen
significado fuera de la conexión TCP en la que fueron usados (rango de puertos
dinámicos/privados: 49152 al 65535, recordemos que el rango total de 2 elevado a la
potencia 16, cubre 65536 números, del 0 al 65535).

Comparativa entre UDP y TCP

 UDP: proporciona un nivel de transporte no fiable de datagramas, ya que apenas
añade la información necesaria para la comunicación extremo a extremo al paquete
que envía al nivel inferior. Lo utilizan aplicaciones como NFS (Network File System) y
RCP (comando para copiar ficheros entre computadores remotos), pero sobre todo se
emplea en tareas de control y en la transmisión de audio y vídeo a través de una red.
No introduce retardos para establecer una conexión, no mantiene estado de conexión
alguno y no realiza seguimiento de estos parámetros. Así, un servidor dedicado a una
aplicación particular puede soportar más clientes activos cuando la aplicación corre
sobre UDP en lugar de sobre TCP.
 TCP: es el protocolo que proporciona un transporte fiable de flujo de bits entre
aplicaciones. Está pensado para poder enviar grandes cantidades de información de
forma fiable, liberando al programador de la dificultad de gestionar la fiabilidad de la
conexión (retransmisiones, pérdida de paquetes, orden en el que llegan los paquetes,
duplicados de paquetes...) que gestiona el propio protocolo. Pero la complejidad de la
gestión de la fiabilidad tiene un coste en eficiencia, ya que para llevar a cabo las
gestiones anteriores se tiene que añadir bastante información a los paquetes que
enviar. Debido a que los paquetes para enviar tienen un tamaño máximo, cuanta más
información añada el protocolo para su gestión, menos información que proviene de la
aplicación podrá contener ese paquete (el segmento TCP tiene una sobrecarga de 20
bytes en cada segmento, mientras que UDP solo añade 8 bytes). Por eso, cuando es
más importante la velocidad que la fiabilidad, se utiliza UDP. En cambio, “TCP asegura
la recepción en destino de la información para transmitir”.

Localizador de recursos uniforme

Un localizador de recursos uniforme o URL —siglas en inglés de uniform resource
locator— es un identificador de recursos uniforme (URI) cuyos recursos referidos pueden
cambiar, esto es, la dirección puede apuntar a recursos variables en el tiempo.1 Están
formados por una secuencia de caracteres, de acuerdo a un formato modélico y estándar,
que designa recursos en una red, como Internet.
Los localizadores uniformes de recursos fueron una innovación en la historia de la Internet.
Fueron usadas por primera vez por Tim Berners-Lee en 1991, para permitir a los autores
de documentos establecer hiperenlaces en la World Wide Web. Desde 1994, en los
estándares de la Internet, el concepto de URL ha sido incorporado dentro del más general
de URI (Uniform Resource Identifier, en español identificador uniforme de recurso), pero el
término URL aún se utiliza ampliamente.
Aunque nunca fueron mencionadas como tal en ningún estándar, mucha gente cree que
las iniciales URL significan universal -en lugar de 'uniform'- resource locator (localizador
universal de recursos). Esta se debe a que en 1990 era así, pero al unirse las normas
"Functional Recommendations for Internet Resource Locators" [RFC1736] y "Functional
Requirements for Uniform Resource Names" [RFC1737] pasó a denominarse Identificador
Uniforme de Recursos [RFC 2396]. Sin embargo, la U en URL siempre ha significado
"uniforme".
El URL es una cadena de caracteres con la cual se asigna una dirección única a cada uno
de los recursos de información disponibles en la Internet. Existe un URL único para cada
página de cada uno de los documentos de la World Wide Web, para todos los elementos
de Gopher y todos los grupos de debate USENET, y así sucesivamente.
El URL de un recurso de información es su dirección en Internet, la cual permite que el
navegador la encuentre y la muestre de forma adecuada. Por ello el URL combina el
nombre del ordenador que proporciona la información, el directorio donde se encuentra, el
nombre del archivo, y el protocolo a usar para recuperar los datos para que no se pierda
alguna información sobre dicho factor que se emplea para el trabajo.

Formato General
El formato general de un URL es:

scheme://[user:password@]domain:port
También pueden añadirse otros datos:

scheme://[user:password@]domain:port/path?query_string#fragment_id
La especificación detallada se encuentra en la RFC 1738, titulada Uniform Resource
Locators.

Esquema URL
Un URL se clasifica por su esquema, que generalmente indica el protocolo de red que
se usa para recuperar, a través de la red, la información del recurso identificado. Un
URL comienza con el nombre de su esquema, seguido por dos puntos, seguido por
una parte específica del esquema'.
Algunos ejemplos de esquemas URL:

 http - recursos HTTP

 https - HTTP sobre SSL
 ftp - File Transfer Protocol
 mailto - direcciones de correo electrónico
 ldap - búsquedas LDAP Lightweight Directory Access Protocol
 file - recusos disponibles en el sistema local, o en una red local
 news - grupos de noticias Usenet (newsgroup)
 gopher - el protocolo Gopher (ya en desuso)
 telnet - el protocolo telnet
 data - el esquema para insertar pequeños trozos de contenido en los
documentos Data: URL

Algunos de los esquemas URL, como los populares "mailto", "http", "ftp", y "file", junto a
los de sintaxis general URL, se detallaron por primera vez en 1994, en el Request for
Comments RFC 1630, sustituido un año después por los más específicos RFC
1738 y RFC 1808.
Algunos de los esquemas definidos en el primer RFC aún son válidos, mientras que
otros son debatidos o han sido refinados por estándares posteriores. Mientras tanto, la
definición de la sintaxis general de los URL se ha escindido en dos líneas separadas de
especificación de URI: RFC 2396 (1998) y RFC 2732 (1999), ambos ya obsoletos pero
todavía ampliamente referidos en las definiciones de esquemas URL.
El estándar actual es STD 66 / RFC 3986 (2005).

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 red tales 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).
Introducción
El protocolo básico de transmisión de mensajes electrónicos de Internet soporta sólo
caracteres ASCII de 7 bit (véase también 8BITMIME). Esto limita los mensajes de
correo electrónico, ya que incluyen sólo 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 y a formato MIME
cuando envían o reciben (SMTP/MIME) e-mails.

MIME headers
MIME-Version
La presencia de este encabezado indica que el mensaje utiliza el formato MIME. Su
valor es típicamente igual a "1.0" por lo que este encabezado aparece como:

MIME-Version: 1.0
Debe señalarse que los implementadores han intentado cambiar el número de versión
en el pasado y el cambio ha tenido resultados imprevistos. En una reunión
de IETF realizada en Julio 2007 se decidió mantener el número de versión en "1.0"
aunque se han realizado muchas actualizaciones a la versión de MIME.

Content-Type
Este encabezado indica el tipo de medio que representa el contenido del mensaje,
consiste en un tipo: type y un subtipo: subtype, por ejemplo:

Content-Type: text/plain
A través del uso del tipo multiparte (multipart), MIME da la posibilidad de crear
mensajes que tengan partes y subpartes organizadas en una estructura arbórea en la
que los nodos hoja pueden ser cualquier tipo de contenido no multiparte y los nodos
que no son hojas pueden ser de cualquiera de las variedades de tipos multiparte. Este
mecanismo soporta:

 mensajes de texto plano usando text/plain (este es el valor implícito para el

encabezado "Content-type:")
 texto más archivos adjuntos (multipart/mixed con una parte text/plain y otras partes
que no son de texto, por ejemplo: application/pdf para
documentos pdf, application/vnd.oasis.opendocument.text para OpenDocument
text). Un mensaje MIME que incluye un archivo adjunto generalmente indica el
nombre original del archivo con un encabezado "Content-disposition:" o por un
atributo name de Content-Type, por lo que el tipo o formato del archivo se indica
usando tanto el encabezado MIME content-type y la extensión del archivo
(usualmente dependiente del SO).
Domain Name System
Domain Name System o DNS (en español «Sistema de Nombres de Dominio») es un
sistema de nomenclatura jerárquica para computadoras, servicios o cualquier recurso
conectado a Internet o a una red privada. Este sistema asocia información variada con
nombres de dominios asignado a cada uno de los participantes. Su función más
importante, es traducir (resolver) nombres inteligibles para las personas en identificadores
binarios asociados con los equipos conectados a la red, esto con el propósito de poder
localizar y direccionar estos equipos mundialmente.
El servidor DNS utiliza una base de datos distribuida y jerárquica que almacena
información asociada a nombres de dominio en redes como Internet. Aunque como base
de datos el DNS es capaz de asociar diferentes tipos de información a cada nombre, los
usos más comunes son la asignación de nombres de dominio a direcciones IP y la
localización de los servidores de correo electrónico de cada dominio.
La asignación de nombres a direcciones IP es ciertamente la función más conocida de los
protocolos DNS. Por ejemplo, si la dirección IP del sitio FTP
de ficct.uagrm.edu.bo es 200.87.51.4, la mayoría de la gente llega a este equipo
especificando ftp.ficct.uagrm.edu.bo y no la dirección IP. Además de ser más fácil
de recordar, el nombre es más fiable. La dirección numérica podría cambiar por muchas
razones, sin que tenga que cambiar el nombre.
Inicialmente, el DNS nació de la necesidad de recordar fácilmente los nombres de todos
los servidores conectados a Internet. En un inicio, SRI (ahora SRI International) alojaba un
archivo llamado HOSTS que contenía todos los nombres de dominio conocidos. El
crecimiento explosivo de la red causó que el sistema de nombres centralizado en el
archivo hosts no resultara práctico y en 1983, Paul V. Mockapetris publicó los RFC
882y RFC 883 definiendo lo que hoy en día ha evolucionado hacia el DNS moderno
(estos RFC han quedado obsoletos por la publicación en 1987 de los RFC 1034 y RFC
1035).

Componentes
Para la operación práctica del sistema DNS se utilizan tres componentes principales:

 Los Clientes fase 1: Un programa cliente DNS que se ejecuta en la computadora del
usuario y que genera peticiones DNS de resolución de nombres a un servidor
DNS (Por ejemplo: ¿Qué dirección IP corresponde a nombre.dominio?);
 Los Servidores DNS: Que contestan las peticiones de los clientes. Los servidores
recursivos tienen la capacidad de reenviar la petición a otro servidor si no disponen de
la dirección solicitada.
 Y las Zonas de autoridad, es una parte del espacio de nombre de dominios sobre la
que es responsable un servidor DNS, que puede tener autoridad sobre varias zonas. (
Por ejemplo : subdominio .ORG, .COM, etc).

Entendiendo las partes de un nombre de

dominio
Un nombre de dominio usualmente consiste en dos o más partes (técnicamente
«etiquetas»), separadas por puntos cuando se las escribe en forma de texto. Por
ejemplo, www.example.com o es.wikipedia.org
 A la etiqueta ubicada más a la derecha se le llama dominio de nivel superior (en
inglés top level domain).
Como com en www.ejemplo.como org en es.wikipedia.org
 Cada etiqueta a la izquierda especifica una subdivisión o subdominio. Nótese que
"subdominio" expresa dependencia relativa, no dependencia absoluta. En teoría, esta
subdivisión puede tener hasta 127 niveles, y cada etiqueta puede contener hasta 63
caracteres, pero restringidos a que la longitud total del nombre del dominio no exceda
los 255 caracteres, aunque en la práctica los dominios son casi siempre mucho más
cortos.
 Finalmente, la parte más a la izquierda del dominio suele expresar el nombre de la
máquina (en inglés hostname). El resto del nombre de dominio simplemente especifica
la manera de crear una ruta lógica a la información requerida. Por ejemplo, el
dominio es.wikipedia.orgtendría el nombre de la máquina "es", aunque en este
caso no se refiere a una máquina física en particular.

El DNS consiste en un conjunto jerárquico de servidores DNS. Cada dominio o subdominio

tiene una o más zonas de autoridad que publican la información acerca del dominio y los
nombres de servicios de cualquier dominio incluido. La jerarquía de las zonas de autoridad
coincide con la jerarquía de los dominios. Al inicio de esa jerarquía se encuentra
los servidores raíz: los servidores que responden cuando se busca resolver un dominio de
primer y segundo nivel.

DNS en el mundo real

Los usuarios generalmente no se comunican directamente con el servidor DNS: la
resolución de nombres se hace de forma transparente por las aplicaciones del cliente (por
ejemplo, navegadores, clientes de correo y otras aplicaciones que usan Internet). Al
realizar una petición que requiere una búsqueda de DNS, la petición se envía al servidor
DNS local del sistema operativo. El sistema operativo, antes de establecer alguna
comunicación, comprueba si la respuesta se encuentra en la memoria caché. En el caso
de que no se encuentre, la petición se enviará a uno o más servidores DNS.
La mayoría de usuarios domésticos utilizan como servidor DNS el proporcionado por el
proveedor de servicios de Internet. La dirección de estos servidores puede ser configurada
de forma manual o automática mediante DHCP. En otros casos, los administradores de
red tienen configurados sus propios servidores DNS.
En cualquier caso, los servidores DNS que reciben la petición, buscan en primer lugar si
disponen de la respuesta en la memoria caché. Si es así, sirven la respuesta; en caso
contrario, iniciarían la búsqueda de manera recursiva. Una vez encontrada la respuesta, el
servidor DNS guardará el resultado en su memoria caché para futuros usos y devuelve el
resultado.
Es importante añadir que el protocolo DNS generalmente transporta las peticiones y
respuestas por puerto UDP, puesto que al ser un protocolo que por su estructura y al tener
menos niveles de seguridad es mucho más rápido. Los motivos por el cual en ocasiones
se usa el puerto TCP son cuando se necesitan transportar respuestas mayores de 512
bytes de longitud y cuando por razones de fiabilidad se necesitan conectar un servidor
DNS secundario al primario para recoger una nueva base de datos con authoritative.

Jerarquía DNS

Árbol DNS
El espacio de nombres de dominio tiene una estructura arborescente. Las hojas y los
nodos del árbol se utilizan como etiquetas de los medios. Un nombre de dominio completo
de un objeto consiste en la concatenación de todas las etiquetas de un camino. Las
etiquetas son cadenas alfanuméricas (con '-' como único símbolo permitido), deben contar
con al menos un carácter y un máximo de 63 caracteres de longitud, y deberá comenzar
con una letra (y no con '-') (ver la RFC 1035, sección "2.3.1. Preferencia nombre de la
sintaxis "). Las etiquetas individuales están separadas por puntos. Un nombre de dominio
termina con un punto (aunque este último punto generalmente se omite, ya que es
puramente formal). Un FQDN correcto (también llamado Fully Qualified Domain Name), es
por ejemplo este: www.example.com. (incluyendo el punto al final).
Un nombre de dominio debe incluir todos los puntos y tiene una longitud máxima de 255
caracteres.
Un nombre de dominio se escribe siempre de derecha a izquierda. El punto en el extremo
derecho de un nombre de dominio separa la etiqueta de la raíz de la jerarquía (en inglés,
root). Este primer nivel es también conocido como dominio de nivel superior (TLD - Top
Level Domain).
Los objetos de un dominio DNS (por ejemplo, el nombre del equipo) se registran en un
archivo de zona, ubicado en uno o más servidores de nombres.

Tipos de servidores DNS

 Primarios o maestros: Guardan los datos de un espacio de nombres en sus ficheros.
 Secundarios o esclavos: Obtienen los datos de los servidores primarios a través de
una transferencia de zona.
 Locales o caché: Funcionan con el mismo software, pero no contienen la base de
datos para la resolución de nombres. Cuando se les realiza una consulta, estos a su
vez consultan a los servidores DNS correspondientes, almacenando la respuesta en
su base de datos para agilizar la repetición de estas peticiones en el futuro continuo o
libre.

Tipos de resolución de nombres de dominio

Existen dos tipos de consultas que un cliente puede hacer a un servidor DNS, la iterativa y
la recursiva.

Resolución recursiva
Las resoluciones recursivas consisten en la respuesta completa que el servidor de
nombres pueda dar. El servidor de nombres consulta sus datos locales (incluyendo su
caché) buscando los datos solicitados. El servidor encargado de hacer la resolución realiza
iterativamente preguntas a los diferentes DNS de la jerarquía asociada al nombre que se
desea resolver, hasta descender en ella hasta la máquina que contiene la zona autoritativa
para el nombre que se desea resolver.

Resolución iterativa
En las resoluciones iterativas, el servidor no tiene la información en sus datos locales, por
lo que busca y se pone en contacto con un servidor DNS raíz, y en caso de ser necesario
repite el mismo proceso básico (consultar a un servidor remoto y seguir a la siguiente
referencia) hasta que obtiene la mejor respuesta a la pregunta.
Cuando existe más de un servidor autoritario para una zona, Bind utiliza el menor valor en
la métrica RTT (round-trip time) para seleccionar el servidor. El RTT es una medida para
determinar cuánto tarda un servidor en responder una consulta.
El proceso de resolución normal se da de la siguiente manera:

1. El servidor A recibe una consulta iterativa desde el cliente DNS.

2. El servidor A envía una consulta iterativa a B.
3. El servidor B refiere a A otro servidor de nombres, incluyendo a C.
4. El servidor A envía una consulta iterativa a C.
5. El servidor C refiere a A otro servidor de nombres, incluyendo a D.
6. El servidor A envía una consulta iterativa a D.
7. El servidor D responde.
8. El servidor A regresa la respuesta al resolver.
9. El servidor entrega la resolución al programa que solicitó la información.
Corporación de Internet para la Asignación de
Nombres y Números
La Corporación de Internet para la Asignación de Nombres y Números (en
inglés: Internet Corporation for Assigned Names and Numbers; ICANN) es
una organización sin fines de lucro creada el 18 de septiembre de 1998 con objeto de
encargarse de cierto número de tareas realizadas con anterioridad a esa fecha por otra
organización, la IANA. Su sede radica en California y está sujeta a las leyes de dicho
Estado.

¿Qué es ICANN?
ICANN es una organización que opera a nivel multinacional/internacional y es la
responsable de asignar las direcciones del protocolo IP, de los identificadores de
protocolo, de las funciones de gestión del sistema de dominio y de la administración del
sistema de servidores raíz.
En un principio, estos servicios los realizaba IANA (Internet Assigned Numbers Authority) y
otras entidades del gobierno estadounidense.
ICANN se dedica a preservar la estabilidad de Internet por medio de procesos basados en
el consenso.

El papel de ICANN
ICANN coordina la administración de los elementos técnicos del DNS para garantizar la
resolución unívoca de los nombres, para que los usuarios puedan encontrar todas las
direcciones sin ser repetidas.

El funcionamiento de ICANN
En la actualidad, la ICANN está formalmente organizada como una corporación sin fines
de lucro y de utilidad pública. Está administrada por una Junta de Directores, que está
compuesta por seis representantes de las organizaciones de apoyo, sub-grupos que se
ocupan de las secciones específicas de las políticas de ICANN en virtud de la
competencia, ocho representantes independientes del interés público general,
seleccionados a través de un Comité de Nominaciones que representa a todas las
circunscripciones de la ICANN, y el Presidente y Director Ejecutivo, nombrado por el resto
de la Junta.
En la actualidad hay tres organizaciones de apoyo: la GNSO (Generic Names Supporting
Organization) se ocupa de la formulación de políticas sobre dominios genéricos de nivel
superior, ccNSO (Country Code Names Supporting Organization) se ocupa de la
elaboración de políticas relativas a códigos de países en dominios de nivel superior,
la ASO (Address Supporting Organization) se ocupa de la formulación de políticas
en direcciones IP.
ICANN también se basa en algunos comités consultivos para recibir asesoramiento sobre
los intereses y necesidades de los interesados que no participen directamente en las
organizaciones de apoyo. Entre ellos figuran el Comité Asesor Gubernamental (GAC), que
está integrado por representantes de un gran número de gobiernos nacionales de todo el
mundo; el ALAC (At-Large Advisory Comité), que está integrado por representantes de
organizaciones de los distintos usuarios de Internet de todo el mundo; el sistema DNS
y TLG (Technical Liaison Group) compuesto por representantes de otras organizaciones
técnicas internacionales de Internet.

Procedimientos
ICANN periódicamente sostiene reuniones públicas de rotación entre los continentes para
fomentar la participación mundial en sus procesos. Los críticos argumentan que los
lugares de estas reuniones se encuentran a menudo en los países con menor uso de
Internet. Lo que se quiere dar a conocer es que ICANN tiene mandato en todo el mundo y
una parte esencial de su misión es fomentar el uso de Internet donde es débil.
Se creó en California debido a la iniciativa de Jon Postel, uno de sus fundadores. ICANN
sigue en el mismo edificio donde se creó, que es una oficina del Instituto de Ciencias de la
Información en la Universidad del Sur de California.
Las resoluciones de la junta de ICANN se publican en su página web para que las pueda
consultar todo el mundo.

Política Uniforme
Una de las tareas que se le pidió que realizara es abordar la cuestión del nombre de
dominio propiedad del gTLD. ICANN intentó que esa política fuera elaborada en estrecha
cooperación con la Organización Mundial de la Propiedad Intelectual (OMPI), y el resultado
ha pasado a ser conocido como la Política de Resolución de Disputas de Nombres de
Dominio Uniformes (UDRP).
Esta política esencialmente intenta proporcionar un mecanismo de respuesta rápida,
económica y razonable de resolución de conflictos de nombres de dominio.

Historia
El mandato original de la ICANN provino del Gobierno de los Estados Unidos durante el
gobierno de Bill Clinton y George W. Bush. El 30 de enero de 1998, el Consejo Nacional
de Telecomunicaciones y Administración de Información (NTIA), una agencia del
Departamento de Comercio de los EE.UU., comentó que era necesaria "una propuesta
para mejorar la gestión técnica de Internet los nombres y las direcciones". La propuesta de
elaboración de normas, o "Libro Verde".
Se publicó en el Registro Federal el 20 de febrero de 1998, y ofrecía oportunidades para
comentarios del público. NTIA ha recibido más de 650 observaciones desde el 23 de
marzo de 1998, cuando se cerró el periodo de comentarios.
El Libro Verde propone ciertas acciones destinadas a privatizar la gestión de Internet, los
nombres y las direcciones de una manera que permita el desarrollo de sólidas
competencias y facilite la participación global en la gestión de Internet. Además, propone
para la discusión una serie de cuestiones relacionadas con la gestión de DNS, incluido el
sector privado. ICANN se creó en respuesta a esta política.
En septiembre y octubre de 2003, la ICANN desempeñó un papel crucial en el conflicto en
torno a VeriSign's "wild card", un servicio de DNS. Después de una carta abierta de la
ICANN, un ultimátum a VeriSign, la empresa voluntariamente terminó el servicio el 4 de
octubre de 2003. Tras este paso, VeriSign presentó una demanda contra ICANN el 27 de
febrero de 2004, alegando que ICANN había sobrepasado su autoridad, buscando a través
de la demanda para reducir la ambigüedad sobre la autoridad de ICANN. La lucha contra
los monopolios VeriSign componente de la reclamación fue desestimada en agosto de
2004.
El 17 de mayo de 2004, ICANN publicó un proyecto de presupuesto para el año 2004-05.
Incluye propuestas para aumentar la transparencia y el profesionalismo de sus
operaciones, y aumenta en gran medida su propuesta de gasto. El Consejo Europeo
Nacional de dominio de nivel superior Registros (CENTR), que representa los registros de
Internet de 39 países, rechazó el aumento, acusando a ICANN de una falta de prudencia
financiera. A pesar de las críticas, se llegó a un acuerdo de registro para los dominios de
nivel superior.JOBS y.TRAVEL que incluye una tasa de 2 dólares por cada dominio de las
empresas autorizadas.
Junto con el éxito de las negociaciones.TRAVEL y.JOBS, los nombres de dominio.MOBI,
y.CAT son algunos de los nuevos dominios de nivel superior establecidos por ICANN.
El 10 de mayo de 2006 la ICANN no aprobó un plan para un nuevo ".XXX" sufijo que han
sido designados para los sitios web con contenido pornográfico. ICANN rechazó
formalmente.XXX el 30 de marzo de 2007 durante su reunión en Lisboa, Portugal, aunque
posteriormente, el 25 de junio de 2010, decidieron dar vía libre al sufijo que finalmente verá
la luz a principios de 2011.
El 26 de julio de 2006, el Gobierno de los Estados Unidos renovó el contrato con la ICANN
para la ejecución de la IANA por un período adicional de cinco años.5

Logros
ICANN estableció la competencia en el mercado para los registros de nombres de dominio
genéricos de primer nivel quitando el monopolio. Implementó la Política de Resolución de
Disputas de Nombres de Dominio Uniformes (UDRP). Ha adoptado normas generales para
nombres de dominios internacionalizados (IDN), lo que ha permitido el registro de dominios
en muchos idiomas, cada zona tiene sus registros permitidos.

Alternativas
Se han sugerido alternativas a ICANN para la gestión de nombres DNS y el espacio de
direcciones, entre ellas:

 Dejar que el Gobierno de los EE. UU. realice las tareas de la ICANN directamente.
 Asignación de tareas del ICANN a la Unión Internacional de Telecomunicaciones.
 Dejar al Registro Regional de Internet gestionar las direcciones.
 El abandono de todo control y dejar que los nombres DNS sean gratuitos para todos.
 La creación de una nueva organización sin fines de lucro sin ningún vínculo con la
actual, como por ejemplo OpenNIC.

Próximos retos
 Implementar nombres de dominio internacionalizados y nuevos dominios de nivel
superior genéricos.
 Aumentar la seguridad y estabilidad de los identificadores únicos de Internet.
 Supervisar el agotamiento del espacio de direcciones IPv4 y liderar el cambio hacia la
adopción del IPv6.
 Mantener y mejorar la confianza en el mercado de dominios de nivel superior
genéricos.
 Luchar por la excelencia en las operaciones clave.
 Fortalecer el modelo de múltiples partes interesadas de ICANN para atender la
creciente demanda y las necesidades cambiantes.
 Reforzar la responsabilidad y el gobierno.
 Garantizar la estabilidad financiera y la responsabilidad.

Simple Mail Transfer Protocol

El Simple Mail Transfer Protocol (SMTP) o “protocolo para transferencia simple de
correo”, es un protocolo de red utilizado para el intercambio de mensajes de correo
electrónico entre computadoras u otros dispositivos (PDA, teléfonos móviles, etcétera).
Fue definido en el RFC 2821 y es un estándar oficial de Internet.
El funcionamiento de este protocolo se da en línea, de manera que opera en los servicios
de correo electrónico. Sin embargo, este protocolo posee algunas limitaciones en cuanto a
la recepción de mensajes en el servidor de destino (cola de mensajes recibidos). Como
alternativa a esta limitación se asocia normalmente a este protocolo con otros, como el
POP o IMAP, otorgando a SMTP la tarea específica de enviar correo, y recibirlos
empleando los otros protocolos antes mencionados (POP O IMAP).

Modelo de procesamiento de correo

Modelo de procesamiento del correo.

El correo electrónico es presentado por un cliente de correo (MUA, agente de usuario de
correo) a un servidor de correo (MSA, agente de sumisión de correo) usando SMTP. Una
gran parte de los abastecedores de caja permiten la sumisión. Desde allí, el MSA entrega
el correo a su agente de transferencia postal mejor conocido como el MTA (Mail Transfer
Agent, Agente de Transferencia de Correo). En algunas ocasiones, estos dos agentes son
casos diferentes aunque hay que destacar que provienen del mismo software de donde
fueron lanzados sólo que presentan opciones diferentes dentro de la misma máquina.
El procesamiento local que se presenta puede ser realizado en una sola máquina o partido
entre varias aplicaciones; en este segundo caso, los procesos implicados pueden
compartir archivos; aquí SMTP es usado para la transferencia de mensajes internamente,
con cada uno de los hosts configurados para usar la siguiente aplicación como un anfitrión
elegante. Para lograr la localización del servidor objetivo, el MTA divisorio tiene que usar el
sistema de nombre de dominio (DNS) para lograr la búsqueda del registro interno de
cambiado de correo conocido como registro MX para la esfera del recipiente (la parte de la
dirección a la derecha). Es en ese instante cuando el registro de MX devuelto contiene el
nombre del anfitrión objetivo.
Luego el MTA se une al servidor de cambio como un cliente SMTP. Una vez que MX
acepta el mensaje entrante, este a su vez se lo da a un agente de entrega de correo
(MDA) para luego ser llevado a la entrega de correo local. El MDA, además de entregar
mensajes es también capaz de salvar mensajes en un buzón de formato, y la recepción de
correo puede ser realizada usando muchas computadoras. Hay dos formas en que un
MDA puede entregar mensajes: ya sea enviándolos directamente al almacenamiento, o
expedirlos sobre una red usando SMTP. Una vez entregado al servidor de correo local,
dicho correo es almacenado para la recuperación de la hornada. Su recuperación se logra
por medio de las aplicaciones de usuario final, conocidas como clientes de correo
electrónico, usando el Protocolo de Acceso de Mensaje de Internet (IMAP), este protocolo
que facilita tanto el acceso para enviar, como el manejo de correo almacenado.

Puertos
Los administradores de servidor pueden elegir si los clientes utilizan TCP puerto 25
(SMTP) o el puerto 587 (Presentación) para retransmitir el correo saliente a una inicial del
servidor de correo.3 Las especificaciones y muchos servidores soportan ambos. Aunque
algunos servidores soportan el puerto 465 para el legado SMTP seguro en violación de las
especificaciones, es preferible utilizar los puertos estándar y comandos ESMTP estándar
de acuerdo con RFC 3207, si se debe utilizar una sesión segura entre el cliente y el
servidor.
Algunos servidores están configurados para rechazar toda la retransmisión en el puerto 25,
pero los usuarios válidos de autenticación en el puerto 587 pueden retransmitir correo a
cualquier dirección válida. Algunos proveedores de servicios de Internet interceptan el
puerto 25, volviendo a dirigir el tráfico a su propio servidor SMTP, independientemente de
la dirección de destino. Esto significa que no es posible para sus usuarios acceder a un
servidor SMTP fuera de la red del ISP a través del puerto 25.
Algunos servidores SMTP soportan el acceso autenticado en otro puerto que no sea 587 o
25 para permitir a los usuarios conectarse a ellos, incluso si el puerto 25 está bloqueado,
pero 587 es el puerto estándar y ampliamente apoyada por los usuarios enviar correo
nuevo. Microsoft Exchange Server 2013 SMTP puede escuchar en los puertos 25, 587,
465, 475, y 2525, en función de servidor y si los roles se combinan en un solo servidor. Los
puertos 25 y 587 se utilizan para proporcionar la conectividad del cliente con el servicio de
transporte en la parte delantera de la función de servidor de acceso de cliente (CAS). Los
puertos 25, 465 y 475 son utilizados por el servicio de transporte de buzón de correo. Sin
embargo, cuando la función de buzón se combina con la función de CAS en un único
servidor, el puerto 2525 se utiliza por la función de buzón de SMTP desde el servicio de
transporte de extremo delantero del CAS, CAS, mientras que continúa para utilizar el
puerto 25. Puerto 465 es utilizado por el servicio de transporte de buzón de correo para
recibir las conexiones de cliente proxy de la función CAS. Puerto 475 es utilizado por la
función de buzón para comunicarse directamente con otras funciones de buzón, la
transferencia de correo entre el servicio de envío de transporte de buzón de correo y el
servicio de entrega de transporte buzó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 válido, 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 de todo un 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.

Ejemplo de una comunicación SMTP

En primer lugar se ha de establecer una conexión entre el emisor (cliente) y el receptor
(servidor). Esto puede hacerse automáticamente con un programa cliente de correo o
mediante un cliente telnet.
En el siguiente ejemplo se muestra una conexión típica. Se nombra con la letra C al cliente
y con S al servidor.

$telnet mail.ficct.uagrm.edu.bo 25
S: Trying 200.87.51.3...
Connected to mail.ficct.uagrm.edu.bo.
Escape character is '^]'.
220 proxy.ficct.uagrm.edu.bo ESMTP Sendmail; Mon, 4 Apr 2016 20:19:04 -0400

C: EHLO proxy.ficct.uagrm.edu.bo

S: 250-proxy.ficct.uagrm.edu.bo Hello [172.20.172.64], pleased to meet you

250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-STARTTLS
250-DELIVERBY
250 HELP

C: MAIL FROM: <evansbv@gmail.com>

S: 250 2.1.0 evansbv@gmail.com... Sender ok

C: RCPT TO: <grupo01sa@ficct.uagrm.edu.bo>

S: 250 2.1.5 grupo01sa@ficct.uagrm.edu.bo... Recipient ok

C: DATA

S: 354 Enter mail, end with "." on a line by itself

C: Subject: DEMO EMAIL

C: Hola,
C: Esto es una prueba.

C: Hasta luego.

C: .

S: 250 2.0.0 u350ImOV011465 Message accepted for delivery

C: quit

S: 221 2.0.0 proxy.ficct.uagrm.edu.bo closing connection

Connection closed by foreign host

Formato del mensaje

Como se muestra en el ejemplo anterior, el mensaje es enviado por el cliente después de
que éste manda la orden DATA al servidor. El mensaje está compuesto por dos partes:

 Cabecera: en el ejemplo las tres primeras líneas del mensaje son la cabecera. En
ellas se usan unas palabras clave para definir los campos del mensaje. Estos campos
ayudan a los clientes de correo a organizarlos y mostrarlos. Los más típicos
son subject (asunto), from (emisor) y to (receptor). Éstos dos últimos campos no hay
que confundirlos con las órdenes MAIL FROM y RCPT TO, que pertenecen al
protocolo, pero no al formato del mensaje.
 Cuerpo del mensaje: es el mensaje propiamente dicho. En el SMTP básico está
compuesto únicamente por texto, y finalizado con una línea en la que el único carácter
es un punto.
Post Office Protocol
En informática se utiliza el Post Office Protocol (POP3, Protocolo de Oficina de Correo o
"Protocolo de Oficina Postal") 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
quedado obsoletas debido a las últimas versiones de POP3. En general cuando se hace
referencia al término POP, se refiere a POP3 dentro del contexto de protocolos de correo
electrónico.

Características
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 de dejar 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.
Los clientes que utilizan la opción dejar mensajes en el servidor por lo general utilizan la
orden UIDL ('Unique IDentification Listing). La mayoría de las órdenes de POP3
identifican los mensajes dependiendo de su número ordinal del servidor de correo. Esto
genera problemas al momento que un cliente pretende dejar los mensajes en el servidor,
ya que los mensajes con número cambian de una conexión al servidor a otra. Por ejemplo
un buzón de correo contenía 5 mensajes en la última conexión, después otro cliente
elimina el mensaje número 3, si se vuelve a iniciar otra conexión, ya el número que tiene el
mensaje 4 pasará a ser 3, y el mensaje 5 pasará a ser número 4 y la dirección de estos
dos mensajes cambiara. El UIDL proporciona un mecanismo que evita los problemas de
numeración. El servidor le asigna una cadena de caracteres única y permanente al
mensaje. Cuando un cliente de correo compatible con POP3 se conecta al servidor utiliza
la orden UIDL para obtener el mapeo del identificador de mensaje. De esta manera el
cliente puede utilizar ese mapeo para determinar qué mensajes hay que descargar y
cuáles hay que guardar al momento de la descarga.
Al igual que otros viejos protocolos de internet, POP3 utilizaba un mecanismo de firmado
sin cifrado. La transmisión de contraseñas de POP3 en texto plano aún se da. En la
actualidad POP3 cuenta con diversos métodos de autenticación que ofrecen una diversa
gama de niveles de protección contra los accesos ilegales al buzón de correo de los
usuarios. Uno de estos es APOP, el cual utiliza funciones MD5 para evitar los ataques de
contraseñas. Mozilla, Eudora, Novell Evolution así como Mozilla Thunderbird implementan
funciones APP.

Órdenes
Para establecer una conexión a un servidor POP, el cliente de correo abre una conexión
TCP en el puerto 110 del servidor. Cuando la conexión se ha establecido, el servidor POP
envía al cliente POP y después las dos máquinas se envían entre sí otras órdenes y
respuestas que se especifican en el protocolo. Como parte de esta comunicación, al
cliente POP se le pide que se autentifique (Estado de autenticación), donde el nombre de
usuario y la contraseña del usuario se envían al servidor POP. Si la autenticación es
correcta, el cliente POP pasa al Estado de transacción, en este estado se pueden utilizar
órdenes LIST, RETR y DELE para mostrar, descargar y eliminar mensajes del servidor,
respectivamente. Los mensajes definidos para su eliminación no se quitan realmente del
servidor hasta que el cliente POP envía la orden QUIT para terminar la sesión. En ese
momento, el servidor POP pasa al Estado de actualización, fase en la que se eliminan los
mensajes marcados y se limpian todos los recursos restantes de la sesión.
Es posible conectarse manualmente al servidor POP3 haciendo Telnet al puerto 110. Es
muy útil cuando envían un mensaje con un fichero muy largo que no se quiere recibir.

 USER <nombre> Identificación de usuario (Solo se realiza una vez).

 PASS <password> Envía la clave del servidor.
 STAT Da el número de mensajes no borrados en el buzón y su longitud total.
 LIST Muestra todos los mensajes no borrados con su longitud.
 RETR <número> Solicita el envío del mensaje especificando el número (no se borra
del buzón).
 TOP <número> <líneas> Muestra la cabecera y el número de líneas requerido del
mensaje especificando el número.
 DELE <número> Borra el mensaje especificando el número.
 RSET Recupera los mensajes borrados (en la conexión actual).
 UIDL <número> Devuelve una cadena identificatoria del mensaje persistente a través
de las sesiones. Si no se especifica <número> se devuelve una lista con los números
de mensajes y su cadena identificatoria de los mensajes no borrados.
 QUIT Salir.

Ejemplo de una comunicación POP

En primer lugar se ha de establecer una conexión entre el emisor (cliente) y el receptor
(servidor). Esto puede hacerse automáticamente con un programa cliente de correo o
mediante un cliente telnet.
En el siguiente ejemplo se muestra una conexión típica. Se nombra con la letra C al cliente
y con S al servidor.
$telnet mail.ficct.uagrm.edu.bo 110
S: Trying 200.87.51.3...
Connected to mail.ficct.uagrm.edu.bo.
Escape character is '^]'.
+OK Dovecot ready.

C: USER grupo01sa

S: +OK

C: PASS grupo0101

S: +OK Logged in.

C: LIST

S: +OK 3 messages:
1 446
2 393
3 427
.

C: RETR 1

S: +OK 446 octets

Return-Path: <grupo01sa@ficct.uagrm.edu.bo>
Received: from mail.ficct.uagrm.edu.bo ([172.20.172.71])
by proxy.ficct.uagrm.edu.bo (8.15.2/8.14.9) with ESMTP id u3518lH1014
778
for grupo01sa@ficct.uagrm.edu.bo; Mon, 4 Apr 2016 21:11:09 -0400
Date: Mon, 4 Apr 2016 21:09:03 -0400
From: grupo01sa <grupo01sa@ficct.uagrm.edu.bo>
Message-Id: <201604050111.u3518lH1014778@proxy.ficct.uagrm.edu.bo>
subject:hola

hola agan funcionar por favor

.
C:DELE 1
S: +OK Marked to be deleted.
C: quit

S: +OK Logging out, messages deleted.

Connection closed by foreign host.
Hypertext Transfer Protocol
Hypertext Transfer Protocol o HTTP (en español protocolo de transferencia de
hipertexto) es el protocolo usado en cada transacción de la World Wide Web. HTTP fue
desarrollado por el World Wide Web Consortium y la Internet Engineering Task Force,
colaboración que culminó en 1999 con la publicación de una serie de RFC, el más
importante de ellos es el RFC 2616 que especifica la versión 1.1. HTTP define la sintaxis y
la semántica que utilizan los elementos de software de la arquitectura web (clientes,
servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue
el esquema petición-respuesta entre un cliente y un servidor. Al cliente que efectúa la
petición (un navegador web o un spider) se lo conoce como "user agent" (agente del
usuario). A la información transmitida se la llama recurso y se la identifica mediante
un localizador uniforme de recursos (URL). El resultado de la ejecución de un programa,
una consulta a una base de datos, la traducción automática de un documento, etc.
HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre
conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente
mantener estado. Para esto se usan las cookies, que es información que un servidor
puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la
noción de "sesión", y también permite rastrear usuarios ya que las cookies pueden
guardarse en el cliente por tiempo indeterminado.

Transacciones HTTP
Una transacción HTTP está formada por un encabezado seguido, opcionalmente, por una
línea en blanco y algún dato. El encabezado especificará cosas como la acción requerida
del servidor, o el tipo de dato retornado, o el código de estado.
El uso de campos de encabezados enviados en las transacciones HTTP le dan gran
flexibilidad al protocolo. Estos campos permiten que se envíe información descriptiva en la
transacción, permitiendo así la autenticación, cifrado e identificación de usuario.
Un encabezado es un bloque de datos que precede a la información propiamente dicha,
por lo que muchas veces se hace referencia a él como metadato —porque tiene datos
sobre los datos—.
Si se reciben líneas de encabezado del cliente, el servidor las coloca en las variables de
entorno de CGI con el prefijo HTTP_ seguido del nombre del encabezado. Cualquier
carácter guion ( - ) del nombre del encabezado se convierte a caracteres "_".
El servidor puede excluir cualquier encabezado que ya esté procesado,
como Authorization, Content-type y Content-length. El servidor puede elegir excluir alguno
o todos los encabezados, si incluirlos, si se excede algún límite del entorno de sistema.
Ejemplos de esto son las variables HTTP_ACCEPT y HTTP_USER_AGENT.

 HTTP_ACCEPT. Los tipos MIME que el cliente aceptará, dados los encabezados
HTTP. Otros protocolos quizás necesiten obtener esta información de otro lugar. Los
elementos de esta lista deben estar separados por una coma, como se dice en la
especificación HTTP: tipo, tipo.

 HTTP_USER_AGENT. El navegador que utiliza el cliente para realizar la petición. El

formato general para esta variable es: software/versión biblioteca/versión.

El servidor envía al cliente:

 Un código de estado que indica si la petición fue correcta o no. Los códigos de error
típicos indican que el archivo solicitado no se encontró, que la petición no se realizó de
forma correcta o que se requiere autenticación para acceder al archivo.
 La información propiamente dicha. Como HTTP permite enviar documentos de todo
tipo y formato, es ideal para transmitir multimedia, como gráficos, audio y video. Esta
libertad es una de las mayores ventajas de HTTP.
 Información sobre el objeto que se retorna.

Hay que tener en cuenta que la lista no es una lista completa de los campos de
encabezado y que todos ellos sólo tienen sentido en una dirección.

Versiones
HTTP ha pasado por múltiples versiones del protocolo, muchas de las cuales son
compatibles con las anteriores. El RFC 2145 describe el uso de los números de versión de
HTTP. El cliente le dice al servidor al principio de la petición la versión que usa, y el
servidor usa la misma o una anterior en su respuesta.

0.9
Obsoleta. Soporta sólo un comando, GET, y además no especifica el número de
versión HTTP. No soporta cabeceras. Como esta versión no soporta POST, el
cliente no puede enviarle mucha información al servidor.
HTTP/1.0 (mayo de 1996)
Esta es la primera revisión del protocolo que especifica su versión en las
comunicaciones, y todavía se usa ampliamente, sobre todo en servidores proxy.
HTTP/1.1 (junio de 1999)
Versión actual; las conexiones persistentes están activadas por defecto y
funcionan bien con los proxies. También permite al cliente enviar múltiples
peticiones a la vez por la misma conexión (pipelining) lo que hace posible eliminar
el tiempo de Round-Trip delay por cada petición.
HTTP/1.2
Los primeros borradores de 1995 del documento PEP — an Extension Mechanism
for HTTP (el cuál propone el Protocolo de Extensión de Protocolo, abreviado PEP)
los hizo el World Wide Web Consortium y se envió al Internet Engineering Task
Force. El PEP inicialmente estaba destinado a convertirse en un rango distintivo de
HTTP/1.2.3 En borradores posteriores, sin embargo, se eliminó la referencia a
HTTP/1.2. El RFC 2774 (experimental), HTTP Extension Framework, incluye en
gran medida a PEP. Se publicó en febrero de 2000.

Ejemplo de un diálogo HTTP

Para obtener un recurso con el URL http://www.example.com/index.html

1. Se abre una conexión al host www.example.com, puerto 80 que es el puerto

predefinido para HTTP.
2. Se envía un mensaje en el estilo siguiente:

GET /index.html HTTP/1.1

 Host: www.example.com

User-Agent: nombre-cliente

[Línea en blanco]
La respuesta del servidor está formada por encabezados seguidos del recurso
solicitado, en el caso de una página web:

HTTP/1.1 200 OK

Date: Fri, 31 Dec 2003 23:59:59 GMT

Content-Type: text/html

Content-Length: 1221

<html>

<body>

<h1>Página principal de tuHost</h1>

(Contenido)

</body>

</html>

Métodos de petición
HTTP define 8 métodos (algunas veces referido como "verbos") que indica la acción
que desea que se efectúe sobre el recurso identificado. Lo que este recurso
representa, si los datos pre-existentes o datos que se generan de forma dinámica,
depende de la aplicación del servidor. A menudo, el recurso corresponde a un
archivo o la salida de un ejecutable que residen en el servidor.

HEAD
Pide una respuesta idéntica a la que correspondería a una petición GET, pero sin
el cuerpo de la respuesta. Esto es útil para la recuperación de meta-información
escrita en los encabezados de respuesta, sin tener que transportar todo el
contenido.
GET
Pide una representación del recurso especificado. Por seguridad no debería ser
usado por aplicaciones que causen efectos ya que transmite información a través
de la URI agregando parámetros a la URL. La petición puede ser simple, es decir
en una línea o compuesta de la manera que muestra el ejemplo.
Ejemplo:
GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png
Ejemplo con parámetros:
/index.php?page=main&lang=es
POST
Envía los datos para que sean procesados por el recurso identificado. Los datos se
incluirán en el cuerpo de la petición. Esto puede resultar en la creación de un
nuevo recurso o de las actualizaciones de los recursos existentes o ambas cosas.
PUT
Sube, carga o realiza un upload de un recurso especificado (archivo), es el camino
más eficiente para subir archivos a un servidor, esto es porque en POST utiliza
un mensaje multiparte y el mensaje es decodificado por el servidor. En contraste,
el método PUT te permite escribir un archivo en una conexión socket establecida
con el servidor.
La desventaja del método PUT es que los servidores de hosting compartido no lo
tienen habilitado.
Ejemplo:
PUT /path/filename.html HTTP/1.1
DELETE
Borra el recurso especificado.
TRACE
Este método solicita al servidor que envíe de vuelta en un mensaje de respuesta,
en la sección del cuerpo de entidad, toda la data que reciba del mensaje de
solicitud. Se utiliza con fines de comprobación y diagnóstico.
OPTIONS
Devuelve los métodos HTTP que el servidor soporta para un URL específico. Esto
puede ser utilizado para comprobar la funcionalidad de un servidor web mediante
petición en lugar de un recurso específico.
CONNECT
Se utiliza para saber si se tiene acceso a un host, no necesariamente la petición
llega al servidor, este método se utiliza principalmente para saber si un proxy nos
da acceso a un host bajo condiciones especiales, como por ejemplo "corrientes" de
datos bidireccionales encriptadas (como lo requiere SSL).

Códigos de respuesta
 1xx Mensajes

N° Descripción
100 111 Conexión rechazada

 2xx Operación exitosa

N° Descripción
200 OK
201-203 Información no oficial
204 Sin Contenido
205 Contenido para recargar
206 Contenido parcial

 3xx Redirección

N° Descripción
301 Mudado permanentemente
302 Encontrado
303 Vea otros
304 No modificado
305 Utilice un proxy
307 Redirección temporal

 4xx Error por parte del cliente

N° Descripción
400 Solicitud incorrecta
401 No autorizado
402 Pago requerido
403 Prohibido
404 No encontrado
409 Conflicto
410 Ya no disponible
412 Falló precondición

 5xx Error del servidor

N° Descripción
500 Error interno
501 No implementado
502 Pasarela incorrecta
503 Servicio no disponible
504 Tiempo de espera de la pasarela agotado
505 Versión de HTTP no soportada
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.

Introducción
El protocolo básico de transmisión de mensajes electrónicos de Internet soporta sólo
caracteres ASCII de 7 bit (véase también 8BITMIME). Esto limita los mensajes de correo
electrónico, ya que incluyen sólo 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 y a formato MIME cuando envían o reciben
(SMTP/MIME) e-mails.

Nomenclatura de tipos
MIME asigna un nombre a cada tipo de datos. Los nombres siguen el siguiente formato:
tipo/subtipo (tipo como subtipo son cadenas de caracteres)
El tipo define la categoría general de los datos y el substipo define un tipo más específico
de esos datos. El tipo tener los siguientes valores:

 text: Indica que el contenido es texto plano. Ejemplos de subtipos: html, xml
 multipart: Indica que tiene multiples partes de datos independientes. Ejemplos de
subtipos: form-data, digest
 message: Para encapsular un mensaje existente. Por ejemplo cuando queremos
responder a un mensaje de correo incorporando el mensaje origen. Ejemplos de
subtipos: partial, rfc822
 image: Indica que es una imagen. Ej de subtipos: png, gif
 audio: Indica que es un audio. Ejemplos de subtipos: mpeg, avi
 video: Indica que es un video. Ejemplos de subtipos: mp4, 32kadpcm
 application: Indica que se trata de datos de aplicación los cuales pueden ser binarios.
Ejemplos de subtipos: json, pdf

MIME headers
MIME-Version
La presencia de este encabezado indica que el mensaje utiliza el formato MIME. Su valor
es típicamente igual a "1.0" por lo que este encabezado aparece como:

MIME-Version: 1.0
Debe señalarse que los implementadores han intentado cambiar el número de versión en
el pasado y el cambio ha tenido resultados imprevistos. En una reunión de IETF realizada
en julio 2007 se decidió mantener el número de versión en "1.0" aunque se han realizado
muchas actualizaciones a la versión de MIME.

Content-Type
Este encabezado indica el tipo de medio que representa el contenido del mensaje,
consiste en un tipo: type y un subtipo: subtype, por ejemplo:

Content-Type: text/plain
A través del uso del tipo multiparte (multipart), MIME da la posibilidad de crear mensajes
que tengan partes y subpartes organizadas en una estructura arbórea en la que los
nodos hoja pueden ser cualquier tipo de contenido no multiparte y los nodos que no
son hojas pueden ser de cualquiera de las variedades de tipos multiparte. Este mecanismo
soporta:

 mensajes de texto plano usando text/plain (este es el valor implícito para el

encabezado "Content-type:")
 texto más archivos adjuntos (multipart/mixed con una parte text/plain y otras partes
que no son de texto, por ejemplo: application/pdf para
documentos pdf, application/vnd.oasis.opendocument.text para OpenDocument text).
Un mensaje MIME que incluye un archivo adjunto generalmente indica el nombre
original del archivo con un encabezado "Content-disposition:" o por un
atributo name de Content-Type, por lo que el tipo o formato del archivo se indica
usando tanto el encabezado MIME content-type y la extensión del archivo (usualmente
dependiente del SO).

Content-Type: application/vnd.oasis.opendocument.text;

name="Carta.odt"

Content-Disposition: inline;

filename="Carta.odt"
 reenviar con el mensaje original adjunto (multipart/mixed con una parte text/plain y el
mensaje original como una parte message/rfc822)
 contenido alternativo, un mensaje que contiene el texto tanto en texto plano como en
otro formato, usualmente HTML (multipart/alternativecon el mismo contenido en forma
de text/plain y text/html)
 muchas otras construcciones de mensaje

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, que no son sensibles a mayúsculas ni minúsculas:

 Adecuados para usar con SMTP:

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

Encoded-Word
Desde la RFC 2822, los nombres y valores de los encabezados MIME de mensajes son
siempre caracteres ASCII; los valores que contengan otro tipo de caracteres tienen que
usar la sintaxis de palabra codificada o encoded-word (RFC 2047) en lugar del texto
literal. Esta sintaxis utiliza una cadena de caracteres ASCII que indica el conjunto de
caracteres original (el "charset") y el content-transfer-encoding usado para mapear los
bytes del conjunto original a caracteres ASCII.
Su forma general es:

=?charset?codificación?texto codificado?=

 charset puede ser cualquier conjunto de caracteres registrado con IANA. Típicamente
coincidirá con el charset del cuerpo del mensaje.
 codificación puede ser: " Q " que denota Q-encoding que es similar a la
codificación quoted-printable, o " B " que denota la codificación base64.
 texto codificado es el texto codificado con Q-encoding o base64.

Diferencias entre Q-encoding y quoted-printable

Los códigos ASCII del signo de pregunta (?) y el signo de igualdad (=) no pueden ser
representados directamente dado que ellos son usados como delimitadores del encoded-
word. El código ASCII reservado para el espacio no puede ser representado directamente
porque puede ocasionar que intérpretes antiguos dividan, de forma no deseada, el
encoded-word. Para hacer la codificación más pequeña y fácil de leer, el
símbolo subrayado (_) se utiliza en lugar del espacio, creando el efecto colateral que este
símbolo no se pueda representar directamente. El uso de encoded-word en ciertas partes
de los encabezados impone otras restricciones sobre cuáles caracteres pueden o no ser
representados directamente.
Por ejemplo:

Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=

es interpretado como:

Subject: ¡Hola, señor!

El formato encoded-word no se utiliza para los nombres de los encabezados (por
ejemplo Subject ). Estos nombres de encabezados son siempre en Inglés. Cuando se lee
el mensaje con un cliente de correo en otro idioma que no sea Inglés, los nombres de los
encabezados son traducidos por el cliente.

Mensajes multiparte
Un mensaje MIME multiparte contiene una frontera en el encabezado "Content-type:"; esta
frontera, que no puede aparecer en ninguna de las partes, es ubicada entre cada una de
ellas, y al inicio y al final del cuerpo del mensaje,

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 red tales 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).
Arquitectura Web
1. Introducción - La Web
World Wide Web:

 Universo de información interconectada, accesible a través de internet.

 Propuesta por Tim Berners-Lee (1989).
 Ha tenido mayor difusión que otros servicios

contemporáneas (Archie, Gopher, WAIS), gracias sobre

todo a uno de sus elementos: el HTML.

 Hipertexto.
 Hipermedia.
 En el 2001 había más de un billón de URLs accesibles

al público, repartidas entre más de 30 millones de servidores.

Componentes semánticos de la Web
URI: Uniform Resource Identifier.

 Identifica los recursos web para su acceso y manipulación.

 HTML: HyperText Markup Language.
 Lenguaje de marcas.
 Provee una representación estándar de los documentos

hipertexto en formato ASCII.

 Permite formatear texto, integrar imágenes, referenciar otros documentos, etc.

 HTTP: Hypertext Transfer Protocol.
 Protocolo que permite a los componentes web (cliente, servidores, etc) comunicarse
de una forma estándar y bien definida.
 Define el formato y el significado de los mensajes intercambiados entre componentes
web.

Codificación URI : Identifica de forma única el recurso.

2 Tipos:
URN: Uniform Resource Name.

 Identifica de forma única el recurso, independientemente de donde resida (RFC 2141).

 El mismo recurso situado en máquinas diferentes poseen el mismo identificador.
 Todavía está en fase experimental.

URL: Uniform Resource Locator.

 La forma más común de identificar el recurso.

 Señala exactamente donde se encuentra el recurso.
 3 partes principales:
 esquema + servidor + nombre del recurso.
URL Sintáxis:

 esquema://[usuario];[password]@<maquina>:[puerto]/<camino>;[parametros]?[consulta
]#[sección]
 Esquema: protocolo (http, https, file, ftp, news, mailto, ..).
 Usuario:password: para recursos de acceso restringido
 Máquina: nombre del servidor
 Puerto: número del puerto donde escucha el servidor.
 Camino: Directorio virtual y nombre del recurso.
 Parámetros: pares nombre=valor utilizados por algunos esquemas.
 Consulta: pares nombre=valor separados por &, utilizados en algunas aplicaciones
web.
 Sección: nombre de una parte del recurso.

Ejemplos:

 http://www.hardware.com:2000/pc/check.cgi?item=1273&model=B
 ftp://jose:suclave@www.hardware.com/informacion.txt

Conjunto de caracteres de la URL

La URL ha sido diseñada para ser portable.
Los caracteres especiales incluidos en la URL son transformados antes de ser enviados:

 Los caracteres de letras y números de la tabla ASCII estándar se dejan intactos.

 Los espacios en blanco son sustituidos por +.
 Los caracteres especiales son sustituidos por su valor hexadecimal con el prefijo '%‘.
 Los caracteres con un significado especial (“+”, “&” , “=”, “;” , “/”, “?”, “#”, etc. ) son
también sustituidos por su código hexadecimal.

Ejemplo
Núñez & Cía. ? N%FA%F1ez+%26+C%EDa

2. Componentes software de la Web.

Arquitectura Cliente/Servidor
El modelo cliente-servidor es una aquitectura software que involucra uno o más clientes
solicitando servicios a uno o más servidores.

 El cliente puede ser un proceso corriendo en un computadora o en un dispositivo como

una PDA o un teléfono móvil.
 El servidor p uede ser un proceso corriendo en un computadora (normalmente de altas
prestaciones).
 En la arquitectura Web actual aparecen además elementos que se sitúan en medio
(proxies, cachés)

Beneficios:
 Usabilidad/flexibilidad/interoperabilidad/ escalabilidad.

Clientes
Originan el trafico web.

 Envían las peticiones y reciben las respuestas.

Dos clases de clientes web: navegadores y robots.

Los navegadores (Netscape, IE, etc).

 Las peticiones están dirigidas por el usuario.

 Repiten peticiones al mismo objeto cuando navegan por un site.
 Utilizan caches de memoria y disco.

Robots (spiders, y agentes inteligentes).

 Las peticiones son automatizadas.

 La velocidad y carga está limitada por la velocidad de proceso, y por la velocidad de la
red.

Navegadores
Programa que realiza las peticiones, a solicitud de un usuario, y recibe, analiza y presenta
las respuestas.
Pasos:
Funciones de los navegadores
Construyen y mandan la petición HTTP
Reciben, interpretan y presentan la respuesta.

 La apariencia final depende de los parámetros de configuración

 Algunos recursos precisan aplicaciones de ayuda para visualizarse

Código MIME
Proporcionan el interfaz para conectarse y utilizar otros servicios: mail, news, ftp, etc.

 El protocolo por defecto es http.

Caché local.

 Sirve recursos guardados en la caché sin conectarse al servidor.

 Consistencia:

Fuerte: revalida siempre el recurso conectándose al servidor.

Débil: se basa en los parámetros HTTP, y en los parámetros de configuración, para
decidir si es necesario revalidar el recurso.

 Manejo de las Cookies.

Spiders
Robots dedicados a la b úsqueda automática de información.

 Parten de la página principal de un sitio web, y examinan los enlaces embebidos que
encuentran.
 Las peticiones están espaciadas en el tiempo para no sobrecargar el servidor.
La información se utiliza posteriormente en aplicaciones de búsqueda (google, yahoo).
Los recursos dinámicos (CGI, PHP, etc.) no son indexados.
Algunos sitios web no desean ser indexados:

 Controlan el acceso de robots.

 Los recursos HTML incluyen una directiva META:

<META NAME=“ROBOTS” CONTENT=“NOINDEX, NOFOLLOW”>

Servidores
Programa que contesta y genera la respuesta HTTP a las peticiones de recursos web por
parte del cliente

 Involucra múltiples servidores, scripts, bases de datos, ..

Trabajo básico:

 Se conecta con el cliente.

 Recibe el mensaje HTTP de la petición.
 Procesa el mensaje HTTP.
 Localiza y envía el resultado (en forma de mensaje HTTP)

Los servidores de altas prestaciones, además:

 Tratan múltiples peticiones: hilos para manejar cada conexión.

 Generan dinámicamente contenido: ASP, PHP, JSP
 Caché.

Los más populares son Apache e IIS.

Manejo de las peticiones
Los servidores proveen acceso a los recursos:

 Estáticos.
 Dinámicos (scripts que generan la respuesta dinámicamente).

Pasos:

 Lee e interpreta el mensaje de petición (método, URL, cookies,..)

 Localiza físicamente el recurso apuntado en la URL
 Determina si el cliente está autorizado (controla el acceso)
 Genera el mensaje de respuesta y lo transmite (cookies)
 Registra la operación en un fichero de log

Controlan el acceso a recursos restringidos:

 Autenticación.

Piden al usuario que se identifique (login y password)

La información se incluye en la cabecera del mensaje.
 Autorización.

Comprueba en su lista de acceso si el usuario está autorizado.

Recursos dinámicos
El contenido se crea tras recibir la petición.

 El recurso apuntado en la URL incluye código que debe ser ejecutado para resolver el
contenido de la respuesta.

Dos tipos:

 Scripts de servidor (PHP, ASP, JSP)

Ficheros HTML que incluyen macros que el servidor (un módulo) interpreta para
insertar la información precisa.
El servidor reconoce este tipo de recursos por la extensión

 Programas independientes (CGI, Servlets)

Programa separado del servidor que genera la respuesta.

Fórmulas:
Procesos separados (CGI). Pueden ser persistentes (FastCGI).
Módulos software en el mismo proceso (Servlets).

3. Arquitectura de las aplicaciones Web

Aplicaciones Web
Una aplicación web es proporcionada por un servidor
web y utilizada por usuarios que se conectan desde
cualquier punto vía clientes web (navegadores).
Definición:

 Son aplicaciones basadas en el modelo Cliente/Servidor que gestionan servidores

web, y que utilizan como interfaz páginas web.
 La colección de páginas son en una buena parte dinámicas (ASP, PHP, etc.), y están
agrupadas lógicamente para dar un servicio al usuario.
 El acceso a las páginas está agrupado también en el tiempo (sesión).
 Ejemplos: venta de libros, reserva de billetes, etc.

Componentes de una aplicación Web

Lógica de negocio.

 Parte más importante de la aplicación.

 Define los procesos que involucran a la aplicación.
 Conjunto de operaciones requeridas para proveer el servicio.

Administración de los datos.

 Manipulación de BD y archivos.
Interfaz:
Los usuarios acceden a través de navegadores, móviles, PDAs,etc.

 Funcionalidad accesible a través del navegador.

 Limitada y dirigida por la aplicación.

Modelo de capas
Las aplicaciones web se modelizan mediante lo que se conoce como modelo de capas.

 ? Una capa representa un elemento que procesa o trata información.

Tipos:

 Modelo de dos capas: La información atraviesa dos capas entre la interfaz y la

administración de los datos.
 Modelo de n-capas: La información atraviesa varias capas.
 El más habitual es el modelo de tres capas.

Modelo de dos Capas.

Gran parte de la aplicación corre en el lado del cliente (fat client).
Capas:

 Cliente (fat client): La lógica de negocio está inmersa dentro de la aplicación que
realiza el interfaz de usuario, en el lado del cliente.
 Servidor: Administra los datos.

Limitaciones.

 Es difícilmente escalable : Número de conexiones reducida

 Alta carga de la red.
 La flexibilidad es restringida
 La funcionalidad es limitada.

Modelo de tres Capas

Diseñada para superar las limitaciones de las arquitecturas ajustadas al modelo de dos
capas
Introduce una capa intermedia (la capa de proceso)entre presentación y los datos

 Los procesos pueden ser manejados de forma separada al interfaz de usuario y a los
datos
 La capa intermedia centraliza la lógica de negocio, haciendo la administración más
sencilla.

Pueden integrar datos de múltiples fuentes

Las aplicaciones web actuales se ajustan a este modelo.
Capas:
Capa de presentación (parte en el cliente y parte en el servidor)
 Recoge la información del usuario y la envía al servidor (cliente)
 Manda información a la capa de proceso para su procesado
 Recibe los resultados de la capa de proceso
 Generan la presentación
 Visualizan la presentación al usuario (cliente)

Capa de proceso (servidor web)

 Recibe la entrada de datos de la capa de presentación

 Interactúa con la capa de datos para realizar operaciones
 Manda los resultados procesados a la capa de presentación

Capa de datos (servidor de datos)

 Almacena los datos

 Recupera datos
 Mantiene los datos
 Asegura la integridad de los datos