Home » Computer » Archive by category "Network" (Page 5)

Cloudflare 推出在 HTTPS 下的壓縮機制

在 TLS (HTTPS) 環境下基本上都不能開壓縮,主要是為了避免 secret token 會因為 dictionary 的可預測性而被取出,像是 CRIMEBREACHTIMEHEIST (沒完結過...),而因為全面關閉壓縮,對於效能的影響很大。

Cloudflare 就試著去找方法,是否可以維持壓縮,但又不會洩漏 secret token 的方式,於是就有了這篇:「A Solution to Compression Oracles on the Web」。

重點在於 Our Solution 這段的開頭:

We decided to use selective compression, compressing only non-secret parts of a page, in order to stop the extraction of secret information from a page.

透過 regex 判斷那些東西屬於 secret token,然後對這些資料例外處理不要壓縮,而其他的部份就可以維持壓縮。這樣傳輸量仍然可以大幅下降,但不透漏 secret token。然後因為這個想法其實很特別,沒有被實證過,所以成立了 Challenge Site 讓大家打:

We have set up the challenge website compression.website with protection, and a clone of the site compression.website/unsafe without it. The page is a simple form with a per-client CSRF designed to emulate common CSRF protection. Using the example attack presented with the library we have shown that we are able to extract the CSRF from the size of request responses in the unprotected variant but we have not been able to extract it on the protected site. We welcome attempts to extract the CSRF without access to the unencrypted response.

這個方向如果可行的話,應該會有人發展一些標準讓 compression algorithm 不用猜哪些是 secret token,這樣一來就更能確保因為漏判而造成的 leaking...

出租 GPU 的服務...

前陣子在「Rent out your GPU compute to AI researchers and make ~2x more than mining the most profitable cryptocurrency.」這邊看到的消息,服務網站是「Vectordash: GPU instances for deep learning」。

起因是搞計算的弄不到顯卡計算,而雲服務的 GPU 又太貴,所以再找方法解決... 結果注意到 cryptocurrency 計算的獲利與雲服務的 GPU 中間有不少差價,於是就弄出一個服務來媒合手上有顯卡與需要科學計算的人,一邊提供較高的獲利給本來在挖礦的人,另外一邊提供較低的價錢給需要科學計算的人。

目前支援的平台有限 (Nvidia 的顯卡,另外不支援 Windows,不知道是不是 Linux only),其他支援目前都還沒列 ETA,不過感覺是個解決大家痛點的服務 (而且挖礦這邊就是在拼獲利),應該有機會弄得很大...

繼續觀望... XD

在 Amazon Aurora 利用 ProxySQL 的讀寫分離提昇效能

Percona 的「Leveraging ProxySQL with AWS Aurora to Improve Performance, Or How ProxySQL Out-performs Native Aurora Cluster Endpoints」這篇有夠長的,其實就是發現 AWSAmazon Aurora 只使用 Cluster Endpoint 無法壓榨出所有效能,只有當你讀寫分離拆開 Cluster endpoint 與 Reader endpoint 時才能提昇效能。主要是在推銷 ProxySQL 啦,其他的軟體應該也能達到類似的效果...

然後這張怪怪的,應該是 copy & paste 上去的關係?

因為事後再疊 ProxySQL 進去不會太困難,一般還是建議先直接用服務本身提供的 endpoint (少了一層要維護的設備),等到有遇到效能問題時再來看是卡在哪邊,如果是 R/W split 可以解決的,才用 ProxySQL 或是其他軟體來解...

Amazon DynamoDB 的 Point-In-Time Recovery

Amazon DynamoDB 在 3/26 發出來的功能,以秒為單位的備份與還原機制:「New – Amazon DynamoDB Continuous Backups and Point-In-Time Recovery (PITR)」。

先打開這個功能:

打開後就會開始記錄,最多可以還原 35 天內的任何一個時間點的資料:

DynamoDB can back up your data with per-second granularity and restore to any single second from the time PITR was enabled up to the prior 35 days.

