HTTP y HTTPS

Evolución del protocolo HTTP
HTTP es el protocolo en el que se basa la Web.
Fue inventado por Tim Berners-Lee entre los años 1989-1991,
HTTP ha evolucionado, desde un protocolo destinado al intercambio de archivos en

un entorno de un laboratorio semi-seguro, al actual laberinto de Internet, sirviendo
ahora para el intercambio de imágenes, vídeos en alta resolución y en 3D.
DATO CURIOSO
Invención de la World Wide Web

En 1989, Tim Berners-Lee escribió una propuesta para desarrollar un sistema de
hipertexto sobre Internet. Inicialmente lo llamó: 'Mesh' (malla, en inglés), y
posteriormente se renombró como World Wide Web (red mundial), durante su
implementación en 1990. Desarrollado sobre los protocolos existentes TCP e IP,
está basado en cuatro bloques:
 Un formato de texto para representar documentos de hiper-texto: HyperText

Markup Language (HTML).
 Un protocolo sencillo para el intercambio de esos documentos,
del inglés: HypertText Transfer Protocol (HTTP) : protocolo de transferencia de
hiper-texto.
 Un cliente que muestre (e incluso pueda editar) esos documentos. El primer
navegador Web, llamado: WorldWideWeb.
 Un servidor para dar acceso a los documentos, una versión temprana: httpd (http
daemon)
Estos cuatro bloques fundamentales se finalizaron para finales de 1990, y los
primeros servidores estaban ya funcionando a principios del 1991.
El 6 de Agosto de 1991, el post de Tim Berners-Lee, se considera actualmente

como el inicio oficial de la Web como proyecto público.
HTTP/0.9 – El protocolo de una sola línea

La versión inicial de HTTP, no tenía número de versión; aunque posteriormente se
la denominó como 0.9 para distinguirla de las versiones siguientes. HTTP/0.9 es un
protocolo extremadamente sencillo: una petición consiste simplemente en una
única linea, que comienza por el único método posible GET, seguido por la dirección
del recurso a pedir (no la URL, ya que tanto el protocolo, el servidor y el puerto, no
son necesarios una vez ya se ha conectado al servidor).
GET /miPaginaWeb.html
La respuesta también es muy sencilla: solamente consiste el archivo pedido.
<HTML>
Una pagina web muy sencilla
</HTML>
Al contrario que sus posteriores evoluciones, el protocolo HTTP/0.9 no usa

cabeceras HTTP, con lo cual únicamente es posible transmitir archivos HTML, y
ningún otro tipo de archivos. Tampoco había información del estado ni códigos de
error: en el caso un problema, el archivo HTML pedido, era devuelto con una
descripción del problema dentro de él, para que una persona pudiera analizarlo.
HTTP/1.0 – Desarrollando expansibilidad

La versión HTTP/0.9 era ciertamente limitada y tanto los navegadores como los
servidores, pronto ampliaron el protocolo para que fuera más flexible.
 La versión del protocolo se envía con cada petición: HTTP/1.0 se añade a la línea
de la petición GET.
 Se envía también un código de estado al comienzo de la respuesta, permitiendo así
que el navegador pueda responder al éxito o fracaso de la petición realizada, y
actuar en consecuencia (como actualizar el archivo o usar la caché local de algún
modo).
 El concepto de cabeceras de HTTP, se presentó tanto para las peticiones como
para las respuestas, permitiendo la trasmisión de meta-data y conformando un
protocolo muy versátil y ampliable.
 Con el uso de las cabeceras de HTTP, se pudieron transmitir otros documentos
además de HTML, mediante la cabecera Content-Type.
Una petición normal, sigue la estructura:
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT

Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
Una pagina web con una imagen
<IMG SRC="/miImagen.gif">
</HTML>
Continua con una segunda conexión y la petición de una imagen:
GET /myImagen.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)
Estas innovaciones, no se desarrollaron de forma planeada, sino más bien con una
aproximación de prueba y error, entre los años 1991 y 1995: un servidor y un
navegador, añadían una nueva funcionalidad y se evaluaba su aceptación. Debido
a esto, en ese periodo eran muy comunes los problemas de interoperatividad. En
Noviembre de 1996, para poner fin a estos problemas se publicó un documento
informativo que describía las prácticas adecuadas, RFC 1945. Esté documento es
la definición del protocolo HTTP/1.0. Resulta curioso, que realmente no es un
estándar oficial.
HTTP/1.1 – El protocolo estándar.

En paralelo al uso, un poco desordenado, y las diversas implementaciones de
HTTP/1.0, y desde el año 1995, un año antes de la publicación del documento del
HTTP/1.0, un proceso de estandarización formal ya estaba en curso. La primera
versión estandarizada de HTTP: el protocolo HTTP/1.1, se publicó en 1997, tan
solo unos meses después del HTTP/1.0
HTTP/1.1 aclaró ambigüedades y añadió numerosas mejoras:
 Una conexión podía ser reutilizada, ahorrando así el tiempo de re-abrirla repetidas

veces para mostrar los recursos empotrados dentro del documento original pedido.
 Enrutamiento ('Pipelining' en inglés) se añadió a la especificación, permitiendo
realizar una segunda petición de datos, antes de que fuera respondida la primera,
disminuyendo de este modo la latencia de la comunicación.
 Se permitió que las respuestas a peticiones, podían ser divididas en sub-partes.
 Se añadieron controles adicionales a los mecanismos de gestión de la cache.
 La negociación de contenido, incluyendo el lenguaje, el tipo de codificación, o tipos,
se añadieron a la especificación, permitiendo que servidor y cliente, acordasen el
contenido más adecuado a intercambiarse.
 Gracias a la cabecera, Host, pudo ser posible alojar varios dominios en la misma
dirección IP.
El flujo normal de una serie de peticiones y respuestas, bajo una única conexión,
se expone a continuación:
GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0)

Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
(...contenido...)
GET /static/img/header-background.png HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0)

Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache
(image content of 3077 bytes)
HTTP/1.1 fue publicado inicialmente como RFC 2068 en Enero de 1997.
Más de 15 años de expansiones

Gracias a su expansibilidad - ya que la creación de nuevas cabeceras o métodos
es sencilla - e incluso teniendo en cuenta que el protocolo HTTP/1.1 fue mejorado
en dos revisiones: la primera, el documento RFC 2616, publicado en Junio de 1999
y posteriormente en los documentos RFC 7230-RFC 7235 publicados en Junio del
2014, en previsión de la publicación de HTTP/2. Así pues, el protocolo
HTTP/1.1 ha sido increíblemente estable durante más de 15 años.
El uso de HTTP para transmisiones seguras
El mayor cambio en el desarrollo de HTTP, fue a finales de 1994. En vez de

trasmitir HTTP sobre la capa de TCP/IP, se creo una capa adicional sobre esta:
SSL. La versión SSL 1.0 nunca fue publicada fuera de las compañías
desarrolladoras, pero el SSL 2.0 y sus sucesoras SSL 3.0 y SSL 3.1 permitieron la
creación del comercio electrónico en la Web (e-commerce), encriptando y
garantizando la autenticidad de los mensajes intercambiados entre servidor y
cliente. SSL se añadió a la lista de estándares y posteriormente evolucionó hasta
ser el protocolo TLS, con versiones 1.0, 1.1 y 1.2, que fueron apareciendo para
resolver vulnerabilidades. Actualmente se está desarrollando el protocolo TLS 1.3.
Durante el mismo periodo, la necesidad por una capa de trasporte encriptada

