在 Android 使用者态实现 TCP 代理：从 SYN 到 FIN 的完整生命周期

这是整个系列最复杂的一篇，也是 WeakNet 最主要的部分。

前面几篇我们讲了 VpnService 怎么把流量导入使用者态、怎么从原始字节解析出 IP/TCP/UDP 头部。这些都只是准备工作，真正的难题是：拿到 App 发出的 TCP 数据包之后怎么办？其实，

TCP 是一个有状态的、可靠的、字节流协议。它有连接建立、连接关闭、管理、超时重传、流量控制、拥塞控制等一整套复杂的机制。正常情况下这些由操作程序内核的 TCP/IP 协议栈完成。而 WeakNet 要做的事情。是在使用者态重新实现一个 TCP 端点——代理既是 App 的"服务器"，又是真实服务器的"客户端"。你需要自己管理 seq/ack、自己处理 SYN 和 FIN、自己决定什么时候发 ACK、什么时候该让包"丢掉"。

说白了这不是简单的代理转发——你在使用者态实现了一个完整的 TCP 端点。按理说，

代理模型的观点是。WeakNet 是透明代理

理解 WeakNet 的 TCP 代理，最关键的一点是：代理进程维护了两条独立的 TCP 连接。

App <-- TCP --> 代理 <-- TCP --> 真实服务器 App 认为在跟服务器通信 代理建立真实连接 是跟代理通信 转发 App 的数据到服务器

App 发出的 TCP 包经过 TUN 接口到达 PacketProcessor。PacketProcessor 解析 TCP 头部，根据四元组查找或创建一个 TcpSession。对于 App 代理就是"服务器"；对于真实服务器代理，说白了就是"客户端"。两边各自维护独立的 seq/ack，互不感知。

这个模型代表着：

• App 发 SYN -> 代理创建 TcpSession -> 代理模拟 SYN-ACK 给 App -> 代理在后台连接真实服务器
• App 认为连接已经建立，开始发数据
• 真实连接可能还没建好。代理先把 App 的数据缓存起来
• 真实连接建立后代理把缓存的数据一次性发给服务器
• 之后进入双向转发：App -> 代理 -> 服务器，服务器 -> 代理 -> App

SYN 处理：连接建立的魔法

收到 App 发来的 SYN 包时代理需要做三件事：创建会话、模拟 SYN-ACK、连接真实服务器。话说回来，其中模拟 SYN-ACK 是关键——它让 App 以为连接已经建立。可以开始发数据了，

// 收到 SYN 包
if {
// 同一四元组已有未关闭会话，丢弃重复 SYN
if return
val session = tcpSessionManager.createSession(
ip.sourceAddress,tcp.sourcePort,ip.destinationAddress,tcp.destinationPort,tcp.sequenceNumber)
// 随机初始 seq，模拟真实服务器的初始
session.serverSeq = Random.nextInt
// 必须在后台线程：先给 app 发 SYN-ACK，再阻塞等真实连接
connectExecutor.submit {
// . SYN-ACK 也要经过延迟。模拟真实网络的握手 RTT
val jitter = pipeline.calculateJitter
val synDelay = .coerceAtLeast.toLong
if Thread.sleep
sendSynAck // 内部已调用 addAndGetServerSeq，// SYN 占 个 seq 号
// . 建立真实 TCP 连接
if ) {
// . 把握手期间 app 缓存的数据发给真实服务器
val pendingWriteData = pendingData.remove
if {
synchronized {
val wbuf = ByteBuffer.wrap
while ) {
session.channel?.write
}
}
}
// . 进入 relay 循环
relayUpstream
} else {
// 连不上就直接 RST。让 app 快速失败
sendRstToSession
tcpSessionManager.removeSession
}
}
return
}

• 痛点一：SYN‑ACK 模拟失误会导致整个握手卡住——如果忘记给 APP 返回 ACK，就相当于让它永远等待。
• 痛点二：SYN‑ACK 延迟设置不合理会让体验变差；说起来，过短看不到弱网效果，但过长则会让应用层感受到明显延迟。
• 痛点三：SYN 占用 seq 必须严格按照 RFC，否则后续所有包都会被视为错误而导致断连。

SYN‑ACK 构造细节与选项设置

private fun sendSynAck {
val tcpHeaderLen = /* 基础长度 + 长度 */
val pkt = ByteArray + TCP */)
/* ...IP头... */
// TCP Options:
// MSS=
// NOP + Window Scale=
// Window=
session.addAndGetServerSeq // SYN 占 个 seq
updateTcpChecksum
writeToTun
}

• 痛点四：MSS 与窗口缩放必须与实际 MTU 匹配，否则会出现碎片化或吞吐量下降的问题。
• 痛点五：`addAndGetServerSeq` 必须执行，否则后续 ACK 会错位。

TcpSession 状态机：CAS 原子保护

• "SYN_RECEIVED --> ESTABLISHED --> CLOSED"

enum class TcpState {SYN_RECEIVED。ESTABLISHED,CLOSED}
class TcpSession {
private val _state = AtomicReference
fun connectBlocking: Boolean {
val ch = SocketChannel.open
ch.configureBlocking
if )) { ch.close;return false }
ch.socket.connect,timeoutMs)
_channel.set
if ) {
try { ch.close } catch {}
return false
}
return true
}
fun close {
if == TcpState.CLOSED) return
try { _channel.getAndSet?.close } catch {}
}
}

