HTTP/3 (QUIC) 的反面看法

這篇整理了 HTTP/3 (QUIC) 的反面看法,算是常見的疑慮都列出來了:「QUIC and HTTP/3 : Too big to fail?!」。

其實大多都是使用 UDP 而導致的問題:

  • 因為 UDP 導致 firewall 可能沒開,以及可能會需要等 timeout 走回 TCP 的問題。
  • 因為 UDP 變成很多事情在 userland 處理,而導致的 CPU 使用率比使用 TCP 的 TLS 1.2/1.3 高很多。
  • 因為 UDP 導致 amplification attack 的安全性問題,以及對應的 workaround 產生的頻寬議題。
  • 由於 UDP 會需要自己控制擁塞,等於是在 UDP 上面又重做了一次 TCP congestion algorithm,而且因為重作所以得考慮與 TCP 搶資源的公平性。

整篇文章算是整理了一般對 HTTP/3 的疑慮,之後如果有進展的話,可以再拿出來當 checklist 再確認有哪些有改善...

fontconfig fallback 機制與 CSS font-family fallback 機制的衝突...

自己搞不定,加上需要有圖才比較好理解,所以發篇文章問看看...

起因是在 Twitter 上發現某篇文章的截圖,在我的機器上顯示是 sans-serif 類的字型,而對方顯示的是 serif (看起來像是 Mac 的機器上):

而翻了網站本身的 CSS 設定,發現是設成 serif,所以表示我這邊的設定有問題...

找了些資料並且測試,發現是 Linuxfontconfig 所設計的 fallback 機制跟一般人認知的不一樣,使得 CSS font-family fallback 機制直接失效...

在那篇文章的 font-family 設定是「medium-content-serif-font,Georgia,Cambria,"Times New Roman",Times,serif」,所以你會假設 medium-content-serif-font (這是 Medium 設定的 web fonts) 內沒有的字型會去 Georgia 找,然後依序是 CambriaTimes New RomanTimes,最後到 serif

但在 Linux 下的 fontconfig 的設計則跟這點衝突。當你丟 medium-content-serif-font 查詢時,系統會將全系統有的字型都給你 (但是排序好),而不是只有找 medium-content-serif-font 這個字型:

gslin@GSLIN-HOME [~] [22:11/W2] fc-match -s 'medium-content-serif-font' | wc -l
122
gslin@GSLIN-HOME [~] [22:11/W2] fc-match -s 'medium-content-serif-font' | head 
FreeMono.ttf: "FreeMono" "Regular"
FreeSans.ttf: "FreeSans" "Regular"
FreeSerif.ttf: "FreeSerif" "Regular"
opens___.ttf: "OpenSymbol" "Regular"
LinLibertine_R_G.ttf: "Linux Libertine G" "Regular"
Norasi.ttf: "Norasi" "Regular"
KacstOne.ttf: "KacstOne" "Regular"
FiraSans-Regular.otf: "Fira Sans" "Regular"
NanumGothic.ttf: "NanumGothic" "Regular"
fonts-japanese-gothic.ttf: "TakaoPGothic" "Regular"

而因為將所有系統內有的字型都放進去了,所以 font-family 第二個設定基本上都沒用了,因為我裝了一堆語系的文字... Orz

而我想要關閉這套機制,卻發現看起來關不掉:「How to block glyph fallback on Linux?」。

後來想要找 workaround 來解這個問題,不過看起來沒有堪用的 workaround。所以就來問問看有沒有人有建議...?