计算机网络-谢希仁-运输层02

5.5 TCP报文段的首部格式

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

TCP报文段首部的前20个字节是固定的，后面有4n字节是根据需要而增加的选项(n为整数)。因此TCP首部的最小长度是20字节。TCP首部最大长度60字节。

这里搞一张图片

首部固定部分各字段的意义：

（1）源端口和目的端口 （各占2个字节，分别写入源端口和目的端口号）

（2）序号 （占4个字节，范围为0,2^32-1 共4294967296个序号）序号增加到2^32 -1 后，下一序号就又回到0.序号使用mod 2^32运算。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。例如，一报文段的序号字段值是301，而携带的数据共有100字节。这就表明：本报文段的数据的一个字节的序号字段是301，最后一个字节的序号是400.显然，下一个报文段的数据序号应当从401开始，这个字段的名称也叫做**“报文段序号”**。

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

若确认号 = N，则表明： 到序号N-1为止的所有数据都已正确收到。

（4）数据偏移（占4位，单位是4字节 。 它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。这个字段实际上是指出TCP报文段的首部长度。）

（5）保留 占6位，保留为今后使用，但目前应置为0。

(6) 紧急URG（URGent） 当URG = 1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据），而不要按原来的排顺序来传送。于是，发送方TCP就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍是普通数据。

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

（8）推送 PSH（PuSH）发送方TCP把PSH置1，并立即创建一个报文段发送出去。接收方TCP收到PSH = 1 的报文段，就尽快地（即“推送”向前）交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。

（9）复位 RST（ReSeT）当RST = 1时，表明TCP连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。RST置1还用来拒绝一个非法的报文段或拒绝打开一个连接。RST也可称为重建位或重置位。

**（10）同步 SYN（SYNchronization） 在连接建立时用来同步序号。**当SYN = 1而ACK = 0时，表明这是一个连接请求报文段。若对方同意建立连接，则应在响应的报文段中使SYN = 1和ACK = 1。因此，SYN置1就表示这是一个连接请求或连接接受报文。

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

（12）窗口 （占2字节 0~2^16-1）窗口指的是发送本报文段的一方的接收窗口。窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量。窗口值作为接收方让发送方设置其发送窗口的依据。

窗口字段明确指出了现在允许对方发送的数据量。窗口值经常在动态变化着。

（13）检验和 （占2个字节。检验和字段检验的范围包括首部和数据这两部分）和UDP用户数据报一样，在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。格式与UDP数据报中的伪首部一样。但应把伪首部第4个字段中的17改为6，把第5个字段中的UDP长度改为TCP长度。

（14）紧急指针 （占2个字节，紧急指针仅在URG=1时才有一样，它指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据）。因此，紧急指针指出了紧急数据的末尾在报文段中的位置。）即使窗口为0时也可发送紧急数据。

（15）选项 （长度可变，最长可达40字节）当没用“选项”时，TCP的首部长度是20字节。

5.6 TCP可靠传输的实现

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

发送窗口的位置由窗口前沿和后沿的位置共同确定。发送窗口前沿通常是不断向前移动，但也有可能不动。这对应于两种情况：一是没有收到新的确认，对方通知的窗口大小也不变；二是收到了新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动。

要描述一个发送窗口的状态需要三个指针：P1,P2和P3。指针都指向字节的序号。

这三个指针指向的几个部分的意义如下:

1. 小于P1的是已发送并已收到确认的部分，而大于P3的是不允许发送的部分。
2. P3-P1 = A的发送窗口
3. P2-P1 = 已发送但尚未收到确认的字节数
4. P3-P2 = 允许发送但当前尚未发送的字节数（又称为可用窗口或有效窗口）

发送方的应用进程把字节流写入TCP的发送缓存，接收方的应用程序从TCP的接收缓存中读取字节流。

发送缓存用来暂时存放：

（1）发送应用程序传送给发送方TCP准备发送的数据

（2）TCP已发送出但尚未收到确认的数据

接收缓存用来暂时存放：

（1）按序到达的、但尚未被接收应用读取的数据

（2）未按序到达的数据

强调以下三点：

（1）发送方A可能根据网络当时的拥塞情况适当减小自己的发送窗口数值。

（2）TCP同创对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用程序。

（3）TCP要求接收方必须有累计确认的功能，这样可以减小传输开销。

强调：TCP的通信是全双工通信。

5.6.2 超时重传时间的选择

TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文段。这种重传的概念是很简单的，但重传时间的选择却是TCP最复杂的问题之一。

如果把超时重传时间设置得太短，就会引起很多报文段的不必要的重传，使网络负荷增大。但若把超时重传时间设置得过长，则又使网络的空闲时间增大，降低了传输效率。

TCP采用了一种自适应算法 P225。

5.7 TCP的流量控制

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

