需要回复Acknowledge的协议
重传的数据
连接在busy状态多长时间就新建链接
结束一个TCP连接,相当于TCP FIN。
结束一个TCP连接,相当于TCP FIN。
不能直接用TCP FIN是因为一方发送Finish后还可能继续发Acknowledge。 而在调用shutdown发送TCP FIN后,就没办法再发送Acknowledge了。
当一个TCP连接空闲多长时间没发送任何数据时,发一个心跳包
连接在idle状态多长时间就关闭链接
每个会话最多允许多少个活跃TCP连接
每个会话最多允许多少个TCP连接,包括活跃TCP连接和还没有收到Finish但已经关闭的僵尸连接
数据包上限是多少字节
最多缓存多少个离线包
Session ID由多少字节构成
多长时间收不到任何包,就杀掉TCP连接。
重新建立链接时间
多长时间发不出数据就杀掉TCP连接。
多长时间发不出数据就杀掉TCP连接。
发数据超时只可能因为TCP缓冲区满, 只有发送超大数据包时,客户端很慢,才会发生这种情况,可能性微乎其微。
BCP协议相关的数据结构和常量
BCP(Brutal Control Protocol,残暴控制协议)是基于TCP实现的用户层传输协议。特性如下:
BCP vs. TCP
BCP和普通TCP功能相似,重新实现了TCP的包确认重发机制。
当网络条件不好,丢包频繁,TCP重传间隔时间会变得很长,从而基本不可用。 这种情况下,BCP会暴力杀死底层TCP连接,强制重建TCP连接,暴力重发数据,避免丢失数据并减少延时。
BCP和TCP都属于面向连接会话的协议。 但另一方面,BCP数据不是TCP那样的流,而以Packet为单位。 BCP协议不保证接收方收取Packet的顺序和发送方发出Packet的顺序一致。 这是因为,一条BCP会话,可能会对应多达MaxConnectionsPerSession个底层TCP连接, 而这几条底层TCP连接的延时可能并不相同。
BCP会话的一生
此外,客户端可以把会话ID记录在文件中。 如果应用崩溃,用户在短时间内重连, 客户端可以使用先前保存的会话ID,而不需要重新生成会话ID。 这种情况下,客户端应当在建立连接后立即发送Renew给服务端, 服务端会放弃重发原会话尚未成功发送的数据, 但同时会视为会话从未断开,不会清除原会话的服务端数据。