前言

之前有过一篇关于 NAT打洞的，主要是 UDP打洞，感兴趣的可以看之前的文章：NAT打洞
该篇文章主要讲述的是对 TCP打洞的实现，以及其中的步骤的讲解和优化
也算是继续完善这个系列的坑…

可运行的代码放在了 Github仓库

当你开始阅读时，默认读者已具备一定的网络基础以及对NAT有基本的认识
那我们开始！

TCP 打洞

与 UDP 的区别

TCP与UDP打洞，最大的不同在于TCP是有连接，UDP是无连接
这就决定了，UDP可以一边打洞一边监听端口
其次就是，UDP打洞成功就能进行通信，TCP是要想办法达成握手，三次握手成了才可以通信

但其实，并没什么影响。。。因为打洞的原理并没有变，只是流程上需要稍微改变一下

流程

整个的原理和流程如下图[^1]：(先说完这个图再说改进)

TCP打洞流程

Step1-2: R 向服务器注册信息（这里其实UDP和TCP都可以，改进部分有说明）
Step3: I 向服务器发出 “想要连接的请求”，用的是TCP（这样可以知道 I 自身的 NAT 信息 NI:Y）
Step4: 服务器将 “I 想要连接的请求” 发送给 R
Step5: R 收到服务器发来的 “I 想要连接的请求” 后，用 R:J 向服务器发起 TCP 连接
服务器收到连接后，会收到来自 NR:K 的信息，之后会判断 NR 是否等于 R，
- 是的话，即 R 不经过 NAT，I 可以直接发起连接
- 否的话，即 R 经过 NAT，需要 R 打洞后，I 才可以发起连接（这里讨论这种情况）
Step6: 服务器向 R 发送打洞的消息，并将 NI:Y 信息发送给 R，表示可以通过 NI:Y 与 I 通信
Step7: R 收到 NI:Y 后，用 R:J 向 NI:Y 发送 TCP 连接请求（指SYN）
Step8: R 不会收到返回信息（指ACK），但这里也有可能收到拒绝信息，但这里不影响
随后 R 直接断开通过 R:J 发起的 TCP 连接，并开启 TCP Server 监听 J 端口
Step9: R 用 其他端口 向服务器发送 “打洞完成” 的信息
Step10: 服务器通过 NI:Y 将 “打洞完成” 的信息以及 NR:K 的信息发送给 I，并且关闭与之的通信
Step11: I 收到信息后，会终止 NI:Y 与服务器的 TCP 连接，然后会用 NI:Y 向 NR:K 发起 TCP 连接请求（指SYN）
最终 SYN 会被 NR:K 送进给 R:J，之后会进行完整的三次握手建立TCP连接

改进

这里的 Step1、2、9 其实对连接并没有要求
1 2 9 可以用同一个连接专门用来发送信息也是可以的，这里起到的作用单纯是通知状态和交换信息
甚至 Step1-2 直接用 R:J 与服务器进行通信也是可以的，因为 Step6 之后都会断开与服务器的连接而转为打洞和监听

其次，这里并没有那么严谨的区分 I 和 R 与服务器发起连接的顺序，因为与服务器建立连接之后，不管是 Step4 还是 Step10，都是在等待服务器返回信息才进行下一步操作（这里代码中我用了心跳包的方式维持）

Step6 的 NI:Y 信息其实可以在 Step4 就带过来给 R，这里主要是考虑是否需要考虑打洞的情况，因为 R 如果不需要打洞的话 NI:Y 的信息其实并不需要告知 R
但如果单纯是考虑是否需要打洞的话，其实还得考虑双方的 NAT 类型来进一步判断是谁来打洞
比如说：

I 是 NAT3 *端口限制性锥形NAT( Port Restricted Clone NAT)*，
R 是 NAT4 对称式NAT(Symmetric NAT)
则需要 I 来打洞，R 向 NI 发起连接

如果不需要考虑的话，其实这里 punchHole 一直为 True 都可以

改进后：(其实也没多大必要)

sequenceDiagram
participant I
participant NI
participant S
participant NR
participant R

par
R ->>+ S : Step2: TCP - S:Z < NR:K < R:J
Note over NR: NR:K；想要被 I 连接

I ->> S : Step1: TCP - I:X > NI:Y > S:Z
Note over NI: NI:Y；想要连接R
end

Note right of S: NI:Y；需要打洞
S -->> R : 

R->>+ NI: Step3: TCP - NI:Y < NR:K < R:J (打洞)
NI--x R: 
# Note right of R: Destroy TCP R:J

R->>R: Step4: <br/>① Destroy TCP R:J<br/>② CreateServer Listen R:J

R->>S: Step5: New Connection <br/>  S:* < NR:* < R:*
Note over NR: 打洞完成

Note left of S: NR:K
S-->>- I: 

I->>I: Step6: <br/>Destroy TCP I:X

I->>NI: Step7: TCP - I:X
NI->>-NR: 
NR->>R: 
Note over NI,NR:  Step7: TCP - I:X > NI:Y  > NR:K > R:J

R-->>I: ACK
I-->>R: ACK

par 里的 Step1、Step2 不分先后
Step3 发出去就可以进入 Step4 了
Step5 的 * 号表示任意，只要不是 R:J 都行（反正你也开Server监听了，也绑定不了）
Step7 是用 Step6 的 I:X 向 NR:K 直接发起连接

代码部分说明

1
2
3

1. 使用前，请先将 Server.js 部署，记得开启端口
2. 完善 Client*.js 中的 `SERVER_IP` `SERVER_PORT` `LOCAL_PORT`
3. 启动 ClientA.js 和 ClientB.js

/**
 * 这里的 from 和 to，分别代表的是：
 * 	from: 想要发起连接的一方
 * 	to: 被连接的一方
 * 
 * 它 **并不关乎** 这个 msg 是由 ClientA 发出还是由 ClientB 发出
*/ 
msg: {
	from: "ClientA"，
	to: "ClientB"
}

// 连接成功后，可以将 ClientA.js、ClientB.js 中的这段代码放开，然后通过键盘输入发送消息

// 键盘输入发送消息
process.stdin.on('data', data => {
    socket.write(JSON.stringify({
        type: "msg",
        msg: data.toString().trim()
    }))
})

其他

一些实验发现

NAT 维持 TCP洞口的时间一般比较短，我试过我这边区域的网络，一般是维持 5s 左右，超过 5s 这个端口没有数据包，
NAT 会默认这个端口不再使用，外面数据包再想进来都会被 NAT 丢弃，这点不管是打洞，亦或是已经建立的TCP通信
(通过服务端设置延迟返回信息，测试得到，但各区域的 NAT 会有所不同，可以自己试下)
同样，在这段维持时间内，用户通过同一个端口向外发送信息，都会绑定同一个 NAT 端口。所以并不需要端口复用，
只要在维持时间内，客户端 Destroy 之前的TCP连接（再暴力点可以直接抛出来终结掉之前的连接），
再用同一个端口建立连接/监听这个端口都是可以

数据包发送是毫秒级的，对于 5s 的窗口期来说是完全足够的 (手动才勉强)
当前这个，最差可以在 NAT3 和 NAT3 之间建立起连接，如果其中一方是 NAT4 的话，NAT3 作为需要打洞的一方即可
但可能需要用同一个端口向 NAT4 的多个端口发送数据包（端口预测）