TCP | UDP |
---|---|
可靠性 | 可靠 |
连接性 | 面向连接 |
报文 | 面向字节流 |
效率 | 传输率低 |
双工性 | 全双工 |
流量控制 | 有(滑动窗口) |
拥塞控制 | 有(慢开始、拥塞避免、快重传、快恢复) |
首部开销 | 20字节 |
1 可靠性
TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达。
UDP尽最大努力交付,即不保证可靠交付。
2 连接性
TCP面向连接:三次握手。
UDP是无连接的,即发送数据之前不需要建立连接。
3 报文
TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的。
3.1 面向字节流
面向字节流的话,虽然应用程序和TCP的交互是一次一个数据块(大小不等),但TCP把应用程序的数据看成是一连串的无结构的字节流。TCP有一个缓冲,当应用程序传送的数据块太长,TCP就可以把它划分短一些再传送。如果应用程序一次只发送一个字节,TCP也可以等待积累有足够多的字节后再构成报文段发送出去。
3.2 面向报文
面向报文的传输方式是应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文。因此,应用程序必须选择合适大小的报文。若报文太长,则IP层需要分片,降低效率。若太短,会是IP太小。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。这也就是说,应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文。
4 流量控制
所谓的流量控制就是让发送方的发送速率不要太快,让接收方来得及接受。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。TCP的窗口单位是字节,不是报文段,发送方的发送窗口不能超过接收方给出的接收窗口的数值。
5 拥塞控制
UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电话,实时视频会议等)。下面介绍TCP的拥塞控制机制。
5.1 慢开始和拥塞避免
发送方维持一个拥塞窗口的状态变量,其大小取决于网络的拥塞程度,动态地变化,而发送窗口一般取拥塞窗口和对方给出的接收窗口的最小值(为了便于描述,后面的分析中假定对方给出的接收窗口足够大,这样将发送窗口等于拥塞窗口就可以了)。
慢开始算法的核心是从小到大逐渐增大发送窗口,也就是说,从小到大逐渐增大拥塞窗口的数值。通常在刚开始发送报文段时,先把拥塞窗口设置为一个最大报文段MSS的数值,而在每收到对上一轮报文段(每次加倍后的报文段的个数,可能不止一个报文段)的确认后,就把拥塞窗口的数值加倍。
为了防止拥塞窗口增长过大引起网络拥塞,还需要维护一个慢开始门限的状态变量,当拥塞窗口的值小于慢开始门限时,使用慢开始算法,一旦拥塞窗口的值大于慢开始门限的值,就改用拥塞避免算法。拥塞避免算法的思路是让拥塞窗口缓慢地增大,收到每一轮的确认后,将拥塞窗口的值加1,而不是加倍,这样拥塞窗口的值按照线性规律缓慢增长。
无论是在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(没有按时收到确认),就把慢开始门限设置为出现拥塞时发送窗口值的一半,但最小不能小于2个MSS值,而后把拥塞窗口的值重新设置为1个MSS,执行慢开始算法。
5.2 快重传和快恢复
快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认(重复发送对前面有序部分的确认),而不是等待自己发送数据时才进行稍待确认,也不是累积收到的报文发送累积确认,如果发送方连续收到三个重复确认,就应该立即重传对方未收到的报文段(有收到重复确认,说明后面的报文段都送达了,只有中间丢失的报文段没送达)。
快恢复算法与快重传算法配合使用,其过程有如下两个要点:
- a) 当发送方连续收到三个重复确认时,就把慢开始门限减半,这是为了预防网络发生拥塞。注意,接下来不执行慢开始算法。
- b) 由于发送方现在认为网络很很可能没有发生特别严重的阻塞(如果发生了严重阻塞的话,就不会一连有好几个报文段到达接收方,就不会导致接收方连续发送重复确认),因此与慢开始不同之处是现在不执行慢开始算法(即拥塞窗口的值不设为1个MSSS),而是把拥塞窗口的值设为慢开始门限减半后的值,而后开始执行拥塞避免算法,线性地增大拥塞窗口。