HTTP is mainly used for viewing web pages. Coap is a simplified version of HTTP for IoT or WSNs. Although COAP is based on UDP, it should have ACK messages to emulate TCP. Since COAP is simpler than HTTP, it will have lower latency and draw less power.
Then, why browsers and web servers do not replace HTTP with COAP? Given the previous arguments, is it expected that COAP will completely replace HTTP? Is it just a matter of time? Are there any features which are supported only by HTTP?
If coap is more efficient, can I say that http is useless in the future if we replace them to coap?
The industry plan is to improve HTTP by moving to HTTP/2, and HTTP/2 includes (amoung other features) a header compression, which should bring you similar benefits than CoAP.
While most web servers and some browsers today support HTTP/2 already, AFAIK no browser nor any server support CoAP. Same goes for TLS vs. DTLS.
Are there features coap cannot support but http can?
As you said, HTTP is TCP based, while CoAP is UDP based.
UDP requires that you send UDP pings every few seconds to keep the NAT/Firewall connection open, while in TCP typically it is only required every 15 min or so.
So if you need to keep the connection open (e.g. for push technologies), then CoAP is less efficient than HTTP (and HTTP/2).
CoAP was never intended to replace HTTP, while it seems to "emulate" http, it only because it follows the REStful Paradigm. CoAP is intended as a application layer for device and more specifically was design for Constraint device.
The REStful design was chosen also to facilitate proxying operation through http (there are recommendation for doing that in the RFC). But again was never intended to replace HTTP.
CoAP is build with small amount of resources in mind. The small header and different feature of CoAP are in place to make sure that constraint device have standards mean to communicate on the internet.
HTTP and CoAP each have their own purpose.
CoAP and HTTP con be used for different purposes. CoAP has been implemented for IoT and M2M environment,in other words,to send short messagges using UDP. For instance:
A typical CoAP exchange consists of 2 messages, i.e., a request and a
response. In contrast, an HTTP request first requires the client to establish a TCP
connection and later terminate it. This results in at least 9 messages for only one
request [11]. Note that this argument is not necessarily true for large payloads. After
TCP’s slow-start phase, it is able to send multiple packets at once and acknowledge
all of them with a single acknowledgement. CoAP’s blockwise transfer [8] though,
requires an acknowledgement for each block and leads to more messages and higher
transfer time. Since we expect the majority of CoAP messages to be rather short, this
is of less importance. However, CoAP’s blockwise mechanism allows a constrained
server to not only receive but also process a large request block-by-block. This
would not be possible if we used HTTP and TCP.
(Scalability for IoT CLoud Services by Martin Lanter)
Actually, Firefox can support CoAP using Copper(CU) plug-in. ;)
CoAP is optimized for the resource constrained networks and devices typical of IoT and M2M applications. It uses less resources than HTTP and can provide an environment for communication in WSNs, IoTs, and M2M comm. It is not made to replace HTTP.
HTTP has different application scenarios, while CoAP has a different one. HTTP is mainly designed for Internet devices where the power and other constraints are not an important issues. HTTP is more reliable than CoAP as it uses TCP.
Related
Why achieving real time connection was difficult with HTTP protocol.
As HTTP is implemented over TCP connection which is reliable and continuing the persistent connection should be easier . right?.
How Web Sockets solves this persistent connection problem?
Prior to HTTP/2, HTTP/0.9 and HTTP/1.x were just command+response protocols only. A client would send a command, the server would send a reply, done, nothing more. And prior to HTTP/1.1, keeping the TCP connection alive after each response was impossible in HTTP/0.9 and not common practice in HTTP/1.0. HTTP/1.1 standardized that practice.
So it was very difficult to implement any kind of persistent real-time bi-direction communications over HTTP until recent years. Sure, various technologies were devised to try to address this (long polling, server-side pushes, etc), but nothing was really widely accepted and put into common practice across all implementations.
Then WebSockets came along, which was specifically designed for persistent bi-directional communications, in such a way that was easy to add to existing HTTP infrastructures so server admins didn't have to re-invest in new technologies, while maintaining backwards compatibility with older HTTP systems that can't/won't support WebSockets.
Then HTTP/2 came along, which now has server pushes and multiplexing built right in to the HTTP protocol, solving many of the shortcomings of old HTTP versions, and covers some of the use-cases that WebSockets were being used for, but doesn't obsolete Websockets completely.
HTTP has a very long history of evolution to get to where it is today. Evolution takes time.
Apparently, I don't get true parallel reads of different URLs on the same server, even issuing truly contemporary requests, on multiple physical interfaces (NICs).
I think the problem could be that HTTP protocol is connection oriented, then requests are serialized at lower level into TCP/IP stack (is this correct wording?).
Does make sense to attempt to 'reimplement' an high level HTTP request with a connectionless schema, like UDP, and handle myself packet addressing, to speedup streaming ?
HTTP requests are independent. They can be issues over arbitrarily many independent connections. HTTP does not impose an limits regarding concurrency.
You hit some resource limit. Maybe your client library restricts the number of concurrent calls. Maybe the server does. Maybe the network is fully utilized. Maybe back-end resources that the server uses are maxed out.
Find the bottleneck and eliminate it. The transport protocol is not the problem. Changing it can't help.
different URLs
Whether the URL is different or not makes no difference, except if the server implements some special throttling. Highly unlikely.
on multiple physical interfaces (NICs).
You are probably not network-bound.
requests are serialized at lower level into TCP/IP stack
No. Connection management is not part of HTTP. The client decided how many connections to use. Reconfigure the client.
Does make sense to attempt to 'reimplement' an high level HTTP request with a connectionless schema, like UDP, and handle myself packet addressing, to speedup streaming ?
You will have to re-implement flow control, segment fragmentation, re-transmission and other features of TCP protocol yourself. And then your HTTP implementation will not be compatible with the standard one.
So no, it does not make much sense.
For streaming you may like to use protocols designed for streaming, like WebRTC.
I don't seem to find a answer, so I'm asking you.
Does a stock Icecast2 server use TCP or UDP to broadcast the streaming data? I know that it uses a custom HTTP based Application Layer protocol, so one might think its TCP, but on the other hand it is a broadcast application, so UDP would be more logical to me. If it uses TCP nonetheless, why does it do that?
Icecast and SHOUTcast both use TCP for both the source streams and streaming to end clients. There are many reasons this is beneficial:
The codecs used by most internet radio stations do not lend themselves well to having lost chunks of data. If the stream were corrupt, either by lost or out-of-order packets, the decoder will sometimes be able to re-sync and continue, but many will simply fail.
Most internet radio stations have no real latency requirement. Nobody knows or cares if they get the audio delayed by a few seconds. It is actually typical to crank up the buffer size to allow clients to start playback quickly, causing delays of 10-30 seconds.
It is important to be compatible with HTTP. I suspect that when Nullsoft originally built SHOUTcast, their goal was to get up and running with it as simply as possible, so it makes sense that they mimicked HTTP. I suspect that the reason Icecast and SHOUTcast are so popular is that it is easy to write a client for them because it is essentially HTTP. Now that web-based players are a reality (with Flash and even HTML5), it is critical that the protocol be compatible with HTTP as many browsers do not support other streaming protocols. (Flash has its own protocol, but it is not nearly as simple as HTTP to implement.) If a client can play a file streamed from an HTTP server, it can stream from Icecast (and SHOUTcast if it is lenient in its HTTP implementation).
You mentioned broadcast... I don't know if you meant in the sense of UDP broadcast packets, but those do not work well in practice over the internet. Therefore, the only benefit to using UDP would be to reduce overhead, but I think you will see that for the reasons above, the few bytes of overhead don't outweigh the benefits of TCP for this type of application.
In short, this is not a telephony application where latency matters and custom clients can be used.
that's the question.
Dose anyone know?
I wonder If I could develop a UDP protocol based application to enhance service response.
There is a reason HTTP uses TCP. TCP provides reliability, e.g. no lost, no duplicate and no reordered data. This features are necessary, so that you don't get any broken content back from the server and no broken uploads. Of course you can re-implement this in UDP - but I doubt that you will have improved response time compared to TCP when you are done.
I was considering doing a chat server using node.js/socket.io. Should I make it a tcp server or a http server? I'd imagine tcp server would be more efficient, but can you send other stuff to it like file attachments etc? If tcp is more efficient, how much more so? Also, just wondering how many concurrent connections can one node.js server handle? Is it more work to do TCP or HTTP?
You are talking about 2 totally different approaches here - TCP is a transport layer protocol and HTTP is an application layer protocol. HTTP (usually) operates over TCP, so whichever option you choose, it will still be operating over TCP.
The efficiency question is sort of a moot point, because you are talking about different OSI layers. If you went for raw TCP sockets, your solution would probably be more efficient - in bandwidth at least - since HTTP contains a whole bunch of extra data (the headers) that would likely be irrelevant to your purposes (depending on the scale of the chat program). What you are talking about developing there is your own application layer protocol.
You can send anything you like over TCP - after all HTTP can send attachments, and that operates over TCP. FTP also operates over TCP, and that is designed purely for transferring "attachments". In order to do this, you would need to write your protocol so that it was able to tell the remote party that the following data was a file, then send the file data, then tell the remote party that the transfer is complete. Implementations of this are many and varied (the HTTP approach is completely different from the FTP approach) and your options are pretty much infinite.
I don't know for sure about the node.js connection limit, but I can say with a fair amount of confidence that it is limited by the operating system. This might help you get to grips with the answer to that question.
It is debatable whether it is more work to do it with TCP or HTTP - it's a lot of work to do it in both. I would probably lean more toward the TCP option being your best bet. While TCP would require you to design a protocol rather than/as well as an application, HTTP is not particularly suited to live, 2-way applications like chat servers. There are many implementations of chat over HTTP that use AJAX, but I can tell you from painful experience that they are a complete pain in the rear-end.
I would say that you should only be looking at HTTP if you are intending the endpoint (i.e. the client) to be a browser. If you are going to write a desktop app for the endpoint, a direct TCP link would definitely be the way to go. The main reason for this is that HTTP works in a request-response manner, where the client sends a request to the server, and the server responds. Over TCP you can open a single TCP stream, that can be used for bi-directional communication. This means that the server can push an event to the client instantly, while over HTTP you have to wait for the client to send a request, so you can respond with an event. If you were intending to use a browser as the client, it will make the whole file transfer thing much more tricky (the sending at least).
There are ways to implement this over HTTP using long-polling and server push (read this) but it can be a real pain to implement.
If you are going to implement this on a LAN (or possibly even over the internet) it is worth considering UDP over TCP - in a chat application it is not usually absolutely mission critical that messages arrive in the right order, and even if it was, users would probably not be able to type faster than the variations in network latency (probably <100ms). Then for file transfers you could either negotiate a seperate TCP socket for the data exchange (like FTP), or implement some kind of UDP ACK system (like TFTP).
I feel there is a lot more to say on this subject but right now I can't put it into words - I may extend this answer at some point.
Chat servers are the Hello World program in node. Use http.
As far as the question of how many concurrent connections can it handle, that all depends on your system. Set up a simple chat server and then try benchmarking it.
Also, check out http://search.npmjs.org/ and search for chat for a few pointers.