计算机网络学习记录--第五章 运输层

第五章 运输层

运输层是整个网络体系结构中的关键层次之一。为相互通信的应用进程提供逻辑通信。

5.1 运输层协议概述

5.1.1 进程之间的通信

  运输层向它上面的应用层提供通信服务。
  运输层的复用功能：在发送方不同的应用进程都可以使用同一个运输层协议传送数据。
  运输层的分用功能：在接收方的运输层在剥去报文首部后能够把这些数据正确交付目的应用进程。
  网络层与运输层的区别：网络层为主机之间提供逻辑通信，运输层为应用进程之间提供端到端的逻辑通信。

  在网络层，IP数据报首部中的检验和字段，只检验首部中是否出现差错，而不检验数据部分。
  根据应用程序的不同需求，运输层需要有两种不同的运输协议，面向连接的TCP（全双工可靠信道）、无连接的UDP（不可靠信道）。

5.1.2 运输层的两个主要协议

  （1）用户数据报协议UDP（user datagram protocol）：不需要建立连接，不提供可靠交付。
  （2）传输控制协议TCP（transmission control protocol）：建立连接，数据传送，连接释放。不提供广播或多播服务。
  运输协议数据单元TPDU（transport protocol data unit）：两个对等运输实体在通信时传送的数据单位。在TCP\IP体系中，根据所使用的协议是TCP或UDP，分别称之为TCP报文段（segment）或UDP用户数据报。

5.1.3 运输层的端口

  一台主机会有不同的应用进程，因此给应用进程赋予一个非常明确的标志是非常重要的。
  这个标志要适应不同的操作系统，同时因为进程的创建和销毁是动态的，还不能为某个主机特定进程指明为通信终点。
  解决上述问题的方法就是在运输层使用协议端口号（protocol port number），或简称为端口（port）。这是一种软件端口，是应用层各种协议进程与运输实体进行层间交互的一种地址。【应用进程报文-- 合适的端口-- TCP/UDP】
  运输层用一个16位的端口号标志一个端口，端口号只有本地意义，只是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口。在互联网的不同计算机中，相同的端口号是没有关联的。
  也就是两台计算机中的进程要互相通信，要知道对方的IP地址（找到计算机）和端口号（找到计算机的应用进程），类比寄信时地址和姓名。

  运输层的端口号分为：服务器端使用的端口号（0 ~ 1023指派给熟知端口–必须是确定的，让客户程序能找到，1024 ~ 49151是登记端口号）和客户端暂时使用的端口号（49151~65535，仅在客户进程运行时才动态选择）

5.2 用户数据报协议UDP

5.2.1 UDP概述

  （1）无连接，减少了开销和发送数据之前的时延。
  （2）尽最大努力交付，即不保证可靠交付。
  （3）面向报文，应用层交给UDP多长的报文，UDP就照样发送，一次交付一个完整的报文，因此应用程序要选择合适大小的报文。报文太长，则在IP层要进行分片，太短则IP数据报的首部相对长度太大。
  （4）没有拥塞控制，对某些实时应用很重要。但当很多源主机都向网络发送高速率的实时视频流时，网络可能发生拥塞，结果大家都无法接收。这种情况下，应用进程本身在不影响应用实时性的前提下，可以增加一些提高可靠性的措施，如采用前向纠错或重传已丢失的报文。
  （5）支持一对一，一对多，多对一和多对多的交互通信。
  （6）首部开销小，只有8个字节，比TCP20字节的首部要短。

5.2.2 UDP的首部格式

  用户数据报UDP有两个字段，数据字段和首部字段。首部字段有8个字节，由四个字段组成，每个字段的长度都是两个字节。分别是源端口，目的端口，长度（最小值是8）和检验和。

  在计算检验和时，要临时在UDP用户数据报前边加上12个字节的伪首部 （这里的17是UDP的协议号，TCP的协议号是6）用来计算。UDP的检验和是把首部和数据部分一起都检验。与计算IP数据报首部检验和相似。（反码求和取反等操作）

  如果发现不存在目的端口号对应的应用进程，则丢弃该报文，并由网际控制报文协议ICMP发送“端口不可达”差错报文。第四章的traceroute就是让发送的UDP故意使用一个非法的UDP端口，以返回差错报文，获得想要的信息。

5.3 传输控制协议TCP概述

