Nginx và Apache

I. Giới thiệu

1. Apache là gì?

Apache HTTP Server, hay thường được gọi là Apache là phần mềm web server được sử dụng nhiều nhất trên thế giới. Ban đầu được dựa trên NCSA HTTPd server. Apache bắt đầu được phát triển vào khoảng đầu năm 1995 khi NCSA bị đình trệ và đóng 1 vai trò quan trọng trong sự phát triển ban đầu của World Wide Web, nhanh chóng vượt qua NCSA HTTPd như HTTP server ưu thế và trở nên phổ biến nhất kể từ tháng 4/1996. Vào năm 2009, nó trở thành phần mềm web server đầu tiên phục vụ hơn 100 triệu website.
Apache được phát triển và duy trì bởi 1 cộng đồng mở của các nhà phát triển dưới sự bảo trợ của Apache Software Foundation. Thường được sử dụng trên hệ thống giống Unix (thường là Linux), ngoài ra còn hỗ trợ rộng rãi các hệ điều hành khác bao gồm eComStation, Microsoft Windows, NetWare, OpenVMS, OS/2 và TPF. Apache là miễn phí và là phần mềm mã nguồn mở.
Vào tháng 11/2015, Apache được đánh giá phục vụ 50% của tất cả các website đang hoạt động và 35% top server trên tất cả các lĩnh vực.

2. Nginx là gì?

Nginx (phát âm là “engine x”) là 1 web server tập trung mạnh mẽ vào khả năng xử lý đồng thời cao, hiệu suất và sử dụng ít bộ nhớ. Nó cũng có thể hoạt động như một reverse proxy server cho các giao thức HTTP, HTTPS, SMTP, POP3 và IMAP, cũng như cân bằng tải (load balancer) và HTTP cache.
Được tạo ra bởi Igor Sysoev năm 2002, Nginx chạy trên Unix, Linux, các biến thể BSD, Mac OS X, Solaris, AIX, HP-UX và Microsoft Windows. Nginx là miễn phí và là phần mềm mã nguồn mở.

II. So sánh Nginx và Apache

1. Tổng quan chung

  • Apache web server là server phổ biến nhất trên Internet từ năm 1996.
  • Nginx được Igor Sysoev tạo ra năm 2002 nhằm giải quyết nhu cầu cần phục vụ 1 số lượng lớn các request đồng thời và vấn đề C10K (tức là hệ thống cần xử lý được khi có 10.000 khách hàng sử dụng cùng 1 thời điểm).

2. Kiến trúc

