Sobre el protocolo HTTP

Introducción a HTTP

El protocolo HTTP es una abreviatura del Protocolo de transferencia de hipertexto (Protocolo de transferencia de hipertexto) y es un protocolo de transferencia utilizado para transferir hipertexto de un servidor de la World Wide Web (WWW: World Wide Web) a un navegador local.

HTTP es un protocolo de comunicación TCP / IP para transferir datos (archivos HTML, archivos de imagen, resultados de consultas, etc.).

HTTP es un protocolo orientado a objetos que pertenece a la capa de aplicación. Debido a su método simple y rápido, es adecuado para sistemas de información hipermedia distribuidos. Fue propuesto en 1990. Después de varios años de uso y desarrollo, se ha mejorado y ampliado continuamente. La sexta edición de HTTP / 1.0 se usa actualmente en WWW. La estandarización de HTTP / 1.1 está en progreso, y se ha presentado la propuesta de HTTP-NG (Next Generation of HTTP).

El protocolo HTTP funciona en la arquitectura cliente-servidor. Como cliente HTTP, el navegador envía todas las solicitudes al servidor HTTP, es decir, el servidor WEB, a través de la URL. Después de recibir la solicitud, el servidor web envía un mensaje de respuesta al cliente.


http request-response model.jpg

Características principales

1. Simple y rápido: cuando un cliente solicita un servicio de un servidor, solo se debe transmitir el método de solicitud y la ruta. Los métodos de solicitud comunes incluyen GET, HEAD y POST. Cada método especifica un tipo diferente de contacto cliente-servidor. Debido a que el protocolo HTTP es simple, el tamaño del programa del servidor HTTP es pequeño, por lo que la velocidad de comunicación es rápida.

2. Flexible: HTTP permite la transmisión de cualquier tipo de objeto de datos. El tipo que se transmite está marcado por Content-Type.

3. Sin conexión: el significado de sin conexión es limitar el procesamiento de una sola solicitud por conexión. Después de que el servidor procesa la solicitud del cliente y recibe la respuesta del cliente, se desconecta. El uso de este método puede ahorrar tiempo de transmisión.

4. Sin estado: el protocolo HTTP es un protocolo sin estado. Sin estado significa que el protocolo no tiene memoria para el procesamiento de transacciones. La falta de estado significa que si el procesamiento posterior requiere la información previa, debe ser retransmitida, lo que puede resultar en un aumento en la cantidad de datos transferidos por conexión. Por otro lado, cuando el servidor no necesita información previa, su respuesta es más rápida.
5. Soporta modos B / S y C / S.

HTTP 之 URL

HTTP utiliza identificadores uniformes de recursos (URI) para transmitir datos y establecer conexiones. Una URL es un tipo especial de URI que contiene suficiente información para encontrar un recurso

URL, el nombre completo es UniformResourceLocator, el nombre chino es el localizador uniforme de recursos, es la dirección utilizada para identificar un recurso en Internet. Tome la siguiente URL como ejemplo para presentar los componentes de una URL común:

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

Como se puede ver en la URL anterior, una URL completa incluye las siguientes partes:
1. Parte del protocolo: La parte del protocolo de la URL es "http:", lo que significa que la página web utiliza el protocolo HTTP. Se pueden usar varios protocolos en Internet, como HTTP, FTP, etc. En este ejemplo, se usa el protocolo HTTP. "//" después de "HTTP" es el separador

2. Parte del nombre de dominio: la parte del nombre de dominio de la URL es "www.aspxfans.com". En una URL, también puede usar la dirección IP como nombre de dominio

3. Parte del puerto: el puerto que sigue al nombre de dominio es el puerto. Use ":" como delimitador entre el nombre de dominio y el puerto. El puerto no es una parte necesaria de una URL, si omite la parte del puerto, se utilizará el puerto predeterminado

4. Parte del directorio virtual: desde la primera "/" después del nombre de dominio hasta la última "/", es la parte del directorio virtual. Los directorios virtuales no son una parte necesaria de una URL. El directorio virtual en este ejemplo es "/ news /"

5. Parte del nombre del archivo: desde la última "/" después del nombre de dominio hasta "?", Es la parte del nombre del archivo. Si no hay "?", Comienza desde la última "/" después del nombre de dominio hasta "#" , ¿Es la parte del archivo? Si no hay "?" Y "#", entonces, desde el último "/" después del nombre de dominio hasta el final, es la parte del nombre del archivo. El nombre del archivo en este ejemplo es "index.asp". La parte del nombre del archivo no es una parte obligatoria de una URL. Si se omite esta parte, se utiliza el nombre de archivo predeterminado.

