《计算机网络基础》笔记 -----运输层（五）

最新推荐文章于 2023-02-05 21:06:34 发布

兰麒居士

最新推荐文章于 2023-02-05 21:06:34 发布

阅读量520

点赞数

分类专栏：计算机网络

本文链接：https://blog.csdn.net/m0_37813273/article/details/89674252

版权

计算机网络专栏收录该内容

10 篇文章 2 订阅

订阅专栏

1.运输层协议概述

进程之间的通信
- 从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最底层。
- 当网络的边缘部分中的两个主机使用网络核心部分的功能进行端到端的通信时，只有位于网络边缘的主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时只用到下三层的功能。
  - 运输层的作用
    - “逻辑通信”的意思是“好像是这样通信，但事实上并非真的这样通信”
    - 从IP层来说，通信的两端是两台主机。但“两台主机之间的通信”这个说法还不够清楚
    - 严格地讲，两台主机进行通信就是两台主机中的应用进程相互通信
    - 从运输层的角度看，通信的真正端点并不是主机而是主机中的进程。也就是端到端的通信时应用进程之间的通信。即“主机 A 的某个进程和主机 B 上的另一个进程进行通信”。简称为“计算机之间通信”。
      - 网络层和运输层作用不同
      - 基于端口复用和分用功能
      - 运输层向高层用户屏蔽了下面网络核心的细节，它使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道
  - 两种不同的运输协议
    - 但这条逻辑通信信道对上层的表现却因运输层使用的不同协议而有很大的差别
    - 当运输层采用面向连接的TCP协议时，尽管下面的网络是不可靠的（只提供最大努力服务），但这种逻辑通信信道就相当于一条全双工的可靠通信。
    - 当运输层采用无连接的UDP协议时，这种逻辑通信信道是一个不可靠信道。
运输层之间的的两个主要协议
- TCP/IP的运输层有主要的两个协议
  - 用户数据报协议UDP（User Datagram Protocol）
  - 传输控制协议TCP（Transmission Control Protocol）
- TCP与UDP
  - 两个对等运输实体在通信传送的数据单位叫做运输协议数据单元
  - TCP传送的数据单位协议是TCP报文段
  - UDP传送的数据单位协议是UDP报文或用户数据报

UDP	TCP
无连接，提供无连接服务	面向连接的协议，提供面向连接的服务
其传送的运输协议数据单元TPDU是UDP报文或用户数据报	其传送的运输协议数据单元TPDU是TCP报文
支持单播，多播，广播	支持点对点单播，不支持多播，广播
不提供可靠交付	提供可靠交付
简单。适用于很多应用，如：多媒体应用等。	复杂。用于大多数应用，如：万维网，电子邮件，文件传送等

运输层的UDP用户数据报与网际层的IP数据报是有很大区别的
- IP数据报要经过互联网中的许多路由器的存储转发
- UDP用户数据报是在运输层的端到端的逻辑信道中传送的
TCP报文段是在运输层抽象的端到端逻辑信道中传送，这种信道是可靠的全双工信道。但是这样的信道却不知道究竟经过可那些路由器，而这些路由器也根本不知道上面的运输层是否建立了TCP连接。
运输层的端口
- 运行在计算机中的进程是用进程标识符来标志的
- 但运行在应用层的各种应用进程却不应当让计算机操作系统指派的进程标识符。这是因为在互联网上使用的计算机操作系统种类很多，而不同的操作系统又使用不同格式的进程标识符
- 为了是运行不同操作的计算机的应用进程能够互相通信，就必须用统一的方法对TCP/IP体系的应用进程进行标志。
- 需要解决的问题
  - 由于进程的创建和撤销都是动态的，发送几乎无法识别其他机器上的进程
  - 有时我们会改换接收报文的进程，但并不需要通知所有发送方
  - 我们往往需要利用目的的主机提供的功能来识别终点，而不需要知道实现这个功能的进程
- 端口号
  - 解决这个问题的方法就是在运输层使用协议端口号（Protocol port number）
  - 虽然通信的终点是应用进程，但我们可以吧端口想象是通信的终点，因为我们只要把传送的报文交到目的的主机的一个某一合适的目的端口，剩下的工作（即最后的交付目的进程）就由TCP来完成。
软件端口与硬件端口
- 两个不同的概念
- 在协议栈层间的抽象的协议端口是软件端口
- 路由器或交换机的端口是硬件端口
- 硬件端口是不同的硬件设备进行交互的接口，而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。
TCP/IP运输端口
- 端口用一个16位端口号进行标志，允许有65535个不同的端口号
- 端口号只具有本地意义，即端口号只是为了标志本计算机应用层中的各进程。在互联网中，不同计算机的相同端口没有必然联系。
两大类端口
- 服务器端口使用的端口号
  - 熟知端口，数值一般为0~1023.
  - 登记端口号，数值为1024~49151，为没有熟知的端口号的应用程序使用的。使用这个范围的端口号为IANA登记，以防止重复。
