Reunión semanal del grupo técnico de HTTP3 (HTTP sobre QUIC) y Websocket-ACM

Del grupo backend del departamento técnico de neuq-acm (yh, wyx, wtl)

一.HTTP 3.0

1. Información general

Cuando el IETF estandarizó formalmente HTTP/2, Google estaba construyendo de forma independiente un nuevo transporte llamado gQUIC. Más tarde se convirtió en el New Internet-Draft y se denominó QUIC. Los experimentos iniciales con gQUIC demostraron que gQUIC funciona muy bien para mejorar la experiencia de navegación web en condiciones de red deficientes. Como resultado, gQUIC está cobrando impulso y la mayoría de los miembros del IETF están a favor de una nueva especificación para HTTP que se ejecuta en QUIC. Esta nueva iniciativa se llama HTTP/3 para diferenciarla del actual estándar HTTP/2.

Optimización de HTTP3.0

• existente en HTTP/2bloqueo de cabeza de líneapregunta. Dado que HTTP/2 utiliza la multiplexación en una sola conexión TCP, debido al control de congestión de TCP, una pequeña cantidad de pérdida de paquetes puede provocar que se bloqueen todos los flujos en toda la conexión TCP. (múltiples flujos de datos)

• Retención de la conexión al cambiar de redEl problema es el protocolo basado en TCP. Dado que la IP cambiará después de cambiar de red, no se podrá mantener la conexión anterior. El protocolo QUIC basado en UDP puede tener un método de identificación de conexión incorporado diferente al de TCP, de modo que la conexión anterior al servidor se pueda restaurar después de cambiar la red. (fiabilidad de la transmisión)

Método de conexión

首次连接
	首次连接时客户端和服务端的密钥协商和数据传输过程，其中涉及了DH算法的基本过程：
	1、客户端对于首次连接的服务端先发送client hello请求。
	2、服务端生成一个素数p和一个整数g，同时生成一个Ks_pri为私钥，	然后计算出公钥 = mod p，服务端将，p，g三个元素打包称config，后续发送给客户端。
	3、客户端随机生成一个自己的私钥，再从config中读取g和p，计算客户端公钥 = mod p。
	4、客户端使用自己的私钥和服务端发来的config中读取的服务端公钥，生成后续数据加密用的密钥K = mod p。
	5、客户端使用密钥K加密业务数据，并追加自己的公钥，都传递给服务端。
	6、服务端根据自己的私钥和客户端公钥生成客户端加密用的密钥K = mod p。
	7、为了保证数据安全，上述生成的密钥K只会生成使用1次，后续服务端会按照相同的规则生成一套全新的公钥和私钥，并使用这组公私钥生成新的密钥M。
	8、服务端将新公钥和新密钥M加密的数据发给客户端，客户端根据新的服务端公钥和自己原来的私钥计算出本次的密钥M，进行解密。
之后的客户端和服务端数据交互都使用密钥M来完成，密钥K只使用1次。

后续连接
	前面提到客户端和服务端首次连接时服务端传递了config包，里面包含了服务端公钥和两个随机数，客户端会将config存储下来，后续再连接时可以直接使用，从而跳过这个1RTT，实现0RTT的业务数据交互。
    客户端保存config是有时间期限的，在config失效之后仍然需要进行首次连接时的密钥交换。

2. Función

• Realiza las funciones de control de flujo y confiabilidad de transmisión similar a TCP

• Función de cifrado TLS (Seguridad de la capa de transporte) integrada

• Multiplexación implementada en HTTP/2.0, y su tiempo de carga de página es 2.5 tiempo RTT

  La diferencia es que QUIC se da cuenta de que puede haber múltiples flujos de datos lógicos independientes en la misma conexión física, realiza la transmisión separada de flujos de datos y resuelve el problema del bloqueo de cabeza de escuadrón TCP.

• Función de apretón de manos rápida implementada

  QUIC se basa en UDP, por lo que QUIC puede usar 0-RTT y 1-RTT para establecer conexiones.Específicamente: El ID de sesión de la conexión que completa la transacción QUIC se almacenará en caché en la memoria del navegador. Si el usuario abre la página nuevamente, no es necesario establecer una conexión TLS, y los parámetros de cifrado correspondientes al ID de sesión almacenado en caché son directamente utilizado. El servidor puede buscar el ID de sesión correspondiente en el caché de acuerdo con el ID de sesión. Cifrar los parámetros y completar el cifrado.

  

3. Características

QUIC abandonó TCP en favor de su hermano, UDP (Protocolo de datagramas de usuario). UDP es el "opuesto" de TCP; no es confiable (es posible que el otro extremo nunca reciba los datos enviados desde un extremo, y el otro extremo no tiene forma de saber que falta algo) y no está ordenado (se envía después de The los datos pueden exceder los datos enviados antes, llegando en un lío). Sin embargo, UDP es muy simple y, a menudo, se crean nuevos protocolos sobre UDP.

QUIC restaura la confiabilidad y el orden de TCP sin introducir la misma cantidad de viajes de ida y vuelta y latencia. Por ejemplo, si un cliente se vuelve a conectar al servidor, el cliente puede enviar datos cifrados importantes en el primer paquete, lo que permite que el servidor reanude la conexión anterior utilizando el mismo cifrado que se negoció previamente sin viajes de ida y vuelta adicionales.

