网络协议分析

URL解析：浏览器首先对用户输入的内容进行解析，判断它是一个网址还是一个搜索查询。如果是网址，浏览器会检查并补全URL中的协议部分（如http://或https://）。
DNS查询：解析完URL后，浏览器会通过域名系统（DNS）将域名转换为服务器的IP地址。这个过程包括以下步骤：
- 本地DNS缓存查询：浏览器首先检查本地的DNS缓存是否有对应的IP地址记录。
- 本地hosts文件查询：如果没有在缓存中找到，浏览器接着检查系统的hosts文件。
- 递归查询：如果hosts文件中也没有，浏览器会向本地DNS服务器发起递归查询，DNS服务器会依次向上级DNS服务器查询，直到找到负责该域名的权威DNS服务器。
建立TCP连接：一旦获得服务器的IP地址，浏览器会通过传输控制协议（TCP）建立与服务器的连接。如果是HTTPS协议，还需要进行SSL/TLS握手来确保连接的安全。
发送HTTP请求：连接建立后，浏览器会向服务器发送一个HTTP请求。这个请求包括请求行（如GET /index.html HTTP/1.1），请求头（如Host: www.example.com），以及可能的请求体（如POST请求中的数据）。
服务器处理请求：服务器接收到请求后，根据请求类型（如GET或POST）和路径，服务器端的程序（如Web服务器、应用服务器）会处理请求，并生成响应。
服务器响应：处理完成后，服务器会发送一个HTTP响应给浏览器。这个响应包括状态码（如200 OK表示成功，404 Not Found表示找不到页面），响应头（如Content-Type），以及响应体（如HTML内容）。
浏览器渲染页面：浏览器接收到服务器响应的HTML内容后，会开始渲染页面。这个过程包括解析HTML，CSS，以及执行JavaScript代码。
处理资源加载：页面中的资源（如图片、CSS文件、JavaScript文件）可能会在HTML中通过链接引用。浏览器会分别对这些资源发起额外的HTTP请求，并按需加载和渲染。
会话管理：为了维持用户状态，如登录信息，浏览器会使用Cookie机制。服务器可以在响应头中包含Set-Cookie字段来设置Cookie，浏览器在后续请求中会包含这些Cookie。

二、HTTPS

https

1. HTTP的缺点

在正式介绍HTTPS前我们先来看看HTTP协议当前存在的三大缺点：

机密性问题：通信使用了明文，第三方可以拦截并获悉通信内容；
完整性问题：未验证报文的完整性，第三方可以篡改通信内容；
认证问题：未验证对方的身份，第三方可以冒充他人身份参与通信。

注：其他未加密协议也会存在以上问题，比如Telnet、FTP。

2. HTTPS简介

HTTPS 被称为 HTTP Over SSL (基于SSL加密的HTTP)，这里的SSL (Secure Socket Layer) 被称为安全套接层，它是一种加密协议，不仅可应用于HTTP协议、还可应用于POP3协议、SMTP协议、VPN等。

TLS (Transport Layer Security) 被称为传输层安全，TLS相对于SSL 3.0版本做了些修改和功能增强，相当于SSL的升级版本，所以有时也一起统称为 SSL，接入来本文若不明显强调，SSL就默认表示SSL/TLS。

我们可以用公式HTTPS = HTTP + SSL / TLS来表示HTTPS。

3. HTTPS交互流程（四阶段）

4.实验

1）TLS四次握手（第二阶段）

打开wireshark开始抓包，浏览器输入https://www.baidu.com，停止抓包，在Wireshark的显示过滤器中输入表达式ip.addr == 192.168.130.153 and tls过滤出TLS协议数据包。

可以先输入http.host == "www.baidu.com"看看ip地址是多少。