客户端使用的端口号
- 又称为短暂端口号，数值为49152~65535，留给客户进程选择暂时使用
- 当服务器进程收到客户进程的报文时，就知道客户所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。
  - 常用熟知的端口

2.用户数据报协议UDP

UDP概述
- UDP只在IP的数据报服务之上增加了很少一点功能：
  - 复用和分用的功能
  - 差错检测的功能
- UDP的主要特点
  - UDP是无连接的，发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。
  - UDP使用最大努力交付机保证可靠交付，因此主机不需要维持复杂的连接状态表。
  - UDP是面向报文的。UDP对应用层交下来的报文，既不合并也不拆分，而是保留这些报文的边界。UDP一次交付一个完整报文。
  - UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的，很适合多媒体通信的要求
  - UDP支持一对一，一对多，多对一和多对多的交互通信
  - UDP的首部开销下，只有8个字节，比TCP的20个字节的首部要短。
- 面向报文的UDP
  - 接收方UDP对IP层交上来的UDP用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整报文。
  - 应用程序必须选择合适大小的报文
    - 若报文太长，UDP把它交给IP层后，IP层在传送是可能要进行分片，这会降低IP层的效率。
    - 若报文太短，UDP把它交给IP层后，会使IP数据报首部相对长度太大，这也降低了IP层的效率
UDP的首部格式
- 用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段有 8 个字节，由 4 个字段组成，每个字段都是 2 个字节。
  - UDP是基于端口分用：当运输层从IP层到UDP数据报时，就根据首部中的目的端口，把UDP数据通过相应的端口，上交给最后的终点—应用进程
    - 用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段有 8 个字节，由 4 个字段组成，每个字段都是 2 个字节。
    - 在计算检验和时，临时把 12 字节的“伪首部”和 UDP 用户数据报连接在一起。伪首部仅仅是为了计算检验和。

3.传输控制协议概述

TCP的最主要特点
- TCP是面向连接的运输层协议，在连接的不可靠的IP网络服务基础上提供可靠的服务。为此，在IP的数据报服务基础之上，增加了保证可靠性的一系列措施。
- TCP是面向连接的运输层协议
- 每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的（一对一）
- TCP提供可靠交付的服务
- TCP提供全双工通信
- 面向字节流
  - TCP中的“流”（stream）指的是流入或流出进程的字节序列
  - “面向字节流”的含义是：虽然应用程序和TCP交互是一次一个数据块，但是TCP把应用程序交下来的数据看成是一连串无结构的字节流。
  - TCP不保证接收方应用程序锁收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系
  - 但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样
- TCP 连接是一条虚连接而不是一条真正的物理连接。
- TCP 对应用进程一次把多长的报文发送到 TCP 的缓存中是不关心的。
- TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP 发送的报文长度是应用进程给出的）。
- TCP 可把太长的数据块划分短一些再传送。
- TCP 也可等待积累有足够多的字节后再构成报文段发送出去。
TCP连接
- TCP把连接作为最基本的抽象
- 每一条TCP连接有两个端点
- TCP连接的端点不是主机，不是主机的IP地址，不是应用进程，也不是运输层协议端口。TCP连接的端点叫做套接字（socket）或插口
- 端口号拼接到IP地址即构成了套接字
- TCP连接，IP连接，套接字
  - TCP连接是有协议软件所提供的一种抽象
  - TCP连接的端口是个很抽象的套接字，即（IP地址：端口）
  - 同一个IP地址可以有多个不同的TCP连接
  - 同一个端口也可以出现不同的TCP 连接中
- Socket有多种不同的意思
  - 应用编程接口API称为socket API，简称为socket
  - socket API中使用的一个函数名也叫socket
  - 调用socket的端点也叫socket
  - 调用socket函数时其返回值称为socket描述符，可简称为socket
  - 在操作系统内连网协议的Berkeley实现，称为socket实现。

4.可靠的传输原理

停止等待协议
- “停止等待”就是发送完一个分组就停止发送，发送对方的确认，在收到确认之后在发送下一个分组。
- 全双工通信的双方即是发送方也是接收方
- 为了讨论问题的方便，我们仅考虑A发送数据，而B接收数据并发送确认。因此A叫做发送方，而 B叫做接收方。
- 无差错情况
  - A 发送分组 M1，发完就暂停发送，等待 B 的确认 (ACK)。B 收到了 M1 向 A 发送 ACK。A 在收到了对 M1 的确认后，就再发送下一个分组 M2。
