「HTML5 Conference 2013」ルーム5Cの最終セッションは「通信キャリアプロフェッショナルが語るHTML5への期待」と題したパネルディスカッションが行われた。パネラーとして登壇したのはNTTコミュニケーションズの宮川晋氏（専門：バックボーンNW）、ソフトバンクモバイルの湧川隆次氏（専門：アクセスNW）、KDDIの藤井彰人氏（専門：クラウド基盤）の3人。コーディネータをNTTコミュニケーションズの小松健作氏が務めた。

これからのアプリ開発はネットワークの知識は欠かせない

セッション開始にあたり、まず小松氏が同セッションの目的を紹介した。
「HTML5の登場により、Webが進化しているのは承知のとおり。通信など他のレイヤーに影響を及ぼしている。つまりWebアプリ開発者も、キャリア通信のところで何が起きているか知らないとやっていけない状況になっている。またこれは逆もしかり。そこでまずキャリアプロフェッショナルに、今、通信のところでは何が起きているか語ってほしい」。こう口火を切り、宮川氏のプレゼンテーションが始まった。

アプリ屋さんはTCPより下を、IP屋さんはTCPより上を

「私はIP屋なので、Webの世界は知らない」。開口一番そう話し、プロフィールの紹介を始めた宮川氏。同氏は会社での仕事のほか、RFC3769 Requirements IPv6　Prefix DelegationなどIPv6の規格の標準化・実用化に長らく携わっているという。
「今日はIPネットワークに携わっている側から、HMTLをやっている皆さんに知っていただきたいこと、あるいは教えていただきたいことについて話をしたい」

こう前置きし、最初に宮川氏が紹介したのはIETFの「HourGlass（砂時計モデル）」図。同図では砂時計の真ん中部分がIPとなっており、IP屋さんはTCPより上については良くわからず、反対にアプリ屋さん（HTMLを書く人）はTCPより下については気にしなくてよかった。しかし「HTML5関連の技術であるSPDYやWebSocket、WebRTCなどが登場してからはそうも言っていられなくなった」という。

CGN（Carrier Grade NAT）という技術がある。これは1つのグローバルアドレスを複数のユーザーで共用するという、IPv4延命のための技術だ。重要なのはCGNでは1台のマシンで使用できるTCPの数には限界があるということ。最近のWebアプリはAjaxを用いて多数のTCPを張り、表示の高速化を図っている。つまりたくさんのTCPを同時使用しているということ。このような状況下でCGNが導入されればCGNに多大な負荷と影響を及ぼすことになると予想できるという。もちろんIPv6化も検討が進められているが、「これも問題がないわけではない」と宮川氏は次の点を指摘する。

• SPDYやWebSocketなどとインフラとの親和性が本当にあるのか。
• ファイアウォールやロードバランサーとかがうまく機能するのか
• 全部HTTPSになるとしたら、コンテンツの中身をプロバイダは見えなくなる。ISPはもう何もできなくなるがいいのか

また今のネットワークはクライアント/サーバモデルに忠実なので、North-Southが太くてEast-Westはあまり考えていないつくりになっている。しかしこれからWebRTCが流行ったりすると、EW方向も重要になると思われる。

「アプリ屋さんと意見交換をしたい。現在、V6協議会研究で『IPv4枯渇に係るインターネット新技術導入に向けた検討WG』を運営している。一緒にやってくれる人を大募集している」

IPv6は真のエンドツーエンド実現。だからIPの知識が必要

続いて湧川氏が登壇。
「キャリアという紹介があったが、実はソフトバンクモバイルに入ったのは今年4月。IETFでモバイルの標準化にずっと携わってきた。今日はHTML5のWebsocketやSPDYが、どうIPに影響するかというところから話をさせていただこうと思っている」。こう切り出し、湧川氏のプレゼンが始まった。

今まではサーバーとマシンとのやり取りはHTTP1.1。複数のTCPでマルチにセッションを張り、各TCPが1つのやり取りをしてデータを落としてきた。これを効率化するために登場したのが、WebSocketである。これにより、一つのTCPパイプの中で複数のストリームを流せるようになった。そしてHTTP2.0では暗号化して仮想的なセッションでやり取りするという新しい動きが出てきている。

