13 phút để đọc
Nginx và Apache là hai bộ máy chủ web mã nguồn mở phổ biến nhất thế giới. Chúng phục vụ tổng cộng hơn 50% lưu lượng internet. Cả hai giải pháp này đều có khả năng xử lý các loại công việc đa dạng và phối hợp với những phần mềm khác để tạo nên một bộ công nghệ web hoàn chỉnh.
Dù Nginx và Apache có nhiều điểm tương đồng, chúng không thể hoàn toàn thay thế lẫn nhau. Mỗi bên đều có những điểm nổi trội riêng, và bài viết này sẽ đi sâu vào những điểm mạnh cũng như điểm yếu của từng phần mềm.
Tổng quan chung
Trước khi đi sâu vào những khác biệt giữa Apache và Nginx, chúng ta hãy cùng điểm qua lịch sử hình thành và những đặc điểm tổng quan của hai dự án này.
Apache
Phầm mềm máy chủ HTTP Apache do Robert McCool tạo ra vào năm 1995 và được phát triển dưới sự điều hành của tổ chức Apache Software Foundation từ năm 1999. Do máy chủ web HTTP là dự án khởi đầu và cũng là phần mềm phổ biến nhất của tổ chức này, nó thường được gọi tắt là “Apache”.
Apache từng là phần mềm máy chủ phổ biến nhất trên internet trong giai đoạn từ 1996 đến 2016. Nhờ sự phổ biến này, Apache sở hữu một nguồn tài liệu phong phú và được nhiều phần mềm khác hỗ trợ việc tích hợp.
Các quản trị viên thường chọn Apache vì nó linh hoạt, mạnh mẽ và được hỗ trợ rộng rãi. Apache có thể mở rộng thông qua hệ thống module nạp động (dynamically loadable module) và có khả năng phục vụ trực tiếp nhiều ngôn ngữ script như PHP mà không cần đến phần mềm bổ trợ.
Nginx
Vào năm 2002, Igor Sysoev bắt tay xây dựng Nginx nhằm giải quyết bài toán C10K. Đó là việc đòi hỏi máy chủ web phải xử lý được mười nghìn kết nối đồng thời, một thách thức lớn lúc bấy giờ. Bản phát hành công khai đầu tiên của Nginx ở năm 2004 đã đạt được mục tiêu này nhờ vào kiến trúc bất đồng bộ (asynchronous) và dựa trên sự kiện (event-driven).
Kể từ đó, Nginx đã vượt mặt Apache về độ phổ biến nhờ dung lượng nhẹ và khả năng mở rộng dễ dàng trên các phần cứng có cấu hình yếu. Nginx nổi trội trong việc phục vụ nhanh chóng nội dung tĩnh (static), sở hữu hệ thống module mạnh mẽ và có thể chuyển tiếp (proxy) các yêu cầu động tới những phần mềm khác khi cần thiết.
Các quản trị viên thường chọn Nginx vì hiệu quả sử dụng tài nguyên, khả năng phản hồi tốt khi chịu tải cao, cũng như cú pháp cấu hình trực quan, dễ hiểu.
Kiến trúc xử lý kết nối
Một khác biệt đáng lưu tâm giữa Apache và Nginx nằm ở cách thức mà mỗi phần mềm xử lý kết nối và lưu lượng mạng. Đây có lẽ là điểm khác biệt quan trọng nhất quyết định cách chúng phản hồi khi chịu tải.
Apache
Apache cung cấp nhiều module đa xử lý (multi-processing modules – Apache gọi tắt là MPM) để quy định cách thức xử lý request từ client. Điều này cho phép quản trị viên tùy chỉnh kiến trúc xử lý kết nối của máy chủ. Các MPM bao gồm:
- mpm_prefork: Module xử lý này tạo ra các process, mỗi process chỉ có một thread để xử lý request. Mỗi process con chỉ xử lý được một kết nối tại một thời điểm. Khi số lượng request ít hơn số lượng process, MPM này hoạt động rất nhanh. Tuy nhiên, hiệu suất sẽ giảm mạnh khi số request vượt quá số process, cho nên không phải là lựa chọn tốt trong nhiều trường hợp. Mỗi process chiếm dụng một lượng RAM đáng kể, khiến MPM này khó mở rộng một cách hiệu quả. Dù vậy, đây vẫn có thể là lựa chọn phù hợp nếu được sử dụng cùng các thành phần không được thiết kế để chạy đa luồng. Ví dụ, PHP không phải lúc nào cũng có tính an toàn luồng (thread-safe), nên MPM này từng được coi là giải pháp tốt để làm việc với
mod_php, module Apache xử lý những file dạng này. - mpm_worker: Module này tạo ra các process, và mỗi process quản lý nhiều thread. Mỗi thread này có thể xử lý một kết nối. Thread hiệu quả hơn process rất nhiều, đồng nghĩa với việc MPM này có khả năng mở rộng tốt hơn so với mpm_prefork. Do số lượng thread nhiều hơn process, các kết nối mới có thể ngay lập tức được một thread trống xử lý mà không phải chờ đợi process trống.
- mpm_event: Trong hầu hết các trường hợp module này hoạt động tương tự module worker, nhưng nó được tối ưu hóa để xử lý các kết nối dạng keep-alive (kết nối HTTP được giữ mở để tái sử dụng). Với mpm_worker, một kết nối sẽ giữ một thread cho dù có request nào đang được thực hiện hay không, miễn là kết nối đó được duy trì (keep-alive). Ngược lại, mpm_event xử lý các kết nối keep-alive bằng cách sử dụng các thread chuyên biệt để quản lý chúng, và chuyển các request đang hoạt động sang cho những thread khác. Cơ chế này giúp module không bị tắc nghẽn bởi các request dạng keep-alive, tăng tốc độ thực thi.
Apache có một kiến trúc linh hoạt với nhiều lựa chọn thuật toán xử lý kết nối và request khác nhau. Chúng chủ yếu phản ánh quá trình phát triển của máy chủ web qua thời gian cũng như nhu cầu ngày càng tăng về khả năng xử lý đồng thời (concurrency) trong bối cảnh internet không ngừng thay đổi.
Nginx
Nginx ra đời sau Apache khi nhận thức rõ ràng hơn về các vấn đề liên quan đến concurrency mà những trang web quy mô lớn phải đối mặt. Kết quả là Nginx ngay từ đầu đã được thiết kế để sử dụng thuật toán xử lý kết nối theo kiểu bất đồng bộ, non-blocking (không chặn) và dựa trên sự kiện.
Nginx tạo ra các worker process, mỗi process có thể xử lý hàng ngàn kết nối. Các worker process làm được điều này nhờ triển khai một cơ chế vòng lặp nhanh (fast looping mechanism) liên tục kiểm tra và xử lý các event. Việc tách biệt tác vụ xử lý thực tế khỏi kết nối cho phép mỗi worker chỉ phải bận tâm đến một kết nối khi có một event mới được kích hoạt.
Mỗi kết nối do worker xử lý được đặt trong một event loop (vòng lặp sự kiện). Bên trong vòng lặp này, các event được xử lý bất đồng bộ, cho phép công việc diễn ra theo kiểu non-blocking. Khi một kết nối đóng lại, nó sẽ được gỡ bỏ khỏi vòng lặp.
Kiểu xử lý kết nối này cho phép Nginx mở rộng quy mô hiệu quả ngay cả với nguồn tài nguyên hạn chế. Do server chạy kiểu đơn luồng và không tạo thêm process mới cho mỗi kết nối mới, lượng tài nguyên RAM và CPU tiêu thụ thường giữ ở mức tương đối ổn định, ngay cả khi nó chịu tải lớn.
Nội dung tĩnh và nội dung động
Trong các trường hợp thực tế, một trong những điểm so sánh phổ biến nhất giữa Apache và Nginx là cách mỗi máy chủ xử lý request đối với nội dung tĩnh và nội dung động.
Apache
Máy chủ Apache có thể xử lý nội dung tĩnh bằng các phương thức truyền thống dựa trên file. Hiệu suất của những tác vụ này chủ yếu phụ thuộc vào các phương thức MPM đã được mô tả ở phần trước.
Apache cũng có thể xử lý nội dung động bằng cách nhúng trực tiếp processor (trình xử lý) của ngôn ngữ đó vào mỗi thực thể worker. Điều này cho phép Apache chạy nội dung động ngay bên trong web server mà không cần phụ thuộc vào các thành phần bên ngoài. Các processor động này có thể được kích hoạt thông qua việc sử dụng các module nạp động.
Khả năng xử lý nội dung động ngay trong server của Apache đã trực tiếp góp phần vào sự phổ biến của các kiến trúc LAMP (Linux-Apache-MySQL-PHP), bởi code PHP có thể được chạy trực tiếp bởi chính web server.
Nginx
Nginx tự nó không có khả năng xử lý nội dung động. Để xử lý các request PHP và các request nội dung động khác, Nginx phải chuyển request đó cho một thư viện bên ngoài để thực thi và chờ output trả về. Kết quả sau đó mới được chuyển tiếp tới client.
Các request này phải được trao đổi giữa Nginx và thư viện bên ngoài thông qua một trong các giao thức mà Nginx hỗ trợ (ví dụ: http, FastCGI, SCGI, uWSGI, memcache). Trên thực tế, PHP-FPM (một triển khai của FastCGI) thường là một giải pháp thay thế trực tiếp, nhưng Nginx không bị ràng buộc với bất kỳ ngôn ngữ cụ thể nào.
Tuy nhiên, phương pháp này cũng có những ưu điểm nhất định. Do interpreter (trình thông dịch) động không được nhúng vào worker process, gánh nặng xử lý của nó sẽ chỉ xuất hiện đối với nội dung động. Nội dung tĩnh có thể được phục vụ một cách trực tiếp, và interpreter sẽ chỉ được gọi đến khi thực sự cần thiết.
Cấu hình phân tán và tập trung
Apache và Nginx có cách tiếp cận rất khác nhau về việc cho phép ghi đè cấu hình theo từng thư mục.
Apache
Apache cung cấp tùy chọn cho phép cấu hình bổ sung theo từng thư mục bằng cách kiểm tra và diễn giải các directive (chỉ thị) trong những file ẩn đặt ngay bên trong các thư mục chứa nội dung. Những file này được gọi là file .htaccess.
Vì các file này nằm ngay trong thư mục nội dung, nên khi xử lý một request, Apache sẽ kiểm tra từng thành phần của đường dẫn để tìm file .htaccess và áp dụng các directive được tìm thấy. Cơ chế này cho phép cấu hình web server một cách phi tập trung. Nó thường được dùng để triển khai URL rewrite (thay đổi URL hiển thị), giới hạn truy cập, xác thực và phân quyền, hay thậm chí là các chính sách cache.
Mặc dù tất cả các ví dụ trên đều có thể được cấu hình trong file cấu hình chính của Apache, file .htaccess lại có một số ưu điểm quan trọng. Thứ nhất, vì các file này được diễn giải mỗi khi được tìm thấy trong đường dẫn của request, các thay đổi sẽ có hiệu lực ngay lập tức mà không cần reload server. Thứ hai, phương pháp này cho phép người dùng không có đặc quyền được quản lý một số khía cạnh trên nội dung web của họ mà không cần có quyền kiểm soát toàn bộ file cấu hình.
Cách làm giúp một số phần mềm web (như hệ thống quản lý nội dung – CMS) tự cấu hình môi trường của mình mà không cần truy cập vào file cấu hình trung tâm. Nó cũng được các nhà cung cấp shared hosting (hosting dùng chung) sử dụng để vừa giữ quyền kiểm soát cấu hình chính, vừa cho phép khách hàng quản lý các thư mục riêng của họ.
Nginx
Ngoài file cấu hình chính, Nginx không diễn giải file .htaccess và cũng không cung cấp bất kỳ cơ chế nào để đánh giá cấu hình theo thư mục. Apache ra đời trong bối cảnh mà việc chạy nhiều ứng dụng web khác nhau trên cùng một server còn phổ biến và việc phân quyền còn hợp lý. Ngược lại, Nginx được phát triển khi các ứng dụng có xu hướng được container hóa và đi kèm với cấu hình mạng riêng, làm giảm thiểu nhu cầu này. Cách tiếp cận của Nginx có thể kém linh hoạt hơn so với mô hình của Apache trong một số trường hợp, nhưng nó cũng có những ưu điểm riêng.
Cải tiến đáng chú ý nhất so với hệ thống cấu hình cấp thư mục của.htaccess là cải thiện hiệu năng. Với một thiết lập Apache điển hình với .htaccess có thể ở trong bất kỳ thư mục nào, server sẽ phải kiểm tra sự tồn tại của các file này trong mỗi thư mục cha dẫn đến file được yêu cầu, và việc này được lặp lại với mỗi request.
Nếu tìm thấy một hoặc nhiều file .htaccess, tất chúng phải được đọc và diễn giải. Bằng cách không cho phép ghi đè cấu hình ở cấp thư mục, Nginx có thể phục vụ request nhanh hơn nhờ việc chỉ cần tra cứu thư mục và đọc file một lần cho mỗi request (với giả định file được tìm thấy trong cấu trúc thư mục thông thường).
Một ưu điểm khác liên quan đến bảo mật. Việc phân tán quyền truy cập cấu hình ở cấp thư mục cũng đồng nghĩa với việc phân tán trách nhiệm bảo mật cho từng người dùng, những người có thể không đủ tin cậy để xử lý tốt việc này. Cần lưu ý rằng ta hoàn toàn có thể tắt tính năng diễn giải .htaccess trong Apache nếu có những lo ngại tương tự.
Diễn giải dựa trên file và dựa trên URI
Cách web server diễn giải các request và cách nó ánh xạ chúng tới các tài nguyên thực tế trên hệ thống là một điểm khác biệt nữa giữa hai phần mềm này.
Apache
Apache có khả năng diễn giải một request dưới dạng một tài nguyên vật lý trên hệ thống file hoặc một địa chỉ URI (trường hợp này sẽ cần được đánh giá một cách trừu tượng hơn). Nhìn chung, Apache sử dụng block <Directory> hoặc <Files> cho tài nguyên dựa trên file, trong khi block <Location> được dùng cho các tài nguyên trừu tượng hơn.
Vì Apache được thiết kế ngay từ đầu để làm một web server, nên mặc định của nó là diễn giải các request như là các tài nguyên trên hệ thống file. Nó bắt đầu bằng cách lấy document root (thư mục gốc tài liệu), sau đó nối với phần URI của request (phần nằm sau host và port) để tìm ra file thực tế. Về cơ bản, cấu trúc phân cấp của hệ thống file được thể hiện trên web dưới dạng cây tài liệu (document tree) có thể truy cập.
Apache cung cấp một số phương án thay thế khi request không khớp với hệ thống file thực tế bên dưới. Chẳng hạn, directive Alias có thể được dùng để ánh xạ tới một vị trí khác. Sử dụng block <Location> là một cách làm việc trực tiếp với URI thay vì với hệ thống file. Ngoài ra còn có các biến thể sử dụng biểu thức chính quy (regular expression) để áp dụng cấu hình một cách linh hoạt hơn trên toàn bộ hệ thống file.
Mặc dù Apache có khả năng hoạt động dựa trên cả hệ thống file và URI, nó vẫn thiên về các phương pháp xử lý dựa trên hệ thống file. Điều này có thể được thấy qua một số quyết định thiết kế, bao gồm việc sử dụng file .htaccess cho cấu hình theo thư mục. Chính tài liệu của Apache cũng cảnh báo ta không nên dùng các block dựa trên URI để giới hạn truy cập khi request đó tương ứng với một đường dẫn trên hệ thống file.
Nginx
Nginx được tạo ra để vừa là web server, vừa là proxy server. Do kiến trúc của nó cần phải phục vụ cho cả hai vai trò này, Nginx chủ yếu làm việc với URI và chỉ chuyển đổi sang hệ thống file khi cần.
Điều này thể hiện rõ trong cách file cấu hình của Nginx được xây dựng và diễn giải. Nginx không cung cấp cơ chế để chỉ định cấu hình cho một thư mục trên hệ thống file, mà thay vào đó nó sẽ phân tích chính URI đó.
Ví dụ, các block cấu hình chính của Nginx là block server và location. Block server diễn giải host đang được request, trong khi các block location chịu trách nhiệm so khớp các phần của URI nằm sau host và port. Tại thời điểm này, request đang được diễn giải như một URI, chứ không phải là một vị trí trên hệ thống file.
Đối với các file tĩnh, mọi request cuối cùng đều phải được ánh xạ tới một vị trí trên hệ thống file. Đầu tiên, Nginx chọn các block server và location sẽ xử lý request, sau đó kết hợp document root với URI, đồng thời điều chỉnh lại nếu cần dựa theo cấu hình đã chỉ định.
Những điều đó nghe có vẻ tương tự nhau, nhưng việc phân tích request chủ yếu dưới dạng URI thay vì vị trí trên hệ thống file cho phép Nginx dễ dàng hoạt động trong cả vai trò web server, mail server và proxy server.
Nginx được cấu hình bằng cách xác định cách phản hồi với các dạng request (request pattern) khác nhau. Nginx không kiểm tra hệ thống file cho đến khi sẵn sàng phục vụ request. Điều này giải thích tại sao nó không triển khai một cơ chế tương tự như file .htaccess.
Sử dụng Apache và Nginx cùng nhau
Sau khi xem xét các ưu và nhược điểm của cả Apache và Nginx, có thể bạn đã hình dung rõ hơn server nào phù hợp hơn với nhu cầu của mình. Trong một số trường hợp, ta hoàn toàn có thể tận dụng thế mạnh của mỗi bên bằng cách sử dụng cả hai cùng lúc.
Cấu hình phổ biến cho sự kết hợp này là đặt Nginx ở phía trước Apache với vai trò như một reverse proxy (máy chủ trung gian giữa client và backend server). Thiết lập này cho phép Nginx xử lý tất cả các request từ client, qua đó tận dụng được tốc độ xử lý nhanh và khả năng xử lý đồng thời một lượng lớn kết nối của nó.
Đối với nội dung tĩnh (vốn là thế mạnh của Nginx), các file sẽ được phục vụ nhanh chóng và trực tiếp tới client. Đối với nội dung động, ví dụ như các file PHP, Nginx sẽ dẫn request đó tới Apache để xử lý và nhận về trang đã được render. Sau đó, Nginx sẽ chuyển nội dung này ngược lại cho client.
Thiết lập này hoạt động hiệu quả với nhiều trường hợp vì nó cho phép Nginx hoạt động như một “cỗ máy phân loại”. Nó sẽ xử lý tất cả các request trong khả năng của mình và chuyển tiếp những request mà nó không thể tự phục vụ. Bằng cách giảm bớt lượng request mà server Apache phải xử lý, ta có thể giảm thiểu tình trạng blocking xảy ra khi một tiến trình (process) hoặc luồng (thread) của Apache bị chiếm dụng.
Cấu hình này cũng tạo điều kiện thuận lợi cho việc scale theo chiều ngang bằng cách thêm các backend server khi cần thiết. Nginx có thể được cấu hình để chuyển tiếp request tới nhiều server, từ đó tăng hiệu năng cho toàn bộ hệ thống.
Kết luận
Cả Apache và Nginx đều là những công cụ mạnh mẽ và linh hoạt. Việc quyết định phần mềm nào là tốt nhất cho bạn phụ thuộc phần lớn vào việc đánh giá các yêu cầu cụ thể và kiểm thử với các mẫu lưu lượng mà bạn dự kiến phục vụ.
Sự khác biệt giữa hai dự án này có tác động rất thực tế đến hiệu năng, tính năng, và thời gian cần thiết để triển khai một trong hai giải pháp trên môi trường production. Hãy sử dụng giải pháp phù hợp nhất với mục tiêu của bạn.
