五、运输层

1.运输层向它上面的应用层提供通信服务

它属于面向通信部分的最高层，同时也是用户功能中的最底层。

 

两个主机进行通信就是两个主机中的应用进程互相通信。

 

从运输层的角度看，通信的真正端点并不是主机而是主机中的进程。即：端到端的通信是应用进程之间的通信。

 

运输层有一个很重要的功能——复用(multiplexing)和分用(demulitiplexing)。复用指在发送方不同的应用进程都可以使用同一个运输层协议传达数据。分用是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。

 

网络层是为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。

 

运输层对收到的报文进行差错检测。运输层需要提供两种不同的运输协议，即面向连接的TCP和无连接的UDP.

 

运输层向高层用户屏蔽了下面网络核心的细节，它使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道。

 

2.运输层的两个主要协议

UDP：用户数据保协议

(1)  UDP是无连接的，即发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。

(2)  UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表。

(3)  UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文。

(4)  UDP没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。很多的实时应用（如IP电话、实时视频会议等）要去源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，但却不允许数据有太多的时延。UDP正好符合这种要求。

(5)  UDP支持一对一、一对多、多对一和多对多的交互通信。

(6)  UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。
 

注意：(1)  不使用拥塞控制功能的UDP有可能会引起网络产生严重的拥塞问题。

(2)  一些使用UDP的实时应用进程本身可以在不影响应用的实时性的前提下，增加一些提高可靠性的措施，如采用前向纠错或重传已丢失的报文。

UDP的首部格式：用户数据报UDP有两个字段：数据字段和首部字段。首部字段很简单，只有8个字节，由四个字段组成，每个字段的长度都是两个字节。各字段的意义如下：

(1)  源端口      源端口号。在需要对方回信时选用。不需要时可用全0。

(2)  目的端口    目的端口号。 这在终点交付报文时必须要使用到。

(3)  长度        UDP用户数据报的长度，其最小值是8（仅有首部）

(4)  检验和      检测UDP用户数据报在传输中是否有错。有错就丢弃。
 

UDP计算校检和的方法和计算IP数据报首部校检和的方法相似。但不同的是：IP数据报的校检和只校检IP数据报的首部，但UDP的校检和使把首部和数据部分一起都校检。

TCP:传输控制协议

TCP最主要的特点

（1）面向连接的运输层协议；

（2）每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的（端到端的通信）；

（3）TCP提供可靠交付的服务(高可靠性，确保传输数据的正确性，不出现丢失或乱序)；

（4）全双工方式传输；

（5）采用字节流方式，即以字节为单位传输字节序列；

 

TCP连接：TCP把连接作为最基本的抽象。

TCP连接的端点是个很抽象的套接字，即（IP地址：端口号）。同一个IP地址可以有多个不同的TCP链接，而同一个端口号也可以出现在多个不同的TCP连接中。

 

TCP报文段的首部格式

概述：TCP报文段首部的前20个字节是固定的，因此TCP首部的最小长度是20字节。
 

源端口和目标端口

　　各占2个字节，分别写入源端口号和目的端口号。

序列号

　　占4个字节，表示本报文段所发送数据的第一个字节的编号。在TCP连接中所传送的字节流的每一个字节都会按顺序编号。由于序列号由32位表示，所以每2^32个字节，就会出现序列号回绕，再次从 0 开始。

确认号

　　占4个字节，是期望收到对方写一个报文段的第一个数据字节的序号。若确认号=N，则表明：到序号N-1为止的所有数据都已正确收到。

数据偏移（TCP首部长度）

　　占4位，它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。这个字段实际上是指出TCP报文段的首部长度，由于4位二进制数能够表示的最大十进制数字是15，因此数据偏移的最大值是60字节，这也是TCP首部的最大长度。

紧急URG控制位

　　当URG=1时，表明紧急指针字段有效。它告诉系统此报文中有紧急数据，应尽快传送，而不要按原来的排队顺序来传送。当URG置1时，发送方TCP就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍是普通数据。这时要与首部中的紧急指针字段配合使用。

确认ACK控制位

　　仅当ACK=1时，确认号字段才有效，TCP规定，在连接建立后的所有传送的报文段都必须要ACK置1。

推送PSH控制位

　　发送方TCP把PSH置1，并立即创建一个报文段发送出去。接收方TCP收到PSH=1的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。

复位RST控制位

　　当RST=1时，表明TCP连接中出现了严重差错，必须释放连接，然后再重新建立运输连接。

同步SYN控制位

　　在连接建立时用来同步序号，当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。因此，SYN置为1就表示这是一个连接请求或连接接受请求。

