17826
# 前置き

(やや混乱しているので質問がわかりづらいかもしれません)

大昔`Perl`で`CGI`によるWebアプリを作ったときに、`Apatch`で`Perl`で書いたプログラムを呼び出していた記憶があります。

## Rails

`Rails`ですが、`Webサーバー`と`アプリケーションサーバー`が分かれている印象です。

## CGI

上記`CGI`のやり方では`Webサーバー`は存在しますが、`アプリケーションサーバー`は存在しないと認識しています。

# Webサーバーとアプリケーションサーバーで混乱

`Rails`ですと

## Webサーバー

例えば`Rack` (←回答よりこれは勘違い）

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

例えば`Unicorn`、`Puma`

といったように、ソフトウェアとして`Webサーバー`と`アプリケーションサーバー`が分かれていると認識しています。

## Webサーバーとアプリケーションサーバーを同時に満たすものがある？

`WEBrick`ですが、`Webサーバー`と`アプリケーションサーバー`どちらの役目もしているような気がしていて混乱しています。（`dev環境`だと`アプリケーションサーバー`など意識せず`WEBrick`だけで動いている気がする）

## Rackは各種アプリケーションサーバーの仕様の乱立を避けるために生まれた？

各種アプリケーションサーバーがどんどん出てきたときに、デプロイの作業がバラバラとなり、それを救うために`Rack`が生まれたというような内容を見かけました。  
となると、`アプリケーションサーバー`の違いを吸収するために`Webサーバー(Rack)`を用意するということでしょうか？  
(そもそも`Webサーバー`は`HTTP`などのリクエストを受け取るもので`アプリケーションサーバー`の違いを吸収するものではないような...)
CC BY-SA 3.0
2015-10-19T08:36:02.320
17813
2015-10-20T23:26:23.737
2015-10-20T23:26:23.737
9008
9008
question
ruby-on-rails ruby rack
webサーバー、アプリケーションサーバー、Rackといった仕様や概念と、WEBrick、Unicorn、Pumaといった実装の関係が頭の中で結びつきません
webサーバー、アプリケーションサーバー、Rack、Unicorn、Puma、Railsと言った用語や概念の理解がこんがらかっているように見えたので、このあたりをきれいに説明している記事を探してみました。

おそらく以下の記事が回答にぴったりだと思います。

<http://www.justinweiss.com/articles/a-web-server-vs-an-app-server/>

この記事の中からnakanishiさんの理解に役立ちそうなセクションをピックアップして、ざっくり翻訳してみました。

* * *

### webサーバーとは

  * **webサーバー** はユーザー送られてきた自サイトへのリクエストを受け取り、なんらかの処理を加えるプログラムです。そして、場合によってはあなたのRailsアプリケーションにリクエストを投げます。NginxとApacheは最も有名な **webサーバー** です。
  * CSSやJavaScript、画像など、頻繁に変化しないファイルへのリクエストであれば、Railsアプリケーションはそのリクエストを処理する必要がないかもしれません。 **webサーバー** はRailsアプリケーションに処理を移譲することなく、そのリクエストを自分で処理できます。また、そうした方が通常は速く完了します。
  * **webサーバー** はSSLリクエストや静的なファイルやアセット、圧縮されたリクエスト等を処理したり、その他大半のwebサイトが必要としそうな数多くの処理をこなしたりすることができます。そしてもし、あなたのRailsアプリケーションがリクエストを処理しなければならない場合は、 **webサーバー** はリクエストを **アプリケーションサーバー** にパスします。

### アプリケーションサーバーとは

  * **アプリケーションサーバー** はあなたのRailsアプリケーションを動かしているものです。 **アプリケーションサーバー** はあなたのコードを読み込み、アプリケーションをメモリに保持します。 **アプリケーションサーバー** は **webサーバー** からリクエストを受け取ると、Railsアプリケーションにそのことを知らせます。アプリケーションがリクエストを処理すると、 **アプリケーションサーバー** はそのレスポンスを **webサーバー** に返します。（そのレスポンスは最終的にユーザーへ届きます。）

  * 大半の **アプリケーションサーバー** は **webサーバー** を使わずに単体で実行できます。これはあなたがdevelopmentモードでやっていることです！しかしproduction環境では **webサーバー** を手前に置くことが多いはずです。 **webサーバー** は複数のアプリケーションを一度に処理したり、アセットを素早くレンダリングしたり、リクエストごと発生する多くの処理をさばいたりしてくれます。

  * Rails用の **アプリケーションサーバー** は山ほどあります。たとえば、Mongrel（ただし最近はほとんど使われていない）、 **Unicorn** 、Thin、Rainbows、 **Puma** などです。それぞれに異なる長所があり、異なる設計思想を持っています。とはいえ、みんなやっていることは一緒です。つまり、どの **アプリケーションサーバー** もあなたのRailsアプリケーションを動かし、リクエストを処理し続けています。

### Rackとは

  * **Rack** は魔法です。 **Rack** を使えばどの **アプリケーションサーバー** であってもあなたのRailsアプリケーションを動かすことができます。（Railsに限らず、SinatraやPadrinoであっても同じです）
  * **Rack** はRailsのようなRuby製のwebフレームワークと **アプリケーションサーバー** の両方が話せる共通言語のようなものだと考えてください。両者が共通言語を理解できるので、Railsは **Unicorn** と話せますし、 **Unicron** はRailsと話せます。しかも、Railsも **Unicorn** も相手のことを知っておく必要は全くありません。

### webサーバーとアプリケーションサーバーはどういう関係なのか？

  * それでは、この話を全部まとめるとどうなるでしょうか？

  * まず、webリクエストは **webサーバー** にぶつかります。そのリクエストがRailsで処理できるものであれば、 **webサーバー** はリクエストに簡単な処理を加えて **アプリケーションサーバー** に渡します。 **アプリケーションサーバー** は **Rack** を使ってRailsアプリケーションに話しかけます。Railsアプリケーションがリクエストの処理を終えると、Railsはレスポンスを **アプリケーションサーバー** に返します。そして、 **webサーバー** はあなたのアプリケーションを使っているユーザーにレスポンスを返します。

  * もっと具体的に言えば、Nginxはリクエストを **Unicorn** に渡します。 **Unicorn** はリクエストを **Rack** に渡します。 **Rack** はリクエストをRailsのrouterに渡します。routerはリクエストを適切なcontrollerに渡します。そしてレスポンスが逆の順番で返されます。

[（全文訳はこちら）](http://qiita.com/jnchito/items/3884f9a2ccc057f8f3a3)

* * *

この内容をじっくり読んで理解すれば、疑問点の大半は解消されると思うのですがいかがでしょうか？  
（ちなみに僕も理解があやふやなところがあったので、翻訳してみてスッキリしました）
CC BY-SA 3.0
2015-10-19T13:19:44.037
17826
2015-10-20T22:06:39.500
2015-10-20T22:06:39.500
85
85
17813
answer