MASQUE y CONNECT-UDP para operadores web
Comprende MASQUE y CONNECT-UDP, el papel de los datagramas HTTP y qué debe confirmarse con un proveedor de proxy.
Quieres la documentación estructurada de Red?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
Por qué existe MASQUE
Las aplicaciones web usan cada vez más transportes que no encajan en un túnel HTTP tradicional de solicitud y respuesta. MASQUE reúne enfoques para transportar tráfico a través de proxies HTTP. Para operaciones, el valor es contar con funciones de proxy descritas de forma estándar; el nombre por sí solo no demuestra que un servicio concreto las ofrezca.
MASQUE abarca varias capas de protocolo. HTTP define la semántica de solicitudes y respuestas, HTTP/2 o HTTP/3 suele proporcionar la conexión con el proxy y la función solicitada determina cómo se transporta el tráfico. RFC 9298 especifica el proxy de UDP sobre HTTP, mientras que RFC 9297 define los datagramas HTTP y el protocolo Capsule usados por extensiones relacionadas.
El espacio del problema se entiende mejor si los nombres se tratan como funciones y no como una marca de producto. Un proxy puede exponer un punto HTTP, aceptar una solicitud CONNECT-UDP y aplicar después una autorización independiente para el destino. Otro servicio puede admitir túneles HTTPS normales, pero no tener ningún retransmisor UDP. Ambos pueden usar palabras HTTP conocidas en su documentación y aun así ofrecer capacidades operativas distintas. Empieza por la función que necesita la aplicación y asigna cada responsabilidad al equipo que la posee.
MASQUE también ofrece un vocabulario común para los límites. El cliente conoce el endpoint del proxy y su política local. El proxy conoce los destinos que retransmitirá y el transporte que puede alcanzar. El origen conoce su protocolo de aplicación y sus controles de acceso. Estos límites no desaparecen cuando la conexión está cifrada. Solo resultan más difíciles de ver si se toma una navegación correcta del navegador como prueba de todas las capacidades intermedias.
Por tanto, el operador puede formular preguntas centradas en resultados. ¿Qué versión HTTP se usa entre cliente y proxy? ¿CONNECT-UDP está incluido para la cuenta y el endpoint exactos? ¿El proveedor documenta la autorización del destino y la disponibilidad regional? ¿Qué estado visible se acepta cuando la función no está disponible? Estas preguntas permiten calificar un servicio sin pedir detalles internos.
Qué significa CONNECT-UDP
Sobre HTTP/2 y HTTP/3, CONNECT-UDP es la solicitud CONNECT extendida de RFC 9298 que usa el valor :protocol=connect-udp para pedir al proxy un contexto de comunicación UDP; sobre HTTP/1.1, la misma función de solicitud usa un HTTP Upgrade a connect-udp. La solicitud se dirige al proxy, que decide si acepta el destino solicitado según su propia política. No es una orden que convierta un origen web corriente en un proxy, y una petición del navegador no demuestra que el proxy pueda alcanzar cualquier destino.
La palabra «conectar» puede inducir a error porque el contexto resultante no es un socket extremo a extremo propiedad de la página. El proxy sigue siendo un intermediario con autorización, límites y fallos propios. La aplicación web continúa hablando su protocolo sobre el contexto permitido, y el destino decide si acepta ese protocolo. Esta separación importa cuando un servicio anuncia UDP, pero restringe destinos, puertos, regiones o clases de cuenta concretas.
CONNECT-UDP tampoco es una promesa general sobre las API del navegador. Una página no puede seleccionar un tipo de solicitud proxy solo con nombrarlo en JavaScript, y el navegador no puede fabricar un servicio de retransmisión que el proveedor configurado no ofrece. El navegador, el proxy y el destino necesitan políticas compatibles. Una revisión debe describir el flujo observable y la ruta aprobada, no suponer que un token de protocolo concede una capacidad de red nueva.
La solicitud CONNECT extendida pertenece a un plano de control HTTP más amplio. La autenticación, la autorización, el ciclo de vida de la solicitud y los errores siguen el contrato del proxy. Un proveedor puede rechazar la solicitud antes de cualquier intercambio UDP, cerrar después un contexto aceptado o limitar el destino según la política del servicio. La aplicación debe conservar una recuperación clara para cada categoría en lugar de presentar todos los fallos como un error de página genérico.
El operador debe separar tres responsabilidades: la conexión entre cliente y proxy, el servicio de retransmisión UDP del proxy y el comportamiento de la aplicación de destino. Conectarse al proxy solo establece el primer tramo. La compatibilidad del proveedor, la política de la cuenta, la alcanzabilidad del destino y la compatibilidad de la aplicación son condiciones distintas. Esto difiere en alcance de la ruta proxy QUIC y UDP sobre SOCKS5, que describen sus propios procedimientos de configuración y operación.
Datagramas y cápsulas
Los datagramas HTTP permiten asociar cargas de datagrama con un contexto HTTP, mientras que el protocolo Capsule transporta información de control definida por extensiones en un flujo HTTP. Sus funciones están relacionadas, pero son distintas: los datagramas llevan tráfico orientado a datagramas; las cápsulas pueden comunicar cambios de contexto u otros mensajes de control. La correspondencia exacta depende de la extensión y del transporte, por lo que no conviene tratarlos como descripciones intercambiables de un único formato de paquete.
Cuando interviene HTTP/3, QUIC es el transporte para los flujos y datagramas HTTP/3 según las especificaciones pertinentes. Esa relación no significa que toda solicitud HTTP/3 use CONNECT-UDP ni que la compatibilidad con HTTP/3 pruebe que un proxy admite MASQUE. Para los límites de negociación y compatibilidad del navegador, consulta compatibilidad del navegador con HTTP/3 y QUIC.
Los datagramas HTTP se asocian con un contexto HTTP, lo que da a una extensión un lugar para relacionar el tráfico de datagramas con el estado de la solicitud. Los mensajes Capsule viajan por un flujo HTTP fiable y pueden transportar instrucciones o información de contexto definida por la extensión. La diferencia permite elegir la propiedad de entrega necesaria para cada tipo de información. Aunque un datagrama viaje en una cápsula DATAGRAM sobre un flujo (como en HTTP/2), conserva la semántica de datagrama, así que la aplicación no debe depender de una entrega fiable; tampoco esta diferencia convierte Capsule en un lenguaje de control universal.
El transporte subyacente también importa. HTTP/3 usa QUIC, cuyos flujos y funciones de datagrama tienen su propio comportamiento de conexión y pérdida. HTTP/2 tiene otro conjunto de reglas de encuadre y extensiones. Un proveedor puede admitir una función MASQUE sobre una versión HTTP y limitarla sobre otra. Pregunta qué combinaciones están calificadas en vez de inferir la capacidad de una declaración genérica sobre HTTP.
Para el responsable de la aplicación, la cuestión práctica es qué semántica necesita. Una función interactiva puede necesitar entrega de datagramas y tolerar pérdidas, mientras una decisión de autorización puede requerir un mensaje de control fiable. El operador no tiene que rediseñar esas semánticas en el proxy; debe confirmar que el servicio y la política del navegador conservan el contrato de la aplicación y muestran un fallo acotado cuando no pueden hacerlo.
Revisión operativa
Antes de adoptar un servicio proxy con capacidad UDP, confirma qué endpoint, plan de cuenta, región, política de destinos y condiciones de concurrencia incluyen CONNECT-UDP. Pregunta cómo informa el servicio de los rechazos y cuáles son sus expectativas documentadas de disponibilidad. Registra el resultado de aplicación que importa y una recuperación aprobada; no deduzcas que la retransmisión UDP funciona porque cargue una página HTTPS corriente.
Mantén el registro de calificación al mismo nivel que la decisión de producción. Nombra la versión del navegador, la política del contexto, la clase de endpoint del proveedor, la región, la autorización de la cuenta y la categoría de destino. Registra si el flujo principal terminó, si una función opcional quedó no disponible y qué responsable recibe la siguiente acción. Así se puede repetir la evidencia tras un cambio sin guardar contenido de clientes ni secretos en un documento público.
Revisa el proxy y el origen como dependencias separadas. El proxy puede aceptar la solicitud de control mientras el origen rechaza el protocolo de aplicación. También puede ocurrir que el origen admita la aplicación y la cuenta del proxy no incluya la operación requerida. Una categoría de incidente útil identifica el límite que falló y la recuperación o escalado aprobado. No debe exponer credenciales, historiales privados ni capturas detalladas a un usuario final.
La política de ruta también debe decir qué no está permitido. Si la función UDP no está disponible, un flujo HTTP/2 aprobado puede continuar cuando la aplicación lo permite, o una función puede mostrarse como no disponible hasta resolver el problema del proveedor. Una conexión directa que parece hacer que la página cargue no es una alternativa implícita. Tratarla como tal cambiaría el límite de red sin una decisión explícita.
La documentación del proveedor es necesaria, pero no constituye evidencia permanente. Repite la revisión tras un cambio de plan, migración de endpoint, cambio regional, actualización principal del navegador o cambio importante del origen. Compara el mismo flujo y conserva la última política aceptada mientras se evalúa una candidata. La etiqueta del protocolo ayuda a explicar un resultado, pero el resultado del cliente y la recuperación son los criterios de aceptación.
Trata los fallos como resultados acotados de capacidad o disponibilidad. La falta de una operación corresponde al proveedor o al responsable del despliegue; la alternativa específica de la aplicación corresponde a su responsable. Conserva las credenciales y los registros detallados del tráfico en sistemas controlados. No crees una ruta directa como recuperación sin documentarla.
BotBrowser permite elegir una ruta proxy aprobada por contexto del navegador, lo que puede hacer repetible la misma política de red durante una revisión. No puede implementar un servicio MASQUE, añadir CONNECT-UDP a un proveedor ni controlar la retransmisión ascendente del proveedor o el comportamiento del origen. El enrutamiento por contexto es un límite de política del cliente, no sustituye la capacidad del proveedor.
El enrutamiento por contexto resulta útil cuando un proceso de navegador sirve varios flujos aprobados con requisitos de red distintos. El ajuste del contexto selecciona una ruta que el despliegue ya ha calificado; no crea una autorización nueva del proveedor ni cambia las decisiones de protocolo del destino. Aplica la política antes de la primera acción de página, registra el nombre de ruta junto al responsable del contexto y vincula el resultado visible con ese registro.
El límite del producto es deliberadamente concreto. BotBrowser puede repetir una ruta del cliente ya aprobada y ayudar a comparar el mismo flujo bajo una política documentada. No expone un servidor MASQUE, no implementa un retransmisor ascendente ni garantiza que un destino use HTTP/3. Esas capacidades pertenecen al proveedor, al origen y a la política de red circundante. Mantener el límite explícito evita confundir un ajuste del navegador con un contrato de servicio.
Cuando la ruta no está calificada, la acción responsable es elegir otra ruta aprobada, esperar la recuperación o detener el flujo. No uses una opción del navegador ni un script de página para inventar una operación CONNECT-UDP ausente. El registro operativo debe mostrar la decisión al soporte, mientras la evidencia sensible del proveedor permanece en los sistemas controlados de revisión.
El registro de ruta debe identificar la relación entre el contexto del navegador y la cuenta del proxy sin copiar un secreto en un comando, ticket o registro de página. Un nombre breve, responsable, región y resumen de capacidades suelen bastar para elegir la recuperación correcta. Guarda el acuerdo detallado del proveedor y la autorización en el sistema que controla su acceso.
Los equipos de aplicación deben indicar si UDP es necesario para la tarea principal o solo para una mejora opcional. Un documento, formulario o API corriente puede seguir siendo útil mediante una ruta aprobada basada en flujo. Una función en tiempo real puede mostrar un estado no disponible y permitir un intento posterior. Esta decisión debe formar parte del contrato de aplicación antes del incidente.
Un proveedor puede cambiar su comportamiento sin cambiar el token de protocolo :protocol=connect-udp. Puede modificar capacidad regional, límites de cuenta, política de destinos o versión HTTP admitida. Repite un flujo representativo tras esos cambios y compáralo con el último registro aceptado. La comparación debe centrarse en finalización, fallo acotado y responsable de recuperación, no en una etiqueta de transporte supuesta.
Las revisiones de versiones del navegador deben mantener separadas las funciones del protocolo. El navegador puede elegir una ruta configurada, negociar con un destino y mostrar un resultado visible. No certifica la política de retransmisión del proxy ni el servicio de aplicación del destino. Registra juntos la versión principal, la familia de perfil, la política de ruta y la categoría de destino para disponer de una base útil.
Los operadores de red también deben documentar los fallos esperados. Una solicitud CONNECT-UDP rechazada, un endpoint proxy no disponible y un error de aplicación del origen tienen responsables distintos aunque aparezcan durante el mismo flujo. Una categoría breve y una siguiente acción aprobada ayudan al soporte a dirigir el caso sin recopilar tráfico privado ni exponer credenciales.
La explicación más duradera se mantiene por capas: MASQUE nombra un espacio de proxy, CONNECT-UDP nombra una función de solicitud normalizada, los datagramas HTTP y las cápsulas describen mecanismos relacionados, y el contrato del proveedor determina lo que está disponible. BotBrowser puede repetir la política del cliente aprobada; el proveedor y el origen siguen siendo responsables de las capacidades del servicio más allá de ese límite.
Usa el mismo vocabulario en el procedimiento operativo y en el estado visible para clientes. «El proxy aceptó la solicitud HTTP» es más limitado que «la aplicación llegó al destino». «El retransmisor UDP no está disponible para esta cuenta» orienta mejor que «falló HTTP/3». Las palabras precisas asignan el incidente al equipo correcto y permiten elegir una recuperación autorizada.
El registro de aceptación no debe convertir los nombres de protocolo en promesas de rendimiento. QUIC, HTTP/3, los datagramas y el retransmisor proxy pueden cambiar el comportamiento de un flujo, pero también importan el destino, la cuenta y la red. Mide la tarea de aplicación relevante, guarda un resultado acotado y revisa el registro cuando cambie una condición.
La revisión puede ser ligera. Un nombre de ruta, versiones compatibles de navegador y perfil, una categoría de destino representativa y un estado claro de indisponibilidad bastan para una base operativa. Los registros detallados y la autorización del proveedor quedan en sistemas controlados. Una nota de estado pública solo debe indicar la función, el límite externo y la recuperación aprobada.
Esta separación ayuda cuando varios equipos comparten un despliegue. El responsable del contexto elige la ruta del cliente, el equipo de red califica al proveedor y el equipo de aplicación define la alternativa aceptable. Una transferencia breve entre responsables aporta más evidencia que suponer que una opción del navegador puede crear un servicio proxy ausente.
En una nota de versión, describe el resultado aceptado en términos sencillos: el contexto usó la política proxy aprobada, el flujo al destino terminó o mostró su estado documentado de indisponibilidad y se conocía el siguiente responsable. Enlaza después las normas públicas que explican las funciones, sin sugerir que el navegador proporciona el servicio del proveedor. Así el operador obtiene contexto suficiente sin exponer credenciales, destinos privados ni registros detallados.
Este lenguaje también facilita las entregas de soporte. Separa la decisión de política del navegador de la decisión del servicio, ofrece al responsable de la aplicación un estado concreto que probar y permite una ruta alternativa calificada. El mismo registro sirve para la revisión, el incidente y una nueva calificación del proveedor sin exponer el contenido de la sesión. Las páginas de estado públicas deben limitarse a funciones, resultados y límites; la evidencia propia de cada cuenta permanece en sistemas autorizados.
Ejecuta las comprobaciones de calificación
Aplica estas comprobaciones a cada ruta candidata y registra aprobado o fallido en cada una.
- La documentación del proveedor nombra la compatibilidad con CONNECT-UDP (RFC 9298) para la clase de endpoint y la cuenta. Registra la clase de endpoint, la autorización de la cuenta y la versión HTTP. Falla si la documentación solo afirma HTTP/3.
- El flujo representativo se ejecuta por la ruta aprobada del contexto. Aprueba si termina, o si acaba en un fallo acotado con un responsable nombrado. Registra el nombre de la ruta y la política de contexto usada.
- El estado del tramo del proxy se compara con el resultado del origen. Clasifica por separado «el proxy acepta, el origen rechaza» y el caso inverso.
- Una ruta sin CONNECT-UDP se registra como incompatibilidad de capacidad. Falla si el registro de la ejecución muestra que el flujo terminó por una ruta directa en lugar de la ruta aprobada.
- Si se aprueba una alternativa HTTP/2 para la aplicación, se registra como alternativa. Falla si se usó una alternativa y no se registró.
- Las comprobaciones se repiten tras un cambio de plan, una migración de endpoint, un cambio regional, una actualización mayor del navegador o un cambio importante del origen. Conserva la última política aceptada hasta que la repetición apruebe.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.