Preguntas frecuentes sobre HTTP

Aprenda de: xiaolincoding.com

Prefacio

HTTP es un protocolo muy importante en la capa de aplicación, ya sea un examen o una entrevista, existe una alta probabilidad de aprobarlo. Este artículo brinda algunas preguntas frecuentes sobre HTTP y soluciones simples. Según las ideas, los lectores pueden verificar la información y refinarla ellos mismos. La mayoría de las preguntas en este artículo provienen de la introducción de la red gráfica | Codificación Xiaolin (xiaolincoding.com) . Si no lo ha visto, se recomienda leer primero la serie de gráficos Xiaolin y luego leer este artículo para profundizar su impresión cuando estás abrumado.

pregunta

1. ¿Qué es HTTP?

El nombre completo de HTTP es HyperTextTransferProtocol , que es el Protocolo de transferencia de hipertexto . Hipertexto se refiere a texto que va más allá del texto ordinario, incluido texto, imágenes, videos, etc. El protocolo de transmisión se refiere a las especificaciones y estándares para la transmisión de información entre dos entidades. En conjunto, HTTP es un estándar y una especificación que define la transmisión de datos de hipertexto, incluidos texto, imágenes, videos, etc., entre dos entidades.

2.¿Cuáles son los códigos de estado HTTP comunes?

1xx es un mensaje rápido que indica que el protocolo actual todavía se encuentra en un estado intermedio y requiere algunas operaciones adicionales.

2xx es información de éxito, el mensaje fue recibido y procesado correctamente.

3xx es información de redirección, que requiere que el cliente vuelva a visitar la dirección redirigida.

4xx es un error del cliente. La solicitud enviada es incorrecta y el servidor no puede realizar la solicitud.

5xx es el mensaje de error del servidor. Se produjeron algunos errores dentro del servidor.

3.¿Cuáles son los campos comunes de HTTP?

** Campo de host : **Nombre de dominio.

** Campo Longitud del contenido : ** Indica la longitud de este mensaje de respuesta.

** Campo de conexión : ** Si el valor es Keep-Alive, significa que se trata de una conexión larga. Cuando el cliente envía una solicitud, se utilizará una conexión larga hasta que una de las partes desconecte el enlace.

** Campo Tipo de contenido : ** Indica el formato de la información de respuesta

Campo de codificación de contenido : indica el formato comprimido de la información de respuesta.

4. ¿Cuál es la diferencia entre OBTENER y POST?

Según la especificación RFC, GET se utiliza para solicitar un determinado recurso y es de solo lectura. POST contiene un cuerpo que solicita el procesamiento de ciertos recursos en el servidor.

Los parámetros GET generalmente se incluyen en la URL y los parámetros POST generalmente se incluyen en el cuerpo. Sin embargo, eso no significa que POST sea seguro si los datos están contenidos en el cuerpo. Un atacante aún puede interceptar el cuerpo de POST y obtener los datos que contiene. Por lo tanto, si desea una comunicación segura, debe utilizar https.

5.¿Son GET y POST seguros e idempotentes?

La seguridad significa que la solicitud no destruirá algunos recursos del servidor. Idempotencia significa que la misma solicitud se enviará al servidor varias veces y se obtendrá el mismo resultado.

Según la especificación, GET es seguro e idempotente porque la solicitud GET es una solicitud de solo lectura y no provocará modificaciones adicionales en los recursos del servidor. Las solicitudes POST no son seguras y son parcialmente idempotentes porque las solicitudes POST procesan algunos recursos en el servidor.

Pero si se hace de acuerdo con la especificación, GET también puede contener algunas solicitudes para modificar el servidor, dependiendo de cómo esté codificado el servidor.

6. ¿Cuáles son los métodos de implementación del almacenamiento en caché HTTP?

Para algunos datos que rara vez cambian, no es necesario solicitarlos al servidor cada vez, sino que se pueden almacenar en caché localmente y mostrarse directamente en la siguiente solicitud.

Los métodos de implementación HTTP incluyen principalmente el almacenamiento en caché forzado (almacenamiento en caché activo) y el almacenamiento en caché negociado.

