从生产环境遇到的问题聊聊TCP设计思路

当我们在学校学习网络和网络传输层时，我们可能总是感到枯草乏味、枯燥难懂。但事实上，在生产环境中，这是一个非常常见的问题，如果你不明白，可能会更困惑。

生产环境遇到的问题

谈谈我今年遇到的TCP层的几个问题。

• 问题1：长短连接的选择？
  
• 问题2：连接超时了，为什么超时的时间是128s左右
  
• 问题3：系统不可达，80端口连不通了，可是本地查看80端口是正常的，这是为什么？
  
• 问题4：客户端连接池很多处于CLOSE-WAIT？
  

传输层

要充分解释这些问题，我们需要对传输层的协议有非常深入的了解。网络层可能离软件开发人员有点远，但传输层，特别是广泛使用的TCP，与我们的工作密切相关。

传输层的目的

• 从上到下依次包括 应用层、传输层、网络层、链路层、物理层。
  
• 应用层就是对应不同的数据
  
• 通过网络层，包已经能够正确的被路由到对应的主机
  

我们需要有机制将不同的应用程序映射到同一主机的网络层，并确保数据的准确到达。

区别不同的应用-UDP

• 每个应用程序对应一个端口，端口信息也封装在包中，以确定数据包属于哪个应用的。
  
• UDP的报文格式为传输层的简单协议，也很简单。
  

保证传输的质量-TCP

UDP不保证数据的准确传输和质量保证。如果包丢失，网络层不会重新传输。因此，传输层还设计了一种新的协议TCP。除了端口映射外，还在应用层和网络层之间增加了一些处理机制，以确保传输质量。

传输的质量对应用而言实际上就2个方面：

• 收到了对端发出的所有数据。
  
• 对端发出的所有数据都按顺序收到。
  

• C1.C2表示两个客户端与app1有数据交互。
  
• 假设app1向C2发送数据，app1的传输层应确保所有数据都发送到C2，以确保没有丢包事件。
  

• 不丢包不是真的不丢包，而是如果丢包还能重传，保证数据最终收到。
  

• 假设C1向app1发送数据，则需要按顺序正确接收发送的数据。
  

核心：Tcp的具体运行机制

TCP要干什么

依据以上的描叙，TCP主要的要做2件事：

• 防止丢包
  

     a.丢包重传

       一般情况下，收到包后会向发送者发送ack信号。

       超时未收到会使用重传机制。

     b. 减少丢包

       告诉我你的窗口:感受对端的处理能力。

       丢包原因及优化：感受网络拥塞，控制传输速率。

• 保证包到达的顺序。
  

       使用序列号：确保数据包按正确顺序交付。

基本试探-建立连接

正如上面提到的，TCP首先要试探两个对端的收发能力，试探过程如下：

主要是试探并确认了：

• 确认A发送数据的能力
  
• 确认B接收数据的能力
  
• 确认B发送数据的能力
  
• 确认A接收数据的能力
  

这个试探过程也叫做三次握手，通过三次握手两个应用程序之间建立了一条TCP连接。

具体的过程和状态

TCP连接是内核抽象给应用程序使用的。

我们可以更具体地看看这个过程，包括建立连接之前、中间和之后。

三次握手的状态随时间变迁图如下：

三次握手就是三次发包的过程：

• 1、发起端发送SYNC包：SYN，seq=x，自己进入Sync-Sent状态
  注意：seq=x，下面还会有详细描述
  
• 2、监听端收到SYNC包，发送SYN,ACK,seq=y,ack=x+1，进入Sync-RCVD状态
  
• 3、发起端收到SYNC，ACK包,发送           ACK,seq=x+1,ack=y+1，进入Established状态
  a、RTT表示发送数据到收到ACK的时间
  
• 4、监听端收到ACK包，进入Established状态
  

accept和LISTEN

服务器的内核使用accept系统调用来帮助建立连接。服务器调用accep函数后，处于LISTEN状态。可以等待客户端建立连接，并使用netstat查看LISTEN状态的连接。

# netstat -alpnt
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:11110           0.0.0.0:*  

• *0.0.0.0:**表示接受网络上所有端口的连接。
  
• 内核使用socket作为真正的tcp连接对象，但accept的socket是特殊的，没有建立tcp连接。
  

ESTABLISHED

三次握手成功后，这个连接将保存在内存中。

