Explicación detallada del protocolo HTTP (1)

1. Descripción general de HTTP

1. ¿Qué es HTTP?

Protocolo de transferencia de hipertexto (HTTP)

HTTP是一个基于请求与响应的、无状态的应用层协议，用于在两点之间传输超文本数据，常基于TCP/IP协议传输数据。

HTTP fue diseñado para proporcionar 发布和接收HTML页面的方法una

2. Características de HTTP

Basado en el protocolo TCP/IP: se puede garantizar que la conexión sea segura y confiable, pero no se puede garantizar que el contenido sea seguro y privado.
Basado en el modelo de solicitud y respuesta: una solicitud corresponde a una respuesta
Sin estado: cada solicitud es independiente entre sí.

3. Ventajas y desventajas de HTTP

ventaja:

Simple: el formato del mensaje HTTP es encabezado + cuerpo, y la información del encabezado también está en un formato clave-valor simple, que es fácil de analizar.
Flexible y fácil de expandir: HTTP funciona en la capa de aplicación y la capa inferior se puede cambiar a voluntad. Además, los métodos de solicitud HTTP, códigos de estado, campos de encabezado y otros componentes se pueden personalizar, conectar y usar.
Versátil y multiplataforma

Las desventajas son todas armas de doble filo:

sin Estado:
- Beneficios: el servidor no necesita guardar el estado de cada conexión HTTP, lo que reduce la presión sobre el servidor y utiliza todos los recursos para proporcionar servicios.
- Desventajas: Es más problemático completar operaciones relacionadas, puede utilizar Cookie y Sesión para mantener el estado manualmente.
Transmisión de texto claro
- Beneficios: Conveniente para el análisis y la depuración
- Desventajas: es fácil para otros obtener el contenido de la solicitud o respuesta, lo cual no es seguro.

La mayor desventaja de HTTP es que es inseguro, lo cual se refleja en:

La comunicación utiliza texto claro y no está cifrada, por lo que el contenido puede ser robado.
No se verificará la identidad de las partes que se comunican y se podrá acceder a sitios disfrazados.
No se puede verificar la integridad y exactitud del mensaje y el contenido de la comunicación puede ser alterado.

Los problemas de seguridad de HTTP se han resuelto en HTTPS y se ha introducido la capa SSL/TSL para lograr la máxima seguridad.

4. ¿Por qué se necesita HTTP después de TCP?

Estructura en capas, TCP es responsable de la transmisión de un extremo a otro y HTTP se centra en la lógica de la capa de aplicación. Los servicios de capa superior no deberían estar fuertemente acoplados a los protocolos subyacentes, ya que los protocolos se actualizarán y eliminarán.
TCP ya es responsable de muchas cosas: agregarle campos y funciones hará que TCP sea demasiado grande y difícil de actualizar y mantener.
El desarrollo de aplicaciones de red directamente para TCP no favorece el desarrollo centrado en el negocio y puede quedar atrapado en los detalles del protocolo.

2. Solicitud HTTP

1. Composición del mensaje de solicitud HTTP

El mensaje de solicitud HTTP consta de 4 partes ( 请求行+请求头+请求空行+请求体)

El siguiente es un mensaje de solicitud para el método POST:

1. Línea de solicitud

请求行分为三个部分：请求方法、请求地址URL和HTTP协议版本, separados por espacios. Por ejemplo, OBTENER /index.html HTTP/1.1.

1. Método de solicitud

Hay 8 métodos de solicitud definidos por HTTP/1.1:

Los dos más utilizados son GETy POST.

2、URL

URI: Identificador uniforme de recursos, identifica de forma única un recurso en la red

URL: 统一资源定位符es un método abstracto de identificación única de la ubicación de recursos.

Composición: <protocolo>://<host>:<puerto>/<ruta>

A veces se pueden omitir el puerto y la ruta (el número de puerto predeterminado para HTTP es 80)

La URL es un subconjunto de URI, que no solo identifica de forma única un recurso, sino que también proporciona una forma de acceder al recurso.

3. Versión del protocolo

El formato de la versión del protocolo es: HTTP/número de versión principal.número de versión menor. Los más utilizados son HTTP/1.0, HTTP/1.1, HTTP/2 y HTTP/3.

2. Solicitar encabezado

El encabezado de la solicitud agrega información adicional al mensaje de solicitud y consta de pares clave-valor, un par por línea, y el nombre y el valor están separados por dos puntos.

3. Solicite una línea en blanco

Habrá una línea en blanco al final del encabezado de la solicitud, que indica el final del encabezado de la solicitud, seguida de los datos de la solicitud.

4. Cuerpo de solicitud

Los datos de la solicitud no se utilizan en el método GET, sino en el método POST. POST方法适用于需要客户填写表单的场合.

