计算机网络原理第五篇 运输层

第五章. 运输层

5.1、运输层协议概述

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

从IP层角度看，通信两端是两个主机（因为：IP数据报首部写的是主机IP地址），而两个主机进行通信实际上就是两个主机中的应用进程互相通信。

从运输层角度看，通信的真正端点是主机的应用进程，所以这种应用进程之间的通信称之为“端到端的通信”。

1、运输层的两个重要功能：
⑴、运输层第一个重要功能——通过复用和分用技术为应用进程之间提供端到端的逻辑通信。

“逻辑通信”的意思是：运输层之间的通信好像是沿水平方向传送；即：应用进程看见的是用户数据好像在两个运输层实体之间的端到端逻辑通信信道中传输。但事实上这两个运输层之间并没有一条水平方向的物理连接，这样运输层向高层用户屏蔽了下面网络核心部分的通讯细节（如网络拓扑、所采用的路由选择协议等）。

复用——指的是发送方不同的应用进程都可以使用同一个运输层协议传送数据。
分用——指接收方的运输层剥去报文首部后能够把这些数据正确地交付到目的应用进程。
这是因为：一个主机可能有多个应用进程同时和另一台主机的多个应用进程通讯。比如，用户浏览网页的同时用电子邮件给同一网站发送信息，此时用户运行的浏览器客户进程AP1和电子邮件客户进程AP2分别与网站运行的浏览器服务进程AP3和电子邮件服务进程AP4之间同时进行通讯（如下图所示）。

⑵、运输层第二个重要功能——对报文进行差错检测。
网络层只对IP数据报首部进行检查，而不检查数据部分。
运输层对报文（包含本层添加的首部和应用层用户的数据部分）进行差错检验。

5.1.2、运输层的两个主要协议——TCP协议和UDP协议

1、运输协议数据单元TPDU (Transport Protocol Data Unit) è是指两个对等运输实体在通信时传送的数据单位。
⑴、TCP 传送的数据单元——TCP报文段；
⑵、UDP 传送的数据单元——UDP 报文 或 用户数据报。
2、TCP/IP 协议体系中的运输层协议

⑴、传输控制协议 TCP（Transmission Control Protocol）—— TCP提供可靠的、面向连接的服务，开销较大。TCP在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或者多播服务。
⑵、用户数据报协议 UDP（User Datagram Protocol）—— UDP提供不可靠的、无连接的服务，开销较小。UDP 在传送数据之前不需要先建立连接。对方的运输层在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 是一种最有效的工作方式。

强调解释 ：
①.当运输层采用面向连接的 TCP 协议时，TCP 报文段是在运输层抽象的端到端逻辑信道中传送，尽管下面的网络是不可靠的（只提供尽最大努力服务），这种逻辑信道就相当于一条全双工的可靠信道，逻辑信道不知道究竟经过了哪些路由器，而这些路由器也根本不知道上面的运输层是否建立了 TCP 连接。
②.当运输层采用无连接的UDP协议时，这种逻辑通信信道是一条不可靠信道。运输层的 UDP 用户数据报与网际层的IP数据报有很大区别。IP 数据报要经过互连网中许多路由器的存储转发，但 UDP 用户数据报是在运输层的端到端抽象的逻辑信道中传送的。

3、运输层协议和网络层协议的主要区别
运输层的TCP 和 UDP 协议为进程之间提供逻辑通信；
网络层的IP 协议为主机之间提供逻辑通信。

5.1.3、运输层的端口

1、端口的概念——计算机中的进程是用进程标识符来标志的。为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须用统一的方法对 TCP/IP 体系的应用进程进行标志。解决这个问题的方法就是在运输层使用协议端口号(protocol port number)，或通常简称为端口(port)。

特别注意 ：①.在协议栈各层之间抽象出的协议端口是软件端口。而路由器或交换机上的端口是硬件端口。硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层的各种协议进程与运输层的运输实体之间进行层间信息交互的地址，它是一个16位标识符。②.两个计算机中的进程要相互通信，不仅要知道对方的IP地址，而且要知道对方的端口号。