5.3.1 TCP最主要的特点

  面向连接的运输层协议。建立TCP连接，传送数据，释放已建立的TCP连接。
  每一条TCP连接只能是点对点的（一对一）。
  提供可靠交付的服务。无差错，不丢失，不重复，按序到达。
  提供全双工通信。TCP连接的两端都设有发送缓存和接收缓存，允许通信双方的应用进程在任何时候都能发送数据。发送端TCP会在合适的时候将数据发送出去，接收端上层应用会在合适的时候读取数据。
  面向字节流。流（stream）指的是流入到进程或从进程流出的字节序列。TCP把应用进程交下来的数据仅仅看成是一连串的无结构的字节流，TCP并不知道所传送的字节流的含义，接收方必须有能力识别收到的字节流，把它还原成有意义的应用层数据。
  TCP并不关心应用进程一次把多长的报文发送到TCP的缓存中，而是根据对方给出的窗口值和当前网路拥塞程度来决定一个报文段应包含多少个字节。

5.3.2 TCP的连接

  TCP连接的端点叫做套接字（socket）或插口。
  套接字socket = （IP地址 ： 端口号）
  每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定。
  同一个IP地址可以有多个不同的TCP连接（不同端口，不同主机），同一个端口号也可以出现在多个不同的TCP连接中（端口的本地意义）。
  同一个socket可以表示不同的意思，本章是端口号拼接到IP地址。

5.4 可靠传输的工作原理

  TCP下面的网络所提供的是不可靠的传输。因此TCP必须采取适当的措施才能使得两个运输层之间的通信变得可靠。
  理想的传输条件：传输信道不产生差错；接收方总是来得及处理收到的数据。
  实际上，网络都不具备上述两个理想条件，但是可以采取一些可靠传输协议，当出现差错时，让对方重传出现差错的数据；同时在接收方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速度。

5.4.1 停止等待协议

  “停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。 这里为了讨论可靠传输原理，把传送的数据单元都成为分组。

1. 无差错情况
     链路层传送数据时都要采用可靠的通信协议，其中最简单的就是这种“停止等待协议”。在运输层并不使用这种协议。
2. 出现差错
     在每发送完一个分组时，设置一个超时计时器，如果在超时计时器到期之前收到了对方的确认，就撤销已设置的一个超时计时器。
     需要注意的是：
       A在发送完一个分组后，必须暂时保留已发送的分组的副本，这个副本只有在A收到对方相应的确认后才清除。
       分组和确认分组都必须进行编号。这样才能明确是哪一个发送出去的分组收到了确认，哪一个分组还没有收到确认。
       超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。重传时间设的太长会降低通信效率，设的太短会造成不必要的重传。
   
3. 确认丢失和确认迟到
     （a）对应的是发回的M1确认丢失了。（b）对应的是发回的M1确认迟到了。
     不论是接收端还是发送端，只要有重复的，就丢弃。
     在接收端收到重复的之后，要回送确认。
   
     自动重传请求ARQ（automatic repeat request）：重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组。
4. 信道利用率
     RTT是往返时间，这里仅仅在时间T_D 内才用来传送有用的数据，因此信道利用率是U = T_D /(T_D + RTT + T_A )
     往返时间RTT取决于所使用的信道，当往返时间远大于分组发送的时间T_D 时，信道利用率就会非常低。若出现重传，就会更低。
   
     为了提高传输效率，发送方可以采用流水线传输。就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认，这样就可使信道上一直有数据不间断的在传送。
   

5.4.2 连续ARQ协议

  滑动窗口协议是TCP协议的精髓。

  接收方一般是采用累积确认的方式。即收到几个分组后，对按序到达的最后一个分组发送确认。
  Go-back-N（回退N），表示需要再退回来重传已发送的N个分组。当通信线路质量不好时，连续ARQ协议会带来负面的影响。

