ユーザーへの配信を高速化

アナトリー・オルロフ（ anatolix ）、デニス・ナゴルノフ（ Yandex ）

アナトリー・オルロフ：みなさん、こんにちは！ 私の名前はアナトリーです。 私は過去10年間、Yandexで働いています。 Yandexではさまざまなことをしましたが、HighLoadでは常にさまざまな種類の速度に関するレポートを作成することがありました。 私は共同報告者がいます-デニス・ナゴルノフ、彼はまだYandexで働いており、とりわけ、スピードも信じていません。



このレポートは、「ユーザーへの配信速度」と呼ばれます。 ご存知のように、膨大な数の企業がページの読み込みを最適化しようとしています。 一部の企業は、達成した結果を非常に誇りに思っており、これらの結果をページの下部に記載せず、上部にも記載しています。



たとえば、Googleのスクリーンショット：







ブラウザで開発者ツールの同じページを見ると、数値がわずかに異なることがわかります。430ミリ秒ではなく、625ミリ秒です。







直観的には、430がGoogleサーバー上のどこかにあり、625がブラウザにあることはだれもがはっきりとわかります。 質問：どの数字が速度指標に適していますか？ 私は、サーバー上の数字を誇りに思うことができるので、ブラウザの数字がより便利であるように思えますが、それによる利益はもはやありません。 そして、ブラウザの数字はユーザーエクスペリエンスを本当にスピードアップします。







クライアントで何らかの速度メトリックを作成したいと考えています。 問題はすぐに発生します-何を測定し、どのように測定するのですか？



測定方法は簡単な質問です。 また、ページの読み込みは複雑なプロセスであるため、何を測定するかはそれほど簡単ではありません。 しかし、想像してみてください。lib.ruからWar and Peaceのファイルをダウンロードすると、すぐに読むことができ、数分でロードされるでしょう。 これは、ブート時に選択するポイントが明確でない例です。



たとえば、ページからページに移動するとすぐに機能するサイトが多数あります。すべてキャッシュされているため、すぐにナビゲーションできますが、結果の読み込みには時間がかかります。



世界中のすべてのサイトで何を測定する必要があるかという質問に対する答えは存在しません。 特定のサイトについて、そのような答えを思い付くことができます。 検索エンジンの場合、おそらく最初の検索結果を読み込むことは、測定する価値のあるマークです。



そのようなフレーズがあります：ツールからハンマーしか持っていない場合、すべての問題は釘のように見えます。 このエリアには非常に多くのハンマーがあります。







つまり 多かれ少なかれ2つのAPIと2つのプロパティがあり、1つはChromeに実装され、もう1つはIEに実装されています。 したがって、すべてを測定できるわけではありません。 たとえば、問題の最初の結果がいつ描画されたかはわかりません。



何を測定できますか？ あなたのブラウザで起こっていることのいくつかの非常に単純化されたスキームがあります（実際には5倍大きいです）：







ブラウザがサーバーにリクエストを送信した時点があります。 その後、サーバーはHTMLの発行を開始します。 最初に最初のバイト、次に静かに残りのバイト、次に最後のバイトが来ます。 そして、ここで特定のメトリックのセットを取得します。 最初のバイトまでの時間を測定し、転送時間を測定し、最後のバイトまでの時間を測定し、それをJava Scriptですべて引き出して、サーバーにアップロードし、サーバーでグラフを作成できます。



比較のため。 これは高速サーバーの最初のバイトであり、サーバーはモスクワからそれほど遠くない場所にあります。 ロシアのさまざまな都市でどのように見えますか：







ここで各行にはいくつかの意味があり、これはいわゆる パーセンタイル。 知らない人にとって、50パーセンタイルは、ユーザーの応答の50％がこの値よりも速く、50％多いことを意味します。 まあ、95％は同じです。 このチャートには何が見えますか？ 以下は、0を条件付きで処理するサーバーです。 最初のバイトはすぐにサーバーから飛び出します。 これは最初のバイトであるため、ページサイズは最初のバイトには関係ありません。 たとえば、ここで興味深いデータのうち、ウラジオストクを見てみましょう-何らかの理由で、彼は自信を持ってノボシビルスクを高いパーセンタイルで「作成」します。そして、低いパーセンタイルを見ると。 低パーセンタイルは、光の速度によって条件付きで決定され、高パーセンタイルは、何によって不可解に決定されます。 私にとっては、このグラフから、ノボシビルスクにはつながりに何らかの問題があるように思えます。







