【网络篇】计算机网络——运输层详述（笔记）

一、运输层

1. 概述

2. 运输层和网络层的关系

3. 运输层协议概述

二、多路复用和多路分解

1. 综述

2. 无连接的多路复用与多路分解（UDP）

3. 面向连接的多路复用与多路分解（TCP）

4. Web 服务器与TCP

三、UDP（无连接运输）

1. 综述

2. UDP 报文段结构

四、TCP（面向连接的运输）

1. TCP 连接概述

2. TCP报文结构

3. TCP 连接管理

（1）连接建立

（2）连接断开

（3）客户端状态转换

（4）服务器端状态转换

一、运输层

运输层位于 应用层和网络层之间，是分层的网络体系结构的重要部分。该层 为运行在不同主机上的应用进程提供直接的通信服务起着至关重要的作用。

1. 概述

运输层协议为运行在不同主机上的应用进程之间提供了逻辑通信（logic communica-tion）功能。

从应用程序的角度看，通过逻辑通信，运行不同进程的主机好像直接相连一样；实际上，这些主机也许位于地球的两侧，通过很多路由器及多种不同类型的链路相连。

应用进程使用运输层提供的逻辑通信功能彼此发送报文，而无须考虑承载这些报文的物理基础设施的细节。

运输层协议是在端系统中而不是在路由器中实现的。

在发送端，运输层将从发送应用程序进程接收到的报文转换成运输层分组，用因特网术语来讲该分组称为运输层 报文段（segment）。实现的方法（可能）是将应用报文划分为较小的块，并每块加上一个运输层首部以生成运输层报文段。

在发送端系统中，运输层将这些报文段传递给网络层，网路层将其封装成网络层分组（即数据报）并向目的地发送。

在接收端，网络层从数据报中提取运输层报文段，并将该报文段向上交给运输层。运输层则处理接收到的报文段，使该报文段中的数据为接收应用进程使用。

网络应用程序可以使用多种的运输层协议，每种协议都能为调用的应用程序提供一组不同的运输层服务。

注意：

网络路由器仅作用于该数据报的网络层字段；即它们不检查封装在该数据报的运输层报文段的字段。

2. 运输层和网络层的关系

在协议栈中，运输层刚好位于网络层之上。网络层提供了主机之间的逻辑通信，而运输层为运行在不同主机上的进程之间提供了逻辑通信。

这里用一个家庭类比来帮助分析这种差别。

        考虑有两个家庭，一家位于美国东海岸，一家位于美国西海岸，每家有12个孩子。东海岸家庭的孩子们是西海岸家庭孩子们的堂兄弟姐妹。

        这两个家庭的孩子们喜欢彼此通信，每个人每星期要互相写一封信，每封信都用单独的信封通过传统的邮政服务传送。因此，每个家庭每星期向另一家发送144 封信。

        每一个家庭有个孩子负责收发邮件，西海岸家庭是 Ann 而东海岸家庭是 Bill。每星期 Ann 去她的所有兄弟姐妹那里收集信件，并将这些信件交到每天到家门口来的邮政服务的邮车上。当信件到达西海岸家庭时，Ann 也负责将信件分发到她的兄弟姐妹手上。在东海岸家庭中的Bill 也负责类似的工作。

在这个例子中，邮政服务为两个家庭间提供逻辑通信，邮政服务将信件从一家送往另一家，而不是从一个人送往另一个人。在另一方面，Ann 和Bill 为堂兄弟姐妹之间提供了逻辑通信，Ann 和 Bill 从兄弟姐妹那里收取信件或到兄弟姐妹那里交付信件。注意到从堂兄弟姐妹们的角度来看，Ann 和 Bill 就是邮件服务，尽管他们只是端到端交付过程的一部分（即端系统部分）。

应用层报文 = 信封上的字符
进程 = 堂兄弟姐妹
主机（又称为端系统）= 家庭
运输层协议 = Ann 和 Bill
网络层协议 = 邮政服务（包括邮车）

值得注意的是，Ann 和 Bill 都是在各自家里进行工作的；例如，他们并没有参与任何一个中间邮件中心对邮件进行分拣，或者将邮件从一个邮件中心送到另一个邮件中心之类的工作。类似地，运输层协议只工作在端系统中。

