TCP/UDP对比总结
在计算机网络中,有三种体系结构划分方式,第一种是OSI七层协议体系结构,由上到下分别是:应用层,表示层,会话层,运输层,网络层,数据链路层,物理层;第二种是TCP/IP四层协议,由上到下分别是:应用层,运输层,网际层,网络接口层。第一种划分方式复杂又不实用,第二种划分方式最下面“网络接口层”对计算机网络来说,和一般的通信链路没有多大的区别,所以最后折中为我们常用的五层协议:应用层,运输层,网络层,数据链路层,物理层。
运输层向它上面的应用层提供服务,它属于面向通信部分的最高层,同时也是用户功能的最底层。两个主机通过核心网络进行端到端通信时,只有主机部分有运输层,核心网络部分的路由在转发分组时只用到下面三层。
TCP/UDP作为传输层协议,各自都有着非常广泛的应用场景,下面先对这两种协议做一个简单对比,然后分别介绍下这两种协议。本文仅从原理上介绍两种协议,暂并不涉及编程。
1 TCP-UDP对比
相同点:
TCP和UDP都是网络层之上的,传输层协议,都能都能保护网络层的传输,双方的通信都需要开放端口,TCP和UDP中都存在复用和分用技术。
不同点:
一提到TCP-UDP的区别,大家最容易想到的便是TCP是可靠传输的,UDP是不可靠传输的,下面就简单罗列一下:
选项 | TCP | UDP |
---|---|---|
可靠性 | 全双工可靠传输无差错,不丢失,不重复,且按序到达 | 尽最大努力交付 |
建立连接 | 需要建立连接 | 无需建立连接 |
数据发送模式 | 面向字节流 | 面向报文 |
传输方式 | 点对点(不支持广播和多播) | 一对一,一对多,多对一,多对多 |
首部开销 | 20字节 | 8字节 |
拥塞机制 | 有 | 无 |
流量控制 | 有 | 无 |
系统资源占用 | 对系统资源要求较多 | 对系统资源要求较少 |
实时性 | 相对UDP较低 | 较高,适用于对高速传输和实时性要求较高的通信或广播通信 |
确认重传机制 | TCP提供超时重发,丢弃重复数据,检验数据, | 无重传,只是把应用程序传给IP层的数据报发送出去,但是并不能保证它们能到达目的地 |
对于上表中所述“数据发送模式”做一下简单补充:
对TCP:TCP不关心应用程序一次性把多长的数据报文发送到TCP缓存中,而是根据对方给出的窗口值和网络拥塞程度决定报文段应该包含多少字节.
对UDP:一次交付一个完整的报文,报文长度由应用程序给出。
2 UDP介绍
对于UDP的介绍以及提点在第一节比较中已做了详细描述,这里提一点:虽说UDP的不可靠传输特性在很多应用场景中大展身手,但是也要尽可能的提高UDP传输的可靠性。如何提高UDP的可靠性呢?应用程序可以在不影响应用的实时性的前提下,增加一个提高可靠性的措施,如采用前向纠错或重传已丢失的报文。
3 TCP介绍
对于TCP的介绍,主要围绕一个主题,为什么说TCP是可靠传输,下面会分别从可靠传输的原理和实现,面向连接,流量控制,拥塞控制,几个方面进行介绍。
对TCP的介绍有一个前提:只介绍单项传输,有A传输数据给B
3.1 可靠传输的原理和实现
3.1.1 可靠传输原理
可靠传输的原理主要依赖于两个协议:停止等待协议和连续ARQ协议,下面分别介绍之:
1 停止等待协议
当A向B传输数据时,A收到B的确认才发送下一个分组。如果收不到B的确认,A会重传上一个未收到确认的报文。具体确认重传机制如下:当A向B发送数据后,A会开启一个超时计时器,计时时间内收到B的确认,发送下一个报文,若计时器超时,还没有收到B发来的确认,A重传上一个未收到确认的报文。
在确认重传机制中存在一个“确认丢失和确认迟到”的现象。
“确认丢失”表示B发给A的确认报文在传输过程中丢失,A没有收到,当A的超时计数器超时后,A会重传报文,B接收到该重传报文后,丢弃该报文并重新发送确认。
“确认迟到”表示B发给A的确认报文卡在了传输过程中的某一个环节,A没有收到,当A的超时计数器超时后,A会重传报文,B接收到该重传报文后,丢弃该报文并重新发送确认,A接收到重复发来的确认报文后,丢弃该报文不做任何处理。
2 连续ARQ协议
在A发送报文时使用一个合适大小的窗口(也即后面提到的滑动窗口),A发送报文段从该窗口中依次发送,A每接收到一个确认,该窗口就向后移动一个报文段。此时B一般不会收到每个报文段都回复一个确认,而是采用累积确认的方式,即在B收到几个分组后,对按顺序到达的最后一个分组发送确认,表示到这个分组为止的所有分组都已经收到了。
3.1.2 可靠传输实现
在面向连接的基础上,主要是通过以字节为单位的滑动窗口,超时重传和选择确认这三种方式,并辅以流量控制和拥塞控制这两种机制,来实现TCP的可靠传输。
3.2 TCP面向连接管理
3.2.1 建立连接
如上图,是TCP建立连接的示意图,下面分布说明之:
1 考试客户端A和服务器端B都处于CLOSE
状态;并且A是主动打开连接,B是被动打开连接;
2 B的服务器进程创建传输控制块TCB,进入LISTEN
(收听)状态,等待客户端发送请求。TCB用来存储每一个连接中的一些重要信息,如TCP连接表,到发送和接收缓存的指针,到重传队列的指针,当前的发送和接受序号等;
3 客户端A也创建TCB,向B发出连接请求报文段,其中首部中同部位SYN = 1
,选择一个初始序列号seq = x
,进入SYN-SEND
(同步已发送)状态。SYN报文段不携带数据,占用一个序列号;
4 B收到请求报文段后,如同意连接,向A发送确认,其中SYN
和ACK
都置为1,确认号ack = x+1
,选择一个初始序列号seq = y
,进入SYN-RCVD
(同步收到)状态,该报文段不携带数据,占用一个序列号;
5 A收到B的确认后,再给B发确认,其中ACK = 1
,ack = y+1
,seq = x+1
。A进入ESTABLISHED
(已建立连接状态)。可带数据可不带,若不携带数据则不消耗序列号,下次发送数据序列号依旧是seq = x+1
。
6 B收到A的确认后,B进入ESTABLISHED
(已建立连接状态)。
3.2.2 释放连接
如上图,是TCP释放连接的示意图,下面分布说明之:
1 A,B都处于 ESTABLISHED
状态,假设A的进程先向B发出释放连接报文段,FIN = 1
,seq
等于上一次发送数据最后一个字节的序号加1;此时A进入FIN-WAIT-1
(终止等待1)状态;
2 B收到连接释放报文段后,发出确认,ACK
置为1,ack = u+1
,seq
等于上一次发送数据最后一个字节的序号加1;此时B进入CLOSE-WAIT
(关闭等待)状态;此时TCP服务器进程通知高层应用程序A到B的连接释放了,此时,A没有数据发送给B,但是B可以发送数据给A,A要接受;属于半关闭状态;
3 A收到来自B的确认后,进入FIN-WAIT-2
(终止等待2)状态,等待B发送释放连接报文段;在此期间,A有可能还会收到B发过来的数据;
4 当B没有数据发送到A时,向A发送连接释放报文段,FIN = 1
,假定B的req = w
(假设在半关闭状态B又向A发送数据),确认号重复上次的确认号ack = u+1
;此时B处于LAST-ACK
(最后确认)状态;
5 A收到B的连接释放报文段时,向B发出确认,ACK
置为1,自己的序列号req = u+1
(根据TCP规定,前面发送的FIN报文段需要消耗一个报文段);此时A进入TIME-WAIT
(时间等待)状态;此时,连接还没有释放,A等到2倍的最长报文段寿命MSL(4分钟)后,才能释放连接,A进入CLOSE
状态,随时准备下一个连接;
6 B收到A的确认后,进入CLOSE
状态,随时准备下一个连接。
3.3 流量控制
流量控制往往指点对点通信量的控制,是端到端的问题。流量控制所要做的就是:抑制发送端的发送速率,以便接收端来得及接收。
主要是由接收方通过发送给发送方的控制窗口的大小,开控制发送方的发送速率。
3.4 拥塞控制
拥塞控制是一个全局性的过程,涉及到所有的主机,所有的路由器等,主要是防止过多的数据注入到网络中,使网络能够承受现有的网络负荷。总之一句话,要做到可用的资源大于对网络资源的总需求,这样就能防止网络拥塞。
防止网络拥塞有两种方法,“慢开始和拥塞避免”和“快重传和快恢复”,下面分别介绍之:
1 慢开始和拥塞避免
前提:TCP中是以字节作为窗口的单位,这里为了描述方便,使用报文段的个数作为窗口的大小。
1 发送方开始发送数据时,拥塞窗口cwnd设置为一个最大报文段MSS的大小;
2 发送方收到确认后,发送方把拥塞窗口cwnd设置为2,这样发送方可以发送第二,第三个报文段;
3 发送方每收到一个报文段的确认后,cwnd的大小加1,由于接收方采用累积确认的方式,当发送方接收到报文段3的确认时,发送方把拥塞窗口cwnd设置为4;
4 这样,每经过一个轮次,cwnd就加倍。所谓轮次。是指把拥塞窗口cwnd所允许的所有报文段都发送出去,并收到对已发送的最后一个字节的确认,这个轮次称为一次往返时间RTT;
5 拥塞窗口cwnd以此指数规律增长,但并不能一直增长下去,会产生拥塞。此时设置一个慢开始门限ssthresh,当cwnd大于ssthresh时,使用拥塞避免算法;
以上是慢开始算法,以下是拥塞避免算法
6 当cwnd大于ssthresh时,ssthresh减为当前cwnd的一半大小(乘法减小),cwnd从1开始增加(加法增大),继续使用慢开始算法,依次循环使用两种算法。
总结:
cwnd > ssthresh时,使用慢开始算法
cwnd < ssthresh时,使用拥塞避免算法
cwnd = ssthresh时,两种算法都能使用
2 快重传和快恢复
1 假设接收方已经接收到第二个报文段,紧接着收到第四个报文段,没有收到第三个报文段,由于是TCP协议累积确认时针对按序到达的报文段,此时不能对第四个报文段确认,接收方只能发送第二个报文段的确认;
2 由于接受方的超时计数器还没有超时,发送方接着发送第五个报文段和第六个报文段;
3 接收方收到第五个报文段和第六个报文段时,还是没有收到第三个报文段,依次在收到第五个报文段和第六个报文段后向发送方回复第二个报文段的确认;
4 当发送方连续接收到三个确认报文后,就会使用快恢复算法
以上是快重传算法,以下是快恢复算法
5 当发送方连续接收到三个确认报文后,执行“乘法减小算法”,把慢开始门限ssthresh减半,cwnd设置为慢开始门限ssthresh减半后的数值,然后使用拥塞避免算法。