背景

北方刮大风的那个周五
因为担心电驴被吹倒,六点就赶紧骑车去了.
电梯里同事打电话问一个问题.
在客户服务器上面使用postman和产品访问公司云服务上面的OCR服务有问题
没有图片就正常, 有图片就不通.
当时我第一反应是图片太大,时间长.
但是又告知刚重启之后一会儿是可以的.
但是运行一段时间就不行了.
当时也没考虑太多, 只是随口说了一个最大包大小. 
因为我记得复杂互联网情况下, MTU差异有概率出现丢包的情况. 
但是转念一想也不应该, 因为大多数设备都可以实现根据MTU大小实现分包的.
所以就认为是自己想多了.
下周二, 客户反馈找到问题原因, 的确是默认的包大小跟OCR服务器有差异
从 1460 下降 到 1430 应该就可以完美规避这个问题了. 
不过我一直很困惑, 并且也有一个理解不了的地方.
所以想总结一下. 因为问题链我没参与线上分析, 所以可能有失偏颇

部分概念

MTU 和 MSS 的定义与区别

MTU（Maximum Transmission Unit）

• 定义：MTU 是最大传输单元，指网络链路层能够传输的最大数据帧大小，以字节为单位。
• 作用：MTU 限制了单个数据包的大小。如果数据包的大小超过 MTU，IP 层会将数据包分割成多个较小的分片进行传输。
• 计算：MTU 包括数据链路层的头部和尾部，以及上层协议（如 IP）的头部。
• 常见值：以太网中通常为 1500 字节。

MSS（Maximum Segment Size）

• 定义：MSS 是最大分段大小，是 TCP 协议中的一个参数，表示 TCP 数据段中数据部分的最大长度，不包括 TCP 头部和 IP 头部。
• 作用：MSS 用于限制每个 TCP 数据段的最大数据负载量，以避免数据包过大导致 IP 分片。
• 计算：在以太网环境下，MSS = MTU - IP 头部长度 - TCP 头部长度。
  通常情况下，MSS = 1500 - 20 - 20 = 1460 字节。

MTU 与 MSS 的区别

作用层次不同

• MTU：数据链路层的概念，限制单个数据包的大小。
• MSS：传输层（TCP）的概念，限制 TCP 数据段的数据部分大小。

所涉及的内容不同

• MTU：包括数据链路层头部、IP 头部和 TCP 数据部分。
• MSS：只包括 TCP 数据部分。

确定方式不同

• MTU：由底层网络技术和设备配置决定。
• MSS：在 TCP 连接建立时通过协商确定，取双方中较小的值。

适用范围不同

• MTU：影响整个数据包的大小，对底层网络通信起作用。
• MSS：主要影响 TCP 数据段的大小，对应用层的数据传输起作用。

实际应用

• 性能优化：通过合理设置 MSS，可以减少 TCP 数据包的分片，提高传输效率。
• 故障排除：了解 MTU 和 MSS 的概念有助于定位网络问题，例如 MTU 过小可能导致数据包分片或丢失。

总结

MTU 和 MSS 都是网络通信中重要的参数，但它们在网络层次和作用上有所不同。  
MTU 是数据链路层的概念，限制单个数据包的大小；  
MSS 是 TCP 协议中的参数，限制 TCP 数据段的数据部分大小。  
了解它们的区别和关系，有助于优化网络性能和解决网络问题。

之前学习到的资料

1. 修改MTU大小的方法(2022.12)
https://www.jianshu.com/p/399049fa1648
https://www.jianshu.com/p/cb3bd1e34f3a
Linux: 
nmcli con modify ens33 802-3-ethernet.mtu 16110
nmcli con up ens33
Windows:
netsh  interface  ipv4 set   subinterface  "VMware Network Adapter VMnet8"  mtu=1000000
netsh  interface  ipv4 show   subinterface  "VMware Network Adapter VMnet8"

2. https://www.cnblogs.com/zisefeizhu/p/16611626.html
k8s-mtu设置不当引发的线上故障

# 查看物理节点mtu：
netstat -i
# 发现其物理节点mtu值为1450

# 查看calico配置的mtu参数
kubectl get configmap/cali-config -n kube-system | grep "veth_mtu"
# 发现其mtu值也为1450
此时问题原因找到，calico启用tunnel模式，因此经过tunnel会封装一个新的20字节的ip包头，
所以当发送大量数据时，calico生成的1450大小的数据包再加上20大小的ip包头为1470字节的包。
本地网卡转发calico通讯数据包1470，将失败。

可以通过两种方式解决此问题
1、更改物理节点mtu值大小。
2.修改calicomtu值大小为 物理节点mtu-20。

推荐使用第二种
kubectl patch configmap/calico-config -n kube-system --type merge -p '{"data":{"veth_mtu": "1430"}}
根据实际需要调整所在k8s node节点的 eth0或tunl0的mtu，需确保tunl0的mtu比eth0的mtu少20。

3. https://www.cnblogs.com/jinanxiaolaohu/p/14261266.html
友商的给设置:  2021年自己整理的
net.ipv4.ip_local_port_range = 9000 65500
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_orphan_retries = 3
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_max_syn_backlog = 8192
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864


net.ipv4.tcp_mtu_probing = 1
net.core.somaxconn = 512
net.ipv4.tcp_retries2 = 5

一些理解与总结

IP_header和TCP_header 都是overhead 
局域网内都是巨型帧, 协议开销小,速度快.
互联网,因为各式各样的设备. 没办法将MTU设置到很大
所以他的payload 其实占比是比较小的. 

现在一些新的协议 像是IB的 NvLINK的都是高级协议
损耗都比TCP/IP要小很多. 

关于为什么开机之后没问题.
我怀疑系统应该是有开PMTU?
PMTU（Path Maximum Transmission Unit）
定义：PMTU 是路径最大传输单元，
指从源主机到目的主机之间路径上能够无分片传输的最大数据包大小。
作用：通过动态发现路径上的最小 MTU，PMTU 机制可以避免 IP 分片，
从而减少网络延迟和丢包率，提高网络传输效率。

综合一下:
刚开机因为有PMTU, 所以一开始的包都比较小.
所以可以正常返回
类似于Windows的慢启动之后, 包可以扩展
不知道是基于什么原理. 系统将MTU设置到了比较大的值
然后都没有返回. 系统却没有下降MTU
导致bug? 
猜测应该是协议除了问题或者是阿里云设置了不能DF?