Planteamiento y contexto
Una sola sesión de WebTransport debe enviar vistas previas en vivo, mensajes de control y archivos grandes. Las vistas previas necesitan baja latencia, los mensajes de control deben llegar con prontitud y los archivos pueden ceder ancho de banda. Utilice WebTransportSendGroup, sendOrder y getStats() para diseñar la política de envío, incluidos los límites de prioridad, la congestión, las reconexiones, los navegadores no compatibles y los errores.
MDN describe un send group como un conjunto de flujos y datagramas cuya prioridad de envío relativa está determinada por sendOrder; la asignación de ancho de banda entre diferentes grupos está definida por la implementación. La interfaz sigue siendo experimental. Este artículo sintetiza material público y no pretende ser una pregunta de entrevista específica de una empresa.
Qué está evaluando el entrevistador
El entrevistador quiere ver si distingue el ordenamiento relativo dentro de un grupo de la equidad entre grupos, si asigna la prioridad del negocio a colas observables y si explica la diferencia entre datagramas no confiables y flujos ordenados confiables. Una respuesta sólida menciona createSendGroup(), pasar sendGroup al crear un flujo, sendOrder, getStats() a nivel de grupo, control de congestión y detección de capacidades; una respuesta débil se limita a decir "ponderar los mensajes importantes".
Preguntas para aclarar primero
- ¿Qué datos pueden descartarse y cuáles deben ser confiables, ordenados y duraderos?
- ¿Cuáles son el objetivo de latencia, el objetivo de rendimiento de archivos y la antigüedad máxima de la cola?
- ¿La prioridad es fija para la sesión o se modifica por acciones del usuario?
- ¿Los navegadores de destino admiten send groups y el mecanismo de respaldo puede expresar la misma semántica de negocio?
Una respuesta de 30 segundos
"Separaría los mensajes de control confiables, las vistas previas en tiempo real con tolerancia a pérdidas y la transferencia de archivos en segundo plano en miembros explícitos. Los miembros que necesitan un ordenamiento relativo comparten un send group, con sendOrder colocando el control y las vistas previas por delante de los archivos; esto no constituye una garantía de ancho de banda entre grupos. El remitente limita las colas y el tamaño de los elementos, observa el encolamiento y la finalización mediante getStats(), descarta vistas previas obsoletas y pausa los archivos ante situaciones de congestión. Si no es compatible, recurre a una conexión separada o a un programador de aplicaciones mientras preserva la confiabilidad de los mensajes de control".
Solución paso a paso
Comience con los límites de confiabilidad. Utilice flujos confiables para control, autorización y confirmación final; los datagramas pueden transportar vistas previas en vivo descartables; los flujos confiables pueden transportar archivos a baja prioridad. Un send group resuelve el orden de envío relativo entre miembros. No convierte diferentes grupos en colas ponderadas predecibles ni realiza reintentos a nivel de negocio.
Después de crear un grupo, asocie flujos de envío o un flujo de datagramas escribible con él y establezca sendOrder en los miembros. Documente la relación numérica en el protocolo para que las implementaciones no difieran sobre si gana un valor mayor o menor. Solo se comparan los miembros que participan en un ordenamiento estricto dentro del mismo grupo; un orden no establecido queda definido por la implementación.
const group = transport.createSendGroup();
const control = await transport.createUnidirectionalStream({
sendGroup: group,
sendOrder: 30,
});
const preview = transport.datagrams.createWritable({
sendGroup: group,
sendOrder: 20,
});
const archive = await transport.createUnidirectionalStream({
sendGroup: group,
sendOrder: 1,
});La aplicación todavía necesita presupuestos: limite el tamaño y la antigüedad de los datagramas de vista previa, y consolide el estado más reciente para cada objeto; los fragmentos de archivo necesitan cancelación, reintentos y registros de puntos de control. Cuando las colas se acerquen a sus límites, descarte primero las vistas previas obsoletas y pause los archivos, pero conserve los mensajes de control. Utilice confirmaciones y claves de idempotencia para mensajes críticos; un orden de envío alto no implica la entrega.
El control de congestión es una preferencia de transporte, no un SLA de negocio estricto. congestionControl puede expresar una preferencia de baja latencia o alto rendimiento, pero el resultado depende de la implementación y de las condiciones de la red. Elija la preferencia al crear la conexión, luego use métricas de aplicación para reducir la frecuencia de las vistas previas o pausar el trabajo en segundo plano; no afirme una garantía de latencia a partir de una sola opción.
Utilice getStats() del grupo y las métricas a nivel de miembro para observar el encolamiento, el envío, los descartes, los reintentos y la latencia de finalización. Registre dimensiones para el grupo, tipo de mensaje, red y versión de sesión, distinguiendo "aún no enviado", "datagrama perdido" y "receptor lento". Al reconectar, cree un nuevo grupo, restaure el estado del flujo confiable y reconstruya las vistas previas descartables a partir de una instantánea autoritativa en lugar de reutilizar objetos de flujo obsoletos.
Detecte la capacidad antes de abrir la sesión. Si los send groups no están disponibles, el flujo de control central aún debe funcionar; use una conexión confiable separada o una cola de aplicación. No bloquee el inicio de sesión, la autorización ni el envío para preservar una vista previa visual. Antes de lanzar una interfaz experimental, proporcione cohortes de navegadores, un interruptor de despliegue y una vía de desactivación inmediata (kill path).
Ejemplo de una respuesta sólida
Dividiría los mensajes de control, las vistas previas en vivo y la transferencia de archivos en miembros de envío separados, eligiendo flujos o datagramas según la confiabilidad. Los miembros que necesitan un orden relativo comparten un único send group: el control obtiene el sendOrder más alto, las vistas previas el siguiente y los archivos el más bajo; los miembros sin un orden quedan fuera de la comparación estricta. El orden del grupo es relativo, y la equidad entre grupos está definida por la implementación, por lo que no lo presentaría como una cuota de ancho de banda.
La aplicación es propietaria de los presupuestos, la cancelación, la idempotencia y la expiración: bajo congestión consolida o descarta vistas previas antiguas y pausa archivos, mientras que los mensajes de control conservan la confirmación confiable. congestionControl expresa una preferencia, y getStats() mide el encolamiento y la latencia de finalización. Las reconexiones reconstruyen el grupo y restauran a partir de una instantánea. Los navegadores no compatibles mantienen la ruta de control confiable y degradan o deshabilitan las vistas previas. Monitorearía los descartes, la latencia y el éxito de las tareas por grupo y tipo de mensaje.
Errores comunes
- Síntoma → Tratar
sendOrdercomo una ponderación de ancho de banda entre grupos; por qué falla → La API define el orden de envío relativo dentro de un grupo; solución → Programe entre grupos en la aplicación y mida el resultado. - Síntoma → Reemplazar la confirmación confiable con alta prioridad; por qué falla → El orden de envío no garantiza la entrega; solución → Utilice flujos confiables, confirmaciones e idempotencia para mensajes críticos.
- Síntoma → Seguir encolando cada vista previa y archivo durante la congestión; por qué falla → La latencia y la memoria se vuelven ilimitadas; solución → Establezca presupuestos, consolide el estado más reciente y pause la transferencia en segundo plano.
- Síntoma → Reutilizar objetos de flujo antiguos después de reconectar; por qué falla → Pertenecen a una sesión expirada; solución → Reconstruya el grupo, restaure el estado autoritativo y vuelva a suscribirse.
- Síntoma → Convertir una API experimental en el único canal; por qué falla → Las diferencias de navegador bloquean las acciones principales; solución → Detecte capacidades, despliegue gradualmente y preserve un respaldo confiable.
Preguntas de seguimiento y respuestas
¿Cuál es la diferencia entre la prioridad dentro del grupo y entre grupos?
Dentro de un send group, los flujos o datagramas participantes se comparan por sendOrder; se espera que los diferentes grupos reciban un trato equitativo, pero la división exacta está definida por la implementación. Para ponderaciones entre grupos, programe colas o conexiones separadas en la aplicación y valide con métricas.
¿Por qué un orden de envío alto no es suficiente para proteger las vistas previas?
La prioridad cambia el orden de la cola; no altera la falta de confiabilidad de los datagramas ni garantiza el procesamiento del receptor. Las vistas previas aún necesitan reglas de expiración, consolidación y descarte. Los datos de control necesitan transporte confiable, confirmación y durabilidad.
¿Cómo sabe si pausar archivos ayudó?
Rastree la longitud de la cola de archivos, la latencia de vista previa, la latencia de finalización de control y el éxito de las tareas. Continúe si la latencia de control mejora mientras las vistas previas cumplen su objetivo; reanude los archivos dentro de un presupuesto cuando cambie la red o la prioridad del negocio, evitando la inanición indefinida.
¿Cuál es el respaldo cuando no se admiten los send groups?
Preserve primero el flujo de control confiable y la navegación principal. Enrute las vistas previas a través de una ruta de datos separada, un flujo confiable o sin vista previa. Mantenga el mismo protocolo de mensajes y reglas de cancelación para que la autorización, el envío y la semántica de errores permanezcan intactos.