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 也常幹這種事情...

Facebook 提供 Public NTP Service

在「Building a more accurate time service at Facebook scale」這邊 Facebook 講了不少跟 NTP 有關的東西,不過重點在他們提供 Public NTP service:

Having five independent geographically distributed endpoints helps us provide better service — even in the event of a network path failure. So we provide five endpoints:

  • time1.facebook.com
  • time2.facebook.com
  • time3.facebook.com
  • time4.facebook.com
  • time5.facebook.com

Each of these endpoints terminates in a different geographic location, which has a positive effect on both reliability and time precision.

看起來是混了 anycast 進去,從台灣 (HiNet) 走的話,time1.facebook.com 會到東京,time2.facebook.com 到大阪 (難得在 traceroute 上看到 ITM 這個代碼,代表 伊丹機場),time3.facebook.com 則是台灣,time4.facebook.com 到香港,time5.facebook.com 好像是馬來西亞?看 latency 與 maa 這個詞... (Update:應該是清奈國際機場)

可以考慮看看,另外 Google Public NTP 也是個選項。

Chrome 與 Chrome OS 最近不會更新新功能

這邊看到的消息,ChromeChrome OS 會避免在最近推出新功能,以維持軟體的穩定性,最近更新的主力會放在安全性上:「Google halts upcoming releases of Chrome and Chrome OS to keep things stable for everyone working from home」。

報導引用自 Twitter 上的宣佈:

呃,突然想到 Windows 的更新情況...

Pale Moon 呼籲不要使用 Google 主導的 WebComponents

Pale Moon 官方論壇的公告區「An Open Letter to Web Developers」這邊。

While, as a software developer ourselves, we understand very well that new features are exciting to use and integrate into your work, we ask that you please consider not adopting Google WebComponents in your designs.

話說回來,Pale Moon 用起來有種懷念感,而且比起現在的 Firefox 好用不少,只是上面套件有點少...

AWS Elemental MediaConvert 支援 AV1

在「2020/03/17 - AWS Elemental MediaConvert - 11 updated api methods」這邊看到的:

AWS Elemental MediaConvert SDK has added support for: AV1 encoding in File Group MP4, DASH and CMAF DASH outputs; PCM/WAV audio output in MPEG2-TS containers; and Opus audio in Webm inputs.

翻了一下同個站台的總表「AWS Elemental MediaConvert」這頁,看起來是第一次支援 AV1 輸出,這對於很在意頻寬的應用方便不少,另外翻了一下 Can I Use 這邊的資料「AV1 video format」,看起來也已經有不少環境可以用 AV1 了 (又看到 Safari,真不愧是 2020 年的 IE6):

另外可以參考「Netflix Now Streaming AV1 on Android」這篇,Netflix 在今年稍早的時候也決定在 Android 平台上採用 AV1。

AWS 上的 Redis 服務支援 Global Replication

AWS 上的 Redis 服務 (Amazon ElastiCache) 推出了 Global Datastore,也就是跨區同步的功能:「Now Available: Amazon ElastiCache Global Datastore for Redis」。

技術上會分成 read endpoint 與 write endpoint (在最後面的操作可以看到 $US_WEST_1_CLUSTER_READWRITE$US_WEST_2_CLUSTER_READONLY),所以算是蠻常見的 primary-secondary 架構。

不過我基本上不太愛 Redis,能用 Memcached 解決的偏好用 Memcached 解。不過如果把 Redis 當作是一種雲端服務的話,倒是還可以接受...

Brave 出手檢舉 Google 沒有遵守 GDPR

Brave (從 Chromium 分支出來的瀏覽器) 檢舉 Google 沒有遵守 GDPR 的規定:「Formal GDPR complaint against Google’s internal data free-for-all」。

主要是「purpose limitation」這個部份,出自「REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 April 2016」:

1. Personal data shall be:

(b)

collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’);

比較重要的是 specified 與 explicit 這兩個詞,GDPR 規定必須明確指明用途,而可以從整理出來的文件「Inside the black box」裡的「Purported processing purpose」看到大量的極為廣泛的說明。

Google 應該會就這塊反擊認為這樣的描述就夠用,就看歐盟決定要怎麼做了...

Kafka 拔掉 ZooKeeper 的計畫

目前 Kafka cluster 還是會需要透過 ZooKeeper 處理不少資料,但眾所皆知的,ZooKeeper 實在是不好維護,所以 Kafka 官方從好幾年前就一直在想辦法移除對 ZooKeeper 的相依性。

這篇算是其中一塊:「Kafka Needs No Keeper」。

真的自己架過 Kafka cluster 就會知道其中的 ZooKeeper 很不好維護,尤其是 Apache 官方版本的軟體與文件常常脫勾,設定起來就很痛苦。所以一般都會用 Confluent 出的包裝,裡面的 ZooKeeper 軟體與 Confluent 自己寫的文件至少都被測過,不太會遇到官方文件與軟體之間搭不上的問題。

另外一個常見的痛點是,因為 Kafka 推動拔掉 ZooKeeper 的計畫推很久了 (好幾年了),但進展不快,所以有時候會發現在 command line 下,有些指令會把 API endpoint 指到 ZooKeeper 伺服器上,但有些指令卻又指到 Kafka broker 上,這點一直在邏輯上困擾很久,直到看到官方的拔除計畫 (但又不快) 才理解為什麼這麼不一致...

給需要的人參考,當初在架設 Kafka cluster 時寫下來的筆記:「Confluent」。

把 TLS 1.0 關掉...

突然想到所以到 SSL Report 上測試 blog.gslin.org,發現如果還支援 TLS 1.0,在 Overall Rating 的部份會直接被降為 B。

翻了一下 access log (我在 log 裡有多記錄連線的 TLS Protocol),看起來用 TLS 1.0 連的主要都是 bot,關掉應該是還好...

另外看了一下報告裡的 Cipher Suites 部份,發現不少 cipher (像是 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)) 被列為 weak,看起來像是把使用 CBC 的 cipher 都認為是 weak,是個推廣 AEAD 的概念。

影響應該不大,但還是記錄一下... 另外等 Ubuntu 20.04 出了以後把整台重灌好了,目前還在用 Ubuntu 16.04,系統內建的 nginx 不支援 TLS 1.3。