计算机网络系列学习（四）传输层

计算机网络系列学习（一）概述
计算机网络系列学习（二）数据链路层
计算机网络系列学习（三） 网络层
计算机网络系列学习（四）运输层
计算机网络系列学习（五）应用层

第四章：运输层

一、运输层协议概述

1. 进程之间的通信

1. 运输层的作用

   为应用层进程之间的通信提供服务

2. 屏蔽作用

   运输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑、所采用的路由选择协议等），使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道

3. 可靠信道与不可靠信道

   • 全双工可靠信道：面向连接的协议，TCP
   • 不可靠信道：无连接的协议，UDP

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

用户数据报协议 UDP (User Datagram Protocol)

传输控制协议 TCP (Transmission Control Protocol)

两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元 TPDU (Transport Protocol Data Unit)。

TCP：传送的数据单位协议是TCP报文段

UDP：传送的数据单位协议是UDP报文或用户数据报

1. UDP与TCP的区别

   

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

   

3. 运输层的端口

复用：应用进程都可以通过运输层再传送到 IP 层（网络层）

分用：运输层从 IP 层收到发送给应用进程的数据后，必须分别交付给指明的各应用进程

1. 端口号：在运输层使用协议端口号 (protocol port number)，或通常简称为端口 (port)。把端口设为通信的抽象终点

   

2. 软件端口与硬件端口

   • 软件端口

     协议栈层间的抽象的协议端口。

     是应用层的各种协议进程与运输实体进行层间交互的地点。

     不同系统实现端口的方法可以不同

   • 硬件端口

     不同硬件设备进行交互的接口

3. TCP/IP运输层端口的标志

   • 端口用一个 16 位端口号进行标志，允许有 65,535 个不同的端口号。

   • 端口号只具有本地意义，只是为了标志本计算机应用层中的各进程。

   • 在互联网中，不同计算机的相同端口号没有联系

   由此可见，两个计算机中的进程要互相通信，不仅必须知道对方的端口号，而且还要知道对方的 IP 地址

4. 两大类、三种类型的端口

   

二、用户数据报协议UDP

1. UDP概述

1. 特点：简单方便，但不可靠

   • 无连接。发送数据之前不需要建立连接。
   • 使用尽最大努力交付。即不保证可靠交付。
   • 面向报文。UDP 一次传送和交付一个完整的报文。
   • 没有拥塞控制。网络出现的拥塞不会使源主机的发送速率降低。
   • 很适合多媒体通信的要求。
   • 支持一对一、一对多、多对一、多对多等交互通信。首部开销小，只有 8 个字节

2. UDP是面向报文的

   发送方 UDP 对应用层交下来的报文，既不合并，也不拆分，按照样发送。

   接收方 UDP 对 IP 层交上来的 UDP 用户数据报，去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文

   应用程序必须选择合适大小的报文

   • 若报文太长，IP 层在传送时可能要进行分片，降低 IP 层的效率
   • 若报文太短，会使 IP 数据报的首部的相对长度太大，降低 IP 层的效率

3. UDP通信和端口号的关系

   复用：将 UDP 用户数据报组装成不同的 IP 数据报，发送到互联网。

   分用：根据 UDP 用户数据报首部中的目的端口号，将数据报分别传送到相应的端口，以便应用进程到端口读取数据

   

   

2. UDP的首部概述

• 源端口：源端口号。在需要对方回信时选用。不需要时可用全 0
• 目的端口：目的端口号。终点交付报文时必须使用
• 长度：UDP 用户数据报的长度，其最小值是 8（仅有首部）
• 检验和：检测 UDP 用户数据报在传输中是否有错。有错就丢弃

1. UDP基于端口的分用

   

   • 接收方 UDP 根据首部中的目的端口号，把报文通过相应的端口上交给应用进程。
   • 如果接收方 UDP 发现收到的报文中的目的端口号不正确（即不存在对应于该端口号的应用进程），就丢弃该报文，并由 ICMP 发送“端口不可达”差错报文给发送方

