Herokuに小さなサイトがあり、現在Thinを使用しています。私は漠然とユニコーンに気づいていましたが、その「高速クライアント」の規定に合うものがあるとは決して感じませんでした。
READMEとこのリンクは、LAN(またはLambdarail)でUnicornのみを使用することについて話していることを示唆していますが、通常のブロードバンドやモバイルネットワークでさえアクセスされる一般的なサイトで多くの人がUnicornを使用しているようです。これは本当ですか?何が得られますか?
Herokuに小さなサイトがあり、現在Thinを使用しています。私は漠然とユニコーンに気づいていましたが、その「高速クライアント」の規定に合うものがあるとは決して感じませんでした。
READMEとこのリンクは、LAN(またはLambdarail)でUnicornのみを使用することについて話していることを示唆していますが、通常のブロードバンドやモバイルネットワークでさえアクセスされる一般的なサイトで多くの人がUnicornを使用しているようです。これは本当ですか?何が得られますか?
Unicornは通常、実際のクライアントからHTTP接続を受信し、静的アセットを提供し、動的リクエストをバックエンドサーバー(Unicorn)に転送するNginxなどのWebサーバー/プロキシの背後で使用されます。
Webサーバーは、Unicornのクライアントとして機能するようになりました。Nginx(およびほとんどの場合Apache mod_proxy)はストアアンドフォワードプロキシとして機能するためです。つまり、クライアントに送信する前に、最初に完全な応答をバッファリングします(または少なくともそのバッファに収まるだけのバッファリングを行います)。そして、これはUnicornの高速クライアントの定義にうまく適合します。それは、データをキャッシュして提供するという難しいタスクを、クライアントの速度を低下させるWebサーバーに渡します。Webサーバーは、とにかくそれを実行する必要があるため、おそらくはるかに優れた処理を実行できます。
また、Unicornをクライアントに直接向けて実行するべきではないことも示唆しています(クライアントがデータを高速に消費する場合を除きます(たとえば、混雑していないクライアントとネットワークを備えたLAN上で)。
Herokuでユニコーンを使用していて、良い結果が得られています。ユニコーンサイトが区別していないのは、動的データを提供するユニコーンと静的アセットの間に違いがあるということです。アセットサービングをCDNにオフロードする場合、前にnginxがある場合とない場合のユニコーンに大きな違いはありません。これに注意すると、生のユニコーンは、DDoSやその他のハッキングの試みで導入される可能性があるなど、「意図的に」遅いクライアントに対して脆弱です。