2、端口号的分类——运输层端口号分两类三种：
⑴、服务器端口使用的端口号——①.熟知端口号（系统端口号）：0－1023
②.登记端口号：1024－49151
⑵、客户端端口使用的端口号——③.49152－65535

说明：
①.熟知端口号由IANA固定地指派给TCP/IP的应用程序，查询网址：www.iana.org；
②.登记端口号是给没有熟知端口号的应用程序使用的，使用时必须在 IANA 登记，以防重复；Internet Assigned Numbers Authority（IANA互联网编号分配机构）。

5.2、用户数据报协议UDP

5.2.1、UDP概述

UDP只在IP 的数据报服务之上增加了端口功能（复用与分用功能）和差错检测功能。虽然 UDP 用户数据报只能提供不可靠的交付，但也有某些特殊优点。
1、UDP的主要特点：
⑴、无连接——即发送数据之前不需要建立连接；
⑵、尽最大努力交付——即不保证可靠交付；
⑶、面向报文——发送方UDP对应用进程交下来的报文不合并、不拆分，添加首部后就向下交付 IP 层，一次发送一个完整的报文；接收方 UDP 对 IP 层交上来的 UDP 用户数据报去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文。
⑷、无拥塞控制——因为很多实时应用要求原主机发送速率恒定；
⑸、支持一对一、一对多、多对一、多对多交互通信；
⑹、首部开销小——TCP首部为20字节，而UDP首部只有8字节。

2、UDP用户数据报的结构：

5.2.2、UDP的首部格式（首部长度为8个字节）

⑴、源端口——源端口号，在需要对方回信时选用，不需要时全0；
⑵、目的端口——在终点交付报文时必须用到；
⑶、长度——UDP数据报长度，最小值为8（仅首部）；
⑷、检验和——检测UDP用户数据报传输中是否出错，若有错，则丢弃数据报。

在计算UDP用户数据报中的检验和时，要在用户数据报前面临时加12字节的伪首部，计算完后丢弃伪首部，即伪首部既不上交也不下送；

UDP计算检验和的方法与IP数据报首部检验和的方法相似，不同的是IP数据报的检验和只检验数据报首部，但UDP把首部和数据部分一起检验；

接收方检验收到UDP用户数据报文有错或目的端口不正确时丢弃，并由ICMP发送“端口不可达”差错报文给发送方。

**【例题5.1】**计算UDP检验和，具体如下：

Ⅰ**.N个二进制数反码求和**的方法：
①. N个二进制数原码相加得到的结果为M位和S1；
②. 如果M>N,则把和S1的高M-N位截取下来与和S1的低N位相加得到和S2；
③. 把和S2的低N位按位取反得到结果N位和S3即可；
例如：

Ⅱ、IP/ICMP/IGMP/TCP/UDP等协议的校验和算法都是相同的，算法如下：
（1）在发送数据时，计算IP数据包的校验和应该按如下步骤：
①.把IP数据包的校验和字段置为0；
②.把首部看成以16位为单位的数字组成，依次进行二进制反码求和；
③.把得到的结果存入校验和字段中。

（2）在接收数据时，计算数据包的校验和按如下步骤：
①.把首部看成以16位为单位的数字组成，依次进行二进制反码求和，包括校验和字段；
②.检查计算出的校验和的结果是否等于零（反码应为16个1）；
③.如果等于零，说明被整除，校验是和正确。否则，校验和就是错误的，协议栈要抛弃这个数据包。

5.3、传输控制协议 TCP

5.3.1、TCP最主要特点

⑴、点对点通讯——每一条TCP连接只能有两个端口，只能是点对点的通讯；
⑵、可靠交付——无差错，不丢失，不重复，按序到达；
⑶、全双工通信——收发双方都有发送缓存和接受缓存；
⑷、面向连接——建立TCP连接（虚连接）、通讯、释放TCP连接；
⑸、面向字节流——划分报文，“流”是指流入到进程或从进程流出的字节序列。

面向字节流含义是：①.应用程序和TCP的交互是一次一个数据块，但TCP把数据块看成无结构的字节流；②.保证接收方应用进程收到的字节序列与发送方应用进程发送的字节序列一样，但不保证接数据块大小一样。

