Clever Geek Handbook

ダりンロヌド速床に圱響する内郚TCPメカニズムパヌト2





最初の郚分では、TCPの「トリプルハンドシェむク」ずいく぀かのテクノロゞヌTCP高速オヌプン、フロヌ制埡ず茻茳、りィンドりスケヌリングを調べたした 。 第2郚では、TCPスロヌスタヌトずは䜕か、デヌタ転送速床を最適化しお初期りィンドりを増やす方法、およびTCP / IPスタックを最適化するためのすべおの掚奚事項を収集したす。



スロヌスタヌト



TCPにはフロヌ制埡が存圚したすが、80幎代半ばにはネットワヌク蓄積の厩壊が本圓の問題でした。 問題は、フロヌ制埡では送信者がデヌタ内の受信者を「ownれさせる」こずを蚱可しおいなかったが、ネットワヌクでこれが行われないようにするメカニズムがなかったずいうこずでした。 結局、送信者も受信者も接続開始時のチャネル幅を知らないため、ネットワヌク内の倉化する条件に速床を適応させるための䜕らかのメカニズムが必芁です。



たずえば、自宅にいお、最倧速床を確保するためにすべおのダりンリンクをダりンロヌドしたリモヌトサヌバヌから倧きなビデオをダりンロヌドした堎合。 次に、自宅の別のナヌザヌが䞀括゜フトりェア曎新プログラムをダりンロヌドするこずにしたした。 ビデオの利甚可胜なチャネルは突然非垞に小さくなり、ビデオを送信するサヌバヌはデヌタの送信速床を倉曎する必芁がありたす。 圌が同じ速床で続けるず、デヌタは単に䞭間ゲヌトりェむで「ヒヌプに蓄積」され、パケットは「ドロップ」したす。これは、ネットワヌクの非効率的な䜿甚を意味したす。



1988幎、Van JacobsonずMichael J. Karelsは、この問題に察凊するためにいく぀かのアルゎリズムを開発したした。スロヌスタヌト、過負荷防止、高速再送信、高速回埩です。 それらはすぐにTCP仕様の必須郚分になりたした。 これらのアルゎリズムのおかげで、むンタヌネットの䞖界的な問題は、トラフィックが指数関数的に増加した80幎代埌半/ 90幎代前半に回避されたず考えられおいたす。



スロヌスタヌトの仕組みを理解するために、ニュヌペヌクのクラむアントがロンドンのサヌバヌからファむルをダりンロヌドしようずしおいる䟋に戻りたしょう。 たず、トリプルハンドシェむクが実行されたす。その間に、圓事者はASKパケットで受信りィンドりの倀を亀換したす。 最埌のACKパケットがネットワヌクに入るず、デヌタ亀換を開始できたす。



クラむアントずサヌバヌ間のチャネル幅を掚定する唯䞀の方法は、デヌタ亀換䞭にチャネル幅を枬定するこずであり、これがたさにスロヌスタヌトの原因です。 最初に、サヌバヌはTCP接続の新しい茻茳りィンドり倉数cwndを初期化し、システム倀Linuxではinitcwndに埓っお倀を控えめに蚭定したす。



cwnd倉数の倀は、クラむアントずサヌバヌ間で亀換されたせん。 これは、ロンドンのサヌバヌのロヌカル倉数になりたす。 次に、新しいルヌルが導入されたした。サヌバヌずクラむアント間の「送信䞭」のデヌタの最倧量ASKで確認されないは、rwndずcwndの最小倀でなければなりたせん。 しかし、サヌバヌずクラむアントは、オヌバヌロヌドりィンドりの最適倀に぀いおどのように「同意する」こずができたすか。 実際、ネットワヌクの状態は絶えず倉化しおいるため、各TCP接続を調敎する必芁なくアルゎリズムが機胜するこずを望んでいたす。



解決策䜎速で送信を開始し、パケット受信が確認されるずりィンドりを増やしたす。 これは遅いスタヌトです。



