Una descripción general del protocolo http y conocimientos sobre él.

0.0742017.08.29 00:22:51 Recuento de palabras 11.800 Lecturas 913

El protocolo http tiene tres versiones: http0.9, http1.0, http1.1 y http2. Sin embargo, los navegadores ahora utilizan el estándar http1.1. Este artículo se centra en la versión http1.1 y también la intercala con http2. Algunas novedades características.

Una introducción

Sin más preámbulos, HTTP es el Protocolo de transferencia de hipertexto. Es un protocolo de capa de aplicación basado en TCP/IP. Se utiliza principalmente para transmitir hipertexto desde el servidor web al navegador local. Consiste en solicitud y La composición de respuesta es un estándar modelo cliente-servidor.

Aquí hay una breve introducción a la diferencia entre http y https: el protocolo https se lleva a cabo en SSL+TLS y se basa en http y ssl. Su mayor diferencia con http es su seguridad y utiliza diferentes conexiones. Los métodos y puertos utilizados son También es diferente (443, http es 80). Además, debido a que garantiza la seguridad, https necesita devolver la clave y confirmar el algoritmo de cifrado con el servidor. En este caso, el número de apretones de manos con el servidor aumenta, lo que afecta el rendimiento y siendo engorroso.

2. Las características principales de http

1 Admite modo cliente/servidor

2 Simple y rápido: el cliente solo necesita el método de transmisión y la ruta para solicitar servicios al servidor. Los métodos de solicitud más utilizados son GET, HEAD y POST. Dado que cada protocolo http es simple, el tamaño del programa del servidor http es pequeño y la velocidad de comunicación es muy rápida.

3 Flexible: http permite la transmisión de cualquier tipo de objeto de datos. El tipo que se transmite está marcado por el tipo de contenido en el encabezado de la solicitud.

4 HTTP 0.9 y 1.0 utilizan conexiones no persistentes: cada conexión se limita a procesar solo una solicitud. Después de que el servidor procesa la solicitud del cliente y recibe la respuesta del cliente, la conexión se desconecta. Este método ahorra tiempo de transmisión. HTTP 1.1 utiliza conexiones persistentes: en lugar de crear una nueva conexión para cada objeto web, una conexión puede transferir múltiples objetos (esto está controlado por la Conexión asociada con la información del encabezado)

5 http es un protocolo sin estado. Sin estado se refiere a la falta de memoria para el procesamiento de transacciones, lo que significa que si el procesamiento posterior requiere información previa, debe retransmitirse, lo que puede resultar en un aumento en la cantidad de datos transmitidos por conexión.

(Protocolo sin estado: el estado del protocolo se refiere a la capacidad de la próxima transmisión de "recordar" la información transmitida esta vez. http no mantendrá la información transmitida por esta conexión para la próxima conexión, para garantizar la memoria del servidor.

Por ejemplo: por ejemplo, después de que un cliente obtiene una página web, cierra el navegador, luego lo inicia nuevamente y luego inicia sesión en el sitio web, pero el servidor no sabe que el cliente cerró el navegador una vez. Dado que el servidor web tiene que enfrentar el acceso concurrente desde muchos navegadores, para mejorar la capacidad del servidor web para manejar el acceso concurrente, al diseñar el protocolo HTTP, se estipula que cuando el servidor web envía mensajes y documentos de respuesta HTTP, el navegador web No se guarda ninguna información de estado del proceso que realiza la solicitud. Es posible que cuando un navegador accede al mismo objeto dos veces en tan solo unos segundos, el proceso del servidor no acepte la segunda solicitud de servicio porque ya le ha enviado un mensaje de respuesta. Dado que el servidor web no guarda ninguna información sobre el proceso del navegador web que envió la solicitud, el protocolo HTTP es un protocolo sin estado.

）

La diferencia entre el protocolo HTTP sin estado y Conexión: mantener vivo:

HTTP es un protocolo orientado a conexión sin estado. La apatridia no significa que HTTP no pueda mantener una conexión TCP, ni significa que HTTP utilice el protocolo UDP (sin conexión).

A partir de HTTP/1.1, Keep-Alive está habilitado de forma predeterminada para mantener la función de conexión. En pocas palabras, cuando se abre una página web, la conexión TCP utilizada para transmitir datos HTTP entre el cliente y el servidor no se cerrará. Si el client Al acceder nuevamente a la página web en este servidor se continuará utilizando esta conexión establecida.

Keep-Alive no mantiene la conexión permanentemente, tiene un tiempo de retención que se puede configurar en diferentes software de servidor (como Apache).

La versión 1.1 también introdujo el mecanismo de canalización, es decir, en la misma conexión TCP, el cliente puede enviar varias solicitudes al mismo tiempo. Esto mejora aún más la eficiencia del protocolo HTTP.

Por ejemplo, el cliente necesita solicitar dos recursos. El enfoque anterior era enviar primero la solicitud A en la misma conexión TCP, luego esperar a que el servidor respondiera y luego enviar la solicitud B después de recibirla. El mecanismo de canalización permite que el navegador emita una solicitud A y una solicitud B al mismo tiempo, pero el servidor aún responde a la solicitud A en orden y luego responde a la solicitud B una vez completada.

Tres flujos de trabajo

Una operación http se denomina transacción y el proceso de trabajo se puede dividir en cuatro pasos:

1) Primero, el cliente y el servidor deben establecer una conexión. Tan pronto como se hace clic en un hipervínculo, comienza el trabajo HTTP (se establece la conexión)

2) Después de eso, el cliente envía una solicitud al servidor. El formato de la solicitud es: Identificador uniforme de recursos (URL), número de versión del protocolo, seguido de información MIME que incluye modificadores de solicitud, información del cliente y posible contenido. (Enviar petición)

3) Después de que el servidor recibe la solicitud, proporciona la información de respuesta correspondiente. El formato es una línea de estado, que incluye el número de versión del protocolo de la información, seguida de información MIME que incluye modificadores de solicitud, información del cliente y posible contenido. (respuesta a la solicitud)

