Everywhere I’ve looked for information about reliability and delivery guarantees in WebSockets, it says that it operates over TCP, which means lost packets will be automatically resent.
However, when I use Burp for testing and drop an outgoing message, the client does not react to this. The connection doesn’t drop, and new messages are sent and received correctly.
I want to understand whether the application is somehow not handling an error that exists, or if these are the specifics of how the drop function works in Burp.
In general, is it possible that a single message doesn't reach the server while the connection stays open and new messages continue to be delivered? If not, what happens when I use the 'drop' feature in Burp?
I saw this question Is it possible for a websocket frame to fail to arrive?, which is very similar to mine, but there is no relevant answer.
TCP does not resent lost packets but it will resent data which were not acknowledged at the TCP level. This resending does not need to be the same packet, but it can be combined in a new packet with not yet send data.
When you use Burp you have two independent TCP connections - one between the client and Burp and another between Burp and the server. TCP will take care that no data are lost at each of these TCP connection. But TCP does not care if Burp removes data or manipulates data when relaying the data between these two independent TCP connections.