- 出现差错情况
  
  在接收方 B 会出现两种情况：
  1.B 接收 M1 时检测出了差错，就丢弃 M1，其他什么也不做（不通知 A 收到有差错的分组）。
  2.M1 在传输过程中丢失了，这时 B 当然什么都不知道，也什么都不做。
  - 在这两种情况下，B 都不会发送任何信息。但A都必须重发分组，直到B正确接收为止，这样才能实现可靠通信。
  A如何知道 B 是否正确收到了 M1 呢？
  - 解决方法：超时重传
    - A 为每一个已发送的分组都设置了一个超时计时器。
    - A 只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器，继续发送下一个分组 M2 。
    - 若A在超时计时器规定时间内没有收到B的确认，就认为分组错误或丢失，就重发该分组。
  若分组正确到达B，但B回送的确认丢失或延迟了，A未收到B的确认，会超时重发。B 可能会收到重复的 M1 。B如何知道收到了重复的分组，需要丢弃呢？
  - 解决方法：编号
    - A为每一个发送的分组都进行编号。若B收到了编号相同的分组，则认为收到了重复分组，丢弃重复的分组，并回送确认。
    - B为发送的确认也进行编号，指示该确认是对哪一个分组的确认。
    - A根据确认及其编号，可以确定它是对哪一个分组的确认，避免重发发送。若为重复的确认，则将其丢弃。
- 确认丢失和确认迟到
  - 确认丢失
    - 若 B 所发送的对 M1 的确认丢失了，那么 A 在设定的超时重传时间内不能收到确认，但 A 并无法知道：是自己发送的分组出错、丢失了，或者是 B 发送的确认丢失了。因此 A 在超时计时器到期后就要重传 M1。
      假定 B 又收到了重传的分组 M1。这时 B 应采取两个行动：
      - 第一，丢弃这个重复的分组 M1，不向上层交付。
      - 第二，向 A 发送确认。不能认为已经发送过确认就不再发送，因为 A 之所以重传 M1 就表示 A 没有收到对 M1 的确认。
  - 确认迟到
    - 传输过程中没有出现差错，但 B 对分组 M1 的确认迟到了。
    - A 会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃。
    - B 仍然会收到重复的 M1，并且同样要丢弃重复的 M1，并重传确认分组。
    - 在发送完一个分组后，必须暂时保留已发送的分组的副本，以备重发。
      分组和确认分组都必须进行编号。超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。
- 自动重传请求 ARQ
  - 通常 A 最终总是可以收到对所有发出的分组的确认。如果 A 不断重传分组但总是收不到确认，就说明通信线路太差，不能进行通信。
  - 使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。
  - 像上述的这种可靠传输协议常称为自动重传请求 ARQ (Automatic Repeat reQuest)。意思是重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组。
- 信道利用率
  - 可以看出，当往返时间 RTT 远大于分组发送时间 TD 时，信道的利用率就会非常低。若出现重传，则对传送有用的数据信息来说，信道的利用率就还要降低。
- 流水线传输
  - 为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输。
  - 流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地传送。
  - 由于信道上一直有数据不间断地传送，这种传输方式可获得很高的信道利用率。
- 停止等待协议要点
  - 停止等待。发送方每次只发送一个分组。在收到确认后再发送下一个分组。
  - 编号。对发送的每个分组和确认都进行编号。
  - 自动重传请求。发送方为每个发送的分组设置一个超时计时器。若超时计时器超时，发送方会自动重传分组。
  - 简单，但信道利用率太低。
连续的ARQ协议
- 基本思想
  - 发送方一次可以发出多个分组
  - 使用滑动窗口协议控制发送方和接收方所能发送额接收的分组数量和编号
  - 每收到一个确认，发送方就把发送窗口向前滑动
  - 接收方一般采用累积确认的方式
  - 采用回退N（Go-Back-N)方法进行重传。
- 累积确认
  - 接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都已经正确收到了
  - 优点：容易实现，即确认丢失也不必重传
  - 缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息
- Go-back-N(回退N)
  - 如果发送方发送了前5个分组，而中间的第三个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次
  - 这就叫Go-Back-N(回退N)，表示需要在回退回来重传已发送过的N个分组
  - 可见当通信线路质量不好时，连续的ARQ协议会带来负面的影响
- TCP可靠通信的具体实现
  - TCP连接的每一端都必须设有两个窗口：一个发送窗口和一个接收窗口
  - TCP的可靠传输的机制用字节的序号进行控制。TCP所有的确认都是基于序号而不是基于报文段
  - TCP两端的四个窗口经常处于动态变化之中
  - TCP连接的往返时间RTT也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。
