Winfrom recopila el código fuente del rastreador
1. Descripción general de HTTP
1.1 Interacción entre cliente y servidor del protocolo HTTP
1.2.
1.3, método de solicitud HTTP
1.4, código de respuesta HTTP
2. Análisis de captura de paquetes
3 La diferencia entre POST y GET
4. Dé ejemplos de cómo utilizar POST, GET y otras operaciones en C#.
4.1, solicitud web http
4.2, HttpWebResponse
4.3 Escriba un programa WinForm para abrir la página de inicio del jardín del blog (código fuente adjunto).
1. Descripción general de HTTP
Para despertar su memoria sobre el protocolo HTTP o brindarle una comprensión del protocolo HTTP, primero presentemos brevemente el protocolo HTTP. El Protocolo de transferencia de hipertexto (HTTP, ¿Protocolo de transferencia de hipertexto) es el protocolo de red más utilizado en Internet? Todos los documentos WWW deben ajustarse a este estándar. HTTP se diseñó originalmente para proporcionar una forma de publicar y recibir páginas HTML.
El desarrollo de HTTP fue el resultado de la cooperación entre el Consorcio World Wide Web (¿World? Wide? ¿Web? Consorcio) y el Grupo de Trabajo de Internet (¿Internet? ¿Ingeniería? ¿Tarea (Ellos) finalmente publicaron). una serie de RFC, el más famoso de los cuales es el RFC 2616. RFC 2616 define una versión ampliamente utilizada del protocolo HTTP: HTTP 1.1
HTTP es un estándar para solicitudes y respuestas de clientes y servidores (TCP). El cliente es el usuario final y el servidor es el sitio web. Al utilizar un navegador web, un rastreador web u otra herramienta, el cliente envía una solicitud a un puerto específico en el servidor (el puerto predeterminado es 80) Inicia una solicitud HTTP. (Llamamos a este cliente) llama al agente de usuario (¿usuario? Agente). El servidor de respuesta almacena (algunos) recursos, como archivos HTML e imágenes. Este servidor de respuesta se llama servidor de origen (¿origen? Servidor). capas entre el agente de usuario y el servidor de origen, como proxies, puertas de enlace o túneles. Aunque el protocolo TCP/IP es la aplicación más popular en Internet, el protocolo HTTP no exige su uso y las capas que admite HTTP sí. puede implementarse a través de cualquier otro protocolo de Internet u otra red. HTTP solo asume una transmisión confiable y cualquier protocolo que pueda proporcionar esta garantía puede ser utilizado por él.
Normalmente, un cliente HTTP inicia una solicitud. Conexión TCP al puerto especificado del servidor (el puerto predeterminado es 80). El servidor HTTP envía una solicitud desde el cliente del monitor de puerto. Una vez recibida la solicitud, el servidor devuelve una línea de estado, como "HTTP/1.1? 200? OK". ". Y mensaje (respuesta), el cuerpo del mensaje puede ser el archivo solicitado, mensaje de error o alguna otra información.
HTTP usa TCP en lugar de UDP porque una página web debe transmitir una gran cantidad de datos, y TCP El protocolo proporciona funciones como control de transmisión, ordenamiento de datos y corrección de errores. Los recursos solicitados a través del protocolo HTTP o HTTPS se identifican mediante un Identificador uniforme de recursos (¿Uniforme? ¿Recurso? Identificador, o más exactamente, URI)
<. p>La estructura y el proceso de interacción entre el cliente y el servidor se pueden expresar como las dos figuras siguientes:Figura 1, estructura cliente-servidor web (donde el enlace de hipertexto del servidor Web pasa por el Enlace salta a otros servidores).
Figura 2. Interacción entre el cliente web y el servidor
1.2, mensaje HTTP
Las interacciones entre el cliente y el servidor utilizan dos tipos. Mensajes: solicitudes y respuestas.
El formato de la solicitud HTTP es:
Figura 3. El formato de la solicitud HTTP
El formato de la respuesta HTTP es:
Figura 4. El formato de la respuesta HTTP
Como se puede ver en lo anterior, los encabezados de los mensajes de solicitud y respuesta HTTP contienen un número variable de campos, con una línea en blanco (¿línea en blanco?) para separar todos los campos del encabezado. el cuerpo del mensaje por separado. El campo de título consta de un nombre de campo seguido de dos puntos, un espacio y el valor del campo no distingue entre mayúsculas y minúsculas.
Los encabezados de los mensajes se pueden dividir en tres categorías: una para solicitudes, otra para respuestas y otra para describir el tema. Algunos encabezados (como Fecha) están disponibles para solicitudes y respuestas. Los encabezados que describen el asunto pueden aparecer en las solicitudes POST y en todos los mensajes de respuesta. Los campos de encabezado de HTTP se muestran en la siguiente figura:
Figura 5. Campos de encabezado HTTP
1.3, métodos de solicitud HTTP
En el protocolo HTTP/1.1, * * se definen ocho métodos (a veces llamados "acciones") para indicar la especificación de URI de solicitud. modos de recursos:
¿Opciones?
Devuelve el método de solicitud HTTP para un recurso específico admitido por el servidor. También puede probar la funcionalidad del servidor enviando una solicitud "*" al servidor web.
¿Cabeza?
Solicite una respuesta del servidor que sea coherente con la solicitud GET, pero no se devolverá el cuerpo de la respuesta. Este método obtiene la metainformación contenida en el encabezado del mensaje de respuesta sin transmitir todo el contenido de la respuesta.
¿Entiendes?
Realizar una solicitud a un recurso específico. Nota: El método GET no debe usarse en operaciones que produzcan "efectos secundarios", como en Web? en aplicación. Una razón es que las arañas web y similares pueden acceder a GET a voluntad.
¿Publicar?
Una solicitud para enviar datos a un recurso específico para su procesamiento (como enviar un formulario o cargar un archivo). Los datos se incluyen en el cuerpo de la solicitud. Las solicitudes de publicación pueden resultar en el establecimiento de nuevos recursos y/o modificación de recursos existentes.
¿Guardarlo?
Sube su contenido más reciente a la ubicación de recursos especificada.
¿Eliminar?
Solicita al servidor que elimine el recurso identificado por el URI de solicitud.
¿Huellas?
Responder a las solicitudes recibidas por el servidor, utilizadas principalmente para pruebas o diagnóstico.
¿Conectar?
El protocolo HTTP/1.1 está reservado para servidores proxy que pueden cambiar las conexiones al modo canalización.
Los nombres de los métodos distinguen entre mayúsculas y minúsculas. Cuando el recurso al que se dirige la solicitud no admite el método de solicitud correspondiente, el servidor debe devolver el código de estado 405 (¿Método? ¿No? Permitido; cuando el servidor no conoce o no admite el método de solicitud correspondiente, debe devolver el código de estado); 501 (¿No? Implementado).
Los servidores HTTP deben implementar al menos los métodos GET y HEAD, otros métodos son opcionales. Además, además de los métodos anteriores, servidores HTTP específicos también pueden ampliar métodos personalizados.
Métodos de seguridad
Los desarrolladores deben ser conscientes de que su software representa las interacciones de los usuarios en Internet y deben informarles que lo que están haciendo puede tener consecuencias inesperadas para ellos mismos o para otros. .
Especialmente para los métodos GET y HEAD, estas solicitudes no deben tener ningún significado distinto al de obtener información de recursos. En otras palabras, estos métodos deben considerarse "seguros", lo que significa que las operaciones se utilizan para obtener información en lugar de modificarla. Los clientes deben utilizar otros métodos "inseguros", como POST, PUT y DELETE, informar al cliente de una posible responsabilidad (como un botón que genere una transacción financiera) o usarse de una manera especial (generalmente un botón en lugar de un hipervínculo). Informar que la operación solicitada puede no ser segura (como que se esté cargando o eliminando un archivo).
Sin embargo, no se puede dar por sentado que el servidor no manejará solicitudes GET sin efectos secundarios. De hecho, muchos recursos dinámicos se caracterizarán por esto. La diferencia importante aquí es que el usuario no solicitó este efecto secundario, por lo que no debe ser responsable de estos efectos secundarios.
Métodos impotentes
Estos métodos de solicitud se utilizan si los efectos secundarios de varias solicitudes son los mismos que los efectos secundarios de una sola solicitud o no tienen ningún efecto secundario, sin tener en cuenta Problemas de cuenta como errores o caducidad. Pueden considerarse "idempotentes".
Los métodos GET, HEAD, PUT y DELETE tienen esta propiedad idempotente. Asimismo, según el protocolo, OPTIONS y TRACE no deberían tener efectos secundarios, por lo que son naturalmente idempotentes.
Si el resultado de una secuencia de solicitudes que consta de varias solicitudes no cambia después de la ejecución repetida de esta secuencia de solicitudes o de una o más de ellas, ¿entonces esta secuencia de solicitudes es idempotente? Sí. Sin embargo, puede suceder que varias solicitudes emitan una secuencia de solicitud que sea "no idempotente" aunque todos los métodos de solicitud ejecutados en esta secuencia de solicitud sean idempotentes. Por ejemplo, el resultado de esta solicitud de serialización depende de variables que se modificarán en la próxima ejecución de esta serialización.
1.4, código de respuesta HTTP
La primera línea de la respuesta del programa del servidor se llama línea de estado. La línea de estado comienza con el número de versión HTTP, luego el código de respuesta de 3 dígitos y, finalmente, la frase de respuesta legible por humanos. Según el primer lugar, estas respuestas se pueden dividir en cinco categorías:
Figura 6. Código de respuesta HTTP
2. Análisis de captura de paquetes
Ahora que tenemos un conocimiento básico de HTTP, usaré Wireshark para capturar mi computadora y los paquetes HTTP del proceso de interacción del servidor del blog. Esté preparado para cerrar algunos programas relacionados que puedan interferir con nuestra capacidad de rastrear y abrir el blog. Como se muestra en la figura siguiente, cuando ingresamos www.cnblogs.com en el navegador y confirmamos, primero capturamos el siguiente paquete:
Figura 7. Abre Blog Garden para conseguir el paquete.
Como se puede ver en la imagen, cuando ingresamos www.cnblogs.com en el navegador y confirmamos, se envía un mensaje de solicitud HTTP al servidor: GET/HTTP/1.1. Según el formato del mensaje HTTP introducido en 1.2, sabemos que GET corresponde a la solicitud, / corresponde a la línea de solicitud y HTTP/1.1 corresponde al número de versión. Además de la línea de solicitud, también se envían algunos campos de encabezado, como: Aceptar, Aceptar-Idioma, Usuario-Agente, Aceptar-Codificación, Host, Conexión, etc. Y se puede observar que su formato es: nombre del primer campo:? valor del campo, tenga en cuenta que hay un espacio después de los dos puntos.
A continuación, echemos un vistazo al mensaje de respuesta de la solicitud GET/HTTP/1.1:
Figura 8. Mensaje de respuesta para solicitud GET/HTTP/1.1.
La línea de estado del mensaje de respuesta es: HTTP/1.1200OK, donde HTTP/1 corresponde al número de versión, 200 corresponde al código de respuesta y OK corresponde a la frase de respuesta. Además de la línea de estado, también se devolverán algunos campos de encabezado, como: Cache-Control, Content-Type, Content-Encoding, Expires, Last-Modified, Vary, Server, etc. Como puede ver en la imagen de arriba, el blog usa IIS7.0.
Lo anterior es un paquete GET, ahora quiero ver un paquete POST: la información de categoría de la izquierda se devuelve a través de la solicitud POST cuando abro la página de inicio de Blog Park.
Figura 9. Paquetes postales
¿Podemos ver, publicar? /ws/servicio de usuario público .asmx/GetLoginInfo? HTTP/1.1. La información es similar excepto que GET se cambia a POST. Echemos un vistazo más de cerca al campo de título enviado:
Figura 10, ¿Publicación? /ws/servicio de usuario público .asmx/GetLoginInfo? Campos de encabezado HTTP/1.1
Nota: algunos campos de encabezado involucrados en esta sección no se explican aquí. Creo que la comprensión que todos tienen de HTTP debería ir más allá.
3. La diferencia entre POST y GET
En 1.3 se introdujeron ocho métodos, entre los cuales GET y POST son los más básicos y comúnmente utilizados. La diferencia entre get y post en el envío de formularios se resume a continuación:
GET obtiene datos del servidor y POST transmite datos al servidor.
GET agrega la cola de datos de parámetros a la URL indicada por el atributo ACTION del formulario enviado. El valor corresponde a cada campo del formulario y se puede ver en la URL. ¿Las publicaciones son a través de HTTP? ¿Mecanismo POST que pone cada campo y su contenido en un formulario en HTML? El encabezado se agrega a la dirección URL indicada por el atributo ACCIÓN. Los usuarios no pueden ver este proceso.
Para el modo GET, el servidor utiliza Request. QueryString obtiene el valor de la variable. Para el modo POST, el servidor utiliza Solicitud. formulario para obtener los datos enviados.
La cantidad de datos transmitidos por GET es pequeña y no puede superar los 2 KB (principalmente debido a restricciones de longitud de URL). POST transfiere grandes cantidades de datos y, por lo general, el valor predeterminado es ilimitado. Pero, en teoría, el límite depende de la potencia de procesamiento del servidor.
GET tiene baja seguridad y POST tiene alta seguridad. Debido a que GET coloca los datos en la URL solicitada durante el proceso de transmisión, muchos servidores, servidores proxy o agentes de usuario existentes registrarán la URL solicitada en un archivo de registro y la colocarán en algún lugar, por lo que existe cierta privacidad. La información puede ser vista por terceros. Además, los usuarios también pueden ver los datos enviados directamente en el navegador, y parte de la información interna del sistema también se mostrará frente a los usuarios. Todas las operaciones POST son invisibles para el usuario.
Al enviar un formulario, si no se especifica ningún método, será una solicitud GET de forma predeterminada (.net por defecto es POST) y los datos enviados en el formulario se agregarán a la URL, usando? separado de la URL. Los caracteres alfanuméricos se envían tal cual, pero los espacios se convierten en signos "+" y otros símbolos se convierten a %XX, donde XX es un valor ASCII (¿o ISO? Latin-1). Los datos enviados por la solicitud GET se colocan en el encabezado del protocolo de solicitud HTTP y los datos enviados por POST se colocan en los datos de la entidad. Los datos enviados por GET solo pueden tener hasta 2048 bytes, mientras que POST no tiene este límite. Los parámetros pasados por POST están en doc, es decir, ¿pantanos? =?(HttpWebRequest) sistema. Net.WebRequest.Create(txtURL.text.ToString());?
cnbogs. ¿aceptar? =?"image/jpeg,?app/x-ms-application,?image/gif,?app/xaml+xml,?image/pjpeg,?app/x-ms-xbap,?app/x -shockwave-flash ,?aplicación/vnd.ms-powerpoint,?aplicación/QVOD,?
cnbogs. ¿Agente de usuario? =?"Mozilla/4.0? (Compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2 SLCC2.NET CLR 2.0.50727; NET CLR 3.5.30729 ? ? CLR ? CIBA ? . NET ? PC ? ;?
cnbogs. ¿método? =?"Obtener";?
¿Respuesta HTTPWeb? cnblogsRespone? =?(HttpWebResponse)cnbogs. ObtenerRespuesta();?
¿Y si? (cnblogsRespone?!=?zero&&cnblogsRespone.StatusCode==HttpStatusCode.OK)?
{?
Usar (StreamReader?sr?=?new?StreamReader(cnblogsRespone.
GetResponseStream()))?
{?
html? =?Sr .
}?
}?
¿Volver? HTML?
}?
¿Privado? ¿Vacío? btnGetHtml_Click(¿Objeto? ¿Remitente? ¿EventArgs? e)?
{?
Cuadro de mensajes. mostrar(GetCnBlogs());?
}?
Haga clic en el botón "Ver código fuente HTML" y aparecerá un cuadro de diálogo para mostrar el código fuente HTML de la página de inicio de Blog Park.
De hecho, este proceso es el mismo que escribir en el navegador para abrir el sitio web de Blog Park, pero aquí lo implementamos a través de los objetos de la clase HttpWebRequest y la clase HttpWebRequest.
¿Pero haciendo clic en el botón "Mostrar en el navegador web", justo debajo? La función de mostrar la página de inicio de Blog Garden en el control WebBrowser es similar, excepto que se muestra en el control WebBrowser. Encapsula algunas operaciones comunes relacionadas con HTTP en un espacio de nombres auxiliar para su uso posterior. Haga clic para descargar el código fuente de todo el proyecto.
Mi código fuente es relativamente simple. Simplemente uso la clase HttpWebRequest y la clase HttpWebRequest para implementar la interacción con el servidor HTTP. Espero que complete funciones más completas.
Explicación adicional: con respecto al límite de longitud de la URL, ¿cuál es la URL más larga en IE? 2083? caracteres (medio ancho), mientras que GET solo puede alcanzar hasta 2048 caracteres. Pero ¿qué pasa con los RFC? 2616, ¿hipertexto? ¿Transferir de escuela? ¿protocolo? - ?HTTP/1.1 no limita la longitud máxima de la URL. ?
Este artículo proviene de Webology(), indique la fuente para la reimpresión:/LUN Wen-resource/net-biancheng/c-zhongruheshiyong-post get-Deng-fushili-download/