← Volver al Blog
06 May, 2026 Por Andrés Pacheco

HTTP & HTTPS: Historia, Anatomía Interactiva y Todos sus Métodos

Cada vez que abres un navegador, ves un emoji o pides comida online — HTTP trabaja silenciosamente detrás. Es el lenguaje de la web. HTTPS es su versión cifrada que protege tus datos. En esta guía veremos su historia, anatomía y demos interactivas en vivo.

1991
HTTP/0.9 nace
1994
SSL nace
9
Métodos HTTP estándar
5
Clases de status codes
95%+
Tráfico web es HTTPS
2022
HTTP/3 (RFC 9114)

🌐 ¿Qué es HTTP?

HTTP (HyperText Transfer Protocol) es un protocolo de la capa de aplicación, basado en mensajes de texto, cliente-servidor y stateless (sin estado): cada petición es independiente. El cliente envía un request, el servidor responde con un response. Punto.

Originalmente diseñado para transferir documentos HTML entre máquinas en CERN, hoy mueve todo: APIs REST/GraphQL, video streaming, IoT, gaming en la nube, modelos de IA. Su simplicidad es su super poder.

🔐 ¿Qué es HTTPS?

HTTPS (HTTP Secure) es exactamente HTTP — pero envuelto en una capa de cifrado TLS (antes SSL). Tres garantías:

  • Confidencialidad — nadie en la red puede leer el contenido (cifrado simétrico AES).
  • Integridad — ningún atacante puede alterar los datos en tránsito (HMAC).
  • Autenticidad — el cliente verifica que está hablando con el servidor real (certificados X.509).

📜 Historia de HTTP

1989
1989 — Tim Berners-Lee propone la Web en CERN

El físico británico publica el memo "Information Management: A Proposal". Concibe HTTP, HTML y URLs como las tres patas de la World Wide Web. En 1990 escribe el primer cliente y servidor en NeXTSTEP.

1991
1991 — HTTP/0.9 (one-line protocol)

Solo existía GET. Sin headers, sin status codes, sin URLs absolutas. El servidor cerraba la conexión tras enviar el HTML. GET /index.html y listo.

1996
1996 — HTTP/1.0 (RFC 1945)

Primera versión documentada formalmente. Llegan headers, status codes, soporte para POST y HEAD, contenido distinto a HTML (imágenes, video). Pero cada request abría una nueva conexión TCP — costoso.

1997
1997 → 1999 → 2014 — HTTP/1.1 (RFC 2068, 2616, 7230-7235)

La versión que dominó 25 años. Conexiones persistentes (keep-alive), pipelining, chunked encoding, caching headers robustos, Host header obligatorio (multi-tenancy). Llegan PUT, DELETE, PATCH, OPTIONS, TRACE, CONNECT.

2015
2015 — HTTP/2 (RFC 7540) · binario y multiplex

Basado en SPDY de Google. Protocolo binario (no texto). Multiplexing: múltiples streams concurrentes en una sola conexión TCP. HPACK comprime headers. Server Push (ahora deprecated). Latencia drásticamente menor.

2022
2022 — HTTP/3 (RFC 9114) · sobre QUIC/UDP

Abandona TCP. Corre sobre QUIC (sobre UDP) con TLS 1.3 integrado. Adiós head-of-line blocking. Conexiones se reanudan al cambiar de Wi-Fi a 4G sin perder estado. Adoptado por Google, Cloudflare, Meta, Apple. ~30% del tráfico web ya es HTTP/3 en 2026.

🛡️ Historia de HTTPS / SSL / TLS

1994
1994 — SSL 1.0 (Netscape, nunca liberado)

Diseñado por Taher Elgamal en Netscape. Tan inseguro que jamás se publicó externamente. El internet temprano necesitaba urgentemente cifrado para comercio electrónico.

1995
1995 — SSL 2.0 (Netscape) · roto desde el inicio

Primer release público. Vulnerabilidades graves descubiertas casi inmediatamente. Deprecado oficialmente en 2011 (RFC 6176).

1996
1996 — SSL 3.0 (rediseño completo)

Paul Kocher lo rediseña desde cero. La base de TLS moderno. Sobrevive 18 años hasta ser fulminado por POODLE attack (2014). Deprecado en 2015.