2. UDP检验和

   在计算检验和时，临时把 12 字节的“伪首部”和 UDP 用户数据报连接在一起。伪首部仅仅是为了计算检验和

   

   UDP 的检验和是把首部和数据部分一起都检验

三、传输控制协议TCP概述

1. TCP最主要的特点

TCP 是面向连接的运输层协议，在无连接的、不可靠的 IP 网络服务基础之上提供可靠交付的服务

1. 特点

   • TCP 是面向连接的运输层协议。

   • 每一条 TCP 连接只能有两个端点 (endpoint)，每一条 TCP 连接只能是点对点的（一对一）。

   • TCP 提供可靠交付的服务。

   • TCP 提供全双工通信。

   • 面向字节流

     TCP 中的“流”(stream) 指的是流入或流出进程的字节序列。

     面向字节流：虽然应用程序和 TCP 的交互是一次一个数据块，但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流

2. TCP面向流的概念

   TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系。

   但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样

   

   TCP 不关心应用进程一次把多长的报文发送到 TCP 缓存。

   TCP 根据对方给出的窗口值和当前网络拥塞程度来决定一个报文段应包含多少个字节，形成 TCP 报文段

2. TCP的连接

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

TCP 连接的端点：套接字 (socket) 或插口

1. 套接字 socket = (IP地址 : 端口号)

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

2. TCP连接，IP地址，套接字

   • TCP 连接就是由协议软件所提供的一种抽象。

   • TCP 连接的端点是抽象的套接字，即（IP 地址：端口号）。

   • 同一个 IP 地址可以有多个不同的 TCP 连接。

   • 同一个端口号也可以出现在多个不同的 TCP 连接中

四、可靠传输的工作原理

1. 停止等待协议

每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

1. 无差错情况

   

2. 出现差错

   • B 接收 M1 时检测出了差错，就丢弃 M1，其他什么也不做（不通知 A 收到有差错的分组）。
   • M1 在传输过程中丢失了，这时 B 当然什么都不知道，也什么都不做。

   发送方如何知道出现差错：超时重传

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

3. 确认丢失和确认迟到

   • 确认丢失

     若 B 所发送的对 M1 的确认丢失了，那么 A 在设定的超时重传时间内将不会收到确认，因此 A 在超时计时器到期后重传 M1。假定 B 正确收到了 A 重传的分组 M1。

     这时 B 应采取两个行动：(1) 丢弃这个重复的分组 M1，不向上层交付。(2) 向 A 发送确认

   • 确认迟到

     B 对分组 M1 的确认迟到了，因此 A 在超时计时器到期后重传 M1。

     B 会收到重复的 M1，丢弃重复的 M1，并重传确认分组。

     A 会收到重复的确认。对重复的确认的处理：丢弃

4. 信道利用率

   

5. 要点

   • 暂存：在发送完一个分组后，发送方必须暂存已发送的分组的副本，以备重发。
   • 编号：对发送的每个分组和确认都进行编号
   • 简单：但信道利用率太低。

2. 连续ARQ协议

发送窗口：发送方维持一个发送窗口，位于发送窗口内的分组都可被连续发送出去，而不需要等待对方的确认。

发送窗口滑动：发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

累积确认：接收方对按序到达的最后一个分组发送确认，表示：到这个分组为止的所有分组都已正确收到了

1. 发送窗口

   

2. 累计确认

   

   缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息

   连续 ARQ 协议采用 Go-back-N（回退N）。

   Go-back-N（回退N）：表示需要再退回来重传已发送过的 N 个分组。当通信线路质量不好时，连续 ARQ 协议会带来负面的影响

五、TCP报文段的首部格式

TCP 虽然是面向字节流的，但 TCP 传送的数据单元却是报文段。

一个 TCP 报文段分为首部和数据两部分，而 TCP 的全部功能都体现在它首部中各字段的作用。

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

