REALITY dangling connections

[izmmisha]

In function Server (tls.go) communication between client and target separated by directions.

In state when we want to pass all traffic between client and target there are two io.Copy(...) calls.
One for client -> target, and another for target -> client.

io.Copy(target, ...) dispatching client -> target stream may complete if client closes connection.
In this case nothing happen, and second io.Copy(underlying, ...) will keep untouched until target will close connection too (some servers may wait very long time before do it).

Probably it would be good to close target connection when client connection lost and io.Copy(target, ...) complete.
There is exactly same mechanism in target -> client direction,io.Copy(underlying, ...) call followed by underlying.CloseWrite().

It is simple to reproduce, just connect to xray with openssl s_client -connect ip:port and after successful connection just interrupt it with ctrl+c.

Graceful tls connection shutdown will not lead to this problem.

[Fangliding]

服务端关闭关客户端最开始也没有 因为可能导致指纹后来修掉了
这个并没有多critical 不过加一个也不是不行

[izmmisha]

Thank you!

[izmmisha]

The fix works great.

Another observation:
target connection has it's own tcp keepalive
client connection in my case has system default tcp keepalive option

This was the source of growing target connections count.

I changed tcp keepalive sock option and everything looks great now.

But probably would be nice to have ability to specify different tcp keepalive options. More strict for reality phase and more relaxed for main proxy phase.