aumentó; la Web, que permitía una relativa confianza de lo que era una mayoría de
trabajo académico, pasó a ser una jungla donde anuncios, individuos aleatorios o
criminales competían para obtener tanta información privada sobre la gente como
pudieran, o trataban de suplantarlos o incluso sustituir los datos trasmitidos por
otros alterados. A medida que hubo aplicaciones que se desarrollaban y
funcionaban sobre HTTP, fueron más y más funcionales, tener acceso a más y
mayor información personal como contactos, e-mails, o posición geográfica del
usuario, la necesidad de tener el protocolo TLS, fue fundamental incluso fuera del
ámbito del comercio electrónico.
Uso de HTTP para aplicaciones complejas
La visión original de Tim Berners-Lee para la Web no era solo un medio de 'solo'
lectura. Él había visionado una Web donde la gente pudiese añadir y mover
documentos de forma remota, un estilo de sistema de archivos distribuido. Sobre el
año 1996, HTTP se había desarrollado para permitir la autoría, y fue creado
un estándar denominado WebDAB. Este fue más tarde ampliado por aplicaciones
especificas como CardDAV, para permitir libros de direcciones, y CalDAV para
trabajar con calendarios. Pero todos estas extensiones '*DAV', tenían una
debilidad, y es que debian ser implementadas por los servidores, para poder ser
usadas, lo cual era bastante complejo. Así pues su uso en la Web fue bastante
acotado.
En el año 2000, un nuevo formato para usar HTTP fue diseñado: REST (del
inglés: 'Representational State Transfer'). Las acciones de la nueva API, no
estaban supeditadas a nuevos métodos HTTP, unicamente al acceso a URIs
especificas con métodos HTTP/1.1). Esto permitió que cualquier aplicación Web
dispusiera de una API, para permitir la recuperación y modificación de datos, sin
tener que actualizar servidores o navegadores; todo lo que se necesitaba era
incluido en los archivos servidos por los sitios Web. La contrapartida del modelo
REST está en que cada sitio Web define su propia versión no estándar de API
RESTful y tiene un control total sobre ella; al contrario del formato *DAV donde
clientes y servidores eran interoperables. La arquitectura REST empezó a ser muy
común a partir del año 2010.
Desde el año 2005, las APIs disponibles para páginas Web a aumentado
considerablemente, y muchas de estas nuevas APIs dependen de cabeceras
HTTP específicas para funciones concretas:
 Eventos enviados por el servidor: El servidor es el que ocasionalmente inicia los

mensajes hacia el navegador.
 WebSocket, un nuevo protocolo que puede establecerse actualizando una
conexión HTTP existente.
Relajación del modelo de seguridad de la Web
El protocolo HTTP es independiente del modelo de seguridad de la Web: la política

del mismo origen. De hecho, el actual modelo de seguridad de la Web, ha sido
desarrollado con posterioridad a la creación del protocolo HTTP. A lo largo de los
años, se ha probado útil, poder ser más permisivo con ella, permitiendo que bajo
ciertos requerimientos se puedan levantar algunas de las restricciones de esta
política. Cuanto y cuantas de estas restricciones se pueden saltar es comunicado
desde el servidor al cliente, mediante una serie de nuevas cabeceras HTTP. Estas
están especificadas en los documentos como CORS ( del inglés Cross-Origin
Resource Sharing, que viene a significar: recursos compartidos de orígenes
cruzados) y el CSP (del inglés: Content Security Policy , que traducido es: política
de seguridad de contenidos).
Además de estas ampliaciones, muchas otras cabeceras han sido añadidas,

algunas unicamente experimentales. Algunas de ellas notables son: Do Not Track
(DNT (en-US)); cabecera de control de privacidad: X-Frame-Options, y Upgrade-
Insecure-Requests (en-US).
HTTP/2 – Un protocolo para un mayor rendimiento

A lo largo de los años, las páginas Web han llegado a ser mucho más complejas,
incluso llegando a poder considerarse como aplicaciones por derecho propio. La
cantidad de contedio visual, el tamaño de los scripts, y los scripts que añaden
interactividad ha aumentado mucho también. Muchismos más datos son
transmitidos bajo muchas mas peticiónes HTTP. Las conexiones HTTP/1.1 han de
enviar las peticiones HTTP en el orden correcto. Teóricamente, seria posible usar
varias conexiones en paralelo (normalmente entre 5 y 8), aumentando
consecuentemente la complejidad del proceso. Por ejemplo, el HTTP 'pipelining' ha
demostrado ser un lastre para el desarrollo Web.
En la primera mitad de la década de 2010, Google demostró un proceso alternativo

para el intercambio de data entre clientes y servidores, implementando el protocolo
experimental SPDY (pronunciado como en inglés 'speedy'). Este atrajo mucho
interés por los desarrolladores de tanto los navegadores como los servidores.
Definiendo una mejora en los tiempos de respuesta, y resolviendo el problema de
datos duplicados transmitidos. SPDY sirvió como base para el desarrollo del
protocolo HTTP/2.
El protocolo HTTP/2, tiene notables diferencias fundamentales respecto a la

versión anterior HTTP/1.1
 Es un protocolo binario, en contraposición a estar formado por cadenas de texto, tal

y como estában basados sus protocolos anteriores. Así pues no se puede leer
directamente, ni crear manualmente A pesar de este inconveniente, gracias a este
cambio es posible utilizar en él técnicas de optimización.
 Es un protocolo multiplexado. Peticiones paralelas pueden hacerse sobre la misma
connexión, no está sujeto pues a mantener el orden de los mensajes, ni otras
restricciónes que tenian los protocolos anteriores HTTP/1.x
 Comprime las cabeceras, ya que estas, normalmente son similares en un grupo de
peticiones. Esto elimina la duplicación y retardo en los datos a transmitir.
 Esto permite al servidor almacenar datos en la caché del cliente, previamente a que
estos sean pedidos, mediante un mecanismo denominado 'server push'.
Estandarizado de manera oficial en Mayo de 2015, HTTP/2 ha conseguido muchos
éxitos. En Julio de 2016, un 8.7% de todos los sitios Web[1] estaban usandolo ya,
representando más del 68% de todo su tráfico[2]. Los sitios Web con mucho tráfico,
fueron aquellos que lo adoptaron más rápidamente, ahorrando considerablemente
las sobrecargas en la transferencia de datos, ... y en sus presupuestos.
Esta rápida adopción era esperada, ya que el uso de HTTP/2, no requiere de una

adaptación de los sitios Web y aplicaciones: el uso de HTTP/1.1 o HTTP/2 es
transparente para ellos. El uso de un servidor actual, comunicandose con un
navegador actualizado, es suficiente para permitir su uso: únicamente en casos
partículares fue necesario impulsar su utilización; y según se actualizan servidores
y navegadores antiguos, su utilización aumenta, sin que requiera un mayor
esfuerzo de los desarrolladores Web.
Post-evolución del HTTP/2

Con la publicación de la versión del protocolo HTTP/2, esté no ha dejado de
evoluciónar. Como con el HTTP/1.x, anteriormente, la extensibilidad del HTTP se
sigue usando para añadir nuevas funcionalidades. Podemos enumerar algunas de
estas nuevas características que se desarrollaron en el año 2016:
 Soporte de la cabecera Alt-Svc (en-US), la cual permite disociar la identificación de

una ubicación, con respecto a un recurso pedido, permitiendo el uso más
inteligente de los mecanismos de cacheo de memoria de los CDN.
 La introducción de la cabecera Client-Hints, que permíte al navegador, o cliente,
comunicar proactivamente al servidor, sus necesidades o restricciones de
hardware.
 La introducción de prefijos de seguridad en la cabecera Cookie, esto ayuda
a garantizar que una cookie, no ha sido alterada.
Esta evolución del HTTP demuestra su capacidad de ampliación y simplicidad,
permitiendo así de forma deliverada su uso para muchas aplicaciónes y
favoreciendo el uso de este protocolo. El entorno en el que el HTTP se usa hoy en
día, es muy distinto al que habia a principios de la década de 1990. El desarrollo
original de HTTP, ha demostrado ser una obra maestra, permitiendo a la Web
evolucionar a lo largo de un cuarto de siglo, sin la necesidad de un 'amotinamiento'.
Corrigiendo errores, y manteniendo la flexibilidad y extensibilidad que han hecho al
HTTP un éxito, la adopción del HTTP/2 tiene un brillante futuro.
Generalidades del protocolo HTTP
HTTP, de sus siglas en inglés: "Hypertext Transfer Protocol", es el nombre de un
protocolo el cual nos permite realizar una petición de datos y recursos, como
pueden ser documentos HTML. Es la base de cualquier intercambio de datos en la
Web, y un protocolo de estructura cliente-servidor, esto quiere decir que una
petición de datos es iniciada por el elemento que recibirá los datos (el
cliente), normalmente un navegador Web. Así, una página web completa resulta de
la unión de distintos sub-documentos recibidos, como, por ejemplo: un documento
que especifique el estilo de maquetación de la página web (CSS), el texto, las
imágenes, vídeos, scripts, etc...
Clientes y servidores se comunican intercambiando mensajes individuales (en

contraposición a las comunicaciones que utilizan flujos continuos de datos). Los
mensajes que envía el cliente, normalmente un navegador Web, se
llaman peticiones, y los mensajes enviados por el servidor se llaman respuestas.
Diseñado a principios de la década de 1990, HTTP es un protocolo ampliable, que
ha ido evolucionando con el tiempo. Es lo que se conoce como un protocolo de la
capa de aplicación, y se transmite sobre el protocolo TCP, o el protocolo
encriptado TLS (en-US), aunque teóricamente podría usarse cualquier otro
protocolo fiable. Gracias a que es un protocolo capaz de ampliarse, se usa no solo
para transmitir documentos de hipertexto (HTML), si no que además, se usa para
transmitir imágenes o vídeos, o enviar datos o contenido a los servidores, como en
el caso de los formularios de datos. HTTP puede incluso ser utilizado para
transmitir partes de documentos, y actualizar páginas Web en el acto.
Arquitectura de los sistemas basados en HTTP

