万万没想到，你变成了这样的 GitHub

github：https://github.com/doukoi-BDB

文章底部有【技术社群&福利】，不定更新活动、源码，欢迎来撩~~~

今日主题：

1、仓库代码更新（详见公告）

2、服务端tcp 连接出现大量time_wait (问题)

3、github活动参与持续进行

一、仓库代码 更新公告🪧

1、新增 4个demo 案列&类库 代码：

1）发送邮件demo案例，邮件类库；

2）发送短信demo案例，短信类库；

3）导出excel 表格demo案例；

4）数据导出pdf 案例，类库；

注意事项：代码均可优化，因我写的为了结合案例，未曾使用框架，可替换内容，可自行优化。

链接🔗：https://github.com/doukoi-BDB

二、服务端tcp连接出现大量time_wait

上述问题分为 3块来思考：

Q1、大量的time_wait 状态tcp 连接存在，其本质原因是什么？

Q2、会对业务产生影响吗？

Q3、解决方式是什么？

先来回答第一个问题：

解答：高并发场景时候，会有大量短连接场景，特别是在http请求头中，如果connection 头部被设置为 close时，基本都由【服务端】发起主动关闭连接。

而 tcp 四次挥手关闭连接机制中，为了保证 ack 重发和丢弃延迟数据，设置time_wait 为 2倍的 msl（报文最大存活时间）。

其次回答第二个问题：

解答：每一个time_wait 状态，都会占用一个本地端口，上限为65535（16bit），当大量连接处于 time_wait 时，新的tcp建立连接就会【报错】，报错信息：address already in use ：connect 异常 。

tips: tcp 本地端口数量，上限65535（6.5w），这是因为 tcp头部使用16bit存储端口号，因此约束上限。

最后回答第三个问题：

解答：3种解决方式，分别是：

1）客户端的http请求头部，connection 设置为 keep-alive，保持存活时间。2）服务端缩减time_wait时间，设置为1 msl(即，2min)。 

3）更新内核参数，编辑文件：/etc/sysctl.conf 。调整参数如下：

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30

然后执行 /sbin/sysctl -p 让参数生效。

注意⚠️⚠️⚠️：

统计网络time_wait连接状态及tcpip连接数 命令如下：

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

状态：描述

CLOSED：无连接是活动的或正在进行

LISTEN：服务器在等待进入呼叫

SYN_RECV：一个连接请求已经到达，等待确认

SYN_SENT：应用已经开始，打开一个连接

ESTABLISHED：正常数据传输状态

FIN_WAIT1：应用说它已经完成

FIN_WAIT2：另一边已同意释放

ITMED_WAIT：等待所有分组死掉

CLOSING：两边同时尝试关闭

TIME_WAIT：另一边已初始化一个释放，等待tcp连接的数量，这个状态也是占用连接的

LAST_ACK：等待所有分组死掉

三、9月30开奖活动

上篇介绍了自己的GitHub 仓库用来服务大家，特意讲解是做什么，也因此给到大家一波简单的小福利红包🧧。

文章链接：https://mp.weixin.qq.com/s/nIJkATtPJsyOT7Jniar9Uw

文章底部有参与方式～～～

分割线

为了让各位方便：交流、交友、技术视频、资源分享、接私活 等等，可以扫下面二维码（wx：xzzs730），备注 “ 技术 ” 就可以通过审核。

进群的小伙伴请加右侧私人微信（备注：技术）

-----商务合作分隔线----

商务合作，关注公众号回复“商务合作”