初期cwnd倀は、最初に1ネットワヌクセグメントに蚭定されおいたした。 RFC 2581では、これは4セグメントに倉曎され、RFC 6928では最倧10セグメントに倉曎されたした。



したがっお、サヌバヌは最倧10個のネットワヌクセグメントをクラむアントに送信できたす。その埌、送信を停止しお確認を埅぀必芁がありたす。 次に、受信したACKごずに、サヌバヌはcwnd倀を1セ​​グメントず぀増やすこずができたす。 ぀たり、ASKで確認された各パッケヌゞに察しお、2぀の新しいパッケヌゞを送信できたす。 これは、サヌバヌずクラむアントが䜿甚可胜なチャネルをすぐに「占有」するこずを意味したす。





図 1.過負荷制埡および防止。



スロヌスタヌトは、ブラりザアプリケヌションの開発にどのように圱響したすか 各TCP接続はスロヌスタヌトフェヌズを通過する必芁があるため、䜿甚可胜なチャネル党䜓をすぐに䜿甚するこずはできたせん。 すべおは小さなオヌバヌロヌドりィンドりから始たり、埐々に拡倧しおいたす。 したがっお、所定のボヌレヌトに達するたでにかかる時間は、埀埩遅延ず茻茳りィンドりの初期倀の関数です。



Nに等しいcwndに達するたでの時間。









これが実際にどのように行われるかを理解するために、次の前提を考えおみたしょう。





64Kの受信りィンドりにもかかわらず、TCP接続のスルヌプットは最初は茻茳りィンドりによっお制限されたす。 64Kの制限に到達するには、茻茳りィンドりを45セグメントに拡倧する必芁がありたす。これには168ミリ秒かかりたす。









クラむアントずサヌバヌがメガビット/秒を盞互に亀換できる可胜性があるずいう事実は、スロヌスタヌトにずっお重芁ではありたせん。









図 2.茻茳りィンドりの拡倧。



茻茳りィンドりの最倧倀に達するたでの時間を短瞮するために、パケットが行き来する時間、぀たりサヌバヌをクラむアントに地理的に近づける時間を短瞮できたす。



クラむアントずサヌバヌは数十たたは数癟ミリ秒で茻茳りィンドりの最倧倀に達するが、これは1぀のTCP接続であるため、スロヌスタヌトは倧きなファむルのダりンロヌドやビデオのストリヌミングにはほずんど圱響したせん。



ただし、倚くのHTTP芁求では、タヌゲットファむルが比范的小さい堎合、最倧茻茳りィンドりに達する前に転送が終了する堎合がありたす。 ぀たり、Webアプリケヌションのパフォヌマンスは、サヌバヌずクラむアント間の埀埩遅延によっお制限されるこずがよくありたす。



スロヌスタヌト再起動SSR



TCPは、新しい接続のボヌレヌトの調敎に加えお、接続が指定された期間䜿甚されなかった堎合に茻茳りィンドりをリセットするスロヌスタヌト再起動メカニズムも提䟛したす。 ここでのロゞックは、接続の非アクティブ䞭にネットワヌク条件が倉化する可胜性があるこずです。過負荷を回避するために、りィンドり倀は安党な倀にリセットされたす。



圓然のこずながら、SSRは、たずえばナヌザヌの非アクティブなどにより䞀時的にアむドル状態になる可胜性のある、長寿呜のTCP接続のパフォヌマンスに倧きな圱響を䞎える可胜性がありたす。 したがっお、サヌバヌ䞊でSSRを無効にしお、長期間有効な接続のパフォヌマンスを改善するこずをお勧めしたす。 Linuxでは、次のコマンドを䜿甚しおSSRのステヌタスを確認し、無効にするこずができたす。 



  $> sysctl net.ipv4.tcp_slow_start_after_idle 
 $> sysctl -w net.ipv4.tcp_slow_start_after_idle = 0


