TCP特性：延迟应答、捎带应答、粘包问题、保活机制、面向字节流

一、TCP 连接可靠性的依据
确认应答、超时重传、连接管理

二、其他特性
滑动窗口、流量控制

（六）延迟应答

在保证传输可靠性的前提下，可以延迟应答提高效率。

如果接收数据的主机立刻返回 ACK 应答, 这时候返回的窗口可能比较小。
例：
假设接收端缓冲区为 1 M， 一次收到了 500 K 的数据。
如果立刻应答, 返回的窗口就是 500 K; 但实际上可能处理端处理的速度还远没有达到自己的极限, 即使窗口再放大一些, 也能及时处理。
因此如果接收端稍微等一会再应答，比如等待 200ms 再应答, 那么这个时候返回的窗口大小就是1M。

窗口越大, 网络吞吐量就越大, 传输效率就越高. 可以保证网络不拥塞的情况下尽量提高传输效率。

（七）捎带应答

在延迟应答的基础上，我们发现在很多情况下，客户端服务器在应用层也是 “一发一收” 的。

例：
假设客户端给服务器说了 “你好”，服务器也会给客户端回一个 “你好”。那么这个时候 ACK 就可以搭 “顺风车”, 和服务器回应的 “你好” 一起回给客户端。

ps: 主机断开连接时进行的 “四次挥手”，中间两次在满足一定条件下可以进行延迟应答和捎带应答，三次“挥手”即可完成。

（八）面向字节流

创建一个 TCP 的 socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区。
调用 write 时, 数据会先写入发送缓冲区中;
如果发送的字节数太长, 会被拆分成多个 TCP 的数据包发出;
如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
然后应用程序可以调用 read 从接收缓冲区拿数据;
另一方面, TCP 的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据。
这个概念叫做 全双工。

作用：
由于缓冲区的存在, TCP 程序的读和写不需要一一匹配。

写 100 个字节数据时, 可以调用一次 write 写 100 个字节, 也可以调用 100 次 write, 每次写一个字节。
读 100 个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次 read 100 个字节, 也可以一次 read 一个字节, 重复 100 次。

（九）粘包问题

粘包问题中的 “包” , 是指应用层的数据包。

在 TCP 的协议头中, 没有如同 UDP 一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段。
站在传输层的角度, TCP 是一个一个报文过来的，按照序号排好序放在缓冲区中。
站在应用层的角度, 看到的只是一串连续的字节数据。那么应用程序看到了这么一连串的字节数据, 就不知道哪些是一个完整的应用层数据包。

如何避免粘包问题？
答：明确包与包之间的边界。

对于定长的包, 保证每次都按固定大小读取即可;
对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置; 还可以在包和包之间使用明确的分隔符(自定, 只要保证分隔符不和正文冲突即可);

对于 UDP ，是否也存在粘包问题？
答：对于 UDP，如果还没有上层交付数据，UDP 的报文长度仍然在。
同时, UDP 是一个一个把数据交付给应用层，就有很明确的数据边界。
站在应用层的角度, 使用 UDP 的时候, 要么收到完整的 UDP 报文, 要么完全收不到。不会出现收到一半的情况。

（十）保活机制

解决 TCP 异常情况。

进程终止：进程终止会释放文件描述符，仍然可以发送 FIN，和正常关闭没有什么区别。
机器重启：和进程终止的情况相同。
机器掉电 / 网线断开：接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行 reset 。
即使没有写入操作, TCP 自己也内置了一个保活定时器, 会定期询问对方是否还在。如果对方不在, 也会把连接释放。
另外, 应用层的某些协议, 也有一些这样的检测机制。
例如 HTTP 长连接中，也会定期检测对方的状态。
例如QQ, 在QQ断 线之后, 也会定期尝试重新连接。