终止FIN控制位

　　用来释放一个连接。当FIN=1时，表明此段报文段的发送发的数据已经发送完毕，并要求释放运输连接。

窗口

　　占2个字节。窗口指的是发送本报文段的接受窗口。窗口值告诉对方：从本报文段首部中的确认好算起，接收方目前允许对方发送的数据量。窗口值作为接收方法让发送方设置其发送窗口的依据。窗口字段明确指出了现在允许对方发送的数据量。窗口值是经常动态变化的。

紧急指针

　　占2个字节。指出本报文段中紧急数据的字节数。

选项

　　长度可变，最长可达40字节。当没有使用“选项”时，TCP的首部长度是20字节。

选项部分的应用：

1）MSS最大报文段长度(Maxium Segment Size)：指明数据字段的最大长度，数据字段的长度加上TCP首部的长度才等于整个TCP报文段的长度。MSS值指示自己期望对方发送TCP报文段时那个数据字段的长度。通信双方可以有不同的MSS值。如果未填写，默认采用536字节。MSS只出现在SYN报文中。即：MSS出现在SYN=1的报文段中。

 

2）窗口扩大选项(Windows Scaling)：由于TCP首部的窗口大小字段长度是16位，所以其表示的最大数是65535。但是随着时延和带宽比较大的通信产生（如卫星通信），需要更大的窗口来满足性能和吞吐率，所以产生了这个窗口扩大选项。

 

3）SACK选择确认项(Selective Acknowledgements)：用来确保只重传缺少的报文段，而不是重传所有报文段。比如主机A发送报文段1、2、3，而主机B仅收到报文段1、3。那么此时就需要使用SACK选项来告诉发送方只发送丢失的数据。那么又如何指明丢失了哪些报文段呢？使用SACK需要两个功能字节。一个表示要使用SACK选项，另一个指明这个选项占用多少字节。描述丢失的报文段2，是通过描述它的左右边界报文段1、3来完成的。而这个1、3实际上是表示序列号，所以描述一个丢失的报文段需要64位即8个字节的空间。那么可以推算整个选项字段最多描述(40-2)/8=4个丢失的报文段。

 

4）时间戳选项（Timestamps）：可以用来计算RTT(往返时间)，发送方发送TCP报文时，把当前的时间值放入时间戳字段，接收方收到后发送确认报文时，把这个时间戳字段的值复制到确认报文中，当发送方收到确认报文后即可计算出RTT。也可以用来防止回绕序号PAWS，也可以说可以用来区分相同序列号的不同报文。因为序列号用32为表示，每2^32个序列号就会产生回绕，那么使用时间戳字段就很容易区分相同序列号的不同报文。

 

5）NOP(NO-Operation)：它要求选项部分中的每种选项长度必须是4字节的倍数，不足的则用NOP填充。同时也可以用来分割不同的选项字段。如窗口扩大选项和SACK之间用NOP隔开。

 

3.TCP可靠传输的实现

TCP协议通过使用连续ARQ协议和滑动窗口协议，来保证数据传输的正确性，从而提供可靠的传输。

 

ARQ协议，即自动重传请求（Automatic Repeat-reQuest），是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议，拥有错误检测（Error Detection）、正面确认（Positive Acknowledgment）、超时重传（Retransmission after Timeout）和 负面确认及重传（Negative Acknowledgment and Retransmission）等机制。

 

连续ARQ协议：由于停止等待ARQ协议信道利用率太低，所以需要使用连续ARQ协议来进行改善。这个协议会连续发送一组数据包，然后再等待这些数据包的ACK。

发送方采用流水线传输。流水线传输就是发送方可以连续发送多个分组，不必每发完一个分组就停下来等待对方确认。如下图所示：

连续ARQ协议通常是结合滑动窗口协议来使用的，发送方需要维持一个发送窗口，如下图所示：

图（a）是发送方维持的发送窗口，它的意义是：位于发送窗口内的5个分组都可以连续发送出去，而不需要等待对方的确认，这样就提高了信道利用率。 

连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。例如上面的图（b），当发送方收到第一个分组的确认，就把发送窗口向前移动一个分组的位置。如果原来已经发送了前5个分组，则现在可以发送窗口内的第6个分组。

接收方一般都是采用累积确认的方式。也就是说接收方不必对收到的分组逐个发送确认。而是在收到几个分组后，对按序到达的最后一个分组发送确认。如果收到了这个分组确认信息，则表示到这个分组为止的所有分组都已经正确接收到了。 