5.3.2、TCP连接

⑴、TCP 连接是一条虚连接而不是一条真正的物理连接，是一种最基本的抽象；
⑵、TCP 对应用进程一次把多长的报文发送到TCP 的缓存中是不关心的；
⑶、TCP发送的报文长度取决于发送窗口、接受窗口大小和网络拥塞程度（有专门的处理算法，而UDP由应用进程决定），数据块长了就划分、短了就等待积累；
⑷、TCP 连接的端点不是主机，不是主机的IP 地址，不是应用进程，也不是运输层的协议端口，而是套接字(socket)或插口，即把端口号拼接到(contatenated with) IP地址构成了套接字。
套接字 socket = （IP地址: 端口号）
每一条TCP连接唯一地被通信两端的两个端口点所确定{(IP1: port1), (IP2: port2)}
TCP 连接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}

5.4、可靠传输的工作原理

理想传输的两个特点
①.传输信道不产生差错；
②.不管发送方以多快速度发送数据，接收方总来得及接收。

5.4.1、停止等待协议（常称之为自动重传请求ARQ(Automatic Repeat reQuest)）

1、基本原理——发送方每发完一个分组就停止发送，等待对方确认，收到确认后再发送下一分组（发送分组和确认分组都无差错地按时到达，如上图(a)所示），发送方只要超过一段时间没有收到确认，就认为刚才发送的分组丢失了，因而重传，所以需要设置超时计时器。超时重传大体分以下三种情况。
⑴、发送分组出错——①.发送分组按时到达但出错了（丢弃）；②.发送分组到不了接收方；两种情况接收方都不发确认分组，如上图(b)所示；
⑵、发送分组无差错地按时到达，但确认分组丢失——如上图©所示，接收方会收到重复分组，接收方应丢弃这个重复的分组，不交付上层，再次发送确认；
⑶、发送分组无差错地按时到达，但确认分组超时到达——如上图(d)所示，接收方会收到重复分组，接收方应丢弃重复的分组，不交付上层，再次发送确认。

使用这种确认和重传机制，可在不可靠的传送网络上实现可靠的传输；实现时应该注意以下3点è
①.发送方发送完分组后，保留分组副本直至收到确认；
②.分组和确认分组必须编号；
③.超时计时器设置重传时间应当比数据在分组传输的平均往返时间长一些。

2、信道利用率——停止等待协议的优点是简单，但缺点是信道利用率太低。

TD ——发送分组的时间（精确计算时应扣除传送控制信息（如首部）的时间）；
RTT——信号在信道中的往返时间，它取决于信道；
TA——确认分组的接受时间(TA <TD) 。

上述公式的分母还应该包含接收方对信息的处理时间（很小而被忽略）；
∵RTT>> TD ∴信道利用率低，为了提高信道利用率采取流水线传输，这就需要连续ARQ协议和滑动窗口协议。

5.4.2、连续ARQ协议：

基本原理：发送方维持一个发送窗口，位于该窗口内的多个分组可连续发送，不必每发完一个分组就停顿下来等待对方的确认。接收方一般采用累积确认的方式，即不必对收到的分组逐个发送确认，而是对按序到达的、正确的最后一个分组发送确认，表示到这个分组为止的所有分组都已正确收到了。发送方重新发送确认以后的分组，这种重传机制叫“回退 N机制（go-back-N）”。

若中间分组丢失，即使后面分组均正确收到，接收方也只能对丢失分组之前的分组进行确认，发送方并不知道丢失分组后面的分组已正确接收，故从丢失分组起，重新发送。

累积确认的优点是：容易实现。缺点是：不能向发送方反映出接收方已经正确收到的所有分组的信息，可见，通信线路质量不好时，连续ARQ会带来负面影响。

TCP可靠传输的具体实现需要对连续ARQ协议进行改进（§5.5节详述）。

5.5、TCP 报文段的首部格式