小さなファむルの転送におけるスロヌスタヌトの圱響を瀺すために、ニュヌペヌクのクラむアントが次のパラメヌタヌを䜿甚しお新しいTCP接続を介しおロンドンのサヌバヌに64 KBファむルを芁求したずしたす。







図 3.新しいTCP接続を介しおファむルをダりンロヌドしたす。





新しいTCP接続で64 KBファむルを転送するには、264ミリ秒かかりたす。 ここで、クラむアントが同じ接続を再利甚し、同じ芁求を再床行うこずを想像しおみたしょう。





図 4.既存のTCP接続を介しおファむルをダりンロヌドしたす。





同じ接続を介しお行われた同じ芁求が、ハンドシェむクに時間を費やすこずなく、スロヌスタヌトによりスルヌプットを増加させるこずなく、96ミリ秒で実行されたす。぀たり、275高速です。



どちらの堎合も、クラむアントずサヌバヌが5 Mbpsの垯域幅を持぀チャネルを䜿甚するずいう事実は、ファむルのダりンロヌド時間に圱響を䞎えたせんでした。 茻茳りィンドりのサむズずネットワヌク遅延のみが制限芁因でした。 興味深いこずに、ネットワヌク遅延が増加するず、新芏および既存のTCP接続を䜿甚するずきのパフォヌマンスの差が倧きくなりたす。



新しい接続の䜜成における遅延の問題を認識したら、キヌプアラむブ、パむプラむン、倚重化などの最適化方法をすぐに䜿甚する必芁がありたす。



TCP茻茳りィンドりの初期倀を増やしたす



これは、TCPを䜿甚するすべおのナヌザヌたたはアプリケヌションのパフォヌマンスを向䞊させる最も簡単な方法です。 倚くのオペレヌティングシステムでは、曎新で既に10ずいう新しい倀が䜿甚されおいたす。 Linux 10の堎合、カヌネルバヌゞョン2.6.39以降のオヌバヌロヌドりィンドりのデフォルト倀。



過負荷防止



TCPは、パフォヌマンスの調敎に圹立぀フィヌドバックメカニズムずしおパケット損倱を䜿甚するこずを理解するこずが重芁です。 スロヌスタヌトは、茻茳りィンドりの控えめな倀ずの接続を䜜成し、受信者の受信りィンドり、sshtreshシステムのしきい倀に達するたで、たたはパケットが倱われ始めるたで、時間ごずに送信されるデヌタ量を2倍にしたす。その埌、茻茳回避アルゎリズムがオンになりたす。



茻茳回避は、パケット損倱がネットワヌク茻茳の指暙であるずいう仮定に基づいおいたす。 リンク䞊のパケットのパス䞊のどこか、たたは蓄積されたルヌタヌパケット䞊のどこかで、これは、ネットワヌクのさらなるトラフィックの詰たりを防ぐために茻茳りィンドりを枛らす必芁があるこずを意味したす。



オヌバヌロヌドりィンドりが瞮小された埌、別のアルゎリズムを䜿甚しお、りィンドりをさらに拡倧する方法を決定したす。 遅かれ早かれ、別のパケット損倱が発生し、プロセスが繰り返されたす。 TCP接続を通過するトラフィックののこぎりのようなグラフを芋たこずがある堎合、これは、制埡および茻茳防止アルゎリズムがネットワヌク内のパケット損倱に応じお茻茳りィンドりを調敎するためです。



これらのアルゎリズムの改善は、科孊的研究ず垂販補品の開発の䞡方の掻発な分野であるこずは泚目に倀したす。 特定のタむプのネットワヌク䞊で、たたは特定のタむプのファむルを転送するためなど、より適切に機胜するオプションがありたす。 実行しおいるプラ​​ットフォヌムに応じお、TCP Tahoe and Reno初期実装、TCP Vegas、TCP New Reno、TCP BIC、TCP CUBICデフォルトではLinux、Compound TCPby Windowsのデフォルトおよび他の倚くの。 特定の実装に関係なく、Webアプリケヌションのパフォヌマンスに察するこれらのアルゎリズムの圱響は䌌おいたす。



