Tag: curl

cURL 放入 ipfs:// 支援

在 Hacker News 上看到 cURL 支援 ipfs:// 的消息：「IPFS support got merged into curl (twitter.com/bmann)」。

Hacker News 上有人提到這包支援的特性與問題：

This patch makes curl utilize a gateway for ipfs:// addresses. It prefers a local one but can also use public gateways. It makes no effort to verify that the final product's cryptographic hash corresponds to the one in the address.

依照說明是透過 gateway 處理，如果本地端有的話就用本地端的 gateway，不然就用 public gateway。另外就是沒有驗證 hash...

不算是原生支援，但還行...？

cURL 的 TLS fingerprint

看到「curl's TLS fingerprint」這篇，cURL 的作者 Daniel Stenberg 提到 TLS fingerprint。

先前在「修正 Curl 的 TLS handshake，避開 bot 偵測機制」與「curl 的 TLS fingerprint 偽裝專案 curl-impersonate 支援 Chrome 了」這邊有提到 curl-impersonate 這個專案，試著在 cURL 裡模擬市面上常見的瀏覽器的 TLS fingerprint。

在 Daniel Stenberg 的文章裡面也有提到這件事情，另外也提到了對 curl-impersonate 的態度：

I cannot say right now if any of the changes done for curl-impersonate will get merged into the upstream curl project, but it will also depend on what users want and how the use of TLS fingerprinting spread or changes going forward.

看起來短期內他是沒打算整，跟當初 curl-impersonate 的預期差不多...

25Gbps 下 HTTPS 的效率

作者家裡拉了 25Gbps 的 Internet 後 (可以參考先前寫的「25Gbps 的家用 Internet」這篇)，然後發現 Internet 上好像拉不動 25Gbps 的量，所以自己在家裡先測試了現在 HTTPS 的極限速度：「25 Gbit/s HTTP and HTTPS download speeds」。

Client 是 AMD 的 5600X，算是目前最新的世代；Server 則是 Intel 的 9900K，目前最新應該是 12 代；測試用 35GB 的檔案來測，然後使用 TCP BBR (這邊沒有特別講，目前 kernel 內建的還是 v1)。

在單條 HTTP 的情況下 curl + nginx 與 curl + caddy 都可以直接跑滿 (23.4Gbps)，Go 的 net/http 會卡在 20Gbps 左右。

如果是多條 HTTP 的話都可以跑滿 23.4Gbps。

但到了 HTTPS 的情況下最快的是 Go + net/http，可以跑到 12Gbps；curl + nginx 剩下 8Gbps；接下來 curl + caddy 的部份只有 7.5Gbps，而 go + caddy 只有 7.2Gbps。

上到多條 HTTPS 的情況大家都可以跑滿 23.4Gbps，除了 go + caddy 只能跑到 21.6Gbps。

另外作者試著用 kTLS 把 TLS 的工作丟進 kernel，就不需要全部在 nginx 內處理，速度基本上沒有太大變化，主要是降低了 CPU loading：

In terms of download speeds, there is no difference with or without KTLS. But, enabling KTLS noticeably reduces CPU usage, from ≈10% to a steady 2%.

算是一個有趣的發現，如果目前的 HTTPS 想要在 25Gbps 上面單線直接跑滿，還需要再 tune 不少東西...

curl 的 TLS fingerprint 偽裝專案 curl-impersonate 支援 Chrome 了

先前在「修正 Curl 的 TLS handshake，避開 bot 偵測機制」這邊提到 curl-impersonate 這個專案，試著修改 curl 的 TLS handshake fingerprint 讓偽裝的更好，本來只支援 Firefox，現在則是支援 Google Chrome 的 fingerprint 了...

作者寫的兩篇說明文章也可以看看：「Making curl impersonate Firefox」、「Impersonating Chrome, too」。

看起來愈來愈完整了，連 LD_PRELOAD 的用法也出現了，然後在 Arch Linux 上也出現 AUR 可以用了...

修正 Curl 的 TLS handshake，避開 bot 偵測機制

利用 TLS handshake 的 pattern 可以當作是某種 fingerprint，就可以知道你是用 Curl，這個方式在蠻多 CDN 都會用在 anti-bot 機制 (像是 Cloudflare)，而剛剛看到有人投稿自己的 patch，試著將 Curl 修改成 Firefox 的 pattern：「curl-impersonate」，Hacker News 上的討論在這邊可以看到：「Show HN: Curl modified to impersonate Firefox and mimic its TLS handshake (github.com/lwthiker)」。

作者有提到這次的 patch 偏 hack，不太可能整進上游，但希望未來改的乾淨一點，然後整進上游：

I hope to do so in the future, for now the implementation is extremely hacky so I doubt it can get accepted into curl.

