如何妥善处理 TCP 代理中连接的关闭
相比较于直接关闭 TCP 连接，只关闭 TCP 连接读写使用单工连接的场景较少，但通用的 TCP 代理也需要考虑这部分场景。
背景
今天在看老代码的时候，发现一个 TCP 代理的核心函数实现的比较粗糙，收到 EOF 后直接粗暴关闭两条 TCP 连接。
func ConnCat(uConn, rConn net.Conn) {
wg := sync.WaitGroup{}
wg.Add(2)
go func() {
defer wg.Done()
io.Copy(uConn, rConn)
uConn.Close()
rConn.Close()
}()
go func() {
defer wg.Done()
io.Copy(rConn, uConn)
uConn.Close()
rConn.Close()
}()
wg.Wait()
}
一般场景下是感知不到问题的，但是做为一个代理，应该只透传客户端/服务端的行为，多余的动作不应该发生，比如客户端关闭写，代理只需要把关闭传递给服务端即可。
连接关闭
调用 close 关闭连接是通用做法，相关的还有一个 shutdown 系统调用。shutdown 与 close 相比可以更精细的控制连接的读写，但是不负责 fd 资源的释放，换而言之，无论是否调用 shutdown， close 最后都是需要调用的。
对于 shutdown 第二参数的说明
- SHUT_RD 连接关闭读，仍然可以继续写。
- SHUT_WR 连接关闭写，仍然可以继续读；并且会发送一个 FIN 包。
- SHUT_RDWR 连接读写都被关闭；并且会发送一个 FIN 包。
对于上层应用而言，只需要关注 read 的结果，收到 FIN（也就是 EOF）虽然不能判断对端是关闭读写还是只关闭写，但后续处理并不会受影响。
根据读取数据来处理后续逻辑
- 判断已读数据是否符合预期来决定 关闭连接 或者 写入数据
- 向连接写入数据，失败的话直接关闭连接即可，不失败的话当前连接则为单工模式
- 关闭连接
Go 中连接关闭读写的示例
测试代码展示两个 TCP 连接分别关闭读（写）再进行写（读）
func TestTCPClose(t *testing.T) {
lis, err := net.ListenTCP("tcp", &net.TCPAddr{IP: net.ParseIP("127.0.0.1"), Port: 12345})
if err != nil {
t.Fatal(err)
}
var (
conn0 *net.TCPConn
conn1 *net.TCPConn
acceptErr error
)
acceptDoneCh := make(chan struct{})
go func() {
conn0, acceptErr = lis.AcceptTCP()
close(acceptDoneCh)
}()
conn1, err = net.DialTCP("tcp", nil, lis.Addr().(*net.TCPAddr))
if err != nil {
t.Fatal(err)
}
<-acceptDoneCh
if acceptErr != nil {
t.Fatal(acceptErr)
}
wg := sync.WaitGroup{}
wg.Add(2)
go func() {
conn1.Write([]byte("hello"))
time.Sleep(time.Second * 1)
conn1.CloseWrite()
b := make([]byte, 1024)
conn1.Read(b)
wg.Done()
}()
go func() {
b := make([]byte, 1024)
conn0.Read(b)
conn0.CloseRead()
time.Sleep(time.Second * 2)
conn0.Write([]byte("test"))
wg.Done()
}()
wg.Wait()
conn0.Close()
conn1.Close()
}
通过 tcpdump 抓包也可以看到 CloseWrite 会发送一个 FIN 包
17:21:09.877056 IP 127.0.0.1.44158 > 127.0.0.1.12345: Flags [S], seq 4257116181, win 65495, options [mss 65495,sackOK,TS val 3165750919 ecr 0,nop,wscale 7], length 0
17:21:09.877069 IP 127.0.0.1.12345 > 127.0.0.1.44158: Flags [S.], seq 188514168, ack 4257116182, win 65483, options [mss 65495,sackOK,TS val 3165750919 ecr 3165750919,nop,wscale 7], length 0
17:21:09.877081 IP 127.0.0.1.44158 > 127.0.0.1.12345: Flags [.], ack 1, win 512, options [nop,nop,TS val 3165750919 ecr 3165750919], length 0
17:21:09.877211 IP 127.0.0.1.44158 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 512, options [nop,nop,TS val 3165750920 ecr 3165750919], length 5
17:21:09.877219 IP 127.0.0.1.12345 > 127.0.0.1.44158: Flags [.], ack 6, win 512, options [nop,nop,TS val 3165750920 ecr 3165750920], length 0
17:21:10.878149 IP 127.0.0.1.44158 > 127.0.0.1.12345: Flags [F.], seq 6, ack 1, win 512, options [nop,nop,TS val 3165751920 ecr 3165750920], length 0
17:21:10.920263 IP 127.0.0.1.12345 > 127.0.0.1.44158: Flags [.], ack 7, win 512, options [nop,nop,TS val 3165751963 ecr 3165751920], length 0
17:21:11.877430 IP 127.0.0.1.12345 > 127.0.0.1.44158: Flags [P.], seq 1:5, ack 7, win 512, options [nop,nop,TS val 3165752920 ecr 3165751920], length 4
17:21:11.877460 IP 127.0.0.1.44158 > 127.0.0.1.12345: Flags [.], ack 5, win 512, options [nop,nop,TS val 3165752920 ecr 3165752920], length 0
17:21:11.882928 IP 127.0.0.1.12345 > 127.0.0.1.44158: Flags [F.], seq 5, ack 7, win 512, options [nop,nop,TS val 3165752925 ecr 3165752920], length 0
17:21:11.882957 IP 127.0.0.1.44158 > 127.0.0.1.12345: Flags [.], ack 6, win 512, options [nop,nop,TS val 3165752925 ecr 3165752925], length 0
分析
一个完整建立的 TCP 连接图如下，每条线代表一条单工连接。
┌────────┐ R W ┌────────┐ R W ┌────────┐
│ │ ◄─────────────── │ │ ◄─────────────── │ │
│ Client │ UConn │ Proxy │ RConn │ Server │
│ | ───────────────► │ │ ───────────────► │ │
└────────┘ W R └────────┘ W R └────────┘
对于 Proxy 而言，需要将一条连接的包传递至另外一条连接，收到数据包则进行转发，读取到 EOF 则关闭另一条连接的写（也可以关闭本连接的读，多调用一次系统调用）
整个关闭的流程由 Client（Server 同样适用） 发起，是一个击鼓传花的过程：
- Client 关闭 UConn 连接的写端（或读端，后续数据写入报错则进入错误处理）
- Proxy 收到 UConn 的 EOF，关闭 RConn 连接的写端
- Server 收到 RConn 的 EOF，关闭 RConn 连接的写端
- Proxy 收到 RConn 的 EOF，关闭 UConn 连接的写端
- 所有单工连接被关闭，连接代理完成
核心实现
直接拿 docker-proxy 的实现修改一下，额外支持了主动退出的逻辑。
from.CloseRead()这行代码可以不需要，已经 EOF，这条连接不会再出现数据了。- 读取或者写入失败的场景全部包含在
io.Copy中，并且忽略了错误处理，尽可能减小两个代理过程的相互影响。
func ConnCat(ctx context.Context, client *net.TCPConn, backend *net.TCPConn) {
var wg sync.WaitGroup
broker := func(to, from *net.TCPConn) {
io.Copy(to, from)
from.CloseRead()
to.CloseWrite()
wg.Done()
}
wg.Add(2)
go broker(client, backend)
go broker(backend, client)
finish := make(chan struct{})
go func() {
wg.Wait()
close(finish)
}()
select {
case <-ctx.Done():
case <-finish:
}
client.Close()
backend.Close()
<-finish
}
参考
- https://github.com/moby/moby/blob/master/cmd/docker-proxy/tcp_proxy_linux.go#L27, docker-proxy 的 tcp 代理实现