【计算机网络】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进行扩容等手段优化系统性能