pslaboが試したことの記録

はてなダイヤリーからはてなブログに引っ越してきました

この日記は現在実行中の減量記録を含む個人的なメモとして始めましたが、最近はコンピュータやガジェット、ハック、セキュリティネタのほうがメインになっております。

はてなダイヤリー時代はカテゴリ分けが適当だったのですが、これはそのうち直します。


nanaco や WAON の Apple Pay 対応時期について考察する

日本でのプリペイド式 IC カードの Apple Pay 対応は Suica / PASMO しか行われておらず、nanaco, WAON, Edy 利用者は引き続きプラスチックカードを持ち歩く必要がありましたが、nanaco, WAON について Apple Pay 対応予定であることが発表されました。

そこで nanaco, WAON の対応開始時期について考察してみることにします。これを考察する際の参考になるのは、PASMO や Suica の Apple Pay 対応時のスケジュール感です。

PASMO の場合はどういうスケジュールだったか？

PASMO の Apple Pay 対応については、2020年8月6日(木)にプレスリリースが出ています。そして2020年10月6日(火)に提供開始となりました。つまり、情報告知から 2 ヶ月後のサービス開始。

このときの動作要件は、iOS 14 をインストールした iPhone 8 以降、または Watch OS 7 をインストールした Apple Watch Series 3 以降でした。

https://www.pasmo.co.jp/pressrelease/pdf/apple_PressRelease_August6%2C2020.pdf

https://www.pasmo.co.jp/pressrelease/pdf/apple_PressRelease_October6_2020.pdf

Suica の場合はどうだったのか？

2016年9月8日(月)のプレスリリースにて iPhone 7 や Apple Watch Series 2 で利用可能となることが発表され、2016年10月25日(火)にリリースされたIOS 10.1から Suica が Apple Pay で利用可能となりました。

https://www.jreast.co.jp/press/2016/20160906.pdf

nanaco、WAON の場合はどうなるだろうか？

基本的に類似のパターンで利用できるようになると想定した場合は、2021年10月5日(火)、10月12日(火)、10月19日(火) あたりに正式サービスが開始されるものと見込まれます。

iOS15 や watchOS 8 がリリースされた後の日付になると見込まれるため、利用の前提として iOS 15 や watchOS 8 が必須となる可能性が高そうです。対応機種については何とも言い難い感じではありますが、あと 2 ヶ月待てば nanaco, WAON は iPhone や Apple Watch で利用可能となりそうです。

ちなみに、nanaco, WAON とも、プレスリリース文書のスクリーンショットを見ると時計の時刻が 9:41 であることが確認できます。

https://www.nanaco-net.jp/material/pdf/release/pdf/2021/20210810.pdf

https://www.aeon.info/wp-content/uploads/news/pdf/2021/08/210810R_1.pdf

この 9:41 という時刻は Apple が広告に用いるスクリーンショットの時刻としてお約束の表示となっている表示です。

https://www.google.com/search?q=9%3A41+Apple

Edy はどうなる？

現時点で Edy の Apple Pay 対応に関するリリースが出ていないということは、nanaco, WAON と同時期に Apple Pay で利用できるようになるのは期待できない感じがあります。

OpenWrt ベースのルータ GL.iNet GL-MT1300 レビュー（夏場の連続稼働)

OpenWRT

GL.iNet GL-MT1300 を購入して2ヶ月が経過したのですが、ふと気がつくとインターネット接続の速度が低下していたので追加レビューします。

速度低下の状況

なんとなく速度低下が起きているような気がしたのですが、実際に計測してみると、次の状況でした。

  • GL-MT1300 の WiFi または LAN 側に収容した機器で fast.com の速度計測を行うと、6Mbps 程度しか速度が出ない

これに対して、フレッツ光回線の ONU に直結した機器で fast.com の速度計測を行うと 400Mbps 程度のスループットが得られていました。

これはどうみても GL-MT1300 で速度低下が発生しています。あくまでトラベルルータなので据え置き用で夏場に長期間運用するのは厳しいのかもしれません。

GL-MT1300 を再起動してみる。

管理画面からの再起動を実施してみましたが、状況変わらず。

WN-AC1600DGR2 に戻してみる

無線部分を無効に設定した WN-AC1600DGR2 で LAN 側に有線接続した状態で fast.com の計測を行うと 200Mbps 程度のスループットが得られました。