• 痛点六：CAS 与同步锁选择错误会导致死锁或资源泄漏；是在多线程同时尝试关闭同一会话时需要确保幂等性。

“预 ACK”丢包设计——出方向数据处理精髓

// 在 ACK 前决定是否丢包
val tcpLost = pipeline.shouldDropTcpOutgoing
if {
session.clientNextSeq = newSeqEnd
sendAck
}
outgoingExecutor.submit{
ifreturn@submit
val manipulated=pipeline.processOutgoing
/* 写到上游 SocketChannel…话说回来，*/
}

• 痛点七：`pipeline.shouldDropTcpOutgoing` 的概率必须与整体网络配置保持一致。否则容易出现“看似正常但实际丢失”现象。
`
• `newSeqEnd` 与 `clientNextSeq` 的计算若出现偏差。将导致后续所有 ack 错乱，从而引起全局断连。

“重传检测” 必不可少

// 使用无符号比较防止 seq 回绕误判
val newSeqEnd=tcp.sequenceNumber+payloadSize
if and0xFFFFFFFFL)<= 
           and0xFFFFFFFFL)) return 

• 痛点八：TCP 回绕时若使用有符号比较。会导致合法重传被误判为重复，从而造成数据缺失。

“pendingData 缓存”

// channel 未就绪时缓冲等待连接建立 pendingData.compute
...

• 痛点九: “pendingData 超阈值” - 若超过1MB。则说明目标主机极可能不可达，此时应立即抛弃新数据并返回 RST，以免占用过多内存资源造成 OOM 或 FD 泄漏问题。

“入方向” 数据中继 – 从 Server 到 App

// relayUpstream // 每次读取 MTU - IP头 -TCP头 字节数以内，以保证构造出的 IP 包恰好不超过 MTU.

private fun relayUpstream{
val buf=ByteBuffer.allocate
val ch=session.channel?:return 
while {
buf.clear;var bytesRead=ch.read;...
}

下面几点值得注意：
• 读块大小 – 不可超过 MTU - IP头 -TCP头，否则构造出的 IP 包将被分片；每个分片都需要单独处理和校验。
• seq 增量 – 对方发送的是字节流。每读完 bytesRead 字节就要加上去，而不是简单地 ++。
• FIN 打洞 – 当对方发送 FIN 时它也占用了一个；如果没有正确递增，对方就收不到 FIN 或者收到错误序列。不过，

---

FIN / RST 处理 – 如何优雅关闭链接？

RST 处理最简单：直接清理会话，不走操控管线。RST 是“异常断开”，应该尽快生效，被延迟反而会导致问题。

FIN 处理要复杂一些。FIN 可能携带最终一批数据，而且要保证 FIN 在所有排队数据之后处理。FIN 整个提交到 outgoingExecutor

kotlin

if { outoingExecutor.submit{ ...

步骤拆解

• 第一步先 ：先释放管线中的残余包
• 接下来 ：停止 Relay Upstream
• 然后 ：发送 FIN‑ACK 给 APP

---

RST + FIN + FD 泄漏 —— 一个典型坑

• 为什么 RST 必须符合 RFC 当接收方收到 RST 时如果其 Seq 没有落在接收窗口内，就直接抛弃。这代表着我们必须把 RST 的 Seq 设置为 “对方期望下一个 Seq”，而且 Ack 为 “对方已收到的数据”。如果只写了 Seq 而没有 Ack 标志，在 Android 上某些实现甚至根本忽略此报文。

private fun sendRstToSession{ ... }

---

CAS & fd 泄漏

如前面讨论。当 CAS 操作失败表示已有其它线程关闭了该 Session，但此时我们还没创建 socket 或刚刚创建完成。一定要显式地 close 那个 socket，以防长期运行后文件描述符耗尽。

---

不做逐包延迟

TCP 是流协议。如果每个包都 sleep，那么第 N 个包往往比理论 RTT 多 N×sleep 时间！只在握手阶段施加人工延迟，在真正的数据传输阶段使用限速或流水线调度。而不是每个 packet sleep。

---

小结 – 一遍搞定从 SYNC 到 CLOSE 的全周期

阶段	主要操作	常见坑
接收SYN	模拟SYN‑ACK 开启后台 connect	未及时返回 ACK → 握手机能卡住
建立通道	CAS 控制状态转换 及时关闭 fd	CAS 未成功却忘记 close → FD 泄漏
出方向转发	pre‑ACK 丢包 无符号 seq 比较	ack/seq 溢出/回绕
入方向转发	按 MTU 分块 按字节递增 seq	粘包 / 冗余分片
FIN/RST	按 RFC 构造报文 资源顺序正确	RST 未带 ACK → 被忽略

---

接下来 🚀

既然已经搞定了从 SYN→ESTABLISHED→CLOSE` 全生命周期，只剩下真正操控- 数据包装器这一块可以继续：

• 如何用 flatMap 式管线串联限速／乱序／重复／篡改？
• 如何保证链路安全性与性能兼顾？其实，
• 如何通过配置快速切换不同弱网场景？

敬请期待下一篇《弱网效果管线设计》！话说回来，

---

项目地址: https://github.com/baithinking…