HTTP es un protocolo basado en el principio de cliente-servidor: las peticiones son
enviadas por una entidad: el agente del usuario (o un proxy a petición de uno). La
mayoría de las veces el agente del usuario (cliente) es un navegador Web, pero
podría ser cualquier otro programa, como por ejemplo un programa-robot, que
explore la Web, para adquirir datos de su estructura y contenido para uso de un
buscador de Internet.
Cada petición individual se envía a un servidor, el cuál la gestiona y responde.

Entre cada petición y respuesta, hay varios intermediarios, normalmente
denominados proxies (en-US), los cuales realizan distintas funciones,
como: gateways o caches.
En realidad, hay más elementos intermedios, entre un navegador y el servidor que
gestiona su petición: hay otros tipos de dispositivos: como routers, modems ... Es
gracias a la arquitectura en capas de la Web, que estos intermediarios, son
transparentes al navegador y al servidor, ya que HTTP se apoya en los protocolos
de red y transporte. HTTP es un protocolo de aplicación, y por tanto se apoya
sobre los anteriores. Aunque para diagnosticar problemas en redes de
comunicación, las capas inferiores son irrelevantes para la definición del
protocolo HTTP .
Cliente: el agente del usuario
El agente del usuario, es cualquier herramienta que actué en representación del

usuario. Esta función es realizada en la mayor parte de los casos por un navegador
Web. Hay excepciones, como el caso de programas específicamente usados por
desarrolladores para desarrollar y depurar sus aplicaciones.
El navegador es siempre el que inicia una comunicación (petición), y el servidor

nunca la comienza (hay algunos mecanismos que permiten esto, pero no son muy
habituales).
Para poder mostrar una página Web, el navegador envía una petición de
documento HTML al servidor. Entonces procesa este documento, y envía más
peticiones para solicitar scripts, hojas de estilo (CSS), y otros datos que necesite
(normalmente vídeos y/o imágenes). El navegador, une todos estos documentos y
datos, y compone el resultado final: la página Web. Los scripts, los ejecuta también
el navegador, y también pueden generar más peticiones de datos en el tiempo, y el
navegador, gestionará y actualizará la página Web en consecuencia.
Una página Web, es un documento de hipertexto (HTTP), luego habrá partes del
texto en la página que puedan ser enlaces (links) que pueden ser activados
(normalmente al hacer click sobre ellos) para hacer una petición de una nueva
página Web, permitiendo así dirigir su agente de usuario y navegar por la Web. El
navegador, traduce esas direcciones en peticiones de HTTP, e interpretara y
procesará las respuestas HTTP, para presentar al usuario la página Web que
desea.
El servidor Web
Al otro lado del canal de comunicación, está el servidor, el cual "sirve" los datos

que ha pedido el cliente. Un servidor conceptualmente es una unica entidad,
aunque puede estar formado por varios elementos, que se reparten la carga de
peticiones, (load balancing), u otros programas, que gestionan otros computadores
(como cache, bases de datos, servidores de correo electrónico, ...), y que generan
parte o todo el documento que ha sido pedido.
Un servidor no tiene que ser necesariamente un único equipo físico, aunque si que
varios servidores pueden estar funcionando en un único computador. En el
estándar HTTP/1.1 y Host , pueden incluso compartir la misma dirección de IP.
Proxies
Entre el cliente y el servidor, además existen distintos dispositivos que gestionan

los mensajes HTTP. Dada la arquitectura en capas de la Web, la mayoria de estos
dispositivos solamente gestionan estos mensajes en los niveles de protocolo
inferiores: capa de transporte, capa de red o capa física, siendo así transparentes
para la capa de comunicaciones de aplicación del HTTP, además esto aumenta el
rendimiento de la comunicación. Aquellos dispositivos, que sí operan procesando la
capa de aplicación son conocidos como proxies. Estos pueden ser transparentes, o
no (modificando las peticiones que pasan por ellos), y realizan varias funciones:
 caching (la caché puede ser pública o privada, como la caché de un navegador)

 filtrado (como un anti-virus, control parental, ...)
 balanceo de carga de peticiones (para permitir a varios servidores responder a la
carga total de peticiones que reciben)
 autentificación (para el control al acceso de recursos y datos)
 registro de eventos (para tener un histórico de los eventos que se producen)
Características clave del protocolo HTTP
HTTP es sencillo
Incluso con el incremento de complejidad, que se produjo en el desarrollo de la

versión del protocolo HTTP/2, en la que se encapsularon los mensajes, HTTP esta
pensado y desarrollado para ser leído y fácilmente interpretado por las personas,
haciendo de esta manera más facil la depuración de errores, y reduciendo la curva
de aprendizaje para las personan que empieza a trabajar con él.
HTTP es extensible
Presentadas en la versión HTTP/1.0, las cabeceras de HTTP, han hecho que este
protocolo sea fácil de ampliar y de experimentar con él. Funcionalidades nuevas
pueden desarrollarse, sin más que un cliente y su servidor, comprendan la misma
semántica sobre las cabeceras de HTTP.
HTTP es un protocolo con sesiones, pero sin estados
HTTP es un protocolo sin estado, es decir: no guarda ningún dato entre dos
peticiones en la mísma sesión. Esto crea problemáticas, en caso de que los
usuarios requieran interactuar con determinadas páginas Web de forma ordenada
y coherente, por ejemplo, para el uso de "cestas de la compra" en páginas que
utilizan en comercio electrónico. Pero, mientras HTTP ciertamente es un protocolo
sin estado, el uso de HTTP cookies, si permite guardar datos con respecto a la
sesión de comunicación. Usando la capacidad de ampliación del protocolo HTTP,
las cookies permiten crear un contexto común para cada sesión de comunicación.
HTTP y conexiones
Una conexión se gestiona al nivel de la capa de trasporte, y por tanto queda fuera
del alcance del protocolo HTTP. Aún con este factor, HTTP no necesita que el
protocolo que lo sustenta mantenga una conexión continua entre los participantes
en la comunicación, solamente necesita que sea un protocolo fiable o que no
pierda mensajes (como mínimo, en todo caso, un protocolo que sea capaz de
detectar que se ha pedido un mensaje y reporte un error). De los dos protocolos
más comunes en Internet, TCP es fiable, mientras que UDP, no lo es. Por lo tanto
HTTP, se apoya en el uso del protocolo TCP, que está orientado a conexión,
aunque una conexión continua no es necesaria siempre.
En la versión del protocolo HTTP/1.0, habría una conexión TCP por cada
petición/respuesta intercambiada, presentando esto dos grandes inconvenientes:
abrir y crear una conexión requiere varias rondas de mensajes y por lo tanto
resultaba lento. Esto sería más eficiente si se mandaran varios mensajes.
Para atenuar estos inconvenientes, la versión del protocolo HTTP/1.1 presentó el

'pipelining' y las conexiones persistentes: el protocolo TCP que lo transmitía en la
capa inferior se podía controlar parcialmente, mediante la cabecera 'Connection'.
La versión del protocolo HTTP/2 fue más allá y usa multiplexación de mensajes
sobre un única conexión, siendo así una comunicación más eficiente.
Todavía hoy se sigue investigando y desarrollando para conseguir un protocolo de

transporte más conveniente para el HTTP. Por ejemplo, Google está
experimentado con QUIC, que se apoya en el protocolo UDP y presenta mejoras
en la fiabilidad y eficiencia de la comunicación.
¿Qué se puede controlar con HTTP?
La característica del protocolo HTTP de ser ampliable, ha permitido que durante su
desarrollo se hayan implementado más funciones de control y funcionalidad sobre
la Web: caché o métodos de identificación o autentificación fueron temas que se
abordaron pronto en su historia. Al contrario la relajación de la restricción de
origen solo se ha abordado en los años de la década de 2010.
Se presenta a continuación una lista con los elementos que se pueden controlar
con el protocolo HTTP:
 Cache
El como se almacenan los documentos en la caché, puede ser especificado por
HTTP. El servidor puede indicar a los proxies y clientes, que quiere almacenar y
durante cuanto tiempo. Aunque el cliente, también puede indicar a los proxies de
caché intermedios que ignoren el documento almacenado.
 Flexibilidad del requisito de origen
