SO SÁNH KIẾN TRÚC APACHE – NGINX – CADDY

---

Thông tin metadata

• Người thực hiện: [NGUYỄN PHẠM TUYÊN]
• Thời gian thực hiện: [05/12/2025]
• Người hướng dẫn hoặc cộng tác: [Tech Lead Trần Thanh Vượt]

---

1. Mục đích của nghiên cứu

• Mục đích: Giới thiệu về Caddy, Apache, Nginx
• Kiến trúc của Caddy
• Kiến trúc của Apache
• Kiến trúc của Nginx
• Kết quả mong đợi: Hiểu rõ kiến trúc Nginx, Apache và Caddy khác gì nhau để đưa ra lựa chọn phù hợp cho dự án.

---

2. Tổng quan

Giới thiệu về Nginx

Nginx là một web server được phát hành vào năm 2004 bởi Igor Sysoev, ngày nay nó được phát triển còn hơn cả là một web server. Khởi điểm, nginx được sử dụng như là một phần bổ sung của apache. Nó thường được sử dụng để xử lý các file tĩnh (static file), ngày nay, nó đã được phát triển một cách hoàn thiện các tác vụ mà một web server cần thực hiện. Ngoài ra, nginx còn được sử dụng để làm reverse proxy, load balancer, mail proxy và HTTP caching.

Giới thiệu về Caddy Server

Caddy Server là một web server mã nguồn mở hiện đại được phát triển bằng ngôn ngữ Go, tận dụng khả năng xử lý song song (concurrency) và hiệu năng cao vốn có của Go. Ra mắt lần đầu vào năm 2015. Điểm nổi bật của Caddy là tự động cấp và gia hạn SSL/TLS qua Let’s Encrypt, giúp HTTPS hoạt động ngay khi cài đặt mà không cần cấu hình phức tạp như Nginx hay Apache. Caddy còn hỗ trợ HSTS, chống DDoS, kiểm soát truy cập, đồng thời tích hợp sẵn HTTP/2 và HTTP/3 (QUIC), cải thiện tốc độ, giảm độ trễ và nâng cao bảo mật mà không cần thêm mô-đun hay cấu hình đặc biệt.

Giới thiệu về Apache (Apache HTTP Server)

Apache HTTP Server là một web server mã nguồn mở đa nền tảng được quản lý bởi Apache Software Foundation ra đời năm 1995, và được phát triển, maintained bởi cộng đồng mở lập trình viên dưới ASF. Nó còn được biết đến với tên gọi Httpd hay Apache. Thường được triển khai trên hệ điều hành linux, apache được sử dụng để triển khai đến 46% trang web trên toàn thế giới. Ngoài ra, nó còn là thành phần quan trọng của LAMP Stack bao gồm Linux, Apache, PHP, MySql.

---

3. Kiến trúc

Khi nói đến Nginx, Caddy và Apache, sự khác biệt cơ bản giữa cả 3 là về thiết kế kiến trúc của chúng. Nghĩa là chúng khác nhau về cách xử lý kết nối (connections), lưu lượng truy cập (traffic), cách chúng phản ứng (respond) với các điều kiện lưu lượng khác nhau (traffic conditions).

Apache tiếp cận theo phương hướng process-driven approach tạo ra một thread mới cho mỗi request, khiến nó tốn tài nguyên khi lưu lượng cao. Nginx và Caddy thì lại theo hướng event-driven architecture cho phép xử lý nhiều request với chỉ một thread, tiết kiệm tài nguyên và tối ưu hiệu suất. Caddy, đặc biệt, sử dụng goroutinecủa Go, giúp xử lý đồng thời cực kỳ hiệu quả và dễ mở rộng hơn Nginx.

Cùng đi qua 1 số khái niệm:

• Tiến trình (process): có thể hiểu đơn giản là một chương trình đang chạy trong máy tính. Mỗi tiến trình sẽ có một luồng chính (main thread) để chạy chương trình và được hệ điều hành cấp pháp cho một không gian bộ nhớ nhất định. Khi main thread ngừng hoạt động đồng nghĩa với việc chương trình bị tắt.
• Thread: hay còn gọi là “luồng” hoặc còn được gọi là tiểu trình là một luồng trong tiến trình đang chạy, đơn vị nhỏ nhất của CPU để thực thi chương trình. Một chương trình chạy có thể có nhiều thread, Cho phép chương trình đó chạy trên nhiều luồng một cách “đồng thời”. Những thread sẽ được cấp pháp riêng một vùng nhớ stack để lưu trữ biến riêng của thread đó.

