Advantage of RTSP over HTTP for ip cam streaming - http

I recently bought an ip cam for a project. So my project was just to create a button on a webpage to show the video feed coming from the cam when clicked on it. If i have to stream the rtsp link of the ip cam via a browser, i need to use ffmpeg for converting into HLS. But when i use a http video link of the cam, its easy and convenient. So my question is, what advantage does rtsp have over http ? and what method should i choose in a industrial project. At the moment i have successfully implemented the button with http video link and it works. I was just curious to know the advantage i will have if i use rtsp. Thanks a lot for you precious time.

it depends on the network environment that you are dealing with. For sure using dash/HLS will result in higher latency but on the other hand using TCP for streaming is easier to go through the firewalls.
Apple reasoning for introducing RTSP over HTTP:
Using standard RTSP/RTP it is possible to stream a presentation to a user via a single
TCP connection. (See RFC 2036 “Real Time Streaming Protocol (RTSP)”, section 10.12)
Unfortunately, that is not sufficient to reach a significant population of Internet users.
These users are typically on private IP networks where the client machines have indirect
access to the public Internet via email and HTTP Proxies.
The QuickTime HTTP transport exploits the capability of HTTP GET and POST
methods to carry an indefinite amount of data in their reply, and message body
respectively. In the most simple case, the client makes a HTTP GET request to the
streaming server to open the server to client channel. Then the client makes a POST
request to the server to open the client to server channel.
Link

Related

What does ecxactly http do?

I understand that HTTP is a protocol that allows information to be transferred between a client and a server. At the moment, this protocol is used everywhere: when we're opening needed web page, downloading music, videos, applications...
MDN
HTTP is a protocol for fetching resources such as HTML documents. It is the foundation of any data exchange on the Web and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser. A complete document is reconstructed from the different sub-documents fetched, for instance, text, layout description, images, videos, scripts, and more.
But it's not entirely clear to me what exactly HTTP does during this information transfer. If, as I read, a protocol is essentially a set of rules, then does it mean that HTTP just setting up rules for passing information between server and client? If so, what are these rules and what are they for?
Hypertext Transfer Protocol is a communications protocol. It is used to send and receive webpages and files on the internet. It is now coordinated by the W3C. HTTP version 1.1 is the most common used.
HTTP works by using a user agent to connect to a server. The user agent could be a web browser or spider. The server must be located using a URL or URI. This always contains http:// at the start. It normally connects to port 80 on a computer.
A more secure version of HTTP is called HTTPS (Hypertext Transfer Protocol Secure). This contains https:// at the beginning of the URL. It encrypts all the information that is sent and received. This can stop malicious users such as hackers from stealing the information and is often used on payment websites. HTTPS uses port 443 for communication instead of port 80.

How can a third person read the HTTP request headers, if those are transported via HTTP (insecure)?

My question is about networking. I'm just looking for a simple answer, yet I couldn't find one after 1 hour research. I know there are techniques such as Wi-Fi Hotspot, man-in-the-middle-attack, local network, echo switch, etc. But I couldn't find an answer to my specific question.
Let's say, client A wants to communicate with server B, and server B says client A must authenticate himself via HTTP basic authentication first. My question is, what happens if client A sends the authentication credentials via HTTP layer (insecure), who can read the HTTP headers that the client A sends to server B over the internet? Would it be easy to do that? Like placing a breakpoint between two arbitrary routers, which help to transfer the packets across the internet, in order to read those headers? How does it work in general?
Thank you!
PS.: I am not trying to learn and do it. I just want to know, how dangerous it would be, if the HTTP basic auth is made via the insecure HTTP layer.
Who can read the HTTP headers that the client A sends to server B over
the internet?
Your Network Provider (e.g Wi-fi hotspot Provider).
Your Domain Name System server (DNS, as 192.168.1.1).
Your Internet Service Provider (ISP).
Your Virtual Private Network if using one (VPN server).
Yourself Or a Virus.
and here comes the HTTPS (HTTP + SSL Encryption)
SSL is about communicating in a language that you and the server only understand.
How dangerous it would be if the HTTP basic auth is made via the insecure HTTP layer?
Well, from above, You can totally get that a simple virus or even a public Wi-fi Hotspot Device can capture and see all of your data if the communication was done in a plain HTTP Socket.
A Simple packet may contain all of your Device information including its basic contents as your passwords, credit cards information, The HTML form for the signup/login that you've just completed with all its data, VoIP Calls and messages being sent to the server + upcoming/received ones.
that's why we need SSL encryption and the server should have a valid SSL certificate too.
By the way, your device may have sent thousands of packets while you read this now!
Capturing the packets that your device sends or even the packets that other devices on your network send can be done through any packet capturing tool or software as Wireshark.

