Revert: Disable HTTP/2 to resolve significant client loading latency in high-latency scenarios

[gustavotrott]

This PR reverts the use of HTTP/2 and re-enables HTTP/1.1 for the BBB server. This change is necessary to resolve a critical performance degradation issue that occurs under non-ideal network conditions, such as high Round-Trip Time (RTT) or poor connectivity.

The Problem: Client loads extremely slow with high RTT

During the 22nd BBB Developer Conference, an investigation was conducted into reports of random high network RTT and excessive client loading times when the server is geographically distant from the client.

Reproduction Steps

1. Set up a BBB server on a different continent or with a guaranteed high-latency route.
2. Connect to the server using a client device via Wi-Fi.
3. Use the Chrome browser.
4. Open the BBB client for the first time, or ensure the browser cache is disabled in Dev Tools.
5. Observation: The client will experience a significantly slow and delayed loading process.

Root Cause: Head-of-Line Blocking in HTTP/2 Multiplexing

The core issue stems from how HTTP/2 handles multiple requests over a single TCP connection, a process called multiplexing:

• HTTP/2: All requests for client assets (JavaScript, CSS, images, etc.) are streamed over a single TCP connection. If a single request is delayed due to high RTT or packet loss, it effectively causes Head-of-Line Blocking, impacting the entire stream and delaying all subsequent requests.

• HTTP/1.1: The browser opens multiple parallel TCP connections to fetch assets. This parallelization allows unaffected requests to complete independently, mitigating the impact of any single problematic request.

Performance Evidence

Our testing confirms that while HTTP/2 offers potential benefits in ideal, low-latency environments (though we noted no significant difference in our tests), its performance degrades severely under real-world, high-latency conditions.

The following table demonstrates the loading time difference under a high-latency test scenario:

HTTP2 (22 seconds)	HTTP1 (6 seconds)

Conclusion: To ensure BBB works well for all scenarios, especially for users with poor or distant connections, reverting to HTTP/1.1 is the necessary performance optimization.

I recommend disabling HTTP/2 to prioritize a reliable and consistent user experience across the global user base.

1. Improves Stability for All Users: This change directly addresses and eliminates a major performance bottleneck for users connecting to distant or high-latency servers.
2. No Downside Risk: The original PR enabling HTTP/2 (Enable http2 in nginx #403) did not demonstrate any strong, measurable benefit, nor is HTTP/2 required for any BBB feature. Disabling it carries no known downsides.

Further Reading

For additional context on the challenges of HTTP/2 in non-ideal networks:

• "Discovering Issues with HTTP/2 via Chaos Testing" - https://www.twilio.com/en-us/blog/developers/http2-issues-html
• "Why Turning on HTTP/2 Was a Mistake" - https://lucid.co/techblog/2019/04/10/why-turning-on-http2-was-a-mistake

[kepstin]

This PR includes a large number of whitespace changes in areas that are irrelevant to the change. Can you please adjust the PR to include only the changes required?

[gustavotrott]

This PR includes a large number of whitespace changes in areas that are irrelevant to the change. Can you please adjust the PR to include only the changes required?

I saw it, but I thought it was not necessary to undo as it's easy to see the diff enabling "Hide whitespace".
And the removal of whitespaces seems to be good (it will avoid it from being removed again by the Editor in a future change).

[ffdixon]

The whitespace was just cleanup -- merged.

[kepstin]

I do not recommend merging changes with large whitespace updates like this because it will make merges between versions (e.g. updating the 3.1 bbb-install) much more difficult.