授权与合规声明本文全部操作对象均为自建隔离靶场本机容器或隔离虚拟机涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离不含任何攻击步骤、利用载荷与绕过手法请勿将文中环境指向任何非自有系统。本文引用的规范原文取自 RFC 9293TCP 现行标准文本核验日期为 2026-10-13英文原句逐字保留、不加改动。一、三种连不上其实是同一段过程停在了三个位置1.1 界面上看到的三种样子刚开始用抓包工具的人最常撞到的连不上有三种只看到几个空包然后页面正常打开了。抓包窗口里先是几行不带内容的东西之后才是真正带数据的请求。连接被拒绝。几乎不等待瞬间就结束了。一直转圈最后超时。界面卡很久。这三者放在一起毫无共同点一个快得没有过程一个慢得看不到头还有一个干脆什么都不显示。但背后是同一件事——一次连接的建立过程走到了不同的位置。你以为在看三种毛病其实是在看同一个过程的三张快照。1.2 先把这段过程的名字立起来规范给这段过程起了名字。RFC 9293 §3.5 的第一句就是它的定义表 A 第 1 行The “three-way handshake” is the procedure used to establish a connection.即三次握手就是用来建立连接的那个过程。这句话把位置摆正了——“连不上不是连接坏了”而是建立过程没有走完既然是过程就存在走到哪一步这个问题。本文的支点就是接下来这句话连接不是打开一条管道而是双方各自维护一份状态几段交互之后两份状态才对得上。1.3 本文的边界先把不写的列清楚免得在错的方向上花时间本文不写任何扫描、探测与连通性测试类命令。判断某个地址、某个端口上有没有东西在等连接是另一件事本文只解释状态。本文不写抓包样例里的报文字节也不写各字段在报文里的排列顺序。本文不写如何造出半个连接这类操作。同时打开只在规范承认它是正常路径这个层面出现第 5 章。不写报文形态某个应用层协议各版本的报文长什么样、不写域名解析、不写抓包工具的配置这三条各自是一条独立的轴。还有一条边界一次说完卡到超时也可能是路上的设备把包丢掉了。中间有没有防火墙一类的设备参与、按什么规则放行属于另一条轴本文只用这一句点到不展开任何出入站规则。本章可以带走的一句三种连不上不是三种毛病而是同一段建立过程停在了三个不同位置先把观察方式从这句话什么意思换成这段过程走到哪一步排障才有路线可走。二、连接到底是什么两份状态而不是一条管道2.1 管道这个比喻漏掉了最关键的一件事把连接说成两端之间有一条管道听起来直观但它漏掉了关键一点这条管道里没有任何一处被叫管道的东西有的只是两边各自的记录。RFC 9293 §3.3.1 把这件事写得很直白表 A 第 4 行We conceive of these variables being stored in a connection record called a Transmission Control Block or TCB.也就是这些变量被设想成放在一份连接记录里它叫Transmission Control Block简称TCB。规范紧接着交代了记录里存了什么表 A 第 5 行Among the variables stored in the TCB are the local and remote IP addresses and port numbers——本地与远端的 IP 地址和端口号都在里面此外还有序号相关变量、缓冲区指针等。于是连接的真实含义是**两端各自有一份 TCB两份 TCB 里的变量互相对得上。**日常排障里习惯把本地地址本地端口远端地址远端端口这四项叫四元组通行叫法不是规范原话某一侧找不到匹配的那份记录对它来说这条连接就不存在。2.2 十一个状态其中有一个是虚构的只有记录还不够还要知道这份记录现在处于什么阶段。规范把阶段排了出来表 A 第 2 行The states are: LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and the fictional state CLOSED.一共十一个其中最后一个用的是虚构这个词。规范自己解释了为什么表 A 第 3 行CLOSED is fictional because it represents the state when there is no TCB, and therefore, no connection.这句值钱的地方在于**“没有连接并不是一种状态而是没有这条记录”。**某一侧对某个四元组说它是 CLOSED真正表达的是我这里没有对应的 TCB。由此能推出一条很容易忽略的结论在那一侧看来刚关掉和从来没建立过是同一件事。第 6 章讲连接被拒绝时要用到它。状态一句话容易混的地方LISTEN在等连接请求等的是任意远端不是某个特定对端第 3 章SYN-SENT请求已发出等一个匹配的请求回来是主动发起的一侧SYN-RECEIVED请求既收到也发出过在等确认不专属于应答方第 5 章ESTABLISHED连接已经打开数据可以交给用户数据传输阶段的正常状态FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSING、LAST-ACK、TIME-WAIT关闭过程里的六个状态都属于关闭阶段本文不展开CLOSED虚构态没有 TCB也就没有连接不是关掉了是没有这份记录2.3 两份状态是各自变的所以不同步是常态既然状态存在各自的记录里两边的状态就不是同一个东西。本侧进了SYN-SENT请求已经发出去了对端此刻可能什么都还没收到也可能它早就在LISTEN上等着。同一时刻两边记的状态不一样不是异常而是常态——因为包在路上。所以每一步都要先问一句你看的是哪一侧的状态下面这段用来在本机看记录长什么样只是只读地把状态列出来不做任何探测。⚠️代码待验证# Linux列出所有 TCP 连接及其状态列ss-tan# macOS没有 ss用 netstat 看同一类信息netstat-an-ptcp本章可以带走的一句连接不是一条管道而是两端各自的一份 TCB 记录十一个状态里CLOSED是规范明说的虚构态因为它指的是没有 TCB而不是有一种叫关闭的状态。三、三步各做一件事3.1 四个状态各自的定义规范对每个状态的说明只有一两行但逐条都能对上界面现象。下面四条取自 §3.3.2逐字保留表 A 第 6–9 行LISTEN - represents waiting for a connection request from any remote TCP peer and port.SYN-SENT - represents waiting for a matching connection request after having sent a connection request.SYN-RECEIVED - represents waiting for a confirming connection request acknowledgment after having both received and sent a connection request.ESTABLISHED - represents an open connection, data received can be delivered to the user. The normal state for the data transfer phase of the connection.LISTEN的定义里有一个词最容易被读快anyremote TCP peer and port——等的是任意远端的连接请求。所以有人在LISTEN的含义是这里有一个进程在等连接请求而不是它认识你。这个区别在第 6 章会直接决定怎么读被拒绝。3.2 三步到底在同步什么各自的初始序号三段交互不是为了打个招呼。§3.4.1 写明了要同步的到底是什么表 A 第 10 行The synchronization requires each side to send its own initial sequence number and to receive a confirmation of it in acknowledgment from the remote TCP peer. Each side must also receive the remote peer’s initial sequence number and send a confirming acknowledgment.这其实是四件事**我发我的序号、我确认你的、你发你的、你确认我的。**规范紧接着说明了为什么最后叫三步表 A 第 11 行Because steps 2 and 3 can be combined in a single message this is called the three-way (or three message) handshake (3WHS).即**四件事里有两件可以合并到同一条消息里于是四条变成了三条。**所以三步不是一个刻意挑选的数字而是合并之后的自然结果——第 4 章问为什么两步不够时答案就落在少的到底是哪一件事上。3.3 主动打开与被动打开发起方式只有两种发起连接这件事规范只分了两种方向。§3.3.2 的措辞表 A 第 12 行A passive OPEN request means that the process wants to accept incoming connection requests, in contrast to an active OPEN attempting to initiate a connection.一种是被动打开进程想要接受进来的连接请求走到LISTEN去等另一种是主动打开进程尝试发起一个连接走到SYN-SENT去等回音。一端在LISTEN、另一端在SYN-SENT——**这就是看起来只有一条线的过程里两份记录在各自变化的样子。**下面这段用来把状态在变看出来同样只读本地状态。⚠️代码待验证# 一个终端里每隔一秒列一次 TCP 连接状态连续看几秒whiletrue;dodate;ss -tan;sleep1;done# macOS 上把 ss 换成 netstatwhiletrue;dodate;netstat-an-ptcp;sleep1;done步骤发出的一方这一步在做的事两侧状态怎么变第一步主动打开的一侧发出自己的初始序号发起侧无记录 →SYN-SENT应答侧仍停在原处第二步被动打开的一侧确认对方的序号同时报出自己的序号应答侧LISTEN→SYN-RECEIVED第三步主动打开的一侧确认对方的序号发起侧先到ESTABLISHED应答侧收到后也到ESTABLISHED本章可以带走的一句三步握手里三步只是合并的结果——本来要同步四件事我发我的序号、我确认你的、你发你的、你确认我的其中两件能合并成一条消息而LISTEN等的是任意远端不是某个特定对端。四、为什么是三步两步不够因为旧包当场认不出来4.1 规范里最直接的那一句如果只允许一个包出去、一个包回来会省掉一次往返。规范解释了为什么不行。§3.4.1 这一段是全文的支点表 A 第 13 行A 3WHS is necessary because sequence numbers are not tied to a global clock in the network, and TCP implementations may have different mechanisms for picking the ISNs. The receiver of the first SYN hasno way of knowing whether the segment was an old one or not, unless it remembers the last sequence number used on the connection (which is not always possible), and so itmust ask the sender to verify this SYN.拆成三层意思前提一序号不挂在网络里的某个全局时钟上各实现挑选初始序号的机制也可以不一样。前提二所以收到第一个 SYN 的那一侧除非它记得这条连接上一次用过的序号否则没有别的办法判断这个段是不是旧的而记得这件事不是总能做到。结论于是它必须请发送方来确认这个 SYN。因果链很干净不是对方认不出来这种能力不足而是旧包长什么样在信息上就不可判——段里带的序号只能证明发送方当时选了它不能证明这个包是现在发的还是很久以前发的。所以接收方不去猜而是把问题退还给唯一能回答它的一方。4.2 第三步在回答的问题按谁提问、谁回答重排一次分工就清楚了第一步发起方说我要连我的初始序号是这个第二步接收方说你的序号我收到了同时报一下我的序号第三步发起方说我确实刚发过那个 SYN。第三个包的价值不在于多确认一次而在于它是唯一能回答这个 SYN 是新的还是旧的那句话的位置。下面这句是笔者的转述、不是规范原话那个 SYN 是发起方自己发的只有它知道自己刚刚发过一个、序号是什么所以请发送方确认是把一个不可判的问题变成可判的问题。顺带澄清一个常见误读三步握手常被讲成确认对方在线而规范给的首要原因不是这个见下一节。4.3 规范把首要原因写在了明处§3.5 里有一句直接点题表 A 第 14 行The principal reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.首要原因是防止旧的重复连接发起造成混淆。注意用词不是为了双方都确认一下而是冲着旧包去的。两端都还活着更像是顺带得到的结果而不是它被设计出来的理由——把主次换过来的人往往会在对方明明在线为什么还连不上这类问题上绕圈。顺带回答一个自然的追问那我平常会碰到旧包吗规范在讲安静时间时说得克制although it is not felt to be necessary in most current implementations表 A 第 15 行并交代今天的实际使用中相关条件已足够不可能it is safe to ignore——**机制为了边界情况而存在不等于边界情况天天发生。**本文只写到机制这一层不展开任何构造或触发方式。本章可以带走的一句两手往返不够是因为接收第一个 SYN 的一侧没有办法当场判断这个段是不是旧的只能把这个判断退还给唯一能回答它的发送方而规范给握手的首要原因写得很清楚——防止旧的重复连接发起造成混淆。五、同时打开规范承认的正常路径以及看起来像的那种5.1 两边同时发起规范说是允许的第 3 章讲的是一主动一被动的常见走法。规范紧接着说明了另一种走法同样成立表 A 第 16 行The procedure also works if two TCP peers simultaneously initiate the procedure. When simultaneous open occurs, each TCP peer receives a SYN segment that carries no acknowledgment after it has sent a SYN.这里有个细节值得停一下每一侧都是在自己发出 SYN 之后才收到一个不带确认的 SYN所以两侧都会经过同一个中间状态。§3.5 对它的描述是表 A 第 17 行Each TCP peer’s connection state cycles from CLOSED to SYN-SENT to SYN-RECEIVED to ESTABLISHED.两条路都要走SYN-SENT与SYN-RECEIVED。而且这不是也允许这种软口气规范用的是 MUST 级别表 A 第 18 行A TCP implementation MUST support simultaneous open attempts (MUST-10).“必须支持”——所以同时打开是一条正常路径不是异常处理分支。这也修正了第 3 章留下的一句话把SYN-RECEIVED理解成对端那一侧的中间状态通常够用但并不准确因为同时打开时发起方自己也会走到它。5.2 但看起来像同时打开可能是一次旧重复 SYN规范讲完正常路径后立刻补了一句提醒表 A 第 19 行the arrival of an old duplicate SYN segment can potentially make it appear, to the recipient, that a simultaneous connection initiation is in progress注意措辞是make it appear——“看起来像”。接收方看到的画面自己也发过、又收到一个不带确认的 SYN与真正的同时打开在画面上很像但来路完全不同一个是两边真的同时发起一个是一个早该消失的旧包又冒了出来。规范随即说明了接收方的实际处境。§3.5 在描述从旧重复 SYN 中恢复的那张图时写道表 A 第 20 行At line 3, an old duplicate SYN arrives at TCP Peer B. TCP Peer B cannot tell that this is an old duplicate, so it responds normally (line 4).**B 分辨不出来所以它照常回应。**这不是疏忽而是第 4 章那条结论的必然结果**单看一个包无法判断它是不是旧的。**分辨的责任落在发起方那一侧——它发现回来的确认对不上就回一个复位段接收方收到后回到LISTEN随后真正的 SYN 到了握手照常走完。规范对这套处置给了一句总结表 A 第 21 行Proper use of reset segments can disambiguate these cases.——正确使用复位段可以把这几种情况区分开。画面真实来路规范的态度两侧都在等对方两边真的同时发起正常路径实现必须支持两侧都在等对方一个旧的重复 SYN 冒了出来接收方分辨不出靠复位段区分这两行画面几乎一样处置方向却不同**同一种现象不能默认它属于哪一类得看规范给出的判别手段有没有被用上。**本文只写到规范承认这套处置存在这一层不写任何构造这类情形的方法。TCP 连接建立过程速查图本文讲的状态走法与同时打开 / 看起来像的区分都拆自这张图的骨架。它把十一个状态和建立阶段的关系画在一页上放在资料包里扫码即可获取本章可以带走的一句同时打开是规范用MUST要求实现支持的正常路径两侧都会走SYN-SENT与SYN-RECEIVED而看起来像同时打开可能只是一个旧的重复 SYN——因为接收方分辨不出来区分要靠复位段的正确使用。六、把四个状态放回排障现象、状态与在等什么本章只做一件事把LISTEN、SYN-SENT、SYN-RECEIVED、ESTABLISHED这四个状态逐一对应到界面上那三种现象。不讲任何探测手段也不回头去讲监听侧该取什么值。6.1LISTEN有东西在等但等的不是你回到第 3 章那句any remote TCP peer and portLISTEN只说明有一个进程在这个位置等连接请求不说明它会接受你的请求——它等的不是你而是任意来客。那连接被拒绝是怎么来的它来自对侧的 CLOSED。§3.5.2 写得很直接表 A 第 22 行If the connection does not exist (CLOSED), then a reset is sent in response to any incoming segment except another reset. A SYN segment that does not match an existing connection is rejected by this means.——**一个与任何已有连接都不匹配的 SYN就是这样被拒绝的。**所以被拒绝的准确含义是**对侧在那个四元组上没有对应的 TCB于是回了一个复位段。**它回答的问题是对侧此刻有没有在与这个请求对应的连接上等至于为什么没有可能的原因有好几条属于监听侧那条轴本文不展开。又因为第 2 章那条结论——在那一侧看来刚关掉和从来没建立过长得一样——被拒绝本身不区分这两种情况这是它最容易误读的地方。6.2SYN-SENT包出去了回音没来本侧停在SYN-SENT意思是请求已经发出还没等到一个匹配的请求回来界面上的表现就是卡住转圈。要分清两件完全不同的事没有回音只能继续等到超时收到了复位会立刻结束等待表现就是 6.1 里那个瞬间被拒绝。也就是说“慢和快的差别在于回音是没有还是是复位”。没有回音的原因之一是通路上的某个环节把包丢掉了通路本身怎么走、在哪一段出的问题属于另一条轴本文只解释状态。⚠️代码待验证# 只看本机上停在等回音这一段的 TCP 记录ss-tanstate syn-sent# macOS 上用 netstat 加过滤看同一类记录netstat-an-ptcp|grep-isyn_sent6.3SYN-RECEIVED中间那一小段窗口对侧停在这个状态表示它既收到过也发出过连接请求正在等确认。它对应一小段时间我方的 SYN 到了、对方回的确认也回来了、但第三步还没到。这段时间通常很短第三步丢了或延迟就会被拉长。第 5 章还提醒过同时打开时发起方自己也会走它所以看到它并不必然意味着我是应答方。6.4ESTABLISHED只有到这里数据才交得出去ESTABLISHED的定义是an open connection, data received can be delivered to the user——**连接打开收到的数据可以交付给用户。**规范还补了一句它的重要性表 A 第 23 行so long as the receiving TCP endpoint doesn’t deliver the data to the user until it is clear the data is valid (e.g., the data is buffered at the receiver until the connection reaches the ESTABLISHED state, given that the three-way handshake reduces the possibility of false connections)——在数据被确认为有效之前接收端不把它交给用户比如先缓存在接收侧直到连接到达ESTABLISHED。这一句正好解释了第 1 章那个几个空包那几个包不是浪费它们就是把连接推到ESTABLISHED的过程。界面上看到的现象本侧可能在的状态对侧可能在的状态在等什么先几个空包然后正常经过SYN-SENT→ESTABLISHED经过SYN-RECEIVED→ESTABLISHED三步依次走完连接被拒绝几乎不等发出请求后收到复位该四元组上没有 TCB等不到匹配被复位结束一直卡到超时停在SYN-SENT可能根本没收到等一个始终没来的回音最后给三个只读的观察动作用来把上面的状态在本地对上。它们都只查看本机已有的连接记录不向任何外部目标发探测。⚠️代码待验证# 只看处于监听状态的 TCP 端点ss-tln# 只看已经建立的 TCP 连接ss-tanstate established# macOS 上没有 ss用 netstat 加过滤看监听与已建立netstat-an-ptcp|grep-ilistennetstat-an-ptcp|grep-iestablished⚠️代码待验证# 用 lsof 按状态列出本机 TCP 连接适合同时看哪个进程在占lsof-iTCP-sTCP:LISTENlsof-iTCP-sTCP:ESTABLISHED本章可以带走的一句四个状态各自对上一段时间——LISTEN是有东西在等但等的不是某个特定的人SYN-SENT是发出了没回音收到复位则立刻结束SYN-RECEIVED是第三步还没到的短窗口ESTABLISHED才是数据可以交给用户的那一步。七、收束一条主线与六项自查7.1 一条主线整篇可以收在一句话上连接是两端各自的一份 TCB建立过程就是让两份记录对得上。沿这条线三种现象是同一段过程的三个位置第 1 章没有管道CLOSED甚至是虚构的第 2 章三步是四件事合并两条的结果第 3 章两步不够是因为一侧没法判断这个段是不是旧的第 4 章同时打开是正常路径看起来像另有来路第 5 章。7.2 六项自查下次再遇到连不上按顺序问自己六句**我这一侧现在记的是什么状态**先分清观察的是哪一端别把两端的结论混着用。**对侧是瞬断还是长等**瞬断通常意味着收到复位长等通常意味着回音没来。**我看到的SYN-RECEIVED真是应答方的那个吗**它也可能出现在主动发起的一侧。**现象和状态对得上吗**对不上时先怀疑我看的那份记录不是这条连接的记录。把现象套回三个位置停在LISTEN对侧没有记录、停在SYN-SENT等不到回音、还是停在SYN-RECEIVED差最后一步**有没有更省事的规范层解释**很多看起来矛盾的现象答案就是某一侧本来就没有判断所需的全部信息。7.3 一条纪律最后一句本文讲的全是建立过程本身。任何造出半个连接让某一侧停在中间状态的操作都不属于本文范围也不在这里提供思路规范原文只用来说明机制为什么这么设计不用来当作操作指引。配套资料获取这篇里反复用来对上号的那张状态速查图和一套自建靶场环境的搭建对照表都放在同一个资料包里。后面想按状态去读现象先把图放在旁边对着看会快很多扫码即可获取本章可以带走的一句遇到连不上先回答哪一侧、什么状态、在等什么这三个问题三个问题都能答上来时现象基本已经自己说出答案了。附表 A本文引用事实与官方出处对照表#事实一句出处核验日期本文位置1建立连接所用的过程在规范里就叫 “three-way handshake”RFC 9293 §3.5首句2026-10-13第 1 章2连接状态共十一个最后一个是虚构态CLOSEDRFC 9293 §3.3.22026-10-13第 2 章3CLOSED是虚构的因为它代表没有 TCB、因而没有连接RFC 9293 §3.3.22026-10-13第 2 章4连接要维护的变量被设想成放在一份叫 TCB 的连接记录里RFC 9293 §3.3.12026-10-13第 2 章5TCB 里存的变量包括本地与远端的 IP 地址和端口号RFC 9293 §3.3.12026-10-13第 2 章6LISTEN 等任意远端 TCP 对端与端口的连接请求RFC 9293 §3.3.22026-10-13第 3、6 章7SYN-SENT 发出连接请求之后等一个匹配的连接请求RFC 9293 §3.3.22026-10-13第 3、6 章8SYN-RECEIVED 既收到也发出连接请求之后等确认RFC 9293 §3.3.22026-10-13第 3、6 章9ESTABLISHED 连接已打开收到的数据可交付用户RFC 9293 §3.3.22026-10-13第 3、6 章10同步要求每侧发出自己的初始序号并收到确认同时收到对方的初始序号并给出确认RFC 9293 §3.4.12026-10-13第 3 章11因为第 2、3 步可合并到一条消息所以叫三消息握手3WHSRFC 9293 §3.4.12026-10-13第 3 章12passive OPEN 表示进程想接受进来的连接请求与 active OPEN 相对RFC 9293 §3.3.22026-10-13第 3 章13收到第一个 SYN 的一侧无法知道这个段是不是旧的所以必须请发送方确认这个 SYNRFC 9293 §3.4.12026-10-13第 4 章14三步握手的首要原因是防止旧的重复连接发起造成混淆RFC 9293 §3.52026-10-13第 4 章15规范说安静时间在多数现行实现里并不必要实际使用中相关条件已可安全忽略RFC 9293 §3.4.22026-10-13第 4 章16两个对端同时发起时该过程同样能工作同时打开时每侧在发出 SYN 后收到一个不带确认的 SYNRFC 9293 §3.52026-10-13第 5 章17同时打开时每侧状态依次经过CLOSED→SYN-SENT→SYN-RECEIVED→ESTABLISHEDRFC 9293 §3.52026-10-13第 5 章18实现必须支持同时打开尝试MUST-10RFC 9293 §3.52026-10-13第 5 章19旧的重复 SYN 可能让接收方看起来像正在进行同时连接发起RFC 9293 §3.52026-10-13第 5 章20接收方分辨不出旧重复于是照常回应RFC 9293 §3.5Figure 8 说明2026-10-13第 5 章21正确使用复位段可以把这些情况区分开RFC 9293 §3.52026-10-13第 5 章22连接不存在CLOSED时对进来的段回复位不匹配任何连接的 SYN 就是这样被拒绝的RFC 9293 §3.5.22026-10-13第 6 章23数据被确认有效之前接收端不交给用户例如缓存到连接到达ESTABLISHEDRFC 9293 §3.52026-10-13第 6 章说明本文全部规范原文取自 RFC 92932022-08本批核验时为本机留存的原文文本上表均为逐字口径。本文未在本机做过任何 TCP 抓包或状态观察因此第 2、3、6 章的命令片段一律标注代码待验证不作为结论。附表 B术语速查表术语一句话解释易混点TCB保存一条连接各项变量的连接记录连接不是管道是两端各一份记录CLOSED规范里的虚构状态代表没有 TCB不是关掉了是没有这份记录LISTEN在等任意远端的连接请求只说明有东西在等不说明它会接受你SYN-SENT请求已发出在等一个匹配的请求回来收到复位会立刻结束与超时是两回事SYN-RECEIVED请求既收到也发出过在等确认不专属于应答方同时打开时发起方也经过它ESTABLISHED连接已打开数据可以交付用户只有到这里数据才交得出去初始序号ISN每一侧为自己选的起始序号与全局时钟无关所以旧包无法靠它自证新旧同时打开两端各自主动发起规范用 MUST 要求支持是正常路径不是故障旧重复 SYN早该消失却又出现的连接请求接收方分辨不出只能照常回应写在最后这篇用到的资料写这篇文章时我一直在回想自己第一次盯着抓包窗口发愣的样子——明明只看到几个空包网页却好好地打开了。把 RFC 9293 里那几段状态定义读完之后才明白那几个包不是浪费它们就是把连接推到能交付数据那一步的过程。顺手也整理了几份配套的东西靶场环境对照表DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径Web 安全学习路线图从基础打牢到安全管理四个阶段各学什么常用靶场清单每个靶场练什么、适合哪个阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「靶场」优先通过。拿到之后建议先看环境对照表那一份再把自己靶场里几个空包之后才出数据的那次抓包对照着走一遍哪一侧、什么状态、在等什么这三个问题下次再看到卡住转圈就知道该往哪一段去想了。