# netstat -alpnt
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 9.13.73.14:38604      9.13.39.104:3306       ESTABLISHED 26100/java          
tcp        0      0 9.13.73.14:32926      9.21.210.17:8080       ESTABLISHED 26100/java    

• ESTABLISHED:已建立连接。
  
• 连接的信息包括本地IP端口地址和远程IP端口。
  a.本地9.13.73.14:38604与远程9.13.39.104:3306建立连接。
  b.本地9.13.73.14:32926与远程9.21.210.17:8080建立连接。
  

对于问题3的回答

有一次，我们的服务无法到达，即80端口无法连接，但登录机器并发送80端口仍然是正常的列表状态，但我们发现许多连接处于Sync-RCVD状态。查看日志，我们发现系统已经运行，完全有理由怀疑服务建立连接的过程是由内存引起的。

因此，尽管80端口的LISTEN状态正常，但外部无法正常连接。

TCP报文格式和信息交换

三次握手中发的数据报都是TCP报文，TCP报文格式如下：

从这个报文格式和上面三次握手的过程可以看出：

• SYN标记位为1说明这个报文是一个SYN类型的包，用于握手
  

1. 发起端发送SYNC包：SYN，seq=x
   
2. 监听端收到SYNC包后，也发送自己的SYN包：SYN，seq=y
   
3. 发起端和监听端的起始序号x和y是32位序号，它们是系统随机生成的
   
4. 在SYN报文中交换了初始序列号之后，这个序列号就一直单调递增
   
5. 初始序列号ISN还用于关闭连接的吗？
   

• ACK标记位为1说明这个报文是一个ACK类型的包
  

1. 32位确认号
   
2. 监听端收到SYNC包，还发送ACK,ack=x+1，小于x+1的全部字节已经收到，**期待下一次收到seq=x+1的包
   
3. 发起端收到SYNC，发送ACK,ack=y+1，小于y+1的全部字节已经收到,期待下一次收到seq=y+1的包**
   

• 用于SYN和ACK连接的包的数据为空
  

另外报文格式中还包含下面信息：

1. 接收到的SYN包的窗口大小代表对方的接收窗口的大小
   
2. RST标记位为1: 可以用于强制断开连接
   
3. PSH标记位为1：告知对方这些数据包收到后应该马上交给上层的应用
   
4. 选项中的MSS:TCP允许的从对方接收的最大报文段。
   

连接建立后，传输数据

连接建立后，数据可以传输。

回顾上述TCP主要保证的两件事和基本思路：

• 使用序列号seq确保数据包按正确的顺序交付。
  
• ack信号和超时重传机制防止丢包。
  
• 用窗户减少丢包。
  

建立连接的过程为这件事情做好了铺垫。让我们来看看具体的运行机制。

超时重传和ACK深层含义

• 发送出去的数据如果一直没收到ack就重传，需要确定多久时间没收到就重传
  

• 接收端如果多次收到同一个seq的数据就丢弃
  
• 需要大于RTT,又不能太大
  
• RTT是在动态变化的，内核采样，使用RTO来计算
  

每当遇到一次超时重传时，都会将下一次超时间隔将设置为以前值的两倍。多次超时，表明网络环境差，不宜频繁重复发送，就会每次将成为原来的两倍，可设置最大重传次数。

现在就可以回答问题2了

问题2：连接超时了，为什么超时的时间是128s左右

初始1S超时，然后因为系统设置的重传次数是6，重传了6次，1+2+4+8++16+32+64加起来大约是128s左右。

可以批量提交ack

seq=4的ack没有正确的收到， 但如果在超时时间内收到了ack=6 则表示6之前的seq都已经正确接收到了 seq=4的数据也不会重传

滑动的窗口和右移的指针

发送端的socket缓冲区，示意图如下：

• 已发送并收到ACK确认的数据
  

• 已发送但未收到ACK确认的数据
  
• 未发送但总大小在接收方处理范围内
  
• 未发送但总大小超过接收方处理范围
  

窗口右移

• 图示的发送窗口和收到ack报文中的window大小相关
  
• ack指针右移则可用窗口变大
  
• 发送seq指针右移则可用窗口变小
  

接收端的socket缓冲区，示意图如下：

• ACK包，ack=16,且（window=16）
  
• 已成功接收并确认的数据
  

1. ack指针右移则可用窗口还是右移
   

• 接收窗口是未收到数据但可以接收的数据
  

