[FeatureRequest] Prefer to use established connection

[Chapoly1305]

Appears there will be a [SYN] at the beginning of each inquiry are made, and [FIN] after it.
This is acceptable when communicating locally directly on the server.

But when we rent a server and would like to setup a nginx and perform such inquiries under TLS, such SYN, FIN action will cause tons of handshakes and overheads eventually cause performance issues.

I wish the connection logic could be adjusted to only make one SYN and keep using this the connection until FIN is a must.

[Venthe]

I'll take a look, thanks for raising the issue

[0xhaggis]

You're at the wrong layer of the OSI model (layer 3). This is just how TCP/IP works. First SYN, SYN/ACK, ACK handshake and then a bunch of PSH or PSH/ACK until the connection is torn town with FIN or RST.

You seem to be talking about using HTTP Keep-Alive, which is further down the OSI model and refers to persistent HTTP connections that use one SYN, SYN/ACK, ACK handshake and then leave the TCP stream open for further HTTP requests so that the TCP/IP handshake isn't required for every transaction, thereby reducing latency.

Let's see what the TCP/IP SYN, SYN/ACK handshake does for latency:

$ sudo hping3 -S 192.168.0.250 -p 80
HPING 192.168.0.250 (eno1 192.168.0.250): S set, 40 headers + 0 data bytes
len=46 ip=192.168.0.250 ttl=64 DF id=0 sport=80 flags=SA seq=0 win=65535 rtt=7.8 ms
len=46 ip=192.168.0.250 ttl=64 DF id=0 sport=80 flags=SA seq=1 win=65535 rtt=7.7 ms
len=46 ip=192.168.0.250 ttl=64 DF id=0 sport=80 flags=SA seq=2 win=65535 rtt=7.6 ms
len=46 ip=192.168.0.250 ttl=64 DF id=0 sport=80 flags=SA seq=3 win=65535 rtt=7.4 ms
len=46 ip=192.168.0.250 ttl=64 DF id=0 sport=80 flags=SA seq=4 win=65535 rtt=7.3 ms

Round trip is approx 7.5ms per SYN request and SYN/ACK response, but omits the additional latency of the final ACK that's sent by the client, which would be another 7.5ms RTT. This makes 15ms in all, just to setup an HTTP connection.

Given that on my modest system (single RTX 3090) a typical completion request from Fauxpilot server takes 30ms to complete, then 15ms represents a fairly significant latency if you're running a system for multiple users who need fast response times.

It may well make sense to change the HTTP connection to persistent using keep-alive. Interesting post!