コミュニケーションチャンネルを利用して拡大することはできません

このグラフは、TCPを使用する場合のネットワーク遅延が最大速度にどのように影響するかを示しています。 簡単に言えば、500ミリ秒のpingがあり、6、10、100、500などの使用可能な帯域幅がある場合、2つのホスト間のメガビットトラフィックは1メガビットを超えて加速しません。









私のチームはコミュニケーションチャネルを最適化しています。 数回クリックするだけですべてを手動で修正できる場合もありますが、交換を大幅に圧縮し、プロトコルをより「楽観的」または「予測的な」ものに変える特別なデバイスをインストールする必要があります。



楽観的プロトコルとは何ですか？ 非常に大雑把に-これは、次のフレームを送信することが可能であるとリモートサーバーがまだ応答しておらず、成功の可能性が97％であることを知っているため、鉄片はすでに「送信」と言っています。 突然何かがおかしくなった場合、彼女自身が送信サーバーを邪魔することなく必要なパッケージを送信します。

ウィンドウと遅延

RWIN（https://en.wikipedia.org/wiki/TCP_tuning）のようなものがあります。 これはウィンドウのサイズです。

以前は、トランジスタが大きい場合（これは2004-2005）、制限は64Kでした。 したがって、速度、遅延、およびアプリケーションは異なっていました。 そして、この段階では問題はありませんでした。 ネットワークが高速になり、アプリが大食いになると（トラフィックが増えたという意味で）表示され始めました。 企業は、すべてを迅速に機能させるために帯域を拡張する必要があります。 ただし、すべてが特定のポイントまでしかうまく機能しなかったため、下のグラフで確認できます。 さらに、企業ネットワークの最新のオペレーティングシステムは、自動モードでユーザーに透過的ないわゆる「天井」問題に対処することを学びました。 しかし、古いOSだけでなく、さまざまなOSやスタックの動物園全体があります...



最初、TCP受信ウィンドウは64K（WinXP時間）に制限されています。 最新バージョンのプロトコルでは、大きなフレームサイズもサポートされています（これは多くの場合必要です）が、交換は小さなものから始まります。







「TCPソー」のようなものがあります。 これは、次のことを意味します。複数のフレームが送信されるたびにTCPでデータを交換する場合、送信側は一度に送信される数を増やします。 図は、特定のポイントまでこの数を増やすことができることを示していますが、一度上限に達して損失が始まります。



損失が発生すると、RWINは自動的に半分になります。 そのため、ユーザーがファイルをダウンロードした場合、オーバークロックしているように見えますが、その後クラッシュします。 この動作は多くの人に馴染みがあるはずです。



ウィンドウサイズを変更することで、古いルーターと多数のワイヤレスの希望を持つネットワークに対して非常に良い効果を達成できます：最大の非スケールRWIN（最大65535バイト）を取得し、最小スケールファクター（RFC 1323、スケールファクター）を使用する必要があります。 新しいウィンドウは独自にフレームサイズを選択し、適切に実行します。



これまでのところ、すべてが単純です。非常に単純化して、64Kを送信し、応答を待ってから64Kを送信します。 半惑星と静止軌道を介した石油生産施設から答えが得られる場合は、有効速度がどの程度になるかを推測してください。 実際、すべてはもう少し複雑ですが、問題は同じです。 したがって、より多くのパッケージが必要です。



RWINでの作業は、衛星チャンネルで今できる最も簡単なことです（1つの設定で多くの問題が解決します）。 例：パケットが衛星に飛んでから地球に戻った場合、サーバーが応答するのを待ってから、衛星に飛んで戻ってきます。 静止衛星とそれに対して正常な受信局の場合、これは500ミリ秒の遅延を意味します。 ジャンプが長い場合（ステーションが三角形を形成する場合）、数秒を得ることができます。 私の練習では、リピーターが衛星を介して再び情報を送信する場合があります（すでに別の1つは、出発点で惑星を越えて最初のテレポートを見ていません）-そこで3-4秒をキャッチできますが、これは別のタイプの通信地獄です。







