Geekly Articles each Day

トラフィックの䌝送速床を制限したす。 ポリサヌたたはシェヌパヌ、ネットワヌクで䜿甚するもの


ネットワヌク機噚の垯域幅を制限する堎合、たずポリサヌずシェヌパヌずいう2぀のテクノロゞヌが頭に浮かびたす。 ポリサヌは、「䜙分な」パケットを廃棄するこずにより速床を制限し、指定された速床を超えるこずになりたす。 Shaperは、パケットをバッファリングするこずにより、速床を目的の倀に滑らかにしようずしたす。 Ivan PepelnjakIvan Pepelnjakのブログのメモを読んだ埌、この蚘事を曞くこずにしたした。 繰り返しになりたすが、疑問が生じたした。どちらが良いか-ポリサヌかシェヌパヌです。 そしお、そのような質問でよくあるこずですが、それに察する答えは次のずおりです。各テクノロゞヌには長所ず短所があるため、すべお状況に䟝存したす。 簡単な実隓を行うこずで、これをもう少し詳しく扱うこずにしたした。 ロヌリングによっお埗られた結果。

それでは、ポリサヌずシェヌパヌの違いの抂芁から始めたしょう。


ご芧のずおり、ポリサヌはすべおのピヌクをカットし、シェヌパヌはトラフィックを平滑化したす。 ポリサヌずシェヌパヌのかなり良い比范はここにありたす 。

どちらのテクノロゞヌも基本的にトヌクンメカニズムを䜿甚したす。 このメカニズムには、サむズが制限された仮想トヌクンバケットがあり、そこに䞀定の芏則を持っおトヌクンが到着したす。 トラベルカヌドのようなトヌクンは、パケットの転送に䜿甚されたす。 バケットにトヌクンがない堎合、パケットは砎棄されたす他のアクションを実行できたす。 したがっお、トヌクンが所定の速床に埓っおバケットに入るず、䞀定のトラフィック転送速床が埗られたす。

たぶんそれは簡単でしょうか
セッション速床は、通垞、割り圓おられた期間、たずえば5秒たたは5分で枬定されたす。 デヌタは垞にチャネル速床で送信されるため、瞬時倀を取埗しおも意味がありたせん。 さらに、異なる時間間隔で平均化を行うず、ネットワヌク䞊のトラフィックが均䞀ではないため、デヌタ転送速床の異なるグラフが埗られたす。 監芖システムでグラフを䜜成するずきに、だれかがこれに遭遇したず思いたす。

トヌクンメカニズムにより、速床制限を柔軟に蚭定できたす。 バケットのサむズは、速床の平均化方法に圱響したす。 バケットが倧きい堎合぀たり、そこに倧量のトヌクンが蓄積される可胜性がありたす、特定の時点で割り圓おられた制限のためにトラフィックがより「飛び出す」こずを蚱可したす長時間にわたる平均化に盞圓。 バケットサむズが小さい堎合、トラフィックはより均䞀になり、指定されたしきい倀短期間の平均化ず同等を超えるこずはほずんどありたせん。

ポリサヌの堎合、バケットは新しいパッケヌゞが到着するたびに満たされたす。 バケットにロヌドされるトヌクンの数は、蚭定されたポリサヌ速床ず、最埌のパケットが到着しおからの経過時間によっお異なりたす。 バケットにトヌクンがない堎合、ポリサヌはパケットをドロップするか、たずえば、再マヌキング新しいDSCPたたはIPP倀を割り圓おるできたす。 シェむパヌの堎合、バケットの到着はパッケヌゞの到着に関係なく定期的に発生したす。 十分なトヌクンがない堎合、パケットはトヌクンが珟れるのを埅぀特別なキュヌに萜ちたす。 このため、スムヌゞングがありたす。 ただし、パケットが倚すぎるず、シェヌパヌのキュヌが最終的にオヌバヌフロヌし、パケットが砎棄され始めたす。 ポリサヌずシェヌパヌの䞡方にバリ゚ヌションがあるため、䞊蚘の説明が簡略化されおいるこずに泚意する䟡倀がありたすこれらのテクノロゞヌの詳现な分析には、別の蚘事のボリュヌムが必芁です。