1、源端口和目的端口——各2个字节；端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。
2、序号——4字节，TCP传输的字节流中每一个字节都按顺序编号，建立连接时必须设置起始序号。报文首部序号字段值指本报文段所发送数据第一个字节编号。
3、确认号——4B，期望收到对方下一报文第一数据字节序号。确认=N，表明到序号N－1为止所有数据都已正确收到。
4、数据偏移——4b，指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位是 32 位字（以 4 字节为计算单位）。
5、保留——占6位，保留为今后使用，但目前应置为 0。
6、紧急 URG——当 URG = 1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据）。
7、确认ACK——ACK=1时确认号才有效。
8、推送 PSH—— PSH =1时，表示尽快将该报文段推送出去，不用等缓冲区都填满才向上交付，很少用。
9、复位RST——当 RST = 1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。
10、同步SYN——在建立连接时同步序号。当SYN=1，ACK=0时，表明连接请求报文。若同意建立链接，则响应报文中SYN=1，ACK=1，因此SYN表示连接请求或连接接受报文。
11、终止FIN——FIN=1时，发送方数据发送完毕，请求释放连接。
12、窗口——占2B ，窗口值作为接收方让发送方设置其发送窗口的依据。明确指出现在允许对方发送的数据量，窗口值经常在动态变化着。
13、检验和——占2B，包括对首部和数据两部分的检验，方法与UDP一样，只是伪首部第四个字段17改为36。
14、紧急指针——占2B ，仅在URG=1时有意义，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。
15、选项——长度可变，最长40B，无选项时TCP首部20B。
⑴、MSS——每一个TCP报文段数据字段最大长度；
MSS应尽可能大些，只要在IP层不要分片就行。
⑵、SACKè选择确认。
⑶、时间戳
①.计算往返时间RTT{从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延}；
②.处理TCP序号超过232 的情况。

16、填充——确保TCP首部总长度字节数为4的整数倍。

5.6、TCP 可靠传输的实现

TCP 可靠通信的特征：
1、TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。
2、TCP 的可靠传输机制用字节的序号进行控制——TCP 确认都是基于字节序号，而不是基于报文段。
3、TCP 两端的四个窗口经常处于动态变化之中。
4、TCP连接的往返时间 RTT 也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。
为讲述方便，我们假定数据传输只在一个方向进行。

5.6.1、以字节为单位的滑动窗口协议

TCP滑动窗口是以字节为单位的。

1、发送窗口——可连续发送的字节范围，通常只是发送缓存的一部分；在没有收到对方确认的情况下，发送方可连续把窗口中的数据都发送出去。凡是已经发送过的数据，在未收到确认之前必须暂时保留，以便超时重传。

⑴、发送窗口的后沿——后面部分表示已经发送且已接收到确认。
发送窗口的后沿的两种变化情况：
①.前移——收到新的确认；
②.不动——没有收到新的确认，并且对方通知的窗口大小没变；
收到新的确认，但对方通知的窗口大小缩小了使得前沿正好不动。
⑵、发送窗口的前沿è前面部分表示不允许发送。
⑶、前沿与后沿共同确认发送窗口的位置。
⑷、后沿不可能后移，前沿不断前移，也可能不动。
⑸、TCP不赞成前沿向后回缩（由于B通知的窗口大小缩小了而需要前沿回缩）。
⑹、描述发送窗口状态需三个指针：P1、P2、P3。
①.小于P1的表示已发送并已接收到确认的部分；
②.大于P3的是不允许发送的部分；
③.P3－P1=发送方A的发送窗口；
④.P2－P1=已发送但尚未收到确认的字节数；
⑤.P3－P2=允许发送但尚未发送的字节数。

2、发送缓存用来存放以下数据：
①.发送应用程序传给发送方TCP准备发送的数据；
②.TCP已发送但尚未收到确认的数据。
发送缓存与发送窗口后沿重合。

3、接收窗口——可连续接收的字节范围，通常只是接收缓存的一部分。
4、接收缓存用来暂时存放以下数据：
①.按序到达的，但尚未被接收应用程序读取的数据；
②.不按序到达的数据。

