AT&T 網路的問題

Hacker News Daily 上看到個有趣的 troubleshooting 過程,AT&T 的線路會造成 random bit flipping 的問題,另外在 Hacker News 上的討論野蠻熱鬧的:「AT&T Fiber in the SF Bay Area is flipping bits (twitter.com/catfish_man)」。

有人生了一個 script 出來測試,這隻 script 會抓 www.example.com 的 HTTP 與 HTTPS 結果比較,從下面大家的留言回報,可以看出來有 random bit flipping 的問題:「bmastenbrook/example-test.sh」。

然後總算是解決了:

可惜看不到 AT&T 的回應,大家只能猜測是 memory 相關的問題,也許壞的部份有多個地方,造成 ECC 機制在某些情況下不夠用...

Internet Archive 的 Flash 收藏

剛剛看到 Internet Archive 的這篇文章:「Flash Animations Live Forever at the Internet Archive」。

Internet Archive 把模擬器掛上去了,所以你可以直接在網站上用這些 Flash 程式:

Great news for everyone concerned about the Flash end of life planned for end of 2020: The Internet Archive is now emulating Flash animations, games and toys in our software collection.

看起來是透過 ruffle + WebAssembly 轉到瀏覽器上面跑:

Utilizing an in-development Flash emulator called Ruffle, we have added Flash support to the Internet Archive’s Emularity system, letting a subset of Flash items play in the browser as if you had a Flash plugin installed. While Ruffle’s compatibility with Flash is less than 100%, it will play a very large portion of historical Flash animation in the browser, at both a smooth and accurate rate.

You will not need to have a flash plugin installed, and the system works in all browsers that support Webassembly.

然後在「Software Library: Flash Showcase」這邊有一些 showcase 可以看,基本上就是測過沒問題的。另外在「Software Library: Flash」看起來就是整包了...

搜了一下以前有在玩的 Zookeeper,好像沒有在裡面...

SpaceX Starlink 的延遲與速度

SpaceXStarlink 已經有些人開始在測試了,在 Speedtest.net 上也已經有人挖到資料,可以看出他的延遲與速度了:「SpaceX Starlink speeds revealed as beta users get downloads of 11 to 60Mbps」。

報導的資料主要是從 Reddit 上的拉出來的,如果要看原始的資料,可以參考「List of Confirmed Starlink Speed Tests」這篇列出來的連結。

延遲可以低到 20ms 左右,不過比較常見是 30ms~40ms,高的時候可以看到 90ms 左右,這樣看起來頗有競爭性的,下載速度看起來也還不錯...

目前看起來都是加州地區的測試,查了資料看起來是目前開放的區域有限 (加拿大南部與美國北部),之後可以看開放其他地區的情況。

另外未來如果更多衛星打上去,網路的品質應該會更好,不過對天文學家看起來是場災難,光害的問題看起來很嚴重,像這張曝兩秒的照片就可以看出來這六顆的情況:(出自「File:Starlink 6 satellites.jpg」)

阻擋網站透過瀏覽器掃 localhost

五月的時候,DuckDuckGoCharlie Belmer 發了一篇關於網站透過瀏覽器掃 localhost 的文章,引起了不少重視:「Why is This Website Port Scanning me?」。

這個月陸陸續續看到一些反制方式了,比較簡單的是透過像 uBlock Origin 這類可以擋特定 url 的方式,像是 EasyPrivacy 裡面把一些大站台的 javascript script 擋下來:「uBlock Origin ad blocker now blocks port scans on most sites」。

在同一篇文章的 comment 處也有人提到 uBlock Origin 可以做的更廣泛:「Block access to 127.0.0.1/localhost and LAN address from the internet #4318」,裡面有人已經整理好丟出來了:「lan-block.txt」,看起來也可以擋一些...

要擋得比較完整的還得考慮 scan.example.com IN A 127.0.0.1 這種方式繞過去的情況?這可能需要用 extension 了...

Internet Archive 的頻寬...

