Tag: stack

Happy Eyeballs (RFC 6555)

在「PChome 24h 連線會慢的原因...」這篇的 comment 有讀者提到了 Happy Eyeballs 應該可以解決這個問題：

除了可以在維基百科上面看到外，比較正式的說明可以參考 RFC 6555：「Happy Eyeballs: Success with Dual-Stack Hosts」，其中在「6. Example Algorithm」就有提到 Google Chrome 與 Mozilla Firefox 怎麼實做 Happy Eyeballs：

What follows is the algorithm implemented in Google Chrome and Mozilla Firefox.

  1. Call getaddinfo(), which returns a list of IP addresses sorted by the host's address preference policy.
  2. Initiate a connection attempt with the first address in that list (e.g., IPv6).
  3. If that connection does not complete within a short period of time (Firefox and Chrome use 300 ms), initiate a connection attempt with the first address belonging to the other address family (e.g., IPv4).
  4. The first connection that is established is used. The other connection is discarded.

If an algorithm were to cache connection success/failure, the caching would occur after step 4 determined which connection was successful.

Other example algorithms include [Perreault] and [Andrews].

可以看到 Happy Eyeballs 的演算法是要避免 IPv6 network 不通的情況卡住很慢 (如果在 300ms 內連線沒有建起來，就會儘快往另外一個 address family 嘗試)，而不是在 DNS 層避免問題 (也就是 getaddinfo() 觸發的 DNS query)。

這次的情況是 DNS query 很慢，就會導致還是一開始就很慢，Happy Eyeballs 沒辦法解決這個問題。

不過話說回來，我是有印象知道有這個演算法，但不知道有「Happy Eyeballs」這個這麼逗趣的名字... (掩面)

Python 在高收入國家的成長

Stack Overflow 的內文其實有點奇怪的誤導... 主要是分析在 Stack Overflow 上 Python 成長的趨勢：「The Incredible Growth of Python」。

但一開始的分析是做高收入國家的部份：

但如果你捲到最下面，即使是非高收入的國家也是一樣急遽成長，只是沒那麼明顯：

Anyway，回到高收入國家的部份，如果用模型預測的話：

另外列出 YoY 成長：

這篇用高收入這個分法有種在炒話題的感覺...

「把工作自動化」的討論

最近在 The Workplace Stack Exchange 上還蠻火紅的一篇文章：「Is it unethical for me to not tell my employer I’ve automated my job?」。

作者的全職工作是從系統上抓資料出來，貼到 spreadsheet 上 (也許是 Excel？)，這份工作的薪資還不錯，然後作者寫程式自動化掉後發現他每禮拜只需要做一兩個小時了：

There might be amendments to the spec and corresponding though email etc, but overall, I spend probably 1-2 hours per week on my job for which I am getting a full time wage.

然後在糾結要不要跟雇主講，跑上來發文 XDDD 有興趣的人可以去圍觀看一看下面的回應...

最近 OpenVPN 的安全性漏洞...

看到「The OpenVPN post-audit bug bonanza」這個只有苦笑啊...

作者在 OpenVPN 經過一連串的安全加強後 (包括 harden 計畫與兩個外部單位的程式碼稽核找到不少問題)，決定出手挖看看：

After a hardening of the OpenVPN code (as commissioned by the Dutch intelligence service AIVD) and two recent audits 1 2, I thought it was now time for some real action ;).

然後就挖出不少問題了...

可以看到作者透過 fuzzing 打出一卡車，包含了不少 crash XDDD：(然後有一個是 stack buffer corruption，不知道有沒有機會變成 RCE)

  • Remote server crashes/double-free/memory leaks in certificate processing (CVE-2017-7521)
  • Remote (including MITM) client crash, data leak (CVE-2017-7520)
  • Remote (including MITM) client stack buffer corruption
  • Remote server crash (forced assertion failure) (CVE-2017-7508)
  • Crash mbed TLS/PolarSSL-based server (CVE-2017-7522)
  • Stack buffer overflow if long –tls-cipher is given

StackOverflow 預設全上 HTTPS 了...

用 HTTPS Everywhere 沒什麼感覺，但對於一般人應該不簡單，所以 Nick Craver (根本就是他們家非正式的 PR Engineer XDD 他這幾年寫了不少內部的資訊...) 寫了一篇關於上 HTTPS 的故事：「HTTPS on Stack Overflow: The End of a Long Road」。

