INSTITUTO TECNOLOGICO LA PAZ

PROGRAMACIÓN WEB

Conceptos claves sobre aplicaciones web

ALUMNO:
Leon Tapia Jesus Manuel
14310694

MAESTRO:
Luis Armando Cárdenas Florido

LA PAZ B.C.S. 30/01/2018

HTTP
El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un sencillo
protocolo cliente-servidor que articula los intercambios de información entre los clientes Web
y los servidores HTTP. La especificación completa del protocolo HTTP 1/0 está recogida en el
RFC 1945. Propuesto por Tim Berners-Lee. Visto desde las comunicaciones es básicamente
un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el 80), y
espera las solicitudes de conexión de los clientes Web.
HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una
conexión con un servidor y envía un mensaje con los datos de la solicitud. El servidor responde
con un mensaje similar, que contiene el estado de la operación y su posible resultado. Todas
las operaciones pueden adjuntar un objeto o recurso sobre el que actúan; cada objeto Web
(documento HTML, fichero multimedia o aplicación CGI) es conocido por su URL.
Transacción HTTP:
Cada vez que un cliente realiza una petición a un servidor, se ejecutan los siguientes pasos:
 Un usuario accede a una URL, seleccionando un enlace de un documento HTML o
introduciéndola directamente en el campo Location del cliente Web.
 El cliente Web descodifica la URL, separando sus diferentes partes. Así identifica el
protocolo de acceso, la dirección DNS o IP del servidor, el posible puerto opcional (el valor
por defecto es 80) y el objeto requerido del servidor.
 Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP correspondiente.
 Se realiza la petición. Para ello, se envía el comando necesario (GET, POST, HEAD, etc.),
la dirección del objeto requerido (el contenido de la URL que sigue a la dirección del
servidor), la versión del protocolo HTTP empleada (casi siempre HTTP/1.0) y un conjunto
variable de información, que incluye datos sobre las capacidades del browser, datos
opcionales para el servidor, …
 El servidor devuelve la respuesta al cliente. Consiste en un código de estado y el tipo de
dato MIME de la información de retorno, seguido de la propia información.
 Se cierra la conexión TCP.

HTTPS
HTTP / TLS se diferencia de los URL HTTP mediante el uso de 'https' identificador de
protocolo en lugar del identificador de protocolo 'http'. El URL de ejemplo que especifica HTTP
/ TLS es: https://www.example.com/~smith/home.html
Conceptualmente, HTTP / TLS es muy simple. Simplemente use HTTP sobre TLS
precisamente como usaría HTTP sobre TCP.
El agente que actúa como cliente HTTP también debería actuar como TLS cliente. Debe iniciar
una conexión con el servidor en el puerto apropiado y luego enviar el TLS ClientHello para
comenzar el apretón de manos con TLS. Cuando el saludo de TLS ha terminado. El cliente
puede entonces iniciar la primera solicitud HTTP. Todos los datos HTTP deben enviarse como
"Datos de la aplicación" TLS.
TLS proporciona una instalación para el cierre seguro de la conexión. Cuando es válido se
recibe una alerta de cierre, se puede asegurar una implementación que no se recibirán más
datos sobre esa conexión. Las implementaciones TLS deben iniciar un intercambio de alertas
de cierre antes de cerrar una conexión. Una implementación de TLS puede, después de enviar
una alerta de cierre, cerrar la conexión sin esperar que el interlocutor envíe su alerta de cierre,
generando un "cierre incompleto".
Esto debe hacerse solo cuando la aplicación sepa (típicamente a través de la detección de
límites de mensajes HTTP) que ha recibido todos los datos del mensaje que le interesan.
Como se especifica en [ RFC2246], cualquier implementación que reciba una conexión
cerrada sin recibir primero una alerta de cierre válida (un "cierre prematuro") NO DEBE
reutilizar esa sesión. Tenga en cuenta que un cierre prematuro no cuestiona la seguridad de
los datos ya recibidos, pero simplemente indica que los datos posteriores podrían ser
truncados porque TLS es ajeno a los límites de solicitud / respuesta de HTTP, es necesario
examinar los datos HTTP (específicamente el encabezado Content-Length) para determinar
si el truncamiento ocurrió dentro de un mensaje o entre mensajes.

