005运输层*

概述

1. 运输层向应用层提供通信服务
   （1）运输层是面向通信部分的最高层
   （2）运输层是用户功能中的最底层
2. 只有主机的协议栈才有运输层，而网络核心部分中的路由器在分组转发时都使用到下三层的功能
3. 网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信

• 复用和分用：

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

运输层端口

1. 运输层使用协议端口号(端口)，当运输层收到IP层交上来的运输层报文时，能够根据目的端口号把数据交付应用层的目的应用进程
2. 两个计算机中的进程要相互通信，不仅必须知道对方的IP地址，而且要知道对方的端口号

• 服务器使用的端口号：

1. 熟知端口号(系统端口号)： 0 ~ 1023
2. 登记端口号： 1024 ~ 49151

• 客户端使用的端口号：

1. 客户端使用的端口号: 49152 ~ 65535
2. 此类端口只能在客户进程运行时才动态选择，因此又叫做短暂端口号

用户数据报协议UDP

1. UDP是无连接的，使用尽最大努力交付， 即不保证可靠交付
2. UDP是面向报文的：
   （1）发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层
   （2）UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界
   （3）应用程序必须选择合适大小的报文，报文段太长，IP层在传送时需要进行分片，会降低IP层的效率
3. UDP没有拥塞控制，因此网络拥塞不会使源主机的发送速率降低
4. UDP支持一对一、一对多、多对一和多对多的交互通信
5. UDP首部开销小，只有8个字节

首部格式

1. 用户数据报 = 数据字段 + 首部字段
2. 首部字段 = 4字段 * 2字节
   （1）源端口： 源端口号
   （2）目的端口： 目的端口号
   （3）长度： 用户数据报的长度，最小值是8(仅有首部)
   （4）校验和： 检测用户数据报在传输中是否有错，差错即丢弃

1. 当运输层从IP层收到用户数据报时，就根据首部中的目的端口，把用户数据报通过相应的端口，上交给应用进程
2. 若接收方UDP发现收到的报文中的目的端口号不正确（即不存在对应于该端口号的应用进程），就丢弃该报文，并由网际控制报文协议ICMP发送端口不可达差错报文给发送方
3. 虽然在UDP之间的通信要用到其端口号，但由于UDP的通信是无连接的，因此不需要使用套接字

• UDP校验和:
  

1. 在计算校验和时，要在UDP用户数据报之前增加12个字节的伪首部
2. 伪首部既不向下传送也不向上递交，而仅仅是为了计算校验和
3. IP数据报的检验和只检验IP数据报的首部，但UDP的校验和检验首部和数据
4. 计算步骤：
   （1）将全零放入检验和字段
   （2）将伪首部及UDP数据报看成由许多16位的字串接起来的
   （3）若UDP数据报的数据部分不是偶数个字节，则要填入一个全零字节(但此字节不发送)
   （4）按二进制反码计算出这些16位字的和
   （5）将此和的二进制反码写入校验和字段后
5. 在接收方，将收到的UDP用户数据报连同伪首部以及可能的填充全零字节一起，按二进制反码求这些16位字的和
   （1）无差错： 结果应全为1
   （2）出现差错： 结果不全为1，丢弃

传输控制协议TCP

1. TCP是面向连接的运输层协议
2. 每一个TCP连接只能是点对点的
3. TCP提供可靠交付的服务
4. TCP连接提供全双工通信，TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据
5. TCP连接是面向字节流的：
   （1）流： 流入进程或从进程流程的字节序列
   （2）虽然用户程序和TCP的交互是一次一个数据块(大小不等)，但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流
6. TCP报文段的长度由接收方给出的窗口值rwd和网络拥塞程度决定而并不关心应用进程一次把多长的报文发送到TCP的缓存中

套接字

1. TCP连接的端点叫做套接字(socket)或插口
2. 套接字 socket = (IP地址 : 端口号)
3. 每一条TCP连接唯一地被通信两端的两个端点(两个套接字)所确定
4. TCP连接 ::= {socket₁， socket₂} = {(IP₁ :Port₁), (IP₂:Port₂)}
5. 同一个IP地址可以有多个不同的TCP连接，而同一个端口号也可以出现在多个不同的的TCP连接中

