【计算机网络】TCP的可靠性传输机制和常见配置讲解

1.TCP的可靠性传输机制

• TCP的可靠性传输机制

• ACK机制

• 接收方收到TCP 数据包，要响应一个确认消息 acknowledgement，简称 ACK。
• ACK有两个信息：期待要收到下一个数据包的编号和 当前接收方的接收窗口的剩余容量。

• 流量控制
  
• TCP连接的双方都有固定大小的buffer缓冲空间，接收端只允许发送端发送接收端缓冲区能接纳的数据。

当接收方处理不过来发送方的数据，会提示发送方降低发送的速率，防止包丢失。

流量控制是让发送方的发送速率不要过快，让接收方来得及接收。

利用可变大小的滑动窗口机制，在TCP连接上实现对发送方的流量控制。

TCP协议有个叫win，即16位的窗口大小。

接受方每次收到数据包，在发送确认报文的时候也会告诉发送方，自己的缓存区还有多少空余空间。

缓存区的空余空间，称为接收窗口大小。

拥塞控制（通过发送方来控制流量的一种方式，对整个网络 全局性考虑）

• 是一种自适应算法，利用多种机制，根据网络的状况自动调整发送端的发送速率，以避免网络拥塞

慢启动

发送端会以一个较小的窗口值开始发送，每收到一个ACK消息后，窗口值就会翻倍增加，直到窗口值达到最大值

如果不丢包，就加快发送速度；如果丢包，则降低发送速度

这样就可以慢慢地增加发送端的发送速率，避免突然发送大量数据造成网络拥塞。

快速重传

当发送端发送的数据报文没有在规定时间内收到ACK确认消息时，发送端就会认为该数据报文丢失

它会立即重发该数据报文，从而提高数据传输的效率。

拥塞避免

当收到三个重复的ACK消息时，发送端会认为网络出现拥塞，它会减少发送速率

降低发送端的数据量，从而减少网络的拥塞情况

重传机制

超时重传 Retransmission Timeout（时间驱动）

发送一个数据包后就开启计时器，在一定时间内如果没有得到发送的数据报的 ACK 报文，就重发数据，直到发送成功

配置超时重传时间就是 RTO，一般大于RTT**（Round-Trip Time，往返时间）**就行

缺点

报文丢失会等待一定的超时时候才重传，增加端到端的时延

快速重传 Fast Retransmit （数据驱动）

• TCP 协议给每个包编号seq（sequence number），第1个包的编号是一个随机数
• 接收方收到多个包后，方便组装还原，如果发生丢包，可以知道丢失的是哪一个包

例子

接收方收到了6号包，没有收到14号包，ACK 就会记录，期待收到14号包

过了一段时间14号包还是没收到，但是收到24号包，ACK 里面的编号不会变化，总是响应期待14号包

如果发送方收到三个连续的重复 ACK 或者 超时还没有收到任何 ACK，会确认14号包丢包，再次重发这个包。

重传成功后，接收方会返回正常最新的ACK

缺点

快速重传 解决了超时时间的问题，但存在重传的时候，是重传之前的⼀个，还是重传所有的问题

根据不同的实现，两种重传都可能，也有更多机制SACK和D-SACK

2.TCP的传输优化机制 Nagle算法和延迟确认

• Nagle 算法

• 是TCP协议的一种流量控制算法，它的目的是为了减少网络中的小数据包的数量，提高网络的效率
  

• TCP/IP协议中，无论发送多少数据都要在数据前面加上协议头，对方接收到数据也需要发送ACK表示确认
  
• 为了提高利用网络带宽，TCP希望尽可能的发送足够大的数据，诞生了Nagle算法
  
• 任意时刻，最多只能有一个未被确认的小段。
• “小段” 指的是小于MSS尺寸的数据块
• “未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认。
• 
  

TCP协议默认开启了Nagle算法，默认TCP_NODELAY选项为false

做法

一个 TCP 连接上最多只能有一个未被ACK确认的数据包，在收到确认信息之前，不再发送后续数据包

在上一个数据包未到达目的地前，即未收到 ack 前，将多个数据包组合成一个数据包发送

当上一个小分组的 ack 收到后，TCP 就将收集的小分组合并成一个大分组发送出去，以减少小包的发送数量

上面条件都没满足，发生了超时（一般为200ms），也会立即发送

禁用Nagle算法

默认开启的，比较适用于发送方发送大批量的小数据，并且接收方作出及时回应的场合，降低包的传输个数

如果业务是实时的发送数据并需要及时获取响应，则不适合开启Nagle算法

延迟要求比较严格的地方，网络比较通畅 或 内部网的情况下，应该关闭nagle算法

游戏类服务器开发也会禁用Nagle

linux提供了TCP_NODELAY的选项来禁用Nagle算法