- 连续ARQ协议与停止等待协议

	连续ARQ协议	停止等待协议
发送的分组数量	一次发送多个分组	一次发送一个分组
传输控制	滑动窗口协议	停止-等待
确认	单独确认+ 累积确认	单独确认
超时定时器	每个发送的分组	每个发送的分组
编号	每个发送的分组	每个发送的分组
重传	回退N，多个分组	一个分组

滑动窗口协议

5.TCP报文的首部格式

TCP虽然是面向字节流的，但是TCP传送的数据单元确是报文段
一个TCP报文段分为首部和数据两部分，而TCP的全部功能都是体现在首部中的各字段的作用中

TCP报文首部的前20个字段是固定搞的，后面有4n字节是根据需要而增加的选项（n是整数）。因此TCP首部的最小长度是20字节。
TCP首部格式

TCP首部各字段的含义

源端口和目的端口字段

  各占 2 字节。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。

序号字段

 占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。
 序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。
 现有5000个字节的数据。
假设报文段的最大数据长度为1000个字节，初始序号为1001。
报文段 1 序号 = 1001 （数据字节序号：1001 ~ 2000）
报文段 2 序号 = 2001 （数据字节序号：2001 ~ 3000）
报文段 3 序号 = 3001 （数据字节序号：3001 ~ 4000）
报文段 4 序号 = 4001 （数据字节序号：4001 ~ 5000）
报文段 5 序号 = 5001 （数据字节序号：5001 ~ 6000）

确认号字段

占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。

数据偏移（即首部长度）

占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位是 32 位字（以 4 字节为计算单位）。

保留字段

占 6 位，保留为今后使用，但目前应置为 0

紧急 URG

当 URG 为 1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)。

确认 ACK

只有当 ACK =1 时确认号字段才有效。当 ACK =0 时，确认号无效。

推送 PSH (PuSH)

接收 TCP 收到 PSH = 1 的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。

复位 RST (ReSeT)

当 RST=1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。

同步 SYN

同步 SYN = 1 表示这是一个连接请求或连接接受报文。

终止 FIN (FINish)

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

窗口字段

占 2 字节，用来让对方设置发送窗口的依据，单位为字节。

检验和

占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。

TCP伪首部

紧急指针字段

占 16 位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。

选项字段
```
长度可变。TCP 最初只规定了一种选项，即最大报文段长度 MSS。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”

MSS (Maximum Segment Size)
是 TCP 报文段中的数据字段的最大长度。
数据字段加上 TCP 首部才等于整个的 TCP 报文段。
所以，MSS是“TCP 报文段长度减去 TCP 首部长度”
```
为什么要规定 MSS ？
♣ MSS 与接收窗口值没有关系。
♣ 若选择较小的 MSS 长度，网络的利用率就降低。
♣ 若 TCP 报文段非常长，那么在 IP 层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的 TCP 报文段。当传输出错时还要进行重传。这些也都会使开销增大。
♣ 因此，MSS 应尽可能大些，只要在 IP 层传输时不需要再分片就行。
♣ 但最佳的 MSS 是很难确定的。

其他选项

窗口扩大选项 ——占 3 字节，其中有一个字节表示移位值 S。新的窗口值等于 TCP 首部中的窗口位数增大到 (16 + S)，相当于把窗口值向左移动 S 位后获得实际的窗口大小。
时间戳选项——占 10 字节，其中最主要的字段时间戳值字段（4 字节）和时间戳回送回答字段（4 字节）。
选择确认选项——在后面的介绍

填充字段

 这是为了使整个首部长度是 4 字节的整数倍。

6. TCP可靠传输的实现

以字节为单位的滑动窗口
- TCP使用流水线传输和滑动窗口协议实现高效，可靠的传输
- TCP的滑动窗口是以字节为单位的
- 发送方A和接收方B分别维持一个发送窗口和一个接收窗口
- 发送窗口表示：在没有收到确认的情况下，可以连续把窗口内的数据全部发送出去
- 接收窗口表示：只允许接收落入窗口内的数据
  - 根据 B 给出的窗口值，A 构造出自己的发送窗口。
  - 发送窗口表示：在没有收到 B 的确认的情况下，A 可以连续把窗口内的数据都发送出去。
  - 发送窗口里面的序号表示允许发送的序号。
  - 显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。