6. Parte del ancla: desde "#" hasta el final, todas son partes del ancla. La parte de anclaje en este ejemplo es "nombre". La parte de ancla no es parte de una URL

7. Parte del parámetro: la parte de "?" A "#" es la parte del parámetro, también llamada parte de búsqueda y parte de consulta. La parte del parámetro en este ejemplo es "boardID = 5 & ID = 24618 & page = 1". Los parámetros pueden permitir múltiples parámetros y usar "&" como delimitador entre parámetros.

(Original: http://blog.csdn.net/ergouge/article/details/8185219  )

La diferencia entre URI y URL

URI es un identificador de recurso uniforme, un identificador de recurso uniforme que se utiliza para identificar un recurso de manera única.

Cada recurso disponible en la Web, como documentos HTML, imágenes, videoclips, programas, etc., es un URI para localizar. Un
URI generalmente se compone de tres partes:
① Mecanismo de denominación para acceder a los recursos
② Nombre del host para almacenar recursos
③ Nombre de los propios recursos , Representado por el camino, con énfasis en los recursos.

La URL es un localizador uniforme de recursos, un localizador uniforme de recursos. Es un URI específico, es decir, la URL se puede utilizar para identificar un recurso y también indica cómo ubicar el recurso.

La URL es una cadena de caracteres que se usa para describir los recursos de información en Internet, y se usa principalmente en varios programas de cliente WWW y programas de servidor, especialmente el famoso mosaico.
El uso de URL puede describir una variedad de recursos de información en un formato unificado, incluidos archivos, direcciones de servidores y directorios. La URL generalmente consta de tres partes:
①Protocolo (o llamado modo de servicio)
② Dirección IP de host (a veces también incluye el número de puerto) donde se almacena el recurso ③ Dirección específica del
recurso de host. Como el directorio y el nombre del archivo

URN, nombre de recurso uniforme, nombre de recurso uniforme, es identificar recursos por nombre, como mailto: [email protected].

URI es un concepto abstracto de alto nivel que define un identificador de recursos uniforme, mientras que URL y URN son identificadores de recursos específicos. Tanto la URL como la URN son un tipo de URI. En términos generales, cada URL es un URI, pero no todos los URI son una URL. Esto se debe a que el URI también incluye una subclase, Nombre uniforme de recurso (URN), que nombra el recurso pero no especifica cómo ubicarlo. El mailto, las noticias y los URI de isbn anteriores son ejemplos de URN.

En el URI de Java, una instancia de URI puede representar absoluta o relativa, siempre que se ajuste a las reglas gramaticales del URI. La clase de URL no solo se ajusta a la semántica, sino que también contiene información para ubicar el recurso, por lo que no puede ser relativo.
En la biblioteca de clases Java, la clase URI no contiene ningún método para acceder a los recursos, su único rol es analizar.
Por el contrario, la clase URL puede abrir una secuencia al recurso.

Mensaje de solicitud HTTP

El mensaje de solicitud de que el cliente envía una solicitud HTTP al servidor incluye el siguiente formato:

La línea de solicitud (línea de solicitud), el encabezado de solicitud (encabezado), la línea en blanco y los datos de solicitud se componen de cuatro partes.




Http request message structure.png
  • La línea de solicitud comienza con un símbolo de método, separado por un espacio, seguido del URI solicitado y la versión del protocolo.
Obtenga un ejemplo de solicitud, utilizando Charles para obtener la solicitud:
GET /562f25980001b1b106000338.jpg HTTP/1.1
Host    img.mukewang.com
User-Agent    Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 Accept image/webp,image/*,*/*;q=0.8 Referer http://www.imooc.com/ Accept-Encoding gzip, deflate, sdch Accept-Language zh-CN,zh;q=0.8
La primera parte: la línea de solicitud, utilizada para indicar el tipo de solicitud, el recurso al que se debe acceder y la versión HTTP utilizada.

GET indica que el tipo de solicitud es GET, [/562f25980001b1b106000338.jpg] es el recurso al que se debe acceder, y la última parte de la línea indica que se utiliza la versión HTTP 1.1.

La segunda parte: el encabezado de la solicitud, la parte inmediatamente posterior a la línea de solicitud (es decir, la primera línea) se utiliza para explicar la información adicional que utilizará el servidor

Desde la segunda línea está el encabezado de la solicitud, HOST indicará el destino de la solicitud. El Agente de usuario, el script del lado del servidor y del lado del cliente pueden acceder, es una base importante para la lógica de detección del tipo de navegador. Esta información la determina su navegador Para definir y enviar automáticamente cada solicitud, etc.

La tercera parte: línea en blanco, la línea en blanco después del encabezado de la solicitud es obligatoria

Incluso si los datos de la solicitud en la cuarta parte están vacíos, debe haber una línea en blanco.

Parte 4: Los datos de la solicitud también se denominan asunto, y se pueden agregar otros datos.

Los datos de solicitud para este ejemplo están vacíos.

Ejemplo de solicitud POST, usando Charles para tomar la solicitud:
POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) Content-Type:application/x-www-form-urlencoded Content-Length:40 Connection: Keep-Alive name=Professional%20Ajax&publisher=Wiley

