Giải thích về cách truy cập ngôn ngữ lập trình phía máy chủ

Theo hiểu biết của tôi, bất kỳ ngôn ngữ lập trình đa năng nào cũng có thể được sử dụng để phát triển phía máy chủ của trang web.

Tôi có đúng không khi nghĩ rằng một máy chủ chỉ cần một số loại giao diện như CGI để làm cho máy chủ và ngôn ngữ lập trình hoạt động cùng nhau? Nếu vậy thì tại sao một số ngôn ngữ lập trình (như php) phổ biến hơn các ngôn ngữ khác?

Trong những ngày đầu của web, CGI thực sự là cách duy nhất (thực tế) để có nội dung động (bạn có thể đặt tên các tệp của tệp - và chúng được sử dụng trong những ngày trước cgi, nhưng điều đó không thực tế).

CGI hoạt động bằng cách dán một loạt thông tin trong môi trường của quá trình được rẽ nhánh và sau đó được thực thi (và có thể một số trong stdin) và sau đó lấy những gì ra khỏi thiết bị xuất chuẩn và gửi lại cho người yêu cầu.

Điều này không quan tâm một chút về ngôn ngữ thực hiện là gì. Thật vậy, tôi đã viết CGI đầu tiên của tôi trở lại trong ngày bằng C hoặc C ++. Đó là loại đau đớn. Sau đó tôi đã học được một số perl vào đầu những năm 90 và điều đó ít đau đớn hơn nhiều.

Điều này hoạt động, lên đến một điểm. Vấn đề là quy mô. Mỗi yêu cầu CGI là một ngã ba và thực hiện một quy trình. Hàng ngàn yêu cầu có nghĩa là hàng ngàn quá trình. Điều đó thực sự không hoạt động tốt.

Giải pháp cho vấn đề này là loại bỏ việc giả mạo và thực thi bằng cách di chuyển nó vào một luồng trong chính máy chủ web hoặc gửi yêu cầu đến một quy trình khác xử lý yêu cầu mà không cần rẽ nhánh và thực thi. mod_perl là một trong những công cụ như vậy để làm điều này (một plugin chuyển perl thành apache). Php (cuối những năm 90) cũng đã làm điều này với việc triển khai ngôn ngữ như một plugin trong chính máy chủ web chứ không phải là thứ gì đó đã bị rẽ nhánh và vượt quá. Điều này trở nên khá phổ biến vì nó giống như perl (vốn là ngôn ngữ lập trình web thống trị ban đầu) và có thể vượt trội hơn perl cgis. Vẫn còn khá nhiều động lực từ thời kỳ này vào giữa những năm 90 - trước khi các máy chủ ứng dụng cấp doanh nghiệp bắt đầu nắm giữ các ngôn ngữ chính thức hơn đằng sau chúng. Nếu bạn đào xung quanh,

Điều này đưa chúng ta đến các máy chủ ứng dụng nơi các luồng nội bộ được sinh ra (hoặc các cách tiếp cận khác - đây không phải là trường hợp của mọi thứ) để xử lý các yêu cầu thay vì toàn bộ các quy trình mới - có thể giúp mở rộng quy mô. Là một quá trình bên ngoài, điều này có thể được nhìn thấy với FastCGI và sau đó trở nên phổ biến với các máy chủ ứng dụng khác. Lưu ý rằng với điều này, đường giữa máy chủ ứng dụng và máy chủ web có một chút mờ - nhiều máy chủ ứng dụng có thể tăng gấp đôi so với máy chủ web, mặc dù không được tối ưu hóa để xử lý IO tệp tĩnh theo cách mà các máy chủ web truyền thống.

Máy chủ ứng dụng chung cũng đã mở đường cho các giải pháp thay vì máy chủ ứng dụng chung , bạn có chính ứng dụng đó đang chạy một máy chủ web nhúng hoặc nói cách khác là toàn bộ triển khai. Trong những tình huống như vậy, người ta không triển khai một ứng dụng web trên một máy chủ ứng dụng - nó chỉ tự chạy và xử lý các yêu cầu. Một lần nữa, mục tiêu của mô hình này là để tránh giá đắt khi tung ra các phiên bản mới của ứng dụng và thay vào đó xử lý các yêu cầu bên trong ứng dụng bằng các luồng trọng lượng nhẹ hơn nhiều hoặc các cách tiếp cận tương tự.

