用示波器看 UDP 封包...

Hacker News Daily 上看到「From Oscilloscope to Wireshark: A UDP Story」這篇講怎麼用示波器挖出 UDP 封包的方法。不是用邏輯分析儀,而是用示波器...

上面示波器的圖片可以查到作者是用 Tektronix6 Series MSO,看起來停賣了,但類似的型號應該是百萬等級...

所以真的是打算從 L1 層一路解到 L4 層:

The rest of this post will take us from these raw voltage waveforms all the way to decoded UDP packets. Hold on tight, we're going from L1 all the way to L4.

網路設備是 VSC7448 這顆 52-port 10Gbps switch:

不過這邊提到一秒可以打 30K 的 UDP 封包出來,對於這台 switch 應該是沒滿才對,而且速度上應該也不到 10Gbps,加上作者提到的是 QSGMII,有可能是跑 1Gbps 的速度在抓:

The oscilloscope doesn't have a built-in QSGMII analyzer (and we'll want to do fairly sophisticated processing of the data), so I wanted to export waveform data to my computer.

I knew that a device on the network was emitting about 30K UDP packets per second, or one packet every 33 µs. I configured the oscilloscope to collect 100M samples at 1 TSPS (tera-sample per second, 1012), which multiplies out to 100 µs of data; this means we should catch 1-3 UDP packets.

看起來只是抓個意思意思練練手而已,抓 1 到 3 個 UDP 封包。

後面就是一堆數學處理... 看起來前面有一小段程式碼是 Python,但後面的程式碼有人知道是什麼語言嗎?

看起來這個月 HiNet 連外大概會不怎麼順...

Twitter 上看到這則障礙資料:

APG (Asia Pacific Gateway) 在 2016 年啟用,還算是新的海纜,看起來會有不少頻寬受到影響... 這點在 HiNet 上用 SmokePing 監控對 dynamodb.ap-southeast-1.amazonaws.com 的 packet loss 就很明顯的可以看出來了:

連過去封包掉的亂七八糟的,然後公司做東南亞生意,操作起來苦哈哈... 不過其他 ISP 看起來還行,應該有機會先繞過去。

台灣看 Lbry/Odysee 的速度變快一些

Twitter 上看到 jkgtw 提到 Lbry/Odysee 的速度快很多:

看了一下資料,HiNetcdn.lbryplayer.xyz 的 latency 增加了,但是 packet loss 改善了不少,看起來是把本來導去新加坡的流量改導去美國:

另外走 APOL 的 cable 這邊也有類似的情況,可以看出導去美國了:

測了一下影片觀看速度,1.5x 可以看,2x 還是放不太動,的確是比以前好不少。

Dropbox 測試 BBRv2 的結果

BBRv1 有不少問題,在 BBRv2 有一些改善 (目前還在測試階段,在「TCP BBR v2 Alpha/Preview Release」這邊可以看到一些說明),而 Dropbox 則是跳下去測試,並且公佈結果:「Evaluating BBRv2 on the Dropbox Edge Network」。

Spoiler alert: BBRv2 is slower than BBRv1 but that’s a good thing.

在文章開頭的這張圖就說明了 BBRv2 的速度比較慢,但是說明這是朝好的方向改善。

BBRv1 的問題其實我自己都有遇到:我自己的 Ubuntu 桌機跑 BBRv1,在我上傳大量資料的時候 (只開一條連線),會導致 PPPoE 的 health check 失敗,於是就斷線了,另外 VM 裡面的 Windows 7 因為也是 bridge mode 跑 PPPoE,也可以看到斷線嘗試重連的訊息,於是只好改掉...

上面提到的問題就是 BBRv1 造成 packet loss 過高,除了我遇到的問題外,這對於其他 loss-based 的 TCP congestion algorithm 來說會有很大的傷害 (i.e. 不公平):

Other tradeoffs were quite conceptual: BBRv1’s unfairness towards loss-based congestion controls (e.g. CUBIC, Compound), RTT-unfairness between BBRv1 flows, and (almost) total disregard for the packet loss:

另外一個改善是 BBRv2 加入了 ECN 機制,可以更清楚知道塞住的情況。

整體上來說應該會好不少,不知道之後正式釋出後會不會直接換掉 Linux Kernel 裡的 BBRv1,或是不換,讓 BBRv1 與 BBRv2 共存?

在 AWS 上用 pfSense 串接的細節

這邊講的是在 AWS 上想要串接不同帳號的流量 (也就是 site-to-site VPN),不使用 AWS 自己提供的串接服務,而是用 pfSense 串接。