4) El cliente recibe la información devuelta por el servidor y la muestra en la pantalla del usuario a través del navegador, y luego el cliente se desconecta del servidor (desconectarse)

El proceso anterior puede ser que el cliente llegue al servidor web después de pasar por el servidor proxy.

Dado que HTTP se basa en el protocolo TCP/IP en la capa de transporte, TCP es un protocolo orientado a la conexión de un extremo a otro. El llamado extremo a extremo puede entenderse como comunicación entre procesos, por lo que HTTP necesita establecer una conexión TCP antes de iniciar la transmisión. El proceso de conexión TCP requiere el llamado "apretón de manos de tres vías", como se muestra en la figura. cifra. Una vez conectado, la transferencia puede comenzar. HTTP no desconectará la conexión TCP entre las finalización de la transferencia. Este es el comportamiento predeterminado en HTTP 1.1 (establecido a través del encabezado Conexión).

Explicación detallada de cuatro URL

URL: Localizador uniforme de recursos, un tipo de URI (Identificador uniforme de recursos), que se utiliza para describir un recurso en la red. El formato básico es el siguiente: esquema://host[:port#]/path/.../[ ;parámetros de URL][?cadena de consulta][#anchor]

El esquema especifica el protocolo utilizado por la capa inferior (por ejemplo: http, https, ftp).

La dirección IP o el nombre de dominio del servidor HTTP host.

":" es el puerto, el valor predeterminado es 80

ruta: es la ruta para acceder a los recursos

Lo que sigue a ";" son url-params: parámetros de URL, que se pueden utilizar como identificador de caché (ID de sesión).

cadena de consulta: los datos enviados al servidor http, que también se puede decir que son parámetros de consulta, separados por símbolos &.

Lo que sigue a "#" es el ancla.

Cinco mensajes de solicitud

5.1 El formato de mensaje solicitado es el siguiente:

1) Línea de solicitud, como GET /images/logo.gif HTTP/1.1, que significa solicitar el archivo logo.gif del directorio /images, utilizando el método get, y la versión del protocolo es http1.1

2) Encabezado de solicitud, como Accept-Language: en

3) Línea en blanco

4) Cuerpo del mensaje opcional

La línea de solicitud y el título deben terminar con un retorno de carro y un avance de línea, y la línea vacía solo debe contener un retorno de carro y un avance de línea.

5.2 Método de solicitud

Los primeros tres ya están en los protocolos http0.9 y http1.0, y los últimos cinco se agregaron después de http1.1.

OBTENER: enviar una solicitud a un recurso específico

POST: envíe datos al recurso especificado para procesar la solicitud (como enviar un formulario o cargar un archivo). Los datos se incluyen en la solicitud. Las solicitudes POST pueden resultar en la creación de nuevos recursos y/o modificación de recursos existentes.

HEAD: Solicita al servidor una respuesta coherente con la solicitud GET, pero no se devolverá el cuerpo de la respuesta. Este método le permite obtener la metainformación contenida en los encabezados de respuesta sin tener que transmitir todo el contenido de la respuesta. Este método se usa a menudo para probar la validez de un hipervínculo, si es accesible y si se actualizó recientemente (luego se usa principalmente para obtener información del encabezado de respuesta).

PUT: cargue el contenido más reciente en la ubicación de recursos especificada

OPCIONES: Devuelve los métodos de solicitud HTTP admitidos por el servidor para recursos específicos.

ELIMINAR: Solicite al servidor que elimine el recurso identificado por Request-URI

TRACE: solicitudes de eco recibidas por el servidor, para pruebas o diagnóstico

CONECTAR: El protocolo http1.1 está reservado para servidores proxy que pueden cambiar la conexión a una canalización.

PATCH: utilizado para aplicar modificaciones parciales a un recurso, agregado a la especificación RFC5789.

El resumen es: el método GET se usa para obtener datos en el servidor, el método POST se usa para modificar datos de recursos en el servidor, PUT se usa para cargar datos, DELETE se usa para eliminar recursos en el servidor y HEAD se usa para obtener información del encabezado de respuesta.

La diferencia entre OBTENER y POST:

1) La ubicación de los datos enviados es diferente: GET está después de la URL, mientras que POST está en el cuerpo del paquete HTTP.

2) El tamaño de los datos enviados por GET es limitado, hasta 1024 bytes, principalmente porque el navegador tiene restricciones en la longitud de la URL, pero no hay límite para los datos enviados por POST.

3) POST es más seguro que GET, porque GET expondrá cierta información en la URL y los datos enviados se mostrarán en la URL. Si la página se puede almacenar en caché o otros pueden acceder a ella, la contraseña de la cuenta de usuario se puede obtener del registro histórico material

4) El método GET requiere usar Request.QueryString para obtener el valor de la variable, mientras que el método POST usa Request.Form para obtener el valor de la variable.

Seis mensajes de respuesta

El cliente envía una solicitud al servidor y el servidor responde con una línea de estado. El contenido de la respuesta incluye: versión del protocolo del mensaje, código de éxito o error, información del servidor, metainformación de la entidad y contenido necesario de la entidad . Dependiendo de la categoría de la clase de respuesta, la respuesta del servidor puede contener contenido de entidad, pero no todas las respuestas tienen contenido de entidad.

Formato:

espacio de versión del protocolo http espacio de código de estado Frase de motivo retorno de carro y avance de línea (la frase de motivo es una descripción de texto simple), como

Siete códigos de respuesta de estado http

1XX (tipo de información): Indica que la solicitud se recibe y el procesamiento continúa

2XX (respuesta exitosa): Indica que la acción fue recibida, comprendida y recibida exitosamente

Seguir 200: indica que la solicitud se completó con éxito y el recurso solicitado se envió de regreso al cliente.

3XX (Redireccionamiento): Para completar la acción especificada, se debe aceptar el procesamiento posterior

Preste atención a 304: la página web solicitada no se ha modificado desde la última solicitud. Cuando el servidor devuelve esta respuesta, no devolverá el contenido de la página web, lo que significa que el último documento se ha almacenado en caché y se puede seguir utilizando.

4XX (clase de error del cliente): la solicitud contiene una sintaxis incorrecta o no se puede ejecutar correctamente

