HTTP/2 คืออะไร ต้องใช้ SSL ไหม เปิดใช้บน Nginx และ Apache อย่างไร

HTTP/2 คืออะไร

HTTP/2 คือเวอร์ชันที่สองของโปรโตคอล HTTP (HyperText Transfer Protocol) ที่ใช้รับส่งข้อมูลระหว่างเบราว์เซอร์และเซิร์ฟเวอร์ ถูกกำหนดมาตรฐานโดย IETF ในปี 2015 (RFC 7540) และออกแบบมาเพื่อแก้ปัญหาประสิทธิภาพของ HTTP/1.1 ที่ใช้มาตั้งแต่ปี 1997

HTTP/1.1 มีข้อจำกัดสำคัญคือ "Head-of-Line Blocking" — การที่ request หนึ่งต้องรอ response ของ request ก่อนหน้าให้เสร็จก่อน ทำให้เบราว์เซอร์ต้องเปิด connection หลายตัวพร้อมกัน (โดยทั่วไปสูงสุด 6 connections ต่อ domain) ซึ่งสิ้นเปลือง resource HTTP/2 แก้ปัญหานี้ด้วยเทคนิค Multiplexing ซึ่งส่งได้หลาย request พร้อมกันใน connection เดียว

ข้อดีหลักของ HTTP/2 เทียบกับ HTTP/1.1

HTTP/2 ดีกว่า HTTP/1.1 อย่างไร (multiplexing, header compression, server push)

สาเหตุที่ HTTP/2 เร็วกว่า HTTP/1.1 อย่างชัดเจนไม่ได้มาจากการเพิ่มแบนด์วิดท์ แต่มาจากการออกแบบโปรโตคอลใหม่ที่ลดความสูญเปล่าในการรับส่งข้อมูล จุดเปลี่ยนสำคัญมีอยู่สามเรื่องหลัก คือ multiplexing, header compression และ stream prioritization ซึ่งทำงานร่วมกันบน connection เดียวที่เข้ารหัสด้วย TLS

Multiplexing — รับส่งหลาย request พร้อมกันใน connection เดียว

ใน HTTP/1.1 หนึ่ง connection ส่งได้ทีละ request และต้องรอ response กลับมาก่อนจึงจะส่ง request ถัดไปได้ ปัญหานี้เรียกว่า Head-of-Line Blocking เบราว์เซอร์จึงต้องเปิด connection พร้อมกันสูงสุดราว 6 ตัวต่อ domain เพื่อโหลดทรัพยากรหลายชิ้นพร้อมกัน แต่ละ connection ต้องทำ TCP handshake และ TLS handshake ของตัวเอง สิ้นเปลืองทั้งเวลาและหน่วยความจำของเซิร์ฟเวอร์ HTTP/2 เปลี่ยนวิธีคิดทั้งหมดด้วยการแบ่งข้อมูลเป็น "frame" เล็กๆ แล้วผูกแต่ละ frame เข้ากับ "stream" ที่มีหมายเลขกำกับ ทำให้ส่ง request และ response หลายชิ้นสลับกันไปมาบน connection เดียวได้พร้อมกัน เมื่อข้อมูลถึงปลายทางจึงประกอบกลับตามหมายเลข stream ผลคือหน้าเว็บที่มีรูป CSS และ JavaScript หลายสิบไฟล์โหลดเสร็จเร็วขึ้นมาก โดยเฉพาะบนเครือข่ายที่ latency สูง

Header Compression (HPACK) — ลด overhead ของ header ที่ส่งซ้ำ

ทุก request ใน HTTP/1.1 จะแนบ header จำนวนมากไปด้วยทุกครั้ง เช่น User-Agent, Accept, Cookie ซึ่งมักมีค่าเหมือนเดิมแทบทั้งหมดในทุก request ของหน้าเดียวกัน เมื่อหน้าเว็บหนึ่งยิงไปหลายสิบ request header ที่ซ้ำกันเหล่านี้กินแบนด์วิดท์โดยเปล่าประโยชน์ HTTP/2 แก้ด้วย HPACK ซึ่งเป็นอัลกอริทึมบีบอัด header โดยเฉพาะ HPACK เก็บตารางอ้างอิง (dynamic table) ของ header ที่เคยส่งไปแล้ว ครั้งต่อไปจึงส่งเพียง index อ้างอิงแทนที่จะส่งข้อความเต็ม ลดขนาด header ลงได้มากในเว็บที่มี cookie ยาวหรือ header เยอะ ช่วยลด TTFB และทำให้การโหลดทรัพยากรย่อยๆ เร็วขึ้นตามไปด้วย

Stream Prioritization และ Binary Framing