「しかし疑問もある」と湧川氏。それはTCPのLong-Livedセッションはモバイルには向かないのではということ。先述したように今までは一つのページに複数のTCPを張り、通信をしていたので非常に短いセッションですんだ。一方今はWebSocketのように1つのTCPに複数のストリームを流していくので、長い時間TCPのセッションを張ることになる。そうなるとモバイルはどうしても「パケ詰まりにより、無線の混雑が起きてしまう」と指摘する。またモバイルはハンドオーバーもある。「モバイルの場合、TCPのセッションを減らそうといっても、複数のセッションを張ることになると思う」と湧川氏。

一般的にキャリア側ではユーザーが便利に使えるよう、さまざまな施策を講じてきた。以下がそれだ。

• キャッシュ
• CDN
• オプティマイザー
• フィルタリング
• ファイアウォール
• DPI（Deep Packet Inspection）
• QoS

今後、暗合化してエンドツーエンドで通信をするようになると、「キャリアができることはなくなる」と湧川氏は言う。つまりアプリケーションを書く人が用途と使える機能をきちんと理解して使うことが重要になるという。そしてIPv6が普及すると、真のエンドツーエンドが実現する。「すばらしい世界だが、大丈夫かどうか、注意が必要。ぜひアプリ開発者と議論していきたい」（湧川氏）。

ネットワークのSDKもプログラムブルに

最後に登壇したのは藤井氏。 「先の二人とはバックグラウンドがかなり違う」 プレゼン冒頭でこう切り出し、藤井氏のプレゼンが始まった。同氏がGoogleからKDDIに転職したのは今年の4月で、MashupやWebAPIでアプリケーションを作っていくことに関心を抱いているという。KDDIではクラウド基盤のサービスの企画を担当している。

「HTML5はモバイル、ウェアラブル、クラウドへ転換していく」と藤井氏。そのときにクラウドの基盤とアプリケーションの配信基盤が今後、どうなっていくのか、そこに関心があるという。データセンターなどのインフラとアプリケーション開発基盤がセットになったものがどんどん登場している。その例として藤井氏が挙げたのが、Facebookのデータセンターのハードウェア設計をオープンソース化する「Open Compute Project」やAmazonの「AWS SDK for JavaScript」。「インスタンスを追加したりロードバランスの設定を変えたり、ということがAWSで動的に変えていける時代になっている」（藤井氏）

Webアプリケーションの基盤としてのPaaS、BaaS、MEAP（モバイル・エンタープライズ・アプリケーション・プラットフォーム）なども登場している。

「ネットワークのSDKのところがプログラムブルになるなど、Webアプリ開発者もアプリだけをみていれば良いという時代は終わったと言える。どんなクラウド、開発基盤を求めていくのか。Webアプリ開発者のその分野への自由な進撃が始まる」（藤井氏）

3人のプレゼンが終了し、コーディネータの小松氏は「これからのWebアプリケーション開発では、ネットワークやクラウドなどの知識もなければ難しくなる。そのための取り組みとしてキャリア側で用意していることやアプリ開発者に期待していることが教えてほしい」と問いかけた。

「2015年11月にIETFの会合が横浜で開催される。しかもW3CのTPACとの同時開催を今、画策している。この同時開催の裏側にあるのは、インフラとアプリがバラバラで開催することに限界がきているから。お互いにセッションし合わなければならないほど、深刻な事態に突入してきている。これは逆にビジネスチャンスでもある。IETFやTPACで何かしようとしたら2年ぐらいかかるので、『こういうアイデアがあるんだけど』という人がいれば、どんどん発信してほしい。そして2年後の横浜で世界に向かって成果として出す。これはすごいバリューになる」（宮川氏）

「アプリ開発側からネットワークの方にもっと寄ってきて欲しい。要求仕様を出してもらえると、私たちができることはまだまだ一杯ある。アプリ開発側がどういうところに問題を感じているかをぜひ、教えて欲しい」（湧川氏）

