アプリケーションサーバーとWebサーバーの違いは何ですか？

ほとんどの場合、Webサーバーとアプリケーションサーバーという用語は同じ意味で使用されています。

Webサーバーとアプリケーションサーバーの機能の主な違いは次のとおりです。

• WebサーバーはHTTPコンテンツを提供するように設計されています。 App ServerはHTTPコンテンツも提供できますが、HTTPだけに限定されません。 RMI / RPCなどの他のプロトコルサポートを提供できます。
• Webサーバーはほとんど静的コンテンツを提供するように設計されていますが、ほとんどのWebサーバーはPerl、PHP、ASP、JSPなどのスクリプト言語をサポートするためのプラグインを持っています。
• ほとんどのアプリケーションサーバーは、Webサーバーをその一部として備えています。つまり、App Serverは、Webサーバーができることなら何でも実行できます。さらに、App Serverには、コネクションプーリング、オブジェクトプーリング、トランザクションサポート、メッセージングサービスなどのアプリケーションレベルのサービスをサポートするためのコンポーネントと機能があります。
• Webサーバーは静的コンテンツや動的コンテンツ用のアプリケーションサーバーに適しているため、ほとんどの実稼働環境ではWebサーバーがアプリケーションサーバーへのリバースプロキシとして機能しています。つまり、ページリクエストを処理している間は、リクエストを解釈するWebサーバーによって静的コンテンツ（images / Static HTMLなど）が配信されます。ある種のフィルタリング技術（主に要求されたリソースの拡張）を使用してWebサーバーは動的コンテンツ要求を識別し、透過的にアプリケーションサーバーに転送します

そのような構成の例は、Apache Tomcat HTTP ServerおよびOracle（以前のBEA）WebLogic Serverです。 Apache Tomcat HTTPサーバーはWebサーバーであり、Oracle WebLogicはアプリケーションサーバーです。

場合によっては、サーバーはIISや.NET Runtimeのように緊密に統合されています。 IISはWebサーバーです。 .NETランタイム環境を備えている場合、IISはアプリケーションサービスを提供できます。

• JBoss（現在はWildFly）もアプリケーションサーバーの有名な例です。D - KNU
• ガラス魚も。 - Revanth Kumar
• Webサーバーの代わりにアプリケーションサーバーを使用できるので、Webサーバーとアプリケーションサーバーの両方を単一のアプリケーションに使用する利点は何ですか。そしてパフォーマンスの面で最良の選択肢は何でしょうか。 - Lalinda Sampath
• " Apache Tomcat HTTPサーバーはWebサーバーであり、Oracle WebLogicはアプリケーションサーバーです。つまり、まず第一に、Apache TomcatとApache HTTPサーバーは2つの異なる製品です。これは正確な説明ではありません。 Apache Tomcatはアプリケーションサーバーです。もちろん、Webページも提供できますが、Javaをデプロイするためのアプリケーションサーバーです。私は「Webサーバー」という用語をよく使用しています。ゆるく。しかしそれは人々を混乱させるだけです。 - ironarm
• Apache TomcatはWebサーバーではなく、Javaサーブレットを実行するアプリケーションサーバーです。 Apache HTTPサーバーはWebサーバーです。 Apache Tomcat HTTPサーバーと呼ばれるサーバーはありません。 - Abhishek Pathak

両方の用語は非常に一般的で、一方が他方を含み、場合によってはその逆もあります。

• Webサーバー：httpプロトコルを使用してコンテンツをWebに配信します。

• アプリケーション・サーバー：ビジネスロジックとプロセスをホストし、公開します。

重要な点は、Webサーバーはhttpプロトコルを介してすべてを公開するのに対し、アプリケーションサーバーはそれに限定されないことです。

とはいえ、多くのシナリオでは、Webサーバーがアプリケーションサーバーのフロントエンドの作成に使用されていることがわかります。つまり、Webサーバーに組み込まれているビジネスルールと対話できるWebページのセットが公開されます。アプリケーション・サーバー。

これは、違い、類似性、および両方が連携して機能する方法をすべて理解するための、いくつかのシナリオに関する詳細な回答です。

アプリケーション・サーバー時々混在する用語ですWebサーバー。 Webサーバーが主に処理している間HTTPプロトコルアプリケーションサーバーは、次のようないくつかの異なるプロトコルを処理します。HTTPに限定されない。