5.5 TCP报文段的首部格式

   虽然TCP是面向字节流的，但是TCP传送的数据单元却是报文段。
   TCP首部的20个字节是固定的，后面4n字节是根据需要而增加的选项（n是整数）。因此TCP首部最小的长度是20字节。

   （1）源端口和目的端口：各占2字节。
   （2）序号seq：占4字节。使用mod 2³²运算，当序号增加到2³² - 1后，下一个序号又回到0。首部中的序号字段值指的是本报文段所发送的数据的第一个字节的序号，一个TCP连接中传送的字节流中的每一个字节都按顺序编号。
   （3）确认号ack：占4字节，是期望收到对方下一个报文段的第一个数据字节的序号。若确认号=N，则表明到序号N-1为止的所有数据都已正确收到。
   （4）数据偏移：占4位，指出的是TCP报文的首部长度。4位二进制数能够表示的最大十进制数字是15，因此数据偏移的最大值是60字节。（即选项长度不能超过40字节）（15*4）
   （5）保留：占6位。
   （6）~（11）是6个控制位，用来说明本报文段性质。
   （6）紧急URG：为1时，把这个紧急数据放到本报文段数据最前面，尽快发送。
   （7）确认ACK：仅当ACK = 1时，确认号字段才有效。在连接建立后所有传送的报文段都必须把ACK置一。
   （8）推送PSH：TCP收到PSH为1的报文，会尽快交付接收应用进程。
   （9）复位RST：重新建立一个连接。
   （10）同步SYN：建立连接时用来同步序号。
   （11）终止FIN：为1时，表明发送方数据已经发送完毕，要求释放运输连接。
   （12）窗口：占2字节，接收方让发送方设置发送窗口的依据。（接收窗口，动态变化的）
   （13）检验和：占2字节，检验的范围包括首部和数据，检验时要临时加上12字节的伪首部，和UDP相似。
   （14）紧急指针：占2字节，为1时指出本报文段中的紧急数据的字节数。在窗口为0时也可以发送紧急数据。
   （15）选项：长度可变，最长40字节。

   最大报文段长度MSS（maximum segment size）：每一个TCP报文段中的数据字段的最大长度。
   MSS应尽可能大些，只要在IP层传输时不需要再分片就行。MSS的默认值是536字节，因此报文段长度是556字节。
   还有一些选项字段：窗口扩大，时间戳，选择确认SACK选项等。

5.6 TCP可靠传输的实现

这里为了讨论方便，假定数据传输只在一个方向进行。

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

  TCP滑动窗口是以字节为单位的。
  发送窗口表示，在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用，知道接收方发过来。
  发送窗口的大小要视对方接受窗口而定（也就是对方发过来TCP报文首部的窗口字段），以及网络的拥塞程度。

  要描述一个窗口的状态需要三个指针，指针指向字节的序号。

  接收方会对按序收到的数据中的最高序号给出确认。

  缓存空间和序号空间都是有限的，并且是循环使用的。
  发送窗口通常只是发送缓存的一部分。发送缓存和发送窗口的后延是重合的（数据前发送出去的一端）。
  TCP通常对不按序到达的数据是先临时存放在接受窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
  TCP的通信是全双工的，每一方都有自己的发送窗口和接收窗口。

5.6.2 超时重传时间的选择

  若超时重传的时间设置的太短，就会引起很多报文段不必要的重传，使网络负荷增大。 若把超时重传时间设置的过长，则又使网络的空闲时间增大，降低了传输效率。
  TCP采用的是一种自适应算法，超时重传时间RTO略大于加权平均往返时间RTT_s，大于的部分可以用每次RTT偏差的加权平均值RTT_D来衡量。
  如果发生了重传，收到的确认是对之前报文的确认，还是对重传报文的确认，这会影响超时重传时间的计算。对此，有了Karn算法，报文段每重传一次，就把超时重传时间RTO增大一些，当不发生重传时，按照之前的方法计算。

5.6.3 选择确认SACK

  选择确认（Selective ACK），接收方收到了和前边字节流不连续的字节块，如果这些字节的序号在接收窗口之内，那么接收方就先收下这些数据，但是要把这些信息准确告诉发送方，使发送方不重复发送这些已经收到的数据。
  每一个不连续的字节块都有左右边界，指明一个边界要用4个字节，而选项长度最长40字节，因此最多能指明4个字节块的信息。（4 * 2 * 4 = 32字节）

5.7 TCP的流量控制

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

  流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。
  发送方的发送窗口不能超过接收方给出的接收窗口的数值，TCP的窗口单位是字节。
  考虑一种特殊的情况：若B向A发送了零窗口报文段后不久，B的接收缓存又有了一些存储空间，于是B向A发送了接收窗口rwnd = 400 的报文段。然而这个报文段在传送过程中丢失了。A一直等待B发送的非零窗口的通知，而B也一直等待A发送的数据，出现了相互等待的死锁局面。
  为了解决此问题，TCP为每一个连接设有持续计数器（persistence timer），只要TCP连接的一方收到了对方零窗口的通知，就启动持续计时器。若持续计时器设置的时间到了，就发送一个零窗口探测报文，对方在确认这个探测报文段时给出了现在的窗口值。如果窗口值仍然是零，就重置持续计时器；如果不是零，就打破了死锁的僵局。

