面试官：用了 TCP 协议，肯定不会丢包( 三 ) _缓冲

当两者加起来的值约等于 12~13w 字节的时候，也就对应大概 125MB/s 的传输速度。此时达到网卡性能极限，就会开始丢包。
遇到这个问题，优先看下你的服务是不是真有这么大的真实流量，如果是的话可以考虑下拆分服务，或者就忍痛充钱升级下配置吧。
接收缓冲区丢包
我们一般使用 TCP进行网络编程的时候，内核都会分配一个发送缓冲区和一个接收缓冲区。
当我们想要发一个数据包，会在代码里执行 send (msg)，这时候数据包并不是一把梭直接就走网卡飞出去的。而是将数据拷贝到内核发送缓冲区就完事返回了，至于什么时候发数据，发多少数据，这个后续由内核自己做决定。
逻辑
而接收缓冲区作用也类似，从外部网络收到的数据包就暂存在这个地方，然后坐等用户空间的应用程序将数据包取走。
这两个缓冲区是有大小限制的，可以通过下面的命令去查看。
# 查看接收缓冲区 #net.ipv4. net.ipv4. = 4096 87380
# 查看发送缓冲区 #net.ipv4. net.ipv4. = 4096 16384
不管是接收缓冲区还是发送缓冲区，都能看到三个数值，分别对应缓冲区的最小值，默认值和最大值（min、、max）。缓冲区会在 min 和 max 之间动态调整。
那么问题来了，如果缓冲区设置过小会怎么样？
对于发送缓冲区，执行 send 的时候，如果是阻塞调用，那就会等，等到缓冲区有空位可以发数据。
send 阻塞
如果是非阻塞调用，就会立刻返回一个错误信息，意思是 Try again。让应用程序下次再重试。这种情况下一般不会发生丢包。
send 非阻塞
当接受缓冲区满了，事情就不一样了，它的 TCP 接收窗口会变为 0，也就是所谓的零窗口，并且会通过数据包里的 win=0，告诉发送端，"球球了，顶不住了，别发了" 。一般这种情况下，发送端就该停止发消息了，但如果这时候确实还有数据发来，就会发生丢包。
丢包
我们可以通过下面的命令里的查看到有没有发生过这种丢包现象。
cat /proc/net/ :: 0 157 60116
但是说个伤心的事情，我们一般也看不到这个，因为这个是 5.9 版本里引入的打点，而我们的服务器用的一般是 2 。x~3 。x 左右版本。你可以通过下面的命令查看下你用的是什么版本的 Linux 内核。
# cat /proc/ Linux3.10.0-1127.19.1.el7.
两端之间的网络丢包
前面提到的是两端机器内部的网络丢包，除此之外，两端之间那么长的一条链路都属于外部网络，这中间有各种路由器和交换机还有光缆啥的，丢包也是很经常发生的。
这些丢包行为发生在中间链路的某些个机器上，我们当然是没权限去登录这些机器。但我们可以通过一些命令观察整个链路的连通情况。
ping 命令查看丢包
比如我们知道目的地的域名是。想知道你的机器到 baidu 服务器之间，有没有产生丢包行为。可以使用 ping 命令。
ping 查看丢包
倒数第二行里有个 100%loss，意思是丢包率 100% 。
但这样其实你只能知道你的机器和目的机器之间有没有丢包。
那如果你想知道你和目的机器之间的这条链路，哪个节点丢包了，有没有办法呢？有。
mtr 命令
mtr 命令可以查看到你的机器和目的机器之间的每个节点的丢包情况。

文章插图
像下面这样执行命令。
其中 -r 是指，以报告的形式打印结果。
可以看到 Host 那一列，出现的都是链路中间每一跳的机器，Loss 的那一列就是指这一跳对应的丢包率。
需要注意的是，中间有一些是 host 是？，那个是因为 mtr 默认用的是 ICMP 包，有些节点限制了 ICMP 包，导致不能正常展示。