delay

X/Twitter 在惡搞外部連結結果被抓包玩陰的

這算一個歷史記錄，現在已經改回來了...

在 Hacker News 上看到 X (前 Twitter) 惡搞他們不喜歡的外部連結，然後被抓包，以及恢復的故事：「Tell HN: t.co is adding a five-second delay to some domains」。

有人發現 t.co 指到 nytimes.com 或是 threads.net 的連結會有很固定的五秒 delay：

Go to Twitter and click on a link going to any url on "NYTimes.com" or "threads.net" and you'll see about a ~5 second delay before t.co forwards you to the right address.

Twitter won't ban domains they don't like but will waste your time if you visit them.

I've been tracking the NYT delay ever since it was added (8/4, roughly noon Pacific time), and the delay is so consistent it's obviously deliberate.

然後就被 Washington Post 報導出來了：「Elon Musk’s X is throttling traffic to websites he dislikes」，在報導後沒多久，這個機制就被取消掉了。

居然玩陰的 XDDD

用 FFmpeg 處理單聲道聲音產生空間感

先提供指令 (需要新版 FFmpeg)，把單聲道的 1.wav 加工成 2.wav (兩聲道)：

ffmpeg -i 1.wav -filter_complex '[0:0]stereotools=delay=20[aout]' -map '[aout]' -y 2.wav

這是看了『如何讓聲音有「立體感」？』後的實驗：

裡面提到要怎麼讓單聲道錄音產生空間感，其中一個方式是將單聲道的 audio stream 複製到兩邊，但讓左右聲道差 0.02 秒 (也就是 20ms)，讓兩邊聲音有些微差距而產生空間感。

查了資料後發現這個功能可以靠 FFmpeg 裡 stereotools 的 delay 達成：

delay

Set delay in milliseconds how much to delay left from right channel and vice versa. Default is 0. Allowed range is from -20 to 20.

但 Ubuntu 16.04 內的 FFmpeg 版本不夠新 (2.8.15)，測試時說沒有 stereotools 這個 filter，所以找了「FFMPEG 4 : Jonathon F」這個 PPA，改用 4.x 版的 FFmpeg 就可以用了。

算是找個機會玩看看... 另外也熟悉一下 FFmpeg 的 -filter_complex 到底是什麼語法。

Let's Encrypt 的 Wildcard Certificate 將會再延...

先前有提到 Let's Encrypt 的 Wildcard Certificate 從一月延到二月底 (表訂 2/27，參考先前的「Let's Encrypt 的 Wildcard SSL Certificate 延至二月底推出」這篇)，今天想說歐美的時區也差不多要過完 2/27 了，結果翻資料發現在「ACMEv2 and Wildcard Launch Delay」這邊又宣佈延期了，這次也不給時間了 XDDD

主要是 TLS-SNI 認證方式的前提有問題，導致 Let's Encrypt 臨時調度人力處理這個包 (可以參考「2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure」這篇，裡面有提到共用產生的問題假設)：

The biggest reason for this delay is the recent TLS-SNI deprecation. This unexpectedly pulled most engineering resources away from ACMEv2 and wildcard support for approximately two weeks.

然後 2/27 的說明提到目前是沒什麼大問題，但目前還在 QA 階段，然後目前先不給 release date：

Feb 27 Update: There are no known major issues with the ACMEv2/wildcard test endpoint. ACMEv2 and wildcard support quality assurance is continuing. No release date to announce yet.

就只能繼續等了... XD

Google 研發出的 BBR: Congestion-Based Congestion Control

Google 針對 TCP 的 congestion control 研究出了新的方法，是個純 sender-side 的演匴法，可以讓現有的 internet 直接換上去使用：「[net-next,14/14] tcp_bbr: add BBR congestion control」。

在 long-lived TCP connection 愈來愈普及後 (像是 HTTP/2)，TCP 連線的最佳化可以用統計模型來計算，這也就是 BBR 的想法：

In a nutshell, BBR creates an explicit model of the network pipe by sequentially probing the bottleneck bandwidth and RTT. On the arrival of each ACK, BBR derives the current delivery rate of the last round trip, and feeds it through a windowed max-filter to estimate the bottleneck bandwidth. Conversely it uses a windowed min-filter to estimate the round trip propagation delay. The max-filtered bandwidth and min-filtered RTT estimates form BBR's model of the network pipe.

不過 QUIC 不是也開始有進展了嗎？(參考「Google Chrome 52 預設開啟了更快的 QUIC (被戲稱為 TCP/2)」這篇)

感覺 QUIC 解決的比較徹底，不過 443/udp 的 firewall 問題的確也是個需要時間解決的課題...

前幾天 Gmail 收信延遲的問題...

前幾天 Gmail 可以正常運作，但一直收不到信的問題由官方發公告出來解釋了：「More On Gmail’s Delivery Delays」。

官方宣稱，這次的問題出自於兩個獨立的網路同時掛掉，造成 Gmail 的收信處理能力大幅下降：

The message delivery delays were triggered by a dual network failure. This is a very rare event in which two separate, redundant network paths both stop working at the same time. The two network failures were unrelated, but in combination they reduced Gmail’s capacity to deliver messages to users, and beginning at 5:54 a.m. PST messages started piling up.

最後是十個多小時後完全恢復。