首页 > 极客资料 博客日记
[Go] 如何妥善处理 TCP 代理中连接的关闭
2024-10-24 19:30:02极客资料围观19次
如何妥善处理 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 代理实现
标签:
上一篇:处理异常的13条军规
下一篇:ansible批量部署apache
相关文章
最新发布
- Nuxt.js 应用中的 prerender:routes 事件钩子详解
- 【问题解决】Tomcat由低于8版本升级到高版本使用Tomcat自带连接池报错无法找到表空间的问题
- 【FAQ】HarmonyOS SDK 闭源开放能力 —Vision Kit
- 六、Spring Boot集成Spring Security之前后分离认证流程最佳方案
- 《JVM第7课》堆区
- .NET 8 高性能跨平台图像处理库 ImageSharp
- 还在为慢速数据传输苦恼?Linux 零拷贝技术来帮你!
- 刚毕业,去做边缘业务,还有救吗?
- 如何避免 HttpClient 丢失请求头:通过 HttpRequestMessage 解决并优化
- 让性能提升56%的Vue3.5响应式重构之“版本计数”