另外有人提出來說應該要用 Firefox ESR 版本的 pattern 而非 stable channel，也有人提出來說用 Google Chrome 的更好，不過我覺得有人開始做就已經很棒了 XD

curl 的 command line 工具也要支援 JSON 格式了

Daniel Stenberg 在 curl 的 mailing list 上宣佈要支援 JSON 格式：「JSON support」，用法在「JSON awareness in the curl tool」在這邊可以看到，另外在 Hacker News 上的討論「The time might come when we add some JSON specific command line options (curl.se)」也可以翻翻。

討論裡面馬上有提到 HTTPie，這個套件基本上也算是標配了 (而且在各大 distribution 的 package 都有內建，直接裝就可以了)，可以看到主要是處理 POST 輸入時的 JSON 部份 (在 Content-Type: application/json 的情境下)，HTTP response 輸出的部份一般都還是用 jq 處理。

不過 curl 自己又定義了一套指定 JSON 內容的方式...

列出 curl 連線的內部時間資訊

在 Twitter 上看到一個很久前的討論：

裡面提到了「Timing Details With cURL」，可以給一個 template 進去輸出內部資訊：

time_namelookup: %{time_namelookup}
time_connect: %{time_connect}
time_appconnect: %{time_appconnect}
time_pretransfer: %{time_pretransfer}
time_redirect: %{time_redirect}
time_starttransfer: %{time_starttransfer}
———
time_total: %{time_total}

不過我實際測試發現現在的 curl 版本要加上 \n 才會換行，之後可以拿來 debug 看看...

cURL 與 Travis CI 的事件

前幾天 Daniel Stenberg (cURL 的發明人與現在的維護者) 發表一篇從 Travis CI 搬出來的文章，換到 Zuul CI 與 Circle CI 上：「Bye bye Travis CI」，對應的 Hacker News 的討論可以在「Bye Bye Travis CI (haxx.se)」這邊翻到。

文章裡提到主要的兩個點是，Travis CI 當初有承諾會提供免費服務給 open source project：

今年的時候整個 Travis CI 的商業收費的機制改了，另外也嚴格增加了對 open source project 的限制，包括了你不能收到任何商業公司或是任何組織的贊助：

Project must not be sponsored by a commercial company or organization (monetary or with employees paid to work on the project)

另外 Daniel Stenberg 在文章裡也表明目前不打算付錢，要找市場上便宜可用的方案 (而目前看起來還有，至少 Zuul CI 與 Circle CI 都在選項內)，所以就從 Travis CI 搬離了：

Lots of people have commented and think I’m “whining” about Travis CI charging for something that is useful and that I should rather just pay up. I could probably have gone with that but I dislike their broken promise and that they don’t consider us Open source anymore and I feel I have a responsibility to use the funds we get from gracious donors as wisely and economically as possible, and that includes using no-cost or cheap services rather than services charging thousands of dollars per year.

If there really were no other available and viable options, then paying could’ve been an alternative. Now, moving on to something else was the right choice for us.

然後 Travis CI 過了兩天丟出「Open Source Terms at Travis CI – An Update and Clarification」，雖然沒有表明是在講 cURL，但放在一起看其實也都大概知道發生什麼事情。

看了一下自己的小專案 (更新頻率不高，test case 也不多)，丟 Circle CI 還算是夠用，另外自己也有弄個 GitLab，需要的時候也可以在上面跑 CI。

這邊另外看到 cURL 這種大型專案，因為 test case 數量很多，丟到不同的 CI vendor 上跑，看起來是個還不錯的架構...

cURL 支援 Zstandard

在「curl 7.72.0 – more compression」這邊看到新版的 cURL 要支援 Zstandard 了，查了一下發現 Zstandard 有對應的 RFC，在 RFC 8478：「Zstandard Compression and the application/zstd Media Type」。

對應到 server 端的部份，看起來可以用 tokers/zstd-nginx-module 搭 (在 nginx 環境下)，不然就是 application 端要自己壓縮了。

不過普及率比較高的演算法是 Google 主導的 Brotli，查了一下壓縮率大概在同一個等級。

Facebook 沒有自家瀏覽器，推這些東西比較辛苦一點，但這次 cURL 決定支援 Zstandard 算是一個開始，讓開發者多了一個選擇可以用...

curl 將支援 DNS over HTTPS

curl 的維護者 Daniel Stenberg 在他的 blog 上宣佈 curl 將會支援 DNS over HTTPS：「DoH in curl」。

從給的範例可以看出來就是多一個 CURLOPT_DOH_URL 可以設，對於要用的人很簡單：

curl = curl_easy_init();
curl_easy_setopt(curl, CURLOPT_URL,
                 "https://curl.haxx.se/");
curl_easy_setopt(curl, CURLOPT_DOH_URL,
                 "https://doh.example.com/");
res = curl_easy_perform(curl);