在端系统中，运输层协议将来自应用进程的报文移动到网络边缘（即网络层），反过来也是一样，但对有关这些报文在网络核心如何移动并不作任何规定。

事实上，中间路由器既不处理也不识别运输层加在应用层报文的任何信息。

现在假定 Ann 和 Bill 外出度假，另外一对堂兄妹（如 Susan 和 Harvey）接替他们的工作，在家庭内部进行信件的收集和交付工作。

不幸的是，Susan 和 Harvey 的收集和交付工作与 Ann 和 Bill 所做的并不完全一样。由于年龄更小，Susan 和 Harvey 收发邮件的次数更少，而且偶尔还会丢失邮件（有时是被家里的狗咬坏了）。因此，Susan 和 Harvey 这对堂兄妹并没有提供与 Ann 和 Bill一样的服务集合（即相同的服务模型）。

与此类似，计算机网络中可以安排多种运输层协议，每种协议为应用程序提供不同的服务模型。Ann 和 Bill 所能提供的服务明显受制于邮政服务所能提供的服务。例如，如果邮政服务不能提供在两家之间传递邮件所需时间的最长期限（例如3天），那么 Ann 和 Bill 就不可能保证邮件在堂兄弟姐妹之间传递信件的最长期限。

与此类似，运输协议能够提供的服务常常受制于底层网络层协议的服务模型。如果网络层协议无法为主机之间发送的运输层报文段提供时延或带宽保证的话，运输层协议也就无法为进程之间发送的应用程序报文提供时延或带宽保证。

然而，即使底层网络协议不能在网络层提供相应的服务，运输层协议也能提供某些服务。例如，即使底层网络协议是不可靠的，也就是说网络层协议会使分组丢失、篡改和冗余，运输协议也能为应用程序提供可靠的数据传输服务。

另一点是，即使网络层不能保证运输层报文段的机密性，运输协议也能使用加密来确保应用程序报文不被人侵者读取。

3. 运输层协议概述

因特网为应用层提供了两种截然不同的可用运输层协议。这些协议一种是 UDP（用户数据报协议），它为调用它的应用程序提供了一种不可靠、无连接的服务。另一种是 TCP（传输控制协议），它为调用它的应用程序提供了一种可靠的、面向连接的服务。

当设计一个网络应用程序时，该应用程序的开发人员在生成套接字时必须指定是选择 UDP 还是选择 TCP。

我们将运输层分组称 报文段（segment）。将 UDP 的分组称为数据报（data-gram）。

因特网网络层协议有一个名字叫 IP，即网际协议。IP 为主机之间提供了逻辑通信。IP 的服务模型是尽力而交付服务（best-effort delivery serv-ice）。这意味着 IP 尽它 “ 最大的努力 ” 在通信的主机之间交付报文段，但它并不做任何确保。特别是，它不确保报文段的交付，不保证报文段的按序交付，不保证报文段中数据的完整性。由于这些原因，IP 被称不可靠服务（unreliable service）。每台主机至少有一个网络层地址，即所谓的 IP 地址。

UDP 和 TCP 最基本的责任是，将两个端系统间IP 的交付服务扩展为运行在端系统上的两个进程之间的交付服务。将主机间交付扩展到进程间交付被称 运输层的多路复用（transport-layer multiplexing）与多路分解（demultiplexing）。UDP 和 TCP 还可以通过在其报文段首部中包括差错检查字段而提供完整性检查。

进程到进程的数据交付和差错检查是两种最低限度的运输层服务，也是 UDP 所能提供的仅有的两种服务。特别的，与 IP 一样，UDP 也是一种不可靠的服务，即不能保证一个进程所发送的数据能够完整无缺地到达目的进程。

另一方面，TCP 为应用程序提供了几种附加服务。首先，它提供可靠数据传输（relia-ble data transfer）。通过使用流量控制、序号、确认和定时器，TCP 确保正确地、按序地将数据从发送进程交付给接收进程。这样，TCP 就将两个端系统间的不可靠 IP 服务转换成了一种进程间的可靠数据传输服务。

