网络基础3-传输层

OSI传输层网络基础——第3章学习目标解释传输层的需求；确定传输层在终端应用程序之间传输数据的过程中所扮演的角色；描述两种TCP/IP传输层协议—TCP和UDP协议的作用。解释传输层的关键功能，包括可靠性、端口寻址以及数据分段；解释TCP和UDP协议如何发挥各自的关键功能；确定TCP或UDP协议的应用场合，并举出使用每个协议的应用程序的例子。课程目录3.1传输层的作用3.2TCP协议——可靠通信3.3管理TCP会话3.4UDP协议——低开销通信3.5实验练习3.1传输层的作用Transportservicesandprotocolsprovidelogicalcommunicationbetweenapp’processesrunningondifferenthoststransportprotocolsruninendsystemstransportvsnetworklayerservices:networklayer:datatransferbetweenendsystemstransportlayer:datatransferbetweenprocessesrelieson,enhances,networklayerservicesapplicationtransportnetworkdatalinkphysicalapplicationtransportnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicallogicalend-endtransport3.1.1传输层的作用跟踪每个会话数据分段重组数据段标志应用程序3.1.2控制会话传输层的主要功能包括分段和重组会话多路复用传输层的其它功能面向连接的会话可靠传输有序的数据重构流量控制applicationtransportnetworkMP2applicationtransportnetworkMultiplexing/demultiplexingRecall:segment-unitofdataexchangedbetweentransportlayerentities

akaTPDU:transportprotocoldataunitreceiverHtHnDemultiplexing:deliveringreceivedsegmentstocorrectapplayerprocessessegmentsegmentMapplicationtransportnetworkP1MMMP3P4segmentheaderapplication-layerdataMultiplexing/demultiplexingmultiplexing/demultiplexing:basedonsender,receiverportnumbers,IPaddressessource,destport#sineachsegmentrecall:well-knownportnumbersforspecificapplicationsgatheringdatafrommultipleappprocesses,envelopingdatawithheader(laterusedfordemultiplexing)sourceport#destport#32bitsapplicationdata(message)otherheaderfieldsTCP/UDPsegmentformatMultiplexing:3.1.3端口寻址识别会话3.1.3端口寻址端口号的类型exampleshostAserverBsourceport:xdest.port:23sourceport:23dest.port:xportuse:simpletelnetappWebclienthostAWebserverBWebclienthostCSourceIP:CDestIP:Bsourceport:xdest.port:80SourceIP:CDestIP:Bsourceport:ydest.port:80portuse:WebserverSourceIP:ADestIP:Bsourceport:xdest.port:803.1.3端口寻址netstat

命令3.1.4支持可靠通信3.1.4TCP和UDP用户数据报协议（UDP）简单无连接低开销尽力传递使用UDP的应用：域名系统(DNS)；视频流；IP语音(VoIP)传输控制协议（TCP）面向连接可靠传输流控使用TCP的应用：Web浏览器；