「ネットワークやクラウドを含め、すべてがプログラムできるような世界がくる。それを考慮に入れたアプリケーションの開発やアーキテクチャの作り方をしていってほしい。また先述したようにさまざまなインフラのサービスが登場しているので、それを使い分けていくのも面白いと思う。そのためにも、ほかのレイヤーの知識を身につけてほしいですね」（藤井氏）

ネットワークの知識は欠かせない

藤井氏の話に付け足す形で宮川氏はジュニパーネットワークスがこの秋に発表したOSSプロジェクト「OpenContrail」を紹介。同プロジェクトではApache License 2.0で利用できる SDNコントローラ、仮想ルータ、オーケストレーションAPI、アナリティクス、管理コンソールなど、データセンターのオーバーレイを実行するのに必要なすべてのコンポーネントを提供している。

また同プロジェクトではXMPPというチャットで使われるプロトコルを採用していることから、「例えば30分だけより大きな帯域を確保したいというと、15分後にそれが実現する、ということもできるようになるかも」と、アプリ側でできることの広がりを示唆した。

アプリ開発者にとってネットワークの知識がこれから大事になることを改めて実感できた同セッション。「HTML5の普及でネットワークへの敷居は下がってきている。Googleなども遅延をなくそうといろんな仕掛けに取り組んでいる。ぜひ、みなさんもネットワークを武器にしてこれからのアプリ開発に生かしてほしい」（湧川氏）、「HTML5だけに小さくまとまってしまうのではなくて、ネットワークとクラウドのところにも興味を広げ、大きな可能性を探ってほしい」（藤井氏）と呼びかけ、セッションは終了した。

【講演資料・セッション映像】

HTTPは、その下層にあたるトランスポートレイヤーのプロトコルとして、通常TCPを使用します。 したがって、TCPのレイヤで速度が改善することは、そのままWebの高速化につながる可能性があるといえます。

GoogleはWebを速くするための活動として、TCPのようなプロトコルレイヤの改善にも取り組んでいます。 今回はその中の一つ、TCP Fast Openを取り上げ、解説と動作検証、簡単なベンチマークを行います。 検証環境等は最下部に記載します.

Make the Web Faster: TCP Fast Open

3 Way Handshake

TCPは、「正確、確実にデータを届ける」ことを重視した設計になっています。 特に接続確立時には、双方の状態をきちんと確認しながら実施するための 3 Way Handshake (以下3WH)という方式を採用しています。

例えば、クライアントがサーバに対してHTTPリクエストを送信したい場合は、以下のような流れになります。

クライアントは、3WHが終わってはじめてHTTPリクエストを送信できるため、HTTPのリクエストを送るまでにはTCPのレイヤで三回の通信が必要になります。 HTTPでは、Keep-AliveなどでTCPコネクションを使いまわすこともできますが、それでも切断と接続の頻度は多いのが現状です。

そこで、3WHの通信を「なるべく少なく」することで、接続確立の高速化を図る方法が、今回紹介する TCP Fast Open (以下TFO)です。

なぜ3WHを使うのか

わざわざ三回も通信を行う3WHを用いる理由はいくつかありますが、その一つとして、クライアントIPの確認があります。

クライアントSYNが含まれるパケットにはクライアントのIPアドレスが載るため、サーバはそのアドレスにレスポンスを返すのですが、このIPは簡単に偽装することができます。

そこで、HTTPのやりとりに移る前に、クライアントのアドレスに対してサーバからもSYNを送ります。 もしこのとき、アドレスが偽装されたものであった場合、その機器が実在したとしてもサーバからのSYNは無視されるため、HTTPのやりとりに移る前にアドレスが正しいことを確認できるのです。

TCP Fast Open

TFOは、簡単に言えばTCPレイヤでCookieを用いることで、すでに接続を確立したことがあるIPアドレスのホストに対しては、3WHを簡略化するという方式です。

Cookieを用いるため、まったく初めて接続する(Cookieを保持していない)ホストに対しては通常の3WHを実行し、その時ホストがCookieを発行します。 二回目以降の接続確立では、クライアントはそのCookieをサーバに送信するという流れになります。

