Cloudflare 也推出自己的 Speed Test 服務

Cloudflare 推出了自己的 Speed Test 服務:「Test your home network performance」。

這個服務跟 Netflix 推出的 fast.com 類似,測試的是使用者端到 Netflix (或是 Cloudflare) 中間的速度,主要的目的還是公關 (PR),所以看看就好,實際上用 Speedtest 測出來會比較有參考價值,而且可以選擇不同的點測試...

不過這讓我想到之前有人測出來遠傳會對偵測使用者要使用 Speedtest 測試時開放速限的情況 (像是「遠傳吃到飽只有 Speedtest 沒限速」這篇),然後就有各種定時去打 Speedtest 觸發開放速限的方法...

目前好像只剩下這篇活著,內文提到的是 Android 上的方法,另外推文有人提到 iOS 下的方法:「[心得] 在Android破解遠X限速」,如果有遇到的可以用看看...

Internet Archive 的頻寬...

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

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

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

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

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

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

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

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

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

用 OpenCV 與類神經網路放大圖片

在「Deep Learning based Super Resolution with OpenCV」這邊看到 OpenCV 支援這些類神經網路的演算法了,而且有預先訓練好的模型資料可以下載來用。

傳統放大的方法包括 bicubic 與 nearest neighbor,速度很快但是效果就普普通通,而 NN 類的方法的效果遠超過傳統方式,不過速度慢不少。

文章裡面有提到可以指定不同的 NN 模型:

The first parameter is the name of the model. You can choose between: “edsr”, “fsrcnn”, “lapsrn”, “espcn”. It is very important that this model is the correct one for the model you specified in ‘sr.readModel()’. See the Model section on the bottom of the page for the specifications of each model.

拿這些模型名字搜了一下資料,在「Super-resolution benchmarking」這邊可以看到比較,主要是在講 EDSR 很棒,然後 ESPCN 很快?

不過看起來可以直接拿來用在不少地方了...

AWS Global Accelerator 的 TCP 協定

AWS Global Accelerator 是讓使用者先連到最近的 AWS 節點,再透過 AWS 的骨幹網路連到服務上 (可以參考之前寫的「AWS 推出 Global Accelerator,用 AWS 的網路加速」這篇),當時就有說支援 TCP 與 UDP,但剛剛看到「AWS Global Accelerator launches TCP Termination at the Edge」這篇的時候才注意到,本來的產品是把 TCP 封包當作 UDP 在處理,也就是 TCP 3-way handshake 還是要到服務節點本身處理。

現在這個 TCP Termination 的功能則是先在最近的節點上建立 TCP 連線,然後同時往後端的建立連線接起來:

Typically, a TCP connection is established by using a three-way handshake (that is, three messages) between the client on the internet and the application endpoint in the AWS Region. So the farther away the client is from the endpoint, the longer the initial connection setup takes. With TCP termination at the edge, Global Accelerator reduces initial setup time by establishing a TCP connection between the client and the AWS edge location closest to the client. At nearly the same time, Global Accelerator creates a second TCP connection between the edge location and the application endpoint in the AWS Region. With this process, the client gets a faster response from the Global Accelerator edge location, and the connection from the edge location to the application endpoint in the Region is optimized to run over the AWS global network.

這樣連線的速度就會更快,但有可能會有前面建起來但後面建不起來的情況需要處理,一般的應用程式應該還好,畢竟地球上有個 GFW 也常幹這種事情...

Let's Encrypt 的 ACME v1/v2 透過多個節點認證

從 2020/02/19 開始,Let's Encrypt 的 ACME v1/v2 都會透過多個節點認證:「ACME v1/v2: Validating challenges from multiple network vantage points」。

從多個節點認證可以降低路由被劫持後被拿來產生 SSL Certificate 的風險,看起來會有三個機房參與,需要兩個確認:

After Feb 19th we will make four total validation requests (1 from a primary datacentre, and 3 from remote datacentres). The primary request and at least 2 of the 3 remote requests must receive the correct challenge response value for the domain to be considered authorized.

也如同標題寫的,包括了現有的 v2 與將要淘汰的 v1。

在家裡遺失 Kindle 的找法...

Hacker News Daily 上看到的文章,作者遺失了 Kindle,但是確定在家裡 (因為在 router log 上看得到):「Any way to find a lost Kindle inside a house?」。

然後作者發現每天早上五點半到六點半 Kindle 會自己同步,所以塞了一個夠大的 PDF 進去以確保有夠長的時間連在網路上,然後用三台跑 Kali Linux 的筆電定位,完全是一個殺雞用牛刀的概念 XDDD (還是他家真的超大?)

但記得這要在剛遺失的時候就要找,不然等到 Kindle 的電池也沒電就沒救了 XDDD 以原文作者的情況,如果真的是這種 case 說不定到時候會拿金屬探測器掃 XDDD

CloudFront 的 BBR 效能提昇

這是在找一些 TCP congestion algorithm 相關的資訊時發現的,看起來 Amazon CloudFront 導入 BBR 一陣子了:「TCP BBR Congestion Control with Amazon CloudFront」。

不過 BBR 被研究的愈來愈多,大家開始發現這個演算法的霸道,跟其他的 TCP congestion algorithm 並不太能和平共存,但這就跟軍事武器一樣,隔壁升級了你就得跟著升級,抱怨沒有用,只會被消滅...

AWS 推出了與 5G 結合的 AWS Wavelength

看到「Announcing AWS Wavelength for delivering ultra-low latency applications for 5G」這篇,裡面提到了與 5G 結合的 AWS Wavelength

裡面提到的東西包括了把 AWS 的架構延伸到各家電信的架構裡面,看起來跟剛推出的 AWS Outposts 有關 (參考「AWS Outposts 總算要開始出貨了」這邊的介紹):

AWS Wavelength brings AWS services to the edge of the 5G network, minimizing the network hops and latency to connect to an application from a 5G device.

然後目前已經公佈的,會跟四家電信業者合作,包括北美、歐洲、日本與南韓:

AWS is partnering with leading telecommunications companies around the world, including Verizon, Vodafone, SK Telecom, and KDDI, to launch Wavelength across North America, Europe, Japan, and South Korea in 2020.

有點噱頭,但技術上還在想有什麼用...

AWS 的 VPC 在 Routing 上的改善

在這次 re:Invent 發表會上,AWS 也宣佈了一些跟 VPC routing 有關的改善。

第一個是 AWS Transit Gateway 彼此可以互串了:「New for AWS Transit Gateway – Build Global Networks and Centralize Monitoring Using Network Manager」。

第二個是可以拿 EC2 的機器 (實際上應該是 ENI) 當作 routing 的目標:「New – VPC Ingress Routing – Simplifying Integration of Third-Party Appliances」。

不過我記得第二個好像早就可以了啊,這次不知道是簡化了什麼東西...