5.7.2 TCP的传输效率

  可以用不同的机制来控制 TCP报文段的发送时机：
  （1）TCP维持一个变量，它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去。
  （2）由发送方的应用进程指明要求发送报文段，即TCP支持的推送（push）操作。
  （3）发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段发送出去。（长度不能超过MSS）

  TCP的实现中， 广泛使用Nagle算法。
  发送应用进程把要发送的数据逐个字节的送到TCP的发送缓存中，发送方把第一个数据字节先发送过去，把后面到达的数据字节都缓存起来。
  当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后的数据进行缓存。
  当数据到达较快，网络速率较慢时，这样的方法可以减少所用的网络带宽。
  当到达的数据已达到发送窗口大小的一半，或已达到报文段的最大长度时，就立即发送一个报文段，这样做可以有效的提高网络的吞吐量（单位时间通过网络的实际数据量）。

  糊涂窗口综合征（silly window syndrome），有时也会使TCP的性能变坏。
  设想接收方缓存已满，而应用程序每次只从接收缓存中读取一个字节，然后向发送方发送确认，并把窗口设置为1个字节（但发送的数据报是40字节长）。
  接着，发送方又发来一个字节的数据（IP数据报是41字节），发送方发回确认，仍将窗口设置为1个字节。
  这样进行下去，会使网络效率很低。
  要解决这个问题，可以让发送方把数据积累成足够大的报文段，或者达到接收方缓存的空间的一半大小；接收方等待一段时间，使得接收缓存有足够的空间容纳一个最长的报文段，或等到接收缓存已有一半空闲的空间，再发出确认报文。

5.8 TCP的拥塞控制

5.8.1 拥塞控制的一般原理

  网络的资源包括链路容量（即带宽），交换结点中的缓存和处理机等。
  若某一段时间，对网络中某一资源的需求，超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞（congestion）。
  问题的实质往往是整个系统的各个部分不匹配。只有所有部分都平衡了，问题才会得到解决。
  拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。 而流量控制往往是点对点通信量的控制，所要做的是抑制发送端发送数据的速率，以便使接收端来得及接收。
  由于缺少缓存空间而被丢弃的分组的百分数、平均队列长度、超时重传的分组数、平均分组时延、分组时延的标准差 等，这些指标的上升都标志拥塞的增长。

5.8.2 TCP的拥塞控制方法

  拥塞控制的方法有四种，分别是慢开始（slow-start）、拥塞避免（congestion avoidance）、快重传（fast retransmit）和快恢复（fast recovery）。
  这里假设数据单方向传送，对方只发送确认报文；接收方有足够的缓存空间，发送窗口的大小由网络的拥塞程度决定。

  发送方控制拥塞窗口cwnd的原则是：只要网络没有出现拥塞，拥塞窗口就可以增大一些，以便把更多的分组发送出去，提高网络的利用率；但是只要网络有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，缓解网络出现的拥塞。
  判断网络拥塞的依据就是出现了超时。因为现在通信线路的质量一般都很好，因传输差错而丢弃分组的概率是很小的。

  ①慢开始：当主机开始发送数据时，由小到大逐渐增大拥塞窗口的数值。 可以增加最多一个SMSS的数值。（根据发送方的不同最大报文段SMSS的数值大小，初始拥塞窗口一般不超过2~4个SMSS）

  实际上，发送方只要收到一个对新报文段的确认，其拥塞窗口就立即加1，并可以立即发送新的报文段，而不需要等这个轮次中所有的确认都收到后再发送新的报文段。
  为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。当 $cwnd\ge ssthresh$ 时，使用拥塞避免算法。

  ②拥塞避免：每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加一。而不是像慢开始阶段那样加倍增长。
  拥塞避免把拥塞窗口控制为按线性增长，使网络比较不容易出现拥塞。

  ③快重传：让发送方尽早知道发生了个别报文段的丢失。可以提高网络的吞吐量约20%。
  快重传要求接收方即使收到了失序的报文段，也要立即发出对已收到的报文段的重复确认。如下图，因为每次都要立即发送确认，M₃丢失了，因此之后在依次发送M₄、M₅、M₆时，会受到三个重复的对M₂的确认。
  快重传算法规定，发送方只要一连收到3个重复确认，就知道接收方确实没有收到报文段M₃，因而立即进行重传。这样就不会出现超时，发送方就不会误认为出现了网络拥塞。

  ④快恢复：发送方知道现在只是丢失了个别的报文段，于是不启动慢开始，而是执行快恢复算法。 这次慢开始门限值和拥塞窗口 都变为 原来拥塞窗口值 的一半，并开始执行拥塞避免算法。

  其中，发送窗口的上限值，应为接收方窗口rwnd 和拥塞窗口cwnd 的最小值.

