Apache HTTP Server #2 - Module: Bí mật giúp Apache tồn tại hơn 30 năm mà không cần viết lại từ đầu

1 tháng 8, 2026 • Web Infrastructure • 3 phút đọc
Related
Distributed Systems
This article is part of
Apache HTTP Server
  1. Apache HTTP Server #1 - Virtual Host: Làm sao một server có thể host hàng nghìn website?
  2. Apache HTTP Server #2 - Module: Bí mật giúp Apache tồn tại hơn 30 năm mà không cần viết lại từ đầu

Nếu Virtual Host trả lời câu hỏi:

“Request này thuộc về website nào?”

thì mình lại nảy ra một câu hỏi khác.

Apache làm sao có thể vừa làm Web Server, vừa hỗ trợ HTTPS, vừa Reverse Proxy, vừa URL Rewrite, vừa nén GZIP… mà không biến thành một mớ code khổng lồ?

Câu trả lời là Module.

Nếu từng cài Apache trên Linux, có thể bạn sẽ bắt gặp những cái tên như:

mod_ssl
mod_rewrite
mod_headers
mod_proxy
mod_deflate
mod_cache

Ban đầu mình cứ nghĩ đây chỉ là các thư viện đi kèm.

Nhưng thực ra chúng chính là lý do Apache có thể tồn tại và phát triển suốt hàng chục năm.

Apache gần như chỉ là một “bộ khung”

Thay vì nhồi tất cả tính năng vào một chương trình duy nhất, Apache được thiết kế theo kiểu:

                Apache HTTP Server
                       │
     ┌─────────────────┼─────────────────┐
     │                 │                 │
     ▼                 ▼                 ▼
 mod_ssl         mod_rewrite      mod_proxy
     │                 │                 │
 HTTPS          URL Rewrite     Reverse Proxy

Mỗi module chỉ giải quyết một nhiệm vụ.

Muốn website hỗ trợ HTTPS?

↓

Nạp mod_ssl.

Muốn rewrite URL?

↓

Nạp mod_rewrite.

Muốn Apache làm Reverse Proxy cho Spring Boot hay Node.js?

↓

Nạp mod_proxy.

Apache không cần biết chi tiết từng tính năng hoạt động ra sao, nó chỉ cần gọi đúng module khi cần.

Một request thực sự đi qua những module nào?

Giả sử bạn truy cập:

https://example.com/products/15

Request có thể được xử lý theo thứ tự như sau:

Browser
      │
      ▼
Apache
      │
      ▼
mod_ssl
(Giải mã TLS)
      │
      ▼
mod_rewrite
(Kiểm tra rule)
      │
      ▼
mod_headers
(Thêm security headers)
      │
      ▼
mod_deflate
(Nén response)
      │
      ▼
Laravel / PHP

Điều này cũng có nghĩa là mỗi module chỉ quan tâm đến đúng phần việc của mình.

Vậy .htaccess liên quan gì đến Module?

Đây là lúc mọi thứ bắt đầu kết nối lại với nhau.

Hồi deploy website PHP lên Hostinger, mình thường thấy:

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Mình cứ nghĩ:

Đây là cú pháp của Apache.

Không hẳn.

Đây là cú pháp của mod_rewrite.

Nếu module này không được bật, Apache sẽ báo lỗi vì hoàn toàn không hiểu:

RewriteEngine
RewriteCond
RewriteRule

Tương tự,

AddOutputFilterByType DEFLATE text/html

lại thuộc về mod_deflate.

Hay:

Header always set X-Frame-Options SAMEORIGIN

là của mod_headers.

Nói cách khác, .htaccess không phải là một ngôn ngữ duy nhất.

Nó là nơi nhiều module khác nhau cùng khai báo cấu hình của mình.

Vì sao thiết kế này lại quan trọng?

Hãy tưởng tượng nếu Apache nhúng toàn bộ tính năng vào lõi.

Muốn sửa chức năng nén GZIP?

↓

Phải sửa cả Apache.

Muốn bổ sung Reverse Proxy?

↓

Lại sửa Apache.

Muốn thêm HTTP/2?

↓

Tiếp tục sửa Apache.

Sau vài chục năm, code sẽ trở thành cơn ác mộng.

Module giải quyết vấn đề đó bằng cách tách từng tính năng thành các khối độc lập.

Mỗi nhóm phát triển có thể tập trung vào module của mình mà không ảnh hưởng quá nhiều đến phần còn lại của hệ thống.

Mình bắt đầu hiểu vì sao Apache từng thống trị Internet

Trước đây mình chỉ nghĩ Apache nổi tiếng vì nó là web server đầu tiên.

Nhưng đọc sâu hơn mới thấy điều đáng học nhất lại là kiến trúc của nó.

Apache không cố gắng làm mọi thứ trong một khối duy nhất.

Nó xây dựng một nền tảng có thể mở rộng bằng Module.

Có lẽ đó cũng là lý do sau hơn 30 năm, rất nhiều module như mod_ssl, mod_rewrite, mod_proxy… vẫn được sử dụng trên hàng triệu website.