计算机网络—运输层

运输层概述

1、传输层概念

（1）运输层定义

运输层，也叫传输层，实现端对端的传输，应用层进程得到消息后交给传输层变成数据段，然后交予网络层。它位于网络层之上，应用层之下，为运行在不同主机上的应用进程之间提供了逻辑通信功能。

（2）进程之间的通信

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

从IP层来说，通信的两端是两台主机。但是真正进行的通信的实体是主机中的进程，是这台主机的一个应用进程和另一台主机中的一个进程在互相通信。从运输层的角度看，通信的真正端点并不是主机而是主机中的进程。

运输层为应用进程之间提供应用进程间的逻辑通信。只要把应用层报文交给下一层的运输层，运输层就能把这份报文送到对方的运输层，然后上交给应用层。好像这种通信就像沿水平方向直接传送数据，但事实上是沿着图中的虚线方向进行传输。

（3）传输层的两大重要功能

（1）多路复用：发送方不同的应用进程都可以使用同一个运输层协议传送数据（加上适当的头部）。

源主机从不同应用进程的套接字中收集数据块，并为每个数据块封装上首部信息从而生成报文段，然后将报文段传递到网络层

（2）多路分用：接收方的传输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。

在主机上的每个应用进程的套接字能够分配一个端口号，当报文段到达接收主机的时候，运输层检查报文段的目的端口号，并将其定向到相应的套接字，然后报文段中的数据通过套接字进入其所连接的进程。

（4）输层的主要作用

● 运输层为应用进程之间提供端到端的逻辑通信（但网络层是为主机之间提供逻辑通信） 。
● 运输层还要对收到的报文进行差错检测。
● 运输层需要有两种不同的运输协议，即面向连接的 TCP 和无连接的 UDP。

（5）数据加封与解封的过程

（6）与网络层的对比

● 网络层为不同主机提供通信服务，而传输层为不同主机的不同应用提供通信服务。
● 网络层只对报文头部进行差错检测，而传输层对整个报文进行差错检测。

2、传输层的端口

为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须用统一的方法对 TCP/IP 体系的应用进程进行标志。解决这个问题的方法就是在运输层使用协议端口号 (protocol port number)，或通常简称为端口 (port)。运输层收到网络层IP协议交上来的报文后，能够根据其中的目的端口号把数据交付给应用层的目的应用进程。

端口简言之就是为应用层的各个应用进程的数据通过这个“门”向下传递给传输层，反过来呢就是让传输层知道接受到的报文数据如何正确传递交付到对应的应用层上的进程上。

此处端口是指软件端口，是应用层的各种协议进程与运输实体进行层间交互的一种地址。硬件端口是不同硬件设备进行交互的接口，比如路由器或交换机上的硬件端口。

端口号只具有本地意义，即端口号只是为了标志本计算机应用层中的各进程。在 Internet 中不同计算机的相同端口号是没有联系的(最好不要有冲突)。

端口用一个 16 位端口号进行标志，其大小也就有 65536 个，是从 0~65535，也就是一台计算机有 65536 个端口。

● UDP常用熟知端口号

● TCP常用熟知端口号

端口种类

传输层的端口分为两大类：

（1） 服务器端使用的端口号
其中又分熟知端口号（端口号0 - 1023范围）和登记端口号（端口号1024 - 49151范围）。熟知端口号又叫系统端口号，是IANA指派给了TCP/IP最重要的一些应用程序，让所有用户都熟知。登记端口号是为没有熟知端口号的应用程序使用的，当一个新的应用程序出现后，在IANA处登记使用的端口号，防止重复。
（2）客户端使用的端口号
也叫短暂端口号，端口号为 49152 ~ 65535 。这类端口号是仅在客户端进程运行时动态选择，暂时使用进程结束端口号即不存在了，又可以被其他客户进程使用。

3、套接字