HTTP/2 ใช้รูปแบบ binary ในการรับส่งข้อมูลแทน text ของ HTTP/1.1 ทำให้ parse ได้เร็วและแม่นยำกว่า ไม่ต้องตีความ whitespace หรือบรรทัดเหมือนเดิม นอกจากนี้ยังกำหนดลำดับความสำคัญ (priority) ให้แต่ละ stream ได้ เช่น บอกเบราว์เซอร์ให้โหลด CSS ที่จำเป็นต่อการ render ก่อนรูปภาพด้านล่างของหน้า เซิร์ฟเวอร์จึงจัดสรรแบนด์วิดท์ให้ทรัพยากรสำคัญก่อน ช่วยให้ผู้ใช้เห็นเนื้อหาหลักเร็วขึ้นและ Core Web Vitals ดีขึ้น

HTTP/2 ต้องใช้ SSL ไหม?

ในเชิงมาตรฐาน RFC 7540 รองรับ HTTP/2 ทั้งแบบ cleartext (h2c) และแบบ TLS (h2) แต่ในทางปฏิบัติ เบราว์เซอร์ทุกตัวที่ใช้งานทั่วไปในปัจจุบัน รองรับ HTTP/2 เฉพาะเมื่อใช้งานผ่าน HTTPS เท่านั้น

นั่นหมายความว่าถ้าเว็บไซต์ของคุณยังใช้ HTTP อยู่ คุณจะไม่ได้รับประโยชน์จาก HTTP/2 แม้เซิร์ฟเวอร์จะรองรับก็ตาม การอัปเกรดเป็น HTTPS ด้วย SSL Certificate จึงเป็นขั้นตอนแรกที่จำเป็นก่อนเปิดใช้ HTTP/2

เปิด HTTP/2 บน Nginx (listen 443 ssl http2)

Nginx รองรับ HTTP/2 ตั้งแต่เวอร์ชัน 1.9.5 การเปิดใช้งานง่ายมาก เพียงเพิ่ม http2 ใน listen directive ของ server block ที่ฟังพอร์ต 443 ด้านล่างเป็นตัวอย่าง config เต็มที่พร้อมใช้งานจริง รวมการ redirect HTTP ไป HTTPS และค่า TLS ที่แนะนำ:

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

# บล็อก HTTP — redirect ทุกอย่างไป HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

# บล็อก HTTPS — เปิด HTTP/2 ที่นี่
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;
}

หมายเหตุ: ใน Nginx รุ่นก่อน 1.25.1 ต้องใส่ http2 ในทุก listen directive ที่ต้องการให้รองรับ ทั้ง IPv4 และ IPv6 มิฉะนั้น connection ที่เข้ามาทาง listen ที่ไม่ได้ระบุ http2 จะใช้แค่ HTTP/1.1

Nginx รองรับ HTTP/2 ตั้งแต่เวอร์ชัน 1.9.5 การเปิดใช้งานง่ายมาก เพียงเพิ่ม http2 ใน listen directive:

วิธีที่ 1 — เพิ่ม http2 ใน server block (Nginx 1.9.5+)

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;

    # ... โค้ดเว็บไซต์อื่นๆ ...
}

สำหรับ Nginx 1.25.1+ (วิธีใหม่)

ตั้งแต่ Nginx 1.25.1 syntax เปลี่ยนเป็น http2 on; directive แยก:

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

nginx -t && systemctl reload nginx

ตรวจสอบว่า HTTP/2 ทำงานบน Nginx

curl -I --http2 https://example.com 2>&1 | grep "HTTP/"
# ควรเห็น: HTTP/2 200

เปิด HTTP/2 บน Apache (mod_http2, Protocols h2)

Apache รองรับ HTTP/2 ผ่าน module mod_http2 ซึ่งมาพร้อม Apache 2.4.17 ขึ้นไป การเปิดใช้ต้องทำสามขั้นตอน คือ โหลด module, ประกาศ Protocols h2 ใน VirtualHost ที่ใช้ SSL และตรวจสอบว่าใช้ MPM ที่รองรับ (event หรือ worker) ลำดับ h2 h2c http/1.1 มีความหมาย: h2 คือ HTTP/2 over TLS, h2c คือ HTTP/2 แบบไม่เข้ารหัส (ใช้ภายใน) และ http/1.1 คือ fallback สำหรับเบราว์เซอร์เก่า — Apache จะเลือกโปรโตคอลสูงสุดที่ทั้งสองฝั่งรองรับผ่าน ALPN ระหว่าง TLS handshake

ขั้นตอนที่ 1 — เปิดใช้ module

a2enmod http2
systemctl restart apache2

ขั้นตอนที่ 2 — เพิ่ม Protocols directive

เพิ่มในไฟล์ VirtualHost หรือ /etc/apache2/conf-enabled/http2.conf:

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

# หรือตั้งระดับ Global ใน apache2.conf
Protocols h2 h2c http/1.1

