Cowboy 現代のWeb - ハードリカーエンジニア

Webの始まりから今日までのさまざまなWeb技術を見てみることによって、次に何がくるのかの予測を得てみましょう
Cowboyは、この記事を書いている時点で仕様として実現例のないHTTP/2.0以外のすべてのテクノロジーと互換性を持っています。

先史時代のWeb

HTTPは最初はHTMLページを提供するためだけに作成され、HTMLページを取得するためのGETメソッドのみを持っていました。
この最初のバージョンは文書化され、HTTP/0.9と呼ばれています。
HTTP/1.0はGET、HEAD、POSTメソッドを定義し、POSTリクエストを使用してデータを送信することができました。

HTTP1.0は非常に簡単な方法で実装されたものです
TCP接続が最初にサーバと確立されます。
次に要求が送信されます。
そしてサーバは応答を送り返し、接続を終えます。

こういえば十分ですが、HTTP1.0はあまりにも効率的ではありませんでした。
TCP接続を開始することはかなりの時間がかかります、そして多くのリソースを含むページを開こうとしたときは非常にゆっくりとロードをしてしまいました。

その後に行われたほとんど改善は、このロード時間を短縮し、要求の待ち時間を減らすことに焦点があてられました。

HTTP/1.1

HTTP/1.1はHTTP/1.0からすぐに続き、エンドポイントが明確に定義されたチャンクでBody部を送信することができ、多くの要求だけでなく、ストリーミング機能にも同じ接続を使用可能とするためのkeep-aliveの機能を追加しました。

HTTP/1.1はHRAD、OPTIONS、 GET、 HEAD、 POST、 PUT、 DELETE、 TRACE、CONNECTメソッドを定義しています。
上記のものの後にPATCHメソッドは追加されました。
また多くのヘッダ部の導入とキャッシュ機能を向上させています。

HTTP/1.1は後続のリクエストのために接続がつながり続けていること以外はHTTP/1.0と同じように動作します。
クライアントがパイプラインと呼ばれるものを実行することができます（順々に多くの要求を送信して、要求と同じ順序で受け取って反応を処理すること）

REST

HTTP/1.1の設計はRESTアーキテクチャのスタイルの影響を受けていました。
REST、またはRepresentational State Transferは緩やかに接続された分散システムのためのアーキテクチャの形です。

RESTはシステムがRESTfulであるために従わなければならない制約を定めています。
すべての制約に従っていないシステムはRESTfulとは考えられません。

RESTはクライアントとサーバ間の関心事を明確に分離したクライアントサーバアーキテクチャです。
クライアントはリソースを参照することで通信します
リソースは特定されるだけではなく操作することができます。
リソース表現は、どのように使用することができるかについてメディアタイプ情報を持っており、キャッシュされます。
ハイパーメディアはリソースがどのような関連があるのか、クライアントがどのように使うことができるのか決定します
RESTはステートレスです。
すべての要求はアクションを実行するために必要な情報が全て含まれています。

HTTP/1.1はすべてのメソッド、ヘッダとRESTfulシステムを実装するために必要なセマンティクスを定義しています。

一般的に直接実行可能なコードにて使用することを意図しているWebアプリケーションAPIを設計する際にRESTは最もよく使われます。

XmlHttpRequest

AjaxはWebページ上で実行されているJavaScriptコードとサーバへの非同期処理を実行することを可能とした技術である
これは静的なWebサイトから動的なWebサイトへの移行を開始した始まりでもあります。

XmlHttpRequestは覆いの下でHTTPリクエストを実行して反応を待ちます。ですが反応が起こるまでJavaScriptコードは動作し続けます。
それから定められたコールバックを通してリクエストを受付ます。

これはもちろんクライアント側で始められたリクエストです、サーバ側単体でクライアント側へPUTする方法が存在しなかったためなかったためAjaxはまるでPUTを行えるようにみえました。

ロングポーリング

ポーリングはサーバからクライアントへ直接データを送ることができなかったため、それを解決するために使用される技術でした。
したがってクライアントが繰り返し接続を作成し、リクエストを取得し、要求を行い、数秒後に再試行する必要がありました。
これは過度に高価であり、クライアントがデータを受信する前に追加の遅延が発生します。

ポーリングは次のページへとリフレッシュするようなときよりも、投稿やメッセージ・キューなどに類似したメカニズム(それが起こる時はユーザーは何が起きるかを知っている場合)を実装するのに必要でした。
典型的な例はチャットアプリケーションです。

ロングポーリングはより少ない接続の確立で実施することによってサーバの負荷を減らす目的で作りました、それだけではなくサーバ上で利用可能になるとすぐにクライアント側へ応答を返すことにより遅延を改善する目的もありました。