首部格式*

• 源端口和目的端口： 源端口号和目的端口号

• 序号(报文段序号)： 本报文段所发送的数据的第一个字节的序号

1. 在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，确保通信的有序性，避免网络中的乱序问题
2. 初始的序列号由自己定，后续的序列号由对方的确认号决定

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

1. 确认号 = N: 到序号$N-1$为止的所有数据都已正确收到

• 数据偏移： 指出TCP报文段的数据起始处距离TCP报文段的起始处有多远，单位是4个字节
• 保留： 置为0，保留为今后使用
• 控制位(6个)：

1. 紧急URG：
   （1）当URG = 1时，表明紧急指针字段有效，即告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)
   （2）发送方TCP就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍是普通数据
   （3）需要与首部中的紧急指针字段配合使用
2. 确认ACK：
   （1）仅当ACK = 1时确认号字段才有效
   （2）当ACK = 0时，确认号无效
   （3）TCP规定，在建立连接后所有传送的报文段都必须把ACK置为1
3. 推送PSH：
   （1）发送方TCP把PSH置为1，并立即创建一个报文段发送出去
   （2）接收方TCP收到PSH = 1的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付
4. 复位RST：
   （1）当RST = 1时，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立运输连接
   （2）当RST=1还用来拒绝一个非法的报文段或拒绝打开一个连接
5. 同步SYN： 在连接建立时用来同步序号
   （1）当SYN = 1而ACK = 0时，表明这是一个连接请求报文段
   （2）若对方同意建立连接，则应在响应的报文段中使用SYN = 1和ACK = 1
6. 终止FIN： 用来释放一个连接
   （1）当FIN = 1时，表明此报文段的发送方的数据已经发送完毕，并要求释放运输连接

• 窗口： 发送本报文段的一方的接收窗口(而不是自己的发送窗口)
  （1）窗口值告诉对方，从本报文段首部中的确认号算起，目前允许对方发送的数据量(以字节为单位)
  （2）窗口值作为接收方让发送方设置其发送窗口的依据
  （3）窗口值经常动态变化

• 检验和：
  （1）检验范围: 首部+数据
  （2）在计算检验和时，要在TCP报文段的前面加上12字节的伪首部
• 紧急指针：
  （1）紧急指针仅在URG = 1时才有意义
  （2）紧急指针指出本报文段中的紧急数据的字节数

TCP vs UDP *

	UDP	TCP
连接性	无连接	面向连接
可靠性	不可靠，无确认机制	可靠,有确认机制
流量控制	无	有
拥塞控制	无	有
连接对象个数	一对一、一对多、多对多	一对一
传输方式	面向报文	面向字节流
首部开销	开销小，固定8字节	开销大，最小20字节、最大60字节
使用场景	适用于实时应用(IP电话、视频会议、直播等)	适用于要求可靠传输的应用，如文件传输等

可靠传输的原理

停止等待协议

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

• 无差错时：

1. $A$发送分组$M_1$，发完就暂停发送，等待$B$的确认
2. $B$收到了$M_1$就向A发送确认
3. $A$收到了对$M_1$的确认之后，就再发送下一个分组$M_2$
4. 同样，在收到$B$对$M_2$的确认后，再发送$M_3$，如此循环往复

• 出现差错时：

1. 出现差错地可能情况：
   （1）$B$接收到$M_1$时检测出了错误，就丢弃$M_1$，其他什么也不做，即不通知$A$收到有差错的分组
   （2）$M_1$在传输过程中丢失了，此时$B$什么都不知道，因此$B$也不会发送任何消息
2. 超时重传： 只要超过一定时间$A$仍然没有收到$B$的确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组

1. $A$在发送完一个分组后，必须暂时保留已发送的分组的副本(在发生超时重传时使用)，只有收到相应的确认后才能清除暂时保留的分组副本
2. 分组和确认分组必须进行编号
3. 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些

• 确认丢失：