• 序号：占 4 字节。TCP 连接中传送的数据流中的每一个字节都有一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号

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

• 数据偏移（即首部长度）：占 4 位，指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。单位是 32 位字（以 4 字节为计算单位）

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

• 确认 ACK：控制位。只有当 ACK =1 时，确认号字段才有效。当 ACK =0 时，确认号无效

• 推送 PSH (PuSH) ：控制位。接收 TCP 收到 PSH = 1 的报文段后，就尽快（即“推送”向前）交付接收应用进程，而不再等到整个缓存都填满后再交付

• 复位 RST (ReSeT) ：控制位。当 RST=1 时，表明 TCP 连接中出现严重差错（如主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接

• 同步 SYN (SYNchronization) ：控制位。同步 SYN = 1 表示这是一个连接请求或连接接受报文。

  当 SYN = 1，ACK = 0 时，表明这是一个连接请求报文段。当 SYN = 1，ACK = 1 时，表明这是一个连接接受报文段

• 终止 FIN (FINish) ：控制位。用来释放一个连接。FIN=1 表明此报文段的发送端的数据已发送完毕，并要求释放运输连接

• 窗口：占 2 字节。窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量（以字节为单位）

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

• 紧急指针：占 2 字节。在 URG = 1时，指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据）

• 选项：长度可变，最长可达 40 字节。

  • 最大报文段长度 MSS选项：是 TCP 报文段中的数据字段的最大长度

  

  • 窗口扩大选项：占 3 字节，其中一个字节表示移位值 S。新的窗口值位数从 16 增大到 (16 + S)，相当于

    窗口值向左移动 S 位。移位值允许使用的最大值是 14。

    窗口扩大选项可以在双方初始建立 TCP 连接时进行协商

  • 时间戳：占 10 字节。最主要的 2 个字段：时间戳值字段（4字节）和时间戳回送回答字段（4字节）。

    2 个主要功能：计算往返时间 RTT和防止序号绕回 PAWS (Protect Against Wrapped Sequence numbers)：序号重复时，为了使接收方能够把新报文段和迟到很久的旧报文段区分开，可以在报文段中加上时间戳

• 填充：使整个 TCP 首部长度是 4 字节的整数倍。

六、TCP可靠传输的实现

1. 以字节为单位的滑动窗口

1. 发送窗口

   

   

   • p3-p1:发送窗口

   • p2-p1:已发送但尚未收到确认的字节数

   • p3-p2:允许发送但还未发送的字节数，也称为可用窗口

     

     接受方收到了序号为 32 和 33 的数据，但未收到序号为 31 的数据。因此，因此发送的确认报文段中的确认号是 31（即期望收到的序号）

     此时A将再次发送序号31数据

     B收到后修改确认号，并将31~33数据上交给主机，新的确认号发送给A,A根据确认号移动窗口

     ---

     A未收到确认的原因有：① B 未发送；② B已发送，但还未到达 A

     为保证可靠传输，A 只能认为 B 还没有收到这些数据。A 经过一段时间后（由超时计时器控制）就重传这部分数据，重新设置超时计时器，直到收到 B 的确认为止

2. 发送缓存与发送窗口

   

   • 发送缓存：缓存中的字节数=发送应用程序最后写入缓存的字节数-最后被确认的字节

     发送窗口通常只是发送缓存的一部分

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

3. 接收缓存与接受窗口

   

   若不能及时读取，缓存最终会被填满，使接收窗口减小到零。

   如果能够及时读取，接收窗口就可以增大，但最大不能超过接收缓存的大小

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

4. 特别注意三点

   • 发送窗口是根据接收窗口设置的，但在同一时刻，发送窗口并不总是和接收窗口一样大（因为有一定的时间滞后）
   • TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程
   • TCP 要求接收方必须有累积确认的功能，以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。但接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，捎带确认实际上并不经常发生

2. 超时重传时间段选择

TCP 采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应确认的时间。这两个时间之差就是报文段的往返时间 RTT

