[1] Webアプリケーションの本体サーバーのことを、 アプリケーションサーバーやバックエンドなどと呼びます。
[2] ふつう、 Webアプリケーションを構成するサーバーをデータベースサーバー、 プロキシサーバー、 その他のストレージサーバーといった役割によって分けるときに、 アプリケーション本体を指すために使う言葉です。
[5] プロキシサーバーやキャッシュサーバーを前面に置く構成のとき、 クライアントはアプリケーションサーバーに直接アクセスせず、 前面のサーバーを通して間接的にアクセスすることになります。 この場合は前面のサーバーとアプリケーションサーバー (やその他の構成サーバー) の全体が1つの Webサーバーとして機能するといえます。
[3] ほとんどの場合、 アプリケーションサーバーは HTTP によって要求を受け取り、 応答を返す形で実装されます。 この場合アプリケーションサーバーは HTTPサーバーであり、 これ単体でも Webサーバーといえます。
[4] 理論上はアプリケーションサーバーを HTTP 以外で実装することもできます。 パフォーマンス向上や、 旧来システムとの互換性など、 相応の理由があるときは採用され得ますが、 反面、 単体でのデバッグが難しくなるなどデメリットも多いので、 通常はそうしません。
[6] 前面にサーバーを置かない構成のとき、 アプリケーションサーバーはクライアントの要求を直接受け取り、 応答を直接返すことになります。 この場合は当然、アプリケーションサーバーが HTTP (や TLS) のすべての要件に従う義務が生じることになります。
[7] 前面に他のサーバーを置く構成を前提とするアプリケーションサーバーは、 HTTP の一部の機能に限って実装したり、 パフォーマンスやセキュリティーに一定の制限を置く形の実装になっていたりすることがありますので、 注意が必要です。
[8] Webアプリケーションフレームワークの HTTPサーバーライブラリーは、 前面にサーバーを配したアプリケーションサーバーとしての利用を前提に、 HTTPS 対応を省いたり、 HTTP/1.1 対応を省いたり、 HTTP/2 対応を省いたり、 応答に必要な HTTPヘッダーを出力しなかったりすることがあります。
[11] Webアプリケーションの運用技法として発達したものですが、 HTTP を使うネイティブアプリケーションにも流用されています。 歴史をたどれば Web で完全に新規に発達したものでもなく、 従来の分散システム技術から派生した部分もあります。
[10] Web Push におけるアプリケーションサーバーは、 アプリケーションの部品であって、 通常サーバー上で動作し、 プッシュメッセージの配送を要求するものです。 >>9
[13] Push API におけるアプリケーションサーバーは、 Webアプリケーションのサーバー側部品です。 >>12