After using mosh on and off for a year, I realized that what they wrote in their PDF is absolutely true:
mosh latency isn't much different from SSH latency, which is a common misconception. What mosh adds is:
- decent prediction (this is what mitigate most of the latency)
- integrated auto-reconnect (even thus auto-ssh and others do the same thing, they're not built-in)
- mostly asynchronous keystrokes thanks to UDP+stream protocol, so if you hit ^C it will abort stuff even if the screen is scrolling. Note that the way keystrokes are handled makes it susceptible to a timing attack, and there might have been work to mitigate this that i'm unaware of.
> so if you hit ^C it will abort stuff even if the screen is scrolling
I might be wrong, but AFAIK the fact that your terminal isn't handling this correctly already is due to a flow control setup problem somewhere in the chain (probably the terminal itself, as usually the server-side components are the most ancient): if your local console is only able to download and display and scroll data at a certain rate, it should "push back" on the server to get it to send you data at a slower rate, which in turn will push back on the terminal. When setup correctly, this flows all the way back to the original application, which will itself slow down whatever it is that it is doing.
I don't mean locally: I mean that if you have all of your flow control stuff setup correctly, you shouldn't ever end up in the situation of "I hit ctrl-C to try to stop the massive stream of text, but this text was actually generated a minute ago and was streamed to me in a massive 10MB block and buffered in a bunch of sockets, so my ctrl-C is meaningless".
One thing that's distinctly better is that the backoff/recovery behavior of SSP (mosh's custom encrypted protocol, over UDP) works a lot better than TCP's. If I'm typing, and there's a network blip for e.g. thirty seconds (cell handoff), SSH will literally take minutes to get back to normal, and it'll be easier for me to kill SSH and restart the connection. mosh will recover much more quickly. TCP was written in the days when congestion on a shared Ethernet segment was a thing people actually ran into; with wireless and cell networks, that's not actually your protocol's biggest concern.
The common-case latency, when there's a good network connection, shouldn't differ much.
mosh latency isn't much different from SSH latency, which is a common misconception. What mosh adds is:
- decent prediction (this is what mitigate most of the latency)
- integrated auto-reconnect (even thus auto-ssh and others do the same thing, they're not built-in)
- mostly asynchronous keystrokes thanks to UDP+stream protocol, so if you hit ^C it will abort stuff even if the screen is scrolling. Note that the way keystrokes are handled makes it susceptible to a timing attack, and there might have been work to mitigate this that i'm unaware of.