应用层通过传输层进行数据通信时，TCP 和 UDP 会遇到需要同时为多个应用程序进程提供并发服务的问题。
多个 TCP 连接或多个应用程序进程可能需要通过同一个 TCP 协议端口传输数据。为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与 TCP／IP 协议交互提供了称为套接字（Socket）的接口，区分不同应用程序进程间的网络通信和连接。

我们知道在网络中通过 IP 来唯一标识一个主机，而通过端口号来标识一台主机中的不同应用进程。所以在网络连接中就出现了 Socket 套接字来标识一个主机上的某进程，其实际是一个通信端点。

套接字是由主机的 IP 地址加上主机上的端口号组成的地址。

运输层就是将两个套接字连起来通信的介质，端口怎么使用，怎么通信，靠两个协议，UDP 和 TCP 协议。

4、面向连接和无连接

针对不同情况下的数据质量保证，传输层提供了两种数据传输协议类型，分别为面向连接与无连接。

（1）面向连接

面向连接就是通信双方在通信时，要事先建立一条通信线路，然后进行通信。其过程分为三个阶段。第一阶段是建立连接。第二阶段是连接成功建立之后，进行数据传输。第三阶段是在数据传输完毕后，释放连接。

下面以李四与张三的对话来说明面向连接的工作原理，如图所示。

其中，李四向张三说的每一句话都要得到张三的回应，然后才会说下一句话，直到李四说完最后一句话。

（2）面向无连接

无连接是指通信双方不需要事先建立通信线路，而是把每个带有目的地址的包（报文分组）发送到线路上，由系统选定路线进行传输，不需要目标方进行回复。

下面以李四与张三的对话来说明无连接的工作原理，如图所示。

从图中可以看到，李四向张三说出了要说的话，而不需要得到张三的回复。

运输层协议

因特网的网络层为主机之间提供的逻辑通信服务是一种尽最大努力交付的数据报服务。也就是说，IP报文在传送过程中有可能出错、丢失或失序。因此，需要运输层为这类应用提供可靠的数据传输服务。
TCP/IP网络为上层应用提供了两个不同的运输协议。

（1）用户数据报协议（User Datagram Protocol，UDP）
（2）传输控制协议（Transmission Control Protocol，TCP）OSI术语，两个对等实体在通信时传送的数据单位叫作运输协议数据单元（Transport Protocol Data Unit，TPDU）。
运输层协议分别称为TCP报文段和UDP报文或用户数据报。

1、用户数据报协议 UDP

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

（1）UDP的主要特点

● UDP 是无连接的，发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。
● UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表。 UDP 是面向报文的。

UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。UDP 一次交付一个完整的报文。接收方 UDP 对 IP 层交上来的 UDP 用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文。

● UDP 没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很适合多媒体通信的要求。
● UDP 支持一对一、一对多、多对一和多对多的交互通信。 UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。

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

若报文太长，UDP 把它交给 IP 层后，IP 层在传送时可能要进行分片，这会降低 IP 层的效率。
若报文太短，UDP 把它交给 IP 层后，会使 IP 数据报的首部的相对长度太大，这也降低了 IP 层的效率。

（2）UDP的首部格式

用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段有 8 个字节，由 4 个字段组成，每个字段都是 2 个字节。

● 源端口：源端口号。在需要对方回信时选用，不需要时可全写０。
● 目的端口：目的端口号。在终点交付报文时必须用到。若不存在对应于该端口的应用进程，就丢弃报文，并由ICMP发送“端口不可达”的差错报文给发送方。
● 长度：UDP 用户数据报的长度。其最小值是８字节（仅有首部）。
● 检验和：差错校验机制，检测 UDP 数据报在传输中是否有错，有就丢弃。

UDP的校验和不是必须有的，是可选的。
校验和既检查了 UDP 用户数据报的源端口号和目的端口号以及数据部分， 又同时对IP数据报的源 IP 地址和目的 IP 地址进行了校验。

（3）伪首部