今から楽しい部分です。 ウィンドウフレームを使用するプロトコルの場合、最大帯域幅はチャネル幅と遅延によって決まります。 したがって、最適なパケットサイズ（または中間最適化を使用する場合は1フレームのパッケージアセンブリ）は、その能力を最大化するために、チャネルが広くなるほど大きくなります。 アプリケーションの値はより単純です。RWIN/ BDP（帯域幅遅延積）の比率-伝送遅延の不可欠な指標を知る必要があります。 ここでは、スケーリングされていない64kパッケージに対して計算できます。



次の論理的なステップは、最適なTCP受信ウィンドウを決定することです 。これがテストです 。



最大セグメントサイズ（MSS）を決定し、後で交換設定で設定すると、プロセスが大幅に高速化されます。 より正確に言えば、遅延によって理論上の最大値に達します。 Win7および2008 Serverは次のことを実行できます。非常に小さなウィンドウ（約17520バイト）から開始し、ノード間のインフラストラクチャが許可する場合は自動的に増加します。 次に、RWIN自動チューニングがオンになりますが、かなり制限されています。 Win10では、自動調整の境界がわずかに広がりました。



RWINを手動で制御できます。これにより、低速ネットワークで違いが生じる可能性があります。 少なくとも数回、お客様が高価な機器を購入するのを防ぎました。 複製ウィンドウが24時間で、わずか26時間である場合、チャネルを調整し、異なるノードの独自の圧縮を調整すると、18〜19に低下する可能性が十分にあります。 オプティマイザーを使用すると、おしゃべりなやり取りで最大6〜7が可能ですが、タスクが既に解決されている場合もあります。 または、数年遅れました。



オプティマイザー（以降、Riverbed Steelheadファミリーについて説明します-数百の異なる鉱床に既にインストールしているため、練習に依存します）-したがって、TCPをトランスポートに変換することにより、フレームプロトコルの固有の欠点を「取り除く」ことができますプロトコル。 交換がRiverbedの2つのノード間で行われる場合、変換は次のようになります。







次に、これらのかわいいデバイスがどのように最適化レベルを高くして動作するかを見てみましょう。 Steelheadには通常、データの合理化（重複排除）、トランスポートの合理化（上記のトランスポートの最適化）、およびアプリケーションの合理化（これは低い）の3つの最適化手法があります。



HTTPは、サイトを操作するための古き良きプロトコルです。 古いものは正しい言葉ではなく、そこに最適化するものがあります。 たとえば、ロードする他のオブジェクトが明確になったときに、追加の接続を開きます。 最新のブラウザは、すぐにこれを実行できます。







彼は非常に退屈な認証を持っています：







楽観的なケースでは、最大2つのパケットを圧縮できます。送信ノードにこれを一度に要求し、それを受信ノードのRiverbedに渡すだけで、彼はすでにだれとでも「話す」ことができます。 企業ポータルには非常に便利です。



いくつかの接続が開いていると、接続の1つが401を返し、ハンドシェイク要求の一部がすでに認証済みの最初の要求に該当する場合、いわゆる接続ジャンプによる再認証の問題があります。



最適化の主な種類は次のとおりです。

