AdguardTeam / AdguardTeam/dnsproxy

Set keepalive to clean up CLOSE_WAIT dot connections.

Abierto
#444 1 comentario 0 reacciones 0 asignados Ver en GitHub
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.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.