运输层（计网_05）

第五章 运输层

计算机网络体系结构

5.1 运输层协议

5.1.1进程之间的通信

• 从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。
• 当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时，只有位于网络边缘部分的主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到下三层的功能。

（1）运输层的作用

• 从IP层来说，通信的两端是两台主机。
• 从运输层的角度看，通信的真正端点并不是主机而是主机中的进程。也就是说，端到端的通信时应用进程之间的通信。

（2）端系统之间通信的含义

• “主机A和主机B进行通信”实际上是指“运行在主机A上的某个程序和运行在主机B上的另一个程序进行通信“（计算机之间通信）。端到端的通信时进程之间的通信。

（3）运输层的作用

运输层为相互通信的应用进程提供了 逻辑通信

（4）网络层和运输层有明显的区别

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

（5）基于端口的复用和分用功能

• 复用：是指在发送方不同的应用进程都可以使用同一个运输层协议传送数据（需要加上适当的首部）。
• 分用：是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。
  

（6）屏蔽作用

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

（7）两种不同的运输协议

• TCP：当运输层采用面向连接的TCP协议时，尽管下面的网络是不可靠的（只提供尽最大努力服务），但这种逻辑通信信道就相当于一条全双工的可靠信道。
• UDP：当运输层采用无连接的UDP协议时，这种逻辑通信信道是一条不可靠信道。

5.1.2运输层的两个主要协议

TCP/IP的运输层有两个主要协议：

1. 用户数据报协议UDP（user datagram protocol）
2. 传输控制协议TCP（transmission control protocol）

（1）TCP与UDP

• 运输协议数据单元TPDU：两个对等运输实体在通信时传送的数据单元。
• TCP传送的数据单位协议是TCP报文段
• UDP传送的数据单位协议是UDP报文或用户数据报。

（2）使用UDP和TCP的典型应用和应用层协议

• 运输层的UDP用户数据报与网际层的IP数据报有很大区别
  1. IP数据报要经过互连网中许多路由器的存储转发
  2. UDP用户数据报是在运输层的端到端抽象的逻辑信道中传送的。
• TCP报文段是在运输层抽象的端到端逻辑信道中传送，这种信道是可靠的全双工信道。但这样的信道却不知道究竟经过了哪些路由器，而这些路由器也根本不知道上面的运输层是否建立了TCP连接。

5.1.3 运输层的端口

• 运行在计算机中的进程是用进程标识符来标志的。为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须用统一的方法对TCP/IP体系的应用进程进行标志。

（1）端口号（protocol port number）

A、问题

由于进程的创建和撤销都是动态的，发送方几乎无法识别其他机器上的进程。有时我们会改换接收报文的进程，但并不需要通知所有发送方。我们往往需要利用目的主机提供的功能来识别终点，而不需要知道实现这个功能的进程。

B、解决问题的方法

在运输层使用协议端口号。简称为端口。

我们可以把端口想象成通信的终点，因为我们只要把要传送的报文交到目的主机的某一个合适的目的端口，剩下的工作（即最后交付目的进程）就由TCP来完成。

C、软件端口和硬件端口

• 软件端口：在协议栈层间的抽象的协议端口
• 硬件端口：路由器或交换机上的端口

硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。

（2）TCP/IP运输层端口

• TCP/IP的运输层用一个16位端口号来标志一个端口。允许有65535个不同的端口号。
• 端口号只具有本地意义，即端口号只是为了标志本计算机应用层中的各进程。
  

两个计算机中的进程要互相通信，不仅必须知道对方的端口号（为了找到对方计算机中的应用进程），而且还要知道对方的IP地址（为了找到对方的计算机）。

（3）两大类端口

服务器端使用的端口

1. 熟知端口，数值一般为0-1023
2. 登记端口号，数值为1024-49151，为没有熟知端口号的应用程序使用的。

客户端使用的端口号

1. 又称为短暂端口号，数值为49152-65535，留给客户进程短暂时使用。

5.2.1UDP概述

• UDP只在IP的数据报服务之上增加了很少的一点功能：
  1. 复用和分用的功能
  2. 差错检测的功能

（1）UDP的主要特点

1. UDP是无连接的。发送数据之前不需要建立连接，因此减小了开销和发送数据之前的时延。
2. UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表。
3. UDP是面向报文的。UDP对应用层交下来的报文，即不合并，也不拆分，而是保留这些报文的边界。UDP一次交付一个完整的报文。
4. UDP没有拥塞控制，因此网络出现的拥塞不会使主机的发送速率降低。这对某些实时应用时很重要的。很适合多媒体通信的要求。
5. UDP支持一对一，一对多，多对一和多对多的交互通信
6. UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。