La primera parte: la línea de solicitud, la primera línea es la solicitud posterior y la versión http1.1.
La segunda parte: encabezado de solicitud, la segunda línea a la sexta línea.
La tercera parte: línea en blanco, línea en blanco de la séptima línea.
Parte IV: Solicitud de datos, línea ocho.

Mensaje de respuesta HTTP Respuesta

En general, el servidor devolverá un mensaje de respuesta HTTP después de recibir y procesar la solicitud del cliente.

La respuesta HTTP también consta de cuatro partes, a saber: línea de estado, encabezado de mensaje, línea en blanco y cuerpo de respuesta.

 


mensaje de respuesta http format.jpg

Ejemplos

HTTP/1.1 200 OK
Date: Fri, 22 May 2009 06:07:21 GMT
Content-Type: text/html; charset=UTF-8

<html>
      <head></head> <body> <!--body goes here--> </body> </html>
La primera parte: la línea de estado, que consiste en el número de versión del protocolo HTTP, el código de estado y el mensaje de estado.

La primera línea es la línea de estado, (HTTP / 1.1) indica que la versión HTTP es la versión 1.1, el código de estado es 200 y el mensaje de estado es (ok)

La segunda parte: el encabezado del mensaje, que se utiliza para explicar alguna información adicional que utilizará el cliente

La segunda y tercera línea son el encabezado del mensaje,
Fecha: la fecha y hora en que se generó la respuesta; Tipo de contenido: HTML (texto / html) que especifica el tipo MIME, y el tipo de codificación es UTF-8

Parte 3: se requieren líneas en blanco, líneas en blanco después del encabezado del mensaje
La cuarta parte: el texto del cuerpo de respuesta, el servidor vuelve al cliente.

La parte html después de la línea en blanco es el cuerpo de la respuesta.

Código de estado HTTP

El código de estado consta de tres dígitos. El primer dígito define la categoría de respuesta, que se divide en cinco categorías:

1xx: mensaje de indicación: indica que se ha recibido la solicitud, continúe procesando
2xx: Correcto: indica que la solicitud se ha recibido, entendido y aceptado satisfactoriamente.
3xx: Redirección: se deben realizar más operaciones 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

Códigos de estado comunes:

200 OK                        //客户端请求成功
400 Bad Request //客户端请求有语法错误,不能被服务器所理解 401 Unauthorized //请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用 403 Forbidden //服务器收到请求,但是拒绝提供服务 404 Not Found //请求资源不存在,eg:输入了错误的URL 500 Internal Server Error //服务器发生不可预期的错误 503 Server Unavailable //服务器当前不能处理客户端的请求,一段时间后可能恢复正常

Más códigos de estado http://www.runoob.com/http/http-status-codes.html

Método de solicitud HTTP

Según el estándar HTTP, las solicitudes HTTP pueden usar múltiples métodos de solicitud.
HTTP 1.0 define tres métodos de solicitud: métodos GET, POST y HEAD.
HTTP1.1 agrega cinco nuevos métodos de solicitud: métodos OPTIONS, PUT, DELETE, TRACE y CONNECT.

GET     请求指定的页面信息,并返回实体主体。
HEAD     类似于get请求,只不过返回的响应中没有具体的内容,用于获取报头
POST     向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT     从客户端向服务器传送的数据取代指定的文档的内容。
DELETE      请求服务器删除指定的页面。
CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。 OPTIONS 允许客户端查看服务器的性能。 TRACE 回显服务器收到的请求,主要用于测试或诊断。

