计算机网络笔记整理(五)：运输层

一、运输层协议概述

进程之间的通信
运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时，只有主机的协议栈才有运输层，而网络核心部分中的路由在转发分组时都只用到下三层的功能。
从IP层来说，通信的两端是两个主机，IP数据报的首部明确地标志了这两个主机的IP地址，但真正进行通信的实体是在主机中的进程，是这个主机中的一个进程和另一个主机中的一个进程在交换数据(即通信)。IP协议虽然能把分组送到目的主机，但是这个分组还停留在主机的网络层而没有交付给主机中的应用程序。从运输层的角度看，通信的真正端点并不是主机而是主机中的进程。
运输层有一个很重要的功能——复用(multiplexing)和分用(demultiplexing)。“复用”指在发送方不同的应用进程都可以使用同一个运输层协议传送数据，而“分用”指接收方的运输层在剥去报文的首部后能够把这些数据正确交付到目的应用进程。
网络层和运输层之间有明显的区别。网络层是为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。
运输层还要对收到的报文进行差错检测(注意网络层的IP数据报首部中的检验和字段，只检验首部是否出现差错而不检查数据部分)。
根据应用程序的不同需求，运输层需要有两种不同的运输协议，即面向连接的TCP和无连接的UDP。当运输层采用面向连接的TCP协议时，尽管下面的网络是不可靠的(只提供尽最大努力服务)，但这种逻辑通信信道就相当于一条全双工的可靠信道。但当运输层采用无连接的UDP协议时，这种逻辑通信信道仍然是一条不可靠信道。

运输层的两个主要协议
按照OSI的术语，两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元TPDU(Transport Protocol Data Unit)。但在TCP/IP体系中，则根据所使用的协议是TCP或UDP，分别称之为TCP报文段(segment)或UDP用户数据报。
UDP在传送数据之前不需要先建立连接。远地主机的运输层在收到UDP报文后，不需要给出任何的确认。虽然UDP不提供可靠交付，但在某些情况下UDP却是一种最有效的工作方式。
TCP则提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或多播服务。由于TCP要提供可靠的、面向连接的运输服务，所以协议数据单元的首部增大很多，还要占用许多的处理及资源。
下表给出一些应用和应用层协议主要使用的运输层协议(UDP或TCP)：

应用	应用层协议	运输层协议
名字转换	DNS	UDP
文件传送	TFTP	UDP
远程文件服务器	NFS	UDP
电子邮件	SMTP	TCP
远程终端接入	TELNET	TCP
万维网	HTTP	TCP
文件传送	FTP	TCP

运输层的端口
运输层从IP层收到数据后必须交付给指明的应用进程，所以给应用层的每一个应用进程赋予一个非常明确的标志是至关重要的。解决的方法就是在运输层使用协议端口号(protocol port number)，或通常简称为端口(port)。也就是说，虽然通信的终点时应用进程，但我们只要把传送的报文交到目的主机的某一个合适的目的端口，剩下的工作(即最后交付给目的进程)就由TCP来完成。这种在协议栈层间抽象的协议端口是软件端口，和硬件端口不是同一概念。硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。
运输层的端口号共分为下面的两大类：

服务端使用的端口号
此处又分为两类，最重要的一类叫做熟知端口号(well-known port number)或系统端口号，数值为0~1023。IANA把这些端口号指派给了TCP/IP最重要的一些应用程序，让所有的用户都知道，当一种新的应用程序出现后，IANA必须为它指派一个熟知端口，否则因特网上的其他应用进程就无法和它通信，一些常用的熟知端口号如下表：

应用程序	FTP	TELNET	SMTP	DNS	TFTP	HTTP	SNMP	SNMP(trap)
熟知端口号	21	23	25	53	69	80	161	162

另一类叫做登记端口号，数值为1024~49151。这类端口号是为没有熟知端口号的应用程序使用的。使用这类端口号必须在IANA按照规定的手续登记，以防止重复。

客户端使用的端口号
数值为49152~65535。由于这类端口号仅在客户进程运行时才动态选择，因此又叫做短暂端口号。这类端口号是留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户端所使用的端口号，因而可以把数据发送给客户进程。通信结束后，刚才已使用过的客户端口号就不复存在。这个端口号就可以供其他客户进程以后使用。

二、用户数据报协议UDP

UDP概述
用户数据报协议UDP只在IP的数据报服务之上增加很少一点的功能，这就是复用和分用的功能以及差错检测的功能。UDP的主要特点是：

