文章目录
- 1.TCP的可靠性传输机制
- 2.TCP的传输优化机制 Nagle算法和延迟确认
- 3.Linux服务器常见网络内核参数配置
- 4. Linux服务器生产环境常见问题
1.TCP的可靠性传输机制
-
TCP的可靠性传输机制
- ACK机制
- 接收方收到TCP 数据包，要响应一个确认消息 acknowledgement，简称 ACK。
- 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的中文意思理解为存储）
| 描述 | |
|---|---|
| net.core.rmem_default | 默认的TCP数据接收窗口大小（字节）。 |
| net.core.rmem_max | 最大的TCP数据接收窗口（字节）。 |
| net.core.wmem_default | 默认的TCP数据发送窗口大小（字节）。 |
| net.core.wmem_max | 最大的TCP数据发送窗口（字节）。 |
| net.core.netdev_max_backlog | 当内核处理速度比网卡接收速度慢时，这部分多出来的包就会被保存在网卡的接收队列上，而该参数说明了这个队列的数量上限。 在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。 |
| net.core.somaxconn | 该参数定义了系统中每一个端口最大的监听队列的长度，是个全局参数。 该参数和net.ipv4.tcp_max_syn_backlog有关联，后者指的是还在三次握手的半连接的上限，该参数指的是处于ESTABLISHED的数量上限。当backlog大于net.core.somaxconn时，以net.core.somaxconn参数为准。 |
| net.ipv4.tcp_keepalive_time | TCP发送keepalive探测消息的间隔时间（秒），用于确认TCP连接是否有效。 |
| net.ipv4.tcp_syncookies | 默认值0表示关闭。 当该参数被设置为1，且SYN_RECV队列满了之后，内核会对SYN包的回复做一定的修改，即在响应的SYN+ACK包中，初始的序列号是由源IP+Port、目的IP+Port及时间这五个参数共同计算出一个值组成精心组装的TCP包。由于ACK包中确认的序列号并不是之前计算出的值，恶意攻击者无法响应或误判，而请求者会根据收到的SYN+ACK包做正确的响应。 启用net.ipv4.tcp_syncookies后，会忽略net.ipv4.tcp_max_syn_backlog。 |
| net.ipv4.tcp_tw_reuse | 表示是否允许将处于TIME-WAIT状态的Socket（TIME-WAIT的端口）用于新的TCP连接。 |
| net.ipv4.tcp_tw_recycle | 能够更快地回收TIME-WAIT套接字。 |
| net.ipv4.tcp_fin_timeout | 对于本端断开的Socket连接，TCP保持在FIN-WAIT-2状态的时间（秒）。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。 |
| net.ipv4.ip_local_port_range | 表示TCP/UDP协议允许使用的本地端口号。 |
| net.ipv4.tcp_max_syn_backlog | 该参数决定了系统中处于SYN_RECV状态的TCP连接数量。SYN_RECV状态指的是当系统收到SYN后，作为SYN+ACK响应后等待对方回复三次握手阶段中的最后一个ACK的阶段。对于还未获得对方确认的连接请求，可保存在队列中的最大数目。如果服务器经常出现过载，可以尝试增加这个数字。默认值大小会受实例内存的影响，默认值最大为2048。 |
| net.ipv4.tcp_max_tw_buckets | 该参数设置系统的TIME_WAIT的数量，如果超过默认值则会被立即清除 tcp_max_tw_buckets默认值大小会受实例内存的影响，最大值为262144。 |
| net.ipv4.tcp_synack_retries | 指明了处于SYN_RECV状态时重传SYN+ACK包的次数。 |
| net.ipv4.tcp_abort_on_overflow | 设置该参数为1时，当系统在短时间内收到了大量的请求，而相关的应用程序未能处理时，就会发送Reset包直接终止这些链接。建议通过优化应用程序的效率来提高处理能力，而不是简单地Reset。默认值为0。 |
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命令，使配置立刻生效
- 统计TCP连接数
（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
- 阿里云ECS默认是60秒，查看
- 执行
sysctl -p命令，使配置立刻生效
- 统计 TCP处于连接的数量
（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命令,调整参数
- 查看处于TIME_WAIT状态的连接数
#开启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进行扩容等手段优化系统性能