2. 可用窗口和应用程序获取数据的能力有关，如果应用程序一直不从socket缓冲区获取数据，则接收窗口也会变得越来越小
   
3. 滑动窗口并不是一成不变的。当接收方的应用读取数据的速度非常快的话，接收窗口可以很快的空缺出来。
   
4. 通过使用窗口可以起到流控的作用，可以减少不必要的丢包，并减少网络拥塞。
   

顺序的保证

如下图：

假设接收端未收到16，17的报文， 儿后面18-27的数据都收到了， 则并不会发ack给发送方 当发送端超时重传16，17之后，且接收端收到之后 则接收端返回ack=28的报文给发送端。

• ack指针只能右移，不能往回走
  
• 这样可以保证顺序交付
  

传输的总结

TCP的主要功能是防止包丢失，保证包到达的顺序。本节通过描述TCP的具体工作机制证明了TCP确实达到了这一目的。

高并发系统和关闭连接的设计

最后，我完成了TCP连接建立和传输的基本原理和过程，认为我可以松一口气。

关闭连接是TCP的一部分，但与TCP相比，这并不重要。

但最近发现，在生产活动中，大家也非常关注TCP四次挥手的过程。主要原因是系统并发量大。

TCP连接是衡量系统并发量的重要因素，如果关闭连接异常，必然会影响系统的运行。

对于连接对并发量的影响，首先可以分析开头提出的问题。

长连接 VS 短链接

• 短连接一般只会在 client/server间传递一次请求操作
  

1. 这时候双方任意都可以发起close操作
   
2. 短连接管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段。
   
3. 通常浏览器访问服务器的时候一般就是短连接。
   

• 长连接
  

1. Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。
   
2. 所以一条连接保持几天、几个月、几年或者更长时间都有可能，只要不出现异常情况或由用户（应用层）主动关闭。
   
3. 长连接可以省去较多的TCP建立和关闭的操作，减少网络阻塞的影响，
   
4. 减少CPU及内存的使用，因为不需要经常的建立及关闭连接。
   
5. 连接数过多时，影响服务端的性能和并发数量。
   

所以，长短连接怎么选择呢？

• 所以对于并发量大，请求频率低的，建议使用短连接。
  

1. 对于服务端来说，长连接会耗费服务端的资源
   
2. 如果有几十万，上百万的连接，服务端的压力会非常大，甚至会崩溃
   

• 对于并发量小，性能要求高的，建议选择长连接
  

1. 比如mysql连接池
   

TCP关闭连接

长短连接的选择如此重要，如果连接不能正确关闭，就会造成很大的麻烦。TCP设计了完善的关闭机制，关闭连接过程如下：

• 关闭连接发起方 发起第一个FIN,处于FIN-WAIT1
  
• 关闭连接被动方的内核代码回复ACK，此时还可以发送数据，处于Close-WAIT状态
  

1. 关闭连接被动方等待应用程序发送FIN，如果上层应用一直不发FIN，就还可以继续发送数据
   

• 关闭连接发起方收到ACK后处于FIN-WAIT2状态，还可以接收数据自己不再发送数据
  
• 关闭连接被动方直到应用程序发出FIN，处于LAST-ACK状态
  
• 关闭连接发起方收到FIN，会发送ACK，自己会处于TIME-WAIT状态，此时
  

1. 若是关闭连接被动方收到ack,就close连接
   
2. 若是是关闭连接被动方没收到ack,则会重传FIN
   

TIME-WAIT等多长时间

MSL是报文最大的生存时间。它是任何报文在网络上存在的最长时间。超过这个时间，报文将被丢弃，即MSL的两倍。TCP的TIME_WAIT状态也称为2MSL等待状态。

等待2MSL时间的主要目的是害怕对方没有收到最后一个ACK包，所以对方会在超时后重发第三次握手的FIN包。

若之前交互异常，收到重传的FIN最多使用2MSL，因此结论是等待2MSL的时间。

最后一个问题

有一次，同步数据的应用从一个服务器并发同步大量数据，这个过程比较缓慢，所以考虑如何加快同步。

• 首先查看网络连接，发现20个连接的连接池中有很多处于close_wait状态的连接。
  

通过以上分析，我们知道Close-WAIT是对方可能认为连接空闲时间太长而关闭的连接，但我在这里使用的连接池还没有发送FIN释放包。

可见看出，连接的数量并没有成为系统的瓶颈，我们可以继续增加并发线程的数量，以增加并发量。