第一次握手报文：我->百度发送TLS消息「Client Hello」；
第二次握手报文：
- 百度->我发送TLS消息「Server Hello」；
- 百度->我发送TLS消息「Certificate」，「Server Key Exchange」，「Server Hello Done」
第三次握手报文：我->百度发送TLS消息「Client Key Exchange」，「Change Cipher Spec」，「Encrypted Handshake Message」
第四次握手报文：百度->我发送TLS消息「Change Cipher Spec」，「Encrypted Handshake Message」

TLS第一次握手

客户端向服务端发送：

客户端支持的协议；
已经使用的TLS版本；
随机数Random；
支持的密码套件。

接下来我们看几个TLS协议中的重要字段（Version、Random、SessionID和Cipher Suites）。

version

从上图中可以看到当前通信安全层协议版本（Version）为TLS 1.2。其实TLS共总有4个版本，最新为TLS 1.3，具体如下：

TLS 1.3：发布于2018年，TLS 1.3是TLS协议的最新版本，大幅简化了握手过程，提高了性能和安全性。它删除了一些不安全的加密算法，并引入了0-RTT（零往返时间）握手，以减少延迟。
TLS 1.2：TLS 1.2发布于2008年，它引入了更强的加密算法和更灵活的密码套件选择，修复了许多安全漏洞，是目前广泛使用的版本。（当前样例中百度网站使用的就是TLS 1.2协议）
TLS 1.1：TLS 1.1发布于2006年，引入了一些改进，包括对CBC（Cipher Block Chaining）模式的安全性改进，但仍然存在一些已知的安全问题。
TLS 1.0：TLS 1.0于1999年发布，是SSL 3.0的升级版本，修复了一些安全漏洞，但仍然存在一些安全问题。

Random

Random用于密钥的制作。这里我们将第一次握手中客户端发送给服务端的随机数记为Client Random，记住这个随机数，后面还会用到。

SessionID

SessionID用来表示客户端是否想复用先前存在的session。如果不复用，则此字段为0；如果想要复用，则此字段为想要复用的sessionID。是否复用由服务端确定。

Cipher Suites

密码套件列表会全部发给服务端，服务端从中挑选一个最安全的密码套件返回客户端。

将Cipher Suites字段展开，如下图。代表客户端支持的密码套件列表。由于本次抓包使用的是curl工具，我们可以看到里面支持49种密码套件。每种套件代表不同的加密方式。不同的客户端（如浏览器）支持的列表也可能不一样。

密码套件的格式通常由一系列的加密算法和相关参数组成。一般来说，它的格式包含以下几个部分：

密钥交换算法：用于协商会话密钥，例如 Diffie-Hellman（DHE）、ECDHE等。
身份验证算法：也称签名算法用于验证对端身份，例如RSA。
加密算法：用于实际数据传输的加解密，例如 AES（Advanced Encryption Standard）、RC4 等。
数据摘要算法：用于计算哈希，主要是用于验证数据的完整性，防止信息被篡改。

格式：「密钥交换算法 + 签名算法（认证算法） + 对称加密算法 + 摘要算法」。其中密钥交换算法和签名算法可以相同，此时就会合二为一。

比如上图密码套件列表中的第四个TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA38

密码套件格式构成

在这个例子中：

ECDHE表示密钥交换算法是基于椭圆曲线的 Diffie-Hellman（ECDHE）。
RSA表示使用RSA算法（私钥加密、公钥解密）验证对方身份。
AES_256_GCM表示使用 256 位的 AES 加密算法和 GCM 模式。
SHA384表示使用 SHA-384 作为消息摘要算法。

不同的密码套件组合提供了不同的安全性和性能特点，服务器和客户端在进行 TLS 握手时会协商选择双方都支持的 Cipher Suite 来建立安全连接。

客户端发送完「Client Hello」（第72个报文），第73个报文则是服务端向客户端发送的ACK确认消息，代表上面的「Client Hello」已经收到。这里也可以看出服务端是通过普通的TCP 的ACK消息去应答「Client Hello」。

TLS第二次握手

这一次握手时，server向client连续发送了两个报文：