TCPの比䟋速床䜎䞋



パケット損倱から回埩する最善の方法を決定するこずは、最も簡単な䜜業ではありたせん。 これに積極的に反応しすぎるず、偶発的なパケット損倱が接続速床に過床に悪圱響を及がしたす。 十分に迅速に応答しない堎合、これによりパケット損倱がさらに発生する可胜性が高くなりたす。



最初は、TCPは乗数の枛少ず加算の増加AIMDアルゎリズムを䜿甚したした。パケットが倱われるず、茻茳りィンドりは半分になり、ラりンドトリップパケットが通過するたびに所定の量ず぀埐々に増加したす。 倚くの堎合、AIMDは過床に保守的なアルゎリズムであるこずが刀明したため、新しいアルゎリズムが開発されたした。



Proportional Rate ReductionPRRは、RFC 6937で説明されおいる新しいアルゎリズムであり、その目的は、パケット損倱埌により迅速に回埩するこずです。 アルゎリズムが開発されたGoogleの枬定によるず、パケット損倱に関連しおネットワヌク遅延を平均3〜10削枛できたす。 Linux 3.2以降では、PPRはデフォルトで有効になっおいたす。



チャネル幅ず遅延の積垯域幅遅延積-BDP



組み蟌みのTCP茻茳制埡メカニズムには重芁な結果がありたす。受信偎ず送信偎の最適なりィンドり倀は、埀埩遅延ずタヌゲットデヌタレヌトに応じお倉化する必芁がありたす。 「送信䞭」の未確認パケットの最倧数は、受信および過負荷りィンドりrwndおよびcwndからの最小倀ずしお定矩されるこずを思い出しおください。 送信者が未確認パケットの最倧数を超えた堎合、送信者が転送を再開できるように、送信を停止し、受信者が特定の数のパケットを確認するたで埅機する必芁がありたす。 圌はどれくらい埅぀べきですか これは、埪環遅延によっお決たりたす。



BDPは転送䞭のデヌタ量を決定したす



送信者が頻繁に停止し、以前に送信されたパケットのACK確認を埅぀必芁がある堎合、これによりデヌタストリヌムにギャップが生じ、最倧接続速床が制限されたす。 この問題を回避するには、以前に送信したパケットからのACK確認の受信を埅機しお、デヌタを送信できるようにりィンドりサむズを十分に倧きく蚭定する必芁がありたす。 その埌、最倧䌝送速床が可胜になり、ギャップがなくなりたす。 したがっお、最適なりィンドりサむズは埪環遅延の速床に䟝存したす。





図 5.小さなりィンドり倀による䌝送ギャップ。



受信りィンドりずオヌバヌロヌドりィンドりの倧きさはどれくらいですか 䟋を芋おみたしょうcwndずrwndが16 KBに等しく、埪環遅延が100 msに等しいずしたす。 次に







送信偎ず受信偎の間のチャネルの幅に関係なく、このような接続では1.31 Mbpsを超える速床が埗られないこずがわかりたす。 速床を䞊げるには、りィンドりの倀を増やすか、埪環遅延を枛らす必芁がありたす。



同様に、埪環遅延ず必芁なチャネル幅を知っお、りィンドりの最適倀を蚈算できたす。 時間は同じ100ミリ秒のたたで、送信偎チャネル幅は10 Mbit / sであり、受信偎は100 Mbit / sの高速チャネル䞊にあるず仮定したす。 それらの間のネットワヌクに䞭間セクションで問題がないず仮定するず、送信者は次のようになりたす。







10 Mbpsチャネルを完党に占有するには、りィンドりサむズが少なくずも122.1 KBである必芁がありたす。 りィンドりスケヌリングが有効になっおいない限り、TCPの最倧受信りィンドりサむズは64 KBであるこずを思い出しおくださいRFC 1323。 蚭定を再確認するもう1぀の理由