• Trong multi-threading có tồn tại 2 khái niệm là Concurrency (đồng thời) và Parallelism (song song). Mới đầu thì nghĩ chúng có vẻ giống nhau, nhưng chúng không phải là một.
  • Concurrency nghĩa là những tác vụ có thể bắt đầu, chạy, và hoàn thành trong những khoảng thời gian chống chéo lên nhau mà không theo thứ tự nào cả. Ví dụ: chạy trên 1 core processor. Còn Parallelism là nhiều tác vụ hoặc một phần của tác vụ chạy đồng thời tại cùng một thời điểm. Ví dụ: chạy trên multi-core processors.

• Tìm hiểu sâu về Goroutine với Thread:
  • Thread sẽ có một kích thước vùng nhớ stack cố định. Vùng nhớ này chủ yếu được sử dụng để lưu trữ những tham số, biến cục bộ và địa chỉ trả về khi chúng ta gọi hàm. Chính vì kích thước cố định của stack nên dẫn đến hai vấn đề:
    • Gặp hiện tượng stack overflow với những chương trình gọi hàm đệ quy sâu.
    • Lãng phí vùng nhớ đối với chương trình đơn giản.
  • Với Goroutines thì vẫn đề này đã được khắc phục bằng cách cấp pháp linh hoạt vùng nhớ stack:
    • Goroutines có kích thước nhỏ hơn rất đáng kể so với Thread. Mỗi goroutine = một “task”, sử dụng 2KB memory stack(mở rộng dần), trong khi đó các OS Thread lên đến 2MB. Một Goroutines sẽ được bắt đầu bằng một vùng nhớ nhỏ.
    • Goroutines có thể linh động tăng giảm bộ nhớ sử dụng trong khi đó OS Thread là cố định.
    • Một chương trình Golang có thể có hàng trăm nghìn Goroutine trong khi Thread chỉ được vài trăm đến hàng nghìn. Do chi phí việc khởi tạo nhỏ nên ta có thể dễ dàng giải phóng hàng ngàn Goroutines.
    • Goroutines có thời gian khởi động nhanh hơn Thread.
    • Goroutines có thể giao tiếp an toàn với nhau thông qua các kênh trong Golang (Channel). Các channel hỗ trợ mutex lock (là một cơ chế đồng bộ hóa dùng để đảm bảo rằng chỉ có một goroutine hoặc thread được phép truy cập vào một vùng dữ liệu dùng chung tại một thời điểm) vì thế tránh được các lỗi liên quan tới cùng ghi và đọc lên vùng dữ liệu chia sẻ (data race).
    • Goroutines có thể được ánh xạ và hoạt động trên nhiều OS threads thay vì là ánh xạ 1:1.
  • Trong Java thì các thread được quản lý bởi hệ điều hành nên chương trình đang xử lý đồng thời bị phụ thuộc vào hệ điều hành. Còn Golang sử dụng Go runtime có cơ chế riêng cho Goroutines, nó dùng một số kỹ thuật ghép các Goroutines với các thread của hệ điều hành.

Thread	Goroutines
Được quản lý bởi hệ điều hành và thuộc vào số nhân CPU	Được quản lý bởi Go runtime và không phụ thuộc vào số nhân CPU
Có kích cỡ vùng nhớ stack cố định	Có kích cỡ vùng nhớ stack linh hoạt (tự mở rộng/thu nhỏ)
Giao tiếp giữa các thread khó, độ trễ lớn	Giao tiếp qua channels với độ trễ thấp
Có định danh (ID)	Không có định danh trực tiếp
Khởi tạo và giải phóng tốn nhiều thời gian	Khởi tạo và giải phóng rất nhanh nhờ Go runtime

• Process-driven architecture (Kiến trúc dựa trên tiến trình)
  • Khái niệm:
    • Mỗi request (yêu cầu từ client) được xử lý bởi một process hoặc một thread riêng.
    • Nghĩa là server sẽ tạo một bản sao xử lý riêng biệt cho mỗi kết nối đến.
  • Cách hoạt động (simplified):
    Client 1 ---> Process 1 xử lý Client 2 ---> Process 2 xử lý Client 3 ---> Process 3 xử lý
  • Đặc điểm:
    • Ưu điểm:
      • Dễ hiểu, dễ lập trình.
      • Nếu một process crash, các process khác vẫn chạy bình thường.
    • Nhược điểm:
      • Tốn nhiều tài nguyên (RAM, CPU) khi có nhiều request.
      • Không hiệu quả với hàng ngàn kết nối đồng thời.
  • Ví dụ điển hình:
    • Apache (trong chế độ prefork hoặc worker).
    • Mỗi request HTTP sẽ được gán cho một process/thread riêng.