看到「Thank you for helping us increase our bandwidth」這邊在說明 Internet Archive 的流量資訊:

看起來平常就是滿載的情況,然後加上去的流量馬上就被吃掉了... 這些資料看起來是放在 Cacti 這邊,不過只有 error rate 有開放讓大家翻,流量的部份看起來要登入才能看。

ICANN 否決 .org 與 .ngo 的交易

ICANN 否決了 .org.ngo 網域控制權的交易:「ICANN Board Withholds Consent for a Change of Control of the Public Interest Registry (PIR)」。

Today, the ICANN Board made the decision to reject the proposed change of control and entity conversion request that Public Interest Registry (PIR) submitted to ICANN.

事情主要是起於 PIR (Public Interest Registry) 在 2019/11/13 宣佈他們的母單位 ISOC (Internet Society) 將被 Ethos Capital 併購,而這包含了 .org.ngo 網域的資產,這也代表了由 PIR 控制的網域會從非營利單位移到營利單位下 (總共有七個網域,其中最重要的是 .org,有超過一千萬個網域在上面),於是引發許多人的關注:

On 13 November 2019, PIR announced that ISOC, its parent organization, had reached an agreement with Ethos Capital, under which Ethos Capital would acquire PIR and all of its assets from ISOC. Under the agreement, PIR would also be converted from a Pennsylvania not-for-profit corporation to a for-profit Pennsylvania limited liability company. ISOC created and agreed to the transaction details that are under review.

而在隔天 2019/11/14,PIR 依照規定向 ICANN 送出「Notice of Indirect Change of Control and Entity Conversion」申請,依照規定,ICANN 需要在 2020/05/04 前批准或是否決,也就是這幾天就要做出決定。

而 ICANN 昨天宣佈了否決這項提案,暫時搞定了這件事情... 接下來看 Ethos Capital 會不會有什麼反擊 (上訴或是上法院)。

Fastly 觀察到因 COVID-19 產生的流量上升資料

因為 COVID-19 的關係,可以預期網路的流量一定會大幅提昇,但實際上是多少總是需要一些數據才能想像...

剛剛看到 Fastly 放出了他們觀察到因為 COVID-19 而產生的流量變化:「How COVID-19 is affecting internet performance」。

從 2020 年二月與三月相比,可以看到許多區域的流量都有大幅成長,尤其是重災區的義大利與英國,不過這邊沒有給與 2019 三月的比較 (YoY):

另外是這些流量成長的種類,可以看到 streaming、數位媒體與教育類的流量大幅成長:

在網路速度的部份,可以看到大多數的地區是下降的,但加州沒什麼影響,而日本反而是上升的,應該可以解讀為這兩個地區平常就有夠多的容量,所以真的有爆量而用到的時候反而不會是瓶頸?

接下來幾個月應該會更嚴峻...

Bootstrap v5 將會拔掉對 IE 的支援

如同標題所說的,Bootstrap 打算拔掉對 IE 的支援,在 GitHub 上的 Pull Request:「v5: drop Internet Explorer support」。

當然下面可以看到有反對意見,不過基本上還是尊重 Bootstrap 團隊做的決定,另外一方面也是現在的選擇多了很多,市場自由競爭總是會看出結果的。

測了一下先前提到的「MVP.css」,本來以為只做 semantic html 的設計,純 css 應該是有機會往下支援到蠻早的版本,結果拿 IE11 一開官網,看起來還是不少東西掛掉了 XD

看起來還得再找找... 也許繼續龜在 v4?

RIPE 的 IPv4 位置發完了

RIPE 在上個禮拜宣佈 IPv4 address 發完了:「[ripe-list] The RIPE NCC has run out of IPv4 Addresses」。

但這不代表不能申請,只是會進到「IPv4 Waiting List」這個列表裡面等待,各種原因取回的會發個這些申請者。