1. 送信ノードと受信ノードの圧縮、およびパケット内のパケットのアセンブリを無効にします。 個々のパケットの圧縮を無効にすると、複数の繰り返しパケットを完全に重複排除できます。 実際、これは、一度送信されたパケットについて、次に送信されたパケットと同様に、最も近い類似の番号と差のみを送信できることを意味します。 これは、2つの圧縮パッケージよりもかなり少ないです。
2. Cookieを挿入します。 一部のサーバーでは、特定の技術データのストレージが必要です。これは、すべてのユーザーでほぼ同じであり、ほとんど変更されません。 それらはキャッシュに入れることができます。 さらに、サイトがCookieをサポートしていない場合、トラフィックオプティマイザーでこのサポートを有効にできます。
3. 接続のサポート-すべてが簡単です。セッションを解放しない場合、再度ログインする必要はありません。
4. URLトレーニング。 ユーザーは同じトラックをたどるので、オプティマイザーはオフィスの習慣をすばやく学習し、一部をキャッシュしたり、一部を事前リクエストにすばやくアクセスしたりできます。
5. クエリ予測 たとえば、imgタグのあるページがSteelheadを通過する場合、数ミリ秒後に受信サーバーが画像自体を要求すると想定するのが論理的です。 川底は楽観的なアプローチをとり、これを期待していませんが、ただすぐに尋ねます。 サーバーがリクエストを送信すると、Riverbedはリクエストをインターセプトし、すでに受信したものを返します。
6. プリフェッチは、オープン可能なセッションにも適しています。
7. 可能であればNTLMを強制します（これは高速です）。
8. 余分なヘッダーを取り除くための標準的な方法。
9. 「Gratuitos 401」-ブラウザは追加のGETを頻繁に実行しますが、これは回避できます。

非標準ポートを含むHTTPSおよびSSLアプリケーションを最適化することができます。 私たちの実践では、これは複数回発生しています。 Steelheadソフトウェアの最新バージョンでは、ユーザーが常に安全なポータルにアクセスする場合（すべてのインターネットトラフィックを最適化することは実用的ではありません）、インターネットへのアクセスにプロキシサーバーを使用する場合など、インターネットトラフィックを最適化できます。



Office365の最適化があります。 企業プロキシを使用することもできます。







CIFS / SMBは、ネットワークノード間でファイルを交換するための1990年のプロトコルです。 ネットワーク印刷にも使用されます。 Riverbedは、標準のTCPポート（445および139）の両方でリッスンします。 正確な最適化方法は開示されていませんが、パッケージをチャネルに最適なものに組み立てること、高速ノードでの過度のロック、頻繁に発生するセッションの維持（実際の必要性までそれらを開いたままにする）、保護の一部をノードの独自の負荷ではなくSteelheadデバイスのペアに転送することについて話します。 SMB 3.1.1用のWin10およびServer16には事前認証の整合性メカニズムがあります。その類似物の一部は、Steelheadプロトコルの古いバージョンに実装されています。 他のファイルプロトコルにも同様の方法が使用されます。 デバイスは、Signed-SMBを含む3.1.1までのSMBのすべてのバージョンをサポートします。







ここでは、圧縮がどのように発生し、TCPペイロードが増加するかを説明します。 ファイル転送に非常に関連します。



MAPI （HTTP、署名付きMAPI、およびOffice365経由）-OutlookクライアントとExchangeサーバー間のメール交換。 彼はかなり長いハンドシェイク手順を持っています：







このセッションを開いたままにして（インターセプトをリバーブし、96時間保持する）、確認の効率的な交換、メールと添付ファイルのストリーム読み取り（実際には、クライアントが実際にまだ受信し始めていないもののキャッシング）によって最適化が達成されます。







トラフィック自体は十分に圧縮/重複排除され、冗長性がなくなります。







クラスタのインストールでは、ポートの事前定義方法も非常に役立ちます。

休日に人事スペシャリストが非常に遠い銀行事務所のネットワーク全体を削除した場合がありました。 調査の結果、年配の同僚が10メガバイト未満のBMPはがきを郵送したことが明らかになりました。 Steelheadは、従業員が午前10時にメールを開き、夜にメールを収集し始めたことを「認識」しました。 そして同時に、これらのいまいましいポストカードを圧縮し、実際に10文字から1文字への重複排除と、この標準サンプルの圧縮を提供します。 以前は、すべてが「通り抜ける」ように、人々は10時に来て、10時30分に働き始めました。 現在、悲しみの理由はありません。仕事の開始は厳密に予定通りです。