• Event-driven architecture (Kiến trúc dựa trên sự kiện)
  • Khái niệm:
    • Server không tạo process mới cho mỗi request.
    • Thay vào đó, server có một hoặc vài worker và một event loop (vòng lặp sự kiện) để xử lý nhiều request cùng lúc.
    • Khi một request cần chờ IO (disk, network), server không block, mà chuyển sang xử lý request khác.
  • Cách hoạt động (simplified):
    Worker 1 (event loop) ├── Xử lý Client 1 ├── Xử lý Client 2 └── Xử lý Client 3
  • Nhiều kết nối được xử lý song song trong cùng một process/thread nhờ non-blocking IO và event loop.
  • Đặc điểm:
    • Ưu điểm:
      • Tốn ít tài nguyên, xử lý hàng ngàn request đồng thời rất hiệu quả.
      • Phù hợp cho static files, reverse proxy, API server.
    • Nhược điểm:
      • Lập trình phức tạp hơn.
      • Nếu một task block (ví dụ tính toán nặng), sẽ làm chậm toàn bộ worker.
  • Ví dụ điển hình: Nginx, Caddy (dùng goroutines thay cho event loop truyền thống), Node.js.

Apache

Apache tiếp cận theo hướng multi-threaded. Nó cung cấp một bộ các modules xử lý rất đa dạng. Các modules này về cơ bản bao gồm 3 loại thuật toán xử lý request. Mỗi cái sẽ đáp ứng nhu cầu của các máy chủ (server) khác nhau.

MPMs (Multi-Processing Modules) cung cấp một kiến trúc linh hoạt để lựa chọn các kết nỗi khác nhau và các thuật toán xử lý khác nhau. MPMs gồm 3 loại chính là:

• Process (Pre-fork) MPM (cũ nhất process-per-connection)
  • Mỗi request => 1 process riêng
  • Mỗi process có không gian bộ nhớ riêng
  • Hoàn toàn blocking
• Worker MPM (thread-per-connection)
  • Mỗi request => một thread trong cùng process
  • Blocking I/O
  • Tốn RAM hơn Nginx/Caddy do thread stack lớn
• Event MPM (hiện đại nhất)
  • Có tính event-driven cho keep-alive
  • Nhưng thực chất vẫn thread-per-request để xử lý nội dung
  • Chỉ phần idle/keep-alive được event hóa
  • VÍ dụ: Event MPM giống như quán tư vấn có lễ tân (event loop) và tư vấn viên (thread):
    • Khách chỉ ngồi chờ (keep-alive) -> lễ tân đứng trông, không cần tư vấn viên
    • Khách lại hỏi thật (request) -> đưa cho 1 tư vấn viên (thread) xử lý yêu cầu
    • Xong câu hỏi, khách lại ngồi chờ -> tư vấn viên được trả về, lễ tân tiếp tục trông
  • Event MPM = dùng thread khi cần xử lý request, còn lúc chờ thì dùng event (event loop) để tiết kiệm tài nguyên. Nginx = Event loop xử lý cả chờ lẫn request => không dùng thread-per-request.

Kiểu kiến trúc tổng quan:

• Modular architecture
• Nhiều module mạnh (rewrite, auth, proxy, security)
• Tích hợp tốt PHP qua mod_php, php-fpm, CGI.

Ưu điểm:

• Module phong phú nhất
• Linh hoạt, mạnh với hệ thống phức tạp
• Hỗ trợ .htaccess -> cho phép người dùng tùy chỉnh từng thư mục. Ổn định và tương thích tốt (đặc biệt mod_php)

Nhược điểm:

• RAM tiêu thụ tăng theo số connection, Scale kém với lượng kết nối lớn.
• Ít tối ưu hơn Nginx trong high-load
• Cấu hình đôi khi nặng

Nginx

Nginx sử dụng cấu trúc hướng sự kiện và xử lý các request không đồng bộ. Nó được thiết kế sử dụng thuật toán xử lý kết nối theo hướng sự kiện không chặn (non-blocking). Do đó, tiến trình của nó có thể xử lý hàng ngàn kết nối (request) trong 1 luồng xử lý (thread). Với cách xử lý kết nối như vậy cho phép Nginx làm việc rất nhanh và mạnh với lượng tài nguyên hạn chế.