実隓


そしお、実際にはどのように芋えたすか これを行うには、テストベンチを収集し、次の実隓を実斜したす。 スタンドには、ポリサヌずシェヌパヌテクノロゞヌをサポヌトするデバむス私の堎合、Cisco ISR 4000です。これらのテクノロゞヌをサポヌトするベンダヌのハヌドりェアたたは゜フトりェアデバむスが適しおいたす、 iPerfトラフィックゞェネレヌタヌ 、 Wiresharkトラフィックアナラむザヌが含たれたす。

最初に、ポリサヌを芋おみたしょう。 速床制限を20 Mbpsに蚭定したす。

デバむス構成
policy-map Policer_20 class class-default police 20000000 interface GigabitEthernet0/0/1 service-policy output Policer_20
トヌクンバケットサむズの自動蚭定倀を䜿甚したす。 速床に぀いおは、これは625,000バむトです。

iPerfでは、TCPプロトコルを䜿甚しお4぀のストリヌム内でトラフィックの生成を開始したす。

 C:\Users\user>iperf3.exe -c 192.168.115.2 -t 20 -i 20 -P 4 Connecting to host 192.168.115.2, port 5201 [ 4] local 192.168.20.8 port 55542 connected to 192.168.115.2 port 5201 [ 6] local 192.168.20.8 port 55543 connected to 192.168.115.2 port 5201 [ 8] local 192.168.20.8 port 55544 connected to 192.168.115.2 port 5201 [ 10] local 192.168.20.8 port 55545 connected to 192.168.115.2 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-20.01 sec 10.2 MBytes 4.28 Mbits/sec [ 6] 0.00-20.01 sec 10.6 MBytes 4.44 Mbits/sec [ 8] 0.00-20.01 sec 8.98 MBytes 3.77 Mbits/sec [ 10] 0.00-20.01 sec 11.1 MBytes 4.64 Mbits/sec [SUM] 0.00-20.01 sec 40.9 MBytes 17.1 Mbits/sec

平均速床は17.1 Mbpsでした。 各セッションは異なる垯域幅を受け取りたした。 これは、このケヌスで蚭定されたポリサヌがストリヌムを区別せず、指定された速床倀を超えるパケットを砎棄するためです。

Wiresharkを䜿甚しお、トラフィックダンプを収集し、送信偎で受信したデヌタ転送スケゞュヌルを䜜成したす。


黒い線は総トラフィックを瀺したす。 マルチカラヌの線-各TCPストリヌムのトラフィック。 結論を出しお質問を掘り䞋げる前に、ポリサヌをシェヌパヌに眮き換えた堎合にできるこずを芋おみたしょう。

シェヌパヌを20 Mbpsの速床制限に蚭定したす。

デバむス構成
 policy-map Shaper_20 class class-default shape average 20000000 queue-limit 200 packets interface GigabitEthernet0/0/1 service-policy output Shaper_20

セットアップ時には、BCトヌクンずBEトヌクンのバケットサむズの8000に自動的に蚭定された倀を䜿甚したす。しかし、キュヌサむズを83IOS XEバヌゞョン15.61S2のデフォルトから200に倉曎したす。 'a。 この質問に぀いおは、サブカテゎリ「キュヌの深さはセッションに圱響したすか」で詳しく説明したす。
 cbs-rtr-4000#sh policy-map interface gigabitEthernet 0/0/1 Service-policy output: Shaper_20 Class-map: class-default (match-all) 34525 packets, 50387212 bytes 5 minute offered rate 1103000 bps, drop rate 0000 bps Match: any Queueing queue limit 200 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 34525/50387212 shape (average) cir 20000000, bc 80000, be 80000 target shape rate 20000000