やはり、GL-MT1300 が原因で速度低下が発生していた模様です。発生原因が熱の問題であるかどうかの検証を厳密に行った訳ではありませんが、速度低下が発生した場合には機器をクールダウンしたり、空調の効いた場所に配置するなどしたほうがよさそうです。

Windows 10 の今後のサポートと提供内容について考察する。

Windows

Windows 11 が発表されましたが、「Windows 10 は最後の Windows と言っていたのに、最後じゃなかったのか？」みたいな話や、「Windows 11 をインストール可能なハードウェア要件に適合するのは直近3年くらいにリリースされた H/W に限られるのでは」みたいな話があるので、自分なりに内容を整理しようと考えました。

なぜ Windows 11 をリリースするのか。

これについては、ASCII の以下の記事の内容が参考になります。

https://ascii.jp/elem/000/004/060/4060506/

Windows を実行できる PC に対する線引きを行う際に、Windows 10 のままでは線引きがわかりづらいです。実は Microsoft は Windows 10 Creators Update (バージョン1703、ビルド15063) にて、一部の CPU (Clover Trail) をサポート対象から外したという前例があります。しかし、Windows 10 という製品名のママだと、このような線引きが行われたことが非常にわかりづらいですね。

https://www.sbbit.jp/article/cont1/35047

従って、今回のリブランディングのように、ハードウェア要件の線引きを明確にすることにより、その OS で利用可能なハードウェア要件がわかりやすくなります。

Windows 10 をインストールした PC はいつまで使えるのか？

Windows 11 でハードウェア要件の線引きを改めたということを考えると、今後の Windows 10 の機能更新プログラムでハードウェア要件をさらに絞ることはしないのではないかと考えます。

そして機能更新プログラムの内容は Windows 11 の機能を必要最低限の範囲に限ってバックポートするようなものになるような気がします。

そもそも Windows 10 には 2 種類のアップデート（品質更新プログラム、機能更新プログラム）が提供されており、機能更新プログラムを適用している場合は引き続き品質更新プログラムを利用可能でした。

しかし Windows 10 21H2 という機能更新プログラムとして開発されていたバージョンが Windows 11 にリブランディングされました。

https://pc.watch.impress.co.jp/docs/news/1333729.html

そうすると、Windows 10 21H2 はどうなってしまうのか、ということが気になりますが、こちらの記事によると Windows 11 の一部機能を取り入れた形で Windows 10 21H2 としてリリースされるという趣旨の記載があります。

https://pc.watch.impress.co.jp/docs/news/1333963.html

21H2 以降の Windows 10 機能更新プログラムの提供についてはなんとも判断しづらいのですが、少なくとも Windows 11 のリリースに伴い、Windows 10 のサポートは 2025/10/14 まで、という線引きが明確になりました。

これについて、Microsoft のサイトの情報を見ると、次のように記載されています。

https://docs.microsoft.com/ja-jp/lifecycle/products/windows-10-home-and-pro

マイクロソフトは、2025 年 10 月 14 日まで、少なくとも 1 つの Windows 10 半期チャネルを引き続きサポートします。

従って、今後提供される機能更新プログラムを引き続きインストールする限りは 2025 年 10 月まではサポートが提供されます。

Windows 10 21H2 は少なくとも 2022 年 10 月まではサポートが提供されるはずなので、万が一、21H2 以降の機能更新プログラムが一部のハードウェアにインストールできないような線引きが行われたといても 2022 年までは利用できます。

では、仮に新たな線引きが今後の Windows 10 機能更新プログラムで実際された場合に線引きの対象となるハードウェアについて考えてみると、前回の線引きは Clover Trail (2012年) ですから、これ以降の CPU についてどこかの時点で足切りが行われることになると見受けられます。

ただ、ここで新たな足切りを設定すると、ハードウェアによっては10年を経過する前に利用できないという状況となりうるので、わざわざ新たな線引きを設けることはしないのではないかという気がします。

また、Windows 11 が直近 3 年程度のハードウェア縛りを設けている状況に対して Windows 10 側で新たに別の線引きを積極的に行う理由もないように思います。

微妙に不満が出るとしたら 4 年前のスペックの H/W を所有している場合かもしれませんが、そのスペックの機材で Windows 10 をサポート終了まで使い続けたらトータルで 8 年程度は使っていることになりますから、利用可能な期間としては十分すぎるようにも思います。

OpenWrt ベースのルータ GL.iNet GL-MT1300 レビュー（無線部分の性能測定）

OpenWRT