（2）面向报文的UDP

• 发送方UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。
• 应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。
• 接收方UDP对IP层交上来的UDP用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文。
• 应用程序必须选择合适大小的报文。
  1. 若报文太长，UDP把它交给IP层后，IP层在传送时可能要进行分片，这会降低IP层的效率。
  2. 若报文太短，UDP把它交给IP层后，会使IP数据报的首部的相对长度太大，这也降低了IP层的效率。
     
     

5.2.2UDP的首部格式

用户数据报UDP有两个字段：数据字段和首部字段。

首部字段有8个字节，由4个字段组成，每个字段都是2个字节。

5.3 传输控制协议TCP概述

5.3.1 TCP最主要的特点

• TCP是面向连接的运输层协议，在无连接的、不可靠的IP网络服务基础之上可靠交付的服务。为此，在IP的数据服务基础之上，增加了保证可靠性的一系列措施。
• 每一条TCP连接只能有两个端点，每一条TCP连接只能是对点的（一对一）
• TCP提供可靠交付的服务，提供全双工通信。
• 面向字节流
  1. TCP中的“流”（stream）指的是流入或流出进程的字节序列。
  2. “面向字节流”的含义是：虽然应用程序和TCP的交互式一次一个数据块，但TCP把应用程序交下来的数据看成仅仅是一连串无结构的字节。

（1）TCP面向流的概念

• TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系。
• 但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。

注意：

• TCP连接是一条虚连接而不是一条真正的物理连接
• TCP对应用进程一次把多长的报文发送到TCP的缓存中是不关心的。
• TCP根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个（UDP发送的报文长度是应用进程给出的）
• TCP可把太长的数据块划分短一些再传送。
• TCP也可等待积累有足够多的字节后再构成报文段发送出去。

5.3.2 TCP的连接

• TCP把连接作为最基本的抽象。
• 每一条TCP连接有两个端点。
• TCP连接的端点不是主机，不是主机的IP地址，不是应用进程，也不是运输层的协议端口。TCP连接的端点叫做套接字（socket）或插口。
• 端口号拼接到IP地址即构成了套接字。192.89.9.9：8080

每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定。即

（1）TCP连接，IP地址，套接字

• TCP连接就是由协议软件所提供的一种抽象
• TCP连接的端点是个很抽象的套接字，即（IP地址：端口号）
• 同一个IP地址可以有很多个不同的TCP连接。
• 同一个端口号也可以出现在多个不同的TCP连接中。

5.4可靠传输的工作原理

5.4.1 停止等待协议

• “停止等待”就是每发送完一个分组就停止发送，等待对方的确认。收到确认后再发送下一个分组。
• 全双工通信的双方既是发送方也是接收方。

（1）无差错情况

（2）出现差错及解决方法

A、接收方B会出现两种情况：

• 在接收方B会出现两种情况：
  1. B接收M1时检测出了差错，就丢弃M1，其他什么也不做（不通知A收到有差错的分组）
  2. M1在传输过程中丢失了，这时B当然什么都不知道，也什么都不做。
• 在这两种情况下，B都不会发送任何信息。
• 但A都必须重发分组，直到B正确接收为止，这样才能实现可靠通信。

B、问题：A如何知道B是否正确收到了M1呢？

• 解决方法：超时重传
  1. A为每一个已发送的分组都设置了一个超时计时器。
  2. A只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器，继续发送下一个分组M2.
  3. 若A在超时计时器规定时间内没有收到B的确认，就认为分组错误或丢失，就重发该分组。

C、若分组到达B，但B回送的确认丢失或延迟了，A未收到B的确认，会超时重发。B可能会收到重复的M1。B如何知道收到了重复的分组，需要丢弃呢？

• 解决方法：编号
  1. A为每一个发送的分组都进行编号。若B收到了编号相同的分组，则认为收到了重复分组，丢弃重复的分组，并回送确认。
  2. B为发送的确认也进行编号，指示该确认是对哪一个分组的确认
  3. A根据确认机器编号，可以确定他是对哪一个分组的确认，避免重发发送。若为重复的确认，则将其丢弃。

（3）确认丢失和确认迟到