5.8.3 主动队列管理AQM

  路由器的队列通常都是按照“先进先出”FIFO的规则处理到来的分组，由于队列长度是有限的，当队列已满时，以后再到达的所有分组将都被丢弃。这就叫尾部丢弃策略。
  网络中通常有很多TCP连接，这些连接的报文段通常是复用（发送方不同协议的数据都可以封装成IP数据报发送出去）在网络层的IP数据报中传送的，若发生路由器的尾部丢弃，很可能会影响多条TCP连接，使许多TCP连接突然都进入到慢开始状态（因为发生了超时）。这在TCP的术语中成为全局同步。
  主动队列管理AQM：（避免全局同步）在队列长度达到某个值得警惕的数值时，主动丢弃到达的分组。这样就提醒了发送方放慢发送的速率，因而有可能使网络拥塞的程度减轻，甚至不出现网络拥塞。

5.9 TCP的运输连接管理

TCP是面向连接的协议。运输连接是用来传送TCP报文的。运输连接的三个阶段：连接建立，数据传送，连接释放。

5.9.1 TCP的连接建立

  主动发起TCP连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫做服务器。
  TCP的连接建立采用三报文握手机制。服务器要确认客户的连接请求，然后客户要对服务器的确认进行确认。

  连接建立的过程就是要解决以下的问题：（探测对方能力）
  （1）要使每一方能确知对方的存在。
  （2）允许双方协商一些参数（比如最大窗口值，是否使用窗口扩大选项和时间戳选项以及服务质量等）。
  （3）能够对运输实体资源进行分配（如缓存表大小，连接表中的项目等）。

  这里三次握手中的第二次握手，把SYN与ACK一起发送到客户端了。其实四次也是可以的，服务器先发送确认报文段（ACK=1），之后再发送同步报文段（SYN=1,连接请求）。

  发送最后一次确认的原因：
  假定出现一种异常情况，主动方A发出的连接请求报文段没有丢失，而是在某个网络结点长时间逗留了，以致延误到连接释放以后的某个时间才到达另一方B。
  虽然这是一个失效的报文段，但是B收到后仍然会向A发出确认报文段。
  如果没有第三次握手，那么A不会理睬B发送的确认报文段，而B以为新的运输连接建立了，这样就造成了资源的浪费。

5.9.2 TCP的连接释放

  TCP的连接释放采用四报文握手机制。
  任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后就进入半关闭状态。
  当另一方也没有数据再发送时，则发送连接释放通知，对方确认后就完全关闭了TCP连接。

  一方进入半关闭状态之后，另一方还可以继续发送数据，待数据发送结束后再释放连接，因此采用四次而不是三次（如果是三次，那么就是在确认对方关闭请求的时候，捎带自己的关闭请求信息，这样就不能再发送数据了）。

  主动关闭连接的一方在收到对方的连接释放请求之后，要进入time wait状态，等待时间大约是2MSL（最长报文段寿命 Maximun segment lifetime）。原因如下：
  （1）为了保证主动方发送的最后一个ACK报文段能够到达另一方。（如果没有这一段等待时间，并且主动方发送的ACK报文段丢失了，另一方会超时重传连接释放FIN+ACK报文段，而此时主动方已经释放连接了，无法收到这个报文段，也就无法回应确认，另一方就无法正常关闭了）
  （2）防止“已失效的连接请求报文段”出现在本连接中。（等待的这2MSL时间，就可以使本连接持续的时间内所产生的报文段都从网络中消失。）

  TCP还有一个保活计时器（keepalive timer）。针对客户已经与服务器主动建立了连接，但是客户端主机突然故障的情况。服务器每收到客户的数据就会重置保活计时器，时间通常是2个小时，若这个时间内还没有收到客户的数据，那么就要向客户发送一个探测报文，之后每隔75秒发送一次，如果10次后客户还是没有响应，那么服务器就会认为客户端出现了故障而关闭连接。