Apache vs Nginx: Cân nhắc thực tế
Apache và Nginx là hai web server open-souce phổ biến nhất trên thế giới. Cùng nhau, chúng chịu trách nhiệm phục vụ hơn 50% lưu lượng truy cập trên internet. Cả hai giải pháp đều có khả năng xử lý dung lượng công việc đa dạng và làm việc với phần mềm khác để cung cấp một ngăn xếp web hoàn chỉnh.Mặc dù Apache và Nginx chia sẻ nhiều phẩm chất, nhưng chúng không nên được coi là hoàn toàn có thể thay thế cho nhau. Mỗi loại vượt trội theo cách riêng của nó và điều quan trọng là phải hiểu các tình huống mà bạn có thể cần phải đánh giá lại web server của bạn mà bạn lựa chọn. Bài viết này sẽ được dành cho thảo luận về cách mỗi server xếp chồng lên nhau trong các lĩnh vực khác nhau.
Tổng quan chung
Trước khi ta đi sâu vào sự khác biệt giữa Apache và Nginx, ta hãy xem nhanh nền tảng của hai dự án này và đặc điểm chung của chúng.
Apache
Server Apache HTTP được tạo ra bởi Robert McCool vào năm 1995 và đã được phát triển dưới sự chỉ đạo của Apache Software Foundation từ năm 1999. Vì web server HTTP là dự án ban đầu của nền tảng và cho đến nay là phần mềm phổ biến nhất của họ, nó thường được gọi đơn giản là “Apache”.
Web server Apache là server phổ biến nhất trên internet kể từ năm 1996. Vì sự phổ biến này, Apache được hưởng lợi từ tài liệu tuyệt vời và hỗ trợ tích hợp từ các dự án phần mềm khác.
Apache thường được các administrator lựa chọn vì tính linh hoạt, sức mạnh và sự hỗ trợ rộng rãi. Nó có thể mở rộng thông qua một hệ thống module có thể tải động và có thể xử lý một số lượng lớn các ngôn ngữ thông dịch mà không cần kết nối với phần mềm riêng biệt.
Nginx
Năm 2002, Igor Sysoev bắt đầu nghiên cứu Nginx như một câu trả lời cho vấn đề C10K, đây là một thách thức đối với các web server để bắt đầu xử lý mười nghìn kết nối đồng thời như một yêu cầu cho web hiện đại. Bản phát hành công khai đầu tiên được thực hiện vào năm 2004, đáp ứng mục tiêu này bằng cách dựa trên kiến trúc hướng sự kiện, không đồng bộ.
Nginx đã trở nên phổ biến kể từ khi phát hành do sử dụng tài nguyên trọng lượng nhẹ và khả năng mở rộng quy mô dễ dàng trên phần cứng tối thiểu. Nginx vượt trội trong việc phân phối nội dung tĩnh một cách nhanh chóng và được thiết kế để chuyển các yêu cầu động sang phần mềm khác phù hợp hơn cho các mục đích đó.
Nginx thường được các administrator lựa chọn vì hiệu quả tài nguyên và khả năng đáp ứng khi tải. Những người ủng hộ hoan nghênh sự tập trung của Nginx vào web server cốt lõi và các tính năng proxy.
Kiến trúc xử lý kết nối
Một sự khác biệt lớn giữa Apache và Nginx là cách chúng xử lý các kết nối và lưu lượng truy cập thực tế. Điều này có lẽ cung cấp sự khác biệt đáng kể nhất trong cách họ phản ứng với các điều kiện giao thông khác nhau.
Apache
Apache cung cấp nhiều module đa xử lý khác nhau (Apache gọi các MPM này) quy định cách xử lý các yêu cầu của khách hàng. Về cơ bản, điều này cho phép administrator swap kiến trúc xử lý kết nối của nó một cách dễ dàng. Đó là:
- mpm_prefork : Mô-đun xử lý này tạo ra các quy trình với một stream duy nhất, mỗi quy trình để xử lý yêu cầu. Mỗi đứa trẻ có thể xử lý một kết nối duy nhất tại một thời điểm. Miễn là số lượng yêu cầu ít hơn số lượng quy trình, MPM này rất nhanh.Tuy nhiên, hiệu suất giảm nhanh chóng sau khi yêu cầu vượt quá số lượng quy trình, vì vậy đây không phải là một lựa chọn tốt trong nhiều trường hợp. Mỗi quá trình đều có tác động đáng kể đến mức tiêu thụ RAM, vì vậy MPM này khó có thể mở rộng hiệu quả. Mặc dù vậy, đây vẫn có thể là một lựa chọn tốt nếu được sử dụng cùng với các thành phần khác không được xây dựng với chủ đề. Ví dụ: PHP không an toàn theo stream , vì vậy MPM này được khuyến khích là cách an toàn duy nhất để làm việc với
mod_php, module Apache để xử lý các file này. - mpm_worker : Mô-đun này sinh ra các quy trình mà mỗi quy trình có thể quản lý nhiều stream . Mỗi stream này có thể xử lý một kết nối duy nhất. Luồng hiệu quả hơn nhiều so với quy trình, nghĩa là MPM này mở rộng quy mô tốt hơn MPM làm việc trước. Vì có nhiều stream hơn các quy trình, điều này cũng nghĩa là các kết nối mới có thể nhận ngay một stream miễn phí thay vì phải đợi một quy trình miễn phí.
- mpm_event : Mô-đun này tương tự như module worker trong hầu hết các tình huống, nhưng được tối ưu hóa để xử lý các kết nối tồn tại. Khi sử dụng worker MPM, một kết nối sẽ giữ một stream dù yêu cầu có đang được thực hiện tích cực hay không miễn là kết nối được duy trì. Sự kiện MPM xử lý giữ các kết nối còn tồn tại bằng cách dành ra các stream chuyên dụng để xử lý các kết nối còn tồn tại và chuyển các yêu cầu hoạt động sang các stream khác. Điều này giúp module không bị sa lầy bởi các yêu cầu duy trì, cho phép thực thi nhanh hơn. Điều này được đánh dấu là ổn định với việc phát hành Apache 2.4.
Như bạn thấy , Apache cung cấp một kiến trúc linh hoạt để lựa chọn các thuật toán xử lý yêu cầu và kết nối khác nhau. Các lựa chọn được cung cấp chủ yếu là một chức năng của sự phát triển của server và nhu cầu ngày càng tăng về tính đồng thời khi bối cảnh internet đã thay đổi.
Nginx
Nginx xuất hiện sau Apache, với nhận thức rõ ràng hơn về các vấn đề đồng thời sẽ phải đối mặt với các trang web trên quy mô lớn. Tận dụng kiến thức này, Nginx đã được thiết kế ngay từ đầu để sử dụng thuật toán xử lý kết nối theo hướng sự kiện, không đồng bộ, không chặn.
Nginx tạo ra các quy trình công nhân, mỗi quy trình có thể xử lý hàng nghìn kết nối. Các quy trình công nhân thực hiện điều này bằng cách triển khai cơ chế lặp nhanh liên tục kiểm tra và xử lý các sự kiện. Việc tách công việc thực tế khỏi các kết nối cho phép mỗi công nhân chỉ quan tâm đến kết nối khi một sự kiện mới đã được kích hoạt.
Mỗi kết nối do worker xử lý được đặt trong vòng lặp sự kiện, nơi chúng tồn tại với các kết nối khác. Trong vòng lặp, các sự kiện được xử lý không đồng bộ, cho phép xử lý công việc theo cách không chặn. Khi kết nối đóng, nó sẽ bị xóa khỏi vòng lặp.
Phong cách xử lý kết nối này cho phép Nginx mở rộng quy mô cực kỳ xa với tài nguyên hạn chế. Vì server là một stream và các quy trình không được tạo ra để xử lý từng kết nối mới, nên việc sử dụng bộ nhớ và CPU có xu hướng duy trì tương đối nhất quán, ngay cả khi tải nặng.
Nội dung tĩnh so với động
Về trường hợp sử dụng trong thế giới thực, một trong những so sánh phổ biến nhất giữa Apache và Nginx là cách mỗi server xử lý các yêu cầu đối với nội dung tĩnh và động.
Apache
Server Apache có thể xử lý nội dung tĩnh bằ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 là một chức năng của các phương pháp MPM được mô tả ở trên.
Apache cũng có thể xử lý nội dung động bằng cách nhúng một bộ xử lý ngôn ngữ được đề cập vào từng version worker của nó. Điều này cho phép nó thực thi nội dung động trong chính web server mà không cần phải dựa vào các thành phần bên ngoài. Các bộ xử lý động này có thể được kích hoạt thông qua việc sử dụng các module có thể tải động.
Khả năng xử lý nội dung động của Apache nghĩa là cấu hình của xử lý động có xu hướng đơn giản hơn. Giao tiếp không cần phải được phối hợp với một phần mềm bổ sung và các module có thể dễ dàng được swap nếu yêu cầu nội dung thay đổi.
Nginx
Nginx không có bất kỳ khả năng xử lý nội dung động nào. Để PHP processor và các yêu cầu khác đối với nội dung động, Nginx phải chuyển cho bộ xử lý bên ngoài để thực thi và đợi nội dung được hiển thị được gửi lại. Sau đó, kết quả có thể được chuyển tới client .
Đối với administrator , điều này nghĩa là giao tiếp phải được cấu hình giữa Nginx và bộ xử lý qua một trong các giao thức mà Nginx biết cách nói (http, FastCGI, SCGI, uWSGI, memcache). Điều này có thể làm phức tạp thêm một chút, đặc biệt là khi cố gắng dự đoán số lượng kết nối cho phép, vì một kết nối bổ sung sẽ được sử dụng cho mỗi cuộc gọi đến bộ xử lý.
Tuy nhiên, phương pháp này cũng có một số ưu điểm. Vì trình thông dịch động không được nhúng trong quy trình công nhân, chi phí của nó sẽ chỉ hiển thị cho nội dung động. Nội dung tĩnh có thể được cung cấp một cách trực tiếp và người thông dịch sẽ chỉ được liên hệ khi cần thiết. Apache cũng có thể hoạt động theo cách này, nhưng làm như vậy sẽ loại bỏ các lợi ích trong phần trước.
Cấu hình phân tán so với tập trung
Đối với administrator , một trong những điểm khác biệt rõ ràng nhất giữa hai phần mềm này là liệu cấu hình cấp folder có được phép trong các folder nội dung hay không.
Apache
Apache bao gồm một tùy chọn để cho phép cấu hình bổ sung trên cơ sở từng folder bằng cách kiểm tra và diễn giải các chỉ thị trong các file ẩn trong chính các folder nội dung. Các file này được gọi là .htaccess .
Vì các file này nằm trong chính các folder nội dung, nên khi xử lý một yêu cầu, Apache sẽ kiểm tra từng thành phần của đường dẫn đến file được yêu cầu để tìm .htaccess và áp dụng các chỉ thị được tìm thấy bên trong. Điều này cho phép một cách hiệu quả cấu hình phi tập trung của web server , thường được sử dụng để thực hiện ghi lại URL, hạn chế truy cập, ủy quyền và xác thực, thậm chí cả policy bộ nhớ đệm.
Mặc dù các ví dụ trên đều có thể được cấu hình trong file cấu hình Apache chính, nhưng .htaccess có một số ưu điểm quan trọng. Đầu tiên, vì chúng được diễn giải mỗi khi chúng được tìm thấy dọc theo đường dẫn yêu cầu, chúng được thực hiện ngay lập tức mà không cần reload server . Thứ hai, nó có thể cho phép user không có quyền kiểm soát các khía cạnh nhất định của nội dung web của riêng họ mà không cho phép họ kiểm soát toàn bộ file cấu hình.
Điều này cung cấp một cách dễ dàng cho một số phần mềm web, như hệ thống quản lý nội dung, để cấu hình môi trường của chúng mà không cần cung cấp quyền truy cập vào file cấu hình trung tâm.Điều này cũng được các nhà cung cấp dịch vụ lưu trữ chia sẻ sử dụng để giữ quyền kiểm soát cấu hình chính trong khi cho phép khách hàng kiểm soát các folder cụ thể của họ.
Nginx
Nginx không diễn giải các .htaccess , cũng như không cung cấp bất kỳ cơ chế nào để đánh giá cấu hình từng folder bên ngoài file cấu hình chính. Điều này có thể kém linh hoạt hơn so với mô hình Apache, nhưng nó có những lợi thế riêng.
Cải tiến đáng chú ý nhất so với hệ thống .htaccess của cấu hình cấp folder là tăng hiệu suất. Đối với cài đặt Apache điển hình có thể cho phép .htaccess trong bất kỳ folder nào, server sẽ kiểm tra các file này trong từng folder mẹ dẫn đến file được yêu cầu, cho mỗi yêu cầu. Nếu một hoặc nhiều .htaccess được tìm thấy trong quá trình tìm kiếm này, chúng phải được đọc và diễn giải. Bằng cách không cho phép overrides folder , Nginx có thể phục vụ các yêu cầu nhanh hơn bằng cách
thực hiện tra cứu folder duy nhất và đọc file cho mỗi yêu cầu (giả sử rằng file được tìm thấy trong cấu trúc folder thông thường).
Một lợi thế khác là liên quan đến bảo mật. Phân phối quyền truy cập cấu hình mức folder cũng phân phối trách nhiệm bảo mật cho user cá nhân, những người có thể không được tin cậy để xử lý tốt tác vụ này. Đảm bảo rằng administrator duy trì quyền kiểm soát đối với toàn bộ web server có thể ngăn chặn một số sơ suất bảo mật có thể xảy ra khi quyền truy cập được cấp cho các bên khác.
Lưu ý bạn có thể tắt giải thích .htaccess trong Apache nếu những lo ngại này phù hợp với bạn.
Giải thích dựa trên file so với URI
Cách web server diễn giải các yêu cầu và ánh xạ chúng tới các tài nguyên thực tế trên hệ thống là một lĩnh vực khác mà hai server này khác nhau.
Apache
Apache cung cấp khả năng diễn giải yêu cầu dưới dạng tài nguyên vật lý trên hệ thống file hoặc vị trí URI có thể cần đánh giá trừu tượng hơn. Nói chung, đối với Apache trước đây sử dụng các khối <Directory> hoặc <Files> , trong khi nó sử dụng các khối <Location> cho nhiều tài nguyên trừu tượng hơn.
Bởi vì Apache được thiết kế từ đầu như một web server , mặc định thường là giải thích các yêu cầu dưới dạng tài nguyên hệ thống file . Nó bắt đầu bằng cách lấy root tài liệu và thêm phần yêu cầu theo sau số server và cổng để cố gắng tìm một file thực. Về cơ bản, phân cấp hệ thống file được biểu diễn trên web dưới dạng cây tài liệu có sẵn.
Apache cung cấp một số lựa chọn thay thế khi yêu cầu không trùng với hệ thống file bên dưới. Ví dụ: một chỉ thị Alias được dùng để ánh xạ đến một vị trí thay thế. Sử dụng khối <Location> là một phương pháp làm việc với chính URI thay vì hệ thống file . Ngoài ra còn có các biến thể biểu thức chính quy được dùng để áp dụng cấu hình linh hoạt hơn trong toàn bộ hệ thống file .
Mặc dù Apache có khả năng hoạt động trên cả hệ thống file bên dưới và không gian web, nhưng nó lại nghiêng nhiều về các phương thức hệ thống file . Điều này có thể được nhìn thấy trong một số quyết định thiết kế, bao gồm cả việc sử dụng .htaccess cho cấu hình mỗi folder . Bản thân các tài liệu Apache cảnh báo không sử dụng các khối dựa trên URI để hạn chế quyền truy cập khi yêu cầu phản ánh hệ thống file bên dưới.
Nginx
Nginx được tạo ra để vừa là web server vừa là server proxy. Do kiến trúc cần thiết cho hai role này, nó hoạt động chủ yếu với URI, dịch sang hệ thống file khi cần thiết.
Có thể thấy điều này theo một số cách mà file cấu hình Nginx được xây dựng và diễn giải.Nginx không cung cấp cơ chế chỉ cấu hình cho folder hệ thống file và thay vào đó phân tích cú pháp chính URI.
Ví dụ, các đoạn cấu hình chính cho Nginx là các khối server và location . Khối server thông dịch server được yêu cầu, trong khi các khối location chịu trách nhiệm khớp các phần của URI xuất hiện sau server và cổng. Đến đây, yêu cầu đang được hiểu là một URI, không phải là một vị trí trên hệ thống file .
Đối với các file tĩnh, tất cả các yêu cầu cuối cùng phải được ánh xạ tới một vị trí trên hệ thống file . Đầu tiên, Nginx chọn server và khối vị trí sẽ xử lý yêu cầu và sau đó kết hợp root tài liệu với URI, điều chỉnh bất kỳ thứ gì cần thiết theo cấu hình được chỉ định.
Điều này có vẻ tương tự, nhưng phân tích cú pháp các yêu cầu chủ yếu dưới dạng URI thay vì vị trí hệ thống file cho phép Nginx hoạt động dễ dàng hơn trong cả role web, thư và server proxy. Nginx được cấu hình đơn giản bằng cách đặt ra cách phản hồi các mẫu yêu cầu khác nhau. Nginx không kiểm tra hệ thống file cho đến khi nó sẵn sàng phục vụ yêu cầu, điều này giải thích tại sao nó không triển khai một dạng .htaccess .
Mô-đun
Cả Nginx và Apache đều có thể mở rộng thông qua các hệ thống module , nhưng cách chúng hoạt động khác nhau đáng kể.
Apache
Hệ thống module của Apache cho phép bạn tự động tải hoặc dỡ các module để đáp ứng nhu cầu của bạn trong quá trình chạy server . Lõi Apache luôn hiện diện, trong khi các module có thể được bật hoặc tắt, thêm hoặc bớt chức năng bổ sung và kết nối vào server chính.
Apache sử dụng chức năng này cho nhiều tác vụ khác nhau. Do sự trưởng thành của nền tảng, có sẵn một thư viện rộng rãi gồm các module . Chúng được dùng để thay đổi một số chức năng cốt lõi của server , chẳng hạn như mod_php , nhúng một trình thông dịch PHP vào mỗi nhân viên đang chạy.
Tuy nhiên, các module không bị giới hạn trong việc xử lý nội dung động. Trong số các chức năng khác, chúng được dùng để viết lại URL, xác thực client , củng cố server , ghi log , lưu vào bộ nhớ đệm, nén, ủy quyền, giới hạn tốc độ và mã hóa. Các module động có thể mở rộng đáng kể chức năng cốt lõi mà không cần thêm nhiều công việc.
Nginx
Nginx cũng triển khai một hệ thống module , nhưng nó khá khác so với hệ thống Apache. Trong Nginx, các module không thể tải động, vì vậy chúng phải được chọn và biên dịch thành phần mềm cốt lõi.
Đối với nhiều user , điều này sẽ làm cho Nginx kém linh hoạt hơn nhiều. Điều này đặc biệt đúng đối với những user không cảm thấy thoải mái khi duy trì phần mềm đã biên dịch của riêng họ bên ngoài trình cài đặt gói thông thường của nhà phân phối. Trong khi các gói của bản phân phối có xu hướng bao gồm các module được sử dụng phổ biến nhất, nếu bạn yêu cầu một module không chuẩn, bạn sẽ phải tự xây dựng server từ nguồn.
Mặc dù vậy, các module Nginx vẫn rất hữu ích và chúng cho phép bạn ra lệnh cho những gì bạn muốn từ server của bạn bằng cách chỉ bao gồm chức năng bạn định sử dụng. Một số user cũng có thể coi điều này an toàn hơn, vì không thể nối các thành phần tùy ý vào server . Tuy nhiên, nếu server của bạn đã từng được đặt ở vị trí có thể thực hiện được, thì nó có thể đã bị xâm phạm.
Các module Nginx cho phép nhiều khả năng giống như các module Apache. Ví dụ: các module Nginx có thể cung cấp hỗ trợ proxy, nén, giới hạn tốc độ, ghi log , viết lại, định vị địa lý, xác thực, mã hóa, phát trực tuyến và chức năng thư.
Hỗ trợ, Tương thích, Hệ sinh thái và Tài liệu
Một điểm chính cần xem xét là quá trình cài đặt và chạy thực tế sẽ như thế nào với bối cảnh trợ giúp và hỗ trợ sẵn có giữa các phần mềm khác.
Apache
Bởi vì Apache đã phổ biến từ lâu nên việc hỗ trợ cho server là khá phổ biến. Có một thư viện lớn tài liệu của bên thứ nhất và thứ ba dành cho server lõi và cho các tình huống dựa trên tác vụ liên quan đến việc kết nối Apache với phần mềm khác.
Cùng với tài liệu hướng dẫn, nhiều công cụ và dự án web bao gồm các công cụ để tự khởi động trong môi trường Apache. Điều này có thể được đưa vào chính các dự án hoặc trong các gói do group đóng gói của nhà phân phối của bạn duy trì.
Nhìn chung, Apache sẽ nhận được nhiều sự hỗ trợ hơn từ các dự án của bên thứ ba chỉ vì thị phần và thời gian tồn tại của nó. Các administrator cũng có nhiều khả năng có kinh nghiệm làm việc với Apache hơn không chỉ do tính phổ biến của nó mà còn vì nhiều người bắt đầu trong các tình huống chia sẻ lưu trữ hầu như chỉ dựa vào Apache do khả năng quản lý phân tán .htaccess .
Nginx
Nginx đang nhận được sự hỗ trợ ngày càng tăng khi nhiều user chấp nhận nó cho profile hiệu suất của nó, nhưng nó vẫn còn một số vấn đề cần làm trong một số lĩnh vực chính.
Trước đây, rất khó để tìm tài liệu toàn diện bằng tiếng Anh về Nginx do hầu hết các tài liệu và bản phát triển ban đầu đều bằng tiếng Nga. Khi sự quan tâm đến dự án ngày càng tăng, tài liệu đã được điền đầy đủ và hiện có rất nhiều tài nguyên quản trị trên trang Nginx và thông qua các bên thứ ba.
Liên quan đến các ứng dụng của bên thứ ba, hỗ trợ và tài liệu đang trở nên sẵn có hơn và những người bảo trì gói, trong một số trường hợp, đang bắt đầu đưa ra các lựa chọn giữa tự động cấu hình cho Apache và Nginx. Ngay cả khi không được hỗ trợ, việc cấu hình Nginx để hoạt động với phần mềm thay thế thường dễ dàng thực hiện miễn là bản thân dự án ghi lại các yêu cầu của nó (quyền, tiêu đề, v.v.).
Sử dụng Apache và Nginx cùng nhau
Sau khi xem qua các lợi ích và hạn chế của cả Apache và Nginx, bạn có thể có ý tưởng tốt hơn về server nào phù hợp hơn với nhu cầu của bạn . Tuy nhiên, nhiều user thấy rằng có thể tận dụng điểm mạnh của từng server bằng cách sử dụng chúng cùng nhau.
Cấu hình thông thường cho quan hệ đối tác này là đặt Nginx trước Apache như một Reverse Proxy . Điều này sẽ cho phép Nginx xử lý tất cả các yêu cầu từ khách hàng. Điều này tận dụng lợi thế của tốc độ xử lý nhanh của Nginx và khả năng xử lý số lượng lớn kết nối đồng thời.
Đối với nội dung tĩnh, mà Nginx vượt trội, các file sẽ được phân phát nhanh chóng và trực tiếp cho khách hàng. Đối với nội dung động, chẳng hạn như các file PHP, Nginx sẽ ủy quyền yêu cầu tới Apache, sau đó có thể xử lý kết quả và trả về trang được kết xuất. Sau đó, Nginx có thể chuyển nội dung trở lại client .
Cài đặt này hoạt động tốt đối với nhiều người vì nó cho phép Nginx hoạt động như một máy phân loại. Nó sẽ xử lý tất cả các yêu cầu mà nó có thể và chuyển những yêu cầu mà nó không có khả năng phục vụ. Bằng cách cắt giảm các yêu cầu mà server Apache được yêu cầu xử lý, ta có thể giảm bớt một số chặn xảy ra khi một quy trình hoặc stream Apache bị chiếm dụng.
Cấu hình này cũng cho phép bạn mở rộng quy mô bằng cách thêm các server backend bổ sung nếu cần. Nginx có thể được cấu hình để chuyển đến một group server dễ dàng, tăng khả năng phục hồi của cấu hình này đối với lỗi và hiệu suất.
Kết luận
Như bạn thấy , cả Apache và Nginx đều mạnh mẽ, linh hoạt và có khả năng. Quyết định server nào tốt nhất cho bạn phần lớn là một chức năng đánh giá các yêu cầu cụ thể của bạn và thử nghiệm với các mẫu mà bạn mong đợi.
Có sự khác biệt giữa các dự án này có tác động rất thực tế đến hiệu suất thô, khả năng và thời gian thực hiện cần thiết để bắt đầu và vận hành từng giải pháp. Tuy nhiên, những điều này thường là kết quả của một loạt các đánh đổi mà không nên tùy tiện loại bỏ. Cuối cùng, không có web server nào phù hợp với tất cả, vì vậy hãy sử dụng giải pháp phù hợp nhất với mục tiêu của bạn.
Các tin liên quan
Cách cài đặt một Apache, MySQL và PHP (FAMP) trên FreeBSD 10.12015-01-14
Cách cài đặt WordPress với Apache trên FreeBSD 10.1
2015-01-14
Cách triển khai ứng dụng Rails với Passenger và Apache trên Ubuntu 14.04
2014-11-21
Cách sử dụng JRuby để chạy ứng dụng Rails trên Apache Tomcat 7 và Ubuntu 14.04
2014-11-14
Cách cấu hình quyền truy cập WebDAV với Apache trên Ubuntu 14.04
2014-09-22
Cách cài đặt và bảo mật phpMyAdmin với Apache trên server CentOS 7
2014-08-07
Cách sử dụng Apache JMeter để thực hiện kiểm tra tải trên web server
2014-06-24
Cách cấu hình OCSP Stapling trên Apache và Nginx
2014-06-12
Cách tạo chứng chỉ SSL trên Apache cho Ubuntu 14.04
2014-04-23
Cách thiết lập server ảo Apache trên Ubuntu 14.04 LTS
2014-04-22
