Home » Posts tagged "udp"

HTTP-over-QUIC 將變成 HTTP/3

cURL 作者那邊看到的,之前 HTTP-over-QUIC 的名稱實在太長,想要找個短一點的名字來用,這邊算是把命字確定下來了:「HTTP/3」。從文章後的說明就可以看出來:

No more confusion. HTTP/3 is the coming new HTTP version that uses QUIC for transport!

不過這代表 HTTP/3 需要 443/udp 了,之後防火牆預設應該要打開...

解 ocserv 因為沒有使用 DTLS 而導致速度很慢的問題...

最近偏好用 ocserv 來跑 VPN。在連上 full-route VPN 後測試發現速度偏慢,發現是沒有走 UDP 的 DTLS,只有 TCP 的 TLS 流量... 找了一下發現用有人遇過了,可以用 workaround 解:「OpenConnect not working with DTLS」。

作者發現是 ocserv.socket 有問題,打算整個抽開。方法是註解掉 /lib/systemd/system/ocserv.service 裡的 Requires=ocserv.socketAlso=ocserv.socket,然後在 systemd 裡一起處理:

sudo systemctl stop ocserv
sudo systemctl disable ocserv.service
sudo systemctl disable ocserv.socket
sudo systemctl daemon-reload
sudo systemctl start ocserv
sudo systemctl enable ocserv

重新連上去後跑 tcpdump 可以看到是 UDP 了,測速也可以看出來快不少...

Cloudflare 決定支援 QUIC

Cloudflare 決定支援 QUIC 了:「Get a head start with QUIC」、「The QUICening」。

QUIC 目前被使用的範圍比較小 (相較於 HTTP/2):

  • 主流瀏覽器內只有 Google Chrome 有支援 QUIC,其他主流瀏覽器都沒有支援。不過 Google Chrome 也夠大了...
  • 因為是走 UDP,所以防火牆要另外開。

而 Google Chrome 上面可以安裝「HTTP/2 and SPDY indicator」看到連線的狀態。雖然套件名稱沒有 QUIC,但實際上是可以看出 QUIC 的,基本上 Google 的服務應該都是走 QUIC。

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.

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

Archives