TCP BBR：ページの読み込みを高速化するための高速で簡単な方法。Yandexレポート

最新のアプリケーション層プロトコルは、多重化を使用してデータ送信を高速化し、チャネルの信頼性に対する要件を高めています。YaTalksカンファレンスでAlexanderGryanko phasma例としてHTTP / 2およびTCPBBRプロトコルを使用して、パケット損失の多いチャネルでのページの読み込みを高速化する方法を説明しました。



- こんにちは。私はサーシャです。Yandexで働いています。過去3年間、L7ロードバランサーを開発してきました。ネットワークを高速化するためのすばやく簡単な方法について説明します。第7レベルのHTTPから始めて、第4レベルのTCPに移ります。今日は、これら2つのレベルについてのみ説明し、それらについて詳しく説明します。



過去8年間、私はより多くのバックエンド開発を行ってきましたが、おそらく私の知識は最初のバージョンではAngularJSのレベルのままでした。あなたはおそらくそれがすべてどのように機能するかを私よりよく知っています。あなたはすでにすべてを最適化し、すべてを圧縮しました、そしてここで私はあなたに何もアドバイスすることができません。



ただし、サーバー自体、つまりオペレーティングシステム自体を最適化して、ネットワークを高速化する方法についてアドバイスすることはできます。







何かをスピードアップするには、メトリックが必要です。この場合、次のものを使用しました。最初のバイトまでの平均時間はTCPレイヤーの速度を示し、2番目のメトリックは最初のバイトからHTMLを受信する時間です。メトリックを実験して測定し、BBRをオンにした後、スピードアップは約10％でした。







10パーセントが何であるかを理解するために、66ミリ秒である絶対値に目を向けます。お気に入りのオンラインマルチプレイヤーゲームにアクセスすると、西ヨーロッパのサーバーへのPingは約60〜70ミリ秒になります。

すばやく行う方法

すべてのサーバーは、リモート制御プロトコル（この場合はSSH）を使用して管理されます。 SSHをまだ使用していない場合は、システム管理者にサーバーの構成を依頼できます。彼にこれをするように説得する方法を教えます。







BBRとは何ですか？これは、パケットがネットワークに送られる方法を制御できるようにするアルゴリズムの1つです。また、次の2つのパラメータで構成されています。最初はパッケージスケジューラをFQに設定することです。次に、FQを使用する理由を説明します。 2つ目は、輻輳制御自体、つまりBBR自体を含めることです。



これで終わりのようです。しかし実際には、多くの落とし穴があり、おそらく、sysadminはサーバー上でBBRをオンにするだけではありません。したがって、さらに進んでいきます。

HTTP / 2と多重化

レベル7（HTTP）から始めて、徐々にプロトコルを確認していきます。







まず、毎日やり取りするブラウザから始めます。Web開発者コンソールが表示されます。コンソールには、プロトコルという興味深いフィールドがあります。



この場合、プロトコルはHTTP / 1とHTTP / 2です。GoogleのQUICプロトコルに基づくHTTP / 3プロトコルもあります。しかし、それは開発中であり、まだ完全には承認されていないため、今日はそれに戻りません。HTTP / 1に戻りましょう。







スライドには、Wiresharkユーティリティが表示されています。このユーティリティを使用すると、ネットワークとのやり取りの方法であるパケットを分析できます。 1つのフィールドが緑色で強調表示されていることがわかります。これがHTTPリクエストです。以下に、バイトと、それらがネットワーク上でどのように表示されるかを示します。







HTTP / 1は実際にはどのように見えますか？これはかなり単純なプロトコルです。これは完全にテキストベースです。つまり、テキストを書き込んでネットワークに送信するだけです。私たちのキャラクターは特別な16進値でエンコードされています。右側はASCIIテーブルで、ナビゲートできるように小さなピースです。



最初の部分はヘッダーの形式で、本体から「\ r \ n \ r \ n」の文字で区切られています。ここでは、GETメソッドを使用して通常のリソースを要求しているだけなので、この要求には本文がありません。そして、バイトはASCIIテーブルにあるものとほぼ同じであることがわかります。ある種のJS、ある種のリソースを要求しています。現在使用しているドメインを示すHostヘッダーもあります。そして-いくつかの追加のヘッダーセット。それらはカスタムにすることができ、あなたは何でも使うことができます。







HTTP / 2は、より複雑なプロトコルです。これはバイナリであり、フレームは情報交換の最小単位です。多くの特殊なケース、これらのフレームの特殊なタイプがあります。スライドで、それらが強調表示されていることがわかります。