禁止Nagle算法，每一次send 都会组一个包进行发送，hello被分成5个小包分别发送

不用等待ACK，可以连续发送数据包

• netty框架里面 .childOption(ChannelOption.TCP_NODELAY, true) 禁用
  

• 延迟确认
  
• 
  

TCP报文中假如没携带数据，只是发ACK, 但有 40 个字节的 IP 头 和 TCP 头，⽹络效率也是很低的，就产⽣出 TCP 延迟确认

做法

当 TCP 收到一个数据包时，它不会立即发出确认，而是等待一段时间 ，Linux默认延时时间为 40ms

如果在这段时间内有响应数据要发送时，ACK会随着响应数据⼀起发送给对⽅；如果期间没数据发送则40ms后才ACK

TCP 就将这两个数据包一起确认，从而减少了确认报文的数量

这种策略可以有效地减少网络中的报文交换，从而提高网络效率

注意

Nagle 算法和延迟确认不能一起使用

Nagle 算法 是用于延迟发送数据包，延迟确认 是用于 延迟接收数据包

两个凑在一起就会造成更大的延迟，会产生性能问题

3.Linux服务器常见网络内核参数配置

• 查看内核参数

• 执行sysctl -a命令，查看当前系统中生效的所有参数
  
• sysctl -a 显示参数特别多，常规加 grep 过滤下 sysctl -a | grep net.ipv4.tcp
  
• 
  

两种修改Linux实例内核参数

• 方法一：通过/proc/sys/目录查看和修改内核参数

• /proc/sys/目录是Linux内核在启动后生成的伪目录，
• 目录下的net文件夹中存放了当前系统中开启的所有内核参数，目录树结构与参数的完整名称相关
• 比如 net.ipv4.tcp_tw_recycle，它对应的文件是/proc/sys/net/ipv4/tcp_tw_recycle文件，文件的内容就是参数值

• 查看内核参数 net.ipv4.tcp_tw_recycle 的值，命令 cat /proc/sys/net/ipv4/tcp_tw_recycle
• 修改内核参数 net.ipv4.tcp_tw_recycle 的值，命令 echo "0" > /proc/sys/net/ipv4/tcp_tw_recycle

• 方法二：通过sysctl.conf文件查看和修改内核参数

• 修改 /etc/sysctl.conf 文件中的参数: vim /etc/sysctl.conf
• 执行命令使配置生效. /sbin/sysctl -p

• Linux文件句柄数限制优化

• 啥是Linux文件句柄

* 在linux系统设计里面遵循一切都是文件的原则，即磁盘文件、目录、网络套接字、磁盘、管道等
* 所有这些都是文件，进行打开的时候会返回一个fd，即是文件句柄
* 如果频繁的打开文件，或者打开网络套接字而忘记释放就会有句柄泄露的现象
* 在linux系统中对进程可以调用的文件句柄数进行了限制，在默认情况下每个进程可以调用的最大句柄数是1024个
* 如果超过了这个限制进程将无法获取新的句柄，而从导致不能打开新的文件或者网络套接字，对于线上服务器即会出现服务被拒绝的情况。
* 遇到文件句柄达到上限时，会碰到`Too many open files`或者 `Socket/File: Can’t open so many files`等错误

修改方式

• 局部文件句柄数（单个进程最大打开文件数）

• ulimit -n 一个进程最大打开的文件数 fd, 不同系统有不同的默认值
  
• 编辑 vim /etc/security/limits.conf 文件末尾增加
  

• hard nofile 100000
  
• soft nofile 100000
  

• 其中* 代表所有用户，100000代表修改的值，修改以后需要重新登录才能生效
  

• 全局文件句柄数（所有进程所能够创建的文件句柄数）
  

• 查看全局文件句柄数：cat /proc/sys/fs/file-max
• 编辑 /etc/sysctl.conf，在文件末尾加上：fs.file-max=10000000000
• 使配置文件生效：sysctl -p

• 注意

• 一般修改进程级的最大打开文件句柄数即可（很多系统默认1024，有点小）
• 一般不需要调整系统级的最大数，局部文件句柄数一定不要超过全局文件句柄数

• Linux常见的网络内核参数说明（backlog的中文意思理解为存储）
• 

4. Linux服务器生产环境常见问题

（1）生产环境Linux服务问题一

• 现象

• 业务突然访问不了，诊断出是网络方向的问题
• Linux实例的/var/log/messages日志信息全是类似“kernel: TCP: time wait bucket table overflow”的报错信息

• 提示“time wait bucket table”溢出

• 原因分析
  
• 参数net.ipv4.tcp_max_tw_buckets可以调整内核中管理TIME_WAIT状态的数量
• 当实例中处于TIME_WAIT状态，需要转换为TIME_WAIT状态的连接数之和超过net.ipv4.tcp_max_tw_buckets参数值
• messages日志中将报“time wait bucket table” 错误，同时内核关闭超出参数值的部分TCP连接
• 根据实际情况适当调高net.ipv4.tcp_max_tw_buckets参数，同时从业务层面去改进TCP连接。
• 解决方案