1999
1999 — TLS 1.0 (RFC 2246) · IETF toma el control

Netscape pasa el estándar a IETF. Se renombra a TLS (Transport Layer Security) por temas de marca. Esencialmente SSL 3.1.

2008
2008 — TLS 1.2 (RFC 5246)

Soporte SHA-256, AEAD ciphers (AES-GCM), removal de MD5. Estándar dominante por una década.

2016
2016 — Let's Encrypt democratiza HTTPS

EFF, Mozilla y otros lanzan Let's Encrypt: certificados SSL gratuitos y automatizables vía protocolo ACME. Antes los certificados costaban $50-500/año. Hoy hay 400M+ sitios HTTPS gracias a este proyecto.

2018
2018 — TLS 1.3 (RFC 8446) · más rápido y seguro

Handshake en 1 RTT (vs 2 en TLS 1.2). 0-RTT resumption para conexiones repetidas. Eliminados todos los algoritmos legacy (RSA key exchange, CBC modes, RC4, SHA-1). Solo cipher suites AEAD modernos. Default en navegadores desde 2019.

🎬 Demo Interactivo: Anatomía de una petición HTTP

Click en cualquier método. Verás el paquete viajar del navegador al servidor, los headers reales que se envían y la respuesta típica. Cada método tiene una semántica distinta:

Browser cliente 🌐 Server api.example.com 🖥️ GET 200 OK

📤 Request

GET /api/users HTTP/1.1
Host: api.example.com
Accept: application/json
User-Agent: Mozilla/5.0
Authorization: Bearer eyJ...

📥 Response

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 142

[
  {"id":1,"name":"Andrés"},
  {"id":2,"name":"María"}
]

📋 Los Métodos HTTP en Profundidad

Cada método tiene tres propiedades clave: Safe (no modifica recursos), Idempotent (N llamadas = 1 llamada en efecto) y Body (admite cuerpo en el request).

Método Safe Idempotent Body Uso típico
GETLeer recurso. Cacheable. Visible en logs/historial.
POSTCrear recurso. Procesos no idempotentes (login, pagos).
PUTReemplazo completo de recurso. Si llamas 5×, mismo estado.
PATCH⚠️Modificación parcial (JSON Patch, JSON Merge Patch).
DELETE⚠️Eliminar recurso. Idempotente: borrar ya borrado = 404 o 204.
HEADComo GET pero sin body. Verificar existencia, tamaño, fecha.
OPTIONSDescubrir capacidades. Preflight CORS lo usa.
TRACEEco para debugging. Casi siempre deshabilitado por seguridad.
CONNECTEstablecer túnel TCP (proxies HTTPS).

🔐 Demo Interactivo: Handshake TLS 1.3

Cuando entras a una URL https://..., antes del primer byte HTTP ocurre un handshake TLS. En TLS 1.3 toma 1 RTT (round-trip-time). Click Reproducir para ver el flujo paso a paso:

Esperando inicio...
CLIENT SERVER ClientHello + KeyShare cipher suites · supported versions · random ServerHello + Certificate + Finished cert X.509 firmado · KeyShare server ClientFinished + Verify cliente verifica certificado · deriva session keys 🔒 Application Data (AES-256-GCM) canal cifrado · HTTP requests/responses fluyen ✓ Conexión segura establecida

🚦 Códigos de Estado HTTP

Click cualquier código para ver su significado:

Click un código arriba para ver su descripción detallada...

Las 5 clases de status codes:

  • 1xx Informational — petición recibida, continuando.
  • 2xx Success — petición exitosa.
  • 3xx Redirection — más acciones necesarias.
  • 4xx Client Error — la petición tiene problemas.
  • 5xx Server Error — el servidor falló al procesar.

🚄 Demo Interactivo: HTTP/1.1 vs HTTP/2 (Multiplexing)

La diferencia más visible entre HTTP/1.1 y HTTP/2 es cómo manejan múltiples requests. HTTP/1.1 los hace en serie (con head-of-line blocking). HTTP/2 los multiplex en paralelo. Click para ver:

HTTP/1.1 — secuencial (con keep-alive, 1 conexión)