Server Hello：服务端为了证明自己的身份，会发送「Server Certificate」给客户端，这个消息里含有数字证书；
Certificate,Server key Exchange,Server Hello Done：目的是告诉客户端，我已经把该给你的东西都给你了，本次打招呼完毕。

1. 服务端发送报文：Server Hello

服务端向客户端发送：

服务端支持的协议；
使用的TLS版本；
随机数Random；
服务端选用的密码套件。

上图中可以看到，服务端也生成了一个随机数，并发送给了客户端，服务端生成的随机数记为Server Random。

小结：

到目前为止客户端和服务器都已经拥有了自有的随机数，并且还会把随机数传递给对方，分别记为Client Random和Server Random，那这两个随机数有啥用呢？后文见分晓。
客户端和服务端就已确认了 TLS 版本和使用的密码套件TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。

2. 服务端发送报文：Certificate,Server key Exchange,Server Hello Done

这里服务端在一个数据包中发送了三个TLS消息：

Certificate
Server key Exchange
Server Hello Done

Certificate

可以看到当前数据包中包含了三个数字证书，三个证书实际构成了一个完整的证书链。

最下面的为根证书，最上面的为网站证书。感兴趣的同学可以逐一将证书链中的各个证书字段展开，查看详情。

根证书：

网站证书：

我们直接在百度网站上点击地址栏中的"🔒"图标也能看到此证书链，实际上与我们抓的证书链完全一致。

Server Key Exchange

之前由于服务端选用ECDHE进行密钥协商，所以可以看到「Sever Key Exchange」消息中主要包括密钥交换算法EC Diffie-Hellman（简称ECDHE）以及携带的额外数据（Server Params）。Server Params参数包含：Curve Type、Named Curve以及Pubkey，分别代表曲线类型、曲线名称以及椭圆曲线公钥（用于实现密钥交换算法）。为了防止公钥被篡改，这里服务端使用RSA私钥对椭圆曲线公钥进行签名并发送给客户端。

实质上这个过程服务器做了三件事情：

选择了名为 named_curve 的椭圆曲线，选好了椭圆曲线相当于椭圆曲线基点 G 也定好了，这些都会公开给客户端；
生成随机数会作为服务端椭圆曲线的私钥，保留到本地；
根据基点 G 和私钥计算出服务端的椭圆曲线公钥，这个会公开给客户端。

以上三件事是ECDHE密钥交换必备的步骤，如果前期双方选用了RSA密钥交换算法，这里的步骤就又不一样了。

Server Hello Done

表明Server Hello消息结束，这个消息中没有额外的其他字段。

TLS第三次握手

该报文中，也是将TLS的三个消息合并到一个中发送。

Client Key Exchange

客户端收到了服务端的证书及「Server Hello Done」消息后，会先校验证书，校验通过后会将Client Params数据传递给服务端，其中包含自身生成的椭圆曲线公钥（Pubkey），数据内容如图所示：

客户端会生成一个随机数作为客户端椭圆曲线的私钥，然后再根据服务端前面给的信息，生成客户端的椭圆曲线公钥，然后用「Client Key Exchange」消息发给服务端。

至此，双方都有对方的椭圆曲线公钥、自己的椭圆曲线私钥、椭圆曲线基点 G。于是，双方都可计算椭圆曲线的交点（x，y）。

还记得 TLS 握手阶段，客户端和服务端都会生成了一个随机数传递给对方吗？

最终的会话密钥就是用「客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的预共享密钥）」三者结合生成的。

之所以搞这么麻烦，就是因为 TLS 设计者不信任客户端或服务器伪随机数的可靠性，为了保证真正的完全随机，把三个不可靠家伙混合起来，随机的程度就非常高了，安全性也就更高。

Change Cipher Spec

「Change Cipher Spec」消息表示客户端已经生成密钥，并切换到对称加密模式。

Encrypted Handshake Message

发送这个消息有两个目的：

