《计算机网络 自顶向下方法》读书笔记 第3章 运输层

第3章 运输层

3.1概述和运输层服务

1.运输层协议只工作在端系统中。在端系统中,运输层协议将来自应用进程的报文移动到网络边缘(即网络层),反过来也是一样,但对有关这些报文在网络核心如何移动并不作任何规定。

2.运输协议能够提供的服务常常受制于底层网络协议的服务模型。如果网络层协议无法为主机之间发送的运输层报文段提供时延或带宽保证的话,运输层协议也就无法为进程之间发送的应用程序报文提供时延或带宽保证。

3.2多路复用和多路分解

1.将运输层报文段中的数据交付到正确的套接字的工作称为多路分解。在源主机从不同套接字中收集数据块,并为每个数据块封装上首部信息从而生成报文段,然后将报文段传递到网络层,所有这些工作称为多路复用

2.运输层多路复用的要求:①套接字有唯一标识符;②每个报文段有特殊字段来指示该报文段所要交付到的套接字。这些特殊字段是源端口号字段和目的端口号字段。(UDP报文段和TCP报文段还有其他一些字段)。端口号是一个16比特的数,其大小在065535之间。01023范围的端口号称为周知端口号,是受限制的,这是指它们保留给诸如HTTP和FTP之类的周知应用层协议来使用。

3.UDP套接字是由一个二元组全面标识的,该二元组包含一个目的IP地址和一个目的端口号。因此,如果两个UDP报文段有不同的源IP地址和/或源端口号,但具有相同的目的IP地址和目的端口号,那么这两个报文段将通过相同得到目的套接字被定向的相同的目的进程。

4.TCP套接字是由一个四元组来标识的,该四元组包含源IP地址、源端口号、目的IP地址、目的端口号。因此,两个具有不同源IP地址或源端口号的到达TCP报文段将被定向到不同的套接字,除非TCP报文段携带了初始创建连接的请求。

3.3无连接运输:UDP

1.UDP只是做了运输协议能够做的最少工作。除了复用/分解功能及少量的差错检测外,它几乎没有对IP增加别的东西。UDP从应用程序进程得到数据,附加上用于多路复用/分解服务的源和目的端口号字段,以及两个其他的小字段,然后将形成的报文段交付给接收主机。如果该报文段到达接收主机,UDP使用目的端口号将报文段中的数据交付给正确的应用进程。

2.某些应用的开发人员选择UDP而不选择TCP的原因如下:

  • 关于发送什么数据以及何时发送的应用层控制更为精细。采用UDP时,只要应用进场将数据传递给UDP,UDP就会将此数据打包进UDP报文段并立即将其传递给网络层。而TCP有一个拥塞控制机制,以便当源和目的主机间的一条或多条链路变得极度拥塞时来遏制运输层TCP发送方。TCP仍将继续重新发送数据报文段知道目的主机收到此报文并加以确认,而不管可靠交付需要用多长时间。因为实时应用通常要求最小的发送速率,不希望过分地延迟报文段的传送,且能容忍一些数据丢失,TCP服务模型并不是特别适合这些应用的需要。

  • 无须连接建立。TCP在开始数据传输之前要进过三次握手。UDP却不缺要任何准备即可进行数据传输。因此UDP不会引入建立连接的时延。

  • 无连接状态。TCP需要在端系统中维护连接状态。此连接状态包括接收和发送缓存、拥塞控制参数以及序号与确认好的参数。而UDP不维护连接状态,也不跟踪这些参数。因此,某些专门用于某种特定应用的服务器当应用程序运行在UDP之上而不是运行在TCP上时,一般都能支持更多的活跃用户。

  • 分组首部开销小。每个TCP报文段都有20字节的首部开销,而UDP仅有8字节的开销。

3.UDP报文的结构如图3-1所示。
UDP

图3-1 UDP报文段结构

通过端口号可以使目的主机将应用数据交给运行在目的端系统的相应进程。长度字段指示了在UDP报文段中的字节数(首部加数据)。因为数据字段的长度在一个UDP段中不同与在另一个段中,故需要一个明确的长度。接收方使用检验和来检查在该报文段中是否出现了差错。

