Prompt y alcance
Una pizarra colaborativa transmite cursores, ediciones por lotes y fragmentos de archivos. Compara WebTransport con WebSocket y explica cómo las garantías de entrega, el ordenamiento, la congestión, el soporte del navegador y las operaciones guían la elección.
WebSocket ofrece un canal de mensajes bidireccional maduro. WebTransport utiliza HTTP/3 y expone flujos unidireccionales o bidireccionales confiables más datagramas con pérdida. La pregunta evalúa la capacidad de hacer coincidir la semántica de transporte con las restricciones del sistema, no repetir que HTTP/3 es más rápido.
Qué evalúa el entrevistador
Busca una división entre los datos que deben llegar y los datos que pueden expirar; comprensión del ordenamiento, contrapresión (backpressure), congestión y cierre; y una evaluación honesta de los servidores HTTP/3, certificados, proxies, soporte del navegador, mecanismos de reserva (fallback) y observabilidad.
Estructura de respuesta de 30 segundos
“Primero clasificaría los datos: las ediciones y los fragmentos de archivo utilizan flujos bidireccionales confiables con contrapresión; las posiciones del cursor pueden usar datagramas porque las posiciones obsoletas no tienen valor. Si los navegadores, puertas de enlace o servidores de destino no admiten WebTransport de forma confiable, comenzaría con WebSocket y mantendría un fallback basado en la detección de capacidades. Ambas rutas necesitan autenticación, cuotas, latidos (heartbeats), reconexiones y métricas. Decidiría a partir de datos de pérdida de extremo a extremo, latencia, reconexión y costos operativos”.
Respuesta detallada paso a paso
Paso 1: Definir un contrato de entrega para cada mensaje
Las ediciones necesitan entrega confiable y ordenamiento, generalmente con un ID de operación para la deduplicación. Los fragmentos de archivo necesitan flujos confiables, sumas de verificación (checksums) y desplazamientos (offsets) reanudables. El estado del cursor y de la vista previa de arrastre puede conservar solo el valor más reciente y tolerar pérdidas o desorden.
Paso 2: Comprender el límite de WebSocket
WebSocket tiene un modelo de mensajes simple y maduro para un canal bidireccional confiable. La aplicación aún define los tipos de mensajes, la contrapresión, los heartbeats, las reconexiones, la difusión (broadcast) y el enmarcado de mensajes grandes. Un mensaje grande puede complicar la programación cuando todas las cargas útiles comparten un solo canal.
Paso 3: Comprender las capacidades de WebTransport
WebTransport combina flujos unidireccionales o bidireccionales confiables con datagramas no confiables. Los flujos transportan bytes ordenados; los datagramas admiten actualizaciones de baja latencia que pueden perderse. Las implementaciones deben respetar la disponibilidad del flujo, el cierre y los errores en lugar de asumir que los datagramas llegan.
Paso 4: Asignar expiración y deduplicación a los datagramas
Incluye un ID de entidad, secuencia o marca de tiempo en cada datagrama. El receptor descarta el estado obsoleto en lugar de tratar la pérdida como un fallo de negocio. Conserva solo el cursor más reciente por usuario; envía analíticas o confirmaciones de edición a través de un flujo confiable.
Paso 5: Manejar la contrapresión y la recuperación del flujo
Espera la disponibilidad para escritura y limita las colas por sesión. Pausa las actualizaciones de baja prioridad o aísla a un cliente abusivo cuando se supere el límite. Calcula el checksum de los fragmentos de archivo y persiste los offsets; después de la reconexión, continúa desde el último fragmento confirmado en lugar de reproducir todo el archivo.
Paso 6: Evaluar el despliegue y la compatibilidad
WebTransport requiere un servidor HTTP/3 compatible y una configuración de certificados, además de la validación de proxies, firewalls y balanceadores de carga. Prueba el soporte del navegador, los fallos de conexión, la degradación de HTTP/3 y las redes entre regiones antes del lanzamiento. Recurre a WebSocket o HTTP preservando la misma semántica de negocio.
Paso 7: Diseñar la autenticación y el aislamiento de recursos
Autentica la sesión y el origen durante el establecimiento de la conexión. Aplica límites por usuario y por inquilino en conexiones, flujos, tasa de datagramas y bytes. La prioridad de flujo declarada por el cliente no es una autorización; las escrituras de archivos aún requieren permisos, checksums y registros de auditoría.
Paso 8: Decidir con métricas de extremo a extremo
Registra los tiempos de envío y llegada, reconexiones, errores de flujo, pérdida estimada de datagramas, longitud de cola, CPU y ancho de banda por tipo de mensaje. Compara ambos transportes y el fallback bajo redes reales, transiciones móviles, proxies y concurrencia.
Compensaciones y límites
Un canal frente a múltiples semánticas
Un solo canal WebSocket confiable es más fácil de mantener. WebTransport puede separar los flujos confiables de los datagramas de baja latencia, pero aumenta la complejidad del protocolo, las pruebas y las operaciones. Asume ese costo solo cuando el producto necesite ambas semánticas.
Latencia frente a recuperabilidad
Los datagramas reducen la espera, pero requieren que el negocio acepte pérdidas y expiración. El estado crítico pertenece a flujos confiables con IDs de operación, puntos de control y protección contra repeticiones.
Beneficio del nuevo protocolo frente al riesgo de despliegue
La capacidad de HTTP/3 no elimina los fallos causados por navegadores o dispositivos de red no compatibles. Valida las tasas de conexión y fallback con un despliegue pequeño antes de expandir la cobertura.
Simulacros de fallos y evolución
HTTP/3 no está disponible en una red corporativa
Simula el bloqueo de proxy o el fallo del handshake. Confirma un fallback rápido a WebSocket, que no haya ediciones críticas duplicadas o perdidas y una métrica de fallo procesable.
Las actualizaciones del cursor se acumulan
Limita la tasa de datagramas y crea una red lenta. Verifica que los cursores obsoletos se descarten mientras que las operaciones de edición se mantengan confiables.
Se interrumpe un flujo de archivos
Reconecta después de la interrupción y verifica los checksums de fragmentos, la recuperación de offsets y la autorización renovada. Un cliente no debe sobrescribir offsets arbitrarios.
Errores comunes y preguntas de seguimiento
Error 1: Asumir que WebTransport siempre es más rápido
Pregunta por el éxito de la conexión, el tiempo de handshake y la tasa de fallback en la red de destino.
Error 2: Enviar ediciones críticas como datagramas
Pregunta cómo se manejan la pérdida, el reordenamiento y la duplicación; la respuesta debe mover las ediciones a flujos confiables con IDs de operación.
Error 3: Analizar únicamente las API del navegador
Pregunta cómo se despliegan los servidores HTTP/3, balanceadores de carga, certificados, proxies y la observabilidad.
Error 4: Omitir la contrapresión y las cuotas
Pregunta cómo se aísla a un cliente lento y cómo se aplican los límites de flujo y bytes por inquilino.
Error 5: Crear un segundo protocolo de negocio para el fallback
Pregunta cómo WebSocket y WebTransport preservan el mismo contrato de mensajes y la semántica de idempotencia.
Preguntas de seguimiento ampliadas y respuestas de referencia
¿Por qué separar el tráfico de cursores y de ediciones?
Los cursores son transitorios y se vuelven obsoletos rápidamente, por lo que la pérdida es aceptable a cambio de una menor latencia. Las ediciones deben ser confiables, ordenadas y recuperables, por lo que pertenecen a flujos confiables.
¿Qué pasa si WebTransport no está disponible?
Sondea la capacidad y luego recurre a WebSocket o HTTP mientras se preserva la autenticación, los IDs de mensajes, la reconexión y las confirmaciones de negocio.
¿Cómo demuestras que la elección funciona?
Compara la latencia, la pérdida estimada, las reconexiones, las colas, la CPU, el ancho de banda y el fallback en cohortes de red reales, y verifica que las operaciones críticas no se pierdan ni se dupliquen.