1. $B$所发送的对$M_1$的确认丢失了
2. $A$在设定超时时间内没有收到确认，此时$A$无法知道是发送的分组出错、丢失，还是$B$发送的确认丢失了，因此$A$在超时计时器到期后仍要重传$M_1$
3. 当$B$收到了重传的分组$M_1$，应采取如下行动：
   （1）丢弃这个重复分组$M_1$，不向上层交付
   （2）再次向$A$发送确认

• 确认迟到：

1. 传输过程中没有出现差错，但$B$对分组$M_1$的确认迟到了
2. $A$会收到重复的确认，对重复的确认的处理：收下后丢丢弃
3. $B$仍然会收到重复的分组$M_1$，并且同样要丢弃重复的$M_1$，并重传确认分组

• 自动重传请求ARQ：

1. 通过确认和重传机制，可以在不可靠的传输网络上实现可靠的通信
2. 自动重传请求ARQ： 重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组
   （1）优点：简单
   （2）缺点：信道利用率低

1. 为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输
2. 流水线传输： 发送方可连续发送多个分组，不必每发送完一个分组就停顿下来等待对方的确认
3. 通过流水线传输可以使信道上一直有数据不间断地在传送，可以获得较高的信道利用率
4. 当使用流水线传输时，需要使用连续ARQ协议和滑动窗口协议

连续ARQ协议

1. 发送方维持了一个发送窗口: 位于发送窗口内的分组都可以连续发出，而不需要等待对方的确认
2. 接收方采用累基确认的方式
   （1）接收方不必对收到的分组逐个发送确认
   （2）在收到几个分组后，对按序到达的最后一个分组发送确认
   （3）确认分组的含义： 到这个分组为止的所有分组都已正确收到
3. 优缺点：
   （1）优点： 实现容易，即使确认丢失也不必重传
   （2）缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息

• Go-back-N:

1. GO-back-N(回退N)： 需要再退回来重传已发送过的$N$个分组
2. 举例：
   （1）如果发送方发送了前5个分组，而中间的第三个分组丢失了
   （2）此时接收方只能对前两个分组发送确认
   （3）发送方无法知道后面3个分组的下落，而只好把后面的3个分组都再重传一次

可靠传输的实现

滑动窗口

1. 在没有收到$B$的确认的情况下，$A$可以连续把发送窗口内的数据发送出去
2. 凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用
3. 发送窗口后沿的后面部分为已发送且已收到了确认的字节，因此这些数据无需继续保留
4. 发送窗口前沿的前面部分为不允许发送的字节，因为接受方没有为这部分数据保留临时存放的缓存空间

• 发送窗口后沿的变化：

1. 不动： 未收到新的确认
2. 前移： 收到新的确认
3. 发送窗口后沿不可能向后移动，因为不能撤销已收到的确认

• 发送窗口前沿的变化：

1. 通常情况下，发送窗口前沿会不断向前移动
2. 保持不动：
   （1）没有收到新的确认，对方通知的窗口大小也不变
   （2）收到了新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动
3. 向后收缩：
   （1）在对方通知的窗口缩小时，但TCP的标准强烈不赞成这样做
   （2）因为很可能发送方在收到这个通知以前已经发送了窗口中的许多数据，现在又要收缩，不让发送这些数据，就会产生一些错误

• A的发送窗口:

1. 要描述一个发送窗口的状态需要三个指针:$P_1$，$P_2$，$P_3$
2. 指针小于$P_1$表示已发送并且已收到确认的部分，而大于$P_3$的是不允许发送的部分
3. $P_3-P_1=A的窗口大小$
4. $P_2-P_1=已发送但尚未收到确认的字节数$
5. $P_3-P_2=允许发送但当前尚未发送的字节数$(可用窗口 或 有效窗口)

• B的接收窗口：

1. 到30号为止的数据为已经发送过确认，并且已经交付主机的数据，因此$B$可以不再保留这些数据
2. 接收窗口(31~50)是允许接收的， $B$只能对按序收到的数据中最后序号给出确认，因此$B$的确认报文段中的确认号仍然是31(即期望收到的序号)，而不能是32或33