OpenWrt ベースの市販ルータである GL.INet GL-MT1300 を先日購入した際に、WAN側とLAN側をまたぐ有線LAN接続のスループットを iperf3 で計測してみました。

pslabo.hatenablog.com

今回は LAN側の有線LAN と WiFi の間のスループットを計測してみます。

事前準備

  • LAN側の有線LANには、MacBook Pro + USB3 イーサネットアダプタを接続し、iperf3 のサーバーとして使用します。クライアントからは IP アドレスを指定して接続するため、NIC に割り当てられた IP アドレスを確認しておきます。
  • LAN側のWiFi (5GHz) には、iPhone XR を接続し、iperf3 のクライアントとして使用します。
  • MacBook Pro には iperf3 をインストールします。
  • iPhone XR には HE.NET Network Tools をインストールしておきます。

※ iperf は Windows 版もあるので、Windows PC でも同様の調査は可能です

計測

  • MacBook Pro で "iperf3 -s" を起動します。
  • iPhone XR で HE.NET Network Tools を起動し、iperf のメニューから iperf3 を選択します。
  • 一定量の送信を行うほうが適切な計測が行えるため、ここでは 500M の送信を行うように設定します。
  • "iperf3 Server" に MacBook Pro の IP アドレスを入力して Enter を押すと計測が始まります。

計測結果は次の通りであり、概ね 400Mbits/sec のスループットが出ていることがわかります。

-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.8.117, port 63246
[  5] local 192.168.8.160 port 5201 connected to 192.168.8.117 port 63247
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  47.9 MBytes   402 Mbits/sec                  
[  5]   1.00-2.00   sec  43.5 MBytes   365 Mbits/sec                  
[  5]   2.00-3.00   sec  43.5 MBytes   365 Mbits/sec                  
[  5]   3.00-4.00   sec  45.2 MBytes   379 Mbits/sec                  
[  5]   4.00-5.00   sec  49.0 MBytes   411 Mbits/sec                  
[  5]   5.00-6.00   sec  46.1 MBytes   387 Mbits/sec                  
[  5]   6.00-7.00   sec  49.1 MBytes   412 Mbits/sec                  
[  5]   7.00-8.00   sec  51.1 MBytes   428 Mbits/sec                  
[  5]   8.00-9.00   sec  44.1 MBytes   370 Mbits/sec                  
[  5]   9.00-10.00  sec  44.2 MBytes   371 Mbits/sec                  
[  5]  10.00-10.48  sec  23.1 MBytes   406 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.48  sec   487 MBytes   390 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

考察

iPhone XR の WiFi の仕様は Apple のドキュメントによると次の通りです。https://support.apple.com/ja-jp/guide/deployment-reference-ios/apd1c22e481c/web

802.11規格、名称、周波数 最大PHYデータレート 最大チャンネル帯域幅 最大MCSインデックス 最大空間ストリーム
ac@5 GHz 866 Mbps 80 MHz 9（VHT） 2/MIMO
a/n@5 GHz 300 Mbps 40 MHz 7（HT） 2/MIMO
b/g/n@2.4 GHz 144 Mbps 20 MHz 7（HT） 2/MIMO

また、GL-MT1300 の WiFi の仕様は次の通りです。https://www.gl-inet.com/products/gl-mt1300/

Protocol IEEE 802.11a/b/g/n/ac
Wi-Fi Speed 2.4GHz(400Mbps), 5GHz(867Mbps)

従って、iPhone XR と GL-MT1300 の組み合わせの場合、5GHz の周波数帯で 802.11ac、チャネル帯域幅 80MHz での通信が行えることがわかります。

802.11ac でのスループットが約 400Mbits/sec 程度出ているなら、まあまあ悪くないと思います。

WiFi - DS-Lite の速度計測

WiFi - DS-Lite の速度を speedtest cli で計測してみました。MacBook Pro 13inch retina (2013) の場合はこのくらいの速度です。

$ speedtest -s 24333

   Speedtest by Ookla

     Server: Rakuten Mobile, Inc - Tokyo (id = 24333)
        ISP: Internet Multifeed Co.
    Latency:    10.60 ms   (1.79 ms jitter)
   Download:   197.66 Mbps (data used: 264.3 MB)                               
     Upload:    89.88 Mbps (data used: 157.2 MB)                               
Packet Loss:     0.0%

iPhone XR で計測した場合は、最もよい場合でこれくらいの速度が出ていました。

Download Mbps
246.16

