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,在网线断开的情况下,即便是发了,对方也收不到,因为这属于物理层面的原因。应该怎么办?
站在服务端的角度,认为客户端是在线的,由于长时间没有收到反馈,此时就会触发保活机制,服务端会定期询问客户端,如果依然没有反馈,服务端就会断开连接。