4.检验和用于确定当UDP报文段从源到达目的地移动时,其中的比特是否发生了改变。发送方的UDP对报文段中的所有16比特字的和进行反码运算,求和时遇到的任何溢出都被回卷。在接收方,全部的4个16比特字(包括检验和)加在一起。如果该分组中没有引入差错,则显然在接收方处该和将是1111111111111111。如果这些比特之一是0,那么该分组中出现了差错。

3.4可靠数据传输原理

1.选择重传(Selective Repeat, SR)发送方的事件与动作:

  • 从上层接收到数据。当从上层接收到数据后,SR发送方检查下一个可用于该分组的序号。如果序号位于发送方的窗口内,则将数据打包并发送;否则要么将数据缓存,要么将其返回上层以便以后传输。

  • 超时。定时器再次被用来防止丢失分组。然而,现在每个分组必须拥有其自己的逻辑定时器,因为超时发生后只能发送一个分组。可以使用单个硬件定时器模拟多个逻辑定时器的操作。

  • 收到ACK。如果收到ACK,倘若该分组序号在窗口内,则SR发送方将那个被确认的分组标记为已接收。如果该分组的序号等于send_base,则窗口基序号向前移动到具有最小序号的未确认分组处。如果移动了并且有序号落在窗口内的未发送分组,则发送这些分组。

SR接收方的事件与动作:

  • 序号在[rcv_base, rcv_base + N – 1]内的分组被正确接收。在此情况下,收到的分组落在接收方的窗口内,一个选择ACK被回送给发送方。如果该分组以前没收到过,则缓存该分组。如果该分组的序号等于接收窗口的基序号,则该分组以及以前缓存的序号连续的分组交付给上层。然后,接收窗口按向前移动分组的编号向上交付这些分组。

  • 序号在[rcv_base – N, rcv_base – 1]内的分组被正确收到。在此情况下,必须产生一个ACK,即使该分组时接受方以前已确认过的分组。

  • 其他情况。忽略该分组。

2.可靠数据传输机制及其用途:

  • 检验和。用于检测在一个传输分组中的比特错误。

  • 定时器。用于超时/重传一个分组,可能因为该分组(或其ACK)在信道中丢失了。由于当一个分组延时但未丢失(过早超时),或当一个分组已被接收方接收到但从接收方到发送方的ACK丢失时,可能产生超时时间,所以接收方可能会受到一个分组的多个冗余副本。

  • 序号。用于为从发送方流向接收方的数据分组按顺序编号。所接收分组的序号间的空隙可使接收方检测出丢失的分组。具有相同序号的分组可使接收方检测出一个分组的冗余副本。

  • 确认。接收方用于告诉发送方一个分组或一组分组已被正确地接收到了。确认报文通常携带着被确认得到分组或多个分组的序号。确认可以是逐个的或积累的,这取决于协议。

  • 否定确认。接收方用于告诉发送方某个分组未被正确地接收。否定确认报文通常携带着未被正确接收的分组的序号。

  • 窗口、流水线。发送方也许被限制仅发送那些序号落在一个指定范围内的分组。通过允许一次发送多个分组但未被确认,发送方的利用率可在停等操作模式的基础上得到增加。

3.5面向连接的运输:TCP

1.TCP(Transmission Control Protocol)连接提供的是全双工服务:如果一台主机上的进程A与另一台主机上的进程B存在一条TCP连接,那么应用层数据就可在从进程B流向进程A的同时,也从进程A流向进程B。TCP连接也总是点对点的,即在单个发送方与单个接收方之间的连接。

2.建立TCP连接后,客户进程通过套接字传递数据流,TCP将这些数据引导到该连接的发送缓存,发送缓存是发起三次握手期间设置的缓存之一。接下来TCP就会时不时从发送缓存里取出一块数据,并将数据传递到网络层。TCP可从缓存中取出并放入报文段中的数据数量受限于最大报文段长度(Maximum Segment Size, MSS)。MSS通常根据最初确定的由本地发送主机发送的最大链路层帧长度(即所谓的最大传输单元(Maximum Transmission Unit, MTU))来设置。

3.图3-2显示了TCP报文段的结构。
TCP

图3-2 TCP报文段结构