TCP 还提供拥塞控制（con-gestion control）。拥塞控制与其说是一种提供给调用它的应用程序的服务，不如说是一种提供给整个因特网的服务，这是一种带来通用好处的服务。不太严格地说，TCP 拥塞控制防止任何一条 TCP 连接用过多流量来淹没通信主机之间的链路和交换设备。TCP 力求为每个通过一条拥塞网络链路的连接平等地共享网络链路带宽。这可以通过调节 TCP 连接的发送端发送进网络的流量速率来做到。

另一方面，UDP 流量是不可调节的。使用 UDP 传输的应用程序可以根据其需要以其愿意的任何速率发送数据。

二、多路复用和多路分解

1. 综述

在目的主机，运输层从紧邻其下的网络层接收报文段。运输层负责将这些报文段中的数据交付给在主机上运行的适当应用程序进程。

再来看一个例子。假定你正坐在计算机前下载 Web 页面，同时还在运行一个 FTP 会话和两个 Telnet 会话。这样就有 4 个网络应用进程在运行，即两个 Telnet 进程，一个 FTP 进程和一个 HTTP 进程。当你的计算机中的运输层从底层的网络层接收数据时，它需要将所接收到的数据定向到这 4 个进程中的一个。现在来研究这是怎样完成的。

一个进程（作为网络应用的一部分）有一个或多个套接字（socket），它相当于从网络向进程传递数据和从进程向网络传递数据的门户。因此，在接收主机中的运输层实际上并没有直接将数据交付给进程，而是将数据交给了一个中间的套接字。

由于在任一时刻，在接收主机上可能有不止一个套接字，所以每个套接字都有唯一的标识符。标识符的格式取决于它是 UDP 还是 TCP 套接字。

现在考虑接收主机怎样将一个到达的运输层报文段定向到适当的套接字。为此目的，每个运输层报文段中具有几个字段。在接收端，运输层检查这些字段，标识出接收套接字，进而将报文段定向到该套接字。

将运输层报文段中的数据交付到正确的套接字的工作称为 多路分解（demultiplexing）。

在源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息（这将在以后用于分解）从而生成报文段，然后将报文段传递到网络层，所有这些工作称为多路复用（multiplexing）。

上图中间的那台主机的运输层必须将从其下的网络层收到的报文段分解后交给其上的 P1 或 P2 进程；这一过程是通过将到达的报文段数据定向到对应进程的套接字来完成的。

中间主机中的运输层也必须收集从这些套接字输出的数据，形成运输层报文段，然后将其向下传递给网络层。

那它们在主机中实际是怎样工作的？从上述中运输层多路复用要求为：① 套接字有唯一标识符；② 每个报文段有特殊字段来指示该报文段所要交付到的套接字。

这些特殊字段是 源端口号字段（source port number field）和目的端口号字段（destination port number field）。端口号是一个 16 比特的数，其大小在 0~65535 之间。

0~1023 范围的端口号称为 周知端口号（well-known portnumber），是受限制的，这是指它们保留给诸如 HTTP（它使用端口号 80）和 FTP（它使用端口号 21）之类的周知应用层协议来使用。当我们开发一个新的应用程序时，必须为其分配一个端口号。

2. 无连接的多路复用与多路分解（UDP）

（1）当我们使用 socket（）函数创建一个 UDP 套接字时，运输层自动地为该套接字分配一个端口号。特别是，运输层从范围 1024~65535 内分配一个端口号，该端口号是当前未被该主机中任何其他 UDP 端口使用的号。

（2）另外一种方法是，在创建一个套接字后，我们能够通过套接字 bind（）方法为这个 UDP 套接字关联一个特定的端口号。

（3）如果应用程序开发者所编写的代码实现的是一个 “ 周知协议 ” 的服务器端，那么开发者就必须为其分配一个相应的周知端口号。

通常，应用程序的客户端让运输层自动地（并且是透明地）分配端口号，而服务器端则分配一个特定的端口号。

假定在主机 A 中的一个进程具有 UDP 端口 19157，它要发送一个应用程序数据块给位于主机 B 中的另一进程，该进程具有 UDP 端口 46428。

主机 A 中的运输层创建一个运输层报文段，其中包括应用程序数据、源端口号（19157）、目的端口号（46428）和两个其他值。