UDP 用户数据报中首部的检验和在计算时，需要在该UDP数据报之前增加 12 个字节的伪首部，计算方法是二进制反码求和。伪首部并不是
UDP 数据报真正的首部，只是在计算检验和时临时加上的，得到一个临时的 UDP 用户数据报。伪首部仅仅是为了计算这个临时的 UDP
用户数据报的检验和，而不进行传送和递交服务。伪首部由五个字段构成分，如下：

（4）UDP 数据报的上交

当传输层从 IP 层收到 UDP 数据报时，就根据首部中的目的端口，把UDP 数据报通过相应的端口上交给应用进程。

如果接收方 UDP 发现收到的报文中的目的端口号不正确（不存在对应于该端口号的应用进程），就丢弃报文，并由网际控制报文协议 ICMP 发送“端口不可达”差错报文给发送方。
虽然在 UDP 之间的通信要用到端口号，但由于 UDP 的通信是无连接的，因此不需要使用套接字（Socket）来建立。

2、传输控制协议 TCP

（1）TCP 的主要特点

① TCP 是面向连接的

通信前需要建立连接，通信结束需要释放连接。

② 每一条TCP 连接只能有两个端点

TCP 只能提供点到点的通信，而UDP可以任意方式的通信。

③ TCP 提供可靠交付的服务

可靠指的是：TCP 发送的数据无重复、无丢失、无错误、与发送端顺序一致。

④ TCP 提供全双工通信

全双工通信指的是：TCP 的两端既可以作为发送端，也可以作为接收端。

⑤ TCP 是面向字节流的

面向字节流指的是：TCP 以字节为单位。虽然传输的过程中数据被划分成一个个数据报 ，但这只是为了方便传输，接收端最终接受到的数据将与发送端的数据一模一样。
面向字节流的含义是：虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流。TCP并不知道所传输的字节流的含义。TCP并不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应的大小关系（发送发交给发送方TCP10个数据块，但接收方的TPC用了4个数据块就把收到的字节流交付上层的应用程序）。但接收方应用程序收到的字节流必须和发送方应用程序发送的字节流完全一样。
CP将所要传送的整个报文看成是一个个字节组成的数据流，然后对每一个字节编一个序号。在连接建立时，双方要商定初始序号。TCP就将每一次所传送的报文段中的第一个数据字节的序号，放在TCP首部的序号字段中。TCP的确认是对接收到的数据的最高序号（即收到的数据流中的最后一个序号）表示确认。但返回的确认序号是已收到的数据的最高序号加1。也就是说，确认序号表示期望下次收到的第一个数据字节的序号。由于TCP能提供全双工通信，因此通信中的每一方都不必专门发送确认报文段，而可以在传送数据时顺便把确认信息捎带传送。这样可以提高传输效率。

注意：

（2）TCP 报文

（3）TCP的连接

TCP连接就是由协议软件所提供的一种抽象，表示一条可通信的链路。每条 TCP 连接有且仅有两个端点，表示通信的双方，且双发在任意时刻都可以作为发送者和接收者。
TCP 连接的端点叫做套接字(socket)或插口。

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

（4）可靠传输的原理

TCP的可靠性表现在：它向应用层提供的数据是 无差错的、有序的、无丢失的，简单的说就是：TCP最终递交给应用层的数据和发送者发送的数据是一模一样的。
TCP 发送的报文段是交给 IP 层传输的。但 IP 层只提供尽最大努力服务，也就是说，TCP下面的网络所提供的是不可靠传输，因此，TCP 必须采用适当的措施才能使得两个运输层之间的通信变得可靠。
TCP采用了流量控制、拥塞控制、连续 ARQ 等技术来保证它的可靠性。
当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速度。这样一来，本来是不可靠的传输信道就能够实现可靠传输了。

① 停止等待协议(ARQ协议)

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

分组差错和分组迟到

