0

in section 5.5.1 in the rfc6455 https://datatracker.ietf.org/doc/html/rfc6455#section-5.5.1, it says:

The server MUST close the underlying TCP connection immediately;
the client SHOULD wait for the server to close the connection

Dose this mean the server should intiate the close of the TCP connection (by sending out the FIN packet first) and finally enter "TIME WAIT" state? But why is it designed this way? I thought client TIME WAIT was always the best practice!

Todd Wong
  • 234
  • 1
  • 4
  • `TIME_WAIT` affects an inbound-only server less than it affects an outbound client or an inbound+outbound server, see: [TIME_WAIT and its design implications for protocols and scalable client server systems](http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html) – Remy Lebeau Jul 28 '21 at 18:57
  • @RemyLebeau Thanks for the link, sounds reasonable. Though I still kinda feel that will spend some resource on the server which is more precious than on clients. And I think the TIME_WAIT shouldn't prevent the port from being used to connect peers other than the one just closed, though I heard that TCP stacks are often misimplemented on this. BTW, I'd like mark your comment as the answer, but it is not allowed. – Todd Wong Jul 29 '21 at 05:58
  • It has nothing to do with Web sockets. TIME_WAIT is a state in the TCP protocol. Web Sockets run over HTTP which runs over TCP, so one end of the other is going to incur that state. See RFC 793. – user207421 Apr 03 '22 at 04:44

0 Answers0