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

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

用 Machine Learning 改善 Streaming 品質的服務與論文

Hacker News 上看到「Puffer」這個服務,裡面利用了 machine learning algorithm 動態調整 bitrate,以提昇傳輸品質。

測試得到的數據後來被整理起來一起放進論文:「Continual learning improves Internet video streaming」。

在開頭介紹了 Fugu 這個演算法:

We describe Fugu, a continual learning algorithm for bitrate selection in streaming video.

而 Puffer 就是實驗網站:

We evaluate Fugu with Puffer, a public website we built that streams live TV using Fugu and existing algorithms. Over a nine-day period in January 2019, Puffer streamed 8,131 hours of video to 3,719 unique users.

這個站台提供了許多真實的頻道進行測試:

Stream live TV in your browser. There's no charge. You can watch U.S. TV stations affiliated with the NBC, CBS, ABC, PBS, FOX, and Univision networks.

可以看到 Fugu 的結果很好,比起其他提出的方案是全面性的改善:

這邊是用 WebSocket 測試,並且配合了不同的 TCP congestion algorithm,沒有太考慮額外的計算成本...

SpaceX 得到 FCC 的同意架設家用的衛星網路

在「FCC approves SpaceX’s plans to fly internet-beaming satellites in a lower orbit」這邊看到的:

The Federal Communications Commission has approved SpaceX’s request to fly a large swath of its future internet-beaming satellites at a lower orbit than originally planned.

預定打四千顆低軌道衛星上去:

Under SpaceX’s original agreement with the commission, the company had permission to launch 4,425 Starlink satellites into orbits that ranged between 1,110 to 1,325 kilometers up. But then SpaceX decided it wanted to fly 1,584 of those satellites in different orbits, thanks to what it had learned from its first two test satellites, TinTin A and B. Instead of flying them at 1,150 kilometers, the company now wants to fly them much lower at 550 kilometers.

不知道價位會落在那個區塊... 如果價位夠低的話,也許是可以考慮當作偏鄉地區的通訊方案?至少是個備用方式...