また、最初の行で、2つのフレームが一度に1つのパケットに収まることがわかります。どのフレームが存在するかについては詳しく説明しません。かなりの数のフレームがあります。この場合、リソースを要求できるようにするだけなので、ヘッダーフレームに関心があります。私はWiresharkの開発に少し関わり、この分野での改善に貢献しました。



getリクエストがあることがわかります。中央に、このgetリクエストのテキスト表現があることがわかります。ただし、右側の列には、割り当てられたバイトが1つだけ表示され、これがこのgetメソッドになります。次に、なぜこれが起こっているのかを説明します。



次に、リソースへのパスを示すパスヘッダーがあり、JSへのパスを要求します。また、リクエストに含まれる追加のヘッダーのセットがあります。



では、なぜネットワーク上のバイトは、これがすべて私たちの絵に描かれているのと同じではないのですか？事実、Wiresharkは最終結果、つまり彼がすべてをどのようにデコードしたかを示しています。そしてネットワーク上では、これらのバイト、これらのヘッダーは、特別なHPACK形式で圧縮されます。詳細については、インターネットで確認することをお勧めします。情報を探してください、それは十分に文書化されています。



かみ傷に戻りましょう。特別なフィールドがあります-コンテンツ識別子。これらのフレームが現在使用しているリソースを示します。この場合、最初のフレームを送信し、データを受信しました。サーバーがコンテンツバイト自体を提供する場合、データフレームはすでに使用されています。







HTTP / 1プロトコルとHTTP / 2プロトコルは大きく異なります。 HTTP / 1はテキストプロトコルであり、HTTP / 2はバイナリプロトコルである、つまりフレームを使用して機能するという事実については、すでに説明しました。



単一接続の形式の要求の場合のHTTP / 1は、Webサーバーの開発者がそれを書き込んだ方法の実装に応じて、不明な結果を返します。つまり、1つの接続で2つの要求を行うと、ほとんどの場合、最初の要求または2番目の要求への応答が返されます。これを行うには、リソースを並列にロードするために、ブラウザーは複数の接続（通常は約6つ）を確立し、リソースを並列にロードします。



次に、HTTP / 2は単一の接続を使用します。つまり、接続を設定し、その内部で必要なすべてのデータをフレームを介してロードします。複数のリソースを1つの接続にパックするこの手法は、多重化と呼ばれます。



接続がどのように機能するかから明らかです。接続の1つでパケットが失われた場合、HTTP / 1の方がうまく機能します。ほとんどの場合、他の接続には触れず、同じ速度でロードし続けます。また、HTTP / 2の場合、パケットが失われると、すべてのリソースのロードが遅くなり始めます。







HTTP / 2の方が悪いようで、パケット損失にも敏感です。実際、これら6つの接続をそれぞれ作成するとき、次の操作を実行しています。



クライアントとサーバーは、信頼できる接続、つまりTCP接続を確立します。クライアントからサーバーに2つのパケットを送信し、サーバー側からクライアントに1つのパケットを送信します。したがって、データを転送する準備ができていると言えます。もちろん、これはオーバーヘッドリソースを作成しますが、これは長期間実行できます。







暗号化もあります。ここでブラウザを見ると、おそらくパドロックアイコンが表示されます。多くの人がSSLと呼んでいますが、実際にはSSLではありません。これはTLSです。 SSLは長い間時代遅れであり、実際にはサポートされていないため、廃止する必要があります。



TLSにはパケット交換もあります。つまり、TCPハンドシェイクの場合と同様に、特定の状態を設定した後、作業を​​続行できます。この時点で、最適化を行うこともできますが、ブラウザーは、サーバー側から既に有効にしている機能をまだサポートしていません。皆がそれをオンにするのを待ちます。







昔々、HTTP / 1はリソースの同時ロードの問題を解決しようとしました。 RFCにはそれがあります。そして昔々、パイプライニングが実装されていました。実装が複雑なため、Internet Explorerはサポートしていませんが、FirefoxとChromeはサポートしていますが、サポートは時間の経過とともに廃止されています。







すでに作成した6つの接続のそれぞれは、実際には閉じません。つまり、以前と同じように機能し続けます。これには、Keep-Aliveなどの手法が使用されます。つまり、特定のサーバーへの信頼できる接続を作成し、作業を継続します。



HTTPレベルでは、これはヘッダーによって制御されます。この場合は接続です。そしてTCPレベルでは、すでにオペレーティングシステム自体を使用し、何をすべきかを決定します。







HTTP / 2には他にも問題があります。HTTP / 2では、パケットに優先順位を付けて、より多くの必要なデータをより速く送信できます。この場合、一度に大量のデータを送信しようとすると、サーバー上のバッファーがオーバーフローする可能性があります。次に、優先度の高いパケットは単に速度が低下し、キューの最後に移動します。