1. 加权平均往返时间RTT_S

   

   若 α→0，表示 RTT 值更新较慢。若 α→1，表示 RTT 值更新较快。RFC 6298 推荐的  值为 1/8，即 0.125

2. 超时重传时间RTO

   RTO (Retransmission Time-Out) 应略大于加权平均往返时间 RTT_S

   • RFC 6298 建议 RTO

     

     RTT_D 是 RTT 偏差的加权平均值

   • RFC 6298 建议 RTTD

     

     β是个小于 1 的系数，其推荐值是 1/4

3. RTT的测量

   • Karn算法：在计算平均往返时间 RTT 时，只要报文段重传了，就不采用其往返时间样本

     超时重传时间就无法更新，造成很多不必要的重传

   • 修正的Karn算法：报文段每重传一次，就把 RTO 增大一些

   

   ​ γ的典型值=2

   ​ 当不再发生报文段的重传时，才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数 值

3. 选择确认SACK

设法只传送缺少的数据而不重传已经正确到达接收方的数据

• 在建立 TCP 连接时，要在 TCP 首部的选项中加上允许 SACK 选项，且双方必须事先商定好
• 原来首部中的确认号的用法仍然不变（累积确认）。只是在 TCP 首部中都增加了 SACK 选项，以便报告收到的不连续的字节块的边界

左边界 = 第一个字节的序号，右边界 = 最后一个字节序号 + 1

七、TCP的流量控制

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

1. 流量控制 (flow control) ：让发送方的发送速率不要太快，使接收方来得及接收

   通过接收方告诉发送方接收窗口大小来实现流量控制

2. 持续计时器：只要 TCP 连接的一方收到对方的零窗口通知，就启动该持续计时器

   若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带 1 字节的数据），对方在确认这个探测报文段时给出当前窗口值。

   若窗口仍然是零，收到这个报文段的一方就重新设置持续计时器。

   若窗口不是零，则死锁的僵局就可以打破了

2. TCP的传输效率

控制TCP发送报文段的时机：三种机制

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

1. 糊涂窗口综合症

   每次仅发送一个字节或很少几个字节的数据时，有效数据传输效率变得很低的现象

2. Nagle算法

   

3. 接收方糊涂窗口综合症

   接收方应用进程消耗数据太慢，例如：每次只读取一个字节

   

   解决：让接收方等待一段时间，使得接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小

八、TCP的拥塞控制

1. 拥塞控制的一般原理

拥塞：在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降

---

增加资源能解决缓存吗

增大缓存，但未提高输出链路的容量和处理机的速度，排队等待时间将会大大增加，引起大量超时重传，解决不了网络拥塞；提高处理机处理的速率会将瓶颈转移到其他地方；拥塞引起的重传并不会缓解网络的拥塞，反而会加剧网络的拥塞

---

1. 拥塞控制与流量控制的区别

   

2. 拥塞控制的一般原理

   拥塞控制的前提：网络能够承受现有的网络负荷

   分组的丢失是网络发生拥塞的征兆，而不是原因

3. 开环控制和闭环控制

   

4. 闭环控制措施

   

2. TCP的拥塞控制方法

TCP 采用基于滑动窗口的方法进行拥塞控制，属于闭环控制方法

TCP 发送方维持一个拥塞窗口 cwnd

拥塞窗口的大小取决于网络的拥塞程度，并且是动态变化的

发送窗口大小不仅取决于接收方窗口，还取决于网络的拥塞状况

1. 控制拥塞窗口变化的原则

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

2. 发送方判断拥塞的方法：隐式反馈

   发送方在超时重传计时器启动时，就判断网络出现了拥塞

3. TCP四种拥塞控制算法

   • 慢开始 (slow-start)
   • 拥塞避免 (congestion avoidance)
   • 快重传 (fast retransmit)
   • 快恢复 (fast recovery)