- TCP滑动窗口传输原理过程
  - 发送缓存
    - 发送缓存用来暂时存放：
      - 发送应用程序传送给发送方 TCP 准备发送的数据；
      - TCP 已发送出但尚未收到确认的数据。
  - 接收缓存
  - 接收缓存用来暂时存放：
    - 按序到达的、但尚未被接收应用程序读取的数据；
    - 不按序到达的数据。
  需要强调三点
  第一，A 的发送窗口并不总是和 B 的接收窗口一样大（因为有一定的时间滞后）。
  第二，TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
  第三，TCP 要求接收方必须有累积确认的功能，这样可以减小传输开销。
- 接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。
  但请注意两点：
  - 第一，接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，这反而浪费了网络的资源。。
  - 第二，捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。
超时重传时间的选择
- 重传机制是 TCP 中最重要和最复杂的问题之一。
- TCP 每发送一个报文段，就对这个报文段设置一次计时器。
- 只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。
- 重传时间的选择是 TCP 最复杂的问题之一。
- 往返时延的方差很大
  - TCP 超时重传时间设置
    - 如果把超时重传时间设置得太短，就会引起很多报文段的不必要的重传，使网络负荷增大。
    - 但若把超时重传时间设置得过长，则又使网络的空闲时间增大，降低了传输效率。
    - TCP 采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间 RTT。
  - 加权平均往返时间
    - TCP保留了RTT的一个加权平均往返时间RTTS（这又称为平滑的往返时间）。
      第一次测量到 RTT 样本时，RTTS 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTTS：
    式中，若 $\alpha$ 很接近于零，表示 RTT 值更新较慢。若选择 $\alpha$ 接近于 1，则表示 RTT 值更新较快。
    
    RFC 6298 推荐的 $\alpha$ 值为 1/8，即 0.125。
  - 超时重传时间 RTO
  - 往返时间 (RTT) 的测量相当复杂
    
    TCP 报文段 1 没有收到确认。重传（即报文段 2）后，收到了确认报文段 ACK。
    如何判定此确认报文段是对原来的报文段 1 的确认，还是对重传的报文段 2 的确认？
  - Karn 算法
    - 在计算平均往返时间 RTT 时，只要报文段重传了，就不采用其往返时间样本。
    - 这样得出的加权平均平均往返时间 RTTS 和超时重传时间 RTO 就较准确。
    - 但是，这又引起新的问题。当报文段的时延突然增大了很多时，在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据 Karn 算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。
  - 修正的 Karn 算法
    - 报文段每重传一次，就把 RTO 增大一些：
      
      新的 RTO = $\gamma$ $\times$ (旧的 RTO)
      - 系数 $\gamma$ 的典型值是 2 。
      - 当不再发生报文段的重传时，才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数值。
      - 实践证明，这种策略较为合理。
选择确认SACK

若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？
“答案是可以的。选择确认 SACK (Selective ACK) 就是一种可行的处理方法。”
- 如果要使用选择确认，那么在建立 TCP 连接时，就要在 TCP 首部的选项中加上“允许 SACK”的选项，而双方必须都事先商定好。
- 如果使用选择确认，那么原来首部中的“确认号字段”的用法仍然不变。只是以后在 TCP 报文段的首部中都增加了 SACK 选项，以便报告收到的不连续的字节块的边界。
- 由于首部选项的长度最多只有 40 字节，而指明一个边界就要用掉 4 字节，因此在选项中最多只能指明 4 个字节块的边界信息。

7.TCP的流量控制

利用滑动窗口实现流量控制
- 一般说来，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失
- 流量控制 (flow control) 就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。
- 利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制。
  - 利用可变窗口进行流量控制举例
    - 可能发生死锁
      - B 向 A 发送了零窗口的报文段后不久，B 的接收缓存又有了一些存储空间。于是 B 向 A 发送了 rwnd = 400 的报文段。
      - 但这个报文段在传送过程中丢失了。A 一直等待收到 B 发送的非零窗口的通知，而 B 也一直等待 A 发送的数据。
      - 如果没有其他措施，这种互相等待的死锁局面将一直延续下去。
      - 为了解决这个问题，TCP 为每一个连接设有一个持续计时器 (persistence timer)。
    - 持续计时器
      - 为了解决这个问题， TCP 为每一个连接设有一个持续计时器 (persistence timer) 。
      - 只要 TCP 连接的一方收到对方的零窗口通知，就启动该持续计时器。
      - 若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带 1 字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。
      - 若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。
      - 若窗口不是零，则死锁的僵局就可以打破了。
