Is communicating using TCP faster than HTTP?

Question

WCF supports several different protocols for communicating. My WCF services are deployed on the same machine only. I just wanted to know whether TCP is more effecient than HTTP or should i go with HTTP?

Answer 1

HTTP is built on top of TCP, therefore TCP will be definitely faster. Also HTTP has to parse the text headers which is another bunch of time spent. If your use case allows that, go with TCP.

Answer 2

HTTP is a protocol on top of TCP, so it's most likely faster NOT to add an additional protocol on top. See also the OSI Model.

Answer 3

You can clearly see that HTTP is on top of TCP here: http://en.wikipedia.org/wiki/OSI_model OR even better here: http://en.wikipedia.org/wiki/TCP/IP_model

Answer 4

If your service will only run on the same machine, then try using NetNamedPipeBinding.

Of course, in any case, you should measure the performance you receive using realistic test data.

Answer 5

If your WCF services are on the same machine, use named pipes. I've found this flow chart helpful.

.

Answer 6

As has been said before, TCP is the transmission control protocol, HTTP is a protocol on top. You can create your own custom protocol that could be more efficient as it would not have some of the http baggage. I had to do this to grab frame numbers from a video stream being recorded on a remote computer.

Answer 7

The advantage of HTTP - Application layer (7 in the OSI model) - is

• close to user (human) usage, via text commands (and many responses)
• one can use telnet (to a port where an application dialogs via http protocol) for instance and issue some simple commands to dialog with the remote server
• the http protocol deals for you with otherwise complex actions

HTTP is (usually) based on TCP (transport) / IP (Network). Thus all the advantages described above bear a performance penalty. You could define yourself an application with a more flexible protocol (at the user/application level) but it usually requires more programming, like dealing with issues that were already included in HTTP. Also, as the name protocol implies, nobody will understand your own protocol if you define one, unlike http. You'll have to design, program and build not only the server side, but also the client side. Clients will have to install your program and use it.