有了 TCP 协议本身的 ACK 机制为什么还需要业务层的ACK 机制?
答:这个问题从操作系统(linux/windows/android/ios)实现TCP协议的原理角度来说明更合适:
1 操作系统在TCP发送端创建了一个TCP发送缓冲区,在接收端创建了一个TCP接收缓冲区;
2 在发送端应用层程序调用send()方法成功后,实际是将数据写入了TCP发送缓冲区;
3 根据TCP协议的规定,在TCP连接良好的情况下,TCP发送缓冲区的数据是“有序的可靠的”到达TCP接收缓冲区,然后回调接收方应用层程序来通知数据到达;
4 但是在TCP连接断开的时候,在TCP的发送缓冲区和TCP的接收缓冲区中可能还有数据,那么操作系统如何处理呢?
首先,对于TCP发送缓冲区中还未发送的数据,操作系统不会通知应用层程序进行处理(试想一下:send()函数已经返回成功了,后面再告诉你失败,这样的系统如何设计?太复杂了...),通常的处理手段就是直接回收TCP发送缓存区及其socket资源;
对于TCP接收方来说,在还未监测到TCP连接断开的时候,因为TCP接收缓冲区不再写入数据了,所以会有足够的时间进行处理,但若未来得及处理就发现了连接断开,仍然会为了及时释放资源,直接回收TCP接收缓存区和对应的socket资源。
总结一下就是: 发送方的应用层程序,调用send()方法返回成功的时候,数据实际是写入到了TCP的发送缓冲区,而非
TCP Send函数的阻塞和非阻塞,以及TCP发送数据的异常情况
最新推荐文章于 2024-05-25 21:47:48 发布
![](https://img-home.csdnimg.cn/images/20240711042549.png)