Los encabezados de solicitud más utilizados relacionados con los datos de la solicitud son Content-Type y Content-Length.

2. OBTENER y PUBLICAR

1. La diferencia entre los dos

CONSEGUIR

El significado de GET es obtener el recurso especificado del servidor, lo que requiere que el servidor coloque el recurso de destino en la parte de datos del mensaje de respuesta y lo envíe al cliente.
Una solicitud GET no incluye el cuerpo de la solicitud, está separado por un signo de interrogación después de la URL y luego los parámetros de la solicitud y los valores correspondientes se agregan directamente al final. Las desventajas de este método son:
- La longitud del parámetro es limitada y no se pueden transferir grandes cantidades de datos.
- No apto para transmitir datos privados.
GET también puede tener un cuerpo de solicitud, pero RFC define que la función de GET es solicitar recursos, por lo que, según esta semántica, GET no requiere un cuerpo de solicitud.

CORREO

El significado de POST es procesar los recursos especificados del servidor en consecuencia en función del contenido del cuerpo de la solicitud.
Los beneficios de encapsular los parámetros de la solicitud en el cuerpo de la solicitud en forma de pares clave-valor son:
- El navegador no limita el tamaño del cuerpo de la solicitud y puede transmitir grandes cantidades de datos.
- Los datos no se mostrarán directamente en la URL, lo cual es relativamente seguro. Pero HTTP es una transmisión de texto claro, puedes verlo tomando el paquete.
Las URL POST también pueden aceptar parámetros, pero generalmente nadie lo hace.

2. ¿Son seguros e idempotentes?

Seguro: las solicitudes no destruirán los recursos del servidor

Idempotente: la misma solicitud se realiza varias veces y los resultados devueltos son los mismos.

en conclusión:

Las solicitudes en sí no pueden reflejar nada, depende de lo que realmente hacen.
El método GET se utiliza generalmente para leer datos y es de solo lectura, por lo que es seguro e idempotente.
- Por lo tanto, la respuesta a la solicitud GET se puede almacenar en caché y el contenido de la respuesta se puede almacenar en caché en el navegador o en el servidor proxy.
POST se usa generalmente para agregar o modificar datos, por lo que no es seguro ni idempotente.
- Por lo tanto, los navegadores generalmente no almacenan en caché las respuestas a las solicitudes POST.
Sin embargo, en el desarrollo real, las solicitudes GET se pueden utilizar para modificar y eliminar datos, y POST también se puede utilizar para consultar datos.

Entonces, GET no es seguro ni idempotente en este momento, y POST es seguro e idempotente, por lo que aún debe determinarse en función del uso real.

3. Respuesta HTTP

1. ¿Qué es una respuesta?

响应内容是服务器返回给浏览器的内容。

Cuando el servidor recibe la solicitud del navegador, enviará un mensaje de respuesta al navegador y el navegador lo mostrará según el contenido de la respuesta.

2. Formato del mensaje de respuesta

La respuesta HTTP es similar a la solicitud HTTP y también consta de 4 partes:

línea de respuesta
encabezado de respuesta
Responder a líneas vacías
cuerpo de respuesta

Mire un mensaje de respuesta simple:

Línea de respuesta:

HTTP/1.1 200 correcto

Encabezado de respuesta:

Servidor: Apache-Coyote/1.1

Tipo de contenido: texto/html;charset=UTF-8

Longitud del contenido: 624

Fecha: lunes 3 de noviembre de 2014 06:37:28 GMT

Responder a líneas vacías

cuerpo de respuesta

Análisis:

Línea de respuesta:

HTTP/1.1 200 OK: El protocolo de respuesta es HTTP1.1 y el código de estado es 200, lo que indica que la solicitud fue exitosa. OK es la explicación del código de estado;

Encabezado de respuesta:

Servidor: Apache-Coyote/1.1: Información de la versión del servidor;

Tipo de contenido: text/html;charset=UTF-8: el cuerpo de la respuesta es un archivo html y la codificación utilizada es UTF-8;

Longitud del contenido: 624: el cuerpo de la respuesta es de 724 bytes;

Set-Cookie: JSESSIONID=C97E2B4C55553EAB46079A4F263435A4;Path=/hello: Cookie respondió al cliente;

Fecha: lunes, 3 de noviembre de 2014 06:37:28 GMT: tiempo de respuesta, que puede tener una diferencia de zona horaria de 8 horas;

Responder a una línea vacía:

Al igual que la línea en blanco de la solicitud, su propósito es separar el encabezado y el cuerpo de la respuesta.

Cuerpo de respuesta:

A veces, el cuerpo de la respuesta es un archivo html al que el navegador puede acceder directamente.