TCP 的传输效率
- 必须考虑传输效率
  - 可以用不同的机制来控制 TCP 报文段的发送时机:
    - 第一种机制是 TCP 维持一个变量，它等于最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP 报文段发送出去。
    - 第二种机制是由发送方的应用进程指明要求发送报文段，即 TCP 支持的推送 (push) 操作。
    - 第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过 MSS）发送出去。
  如何控制TCP发送报文段的时机仍然是一个较为复杂的问题。
- 糊涂窗口综合症
  - 每次仅发送一个字节或很少几个字节的数据时，有效数据传输效率变得很低的想象。
- 发送方的糊涂综合症
  - 发送方TCP每次接收到一字节的数据就发送
  - 这样一个字节需要形成41字节长的IP数据报。效率很低
  - 解决方法：使用Nagle算法
- Nagle算法
  - 若发送应用进程把发送的数据逐个字节地送到TCP的发送的缓存，则发送方就把第一个数据字节先发送出去，把后面的数据字节都缓存起来
  - 当发送方接收到对第一个数据字符的确认后，再把发送缓存中的所有数据装成一个报文发送出去，同时继续对随后到达的数据进行缓存
  - 只有在收到对前一个报文段的确认后才继续发送下一个报文段。
  - 当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。
- 接收方糊涂窗口综合症
  - 当接收方的TCP缓存区已满，接收方会发送方发送窗口大小为0的报文。
  - 若此时接收方的应用进程以交互方式每次只读取一个字节，于是接收方又发送窗口大小为一个字节的更新报文，发送方应邀发送一个字节的数据（发送的IP数据报是41字节长），于是接收窗口又满了，如此循环往复。
解决方法：让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发出确认报文，并且向发送方通知当前的窗口大小。

8.TCP的拥塞控制

拥塞控制的一般原理

在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种现象称为拥塞（congestion）
最坏结果：系统奔溃
- 网络拥塞往往是由许多因素引起的。例如：
  - 1.点缓存的容量太小
  - 2.链路容量不足
  - 3.处理机处理的速率太慢
  - 4.拥塞本身会进一步加剧拥塞
- 出现拥塞的原因：
  - 对资源需求 > 可用资源
增加资源能解决拥塞吗？
- 不能。这是因为网络拥塞是一个非常复杂的问题。简单地采用上述做法，在许多情况下，不但不能解决拥塞问题，而且还可能是网络的性能更坏。
- 网络拥塞往往是由许多因素引起的。例如：
  - 1.增大缓存，但未提高输出链路的容量和处理机的速度，排队等待时间将会大大增加，引起大量超时重传，解决不了网络拥塞；
  - 2.提高处理机处理速率会将瓶颈转移到其他地方
- 拥塞控制与流量控制的区别

拥塞控制	流量控制
防止过多的数据注入到网络中，使网络中路由器或链路不致过载	抑制发送端发送数据的速率以使接收端来得及接收
是一个全局性的过程，涉及到与降低网络传输性能有关的所有因素	是点到点通信量的控制，是端到端的问题

拥塞控制所起的作用
拥塞控制的前提：网络能够承受现有的网络负荷
实践证明，拥塞控制是很难设计的，因为是一个动态问题
分组的丢失是网络发生拥塞的征兆而不是原因
在许多情况下，甚至是拥塞控制本身成为引起网络性能恶化，甚至发生死锁的原因。
开环控制与闭环控制
- 开环控制：在设计网络时，事先考虑周全，力求工作时不发生拥塞；（思路：力争避免发生拥塞）
- 闭环控制：基于反馈环路的概念；根据网络当前的运行状态采取相应的措施；（思路：在发生拥塞后，采取措施进行控制，消除拥塞）
- 闭环控制有以下几种措施：
  - 1）监测网络系统，以便检测到拥塞在何时，何处发生
    - 主要指标有：
      - 由于缺少缓存空间而被丢弃的分组的百分数
      - 平均队列长度
      - 超时重传的分组数
      - 平均分组时延
      - 分组时延的标准差
      上述这些指标的上升都标志着拥塞的增长
  - 2）将拥塞发生的信息传送到可采取行动的地方
    - 发送通知拥塞发生的分组
    - 在分组中保留表示拥塞状态的字段
    - 周期性地发出探测分组等
  - 3）调整网络系统的运行解决出现的问题。
    - 过于频繁，会使系统产生不稳定的震荡
    - 过于迟缓地采取行动又不具有任何的实用价值
- 解决拥塞的两条思路
  - 增加网络的可用资源
  - 减少用户对资源的需求