其中他們為了支援舊設備 (沒有支援 SNI 的)，決定直接把所有 wildcard 類的 SSL certificate 都包進去 (另外找 DigiCert 處理)：

然後中間提到這個真的頗無奈的，抱怨 SVG 的 XML... XDDD：

Finding and killing these was a little fun because you can’t just search for "http://". Thank you so much W3C for gems like this:

<svg xmlns="http://www.w3.org/2000/svg"...

一條辛苦路 XD

StackOverflow 上離開 Vim 方法的文章...

被拿出來當 PR 宣傳了：「Stack Overflow: Helping One Million Developers Exit Vim」。

由於 Vim 是 Unix-like 系統一定會內建的 editor，所以常常被拿來放在 tutorial 裡面 (考慮到普及性，但完全不熟的初學者就...)，或是不小心在輸入 vipw 或是 visudo 之類的指令就中獎了：

可以看到 pageview 破一百萬次了 XDDD 而且流量也都很穩定：

依照地區來拆開的話：(不過沒有照人口數正規化...)

然後做交叉分析，看這些卡在 Vim 的人平常是看什麼其他的文章：

回到資料分析的角度來看，這些東西可以透過有 cookie 的 access log 做到。有 access log 後可以用 Google Cloud 的 BigQuery，也可以用 AWS 家的 Amazon Athena 做。

iOS 透過無線網路的 RCE...

在「About the security content of iOS 10.3.1」這邊的說明：

Available for: iPhone 5 and later, iPad 4th generation and later, iPod touch 6th generation and later
Impact: An attacker within range may be able to execute arbitrary code on the Wi-Fi chip
Description: A stack buffer overflow was addressed through improved input validation.
CVE-2017-6975: Gal Beniamini of Google Project Zero

這描述看起來就不太妙...

Go 1.9 的 GC 改善

Update：被提醒後仔細看了一下，是 1.8 預設生效 (但保留選項切回來 debug)，如果沒問題的話 1.9 把舊的方式拔乾淨：

Assuming things go smoothly, we will remove stack re-scanning support when the tree opens for Go 1.9 development.

標題就不改了... 以下原文。

在「Sub-millisecond GC pauses」這邊看到的。Golang 想辦法將 GC 造成的影響降低：「Proposal: Eliminate STW stack re-scanning」。

目標是解決最大的 GC pause 來源：

As of Go 1.7, the one remaining source of unbounded and potentially non-trivial stop-the-world (STW) time is stack re-scanning.

然後拿新的解法來戰，目前初步的測試看起來可以降到 50µs (== 0.05ms)：

We propose to eliminate the need for stack re-scanning by switching to a hybrid write barrier that combines a Yuasa-style deletion write barrier [Yuasa '90] and a Dijkstra-style insertion write barrier [Dijkstra '78]. Preliminary experiments show that this can reduce worst-case STW time to under 50µs, and this approach may make it practical to eliminate STW mark termination altogether.

在「runtime: eliminate stack rescanning · Issue #17503 · golang/go」這邊可以看到進度，現在已經在 master branch 上了，看起來會在 1.9 的時候被放出來... 不過 worst case 的時間上修了 XDDD

The high level summary is that this reduces worst-case STW time to about 100 µs and typical 95%ile STW time to 50 µs (assuming, of course, that the OS doesn't get in the way and that the system isn't otherwise overloaded).

但看起來應該還是很大的效能改善，尤其是 CPU bound 的應用？

在 Command Line 跟 Stack Overflow 互動

在 Hacker News Daily 上看到可以在 command line 跟 Stack Overflow 互動的工具：「stackoverflow from the terminal」。

可以用 npm 安裝。

作者引用了 xkcd 的笑話來說明為什麼要開發這個程式：

出自「tar」

RightScale 介紹的 TrackJS

RightScale 介紹了 TrackJS 這個服務：「Why do we use TrackJS」。

可以看發生錯誤的 stack：

有錯誤的綜合分析：

然後可以將 minified 的 JS 試著展開，讀起來會比較容易，不過沒看到對 source map 的支援？

價位上比 Rollbar 低不少 ($249 在 TrackJS 可以記 10M，但在 Rollbar 只能記 1.5M)，不過 Rollbar 支援的平台比較多 (台灣也有代理商可以開發票處理帳務)，也許找機會用看看 TrackJS 再決定吧。