UDP是无连接的，减少了开销和发送数据之前的时延； UDP使用尽最大努力交付； UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。也就是说，UDP一次交付一个完整的报文。

UDP的优点如下：

UDP没有拥塞处理控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用很重要的，如IP电话、实时视频会议等。 UDP支持一对一、一对多、多对一和多对多的交互通信。 UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。

UDP的首部格式
用户数据报UDP有两个字段：数据字段和首部字段。首部字段很简单，只有8个字节，如图1所示，由四个字段组成，每个字段的长度都是两个字节。各字段意义如下：

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

UDP用户数据报首部中检验和的计算方法有些特殊。在计算检验和时，要在UDP用户数据报之前增加12个字节的伪首部。这个伪首部只是在计算检验和时，临时添加在UDP用户数据报前面，得到一个临时的UDP用户数据报。伪首部既不向下传送也不向上递交。UDP的检验和是把首部和数据部分一起检验。
伪首部的第3字段是全零，第4个字段是IP首部中的协议字段的值，对于UDP，此协议字段值是17.第5个字段是UDP用户数据报的长度。因此UDP的检验和既检查了UDP用户数据报的源端口号和目的端口号以及UDP用户数据报的数据部分，又检查了IP数据报的源IP地址和目的地址。

三、传输控制协议TCP概述

TCP最主要的特点

TCP是面向连接的运输层协议。应用程序在使用TCP协议之前，必须先建立TCP连接。在传送数据完毕后，必须释放已经建立的TCP连接。 每一条TCP连接只能有两个端点(endpoint)，每一条TCP连接只能是点对点的(一对一)。 TCP提供可靠交付的服务，也就是无差错、不丢失、不重复、按序到达。 TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。 面向字节流。虽然应用程序和TCP的交互是一次一个数据块(大小不等)，但TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流。

TCP和UDP在发送报文时所采用的方式完全不同。TCP对应用进程一次把多长的报文发送到TCP的缓存中是不关心的。TCP根据堆放给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节(UDP发送的报文长度是应用程序给出的)。

TCP的连接
TCP连接的端点叫做套接字(socket)或插口。端口号拼接到(contatenated with) IP地址即构成了套接字，如IP地址是192.3.4.5而端口号是80，那么套接字就是192.3.4.5:80。就是 套接字socket=(IP地址:端口号)。
每一条TCP连接唯一地被通信两端的两个端点(即两个套接字)所确定。即：
TCP连接::={socket1, socket2}={(IP1:port1),(IP2:port2)}

四、可靠传输的工作原理

TCP发送的报文段是交给尽最大努力服务的IP层传送的，也就是TCP下面的网络所提供的是不可靠的传输。因此，TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠。所以TCP使用了一些可靠传输协议，当出现差错时让发送方重传出错的数据，同时在接收方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速度。

停止等待协议
全双工通信的双方既是发送方也是接收方。下面我们只考虑A发送数据而B接收数据并发送确认。“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

无差错情况
最简单的情况，如图2(a)所示，A发送分组M1，发完就暂停发送，等待B的确认。B收到了M1就向A发送确认。A在收到了对M1的确认后再发送下一个分组。 出现差错
图2(b)是分组在传输过，程中出现差错的情况。B接收M1时检测出了差错就丢弃M1，其他什么也不做(不通知A收到有差错的分组)，也可能是M1在传输过程中丢失了，这时B当然什么都不知道，这两种情况下，B都不会发送任何信息。A只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组，这就叫做超时重传。所以就要在每发送完一个分组设置一个超时计时器。
此处应注意三点：(1) A在发送完一个分组后，必须暂时保留已发送的分组的副本(为发生超时重传时使用)。(2) 分组和确认分组都必须进行编号。(3) 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。

确认丢失和确认迟到
如图3(a)所示，B所发送的对M2的确认丢失了。A在设定的超时重传时间内没有收到确认，但并无法知道是自己发送的分组出错、丢失，或者是B发送的确认丢失了。因此A在超时计时器到期后就要重传M2。现在应注意B的动作，假定B又收到了重传的分组M2。此时应采取两个行动：(1) 丢弃这个重复的分组M2，不向上层交付；(2) 向A发送确认。
图2(b)中，传输过程中没有出现差错，但B对分组M1的确认迟到了。A会收到重复的确认，对重复的确认的处理很简单：收下后就丢弃。B仍然会收到重复的M1，并且同样要丢弃重复的M1，并重传确认分组。
通常A最终可以收到所有发出的分组的确认，如果A不断重传分组但总是收不到确认，说明通信线路太差，不能进行通信。
使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。像上述的这种可靠传输协议常称为自动重传请求ARQ(Automatic Repeat reQuest)。意思就是重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组。
信道利用率
停止等待协议的优点是简单，但缺点是信道利用率太低。为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输。流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地在传送。显然这种传输方式可获得很高的信道利用率。
当使用流水线传输时，就要使用下面介绍的连续ARQ协议和滑动窗口协议。