では、通信の詳細を見てみましょう。

次に解説する流れは、TCPコネクションを確立した後にHTTPのGETリクエストを発行し、レスポンスを受け取るところまでの範囲とします。 この時、HTTPのリクエストの受信、レスポンスの送信はサーバの責務ですが、リクエストデータを処理しレスポンスデータを生成するのは、アプリレイヤの責務であるという前提を踏まえて読んでください。

最初の接続

この時点ではサーバとクライアントが有効なCookieをお互いに保存していません。

1. クライアントは、SYNに Fast Open Cookie オプションにCookie Requestをつけて送信する。
2. サーバは、 TFO-Cookie を生成し、それをFast Open CookieオプションにつけたSYN-ACKを送信する。
3. クライアントは、TFO-Cookieをキャッシュする。
4. クライアントは、ACKを返し、通常の接続確立を終える。
5. クライアントは、HTTP GETリクエストを送信する。
6. サーバは、HTTP GETクエストをアプリレイヤに渡し、アプリが生成したレスポンスデータをレスポンスとして送信する。

通常の3WHと違うのは、SYNとSYN-ACKにFast Open Cookieオプションが付く点です。 通信の回数は三回と変わりません。 また、最初のSYNを受け取ったサーバがTFOに対応していない場合、サーバはオプションを無視して通常の3WHが実行(フォールバック)されます。 HTTPの通信は3WHが完全に終わった後になります。

ここでサーバが生成するTFO-Cookieは、クライアントのIPをベースにします。 クライアントはこのTFO-Cookieを、次回以降の接続で仕様するためにキャッシュします。

次回以降の接続

サーバとクライアントが有効なCookieをお互いに保持している状態です。

1. クライアントは、SYNパケットにキャッシュしたTFO-CookieとHTTP GETのリクエストデータを含めて送信する。
2. サーバは、TFO-Cookieを受け取る。この時初回接続で生成した方法と同じようにSYNからTFO-Cookieを生成し、受け取ったTFO-Cookieと比較する。同じであればTFO-Cookieは正しいものであり、同時にクライアントのIPは偽装されていないことがわかる。
3. TFO-Cookieが正しいことを確認したら、サーバはリクエストデータをアプリケーションレイヤに渡す。クライアントにはSYN-ACKを返すが、もしHTTPレスポンスデータが準備できていればSYN-ACKに載せることも可能。
4. アプリレイヤがHTTPレスポンスデータを生成し終えたら、サーバはそれをクライアントに送信する。
5. クライアントは、ACKを送信する。

通常の3WHと違うのは、SYNに初回接続でキャッシュしたTFO-CookieとHTTP GETのリクエストデータが付くことです。 サーバはTFO-Cookieを元に、クライアントがIPを偽装していないかを知ることができるので、正しいIPであればその後のクライアントからのACKがくる前にGETのデータをアプリのレイヤに渡してしまいます。 アプリから見れば一回の通信で、リクエストデータを取得したのと同等の状態になります。

また、TFOは3WHの省略と解説されることが多いですが、実際にはサーバは従来どおりSYN-ACKを返し、クライアントも最後のACKをきちんと送ります。 ただし、もしアプリが生成したレスポンスデータがサーバに届いたらSYN-ACKに載せて返すこともできますし、SYN-ACKを先に返しておいて別途送ることもできます。 最後のクライアントACKを待たずにレスポンスを開始できるのが、3WHを短縮するからくりになっているのです。

もし、サーバがTFOに対応していなかったりクライアントのTFO-Cookieが無効と判断された場合は、通常の3WHにフォールバックされ、通常のフローでHTTPのGETが行われます。

TFO-Cookie

TFO-CookieはクライアントのIPを保証できなければなりませんが、その生成アルゴリズムは仕様では定義されておらず、実装依存です。 参考までにLinux Kernel 3.11では、以下のようにクライアント/サーバ双方のIPアドレスを暗号化して生成しています。

http://lxr.linux.no/linux+v3.11/net/ipv4/tcp_fastopen.c#L67

