AWS 提供 VPC Traffic Mirroring 的功能

以前在機房可以在 switch 上用 port mirror 看流量內容找問題,現在在 AWS 上也提供類似的功能 VPC Traffic Mirroring:「New – VPC Traffic Mirroring – Capture & Inspect Network Traffic」。

所以所有以前在傳統機房使用 switch 的技術,都可以在 AWS 上重新發展出來,所以不算太意外的是第一波就有一堆 partner 提供服務,或是一些公司提供經驗。

另外 AWS 的 VPC Traffic Mirroring 比以前 switch 的 port mirror 更彈性,可以把整個網路當來源,或是指定特定的 ENI 當來源:

Mirror Source – An AWS network resource that exists within a particular VPC, and that can be used as the source of traffic. VPC Traffic Mirroring supports the use of Elastic Network Interfaces (ENIs) as mirror sources.

然後除了可以打到 ENI 上,也可以打到 NLB 上:

Mirror Target – An ENI or Network Load Balancer that serves as a destination for the mirrored traffic. The target can be in the same AWS account as the Mirror Source, or in a different account for implementation of the central-VPC model that I mentioned above.

不免俗的,可以過濾封包:

Mirror Filter – A specification of the inbound or outbound (with respect to the source) traffic that is to be captured (accepted) or skipped (rejected). The filter can specify a protocol, ranges for the source and destination ports, and CIDR blocks for the source and destination. Rules are numbered, and processed in order within the scope of a particular Mirror Session.

然後有判斷 session 的能力 (看這邊的敘述,應該就是指 stateful connection?):

Traffic Mirror Session – A connection between a mirror source and target that makes use of a filter. Sessions are numbered, evaluated in order, and the first match (accept or reject) is used to determine the fate of the packet. A given packet is sent to at most one target.

而且這一次公佈就幾乎開放所有區域了,費用看起來也不太貴:

VPC Traffic Mirroring is available now and you can start using it today in all commercial AWS Regions except Asia Pacific (Sydney), China (Beijing), and China (Ningxia). Support for those regions will be added soon. You pay an hourly fee (starting at $0.015 per hour) for each mirror source; see the VPC Pricing page for more info.

Tumblr 對 Yahoo! 流量的影響

也是在 Twitter 上看到的,Yahoo! (Oath) 決定對 Tumblr 上的 NSFW 類圖片下手後對流量的影響:

這張圖應該是出自「Traffic Analysis for port 36:"(36) Yahoo (AS 10310)"」這邊的資料,可以看到頗明顯的下降... 不過九月那個掉下來的部份又是什麼啊 :o

Sandvine 對全球網路流量的分析,那兩個是怎麼上榜的...

看到「Netflix Dominates Internet Traffic Worldwide, BitTorrent Ranks Fifth」這篇報導了 Sandvine 對全球網路流量的分析,主要是這張:

大多數的應用都不算意外 (只是差在各地區的使用習慣),但 AMERICAS 的第十名 (XBOX LIVE UPDATE) 跟 EMEA 的第七名 (PLAYSTATION DOWNLOAD) 是怎麼一回事 XDDD

依照交通時間,評估各種「地點」的服務...

Oalley 這個服務利用「交通時間」來評估地點,最簡單的應用像是給一個地點與時間,畫出範圍:

或是給多個點以及時間來評估地點:

不過後面是用 OpenStreetMap 的資料,我丟了幾個中文測試好像都找不到,用英文倒是可以...

CloudFront 在東京開到第八個點了...

看到 Amazon CloudFront 宣佈在東京開到第八個點了:「Amazon CloudFront launches eighth Edge location in Tokyo, Japan」。

Amazon CloudFront announces the addition of an eighth Edge location in Tokyo, Japan. The addition of another Edge location continues to expand CloudFront's capacity in the region, allowing us to serve increased volumes of web traffic.

這個成長速度有點驚人,一月才加了兩個,現在又要再加一個... 不過大阪還是維持一個。

各種道路設計對於流量的影響?

在「The rates of traffic flow on different kinds of 4-way intersections」這邊看到有趣的東西,利用遊戲 Cities: Skylines 模擬各種道路設計對流量的影響:

This is an animation of traffic flows simulated on 30 different kinds of four-way junctions, from two roads intersecting with no traffic lights or signs to complex stacked interchanges that feature very few interactions between individual cars. It was recorded in a game called Cities: Skylines, a more realistic take on SimCity.

影片在這:

記得這是模擬,實際情況會有其他考量,所以裡面的結果參考就好...

然後裡面有看到很多常見的設計,還有一些沒看過的神奇設計 XD 另外有些設計超級複雜,第一次開的人真的會知道怎麼開嗎 XDDD

俄羅斯的 BGP traffic reroute...

前幾天 (12 號) BGPmon 發現有很多知名的網段被導去俄羅斯:「Popular Destinations rerouted to Russia」。

Early this morning (UTC) our systems detected a suspicious event where many prefixes for high profile destinations were being announced by an unused Russian Autonomous System.

可以看到相當多知名的網段都被導走:

Starting at 04:43 (UTC) 80 prefixes normally announced by organizations such Google, Apple, Facebook, Microsoft, Twitch, NTT Communications and Riot Games were now detected in the global BGP routing tables with an Origin AS of 39523 (DV-LINK-AS), out of Russia.

從圖中也可以看出來 AS39523 透過 AS31133 發出這些 routing,然後主要是透過 AS6939 (Hurricane Electric) 擴散:

這幾年俄羅斯在網路上的動作多很多...

AWS CodeDeploy 支援在 AWS Lambda 上跑更多奇怪花樣

AWS Lambda 總算可以跟 AWS CodeDeploy 深度整合了:「AWS Lambda Supports Traffic Shifting and Phased Deployments with AWS CodeDeploy」。

像是兩個版本之間依照權重轉移:

You can now shift incoming traffic between two AWS Lambda function versions based on pre-assigned weights.

而把這個功能延伸就會是 Phased Deployments 了...

筑波快線因為提早 20 秒開車而道歉

居然是從 Hacker News Daily 上看到的:「Apology after Japanese train departs 20 seconds early」,引用的是官方的道歉文:「【お詫び】南流山駅における普通列車の早発について」。

平成29年11月14日(火)9時44分頃、第5255列車(秋葉原9時17分発、普通守谷行き)が、南流山駅に定刻9時43分40秒に到着。当該乗務員はドア開操作後、お客様の乗降取り扱いを行いました。その後、定刻9時44分40秒の発車のところ、発車時刻を十分に確認しないまま、ドア閉じ操作を行い、9時44分20秒に発車(出発操作)してしまいました。

これにより、駅時刻表との相違はなかったものの、定刻より約20秒早発するという事象が発生いたしました。なお、この件でお客様からの苦情等はありません。

更有趣的是 Hacker News 上的討論 (在這裡),一如既往的無法理解日本的鐵路與電車為什麼可以這麼準時 XDDD

日本電車要大幅延遲,最常見的就是人身事故以及暴雪暴雨之類的吧,營運方的問題不是很常看到... (不過這個案例是提前開車而道歉,純粹看討論時想到而已...)

Stream 對 .io 的感冒

Stream 的人寫了一篇「Why Stream Stopped Using .IO Domain Names for Production Traffic」表達他們對 .io 的感冒...

主要是因為 9/20 爛掉的情況不太妙。第一個是 .io 爛掉了兩個小時 (以月來算 SLA 就等於直接掉了 0.2% uptime,變成不到 99.8%),第二個是爛掉時 server 傳回的不是 SERVFAIL,而是 NXDOMAIN

The outage lasted for almost 2 hours, during which 1/5th of DNS queries for any .getstream.io record would fail.

他們的解法是改到 .com 上,畢竟影響的時候應該會修得比較快。另外文章裡也有延伸提到 Amazon Route 53 爛掉時要怎麼辦,如果他們真的決定要解決的話,應該是會拿出像「StackOverflow 對於多 DNS 商的同步方式...」或是「GitHub 也自己搞了一套管理多家 DNS 的程式...」的搞法吧。

不過這的確是當初選 .io 沒預料到的...