Next generation HTTP afoot
Engineers rebuild HTTP as a faster Web foundation | Deep Tech – CNET News
HTTP has been the standard transport protocol since the dawn of the World Wide Web and effectively became the backbone for most file transfer and streaming activities of the modern Internet.
But there is a desire in the Internet industry to bring this standard to 2.0 and bring some major improvements to this standard to cater for today’s Internet reality.
Data multiplexing between client and server
One key capability is to implement the SPDY protocol which supports multiplexing of data between the Web server and the Web browser. This is to provide for faster and efficient data throughput by shifting the data using one “channel”; as well as providing support for managing quality-of-service.
This may involve the deployment of audio and video material under a high quality-of-service while text data and software downloads can pass through on an “as-needed” basis.
Inherent end-to-end encryption support
The SPDY protocol that is to underpin HTTP 2.0 also provides support for end-to-end transport-layer encryption. But Microsoft wanted this feature to be optional so it is implemented according to the needs, such as a blog not needing encryption whereas an Internet banking or device management Web page would need this level of encryption.
But I would also like to support in this feature the ability not just to encrypt data but to authenticate the same data using a digital signature. Here, it could permit users to be sure that the Web site they are visiting or the file they are downloading is authentic and would be especially of importance with field-updated BIOS and firmware deployments, as I raised in my commentary about a lawsuit involving HP concerning this practice and its security ramifications.
Caching support at network level
Another feature that is being proposed is to provide for network-level caching of HTTP data. This is intended to provide for environments like mobile networks where it could be desirable to cache data in the service network rather than on the user’s mobile device; rather than introducing proxy servers to provide this kind of caching.
It will also allow mobile and embedded devices to avoid the requirement to have Web caches for quick loading of Web pages. Of course this will not be needed for those Web pages that have regularly-updated data such as Web dashboards, Web mail or similar applications.
It also is worth investigating whether the HTTP 2.0 standard could support applications like client-server email delivery or advanced document authoring such as version control.
Of course this development will take a long time to achieve and will require some form of HTTP 1.x backward compatibility so there isn’t the loss of continuity through an upgrade cycle.