累积确认的优点是容易实现，即使确认丢失也不必重传。但缺点是，不能正确的向发送方反映出接收方已经正确收到的所以分组的信息。比如发送方发送了前5个分组，而中间的第3个分组丢失了，这时候接收方只能对前2个发出确认。而不知道后面3个分组的下落，因此只能把后面的3个分组都重传一次，这种机制叫Go-back-N（回退N），表示需要再退回来重传已发送过的N个分组。

 

滑动窗口协议：在发送方和接收方之间各自维持一个滑动窗口，发送方是发送窗口，接收方是接收窗口，而且这个窗口是随着时间变化可以向前滑动的。它允许发送方发送多个分组而不需等待确认。TCP的滑动窗口是以字节为单位的。

如下图所示，发送窗口中有四个概念：：已发送并收到确认的数据（不在发送窗口和发送缓冲区之内）、已发送但未收到确认的数据（位于发送窗口之内）、允许发送但尚未发送的数据（位于发送窗口之内）、发送窗口之外的缓冲区内暂时不允许发送的数据。

 

接收窗口中也有四个概念：已发送确认并交付主机的数据（不在接收窗口和接收缓冲区之内）、未按序收到的数据（位于接收窗口之内）、允许的数据（位于接收窗口之内）、不允许接收的数据（位于发送窗口之内）。
 

规则：

1）凡是已经发送过的数据，在未收到确认之前，都必须暂时保留，以便在超时重传时使用。

2）只有当发送方A收到了接收方的确认报文段时，发送方窗口才可以向前滑动几个序号。

3）当发送方A发送的数据经过一段时间没有收到确认（由超时计时器控制），就要使用回退N步协议，回到最后接收到确认号的地方，重新发送这部分数据。

 

4.TCP可靠传输、流量控制和拥塞控制的实现

可靠传输：

l 对于收到的请求，给出确认响应

l 超时重传

流量控制：

    所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。利用滑动窗口实现流量控制。

设A向B发送数据。在连接建立时，B告诉A：我的接收窗口rwnd=400。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。TCP窗口单位是字节，不是报文段。
 

上图中：接收方的主机B进行了三次流量控制。第一次把小黄口减小到rwnd=300,第二次又减到rwnd=100，最后减到rwnd=0，即不允许发送方再发送数据了。

考虑一种特殊的情况，就是接收方若没有缓存足够使用，就会发送零窗口大小的报文，此时发送放将发送窗口设置为0，停止发送数据。之后接收方有足够的缓存，发送了非零窗口大小的报文，但是这个报文在中途丢失的，那么发送方的发送窗口就一直为零导致死锁。

解决这个问题，TCP为每一个连接设置一个持续计时器（persistence timer）。只要TCP的一方收到对方的零窗口通知，就启动该计时器，周期性的发送一个零窗口探测报文段。对方就在确认这个报文的时候给出现在的窗口大小（注意：TCP规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段）。

拥塞控制：

所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。

    慢开始（Slow-start)
    慢开始的“慢”并不是指增长速率的慢，而是指在TCP开始发送报文段时先设置拥塞窗口为1。

算法流程如下

1）连接建好的开始先初始化cwnd = 1，表明可以传一个SMSS大小的数据。

2）每当收到一个ACK，cwnd++; 呈线性上升

3）每当过了一个RTT，cwnd = cwnd*2; 呈指数让升

4）还有一个慢启动门限ssthresh（slow start threshold），是一个上限，当cwnd >= ssthresh时，就会进入拥塞避免。

5)当遇到RTO超时重传时会触发cwnd和ssthresh的调整，ssthresh=max(cwnd/2, 2)，cwnd=1，然后重新开始慢启动过程。

    拥塞避免（Congestion Avoidance)
    使拥塞窗口按线性规律增长。

从慢启动可以看到，cwnd可以很快的增长上来，从而最大程度利用网络带宽资源，但是cwnd不能一直这样无限增长下去，一定需要某个限制。TCP使 用了一个叫慢启动门限(ssthresh)的变量，当cwnd超过该值后，慢启动过程结束，进入拥塞避免阶段。慢启动门限 ssthresh 的用法如下：

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

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

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

分别对图中标示的箭头做如下说明：

1)在标号为1的箭头处，TCP初始连接进行数据交换，开始慢启动，初始cwnd=IW=1，ssthresh=16，在传输轮次0-4阶段进行慢启动过程，cwnd按照1-2-4-8-16的顺序进行指数增长

