piu lentoの日々 (piu lento days)

IIJの光回線(IPoE)が開通して数日しか経っていないが、問題はない。まだ確定していないが、一番気にしていた、IPoEでもIPv4が遅くなる(DTIの時は混雑時に数Mbpsになることが多々あった)ことは なさそうだ(今までのところ そういうことはなかった)。※

とは言え、ネットの混雑状況に通信速度が影響されるようで、混んでいる(と思われる)時間帯(例: 午後-夜)は空いている時(例: 早朝)より30%近く遅くなることはある。(例: ダウンロード: 90Mbps → 66Mbps)

ただ、早朝でも遅くなったことがあったので、混雑だけではないのかも知れない。

まあ、近頃実感したのだが、速度測定結果で数百Mbpsなどという値を頻繁に見るにつけ、「そういう人が多ければ、いくらフレッツやプロバイダの回線・機器がすごくても、遅くは なるわなあ」と思う。もちろん、常時数百Mbps使っている訳ではないだろうが、利用者が多ければ、平均しても ものすごい転送量・速度になるはずで、混む時はやっぱり遅くなるだろう。

※その後、やっぱり、混む時(例: 休日の夕方)は数Mbpsくらいに遅くなることが分かった。ただ、DTIよりは頻度が少なそうだし、遅くなる時間も短そうだ。 (12/19 18:19)

そして、問題ではないが、いくつか(分かっても何の役にも立たないｗ)謎があるので書く。

• 速度測定サイトfast.comがIPv4でしか繋がらない。 ← 推測だが、fast.comの仕様(速いほうを選ぶ)ではないか。
  • IPoEが開通してから、一度もv6になったことがない。
  • こちらのIPv6(特にDNS)周りに問題があるのかと思って いろいろ調べ、試行錯誤したが、問題はなさそうだ。
  • ブラウザはRFC8305などの"Happy Eyeballs"でv4とv6を切り替えているとのことだが、常に変わらず、ブラウザを変えても変わらないので、それによるものではなさそうで、fast.comが自分でv4にしているようだ。
    • また、/etc/hostsにfast.comのv6のアドレスを書いてv6だけで繋がるようにしてもv4で測定されたので、ブラウザの機能によるものではなさそうだ。
    • 推測ではあるが、RFC8305より もっと細かい応答時間・速度差でv4を選んでいるように思う。 (→ 参考資料: ただし、v4/v6の選択に関してはNetflixの原典には明記されていないので、推測だと思われる。)
      • 参考: RFC8305の推奨しきい値(v6/v4の時間差): 名前解決: 50ms, 接続: 250ms
    • 実際、Firefoxで他のサイトにアクセスする場合、v6も可能なら ほとんどv6が使われる(もちろん、いつも調べては居ない)。
  • このこと自体は問題ではないのだが、そのために、今まで同サイトをv6の速度測定に使っていたのが駄目になったので、別のサイト(iNonius)を探して使っている。
    • iNoniusではv4とv6の速度を両方測れる。その時々でv4とv6で優先されるものが異なるのは、ネットの混み具合によるのかと想像している。
      • そのv4とv6の選択は、上記のブラウザの機能によるようで(おそらく、名前解決の時間で決まるのだろう)、一旦どちらかに決まったらしばらく固定されるようだ。そのため、別のブラウザでは別の選択になることもある。
  • 以上のことから、IIJのIPoEのIPv4は結構空いていて(注: PPPoEは駄目)、v6と同じくらいの応答時間・速度が得られるのではないかと想像している。
    • 実際、iNoniusで表示される応答時間(RTT)のv4とv6の差は数msしかない(その代わり、ジッタはv4が大きいことが多い。 ← v6より多く利用されるためだろうか)。
    • また、v6のホップ数(途中の段数)がv4より多いために、fast.comはv4を優先するのかも知れない。
• ルータのFWの(勝手な)off/onがなくなった。 ← MAP-EとDS-Liteの違い?
  • DTIの時は、使っているルータ(I/Oデータ WN-SX300GR)に ほぼ毎日、ファイアウォールがoff/onしたというログが出ていたが、ここ数日は出ていない。
    • 以前、メーカーに問い合わせたら「回線の品質によるのでは」という答えが来て怪しいと思って居たが、やっぱりそうではなかったようだ。
  • これから出るのかも知れないが、出なくなったとしたら、v6にv4を載せる方式(MAP-EとDS-Lite)の違いによるのではないかと思う。
    • MAP-Eは定期的に何かをしていて、それでルータの何かの処理が再起動したりするのではないか。