Webサーバーの主な仕事は、サイトのコンテンツを表示するアプリケーションサーバーはロジックを担当すなわち、ユーザと表示されたコンテンツとの間の相互作用。アプリケーションサーバーは一緒に働く一方が表示され、もう一方が対話するWebサーバーと。

サーバーとそのクライアントの間を行ったり来たりする情報は、単純な表示マークアップだけでなく、その2つの間の対話にも限定されています。

ほとんどの場合、サーバーはこれを作成します。コンポーネントAPIを介した対話、 といったJ2EE（Java 2プラットフォーム）、EJB（Enterprise JavaBean）そして他の異なるアプリケーションソフトウェアモデル。

例：

アプリケーションサーバーがWebサーバーと連携するシナリオと、アプリケーションサーバーがないシナリオとの違いを理解する最良の方法は、オンラインストアを使用することです。

シナリオ1：アプリケーションサーバーのないWebサーバー

Webサーバーだけがあり、アプリケーションサーバーはないオンラインストアがあります。このサイトには、商品を選択できる画面が表示されます。クエリを送信すると、サイトは検索を実行してHTMLの結果をクライアントに返します。 Webサーバはあなたの問い合わせをデータベースサーバに直接送信し（辛抱強く、これについては次のナゲットで説明します）、応答を待ちます。受信すると、Webサーバーは応答をHTMLファイルに定式化してWebブラウザに送信します。サーバーとデータベースサーバー間のこの双方向の通信は、クエリが実行されるたびに行われます。

シナリオ2：Webサーバーとアプリケーションサーバー

実行するクエリがすでに実行済みで、それ以降データが変更されていない場合、サーバは要求をデータベースサーバに送信しなくても結果を生成します。これにより、別の重複クエリをデータベースサーバに送信せずに、2番目のクライアントが同じ情報にアクセスして信頼性の高いリアルタイムの情報を受信できるリアルタイムクエリが可能になります。サーバーは基本的にデータベースサーバーとWebサーバーの間の仲介役として機能します。この情報は特定の「カスタマイズされた」HTMLページに埋め込まれているため、最初のシナリオでは、プルされた情報を再利用可能にできます。これは再利用可能なプロセスではありません。 2番目のクライアントは、情報をもう一度要求し、要求された情報を含む別のHTML埋め込みページを受け取る必要があります。非常に非効率的です。言うまでもなく、このタイプのサーバーは、セキュリティー、トランザクション処理、メッセージング、およびリソースプールなど、独自のリソースを管理することができるため、非常に柔軟です。

このようなさまざまな複雑なタスクをサポートするために、このサーバーには冗長性、優れた処理能力、大量のRAMが組み込まれている必要があります。

お役に立てれば。

• これは、Webアプリケーションであっても正確ではありません（つまり、アプリケーションサーバーという用語はWeb以外のアプリケーションにも適用されます）。 Webのみを考慮する：Webサーバーには、Web要求（http）を処理するためのソフトウェア（apache、nginx）が含まれています。アプリケーションサーバはアプリケーション（例えばphpコード）を含む／公開する。たとえば、あるマシン（ウェブサーバー）のnginxが、異なるマシン（アプリケーションサーバー）のphp-fpmにリクエストを転送しないのは普通と考えられます。 tそれ自身には任意のhttpアクセス権があります（php-fpm自体のためにポートを公開するだけです）。 - AD7six
• @ AD7six WebサーバーはHTTP要求を排他的に処理しますが、アプリケーションサーバーはHTTPを含む任意の数のプロトコルを通じてアプリケーションプログラムへのビジネスロジックを処理します。 - Durai Amuthan.H
• 私のポイントはアプリケーションサーバーですよろしくhttpリクエストを処理するため、これは必須ではありません。the application server deals with several different protocols, including, but not limited, to HTTP< - それは間違いなくhttpリクエストを処理すると言っています - これは正確ではありません。 - AD7six
• 与えられた例をもう一度読んだ後、私はここで本当の明快さを見ません - 記述は主にキャッシングに関連しています。明らかになったのは、Webサーバーはソフトウェア、アプリケーションはソフトウェアだということです。それらが同じマシンにデプロイされている場合は、そのマシンを参照できます。それらが異なるマシン上にある場合は、Webサーバーを実行しているものを参照するのが普通です。としてWebサーバー、およびアプリケーションをアプリケーションサーバーとして実行しているもの。あなたは通常、負荷と負荷分散に従って物事を分割します。全体的に見て、この回答では何も役に立つものではありません。 - AD7six
• @ AD7six私の答えは他の答えを補完することを意味しています。すなわち、他の答えはすでにあなたがそれに対する拡張だけを求めたということを意味しています。 - Durai Amuthan.H