A 向 B 每发送一个分组，都要停止发送，等待 B 的确认应答；A 只有收到了B的确认应答后才能发送下一个分组。
发送者拥有超时计时器。每发送一个分组便会启动超时计时器，等待B的应答。若超时仍未收到应答，则A会重发刚才的分组。
● 分组差错：若B收到分组，但通过检查和字段发现分组在运输途中出现差错，它会直接丢弃该分组，并且不会有任何其他动作。A超时后便会重新发送该分组，直到B正确接收为止。
● 分组丢失：若分组在途中丢失，B并没有收到分组，因此也不会有任何响应。当A超时后也会重传分组，直到正确接收该分组的应答为止。
综上所述：当分组丢失 或 出现差错 的情况下，A都会超时重传分组。

应答丢失和应答迟到

TCP会给每个字节都打上序号，用于判断该分组是否已经接收。
● 应答丢失：若B正确收到分组，并已经返回应答，但应答在返回途中丢失了。此时A也收不到应答，从而超时重传。紧接着B又收到了该分组。接收者根据序号来判断当前收到的分组是否已经接收，若已接收则直接丢弃，并补上一个确认应答。
● 确认迟到：若由于网络拥塞，A迟迟收不到B发送的应答，因此会超时重传。B收到该分组后，发现已经接收，便丢弃该分组，并向A补上确认应答。A收到应答后便继续发送下一个分组。但经过了很长时间后，那个失效的应答最终抵达了A，此时A可根据序号判断该分组已经接收，此时只需简单丢弃即可。

停止等待协议的注意点

● 每发送完一个分组，该分组必须被保留，直到收到确认应答为止。
● 必须给每个分组进行编号。以便按序接收，并判断该分组是否已被接收。
● 必须设置超时计时器。每发送一个分组就要启动计时器，超时就要重发分组。
● 计时器的超时时间要大于应答的平均返回时间，否则会出现很多不必要的重传，降低传输效率。但超时时间也不能太长。

② 连续ARQ协议

位于发送窗口的分组都可以连续的发送出去，而不需要等待对方的确认，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

发送窗口的大小由接收窗口的剩余大小决定。接收者会把当前接收窗口的剩余大小写入应答TCP报文段的头部，发送者收到应答后根据该值和当前网络拥塞情况设置发送窗口的大小。发送窗口的大小是不断变化的。

接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都已正确收到了。

TCP头部的ack字段就是用来累计确认，它表示已经确认的字节序号+1，也表示期望发送者发送的下一个分组的起始字节号。
接收者收到的字节会存入接收窗口，接收者会对已经正确接收的有序字节进行累计确认，发送完确认应答后，接收窗口就可以向前移动指定字节。
如果某些字节并未按序收到，接收者只会确认最后一个有序的字节，从而乱序的字节就会被重新发送。
累积确认优点是：容易实现，即使确认丢失也不必重传。 缺点是：不能向发送方反映出接收方已经正确收到的所有分组的信息。

Go - back - N（回退N）

如果发送方发送了前 5 个分组，而中间的第 3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。 这就叫做 Go-back-N（回退 N），表示需要再退回来重传已发送过的 N 个分组。 可见当通信线路质量不好时，连续 ARQ 协议会带来负面的影响。

连续ARQ的注意点：

同一时刻发送窗口的大小并不一定和接收窗口一样大。

虽然发送窗口的大小是根据接收窗口的大小来设定的，但应答在网络中传输是有时间的，有可能t1时间接收窗口大小为m，但当确认应答抵达发送者时，接收窗口的大小已经发生了变化。 此外发送窗口的大小还随网络拥塞情况影响。当网络出现拥塞时，发送窗口将被调小。

TCP标准并未规定未按序到达的字节的处理方式。

但TCP一般都会缓存这些字节，等缺少的字节到达后再交给应用层处理。这比直接丢弃乱序的字节要节约带宽。

TCP标准规定接收方必须要有累计确认功能。