Preste atención al 404: un error 404 indica que el servidor se puede conectar, pero el servidor no puede obtener la página web solicitada y el recurso solicitado no existe. por ejemplo: se ingresó una URL incorrecta

5XX (clase de error del lado del servidor): el servidor no puede ejecutar correctamente una solicitud correcta

Ocho información de encabezado

8.1 Encabezados de solicitud HTTP comunes

If-Modified-Since: envía la hora de la última modificación de la página almacenada en caché del lado del navegador al servidor, y el servidor comparará esta hora con la hora de la última modificación del archivo real en el servidor. Si los tiempos son consistentes, se devuelve 304 y el cliente usa directamente el archivo de caché local. Si el tiempo es inconsistente, se devolverán 200 y el nuevo contenido del archivo. Después de recibirlo, el cliente descartará el archivo antiguo, almacenará en caché el archivo nuevo y lo mostrará en el navegador. (Esto está relacionado con el caché de comparación, que se discutirá más adelante. Lo opuesto es el encabezado de respuesta Última modificación)

If-None-Match: If-None-Match funciona con ETag. El principio de funcionamiento es agregar información de ETag en el encabezado de respuesta HTTP. Cuando el usuario solicita el recurso nuevamente, la información If-None-Match (el valor de ETag) se agregará al encabezado de la solicitud HTTP. Si el servidor verifica que la ETag del recurso no ha cambiado (el recurso no se ha actualizado), devolverá un estado 304 para indicarle al cliente que use el archivo de caché local. De lo contrario, se devolverá un estado 200 y un nuevo recurso y Etag (esto también está relacionado con el caché de comparación y tiene mayor prioridad que el par If-Modified-Since/Last-Modified anterior)

Cache-Control: especifica el mecanismo de almacenamiento en caché seguido de solicitudes y respuestas. Las directivas de caché son unidireccionales (las directivas de caché que aparecen en la respuesta pueden no aparecer en la solicitud) y son independientes (configurar Cache-Control en el mensaje de solicitud o en el mensaje de respuesta no modifica el procesamiento de la caché durante el procesamiento de otro mensaje. proceso ). Las instrucciones de almacenamiento en caché durante la solicitud incluyen no-cache, no-store, max-age, max-stale, min-fresh, only-if-cached, y las instrucciones en el mensaje de respuesta incluyen public, private, no-cache, no -store, no-transform, must-revalidate, proxy-revalidate, max-age, s-maxage. (Tanto en los encabezados de solicitud como en los encabezados de respuesta, sobre el almacenamiento en caché forzado)

Control de caché: público Tanto los clientes como los servidores pueden almacenar en caché

Control de caché: el cliente privado puede almacenar en caché

Cache-Control:no-cache requiere comparar el caché para verificar los datos almacenados en caché

Cache-Control:no-store No se almacenará en caché todo el contenido, no se activará el almacenamiento en caché forzado ni el almacenamiento en caché de comparación.

Cache-Control:max-age El contenido almacenado en caché caducará después de xxx segundos.

Cache-Control:min-fresh indica que el cliente puede recibir respuestas con un tiempo de respuesta menor que el tiempo actual más el tiempo especificado.

Cache-Control:max-stale indica que el cliente puede recibir mensajes de respuesta más allá del período de tiempo de espera. Si especifica un valor para mensajes máximos obsoletos, el cliente puede recibir mensajes de respuesta que excedan el valor especificado del período de tiempo de espera.

Aceptar: tipos MIME que el navegador puede aceptar. Por ejemplo: Aceptar: texto/html significa que el navegador puede aceptar el tipo de devolución de datos del servidor como texto/html, que es lo que a menudo llamamos documentos html.

Accept-Encoding: el navegador declara el método de codificación que puede aceptar, generalmente especificando el método de compresión, si admite la compresión y qué métodos de compresión admite (gzip, deflate).

Accept-Language: El navegador declara el idioma que acepta. La diferencia entre idioma y conjunto de caracteres: el chino es un idioma y el chino tiene varios conjuntos de caracteres, como big5, gb2312, gbk, etc.

Accept-Charset: conjunto de caracteres aceptable por el navegador

Agente de usuario: le dice al servidor HTTP el nombre y la versión del sistema operativo y el navegador utilizados por el cliente.

Tipo de contenido: Ejemplo: Tipo de contenido: aplicación/x-www-form-urlencoded.

Conexión: Por ejemplo:

Conexión: keep-alive Cuando se abre una página web, la conexión TCP utilizada para transmitir datos HTTP entre el cliente y el servidor no se cerrará. Si el cliente accede nuevamente a la página web en el servidor, continuará usando esta establecida conexión. . HTTP 1.1 realiza conexiones persistentes de forma predeterminada. Aprovechando las conexiones persistentes, cuando la página contiene múltiples elementos (como Applets, imágenes), el tiempo de descarga se reduce significativamente. Para lograr esto, el servlet necesita enviar un encabezado Content-Length en la respuesta. La forma más sencilla de lograrlo es escribir primero el contenido en un ByteArrayOutputStream y luego calcular su tamaño antes de escribir oficialmente el contenido.

Conexión: cerrar significa que una vez completada una Solicitud, la conexión TCP utilizada para transmitir datos HTTP entre el cliente y el servidor se cerrará. Cuando el cliente envíe una Solicitud nuevamente, es necesario restablecer la conexión TCP.

Referer: Contiene una URL desde la que el usuario accede a la página solicitada actualmente.

Host: (este campo de encabezado es obligatorio al enviar una solicitud) Se utiliza principalmente para especificar el host de Internet y el número de puerto del recurso solicitado, generalmente se extrae de la URL HTTP (debe incluirse en el protocolo http1.1)

Por ejemplo: ingresamos: http://www.guet.edu.cn/index.html en el navegador, y el mensaje de solicitud enviado por el navegador incluirá el campo de encabezado de solicitud de Host: Host: http://www.guet .edu.cn, aquí se utiliza el número de puerto predeterminado 80. Si se especifica el número de puerto, se convierte en: Host: especifique el número de puerto.

