南理工计算机考研笔试第3章 运输层05.docx
- 文档编号:27349523
- 上传时间:2023-06-29
- 格式:DOCX
- 页数:52
- 大小:3MB
南理工计算机考研笔试第3章 运输层05.docx
《南理工计算机考研笔试第3章 运输层05.docx》由会员分享,可在线阅读,更多相关《南理工计算机考研笔试第3章 运输层05.docx(52页珍藏版)》请在冰豆网上搜索。
南理工计算机考研笔试第3章运输层05
第3章运输层
位于应用层和网络层之间。
为运行在不同主机上的应用进程提供直接的通信服务。
主要内容:
·运输层和网络层的关系;
·两个实体如何可靠地通信;
·拥塞控制技术。
3.1概述和运输层服务
运输层协议:
·为运行在不同主机上的应用进程提供逻辑通信功能。
即
运行不同进程的主机好像是直接相连的。
·应用进程使用逻辑通信功能彼此发送报文,无需考虑具体物理链路。
如图3.1。
·运输层协议在端系统中,而不是在路由器中实现;
发送方:
运输层将应用进程的报文封装成报文段,传给网络层,网络层封装成数据报向目的地发送。
接收方:
网络层从数据报中提取报文段,上传给运输层。
路由器只根据网络层字段而动作。
3.1.1运输层和网络层的关系
·运输层位于网络层上;
·运输层为运行在不同主机上的进程之间提供逻辑通信;
·网络层提供了主机之间的逻辑通信。
例:
东海岸家庭和西海岸家庭的堂兄弟姐妹之间互相通信。
·每封信通过传统的邮政服务发送。
·每家有一个孩子负责收发邮件,分别为Ann和Bill;
·邮政服务为两个家庭间提供逻辑通信:
将信件从一家送往另一家。
·Ann和Bill为堂兄弟姐妹之间提供了逻辑通信:
向兄弟姐妹收取或交付信件。
Ann和Bill是端到端交付过程的一部分(即端系统部分),是邮件服务。
与网络术语对比:
应用层报文=信封上的字
进程=堂兄弟姐妹
主机(端系统)=家庭
运输层协议=Ann和Bill
网络层协议=邮政服务(包括邮车)
说明:
Ann和Bill在各自家里工作,不参与邮件分拣及传递:
·运输层协议工作在端系统中,将来自应用进程的报文移动到网络边界(网络层),不考虑报文在网络核心如何移动;
·中间路由器既不处理也不识别运输层加在报文上的任何信息。
Ann和Bill外出,其他人接替工作,服务方式、效果可能不同:
计算机网络中有多种运输层协议,每种协议为应用程序提供不同的服务模型。
Ann和Bill能够提供的服务要受到邮政服务提供服务的限制。
运输层协议所能提供的服务受底层网络协议服务模型的限制。
如,时延和带宽保证。
某些特定服务既使底层网络协议不提供,运输层协议也能提供。
如,当底层网络协议是不可靠的(分组丢失、混乱和重复),运输层同样能为应用程序提供可靠的传输服务。
3.1.2因特网运输层概述
因特网运输层协议:
·UDP(用户数据报协议):
为应用程序提供不可靠、无连接的服务。
·TCP(传输控制协议):
为应用程序提供可靠的、面向连接的服务。
术语:
·报文段(segment):
运输层分组。
·数据报(datagram):
网络层分组。
因特网网络层协议:
·IP(网际协议):
为主机之间提供逻辑通信。
·IP服务模型:
尽力交付服务(best-effortdeliveryservice)。
尽最大的努力在通信的主机之间交付报文段,但不保证按序交付或数据的完整性。
属于不可靠服务。
·IP地址:
主机的网络层地址。
每台主机有一个。
UDP和TCP的服务模型:
·将两个端系统间IP的交付服务扩展为运行在两个端系统上的进程之间的交付服务。
运输层的多路复用与分解:
将主机间交付扩展到进程间交付。
·可提供完整性检查。
·UDP是不可靠服务,TCP提高可靠数据传输及流量控制。
3.2多路复用与多路分解
运输层的多路复用与多路分解:
将网络层所提供的主机到主机交付服务扩展到在主机上运行的应用程序到应用程序的交付服务。
通常,主机上可以有多个应用程序进程运行(如一个HTTP、一个FTP、两个Telnet)。
当运输层从底层网络接收数据时,应能正确地定向到相应的一个进程。
套接字:
从网络向进程传递数据,或从进程向网络传递数据的门户。
即运输层和应用进程通过套接字来传递数据。
主机上的套接字可以有多个,每个套接字都有惟一的标识符(格式取决于UDP或TCP)。
多路复用(multiplexing):
从源主机的不同套接字收集数据块,并为每个数据块封装上首部信息,生成报文段,传递到网络层。
多路分解(demultiplexing):
将运输层报文段中的数据交付到正确的套接字。
接收方运输层从报文段的多个字段中,标识出套接字,并将报文段定向到该套接字。
例,图3-2中,进程P3向进程P1发送。
·A主机上的运输层收集套接字输出的数据,形成运输层报文段,将其传递给下面的网络层,(多路复用);
·B主机的运输层将从其网络层收到的报文段多路分解后通过相应的套接字交给其上的Pl进程。
报文段格式:
源端口号
目的端口号
其他首部字段
应用数据(报文)
·端口号:
主机上的每个套接字分配一个端口号。
16位(0~65535)。
0~1023为周知端口号,保留给固定的应用程序。
开发一个新应用时,需选择一个端口号。
目的主机的分解过程:
·主机上的每个套接字分配一个端口号。
·当报文段到达主机时,运输层检查报文段中的目的端口号,将其定向到相应的套接字。
·报文段中的数据通过套接字进入其所连接的进程。
1、无连接的多路复用与多路分解
创建UDP套接字:
·运输层自动为该套接字分配一个端口号。
如
DatagramSocketmySocke=newDatagramSocket();
从1024~65535的号码中分配一个主机尚末使用的UDP端口号。
·直接为UDP套接字指定一个特定的端口号。
如
DatagramSocketmySocke=newDatagramSocket(l9157);
·应用程序的客户机端自动地分配端口号,服务器端分配一个特定的端口号。
·如果是“周知协议”的服务器端,必须分配一个相应的周知端口号。
UDP的多路复用与多路分解:
图3-4
假定:
主机A中的一个进程向主机B中的另一进程发送一个应用程序数据块。
·主机A的进程:
使用端口号为19157的UDP套接字;
·主机B的进程:
使用端口号为46428的UDP套接字。
主机A的多路复用:
·运输层创建一个报文段:
包括数据、源端口号、目的端口号等。
·将生成的报文段传递到网络层;
·网络层将该报文段封装到IP报文中,并尽力交付给接收主机。
主机B的多路分解:
UDP报文段到达接收方,主机B通过检查该报文段中的目的端口号,将报文段定向(多路分解)到相应的套接字,并交给相应进程。
说明:
·UDP套接字组成:
二元组(IP地址,端口号);
·两个具有不同源套接字,但具有相同目的套接字的UDP报文段,可通过相同套接字定向到相同的目的进程;
·源端口号的用途:
目的方回发报文段中的“返回地址”。
2、面向连接的多路复用与多路分解
·TCP套接字:
四元组(源IP地址,源端口号,目的IP地址,目的端口号);
·目的主机使用全部四个值来将收到的TCP报文段定向(分解)到相应的套接字。
·两个具有不同源套接字的到达TCP报文段,将被定向到两个不同的套接字。
TCP连接及分解:
·服务器应用程序在某个端口上等待TCP客户机连接建立请求。
如
ServerSocketwelcomeSocke=newserverSocket(6789);
·TCP客户机在相应端口上产生一个连接建立请求报文段。
如
SocketclientSocke=newSocket("serverHostName",6789);
·当服务器收到客户机的连接请求报文段后,就通知服务器进程,并创建一个连接套接字。
如,
SocketconnectionSocket=WelcomeSocket.accept();
连接套接字通过(源端口号,源主机IP地址,目的端口号,目的IP地址)4个值来标识。
·TCP连接完成后,客户机和服务器可相互发送数据。
当一个TCP报文段到达主机时,根据4个字段值的来定向(多路分解)到相应的套接字。
例,如图3-5。
主机C向服务器B发起两个HTTP会话;主机A向服务器B发起一个HTTP会话。
·主机A、C及服务器B都有各自的惟一IP地址,分别是A、C和B。
·主机C为两个HTTP连接分配两个不同的源端口号(26145和7532)。
·主机A为其HTTP连接分配源端口号26145。
·Web服务器HTTP连接端口号为80。
说明:
·一个web服务器可以同时与多个客户机连接,并产生多个进程。
·每个进程都有自己的连接套接字,通过这些套接字可以收到HTTP请求和发送HTTP响应。
·高性能Web服务器通常只使用一个进程,但是为每个新的客户机连接创建一个具有新连接套接字的新线程(是一个轻量级的子进程)。
·持久HTTP,客户机与服务器之间经由同一个服务器套接字交换HTTP报文。
·非持久HTTP,每一对请求/响应,都要创建一个新的TCP连接,响应后即关闭。
影响Web服务器的性能。
3.4可靠数据传输的原理
可靠数据传输的问题在运输层、链路层及应用层都会出现。
图3-8说明可靠数据传输的框架。
·提供给上层的服务:
数据可以通过一条可靠的信道传输。
即传输的数据不会出错、丢失,并按照发送顺序传送。
图3-8(a)
·服务实现:
由可靠数据传输协议负责。
由于现实存在的各种干扰,低层信道可能不太可靠,通过使用可靠数据传输协议来保证可靠的数据传输。
需要分别设计开发可靠数据传输协议的发送方和接收方。
图3-8(b)说明数据传输协议的接口。
发送方:
·通过rdt_send()函数调用可靠数据传输协议的发送方(rdt表示“可靠数据传输”协议)。
·udt_send()用来发送分组给对方(udt表示“不可靠数据传输”)。
接收方:
·当一个分组从信道抵达时,调用rdt_rcv()接收;
·调用deliver_data()将数据交付给上层。
本节,只介绍单向数据传输,即数据传输是从发送方到接收方。
·除了数据分组外,发送方和接收方还需来回交换控制分组。
3.4.1构造可靠的数据传输协议
一、完全可靠信道上的可靠的数据传输:
rdt1.0
假设:
·底层信道完全可靠,数据传送不出错不丢失;
·收发双方速率匹配:
接收方接收数据的速率和发送方发送数据一样快。
rdt1.0发送和接收方的有限状态机FSM,如图3-9。
说明:
·发送方和接收方有各自独立的FSM,并且都只有一个状态。
·箭头表示协议从一个状态变迁到另一个状态。
·横线上方:
表示引起变迁的事件;
横线下方:
表示事件发生时所采取的动作;
:
表示没有事件或未采取动作
·虚线表示FSM的初始状态。
发送方:
从上层接受数据rdt_send(data)封装成分组make_pkt(data)将分组发送到信道中udt_send(packet)
接收方:
从底层信道接收一个分组rdt_rcv(packet)解封取出数据extract(packet,data)数据传给上层deliver_data(data)
·
所有的分组都是从发送方流向接收方;
·接收方不需反馈信息给发送方,因为不会发生任何差错。
二、具有比特差错信道上的可靠的数据传输:
rdt2.0
·信道不完全可靠,有可能产生比特错,但不丢包;
·所有分组按发送顺序被接收(有些比特可能出错)。
类比例:
打电话传递一条长信息,报文接收者:
·听清每句话后说“OK”(肯定确认);
·听到不清楚的话,要求对方重复说“请重复一遍”(否定确认)。
肯定、否定确认作用:
接收方使发送方知道哪些内容被正确接收(肯定确认),哪些有误需要重传(否定确认)。
基于重传机制的可靠数据传输协议称为自动重传请求协议ARQ(AutomaticRepeatrequest)。
ARQ协议处理比特差错机制:
·差错检测:
使接收方检测出是否出现比特差错。
如采用差错检测和纠错技术,使接收方能够进行差错检测并纠正。
可以给分组附加额外的比特一起发送。
如rdt2.0协议中,放在分组的检验和checksum字段中。
·接收方反馈:
使发送方知道发送的分组是否被正确接收。
可以通过接收方回送肯定确认(ACK)和否定确认(NAK)分组完成。
如rdt2.0协议中,接收方将向发送方回送ACK(“1”比特)或NAK(“0”比特)分组。
·重传:
接收方收到有差错的分组时,通知发送方重传该分组。
rdt2.0的FSM如图3-10。
该数据传输协议采用了差错检测、肯定确认与否定确认。
发送方FSM:
左边状态:
等待上层数据上层数据传来rdt_send(data)计算校验和,封装成分组make_pkt(data,checksum)发送分组udt_send(sndpkt)
右边状态:
·收到ACK分组rdt_rcv(revpkt)&&isACK(rcvpkt)返回左边状态
·收到NAK分组rdt_rcv(revpkt)&&isNAK(rcvpkt)重传上次发送的分组udt_send(sndpkt)等待ACK或NAK
说明:
·当发送方在等待ACK或NAK状态时,不能从上层得到数据,直到收到ACK离开该状态。
·发送方在收到ACK分组之前,不会发送任何新数据,直到收到ACK分组为止。
rdt2.0协议称为停等(stop-and-wait)协议。
停等(stop-and-wait)协议:
发送方发完一个分组后停止,等待对方回答。
接收方FSM:
从底层接收一个分组,检查校验和:
·分组受损rdt_rcv(rcvpkt)&&corrupt(rcvpkt)丢弃分组返回NAK分组udt_send(NAK)
·分组无错rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)从分组中取出数据extract(rcvpkt,data)将数据传给上层deliver_data(data)返回ACK分组udt_send(ACK)
rdt2.0协议:
·可以解决数据分组出错的问题。
·若返回的ACK或NAK分组受损,发送方无法知道接收方是否正确接收了上一块数据。
处理受损ACK和NAK的可能方法:
·收发双方互不理解对方回答的含义:
对话不能正常进行;
·增加足够的检验和比特:
使发送方不仅可以检测差错,还可进行恢复。
适用于会产生差错但不丢失分组的信道。
·当发送方收到含糊不清的ACK或NAK分组时:
只简单地重发当前数据分组。
冗余分组(duplicatepackets):
同一个分组收到两次。
接收方无法知道收到的是新的分组还是重传的分组。
解决冗余分组的方法:
给分组添加一个序号字段。
·发送方:
给发送的数据分组编号,并将其序号放入“序号字段”。
每发送一个新的分组“序号加1”;
·接收方:
通过检查序号,确定收到的分组是不是重复传送。
按序号接收,若本次接收到的分组序号与前一次收到的分组的序号相同,即为重复分组,将该重复分组丢弃。
序号位数选择:
停等协议只需用一个比特,即“0”和“1”两种不同的序号。
序号通过模2运算向前移动,可以区分前后相邻的两帧。
0、1、0、1、……
说明:
·ACK和NAK分组本身不需要序号。
因为假设信道不丢失分组。
·发送方知道所接收的ACK和NAK分组是对最近发送分组的响应。
rdt2.1协议FSM:
rdt2.0改进,可处理重复分组。
如图3-11和3-12。
·指出正发送或准备接收的分组的序号。
·发送或期望接收0号分组的状态中的动作与发送或期望接收1号分组的状态中的动作相似的,只是序号处理方法不同。
·使用了从接收方到发送方的肯定和否定确认。
rdt2.1协议发送方:
rdt2.1协议接收方:
·收到乱序的分组时,即是重复分组,丢弃,并回发一个肯定确认;
·收到受损的分组时,丢弃,并回发一个否定确认。
进一步改进:
·接收方收到受损的分组时,丢弃,不发送NAK,改为发送一个对前一个正确接收分组的ACK。
·发送方接收到对同一个分组的两个ACK(接收冗余ACK)后,可知道接收方没有正确接收到跟在被确认两次的分组后面的分组。
rdt2.2协议:
rdt2.1改进,无NAK。
·接收方回发的ACK分组中,包括一个被确认的分组的序号make_pkt(ACK0或ACK1);
·发送方必须检查ACK分组中所确认的分组的序号。
rdt2.2协议发送方:
rdt2.2协议接收方:
三、具有比特差错的丢包信道上的可靠的数据传输:
rdt3.0
·会出现比特差错;
·会丢包:
发送的数据分组丢失,或接收方回发的ACK丢失。
主要问题:
如何检测丢包以及发生丢包后该如何处理。
解决方法:
由发送方负责检测丢包和恢复,即“超时重发”。
发送方发送一个数据分组后,等待一定时间,如果该段时间内没有收到ACK,则重传分组。
时间选择:
通常为“从发送方发出分组到收到接收方应答所需的平均时间”。
特例:
一个分组在网络中经历了一个特别大的时延,使发送方重传该分组(该数据分组或ACK并未丢失),产生冗余分组(可通过设置序号解决)。
重传的实现:
设置一个“递减(倒countdowntimer)计数定时器”,给定时间过期后,中断发送方。
要求发送方:
·每发送一个分组(包括第一次和重发的分组),启动一个定时器;
·响应定时器中断(采取适当的动作);
·终止定时器。
rdt3.0的发送方,如图3-15。
图3-16说明几种情况下协议的运作。
rdt3.0也被称为比特交替协议(分组序号在0和1之间交替)。
保证可靠数据传输协议的要点:
检验和、序号、定时器、重传、肯定和否定确认。
四、停止等待协议流程
·V(S):
发送序号变量,发送新分组时,V(S)+1;
·N(S):
分组序号字段,当前传送分组的编号;
·V(R):
接收序号变量,当前准备接收的分组序号,每收到一个新分组时,V(R)+1;
·判断重复分组:
N(S)V(R),收到的是新数据分组;
N(S)V(R),收到的是重复分组。
发送方:
接收方:
3.4.2流水线可靠数据传输协议
停等协议的性能:
发送方(信道)利用率Usender=
发送方将比特发送到信道的时间/发送时间
传输时延:
发送方将比特发送到信道的时间
发送时间:
发送方从发送分组开始,到收到对方ACK分组,所需的时间。
两台端主机之间进行理想的通信。
如图3-17所示。
假设:
·两个端系统之间的光速往返传播时延RTT约30ms;
·信道传输速率为R=1Gb/s(109bit/s);
·分组长L=1000字节
传输时延:
发送一个分组到链路中所需的时间
发送时间:
L/R+RTT=30.008ms
图3-18(a)说明停等协议中,发送方从发送分组开始,到收到对方ACK分组,所需的时间。
停等协议信道利用率:
发送方只有0.027%的时间忙。
发送方在30.008ms内只能发送l000byte,有效的吞吐量仅为267kbit/s(即使有1Gbit/s的链路可用)。
简单改进方法:
允许发送方连续发送多个分组而无需等待确认,如图3-17(b)例。
称为流水线技术。
图3-18(b)例,发送方在等待确认之前连续发送3个报文。
其利用率提高3倍。
N为连续发送分组个数。
流水线技术对可靠数据传输协议影响:
增加序号范围:
由于可连续发送多个分组,每个分组有唯一序号,可能有多个在传输中的未确认报文。
需要缓存多个分组:
·发送方至少能缓冲已发送但没有确认的分组;
·接收方可以缓存已正确接收的分组。
序号范围和对缓冲的要求取决于数据传输协议处理丢失、差错及过度延时分组的方式。
流水线的差错恢复方法,可分两类:
·回退N步(Go-Back-N)
·选择性重传(selective repeat)
3.4.3Go-Back-N(GBN)
基本思想:
发送方:
连续发送多个数据分组,停止等待
·收到确认ACK,继续发送后面分组;
·超时,未收到应答,从出错分组开始重发
接收方:
按序号接收数据分组
·正确:
接收处理,发确认ACK;
·出错:
将该分组及后面分组均丢弃,不发任何应答。
工作示意图:
说明:
·连续发送的分组个数不能太多:
增加序号字段位数;出错时,要重传很多数据分组,影响效率。
·连发个数受流水线中未确认的分组数限制,不能超过最大允许数N。
通过设置发送窗口和接收窗口来分别控制连续发送和接收的分组个数。
1、发送窗口:
控制发送方连续发送的个数。
实际是允许连续发送的序号表,只有落在发送窗口所含序号之内的,才能不等待应答发送。
图3-19说明:
·基序号(base):
最早的未确认分组的序号;
·下一个序号(nextseqnum):
最小的未使用序号(即下一个待发分组的序号)
序号范围分割成4部分:
·[0,base-1]:
已经发送并确认过的分组。
·[base,nextseqnum-1]:
已经发送但未被确认分组。
·[nextseqnum,base+N-1]:
用于将立即发送的分组。
·base+N:
不能使用,直到当前流水线中未被确认的分组得到确认(序号为base的分组)。
发送窗口大小(windowsize)WT:
WT=N,即序号范围[base,base+N-1],包括已发送未被确认的分组、以及准备发送的序号N的分组。
随着协议的运行,发送的分组陆续被确认,发送窗口在序号空间内向前滑动。
GBN协议常被称为滑动窗口协议(sliding-windowprotocol)。
2、序号取值范围:
如果分组序号字段的位数是k,则序号范围是[0,2k-1]。
即序号在0~2k-1的范围循环,0,1,…,2k-1,0,…。
停等协议序号字段的位数是1,序号范围是[0,1]。
3、发送方扩展FSM:
图3-20和图3-21给出了一个基于ACK、无NAK的GBN协议。
GBN发送方响应三种事件:
上层的调用:
上层调用rdt_send()检查发送窗口是否已满(是否有N个已发送、但未被确认的分组)
·窗口未满:
创建一个分组并将其发送,更新变量;
·窗口已满:
将数据返回给上层,以后再试。
收到ACK:
对序号为n的分组的确认使用累积确认,即表明接收方已正确接收到序号为n及以前的所有分组。
超时:
设置定时器处理“丢失数据或确认分组”的情况。
只使用一个定时器,作为最早的已发送但未被确认的分组的定时。
·产生超时,发送方重发所有已发送过但还未被确认过的分组。
·收到一个ACK,但仍有已发送但未被确认的分组,重新启动定时器。
若没有未确认报文,终止定时器。
4、接收方
按序接收。
接收方WR=1。
接收方扩展FSM:
·正确按顺序接收到序号为n的分组:
将分组中的数据交付到上层,并回发一个ACK;
·其他情况的分组:
丢弃该分组,并为最近按序接收的分组重发ACK。
·分组一次性交付给上层:
分组k被交付,之前均已交付。
·丢弃所有失序分组:
控制简单,接收方不需要缓存任何失序分组。
发送方维护窗口的上下边界及nextseqnum在该窗口中的位置;
接收方维护下一个按序接收的分组的序号,该值保存expectedseqnum变量中。
缺点
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 南理工计算机考研笔试第3章 运输层05 理工 计算机 考研 笔试 运输 05