高速サーバーの最後のバイト。 実際、これは私がここで描いたある種の合成指標です。 つまり ここでは検索時間を取りましたが、ここでのサーバー時間はそれほどゼロではないため、結果からそれを差し引きました。 つまり、大まかに言って、これはサーバーの稼働時間がゼロの場合に検索応答にかかる時間です。 ここで、数値が十分に大きいことがわかります。 興味深いことに、ここでも、ノボシビルスクはある種の反指導者になり、ウラジオストクは予想外にクールに見え、アルマトイとキエフを「作り」ます。 これらの数字について。 順序を理解できるように番号を付けました。 そこで、下の桁に95パーセンタイル、コペックで3秒。 つまり、大まかに言えば、サーバーを100ミリ秒間最適化すると、しばらくはまったく最適化されないことがわかります。







前の2つのスライドには統計がありました。 嘘、露骨な嘘、統計があるということわざがあります。 これは統計です。



統計について話すときは、制限について話す必要があります。 まず、これらのAPIはすべてのブラウザーでサポートされているわけではありません。 つまり これはデスクトップでも問題ありませんが、携帯電話では、AndroidのChromeのみがこれらのAPIを実行できます。 第二に、ブラウザが異なる数字を与えることを理解する必要があります。 つまり ChomeベースのブラウザとIEの異なるプロパティ名は、何か異なるものを測定すると言います。



そして、Chromeでこの数字が何を意味するのか理解できる場合、ソースがあるため、IEで数字が何を意味するのか、実際には理解できません。 したがって、純粋に正式にそれらを比較することはあまり正しくありませんが、一方で、ブラウザの作成者ではなく、IEを追い越そうとしていない場合、あなたは本当に気にしません、あなたがサイトでブラウザの分布がほぼ同じであるため、 、そして通常。 そして、異なる統計的発見は異なる認知エラーの影響を受けます。



もっと面白いものを見てみましょう。 ここでは、さまざまなブラウザーのコンテキストで最初のバイトまでの時間の内訳を示します。







ここで何が見えますか？ ChromeはIEよりも高速であり、Operaのパフォーマンスは予想外に劣っています。 そして、ここにはSafariと呼ばれるスーパーブラウザーがあります。これは、他のすべてのブラウザーよりも2.5倍高速に動作します。 これは、バイアスと呼ばれる古典的な例です。 状況は非常に単純です-周りを見渡せば、それからMacintoshを1秒おきに、比較的話しています。 したがって、バイカル湖の外のどこかに森に行くと、マッキントッシュはあなただけのものになり、そこに他のケシはありません。そのため、Safariのすべての人がページをすばやく開くのは確かですが、しかし、彼らは通常良いインターネットを持っているからです。 彼らはモスクワにいて、ITの専門家であり、すべてです。 そのような写真が存在することは驚くことではありません。 これは、いくつかの仮説を見たときに、それらをチェックして理解するために何らかの形で考えなければならないという事実です。







HTTPSと呼ばれるこのような魔法のプロトコルがあります。 私たちは皆彼を愛し、誰もが彼のところへ行きます。 彼について何を知っていますか？ 一般に、プロトコルの速度は遅くなります。 誰もが、あらゆる種類の公開鍵の計算、あらゆる種類のハンドシェイクがあり、余分な往復があることを理解しています。 一般に、誰もがHTTPSが遅いことを知っています。



これらのグラフを見ると、HTTPSの最初のバイトが速くなっています。 私はあなたにスケジュールを見せません、これはここで最も重要ではありません。 これは一種の統計の選択、つまり ほとんどの場合、ブラウザはハンドシェイクの最初のバイトをHTMLの最初のバイトであると見なしているため、少し高速であると言われます。 しかし、ここでは、一般的に全体的に速くなるという奇妙な結論があります。 それは本当です、HTTPSはより高速です。 そして、ある時点でのこの結論は非常に逆説的であることが判明し、問題が何であるかを掘り始めました。







すでに見せました。 しかし、誰もがすでに忘れているので、私は再び見せます。 パラメータ「1バイト目までの時間」と「htmlの送信時間」を確認します。 ここでは、このジョークの関係に違いがあります。 だから：







だから：







だから：







または：







つまり、特定のスケジュールがあります。これは、実際にはプレゼンテーションの最初のスケジュールであり、何が描かれているのかを理解するために考慮する必要があります。