Ruteshとjmserveraが指摘したように、この区別はあいまいです。歴史的に、それらは異なっていました、しかし90年代を通してこれら二つの以前は異なったカテゴリーは特徴を混ぜ合わせて効果的にマージしました。現時点では、 "App Server"製品カテゴリは "Webサーバー"カテゴリの厳密なスーパーセットであると考えるのがおそらく最善です。

いくつかの歴史Mosaicブラウザとハイパーリンクされたコンテンツの初期の頃には、HTTPを介してWebページのコンテンツと画像を提供する「Webサーバー」と呼ばれるものが進化しました。コンテンツの大部分は静的であり、HTTP 1.0プロトコルはファイルを配布するための単なる方法です。すぐに「Webサーバー」カテゴリは、動的コンテンツを生成するために各Web要求で効果的にプロセスを起動するCGI機能を含むように進化しました。 HTTPも成熟し、キャッシング、セキュリティ、および管理機能を備えた製品はより洗練されたものになりました。技術が成熟するにつれて、私たちはKivaとNetDynamicsから会社固有のJavaベースのサーバーサイド技術を得ました。そして、それらは最終的にすべてJSPに統合されました。 Microsoftは、1996年にASPをWindows NT 4.0に追加しました。静的Webサーバーはいくつかの新しいトリックを習得していたので、多くのシナリオで効果的な「アプリケーションサーバー」でした。

パラレルカテゴリでは、アプリサーバーは長い間進化していました。 Tuxedo、TopEnd、EncinaなどのUNIX向けの製品は、IMSやCICSなどのメインフレームのアプリケーション管理および監視環境から哲学的に派生した製品で提供されていました。 Microsoftが提供する製品はMicrosoft Transaction Server（MTS）で、後でCOM +に進化しました。これらの製品のほとんどは、「太った」クライアントをサーバーに相互接続するための「クローズド」製品固有の通信プロトコルを指定していました。 （Encinaの場合はcommsプロトコルはDCE RPC、MTSの場合はDCOMなどでした。）1995/96年に、これらの従来のアプリケーションサーバー製品は、最初はゲートウェイ経由で基本的なHTTP通信機能を組み込み始めました。そして線がぼやけ始めました。

Webサーバーは、より高い負荷、より多くの並行性、およびより優れた機能の処理に関してますます成熟しています。アプリケーションサーバーは、ますます多くのHTTPベースの通信機能を提供していました。

この時点で、「アプリケーションサーバー」と「Webサーバー」の間の線はあいまいです。しかし、人々は強調の問題として、この用語を違う意味で使い続けています。誰かが「Webサーバー」と言うときは、HTTP中心のWeb UI指向のアプリをよく考えます。誰かが「アプリケーションサーバー」と言うと、「より重い負荷、エンタープライズ機能、トランザクションとキュー、マルチチャネル通信（HTTP以上）」と思うかもしれませんが、多くの場合、両方のワークロード要件を満たすのは同じ製品です。

• WebSphere、IBMの「アプリケーションサーバー」には独自のバンドルWebサーバーがあります。
• もう1つの従来のアプリケーションサーバーであるWebLogic。
• MicrosoftのApp ServerであるWindowsは（そのFile&Print Server、Media Serverなどに加えて）IISをバンドルしています。

• 非常に明確な答えです。ただし、新しいトリックについてもう少し詳しく説明してください。これにより、Webサーバーはアプリケーションサーバーとして機能することができました。 - Quazi Irfan
• 「新しいトリック」サーバー側のロジックを実行することを意味します。 ASPなどのスクリプトロジック元の「ウェブサーバー」ファイルシステムから静的コンテンツを返しました。私たちは今、それから長い道のりを歩んでいます。 - Cheeso