銀行は多くの遠隔教育システムを使用しています。これは従業員にとって非常に便利です。 リモートブランチでは、ほとんどのバンドがトレーニングビデオで詰まっています。 httpストリームのある川底では、写真のようなことができます。 結果として、チャネルはそのようなトラフィックに「苦しむ」ことはありません。 しかし、これは予測メカニズムであり、リアルタイムビデオ（ビデオ会議など）であり、優先順位付けのみが可能です。





RTP / RSTPではなく、HTTPストリームに関するものです

他のプロトコルでも同様の方法が使用されます。

次のメカニズムは事前入力です。 事前に知っている場合-オフィスがあり、ネットワークドライブがありますが、マーケティングは独自のフォルダで動作し、ネットワークの最適化と制御は独自で動作します。 特定の部門が特定のネットワークフォルダーを使用するブランチにいることもわかっている場合は、Riverbedに自分でアクセスするように指示できます（これらのパスを表示します）。 彼は、どのような種類のファイルが存在するか、どのくらい早く要求されるかを理解します。 したがって、多くのセッションは開かれず、Riverbed自身がクライアントになりすましてネットワークボールを降り、そこにあるすべてのものを収集し、最も頻繁に使用されるコンテンツを引き継ぎます。 合計：翌日、従業員はオフィスに来て、彼はすでに反対側へのアクセスを遅滞なく使用できます。 したがって、更新された情報を受け取ります。



他のプロトコルは、低レベルのプロトコル最適化スキームに従って分類されます（ほとんどの場合、フレームサイズとチャネルの最適なパケットライフタイムの設定について話します）-チャネルが大きなフレームを必要とし、プロトコルを小さく送信したい場合でも、Steelheadsはそれをすべて独自の形式に並べ替え、重複排除します必要に応じて送信します。 次に、フローは重複排除、圧縮、キャッシュ、予測されます。 「チャット」シーケンスが識別され、楽観的な応答に変換されます。



接続プーリングもあります-Steelheadは、現在のニーズのために20の追加セッションを開いたままにします。 これは衛星にとって非常に重要です。

別の練習

64Kの標準ウィンドウで作業する人はまだ多くいます-これは交換に大きな影響を与えます。 たとえば、ハバロフスクとモスクワのデータセンター間で、80ミリ秒の遅延で100 Mbpsのチャネルを使用する場合、標準的な手段の複製速度は5メガビット/秒です。 サプライズ！ ウィンドウのサイズを変更してから、残りを実行する必要があります。 繰り返しますが、同じOffice365には、アムステルダムとダブリンに最も近いAzureデータセンターがあります。 上記のリンクのルーラーと計算機を使用して、遅延を推定できます。 同じハバロフスクからのより多くのトラフィックがモスクワを通過します（ただし、アジアのAzureデータセンターを経由します）。



そして、まだ損失があります。 衛星上では-天気の5％が簡単です。 一部のパッケージは霧の中で立ち往生し、一部は雪片を通過しません。また、大きくて厚いパッケージは鳩に情報を与えることができます。 または、トランスポンダーから映画をつつくために到着したカラス（幸いなことに、彼らは大きなテレポーターでミラーを素早く沸騰させて滑り落ちます）。 ところで、SCPSサポートが役立ちます。





フレームサイズの操作に加えて、Riverbed SteelHeadは最適な輻輳回避メカニズムも使用できます。 NewRenoから特定のMX-TCPおよびHSTCPへ。 後者は、高BDPの問題とTCPスロースタートの問題を回避するのに役立ちます。つまり、チャネル幅を知っていれば、特定のトラフィックに帯域全体を一度に与えることができます。



