QUIC 的進展

在「New Work in Seoul」這邊看到 QUIC 的消息:

The QUIC working group has just been chartered, and will meet for the first time in Seoul. This working group is taking Google’s pre-standardization QUIC protocol that has been deployed in production for several years, and will use it as a starting point to develop a UDP-based, stream-multiplexing, encrypted transport protocol with standardized congestion control, TLS 1.3 by default, a mapping for HTTP/2 semantics over QUIC, and multipath extensions. This is the IETF’s first standardized always-encrypted transport protocol, so careful consideration of applicability and operational capabilities will be key for success.

IETFDatatracker 上也可以看到記錄了:「QUIC (quic)」,最下面的 Milestones 可以看到第一階段的目標是在明年二月把基本的協定都定下來,之後再加東西上去。

Google Chrome 52 預設開啟了更快的 QUIC (被戲稱為 TCP/2)

在「Google’s QUIC protocol: moving the web from TCP to UDP」這篇前半部在介紹 QUIC (走 UDP 的 TLS),後半部則提到了幾個重點。

首先是 Google Chrome 從 52 開始 (也就是現在的 stable 版) 預設會開啟 QUIC (以前是只有 Google 自家的 domain),這讓採用的價值變高:

Since no one has QUIC support enabled by default in the client, you're probably still safe to run it and enable QUIC in your own browser(s). (Update: since Chrome 52, everyone has QUIC enabled by default, even to non-whitelisted domains)

再來是 QUIC 走 UDP/443:

Well, if we want to allow the QUIC protocol, we will need to allow 443/UDP too.

同時因為走的 Protocol 跟以前不同,所以我可以跑另外一隻 Server 服務使用者,目前只有 Caddy 有支援,雖然是實驗性質:

Right now, the only webserver that can get you QUIC is Caddy since version 0.9.

Both client-side and server-side support is considered experimental, so it's up to you to run it.

至少可以先把 firewall 打開了...

Slack 開始測試語音通話功能

Slack 開始測語音通話功能了:「Making voice calls in Slack」,目前是 beta:

Keep in mind: Calls (beta) is currently voice only and desktop only. Video, screen sharing, and mobile support will come in the future.

包括了 one-to-one (開放給所有的 plan),以及 group (開放給付費 plan)。

在 troubleshooting 的說明裡有提到技術問題,也可以看出一些東西:

If Slack is having trouble establishing a call connection, check the following settings, or ask your IT admin to do so:

  • Set your network to allow outbound UDP connections to port 22466.
  • Make sure your network is allowing incoming traffic from UDP 22466.

功能愈來愈齊了...

HTTP/1.1 時代的 Best Practice 變成 HTTP/2 的問題

Velocity 2015 上的「HTTP/2 is here, let's optimize!」提到了很多關於 HTTP/1.1 時代所採用的 Best Practice (或者說,workaround) 變成了 HTTP/2 的問題。

這張表整理了各種技巧在 HTTP/1.1 與 HTTP/2 的差異:

在 HTTP/2 因為有了 multiplexing 機制,用了 Apply domain sharding 後反而增加 DNS query 以及開新的連線所需要的 handshake 時間。

而 Concatenate resources 也算是 workaround 的一種,不同等級的合併會有不同的 trade-off。全站合併 assets 可以讓常逛的使用者下載的量降到最低,但會讓第一次讀取的使用者花比較多時間下載。如果是單頁合併 assets,則剛好反過來:第一次讀取的使用者較快,但常逛的使用者會下載重複的內容。

最後的 Inline resources,作者則是提出利用 HTTP/2 提供的 server push 機制來改善,不過沒看懂...

有些 workaround 總算可以拋開了...

Google 的 QUIC 擴大實驗

QUIC (Quick UDP Internet Connections) 是 Google 發明的協定,主要是希望改善 TCP + TLS 的反應速度,目前是用來加速 Google Chrome 與 Google server 之間的連線。