• スリープからの復帰時に、既存のIPv6一時アドレスが まだ有効なうちに新しいアドレスが割り当てられる。 ← プロバイダ側のルータの違い?
  • 今朝、PC(Linux Mint)をスリープから復帰させたら、なぜか、IPv6一時アドレスが2つになっていた。
    • 普通は1個だけ有効で、残りは無効(deprecated)なのだが、今は両方ともアクティブだ。
    • 実用上の問題はなく、2つのうち新しいアドレスが使われている。
  • これは上のルータのFWのoff/onに似て、プロバイダ側のルータの違いによるのかと想像している。また、MAP-EとDS-Liteの違いも関係しているのかも知れない(それらはv4を載せる仕組みなので、直接の関係はないだろうが)。
  • 書いてから不安になったが、実は以前もそうだったのかも知れない。PCが復帰する時にはDHCPが動くはずで、それで新しいアドレスが割り当てられるのは普通のことだ。
    • ああ、IIJのルータのDHCPのリース時間がDTIより短いのかも知れない。
  • → (12/13 7:31) 今朝の復帰時はアドレスは増えていなかったので、DHCPのリース時間の関係だったようだ。
• fast.comでIPv4アドレスの接続元地域が分散している。 ← IP-Geoloc DBの問題?
  • おそらく表示(IPアドレス-地域DBの情報がおかしい?)だけの問題だろうが、fast.comで表示される接続元の地域が日本中に分散している。県内や隣の県も多いが、調布や柏崎や旭川や函館などということもある。それでも遅くないので良しであるｗ
    • もしかして、接続地点の混み具合によって本当に分散させているのだろうか? ただ、それで速くなるのかは不明だ。もしそれが効いているのなら、IIJはすごいと思う。
      • でも、さすがに それはない気がする。実際、遠い地点なら応答時間が長くなりそうなものだが、ほとんど一定だ。
      • 実際、"IP geolocation"で検索して出て来る いろいろなサイトでの地域表示は、同じIPアドレスなのに「てんでバラバラ」だから、当てにならない感じだ。
  • その後、同じIPアドレスでも実行する回によって表示される地域名が異なるので、どうやら、fast.comの参照するDBがおかしいようだ。あるいは、IPアドレスでない何か(経路?)で地域を割り出している? (それでも合ってないがｗ)
    • そういうところから見ると、(一部で「速過ぎる」と言われているようだが)fast.comの速度測定は それほど確かでないのかも知れない(まあ、この件は関係ないとは思うが)。

 

PS. fast.comが必ずIPv4でアクセスされる件で、フレッツのIPv6のDNSサーバ(2404:1a8:7f01:a::3, -:b:-)が悪いのかと思って無効にしてみたが関係なかった。その時は、このサーバは役に立たない(フレッツ関係のドメイン(iptvf.jp?)だけサポートしている)と思い込んで一旦無効にしたのだが、良く調べたらちゃんと使えることが分かった。 (これを書いている時に、念のために確認して分かった。)

それで、IIJのDNSサーバはv4だけで、それはIPoE(またはPPPoE)が使えないとアクセスできなさそうで ちょっと弱い気がしたので、いざという時のために残すことにした。

まあ、IPoEが使えない(≒ v6のアドレスがもらえない?)とかDNSサーバが停まっている状況で外(インターネット)に出られる可能性は低そうだが・・・

なお、フレッツのDNSサーバはNetworkManagerの設定で無効にすることができる。: 具体的には、IPv6の設定で、Methodを"Automatic, addresses only"にすると、IPアドレスと経路情報は自動設定するが、DNSサーバの設定はしないようになる。 (12/13 14:37)

↓

更に考えたら、Linuxの設定やNW構成により、どうやらIIJのDNSサーバは使っておらず、フレッツのだけが使われているようだ。というのは、僕のPCのDNSサーバはデフォルトでルータになり(そこに上記のフレッツのサーバが自動追加される)、ルータはフレッツのサーバを参照している(推測)ためだ。

結局、IIJのDNSサーバのアドレスは どこからも取得されず、設定もされないので、使われていない。それで、やっぱり、PCでフレッツのDNSサーバを設定するのは無駄(ルータだけで充分)なようなので、(上に書いた手順で)無効にした。

いざという時のことを考えるなら、それにIIJのDNSサーバを追加することだが、まあ、そこまでは要らない気がする。 (12/13 15:24)

↓

どうでもいいことだったが、いろいろ考え、DNSサーバとしてローカルのルータを指定すると、PCからはv4でしかDNSサーバへの経路がなくなるのと、ルータ内でv4→v6変換が行われる(元々v6なのに馬鹿らしいし、それほど速くなさそう)のが ちょっと不満だったので、以下のようにNetworkManagerに指定して落ち着くことにした。

