肌の色が違う人の外見は千差万別で、双子を識別するのは難しいことを知っています。興味深いことに、ウェブサーバ、ウェブコンテナ、ウェブアプリケーションサーバ、リバースプロキシは四つ子のようなもので、ウェブ上ではしばしば一緒に登場します。この記事では、これら4つの似た概念をどのように見分けることができるのか、読者に説明します。
ウェブサーバーの歴史
1989年、インターネットの生みの親であるバーナーズ＝リーは、ハイパーテキスト・システムを利用して科学者間の情報交換を容易にすることを目的とした新しいプロジェクトを雇用主であるCERNに提案しました。このプロジェクトにより、バーナーズ＝リーは1990年に2つのプログラムを作成：
WorldWideWebというブラウザ。
後にCERN httpdとして知られる世界初のウェブサーバーは、1991年から1994年にかけて、World Wide Web上でのデータ閲覧や交換に使用された初期の技術であるNeXTSTEP上で動作し、そのシンプルさと有効性により、多くの異なるオペレーティングシステムに移植され、科学組織や大学で使用されるようになり、その後、産業界にも広まりました。
1994年、バーナーズ＝リーは、標準化のプロセスを通じて、関連する多くの技術のさらなる発展を管理するために、ワールド・ワイド・ウェブ・コンソーシアムを設立することを決定しました。
ウェブサーバーの主な機能は、ウェブページを保存、処理し、クライアントに配信することです。クライアントとサーバー間の通信は、ハイパーテキスト転送プロトコルを使用して行われます。配信されるページは HTML ドキュメントであることがほとんどで、テキストコンテンツに加えてイメージ、スタイルシート、スクリプトが含まれることもあります。
ユーザーエージェント（通常はウェブブラウザやウェブクローラ）がHTTPリクエストを開始することで、サーバーのリソースに対してHTTPリクエストを行い、サーバーはリクエストに基づいてそのリソースを返すか、何らかの理由でエラーメッセージを返します。リソースは通常、サーバーのセカンダリストレージ上の実際のファイルですが、ウェブサーバーの実装方法によっては必ずしもそうとは限りません。
主な機能はコンテンツを提供することですが、HTTP の完全な実装には、クライアントからコンテンツを受け取る方法も含まれています。この機能は、ファイルのアップロードを含むウェブフォームの送信に使われます。多くの汎用 Web サーバーは、Active Server Pages や PHP などのスクリプト言語を使ったサーバーサイドスクリプティングもサポートしています。これは、実際のサーバーソフトウェアはそのままで、ウェブサーバーの動作を別のファイルでスクリプト化できることを意味します。通常、この機能は静的なドキュメントを返す代わりに、動的にHTMLドキュメントを生成するために使われます。前者は主にデータベースから情報を取得したり変更したりするために使われます。後者は通常、はるかに高速でキャッシュも簡単ですが、動的なコンテンツを提供することはできません。
ウェブサーバーは、ワールド・ワイド・ウェブを提供するためだけに使われるわけではありません。プリンター、ルーター、ウェブカメラなどの機器に組み込み、ローカルネットワークのみにサービスを提供することもできます。その場合、ウェブサーバーは、当該デバイスの監視や管理に使用されるシステムの一部として使用することができます。通常、ウェブ・ブラウザだけが必要なので、クライアント・コンピュータに他のソフトウェアをインストールする必要はありません。
ウェブサーバーの仕組み
HTTPプロトコルはTCPプロトコルをベースにしており、ユーザーエージェントとウェブサーバー間の通信に使用されるアプリケーションレイヤープロトコルです：
1、ユーザがリソース要求を開始する際のユーザエージェントにおいて、要求は以下を含みますが、これらに限定されるものではありません：リソースIRIの固有IDの指定、アクションのタイプの指定。
2、ユーザーエージェントの解決 ユーザーがIRIを入力し、DNSサーバーによって解決されたターゲットドメイン名を取得します。IRIにIPアドレスが指定されている場合は、このステップは必要ありません。
3.サーバーとのセッションがまだ確立されていない場合は、この時点でまず TCP 接続を確立し、HTTP ネゴシエーションを完了します。
4.ユーザーエージェントはリクエストをHTTPパケットにカプセル化し、サーバーに送信します。
5.サーバーはリソースリクエストを受信し、ネゴシエートされた方法でそれを解凍して処理します。
6.サーバーによって要求されたリソースは、HTTPパケットにカプセル化され、ユーザーエージェントに返されます。
TCPリスニング・モジュール
サーバは、ユーザエージェントとの接続を確立するためにポートをリッスンします。いったん接続が確立されると、その後のユーザエージェントからの HTTP リクエストはリッスンモジュールに入る必要がなくなります。
前処理
1.TCPパケットからHTTPリクエストメッセージを取得し、2.ユーザーエージェントとのネゴシエーションに従って、復号、伸長、セキュア化などを行い、3.サーバー自身の設定に従って、セキュア化、セッション状態の確立などを行います。
UR
URL文字列とアクションを解析して、ユーザーエージェントによって要求されたリソースを決定し、マッチングルールに基づいて静的リソース処理モジュールまたは動的リソース処理モジュールのいずれかにルーティングします。
静的リソース処理モジュール
HTML/Javascript/CSSファイル/イメージ/イメージなどの静的リソースを見つけ、コンテンツが文字ストリームまたはバイトストリームであることを判断し、対応するMIMEを決定します。
動的リソース処理モジュール
ビジネスロジックの処理を実行し、動的に返されたリソースの内容と種類を決定し、処理の原則の内容と種類は上記と同じです。
前処理
暗号化、圧縮、安全な処理などは、ユーザーと交渉したプロトコルに従って実行されます。
リソース出力モジュール
処理されたコンテンツとタイプをHTTPメッセージにカプセル化し、TCP接続の相手側のユーザー・エージェントにTCPメッセージを送信します。
ウェブサーバーの主流
Apache、IIS、Nginxを含めたシェアは以下の通りです。
他にも、Tomcat、Jetty、WebSphere、WebLogic、Kerstrelなどがあります。
Webアプリケーションコンテナの概念と基礎
Webサーバーの登場はWWW時代の幕開けを告げ、世界はよりフラットになりました。最初にその甘さを味わった先駆者たちは、インターネット上の静的なリソースでは満足できなくなり、動的にリソースを取得するCGIスクリプトが登場しました。その後、ネットワークの発展の方向も、Webサーバーが動的にリソースにアクセスする能力を高める方向に向かいます。以下に代表的な動的技術を紹介します：
特性
CGI
スタンドアロンのプロセスとして実行され、C、C + +、VB、Perlなどの複数の言語で開発することができ、柔軟性がありますが、非効率、メンテナンスの複雑さ。
PHP
サーバーサイドに埋め込まれたHTMLスクリプト、オープンソース、強力、拡張性が低い
ジェイエスピー
サーバーサイドに埋め込まれたHTMLスクリプト、クロスプラットフォーム、デプロイ前にコンパイル、主な欠点はJSPの記述がより複雑であること、JAVAや関連技術に精通している必要があることです。
アクティブサーバーページ
サーバーサイドの埋め込みHTMLスクリプト。
その後、Web サーバーはエンタープライズ・アプリケーションへと進化し、急速なビジネスの変化により、Web 開発者は新たな課題に直面せざるを得なくなりました。この課題に対する効果的な解決策は、堅牢性と信頼性の問題に対処し、迅速な開発インタフェースを提供するWebアプリケーション開発フレームワークを作成することです。言い換えれば、開発者はビジネスそのものの実装に集中すればよく、より高い要求があればフレームワークをカスタマイズして拡張することができます。このフレームワークの別の名前はWebアプリケーションコンテナです。
ウェブアプリケーションコンテナの仕組みの基本
一般的にウェブアプリケーションコンテナは、以下のような構成システムになっています：
注：水色のモジュールは、ビジネスプロセスを実装するために主に使用されるモジュールです。
ウェブ・サーバーに関連して、コンテナには以下の新モジュールまたは拡張モジュールがあります：
スレッドプールリソースの割り当て
コンテナは各リクエストにスレッドを割り当てて処理します。通常はスレッドプールという形で、CPU リソースを効率的に正当化します。
リクエストは、主にユーザーリクエストの主なコンポーネントをカプセル化するリクエストコンテキストに対応しています：URL、HTTPリクエストヘッダ、およびセッション、クッキーや他のオブジェクトを構築するために、リクエストヘッダに基づいて、プログラミングを使用するのは簡単です。
リクエストはレスポンスコンテキストに対応し、主にユーザーエージェントにリソースを返すために使用されます。その中に出力ストリームを書いたり、リダイレクトしたり、エラーコードを返したりすることができます。
通常、ここでは特定のコンテナや開発言語が、JAVAのサーブレットASP.NETWebフォーム、MVCのような独自の効率的な開発モデルを持っています。
ここで、スレッドリソースは、スレッドを再利用するために、サーバがアイドルでない限り、通常はスレッドプールにスレッドを返します。
見ることができる、Webコンテナ自体がWebサーバとしての機能を持って、実際には、通常、サーバのWebコンテナ機能の実装は、Webサーバです。Tomcat、IIS、Jettyなど。
ウェブコンテナの主流
Tomcat、IIS、Jettyを含みます。
また、WebSphereやWebLogicなどの利用も増えています。
Webアプリケーションサーバーの概念と基礎
ウェブ・サーバーが開発されていた同じ時期に、アプリケーション・サーバーは長い間存在し、進化していました。いくつかの企業が、IMS や CICS のようなホストアプリケーション管理・監視環境から派生した、Tuxedo、TopEnd、Encina などの Unix 向け製品を開発しました。これらの製品のほとんどは、ファットクライアントとサーバーを相互接続するために「閉じた」製品固有の通信プロトコルを指定していました。1990年代、これらのレガシー・アプリケーション・サーバ製品は、当初はゲートウェイを使用してHTTP通信機能を組み込み始めました。両者の境界線が曖昧になるまで、そう時間はかかりませんでした。
同時に、ウェブサーバはより洗練され、より高い負荷、より高い並行性、より優れた機能を扱うようになり、アプリケーションサーバはより多くの HTTP ベースの通信機能を追加し始めています。これらにより、ウェブサーバーとアプリケーションサーバーの境界線は狭くなっています。
現在、「アプリケーション・サーバー」と「ウェブ・サーバー」の境界線は曖昧になっています。しかし、2つの用語の区別は、強調するためにまだ使用されています。
誰かが「ウェブサーバー」と言うと、通常はHTTP中心のウェブUI駆動型アプリケーションを思い浮かべるでしょう。アプリケーション・サーバー」と言われると、おそらく「高負荷、エンタープライズ機能、トランザクションとキュー、マルチチャネル・コミュニケーション」を思い浮かべるでしょう。しかし現在では、これらの要件をすべて提供するのは基本的に同じ製品です。
上の図から、あなたは、Webアプリケーションサーバーは、Webコンテナが含まれて見ることができますが、エンタープライズアプリケーション、トランザクション、セキュリティ、統合、通信、高可用性などのビルトインサポートは、大幅に迅速な開発とビジネスシステムの展開を確保するために、開発の重複の量を削減し、それはまた、Webサーバーです。 Webアプリケーションサーバーは、WebLogicとWebSphereのようなヘビー級の製品の大手メーカーを使用するように選択することができますが、また、Tomcat、jetty、Webコンテナに加えて、独自のアプリケーションサーバーを構築するためのサードパーティのフレームワークなどと同様に使用することができます。WebSphereのようなヘビー級の製品は、また、独自のアプリケーションサーバーを構築するためにTomcat、jetty、プラスサードパーティフレームワークと同様のWebコンテナを使用することができます。.NET Coreプラットフォームでは、IIS、Apache、Nginxおよびhttp://ASP。.NET Coreプラットフォームは、IIS、Apache、Nginxおよび.NET Frameworkを選択することができます。
リバースプロキシの概念と基礎
リバースプロキシはプロキシサーバの一種です。クライアントのリクエストに基づいてバックエンドサーバからリソースを取得し、 そのリソースをクライアントに返します。インターネット上で取得したリソースを関連するクライアントに返す媒体として動作するフォワードプロキシとは異なり、リバースプロキシはクライアントではなくサーバ側でプロキシとして使用されます。クライアントは、フォワードプロキシを通して多くの異なるリソースにアクセスすることができます。一方、リバースプロキシは、すべてのリソースがこのリバースプロキシサーバから来ていると仮定して、多くのクライアントがこれらのバックエンドサーバの存在を知る必要なく、異なるバックエンドサーバのリソースにアクセスするものです。
インターネット上のリクエストはリバースプロキシに送られ、リバースプロキシはリクエストをイントラネット内のサーバーに転送します。
- 暗号化とSSLアクセラレーション
- 負荷分散
- 静的コンテンツのキャッシュ
- 圧縮
- ゆっくりアップロード
- セキュアファイアウォール
- エクストラネットのリリース
- インターネット封鎖の解除
- 領域横断的な問題の解決
リバースプロキシサーバーの構成と処理を以下に示します：
左側の黄色がかったファンクション・モジュールはエクストラネット・メッセージを処理し、右側の灰色のファンクション・モジュールはイントラネット・メッセージを処理します。
TCPリクエストをリスニングし、ここでのリクエストは、メッセージの内容は、特定のアプリケーション層のプロトコルの要求です。ここでは、別のスレッドが処理を開始するために生成されるかどうかについては、これはサーバ自体によって決定され、最も人気のあるメッセージキューに最初にされ、非同期処理は、大幅にエージェントのスループットと安定性を向上させることができます。
プロキシサーバーは、テーブルに従って、一致する場合は処理を続行するには、それ以外の場合は、HTTPプロトコルなどのエラーメッセージを返すには、外部ネットワークのプロトコルに基づいて404を返します。
比較的大規模なインターネットアプリケーションの場合は、システム全体の安定性のために、シングルポイントの問題を解決するには、カスタムポリシーに基づいてする必要がある合理的なプロキシサーバーにメッセージを転送します。単純なポリシーは、一般的に設定し、ユーザーが選択することができますハッシュ分布またはランダム分布です。
復号化、セキュリティ、セッション、解凍などは、ネゴシエートされたエクストラネット・アプリケーション・プロトコルに従ってここで処理されます。
ここでネットワーク・メッセージは、ネゴシエートされたイントラネット・アプリケーション・プロトコルに基づいて生成され、暗号化、セキュリティ、セッション、圧縮などが実行されます。
新しく生成されたネットワーク・メッセージをイントラネット・サーバーに送信します。
イントラネット・サーバーからのネットワーク・メッセージを受信します。
ここでは、ネゴシエートされたエクストラネット・アプリケーション・プロトコルに基づいて、暗号化、セキュリティ、セッション、圧縮などが実行されます。
この時点で、外部ネットワーク用のアプリケーション・プロトコルの要件を満たすメッセージが生成され、外部ネットワーク接続の相手側に送信されます。
Ngnix、IIS、Apacheの名前を覚えているだろう。
要約すると
概念的には：Webサーバーは、WWWサービスの手順を提供することです。Webコンテナは、開発者のフレームワークに提供されます。Webアプリケーションサーバーの内容ははるかに豊富で、ベンダーが通常、特定の業界標準やカスタム拡張機能に従って使用することができますし、利用できるようになるだけでなく、オープンソースのコンポーネントを使用することができます軽量ビルドするために組み立て。リバースプロキシサーバは、集中セキュリティ、負荷分散、およびその他の利点に対処し、エンタープライズアプリケーションで顕著です。今日では、これらの4つの概念の境界は、より多くのあいまいな、知るために、この表を見てください：
Kerstrel がウェブコンテナであるかどうかについては、2 つの見解があります：
1.Kerstrelは、アプリケーションを記述するためのフレームワークを提供しないため、コンテナではありません。http://asp.net coreは、アプリケーションを開発するためのフレームワークを提供し、Webアプリケーション（MVC、Web API）の実行環境を提供するため、コンテナです。
2.Kerstrelは動作環境を提供します。
このhttp://asp.net コア・コンテナのコンセプトを明確にするために、あなた自身の長所を大いに歓迎します。
