用了TCP协议，就一定不会丢包吗？

迷南。 2024-04-08 08:50 43阅读 0赞

TCP 是一个可靠的传输协议，那它一定能保证数据不丢失吗？

这次，就跟大家探讨这个问题。

#### 数据包的发送流程 ####

首先，我们两个手机的绿皮聊天软件客户端，要通信，中间会通过它们家服务器。大概长这样。

![44406a0061fe0a0d9485503c6e94fb22.png][]

**聊天软件三端通信**

但为了**简化模型**，我们把中间的服务器给省略掉，假设这是个端到端的通信。且为了保证消息的可靠性，我们盲猜它们之间用的是**TCP协议**进行通信。

![d263cee72bcab1cc1ce81fa995dcfe6a.png][]

聊天软件两端通信

为了发送数据包，两端首先会通过**三次握手**，建立TCP连接。

一个数据包，从聊天框里发出，消息会从**聊天软件**所在的**用户空间**拷贝到**内核空间**的**发送缓冲区（send buffer）**，数据包就这样顺着**传输层、网络层，进入到数据链路层，在这里数据包会经过流控（qdisc），再通过RingBuffer发到物理层的网卡**。数据就这样顺着**网卡**发到了**纷繁复杂**的网络世界里。这里头数据会经过n多个**路由器和交换机**之间的跳转，最后到达**目的机器的网卡**处。

此时目的机器的网卡会通知**DMA**将数据包信息放到`RingBuffer`中，再触发一个**硬中断**给`CPU`，`CPU`触发**软中断**让`ksoftirqd`去`RingBuffer`收包，于是一个数据包就这样顺着**物理层，数据链路层，网络层，传输层**，最后从内核空间拷贝到用户空间里的**聊天软件**里。

![4cac9558005aef10f2df53142d245071.png][]

网络发包收包全景图

> 画了那么大一张图，只水了200字做解释，我多少是有些心痛的。

到这里，抛开一些细节，大家大概知道了一个数据包从**发送到接收**的宏观过程。

可以看到，这上面全是密密麻麻的**名词**。

整条链路下来，有不少地方可能会发生丢包。

但为了不让大家**保持蹲姿太久**影响身体健康，我这边只重点讲下几个**常见容易发生丢包的场景**。

#### 建立连接时丢包 ####

TCP协议会通过**三次握手**建立连接。大概长下面这样。

![ab28bead9941ef9b70dd318ead7aa3c0.png][]

TCP三次握手

在服务端，第一次握手之后，会先建立个**半连接**，然后再发出第二次握手。这时候需要有个地方可以**暂存**这些半连接。这个地方就叫**半连接队列**。

如果之后第三次握手来了，半连接就会升级为全连接，然后暂存到另外一个叫**全连接队列**的地方，坐等程序执行`accept()`方法将其取走使用。

![5054b8a03e16d7af8e4f349df27781ae.png][]

半连接队列和全连接队列

是队列就有长度，有长度就有可能会满，如果它们**满了**，那新来的包就会被**丢弃**。

可以通过下面的方式查看是否存在这种丢包行为。

# 全连接队列溢出次数
    # netstat -s | grep overflowed
        4343 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

从现象来看就是连接建立失败。

![da4d988cbd8a226a86037a29813102bb.png][]

**流量控制丢包**

应用层能发网络数据包的软件有那么多，如果所有数据不加控制一股脑冲入到网卡，网卡会吃不消，那怎么办？让数据按一定的规则排个队依次处理，也就是所谓的**qdisc**(**Q**ueueing**Disc**iplines，排队规则)，这也是我们常说的**流量控制**机制。

排队，得先有个队列，而队列有个**长度**。

我们可以通过下面的`ifconfig`命令查看到，里面涉及到的`txqueuelen`后面的数字`1000`，其实就是流控队列的长度。

当发送数据过快，流控队列长度`txqueuelen`又不够大时，就容易出现**丢包**现象。

![fdfeaec59a9b4d01b9e2f6a58bbc78af.png][]

qdisc丢包

可以通过下面的`ifconfig`命令，查看TX下的dropped字段，当它大于0时，则**有可能**是发生了流控丢包。

# ifconfig eth0
    eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            inet 172.21.66.69  netmask 255.255.240.0  broadcast 172.21.79.255
            inet6 fe80::216:3eff:fe25:269f  prefixlen 64  scopeid 0x20<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`接收缓冲区中，然后等着内核触发软中断慢慢收走。如果这个**缓冲区过小**，而这时候发送的数据又过快，就有可能发生溢出，此时也会产生**丢包**。

![c2f5565f1019a16fb18e4552f0dab76e.png][]

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: 10000Mb/s

可以看到，我这边用的网卡能支持的最大传输速度**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  rxmcst/s
    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)`，这时候数据包并不是一把梭直接就走网卡飞出去的。而是将数据拷贝到内核**发送缓冲区**就完事**返回**了，至于**什么时候发数据，发多少数据**，这个后续由内核自己做决定。

![ce5af0ae1f75bffbad353c6c53026c53.png][]