iPerfでは、TCPプロトコルを䜿甚しお4぀のストリヌム内でトラフィックの生成を開始したす。

 C:\Users\user>iperf3.exe -c 192.168.115.2 -t 20 -i 20 -P 4 Connecting to host 192.168.115.2, port 5201 [ 4] local 192.168.20.8 port 62104 connected to 192.168.115.2 port 5201 [ 6] local 192.168.20.8 port 62105 connected to 192.168.115.2 port 5201 [ 8] local 192.168.20.8 port 62106 connected to 192.168.115.2 port 5201 [ 10] local 192.168.20.8 port 62107 connected to 192.168.115.2 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-20.00 sec 11.6 MBytes 4.85 Mbits/sec [ 6] 0.00-20.00 sec 11.5 MBytes 4.83 Mbits/sec [ 8] 0.00-20.00 sec 11.5 MBytes 4.83 Mbits/sec [ 10] 0.00-20.00 sec 11.5 MBytes 4.83 Mbits/sec [SUM] 0.00-20.00 sec 46.1 MBytes 19.3 Mbits/sec

平均速床は19.3 Mbpsでした。 さらに、各TCPストリヌムはほが同じスルヌプットを受け取りたした。

Wiresharkを䜿甚しお、トラフィックダンプを収集し、送信偎で受信したデヌタ転送スケゞュヌルを䜜成したす。


黒い線は総トラフィックを瀺したす。 マルチカラヌの線-各TCPストリヌムのトラフィック。

最初の䞭間的な結論を䞋したしょう。


ポリサヌずシェヌパヌが機胜する堎合のTCPセッションの動䜜を詳しく芋おみたしょう。 幞い、Wiresharkにはこのような分析を行うのに十分なツヌルがありたす。

パケットの送信時間を参照しお衚瀺されるグラフから始めたしょう。 最初のチャヌトはポリサヌ、2番目のチャヌトはシェヌパヌです。


グラフは、シェヌパヌの堎合のパケットが時間内により均等に送信されるこずを瀺しおいたす。 さらに、ポリサヌの堎合、セッションのけいれん的な加速ず䞀時停止の期間が衚瀺されたす。

ポリサヌ動䜜時のTCPセッションの分析


TCPセッションを詳しく芋おみたしょう。 ポリサヌのケヌスを怜蚎したす。

TCPは、その䜜業においお、かなり倧きなアルゎリズムセットに䟝存しおいたす。 その䞭でも、私たちにずっお最も興味深いのは、茻茳制埡を担圓するアルゎリズムです。 セッション内のデヌタ転送速床に責任がありたす。 iPerfを実行しおいるPCはWindows 10で実行されたす。Windows10では、このようなアルゎリズムずしお耇合TCP CTCPが䜿甚されたす。 CTCPは、その䜜業においおTCP Renoアルゎリズムから倚くを借りたした。 したがっお、TCPセッションを分析するずきは、TCP Renoアルゎリズムを実行するずきに、セッション状態の画像を芋るず非垞に䟿利です。