然后，运输层将得到的报文段传递到网络层。网络层将该报文段封装到一个 IP 数据报中，并尽力而为地将报文段交付给接收主机。

如果该报文段到达接收主机 B，接收主机运输层就检查该报文段中的目的端口号（46428）并将该报文段交付给端口号 46428 所标识的套接字。

注意：

① 主机 B 能够运行多个进程，每个进程有自己的 UDP 套接字及相应的端口号。当UDP 报文段从网络到达时，主机 B 通过检查该报文段中的目的端口号，将每个报文段定向（分解）到相应的套接字。

② 一个 UDP 套接字是由一个二元组全面标识的，该二元组包含一个目的 IP 地址和一个目的端口号。因此。如果两个 UDP 报文段有不同的源 IP 地址或源端口号，但具有相同的目的 IP 地址和目的端口号，那么这两个报文段将通过相同的目的套接字被定向到相同的目的进程。

源端口号的用途是什么呢？

在 A 到 B 的报文段中，源端口号用作 “ 返回地址 ” 的一部分，即当 B 需要回发一个报文段给 A 时，B 到 A 的报文段中的目的端口号便从 A 到 B 的报文段中的源端口号中取值。（完整的返回地址是 A 的 IP 地址和源端口号。）

3. 面向连接的多路复用与多路分解（TCP）

TCP 套接字和 UDP 套接字之间的一个细微差别是，TCP 套接字是由一个四元组（源 IP 地址，源端口号，目的 IP 地址，目的端口号）来标识的。因此，当一个 TCP 报文段从网络到达一台主机时，该主机使用全部 4 个值来将报文段定向（分解）到相应的套接字。

与 UDP 不同的是，两个具有不同源 IP 地址或源端口号的到达 TCP 报文段将被定向到两个不同的套接字，除非 TCP 报文段携带了初始创建连接的请求。

举个 TCP 客户-服务区编程的例子：

TCP服务器应用程序有一个 “ 欢迎套接字 ” ，它在 12000 号端口上等待来自 TCP 客户的连接建立请求。
TCP 客户使用 socket（）函数创建一个套接字并使用 connect（）函数发送一个连接建立请求报文段。
一条连接建立请求只不过是一个目的端口号为 12000，TCP 首部的特定 “ 连接建立位 ” 置位的 TCP 报文段。这个报文段也包含一个由客户选择的源端口号。
当运行服务器进程的计算机的主机操作系统接收到具有目的端口 12000 的人连接请求报文段后，它就 定位服务器进程，该进程正在端口号 12000 等待接受连接。该服务器进程则创建一个新的客户端套接字。
该服务器的运输层还注意到连接请求报文段中的下列 4 个值：① 该报文段中的源端口号；② 源主机IP 地址；③ 该报文段中的目的端口号；④ 自身的 IP 地址。新创建的连接套接字通过这 4 个值来标识。所有后续到达的报文段，如果它们的源端口号、源主机 IP 地址、目的端口号和目的 IP 地址都与这 4 个值匹配，则被分解到这个套接字。
随着 TCP 连接完成，客户和服务器便可相互发送数据了。

服务器主机可以支持很多并行的 TCP 套接字，每个套接字与一个进程相联系，并由其四元组来标识每个套接字。

当一个 TCP 报文段到达主机时，所有 4 个字段（源 IP 地址，源端口，目的 IP 地址，目的端口）被用来将报文段定向（分解）到相应的套接字。

上图中主机 C 向服务器 B 发起了两个 HTTP 会话，主机 A 向服务器 B 发起了一个 HTTP 会话。主机 A 与主机 C 及服务器 B 都有自己唯一的 IP 地址，它们分别是 A、C、B。

主机 C 为其两个 HTTP 连接分配了两个不同的源端口号（26145 和 7532）。因为主机 A 选择源端口号时与主机 C 互不相干，因此它也可以将源端口号 26145 分配给其 HTTP 连接。服务器 B 仍然能够正确地分解这两个具有相同源端口号的连接，因为这两条连接有不同的源 IP 地址。

4. Web 服务器与TCP

考虑一台运行 Web 服务器的主机，例如在端口 80 上运行一个 Apache Web 服务器。