幞いなこずに、りィンドりのサむズ倉曎はネットワヌクスタックで自動的に行われたす。 悪いニュヌスは、これが制限芁因になる堎合があるこずです。 接続が利甚可胜なチャネル幅のほんの䞀郚の速床で送信される理由を疑問に思った堎合、これはりィンドりのサむズが小さいためである可胜性が高いです。



高速ロヌカル゚リアネットワヌクのBDP



埪環遅延は、ロヌカルネットワヌクのボトルネックになる可胜性がありたす。 1ミリ秒の埀埩遅延で1ギガビット/秒を達成するには、少なくずも122 KBのオヌバヌロヌドりィンドりが必芁です。 蚈算は䞊に瀺したものず同様です。



キュヌの先頭のブロック行頭ブロッキング-HOLブロッキング



TCPは䞀般的なプロトコルですが、特定のケヌスに最も適しおいるのは、これだけではありたせん。 泚文の配達などの機胜は必ずしも必芁ではなく、堎合によっおは遅延が増加する可胜性がありたす。



各TCPパケットには䞀意のシヌケンス番号が含たれおおり、デヌタは順番に到着する必芁がありたす。 パケットの1぀が倱われた堎合、その埌のすべおのパケットは、倱われたパケットが再送されお受信者に届くたで、受信者のTCPバッファヌに栌玍されたす。 これはTCP局で発生するため、アプリケヌションはこれらの再送信やバッファ内のパケットキュヌを「認識」せず、デヌタが䜿甚可胜になるたで埅機したす。 アプリケヌションが「認識する」のは、゜ケットからデヌタを読み取るずきに発生する遅延だけです。 この効果は、キュヌの開始をブロックするこずずしお知られおいたす。



キュヌの先頭をブロックするず、アプリケヌションでパケットを敎理する必芁がなくなり、コヌドが簡玠化されたす。 ただし、䞀方で、パケットの到着に予枬できない遅延が発生し、アプリケヌションのパフォヌマンスに悪圱響を及がしたす。





図 6.キュヌの先頭をブロックしたす。



䞀郚のアプリケヌションでは、保蚌付き配信たたは泚文配信が必芁ない堎合がありたす。 各パケットが個別のメッセヌゞである堎合、順番に配信する必芁はありたせん。 たた、新しいメッセヌゞがそれぞれ以前のメッセヌゞを䞊曞きする堎合、保蚌された配信も必芁ありたせん。 しかし、TCPにはそのような堎合の蚭定はありたせん。 すべおのパケットが順番に配信され、䞀郚が配信されない堎合、再送されたす。 遅延が重芁なアプリケヌションでは、UDPなどの代替トランスポヌトを䜿甚できたす。



パケット損倱は正垞です



TCPパフォヌマンスを向䞊させるには、パケット損倱も必芁です。 倱われたパケットは、ネットワヌクの茻茳を回避しお遅延を最小限に抑えるために、受信者ず送信者が送信速床を倉曎できるフィヌドバックメカニズムずしお機胜したす。



䞀郚のアプリケヌションでは、パッケヌゞの玛倱を「コピヌ」できたす。たずえば、オヌディオ、ビデオを再生したり、ゲヌム内のステヌタスを転送したり、配信の保蚌や順序どおりの配信は必芁ありたせん。 したがっお、WebRTCはプラむマリトランスポヌトずしおUDPを䜿甚したす。



オヌディオの再生䞭にパケット損倱が発生した堎合、オヌディオコヌデックは再生に小さなギャップを挿入するだけで、着信パケットの凊理を続行できたす。 ギャップが小さい堎合、ナヌザヌはそれに気付かない可胜性があり、倱われたパケットの配信を埅機するず、再生の顕著な遅延が発生する可胜性があり、これはナヌザヌにずっお非垞に悪いこずです。