2)在标号为2的箭头处，cwnd=16=ssthresh，此时触发拥塞避免过程，开始线性增长，在传输轮次4-12阶段，cwnd按照16-17-18-19-20-21-22-23-24进行线性增长。

3)在标号为3的箭头处，TCP发生了RTO重传，认为网络发生拥塞，于是设置ssthresh=cwnd/2=12，cwnd=1重新进行慢启动过程

4)在标号为4的箭头处，TCP从cwnd=1开始重新开始慢启动过程

5)在标号为5的箭头处，当 cwnd = 12 时改为执行拥塞避免算法，拥塞窗口按按线性规律增长，每经过一个往返时延就增加一个 MSS 的大小。  

快重传（Fast Restrangsmit)
    发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待为其设置的重传计时器到期。

 快恢复(与快重传配合使用)（Fast Recovery）
    当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢开始门限减半。这是为了预防网络发生拥塞。请注意，接下来不执行慢开始算法。

    由于发送方现在认为网络很可能没有发生拥塞(如果网路发生了严重的拥塞，就不会一连有好几个报文段连续达到接收方，就不会导致接收方连续发送重复确认)，因此与慢开始不同之处是现在不执行慢开始算法(即拥塞窗口现在不设置为1)，而是把它设置为慢开始门限减半后的数值，然后开始执行拥塞避免算法(“加法增大”)，使拥塞窗口缓慢地线性增大。

下图是慢启动和拥塞避免(快重传和快恢复)的一个可视化描述。我们以段为单位来显示cwnd和ssthresh，但它们实际上都是以字节为单位进行维护的。

指数增长—>加法增大—>乘法减小(超时)—>加法增大(快恢复)
 

一条TCP连接有时会因等待重传计时器的超时而空闲较长的时间，慢开始和拥塞避免无法很好的解决这类问题，因此提出了快重传和快恢复的拥塞控制方法。

     快重传算法并非取消了重传机制，只是在某些情况下更早的重传丢失的报文段（如果当发送端接收到三个重复的确认ACK时，则断定分组丢失，立即重传丢失的报文段，而不必等待重传计时器超时）。

    例如：M1，M2，M3 -----> M1,M3,缺失M2，则接收方向发送方持续发送M2重复确认，当发送方收到M2的三次重复确认，则认为M2报文丢失，启动快重传机制，重传数据，其他数据发送数据放入队列，待快重传结束后再正常传输。

     快恢复算法有以下两个要点：

     1）当发送方连续收到接收方发来的三个重复确认时，就执行“乘法减小”算法，把慢开始门限减半，这是为了预防网络发生拥塞。

     2）由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是把cwnd(拥塞窗口)值设置为慢开始门限减半后的值，然后开始执行拥塞避免算法，使拥塞窗口的线性增大。

 

5.TCP运输连接管理

1）TCP的连接建立(用三次握手建立TCP连接)
 

为什么A还要发送一次确认呢？

这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到此失效的连续请求报文段后，就误认为是A又发出新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了。

由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却认为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。

采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下，A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求建立连接。

 

2）TCP的连接释放(四次挥手)
 

**A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。A把连接释放报文段首部的FIN置1，其序号seq=u，它等于前面已传送过的数据的最后一个字节的序号加1。这时A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。

 

**B收到连接释放报文段后即发出确认，确认号是ack=u+1，而这个报文段自己的序号是v，等于B前面已传送过的数据的最后一个字节的序号加1。然后B就进入了CLOSE-WAIT(关闭等待)状态。因而从A到B这个方向的连接释放了，这时的TCP连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收。

 

**A收到来自B的确认后，就进入FIN-WAIT-2(终止等待2)状态，等待B发出的连接释放报文段。

 

**若B已经没有要向A发送的数据，其应用程序就通知TCP释放连接。这时B发出的连接释放该报文段必须使FIN=1。现假定B的序号为w(在半关闭状态B可能又发送了一些数据)。B还必须重复上次已发送过的确认号ack=u+1。这时B就进入LAST_ACK(最后确认)状态，等待A的确认。

 

**A在收到B的连接释放该报文段后，必须对此发出确认。在确认报文段中把ACK置1，确认号ack=w+1，而自己的序号是seq=u+1。然后进入到TIME-WAIT(时间等待)状态。请注意，现在TCP连接还没有释放掉。必须经过时间等待计时器(TIME-WAIT timer)设置的时间2MSL后，A才进入到CLOSED状态。

为什么A在TIME-WAIT状态必须等待2MSL的时间呢？

 

**为了保证A发送的最后一个ACK报文段能够到达B

**防止已失效的连接请求报文段出现在本连接中。