When Not to Embed a Web Server in a Device
Embedding a web server in a product is a remarkably powerful mechanism for easily implementing a variety of key features and functions in your device. One of the greatest benefits of an embedded web server is that it resides in the equipment itself and not as a separate software that needs to be installed on a computer. A user can simply use a browser and navigate to the IP address or domain name given to access key features in the product.
In this article, we look into a few use cases where embedding a web server in a product is not the optimal solution, but where a hybrid IoT solution creates a much better user experience.
In general, an embedded web server is not the optimal solution if:
- the product is powered by a small microcontroller such as a Cortex M4 and a secure HTTPS server is needed
- the product is deployed on an Intranet but needs to be accessible from the Internet
- the user wants to manage many products/devices simultaneously
Embedding Web Servers in Microcontrollers
Products powered by small microcontrollers, such as ARM Cortex M4, that mandate the use of secure HTTPS web servers are problematic since modern web browsers may attempt to pre-allocate as many as 12 connections before sending the first GET request. Each connection requires its own time consuming TLS handshake.
Figure1: Modern browsers may request more resources than the device can handle.
To fully understand the problem with using HTTPS in microcontrollers, we recommend reading the article "Creating Applications with the Secure Minnow Server", section Why use WebSockets for Device Management.
What is a Private Embedded Web Server
Devices and other products with an embedded web server normally operate on private networks such as Intranets. Private networks are not directly accessible via the Internet and are shielded from external Internet access by a firewall/router. For example, even the most basic home router shields any type of server solution from external Internet access.
Figure 2: External attacker is unable to access embedded web server on private network
In many cases, preventing external access is beneficial since the embedded web server is protected from potentially malicious external users. However, it creates a major problem if the product with the embedded web server needs to be operated from another network via the Internet. This type of remote access could be anything from remote management and supervision to updating the device firmware.
How to Access a Private Embedded Web Server Remotely the Hard Way
External access to one web server on a private network is technically possible by opening a pinhole in the firewall. In computer networking, a firewall pinhole is a port that is not protected by a firewall to allow a particular application to gain access to a service on a host in the network protected by the firewall.
Figure 3: External user accessing private web server via firewall pinhole
How to set up a firewall pinhole depends on the firewall product being used. However, regardless of firewall type, setting up a pinhole such as port forwarding is generally complicated and requires extensive network experience. Unless your customers are very tech savvy, setting up port forwarding will be near to impossible for them to configure. Customers deploying your products in corporate environments may have IT personnel with the required expertise, but corporate environments typically ban the use of pinholes.
For all practical purposes, accessing a private web server from another network is not practical and we should look into alternative solutions that provide an as-close-to-embedded-web-server-as-possible solution that works over the Internet.
How to Access Products on Private Networks the Easy Way
Although firewalls block all external access by default, virtually all networks allow products to connect out to services on the Internet (Figure 4). Instead of embedding a web server and waiting for incoming connections, a product can instead connect to a service on the Internet that acts as a proxy for all connected clients, including the users using a browser.
Figure 4: User accessing device on private network via online proxy
Although the solution depicted in Figure 4 can be designed from scratch or partly assembled using a number of open source products, we provide a complete ready to use secure solution called SMQ. One of the things we strive to do at Real Time Logic is to simplify security. The SMQ protocol makes it easy for you to include a multilayered defense system as outlined in the DZone article Have We Forgotten the Ancient Lessons About Building Defense Systems?.
In Figure 4, we show the virtual connection between the user and the device. The real communication path is via the online server; however, as a computer programmer, you do not have to think about it this way. You set up a one-to-one communication between the SPA running in the browser and the device. The one-to-one communication is referred to as the virtual connection in Figure 4. An SPA may be designed to manage one virtual connection as shown in Figure 4 or an SPA can also be designed to manage any number of virtual connections. In other words, an SPA can be designed to manage any number of devices simultaneously.
Unlike many IoT solution providers, SMQ does not constrain your server deployment options. You may deploy the server on one low cost virtual private server as shown in Figure 4, or you may choose to use a cloud server solution. The following figure depicts an SMQ cluster solution deployed on a cloud solution using two online servers.
Figure 5: SMQ supports clustering, thus enabling horizontal scaling and redundancy.
To learn more about how to use SMQ for remote device management, we recommend the following:
- Download the SMQ device C code stack and compile it for your host operating system (Windows/Linux), use the default settings, and connect to our public SMQ test broker. You can in that way immediately see how SMQ can be used for device management.
- Navigate to the Mako Server's IoT page and read tutorials on how to create SMQ web applications and how to install the server on an online cloud solution. The Mako Server, which is a pre-compiled binary version of the Barracuda App Server, includes the SMQ server side broker and JavaScript client framework. With SMQ, you have the option of designing, hosting, and running your own solution or you may opt to use our services.
Using an Embedded Web Server in combination with SMQ
SMQ does not exclude the use of an embedded web server. In fact, the same embedded web server's HTML web application can be re-used by the SMQ solution if the HTML web application is designed as a Single Page Application (SPA). For details on this design technique and how to re-use the SPA for SMQ, see the article Creating Applications with the Minnow Server.