• v4: IIJのDNSサーバ
• v6: 自動設定(→ フレッツのDNSサーバ)

実際には、PC内のアプリからキャッシュサーバ(systemd-resolved)への経路はv4だけなので、それほど大きな意味があるとは思えない。効果が発揮されるのは、フレッツかIIJのDNSサーバが落ちた場合だが、そういう時に まともに外部にアクセスできるとも思えないので、まあ、単なる自己満足であろう。 (12/14 6:31)

 

(2023/5/21 NetworkManagerの誤字を修正)

近頃、ネットのアクセスがすごく遅い気がしていたのだが、(良くあることだが)たまたま混んでいるせいだと思って居た。しかし、今朝は どうも違うような気がしたので、スピードテストをしてみると、テストが始まるまでは すごく遅いものの、スピード自体は問題なかった。

それで、DNSが遅いのではと思って調べたら、どうやら、僕が使っているDNSサービスのQuad9(9.9.9.9)は10/16(おそらくUTC)頃から急に遅くなったようだ。 (→ 参照: "Not found"になる場合あり) 以下に、DNSPerf("Not found"になる場合あり)で調べた、Quad9と有名なCloudflare(1.1.1.1)の応答速度変化を示す。

他も見てみると、Quad9同様に近頃遅くなったものが多いので、世界的な問題なのだろうか? 何かの攻撃・活動?? まあ、そういうことは僕は どうでも良くてｗ、とりあえず遅いのを解消したいので、PCのDNSサーバ設定をCloudflareに変更した。当然ながら、スピードテストの開始が速くなり、他のwebの表示も気持ちいいほど速くなった。

おもしろかったのは、僕のこのブログの表示は いつも遅い(でも、下に出る表示時間はそれほど遅くない)と思って居たのだが、それも ほぼ一瞬で出るようになったことだ。「今までの遅さはなんだったんだ!」と思ったｗ

同様に、ネットが妙に遅く感じることがあったのは、Quad9が遅いこともあったのではないか(もちろん、ネット自体が遅いことが ほとんどだったと思う)。

その後、dnspingというプログラム(パッケージdnsdiagでインストールする)でDNSサーバの応答時間が測れることが分かって調べたら、Quad9の応答時間はCloudflareやGoogleの約2-5倍であることが分かった。なお、Cloudflareは速いが変動があり、Googleは言われるほど速くなかった。以下にいくつかの測定結果を示す。

Quad9: 平均 222ms

--- 9.9.9.9 dnsping statistics ---
4 requests transmitted, 4 responses received, 0% lost
min=187.845 ms, avg=222.095 ms, max=271.483 ms, stddev=40.576 ms

Cloudflare: 平均 118ms

--- 1.1.1.1 dnsping statistics ---
4 requests transmitted, 4 responses received, 0% lost
min=23.369 ms, avg=117.756 ms, max=172.085 ms, stddev=70.577 ms

同2回目: 平均 43ms
--- 1.1.1.1 dnsping statistics ---
6 requests transmitted, 6 responses received, 0% lost
min=23.226 ms, avg=42.777 ms, max=138.602 ms, stddev=46.946 ms

Google: 平均 132ms
--- 8.8.8.8 dnsping statistics ---
5 requests transmitted, 5 responses received, 0% lost
min=22.459 ms, avg=132.160 ms, max=232.088 ms, stddev=101.970 ms

同2回目: 平均 77ms

--- 8.8.8.8 dnsping statistics ---
6 requests transmitted, 6 responses received, 0% lost
min=22.410 ms, avg=76.629 ms, max=196.265 ms, stddev=83.767 ms

それから、Quad9はどうも駄目になっている感じの記事もあった。最初は見出しからドイツ語だと思って(本文は英語だったｗ)拙い翻訳版しか見ていないので詳細は不明だが、良くある資金不足だろうか。

 

そんな状況を眺めつつ考えたら、べつに外部のDNSサーバでなくてもルータのでいいような気がした。というのは、Quad9は安全面で良い(例: 危険なサイトをブロックする)から使っていたのだが、Cloudflareにはそういう機能はないので、速度以外に選ぶ理由はない。が、速度ならルータのサーバ(プロバイダのをキャッシュする)が一番速いはずだ。

なお、Quad9の危険サイトブロック機能は惜しいが、今まで働いたことがないので なくてもいい気がする。ブラウザにも、危険なサイトから保護する機能はある。

