Iain Learmonth
Platforms such as wireless sensor nodes are typically quite constrained in the amount of processing power, memory and battery power available. Whilst 6LoWPAN has enabled these devices to have IPv6 connectivity, the protocols that are typically deployed on top of IPv6 may not be well suited and either the protocol needs to be modified to allow for this use case or a new protocol needs to be developed. Iain Learmonth a member of the Electronics Research Group at the University of Aberdeen explains the HTTP protocol, for providing representational state transfer (REST) and how wireless sensor node may use these services to send sensor observation data to a data logger or to request configuration updates from a server.
The Representational State Transfer (REST) architectural style was developed by W3C Technical Architecture Group (TAG) in parallel with HTTP/1.1, based on the existing design of HTTP/1.0. The World Wide Web represents the largest implementation of a system conforming to the REST architectural style.’
REST-style architectures conventionally consist of clients and servers. Clients initiate requests to servers; servers process requests and return appropriate responses. Requests and responses are built around the transfer of representations of resources. A resource can be essentially any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document that captures the current or intended state of a resource.
We begin by looking at the evolution of HTTP. All HTTP versions are plain-text based protocols, i.e. no compression is performed and only printable characters are used.
HTTP version 0.9, still supported by modern web servers including the Apache HTTP server, has a simple request protocol which consists of opening a TCP connection and sending a plain-text string in the form of GET followed by a carriage return and a line feed. Headers are not supported for requests and only the GET method is available. There are also no headers attached to a response and so a zero-length response would simply result in the connection being closed. Parameters such as a sensor ID and sensor reading can be attached to the URL as parameters in order to be processed by the server.
HTTP version 1.0, again still supported by modern web servers including the Apache HTTP server, has a more complex request protocol. Once the TCP stream is opened a plain text string in the form of METHOD /url HTTP/1.0followed by a carriage return and line feed must be sent. The version number added to the request informs the server that the newer version of the protocol is in use. As HTTP/1.0 supports headers, a second carriage return and line feed must be present to indicate the end of the headers section. There are no required headers for HTTP/1.0.
HTTP version 1.1, the currently most widely deployed version of HTTP, adds further complexity by requiring the presence of a “Host” header in all requests. HTTP versions 1.0 and 1.1 also support the POST method, where the parameters are passed as a request body, which requires the additional “Content-Type” and “Content-Length” headers.
The minimum request size, assuming an 8 character sensor ID, a 5 character sensor value, an 11 character hostname and the update script being at the root of the server, for each protocol is shown in the table below:
| HTTP/0.9 | HTTP/1.0 | HTTP/1.1 | |
| GET | 26 | 37 | 56 |
| POST | – | 121 | 140 |
Minimum request sizes for GET and POST requests for HTTP versions 0.9, 1.0 and 1.1
One of the stated uses for the POST method within the HTTP/1.0 specification is “extending a database through an append operation” which is exactly what submitting a sensor result should do. GET requests are meant only for retrieving information, whether from static resources or from data generating processes. GET requests should not be used for performing any updates or changes. As a result, with version 1.0 and 1.1 of the HTTP specifications the use of a GET request to submit sensor readings would break the intentions for use laid out in the specification.
Zero-length responses from the server with versions 1.0 and 1.1 would in fact have the server respond with an HTTP status code of “204 No Content”, a number of headers, and a human-readable message as an HTML document explaining the status code. This size of this would be likely to be significantly larger than the request, although the page returned in this case by the server is configurable. As the connection is already using TCP, there is nothing gained from the receipt of a response from the server by the sensor node.
Following this analysis of the HTTP versions, it seems that as the HTTP protocol evolves, more and more complexity is being added that all adds up to increase the amount of bytes that need to be carried over the constrained low-power low-bitrate networks that wireless sensor platforms use.
The SPDY/2 and SPDY/3 protocols, whilst in current use, have not been considered for the same reason that HTTP over SSL and HTTP over TLS have not been considered. The overhead of the encryption and key generation would place considerable load on the processing power of constrained environments. Encryption, if necessary, should be implemented at the MAC layer where it can be performed by hardware as opposed to software with less overhead and reduced power consumption.