1. $A$继续发送完序号42~53的数据后，指针$P_2$向前移动与$P_3$重合，发送窗口内的序号都已用完，但仍未收到确认，因此$A$必须停止发送数据
2. 有可能发送窗口内的所有数据都已正确到达$B$，$B$也早已发出了确认，但所有$确认$都滞留在网络中
3. 由于没有收到$B$的确认，$A$在经过一段时间后(由超时重传计时器控制)就重传这部分数据，并重新设置$超时重传计时器$，直到收到$B$的确认为止

• 发送缓存与接收缓存:
  

1. 缓存空间和序号空间都是有限且循环使用的

• 发送缓存：

1. 存放的数据：
   （1）发送应用程序传送给发送方TCP准备发送的数据
   （2）TCP已发送但尚未收到确认的数据
2. 发送窗口通常只是发送缓存的一部分
3. 已被确认的数据应当从发送缓存中删除， 因此发送缓存和发送窗口的后沿是重合的
4. 发送应用程序必须控制写入缓存的速率， 不能太快， 否则发送缓存就会没有存放该数据的空间

• 接收缓存：

1. 存放的数据
   （1）按序到达的、 但尚未被接收应用程序读取的数据
   （2）未按序到达的数据
2. 若接收应用程序来不及读取收到的数据， 接收缓存最终就会被填满， 使接收窗口减小到零
3. 如果接收应用程序能够及时从接收缓存中读取收到的数据， 接收窗口就可以增大， 但最大不能超过接收缓存的大小

1. 虽然$A$的发送窗口是根据$B$的接收窗口设置的， 但在同一时刻， $A$的发送窗口并不总是和$B$的接收窗口一样大
   （1）通过网络传送窗口值需要经历一定的时间滞后
   （2）发送方$A$还可能根据网络当时的$拥塞情况$适当减小自己的发送窗口数值
2. TCP通常对不按序到达的数据是先临时存放在接收窗口中， 等到字节流中所缺少的字节收到后， 再按序交付上层的应用进程
3. TCP要求接收方必须有累积确认的功能， 这样可以减小传输开销
4. 接收方可以在合适的时候发送确认， 也可以在自身发送数据时把确认信息顺便捎带上
5. 接收方不应过分推迟发送确认， 否则会导致发送方不必要的重传， 这反而浪费了网络的资源
6. TCP的通信是全双工通信： 通信中的每一方都在发送和接收报文段，因此， 每一方都有自己的发送窗口和接收窗口

超时重传时间

• 超时重传时间的选择：

1. 超时重传时间的选择是十分困难的:
   （1）超时重传时间是基于报文段的往返时间$RTT$确定的
   （2）$RTT$的测量较为复杂，路由和网络资源的不同，它会随时间变化
2. 若超时重传时间设置得太短， 会引起很多报文段的不必要的重传， 使网络负荷增大
3. 若超时重传时间设置得过长， 会使网络的空闲时间增大， 降低了传输效率

• 超时重传时间的确定算法：

1. TCP采用了一种自适应算法:
   （1）记录1个报文段发出的时间及收到相应确认的时间
   （2）这两个时间之差就是报文段的往返时间$RTT$
   （3）TCP保存了RTT的一个加权平均往返时间(平滑的往返时间)$RT{T}_s$
   （4）$$新RT{T}_s=(1-\alpha )\times (旧RT{T}_s)+\alpha \times (新RTT样本)0\le \alpha \le 1$$
   （5）超时计时设置的重传时间RTO应略大于加权平均往返时间$RT{T}_s$

选择确认(SACK)

1. 选择确认： SACK是一个TCP选项，可以允许接收方告诉发送方它正确接收到了次序杂乱的数据
2. 与前后字节不连续的每一个字节块都有两个边界：左边界和右边界
3. 如果要使用选择确认， 则在建立TCP连接时， 要在TCP首部的选项中加上允许SACK的选项， 且双方必须事先商定好
4. 如果使用选择确认，那么原来首部中的确认号字段的用法仍然不变，只是以后在TCP报文段的首部中都增加了SACK选项, 以便报告收到的不连续的字节块的边界
5. 首部选项的长度最多只有40个字节,而指明一个边界就要用掉4个字节(序号为32位)，因此在选项中最多只能指明4个字节块的边界信息
   （1）4个字节块共有8个边界， 需要用32个字节来描述
   （2）另外还需要2个字节： 一个字节用来指明是SACK 选项， 另一个字节是指明该选项的长度