パケット損失が観察されます。それらはロードを遅くし、このブロッキングはヘッドオブラインブロッキングと呼ばれます。

TCPがパケット損失の問題を解決する方法

次に、TCP、つまり4番目のレイヤーについて説明します。次の10分間で、TCPがどのように機能するかについて説明します。







私たちが訪問するとき、私たちは誰かに塩を渡すように頼みます。人が私たちに塩を与えるとき、私たちは塩が私たちに届いたことを確認します。この場合も、セグメントを取得して送信し、確認を待ちます。また送信します。また、損失が発生した場合は、このセグメントを転送し、結果として配信されます。 1つのセグメントを送信するこの手法は、停止と待機と呼ばれます。



しかし、私たちのネットワークは過去30年間で途方もなく加速しています。おそらくあなた方の何人かは、メガバイト単位のダイヤルアップ、インターネットを覚えています。今では、すでに自宅でギガビットインターネットに接続できる可能性があります。



また、この場合、一度に複数のパッケージの送信を開始できます。この例では、3つあります。ウィンドウを3つのパッケージの形式で送信し、すべてが確認されるのを待ちます。



パケットが失われた場合、最初の損失からすべてのパケットの再転送を開始できます。この手法はGo-BackNと呼ばれます。それ以外の場合は、すべてのパケットの追跡を開始し、失われたパケットのみを転送できます。この手法は、セレクティブリピートと呼ばれます。サーバー側ではより高価です。スライドを準備していたとき、それをどのように提示するかを理解するのに長い時間がかかりました。私自身も戸惑いましたので、そのようなアナロジーを思いつきました。







水が流れるパイプは私たち全員に知られています。パイプの直径は異なり、どこかで細くすることができます。この場合、最も狭いポイントは最大スループットになります。このボトルネックが許す以上の水を注ぐことはできません。



左から右にボールを撃ちます。右側では、ボールが飛んでいることが確認できます。私たちはボールの流れを送り始めています。そのカットを見てみましょう。これでボールは一方向に飛んで確認され、ボールの数は指数関数的に増加します。ある時点で、ボールのボリュームが非常に大きくなり、速度が低下して失われ始めます。負けた後、少し減速し、ウィンドウを半分に減らします。次に、私たちは自分たちに何が起こったのかを理解しようとします。最初の段階はTCPスロースタートと呼ばれます。







ウィンドウを2回閉じたら、接続を復元して、ボールをもう一度送ってもらうように頼むことができます。彼らは私たちがボールを送る必要があると私たちに叫びます、私たちは彼らに答えます-ここにあなたのボールがあります。このフェーズは、高速リカバリおよび高速再送信と呼ばれます。







すべてが順調であることに気付いたとき、私たちはその折りたたまれた窓から始めて、送られるボールの数を徐々に増やし始めます。このフェーズは、輻輳回避と呼ばれます。つまり、パケットの損失を回避しようとしています。



ウィンドウが2回折りたたまれる段階は、乗法減少と呼ばれます。そして、ボールの数を増やす遅い段階は、加法的な増加と呼ばれます。



輻輳回避で再びパケットが失われた場合、次の手順を実行できます。しかし、現時点では、このグラフのイメージそのものに関心があります。私たちはそのようなのこぎりを見ます、そしてこののこぎりは私たちに数回役立つでしょう。それがどのように見えるかを覚えておいてください。







従来のTCPプロトコルの問題に戻ります。パイプと同様に、バッグを注ぎます。私たち以外にもインターネット上に他のユーザーがいるので、彼らもパッケージをパイプに注ぎ始めます。ある時点で、ルーターのバッファーがオーバーフローし、パケットの送信に問題が発生する可能性があります。



ワイヤレスネットワークでのパケット損失にも問題があります。ほとんどの場合、ラップトップにはイーサネットポートがなく、Wi-Fiを介してトークを見ています。Wi-Fiおよびモバイルネットワークでのパケット損失は、ルーター自体ではなく、無線干渉が原因で発生します。このようなメトリックは、私たちにとってあまり役に立ちません。

TCPBBRと他のアルゴリズムの違い

ここでBBRに行きます。これは、ボトルネック帯域幅とラウンドトリップ時間の略で、チャネルを完全に詰まらせていないときの帯域幅と、パケットがサーバーに戻ってくるまでの移動時間の指標です。



データを送信するとき、パケットが安定した状態で飛行し、まだ確認されていない理想的な状態は、帯域幅遅延積と呼ばれます。ネットワークデバイスのバッファを使用することで、BDPを増やすことができます。このバッファーを超えると、損失が始まります。