• 确认丢失
  1. 若B所发送的对M1的确认丢失了，那么A在设定的超时重传时间内不能收到确认，但A并无法知道：是自己发送的分组出错、丢失了，或者是B发送的确认丢失了。因此A在超时计时器到期后就要重传M1.
  2. 假定B又收到了重传的的分组M1。这时B应采取两个行动：
     1. 第一，丢弃这个重复的分组M1，不向上层交付。
     2. 第二，向A发送确认。不能认为已经发送过确认就不再发送，因为A之所以重传M1就表示A没有收到对M1的确认。
• 确认迟到
  1. 传输过程中没有出现差错，但B对分组M1的确认迟到了。
  2. A会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃。
  3. B仍然会收到重复的M1，并且同样要丢弃重复的M1，并重传确认分组。

请注意：

• 在发送完一个分组后，必须暂时保留已发送的分组的副本，以备重发。
• 分组和确认分组都必须进行编号。
• 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。

（4）自动重传请求ARQ、

• 通常A最终总是可以收到对所有发出的分组的确认。如果A不断重传分组但是收不到确认，就说明通信线路太差，不能进行通信。
• 使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。
• 像上述的这种可靠传输协议常称为自动重传请求ARQ。意思是重传的请求时自动进行的，接收方不需要请求发送方重传某个出错的分组。

（5）信道利用率

• 可以看出，当往返时间RTT远大于分组发送时间TD时，信道的利用率就会非常低。

• TD：A发送分组需要的时间。
• TA：B发送确认分组需要时间。
• RTT：往返时间。

（6）流水线传输

• 流水线传输：就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。这样可以使信道上一直有数据不间断地传送。
• 可以获得很高的信道利用率。

停止等待协议要点：

• 停止等待
• 编号
• 自动重传请求

5.4.2 连续ARQ协议

基本思想：

• 发送方一次可以发出多个分组。
• 使用滑动窗口协议控制发送方和接收方所能发送和接收的分组的数量和编号。
• 每收到一个确认，发送方就把发送窗口向前滑动。
• 接收方一般采用累积确认的方式。
• 采用**回退N（Go-Back-N）**方法进行重传。

(1)累积确认

• 接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都已正确收到了。
• 优点：容易实现，即使确认丢失也不必重传。
• 缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。

（2）Go-back-N（回退N）

• 如果发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。
• 这就叫做Go-back-N**（回退N），表示需要再退回来重传已发送过的N个分组**。

（3）TCP可靠通信的具体实现

• TCP连接的每一端都必须设有两个窗口-------一个发送窗口和一个接收窗口。
• TCP的可靠传输机制用字节的序号进行控制。TCP所有的确认都是基于序号而不是基于报文段。
• TCP两端的四个窗口经常处于动态变化之中。
• TCP连接的往返时间RTT也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。

（4）连续ARQ协议与停止等待协议

5.5TCP报文段的首部格式

• TCP虽然是面向字节流的，但TCP传送的数据单元却是报文段。
• 一个TCP报文段分为首部和数据两部分，而TCP的全部功能都体现在它首部中各字段的作用。
• TCP报文段首部的前29个字节是固定的，后面有4n字节是根据需要而增加的选项（n是整数）。因此TCP首部的最小长度是20字节。
  

1. 源端口和目的端口字段：各占2个字节。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。
2. 序号字段：占4字节。TCP连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。
3. 确认号：占4字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。
4. 数据偏移：占4位。他指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。“数据偏移”的单位是32位字（以4字节为计算单位）
5. 保留字段：占6位，保留为今后使用，但目前应置为0.
6. 紧急URG：当URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应当尽快传送（相当于高优先级的数据）
7. 确认ACK：只有当ACK=1时确认号字段才有效。当ACK=0时，确认号无效。
8. 推送PSH（PuSH）：接收TCP收到PSH=1的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。
9. 复位RST（ReSeT）：当RST=1时，表明TCP连接中出现严重差错（如由于主机崩溃或者其他原因），必须释放连接，然后再重新建立运输连接。
10. 同步SYN：同步SYN=1表示这是一个连接请求或连接接受报文。
11. 终止FIN（FINish）：用来释放一个连接。FIN=1表明此报文段的发送段的数据已发送完毕，并要求释放运输连接。
12. 窗口：占2字节。用来让对方设置发送窗口的依据，单位为字节。
13. 检验和：占2字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。
14. 紧急指针：占16位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文数据的最前面）。
15. 选项字段：长度可变。TCP最初只规定了一种选项，即最大报文段长度MSS。MSS告诉对方TCP：“我的缓存所能接收的报文段的数据字段的最大长度是MSS个字节”。
    • MSS（Maximum Segment SIze）：是TCP报文段中的数据字段的最大长度。数据字段加上TCP首部才等于整个的TCP报文段。所以，MSS是“TCP报文段长度减去TCP首部长度”。
