c# - studio - ¿Por qué la solicitud Http con Fiddler está ardiendo rápido?
fiddler not capturing traffic from visual studio (2)
Escribí un programa de subprocesos múltiples en c # que rastrea un sitio web, pero cuando inicié Fiddler en la solicitud en segundo plano completada 12 veces más rápido, es realmente extraño para mí y cuando cierro las tasas de descarga de Fiddler disminuye. cómo es posible, por favor, ayuda, (no hay una configuración de proxy para mi conexión a Internet y para Fiddler también) Si puedo inyectar el rendimiento de Fiddler en mi aplicación, ¿sería una solución maravillosa? ¿Hay magia detrás de escena? :)
Gracias
¿Puedes mostrar algún código de ejemplo para que la gente pueda confirmar esto? De lo contrario, se volverá salvaje adivinando.
Mi mejor conjetura: Fiddler usa keepalive, lo que le ahorrará la molestia de abrir la conexión una y otra vez. Puede confirmar esto deshabilitando tanto Reuse client connections como Reuse connections to servers : si es tan lento como de costumbre (o más lento), se obtiene el beneficio de mantener la conexión activa.
La razón es el límite para la cantidad de conexiones http que se ignoran al usar Fiddler.
Encontré el mismo comportamiento al usar System.Net.Http.HttpClient para realizar múltiples solicitudes simultáneas (~ 80). Con Fiddler en ejecución, todas las solicitudes se completaron mucho más rápido. Keep-alive fue habilitado ciertamente.
Usé Wireshark para ver qué estaba pasando y lo primero que noté fue que la forma del tráfico http era diferente. Con Fiddler, las solicitudes se lanzaron todas a la vez y después de eso, las respuestas también fueron bien agrupadas. Sin Fiddler las peticiones se intercalaron con respuestas.
En segundo lugar, tcpview mostró que mi código sin Fiddler creó solo 2 conexiones tcp al servidor. Con Fiddler iniciado, la cantidad de conexiones aumentó drásticamente. Había decenas de ellos desde mi aplicación a Fiddler y luego desde Fiddler al servidor.
Es bien sabido que el estándar http recomienda que la cantidad de conexiones http no sea superior a 2 y parece que el límite se implementa como una configuración predeterminada en los clientes http.
En aplicaciones .NET podemos controlar el límite con la propiedad estática ServicePointManager.DefaultConnectionLimit . Como experimento, al configurarlo en 100, las solicitudes se ejecutan a la misma velocidad con o sin Fiddler.
La configuración también se puede controlar a través de app.config:
<system.net>
<connectionManagement>
<add address="*" maxconnection="100" />
</connectionManagement>
</system.net>
Ahora, ¿por qué no se respeta el límite de conexión predeterminado al usar Fiddler? Resulta que el límite es diferente cuando un cliente http utiliza un proxy y Fiddler actúa como un proxy. No encontré mucha información sobre el límite de conexión de proxy además de este artículo anterior .