私が使うtcpingは、TCPポートにpingを送信して、コンピュータの特定のポートへの接続を確認します。特定のアドレスとポートの平均応答時間は50ミリ秒通常の接続で。今度は別のアドレスからダウンロードを開始しますインドファイルを分割して同時にダウンロードします。ping応答時間は約1500ミリ秒ダウンロードを一時停止すると、応答時間が元に戻るので、ダウンロードによって応答時間が長くなったのは確かです。50ミリ秒。
登録されたアドレスとポートでの応答時間の増加を防ぎたいです。
使いたくないネットリミッターまたはネットバランサー。
私も試してみましたこれWireshark をチェックしたところ、DSCP は設定されていると確信していますが、問題は解決されていません。
答え1
アップストリームまたはダウンストリームのネットワーク帯域幅が飽和してレイテンシが急増する場合は、ネットワーク パス内のいずれかのボックス (おそらくブロードバンド モデムまたは ISP の CMTS または DSLAM) に、バッファブロートと呼ばれるよく知られたバグがあることを意味します。このバグでは、ボックスでの過剰なバッファリングによってレイテンシが増加するだけでメリットはありません。
バッファブロートの修正方法は、バグのあるデバイスのキューイング アルゴリズム (キュー ディシプリン、ネットワーク スケジューラとも呼ばれます) を、FQ-CoDel などの遅延を考慮したスマート キューイング アルゴリズムにアップグレードすることです。
問題のある実際のボックスを修理できない場合は、ネットワークの先頭に FQ-CoDel を備えたボックスを設置し、そのトラフィック シェーピングを調整して、アップストリームとダウンストリームの両方向でわずかなボトルネックになるようにすることで、問題を回避できます。こうすることで、FQ-CoDel が起動し、バグのあるボックスでバッファ キューが肥大化する前に、TCP 輻輳制御が機能するようになります。
LEDE (旧 OpenWrt) などのオープン ソース ルーター ファームウェア ディストリビューションを使用してこれを自分で実行することもできますが、ターンキー ソリューションが必要な場合は、evenroute.com の IQrouter を検討してください。このソリューションは、1 日を通して帯域幅のシェーピングを自動調整し、スループットを最大化しながら遅延を最小限に抑えるようです。
バッファブロートについて知らない多くの人は、レイテンシの急増はネットワーク リンクの飽和による自然な結果であると誤って想定しています。また、QoS を微調整してバッファブロートを回避し、ブロートを引き起こしている大きなフローよりも一部のフローを優先させようとする問題のある試みをする人も多くいます。しかし、バッファブロートを直接解決する方がはるかに優れています。なぜなら、ブロートを引き起こしていた大きなフローも含め、すべてのフローが改善されるからです。
答え2
各インターネット接続には、ユーザーからインターネットへ、およびその逆の 2 つの方向があります。各方向は、QoS とパケットの通過ルートに関して独立しています。
送信パケットに優先度を設定しても、受信パケットの優先度は変わりません。受信パケットの優先度と QoS は、引き続き ISP によって制御されます。
ISP 側でトラフィックを優先するオプションがある場合は、これを試してください。それ以外の場合は、着信する「ベスト エフォート」トラフィックをレート制限して、ping やその他の「高優先度」トラフィック用に常に帯域幅を確保することが唯一のオプションです。
残念ながら、これは解決策ではありませんが、問題を理解するのに役立つことを願っています。