接收方可以对多个TCP报文段同时确认，但不能拖太长时间，一般是0.5S以内。 此外，TCP允许接收者在有数据要发送的时候捎带上确认应答。但这种情况一般较少，因为一般很少有两个方向都要发送数据的情况。

③ TCP可靠通信的具体实现

数据编号与确认

TCP协议是面向字节的。TCP把应用层交下来的长报文（这可能要划分为许多较短的报文段，）看成是一个个字节组成的数据流，并使每一个字节对应于一个序号。在建立连接时，双方TCP要各自确定初始序号。TCP每次发送的报文段的首部中的序号字段数值表示该报文段中紧接着首部后面的第一个数据字节的序号。
TCP使用的是累积确认，即确认是对是所有按序收到的数据的确认。但接收方返回的确认号是已按序收到的数据的最高序号加1 表示接收方期望下次收到的数据中的第一个数据字节序号。
TCP发送一段报文段时，同时也在自己的重传队列中存放这个报文段的一个副本。收到确认后，删除此副本；规定时间内没收到，则重传报文段的副本。
TCP的连接是全双工通信，可以在传送数据时顺便把确认信息稍带传送。
收到的报文段无差错，只是未按序到达，数TCP实现是现将其暂存与接收缓存内，待所缺的报文段收齐后一起上交应用层。

以字节为单位的滑动窗口

为了提高报文段的传输效率，TCP采用滑动窗口协议。但与GBN不用，TCP发送窗口大小的单位是字节，而不是分组数。TCP发送方已发送但未确认的字节数不能超过不能超过发送窗口的大小。

TCP的滑动窗口是会不断变化的，TCP的流量控制和拥塞控制会根据情况动态地调整发送窗口的上限制，从而控制发送数据的平均速率。

● 发送缓存用来暂时存放:

发送应用程序传送给发送方TCP准备发送的数据；
TCP已发送出去但尚未收到确认的数据。

● 接收缓存用来暂时存放：

按序到达的，但尚未被接收应用程序读取的数据；
未按序到达的，但还不能被接收应用程序读取的数据。

如果收到的分组被检测出有差错，则要丢弃。如果接受应用程序不及时读取数据，接收缓存最终就会被填满，使接收窗口减小到零。

超时重传时间的选择

TCP的发送方在规定时间内没有收到确认就要重传已发送的报文段。但如何选择超时重传的时间？ 运输层的超时计时器的超时重传时间究竟设置多大？
显然超时重传时间要比当前报文段的往返时间（Round-Trip Time，RTT）要长一些。TCP采用自适应算法。该算法记录每一个报文段发出的时间，以及收到相应的确认报文段时间，这两个时间之差就是报文段的往返时间RTT。TCP采用指数加权移动平均的算法对RTT测量值进行加权平均，得出报文段的平均往返时间RTTs。

SACK(选择确认)

TCP的报文段的确认字段是一种累积确认，它只通告收到的最后一个按序列到达的字节，而没有通告所有收到的失序到达的那些字节，虽然这些字节已经被接收方接收并暂存在接收缓存中。这些没有被确认的字节可能会因为超时而被发送方重传。所以一个可选的功能选择确认（Selective ACK，SACK）可以解决。
每一个字节块需要用两个边界序号来标识。TCP在首部提供了一个 可 变 长的 “ SACK选项字段 ”来存放这些信息。除此之外，要使用选择确认功能，在建立TCP连接时，双方还要分别在SYN报文段和SYN+ACK报文段的首部选项中添加“允许SACK选项字段”，表示都支持选择确认功能。

（5）TCP 的流量控制

如果发送者发送过快，接收者来不及接收，那么就会有分组丢失。为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。
TCP为应用程序提供了 流量控制（flow control）服务，以解决因发送方发送数据太快而导致接收方来不及接收，使接受方缓存溢出的问题。

