文章目录
- 运输层概述
- UDP和TCP的对比
-
- 无连接的UDP和面向连接的TCP
- UDP和TCP对单播、多播和广播的支持情况
- UDP和TCP对应用层报文的处理
- UDP和TCP对数据传输可靠性的支持情况
- [UDP首部和TCP 首部的对比](#UDP首部和TCP 首部的对比)
- 传输控制协议
注：内容参考湖科大教书匠《深入浅出计算机网络》
运输层概述
进程间基于网络的通信
计算机网络体系结构中的物理层、数据链路层和网络层，它们共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信。
然而在计算机网络中实际进行通信的真正实体，是位于通信两端主机中的进程。
运输层的主要任务是为运行在不同主机上的应用进程提供直接的逻辑通信服务。运输层协议又称为端到端协议。
运输层向应用层实体屏蔽了下面网络核心的细节（例如网络拓扑、所采用的路由选择协议等），它使应用进程看见的就好像是在两个运输层实体之问有一条端到端的逻辑通信信道。
根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输层协议，即面向连接的TCP和无连接的UDP。
注：这里的"端口"并不是看得见、摸得着的物理端口，而是用来区分不同应用进程的标识符。
TCP/IP运输层中的两个重要协议
| TCP | UDP |
|---|---|
| 传输控制协议（TCP）为其上层提供面向连接的可靠的数据传输服务。 | 用户数据报协议（UDP）为其上层提供无连接的不可靠的数据传输服务。 |
| 使用TCP通信的双方，在传送数据之前必须首先建立TCP连接（逻辑连接，而非物理连接）。数据传输结束后必须要释放TCP连接。 | 使用UDP通信的双方，在传送数据之前不需要建立连接。 |
| TCP为了实现可靠传输，就必须使用很多措施，例如TCP连接管理、确认机制、超时重传、流量控制以及拥塞控制等。 | UDP不需要实现可靠传输，因此不需要使用实现可靠传输的各种机制。 |
| TCP的实现复杂，TCP报文段的首部比较大，占用处理机资源比较多。 | UDP的实现简单，UDP用户数据报的首部比较小 |
因特网中的一些典型应用所使用的TCP/IP应用层协议和相应的运输层协议如下所示：
运输层端口号、复用与分用的概念
运输层端口号
运行在计算机上的进程是使用进程标识符（PID）来标识的。
然而，因特网上的计算机并不是使用统一的操作系统，而不同操作系统又使用不同格式的进程标识符。为了使运行不同操作系统的计算机的应用进程之间能够基于网络进行通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识。
TCP/IP体系结构的运输层使用端口号来标识和区分应用层的不同应用进程。端口号的长度为16比特，取值范围是0~65535。
-
服务器端使用的端口号
- 熟知端口号：又称为全球通用端口号，取值范围是0～1023。这些端口号分配给了TCP/IP体系结构应用层中最重要的一些应用协议。
- 登记端口号：取值范围是1024～49151。这类端口号是为没有熟知端口号的应用程序使用的，要使用这类端口号必须登记。
-
客户端使用的短暂端口号：取值范围是49152～65535。这类端口号仅在客户端使用，由客户进程在运行时动态选择，又称为临时端口号。
注：端口号只具有本地意义，即端口号只是为了标识本计算机网络协议栈应用层中的各应用进程。在因特网中，不同计算机中的相同端口号是没有关系的，即相互独立。另外，TCP和UDP端口号之间也是没有关系的。
发送方的复用和接收方的分用
发送方的某些应用程序所发送的不同应用报文，在运输层使用UDP协议进行封装，这称为UDP复用 ；而另一些应用进程所发送的不同应用报文，在运输层使用TCP协议进行封装，这称为TCP复用。运输层使用端口号来区分不同的应用进程。
不管是使用运输层的UDP协议封装成的UDP用户数据报，还是使用TCP协议封装成的TCP报文段，在网际层都需要使用IP协议封装成IP数据报，这称为IP复用。IP数据报首部中的协议字段用来表明是何种协议数据单元。取值为6表示TCP报文段，取值为17表示UDP用户数据报。
接收方的网际层收到IP数据报后进行IP分用。
运输层对UDP用户数据报进行UDP分用 ，对TCP报文段进行TCP分用，根据UDP用户数据报或TCP报文段首部中的目的端口号，将它们向上交付给应用层的相应应用进程。
TCP/IP体系结构应用层常用协议所使用的运输层协议和熟知端口号如下图所示
注：OSPF报文并不使用运输层的UDP或TCP进行封装，而是直接使用网际层的IP进行封装，协议字段的值为89。
UDP和TCP的对比
无连接的UDP和面向连接的TCP
UDP是无连接的。使用UDP的通信双方，在传送数据之前不需要建立连接，可以随时发送数据。
TCP是面向连接的。换句话说，使用TCP的通信双方，在传送数据之前必须使用"三报文握手"来建立TCP连接。数据传输结束后，必须使用"四报文挥手"来释放TCP连接。
UDP和TCP对单播、多播和广播的支持情况
UDP支持单播、多播和广播。UDP支持"一对一"、"一对多"以及"---对全"的通信。
TCP仅支持单播，也就是"一对一"的通信。
UDP和TCP对应用层报文的处理
发送方的应用进程将应用层报文向下交付给运输层的UDP。UDP直接给应用层报文添加一个UDP首部，使之成为UDP用户数据报，然后进行发送。接收方的UDP收到UDP用户数据报后，去掉UDP首部，将应用层报文向上交付给应用进程。
综上所述，UDP对应用进程交付下来的报文既不合并也不拆分，而是保留这些报文的边界。
UDP是面向应用报文的。
发送方的TCP把应用进程交付下来的应用报文，仅仅看作一连串的、无结构的字节流。TCP并不知道这些待传输的字节流的含义，仅将它们编号并存储在自已的发送缓存中。TCP根据发送策略，从发送缓存中提取一定数量的字节，构建TCP报文段并发送。接收方的TCP一方面从所接收到的TCP报文段中取出数据载荷并存储在接收缓存中，另一方面将接收缓存中的一些字节向上交付给应用进程。
综上所述，TCP是面向字节流的，这正是TCP实现可靠传输、流量控制以及拥塞控制的基础。
注：在实际的网络中，基于TCP连接的两端可以同时进行TCP报文段的发送和接收，也就是全双工通信。
UDP和TCP对数据传输可靠性的支持情况
当运输层使用UDP时，UDP向其上层提供的也是无连接不可靠的数据传输服务。
对于UDP用户数据报出现的误码和丢失等问题，UDP并不关心。基于UDP的这个特点，UDP适用于实时应用，例如IP电话和视频会议等。
尽管IP数据报可能在传输过程中出现丢失或误码，但只要运输层使用TCP协议，TCP就可向其上层提供面向连接的可靠的数据传输服务。
基于TCP连接的可靠信道进行数据传输，不会出现误码、丢失、失序和重复等传输差错。基于TCP的这个特点，TCP适用于要求可靠传输且对实时性要求不高的应用，例如文件传输和电子邮件等。
UDP首部和TCP 首部的对比
UDP用户数据报由首部和数据载荷两部分构成。
UDP用户数据报的首部仅有4个字段，每个字段长度为2字节。由于UDP不提供可靠传输服务，它仅仅在网际层的基础上添加了用于区分应用进程的端口，因此它的首部非常简单，仅有8字节。
TCP报文段由首部和数据载荷两部分构成。
TCP报文段的首部比UDP用户数据报的首部复杂得多，其最小长度为20字节，最大长度为60字节。TCP要实现可靠传输、流量控制、拥塞控制等服务，其首部自然会比较复杂，首部中的字段比较多，首部长度也比较长。
传输控制协议
传输控制协议（TCP）是TCP/IP体系结构运输层中面向连接的协议，它向其上的应用层提供全双工的可靠的数据传输服务。
TCP除具有面向连接和可靠传输的特性，TCP还在运输层使用了流量控制和拥塞控制机制。
TCP报文段的首部格式
源端口字段和目的端口字段
源端口字段占16比特，用来写入源端口号。源端口号用来标识发送该TCP报文段的应用进程。
目的端口字段占16比特，用来写入目的端口号。目的端口号用来标识接收该TCP报文段的应用进程。
序号
占32比特，取值范围 0 ∼ 2 32 − 1 0 \sim 2^{32}-1 0∼232−1。当序号增加到最后一个时，下一个序号又会回到 0 0 0。
用来指出本TCP报文数据载荷的第一字节的序号。
确认号
占32比特，取值范围为 0 ∼ 2 32 − 1 0 \sim 2^{32}-1 0∼232−1。当确认号增加到最后一个时，下一个确认号又回到 0 0 0。
用来指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。
确认标志位ACK
只有当ACK取值为1时，确认号字段才有效。ACK取值为0时，确认号字段无效。TCP规定在TCP连接建立后，所有传送的TCP报文段都必须把ACK置1。
数据偏移
占4比特，该字段的取值以4字节为单位。
指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远，这实际上指出了TCP报文段的首部长度。
保留
占6比特，保留为今后使用，目前应置为0。
窗口
占16比特，该字段的取值以字节为单位。
指出发送本报文段的一方的接收窗口的大小，即接收缓存的可用空间大小，这用来表征接收方的接收能力。
检验和
占16比特，用来检查整个TCP报文段在传输过程中是否出现了误码。
发送方检验和计算方法
- 将TCP首部中检验和字段的值置为0。
- 将伪首部、TCP首部以及数据载荷这三部分划分成若干个2字节的字。若伪首部、TCP首部以及数据载荷这三部分的总长度不是偶数个字节，则在最后添加1 个"全0"字节。
- 对划分出的全部2字节的字进行反码算数运算求和，并将求和结果取反码。
- 将步骤3得到的结果写入TCP首部中的检验和字段。
接收方判断是否误码的方法
- 给接收到的TCP报文段前面添加一个12字节的伪首部。
- 将伪首部、TCP首部以及数据载荷这三部分划分成若干个2 字节的字。
- 对划分出的全部2字节的字进行反码算数运算求和，并将求和结果取反码。
- 若步骤3得到的结果为0，则表示TCP报文段在传输过程中没有误码。否则，表示出现了误码.
同步标志位SYN
用于TCP"三报文握手"建立连接。
当SYN=1且ACK=0时，表明这是一个TCP连接请求报文段。
对方若同意建立连接，则应在响应的TCP报文段的首部中使SYN=1且ACK=1 。
注：SYN为1的TCP报文段要么是一个连接请求报文段，要么是一个连接响应报文段。
终止标志位FIN
用于释放TCP连接。
当FIN=1时，表明此TCP报文段的发送方已经将全部数据发送完毕，现在要求释放TCP连接。
复位标志位RST
用于复位TCP连接。
当RST=1时，表明TCP连接中出现严重差错（例如由于主机崩溃或其他原因），必须释放连接，然后再重新建立连接。
RST置1还用来拒绝一个非法的TCP报文段或拒绝打开一个TCP连接。
推送标志位PSH
发送方TCP把PSH置1，并立即创建一个TCP报文段发送出去，而不需要积累到足够多的数据再发送。
接收方TCP收到PSH为1的TCP报文段，就尽快地交付给应用进程，而不再等到接收到足够多的数据才向上交付。
紧急标志位URG
当URG=1时，紧急指针字段有效。当URG=0时，紧急指针字段无效。
紧急指针
占16 比特，以字节为单位，用来指明紧急数据的长度。
当发送方有紧急数据时，可将紧急数据"插队"到发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。
接收方收到紧急标志位为1的TCP报文段，会按照紧急指针字段的值从报文段数据载荷中取出紧急数据并直接上交应用进程，而不必在接收缓存中排队。
选项
TCP报文段首部除了20字节的固定部分，还有最大40字节的选项部分。增加选项可以增加TCP的功能。
填充
由于选项字段的长度是可变的，因此还需要使用填充字段（填充内容为若干个比特0）来确保TCP报文段首部能被4整除 。这是因为TCP报文段首部中的数据偏移字段是以4字节为单位的。
TCP运输连接管理
TCP是面向连接的协议，它基于运输连接来传送TCP报文段。TCP运输连接的建立和释放，是每一次面向连接的通信中必不可少的过程。
TCP运输连接有三个阶段：
- 建立TCP连接：通过"三报文握手"来建立TCP连接。
- 数据传送：基于已建立的TCP连接进行可靠的数据传输。
- 释放连接：在数据传输结束后，还要通过"四报文挥手"来释放TCP连接。
"三报文握手"建立TCP连接
"三报文握手"建立TCP连接的目的在于解决以下三个主要问题：
- 使TCP双方能够确知对方的存在。
- 使TCP双方能够协商一些参数（例如最大报文段长度、最大窗口大小、时间戳选项等）。
- 使TCP双方能够对运输实体资源进行分配和初始化。运输实体资源包括缓存大小、各状态变量、连接表中的项目等。
- 报文1 ：TCP连接请求报文段和TCP连接请求确认报文段首部中的同步标志位SYN的值必须设置为1 。序号seq字段被设置了一个初始值x，作为TCP客户进程所选择的初始序号。
注：TCP规定同步标志位SYN被设置为1的报文段不能携带数据，但要消耗掉一个序号。因此，TCP客户进程下一次发送的TCP报文段的数据载荷的第一个字节的序号为x+1。
-
报文2 ：TCP连接请求确认报文段首部中的同步标志位SYN和确认标志位ACK的值都设置为1 。序号seq字段被设置了一个初始值y ，作为TCP服务器进程所选择的初始序号。确认号ack字段的值被设置为x+1，这是对TCP客户进程所选择的初始序号x的确认。
-
报文3 ：确认标志位ACK的值被设置为1 ，表明这是一个普通的TCP确认报文段。确认号ack字段的值被设置为y+1，这是对TCP服务器进程所选择的初始序号y的确认。
"四报文挥手"释放TCP连接
- 报文1 ：TCP连接释放报文段首部中的终止标志位FIN和确认标志位ACK的值都被设置为1 。表明这是一个TCP连接释放报文段，同时也对之前收到的TCP报文段进行确认。序号seq字段的值设置为u ，等于TCP客户进程之前已经传送的数据的最后一个字节的序号加1 。确认号ack字段的值设置为v ，等于TCP客户进程之前已收到的数据的最后一个字节的序号加1。
注：TCP规定终止标志位FIN等于1的TCP报文段即使不携带数据，也要消耗掉一个序号。
- 报文2 ：确认标志位ACK的值被设置为1 ，表明这是一个TCP普通确认报文段。序号seq字段的值设置为v ，等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1 。这也与之前收到的TCP连接释放报文段中的确认号v匹配。确认号ack字段的值设置为u+1，这是对TCP连接释放报文段的确认。
注：此时的TCP连接属于半关闭状态，从TCP客户进程到TCP服务器进程这个方向的连接就释放了，从TCP服务器进程到TCP客户进程这个方向的连接并未关闭。
-
报文3 ：TCP连接释放报文段首部中的终止标志位FIN和确认标志位ACK的值都被设置为1 。表明这是一个TCP连接释放报文段，同时也对之前收到的TCP报文段进行确认。序号seq字段的值假定被设置为w ，这是因为在半关闭状态下TCP服务器进程可能又发送了一些数据。确认号ack字段的值被设置为u+1，这是对之前收到的TCP连接释放报文段的重复确认。
-
报文4 ：确认标志位ACK的值设置为1 ，表明这是一个TCP普通确认报文段。序号seq字段的值设置为u+1 ，这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据，但要消耗掉一个序号。确认号ack字段的值设置为w+1，这是对所收到的TCP连接释放报文段的确认。
MSL是最长报文段寿命，建议为2分钟。也就是说，TCP客户进程进入时间等待（TIMEWAIT）状态后，还要经过4分钟才能进入关闭（CLOSED）状态。
TCP保活计时器
除时间等待计时器（2MSL计时），TCP还设有一个保活计时器。
TCP服务器进程每收到一次TCP客户进程的数据，就重新设置并启动保活计时器（通常为2小时）。
若保活计时器在定时周期内未收到TCP客户进程发来的数据，则当保活计时器到时后，TCP服务器进程就向TCP客户进程发送一个探测报文段，以后则每隔75秒发送一次。若一连发送10个探测报文段后仍无TCP客户进程的响应，TCP服务器进程就认为TCP客户进程所在主机出了故障，于是就关闭这个连接。
TCP的流量控制
TCP流量控制的基本概念
TCP为应用程序提供了流量控制（Flow Control）机制，以解决因发送方发送数据太快而导致接收方来不及接收，造成接收方的接收缓存溢出的问题。
流量控制的基本方法：接收方根据自己的接收能力（接收缓存的可用空间大小）控制发送方的发送速率。
TCP流量控制方法
TCP利用滑动窗口机制可用再TCP连接上实现对发送方的流量控制。
说明如下：
主机A和B已成功建立了TCP连接，A给B发送数据，B对A进行流量控
制。图中给出了主机A待发送数据的字节序号，每个小格子表示100字节数据的序号。
假设主机A发送的每个TCP数据报文段都携带100字节的数据，在主机A和B建立TCP连接时，B告诉A接收窗口为400，因此主机A的发送窗口也设置为400。
（1）主机A将发送窗口内序号为1～100的数据封装成一个TCP报文段发送出去，还有300字节可以发送。
seq是TCP报文段首部中的序号字段，取值1表示该TCP报文段数据载荷的第一个字节的序号是1；DATA表示这是TCP数据报文段。
（2）主机A将序号为101～200的数据封装成一个TCP报文段发送出去，发送窗口内还有200字节可以发送。
（3）主机A将序号为201～300的数据封装成一个TCP报文段发送出去，但该报文段在传输过程中丢失了。
（4）主机A还可发送100个字节的数据，即301～400号数据。此时主机B给主机A发送累积确认报文段，对主机A之前所发送的201号以前的数据进行累积确认。
该累积确认报文段首部中的ACK被设置为1，表示这是一个TCP确认报文段；确认号字段ack的取值设置为201，表示序号201之前的数据已全部正确接收，现在期望收到序号201及其后续数据；窗口字段rwnd的值被设置为300，主机B的接收缓存的可用空间变为为300字节，对主机A进行流量控制。
（5）主机A收到主机B发来的累积确认报文段后，将发送窗口向前滑动，使已发送并收到确认的数据的序号移出发送窗口，这些数据可从发送缓存中删除了。由于主机B在该累积确认报文段中将自己的接收窗口调整为了300，因此主机A相应地将自己的发送窗口调整为300。
这样，主机A的发送窗口内的序号为201～500，其中201~300号是已发送但还未收到确认的数据的序号，因此不能将这些数据从发送缓存删除，因为有可能之后会超时重传这些数据；301～400号字节数据以及401～500号字节数据还未被发送，可被分别封装在一个TCP报文段中发送。
（6）主机A将序号301～400号的数据封装成一个TCP报文段发送出去，还有401～500号共100字节可以发送。
（7）主机A将序号401～500号的数据封装成一个TCP报文段发送出去。至此，序号落在发送窗口内的数据已经全部发送出去了，不能再发送新的数据了。
（8）假设此时主机A发送窗口内序号201～300这100字节数据的重传计时器超时了，主机A将它们重新封装成一个TCP报文段发送出去，暂时不能发送其他数据。
（9）主机B收到该重传的TCP报文段后，给主机A发送累积确认报文段，对主机A之前所发送的501号以前的数据进行累积确认。
另外，主机B在该累积确认报文段中将自己的接收窗口调整为100，这是主机B对主机A进行的第二次流量控制。
（10）主机A收到主机B发来的累积确认报文段后，将发送窗口向前滑动，相应地将自己的发送窗口调整为100。这样，主机A的发送窗口内的序号为501～600，也就是主机A还可以发送这100字节数据。
（11）主机A将发送窗口内序号为501～600号的数据封装成一个TCP报文段发送出去。至此，序号落在发送窗口内的数据已经全部发送出去了，不能再发送新的数据了。
（12）主机B给主机A发送累积确认报文段，对主机A之前所发送的601号以前的数据进行累积确认。
另外，主机B在该累积确认报文段中将自己的接收窗口调整为0，这是主机B对主机A进行的第三次流量控制。
（13）主机A收到主机B发来的累积确认报文段后，将发送窗口向前滑动，相应地将自己的发送窗口调整为0。主机A不能再发送普通的TCP报文段了。
（14）假设主机B的接收缓存又有了一些可用空间。于是主机B向主机A发送了接收窗口等于300的报文段。然而，这个报文段丢失了。
（15）主机A一直等待主机B发送的非零窗口的通知，而主机B也一直等待主机A发送的数据。如果不采取措施，这种互相等待而形成的死锁局面将一直持续下去。
为了打破死锁局面，TCP为每一个连接都设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。当持续计时器超时时，就发送一个零窗口探测报文段，仅携带1字节的数
据。对方在确认这个零窗口探测报文段时，给出自己现在的接收窗口值。如果接收窗口值仍然是0，那么收到这个报文段的一方就重新启动持续计时器。如果接收窗口值不是0，那么死锁的局面就可以被打破了。
注 ：TCP规定，即使接收窗口值为0，也必须接受零窗口探测报
文段、确认报文段以及携带有紧急数据的报文段。
TCP的拥塞控制
拥塞控制的基本概念
在某段时间内，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，这就叫做拥塞。
若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。
拥塞控制的基本方法
流量控制与拥塞控制的区别
流量控制：以接收方的接收能力控制发送方（源点）的发送速率，只与特定的点对点通信的发送方和接收方之间的流量有关。
拥塞控制：源点根据各方面因素，按拥塞控制算法自行控制发送速率，全局性问题，涉及网络中所有的主机、路由器等。
拥塞控制的基本方法
开环控制
- 试图用良好的设计来解决问题。
- 从一开始就保证问题不会发生。
- 一旦系统启动并运行起来，就不需要中途修正。
当网络的流量特征可以准确规定且性能要求可以事先获得时，适合使用开环控制。
闭环控制
基于反馈的控制方法，包括以下三个部分：
- 监测网络拥塞在何时、何地发生。
- 把拥塞发生的相关信息传送到可以采取行动的地方。
- 调整网络的运行以解决拥塞问题。
当网络的流量特征不能准确描述或者当网络不提供资源预留时，适合使用闭环控制。因特网采用的就是闭环控制方法。
根据拥塞信息的反馈形式，可将闭环拥塞控制算法分为：
-
显式反馈算法：从拥塞节点（即路由器）向源点提供关于
网络中拥塞状态的显式反馈信息。
-
隐式反馈算法：源点自身通过对网络行为的观察（例如超时重传或往返时间RTT）来推断网络是否发生了拥塞。（TCP采用）
TCP的四种拥塞控制方法
TCP的四种拥塞控制方法是慢开始（Slow-Start）、拥塞避免（Congestion Avoidance）快重传（Fast Retransmit）、快恢复（Fast Recovery）。
发送方要维护一个叫作拥塞窗口的状态变量cwnd，其值取决于网络的拥塞程度和所采用的TCP拥塞控制算法。拥塞窗口cwnd的维护原则是，网络没有出现拥塞，拥塞窗口就增大一些；网络出现拥塞，拥塞窗口就减少一些。
注：当发送方出现超时重传时，很可能是因为网络中的某个路由器"繁忙"而丢弃了一些分组，这是网络出现拥塞的征兆。
发送方除了要维护拥塞窗口cwnd变量，还要维护发送窗口的状态变量swnd。发送窗口 s w n d = m i n ( c w n d , r w n d ) swnd=min(cwnd,rwnd) swnd=min(cwnd,rwnd)。
注：不考虑流量控制时，swnd=cwnd。
除拥塞窗口cwnd和发送窗口swnd，发送方还需要维护一个叫作慢开始门限的状态变量ssthresh：
- 当cwnd<ssthresh时，使用慢开始算法。
- 当cwnd>ssthresh时，停止使用慢开始算法而改用拥塞避免算法。
- 当cwnd=ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法。
慢开始算法和拥塞避免算法
发送方的拥塞窗口cwnd的初始值为1，而发送窗口swnd的
值始终等于cwnd的值（不考虑流量控制)，因此发送方一开始只能发送1个TCP数据报文段。
使用慢开始算法后，每经过一个传输轮次，拥塞窗口cwnd加倍。
当cwnd的值增大到了ssthresh值时，需要改用拥塞避免算法，每个传输轮次结束后，拥塞窗口cwnd线性加1。
假设这数据报文段在传输过程中丢失了几个。这必然会造成发送方对这些丢失报文段的超时重传。发送方以此判断网络可能出现了拥塞，需要调整自已的cwnd值和ssthresh值：
- 将ssthresh值调整为发生拥塞时cwnd值的一半。
- 将cwnd值减小为1，重新开始执行满开始算法。
"慢开始"是指一开始向网络注入的报文段少，而并不是指拥塞窗口cwnd的值增长速度慢。
"拥塞避免"也并非指完全能够避免拥塞，而是指在拥塞避免阶段将cwnd值控制为按线性规律增长，使网络比较不容易出现拥塞。