6. 当收到乱序数据时，提供一个SACK来描述乱序数据，可以帮组对方有效地进行重传

• TCP如何实现可靠传输：

1. 建立连接(标志位): 通信前确认通信实体是存在的
2. 序号机制(序号、确认号):确保了数据的有序性和完整性
3. 数据校验(校验和):用于校验TCP报文是否损坏
4. 超时重传(定时器): 接收方收到报文后就会确认，发送方一段时间后没有收到确认就会重传
5. 流量控制(窗口):接收方通过滑动窗口控制发送方的发送速率，避免过量发送导致包丢失
6. 拥塞控制:当网络发送拥塞时，通过拥塞窗口，减少数据发送，避免过量发送导致包丢失

流量控制

1. 控制发送方的发送速率，使得接收方来得及接收
2. 接收方通过控制发送方的发送窗口大小来控制其发送速率
3. 发送方的发送窗口不能超过接收方给出的接收窗口的数值

• 异常情况与持续计时器：

1. 异常情况描述：
   （1）$B$向$A$发送了$rwd=0$的报文段后不久，$B$的接收缓存又有了一些存储空间
   （2）于是$B$向$A$发送了$rwd=400$的报文段，但该报文段在传输过程丢失了
   （3）此时$A$将一直等待$B$发送的非零窗口的通知，而$B$也一直等待$A$发送的数据
2. 解决方案：
   （1）为每个TCP连接设有一个持续计时器，当TCP连接的一方接收到对方的零窗口通知，就启动持续计时器
   （2）若持续计时器设置的时间到期，就发送一个零窗口探测报文段(仅携带1个字节的数据)，而对方就在确认该探测报文段时给出了现在的窗口值
   （3）若窗口仍然是0，那么收到这个报文段的一方就重新设置持续计时器；若窗口不是0，那么死锁的局面就可以打破了

发送时机

• 报文段的发送时机：

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

• Nagle算法:

1. Nagle算法是TCP的实现中广泛使用的发送控制机制
2. 基本原理：
   （1）若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存中， 则发送方就把第一个数据字节先发送出去， 把后面到达的数据字节都缓存起来
   （2）当发送方收到对第一个数据字符的确认后， 再把发送缓存中的所有数据组装成一个报文段发送出去， 同时继续对随后到达的数据进行缓存
   （3）只有在收到对前一个报文段的确认后才继续发送下一个报文段
   （4）此外，当到达的数据己达到发送窗口大小的一半或已达到报文段的最大长度时， 就立即发送一个报文段

传输效率

• 糊涂窗口综合征:

1. 现象描述：
   （1）TCP接收方的缓存已满，而交互式应用进程一次只从接收缓存中读取一个字节(接收缓存空间仅腾出1个字节)
   （2）然后向发送方发送确认，并把窗口设置为1(发送的数据报长度是40个字节)
   （3）接着，发送方又发来1个字节的数据(发送方发送的IP数据报是41个字节)
   （4）接收方发回确认，仍然将窗口设置为1个字节
2. 危害： 糊涂窗口综合征长期进行下去，会使网络的效率很低
3. 解决方法：
   （1）让接收方等待一段时间，或者接收方缓存已有足够空间容纳一个最长的报文段，或者等到接收方缓存已有一半空闲的空间时，接收方就发出确认报文，并向发送方通知当前窗口的大小
   （2）发送方也不要发送太小的报文段，而是把数据累积成足够大的报文段，或达到接收方缓存空间的一半大小

拥塞控制*

1. 拥塞： 若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏
2. $\sum$ 对资源的需求 > 可用资源

• 拥塞控制 vs 流量控制:*

1. 控制目的：
   （1）拥塞控制： 防止过多的数据注入到网络导致网络资源(路由器、交换机等)过载
   （2）流量控制： 抑制发送端发送数据的速率，使接收端来得及接收
2. 参与者：
   （1）拥塞控制： 全局性的过程，涉及到通信链路全局
   （2）流量控制： 点对点通信的控制，是一个端到端的问题
