数据包的发送流程
4.21 用了 TCP 协议，数据一定不会丢吗？
数据包的发送流程
首先，我们两个 手机的绿皮聊天软件客⼾端，要通信，中间会通过它们家服务器。大概⻓这样。
但为了 简化模型，我们把中间的服务器给省略掉，假设这是个端到端的通信。且为了 保证消息的
可靠性，我们盲猜它们之间用的是TCP 协议进行通信。
为了 发送数据包，两端首先会通过三次握手，建立TCP 连接。
一个数据包，从聊天框里发出，消息会从聊天软件所在的用⼾空间拷⻉到内核空间的发送缓冲区（send buffer ），数据包就这样顺着传输层、网络层，进入到数据链路层，在这里数据包会经过流 控（qdisc ），再通过RingBuffer 发到物理层的网卡。数据就这样顺着网卡发到了纷繁 复杂的网络世
界里。这里头数据会经过n多个路由器和交换机之间的跳转，最后到达目的机器的网卡处。
此时目的机器的网卡会通知DMA 将数据包信息放到 RingBuffer 中，再触发一个硬中断给 CPU ，
CPU 触发软中断让 ksoftirqd 去 RingBuffer 收包，于是一个数据包就这样顺着物理层，数据链
路层，网络层，传输层，最后从内核空间拷⻉到用⼾空间里的聊天软件里。
画了那么大一张图，只水了200 字做解释，我多少是有些心痛的。
到这里，抛开一些细节，大家大概知道了一个数据包从发送到接收的宏观过程。
可以看到，这上面全是密密 麻麻的名词。
整条链路下来，有不少地方可能会发生丢包。
但为了不 让大家保持蹲姿太久影响身体健康，我这边 只重点讲下几个常⻅容易发生丢包的场景。
建立连接时丢包
TCP 协议会通过三次握手建立连接。大概⻓下面这样。
在服务端，第一次握手之后，会先建立个半连接，然后再发出第二次握手。这时候需要有个地方
可以暂存这些半连接。这个地方就叫半连接队列。
如果之后第三次握手来了，半连接就会升级为全连接，然后暂存到另外一个叫全连接队列的地
方，坐等程序执行 accept() 方法将其取走使用。是队列就有⻓度，有⻓度就有可能会满，如果它们满了，那新来的包就会被丢弃。
可以通过下面的方式查看是否存在这种丢包行为。
# 全连接队列溢出次数
\# netstat -s | grep overflowed4343 times the listen queue of a socket overflowed
# 半连接队列溢出次数
\# netstat -s | grep -i "SYNs to LISTEN sockets dropped"109 times the listen queue of a socket overflowed
从现象来看就是连接建立失败。
流量控制丢包
应用层能发网络数据包的软件有那么多，如果所有数据不加控制一股脑冲入到网卡，网卡会吃不
消，那怎么办？让数据按 一定的规则排个队依次处理，也就是所谓的qdisc (Queueing
Disc iplines ，排队规则)，这也是我们常说的流量控制机制。排队，得先有个队列，而队列有个⻓度。
我们可以通过下面的 ifconfig 命令查看到，里面涉及到的 txqueuelen 后面的数字 1000 ，其实
就是流控队列的⻓度。
当发送数据过快，流控队列⻓度 txqueuelen 又不够大时，就容易出现丢包现象。
可以通过下面的 ifconfig 命令，查看TX 下的dropped 字段，当它大于0时，则有可能是发生了流
控丢包。
flags=416**3**<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500inet 172.21.66.69 netmask 255.255.240.0 broadcast 172.21.79.255
inet6 fe80::216:3eff:fe25:269f prefixlen 64 scopeid 0x2**0**<link>
ether 00:16:3e:25:26:9f txqueuelen 1000 (Ethernet)
RX packets 6962682 bytes 1119047079 (1.0 GiB)RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9688919 bytes 2072511384 (1.9 GiB)TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
当遇到这种情况时，我们可以尝试修改下流控队列的⻓度。比如像下面这样将eth0 网卡的流控队
列⻓度从1000 提升为1500.
# ifconfig eth0 txqueuelen 1500
网卡丢包
网卡和它的驱动导致丢包的场景也比较常⻅，原因很多，比如网线质量差，接触不良。除此之
外，我们来聊几个常⻅的场景。
RingBuffer 过小导致丢包
上面提到，在接收数 据时，会将数据暂存到 RingBuffer 接收缓冲区中，然后等着内核触发软中断
慢慢 收走。如果这个缓冲区过小，而这时候发送的数据又过快，就有可能发生溢出，此时也会产
生丢包。
我们可以通过下面的命令去查看是否发生过这 样的事情。
# ifconfig
eth0: RX errors 0 dropped 0 overruns 0 frame 0
查看上面的 overruns 指标，它记录了由于 RingBuffer ⻓度不足导致的溢出次数。
当然，用 ethtool 命令也能查看。
\# ethtool -S eth0|grep rx_queue_0_drops但这里需要注意的是，因为一个网卡里是可以有多个RingBuffer 的，所以上面的
rx_queue_0_drops 里的0代表的是第0个RingBuffer 的丢包数，对于多队列的网卡，这个0还可以改成其他数字。但我的家庭条件不允许我看其他队列的丢包数，所以上面的命令对我来说是够用
了。。。
当发现有这类型丢包的时候，可以通过下面的命令查看当前网卡的配置。
#ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 1024
RX Mini: 0
RX Jumbo: 0
TX: 1024
上面的输出内容，含义是RingBuffer 最大支持4096 的⻓度，但现在实际只用了1024 。
想要修改这个⻓度可以执行 ethtool -G eth1 rx 4096 tx 4096 将发送和接收RingBuffer 的⻓度都
改为4096 。
RingBuffer 增大之后，可以减少因为容量小而导致的丢包情况。
网卡性能不足
网卡作为硬件，传输速度是有上限的。当网络传输速度过大，达到网卡上限时，就会发生丢包。
这种情况一般常⻅于压测场景。
我们可以通过 ethtool 加网卡名，获得当 前网卡支持的最大速度。
# ethtool eth0
Settings for eth0:
可以看到，我这边 用的网卡能支持的最大传输速度speed=1000Mb/s 。
也就是俗称的千兆网卡，但注意这里的单位是Mb ，这里的b是指bit ，而不是Byte 。1Byte=8bit 。
所以10000Mb/s 还要除以8，也就是理论上网卡最大传输速度是 1000/8 = 125MB/s 。我们可以通过 sar 命令 从网络接口层面来分析数据包的收发情况。
# sar -n DEV 1
Linux 3.10.0-1127.19.1.el7.x86_64 2022年07月27日 _x86_64_ (1 CPU)08时35分39秒 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmc
08时35分40秒 eth0 6.06 4.04 0.35 121682.33 0.00 0.00 0.00
其中 txkB/s 是指当前每秒发送的字节（byte ）总数，rxkB/s 是指每秒接收的字节（byte ）总数。
当两者加起来的值约等于 12~13w 字节 的时候，也就对 应大概 125MB/s 的传输速度。此时达到网卡
性能极限，就会开始丢包。
遇到这个问题，优先看下你的服务是不是真有这么大的真实流量，如果是的话可以考虑下拆分服
务，或者就忍痛充钱升级下配置吧。
接收缓冲区丢包
我们一般使用 TCP socket 进行网络编程的时候，内核都会分配一个发送缓冲区和一个接收缓冲
区。
当我们想要发一个数据包，会在代码里执行 send(msg) ，这时候数据包并不是一把梭直接就走网卡⻜出去的。而是将数据拷 ⻉到内核发送缓冲区就完事返回了，至于什么 时候发数据，发多少数
据，这个后续由内核自己做决定。
而接收缓冲区作用也类似，从外部网络收到的数据包就暂存在这个地方，然后坐等用⼾空间的应
用程序将数据包取 走。
这两个 缓冲区是有大小限制的，可以通过下面的命令去查看。
# 查看接收缓冲区
\# sysctl net.ipv4.tcp_rmem
net.ipv4.tcp_rmem = 4096 87380 6291456# 查看发送缓冲区
\# sysctl net.ipv4.tcp_wmem
net.ipv4.tcp_wmem = 4096 16384 4194304不管是接收缓冲区还是发送缓冲区，都能看到三个 数值，分别 对应缓冲区的最小值，默认值和最
大值 （min 、default 、max ）。缓冲区会在min 和max 之间动态调整。
那么问题来了，如果缓冲区设置过小会怎么样？
对于发送缓冲区，执行send 的时候，如果是阻塞调用，那就会等，等到缓冲区有空位可以发数
据。
如果是非阻塞调用，就会立刻返回一个 EAGAIN 错误信息，意思是 Try again 。让应用程序下次
再重试。这种情况下一般不会发生丢包。
当接受缓冲区满了，事情就不一样了，它的TCP 接收窗口会变为0，也就是所谓的零窗口，并且会
通过数据包里的 win=0 ，告诉发送端，"球球 了，顶不住了，别发了"。一般这种情况下，发送端就该停止发消息了，但如果这时候确实还有数据发来，就会发生丢包。
我们可以通过下面的命令里的 TCPRcvQDrop 查看到有没有发生过这 种丢包现象。
TcpExt: SyncookiesSent TCPRcvQDrop SyncookiesFailed
TcpExt: 0 157 60116
但是说个伤心的事情，我们一般也看不到这个 TCPRcvQDrop ，因为这个是 5.9 版本 里引入的打
点，而我们的服务器用的一般是 2.x~3.x 左右版本。你可以通过下面的命令查看下你用的是什么
版本的linux 内核。
\# cat /proc/versionLinux version 3.10.0-1127.19.1.el7.x86_64
两端之间的网络丢包
前面提到的是两端机器内部的网络丢包，除此之外，两端之间那么⻓的一条链路都属于外部网
络，这中间有各种路由器和交换机还有光缆啥的，丢包也是很经常发生的。
这些丢 包行为发生在中间链路的某些个 机器上，我们当然是没权限去登录这些机器。但我们可以
通过一些命令观察整个链路的连通情况。
ping 命令查看丢包
比如我们知道目的地的域名是 baidu.com 。想知道你的机器到baidu 服务器之间，有没有产生丢
包行为。可以使 用ping 命令。
倒数第二行里有个 100% packet loss ，意思是丢包率100% 。
但这样其实你只能知道你的机器和目的机器之间有没有丢包。
那如果你想知道你和目的机器之间的这条链路，哪个节点丢包了，有没有办法呢?
有。
mtr 命令
mtr 命令可以查看到你的机器和目的机器之间的每个节点的丢包情况。
像下面这样执行命令。
其中 -r 是指report ，以报告的形式 打印结果。
可以看到 Host 那一列，出现的都是链路中间每一跳的机器， Loss 的那一列就是指这一跳对应的
丢包率。
需要注意的是，中间有一些是host 是 ??? ，那个是因为mtr 默认用的是ICMP 包，有些节点限制了ICMP 包，导致不能正常展示。
我们可以在mtr 命令里加个 -u ，也就是使用udp 包，就能看到部分??? 对应的IP 。
把ICMP 包和UDP 包的结果拼在一起看，就是比较完整的链路图了。
还有个小细节， Loss 那一列，我们在icmp 的场景下，关注最后一行，如果是0% ，那不管前面
loss 是100% 还是80% 都无所谓，那些都是节点限制导致的虚报。
但如果最后一行是20% ，再往前几行都是20% 左右，那说明丢包就是从最接近的那一行开始产生
的，⻓时间是这样，那很可能这一跳出了点问题。如果是公司内网的话，你可以带着这条线索去
找对应的网络同事。如果是外网的话，那耐心点等等 吧，别人家的开发会比你更着急。
发生丢包了怎么办
说了这么多。只是想告诉大家，丢包是很常⻅的，几乎不 可避免的一件事情。
但问题来了，发生丢包了怎么办？
这个好办，用TCP 协议去做传输。
建立了TCP 连接的两端，发送端在发出数据后会等待接收端回复 ack 包 ， ack 包 的目的是为了 告
诉对方自己确实收到了数据，但如果中间链路发生了丢 包，那发送端会迟迟 收不到确认ack ，于是
就会进行重传。以此来保证每个数据包都确确 实实 到达了接收端。
假设现在网断了，我们还用聊天软件发消息，聊天软件会使 用TCP 不断尝试重传数据，如果重传期
间网络恢复了，那数据就能正常发过去。但如果多次重试直到超时都还是失败，这时候你将收获
一个红色感叹号 。
这时候问题又来了。
假设某绿皮聊天软件用的就是TCP 协议。
在聊天的时候， 发生丢包了，丢包了会重试，重试失败了还会出现红色感叹号 。
于是乎，问题就变成了，用了 TCP 协议，就一定不会丢包吗？
用了TCP 协议就一定不会丢包吗
我们知道TCP 位于传输层，在它的上面还有各种应用层协议，比如常⻅的HTTP 或者各类RPC 协议。
TCP 保证的可靠性，是传输层的可靠性。也就是说，TCP 只保证数据从A机器的传输层可靠地发到B
机器的传输层。
至于数据到了接收端的传输层之后，能不能保证到应用层，TCP 并不管。
假设现在，我们输入一条消息，从聊天框发出，走到传输层TCP 协议的发送缓冲区，不管中间有没
有丢包，最后通过重传都保证发到了对方的传输层TCP 接收缓冲区，此时接收端回复了一个
ack ，发送端收到这个 ack 后就会将自己发送缓冲区里的消息给扔掉。到这里TCP 的任务就结束
了。
TCP 任务是结束了，但聊天软件的任务没结束。
聊天软件还需要将数据从TCP 的接收缓冲区里读出来，如果在读出来这一刻，手机由于内存不足或
其他各种原因，导致软件崩溃闪退了。
发送端以为自己发的消息已经发给对方了，但接收端却并没有收到这条消息。
于是乎，消息就丢了 。
虽然概率很小，但它就是发生了。
合情合理，逻辑自洽。
这类丢包问题怎么解决？
故事到这里也到尾声了，感动之余，我们来聊点掏心窝子的话。
其实前面说的都对，没有一句是假话。
但某绿皮聊天软件这么成熟，怎么可能没考虑过这 一点呢。
大家应该还记得我们文章开头提到过，为了 简单，就将 服务器那一方给省略了，从三 端通信变成
了两 端通信，所以才有了这个丢 包问题。
现在我们重新将服务器加回来。
大家有没有发现，有时候我们在手机里聊了一大堆内容，然后登录电脑版，它能将最近的聊天记
录都同步到电脑版上。也就是说服务器可能记录了我们最近发过什么 数据，假设每条消息都有个
id ，服务器和聊天软件每次 都拿最新消息的id 进行对比，就能知道两端消息是否一致，就像对账一
样。
对于发送方，只要定时跟服务端的内容对账一下，就知道哪条消息没发送成功，直接重发就好
了。
如果接收方的聊天软件崩溃了，重启后 跟服务器稍微通信一下就知道少了哪条数据，同步上来就
是了，所以也不 存在上面提到的丢包情况。
可以看出，TCP 只保证传输层的消息可靠性，并不保证应用层的消息可靠性。如果我们还想保证应
用层的消息可靠性，就需要应用层自己去实现逻辑做保证。
那么问题叒来了，两端通信的时候也能对账，为什么 还要引入第三端服务器？
主要有三个 原因。
第一，如果是两端通信，你聊天软件里有 1000 个 好友，你就得建 立 1000 个 连接。但如果引入
服务端，你只需要跟服务器建立 1个 连接就够了，聊天软件消耗的资源越少，手机就越省电。
第二，就是安全问题，如果还是两端通信，随便一个人找你对账一下，你就把聊天记录给同步
过去了，这并不合适吧。如果对方别有用心，信息就泄露了。引入第三方服务端就可以很方便
的做各种鉴权校验。
第三，是软件版本问题。软件装到用⼾手机之后，软件更不更新就是由用⼾说了算了。如果还
是两端通信，且两 端的软件版本跨度太大，很容易产生各种兼容性问题，但引入第三端服务
器， 就可以强制部分过低版本升级，否则不能使用软件。但对于大部分兼容性问题，给服务端
加兼容逻辑就好了，不需要强制用⼾更新软件。
所以看到这里大家应该明白了，我把 服务端去掉，并不单纯是为了 简单。
总结
数据从发送端到接收端，链路很⻓，任何 一个地方都可能发生丢包，几乎可以说丢包不可避
免。
平时没事也不 用关注丢包，大部分时候TCP 的重传机制保证了消息可靠性。
当你发现服务异常的时候，比如接口延时很高，总是失败的时候，可以用ping 或者mtr 命令看下
是不是中间链路发生了丢 包。
TCP 只保证传输层的消息可靠性，并不保证应用层的消息可靠性。如果我们还想保证应用层的消
息可靠性，就需要应用层自己去实现逻辑做保证。