连续ARQ协议
如图3所示，(a)表示发送方维持的发送窗口，它的意义在于：位于发送窗口内的5个分组都可以连续发送出去，而不需要等待对方确认，这就提高了信道利用率。
连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前移动一个分组的位置。如果原来已经发送了前5个分组，那么现在就可以发送窗口内的第6个分组。

接收方一般都是采用累积确认的方式，也就是接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，表示这个分组为止的所有分组都已正确收到了。累积确认的优点是容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息。
例如，如果发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N(回退N)，表示需要再退回来重传已发送过的N个分组。可见当通信线路质量不好时，连续ARQ协议会带来负面的影响。目前对可靠传输有更好的解决方法。

五、TCP报文段的首部格式

TCP报文段首部的前20个字节是固定的，如图4所示。后面有4N字节是根据需要而增加的选项(N是整数)。因此TCP首部的最小长度是20字节。
首部固定部分各字段的意义如下：

源端口和目的端口 各占2个字节，分别写入源端口号和目的端口号。 序号 占4字节。序号使用mod 2^32^运算。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。首部中的序号字段值是本报文段所发送的数据的第一个字节的序号。 确认号 占4字节，是期望收到对方下一个报文段的第一个数据字节的序号。若确认号=N，则表明到序号N-1为止的所有数据都已正确收到。 数据偏移 占4位。指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。这个字段实际上是指出TCP报文段的首部长度。“数据偏移”的单位是32位字(即以4字节长的字为计算单位)。 保留 占6位，保留为今后使用，但目前应置为0。

下面是6个控制位说明本报文段的性质。

紧急URG(URGent) 当URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级数据)，而不要按原来的排队顺序来传送。当URG置1时，发送应用进程就告诉发送方的TCP有紧急数据要传送。于是发送方TCP就把紧急数据插入本报文段数据的最前面，而在紧急数据后面的数据仍然是普通数据，这时要与首部中紧急指针(Urgent Pointer)字段配合使用。 确认ACK(ACKnowlegment) 仅当ACK=1时确认号字段才有效。当ACK=0时，确认号无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置1。 推送PSH(PuSH) 当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。在这种情况下，TCP就可以使用推送(push)操作。这是发送方TCP把PSH置1，并立即创建一个报文段发送出去。接收方TCP收到PSH=1的报文段，就尽快地(即“推送”向前)交付给接收应用进程，而不再等到整个缓存都填满了后再向上交付。 复位RST(ReSeT) 当RST=1时，表明TCP连接中出现严重差错(如由于主机崩溃或其他原因)，必须释放连接，然后再重新建立运输连接。RST置1还用来拒绝一个非法的报文段或拒绝打开一个连接。RST也可称为重建位或重置位。 同步SYN(SYNchronization) 在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。若对方同意建立连接，则在响应的报文段中使用SYN=1和ACK=1。因此，SYN置1就表示这是一个连接请求或连接接收报文。 终止FIN 用来释放一个连接。当FIN=1时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。 窗口 占2字节。窗口指的是发送本报文段的一方的接收窗口(而不是自己的发送窗口)。窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量。因为接收方的数据缓存空间是有限的，总之，窗口值作为接收方让发送方设置其发送窗口的依据。 检验和 占2字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。其格式与UDP数据报的伪首部一样，注意TCP的协议号为6。 紧急指针 占2字节。仅在URG=1时才有意义，他指出本报文段中的紧急数据的字节数(紧急数据结束后就是普通数据)。注意即使窗口为0时也可发送紧急数据。 选项 长度可变，最长可达40字节。当没有使用选项时，TCP的首部长度是20字节。TCP最初只规定了一种选项，即最大报文段长度MSS(Maximum Segment Size)，指的是每一个TCP报文段中的数据字段的最大长度。MSS的默认值是536字节长。还有其他选项，如窗口扩大选项、时间戳选项、选择确认(SACK)选项。

六、TCP可靠传输的实现