7. ¿Qué es el almacenamiento en caché forzado?

El almacenamiento en caché forzado significa que siempre que el navegador determine que una determinada solicitud puede utilizar el caché local, utilizará directamente los datos locales sin enviarlos al servidor. Dado que la decisión de utilizar el caché recae en el navegador, También se llama caché activo.

El almacenamiento en caché forzado se realiza a través de los dos campos siguientes:

• Cache-Control, es un tiempo relativo;
• Expires, es un tiempo absoluto;

El proceso específico es el siguiente:

• Cuando el usuario envía una solicitud al servidor a través del navegador por primera vez, el servidor puede configurar estos dos campos al devolver la solicitud para indicar el tiempo de vencimiento del recurso devuelto.

• Cuando el navegador envía la misma solicitud por segunda vez, puede verificar estos dos campos de la solicitud anterior para verificar si el caché ha caducado. Si no ha caducado, utilice los datos locales directamente. Si ha caducado, solicitará de nuevo.

• Una vez que el servidor recibe la solicitud nuevamente, puede restablecer estos dos campos y regresar.

8. ¿Qué es el caché de negociación?

El código de respuesta de algunas solicitudes es 304, lo que significa que el servidor le dice al cliente que se puede usar un recurso local. Este método para decirle al navegador si se puede usar el caché se llama caché de negociación. El almacenamiento en caché de negociación generalmente se implementa a través del campo en el encabezado de la solicitud If-Modified-Sincey el campo en el encabezado de la respuesta .Last-Modified

9. ¿Cuáles son las ventajas de HTTP/1.1?

• Multiplataforma, siempre que se implemente el protocolo HTTP, el protocolo HTTP se puede utilizar para la comunicación y la interacción.
• Sencillo y rápido para empezar.
• Flexible y fácil de expandir, es un protocolo de capa de aplicación y el protocolo subyacente es variable, como agregar protocolo de enlace TLS.

10. ¿Cuáles son las desventajas de HTTP/1.1?

• No es lo suficientemente seguro: se transmite en texto claro, no se puede verificar que el mensaje esté completo y sea nuevo y no existe ningún proceso para verificar la identidad del servidor.
• Sin estado, es más problemático completar algunas operaciones relacionadas. Pero se puede solucionar utilizando la tecnología de cookies. Al incorporar la cookie con cada solicitud, el servidor conocerá cierta información sobre la última interacción.

11. ¿Cómo funciona HTTP/1.1?

El rendimiento es relativamente promedio, pero ha mejorado mucho en comparación con HTTP/1.0.

• Conexión larga

HTTP/1.0 requiere un protocolo de enlace de tres vías y cuatro ondas cada vez que se envía una solicitud, lo que consume mucho tiempo y recursos. HTTP/1.1 utiliza conexiones largas. Después del protocolo de enlace de tres vías, el cliente y el servidor pueden interactuar con el protocolo HTTP varias veces en una ronda de comunicación TCP hasta que una de las partes desconecta activamente el enlace o el servidor se desconecta activamente después de demasiado tiempo. Rompe el enlace.

• Canalización y bloqueo de cabecera de línea

Después de realizar una conexión larga, el cliente puede enviar varias solicitudes al servidor en secuencia a la vez . A diferencia de la versión anterior, la siguiente solicitud solo se puede enviar después de que se responda cada respuesta. Sin embargo, el servidor solo puede procesar una solicitud a la vez. Cuando una de las solicitudes enviadas en secuencia se bloquea por algún motivo, todas las solicitudes en cola posteriores también se bloquearán, lo que hará que el cliente siga solicitando. Si no hay datos, Este es el bloqueo de cabecera de línea .

Los siguientes HTTP/2.0 y HTTP/3.0 están optimizados principalmente para el rendimiento de HTTP/1.1.

12. ¿Cuáles son las diferencias entre HTTP y HTTPS?

• HTTP no es seguro. HTTPS agrega el protocolo de seguridad SSL/TLS a HTTP a través de algunas soluciones criptográficas, que implementan principalmente las funciones de verificación de integridad, autenticación de identidad del lado del servidor y cifrado de datos.

