El protocolo HTTP (protocolo HTTP) generalmente se refiere a HTTP
El Protocolo de transferencia de hipertexto ( HTTP ) es un protocolo de solicitud-respuesta simple que generalmente se ejecuta sobre TCP . Especifica qué tipo de mensajes puede enviar el cliente al servidor y qué tipo de respuesta obtiene. Los encabezados de los mensajes de solicitud y respuesta se dan en formato ASCII ; [9] el contenido del mensaje tiene un formato similar a MIME . Este modelo simple fue responsable del éxito inicial de la Web porque hizo que el desarrollo y la implementación fueran muy sencillos.
| nombre chino | Protocolo de Transferencia de Hipertexto |
Base | Arquitectura en TCP |
| nombre extranjero | HTTP |
Navegadores aplicables | Firefox , Google Chrome |
| capa de trabajo | Capa de aplicación | función | Estipula las especificaciones de transferencia de información entre servidores WWW y navegadores, y es un acuerdo que cumplen ambas partes. |
Introducción
La World Wide Web (WWW) se originó en el CERN, un laboratorio de física cuántica en Ginebra , Europa . Fue la aparición de la tecnología WWW la que permitió que Internet se desarrollara a una velocidad inimaginable. Esta tecnología basada en TCP/IP se ha convertido rápidamente en el mayor sistema de información de Internet desarrollado durante décadas en tan sólo diez años. Su éxito se atribuye a su simplicidad y practicidad. Detrás de la WWW, hay una serie de protocolos y estándares que la respaldan en la realización de tan gran trabajo: este es el conjunto de protocolos web, que incluye el protocolo de transferencia de hipertexto HTTP.
En 1990, HTTP se convirtió en el protocolo de soporte de WWW. Fue propuesto por su fundador Tim Berners -Lee, el padre de WWW, y luego se estableció el Consorcio WWW y organizó el grupo IETF (Internet Engineering Task Force) para mejorar y lanzar HTTP aún más.
HTTP es un protocolo de capa de aplicación . Al igual que otros protocolos de capa de aplicación, es un protocolo para implementar un determinado tipo de aplicación específica y sus funciones las implementa una aplicación que se ejecuta en el espacio del usuario . HTTP es una especificación de protocolo, esta especificación está registrada en el documento y es el programa de implementación de HTTP que realmente se comunica a través de HTTP.
HTTP se comunica según la arquitectura B/S , y los programas de implementación del lado del servidor de HTTP incluyen httpd , nginx , etc., y sus programas de implementación del lado del cliente son principalmente navegadores web , como Firefox , Internet Explorer , Google Chrome , Safari , Opera , etc., además, las herramientas de línea de comandos del cliente también incluyen elink, curl , etc. Los servicios web se basan en TCP, por lo que para responder a las solicitudes de los clientes en cualquier momento, el servidor web necesita escuchar en el puerto 80/TCP. De esta forma, el navegador del cliente y el servidor web pueden comunicarse a través de HTTP.
etapa de desarrollo
0,9
El protocolo 0.9 es un protocolo simple y rápido adecuado para diversa información de datos, pero está lejos de satisfacer las necesidades de diversas aplicaciones en constante desarrollo. El protocolo 0.9 es un protocolo desordenado para intercambiar información, limitado a texto. Dado que el contenido no se puede negociar, el apretón de manos y el acuerdo entre las dos partes no estipulan el contenido de las dos partes, es decir, las imágenes no se pueden mostrar ni procesar.
1.0
En la etapa del protocolo 1.0, es decir, en 1982, Tim Berners-Lee propuso HTTP/1.0. En el posterior enriquecimiento y desarrollo, HTTP/1.0 se ha convertido en el protocolo de capa de aplicación orientado a transacciones más importante . Este protocolo establece y deshace una conexión para cada solicitud/respuesta. Se caracteriza por su simplicidad y facilidad de manejo, por lo que satisface las necesidades de todos y ha sido ampliamente utilizado.
1.1
En el protocolo 1.0, ambas partes estipularon el método y el tipo de conexión, lo que ha ampliado enormemente el campo de HTTP, pero no se tiene en cuenta la velocidad y la eficiencia más importantes de Internet. Después de todo, como autor del protocolo, no esperaba que HTTP se volviera tan popular en ese momento.
Para conocer el contenido específico del protocolo HTTP1.1 , consulte RFC 2616.
2.0
Los predecesores de HTTP2.0 son HTTP1.0 y HTTP1.1. Aunque antes solo había dos versiones, las especificaciones de protocolo contenidas en estas dos versiones son lo suficientemente grandes como para causar dolor de cabeza a cualquier ingeniero experimentado. Las nuevas versiones de protocolos de red no reemplazan inmediatamente a las versiones anteriores. De hecho, 1.0 y 1.1 han coexistido durante mucho tiempo, lo que se debe a la lenta actualización de la infraestructura de red .
Para conocer el contenido específico del protocolo HTTP2.0, consulte RFC 7540.
Escenarios de aplicación
Cuando nació HTTP, se utilizaba principalmente para obtener contenido en el lado WEB, en ese momento el contenido no era tan rico como lo es ahora, el diseño no era tan exquisito y casi no había escenarios de interacción del usuario. Para este sencillo escenario de obtención de contenido web, HTTP funciona razonablemente bien. Pero con el desarrollo de Internet y el nacimiento de WEB2.0, comenzó a mostrarse más contenido (más archivos de imagen), el diseño se volvió más hermoso (más CSS ) y se introdujeron interacciones más complejas (más JS ) . La cantidad total de datos cargados y el número de solicitudes cuando un usuario abre la página de inicio de un sitio web también están aumentando.
Hoy en día, el tamaño de la página de inicio de la mayoría de los sitios web de portales supera los 2 millones y el número de solicitudes puede llegar a 100. Otra aplicación muy extendida son las aplicaciones cliente de Internet móvil , donde el uso de HTTP por parte de aplicaciones de diferente naturaleza varía mucho. Para aplicaciones de comercio electrónico, puede haber más de 10 solicitudes para cargar la página de inicio. Para mensajería instantánea como WeChat , las solicitudes HTTP pueden limitarse a la descarga de archivos de voz e imágenes, y la frecuencia de las solicitudes no es alta.
principio de funcionamiento
HTTP se basa en el modelo cliente/servidor y está orientado a la conexión. El procesamiento de transacciones HTTP típico tiene el siguiente proceso:
(1) El cliente establece una conexión con el servidor;
(2) El cliente realiza una solicitud al servidor;
(3) El servidor acepta la solicitud y devuelve el archivo correspondiente como respuesta de acuerdo con la solicitud;
(4) El cliente y el servidor cierran la conexión.
La conexión HTTP entre el cliente y el servidor es una conexión única, lo que limita cada conexión a procesar solo una solicitud. Cuando el servidor devuelve la respuesta a esta solicitud, inmediatamente cierra la conexión y la restablece para la siguiente. pedido. Esta conexión única tiene en cuenta principalmente que el servidor WWW se enfrenta a miles de usuarios en Internet y solo puede proporcionar un número limitado de conexiones, por lo que el servidor no dejará una conexión en estado de espera. La liberación oportuna de la conexión puede mejorar en gran medida la eficacia del rendimiento del servidor.
HTTP es un protocolo sin estado , es decir, el servidor no retiene ningún estado de sus transacciones con el cliente. Esto reduce en gran medida la carga de memoria en el servidor, manteniendo así una velocidad de respuesta más rápida . HTTP es un protocolo orientado a objetos. Permite la transferencia de objetos de datos de cualquier tipo . Identifica el contenido y el tamaño de los datos transmitidos a través del tipo y la longitud de los datos , y permite la transmisión comprimida de datos. Cuando el usuario define un enlace de hipertexto en un documento HTML , el navegador establecerá una conexión con el servidor especificado a través del protocolo TCP/IP .
HTTP admite conexiones persistentes y en HTTP/0.9 y 1.0 la conexión se cierra después de un único par de solicitud/respuesta. En HTTP/1.1, se introdujo un mecanismo de mantenimiento en el que una conexión se puede reutilizar para múltiples solicitudes. Una conexión tan persistente puede reducir significativamente la latencia de la solicitud porque el cliente no necesita renegociar la conexión TCP 3-Way-Handshake después de enviar la primera solicitud . Otro efecto secundario positivo es que, normalmente, las conexiones se vuelven más rápidas con el tiempo debido al mecanismo de inicio lento de TCP.
La versión 1.1 del protocolo también presenta mejoras de optimización del ancho de banda con respecto a HTTP/1.0. Por ejemplo, HTTP/1.1 introdujo codificación de transferencia fragmentada para permitir la transmisión en streaming en lugar de almacenar contenido en búfer en conexiones persistentes. La canalización HTTP reduce aún más la latencia , lo que permite a los clientes enviar múltiples solicitudes antes de esperar cada respuesta. Otra característica adicional del protocolo es el servicio de bytes, donde el servidor solo transmite la parte del recurso que el cliente solicitó explícitamente.
Técnicamente hablando, el cliente abre un socket en un puerto TCP específico ( el número de puerto suele ser 80) . Si el servidor ha estado escuchando conexiones en este puerto conocido, se establecerá la conexión. Luego, el cliente envía un bloque de solicitud que contiene el método de solicitud a través de la conexión.
La especificación HTTP define 9 métodos de solicitud. Cada método de solicitud especifica un método de intercambio de información diferente entre el cliente y el servidor. Los métodos de solicitud más utilizados son GET y POST. El servidor completará las operaciones correspondientes de acuerdo con la solicitud del cliente, se las devolverá al cliente en forma de bloque de respuesta y finalmente cerrará la conexión.
Modo de operación
En WWW, "cliente" y "servidor" son conceptos relativos que sólo existen durante una conexión específica, es decir, un cliente en una conexión puede actuar como servidor en otra conexión. El proceso de intercambio de información basado en el modelo cliente/servidor HTTP se divide en cuatro procesos: establecer una conexión, enviar información de solicitud, enviar información de respuesta y cerrar la conexión.
Figura 3 Una de las formas en que opera http
HTTP se basa en el paradigma de solicitud/respuesta. Después de que un cliente establece una conexión con el servidor, envía una solicitud al servidor. El formato de la solicitud es un identificador de recurso uniforme , un número de versión del protocolo, seguido de información MIME que incluye modificadores de solicitud , información del cliente y posible contenido. Después de recibir la solicitud, el servidor 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, un código de éxito o error, seguido de información MIME que incluye información del servidor, información de la entidad y posible contenido . De hecho, en pocas palabras, además de los archivos HTML , cualquier servidor también tiene un programa residente HTTP para responder a las solicitudes de los usuarios. Su navegador es un cliente HTTP y envía una solicitud al servidor. Cuando se ingresa un archivo de inicio en el navegador o se hace clic en un hipervínculo , el navegador envía una solicitud HTTP al servidor. Esta solicitud se envía a la dirección especificada por la IP dirección URL. El programa residente recibe la solicitud, realiza las operaciones necesarias y devuelve el archivo solicitado. En este proceso, los datos enviados y recibidos en la red se han dividido en uno o más paquetes de datos . Cada paquete de datos incluye: los datos a transmitir; información de control , que le dice a la red cómo procesar el paquete de datos. TCP/IP determina el formato de cada paquete de datos. Si no se lo dijeron de antemano, es posible que no sepa que la información se divide en muchos fragmentos pequeños para su transmisión y luego se vuelve a unir.
Muchas comunicaciones HTTP son iniciadas por un agente de usuario e incluyen una solicitud de recursos en el servidor de origen. El caso más simple probablemente se realiza a través de una única conexión entre el agente de usuario (UA) y el servidor de origen (O).
Las cosas se complican un poco más cuando uno o más intermediarios están presentes en la cadena de solicitud/respuesta. Hay tres tipos de intermediarios: Proxy, Gateway y Tunnel. Un proxy acepta solicitudes basadas en el formato absoluto del URI , reescribe todo o parte del mensaje y envía la solicitud formateada al servidor utilizando el identificador URI. Una puerta de enlace es un proxy receptor que actúa como una capa encima de algún otro servidor y, si es necesario, puede traducir solicitudes al protocolo del servidor subyacente. Un canal actúa como un punto de retransmisión entre dos conexiones que no cambian los mensajes. Los canales se utilizan a menudo cuando la comunicación necesita pasar a través de un intermediario (por ejemplo, firewall, etc.) o cuando el intermediario no puede identificar el contenido del mensaje.
Formato de mensaje
Los mensajes HTTP constan de solicitudes del cliente al servidor y respuestas del servidor al cliente. El formato del mensaje de solicitud es el siguiente: [6]
Línea de solicitud - Encabezado de información general - Encabezado de solicitud - Encabezado de entidad - Cuerpo del mensaje
La línea de solicitud comienza con el campo método, seguido por el campo URL y el campo versión del protocolo HTTP, y termina con CR LF . SP es el delimitador . Excepto que CF y LF son necesarios en la secuencia CRLF final, todo lo demás es opcional. Para obtener información específica sobre encabezados de información general, encabezados de solicitud y encabezados de entidad, consulte los documentos relevantes.
El formato del mensaje de respuesta es el siguiente:
Línea de estado - Encabezado de información general - Encabezado de respuesta - Encabezado de entidad - Cuerpo del mensaje
El elemento del código de estado consta de 3 dígitos e indica si se entiende o se cumple la solicitud. El análisis de causa es una breve descripción del código de estado del texto original. El código de estado se utiliza para admitir operaciones automáticas y el análisis de causa se utiliza para los usuarios. No es necesario utilizar el cliente para comprobar o mostrar la sintaxis. Para obtener información específica sobre encabezados de información general, encabezados de respuesta y encabezados de entidad, consulte los documentos relevantes.
mensaje de estado
| información |
describir |
|---|---|
| 100 Continuar |
El servidor recibe solo una parte de la solicitud, pero una vez que el servidor no rechaza la solicitud, el cliente debe continuar enviando el resto de la solicitud. |
| 101 protocolos de conmutación |
Protocolo de conversión del servidor: el servidor cumplirá con la solicitud del cliente y la convertirá a otro protocolo. |
| información |
describir |
|---|---|
| 200 bien |
Solicitud exitosa (seguida de los documentos de respuesta a las solicitudes GET y POST). |
| 201 creado |
Se crea la solicitud y se crea el nuevo recurso. |
| 202 Aceptado |
Se aceptó la solicitud de procesamiento, pero el procesamiento no se completó. |
| 203 Información no autorizada |
El documento se ha devuelto normalmente, pero algunos encabezados de respuesta pueden ser incorrectos porque se utilizó una copia del documento. |
| 204 Sin contenido |
No hay documentos nuevos. El navegador debería seguir mostrando el documento original. Este código de estado es útil si el usuario actualiza la página periódicamente y el servlet puede determinar que el documento del usuario está lo suficientemente actualizado. |
| 205 Restablecer contenido |
No hay documentos nuevos. Pero el navegador debería restablecer lo que muestra. Se utiliza para obligar al navegador a borrar el contenido de entrada del formulario. |
| 206 Contenido parcial |
El cliente envía una solicitud GET con un encabezado Range y el servidor la completa. |
| información |
describir |
|---|---|
| 300 opciones múltiples |
Múltiples opciones. Lista enlazada. Los usuarios pueden seleccionar un enlace para llegar a su destino. Se permiten un máximo de cinco direcciones. |
| 301 Movido Permanentemente |
La página solicitada se ha movido a la nueva URL. |
| 302 encontrado |
La página solicitada se ha movido temporalmente a la nueva URL. |
| 303 Ver Otros |
La página solicitada se puede encontrar en otra URL. |
| 304 No modificado |
El documento no fue modificado como se esperaba. El cliente tiene un documento almacenado en búfer y realiza una solicitud condicional (generalmente proporcionando un encabezado If-Modified-Since para indicar que el cliente solo quiere documentos que sean más recientes que la fecha especificada). El servidor le dice al cliente que el documento original almacenado en el búfer puede seguir utilizándose. |
| 305 Usar proxy |
Los documentos solicitados por el cliente deben recuperarse a través del servidor proxy especificado en el encabezado Ubicación. |
| 306 sin usar |
Este código se utilizó en una versión anterior. Ya no se utiliza, pero el código aún se conserva. |
| 307 Redirección Temporal |
La página solicitada se ha movido temporalmente a una nueva URL. |
| información |
describir |
|---|---|
| 400 Petición Incorrecta |
El servidor no entendió la solicitud. |
| 401 No autorizado |
La página solicitada requiere un nombre de usuario y contraseña. |
| 401.1 |
Error de inicio de sesion. |
| 401.2 |
La configuración del servidor provoca un error de inicio de sesión. |
| 401.3 |
No se obtiene la autorización debido a restricciones de recursos de ACL. |
| 401.4 |
Error en la autorización del filtro. |
| 401.5 |
Error en la autorización de la aplicación ISAPI/CGI. |
| 401.7 |
El acceso es denegado por la política de autorización de URL en el servidor web. Este código de error es específico de IIS 6.0. |
| 402 Pago requerido |
Este código aún no está disponible. |
| 403 Prohibido |
Está prohibido el acceso a la página solicitada. |
| 403.1 |
El acceso a la ejecución está prohibido. |
| 403.2 |
El acceso de lectura está prohibido. |
| 403.3 |
El acceso de escritura está prohibido. |
| 403.4 |
Se requiere SSL. |
| 403.5 |
Se requiere SSL 128. |
| 403.6 |
Dirección IP rechazada. |
| 403.7 |
Requiere certificado de cliente. |
| 403.8 |
Acceso al sitio denegado. |
| 403.9 |
Demasiados usuarios. |
| 403.10 |
Configuración no válida. |
| 403.11 |
Cambio de contraseña. |
| 403.12 |
Se deniega el acceso a la tabla de mapeo. |
| 403.13 |
El certificado de cliente fue revocado. |
| 403.14 |
Denegar listado de directorio. |
| 403.15 |
Se excedió el permiso de acceso del cliente. |
| 403.16 |
El certificado del cliente no es de confianza o no es válido. |
| 403.17 |
El certificado de cliente ha caducado o aún no es válido. |
| 403.18 |
La URL solicitada no se puede ejecutar en el grupo de aplicaciones actual. Este código de error es específico de IIS 6.0. |
| 403.19 |
No se puede realizar CGI para clientes en este grupo de aplicaciones. Este código de error es específico de IIS 6.0. |
| 403.20 |
Error al iniciar sesión con el pasaporte. Este código de error es específico de IIS 6.0. |
| 404 No encontrado |
El servidor no puede encontrar la página solicitada. |
| 404.0 |
(Ninguno): no se encontró ningún archivo o directorio. |
| 404.1 |
No se puede acceder al sitio web en el puerto solicitado. |
| 404.2 |
La política de bloqueo de extensiones de servicios web bloquea esta solicitud. |
| 404.3 |
La política de mapeo MIME bloquea esta solicitud. |
| Método 405 no permitido |
El método especificado en la solicitud no está permitido. |
| 406 No Aceptable |
La respuesta generada por el servidor fue inaceptable para el cliente. |
| Se requiere autenticación de proxy 407 |
用户必须首先使用代理服务器进行验证，这样请求才会被处理。 |
| 408 Request Timeout |
请求超出了服务器的等待时间。 |
| 409 Conflict |
由于冲突，请求无法被完成。 |
| 410 Gone |
被请求的页面不可用。 |
| 411 Length Required |
"Content-Length"未被定义。如果无此内容，服务器不会接受请求。 |
| 412 Precondition Failed |
请求中的前提条件被服务器评估为失败。 |
| 413 Request Entity Too Large |
由于所请求的实体的太大，服务器不会接受请求。 |
| 414 Request-url Too Long |
由于url太长，服务器不会接受请求。当post请求被转换为带有很长的查询信息的get请求时，就会发生这种情况。 |
| 415 Unsupported Media Type |
由于媒介类型不被支持，服务器不会接受请求。 |
| 416 Requested Range Not Satisfiable |
服务器不能满足客户在请求中指定的Range头。 |
| 417 Expectation Failed |
执行失败。 |
| 423 |
锁定的错误。 |
| 消息 |
描述 |
|---|---|
| 500 Internal Server Error |
请求未完成。服务器遇到不可预知的情况。 |
| 500.12 |
应用程序正忙于在Web服务器上重新启动。 |
| 500.13 |
Web服务器太忙。 |
| 500.15 |
不允许直接请求Global.asa。 |
| 500.16 |
UNC授权凭据不正确。这个错误代码为IIS 6.0所专用。 |
| 500.18 |
URL授权存储不能打开。这个错误代码为IIS 6.0所专用。 |
| 500.100 |
内部ASP错误。 |
| 501 Not Implemented |
请求未完成。服务器不支持所请求的功能。 |
| 502 Bad Gateway |
请求未完成。服务器从上游服务器收到一个无效的响应。 |
| 502.1 |
CGI应用程序超时。 |
| 502.2 |
CGI应用程序出错。 |
| 503 Service Unavailable |
请求未完成。服务器临时过载或宕机。 |
| 504 Tiempo de espera de puerta de enlace |
Tiempo de espera de la puerta de enlace. |
| Versión HTTP 505 no compatible |
El servidor no admite la versión HTTP especificada en la solicitud. |
número de versión
Los mensajes de solicitud y respuesta HTTP incluyen números de versión HTTP y existe cierta confusión sobre el uso y la interpretación correctos de los números de versión HTTP y sobre la interoperabilidad de las implementaciones HTTP de diferentes conversiones de protocolo . El uso y la interpretación de los números de versión HTTP se pueden encontrar en RFC 2145.