Apache hoạt động dựa trên kiến trúc hướng quy trình. Nginx hoạt động dựa trên kiến trúc hướng sự kiện.

  • Apache cung cấp một loạt các module đa xử lý (MPMs) để quy định cách mà nó phục vụ các request của người dùng. Các loại MPMs mà chúng ta có thể lựa chọn gồm:
    • Prefork: Nếu sử dụng MPM này thì mỗi request đến sẽ được một process xử lý, điều này sẽ tốn nhiều RAM nếu như có nhiều request đến (sẽ có nhiều process được tạo ra), tuy nhiên ưu điểm là nếu một process có vấn đề thì không ảnh hưởng đến các process khác. Số lượng process được tạo ra chúng ta có thể quy định trong file cấu hình của apache.
    • Worker: Nếu sử dụng MPM này thì mỗi request đến sẽ được xử lý bởi một thread thay vì một process (các thread có thể share memory chung với nhau), do đó sẽ tiết kiệm RAM nhiều hơn. Số lượng thread và process sinh ra, số thread trong một process, … chúng ta có thể quy định trong file cấu hình. Nhược điểm của MPM này là nếu như một thread có vấn đề sẽ ảnh hưởng đến các thread khác trong cùng process, hơn nữa nếu cấu hình keep-alive thì tất cả các process/thread đều được giữ lại để phục vụ cho đến khi hết thời gian keep-alive.
    • Event: Tương tự như Worker, có nghĩa là cũng sử dụng thread để phục vụ các request thay vì dùng process, tuy nhiên với Event MPM, thread riêng biệt sẽ dùng để phục vụ request và được giải phóng ngay sau khi xử lý xong, không phục thuộc vào trạng thái kết nối HTTP. Điều này đã được đánh dấu ổn định với việc phát hành của Apache 2.4.

    Tuy nhiên, việc xử lý các truy vấn từ client đến server bằng các thread, mỗi truy vấn client sẽ được server xử lý bằng một thread riêng biệt cho đến khi nó hoàn thành nhiệm vụ sẽ làm ổ cứng trên server sẽ mất nhiều thời gian hơn để giải phóng các thread đã hoàn thành nhiệm vụ, và việc tạo ra nhiều thread cũng sẽ làm server tiêu hao rất nhiều tài nguyên (CPU, RAM).

  • Do ra đời sau Apache, Nginx đã khắc phục được hạn chế trên của Apache do sử dụng các thuật toán xử lý không đồng bộ, đơn luồng và hướng sự kiện.
    • Hướng sự kiện có nghĩa rằng các thông báo hoặc tín hiệu được sử dụng để đánh dấu sự khởi đầu hay kết thúc của 1 process. Như vậy, các tài nguyên có thể được sử dụng bởi các process khác cho đến khi 1 process khởi tạo sự kiện được kích hoạt và tài nguyên có thể được phân bố và phát hành tự động. Điều này dẫn đến việc sử dụng tối ưu hóa bộ nhớ và CPU.
    • Không đồng bộ có nghĩa là các thread có thể được xử lý đồng thời, giúp tăng cường việc chia sẻ tài nguyên mà không bị chuyên dụng hoặc bị chặn.
    • Đơn luồng có nghĩa là nhiều client có thể được xử lý bởi 1 worker process duy nhất với các tài nguyên không bị chặn.
    • Nginx sinh ra các worker process, mỗi worker process có thể xử lý hàng ngàn kết nối bằng cách thực hiện một cơ chế lặp nhanh chóng để liên tục kiểm tra và xử lý các sự kiện.
    • Mỗi kết nối được xử lý bởi worker được đặt trong sự kiện vòng lặp. Bên trong vòng lặp, các sự kiện được xử lý đồng bộ, cho phép công việc được xử lý một cách không chờ đợi. Khi kết nối đóng lại thì worker process bị xóa khỏi vòng lặp.

    Với phương thức xử lý kết nối này cho phép Nginx tiến đến quy mô vô cùng xa chỉ với nguồn lực hạn chế. Vì máy chủ là đơn luồng và không tạo ra process hoặc thread mới cho mỗi request mới nên tương đối là hiệu quả, giúp giảm thiểu tài nguyên cần sử dụng.

3. Nội dung tĩnh và động

  • Các Apache server có thể xử lý nội dung tĩnh bằng cách sử dụng các phương pháp dựa trên file thông thường của nó. Hiệu suất của các hoạt động này chủ yếu phụ thuộc vào các module đa xử lý MPMs đã được trình bày ở trên.
  • Apache cũng có thể xử lý nội dung động bằng cách nhúng một bộ xử lý của ngôn ngữ trong câu hỏi vào trường hợp worker của nó. Điều này cho phép nó thực hiện nội dung động bên trong các web server của mình mà không cần phải dựa vào các thành phần bên ngoài. Các bộ vi xử lý động có thể được kích hoạt thông qua việc sử dụng các module có thể tự động load được.
  • Nginx không có khả năng xử lý các nội dung động mà chỉ phục vụ các nội dung tĩnh.
  • Để xử lý các request PHP và các request khác đối với nội dung động, Nginx phải gọi đến một bộ vi xử lý bên ngoài để thực thi và đợi khi kết quả được gửi trở lại, sau đó sẽ chuyển các kết quả này đến client. Đối với người quản trị, điều này có nghĩa là cần phải cấu hình giữa Nginx và bộ vi xử lý dựa trên những giao thức mà Nginx có thể kết nối được, bao gồm: http, FastCGI, SCGI, uWSGI, memcache. Điều này có thể là hơi phức tạp.