【例题5.2】TCP可靠传输的具体实现的实例——滑动窗口协议：
①.假设：某一时刻A的发送窗口和B的接收窗口如下图所示，接收窗口和发送窗口大小为20B不变；由于B只能对按序收到的数据中的最高序号给出确认，此时虽然正确地收到32和33号报文，但没收到31号报文，所以B发送的确认报文中的确认号为31（即期望收到31号报文），32和33号报文存储在B的缓存中等待31号报文；

②.A收到确认号为31号的确认报文后停止发42号报文而重传缓存中的31号报文；重传后继续发送42以后的报文直至发送窗口前沿；
③.当B正确地收到31号报文后把31—33号报文交给主机并从缓存中删除，然后发送确认号为34号的新确认报文；同时B的接收窗口后沿移到34，前沿移到54并继续接收报文；
④.A收到确认号为34号的新确认报文后把发送窗口后沿移到34，前沿移到54，从发送缓存中删除33号以前的报文，并继续发送42以后未发送的报文直至发送窗口前沿；（如下图所示）

⑤.若A的发送窗口已满（即可用窗口为0）就停止发送数据，等待新的确认（如下图所示）；若此后收到新的确认（假设确认号为41），则重传41号报文，并把接收窗口后沿移到41，前沿移到61，从发送缓存中删除40号以前的报文，并继续发送53以后未发送的报文直至发送窗口前沿；如此循环直至B接收完数据。

5、注意三点
①.发送窗口并不总是与接收方的接收窗口一样大；
②.TCP标准并未规定对不按序到达的数据如何处理，通常做法是临时存在接收窗口，等缺少的字节到达后再按序交付上层应用程序；
③.TCP要求接收方必须有累积确认功能，以减少传输开销，接收方有数据要发送时可捎带确认，但累积的时间不应该超过0.5秒。

5.6.2、超时重传时间的选择

TCP 每发送一个报文段，就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。TCP超时计时器的超时重传时间究竟应设置多大呢？
1、TCP采用了一种自适应算法
TCP保留了RTT的一个加权平均往返时间RTTs，第一次测量的RTT样本值作为RTTs的初始值，以后每测到一个RTT样本，就按下式重新计算一次RTTs：
式中，0 £ a < 1。若 a 很接近于零，表示 RTT 值更新较慢。若选择 a 接近于 1，则表示 RTT 值更新较快。RFC 2988 推荐的 a 值为 1/8，即 0.125。
超时重传时间RTO略大于RTTs，使用下式计算：

RTTD是 RTT 的偏差的加权平均值，第一次测量RTTD为RTT样本值的一半，以后按下式计算：
b 是个小于 1 的系数，其推荐值是 1/4，即 0.25。

2、Karn方法和改进的Karn方法
问题 ： 若重传时间到了，但仍未收到确认，于是重传报文，经过一段时间后，收到确认，此时如何判断此确认报文是对先前发送的报文确认，还是对以后重传报文的确认？方法如下：

⑴、Karn的方法——在计算RTTs时，只要报文重传了，就不采用其往返时间样本；
这样得到的加权平均RTTs和RTO就比较准确。但这引起新的问题，即若报文段时延增大了很多，超时重传时间无法更新，使重传次数增多。

⑵、改进的Karn方法——报文段每重传一次，把RTO增大一些。
新的 RTO = g ´（旧的RTO) è{系数 g 的典型值是 2}

5.6.3、选择确认SACK

1、问题的提出 ：接收方收到了和前面的字节流不连续的两个字节块，这些字节的序号都在接收窗口之内，接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方只发中间未收到的数据块而不要再重复发送这些已收到的数据，如何实现？

2、问题的解决办法 ：RFC2018的规定：
⑴、如果要使用选择确认，那么双方必须都事先商定好在建立 TCP 连接时，就要在TCP 首部的选项中加上“允许 SACK”的选项。
⑵、原来首部中的“确认号字段”的用法仍然不变。只是以后在 TCP 报文段的首部中都增加了 SACK 选项，以便报告收到的不连续的字节块的边界。
⑶、由于首部选项的长度最多只有 40 字节，而指明一个边界就要用掉 4 字节，因此在选项中最多只能指明 4 个字节块的边界信息，32B，还需一个字节指明是SACK选项，一个字节指明这个选项占多少字节。
⑷、SACK文档并未指明发送方应当怎样响应SACK，因此，大多数的实现还是重传所有未被确认的数据块。