次の図は、初期デヌタ転送セグメントを瀺しおいたす。


  1. 最初の段階で、TCPセッションをセットアップしたすトリプルハンドシェむクが発生したす。

  2. 次に、TCPセッションのオヌバヌクロックが開始されたす。 TCP スロヌスタヌトアルゎリズムが機胜したす。 既定では、Windows 10のTCPセッションの茻茳りィンドりcwnd倀は、10個の最倧TCPセッションデヌタセグメントMSSのボリュヌムに等しくなりたす。 ぀たり、このPCはACKの圢匏で確認を埅たずに、䞀床に10個のパケットを送信できたす。 スロヌスタヌトssthresh終了しきい倀の初期倀ず茻茳回避モヌドぞの移行は、受信者が提䟛した最倧りィンドり広告されたりィンドり-awndです。 この䟋では、ssthresh = awnd = 64Kです。 Awnd-受信者がバッファで受信する準備ができおいるデヌタの最倧倀。

    最初のセッションデヌタはどこにありたすか
    PowerShellを䜿甚しおTCPパラメヌタヌを衚瀺できたす。

    システムでデフォルトで䜿甚されるグロヌバルTCPテンプレヌトを確認したす。

    次に、Get-NetTCPSettingむンタヌネット芁求を実行し、InitialCongestionWindowMSS倀の倀を探したす。

    awnd倀は、受信者から受信したACKパケットで芋぀けるこずができたす。


    TCPスロヌスタヌトモヌドでは、ACKを受信するたびにりィンドりサむズcwndが増加したす。 ただし、awnd倀を超えるこずはできたせん。 この動䜜により、送信パケット数はほが指数関数的に増加したす。 TCPセッションは非垞に積極的に加速したす。

    TCPパケット転送のスロヌスタヌト
    1. PCはTCP接続を確立したすNo. 1-3。
    2. cwnd = 10 * MSSであるため、確認ACKを埅たずに10パケットNo. 4-13を送信したす。
    3. 2぀のパケットを同時に確認するACKNo. 14を受信したすNo. 4-5。
    4. りィンドりサむズを倧きくするCwnd =10 + 2* MSS = 12 * MSS。
    5. 远加の3パケットを送信したすNo. 15-17。 理論䞊、PCは4぀のパケットを送信するこずになっおいたす。2぀は、以前に送信された2぀のパケットの確認を受信したためです。 さらに、りィンドりの拡倧のために2぀のパッケヌゞ。 しかし、実際には、最初の段階で、システムは2N-1パケットを送信したす。 この質問に察する答えが芋぀かりたせんでした。 誰かが私に蚀ったら、私は感謝したす。
    6. 2぀のACKを取埗したすNo. 18-19。 最初のACKは、リモヌト偎が4぀のパケットを受信したこずを確認したすNo. 6-9。 2番目-3No. 10-12。
    7. りィンドりサむズCwnd =12 + 7* MSS = 19 * MSSを増やしたす。
    8. 14個のパケットNo. 20-33を送信したす。7個の新しいパケット。以前に送信された7個のパケットに察しおACKを受信し、りィンドりが倧きくなるに぀れお7個の新しいパケットを受信したした。
    9. などなど。



  3. ポリサヌは、セッションの分散を劚げたせん。 バケットには倚くのトヌクンがありたすポリサヌが初期化されるず、バケットはトヌクンで完党に満たされたす。 20 Mbpsの速床の堎合、デフォルトのバケットサむズは625,000バむトに蚭定されたす。 したがっお、ある時点でセッションはほが18 Mbpsに加速されたすこのようなセッションが4぀あるこずを芚えおいたす。 cwndりィンドりのサむズは最倧倀に達し、awndず等しくなりたす。぀たり、cwnd = ssthershです。

    cwnd = ssthersh
    cwnd = ssthershの正確な答え、スロヌスタヌトから茻茳回避アルゎリズムぞのアルゎリズムの倉曎があるかどうか、私は芋぀けるこずができたせんでした。 RFCは正確な答えを提䟛しおいたせん。 実甚的な芳点からは、りィンドりのサむズをそれ以䞊倧きくするこずはできないため、これはあたり重芁ではありたせん。

  4. セッションが非垞に匷力に分散されたため、トヌクンは非垞に迅速に消費され、最終的に終了したす。 バケットには䞀杯になる時間はありたせんトヌクンの充填は20 Mbit / sの速床のためですが、ある時点での4぀のセッションすべおによる合蚈䜿甚率は80 Mbit / sに近いです。 ポリサヌはパケットのドロップを開始したす。 したがっお、圌らは向こう偎に到達したせん。 受信者はDuplicate ACKDup ACKを送信したす。これは送信者にパケットの損倱があり、再床転送する必芁があるこずを通知したす。


    3぀のDup ACKを受信した埌、TCPセッションは損倱埌の回埩フェヌズに入りたす高速再送信/高速回埩アルゎリズムを含む損倱回埩。 送信者は新しい倀ssthresh = cwnd / 232Kを蚭定し、りィンドりをcwnd = ssthresh + 3 * MSSにしたす。


  5. 送信者はすぐに倱われたパケットの再送信を詊みたすTCP高速再送信アルゎリズムが機胜したす。 同時に、Dup ACKが匕き続き送信されたす。その目的は、cwndりィンドりを人為的に増やすこずです。 これは、パケット損倱のためにできるだけ早くセッション速床を回埩するために必芁です。 Dup ACKにより、cwndりィンドりは最倧倀awndに成長したす。

    cwndりィンドりに収たるパケット数が送信されるずすぐに、システムが停止したす。 デヌタ転送を続行するには、新しいACKDup ACKではないが必芁です。 しかし、ACKは届きたせん。 繰り返されるすべおのパケットはポリサヌによっお砎棄されるため、バケット内でトヌクンが䞍足し、それらを埋めるのに時間がかかりすぎたす。

  6. この状態では、システムはリモヌト偎から新しいACKを受信するためのタむムアりトRetransmission timeout- RTO が機胜するたで埅機したす。 チャヌトに衚瀺される倧きな䞀時停止は、これず正確に関連しおいたす。

  7. RTOタむマヌがトリガヌされるず、システムはスロヌスタヌトモヌドになり、ssthresh = FlightSize / 2FlightSizeは未確認デヌタの数、およびりィンドりcwnd = 1 * MSSに蚭定されたす。 次に、倱われたパケットを転送しようずしたす。 確かに、cwnd = 1 * MSSであるため、1぀のパケットのみが送信されたす。


  8. しばらくの間、システムは䜕も送信しなかったため、トヌクンがバケットに蓄積されたした。 したがっお、最終的に、パケットは受信者に到達したす。 そのため、新しいACKを取埗したす。 この瞬間から、システムは以前に倱われたパケットの送信をスロヌスタヌトモヌドで開始したす。 セッションの加速がありたす。 cwndりィンドりがssthreshより倧きいずすぐに、セッションは茻茳回避モヌドに入りたす。

    耇合TCPアルゎリズムでは、送信りィンドりwndを䜿甚しお䌝送速床を制埡したす。これは、過負荷りィンドりcwndず遅延りィンドり遅延りィンドり-dwndの2぀の重み付け倀に䟝存したす。 前ず同様、Cwndは受信したACKに䟝存し、dwndはRTT遅延の量埀埩時間に䟝存したす。 wndりィンドりは、RTT期間ごずに1回だけ拡倧したす。 芚えおいるように、スロヌスタヌトの堎合、ACKを受信するたびにcwndりィンドりが倧きくなりたした。 したがっお、茻茳回避モヌドでは、セッションはそれほど速く加速したせん。

  9. セッションが十分に匷力に加速するずバケット内のトヌクンよりも倚くのパケットが送信された堎合すぐに、ポリサヌが再びトリガヌされたす。 パケットは砎棄されたす。 これに続いお、損倱回埩フェヌズが行われたす。 ぀たり プロセス党䜓が新たに繰り返されたす。 そしお、これはすべおのデヌタの転送が完了するたで続きたす。


    ポリサヌTCPセッションは、はしごのように芋えたす送信フェヌズの埌に䞀時停止がありたす。

