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

45

Webサイトのサーバー側開発には、あらゆる汎用プログラミング言語を使用できることを理解しています。

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

programming-languages web-development web

— クリスダンス
ソース

2

他のプログラミングタスクと同じ理由です。人々は既存の言語について何かを嫌うため、新しいプログラミング言語を発明します。また、他の人は同じものを嫌っていないため、または少なくとも切り替えるのに十分ではないため、古いものを使用し続けます。

— キリアンフォス

だから私はPHPなどのいくつかの言語はウェブ開発を念頭に置いて設計されているため、一般的なアプリケーションにとってより簡単な（したがってより人気のある）オプションであると言ってもいいでしょうか？

— クリスダンス

29

PHPは、私が「浅い」言語と呼ぶものです。基本構造は理解しやすく、便利な機能を実行する何百もの小さな関数があります。したがって、新人にアピールします。C＃のような言語と比較してください。C＃では、継承、オブジェクト指向、タイプセーフティ、および生産性を高める比較的複雑なライブラリなどを学ぶ必要があります。

— ロバートハーヴェイ

4

そのようなインターフェイスがない場合でも、言語でサーバーを作成できます。

— user253751

75

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

CGIは、フォークされて実行されるプロセスの環境（および場合によってはstdinの一部）に大量の情報を貼り付け、stdoutから得た情報を取得して要求者に返します。

これは、実装言語が何であるかを気にしません。実際、私は初期のCGIをその日のCまたはC ++で書きました。ちょっと痛かった。後で90年代前半にいくつかのperlを学びましたが、それほど痛みはありませんでした。

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

これに対する解決策は、Webサーバー自体のスレッドに移動するか、またはforkとexecを行わずにリクエストを処理する別のプロセスにリクエストをディスパッチすることにより、forkとexecingを削除することです。mod_perlは、これを行うためのツールの1つです（perlをapacheに移動するプラグイン）。Php（90年代後半）も、言語をプラグインとしてWebサーバー自体に実装することでこれを行いました。これはperlに似ていて（初期の支配的なWebプログラミング言語でした）、perl cgisを上回る可能性があるため、非常に人気がありました。90年代半ばのこの期間からまだかなりの勢いがあります-より多くのエンタープライズグレードのアプリケーションサーバーがそれらの背後にあるより正式な言語で定着し始める前に。掘り下げると、

これにより、内部スレッドが生成されるアプリケーションサーバー（または他のアプローチ-すべてに当てはまるわけではない）にアクセスして、新しいプロセス全体ではなく要求を処理できます。外部プロセスとして、これはFastCGIで見られ、その後他のアプリケーションサーバーで一般的になりました。これにより、アプリケーションサーバーとWebサーバーの間の境界線が少し曖昧になることに注意してください。多くのアプリケーションサーバーはWebサーバーの2倍になる可能性がありますが、従来のWebサーバーのように静的ファイルIOを処理するために最適化されていませんでした。

また、汎用アプリケーションサーバーは、汎用アプリケーションサーバーの代わりに、組み込みWebサーバーを実行するか、または展開全体であるアプリケーション自体を持つソリューションへの道を開きました。このような状況では、アプリケーションサーバーにWebアプリケーションをデプロイするのではなく、それ自体を実行してリクエストを処理するだけです。繰り返しになりますが、このモデルの目標は、アプリケーションの新しいインスタンスを起動するという重い価格を回避し、代わりに、はるかに軽いスレッドまたは同様のアプローチでアプリケーション内のリクエストを処理することです。

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

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

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

これはまさに私が探していたものです。包括的で独創的な答え。ありがとうございました！

— クリスダンス

1

「解決策は、フォークと実行サイクルをWebサーバー自体に移動することです。」必ずしもそうではありません：FastCGI、リバースプロキシは、ターゲット言語やWebサーバーの実装を気にせずにアプリケーションサーバーに接続するためのよく知られたソリューションであり、明確に指定されたプロセス間通信プロトコルを使用して作業を行います。

— ジョミナル

1

@jhominal「FastCGIは、リクエストごとに新しいプロセスを作成する代わりに、永続プロセスを使用して一連のリクエストを処理します。これらのプロセスは、WebサーバーではなくFastCGIサーバーが所有します。」（ソース）-それはその核心であり、これがアプリケーションサーバーの役割です。forkおよびexecを実行せずに要求を処理する永続的なプロセス。