• Master Process – điều khiển, không xử lý request
  • Master process chỉ làm các việc:
    • Reads your configuration files : Parse các file cấu hình, nginx.conf, check syntax, xác thực các giá trị (port, path của log, số lượng worker,…), build internal config structure để các worker dùng chung. Đảm bảo mọi thứ được cấu hình chính xác.
    • Binds to network ports : Tạo logic cho các cổng 80 và 443 cho trang web của bạn
    • Manages worker processes : Khởi động, monitors, restarts khi mà nó bị crash
    • Handles system signals : Xử lý thông tin hệ thống, reload hoặc stop Nginx
• Worker Process – đơn vị xử lý request thực sự
  • Mỗi worker process:
    • Handles actual web requests : Đây là nơi thực hiện toàn bộ công việc chính.
    • Works independently : Nếu 1 worker có sự cố, các worker khác vẫn tiếp tục chạy
    • Uses smart event handling : Có thể xử lý hàng ngàn kết nối mà không bị quá tải
    • Runs with limited privileges : Chạy với quyền hạn hạn chế: thường dưới tài khoản www-data để tăng cường bảo mật
• **Event Loop – cốt lõi của từng worker ** while (true) { receive events from the kernel via epoll/kqueue; process events: read, write, accept, timer; run the HTTP request state machine; }
  • Nginx không cấp phát thread mới cho mỗi request. Nginx worker không đọc/ghi socket trực tiếp mỗi khi có request, mà:
    1. Đăng ký socket vào epoll (epoll_ctl)
    2. Chờ epoll báo event (epoll_wait)
    3. Khi có event, Nginx xử lý event bằng callback
    4. Trở lại vòng lặp (không block)
  • Điều này tạo ra 3 ưu điểm lớn:
    • Không chặn CPU khi I/O chờ (non-blocking)
    • Không cần thread stack (tiết kiệm RAM)
    • Event loop xử lý đồng thời hàng nghìn kết nối chỉ trong một worker
• Multi-Phase Request Processing Architecture
  • Nginx xử lý HTTP theo dạng state machine gồm nhiều phase:
    POST_READ => SERVER_REWRITE => FIND_CONFIG => REWRITE => ACCESS => TRY_FILES => CONTENT => LOG
  • Ở mỗi phase:
    • Các module được gọi theo thứ tự ưu tiên
    • Không block
    • Nginx dịch chuyển request sang phase kế tiếp
    • Module có thể dừng pipeline (deny, rewrite, redirect, proxy…)
  • Ví dụ:
    • REWRITE phase chạy rewrite rules
    • ACCESS phase kiểm tra quyền truy cập
    • CONTENT phase quyết định trả file tĩnh hay proxy_pass
    • LOG phase ghi access log

Mỗi phase chỉ làm việc rất ngắn, rất nhanh.

Tại sao nhiều worker?

• Tránh bottleneck từ single process
• Mỗi worker chạy trên một CPU core
• Nếu 1 worker crash -> không làm chết cả server

Master không xử lý HTTP/HTTPS hay TCP request. Nó chỉ “quản lý” toàn bộ server.

Kiểu kiến trúc:

• Event loop, asynchronous, non-blocking I/O.
• Một process master + nhiều process worker.
• Mỗi worker có thể xử lý hàng chục nghìn kết nối đồng thời.

Ưu điểm kiến trúc:

• Rất nhanh và nhẹ
• Thích hợp làm reverse proxy, load balancer, static file server, API gateway
• Không bị chặn (non-block)

Nhược điểm:

• Cấu hình đôi khi phức tạp
• Hạn chế module động (dù bản mới đã hỗ trợ load module)

Caddy Server

Thời gian chạy của Go tối ưu hóa thời gian CPU theo lịch trình theo những cách thông minh hơn hệ điều hành, có thể sử dụng các luồng không gian người dùng nhẹ được gọi là goroutines. Caddy sử dụng tất cả các lõi CPU và dễ dàng xử lý hàng trăm nghìn yêu cầu mỗi giây.
Caddy = Go application + Go netpoller + Go goroutines + plugin architecture
Không có master process, không có worker process.
Tất cả hoạt động trong một process duy nhất.
Caddy dựa trên cơ chế concurrency M:N của Go, không dùng OS threads trực tiếp.