Si se accede a una página jsp, la respuesta devuelta también es un archivo html. 服务器将该jsp翻译成了一个htmly luego responder al navegador.

响应体的类型，由响应头的Content-Type指出。

3. Campos comunes de HTTP

1. Solicitar campos

Host: cuando el cliente envía una solicitud, se utiliza para especificar el nombre de dominio del servidor.
- Anfitrión: www.A.com
Aceptar: el cliente le dice al servidor qué formato de datos recibe.
- Aceptar: */* , lo que significa que cualquier formato es aceptable
Accept-Encoding: el cliente le dice al servidor los métodos de compresión que admite.
- Aceptar codificación: gzip, deflate
Agente de usuario: el cliente le dice al servidor la información de su navegador.
Referer: el cliente le dice al servidor la dirección de origen de la solicitud actual, que puede usarse para evitar enlaces directos o realizar estadísticas.
Conexión: use conexión larga TCP

2. Campo de respuesta

Tipo de contenido: el servidor le dice al cliente el formato de esta respuesta.
- Tipo de contenido: texto/html; juego de caracteres = utf-8
Longitud del contenido: la longitud en bytes de esta respuesta.
- Longitud del contenido: 1000
Codificación de contenido: especifica el método de compresión de los datos devueltos por el servidor.
- Codificación de contenido: gzip
Conexión: use conexión larga TCP
- Conexión: mantener vivo
Set-Cookie: Cookie enviada por el servidor al cliente

3. Código de estado de la línea de respuesta

El código de estado de respuesta consta de tres dígitos, 表示服务器对请求的响应结果.

Equivale a un código secreto unilateral entre el servidor y el navegador, cuando el navegador recibe estos tres dígitos comprende el significado del servidor.

ParaCódigo de estado de respuesta HTTP 第一个数字定义了响应的类别, Los dos últimos dígitos no tienen una clasificación específica. El primer número tiene cinco valores posibles. La introducción específica es la siguiente:

Clasificación	Descripción de la clasificación
1x	Mensaje rápido, el servidor ha recibido la solicitud, pero necesita que el cliente continúe realizando la operación
2xx	Éxito, el mensaje fue recibido y procesado exitosamente.
3xx	Redirigir, la ubicación del recurso cambia y el cliente necesita reenviar la solicitud.
4xx	Se produjo un error en el cliente. El mensaje de solicitud enviado fue incorrecto y el servidor no pudo procesarlo.
5xx	Se produjo un error en el servidor. Se produjo un error mientras el servidor procesaba la solicitud.

Los códigos de estado específicos de uso común son los siguientes:

código de estado	significado
200	`请求成功`, el navegador mostrará la información de respuesta en el lado del navegador.
302	expresado `重定向`. Por ejemplo, cuando un navegador accede a un recurso, el servidor responde al navegador con un código de estado 302 y envía una nueva URL a través del encabezado de respuesta Ubicación, indicándole al navegador que solicite esta URL. Esto es redirección.
304	Después de acceder a un recurso por primera vez, el navegador almacenará en caché el recurso localmente. `再访问该资源时`Si el recurso no ha cambiado por segunda vez, el servidor responderá al navegador con un código de estado 304 y se lo informará `使用本地缓存的资源`.
404	Un tipo de error del cliente, como en el lado del navegador `请求一个不存在的资源`, cuando aparecerá un código de estado 404 en el lado del navegador.
405	Un tipo de error del cliente, indicado `当前的请求方式不支持`. Por ejemplo, si el servidor solo procesa solicitudes GET y la solicitud del cliente está en modo POST, aparecerá un código de estado 405 en este momento.
500	`服务器端错误`Por ejemplo, si se produce una excepción como un puntero nulo en el código del lado del servidor, el navegador recibirá un código de estado 500 enviado por el servidor.

Explicación detallada de la serie 300.

301: movido permanentemente, el servidor reenvía automáticamente la solicitud a la nueva dirección
302: Redirección, el servidor devuelve una nueva dirección al navegador y el navegador visita esta dirección nuevamente para obtener datos.
304: El servidor le dice al navegador que el recurso no ha sido modificado y usa el caché local.

4. Encabezado de respuesta

Formato:

Nombre del encabezado de respuesta: valor
Por ejemplo, Servidor: Apache-Coyote/1.1

Encabezados de respuesta de uso común:

Nombre del encabezado de respuesta	significado
Tipo de contenido	El servidor le dice al cliente el formato de datos y el formato de codificación (conjunto de caracteres) de este cuerpo de respuesta.
Disposición de contenido	El servidor le dice al cliente en qué formato abrir los datos del cuerpo de la respuesta.

Explicación detallada:

Disposición de contenido
- El valor predeterminado está en línea y se abre en la página actual.
- También se puede configurar como archivo adjunto para abrir el cuerpo de la respuesta como un archivo adjunto para descargar el archivo.

5. Órgano de respuesta

El cuerpo de la respuesta son los datos transmitidos.

4. Diferentes formas de salto de recursos

请求转发(adelante) y 请求重定向(redireccionamiento) 定时刷新pueden realizar un salto de recursos, pero tienen algunas diferencias.

1. Diferencias en los métodos de salto de recursos.

Solicitar reenvío :
- Una petición, una respuesta
- La barra de direcciones permanece sin cambios.
- La misma aplicación sólo puede redirigirse dentro del servidor y no puede reenviarse a otros servidores.
Solicitar redirección :
- Dos solicitudes, dos respuestas, diferentes objetos de solicitud (el servidor creará un nuevo objeto de solicitud cada vez que se solicite)
- La barra de direcciones ha cambiado.
- Puede saltar dentro del servidor o a diferentes aplicaciones en diferentes servidores.
Actualización periódica :
- Dos solicitudes, dos respuestas, diferentes objetos de solicitud
- La barra de direcciones ha cambiado.
- Se puede utilizar para saltar recursos dentro del servidor y también para saltar recursos entre diferentes aplicaciones y diferentes servidores.
- La diferencia entre la actualización programada y la redirección de solicitudes es 定时刷新可以设置时间间隔que, por ejemplo, para implementar la operación de "inicio de sesión exitoso, regrese a la página de inicio después de 5 segundos".

2. Proceso de implementación del método de salto de recursos.

Resumen de una frase: 转发是服务器行为，重定向是客户端行为. ¿Por qué dices esto? Depende del flujo de trabajo de dos acciones:

Proceso de reenvío:

El navegador del cliente envía una solicitud http
El servidor web acepta esta solicitud.
服务器调用内部的一个方法在容器内部完成请求处理和转发动作
Enviar recursos de destino a los clientes

Lo que se muestra en la barra de ruta del navegador del cliente sigue siendo la ruta de la primera visita, lo que significa que el cliente no puede sentir que el servidor la ha reenviado.

El comportamiento de reenvío significa que el navegador sólo realiza una solicitud de acceso.

Proceso de redirección:

El navegador del cliente envía una solicitud http
Una vez que el servidor web lo acepta, envía un código de estado 302 y la nueva ubicación correspondiente al navegador del cliente.
客户浏览器发现是302响应，则自动再发送一个新的http请求, la URL de solicitud es la nueva dirección de ubicación
服务器根据此请求寻找资源并发送给客户端

Dado que el navegador volvió a emitir la solicitud, no existe el concepto de entrega de la solicitud.

La ruta redirigida se muestra en la barra de ruta del navegador del cliente y los clientes pueden observar el cambio de dirección.

En el comportamiento de redirección, el navegador realiza al menos dos solicitudes de acceso.

在重定向的过程中，传输的信息会被丢失。

3. Diferencias funcionales entre reenvío y redirección

Reenvío: el cliente envía una solicitud y el servidor salta a varias direcciones según la lógica interna y devuelve el resultado final al cliente.

Redirección: el cliente envía una solicitud y el servidor devuelve un código de estado 302 y una nueva dirección, lo que requiere que el cliente realice otra solicitud. Después de que el cliente solicita una nueva dirección, el servidor devuelve el resultado final.

En pocas palabras, el reenvío es algo interno del servidor. Por ejemplo, A está a la mitad de una tarea, se la envía a B para que continúe y finalmente la completa. Para el cliente, solo conoce la A que solicitó primero, pero no conoce la B en el medio, ni siquiera C y D.

Redirección significa que la solicitud se envía a A. A determina que el asunto no se puede completar y requiere que el cliente acceda nuevamente a B. B descubre que se puede hacer y se completa. En este momento, el navegador puede ver que la dirección ha cambiado y el botón de retroceso histórico también está iluminado. Los redireccionamientos pueden acceder a recursos fuera de su propia aplicación web.

Ejemplos de la vida real:

Supongamos que solicita una determinada licencia,

Adelante: Primero fue a la Oficina A. Después de que la Oficina A lo miró, se dieron cuenta de que este asunto debería ser manejado por la Oficina B. Sin embargo, no lo enviaron de regreso, sino que le pidieron que se sentara un rato y se fue. a la oficina administrativa para contactar a B. Después de pedirles que lo hicieran, lo enviaron.

Redirección: Primero fue a la oficina A y la gente de la oficina A dijo: "Este asunto no es nuestra responsabilidad, vaya a la oficina B". Luego, salió de la oficina A y tomó un autobús hasta la oficina B usted solo.