私たちが何をするか見てください x軸は単なるリクエスト番号です。 ただし、リクエストはhtml転送時間でソートされます。 そして、y軸には緑色のドット（最初のバイトまでの時間）と黒いドット（html伝送までの時間）があります。 すべてがhtml転送の時間でソートされるため、すべてのブラックポイントは1つの連続した行に並んでいますが、これは多少論理的です。 そして、最初のバイトまでの時間がソートされていないため、それらは整列していませんでしたが、何らかの相関があることは明らかです、すなわち そこでは、最初のバイトのロード時間が長いほど、送信時間が長くなります。 しかし、このグラフでは、明らかに異なる2つのクラスターがあります。 最初のクラスターはほぼ正常に動作し、送信時間は相関しており、約70％であり、右端の30％は奇妙な要求の時間であり、条件付きでロード時間は約0であり、最初のバイトの時間はゼロではありません。 つまり、大まかに言えば、ページは長い間馬鹿げており、その後すぐに完全に降伏しました。 質問：それは何ですか？ 信じられないでしょう、これらは実際にはアンチウイルスです。



ウイルス対策はどのように機能しますか？ アンチウイルスは、恐ろしいウイルスやエクスプロイト画像をページなどにアップロードしていることを非常に恐れています。 したがって、httpを介して何かをロードすると、アンチウイルスはすべてをバッファリングし、最後のバイトを待機し、すばやくチェックしてからすべてを吐き出します。 このページは既にコンピューター上にあるため、ページの長時間のスローダウンと、すぐに到達したことがわかります。



質問：この場所でHTTPSに切り替えるとどうなりますか？ すぐに、すべてのウイルス対策ソフトウェアは魔法のようなことをする能力を失い、ページはその後より速くロードを開始します。 実際、この効果は、すべての直感的な判断にもかかわらずHTTPSがHTTPよりも高速である理由です。 そして、これがGoogleやFacebookなどのすべてのサイトがHTTPSに切り替わる理由です-それはただ愚かです。 これはある種の非常に革命的な声明であることを理解しているので、証拠を添付します。







Proofpic-それは何ですか？ これは、特定のYandex内部インターフェイスからの写真です。 以前のグラフをExcelで再描画しましたが、このグラフをExcelで再描画した場合、Proofpicではなく、偽造できます。 したがって、それは細い線で、非常に便利ではありません。 これは、サンクトペテルブルク市のHTTPSではなく、HTTPSでの特定のYandexページの読み込み時間です。 パーセンタイルはX軸に沿ってプロットされ、ロード時間は対数であるにもかかわらず、Y軸に沿ってプロットされます。 規模は10万、1万で、100、200、300ではありません。すべてのパーセンタイルでのHTTPSの方が高速であることがわかります。



これはウラジオストクでも同じです：







Yandexがウイルス対策に苦労したとき（ウイルス対策会社と良好な関係があります）、私たちはすべてを「ホワイトシート」に入れるように依頼しました。 緑色のドットで作成したグラフは非常に古いものであり、ここまでです。 しかし、この効果は消えていません。これらは文字通り9月の新しいグラフィックです。 これらのグラフは、私たちのサイトが禁止しているさまざまなDPIシステムを提供しているように思えたので、インターネット上で悪いことは見ていませんでした。 そんなことがあるようです。



このチャートはキエフのものです：







そして、ここでは状況はまったく同じです。ロシアの偉大なDPIはそれとは何の関係もないかもしれませんが、何らかの形でそこに参加しています。



そして、このチャートはイスタンブールのものです。







イスタンブールでは、おわかりのように、HTTPSとHTTPは実質的に同じであり、他の状況もありますが、その理由はわかりません。



私が描く結論は、おおむね非常にスマートであると考えている膨大な数の異なるタイプのシステムがあり、彼らはあなたがHTTPに持っているものに非常に興味があり、このために速度が低下するということです。 したがって、ほとんどすべての場合にHTTPSを使用することをお勧めします。







これは一種の中間結果であり、最初の部分の終わりです。



サーバー時間がすべてではないことに気付きました。 そして、クライアントを測定する方法を理解しました。 ここではっきりしないのは、ウラジオストクでpingが明らかに200ミリ秒未満である場合、95パーセンタイルでのページの読み込み時間が3秒になる可能性があるということです。 そして、ここで私が話したこれらのブラウザAPIの欠陥が明らかになります。なぜなら、それはあなたに数字を返し、あなた自身はこの数字が何から来たのかわからないからです。



tcpdumpと呼ばれる魔法のツールがあります：







