// Engineering Log

HTTP, HTTPS y TLS: Parte 1 — Qué es HTTP: solicitud, respuesta, métodos y códigos de estado

Publicado el 25.09.2026

// Ruta rapida

Este articulo pertenece al tema Redes y enrutamiento.

Necesito ayuda con este tema Pagina del tema

HTTP (HyperText Transfer Protocol) — protocolo de aplicación por el que el navegador, una app móvil o un script solicita un recurso al servidor y recibe una respuesta. El recurso puede ser una página HTML, una imagen, un JSON de una API o un archivo para descargar. HTTP no mantiene estado entre solicitudes: cada solicitud la procesa el servidor por separado, y la “memoria” sobre el usuario — sesión, carrito, inicio de sesión en la cuenta — la proporcionan las cookies y los tokens que el cliente envía en los encabezados.

Actualmente HTTP está descrito por un conjunto de documentos del IETF de 2022: RFC 9110 define la semántica general (métodos, códigos, encabezados), y RFC 9112, 9113 y 9114 — la forma de transmisión por la red para HTTP/1.1, HTTP/2 y HTTP/3. La semántica es la misma en todas las versiones; solo difiere cómo viajan los bytes por la red. Por eso todo lo que está escrito en esta parte es válido para cualquier versión.

Cómo se ve el intercambio

El cliente abre una conexión TCP con el servidor (para HTTP — puerto 80, para HTTPS — 443), envía la solicitud y espera la respuesta. En HTTP/1.1 esto es texto plano, y es cómodo examinarlo con curl -v:

bash
curl -v http://example.com/

Las líneas con > — lo que envió curl; las con < — la respuesta del servidor:

> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/8.7.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html
< Content-Length: 1256
< Cache-Control: max-age=3600
<
<!doctype html>
...