5.7、TCP 的流量控制

5.7.1、利用滑动窗口实现流量控制

流量控制——就是让发送方的发送速率不要太快，要让接受方来得及接收。
利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制。

【例题5.2】流量控制举例（注意：TCP窗口单位是字节，不是报文段）。
设A向B发送数据，每个报文段长100B，建立连接时B告诉A其接受窗口rwnd=400B，因此，发送方的发送窗口不能超过接收方给出的接受窗口的数值。数据报文段序号初始值seq=1，大写ACK表示首部中的确认位，小写ack表示确认字段值。

考虑A接受B的零窗口通知后，一直等B放入非零窗口通知，但非零窗口也有可能丢失，这时会出现死锁。为解决该问题，TCP为每个连接设一个持续计时器，只要发送方收到对方0窗口通知，就启动持续计时器，若持续时间到零，就发送一个0窗口回测报文段，而对方就在确认这个探测报文段时给出了现在的窗口值。
若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器；若窗口不是零，则死锁的僵局就可以打破了。

5.7.2、必须考虑传输效率

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

2、NAGLE算法——在TCP的实现中广泛使用的算法
⑴、发送方把第一个字节先发送出去，收到第一个字节确认后，再把缓存中所有数据组装发出。
⑵、当到达的数据已达到发送窗口大小一半或已达到MSS时，立即发送一个报文段。

3、糊涂窗口综合症——接受窗口已满，应用程序一次只从接受缓存中读取1B，然后向发送方发送确认，并把接收窗口设为1B，这样进行下去，网络效率很低。

解决方法——接受方等待一段时间，接受缓存已达MSS或有一半空闲时确认。

5.8、TCP 的拥塞控制

5.8.1、拥塞控制的一般原理

1、拥塞——在某段时间，若因网络中某一资源求大于供，网络性能变坏的现象。
2、网络拥塞的原因——往往由多种因素引起的，如缓存不足出现丢包，即使缓存足够大，又会因排队时间过长使上层软件重传数据包。又如提高处理机速度，虽可缓解拥塞情况，但又会使瓶颈转移到别处。
拥塞引起的重传不会缓解拥塞，反而会加剧拥塞。

3、拥塞控制——就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不至过载。

4、拥塞控制和流量控制的比较
⑴、拥塞控制的前提是网络能够承受现有的网络负荷。它是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。
⑵、流量控制往往指在给定的发送端和接收端之间的点对点通信量的控制。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

5、拥塞控制的原理 ——拥塞控制很难设计，它是动态的问题。
⑴、开环控制——设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞，但一旦整个系统运行起来，就不再进行改正。
⑵、闭环控制——基于反馈环路概念，有以下几种措施：
①.监视网络系统，以便检测到拥塞在何时何处发生。
②.把拥塞控制信息传送到可采取行动的地方。
③.调整网络系统的运行以解决出现的问题。

6、检测网络拥塞的指标——由于缺少缓存而丢弃分组的百分数、平均队列长度、超时重传分组数、平均分组时延等。
检测到拥塞发生时，一般将拥塞信息发送到产生分组的源站，但通知拥塞发生的分组会使网络更加拥塞。解决的方法主要有：①.在路由器转发的分组中保留一个比特或字段用以标示有没有产生拥塞；②.主机或路由器周期性地发送拥塞探测分组。

5.8.2、TCP的几种拥塞控制方法è①.慢开始和拥塞避免；②.快重传和快恢复。

为讨论拥塞控制方便，我们假定：
①.数据是单方向传送，而另一个方向只传送确认。
②.接收方有足够大缓存，因而发送窗口大小由拥塞程度来决定。

1、慢开始和拥塞避免

