http2
Los marcos de encabezado (HEADERS) y datos (DATA) conforman la solicitud y respuesta HTTP básica
La configuración (AJUSTES), las actualizaciones de ventana (WINDOW_UPDATE) y las promesas automáticas (PUSH_PROMISE) se utilizan para implementar otras funciones de HTTP/2
1. Inicio de HTTP/2
2. Marcos (sección 4) y la capa de transmisión
3. Marcos (sección 6) y códigos de error (sección 7)
4. Direccionamiento HTTP (sección 8) y requisitos ampliados (sección 9) describen la semántica de HTTP Cómo es la cultura representada por marcos y flujos
3 Iniciar HTTP/2
3.1 Definición de la versión HTTP/2
El carácter "h2" indica que el protocolo HTTP/2 utiliza TLS [TLS]
El carácter "h2c" indica que el protocolo HTTP/2 se ejecuta en texto sin formato TCP
El uso de "h2" o "h2c" indica el uso de transporte, seguridad, tramas y mensajería semántica tal como se define en el documento.
El cliente no puede predecir si el servidor admite http2
GET /default.htm HTTP/1.1
Host: server.example.com
Conexión: Actualización, HTTP2-Configuración
Actualización: h2c
HTTP2-Configuración: <codificación base64url de carga útil de CONFIGURACIÓN HTTP/2>
不支持
HTTP/1.1 200 OK
Longitud del contenido: 243
Tipo de contenido: texto/html
…
支持
HTTP/1.1 101 Protocolos de conmutación
Conexión: Actualizar
Actualizar: h2c
[Conexión HTTP/2...
Después del soporte, la primera trama HTTP/2 enviada por el cliente es el preámbulo de conexión.La
primera trama HTTP/2 enviada por el servidor es una trama de CONFIGURACIÓN. Después de recibir una respuesta 101, el cliente envía un preámbulo de conexión que contiene un marco de AJUSTES.
Prólogo de conexión: PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n
Si alguno de los extremos no comienza con un preámbulo de conexión válido, el cliente y el servidor DEBEN terminar la conexión TCP. El marco GOAWAY (sección 6.8) PUEDE omitirse si el punto final no está utilizando HTTP/2.
4 tramas HTTP HTTP帧
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±±±±±±±±± ±±±±±±±±±±±±±±±±±±+
| R | Longitud (14) | Tipo (8) | Banderas (8) |
±±±----------±--------------±--------------------- ---------+
|R| Identificador de corriente (31) |
+=+============================================== ==============+
| Carga útil de trama (0…) …
±------------------------------------------- --------------------+
R : Campo reservado de 2 bits. La semántica de estos bytes no está definida y DEBE dejarse sin establecer (0) cuando se envía, y este campo DEBE ignorarse cuando se recibe.
Longitud: la longitud del cuerpo de la trama en un entero sin signo de 14 bits. La información del encabezado de la trama de 8 bytes no se cuenta.
Tipo: El tipo de 8 bits del marco. El tipo de marco define cómo se interpretará el resto del encabezado y el cuerpo del marco. Las implementaciones concretas DEBEN manejar la recepción de un tipo de marco desconocido (cualquier marco no definido en la documentación) como un error de conexión de tipo PROTOCOL_ERROR.
Indicadores: el campo de 8 bytes reservado para el tipo de trama tiene un indicador booleano específico.
Los identificadores asignan una semántica específica a ciertos tipos de marcos. Las banderas que no sean las que definen la semántica de la definición del tipo de trama DEBEN ignorarse y DEBEN dejarse sin establecer (0) cuando se envían.
R : Campo reservado de 1 bit. La semántica de este campo no está configurada y DEBE permanecer sin configurar (0) al enviar, y DEBE ignorarse al recibir.
Identificador de flujo: identificador de flujo de 31 bytes (ver StreamIdentifiers). 0 está reservado e indica que la trama está asociada con la conexión como un todo en lugar de un solo flujo.
4.2 Tamaño del marco
El límite de longitud máxima del cuerpo del marco es diferente para diferentes tipos de marco. La longitud absoluta del cuerpo máximo de la trama es (16 383) bytes, lo que indica que la longitud máxima de la trama es 16 391 bytes. Todas las implementaciones DEBEN ser capaces de recibir y procesar tramas de esta longitud máxima.
4.3 Compresión y descompresión de encabezados Compresión y descompresión de encabezados
Un campo de encabezado de mensaje HTTP/2 contiene uno o más pares clave-valor asociados. Se utilizan en mensajes de respuesta de solicitud HTTP y operaciones de inserción del servidor (consulte la Sección 8.2).
Un conjunto de encabezados es una colección de 0 o más campos de encabezado. Cuando se transmite a través de la conexión, el conjunto de encabezados se serializará en el bloque de encabezado del mensaje mediante la compresión de encabezado HTTP. Los bloques de encabezado serializados se dividen en una o más secuencias de bytes, denominadas particiones de encabezado, y se entregan en el portador de marcos de encabezado, promesa de inserción y continuación.
La compresión del encabezado HTTP no conserva el orden relativo de los campos del encabezado. Los campos de encabezado con múltiples valores se codifican en un solo campo de encabezado utilizando un divisor específico (consulte la Sección 8.1.2.3 Ordenación de encabezados), que conserva el orden correspondiente de los diversos valores en ese campo de encabezado.
El campo de encabezado de la cookie es manejado especialmente por el mapeo HTTP; vea la Sección 8.1.2.4.
El punto final de recepción conecta el reensamblaje del bloque de encabezado y reconstruye el conjunto de encabezado después de descomprimir el bloque.
Un bloque de encabezado completo contiene:
Un bloque de encabezado completo contiene:
Una sola trama HEADERS o PUSH_PROMISE que contiene el conjunto de marcadores de terminación de encabezado, o
una trama PUSH_PROMISE de HEADERS o promesa push con los marcadores de terminación de encabezado borrados y una o más tramas de CONTINUACIÓN de continuación, la última trama de CONTINUACIÓN de continuación tiene el marcador de terminación de encabezado configurado.
La compresión de encabezado tiene estado y utiliza el mismo entorno de compresión en toda la conexión. Cada bloque de encabezado se trata como una unidad discreta. Los bloques de encabezado DEBEN transmitirse como una secuencia continua de tramas, sin tramas intercaladas de ningún tipo ni ningún otro flujo. El último cuadro de una secuencia de ENCABEZADOS o cuadros de CONTINUACIÓN de continuación DEBE tener el indicador Fin de encabezados establecido. Una promesa push PUSH_PROMISE o la última trama de una secuencia de tramas de continuación CONTINUACIÓN DEBEN tener el indicador Terminate de encabezado establecido.
El bloque de encabezado DEBE enviarse con encabezados HEADERS, PUSH_PROMISE o carga útil de CONTINUACIÓN, porque estos marcos transportan datos de contexto de compresión que el receptor puede modificar. Un punto final DEBE volver a ensamblar los bloques de encabezado y realizar la descompresión al recibir marcos de ENCABEZADOS, PUSH_PROMISE o CONTINUACIÓN de continuación, incluso si esos marcos se descartarían. Si la sección de encabezado no se puede reconstruir, el receptor DEBE terminar la conexión con un error de conexión del tipo Error de descompresión (Sección 5.4.1).
5 Flujos y multiplexación Flujos y multiplexación
Una sola conexión HTTP/2 puede contener múltiples flujos abiertos simultáneamente, desde los cuales se intercambian marcos entre los distintos puntos finales.
Los flujos pueden ser creados, utilizados o compartidos unilateralmente por clientes o servidores.
Los flujos pueden ser cerrados por cualquier punto final de conexión.
El orden en que se envían las tramas dentro de un flujo es importante. Se procesarán en el orden en que se reciban. En particular, la secuencia de encabezados y marcos de datos tiene sentido semánticamente.
Los flujos se identifican con un número entero. El identificador lo asigna el terminal que inició el flujo.
+--------+
PP | | PP
,--------| idle |--------.
/ | | \
v +--------+ v
+----------+ | +----------+
| | | H | |
,—| reservado | | | reservado |—.
| | (local) | v | (remoto) | |
| ±---------+ ±-------+ ±---------+ |
| | ES | | ES | |
| | H ,-------| abierto |-------. | H |
| | / | | \ | |
| vv ±-------+ vv |
| ±---------+ | ±---------+ |
| | la mitad | | | la mitad | |
| | cerrado | | R | cerrado | |
| | (remoto) | | | (local) | |
| ±---------+ | ±---------+ |
| | v | |
| | ES/R ±-------+ ES/R | |
| ----------->| |<-----------' | | R | closed | R | -------------------->| |<------------'
±-------+
H: marco HEADERS (con CONTINUACIONES implícitas)
PP: marco PUSH_PROMISE (con CONTINUACIONES implícitas)
ES: indicador END_STREAM
R: marco RST_STREAM
Estado de transmisión:
Todos los flujos comienzan en un estado "inactivo". En este estado, no hay intercambio de marcos.
Las siguientes transferencias son válidas en este estado:
Enviar o recibir una trama de ENCABEZADOS hace que el flujo se "abra". Los identificadores de flujo se describen en StreamIdentifiers. Este marco de ENCABEZADOS también puede hacer que el flujo se "cierre a medias" inmediatamente.
Envíe un marco PUSH_PROMISE para marcar la secuencia relacionada para su uso posterior. El estado de flujo reservado pasará a "Reservado (local)".
Recibir un marco PUSH_PROMISE marca el flujo asociado como un flujo reservado para el extremo remoto. El estado de estos flujos pasa a ser "Reservado (Remoto)"
reservado (local) :
En el estado "reservado (local)" hay flujos que se han comprometido a enviar marcos PUSH_PROMISE. Una trama PUSH_PROMISE reserva un flujo inactivo al asociar un flujo con un flujo abierto iniciado por el par remoto.
En este estado, solo son posibles las siguientes transferencias:
Un punto final puede enviar una trama HEADERS, lo que hace que el flujo se abra a un estado "medio cerrado (remoto)".
Cualquier punto final puede enviar un marco RST_STREAM para hacer que la transmisión se "cierre". Esto liberará la retención de la transmisión.
En este estado, un par NO DEBE enviar tramas que no sean tramas HEADERS y RST_STREAM
Una trama de PRIORIDAD se puede recibir en este estado. La recepción de cualquier trama que no sea una trama HEADERS, una trama RST_STREAM o una trama PRIORITY de prioridad se considerará un error de conexión (Sección 5.4.1) del tipo PROTOCOL_ERROR.
reservado (remoto):
Las descripciones de flujo en el estado "reservado (remoto)" han sido reservadas por el par remoto.
En este estado, solo son posibles las siguientes transferencias:
Recibir una trama de ENCABEZADOS hace que la secuencia pase al estado "semicerrado (local)".
Cualquiera de los extremos puede enviar una trama RST_STREAM para que la transmisión se "cierre". Esto liberará la retención de la transmisión.
abierto :
Ambos pares pueden usar un flujo en el estado "abierto" para enviar tramas de cualquier tipo. En este estado, la inspección por pares de los datos enviados está limitada por el control de flujo FlowControl de la emisora (Sección 5.2).
En este estado, cada terminal puede enviar una trama con el marcador de flujo final END_STREAM para hacer que el flujo pase a uno de los estados "medio cerrado": un punto final envía un marcador de flujo final END_STREAM para convertir el flujo en el estado "medio cerrado". estado cerrado" ;Un terminal recibe un flujo final END_STREAM marcador para que el flujo pase a un estado "semicerrado (remoto)". Una trama de ENCABEZADOS marcada con un flujo final END_STREAM puede ir seguida de una trama de CONTINUACIÓN.
Cada terminal en este estado puede enviar una trama RST_STREAM para hacer la transición del flujo al estado "cerrado".
medio cerrado (local) :
Los flujos en estado "semicerrado (local)" no pueden enviar tramas. Solo se pueden enviar tramas de actualización de ventana (WINDOW_UPDATE), prioridad (PRIORITY) y terminación de flujo (RST_STREAM) en este estado.
medio cerrado (remoto) :
el par ya no utiliza un flujo en el estado "medio cerrado (remoto)" para enviar tramas. En este estado, el terminal que realiza el control de flujo ya no realiza el trabajo de recibir la ventana de control en blanco.
Si un punto final recibe tramas adicionales de un flujo en este estado, a menos que sea una trama de CONTINUACIÓN de continuación, DEBE devolver un error de flujo del tipo FLUJO_CERRADO (Sección 5.4.2).
En este estado, cuando la transmisión envía un marco con el indicador END_STREAM o un punto final envía un marco RST_STREAM, la transmisión pasará al estado "cerrado".
cerrado:
El estado "cerrado" es un estado terminal.
Un punto final NO DEBE enviar tramas a través de un flujo cerrado. Cualquier trama recibida por un punto final después de recibir un RST_STREAM DEBE tratarse como un error de flujo StreamErrorHandler (Sección 5.4.2) de tipo STREAM_CLOSED. De manera similar, cualquier trama recibida por un punto final después de una trama de DATOS con el indicador END_STREAM establecido, o después de una trama de ENCABEZADOS con el indicador END_STREAM establecido y no seguida por un marco de CONTINUACIÓN de continuación DEBE cerrarse como un flujo. Error de conexión (Sección 5.4.1). ) manejo para STREAM_CLOSED.
5.1.1 Identificadores de flujo identificador de flujo
Los flujos se identifican mediante números enteros sin signo de bytes de 31 bits. Los flujos iniciados por el cliente deben estar marcados con un número impar, los flujos iniciados por el servidor deben estar marcados con un número par,
un identificador de flujo recién establecido debe tener un valor mayor que cualquier terminal que haya abierto o reservado identificadores de flujo. Las reglas se aplican a los flujos abiertos con marcos de encabezado y a los flujos reservados con marcos de promesa de inserción. Un punto final que recibe un identificador de flujo no canónico DEBE responder con un error de conexión de tipo PROTOCOL_ERROR.
Los identificadores de flujo no se pueden reutilizar. Las conexiones de larga duración pueden hacer que se agote el rango disponible de identificadores de flujo. Un cliente puede establecer una nueva conexión para un nuevo flujo cuando no puede crear un nuevo identificador de flujo. Cuando el servidor no puede crear un nuevo identificador de transmisión, puede enviar un marco de tiempo de espera (GOAWAY) para obligar al cliente a usar una nueva conexión para la nueva transmisión.
5.1.2 Simultaneidad de flujo
El par puede usar el parámetro SETTINGS_MAX_CONCURRENT_STREAMS en el marco de configuración para limitar la concurrencia de flujos.
El cliente puede especificar la concurrencia máxima de secuencias que el servidor puede iniciar y el servidor puede especificar la concurrencia máxima de secuencias que el cliente puede iniciar. Los puntos finales nunca deben exceder el límite establecido por el par.
Los flujos en estado "abierto" o cualquiera de los estados "semicerrados" se cuentan en el número de flujos que el terminal puede iniciar. Las transmisiones en cualquiera de estos tres estados contarán para la configuración SETTINGS_MAX_CONCURRENT_STREAMS. Las transmisiones en cualquiera de los estados "reservados" no cuentan para las aperturas.
Los puntos finales nunca deben exceder la configuración establecida por los pares. Los extremos que reciben tramas de encabezado que provocan que los flujos simultáneos que difunden excedan el límite DEBEN tratar esto como un error de flujo (Sección 5.4.2). Un punto final que desee reducir el valor de SETTINGS_MAX_CONCURRENT_STREAMS a un valor más pequeño que los flujos actualmente abiertos puede cerrar los flujos que excedan el nuevo valor de configuración o permitir que los flujos finalicen.
5.2 Control de flujo Control de flujo
El uso de flujos multiplexados describe el bloqueo de flujo causado por la contención de recursos para las conexiones TCP. Los esquemas de control de flujo, etc. aseguran que los flujos en la misma conexión no interfieran destructivamente entre sí. El control de flujo se utiliza tanto para flujos individuales como para toda la conexión.
HTTP/2 proporciona control de flujo mediante el uso del tipo de trama WINDOW_UPDATE (Sección 6.9).
5.2.1 Principios de control de flujo Reglas de control de flujo
El control de flujo se define para proteger la operación de los puntos finales bajo restricciones de recursos. Por ejemplo, un proxy necesita compartir memoria a través de muchas conexiones, posiblemente con conexiones ascendentes lentas y conexiones descendentes rápidas.
El control de flujo resuelve la situación en la que el extremo receptor está procesando datos en un flujo y al mismo tiempo desea continuar procesando otros flujos en la misma conexión.
5.4 Manejo de errores Manejo de errores
El marco HTTP/2 permite dos tipos de errores:
Un error que inutiliza toda la conexión.
Errores que ocurren dentro de una sola transmisión.
Puede encontrar una lista de códigos de error en "ErrorCodes".
5.4.1 Manejo de errores de conexión Un
error de flujo es un error que impide que la capa de trama procese más o corrompe cualquier estado del flujo.
Un punto final que envía un error de transmisión DEBERÍA enviar primero una trama GOAWAY (Sección 6.8) con el identificador de la transmisión más reciente que recibió con éxito una trama del par. El marco de tiempo de espera GOAWAY contiene el código de error del terminal de enlace. Después de enviar GOAWAY, el punto final DEBE cerrar la conexión TCP.
Es posible que el extremo receptor no reciba efectivamente la trama de tiempo de espera (GOAWAY). En el caso de un error de conexión, una trama GOAWAY es un intento de mejores prácticas para comunicar al par por qué se terminó la conexión.
5.4.2 Manejo de errores de flujo Manejo de errores de flujo
Un punto final que detecta un error de flujo envía una trama RST_STREAM (RST_STREAM, Sección 6.4) con el identificador de flujo en el momento en que ocurrió el error. Las tramas RST_STREAM llevan un código de error que indica el tipo de error.
RST_STREAM es el último marco que un punto final puede enviar una transmisión. Un par que envía una trama RST_STREAM DEBE estar listo para recibir cualquier trama enviada o preparada para ser enviada por un par remoto. Estas tramas PUEDEN ignorarse a menos que se modifique el estado de la conexión (como en la compresión de encabezado (Sección 4.3)).
5.4.3 Terminación de la conexión
Si una conexión TCP se desconecta mientras los flujos aún están abiertos o medio cerrados, el punto final DEBE asumir que estos flujos están anormalmente terminados e incompletos.
6 Definiciones de cuadros definición de cuadros
6.1 DATOS trama de datos
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±±±±±±±±± ±±±±±±±±±±±±±±±±±±+
| [Almohadilla alta(8)] | [Almohadilla baja (8)] | datos ( ) .
±--------------±--------------±------------------- -----------+
. Datos ( ) …
±--------------------------------------------- -----------------+
| Relleno (*) …
±-------------------------------------------- ------------------+
Longitud del relleno: un campo de 8 bits que contiene la longitud del relleno del marco en bytes. Este campo es opcional y solo está presente si se establece el indicador PADDED.
Relleno: los bytes de relleno no contienen ningún valor semántico de la aplicación. Los bytes de relleno deben establecerse en 0 al enviar e ignorarse al recibir.
Datos: datos de la aplicación. El tamaño del volumen de datos es la carga útil del marco menos la longitud de otros campos de presentación.
END_STREAM (0x1): El bit 1 se utiliza para indicar que la trama actual es la última trama enviada por el flujo determinado. Cuando se establece esta bandera, la corriente entra en un estado semicerrado o cerrado (Sección 5.1).
END_SEGMENT (0x2): El bit 2 indica que es el último cuadro del final actual. El proxy NO DEBE fusionar tramas a través de múltiples límites de pares, y el proxy DEBE mantener los límites de los segmentos al reenviar tramas.
PADDED (0x8): el bit 4 se usa para indicar que el campo de longitud del pad está visible.
Un marco de datos absolutamente necesita estar asociado con una secuencia. Si se recibe una trama de datos con un campo Marcador de flujo de 0x0, DEBE responderse un Error de conexión del tipo Error de protocolo (Sección 5.4.1).
Las tramas de datos están sujetas al control de flujo y solo se pueden enviar si el flujo está abierto o medio cerrado (remoto). El relleno también se incluye en el control de flujo.
Si se recibe una trama de datos mientras el flujo asociado no está en el estado abierto y semicerrado (nativo), el receptor DEBE responder con un error de flujo (Sección 5.4.2) del tipo flujo cerrado.
El número total de bytes de relleno depende del valor de Pad Length. Si el tamaño del relleno es mayor que el tamaño de la carga útil de la trama, el receptor DEBE tratarlo como un error de conexión (Sección 5.4.1) del tipo Error de protocolo.
6.2 Cabecera encabezado
Un marco de encabezado (tipo = 0x1) consta de pares clave-valor. Se utiliza para abrir una corriente (Sección 5.1). Los marcos de encabezado se pueden enviar con el flujo abierto o medio cerrado (remoto).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±±±±±±±±± ±±±±±±±±±±±±±±±±±±±+
|¿Longitud de la almohadilla? (8)|
±±-------------±------------------------------------ -----------+
|E| ¿Dependencia de flujo? (31) |
±±-------------±------------------------------------ -----------+
| ¿Peso? (8) |
±±-------------±------------------------------------ -----------+
| Fragmento de bloque de encabezado ( ) …
±------------------------------------------- -------------------+
| Relleno ( ) …
±--------------------------------------------- -----------------+
Longitud del relleno: la unidad contenedora de 8 bits es el campo de longitud del relleno del marco de bytes. Este campo es opcional y está presente solo si se establece el indicador PADDED
E: Un indicador de 1 bit que se utiliza para identificar si una dependencia de flujo es privada, consulte la Sección 5.3. Este campo es opcional y solo está presente si se establece el indicador de prioridad.
Dependencia de flujo: el campo del identificador del flujo del que depende el flujo de 31 bits, consulte la Sección 5.3. Este campo es opcional y solo está presente si se establece el indicador de prioridad.
Peso: el indicador de peso de 8 bits del flujo, consulte la sección 5.3. Agregue un valor de 1 a 256 para almacenar el peso de la transmisión. Este campo es opcional y solo está presente si se establece el indicador de prioridad.
Fragmento de bloque de encabezado: Fragmento de bloque de encabezado.
Relleno: bytes de relleno
6.3 PRIORIDAD marco de prioridad
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±±±±±±±±± ±±±±±±±±±±±±±±±±±±+
|E| Dependencia de flujo (31) |
±±-------------±------------------------------------ -----------+
| Peso (8) |
±±------------+
E: Un indicador de un bit que indica que la dependencia del flujo es exclusiva, consulte la Sección 5.3
Dependencia del flujo: Un identificador de flujo de 31 bits que identifica el flujo del que depende el flujo, consulte la Sección 5.3
Peso: El peso de la dependencia del flujo (8 bits), consulte la Sección 5.3. Agregue un valor de peso de 1-256.
6.4 RST_STREAM RST_STREAM帧
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±±±±±±±±± ±±±±±±±±±±±±±±±±±±+
| Código de error (32) |
±-------------------------------------------------------- -------------+
Las tramas RST_STREAM (tipo = 0x3) permiten la terminación anormal de flujos. Cuando lo envía el puntero de una transmisión, indica que se espera la cancelación de la transmisión o que se ha producido una condición de error. Cuando se envía por un flujo en el extremo receptor, indica que el receptor desea rechazar el flujo, que se canceló el flujo o que ocurrió un error.
6.5 Marco de configuración AJUSTES
El marco de configuración (tipo = 0x4) contiene parámetros de configuración que afectan la forma de comunicarse con el terminal (como las preferencias y las restricciones de comportamiento de los compañeros), y se utiliza para confirmar la recepción de estos parámetros. Los parámetros de configuración individuales también pueden considerarse "configuraciones".
Los marcos de configuración siempre se aplican a las conexiones, no a un solo flujo. El identificador de marco de configuración de flujo DEBE ser 0. Si un punto final recibe un marco de configuración con un identificador de marco de configuración de flujo distinto de 0, DEBE responder con un error de conexión del tipo Error de protocolo (Sección 5.4.1).
6.5.1 SettingFormat Establecer formato de cuadro
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±± ±±±±±±±±±±±±±±±±±±±±±±±±+
|Identificador (8) |Valor (32) …
±------------ -- ±----------------------------------------------+
…Valor |
±--------------+
Se definen los siguientes parámetros:
SETTINGS_HEADER_TABLE_SIZE (1): Permite al remitente notificar al terminal remoto la capacidad máxima de la tabla de compresión de encabezados para decodificar bloques de encabezados. Este codificador puede usar opcionalmente ciertas señales en el bloque de encabezado para reducir el tamaño de la compresión del encabezado (???). El valor inicial es de 4.096 bytes.
SETTINGS_ENABLE_PUSH (2): este parámetro se puede usar para desactivar la inserción del servidor. Cuando el terminal recibe este parámetro como 0, no debe enviar el marco de promesa de inserción del servidor. Cuando el terminal ha establecido este parámetro en 0 y lo reconoce, debe manejar el servidor push recibido como un error de conexión de tipo Error de protocolo.
El valor inicial es 1, lo que significa que se permite empujar. Cualquier valor que no sea 0 o 1 DEBE tratarse como un error de conexión de tipo ProtocolError.
SETTINGS_MAX_CONCURRENT_STREAMS (3): indica el máximo de flujos simultáneos permitidos por el remitente. Este límite es direccional: se aplica al número máximo de flujos simultáneos que el remitente permite que el receptor cree. No hay límite para este valor cuando se inicializa. Se recomienda que el valor no sea superior a 100 para evitar restricciones innecesarias en el paralelismo.
Un valor de este conjunto a 0 no debe ser considerado especial por el terminal. Un valor de 0 impide la creación de nuevos flujos, de lo contrario, se aplica a cualquier límite agotado por los flujos activados. Para conexiones cortas, este parámetro no debe establecerse en 0; si el servidor no desea recibir ninguna solicitud, la mejor manera es cerrar la conexión.
SETTINGS_INITIAL_WINDOW_SIZE (4): Indica el tamaño de la ventana inicial (en bytes) del control de flujo de la troposfera del remitente. El valor inicial es 65.535.
Este parámetro afecta el tamaño de la ventana para todos los flujos, incluidos los flujos existentes. Consulte la Sección 6.9.2
Los valores del tamaño de la ventana de control de flujo superiores a 2 elevado a 31 -1 DEBEN tratarse como errores de conexión para errores de control de flujo.
6.6 PUSH_PROMISE marco de promesa de inserción
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±±±±±±±±± ±±±±±±±±±±±±±±±±±±+
| [Almohadilla alta(8)] | [Almohadilla baja (8)] |X| Id. de transmisión prometida (31) …
±--------------±--------------±±---------- -----------------+
… ID de transmisión prometida | Fragmento de bloque de encabezado ( ) …
±------------------------------±------------------ ------------------+
| Fragmento de bloque de encabezado ( ) …
±------------------------------------------- -------------------+
| Relleno (*) …
±-------------------------------------------- ------------------+
El Portador de marco de encabezado contiene los siguientes campos:
Pad High: tamaño de pad alto. Este campo solo está presente si se establece el indicador PAD_HIGH.
Pad Low: tamaño de pad bajo. Este campo solo está presente si se establece el indicador PAD_LOW.
X : Bits reservados individuales.
ID de transmisión prometida: este entero de 31 bits sin signo representa el identificador de transmisión que el extremo está listo para enviar. El token de flujo prometido debe ser una opción válida para el siguiente flujo que el remitente pretende enviar.
Fragmento de bloque de encabezado: un fragmento de bloque de encabezado (Sección 5.1.1) que contiene los campos de encabezado de la solicitud.
Relleno: bytes de relleno.
6.7 PING PING帧
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±±±±± ±±±±±±±±±±±±±±±±±±±±±±+
| |
| Datos opacos (64) |
| |
±-------------------------------------------------------- -------------+
6.8 Marco de tiempo de espera GOAWAY
El marco de tiempo de espera (tipo = 0x7) informa al par remoto que no establezca nuevos flujos en esta conexión. Los marcos de tiempo de espera pueden ser enviados por el cliente o el servidor. Una vez enviado, el iniciador ignorará el envío de nuevas tramas con identificadores mayores que los del flujo anterior en la conexión actual. Después de recibir el marco de tiempo de espera, el extremo receptor no debe abrir una nueva transmisión en esta conexión, pero puede crear una nueva conexión para la nueva transmisión.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±±±±±±±±± ±±±±±±±±±±±±±±±±±±+
|X| ID de última transmisión (31) |
±±------------------------------------------------ ------------+
| Código de error (32) |
±-------------------------------------------------------- -------------+
| Datos de depuración adicionales (*) |
±-------------------------------------------------------- -------------+
6.9 Marco de actualización de ventana WINDOW_UPDATE
El marco WINDOW_UPDATE (tipo=0x8) se utiliza para implementar el control de flujo; consulte el Capítulo 5.2 para obtener una descripción general.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±±±±±±±±± ±±±±±±±±±±±±±±±±±±+
|X| Incremento de tamaño de ventana (31) |
±±------------------------------------------------ ------------+
7 Códigos de error
NO_ERROR (0): La condición relevante no es el resultado de un error. Por ejemplo, un marco de tiempo de espera puede llevar este código de error para indicar un apagado correcto de la conexión.
PROTOCOL_ERROR (1): el extremo detectó un error de protocolo no especificado. Este error se utiliza cuando no hay disponible un código de error más específico.
INTERNAL_ERROR (2): el terminal encontró un error interno inesperado.
FLOW_CONTROL_ERROR (3): el extremo detectó una violación del protocolo de control de flujo por parte del par.
SETTINGS_TIMEOUT (4): El punto final envió un marco de CONFIGURACIÓN, pero no recibió una respuesta a tiempo. Consulte Sincronización de configuraciones.
STREAM_CLOSED (5): el punto final recibió el marco mientras la transmisión estaba medio cerrada.
FRAME_SIZE_ERROR (6): el extremo recibió una trama cuyo tamaño supera el tamaño máximo.
REFUSED_STREAM (7): el punto final rechaza el flujo antes de realizar cualquier procesamiento de la aplicación, consulte Confiabilidad (Sección 8.1.4) para obtener más detalles.
CANCEL (8): el punto final usa esto para indicar que ya no se necesita un flujo.
COMPRESSION_ERROR (9): El terminal no puede mantener la conexión del contexto de compresión de cabecera
CONNECT_ERROR (10): La conexión establecida en respuesta a una solicitud de conexión se considera anormalmente cerrada.
ENHANCE_YOUR_CALM (11): el punto final detecta que el compañero exhibe un comportamiento que puede generar una carga excesiva.
INADECUADA_SEGURIDAD (12): El transporte subyacente contiene atributos que no cumplen con los requisitos mínimos declarados por el documento o terminal.
8.1 Intercambio de solicitud/respuesta HTTP Intercambio de solicitud/respuesta HTTP
El cliente inicia una solicitud HTTP en un flujo nuevo, utilizando un identificador de flujo no utilizado previamente. El servidor inicia una solicitud HTTP en el mismo flujo.
8.1.3 Ejemplos
GET /resource HTTP/1.1 HEADERS
Host: ejemplo.org ==> + END_STREAM
Aceptar: image/jpeg + END_HEADERS
:method = GET
:scheme = https
:path = /resource
host = example.org
accept = image/jpeg
HTTP/1.1 304 No modificado HEADERS
ETag: “xyzzy” ==> + END_STREAM
Vence: jueves 23 de enero… + END_HEADERS
:status = 304
etag: “xyzzy”
vence: jueves 23 de enero…
POST /resource HTTP/1.1 HEADERS
Host: ejemplo.org ==> - END_STREAM
Tipo de contenido: image/jpeg + END_HEADERS
Longitud del contenido: 123 :method = POST
:scheme = https
{binary data} :path = /resource
:authority = ejemplo.org
tipo de contenido = imagen/
longitud de contenido jpeg = 123
DATA
+ END_STREAM
{binary data}
Una respuesta con campos de encabezado y datos de carga útil se convertirá en un marco de encabezado, seguido de cero o más marcos de continuación, seguidos de uno o más marcos de datos, el último marco de datos en la secuencia tiene el indicador END_STREAM.
HTTP/1.1 200 OK ENCABEZADOS
Tipo de contenido: imagen/jpeg ==> - END_STREAM
Longitud de contenido: 123 + END_HEADERS
: estado = 200
{datos binarios} tipo de contenido = imagen/jpeg
longitud de contenido = 123
DATA
+ END_STREAM
{binary data}
Después de enviar todos los bloques de encabezado de solicitud o respuesta y todos los marcos de datos, los campos de encabezado de tráiler se envían como un bloque de encabezado. Una secuencia de marco de encabezado/continuación con un tráiler contiene un marco de terminación marcado con END_HEADERS y END_STREAM.
HTTP/1.1 200 OK HEADERS
Tipo de contenido: image/jpeg ==> - END_STREAM
Codificación de transferencia: fragmentado + END_HEADERS
Trailer: Foo :status = 200
content-length = 123
123 content-type = image/jpeg
{binary data} trailer = Foo
0
Foo: bar DATOS
-
END_STREAM
{datos binarios}HEADERS + END_STREAM + END_HEADERS foo: bar