4. 慢开始

   • 目的：探测网络的负载能力或拥塞程度。
   • 算法：由小到大逐渐增大注入到网络中的数据字节，即：由小到大逐渐增大拥塞窗口数值。每收到一个对新的报文段的确认，就把拥塞窗口增加最多一个发送方的最大报文段 SMSS
   • 2 个控制变量：拥塞窗口cwnd，慢开始门限ssthresh

   

   • 传输轮次：一个传输轮次所经历的时间其实就是往返时间 RTT。把拥塞窗口 cwnd 所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。例如：拥塞窗口 cwnd = 4，这时的往返时间 RTT 就是发送方连续发送 4 个报文段，并收到这 4 个报文段的确认，总共经历的时间

   • 慢开始门限

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

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

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

5. 拥塞避免

   • 目的：让拥塞窗口 cwnd 缓慢地增大，避免出现拥塞

   • 拥塞窗口 cwnd 增大：每经过一个往返时间 RTT（不管在此期间收到了多少确认），发送方的拥塞窗口 cwnd = cwnd + 1

   

   • 当网络出现拥塞时

     ssthresh = max (cwnd/2，2)

     cwnd = 1

     执行慢开始算法

     目的：迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕

   • 慢开始和拥塞避免算法的实现举例

     

     当 TCP 连接进行初始化时，将拥塞窗口置为 1（窗口单位不使用字节而使用报文段）。慢开始门限的初始值设置为 16 个报文段，即 ssthresh = 16

     开始执行慢开始算法时，拥塞窗口 cwnd=1，发送第一个报文段，收到确认后拥塞窗口 cwnd 随着往返时延 RTT 按指数规律增长

     当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh 时，改为执行拥塞避免算法，拥塞窗口按线性规律增长

     当拥塞窗口 cwnd = 24 时，网络出现了超时，发送方判断为网络拥塞。调整门限值 ssthresh = cwnd / 2 = 12，同时设置拥塞窗口 cwnd = 1，进入慢开始阶段

     按照慢开始算法，发送方每收到一个对新报文段的确认 ACK，就把拥塞窗口值加 1。当拥塞窗口 cwnd = ssthresh = 12 时，改为执行拥塞避免算法，拥塞窗口按线性规律增大

     当拥塞窗口 cwnd = 16 时，发送方连续收到 3 个对同一个报文段的重复确认（记为 3-ACK）。发送方改为执行快重传和快恢复算法

6. 快重传FR算法

   • 目的：让发送方尽早知道发生了个别报文段的丢失

     发送方只要连续收到三个重复的确认，就立即进行重传（即“快重传”），这样就不会出现超时

     快重传算法要求接收方立即发送确认，即使收到了失序的报文段，也要立即发出对已收到的报文段的重复确认

   • 快重传举例

     

   • 快恢复FR算法

     当发送端收到连续三个重复的确认时，执行快恢复算法 FR (Fast Recovery) 算法

     慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ；

     乘法减小 MD (Multiplicative Decrease) 拥塞窗口。新拥塞窗口 cwnd = 慢开始门限 ssthresh

     执行拥塞避免算法，使拥塞窗口缓慢地线性增大（加法增大 AI）

   • 慢开始和拥塞避免算法举例（续）

     

     当拥塞窗口 cwnd = 16 时，发送方连续收到 3 个对同一个报文段的重复确认（记为 3-ACK）。发送方改为执行快重传和快恢复算法

     发送方调整门限值 ssthresh = cwnd / 2 = 8，设置拥塞窗口 cwnd = ssthresh = 8，开始执行拥塞避免算法

7. 发送窗口的上限值

   

3. 主动队列管理AQM

若路由器对某些分组的处理时间特别长，就可能引起发送方 TCP 超时，对这些报文段进行重传。重传会使 TCP 连接的发送端认为在网络中发生了拥塞，但实际上网络并没有发生拥塞

对 TCP 拥塞控制影响最大的就是路由器的分组丢弃策略