统计TCP连接数 netstat -atnp |grep tcp |wc -l ,如果确认连接使用很高，容易超出限制

vim /etc/sysctl.conf, 增加net.ipv4.tcp_max_tw_buckets参数值的大小

执行sysctl -p命令，使配置立刻生效

2）生产环境Linux服务问题二

• 现象

• 业务突然访问不了，诊断出是网络方向的问题
• Linux实例中FIN_WAIT2状态的TCP链接过多
• 原因分析

• 在HTTP服务中，Server由于某种原因会主动关闭连接，作为主动关闭连接的Server就会进入FIN_WAIT2状态。
• 如果Client不关闭，FIN_WAIT2状态将保持到系统重启，越来越多的FIN_WAIT2状态会致使内核Crash。
• 建议调小net.ipv4.tcp_fin_timeout参数的值，加快系统关闭处于FIN_WAIT2状态的TCP连接

TCP连接处于FIN_WAIT2状态，下一步会进入TIME_WAIT状态

解决方案

统计 TCP处于连接的数量 netstat -atn|grep FIN_WAIT2|wc -l

执行vim /etc/sysctl.conf命令,调整 net.ipv4.tcp_fin_timeout = 30

阿里云ECS默认是60秒，查看 sysctl -a | grep net.ipv4.tcp_fin_timeout

执行sysctl -p命令，使配置立刻生效

（3）生产环境Linux服务问题三

• 现象

• 业务突然访问不了，诊断出是网络方向的问题
• Linux实例中出现大量CLOSE_WAIT状态的TCP连接

原因分析

根据机器的业务量判断CLOSE_WAIT数量是否超出了正常的范围

TCP连接断开时需要进行四次挥手，TCP连接的两端都可以发起关闭连接的请求

如果对端发起了关闭连接，但本地没有关闭连接，那么该连接就会处于CLOSE_WAIT状态

虽然该连接已经处于半开状态，但是已经无法和对端通信，需要及时的释放该连接

• 建议从业务层面及时判断某个连接是否已经被对端关闭，即在程序逻辑中对连接及时关闭，并进行检查

• 解决方案
• 编程语言中对应的读、写函数一般包含了检测CLOSE_WAIT状态的TCP连接功能，

查看处于CLOSE_WAIT状态的连接数 netstat -atnp|grep CLOSE_WAIT|wc -l

比如是java业务，检查相关IO操作是否有正常关闭

通过read方法来判断I/O ，当read方法返回-1时，则表示已经到达末尾

通过close方法关闭该连接

（4）生产环境Linux服务器问题四

• 现象

• 业务突然访问不了，诊断出是网络方向的问题
• 存在大量处于TIME_WAIT状态的连接

• 原因分析
  
• 主动发起关闭的一端，在发送最后一个ACK之后会进入time_wait的状态
• 该发送方会保持2MSL时间之后才会回到初始状态，MSL值是数据包在网络中的最大生存时间

• 处于这个状态的TCP连接在2MSL等待期间，定义这个连接的四元组 客户端IP和端口，服务端IP和端口号 不能被使用

• 解决方案
  
• 查看处于TIME_WAIT状态的连接数 netstat -atnp|grep TIME_WAIT|wc -l
• 执行vim /etc/sysctl.conf命令,调整参数

#开启SYN的cookies，当出现SYN等待队列溢出时，启用cookies进行处理
net.ipv4.tcp_syncookies = 1 
#允许将TIME-WAIT的socket重新用于新的TCP连接
net.ipv4.tcp_tw_reuse = 1 
#开启TCP连接中TIME-WAIT的sockets快速回收功能
net.ipv4.tcp_tw_recycle = 1
#如果socket由服务端要求关闭，则该参数决定了保持在FIN-WAIT-2状态的时间。
net.ipv4.tcp_fin_timeout = 30

• 执行sysctl -p命令，使配置立刻生效
  启用cookies进行处理
  net.ipv4.tcp_syncookies = 1

#允许将TIME-WAIT的socket重新用于新的TCP连接

net.ipv4.tcp_tw_reuse = 1

#开启TCP连接中TIME-WAIT的sockets快速回收功能

net.ipv4.tcp_tw_recycle = 1

#如果socket由服务端要求关闭，则该参数决定了保持在FIN-WAIT-2状态的时间。

net.ipv4.tcp_fin_timeout = 30

* 执行`sysctl -p`命令，使配置立刻生效
* 除了的减少TIME_WAIT状态的连接，也可以通过扩大端口范围和对TIME_WAIT的bucket进行扩容等手段优化系统性能