Mặc dù vậy, đây là điều - tất cả các giải pháp đều thiếu theo một cách nào đó, hình dạng hoặc hình thức. CGI, trong khi dễ dàng có vấn đề nghiêm trọng với quy mô. Các plugin trong máy chủ web bị ràng buộc vào chính máy chủ web (apache vs nginx vs IIS vs ...) và mất chức năng chung của ngôn ngữ. Microsoft có cuộc diễu hành công nghệ riêng mà họ muốn quảng bá. Và nếu bạn biết một ngôn ngữ, bạn có muốn tiếp tục lập trình trong ngôn ngữ đó thay vì có các ngôn ngữ khác nhau trong các phần khác nhau của ngăn xếp (javascript trong ứng dụng khách và Node.js) không?

Và vì vậy, bạn đã có ngày hôm nay. Một số người làm việc trong một ngăn xếp Java (với scala và clojure trở nên không phổ biến). Những người khác trong ngăn xếp C #. Những người khác trong một ngăn xếp JavaScript. Có khá nhiều ngăn xếp php ngoài kia. Rất nhiều trăn. Bạn vẫn có thể tìm thấy một số ngăn xếp perl ngoài đó (và nếu bạn xem một số trang web có khối lượng thấp, bạn vẫn sẽ tìm thấy CGI). Với điện toán đám mây, Google cũng đã quảng bá Go như một ngôn ngữ web phía máy chủ khả thi.

Mỗi cái đều có ưu điểm, nhược điểm, khung và máy chủ. Sự phổ biến tương đối của những dòng chảy và dòng chảy này khi các công nghệ xung quanh chúng thay đổi. Họ làm những điều khác nhau tốt.

Có, bất kỳ ngôn ngữ lập trình chung nào cũng có thể dùng để viết phần phía máy chủ của trang web.

Tuy nhiên, phẩm chất của một ngôn ngữ lập trình, trong chủ đề này cũng như trong những thứ khác, thường chỉ là một trong nhiều yếu tố góp phần vào sự phổ biến của nó.

Ví dụ: tôi cho rằng PHP đã trở nên phổ biến cho các trang web vì:

• Việc nâng cấp từ một trang web tĩnh thành một trang web động PHP cực kỳ dễ dàng - chỉ cần thay thế phần mở rộng tệp của tệp HTML của bạn, đặt <?phpthẻ ở đầu và, với điều kiện PHP được cài đặt, bạn có một trang web động! Phần còn lại của quy trình làm việc hoàn toàn giống với một trang web tĩnh;
• Do tính dễ triển khai đó, các máy chủ web đang tìm cách đề xuất các trang web động đã chọn PHP, làm cho nó trở thành nền tảng phía máy chủ được triển khai rộng rãi nhất;
• Nó đã vào thị trường đó vào đúng thời điểm;

Và một khi PHP được triển khai rộng rãi, việc viết các ứng dụng web nghiêm túc hơn trong PHP trở nên thú vị để hưởng lợi từ sự triển khai rộng rãi đó.

Nói một cách chung chung hơn: việc áp dụng ngôn ngữ thường là về câu trả lời cho những câu hỏi sau:

• Làm thế nào dễ dàng để làm những gì tôi muốn làm?
• Làm thế nào được hỗ trợ rộng rãi là ngôn ngữ cho những gì tôi muốn làm?

Tôi có đúng không khi nghĩ rằng một máy chủ chỉ cần một số loại giao diện như CGI để làm cho máy chủ và ngôn ngữ lập trình hoạt động cùng nhau?

Hầu hết. Bạn cần một máy chủ web có một số loại phần mềm để cho phép nó đáp ứng các yêu cầu HTTP.

Hãy suy nghĩ về cách một trang tĩnh được phục vụ. Máy chủ truy xuất yêu cầu HTTP, tìm tài liệu được yêu cầu từ hệ thống tệp dựa trên cấu hình của máy chủ HTTP và trả về trang tĩnh.

CGI mở rộng khái niệm này bằng cách cho phép bạn chỉ định thư mục cgi-bin trên hệ thống tệp nơi tệp thực thi hoặc tập lệnh có thể được lưu trữ. Khi bạn truy cập một chương trình thông qua CGI, máy chủ HTTP sẽ chạy quy trình hoặc tập lệnh và chuyển đầu ra tiêu chuẩn trở lại máy khách thay vì chỉ phục vụ tài liệu tĩnh.

 If so then why are some programming languages (such as php) more popular than others?

