网络学习/复习4传输层UDP/TCP(协议属性详解、主机间连接状态详解)

负责向两台主机中的进程之间的通信提供通用的数据传输服务

一、协议概述

1.1进程间的通信

复用和分用。这里的“复用“是指在发送方不同的应用进 程都可以使用 同一个运输层协议传送数据（当然需要加上适当的首部），而“分用”是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程

网络层为主机之间 的通信提供服务；网络层，IP数据报首部中的检验和字段，只检验首部是否出现差错而不检查数据部分。

运输层则在网络层的基础上，为应用进程之间的通信提供服务。运输层 还要对收到的报文进行差错检测；

运输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑 、所采用的路由选择协议等），它使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道

1.2 两个主要协议

1. 用户数据报协议UDP（无连接）
2. 传输控制协议TCP（面向连接）

UDP在传送数据之前不需要先建立连接。在收到UDP报文后，不需要给出任何确认。UDP不提供可靠交付，但UDP非常简单，在某些情况下UDP是一种最有效的工作方式。

TCP在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或多播服务。TCP要提供可靠的、面向连接的运输服务，不可避免地增加了许多的开销，如确认、流量控制、计时器以及连接管理等。这 不仅使协议数据单元的首部增大很多，还要占用许多的处理机资源。

1.3端口

通信不仅需要知道端口号还需要知道IP地址

在协议栈层间 的抽象的协议端口是软件端口，和路由器或 交换机上的硬件端口是完全不同的概念。硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层的 各种协议进程与运输实体进行层间 交互的地点。不 同的系统具体实现端口的方法可以是 不同的（取决于系统使用的操作系统）。

 TCP/IP的运输层用一个16位端口号来标志一个端口。但请注 意，端口号只具有本地意义 ，它只是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口。在互联网不同计算机中，相同的端口号是没有关联的。16位的端口号可允许有65535个不同的端口 

服务器端使用 的端口 号 分为两类，最重要的一类叫作熟知端口号 或全球通用端口号，数值为0~1023。 IANA把这些熟知端口号指派给了TCP/IP最重要的一些应用程序，让所 有的用户都知道。当一种新的应用程序出现后，IANA必须为它指派一个熟知端口 ，否则互联网上的其他应用进 程就无法和它进行通信。和电话通信对 比，熟知端口号相当 千所有人都应知晓的重要 电话号码，如报警 电话110,急救电话120等。

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

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

1,0

二、用 户数据报协议UDP

在IP数据报的基础上添加了复用和分用、差错检测

2.1UDP概述

1. 无连接：发送之前不需要建立连接
2. 使用尽最大努力交付：不保证可靠交付
3. 面向报文：一次传送完整的报文
4. 没有拥塞控制：网络拥塞不会使主机发送降低，虽然某些实时应用需要使用没有拥塞控制的UDP,但当很多的源主机同时都向网络发送高速率的实时视频流时，网络就有可能发生拥 塞，结果大家都无法正常接收。因此，不使用拥塞控制功能的UDP有可能会引 起网络产 生严重的拥塞问题。
5. 支持一对一、一对多、多对一、多对多
6. 首部开销小，只有8个字节

2.2UDP首部格式

检验和：
首先UDP有一个伪首部，这个是IP的信息

IP数据报的检验和只检验IP数据报的首部，但UDP的检验和是把首部和数据部分—起都检验 。

检验和一开始为0

然后，每16位（包括伪首部、首部、用户数据报，分成一份份16位）按二进制反码运算求和
先求和。若UDP用户 数据报的数据部分不是偶数个字节，则要填 入一个全零字节（但此字节不发送）。最后再取反

然后接受方把收到的UDP用户数据报连同伪 首部（以及可能的填充全零字节）一起，按二进制反码求这些16位字的和 。无差错就是相加结果为全1，否则就是有差错

三、TCP传输控制协议

3.1主要特点

(1)面向连接。应用程序必须先建立TCP连接。传送完毕必须释放已经建立的TCP连接。

(2)每一条TCP连接只能有两个端点，只能是点对点的（一对一）。

(3) 提供可靠交付。通过TCP连接传送的数据，无差错 、不丢失 、不重复，并且按序到达。