Not able to access Server-Sent-Events over Mobile 3g Network

I am having an issue with Server Sent events.
My endpoint is not available on mobile 3G network.
One observation I have is that a https endpoint like the one below which is available on my mobile network.
https://s-dal5-nss-32.firebaseio.com/s1.json?ns=iot-switch&sse=true
But the same endpoint when proxy passed using an nginx and accessed over http (without ssl) is not available on my mobile network.
http://aws.arpit.me/live/s1.json?ns=iot-switch&sse=true
This is available on my home/office broadband network though. Only creates an issue over my mobile 3g network.
Any ideas what might be going on?
I read that mobile networks use broken transparent proxies that might be causing this. But this is over HTTP.
Any help would be appreciated.
I suspect the mobile network is forcing use of an HTTP proxy that tries to buffer files before forwarding them to the browser. Buffering will make SSE messages wait in the buffer.
With SSE there are a few tricks to work around such proxies:
Close the connection on the server after sending a message. Proxies will observe end of the "file" and forward all messages they've buffered.
This will be equivalent to long polling, so it's not optimal. To avoid reducing performance for all clients you could do it only if you detect it's necessary, e.g. when a client connects always send a welcome message. The client should expect that message and if the message doesn't arrive soon enough report the problem via an AJAX request to the server.
Send between 4 and 16KB of data in SSE comments before or after a message. Some proxies have limited-size buffers, and this will overflow the buffer forcing messages out.
Use HTTPS. This bypasses all 3rd party proxies. It's the best solution if you can use HTTPS.

Can I reuse my existing TCP-Server?

At the moment I have an existing application which basically consists of a desktop GUI and a TCP server. The client connects to the server, and the server notifies the client if something interesting happens.
Now I'm supposed to replace the desktop GUI by a web GUI, and I'm wondering if I have to rewrite the server to send http packets instead of tcp packets or if I can somehow use some sort of proxy to grab the tcp packets and forward them to the web client?
Do I need some sort of comet server?
If you can make your client ask something like "Whats new pal?" to your server from time to time you can start implementing HTTP server emulator over TCP - its fun and easy process. And you could have any web based GUI.
You can just add to your TCP responds Http headers - itll probably do=)
So I mean HTTP is just a TCP with some headers like shown in here.
You should probably install fiddler and monitor some http requests/ responses you normally do on the web and you'll get how to turn your TCP server into http emulator=)
If you want keep sockets based approche use flash (there is some socket api) or silverlight (there is socket API and you can go for NetTcpBinding or Duplexbinding something like that - it would provide you with ability to receive messages from server when server wants you to receive them (server pushes messages))
So probably you should tall us which back end you plan to use so we could recomend to you something more usefull.

How to implement HTTP Tunneling

I've written a Flash (Flex) client connecting to a back-end server to exchange data.
I've also written my server from scratch, and it serves two purposes:
(1) Web (HTTP) Server- By default listens on port 80
(2) Socket/Application- Server - By default listens on port 443
Just FYI, both servers run in the same process space, for convenience reasons. They are not expected to handle massive loads, so I'm fine with that.
As soon as the Flash client is served to the browser from the HTTP socket, the client attempts to open an XMLSocket to the Socket/Application server.
I now want to implement HTTP tunneling, so that my client can connect to the Application server even if the user is behind a firewall. I do not want any external servers involved (proxies etc.) - simply use the servers I already have.
My questions:
(1) Is it better to use port 443 for that? (does it better fool firewalls?)
(2) As far as I can see, what I am required to do, is just ensure that my actual application data is simply encapsulated in an HTTP structure (preceded by a dummy HTTP header), both from the client and server sides. Is that so or am I missing anything here?
(3) Do I need to keep hiding/encapsulating my data every message I send through the socket, or can I just encapsulate the first message when opening the connection?
Thanks in advance guys!
Fuzz
Don't reinvent the wheel - use remoting via AMF protocol. AMF an HTTP-based binary format that performs serialization between ActionScript (MXML) and server side languages. Technically, this is HTTP tunneling.
Adobe offers BlazeDS (open source) and LCDS (commercial) implementations of AMF for AS/Java, but there are third-party implementations of AMF for AS/PHP, AS/Python, AS/Ruby, AS/.Net.
BTW, AMF is an open source format.

Resources