HttpWebRequest的GetResponse或GetRequestStream偶尔超时 + 总结各种超时死掉的可能和相应的解决办法

简介: 原文:HttpWebRequest的GetResponse或GetRequestStream偶尔超时 + 总结各种超时死掉的可能和相应的解决办法     【问题】 用C#模拟网页登陆,其中去请求几个页面,会发起对应的http的请求request,其中keepAlive设置为true,提交请求后,然后会有对应的response: resp = (HttpWebResponse)req.GetResponse(); 之前的多次调试,一直都是可以正常获得对应的response,然后读取html页面的。
原文: HttpWebRequest的GetResponse或GetRequestStream偶尔超时 + 总结各种超时死掉的可能和相应的解决办法

 

 

【问题】

用C#模拟网页登陆,其中去请求几个页面,会发起对应的http的请求request,其中keepAlive设置为true,提交请求后,然后会有对应的response:

resp = (HttpWebResponse)req.GetResponse();

之前的多次调试,一直都是可以正常获得对应的response,然后读取html页面的。

但是后来几次的调试,在没有改变代码的前提下,结果GetResponse却始终会超时死掉。

 

【解决过程】

1.默认request的timeout是1000000毫秒=100秒,都会超时,手动改为10秒,因此就更容易超时了,无法解决问题。

2.将http的request的keepAlive设置为false,问题依旧。

3.去谷歌找资料:https://www.google.com/search?q=HttpWebRequest%E8%B6%85%E6%97%B6&oq=HttpWebRequest%E8%B6%85%E6%97%B6&gs_l=serp.3..30i10.4020.6251.0.6485.18.11.3.0.0.0.328.1364.0j1j3j1.5.0....0...1c.1j4.64.serp..12.6.772...0j0i13.FSdXWvba01k

去把前面共4次的httprequest,每次都增加对应的:

resp = null; 
if (resp != null) 
{ 
    resp.Close(); 
} 
if (req != null) 
{ 
    req.Abort(); 
}

结果还是没解决问题。

4. 同样参考:http://www.cnblogs.com/robot/archive/2009/06/10/1500085.html

去尝试关于DefaultConnectionLimit的设置,改为为10:

System.Net.ServicePointManager.DefaultConnectionLimit = 10; 

问题依旧。

5.又去测试了下,关于response.Close()

也是没解决问题。

6. 最后无意间,索性不抱希望的,再次DefaultConnectionLimit设置为更大的值50:

System.Net.ServicePointManager.DefaultConnectionLimit = 50;

试了试,结果就解决超时的问题了。

然后才搞懂原因。

之前默认设置为2,后来改为10,都没有解决问题的原因在于,当前有很多个http的连接,没有被关闭掉,

而这些keepalive的连接,都是

由于代码中,对于前面多个request。其都是keepalive为true,以及多个response也没有close,

而之前调试了很多次了,所以,此时已经存在了很多个alive的http连接了,已经超过了10个了,所以前面设置了DefaultConnectionLimit 为10,也还是没用的。

而改为50,才够用。

【总结】

此处GetResponse超过的原因是,当前存在太多数目的alive的http连接(大于10个),所以再次提交同样的http的request,再去GetResponse,就会超时死掉。

解决办法就是,把DefaultConnectionLimit 设置为一个比较大一点的数值,此数值保证大于你当前已经存在的alive的http连接数即可。

【经验总结】

以后写http的request代码,如果不是必须的要keepalive的,那么就要设置KeepAlive为false:

req.KeepAlive = false;

以及做对应的收尾动作:

if (resp != null) 
{ 
    resp.Close(); 
} 
if (req != null) 
{ 
    req.Abort(); 
}

 

 【后记】

又偶尔遇到一次,DefaultConnectionLimit已经是200了,足够大了,但是GetResponse和GetRequestStream,还是会超时死掉的问题,具体是什么原因导致的还不是很清楚,但是经过折腾,参考:

HttpWebResponse’s GetResponse() hangs and timeouts

在:

req = (HttpWebRequest)WebRequest.Create(constSkydriveUrl); 
setCommonHttpReqPara(ref req); 
resp = (HttpWebResponse)req.GetResponse();

之前,添加一句垃圾回收:

System.GC.Collect();

然后就解决了GetResponse的超时问题,并且后面的GetRequestStream也同时可以正常工作,不超时了。

所以,看起来像是当前系统由于调试多次,并且HttpWebRequest和HttpWebResponse都是没有正常去Close的,可能会残留一些http的链接,然后就可能影响到了后续对于http的使用,垃圾回收后,估计就把残余的http相关资源释放了,然后http就可以正常工作了。

 

【总结】

对于GetResponse或GetRequestStream超时死掉的原因,可能是:

1.DefaultConnectionLimit是默认的2,而当前的Http的connection用完了,导致后续的GetResponse或GetRequestStream超时死掉

==>> 默认系统只支持同时存在2个http的connection

==>> 使用HttpWebRequest之后如果没有close,则会占用1个http的connection,所以如果超过2次使用HttpWebRequest而没有close,那么就用完系统的http的connection,之后再去使用HttpWebRequest,GetResponse就会死掉

解决办法:

办法1:

每次使用完HttpWebRequest,使用

req.Close();
req=null