1. Go Scheduler (GOMAXPROCS): Hệ thống quyết định mức song song của Go
   • Số CPU core = số “P” (Processor logical)
   • Mỗi P chạy nhiều goroutines
   • Scheduler map:
     • M (OS threads): OS thread thật
     • P (logical processors): Slot logic để M chạy G
     • G (goroutines): task cần chạy
       GOMAXPROCS = số CPU core -> Caddy tận dụng hết.
   • Chu trình:
     1. Goroutine (G) đưa vào hàng đợi của P
     2. P gán G cho một M (OS thread)
     3. M thực thi
     4. Nếu G block (syscall/I/O), M bị block → Scheduler gán P cho một M khác để chạy G khác.
     5. Scheduler liên tục xoay vòng
2. Go Netpoller: Hệ thống epoll/kqueue/IOCP của Go
   • Go runtime sử dụng hệ thống I/O không đồng bộ:
     • Linux -> epoll
     • FreeBSD -> kqueue
     • Windows -> IOCP
   • Khi socket có event (read/write), netpoller đánh thức goroutine tương ứng.

Go: event-loop do runtime quản lý, tự xử lý epoll/kqueue/IOCP và đánh thức goroutine khi I/O sẵn sàng; lập trình viên không cần tự dùng select/epoll như Nginx.
Nginx: event-loop do lập trình viên viết => xử lý request

3. Goroutine Scheduling: cơ chế lập lịch M:N
   • Mỗi request HTTP/TLS = 1 goroutine riêng
   • Khi goroutine block -> scheduler park nó
   • Khi có event -> scheduler wake nó

Caddy xử lý mỗi request bằng goroutine, còn nền tảng event-driven thực sự nằm trong Go runtime.

Kiến trúc:

• Event-driven như Nginx
• Tích hợp ACME LetsEncrypt tự động
• Một cấu hình “human friendly”
• Dùng JSON hoặc Caddyfile

Ưu điểm:

• Chỉ cần 1 dòng là có HTTPS
• Cấu hình rõ ràng
• Tích hợp tốt reverse proxy, load balancing, TLS, HTTP/3

Nhược điểm:

• Ít module hơn Nginx & Apache
• Cộng đồng nhỏ hơn
• Chưa phổ biến ở hệ thống enterprise “legacy”

---

4. Phân tích

Sau đây là bảng so sánh của Caddy, Nginx và Apache nhằm liệt kê một số tính năng và chức năng chính:

Tính năng/Chức năng	Caddy	Nginx	Apache
Ngôn ngữ phát triển	Go	C	C
Giấy phép	Apache 2.0	BSD 2-Clause (tương tự)	Apache 2.0
Cơ chế	Goroutine + Go scheduler	Event-loop non-blocking	OS thread/process
Process model	1 process duy nhất	Master + worker	Master + worker (Prefork/Worker/Event)
Threads	Goroutine (M:N)	Gần như không dùng thread cho request	OS thread (Worker/Event)
HTTPS tự động	Có (hỗ trợ mặc định)	Không (cần module + cấu hình)	Không (cần module + cấu hình)
Event-loop	Go netpoller (epoll/kqueue/IOCP)	Tự viết event-loop sử dụng epoll/kqueue	Không có event-loop (phụ thuộc MPM)
I/O concurrency	Non-blocking I/O qua Go runtime	epoll/kqueue non-blocking	Blocking hoặc hybrid tùy MPM
Hot reload	Không restart process, zero-downtime	Worker restart (hot reload nhưng có worker swap)	Rất yếu (process restart, downtime nhẹ)
HTTP/2 & HTTP/3	Hỗ trợ sẵn	Hỗ trợ (HTTP/3 yêu cầu build riêng)	Hỗ trợ (HTTP/2 ổn, HTTP/3 chưa ổn định)
Phương thức cấu hình	Caddyfile	nginx.conf	.htaccess và httpd.conf
Reverse proxy	Hỗ trợ sẵn	Hỗ trợ sẵn	Cần module mod_proxy
Load balancing	Hỗ trợ sẵn	Hỗ trợ sẵn	Cần module mod_proxy_balancer
Hệ thống module/plugin	Hỗ trợ (nạp động)	Hỗ trợ (thường biên dịch tĩnh)	Hỗ trợ (nạp động)
Hiệu năng	Cao (đặc biệt ở cấu hình mặc định)	Cao	Trung bình (nhưng có thể tối ưu)
Mức độ an toàn	Thiết kế hướng đến bảo mật (HTTPS mặc định)	An toàn, nhưng cần cấu hình cẩn thận	An toàn, nhưng cần chú ý cấu hình và module
Thân thiện với người mới	Cao (HTTPS tự động, cấu hình đơn giản)	Trung bình (cấu hình hơi phức tạp)	Thấp (cấu hình và quản lý module phức tạp hơn)
Đa nền tảng	Có	Có	Có

