RTMP was introduced by Adobe for transferring real time media data. Hence the name Real Time Messaging protocol. RTMP is based on TCP and operates in a typical client-server architecture where client and server do an initial handshake and start sending packets of data – which can contain any object of information – video, audio, message text etc. These message packets were using guided by the AMF protocol specification. So an AMF data is sent with header information related to AMF data’s type, length in what is called as Chunks.
So once an initial handshake is done we are mostly dealing with Real time data between client <-> server. Now this can operate both ways where server can be the sender or receiver of data – which mean a client can be a viewer or a publisher of content.
This is starkly in contrast to what HTTP is designed for and is used for. HTTP is more a server side to client side data delivery protocol. So all forms of streaming media content like live/VOD streams that are delivered through HTTP are just one way data coming from server and if at all there is going to be client side HTTP interaction it has to go through another API/Application layer of web server.
HTTP is not designed for continuous connection between server & client. So each part of media data has to be fetched with new HTTP requests unlike RTMP’s one time handshake after TCP establishment which will be maintained through the entire media session.
Having said the above – the answer to media delivery and publishing over HTTP has gone through a phase of WebRTC which are continuous socket based protocols which are maintained across a session. But the web’s RTC protocol is an add-on and a separate tool that helps out HTTP and is not an extension over the RFC of HTTP!
RTMP’s limitations are now more considering the encoding to RTMP/AMF are more proprietary to Flash platform which has a lot of security flaws in its way of operation over a webpage. So if Flash is being ditched, RTMP is bye-bye too!