

SSH uses four TCP segments for each character you type - ultimoo
http://blog.hyfather.com/blog/2013/04/18/ssh-uses-four-tcp-segments-for-each-character/

======
simias
Well, that's just called "remote echo" and it doesn't have much to do with
SSH. It's just that the remote is in charge of drawing the character on the
screen if needed.

If you change to "local echo" it would cause problems with programs such as vi
which will interpret certain characters (such as hjkl) as special commands and
won't actually draw them on the screen.

If you start a remote program that just "eats" your input without updating the
terminal (like a password prompt) you won't see the 2nd tcp roundtrip.

You'd have the same behaviour with a serial link, rsh, telnet or anything
else.

I think I saw a custom SSH client on hn some months ago that would try to
compensate high network latencies by echoing the characters locally while
waiting for the remote reply. It would then undo the local echo and use the
"authoritative" reply instead.

~~~
robinson-wall
Are you thinking of Mosh? <http://mosh.mit.edu/>

~~~
markild
I have used Mosh as my primary remote access client for a few months on my
"on-the-go" laptop, and I must say that the user experience is very good.

In a lot of scenarios, the latency is not much of an issue, but on wlan/3g,
this very fast become very noticeable. In the few cases since, I've used ssh
on wireless, I suddenly find myself noticing how much of an issue the sudden
feedback delay might be at some times.

~~~
eridius
Not only is mosh great for latency, but it's also great for laptops because of
IP roaming. These days I have a dedicated Terminal window with a permanent
Mosh session to my Linode. The Mosh session never shuts down (unless I'm
rebooting), no matter how often I put my laptop to sleep, or go between home
and work.

~~~
markild
Indeed.

The only obvious downside to Mosh I've seen so far, is that a lot of
enterprisy firewalls tend to block UDP traffic.

------
toki5
SSH is an interesting set of solutions that appear on the surface to be
horribly inefficient but after a tiny amount of digging are actually okay.

I had to write an SSH terminal inside a browser, and it was full of "why the
heck did they"s followed ten minutes later by "oh, that's why"s.

~~~
gcr
Do you have any anecdotes to share, or a blog post or something? I'd be quite
interested to read about your thought process.

------
msmith
One interesting thing about this is how it can lead to timing attacks which
leak information about your keystrokes. There's a great paper [1] which gives
some examples. One more reason to use pubkey authentication for SSH.

[1] <http://users.ece.cmu.edu/~dawnsong/papers/ssh-timing.pdf>

~~~
betterunix
I believe that passwords are not transmitted like this in SSHv2 because of
that very attack (not to say there are not overwhelmingly good reasons to use
public key authentication anyway).

~~~
theg5prank
They can still get you if you invoke SSH on the remote, as the password is
sent to the remote machine one character at a time, then forwarded on to your
ultimate destination all at once.

~~~
betterunix
Good point, though I imagine that this issue could be fixed in SSH as long as
the password is not being echoed (which it should not be).

~~~
msmith
Ironically, I think it's actually slightly easier for an eavesdropper to
detect that your keystrokes are part of a password if the password is not
being echoed.

They could potentially use this information to know the length of a password,
which would make brute-forcing easier. A very hypothetical attack, but fun to
think about! Less effective than a $5 wrench, no doubt.

------
Aloha
I'm honestly wondering why this is here.

Specifically, the section on "Why not send whole commands" made me wonder who
this is targeted at, its pretty basic UNIX stuff to know how an Async ASCII
terminal works.

~~~
njharman
Then, obviously, it's targeted at people who don't know "pretty basic UNIX
stuff". Which to a few points of precision is everyone. And, guessing, a
significant enough portion (to be interesting article) of HN readers.

------
zobzu
you can also use linemode. it works for telnet and, uhm, it sort of work for
ssh through a 3rd party patch. it sends whole commands AND supports
everything. That's because its not just a dumb echo, and require terminal
support on the server side.

mosh actually does something in between (and thus have display errors
sometimes)

------
ibotty
it's hardly surprising that you send one packet, get one ack and then, when
the shell wants to update the display sends a packet and then gets one ack.
how should it be different? (leaving aside udp-protocols for similar
functionality as mosh)

------
quackerhacker
Just a question...Doesn't TCP confirm the data sent, UDP doesn't and has a
lower overhead, right?

~~~
chinpokomon
Correct, UDP doesn't ACK, but you also don't know if the packet reached the
server for the same reason. UDP is great for streaming data that may arrive
out of order or where packets can be lost and it isn't critical, such as
streaming video, but it is awful if you need to be sure the data got to its
destination.

~~~
quackerhacker
Thank you, that's what I was thinking about UDP. I knew UDP was good for video
and raw data packets. Disappointing that Webworkers, Video, and Audio streams
for HTML5 still use TCP.

BTW: awesome handle - south park, lol :)

~~~
raylu
You mean websockets? Those try to support all the legacy of HTTP proxies
(which I don't understand the point of).

~~~
quackerhacker
whoops, yeah I meant websockets (was coding a worker when I commented lol)

------
inopinatus
I always used to turn off delayed acks when tunnelling X11 over SSH, for
substantial improvement in interactive responsiveness.

------
shafferj
Why is this surprising?