• HTTP solo requiere un protocolo de enlace de tres vías TCP para la transmisión de datos, mientras que HTTPS también requiere el proceso de protocolo de enlace SSL/TLS para la transmisión de datos.

• Los puertos de los dos son diferentes, HTTP es el puerto 80, HTTPS es el puerto 443

13. ¿Qué problemas de HTTP resuelve HTTPS?

• durante la transferencia de datos. Utilice un algoritmo de cifrado híbrido para lograr la confidencialidad, utilice un algoritmo de cifrado asimétrico para completar el intercambio de claves y utilice un algoritmo de cifrado simétrico para completar conversaciones posteriores.
• Utilice una función hash para garantizar que no se pueda alterar todo el contenido.
• Utilice un mecanismo de certificado digital para garantizar la autenticidad del servidor y evitar ataques de intermediario.

14. ¿Cómo establece HTTPS una conexión? ¿Cuál fue la interacción?

Hay tres objetivos principales al crear enlaces:

• El cliente verifica el certificado del servidor y obtiene la clave pública real y correcta del servidor.
• Intercambie claves de sesión simétricas basadas en cifrados asimétricos
• Utilice claves de sesión para completar la comunicación cifrada en interacciones posteriores

15. ¿Cómo se garantiza la integridad de los datos de la aplicación HTTPS?

**El núcleo para garantizar la integridad es la función hash. ** Específicamente, el mensaje primero se divide en varios fragmentos, luego se comprime cada fragmento y luego se usa una función hash en cada fragmento comprimido para convertirlo en un código de identificación MAC, y la verificación posterior del código MAC se puede identificar. si estos datos han sido manipulados.

16. ¿HTTPS es necesariamente seguro y confiable?

Desde la perspectiva del protocolo, actualmente es muy seguro y confiable. La fuente de esta seguridad es el principio de criptografía. Por ejemplo, el problema del logaritmo discreto garantiza que la clave privada no se pueda derivar de la clave pública. Por lo tanto, mientras Como el problema de la criptografía no está resuelto, entonces HTTPS No hay ningún problema de seguridad.

Pero a veces algunos ataques al servidor o al cliente pueden causar problemas de seguridad. Específicamente, si se filtra la clave privada del servidor, el atacante puede pretender ser el servidor para comunicarse con el cliente, que es un hombre en el ataque medio. Para el cliente, si se modifica la biblioteca de certificados raíz en la máquina del cliente y se agrega el certificado de un nodo malicioso, entonces el nodo malicioso puede disfrazarse de un nodo normal para comunicarse con el cliente.

17. ¿Qué mejoras de rendimiento aporta HTTP/1.1 respecto a HTTP/1.0?

• Al utilizar una conexión larga, no es necesario pasar por el proceso de tres apretones de manos y cuatro saludos para cada solicitud.
• Utilizando el mecanismo de canalización, se pueden enviar muchas solicitudes a la vez sin esperar una respuesta en tiempo real antes de enviar la siguiente solicitud.

Pero todavía hay algunos problemas.

• No hay compresión en la cabeza y cuanto más grande sea la cabeza, más lenta será;
• Las solicitudes solo pueden comenzar desde el cliente y el servidor solo puede responder pasivamente;
• El servidor responde en el orden de las solicitudes, si el servidor responde lentamente, el cliente nunca podrá solicitar datos, es decir, el encabezado de la cola está bloqueado;

18. ¿Qué optimizaciones se han realizado en HTTP/2?

Principalmente completó el siguiente trabajo:

• Compresión de la cabeza
• formato binario
• Las transmisiones compatibles también admiten la transmisión simultánea.
• El servidor puede enviar trabajos de forma proactiva

1. Compresión de la cabeza

HTTP/2 realizará la compresión del encabezado. Si las solicitudes consecutivas tienen el mismo encabezado de solicitud, las partes duplicadas se eliminarán.

2. formato binario

Los campos en HTTP/1.1 son todos estructuras de cadenas, pero en HTTP/2, algunos campos se convierten en bits binarios (bits de bandera).