告诉服务端，客户端在握手的过程中收到和发送的数据做一个摘要并用会话密钥加密发送给服务端做校验，保证TSL握手过程中报文没有被修改过；
如果服务端收到这个消息并能解密成功，就能说明对称密钥是正确的。
「Encrypted Handshake Message」消息其实不只是客户端会发送，之后服务端也会发送一个。

TLS 第四次握手

服务器也是同样的操作，发送「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么TLS握手正式完成。

最后，就用会话密钥加解密 HTTPS 请求和响应了，即开启了阶段三的加密通信。

问题1：HTTPS的交互过程中总共用到了几组密钥（包含对称密钥及非对称密钥）？

总共用到了两组密钥：一组非对称密钥（包含公钥和私钥）和一组对称密钥。

非对称密钥：服务器拥有一个密钥对，包括一个公钥和一个私钥。公钥用于加密数据，私钥用于解密数据。
对称密钥：在SSL/TLS握手过程中，客户端和服务器协商出一个对称密钥（也称为会话密钥或临时密钥），用于加密和解密实际传输的数据。

非对称密钥用于安全地交换对称密钥，而对称密钥则用于实际的数据传输。

2）第三阶段：加密通信

TLS握手完成后，客户端与服务端的所有通信内容均被加密，如果没有会话密钥则无法解密通信内容。

问题2：此处的加密通信有可能会被第三方解密吗？如果会，那么第三方运用了什么技术手段？

3）第四阶段

4. HTTPS的缺点

尽管HTTPS提供了许多安全优势，但也存在一些缺点：

在相同网络环境中，HTTPS 相比 HTTP 无论是响应时间（慢2~100倍）还是耗电量（因为需要更多的服务器资源）都有大幅度上升，会导致成本升高。

HTTPS需要客户端、服务端双方做加解密处理，需要消耗更多CPU和内存资源，相比HTTP通信，HTTPS又多了TLS握手，会消耗更多的网络资源，总体也导致HTTPS响应时间变慢。

HTTPS 并不是绝对安全的，在中间人攻击、服务器劫持等情况下几乎起不到作用。

相比HTTPS，HTTPS需要额外购买SSL证书，最便宜的证书一年300多元，如果是是企业网站证书，一年至少也得3000元。

三、HTTP1/2/3的升级之路

HTTP/1 升级到 HTTP/2

HTTP/1的问题：

队头阻塞：由于HTTP/1不支持并发，当多个资源请求时，必须等待前一个请求完成后才能发送下一个请求，这会导致性能瓶颈。
冗余头部：每个请求和响应都需要发送完整的头部，即使它们大多数时候都是相同的，造成了额外的网络开销。
无法压缩头部：HTTP/1的头部无法压缩，进一步增加了数据传输的大小。

HTTP/2的改进：

多路复用：HTTP/2允许在同一个连接中并发地发送多个请求和响应，解决了队头阻塞问题。
头部压缩：使用HPACK压缩算法，减少了冗余头部的大小。
服务器推送：服务器可以在客户端请求之前主动推送资源，减少加载延迟。
优先级：客户端可以设置请求的优先级，让服务器知道哪个资源更重要。
二进制格式：HTTP/2将HTTP/1的文本格式改为二进制格式，提高了传输效率。

HTTP/2 升级到 HTTP/3

HTTP/2的问题：

基于TCP的问题：HTTP/2虽然在性能上有了很大提升，但TCP协议在某些场景下（如移动网络）存在一些不足，如队头阻塞和连接迁移问题。

HTTP/3的改进：

基于QUIC协议：HTTP/3使用了Google开发的QUIC（Quick UDP Internet Connections）协议。QUIC是一个基于UDP的协议，可以减少连接建立的时间，并且具有更好的移动网络性能。
连接迁移：由于QUIC支持连接迁移，即使在移动设备在不同网络之间切换时，也能保持连接的持续性。
加密：HTTP/3默认使用加密，提高了通信的安全性。
更快的连接建立：通过使用现有的TLS握手过程，HTTP/3可以更快地建立连接。

HTTP/1