当客户（如浏览器）向该服务器发送报文段时，所有报文段的目的端口都将为 80。特别是，初始连接建立报文段和承载 HTTP 请求的报文段都有 80 的目的端口。该服务器能够根据源 IP 地址和源端口号来区分来自不同客户的报文段。

上图显示了一台 Web 服务器为每条连接生成一个新进程。每个这样的进程都有自己的连接套接字，通过这些套接字可以收到 HTTP 请求和发送 HTTP 响应。

然而，连接套接字与进程之间并非总是有着一一对应的关系。事实上，当今的高性能 Web 服务器通常只使用一个进程，但是为每个新的客户连接创建一个具有新连接套接字的新线程。对于这样一台服务器，在任意给定的时间内都可能有（具有不同标识的）许多连接套接字连接到相同的进程。

如果客户与服务器使用 持续 HTTP，则在整条连接持续期间，客户与服务器之间经由同一个服务器套接字交换 HTTP 报文。

然而，如果客户与服务器使用 非持续 HTTP，则对每一对请求 / 响应都创建一个新的 TCP连接并在随后关闭，因此对每一对请求 / 响应创建一个新的套接字并在随后关闭。这种套接字的频繁创建和关闭会严重地影响一个繁忙的 Web 服务器的性能（尽管有许多操作系统技巧可用来减轻这个问题的影响）。

三、UDP（无连接运输）

1. 综述

UDP 只是做了运输协议能够做的最少工作。除了复用 / 分解功能及少量的差错检测外，它几乎没有对 IP 增加别的东西。

UDP 从应用进程得到数据，附加上用于多路复用 / 分解服务的源和目的端口号字段，以及两个其他的小字段，然后将形成的报文段交给网络层。网络层将该运输层报文段封装到一个 IP 数据报中，然后尽力而为地尝试将此报文段交付给接收主机。如果该报文段到达接收主机，UDP 使用目的端口号将报文段中的数据交付给正确的应用进程。

值得注意的是，使用 UDP 时，在发送报文段之前，发送方和接收方的运输层实体之间没有握手。正因为如此，UDP 被称为是无连接的。

        DNS 是一个通常使用 UDP 的应用层协议的例子。

        当一台主机中的 DNS 应用程序想要进行一次查询时，它构造了一个 DNS 查询报文并将其交给 UDP。无须执行任何与运行在目的端系统中的 UDP 实体之间的握手，主机端的 UDP 为此报文添加首部字段，然后将形成的报文段交给网络层。

        网络层将此 UDP 报文段封装进一个 IP 数据报中，然后将其发送给一个名字服务器。在查询主机中的 DNS 应用程序则等待对该查询的响应。

        如果它没有收到响应（可能是由于底层网络丢失了查询或响应），则要么试图向另一个名字服务器发送该查询，要么通知调用的应用程序它不能获得响应。

2. UDP 报文段结构

应用层数据占用 UDP 报文段的数据字段。例如，对于 DNS应用，数据字段要么包含一个查询报文，要么包含一个响应报文。

UDP 首部只有 4 个字段，每个字段由两个字节组成。通过端口号可以使目的主机将应用数据交给运行在目的端系统中的相应进程（即执行分解功能）。

长度字段指示了在 UDP 报文段中的字节数（首部加数据）。因为数据字段的长度在一个 UDP 段中不同于在另一个段中，故需要一个明确的长度。

接收方使用检验和来检查在该报文段中是否出现了差错。

四、TCP（面向连接的运输）

1. TCP 连接概述

TCP 被称为是面向连接的（connection-oriented），这是因为在一个应用进程可以开始向另一个应用进程发送数据之前，这两个进程必须先相互 “ 握手 ” ，即它们必须相互发送某些预备报文段，以建立确保数据传输的参数。作为 TCP 连接建立的一部分，连接的双方都将初始化与 TCP 连接相关的许多 TCP 状态变量。