3. 控制方式：
   （1）拥塞控制： 拥塞窗口大小变化由试探性发送一定量数据探查网络状况后依据拥塞控制算法自适应调节
   （2）流量控制： 通信双方各维护一个发送窗口一个接收窗口，接收窗口大小由自身决定，发送窗口大小由接收方响应的TCP报文段中窗口值确定

拥塞控制算法

• TCP进行拥塞控制的算法：慢开始、拥塞避免、快重传、快恢复

1. 发送方维持一个拥塞窗口(cwnd) 的状态变量
   （1）拥塞窗口的大小取决于网络的拥塞程度，且动态变化
   （2）发送方让自己的发送窗口等于拥塞窗口
2. 控制原则：
   （1）只要网络未出现拥塞，拥塞窗口就再增大一些，以便发送更多的分组，提高网络利用率
   （2）只要网络出现拥塞或有可能出现拥塞，就把拥塞窗口减小，以减少注入到网络中的分组数，缓解网络出现的拥塞
3. 网络拥塞的判断标准： 出现超时
   （1）只要网络发送拥塞时，路由器就要丢弃分组
   （2）只要发送方没有按时收到应当到达的确认报文，即只要出现了超时重传时，就可以猜想网络可能出现了拥塞
4. $发送窗口的上限值=Min[rwnd,cwnd]$

• 慢开始算法：

1. 基本思路：
   （1）当主机开始发送数据时，并不清楚网络的负荷情况
   （2）所以先探测一下，即由小到大逐渐增大发送窗口，即从小到大逐渐增加拥塞窗口数值
2. 初始拥塞窗口(cwnd)数值设置为2~4个SMSS(发送方的最大报文段)的数值
3. 慢开始规定，在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个SMSS
4. $拥塞窗口cwd每次增加量=min(N,SMSS)$，其中$N$是原先未被确认，但现在被刚收到的确认报文所确认的字节数
5. 慢开始并不是指cwnd的增长速率慢，而是指在开始发送报文段时先设置cwnd = 1，使得发送方在开始时只发送一个报文段，然后再逐渐增大cwnd，相比设置大的cwnd值一下将许多报文段注入网络要 “慢得多”
6. 为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需设置一个慢开始门限(ssthresh):
   （1）当cwnd < ssthresh时，使用慢开始算法
   （2）当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法
   （3）当cwnd = ssthresh时，既可以使用慢开始算法，也可以使用拥塞避免算法

• 拥塞避免算法：

1. 基本思路： 让拥塞窗口缓慢地增大，即每经过一个往返时间就把发送方的拥塞窗口+1，而非慢开始阶段的加倍增长
2. 拥塞避免的特点： 加法增大，即拥塞窗口按线性规律缓慢增长，调整到网络的最佳值

• 快重传算法：

1. 采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失
2. 快重传算法要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认
3. 快重传算法规定：发送方只要一连收到3个重复确认，就知道接收方确实没有收到某报文段，因此应立即进行重传(快重传)， 这样就不会出现超时，发送方也就不会误认为出现了网络拥塞

• 快恢复算法:

1. 当发送方知道现在只是丢失个别的报文，而非网络拥塞，于是不启动慢开算法，而是快恢复算法
2. 在快恢复算法中，发送方调整门限值 ssthresh = cwnd / 2，同时设置拥塞窗口cwnd = ssthresh，并开始执行拥塞避免算法

主动队列管理(AQM)

1. 在网络层，路由器的分组丢弃策略对TCP拥塞控制影响最大
2. 尾部丢弃策略： 路由器队列通常按照先入先出规则来处理分组，当队列已满时，以后再到达的多余分组都将被丢弃
3. 尾部丢弃会导致一连串分组的丢失，此时发送方会出现超时重传，使TCP进入拥塞控制的慢开始状态，结果使TCP连接的发送方突然把数据的发送速度降到很小的数值
4. 全局同步：
   （1）在网络中通常有很多的TCP连接，在这种情况下，若发生了路由器中的尾部丢弃， 就可能会同时影响到很多条TCP连接
   （2）结果使这许多TCP连接在同一时间突然都进入到慢开始状态，全网的通信量突然下降很多
   （3）在网络恢复后正常后，其通信量又突然增大很多

