Explicación popular: https://blog.csdn.net/mi2shao/article/details/99707415?depth_1-utm_source=distribute.pc_relevant.none-task-blog-OPENSEARCH-1&utm_source=distribute.pc_relevant.none-task-blog-OPENSEARCH -1
1. Solicitud HTTP y pasos de respuesta
Lo anterior muestra completamente los 7 pasos de la solicitud y respuesta HTTP. Comprendamos cómo se transmiten la solicitud y la respuesta HTTP desde la perspectiva del modelo de protocolo TCP / IP.
2. Protocolo TCP / IP
El modelo de protocolo TCP / IP (Protocolo de control de transmisión / Protocolo de Internet) contiene una serie de protocolos de red que forman la base de Internet. Es el protocolo central de Internet y se usa ampliamente en redes de área amplia y redes de área local.
El protocolo HTTP se basa en el modelo de protocolo TCP / IP para transmitir información.
(1) Capa de enlace
También conocida como capa de enlace de datos o capa de interfaz de red (la capa de interfaz de red y la capa de hardware en la primera figura), generalmente incluye el controlador del dispositivo en el sistema operativo y la tarjeta de interfaz de red correspondiente en la computadora. Juntos manejan los detalles de la interfaz física con el cable (o cualquier otro medio de transmisión). ARP (Protocolo de resolución de dirección) y RARP (Protocolo de resolución de dirección inversa) son protocolos especiales utilizados por algunas interfaces de red (como Ethernet y Token Ring) para convertir las direcciones utilizadas por la capa IP y la capa de interfaz de red.
(2). Capa de red
También conocida como la capa de Internet (la capa de Internet en el primer diagrama), maneja las actividades de los paquetes en la red, como el enrutamiento de paquetes. En la familia de protocolos TCP / IP, los protocolos de capa de red incluyen el protocolo IP (Protocolo de Internet), el protocolo ICMP (Protocolo de mensajes de control de Internet de Internet) y el protocolo IGMP (Protocolo de administración de grupos de Internet).
IP es un protocolo de capa de red que proporciona un servicio poco confiable. Simplemente envía paquetes desde el nodo de origen al nodo de destino lo más rápido posible, pero no proporciona ninguna garantía de confiabilidad. Usado por TCP y UDP. Cada conjunto de datos para TCP y UDP se transmite a través de Internet a través del sistema final y la capa IP en cada enrutador intermedio.
ICMP es un protocolo subsidiario del protocolo IP. La capa IP lo utiliza para intercambiar mensajes de error y otra información importante con otros hosts o enrutadores.
IGMP es un protocolo de gestión de grupos de Internet. Se utiliza para multidifundir un datagrama UDP a múltiples hosts.
(3). Capa de transporte
Principalmente proporciona comunicación de extremo a extremo para aplicaciones en dos hosts. En la familia de protocolos TCP / IP, hay dos protocolos de transmisión diferentes: TCP (Protocolo de control de transmisión) y UDP (Protocolo de datagramas de usuario).
TCP proporciona comunicación de datos de alta confiabilidad para dos hosts. El trabajo que realiza incluye dividir los datos que le entrega la aplicación en pequeños bloques adecuados y entregarlos a la capa de red subyacente, confirmar los paquetes recibidos, configurar el reloj de tiempo de espera para enviar el último paquete de confirmación, etc. Dado que la capa de transporte proporciona una comunicación de extremo a extremo altamente confiable, la capa de aplicación puede ignorar todos estos detalles. Para proporcionar servicios confiables, TCP utiliza mecanismos como la retransmisión de tiempo de espera, el envío y la recepción de paquetes de reconocimiento de extremo a extremo.
UDP proporciona un servicio muy simple para la capa de aplicación. Simplemente envía paquetes llamados datagramas de un host a otro, pero no garantiza que el datagrama pueda llegar al otro extremo. Un datagrama se refiere a una unidad de información transmitida desde el emisor al receptor (por ejemplo, un cierto número de bytes de información especificada por el emisor). La capa de aplicación debe proporcionar toda la confiabilidad necesaria del protocolo UDP.
(4). Capa de aplicación
La capa de aplicación determina las actividades de comunicación al proporcionar servicios de aplicación a los usuarios. Varios servicios de aplicaciones generales se almacenan previamente en la familia de protocolos TCP / IP. Incluidos los servicios HTTP, FTP (Protocolo de transferencia de archivos, protocolo de transferencia de archivos), DNS (Sistema de nombres de dominio, sistema de nombres de dominio).
Cuando una aplicación usa TCP para transferir datos, los datos se envían a la pila de protocolos y luego pasan a través de cada capa uno por uno hasta que se envían a la red como una cadena de flujos de bits. Cada capa debe agregar cierta información de encabezado (a veces agregar información de cola) a los datos recibidos. El proceso se muestra en la figura.
Cuando el host de destino recibe una trama de datos Ethernet, los datos comienzan a elevarse desde la parte inferior de la pila de protocolos y, al mismo tiempo, eliminan el encabezado del mensaje agregado por cada capa de protocolo. Cada casilla de protocolo debe verificar el identificador de protocolo en el encabezado del paquete para determinar el protocolo superior de los datos recibidos. Este proceso se llama demultiplexación. El protocolo se desempaqueta por número de puerto de destino, dirección IP de origen y número de puerto de origen.
A través de los pasos anteriores, entendemos el proceso de una solicitud y respuesta HTTP desde la perspectiva del modelo TCP / IP.
La siguiente imagen es más clara:
Tres, protocolo de enlace de tres vías TCP
TCP está orientado a la conexión. Antes de enviar datos a la otra parte, se debe establecer una conexión entre las dos partes. En el protocolo TCP / IP, el protocolo TCP proporciona un servicio de conexión confiable y la conexión se inicializa mediante un protocolo de enlace de tres vías. El propósito del protocolo de enlace de tres vías es sincronizar el número de serie y el número de reconocimiento de ambos lados de la conexión e intercambiar información del tamaño de la ventana TCP.
El primer apretón de manos: establecer una conexión. El cliente envía el segmento de solicitud de conexión, configurando la posición SYN en 1 y el Número de secuencia en x; luego, el cliente ingresa al estado SYN_SEND y espera la confirmación del servidor;
Segundo apretón de manos: el servidor recibe el segmento SYN. El servidor recibe el segmento de mensaje SYN del cliente y necesita confirmar este segmento de mensaje SYN, establecer el Número de acuse de recibo en x + 1 (Número de secuencia + 1); al mismo tiempo, también debe enviar su propia información de solicitud SYN y establecer la posición SYN en 1. , Número de secuencia es y; el servidor coloca toda la información anterior en un segmento de mensaje (es decir, segmento de mensaje SYN + ACK) y lo envía al cliente juntos, en este momento el servidor ingresa al estado SYN_RECV;
El tercer apretón de manos: el cliente recibe el segmento SYN + ACK del servidor. Luego establezca el Número de acuse de recibo en y + 1 y envíe un segmento ACK al servidor.Después de que se envíe el segmento, tanto el cliente como el servidor ingresan al estado ESTABLECIDO, completando los tres protocolos de enlace TCP.
¿Por qué deberíamos estrecharnos la mano tres veces?
Para evitar que el segmento de solicitud de conexión no válida se envíe repentinamente al servidor, se genera un error.
Ejemplo específico: la generación del "segmento de solicitud de conexión fallida" ocurre en tal situación: el primer segmento de solicitud de conexión enviado por el cliente no se pierde, pero permanece durante mucho tiempo en un nodo de red , Para que el retraso no llegue al servidor hasta un tiempo después de que se libere la conexión. Originalmente, este era un segmento que había expirado hace mucho tiempo. Sin embargo, después de recibir este segmento de solicitud de conexión no válida, el servidor cree erróneamente que es una nueva solicitud de conexión enviada nuevamente por el cliente. Por lo tanto, envía un segmento de confirmación al cliente y acepta establecer una conexión. Suponiendo que no se utiliza el "protocolo de enlace de tres vías", tan pronto como el servidor envía un acuse de recibo, se establece una nueva conexión. Como el cliente no ha emitido una solicitud para establecer una conexión, no ignorará la confirmación del servidor ni enviará datos al servidor. Sin embargo, el servidor pensó que se había establecido una nueva conexión de transporte y había estado esperando los datos del cliente. De esta forma, se desperdician muchos recursos del servidor. El método de "apretón de manos de tres vías" puede prevenir el fenómeno anterior. Por ejemplo, en el caso justo ahora, el cliente no enviará confirmación a la confirmación del servidor. Como el servidor no puede recibir la confirmación, sabe que el cliente no ha solicitado establecer una conexión. "
¿Qué es el HTTP?
En términos simples, es la regla que las computadoras se comunican a través de la red. Es un protocolo de capa de aplicación sin estado basado en solicitudes y respuestas. A menudo se basa en el protocolo TCP / IP para transmitir datos. En la actualidad, cualquier tipo de comunicación entre cualquier terminal (teléfono móvil, computadora portátil ...) debe realizarse de acuerdo con el protocolo Http, de lo contrario no se puede conectar.
Los cuatro se basan en:
Solicitud y respuesta: el cliente envía una solicitud y el servidor responde con datos
Sin estado: el protocolo no tiene memoria para el procesamiento de transacciones. Cuando el cliente establece por primera vez una conexión con el servidor y envía una solicitud, se requiere una serie de coincidencias de autenticación de seguridad. Por lo tanto, el tiempo de espera de la página aumenta. Una vez completada la respuesta final, los dos se desconectan y el estado de la conexión no se guarda. ¡Implacable! De ahora en adelante los transeúntes! La próxima vez que el cliente envíe una solicitud al mismo servidor, ya que se han olvidado antes, deben restablecer la conexión.
Capa de aplicación: Http es un protocolo que pertenece a la capa de aplicación, utilizado con TCP / IP.
TCP / IP: Http usa TCP como su protocolo de transporte de soporte. El cliente HTTP inicia una conexión TCP con el servidor. Una vez que se establece la conexión, el navegador (cliente) y el proceso del servidor pueden acceder a TCP a través de la interfaz de socket.
Algunas soluciones a la apatridia:
A veces es necesario guardar el estado de comunicación HTTP anterior del usuario, como realizar una operación de inicio de sesión, y no es necesario que todas las solicitudes vuelvan a iniciar sesión en 30 minutos. Entonces se introdujo la tecnología de cookies.
HTTP / 1.1 ideó un método de HTTP keep-alive. Su característica es que mientras no se proponga explícitamente una conexión en ninguno de los extremos, se mantiene el estado de la conexión TCP. Conexión: mantener vivo en el campo de encabezado de solicitud indica que se utiliza una conexión persistente.
Hay muchos mas . . . . .
Lo siguiente comienza a explicar los aspectos más destacados: mensaje de solicitud HTTP, mensaje de respuesta, correspondiente a los pasos anteriores 2, 3, 4, 5, 6.
Los mensajes HTTP están orientados al texto. Cada campo en el mensaje es una cadena de código ASCII, y la longitud de cada campo es incierta. Hay dos tipos de mensajes HTTP: mensajes de solicitud y mensajes de respuesta.
Cinco, mensaje de solicitud HTTP
Un mensaje de solicitud HTTP consta de una línea de solicitud, un encabezado de solicitud, una línea en blanco y datos de solicitud. La siguiente figura muestra el formato general del mensaje de solicitud.
1. Línea de solicitud
La línea de solicitud se divide en tres partes: método de solicitud, dirección de solicitud y versión del protocolo.
Método de solicitud
Hay 8 tipos de métodos de solicitud definidos por HTTP / 1.1: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, TRACE.
Los dos tipos más comunes de GET y POST, si es una interfaz RESTful, generalmente usan GET, POST, DELETE, PUT.
Dirección de solicitud
URL: Uniform Resource Locator, es un método de identificación único abstracto de ubicación voluntaria.
Composición: <protocolo>: // <host>: <port> / <path>
El puerto y la ruta a veces se pueden omitir (el número de puerto predeterminado de HTTP es 80)
El siguiente ejemplo:
A veces con parámetros, solicitud GET
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, comúnmente utilizado son HTTP / 1.0 y HTTP / 1.1
2. Solicitar encabezado
El encabezado de solicitud agrega información adicional al mensaje de solicitud, que consiste en pares de "nombre / valor", un par por línea, con dos puntos que separan el nombre y el valor.
Los encabezados de solicitud comunes son los siguientes:
Habrá una línea en blanco al final del encabezado de la solicitud, que indica el final del encabezado de la solicitud, seguido de los datos de la solicitud, esta línea es muy importante e indispensable.
3. Solicitar datos
Parte opcional, como solicitud GET, no hay datos de solicitud.
El siguiente es un mensaje de solicitud de método POST:
POST /index.php Línea de solicitud HTTP / 1.1
Anfitrión: localhost
User-Agent: Mozilla / 5.0 (Windows NT 5.1; rv: 10.0.2) Gecko / 20100101 Firefox / 10.0.2 encabezado de solicitud
Aceptar: text / html, application / xhtml + xml, application / xml; q = 0.9, / ; q = 0.8
Idioma de aceptación: zh-cn, zh; q = 0.5
Aceptar-codificación: gzip, desinflar
Conexión: mantener vivo
Referer: http: // localhost /
Longitud del contenido: 25
Tipo de contenido: application / x-www-form-urlencoded
Línea en blanco
username = aa & password = 1234 datos de solicitud
Seis, mensaje de respuesta HTTP
El mensaje de respuesta HTTP consiste principalmente en línea de estado, encabezado de respuesta, línea en blanco y datos de respuesta.
1. Línea de estado
Consta de 3 partes, a saber: versión del protocolo, código de estado y descripción del código de estado.
La versión del protocolo es coherente con el mensaje de solicitud, y la descripción del código de estado es una descripción simple del código de estado, por lo que aquí solo se introduce el código de estado.
Código de estado
El código de estado es de 3 dígitos.
1xx: Mensaje de indicación: indica que la solicitud se ha recibido y el procesamiento continúa.
2xx: Correcto: indica que la solicitud se recibió, entendió y aceptó con éxito.
3xx: Redirección: se requieren operaciones adicionales para completar la solicitud.
4xx: Error del cliente: la solicitud tiene un error de sintaxis o la solicitud no se puede cumplir.
5xx: Error del lado del servidor: el servidor no pudo cumplir una solicitud legítima.
Aquí hay algunos comunes:
2. Encabezado de respuesta
Similar al encabezado de la solicitud, se agrega información adicional al mensaje de respuesta
Los encabezados de respuesta comunes son los siguientes:
3. Datos de respuesta
Se utiliza para almacenar información de datos que debe devolverse al cliente.
El siguiente es un ejemplo de un mensaje de respuesta:
HTTP / 1.1 200 OK línea de estado
Fecha: dom, 17 de marzo de 2013 08:12:54 GMT encabezado de respuesta
Servidor: Apache / 2.2.8 (Win32) PHP / 5.2.5
Desarrollado por X: PHP / 5.2.5
Set-Cookie: PHPSESSID = c0huq7pdkmm5gg6osoe3mgjmm3; ruta = /
Expira: jue, 19 nov 1981 08:52:00 GMT
Control de caché: no-store, no-cache, must-revalidate, post-check = 0, pre-check = 0
Pragma: sin caché
Longitud del contenido: 4393
Keep-Alive: tiempo de espera = 5, max = 100
Conexión: Keep-Alive
Tipo de contenido: texto / html; charset = utf-8
Línea en blanco
Datos de respuesta
Ejemplo de respuesta HTTP <título>
Hola HTTP!
Hay muchos puntos de conocimiento sobre encabezados de solicitud y encabezados de respuesta, por lo que aquí hay una breve introducción.
A través de los pasos anteriores, los datos se han transferido y HTTP / 1.1 mantendrá una conexión persistente, pero siempre habrá un momento para cerrar la conexión por un período de tiempo. En este momento, la conexión TCP se desconecta según sea necesario.
Después de que el cliente y el servidor establecen una conexión TCP a través del protocolo de enlace de tres vías, cuando se completa la transferencia de datos, la conexión TCP debe desconectarse. Para la desconexión de TCP, hay un misterioso "cuatro rupturas".
El primer desglose: Host 1 (puede ser un cliente o un servidor), establezca el Número de secuencia y envíe un segmento FIN al Host 2; en este momento, el Host 1 ingresa al estado FIN_WAIT_1; esto significa que el Host 1 no tiene datos Enviado al host 2;
Segunda ruptura: el host 2 recibe el segmento FIN enviado por el host 1, devuelve un segmento ACK al host 1, el número de reconocimiento es el número de secuencia más 1; el host 1 ingresa al estado FIN_WAIT_2; el host 2 le dice al host 1, soy " Acepto "su solicitud de cierre;
La tercera ruptura: el Host 2 envía un segmento FIN al Host 1, solicitando cerrar la conexión, y al mismo tiempo el Host 2 ingresa al estado LAST_ACK;
La cuarta ruptura: el host 1 recibe el segmento FIN enviado por el host 2 y envía un segmento ACK al host 2, luego el host 1 ingresa al estado TIME_WAIT; el host 2 cierra la conexión después de recibir el segmento ACK del host 1 ; En este momento, el host 1 no ha recibido una respuesta después de esperar 2MSL, demuestra que el servidor se ha apagado normalmente, luego, el host 1 también puede cerrar la conexión.
¿Por qué romper cuatro veces?
El protocolo TCP es un protocolo de comunicación de capa de transporte, confiable y orientado a la conexión basado en flujos de bytes. TCP es modo dúplex completo, lo que significa que cuando el Host 1 envía un segmento FIN, solo significa que el Host 1 no tiene datos para enviar. El Host 1 le dice al Host 2 que todos sus datos se han enviado; sin embargo, En este momento, el host 1 aún puede recibir datos del host 2; cuando el host 2 devuelve un segmento ACK, indica que ha sabido que el host 1 no tiene datos para enviar, pero el host 2 aún puede enviar datos al host 1; cuando el host 2 también Cuando se envía el segmento de mensaje FIN, esta vez significa que el host 2 no tiene datos para enviar, y le dirá al host 1 que no tengo datos para enviar, y luego interrumpirán felizmente la conexión TCP.
A través de los pasos anteriores, se completaron la solicitud y la respuesta HTTP, y se transfirieron los datos, entre ellos, los puntos de conocimiento involucrados se entendieron uno por uno.
Autor: Ruheng
Enlace: http://www.jianshu.com/p/c1d6a294d3c0
Fuente: Libro Breve
Los derechos de autor pertenecen al autor. Para reproducción comercial, por favor contacte al autor para autorización, y para reproducción no comercial, por favor indique la fuente.