書いたあとで思い出したが、たまに、なぜかCloudflareの「ブラウザをチェックしています」という画面が出ていたが、Cloudflareにも似たような機能があって、それだったのか。ということは、全然気付いて居なかったけどQuad9が使われていなかった(ダウンとみなされてCloudflareに切り替わって居た)ことが多そうだ。謎だ・・・

とすれば、Cloudflareでも ある程度は安全性の向上が期待できそうだ。ただ、上の変な画面が出る(実はこれ、最近まで危険なサイトかと思って閉じていたよｗｗｗ)。 ← 調べたら、これはCloudflareのDNSでなく、CDNの機能のようなので、やっぱり、CloudflareのDNSにするメリットは(僕には)余りない。

測ってみたら、以下のように、平均1.3msと爆速だった(キャッシュされたサイトに限る)。

--- 192.168.0.1 dnsping statistics ---
5 requests transmitted, 5 responses received, 0% lost
min=1.212 ms, avg=1.273 ms, max=1.329 ms, stddev=0.044 ms

キャッシュされていないサイトはプロバイダのサーバが参照されるが、近いせいもあってCloudflareなどと遜色なかった。以下にdnspingの結果を示す。

プロバイダ(DTI): 平均 61ms

--- 2404:1a8:7f01:b::3 dnsping statistics ---
5 requests transmitted, 5 responses received, 0% lost
min=22.127 ms, avg=61.362 ms, max=209.331 ms, stddev=82.741 ms

同2回目: 平均 52ms

--- 2404:1a8:7f01:b::3 dnsping statistics ---
6 requests transmitted, 6 responses received, 0% lost
min=21.448 ms, avg=52.380 ms, max=191.389 ms, stddev=68.169 ms

あと、Cloudflareがうたうメリットの一つにアクセスが記録されないからプライバシー面で良いことがあるが、プロバイダはDNSだけでなく アクセス履歴はなんでも記録できるから、DNSアクセスだけ記録しないことにメリットはないと考えた。

それで、PCのDNS設定をルータに変えた。気のせいか、このブログの表示が更に速くなった気がする＾＾

なお、ルータは代替DNSサービスやv6のDNSサービスを持たないので、代替サーバ※はCloudflareにした。

※ PS2に書いたが、上(NetworkManagerの設定)は実際には「代替」サーバでなく、ルータ(またはプロバイダ)のサーバと対等な「追加」サーバとなっていた。良く調べなかったせいもあるが、この辺りは 見た目ほど単純でなく、中は すごく こんがらがっていて誤解しやすいので、今まで分からなかった。 (10/23 18:43)

僕のルータ(I/Oデータ WN-SX300GR)が残念なのは、IPoE接続(MAP-E)の時はDNSサーバを変更できないことだ。もしできれば、ルータのキャッシュにない時はCloudflareなどにアクセスできるのだが。まあ、大きな問題ではない。あと、プロバイダのDNSサーバから送られてくるのか、resolv.confにフレッツ用の設定らしきもの(例: search flets-east.jp iptvf.jp)が入ってしまうが、気にしなければ良いｗ

それから、スマフォ(Andorid)は簡単にはDNSサーバが変更できないため元々ルータだったので、何も変更は要らなかった。

 

結局、「ごく普通の設定」が最適だった訳で、僕が良くやる「とりあえずいじる」の「過ぎたるは−」的な失敗ではあったｗ

 

それにしても、数年前から「CloudflareやGoogleにするとネットが速くなる」って良く見ていたが、本当なのだろうか? (国内にもいくつかサーバがあるのだろうが、)わざわざ遠いサーバを参照しても、それに見合うとは思えない。プロバイダのDNSサーバが貧弱とか混んでいる場合の話だろうか。後者だったらネット自体も遅くなる気がする。

 

PS. 僕のPCのDNS検索が遅かった件については、DNS検索結果をPC内でキャッシュしないようにしているせいもあることに気付いた。通常はキャッシュする(DNSサーバのIPアドレスが自分のPCになる)ようだが、確かv6対応にした時に何か問題があって止めた気がする(が、詳細を思い出せない)。

→ 少し調べたら、どうやらdnsmasqをNetworkManager経由で使っていたのを2020年の年末に止めたようだ。その経緯をノートで調べたら、その時は楽天モバイル(ポケットWi-Fi)を使おうとしていて、光のプロバイダのDNSサーバの設定が競合してDNS検索が遅かった(今回のようにブラウザの表示が遅かった)ので無効にしたことが分かった。もう楽天モバイルは使わないので戻してもいいはずだ。が、ちょっと面倒だｗ まあ そのうちやりたい。

