throttle

X/Twitter 又繼續在搞競爭對手的外部連結了...

八月的時候提過「X/Twitter 在惡搞外部連結結果被抓包玩陰的」這個，X (Twitter) 故意對某些網站 delay 個幾秒鐘再重導，當時爆料出來後就馬上拿掉了，結果這幾天又被抓到故技重施：「Twitter is Still Throttling Competitors’ Links—Check for Yourself」。

依照測試，Meta 家的 Facebook、Instagram 以及 Threads 都中獎，另外沒什麼意外的，Twitter 前頭頭跳出來開的 Bluesky 也都有被搞...

而且這次爆料出來後也沒有「迅速修正」了，到目前也都還是如此... 來看看後續？

下載 YouTube 影片的技術限制與繞過方法

Hacker News 上看到這篇「How They Bypass YouTube Video Download Throttling」在講 YouTube 防止下載的各種方式。

透過 API 拿到的 URL 直接抓很慢，大約 40-70KB/sec：

However, attempting to download from this URL leads to really slow download:

The speed is always limited to around 40-70kB/s.

這邊需要一個 javascript 環境計算出 n，帶入後續的 request 以「證明」你是官方的網頁 client：

Since mid-2021, YouTube has included the query parameter n in the majority of file URLs. This parameter needs to be transformed using a JavaScript algorithm located in the file base.js, which is distributed with the web page. YouTube utilizes this parameter as a challenge to verify that the download originates from an “official” client. If the challenge is not resolved and n is not transformed correctly, YouTube will silently apply throttling to the video download.

The JavaScript algorithm is obfuscated and changes frequently, so it’s not practical to attempt reverse engineering to understand it. The solution is simply to download the JavaScript file, extract the algorithm code, and execute it by passing the n parameter to it. The following code accomplishes this.

但即使算出 n，也還是會限速，可以看到作者策出來大約是 4MB/sec，雖然比以前快很多了，但還是看得出來有限速。這主要是避免 client 端過度 buffer 浪費頻寬：

With this new URL containing the correctly transformed n parameter, the next step is to download the video. However, YouTube still enforces a throttling rule. This rule imposes a variable download speed limit based on the size and length of the video, aiming to provide a download time that’s approximately half the duration of the video. This aligns with the streaming nature of videos. It would be a massive waste of bandwidth for YouTube to always provide the media file as quickly as possible.

接下來的方式就是利用 Range 拆成很多個 HTTP request 打，這樣因為 buffering algorithm 在開始限速前會先全速塞資料給你，就可以用這點避開限速的問題了。

把多的 request 與處理時間都算進去後，整體大約可以到 50-70MB/sec，算是可以接受的下載速度了：

However, the average speeds typically ranged between 50-70 MB/s or 400-560 Mb/s, which is still pretty fast.

後面有一些合併處理的指令 (因為 YouTube 會把影與音分離成兩個檔案)，就不是重點了...

全世界都一樣：開 Speedtest 可以讓網路速度變快

在 Hacker News Daily 上看到開 Speedtest 可以讓速度變快的討論：「Ask HN: Internet magically gets faster when opening speedtest?」。

先前在「Cloudflare 也推出自己的 Speed Test 服務」這篇也有提到遠傳的 Speedtest 加速法：「[心得] 在Android破解遠X限速」，裡面有 Android 的解法，推文有 iOS 的解法，不過這都舊文章了，不確定現在還有沒有用...

HiNet 開始提供 2G/1G 的線路

HiNet 開始提供 2G/1G 的線路了，但在企業上網的「HiNet企業上網促銷網站」這邊還沒看到 2G/1G 的方案，反倒是在一般家用的「HiNet光世代 2G/1G HiLight極速方案 | 中華電信網路門市 CHT.com.tw」這邊可以看到了，不過有些地方得注意。

首先是「家用型」(NTD$3,069/month) 是有限制流量的：

2G/1G家用型(非固定制)僅供自然人以個人證號提出申請。如連續3日每日訊務量(上下行加總)皆超過200GB，本公司得於通知後，於其後連續2日調整服務速率上限為100Mbps/40Mbps(Best Effort)，調整速率期滿後恢復申辦速率。

如果想要將頻寬灌好灌滿的話，得裝「進階型」(NTD$5,299/month)，另外一個問題是「家用型」不支援 PPPoE 固定 IP 服務 (i.e. 非固固)：

2G/1G進階型(非固定制)得自行上網申請非固定制之固定IP，換言之有動態IP 16個或固定IP 1個+動態IP 15個此二種型態供客戶選擇，前述非固定制之固定IP，本公司有權於下列情況發生者，重新配發新的固定IP取代原本之固定IP。

目前的 1G/600M 是可以申請一個非固固的，這樣誘因又少了些。

另外看了一下目前 1G/600M 的優惠價是 NTD$2,399/month，所以意思是，租兩條頻寬還比較多 (2G/1.2G)，還比較便宜 (NTD$4,798/month)，而且有兩個固定 IP？

Ptt 上的「Re: [情報] 中華電信將推2G/1G光世代上網新服務，每月最低3069元起」這篇裡面也有不少討論，看起來這個方案有得吵了 XD

這幾天 blog 被掃，用 nginx 的 limit_req_zone 擋...

Update：這個方法問題好像還是不少，目前先拿掉了...

這幾天 blog 被掃中單一頁面負載會比較重的頁面，結果 CPU loading 變超高，從後台可以看到常常滿載：

看了一下是都是從 Azure 上面打過來的，有好幾組都在打，IP address 每隔一段時間就會變，所以單純用 firewall 擋 IP address 的方法看起來沒用...

印象中 nginx 本身可以 rate limit，搜了一下文件可以翻到應該就是「Module ngx_http_limit_req_module」這個，就設起來暫時用這個方式擋著，大概是這樣：

limit_conn_status 429;
limit_req_status 429;
limit_req_zone $binary_remote_addr zone=myzone:10m rate=10r/m;

其中預設是傳回 5xx 系列的 service unavailable，但這邊用 429 應該更正確，從維基百科的「List of HTTP status codes」這邊可以看到不錯的說明：

429 Too Many Requests (RFC 6585)
The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.

然後 virtual host 的設定檔內把某個 path 放進這個 zone 保護起來，目前比較困擾的是需要 copy & paste try_files 與 FastCGI 相關的設定：

    location /path/subpath {
        limit_req zone=myzone;
        try_files $uri $uri/ /index.php?$args;

        include fastcgi.conf;
        fastcgi_intercept_errors on;
        fastcgi_pass php74;
    }

這樣一來就可以自動擋下這些狂抽猛送的 bot，至少在現階段應該還是有用的...

如果之後有遇到其他手法的話，再見招拆招看看要怎麼再加強 :o