Red informática (3) -Protocolo de capa de aplicación: HTTP y HTTPS

一 、 HTTP

HTTPEl protocolo (Protocolo de transferencia de hipertexto), que es un protocolo de transmisión de la capa de aplicación basado en el protocolo TCP / IP, es simplemente una regla para la transmisión de datos entre el cliente y el servidor. HTTPEs un protocolo sin estado, lo que significa que la siguiente solicitud no recuerda lo que se envió en la última solicitud, pero si necesita recordar el estado de inicio de sesión del usuario en varias páginas, ¿qué debe hacer? Así que se introdujo la tecnología de cookies y la cookie se utilizó para la gestión de registros.

1.1 ¿URL dada URI?

• URI: identificador de recursos uniforme, localizador de recursos uniforme, se puede utilizar para identificar un recurso único
• URL: localizador uniforme de recursos, localizador uniforme de recursos, es un URI específico, la URL se puede usar para identificar un recurso, pero también especificar cómo apuntar al recurso

URI es equivalente a la identificación de la tarjeta de identificación, el uso de la identificación de la tarjeta de identificación puede identificar a una persona, mientras que la URL es más detallada, es un subconjunto de URI, vívidamente hablando, puede hacer la dirección en la tarjeta de identificación, ya sea una identificación de tarjeta de identificación o la dirección de la casa de una persona puede identificar de forma única a la persona, y la URL presta más atención a cómo el localizador encuentra a la persona y encuentra el recurso, y la URL se usa más en Internet

1.2 mensaje de solicitud HTTP

El mensaje de solicitud HTTP consta de cuatro partes: línea de solicitud, encabezado de solicitud, línea en blanco de solicitud y cuerpo de solicitud.

请求行

La línea de solicitud consta de tres partes: método de solicitud, ruta de solicitud y versión de solicitud. El formato general es el siguiente:

GET / HTTP/1.1

Hay varias formas de solicitar:

• GET: solicitud para obtener el recurso identificado por el Request-URI
• POST: agregue nuevos datos después del recurso identificado por Request-URI
• HEAD: el encabezado del mensaje de respuesta que solicita obtener el recurso identificado por el Request-URI
• PUT: Solicite al servidor que almacene o modifique un recurso, y use Request-URI como su identificación
• ELIMINAR: Solicite al servidor que elimine el recurso identificado por el Request-URI
• TRACE: Solicite al servidor que envíe la información de la solicitud recibida, principalmente para pruebas o diagnóstico
• CONNECT: reservado para uso futuro
• OPCIONES: solicitud para consultar el rendimiento del servidor, o consultar opciones y requisitos relacionados con los recursos

La diferencia entre GET y POST:

• Los parámetros transportados en el método GET usan el formulario key = val y & empalmando detrás de la URL, mientras que los datos transportados en el método POST están en el cuerpo de la solicitud
• La URL solicitada por GET tiene un tamaño de espacio, mientras que POST no
• Use el método GET porque los parámetros se incluyen en la URL de la solicitud, por lo que es relativamente inseguro
• Básicamente, ambos usan el protocolo TCP

请求头

El encabezado de la solicitud consta de una serie de pares clave-valor, lo que permite al cliente enviar información adicional al servidor o la propia información del cliente.

Encabezados de solicitud comunes:

• User-Agent: el navegador le dice al servidor la información de la versión del navegador

  La información del encabezado se puede obtener del lado del servidor para solucionar el problema de compatibilidad del navegador

• Referer: decirle al servidor de dónde proviene la solicitud actual

  Rol: trabajo anti-sanguijuelas y estadístico

请求空行

Se utiliza para separar el encabezado de la solicitud y el cuerpo de la solicitud de una solicitud POST.

请求体

Hay un cuerpo de solicitud solo cuando se envía una solicitud POST

1.3 mensaje de respuesta HTTP