⑴、基本思想 ; 发送方维持一个叫做拥塞窗口cwnd的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地变化。发送方让自己的发送窗口等于或小于拥塞窗口。发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
⑵、发送方如何知道网络中发生拥塞？
只要发送方没有按时收到应当到达的确认报文，就可以猜想网络中可能出现了拥塞。
⑶、慢开始算法_发送方刚开始发送报文时，先把拥塞窗口设置为一个MSS的数值（即:cwnd = 1），每收到一个确认，拥塞窗口增加至多一个MSS（即:cwnd = cwnd +1）。
为方便起见，我们用报文段的个数作为窗口大小的单位，这样可用较小的数字来说明原理（实际上TCP窗口以字节为单位）。
一开始发送方先将拥塞窗口cwnd设置为1，发送一个报文段M1后，收到M1的确认，发送方将cwnd设置为2，于是可发送M2、M3，每收到一个确认，拥塞窗口加1，若M2、M3的确认都收到后，窗口变为4，这时可发送M4、M5、M6、M7四个报文段。因此，每经过一个传输轮次，拥塞窗口cwnd加倍。
为防止cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限状态变量ssthresh。使用如下：
当cwnd<ssthresh时，使用上述慢开始算法；
当cwnd>ssthresh时，改用拥塞避免算法；
当cwnd=ssthresh时，即可用慢开始算法也可用拥塞避免算法。

⑷、拥塞避免算法——每经过一个传输轮次，cwnd加1

①.无论是慢开始还是拥塞避免阶段，只要发送方判断网络出现拥塞，就把ssthresh置为出现拥塞时发送窗口的一半(但不小于2)。然后拥塞窗口cwnd重新置1，执行慢开始算法。
不考虑流量控制时，拥塞窗口与发送窗口一样大。
注意 ；拥塞避免并非指可以避免拥塞。
②.乘法减小与加法增大
乘法减小——是指不论在慢开始阶段还是拥塞避免阶段，只要出现一次超时(即出现一次网络拥塞)，就把慢开始门限值ssthresh设置为当前的拥塞窗口值乘以0.5。当网络频繁出现拥塞时，ssthresh值就下降得很快，以大大减少注入到网络中的分组数。
加法增大——是指执行拥塞避免算法后，在收到对所有报文段的确认后（即经过一个往返时间），就把拥塞窗口 cwnd增加一个 MSS 大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。
⑸、慢开始和拥塞避免应用实例：

①.当 TCP 连接进行初始化时，将拥塞窗口置为 1。图中的窗口单位不使用字节而使用报文段。慢开始门限的初始值设置为 16 个报文段，即 ssthresh = 16。
②.发送端的发送窗口不能超过拥塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我们假定接收端窗口足够大，因此现在发送窗口的数值等于拥塞窗口的数值。
③.在执行慢开始算法时，拥塞窗口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 的大小。

2**、快重传和快恢复**

⑴、快重复算法——首先要求接受方每收到一个失序的报文段后就立即发出确认，而不是等自己发送数据时捎带确认。发送方一连收到三个重复确认，就认为应当立即重传对方尚未收到的报文，不必等该报文的重传计时器到期。

⑵、快恢复算法——当发送方连续收到三个重复确认时，执行乘法减小，把慢开始门限减半，接下去不是执行慢开始算法；而是把cwnd设置为ssthresh减半后的值，然后开始执行拥塞避免算法。
发送窗口上限值=Min[ rwnd , cwnd ] ；（rwnd指接收窗口，cwnd指拥塞窗口）

5.8.3、随机早期检测RED(Random Early Detection)

路由器的队列通常按“先进先出“的规则来处理分组，由于队列长度是有限的，因此当队列满时，以后到达的分组将被丢弃，这叫尾部丢弃策略。

