AWS 在阿聯開區域了 (me-central-1)

AWS 在阿聯開新的區域了:「Now Open–AWS Region in the United Arab Emirates (UAE)」。

也是首發就 3 AZ:

The Middle East (UAE) Region has three Availability Zones that you can use to reliably spread your applications across multiple data centers.

中東的第一個區域是巴林,首都麥納瑪離阿聯的首都杜拜直線距離大約 500km,算起來蠻近的... 對於主要客群是中東的用戶,看起來可以設計 Active-Active 的機制做到跨區備援?

不過更重要的還是繼續等台灣的 local zone...

Starlink 想要在太空直接提供 5G 網路訊號讓地面手機使用

Hacker News 上看到 Starlink 打算跟 T-Mobile 合作,直接用衛星提供 5G 訊號讓地面手機使用:「SpaceX, T-Mobile to connect satellites to cellphones in remote areas (wsj.com)」,原報導在 WSJ 的「SpaceX, T-Mobile to Connect Satellites to Cellphones in Remote Areas」這邊,另外因為 paywall 的關係,可以在這邊讀。

會用二代衛星:

Mr. Musk said the service would use second-generation Starlink satellites that would be outfitted with large antennas that cover swaths of land that have no service. SpaceX has a pending application before the FCC to launch around 30,000 of the second-generation satellites over time.

在另外一篇報導「SpaceX and T-Mobile team up to use Starlink satellites to ‘end mobile dead zones’」裡面有提到更細一點,不是衛星電話,是目前一般的手機:

The service won’t require mobile users to get a new phone. Musk said in or after a natural disaster, even if all the cell towers are taken out, the planned service should work.

不過可以預期只會有很基本的服務 (大概確保通話與簡訊會通),針對緊急危難狀況會特別有幫助:

Mr. Musk said that the bandwidth would be limited and that the new satellite service wouldn’t supplant existing ground-based cellular services. “This is meant to provide basic coverage to areas that are completely dead,” he said.

翻了翻 wiki,目前 Starlink 第一代衛星的軌道高度是 340km 左右,好像還不確定二代衛星會在哪個高度...

Hacker News 上有蠻多人在算技術上的可行性,除了訊號強度外,衛星與地面相對速度比目前地面上的交通工具都快,都卜勒效應 (Doppler effect) 看起來也是個會影響很多的主題...

不過討論裡面有提到 2021 年就已經有其他商用公司在幹類似的事情,所以看起來不只是講講而已?應該是有些可能性:「Lynk demos global satellite connection for ordinary phones and prepares for commercial launch」。

AWS Support 整合到 Slack 頻道內

在「New – AWS Support App in Slack to Manage Support Cases」這邊看到的新功能,主要是下面這張圖,看起來可以直接在 Slack 上面開 private channel 跟 AWS Support 成員討論事情:

依照說明,有 Business 以上的等級都可以用:

The AWS Support App in Slack is now available to all customers with Business, Enterprise On-ramp, or Enterprise Support at no additional charge.

雖然好像不是哪麼常跟 AWS 的人打交道,但平常先掛起來好像不錯...

Heroku 公佈了廢止免費方案的時間表

打開 Hacker News 看到的第一名,Heroku 公佈了廢止免費方案的時間表:「Removal of Heroku free product plans (heroku.com)」,文章在「Removal of Heroku Free Product Plans FAQ」。

沒在用的帳號會在 2022/10/26 開始刪,既有的帳號會在 2022/11/28 終止:

Focus on what's mission-critical: Removal of free dynos, hobby-dev Heroku Postgres and hobby-dev Heroku Data for Redis plans starting November 28, 2022 and inactive account deletion starting October 26, 2022.

取而代之的是針對特定團體條件性的開放,分成三類:學生、非營利組織以及 open source 專案。但前兩個目前方案都還沒出來,要晚點才會公佈;後面的 open source 專案則是要寄信申請。

不過現在好像沒什麼人在用 Heroku 了,大多都是因為以前有在用的人就繼續用,如果要講 "sexy" 的產品 (玩新東西的感覺),Fly.io 應該是比較常見的方案?

Google Cloud 宣佈明年關閉 IoT Core Services

Hacker News 上的「Google IoT Core will be discontinued on Aug. 16, 2023」這篇,大家在討論 Google Cloud 宣佈明年關閉 IoT Core Services 的事情,基本上討論的內容大概都想的到...