De qué se compone la solicitud

  1. Línea inicial: método, ruta y versión del protocolo — GET /catalog?page=2 HTTP/1.1. La ruta incluye la cadena de consulta (?page=2), pero no incluye el fragmento (#section) — el fragmento el navegador no lo envía al servidor.
  2. Encabezados: pares Nombre: valor, uno por línea. Obligatorio solo Host — con él el servidor entiende qué sitio en esa IP quiere el cliente.
  3. Línea vacía — fin de los encabezados.
  4. Cuerpo — opcional. Lo llevan los métodos que envían datos: POST, PUT, PATCH. El servidor conoce la longitud del cuerpo por el encabezado Content-Length o por la fragmentación en partes Transfer-Encoding: chunked.

La mayúscula/minúscula en los nombres de los encabezados no importa: Content-Type y content-type es el mismo encabezado. En HTTP/2 y HTTP/3 los nombres siempre se envían en minúsculas.

De qué se compone la respuesta

  1. Línea de estado: versión, código y frase explicativa — HTTP/1.1 404 Not Found. La frase es útil solo para humanos; los programas miran el código; en HTTP/2 y HTTP/3 directamente no existe.
  2. Encabezados de respuesta: tipo de contenido, longitud, reglas de caché, cookies, encabezados de seguridad.
  3. Línea vacía y cuerpo.

Métodos

El método indica al servidor qué quiere hacer el cliente con el recurso. RFC 9110 define ocho métodos, y uno más (PATCH) está en el RFC 5789.

MétodoPropósitoSeguroIdempotenteCuerpo de la solicitud
GETobtener un recursosísíno se usa
HEADigual que GET, pero solo los encabezadossísíno
POSTenviar datos para su procesamiento: formulario, creación de objetononosí
PUTcrear o reemplazar completamente un recurso en la direcciónnosísí
PATCHmodificar parcialmente un recursononosí
DELETEeliminar un recursonosínormalmente no
OPTIONSsaber qué métodos están disponibles; se usa en CORSsísínormalmente no
CONNECTabrir un túnel a través de un proxy, normalmente para HTTPSnonono
TRACEdevolver la solicitud para depuración; en servidores normalmente está deshabilitadosísíno

Un método seguro no cambia el estado en el servidor: se puede invocar tantas veces como se quiera sin estropear nada. Por eso los robots de búsqueda y la función de precarga del navegador pueden seguir enlaces libremente — los enlaces siempre apuntan a GET. Si la eliminación de un registro en el panel de administración se hace a través de GET /delete?id=5, tarde o temprano lo ejecutará algún robot o un antivirus que compruebe enlaces en correos.

Un método idempotente produce el mismo resultado si se repite. PUT /users/5 con el mismo cuerpo dos veces dejará al usuario en el mismo estado, mientras que dos POST /orders idénticos crearán dos pedidos. Esto es importante para reintentos: clientes, proxies y balanceadores pueden reintentar automáticamente una solicitud idempotente tras una caída de conexión, pero no POST. De ahí la advertencia del navegador «¿Enviar de nuevo los datos del formulario?» al actualizar la página después de un POST.

Formalmente no está prohibido enviar cuerpo en GET, pero por la especificación carece de sentido, y muchos proxies y servidores lo descartan. Los parámetros de GET se pasan en la cadena de consulta.

Códigos de estado

El código es un número de tres cifras; la primera cifra indica la clase.

1xx — informativos. Respuestas intermedias, después vendrá la final.

  • 100 Continue — el servidor está listo para aceptar un cuerpo grande (el cliente lo pregunta con el encabezado Expect: 100-continue; curl lo añade automáticamente al enviar cuerpos grandes);
  • 101 Switching Protocols — el servidor cambia a otro protocolo, por ejemplo WebSocket (más detalles — HTTP, HTTPS y TLS: Parte 7 — Transición a HTTPS: redirecciones, HSTS, HTTPS-First y el encabezado Upgrade);
  • 103 Early Hints — pistas tempranas: el servidor aún prepara la página, pero ya indica qué estilos y scripts conviene comenzar a cargar.

2xx — éxito.

  • 200 OK — respuesta exitosa habitual;
  • 201 Created — recurso creado, su dirección en el encabezado Location;
  • 204 No Content — éxito, sin cuerpo (respuesta frecuente a DELETE y PUT);
  • 206 Partial Content — se entregó una parte del archivo por petición Range; esto permite reanudar descargas y “seek” en vídeo.

3xx — redirecciones. La dirección a la que ir está en el encabezado Location.

  • 301 Moved Permanently y 308 Permanent Redirect — el recurso se mudó permanentemente; los buscadores transfieren la autoridad al nuevo URL, el navegador recuerda el redireccionamiento;
  • 302 Found y 307 Temporary Redirect — redirección temporal;
  • 304 Not Modified — el recurso no cambió, se puede tomar copia desde la caché.

La diferencia entre 301/302 y 308/307 está en el método: con 301 y 302 los navegadores históricamente convierten POST a GET y pierden el cuerpo, mientras que 307 y 308 obligan a repetir la solicitud con el mismo método y el mismo cuerpo. Para redirigir APIs o formularios usa 307/308.

4xx — error del cliente. La solicitud es incorrecta; repetirla sin cambios no tiene sentido.

  • 400 Bad Request — solicitud sintácticamente incorrecta, JSON malformado;
  • 401 Unauthorized — se requiere autenticación (pese al nombre, significa que el cliente no se identificó); el servidor envía el encabezado WWW-Authenticate con el método de acceso;
  • 403 Forbidden — el cliente está identificado, pero no tiene permiso;
  • 404 Not Found — el recurso no existe;
  • 405 Method Not Allowed — el método no está soportado para esa dirección;
  • 408 Request Timeout — el cliente tardó demasiado en enviar la solicitud;
  • 409 Conflict — conflicto con el estado actual, por ejemplo la versión del objeto está obsoleta;
  • 413 Content Too Large — el cuerpo es más grande de lo permitido (en Nginx — client_max_body_size, por defecto 1 MB);
  • 415 Unsupported Media Type — el servidor no acepta ese Content-Type;
  • 429 Too Many Requests — se ha activado un límite de tasa; en el encabezado Retry-After puede indicar el tiempo de espera;
  • 451 Unavailable For Legal Reasons — acceso restringido por requerimiento legal.

5xx — error del servidor. Con la solicitud no hay problema, algo falló en el lado del servidor.

  • 500 Internal Server Error — error no controlado en la aplicación;
  • 502 Bad Gateway — el proxy o balanceador no recibió una respuesta correcta de la aplicación detrás: la aplicación falló, cerró la conexión o respondió basura;
  • 503 Service Unavailable — el servicio no está disponible temporalmente: sobrecarga, mantenimiento;
  • 504 Gateway Timeout — el proxy no esperó la respuesta de la aplicación.

Los códigos 502 y 504 casi siempre los devuelve no la propia aplicación, sino el Nginx, HAProxy o CDN que está delante de ella. Si ves un 502, revisa el registro del proxy — allí estará la causa, por ejemplo connect() failed (111: Connection refused) while connecting to upstream.

URL y qué llega al servidor

La dirección https://user@shop.example.ru:8443/catalog/phones?sort=price#reviews se descompone así:

  • https — esquema, determina el protocolo y el puerto por defecto;
  • user@ — credenciales de usuario; los navegadores ya no las soportan, curl las convierte en el encabezado Authorization;
  • shop.example.ru — host, se resuelve en IP vía DNS y se pasa en Host (y en HTTPS también en SNI);
  • 8443 — puerto, si no es el estándar;
  • /catalog/phones — ruta;
  • sort=price — cadena de consulta;
  • reviews — fragmento, queda en el navegador.

Los caracteres fuera de ASCII y los caracteres reservados en la ruta y parámetros se codifican con porcentajes: espacio — %20, la «я» cirílica — %D1%8F. El dominio en cirílico se codifica de otra forma — en Punycode (пример.рф → xn--e1afmkfd.xn--p1ai), y es en ese formato que se envía al DNS y en Host.

Conexiones y keep-alive

En HTTP/1.0 para cada solicitud se abría una nueva conexión TCP. En HTTP/1.1 la conexión por defecto permanece abierta, y las siguientes solicitudes van por la misma: no es necesario rehacer el apretón de manos de tres vías de TCP y, para HTTPS, el apretón de manos de TLS. Para pedir el cierre de la conexión después de la respuesta se usa el encabezado Connection: close.

Las solicitudes por una única conexión en HTTP/1.1 van estrictamente en orden: solo se puede enviar la siguiente tras la respuesta de la anterior. Por eso los navegadores abren hasta seis conexiones en paralelo hacia un mismo sitio. Este problema lo resolvieron HTTP/2 y HTTP/3.

HTTP y HTTPS

HTTPS es el mismo HTTP, pero transmitido dentro de una conexión TLS cifrada. La solicitud y la respuesta se ven igual, cambia el transporte: primero cliente y servidor acuerdan claves y verifican el certificado, y solo después por el canal protegido circulan los mensajes HTTP. Sin TLS todo lo anterior — la dirección, las cookies, las contraseñas de formularios, el contenido de las páginas — lo puede ver y modificar cualquier nodo en la ruta: el Wi-Fi de un café, el proveedor, un proxy.

Pruébalo tú mismo

HTTP/1.1 es un protocolo de texto, y la solicitud se puede teclear a mano, sin navegador ni curl. Los comandos siguientes funcionan en Linux y macOS.

Solicitud por HTTP con nc. Cada línea termina en \r\n, tras los encabezados hay una línea vacía. sleep es necesario para que nc no cierre la conexión antes de que llegue la respuesta:

bash
{ printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n'; sleep 2; } | nc example.com 80 | head -6
HTTP/1.1 200 OK
Date: Thu, 24 Sep 2026 04:54:21 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: close
Server: cloudflare

Quita la línea Host — el servidor responderá 400 Bad Request: sin ella no sabe qué sitio necesitas.

La misma solicitud por HTTPS. openssl s_client establece la conexión TLS y envía la entrada tal cual:

bash
printf 'HEAD / HTTP/1.1\r\nHost: example.ru\r\nConnection: close\r\n\r\n' \
  | openssl s_client -quiet -connect example.ru:443 -servername example.ru 2>/dev/null

Métodos y códigos de estado. Mira cómo responde tu sitio a distintos métodos y a una dirección inexistente:

bash
curl -s -o /dev/null -w '%{http_code}\n' https://example.ru/                 # 200
curl -s -o /dev/null -w '%{http_code}\n' https://example.ru/no-such-page/    # debería ser 404, no 200
curl -s -o /dev/null -w '%{http_code}\n' -X DELETE https://example.ru/       # 405 o 403
curl -si -X OPTIONS https://example.ru/ | grep -iE '^(HTTP|allow)'            # qué métodos están permitidos
curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' http://example.ru/   # 301 a https

Si en una dirección inexistente el sitio responde 200 con una página «No encontrado», los buscadores consideran esas páginas reales y las indexan — esto se llama soft 404, y Google Search Console marca esas páginas por separado.

La propia solicitud HTTP desde curl. Con la opción -v se ve qué encabezados curl añadió por sí mismo — compáralos con lo que envía el navegador (DevTools → Network → Headers → Request Headers):

bash
curl -sv -o /dev/null https://example.ru/ 2>&1 | grep '^>'

Errores típicos

  • Modificar datos vía GET — un robot o la precarga ejecutarán la acción sin conocimiento del usuario.
  • Redirigir formularios y APIs con 301/302 — se pierde el cuerpo del POST. Se necesitan 307 o 308.
  • 200 con texto de error en el cuerpo en lugar de código 4xx/5xx — el monitoreo y las cachés consideran la respuesta exitosa, un CDN puede cachear la página de error.
  • 401 en lugar de 403 y viceversa — el cliente no entiende si debe autenticarse o si la autenticación no ayudará.
  • Reintento automático de POST en el propio cliente tras un timeout — pedidos y pagos dobles. Para reintentos seguros se usa una clave de idempotencia en un encabezado (así lo hacen las API de pagos).
Etiquetas:
#http#https#web#curl#red#protocolos

// Tarea parecida

Si estas resolviendo algo parecido

Este articulo pertenece a uno de los temas principales de trabajo. Puedes seguir leyendo sobre el tema, ir a la pagina principal para entender a que me dedico o abrir directamente los servicios.

Tema del articulo

Redes y enrutamiento

MikroTik, VPN, enrutamiento, DNS, BGP, conectividad y problemas de acceso.

Tareas frecuentes de esta tema

  • Montar VPN y acceso seguro a oficina o nube
  • Corregir enrutamiento, DNS o conectividad inestable
  • Configurar MikroTik, firewall y enlaces externos

// Siguiente paso

Si necesitas ayuda con este tema y no solo otro articulo, es mejor ir directo a la pagina del servicio. La pagina principal y la seleccion de materiales quedan como rutas secundarias.

Abrir servicios
Que hago Todos los materiales sobre este tema

// Reviews

Reseñas relacionadas

Muchísimas gracias a Mijaíl por su trabajo, estoy muy satisfecho con el resultado. Agradezco especialmente las recomendaciones durante la configuración: a partir de un pliego de requisitos bastante confuso por mi parte (y yo entiendo poco de servidores), Mijaíl, con preguntas aclaratorias y propuestas, formuló una comprensión clara de qué tareas resolvería la configuración final y cómo organizarlo todo de la mejor manera. ¡Lo recomiendo!

Muchísimas gracias a Mijaíl por el trabajo, estoy muy satisfecho con el resultado. Agradezco especialmente las recomendaciones durante el proceso de configuración; a partir de mi especificación bastante confusa (y yo sé …

ladohinpy

Configuración de Mikrotik hAP. Configuraré su router Wi‑Fi Mikrotik.

21.07.2025 · ★ 5/5

Excelente profesional, experto y persona maravillosa. En una hora nos arregló lo que llevábamos días intentando solucionar. Estoy seguro de que no será la primera vez que recurramos a su excepcional profesionalismo.

Excelente especialista, un experto con mucha experiencia y una persona maravillosa. En una hora nos arregló aquello por lo que llevábamos días rompiéndonos la cabeza! Estoy seguro de que no será la primera vez que …

Ravenor

MikroTik hAP: configuración del router. Configuraré su router MikroTik Wi‑Fi.

28.05.2025 · ★ 5/5

¡Un enfoque profesional!

¡Enfoque profesional al asunto!

ErlikZ

Configuración del router Mikrotik hAP. Configuraré su router Mikrotik Wi-Fi.

31.03.2025 · ★ 5/5

// Contact

¿Necesitas ayuda?

Escríbeme y te ayudaré a resolver el problema

Escribir a task@bigmike.help Telegram →

Respondo en un día laborable (03:00-13:00 GMT)

Или оставьте заявку здесь:

Confirme que no es un bot.

// Related

Publicaciones relacionadas

Escribir y recibir una respuesta rápida