FTP
FTP es un protocolo estándar con el STD 9. Su status es recomendado. Se describe en el
RFC 959 - FTP ("File Transfer Protocol").
Para acceder a ficheros remotos, el usuario debe identificarse al servidor. En este punto el
servidor es responsable de autentificar al cliente antes de permitir la transferencia de ficheros.
Desde el punto de vista de un usuario de FTP, el enlace está orientado a conexión. En otras
palabras, es necesario que ambos hosts estén activos y ejecutando TCP/IP para establecer
una transferencia de ficheros.
FTP usa TCP como protocolo de transporte para proporcionar conexiones fiables entre los
extremos. Se emplean dos conexiones: la primera es para el login y sigue el protocolo TELNET
y la segunda es para gestionar la transferencia de datos. Como es necesario hacer un login
en el host remoto, el usuario debe tener un nombre de usuario y un password para acceder a
ficheros y a directorios. El usuario que inicia la conexión asume la función de cliente, mientras
que el host remoto adopta la función de servidor
En ambos extremos del enlace, la aplicación FTP se construye con intérprete de protocolo(PI),
un proceso de transferencia de datos, y una interfaz de usuario.
La interfaz de usuario se comunica con el PI, que está a cargo del control de la conexión. Este
intérprete de protocolo ha de comunicar la información necesaria a su propio sistema de
archivos.
En el otro extremo de la conexión, el PI, además de su función de responder al protocolo
TELNET, ha de iniciar la conexión de datos. Durante la transferencia de ficheros, los DTPs se
ocupan de gestionar la transferencia de datos. Una vez que la operación del usuario se ha
completado, el PI ha de cerrar la conexión de control.
SMTP
El correo electrónico (E-mail) es probablemente la aplicación TCP/IP más usada. Los
protocolos de correo básicos de correo proporcionan intercambio de correo y mensajes entre
hosts TCP/IP hosts; se han añadido servicios para la transmisión de datos que no se pueden
representar con texto ASCII de 7 bits.
Hay tres protocolos estándares que se aplican a este tipo de correo. Todos son
recomendados. El término SMTP se emplea con frecuencia para referirse a la combinación de
los tres protocolos, por su estrecha interrelación, pero estrictamente hablando, SMTP es sólo
uno de los tres.

Flujo de transacción de correo de SMTP:

Aunque los comandos y réplicas de correo están definidas rígidamente, el intercambio se
puede seguir en Figura - Flujo de datos normal de SMTP. Todos los comandos, réplicas o
datos intercambiados son líneas de texto, delimitadas por un <CRLF>. Todas las réplicas
tienen un código numérico el comienzo de la línea.
 El emisor SMTP establece una conexión TCP con el SMTP de destino y espera a que el
servidor envíe un mensaje "220 Service ready" o "421 Service not available" cuando el
destinatario es temporalmente incapaz de responder.
 Se envía un HELO (abreviatura de "hello"), con el que el receptor se identificará
devolviendo su nombre de dominio. El SMTP emisor puede usarlo para verificar si contactó
con el SMTP de destino correcto.
 Si el emisor SMTP soporta las extensiones de SMTP definidas en el RFC 1651, puede
sustituir el comando HELO por EHLO. Un receptor SMTP que no soporte las extensiones
responderá con un mensaje "500 Syntax error, command unrecognized". El emisor SMTP
debería intentarlo de nuevo con HELO, o si no puede retransmitir el mensaje sin
extensiones, enviar un mensaje QUIT.
Si un receptor SMTP soporta las extensiones de servicio, responde con un mensaje multi-
línea 250 OK que incluye una lista de las extensiones de servicio que soporta.
 El emisor inicia ahora una transacción enviando el comando MAIL al servidor. Este