• 主动队列管理：

1. 作用： 为了避免发生网络中的全局同步现象
2. 主动:
   （1）不要等到路由器的长度已经达到最大值时才不得不丢弃后面到达的分组
   （2）应当在队列长度达到某个值得警惕的数值时，即当网络拥塞有了某些拥塞征兆时，就主动丢弃到达的分组

• 随机检测(RED)：

1. 随机早期检测是主动管理队列的一种实现方法
2. 基本思路： 随机早期检测使路由器维持两个参数：队列长度最小门限、队列长度最大门限
   （1）若平均队列长度小于最小门限，则把新到达的分组放入队列进行排队
   （2）若平均队列长度超过最大门限，把新到达的分组丢弃
   （3）若平均队列长度在最小门限和最大门限之间，则按照某一丢弃概率$p$把新到达的分组丢弃

连接建立与释放*

1. 运输连接的阶段：连接建立、数据传送、连接释放

连接建立

• 建立过程：

1. $A$打算建立TCP连接时，向$B$发送连接请求报文，此时首部中的同步位SYN = 1，同时选择一个初始序号seq = x
   （1）TCP规定，SYN报文段(SYN = 1的报文段)不能携带数据，但要消耗一个序号， 此时TCP客户端进入SYN-SENT(同步已发送)状态
   （2）连接请求报文中可能会含有一个或多个TCP选项
2. $B$收到连接请求报文段后，若同意建立连接，则向$A$发送确认
   （1）在确认报文中应把SYN位和ACK位都置为1，确认号是ack = x + 1，同时也为自己选择一个初始序号seq = y
   （2）确认报文段也不能携带数据，但同样要消耗一个序号，此时TCP服务器进程进入SYN-RCVD(同步收到)状态
3. TCP客户端进程收到B的确认后，还要向$B$给出确认
   （1）确认报文段的ACK = 1，确认号ack = y + 1，而自己的序号seq = x + 1，TCP规定， ACK报文段可以携带数据
   （2）但如果不携带数据则不消耗序号，这种情况下，下一个数据报文段的序号仍然是seq = x + 1，此时，TCP连接已经建立，$A$进入ESTABLISH(已建立连接)状态
4. 当$B$收到$A$的确认后，也进入ESTABLISH状态

• 为什么A最后还要发送一次确认?

• 为了防止已失效的连接请求报文段突然传到B，因而造成服务器资源浪费：

1. $A$发出的第一个连接请求报文并没有丢失，而是在某些网络结点长时间滞留了，一直延误到连接释放以后的某个时间才到达$B$
2. 该链接请求报文是一个早已失效的报文段，但$B$收到此失效的连接请求报文段后，就误以为$A$又发一次新的连接请求，于是就向$A$发送确认报文段，同意建立连接
3. 假定不采用报文握手，那么只要$B$发出确认，新的连接就建立了
4. 由于现在$A$并没有发出建立连接的请求，因此不会理睬$B$的确认，也不会向$B$发送数据
5. 但$B$却以为新的运输连接已经建立了，并一直等待$A$发来数据，B的许多资源就白白浪费了

• 三次握手的目的：
  （1）三次握手的主要作用是确认双方的接收和发送能力是否正常，指定自己的初始化序列号，交换TCP窗口大小信息，为后续的可靠性传输做准备
  （2）第一次握手：客户端发送链接请求报文，服务端收到了，服务端可以得出结论：客户端的发送能力和服务端的接收能力是正常的
  （3）第二次握手：服务端发包，客户端收到了，客户端得出结论：服务端的发送和接收能力都是正常的，客户端的发送和接收能力也是正常的，但服务端不能确认客户端的接收能力是否正常
  （4）第三次握手：客户端发包，服务器收到了，服务器得出结论：服务端的发送和接收能力都是正常的，客户端的发送和接收能力也是正常的
  （5）因此，需要三次握手才能确认双方的发送和接收能力是否正常