ロングポーリングは要求に対してすぐにリクエストを返すことができないことを除いて、ポーリングと同等に動作します。
ロングポーリングが返信するリクエストを有するまでサーバは接続を開いたままにします。
リクエストを取得した後、クライアントは新たしいリクエストを作成し、待機中に戻ります。

あなたはおそらくロングポーリングが改善された良い物であると感じたでしょう。しかしそれは思いがけない問題が発生することもあります。今回の場合で言うとプロキシがあるとうまく接続できません。

HTML5

HTML5はもちろんHTML4の後続のHTMLのバージョンです。
しかしHTML5は特定の問題解決のために提案されました：動的なWebアプリケーション

HTMLは初期のWebサイトを構築するためのWebページを記述するために作成されました。
しかしすぐに人や企業はWebアプリケーションとして知られているより複雑なウェブサイトを書くためにHTMLを使用しました。
例えばニュースリーダーやブラウザで電子メールクライアント、またはビデオストリーミングサイトなどです。

HTMLはそういうものを実装するために十分ではなかったので、彼らはプラグインを使用して実装したり、独自のソリューションを使用するなどしました。
これはもちろん完璧ではありませんでしたが、大多数の人のためには十分な動きをしました。

しかし後々になって標準化の必要性は理解されてきました。
必要なブラウザが標準のメディアを再生できるようにする。
または何かを描くことができるために必要です。
これはサーバーにイベントをストリーミングするだけではなく、サーバーからイベントを受信する効率的な方法を必要としました。

解決策はHTML5で行うこととなりました。執筆時点では、それが標準化されています。

EventSource

EventSource(またはServer Sent Eventsと呼ばれる)は、サーバーはHTML5アプリケーションにデータをプッシュすることができる技術です。

EventSourceはサーバからクライアントへの一方通行の通信チャネルです。
クライアントはHTTPリクエストを使用して、通信があったサーバ以外のサーバへリクエストを送信する手段はありません。

これはサーバへのEventSource接続とHTTP/1.1接続の上にイベントをクライアントへ送信するための非常に小さなプロトコルのセットアップを許可するJavaScriptからなっています。

EventSourceはUTF-8でエンコードされたテキストデータで動く軽量なソリューションです。
異なるエンコードのバイナリデータとテキストデータはプロトコルによって許可されていません。より一般的で重いアプローチとしてはWebsocketとなります。

Websocket

WebsocketはHTTP1.1にてクライアントとサーバ間の2通りの通信チャネルを提供するために構築されたプロトコルです。
通信は非同期であり、同時に通信することがあります。

これはサーバーへのWebsocket通信をJavaScriptにて準備し許可します。そしてバイナリデータベースのサーバーまたはクライアントに送信するプロトコル構成で作られています。

Websocketの接続は、UTF-8でエンコードされたテキストデータやバイナリデータのいずれかを転送することができます。
プロトコルは接続がまだ生きていることを確認するために、サーバーとクライアント間のping/pong通信機構の実装が行えるようなサポートが含まれています。

Websocketの接続は小さな、または大きなテキストやバイナリデータの任意の種類を転送するために使用することができます。
このためWebsocketはたまにシステム間の通信に使用されます。

SPDY

SPDYはリクエストのサイズを小さくするためにHTTPヘッダーを圧縮し、サーバーごとに単一の接続を行い、後続のリクエストのために接続を維持し続けることによってページの読み込み時間を短縮する試みです。

SPDYはHTTP/1.1のセマンティクスと互換性があり、バイナリフレームの代わりにテキストベースのプロトコルを使用する、HTTPリクエストとレスポンスを実行するだけの別の実装です。
SPDYはサーバーが要求以外の余分なリクエストを送信することができます。
これはクライアントがWebサイトをロードする際の待ち時間を節約し、それらを要求する前に要求に関連付けられたリソースを送ることができることを意味します。

SPDYはHTTP/2.0標準の基礎として使用されており成功した実験です。
ブラウザがプロトコルをサポートしている場合はTLSを使い、次にプロトコルネゴシエーション、そしてシームレスにSPDY接続にアップグレードされます。
プロトコル自体はHTTP/2.0に起因するいくつかの欠点があります。

HTTP/2.0

HTTP/2.0はHTTP/1.1の待望のアップデートです。
多くの改善としては書き込み時の改善がおこなわれ、SPDYを基としています。

HTTP/2.0は2つのエンドポイント間の非同期の二通りの通信チャネルです。
これは2014年後半に標準化が予定されています。