4. Cấu hình

  • Các file .htaccess được sử dụng trong việc cấu hình máy chủ Apache. Công dụng của file .htacess này bao gồm: rewrite URL, hạn chế truy cập, ủy quyền và xác thực, thậm chí là chính sách bộ nhớ đệm.Ưu điểm:
    • Thực thi ngay lập tức: Vì htaccess được đọc trên mọi yêu cầu, những thay đổi được thực hiện trong những tập tin này có hiệu lực ngay lập tức, trái ngược với các tập tin cấu hình chính mà đòi hỏi các máy chủ được khởi động lại thì các thiết lập mới có hiệu lực.
    • Hỗ trợ người dùng không có đặc quyền: cho phép người dùng cá nhân có khả năng thay đổi cấu hình trang web của họ trong khi các tập tin cấu hình máy chủ chính không cần phải được thay đổi.

    Nhược điểm:

    • Giảm hiệu suất: cụ thể, khi được cấu hình để sử dụng .htaccess, thì Apache sẽ tìm kiếm tất cả những folder có chứa .htaccess để thực thi, và nó sẽ thực thi tất cả những file .htaccess tìm được. Do vậy, sẽ làm website của bạn trở nên ì ạch một cách không cần thiết.
    • Bảo mật: việc cho phép người dùng cá nhân thay đổi cấu hình của một máy chủ có thể gây ra vấn đề liên quan đến bảo mật nếu không được thiết lập đúng cách.
  • Nginx không có file cấu hình .htaccess giống như ở Apache. Điều đó mang lại sự kém linh hoạt hơn nhưng cũng có lợi thế riêng của nó.
  • Cải tiến đáng chú ý nhất của .htaccess cũng như cấu hình phân cấp thư mục là giúp tăng hiệu suất. Tuy nhiên, việc tìm kiếm các thư mục có chứa .htaccess để thực thi nhiều khi khiến website của bạn trở nên ì ạch hơn. Bằng cách không cho phép ghi đè thư mục, Nginx có thể xử lý các request nhanh hơn bởi việc tìm kiếm trong 1 thư mục đơn và file đọc cho mỗi request.
  • Một lợi thế khác là về vấn đề bảo mật. Cấu hình phân cấp thư mục cho phép người dùng cá nhân thay đổi cấu hình có thể gây ra các vấn đề bảo mật. Nginx đảm bảo các quản trị viên duy trì quyển kiểm soát toàn bộ web server để ngăn ngừa các sai lầm bảo mật có thể xảy ra.

5. File và giải thích dựa trên URI

  • Do Apache được tạo ra chỉ để làm web server. Nó hoạt động chủ yếu với thư mục file hệ thống.
  • Nginx được tạo ra để làm cả web server và proxy server. Do cấu trúc cần được đáp ứng cho cả 2 vai trò này nên nó hoạt động chủ yếu với các URI, chuyển đổi các file hệ thống khi cần thiết.
  • Nginx không cung cấp cơ chế để xác định cấu hình cho 1 thư mục file hệ thống mà thay vào đó là phân tích URI của chính nó.
  • Nginx không kiểm tra file hệ thống cho đến khi nó đã sẵn sàng để phục vụ các request, điều này giải thích lý do tại sao nó không thực hiện một hình thức của các file .htaccess giống với Apache.