• 三次握手中为什么第1次不能携带数据，而第3次可以？
  （1）若第一次握手可以携带数据，会使服务器更加容易受到攻击，因为恶意攻击者可能会在SYN报文中放入大量数据，同时可能会重复发送大量的SYN报文，这会让服务器花费很多时间和空间来接受报文
  （2）第三次握手时，客户端已经处于ESTABLIST状态，对于客户端而言，TCP连接已经建立，并且已经知道服务器的接收和发送能力都是正常的，所以可以携带数据

连接释放

• 释放过程：

1. 起初$A$和$B$都处于ESTABLISHED状态
2. $A$的应用进程先向其TCP发出连接释放报文，并停止发送数据，主动关闭TCP连接
   （1）$A$把连接释放报文段首部的终止控制位FIN置为1，其序号seq = u，此时$A$进入FIN-WAIT-1(终止等待1)，等待$B$的确认
   （2）TCP规定，FIN报文段即使不携带数据，也要消耗掉一个序号
3. $B$接收到连接释放报文后即发出确认，确认号ack = u + 1，该报文段的序号是v，然后$B$就进入CLOSE-WAIT(关闭等待)状态
   （1）TCP服务器进程这时应通知高层应用进程，因而$A$到$B$这个方向的连接就释放了
   （2）此时TCP连接处于半关闭状态，即$A$已经没有数据要发送了，但$B$若发送数据，$A$仍要接收
4. $A$收到来自$B$的确认后，就进入FIN-WAIT-2(终止等待2)状态，等待$B$发出的连接释放报文段
5. 若$B$已经没有要向$A$发送的数据了，其应用进程就通知TCP释放连接
   （1）这时$B$发出的连接释放报文段必须使FIN = 1，现假定$B$的序列号为w(在半关闭状态$B$可能又发送了一些数据)，$B$还必须重复上次已发送过的确认号ack = u + 1
   （2）这时$B$就进入LAST-ACK(最后确认)状态，等待$A$的确认
6. $A$在收到$B$的连接释放报文段后，必须对此发出确认
   （1）在确认报文段中把ACK置为1，确认号ack = w + 1，而自己的序号是seq = u +1(根据TCP标准，前面发送过的FIN报文段要消耗一个序号）
   （2）然后进入TIME-WAIT(时间等待)状态，现在TCP连接还没有释放掉，必须经过时间等待计时器设置的时间2MSL后，$A$才进入到CLOSED状态
   （3）MSL：最长报文段寿命

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

1. 为了保证$A$发送的最后一个ACK报文段能够到达$B$：
   （1）若该ACK报文段丢失，因而$B$无法收到确认，$B$会超时重传这个FIN + ACK报文段，而$A$就能在2MSL时间内收到该重传的FIN + ACK报文段，接着$A$重传一次确认，重新启动2MSL计时器，最后，$A$和$B$正常进入CLOSED状态
   （2）如果$A$在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN + ACK报文段，因而不会再发送一次确认报文段，导致$B$无法按照正常步骤进入CLOSED状态
2. 防止已失效的连接请求报文段出现在本连接中：
   （1）$A$在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，因此可以保证下一个新的连接中不会出现旧的连接请求报文段

• 为什么TCP连接的建立需要三次握手，而TCP连接的释放需要四次挥手？
  （1）在TCP连接时，当服务端收到客户端SYN连接请求报文后，可以直接发送SYN+ACK报文，其中ACK报文用于应答，SYN报文用于同步
  （2）但是，在TCP连接断开时，当服务器收到FIN报文时，很可能服务器并互相立即关闭TCP连接，而是进入半关闭状态，所以只能先回复一个ACK报文，只有等服务器端所有的报文都发送完毕后，才能发送FIN报文，因此FIN和ACK不能一起发送，所以需要四次挥手

• 保活计时器：

1. 作用： 防止TCP连接建立后，因客户端主机突发故障，导致服务器白白等待的现象发生
2. 解决方案：
   （1）服务器每收到一次客户端的数据，就重新设置保活计时器(通常为2小时)
   （2）若2小时没有收到客户的数据，服务器就发送一个探测报文段，以后则每隔75秒发送一次
   （3）若连续发送10个探测报文段后仍无客户的响应，服务器就认为客户端出了故障，接着就关闭这个链接