流量控制的基本方法就是接收方根据自己的接收能力控制发送方的发送速率。TCP采用控制发送方发送窗口大小（发送窗口的上限就是TCP报文段首部窗口写入的数值大小）的方法来实现TCP连接上的流量控制。
在建立连接时，接收方在报头中会携带接收窗口大小的信息。发送方的发送窗口不能超过接收方的接收窗口的数值。需要注意的是，TCP的窗口单位是字节而不是报文段。

流量控制引发的死锁

当发送者收到了一个窗口为0的应答，发送者便停止发送，等待接收者的下一个应答。但是如果这个窗口不为0的应答在传输过程丢失，发送者一直等待下去，而接收者以为发送者已经收到该应答，等待接收新数据，这样双方就相互等待，从而产生死锁。

持续计时器

为了避免流量控制引发的死锁，TCP使用了持续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口，则重置该计时器继续等待；若窗口不为0，则表示应答报文丢失了，此时重置发送窗口后开始发送，这样就避免了死锁的产生。

（6）TCP 的拥塞控制

当网络中出现太多的分组时，网络的性能开始下降。这种情况称为拥塞（congestion）。拥塞是分组交换网中一个非常重要的问题。如果网络中的负载（load），即发送到网络中的数据量超过了网络的容量（网络中能处理的数据量），那么在网络中过就可能发生拥塞。所谓拥塞控制（congestion control）就是防止过多而数据注入到网络中，这样可以使网络中的路由器或链路不致过载。

拥塞的原因及危害：

当输入负载继续增大时，网络的吞吐量可能下降到0，即网络无法工作。这就是死锁（deadlock）。
出现资源拥塞的条件： 对资源需求的总和 > 可用资源

拥塞控制和流量控制之间的区别

它们都需要控制源点的发送速率。
拥塞控制的任务是防止过多的数据注入到网络中，使网络能够承受现有的网络负载。这是一个全局性的问题。
流量控制只与特定点对点通信的发送方和接收方之间的流量有关。它的任务是，确保一个快速的发送方不会持续地以超过接收方能力的速率发送数据，以防止接收方来不及处理数据。通常所涉及的做法是，接收方向发送方提供某种直接的反馈，以抑制发送方的发送速率。

拥塞控制的基本方法

慢开始和拥塞避免