2. WebSocket

1. Información general

• El protocolo WebSocket es un nuevo protocolo de red HTML5 basado en TCP, que realiza una comunicación full-duplex entre el navegador y el servidor, lo que permite que el servidor envíe información de forma activa al cliente.

• El protocolo de enlace debe completarse principalmente con la ayuda del código de estado 101 del protocolo HTTP/1.1.

• Mientras que WebSocket es un protocolo persistente, http es un protocolo no persistente

• El protocolo de comunicación WebSocket fue establecido como estándar RFC 6455 por el IETF (International Internet Engineering Task Force) en 2011

• WebSocket API es estándar por W3C

Ahora, muchos sitios web tienen requisitos de inserción en tiempo real, como chat, consulta de servicio al cliente, etc.

2. Antecedentes de desarrollo

• El protocolo HTTP es un protocolo sin estado, sin conexión,unidireccionalprotocolo de la capa de aplicación. Sigue un modelo de solicitud/respuesta. Una solicitud de comunicación solo puede ser iniciada por el cliente y el servidor responde a la solicitud.

• Si el servidor necesita enviar mensajes activamente al cliente, aparecerán los inconvenientes del protocolo HTTP.

• Cuando no había WebSocket en los primeros días, se implementó un sondeo largo a través de solicitudes ajax asincrónicas frecuentes. Debido a las solicitudes http, el servidor no podía enviar datos activamente al navegador, por lo que se requería el navegador.sincronizaciónEl servidor envía una solicitud al servidor (por ejemplo, una vez cada 1 s), y el servidor envía los datos más recientes al navegador en consecuencia. La desventaja de este modo es el desperdicio de rendimiento y recursos, y la eficiencia es muy baja. (porque es necesariosigue conectandoo conexión HTTPsiempre encendido)

• Propósito: en lugar de sondeo y conexión larga, el navegador del cliente tiene la capacidad de comunicación instantánea como el sistema de escritorio bajo el marco C/S

3. Comparación gráfica del protocolo HTTP y el protocolo WebSocket

análisis longitudinal

Protocolo HTTP: envía solicitudes al servidor periódicamente

Protocolo WebSocket: envía principalmente solicitudes al servidor

Análisis lateral

4. Especificación del protocolo WebSocket

WebSocket facilita el intercambio de datos entre el cliente y el servidor, lo que permite que el servidor envíe activamente datos al cliente. En la API de WebSocket, el navegador y el servidor solo necesitan completar un protocolo de enlace , y se puede crear una conexión persistente directamente entre los dos , y se puede realizar una transmisión de datos bidireccional .

solicitar información de cabecera

ws es la representación de WebSocket

GET ws://localhost/chat HTTP/1.1 
Host: server.example.com 
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 
Origin: http://example.com 
Sec-WebSocket-Protocol: chat, superchat 
Sec-WebSocket-Version: 13

encabezado de retorno

El código de estado 101 indica que el servidor cambia el protocolo en respuesta a la solicitud del cliente para actualizar el protocolo.

HTTP/1.1 101 
Switching Protocols 
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Accept:s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 
Sec-WebSocket-Protocol: chat

5. Ventajas de WebSocket

• Menos sobrecarga de control. Los encabezados de paquetes utilizados para el control de protocolos son relativamente pequeños cuando se intercambian datos entre el servidor y el cliente después de que se crea la conexión. Sin extensiones, este encabezado tiene un tamaño de solo 2 a 10 bytes (según la longitud del paquete) para contenido de servidor a cliente; para contenido de cliente a servidor, este encabezado requiere una máscara adicional de 4 bytes. Esta sobrecarga se reduce significativamente en comparación con la solicitud HTTP que lleva el encabezado completo cada vez.

• Mayor rendimiento en tiempo real. Dado que el protocolo es full-duplex, el servidor puede enviar activamente datos al cliente en cualquier momento. En comparación con las solicitudes HTTP, que deben esperar a que el cliente inicie una solicitud para que el servidor responda, la demora es significativamente menor; incluso en comparación con encuestas largas como Comet, puede entregar datos más veces en un período corto de tiempo.

• Mantente conectado. A diferencia de HTTP, Websocket necesita crear una conexión primero, lo que lo convierte en un protocolo con estado, y luego se puede omitir cierta información de estado al comunicarse. Y las solicitudes HTTP pueden necesitar llevar información de estado (como autenticación, etc.) en cada solicitud.

• Mejor soporte binario. Websocket define marcos binarios, lo que facilita el manejo de contenido binario que HTTP.

• Las extensiones pueden ser compatibles. Websocket define extensiones y los usuarios pueden ampliar el protocolo e implementar algunos subprotocolos personalizados. Por ejemplo, algunos navegadores admiten compresión, etc.

• mejor compresión. En comparación con la compresión HTTP, con el soporte de extensión adecuado, Websocket puede continuar usando el contexto del contenido anterior y puede mejorar significativamente la tasa de compresión al pasar datos similares.