Upload Mbps
88.80

Ping 11 ms
Jitter 1.7 ms
Packet Loss 0%

これくらいの速度が出ていれば、概ね不満はないかと思います。

GL.iNet GL-MT1300 (Beryl) VPN 無線LAN セキュリティ対策 トラベル ギガビット ワイヤレスルーター、デュアルバンドAC1300 400Mbps (2.4GHz) + 867Mbps(5GHz) Wi-Fi、ポケットサイズ ホットスポット、IPv6対応、Tor、NextDNS、MicroSD スロット、USB3.0 Wi-Fi 中継 USBテザリング 日本語設定画面

GL.iNet GL-MT1300 (Beryl) VPN 無線LAN セキュリティ対策 トラベル ギガビット ワイヤレスルーター、デュアルバンドAC1300 400Mbps (2.4GHz) + 867Mbps(5GHz) Wi-Fi、ポケットサイズ ホットスポット、IPv6対応、Tor、NextDNS、MicroSD スロット、USB3.0 Wi-Fi 中継 USBテザリング 日本語設定画面

  • GL.iNet
Amazon

OpenWrt ベースのルータ GL.iNet GL-MT1300 レビュー（有線部分の性能測定）

OpenWRT

OpenWrt を市販ルーターで利用する場合は技術基準適合証明の問題があるので Wi-Fi 利用が憚られますが、最初から OpenWrt ベースのファームウェアを利用すれば技適の問題を気にせずに利用できるという認識です。

そこで適切な製品を探していた所、GL.iNet の製品は技適を通っているようなので、GL-MT1300 を試してみることにしました。これは本来はトラベルルータなので LAN 側の NIC が 2 つしかないなど、据え置き用として利用する場合に口が足りない場合は Hub が必須です。

GL.iNet GL-MT1300 (Beryl) VPN 無線LAN セキュリティ対策 トラベル ギガビット ワイヤレスルーター、デュアルバンドAC1300 400Mbps (2.4GHz) + 867Mbps(5GHz) Wi-Fi、ポケットサイズ ホットスポット、IPv6対応、Tor、NextDNS、MicroSD スロット、USB3.0 Wi-Fi 中継 USBテザリング 日本語設定画面

GL.iNet GL-MT1300 (Beryl) VPN 無線LAN セキュリティ対策 トラベル ギガビット ワイヤレスルーター、デュアルバンドAC1300 400Mbps (2.4GHz) + 867Mbps(5GHz) Wi-Fi、ポケットサイズ ホットスポット、IPv6対応、Tor、NextDNS、MicroSD スロット、USB3.0 Wi-Fi 中継 USBテザリング 日本語設定画面

  • GL.iNet
Amazon

Amazon の販売ページには「技適番号：R 018-210044」の記載がありますし、この番号で総務省のページの記載が確認できます。これならベンダーが提供するファームウェアを用いる限り、特に心配なく利用できそうです。

https://www.tele.soumu.go.jp/giteki/SearchServlet?pageID=jg01_01&PC=018&TC=N&PK=1&FN=210222N018&SN=%94F%8F%D8&LN=26&R1=*****&R2=*****

とりあえず、Wi-Fi 側の性能測定は後回しにして、有線LANのWAN - LAN 間のスループットや、有線LANの内部側と DS-Lite のパフォーマンスをざっくり測ってみました。

雑感

  • デフォルトの管理 UI は、GL.iNet のオリジナルの UI です。ただし ssh でログインしてみると OpenWrt のログインメッセージが表示されることを確認しました。
  • デフォルトでは WAN 側の IPv6 は無効のため、IPv6 IPoE で利用したい場合は IPv6 を有効化する必要があります。
  • 標準の管理 UI には DS-Lite の設定項目はありません。Luci UI を別途インストールし、Luci から設定する必要があります。

  • 管理UI の「高級機能」メニューから Luci をインストールすれば、OpenWrt の Luci UI が利用できるようになります。

  • OpenWrt を搭載しているとはいいつつも、ソフトウェアダウンロード用のサイトは GL.iNet が運用するサーバです。OpenWrt のサイトからダウンロードしているわけではありません。

  • そして GL.iNet のサーバーは IPv6 に対応していないため、DS-Lite をインストールするために IPv4 でインターネットに接続できる環境が必要です。すでに何かのインフラがある場合は特に問題ありませんが、そうではない場合はスマホとテザリングするなどして必要なソフトウェアのインストールを行う必要があります。

