Linux 网络传输学习笔记

这篇是混合《Linux性能优化实战》以及 《Wireshark网络分析就这么简单》的一些关于Linux 网络的学习概念和知识点笔记?，主要记录网络传输流程以及对于TCP和UDP传输的一些影响因素

Linux 网络传输流程

借用一张倪朋飞先生的《Linux性能优化实战》课程中的图片

接收流程

1. 网卡收到网络数据包，加入到收包队列
2. 网卡将网络包写入DMA缓冲区，通知中断处理程序
3. CPU硬中断锁定DMA缓冲区，将网络包拷贝到内核数据结构 sk_buff 缓冲区，清空并解锁当前DMA缓冲区
4. 通知软中断，通知内核收到了新的网络帧，内核协议栈从缓冲区中取出网络帧
5. 在链路层检查报文合法性，找出上层协议类型（ipv4/ipv6），去掉帧头，帧尾，交给网络层
6. 网络层取出IP头，判断网络走向
   1. 本机的：取出上层协议（TCP/UDP），去掉IP头，交给传输层
   2. 非本机：转发
7. 传输层取出TCP或者UDP头，根据 < 源 IP、源端口、目的 IP、目的端口 > 四元组作为标识，找出对应的 Socket，并把数据拷贝到 Socket 的接收缓存中
8. 应用程序就可以使用 Socket 接口，读取到新接收到的数据

发送流程

1. 应用程序通过调用 Socket API（比如 sendmsg，系统调用）发送网络包，这是一个系统调用，所以会陷入到内核态的套接字层中，套接字层会把数据包放到 Socket 发送缓冲区中
2. 网络协议栈从 Socket 发送缓冲区中，取出数据包
3. 传输层依据协议增加TCP或UDP头
4. 网络层增加IP头，通过路由寻找下一条IP，并按照MTU大小分片
5. 分片后的网络包再送到网络接口层，进行物理寻址，找下一条MAC地址，增加帧头和帧尾
6. 软中断通知驱动程序，发包队列有新的网络帧需要发送
7. 驱动通过DMA，从发送队列读取网络帧，并通过物理网卡发送出去

---

TCP的一些网络影响因素

一些小概念

接收窗口（Receiver Window）

接收窗口表示接收方TCP缓冲区可容纳的数据量。

发送方不能发送超过接收窗口大小的数据，以确保接收方有足够的时间处理数据。接收窗口大小由接收方TCP发送给发送方的窗口大小更新。

发送窗口（Sender Window）

发送窗口表示发送方TCP缓冲区可容纳的数据量。

接收方不能发送超过发送窗口大小的数据，以确保发送方有足够的时间发送数据。发送窗口大小由发送方TCP发送给接收方的窗口大小更新。

一般由接收方的接收窗口和发送方的发送窗口的较小值决定，另外网络的影响也会导致发送窗口变化

MSS 最大分段大小（Maximum Segment Size）

MSS表示TCP报文段的最大长度。

每个TCP连接都有一个MSS值，它取决于网络的最大传输单元（MTU）。发送方将数据分割为适当大小的报文段，以确保数据可以在TCP连接上可靠传输。

MTU 最大传输单元（Maximum Transmission Unit）

MTU表示网络中每个数据包的最大大小。

MTU值取决于所使用的网络和协议。在TCP/IP协议栈中，MTU通常等于接收窗口大小，以确保TCP数据可以在单个数据包中传输。

延迟确认

描述

在发送包时，接收方延迟确认，可以实现多个包一块确认，减少确认包的数量，减轻网络负担

缺点

• 在丢包较多的情况下，会导致大量的超时重传，极大的影响网络性能，建议开启SACK提供重传效率
• 接收窗口很小时，由于运输车很小，还要延迟确认，就会导致大量堆积，应该立即配送

过滤

wireshark 的过滤条件

tcp.analysis.ack_rtt >0.2 && tcp.len==0 获取超过200毫秒的确认包

