-
Notifications
You must be signed in to change notification settings - Fork 9
http routing
Herokuのプラットフォームは、自動的にロードバランスを実行し、アプリケーションのホスト名へ送信されるHTTPリクエストを
web dynoへルーティングします。Cedar stack上にある全てのアプリケーションのエントリポイントは、
herokuapp.comドメインとなります。これがweb dynoへダイレクトなルーティングパスを提供してくれます。
インバウンドリクエストは、HTTPターミネーションとSSLターミネーションを提供するロードバランサにより受信されます。 インバウンドリクエストは、ここからrouting meshへとダイレクトに渡されます。
routing meshは、dyno manifold内でアプリケーションのweb dynosの ロケーションを決定し、これらのdynoの1つへ、HTTPリクエストを転送する責任を負います。 dynoの選択は、ランダム選択のアルゴリズムを使い、動作します。
Herokuのインフラを経由する末端のクライアントからアプリケーションへの明瞭なパスのリクエストは、 HTTP 1.1の仕様をフルサポートしています。 chunkedレスポンスや、ロングポーリング、単一のwebプロセスから複数のレスポンスをハンドルするために 非同期webサーバの使用する、と言ったことをサポートしています。
herokuapp.comのHTTPスタックにおけるリクエストは、webプロセスがレスポンスデータ
（プロセスがアクティブであることを示す完了したレスポンス、もしくは若干のレスポンスデータ）
を返さなければならない初期値30秒の制限があります。
初期値30秒の制限内にレスポンスデータを返さないプロセスは、H12のエラーを
logsに残すこととなります。
この初期レスポンスの後、今度は（クライアント、もしくはアプリのプロセスから）送信された各バイトへ、55秒の制限が設けられます。 もし、55秒の制限内でデータが何も送られなければ、コネクションは切られ、 H15のエラーがログとして残ります。
herokuapp.comのルーティングスタックは、同時に1つ以上の接続をハンドルしたいと期待する
非同期、またはマルチスレッドのアプリに使用されます。
Goliath、 Thin （Async Sinatraのようなwebフレームワークに最適）のようなRubyのwebサーバ、または独自にカスタム可能なEventMachineのwebプロセスが例としてあげられます。
Node.jsのwebアプリ（Expressで開発されるような）は、Python、Java、Scala、そしてClojureのアプリでも可能なように、ほぼ常にシングルプロセスにおいて複数のコネクションをハンドル可能です。
-
X-Request-Start: リクエストがルーターによって受信された時のUnixタイムスタンプ（ミリ秒単位） -
X-Heroku-Queue-Depth: リクエストキューの深さ -
X-Heroku-Queue-Wait-Time: リクエストがルーター内で使用した時間（ミリ秒単位）
Varnishのようなリバースプロキシのキャッシュは、 上記したような高度なHTTPの仕様と互換性が無いので、機能として組み込まれておりません。
memcache系のアドオンの1つと適切なHTTPヘッダーを組み合わせることで、 Varnishに匹敵する仕様とパフォーマンスを提供し、さらに認証とページ有効期限を完全にコントロールすることが出来る恩恵を受けれます。
加えて、S3上にアセットを保管すること、またはAWS CloudFrontのような CDNを使うことは、より強固なキャッシュ性能を必要とするアプリケーションとっては、1つのオプションとなります。
WebSocketsは現在、未サポートです。
Cedar上のアプリへのリクエストは、アプリケーションサーバーへ直接生成されるので、 レスポンスの圧縮に関しては、ご自身のアプリケーション内にて行う必要があります。 -- nginxのようなHTTPサーバーを経由してプロキシされません --