以字节为单位的滑动窗口
TCP的滑动窗口是以字节为单位的。假定A收到了B发来的确认报文段，其中窗口是20(字节)，而确认号是31(表明B期望收到的下一个序号是31，而序号30为止的数据已经收到了)，据此两个数据，A就构造出自己的发送窗口(长度为20，序号为31~50)。
凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。
发送方和接收方都有缓存，发送缓存用来暂时存放：(1)发送应用程序传送给发送方TCP准备发送的数据；(2)TCP已发送但尚未收到确认的数据。接收缓存用于暂时存放：(1)按序到达的、但尚未被接收应用程序读取的数据；(2)未按序到达的数据。
根据上述讨论，我们应当注意以下三点：
虽然A的发送窗口是根据B的接收窗口设置的，但由于网络的滞后性，A的发送窗口和B的接收窗口并不总是一样大的。 对于不按序到达的数据，TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付给上层的应用进程。 TCP要求接收方必须有累积确认的功能，这样可以减少传输快消。TCP标准规定，确认推迟的时间不应超过0.5秒。 选择确认SACK
在收到的报文无差错，只是未按序号，中间还缺少一些序号的数据的情况下，选择确认就是用于只传送缺少的数据而不重传已经正确到达接收方的数据。
SACK向发送方报告收到的不连续的字节块边界，由于首部选项长度最多只有40字节，而指明一个边界就要用掉4字节(32位序号)。然而SACK文档并没有指明发送方应当怎样响应SACK。因此大多数的实现还是重传所有未被确认的数据块。

七、TCP的流量控制

利用滑动窗口实现流量控制
当发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。所谓流量控制(flow control)就是让发送方的发送速率不要太快，要让接收方来得及接收。
下面的例子展示了如何通过滑动窗口机制在TCP连接上实现对发送方的流量控制。

如图5所示，seq是数据报文段的序号。ACK表示的是首部确认位，ack表示确认字段的值，只有ACK=1，ack才有意义。B通过不断控制自己的接收窗口大小实现流量控制，因为发送方的发送窗口不能超过接收方给出的接收窗口的数值。当接收窗口数值为0时，发送方暂停发送直到接收方重新发出一个新的窗口值为止。
现在有一种情况是当接收方有了缓存空间，所以向发送方发送了rwnd=400(rwnd表示receiver window)的报文段，然而该报文段丢失了，此时发送方一直等待接收方的非零窗口通知，接收方一直等待发送方的数据，造成了死锁。
为了解决这种情况，TCP为每一个连接设置一个持续计时器(persistence timer)，当连接的一方收到对方的零窗口通知就启动持续计时器。若持续计时器设置的时间到期，就发送一份零窗口探测报文段，而对方就在确认这个探测报文段时给出当前的窗口值。若窗口仍然是零，那么收到报文段的一方就重新设置持续计时器，否则就可以重新发送数据了，这就打破了死锁。 必须考虑传输效率
TCP发送报文段的时机
应用进程把数据传送到TCP的发送缓存后，剩下的发送任务就由TCP控制。TCP报文段的发送控制有多种机制，如(1) TCP维持一个变量，等于最大报文段长度MSS，只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去；(2) 由发送方的应用进程指明要求发送报文段，即TCP支持的推送(push)操作；(3) 发送方的一个计时器时限到了，就把当前已有的缓存数据装入报文段(长度不能超过MSS)发送出去。
虽然有这么多的机制，但是TCP发送报文段的时机仍让是一个比较复杂的问题。
在TCP的实现中广泛使用Nagle算法，若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存，则发送方先把第一个数据字节发送出去，把后面到达的数据字节都缓存起来，当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段(避免发送过多的小报文，极端情况如逐字节发送)。当数据到达较快而网络速率较慢时，这样的方法可明显减少所用的网络带宽。Nagle算法还规定，当到达的数据已达到发送窗口大小的一半或者已达到报文段的最大长度时，就立即发送一个报文段。 糊涂窗口综合症(silly window syndrome)
糊涂窗口综合症有时也会使TCP的性能变化。设想一种情况：TCP接收方的缓存已满，而交互式的应用进程一次只从接收缓存中读取一个字节(使得接收缓存每次仅仅腾出1个字节)，然后向发送方发送确认，并把窗口设置为1个字节，接着发送方又发来一个字节的数据。接收方发回确认，仍然将窗口设置为1个字节，这样进行下去，使得网络的效率很低。
解决这个问题，可以让接收方等待一段时间，使得接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲空间。直到出现这两种情况之一，接收方就发出确认报文，并通知发送方当前的窗口大小。另外，发送方也不要发送太小的报文段，而是把数据积累成足够到的报文段，或达到接收方缓存空间的一半大小。

