第五章:运输层
1、运输层功能?
答:从通信和信息处理的角度看,运输层向它上面的应用层提供通信服务,它属于面向通信部分的最高层,同时也是用户功能中的最低层。运输层位于网络层之上,它为运行在不同主机上的进程之 间提供了逻辑通信(运输层主要任务),而网络层提供主机之间的逻辑通信。
显然,即使网络层协议不可靠, 运输层同样能为应用程序提供可靠的服务。
运输层的功能如下(与网络层区别):
(1)传输层提供应用进程之间的逻辑通信(即端到端的通信)。与网络层的区别是,网络层提供的是主机之间的逻辑通信。从网络层来说,通信的双方是两台主机, IP 数据报的首部给出了这两台主机的IP 地址,但“两台主机之间的通信”实际上是两台主机中的应用进程之间的通信,应用进程 之间的通信又称端到端的逻辑通信。
(2)复用和分用。复用是指发送方不同的应用进程都可使用同一个运输层协议传送数据;分用是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付到目的应用进程。
(3) 运输层还要对收到的报文进行差错检测(首部和数据部分);而网络层只检查IP 数据报的首 部,不检验数据部分是否出错。
(4)提供两种不同的传输协议,即面向连接的TCP 和无连接的UDP ;而网络层无法同时实现两种协议(即在网络层要么只提供面向连接的服务,如虚电路;要么只提供无连接服务,如数据报,而不可能在网络层同时存在这两种方式)。
2、UDP协议。
答:UDP是一种无连接的、不可靠的传输协议。相比TCP,它没有像序号和确认机制、超时重传、流量控制和拥塞控制等复杂的机制。RFC 768 定义的UDP 只是做了传输协议能够做的最少工作,它仅在IP 的数据报服务之上增加了两个最基本的服务:复用和分用以及差错检测。UDP的设计目标就是简单和高效,适用于对传输延迟要求较高、可以容忍数据丢失的应用场景。
UDP 具有如下优点:
(1) UDP 无须建立连接。因此UDP 不会引入建立连接的时延。试想如果DNS 运行在TCP 而非UDP 上,那么DNS 的速度会慢很多。HTTP 使用TCP 而非UDP, 是因为对于基于文本数据的Web网页来 说可靠性是至关重要的。
(2) 无连接状态。TCP 需要在端系统中维护连接状态。此连接状态包括接收和发送缓存、拥塞控制参数和序号与确认号的参数。而UDP 不维护连接状态,也不跟踪这些参数。因此,某些专用应用服务器使用UDP 时,一般都能支持更多的活动客户机
(3) 分组首部开销小。TCP 有20B 的首部升销,而UDP 仅有8B 的开销。
(4) 应用层能更好地控制要发送的数据和发送时间。UDP 没有拥塞控制,因此网络中的拥塞不会影响主机的发送效率。某些实时应用要求以稳定的速度发送,能容忍一些数据的丢失,但不允许有较大的时延,而UDP 正好满足这些应用的需求。
注意:UDP 提供尽最大努力的交付,即不保证可靠交付,但这并不意味着应用对数据的要求是不可靠的,因此所有维护传输可靠性的工作需要用户在应用层来完成。应用实体可以根据应用的需求来灵活设计自己的可靠性机制。
3、TCP协议。
答:TCP协议是在不可靠的IP 层之上实现的可靠的数据传输协议,它主要解决传输的可靠、有序、无丢失 和不重复问题。
TCP协议 是TCP/IP 体系中非常复杂的一个协议,主要特点如下:
(1) TCP 是面向连接的运输层协议。
(2)每条TCP 连接只能有两个端点,每条TCP 连接只能是点对点的(一对一)。
(3)TCP 提供可靠的交付服务,保证传送的数据无差错、有序、不丢失、不重复。
(4) TCP 提供全双工通信,允许通信双方的应用进程在任何时候都能发送数据,为此TCP 连接的两端都设有发送缓存和接收缓存,用来临时存放双向通信的数据。发送缓存用来暂时存放以下数 据:发送应用程序传送给发送方TCP 准备发送的数据;TCP 已发送但尚未收到确认的数据。 接收缓存用来暂时存放以下数据:按序到达但尚未被接收应用程序收取的数据;不按序到达的数据。
4、UDP协议与TCP协议对比。
答:面向连接的TCP 和无连接的UDP对比如下:
5、流量控制?
答:一般来说,我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快,接收方就可能来不及接收,这就会造成数据的丢失。所谓流量控制(flow control)就是让发送方的发送速率不要太快,要让接收方来得及接收。在运输层,TCP协议利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制,TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小;若TCP发送方收到接收方的零窗口通知,会启动持续计时器,持续计时器超时后,向接收方发送零窗口探测报文(避免陷入死锁)。
6.TCP四种拥塞控制算法?
答:拥塞控制是一种网络管理机制,旨在避免网络拥塞的发生或缓解已经发生的拥塞情况。在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络性能就要变坏这种情况就叫做拥塞(congestion)。若出现拥塞而不进行控制,整个网络的吞吐量将随输入负荷的增大而下降。因此非常有必要进行拥塞控制。
拥塞控制与流量控制的区别:拥塞控制是让网络能够承受现有的网络负荷,是一个全局性的过 程,涉及所有的主机、所有的路由器,以及与降低网络传输性能有关的所有因素。相反,流量控 制往往是指点对点的通信量的控制,即接收端控制发送端,它所要做的是抑制发送端发送数据的 速率,以便使接收端来得及接收。
TCP四种拥塞控制算法:
(1)慢开始算法(接收窗口rwnd,拥塞窗口cwnd)
在TCP 刚刚连接好并开始发送TCP 报文段时,先令拥塞窗口cwnd = 1, 即一个最大报文段长度 MSS 。使用慢开始算法后,每经过一个往返时延RTT, 拥塞窗口cwnd 就会加倍,即cwnd 的大小指数式增长。这样一直把拥塞窗口cwnd 增大到一个规定的慢开始门限ssthresh(阈值),然后改用拥塞避免算法。
(2)拥塞避免算法
发送端的拥塞窗口cwnd 每经过一个往返时延RTT 就增加一个MSS的 大小,按线性规律缓慢增长,而不是加倍 。当重传计时器超时时,判断网络很可能出现拥塞,将慢开始门限ssthresh值更新为发生拥塞时cwnd值的一半;将cwnd值减小为1,并重新开始执行慢开始算法。
(3)快重传
快重传并非取消重传计时器,而是在某些情况下更早地重传丢失的报文段。当发送方连续收到三个重复的ACK 报文时,直接重传对方尚未收到的报文段, 而不必等待那个报文段设置的重传计时器超时。
(4)快恢复
发送方一旦收到3个重复确认,就知道现在只是丢失了个别的报文段。于是不启动慢开始算法,而执行快恢复算法。发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半;开始执行拥塞避免算法。由于跳过了拥塞窗口cwnd 从1 起始的慢开始过程,所以被称为快恢复。
7、TCP可靠传输实现。
答:TCP可靠传输实现如下:
8、TCP使用“三报文握手”建立连接。
答:三次握手是 TCP 连接的建立过程。在握手之前,主动打开连接的客户端,结束 CLOSE 阶段,被动打开的服务器也结束 CLOSE 阶段,并进入 LISTEN 监听阶段。随后进入三次握手阶段:
答:在TCP 连接建立的过程中,要解决以下三个问题:
- 要使每一方都能够确知对方的存在。
- 要允许双方协商一些参数(如最大窗口值、时间戳选项及服务质量等)。
- 能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配。
注意:
- 主动发起TCP连接建立称为TCP客户(client)。
- 被动等待TCP连接建立的应用进程称为TCP服务器(server)。
第一步:客户的TCP 首先向服务器的TCP 发送一个连接请求报文段,首部中的同步位SYN被设为为1 (表明这是一个TCP连接请求报文段);并且客户会随机选择一个起始序号seq = x,连接请求报文不携带数据,但要消耗一个序号。
第二步:服务器的TCP 收到连接请求报文段后,如同意建立连接,就向客户发回确认,并为该 TCP 连接分配TCP 缓存和变量。在确认报文段中,同步位 SYN 和确认位ACK 都被设为1, 确认号字段的值为 x+ 1, 并且服务器随机产生起始序号seq= y, 确认报文不携带数据,但也要消耗一个序号。
第三步:当客户收到确认报文段后,还要向服务器给出确认,并且也要给该连接分配缓存和变 量。这个报文段的确认位ACK 被设为1, 序号字段为x+ 1, 确认号字段ack=y+ 1 。该报文段可以携带数据,若不携带数据则不消耗序号。
成功进行以上三步后,就建立了TCP 连接,接下来就可以传送应用层数据。TCP 提供的是全双工 通信,因此通信双方的应用进程在任何时候都能发送数据。
9、为什么不采用“两次握手”建立连接呢?
答:这主要是为了防止两次握手情况下已失效的连接请求报文段突然又传送到服务器而产生错误。考虑下面这种情况。TCP客户向TCP服务器发出TCP 连接请求,第一个连接请求报文在网络的某个结点长时间滞留, TCP客户超时后认为报文丢失,于是再重传一次连接请求, TCP服务器 收到后建立连接。数据传输完毕后双方断开连接。而此时,前一个滞留在网络中的连接请求到达TCP服务器, 而TCP服务器认为TCP客户又发来连接请求,此时若使用“三次握手”,则TCP服务器 向TCP客户返回确认报文段,由于是一个失效的请求,因此TCP客户不予理睬,建立连接失败。若采用的是“两次握手”,则这种情况下TCP服务器 认为传输连接已经建立,并一直 等待TCP客户传输数据,而TCP客户此时并无连接请求,因此不予理睬,这样就造成了TCP服务器的资源白白浪费。
10、TCP使用“四报文挥手”释放连接。
答:"四报文挥手"释放连接过程如下:
第一步:TCP客户打算关闭连接时,向TCP服务器发送一个连接释放报文段,并停止发送数据,主动关闭TCP 连接,该报文段的中止位FIN 和确认位ACK设为1, 序号seq= u(它等于前面已传送过的数据的最后一个字节的序号加1) ,FIN 报文段即使不携带数据,也要消耗一个序号;确认号设为v;
第二步:TCP服务器收到连接释放报文段后发出确认,该报文段的确认位ACK设为1,序号位v,确认号是ack = u + 1。此时,从客户到服务器这个方向的连接就释放了, TCP 连接处于半关闭状态,即TCP服务器若发送数据,TCP客户仍要接收,从服务器到客户机这个方向的连接并未关闭。
第三步:若服务器已经没有要向客户机发送的数据,就通知TCP 释放连接,此时其发出中止位FIN= 1和确认为ACK=1 的连接释放报文段,序号seq=w,确认号仍为ack=u+1;
第四步:TCP客户收到连接释放报文段后,必须发出确认。在确认报文段中, 确认位ACK 被置为1, 序号seq= u + 1, 确认号ack= w + 1。此时TCP 连接还未释放,必须经过时间等待计时器设置的时间 2MSL 后,TCP客户才进入连接关闭状态
11、为何不采用“三次握手“释放连接,且发送最后一次握手报文后要等待2MSL 的时间呢?
答:
(1) 保证TCP客户发送的最后一个确认报文段能够到达TCP服务器 。如果证TCP客户不等待2MSL, 若证TCP客户返回的最后确认报文段丢失,则TCP服务器不能进入正常关闭状态,而TCP客户此时已经关闭,也不可能再重传。
(2) 防止出现“已失效的连接请求报文段“。TCP客户在发送最后一个确认报文段后,再经过2MSL可保证本连接持续的时间内所产生的所有报文段从网络中消失。 服务器结束TCP 连接的时间要比TCP客户早一些,因为TCP客户最后要等待2MSL 后才可进入CLOSED 状态。
12、建立连接后,如果TCP客户进程所在主机出了故障,TCP服务器如何发现?
答:设置保活计时器。