所谓流量控制：就是让发送方的发送速率不要太快，要让接收方来得及接收。

设A向B发送数据。在连接建立时，B告诉A：“我的接收窗口rwnd = 400”。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值，TCP的窗口单位是字节，不是报文段。seq:序号。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值。

现在我们考虑一种情况。B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd = 400 的报文段。然而这个报文段在传送过程中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。如果没有其他措施，这种互相等待的思索局面将一直持续下去。

为了解决这个问题，TCP为每一个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口仍然是零，那么收到这个报文段的一方就重新设置持续计时器。如果窗口不是零，那么死锁的僵局就可以打破了。

5.8.2 TCP的拥塞控制方法

TCP进行拥塞控制的算法有四种，即慢开始，拥塞避免，快重传和快恢复。

1.慢开始和拥塞避免

发送方如何知道网络发生了拥塞呢？我们知道，当网络发生拥塞时，路由器就要丢弃分组。因此只要发送方没有按时收到应当到达的确认报文，也就是说，只要出现了超时，就可以猜想网络可能出现了拥塞。

因此，判断网络拥塞的依据就是出现了超时。

慢开始算法：每经过一个传播轮次，拥塞窗口cwnd就加倍。

使用“传播轮次”是更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并受到了对已发送的最后一个字节的确认。

在TCP的实际运行中，发送方只要收到一个对新报文段的确认，其拥塞窗口cwnd就立即加1，并可以立即发送新的报文段，而不需要等这个轮次中所有的确认都收到后再发送新的报文段。

为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。

慢开始门限ssthresh的用法：

当cwnd<ssthresh 时，使用上述的慢开始算法

当cwnd>ssthresh时，停止使用慢开始算法而改用拥塞避免算法

当cwnd=ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法

拥塞避免算法的思路是让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是像慢开始阶段那样加倍增长。着表明在拥塞避免阶段，拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。

TCP连接进行初始化时，把拥塞窗口cwnd置位1。假设，把拥塞窗口设置为16个报文段，即ssthresh = 16。在执行慢开始算法时，发送方每收到一个对新报文段的确认ACK，就把拥塞窗口值加1，然后开始下一轮的传输。因此拥塞窗口cwnd随着传播轮次按指数规律增长。当拥塞窗口cwnd增长到慢开始门限值ssthresh时，就改为执行拥塞避免算法，拥塞窗口按线性规律增长。

“拥塞避免”是说把拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。如果当拥塞窗口cwnd = 24时，网络出现了超时，发送方判断为网络拥塞。于是调整门限值ssthresh = cwnd/2 = 12,同时设置拥塞窗口cwnd = 1,进入慢开始阶段。同样到达ssthresh = 12就开始拥塞避免，等到超时，又ssthresh = cwnd/2 = 6,

若出现了一个新的情况，发送方一连收到3个对同一个报文段的重复确认（3-ACK）。

有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。如果发送方迟迟收不到确认，就会产生超时，误以为网络发生了拥塞。这就导致发送方错误地启动慢开始，把拥塞窗口cwnd又设置为1，因而降低了传输效率。

采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。快重传算法首先要求接收方不要等到自己发送数据时才进行捎带确认，而是要立即发送确认，即是收到了失序的报文段也要立即发出对已收到的报文段的重复确认。

快重传算法规定，发送方只要一连收到3个重复确认，就知道接收方确实没有收到报文段M3，因而应当立即进行重传（即“快重传”），这样就不会出现超时，发送方也就不会误以为出现了网络拥塞。使用快重传可以使整个网络的吞吐量提高约20%。

接收方窗口 rwnd 和 拥塞窗口cwnd

发送方窗口的上限值 = Min[rwnd,cwnd]

5.8.3 主动队列管理AQM

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

为了避免发生网络中的全局同步现象，在1998年提出了主动队列管理AQM。所谓“主动”就是不要等到路由器的队列长度达到某个值得警惕的数值时（即当网络拥塞有了某些拥塞征兆时），就主动丢弃到达的分组。这样就提醒了发送方放慢发送的速率，因而有可能使网络拥塞的程度减轻，甚至不出现网络拥塞。

AQM可以有不同实现方法，其中曾流行多年的就是随机早期检测RED。RED还有几个不同的名称，如Random Early Drop 或 Random Early Discard(随机早期丢弃)

实现RED时需要使路由器维持两个参数，即队列涨肚最小门限和最大门限。当每一个分组到达时，RED就按照规定的算法先计算当前的平均队列长度。

（1）若平均队列长度小于最小门限，则把新到达的分组放入队列进行排队。

（2）若平均队列长度超过最大门限，则把新到达的分组丢弃。

（3）若平均队列长度在最小门限和最大门限之间，则按照某一丢弃概率p把新到达的分组丢弃（这就体现了丢弃分组的随机性）。

5.9 TCP的传输连接管理

TCP是面向连接的协议。