八、TCP的拥塞控制

拥塞控制的一般原理
拥塞(congestion)：对网络中某一资源(带宽、交换节点中的缓存和处理机等等)的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。
拥塞并不是简单的增加一些资源就能解决的，增加资源有时会使得情况更糟，比如简单的增加缓存由于处理速度慢会导致绝大多数分组的排队等待时间大大增加，最终超时重传。而拥塞引起的重传并不会缓解网络拥塞，反而会加剧网络的拥塞。
拥塞控制与流量控制关系密切但也不尽相同。拥塞控制是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有主机、路由器等等与降低网络传输性能有关的因素。相反，流量控制往往指点对点通信量的控制，是个端对端的问题。

几种拥塞控制方法
RFC 2581定义了进行拥塞控制的四种算法，即慢开始(slow-start)、拥塞避免(congestion avoidance)、快重传(fast retransmit)和快恢复(fast recovery)。
在讨论以下问题时，为了方便起见假定：(1) 数据单方向传送，另一个方向只传送确认；(2)接收方的缓存足够大，因而发送窗口的大小由网络拥塞程度决定。

慢开始和拥塞避免
发送方维持一个拥塞窗口cwnd(congestion window) 的状态变量，拥塞窗口的大小取决于网络的拥塞程度动态变化，发送方让自己的发送窗口等于拥塞窗口。
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便发送更多的分组，只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。只要发送方没有按时收到应当到达的确认报文，就可以猜想网络可能出现了拥塞。
慢开始算法的思路是：当主机开始发送数据时，如果立即把大量数据字节注入到网络，由于并不清楚网络的负荷情况，所以有可能引起引起网络拥塞。经验证明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，即由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，把拥塞窗口cwnd设置成一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。
在使用慢开始算法后，每经过一个传输轮次(transmission round)，拥塞窗口cwnd加倍。一个传输轮次所经历的时间其实就是往返时间RRT，传输轮次强调的是把拥塞窗口cwnd所允许发送的报文段都连续的发送出去，并收到了对已发送的最后一个字节的确认。(例如，拥塞窗口cwnd的大小是四个报文段，那么此时的往返时间RTT就是发送方连续发送4个报文段，并收到这4个报文段的确认总共经历的时间)。
为了防止拥塞窗口cwnd增长过大引起的网络拥塞，还需要设置一个慢开始门限ssthresh状态变量：
当cwnd < ssthresh时，使用慢开始算法；
当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法；
当cwnd=ssthresh时，算法二选一。
拥塞避免算法的思路是让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是翻倍。这样拥塞窗口按线性规律缓慢增长。
无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞(其根据就是没有按时收到确认)，就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半(但不能小于2)，然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的是迅速减少主机发送到网络中的分组数，使得发送拥塞的路由器有足够的时间把队列中积压的分组处理完毕。注意拥塞避免只是使网络比较不容易出现拥塞，并非完全避免。
图6展示了慢开始算法和拥塞避免控制的过程，现在的发送窗口大小和拥塞窗口大小一致。

“乘法减小”(Multiplicative Decrease)表示不论在慢开始阶段还是拥塞避免阶段,只要出现超时(即很有可能出现了网络拥塞)，就把慢开始门限值ssthresh减半(与此同时，执行慢开始算法)。当网络频繁出现拥塞时，ssthresh值就下降得很快，以大大减少注入到网络中的分组数。
“加法增大”(Additive Increase)是指执行拥塞避免算法后，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。上面两种算法合起来常常称为AIMD算法。 快重传和快恢复
快重传：在不使用快重传时，发送方在设置的超时计时器已到还没有收到确认时，就认为网络出现拥塞，TCP马上把拥塞窗口cwnd减小到1，并执行慢开始算法，同时将ssthresh减半。
而快重传算法要求接收方每收到一个失序的报文段就立即发出重复确认(使发送方及早知道有报文段未到达)，而不是等待到自己发送数据是才捎带确认。
举例：M1, M2, M3, M4, M5, M6, … 是按序的报文段，接收方在收到了M1, M2 后就收到了M4，按照可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。按照快重传算法，接收方应及时发送对M2的重复确认，这样发送方可以及早知道报文段M3未到达，发送方接着发送M5和M6。接收方收到后，也要再次发出对M2重复确认。这样发送方收到了4个对M2的确认，后三个都是重复确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文M3，而不必继续等待为M3设置的重传计时器到期。由于发送方尽早重传未被确认的报文段，大大提高了网络吞吐量(提升约20%)。
快恢复：与快重传配合使用，其过程有两个要点：(1) 当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢开始门限ssthresh设置为当前窗口值的一半，预防网络发生拥塞；(2) 由于发送方现在认为网络很有可能没有发生拥塞(若拥塞就不会一连有好几个报文段到达接收方，导致接收方连续发送重复确认)，因此与慢开始不同之处是现在不执行慢开始算法(即拥塞窗口cwnd现在不设为1)，而是把cwnd值设置为当前的慢开始门限ssthresh值，然后开始执行拥塞避免算法(“加法增大”)，使拥塞窗口缓慢地线性增大。
添加了快重传和快恢复的TCP拥塞处理版本如图7所示，这是目前使用很广泛的版本，TCP Tahoe版本是已经废弃不用的版本。