与UDP一样,首部包括了源端口号和目的端口号,它被用于多路复用/分解来自或送到上层应用的数据。TCP首部也包括了检验和字段。TCP报文段首部还包含下列字段:

  • 32比特的序号字段和32比特的确认号字段,这些字段被TCP发送方和接收方用来实现可靠数据传输服务。

  • 16比特的接收窗口字段,该字段用于流量控制指示接收方愿意接受的字节数量。

  • 4比特的首部长度字段,该字段指示了以32比特的字为单位的TCP首部长度。由于TCP选项字段的原因,TCP首部的长度是可变的(通常,选项字段为空,所以TCP首部的典型长度是20字节)。

  • 可选与变长的选项字段,该字段用于发送方与接收方协商最大报文段长度时,或在高速网络环境下用作窗口调节因子时使用。首部字段中还定义了一个时间戳选项。

  • 6比特的标志字段。ACK比特用于指示确认字段中的值是有效的,即该报文段包括一个对已被成功接收报文段的确认。RST、SYN和FIN比特用于连接建立和拆除。在明确拥塞通告中使用了CWR和ECE比特。当PSH比特被置位时,就指示接收方应立即将数据交给上层。最后,URG比特用来指示报文段里存在着被发送端的上层实体置为“紧急”的数据。紧急数据的最后一个字节由16比特的紧急数据指针字段指出。当紧急数据存在并给出指向紧急数据尾指针的时候,TCP必须通知接收端的上层实体。

4.TCP把数据看成一个无结构的、有序的字节流。序号是建立在传送的字节流之上,而不是建立在传送的报文段的序列之上。一个报文段的序号是该报文段首字节的字节流编号。主机A向主机B发送数据流时,主机A填充进报文段的确认号是主机A期望从主机B收到的下一字节的序号。

5.TCP只确认该流中至第一个丢失字节为止的字节,所以TCP被称为提供累积确认

6.对客户到服务器的数据的确认被装载在一个承载服务器到客户的数据的报文段中,这种确认被称为是被捎带(piggybacked)在服务器到客户的数据报文段中的。

7.在任意时刻,TCP为一个已发送的但目前尚未被确认的报文段估计样本RTT(SampleRTT),从而产生一个接近每个RTT的新SampleRTT值。TCP维持一个SampleRTT均值(称为EstimatedRTT)。一旦获得一个新SampleRTT时,TCP就会根据下列公式来更新EstimatedRTT:
E s t i m a t e d R T T = ( 1 − α ) ⋅ E s t u n a t e d R T T + α ⋅ S a m p l e R T T EstimatedRTT = (1 - \alpha) \cdot EstunatedRTT + \alpha \cdot SampleRTT EstimatedRTT=(1α)EstunatedRTT+αSampleRTT
其中α的推荐值为0.125。这种平均被称为指数加权移动平均(Exponential Weighted Moving Average, EWMA)。

除了估算RTT外,测量RTT的变化也是有价值的。定义DevRTT,用于估算SampleRTT偏离EstimatedRTT的程度,按照下式计算:
D e v R T T = ( 1 − β ) ⋅ D e v R T T + β ⋅ ∣ S a m p l e R T T − E s t i m a t e d R T T ∣ DevRTT = (1- \beta) \cdot DevRTT + \beta \cdot | SampleRTT - EstimatedRTT| DevRTT=(1β)DevRTT+βSampleRTTEstimatedRTT
其中β的推荐值为0.25。

TCP的确定重传超时间隔(TimeoutInterval)按下式计算:
T i m e o u t I n t e r v a l = E s t i m a t e d R T T + 4 ⋅ D e v R T T TimeoutInterval = EstimatedRTT + 4 \cdot DevRTT TimeoutInterval=EstimatedRTT+4DevRTT
推荐的初始TimeoutInterval值为1秒。

TCP每次重传时都会将下一次的超时间隔设置为先前的两倍,而不是用上式计算出的值。每当收到上层应用的数据或收到ACK时,TimeoutInterval由上式计算得出。

8.一旦收到3个冗余ACK,TCP就执行快速重传,即在该报文段的定时器过期之前重传丢失的报文段。

9.每当TCP连接收到正确、按序的字节后,它就将数据放入接收缓存。相关联的应用会从该缓存中读取数据,但不必是数据刚到达就立即读取。如果某应用程序读取数据时相对缓慢,而发送方发送得太多、太快,发送的数据就会很容易地使该连接的接收缓存溢出。TCP为此提供了流量控制服务,以消除发送方使接收方缓存溢出的可能性。

