用了TCP协议，就一定不会丢包吗？( 五 ) _TCP协议

文章插图

发生丢包了怎么办说了这么多。只是想告诉大家，丢包是很常见的，几乎不可避免的一件事情。
但问题来了，发生丢包了怎么办？
这个好办，用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 。
额。。。
兄弟们觉得我做得对的，请在评论区扣个"正能量" 。

这类丢包问题怎么解决？故事到这里也到尾声了，感动之余，我们来聊点掏心窝子的话。