HTTP/2

基于TCP的问题

HTTP/3

四、传输层

TCP协议

1. 概述

TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP的基本特点如下。

（1）面向连接。双方必须先建立连接才能进行数据的读写，双方都必须为该连接分配必要的内核资源，以管理连接的状态和连接上的传输。TCP连接是全双工的，双方数据传输可以通过一个连接进行，完成数据交换后，双方必须断开连接，以释放系统资源。

（2）可靠传输。

• TCP采用发送应答机制，TCP发送的每个报文段都必须得到接收方的应答才认为这个TCP报文段传输成功。

• 超时重传，发送端发出一个报文段之后就启动定时器，如果在定时时间内没有收到应答就重新发送这个报文段。

• TCP报文段最终是以IP数据报发送的。IP数据报到达接收端可能乱序重复，TCP对接收到的TCP报文段重排整理后再交给应用程序。

（3）基于字节流。应用层发送的数据会在TCP的发送端缓存起来，统一分片（如一个应用层的数据包分成两个TCP包）或者打包（如两个或者多个应用层的数据包打包成一个TCP数据包）发送，接收端直接按照字节流将数据传递给应用层。

2. TCP报文格式

TCP报文格式如下图所示，报文头部主要字段介绍如下。

（1）源端口：占2个字节，表示发送方端口号。

（2）目的端口：占2个字节，表示接收方端口号。

（3）序号：占4个字节，TCP连接传送的数据流中的每一个字节都被编上一个序号。首部中序号字段的值指的是本报文段所发送数据的第一个字节的序号。

（4）确认序号：包含发送确认的一端所期望接收到的下一个序号。因此，确认序号应该是上次已成功收到的数据字节序列号加1。

（5）首部长度：TCP报文段首部的长度。

（6）保留：占6 bit，保留为今后使用。

（7）URG：紧急指针有效标识，当URG=1时，表明紧急指针有效。它告诉系统报文段中有紧急数据，应尽快传送。

（8）ACK：确认指针有效标识，ACK=1时，确认号字段才有效，ACK=0时，确认号字段无效。

（9）PSH：接收方在接收到PSH=1的报文段时会尽快将其交付给接收应用进程，而不再等到整个接收缓存都填满后再向上交付。

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

（11）FIN：当FIN=1时，表明此报文段发送端的数据已发送完毕，并要求释放传输连接。

（12）窗口：占2个字节，用来控制对方发送的数据量，单位是字节，指明对方发送窗口的上限。

（13）校验和：占2个字节，校验的范围包括首部和数据两个部分，计算校验和时需要在报文段前加上12个字节的伪首部。

（14）紧急指针：占2个字节，指出本报文段中紧急数据最后一个字节的序号。只有当紧急比特URG=1时才有效。

（15）选项：长度可变。TCP只规定了一种选项，即最大报文段长度MSS（Maximum Segment Size）。

说明：连接建立时，各端分配一块缓冲区用来存储接收的数据，并将缓冲区的尺寸发送给另一端。接收方发送的确认信息中包含了自己剩余的缓冲区尺寸，剩余缓冲区空间的数量叫作窗口。

实验1（分析TCP报文）

源端口（Source Port）和目的端口（Destination Port），各占2个字节。这两个值加上IP报头中的源主机IP地址和目的主机IP地址唯一确定一个TCP连接。本实验中源端口是64206，而目的端口是443。

序号（Sequence number），占4个字节。表示在发送报文段中的第一个数据字节的顺序号。

确认号（Acknowledgment number），占4个字节。上次接收端已成功收到数据字节顺序号加1。只有ACK标志为1时确认序号字段才有效。

数据偏移，占4位，半个字节，表示报头长度（Header Length）。下图为32 bytes。

保留（Reserved），占6位。

flag 控制位： URG/ACK/PSH/RST/SYN/FIN，占6位

窗口（Window size），占2个字节。下图表示实验窗口大小为65535