TCP通过让发送方维护一个成为接收窗口的变量来提供流量控制。假设主机A通过一条TCP连接向主机B发送一个大文件。主机B为该连接分配了一个接收缓存,并用RcvBuffer来表示其大小。主机B上得到应用进程不时地从该缓存中读取数据。定义以下变量:

  • LastByteRead :主机B上的应用进程从缓存读出的数据流的最后一个字节的编号。

  • LastByteRcvd :从网络中到达的并且已放入主机B接收缓存中的数据流的最后一个字节的编号。

由于TCP不允许已分配的缓存溢出,下式必须成立:
L a s t B y t e R c v d − L a s t B y t e R e a d ≤ R c v B u f f e r LastByteRcvd - LastByteRead \leq RcvBuffer LastByteRcvdLastByteReadRcvBuffer
接收窗口用rwnd表示,根据缓存可用空间的数量来设置:
r w n d = R c v B u f f e r − [ L a s t B y t e R e a d − L a s t B y t e R c v d ] rwnd = RcvBuffer - [LastByteRead - LastByteRcvd] rwnd=RcvBuffer[LastByteReadLastByteRcvd]
主机B通过把当前的rwnd值放入它发给主机A的报文段接收窗口字段中,通知主机A它在该连接的缓存中还有多少可用空间。开始时,主机B设定rwnd = RcvBuffer。主机A轮流跟踪两个变量,LastByteSent和LastByteAcked,分别表示主机A最后发送的字节序号和最后收到确认的字节序号。这两个变量的差LastByteSent – LastByteAcked就是主机A发送到连接中但未被确认的数据量。通过将未确认的数据量控制在rwnd以内,就可以保证主机A不会使主机B的缓存溢出。因此,主机A在该连接的整个生命周期内须保证:
L a s t B y t e S e n t − L a s t B y t e A c k e d ≤ r w n d LastByteSent - LastByteAcked \leq rwnd LastByteSentLastByteAckedrwnd
当主机B的接收窗口为0时,主机A继续发送只有一个字节数据的报文段。这些报文段将会被接收方确认。最终缓存将开始清空,并且确认报文里将包含一个非0的rwnd值。

10.三次握手的过程:

​ 第一步:客户端的TCP首先向服务器端的TCP发送一个特殊的TCP报文段。该报文段中不包含应用层数据。但是在报文段的首部中的一个标志位(即SYN比特)被置为1。因此,这个特殊报文段被称为SYN报文段。另外,客户会随机地选择一个初始序号(client_isn),并将此编号放置于该起始的TCP SYN报文段的序号字段中。该报文段会被封装在一个IP数据报中,并发送给服务器。

​ 第二步:一旦包含TCP SYN报文段的IP数据报到达服务器主机,服务器会从该数据报中提取出TCP SYN报文段,为该TCP连接分配TCP缓存和变量,并向该客户TCP发送允许连接的报文段。这个允许连接的报文段也不包含应用层数据。但是,在报文段的首部却包含3个重要的信息。首先,SYN比特被置为1。其次,该TCP报文段首部的确认号字段被置为client_isn + 1。最后,服务器选择自己的初始序号(server_isn),并将其放置到TCP报文段首部的序号字段中。该允许连接的报文段被称为SYNACK报文段。

​ 第三步:在收到SYNACK报文段后,客户也要给该连接分配缓存和变量。客户主机则向服务器发送另外一个报文段;这最后一个报文段对服务器的允许连接的报文段进行了确认(该客户通过将值server_isn + 1放置到TCP报文段首部的确认字段中来完成此项工作)。因为连接已经建立了,所以该SYN的比特被置为0。这个阶段可以在报文负载中携带客户到服务器的数据。

11.参与一条TCP连接的两个进程中的任何一个都能终止该连接。当连接接收后,主机中的“资源”(即缓存和变量)将被释放。客户应用进程发出一个关闭连接命令。这会引起客户TCP向服务器进程发送一个特殊的TCP报文段。这个特殊的TCP报文段让其首部中的一个标志位即FIN比特被设置为1。当服务器接收到该报文段后,就向发送方回送一个确认报文段。让后,服务器发送它自己的终止报文段,其FIN比特被置为1。最后,该客户对这个服务器的终止报文段进行确认。此时,在两台主机上用于该连接的所有资源都被释放了。

