Important: Please read the Qt Code of Conduct -

QWebSocketClient close() leads to TCP reset instead proper disconnection

  • Lifetime Qt Champion


    I'm running the Echo server example together with the Echo client example on Ubuntu 18.04 x64 with Qt 5.14.0 and encountering a strange problem: When the client calls close(), I'd expect a proper shutdown sequence (TCP FIN > FIN ACK > ACK).

    What instead happens is:

    • The client sends a Websocket FIN (packet 11)
    • The client sends a TCP FIN (packet 12)
    • The server responds with a Websocket FIN (packet 13)
    • The client sends a TCP RST which aborts the connection (packet 14)


    I'd expect the packet 11 as unneeded, as the Websocket FIN was already given in packets 9 and 10. Unfortunately, now all goes wrong and the server does not respond with a TCP FIN ACK.

    That really smells like a bug - am I missing something?


  • From what I understand there are differing session semantics, depending upon which http version being used. For 1.1 who closes the session depends upon who sends the header/response "Connection: close". You might play with that to see if the behaviour changes and get a better idea what's going on.

  • Lifetime Qt Champion

    I've had the same problem when running the client against ws:// and created QTBUG-81084 to track that.

    Thanks and regards

Log in to reply