WAN - LAN のスループット

フレッツ光ホームゲートウェイの WAN 側に設置した PC で iperf3 をサーバーモードで実行し (iperf3 -s) 、LAN 側の PC から iperf3 のクライアントで接続しました (iperf3 -c サーバのIPアドレス)

Connecting to host 192.168.1.6, port 5201
[  5] local 192.168.8.160 port 61798 connected to 192.168.1.6 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   109 MBytes   915 Mbits/sec                  
[  5]   1.00-2.00   sec   108 MBytes   908 Mbits/sec                  
[  5]   2.00-3.00   sec   109 MBytes   917 Mbits/sec                  
[  5]   3.00-4.00   sec   111 MBytes   932 Mbits/sec                  
[  5]   4.00-5.00   sec   110 MBytes   924 Mbits/sec                  
[  5]   5.00-6.00   sec   111 MBytes   927 Mbits/sec                  
[  5]   6.00-7.00   sec   108 MBytes   904 Mbits/sec                  
[  5]   7.00-8.00   sec   105 MBytes   882 Mbits/sec                  
[  5]   8.00-9.00   sec   106 MBytes   888 Mbits/sec                  
[  5]   9.00-10.00  sec   103 MBytes   868 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  1.06 GBytes   907 Mbits/sec                  sender
[  5]   0.00-10.00  sec  1.06 GBytes   907 Mbits/sec                  receiv

これくらいのスループットが出ていれば悪くないと思います。

DS-Lite のスループット測定

日曜日の夜にSpeedtest CLI で計測してみました。

   Speedtest by Ookla

     Server: Rakuten Mobile, Inc - Tokyo (id = 24333)
        ISP: Internet Multifeed Co.
    Latency:    10.66 ms   (1.12 ms jitter)
   Download:   272.99 Mbps (data used: 403.6 MB)                               
     Upload:    86.51 Mbps (data used: 119.2 MB)                               
Packet Loss:     0.0%

できればもうちょっとスピードが出て欲しい気もしますが、実用上の問題は、あまりなさそうに思います。

というわけで、少なくとも WAN-LAN 間のスループットは全く問題ないので、技適の問題を気にせずに OpenWrt を利用したい場合の選択肢としては悪くないように思います。

ただし、私の手元で Luci UI をインストールして環境構築していたら Wi-Fi が認識できない状況が発生しました。無線の設定は標準の UI と Luci の UI で整合性が取れないように見受けられました。とりあえず設定を初期化し、無線の設定は標準の UI 側だけで操作したところ問題なく設定できましたが、この手のトラブルを楽しみつつ自力で問題解決できるスキルの方には向くと思いますが、そういうのが苦手な方は手を出さないほうが良いかもしれません。

もっとも、OpenWrt 自体、初心者向けではないと思うので、この程度のトラブルを自力で対処できない方向きではないことは間違いないですけど。

IPv4 DS-Lite の速度が出ない時は、そもそもルーターの性能の頭打ちの可能性を疑ってみる

OpenWRT

フレッツ光回線でインターネット接続する場合に IPv6 IPoE + IPv4 + DS-Lite 対応プロバイダを利用し、ルータも DS-Lite 接続を有効にすると PPPoE に比べて帯域速度が改善します。このときにスループットに対する影響を与える要素は以下のように多岐に渡ります。

  1. PC 自体の性能
  2. PC の LAN アダプタ：GbE 対応かどうか、USB3 かどうか、ドライバの性能は問題ないか
  3. LAN ケーブル：ルーターと PC 間
  4. ルーター
  5. LAN ケーブル：フレッツ光ホームゲートウェイ or ONU とルータ間
  6. ONU
  7. フレッツ光回線の種別
  8. 接続先サイトへのネットワーク経路

しかしながら、ブラウザなどで計測できる速度計測サイトでは、1. - 7. の部分を含めて速度計測してしまうため、どこにボトルネックがあるかを知ることができません。

計測方法

2台の PC にiperf3という計測ツールをインストールして使用します。ルーターの WAN 側（フレッツ光ホームゲートウェイ側）に設置した PC でサーバーを実行し、ルーターの LAN 側に設置した PC でクライアント側を実行すれば、ルーターを超える通信のスループットを計測できます。

(サーバー側)
iperf3 -S

(クライアント側)
iperf3 -c サーバ側IPアドレス

