If I ssh into a server, the time between say, issuing the ls command and getting the result is almost nothing.

If however I issue an http request for a simple html page (containing only the word 'hello') on the same server in the browser, it takes at least a second.

Why is this?

migrated from serverfault.com Feb 10 '14 at 23:45

This question came from our site for system and network administrators.

  • 1
    If you mean, "Why does something feel somehow?" this question will be closed. I'm sure you can edit it to conform with the FAQ – Xavierjazz Feb 10 '14 at 23:47
  • 5
    Why does riding a bike feel so much faster than making a cup of coffee? You're comparing completely different technologies, there's no point of reference. – Joel E Salas Feb 10 '14 at 23:47

I don't know that much about how SSH works, but from what I understand it basically takes your keyboard input and pipes it into the shell of a remote console. Pretty light-weight once the connection has been established and keys exchanged.

HTTP is a totally different protocol. It works a bit like this, assuming it's a just a static HTML page:

  • Establish TCP/IP session (this could involve DNS lookups)
  • Send HTTP headers
  • Send HTTP request body (GET, POST, PUT, etc)
  • Web server receives HTTP request
  • Web server checks its handler mappings to figure out how to process the request
  • Web server picks up the static HTML file
  • Web server formulates the response headers and sends them down the wire
  • Web server pushes the static HTML file down the wire
  • Your browser receives the headers
  • Your web browser receives the response
  • Your web browser waits for the connection to be closed
  • Your web browser then parses the HTML
  • Your web browser then renders the HTML to the monitor

That's a really basic overview, but there's a lot more that goes on in HTTP. It's not a "light-weight" protocol, unlike SSH.

Also, unlike SSH, most HTTP requests are self-contained and your TCP connections re-established. SSH keeps your TCP session open, meaning that every time you press a key, you don't have to re-establish the connection. That's why your web browser can survive being unplugged for a few minutes, but the moment you lose your connection your SSH session drops.

  • Thanks. I hadn't really grokked that ssh keeps the connection open while for http it must be reopened and closed for each request. – Collierre Feb 10 '14 at 23:57

You're comparing apples to oranges.

The time for you to download your one-word web page mostly consists of the time necessary to actually set up the connection: looking up the DNS record for the host, and then making a TCP connection to it, then requesting the document.

This is more comparable to the time it takes you to set up an ssh connection: looking up the DNS record for the host and then making a TCP connection to it, then authenticating, which is actually much longer since ssh is a much more complex protocol (and has to set up encryption).

Your interactive response time in an ssh session is mostly due to the amount of latency between you and the remote server, after the connection is actually established. There's no one-to-one analog to this in HTTP, though HTTP does have a keep-alive option which is on by default, and keeps the connection to the server open so that multiple resources can be downloaded without the overhead of setting up the connection again.

  • "This is more comparable to the time it takes you to set up an ssh connection" - this is a good analogy, and as it happens, in this case the time taken to set up an SSH connection to my server is much more similar to that taken for an HTTP request than it is to a ls over SSH. – Collierre Feb 10 '14 at 23:59

I just timed an SSH connection and a wget.

$ time ssh (host) echo "" > /dev/null

real        0m0.461s
user        0m0.004s
sys         0m0.012s

$ time wget (host)

real        0m0.013s
user        0m0.008s
sys         0m0.000s

"Faster" is relative.

  • you are the cool – moeiscool May 17 '18 at 2:18

Don't forget that interactive SSH sets socket TCP NODELAY option to reduce latency at the expense of used bandwidth, so pretty much your every keystroke is sent to the server immediately.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.