运输连接就有三个阶段，即：连接建立、数据传送和连接释放。

在TCP连接建立过程中要解决一下三个问题：

（1）要使每一方能够通知对方的存在。

（2）要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）。

（3）能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。

5.9.1 TCP的连接建立

TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段。

学会根据描述把图画出来：

注：三报文握手是第七版首次采用的译名。以前采用“三次握手”，其实这是在一次握手过程中交换了三个报文，而并不是进行了三次握手。（RFC 973文档中：three way(three message)handshake,handshake的单数，表明只是一次握手。）

假定主机A运行的是TCP客户程序，而B运行TCP服务器程序。最初两端的TCP进程都处于CLOSED(关闭)状态。

A主动打开连接，而B被动打开连接。

一开始，B的TCP服务器进程先创建传输控制块TCB（传输控制块TCP存储了每一个连接中的一些重要信息，如：TCP连接表，指向发送和接收缓存的指针，指向重传队列的指针，当前的发送和接收序号，等等），准备接收客户进程的连接请求。然后服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。如有，即作出响应。

A的TCP客户进程也是首先创建传输控制模块TCB。然后，在打算建立TCP连接时，想B发出连接请求报文段，这时首部中的同部位SYN = 1，同时选择一个初始序号seq = x。TCP规定，SYN报文段（即SYN=1的报文段）不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。

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

TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号ack =y+1,而自己的序号seq=x+1。TCP的标准规定，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是seq = x+1。这时，TCP连接已经建立，A进入ESTABLISHED（已建立连接）状态。

当B收到A的确认后，(ACK=1,seq=x+1,ack=y+1)也进入ESTABLISHED（已建立连接）状态。

上面给出的连接建立过程叫做三报文握手。

注意：在B发送给A的报文段，也可拆成两个报文段。可以先发送一个确认报文段（ACK=1,ack=x+1），然后再发送一个同步报文段（SYN = 1,seq = y）。这样的过程就变成了四报文握手。

为什么A最后还要发送一次确认呢？这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。那么，解释一下为什么就能防止已失效的连接请求？

5.9.2 TCP的连接释放

现在A和B都处于ESTABLISHED状态。

A把连接释放报文段首部的终止控制位FIN置1，其序号seq = u,它等于前面已传送过的数据的最后一个字节的序号加1。这时A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。请注意，TCP规定，FIN报文段即使不携带数据，它也消耗掉一个序号。

B收到连接释放报文段后即发出确认，确认号是ack = u+1,而这个报文段自己的序号是v，等于B前面已传送过的数据的最后一个字节的序号加1。然后B就进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时的TCP连接处于半关闭（half-close）状态,即A已经没有数据要发送了，但B若发送数据，A仍要接收。也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一段时间。

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

这里的时间间隙可能B依然在发送数据…

若B已经没有要向A发送的数据，其应用程序就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN=1。现假定B的序号为w(在半关闭状态B可能又发送了一些数据，所以为数组的最后一个字节的序号加一)。**B还必须重复上次已发送过的确认号ack=u+1。**这时B就进入LAST-ACK（最后确认）状态，等待A的确认。

A在收到B的连接释放报文段后，必须对此发出确认。在确认报文段中把ACK置1，确认号ack=w+1,而自己的序号是seq=u+1(根据TCP标准，前面A发送过的FIN报文段要消耗一个序号)。然后进入到TIME-WAIT（时间等待）状态。请注意，现在TCP连接还没有释放掉。必须经过时间等待计时器（TIME-WAIT timer）设置的时间2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命（Maximun Segment Lifetime）,建议设为2分钟。当A撤销相应的传输控制块TCB后，就结束了这次的TCP连接。

为什么A在TIME-WAIT状态必须等待2MSL的时间呢？这里有两个理由。

第一：为了保证A发送的最后一个ACK报文段能够到达B。

第二：防止上一节提到的“已失效的连接请求报文段”出现在本连接中。

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

上述的TCP连接释放过程是四报文握手。

除时间等待计时器外，TCP还设有一个保活计时器（keppalive timer）。服务器每收到一次客户的数据，就重新设置保活计时器，时间通常是两小时。若两小时没有收到客户的数据，服务器就发送一个探测报文段，以后则每隔75秒钟发送一次。若一连发送10个探测报文段后仍无客户的响应，服务器就认为客户端出了故障，接着就关闭这个连接。

UD的主要特点：

（1）无连接

（2）尽最大努力交付

（3）面向报文

（4）无拥塞控制

（5）支持一对一、一对多、多对一、和多对多的交互通信

（6）首部开销小（只有四个字段：源端口、目的端口、长度、检验和）

TCP的主要特点：

（1）面向连接

（2）每一条TCP连接只能是点对点的（一对一）

（3）提供可靠交付的服务

（4）提供全双工通信

（5）面向字节流