El formato del mensaje de respuesta HTTP es aproximadamente el mismo que el del mensaje de solicitud HTTP, y también tiene cuatro partes: línea de respuesta, encabezado de respuesta, mensaje de respuesta y cuerpo de respuesta

响应行

La línea de respuesta consta de tres partes: el número de versión del protocolo HTTP, el código de estado y la descripción del código de estado correspondiente.

HTTP/1.1 200 OK （CRLF）

código de estado:

• 1xx: el servidor recibe el mensaje del cliente, pero no completa la aceptación. Después de esperar un período de tiempo, envía códigos de estado 1xx (poco común)

• 2xx: Éxito. Representante: 200

• 3xx: Redirigir. Representante: 302 (redireccionamiento), 304 (caché de acceso)

• 4xx: error del cliente. Representante: 404 (la ruta de solicitud no tiene un recurso correspondiente) 405: el método de solicitud no tiene un método doXxx correspondiente

• 5xx: error del lado del servidor. Representante: 500 (se produjo una excepción dentro del servidor)

响应头

Nombre del encabezado: valor

Encabezados de respuesta comunes

• Tipo de contenido: el servidor le dice al cliente el formato de datos y el formato de codificación del cuerpo de la respuesta

• Disposición de contenido: el servidor le dice al cliente que abra los datos del cuerpo de la respuesta en qué formato

  Valor: 1. en línea: valor predeterminado, abrir en la página actual

  2.attachment; filename = xxx: abre el cuerpo de la respuesta como un archivo adjunto. descarga de archivos

1.4 ¿Conexión larga? ¿Conexión corta?

En HTTP1.0, la conexión corta se usa por defecto, lo que significa que cada vez que el cliente y el servidor realizan una operación HTTP, se establece una conexión y el enlace se interrumpe cuando finaliza la tarea. Cuando el navegador del cliente accede a una determinada HTML u otro tipo de Cuando la página web contiene otros recursos web, debe volver a establecer un enlace cada vez que encuentre este recurso.

A partir de HTTP1.1, las conexiones largas se utilizan de forma predeterminada para mantener las características de la conexión. Cuando se utiliza el protocolo HTTP para conexiones largas, esta línea de encabezados de solicitud se agregará a los encabezados de respuesta.

Connection:keep-alive

En el caso de utilizar un enlace largo, cuando se abre una página web, la conexión entre el cliente y el servidor no se desconectará inmediatamente. Cuando el cliente vuelva a acceder al servidor, seguirá utilizando la conexión establecida. Por supuesto, Keep-Alive no Mantendrá la conexión para siempre, tiene un tiempo de espera, este tiempo se puede configurar en un software de servidor diferente

En abstracto, la realización de conexiones largas y cortas es en realidad la realización de conexiones TCP largas y cortas. Cuando se usa el protocolo TCP, la conexión debe establecerse antes de las operaciones de lectura y escritura. Cuando se completan las operaciones de lectura y escritura, las dos partes no necesitan este enlace. Puede liberar la conexión, utilizar el protocolo de enlace de tres vías para establecer la conexión y agitar sus manos cuatro veces para liberar la conexión. El establecimiento y liberación de cada conexión requiere algunos recursos.

Ventajas y desventajas de las conexiones largas y cortas:

• El uso de conexiones largas puede ahorrar más operaciones de establecimiento y conexión de TCP, reducir el desperdicio y ahorrar tiempo, y es adecuado para escenarios donde los recursos se solicitan con frecuencia.
• La conexión corta es relativamente simple de administrar para el servidor. Las conexiones existentes son todas conexiones útiles y no se requieren medios de control adicionales. Es adecuado para situaciones en las que el departamento de recursos se solicita con frecuencia

1.5 ¿HTTP guardar estado de usuario?

Como HTTP no tiene estado, cada conexión no tiene nada que ver con la conexión anterior. Para resolver el problema de identificar al mismo usuario en varias páginas web, existen dos soluciones:

• Al usar cookies, el almacenamiento basado en cookies está del lado del cliente. Solo necesita traer la cookie cada vez que envía una solicitud HTTP para guardar el estado del usuario,
• Con Session, el guardado basado en Session está en el lado del servidor. Cuando la sesión comienza, el servidor guardará la sesión y luego asignará una ID de sesión al cliente. Generalmente, la ID de sesión se guarda en la Cookie, y cada vez El navegador envía una solicitud Traerá el Sessionid en la Cookie al servidor, y el servidor puede leer el estado del usuario previamente guardado en el servidor a través del identificador de sesión, realizando así la preservación de la sesión. Un escenario de aplicación típico es un carrito de compras. el usuario necesita agregar productos a los carritos de compras, el servidor no puede identificar qué usuario es, pero puede identificar al usuario si el Sessionid está disponible.

La ventaja de la solución basada en sesión es que la seguridad es relativamente alta, pero también trae la presión del servidor. Bajo la arquitectura de microservicio distribuido, la solicitud debe pasar a través del Nginx (balanceador de carga) para llegar al servidor, pero Llegan múltiples solicitudes a diferentes niveles Un servidor, para resolver el problema del mismo SessionId, puede guardar la Sesión en el middleware de caché en Redis, y también se puede colocar en la base de datos, pero la eficiencia de la base de datos es menor.

¿Qué pasa si el cliente deshabilita las cookies? Puede poner SessionId en la URL de solicitud

1.6 ¿Cookie? ¿Sesión?

De hecho, ya hemos mencionado algunas de las funciones y diferencias de las cookies y las sesiones, así que profundicemos y comprendamos nuevamente:

• Las cookies se utilizan generalmente para guardar información del usuario, por ejemplo, hemos iniciado sesión correctamente en csdn y la próxima vez que visitemos la página, las cookies pueden ayudar a los usuarios a completar automáticamente cierta información de inicio de sesión.
• La función principal de Session es registrar el estado del usuario a través del servidor. El ejemplo más típico es el ejemplo del carrito de compras anterior.

La cookie se almacena en el lado del cliente y la sesión existe en el lado del servidor. En términos relativos, la sesión es más segura. Si hay información confidencial, se puede cifrar en el lado del cliente mediante cifrado asimétrico y luego descifrar en el servidor lado.

1.7 HTTP1.0? HTTP1.1?

HTTP1.0 se usó por primera vez en 1996, y HTTP1.1 solo se usó ampliamente en las páginas web de los navegadores en 1999. Se puede ver que HTTP1.1 ha pasado la prueba de tantos años y se ha vuelto bastante maduro. Ya hemos mencionado algunas diferencias entre HTTP1.0 y HTTP1.1. Hablemos de ello en detalle a continuación:

• 缓存处理:En HTTP1.0, el If-Modified-Since en el encabezado de la solicitud se usó principalmente como criterio para el juicio de almacenamiento en caché, y HTTP1.1 introdujo más estrategias de control de almacenamiento en caché.
• 带宽优化和网络连接的使用: En HTTP1.0, hay un fenómeno de pérdida de ancho de banda y no admite la función de transmisión reanudable. HTTP1.1 agrega un campo de encabezado de rango en el encabezado de solicitud, y la operación solo solicita una parte del recurso, y el el código de retorno es 206
• 错误通知处理:Se agregaron 24 códigos de respuesta de estado de error en HTTP1.1
• Host头处理:En HTTP1.0, se cree que cada servidor solo se puede vincular a una dirección IP, por lo que el encabezado de solicitud del Host no se incluye en la URL de la solicitud, pero con el desarrollo de la tecnología virtual, una computadora puede tener múltiples enlaces de host virtual Múltiples direcciones IP, por lo que debe traer una información de host en el encabezado de solicitud HTTP1.1 (encabezado de respuesta); de lo contrario, se informará un error 400
• 长链接:HTTP1.0 usa conexiones cortas por defecto, mientras que HTTP1.1 usa enlaces largos por defecto