Cấu trúc CGI cũ không mở rộng tốt trong một khối lượng lớn yêu cầu. Các ngôn ngữ lập trình và khung khác nhau cho web tồn tại vì những lý do khác nhau và mỗi người làm tốt những việc khác nhau. PHP phổ biến như nó là vì lý do lịch sử, vì nó là một trong những giải pháp dễ dàng và rẻ tiền đầu tiên để phục vụ các trang động mà không cần dùng đến CGI và có hỗ trợ lưu trữ rộng rãi. ASP rất phổ biến trong giới Microsoft vì nó cho phép các nhà phát triển VB chuyển các kỹ năng của họ sang web. ASP.NET (Web Forms) đã giúp các nhà phát triển Windows Forms rất dễ dàng, nhiều người trong số họ là lập trình viên VB, chuyển sang web.

Khi một trình duyệt thực hiện một yêu cầu HTTP, nó sẽ trông như thế này:

GET /search?q=cats HTTP/1.0
Host: www.google.com
Connection: close

Máy chủ mà máy chủ sẽ gửi phản hồi giống như thế này:

HTTP/1.0 200 Success
Content-Type: text/html; charset=UTF-8
Content-Length: 1337

<!DOCTYPE html>
<html>
  <head><title>cats - Google Search</title>
  <body>
    <h1>About 415,000,000 results</h1>
    …
  </body>
</html>

Bất kỳ mã nào chạy trên máy chủ lắng nghe yêu cầu trên ổ cắm TCP, đọc yêu cầu và trả lời với phản hồi thích hợp sẽ đủ. Một cách ngu ngốc là chỉ đưa ra phản hồi đóng hộp cho bất kỳ ai kết nối với cổng TCP 80, sử dụng tập lệnh shell:

$ nc -l 8000 <<'RESPONSE'
HTTP/1.0 200 Success
Content-Type: text/html; charset=UTF-8
Content-Length: 1337

<!DOCTYPE html>
<html>
  <head><title>cats - Google Search</title>
  <body>
    <h1>About 415,000,000 results</h1>
    …
  </body>
</html>
RESPONSE

Tất nhiên, kỹ thuật đó chỉ xuất hiện để tuân thủ giao thức HTTP .

Một bước tiến từ phản ứng đóng hộp đó là chương trình Python đơn giản này, sử dụng http.serverthư viện trong Python 3.

#!/usr/bin/python3

import http.server

class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        payload = '<!DOCTYPE html>... insert cats here ...'.encode('UTF-8')
        self.send_response(200)
        self.send_header('Content-Type', 'text/html; charset=UTF-8')
        self.send_header('Content-Length', len(payload))
        self.end_headers()
        self.wfile.write(payload)

http.server.HTTPServer(('', 80), Handler).serve_forever()

Máy chủ HTTP có thể được viết bằng bất kỳ ngôn ngữ nào; đó chỉ là một ví dụ Rõ ràng, ví dụ này rất thô sơ. Tải trọng được mã hóa cứng - chương trình hoàn toàn bỏ qua nội dung của yêu cầu - URL, chuỗi truy vấn, tiêu đề Ngôn ngữ chấp nhận, v.v. Bạn có thể thêm mã để tạo phản hồi có ý nghĩa dựa trên yêu cầu, nhưng sau đó mã sẽ nhận được rất nhiều phức tạp. Bên cạnh đó, các lập trình viên thà tập trung vào viết ứng dụng web, không phải lo lắng về các chi tiết về cách xử lý yêu cầu HTTP.

Một giải pháp phù hợp hơn là sử dụng máy chủ web, chẳng hạn như Apache HTTPD , IIS hoặc nginx . Máy chủ web chỉ là một chương trình lắng nghe các socket TCP có liên quan, chấp nhận nhiều yêu cầu (có thể đồng thời) và quyết định cách tạo phản hồi dựa trên URL yêu cầu, tiêu đề và các quy tắc khác. Lý tưởng nhất, nhiều chi tiết, chẳng hạn như SSL, kiểm soát truy cập và giới hạn tài nguyên được quan tâm thông qua cấu hình thay vì mã. Phần lớn thời gian, máy chủ web sẽ tạo ra một phản hồi chỉ bao gồm nội dung từ các tệp trong hệ thống tệp.