tcp\_sendmsg逻辑

而**接收缓冲区**作用也类似，从外部网络收到的数据包就暂存在这个地方，然后坐等用户空间的应用程序将数据包取走。

这两个缓冲区是有大小限制的，可以通过下面的命令去查看。

# 查看接收缓冲区
    # 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的时候，如果是**阻塞**调用，那就会等，等到缓冲区有空位可以发数据。

![a0db24bf595e883573732e124070dda6.gif][]

send阻塞

如果是**非阻塞**调用，就会**立刻返回**一个`EAGAIN`错误信息，意思是 `Try again`。让应用程序下次再重试。这种情况下一般不会发生丢包。

![74ed9cea2e07c4a9064eddcd4c1b63c2.gif][]

send非阻塞

当接受缓冲区满了，事情就不一样了，它的TCP接收窗口会变为0，也就是所谓的**零窗口**，并且会通过数据包里的`win=0`，告诉发送端，"球球了，顶不住了，别发了"。一般这种情况下，发送端就该停止发消息了，但如果这时候确实还有数据发来，就会发生**丢包**。

![e643fe06ce3f88759f069f1fb8fca97a.png][]

recv\_buffer丢包

我们可以通过下面的命令里的`TCPRcvQDrop`查看到有没有发生过这种丢包现象。

cat /proc/net/netstat
    TcpExt: SyncookiesSent TCPRcvQDrop SyncookiesFailed
    TcpExt: 0              157              60116

但是说个伤心的事情，我们一般也看不到这个`TCPRcvQDrop`，因为这个是`5.9版本`里引入的打点，而我们的服务器用的一般是`2.x~3.x`左右版本。你可以通过下面的命令查看下你用的是什么版本的linux内核。

# cat /proc/version
    Linux version 3.10.0-1127.19.1.el7.x86_64

#### 两端之间的网络丢包 ####

前面提到的是两端机器内部的网络丢包，除此之外，两端之间那么长的一条链路都属于外部网络，这中间有各种路由器和交换机还有光缆啥的，丢包也是很经常发生的。

这些丢包行为发生在中间链路的某些个机器上，我们当然是没权限去登录这些机器。但我们可以通过一些命令观察整个链路的连通情况。

ping命令查看丢包

比如我们知道目的地的域名是`baidu.com`。想知道你的机器到baidu服务器之间，有没有产生丢包行为。可以使用ping命令。

![4bfe44e662d058cfba9f2dcdbcc1fd7d.png][]

ping查看丢包

倒数第二行里有个`100% packet loss`，意思是**丢包率100%**。

但这样其实你只能知道**你的机器和目的机器之间有没有丢包。**

**那如果你想知道你和目的机器之间的这条链路，哪个节点丢包了，有没有办法呢?**

有。

mtr命令

mtr命令可以查看到你的机器和目的机器之间的每个节点的丢包情况。

像下面这样执行命令。

![9f7a43978394e31c8cb411a46b53b3ed.png][]

mtr\_icmp

其中**-r是指report**，以报告的形式打印结果。

可以看到`Host`那一列，出现的都是链路中间每一跳的机器，`Loss`的那一列就是指这一跳对应的丢包率。

需要注意的是，中间有一些是host是`???`，那个是因为**mtr默认用的是ICMP包**，有些节点限制了**ICMP包**，导致不能正常展示。

我们可以在mtr命令里加个`-u`，也就是使用**udp包**，就能看到**部分???**对应的IP。  
mtr-udp

把**ICMP包和UDP包的结果**拼在一起看，就是**比较完整**的链路图了。

还有个小细节，`Loss`那一列，我们在icmp的场景下，关注**最后一行**，如果是0%，那不管前面loss是100%还是80%都无所谓，那些都是**节点限制**导致的**虚报**。

但如果**最后一行是20%，再往前几行都是20%左右**，那说明丢包就是从最接近的那一行开始产生的，长时间是这样，那很可能这一跳出了点问题。如果是公司内网的话，你可以带着这条线索去找对应的网络同事。如果是外网的话，那耐心点等等吧，别人家的开发会比你更着急。

![49c0b1f3f0a5e869f05dc382b8804ed6.png][]

#### 发生丢包了怎么办 ####

说了这么多。只是想告诉大家，**丢包是很常见的，几乎不可避免的一件事情**。

但问题来了，发生丢包了怎么办？

这个好办，用**TCP协议**去做传输。

![5bf8722188fec4458e68aa6cdd809dab.png][]

TCP是什么

建立了TCP连接的两端，发送端在发出数据后会等待接收端回复`ack包`，`ack包`的目的是为了告诉对方自己确实收到了数据，但如果中间链路发生了丢包，那发送端会迟迟收不到确认ack，于是就会进行**重传**。以此来保证每个数据包都确确实实到达了接收端。

假设现在网断了，我们还用聊天软件发消息，聊天软件会使用TCP不断尝试重传数据，**如果重传期间网络恢复了**，那数据就能正常发过去。但如果多次重试直到超时都还是失败，这时候你将收获一个**红色感叹号**。