(4)全双工。允许通信 双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临 时存放双向通信的数据。在发送时，应用程序在把数据传送给TCP的缓存后，就可以做 自己的事，而TCP在合适的时候把数据发送出去。在接收时，TCP把 收到的数据放入缓存，上层的应用进程在合适的时候读取缓存中的数据。

(5)面 向字节流。TCP中的“流”指的是 流入到进程或从进程流出 的字节序列。“面向字节流”的含义是：虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。TCP并不知道所传送的字节流的含义。TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系，但接收方应用程序 收到的字节流必须和发送方应 用程序发出的字节流完 全一样。当然，接收方的应用程序必须有能力识 别收到的字节流，把它还原成有意义的应用层数据。

TCP不关心应用进程一次把多长的报文发送给TCP缓存，TCP根据窗口值和网络拥塞程度，决定报文段包含多少字节，应用进程传送到TCP缓存的数据块太长，TCP就可以把它划分为短一些的数据块 再传送。如果应用进程一次只发来一个字节，TCP也可以等待积累足够多的字节后再构成报文段发送出去。

3.2TCP的连接

TCP把连接作为最基本的抽象，许多特 性都与面向连接的这个基本特性有关。

TCP连接的端点叫作套接字或插口 。

端口号拼接到IP地址即构成了套接字。因此，套接字的表示方法是在点分十进制的IP地址后面写上端口号，中间用冒号或逗号隔 开。

TCP连接就是两个套接字socket1和socket2之 间的连接。