Hình dung dễ hiểu:
OS thread giống: Một nhân viên thật, phải trả lương đầy đủ, tốn chi phí mỗi khi tuyển/dừng
Goroutine giống: Tình nguyện viên: rất rẻ, tạo bao nhiêu cũng được; chỉ cần thread thật điều phối.
Event-loop giống: Một nhân viên chính, nhận tín hiệu rồi gọi người khác làm.

Điểm chung Apache với Nginx: Cả hai đều có master process

Master process ở Apache và Nginx đều làm các việc giống nhau:

• Đọc & parse file cấu hình
• Bind port, mở socket listen
• Fork/spawn các worker
• Nhận tín hiệu (reload, stop, restart)
• Giám sát worker, spawn lại nếu chết

Điểm khác biệt: Kiến trúc worker của Apache, Nginx

1. NGINX Worker = Event-loop non-blocking
   • Mỗi worker chạy 1 luồng (thread) duy nhất theo kiểu: epoll_wait() handle_events()
   • Mỗi worker xử lý hàng chục nghìn connections
   • Không mở thêm thread
   • Không blocking
   • Một worker = một event-loop = một state machine
     Worker của Nginx rất nhẹ, không tạo thread/process per request. Kiến trúc hướng sự kiện (event-driven).
2. APACHE Worker = Thread-based hoặc process-based

• Apache có 3 mô hình (MPM):
  1. prefork
     • Worker = chỉ 1 process = xử lý 1 request
     • Không tạo thread
     • Blocking
     • Siêu tốn RAM
     • Dùng cho mod_php cũ
  2. worker
     • Worker process có nhiều threads
     • Mỗi request = 1 thread xử lý
     • Thread blocking I/O
     • Tốn CPU + RAM
  3. event
     • Gần giống worker nhưng:
       • Thread sự kiện quản lý keep-alive idle
       • Threads còn lại xử lý request active
  Worker của Apache là “container chứa các threads”
  Worker của Nginx là “event-loop chạy đơn thread”

Caddy không có kiến trúc dạng “master–worker” như Nginx hoặc Apache.

Toàn bộ server chỉ là 1 process duy nhất, hoạt động dựa vào:
Caddy = Go Application + Go Scheduler + Go Netpoller + Go Plugin Modules
Toàn bộ concurrency, scaling, I/O event-loop đều do Go runtime xử lý, Caddy chỉ xây logic xử lý HTTP/TLS/Proxy.

Sơ đồ

Usage – Sơ đồ này hiển thị tỷ lệ phần trăm các website sử dụng các máy chủ web khác nhau. (Thu thập vào ngày 8/12/2025)

Usage broken down by ranking

Xu hướng theo thời gian
Sơ đồ này hiển thị xu hướng theo thời gian về tỷ lệ phần trăm các website sử dụng các công nghệ được chọn.
Khảo sát xu hướng chuyên biệt của chúng tôi cung cấp thêm thông tin về tỷ lệ sử dụng các máy chủ web và thị phần của chúng.

---

5. Kết quả đạt được

• Hiểu rõ kiến trúc của Nginx, Caddy, Apache
• Nắm được sự khác nhau giữa các công cụ này
• So sánh ưu/nhược điểm để chọn giải pháp phù hợp.

---

6. Tài liệu tham khảo

Tài liệu tham khảo dạng gợi ý:
[1] https://httpd.apache.org/docs/2.4/mpm.html
[2] https://httpd.apache.org/docs/2.4/configuring.html
https://nginx.org/en/docs/http/request_processing.html
[3] https://www.quora.com/What-are-the-benefits-of-using-a-web-server-like-Apache-or-Nginx-over-Caddy
[4] https://blog.tjll.net/reverse-proxy-hot-dog-eating-contest-caddy-vs-nginx/
[5] https://dev.to/shingaiz/comparing-caddy-to-nginx-and-apache-iok
[6] https://kinsta.com/blog/nginx-vs-apache/
[7] https://www.marketenterprise.vn/blog/gioi-thieu-ve-nginx-va-apache.html
[8] https://medium.com/@nomannayeem/nginx-master-worker-architecture-from-zero-to-production-c451ee8e44ca
[9] https://operavps.com/blog/caddy-vs-nginx-vs-apache/

---