去关闭对应的http connection

最好对应的HttpWebResponse也要close:

resp.Close();
resp = null;

方法2:

修改DefaultConnectionLimit的值,改为足够大,比如:

 

 

System.Net.ServicePointManager.DefaultConnectionLimit = 200;

  

2.系统中Http相关的资源没有正确释放,导致后续GetResponse或GetRequestStream超时死掉

就像我此处遇到的,可能是之前调用http相关函数,没有正确完全释放资源,导致虽然DefaultConnectionLimit给了足够大,但是还是会死掉,此时在http请求代码之前去做一次垃圾回收,则后续http的GetResponse或GetRequestStream就正常了,就不会超时死掉了。

参考代码如下:

System.GC.Collect();
 
req = (HttpWebRequest)WebRequest.Create(constSkydriveUrl);
setCommonHttpReqPara(ref req);
resp = (HttpWebResponse)req.GetResponse();

  

3.Http的GET请求时,不要手动设置ContentLength的值

这个是参考这里:HttpWebRequest.GetResponse() hangs the second time it is called而记录于此的,也许有人是此原因,所以可供参考一下。

即Http的GET请求,不要添加类似如下的代码:

if (m_contentLength > 0)
    httpWebRequest.ContentLength = m_contentLength;

不要去手动修改对应的ContentLength的值,C#的http相关库函数,会自动帮你计算的。

注:POST方法中,的确是要手动填充数据和算出数据大小,然后手动给ContentLength赋值的。

建议大家使用【wireshark】抓包,检查服务器的网络,我也是刚学会

 

 

 

4.其他可能的一些原因

(1)关于KeepAlive的问题

如果Http的请求,是设置了KeepAlive=true的话,那么对应的http的connection会和服务器保持连接的。

所以如果上述办法都不能解决超时的问题,可以尝试将keepAlive设置为false试试,看看能否解决。

(2)关于Sleep

有些人好像是通过在http请求前,加了对应的Sleep,结果解决了此问题。需要的人,也可以试试。

(3)HttpWebRequest的Timeout

一般来说,既然超时了,往往是由于错误使用函数或者网络有问题导致的,所以实际上此处对于有些人去把HttpWebRequest的Timeout的值改的更大,往往都是没用的。

只不过,万一是由于网络响应慢而导致超时,那么倒是可以尝试,将HttpWebRequest的Timeout的值改为更大。

(其中HttpWebRequest的Timeout默认的值是100,000 milliseconds ==100 seconds)

参考代码:

req.Timeout = 5 * 60 * 1000; // 5 minutes

  


目录
相关文章
|
小程序 开发工具 git
【微信小程序】-- uni-app 项目--- 购物车 -- 配置 tabBar 效果(五十一)
【微信小程序】-- uni-app 项目--- 购物车 -- 配置 tabBar 效果(五十一)
|
存储 安全 测试技术
C# 中模拟HTTPS提交及模拟文件上传
【1月更文挑战第5天】昨天讲到用C#模拟POST还有GET进行数据提交,如果遇到的是https或者一些特殊信道的提交昨天的代码就会跑不通,今天就来说一下C#中https的提交以及模拟文件上传
|
4月前
|
运维 网络协议 安全
Netcat:网络瑞士军刀(Linux小白也能轻松上手的网络调试利器)
来源:https://www.vps5.cn/ 教程Netcat(nc)是Linux下强大的网络工具,被誉为“网络瑞士军刀”,支持端口扫描、文件传输、远程通信等。本文详解其安装与基础用法,如端口检测、搭建聊天服务器和文件收发,并提醒明文传输风险,适合初学者快速入门网络调试。
|
机器学习/深度学习 自然语言处理 搜索推荐
智能语音交互技术:构建未来人机沟通新桥梁####
【10月更文挑战第28天】 本文深入探讨了智能语音交互技术的发展历程、当前主要技术框架、核心算法原理及其在多个领域的应用实例,旨在为读者提供一个关于该技术全面而深入的理解。通过分析其面临的挑战与未来发展趋势,本文还展望了智能语音交互技术如何继续推动人机交互方式的革新,以及它在未来社会中的潜在影响。 ####
1434 0
|
前端开发 C# 开发工具
在WPF中使用WriteableBitmap对接工业相机及常用操作
注意事项 1:像素格式问题,相机SDK提供转化成你需要的格式的方法,在接收图像时要确保两边像素格式一致。相机SDK中提供的像素格式、Bitmap的System.Drawing.Imaging.PixelFormat和WriteableBitmap的System.Windows.Media.PixelFormats对同一像素格式的命名是不同的。比如本文中的PixelFormats.Bgr24对应的是Bitmap中的PixelFormat.Format24bppRgb。可以通过解析同一张图像来确定两者之间的对应关系。 2:使用工业相机采图的方式一般都是使用回调函数的形式,所以在回调函数的多线程环境
741 0
|
数据采集 缓存 网络安全
Python中网络请求超时的原因及解决方案
Python中网络请求超时的原因及解决方案
|
网络安全 C#
C# HttpWebRequest 获取 HTTPS 网页内容
C# HttpWebRequest 获取 HTTPS 网页内容
2188 0
|
Java Python
如何设置代理ip服务器地址
如何设置代理ip服务器地址
724 0