大并发带来服务器各种层出不穷的问题，我们要善用服务器系统内核，因为其性能优于用户态的玩意

注：若想永久保存参数，可将其加入到/etc/sysctl.conf中，执行sysctl -p使其永久生效，临时改配则修改/proc/sys/net/ipv4下的参数，重启后失效

[root@master ipv4]# more tcp_syn_retries

5

描述：对于一个新建链接，内核要发送多少SYN链接请求才决定放弃，不应大于255，default value 是5，对应180s,(对于大负载而物理信道通信良好的网络而言，这个值偏高，可修改为2，这个值仅是针对对外的链接，对进来的链接是由tcp_retries1)

对与这个对应时间，经过抓包是有问题的，我们来看截图

 

我们看到重发时间，跟描述并不相符合，那tcp是以什么原则来确定重发时间呢

 

强大的wireshark已经告诉我们了，当发送一个tcp片段后将开始计时，等待该TCP片段的ACK，如果接收方收到符合次序的片段，接收方会利用ACK片段回复发送方，发送方得到ACK后，继续移动窗口，发送接下来的TCP片段，如果直到计时完成，send方仍未收到ACK回复，那么判断之前发送的TCP片段丢失，因此重新发送，这个计时叫做重新发送超时时间（RTO，reteransmission timeout）

 

发方应该在等待多久时间之后重发呢，这是重发的核心问题

上述过程实际上有往返两个方向，1，发送片段从发方到接收方的传输

2，ACK片段从接收方到发送的传输。

整个过程实际耗费称往返时间（RTT）。若RTT是固定的，那么我们可以让

RTO等于RTT即可，但在实际上，RTT上下浮动很大，

 

如图，一个是局域网，一个是公网，我们发现其RTO时间是不一样的，即使在局域网，如果某个时刻，网络中交通比较拥塞，那么RTT也会增加，因此，我们如果设置了RTO过小，那么实际上之前发送的TCP片段未丢失，网络中重复注入TCP片段，从而浪费网络传输资源，另一方面，如果RTO过长，那么当前面的TCP片段丢失的情况下，发方未能及时重发，会造成网络资源闲置。

       所以RTO必须符合当前网络的使用状况，网络状况越好，RTO应该越短，越差则RTO应越长。

TCP协议通过统计RTT，来决定合理的RTO，发送方可以测量每一次TCP传输的RTT（从发送数据片段开始，到接收到ACK片段为止），这样每次测量得到的RTT，叫采样RTT，

此时我们来观测下，为何局域网内RTT为1s

 

请容许我再次感谢万能的wireshark，基于第一次TCP报文的往返时间，1s，

我们仔细观察syn报文从往返时间上可以得出以下规律

第一次   RTO = RTT

第二次   RTO = 1*RTT

第三次   RTO = 2*RTT

第四次   RTO = 4*RTT

第五次   RTO = 8*RTT

 

至此，TCP之发送SYN相关就到此时暂告一个段落，限于文档的上传限制，不能尽述，只好待下次了…

 

END!