TCP连接就是 由协议软件所提供的一种抽象。虽有时为了方便也可以说，一个应用进程和另一个应用进程之 间建立了一条 TCP连接，但一定 要记住：TCP连接的端点 是个很抽象 的套接字 ，即(IP地址：端 口号）。同一个 IP地址可以有多个不同的TCP连接，而同一个端口号也可以出现在多个不同的TCP连接。

（套接字socket是个很抽象的概念 ）

3.3可靠传输的原理

IP层只能提供尽最大努力服务，也就是说，TCP下面的网络所提供的是不可靠的传输。

1、停止等待协议

全双工通信的双方都是发送方（A）也是接收方（B），就是每发送完一个分组就停止发送，等待对方确认。

（1）无差错情况
A发送了数据，收到B的确认返回

（2）出现差错
A超过一段时间依然没有收到确认，就认为刚才发送的丢失了，重新发送这就是超时重传 

三点：A发送完，要保存副本
分组和确认分组要进行编号
超时重传时间比平均往返时间长一点   重传时间的准确设定是非常复杂的，这 是因 为已发送出的分组到底会经过哪些网络，以及这些网络将会产生多大的时延（这取决千这些网络当时的拥 塞情况），这 些都是不确定因素。

（3）确认丢失和确认迟到
确认丢失，就是B发送的确认信息，丢失了
处理：B丢失A重复发来的分组，继续向A发送确认

确认迟到
就是B的确定来迟了，A超时重发了

处理：B丢弃重复分组并重传确认，A收下这个确认但什么都不做

如果A不断重传分组但总是收不到确认，就 说明通信线路太差，不能进行通信。使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。像上述的这种可靠传输协议常称为自动重传请求ARQ。意思是重传的请求是自动进行的，因 此也可见到自动请求重传这样的译名 。接收方不需要请求发送方重传某出错的分组。

（4）信道利用率     发送时间/(发送时间+往返时间+B的发送时间）

改进：流水线

2、连续ARQ协议

维持一个发送窗口，位于发送窗口的分组都可以连续发送，不需要等待对方的确定，信道利用率就高了。

每收到一个确认，就把发送窗口向前滑动一个分组的位置

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

3.4TCP报文段首部格式

面向字节流的，但 传送的数据单元却是报文段。

首部+数据
功能实现体现在首部
首部固定20字节，后面还有4n字节根据需要而添加但最多添加40字节（20<=首部<=60）

(1)源端 口和目 的端 口   各占2个字节。和UDP的分用相 似，TC P的分用功能也是通过端口实现

(2)序号   4字节     范围是[0,2^32-1]，共2^32（即4294967296)个序 号。序号 增加到2^32-1后，下一个序号就又回 到0。即序号使用mod2^32运算。TCP连接中传送的字节流中 的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号 。序号字段有32 位长，可对4GB（即4 千兆字节）的数据进行编号。一般情况下可保证当 序号重复使用时，旧序号的数据早已通过网络到达终点了。

(3)确认号   4字节，是期望收到对方下一个报文段的第一个数据字节的序号。

(4)数据偏移     4位     指报文段数据起始处距 报文段的起始处有多远。实际是指报文段的首部长度。首部中还有长度不确定的选项字段，因此数据偏移字段是必要的。“ 数据偏移＂的单位是32位字（即以4字节长的字为计算单位）。4位二进制数能够表示的最大十进制数字是15,因此数据偏移的最大值是60字节，即TCP首部的最大长度（即选项长度不能超过40字节）。

(5)保留   6位，保留为今后使用，但目前置为0。

6个控制位    

( 6)紧急URG    URG=1时，表明紧急 指针字段有效。报文段有紧急数据，应尽快传送（高优先级），而不按排队顺序传送。如中断命 令(Control-C )。要与首部中紧急指针字段配合使用。

(7)确认ACK    当AC K=1 确认号字段有效。当ACK=0时，确认号无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置为1 。

(8)推送PSH   当两个应用进程进行交互式的通信时，有时在一端的应用进程希 望在键入一个命令后立即就能够收到对方的响应 。TCP就可 以使用推送操作 。发送方TCP把PSH置1，并立即创建一个报文段发送出去 。接收方TCP收到PSH=1的报文段，就尽快地（即“推送“向前）交付接收应用进程，而不再等到缓存填满后再向上交付。推送操作很少使用。

(9)复位RST     RST=1，表明TCP连接中出现严重差错, 如主机崩溃，必须释放连接，然后再重新建立运输连接。将 RST置为1还用来拒 绝一个非法的报文 段或拒绝打开一个连接。也称为重建位或重置位 。

(10 )同步SYN   在连接建立时用来同 步序 号。当 SYN=1而ACK=0时 ，表明这是一个连接请 求报文段。对方若同意建立连接，则应在响应的报文段中使SYN= 1和ACK =1。 

(11)终止FI N   用来释放一个连接。当 FI N=1时，表明此报文 段的发送方的数据已发送完毕 ，并要求释放运输连接。

(12)窗口    2字节。是[0,2^16-1]之间的整数。指发送本报文 段的一方的接收窗口（而不是自己的发送窗口 ）。窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量（以字节为单位）。接收方的数据缓存空 间是有限的。窗口值作为接收方让发送方设置发送窗口的依据。      该字段明确指出了现在允许对方发送的数据量。窗口值经常在动态变化。

(13)检验和   2字节   检验的范围包括首部和数据。和 UDP用户数据报一样，在计算检验和时，要 在TCP报文 段的前面加上12字节的伪首部。伪 首部与 UDP的伪首部一样。但应把伪首部第4个字段中的17改为6(TCP的协议号是6) ，把第5字段中的UDP长度改为TCP长度。接收方收到此报文段后，仍要加上这个伪首部来计算检验和。使用IPv6,则相应的伪首部也要改变。

(14)紧急指针  2字节    仅URG=1时才有意义，指出本报文段中的紧急数据的字节数（紧 急数据结束后就是普通数据）。因此，紧急指针指出了紧急数据的末尾在报文段中的位置。当所有紧急 数据 都处理完时，TCP就告诉应用程序恢复到正常操作。注意即使窗口为零时也可发送紧急数据。

(15)选项    长度可变 ，最长可达40字节。

最后的填充字段仅仅是为了使整个TCP首部长度是4字节的整数倍。

从提高网络传输效率考虑，MSS应尽可能大些，只要在IP层传输时不需要再分片就行。

MSS的默认值是536字节（这个数值来自576字节的IP数据报总长度减去TCP和IP的固定首部）。因此，所有互联网上的主机都应能接受的报文段长度是536+20（固定首部长度）＝556字节。

在TCP连接建立阶段“双方协商MSS值”，但这是错误的 ，因 为这里并不存在任何的协商 ，而只 是一方把MSS值设定好以后再通知另一方而已 。

窗口扩大选项   扩大窗口。 TCP首部中窗口 字段长度是16位 ，因此最大的窗口大小为64KB。 对早期的网络是足够用的，但对包含卫星信道的网络 其传播时延和带宽都很大，要获得高吞吐率需要更大的窗口大小。   3字节 ，其中有一个字节表示移位值S。新的窗口值是TCP首部中的窗口位数从16增大到( 16+S )。S的最大值是14,相当窗口最大值增大到2^30-1。窗口扩大选项可以在双方初始建 立TCP连接时进行协商。如果连接的某一端 实现了窗口扩大，当它不再需要扩大其窗口时，可发送S= 0的选项，使窗口大小回到16。

关于ACK控制位：

3.5可靠传输实现

滑动窗口

以字节为单位

 A发送窗口：B发来的确认报文中的窗口值+确认号

A的发送窗口一定不能超过B的接收 窗口数值。发送方A还可能根据网络当时的拥塞情况适当减小自己的发送窗口数值。同一时刻，A的发送窗口并不总是和 B的接收窗口一样大,因为通过网络传送窗口值需要经历一定的时间滞后（这个时间是不确定的）。 

窗 口越大，发送方就可以在收 到对方确认之前连续发送更多的数据 ，因而可能获得 更高的传输效率。

发送窗口后沿的变化情况：不动（没有收到新的确认）和前移（收到了新的确认）。

后沿不可能向 后移动，因为不能撤销掉已收到的确认。

前沿的变化情况：通常是不断向 前移动的，但也有可能不动（一是 没有收到新的确认，对方通知的窗口大小也不变；二 是收到了新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动。）

前沿也有可能向后收缩。这发生在对方通知的窗口缩小了。但TCP的标准强烈不赞成这样做。

累积确认

TCP要求 接收 方必须有累积确认的功能，可 以减小传输开销。

接收方可以在合适的时候发送确认，也可以在自己有 数据要发送时把确认信息顺便捎带上。

注意两点 :一是不应过分推迟发送确认，否则会导致发送方不必要的重传，这 反而浪费了网络的资源。TCP规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认。二是捎 带确认实际上并 不经常发生，因为大多数应用程序很少同时在两个方向上发送数据 。

在图中，B 收到 了序 号为32和33的数据，但序号为31的数据没有收到（也许丢失了，也许滞留在网络中的某处）。请注意，B只能对按序收到的数据中的最高序号给出确认，因此B发送的确认报文 段中的确认号仍然是31（即期望收到的序号）。对不按序到达的数据应如何处理，TCP标准 并无 明确规定。如果接收 方把 不按序到达的数据一律丢弃，那么接收 窗口的管理将会比较简单，但这样做对网络资源的利用不利（因为发送方会重复传送较多 的数据）。因此TCP通常是把 不按序到达的数据先临时存放在接收 窗口 中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。

窗口和缓存的关系：

缓存空间和序号空间都是有限的，并且都是循环使用的。

缓存或窗口中实际的字节数可能很大。

发送缓存用来暂时存放：(1)发送应用程序传送给发送方TCP准备发送的数据；(2)TCP已发送出但尚未收到确认的数据。

发送窗口通常只是发送缓存的一部分。已被确认的数据应当从发送缓存中删除，因此发送缓存和发送窗口的后沿是重合的。发送应用程序最后写入发送缓存的字节减去最后被确认的字节，就是还保 留在发送缓存中的被写入的字节数。发送应用程序必须控制写入缓存的速率，不能太快，否则发送缓存就会没有存放数据的空间。

接收缓存用来暂时存放：(1)按序到达的、但尚未被接收应用程序读取的数据；(2)未按序到达的数据。（不按序到达的数据应 如何处理，TCP标准 并无 明确规定）

收到的分组被检测 出有差错，则要丢 弃。如果接收 应用程序来 不及读取收到的数据 ，接收缓存最终就会被填满，使 接收窗口减小到零。反之，如果接收 应用程序能够及时从接收缓存中读取收到的数据，接收窗口就可以增大，但最大不能超过接收 缓存的大小。

超时重传

0<=a<1

a很接近零，表示新的RTTS值和旧的RTTS值 相比变化不大，而对新的RTT样本影 响不大(RTT值 更新较慢）。

 a接近1,则表示新的RTTS值受新的RTT样本的影响较大(RTT值 更新较快）。

建议 a值为1/8,即0.125。

往返时间的测量 ，实现起来相当复杂。如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？

超时重传最终做法：

选择确认SACK

收到的报文 段无差错，只是未按 序号，中间还缺少一些序号的数据 ，那么能否设法只传送缺少的数据而 不重传已经正确到达接收 方的数据？选择确认是一种可行的处理方法。

TCP的接收方在接收 对方发送过来的数据 字节流的序号不连续，结果就形成了一些 不连续的字节块：

指明一个边界就要用掉4 字节（因 为序号有32位，需 要使用4个字节表示），因此在选项中最多只能指明4个字节块的边界信息 。另 外还需要两个字节，一个字节用来指明是SACK选项，另一个字节指明这个选项要占用多少字节。(选项长度40字节的上限)

3.6TCP的运输连接管理

TCP的 连接建立

最初两端的TCP进程都处于 CLOSED（关 闭）状态。

B的TCP服务器进程先创建传输控制块TCB，准备 接受客户进程的连接请求。然后服务器进程就处于LISTEN （收听）状态，等待客户的连接请求

A 的TCP客户进程也是首先创建传输控制块TCB。然 后，向B发出连接请求报文段，这时首部中的同 步位SYN=l,同时选择一个初始序号s eq=x。进入SYN-SENT（同步已发送）状 态。

TCP规定，SYN报文段（即SYN=1的报文段）不能携带数据，但要消耗掉一个序号。

B收到 连接请求报文段后，向A发送确认。在确认报文段中应把SYN位和ACK位都置l，确认号是ack= x+1,同时也为 自己选择一个初始序号se q=y。进入 SYN-RCVD（同步收到）状态。这个报文段也不能携带数据，但 同样要消耗掉一个序号。

收到B的确认后，还要向B给出确认。确认报文段的ACK置 l，确认号ack =y+ I,而自己的序号se q=x + 1。A进入ESTABLI SHED（已建立连接状态。

TCP连接已经建立，B收到 A的确认后，也进入ESTABLI SHED状态

TCP的标准 规定，ACK报文段可以携带数据。但如果不携带数据则不消耗序号

B发送给A的报文段，也可拆成两个报文段。可以先发送一个确认报文段(ACK=l,ack=x+1)，然 后再发送一个同步报文段(SY N=1,seq =y)。这样的过程就变成了 四报文握手，但效果是一样的。

“已失效的连接请求报文段”：A发出的第一个连接请求报文段在某些网络节点长时间滞留 了，以致延误到连接释放以后的某个时间才到达B。

B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用报文握手，那么只要B发出确认，新的连接就建立了。A并没有发出建立连接的请求，因此不会理睬B的确认。B却一直等待A发来数据，B的许多资源就浪费了。

采用三报文握手的办法，可以防 止上述现象的发生 。（奇数次报文握手的意义‌在于优化资源利用和减少服务器压力。在TCP连接建立过程中，采用奇数次握手可以确保服务器在收到客户端的连接请求后，不会立即建立连接，而是等待客户端的最终确认，从而避免无效连接的建立。）

               

 TCP的连接释放

通信的双方都可释放连接。

现A和B都处于ESTABLISHED状态。

A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。A把连接释放报文段首部的终止控 制位 FI N置1,其序号 seq=u,它等于前面已传送过的数据的最后一个字节的序号加1。A进入 FIN -WAIT- 1（终止等待1)状态。

TCP规定，FIN报文段即 使不携带数据 ，它也消耗掉一个序号。

B收到连接释放报文段后即发出确认 ，确认号是ack=u+1,报文段自己的序号等 于B前面已传送过的数据的最后一个字节的序号 加1。然后B就进入CLOSE-WAIT（关闭等待）状态。

TCP服 务器进程这 时应通知高层应用进程，因而从A到B 这个方向的连接就释放了 ，这 时的TCP连接处于半 关闭(half-close )状态（从B到A这个方向的连接并未关闭 ，这个状态可能会持续一段时间）

A收到来 自B的确认，进入FIN-WAI T-2（终止等 待2)状态 ，等 待B发出的连接释放报文段。

若 B已经没有要向 A发送的数据，其应用进程就通知 TCP释放连接。

B发出的连接释放报文 段必须使FI N=1，假定B 的序号为w（在半 关闭状态B可能又发送了一些数据）B 还必须重复 上次已发送过的确认号ack= u+1。这时B就进入LAST-ACK（最后 确认）状 态，等待A的确认

A 在收到B的连接释放报文段后，必须 对此发出确认。在 确认报文段中把AC K置1，确认号ack= w+1,而 自己的序号是 seq=u+1，进入到TIME-WAIT（时间等待 ）状态。

现在TCP连接还没有释放掉。必须经过时间等待计时器设置的时间2MSL后 ，A才进入到C LOSED状态。

MSL叫作最长报文段寿命，  建议的MSL=2分钟(可能太长了一些,TCP允许根据具 体情况使 用更小的MSL值)因此，从 A进入到TIME-WAI T状 态后，要经过4分钟才 能进入到CLOSED状态，才能开始建立下一个新的连接。当A撤销相 应的传输控制块TCB后，就结束了这次的TCP连接。

A撤销相 应的传输控制块TC B后，就结束了这次的TCP连接。  B只要 收到 了A发出的确认，就进入CLOSED状 态。同样，B在撤销相 应的传输控制块TC B后，就结束了这次的TC P连接。我们注意到，B结束 TCP连接的时 间要比 A早。

TCP的有限状态机 

3.7TCP的流量控制

滑动窗口

让发送方的发送速率不要太快，使得接收方来得及接收

持续计时器
只要TCP连接的一方收到对方的零窗口通知（不可以再发送了），就启动持续计时器，时间到了，就发送一个探测报文段，对方确认这个探测报文段给出现在的窗口值。
如果窗口不为0，就发送即打破死锁，为0就继续持续计时器

发送零窗口探测报文段：

传输效率

应用进程把数据传送到TCP的发送缓存后，就由TCP来控制了。

3种控制机制：

Nagle算法

糊涂窗口综合征：向发送方发送确认，并把窗口设置为1个字节，每次仅发送一个字节或很少字节的数据，导致数据传输效率变低的现象

3.8TCP的拥塞控制

一般原理

在网络吞吐量还未达到饱和时，就 已经有一部分的输入分组被丢弃 了。当网络的 吞吐量明显地小于理想的吞吐量时，网络就进入了 轻度拥塞的状态。更值得注意的是，当 提供的负载达到某一数值时，网络的吞吐量反而随提供的 负载的增大而下降，这时网络就进入了拥塞状态。当 提供的负载继续增大到某一数值时，网络的吞吐量就下降到零，网络已无法工作，这 就是所谓的死锁

拥塞控制是一个动态的问 题。网络正朝着高速化 的方向发展，很容易出现缓存不够大而导致分组的丢失。但分组的丢失是网络发生拥塞的征兆而不是原因。在许多情况下，甚至正是 拥塞控制机制本身成为引起网络性能恶化甚至发生死锁的原因。

开环控制：事先考虑周全，避免发生拥塞
闭环控制：发生拥塞后，采用措施控制，消除拥塞

监测网络的拥塞：缺少 缓存空间而被 丢弃的分组的百分数 、平均队列长度、超 时重传的分组数 、平均分组时延 、分组时 延的标准差。上述这些指标的 上升都标志着拥塞发生的可能性增加 。

监测到拥塞发生时，要将拥塞发生的信息传送到产生分组的源站。当然，通知拥寒发生的分组 同样 会使网络更加拥塞。

另一种方法是在路由器转发的分组中保留一个比特或字段，用该比特或字段的值表示网络没有拥塞或产 生了拥塞。也可以由一些主机或路由器周期性地发出探测分组，以询问拥塞是否发生。

拥塞控制方法

1. 慢开始
2. 拥塞避免
3. 快重传
4. 快恢复

只要网络没有出现拥塞，拥塞窗口可以增大一点
出现拥塞，拥塞窗口变小一点。

发送方没有按时收到对方的确认报文，也就是说，只 要出现了超时，超时重传计时器启动时，就可以估计可能在网络某处出现了拥塞。

（1）慢开始

 

若SMSS（发送方的最大报文段）> 2190字节，则设置初始拥塞窗口cwnd= 2 x SMSS字节，且不得超过2个报文段。

若(SMSS> 1095字节）且SMSS<=2190字节），则设置初始拥塞 窗口cwnd= 3 x SMSS字节，且不得超过3个报文段。

若 SMSS<=1095字节，则设置初始拥塞 窗口cwnd= 4 x SMSS字节，且不得超过4个报文 段。

N是原先未被确认的、但现在被刚收到的确认报文段所确认的字节数。当 N<SMSS时，拥 塞窗口每次的增加量要小于SMSS 

慢开始门限ssthresh状态变量（可以把ssthresh的数值设置大些，例如达到发送窗口的最大容许值）

 （2）拥塞避免

TCP连接已建立后，把拥塞 窗口cwnd置为1。慢开始门限的初始值设置为16个报文段，即ssthre sh=16。

每经过一个往返时间RTT,拥塞 窗口cwnd就加倍。拥 塞窗 口cwnd增长到慢开始 门限值ssthre sh时，改为执行拥塞避免算法，拥 塞窗口按线性规律增长。

cwnd=24时，网络出现了超时，这 就是 网络 发生拥塞的标志。调 整门限值ssthresh= cwnd / 2= 12,同时设置拥塞窗口cwnd= 1,执行慢开始算法，发送方每收到一个对新报文段的确认 ACK,就把拥塞窗口值加1。

拥塞窗口cwnd=ssthresh=12时（这是ssthresh 第1次调整后的数值），改为执行拥塞避免算法，拥塞窗口按线性规律增大。

 拥塞 窗口cwnd= 16时，发送方一连收到3个对同一个报文段的重复确认（图中记为3-ACK)。 有时，个 别报文段会在网络中意外丢失，但 实际上 网络并未发生拥塞。如果发送方迟迟收不到确 认，就会产生超时，并误认为网络发生了 拥塞。这 就导 致发送方错 误地启动慢开始 ，把拥塞窗口cwnd又设置为1,因而不必要地降低了传输效率。

（3）快重传与快恢复

发送方知 道现在只是丢失了个别的报文段。千是 不启动慢开始，而是执行快恢复算法。这时，发送方第2次调整门限值，使ssthresh= cwnd / 2= 8,同时设置拥塞 窗口cwnd= ssthresh = 8并开始执行拥塞避免算法。

拥塞避免阶段，拥塞窗口是按照线性规律增大的，这就是前面提到过的加法增大AI。而一旦 出现超时或3个重复的确认，就要把门限值设置为当前拥塞窗 口值的一半 ，并大大减小拥塞窗口的 数值 。这 常称 为＂乘法减小“MD。二者合在一起就是所谓 的AIMD算法。

也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些（增大3个报文 段的长度） ，即 等于新的 ss thre sh+ 3xMSS。

主动队列管理AQM

网络层的策略对TCP拥塞控制影响最大的就是路由器的分组丢弃策略

路由器的队列通常都按照“先进先出“FIFO(的规则处理到来的分组。队列长度是有限的，当队列已满时，以后再到达的所有分组（如果能够继续排队，这些 分组都将排在队列的尾部）将都被丢弃（尾部丢弃策略)使发送方出 现超时重传，使TCP进入拥塞控制的慢开始状态，结果使TCP连接的发送方突 然把数据的发送速率降低到很小的数值。

可能 会同时影响到很多条 TCP连接，结果使这许多TCP连接在同一时间突然都进入到慢开始状态。这 在TCP的术语中称为全局同步，全局同 步使得全网的通信量突然下降了很多，而在网络恢复 正常后，其通信量又突然增大很多。

在队列长度达到某个值得警惕的数值时（即当网络拥 塞有了某些拥塞征兆时），就主动丢弃到达的分组。这样就提醒了发送方放慢发送的速率，因而有可能使网络拥塞的程度减轻，甚至不出 现网络拥塞 。

随机早期检测RED

RED是在检测到网络拥塞的早期征兆时（即路由器的平均队列长度达到一定数值时），就以概率 p丢弃个别的分组。RED的使用效果并不太理想。但对路由器进行主动队列管理 AQM仍是必要的。AQM实际上就是对路由器中的分组排队进行智能管理，而不是简单地把队列的尾部丢弃。现在已经有几种不同的算法来代替旧的RED,但都还在实验阶段。

一些使用UDP的实时应用 ，需 要对UDP的不可靠的传输进行适当的改进，以减少数据的丢 失。在这种情况下，应用进程本身可以在不影响应用的实时性的前提下，增加一些 提高可靠性的措施，如采用前向纠错或重传已丢失的报文。