本文に書いたようにルータがキャッシュしているので戻すメリットは余りないが、(キャッシュで ある程度高速化できるので、遅い)Quad9が再び使えるようになることか。まあ、それにどのくらい価値があるか・・・ (そもそも、Quad9は楽天を使う時に始めたので、特に必要はない。)

↓

(15:40) とりあえずやってみたら、またハマったｗ

DNSキャッシュとして最初から使われていたのはdnsmasqでなく、systemd-resolvedだった。どうも設定ファイルにdnsmasqの痕跡がなくておかしいと思った。dnsmasqは動いたのだが(これも分かりにくいことがあって、ちょっと苦労した)、元々のものがいいのでsystemd-resolvedに戻そうとしたら、DNSが参照できなくなって苦労した。

こうなるとネットの検索すらできないので、難儀した。それで一時的にdnsmasqを有効にした。

結局、ここでも楽天のための設定変更が悪かった。/etc/systemd/resolved.confで DNSStubListener=no にしていたために、プログラムがsystemd-resolvedでDNS検索しても応答がなかった。

修正したら うまく行き、キャッシュされたホストについては概ね0.5ms以内に応答が得られるようになったので満足した。(というか、単に元に戻しただけなのだがｗｗｗ)

なお、DNSサーバはプロバイダのものにした(ルータから渡される情報をそのまま使うことにして、何も設定していない。 → この場合、v6のサーバが使われるようだ)。

PS2. 今調べたら、Quad9の速度が回復しているようだ。とすれば、上に書いたローカルなDNSキャッシュ機能を使えば、速度低下を起こさずに使えそうだ。そうする意味は、気休め程度にQuad9による安全性が期待できるだけだが、どうしたものか。 (と、振り出しの近くに戻る?ｗ)

↓

(18:32) 使えるものは使う主義なので、結局、再びQuad9を使ってみることにした。今度はちゃんとキャッシュが効いて、最初の検索以外は遅くない。もしまた遅くなったら戻せば良いのだ(でも、その時は きっと忘れていることだろうｗｗｗ)。まあ、「懲りない奴」ってことで・・・

↓

(10/22 15:50) やっぱりQuad9は遅い(定常状態で遅い)。いくらキャッシュしても、ヒット率が低い(例: 24%)ので、全体的な速度は低下する。特に、ブラウザで最初にページを開く時は(キャッシュがヒットせずに)遅くてイライラするので止めて、プロバイダのサーバにした。大体Quad9の10倍速く、再び高速・快適になった。

PS2. 僕のPCのDNS検索が遅かった件について、更に別な関連することが見付かった。ブラウザ(Firefox)の設定でDNS over HTTPSをQuad9に設定していた。そのため、webページの表示が遅かったのはOS(Linux)の設定とは関係だったようだ。OSの設定を変更して速くなったのは、たまたま同じ頃にQuad9が回復したせいなのだろうか。

あと、OSのDNSの設定も複雑で、NetworkManagerとsystemd-resolvedを使っている場合、DHCPで取得したDNSサーバのアドレス(= プロバイダのもの)も使われるのだが、それらと自分で追加設定したものが並列に有効で(早いもの勝ち?)、実際にどれが使われるかが不明だ(見ていると、時間が経つと変わるようだ)。

マニュアルもなかなか意味不明で、いろいろ設定しても なかなか意図したように(DHCPのDNSサーバアドレスを無視する)は動かない。試行錯誤した結果、NetworkManagerのv6の設定で"Automatic, addresses only"というモードにすると、DHCPではIPアドレスだけ設定し、DNSなどは使われず、systemd-resolvedにも送られないことが分かった。

DHCPで得られる情報のIPアドレス以外(DNS以外は不明)は不要なのかという疑問はあるものの、それで使ってみて、まだ大きな問題はない。 (10/22 12:24)

注: PSに追記したが、Quad9を使うのを止めたため、今は元の"Automatic"の設定に戻した。 (10/22 22:03)

PS3. 更に、DNS over TLSを使うのも一苦労だった。resolved.confでDNSOverTLSを設定するだけでは駄目で、DNSにサーバのIPアドレスだけでなく、"#"でホスト名を追加する必要があった(例: DNS=9.9.9.9#dns.quad9.net)。(→ 参照1, 参照2)

ちょっと凝ったことをしようとすると、なかなか大変だ。 (10/22 15:03)

注: PSに追記したが、Quad9を使うのを止めたため、今はDNS over TLSは使っていない。 (10/22 22:03)

 

(10/23 18:43 少し補足)