AdguardTeam / AdguardTeam/dnsproxy
Set keepalive to clean up CLOSE_WAIT dot connections.
- Lenguaje dominante
- Go
- Estrellas
- 3.3k
- Forks
- 343
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Descripción
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
```
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Evaluación
Este issue todavía no se ha evaluado.