检验和（Checksum），占2个字节，此校验和是对整个TCP报文段，包括TCP头部和TCP数据进行计算所得。下图的校验和为0xb99b

紧急指针（Urgent pointer），占2个字节，只有当URG标志为1时紧急指针才有效，下图为1

选项（Options），字节数不固定，最常见的可选字段是最长报文大小，又称为MSS，下图是12字节

实验2（三次握手四次挥手）

在数据帧部分，前14字节为以太网帧头部，之后的20字节为IP头部，后面的32字节为TCP头部数据，故而这里的头部长度为：32/4=8，即1000，加上后面的0000，即为80

三次握手（建立连接）

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

假定主机A运行的是TCP客户程序，而B运行TCP服务器程序，最初两端的TCP进程都处于CLOSED(关闭)状态，图中在主机下面的方框分别是TCP进程所处的状态，在开始阶段B的TCP服务器进程会先创建传输控制块TCB准备接受客户进程的连接请求，然后服务器进程就处于LISTEN(收听)状态等待客户的连接请求，如有则会立即作出响应，需要注意的是A主动打开连接，而B被动打开连接：

第一次握手

第一次握手：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(已建立连接)状态

四次挥手（释放连接）

TCP连接释放过程比较复杂，在数据传输结束后通信的双方都可释放连接，现在A和B都处于ESTABLISHED状态，整个流程如下：

第一次挥手

第一次挥手：A的应用进程先向其TCP发出连接释放报文段并停止再发送数据并主动关闭TCP连接，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已经没有要向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标准，前面发送过的FIN报文段要消耗一个序号)，然后进入到TIME-WAIT(时间等待)状态，需要注意的是现在TCP连接还没有释放掉，必须经过时间等待计时器(TIME-WAIT timer)设置的时间2MSL后，A才进入到CLOSED状态，时间MSL叫做最长报文段寿命(Maximum Segment Lifetime)，RFC 793建议设为2分钟，但这完全是从工程上来考虑的，对于现在的网络MSL=2分钟可能太长了一些，因此TCP允许不同的实现可根据具体情况使用更小的MSL值，因此从A进入到TIME-WAIT状态后要经过4分钟才能进入到CLOSED状态才能开始建立下一个新的连接，当A撤销相应的传输控制块TCB后就结束了这次的TCP连接

很多人可能会问这里为什么A在TIME-WAIT状态必须等待2MSL的时间，主要有两个理由：

第一：为了保证A发送的最后一个ACK报文段能够到达B，这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器。最后A和B都正常进入到CLOSED状态。如果A在TIME-WAIT状态不等待一段时间而是在发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段，这样B就无法按照正常步骤进入CLOSED状态

第二：防止上一节提到的"已失效的连接请求报文段"出现在本连接中，A在发送完最后一个ACK报文段后再经过时间2MSL就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段，B只要收到了A发出的确认就进入CLOSED状态，同样B在撤销相应的传输控制块TCB后，就结束了这次的TCP连接，我们注意到B结束TCP连接的时间要比A早一些。

连接重置

在理想情况中每一个连接都会以TCP终止来正常地结束，但在现实中连接经常会突然断掉，例如：攻击者在进行端口扫描被EDR等检测到后直接阻断连接，在这些情况下就需要使用设置了RST标志的TCP数据包，RST标志用来指出连接被异常中止或拒绝连接请求

下图给出了一个包含有RST数据包网络流量的例子，这个文件中的第一个数据包发自192.168.100.138，其尝试与192.168.100.1的80端口进行通信，这个主机并不知道192.168.100.1并没有在监听80端口，因为那是一个思科路由器并且没有配置Web接口，也就是说并没有服务监听80端口的连接，为了响应这个连接请求，192.168.100.1向192.168.100.138发送了一个数据包告诉它其对80端口的通信无效，图中展示了在第二个数据包的TCP头中这个连接尝试突然终止的情况，RST数据包除了包含RST和ACK标志外，没有任何其他的东西，之后也并没有额外的通信