しかし、アプリの動作を注意深く観察してきた方なら、以下の改善点に気づいているかもしれません。
* 読み込み時間の短縮
* spdy サポート
* TLSハンドシェイクの回数が減少
* IPv6対応
* より優れたTLS暗号
* 厳格な輸送セキュリティ
* gzip圧縮により、より多くのリソースが利用可能になります。
* WebSocketサポート
この記事では、いくつかの変更点について概説し、それらの変更点の背後にある技術について説明します。
HTTPアーキテクチャの概要
お客様のHTTPリクエストはTCP接続を介して送信され、このTCP接続はTCPロードバランサーを介して当社のウェブサーバーのいずれかに確立されます。ウェブサーバーは次の2つの処理を行います。
* SSL/TLS を処理する
* HTTPリクエストをアプリケーションサーバーにプロキシする
つまり、各データセンターには、TCPロードバランサー、少数のウェブサーバー、そして多数のアプリケーションサーバーが設置されている。
IPv6
ご存知かもしれませんが、IPv4 (インターネット プロトコル バージョン 4) アドレスの数は約 40 億です。これは多いように思えますが、理想的には、どのデバイスもインターネットを介して他のどのデバイスとも直接通信でき、人口は 70 億人を超え、西欧諸国の人々はインターネットに接続されているデバイスを平均 5 台程度持っていることを考えると、それほど多くはありません。では、なぜこれが問題なのでしょうか? 荷物を投函する際に、宛先として郵便番号と番地しか書けないと想像してみてください。名前や部署名などは書けません。この荷物を会社の特定の部署に送ったり、誕生日カードを正しい家族に送ったりするにはどうすればよいでしょうか? メインストリート 15 番地の家の父親が「私は 15a 番地、母は 15b 番地、息子は 15c 番地、娘は 15d 番地に住んでいるとしましょう。ただし、郵便受けは引き続き 15 番地を使用します」と言ったとします。この場合の適切な反応は、「それは愚かな考えだ」でしょう。確かにそれでうまくいきますが、番地の末尾にアルファベットが付いているのはそういう目的ではありません！それは、1軒の家が複数の住所に分かれる場合に、隣人が17番ではなく19番の住所を取得する必要がないようにするためのものです。
とはいえ、これはインターネット上で標準的な解決策です。これはネットワークアドレス変換（NAT）と呼ばれ、1つのIPアドレスを複数のデバイスで共有し、ポート番号を特定の宛先の識別に使用します。そのため、ルーターの背後にある特定のデバイスにアクセスするには、ポート8080をそのマシンに転送することができます。これは良いアイデアのように思えるかもしれませんが、残念ながら、ポート番号は文字の接尾辞と同様に、すでに他の用途に使用されています。ポートは、デバイス上で使用したいサービスの種類を指定するためのもので、Webトラフィック（80）、暗号化されたWebトラフィック（443）、メール（25）などです。結果として、NATゲートウェイ（自宅のルーターなど）の背後にいる場合、サービスは1つのデバイスでしか実行できません。外部から2つのHTTPデバイス（NASとWebカメラ）にアクセスしたい場合は、運が悪く、不格好な回避策に頼らざるを得ません。NATは、誰もが使用する汚いハックとして正当に考えられています。
真の解決策はIPv6であり、そのアドレス数は地球上の原子の数よりも多い。しかし、IPv6の普及は遅く、現時点ではインターネットトラフィック全体の約2%しかIPv6ではない。これはジレンマだ。ほとんどの顧客がまだIPv6を利用していないため、企業はIPv4をサポートせざるを得ず、すべての企業が依然としてIPv4をサポートしなければならないため、顧客はIPv6を使い始める必要がない。とはいえ、進展は見られ（Comcastのリンク参照）、IoT（モノのインターネット）はIPv6の恩恵を大いに受け、顧客需要が増加する可能性がある。
必要なのは、企業がIPv6をサポートする必要性を感じ始め、その責任を真剣に受け止めることです。私たちはまさにそれを実践しており、先週までにアプリケーションの最後の部分をIPv6で利用できるようにしました。
IPv6通知Chrome拡張機能をチェックしてみてください。プロバイダとアクセスしているウェブサイトが適切な対応をしているかどうかを確認できます！
SPDY
ここ数年、HTTP2.0やSPDYについて耳にしたことがあるかもしれません。SPDYは、公式委員会を待たずにHTTPを改善するためのGoogleのイニシアチブです。HTTP1.1の何が問題なのでしょうか？実際にはそれほど大きな問題ではなく、要求が著しく増大しただけです。Webサイトを表示するには、ブラウザは多くのリクエストを実行する必要があります。最初の訪問では平均約40件です。インターネットの初期の頃は、HTMLドキュメントの1つだけでした。これに対処するために、ブラウザはWebサーバーへのソケットプールを開きます。SPDYでは、リクエストを単一のTCP接続で多重化できるため、これはもはや必要ありません。*nixマシンでnetstatコマンドを使用すると、使用されている接続数を簡単に確認できます。
改善点はたくさんあります。
* ヘッダー重複排除
* 圧縮
* リクエスト多重化
* サーバープッシュ
私たちはNGINXを使用しているため、依然としてspdy2に依存しており、spdy3.1が安定版としてリリースされるまで待つ必要があります。
TCP負荷分散
RackspaceやLinodeのようなIaaSプロバイダーでは、TCPロードバランサーを作成でき、弊社でもこれを多用しています。デフォルトでは、これらのロードバランサーはラウンドロビン方式でスケジューリングされます。これは理にかなっているように思えますが、HTTPS接続ごとにクライアントが異なるWebサーバーに接続される可能性があることに気付くと、問題が生じます。サーバーが異なる場合、SSLセッション再開は使用できず、SSLハンドシェイクを再度実行する必要があります。つまり、ラウンドトリップタイム（リクエスト/レスポンスサイクル全体にかかる時間）が1回分余計にかかることになります。
クライアントが毎回同じウェブサーバーに接続されるようにし（かつ高可用性を維持するため）、ロードバランサーの設定でセッション永続性を有効にすることができます。
ただし、お使いのブラウザがSPDYをサポートしている場合は、すでに1つのTCP接続しか使用していないため、これはそれほど大きな問題ではありません。
TLS暗号
近年、BEASTなどのSSL/TLSに対する攻撃がいくつか発生しています。これらの脆弱性に対処する鍵は、Webサーバー上で優先暗号スイートの順序を設定し、脆弱な暗号を除外することです。しかし、すべてのブラウザとオペレーティングシステムに対応する必要があるため、これは少々複雑な作業となります。
少なくともhttps://www.ssllabs.com/ssltest/analyze.htmlのSSLテストによれば、我々はこの難題をうまく解決できたようです。
前方秘匿性
暗号化された通信チャネルを解読できない場合、暗号化されたデータをすべてキャプチャして後で解読するのが良い方法かもしれません。一部の暗号化方式では、秘密鍵が分かれば、以前に記録した安全な通信をすべて復号できます。前方秘匿性を採用している暗号方式では、これは事実上不可能です。1つのセッションの鍵を解読できたとしても、記録した他のすべてのセッションについても同じことをしなければなりません。
この記事で紹介されているすべてのものと同様に、弊社もこれを支持しています。アプリのステータスは、https://www.ssllabs.com/ssltest/analyze.html で確認できます。
厳格な輸送セキュリティ：中間者攻撃を避ける
ウェブブラウザにmail.google.comのようなURLを入力すると、https://mail.google.com/にアクセスしますが、これは安全でないトラフィックです。つまり、あなたとGoogleのサーバーの間にあるどのデバイスでも、このトラフィックは傍受され、操作される可能性があります。この場合、https://mail.google.com/はhttps://mail.google.com/にリダイレクトを送信し、それ以降の接続は安全になります。しかし、誰かがリダイレクトを傍受してプロキシとして動作し始めたとします。そのプロキシはあなたのプレーンなHTTPリクエストを受け取り、https://mail.google.com/に送信します。https://mail.google.comから応答を受け取ると、それを復号化してプレーンなHTTPとしてあなたに応答を送信します。このようにして、傍受者はあなたのすべてのデータを盗聴して操作することができ、あなたは違いに気づくことはありません。これは中間者攻撃と呼ばれます。
完全に解決できる方法はありませんが、HTTP Strict Transport Securityヘッダーは、ブラウザに対し、今後二度とプレーンなHTTPでサイトにアクセスしないように指示します。これを利用して、脆弱性の影響を受ける期間をページへの初回アクセス時のみに限定します。
数週間前から、すべてのHTTPS URLにHSTSヘッダーを送信するようにしました。