Cookie: uno de los encabezados de solicitud más importantes, envía el valor de la cookie al servidor HTTP.

Longitud del contenido: indica la longitud del cuerpo del mensaje de solicitud.

Autorización: información de autorización

8.2 Encabezados de respuesta HTTP comunes

Permitir: qué métodos de solicitud admite el servidor (como GET, POST, etc.)

Fecha: Indica la hora en que se envió el mensaje, el formato de descripción de la hora está definido por rfc822.

Expires: Indica cuando el documento debe considerarse caducado, por lo que ya no se almacenará en caché y se recuperará del servidor nuevamente, lo que actualizará el caché.

P3P: se utiliza para configurar cookies entre dominios, lo que puede resolver el problema del acceso entre dominios iframe a las cookies

Set-Cookie: un encabezado muy importante, que se utiliza para enviar cookies al navegador del cliente. Cada cookie escrita generará un Set-Cookie.

Por ejemplo: Set-Cookie: sc=4c31523a; ruta=/; dominio=.acookie.taobao.com

ETag: Se utiliza junto con If-None-Match.

Última modificación: se utiliza para indicar la fecha y hora de la última modificación del recurso. La última modificación también se puede configurar utilizando el método setDateHeader.

Tipo de contenido: el servidor WEB le dice al navegador el tipo y conjunto de caracteres del objeto al que responde.

Por ejemplo: Tipo de contenido: text/html;charset=utf-8

Longitud del contenido: indica la longitud del cuerpo de la entidad, representada por un número decimal almacenado en bytes.

Codificación de contenido: el servidor WEB indica qué método de compresión (gzip, deflate) utiliza para comprimir los objetos en la respuesta.

Rango de contenido: se utiliza para especificar la posición de inserción de una parte de toda la entidad y también indica la longitud de toda la entidad.

Lenguaje de contenido: el servidor WEB le dice al navegador el lenguaje natural utilizado por el objeto al que responde.

Conexión:

Por ejemplo: Conexión: keep-alive Cuando se abre una página web, la conexión TCP utilizada para transmitir datos HTTP entre el cliente y el servidor no se cerrará. Si el cliente accede nuevamente a la página web en el servidor, continuará utilice este enlace establecido Conexión.

Ubicación: se utiliza para redirigir a una nueva ubicación, que contiene una nueva dirección URL

Actualizar: Indica el tiempo después del cual el navegador debe actualizar el documento, en segundos.

Extraído de: http://www.cnblogs.com/EricaMIN1987_IT/p/3837436.html

Nueve mecanismos de almacenamiento en caché HTTP

El caché WEB (caché) se encuentra entre el servidor web y el cliente.

El caché guardará una copia del contenido de salida de acuerdo con la solicitud, como páginas html, imágenes, archivos. Cuando llegue la siguiente solicitud: si es la misma URL, el caché usa directamente la copia para responder a la solicitud de acceso. de enviar la solicitud al servidor de origen nuevamente.

El protocolo HTTP define encabezados relevantes para que el almacenamiento en caché web funcione lo mejor posible

9.1 Ventajas del almacenamiento en caché

Latencia de respuesta reducida: debido a que las solicitudes se atienden desde el servidor de caché (que está más cerca del cliente) en lugar del servidor de origen, el proceso lleva menos tiempo, lo que hace que el servidor web parezca responder más rápido.

Reducir el consumo de ancho de banda de la red: cuando se reutilizan las réplicas, se reduce el consumo de ancho de banda del cliente; los clientes pueden ahorrar costos de ancho de banda, controlar el crecimiento de los requisitos de ancho de banda y facilitar su administración.

9.2 Campos de encabezado relacionados con el almacenamiento en caché en mensajes http

Para tener una comprensión general de parte de la información del encabezado que se puede utilizar a continuación, se presentan los siguientes campos de encabezado relacionados con el almacenamiento en caché.

1. Campos de encabezado comunes (campos que se pueden usar tanto en mensajes de solicitud como en mensajes de respuesta)

2. Solicitar campos de encabezado

3. Campos del encabezado de respuesta

4. Campos de encabezado de entidad

9.3 Método de almacenamiento en caché

El almacenamiento en caché en realidad determina si se utiliza cierta información almacenada en el navegador de acuerdo con algunas reglas de política. Esta información de caché se puede considerar como una base de datos de caché que existe en el navegador (también se puede llamar caché local).

Clasificados según si es necesario reiniciar una solicitud al servidor, que se pueden dividir en dos categorías ( caching forzado y caching comparativo )

El tipo obligatorio no requiere una solicitud al servidor, mientras que el caché de comparación requiere una solicitud al servidor.

9.3.1 Forzar el almacenamiento en caché

Cuando ya tenga datos almacenados en caché y el tiempo de caché no haya expirado, utilice el almacenamiento en caché forzado.

El almacenamiento en caché forzado de http1.0 tiene dos campos, Pragma (que indica deshabilitar el almacenamiento en caché) y Expires (habilita el almacenamiento en caché y define el tiempo de caché). Si se usa al mismo tiempo, la prioridad de Pragma será mayor, pero el tiempo de caché definido por Expires en el mensaje de respuesta es relativo a la hora en el servidor. Si la hora en el cliente no coincide con la hora en el servidor (especialmente Si el usuario ha modificado la hora del sistema de su propia computadora ) , entonces el tiempo de caché puede no tener sentido. Para resolver este problema, http1.1 usa un nuevo campo: Cache-Control ( centrado en dominar , use esto como punto de referencia)

Nota: Para ser compatible con versiones anteriores del protocolo http, aún puede ver que muchos sitios web todavía incluyen estos dos campos. De hecho, son dos campos desechables.

Control de caché

Uso: "Control de caché": "directiva de caché"

Cuando se usa como encabezado de solicitud, los valores opcionales de la directiva de caché son:

Cuando se usa como encabezado de respuesta, los valores opcionales de la directiva de caché son:

En realidad, concéntrese en cinco valores: privado, público, sin caché, edad máxima, sin almacenamiento; el valor predeterminado es privado

privado: el cliente puede almacenar en caché