电子邮件文件传输程序3.1.5分段和重组保证所传输数据的大小符合传输介质的限制要求确保不同应用程序发出的数据能在介质中多路传输TCP和UDP处理数据段的方式不同3.2UDP协议——低开销通信UDP:UserDatagramProtocol[RFC768]“nofrills,”“barebones”Internettransportprotocol“besteffort”service,UDPsegmentsmaybe:lostdeliveredoutofordertoappconnectionless:nohandshakingbetweenUDPsender,receivereachUDPsegmenthandledindependentlyofothersWhyisthereaUDP?noconnectionestablishment(whichcanadddelay)simple:noconnectionstateatsender,receiversmallsegmentheadernocongestioncontrol:UDPcanblastawayasfastasdesired3.2.1UDP——低开销与可靠性对比UDP提供基本的传输层功能低开销UDP是无连接的，并且不提供复杂的重新传输、排序和流量控制机制使用UDP的应用:域名系统(DNS)简单网络管理协议(SNMP)动态主机配置协议(DHCP)路由信息协议(RIP)简单文件传输协议(TFTP)网络游戏UDP:moreoftenusedforstreamingmultimediaappslosstolerantratesensitiveotherUDPuses(why?):DNSSNMPreliabletransferoverUDP:addreliabilityatapplicationlayerapplication-specificerrorrecover!sourceport#destport#32bitsApplicationdata(message)UDPsegmentformatlengthchecksumLength,inbytesofUDPsegment,includingheaderUDPchecksumSender:treatsegmentcontentsassequenceof16-bitintegerschecksum:addition(1’scomplementsum)ofsegmentcontentssenderputschecksumvalueintoUDPchecksumfieldReceiver:computechecksumofreceivedsegmentcheckifcomputedchecksumequalschecksumfieldvalue:NO-errordetectedYES-noerrordetected.Butmaybeerrorsnonethless?Morelater….Goal:detect“errors”(e.g.,flippedbits)intransmittedsegment3.2.2UDP进程也使用端口号来标识特定的应用层进程并将数据报发送到正确的服务或应用3.2.3UDP数据报重组UDP仅仅是将接收到的数据按照先来后到的顺序转发到应用程序3.3TCP协议——可靠通信3.3.1可靠传输问题：发送方向接收方发送一个帧，发方如何知道发送的帧是否到达收方？确认＋超时确认（Acknowledgement，简称ACK）协议发给它的对等实体的一个小的控制帧，告知它已收到刚才的帧。控制帧一个无任何数据的头部的帧超时重传如果发送方在合理的一段时间后未收到确认，那么它重发（retransmit）原始帧。等待一段合理的时间的这个动作称为超时（timeout）自动请求重发：使用确认和超时实现可靠传输的策略有时称为自动请求重发（AutomaticRepeatRequest，ARQ）。三种ARQ方案：停止等待算法滑动窗口协议并发逻辑信道3.3.2停止等待协议最简单的ARQ方案基本思想发送方传输一帧之后，在传输下一帧之前等待一个确认。如果在某段时间之后确认没有到达，则发送方超时，重发原始帧。时间超时发送方接收方帧ACK（a）确认在超时前到达超时发送方接收方帧帧ACK超时(b)原始帧丢失超时发送方接收方帧ACK帧ACK超时（c）确认丢失超时发送方接收方帧ACK帧ACK超时（d）超时过快重复帧？发送方接收方帧0ACK0帧1ACK1帧0ACK0时间线序号！停止等待算法的主要缺点允许发送方每次在链路上只有一个未确认的帧，这可能远远低于链路的容量！举例说明：一条往返延迟为45ms、带宽为1.5Mbps的链路延迟与带宽的乘积为67.5Kb，或大约8KB。发送方每个RTT仅能发送一帧，假设一帧为1KB。最大发送速率为BitsPerFrame

TimePerFrame=1024

8

0.045=182Kbps大约是链路容量的八分之一182kbps/1.5Mbps=0.121333333为完全利用链路希望发送方在必须等待一个确认之前最多能够发送8帧保持管道满载（keepingthepipefull）延迟与带宽乘积的重要性在于，它表示可传输的数据总量，即希望不等待第一个确认而能够发送的数据总量。3.3.3滑动窗口协议

－－允许管道满载的协议1．滑动窗口算法前提假设：发送方为每一帧赋一个序号，记作SeqNum，并假设SeqNum能无限增大。发送方维护三个变量SWS发送窗口大小（sendwindowsize）给出发送方能够发送但未确认的帧数的上界；LAR最近收到的确认帧的序号（lastacknowledgementreceived）LFS表示最近发送的帧的序号(lastframesent)发送窗口不等式发送方维持下式：LFS-LAR<=SWS<=SWSLARLFS图2.22发送方的滑动窗口

发送进程确认当一个确认到达时，发送方向右移动LAR，允许发送方发送另一帧。定时器发送方为所发的每个帧设置一个定时器，如果定时器在ACK到达之前超时，则重发此帧。