Dos, HTTPS

HTTP tiene las siguientes desventajas:

• La comunicación es en texto plano y el contenido puede ser capturado por una herramienta de captura de paquetes, lo que conduce a la escucha clandestina del contenido.
• No se puede verificar la identidad del interlocutor y es posible que esté disfrazado.
• No se puede verificar la integridad del mensaje.

Para resolver los problemas anteriores, ha surgido el protocolo seguro HTTPS. El protocolo HTTPS es en realidad el protocolo HTTP con un shell SSL. Es decir, el cliente y el servidor están primero encriptados por SSL y tienen la función de protección de SSL. . HTTP se convierte en HTTPS, que puede resolver la comunicación en texto sin formato, verificar la identidad y garantizar la integridad.

2.1 Cifrado simétrico y cifrado asimétrico

Antes de hablar sobre HTTPS, primero comprendamos el cifrado simétrico y el cifrado asimétrico en la criptografía.

• Cifrado simétrico: tanto el cifrado como el descifrado utilizan una clave, no
• La clave no se puede descifrar, lo que significa que siempre que se obtenga la clave, se puede descifrar
• Cifrado asimétrico: el cifrado y el descifrado utilizan claves diferentes, el remitente utiliza la clave pública para el cifrado y el receptor utiliza la clave para el cifrado

Cuando se utiliza encriptación simétrica, si el atacante obtiene la clave, entonces la encriptación no tiene significado. Si la clave es obtenida por el receptor y el remitente, también debe ser transmitida. En teoría, la transmisión de datos no es segura. La clave también es insegura, por lo que solo usar cifrado simétrico tampoco es confiable;

El cifrado asimétrico requiere el uso de una clave pública para el cifrado y una clave privada para el descifrado, que consume muchos recursos y la velocidad de procesamiento es muy lenta;

Por lo tanto, se adopta un método de compromiso en HTTPS SSL. Cuando se establece la conexión por primera vez, se usa encriptación asimétrica para transmitir la clave común de ambas partes, y la próxima vez, se puede usar encriptación simétrica para la transmisión, lo que garantiza tanto La seguridad también garantiza la eficiencia

2.2 Certificado

Usar cifrado asimétrico y cifrado simétrico para resolver el problema del uso de texto plano en la comunicación, pero desafortunadamente no resolvió el problema de verificar las identidades de las dos partes en la comunicación. Para resolver el problema anterior, puede adoptar la publicidad emitida por la autoridad de certificación digital y otras agencias relacionadas. Certificado clave, la autoridad de certificación del certificado digital es una organización de terceros en la que confían tanto el cliente como el servidor.

Primero, el operador del servidor solicita un certificado a una autoridad de certificación digital autorizada. Después de que el servidor recibe el certificado, coloca la clave pública en el certificado, y luego el servidor envía el certificado al cliente, y el cliente comienza a determinar el certificado. Una vez pasada la verificación, se puede verificar la identidad del servidor. El método general del navegador es implantar la clave pública de la autoridad de certificación de uso común en el interior.

2.3 HTTP? HTTPS

Resuma la diferencia entre HTTP y HTTPS:

• 端口:HTTP usa el puerto 80 de forma predeterminada, mientras que HTTPS usa el puerto 443 de manera predeterminada
• 安全性和资源消耗:HTTP se basa en TCP, todas las transmisiones son en texto sin formato y no se puede verificar la identidad de ambas partes. HTTPS es un protocolo HTTP basado en SSL / TLS. Todo el contenido de la transmisión está cifrado y el método de cifrado es simétrico. Cifrado y cifrado asimétrico HTTPS es más seguro que HTTP pero consume más recursos. Por lo tanto, los servicios con una seguridad sólida generalmente deben usar HTTPS; de lo contrario, HTTP todavía se usa.