这种 TCP “ 连接 ” 不是一条像在电路交换网络中的端到端 TDM 或 FDM 电路。相反，该 “ 连接 ” 是一条逻辑连接，其共同状态仅保留在两个通信端系统的 TCP 程序中。由于 TCP 协议只在端系统中运行，而不在中间的网络元素（路由器和链路层交换机）中运行，所以 中间的网络元素不会维持 TCP 连接状态。事实上，中间路由器对 TCP连接完会视而不见，它们看到的是数据报而不是连接。

TCP 连接总是点对点（point-to-point）的，即在单个发送方与单个接收方之间的连接。所谓 “多播”，即在一次发送操作中，从一个发送方将数据传送给多个接收方，这种情况对 TCP 来说是不可能的。对于 TCP 而言，两台主机是一对，而 3 台主机则太多了。

现在来看看 TCP 连接是怎样建立的。

假设运行在某台主机上的一个进程（客户进程）想与另一台主机上的一个进程（服务器进程）建立一条连接。该客户应用进程首先使用 connect（）函数通知客户运输层，它想与服务器上的一个进程建立一条连接。

客户上的 TCP 便开始与服务器上的 TCP 建立一条 TCP 连接。客户首先发送一个特殊的TCP 报文段，服务器用另一个特殊的 TCP 报文段来响应，最后，客户再用第三个特殊报文段作为响应。

前两个报文段不承载 “ 有效载荷 ” ，即不包含应用层数据；而第三个报文段可以承载有效载荷。由于在这两台主机之间发送了 3 个报文段，所以这种连接建立过程常被称为三次握手（three-way handshake）。

一旦建立起一条 TCP 连接，两个应用进程之间就可以相互发送数据了。

现在考虑一下从客户进程向服务器进程发送数据的情况。

客户进程通过套接字（该进程之门）传递数据流。数据一旦通过该门，它就由客户中运行的 TCP 控制了。如上图所示，TCP 将这些数据引导到该连接的 发送缓存（send buffer）里，发送缓存是发起三次握手期间设置的缓存之一。

接下来 TCP 就会不时从发送缓存里取出一块数据，并将数据传递到网络层。TCP 可从缓存中取出并放入报文段中的数据数量受限于最大报文段长度（Maximum Segment Size，MSS）。MSS 通常根据最初确定的由本地发送主机发送的 最大链路层帧长度（即所谓的 最大传输单元（Maximum Transmission Unit, MTU））来设置。设置该 MSS 要保证一个 TCP 报文段（当封装在一个 IP 数据报中）加上 TCP/IP 首部长度（通常 40 字节）将适合单个链路层帧。

TCP 为每块客户数据配上一个 TCP 首部，从而形成多个 TCP 报文段（TCP segment）。这些报文段被下传给网络层，网络层将其分别封装在网络层 IP 数据报中。然后这些 IP 数据报被发送到网络中。

当 TCP 在另一端接收到一个报文段后，该报文段的数据就被放人该 TCP 连接的接收缓存中，如上图中所示。应用程序从此缓存中读取数据流。

2. TCP报文结构

TCP 报文段由首部字段和一个数据字段组成。

数据字段包含一块应用数据。其中 MSS 限制了报文段数据字段的最大长度。当 TCP 发送一个大文件，TCP 通常是将该文件划分成长度 MSS 的若干块（最后一块除外，它通常小于 MSS）。然而，交互式应用通常传送长度小于 MSS 的数据块。

与 UDP 一样，首部包括源端口号和目的端口号，它被用于多路复用 / 分解来自或送到上层应用的数据。另外，同 UDP一样，TCP 首部也包括检验和字段（checksum field）。

3. TCP 连接管理

（1）连接建立

来观察一下一条TCP 连接是如何建立的。假设运行在一台主机（客户）上的一个进程想与另一台主机（服务器）上的一个进程建立一条连接。

客户应用进程首先通知客户 TCP，它想建立一个与服务器上某个进程之间的连接。客户中的 TCP 会用以下方式与服务器中的 TCP 建立一条 TCP 连接：

第一步：客户端的 TCP 首先向服务器端的 TCP 发送一个特殊的 TCP 报文段。该报文段中不包含应用层数据。但是在报文段的首部中的一个标志位（即 SYN 比特）被置 1。因此，这个特殊报文段被称 SYN 报文段。另外，客户会随机地选择一个 初始序号（client_isn），并将此编号放置于该起始的 TCP SYN 报文段的序号字段中。该报文段会被封装在一个 IP 数据报中，并发送给服务器。