Webサーバー

実行するpython -m 'SimpleHTTPServer'そしてに行くhttp://localhost:8080。あなたが見ているものはその働きでウェブサーバです。サーバーは単にあなたのコンピューターに保存されているHTTP経由でファイルを提供します。重要な点は、これらすべてがHTTPプロトコルの上で行われることです。例えば全く同じこと（保存されたファイルを提供する）をするが、異なるプロトコルの上にあるFTPサーバーも存在します。

アプリケーション・サーバー

以下のような小さなアプリケーションがあるとします。フラスコ）

@app.route('/')
def homepage():
    return '<html>My homepage</html>'

@app.route('/about')
def about():
    return '<html>My name is John</html>'

小さなサンプルプログラムはURLをマッピングします/機能へhomepage()そしてその/about機能へabout()。

このコードを実行するには、アプリケーションサーバー、つまりクライアントからの要求を待機してコードを使用して何かを動的に返すことができるプログラムまたはモジュールが必要です。例では、非常に悪いHTMLを返すだけです。

他のすべての人が話しているビジネスロジックは何ですか？さて、URLはコードベースのどこかにマッピングされているので、プログラムがどのように機能するかについての論理を仮定的に示しています。

再キャッピング

Webサーバー - どこかに保存されているファイルを提供します（最も一般的には.css、.html、.js）。一般的なWebサーバーは、Apache、Nginx、さらにはPythonのSimpleHTTPServerです。

アプリケーション・サーバー - その場で生成されたファイルを提供します。基本的にほとんどのWebサーバーはある種のプラグインを持っているか、あるいはそれをするための組込み機能さえ持っています。 Gunicorn（Python）、Unicorn（Ruby）、uWSGI（Python）などの厳格なアプリケーションサーバーもあります。

実際には、アプリケーションサーバーのコードを使ってWebサーバーを構築することができます。これは開発中に、コンピュータ上でさまざまなサーバーを実行したくない場合があります。

• これが最善かつ最も簡潔な答えです。 Webサーバーをアプリケーションサーバーのサブセットと見なすことができるかどうか疑問に思いました。現在のところ、Webサーバーはgetterメソッドのようなもので、アプリケーションサーバーはファクトリメソッドのようなものだと考えています（URLはコンストラクタの引数です：D）。 - user7917402
• 最後に、Pythonの視点を与えてくれてありがとう。このトピックのように言語にとらわれないように見えますが、そうではありません。 EJBを使用したことがない人は、Java指向の答えを明確に理解できないでしょう。 - Vikas

これまで多くの人が言ってきたように、WebサーバーはHTTP請願を処理しますが、アプリケーションサーバーは分散コンポーネントの請願を処理します。 したがって、違いを理解する最も簡単な方法は、2つの製品を、それらが提供するプログラミング環境に関して比較することです。

Webサーバ - >プログラミング環境

IIS、ASP（.NET）

Tomcat：サーブレット

桟橋：サーブレット

アパッチ：Php、CGI

アプリケーションサーバー - >プログラミング環境

MTS：COM +

WAS：EJB

JBoss：EJB

WebLogicアプリケーションサーバー：EJB

重要な違いは、アプリケーションサーバーがいくつかをサポートしていることです。分散コンポーネントリモート呼び出しや分散トランザクションなどの機能を提供するテクノロジEJBJavaの世界ではCOM +Microsoftプラットフォームで。 Httpサーバーは、より単純なプログラミング環境をサポートしています。Microsoftの場合はASP（.NET）、Javaの場合はJSP、Apacheの場合はPHP、CGIなど、サーブレットベースのスクリプトをサポートしています。

ロードバランシング、クラスタリング、セッションフェイルオーバー、接続プーリングなど、以前はアプリケーションサーバーの分野で使用されていたその他の機能が、直接または一部のサードパーティ製品を介してWebサーバーで使用できるようになりました。

最後に、Spring Frameworkのような "軽量コンテナー"を使用すると、アプリケーションサーバーのインフラストラクチャを使用せずに、より単純な方法でアプリケーションサーバーの目的を補完することができ、画像がさらに歪められます。また、アプリケーションにおける分散の側面は、分散コンポーネントからサービスパラダイムおよびSOAアーキテクチャーへと移行しているため、従来のアプリケーションサーバー用のスペースはますます少なくなっています。