TCP的拥塞控制方法
- TCP采用基于窗口的方法进行拥塞控制。该方法属于闭环控制方法
- TCP发送方维持一个拥塞窗口cwnd（Congestion Window）
- 发送端利用拥塞窗口根据网路的拥塞情况调整发送的数据量
- 发送窗口大小不仅取决于接收窗口，还却决于网络的拥塞状况，所以真正的发送窗口值：Min（接收方窗口值，拥塞窗口值）
- 控制拥塞窗口的原则
  - 只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。
  - 但只要网络出现拥塞或可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞。
  - 拥塞的判断
    - 重传定时器超时：网络已经发生了拥塞
    - 收到三个重复的ACK：预示网络可能会出现拥塞（实际可能还为发生拥塞）
    - TCP拥塞控制算法：
      - 慢开始（slow-start）
      - 拥塞避免（congestion avoidance）
      - 快重传（fast retransmit）
      - 快恢复(fast recovery）
    - 慢开始（Slow start）
      - 目的：用来确定网络的负载能力或拥塞程度
      - 算法的思路：由小到大逐渐拥塞窗口数值
      - 两个变量：
        拥塞窗口
        初始拥塞窗口值：2种设置方法
        1至2个最大报文段（旧标准）
        2至4个最大报文段（RFC 5681）
        
        窗口值逐渐增大
        
        慢开始门限
        防止拥塞窗口增长过大引起网络拥塞
      - 拥塞窗口 cwnd 控制方法：在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个 SMSS 的数值。
        
        拥塞窗口 cwnd 每次的增加量 = min (N, SMSS)
        其中N是原来未被确认的，但现在被刚收到的确认报文段所确认的字节数
        不难看出，当N < SMSS 时，拥塞窗口每次的增加量要小于SMSS
        用这样的方法逐步增大发送方的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。
      - 传输轮次
        
        使用慢开始算法后，每经过一个传输轮次（transmission round），拥塞窗口cwnd就加倍
        一个传输轮次所经历的时间其实就是往返时间RTT
        “传输轮次”更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。
        例如，拥塞窗口cwnd = 4 ，这时的往返时间RTT就是发送方连续发送4个报文段，并收到这个4个报文段的确认，总共经历时间。
      - 设置慢开始门限状态变量ssthresh
        
        慢开始门限ssthresh的用法如下：
        1.当cwnd < ssthresh 时，使用慢开始算法
        2.cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法
        当cwnd == ssthresh 时，既可以使用慢开始算法，也可使用拥塞避免算法
      - 拥塞避免算法
        
        思路：让拥塞窗口cwnd 缓慢增大，避免出现拥塞
        
        每经过一个传输轮次，拥塞窗口cwnd = cwnd + 1
        
        使拥塞窗口cwnd 按线性规律缓慢增长
        
        在拥塞避免阶段，具有“加法增大（Additive Increase）”的特点
        
        当网络出现拥塞时
        
        无论在慢开始阶段还是拥塞避免阶段，只要发送方判断网络出现拥塞（重传定时器超时）：
        ssthresh = max（cwnd/2 , 2）
        cwnd = 1
        执行慢开始算法
        
        目的：迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够的时间把队列中积压的分组处理完毕
        
        举例
    - 快重传算法
      - 采用快重传FR（Fast Retransmission）算法可以发送方尽早知道发生了个别报文段的丢失
      - 快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
      - 举例
    - 快恢复算法
      - 当发送端收到连续三个重复的确认时，由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算，而是执行快恢复算法FR（Fast Recovery）算法：
        慢开始门限ssthresh = 当前拥塞窗口cwnd / 2;
        新拥塞窗口cwnd = 慢开始门限ssthresh；
        开始执行拥塞避免窗口缓慢地线性增大
      - 加法增大，乘法减小（AIMD）
        可以看出，在拥塞避免阶段，拥塞窗口是按照线性规律增大的。这常称为“加法增大” AI（Additive Increase）
        当出现超时或3个重复的确认时，就要把门限设置为当前拥塞窗口的一半，并大大减少拥塞窗口的数值。这常称为“乘法减少”MD（Multiplicative Decrease）
        二者在一起就是所谓的AIMD算法
        
        发送窗口的上限
        发送方的发送窗口的上限值应当取为接收方窗口rwnd和拥塞窗口cwnd这两个变量中较小的一个，即应按以下公司确定：
        
        发送窗口的上限值 = Min [rwnd, cwnd] 当 rwnd < cwnd 时，是接收方的接收能力限制发送窗口的最大值。当 cwnd < rwnd 时，则是网络的拥塞限制发送窗口的最大值。
主动队列管理AQM
- TCP拥塞控制和网络层采取的策略有密切联系
- 若路由器对某些分组的处理时间特别长，那么这就可能使这些分组中的TCP报文段经过很长时间才能到达终点，结果引起发送方超时，对这些报文段进行重传
- 重传会使TCP连接的发送端认为在网络中发生了拥塞，但实际上网络并没有发生拥塞
- 对TCP拥塞控制影响最大的就是路由器的分组丢弃策略
- “先进先出”FIFO处理规则
  - 路由器的队列通常就是按照“先进先出”FIFO（First in First Out）的规则处理到来的分组
  - 当队列已满时，以后再到达的所有分组（如果能够继续排队，这些分组都将排在队列尾部）将都被丢弃。这就叫做尾部丢弃策略（tail-drop policy）
  - 路由器的尾部丢弃往往会导致一连串分组的丢失，这就使发送方出现超时重传，使TCP加入拥塞控制的慢开始状态，结果使用TCP连接的发送方突然把数据的发送速率降低到很小的数值。
  - 全局同步
    - 更为严重的是，在网络中通常有很多的TCP连接，这些连接中的报文段通常是复用在网络层的IP数据报中传送的。
    - 在这种情况下，若发生了路由器中的尾部丢弃，就可能同时影响到很多条TCP连接，结果使许多TCP连接在同一时间突然都进入慢开始状态。这在TCP的术语中称为全局同步（global syncronization）
    - 全局同步使得全网的通信量突然下降了很多，而在网络恢复正常后，通信量有突然增大很多
- 主动队列管理AQM
  - 1998年提出了主动队列管理AQM（Active Queue Managerment）
  - 所谓“主动”就是不要等到路由器的队列长度达到最大值时才不得不丢弃后面到达的分组，而是在队列长度达到某个值警惕的数值时（即当网络拥塞有了某些拥塞征兆时），就主动丢弃的分组
  - AQM可以有不同的实现方法，其中曾流行多年的随机早期检测RED（Random Early Detection）
- 随机早期检测RED
  - 使路由器的队列维持两个参数：队列长度最小门限 THmin 和最大门限 Thmax 。
  - RED 对每一个到达的分组都先计算平均队列长度 LAV 。
    - 若平均队列长度小于最小门限 THmin，则将新到达的分组放入队列进行排队。
    - 若平均队列长度超过最大门限 Thmax ，则将新到达的分组丢弃。
    - 若平均队列长度在最小门限 THmin 和最大门限 Thmax 之间，则按照某一概率 p 将新到达的分组丢弃。
      - 当 LAV < Thmin 时，丢弃概率 p = 0。
      - 当 LAV > Thmax 时，丢弃概率 p = 1。
      - 当 Thmin < LAV < Thmax时， 0 < p < 1 。
    - 多年的实践证明，RED 的使用效果并不太理想。
    - 2015 年公布的 RFC 7567 已经把 RFC 2309 列为“陈旧的”，并且不再推荐使用 RED。
    - 对路由器进行主动队列管理 AQM 仍是必要的。
    - AQM 实际上就是对路由器中的分组排队进行智能管理，而不是简单地把队列的尾部丢弃。
    - 现在已经有几种不同的算法来代替旧的 RED，但都还在实验阶段。

9.TCP运输的连接管理

 TCP是面向连接的协议
 TCP连接有三个阶段：
 	1.连接建立
 	2.数据传送
 	3.连接释放
 TCP连接管理就是使得TCP的连接和释放都能正常的进行
 TCP要解决的三个问题
 		1.要使每一方都能确认对方的存在
 		2.要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）
 		3.能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。

TCP连接建立
- TCP 建立连接的过程叫做握手
- 握手需要在客户和服务器之间交换三个 TCP 报文段。称之为三报文握手。
- 采用三报文握手主要是为了防止已失效的连接请求报文段突然又传送到了，因而产生错误
TCP连接释放
- TCP 连接释放过程比较复杂
- 数据传输结束后，通信的双方都可释放连接。
- TCP 连接释放过程是四报文握手。
  - A 必须等待 2MSL 的时间
    - 第一，为了保证 A 发送的最后一个 ACK 报文段能够到达 B。
    - 第二，防止 “已失效的连接请求报文段”出现在本连接中。
  - 保活计时器
    - 用来防止在TCP连接出现长时期的空闲。
    - 保活计时器通常设置为2小时。若服务器过了2小时还没有收到客户的信息，它就发送探测报文段。若发送了10个探测报文段（每一个相隔75秒）还没有响应，就假定客户出了故障，因而就终止该连接。
TCP的有限状态机
- 箭头旁边的字，表明引起这种变迁的原因，或表明发生状态变迁后又出现什么动作。
  图中有三种不同的箭头。
- 粗实线箭头表示对客户进程的正常变迁。
- 粗虚线箭头表示对服务器进程的正常变迁。
- 细线箭头表示异常变迁。