注意：发送方必须可以存储SWS个帧，因为在它们得到确认之前可能重发。接收方维护三个变量RWS接收窗口大小（receivewindowsize）给出接收方所能接收的无序帧数目的上界；LAF表示最大的可接收帧（largestacceptableframe）LFR表示最近收到的帧(lastframereceived)接收方不等式LAF-LFR<=RWS<=RWSLFRLAF图2.23收方的滑动窗口

NFE接收进程当一个序号为SeqNum的帧到达时：接收判断：LFR

seqNum

LAF？否：帧不在接收窗口内，丢弃。是：接收。确认发送与否？三种确认方式：累积确认否认帧有选择确认累积确认SeqNumToACK：未被确认的帧的最大序号只对SeqNumToACK这一帧发确认表示序号小于等于SeqNumToACK的帧都已收到。设置LFR=SeqNumToACK调整LAF=LFR+RWSRWS＝6LFRLAF0SeqNumToACK＝12累积确认的缺点当有分组丢失时，无法保证管道满载接收方不确认1号帧会给发送方带来什么问题？其它确认机制否认帧接收到2号帧之后，发送1号帧的否认帧缺点：发送方超时机制的重复增加接收方实现的复杂度选择性确认增加了实现的复杂性窗口大小的选择发送窗口根据一段给定时间内链路上有多少待确认的帧来选择；对于一个给定的延迟与带宽的乘积，SWS是容易计算的。接收窗口可以设置为任何想要的值RWS=1，表示接收方不存储任何错序到达的帧；RWS=SWS，表示接收方能够缓存发送方传输的任何帧。RWS>SWS,由于错序到达的帧不可能超过SWS个，所以此设置没有意义。在有限的头部字段中说明帧的序号，所以序号不可能无限增大。例：一个3比特序号意味着有8个可用序号0…7，因此序号必须可重用2．有限序号和滑动窗口

可用序号数需解决的问题是：要能够区别同一序号的不同次发送可用序号的数目必须大于所允许的待确认帧的数目发送窗口SWS<＝MaxSeqNum–1这样就可以正确发送了吗？取决于接收窗口的大小接收窗口RWS＝1SWS<＝MaxSeqNum–1可以正确发送RWS=SWS发送可能出错假设：SWS=RWS=7SWS=7012345670ACKRWS=7SWS=7012345670ACKRWS=7x确认丢失会出现什么问题？错误分析现象ACK丢失发方超时，重发0-6帧。收方此时希望收到7，0-5帧，则会认为发方重发的帧为新帧，收下，出错。原因：接收窗口滑动之后期望的帧序号与上一轮序号重合所致当RWS=SWS时，发送窗口的大小不能大于可用序号数的一半，即RWS+SWS<=2n

或

SWS<=2n-1结论：滑动窗口协议是在序号空间的两半之间变换滑动窗口协议有3个不同的功能，（1）在不可靠链路上可靠地传输帧---算法的核心功能；（2）用于保持帧的传输顺序(缓存错序到达的帧)；（3）支持流量控制，它是一种接收方能够控制发送方使其降低速度的反馈机制。4．帧顺序和流量控制3.4TCP–创建可靠会话TCP数据段SegmentFormat(cont)Eachconnectionidentifiedwith4-tuple:(SrcPort,SrcIPAddr,DsrPort,DstIPAddr)Slidingwindow+flowcontrolacknowledgment,SequenceNum,AdvertisedWinowFlagsSYN,FIN,RESET,PUSH,URG,ACKChecksumpseudoheader+TCPheader+data3.4.1TCP服务器进程3.3.1TCP数据段重组使用序列号（sequencenumber）3.3.2TCP窗口确认使用确认号（acknowledgementnumber）期待确认3.3.3TCP重传TCP通常只确认连续序列数据（contiguoussequence）选择性确认（SelectiveAcknowledgements）是备选功能3.5管理TCP会话3.5.1TCP连接的建立和终止

TCPOverviewConnection-orientedByte-streamappwritesbytesTCPsendssegmentsappreadsbytes