• あなたがリストアップしたアプリケーションサーバのうちのどれかがapache httpのようなhttpウェブサーバとして使われることができますか？ - LearningMath

WebサーバーはHTTP / HTTPS要求を排他的に処理します。 HTTP / HTTPSプロトコルを使用してコンテンツをWebに配信します。

アプリケーションサーバーは、HTTPなどのプロトコルをいくつでも使用して、アプリケーションプログラムにビジネスロジックを提供します。アプリケーションプログラムは、オブジェクトのメソッドを呼び出すのと同じようにこのロジックを使用できます。ほとんどの場合、サーバーはJava EE（Java Platform、Enterprise Edition）アプリケーションサーバーにあるEJB（Enterprise JavaBean）コンポーネントモデルなどのコンポーネントAPIを介してこのビジネスロジックを公開します。 重要な点は、Webサーバーはhttpプロトコルを介してすべてを公開するのに対し、アプリケーションサーバーはそれに制限されていないということです。 したがって、アプリケーションサーバーは、通常次のようなWebサーバーよりもはるかに多くのサービスを提供します。

• （プロプライエタリかどうかにかかわらず）API
• 負荷分散、フェイルオーバー...
• オブジェクトライフサイクル管理
• 状態管理（セッション）
• リソース管理（例：データベースへの接続プール）

ほとんどのアプリケーションサーバーは、Webサーバーをその一部として備えています。つまり、App Serverは、Webサーバーができることなら何でも実行できます。さらに、App Serverには、コネクションプーリング、オブジェクトプーリング、トランザクションサポート、メッセージングサービスなどのアプリケーションレベルのサービスをサポートするためのコンポーネントと機能があります。

アプリケーションサーバーは（常にではありませんが）プログラムロジックを実行するためにWebサーバー上で実行でき、その結果はWebサーバーによって配信されます。これは、Webサーバー/アプリケーションサーバーのシナリオの一例です。 Microsoftの世界における良い例は、Internet Information ServerとSharePoint Serverの関係です。 IISはWebサーバーです。 SharePointはアプリケーションサーバーです。 SharePointはIISの最上位に位置し、特定のロジックを実行し、IISを介して結果を提供します。 Javaの世界では、例えばApacheやTomcatと似たようなシナリオがあります。

Webサーバーは静的コンテンツや動的コンテンツ用のアプリケーションサーバーに適しているため、ほとんどの実稼働環境ではWebサーバーがアプリケーションサーバーへのリバースプロキシとして機能しています。つまり、ページ要求を処理している間、images / Static htmlなどの静的コンテンツは、要求を解釈するWebサーバーによって提供されます。ある種のフィルタリング技術（主に要求されたリソースの拡張）を使用して、Webサーバーは動的コンテンツ要求を識別し、透過的にアプリケーションサーバーに転送します。

そのような構成の例は、Apache HTTP ServerとBEA WebLogic Serverです。 Apache HTTPサーバーはWebサーバーで、BEA WebLogicはアプリケーションサーバーです。 場合によっては、IISと.NET Runtimeのようにサーバーが緊密に統合されています。 IISはWebサーバーです。 .NETランタイム環境が装備されている場合、IISはアプリケーションサービスを提供できます。

Web Server                               Programming Environment
Apache                                   PHP, CGI
IIS (Internet Information Server)        ASP (.NET)
Tomcat                                   Servlet
Jetty                                    Servlet

