iOS client-server app: HTTP or TCP/IP?

Question

I am about to start designing/developing a client-server iOS app. I am leaning towards using HTTP requests to get/post data from/to a server, but want to make sure this is the r

Answer 1

HTTP requires sending several dozen bytes of required HTTP header info. Raw sockets can potentially be a pinch more efficient by leaving those header bytes off. But in actuality, after all the hardware buffering and packetizing thru multiple network hops, the difference may not be measurable.

HTTP is less likely to be blocked by whoever is providing upstream net access than J random port number.

Answer 2

Actually, you might want to check out HTML5's WebSockets - they combine both the concept of configurable protocols over http/s while avoiding the bandwidth traditional Ajax httprequests demanded. Google it, it's worth your time, and it is the coming standard, given that both Google and Apple are supporting it in Safari and Chrome. By the time you're done with whatever you're approaching to start now, this will probably be reliably installed on every device out there.

Answer 3

HTTP is just a layer above TCP, so it's also "socket-based". I would use HTTP, for example because there is HTTPS for the cases when secure communication is needed. Another advantage of HTTP(S) over a custom-made TCP-protocol is that firewalls usually have a pinhole for the TCP port it uses (HTTP: 80, HTTPS: 443).

Answer 4

He means that when using HTTP you will need to send the HTTP protocol request verb (GET, POST etc) and in general obey the HTTP rules. When using sockets you are free to send whatever you want and nothing else.
To answer your question we would need to know more about your application. Here are some rules I'd stick to:

1. game - tcp
2. anything real time - tcp
3. database frontend (CRUD operations on data), social networking, non real-time gaming -- http/restful services/json
4. database frontend which you want to expose as an API to enterprise customers -- consider SOAP

Answer 5

In terms of which to go with, you should stick with HTTP unless you know how to guarantee security over a socket connection and can properly handle timeouts etc.

What he means by sending only the exact data you need is, HTTP is a protocol with several layers of abstraction between the message you're trying to send and the envelope it's being sent in.

Example of an HTTP request:

(asking for data)
GET /dumprequest HTTP/1.1
Host: djce.org.uk
User-Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive

(receiving data)
HTTP/1.1 200 OK
Date: Tue, 13 Dec 2011 01:09:14 GMT
Server: Apache/2.2.9 (Ubuntu) DAV/2 SVN/1.5.1 PHP/5.2.6-2ubuntu4.6 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0
Content-Location: dumprequest.pp
Vary: negotiate
TCN: choice
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

*a rather large HTML document here, with data somewhere in the body*

Example of a socket request:

(asking for data)
poll

(receiving data)
*data*

That's much more simplified than what you would do with a socket in reality (you may create your own serialization format for requests to keep them compact but you're almost certainly not going to only have 1 'poll' command), but you get the idea. You discard a whole bunch of extra stuff which has to be parsed, and get down to just the raw data.

Of course, in reality any packet you send will get wrapped in an PPP/Ethernet frame, then in an AAL5 frame if you use ADSL etc. This is what @hotpaw2 is saying. The real world efficiency of sockets over TCP/IP vs HTTP over TCP/IP is sometimes noticeable but other times not. It depends entirely on your use case (how frequently things need to be sent, how big the packets will be).