第二步：一旦包含 TCP SYN 报文段的 IP 数据报到达服务器主机（假定它的确到达了！），服务器会从该数据报中提取出 TCP SYN 报文段，为该 TCP 连接分配 TCP 缓存和变量，并向该客户 TCP 发送允许连接的报文段。这个允许连接的报文段也不包含应用层数据。但是，在报文段的首部却包含 3 个重要的信息。首先，SYN 比特被置为 1。其次，该 TCP 报文段首部的确认号字段被置为 client_isn +1。最后，服务器选择自己的 初始序号（server_isn），并将其放置到 TCP 报文段首部的序号字段中。这个允许连接的报文段实际上表明了：“ 我收到了你发起建立连接的 SYN 分组，该分组带有初始序号 client_isn。我同意建立该连接。我自己的初始序号是 server_isn。” 该允许连接的报文段被称为 SYNACK 报文段（SYNACK segment）。

第三步：在收到 SYNACK 报文段后，客户也要 给该连接分配缓存和变量。客户主机则向服务器发送另外一个报文段；这最后一个报文段 对服务器的允许连接的报文段进行了确认（该客户通过将值 server_isn +1 放置到 TCP 报文段首部的确认字段中来完成此项工作）。因为连接已经建立了，所以该 SYN 比特被置 0。

该三次握手的第三个阶段可以在报文段负载中携带客户到服务器的数据。以后每一个报文段中，SYN 比特都将被置为 0。

（2）连接断开

参与一条 TCP 连接的两个进程中的任何一个都能终止该连接。当连接结束后，主机中的 “ 资源 ”（即缓存和变量）将被释放。

举个例子，假设某客户打算关闭连接。

客户应用进程发出一个关闭连接命令。这会引起客户 TCP 向服务器进程发送一个特殊的TCP 报文段。这个特的报文段让其首部中的一个标志位即 FIN 比特被设置 1。

当服务器接收到该报文段后，就向发送方回送一个确认报文段。然后，服务器发送它自己的终止报文段，其 FIN 比特被置为 1。

最后，该客户对这个服务器的终止报文段进行确认。此时，在两台主机上用于该连接的所有资源都被释放了。

（3）客户端状态转换

在一个 TCP 连接的生命周期内，运行在每台主机中的 TCP 协议在各种 TCP 状态（TCP state）之间变迁。

客户 TCP开始时处于 CLOSED（关闭）状态。
客户的应用程序发起一个新的 TCP 连接。这引起客户中的 TCP 向服务器中的 TCP 发送一个 SYN 报文段。在发送过 SYN 报文段后，客户 TCP 进入了 SYN_SENT 状态。
当客户 TCP 处在 SYN_SENT 状态时，它等待来自服务器 TCP 的对客户所发报文段进行确认且 SYN 比特被置为 1 的一个报文段。收到这样一个报文段之后，客户 TCP 进入 ESTABLISHED（已建立）状态。

当处在 ESTABLISHED 状态时，TCP 客户就能发送和接收包含有效载荷数据（即应用层产生的数据）的 TCP 报文段了。

假设客户应用程序决定要关闭该连接。（服务器也能选择关闭该连接）

这引起客户 TCP 发送一个带有 FIN 比特被置为 1 的 TCP 报文段，并进入 FIN_WAIT_1 状态。
当处在 FIN_WAIT_1 状态时，客户 TCP 等待一个来自服务器的带有确认的 TCP 报文段。
当它收到该报文段时，客户 TCP 进入 FIN_WAIT_2状态。
当处在 FIN_WAIT_2 状态时，客户等待来自服务器的 FIN 比特被置为 1 的另一个报文段；当收到该报文段后，客户 TCP 对服务器的报文段进行确认，并进人 TIME_WAIT状态。
假定 ACK 丢失，TIME_WAIT 状态使 TCP 客户重传最后的确认报文。在 TIME_WAIT 状态中所消耗的时间是与具体实现有关的，而典型的值是 30秒、1分钟或 2分钟。经过等待后，连接就正式关闭，客户端所有资源（包括端口号）将被释放。