接收缓冲区丢包
我们一般使用TCP socket进行网络编程的时候，内核都会分配一个发送缓冲区和一个接收缓冲区。
当我们想要发一个数据包，会在代码里执行send(msg)，这时候数据包并不是一把梭直接就走网卡飞出去的。而是将数据拷贝到内核发送缓冲区就完事返回了，至于什么时候发数据，发多少数据，这个后续由内核自己做决定。之前写过的《代码执行send成功后，数据就发出去了吗？》里有比较详细的介绍。
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的时候，如果是阻塞调用，那就会等，等到缓冲区有空位可以发数据。
send阻塞
如果是非阻塞调用，就会立刻返回一个 EAGAIN 错误信息，意思是 Try again 。让应用程序下次再重试。这种情况下一般不会发生丢包。
send非阻塞
当接受缓冲区满了，事情就不一样了，它的TCP接收窗口会变为0，也就是所谓的零窗口，并且会通过数据包里的win=0，告诉发送端，"球球了，顶不住了，别发了"。一般这种情况下，发送端就该停止发消息了，但如果这时候确实还有数据发来，就会发生丢包。
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命令。
ping查看丢包
倒数第二行里有个100% packet loss，意思是丢包率100%。
但这样其实你只能知道你的机器和目的机器之间有没有丢包。
那如果你想知道你和目的机器之间的这条链路，哪个节点丢包了，有没有办法呢?
有。
mtr命令
mtr命令可以查看到你的机器和目的机器之间的每个节点的丢包情况。
像下面这样执行命令。
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%左右，那说明丢包就是从最接近的那一行开始产生的，长时间是这样，那很可能这一跳出了点问题。如果是公司内网的话，你可以带着这条线索去找对应的网络同事。如果是外网的话，那耐心点等等吧，别人家的开发会比你更着急。
发生丢包了怎么办
说了这么多。只是想告诉大家，丢包是很常见的，几乎不可避免的一件事情。
但问题来了，发生丢包了怎么办？
这个好办，用TCP协议去做传输。
TCP是什么
建立了TCP连接的两端，发送端在发出数据后会等待接收端回复ack包，ack包的目的是为了告诉对方自己确实收到了数据，但如果中间链路发生了丢包，那发送端会迟迟收不到确认ack，于是就会进行重传。以此来保证每个数据包都确确实实到达了接收端。
假设现在网断了，我们还用聊天软件发消息，聊天软件会使用TCP不断尝试重传数据，如果重传期间网络恢复了，那数据就能正常发过去。但如果多次重试直到超时都还是失败，这时候你将收获一个红色感叹号。
这时候问题又来了。
假设某绿皮聊天软件用的就是TCP协议。
那文章开头提到的女生，她男朋友回她的消息时为什么还会丢包？毕竟丢包了会重试，重试失败了还会出现红色感叹号。
于是乎，问题就变成了，用了TCP协议，就一定不会丢包吗？
用了TCP协议就一定不会丢包吗
我们知道TCP位于传输层，在它的上面还有各种应用层协议，比如常见的HTTP或者各类RPC协议。
四层网络协议
TCP保证的可靠性，是传输层的可靠性。也就是说，TCP只保证数据从A机器的传输层可靠地发到B机器的传输层。
至于数据到了接收端的传输层之后，能不能保证到应用层，TCP并不管。
假设现在，我们输入一条消息，从聊天框发出，走到传输层TCP协议的发送缓冲区，不管中间有没有丢包，最后通过重传都保证发到了对方的传输层TCP接收缓冲区，此时接收端回复了一个ack，发送端收到这个ack后就会将自己发送缓冲区里的消息给扔掉。到这里TCP的任务就结束了。
TCP任务是结束了，但聊天软件的任务没结束。
聊天软件还需要将数据从TCP的接收缓冲区里读出来，如果在读出来这一刻，手机由于内存不足或其他各种原因，导致软件崩溃闪退了。
发送端以为自己发的消息已经发给对方了，但接收端却并没有收到这条消息。
于是乎，消息就丢了。
使用TCP协议却发生丢包
虽然概率很小，但它就是发生了。
合情合理，逻辑自洽。
所以从这里，我铿锵有力的得出结论，我的读者已经回了这位女生消息了，只是因为发生了丢包所以女生才没能收到，而丢包的原因是女生的手机聊天软件在接收消息的那一刻发生了闪退。
到这里。女生知道自己错怪她男朋友了，哭着表示，一定要让她男朋友给她买一台不闪退的最新款iphone。
额。。。
兄弟们觉得我做得对的，请在评论区扣个"正能量"。
这类丢包问题怎么解决？
故事到这里也到尾声了，感动之余，我们来聊点掏心窝子的话。
其实前面说的都对，没有一句是假话。
但某绿皮聊天软件这么成熟，怎么可能没考虑过这一点呢。
大家应该还记得我们文章开头提到过，为了简单，就将服务器那一方给省略了，从三端通信变成了两端通信，所以才有了这个丢包问题。
现在我们重新将服务器加回来。
聊天软件三端通信
大家有没有发现，有时候我们在手机里聊了一大堆内容，然后登录电脑版，它能将最近的聊天记录都同步到电脑版上。也就是说服务器可能记录了我们最近发过什么数据，假设每条消息都有个id，服务器和聊天软件每次都拿最新消息的id进行对比，就能知道两端消息是否一致，就像对账一样。
对于发送方，只要定时跟服务端的内容对账一下，就知道哪条消息没发送成功，直接重发就好了。
如果接收方的聊天软件崩溃了，重启后跟服务器稍微通信一下就知道少了哪条数据，同步上来就是了，所以也不存在上面提到的丢包情况。
可以看出，TCP只保证传输层的消息可靠性，并不保证应用层的消息可靠性。如果我们还想保证应用层的消息可靠性，就需要应用层自己去实现逻辑做保证。
那么问题叒来了，两端通信的时候也能对账，为什么还要引入第三端服务器？
主要有三个原因。
- 第一，如果是两端通信，你聊天软件里有
1000个好友，你就得建立1000个连接。但如果引入服务端，你只需要跟服务器建立1个连接就够了，聊天软件消耗的资源越少，手机就越省电。 - 第二，就是安全问题，如果还是两端通信，随便一个人找你对账一下，你就把聊天记录给同步过去了，这并不合适吧。如果对方别有用心，信息就泄露了。引入第三方服务端就可以很方便的做各种鉴权校验。
- 第三，是软件版本问题。软件装到用户手机之后，软件更不更新就是由用户说了算了。如果还是两端通信，且两端的软件版本跨度太大，很容易产生各种兼容性问题，但引入第三端服务器，就可以强制部分过低版本升级，否则不能使用软件。但对于大部分兼容性问题，给服务端加兼容逻辑就好了，不需要强制用户更新软件。
所以看到这里大家应该明白了，我把服务端去掉，并不单纯是为了简单。
总结
- 数据从发送端到接收端，链路很长，任何一个地方都可能发生丢包，几乎可以说丢包不可避免。
- 平时没事也不用关注丢包，大部分时候TCP的重传机制保证了消息可靠性。
- 当你发现服务异常的时候，比如接口延时很高，总是失败的时候，可以用ping或者mtr命令看下是不是中间链路发生了丢包。
- TCP只保证传输层的消息可靠性，并不保证应用层的消息可靠性。如果我们还想保证应用层的消息可靠性，就需要应用层自己去实现逻辑做保证。
最后给大家留个问题吧，mtr命令是怎么知道每一跳的IP地址的？
参考资料
《Linux 内核技术实战》-- 极客时间
《云网络丢包故障定位全景指南》--极客重生
最后
我一想到读者里还有不少兄弟还是单身，我就夜不能寐。
手心手背都是肉，一碗水要端平。
犹豫了很久，为她指了条明路。
"我读者里有很多微信不丢包的兄弟，他们都喜欢在我的文章底下点赞和再看。你可以考虑下他们"
"还有经常在我评论区叫我靓仔的那些个兄弟，一看就是深情种，请重点考虑"。
只能帮到这里了，懂？
我知道，这时候肯定就有兄弟要说我了，"故事汇都不敢这么编！"
嗯。
他们不敢，我敢。