público: tanto el cliente como el servidor proxy se pueden almacenar en caché (los estudiantes de front-end pueden pensar en público y privado como lo mismo)

max-age=xxx: el contenido almacenado en caché caducará después de xxx segundos

no-cache: es necesario utilizar el caché de comparación para verificar los datos almacenados en caché

no-store: todo el contenido no se almacenará en caché, el almacenamiento en caché forzado y el almacenamiento en caché de comparación no se activarán.

Por ejemplo:

En la figura, Cache-Control solo especifica la edad máxima, por lo que el valor predeterminado es privado y el tiempo de caché es 31536000 segundos (365 días).

En otras palabras, si solicita estos datos nuevamente dentro de los 365 días, los datos en la base de datos de caché se obtendrán y utilizarán directamente.

9.3.2 Comparación de cachés

Comparar caché : es decir, se necesita una comparación para determinar si se puede utilizar el caché. Cuando el navegador solicita datos por primera vez, el servidor devolverá el identificador de caché y los datos al cliente, y el cliente realizará una copia de seguridad de ambos en la base de datos de caché. Al solicitar datos nuevamente, el cliente envía la ID de caché respaldada al servidor, y el servidor realiza un juicio basado en la ID de caché. Después de que el juicio es exitoso, devuelve un código de estado 304 para notificar al cliente que es relativamente exitoso y que los datos almacenados en caché se pueden utilizar.

Compare los problemas resueltos por el almacenamiento en caché : El tiempo de caché ha expirado, pero el servidor no ha actualizado el recurso. En este momento, si el cliente solicita al servidor que reenvíe el recurso nuevamente, desperdiciará ancho de banda y tiempo. Comparar el caché es hacerle saber al servidor que los archivos de caché almacenados actualmente por el cliente son en realidad consistentes con todos sus propios archivos y permitir que el cliente use directamente su propio caché, lo que mejora la tasa de reutilización del caché.

El caché de comparación se juzga en función del identificador de caché del encabezado de solicitud y del encabezado de respuesta.

Comparar los campos de identificación de caché utilizados por los cachés

Última modificación / Si se modificó desde

Última modificación:

Cuando el servidor responde a la solicitud, le dice al navegador la hora de la última modificación del recurso.

Si se modifica desde:

Cuando vuelva a solicitar el servidor, utilice este campo para notificar al servidor la hora de la última modificación del recurso devuelto por el servidor durante la última solicitud.

Después de recibir la solicitud, el servidor descubre que el encabezado If-Modified-Since se compara con la hora de la última modificación del recurso solicitado.

Si la hora de la última modificación del recurso es mayor que If-Modified-Since, significa que el recurso se ha modificado nuevamente, se responderá todo el contenido del recurso y se devolverá el código de estado 200;

Si la hora de la última modificación del recurso es menor o igual a If-Modified-Since, significa que el recurso no tiene nuevas modificaciones y responde con HTTP 304 para indicarle al navegador que continúe usando el caché guardado.

La última modificación es buena, pero no particularmente buena, porque si un recurso se modifica en el servidor, pero su contenido real no ha cambiado en absoluto, la entidad completa se devolverá al cliente porque la hora de la última modificación no coincide ( incluso si hay un recurso idéntico en la caché del cliente)

ETag/ If-None-Match (mayor prioridad que Last-Modified/If-Modified-Since)

Para resolver la posible inexactitud de Última modificación mencionada anteriormente, Http1.1 también introdujo el campo de encabezado de entidad ETag.

Etag puede entenderse como un identificador único calculado por el servidor utilizando un algoritmo de cifrado para identificar un recurso. Cuando el cliente realiza la primera solicitud, el servidor la transmitirá al cliente junto con los datos, y el cliente retendrá el campo ETag . y llevarlo al servidor junto con la siguiente solicitud. El servidor solo necesita comparar si la ETag enviada por el cliente es consistente con la ETag del recurso en su propio servidor, y puede determinar si el recurso se ha modificado en relación con el cliente.

Etiqueta:

Cuando el servidor responde a la solicitud, le dice al navegador el identificador único del recurso actual en el servidor (las reglas de generación las determina el servidor).

Si no coincide:

Cuando vuelva a solicitar el servidor, utilice este campo para notificar al servidor el identificador único de los datos de la caché del cliente.

Después de que el servidor recibe la solicitud y descubre que hay un encabezado If-None-Match, lo compara con el identificador único del recurso solicitado.

Diferente, indica que el recurso ha sido modificado nuevamente, responde a todo el contenido del recurso y devuelve el código de estado 200;

El mismo, indicando que no hay nuevas modificaciones en el recurso, responde con HTTP 304, indicándole al navegador que continúe usando el caché guardado.

Nota: Si hay dos pares de campos al mismo tiempo, ambos deben pasarse antes de poder utilizar el almacenamiento en caché.

Resumir

Para el almacenamiento en caché forzado, el servidor notifica al navegador un tiempo de caché. Durante el tiempo de caché, la siguiente solicitud utilizará directamente el caché. Si no está dentro del tiempo, se ejecutará una política de caché de comparación.

Para el almacenamiento en caché de comparación, la información Etag y Última modificación en el caché se envía al servidor a través de la solicitud y el servidor los verifica. Cuando se devuelve un código de estado 304, el navegador usa directamente el caché.

La primera solicitud del navegador:

Cuando el navegador vuelve a solicitar:

Extraído de: http://www.cnblogs.com/vajoy/p/5341664.html, http://www.cnblogs.com/chenqf/p/6386163.html

10. Resuelva el problema de la apatridia HTTP

10.1 Guardar información de estado a través de cookies

Las cookies son en realidad datos (normalmente cifrados) que el sitio web almacena en el cliente y en el terminal local del usuario (lado del cliente) para identificar al usuario. Las cookies son datos almacenados temporalmente en su computadora por el servidor (formato .txt) . archivo de texto), el servidor utiliza el estado de la transmisión HTTP para identificar su computadora. Cuando navega por un sitio web, el servidor web primero enviará una pequeña información a su computadora y la cookie registrará el texto o algunas opciones que escriba en el sitio web.