comando contiene la ruta de vuelta al emisor que se puede emplear para informar de
errores. Nótese que una ruta puede ser más que el par buzón@nombre de dominio del
host. Además, puede contener una lista de los hosts de encaminamiento. Si se acepta, el
receptor replica con un "250 OK".
 El segundo paso del intercambio real de correo consiste en darle al servidor SMTP el
destino del mensaje (puede haber más de un receptor). Esto se hace enviando uno o más
comandos RCPT TO:<forward-path>. Cada uno de ellos recibirá una respuesta "250 OK"
si el servidor conoce el destino, o un "550 No such user here" si no.
 Cuando se envían todos los comandos rcpt, el emisor envía un comando DATA para
notificar al receptor que a continuación se envían los contenidos del mensaje. El servidor
replica con "354 Start mail input, end with <CRLF>.<CRLF>". Nótese que se trata de la
secuencia de terminación que el emisor debería usar para terminar los datos del mensaje.
 El cliente envía los datos línea a línea, acabando con la línea <CRLF>. <CRLF> que el
servidor reconoce con "250 OK" o el mensaje de error apropiado si cualquier cosa fue mal.
 Ahora hay varias acciones posibles:
o El emisor no tiene más mensajes que enviar; cerrará la conexión con un comando QUIT,
que será respondido con "221 Service closing transmission channel".
o El emisor no tiene más mensajes que enviar, pero está preparado para recibir mensajes
(si los hay) del otro extremo. Mandará el comando TURN. Los dos SMTPs intercambian
sus papeles y el emisor que era antes receptor puede enviar ahora mensajes
empezando por el paso 3 de arriba.
o El emisor tiene otro mensaje que enviar, y simplemente vuelve al paso 3 para enviar un
nuevo MAIL.
Las especificaciones básicas del protocolo SMTP indican que todos los caracteres enviados
están codificados mediante el código ASCII de 7 bits y que el 8.º bit sea explícitamente cero.
Por lo tanto, para enviar caracteres acentuados es necesario recurrir a algoritmos que se
encuentren dentro de las especificaciones MIME: base64 para archivos adjuntos y quoted-
printable (abreviado QP) para caracteres especiales utilizados en el cuerpo del mensaje.

POP3
El protocolo POP (Protocolo de oficina de correos), como su nombre lo indica, permite recoger
el correo electrónico en un servidor remoto (servidor POP). Es necesario para las personas
que no están permanentemente conectadas a Internet, ya que así pueden consultar sus
correos electrónicos recibidos sin que ellos estén conectados.
Existen dos versiones principales de este protocolo, POP2 y POP3, a los que se le asignan
los puertos 109 y 110 respectivamente, y que funcionan utilizando comandos de texto
radicalmente diferentes.
Al igual que con el protocolo SMTP, el protocolo POP (POP2 y POP3) funciona con comandos
de texto enviados al servidor POP. Cada uno de estos comandos enviados por el cliente
(validados por la cadena CR/LF) está compuesto por una palabra clave, posiblemente
acompañada por uno o varios argumentos, y está seguido por una respuesta del servidor POP
compuesta por un número y un mensaje descriptivo.
POP3 administra la autenticación utilizando el nombre de usuario y la contraseña. Sin
embargo, esto no es seguro, ya que las contraseñas, al igual que los correos electrónicos,
circulan por la red como texto sin codificar (de manera no cifrada). En realidad, según RFC
1939, es posible cifrar la contraseña utilizando un algoritmo MD5 y beneficiarse de una
autenticación segura. Sin embargo, debido a que este comando es opcional, pocos servidores
lo implementan. Además, el protocolo POP3 bloquea las bandejas de entrada durante el
acceso, lo que significa que es imposible que dos usuarios accedan de manera simultánea a
la misma bandeja de entrada.
SNMP
Simple Network Management Protocol (SNMP). Diseñado en los años 80, su principal
objetivo fue el integrar la gestión de diferentes tipos de redes mediante un diseño sencillo y
que produjera poca sobrecarga en la red.

SNMP opera en el nivel de aplicación, utilizando el protocolo de transporte TCP/IP, por lo