同様に、ゲヌムがその状態を枡す堎合、時間Tの状態に関する情報が既にある堎合、時間T-1の状態を蚘述するパケットを埅぀こずは意味がありたせん。



TCPの最適化



TCPは、ネットワヌクを最倧限に掻甚するように蚭蚈された適応型プロトコルです。 TCPの最適化には、TCPがネットワヌク条件にどのように応答するかを理解する必芁がありたす。 アプリケヌションは、ナヌザヌの安定した動䜜を確保するために、独自の品質保蚌QoSメ゜ッドを必芁ずする堎合がありたす。



アプリケヌションの芁件ずTCPアルゎリズムの倚数の機胜により、この分野での盞互接続ず最適化は研究の倧きな分野ずなっおいたす。 この蚘事では、TCPのパフォヌマンスに圱響するいく぀かの芁因に぀いおのみ觊れたした。 遞択的確認応答SACK、保留䞭の確認応答、高速再送信などの远加メカニズムにより、TCPセッションの理解ず最適化が耇雑になりたす。



各アルゎリズムずフィヌドバックメカニズムの特定の詳现は倉化し続けたすが、䞻芁な原則ずその結果は倉わりたせん。



その結果、珟代の高速ネットワヌクのTCP接続でデヌタを送信できる速床は、埪環遅延によっお制限されるこずがよくありたす。 チャネル幅は増加し続けたすが、遅延は光の速床によっお制限され、倚くの堎合、TCPボトルネックであるのはチャネル幅ではなく遅延です。



サヌバヌ構成のセットアップ



個々のTCPパラメヌタヌをそれぞれ構成する代わりに、オペレヌティングシステムの最新バヌゞョンに曎新するこずから始めるのが最善です。 TCPを䜿甚するためのベストプラクティスは進化を続けおおり、これらの倉曎のほずんどは、最近のOSバヌゞョンですでに利甚可胜です。



「サヌバヌ䞊のOSの曎新」は、ささいなアドバむスのように思えたす。 しかし実際には、倚くのサヌバヌは特定のバヌゞョンのカヌネル甚に構成されおおり、システム管理者は曎新に反察する堎合がありたす。 はい、アップグレヌドには独自のリスクが䌎いたすが、TCPパフォヌマンスの芳点からは、これが最も効果的なアクションになる可胜性がありたす。



OSを曎新した埌、ベストプラクティスに埓っおサヌバヌを構成する必芁がありたす。





他のTCPパラメヌタも蚭定する必芁がある堎合がありたす。 HTTPのTCPチュヌニングを参照しおください。これは、HTTPワヌキンググルヌプによっお定期的に曎新されたす。



Linuxナヌザヌの堎合、ssは開いおいる゜ケットのさたざたな統蚈を確認するのに圹立ちたす。 コマンドプロンプトで、次のように入力したす 

  ss --options --extended --memory --processes --info


珟圚のピアずその蚭定が衚瀺されたす。



アプリケヌションのセットアップ



アプリケヌションが接続を䜿甚する方法は、パフォヌマンスに倧きな圱響を䞎える可胜性がありたす。





䞍芁なデヌタ転送の陀倖は、もちろん、最適化の最も重芁なタむプです。 それでも特定のデヌタを転送する必芁がある堎合は、それらが適切な圧瞮アルゎリズムを䜿甚しおいるこずを確認するこずが重芁です。



䞖界䞭のサヌバヌをホストするか、CDNを䜿甚しおデヌタをクラむアントに近づけるず、ラりンドトリップレむテンシを削枛し、TCPパフォヌマンスを倧幅に向䞊させるこずができたす。



最埌に、可胜な堎合はすべお、既存のTCP接続を再利甚しお、スロヌスタヌトアルゎリズムず茻茳制埡による遅延を回避する必芁がありたす。



結論ずしお、TCPを最適化するために必芁なこずのチェックリストは次のずおりです。





More articles:


All Articles