A través de las Cookies, el servidor puede saber claramente que la solicitud 2 y la solicitud 1 provienen del mismo cliente.

10.2 Guardar información de estado a través de la sesión

El mecanismo de sesión es un mecanismo del lado del servidor: el servidor utiliza una estructura similar a una tabla hash (o puede usar una tabla hash) para guardar información.

Cuando el programa necesita crear una sesión para la solicitud de un cliente, el servidor primero verifica si la solicitud del cliente ya contiene un identificador de sesión, llamado ID de sesión. Si se incluye un ID de sesión, significa que este cliente se ha utilizado antes. Después Al crear una sesión, el servidor recuperará la sesión de acuerdo con la identificación de la sesión y la usará (si no se puede recuperar, puede crear una nueva). Si la solicitud del cliente no incluye la identificación de la sesión, se creará una sesión para el cliente y se generará una sesión con esta sesión. La identificación de sesión asociada. El valor de la identificación de sesión debe ser una cadena que no sea repetitiva ni fácil de encontrar patrones para falsificación. Esta identificación de sesión se devolverá al cliente en este respuesta para el almacenamiento.

Implementación de la sesión:

1. Utilice cookies para lograr

El servidor asigna un JSESSIONID único a cada sesión y lo envía al cliente a través de Cookie.

Cuando el cliente inicia una nueva solicitud, llevará este JSESSIONID en el encabezado de la cookie. De esta forma, el servidor puede encontrar la Sesión correspondiente al cliente.

2. Utilice la reescritura de URL para lograr

La reescritura de URL significa que el servidor lleva el parámetro JSESSIONID en todos los enlaces enviados a la página del navegador, de modo que cuando el cliente haga clic en cualquier enlace, el JSESSIONID se enviará al servidor. Si ingresa directamente la URL del recurso del servidor en el navegador para solicitar el recurso, la sesión no coincidirá.

La implementación de Session de Tomcat utiliza mecanismos de reescritura de URL y cookies al principio. Si se descubre que el cliente admite cookies, continuará usando cookies y dejará de usar reescritura de URL. Si descubre que las cookies están deshabilitadas, utilice siempre la reescritura de URL. Cuando el desarrollo jsp esté procesando la sesión, recuerde usar respuesta.encodeURL() para los enlaces en la página.

10.3 Mantener el estado a través de variables de formulario

Además de las cookies, también puede utilizar variables de formulario para mantener el estado. Por ejemplo, Asp.net mantiene el estado a través de un cuadro de entrada = "oculto" llamado ViewState, como por ejemplo:

Este principio es similar a las cookies, excepto que la información adjunta a cada solicitud y respuesta se convierte en una variable de formulario.

10.4 Mantener el estado a través de QueryString

QueryString transmite información al servidor guardando la información al final de la dirección solicitada. Generalmente se usa junto con un formulario. Un QueryString típico como: www.xxx.com/xxx.aspx?var1=value&var2=value2

Nota: Me gustaría compartir mi propia opinión aquí. Creo que mantener un estado significa que el servidor identifica un determinado estado. En realidad, esto es muy similar al mecanismo de sesión. Consulte los detalles a continuación.

Once cookies y sesiones

11.1 Significado

mecanismo de cookies

Las cookies son pequeños fragmentos de texto almacenados por el servidor en la máquina local y enviados al mismo servidor con cada solicitud. El mecanismo de gestión de estado HTTP IETF RFC 2965 es una especificación general de cookies. El servidor web envía cookies al cliente mediante encabezados HTTP. En el terminal del cliente, el navegador analiza estas cookies y las guarda en un archivo local. Automáticamente vincula estas cookies a cualquier solicitud al mismo servidor .

Específicamente, el mecanismo de cookies utiliza una solución que mantiene el estado en el lado del cliente. Es un mecanismo de almacenamiento para el estado de la sesión en el lado del usuario y requiere que el usuario active la compatibilidad con cookies en el lado del cliente. El papel de las cookies es un esfuerzo por resolver los defectos sin estado del protocolo HTTP.

La distribución de cookies ortodoxas se logra extendiendo el protocolo HTTP. El servidor agrega una línea especial de instrucciones al encabezado de respuesta HTTP para solicitar al navegador que genere la cookie correspondiente de acuerdo con las instrucciones. Sin embargo, los scripts puros del lado del cliente, como JavaScript, también pueden generar cookies. El uso de cookies se envía automáticamente al servidor en segundo plano por el navegador según ciertos principios. El navegador verifica todas las cookies almacenadas. Si el alcance declarado de una cookie es mayor o igual a la ubicación del recurso que se solicitará, la cookie se adjunta al encabezado de solicitud HTTP del recurso solicitado y se envía al servidor.

El contenido de la cookie incluye principalmente: nombre, valor, tiempo de caducidad, ruta y dominio. La ruta y el dominio juntos forman el alcance de la cookie. Si no se establece el tiempo de caducidad, significa que la vida útil de esta cookie es durante la sesión del navegador. Cuando se cierra la ventana del navegador, la cookie desaparece. Este tipo de cookie que dura mientras dura la sesión del navegador se denomina cookie de sesión. Las cookies de sesión generalmente no se almacenan en el disco duro sino en la memoria, por supuesto, este comportamiento no está especificado en la especificación. Si se establece un tiempo de vencimiento, el navegador guardará las cookies en el disco duro. Si cierra y abre el navegador nuevamente, estas cookies seguirán siendo válidas hasta que se exceda el tiempo de vencimiento establecido. Las cookies almacenadas en el disco duro se pueden compartir entre diferentes procesos del navegador, como dos ventanas de IE. Cada navegador tiene diferentes métodos de procesamiento de las cookies almacenadas en la memoria. (Por tanto, también existen cookies de memoria y cookies de disco duro)

El mecanismo de sesión utiliza una solución que mantiene el estado en el lado del servidor. Al mismo tiempo, también hemos visto que dado que la solución para mantener el estado en el lado del servidor también necesita guardar una identidad en el lado del cliente, es posible que el mecanismo de sesión deba utilizar el mecanismo de cookies para lograr el propósito de guardar la identidad. Session proporciona una forma conveniente de gestionar variables globales.

