AdguardTeam / AdguardTeam/dnsproxy

Set keepalive to clean up CLOSE_WAIT dot connections.

未关闭
#444 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
主要语言
Go
星标
3.3k
派生
343
PR 合并指标
30 天内没有已合并 PR

描述

Currently `dot` use simple slice to maintain existing connections. There is no logic about checking connections to clean up invalid connections.

```go
type dnsOverTLS struct {

// conns stores the connections ready for reuse. Don't use [sync.Pool]
// here, since there is no need to deallocate these connections.
//
// TODO(e.burkov, ameshkov): Currently connections just stored in FILO
// order, which eventually makes most of them unusable due to timeouts.
// This leads to weak performance for all exchanges coming across such
// connections.
conns []net.Conn
}
```

However public dns like google or Cloudflare will RST or FIN on server side frequently. I got a lot of FIN_WAIT_2 and CLOSE_WAIT in AdGuard side. Following logs are due to dns server send FIN and wait for ACK FIN from dnsproxy.

```logs
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33412
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33420
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33428
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33460
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33492
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33424
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33442
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33476
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33444
```

Since there is no good connection pool and no async way to check in another thread for this.

A workaround of this in linux system is using keepalive to reduce the waiting time to 15secs, i.e.
```log
TCP_KEEPALIVE_TIME = 6s
TCP_KEEPALIVE_INTERVAL = 3s
TCP_KEEPALIVE_RETRIES=3
```

贡献指南

这个仓库没有索引到贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。