建站
咨詢
售后
建站咨詢
新聞中心
轉(zhuǎn)自：/tupian/20230522/infoflow.baidu.com –abn | find “:443” 如果有兩個(gè)Time_Wait 和CLOSE_WAIT狀態(tài)的網(wǎng)絡(luò)連接，則該服務(wù)就不可用
解決方法：
1 HttpWebRequest的缺省連接只有兩個(gè)，因此在多線程并發(fā)的情況下只有兩個(gè)并發(fā)請(qǐng)求
可以通過 System.Net.ServicePointManager.DefaultConnectionLimit = 20
設(shè)置網(wǎng)絡(luò)HttpWebRequest的網(wǎng)絡(luò)連接池的個(gè)數(shù)
2 HttpWebRequest 的請(qǐng)求因?yàn)榫W(wǎng)絡(luò)問題導(dǎo)致連接沒有被釋放則會(huì)占用連接池中的連接個(gè)數(shù)，導(dǎo)致并非連接數(shù)量減少
可以通過如下方法來修改此問題 ：
2.1 給ServicePointManager設(shè)置KeepLive檢測(cè)，在網(wǎng)絡(luò)沒有響應(yīng)的情況下關(guān)閉該連接
System.Net.ServicePointManager.SetTcpKeepAlive(true, _keepLiveTime, _intervalTime);
3 定時(shí)檢測(cè)HttpWebRequest的ServicePoint的健康狀況
//ServicePoint point = webReq.ServicePoint;
//string connectionsGroupName = webReq.ConnectionGroupName;
//if (point != null)
//{
// if (point. > 15)
// point.CloseConnectionGroup(connectionsGroupName);
//}
4 使用HttpWebRequest 一定要保證GetRequestStream和GetResponse對(duì)象關(guān)閉，否則容易造成連接處于CLOSE_WAIT狀態(tài)
using (Stream stream = webReq.GetRequestStream())
{
stream.Write(buffer, 0, buffer.Length);
}
HttpWebResponse response = null;
try
{
response = webReq.GetResponse() as HttpWebResponse;
}
finally
{
try
{
if (response != null)
response.Close();
//ServicePoint point = webReq.ServicePoint;
//string connectionsGroupName = webReq.ConnectionGroupName;
//if (point != null)
//{
// if (point. > 15)
// point.CloseConnectionGroup(connectionsGroupName);
//}
}
catch
{
}
}
I am wondering whether there is a way to handle broken (or better: closed) TCP connections that reside in the connection pool (ServicePoint) used by a HttpWebRequest instance. What I have seen on Windows 2003 Server systems is that under certain circumstances, all sockets used to connect to a web service are in CLOSE_WAIT state and all subsequent HttpWebRequests fail with a timeout, no new connections to the web service were opened. Looking at the problem with WireShark, I couldn't see any HTTP traffic even though the application kept on making requests that all ended in a timeout.
I have tried to reproduce this behaviour on a development system by writing a simple HTTP server that closes the socket after it has sent a proper HTTP 1.1 response. If you do this, you will see the same behavior that I have described above. Of course, HTTP 1.1 assumes that by default connections are kept alive unless the server explicitly sends a "Connection: Close" header. Thus, the client-side would assume that the connection should be kept alive although the server (that does not function according to HTTP 1.1) already closed it. What stuns me is that the HttpWebRequest, or more specifically the ServicePoint does not recover from such a situation (on Windows Vista/2003 Server the client-side sockets stay in CLOSE_WAIT until they're killed by the OS, on another development machine running the Windows 7 RC they're killed by the OS rather quickly and are just gone, no new ones will be created in either case).
I have tried various things on the client-side, so far I could not solve this problem (except by disabling keep alive in each HttpWebRequest by setting the "KeepAlive" property to "false"). The following list compiles what I've tried to recover from the situation described above:
- Various combinations of using() blocks to dispose all resources (WebResponse object, stream retrieved by GetResponseStream(), StreamReader that was used to read from the stream), as well as using the WebResponse.Close() method call that do everything required from my understanding of the MSDN documentation.
- Calling CloseConnectionGroup() on the ServicePoint used by the HttpWebRequest to somehow "kill" the connections
- Temporarily disabling keep alives to recover
- Increasing the number of connections in the pool of the ServicePoint so that it doesn't stop the system from functioning properly if some connections die
- Enabling TCP keep alives on the ServicePoint
- Using a lower ConnectionLeaseTimeout on the ServicePoint (works correctly in general, fails to do anything when connections are closed)
Thus, I'd like to ask here whether someone faced similar problems and might know a way to overcome such issues. I'd also like to know whether I am hunting ghosts here, although I still doubt it at the moment. I also don't see how a socket could get into a CLOSE_WAIT state without the remote communication partner closing the connection (i.e. sending FIN) and I don't understand why Vista/2003 Server do not seem to respond to this by sending a FIN and receiving an ACK to transition from CLOSE_WAIT to LAST_ACK and then to CLOSED. The HTTP server I wrote does not tinker with the LingerState of the TcpClient, default behavior should apply when it comes down to gracefully closing sockets.
Maybe I am missing some very important point about this whole thing, I'd love to be enlightened :-). If you need any further info, I'm happy to supply it.
PS: I have done all of my tests in Visual Studio 2008 linking both .NET 2.0 and .NET 3.5, it doesn't make a difference from what I can tell.
Cheers!
HTTP連接狀態(tài)：
// //服務(wù)器開通KeepLive. 第一個(gè)參數(shù)是客戶端開啟Keeplive，
// //第二個(gè)參數(shù)是客戶端是否關(guān)閉網(wǎng)絡(luò)連接
////Server: Close_Wait Client:Fin_Wait_2
//HttpRequestTest.TestHttpConnect(false, false);
////Server: Close Client: Time_Wait
//HttpRequestTest.TestHttpConnect(false, true);
////Server: ESTABLISHED Client: ESTABLISHED
//HttpRequestTest.TestHttpConnect(true, true);
//Server: Close Client: Time_Wait
// HttpRequestTest.TestHttpConnect(false, true);
//服務(wù)器關(guān)閉KeepLive. 第一個(gè)參數(shù)是客戶端開啟Keeplive，
//第二個(gè)參數(shù)是客戶端是否關(guān)閉網(wǎng)絡(luò)連接
////Server: Close_Wait Client:Fin_Wait_2
//HttpRequestTest.TestHttpConnect(false, false);
////Server: Close Client: Time_Wait
//HttpRequestTest.TestHttpConnect(false, true);
////Server: Close Client: Time_Wait
//HttpRequestTest.TestHttpConnect(true, true);
////Server: Close Client: Time_Wait
//HttpRequestTest.TestHttpConnect(false, true);
REF:
http://social.msdn.microsoft.com/Forums/en-US/netfxnetcom/thread/5c77f187-add4-46cb-a3f8-93e78910eddc
http://haacked.com/archive/2004/05/15/http-web-request-expect-100-continue.aspx
http://www.cnblogs.com/zealic/archive/2008/05/01/1107942.html
[@more@]新聞標(biāo)題：HttpWebRequest多線程性能問題，請(qǐng)求超時(shí)的錯(cuò)誤-創(chuàng)新互聯(lián)
文章源于：http://www.dlmjj.cn/article/esjjs.html