また、ルーターを超えてインターネット側と通信する場合のスループットは Speedtest CLI を使用して計測します。 https://www.speedtest.net/ja/apps/cli

同一セグメントのノード間で計測

ルーター超えの計測を行う前に、同一セグメントのノードどうしで iperf3 による計測を実施します。この計測で十分な速度が出ていない場合は、そもそも PC の性能が頭打ちの可能性があります。

以下はルーターの LAN 側に有線LANケーブル (CAT-6) で接続した PC どうしの計測結果です。これくらいの速度が出ていれば特に不満はないと思います。

Connecting to host 192.168.1.6, port 5201
[  5] local 192.168.1.4 port 55011 connected to 192.168.1.6 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   104 MBytes   870 Mbits/sec                  
[  5]   1.00-2.00   sec   109 MBytes   916 Mbits/sec                  
[  5]   2.00-3.00   sec   109 MBytes   918 Mbits/sec                  
[  5]   3.00-4.00   sec   112 MBytes   937 Mbits/sec                  
[  5]   4.00-5.00   sec   112 MBytes   939 Mbits/sec                  
[  5]   5.00-6.00   sec   107 MBytes   902 Mbits/sec                  
[  5]   6.00-7.00   sec   111 MBytes   934 Mbits/sec                  
[  5]   7.00-8.00   sec   109 MBytes   915 Mbits/sec                  
[  5]   8.00-9.00   sec  97.9 MBytes   821 Mbits/sec                  
[  5]   9.00-10.00  sec   112 MBytes   939 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  1.06 GBytes   909 Mbits/sec                  sender
[  5]   0.00-10.00  sec  1.06 GBytes   909 Mbits/sec                  receiver

有線LAN経由での同一セグメント接続で十分な速度が出ない場合は、PCのNICが GbE に対応していることや、NIC の実際のリンク速度が GbE であることを確認します。古いLANケーブルを使っている場合はケーブルの問題で速度が出ないこともありえます。NIC のスペックが GbE なのにスピードが出ない場合は CAT6 の新品のケーブルを買ってきて試してみるのも悪くないアイデアです。

なお、有線LAN ではなく Wi-Fi で計測すると、もっと悪い数値が出る場合が多いはずです。今回の計測はルーターを超える通信のスループットを計測し、DS-Lite の速度と比べることを目的としていますが、この手の計測には Wi-Fi は不向きです。必ず有線 LAN で計測しましょう。

PC をフレッツ光ホームゲートウェイに直結して DS-Lite 接続した場合の速度（または IPv6 IPoE の速度）

ルーター超えのスループットを測る前に、DS-Lite 自体の速度の期待値を確認しておきます。Windows だと DS-Lite を扱えないのですが、macOS, Linux の場合は DS-Lite のトンネルを張ることができるため、これらの OS が利用できる場合は計測しておくと良いでしょう。

macOS Sierra 以前の macOS の場合は、下記のスクリプトで DS-Lite 接続が行えます。

techlog.iij.ad.jp

macOS Sierra 以降は IPv6 のアドレス取得方法が変わっているため、上記スクリプトのままでは動作しません。下記記事では修正方法例が示されていますが、私の環境では macOS Big Sur では動作しませんでした。 blog.goo.ne.jp

私の場合は macOS Sierra 以降にアップデートできていない、古い MacBook (macOS El Capitan) 500 Mbps 台の速度が計測できました。

   Speedtest by Ookla

     Server: Rakuten Mobile, Inc - Tokyo (id = 24333)
        ISP: Internet Multifeed Co.
    Latency:     8.71 ms   (0.27 ms jitter)
   Download:   548.26 Mbps (data used: 387.0 MB)                               
     Upload:    91.12 Mbps (data used: 109.8 MB)                               
Packet Loss:     0.0%

もし PC からの DS-Lite 接続が行えない場合は、代わりに https://fast.com/ja/ にブラウザでアクセスしてみてください。これは Netflix の速度計測サイトですが、IPv6 でネットワークからの速度計測にも対応しているようでした。厳密に言えば DS-Lite のスループットとは違う計測ですけど、ルーターを介さない場合の参考値として使えます。

これについても前述の古い MacBook で計測したところ、400 〜 500Mbits/sec の間の数値が計測されました。

したがって、ルーター超えの場合に、この速度にどこまで近づくか、ということが目標になります。PC どうしの直結で計測したスループット問題がある場合にはそもそも論外ですので、適切なスループットが出るように整えてから検査しましょう。