Para prevenir invasiones de la privacidad de los usuarios, los navegadores Web,
solamente permiten a páginas del mismo origen, compartir la información o datos.
Esto es una complicación para el servidor, asi que mediante cabeceras HTTP, se
puede flexibilizar o relajar esta división entre cliente y servidor
 Autentificación
Hay páginas Web, que pueden estar protegidas, de manera que solo los usuarios
autorizados puedan acceder. HTTP provee de servicios básicos de autentificación,
por ejemplo mediante el uso de cabeceras como: WWW-Authenticate, o
estableciendo una sesión especifica mediante el uso de HTTP cookies.
 Proxies y tunneling
Servidores y/o clientes pueden estar en intranets y esconder así su verdadera
dirección IP a otros. Las peticiones HTTP utilizan los proxies para acceder a ellos.
Pero no todos los proxies son HTTP proxies. El protocolo SOCKS, por ejemplo,
opera a un nivel más bajo. Otros protocolos, como el FTP, pueden ser servidos
mediante estos proxies.
 Sesiones
El uso de HTTP cookies permite relacionar peticiones con el estado del servidor.
Esto define las sesiones, a pesar de que por definición el protocolo HTTP es un
protocolo sin estado. Esto es muy útil no sólo para aplicaciones de comercio
electrónico, sino también para cualquier sitio que permita configuración al usuario.
Flujo de HTTP
Cuando el cliente quiere comunicarse con el servidor, tanto si es directamente con
él, o a través de un proxy intermedio, realiza los siguientes pasos:
1. Abre una conexión TCP: la conexión TCP se usará para hacer una petición, o
varias, y recibir la respuesta. El cliente pude abrir una conexión nueva, reusar una
existente, o abrir varias a la vez hacia el servidor.
2. Hacer una petición HTTP: Los mensajes HTTP (previos a HTTP/2) son legibles en
texto plano. A partir de la versión del protocolo HTTP/2, los mensajes se
encapsulan en franjas, haciendo que no sean directamente interpretables, aunque
el principio de operación es el mismo.
3. GET / HTTP/1.1
4. Host: developer.mozilla.org
Accept-Language: fr
5. Leer la respuesta enviada por el servidor:

6. HTTP/1.1 200 OK
7. Date: Sat, 09 Oct 2010 14:28:02 GMT
8. Server: Apache
9. Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
10. ETag: "51142bc1-7449-479b075b2891b"
11. Accept-Ranges: bytes
12. Content-Length: 29769
13. Content-Type: text/html
14.
<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
15. Cierre o reuso de la conexión para futuras peticiones.

Si está activado el HTTP pipelining, varias peticiones pueden enviarse sin tener
que esperar que la primera respuesta haya sido satisfecha. Este procedimiento es
difícil de implementar en las redes de computadores actuales, donde se mezclan
software antiguos y modernos. Así que el HTTP pipelining ha sido substituido en
HTTP/2 por el multiplexado de varias peticiones en una sola trama
Mensajes HTTP
En las versiones del protocolo HTTP/1.1 y anteriores los mensajes eran de formato
texto y eran totalmente comprensibles directamente por una persona. En HTTP/2,
los mensajes estan estructurados en un nuevo formato binario y las tramas
permiten la compresión de las cabeceras y su multiplexación. Así pues, incluso si
solamente parte del mensaje original en HTTP se envía en este formato, la
sematica de cada mensaje es la misma y el cliente puede formar el mensaje
original en HTTP/1.1. Luego, es posible interpretar los mensajes HTTP/2 en el
formato de HTTP/1.1.
Existen dos tipos de mensajes HTTP: peticiones y respuestas, cada uno sigue su
propio formato.
Peticiones
Un ejemplo de petición HTTP:
Una petición de HTTP, está formado por los siguientes campos:
 Un método HTTP, normalmente pueden ser un verbo, como: GET, POST o un

nombre como: OPTIONS (en-US) o HEAD (en-US), que defina la operación que el
cliente quiera realizar. El objetivo de un cliente, suele ser una petición de recursos,
usando GET, o presentar un valor de un formulario HTML, usando POST, aunque
en otras ocasiones puede hacer otros tipos de peticiones.
 La dirección del recurso pedido; la URL del recurso, sin los elementos obvios por el
