Why TCP is Evil and HTTP is King
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Robert Saulnier replied on Thu, 2012/08/02 - 8:27am
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.