IPアドレスを元に生成しているため、クライアントのIPが変わるとCookieが無効になることを意味します。

注意点

Intermedialies(中間サーバ問題)

こうしたネットワークプロトコルの改善には、必ずIntermedialies(middleboxともいう)と呼ばれる中間サーバが問題になります。 具体的にはプロトコルをいじることで、NATやFWなどが通信を不正と見なして遮断したり、内容を書き換えてしまう問題です。

TFOの場合は、NATでアドレスが書き換わる状況などではCookieが不正とみなされ、TFOが成功しない可能性が考えられます。 しかし、問題があれば通常の3WHへのフォールバックによって、通信を続行することができるよう設計されているため、この問題は最小限に抑えられています。

ただし、リクエストデータを付与したSYNが拒否され、3WH成立後に改めてリクエストを送信する場合は、リクエストデータが二重に送信されるためオーバーヘッドになる可能性があります。

導入方法

TFOはクライアントAPIがLinux kernel 3.6に、サーバAPIが3.7にマージされています。 執筆時点ではWindowsおよびMac OSでは使用することができません。

TFOを有効にするには、設定ファイルにフラグを立て、ソケットプログラムにおいて適切なシステムコールを呼ぶ必要があります。

サーバ

サーバでは、生成したソケットをバインドした後に、setsocketopt(2)を用いてTCP_FASTOPENオプションを付与する必要があります。 qlenの値は、TFOによって3WHが終了していないソケットのキューサイズです。

s = socket(AF_INET, SOCK_STREAM, 0);   // ソケットの生成

bind(s, ...);                          // アドレスへのバインド

int qlen = 5;
setsockopt(s, SOL_TCP, TCP_FASTOPEN, &qlen, sizeof(qlen)); // TCP_FASTOPEN オプションの設定

listen(s, ...);                        // ソケットのリッスン

クライアント

クライアントでは、生成したソケットに対するconnect(2)とsend(2)の代わりに、sendto(2)を使用してデータを送信します。 これは通常UDP通信などで使用されるシステムコールですが、TFOでは3WHが終了していない状態でのデータ送信が必要なため、これを用います。

このsendto(2)は、初回接続時はTFO-Cookie Requestを送信し、既にCookieがある場合はそれを使用してSYNにデータを載せて送信を行います。

// ソケットに対する connect(2) + write(2) の代わりに sendto(2) を使用
sendto(s, data, data_len, MSG_FASTOPEN,
    (struct sockaddr *) &server_addr, addr_len);

// 以降の送受信は通常どおり read(2)/write(2) を使用

設定

Linux KernelではTFOの設定ファイルとして /proc/sys/net/ipv4/tcp_fastopen が用意されています。 このファイルにはビットでクライアント/サーバごとに有効/無効の設定が可能です。 Linux Kernelでは以下の設定値が定義されています。

0x0: 無効 0x1: クライアントのみ有効 0x2: サーバのみ有効 0x3: クライアント/サーバともに有効 0x4: CookieがなくてもSYNでデータを送信 0x100: Cookie を検証せずにデータの載ったSYNを受け入れる 0x200: Cookie オプションがなくてもSYNにデータを載せる 0x400/0x800: TCP_FASTOPENオプションを設定してないソケットでもTFOを有効にする。

実装

簡単なTFOサーバとクライアントのスクリプトを作成して、パケットの流れを確認してみます。 現時点で言語レベルでTFOをサポートしているものは少ないため *1、Pythonで直接システムコールを呼ぶスクリプトを使用します。

python sample code (gist)

クライアントは “hello\n” を二回送信し、サーバはそれをエコーバックします。 二台のマシン(MacOS)上のVartual Box上のUbuntuで実行します。

# server
$ sudo python server.py # listen port 80
# client
$ python client.py 192.168.1.10 # server address

実行結果をWiresharkで確認します。

最初のClient SYNにFast Open Cookie Requestが付き、SYN ACKでFast Open Cookiが付与されていることがわかります。 データは別のパケットで送られています。