這時候就算改變資料或是刪除資料,實際上在系統內都是 Copy-on-write 操作,所以需要另外的空間,這部份會另外計價:

Pricing for continuous backups is detailed on the DynamoDB Pricing Pages. Pricing varies by region and is based on the current size of the table and indexes. For example, in US East (N. Virginia) you pay $0.20 per GB based on the size of the data and all local secondary indexes.

有這樣的功能通常是一開始設計時就有考慮 (讓底層的資料結構可以很方便的達成這樣的效果),現在只是把功能實作出來... 像 MySQL 之類的軟體就沒辦法弄成這樣 XDDD

最後有提到支援的地區,是用條列的而不是說所有有 Amazon DynamoDB 的區域都支援:

PITR is available in the US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Canada (Central), EU (Frankfurt), EU (Ireland), EU (London), and South America (Sao Paulo) Regions starting today.

比對一下,應該是巴黎與美國政府用的區域沒進去... 一個是去年年底開幕的區域,另一個是本來上新功能就偏慢的區域。

Cloudflare 推出 1.1.1.1 的 DNS Resolver 服務

Cloudflare 推出了 1.1.1.1 上的 DNS Resolver 服務:「Announcing 1.1.1.1: the fastest, privacy-first consumer DNS service」,主打項目是隱私以及效能。

然後因為這個 IP 的特殊性,上面有不少奇怪的流量... 而 Cloudflare 跟 APNIC 交換條件後取得這個 IP address 的使用權 (然後 anycast 發出去):

APNIC's research group held the IP addresses 1.1.1.1 and 1.0.0.1. While the addresses were valid, so many people had entered them into various random systems that they were continuously overwhelmed by a flood of garbage traffic. APNIC wanted to study this garbage traffic but any time they'd tried to announce the IPs, the flood would overwhelm any conventional network.

We talked to the APNIC team about how we wanted to create a privacy-first, extremely fast DNS system. They thought it was a laudable goal. We offered Cloudflare's network to receive and study the garbage traffic in exchange for being able to offer a DNS resolver on the memorable IPs. And, with that, 1.1.1.1 was born.

Cloudflare 做了效能比較表 (與 Google Public DNSOpenDNS 比較),可以看到平均速度快不少:

在台灣的話,HiNet 非固定制 (也就是 PPPoE 連線的使用者) 連到 8.8.8.8 有奇怪的 latency:

可以比較同一台機器對 168.95.1.1 的反應速度:

不過如果你是 HiNet 固定制 (固 2 或是固 6 IP 那種,不透過 PPPoE,直接設定 IP address 使用 bridge mode 連線的使用者),兩者的 latency 就差不多,不知道是 Google 還是 HiNet 的架構造成的。

另外比較奇怪的一點是在文章最後面提到的 https://1.1.1.1/,理論上不會發 IP-based 的 SSL certificate 才對?不知道 CEO 老大是有什麼誤解... XD

Visit https://1.1.1.1/ from any device to get started with the Internet's fastest, privacy-first DNS service.

Update:查了資料發現是可以發的,只是大多數的 CA 沒有提供而已...

Percona 的人接受 AWS 的建議,重新測試了 Percona XtraDB Cluster 在 gp2 上的效能...

去年年底的時候 Percona 的人在 AWS 上測試 Percona XtraDB Cluster 的效能,尤其是針對底層應該選擇哪種 EBS 的部分給了一些建議。可以參考先前寫的「Percona 分析在 AWS 上跑 Percona XtraDB Cluster 的效能 (I/O bound)」這篇。

當時的建議是用 io1,雖然是比較貴,但對於效能比較好。

而後來 Percona 的人收到 AWS 工程師的建議,可以用另外一個方式,可以在 gp2 上拉出類似的效能,但成本會比 io1 低不少:「Percona XtraDB Cluster on Amazon GP2 Volumes」。