6. Module

  • Hệ thống module của Apache cho phép bạn tự động load hoặc không load module để áp ứng nhu cầu của bạn trong quá trình chạy các server. Phần lõi Apache luôn hiện diện, trong khi các module có thể bật hoặc tắt, thêm hoặc loại bỏ các chức năng bổ sung và gắn vào server chính.
  • Module của Apache là không giới hạn để thực hiện các nội dung động. Hơn nữa, chúng có thể được sử dụng để rewrite URL, chứng thực client, tăng độ bền cho máy chủ, đăng nhập, bộ nhớ đệm, nén, proxy, hạn chế tốc độ và mã hóa.
  • Nginx cũng thực hiện 1 hệ thống module nhưng lại khá là khác với Apache. Trong Nginx, module không load được, vì vậy chúng phải được chọn và biên dịch vào phần mềm lõi. Đối với nhiều người thì điều này không hề linh hoạt 1 chút nào. Tuy nhiên nó cũng có thể hữu ích với trường hợp bạn chỉ muốn thêm những chức năng bạn muốn vào server mà thôi.

7. Hỗ trợ, tương thích, tài liệu

  • Bởi vì Apache đã được phát triển từ rất lâu cộng với các tính năng mạnh mẽ của nó mà nguồn tài liệu của nó thực sự lớn, được hỗ trợ và tương thích với nhiều dự án, nhiều công cụ khác. Ngoài ra, các quản trị viên dường như cũng có nhiều sự quen thuộc với Apache hơn là các web server khác.
  • Nginx cũng đang nhận được nhiều sự hỗ trợ cũng như được sử dụng rộng rãi do sự hiệu quả mà nó mang lại, tuy nhiên, nó vẫn cần bắt kịp Apache ở 1 số lĩnh vực chủ chốt. Về tài liệu, trước đây, thật khó khăn để tìm tài liệu tiếng Anh về Nginx do nó được phát triển ở Nga. Ngày nay thì nguồn tài liệu đã được bổ sung đầy đủ và phong phú hơn.

III. Kết hợp Nginx và Apache

  • Rõ ràng, cả Apache và Nginx đều có những ưu và nhược điểm khác nhau, tùy vào nhu cầu sử dụng mà ta có thể lựa chọn web server nào cho phù hợp. Tuy nhiên, ta hoàn toàn có thể tận dụng thế mạnh của cả Apache và Nginx bằng cách kết hợp chúng với nhau.
  • Apache tốt hơn Nginx trong việc phục vụ các trang web động, nhưng Nginx lại tốt hơn Apache trong việc phục vụ các trang web tĩnh. Do đó, để tận dụng ưu thế của cả 2 web server này, khái niệm reverse proxy đã ra đời.
  • Ở đây, Nginx được sử dụng như 1 reverse proxy của Apache. Đối với nội dung tĩnh là lợi thế của Nginx, các file sẽ được Nginx phục vụ một cách nhanh chóng và trực tiếp cho client. Còn đối với nội dung động là lợi thế của Apache, Nginx sẽ chuyển cho Apache thực hiện sau đó trả kết quả về cho Nginx, rồi Nginx trả kết quả đó lại cho client. Nói 1 cách đơn giản hơn là dùng Nginx để xử lý tập tin tĩnh (CSS, JS, HTML, …) và dùng Apache xử lý các tập tin động (PHP,…).
  • Do bản thân Nginx rất đa nhiệm, nên việc kết hợp với Apache không hề gây ra ảnh hưởng tiêu cực nào, mà còn phát huy tối đa lợi thế của cả 2 web server này, giúp tiết kiệm tài nguyên và làm tăng tốc độ tải cho website. Hơn nữa, bằng việc giảm bớt các yêu cầu gửi đến Apache đòi xử lý sẽ làm giảm bớt sự tắc nghẽn khi các process hoặc thread của Apache bị chiếm đóng. Ngoài ra, bạn cũng có thể thêm các backend server nếu cần thiết để tăng hiệu suất và tăng khả năng phục hồi cho cấu hình.

Site Footer

Sliding Sidebar

About Me

About Me

Hello, my name is Dũng (Johnny). Welcome to my blog.

As I’m a developer, I write about topics related to the field of programming, mainly from a technical point of view. On this blog you’ll find posts which encourage discussion, information about development trends, case studies, reviews, tutorials, tips on how to improve your effectiveness, and anything else that might be fascinating to people from the IT industry.

  • http://lcdung.top/about/
  • Mail: ledung@8bitbase.com

Time line