16. 填充字段：这是为了使整个首部长度是4字节的整数倍。

为什么要规定MSS？

• MSS与接收窗口值没有关系。
• 若选择较小的MSS长度，网络的利用率就降低。
• 若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时还要进行重传。这些也都会使开销增大。
• 因此，MSS应尽可能大些，只要在IP层传输时不需要再分片就行。但最佳的MSS是很难确定的。

5.6 TCP可靠传输的实现

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

• TCP使用流水线传输和滑动窗口协议实现高效、可靠的传输。
• TCP的滑动窗口是以字节为单位的。
• 发送方A和接收方B分别维持一个发送窗口和一个接收窗口。
• 发送窗口表示：在没有收到确认的情况下，可以连续把窗口内的数据全部发送出去。
• 接收窗口表示：只允许接收落入窗口内的数据。

注：TCP标准强烈不赞成发送窗口前沿向后收缩。

（1）发送缓存

• 发送缓存用来暂时存放：
  1. 发送应用程序传送给发送方TCP准备发送的数据
  2. TCP已发送出但尚未收到确认的数据

（2）接收缓存

• 接收缓存用来暂时存放：
  1. 按序到达的、但尚未被接收应用程序读取的数据。
  2. 不按序到达的数据。

注意：

1. A的发送窗口并不总是和B的接收窗口一样大（因为有一定的时间滞后）
2. TCP标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
3. TCP要求接收方必须有累积确认的功能，这样可以减小传输开销。

（3）接收方发送确认

• 接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。
• 但注意：
  1. 接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，这反而浪费了网络资源。
  2. 捎带确认实际上并不经常发生，因为大多数应用进程很少同时在两个方向上发生数据。

5.6.2 超时重传时间的选择

（1）往返时延的方差很大

（2）TCP超时重传时间设置

• 如果把超时重传时间设置得太短，就会引起很多报文段的不必要的重传，使网络负荷增大。
• 若把超时重传时间设置得过长，则又使网络的空闲时间增大，降低了传输效率。
• TCP采用一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认时间。这两个时间之差就是报文段的往返时间RTT。

（3）加权平均往返时间

（4）超时重传时间RTO

（5）Karn算法

问题：

• 在计算平均往返时间RTT时，只要报文段重传了，就不采用其往返时间样本
• 这样得出的加权平均往返时间RTT_s和超时重传时间RTO就较准确。
• 但是。当报文段的时延突然增大了很多时，在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据karn算法，不考虑重传的报文段的往返时间样本。这样**，超时重传时间就无法更新**。

修正：

5.6.3 选择确认SACK（Selective ACK）

问题：若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？

• 如果要使用选择确认，那么在建立TCP连接时，就要在TCP首部的选项上加上“允许SACK”的选项，而双方必须都事先商定好。
• 如果使用选择确认，那么原来首部中的“确认号字段”的用法仍然不变。只是以后在TCP报文段的首部中都增加了SACK选项，以便报告收到的不连续的字节块的边界。
• 由于首部选项的长度最多只有40字节，而指明一个边界就要用掉4字节，因此在选项中最多只能指明4个字节块的边界信息。

5.7 TCP的流量控制

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

流量控制（flow control）：就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。

• 利用 滑动窗口机制 可以很方便地在TCP连接上实现流量控制。

（1）可能发生死锁

• B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd=400的报文段。
• 但这个报文段在传送过程中丢失了，A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送数据。
• 如果没有其他措施，这种互相等待的死锁局面将一直延续下去。
• 为解决这个问题，TCP为每一个连接设有一个持续计时器。

（2）持续计时器

• 只要TCP连接的一方收到对方的零窗口通知，就启动该计时器
• 若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。
• 若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。
• 若窗口不是零，则死锁的僵局就可以打破了。

5.7.2 TCP的传输效率

（1）必须考虑传输效率

可以用不同的机制来控制TCP报文段的发送时机：

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

（2）糊涂窗口综合症

• 糊涂窗口综合征：每次仅发送一个字节或很少几个字节的数据时，有效数据传输效率变得很低的现象。

A、发送方糊涂窗口综合症

• 发送方TCP每次接收到一字节的数据后就发送
• 这样，发送一个字节需要形成41字节长的IP数据报。效率很低**。使用Nagle算法。**

