サーバー側プログラミング言語へのアクセス方法の説明

Question

私の理解では、どのような汎用プログラミング言語でもWebサイトのサーバー側開発に使用できます。

サーバーとプログラミング言語を連携させるには、サーバーにCGIなどのインターフェイスが必要だと思いますか？もしそうなら、なぜいくつかのプログラミング言語（phpなど）が他よりも人気があるのですか？

user40980 · Accepted Answer

Webの初期の頃、CGIは確かに動的なコンテンツを作成する唯一の（実用的な）方法でした（ファイルの名前付きパイプを実行でき、それらはcgiの前の日に使用されましたが、それはまったく実用的ではありませんでした）。

CGIは、forkされてexec'edされた（そしておそらくstdinのいくつかの）プロセスの環境に一連の情報を貼り付け、stdoutから取得したものを取り出して要求元に返します。

これは、実装言語が何であるかについて少し気にしません。確かに、私はその初期のCGIをCまたはC++で書き直しました。ちょっと辛かったです。私は後に90年代の初めにいくつかのPerlを学びましたが、それはそれほど苦痛ではありませんでした。

これはある程度まで機能します。問題は規模です。各CGI要求は、プロセスの分岐と実行です。数千のリクエストは数千のプロセスを意味します。 本当にはうまく機能しません。

これに対する解決策は、フォークと実行をWebサーバー自体のスレッドに移動するか、フォークと実行の必要なしに要求を処理する別のプロセスに要求をディスパッチすることによって、フォークと実行を削除することです。 mod_Perlはそのためのツールの1つです（PerlをApacheに移動するプラグイン）。 Php（90年代後半）もこれを行い、フォークされたものではなく、Webサーバー自体のプラグインとして言語を実装しました。これは、Perlライク（初期の主要なWebプログラミング言語でした）であり、Perl cgisよりも優れているため、非常に人気がありました。 90年代半ばのこの時期からまだかなりの勢いがあり、よりエンタープライズグレードのアプリケーションサーバーが、その背後にあるより正式な言語で定着するようになる前に。調べてみると、90年代後半から2000年代初頭にかけて失敗した試みがたくさん見つかります。

これにより、新しいプロセス全体ではなく要求を処理するために内部スレッドが生成される（または他のアプローチ-これはすべてに当てはまるわけではありません）アプリケーションサーバーに移動します-これは、スケーリングに役立ちます。これは外部プロセスとして、FastCGIで確認でき、その後他のアプリケーションサーバーで蔓延しました。これを使用すると、アプリケーションサーバーとWebサーバーの間の線が少しぼやけます-多くのアプリケーションサーバーは、静的ファイルを処理するように最適化されていませんが、IO従来のWebサーバーはそうです。

汎用アプリケーションサーバーは、genericアプリケーションサーバーの代わりに、アプリケーション自体が埋め込みWebサーバーを実行しているか、またはデプロイメント全体であるソリューションへの道を開きました。このような状況では、アプリケーションサーバーにWebアプリケーションをデプロイせず、アプリケーション自体を実行してリクエストを処理しているだけです。繰り返しますが、このモデルの目標は、アプリケーションの新しいインスタンスを起動するための高額なコストを回避し、代わりにはるかに軽量のスレッドまたは同様のアプローチでアプリケーション内の要求を処理することです。

ただし、ここで問題があります。すべてのソリューションは、何らかの形、形、または形で不十分です。 CGIは簡単ですが、スケールに関して深刻な問題があります。 Webサーバーのプラグインは、Webサーバー自体（Apache vs nginx vs IIS vs ...））にバインドされ、言語の一般的な機能を失います。Microsoftは独自のテクノロジーパレードを持っていますそして、1つの言語を知っている場合は、スタックの異なる部分（クライアントとNode.jsのJavaScript）に異なる言語を使用するのではなく、その言語でプログラミングを続けませんか？

そして、あなたは今日持っています。 Javaスタックで作業する人もいます（scalaとclojureは珍しくなくなりました）。他の人はC＃スタックで。他の人はJavaScriptスタックで。かなりあります。少しのphpスタックがそこにあります。たくさんのpythonがあります。Perlスタックはまだそこにあります（そして、ボリュームの少ないサイトを見ると、まだCGIがあります）。クラウドコンピューティングでは、GoogleはGoを実行可能なサーバー側のWeb言語。

それぞれに長所、短所、フレームワーク、サーバーがあります。それらの周りのテクノロジーが変化するにつれて、これらの衰退と流れの相対的な人気。彼らはさまざまなことをうまくやっています。

jhominal · Answer

はい、一般的なプログラミング言語であれば、Webサイトのサーバー側の部分を作成できます。

ただし、プログラミング言語の品質は、他のことと同様に、この主題では通常、その人気に貢献する多くの要因の1つにすぎません。