La sesión es para cada usuario. El valor de la variable se almacena en el servidor. Se utiliza un ID de sesión para distinguir qué variable de sesión de usuario es. Este valor se devuelve al servidor a través del navegador del usuario al acceder. Cuando el cliente desactiva las cookies, Estos valores también se pueden configurar para que get los devuelva al servidor.

En términos de seguridad: cuando visita un sitio que utiliza sesiones y crea una cookie en su máquina, se recomienda que el mecanismo de sesión en el lado del servidor sea más seguro porque no leerá arbitrariamente la información almacenada por el cliente.

mecanismo de sesión

El mecanismo de sesión es un mecanismo del lado del servidor, que utiliza una estructura similar a una tabla hash (o puede usar una tabla hash) para guardar información.

Cuando el programa necesita crear una sesión para la solicitud de un cliente, el servidor primero verifica si la solicitud del cliente ya contiene un identificador de sesión (llamado ID de sesión). Si es así, significa que se ha creado una sesión para este cliente anteriormente. el servidor recuperará la sesión de acuerdo con la identificación de la sesión y la usará (si no se puede recuperar, se creará una nueva). Si la solicitud del cliente no contiene la identificación de la sesión, se creará una sesión para el cliente y una Se generará el ID de sesión asociado con esta sesión. , el valor del ID de sesión debe ser una cadena que no se repita ni sea fácil de encontrar patrones para imitar. Este ID de sesión se devolverá al cliente en esta respuesta para su almacenamiento.

El método para guardar este ID de sesión puede utilizar cookies, de modo que durante el proceso de interacción, el navegador pueda mostrar automáticamente esta identificación al servidor de acuerdo con las reglas. Generalmente, el nombre de esta cookie es similar a SEEESIONID. Pero las cookies se pueden deshabilitar artificialmente y debe haber otros mecanismos para pasar la identificación de la sesión al servidor cuando las cookies están deshabilitadas.

Una técnica utilizada con frecuencia se llama reescritura de URL, que agrega la identificación de la sesión directamente al final de la ruta URL. También existe una técnica llamada formar campos ocultos. Es decir, el servidor modificará automáticamente el formulario y agregará un campo oculto para que la identificación de la sesión pueda devolverse al servidor cuando se envíe el formulario.

11.2 Función

Todos ellos son mecanismos que pueden mantener el estado.

11.3 Diferencias

11.3.1 Diferencias en los métodos de acceso

Las cookies sólo pueden almacenar cadenas ASCII

La sesión puede almacenar cualquier tipo de datos.

11.3.2 Diferencias en políticas de privacidad

Las cookies se almacenan en el navegador del cliente y son visibles para el cliente. Algunos programas del cliente pueden espiar, copiar o incluso modificar el contenido de las cookies. La sesión se almacena en el servidor y es transparente para el cliente, por lo que no hay riesgo de que se filtre información confidencial.

Si elige cookies, una mejor manera es intentar no escribir información confidencial, como contraseñas de cuentas, en las cookies. Es mejor cifrar la información de las cookies como Google y Baidu, y luego descifrarla después de enviarla al servidor para garantizar que solo la persona pueda leer la información de la cookie. Será mucho más fácil si elige Sesión. De todos modos, se coloca en el servidor y cualquier privacidad en la Sesión se puede proteger de manera efectiva.

11.3.3 Diferencias en el período de validez

Cualquiera que haya utilizado Google sabe que si ha iniciado sesión en Google, su información de inicio de sesión de Google será válida durante mucho tiempo. Los usuarios no necesitan iniciar sesión nuevamente cada vez que visitan, ya que Google registrará permanentemente la información de inicio de sesión del usuario. Para lograr este efecto, utilizar cookies sería una mejor opción. Simplemente configure el atributo de tiempo de vencimiento de la cookie en un número muy, muy grande.

Debido a que la sesión se basa en una cookie denominada JSESSIONID y el tiempo de vencimiento predeterminado de la cookie JSESSIONID es -1, la sesión dejará de ser válida siempre que el navegador esté cerrado, por lo que la sesión no puede lograr el efecto de que la información sea permanentemente válida. No se puede lograr mediante la reescritura de direcciones URL. Y si el tiempo de espera de la sesión es demasiado largo, cuantas más sesiones acumule el servidor, más fácil será provocar un desbordamiento de la memoria.

11.3.4 Diferentes presiones del servidor

La sesión se almacena en el lado del servidor y cada usuario generará una sesión. Si hay muchos usuarios accediendo simultáneamente, se generarán muchas sesiones, lo que consumirá mucha memoria. Por lo tanto, es poco probable que los sitios web con visitas simultáneas extremadamente altas, como Google, Baidu y Sina, utilicen Session para realizar un seguimiento de las sesiones de los usuarios.

Las cookies se almacenan en el lado del cliente y no ocupan recursos del servidor. Si hay muchos usuarios leyendo simultáneamente, Cookie es una buena opción. Para Google, Baidu y Sina, las cookies pueden ser la única opción.

11.3.5 Diferencias en la compatibilidad con navegadores

Las cookies deben ser compatibles con el navegador del cliente. Si el cliente desactiva las cookies o no las admite, el seguimiento de la sesión no será válido. En el caso de las aplicaciones WAP, las cookies normales no sirven de nada.

Si el navegador del cliente no admite cookies, se debe utilizar la reescritura de la dirección URL y de sesión. Cabe señalar que todas las URL que utilizan el programa de sesión deben reescribirse; de lo contrario, el seguimiento de la sesión no será válido. Para aplicaciones WAP, la reescritura de dirección URL de sesión+puede ser su única opción.

Si el cliente admite cookies, la cookie se puede configurar para que sea válida dentro de esta ventana y subventanas del navegador (establezca el tiempo de vencimiento en –1), o se puede configurar para que sea válida en todas las ventanas del navegador (establezca el tiempo de vencimiento en un valor mayor que un número entero de 0). Pero la sesión sólo puede ser válida dentro de esta ventana del lector y sus subventanas. Si dos ventanas del navegador son independientes entre sí, utilizarán dos sesiones diferentes. (La sesión está relacionada con diferentes ventanas en IE8)

