计算机网络复习第五章传输层

网络层提供的是主机之间的通信。

运输层应用进程之间提供端到端的逻辑通信

两个主要协议:

用户数据报协议 UDP:

       一种无连接协议, 提供无连接服务, 传送数据之前不需要先建立连接

       传送的数据单位协议是 UDP 报文用户数据报

对方的运输层在收到 UDP 报文后,不需要给出任何确认

当运输层采用无连接的 UDP 协议时,这种逻辑通信信道是一条不可靠信道

传输控制协议 TCP:

       一种面向连接的协议, 提供面向连接的服务

       传送的数据单位协议是 TCP 报文段

       TCP 不提供广播或多播服务

       TCP 提供可靠的、面向连接、全双工的运输服务

开销大(协议数据单元的首部大, 处理机资源占用多)

运输层的复用与分用:

       在一台主机中经常有多个应用进程同时分别和另一台主机中的多个应用进程通信, 这表明运输层有一个很重要的功能——复用(发送方)分用(接收方)

端口:

       端口用一个 16 位端口号进行标志。

       端口号只具有本地意义,即端口号只是为了标志本计算机应用层中的各进程。

两个计算机中的进程要互相通信,不仅必须知道对方的 IP 地址(为了找到对方的计算机),而且还要知道对方的端口号(为了找到对方计算机中的应用进程)。

两大类端口:

       服务器端使用的端口号

              熟知端口,数值一般为 0~1023

登记端口号,数值为 1024~49151,为没有熟知端口号的应用程序使用的。使用这个范围的端口号必须在 IANA 登记,以防止重复。

客户端使用的端口号

       又称为短暂端口号,数值为 49152~65535,留给客户进程选择暂时使用。

用户数据报协议 UDP:

       UDP 只在 IP 的数据报服务之上增加了很少一点的功能

复用和分用的功能

差错检测的功能

      

       主要特点:

UDP 是无连接的

UDP 使用尽最大努力交付

UDP 是面向报文的->一次交付一个完整的报文

       发送方UDP 对应用程序交下来的报文,在添加首部后就向下交付 IP 层

       接收方 UDP 对 IP 层交上来的 UDP 用户数据报,在去除首部后就原封不动地交付上层的应用进程

UDP 没有拥塞控制->网络出现的拥塞不会使源主机的发送速率降低

UDP 多类型交互通信->支持一对一、一对多、多对一和多对多的交互通信

UDP 的首部开销小->只有 8 个字节,比 TCP 的 20 个字节的首部要短

UDP 的首部格式:

数据字段

首部字段:8 个字节,由 4 个字段组成,每个字段都是 2 个字节。

计算检验和时,临时把“伪首部”和 UDP 用户数据报连接在一起。伪首部仅仅是为了计算检验和(把首部和数据部分一起都检验)

UDP 基于端口的分用:

    当运输层从 IP 层收到 UDP 数据报时,就根据首部中的目的端口,把 UDP 数据报通过相应的端口,上交最后的终点——应用进程。

传输控制协议 TCP:

       面向连接的运输层协议

每一条 TCP 连接只能有两个端点,每一条 TCP 连接只能是点对点的(一对一)。

提供可靠交付的服务, 全双工通信

面向字节流(流入或流出进程的字节序列, 每一个字节都编上一个序号)

TCP 的连接:

       虚连接而不是一条真正的物理连接

       TCP 连接的端点不是主机,不是主机的IP 地址,不是应用进程,也不是运输层的协议端口。TCP 连接的端点叫做套接字 (socket) 或插口

       端口号拼接到IP 地址即构成了套接字(socket)

              套接字 socket = (IP地址 : 端口号)

      

可靠传输的工作原理:

       停止等待协议: (简单,缺点是信道利用率太低)

发送完一个分组停止发送等待对方的确认。收到确认后再发送下一个分组。

接收方接收M1时检测出了差错,就丢弃 M1,其他什么也不做,或者M1在传输过程中丢失了,这时接收方当然什么都不知道,也什么都不做。

为了保证接收方正确收到 M1可以采用超时重传:

发送方为每一个已发送的分组都设置了一个超时计时器,只要在超时计时器到期之前收到了相应的确认,就撤销该超时计时器,继续发送下一个分组,否则重新发送M1

              若接收方返回的确认传输时丢失了,发送方没收到确认,那么触发超时重传,那接收方会接收到重复的M1这时,先丢弃这个重复的M1,然后向发送方发送确认.

              若传输过程中没有出现差错,但接收方对分组M1的确认迟到了, 接收方会收到重复的M1,并要丢弃重复的M1,并重传确认分组发送方会收到重复的确认,收下后就丢弃

       发送完一个分组后,必须暂时保留已发送的分组的副本,以备重发.

       分组和确认分组都必须进行编号.

       超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些.

       如果发送方不断重传分组但总是收不到确认,就说明通信线路太差,不能进行通信。

       使用上述的确认和重传机制,我们就可以在不可靠的传输网络上实现可靠的通信。