ขั้นตอนที่ 3 — ตรวจสอบ MPM

HTTP/2 ใน Apache ต้องการ MPM event หรือ worker ถ้าใช้ prefork อยู่ต้องเปลี่ยน:

a2dismod mpm_prefork
a2enmod mpm_event
apachectl configtest && systemctl restart apache2

ตรวจสอบว่า HTTP/2 ทำงานบน Apache

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

ตรวจสอบ HTTP/2 + HTTP/3 คืออะไร

หลังเปิดใช้งานแล้ว ควรยืนยันว่าเว็บตอบกลับเป็น HTTP/2 จริง และทำความเข้าใจว่า HTTP/3 ซึ่งเป็นเวอร์ชันถัดไปต่างจาก HTTP/2 อย่างไร เพื่อวางแผนอัปเกรดในอนาคต

วิธีตรวจสอบว่าเว็บของคุณใช้ HTTP/2 แล้วหรือยัง

มีหลายวิธีในการตรวจสอบ:

• Chrome DevTools — เปิด Network tab แล้วดูคอลัมน์ "Protocol" ถ้าเห็น "h2" แสดงว่าใช้ HTTP/2 แล้ว (ถ้าคอลัมน์ไม่ปรากฏให้คลิกขวาที่ header row แล้ว enable "Protocol")
• curl command — curl -I --http2 https://example.com ดู response version
• KeyCDN HTTP/2 Test — เว็บ tools.keycdn.com/http2-test ตรวจสอบได้ง่าย
• SSL Labs — รายงาน SSL ระบุว่า server support HTTP/2 หรือไม่

HTTP/3 คืออะไร และต่างจาก HTTP/2 อย่างไร

HTTP/3 เป็นเวอร์ชันล่าสุดของโปรโตคอล HTTP ที่ออกแบบมาเพื่อแก้จุดอ่อนที่ HTTP/2 ยังเหลืออยู่ จุดต่างสำคัญที่สุดคือ HTTP/2 ทำงานบน TCP ส่วน HTTP/3 ทำงานบน QUIC ซึ่งสร้างทับ UDP อีกที ปัญหาของ HTTP/2 บน TCP คือถึงจะมี multiplexing หลาย stream บน connection เดียว แต่ถ้า packet ของ stream ใด stream หนึ่งหายไป TCP จะหยุดส่งมอบข้อมูลของทุก stream จนกว่า packet นั้นจะถูกส่งซ้ำสำเร็จ ปรากฏการณ์นี้เรียกว่า TCP-level Head-of-Line Blocking ซึ่งเห็นผลชัดบนเครือข่ายมือถือหรือ Wi-Fi ที่ packet loss สูง

QUIC ใน HTTP/3 จัดการ stream แต่ละตัวแยกอิสระ ถ้า packet ของ stream หนึ่งหาย stream อื่นยังเดินหน้าต่อได้โดยไม่ต้องรอ นอกจากนี้ QUIC ยังรวม TLS 1.3 handshake เข้ากับ connection handshake ทำให้เปิด connection ได้เร็วขึ้น (0-RTT/1-RTT) และรองรับ connection migration คือเปลี่ยนเครือข่าย เช่น จาก Wi-Fi ไป 4G โดยไม่ต้องสร้าง connection ใหม่ทั้งหมด HTTP/3 ต้องใช้ TLS เสมอเช่นเดียวกับ HTTP/2 และให้บริการผ่าน UDP พอร์ต 443

คำแนะนำในทางปฏิบัติคือ ให้เปิด HTTP/2 เป็นมาตรฐานก่อนเพราะรองรับกว้างและตั้งค่าง่าย เมื่อเซิร์ฟเวอร์และ CDN ของคุณรองรับ QUIC แล้วจึงค่อยเปิด HTTP/3 เพิ่มเป็นชั้นบนเพื่อให้เบราว์เซอร์ที่รองรับได้ประโยชน์ ส่วนเบราว์เซอร์ที่ยังไม่รองรับก็ fallback กลับมาที่ HTTP/2 ได้อัตโนมัติ

HTTP/2 Server Push — ใช้แบบนี้

Server Push คือ feature ที่ server ส่ง resource (CSS, JS, font) ไปให้เบราว์เซอร์ก่อนที่เบราว์เซอร์จะขอ ลดรอบ request เพิ่มเติม:

# Nginx — push CSS และ JS หลักพร้อมกับ HTML
server {
    location = /index.html {
        http2_push /css/style.css;
        http2_push /js/main.js;
    }
}

ในทางปฏิบัติ Server Push มีประโยชน์จำกัดเพราะเบราว์เซอร์มี cache อยู่แล้ว การ push resource ซ้ำอาจเสียแบนด์วิดท์ โดยทั่วไปให้เปิด HTTP/2 แบบพื้นฐาน (Multiplexing) ก็ได้ประโยชน์มากพอแล้ว