すべての管理者は、これを知っており、使用したことがあります。 ツールは何をしますか？ トラフィックを自分から削除することができます。サーバーがユーザーにパケットを送信すると、パケットは「おい、パケットを受信しました」というユーザーから送信されるため、配信時間を検出できます。 問題は、これは時間がかかることであり、次に、ポイントごとに適用され、1つのセッションを見ることができ、10セッションを見ることができますが、tcpdumpで100万セッションを見ることができません。 作業が実際に愚かであるかのように、質問は次のとおりです。 あなたができることがわかりました。



そのようなオープンソースツールがあります。 書きました。







GitHubでプロジェクトを開くのを忘れたことに気付きましたが、レポートの直後にそれを行います。 2番目のリンクに配置され、最初のリンクに転送されます。



これは何ですか これは、tcpdumpを解析するツールです。 tcpdumpを解析してテキストファイルを作成し、Excelに読み込んでそこで何が起こっているのかを理解できます。 これは最終製品ではなく、ハードコアなツールであるとすぐに言うことができます。 お気軽にご連絡ください。使用方法を教えます。



次に、実際にツールとして使用できる結果を生成しようとします。 このようなスタンドを見てみましょう：







これは古典的なスタンドです。 Webサーバーがあり、その上にある種のバランサーがあります。たとえば、nginxです。 要求はインターネットから送信されます。 これらのリクエストのタイミングがここにあることを理解してみましょう。







クライアントのリクエストは常にゼロミリ秒で到着します。これは、それから時間をカウントし始めているためです。 私たちのバランサーは非常に高速でよく書かれているため、このリクエストは同じゼロミリ秒でバックエンドに送られます。 バッグが来て、すぐに投げました。







以下。 Webサーバーの稼働時間。 この特定のWebサーバーは次のように設計されています。 彼は何か170ミリ秒について考えた後、完成したページを完全に放棄します。 そして、リクエストが通常1つのバッグである場合、答えはいくつかのバッグであり、最初と最後のバッグを受け取りますが、彼女はすべて私たちに生まれ、すべてを吐き出すので、再び同じものになります時間。 そして、バランサーはこのページをユーザーに配布し始めます。実際には、nginxが書かれています。







また、バランサーは高速であるため、170ミリ秒でユーザーに最初のバイトを提供します。 質問：彼はいつ最後のバイトを提供しますか？







このグラフは、tcplanzの結果に基づいています。 チャート上には何がありますか？ X軸には、時間でソートされたリクエスト番号が表示されます。 ここには実際には4本のラインがありますが、以下の3本のラインは条件付きで1本に接続されています。これらは、ほぼ同じもので、すべて170ミリ秒であり、互いに重なり合っているためです。 そして紫色の線は、バランサーからのユーザーへの応答の最後のバイトがなくなったときです。 ここで何が見えますか？ Webサーバーは170ミリ秒でページを作成し、それをユーザーに提供し始めたときに、最後のバイトを490ミリ秒で提供しました。







つまり 結論は次のようになります。「パケットは今までどこにぶら下がっていますか？」という質問をすると、実際には常にパケットがサーバー上にありました。 ウラジオストクで95パーセンタイルが3秒である場合、この間ずっとパッケージはサーバーを離れません。 これは逆説的な答えです。 次に、それがどこから来たのかを説明します。



この質問に対する答えを得るには、TCPの仕組みを知る必要があります。 TCPについては、多くの本が直接書かれています。 別のプレゼンテーションでもTCPについて話すことができますが、1つのスライドで説明するようにします。 それは非常に原始的であることが判明しますが。







理解する必要がある3つのTCPの概念がここに記述されています。

• 最初は、いわゆる 往復時間-これは、パケットが目的のサーバーに到達して戻ってくる時間です。 pingユーティリティを使用すると、そこに表示される数値が往復の時間になります。
  
  
• 次に、ACKの概念があります-これは配信の確認です。 データのパケットをユーザーに投げると、パケットは「おい、データを受け取った」というユーザーから来ます。このパケットにより、パケットとackの時間差を半分に分割するため、データがいつ到着したかを理解できます。ユーザーで。 1つのack ackで複数のパッケージが使用されるため、ackがすべてのパッケージに届くわけではないことに注意してください。
  
  
• 3番目の概念はcwndと呼ばれます-これはいわゆる 輻輳ウィンドウ。 これは何ですか これは特定の数です。つまり、確認なしで送信できるパケットの数、つまり いくつかのパケットを送信し、到着するまで確認を待ちます。
  
  