Tuy nhiên, đối với nội dung động, máy chủ web có thể được cấu hình để thực thi một số mã để tạo phản hồi. Một cơ chế để thực hiện điều đó là với CGI - máy chủ đặt một số biến môi trường dựa trên yêu cầu, thực thi chương trình và sao chép đầu ra của nó vào ổ cắm TCP. Một giải pháp phức tạp hơn một chút sẽ là có một mô-đun bổ sung hỗ trợ cho máy chủ web để gọi mã bằng ngôn ngữ lập trình khác (ví dụ mod_php cho Apache ). Tuy nhiên, một tùy chọn khác là viết máy chủ web bằng cùng ngôn ngữ với ứng dụng web, trong trường hợp đó, công văn yêu cầu chỉ là một cuộc gọi chức năng. Đó là trường hợp với các công cụ servlet node.js và Java như Apache Tomcat .

Sự lựa chọn công nghệ thực sự tùy thuộc vào bạn và phụ thuộc vào ngôn ngữ lập trình bạn muốn sử dụng, môi trường lưu trữ có sẵn cho bạn, yêu cầu về hiệu suất, ý kiến ​​phổ biến và thông qua mốt nhất thời. CGI, chẳng hạn, gần đây không được ưa chuộng, vì nhu cầu khởi chạy các chương trình bên ngoài hạn chế khả năng mở rộng.

Máy chủ web là một chương trình được viết bằng bất kỳ ngôn ngữ lập trình nào xử lý "lưu lượng truy cập web" qua (các) ổ cắm tuân thủ các giao thức mức tiêu chuẩn / ứng dụng (HTTP, v.v.). Hầu hết các ngôn ngữ lập trình cung cấp cho bạn để tạo ra một ổ cắm.

Tôi có đúng không khi nghĩ rằng một máy chủ chỉ cần một số loại giao diện như CGI để làm cho máy chủ và ngôn ngữ lập trình hoạt động cùng nhau?

Không cần phải có chương trình máy chủ chuyên dụng và chương trình ứng dụng của bạn - chúng có thể giống nhau (không tính đến bất kỳ vấn đề nào liên quan đến hiệu suất).

Bạn có thể sử dụng một số thư viện máy chủ HTTP , ví dụ libonion , ngay cả trong chương trình của bạn được mã hóa bằng C (hoặc C ++, xem thêm Wt ). Ngoài ra còn có một số thư viện máy khách HTTP (ví dụ libcurl )

Bạn có thể sử dụng các thư viện HTTP khác, ví dụ ocsigen & ocamlnet cho OCaml .

Có một số ngôn ngữ dành riêng cho Web (bên ngoài PHP), ví dụ Opa , HOP , Kaya , v.v ... (cả HOP & Opa đều có thể dễ dàng trộn các tính toán phía máy chủ và phía trình duyệt, nhưng bạn phải thực hiện một cách đau đớn và thủ công PHP, rõ ràng sử dụng các kỹ thuật AJAX và mã hóa một số Javascript cho trình duyệt. Ngược lại, HOP, Opa, Ocsigen có thể tạo Javascript đó).

Bạn cũng có thể sử dụng công nghệ FASTCGI để thêm một số dịch vụ động vào một số máy chủ web ... FASTCGI tốt hơn CGI cũ đơn giản , bắt đầu một quy trình mới cho mọi yêu cầu HTTP đến, trong khi ứng dụng FASTCGI có thể phục vụ nhiều yêu cầu HTTP trong cùng một quy trình. BTW, PHP có thể được cấu hình để hoạt động như một ứng dụng FASTCGI.

C.Queinnec quan sát thấy rằng trình duyệt web và tiếp tục có liên quan đáng kể.

Tái bút Tôi không thích PHP và tôi tin rằng sự phổ biến của nó có lý do lịch sử và xã hội (không phải chủ yếu là kỹ thuật). Thật vậy, PHP đã được phổ biến rộng rãi trước khi AJAX được sử dụng rộng rãi và cũ hơn HOP hoặc Opa (hoặc Ocsigen).