Java Socket网络编程常见的异常有哪些,然后通过一个实验来重现其中的Connection reset异常,并且通过配置Tomcat的参数来解决这个问题。
超时异常,超时分为
端口被占用。 当服务器端调用
若端口已被占用,就会抛该异常。
可以用
netstat –an
查看端口被谁占用了,换个空闲端口即可。
连接被拒绝。 当客户端调用
原因是:
从客户端机器ping一下服务端IP:
连接已关闭。
通信的一方主动关闭了Socket连接(调用了Socket的close方法),接着又对Socket连接进行了读写操作,这时os会报“Socket连接已关闭”。
连接被重置。
为了避免这些异常发生,在编写网络通信程序时要确保:
通信管道已坏。
发生这个异常的场景是,通信的一方在收到“Connect reset by peer: Socket write error”后,如果再继续写数据则会抛出Broken pipe异常,解决方法同上。
进程打开文件句柄数超过限制。
当并发用户数比较大时。 因为每创建一个Socket连接就需一个文件句柄,而且服务端程序在处理请求时可能也需要打开一些文件。
可通过
lsof -p pid
查看进程打开了哪些文件,是否有资源泄露,即进程打开的这些文件本应该被关闭,但由于程序的Bug而没有被关闭。
若无资源泄露,可通过设置增加最大文件句柄数:通过
ulimit -a
查看系统目前资源限制,通过
ulimit -n 10240
修改最大文件数。
客户端向服务端发送SYN包,服务端回复SYN+ACK,同时将这个处于SYN_RECV状态的连接保存到半连接队列。
客户端返回ACK包完成三次握手,服务端将ESTABLISHED状态的连接移入accept队列,等待应用程序(Tomcat)调用accept方法将连接取走。 这里涉及两个队列:
net.ipv4.tcp_max_syn_backlog
设置min(net.core.somaxconn,backlog)
。其中backlog是我们创建ServerSocket时指定的参数,最终会传递给listen方法:int listen(int sockfd, int backlog);
若设置的backlog大于net.core.somaxconn
,accept队列的长度将被设置为net.core.somaxconn
,而这个backlog参数就是Tomcat中的acceptCount参数,默认值100,但请注意net.core.somaxconn
默认值128。
在高并发情况下当Tomcat来不及处理新连接时,这些连接都被堆积在accept队列,而acceptCount参数可以控制accept队列长度。超过该长度,内核会向客户端发送RST,这样客户端会触发“Connection reset”异常。
Tomcat#maxConnections 指Tomcat在任意时刻接收和处理的最大连接数。 当Tomcat接收的连接数达到maxConnections时,Acceptor线程不会再从accept队列取走连接,这时accept队列中的连接会越积越多。
maxConnections的默认值与连接器类型有关:
所以Tomcat
最大并发连接数 = maxConnections + acceptCount
若acceptCount
通过netstat命令发现有大量的TCP连接处在TIME_WAIT状态,请问这是为什么?它可能会带来什么样的问题呢?
增大accept队列长度会使得Tomcat并发短连接数暴增,势必导致服务器处理完请求后,需主动断开连的连接数增加; TCP 连接处在 TIME_WAIT 状态,是TCP协议规定的,四次挥手时主动关闭方所处的一个状态。断开连接时四次挥手的最后一个阶段,客户端要等待2MSL,保证服务端收到客户端ack(如果服务端没有收到最后一次挥手ack会重试,这时客户端需重新发送ack),所以在这个时间段内不会释放端口,若并发量过大会导致大量time_wait;一旦达到上限将导致服务器拒绝服务。
复现流量高峰时accept队列堆积场景,即会导致客户端触发“Connection reset”异常,然后调参解决。
线程组(线程数这里设置为1000,模拟大流量):
请求(请求的路径是Tomcat自带的例子程序):
2.启动Tomcat。 3.开启JMeter测试,在View Results Tree中会看到大量失败的请求,请求的响应里有“Connection reset”异常,也就是前面提到的,当accept队列溢出时,服务端的内核发送了RST给客户端,使得客户端抛出了这个异常。