Requisitos: La mayoría de los sitios web ahora utilizan principalmente los protocolos de versiones Http/1.1 e Http/2.0; para sitios web que solo soportan la versión del protocolo HTTP/2, usar HttpClient para enviar solicitudes por defecto, lanzará System.Net.Http.Http.Http.HttpRequestException: Se produjo un error al enviar la solicitud. ---> System.IO.IOException: No se puede leer datos de la conexión de transporte: El software en tu host ha abortado una conexión establecida. ---> System.Net.Sockets.SocketException (10053): El software en tu host aborta una conexión establecida. en System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(error SocketError, booleano forAsyncThrow).
Historia del protocolo HTTP
Línea de tiempo
HTTP/0.9
El obsoleto HTTP/0.9 fue la primera versión del protocolo HTTP, nacida en 1989. Es extremadamente sencillo, permite al cliente enviar una solicitud GET y no soporta la cabecera de la petición. Dado que no hay encabezado de protocolo, HTTP/0.9 solo puede soportar un tipo de contenido: texto plano. El servidor solo puede responder a cadenas en formato HTML, no en otros formatos. Cuando el servidor termina de enviar, la conexión TCP se cierra.
HTTP/0.9 tiene una típica apatridia, donde cada visita se procesa de forma independiente y se desconecta cuando el procesamiento está completo. Si la página solicitada no existe, no se devuelve ningún código de error.
HTTP/1
HTTP/1 es un término colectivo para HTTP 1.0 y HTTP 1.1, que se refiere a las versiones del protocolo HTTP que son 1.0 y 1.1, respectivamente.
HTTP 1.0 fue la segunda versión del protocolo HTTP y sigue siendo ampliamente adoptado hoy en día. Ha realizado varias mejoras y mejoras basadas en HTTP/0.9, incluyendo:
Se pueden enviar más formatos como imágenes, vídeos y binarios más allá del texto
Además de y se han añadido métodos de solicitud POST
Cambié el formato de las solicitudes y respuestas HTTP. Además de la parte de datos, cada comunicación debe incluir un encabezado HTTP que describa algunos metadatos, es decir, se añade la información del encabezado de la solicitud
Se añadieron funciones como código de estado de respuesta, soporte para conjuntos de múltiples caracteres, autorización, caché y codificación de contenido
Aunque sigue siendo un protocolo sin estado, se pueden soportar conexiones largas añadiendo el encabezado "Connection: keep-alive" a la solicitud
HTTP 1.1
HTTP 1.1 es un protocolo estandarizado, y HTTP 1.1 elimina mucha ambigüedad e introduce varias mejoras.
peculiaridad
El procesamiento de caché, HTTP 1.1, introduce más políticas de control de caché, como etiqueta de entidad, If-Unmodified-Since, If-Match, If-None-Match, etc., y más cabeceras opcionales para controlar la política de caché.
La optimización del ancho de banda y el uso de conexiones de red introducen un rango en la cabecera de la solicitud, que permite solicitar solo una parte del recurso, es decir, devolver el código de estado 206, lo que facilita a los desarrolladores elegir libremente aprovechar al máximo el ancho de banda y los enlaces, y pueden usar Rango y Contenido-Rango para crear una función de reanudación de puntos de interrupción.
Gestión de notificaciones de error, se han añadido 24 nuevos códigos de estado de error en HTTP 1.1.
Añadir el encabezado Host permite configurar diferentes nombres de dominio en servidores con la misma dirección IP.
Soporta conexiones largas, HTTP 1.1 soporta conexiones largas, se pueden transmitir múltiples solicitudes y respuestas HTTP en una conexión TCP, reduciendo el consumo y el retraso en establecer y cerrar conexiones, y Connection:keep-alive está habilitado por defecto en HTTP 1.1, y los navegadores generales permiten establecer 6 enlaces largos al mismo tiempo para el mismo nombre de dominio.
Se añadió tecnología de pipelining para permitir que se envíe una segunda petición antes de que la primera respuesta esté completamente enviada para mejorar el bloqueo de colas, pero el orden de las respuestas seguirá devolveéndose en el orden de las solicitudes.
Soporta el fragmento de respuesta, configurando Transfer-Encoding: chunked for chunked response, permitiendo dividir los datos de respuesta en varias partes, y el servidor puede liberar el buffer lo antes posible para obtener una velocidad de respuesta más rápida.
HTTP 2.0
HTTP 2.0 tiene mejor rendimiento, y ahora las páginas web se están volviendo cada vez más complejas, e incluso evolucionan hacia aplicaciones únicas, la cantidad de reproducción multimedia, el tamaño de los scripts para mejorar la interacción también han aumentado mucho, y se transmiten más datos a través de peticiones HTTP, por lo que HTTP 2.0 ha hecho muchas optimizaciones para la eficiencia de la red.
peculiaridad
La división binaria de tramas, HTTP 2.0, es un protocolo binario más que un protocolo de texto que divide toda la información transmitida en mensajes y tramas más pequeños y los codifica en formato binario.
Multiplexando, las solicitudes paralelas pueden procesarse en el mismo enlace, todos los accesos bajo el mismo nombre de dominio provienen de la misma conexión TCP, los mensajes HTTP se descomponen en tramas independientes, y el servidor reensambla los mensajes según identificadores y cabeceras, eliminando las restricciones de orden y bloqueando en HTTP 1.1.
Comprimir cabeceras, que a menudo son similares en una serie de solicitudes, elimina el coste de duplicación y transmisión de datos duplicados.
En el push del lado del servidor, el servidor puede enviar recursos proactivamente al cliente sin que el cliente lo solicite explícitamente.
HTTP 3.0
HTTP 3.0 está actualmente en fase de formulación y pruebas, es un nuevo protocolo HTTP en el futuro, el protocolo HTTP 3.0 funciona sobre el protocolo QUIC, se basa en UDP para lograr una transmisión fiable, compensar la velocidad de transmisión y la fiabilidad de la transmisión y optimizar, usando UDP evitará el problema de bloqueo de colas TCP y acelerará la velocidad de transmisión en red, pero también necesita un mecanismo de transmisión fiable, HTTP 3.0 no es una extensión de HTTP 2.0, HTTP La versión 3.0 será un protocolo completamente nuevo.
HttpClientHandler VS SocketsHttpHandler
El gestor de mensajes predeterminado utilizado por HttpClient en .NET Framework y .NET Core 2.0 y anteriores es HttpClientHandler.
A partir de .NET Core 2.1, clasesSocketsHttpHandler proporciona una clase de red HTTP de nivel superior(por ejemplo, HttpClient). Utilizar SocketsHttpHandler ofrece muchas ventajas:
El rendimiento ha mejorado significativamente en comparación con implementaciones anteriores.
Eliminar dependencias de la plataforma para simplificar el despliegue y el servicio. Por ejemplo, libcurl ya no depende de .NET Core para macOS ni de .NET Core para Linux.
Comportamiento consistente en todas las plataformas .NET.
En .NET 9, HttpClientFactory utiliza SocketsHttpHandler como gestor principal
HttpClientFactory permite configurar pipelines HttpClient para objetos HttpMessageHandler nombrados y tipados. El manejador más interno o el manejador que realmente envía solicitudes en la red se llama gestor maestro. Si no estaba configurado, este manejador siempre fue un HttpClientHandler antes. Aunque el gestor maestro por defecto son los detalles de implementación, hay usuarios que dependen de él. Por ejemplo, algunos usuarios castan el gestor principal a las propiedades de configuración HttpClientHandler como ClientCertificates, UseCookies y UseProxy.
Enlace:El inicio de sesión del hipervínculo es visible.
La configuración global solicita la versión del protocolo HTTP
El código es el siguiente:
DefaultRequestVersionLa configuración predeterminada es HttpVersion.Version11。
La propiedad DefaultRequestVersion especifica la versión HTTP predeterminada que se usará para las solicitudes enviadas usando esta instancia HttpClient, cuando construye el mensaje HttpRequestMessage para enviar, específicamente llamando a 、、、GetStreamAsyncGetAsyncGetByteArrayAsync, PatchAsyncGetStringAsync, PostAsync y PutAsync.
Propiedad DefaultRequestVersionNo se aplica al método SendAsync。 El parámetro HttpRequestMessage pasado al método SendAsync como parámetro tiene su propia propiedad Version que controla la versión HTTP utilizada para la solicitud.
Enlace:El inicio de sesión del hipervínculo es visible.
Política de negociación de política HttpVersion
RequestVersionOrLower: Usar la versión solicitada, o degradar a una versión inferior (pero no superior a la versión solicitada). Este es el comportamiento por defecto. En términos sencillos, la versión de protocolo más utilizada es la actual, y si no se soporta la versión actual del protocolo, será degradada.
RequestVersionOrHigher: Utilizar la versión más alta soportada por el servidor, pero no inferior a la versión solicitada. Es decir, se permiten mejoras y no se permiten degradaciones por debajo de la versión solicitada. En términos sencillos, utiliza protocolos de versión superior para la comunicación siempre que sea posible.
SolicitudVersiónExacta: Usa estrictamente la versión solicitada, no se permiten mejoras ni degradaciones.
HttpClient utiliza el protocolo de la versión Http/2.0
El código de prueba es el siguiente:
La solicitud utiliza la versión 1.1, y el cliente final y el servidor negocian para usar el protocolo 2.0 para comunicarse, por lo que la respuesta final es la versión 2.0, como se muestra en la figura siguiente:
Referencia:
El inicio de sesión del hipervínculo es visible.
El inicio de sesión del hipervínculo es visible.
El inicio de sesión del hipervínculo es visible. |
Publicado el 31-8-2025 21:16:47
|
|
|
|
Propietario|
Publicado el 31-8-2025 21:46:27
|