HTTP/2 — multiplexed (1 conexión, streams paralelos)

☕ Ejemplos: Backend Spring Boot (Java)

Un controller REST completo en Spring Boot que implementa todos los métodos contra una entidad User:

package com.example.api;

import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;
import java.util.*;

@RestController
@RequestMapping("/api/users")
public class UserController {

    private final Map<Long, User> store = new HashMap<>();

    // ── GET /api/users → listar todos ──
    @GetMapping
    public List<User> listAll() {
        return new ArrayList<>(store.values());
    }

    // ── GET /api/users/{id} → obtener uno ──
    @GetMapping("/{id}")
    public ResponseEntity<User> getOne(@PathVariable Long id) {
        User u = store.get(id);
        return u != null
            ? ResponseEntity.ok(u)
            : ResponseEntity.notFound().build();
    }

    // ── POST /api/users → crear nuevo (no idempotente) ──
    @PostMapping
    public ResponseEntity<User> create(@RequestBody User u) {
        u.setId(System.currentTimeMillis());
        store.put(u.getId(), u);
        return ResponseEntity.status(201).body(u);
    }

    // ── PUT /api/users/{id} → reemplazo completo (idempotente) ──
    @PutMapping("/{id}")
    public User replace(@PathVariable Long id, @RequestBody User u) {
        u.setId(id);
        store.put(id, u);
        return u;
    }

    // ── PATCH /api/users/{id} → modificación parcial ──
    @PatchMapping("/{id}")
    public User patch(@PathVariable Long id, @RequestBody Map<String, Object> patch) {
        User u = store.get(id);
        if (patch.containsKey("name")) u.setName((String) patch.get("name"));
        if (patch.containsKey("email")) u.setEmail((String) patch.get("email"));
        return u;
    }

    // ── DELETE /api/users/{id} → eliminar (idempotente) ──
    @DeleteMapping("/{id}")
    public ResponseEntity<Void> delete(@PathVariable Long id) {
        store.remove(id);
        return ResponseEntity.noContent().build();  // 204
    }

    // ── HEAD se genera automáticamente desde el GET ──

    // ── OPTIONS → describe métodos permitidos (CORS preflight) ──
    @RequestMapping(method = RequestMethod.OPTIONS)
    public ResponseEntity<Void> options() {
        return ResponseEntity.ok()
            .header("Allow", "GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS")
            .build();
    }
}

📜 Ejemplos: Frontend con fetch (JavaScript)

Cómo invocar el backend anterior desde JavaScript moderno con la API fetch:

// ── GET: leer todos los usuarios ──
const users = await fetch("/api/users").then(r => r.json());

// ── POST: crear usuario ──
const created = await fetch("/api/users", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ name: "Andrés", email: "a@x.com" })
}).then(r => r.json());

// ── PUT: reemplazar (todos los campos requeridos) ──
await fetch(`/api/users/${created.id}`, {
    method: "PUT",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ name: "Andrés Pacheco", email: "ap@x.com" })
});

// ── PATCH: modificar solo email ──
await fetch(`/api/users/${created.id}`, {
    method: "PATCH",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ email: "new@x.com" })
});

// ── DELETE: eliminar ──
await fetch(`/api/users/${created.id}`, { method: "DELETE" });

// ── HEAD: ¿existe el recurso? ──
const res = await fetch("/api/users/123", { method: "HEAD" });
console.log(res.ok, res.headers.get("Last-Modified"));

// ── OPTIONS: descubrir capacidades ──
const opts = await fetch("/api/users", { method: "OPTIONS" });
console.log(opts.headers.get("Allow"));
🌐🔐

HTTP es el lenguaje de la web · HTTPS es el lenguaje de la web segura

Desde el primer GET en CERN hasta los streams multiplex de HTTP/3 sobre QUIC, el protocolo evolucionó pero su filosofía es la misma: simplicidad textual, cliente-servidor, stateless. Dominar HTTP es la base de cualquier carrera en desarrollo web, móvil, APIs o cloud.

Guía interactiva escrita en mayo 2026 · HTTP/3 + TLS 1.3 vigentes · Próxima revisión: HTTP/4 (en draft IETF)