3. Admite transmisión, transmisión simultánea y inserción activa del servidor

En HTTP/1.1, en una conexión TCP, las solicitudes solo se pueden procesar una por una. Si una solicitud se procesa muy lentamente, las solicitudes posteriores se bloquearán. Esto es un bloqueo de cabecera.

En HTTP/2, se introduce el concepto de Stream , y múltiples Streams reutilizan un enlace TCP .

Se pueden encapsular diferentes solicitudes HTTP en diferentes Streams. Cada Stream tiene un ID de Stream diferente, que puede transmitirse al mismo tiempo y luego aceptarse al mismo tiempo. Posteriormente, la solicitud y la respuesta se pueden ensamblar a través del ID de Stream.

Para el servidor, puede crear activamente una secuencia y enviarla al cliente. La secuencia creada por el cliente es un número impar y la secuencia del servidor es un número par.

Actualmente, HTTP / 2 utiliza el protocolo TCP en la capa inferior, por lo que las limitaciones de rendimiento se deben principalmente a las limitaciones de rendimiento del protocolo TCP. Por ejemplo, TCP garantiza que los bytes recibidos deben estar completos, lo que provocará que las solicitudes posteriores tengan llegó. , pero antes de recibir la solicitud anterior, TCP no entregará los datos a la capa superior.

19. ¿Qué optimizaciones se han realizado en HTTP/3?

El mayor cambio de HTTP/3 es cambiar el protocolo TCP subyacente al protocolo UDP y al mismo tiempo implementar QUIC (pronunciado "rápido") en la capa de aplicación para mejorar el rendimiento. Actualmente, se ha publicado el RFC de HTTP/3, pero la tasa de popularidad aún no es alta.

20.¿Ideas de optimización HTTP/1.1?

• Reducir el número de solicitudes enviadas
• Reducir el tamaño de la respuesta del lado del servidor

Para la primera idea, primero puede hacer un uso extensivo de la idea de almacenamiento en caché . Para algunos datos estáticos, guardar más datos localmente puede reducir la cantidad de solicitudes enviadas. En segundo lugar, en el lado del cliente, los archivos pequeños que originalmente se solicitaron varias veces se pueden fusionar en una solicitud para solicitar un recurso grande a la vez. Por ejemplo, después de codificar varias imágenes usando BASE64, se pueden transmitir varias imágenes a la vez. Finalmente, también puede retrasar el envío de solicitudes, es decir, para algunos recursos que no son muy necesarios, no envíe solicitudes temporalmente y luego realice solicitudes al servidor cuando sea necesario.

La segunda idea es la compresión. La compresión se divide en compresión sin pérdida y compresión con pérdida. Esto debe seleccionarse de acuerdo con el escenario comercial específico. Si el escenario comercial no es tan preciso para los datos, como algunas texturas pequeñas, entonces puede usar Lossy. La compresión reduce significativamente la cantidad de datos.

21.¿Cómo optimizar HTTPS?

HTTPS agrega una capa de TSL basada en HTTP, que implementa principalmente:

• Autenticación de certificado, el cliente necesita verificar el certificado del servidor para confirmar la verdadera identidad.
• Utilice un mecanismo criptográfico híbrido que utiliza criptografía asimétrica para intercambiar claves simétricas, ECDHE.
• Comunicaciones cifradas posteriores mediante claves simétricas

Primero considere algunos escenarios de optimización comunes:

• Optimización de hardware, es decir, uso de soporte de hardware que admita cifrado y descifrado eficientes para mejorar la velocidad.
• Optimización de software, optimizar algunos algoritmos.

También puede optimizar los tres puntos anteriores agregados a HTTPS:

Para los certificados, en primer lugar, se puede reducir el tamaño del certificado, es decir, se puede utilizar el cifrado de curva elíptica, porque con la misma seguridad, los parámetros de la curva elíptica requieren menos bytes. En segundo lugar, se pueden reducir los pasos de verificación del certificado. Verificación tradicional Al verificar, debe verificar la cadena de certificados y descargar la lista de revocación de certificados para verificar si el certificado ha caducado. Puede cambiarlo para consultar el estado del certificado. El servidor consulta periódicamente a la CA para conocer el estado del certificado y la CA devolverá el estado firmado, por lo que cuando el servidor devuelve la solicitud del cliente con el estado del certificado firmado por la CA, se puede verificar directamente, evitando la engorrosa cadena de certificados. proceso.

Para el algoritmo de intercambio de claves secretas, intente utilizar cifrado de curva elíptica para el intercambio, lo que puede aumentar la velocidad y, después de la actualización de TLS, el protocolo de enlace se puede cambiar de 4 a 3 veces.

Para las claves simétricas, será muy problemático si es necesario negociar algunas claves de sesión para cada solicitud, para solucionar esta situación se puede adoptar la solución de ID de sesión, es decir, tanto el cliente como el servidor guardarán este secreto. Luego, la clave se identifica mediante el ID de sesión. El usuario puede traer el ID de sesión durante la siguiente transmisión, y el servidor consulta el estado del ID de sesión. Si aún existe, las comunicaciones posteriores se realizarán directamente a través de esta clave secreta simétrica. También puede utilizar el esquema Ticket de sesión, es decir, el servidor utiliza una de sus propias claves secretas para cifrar la clave secreta simétrica y luego la transmite al cliente. La próxima vez que el cliente la transmita, utilizará este secreto cifrado. clave y use esta clave secreta. El mensaje cifrado se envía de vuelta. Si el servidor puede usar su propia clave secreta para descifrar el mensaje, y la clave secreta descifrada se puede usar normalmente, puede usar esta clave secreta para la comunicación directa, evitando la Necesidad de que el servidor mantenga muchos clientes.Clave simétrica. Para garantizar la seguridad, preste atención a establecer un tiempo de vencimiento.

22. Después de tener el protocolo HTTP, ¿por qué todavía necesitamos el protocolo RPC?

HTTP y la mayoría de los protocolos RPC se basan actualmente en TCP, por lo que primero debemos hablar sobre el protocolo TCP. TCP solo proporciona servicios confiables, orientados a la conexión y basados ​​​​en flujos de bytes. Para la capa superior, solo se puede ver el flujo de bytes, es decir, el mensaje no tiene límites. Por lo tanto, RPC y HTTP aparecieron basados ​​en TCP. Estas dos son en realidad dos direcciones diferentes. HTTP apareció principalmente para adaptarse a los navegadores, porque la página de inicio de cada empresa es diferente y las tecnologías utilizadas también son diferentes. Para poder comunicarse al mismo tiempo. tiempo, se muestra en un navegador, por lo que se utiliza HTTP. Actualmente, RPC se utiliza principalmente en las empresas, especialmente después del auge de las aplicaciones y los clientes. Debido a que el protocolo RPC es más personalizable, se puede optimizar y personalizar para desarrollar el protocolo de comunicación interna de cada empresa para mejorar el rendimiento. Entonces, ambas son dos direcciones, por lo que ambas son necesarias.

23. Existe el protocolo HTTP, ¿por qué necesitamos WebSocket?

WebSocket se utiliza principalmente para lograr una comunicación full-duplex entre ambas partes, es decir, el servidor puede enviar mensajes activamente al cliente.

¿Cuáles son los métodos de implementación para que el servidor envíe información activamente al cliente, como escanear un código QR para iniciar sesión?

• Sigue encuestando. Es decir, el cliente envía continuamente solicitudes al servidor hasta que el servidor devuelve información de que el código QR se ha iniciado sesión correctamente.

• Sondeo largo. El cliente envía una solicitud al servidor, espera durante mucho tiempo y envía otra solicitud si el tiempo expira sin éxito. hasta que se devuelva información de éxito.

• Utiliza el protocolo WebSocket para la comunicación. WebSocket, al igual que HTTP, es un protocolo basado en TCP. Después de experimentar tres apretones de manos TCP, utiliza el protocolo HTTP para actualizar al protocolo WebSocket . La comunicación posterior utiliza el formato de protocolo WebSocket.