アプリケーションサーバーとWebサーバーの違いは何ですか？
回答:
ほとんどの場合、これらの用語のWebサーバーとアプリケーションサーバーは同じ意味で使用されます。
次に、Webサーバーとアプリケーションサーバーの機能の主な違いをいくつか示します。
- Webサーバーは、HTTPコンテンツを提供するように設計されています。App ServerはHTTPコンテンツも提供できますが、HTTPだけに限定されません。RMI / RPCなどの他のプロトコルサポートを提供できます。
- ほとんどのWebサーバーには、Perl、PHP、ASP、JSPなどのスクリプト言語をサポートするプラグインがあり、これらのサーバーを介して動的なHTTPコンテンツを生成できます。
- ほとんどのアプリケーションサーバーにはWebサーバーが組み込まれています。つまり、アプリケーションサーバーはWebサーバーが実行できるすべてのことを実行できます。さらに、App Serverには、接続プーリング、オブジェクトプーリング、トランザクションサポート、メッセージングサービスなどのアプリケーションレベルのサービスをサポートするコンポーネントと機能があります。
- Webサーバーは静的コンテンツに適し、アプリサーバーは動的コンテンツに適しているため、ほとんどの本番環境には、アプリサーバーのリバースプロキシとして機能するウェブサーバーがあります。つまり、ページリクエストの処理中に、静的コンテンツ（画像/静的HTMLなど）は、リクエストを解釈するWebサーバーによって処理されます。ある種のフィルタリング技術（主に要求されたリソースの拡張）を使用して、動的コンテンツ要求を識別し、透過的にアプリサーバーに転送
このような構成の例は、Apache Tomcat HTTPサーバーおよびOracle（以前のBEA）WebLogicサーバーです。Apache Tomcat HTTPサーバーはWebサーバーであり、Oracle WebLogicはアプリケーションサーバーです。
IISや.NETランタイムなど、サーバーが緊密に統合されている場合もあります。IISはWebサーバーです。IISは、.NETランタイム環境を備えていると、アプリケーションサービスを提供できます。
これは詳細な回答であり、いくつかのシナリオで違い、類似性、および両方がどのように連携して機能するかを明確に理解するためのものです。
アプリケーションサーバーは、ウェブサーバーと混在することもあります。Webサーバーは主にHTTPプロトコルを処理しますが、アプリケーションサーバーはHTTPを含むがこれに限定されないいくつかの異なるプロトコルを扱います。
Webサーバーの主な仕事はサイトのコンテンツを表示することであり、アプリケーションサーバーはロジックと、ユーザーと表示されたコンテンツとの間のやり取りを担当します。アプリケーションサーバーは、一方が表示され、もう一方が相互作用するWebサーバーと連携して動作しています。
サーバーとそのクライアントの間でやり取りされる情報は、単純な表示マークアップだけでなく、2つの間の相互作用に限定されます。
ほとんどの場合、サーバーは、J2EE（Java 2プラットフォーム）、EJB（エンタープライズJavaBean）、その他のさまざまなアプリケーションソフトウェアモデルなどのコンポーネントAPIを介してこの対話を作成します。
例：
アプリケーションサーバーがWebサーバーと連携するシナリオと、アプリケーションサーバーがないシナリオとの違いを理解するには、オンラインストアが最適です。
シナリオ1：アプリケーションサーバーのないWebサーバー
Webサーバーのみがあり、アプリケーションサーバーがないオンラインストアがあります。このサイトでは、製品を選択できるディスプレイが提供されます。クエリを送信すると、サイトは検索を実行し、HTML結果をクライアントに返します。Webサーバーはクエリを直接データベースサーバーに送信し（しばらくお待ちください。これは次のナゲットで説明します）、応答を待ちます。受信すると、Webサーバーは応答をHTMLファイルに作成し、それをWebブラウザーに送信します。サーバーとデータベースサーバー間のこのやり取りは、クエリが実行されるたびに行われます。
シナリオ2：アプリケーションサーバーを備えたWebサーバー
実行するクエリが既に実行されており、それ以降データが変更されていない場合、サーバーはデータベースサーバーに要求を送信する必要なく結果を生成します。これにより、2番目のクライアントがデータベースサーバーに別の重複するクエリを送信せずに、同じ情報にアクセスしてリアルタイムで信頼性の高い情報を受信できるリアルタイムクエリが可能になります。サーバーは基本的に、データベースサーバーとWebサーバーの中間として機能します。これにより、最初のシナリオでプルされた情報を再利用できるようになります。この情報は特定の「カスタマイズされた」HTMLページに埋め込まれているため、これは再利用可能なプロセスではありません。2番目のクライアントは再び情報を要求し、要求された情報を含む別のHTML埋め込みページを受信する必要があります。
このようなさまざまな複雑なタスクをサポートするには、このサーバーに冗長性、優れた処理能力、大量のRAMを組み込み、リアルタイムで取得するすべてのデータを処理する必要があります。
お役に立てれば。
the application server deals with several different protocols, including, but not limited, to HTTP<-それは間違いなくhttpリクエストを処理すると言っています-正確ではありません
どちらの用語も非常に一般的であり、一方が他方を含み、場合によってはその逆もあります。
Webサーバー：httpプロトコルを使用してコンテンツをWebに提供します。
アプリケーションサーバー：ビジネスロジックとプロセスをホストおよび公開します。
重要な点は、アプリケーションサーバーはそれに限定されないが、Webサーバーはhttpプロトコルを通じてすべてを公開することだと思います。
つまり、多くのシナリオでは、Webサーバーがアプリケーションサーバーのフロントエンドの作成に使用されていることがわかります。つまり、Webサーバーは、ユーザーがアプリケーション・サーバー。
ウェブサーバー
実行python -m 'SimpleHTTPServer'してhttp：// localhost：8080にアクセスします。表示されているのは、動作しているWebサーバーです。サーバーは、コンピュータに保存されているHTTP経由でファイルを提供するだけです。重要な点は、これらすべてがHTTPプロトコル上で行われるということです。たとえば、まったく同じことをする（保存されたファイルを提供する）FTPサーバーも存在しますが、プロトコルは異なります。
アプリケーション・サーバー
以下のような小さなアプリケーションがあるとします（Flaskからのスニペット）。
@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()。
このコードを実行するには、アプリケーションサーバー（Gunicornなど）-クライアントからの要求をリッスンし、コードを使用して動的に何かを返すことができるプログラムまたはモジュールが必要です。この例では、非常に悪いHTMLを返すだけです。
他のすべての人が話すビジネスロジックは何ですか？さて、URLはコードベースの特定の場所にマッピングされているため、プログラムの動作に関するロジックを仮想的に示しています。
再キャップ
Webサーバー -どこかに保存されているファイルを提供します（最も一般的には.css、.html、.js）。一般的なWebサーバーは、Apache、Nginx、またはPythonのSimpleHTTPServerです。
アプリケーションサーバー -その場で生成されたファイルを提供します。基本的に、ほとんどのWebサーバーにはある種のプラグインがあり、それを行うための組み込み機能が備わっています。Gunicorn（Python）、Unicorn（Ruby）、uWSGI（Python）などの厳密なアプリケーションサーバーも存在します。
アプリケーションサーバーのコードを使用して、実際にWebサーバーを構築できることに注意してください。これは、コンピュータ上で実行されている膨大な数の異なるサーバーを使用したくない場合に、開発中に行われます。
Ruteshとjmserveraが指摘したように、区別はあいまいです。歴史的には、それらは異なっていましたが、90年代を通じて、これらの2つの以前は異なるカテゴリが機能をブレンドし、効果的にマージしました。この時点で、「App Server」製品カテゴリが「Webサーバー」カテゴリの厳密なスーパーセットであることを想像するのがおそらく最善です。
いくつかの歴史。Mosaicブラウザーとハイパーリンクされたコンテンツの初期の頃には、HTTPを介してWebページのコンテンツと画像を提供する「Webサーバー」と呼ばれるものが進化しました。ほとんどのコンテンツは静的であり、HTTP 1.0プロトコルはファイルを配布するための単なる手段でした。すぐに「Webサーバー」カテゴリはCGI機能を含むように進化しました-動的コンテンツを生成するために各Web要求でプロセスを効果的に起動します。HTTPも成熟し、キャッシング、セキュリティ、および管理機能を備えた製品はより洗練されました。テクノロジーが成熟するにつれ、KivaとNetDynamicsから会社固有のJavaベースのサーバーサイドテクノロジーを入手し、最終的にはすべてJSPに統合しました。マイクロソフトは、1996年にWindows NT 4.0にASPを追加したと思います。静的Webサーバーはいくつかの新しいトリックを学習していたため、効果的でした」
並行するカテゴリーでは、アプリサーバーは進化し、長い間存在していました。企業は、Tuxedo、TopEnd、EncinaなどのUnix用の製品を提供しました。これらの製品は、IMSやCICSなどのメインフレームアプリケーション管理および監視環境から哲学的に派生したものです。マイクロソフトの製品は、後にCOM +に進化したMicrosoft Transaction Server（MTS）でした。これらの製品のほとんどは、「閉じた」製品固有の通信プロトコルを指定して、「太い」クライアントをサーバーに相互接続しました。（Encinaの場合、通信プロトコルはDCE RPC、MTSの場合はDCOMなどでした。）1995/96年に、これらの従来のアプリサーバー製品は、最初はゲートウェイ経由で基本的なHTTP通信機能を組み込み始めました。そして、線がぼやけ始めました。
Webサーバーは、より高い負荷、同時実行性、およびより優れた機能の処理に関して、ますます成熟しています。アプリサーバーは、ますますHTTPベースの通信機能を提供しました。
この時点で、「アプリサーバー」と「ウェブサーバー」の間の線はあいまいです。しかし、人々は強調の問題として、これらの用語を別の方法で使用し続けています。誰かが「Webサーバー」と言うとき、HTTP中心のWeb UI指向のアプリをよく考えます。誰かが「アプリサーバー」と言うと、「負荷、エンタープライズ機能、トランザクション、キューイング、マルチチャネル通信（HTTPなど）が重い」と思うかもしれませんが、多くの場合、両方のワークロード要件に対応する同じ製品です。
- IBMの「アプリサーバー」であるWebSphereには、独自のWebサーバーがバンドルされています。
- 同様に、もう1つの従来のアプリサーバーであるWebLogic。
- MicrosoftのApp ServerであるWindowsは（File＆Print Server、Media Serverなどであることに加えて）、IISをバンドルしています。
以前に多くの人が言ったように、WebサーバーはHTTP請願を処理し、アプリケーションサーバーは分散コンポーネントの請願を処理します。したがって、違いを理解する最も簡単な方法は、2つの製品が提供するプログラミング環境に関して2つの製品を比較することでしょう。
Webサーバー->プログラミング環境
IIS：ASP（.NET）
Tomcat：サーブレット
Jetty：サーブレット
Apache：Php、CGI
アプリケーションサーバー->プログラミング環境
MTS：COM +
WAS：EJB
JBoss：EJB
WebLogicアプリケーションサーバー：EJB
重要な違いは、アプリケーションサーバーがいくつかの分散コンポーネントテクノロジーをサポートし、JavaのEJBやCOM +などのリモート呼び出しや分散トランザクションなどの機能を提供することです。 Microsoftプラットフォームの。Httpサーバーは、MicrosoftまたはServletベースの場合はASP（.NET）のような、より単純なプログラミング環境をサポートすることが多く、JSPを含むほか、JavaまたはPHPの場合は他の多く、Apacheの場合はCGIをサポートします。
アプリケーションサーバーの領域にあったロードバランシング、クラスタリング、セッションフェイルオーバー、接続プーリングなどの他の機能は、直接または一部のサードパーティ製品を介してWebサーバーでも利用できるようになります。
最後に、Spring Frameworkのような「軽量コンテナ」を使用すると、画像がさらに歪むことに注意する必要があります。これは、アプリケーションサーバーのインフラストラクチャなしで、アプリケーションサーバーの目的をより単純な方法で補足することがよくあります。また、アプリケーションの分散の側面は分散コンポーネントからサービスパラダイムおよびSOAアーキテクチャに移行しているため、従来のアプリケーションサーバーに残されるスペースはますます少なくなっています。
Webサーバーとアプリケーションサーバーの主な違いは、WebサーバーはHTMLやCSSなどの静的ページを提供することを目的としているのに対し、アプリケーションサーバーはJSP、サーブレット、EJBなどのサーバー側コードを実行して動的コンテンツを生成することです。
どちらを使用すればよいですか？
Webとアプリケーションサーバー、およびWebコンテナーの違いを理解すると、それらをいつ使用するかを簡単に理解できます。web server静的なWebページを提供する場合は、Apache HTTPDなどが必要です。動的コンテンツを生成するためのJSPとサーブレットだけのJavaアプリケーションがある場合は、web containersTomcatやJettyなどが必要です。一方、EJB、分散トランザクション、メッセージング、およびその他の高度な機能を使用するJava EEアプリケーションがある場合は、本格的なapplication server JBoss、WebSphere、またはOracleのWebLogicなどのなです。
WebコンテナはWebサーバーの一部であり、Webサーバーはアプリケーションサーバーの一部です。
WebサーバーはWebコンテナーで構成され、アプリケーションサーバーはWebコンテナーとEJBコンテナーで構成されます。
簡単に言うと、Webサーバーは、httpを介してユーザーにWebページを提供するサーバーです。アプリケーションサーバは、システムのビジネス・ロジックをホストするサーバーです。多くの場合、長時間実行/バッチプロセスと人間が使用することを目的としていない相互運用サービス（REST / JSONサービス、SOAP、RPCなど）の両方をホストします。
Webサーバーは、HTTP / HTTPS要求のみを処理します。HTTP / HTTPSプロトコルを使用してWebにコンテンツを提供します。
アプリケーションサーバーは、任意の数のプロトコル（おそらくHTTPを含む）を介してビジネスロジックをアプリケーションプログラムに提供します。アプリケーションプログラムは、オブジェクトのメソッドを呼び出すのと同じように、このロジックを使用できます。ほとんどの場合、サーバーは、Java EE（Java Platform、Enterprise Edition）アプリケーションサーバーにあるEJB（Enterprise JavaBean）コンポーネントモデルなどのコンポーネントAPIを介してこのビジネスロジックを公開します。重要な点は、Webサーバーはhttpプロトコルを介してすべてを公開する一方で、アプリケーションサーバーはそれに限定されないということです。したがって、アプリケーションサーバーは、通常以下を含むWebサーバーよりもはるかに多くのサービスを提供します。
- （独自のAPIかどうかにかかわらず）API
- 負荷分散、フェイルオーバー...
- オブジェクトのライフサイクル管理
- 状態管理（セッション）
- リソース管理（データベースへの接続プールなど）
ほとんどのアプリケーションサーバーにはWebサーバーが組み込まれています。つまり、アプリケーションサーバーはWebサーバーが実行できるすべてのことを実行できます。さらに、App Serverには、接続プーリング、オブジェクトプーリング、トランザクションサポート、メッセージングサービスなどのアプリケーションレベルのサービスをサポートするコンポーネントと機能があります。
アプリケーションサーバーは（常にではありませんが）Webサーバー上で実行してプログラムロジックを実行でき、その結果はWebサーバーによって配信されます。これは、Webサーバー/アプリケーションサーバーのシナリオの一例です。マイクロソフトの世界の良い例は、インターネットインフォメーションサーバーとSharePointサーバーの関係です。IISはWebサーバーです。SharePointはアプリケーションサーバーです。SharePointはIISの「上位」に位置し、特定のロジックを実行し、IISを介して結果を提供します。たとえば、Javaの世界では、ApacheとTomcatを使用した同様のシナリオがあります。
Webサーバーは静的コンテンツに適し、アプリサーバーは動的コンテンツに適しているため、ほとんどの本番環境には、アプリサーバーのリバースプロキシとして機能するウェブサーバーがあります。つまり、ページ要求を処理している間、画像や静的htmlなどの静的コンテンツは、要求を解釈するWebサーバーによって処理されます。ある種のフィルタリング手法（主に要求されたリソースの拡張）を使用して、Webサーバーは動的コンテンツ要求を識別し、透過的にアプリサーバーに転送します。
そのような構成の例は、Apache HTTPサーバーおよびBEA WebLogicサーバーです。Apache HTTPサーバーはWebサーバーであり、BEA WebLogicはアプリケーションサーバーです。場合によっては、サーバーはIISや.NETランタイムなどの緊密に統合されています。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+
これら2つの国境はますます薄くなっています。
アプリケーションサーバーはクライアントにビジネスロジックを公開します。つまり、アプリケーションサーバーは、ビジネスロジックを実行するための一連のメソッドで構成されます（ただし、排他的にではなく、多くの人がソフトウェアを実行できるネットワークコンピュータにすることもできます）。したがって、HTMLコンテンツではなく、必要な結果を出力するだけです。（メソッド呼び出しと同様）。そのため、厳密にHTTPベースではありません。
しかし、WebサーバーはHTMLコンテンツをWebブラウザー（厳密にはHTTPベース）に渡します。Webサーバーは静的なWebリソースしか処理できませんでしたが、サーバー側のスクリプトの出現により、Webサーバーは動的なコンテンツも処理できるようになりました。Webサーバーがリクエストを受け取り、関連するスクリプト（PHP、JSP、CGIスクリプトなど）に送信して、クライアントに送信されるHTMLコンテンツを作成します。コンテンツが受信されると、WebサーバーはHTMLページをクライアントに送信します。
ただし、現在これらのサーバーは両方とも一緒に使用されています。Webサーバーが要求を受け取り、スクリプトを呼び出してHTMLコンテンツを作成します。次に、スクリプトは再びアプリケーションサーバーのLOGIC（トランザクション詳細の取得など）を呼び出して、HTMLコンテンツを入力します。
したがって、両方のサーバーが効果的に使用されます。
したがって...現在、ほとんどの場合、Webサーバーはアプリケーションサーバーのサブセットとして使用されていると言えます。しかし、劇場的にはそうではありません。
私はこのトピックに関する多くの記事を読んだことがあり、この記事は非常に重宝しています。
アプリケーションサーバーは、クライアントからの要求を（任意のチャネルで、任意のプロトコルを使用して）リスンし、提供するサービスをクライアントが要求し、それらの要求に基づいて何かを行うマシン（実際には一部のマシンで実行される実行可能プロセス）です。（クライアントへの応答を伴う場合と伴わない場合があります）
Webサーバーは、「インターネット」プロトコルの1つ（http、https、ftpなど）を使用して、特にTCP / IPチャネルで「リッスン」するマシンで実行されるプロセスであり、それらの着信要求に基づいて、何をするかを行います。 ..通常、（元の定義どおりに）サーバーで静的なhtmlファイルからフェッチされるか、受信クライアントリクエストのパラメーターに基づいて動的に構築されるhtml Webページをフェッチ/生成してクライアントに返します。
WebサーバーはHTTPプロトコルを実行してWebページを提供します。アプリケーションサーバーは、Webサーバー上で実行して（常にではない）プログラムロジックを実行でき、その結果はWebサーバーによって配信できます。これは、Webサーバー/アプリケーションサーバーのシナリオの一例です。
マイクロソフトの世界での良い例は、インターネットインフォメーションサーバーとSharePointサーバーの関係です。IISはWebサーバーです。SharePointはアプリケーションサーバーです。SharePointはIISの「上位」にあり、特定のロジックを実行し、IISを介して結果を提供します。
たとえば、Javaの世界では、ApacheとTomcatを使用した同様のシナリオがあります。
まず、WebサーバーはHTTPプロトコルを介してWebコンテンツ（HTMLおよび静的コンテンツ）を提供します。一方、アプリケーションサーバーは、n層アーキテクチャーのHTTPを含むさまざまなプロトコルを介して、ビジネスロジックとプロセスを構築してクライアントアプリケーションに公開できるコンテナーです。
したがって、アプリケーションサーバーは、通常以下を含むWebサーバーよりもはるかに多くのサービスを提供します。
- （独自のAPIかどうかにかかわらず）API
- オブジェクトのライフサイクル管理、
- 状態管理（セッション）、
- リソース管理（データベースへの接続プールなど）、
- 負荷分散、フェイルオーバー...
AFAIK、ATG Dynamoは、90年代後半の非常に最初のアプリケーションサーバーの1つです（上記の定義によると）。2000年の初めには、ColdFusion（CFML AS）、BroadVision（サーバーサイドJavaScript AS）などのいくつかのプロプライエタリアプリケーションサーバーの統治でした。しかし、Javaアプリケーションサーバーの時代を生き残ったものはありません。
基本的な理解：
クライアントサーバーアーキテクチャ
サーバー：>リクエストを処理します。
クライアント：>サービスを消費します。
Webサーバーとアプリケーションサーバーはどちらも、クライアントのサーバーとして機能するソフトウェアアプリケーションです。
彼らは彼らの利用場所に基づいて彼らの名前を得ました。
Web server :> serve web content
:> Like Html components
:> Like Javascript components
:> Other web components like images,resource files
:> Supports mainly web protocols like http,https.
:> Supports web Request & Response formats.
使用法 -
we require low processing rates, regular processing practices involves.例：すべてのフラットサーバーは、Webベースのコンテンツのみを提供する、一般に入手可能な既製です。
Application server :> Serve application content/component data(Business data).
:> These are special kind which are custom written
designed/engineered for specific
purpose.some times fully unique in
their way and stands out of the crowd.
:> As these serves different types of data/response contents
:> So we can utilize these services for mobile client,web
clients,intranet clients.
:> Usually application servers are services offered on different
protocols.
:> Supports different Request& Response formats.
使用法 -
we require multi point processing, specialized processing techniques involves like for AI.例：Googleマップサーバー、Google検索サーバー、Googleドキュメントサーバー、Microsoft 365サーバー、AI用Microsoftコンピュータービジョンサーバー。
それらを4層/ n層アーキテクチャーの層/階層として想定できます。
So they can provide
load balancing,
multiple security levels,
multiple active points,
even they can provide different request processing environments.
標準的なアーキテクチャの類推については、このリンクをたどってください：
https://docs.microsoft.com/en-us/previous-versions/msp-np/ee658120(v%3dpandp.10）
最大の違いは、WebサーバーがHTTPリクエストを処理するのに対し、アプリケーションサーバーは任意の数のプロトコルでビジネスロジックを実行することです。
上記のすべては、非常に単純なものを過度に複雑にしています。アプリケーションサーバーにはWebサーバーが含まれています。アプリケーションサーバーには、標準のWebサーバーよりもいくつかの追加/拡張機能があります。例として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サーバーで取得することもできますが、アプリケーションサーバーでは、これらすべてをパッケージ化して便宜を図っています。アプリサーバーとして完全に分類されるには、基本的に、いくつかの標準で規定されているツールのリストに準拠する必要があります。
https://en.wikipedia.org/wiki/Web_serverから
Webサーバは HTTP、World Wide Web上の情報を配布するために使用される基本的なネットワークプロトコルを介したプロセスが要求するコンピュータシステムです。この用語は、システム全体、または特にHTTPリクエストを受け入れて監視するソフトウェアを指す場合があります。
https://en.wikipedia.org/wiki/Application_server#Application_Server_definitionから
アプリケーションサーバーはWebサーバーの背後で実行されます（ApacheまたはMicrosoftインターネットインフォメーションサービス（IIS）など）の（ほとんどの場合）SQLデータベース（PostgreSQL、MySQL、Oracleなど）の前面でも実行されます。
Webアプリケーションは、アプリケーションサーバー上で実行され、アプリケーションサーバーがサポートする言語で記述され、アプリケーションサーバーが提供するランタイムライブラリとコンポーネントを呼び出すコンピューターコードです。
アプリケーションサーバーとWebサーバーの両方を使用して、Webアプリケーションをホストします。一方、Webサーバーは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：サーブレット
Jetty：サーブレット
Apache：Php、CGI
アプリケーションサーバーは、あらゆるプロトコルを使用してリッスンするWebサーバーと同じように実行できます。また、アプリケーションサーバーには、接続プーリング、オブジェクトプーリング、トランザクションサポート、メッセージングサービスなどのアプリケーションレベルのサービスをサポートするコンポーネントと機能があります。
アプリケーションサーバーのプログラミング環境：
MTS：COM +
WAS：EJB
JBoss：EJB
WebLogicアプリケーションサーバー：EJB
2つの間にオーバーラップが存在する場合がありますが（一部のWebサーバーはアプリケーションサーバーとして使用される場合もあります）、IMHOの最大の違いは処理モデルとセッション管理にあります。
Webサーバー処理モデルでは、要求の処理に重点が置かれます。「セッション」の概念はかなり仮想的です。つまり、「セッション」は、クライアントとサーバー（したがってREST）間で状態の表現を転送し、外部永続ストレージ（SQL Server、Memcachedなど）にシリアル化することによってシミュレートされます。
アプリケーションサーバーでは、セッションは通常、より明示的であり、多くの場合、「セッション」の全期間中、アプリケーションサーバーのメモリに存在するオブジェクトの形をとります。
特定のアーキテクチャに依存します。一部のアプリケーションサーバーはWebプロトコルをネイティブに使用する場合があるため（XML / RPC / SOAP over HTTP）、技術的な違いはほとんどありません。通常、Webサーバーはユーザー向けで、HTTP / HTTPSを介してさまざまなコンテンツを提供しますが、アプリケーションサーバーはユーザー向けではなく、非標準またはルーティング不可能なプロトコルを使用する場合があります。もちろん、RIA / AJAXを使用すると、特定のリモートアクセスサービスをポンピングするクライアントに非HTMLコンテンツ（JSON / XML）のみを提供して、違いをさらに曇らせることができます。
IMO、それは主に懸念を分離することに関するものです。
純粋に技術的な観点から見ると、単一のWebサーバーですべて（Webコンテンツ+ビジネスロジック）を実行できます。それを行うと、情報はリクエストされたHTMLコンテンツ内に埋め込まれます。どのような影響がありますか？
たとえば、まったく異なるHTMLコンテンツをブラウザーにレンダリングする2つの異なるアプリがあるとします。ビジネスロジックをアプリサーバーに分離する場合は、スクリプトを介してアプリサーバー内の同じデータを検索するさまざまなウェブサーバーを提供できます。ただし、ロジックを分離してWebサーバーに保持しないと、ビジネスモデルを変更するたびに、すべてのWebサーバーごとにロジックが変更され、時間がかかり、信頼性が低下します。エラーを起こしやすい。