配信の速度を決定するもの。 ルールは非常に単純です。すべてのCWNDパケットに対して、rtt時間を必要とします。 つまり インターネットでは、一般的なパケットサイズは1450バイトまたは1410です。cwnd= 10、rtt = 100の場合、1秒あたり145 KBのストリーム速度になります。 cwnd = 100、rtt = 50の場合、速度は毎秒約3メートルになります。 また、cwndはハードコーディングされたパラメーターではなく、TCPチャネルの速度を制御するパラメーターです。 実際に適用できるポリシーはたくさんありますが、ルールは非常に単純です。cwndはこれまでのところゆっくりと成長してきました。 パケットが移動し、チャネルで何か悪いことが起こったとき、パケットが失われたとき、ひどく落ちます。 適用できる一般的なポリシー-各ackに対して1つずつ増加し、パケットが失われると半分になります。 これは最も古いもので、今ではあらゆる種類の新しい政治家、よりファッショナブルなものなどです。







では、TCPについて何を知っていますか？ 一般に、これは70年目に作られた最新のプロトコルで、現在は少し時代遅れです。 , , 70- . , - TP-, , -, .



, , .. , wi-fi, , . assumption , , : congestion. これは何ですか , , , , — 100- 100- , , , , . TCP , , , , , . , . なんで？ , , , wi-fi, wi-fi , , .



, wi-fi. , - , . wi-fi :







, wi-fi , . Wi-fi , , .. , wi-fi , . wi-fi 12.5 , - wi-fi , .. 12.5 , 12.5 , .. , . , . wi-fi , . TCP, wi-fi , , , .







— wi-fi vs TCP. , - 2000 rtt=100. 2000 , . , - , . wi-fi , 20 . , 20 . つまり 5% wi-fi — , wi-fi. , , , 80% - . , TCP-, : rtt=100 5%. , . , , .



どうする？ — .







-, , , -, , - . , - , .. , . - .







, CDN, , CDN - , , , - . , . , CDN , - , loop, TCP- 5% rtt=100. TCP-, 0% rtt=90, - , 0% KeepAlive-, CWND - , . CDN- 5% , , , rtt 10 .







TCP. , Initial CWND, CWND, TCP-. Initial CWND=10. «10» , , - .



. RFC, , 1 2. - RFC, , 2 4. Google , 10. , , 10 — , , ? 10 , , 3-4 rtt, 10 14 . , 3, 4 rtt, . , , .. , .



.







, . , initial cwnd=20. , sysctl unix'. ? 4 . — , . tcpdump. つまり , , , 2/3. — ack , . tcpdump , , . つまり sysctl . , TCP .



, , , , , — , . , .



:







? . , TCP. , CWND . つまり , 60 — 40 , . , , 1 . 40 . , , , , 70%. - — , , , , . , - , , selective ack (, « , 3, 10, 17- », 3, 10, 17- ). T.O. : 1-2 rtt. つまり , 3 . , TCP , .



, , TCP - , , . つまり user agent , mobile safari -, , - , .



, QUIC. , UD-based. , , TCP, UDP. — , user space. user agent .. , QUIC, , , . なんで？ , , , .



. , : CDN, , — , . 1 . , , , , , congestion' , , CDN , , CWND , . CDN - .



.







, 3 , , , - , , - .



, - . , , , , QUIC .



— , , , . Tools' , Timing API , tcpdump, , . .

連絡先

» anatolix@yandex.ru

» den@yandex-team.ru

»

私たちはこれらのレポートを何よりも気に入っています-有用であり、リスナー（そして今は読者）を多くの時間を節約できる実際の研究。



このレポートは、高負荷システムHighLoad ++の開発者の会議で行われた最高のスピーチの1つの転写です。



また、これらの資料の一部は、高負荷システムHighLoadの開発に関するオンライントレーニングコースで使用されますガイドは、特別に選択された文字、記事、資料、ビデオのチェーンです。 私たちの教科書にはすでに30以上のユニークな資料があります。 接続してください！



さて、主なニュースは、HighLoad ++ Juniorを含む8つのカンファレンスを含む春祭り「Russian Internet Technologies」の準備を開始したことです。ジュニアは子供向けではありません！Juniorは、コンサルタントに何百ものサーバー、megarasharedデータベース、Igor Sysoevを持たずに、高負荷で作業する方法についてです。現実の状況でのハイロード