中国免费域名申请网站,便宜的网站空间,怎么重建wordpress,肃宁网站建设1.TCP握手定理 2.TCP状态 l CLOSED#xff1a;初始状态#xff0c;表示TCP连接是“关闭着的”或“未打开的”。 l LISTEN #xff1a;表示服务器端的某个SOCKET处于监听状态#xff0c;可以接受客户端的连接。 l SYN_RCVD #xff1a;表示服务器接收到了来自客户端请求…1.TCP握手定理 2.TCP状态 l CLOSED初始状态表示TCP连接是“关闭着的”或“未打开的”。 l LISTEN 表示服务器端的某个SOCKET处于监听状态可以接受客户端的连接。 l SYN_RCVD 表示服务器接收到了来自客户端请求连接的SYN报文。在正常情况下这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态很短暂基本上用netstat很难看到这种状态除非故意写一个监测程序将三次TCP握手过程中最后一个ACK报文不予发送。当TCP连接处于此状态时再收到客户端的ACK报文它就会进入到ESTABLISHED 状态。 l SYN_SENT 这个状态与SYN_RCVD 状态相呼应当客户端SOCKET执行connect()进行连接时它首先发送SYN报文然后随即进入到SYN_SENT 状态并等待服务端的发送三次握手中的第2个报文。SYN_SENT 状态表示客户端已发送SYN报文。 l ESTABLISHED 表示TCP连接已经成功建立。 l FIN_WAIT_1 这个状态得好好解释一下其实FIN_WAIT_1 和FIN_WAIT_2 两种状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时它想主动关闭连接向对方发送了FIN报文此时该SOCKET进入到FIN_WAIT_1 状态。而当对方回应ACK报文后则进入到FIN_WAIT_2 状态。当然在实际的正常情况下无论对方处于任何种情况下都应该马上回应ACK报文所以FIN_WAIT_1 状态一般是比较难见到的而FIN_WAIT_2 状态有时仍可以用netstat看到。 l FIN_WAIT_2 上面已经解释了这种状态的由来实际上FIN_WAIT_2状态下的SOCKET表示半连接即有一方调用close()主动要求关闭连接。注意FIN_WAIT_2 是没有超时的不像TIME_WAIT 状态这种状态下如果对方不关闭不配合完成4次挥手过程那这个 FIN_WAIT_2 状态将一直保持到系统重启越来越多的FIN_WAIT_2 状态会导致内核crash。 l TIME_WAIT 表示收到了对方的FIN报文并发送出了ACK报文。 TIME_WAIT状态下的TCP连接会等待2*MSLMax Segment Lifetime最大分段生存期指一个TCP报文在Internet上的最长生存时间。每个具体的TCP协议实现都必须选择一个确定的MSL值RFC 1122建议是2分钟但BSD传统实现采用了30秒Linux可以cat /proc/sys/net/ipv4/tcp_fin_timeout看到本机的这个值然后即可回到CLOSED 可用状态了。如果FIN_WAIT_1状态下收到了对方同时带FIN标志和ACK标志的报文时可以直接进入到TIME_WAIT状态而无须经过FIN_WAIT_2状态。这种情况应该就是四次挥手变成三次挥手的那种情况 l CLOSING 这种状态在实际情况中应该很少见属于一种比较罕见的例外状态。正常情况下当一方发送FIN报文后按理来说是应该先收到或同时收到对方的ACK报文再收到对方的FIN报文。但是CLOSING 状态表示一方发送FIN报文后并没有收到对方的ACK报文反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢那就是当双方几乎在同时close()一个SOCKET的话就出现了双方同时发送FIN报文的情况这是就会出现CLOSING 状态表示双方都正在关闭SOCKET连接。 l CLOSE_WAIT 表示正在等待关闭。怎么理解呢当对方close()一个SOCKET后发送FIN报文给自己你的系统毫无疑问地将会回应一个ACK报文给对方此时TCP连接则进入到CLOSE_WAIT状态。接下来呢你需要检查自己是否还有数据要发送给对方如果没有的话那你也就可以close()这个SOCKET并发送FIN报文给对方即关闭自己到对方这个方向的连接。有数据的话则看程序的策略继续发送或丢弃。简单地说当你处于CLOSE_WAIT 状态下需要完成的事情是等待你去关闭连接。 l LAST_ACK 当被动关闭的一方在发送FIN报文后等待对方的ACK报文的时候就处于LAST_ACK 状态。当收到对方的ACK报文后也就可以进入到CLOSED 可用状态了。 ####################################################################################################################################### LISTEN等待从任何远端TCP 和端口的连接请求。 SYN_SENT发送完一个连接请求后等待一个匹配的连接请求。 SYN_RECEIVED发送连接请求并且接收到匹配的连接请求以后等待连接请求确认。 ESTABLISHED表示一个打开的连接接收到的数据可以被投递给用户。连接的数据传输阶段的正常状态。 FIN_WAIT_1等待远端TCP 的连接终止请求或者等待之前发送的连接终止请求的确认。 FIN_WAIT_2等待远端TCP 的连接终止请求。 CLOSE_WAIT等待本地用户的连接终止请求。 CLOSING等待远端TCP 的连接终止请求确认。 LAST_ACK等待先前发送给远端TCP 的连接终止请求的确认包括它字节的连接终止请求的确认 TIME_WAIT等待足够的时间过去以确保远端TCP 接收到它的连接终止请求的确认。 TIME_WAIT 两个存在的理由 1.可靠的实现tcp全双工连接的终止 2.允许老的重复分节在网络中消逝。 CLOSED不在连接状态这是为方便描述假想的状态实际不存在 ###################################################################################################################################### 3.服务器大量TIME_WAIT和CLOSE_WAIT分析 #查看TCP状态netstat -n | awk /^tcp/ {S[$NF]} END {for(a in S) print a, S[a]} TIME_WAIT 814CLOSE_WAIT 1FIN_WAIT1 1ESTABLISHED 634SYN_RECV 2LAST_ACK 1 常用的三个状态是ESTABLISHED 表示正在通信TIME_WAIT 表示主动关闭CLOSE_WAIT 表示被动关闭Listen表示正在监听可以接受客户端连接。 #常见问题分析 1.服务器保持了大量TIME_WAIT状态 2.服务器保持了大量CLOSE_WAIT状态 因为linux分配给一个用户的文件句柄是有限的而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持那么意味着对应数目的通道就一直被占着而且是“占着茅坑不使劲”一旦达到句柄数上限新的请求就无法被处理了接着就是大量Too Many Open Files异常tomcat崩溃。 ############################################################################# tomcat环境下服务器文件句柄耗尽Too Many Open Files的问题排查 为什么会出现文件句柄耗尽的情况 主要是因为linux在文件句柄的数目上有两个级别的限制。一个是系统级别的总数限制一个是针对用户的限制。默认情况下每个用户所能使用的句柄数是1024。一般情况下1024也够用了但是在大容量的系统上特别是会频繁使用网络通信和文件IO的系统上1024很快就被耗光了。所以首先我们要调整这个值。修改方法如下 1. ulimit -a 查看当前用户的文件句柄限制 2. 用户级别的句柄数限制修改 修改 /etc/security/limits.conf 增加下面的代码 用户名(或者用*表示所有用户) soft nofile 65535 用户名 hard nofile 65535 有两种限制一种是soft软限制在数目超过软限制的时候系统会给出warning警告但是达到hard硬限制的时候系统将拒绝或者异常了。 修改之后可能需要重启shell生效。 3. 系统级别的句柄数限制修改 sysctl -w fs.file-max 65536 或者 echo 65536 /proc/sys/fs/file-max 两者作用是相同的前者改内核参数后者直接作用于内核参数在虚拟文件系统procfs, psuedo file system上对应的文件而已。 可以用下面的命令查看新的限制 sysctl -a | grep fs.file-max 或者 cat /proc/sys/fs/file-max 4.修改内核参数 /etc/sysctl.conf echo fs.file-max65536 /etc/sysctl.conf sysctl -p 查看系统总限制 命令cat /proc/sys/fs/file-max 查看整个系统目前使用的文件句柄数量命令cat /proc/sys/fs/file-nr 查看某个进程开了哪些句柄 lsof -p pid 某个进程开了几个句柄 lsof -p pid |wc -l 也可以看到某个目录 /文件被什么进程占用了,显示已打开该目录或文件的所有进程信息 lsof path/filename 具体这个值应该设置成多少 优先级Open File Descriptorssoft limit hard limit kernel 实现最大file descriptor数采用的数据结构所导致的限制 其实这个值倒是没有具体限制但是分配的值如果太大反而会影响系统性能所以要根据具体应用调配权衡。 问题的解决方案 首先当然是修改linux句柄数限制到一个合适的值。 然后就是应用本身的一个调整。有这么几种情况 1.数据库连接池的优化。必须要使用连接池否则句柄没耗光数据库就崩了。。。 2.抓取资源的时候有可能会用到HttpClient尽量也应该使用连接池来控制连接数。 3.连接池设置的把握建立连接超时时间读取超时时间连接数目等待时间等都需要配置到一个合适的值否则发挥不出连接池的性能。 ########################################################################################################### 解决思路很简单就是让服务器能够快速回收和重用那些TIME_WAIT的资源。 对/etc/sysctl.conf文件的修改 #对于一个新建连接内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255默认值是5对应于180秒左右时间 net.ipv4.tcp_syn_retries2 #net.ipv4.tcp_synack_retries2 #表示当keepalive起用的时候TCP发送keepalive消息的频度。缺省是2小时改为300秒 net.ipv4.tcp_keepalive_time1200 net.ipv4.tcp_orphan_retries3 #表示如果套接字由本端要求关闭这个参数决定了它保持在FIN-WAIT-2状态的时间 net.ipv4.tcp_fin_timeout30 #表示SYN队列的长度默认为1024加大队列长度为8192可以容纳更多等待连接的网络连接数。 net.ipv4.tcp_max_syn_backlog 4096 #表示开启SYN Cookies。当出现SYN等待队列溢出时启用cookies来处理可防范少量SYN攻击默认为0表示关闭 net.ipv4.tcp_syncookies 1 #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接默认为0表示关闭 net.ipv4.tcp_tw_reuse 1 #表示开启TCP连接中TIME-WAIT sockets的快速回收默认为0表示关闭 net.ipv4.tcp_tw_recycle 1 ##减少超时前的探测次数 net.ipv4.tcp_keepalive_probes5 ##优化网络设备接收队列 net.core.netdev_max_backlog3000 修改完之后执行/sbin/sysctl -p让参数生效。 这里头主要注意到的是net.ipv4.tcp_tw_reuse net.ipv4.tcp_tw_recycle net.ipv4.tcp_fin_timeout net.ipv4.tcp_keepalive_* 这几个参数。 net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的开启都是为了回收处于TIME_WAIT状态的资源。 net.ipv4.tcp_fin_timeout这个时间可以减少在异常情况下服务器从FIN-WAIT-2转到TIME_WAIT的时间。 net.ipv4.tcp_keepalive_*一系列参数是用来设置服务器检测连接存活的相关配置。 如果将大量CLOSE_WAIT的解决办法总结为一句话那就是查代码。因为问题出在服务器程序里头啊。 转载于:https://www.cnblogs.com/xinfang520/p/8961129.html
