Resumen

  • La RFC 6455 abría WebSocket con GET, Upgrade y una respuesta 101 de HTTP/1.1. La RFC 7540 eliminó ese cambio de protocolo de HTTP/2, donde una conexión sostiene varios flujos.
  • La RFC 8441 añadió CONNECT ampliado con :protocol = websocket, :scheme y :path, utilizable después de recibir SETTINGS_ENABLE_CONNECT_PROTOCOL = 1 del servidor. La IANA registra el parámetro 0x8 con valor inicial 0.
  • El flujo aceptado transporta tramas WebSocket sin expulsar a sus vecinos. La apertura deja atrás Connection, Upgrade y el intercambio Sec-WebSocket-Key/Accept; el protocolo WebSocket continúa dentro del flujo.

La llave antigua quería quedarse con todo el edificio

En 2011, el protocolo WebSocket aprovechó una puerta de HTTP/1.1. El cliente enviaba GET con Upgrade: websocket y Connection: Upgrade. Si el servidor respondía 101 Switching Protocols, la conexión TCP pasaba a ser el canal de dos direcciones. En un mundo en el que cada conexión atendía una petición, ceder el conducto entero a una conversación resultaba comprensible.

HTTP/2 repartió ese conducto entre flujos simultáneos. La misma conexión puede entregar estilos e imágenes mientras otra función espera mensajes nuevos. La RFC 7540 quitó la respuesta 101: un cambio que afecta a toda la conexión no encaja con flujos que deben continuar por separado. Upgrade y Connection hablaban del transporte común. Un WebSocket que los empleara para abrirse exigiría poder sobre las solicitudes ajenas.

La contradicción aparecía antes de escribir una sola línea de aplicación. La página ya tenía una conexión HTTP/2 activa, pero la conversación necesitaba otra ceremonia. Crear otro conducto para conservar el viejo saludo desperdiciaba la convivencia que HTTP/2 había introducido. La RFC 8441 redujo el alcance de la petición: un flujo, no la propiedad del enlace compartido.

Primero habla el servidor

El servidor anuncia SETTINGS_ENABLE_CONNECT_PROTOCOL = 1. El registro oficial de parámetros HTTP/2 asigna a este ajuste el código 0x8 y el valor inicial 0. Solo después de recibir el valor 1 puede el cliente utilizar CONNECT ampliado en flujos nuevos. Enviarlo antes convertiría la solicitud en una forma que un servidor sin la extensión considera mal formada. Ese orden hace visible el permiso de reinterpretar CONNECT.

Con permiso, el cliente abre un flujo con :method = CONNECT y :protocol = websocket. Incluye :scheme, :path y :authority para la URI de destino. Aquí está la trampa para una implementación apresurada: el CONNECT ordinario toma :authority como el host al que abrir un túnel. En el CONNECT ampliado, el campo es la autoridad de la URI solicitada. La RFC 8441 prohíbe que el servidor abra un túnel tradicional hacia ese host solo por ver CONNECT. :protocol declara la función del nuevo flujo.

Una URI WebSocket segura utiliza https como esquema de destino; una no segura, http. Ruta y autoridad siguen localizando el recurso. El caso de un proxy HTTP/2 hacia delante conserva otra secuencia: primero se usa CONNECT tradicional para llegar al servidor WebSocket; la versión HTTP dentro de ese túnel determina después cómo se inicia WebSocket. Confundir el túnel del proxy con el flujo ampliado de origen cambia el destino y la responsabilidad de la conexión.

El 200 sustituyó al espectáculo del 101

La apertura ampliada ya no manda el GET con Connection y Upgrade, ni realiza el intercambio HTTP/1.1 Sec-WebSocket-Key y Sec-WebSocket-Accept. En esta ruta, :protocol sustituye aquel procesamiento. Siguen vigentes los campos de origen, versión WebSocket, subprotocolo y extensiones según las reglas de WebSocket. Cambia la admisión al canal; no desaparecen las tramas que circularán por él.

El ejemplo de la RFC muestra el ajuste del servidor, CONNECT ampliado y una respuesta :status = 200. A partir de ahí, los DATA de HTTP/2 llevan los datos WebSocket en ambos sentidos. El flujo asume el papel que antes tenía la conexión TCP completa. Conserva prioridad, cancelación y control de flujo de HTTP/2; END_STREAM y RST_STREAM distinguen el cierre ordenado del cierre excepcional. En paralelo siguen vivos los demás flujos.

Eso cambia una decisión cotidiana de operación. El servicio puede dejar abierta una conversación larga sin secuestrar la descarga de imágenes. El servidor puede negar la nueva apertura omitiendo el ajuste. El cliente puede comprobar esa ausencia antes de construir la solicitud. La compatibilidad nace de un permiso anunciado y de una petición delimitada, no de imaginar cómo habría funcionado un 101 en tráfico multiplexado.

La conexión conservó a sus demás inquilinos

La RFC 8441 prefirió una intervención concreta a rediseñar WebSocket desde cero. Cambió la ceremonia de entrada para que WebSocket y HTTP/2 pudieran compartir transporte. Después del 200 siguen funcionando las tramas WebSocket y gran parte de las consideraciones de seguridad de la RFC 6455. El enmascaramiento de esas tramas pertenece a otra capa de la historia; aquí importa quién puede reclamar el canal que las lleva.

Los textos oficiales prueban el mecanismo y el registro del ajuste. Para afirmar que un servicio concreto lo utilizó hacen falta versiones fechadas de cliente, servidor y proxy, además de capturas de SETTINGS y HEADERS. El giro histórico ya está en el estándar: HTTP/2 no entregó una conexión colectiva a una sola conversación. Le asignó a WebSocket un flujo, bajo condiciones que ambos extremos podían ver.