Understanding HTTP/2 Activation Modes on BIG-IP

Introduction

Activation modes specifies how the BIG-IP system negotiates HTTP/2 protocol:

TMSH equivalent:

In this article I go slightly deeper to explain how BIG-IP negotiates HTTP/2 connection with client peers.

Traditionally, HTTP2 can be negotiated within an HTTP1.1 connection or via TLS extension Application Layer Protocol Negotiation (ALPN).

Currently, the only supported method on BIG-IP is ALPN. There is another option on BIG-IP named always.

Application Layer Protocol Negotiation (ALPN)

ALPN requires client-ssl profile applied to the Virtual Server:

In ALPN, client goes through TLS handshake with BIG-IP and both inform each other about the L7 protocol they want to negotiate in application_layer_protocol_negotiation extension on Wireshark as seen below:

When TLS handshake is finished you should see HTTP2 messages as long as traffic is decrypted because HTTP/2 requires TLS.

Always

Always is just for debugging purposes and not for production as this makes BIG-IP exchange HTTP/2 messages without the need for TLS.

In capture below, BIG-IP exchanges HTTP/2 messages with client immediately after TCP handshake, i.e. no TLS required like this:

When I say without the need for TLS, do not confuse with HTTP/1.1 UPGRADE.

In a subsequent capture, I experimentally sent an HTTP1/1 with Upgrade: h2c header using nghttp tool from my client machine (nghttp http://10.199.3.44) that signals we want to "talk" HTTP2 to BIG-IP and here's what happens:

But BIG-IP replied with SETTINGS (HTTP2 message) and GOAWAY which are HTTP2 messages:

If BIG-IP supported the UPGRADE from HTTP/1.1 to HTTP/2, it should have responded with HTTP1.1 101 (Switching Protocols) message instead and not HTTP/2 SETTINGS directly as seen above.

This also confirms BIG-IP doesn't support upgrade from HTTP/1.1 to HTTP/2.

Good bye and Thank you F5, my team and the whole community!

I'd like to take this opportunity to say that I'm leaving F5 for a new challenge but I'm not leaving F5 community. I'm truly grateful to be part of this vibrant community and I'd like to thank the whole of F5 and DevCentral community members for making DevCentral great. However, a special thank you goes to my team mates Jason Rahm, John Wagnon, Leslie Hubertus, Lief Zimmerman, Chase Abbott, Peter Silva and my manager Tony Hynes. I learnt a lot from you, had lots of fun in our in-person meetings and will be always grateful for that. You'll be truly missed. I won't be posting articles but will still be in the forums so feel free to drop me a message.

Published Jun 11, 2020
Version 1.0

Was this article helpful?

2 Comments

  • Hello Rodrigo_Albuque 

    Thanks for your article.

    So is there any case that the server doesn't respond the extension ALPN in the Server Hello while we still choose ALPN as Activation Mode?

    Because we are actually using ALPN mode in our http/2 profile associated with the VS. However, sometime in the Server Hello packet, we see no extension ALPN and then result the client would use http/1.1 and it causes our issue (error message "ERR_HTTP2_PROTOCOL_ERROR" in customer's browser)

    With another connection including ALPN extension in Hello Server packet, client will use http/2 and then everything is ok.

    Hope to see your advice.

    Thank you in advance.

  • Hello, CF-Gallia-MS-NOC , thank you for your question. In the capture snippet you pasted, it is ok for BIG-IP not to come back with an ALPN extension header because you're reusing a previous TLS session so the security parameters previously negotiated, including the ALPN extension are re-used.

    This could instead be a bug on your client if it's requesting to re-use the same previously negotiated TLS connection but at the same time it wants BIG-IP to re-negotiate the HTTP protocol.

    I also have an article about TLS session resumption and TLS renegotiation.

    Let me know if you have further questions.