Enterprise Integration Zone is brought to you in partnership with:

Ayende Rahien is working for Hibernating Rhinos LTD, a Israeli based company producing developer productivity tools for OLTP applications such as NHibernate Profiler (nhprof.com), Linq to SQL Profiler(l2sprof.com), Entity Framework Profiler (efprof.com) and more. Ayende is a DZone MVB and is not an employee of DZone and has posted 479 posts at DZone. You can read more from them at their website. View Full User Profile

Why TCP is Evil and HTTP is King

  • submit to reddit

Nitpicker corner: If you tell me that HTTP is built on TCP I’ll agree, then point out that this is completely irrelevant to the discussion.

I got asked why RavenDB uses HTTP for transport, instead of TCP. Surely binary TCP would be more efficient to work with, right?

Well, the answer it complex, but it boils down to this:


Huh? What does Fiddler has to do with RavenDB transport mechanism?

Quite a lot, actually. Using HTTP enable us to do a lot of amazing things, but the most important thing it allows us to do?

It is freaking easy to debug and work with.

  • It has awesome tools like Fiddler that are easy to use and understand.
  • We can piggyback on things like IIS for hosting easily.
  • We can test out scaling with ease using off the shelf tools.
  • We can use hackable URLs to demo how things work at the wire level.

In short, HTTP it human readable.

For that matter, I just remapped the Changes API solely for the purpose of making it Fiddler friendly.

Coming back again to building pro software, making sure that your clients and your support team can diagnose things easily.

Compare this:


To this:

There is an entire world of difference between the quality that you can give between the two.

And that is why RavenDB is using HTTP, because going with TCP would mean writing a lot of our own tools and making things harder all around.

Published at DZone with permission of Ayende Rahien, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Robert Saulnier replied on Thu, 2012/08/02 - 8:27am

You're comparing the wrong things. You should be comparing HTTP with a custom/binary protocol, not TCP. HTTP and your custom protocol both run on top of TCP.  Here's my suggested title: Why Custom Protocol is Evil and HTTP is King Bob 

Balint Persics replied on Mon, 2012/08/13 - 10:55am

This article gets to a bad conclusion because it relies on false assumptions.

You are right that HTTP is better for debugging by humans since it is human-readable. But in production no one will read your HTTP messages, they are read by machines (software). For machines binary protocols are much better.

You should design your database for production use not for debugging. HTTP is king for retrieving documents, HTTP is not intented for XML-RPC style communication (like the command= parameters) etc. Think REST. That's the real HTTP. It is sad that we gave a new name for real HTTP because we misused it for more than a decade.

If you do not have any good debugging tools for your protocol, c'mon make one. Wireshark can be extended.

Designing for production use based on availability of debugging tools makes a bad product and I won't use it because it is badly engineered. 


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.