Presumably with the TCP URG flag. That said, I only read years ago that's how it's done, without ever checking myself. I've found references to in in telnet, but not ssh, so perhaps the latter uses some other mechanism.
The way you'd want to use it is not to transmit the Ctrl-C urgently (that direction is clear), but to transmit the interruption of the reply urgently back to the client. And I think there's nothing that will save the server from having to actually send all the bytes that you managed to attempt to send before you received the Ctrl-C.
Also, it's completely broken: https://tools.ietf.org/html/rfc6093
mosh works around this by rendering the terminal window server-side and sending diffs of the terminal window (think VNC or streaming video) to the client. So the in-flight data from server to client is at most a screenful. If the data isn't sent in the first place, you don't have to worry about unsending it. (Of course the tradeoff is loss of scrollback.)
That could always be buffered on the server side.
You can probably do some things to heuristically improve scrollback, e.g., telling the terminal sync thing to sync 1000 lines of scrollback if the connection seems good and only the current screen if it seems poor. You won't get reliable scrollback but maybe it's good enough.
ET however uses TCP, and some type of BackedReader and BackedWriter for TCP data - which _implies_ to me that everything is being sent/received in a massive queue. Also, it supports scrolling, which would be difficult _(but not impossible)_ if they only cared about recent frames like Mosh.
Finally, I'm curious how well it handles mobile connections. That's another selling point of Mosh. Admittedly I never use mobile internet, so that's not a concern of mine, personally.
I love Mosh and I'm always happy to see competing apps, hope they complement each other well :)