发送方维持一个叫做拥塞窗口 cwnd (congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。如再考虑到接收方的接收能力，则发送窗口还可能小于拥塞窗口。
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。

拥塞窗口 < 慢开始门限：使用慢开始算法
拥塞窗口 > 慢开始门限：使用拥塞避免算法
拥塞窗口 = 慢开始门限：使用慢开始算法或拥塞避免算法

无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有按时收到确认），就要把慢开始门限 ssthresh 设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口 cwnd 重新设置为 1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

在执行慢开始算法时，拥塞窗口 cwnd 的初始值为 1，发送第一个报文段 M0。
发送端每收到一个确认 ，就把 cwnd 加 1。于是发送端可以接着发送 M1 和 M2 两个报文段。
接收端共发回两个确认。发送端每收到一个对新报文段的确认，就把发送端的 cwnd 加 1。现在 cwnd 从 2 增大到 4，并可接着发送后面的 4 个报文段。
发送端每收到一个对新报文段的确认，就把发送端的拥塞窗口加 1，因此拥塞窗口 cwnd 随着传输轮次按指数规律增长。
当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh 时（即当 cwnd = 16 时），就改为执行拥塞避免算法，拥塞窗口按线性规律增长。
假定拥塞窗口的数值增长到 24 时，网络出现超时，表明网络拥塞了。
更新后的 ssthresh 值变为 12（即发送窗口数值 24 的一半），拥塞窗口再重新设置为 1，并执行慢开始算法。
当 cwnd = 12 时改为执行拥塞避免算法，拥塞窗口按按线性规律增长，每经过一个往返时延就增加一个 MSS 的大小。

快重传

快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认。这样做可以让发送方及早知道有报文段没有到达接收方。
发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段。
不难看出，快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段。

快恢复算法

与快重传配合使用的还有快恢复算法

当发送端收到连续三个重复的确认时，就执行“乘法减小”算法，把慢开始门限 ssthresh 减半。但接下去不执行慢开始算法。
由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，即拥塞窗口 cwnd 现在不设置为 1，而是设置为慢开始门限 ssthresh 减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。

（7）TCP运输连接管理

1、TCP 三次握手

（1）客户端 A 向服务端 B 发出连接请求，同步位SYN=1，初始序列seq=x，连接请求报文段不能携带数据，但是要消耗一个序号，这时客户端A进入SYN-SENT（同步已发送状态）。
（2）服务端 B 收到请求报文段之后，向 A 发送后确认。将同部位SYN和确认位都置为1，确认序号ack=x+1，同时自己选择一个初始序号seq=y。连接接收报文也不能携带数据，但是也要消耗一个序号，这时服务端进入SYN-RCVD(同步收到状态)。
（3）A 收到 B 的确认时候要给 B 一个确认。确认报文段的确认位ACK=1,确认号ack=y+1,自己的序号seq=x+1。这时,TCP连接已经建立，客户端进入ESTABLISHED（已建立连接状态）。B收到A发出的确认报文之后也进入已建立连接状态。

（1）为什么客户端还需要再发送一次确认？

主要是为了防止已经失效的连接请求报文段突然又传到了B，因而产生错误。“已失效的连接请求报文段”的产生在这样一种情况下：A发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了（因为网络并发量很大在某结点被阻塞了），以致延误到连接释放以后的某个时间才到达B。但是B收到此失效的报文段后，就认为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。如果不采用三次握手，那么只要B发出确认，新的连接就建立了，B的许多资源就白白浪费。

（2）SYN Flood攻击

SYN Flood攻击指利用tcp协议缺陷发送大量伪造的TCP连接请求，从而使被攻击方资源耗尽（CPU满负载或者内存不足）的攻击法方式。解决方法：

● 缩短 SYN Timeout 时间缩短从接收到 SYN 报文到确定这个报文无效并丢弃该连接的时间，但是过低的SYN Timeout可能会影响用户正常访问。
● 设置 SYN Cookie给每一个请求连接的 IP 地址分配一个 Cookie，如果短时间内连续受到某个IP的重复 SYN 报文，就认定是受到了攻击，以后从这个 IP 地址来的包会被丢弃
● 使用硬件防火墙

2、TCP 四次挥手过程

（1）客户端进程发出连接释放报文，并且停止发送数据。A将连接释放报文的终止位FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1）。此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
（2）服务器收到连接释放报文后发出确认，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向的连接就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
（3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）
（4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认
（5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，客户端才进入CLOSED状态
（6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。

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

为了保证A发送的最后一个确认报文段能够达到B。这个ACK报文段可能丢失，因而使处在LAST-ACK状态的B收不到A发送的FIN+ACK报文段的确认。B会超时重传这个ACK+FIN报文段，而A就能在这个时间内收到这个重传的报文。接着A在再重传一次确认报文，并且重启2MSL计时器。使A和B都能正常的进入释放连接状态。
防止已经关闭的连接报文段出现在新的连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有旧报文段都从网络中消失。这样新的连接中不会出现旧连接的数据报文。

(2) 为什么建立连接是三次握手，而关闭连接却是四次挥手呢？

这是由于服务端的LISTEN状态下收到SYN报文的建立连接请求后。它能够把ACK和SYN（ACK起应答作用。而SYN起同步作用）放在一个报文里来发送给客户端。
但关闭连接的时候，当服务端收到客户端的FIN报文段的时候，表示客户端没有数据发送给服务端了，但是服务端可能还有数据要发送给客户端，这时TCP连接处于半连接状态。当服务端没有数据再发送给客户端的时候就会向客户端发送一个FIN报文表示服务端要关闭连接，ACK和FIN一般不会分开发送。这个过程也是由于TCP的通信方式是全双工的，发送和接收方都需要发送FIN和ACK。