【b站-湖科大教书匠】5 运输层 - 计算机网络微课堂

课程地址：【计算机网络微课堂（有字幕无背景音乐版）】 https://www.bilibili.com/video/BV1c4411d7jb/?share_source=copy_web\&vd_source=b1cb921b73fe3808550eaf2224d1c155

[5 运输层](#5 运输层)

[5.1 运输层概述](#5.1 运输层概述)

[5.2 运输层端口号、复用与分用](#5.2 运输层端口号、复用与分用)

[5.2.1 运输层端口号](#5.2.1 运输层端口号)

[5.2.2 发送方的复用和接收方的分用](#5.2.2 发送方的复用和接收方的分用)

[5.2.3 TCP/IP体系应用层常用协议所使用的运输层熟知端口号](#5.2.3 TCP/IP体系应用层常用协议所使用的运输层熟知端口号)

[5.2.4 案例-运输层端口号的作用](#5.2.4 案例-运输层端口号的作用)

[5.3 UDP和TCP的对比](#5.3 UDP和TCP的对比)

[5.3.1 无连接和面向连接](#5.3.1 无连接和面向连接)

[5.3.2 单播、多播和广播](#5.3.2 单播、多播和广播)

[5.3.3 对应用报文处理](#5.3.3 对应用报文处理)

[5.3.4 可靠/不可靠传输服务](#5.3.4 可靠/不可靠传输服务)

[5.3.5 数据报首部](#5.3.5 数据报首部)

[5.4 TCP的流量控制](#5.4 TCP的流量控制)

[5.5 TCP的拥塞控制](#5.5 TCP的拥塞控制)

[5.6 TCP超时重传时间的选择](#5.6 TCP超时重传时间的选择)

[5.7 TCP可靠传输的实现](#5.7 TCP可靠传输的实现)

[5.8 TCP的运输连接管理](#5.8 TCP的运输连接管理)

[5.8.1 TCP的连接建立](#5.8.1 TCP的连接建立)

[1 TCP使用三报文握手建立连接](#1 TCP使用三报文握手建立连接)

[5.8.2 TCP的连接释放](#5.8.2 TCP的连接释放)

[1 TCP使用四报文挥手释放连接](#1 TCP使用四报文挥手释放连接)

[2 保活计时器](#2 保活计时器)

[5.9 TCP报文段的首部格式](#5.9 TCP报文段的首部格式)

[5.9.1 源端口和目的端口](#5.9.1 源端口和目的端口)

[1 源端口和目的端口的作用](#1 源端口和目的端口的作用)

[5.9.2 序号&确认号&确认标志位ACK](#5.9.2 序号&确认号&确认标志位ACK)

[5.9.3 数据偏移](#5.9.3 数据偏移)

[5.9.4 保留](#5.9.4 保留)

[5.9.5 窗口](#5.9.5 窗口)

[5.9.6 校验和](#5.9.6 校验和)

[5.9.7 同步标志位SYN](#5.9.7 同步标志位SYN)

[5.9.8 终止标志位FIN](#5.9.8 终止标志位FIN)

[5.9.9 复位标志位RST](#5.9.9 复位标志位RST)

[5.9.10 推送标志位PSH编辑](#5.9.10 推送标志位PSH编辑)

[5.9.11 紧急标志位URG&紧急指针](#5.9.11 紧急标志位URG&紧急指针)

[5.9.12 选项](#5.9.12 选项)

[5.9.13 填充](#5.9.13 填充)

5 运输层

5.1 运输层概述

具体内容如下。

如上图所示，局域网1上的主机，与局域网2上的主机，通过互联的广域网进行通信。

网络层的作用范围是主机到主机，但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。

上图，AP1和AP2是局域网1这台主机中的与网络通信相关的2个应用进程。AP3和AP4是局域网2上这台主机的与网络通信相关的2个应用进程。

AP是应用进程的英文缩写词。

运输层协议又称为端到端协议，运输层的作用范围是应用进程到应用进程，也称为端到端。

从计算机网络体系结构的角度看运输层

应用进程在应用层。

假设AP1与AP4之间进行基于网络的通信，AP2与AP3之间进行基于网络的通信。

在运输层使用不同的端口对应不同的应用进程。

然后通过网络层及其下层传输应用层报文。

接收方的运输层通过不同的端口将收到的应用层报文交付给应用层相应的应用进程。

需要注意：这里的端口不是指看得见摸得着的物理端口，而是指用来区分不同应用进程的标识符。

简单起见，认为运输层直接为应用进程间的逻辑通信提供服务。

逻辑通信的意思是，运输层之间的通信，好像是沿水平方向传送数据。但事实上，两个运输层之间并没有一条水平方向的物理连接。要传送的数据是沿着图中上下多次的虚线方向传送的。

运输层向高层用户屏蔽了下面网络核心的细节。

总结

5.2 运输层端口号、复用与分用

具体内容如下。

5.2.1 运输层端口号

运输层的任务是直接为应用进程间的逻辑通信提供服务。

运输层使用端口号来区分不同的应用进程。

5.2.2 发送方的复用和接收方的分用

如图所示，这是收发双方的应用进程。

发送方的某些应用进程所发送的不同应用报文，在运输层使用UDP协议进行封装，这称为UDP复用，而另一些应用进程所发送的不同应用报文在运输层使用TCP协议进行封装，这称为TCP复用。

运输层使用端口号来区分不同的应用进程。不管是使用运输层的UDP协议封装成的UDP用户数据报，还是使用TCP协议封装成的TCP报文段，在网络层都需要使用IP协议封装成IP数据包，这称为IP复用。

IP数据报首部中协议字段的值，用来表明IP数据报的数据载荷部分封装的是何种协议数据单元。取值为6表示封装的是TCP报文段，取值为17表示封装的是UDP用户数据报。

接收方的网络层收到IP数据报后进行IP分用。若IP数据报首部中协议字段的值为17，则把IP数据报的数据载荷部分所封装的UDP用户数据报上交运输层的UDP。若协议字段的值为6，则把IP数据报的数据载荷部分所封装的TCP报文段上交运输层的TCP。

运输层对UDP用户数据报进行UDP分用，对TCP报文段进行TCP分用，也就是根据端口号将他们交付给上层相应的应用进程。

5.2.3 TCP/IP体系应用层常用协议所使用的运输层熟知端口号

这些是TCP/IP体系的应用层常用协议。

其中这些协议在运输层使用UDP协议，这是他们各自使用的运输层熟知端口号。

这些协议在运输层使用TCP协议，这是他们各自使用的运输层熟知端口号。

不管在运输层使用UDP还是TCP协议，在网络层都是使用IP协议。IP数据报首部中协议字段的值，表明了IP数据报数据载荷部分封装的是何种协议数据单元。

5.2.4 案例-运输层端口号的作用

如图所示，用户PC、DNS服务器、Web服务器通过交换机进行互联，他们处于同一个以太网中。

假设这是Web服务器的域名。DNS服务器装记录有该域名所对应的IP地址。

我们在用户PC中使用网页浏览器来访问Web服务器的内容。

在网页浏览器的地址栏中输入Web服务器的域名。用户PC中的DNS客户端进程 会发送一个DNS查询请求报文，其内容为域名www.parttest.com所对应的IP地址是什么？

封装UDP用户数据报 ：DNS查询请求报文需要使用运输层的UDP协议封装成UDP用户数据报，其首部中的源端口字段值，在短暂端口号49151到65535中挑选一个未被占用的，用来表示DNS客户端进程 ，例如49152。目的端口字段的值设置为53，这是DNS服务器端进程所使用的熟知端口号。

封装IP数据报：之后，将UDP用户数据报封装在IP数据报中，通过以太网发送给DNS服务器。

解析IP数据报：DNS服务器端收到该数据包后从中解封出UDP用户数据报。UDP首部中的目的端口号为53，这表明应将该UDP用户数据报的数据载荷部分，也就是DNS查询请求报文，交付给本服务器中的DNS服务器端进程。

解析UDP数据报：DNS服务器端进程解析DNS查询请求报文的内容，然后按其要求查找对应的IP地址，之后会给用户PC发送DNS的响应报文，其内容为域名www.porttest.com所对应的IP地址是192.168.0.3。

发送DNS响应报文：DNS响应报文需要使用运输层的UDP协议封装成UDP用户数据报，其首部中的源端口字段的值设置为熟知端口号53，表明这是DNS服务器端进程所发送的UDP用户数据报，目的端口字段的值设置为49152，这是之前用户PC中发送DNS查询请求报文当DNS客户端进程所使用的短暂端口号。

之后将UDP用户数据报封装在IP数据报中。

通过以太网发送给用户PC。

解析UDP数据报：用户PC收到该数据报后从中解封出UDP用户数据报。

UDP首部中的目的端口号为49152，这表明应将该UDP用户数据报的数据载荷部分，也就是DNS响应报文交付给用户PC中的DNS客户端进程。

DNS客户端进程解析DNS响应报文的内容，就可知道自己之前所请求的Web服务器的域名所对应的IP地址为192.168.0.3。

现在用户PC中的HTTP客户端进程可以向Web服务器发送HTTP请求报文了，其内容为首页内容是什么？

HTTP请求报文需要使用运输层的TCP协议封装成TCP报文段，其首部中的源端口字段的值，在短暂端口号49151到65535中挑选一个未被占用的，用来表示HTTP客户端进程。例如，仍然使用之前用过的49152。目的端口字段的值设置为80，这是HTTP服务器端进程所使用的熟知端口号。

之后，将TCP报文段封装在IP数据报文中通过以太网发送给Web服务器。

Web服务器收到该数据包后，从中解封出TCP报文段。

TCP首部中的目的端口号为80，这表明应该将该TCP报文段的数据载荷部分，也就是HTTP请求报文交付给本服务器中的HTTP服务器端进程。HTTP服务器端进程解析HTTP请求报文的内容，然后按其要求查找首页内容之后，会给用户PC发送HTTP响应报文。

HTTP响应报文内容是HTTP客户端所请求的首页内容。

HTTP响应报文需要使用运输层的TCP协议封装成TCP报文段，即首部中的源端口号字段的值设置为熟知端口号80，表明这是HTTP服务器端进程所发送的TCP报文段。目的端口字段的值设置为49152，这是之前用户PC中发送HTTP请求报文当HTTP客户端进程所使用的短暂端口号。

之后，将TCP报文段封装在IP数据报中，通过以太网发送给用户PC。

用户PC收到该数据包后从中解封出TCP报文段。TCP首部中的目的端口号为49152，这表明应该将该TCP报文段的数据载荷部分也就是HTTP响应报文，交付给用户PC中的HTTP客户端进程。

HTTP客户端进程解析HTTP响应报文的内容，并在网页浏览器中进行显示。

这样我们就可以在网页浏览器中看到web服务器所提供的首页内容了。

总结

5.3 UDP和TCP的对比

具体内容如下。

TCP/IP体系结构应用层中的某些协议，需要使用运输层的TCP提供的服务，而另一些协议，需要使用运输层的UDP提供的服务。

5.3.1 无连接和面向连接

这是因特网上的两台主机，他们在运输层使用UDP协议进行通信，纵坐标为时间。使用UDP协议的通信双方可以随时发送数据。

再来看使用TCP协议的情况。使用TCP协议的通信双方在进行数据传输之前，必须使用三报文握手来建立TCP连接 ，TCP连接建立成功后，才能进行数据传输。数据传输结束后，必须使用四报文挥手来释放TCP连接。

三报文握手和四报文挥手属于TCP的连接管理，其过程比较复杂，我们将在后续课程中专门介绍。

需要注意的是，这里所谓的连接是指逻辑连接关系，而不是物理连接。

综上所述UDP是无连接的，而TCP是面向连接的。

5.3.2 单播、多播和广播

这是需要UDP协议议进行通信的四台主机，其中任何一台主机都可向其他三台主机发送广播，也可以向某个多播组发送多播，还可以向某台主机发送单播。

也就是说UDP支持单播多播以及广播。换句话说，UDP支持一对一、一对多以及一对全的通信。

再来看使用TCP协议的情况，需要TCP协议的通信双方在进行数据传输之前必须使用三报文握手来建立TCP连接。

TCP连接建立成功后，通信双方之间就好像有一条可靠的通信信道。通信双方使用这条基于TCP连接的可靠信道进行通信。

很显然，TCP仅支持单播，也就是一对一的通信。

5.3.3 对应用报文处理

发送方的应用进程，将应用层报文交付给运输层的UDP。

UDP直接给应用层报文添加一个UDP首部，使之成为UDP用户数据报，然后进行发送。

需要说明的是为了简单起见，我们忽略运输层下面的各层处理。

接收方的UDP收到该UDP用户数据报后去掉UDP首部，将应用层报文交付给应用进程。

也就是说UDP对应用进程交下来的报文既不合并也不拆分，而是保留这些报文的边界。

换句话说，UDP是面向应用报文的。

使用TCP协议的情况如下图右。

发送方的TCP把应用进程交付下来的数据，会仅仅看作是一连串的无结构的字节流。

报文由若干个字节组成。

TCP并不知道这些待传送的字节流的含义，仅将他们编号并存储在自己的发送缓存中。TCP根据发送策略从发送缓存中提取一定数量的字节，构建TCP报文段并发送。

接收方的TCP一方面从所接收到的TCP报文段中取出数据载荷部分，并存储在接收缓存 中，一方面将接收缓存中的一些字节交付给应用进程。

TCP不保证接收方应用进程所收到的数据块与发送方应用进程所发出的数据块具有对应大小的关系。例如。发送方应用进程交给发送方的TCP共10个数据块。但接收方的TCP可能只用了4个数据块就把收到的字节流交付给了上层的应用进程，但接收方应用进程收到的字节流必须和发送方应用进程发出的字节流完全一样。

当然，接收方的应用进程必须有能力识别收到的字节流，把它还原成有意义的应用层数据，也就是说TCP是面向字节流的。这正是TCP实现可靠传输流量控制以及拥塞控制的基础。

需要说明的是为了突出示意图的要点，我们只画出了一个方向的数据流，在实际网络中基于TCP连接的两端，可以同时进行TCP报文段的发送和接收，也就是全双工通信。另外图中TCP报文段的数据部分只包含了几个字节，实际当中一个TCP报文段包含上千个字节是很常见的。

5.3.4 可靠/不可靠传输服务

我们曾介绍过TCP/IP体系结构的网际层，向其上层提供的是无连接不可靠的传输服务。

当运输层使用UDP协议时，向其上层提供的也是无连接不可靠的传输服务。

发送方给接收方发送UDP用户数据报，若传输过程中用户数据报受到干扰而产生误码，接收方UDP可以通过该数据报首部中的校验和字段 的值检查出产生误码的情况，但仅仅丢弃该数据报，其他什么也不做。发送方给接收方发送UDP用户数据报，如果该数据报被因特网中的某个路由器丢弃了，发送方UDP不做任何处理，因为UDP向上层提供的是无连接不可靠的传输服务。

因此对于UDP用户数据报出现的误码和丢失等问题，UDP并不关心。基于UDP的这个特点，UDP适用于实时应用，例如IP电话、视频会议等。

再来看使用TCP协议的情况。尽管网际层中的IP协议向上层提供的是无连接不可靠的传输服务，也就是说IP数据报可能在传输过程中出现丢失或误码，但只要运输层使用TCP协议，就可向其上层提供面向连接的可靠传输服务。

我们可将其想象成使用TCP协议的收发双方基于TCP连接的可靠信道进行数据传输，不会出现误码丢失乱序以及重复等传输差错。TCP适用于要求可靠传输的应用，例如文件传输。

5.3.5 数据报首部

一个UDP用户数据报由首部和数据载荷两部分构成，其首部格式如图所示，仅有4个字段，每个字段长度为2个字节。由于UDP不提供可靠传输服务，它仅仅在网际层的基础上添加了用于区分应用进程的端口。因此，他的首部非常简单，仅有8个字节。

一个TCP报文段由首部和数据载荷两部分构成，其首部格式如图所示，比UDP用户数据报的首部复杂得多，其最小长度为20字节，最大长度为60字节，这是因为TCP要实现可靠传输、流量控制、拥塞控制等服务，其首部自然会比较复杂。

总结

5.4 TCP的流量控制

具体内容如下。

举例

假设主机A和B是因特网上的两台主机，他们之间已经建立了TCP连接。

A给B发送数据，B对A进行流量控制。

这是主机A中待发送数据的字节序号。

假设主机A发送的每个TCP报文段可携带100字节数据。因此图中每个小格子表示100个字节数据的序号。

在主机A和B建立TCP连接时，B告诉A我的接收窗口为400，因此主机A将自己的发送窗口也设置为400，这意味着主机A在未收到主机B发来的确认时，可将序号落入发送窗口中的全部数据发送出去。

举例介绍流量控制。

主机A将发送窗口内序号1到100的数据封装成一个TCP报文段发送出去。

发送窗口内还有300字节可以发送。

这里的seq是TCP报文段首部中的序号字段，取值1表示TCP报文段数据载荷的第一个字节的序号是1。这里的data表示这是TCP数据报文段。

主机A将发送窗口内序号101到200的数据封装成一个TCP报文段发送出去。发送窗口内还有200字节可以发送。

主机A将发送窗口内序号201到300的数据封装成一个TCP报文段发送出去，但该报文段在传输过程中丢失了。

主机A发送窗口内还有100字节可以发送。

主机B对主机A所发送的201号以前的数据进行累计确认，并在该累计确认将窗口字段的值调整为300，也就是对主机A进行流量控制。

这里的大写ACK是TCP报文段首部中的标志位，取值一表示这是一个TCP确认报文段。小写ACK是TCP报文段首部中的确认号字段，取值201表示序号201之前的数据已全部正确接收，现在希望收到序号201及其后续数据。rwnd是TCP报文段首部中的窗口字段，取值300表示自己的接收窗口大小为300。

主机A收到该累计确认后，将发送窗口向前滑动，使已发送并收到确认的这些数据的序号移除发送窗口。

由于主机B在该累计确认中将自己的接收窗口调整为了300，因此主机A相应地将自己的发送窗口调整为300。

目前主机A发送窗口内的序号为201到500，也就是主机A还可以发送这300字节，其中201到300号字节是已发送的数据。若重传计时器超时，他们会被重传。

301号到400号之间以及401号到500号之间的字节还未被发送，可被分别封装在一个TCP报文段中发送。

主机A现在可将发送缓存中序号1到200的字节数据全部删除了，因为已经收到了主机B对他们的累计确认。

主机A将发送窗口内序号301到400的数据封装成一个TCP报文段发送出去。

发送窗口还有100字节可以发送。

主机A将发发送窗口内序号401到500的数据封装成一个TCP报文段发送出去。

至此，序号落在发送窗口内的数据已经全部发送出去了，不能再发送新数据了。

现在发送窗口内序号201到300这一百字节数据的重传计时器超时了。主机A将他们重新封装成一个TCP报文段发送出去，暂时不能发送其他数据。

这块的意思就是接收方会发送确认报文，里面包括接收窗口的调整，以此实现对发送方的流量控制。

TCP规定，即使接收窗口为0，也必须接收零窗口探测报文段、确认段以及携带有紧急数据的报文段。

零窗口探测报文段也有重传计时器。当重传计时器超时后零窗口探测报文段会被重传。

练习题

说明：

总结

例子看明白就行了，不用记笔记。

5.5 TCP的拥塞控制

具有理想拥塞控制的网络，在吞吐量达到饱和之前，网络吞吐量等于所输入的负载。

吞吐量达到饱和后，随着输入负载的增加，吞吐量仍不变化，说明有一部分的输入分组被丢弃了。

而实际的情况却是，随着输入负载的增大，网络吞吐量的增长率逐渐减小，即网络吞吐量未达到饱和时，就有一部分的数据分组被丢弃了。

网络吞吐量明显小于理想吞吐量时，网络就进入了轻度拥塞的状态。

当输入负载到达某一限度时，网络吞吐量不增反降，此时网络进入拥塞状态。当输入负载继续增加到某一数值时，网络吞吐量减小为0，此时网络无法工作，这就是所谓的死锁。因此进行拥塞控制十分必要。

实际的拥塞控制曲线应十分接近理想的拥塞控制曲线。

TCP的4种拥塞控制算法。p61 3:00-end

5.6 TCP超时重传时间的选择

具体内容如下。

注意往返时间RTT的概念。

RTTs和RTTD都是基于所测量的样本RTT计算的。

RTT测量不准的情况。

karn算法

举例

总结

5.7 TCP可靠传输的实现

具体内容如下。

直接去看ppt吧ppt 1222-1249.

练习题

解析

练习题2

总结

5.8 TCP的运输连接管理

5.8.1 TCP的连接建立

1 TCP使用三报文握手建立连接

ppt 1267-

p64 4:00-

这是两台要基于TCP进行通信的主机，其中一台主机中的某应用进程主动发起TCP连接建立，称为TCP客户，另一台主机中被动等待TCP连接建立的应用进程，称为TCP服务器。

我们可以将TCP建立连接的过程比喻为握手。握手需要在TCP客户和服务器之间交换3个TCP报文段。

① 最初，两端的TCP进程都处于关闭状态。

② 一开始，TCP服务器进程首先创建传输控制块，用来存储TCP连接中的一些重要信息，例如TCP连接表、指向发送和接收缓存的指针、指向重传队列的指针、当前发送和接收序号等。

③ 之后就要准备接受TCP客户进程的连接请求。此时，TCP服务器进程就要进入监听状态，等待TCP客户进程的连接请求。TCP服务器进程是被动等待来自TCP客户进程的连接请求，而不是主动发起，因此称为被动打开连接。

④ TCP客户进程也是首先创建传输控制块，

⑤ 然后，TCP客户进程在打算建立TCP连接时，向TCP服务器进程发送TCP连接请求报文段，并进入同步已发送状态。TCP连接请求报文段首部中的同步位SYN被设置为1，表明这是一个TCP连接请求报文段，序号字段seq被设置了一个初始值x作为TCP客户进程所选择的初始序号。

请注意，TCP规定，SYN被设置为1的报文段，不能携带数据，但要消耗掉一个序号。

⑥ 由于TCP连接建立是由TCP客户进程主动发起的，因此称为主动打开连接。

⑦ TCP服务器进程收到TCP连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态。该报文段首部中的同步位SYN和确认位ACK都设置为1，表明这是一个TCP连接请求确认报文段。序号字段seq被设置了一个初始值y，作为TCP服务器进程所选择的初始序号。确认号字段ack的值被设置成了x+1，这是对TCP客户进程所选择的初始序号的确认。

请注意，这个报文段也不能携带数据，因为它是SYN被设置为1的报文段，但同样要消耗掉一个序号。

⑧ TCP客户进程收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP确认报文段，并进入连接已建立状态。该报文段首部中的确认位ACK被设置为1，表明这是一个普通的TCP确认报文段 。序号字段seq被设置为x+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x，并且不携带数据，因此第二个报文段的序号为x+1。确认号字段ack被设置为y+1，这是对TCP服务器进程所选择的初始序号的确认。

请注意，TCP规定普通的TCP确认报文段可以携带数据，但如果不携带数据，则不消耗序号。在这种情况下，所发送的下一个数据报文段的序号仍是x+1。

⑨ TCP服务器进程收到该确认报文段后，也进入连接已建立状态。

现在TCP双方都进入了连接建立状态，他们可以基于已建立好的TCP连接进行可靠的数据传输了。

请同学们思考这样一个问题，为什么TCP客户进程最后还要发送一个普通的TCP确认报文段？这是否多余？换句话说，能否使用两报文握手建立连接？

答案是并不多余，不能简化为两报文握手。

原因分析

原因如上图。考虑这样一种情况，TCP客户进程发出一个TCP连接请求报文段，但该报文段在某些网络结点长时间滞留了，这必然会造成该报文段的超时重传。

假设重传的报文段被TCP服务器进程正常接收，TCP服务器进程向TCP客户进程发送一个TCP连接请求确认报文段并进入连接已建立状态。

请注意，由于我们改为两报文握手，因此TCP服务器进程发送完TCP连接请求确认报文段后，进入的是连接已建立状态 ，++而不像三报文握手那样进入同步接收状态，++等待TCP客户进程发来针对TCP连接请求确认报文段的普通确认报文段。

TCP客户进程收到TCP连接请求确认报文段后，进入TCP连接建立状态，但不会给TCP服务器进程发送针对该报文段的普通确认报文段。

现在TCP双方都处于连接已建立状态，他们可以相互传输数据。之后可以通过四报文挥手来释放连接。TCP双方都进入了关闭状态。

问题来了：一段时间后，之前滞留在网络中的那个失效的TCP连接请求报文段到达了TCP服务器进程，TCP服务器进程会误认为这是TCP客户进程要发起了一个新的TCP连接请求，于是给TCP客户进程发送TCP连接请求确认报文段，并进入连接已建立状态。

该报文段到达TCP客户进程，由于TCP客户进程并没有发起新的TCP连接请求。并且处于关闭状态，因此不会理会该报文段。

但TCP服务器进程已进入了连接已建立状态，它认为新的TCP连接建立好了，并一直等待TCP客户进程发来数据。

这将白白浪费TCP服务器进程所在主机的很多资源。

综上所述，采用三报文握手而不是两报文握手来建立TCP连接是为了防止已失效的连接请求报文段突然又传送到了TCP服务器进程 ，因而导致错误。

练习题

5.8.2 TCP的连接释放

具体内容如下。

1 TCP使用四报文挥手释放连接

TCP通过四报文挥手来释放连接。

举例来看，数据传输结束后，TCP通信双方都可以释放连接。

现在TCP客户进程和TCP服务器进程都处于连接已建立状态。

① 假设使用TCP客户进程的应用程序通知其主动关闭TCP连接。

TCP客户进程会发送TCP连接释放报文段，并进入终止等待1状态，该报文段首部中的终止位FIN确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认。序号seq字段的值设置为u，它等于TCP客户进程之前已传送过的数据的最后一个字节的序号加1 。确认号ACK字段的值设置为v，它等于TCP客户进程之前已收到的数据的最后一个字节的序号加1。

请注意，TCP规定终止为FIN等于1的报文段，即使不携带数据，也要消耗掉一个序号。

② TCP服务器进程收到TCP连接释放报文段后，会发送一个普通的TCP确认报文段并进入关闭等待状态。

该报文段首部中的确认位ACK的值被设置为1，表明这是一个普通的TCP确认报文段。

序号seq字段的值设置为v，它等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加一， 这也与之前收到的TCP连接释放报文段中的确认号匹配。

确认ack字段的值设置为u+1，这是对TCP连接释放报文段的确认。

③ TCP服务器进程这时应通知高层应用进程，TCP客户进程要断开与自己的TCP连接。

此时从TCP客户进程到TCP服务器进程这个方向的连接就释放了。这时的**TCP连接属于半关闭状态，**也就是TCP客户进程已经没有数据要发送了。但TCP服务器进程如果还有数据要发送，TCP客户进程仍要接收。

也就是说从TCP服务器进程到TCP客户进程这个方向的连接并未关闭，这个状态可能会持续一段时间。

TCP客户进程收到TCP确认报文段后，就进入终止等待2状态，等待TCP服务器进程发出的TCP连接释放报文段。

如果使用TCP服务器进程的应用进程已经没有数据要发送了，应用进程就通知其TCP服务器进程释放连接。

由于TCP连接释放是由TCP客户进程主动发起的，因此TCP服务器进程对TCP连接的释放称成为被动关闭连接。

④ TCP服务器进程发送TCP连接释放报文段，并进入最后确认状态，该报文段首部中的终止位FIN和确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认。

现在假定序号seq字段的值为w，这是因为在半关闭状态下，TCP服务器进程可能又发送了一些数据。

确认位ack字段的值为u+1，这是对之前收到的TCP连接释放报文段的重复确认。

⑤ TCP客户进程收到TCP连接释放报文段后，必须针对该报文段发送普通的TCP确认报文段，之后进入时间等待状态。

该报文段首部中的确认位的值被设置为1，表明,这是一个普通的TCP确认报文段。

序号seq字段的值设置为u加1，这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据，但要消耗掉一个序号。

序号ack字段的值设置为w+1，这是对所收到的TCP连接释放报文段的确认。

⑥ TCP服务器进程收到该报文段号就进入关闭状态。而TCP客户进程还要经过两倍的MSL后才能进入关闭状态。

MSL的意思是最长报文段寿命，RFC793文档建议为2分钟，就是说TCP客户进程进入时间等待状态后，还要经过4分钟才能进入关闭状态，这完全是从工程上来考虑的。

对于现在的网络，MSL取为2分钟，可能太长了。因此TCP允许不同的实现，可根据具体情况需要更小的MSL值。

那么TCP客户进程在发送完最后一个确认报文段号，为什么不直接进入关闭状态，而是要进入时间等待状态？两倍MSL号才进入关闭状态这是否有必要？

原因分析

来看这种情况，TCP服务器进程发送TCP连接释放报文段后进入最后确认状态。

TCP客户进程收到该报文段号发送普通的TCP确认报文段并进入关闭状态，而不是时间等待状态。

问题来了：然而TCP确认报文段丢失了，这必然会造成TCP服务器进程对之前所发送的TCP连接释放报文段的超时重传，并仍处于最后确认状态。

重传的TCP连接释放报文段到达TCP客户进程。由于TCP客户进程属于关闭状态，因此不理睬该报文段。这必然会造成TCP服务器进程反复重传TCP连接释放报文段 ，并一直处于最后确认状态而无法进入关闭状态。

因此时间等待状态以及处于该状态两倍MSL的时长可以确保TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态。

另外TCP客户进程在发送完最后一个TCP确认报文段后，再经过两倍MSL时长，就可以使本次连接持续时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的TCP连接中，不会出现旧连接中的报文段。

以上就是TCP通过四道文挥手释放连接的过程。

最后我们再来看看TCP中保活计时器的作用。

2 保活计时器

总结

5.9 TCP报文段的首部格式

具体内容如下。

5.9.1 源端口和目的端口

1 源端口和目的端口的作用

我们来举例说明源端口和目的端口的作用。

假设主机中的浏览器进程要访问Web服务器中的Web服务器进程。

为了简单起见，我们仅从运输层端口号这个角度来举例说明，而不考虑其他细节，例如ARP、域名解析，TCP连接建立等。

① 当在浏览器地址栏中输入了Web服务器的域名后，浏览器进程会构建一个封装有HTTP请求报文的TCP报文段 ，该报文段首部中的源端口字段会填写一个短暂端口号 ，例如49152，用来标识发送该报文段的浏览器进程。目的端口字段会填写熟知端口号80，因为使用HTTP协议的Web服务器进程默认监听该端口。