在台灣應該還是沒什麼感覺,因為固網 ISP 手上其實都拿一堆 IP 屯著,讓動態 IP 的架構輪著用,而行動網路上也可以看到不少 ISP 使用 Carrier-grade NAT 之類的架構在跑,最差也還可以拿 Private IP 硬上,暫時也不是太缺...

IPv6 的部份的確有愈來愈好,但還是常常可以看到 IPv4 的 routing 比較好,IPv6 有時候會繞到歐美再回亞洲...

話說起來,應該做看看 IPv6 上的 SmokePing 了,這樣才能比較 IPv4 與 IPv6 的 routing...

Google Cloud Platform 在台灣的機房可以開 Standard Network 的機器了

Google Cloud Platform 一開始是提供 Premium Network,會透過 Google 自家的網路骨幹連到最近的點,然後再透過當地的機房交換出去,這樣可以確保頻寬的穩定性,但成本當然也就比較高...

後來提供了 Standard Network 則是從機房出去後就直接交換,成本會比較低 (參考「Network Service Tiers - Custom Cloud Network」這篇),但在台灣的機房一直都沒有提供 Standard Network (好像是需要另外申請?),所以我每個月月底的時候都會測一下看看開放了沒... 然後剛剛發現可以開起來了,不確定是已經全開了還是分批開。

測了一下發現網路相當... 爛?是還在調整嗎...

像是 1.1.1.1 的 latency 很高 (自家的 8.8.8.8 當然就沒這個問題):

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=49 time=48.9 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=49 time=48.5 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=49 time=48.5 ms

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 48.554/48.691/48.964/0.193 ms

然後 168.95.1.1139.175.1.1 也都很差 (61.31.1.1 不給 ping):

PING 168.95.1.1 (168.95.1.1) 56(84) bytes of data.
64 bytes from 168.95.1.1: icmp_seq=1 ttl=239 time=21.2 ms
64 bytes from 168.95.1.1: icmp_seq=2 ttl=239 time=21.3 ms
64 bytes from 168.95.1.1: icmp_seq=3 ttl=239 time=21.4 ms

--- 168.95.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 21.276/21.367/21.454/0.072 ms
PING 139.175.1.1 (139.175.1.1) 56(84) bytes of data.
64 bytes from 139.175.1.1: icmp_seq=1 ttl=53 time=63.4 ms
64 bytes from 139.175.1.1: icmp_seq=2 ttl=53 time=62.9 ms
64 bytes from 139.175.1.1: icmp_seq=3 ttl=53 time=62.9 ms

--- 139.175.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 62.967/63.139/63.455/0.303 ms

不過學術網路倒是還不錯:

PING 140.112.2.2 (140.112.2.2) 56(84) bytes of data.
64 bytes from 140.112.2.2: icmp_seq=1 ttl=51 time=5.13 ms
64 bytes from 140.112.2.2: icmp_seq=2 ttl=51 time=4.40 ms
64 bytes from 140.112.2.2: icmp_seq=3 ttl=51 time=4.52 ms

--- 140.112.2.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.405/4.690/5.138/0.325 ms
PING 140.113.250.135 (140.113.250.135) 56(84) bytes of data.
64 bytes from 140.113.250.135: icmp_seq=1 ttl=55 time=5.87 ms
64 bytes from 140.113.250.135: icmp_seq=2 ttl=55 time=5.97 ms
64 bytes from 140.113.250.135: icmp_seq=3 ttl=55 time=6.11 ms

--- 140.113.250.135 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 5.872/5.987/6.119/0.135 ms
PING 140.117.11.1 (140.117.11.1) 56(84) bytes of data.
64 bytes from 140.117.11.1: icmp_seq=1 ttl=242 time=9.52 ms
64 bytes from 140.117.11.1: icmp_seq=2 ttl=242 time=9.17 ms
64 bytes from 140.117.11.1: icmp_seq=3 ttl=242 time=9.20 ms

--- 140.117.11.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 9.172/9.298/9.521/0.176 ms

有需要的人可以測試看看了...