二回目のClient SYNには、このCookieとデータが一緒に載っています。 しかもサーバはSYN ACKを返した後に、サーバのACKを待たずにデータを返しています。 正常に動いていることがわかりますね。

ApacheとChrome

ApacheやNginxなどはまだTFOに対応していませんが、kernel側でリスニングソケットにTFOを強制するオプションがあるので、それを使用して検証します。 また、最新のChromeはTFOに対応しているため(OSもTFO対応が必要) 、これをクライアントとして利用します。

まず、サーバ側でTFO強制の設定をしApacheをインストールします。

$ echo 0x403 | sudo tee /proc/sys/net/ipv4/tcp_fastopen
$ sudo apt-get install apache2

クライアント側は最新のchromeを用意し chrome://flags で “TCP Fast Openを有効にする” を設定します。

この状態でChromeからapacheのデフォルトページに二回アクセスします。 Chromeは、一回目のGETでCookieをリクエストし、二回目のGETでSYNにCookieとリクエストヘッダを載せて投げています。

同様の方法を使えば、設定ファイルを書くだけで既存のサーバをTFOに対応させることができるでしょう。 しかし、このオプションはあくまでもテスト目的に使用するもので、本番運用ではkernel APIレベルで対応したものを使用するべきです。

ベンチマーク

TFOはRTTが大きい環境でこそ効果が期待されます。そこでAWSを用いて、Tokyoリージョンをクライアント、N.Virginiaリージョンをサーバとし、ベンチマークをとってみます。使用するAMIは以下です。(インスタンスにはElastic IPをふっています)

• TOKYO: ubuntu-raring-13.04-amd64-server-20130820(ami-0b8c1f0a)
• N.Virginia: ubuntu-raring-12.04-amd64-server-20130820(ami-77fcbc1e)

サーバにはApacheを、クライアントはTFOに対応しているHttpingを用いて十回のリクエストを投げる簡単なベンチを行います。

$ echo 3 | sudo tee /proc/sys/net/ipv4/tcp_fastopen
$ wget http://www.vanheusden.com/httping/httping-2.3.3.tgz
$ tar zxvf httping-2.3.3.tgz
$ cd httping-2.3.3.tgz
$ ./configure --with-tfo # TFO を有効にしてビルド
$ make
$ ./httping -g http://192.0.2.0/ -c 10    # TFO off
$ ./httping -g http://192.0.2.0/ -c 10 -F # TFO on

結果

# TFO off 10 connects, 10 ok, 0.00% failed, time 13830ms round-trip min/avg/max = 344.7/382.6/424.2 ms

10 connects, 10 ok, 0.00% failed, time 12052ms round-trip min/avg/max = 161.8/204.9/364.2 ms (TFO onのパターンは、最初の一回はCookie Requestです)

この検証では、RTTは平均で46%短くなっている事がわかります。

まとめ

TFOは、まだドラフトの段階で実装も限られていますが、仕様が固まればサーバやOSも対応が進むと考えられます。 各言語の標準ソケットモジュールレベルでの対応も少しずつ進んでいるため、今後は普通にネットワークプログラムを書けば自動的にTFO対応されるでしょう。

注意点として、通常の3WHにフォールバックした場合にリクエストデータが二重になる可能性がありますが、 一方で通信を「なるべく少なく」することによる効果は非常に大きいため、そことのトレードオフとなるでしょう。

普及にはまだ時間がかかるかもしれませんが、今のうちから自身のもつサービス検証をしてみてはいかがでしょうか。

検証環境

• Ubuntu 13.10
• kernel 3.11.0-13-generic
• Python 2.7.3
• Wireshark 1.10.2
• HTTPing 2.3.3
• Google Chrome 32(beta)

1. いくつかの言語は導入に関する議論やパッチを見つけたので載せておきます。 Ruby, Go, Python

今回から数回にわたって、Googleが進める”Make the Web Faster” というプロジェクト(以下、プロジェクト)について、プロジェクトにリストされたGoogleのプロダクトや仕様提案、ベストプラクティスなどを連載形式で紹介していきます。

Make the Web Faster

