How tokio::io::AsyncWriteExt, shutdown method works on tokio::io::WriteHalf

[Geo-7]

Hi,
I have used tokio for a protocol aware tcp proxy , at my First attempt I tried

let client_to_server = io::copy(&mut ri, &mut wo);
let server_to_client = io::copy(&mut ro, &mut wi);
try_join(client_to_server, server_to_client).await; 

This code works but it will never disconnect from sever even if client close its connection .
Second Attempt I used

if let Err(_) = tokio::time::timeout(Duration::from_secs(timeout), try_join(client_to_server, server_to_client)).await {
                debug!("I am closing server connection after {}seconds",timeout);
            }

I set timeout to 120 seconds its OK but usually my clients finish their job under 10 seconds so lot of connection remain ESTABLISHED on server host and our old backhand has some problems with lot of connections I could reduce the timeout but in some slow case that would be a problem.
Third Attempt I used this from tokio proxy sample:

let client_to_server = async {
                io::copy(&mut ri, &mut wo).await?;
                wo.shutdown().await
            };        
let server_to_client = async {
                io::copy(&mut ro, &mut wi).await?;
                wi.shutdown().await
            };        
tokio::try_join!(client_to_server, server_to_client)?;

This works very well but I do not understand it, What is going on beneath it
My questions(It would be more welcome if the answer explain TCP FLOW in tokio) :

1. What I understand from this is if any side (Client or Server) close the TCP connection the future will end, is this correct?
2. why it is working better than my old HAPROXY setup, why I see less inactive ESTABLISHED connection on my server.
   Old setup
   Client ===>haproxy ===> Server
   New setup
   Client ===> haproxy ===> tokio_proxy ===> Server
   With the new setup everything works fine and I see about 40% less ESTABLISHED connection under the same load
   How tokio will close the connection sooner without creating any problem?
3. from tokio docs for shutdown
   Similar to [flush], all intermediately buffered is written to the underlying stream. Once the operation completes, the caller should no longer attempt to write to the stream. For example, the TcpStream implementation will issue a shutdown(Write) sys call.
   who is the caller?

[Darksonn]

In general, a TCP stream has two directions of communication, and each direction is closed independently. When you call shutdown, that closes your write direction, and the other end's read call will return with a read of length zero, which indicates that the stream is permanently closed in that direction. The tokio::io::copy method will keep running until it gets a read of length zero, at which point it will make sure to finish writing anything it still hasn't written, then return.

You usually don't close your stream in the read direction — that's the job of the other client, since that's their write direction.

The caller from the docs is whoever called shutdown.

[Geo-7]

Thanks, when the shutdown would be called in this senario?
After one of the endpoits (client or server) send TCP FIN or TCP RST or there is write idle timeout variable or both?

[Darksonn]

Well, the io::copy call returns when the other end of the connection calls shutdown. That corresponds to TCP FIN. I'm pretty sure TCP RST would result in io::copy returning an IO error instead.