@MichaelT：用語が交換可能であるかのように「Webサーバー」と「アプリケーションサーバー」を使用しています。そして、答えでは、「Webサーバー」を主にApache、nginxを参照するために使用しています。（コアで）限られたプログラム可能性のみを持ちます。

— ジョミナル

1

これは、各アプリケーションを独自のWebサーバーとして（ほとんどの場合1つまたは複数のHTTPプロキシを使用する）の（今では非常に一般的な）プラクティスに言及するのに十分ではないと思います。

— ホッブズ

19

はい、一般的なプログラミング言語は、Webサイトのサーバー側の部分を作成するのに役立ちます。

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

たとえば、PHPがWebサイトで人気を博した理由は次のとおりです。

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

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

より一般的な言い方をすれば、言語の採用は多くの場合、これらの質問に対する答えについてです。

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

— ジョミナル
ソース

7

サーバーとプログラミング言語を連携させるために、サーバーには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 Forms）を使用すると、Windows Forms開発者（多くはVBコーダー）が非常に簡単にWebに切り替えることができました。

— ラビバーグ
ソース

3

ブラウザが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>

任意の TCPソケットでリクエストをリスニングすることをサーバー上で実行されているコードは、リクエストを読み、適切な応答との回答が十分です。馬鹿げた方法の1つは、シェルスクリプトを使用して、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プロトコルにほとんど準拠していないようです。

その定型化された応答からの一歩はhttp.server、Python 3のライブラリを使用するこの単純なPythonプログラムです。

#!/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ヘッダーなど。リクエストに基づいて意味のある応答を生成するコードを追加できますが、コードは非常に繁雑。また、プログラマーはWebアプリケーションの作成に集中し、HTTPリクエストの処理方法の詳細を心配する必要はありません。

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

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

テクノロジーの選択は本当にあなた次第であり、使用したいプログラミング言語、利用可能なホスティング環境、パフォーマンス要件、一般的な意見、および流行の流行に依存します。たとえば、CGIは、外部プログラムを起動する必要があるためスケーラビリティが制限されるため、最近好まれていません。

— 200_成功
ソース

1

Webサーバーは、標準/アプリケーションレベルのプロトコル（HTTPなど）に準拠したソケットを介した「Webトラフィック」を処理するプログラミング言語で記述されたプログラムです。ほとんどのプログラミング言語では、ソケットを作成できます。

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

専用のサーバープログラムとアプリケーションプログラムを用意する必要はありません-これらは同じものにすることができます（パフォーマンス関連の問題は無視します）。

— ムカホ
ソース

0

C（またはC ++、Wtも参照）でコーディングされたプログラムでさえ、libonionなどのHTTPサーバーライブラリを使用できます。また、いくつかのHTTPクライアントライブラリ（例えばlibcurl）

OCaml用のocsigenおよびocamlnetなど、他のHTTPライブラリを使用できます。

Opa、HOP、Kayaなど、いくつかのWeb専用言語（PHP以外）があります（HOPとOpaの両方で、サーバー側とブラウザー側の計算を簡単に混在させることができますが、 PHP、明示的にAJAX技術を使用し、ブラウザ用にJavaScriptを手動でコーディングします。対照的に、HOP、Opa、OcsigenはそのJavascriptを生成できます。

FASTCGIテクノロジーを使用して、いくつかの動的サービスをWebサーバーに追加することもできます... FASTCGIは、着信HTTP要求ごとに新しいプロセスを開始する単純な古いCGIよりも優れていますが、FASTCGIアプリケーションは同じプロセスで多くのHTTP要求を処理できます。ところで、PHPはFASTCGIアプリケーションとして動作するように構成できます。

C.Queinnecは、Webの閲覧と継続が大きく関連していることを観察しました。

PS。私はPHPが好きではなく、その人気には歴史的および社会的な理由があると信じています（主に技術的な理由ではありません）。実際、PHPはAJAXが広く使用される前に広く普及しており、HOPやOpa（またはOcsigen）よりも古いものです。

— バジル・スタリンケビッチ
ソース