TCP Vs. Http benchmark

I have a web application sitting on IIS and talking to [remote] Service-Machine. I am not sure whether to choose TCP or Http as the main protocol.

more details:

  1. I will have several services \ endpoint
  2. some of them will be one-sided
  3. the other will be two-way.
  4. Web pages will work in front of services.
  5. we are talking about hi-scale website

I know the difference pretty well, but I'm looking for a good test that shows how much faster TCP is?

+46
tcp
Jul 28 '09 at 20:44
source share
4 answers

HTTP is a layer built at the TCP level for some that standardize data transfer. Therefore, naturally, using TCP sockets will be less difficult than using HTTP. If performance is the only thing you care about, then simple TCP is the best solution for you.

You might want to consider HTTP because of its ease of use and simplicity, which ultimately reduces development time. If you are doing something that can be used directly by the browser (via an AJAX call), you should use HTTP. In order for a non-modern browser to directly consume TCP connections without HTTP, you will have to use Flash or Silverlight, and this usually happens for rich content such as video and / or audio. However, many modern browsers (starting in 2013) support an API for accessing network, audio and video resources directly through JavaScript. The only thing to consider is the speed of using modern web browsers among your users; see caniuse.com for the latest browser compatibility information.

As for the tests, this is the only thing I have found. See page 5, it has a performance graph. Note that it does not actually compare apples to apples, as it compares the TCP / Binary data parameter with the HTTP / XML data parameter. What begs the question: what data calls your services? binary (video, audio, files) or text (JSON, XML, HTML)?

A general performance-oriented system such as the military or financial sectors is likely to use simple TCP connections. Where, as companies focused on a common network, prefer to use HTTP and use IIS or Apache to host their services.

+70
Aug 02 '09 at 1:33
source

The question you really need the answer to is "Will TCP or HTTP be faster for my application." The answer is that it depends on the nature of your application and how you use TCP and / or HTTP in your application. The general test protocol HTTP vs TCP will not answer your question, since the likelihood that the benchmark will not match your application behavior.

A theoretically optimized / implemented solution using TCP will be faster than an application using HTTP. But there can also be significantly more implementation work ... depending on the details of your application.

There are other problems that may affect your choice. For example, you are less likely to encounter firewall problems if you use HTTP than if you use TCP on some random port. Another is that HTTP will simplify the implementation of load balancing between the IIS server and internal systems.

Finally, at the end of the day, it is probably more important that your system is reliable, supported, and (possibly) scalable than it is fast. A smart strategy is to implement a simple version first, but you have plans on how to do it faster ... if the simple solution is too slow.

+30
Jul 28 '09 at 22:35
source

You can always compare it.

In general, if what you want to accomplish can be easily accomplished via HTTP (i.e., the only reason you could think about using raw TCP to possibly improve performance), you probably should just use HTTP. Sure, you can program sockets, but why bother? Many people spent a lot of time and effort building client libraries and HTTP servers, and they spent waaaaaay more time optimizing and testing this code than you could ever spend on their TCP sockets. There are just so many possible errors that you will have to handle, extreme cases and optimizations that can be made, which is usually easier and safer to use the library function for HTTP.

In addition, HTTP specifications define all kinds of functions (and clients / servers implement what you can use β€œfor free,” that is, no additional implementation work), which greatly facilitates the interaction of third-party developers. "Here is my URL, here are the rules for what you submit, here are the rules for what I will return ..."

+6
Jul 28 '09 at 21:06
source

I have my own server application with native Windows C ++ hosts, in which I use the REST SDK code for Casablanca C ++. I can use any client C #, JavaScript, C ++, cURL, basically everything that can send POST, GET, Message PUT, DEL can be used to send request messages to this application for self-placing windows. I can also use the address bar of a simple browser to execute GET related requests using various parameters. Currently, I only run this system on the private intranet, so it is very fast - I do not compare it to the fact that I only do a TCP stream, but on the private intranet I doubt that the difference in a few microseconds can be different? For the convenience and simplicity of development and the possibility of expanding to a full Internet application, this is a dream come true. It is a dedicated system with a private protocol that uses small JSON packages, so it’s not certain whether this meets the requirements of your application or not? Another nice thing: this regular C ++ application code for Windows can easily be ported to Linux / MacOS, because the Casablanca REST SDK is ported to these OSs.

0
Dec 04 '18 at 21:06
source



All Articles