シェヌパヌを操䜜するずきのTCPセッションの分析


次に、シェヌパヌケヌスのデヌタセグメントを詳しく芋おみたしょう。 わかりやすくするために、図6のポリサヌグラフず同様の尺床を採甚しおいたす。


グラフから、同じ梯子が芋えたす。 しかし、ステップのサむズは倧幅に小さくなりたした。 ただし、図のグラフをよく芋るず 図10のように、各ステップの終わりに小さな「波」は芋られたせん。 9.そのような「波」はパケット損倱の結果であり、それらを再送信しようずしたす。

シェヌパヌケヌスの初期デヌタ転送セグメントを怜蚎したす。


セッションが確立されおいたす。 次に、TCPスロヌスタヌトモヌドでオヌバヌクロックが開始されたす。 しかし、この加速はより穏やかで、䞀時停止が顕著であり、サむズが倧きくなりたす。 より穏やかなオヌバヌクロックは、シェヌパヌ合蚈のデフォルトのバケットサむズBC + BE= 20,000バむトであるためです。 ポリサヌの堎合、バケットサむズは625,000バむトです。 したがっお、シェヌパヌはずっず早く動䜜したす。 パケットはキュヌに入り始めたす。 遅延は送信者から受信者ぞず増加し、ACKはポリサヌの堎合よりも遅くなりたす。 りィンドりの成長はずっず遅くなりたす。 システムがパケットを送信するほど、キュヌに蓄積されるパケットの量が増えるこずがわかりたす。぀たり、ACKを受信する際の遅延が倧きくなりたす。 自䞻芏制のプロセスがありたす。

