✍个人博客：Pandaconda-CSDN博客
📣专栏地址：http://t.csdnimg.cn/fYaBd
📚专栏简介：在这个专栏中，我将会分享 C++ 面试中常见的面试题给大家~
❤️如果有收获的话，欢迎点赞👍收藏📁，您的支持就是我创作的最大动力💪
82. 用了 TCP 就一定不会丢包吗？
我们知道TCP位于传输层，在它的上面还有各种应用层协议，比如常见的 HTTP 或者各类 RPC 协议。
TCP 保证的可靠性，是传输层的可靠性。也就是说，TCP 只保证数据从 A 机器的传输层可靠地发到 B 机器的传输层。
至于数据到了接收端的传输层之后，能不能保证到应用层，TCP 并不管。
假设现在，我们输入一条消息，从聊天框发出，走到传输层 TCP 协议的发送缓冲区，不管中间有没有丢包，最后通过重传都保证发到了对方的传输层 TCP 接收缓冲区，此时接收端回复了一个ack，发送端收到这个ack后就会将自己发送缓冲区里的消息给扔掉。到这里 TCP 的任务就结束了。
TCP任务是结束了，但聊天软件的任务没结束。
聊天软件还需要将数据从 TCP 的接收缓冲区里读出来，如果在读出来这一刻，手机由于内存不足或其他各种原因，导致软件崩溃闪退了。
发送端以为自己发的消息已经发给对方了，但接收端却并没有收到这条消息。
于是乎，消息就丢了。
83. 这类丢包问题怎么解决？
故事到这里也到尾声了，感动之余，我们来聊点掏心窝子的话。
其实前面说的都对，没有一句是假话。
但某绿皮聊天软件这么成熟，怎么可能没考虑过这一点呢。
大家应该还记得我们文章开头提到过，为了简单，就将服务器那一方给省略了，从三端通信变成了两端通信，所以才有了这个丢包问题。
现在我们重新将服务器加回来。
大家有没有发现，有时候我们在手机里聊了一大堆内容，然后登录电脑版，它能将最近的聊天记录都同步到电脑版上。也就是说服务器可能记录了我们最近发过什么数据，假设每条消息都有个 id，服务器和聊天软件每次都拿最新消息的 id 进行对比，就能知道两端消息是否一致，就像对账一样。
对于发送方，只要定时跟服务端的内容对账一下，就知道哪条消息没发送成功，直接重发就好了。
如果接收方的聊天软件崩溃了，重启后跟服务器稍微通信一下就知道少了哪条数据，同步上来就是了，所以也不存在上面提到的丢包情况。
可以看出，TCP 只保证传输层的消息可靠性，并不保证应用层的消息可靠性。如果我们还想保证应用层的消息可靠性，就需要应用层自己去实现逻辑做保证。
那么问题叒来了，两端通信的时候也能对账，为什么还要引入第三端服务器？
主要有三个原因。
- 第一，如果是两端通信，你聊天软件里有 1000 个好友，你就得建立 1000 个连接。但如果引入服务端，你只需要跟服务器建立 1 个连接就够了，聊天软件消耗的资源越少，手机就越省电。
- 第二，就是安全问题，如果还是两端通信，随便一个人找你对账一下，你就把聊天记录给同步过去了，这并不合适吧。如果对方别有用心，信息就泄露了。引入第三方服务端就可以很方便的做各种鉴权校验。
- 第三，是软件版本问题。软件装到用户手机之后，软件更不更新就是由用户说了算了。如果还是两端通信，且两端的软件版本跨度太大，很容易产生各种兼容性问题，但引入第三端服务器，就可以强制部分过低版本升级，否则不能使用软件。但对于大部分兼容性问题，给服务端加兼容逻辑就好了，不需要强制用户更新软件。
所以看到这里大家应该明白了，我把服务端去掉，并不单纯是为了简单。
84. 三次握手过程中可以携带数据么？
第三次握手的时候，可以携带。前两次握手不能携带数据。
如果前两次握手能够携带数据，那么一旦有人想攻击服务器，那么他只需要在第一次握手中的 SYN 报文中放大量数据，那么服务器势必会消耗更多的时间和内存空间去处理这些数据，增大了服务器被攻击的风险。
第三次握手的时候，客户端已经处于 ESTABLISHED 状态，并且已经能够确认服务器的接收、发送能力正常，这个时候相对安全了，可以携带数据。