HTTP/2 ส่งผลต่อ SEO อย่างไร

Google ใช้ Core Web Vitals (LCP, FID/INP, CLS) เป็น ranking factor ซึ่ง HTTP/2 ช่วยได้โดยตรงผ่าน:

• ลด Time to First Byte (TTFB) จาก header compression และ multiplexing
• โหลด CSS/JS/font พร้อมกันได้เร็วขึ้น ส่งผลต่อ LCP
• ลด connection overhead ทำให้ทรัพยากรทั้งหน้าโหลดเร็วกว่า HTTP/1.1

คำถามที่พบบ่อย (FAQ)

HTTP/3 แตกต่างจาก HTTP/2 อย่างไร

HTTP/3 ใช้ QUIC protocol (ทำงานบน UDP) แทน TCP ช่วยลด connection latency เพิ่มเติม โดยเฉพาะในสภาพ network ที่ไม่เสถียร เบราว์เซอร์ส่วนใหญ่รองรับแล้ว แต่ต้องการ server ที่รองรับ QUIC ซึ่งยังไม่แพร่หลายเท่า HTTP/2

Hosting ของ AsiaGB รองรับ HTTP/2 ไหม?

Hosting ของ AsiaGB รองรับ HTTP/2 เมื่อมีการติดตั้ง SSL Certificate แล้ว ซึ่งทุกแพ็กเกจ Hosting ของ AsiaGB มี Let's Encrypt ให้ฟรีผ่าน DirectAdmin อยู่แล้ว

HTTP/2 ช้ากว่า HTTP/1.1 ได้ไหม?

ในบางสถานการณ์ที่หน้าเว็บมีทรัพยากรน้อยมาก (เช่น เว็บ 1 ไฟล์ HTML ไม่มี CSS/JS เลย) ความแตกต่างอาจเล็กน้อย แต่สำหรับเว็บทั่วไปที่มี resource หลายสิบรายการ HTTP/2 จะเร็วกว่า HTTP/1.1 เสมอ

เปิด HTTP/2 แล้วต้องเปลี่ยนโค้ดเว็บไซต์ไหม?

ไม่ต้องเปลี่ยนโค้ดเว็บไซต์เลย HTTP/2 ทำงานในระดับโปรโตคอลการรับส่งข้อมูล โปร่งใสต่อ HTML/CSS/JavaScript ของคุณทั้งหมด เว็บแอปเดิมใช้งานได้ทันที อย่างไรก็ตามเทคนิคปรับแต่งสมัย HTTP/1.1 บางอย่างอาจไม่จำเป็นอีกต่อไป เช่น การรวมไฟล์ CSS/JS เป็นไฟล์เดียว (concatenation) หรือ image sprite เพราะ multiplexing จัดการหลายไฟล์ได้มีประสิทธิภาพอยู่แล้ว การแยกไฟล์ตามตรรกะจึงดีต่อ cache มากกว่า แต่ทั้งหมดนี้เป็นการปรับให้เหมาะ ไม่ใช่สิ่งบังคับ

ถ้าเว็บอยู่หลัง Cloudflare หรือ CDN ต้องตั้งค่า HTTP/2 ที่เซิร์ฟเวอร์ไหม?

ถ้าเว็บของคุณเปิดผ่าน Cloudflare หรือ CDN อื่นในโหมด proxy เบราว์เซอร์ของผู้เข้าชมจะเชื่อมต่อกับ edge ของ CDN ไม่ใช่เซิร์ฟเวอร์ต้นทางโดยตรง ดังนั้น HTTP/2 (และ HTTP/3) ระหว่างผู้ใช้กับเว็บมักเปิดที่ฝั่ง CDN ให้อัตโนมัติอยู่แล้ว ส่วน connection ระหว่าง CDN กับเซิร์ฟเวอร์ต้นทาง (origin) จะใช้โปรโตคอลตามที่ origin รองรับ การเปิด HTTP/2 ที่ origin จึงยังมีประโยชน์ แต่ผู้เข้าชมจะได้ HTTP/2 จาก edge ก่อนแล้ว

Let's Encrypt ใช้กับ HTTP/2 ได้ไหม?

ได้ เพราะ HTTP/2 ต้องการเพียง SSL Certificate ที่ใช้งานได้ ไม่ได้สนใจว่าใบรับรองมาจากผู้ออกใบรับรองรายใด Let's Encrypt ซึ่งเป็น Certificate แบบ DV ที่ออกฟรี ใช้เปิด HTTP/2 ได้เหมือนใบรับรองแบบเสียเงิน ความต่างของใบรับรองแบบ DV/OV/EV อยู่ที่ระดับการตรวจสอบตัวตนของผู้ถือ ไม่ได้เกี่ยวกับการรองรับ HTTP/2