また、PC どうしでルータを超えない通信のスループットに問題がないにもかかわらずインターネット側とルーターを介さない通信が遅い場合は、フレッツ光側に起因する問題で速度が出ていない可能性があります。この場合ではルーター超えかつインターネット側に出る前のスループットに問題がなくても、ONU から先の部分で遅くなる原因があるため、十分な性能が出ないものと考えられます。

ルーター超えのスループット（WZR-HP-AG300H）

WZR-HP-AG300H は OpenWrt で無難に扱える機種として好まれていますが、OpenWrt 19.07.7 で無線を無効化し、DS-Lite でインターネット接続が行える設定にした上で、ルーター超えのスループットを計測しました。

有線LANの仕様は GbE に対応していることになっていますが、実際にスループットを計測すると、ごらんのとおり 100Mbits/sec 程度のスループットしか出ません。

Connecting to host 192.168.1.6, port 5201
[  5] local 192.168.3.160 port 56817 connected to 192.168.1.6 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  11.5 MBytes  96.1 Mbits/sec                  
[  5]   1.00-2.00   sec  11.3 MBytes  94.8 Mbits/sec                  
[  5]   2.00-3.00   sec  11.3 MBytes  94.8 Mbits/sec                  
[  5]   3.00-4.00   sec  11.1 MBytes  93.3 Mbits/sec                  
[  5]   4.00-5.00   sec  11.3 MBytes  94.6 Mbits/sec                  
[  5]   5.00-6.00   sec  11.3 MBytes  94.5 Mbits/sec                  
[  5]   6.00-7.00   sec  11.4 MBytes  95.4 Mbits/sec                  
[  5]   7.00-8.00   sec  11.3 MBytes  94.8 Mbits/sec                  
[  5]   8.00-9.00   sec  11.3 MBytes  95.2 Mbits/sec                  
[  5]   9.00-10.00  sec  11.3 MBytes  94.7 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec   113 MBytes  94.8 Mbits/sec                  sender
[  5]   0.00-10.00  sec   113 MBytes  94.7 Mbits/sec                  receiver

Speedtest CLI で計測してみても、ごらんの通りの結果です。PPPoE に比べれば十分に速いとは思いますが、DS-Lite の期待値には程遠い結果です。

   Speedtest by Ookla

     Server: Rakuten Mobile, Inc - Tokyo (id = 24333)
        ISP: Internet Multifeed Co.
    Latency:    10.61 ms   (0.28 ms jitter)
   Download:    89.85 Mbps (data used: 89.2 MB)                               
     Upload:    90.58 Mbps (data used: 93.3 MB)                               
Packet Loss:     0.0%

確かに無難に扱える機種ではあるのですが、DS-Lite 接続では回線のパフォーマンスを全く発揮できないスペックしか出ないので、これは予備機に格下げし、別の機器に入れ替えることを検討したほうが良い程度の性能です。

ルーター超えのスループット（I-O DATA WN-AC1600DGR2）

WZR-HP-AG300H は古すぎる機材ですから、別のハードウェアで試してみます。WZR-HP-AG300H と同様に Wi-Fi を使用しない設定での検証です。すると WZR-HP-AG300H の 3 倍程度のスループットになりました。

Connecting to host 192.168.1.6, port 5201
[  5] local 192.168.2.160 port 55576 connected to 192.168.1.6 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  40.1 MBytes   336 Mbits/sec                  
[  5]   1.00-2.00   sec  40.3 MBytes   338 Mbits/sec                  
[  5]   2.00-3.00   sec  40.2 MBytes   337 Mbits/sec                  
[  5]   3.00-4.00   sec  39.4 MBytes   331 Mbits/sec                  
[  5]   4.00-5.00   sec  39.9 MBytes   334 Mbits/sec                  
[  5]   5.00-6.00   sec  39.1 MBytes   328 Mbits/sec                  
[  5]   6.00-7.00   sec  39.2 MBytes   329 Mbits/sec                  
[  5]   7.00-8.00   sec  39.1 MBytes   328 Mbits/sec                  
[  5]   8.00-9.00   sec  39.0 MBytes   327 Mbits/sec                  
[  5]   9.00-10.00  sec  39.0 MBytes   327 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec   395 MBytes   332 Mbits/sec                  sender
[  5]   0.00-10.00  sec   395 MBytes   331 Mbits/sec                  receiver

