What Is HTTP/2? Does It Require SSL? Enable on Nginx and Apache

What Is HTTP/2?

HTTP/2 is the second major version of the Hypertext Transfer Protocol, standardized by the IETF in 2015 (RFC 7540). It was designed to address the performance limitations of HTTP/1.1, which had been in use since 1997 and was never built for the resource-heavy web pages of today.

HTTP/1.1 suffers from "Head-of-Line Blocking" — each request on a connection must wait for the previous response before proceeding. Browsers work around this by opening up to six parallel connections per domain, which wastes resources and increases overhead. HTTP/2 solves this with Multiplexing, enabling multiple requests and responses to flow simultaneously over a single connection.

HTTP/2 vs HTTP/1.1: Key Improvements

How HTTP/2 Beats HTTP/1.1: Multiplexing, Header Compression, Server Push

HTTP/2 is faster than HTTP/1.1 not because it adds bandwidth, but because it redesigns how data travels over the wire to eliminate waste. Three changes do most of the heavy lifting — multiplexing, header compression, and stream prioritization — all working together over a single TLS-encrypted connection.

Multiplexing — Many Requests Over One Connection

In HTTP/1.1, a single connection handles one request at a time and must wait for its response before sending the next. This is Head-of-Line Blocking. Browsers work around it by opening up to six parallel connections per domain, each requiring its own TCP and TLS handshake — wasting both time and server memory. HTTP/2 changes the model entirely by splitting data into small "frames" and tying each frame to a numbered "stream." This allows many requests and responses to interleave over one connection simultaneously, then reassemble by stream ID at the destination. The result: pages with dozens of images, CSS, and JavaScript files load far faster, especially on high-latency networks.

Header Compression (HPACK) — Eliminate Repeated Header Overhead

Every HTTP/1.1 request carries a large set of headers — User-Agent, Accept, Cookie — that are nearly identical across every request for the same page. When a page fires dozens of requests, these repeated headers waste bandwidth. HTTP/2 solves this with HPACK, a compression algorithm built specifically for headers. HPACK maintains a dynamic reference table of previously sent headers, so subsequent requests send only an index reference instead of the full text. This dramatically reduces header size on sites with long cookies or many headers, lowering TTFB and speeding up the loading of small sub-resources.

Stream Prioritization and Binary Framing

HTTP/2 uses a binary wire format instead of HTTP/1.1's text format, making it faster and more precise to parse — no more interpreting whitespace or line breaks. It also lets the client assign a priority to each stream, for example telling the browser to load render-critical CSS before below-the-fold images. The server can then allocate bandwidth to important resources first, helping users see main content sooner and improving Core Web Vitals.

Does HTTP/2 Require SSL?

The HTTP/2 specification (RFC 7540) technically supports both cleartext (h2c) and TLS-encrypted (h2) modes. However, every major browser in common use today only supports HTTP/2 over HTTPS (TLS).

In practice, this means if your site still runs on HTTP, you will not benefit from HTTP/2 even if your server supports it. Installing an SSL certificate and switching to HTTPS is the necessary first step before enabling HTTP/2.

Enabling HTTP/2 on Nginx (listen 443 ssl http2)

Nginx has supported HTTP/2 since version 1.9.5. Enabling it is as simple as adding http2 to the listen directive on the server block that listens on port 443. Below is a complete, production-ready config including the HTTP-to-HTTPS redirect and recommended TLS settings:

# /etc/nginx/sites-available/example.com.conf

# HTTP block — redirect everything to HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

# HTTPS block — enable HTTP/2 here
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;       # IPv6
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_session_cache   shared:SSL:10m;
    ssl_session_timeout 1d;

    root /var/www/example.com;
    index index.html index.php;
}

Note: on Nginx versions before 1.25.1 you must add http2 to every listen directive you want it on — both IPv4 and IPv6 — otherwise connections arriving on a listen directive without http2 will only use HTTP/1.1.

Enabling it is as simple as adding http2 to the listen directive:

Method 1 — Add http2 to server block (Nginx 1.9.5–1.25.0)

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    ssl_protocols TLSv1.2 TLSv1.3;
}

Method 2 — New syntax for Nginx 1.25.1+

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;
    # ...
}

nginx -t && systemctl reload nginx

Verify HTTP/2 is active on Nginx

curl -I --http2 https://example.com 2>&1 | grep "HTTP/"
# Expected output: HTTP/2 200

Enabling HTTP/2 on Apache (mod_http2, Protocols h2)

Apache supports HTTP/2 via the mod_http2 module, available since Apache 2.4.17. Enabling it takes three steps: load the module, declare Protocols h2 in the SSL VirtualHost, and verify you are running a compatible MPM (event or worker). The order h2 h2c http/1.1 matters: h2 is HTTP/2 over TLS, h2c is cleartext HTTP/2 (internal use), and http/1.1 is the fallback for older browsers — Apache negotiates the highest protocol both sides support via ALPN during the TLS handshake.

Step 1 — Enable the module

a2enmod http2
systemctl restart apache2

Step 2 — Add the Protocols directive