Fullduplex

Flowcontrol:keepsenderfrom

overrunningreceiver

Congestioncontrol:keepsenderfromoverrunningnetworkApplication

processWritebytesTCPSendbufferSegmentSegmentSegmentTransmit

segmentsApplication

processReadbytesTCPReceivebuffer■■■

TCP有三种机制触发数据段的发送：用一变量——maximumsegmentsize-MSS

它从发送进程一收到MSS字节就发送一段，TCP通常发不引起局部IP分段的段尺寸，即

MSS=MTU(直连LAN)–TCP头–IP

由发送进程明确要求TCP发送数据段。TCP支持PUSH操作，发送进程调用它发出字节缓冲区中未发送的字节，如Telnet，每按一个字符，马上发送定时周期性触发段的发送，结果是段包含当前缓冲区中待发送的字节TCP会话的建立TCP会话的终止终止连接连接双方都可以关闭连接连接的一方从ESTABLISHED到CLOESED状态转换有四种情况：

*本方先关闭*对方先关闭*双方同时关闭*快速关闭CLOSEDLISTENSYN_RCVDSYN_SENTESTABLISHEDFIN_WAIT_1FIN_WAIT_2CLOSINGTIME_WAITCLOSEDLAST_ACKCLOSE_WAITActiveopen/SYNCloseClosePassiveopenSYN/SYN+ACKSend/SYNSYN/SYN+ACKACKSYN+ACK/ACKClose/FINClose/FINFIN/ACKFIN/ACKACKACKACKClose/FINFIN/ACK两个数据段生存期后超时ACK+FIN/ACK状态转换图状态转换过程TCP连接从创到删要经历10多个状态：状态随事件发生而迁移，事件分三类用户操作：Open/Send/Receive/Close接收到TCP段，特别标有SYN/ACK/FIN的超时事件3.5.2TCP流量控制

流量控制Asthetransportlayersendsdatasegments,ittriestoensurethatdataisnotlost.Areceivinghostthatisunabletoprocessdataasquicklyasitarrivescouldbeacauseofdataloss.Thereceivinghostisthenforcedtodiscardit.Flowcontrolavoidstheproblemofatransmittinghostoverflowingthebuffersinthereceivinghost.

TCPprovidesthemechanismforflowcontrolbyallowingthesendingandreceivinghosttocommunicate.Thetwohoststhenestablishadata-transferratethatisagreeabletoboth.通告窗口大小——AdvertisedWindowTCP中的滑动窗口LastByteAckedLastByteSent发送应用程序接收应用程序TCPTCPLastByteWrittenLastByteReadNextByteExpectedLastByteRcvdTCP发送缓冲区TCP接收缓冲区发送缓冲区3个指针之间的关系显然：接收方不能应答尚未发送的字节LastByteAcked≤LastByteSentTCP不能发送应用进程尚未写入的字节LastByteSent≤LastByteWritten注意LastByteAcked的左边没有字节需要缓存，因为已经确认,LastByteWritten右边没有字节缓存，因为还未产生LastByteAckedLastByteSent发送应用程序TCPLastByteWrittenTCP发送缓冲区接收缓冲区3个指针

NextByteExpected是按序接收所希望的下一个字节，所以：LastByteRead＜NextByteExpected

若数据按序到达，则NextByteExpected指向LastByteRcvd之后的字节，否则指向第1个数据间隔的开始，故有：NextByteExpected≤LastByteRcvd+1

LastByteRead左边和LastByteRcvd右边不须缓冲前者已被读，后者还未到。接收应用程序TCPLastByteReadNextByteExpectedLastByteRcvdTCP接收缓冲区TCP的流量控制TCP接收方必须保持下面不等式LastByteRcvd-LastByteRead≤MaxRcvBuffer防止缓冲区溢出,应通告接收方窗口大小AdvertiseWindow=MaxRcvBuffer-(LastByteRcvd-LastByteRead)显然,窗口大小与LastByteRead