Speedtest CLI で DS-Lite のスループットを計測してみると、WZR-HP-AG300H の 2 倍のスループットが出ています。DS-Lite の期待値の半分以下のスループットではありますが、これくらいの速度が出るなら許容範囲ではないかと思います。

   Speedtest by Ookla

     Server: Rakuten Mobile, Inc - Tokyo (id = 24333)
        ISP: Internet Multifeed Co.
    Latency:     9.60 ms   (0.59 ms jitter)
   Download:   223.96 Mbps (data used: 246.6 MB)                               
     Upload:    92.83 Mbps (data used: 120.1 MB)                               
Packet Loss:     0.0%

ルーター超えのスループット（Raspberry Pi4 + USB3-NIC）

もうちょっと新しいハードウェアでも検証してみましょう。Raspberry Pi 4 が手元にあるので、これに OpenWrt 21.02-rc1 をインストールして検証します。

Raspberry Pi4 はオンボードNIC が一つしかないので、手元にあった Anker の USB-LAN アダプタを組み合わせます。これは Realtek RTL8153 を搭載しているようでしたので、RTL8152 向けのドライバを OpenWrt に追加インストールして使用します…

この構成でルーター超えの iperf3 の速度を計測すると PC どうしの直結に迫る速度でした。

Connecting to host 192.168.1.6, port 5201
[  5] local 192.168.4.188 port 52825 connected to 192.168.1.6 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  98.2 MBytes   824 Mbits/sec                  
[  5]   1.00-2.00   sec  99.9 MBytes   838 Mbits/sec                  
[  5]   2.00-3.00   sec   102 MBytes   853 Mbits/sec                  
[  5]   3.00-4.00   sec   100 MBytes   840 Mbits/sec                  
[  5]   4.00-5.00   sec  96.4 MBytes   809 Mbits/sec                  
[  5]   5.00-6.00   sec   101 MBytes   850 Mbits/sec                  
[  5]   6.00-7.00   sec   100 MBytes   840 Mbits/sec                  
[  5]   7.00-8.00   sec   104 MBytes   872 Mbits/sec                  
[  5]   8.00-9.00   sec   102 MBytes   856 Mbits/sec                  
[  5]   9.00-10.00  sec   103 MBytes   860 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  1007 MBytes   844 Mbits/sec                  sender
[  5]   0.00-10.00  sec  1006 MBytes   844 Mbits/sec                  receiver

これくらいのスループットが出るようならいろいろと期待が高まります。Speedtest CLI で DS-Lite の速度を計測してみると、なかなかよい数値が出ました。ここまでのパフォーマンスが出るようなら期待値として十分だと思います。

   Speedtest by Ookla

     Server: Rakuten Mobile, Inc - Tokyo (id = 24333)
        ISP: Internet Multifeed Co.
    Latency:     9.31 ms   (2.23 ms jitter)
   Download:   416.15 Mbps (data used: 395.7 MB)                               
     Upload:    85.40 Mbps (data used: 97.7 MB)                               
Packet Loss:     0.0%
 Result URL: https://www.speedtest.net/result/c/20c6db34-c2b1-4952-8475-c3281e577505

ただし Raspberry Pi4 はルーター用に用いるには少々お高いので、Nanopi R2S などを用いるのがよいかもしれません。

Internet Watch の記事例では Nanopi R2S で fast.com での速度計測を行った場合に約600Mbits/secのスループットが出ているようです。すべての環境でこの速度が出ることが期待できるわけではないでしょうけれど、十分な速度が出るものと思われます。 https://internet.watch.impress.co.jp/docs/column/shimizu/1311821.html

curl コマンドは URL に含まれる Anchor を送信しない

WebService

Windows で OAuth2 Implicit Grant で認可リクエストを送信するクライアントアプリを試作した際にリダイレクトURIのリクエストを受けるサーバ側の挙動を試そうと考えたのですが、 http://localhost:port/redirectpage#access_token=....&state=....&token_type=... というリクエストを受け先のサーバに curl で送信しようとしてみたのですが、アンカー部分が受け先のサーバに送出されている気配が全くない。

どうも変だなあ、と思って調べてみたら、curl 7.20.0 で "fragment part of URLs are no longer sent to the server" という Bugfix が行われていて、アンカー部分を落として送信するように修正されているということを知りました。

stackoverflow.com

仕方がないので、とりあえず telnet コマンドを以下の PowerShell コマンドでインストールして検証しました。

Enable-WindowsOptionalFeature -Online -FeatureName TelnetClient