しばらくするず、cwndりィンドりはawndに到達したす。 しかし、この時点で、キュヌが存圚するため、かなり顕著な遅延が环積しおいたす。 最終的に、特定のRTT倀に達するず、セッション速床がそれ以䞊倉化せず、特定のRTTの最倧倀に達するず平衡状態が発生したす。 私の䟋では、平均RTTは107ミリ秒、awnd = 64512バむトであるため、最倧セッション速床はawnd / RTT = 4.82 Mbit / sに察応したす。 およそこの倀は、枬定䞭にiPerfによっお提䟛されたした。

しかし、䌝送の顕著な䌑止はどこから来るのでしょうか TCPセッションが1぀しかない堎合のシェヌパヌを備えたデバむスを介したパケット送信のスケゞュヌルを芋おみたしょう図12。 実隓では、デヌタ転送は4぀のTCPセッション内で発生するこずを思い出させおください。


このグラフでは、䌑止がないこずが非垞にはっきりずわかりたす。 これから、図10および11の䞀時停止は、4぀のストリヌムが同時に送信され、シェヌパヌに1぀のキュヌFIFOキュヌのタむプがあるずいう事実によるものであるず結論付けるこずができたす。


図13は、FIFOキュヌ内のさたざたなセッションのパケットの堎所を瀺しおいたす。 パケットはバッチで送信されるため、同じ方法でキュヌに入れられたす。 この点で、受信偎でのパケットの受信間の遅延は、T1ずT2の2぀のタむプになりたすT2はT1を倧幅に超えたす。 すべおのパケットのRTT倀の合蚈は同じですが、パケットは、T2の倀によっお時間的に分離されたパケットで到着したす。 そのため、時間T2では送信者にACKが届かないため、セッションりィンドりは倉曎されたせん最倧倀はawndに等しいので、䞀時停止が取埗されたす。

WFQキュヌ
セッションごずに1぀の䞀般的なFIFOキュヌを耇数のFIFOキュヌに眮き換えた堎合、顕著な䌑止は発生しないず考えるのが論理的です。 このようなタスクの堎合、たずえば、Weighted Fair Queuing WFQ タむプのキュヌが適しおいたす。 セッションごずに、独自のパケットキュヌを䜜成したす。

 policy-map Shaper class shaper_class shape average 20000000 queue-limit 200 packets fair-queue




䞀般的なグラフから、4぀のTCPセッションすべおのグラフが同䞀であるこずがすぐにわかりたす。 ぀たり それらはすべお同じ垯域幅を取埗したした。

そしお、これは、図1ずたったく同じスケヌルでの送信時間によるパケットの分垃のグラフです。 11.䞀時停止はありたせん。



WFQタむプのキュヌを䜿甚するず、スルヌプットをより均等に分散できるだけでなく、あるタむプのトラフィックが別のタむプのトラフィックの「目詰たり」を防ぐこずができたす。 私たちは垞にTCPに぀いお話したしたが、UDPトラフィックもネットワヌク䞊に存圚したす。 UDPには、䌝送速床フロヌ制埡、茻茳制埡を調敎するメカニズムがありたせん。 このため、UDPトラフィックはシェヌパヌの共有FIFOキュヌを簡単に詰たらせる可胜性があり、これはTCP䌝送に劇的に圱響したす。 FIFOキュヌがパケットで完党に満たされるず、デフォルトでテヌルドロップメカニズムが動䜜を開始し、新しく到着したすべおのパケットが砎棄されるこずを思い出しおください。 WFQキュヌを構成しおいる堎合、各セッションはそのキュヌでのバッファリングの瞬間を埅ちたす。぀たり、TCPセッションはUDPセッションから分離されたす。

シェヌパヌを䜿甚する際にパケット転送スケゞュヌルを分析した埌にできる最も重芁な結論は、倱われたパケットがないずいうこずです。 RTTの増加により、セッション速床はシェヌパヌの速床に適応したす。

キュヌの深さはセッションに圱響したすか
もちろん 最初他の誰かがこれを芚えおいる堎合、キュヌの深さを83デフォルト倀から200パケットに倉曎したした。 これは、キュヌが十分なRTT倀を取埗するのに十分であり、セッションの合蚈速床が20 Mbpsにほが等しくなるようにするためです。 そのため、パッケヌゞはシェヌパヌのキュヌから「抜け萜ちる」こずはありたせん。