這個方式是利用 gp2 會依照空間大小,計算可用的 IOPS。在官方的文件裡是這樣描述 gp2 的效能 (IOPS):

General Purpose SSD (gp2) volumes offer cost-effective storage that is ideal for a broad range of workloads. These volumes deliver single-digit millisecond latencies and the ability to burst to 3,000 IOPS for extended periods of time. Between a minimum of 100 IOPS (at 33.33 GiB and below) and a maximum of 10,000 IOPS (at 3,334 GiB and above), baseline performance scales linearly at 3 IOPS per GiB of volume size. AWS designs gp2 volumes to deliver the provisioned performance 99% of the time. A gp2 volume can range in size from 1 GiB to 16 TiB.

在這個前提下,需要 10000 IOPS 的效能會需要 3.3TB 以上的空間,所以 Percona 就被 AWS 的工程師建議直接拉高空間重新測試:

After publishing our material, Amazon engineers pointed that we should try GP2 volumes with the size allocated to provide 10000 IOPS. If we allocated volumes with size 3.3 TiB or more, we should achieve 10000 IOPS.

首先是測出來的效能,可以看到沒有太大差異:

接下來就比較儲存成本,大約是 io1 版本的一半價錢:

如上面文件中提到的,gp1 不完全保證效能,但統計出來經常能夠提供出 3 IOPS/GB 的效能。而 io1 則是保證效能,不太需要擔心效能不穩定的問題。就是這個差異,反應到成本上面就有蠻大的差距。善用這點設計系統,應該會對整體成本有蠻大的幫助... (但對 latency 就未必了,尤其是 P99 之類的數值)

算是另外一種搞法讓大家可以考慮...

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。所以就來問問看有沒有人有建議...?

Facebook 在南韓因為太慢被罰錢???

看到「South Korea fines Facebook $369K for slowing user internet connections」這則新聞,裡面提到 Facebook 的 reroute 行為:

The Korea Communications Commission (KCC) began investigating Facebook last May and found that the company had illegally limited user access, as reported by ABC News. Local South Korean laws prohibit internet services from rerouting users’ connections to networks in Hong Kong and US instead of local ISPs without notifying those users. In a few cases, such rerouting slowed down users’ connections by as much as 4.5 times.

沒有告知使用者就導去香港或是美國的伺服器,聽起來像是 GeoDNS 的架構,以及 Facebook 的 CDN 架構幹的事情?不過在原報導裡面,另外一個指控是:

The KCC probed claims that Facebook intentionally slowed access while it negotiated network usage fees with internet service providers.

另外南韓官方也不承認使用者條款內的告知有效的:

Facebook said it did not violate the law in part because its terms of use say it cannot guarantee its services will operate without delays or interference. KCC officials rejected that argument, saying the terms were unfair. It recommended the company amend its terms of use.

現在看起來應該是要打官司?

TLS 1.3 進入 Proposed Standard

最近蠻熱的一個新聞,TLS 1.3 的 draft-ietf-tls-tls13-28.txt 進入 Proposed Standard 了 (在「draft-ietf-tls-tls13-28 - The Transport Layer Security (TLS) Protocol Version 1.3」這邊可以看到歷史記錄):「Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard (draft-ietf-tls-tls13-28.txt)」。

沒意外的話這就會是最終版本了。如果要看 TLS 1.2 與 TLS 1.3 的差異,看維基百科上的 Transport Layer Security - TLS 1.3 會比較清楚。

大家等很久了... 像是 OpenSSL 1.1.1 其實一部分也是在等 TLS 1.3 正式推出:(出自「Using TLS1.3 With OpenSSL」)

OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised. In the meantime the OpenSSL git master branch contains our development TLSv1.3 code which can be used for testing purposes (i.e. it is not for production use).

主要還是期待非 NSA 派系的 cipher (其實幾乎都是 djb 的戰果) 與 1-RTT handshake,後續等 TLS 1.3 變成 Standard Track 應該就會被各家瀏覽器開預設值了...

Archives