Cómo funciona HTTP

El protocolo HTTP define cómo un cliente web solicita páginas web de un servidor web y cómo el servidor transmite las páginas web al cliente. El protocolo HTTP utiliza un modelo de solicitud / respuesta. El cliente envía un mensaje de solicitud al servidor, que contiene el método de solicitud, la URL, la versión del protocolo, el encabezado de solicitud y los datos de solicitud. El servidor responde con una línea de estado. El contenido de la respuesta incluye la versión del protocolo, los códigos de éxito o error, la información del servidor, los encabezados de respuesta y los datos de respuesta.

Los siguientes son los pasos de la solicitud / respuesta HTTP:

1. El cliente se conecta al servidor web

Un cliente HTTP, generalmente un navegador, establece una conexión de socket TCP con el puerto HTTP del servidor web (80 por defecto). Por ejemplo, http://www.oakcms.cn.

2. Enviar una solicitud HTTP

A través del socket TCP, el cliente envía un mensaje de solicitud de texto al servidor Web. Un mensaje de solicitud consta de una línea de solicitud, un encabezado de solicitud, una línea en blanco y datos de solicitud.

3. El servidor acepta la solicitud y devuelve una respuesta HTTP

El servidor web analiza la solicitud y localiza el recurso solicitado. El servidor escribe una copia del recurso en el socket TCP, que el cliente lee. Una respuesta consta de 4 partes: línea de estado, encabezado de respuesta, línea en blanco y datos de respuesta.

4. Libere la conexión TCP

Si el modo de conexión está cerrado, el servidor cierra activamente la conexión TCP , y el cliente cierra pasivamente la conexión para liberar la conexión TCP ; si el modo de conexión está activo, la conexión permanecerá durante un período de tiempo y puede continuar recibiendo solicitudes durante ese tiempo;

5. El navegador del cliente analiza el contenido HTML

El navegador del cliente primero analiza la línea de estado y mira el código de estado que indica si la solicitud fue exitosa. Luego analice cada encabezado de respuesta, el encabezado de respuesta informa lo siguiente de unos pocos bytes de documentos HTML y el conjunto de caracteres del documento. El navegador del cliente lee los datos de respuesta HTML, los formatea de acuerdo con la sintaxis de HTML y los muestra en la ventana del navegador.

Por ejemplo: escriba la URL en la barra de direcciones del navegador y presione Entrar para realizar el siguiente proceso:

1. El navegador solicita al servidor DNS que resuelva la dirección IP correspondiente al nombre de dominio en la URL;

2. Después de resolver la dirección IP, establezca una conexión TCP con el servidor basada en la dirección IP y el puerto predeterminado 80 ;

3. El navegador envía una solicitud HTTP para leer el archivo (el archivo correspondiente al nombre de dominio en la URL), y el mensaje de solicitud se  envía al servidor como los datos del tercer mensaje del protocolo de enlace de tres vías TCP ;

4. El servidor responde a la solicitud del navegador y envía el texto html correspondiente al navegador;

5. Libere la  conexión TCP ;

6. El navegador muestra el texto html y muestra el contenido;   

La diferencia entre las solicitudes GET y POST

OBTENER solicitud
GET /books/?sex=man&name=Professional HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Connection: Keep-Alive

Tenga en cuenta que la última línea es una línea en blanco

Solicitud POST
POST / HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Content-Type: application/x-www-form-urlencoded Content-Length: 40 Connection: Keep-Alive name=Professional%20Ajax&publisher=Wiley

1. Enviados por GET, los datos solicitados se agregarán a la URL (es decir, los datos se colocan en el encabezado del protocolo HTTP), use? Para dividir la URL y transmitir los datos, varios parámetros están conectados con &; por ejemplo: login.action? Name = hyddd & password = idontknow y verificar =% E4% BD% A0% E5% A5% BD. Si los datos son letras / números en inglés, envíelos como están, si es un espacio, conviértalos a +, si son caracteres chinos / otros, luego encripte directamente la cadena con BASE64, resultando en:% E4% BD% A0% E5% A5% BD, donde XX en% XX es la representación ASCII del símbolo en hexadecimal.