全局同步现象——尾部丢弃策略使得许多TCP连接在同一时间突然进入慢开始状态，在网络恢复正常后，通信量又突然增大很多，进而产生新一轮拥塞。
解决办法 ：随机早期检测RED措施。
RED算法要点
⑴、路由器的队列维持两个参数，即队列最小门限THmin和最大门限THmax。每当一个分组到达时，都先计算平均队列长度LAV。
⑵、若LAV < THmin，新到达分组进入队列排队。
⑶、若LAV > THmax，丢弃新到达的分组。
⑷、若THmin < = LAV < = THmax，按概率P丢弃分组。
这样可以让拥塞控制只在少数TCP连接上进行，因而可避免全局性拥塞控制。
THmin应足够大，以保证链路有较高利用率。THmax与THmin差也应足够大，经验证明，THmax=2THmin是合适的。若THmin设定不合适，RED也可以引发全局振荡。

5.9、TCP 的运输连接管理

1、 运输连接有三个阶段——即：建立连接、传送数据和释放连接。
2、 运输连接的管理è就是使运输连接的建立和释放都能正常地进行。
3、TCP连接过程要解决三个问题：
①.相互确认对方的存在；
②.协商一些参数；
③.分配资源，如缓存大小。
TCP连接的建立采取“客户—服务器”模式，主动发起连接建立的应用进程叫“客户(client)”，而被动等待连接建立的应用进程叫“服务器(server)” 。

5.9.1、TCP连接的建立

TCP通过三次握手建立连接过程如下

①.服务器处于监听（LISTEN）状态；
②.客户向服务器发送连接请求报文段：
SYN=1，SEQ=X 表明传送数据时的第一个数据字节的序号是seq = X；
进入同步已收到状态——第一次握手；
③.服务器收到连接请求报文段后，如同意，则向客户发送确认报文段：
SYN=1，ACK=1，SEQ=Y，ACK=X+1；è自己选择的序号seq = Y；
进入同步已收到状态——第二次握手；
④.客户向服务器发送
ACK=1,SEQ=X+1,ACK=Y+1è客户的 TCP 通知上层应用进程，建立了连接；
进入建立连接状态——第三次握手；
⑤.服务收到步骤④的信息后，通知其上层应用进程，建立了连接；
也进入连接建立状态。
上述步骤中，②和③客户与服务器各消耗一个序号，客户做步骤④的目的是为了防止失效的连接请求报文段又突然送到服务器，产生错误。

例如 、：；客户端先发送了一个连接请求，但该请求在网络中滞留时间太长，客户又重新发送一个连接请求，若新连接请求被服务器端接收后就建立连接，那么在该连接传输完数据后关闭，此时，先前的连接请求到达服务器，服务器将认为是一次新的请求，若不采用三次握手，服务器将与客户再次建立连接，但客户却不知道，服务器许多资源就浪费了。采用三次握手，服务器收不到客户的确认就知道客户没有请求建立连接。

5.9.2、TCP连接的释放

1、TCP连接的释放过程 —— 四次握手
起始情况：通信双方都处于连接状态。

令A表示客户端，B表示服务器。现A向B传送的数据已发送完，向其TCP连接发出释放报文段，主动关闭TCP连接，过程如下：

⑴、A→B：FIN=1,SEQ=Uè A进入FIN-WAIT-1状态(终止等待1)，等待B的确认；
⑵、B→A：ACK=1,SEQ=V,ACK=U+1èB进入CLOSE-WAIT（关闭等待）状态；
此时，从A到B方向的连接释放了，A不再发送数据，若B向A发送数据，A必须接收，TCP处于半关闭状态，转⑶；若B没有数据传送，其应用进程就通知TCP释放连接，转⑷；
⑶、A收到确认后进入终止等待2状态，B可以继续发送数据；
⑷、B→A：FIN=1，ACK=1，SEQ=W，ACK=U+1è B进入LAST-ACK（最后确认）状态；
⑸、A→B：ACK=1，SEQ=U+1，ACK=W+1后è进入TIME-WAIT(时间等待)状态；
⑹、B进入关闭状态，A等待一个2MSL时间后è A进入关闭状态,TCP连接释放。

2、为什么A要等待2MSL后关闭呢？（MSL——报文最长寿命）
①.为保证A的最后一个确认能到达B；
②.防止已失效的报文请求出现在本次连接中。
服务器每收到一次客户数据，还需要重置一个保活计时器，若一段时间未收到客户数据，就要探测客户是否出现故障。