I would like to ask if I should expect some different round-trip time (sending some information to the server and recieving a response) when implemented with web sockets (message) compared to a standard HTTP GET. I assume that the web socket is already connected and the DNS is resolved.
As far as I understand it it would be different if GET would consist of multiple roundtrips in the underlying protocol, which I'm not sure of. Otherwise I would expect the same results.
It depends on the initial scenario you are considering.
Example 1: You already have an HTTP 1.1 connection in place in one case and a WebSocket already established in the other case. In this scenario the round trip for both cases will be exactly the same, because in both cases you already have the TCP connection established and no further application-handshake is necessary. (Note: the quantity of data sent for the two cases will be different, but this impacts bandwidth, not latency, that is, round-trip time).
Example 2: You already have an HTTP 1.1 connection in place in one case (because perhaps you just downloaded the last image in your page) and no WebSocket opened in the other case. Well, in this scenario the round-trip time over HTTP will be lower than the round-trip time over WebSocket. The reason is that with HTTP you only need to send a TCP segment and receive a TCP segment (single round trip). With WebSockets you need to set-up the TCP connection and to perform the WS handshake, which involves a few round trips.