**计算机网络(自顶向下方法)**内容重点
第三章 运输层
- 运输层为运行在不同主机上的应用进程提供直接的通信服务(逻辑通信)起着至关重要的作用。
- 主要研究:
两个实体怎样才能在一种会丢失或损坏数据的媒体上可靠地通信;
控制运输层实体的传输速率以避免网络中的拥塞,或从拥塞中恢复过来。
3.1概述和运输层服务
- 应用层协议是在端系统中而不是在路由器中实现的。
- 在发送端,运输层将从发送应用进程接收到的报文转换成运输层分组,该分组称为运输层报文段。运输层将这些报文段传递给网络层,网络层将其封装成数据报并向目的地发送。
- 网络路由器仅作用于该数据报的网络层字段,不检查封装在该数据报的运输层报文段的字段。
- 在接收端,网络层从数据报中提取运输层保文段,并将该报文段向上交给运输层。
- 运输层处理接收到的报文段,使该报文段中的数据为接收应用进程使用。
3.1.1运输层和网络层的关系
- 网络层提供了主机之间的逻辑通信。
- 运输层为运行在不同主机上的进程之间提供逻辑通信。只工作在端系统中,将来自应用进程的报文移动到网络边缘(即网络层),对有关这些报文在网络核心如何移动并不做任何规定。
- 计算机网络可以安排多种运输层协议,每种协议为应用提供不同的服务模型。
- 运输层协议能够提供的服务往往受制于底层网络层协议的服务模型。
3.1.2因特网运输层概述
- UDP(用户数据报协议):不可靠、无连接
- TCP(传输控制协议):可靠、面向连接
- 面向连接的服务:通信双方在通信时要事先建立一条通信线路,其过程包括建立连接、使用链接、释放链接三个过程。
- 面向无连接的服务:通信双方不需要事先建立一条通信线路,而是把每个带有目的选址的包(报文分组)送到线路上,由系统选定路线进行传输。
- IP的服务模型是尽力而为交付服务,即不可靠服务
- UDP和TCP最基本的责任是:
- 将两个端系统间IP(主机)的交付服务扩展为运行在端系统上的两个进程之间的交付服务,即运输层的多路复用与多路分解
- 通过在其报文段首部中包括差错检查字段而提供完整性检查。
- UDP仅能做到以上两种进程到进程的数据交付和差错检查。UDP流量不可调节,使用UDP传输的应用程序可以根据其需要以其愿意的任何速率发送数据。
- TCP还能提供可靠数据传输、拥塞控制
3.2多路复用和多路分解
- 一个进程(作为网络应用的一部分)有一个或多个套接字,它相当于从网络向进程传输数据和从进程向网络传输数据的门户。
- 将运输层报文段中的数据交付到正确的套接字的工作称为多路分解
- 在源主机从不同套接字中收集数据块,并为每个数据块封装上首部信息(将在以后用于分解)从而生成报文段,然后将报文段传递到网络层,所有这些工作称为多路复用
- 多路复用要求:①套接字有唯一标识符;②每个报文段有特殊字段(源端口号字段和目的端口号字段)来指示该报文段所要交付到的套接字
- 端口号是一个16比特的数,大小在0-65535之间,用于区分应用层的不同应用进程。端口号只具有本地意义,即端口号只是为了标识本计算机应用层中的各进程,在因特网中,不同计算机中的相同端口号是没有联系的。
- 0-1023范围的端口号称为周知端口号,是受限制的,保留给诸如HTTP(80)、FTP(21/20)、DNS(53)之类的周知应用层协议来使用。
- 无连接的多路复用和多路分解
- 面向连接的多路复用和多路分解
- TCP套接字是由一个四元组来标识:
①源端口号
②源主机IP地址
③目的端口号
④自身IP地址 - 服务器主机可以支持很多并行的TCP套接字,每个套接字与一个进程相联系,并由其四元组来标识每个套接字。
- 即使两个主机向同一台服务器发送的请求中具有相同的源端口号,服务器也能通过不同的源IP地址识别会话。
- Web服务器与TCP
- 一台Web服务器为每条链接生成一个新进程,每个进程都有自己的连接套接字,通过这些套接字可以收到HTTP请求和HTTP响应。
3.3无连接运输:UDP
- 复用、分解及少量的差错检测功能。
- 使用UDP时,在发送报文段之前,发送方和接收方的运输层实体之间没有握手。所以,被称为无连接的。
- 适合UDP的特征:
- 应用层对何时发送、发送什么数据的控制更精细:
UDP从应用进程收到数据后立即打包并传递给网络层;TCP可能会因为拥塞控制机制和双方反复确认延迟传送。
实时应用要求最小发送速率,不希望过分地延迟报文段的传送,且能容忍一些数据丢失。 - 无需建立连接:
UDP不需要任何准备即可进行数据传输,因此不会引入建立连接的时延。
DNS使用UDP的主要原因:会快很多 - 无连接状态:
TCP需要在端系统中维护连接状态,包括接收和发送缓存、拥塞控制参数以及提供拥塞控制;UDP不维护连接状态也不跟踪参数。
某些专门用于某种特定应用的服务器当应用程序运行在UDP上时,一般都能支持更多的活跃用户。 - 分组首部开销小:
每个 TCP报文段有20个字节的首部;UDP只有8字节的首部。 - RIP路由选择表的更新使用UDP,因为更新被周期性发送(每五分钟一次),更新的丢失能被最近的更新所替代,因此丢包、过期的更新是无用的。
- UDP也用于承载网络管理数据。网络管理应用程序通常必须在该网络处于重压状态时运行,此时可靠的、拥塞控制的数据传输难以实现。
- 运行在TCP之上的有电子邮件、远程终端访问、Web以及文件传输。
- UDP中缺乏拥塞控制会导致发送方和接收方之间的高丢包率,并挤垮TCP会话。
- 使用UDP的应用程序可以在自身中建立可靠性机制来完成可靠数据传输。
3.3.1UDP报文段结构
- UDP的首部只有4个字段(源端口号、目的端口号、长度、检验和),每个字段有两个字节组成。
- 长度字段指示了在UDP报文段中的字节数(首部+数据)。
- 接收方使用检验和来检查在该报文段中是否出现了差错。
3.3.2UDP检验和
- 发送方的UDP对报文段中的所有16比特字的和进行反码运算(所有的1和0换成0和1),求和时遇到的任何溢出都被回卷(溢出的数位加到末尾),得到的结果被放在UDP报文段中的检验和字段。【检验和字段是反码】
- 在接收方,全部的和与检验和相加,若结果为全1,则正确。若出现一个0,则已经出现了差错。
- 提供检验和的原因:UDP在端到端提供差错检测,因为不能保证在源和目的之间的所有链路都提供差错检测,这就是系统设计中的端到端原则。
- UDP仅提供差错检测,对差错恢复无能为力。只能丢弃受损的报文段,或将受损的报文段交给应用程序并给出警告。
3.4可靠数据传输原理
借助于可靠信道,传输数据比特就不会受到损坏或丢失,而且所有数据都是按照其发送顺序进行交付。
3.4.1构造可靠数据传输协议
- 经完全可靠的可靠数据传输:rdt 1.0
发送无错误,无丢失,有序接收 - 经具有比特差错信道的可靠数据传输:rdt 2.0
发送有些比特可能受损,无丢失,有序接收
解决办法:
自动重传请求:
设置差错检测;
接收方反馈:1比特长:肯定确认“ACK”,用1表示;否定确认“NAK”,用0表示;
重传:当发送方处于等待ACK或NAK时,不能从上层获得更多数据;仅当接收到ACK并离开该状态时才能发送下一个数据,被称为停等协议。
- rdt2.1
ACK和NAK可能会受损
解决办法:
在数据分组中添加一个新字段,让发送方对其数据分组编号,即将发送数据分组的序号放在该字段。1比特序号即可,接收到的分组序号若与最近收到的分组序号相同则在重传上一个分组,不同则用模2“向前”移动。 - rdt2.2
实现没有NAK的反馈
解决办法:
接收方:受损则发送ACK和上一个分组序号;正确则发送ACK和这个分组序号。
发送方:必须检查接收到的ACK和报文中被确认的分组序号。
- 经具有比特差错的丢包信道的可靠数据传输:rdt3.0
发送有错误,有丢失
有时被称为比特交替协议。
解决办法:
让发送方负责检测和恢复丢包工作。如果超过一个往返时延(包括中间路由器的缓冲时延)加上接收方处理一个分组所需的时间则重传该分组。
为了实现基于时间的重传机制,需要一个倒数定时器。
发送方:①每次发送一个分组时,便启动一个定时器。②响应定时器中断(采取适当措施)③终止定时器。
3.4.2流水线可靠数据传输协议
-
rdt3.0性能问题的核心在于它是一个停等协议。
-
信道的利用率:发送方实际忙于将发送比特送进信道的那部分时间与发送时间之比。
U s e n d e r = L / R R T T + L / R U~sender~= \frac {L/R}{RTT\quad+\quad L/R} U sender =RTT+L/RL/RL为分组长度,R为发送速率,RTT为往返传播时延 -
利用率低
解决办法:
不使用停等协议,允许发送方发送多个分组而无需等待确认。(在等待确认之前发送n个报文,基本上利用率提高n倍)
-
对协议造成的影响:
- 必须增加序号范围
- 协议的发送方和接收方两端也许必须缓存多个分组。发送方最低限度应当能缓冲那些已发送但没有确认的分组。
- 所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。解决流水线的差错恢复有两种基本方法:回退N步和选择重传。
3.4.3回退N步(GBN协议)
允许发送方发送多个分组而不需等待确认,但受限于在流水线中未确认的分组数不能超过某个最大允许数N。
- 已发送但未被确认的分组的许可序号范围可以看做是一个长度为N的窗口。N为窗口长度,GBN也被称为滑动窗口协议。
- 若分组字段有k位,则序号范围在[0,2k-1]。所有涉及序号的运算必须模2k。
- 发送方必须相响应的三种类型的事件:
- 上层的调用:上层调用时,首先检查发送窗口是否已满,即是否有N个已发送但未被确认的分组。若未满,则产生一个分组并将其发送,并相应地更新变量。若已满,只需将数据返回给上层,隐式地指示上层该窗口已满。然后上层等会再试。
- 收到一个ACK:在GBN协议中,对序号为n的分组的确认采取累计确认的方式,表明接收方已正确接收到序号为n的以前且包括n在内的所有分组。
- 超时事件:发送方仅使用一个定时器,可被当做最早的已发送但是未被确认的分组所使用的定时器。如果收到一个ACK,但仍有已发送但未被确认的分组,则定时器被重新启动。如果没有已发送但未被确认的分组,该定时器被终止。
- 接收方动作很简单:
- 如果一个序号为n的分组被正确接收到,并且按序(即上次交付给上层的数据分组序号为n-1),则接收方为分组n发送一个ACK,并将分组中的数据部分交付到上层。
- 所有其他情况,接收方丢弃该分组。并为最近按序接收的分组重新发送ACK。,若接收到k的确认,则所有序号比k小的分组都被接收到了。
3.4.4选择重传(SR协议)
通过让发送方仅重传那些他怀疑在接收方出错的分组而避免不必要的重传。这种个别的、按需的重传要求接收方逐个地确认正确接收的分组。
对于SR协议而言,发送方和接收方的窗口并不总是一样的。
窗口长度必须小于或等于序号空间的一半
发送方
- 从上层收到数据
收到数据后,发送方检查下一个可用于该分组的序号。如果序号位于发送方的窗口内,则将数据打包并发送;否则就像在GBN中一样,要么将数据缓存,要么将其返回给上层以便以后传输。 - 超时:
定时器再次被用来防止丢失分组。每个分组必须拥有自己的逻辑定时器,因为超时发生后只能发送一个分组。 - 收到ACK:
如果收到ACK,若该分组在窗口内,SR发送方将那个被确认的分组标记为已接收。若果该分组为窗口第一个,则窗口向前移动到具有最小序号的未确认分组处。如果窗口移动了并且有序号落在窗口内的未发送分组,则发送这些分组。
接收方将确认一个正确接收的分组而不管其是否按序。失序的分组将被缓存直到所有丢失分组(即序号更小的分组)都被接收到为止,这时才可以将这一批分组按需交付给上层。
接收方
- 序号在窗口内的分组被正确接收:
若该分组没有收到过,则缓存该分组,如果该分组的序号等于接收窗口的基序号(第一个分组),则该分组以及以前缓存的序号连续的分组交付给上层。 - 序号在上一个窗口内的分组被正确接收:
必须产生一个ACK,即使该分组是接收方以前确认过的分组。 - 其他情况
忽略该分组。
3.5面向连接的运输:TCP
3.5.1TCP连接
- 一个应用进程可以向另一个应用进程发送数据之前,两个应用进程必须先互相“握手”,即必须相互发送某些预备报文段,已建立确保数据传输的参数。
- 连接状态完全保留在两个端系统中。TCP之在端系统中运行,而不在中间的网络元素(路由器和链路层交换机)中运行,所以中间网络元素不会维持TCP连接状态。
- TCP连接提供的是全双工服务,也总是点对点的,不可能出现多播。
- 发起连接的进程叫客户进程,另一个进程被称为服务器进程。
- TCP将通过套接字的数据引导到该连接的发送缓存里,发送缓存是在三次握手初期设置的缓存之一。
- TCP可从缓存中取出并放入报文段中的数据数量受限于最大报文段长度(MSS),MSS通产根据最初确定的由本地发送的最大链路层帧长度(最大传输单元,MTU)来设置。
- MSS是指在报文段里应用层数据的最大长度,而不是指包括TCP首部的TCP报文段的最大长度。
- TCP连接的组成包括:两台主机上的缓存、变量和进程连接的套接字。在这两台主机之间的网络元素(路由器、交换机和中继器)中,没有为该连接分配任何缓存和变量。
3.5.2TCP报文段结构
- 源端口号和目的端口号:用于多路复用/分解来自货送到上层应用的数据。
- 检验和字段
- 序号字段和确认号字段:用来实现可靠数据传输服务。
- 接收窗口字段:用于流量控制,指示接收方愿意接受的字节数量。
- 首部长度字段:由于TCP选项字段的原因,首部长度是可变的。
- 选项字段:用于发送方与接收方协商最大报文段长度(MSS)时,或高速网络环境下用作窗口调节因子时使用。
- 标志字段:ACK(确认)用于指示确认字段中的值是否有效;RST(复位)、SYN(同步)、FIN(终止)用于连接建立和拆除;PSH(推送)指示接收方应立即将数据交给上层;URG(紧急)用来指示报文段里存在着被发送端的上层实体置为“紧急”的数据;紧急数据指针字段指出紧急数据。
3.5.4可靠数据传输
- 有趣情况
- 超时间隔加倍
- 快速重传
- 回退N步还是选择重传
3.5.5流量控制
- 消除发送方使接收方缓存溢出的可能。
- 发送方的发送速率与接收方应用程序的读取速率相匹配。
- TCP通过让发送方维护一个称为接收窗口的变量来提供流量控制。
- 通过轮流跟踪两个变量LastByteSent和LastByteAcked来保证不会溢出,两变量之差即为发送方发送到连接中但是未被确认的数据量。保证该数据量控制在变量rwnd接收窗口的值以内,即接收方的接收缓存不会溢出。
- 当接收窗口为0时(会造成发送方不知道何时才能正常发送数据),发送方继续发送只有一个字节数据的报文段,来测试是否能够继续发送。
3.5.6TCP连接管理
- 建立连接-三次握手:
- 客户端向服务器端发送一个不包含应用层数据的TCP报文段。SYN为1,因此被称为SYN报文段。客户端随机选择初始序号放入序号字段。
- 服务器提取SYN报文段,为该连接分配TCP缓存和变量,并向客户端TCP发送允许连接的报文段。确认号字段为初始序号+1,服务器选择自己的初始序号放置到报文段里,表示允许连接,因此该报文段被称为SYNACK报文段。
- 客户要给该连接分配缓存和变量,并对发送报文段表示对允许连接的确认,将服务器的初始序号+1放入确认报文段,SYN置为0,序列号为开始发送报文段的第一个序号。
- 关闭连接-四次挥手:
- 客户向服务器发送FIN为1的报文段,
- 服务器回复确认报文段。
- 服务器发送自己的终止报文段即FIN为1,定时等待随后关闭连接。
- 客户回复确认报文段,然后定时等待两个MSL(最长报文段寿命)随后关闭连接。
3.6拥塞控制原理
3.6.1拥塞原因与代价
- 两个发送方和一台具有无穷大缓存的路由器:
- 当发送速率在0-R/2以内时,接收方的吞吐量等于发送方的发送速率;发送方速率超过R/2时,接收方的吞吐量只能达到R/2。吞吐量上限由两条连接之间共享链路容量造成的。
- 发送速率越接近R/2,平均时延就会越来越大。超过R/2时,路由器中的平均排队分组数就会无限增长。
- 代价:分组的到达速率接近链路容量时,分组经历巨大的排队时延。
- 两个发送方和一台具有有限缓存的路由器:
- 分组到达一个已满的缓存时就会被丢弃。
- 代价: 发送方必须重传以补偿因为缓存溢出而丢弃(丢失)的分组。
- 发送方因为发生超时而重传,但是接收方接收到了两份分组,重传分组被丢弃。
- 代价:发送方在遇到大时延时所进行的不必要的时延会引起路由器利用其链路带宽来转发不必要的分组副本。
- 四个发送方和具有有限缓存的多态路由器及多条路径
- 代价:一个分组沿一条路径被丢弃时,每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费掉。
3.6.2拥塞控制方法
- 端到端拥塞控制:
- 当TCP报文段丢失时,TCP会相应的减少其窗口长度。
- 使用增加的往返时延值作为网络拥塞程度增加的指示。
- 网络辅助的拥塞控制:
- 路由器向发送方提供关于网络中拥塞状态的显式反馈信息(以阻塞分组的形式)
- 路由器标记或更新从发送方流向接收方的分组中的某个字段来指示拥塞的产生。一旦收到一个标记的分组后,接收方就会向发送方通知该网络拥塞指示。(至少要经过一个完整的往返时间)
3.7TCP拥塞控制
必须使用端到端拥塞控制,因为IP层不向端系统提供显式的网络拥塞反馈。
- 拥塞窗口:cwnd,对一个TCP发送方能向网络中发送流量的速率进行了限制。特别的,在一个发送方中未被确认的数据量不会超过cwnd和rwnd(接收方窗口)中的最小值。
发送窗口的上限值 = Min [rwnd, cwnd]
当 rwnd < cwnd 时,是接收方的接收能力限制发送窗口的最大值。
当 cwnd < rwnd 时,则是网络的拥塞限制发送窗口的最大值。 - TCP拥塞控制算法
- 慢启动:
cwnd(拥塞窗口)以1个MSS开始传输,每当传输的报文段首次被确认就增加1个MSS。这样下去每过一个RTT,发送速率就翻番。
如果存在一个由超时指示的丢包事件(即拥塞),cwnd被设置为1并重新开始慢启动。第二个状态变量值ssthresh(慢启动阈值的速记)设置cwnd/2。
当cwnd等于ssthresh时,结束慢启动并且TCP转移到拥塞避免模式。当进入拥塞避免模式时,TCP更加谨慎地增加cwnd。
当监测到3个冗余ACK,这时TCP执行一种快速重传并进入快速恢复状态。 - 拥塞避免:
此时cwnd无法再翻番,而是每个RTT增加一个MSS。
拥塞避免并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。是指在拥塞避免阶段把拥塞窗口控制为按线性规律增长,使网络比较不容易出现拥塞。
- 快速恢复:
对收到的每一个冗余的ACK,cwnd就增加一个MSS。若丢失报文段的ACK到达,则降低cwnd后进入拥塞避免状态