这种可靠传输协议常称为自动重传请求 ARQ。意思是重传的请求自动进行的,接收方不需要请求发送方重传某个出错的分组。

信道利用率:

      

往返时间 RTT,分组发送时间 TD,接收方发送ACK确认帧的时延TA

      

流水线传输:

       发送方连续发送多个分组,不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地传送。

连续 ARQ 协议: 发送方每收到一个确认,就把发送窗口向前滑动一个分组的位置。

       滑动窗口协议:发送方维持的发送窗口,它的意义是:位于发送窗口内的分组都可连续发送出去,而不需要等待对方的确认。

       滑动窗口协议三个不同的功能:

              在不可靠链路上实现可靠的传输->接收到正确的数据帧才能滑动窗口

              保护帧的传输顺序

              支持流量控制

累积确认:

       接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认,而是对按序到达的最后一个分组发送确认,这样就表示:到这个分组为止的所有分组都已正确收到了。

Go-back-N(回退 N):

       表示需要再退回来重传已发送过的 N 个分组

采用连续ARQ协议双向通信的每一端都必须设有两个窗口,一个发送窗口和一个接收窗口。这四个窗口经常处于动态变化之中。

帧序号   

NS—发送序号

NR—确认号(接收序号)期望收到的对方发出的分组的发送序号

TCP 报文段的首部格式:

       TCP 虽然是面向字节流的,但 TCP 传送的数据单元却是报文段

       一个 TCP 报文段分为首部和数据两部分。

       首部前 20 个字节是固定的,后面有 4n 字节是根据需要而增加的选项 (n是整数)。因此TCP首部的最小长度是20字节

源端口和目的端口字段——各占2字节

       序号字段——占4字节。本报文段所发送的数据的第一个字节的序号

确认号字段——占4字节,期望收到对方的下一个报文段数据的第一个字节的序号

数据偏移(即首部长度)——占4位,它指出TCP报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位32位字(以4字节为计算单位)。   

保留字段——占6位,保留为今后使用,但目前应置为0

紧急URG——当URG=1时,表明紧急指针字段有效。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据)。

确认ACK——只有当ACK=1确认号字段才有效。当ACK=0时,确认号无效。

推送PSH (PuSH)——接收TCP收到PSH=1的报文段,就尽快地交付接收应用进程,而不再等到整个缓存都填满了后再向上交付。 

复位RST (ReSeT)——当RST=1 时,表明TCP连接中出现严重差错(如由于主机崩溃或其他原因),必须释放连接,然后再重新建立运输连接。

同步SYN——同步SYN=1表示这是一个连接请求连接接受报文

终止FIN (FINish)——用来释放一个连接FIN=1表明此报文段的发送端的数据已发送完毕,并要求释放运输连接。

窗口字段——占2字节,用来让对方设置发送窗口的依据,单位为字节。

检验和——占2字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时,要在TCP报文段的前面加上12字节的伪首部

紧急指针字段——占16位,指出在本报文段中紧急数据共有多少个字节(紧急数据放在本报文段数据的最前面)。 

选项字段——长度可变。最初只规定了一种选项,即最大报文段长度MSS(数据字段)

       其他选项:

              窗口扩大选项/时间戳选项/选择确认选项

填充字段——这是为了使整个首部长度4字节的整数倍

以字节为单位的滑动窗口:

已发送但未收到确认,发送窗口位置不变, 收到新的确认号,发送窗口和接收窗口向前滑动.

发送缓存: 暂时存放发送应用程序传送给发送方TCP准备发送的数据以及TCP已发送出但尚未收到确认的数据

接收缓存: 暂时存放按序到达的、但尚未被接收应用程序读取的数据以及不按序到达的数据

超时重传时间的选择:

       TCP 每发送一个报文段,就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认,就要重传这一报文段。TCP 采用了一种自适应算法,它记录一个报文段发出的时间,以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间 RTT

       TCP 保留了 RTT 的一个加权平均往返时间 RTTS(这又称为平滑的往返时间)。

第一次测量到 RTT 样本时,RTTS 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本,就按下式重新计算一次 RTTS:

           

RFC 2988 推荐的a值为 1/8,即 0.125。  

      

超时重传时间 RTO:略大于加权平均往返时间 RTTS

             

              RTTD 是 RTT 的偏差的加权平均值。

       β是个小于 1 的系数,其推荐值是 1/4,即 0.25。

利用滑动窗口实现流量控制:

TCP 为每一个连接设有一个持续计时器来防止发生死锁.

