Giúp hiểu kịch bản phía máy chủ

Theo tôi hiểu, về cơ bản có 3 tùy chọn để thực hiện kịch bản phía máy chủ hiện nay:

1. Sử dụng các ngôn ngữ kịch bản có thể được máy chủ web giải thích / thực thi trực tiếp (ví dụ: PHP và ASP), trong đó các tập lệnh được diễn giải / thực thi nhanh chóng (nghĩa là khi có yêu cầu HTTP), đầu ra được nhúng vào các trang HTML sau đó gửi lại cho khách hàng

2. Sử dụng bất kỳ ngôn ngữ nào (ví dụ: C, C ++, PERL, Python) hệ điều hành của máy chủ có khả năng thực thi (sử dụng trình thông dịch hoặc sử dụng tệp thực thi đã được biên dịch) và sau đó sử dụng CGI để giao tiếp giữa máy chủ web và HĐH . Đầu ra của các tập lệnh đi qua CGI đến máy chủ dưới dạng các trang HTML hoàn chỉnh và sau đó được gửi lại cho máy khách.

3. Sử dụng Java trên một máy chủ có thể xử lý các servlet / JSP, đó là ý tưởng khá giống với tùy chọn 1 ở trên, ngoại trừ sử dụng Java thay vì PHP / ASP.

Câu hỏi :

1. Là sự hiểu biết của tôi cho đến nay theo dõi, hoặc tôi đã nhận được một cái gì đó sai?

2. Có phải ASP và PHP là ngôn ngữ duy nhất có thể được giải thích và thực thi trực tiếp bởi một máy chủ web?

3. Ruby rơi vào đâu trong phân loại trên? Nó có thể được giải thích / thực thi bởi các máy chủ như PHP không? Hay nó giao tiếp qua CGI?

4. Liệu kịch bản phía máy chủ thông qua CGI có trở nên lỗi thời hay không?

Sự hiểu biết của bạn là chính xác, nếu bạn đến từ quá khứ. Bạn mô tả khá nhiều vì nó trông giống như vào những năm 1990.

Có, nhiều ngôn ngữ có thể được thực thi trực tiếp bởi một plugin máy chủ web. Ngay trên PHP, mod_php cho Apache vẫn là cách phổ biến nhất để lưu trữ nó. Tuy nhiên, các trang web có lưu lượng truy cập cao sử dụng cách tiếp cận hiện đại hơn, chỉ sử dụng máy chủ web làm proxy cho FastCGI (trong trường hợp PHP là PHP-FPM )

đầu ra được nhúng vào các trang HTML sau đó được gửi lại cho máy khách.

Tôi nghĩ rằng bạn đang đề cập đến đầu thập niên 90 được gọi là mã spaghetti, tuy nhiên cách tiếp cận hiện đại là sử dụng một trong nhiều khung MVC. Trong trường hợp PHP có nghĩa là ví dụ Zend Framework (có nhiều lựa chọn thay thế).