1. 先进先出FIFO处理规则

   尾部丢弃策略 (tail-drop policy)：当队列已满时，以后到达的所有分组（如果能够继续排队，这些分组都将排在队列的尾部）将都被丢弃

   路由器的尾部丢弃往往会导致一连串分组的丢失，这就使发送方出现超时重传，使 TCP 进入拥塞控制的慢开始状态，结果使 TCP 连接的发送方突然把数据的发送速率降低到很小的数值

2. 全局同步：分组丢弃使发送方出现超时重传，使多个 TCP 连接同时进入慢开始状态，发生全局同步 (global syncronization)

3. 主动队列管理AQM

   不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组，而是在队列长度达到某个值得警惕的数值时（即当网络拥塞有了某些拥塞征兆时），就主动丢弃到达的分组

   AQM 可以有不同实现方法，其中曾流行多年的就是随机早期检测 RED

4. 随机早期检测RED

   RED 对每一个到达的分组都先计算平均队列长度 L_AV

   • 若平均队列长度小于最小门限 THmin，则将新到达的分组放入队列进行排队。

   • 若平均队列长度超过最大门限 THmax ，则将新到达的分组丢弃。

   • 若平均队列长度介于在最小门限 THmin 和最大门限 THax 之间，则按照某一概率 p 将新到达的分组丢弃

     丢弃概率 p 的选择，因为 p 并不是个常数。例如，按线性规律变化，从 0 变到 pmax

     

九、TCP的运输连接管理

TCP 连接有三个阶段

• 连接建立
• 数据传送
• 连接释放

1. TCP的连接建立

1. 连接建立需要解决的三个问题

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

   TCP 连接的建立采用客户服务器方式

2. TCP 的连接建立：采用三报文握手

   三报文握手：在客户和服务器之间交换三个 TCP 报文段，以防止已失效的连接请求报文段突然

   传送到了，因而产生 TCP 连接建立错误

   

   • 第一次握手：A 的 TCP 向 B 主动发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x，表明传送数据时的第一个数据字节的序号是 x

   

   • 第二次握手：B 在确认报文段中应使 SYN = 1，使 ACK = 1，其确认号 ack = x + 1，自己选择的序号 seq = y

   

   • 第三次握手：A 收到此报文段后向 B 给出确认，其 ACK = 1，确认号 ack = y + 1。A 的 TCP 通知上层应用进程，连接已经建立

     B 的 TCP 收到主机 A 的确认后，也通知其上层应用进程：TCP 连接已经建立。双方可以开始数据传送

2. TCP的连接释放

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

1. 第一次握手

   

   A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的 FIN = 1，其序号seq = u，等待 B 的确认

2. 第二次握手

   

   B 发出确认，ACK=1，确认号 ack = u+1，这个报文段的序号 seq = v。

   TCP 服务器进程通知高层应用进程。从 A 到 B 这个方向的连接就释放了，TCP 连接处于半关闭 (half-close) 状态。B 若发送数据，A 仍要接收

3. 第三次握手

   

   若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。 FIN=1，ACK=1，确认号 ack = u+1

4. 第四次握手

   

   A 收到连接释放报文段后，必须发出确认。 ACK=1，确认号 ack=w+1，自己的序号 seq = u + 1

   注意：此时 TCP 连接还没有释放掉。必须经过时间等待计时器 (TIME-WAIT timer) 设置的时间 2MSL 后，A 才释放 TCP 连接

5. 必须等待2MSL的时间

   • 保证发送的最后一个 ACK 报文段能够到达 B。

   • 防止“已失效的连接请求报文段”出现在本连接中

6. 保活计时器

   • 用来防止在 TCP 连接出现长时期空闲。通常设置为 2 小时 。

   • 若服务器过了 2 小时还没有收到客户的信息，它就发送探测报文段。

   • 若发送了 10 个探测报文段（每一个相隔 75 秒）还没有响应，就假定客户出了故障，因而就终止该连接

3. TCP的有限状态机