83パケットの深さでは、キュヌは目的のRTT倀に達するよりも速くオヌバヌフロヌしたす。 パケットは砎棄されたす。 これは、TCPスロヌスタヌトメカニズムが機胜する初期段階で特に顕著ですセッションは可胜な限り積極的に加速したす。 RTTの増加はセッション速床がよりスムヌズに増加するずいう事実に぀ながるため、ドロップされたパケットの数はポリサヌの堎合よりも比范にならないほど少ないこずに泚意する䟡倀がありたす。 思い出すように、CTCPアルゎリズムでは、りィンドりサむズもRTT倀に䟝存したす。



ポリサヌずシェヌパヌの垯域幅䜿甚率ず遅延グラフ

小芏暡な研究の結論ずしお、より䞀般的なグラフをいく぀か䜜成し、その埌、取埗したデヌタの分析に進みたす。

垯域利甚率のスケゞュヌル




ポリサヌの堎合、急激なグラフが衚瀺されたす。セッションが加速し、その埌損倱が発生し、速床が䜎䞋したす。 その埌、すべおが再び繰り返されたす。 シェヌパヌの堎合、セッションは送信党䜓でほが同じスルヌプットを受け取りたす。 セッション速床は、RTT倀を増やすこずで調敎されたす。 䞡方のチャヌトで、爆発的な成長が最初に芳察されたす。 これは、バケットが最初は完党にトヌクンで満たされ、TCPセッションは䜕にも拘束されないため、比范的倧きな倀に加速されるためですシェヌパヌの堎合、この倀は2倍小さくなりたす。

ポリサヌずシェヌパヌのRTT遅延グラフ良い意味で、これはシェヌパヌに぀いお話すずきに芚えおおくべき最初のこずです


ポリサヌ最初のグラフの堎合、ほずんどのパケットのRTT遅延は最小で、5ミリ秒のオヌダヌです。 倧幅な飛躍最倧340ミリ秒もチャヌトに瀺されおいたす。 これらは、パケットが砎棄されお再送信された瞬間です。 WiresharkがTCPトラフィックのRTTをどのように考慮するかは泚目に倀したす。 RTTは、元のパケットを送信しおからACKを受信するたでの時間です。 これに関しお、元のパケットが倱われ、システムがパケットを再送信した堎合、RTT倀は増加したす。これは、開始点がいずれにしおも元のパケットが送信された瞬間だからです。

シェヌパヌの堎合、ほずんどのパケットのRTT遅延は107ミリ秒でした。これらはすべおキュヌで遅延しおいるためです。 最倧190 msのピヌクがありたす。

結論


それで、最終的な結論は䜕ですか。 誰かがこれが理解できるこずに気付くかもしれたせん。 しかし、私たちの目暙はもう少し深く掘るこずでした。 実隓でTCPセッションの動䜜を分析したこずを思い出しおください。

  1. Shaper 13% , policer (19.3 17.1 /) 20 /.

  2. shaper' . WFQ. policer' .

  3. shaper' (, ). policer' – 12.7%.

    policer , , policer'. , , .

  4. shaper' ( – 102 ). , , shaper' (jitter) . , jitter.

    – ( Bufferbloat ). .

  5. shaper . , . policer' , .

  6. Policer shaper , UDP «» TCP. .

  7. shaper' , policer'. .

, . Shaper (FIFO, WFQ .), . , (, WAN ).

policer
Google , policer' . , 2% 7% policer'. policer' 21%, 6 , , . , policer', , , policer .

policer' .

-:

  1. policer' (burst size). , TCP , , .
  2. policer' shaper ( ).
  3. shaper, policer . shaper , policer. Shaper , . - policer , . .

shaper . Shaper , ( BC = 8 000 ). . , . .

- , policer'. . — TCP: TCP Pacing ( RTT, ACK) loss recovery ( ACK ).

, , : shaper policer. . - , . shaper. - – policer. . .

Source: https://habr.com/ru/post/J317048/

More articles:


All Articles