11.3.6 Diferencias en el soporte entre dominios

La cookie admite el acceso entre dominios. Por ejemplo, si el atributo de dominio está configurado en ".biaodianfu.com", todos los nombres de dominio con el sufijo ".biaodianfu.com" pueden acceder a la cookie. Las cookies entre dominios ahora se utilizan comúnmente en Internet, como Google, Baidu, Sina, etc. La sesión no admitirá el acceso a nombres de dominios cruzados. La sesión sólo es válida dentro del nombre de dominio donde se encuentra.

Es posible que el uso exclusivo de Cookies o de Sesión no logre los resultados deseados. En este momento deberías intentar utilizar Cookie y Sesión al mismo tiempo. La combinación de Cookie y Session logrará muchos efectos inesperados en proyectos prácticos.

11.4 Contacto

El cliente envía una solicitud al servidor por primera vez. En este momento, el servidor genera un ID de sesión único y lo devuelve al cliente (a través de una cookie). Se almacena en la memoria del cliente y corresponde a una ventana del navegador. A las características del protocolo HTTP, esta vez se perdió la conexión.

Cuando este cliente envíe una solicitud al servidor en el futuro, llevará la cookie en la solicitud. Dado que la cookie contiene el ID de sesión, el servidor sabe que este es el cliente en este momento.

En otras palabras, la cookie puede almacenar un identificador del ID de sesión.

Extracto de: http://blog.csdn.net/weixin_37196194/article/details/55806366

Doce nuevas características de http2

http2 lanzado en 2015

12.1 Protocolo binario

La información del encabezado de la versión HTTP/1.1 debe ser texto (codificación ASCII) y el cuerpo de los datos puede ser texto o binario. HTTP / 2 es un protocolo binario completo: la información del encabezado y el cuerpo de los datos son binarios y colectivamente se denominan "marcos": marcos de información del encabezado y marcos de datos.

Una ventaja del protocolo binario es que se pueden definir tramas adicionales. HTTP/2 define casi diez tipos de tramas, sentando las bases para futuras aplicaciones avanzadas. Si utiliza texto para implementar esta función, el análisis de datos será muy problemático y el análisis binario será mucho más conveniente.

12.2 Tareas múltiples

HTTP / 2 reutiliza las conexiones TCP. En una conexión, tanto el cliente como el navegador pueden enviar múltiples solicitudes o respuestas al mismo tiempo sin el orden correspondiente uno a uno, evitando así la "congestión del encabezado de línea". (El bloqueo del encabezado de la cola significa que cuando el cliente o servidor envía un mensaje, si un dato es demasiado grande, tomará mucho tiempo y habrá muchos esperando ser enviados más tarde, lo que provocará congestión)

Por ejemplo, en una conexión TCP, el servidor recibió una solicitud A y una solicitud B al mismo tiempo, por lo que respondió primero a la solicitud A. Resultó que el proceso de procesamiento llevó mucho tiempo, por lo que envió la parte procesada de A. solicitud y luego respondió a la solicitud B. Una vez completada, envíe la parte restante de la solicitud A.

Esta comunicación bidireccional en tiempo real se denomina multiplexación.

12.3 Paquetes de datos

Debido a la función multitarea, los paquetes de datos http2 se envían desordenados y los paquetes de datos consecutivos en la misma conexión pueden pertenecer a diferentes respuestas. Por lo tanto, el paquete debe marcarse para indicar a qué respuesta pertenece.

HTTP/2 llama a todos los paquetes de datos de cada solicitud o respuesta un flujo de datos. Cada flujo de datos tiene un número único. Cuando se envía un paquete de datos, se debe marcar con un ID de flujo de datos para distinguir a qué flujo de datos pertenece. Además, también se estipula que la ID del flujo de datos enviado por el cliente es siempre un número impar y la ID del flujo de datos enviado por el servidor es un número par.

Cuando el flujo de datos se envía a la mitad, tanto el cliente como el servidor pueden enviar una señal (trama RST_STREAM) para cancelar el flujo de datos. La única forma de cancelar el flujo de datos en la versión 1.1 es cerrar la conexión TCP. Esto significa que HTTP/2 puede cancelar una solicitud mientras mantiene la conexión TCP abierta y disponible para otras solicitudes.

El cliente también puede especificar la prioridad del flujo de datos. Cuanto mayor sea la prioridad, antes responderá el servidor.

12.4 Compresión de encabezado

El protocolo HTTP no tiene estado y toda la información debe adjuntarse a cada solicitud. Por lo tanto, muchos campos de la solicitud se repiten, como Cookie y Agente de usuario, y se debe incluir exactamente el mismo contenido en cada solicitud, lo que desperdicia mucho ancho de banda y también afecta la velocidad.

HTTP/2 ha optimizado esto e introducido la compresión de encabezados. Por un lado, la información del encabezado se comprime usando gzip o compress antes de enviarse; por otro lado, el cliente y el servidor mantienen una tabla de información del encabezado al mismo tiempo, todos los campos se almacenarán en esta tabla y un número de índice. se generará, por lo que no se enviarán los mismos campos en el futuro. , solo se envía el número de índice, lo que mejora la velocidad.

12.5 Empuje del servidor

HTTP/2 permite que el servidor envíe recursos activamente al cliente sin solicitud, lo que se denomina inserción del servidor.

Un escenario común es que el cliente solicita una página web que contiene muchos recursos estáticos. En circunstancias normales, el cliente debe recibir la página web, analizar el código fuente HTML, encontrar recursos estáticos y luego emitir una solicitud de recursos estáticos. De hecho, el servidor puede esperar que después de que el cliente solicite la página web, es probable que solicite recursos estáticos nuevamente, por lo que envía activamente estos recursos estáticos al cliente junto con la página web.

Puede buscar aquí para leer el artículo sobre el protocolo http en el registro web de Ruan Yifeng, que es breve y conciso.

Capítulo del navegador web front-end: resumen de conocimientos del protocolo HTTP