B、接收方糊涂窗口综合症

• 当接受方的TCP缓冲区已满，接收方会向发送方发送窗口大小为0的报文。
• 若此时接收方的应用进程以交互式方式每次只读取一个字节，于是接收方又发送窗口大小为一个字节的更新报文，发送方应邀发送一个字节的数据（发送的IP数据报是41字节长），于是接收窗口又满了，如此循环往复。

解决方法：

（3）Nagle算法

5.8 TCP的拥塞控

5.8.1 拥塞控制的一般原理

• 拥塞（congestion）：在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。
• 最坏结果：系统崩溃。

（1）拥塞产生的原因

1. 点缓存的容量太小
2. 链路的容量不足
3. 处理机处理的速率太慢
4. 拥塞本身会进一步加剧拥塞

（2）增加资源能解决拥塞吗？

• 不能。可能会使网络的性能更坏
• 网络拥塞往往是由许多因素引起的，例如：
  1. 增大缓存，但未提高输出链路的容量和处理机的速度，排队等待时间将会大大增加，引起大量超时重传，解决不了网络拥塞。
  2. 提高处理机处理的速率会将瓶颈转移到其他地方。

（3）拥塞控制与流量控制的区别

（4）拥塞控制所起的作用

（5）拥塞控制的一般原理

• 拥塞控制的前提是：网络能够承受现有的网络负荷
• 实践证明，拥塞控制是很难设计的，因为它是一个动态问题。
• 分组的丢失是网络发生拥塞的征兆而不是原因。
• 在许多情况下，甚至正是拥塞控制本身成为引起网络性能恶化、甚至发生死锁的原因。

（6）闭环控制和开环控制

A、闭环控制

1. 检测网络系统，以便检测到拥塞在何时、何处发生。、
2. 将拥塞发生的信息传送到可采取行动的地方。
3. 调整网络系统的运行以解决出现的问题。

B、检测网络的拥塞

• 主要指标有：
  1. 由于缺少缓存空间而被丢弃的分组的百分数。
  2. 平均队列长度
  3. 超时重传的分组数
  4. 平均分组时延
  5. 分组时延的标准差等
• 上述这些指标的上升都标志这拥塞的增长。

C、传递拥塞通知

• 发送通知拥塞发生的分组
• 在分组中保留表示拥塞状态的字段
• 周期性地发出探测分组

D、采取行动的时机

• 过于频繁，会使系统产生不稳定的震荡
• 过于迟缓地采取行动又不具有任何实用价值

E、解决拥塞的两条思路

• 增加网络可用资源
• 减少用户对资源的需求

5.8.2 TCP的拥塞控制方法

• TCP采用基于窗口的方法进行拥塞控制。属于闭环控制方法
• TCP发送方维持一个拥塞窗口cwnd（Congestion Window）
• 发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量。
• 发送窗口的大小不仅取决于接收方窗口，还取决于网络的拥塞状况，所以真正的发送窗口值为：

（1）控制拥塞窗口的原则

• 只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。
• 但只要网络出现拥塞或者有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现拥塞。

（2）拥塞的判断

1. 重传定时器超时：网络已经发生了拥塞。
2. 收到三个重复的ACK：预示网络可能会出现拥塞（实际可能还未发生拥塞）。

（3）TCP拥塞控制算法

1. 慢开始（slow-start）
2. 拥塞避免（congestion avoidance）
3. 快重传（fast retransmit）
4. 快恢复（fast recovery）

a、慢开始

• 目的：用来确定强罗的负载能力或拥塞程度。
• 算法的思路：由小到大逐渐增加拥塞窗口数值。
• 两个变量：

• 拥塞窗口cwnd控制方法：在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个SMSS的数值。
  

• 其中N是原先未被确认的、但现在被刚收到的确认报文段所确认的字节数。

• 不难看出，当N<SMSS时，拥塞窗口每次的增加量要小于SMSS。

• 用这样的方法逐步逐步增大发送方的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。
  

b、拥塞避免算法

• 思路：让拥塞窗口cwnd缓慢地增大，避免出现拥塞。
• 没经过一个传输轮次，拥塞窗口cwnd = cwnd+1
• 使拥塞窗口cwnd按线性规律缓慢增长。
• 在拥塞避免阶段，具有“加法增大”的特点。

当网络出现拥塞时：

• “拥塞避免”并非指完全能够避免了拥塞。
• “拥塞避免”是说在拥塞避免阶段把拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

c、快重传算法

