I have a (Java-) application on many distributed embedded devices talking to my server. The communication consits of HTTP requests, started from either side and is currently secured by building a openVPN tunnel. This works great and has the following required features:
- secure (eavesdropping, injection, authentication etc)
- bidirectional - any of the two parties can start a request
- handles going through firewalls and NAT routers pretty well (as the connection is started from within the home)
- reconnects by itself on tunnel loss
Unfortunately it has also the following disadvantages:
- (expected) pretty heavy server load for 1000s of devices
- some data overhead and continuous sending - this is especially a problem on bandwidth & data volume limited devices
I'm considering secure WebSockets (WSS) as a replacement and would like advice whether this is a good idea. So far, I have the following questions:
- Am I right in assuming that the server load for WebSockets is minimal when no communication takes place? So this technology scales to several 10'000 clients continuously connected on a single server (with little traffic)?
- Am I right in assuming that the data overhead without communication is minimal? (keep-alive is 2bytes, I read)
- WebSockets does not define a protocol. Must I define my own request/response protocol? Or should I tunnel the current HTTP requests over the WebSocket? What is recommended?
- Must I implement reconnect strategies myself (onError, onClose -> try again immediately, if not successful wait a bit and retry etc) or are there standards?
- How well are WebSockets going through usual in-home firewalls, NAT routers, proxys etc? Is it generally working better than for VPN (which uses a non-standard outgoing port, which could be blocked)?
- As the application is not a browser, must I include trusted certificates? Or, as I control both ends, can I run my own certification authority?
- Other particular pitfalls to watch out for in machine-to-machine communication over WebSockets?