たとえば、PHP=がWebサイトで人気になった理由は次のとおりです。

静的なWebサイトからPHP動的なWebサイトへのアップグレードは非常に簡単です。HTMLファイルのファイル拡張子を置き換え、<?php最初にタグを付け、提供されたPHPがインストールされている場合、動的Webサイトがあります！残りのワークフローは、静的Webサイトの場合とまったく同じです。
展開が簡単なため、動的Webサイトを提案しようとしていたWebホストはPHPを選択しました。これにより、最も広く展開されているサーバー側プラットフォームが非常に速くなりました。
それは適切なタイミングでその市場に参入しました。

そしてPHPが広く展開された後、その幅広い展開の恩恵を受けるためにPHPでより深刻なWebアプリケーションを書くことが興味深いものになりました。

より一般的な言い方をすると、言語の採用は、多くの場合、以下の質問に対する答えです。

やりたいことをするのは簡単ですか？
私がやりたいことのための言語はどの程度広くサポートされていますか？

ravibhagw · Answer

サーバーとプログラミング言語を連携させるには、サーバーにCGIなどのインターフェイスが必要だと思いますか？

ほとんど。 HTTPリクエストにも応答できるようにするための何らかのソフトウェアを備えたWebサーバーが必要です。

静的ページがどのように提供されるかを考えてください。サーバーはHTTPリクエストを取得し、HTTPサーバーの設定に基づいてファイルシステムからリクエストされたドキュメントを見つけ、静的ページを返します。

CGIは、実行可能ファイルまたはスクリプトを格納できるファイルシステム上のcgi-binフォルダーを指定できるようにすることで、この概念を拡張します。 CGIを介してプログラムにアクセスすると、HTTPサーバーはプロセスまたはスクリプトを実行し、静的ドキュメントを提供するだけでなく、標準出力をクライアントに返します。

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

古いCGI構造は、大量のリクエストに対して十分に拡張できません。 Webにはさまざまなプログラミング言語やフレームワークが存在しますが、その理由はそれぞれ異なります。 PHPは、CGIを使用せずに動的ページを提供する最初の簡単で安価なソリューションの1つであり、幅広いホスティングサポートがあったため、歴史的な理由から人気があります。 ASPは、VB開発者がスキルをWebに移行できるようになったため、Microsoftサークルの間で人気がありました。 ASP.NET（Webフォーム）により、VBコーダーであるWindowsフォーム開発者がWebに切り替えるのが非常に簡単になりました。

200_success · Answer

ブラウザがHTTPリクエストを行うと、次のようになります。

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

…サーバーは次のような応答を送信する必要があります。

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>

Any TCPソケットで要求をリッスンし、要求を読み取り、適切な応答で応答するサーバー上で実行されているコードで十分です。シェルスクリプトを使用して、TCPポート80に接続するすべての人に返信定型文を出力します。

$ 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

もちろん、その手法は HTTPプロトコルに準拠しているように見えます。

その定型応答からのステップアップは、この単純なPythonプログラムです。これは http.server ライブラリを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()

HTTPサーバーは任意の言語で記述できます。これは単なる例です。明らかに、この例は非常に初歩的なものです。ペイロードはハードコーディングされています—プログラムは、要求の内容（URL、クエリ文字列、Accept-Languageヘッダーなど）を完全に無視します。要求に基づいて意味のある応答を生成するコードを追加できますが、コードは繁雑。さらに、プログラマーはむしろ、HTTPリクエストの処理方法の詳細について心配する必要なく、Webアプリケーションの作成に集中するでしょう。

より適切な解決策は、 Apache HTTPD 、 [〜＃〜] iis [〜＃〜] 、または nginx などのWebサーバーを使用することです。 Webサーバーは、関連するTCPソケットをリッスンし、複数の要求を（場合によっては同時に）受け入れ、要求URL、ヘッダー、およびその他のルールに基づいて応答を生成する方法を決定するだけのプログラムです。理想的には、SSL、アクセス制御、リソース制限などの詳細の多くは、コードではなく構成を介して処理されます。ほとんどの場合、Webサーバーは、ファイルシステム内のファイルのコンテンツのみで構成される応答を作成します。

ただし、動的コンテンツの場合、コードを実行して応答を生成するようにWebサーバーを構成できます。これを行う1つのメカニズムはCGIを使用することです—サーバーは要求に基づいていくつかの環境変数を設定し、プログラムを実行し、その出力をTCPソケットにコピーします。少し洗練されたソリューションは別のプログラミング言語でコードを呼び出すためのサポートをWebサーバーに追加するモジュールがあります（たとえば、Apacheの mod_php ）。さらに別のオプションは、Webアプリケーションと同じ言語でWebサーバーを作成することです。リクエストディスパッチが単なる関数呼び出しである場合 node.js およびJava Apache Tomcat などのサーブレットエンジン）の場合です。