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

Posted 2023-04-01 司腾

我们在学校学习网络以及网络传输层的时候，大概总是会觉得枯燥难懂。 但是其实在生产活动中，这个是很常遇见的问题，如果不懂，大概就会比较懵逼。

生产环境遇到的问题

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

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

传输层

要完全说清楚那些问题，需要对传输层的协议有非常深刻的认识。 网络层或许离软件开发人员还有点遥远，但是传输层特别是用的广泛的TCP却和我们的工作息息相关。

传输层的目的

• 从上到下依次包括 应用层、传输层、网络层、链路层、物理层。

• 应用层就是对应不同的数据

• 通过网络层，包已经能够正确的被路由到对应的主机

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

区别不同的应用-UDP

传输层最开始引入了端口的设计来区分不同的应用。

• 每个应用对应一个端口，端口信息也封装到包里面，这样就能识别数据包是属于哪个应用的。
• 作为传输层的一种简单的协议，UDP的报文格式也很简单。

• UDP报头几乎只加入了端口的信息
• 端口是一个16位的数字

保证传输的质量-TCP

UDP没有保证数据的准确传输，没有质量保证，万一包丢了，网络层是不会重传的。所以传输层还设计了一个新的协议TCP，除了端口映射，在应用层和网络层之间还加入了一些处理的机制，来保证传输的质量。

传输的质量对于应用来说其实就两点：

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

• C1、C2表示和app1有数据交互的两个客户端。

• 假设app1给C2发送数据，那么app1的传输层要保证所有的数据都发送到了C2,确保没有丢包事件的发生

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

• 假设C1给app1发送数据，那么发送的数据需要按序正确的让app1接收

重点：TCP的具体工作机制

TCP要做什么

根据上面的描述，TCP主要的要做两件事情：

• 防止丢包
  • 丢包重传
    • 正常情况下，收到包就发ack信号给发送者
    • 超时未收到则使用超时重传机制
  • 减少丢包
    • 告诉我你的窗口：感受对端的处理能力
    • 丢包的原因以及优化：感受网络的拥塞，控制传输的速率
• 保证包到达的顺序
  • 使用序列号：保证数据包按正确的顺序交付

基本的试探-建立连接

就像上面提到的那样，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状态
  • 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:*               LISTEN      26523/java     
复制代码

• *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端口

  • 本地 9.13.73.14:38604 和远程9.13.39.104:3306建立了连接

  • 本地9.13.73.14:32926和远程 9.21.210.17:8080 建立了连接

回答问题3

问题3：系统不可达，80端口连不通了，可是本地查看80端口是正常的，这是为什么？

有一次我们的服务不可达了，也就是80端口连不通，但是登录到机器上面发送80端口还是正常的listen状态，却发现有很多连接处于Sync-RCVD状态，查看日志发现系统Out of Memory过，完全有理由怀疑是因为内存原因导致服务建立连接的过程出现了异常。

所以这个时候虽然80端口的LISTEN状态是正常的，外部却不能正常连接。

TCP报文格式和信息交换

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

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

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

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

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

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

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

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

• 接收到的SYN包的窗口大小代表对方的接收窗口的大小
• RST标记位为1: 可以用于强制断开连接
• PSH标记位为1： 告知对方这些数据包收到后应该马上交给上层的应用
• 选项中的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）
• 已成功接收并确认的数据
  • ack指针右移则可用窗口还是右移
• 接收窗口是未收到数据但可以接收的数据
  • 可用窗口和应用程序获取数据的能力有关，如果应用程序一直不从socket缓冲区获取数据，则接收窗口也会变得越来越小
  • 滑动窗口并不是一成不变的。当接收方的应用读取数据的速度非常快的话，接收窗口可以很快的空缺出来。
  • 通过使用窗口可以起到流控的作用，可以减少不必要的丢包，并减少网络拥塞。

顺序的保证

如图：

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

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

传输的总结

我们之前讲到TCP的主要作用就是防止丢包和保证包到达的顺序，这个小节通过描述TCP的具体工作机制证明了TCP确实达到了这样的目的。

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

终于讲完了TCP连接的建立和传输的基本原理和过程，以为可以松一口气。

关闭连接是TCP的一环，但是比起TCP要达到的目的来说，这个并不重要。

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

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

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

问题1：长短连接的选择？

长连接 VS 短链接

• 短连接一般只会在 client/server间传递一次请求操作
  • 这时候双方任意都可以发起close操作
  • 短连接管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段。
  • 通常浏览器访问服务器的时候一般就是短连接。
• 长连接
  • Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。
  • 所以一条连接保持几天、几个月、几年或者更长时间都有可能，只要不出现异常情况或由用户（应用层）主动关闭。
  • 长连接可以省去较多的TCP建立和关闭的操作，减少网络阻塞的影响，
  • 减少CPU及内存的使用，因为不需要经常的建立及关闭连接。
  • 连接数过多时，影响服务端的性能和并发数量。

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

• 所以对于并发量大，请求频率低的，建议使用短连接。
  • 对于服务端来说，长连接会耗费服务端的资源
  • 如果有几十万，上百万的连接，服务端的压力会非常大，甚至会崩溃
• 对于并发量小，性能要求高的，建议选择长连接
  • 比如mysql连接池

TCP关闭连接

长短连接的选择都那么重要了，那如果不能正确的关闭连接将引起非常大的麻烦。 TCP设计了完善的关闭连接的机制，关闭连接的交互过程如下：

• 关闭连接发起方 发起第一个FIN,处于FIN-WAIT1
• 关闭连接被动方的内核代码回复ACK，此时还可以发送数据，处于Close-WAIT状态
  • 关闭连接被动方等待应用程序发送FIN，如果上层应用一直不发FIN，就还可以继续发送数据
• 关闭连接发起方收到ACK后处于FIN-WAIT2状态，还可以接收数据自己不再发送数据
• 关闭连接被动方直到应用程序发出FIN，处于LAST-ACK状态
• 关闭连接发起方收到FIN，会发送ACK，自己会处于TIME-WAIT状态，此时
  • 若是关闭连接被动方收到ack,就close连接
  • 若是是关闭连接被动方没收到ack,则会重传FIN

TIME-WAIT等多长时间

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

等待2MSL时间主要目的是怕最后一个ACK包对方没收到，那么对方在超时后将重发第三次握手的FIN包.

如果之前交互异常了，收到重传的FIN最多用2MSL，所以结论是等待2MSL的时间

最后一个问题

问题4： 客户端连接池很多处于CLOSE-WAIT？

有一次，有一个同步数据的应用从一个服务器并发同步大量数据，这个过程比较慢，于是想着怎么去加快同步的速度。

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

通过上面的分析我们知道，Close-WAIT是对方可能认为连接空闲时间太长关闭了连接，不过我这边应用的连接池还没有发FIN释放包。

可见连接的数量没有成为系统瓶颈，为了提高并发量，我们还可以继续增大并发的线程数。

总结

本文通过详细描述传输层和TCP协议回答了生产遇到的TCP相关的问题，希望对你也有所帮助。