crawler_http关闭连接

1:ps aux|grep Spider4Test.jar

查看端口

2: lsof  -p [端口号]

在爬虫运行期间如果看到 大量的 TIME_WAIT  WAIT_CLOSE 说明请求关闭阻塞【采用httpclient默认方法 ,其实没有关闭掉,需要跑等3分钟 才会关闭】 大量并发时   会有阻塞

3: 解决方法

最简单方法【方法四: 
代码实现很简单,所有代码就和最上面的事例代码一样。只需要在HttpMethod method = new GetMethod("http://www.apache.org");加上一行HTTP头的设置即可

    1. method.setRequestHeader("Connection", "close");

其它方法:参考

http://www.cnblogs.com/wasp520/archive/2012/07/06/2580101.html

备注:

TCP状态转移要点
TCP协议规定,对于已经建立的连接,网络双方要进行四次握手才能成功断开连接,如果缺少了其中某个步骤,将会使连接处于假死状态,连接本身占用的资源不 会被释放。网络服务器程序要同时管理大量连接,所以很有必要保证无用连接完全断开,否则大量僵死的连接会浪费许多服务器资源。在众多TCP状态中,最值得 注意的状态有两个:CLOSE_WAIT和TIME_WAIT。

1、LISTENING状态
FTP服务启动后首先处于侦听(LISTENING)状态。

2、ESTABLISHED状态
ESTABLISHED的意思是建立连接。表示两台机器正在通信

3、CLOSE_WAIT

对方主动关闭连接或者网络异常导致连接中断,这时我方的状态会变成CLOSE_WAIT 此时我方要调用close()来使得连接正确关闭

4、TIME_WAIT

我方主动调用close()断开连接,收到对方确认后状态变为TIME_WAIT。TCP协议规定TIME_WAIT状态会一直持续2MSL(即两倍的分 段最大生存期),以此来确保旧的连接状态不会对新连接产生影响。处于TIME_WAIT状态的连接占用的资源不会被内核释放,所以作为服务器,在可能的情 况下,尽量不要主动断开连接,以减少TIME_WAIT状态造成的资源浪费。

目前有一种避免TIME_WAIT资源浪费的方法,就是关闭socket的LINGER选项。但这种做法是TCP协议不推荐使用的,在某些情况下这个操作可能会带来错误。

5、SYN_SENT状态

   SYN_SENT状态表示请求连接,当你要访问其它的计算机的服务时首先要发个同步信号给该端口,此时状态为SYN_SENT,如果连接成功了就变为 ESTABLISHED,此时SYN_SENT状态非常短暂。但如果发现SYN_SENT非常多且在向不同的机器发出,那你的机器可能中了冲击波或震荡波 之类的病毒了。这类病毒为了感染别的计算机,它就要扫描别的计算机,在扫描的过程中对每个要扫描的计算机都要发出了同步请求,这也是出现许多 SYN_SENT的原因。

时间: 2024-11-09 20:03:52

crawler_http关闭连接的相关文章

【HTTP】如何正常关闭连接

参考:<HTTP权威指南> 所有HTTP客户端.服务器或者代理都可以任意时刻关闭一条TCP传输连接.但是服务器永远无法确定它关闭"空闲"连接的那一刻,在线路那一头的客户端有没有数据要发送. 每条HTTP响应都应该有精确的Content-Length首部,用来描述响应主体的尺寸.如果老的HTTP服务器省略了Content-Length或者包含错误的长度指示,这样就要依赖服务器发出连接关闭来说明数据的真实末尾. 如果一个事务,不管是执行一次还是很多次,得到的结果都相同,这个事务

TCP三次握手(建立连接)/四次挥手(关闭连接)

相对于SOCKET开发者,TCP创建过程和链接折除过程是由TCP/IP协议栈自动创建的.因此开发者并不需要控制这个过程.但是对于理解TCP底层运作机制,相当有帮助. 而且对于有网络协议工程师之类笔试,几乎是必考的内容.因此在这里详细解释一下这两个过程. TCP数据包格式 顺序号( 32 位):用来标识从 TCP 源端向 TCP 目的端发送的数据字节流,它表示在这个报文段中的第一个数据字节的顺序号.如果将字节流看作在两个应用程序间的单向流动,则TCP用顺序号对每个字节进行计数.序号是32bit的无

