Why Tcp faster than http?

Question

I had a discussion with my manager, he said tcp is faster than http because of tcp is work on layer lower than http.

Then I remember about the OSI Model that I learnt in university, so I think what he meant is because http work on application layer but tcp work on transport layer (which is 2 layers belows) so is faster...

So my questions is:

1. Is lower layers works faster than upper layers is becasue there is less layers need to access when doing data transfers betweens two computers?

2. If so, that's mean when we use tcp (i.e with WCF), the commnicuation will be start at transport layers => down to physical layer => another computer's physical layer => up to transport layers? But I throught the data still need to be understand by the application, so it will still has to goes up to Application layer?

Thanks in advance.

Haematogenous

As far as u understand that topic there is no real point in comparing them as they both do completely different things. I mean you don't compare the CPU with the program even though you need it to make any use of the program. – Puente

@Puente I think I see what you mean now, protocol in Application layer is for identifiying comminucation partner etc, but Transport layer is for data transfers. When HTTP do a data transfer it using Transport Layer, that's why it doesn't make sense to compare. – Haematogenous

Answer 1

There is always a layer above TCP. The question is really about how much overhead the stuff above TCP adds. HTTP is relatively chunky because each transmission requires a bunch of header cruft in both the request and the response. It also tends to be used in a stateless mode, whereby each request/response uses a separate TCP session. Keep-alives can ameliorate the session-per-request, but not the headers.

Scorch

So that's mean no matter what types of protocal we are using for data transfers, we will still need to access all layers Application Layer down to Physical Layer and back to Application layer on the other side? Does that means there is nothing do with which layers the protocal locate? – Haematogenous

"Always"? What if I use sockets directly? – Everyway

@KingChan when two applications communicate, there will always be objects in the applications memory representing the data (application layer) that is received as electric signals through the wire (physical layer). All layers will be touched. – Balkhash

@JohnSaunders: I think Marcelo means that you use sockets for some reason, and this reason is a layer above TCP – Bottommost

Stateless doesn't imply separate connection. HTTP implementations go to great lengths to conserve TCP connections. – Retract

@EJP: I covered that. What I didn't point out is that keep-alives aren't always practicable, depending on the topology, proxying setup, maturity of the client and/or server frameworks, etc. Even something as simple as not knowing the size of the request or response in advance will prevent the use of keep-alives. – Scorch

@JohnSaunders: AndyT pretty much nailed it. TCP's only intrinsic purpose is to reliably transmit a stream of bytes between nodes. Anything you do with those bytes is thought of as a higher layer (most likely OSI layer 7). – Scorch

@Marcelo: wow! I really didn't know I was writing layer 7 code. – Everyway

Answer 2

I noted the WCF tag, so I guess you're comparing NetTcp to for example BasicHttp. As @Marcelo Cantos pointed out, both drive on the TCP protocol.

Whereas the BasicHttpbinding uses HTTP for transport, a message is first encapsulated in XML (which is pretty verbose and data-eager) and then sent through HTTP, using lots of data for headers.

On the contrary, NetTcp uses a (proprietary?) protocol, where the message encoding and headers are specifically designed to decrease bandwidth usage.

In a common scenario you won't see any difference, but when dealing with lots of requests or larger amounts of data (especially binary data, which has to be encoded to fit in XML which increases its size), you might gain benefits by using NetTcp.

Balkhash

Answer 3

You are correct: TCP and HTTP are protocols that operate on different layers.

In general: in order for applications to utilize networking they need to operate at the application layer. The speed that any given protocol goes depends on the overhead it demands. HTTP typically operates over TCP, so it requires all of the overhead of TCP, all of the overhead of the layers under TCP, and all the overhead that HTTP requires itself (it has some rather large headers).

You're essentially comparing apples to oranges in comparing the speeds of TCP and HTTP. It makes more sense to compare TCP vs UDP vs other transport layer protocols -- and HTTP vs FTP vs other application layer protocols.

Petrina

Now I wonder, so that's mean layers it doens't related to the speed, is basically how the speed is affected by how the protocols operate...So to know which protocal works faster than other I need to know each protocal work? – Haematogenous

How about a car analogy? This is like saying "a Honda Element is slower than a 4-cylinder engine". ;-) – Conway