Linux 网络传输学习笔记
这篇是混合《Linux性能优化实战》以及 《Wireshark网络分析就这么简单》的一些关于Linux 网络的学习概念和知识点笔记 ，主要记录网络传输流程以及对于TCP和UDP传输的一些影响因素
Linux 网络传输流程
借用一张倪朋飞先生的《Linux性能优化实战》课程中的图片
接收流程
- 网卡收到网络数据包，加入到收包队列
- 网卡将网络包写入DMA缓冲区，通知中断处理程序
- CPU硬中断锁定DMA缓冲区，将网络包拷贝到内核数据结构 sk_buff 缓冲区，清空并解锁当前DMA缓冲区
- 通知软中断，通知内核收到了新的网络帧，内核协议栈从缓冲区中取出网络帧
- 在链路层检查报文合法性，找出上层协议类型（ipv4/ipv6），去掉帧头，帧尾，交给网络层
- 网络层取出IP头，判断网络走向
- 本机的：取出上层协议（TCP/UDP），去掉IP头，交给传输层
- 非本机：转发
- 传输层取出TCP或者UDP头，根据 < 源 IP、源端口、目的 IP、目的端口 > 四元组作为标识，找出对应的 Socket，并把数据拷贝到 Socket 的接收缓存中
- 应用程序就可以使用 Socket 接口，读取到新接收到的数据
发送流程
- 应用程序通过调用 Socket API（比如 sendmsg，系统调用）发送网络包，这是一个系统调用，所以会陷入到内核态的套接字层中，套接字层会把数据包放到 Socket 发送缓冲区中
- 网络协议栈从 Socket 发送缓冲区中，取出数据包
- 传输层依据协议增加TCP或UDP头
- 网络层增加IP头，通过路由寻找下一条IP，并按照MTU大小分片
- 分片后的网络包再送到网络接口层，进行物理寻址，找下一条MAC地址，增加帧头和帧尾
- 软中断通知驱动程序，发包队列有新的网络帧需要发送
- 驱动通过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或者收到确认后发送
与延迟确认的区别
- Nagle算法没有明显的时间规律
- 凑满一个MSS或者收到确认后发送
- 如果是收到确认包立即发送，就可以判断是Nagle了
关于拥塞
- 刚开始建立连接时，拥塞窗口都设定的比较小
- 在慢启动阶段，拥塞会指数型增长，直到碰到临界窗口值
- 在临界窗口值往上，就会降低增长速度，避免触碰网络拥塞
- 碰到拥塞后，会有超时丢包现象，该阶段没有数据传输，称为超时重传时间（RTO）
- 超时重传后，会重新进入慢启动阶段，并调整临界值（所以超时重传极大影响网络性能）
- Richard Stevens：临界值设为上次发生拥塞的发送窗口的一半
- 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 的配置方式
网卡》属性》配置》高级》大量传输减负