使用TCP协议就一定零丢包了吗？

简述数据包发送流程

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

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

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

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

整条链路下来，有不少地方可能会发生丢包。这边只重点讲下几个常见容易发生丢包的场景。

建立连接时丢包

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

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

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

流量控制丢包

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

        排队，得先有个队列，而队列有个长度。当发送数据过快，流控队列长度txqueuelen又不够大时，就容易出现丢包现象。

网卡丢包

网卡和它的驱动导致丢包的场景也比较常见，原因很多，比如网线质量差，接触不良。除此之外，我们来聊几个常见的场景。

• RingBuffer过小导致丢包，在接收数据时，会将数据暂存到RingBuffer接收缓冲区中，然后等着内核触发软中断慢慢收走。如果这个缓冲区过小，而这时候发送的数据又过快，就有可能发生溢出，此时也会产生丢包。

• 网卡性能不足，网卡作为硬件，传输速度是有上限的。当网络传输速度过大，达到网卡上限时，就会发生丢包。这种情况一般常见于压测场景。

接收缓冲区丢包

我们一般使用TCP socket进行网络编程的时候，内核都会分配一个发送缓冲区和一个接收缓冲区。

        当我们想要发一个数据包，会在代码里执行send(msg)，这时候数据包并不是一把梭直接就走网卡飞出去的。而是将数据拷贝到内核发送缓冲区就完事返回了，至于什么时候发数据，发多少数据，这个后续由内核自己做决定。

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

发生丢包了怎么办

        实际上，数据从发送端到接收端，链路很长，任何一个地方都可能发生丢包，几乎可以说丢包不可避免。但是平时没事也不用关注丢包，大部分时候TCP的重传机制保证了消息可靠性。

        但是要注意的是，TCP只保证传输层的消息可靠性，并不保证应用层的消息可靠性。如果我们还想保证应用层的消息可靠性，就需要应用层自己去实现逻辑做保证。举个例子：

        有没有发现，有时候我们在手机里聊了一大堆内容，然后登录电脑版，它能将最近的聊天记录都同步到电脑版上。也就是说服务器可能记录了我们最近发过什么数据，假设每条消息都有个id，服务器和聊天软件每次都拿最新消息的id进行对比，就能知道两端消息是否一致，就像对账一样。

• 对于发送方，只要定时跟服务端的内容对账一下，就知道哪条消息没发送成功，直接重发就好了。

• 如果接收方的聊天软件崩溃了，重启后跟服务器稍微通信一下就知道少了哪条数据，同步上来就是了，所以也不存在上面提到的丢包情况。

        可以看出，TCP只保证传输层的消息可靠性，并不保证应用层的消息可靠性。如果我们还想保证应用层的消息可靠性，就需要应用层自己去实现逻辑做保证。

那么问题叒来了，两端通信的时候也能对账，为什么还要引入第三端服务器？

主要有三个原因。

• 第一，如果是两端通信，你聊天软件里有1000个好友，你就得建立1000个连接。但如果引入服务端，你只需要跟服务器建立1个连接就够了，聊天软件消耗的资源越少，手机就越省电。

• 第二，就是安全问题，如果还是两端通信，随便一个人找你对账一下，你就把聊天记录给同步过去了，这并不合适吧。如果对方别有用心，信息就泄露了。引入第三方服务端就可以很方便的做各种鉴权校验。

• 第三，是软件版本问题。软件装到用户手机之后，软件更不更新就是由用户说了算了。如果还是两端通信，且两端的软件版本跨度太大，很容易产生各种兼容性问题，但引入第三端服务器，就可以强制部分过低版本升级，否则不能使用软件。但对于大部分兼容性问题，给服务端加兼容逻辑就好了，不需要强制用户更新软件。