Application Server                       Programming Environment
WAS (IBM's WebSphere Application Server) EJB
WebLogic Application Server (Oracle's)   EJB
JBoss AS                                 EJB
MTS                                      COM+

一言で言えばWebサーバーhttp経由でユーザーにWebページを提供するサーバーです。あアプリケーション・サーバーシステムのビジネスロジックをホストするサーバーです。多くの場合、長時間実行/バッチプロセスおよび/または人が消費することを意図していない相互運用サービス（REST / JSONサービス、SOAP、RPCなど）の両方をホストします。

• 「ホスト」という用語がビジネスロジックを表す用語は何ですか。平均？それはどのように行われますか？ - TwiggedToday
• ビジネスロジックはWebサービスを通じてクライアントに公開されていますか？ - TwiggedToday
• ウェブサービス経由で配信することも、他のインターフェース（TCP、MQ、共有上のフラットファイル（最後には推奨しません））から配信することもできます。 - C. Ross
• これは誤解を招く可能性があります。アプリケーションサーバーは何もホストしていません。あなたのコードはビジネスロジックをホストし、アプリケーションサーバーはそれとユーザーが要求するWebページの間の接着剤として機能します。 - Pithikos

Webサーバーとアプリケーションサーバーの主な違いは、Webサーバーが静的ページを提供することを目的としていることです。一方、Application Serverはサーバーサイドコードを実行することで動的コンテンツを生成します。 JSP、サーブレット、またはEJB。

どちらを使うべきですか？

Webとアプリケーションサーバー、およびWebコンテナの違いがわかれば、いつ使用するかを簡単に判断できます。 あなたには必要だweb server静的Webページを提供している場合は、Apache HTTPDと同じです。動的コンテンツを生成するためのJSPとサーブレットのみを含むJavaアプリケーションがある場合は、次のものが必要です。web containersTomcatやJettyのように。ながら、EJBを使用したJava EEアプリケーション、分散トランザクション、メッセージング、およびその他の優れた機能がある場合あなたが本格的に必要なものよりapplication serverJBoss、WebSphere、またはOracleのWebLogicのように。

WebコンテナはWeb Serverの一部であり、Web ServerはApplication Serverの一部です。

WebサーバーはWebコンテナーで構成されていますが、Application ServerはWebコンテナーとEJBコンテナーで構成されています。

通常、アプリケーションサーバーは、実行時間が長くなるプロセスを容易にするように設計および配置されています。

Webサーバーは、一般的にリソースを消費しない短いバーストに使用されます。これは主にWebベースのトラフィックの処理を容易にするためのものです。

WebサーバーはWebページを提供するためにHTTPプロトコルを実行します。アプリケーションサーバーは（常にではありませんが）プログラムロジックを実行するためにWebサーバー上で実行でき、その結果はWebサーバーによって配信されます。これは、Webサーバー/アプリケーションサーバーのシナリオの一例です。

Microsoftの世界における良い例は、Internet Information ServerとSharePoint Serverの関係です。 IISはWebサーバーです。 SharePointはアプリケーションサーバーです。 SharePointはIISの最上位に位置し、特定のロジックを実行し、IISを介して結果を提供します。

Javaの世界では、例えばApacheやTomcatと似たようなシナリオがあります。

一方で、WebサーバーはHTTPプロトコルを介してWebコンテンツ（HTMLおよび静的コンテンツ）を提供します。一方、アプリケーションサーバーは、HTTPを含むさまざまなプロトコルを介してビジネスロジックとプロセスを構築し、クライアントアプリケーションに公開するためのコンテナです。

したがって、アプリケーションサーバーは、通常次のようなWebサーバーよりもはるかに多くのサービスを提供します。

• （プロプライエタリかどうかにかかわらず）API
• オブジェクトライフサイクル管理
• 状態管理（セッション）
• リソース管理（例：データベースへの接続プール）
• 負荷分散、フェイルオーバー...

私の知る限り、ATGディナモ（上記の定義によると）90年代後半の最初のアプリケーションサーバーの1つでした。 2000年の初め頃、それは次のようないくつかのプロプライエタリなアプリケーションサーバーの統治でした。ColdFusion（CFML AS）ブロードビジョン（サーバーサイドJavaScript AS）などしかし、Javaアプリケーションサーバー時代を生き残ったものはありません。

これら2つの間の境界はこれまでになく薄くなっています。

アプリケーションサーバーは、ビジネスロジックをクライアントに公開します。そのため、そのようなアプリケーションサーバーは、ビジネスロジックを実行するための一連のメソッドで構成されています（必ずしもそうとは限りませんが、多くのユーザーがソフトウェアを実行できるネットワークコンピュータでもかまいません）。そのため、HTMLコンテンツではなく、単純に目的の結果が出力されます。 （メソッド呼び出しに似ています）。そのため、厳密にはHTTPベースではありません。

しかし、WebサーバーはHTMLコンテンツをWebブラウザに渡します（厳密にはHTTPベース）。 Webサーバーは静的Webリソースしか処理できませんでしたが、サーバーサイドスクリプティングの出現により、Webサーバーは動的コンテンツも処理できました。 Webサーバーがリクエストを受け取り、それをスクリプト（PHP、JSP、CGIスクリプトなど）に送信して、クライアントに送信するHTMLコンテンツを作成する場所。それからウェブサーバはそれらをクライアントに送り返す方法を知っています。 Webサーバが本当に知っているのはそのためです。

とは言っても、今日では開発者はこれらの両方を一緒に使用しています。 Webサーバーが要求を受け取ってからスクリプトを呼び出してHTMLを作成する場合、BUTスクリプトは再びアプリケーションサーバーのLOGIC（例：トランザクション詳細の取得）を呼び出して、HTMLコンテンツを埋めます。

そのため、この場合は両方のサーバーが効果的に使用されました。

だから.... 今日では、ほとんどの場合、Webサーバーがアプリケーションサーバーのサブセットとして使用されているとかなり安全に言えます。しかし、演劇的にはそうではありません。

私はこのトピックに関する多くの記事を読み、見つけましたこの記事はかなり便利です。

Javaの用語ではもう1つあります。Webコンテナ（厳密にはサーブレットコンテナ）たとえば、Webサーバーとアプリケーションサーバーの間です。 Java用語でのWebコンテナは、基本的にはアプリケーションサーバーです。のみJava EEのJSP /サーブレット部分を実装し、EJBサポートなど、Java EEのいくつかのコア部分を欠いています。例はApache Tomcatです。

アプリケーションサーバーは、クライアントが提供するサービスを問わず、クライアントからの要求を（任意のチャネルで、任意のプロトコルを使用して）「待機」し、その要求に基づいて何かを実行するマシン（実際には何らかのマシンで実行される実行可能プロセス）です。 （クライアントに責任を負うかどうかは関係ありません）

Webサーバーは、「インターネット」プロトコル（http、https、ftpなど）の1つを使用してTCP / IPチャネルで特に「待機」し、それらの着信要求に基づいて行うことをすべて実行するマシン上で実行されているプロセスです。 ..（元々定義されているように）一般的に、サーバー上の静的HTMLファイルから取得するか、着信クライアント要求のパラメータに基づいて動的に構築するかのいずれかで、HTML Webページを取得/生成してクライアントに返しました。

• バスケースの例を教えてください。 - frewper
• 両方の例を教えてください。ありがとう。 - LearningMath

上記のすべては、非常に単純なものを過度に複雑にしているだけです。アプリケーションサーバーにはWebサーバーが含まれています。アプリケーションサーバーには、標準のWebサーバーよりも2、3の追加/拡張があります。例としてTomEEを見ると：

CDI - Apache OpenWebBeans
EJB - Apache OpenEJB
JPA - Apache OpenJPA
JSF - Apache MyFaces
JSP - Apache Tomcat
JSTL - Apache Tomcat
JTA - Apache Geronimo Transaction
Servlet - Apache Tomcat
Javamail - Apache Geronimo JavaMail
Bean Validation - Apache BVal

Tomcat（Webコンテナ/サーバー）は、アプリサーバーの別のツールにすぎません。必要に応じて、JPAやその他の技術をWebサーバーに取り込むこともできますが、アプリケーションサーバーはこれらすべてをパッケージ化したものです。アプリサーバーとして完全に分類されるためには、基本的に何らかの標準によって定められたツールのリストに従う必要があります。

最大の違いは、WebサーバーがHTTP要求を処理するのに対し、アプリケーションサーバーは任意の数のプロトコルでビジネスロジックを実行することです。

明確な境界線は必ずしもありません。今日では、多くのプログラムが両方の要素を組み合わせています。httpリクエストを処理する（Webサーバー）とビジネスロジックを処理する（アプリケーションサーバー）

実際にはApacheはWebサーバーであり、Tomcatはアプリケーションサーバーです。 HTTPリクエストがWebサーバーに届いたとき。その後、静的コンテンツはWebサーバーによってブラウザに返送されます。そこにありそして論理がするべきであり、それからその要求はアプリケーションサーバーに送られる。ロジックを処理した後、応答はWebサーバーに送信され、クライアントに送信されます。

アプリケーションサーバーとWebサーバーはどちらもWebアプリケーションをホストするために使用されます。一方、Web ServerはWebコンテナを処理しますが、Application ServerはWebコンテナおよびEJB（Enterprise JavaBean）コンテナ、またはMicrosoft dot Net用のCOM +コンテナを処理します。

Webサーバーは、HTML、画像などのHTTP静的コンテンツを提供するように設計されています。動的コンテンツには、Perl、PHP、ASP、JSPなどのスクリプト言語をサポートするプラグインがあり、HTTPプロトコルに限定されます。以下のサーバーは動的HTTPコンテンツを生成できます。

Webサーバーのプログラミング環境

IIS、ASP（.NET）

Apache Tomcat：サーブレット

桟橋：サーブレット

アパッチ：Php、CGI

Application Serverは、接続プーリング、オブジェクトプーリング、トランザクションサポート、メッセージングサービスなどのアプリケーションレベルのサービスをサポートするためのコンポーネントと機能を備えているだけでなく、Webサーバーが対応し、あらゆるプロトコルを使用して待機します。

アプリケーションサーバのプログラミング環境

MTS：COM +

WAS：EJB

JBoss：EJB

WebLogicアプリケーションサーバー：EJB

両者の間にオーバーラップがあるかもしれませんが（いくつかのWebサーバーはアプリケーションサーバーとして使用されるかもしれません）、最大の違いは、処理モデルとセッション管理にあります。

Webサーバー処理モデルでは、焦点は要求の処理にあります。 「セッション」の概念はほとんど仮想的です。つまり、「セッション」はクライアントとサーバーの間で状態の表現（つまりREST）を転送したり、外部の永続的な記憶領域（SQL Server、Memcachedなど）にシリアル化したりすることによってシミュレートされます。

アプリケーションサーバでは、セッションは通常、より明示的であり、「セッション」の全期間にわたってアプリケーションサーバのメモリ内に存在するオブジェクトの形をとることがよくあります。

からhttps://en.wikipedia.org/wiki/Web_server

AWebサーバーWorld Wide Web上で情報を配信するために使用される基本的なネットワークプロトコルであるHTTPを介して要求を処理するコンピュータシステムです。この用語は、システム全体、または具体的にはそのソフトウェアを指すことができます。HTTPリクエストを受け入れて監視します。。

からhttps://en.wikipedia.org/wiki/Application_server#Application_Server_definition

アプリケーションサーバーがWebサーバーの背後で動作している（たとえば、Apacheまたはマイクロソフトのインターネットインフォメーションサービス（IIS））および（ほとんどの場合）SQLデータベース（たとえばPostgreSQL、MySQL、またはOracle）の前。

Webアプリケーションアプリケーションサーバー上で実行され、アプリケーションサーバーがサポートする言語で記述され、ランタイムライブラリとコンポーネントを呼び出すコンピュータコードです。アプリケーションサーバーオファー。

それは特定のアーキテクチャに依存します。一部のアプリケーションサーバーは、Webプロトコルをネイティブに使用する場合があり（HTTP上のXML / RPC / SOAP）、技術的な違いはほとんどありません。通常、Webサーバーはユーザー向けで、HTTP / HTTPS経由でさまざまなコンテンツを提供しますが、アプリケーションサーバーはユーザー向けではなく、非標準またはルーティング不可能なプロトコルを使用することがあります。もちろん、RIA / AJAXでは、その違いはさらに曇り、特定のリモートアクセスサービスを提供しているクライアントには非HTMLコンテンツ（JSON / XML）しか提供されません。

IMO、それは主に懸念を切り離すことについてです。

純粋に技術的な観点からは、すべて（Webコンテンツ+ビジネスロジック）を単一のWebサーバーで実行できます。あなたがそうするならば、情報は要求されたHTMLコンテンツの中に埋め込まれるでしょう。影響は何ですか？

たとえば、まったく異なるHTMLコンテンツをブラウザに表示する2つの異なるアプリケーションがあるとします。ビジネスロジックをアプリケーションサーバーに分離するのであれば、スクリプトを使用してアプリケーションサーバー内の同じデータを検索する別のWebサーバーを提供することができます。ただし、ビジネスモデルを変更するたびにロジックを分離してWebサーバーに保存しないと、最終的には時間がかかり、信頼性が低下し、すべてのWebサーバーで変更することになります。エラーを起こしやすい。