従来、ほとんどのP2PアプリケーションはTCPを使用してデータを交換していました。 そのことについて、µTorrentは、すでに述べたhabr（ one 、 two ）で、UDPに基づく新しいプロトコルの使用を開始します。 この投稿では、新しいµTPプロトコルの詳細と、そのチューニングと無効化機能について説明します。 詳細は、ネットワークプロトコルから遠く離れた人々に明確になるように記述されています。
更新 ：公式プロトコルドキュメント： www.bittorrent.org/beps/bep_0029.html
TCPおよびUDPについて一言。 最初は、伝送制御プロトコル、またはフロー制御プロトコルの略です。 データが完全に、送信された順序で完全に宛先に到達するという保証を、それを使用するプログラムに与えるという点で便利です。 その使用には、接続の予備インストールと、最後のクローズが必要です。 これは、データが交換される「パイプ」の作成です。 UDPは、データが到着すること、またはデータが正しい順序で到着することを保証しません。 あるアドレスから別のアドレスに小さなデータブロック（データグラム）を送信することしかできません。 配信を確認し、必要に応じて再送信するすべての作業は、プログラム自体にかかっています。
トレントクライアントは既にこれを行っているため、これは大きな問題ではありません。 実際には、プロセスでTCP「パイプ」を介して送信されるデータは、断片（「パケット」）に分割され、それぞれが個別に送信されます。 同時に、1つのパケットは1つのルートに、別のパケットは別のパケットに、別のパケットは最初に到着し、最初に到着することができます。 したがって、「パイプ」の各参加者（オペレーティングシステムからルーターへ）は、個々のパケットを収集し、整合性と順序を確認し、一部のパケットが到達しなかった場合は転送を要求するバッファーを保持する必要があります。
同時に、送信者が広いチャネルに座っており、受信者がモデムに座っている場合、最初のデータはすぐに大きなデータブロックを送信し、すぐに2番目のプロバイダーに到達し、ゆっくりとモデムに浸透します。 この時点で、最初の受信者は、受信確認を受信していないため、ピースの一部を再度転送します。 その結果、プロバイダのバックボーンがこの不必要な転送で詰まっています。 uTPの主な目標の1つは、P2Pトラフィックからプロバイダーにかかる余分な負担を排除することです。
潜在的にuTPはµTorrentバージョン1.8に登場しましたが、着信uTP接続のみを受け入れることができ、それら自体を開始する方法を知りませんでした。 これは、アルファバージョン1.9で最初に学習され、次にbt.transp_dispositionキーを使用して新しいバージョン1.8でこれを有効にすることが可能になりました。 その値はバージョンごとに変わりましたが、現在では次のビットフラグに落ち着いています。
1-発信TCP接続の開始を許可します。
2-発信uTP接続の開始を許可します。
4-着信TCP接続の受け入れを許可します。
8-着信uTP接続を許可する
したがって、 13 （1 + 4 + 8）、最近のバージョンのデフォルト値は1.8であり、すべての種類の接続を受け入れるが、TCPのみを自分でインストールする機能を意味します。 15 （デフォルト値は2.0）は、すべてのタイプの発信接続と着信接続の両方を許可します。 uTPを無効にするには（問題が発生する場合）、 5 （1 + 4）を設定する必要があります。 1.8に15を入れることは価値があります-論点、彼らは公式フォーラムでバージョン2.0でのuTPサポートがはるかに優れていると書いているので、1.8の速度はTCPよりも悪い場合があります。
バージョン2.0では、UDPトラッカーのサポートも導入されました。 トラッカーの場合、一般に、TCPは非常に冗長であり、接続セットアップ/クローズパッケージで多くの追加リソースを必要とするため、UDPはオープントラッカーに適しています。 たとえば、最近、anirenaトラッカーはTCPに非常にバグがあり、最初から遠くまで回答します。DHTはしばしば禁止されており、UDPトラッカーは正常に動作します。 ただし、閉じたトラッカーの場合、適切ではありません。 この方法でスイングを識別するために通行人を送信することはできません。
2.0には、いくつかのNAT（ STUN ）をバイパスする方法が表示されます。これは、すべての場合に機能するわけではありませんが、より多くのNAT患者を接続するのに役立ちます。
すべての革新2.0の中で、私は個人的にTCPレート制御に最も満足していました。 これにより、速度とTCP接続を調整して、他のアプリケーションに干渉せず、上記の不要なパケット転送を最小限に抑えることができます。 以前は、これはcFosドライバーをインストールすることで達成されていました。このドライバーでは、トレントに低い優先度、ブラウザーに高い優先度を設定でき、バージョン2.0ではこれは不要になりました。 これはbt.tcp_rate_controlオプションによって制御されます。トレントが他のインターネットアプリケーションに干渉しないことがより重要な場合-トレントの最大速度が重要な場合はオンにする必要があります-それをオフにすることは理にかなっています、彼らはこれが時々速度を上げることを公式フォーラムに書きます。
バージョン1.8でもuTPでは常にこれが行われ、TCPトラフィックの速度は2.0でのみチャネル負荷に合わせて調整されることに注意してください。 uTPでは、データが交換されるピアからの応答時間が常に測定されます。 この「ping」が増加し始めるとすぐに、パケット損失が始まるずっと前に、µTorrentは遅くなります。
このため、チャネルは無料ですが、完全に使用されます。 たとえば、別のアプリケーション（ブラウザ）がチャネルのロードを開始するとすぐに-µTorrentでは、応答時間が増加し始め、ブラウザのチャネルが自動的に解放されます。 pingが返されるとすぐに（チャネルが再び空になります）-µTorrentはチャネルの負荷を増やします。 同時に、TCPレベルで発生した場合よりも、不必要なパケット転送がはるかに少なくなります。
ただし、ここで興味深い点があります。それまたはuTPを介して、発信チャネルは95％ブロックされ、TCPなしでのみ-100％ブロックされますが、この5％の違いは同じパケットの同じ不要な転送である可能性がありますチャンネルが目詰まりするが、本当の利点をもたらさないため、チャンネルがわずかにオーバーシュートするとき、私見は常にそうではありません。これは、新しいバージョンがより悪いことを意味します。
議論の中でさえ、 net.calc_overheadキーはしばしば点滅します。 オンになっている場合、速度を調整するときに、サービストラフィックも考慮されます-ブロックの要求、確認、誰が持っているブロックの通知など。 無効にすると、データブロックのみが考慮されます。 そのため、トレントの発信チャネルを実際のチャネルの80-90％に制限することを以前にアドバイスしました。そうしないと、送信中のブロックによって完全に詰まり、ブロックの受信と新しいブロックのリクエストの通知に時間がかかりませんでしたので、ダウンロード速度は深刻な影響を受けました。 繰り返しますが、ワイドチャンネルでは、このオプションをオフにすると速度がわずかに高くなると書いている人もいますが、ベータバグであり、このリリースではすべて問題ないでしょう。
100％確信が持てないような瞬間はまだありますが、uTPにはより多くのサービストラフィックがあるようです。 各小さなデータグラムでは、それがどのブロックであるか、どのトレントから送信する必要があり、TCPは各ピースに署名せずに大きなブロックを送信できます。 ただし、TCP自体の公式トラフィックが存在するため、それがはるかに「経済的」であることは事実ではありません。
一部のプロバイダーによるP2Pトラフィックの「シェーピング」または「カット」などの現象に言及することは間違いありません。 ロシアにとって、これは（これまで？）関係ありませんが、世界中から多くの仲間がいるオープントラッカーでは、uTPの速度ははるかに高速です。
一方、すべてのネットワークハードウェア（モデム、ルーター）、およびすべてのソフトウェアがそれほど多くのUDPトラフィックに依存しているわけではないため、一部のユーザーはこれに不具合を経験しています。 たとえば、ある速度で-定期的に突然ゼロに低下した後、再び回復するか、ゼロから最大まで浮上します。 どうやら、ネットワーク環境のどこかで、UDPに関連する特定のバッファがオーバーフローしていると悪魔は知っています。 繰り返しになりますが、公式フォーラムでは、問題が発生した場合のさまざまなソフトウェアおよびハードウェアとの互換性を検索できます。
注意が必要なその他の「高度な」オプション：
bt.connect_speed -1秒あたりに確立できる新しい接続の最大数（増加する価値があり、80を持っています）
net.max_halfopen-これについて多くのことが書かれており、tcpip.sysパッチで変更する価値がありますが、これはuTPプロトコルではもはや重要ではありません。
net.utp_target_delayは、接続を調整するときの一種のターゲット「ping」です。場合によっては、どこかで400〜500に増加すると、速度が向上します。
peer.disconnect_inactive_interval-データ交換のないピアとの接続が何秒閉じられた後、より多くの人と「悪い」ピアがあるオープントラッカーにとって、またはネットワークのグリッチの場合、切断を迅速に判断して再インストールするためにより重要です。 場合によっては、90〜120に下げるのが理にかなっています。
バージョン2.0は、ベータ版は非常に安定していますが、こちらからダウンロードできます： forum.utorrent.com/viewtopic.php?id=60602
個人的な感情によると、開いているトラッカーからダウンロードするときの古いアルファ1.9では、着信チャネルが1/3でダウンロードされる前に、uTPで2/3でロードが開始されました。 閉じたトラッカーからダウンロードするとき、ブラウザーがスローダウンし始めるようにロードするために使用されたチャネル、および2.0ではすべてが飛ぶ。
µTorrentの新しいバージョンのµTPについて：それは何ですか、どのように、なぜですか？
All Articles