delay

OpenBSD 提供了關閉 Nagle's algorithm 的 sysctl 選項

看到「Demise of Nagle's algorithm (RFC 896 - Congestion Control) predicted via sysctl」這篇，OpenBSD 提供 sysctl 的選項直接關閉 Nagle's algorithm。

The below changeset introduces sysctl net.inet.tcp.nodelay, which if set to 1 will simply cause TCP_NODELAY to be set on all TCP sockets.

不過裡面提到了 John Nagle 在 2015 年的時候有在 Hacker News 上面回覆 (id=10608356)，大概介紹了一下背景，以及提出了他的看法：

That still irks me. The real problem is not tinygram prevention. It's ACK delays, and that stupid fixed timer. They both went into TCP around the same time, but independently. I did tinygram prevention (the Nagle algorithm) and Berkeley did delayed ACKs, both in the early 1980s. The combination of the two is awful. Unfortunately by the time I found about delayed ACKs, I had changed jobs, was out of networking, and doing a product for Autodesk on non-networked PCs.

然後翻了一下 John Nagle 的 Hacker News 帳號，看起來還蠻活躍的？常常 comment 一些東西...

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.

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