Skip to main content

SPDY (pronounced speedy); NPN (Next Protocol Negotiation); ALPN (Application Layer Protocol Negotiation) and HTTP/2



SPDY (pronounced as SPeeDY) :-



SPDY is an experimental protocol developed at Google, designed to reduce the latency of web pages. Specifically, its goal is to address the limitations of HTTP/1.1 and to remove existing bottlenecks like:-

 - head of line blocking,
 - inefficient use of underlying TCP connections,
 - and header bloat


SPDY achieves reduced latency through compression, multiplexing, and prioritisation.
The name "SPDY" is a trademark of Google and is not an acronym.

Implementing a new protocol across the web, where varieties of devices exists along with multiple range of OS across platforms, is like play with fire. This may lead to random dropped connections with no or very little troubleshooting information and will cause frustration for the end user. To deal with this, SPDY is delivered via SSL.
End-to-end encrypted tunnel allows the client and the server to exchange SPDY frames without intervention by intermediate nodes. It's important to note that SPDY does not require SSL, but in practice, SSL is a pragmatic choice to get to a working solution.

So, how the client and server will know to use the SPDY after the establishment of TLS/SSL session ?
Here comes NPN is picture.
Next Protocol Negotiation (NPN) is a TLS extension, which was developed as part of the SPDY effort at Google to enable efficient application protocol negotiation during the TLS handshake. 

The biggest difference between HTTP/1.1 and SPDY, is that each user action in SPDY is given a "stream ID", meaning there is a single TCP channel connecting the user to the server. SPDY splits requests into either control or data. SPDY has shown evident improvement from HTTP, with a new page load speedup ranging from 11.81% to 47.7%.

On February 2015, Google had announced that following the final ratification of the HTTP/2 standard, support for SPDY would be deprecated, and that support for SPDY will be withdrawn completely in 2016.


Application Layer Protocol Negotiation (ALPN) :-


ALPN is a revised and IETF approved version of the NPN extension. Application Layer Protocol Negotiation (ALPN) is a TLS extension that introduces support for application protocol negotiation into the TLS handshake (please see TLS Handshake blog), thereby eliminating the need for an extra roundtrip required by the HTTP Upgrade workflow. 

Specifically, the process is as follows:

The client appends a new ProtocolNameList field, containing the list of supported application protocols, into the ClientHello message.
The server inspects the ProtocolNameList field and returns a ProtocolName field indicating the selected protocol as part of the ServerHello message.

The server may respond with only a single protocol name, and if it does not support any that the client requests, then it may choose to abort the connection. As a result, once the TLS handshake is complete, both the secure tunnel is established, and the client and server are in agreement as to which application protocol will be used, they can begin communicating immediately.

ALPN eliminates the need for the HTTP Upgrade exchange, saving an extra roundtrip of latency. However, note that the TLS handshake itself still must be performed; hence ALPN negotiation is not any faster than HTTP Upgrade over an unencrypted channel. Instead, it ensures that application protocol negotiation over TLS is not any slower.

In NPN, the server advertised which protocols it supports, and the client then chose and confirmed the protocol whereas in ALPN, this exchange is reversed: the client now specifies which protocols it supports, and the server then selects and confirms the protocol. The rationale for the change is that this brings ALPN into closer alignment with other protocol negotiation standards. In other words, ALPN is a successor to NPN, and NPN is deprecated. Clients and servers that rely on NPN negotiation will have to be upgraded to use ALPN instead.



HTTP/2 :-




HTTP/2 (originally named HTTP/2.0) is the second major version of the HTTP network protocol used by the World Wide Web. It is based on SPDY. HTTP/2 was developed by the Hypertext Transfer Protocol working group (httpbis, where bis means "repeat" or "twice") of the Internet Engineering Task Force. HTTP/2 is the first new version of HTTP since HTTP 1.1, which was standardised in RFC 2068 in 1997.

Why not HTTP/1.2 ?
----------------