注意此处在讨论拥塞控制时前提是接收方缓存空间足够大，这在实际上是不存在的，发送方的发送窗口的上限值是接收方窗口rwnd和拥塞窗口cwnd这两个变量中较小的一个。

九、TCP的运输连接管理(三次握手和四次挥手)

运输连接有三个阶段，即：连接建立、数据传送和连接释放。运输连接的管理就是使运输连接的建立和释放都能正常进行。TCP连接的建立采用客户服务器方式。主动发起连接建立的应用进程叫做客户(client)，而被动等待连接建立的应用进程叫做服务器(server)。

TCP连接建立(三次握手)
如图8所示，主机A运行的是TCP客户程序，而B运行的是TCP服务器程序。最初两端的TCP进程都处于CLOSED(关闭)状态。注意A主动打开链接，而B被动打开连接。

主机A向主机B发出连接请求报文段，此时首部的同步位SYN=1，同时选择一个初始序号seq=x。TCP规定，SYN报文段不能携带数据，但消耗一个序号。
主机B收到连接请求报文段，如同意建立连接，则向主机A发送确认。在确认报文段中应把SYN位和ACK位都置1，确认号为x+1，同时也为自己选择一个初始序号seq=y。
TCP客户进程收到B的确认后，还要向B确认，确认报文段ACK置1，确认号ack=y+1，而自己的序号为seq=x+1。TCP标准规定，ACK报文段可以携带数据，但如果不携带数据则不消耗序号。
上面给出的连接建立过程叫做三次握手(three-way handshake)，或三次联络。
主机A还要发送一次确认主要是为了防止已失效的连接请求报文段突然又传送到了B，因而导致错误和资源浪费。 TCP连接释放
如图9所示，数据传输结束后，通信双方都可释放连接，此处主机A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。

A把连接释放报文段首部的FIN置1，其序号seq=u，它等于前面已传送过的数据的最后一个字节的序号加1。TCP规定，FIN报文段即使不携带数据，也消耗掉一个序号。
B收到连接释放报文段后即发送确认，确认号是ack=u+1，而这个报文段自己的序号是v，等于B前面已传送的数据的最后一个字节的序号加1。TCP服务器进程此时应该通知高层应用进程，因而从A到B这个方向的连接就释放了。此时TCP连接处于半关闭(half-close) 状态，A已经没有数据要发送了，B仍然可以发送数据给A，A仍然接收，也就是B到A这个方向的连接并未关闭。
A收到来自B的确认后，等待B发出的连接释放报文段。
若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN=1。现假定B的序号为w(在半关闭状态B可能又发送了一些数据)。B还必须重复上次已经发送过的确认号ack=u+1，等待A的确认。
A在收到B的连接释放报文段后，必须对此发出确认，在确认报文段ACK置1，确认号ack=w+1，而自己的序号为seq=u+1。
注意此时TCP连接还未释放掉，必须经过 时间等待计时器(TIME-WAIT timer)设置的时间2MSL后，A才进入CLOSED状态。时间MSL叫做最长报文段寿命(Maximum Segment Lifetime)。设置这个等待时间的原因有二：(1) 保证A发送的最后一个ACK报文段能到达B(报文可能丢失)；(2) 等到本连接持续的时间内所产生的所有报文段都从网络中消失，防止“已失效的连接请求报文段”在下一个连接出现。
TCP还设有保活计时器(keepalive timer)，若两个小时没有收到客户的数据，服务端就发送一个探测报文，以后则每隔一段时间发送一次，若一连发送10个探测报文段后仍无客户响应，服务器就认为客户端出现故障，接着就关闭这个连接。