contexto, como pueden ser: sin el protocolo (http://),
el dominio (aquí developer.mozilla.org), o el puerto TCP (aquí el 80).
 La versión del protocolo HTTP.
 Cabeceras HTTP opcionales, que pueden aportar información adicional a los
servidores.
 O un cuerpo de mensaje, en algún método, como puede ser POST, en el cual envía
la información para el servidor.
Respuestas
Un ejemplo de repuesta:
Las respuestas están formadas por los siguentes campos:
 La versión del protocolo HTTP que están usando.

 Un código de estado, indicando si la petición ha sido exitosa, o no, y debido a que.
 Un mensaje de estado, una breve descripción del código de estado.
 Cabeceras HTTP, como las de las peticiones.
 Opcionalmente, el recurso que se ha pedido.
Conclusión
El protocolo HTTP es un protocolo ampliable y fácil de usar. Su estructura cliente-
servidor, junto con la capacidad para usar cabeceras, permite a este protocolo
evolucionar con las nuevas y futuras aplicaciones en Internet.
Aunque la versión del protocolo HTTP/2 añade algo de complejidad, al utilizar un

formato en binario, esto aumenta su rendimiento, y la estructura y semantica de los
mensajes es la misma desde la versión HTTP/1.0. El flujo de comunicaciones en
una sesión es sencillo y puede ser fácilmente estudiado e investigado con un
simple monitor de mensajes HTTP.
¿Qué es HTTP?
Las siglas HTTP, acrónimo de Hypertext Transfer Protocol, es un protocolo de
transferencia de hipertexto. En otras palabras, HTTP es un protocolo de
comunicación que permite la transferencia de información en Internet.
Evolución del protocolo HTTP

Durante muchos años, el protocolo HTTP ha sido el más utilizado en la Red.
Desde que comenzó su desarrollo en 1989, se han lanzado diferentes versiones
más avanzadas que han sabido adaptarse a las necesidades y al avance
tecnológico del momento:
 HTTP/0.9: La primera versión del protocolo HTTP, denominada así a posteriori

para poder identificarlas de las siguientes versiones. Este protocolo no utiliza
cabeceras HTTP por lo que solamente podían transferirse archivos en HTML.
Además, no existían los códigos de estado HTTP como los conocemos hoy en
día.
 HTTP/1.0: Mucho más flexible que la versión anterior tanto para navegadores
como para los servidores web. Permite los métodos de petición GET, HEAD y
POST y todavía es utilizada hoy en día en algunos servidores proxy.
 HTTP/1.1: Publicada en 1997 y añade bastantes mejoras con relación a la
versión anterior. En esta versión ya se pueden realizar múltiples peticiones a la
vez por parte de un cliente, la conexión puede ser reutilizada y se añadieron
mejoras en la gestión de caché.
 HTTP/2: Pretende implantarse como un estándar en la web. Aunque no
modifica semánticamente el protocolo anterior, sí incluye muchas mejoras que
benefician tanto a usuarios como a cualquier persona que tenga una web. Por
ejemplo, HTTP/2 incluye compresión, necesita menos recursos, lo que implica
una menor latencia, el servidor puede responder a varias peticiones al mismo
tiempo… En definitiva, mejoras que tienen como objetivo una Web más rápida y
segura.
Actualmente HTTP/1.1 sigue siendo la versión más utilizada a nivel mundial,
aunque en los últimos 21 años (desde su lanzamiento) también ha sabido
adaptarse a los cambios en los hábitos de consumo de los usuarios.
Aunque sea un protocolo demasiado vulnerable, quizá hace 15 años no suponía

un gran riesgo a la hora de navegar por Internet. Sin embargo, en la actualidad
solo determinados sitios web continúan facilitando el intercambio de información
de este protocolo.
En la actualidad, empleamos las páginas web para comprar online, pedir cita en el
médico o realizar gestiones bancarias. Algo que no era común que hiciésemos
desde nuestro portátil o smartphone hace no demasiados años. Las cosas han
cambiado.
Ha surgido entonces la necesidad de proteger la información que se transfiere
entre el navegador del usuario y los servidores web. Es decir, era necesario un
protocolo más seguro que cifre las conexiones de manera que ningún usuario
malintencionado pueda interceptarla o robarla. De este modo surgió HTTPS.
Entonces, ¿cuál es la diferencia entre los protocolos

de comunicación HTTP y HTTPS?
Además de la evidente “s” al final de la palabra, existe una diferencia fundamental
entre estos dos protocolos: la seguridad.
HTTPS utiliza una combinación de dos protocolos de comunicación

(HTTP+SSL/TLS) que hace que cualquier tipo de información que se transmita en
la red sea cifrada y nadie pueda acceder a ella, únicamente navegador y servidor
web. Y para ello es necesario que tu web tenga instalado un Certificado SSL.
La principal diferencia entre HTTP y HTTPS es la seguridad.

El protocolo HTTPS impide que otros usuarios puedan
interceptar la información confidencial que se transfiere entre
el cliente y el servidor web a través de Internet.
Por decirlo de una manera muy sencilla, el protocolo HTTPS es la versión segura
del HTTP. Su diferencia radica en el nivel de seguridad a la hora de operar con
datos de los usuarios.
Además de mostrarse HTTPS en la barra de direcciones al inicio de la URL de la

página, también hay un elemento que diferencia claramente una web segura y otra
que no lo es: un candado verde. Por ejemplo:
Este es solo un caso, pero los protocolos de seguridad son tremendamente

comunes en la actualidad.
Como ves, dicho protocolo se muestra también al principio de las direcciones de

los sitios web.
Por tanto, para que tu página web funcione bajo el protocolo HTTPS es necesario
instalar un Certificado SSL.
Este certificado de seguridad es el encargado de cifrar o encriptar las conexiones

entre el navegador y servidor web impidiendo que nadie pueda interceptar la
información que se transfiere entre ambos. De este modo, todos los datos
personales, bancarios o cualquier otro tipo de información sensible que se
intercambie estará protegida.
Es, por lo tanto, un protocolo de comunicación seguro implantado en la mayoría de

las páginas web que tratan información confidencial.
En este artículo tienes más información sobre qué es un SSL y los diferentes tipos
de certificados que existen.
¿Por qué debo instalar un certificado SSL en mi

web?
Cuando tienes una página web, uno de tus principales objetivos es conseguir
visitas y conversiones. Pero, ¿qué ocurre si los usuarios saben que tu web no es
segura? ¿Le dejarías tus datos o tu tarjeta de crédito a alguien que sabes que no
los protegerá? Seguro que no, al igual que una gran mayoría de personas.
Además, esta falta de seguridad es un problema importante para tu empresa.
La seguridad de tus clientes debe ser un aspecto prioritario para ti. La recogida y
el envío de datos de forma segura es la única forma de protegerlos y que se
sientan seguros a la hora de facilitarte sus datos de pago, su información personal
o cualquier otro dato que pueda ser importante para ellos.
¿Y sabes lo más importante de todo? Google no para de trabajar por una web más
segura. Tanto es así que, coincidiendo con el lanzamiento de Google Chrome 68,
empezó a marcar como “no seguras” todas las páginas webs que todavía
funcionan con HTTP. O lo que es lo mismo, todas las webs que no
tienen instalado un certificado SSL.
Por tanto, los certificados SSL ya no es cosa solo de los ecommerce o tiendas
online. Cualquier página que tengas, ya sea un blog de moda, una web corporativa
o una página personal que trate información importante -datos personales, correo
electrónico de tus suscriptores, entre otras- necesitan estar protegidas con un SSL
para que Google no las penalice.
Últimas conclusiones entre la diferencia entre HTTP y

HTTPS
Las páginas web, blogs o tiendas online que todavía funcionan con HTTP y no
tienen instalado un certificado SSL no son seguras. Además, Google se encargará
de que los usuarios lo sepan indicando en la barra de navegación que tu sitio no
es seguro.
¿Y por qué es tan importante un certificado de seguridad? La información que se

transmite bajo el protocolo HTTP es susceptible de ser interceptada por los
hackers, pudiendo poner en peligro los datos de tu empresa y, lo que es peor, de
tus clientes -cuentas de correos electrónicos, número de cuentas bancarias, otra
información disponible, etcétera-.
En cambio, tener un SSL y que tu web funcione bajo el protocolo HTTPS te servirá
para decirle a tus usuarios que tu web es legítima, opera de forma segura y es
seguro navegar en ella.
Además, como empresa puede ser una buena idea implementar otras seguridades
adicionales añadidas para evitar el spam o posibles ataques. Haz que la seguridad
de tu página web sea una prioridad.
¿Por qué es importante el HTTPS?

Como ya os contamos el protocolo HTTPS es una extensión
cifrada con una capa SSL o TLS del HTTP tradicional. Sus objetivos
son certificar que la web visitada es legítima y asegurarnos que se
mantiene la integridad y privacidad de los datos de conexión.
Estas dos características ayudan a protegernos de ataques
clásicos en la red como los de man-in-the-middle.
El cifrado de este protocolo es bidireccional en las

comunicaciones entre servicores y clientes, una característica que
ayuda a protegernos contra el espionaje y la manipulación de las
comunicaciones a través de las páginas que lo utilizan. No es un
método infalible, pero sus beneficios son los suficientes para que,
algunos tardando más que otros, al final todos nos estemos
tomando muy en serio su implantación.
Por eso, el que cada vez seamos más páginas las que adoptamos
este protocolo es una muy buena noticia para la seguridad y
privacidad de todos los usuarios. Pero aún queda un largo camino
por recorrer, ya que según páginas como Stat Operator sólo
116.675 de un millón de las páginas más importantes de la red
utilizan este protocolo por defecto.
HTTP: El Protocolo de transferencia de hipertexto (Hypertext Transfer Protocol o HTTP) es el
protocolo de comunicación que permite las transferencias de información en la World Wide Web.
Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y
un servidor. El cliente (se le suele llamar "agente de usuario", en inglés user agent) realiza una
petición enviando un mensaje, con cierto formato al servidor. El servidor (se le suele llamar un
servidor web) le envía un mensaje de respuesta. Si un servidor necesita enviar un mensaje a un
cliente, comprueba si hay una conexión HTTP que pertenece a la sesión requerida y está en el
estado "respondiendo una solicitud HTTP" (incluida una encuesta larga) con lo que el mensaje se
agrega al contenedor de respuesta para la conexión y enviado al usuario. En un caso típico, hay un
tiempo de espera adicional (50 milisegundos) frente a la posibilidad de que el servidor pronto
tenga más mensajes para la sesión. Si no hay una conexión HTTP adecuada disponible, los
mensajes se colocan en la cola de envío de la sesión actual. Sin embargo, encuentran su camino
hasta que el recibo sea confirmado explícitamente por el cliente. Para todos los protocolos, el
cliente debe devolver un acuse de recibo explícito dentro de un tiempo razonable (se puede
agregar a un contenedor para la siguiente solicitud)
HTTPS
El Protocolo seguro de transferencia de hipertexto (en inglés, Hypertext Transfer
Protocol Secure o HTTPS) es un protocolo de aplicación basado en el protocolo HTTP,
destinado a la transferencia segura de datos de hipertexto, es decir, es la versión segura
de HTTP.
Usa TLS para crear un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y del
navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el
protocolo HTTP. De este modo se consigue que la información sensible (usuario y claves de
paso normalmente) no pueda ser usada por un atacante que haya conseguido interceptar la
transferencia de datos de la conexión, ya que lo único que obtendrá será un flujo de datos
cifrados que le resultará imposible de descifrar.
El puerto estándar para este protocolo es el 443. (También comúnmente usado el 4433)
Netscape Communications creó HTTPS en 1992 para su navegador Netscape Navigator.1
Originalmente, HTTPS era utilizado solamente con el cifrado SSL, pero este se volvió obsoleto
ante TLS. HTTPS fue adoptado como un estándar web con la publicación de RFC 2818 en
mayo del 2000.
En el protocolo HTTP las URLs comienzan con "http://" y utilizan por omisión el puerto 80, las

URLs de HTTPS comienzan con "https://" y utilizan el puerto 443 por omisión.
HTTP es inseguro y está sujeto a ataques man-in-the-middle y eavesdropping que pueden
permitir al atacante obtener acceso a bancos y a cuentas de un sitio web e información
confidencial. HTTPS está diseñado para resistir esos ataques y ser más seguro.
El sistema de HTTPS opera en la capa más alta del modelo OSI, la capa de aplicación; pero el
protocolo sin seguridad opera en una subcapa más baja, cifrando un mensaje HTTP previo a
la transmisión y descifrando un mensaje una vez recibido. Estrictamente hablando, HTTPS no
es un protocolo separado, pero refiere el uso del HTTP ordinario sobre una Capa de Conexión
Segura cifrada Secure Sockets Layer (SSL) o una conexión con Seguridad de la Capa de
Transporte (TLS).
Configuración del servidor[editar]

Para preparar un servidor web que acepte conexiones HTTPS, el administrador debe crear
un certificado de clave pública para el servidor web. Este certificado debe estar firmado por
una autoridad de certificación para que el navegador web lo acepte. La autoridad certifica que
el titular del certificado es quien dice ser. Los navegadores web generalmente son distribuidos
con los certificados raíz firmados por la mayoría de las autoridades de certificación por lo que
estos pueden verificar certificados firmados por ellos.
Adquisición de certificados[editar]
Adquirir certificados puede ser gratuito34 o costar entre US$135 y US$15006 por año.
Las organizaciones pueden también ser su propia autoridad de certificación, particularmente si
son responsables de establecer acceso a navegadores de sus propios sitios (por ejemplo,
sitios en la intranet de una empresa, o grandes universidades). Estas pueden fácilmente
agregar copias de su propio certificado firmado a los certificados de confianza distribuidos con
el navegador.
También existen autoridades de certificación persona a persona (peer-to-peer).
Usar un control de acceso[editar]
El sistema puede también ser usado para la autenticación de clientes con el objetivo de limitar
el acceso a un servidor web a usuarios autorizados. Para hacer esto el administrador del sitio
típicamente crea un certificado para cada usuario, un certificado que es guardado dentro de su
navegador. Normalmente, este contiene el nombre y la dirección de correo del usuario
autorizado y es revisado automáticamente en cada reconexión para verificar la identidad del
usuario, potencialmente sin que cada vez tenga que ingresar una contraseña.
En caso de claves privadas comprometidas[editar]
Un certificado puede ser revocado si este ya ha expirado, por ejemplo cuando el secreto de la
llave privada ha sido comprometido. Los navegadores más nuevos como son Firefox,7 Opera,8
e Internet Explorer sobre Windows Vista9 implementan el Protocolo de Estado de Certificado
Online (OCSP) para verificar que ese no es el caso. El navegador envía el número de serie del
certificado a la autoridad de certificación o, es delegado vía OCSP y la autoridad responde,
diciéndole al navegador si debe o no considerar el certificado como válido.10
Adopción de HTTPS[editar]
En febrero de 2017, la adopción HTTPS fue:
 Argentina: 9,77% del total de dominios.11

 España: 5,11% del total de dominios.12
 México: 13.31% del total de dominios.13
 Chile: 18,71% del total de dominios.14
 Colombia: 4,85% del total de dominios.15
Desde Google se está intentando incentivar el uso de https para mejorar la seguridad de
transferencia de información en internet. Actualmente, desde su navegador Chrome marcan
como "no seguras" las urls bajo http y según las comunicaciones de la compañía en un futuro
marcarán como "no seguras" todas las webs que no estén bajo https. Esto está aumentando la
tasa de implementación de certificados SSL y cada vez más webs están bajo https.
Limitaciones[editar]
El nivel de protección depende de la exactitud de la implementación del navegador web, el
software del servidor y los algoritmos de cifrado actualmente soportados. Vea la lista en Idea
Principal.
También, HTTPS es vulnerable cuando se aplica a contenido estático de publicación
disponible. El sitio entero puede ser indexado usando una araña web, y la URI del recurso
cifrado puede ser adivinada conociendo solamente el tamaño de la petición/respuesta.16 Esto
permite a un atacante tener acceso al texto plano (contenido estático de publicación), y
al texto cifrado (La versión cifrada del contenido estático), permitiendo un ataque criptográfico.
Debido a que SSL opera bajo HTTP y no tiene conocimiento de protocolos de nivel más alto,
los servidores SSL solo pueden presentar estrictamente un certificado para una combinación
de puerto/IP en particular17 Esto quiere decir, que en la mayoría de los casos, no es
recomendable usar Hosting virtual name-based con HTTPS. Existe una solución
llamada Server Name Indication (SNI) que envía el hostname al servidor antes de que la
conexión sea cifrada, sin embargo muchos navegadores antiguos no soportan esta extensión.
El soporte para SNI está disponible desde Firefox 2, Opera 8, e Internet Explorer
7 sobre Windows Vista.181920
¿Qué es el protocolo HTTPS?

Cuando accedemos a una página web, lo que realmente hacemos es una petición a una
máquina para que nos muestre en el navegador su contenido, que es descargado a nuestro
ordenador. Pero lo que queremos, por ejemplo, cuando nos logueamos en una página web
como nuestra banca electrónica es que nuestro nombre de usuario y contraseña, la
información que visualizamos de nuestras cuentas y las operaciones que realizamos, es
decir, la información que intercambiamos con el servidor se haga de manera segura y no
pueda ser interceptada por personas no deseadas. Ahí es cuando adquiere especial
relevancia el protocolo HTTPS, también conocido como protocolo seguro de
transferencia de hipertexto.
¿Qué es el protocolo HTTPS y cómo funciona?

Es un protocolo de comunicación de internet, un conjunto de comandos o instrucciones que
ejecuta el navegador, cuando tecleamos una URL, hacemos clic en un enlace o rellenamos
un formulario. El protocolo inicial del que parte es el conocido HTTP, en el que toda la
información que intercambia nuestro navegador con el servidor es en texto normal. En
HTTPS el tráfico es cifrado, garantizando así una conexión segura.
¿Para qué se utiliza?

El objetivo del protocolo HTTPS es evitar que una persona malintencionada o
atacante pueda obtener nuestra información sensible: usuarios, contraseñas o números
de tarjetas de crédito. Si la información que intercambia nuestro navegador con el servidor
no va cifrada (página web implementada con HTTP, que no es seguro,
http://www.pagina.xxx), un atacante que está en la misma red pública o no segura que
nosotros, podría capturar nuestro tráfico y acceder a nuestros datos sensibles. Para ello
debemos asegurarnos siempre que utilicemos datos sensibles a través de redes no
confiables, que las páginas tienen implementado HTTPS (https://www.página.xxx) de
forma que nuestra información viaje cifrada.
Es posible que una persona estando en la misma red Wifi que nosotros, pueda capturar
nuestro tráfico de red, y en el caso de transportar información sensible y no cifrada, pueda
acceder a ella. La recomendación general es utilizar siempre páginas que tengan
implementado HTTPS para la realización de compras o intercambios de información
sensible o confidencial y garantizar así una primera barrera de seguridad para nuestros
datos personales.
Ventajas y desventajas de utilizar https en tu

página web
Está claro que utilizar el protocolo HTTPS tendrá unas ventajas positivas para tu
página web
No queremos decir que al instalar el SSL subirás posiciones repentinamente, si no
que si cumples con los demás factores y además tu página es segura
aumentará en los rankings gracias al certificado https; pero ojo, no todo puede ser
bonito en el mundo de internet. Al igual que hay ventajas, también existen
desventajas las cuales harán plantearte si de verdad es adecuado para tu página
web. ¡Vamos a verlo!
Ventajas del protocolo HTTPS:
1. Seguridad de datos: El certificado HTTPS nos permite “blindar“ nuestra
información enviada.
2. Verificación de identidad: Garantiza que la información que el usuario envía
llega al destino correcto y queda registrado tal y como ha escrito el usuario.
3. Confianza: El protocolo HTTPS aporta una confianza extra al consumidor.
4. Mejora el posicionamiento orgánico de la web: el sitio web aparecerá en
posiciones más altas si cuenta con el certificado de seguridad HTTPS.
5. Favorece las ventas: Este protocolo ayuda a que se produzcan mayores
conversiones en tu sitio web.
6. Mejora la satisfacción del usuario: Al ganar en confianza y seguridad el usuario
quedará más satisfecho con su experiencia en la web.

Desventajas de https:
1. Errores 404: Al migrar un sitio web a https todas las url´s de la página cambian,
ya que en vez de http estará https. Esto puede ser un problema si
no redireccionamos las antiguas url´s hacia las nuevas.
2. Problemas de migración: Hacer una migración no es fácil y es necesario estar
atento a los detalles. Existen muchos problemas a la hora de migrar, problemas
como: olvidar bloquear el robot.txt, mensajes de alerta en la web, problemas de
enlaces, etc.
3. Rendimiento web: El certificado HTTPS necesita algo más de recursos que el
HTTP, es por eso que si nuestro rendimiento web no es bueno, al implementar
https podría ser aún peor y ralentizarnos la web.
¿Debo pasar mi web a HTTPS?

Pues la respuesta es depende. La migración a HTTPS no es una tarea fácil y
requiere estar atentos de los detalles ya que el mínimo error puede hacer caer
nuestro SEO o implementar de manera incorrecta el certificado SSL.
Otro punto a analizar es si tu sitio web en verdad necesita dicho certificado. No es
lo mismo un e-commerce que un blog de salud, el e-commerce seguramente se
vea beneficiado ya que con la compra de productos el envío de información debe
ser seguro. Pero para el blog de salud a lo mejor no compensa hacer el duro
trabajo de la migración, para los pocos beneficios que obtendrá de ella y los
posibles errores a los que te arriesgas.
La mejor opción es ponerse siempre en manos de un experto, UpToBe
como agencia de marketing online puede gestionar el cambio de protocolo http a
https en cuestión de horas.
En cualquier caso, si te has decidido a implementarlo no dudes en ponerte en
contacto con alguien con los conocimientos necesarios para hacerlo, ya que es
una tarea compleja. ¡Desde UpToBe Marketing podemos ayudarte a implementar
tu certificado SSL a tu página web!
Dado su funcionamiento, la principal particularidad del

famoso protocolo HTTPS, radica en que se ocupa de crear un canal
seguro sobre una red insegura, básicamente. Con ello, logra
proporcionar una protección contra diferentes tipos de ataques o
amenazas, para garantizar que el servidor sea verificado y resulte
de confianza.
Por su parte, de forma técnica, el Protocolo Seguro para la
Transferencia de Hipertexto, contempla las siguientes
características de sumo interés:
 Emplea un cifrado basado en la seguridad de textos

SSL/TLS con el objetivo de crear un canal encriptado
pertinente para el tráfico de información sensible.
Considerando que, el nivel de cifrado dependerá del servidor
remoto y el navegador usado.
 Por suerte, su utilización no requiere ninguna instalación
de software adicional. Como consecuencia, puede ser
empleado por cualquier usuario y sin restricción alguna. Lo
cual, inspira confianza en los clientes potenciales, debido a la
autenticación que realiza con un certificado.
 El protocolo HTTPS también se caracteriza por mostrar una
óptima integración con los principales navegadores web,
tales como: Google Chrome, Mozilla Firefox, Opera, Safari e
Internet Explorer.
 Generalmente, este protocolo de seguridad se distingue a
partir de un icono de candado que se encuentra en la parte
derecha de la barra de direcciones. De esa forma, permite
identificar páginas web confiables. Considerando que,
además, también incluye el término “https” al inicio de la
dirección URL.
 El contenido que se transmite con conexiones HTTPS, no
puede ser almacenado en caché. Esto, para algunas
personas puede ser ventajoso y para otras, un punto en
contra.
 Para poder preparar un servidor web, en términos de
configuración, para que admita conexiones HTTPS; el
administrador tendrá que crear un certificado de clave
pública para el servidor web.
 Un protocolo HTTPS puede ser vulnerado cuando se aplica a
contenido estático de publicación disponible.
 En caso de que un infiltrado o una persona no confiable logre
capturar los datos trasmitidos a partir del protocolo
HTTPS, igualmente no podrá descifrar la información en
cuestión porque está totalmente encriptada.
¿Cómo mejora HTTPS al antiguo protocolo HTTP para Internet?
El antiguo HTTP consiste en un protocolo que permite realizar una

petición de datos y recursos, por lo que se considera la base de
cualquier intercambio de datos en la web. Sin embargo, a lo largo
del tiempo, ha sido señalado como un protocolo muy fácil de
violentar porque simplifica, para todas aquellas personas infiltradas,
la captura de datos que se están transmitiendo. Como consecuencia,
se creó el protocolo HTTPS con el objetivo de cambiar la
funcionalidad del protocolo HTTP y proporcionar una mayor
seguridad.
Puesto que, el Protocolo Seguro para la Transferencia de Hipertexto
hace uso de un cifrado en el que los infiltrados no logran descifrar la
información, aun y cuando puedan capturar la transmisión de la
misma. Pues, se mantiene encriptado en su totalidad. Por lo tanto,
la principal diferencia entre el protocolo HTTP y HTTPS, radica en la
seguridad que proporcionan. Tomando en cuenta que, este último
emplea la misma tecnología que el antiguo HTTP, pero incluye
encriptación SSL.
Sumado a ello, se observan las siguientes distinciones:
 En el protocolo HTTP las direcciones URL inician
con “http://”. Mientras que, en el HTTPS, dichos enlaces
empiezan con “https://”.
 Generalmente, el protocolo HTTP usa el puerto 80, por
omisión. En cambio, los HTTPS utilizan el puerto 443.
 A diferencia del HTTP que está sujeto a ataques man-in-the-
middle y eavesdropping, por lo que permiten que las
personas malintencionadas adquieran acceso a cuentas de un
sitio web, bancos e información confidencial; el HTTPS se
encuentra diseñado para soportar y resistir dichos ataques,
por lo que resulta más seguro.
 Regularmente, el HTTP opera en la capa más alta del
Modelo OSI. Sin embargo, el protocolo HTTPS opera en una
subcapa más baja para garantizar el cifrado de un mensaje
HTTP previo a la trasmisión y descifrar los datos, una vez
recibidos.
Capas de red de HTTPS ¿Cuáles son y cómo funciona este protocolo?
Por si no lo sabias, los datos enviados a través de un protocolo

HTTPS están asegurados gracias a un protocolo conocido
como “Transport Layer Security” o “TLS” que, por
defecto, proporciona tres capas de protección primordiales y así,
determina el funcionamiento del protocolo HTTPS mejorado.
Dichas capas de protección de red, son las siguientes:
Cifrado
Por lo general, siempre que un equipo emite un mensaje desde el

navegador web hacia el servidor web, existe la posibilidad de que la
información sea capturada por alguien que está tratando de
interceptar el canal de comunicación, con el fin de espiar todo el
tráfico.
No obstante, el protocolo HTTPS se encarga de cifrar los datos de
intercambios y los mantiene seguros ante miradas indiscretas.
Gracias a esto, mientras el usuario esté navegando en un sitio web,
ninguna otra persona podrá espiar sus movimientos ni realizar un
seguimiento de sus actividades con el objetivo de usurpar su
información confidencial. Más bien, la comunicación con el servidor
web se hará efectiva de forma segura a partir de un cifrado de
punto a punto.
Integridad
Así como existen riesgos de seguridad con los que se puedan perder
los datos, también es posible que el mensaje transmitido desde el
navegador web hasta el servidor sea capturado con el fin de
cambiar la información que hay en él. Por lo que, una vez
modificado, se enviará al destinatario y así, afectará la integridad
del emisor.
Pero, por suerte, el protocolo HTTPS se ocupa de garantizar la

integridad de los datos para que no puedan ser dañados ni
modificados durante el proceso de transferencia,
independientemente de que haya sido intencional o no. Esto significa
que, bajo cualquier circunstancia, el mensaje llegará al receptor
exactamente como se envió, sin riesgos a reducir su integridad.
Autenticación
El protocolo HTTPS también provee un gran nivel de

autenticación, de forma que, logra proteger a los usuarios en contra
de diferentes ataques. De tal modo, construye la confianza de las
personas al suministrar páginas web que sean completamente
auténticas.
Lo cual, ha sido verificado previamente, conociendo la identidad de
quien ha enviado el mensaje por medio del uso de una firma
digital. Por su parte, cabe acotar que, esta ventaja la consigue por
medio de los certificados SSL, con los que se puede afirmar que
estás conectado al lugar correcto. Tomando en cuenta que, por
defecto, un certificado SSL es el encargado de mostrar que el
navegador web es válido y que ha sido presentado por una
autoridad de certificación legal.
Limitaciones del protocolo ¿Cuáles son los puntos débiles del HTTPS?
A pesar de que el protocolo HTTPS mejorado presenta numerosos

beneficios a los usuarios, lo cierto es que también tiene algunos
puntos en contra que vale la pena tomar en cuenta.
Por consiguiente, a continuación, nombramos cuales son las

principales limitaciones o desventajas del HTTPS:
 Por defecto, el nivel de protección depende de la exactitud de
la implementación del navegador web y los algoritmos de
cifrado soportados. Por lo que, al no ser
independientemente, podría presentar ciertas brechas en
términos de privacidad.
 A partir de las conexiones HTTPS, es imposible almacenar el
contenido en memoria caché. Lo cual, resulta desfavorable
para diversos usuarios.
 Se ha evidenciado que, el protocolo HTTPS exhibe
vulnerabilidad una vez se aplica a contenido estático de
publicación disponible. Lo cual, facilita acciones no
fidedignas por parte de usuarios no confiables que buscan
tener acceso al texto plano y al texto cifrado. Esto, sirve para
un ataque criptográfico.
 Otro punto débil radica en un menor rendimiento, como
resultado del empleo del cifrado SSL. Puesto que, por
naturaleza, el servidor tendrá que hacer numerosos cálculos y
con ello, incrementa el tiempo de espera para dar respuesta.
 Desafortunadamente, los hosts virtuales no funcionan con
el protocolo HTTPS. Pues, los servidores SSL solamente
logran presentar un certificado, de manera estricta, para una
combinación de Puerto/IP en particular.
 Los cargos adicionales por certificados pueden ser
distintamente altos y, aparte, revela costes crecientes
debido al aumento del tráfico. Por ende, las tarifas pueden
llegar a ser muy altas en sitios web nuevos y pequeños,
más que todo.
Seguridad del HTTPS ¿Realmente es tan seguro como se dice?
A pesar de que el protocolo HTTPS garantiza el cifrado en la

transmisión de datos, en realidad no es tan seguro como parece.
Pues, con las diferentes amenazas que operan en la red actualmente,
el símbolo de seguridad de dicho protocolo no logra garantizar
que una página web esté protegida en su totalidad. Considerando
que, en este momento, los sitios maliciosos utilizan cada vez más
HTTPS (sobre todo, los de phishing). Esto se debe a que, una
conexión segura no es equivalente a un sitio seguro.
En otras palabras, destacamos que, a pesar de que el

protocolo HTTPS cifra la información que es transmitida entre el sitio
y tú, no tiene nada que ver con la seguridad del sitio web en
concreto. Puesto que, un sitio malicioso podrá conseguir un
certificado de este tipo sin problemas y cifrar todo el tráfico que se
produce entre la página y tú para que no existan fisgones de por
medio. No obstante, aunque aseguren que nadie más puede espiar
los datos que suministras, tu contraseña e información
confidencial estará en manos de dichos sitios.
Por lo tanto, podrá ser usurpada desde allí. Es decir, desde una web
falsa o insegura. Como conclusión, la presencia del candado
correspondiente al protocolo HTTPS, simplemente indica el uso de
un certificado que garantiza un tráfico seguro y libre de las
miradas de terceros. Sin embargo, dicho protocolo no emite avisos
en torno a la inseguridad que contenga un sitio HTTPS malicioso
que puede estar manipulado por estafadores online.
¿Deben considerarse peligrosas las webs que no utilizan este protocolo?
Esta es una duda latente entre diferentes usuarios de los

navegadores web que, por supuesto, es oportuno aclarar. En tal
sentido, destacamos que, aquellas páginas web que no hacen uso del
protocolo HTTPS, no son peligrosas del todo.
Considerando que, aunque este protocolo envía información

cifrada, la misma puede ser capturada por personas
malintencionadas e incluso, por un sitio web falso. Por
consiguiente, así accedas a una web que emplee el protocolo HTTPS,
no estarás exento de ser espiado por otras personas. Por lo que,
en cualquier caso, es recomendable evitar compartir información
confidencial en la red, especialmente, cuando se trata de datos
personales, credenciales importantes u operaciones económicas.
REFERENCIAS
【Protocolo HTTPS】 ¿Qué Es? + Seguridad y Características ▷ 2021. (2020, 5 de

noviembre). Obtenido el 29 de julio de 2021 del sitio web Internetpasoapaso.com:
https://internetpasoapaso.com/protocolo-https/
Computacionales, I. en S. (nd). Tecnológico Nacional de México. Recuperado el 29 de
julio de 2021 del sitio web Tecnm.mx:
https://www.veracruz.tecnm.mx/images/Imagenes/Aplicaciones%20y
%20Protocolos.pdf
¿Cuál es la diferencia entre HTTP y HTTPS? (2021, 6 de julio). Obtenido el 29 de julio
de 2021 del sitio web Godaddy.com: https://es.godaddy.com/blog/diferencia-entre-
http-y-https/
Evolución del protocolo HTTP. (Dakota del Norte). Obtenido el 29 de julio de 2021 del
sitio web Mozilla.org:
https://developer.mozilla.org/es/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_H
TTP
Generalidades del protocolo HTTP. (n.d.). Retrieved July 29, 2021, from Mozilla.org
website: https://developer.mozilla.org/es/docs/Web/HTTP/Overview
HTTPS. (n.d.). Retrieved July 29, 2021, from Ryte.com website:
https://es.ryte.com/wiki/HTTPS
¿Qué es el protocolo HTTPS y que ventajas aporta en tu web? (2017, May 3).
Retrieved July 29, 2021, from Uptobemarketing.com website:
https://uptobemarketing.com/protocolo-https-ventajas/
Santander, B. (n.d.). HTTPS. Retrieved July 29, 2021, from Bancosantander.es
website: https://www.bancosantander.es/glosario/https
Wikipedia contributors. (n.d.). Protocolo seguro de transferencia de hipertexto.
Retrieved July 29, 2021, from Wikipedia, The Free Encyclopedia website:
https://es.wikipedia.org/w/index.php?
title=Protocolo_seguro_de_transferencia_de_hipertexto&oldid=137198157
Yúbal, F. M. (2017, February 4). Por primera vez más del 50% de las webs utilizan
HTTPS, según Firefox. Retrieved July 29, 2021, from Genbeta.com website:
https://www.genbeta.com/seguridad/por-primera-vez-mas-del-50-de-las-webs-
utilizan-https-segun-firefox

HTTP y HTTPS

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

HTTP y HTTPS

Cargado por

Copyright:

Formatos disponibles

Evolución del protocolo HTTP

HTTP es el protocolo en el que se basa la Web.

Fue inventado por Tim Berners-Lee entre los años 1989-1991,

HTTP ha evolucionado, desde un protocolo destinado al intercambio de archivos en

Invención de la World Wide Web

 Un formato de texto para representar documentos de hiper-texto: HyperText

El 6 de Agosto de 1991, el post de Tim Berners-Lee, se considera actualmente

HTTP/0.9 – El protocolo de una sola línea

La respuesta también es muy sencilla: solamente consiste el archivo pedido.

Una pagina web muy sencilla

Al contrario que sus posteriores evoluciones, el protocolo HTTP/0.9 no usa

HTTP/1.0 – Desarrollando expansibilidad

GET /mypage.html HTTP/1.0

User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

Date: Tue, 15 Nov 1994 08:12:31 GMT

Una pagina web con una imagen

Continua con una segunda conexión y la petición de una imagen:

GET /myImagen.gif HTTP/1.0

User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

Date: Tue, 15 Nov 1994 08:12:32 GMT

Server: CERN/3.0 libwww/2.17

HTTP/1.1 – El protocolo estándar.

HTTP/1.1 aclaró ambigüedades y añadió numerosas mejoras:

 Una conexión podía ser reutilizada, ahorrando así el tiempo de re-abrirla repetidas

GET /en-US/docs/Glossary/Simple_header HTTP/1.1

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0)

Accept-Encoding: gzip, deflate, br

Date: Wed, 20 Jul 2016 10:55:30 GMT

Keep-Alive: timeout=5, max=1000

Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT

Vary: Cookie, Accept-Encoding

GET /static/img/header-background.png HTTP/1.1

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0)

Accept-Encoding: gzip, deflate, br

Date: Thu, 31 Mar 2016 13:34:46 GMT

Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT

(image content of 3077 bytes)

HTTP/1.1 fue publicado inicialmente como RFC 2068 en Enero de 1997.

Más de 15 años de expansiones

El uso de HTTP para transmisiones seguras

El mayor cambio en el desarrollo de HTTP, fue a finales de 1994. En vez de

Durante el mismo periodo, la necesidad por una capa de trasporte encriptada

Uso de HTTP para aplicaciones complejas

 Eventos enviados por el servidor: El servidor es el que ocasionalmente inicia los

El protocolo HTTP es independiente del modelo de seguridad de la Web: la política

Además de estas ampliaciones, muchas otras cabeceras han sido añadidas,

HTTP/2 – Un protocolo para un mayor rendimiento

En la primera mitad de la década de 2010, Google demostró un proceso alternativo

El protocolo HTTP/2, tiene notables diferencias fundamentales respecto a la

 Es un protocolo binario, en contraposición a estar formado por cadenas de texto, tal

Esta rápida adopción era esperada, ya que el uso de HTTP/2, no requiere de una

Post-evolución del HTTP/2

 Soporte de la cabecera Alt-Svc (en-US), la cual permite disociar la identificación de

Clientes y servidores se comunican intercambiando mensajes individuales (en

Arquitectura de los sistemas basados en HTTP

Cada petición individual se envía a un servidor, el cuál la gestiona y responde.

Cliente: el agente del usuario

El agente del usuario, es cualquier herramienta que actué en representación del

El navegador es siempre el que inicia una comunicación (petición), y el servidor

Al otro lado del canal de comunicación, está el servidor, el cual "sirve" los datos

Entre el cliente y el servidor, además existen distintos dispositivos que gestionan

 caching (la caché puede ser pública o privada, como la caché de un navegador)

Características clave del protocolo HTTP