そして、通常のTCPアルゴリズムは、グラフの右側、つまり損失が発生する場所で機能します。損失が避けられないほど多くのパケットを注ぎます。パケットの速度が低下し、ウィンドウが折りたたまれ始めます。



次に、BBRは、パイプの近くで別の原理で動作します。スキップできる限り多くのバッグを注ぐだけです。開始フェーズ、つまり最初の段階では、混雑が始まるまでバッグを満たします。



また、パケットが失われる可能性もあります。しかし、BBRはこの瞬間を避けようとしています。パイプがいっぱいになると、ロールバックを開始します。このフェーズはドレインと呼ばれます。







安定した接続に戻り、完全に満たされますが、同時に、追加のバッファーや追加のリザーバーは使用しません。この位置から、BBRは動作を継続します。



時々、ネットワークで何が起こっているかを見ていきます。返送されたほぼすべてのパッケージを追跡します。パケットが戻ってきたら、パケットの数を少し増やし、パケット自体をスピードアップして、ネットワークに送信しようとします。







そして、問題がなければ、この値を維持できます。つまり、私たちにとって快適なペースで働き続けることです。ただし、損失が発生した場合は、ロールバックできます。



確認を受け取ったところ、速度が向上したので、少し待って、10秒間隔を見てみましょう。そして、この間隔の間にパケットの送信速度が向上し、パケットの確認が速くなった場合は、プローブRTTフェーズに入り、すべてが改善されたかどうかを確認できます。







このようなフェーズは交互に行われます。つまり、ネットワークで何が行われているかを常にチェックします。



BBRアルゴリズムは、パケット損失ではなく、チャネル幅とパケット移動時間に基づいています。







実際、パケット損失の影響を受けません。彼は実際にはそれらに反応しません、そしてこれのために私達はいくつかの問題を抱えています。 Googleは、これらの問題がBBRv2で修正されることを約束しました。



私達は私達の段階を調べました、そして私達の前に私がすでに示した櫛が再びあります。通常のTCPプロトコルは赤で強調表示されています。それで彼は拾い上げ、拾い上げ、減速し、そして再び荷物を失います。そして、BBRは彼が必要とするペースを設定し、それを常に使用して、ネットワークが少し良くなったかどうかを常にチェックします。そしてそれは加速しているかもしれません。



メトリックは常に更新され、クライアントからのすべての確認を追跡し、ネットワークが加速しているかどうかを確認します。



このパケット送信速度はどのように制御されていますか？ペーシング手法を使用して送信のペースを制御します。これは、前述のスケジューラーに実装されています。これはFQスケジューラです。カーネル自体にも実装されていますが、これについては後で説明します。



パイプのように、より多くのデータを注ぐと同時に、速度を落とさず、パッケージを失わないようにしています。しかし、BBRはそれほど単純ではありません。ほとんどの場合、コンテナに住んでいるか、データベース用に複数のサーバーを使用しています。おそらく写真用です。







そして、これらすべてのサーバーは相互に作用します。 BBRではなく、通常のTCPが有効になっています。そして、すでに見たのこぎりを持っているとき、ウィンドウが崩壊し始めると、おそらくBBRはウィンドウが崩壊していることを把握し始め、パケットの送信速度を上げます。したがって、それは私たちのネットワークから通常のTCPを追い出し、支配します。



ネットワークが非常に悪い場合、他の問題が発生する可能性があります。通常のTCPはまったく機能せず、BBRは実質的にパケット損失の影響を受けないため、一定の速度で機能し続けます。



TCP_CONGESTIONオプションを使用すると、データセンターでこの問題を解決できます。すべてのソケット、すべての接続に対して公開されます。さて、私が知る限り、このオプションはほとんどすべてのWebサーバーに実装されていません。そして私たちのL7バランサーはそれをサポートしています。しかし、ペースに戻ります。古いカーネルを使用している場合は、バージョン4.20より前のカーネルのペーシング実装にバグがありました。この場合、FQスケジューラーを使用する価値があります。







TCPがどのように機能するかがわかったので、システム管理者に連絡して、BBRを有効にする必要がある理由を伝えることができます。



10パーセントに戻りましょう。彼らはどこから来ることができますか？現在、オペレーターネットワークは非常に大規模です。それはすべてお金に帰着し​​ます。たとえば、100、200テラビットのチャネルを構築し、大量の4Kビデオをスキップできます。ただし、クライアントは引き続きエンドポイントにあります。



そして、おそらく、クライアントへのこの最後の1マイルが問題の原因になります。すべてのWi-FiとLTEはパッケージを失います。通常のTCPを使用している場合、速度が低下します。BBRはこの問題を解決します。私が示した2つのコマンドだけでそれを有効にすることができます。ありがとうございます。