12.当一台主机接收到一个TCP报文段,其端口号或源IP地址与该主机上进行中的套接字都不匹配时,该主机将向源发送一个特殊重置报文段。该TCP报文段将RST标志位置为1。

3.6拥塞控制原理

1.网络拥塞的代价:

  • 发送方必须执行重传以补偿因为缓存溢出而丢弃的分组。

  • 发送方在遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本。

  • 当一个分组沿一条路径被丢弃时,每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费掉了。

2.拥塞控制方法:

  • 端到端拥塞控制。在端到端拥塞控制方法中,网络层没有为运输层拥塞控制提供显式支持。即使网络中存在拥塞,端系统也必须通过对网络行为的观察来推断之。

  • 网络辅助的拥塞控制。在网络辅助的拥塞控制中,路由器向发送方提供关于网络中拥塞状态的显式反馈信息。这种反馈可以简单地用一个比特来指示链路中的拥塞情况。网络辅助控制的拥塞信息从网络反馈到发送方通常有两种方式,一种是采用拥塞分组的形式。更为通用的第二种形式的通知是,路由器标记或更新从发送方流向接收方的分组中的某个字段来指示拥塞的产生。一旦收到一个标记的分组后,接收方就会向发送方通知该网络拥塞指示。

3.7 TCP拥塞控制

1.TCP对于网络拥塞所采取的方法是让每一个发送方根据所感知到的网络拥塞程度来限制其能向连接发送流量的速率。运行在发送方的TCP拥塞控制机制跟踪一个额外的变量,即拥塞窗口。拥塞窗口表示为cwnd,它对一个TCP发送方能向网络中发送流量的速率进行了限制。在一个发送方中未被确认的数据量不会超过cwnd和rwnd中的最小值,即
L a s t B y t e S e n t − L a s t B y t e A c k e d ≤ m i n { c w n d , r w n d } LastByteSent - LastByteAcked \leq min \{cwnd, rwnd\} LastByteSentLastByteAckedmin{cwnd,rwnd}
在每个往返时间(RTT)的起始点,上面的限制条件允许发送方向该连接发送cwnd个字节的数据,在该RTT结束时发送方接收对数据的确认报文。因此,该发送方的发送速率大概是cwnd/RTT字节/秒。通过调节cwnd的值,发送方能调整它向连接发送数据的速率。

2.一个丢失的报文段意味着拥塞,因此当丢失报文段时应当降低TCP发送方的速率;一个确认报文段指示该网络正在向接收方交付发送方的报文段,因此,当对先前未确认的报文段的确认到达时,能够增加发送方的速率。

3.TCP拥塞控制算法的3个部分:

  • 慢启动。在慢启动状态,cwnd的值以1个MSS开始并且每当创术的报文段首次被确认就增加一个MSS。如果存在一个由超时指示的丢包时间,TCP发送方将cwnd设置为1并重新开始慢启动过程。它还将第二个状态变量ssthresh的值设置为cwnd / 2,即当检测到拥塞时将ssthresh置为拥塞窗口值的一半。当cwnd的值等于ssthresh时,结束慢启动并且TCP转移到拥塞避免模式。如果检测到3个冗余ACK,这时TCP执行快速重传,并进入快速恢复状态。

  • 拥塞避免。对于TCP发送方无论何时到达一个新的确认,就将cwnd增加MSS(MSS/cwnd)字节。当出现超时时,cwnd的值被设置为1个MSS,当丢包事件出现时,ssthresh的值被更新为cwnd值的一半。当收到3个冗余ACK时,将cwnd的值减半,将ssthresh的值记录为cwnd的值的一半,并进入快速恢复状态。

  • 快速恢复。对于引起TCP进入快速恢复状态的缺失报文段,对收到的每个冗余的ACK,cwnd的值增加一个MSS。最终,当对丢失报文段的一个ACK到达时,TCP在减半cwnd后进入拥塞避免状态。如果出现超时事件,将cwnd置为1,ssthresh设置为cwnd的一半,并进入慢启动状态。

4.TCP平均吞吐量的计算公式:
KaTeX parse error: Expected 'EOF', got '\mbox' at position 2: \̲m̲b̲o̲x̲{一条连接的平均吞吐量} = …
其中W是当一个丢包事件发生时的窗口长度,L是丢包率。

5.TCP趋于在竞争的多条TCP连接之间提供对一段瓶颈链路带宽的平等分享。

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值