會自己搞主要有幾個考慮:

  • 考慮到 AWS Transit Gateway 的費用,每掛一個上去就要多收一次錢,另外上面處理的流量要再收費。
  • 應用的流量不大,所以用個 t2.nano 跑也有個 100Mbps 左右的 capacity,算是夠用了。
  • 而且應用在寫的時候也考慮到斷線後的處理,加上用戶端的網路本來就不怎麼穩定,AWS Transit Gateway 的 SLA 再怎麼高,我也還是得處理斷線時的後續機制,不如就不要那麼緊張...

在設定的時候要注意的事情:

  • EC2 的 Source IP/Destination IP 檢查要關掉,這算是基本盤。
  • VPC 內的 Routing 要確認過一輪。
  • EC2 上的 Security Group 對於 pfSense 的主機得全開,因為 pfSense 會丟出不屬於他自己 IP address 的封包,也會接收不屬於自己 IP address 的封包 (透過上面提到的 routing),這些都還是會經過 Security Group 的檢查,而 Security Group 能設定的數量有限,基本上應該會全開...
  • pfSense 在設完 IPsec 後,同樣在 pfSense 上面的 firewall 需要手動加開,因為預設是關的。

其實這套作法就是在 AWS 還沒推出 Transit Gateway 前的作法,只是老方法還是很好用...

RFC8482 廢掉 DNS 查詢的 ANY query 了...

看到 Cloudflare 的「RFC8482 - Saying goodbye to ANY」這篇,裡面提到 RFC8482 廢掉了 ANY 查詢:「Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY」。

The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.

對 Cloudflare 的痛點主要在於營運上的困難,因為 ANY 回應的 UDP packet size 很大,很容易造成放大攻擊:

把拒絕 ANY 查詢變成標準後,讓 DNS provider 手上多了一把武器可以用。

新的 DNS Resolver:9.9.9.9

看到新的 DNS Resolver 服務,也拿到了還不錯的 IP address,9.9.9.9:「New “Quad9” DNS service blocks malicious domains for everyone」,服務網站是「Quad 9 | Internet Security and Privacy in a Few Easy Steps」,主打宣稱過濾已知的危險站台...

由政府單位、IBM 以及 Packet Clearing House 成立的:

The Global Cyber Alliance (GCA)—an organization founded by law enforcement and research organizations to help reduce cyber-crime—has partnered with IBM and Packet Clearing House to launch a free public Domain Name Service system.

也就是說,後面三家都不是專門做網路服務的廠商... 於是就會發現連 Client Subnet in DNS Queries (RFC 7871) 都沒提供,於是查出來的地區都不對,這對使用 DNS resolver 位置分配 CDN 節點的服務很傷啊... (或是其他類似服務)

這是 GooglePublic DNS (8.8.8.8) 查出來的:

;; ANSWER SECTION:
i.kfs.io.               576     IN      CNAME   kwc.kkcube.com.country.mp.kkcube.com.
kwc.kkcube.com.country.mp.kkcube.com. 21599 IN CNAME TW.kwc.kkcube.com.
TW.kwc.kkcube.com.      188     IN      CNAME   i.kfs.io.cdn.cloudflare.net.
i.kfs.io.cdn.cloudflare.net. 299 IN     A       104.16.244.238
i.kfs.io.cdn.cloudflare.net. 299 IN     A       104.16.245.238

;; Query time: 28 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Nov 18 05:30:23 CST 2017
;; MSG SIZE  rcvd: 181

這是 Quad9 (9.9.9.9) 查出來的:

;; ANSWER SECTION:
i.kfs.io.               1800    IN      CNAME   kwc.kkcube.com.country.mp.kkcube.com.
kwc.kkcube.com.country.mp.kkcube.com. 42702 IN CNAME US.kwc.kkcube.com.
US.kwc.kkcube.com.      300     IN      CNAME   i.kfs.io.cdn.cloudflare.net.
i.kfs.io.cdn.cloudflare.net. 300 IN     A       104.16.245.238
i.kfs.io.cdn.cloudflare.net. 300 IN     A       104.16.244.238

;; Query time: 294 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sat Nov 18 05:30:27 CST 2017
;; MSG SIZE  rcvd: 181

再來一點是,在科技領域相信政府單位通常都是一件錯誤的事情,我 pass... XD

Amazon S3 推出加速功能