新しいソフトウェアのリリースに伴い、新しい機能が登場します。 バージョン9.0以降、本格的なDPIが登場し、トラフィックはアプリケーションごとに分類できます。 トラフィックの優先順位付けと分析のためのSteelheadの組み込み機能は、ネットワークポリシーの設定に依然として適しています。 たとえば、石油リグでは次のメカニズムがよく使用されます：最初に技術的なトラフィック、次にビデオ会議、ビデオ会議マニュアル、次にオフィス、次に従業員の個人的なトラフィック。 現在、掘削機のボブは、猫と一緒に新しい20メガバイトのgifをダウンロードしても、管理へのトラフィックを中断しません。



または、レンズクの近くに物体がありました。 非常によく訓練された管理者がいます。彼らはチャンネルからできる限りのことを絞り出しました。 私たちは過去の投稿を読んで、テスト用の鉄を求めました。 主な問題は、最速のRDPのような接続ではなく、人々が激怒しています。 そして、これがビジネスアプリケーションにアクセスする主な方法です。 チャネルの高負荷（および非対称）の間、ビジネスアプリケーションのユーザーはRDP経由のアクセスで問題を経験し始めました。 既に持っていた最適化は衛星モデムに組み込まれていましたが、トランスポートレベルでのみであったため、別のソリューションを探していました。 私たちは川を置きました-髪は柔らかくて絹のようになり、負荷は3回落ちました。 その後、衛星モデムの松葉杖に出くわしました-組み込みの最適化をデフォルトでオフにすると、致命的に短いTCPキューの長さが設定されました。 これはリバーベッドに大きな損害を与えました。 最適なパラメーターも選択しました。 その結果、RPDのような動作が安定し、ファイルのスイングが速くなります。人々は24時間体制でシフトして何かをします。 状況はドリラーVasyaの状況と同じです。彼は猫で20 mbのgifをより速く送り出し、誰にも害を与えず、誰もが幸せです。

別の例を示します。 外洋には大型船があります-トロール船の工場。 そしてそこに

獲れたての魚はすぐに缶詰になります。 生産はそこでのネットワークを通じて制御され、プロセスの一部として、データが交換されます。



しかし、単に2回の衛星ジャンプまたは不快な遷移「衛星-2G-光学系」。 彼らはオプティマイザーを与えられました-すべてそこに幸福が来ました。 また、ビジネスプロセスの監視という点で会社、そして労働条件の改善という点で従業員は、家族とコミュニケーションを取り、写真やビデオを共有する機会があるためです。

実際に適用される場所

Steelheadsのセットは、主に次の場合に使用されます。

1. 技術的にチャネルの帯域幅を増やすことができない場合。
2. ワイドチャネルで非常に高い遅延がある場合（たとえば、衛星の場合）。
3. LFN（たとえば、2つのデータセンターまたはモスクワ-キプロスなどの地理的に離れたオフィス間のパイプなどの長い太いネットワーク）。

実際、はるかに多くのシナリオがありますが、ほとんどの場合、それらのすべては1つの問題、つまりビジネスアプリケーションを使用するユーザーの遅い作業から生まれます。 最も一般的なものをリストしました。



Magic Riverbedは、3Gチャンネル、衛星チャンネル、3Gラジオリレーの希望、デュアルサテライトジャンプ、2G-4Gの希望、および10Gワイドチャンネルで2〜5ミリ秒の遅延で作業を開始します。 何よりも、ロシアでは衛星チャンネルを使用すると効果があります。衛星チャンネルは物理的に広くはできませんが、必要です。



以前のチャンネルには非現実的なお金がかかりましたが、今では国のほとんどの地域で安くなっています。 ほとんどの場合、主に銀行と鉱業部門から連絡があります。



多くの人にとって、これは、通信チャネルの拡大が作業の効率を高めることはなく、遅延がチャネルの帯域幅に影響を与え、チャネルを無期限に拡大できないという啓示です。 多くの場合、レプリケーションの速度が遅い、アプリケーションの速度が遅いなどの問題に直面すると、チャネルが拡大し始めます。 そしてほとんどの場合、助けにはなりません。 ここで、実際に、これについて私が伝えたかったのです。 それがうまくいったことを願っています。