<VirtualHost *:443>
    ServerName example.com
    Protocols h2 h2c http/1.1
    # ...
</VirtualHost>

Step 3 — Check MPM compatibility

HTTP/2 in Apache requires the event or worker MPM. If you are using prefork (common on older Ubuntu installs), switch to event:

a2dismod mpm_prefork
a2enmod mpm_event
apachectl configtest && systemctl restart apache2

Verify HTTP/2 + What HTTP/3 Is

Once enabled, confirm your site actually responds over HTTP/2, and understand how HTTP/3 — the next version — differs so you can plan a future upgrade.

How to Check Whether Your Site Is Using HTTP/2

• Chrome DevTools — Open Network tab, right-click the header row, enable "Protocol" column. Requests showing "h2" are using HTTP/2.
• curl command — curl -I --http2 https://example.com
• KeyCDN HTTP/2 Test — tools.keycdn.com/http2-test
• SSL Labs — The SSL report indicates whether the server supports HTTP/2.

What HTTP/3 Is and How It Differs from HTTP/2

HTTP/3 is the latest version of the HTTP protocol, designed to fix the weaknesses HTTP/2 still carries. The most important difference is the transport layer: HTTP/2 runs on TCP, while HTTP/3 runs on QUIC, which is built on top of UDP. The problem with HTTP/2 over TCP is that even though it multiplexes many streams over one connection, if a single packet from any stream is lost, TCP halts delivery of every stream until that packet is retransmitted. This is TCP-level Head-of-Line Blocking, and it is most visible on mobile or Wi-Fi networks with high packet loss.

QUIC in HTTP/3 manages each stream independently — if one stream's packet is lost, the others keep flowing without waiting. QUIC also merges the TLS 1.3 handshake with the connection handshake for faster setup (0-RTT/1-RTT) and supports connection migration, letting a client switch networks (for example Wi-Fi to 4G) without rebuilding the whole connection. Like HTTP/2, HTTP/3 always requires TLS and is served over UDP port 443.

The practical recommendation is to enable HTTP/2 as your baseline first — it has broad support and is simple to configure. Once your server and CDN support QUIC, add HTTP/3 as an additional layer so capable browsers benefit, while browsers that do not support it automatically fall back to HTTP/2.

HTTP/2 Server Push

Server Push allows the server to proactively send resources (CSS, JS, fonts) before the browser requests them, reducing additional round-trips:

# Nginx — push CSS and JS along with HTML
server {
    location = /index.html {
        http2_push /css/style.css;
        http2_push /js/main.js;
    }
}

In practice, Server Push is less valuable than it sounds because browsers already cache resources. Enabling basic HTTP/2 Multiplexing alone delivers the most significant performance gains for the majority of sites.

HTTP/2 and SEO

Google uses Core Web Vitals (LCP, INP, CLS) as ranking factors, and HTTP/2 directly improves these metrics by:

• Reducing Time to First Byte (TTFB) via header compression and connection reuse
• Loading CSS, JS, and fonts faster in parallel, improving LCP
• Reducing overall connection overhead for resource-rich pages

Frequently Asked Questions

How is HTTP/3 different from HTTP/2?

HTTP/3 uses the QUIC protocol (built on UDP instead of TCP), further reducing connection latency — especially on unstable networks. Most modern browsers support HTTP/3, but server-side support is less widespread than HTTP/2. HTTP/2 remains the practical standard for most deployments.

Does AsiaGB Hosting support HTTP/2?

Yes. AsiaGB Hosting supports HTTP/2 once an SSL certificate is installed. Every AsiaGB Hosting package includes a free Let's Encrypt certificate via DirectAdmin, so HTTP/2 is available to all customers.

Can HTTP/2 ever be slower than HTTP/1.1?

On extremely simple pages with very few resources (a single HTML file with no CSS or JS), the difference is negligible. For typical pages with dozens of assets, HTTP/2 is consistently faster than HTTP/1.1.

Do I need to change my website code to enable HTTP/2?

No code changes are required. HTTP/2 operates at the transport protocol level and is completely transparent to your HTML, CSS, and JavaScript — existing web apps work immediately. That said, some HTTP/1.1-era optimizations may no longer be necessary, such as concatenating CSS/JS into single files or using image sprites, because multiplexing already handles many files efficiently. Splitting files logically is actually better for caching. But these are refinements, not requirements.

If my site is behind Cloudflare or a CDN, do I need HTTP/2 on the server?

If your site is served through Cloudflare or another CDN in proxy mode, visitors connect to the CDN edge rather than your origin server directly. So HTTP/2 (and HTTP/3) between users and the site is usually enabled automatically at the CDN edge. The connection between the CDN and your origin uses whatever protocol the origin supports, so enabling HTTP/2 on the origin is still useful — but visitors already get HTTP/2 from the edge.

Can I use Let's Encrypt with HTTP/2?

Yes. HTTP/2 only needs a valid SSL certificate and does not care which authority issued it. Let's Encrypt — a free DV certificate — enables HTTP/2 exactly like a paid certificate. The difference between DV, OV, and EV certificates is the level of identity validation, not HTTP/2 support.