AWS 這邊的話,最近比較有印象的就是要淘汰 EC2 Classic (EC2-Classic 的狀態),但到現在還是在跑。

另外一個是把 Xen 架構 porting 到 Nitro 上 (AWS 將新的 Nitro 架構回過投來支援以前 Xen 的機種),讓原有的 Xen 應用可以繼續用。

久一點以前的 SimpleDB 到現在也還是活著,官方現在應該是主力在推 DynamoDB

兩種完全不同的作法...

Netflix 的 Open Connect 機器往 800Gbps 推進

2021 年的時候曾經提過 Netflix 試著用單機推出 400Gbps 的流量 (用在 Netflix 的 Open Connect):「Netflix 在單機服務 400Gbps 的影音流量」,快一年後的目前,Netflix 的人已經成功推到接近 800Gbps 了:「Serving Netflix Video Traffic at 800Gb/s and Beyond」。另外在 Hacker News 上的討論「Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] (nabstreamingsummit.com)」也可以看看。

翻了一下投影片,最後衝到 720Gbps,主要是因為 NIC output drop,而非其他部份。

裡面還是把之前的故事也都講了一遍 (不然簡報的時間會太短?),如果有看過前面的內容可以快速看一下就好,這次新的東西從 page 89 開始:

  • Asynchronous Sendfile (2014)
  • Kernel TLS (2016)
  • Network-centric NUMA (2019)
  • Inline Hardware (NIC) kTLS (2022)
  • 800G initial results

最後面幾張投影片裡面有提到往 800Gbps 衝的硬體平台:

  • AMD (EPYC 7713 CPUs)
  • Dell (PowerEdge R7525)
  • Mellanox/NVIDIA (ConnectX-6 Dx NICS)
  • Intel (P5316 NVME)

下個目標不知道是什麼,看起來目前已經壓榨到 memory bandwidth 也有點極限的感覺了...

CloudFront 支援 HTTP/3

雖然 HTTP/3 還沒有進到 Standard Track,但看到 CloudFront 宣佈支援 HTTP/3 了:「New – HTTP/3 Support for Amazon CloudFront」。

只要在 CloudFront 的 console 上勾選起來就可以了:

看了看 RFC 9114: HTTP/3 文件裡的描述,client 可以試著建立 UDP 版本的 QUIC 連線,但要有機制在失敗時回去用 TCPHTTP/2 或是 HTTP/1.1

A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake.

Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case.

另外一條路是在 TCP 連線時透過 HTTP header 告訴瀏覽器升級:

An HTTP origin can advertise the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame ([ALTSVC]) using the "h3" ALPN token.

像是這樣:

Alt-Svc: h3=":50781"

然後 client 就可以跑上 HTTP/3:

On receipt of an Alt-Svc record indicating HTTP/3 support, a client MAY attempt to establish a QUIC connection to the indicated host and port; if this connection is successful, the client can send HTTP requests using the mapping described in this document.

另外在 FAQ 裡面有提到啟用 HTTP/3 是不另外計費的,就照著本來的 request 費用算:

Q. Is there a separate charge for enabling HTTP/3?

No, there is no separate charge for enabling HTTP/3 on Amazon CloudFront distributions. HTTP/3 requests will be charged at the request pricing rates as per your pricing plan.

先開起來玩看看...

滲透測試的工具,各種搜尋引擎

Twitter 上看到的東西:

裡面是一張圖,整理一下這 24 個站台:

一堆 .io 網域...

裡面有蠻多服務是偶而會用到的,改拿來當作 pen test 的基礎工作也是蠻好用的,各種預先掃好的結果拿來搜...

Linode 的 VPC 與 VLAN

看到 Linode 的「Go Private with VLANs and VPCs」這篇,裡面特地提到了 VLAN

Can a VLAN be used as a VPC on Linode?

The short answer is again, yes, we can use a VLAN as a VPC on Linode.

在「Common Use Cases for Linode's VLAN Service」這篇 (發現是 2021 年就有的資料) 裡面開頭就有提到:

This means that two or more Linodes connected via the VLAN can see each other as if they were directly connected to the same physical Ethernet network. This network supports all the logical Ethernet features like L2 broadcast and L2 multicast.

所以看起來的確是在 Linode 的 SDN 上面支援了 VLAN。記得早期是用 Cisco 的方案 (2013 年的時候有「Linode NextGen: The Network」這篇),現在不知道是什麼架構...