Nagle算法

描述

在发送的数据还未被确认前，新的小包将会被收集，凑满一个MSS或者收到确认后发送

与延迟确认的区别

1. Nagle算法没有明显的时间规律
2. 凑满一个MSS或者收到确认后发送
3. 如果是收到确认包立即发送，就可以判断是Nagle了

关于拥塞

1. 刚开始建立连接时，拥塞窗口都设定的比较小
2. 在慢启动阶段，拥塞会指数型增长，直到碰到临界窗口值
3. 在临界窗口值往上，就会降低增长速度，避免触碰网络拥塞
4. 碰到拥塞后，会有超时丢包现象，该阶段没有数据传输，称为超时重传时间（RTO）
5. 超时重传后，会重新进入慢启动阶段，并调整临界值（所以超时重传极大影响网络性能）
   1. Richard Stevens：临界值设为上次发生拥塞的发送窗口的一半
   2. RFC5681 ：发生拥塞时没被确认的数据量的一半，并不能小于2个MSS

超时重传

拥塞发生后，发送方发现发出去的包不像往常一样得到确认了，不过考虑收不到确认包可能是网络延迟导致，所以等待一段时间再判断，迟迟未收到就认定丢包了，只能重传，称为超时重传。

发出原始包到重传这个包的这段时间称为超时重传时间（RTO）。

快速重传

当发送方接受到3个或以上重复确认（Dup ACK）时，就意识到相应的包丢了，从而立即重传这些包

一些优化建议

• 没有拥塞时，发送窗口越大，性能越好。所以在没有带宽限制的时候，应该尽量增大接收窗口
• 如果经常发生拥塞，限制发送窗口能提高网络性能，因为重传对性能的影响极大
• 超时重传对性能影响最大，因为有一段RTO重传时间没有任何数据传输，并且会将拥塞窗口设定为1MSS，所以要尽量避免超时重传
• 快速重传对性能影响相对较小，因为没有等待时间，并且拥塞窗口减小幅度不大
• SACK和NewReno有利于提高重传效率，提高传输效率
  • 早期TCP （丢包后面的包都重传，效率极低）
  • NewReno （接收方推理出丢掉的包，一个一个请求重传）
  • SACK （将目前接收到的包反馈给发送方，ACK提示丢掉的包）
    • 例如：SACK=9748-9912 ACK=8820 表示8820到9748之间的包未收到
• 丢包对极小文件的影响比大文件严重，因为读写一个小文件的包数量很少，所以丢包可能也触发不到3个Dup ACK，只能等待超时重传，而大文件更容易触发快速重传

---

MTU 影响判定

1、如果是防火墙阻止会丢包，但是在三次握手时就会丢弃，而不是握手后访问丢弃

2、网络拥塞会丢包，但一段时间后会恢复

3、只丢大包不丢小包，可能是MTU导致的，特别是1460字节的临界值时

4、ping serverip -l 1472 -f 可以测试MTU是否是1500字节

如果报错说被丢弃，可能链路上存在较小的MTU，考虑调整MTU

---

关于UDP

1、UDP不管双方的MTU大小，发送方负责分片，接收方负责将分片组装，会消耗资源和影响性能

2、UDP没有重传机制，丢包由应用层处理，丢了就要全部重传，而TCP仅需重传丢的包

3、分片机制不安全，容易被攻击，如果分片的每个包都有More fragment的flag，1表示还有分片，0表示没有；所以，如果被大量发送flag为1的UDP包，就可能导致资源耗尽

---

LSO（Large Segment Offload 大量传输减负）

描述

为缓解CPU压力，把部分工作offload交给网卡处理

工作方式

TCP层将大于MSS的数据直接传给网卡，网卡负责分段处理

传统方式

TCP层根据MSS分段（CPU负责），再交给网卡处理

位置

Windows 的配置方式

网卡》属性》配置》高级》大量传输减负?