🖖🏿 🏠 🤜 Yandex.MailチームとNginxチームの共同実験：SPDYは本当にインターネットを高速化するのでしょうか？ 🚸 👨🏾‍🎓 🏴󠁧󠁢󠁥󠁮󠁧󠁿

Yandex.Mailのチームは、Nginxチームとともに、SPDYがインターネットを高速化する方法と量についての詳細を示す実例の「」にドットを付けるための調査を実施しました。

もちろん、SPDY自体について知っています。 2011年に、いくつかのGoogle開発者が、通常のHTTPを置き換えるために設計された新しいプロトコルのドラフトを公開しました。主な違いは、応答の多重化、ヘッダーの圧縮、およびトラフィックの優先順位付けでした。最初のいくつかのバージョンは完全に成功しませんでしたが、2012年までに仕様が確立され、最初の代替（Google以外の）実装が登場し、ブラウザーでのサポートのシェアが80％に達し、SPDYをサポートするnginxの安定バージョンが登場しました。

明らかに、プロトコルは有望な観点から優れた、合理化されたソリューションに変わりつつあり、本格的な実装作業サイクルを開始していることがわかりました。もちろん、テストから始めました。私は彼なしでブロゴスフィアで公開された賞賛を本当に信じたかったのですが、これは何百万人ものユーザーがいるプロジェクトではできません。 SPDYが本当に加速効果を持っているという確認を受け取っているはずです。

Google自体を含め、SPDYに関する興味深い研究が数多くあります。プロトコルの作成者は、彼らの場合、SPDYがダウンロードを40％高速化することを示しました。 SPDYプロトコルの研究もOperaによって行われました。しかし、計算方法も、そのような印象的な結果が達成されたページの例も、これらの研究にはありませんでした。

SPDY。内観

SPDYプロトコルは非常に複雑であり、説明が困難です。それがどのように機能するかを明確に説明してみましょう。

複数のJavaScriptファイルとCSSファイルが接続されたWebページを想像してください。ブラウザはサーバーへの複数の接続を開き、これらのファイルのサーバーからのダウンロードを並行して開始します。サーバーでHTTPSが有効になっている場合（Yandex.MailがHTTPS経由で動作することがわかっている場合）、接続ごとにSSLハンドシェイクを行う必要があります。つまり、ブラウザーとサーバーは送信データを暗号化するキーを交換する必要があります。そのためには、サーバーとブラウザーの両方が、ある程度の時間とプロセッサーリソースを費やす必要があります。

SPDYプロトコルは、サーバーへの接続を1つだけ確立する必要があるという事実により、時間を短縮するように設計されています。つまり、ハンドシェイクに必要な接続は1つだけです。その結果、静的ファイルをダウンロードするために、ブラウザーはサーバーとの接続を確立し、応答を待たずにすぐに順次、必要なすべてのスクリプトの要求を送信します。

その後、サーバーはこれらのファイルを順番に提供し始めます。

Https

