Replacing HTTP with plain TCP in a client-server application

Question

I'm building a small application composed of:

• Client (command-line)

• Business logic (remote server)

It's a simple game of tick-tack-toe where the client sends information to the server about which field has been marked and the server returns an updated ASCII drawing of the board.

My initial idea was to implement the client-server communication using RPC over HTTP.

However, since HTTP uses a TCP connection anyway, and I don't seem to have a need for the HTTP headers (I'm sending really small amounts of data) wouldn't it be a better idea to just use a plain TCP connection and do RPC that way?

Could I run into any problems if a large amount of concurrent players (clients) decided to connect to my game (i.e. should I close the TCP connection with every request or keep it open while the game goes on)?

Answer 1

This sounds like homework, and in that case you should probably just do whatever is easiest that's in line with what the instructor is expecting. If you want to learn as much as possible, just do it both ways. The reason I bring this up, is that many of the benefits of using HTTP are not going to be evident in a toy example with few real-world requirements.

So why use HTTP as opposed to a plain TCP socket? Paul mentioned one practical concern with regards to firewall traversal. Another practical concern is that there already exist libraries that will handle HTTP communication on both the sending and receiving end. If you use a raw socket you are going to have to solve problems that HTTP or HTTP servers already solve such as breaking the input into discrete messages and demultiplexing the requests. At a more architectural level, by using a standardized, uniform interface, you can layer on functionality that need know nothing about your application. For example, encryption via TLS or caching layers or access control mechanisms or transparent compression.

That said, HTTP isn't usable for everything. HTTP isn't well suited for low-latency, quickly changing, time-sensitive data. Indeed, TCP is often unsuitable for that and UDP-based protocols are used instead. As you allude to, the overhead of HTTP may lead to the metadata dominating the bandwidth for small messages. In most cases this doesn't really matter since you'd need a large number of messages then to lead to bandwidth bottlenecks. HTTP/2 also changes the equation here a bit.