TCP 面向字节流、延迟应答、异常情况

1、面向字节流

TCP有自己的发送缓冲区和接收缓冲区，客户端上层向发送缓冲区拷贝数据的时候，可以是一次拷贝100个字节，也可以是分十次拷贝，每次拷贝10个字节；数据传递到服务端以后，服务端要怎么从接收缓冲区读数据，没有必要考虑客户端上层是如何写入的，这就是面向字节流！

UDP是面向数据包的，UDP没有发送缓冲区，客户端发10个报文，服务端就必须收10个报文，不能收8.5个，即所谓的“要么不收，要么全收；不能合并，不能拆分”。发送方和接收方的读写必须要匹配，写入多少就得读多少，而且必须是一整个报文读走。

2、延迟应答

客户端给服务端发数据，服务端接收缓冲区大小为1M，收到500K的数据后，此时缓冲区剩余空间大小为500K。如果服务端立马发送ACK，16位窗口大小只能是500K；但是如果等待10ms，这10ms内上层取走500K，此时的窗口大小依然是1M。这就是“延迟应答”。

等与不等，直接影响客户端发送的数据量，但是并非每个报文都要延迟应答。因为如果上层处理数据的速度较慢的话，即便是延迟应答，缓冲区的剩余空间大小也不会有变化。对此我们提出的策略可以是：

• 每隔N个报文延迟应答一次（N一般取2，不同OS可能不同）
• 每隔一定时间延迟应答一次（这个时间一般是200ms）

3、异常情况

TCP的异常情况大致可以分为下面三种 

异常原因	对应策略
进程终止	一旦进程终止，自动进行四次挥手（终止的一方发送FIN）
主机重启	先完成四次挥手，然后再关机
机器断电/网线断开	定期询问，如果没有回应，则断开连接

这里解释一下最后一种情况，假设在TCP通信过程中，客户端的网线突然断开，此时不会像前面两种情况一样，自动进行四次挥手，因为四次挥手要发送FIN，在网线断开的情况下，即便是发了，对方也收不到，因为这属于物理层面的原因。应该怎么办？

站在服务端的角度，认为客户端是在线的，由于长时间没有收到反馈，此时就会触发保活机制，服务端会定期询问客户端，如果依然没有反馈，服务端就会断开连接。