Amazon S3 推出了新的加速功能,並且向更多地區提供 AWS Import/Export Snowball 服務:「AWS Storage Update – Amazon S3 Transfer Acceleration + Larger Snowballs in More Regions」。

其中的 Amazon S3 Transfer Acceleration 只要把本來的 BUCKET_NAME.s3.amazonaws.com 或是帶有地區的 BUCKET_NAME.s3-region.amazonaws.com 變成 BUCKET_NAME.s3-accelerate.amazonaws.com 就可以了,他會透過 CloudFront 的節點做 proxy,並且透過 AWS 內部最佳化過的網路傳輸。

由於這是定位為 Amazon S3 的服務,而實際測試後也確認不會有 cache:他的目的在於降低 latency 而加速,而不是 cache 加速,所以大量 GET 相同內容的部份應該還是用 CloudFront 會比較好。

再來是費用的部份增加相當多,第一筆要收的是 CloudFront 的費用,再來才是計算 Transfer Acceleration 的費用:

Transfer Acceleration pricing is in addition to Data Transfer pricing.

從 Internet 進 CloudFront 再進 Amazon S3 的要收 USD$0.04/GB (透過在美國、歐洲或是日本的 CloudFront 節點) 或 USD$0.08/GB (透過其他 CloudFront 節點)。

另外要收的是從 Amazon S3 一路傳到 Internet 的部份,USD$0.04/GB。如果是傳到其他 AWS region 的話,也是 USD$0.04/GB。

不過他有效能保證條款 (雖然掌控全不在自己),AWS 會持續監控有沒有比較快,如果沒有的話系統會 bypass 回原來的 Amazon S3:

Each time you use Transfer Acceleration to upload an object, we will check whether Transfer Acceleration is likely to be faster than a regular Amazon S3 transfer. If we determine that Transfer Acceleration is not likely to be faster than a regular Amazon S3 transfer of the same object to the same destination AWS region, we will not charge for that use of Transfer Acceleration for that transfer, and may bypass the Transfer Acceleration system for that upload.

我本來以為會是在 DNS 層 bypass 回本來的 region,結果發現是 307 redirect 重導回 Amazon S3 上,效能上應該還是會差一些...

可以看出這個架構的特性主要還是用在上傳的部份,而且用在網路不穩定的環境下很重要 (像是電信網路上的行動裝置),因為 latency 的減少會對於 packet loss 造成的 retry 有很大的幫助。

下載的部份應該會比本來 Amazon S3 快 (因為 Amazon 本身會加速),但由於沒有 cache,除非有特殊需求,不然建議不要這樣規劃。

另外一個是 AWS Import/Export Snowball 推出的新硬體,以及新區域。

新硬體是 80TB 的版本,本來只有 50TB 的版本:

The original Snowball appliances had a capacity of 50 terabytes. Today we are launching a newer appliance with 80 terabytes of capacity.

而新區域包括了 AWS GovCloud (US)、US West (Northern California)、Europe (Ireland) 以及 Asia Pacific (Sydney) 這三區:

Today we are making Snowball available in four new Regions: AWS GovCloud (US), US West (Northern California), Europe (Ireland), and Asia Pacific (Sydney). We expect to make Snowball available in the remaining AWS Regions in the coming year.

其中 80TB 版本只在這三區生效,其他區可以選擇 50TB 或是 80TB 版本:

If you are transferring data in or out of the US East (Northern Virginia), US West (Oregon), US West (Northern California), or AWS GovCloud (US) Regions using Snowball you can choose the desired capacity. If you are transferring data in or out of the Europe (Ireland) or Asia Pacific (Sydney) Regions, you will use the 80 terabyte appliance.

日本還是沒進場...

CloudWatch 可以看 EC2 Instance 的封包進出數量了

CloudWatch 可以監視 EC2 instance 的封包數量了:「Announcing New CloudWatch Metrics for EC2 Instances」:

The new metrics are NetworkPacketsIn and NetworkPacketsOut. These new metrics provide insight into the number of network packets flowing to and from an EC2 instance.

這樣對照流量時就可以知道平均封包大小了...

HTTP/2 測試工具

CloudFlare 整理了一篇「Tools for debugging, testing and using HTTP/2」,說明有哪些測試工具可以用...

Screen-Shot-2015-12-04-at-10-46-21

從最簡單的「HTTP/2 and SPDY indicator」(Google Chrome) 或是「HTTP/2 and SPDY indicator」(Firefox),到後面各式各樣的工具都有列出來。甚至還包括 command line 與 packet snooping 類的工具都有...