TCP 的拥塞控制:

       在某段时间,若对网络中某资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。这种现象称为拥塞 (congestion)。

       拥塞引起的重传并不会缓解网络的拥塞,反而会加剧网络的拥塞

      

开环控制方法:在设计网络时事先将有关发生拥塞的因素考虑周到,力求网络在工作时不产生拥塞。

闭环控制方法:基于反馈环路的概念。

TCP 采用基于窗口的方法进行拥塞控制。该方法属于闭环控制方法。

       TCP发送方维持一个拥塞窗口 CWND (Congestion Window)

拥塞窗口的大小取决于网络的拥塞程度,并且动态地在变化。

发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量。

发送窗口大小不仅取决于接收方公告的接收窗口,还取决于网络的拥塞状况.

所以真正的发送窗口值为:Min(公告窗口值,拥塞窗口值)

只要网络没有出现拥塞拥塞窗口就可以再增大一些,以便把更多的分组发送出去,这样就可以提高网络的利用率

但只要网络出现拥塞或有可能出现拥塞,就必须把拥塞窗口减小一些,以减少注入到网络中的分组数,以便缓解网络出现的拥塞。

判断网络出现拥塞:

       重传定时器超时

       收到三个相同(重复)的 ACK

TCP拥塞控制算法:

       慢开始 (slow-start): 由小到大逐渐增大拥塞窗口数值

              初始拥塞窗口设置为1 至 2 个发送方最大报文段 SMSS的数值。

              发送方每收到一个对新报文段的确认(不算重传)就使cwnd(拥塞窗口)加1。

              每经过一个传输轮次 (往返时间 RTT),拥塞窗口 cwnd 就加倍。

拥塞避免 (congestion avoidance): 设置慢开始门限状态变量 ssthresh

       cwnd < ssthresh 时,使用慢开始算法。

cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法

cwnd = ssthresh 时,既可使用慢开始算法,也可使用拥塞避免算法

拥塞窗口 cwnd 缓慢地增大,即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1,而不是加倍,使拥塞窗口 cwnd 按线性规律缓慢增长

无论在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(重传定时器超时):

ssthresh = max(cwnd/2,2)   cwnd = 1

执行慢开始算法   

              (拥塞窗口置为1,ssthresh初始值设置为16个报文段)

发送方一连收到 3 个对同一个报文段的重复确认(图中记为3-ACK)。发送方改为执行快重传快恢复算法。

快重传 (fast retransmit):发送方尽早知道发生了个别报文段的丢失

       首先要求接收方不要等待自己发送数据时才进行捎带确认,而是要立即发送确认,即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认

快恢复 (fast recovery)

       发送端收到连续三个重复的确认时,由于发送方现在认为网络很可能没有发生拥塞,此时执行快恢复.

       (1) 慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2

       (2) 新拥塞窗口 cwnd = 慢开始门限 ssthresh

(3) 开始执行拥塞避免算法,使拥塞窗口缓慢地线性增大

发送窗口的上限值:

       接收方窗口 rwnd 拥塞窗口 cwnd 这两个变量中较小的一个.

运输连接的三个阶段:

       连接建立(握手): 需要在客户和服务器之间交换三个TCP报文段。称之为三报文握手

              (采用客户服务器方式)

              A (客户)的 TCP 向 B(服务器)发出连接请求报文段,其首部中的同步位 SYN = 1,并选择序号 seq = x,表明传送数据时的第一个数据字节的序号是 x

              B 的 TCP 收到连接请求报文段后,如同意,则发回确认

             B 在确认报文段中应使 SYN = 1,使 ACK = 1,其确认号ack = x +1,自己选择的序号 seq = y

              A 收到此报文段后向 B 给出确认,其 ACK = 1,确认号 ack = y + 1。A的TCP 通知上层应用进程,连接已经建立。

              B 的 TCP 收到主机 A 的确认后,也通知其上层应用进程:TCP 连接已经建立。  

数据传送

连接释放(四报文握手)

       数据传输结束后,通信的双方都可释放连接。

现在 A 的应用进程先向其TCP发出连接释放报文段,并停止再发送数据,主动关闭TCP连接

      A把连接释放报文段首部的 FIN = 1,其序号seq = u,等待 B 的确认。

       B 发出确认,确认号 ack = u +1,而这个报文段自己的序号 seq = v

      TCP 服务器进程通知高层应用进程。从A到 B 这个方向的连接就释放了,TCP 连接处于半关闭状态。B 若发送数据,A 仍要接收。

       若 B 已经没有要向 A 发送的数据,其应用进程就通知 TCP 释放连接。

       A 收到连接释放报文段后,必须发出确认。

       在确认报文段中 ACK = 1,确认号 ack = w +1,自己的序号 seq = u + 1

       TCP 连接必须经过时间2MSL(最长报文寿命)后才真正释放掉。

  • 14
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值