que ignora los aspectos específicos del hardware sobre el que funciona. La gestión se lleva
a cabo al nivel de IP, por lo que se pueden controlar dispositivos que estén conectados en
cualquier red accesible desde la Internet, y no únicamente aquellos localizados en la propia
red local. Evidentemente, si alguno de los dispositivos de encaminamiento con el dispositivo
remoto a controlar no funciona correctamente, no será posible su monitorización ni
reconfiguración.

El protocolo SNMP está compuesto por dos elementos: el agente (agent), y el gestor
(manager). Es una arquitectura cliente-servidor, en la cual el agente desempeña el papel de
servidor y el gestor hace el de cliente.

El agente es un programa que ha de ejecutase en cada nodo de red que se desea gestionar
o monitorizar. Ofrece un interfaz de todos los elementos que se pueden configurar. Estos
elementos se almacenan en unas estructuras de datos llamadas "Management Information
Base" (MIB), se explicarán más adelante. Representa la parte del servidor, en la medida que
tiene la información que se desea gestionar y espera comandos por parte del cliente.

El gestor es el software que se ejecuta en la estación encargada de monitorizar la red, y su

tarea consiste en consultar los diferentes agentes que se encuentran en los nodos de la red
los datos que estos han ido obteniendo.

Hay un comando especial en SNMP, llamado trap, que permite a un agente enviar datos que
no han sido solicitados de forma explícita al gestor, para informar de eventos tales como:
errores, fallos en la alimentación eléctrica, etc.

En esencia, el SNMP es un protocolo muy sencillo puesto que todas las operaciones se
realizan bajo el paradigma de carga-y-almacenamiento (load-and-store), lo que permite un
juego de comandos reducido. Un gestor puede realizar sólo dos tipos diferentes de
operaciones sobre un agente: leer o escribir un valor de una variable en el MIB del agente.
Estas dos operaciones se conocen como petición-de-lectura (get-request) y petición-de-
escritura (set-request). Hay un comando para responder a una petición-de-lectura llamado
respuesta-de-lectura (get-response), que es utilizado únicamente por el agente.

La posibilidad de ampliación del protocolo está directamente relacionada con la capacidad

del MIB de almacenar nuevos elementos. Si un fabricante quiere añadir un nuevo comando
a un dispositivo, como puede ser un encaminador, tan sólo tiene que añadir las variables
correspondientes a su base de datos (MIB).

Casi todos los fabricantes implementan versiones agente de SNMP en sus dispositivos:
encaminadores, hubs, sistemas operativos, etc. Linux no es una excepción, existen varios
agentes SNMP disponibles públicamente en la Internet.
DNS
Un servidor DNS (Domain Name System - Sistema de nombres de dominio) es un servidor
que traduce nombres de dominio a IPs y viceversa. En las redes TCP/IP, cada PC dispone de
una dirección IP para poder comunicarse con el resto de PCs.

Es equivalente a las redes de telefonía en las que cada teléfono dispone de un número de
teléfono que le identifica y le permite comunicarse con el resto de teléfonos.

Trabajar con direcciones IP es incómodo para las personas, ya que requeriría conocer en todo
momento las direcciones IP de los equipos a los que queremos conectarnos. En su lugar
utilizamos nombres de dominio que son más fáciles de recordar y utilizar como por ejemplo
www.google.es, www.educacion.gob.es, etc...

Cada equipo y cada servidor conectado a Internet, dispone de una dirección IP y de un nombre
perteneciente a un dominio. Internamente, la comunicación entre los PCs se realiza utilizando
direcciones IP por eso es necesario algún sistema que permita, a partir de los nombres de los
PCs, averiguar las direcciones IPs de los mismos. Ejemplo, cuando queremos acceder a la
página web del Ministerio de Educación, en la barra de direcciones del navegador escribimos:

http://www.educacion.gob.es

Nuestro PC tendrá que averiguar cuál es la IP correspondiente a www.educacion.gob.es y una