To achieve the performance goals set by the HTTP Working Group, HTTP/2 introduces a new binary framing layer that is not backward compatible with previous HTTP/1.x servers and clients. Hence the major protocol version increment to HTTP/2.

HTTP/2 leaves most of HTTP 1.1's high level syntax, such as methods, status codes, header fields, and URIs, the same. The element that is modified is how the data is framed and transported between the client and the server.

The standardisation effort came as an answer to SPDY, an HTTP-compatible protocol developed by Google. HTTP/2 uses a fixed Huffman code-based header compression algorithm, instead of SPDY's dynamic stream-based compression. This helps to reduce the potential for attacks on the protocol.

The httpbis working group considered Google's SPDY protocol, Microsoft's HTTP Speed+Mobility proposal (SPDY based), and Network-Friendly HTTP Upgrade.
HTTP/2 is defined for both HTTP URIs (i.e. without encryption) and for HTTPS URIs (over TLS, where TLS 1.2 or newer is required).
Although the standard itself does not require usage of encryption, most client implementations (Firefox, Chrome) have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory.
Roughly 1.2% of all websites support HTTP/2 till August 2015.



Popular posts from this blog

Availability of 5 GHz WLAN Channels in India under unlicensed band

Availability of 5 GHz WLAN Channels in India under unlicensed band  In India, Wireless Planning and Coordination Wing of Department of Telecom, under Ministry of Communication takes care of licensing of radio frequencies.  In the latest National Frequency allocation plan 2018 (https://dot.gov.in/sites/default/files/NFAP%202018.pdf), Government of India (GoI), exempted the licensing requirements of the following radio frequency ranges for wireless usage and a gazette notification has also published for this (https://dot.gov.in/sites/default/files/License%20Exemption%20in%205%20GHz%20G_S_R_1048%28E%29%20dated%2022nd%20October%2C%202018_0.pdf)  -- 1.  5150-5250 2. 5250-5350 3. 5470-5725 4. 5725-5875 References

Identity PSK ( iPSK)

With the evolution of IoT (Internet of Things), devices that connect wirelessly have increased many folds. From webcams, Smartwatches, fitness bands, firestick, Alexa, Google Home, and many more.., everything is going wireless for connectivity and so does the security threat. The main concern with IoT devices is the unavailability of the full wireless protocol stack (and in the majority of devices, support of 802.1x is not available). So, previously we only have the WPA-PSK option for connecting the IoT devices.  In WPA*-PSK (WPA or WPA2) WLAN, a Pre-Shared Key (PSK) is configured and distributed to all the clients that connect to the WLAN. This leads to PSK leakage, and it can be accessible to unauthorized users (due to the nature of common PSK across all the devices).  Therefore, there was a need to provision unique PSK or Multiple PSK per SSID. Identity-PSKs are unique pre-shared keys created for clients/groups on the same WLAN. Features of iPSK:-   1.Unique PSK for individual Cli

Summary report of APNIC 55 (APRICOT 2023) Meeting held in Manila, Philippines

APNIC Logo The APNIC 55 meeting was held in Manila, Philippines from 20th Feb to 02nd March 2023. The meeting was hosted by PhNOG, The Philippine Network Operators Group (PhNOG) and supported by DOST- Advanced Science and Technology Institute. Every year, APNIC conferences are held twice, the first of each year is held in conjunction with APRICOT and the second one is a standalone conference. The last such meeting held in India was in 2012, APNIC 33 (which was in conjunction with APRICOT 2012).  APNIC 55 meeting was unique in multiple senses –  i. Firstly, because of the possibility of potential hijack [1] [2][3] of the APNIC Executive Council by Cloud Innovation Ltd. / Larus foundation / NRS, the same organizations which have dragged AFRINIC (RIR for African Continent) into the Mauritius supreme court and at one point nearly halted the AFRINIC operations by getting its bank accounts frozen (over 25 lawsuits have been filed against AFRINIC by Cloud Innovation Ltd.). Number