SO_LINGER和优雅关闭连接

http://blog.csdn.net/ccnyou/article/details/8913334 原文:http://unliminet.blog.51cto.com/380895/346686 当调用closesocket关闭套接字时,SO_LINGER将决定系统如何处理残存在套接字发送队列中的数据.处理方式无非两种:丢弃或者将数据继续发送至对端,优雅关闭连接.事实上,SO_LINGER并不被推荐使用,大多数情况下我们推荐使用默认的关闭方式(即下方表格中的第一种情况). 下方代码段显示l

c#对数据库访问完应关闭连接

1.对数据库的连接SqlConnection con = new SqlConnection(constr);使用完成后,应该至少应该close或dispose关闭.否则会导致数据库例如(SQl2005)中处于sleeping的进程增加并且不能自己销毁,最终会导致出现"“连接超时,已经到达最大连接数等信息”.       其解决方法:见微软的官方说明“如果 SqlConnection 超出范围,则不会将其关闭.因此,除非将代码放在 using 语句内,否则必须调用 Close 或 Dispose

boost::asio 连接管理11 如何关闭连接

在实际产品运行中,对连接管理有了更新的认识,这里分享一下. shared_ptr管理连接对象的生命周期 shared_ptr的引用计数器决定了连接对象的生命周期.这里我说的连接对象就是在我的前文:http://blog.csdn.net/csfreebird/article/details/8522620 中的Client对象: [cpp] view plaincopyprint? #include "core/connection.h" #include <vector>

java连接oracle数据库,关闭连接出现异常:java.sql.SQLRecoverableException: IO Error: Connection reset

java.sql.SQLRecoverableException: IO Error: Connection reset at oracle.jdbc.driver.T4CConnection.logoff(T4CConnection.java:612) at oracle.jdbc.driver.PhysicalConnection.close(PhysicalConnection.java:5094) at com.sms.send.StartTaskNew.run(SmsSend.java

关于TCP主动关闭连接中的wait_timeout

首先我们先来回顾一下tcp关闭连接的过程: 假设A和B连接状态为EST,A需要主动关闭: A发送FIN给B,并将状态更改为FIN_WAIT1, B接收到FIN将状态更改为CLOSE_WAIT,并回复ACK和FIN A收到ACK后将状态更改为FIN_WAIT2,收到FIN后,更改状态为WAIT_TIMEOUT并给B返回ACK B收到ACK后,将关闭自己的链接CLOSE. 问题就在此时,A将处于WAIT_TIMEOUT状态长达2MSL时常(RFC793定义了MSL为2分钟,Linux设置成了30s)

WCF项目中出现常见错误的解决方法:基础连接已经关闭: 连接被意外关闭

原文:WCF项目中出现常见错误的解决方法:基础连接已经关闭: 连接被意外关闭 在我们开发WCF项目的时候,常常会碰到一些莫名其妙的错误,有时候如果根据它的错误提示信息,一般很难定位到具体的问题所在,而由于WCF服务的特殊性,调试起来也不是那么方便,因此往往会花费不少时间来进行跟踪处理.本文介绍我在我在我的框架里面使用WCF服务的时候,出现的一个常见错误的处理方法,它的提示信息是:基础连接已经关闭: 连接被意外关闭.这种情况我碰到的有两种,一种是返回DataTable的时候出现的,一种是返回实体类

Mybatis 打开连接池和关闭连接池性能对比

1  创建数据库表 -- phpMyAdmin SQL Dump -- version 4.2.11 -- http://www.phpmyadmin.net -- -- Host: localhost -- Generation Time: 2016-08-02 18:13:50 -- 服务器版本: 5.6.21 -- PHP Version: 5.6.3 SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"; SET time_zone = "+0