If HTTP runs on a port, does that mean TCP can also run on that port?

Question

I'm building an app that needs to run on a mobile smartphone over a GPRS/3G network. I'm doing bit ops, so every byte wasted through HTTP headers is bad. Mobile providers in my area make heavy use of proxies and the like. Websockets for one don't work.

HTTP on port 80 and 443 seems to always work, but does that mean that I can create a TCP socket connection to my server on the same port and start a bi-directional communication? I don't think mobile apps like WhatsApp, Viber etc. use HTTP connections, but I haven't find any details on their implementations and if they do anything to make the network work flawlessly over 3G, or if it just works as it is.

Solution 1

TCP and HTTP are different things.

TCP is the transport layer. By definition, it's responsible for carrying application layer protocols (HTTP in your case) over it. TCP does not run over a port. It is the arbitrator of ports. In other words, when you connect to an HTTP server, you connect on TCP port 80. When you connect to HTTPS, you're connecting over TCP port 443.

HTTP and HTTPS can run over any TCP port. 80 and 443 are just the common ones. You can make any application listen on those ports if you want. So yes, you can connect to your server over port 80 using some other protocol instead of HTTP, but only if the server is configured to listen on that port using that other protocol, and only if HTTP or HTTPS are configured to not use those ports (assuming you're running a web server on it).

Now, you mentioned that your provider is making use of a proxy. Can you make a non-HTTP/HTTPS connection over port 80 or 443? That depends on how smart the proxy is. If it's performing packet inspection, it could be verifying the HTTP headers to make sure that the traffic going over those ports is indeed HTTP traffic. There are ways to fake it, but it depends on how deeply the proxy is inspecting the traffic. If the proxy is blocking non-HTTP/HTTPS traffic on HTTP/HTTPS ports, then there isn't much you can do about it except squawk at your provider (or pay the higher price as the case may be).

When it comes to how various mobile applications communicate, it all depends on how the vendor wrote them. Most use HTTP or HTTPS over port 80 or 443 respectively because most mobile apps are just skinned web apps. But there's no rule that says they have to, and there's no real way for you to know unless you sniff the packets somehow.

I hope I have answered your question.

Solution 2

If I understand your question correctly, I might rephrase it as, "If the network infrastructure allows HTTP traffic to pass on a certain port, will it also allow pure TCP (without full HTTP-compliant operation or even fake HTTP headers) to pass on that port?"

Unfortunately, the answer is, "It depends on details you have not yet discovered regarding how the network(s) in question filters traffic". There are certainly network infrastructures that filter traffic just based on port number, so any TCP traffic over port 80 or 443 might work, whether or not the TCP payloads look or act like HTTP.

However, there are other networks that insert HTTP proxies or do deep packet inspection to see if the traffic really has HTTP headers, and those kinds of networks would block traffic that isn't proper HTTP. You might be able to get around some of those filters by putting a fake…

GET / HTTP/1.0\r\n\r\n

…at the head of each client-to-server TCP stream, and a fake…

HTTP/1.0 200 OK\r\n\r\n

…at the head of each server-to-client TCP stream. But that kind of fakery might not be enough to make it work through a full HTTP proxy.

Comments

[heavyd]

Most mobile apps do use HTTP to communicate. And, if you're not using HTTP, then going over port 80 is probably not going to be useful, since your traffic will likely go to the proxy and fail.

[Frank Thomas]

HTTP is a layer 7 protocol, whereas TCP is a layer 4 protocol. HTTP command sequences and data flow over a TCP connection, so the answer to your title is an emphatic no. that said however, only one process can use a port at one time. You can run non-http traffic through a connection on port 80, but be aware that intermediary systems can detect the protocol involved, and make management decisions based on that (like blocking the connection if they so choose). 443 is a little better because its expected to be encrypted, but that is not a panacea.

[Jason C]

Adding: For incoming connections, if another application already has TCP port 80 open (e.g. an HTTP server), your application would not be able to also listen on TCP port 80, since the HTTP server is already using it. Also here is a nice little graphic showing HTTP's place in the OSI model.

[Ramhound]

@JasonC - The author talks about WhatsApp, Viber, on mobile devices. I am not sure if running a web server is a concern of the author.

[Alper Turan]

No. Running a web server on a mobile device is not my aim. I maybe could confuse DPI heuristics, fake headers and encrypt content, but it defeats the purpose of what I'm doing. That's why you can't have nice things on mobile. I just did a NPI myself and yes, Android apps on my smartphone do use HTTP, except for WhatsApp which uses HTTPS.

[Alper Turan]

Yes, exactly, that's what I meant. That sucks badly, because my provider uses multiple types of DPI. Adding the header overhead makes all my attempts to use the least data void, also because the data I send is smaller than the header, even going as far as 1-2 bytes.

[Jason C]

@AlperTuran Oh, I misunderstood. The OSI breakdown might still be helpful at least.

[Alper Turan]

@JasonC No biggies. The OSI model is indeed useful to know.

[Wes Sayeed]

@AlperTuran, I shudder to think of what apps out there are using plain-old unencrypted HTTP to communicate -- especially ones that have account info tied to them.

[Wes Sayeed]

@AlperTuran; I'm not knocking on you or anything, and I have no idea what your app does... but it seems to me that sending tiny packets of only 1-2 bytes is a really ineffecient way to do things.

[Alper Turan]

@WesSayeed Isn't it the other way around? My app just sends commands to a remote server which is both interfaced to a remotely controlled drone and electric appliances. Given that it is going to run very often, every additional byte sent is going to waste more battery than needed.

[Alper Turan]

@WesSayeed What about HTTP/2? Does it work in this situation or is it subject to deep packet inspection blocking too?

[KeyC0de]

Great answer. One quick q. How can a proxy not block non-HTTP/HTTPS traffic on HTTP/HTTPS ports? Since these ports are dedicated to HTTP/HTTPS traffix how you can you allow other services to pass from it? Is this possible? Am i missing something? Thanks.