與 SPDY 或 HTTP/2 不同的地方在於使用了 UDP,這降低了 TCP packet loss 造成的壅塞現象,以及 TCP 3-way handshake 的成本,而這兩點在行動平台上都特別明顯。

依照最新的說法,目前 Google Chrome 連到 Google server 大約有一半的連線會走 QUIC:「A QUIC update on Google’s experimental transport」。

Today, roughly half of all requests from Chrome to Google servers are served over QUIC and we’re continuing to ramp up QUIC traffic, eventually making it the default transport from Google clients — both Chrome and mobile apps — to Google servers.

而在 YouTube 的改善也很大:

These benefits are even more apparent for video services like YouTube. Users report 30% fewer rebuffers when watching videos over QUIC. This means less time spent staring at the spinner and more time watching videos.

由於效果不錯,他們打算要換更多...

AWS 跨區域搬大量資料的方式

AWS 跨區域搬資料有一堆方式,而官方今天在 blog 上推薦了用 Tsunami UDP 搬移的方式:「Moving Big Data into the Cloud with Tsunami UDP」。

看文章上的說明,看起來是從 Tokyo 搬到 Virginia (還是反過來?),有很穩定的 651Mbps 在傳輸 XD

看起來之後用的到,這個方法留起來參考...

ISP 架設 NAT 解決 IPv4 不夠的問題...

Slashdot 上看到 PlusNet 決定測試用 CGNAT (Carrier-grade NAT) 解決 IPv4 不夠的問題:「UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6」。

用超大型 NAT 並不是特別的新聞 (某些 mobile network 上就是這樣做),但 ISP 如果用在一般網路上則很有可能會跟客戶的 NAT device (可能是公司,也可能是家庭) 發生 Private Network 相同而導致問題。

2012 年 4 月的 RFC 6598 (IANA-Reserved IPv4 Prefix for Shared Address Space) 將 100.64.0.0/10 (Shared Address Space) 這個網段保留,拿來給營運 CGNAT 的 ISP 使用:

NetRange:       100.64.0.0 - 100.127.255.255
CIDR:           100.64.0.0/10
OriginAS:
NetName:        SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
NetHandle:      NET-100-64-0-0-1
Parent:         NET-100-0-0-0-0
NetType:        IANA Special Use

在 RFC 裡規定 100.64.0.0/10 只能拿來內部使用不得交換;如果要交換必須要有能力將不同介面的 100.64.0.0/10 當作不同網段 NAT (也就是 CGNAT 會做的事情):

In particular, Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.

另外文件裡還定義了使用 100.64.0.0/10 時對 DNS 的過濾。

如果 CGNAT 上不能打洞,那麼很多應用就很苦了 (得靠 UDP hole punching 打洞,這還得在沒有 randomized NAT port 的情況下才打的通),不過非 P2P 的應用應該不會有問題...

會不會做一做之後就維持這個方式?IPv6 遙遙無期... XD

把 SSH 換成 Mosh

Mosh 是一個取代 SSH (OpenSSH) 的工具,官方網站上是這樣介紹:

Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.

Mosh 最大的特性是透過 UDP 加密傳輸 (AES-128 OCB mode),而且不綁定 IP address 後設計出這些特性:

  • 筆電休眠後再打開電腦就可以直接連上。
  • 登入 VPN 造成 IP 改變後也沒關係。

另外 Mosh 模擬了 local echo 機制,就算在 latency 偏高的網路下也還是可以感覺到不錯的反應速度。

不過是到了 1.2 之後支援 --ssh 這個參數才變得好用,在 client 端只要這樣跑 (假設 ssh port 在 1234):

mosh --ssh="ssh -p 1234 -v" gslin@server.example.com --server="env LANG=en_US.UTF-8 mosh-server"

Mosh 就會用 ssh 登入後自動執行 mosh-server 取得 shared key 給 mosh-client 用。如果本來就有使用 public key 機制的話就跟原來沒差了 :p

預設吃 port 60000-61000 其中的一個 UDP port,所以記得開 firewall...