TCP 协议是大量重要的网络和通讯的思想和技术的集合体. 这些思想和技术被应用在 TCP 身上, 另一方面, 学习 TCP 可以了解这些思想和技术. 通讯的思想和技术不仅仅可以应用狭义的数据通讯上, 也可以应用在广义的信息通讯上, 后者一般可以理解为应用层的交互协议, 例如即时通讯(IM)的聊天协议.
首先, TCP 协议是一种可靠的传输协议. 这种可靠性可以从两方面理解: 1. TCP 保证数据的有序性和无差错; 2. TCP 尽最大努力确保数据被接收.
有序和无差错可能比较好理解, 但"最大努力"则和我们一般理解的"可靠"有较大差别. 首先, TCP 尽最大努力传输数据, 一旦发送方无法保证数据传输到接收方, 它将通过断开连接(使连接失效)来声明这一点. 其次, TCP 可以明确地告诉一个数据分段已经被对方接收, 但无法准确的断定未被确认的数据没有被对方接收, 也就是说, 数据可能没有被对方接收, 也能已经被对方接收. 这种对传输失败的不确定性, 显然是对可靠性的一个重大打击. "两军队问题(Two Army Problem)"说明了这一点, 事实上, 我们无法判断一个确认(ACK)是丢失了还是没有发出.
大部分可靠协议使用"带重传的正面确认(PAR, Positive Acknowledgment with Re-Transmission)"机制, TCP 协议也不例外. TCP 的如下特点可以在我们设计可靠传输协议时参考:
1. 连接建立
连接的建立是面向连接的协议所必须的. 连接建立的过程双方可进行某些变量的协商, 如序号. 更高层次的应用层协议还协商版本号, 处理速度等.
2. 分段和序号
分段也即是一般所说的"分包", 也即消息和报文的概念. 序号是为了保证消息的有序性, 用于乱序重排.
分段方式有3种: 1. 固定长度; 2. 报文自声明长度; 3. 分隔符.
基于 TCP 这样可靠传输的协议而设计的上层协议往往不需要序号机制, 但分段大部分情况都是必须的. 序号也是确认和重传的基础. 基于 TCP 的 HTTP, FTP, SMTP 等协议, 没有序号概念. 这是因为, 底层的 TCP 已经保证了有序和数据不会丢失. 基于 TCP 设计的协议也可能需要序号机制, 使用 TCP 的协议需要序号机制的条件为: 1. 协议不依赖连接, 一次上层的会话可能经历 TCP 的断开和重连; 2. 协议不是停止等待式的"请求-响应"模式.
3. 确认和重传
确认和重传消息报文丢失影响的方法. 确认有立即确认和延时确认. 重传的触发时机不仅仅是超时, TCP 还设计了立即重传机制.
4. 滑动窗口
简单的停止等待机制是一种退化了的滑动窗口. TCP 的最大传输速度是 wnd_size/rtt, 因为 RTT 一般主要受物理条件影响, 所以通过增加窗口大小来提高 TCP 的速度.
发送方至少有 4 个变量: snd_una, snd_nxt, snd_max, snd_wnd.
snd_una: 未被确认的第一个序号. TCP 的 ACK 确认的是已收到的最大序号+1.
snd_nxt: 下一个要进行发送(包括重传)的序号, 如果不是重传, 则与 snd_max 相等.
snd_max: 下一个要进行第一次发送的序号, 即已发送的最大序号+1.
snd_wnd: 窗口大小.
接收方至少有 2 个变量: rcv_nxt, rcv_wnd.
rcv_nxt: 下一个要接收的序号, 也即要发送(或已发送的 ACK).
rcv_wnd: 窗口大小.
5. 更多
拥塞控制, 流量控制, 选择ACK, 序号回绕等等, 都是可以学习的东西.
关于 IM 软件的一些问题
IM 的聊天协议需要面向连接吗? 以腾讯 QQ 为例, 它并没有使用应用层的面向连接机制(即会话机制), 而是发送方确保发送到中转服务器, 中转服务器确保发送到接收方.
腾讯的 QQ 缺少序号机制, 无法保证有序性(可完全避免). 而且缺少完善的应用层的确认和重传机制, 常常出现发送方提示发送失败, 但接收方事实上已经收到了的现象(无法完全避免但可减少出现概率到极小).
我认为, QQ 应该解决消息的无序性问题, 并且完善确认和重传机制. 聊天消息应该实现这些状态: 发送中, 取消中, 发送成功, 未发送.
minah
2010-07-09 at 23:31:08
Loading ...