• 发送方只要一连收到三个重复确认，就知道接收方确实没有收到报文段，因而应当立即进行重传（即“快重传），这样就不会出现超时，发送方也就不会误以为出现了网络拥塞。
• 使用快重传可以使整个网络的吞吐量提高约20%。
• 采用快重传FR（Fast Retransmission）算法可以让发送方尽早知道发生了个别报文段的丢失。
• 快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。

不难看出，快重传并非取消重传计时器，而是在某些情况下可以更早地（更快地）重传丢失的报文段。

d、快恢复算法

• 当发送端收到连续三个重复的确认时，由于发送方现在认为网络可能没有发生拥塞，因此现在不执行慢开始算法，而是执行快恢复算法FR（Fast Recovery）算法：
  

e、加法增大，乘法减小（AIMD）

（注）TCP拥塞控制流程图

（注）发送窗口的上限值

5.8.3 主动队列管理AQM

• 尾部丢弃策略：当队列已满时，以后再到达的所有分组（如果能够继续排队，这些分组都将排在队列的尾部）将都被丢弃。
• 不好之处：路由器的尾部丢弃往往会导致一连串分组的丢失，这就使发送方出现超时重传，是TCP进入拥塞控制的慢开始状态，结果使TCP连接的发送方突然把数据的发送速率降低到很小的数值。

（1）先进先出规则与尾部丢弃策略

• 全局同步：分组丢弃使发送方出现超时重传，使多个TCP连接同时进入拥塞控制的慢开始状态，发生全局同步。

（2）主动队列管理AQM

• 所谓“主动”就是不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组，而是在队列长度到达某个值得警惕的数值时（即当前网络拥塞有了某些拥塞征兆时），就主动丢弃到达的分组。
• AQM可以有不同的实现方法，其中曾流行多年的就是随机早期检测RED（Random Early Detection）
  
  

AQM实际上就是对路由器中的分组排队进行智能管理，而不是简单地把队列的尾部丢弃。

5.9 TCP的运输连接管理

5.9.1 TCP的连接建立

（1）运输连接的三个阶段

• TCP是面向连接的协议
• TCP连接有三个阶段：
  1. 连接建立
  2. 数据传送
  3. 连接释放
• TCP连接的管理就是使TCP连接的建立的释放都能正常地进行。

（2）TCP连接建立过程中要解决的三个问题

1. 要使每一方能够确知对方的存在
2. 要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）
3. 能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。

（3）客户-服务器方式

• TCP连接的建立采用客户服务器方式
• 客户：主动发起连接建立的应用进程
• 服务器：被动等待连接建立的应用进程

（4）握手

• 握手：TCP建立连接的过程
• 三报文握手：握手需要在客户和服务器之间交换三个TCP报文段。
  • 采用三报文握手主要是为了防止已失效的连接请求报文段突然又传送到了，因而产生错误。

• SYN：同步位。发送连接请求或连接请求确认时才为1，其余状态为0.
• seq序号位。刚开始发送时是随机的。
• ACK：确认位。
• ack：确认号。ack=seq（上一个报文信息的seq）+1

（5）SYN洪泛攻击

SYN洪泛攻击发生在OSI第四层，这种方式利用TCP协议的特性，就是三次握手。攻击者发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当服务器返回ACK后，该攻击者就不对其进行再确认，那这个TCP连接就处于挂起状态，也就是所谓的半连接状态，服务器收不到再确认的话，还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接，由于每一个都没法完成三次握手，所以在服务器上，这些TCP连接会因为挂起而消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务了。

5.9.2 TCP的连接释放

• 数据传输结束后，通信的双方都可以释放连接
• 四报文握手：TCP连接释放过程。

（1）A必须等待2MSL的时间

• 第一，为了保证A发送的最后一个ACK报文段能够到达B
• 第二，防止“已失效的连接请求报文段”出现在本连接中。

（2）保活计时器

• 用来防止在TCP连接出现长时期的空闲
• 保活计时器通常设置为2小时。若服务器过了2小时还没有收到客户的信息，它就发送探测报文段。若发送了10个探测报文段（每一个相隔75秒）还没有响应，就假定客户出了故障，因而就终止该连接。

5.9.3 TCP的有限状态机

• 箭头旁边的字，表明引起这种变迁的原因，或表明发生状态变迁后又出现什么动作
• 图中有三种不同的箭头
  1. 粗实线箭头表示对客户进程的正常变迁。
  2. 粗虚线箭头表示对服务器进程的正常变迁
  3. 细线箭头表示异常变迁。