“Make the Web Faster” のページには、文字通り Google が 「Webを速くするため」に開発したプロダクトや、新しい仕様の提案、ベストプラクティスなどがリストされています。

例えば以下のようなものがあります。

• WebP
• TCP Fast Open
• Google DNS
• Google Hosted Libraries
• Page Speed
• SPDY
• etc.

この連載では、そこから特に重要なものを、筆者の気の向いた順に紹介していきます。

そして、連載初回の今日は、これら “Make the Web Faster” を紹介するにあたり、共通して押さえておくべき基本知識について紹介します。

Web というターゲット

プロジェクトには様々な手法がリストされていますが、全てに共通するのは「Webの高速化」を目的としている点です。対象がWebであるために、共通するチューニングの観点としては大きく「ネットワーク」と「アプリケーション」の2つが考えられます。

ネットワークのチューニング

Web はネットワークへのアクセスを伴います。ネットワークを効率よく使うことは、パフォーマンスの改善を試みる上で非常に重要です。

まずは、一番簡単な原則としてこれだけは覚えておいてください。

なるべく小さく

Webは、HTML,CSS,JS,画像,動画などのデータをネットワーク経由でクライアントに届けています。このデータが小さければ小さいほど、速く届けることができます。特に画像や動画はサイズが大きくなりがちです。送る上でなるべく小さくするにはどうするか、ここで圧縮などの技術が有効になります。

なるべく少なく

ネットワークアクセスの回数が増えるほどオーバーヘッドが大きくなるため、極力少ない方が望ましいです。アクセス回数を減らす工夫や、プロトコル仕様レベルの改善などがあります。

なるべく近く

ネットは世界の裏側でも簡単にデータを届けることができますが、遠ければそれだけ遅くなってしまいます。しかし、コンテンツの種類によっては、ユーザに近いところにそれを配置するなど、工夫できるところがあります。

他にも HTTP と TCP についての基本的な知識が必要な回もあります。そうした場合は、3 Minutes Networking や、現在執筆が進んでいる High Performance Browser Networking などが参考になるでしょう。(この本はすでにHTTP2.0など最新のトピックも扱っています。)

アプリケーションのチューニング

WebでAPIを用意して、リクエストに対するJSONを返すだけのサービスなら、純粋にレスポンスにかかる時間(いかに早くJSONを返すか)に集中してチューニングすれば良いかもしれません。

しかし、 多くの場合Webはクライアントとして「ブラウザ」が前提になります。また、ブラウザは基本的に人間が使うものです。従って、以下のような観点もチューニングには必要になってきます。

ブラウザの挙動

ブラウザがどのようにリクエスト/レスポンスを処理するかといった挙動を理解することは重要です。そこを理解しないと、効率よくブラウザにコンテンツを届けられず、思ったような速度が得られない場合があります。

人間への視覚フィードバック

ブラウザを使って人間が操作することを想定しているならば、視覚的なフィードバックを調整することで「速いと感じる」という観点からチューニングするアプローチもあります。実際、純粋なレスポンスタイムの短縮が限界にきたら、こうした観点のチューニングは避けては通れないでしょう。

こうしたベストプラクティスについては、ハイパフォーマンスWebサイト で「14のルール」としても紹介され、 続・ハイパフォーマンスWebサイト では、そこにモダンな技術も追加されています。両方を手元に置いておくことをお勧めします。

「推測するな、測定せよ」

「推測するな、測定せよ」という言葉があります。全てのチューニングは、ボトルネックの把握が必要です。やみくもにチューニングすればいいというものではありません。場合によっては遅くなるケースも考えられます。

この連載では、テーマごとに「なぜそれらが作られたのか」を重視して解説します。そこから学べるものが多いからです。しかし、筆者は連載を通して、「入れると速くなるから、今すぐ入れましょう！」などというつもりは一切ありません。

もし、紹介したものから何かを導入するのであれば必ず測定をし、効果と対応クライアントなどをきちんと確認した上で、自己責任で進めて下さい。 また導入した場合は、ノウハウや効果をBlogなどで是非公開してください。それは貴重な情報であり、 “Make the Web Faster” にとって大きな貢献になります。