成正比LastByteRcvd

反比。若读与收等速，窗口到达最大缓冲量发送方的限制发送方必须保证它所得到的收方通告窗口关系LastByteSend

–

LastByteAcked

≤AdvertisedWindow

即:发送方要计算，限制可发送的数据(向网上跑的数据)EffectiveWindow=AdvertisedWindow–(LastByteSend-LastByteAcked)发送方的限制（cont）发方还必须确保本地进程不溢出其发缓冲区（防止上层淹没下层），当发送进程要写y字节到TCP,若

(LastByteWritten

–

LastByteAcked)+y＞MaxSendBuffer,

则阻塞该进程收到xBytes的确认,

允许发方把LastByteAcked

增加xBytes流控的实现动态改变通告窗口大小实现流控：该大小表示收到确认号后允许下次传送的数据长度。等于0时就必须等待，检测到拥塞时，要调整发送速率3.5.3TCP拥塞控制

端到端的拥塞控制如果某个网络或连接设备接收报文的速度超出了它的处理能力，它就不能快速处理到达的报文,出现拥塞。TCP的拥塞控制的概念是每个TCP发送方时刻判断网络中有多少可用资源。从而确定可以安全传送的报文数。引入几个新的变量

CongestionWindow：拥塞窗口。允许发送方发出的未确认数据的最大字节数，不仅仅由接收方的AdvertisedWindow决定，而是由接收方窗口和拥塞窗口二者的最小值决定，即MaxWindow=MIN（AdvertisedWindow，CongestionWindow）EffectiveWindow=MaxWindow-（LastByteSent-LastByteAcked）

CongestionThreshold：拥塞阈值，用来确定是用慢启动还是用拥塞避免算法来控制数据传送。慢启动和拥塞避免发送方

接收方慢启动期间报文数的增长慢启动何时停止增加拥塞窗口的值当发现网络拥塞时这种增加就终止了发送方如何判断网络发生拥塞并且如何减少拥塞窗口的值？*

超时是发生拥塞的标志，并据此减小正在传输数据的速率。*每发生一次超时，发送方就将CongestionWindow

减少为原来值的一半。拥塞避免期间报文数的增长发送方接收方……拥塞避免期间报文数的增长拥塞窗口值的变化拥塞避免并不成倍地增加拥塞窗口的值，而是使用“累次增加”的方法CongestionWindow=CongestionWindow+MSS×(MSS/CongestionWindow)

CongestionWindow

随时间增减的轨迹

t1t2t3t4

t5t6t7t8CONGESTIONWINDOW的值时间快速重传和快速恢复发送方接收方

…

报文1报文2报文3报文4报文5报文6ACK1ACK2ACK2ACK2ACK2报文3ACK6…基于重复确认的快速重传机制带有快速重传机制的TCP的行为

t1t2t3t4t5t6t7t8CONGESTIONWINDOW的值时间带有快速重传机制的TCP的行为带有快速恢复机制的TCP的行为

t1t2t3t4t5t6t7t8CONGESTIONWINDOW的值时间图6.18带有快速恢复机制的TCP的行为流量控制与拥塞控制差别流量控制：防止发送者超过接收者的能力，流控是端到端的发送。拥塞控制：防止太多的数据注入到网络中，从而引起交换机或链路超载，拥塞控制是关于主机和网络的关系。3.5.4TCP适应性重传

TCP的重传机制为保证可靠传送，若在某段时间内未收到应答则要重发该段TCP设置定时，设成是RTT的函数由于因特网上任何一对主机间,甚至同一对主机在不同时段内其RTT都是变化的，故选择适当的RTT不容易因特网组织已经获得使用TCP的许多经验把这个期望的时间设置成连接两端之间的RTT函数，称作适应性重传机制OriginalAlgorithm（最初的算法）

基本思想是维持一个RTT的动态平均值，并把超时值作为这个RTT的函数TCP每发段时，记下发送该段时的时间，当该段的应答到达时，记下收到的应