接続+ TLSハンドシェイク	接続+ TLSハンドシェイク	接続+ TLSハンドシェイク
> GET /bootstrap.css > ... <HTTP / 1.1 200 OK <... <body {margin：0;}	> GET /jquery.min.js > ... <HTTP / 1.1 200 OK <... <（関数（ウィンドウ、未定義）{ <...	> GET / logo.png > ... <HTTP / 1.1 200 OK <... <[データ] <...

HTTPS + SPDY

接続+ TLSハンドシェイク
> GET /bootstrap.css > GET /jquery.js > GET /logo.png <[bootstrap.css content] <... <[jquery.jsコンテンツ] <... <[logo.png content]

最初の起動を高速化する

私たちのメールは多くの静的なものを使用しています。最小化された形式では、合計は、すべてのテーマおよびすべてのページの約500 MBのリソースです。これらはcssおよびjsファイル、および画像です。大量の必要な統計情報があるため、最初の起動時間はそれほど速くありません。

この静的データは、モスクワおよびCDNにある約200のサーバーのユーザーにロシアおよび海外で配布しています。 Nginxをサーバーとして使用します。これは、静的を配布できる既存のWebサーバーの中で最も高速で信頼性が高いと考えているためです。昨年、NginxチームはSPDYバージョン2プロトコルをモジュールとして実装することを発表しました。そして、2013年初頭に、Nginxとこのモジュールを使用して静的データの配布を試み始めました。

継続的な最適化

静的なダウンロード速度が長い間心配されてきました。ユーザーができるだけ静的にロードする必要がないように、すでに多くのことを行っています。まず、もちろん、すべてのjsスクリプトとcssはアセンブリ中に最小化されます。写真のサイズを制御し、メールに必要な静電気の量を超えないようにします。

第二に、いわゆるフリーズスタティックの技術を使用します。ファイルの内容が変更されていない場合、ユーザーはファイルを再ダウンロードする必要はありません。したがって、バージョンからバージョンへのパスが変更されないようにします。レイアウトを構築するとき、このパスはファイルの内容のハッシュ合計を計算することにより取得されます。たとえば。そのようなパスを形成するには、 Borshchikを使用します。

ロード時間の測定方法

最初に、設定でSPDYを有効にするだけで、どれだけ加速するかをテストマシンで測定することにしました。 Ubuntu 12.04を実行していた、ユーザーがアクセスできない1台の物理マシンに静的データを配置しました。タイプライターには、12コアと20GBのRAMがありました。すべてのスタティックは、RAM内のRAMディスクに配置されました。

これらの測定から判断すると、メールを非常に顕著に加速しました。 Googleが測定を加速したのとほぼ同じ方法で。しかし、私たちの内部では、メールのダウンロード、ネットワークの問題、パケット損失、その他のTTLのすべての機能を完全にエミュレートすることはできませんでした。したがって、誰かのダウンロードを遅くするかどうかを理解するために、ユーザーに対して実験を行うことにしました。

その中で、10％がすべての中からランダムに選択され、2つのグループに分けられました。最初のグループはSPDYを介して静的に与えられ、2番目のグループはコントロールでした。

最初のグループでは、静的変数はドメインexperiment.yandex.stから読み込まれ、2番目のグループではmeth.yandex.stから読み込まれました。制御グループの必要性は、すべてのメールユーザーに対して静的データをキャッシュできるという事実によって決定されました。したがって、彼らが別のドメインに移動した場合、静的データをリロードする必要がありますが、実験に参加しなかったユーザーはそうしません。比較は正しくありません。

指標

最新のブラウザはすべて、 Navigation Timing APIをサポートしています。これはブラウザのJavaScript JavaScript APIであり、ロード時間に関するさまざまなデータを受け取ることができます。これにより、ユーザーが「メール」ページにアクセスし、静的データのロードから魔法が始まったミリ秒まで知ることができます。クライアント側は、必要なすべての静的ファイルがロードされた瞬間を認識するように機能します。スクリプトでは、2番目の瞬間から1番目の瞬間を差し引き、すべての統計を完全にロードしてこの数値をサーバーに送信する時間を取得します。

ダウンロード速度に加えて、私たちにとって重要な側面は静的ダウンロードの数です。クライアントで2つのことを確認します。

1. 静的ファイルを取得できましたか？たとえば、サーバーは、そのようなファイルはないと答えました。このような各アンロードの事実もサーバーに送信し、それらの数のグラフを作成します。

2. ファイルが本来あるべきサイズになったかどうか。このタイプのエラーについて詳しく説明しましょう。ファイル転送中にサーバーとクライアント間の接続が切断された場合のブラウザーの動作を確認しました。 Firefox、IE、および古いOperaが200のステータスとすべての失われたコンテンツを提供することが判明しました。ブラウザは、Content-Lengthヘッダーに示されているデータとまったく同じデータを受信したことを確認しません。しかし、さらに悪いことに、IEとOperaは同時にこの受信不足のコンテンツをキャッシュします。したがって、キャッシュが生きている間は、ファイルを再ダウンロードするために正しく動作しません。幸いなことに、Firefoxは次のリクエストでサーバーからデータをリロードします。この不正な動作を報告するバグは、Mozillaトラッカーにあります。

測定結果

数値に基づいて、静的、平均、および80％のパーセンタイルの平均ロード時間を計算しました。残念ながら、機器の加速は統計誤差を克服しませんでした。

平均ロード時間は0.6％減少しました。つまり、Googleのすべての保証にも関わらず、SPDY自体は、40〜50％のクレイジーなユーザーによってサイトを取得して高速化することはできません。

Opera 12.16とコンテンツ長

mail.yandex.ruでSPDY / 2を有効にしようとしました。オンにした後、ログに多くのエラーが記録されたため、オフにする必要がありました。 Operaには不快なバグがありますが、これはサポートが既に中止されているため、修正される見込みはありません。それは、POSTリクエストを送信するときにOperaが無効なContent-Lengthヘッダーを送信するという事実にあります。問題はここに記述されています： trac.nginx.org/nginx/ticket/337

古いOpera（12. *）の訪問者が多く、POST要求が使用されている場合、SPDYを有効にすることはお勧めしません。

UPD：SPDYの開発者は、バージョン1.5.10以降では、nginxがすでにプロトコルの3番目のバージョンを実装しているというコメントを求めているため、古いOperaはSPDYを使用する際にSPDYを使用しなくなります。したがって、Operaのバグは無関係です。

結論

私たちの研究の後、SPDYは私たちにとって何も加速しないという結論に達しました。静的のロードを最適化し、そのサイズを縮小し、最適なキャッシングははるかに-桁違いに-インターフェースの速度に顕著な効果をもたらします。

しかし、SPDYでは、私たち自身に予想外の利益を見出しました。多くのクライアントが各ファイルの接続の作成を停止したという事実により、これらの接続は著しく少なくなりました。つまり、プロセッサの読み込みが少なくなりました。つまり、いいえ、しかし節約があります。

これは、サーバー上のオープン接続グラフでSPDYを含める方法です。

静的読み込みエラーの数に違いは見つかりませんでした。これは、SPDYをNginxに含めても、サポートされていない場合でもブラウザーで問題が発生しないことを意味します。

nginxでSPDYプロトコルの実装をリバースエンジニアリングし、意図したとおりに機能することを確認しました。テストでは、SPDYモジュールが接続されたApacheを介して静的変数を配布し、合成クエリで同じ方法で測定することも試みました。この場合、加速度も非常に小さい量であると確信しました。

その結果、すべてのyandex.stにSPDYを含めました。 100500％の加速はありませんでしたが、CPU負荷が少ないため、電力を節約できました:)

高速化が行われないもう1つの理由は、Nginx自体が非常に高速なサーバーであることです。当初、SPDYはApacheサーバーのモジュールとして実装されていましたが、ご存知のように、接続を維持するには多くのリソースが必要です。したがって、Apacheで接続を保存すると、そのパフォーマンスが著しく向上します。 Nginxでは、10,000の非アクティブHTTPキープアライブ接続を維持するために約2.5Mのメモリが必要です（ソース-nginx.org/ru ）。

残念ながら、GoogleがSPDY加速度測定でどのように研究を行ったかを把握することはできませんでした。したがって、我々の研究の結果は、このプロトコルが何も加速しないというメッセージとして受け取られるべきではありません。私たちの調査結果は、SPDYを使用して静力学を配布する特定のケースの研究の結果です。

Yandex.MailチームとNginxチームの共同実験：SPDYは本当にインターネットを高速化するのでしょうか？

SPDY。 内観