vez que ha averiguado que su IP es 193.147.0.112, se conecta con el servidor para adquirir
la página web principal y mostrarla al usuario. Si en el navegador escribimos:

http://193.147.0.112

Ahorraremos el paso de averiguar la IP y directamente nos mostrará la página web del

Ministerio de Educación. Un servidor DNS es un servidor que permite averiguar la IP de un
PC a partir de su nombre. Para ello, el servidor DNS dispone de una base de datos en la cual
se almacenan todas las direcciones IP y todos los nombres de los PCs pertenecientes a su
dominio.

No existe una base de datos única donde se almacenan todas las IPs existentes en el mundo,
sino que cada servidor almacena las IPs correspondientes a su dominio. Los servidores DNS
están dispuestos jerárquicamente de forma que cuando nuestro servidor más inmediato no
puede atender nuestra petición, éste la traslada al DNS superior.

En el proceso de resolución de un nombre, hay que tener en cuenta que los servidores DNS
funcionan frecuentemente como clientes DNS, consultando a otros servidores para resolver
completamente un nombre consultado. Muchas implementaciones de DNS proporcionan tres
utilidades bastante comunes para consultar a servidores de nombres:

 Host:
Obtiene una dirección IP asociada con un nombre de host o un nombre de host
asociado con una dirección IP.
  Nslookup:
Permite localizar información acerca de los nodos de red, examinar los contenidos de
la base de datos de un servidor de nombres y establecer la accesibilidad a servidores
de nombres.

 dig("Domain Internet Groper"):

Permite probar los servidores de nombres, reunir grandes volúmenes de información
de nombres de dominio y ejecutar simples consultas de nombres de dominio.

Sockets
Los sockets son una forma de comunicación entre procesos que se encuentran en diferentes
máquinas de una red, los sockets proporcionan un punto de comunicación por el cual se
puede enviar o recibir información entre procesos.
Los sockets tienen un ciclo de vida dependiendo si son sockets de servidor, que esperan a
un cliente para establecer una comunicación, o socket cliente que busca a un socket de
servidor para establecer la comunicación.

Hay dos tipos de socket:

Orientado a conexión:
 Establece un camino virtual entre servidor y cliente, fiable, sin pérdidas de información
ni duplicados, la información llega en el mismo orden que se envía.
 El cliente abre una sesión en el servidor y este guarda un estado del cliente.

o El cliente utiliza la clase Socket

o El servidor utiliza la clase ServerSocket

Clase Descripción
Socket Esta clase implementa sockets del cliente

Un socket es uno de los extremos en la comunicación entre dos máquinas.

ServerSocket Esta clase implementa sockets del servidor. Un socket del servidor espera
a que una solicitud provenga de la red; lleva a cabo determinadas
operaciones basadas en la solicitud recibida; y entonces, posiblemente,
retorna un resultado al solicitante.

No orientado a conexión:

 Envío de datagramas de tamaño fijo. No es fiable, puede haber pérdidas de

información y duplicados, y la información puede llegar en distinto orden del que se
envía.
 No se guarda ningún estado del cliente en el servidor, por ello, es más tolerante a
fallos del sistema.
o Tanto el cliente como el servidor utilizan la clase DatagramSocket.

Clase Descripción
DatagramSocket Esta clase representa un socket para enviar y recibir paquetes
datagrama.
Bibliografía
http://neo.lcc.uma.es/evirtual/cdd/tutorial/aplicacion/http.html

https://tools.ietf.org/html/rfc2818#page-2

http://neo.lcc.uma.es/evirtual/cdd/tutorial/aplicacion/ftp.html

http://es.ccm.net/contents/279-protocolos-de-mensajeria-smtp-pop3-e-
imap4

http://www.ite.educacion.es/formacion/materiales/85/cd/linux/m2/servid
or_dns.html

http://dsp.mx/blog/sistemas-de-informacion/49-sockets-tcp-udp

http://neo.lcc.uma.es/evirtual/cdd/tutorial/aplicacion/smtp.html

http://redesdecomputadores.umh.es/aplicacion/snmp.htm