Đối với ASP, có lẽ bạn đang đề cập đến cái gọi là "ASP cổ điển", đã lỗi thời. Hiện tại, đó là ASP.NET, có thể sử dụng bất kỳ ngôn ngữ .NET nào (C # là phổ biến nhất) và dĩ nhiên là .NET framework.

C và C ++ thường không được sử dụng cho ứng dụng web. Nếu vậy, các dịch vụ như vậy được triển khai dưới dạng máy chủ độc lập, dưới dạng mô-đun cho máy chủ web hoặc FastCGI .

Perl có thể được thực thi trực tiếp từ mô đun phục vụ web bằng mod_perl . Ngoài ra còn có PSGI , về cơ bản là bản sao của WSGI của Python .

Python là ngôn ngữ rất phổ biến cho các ứng dụng web. Nó có thể được thực thi trực tiếp từ máy chủ web Apache thông qua mod_python, tuy nhiên điều đó đã lỗi thời và không được khuyến nghị. Hiện tại cách để đi với Python là thông qua mô-đun máy chủ WSGI . Máy chủ WSGI được triển khai bằng Python (ví dụ: CherryPy, WebPy) hoặc sử dụng ngăn xếp web Python độc lập (mô-đun Web của Tornado và Twisted là những ví dụ điển hình). Và tất nhiên, một lần nữa, rất có thể bạn sẽ sử dụng khung MVC tương thích WSGI , Django là phiên bản phổ biến nhất (một lần nữa, nhiều lựa chọn thay thế có sẵn).

Ruby, một lần nữa ngôn ngữ rất phổ biến cho các ứng dụng web. Nổi tiếng nhất với khung web Ruby on Rails, một lần nữa là MVC. Bạn có thể thực thi Ruby trực tiếp từ mô-đun máy chủ thông qua mod_ruby hoặc qua FastCGI .

Servlets / JSP được thực thi trong các máy chủ ứng dụng J2EE độc lập, chẳng hạn như JBoss hoặc Tomcat. Nó thường được sử dụng để thêm giao diện web vào hệ thống doanh nghiệp thay vì tạo các ứng dụng web độc lập.

CGI cổ điển (tức là quá trình sinh sản trên mỗi yêu cầu) đã trở nên lỗi thời từ nhiều năm trước. Nó đã được thay thế bởi FastCGI (nơi quá trình diễn ra lâu dài, thay vì sinh ra trên mỗi yêu cầu), các mô-đun máy chủ, giao diện như WSGI và các bản sao và các giải pháp độc lập.

Ngoài ra mô hình xử lý yêu cầu đã phát triển, với CGI, đó là quy trình cho mỗi yêu cầu. Sau đó là nhóm quy trình (hoặc nhóm luồng), mỗi quy trình (luồng) xử lý một yêu cầu tại một thời điểm. Tuy nhiên, hiện nay, hầu hết các phương pháp hiện đại là dành cho các máy chủ web và các khung độc lập để sử dụng lập trình hướng sự kiện.

Hãy để tôi mở đầu điều này bằng cách nói rằng đây là cái nhìn cực kỳ chung chung và đơn giản về những gì xảy ra.

Phần mềm máy chủ web (như Apache hoặc IIS) không diễn giải bất kỳ mã nào; nó không biết làm thế nào Tất cả những gì nó biết làm là nhận một yêu cầu, tìm kiếm nó ở một số vị trí trên hệ thống tập tin và sau đó gửi mục được yêu cầu trở lại trình duyệt. Đó là tất cả những gì nó làm - ở một mức độ rất đơn giản. Đây là lý do tại sao khi bạn cài đặt Apache và thêm một số tệp php vào DocumentRoot, bạn không nhận được kết quả PHP đã thực hiện; chỉ cần các tập tin trở lại.

Bước đầu tiên để khiến máy chủ thực hiện một việc khác ngoài phục vụ tệp là thêm mã yêu cầu máy chủ thực hiện việc khác khi yêu cầu một tệp cụ thể ; nếu không, tất cả những gì nó sẽ làm là cố gắng phục vụ tệp theo loại mime mặc định của nó (thường là văn bản / thuần túy). Đây là lý do tại sao khi bạn có một máy chủ được cấu hình không chính xác và bạn yêu cầu index.php, bạn sẽ thấy mã nguồn của tệp thay vì kết quả dự định.

Vì vậy, để có được một máy chủ web "hiểu" PHP, bạn phải cho nó biết phải làm gì khi yêu cầu một tệp có .phpphần mở rộng xuất hiện. Đây là nơi mod_phpxuất hiện. Mô-đun này giảm yêu cầu cho trình thông dịch PHP (làm thế nào có thể được cấu hình), sau đó đọc tệp, thực thi mã, biên dịch kết quả; và gửi kết quả trở lại máy chủ, từ đó cung cấp kết quả cho khách hàng. Sau đó, bạn định cấu hình máy chủ web để tất cả các tệp có .php cuối cùng phải được xử lý bởi mod_php.

Quy trình công việc cơ bản này cũng được áp dụng với các ngôn ngữ khác; sự khác biệt duy nhất là những gì máy chủ 'giảm tải' yêu cầu.

Các trường hợp cho PHP được giải thích ở trên, có tương tự là mod_python, và fastcgi, wsgivà các giao thức thiết lập khác trên yêu cầu giảm tải mà một máy chủ web không được thiết kế để xử lý.

Hầu hết các triển khai phổ biến có một quá trình chạy dài chờ đợi một yêu cầu trên một cổng (hoặc ổ cắm) cụ thể. Sau đó, máy chủ web được định cấu hình như một proxy , để nó chuyển bất kỳ yêu cầu nào khớp với một mẫu cụ thể cho quy trình chạy dài này và sau đó đọc lại kết quả.

Đây là cách ruby ​​trên đường ray (rack), script python (với wsgi) hoạt động.

Đây cũng là lý do tại sao các máy chủ web đơn giản như proxy như nginx rất phổ biến. Họ chỉ thực hiện các tác vụ rất cơ bản của một máy chủ web truyền thống - phục vụ các tệp "tĩnh" và rất giỏi trong việc giảm tải các yêu cầu đến các máy chủ proxy khác để xử lý các việc như PHP, Python, ASP, et. al.

Vì vậy, cuối cùng bạn có máy chủ web - nơi chăm sóc các tệp tĩnh, bất cứ thứ gì không cần xử lý.

Bạn có một quy trình khác, biết cách xử lý mã của bạn (ví dụ: quy trình chạy trình thông dịch PHP hoặc máy chủ uWSGI). Điều này nằm và chờ đợi các yêu cầu từ máy chủ web.

Cuối cùng, bạn có các hệ thống như người mới bắt đầu và người giám sát quản lý các quy trình này cho bạn.

Hy vọng điều này làm rõ vấn đề.

Có một lựa chọn thứ 4, được sử dụng một cách nghiêm túc nhất; các trang web như ngân hàng hoặc các dịch vụ tài chính khác: cách tiếp cận n tầng giống như CGI, ngoại trừ quy trình CGI chạy trên một máy chủ khác, mã máy chủ web rất mỏng (chỉ đủ để định dạng lại dữ liệu thành html) và gọi ' dịch vụ của cgi thông qua các giao thức mạng như RPC hoặc SOAP.

Đây vẫn là cách tiếp cận cơ bản tương tự sử dụng máy chủ web làm cổng kết nối giữa yêu cầu http được tạo bởi trình duyệt máy khách và 'công cụ mã' lưu trữ logic nghiệp vụ. Lưu ý rằng trong trường hợp này, máy chủ web sẽ chuyển yêu cầu đến một công cụ tạo tập lệnh bằng một ngôn ngữ (ví dụ: PHP hoặc XSLT) mà lần lượt gọi một dịch vụ khác cung cấp dữ liệu thô, tập lệnh web chỉ được sử dụng để định dạng dữ liệu đó thành html trang được gửi đến trình duyệt.