Envío POST: coloque los datos enviados en el cuerpo del paquete HTTP. La fuente roja en el ejemplo anterior indica los datos de transmisión reales

Por lo tanto, los datos enviados por GET se mostrarán en la barra de direcciones, y la barra de direcciones no cambiará después del envío POST

2. El tamaño de los datos transmitidos: en primer lugar, se afirma que el protocolo HTTP no limita el tamaño de los datos transmitidos, y la especificación del protocolo HTTP no limita la longitud de la URL.

Las principales limitaciones en el desarrollo real son:

OBTENER : Ciertos navegadores y servidores tienen restricciones en la longitud de las URL. Por ejemplo, IE tiene un límite de 2083 bytes (2K + 35). Para otros navegadores, como Netscape, FireFox, etc., no existe un límite de longitud teórico, y el límite depende del soporte del sistema operativo.

Por lo tanto, para el envío GET, los datos de transmisión estarán limitados por la longitud de la URL.

POST : dado que el valor no se pasa a través de la URL, los datos en teoría no están limitados. Pero, de hecho, cada servidor WEB estipulará el límite en el tamaño de los datos posteriores al envío. Apache e IIS6 tienen sus propias configuraciones.

3. Seguridad

La seguridad de POST es mayor que la de GET. Por ejemplo: envíe datos a través de GET, el nombre de usuario y la contraseña aparecerán en texto sin formato en la URL, porque (1) la página de inicio de sesión puede ser almacenada en caché por el navegador; (2) otros ven el historial del navegador, luego otros pueden obtener su La cuenta y la contraseña, además, el uso de GET para enviar datos también puede causar ataques de falsificación de solicitudes en varios sitios

4. Los protocolos HTTP get, post y soap se ejecutan en http

(1) get: el parámetro de solicitud es una secuencia de pares clave / valor (cadena de consulta) adjunta a la URL. La longitud de la
cadena de consulta está limitada por el navegador web y el servidor web (como IE admite hasta 2048 caracteres), No es adecuado para transmitir grandes conjuntos de datos al mismo tiempo, es muy inseguro

(2) post: los parámetros de solicitud se transmiten en una parte diferente del encabezado http (cuerpo de entidad con nombre). Esta parte se utiliza para transmitir información de formulario, por lo que el tipo de contenido debe establecerse en: application / x-www-form-urlencoded . Post está diseñado para admitir campos de usuario en formularios web, y sus parámetros también se transmiten como pares clave / valor.
Pero: no admite tipos de datos complejos, porque la publicación no define la semántica y las reglas de la estructura de datos de transmisión.

(3) soap: es una versión especial de la publicación http, que sigue un formato especial de mensaje xml
. Tipo de contenido establecido en: text / xml Cualquier dato puede ser xmlized.

El protocolo Http define muchos métodos para interactuar con el servidor, el más básico de los cuales son cuatro tipos, a saber, GET, POST, PUT y DELETE. Una dirección URL se utiliza para describir un recurso en la red, y HTTP GET, POST, PUT, DELETE corresponde a las cuatro operaciones de verificación, modificación, adición y eliminación de este recurso. Los más comunes son GET y POST. GET se usa generalmente para obtener / consultar información de recursos, mientras que POST generalmente se usa para actualizar información de recursos.

Veamos la diferencia entre GET y POST

    1. Los datos enviados por GET se colocarán después de la URL, y la URL y los datos de transmisión se separarán por ?, y los parámetros están conectados por &, como EditPosts.aspx? Name = test1 & id = 123456. El método POST consiste en colocar los datos enviados en el cuerpo del paquete HTTP. .

    2. El tamaño de los datos enviados por GET es limitado (porque el navegador tiene un límite en la longitud de la URL), mientras que los datos enviados por el método POST no están limitados.

    3. El método GET necesita usar Request.QueryString para obtener el valor de la variable, mientras que el método POST usa Request.Form para obtener el valor de la variable.

    4. Enviar datos por GET traerá problemas de seguridad, como una página de inicio de sesión, cuando envíe datos por GET, el nombre de usuario y la contraseña aparecerán en la URL, si la página se puede almacenar en caché u otros pueden acceder a esta máquina, puede comenzar desde el historial Registre la cuenta y la contraseña del usuario.

Publicado 7 artículos originales · 69 alabanzas · 200,000+ visitas

Supongo que te gusta

Origin blog.csdn.net/u014320421/article/details/79641480
Recomendado
Clasificación