Home » Posts tagged "network" (Page 2)

Facebook 觀察 IPv6 的使用情況

Facebook 是在六年前啟用了 IPv6 服務,然後分析了現在各地區 IPv6 使用的情況:「How IPv6 deployment is growing in U.S. and other countries」,另外提供了統計系統的資料給大家查 (不過看起來只有二月以後的?):「Facebook IPv6」。

然後被提到台灣區的成長在這幾個月很快速,主要原因是中華電信的導入:

We are also seeing countries and regions with less mature internet infrastructure start to transition to IPv6. Although overall deployment is still low, recent growth in some places has been exponential. Taiwan, for example, has gone from less than 1 percent in February 2018 to more than 10 percent as of May 28, 2018. Taiwan's rapid growth directly corresponds to recent IPv6 initiatives by Chunghwa, Taiwan's largest ISP.

先前在 Twitter 上有提到中華在 www.ipv6.hinet.net 網站上的跑馬燈有公告關於 IPv6 的導入,所以到這個月月底,使用比率應該都還會有明顯的提昇:

因為 Windows 7 以上的系統直接 PPPoE 的應該都會拿到 IPv6 address,但如果是 IP 分享器的就不一定支援了,不然應該會更高...

另外行動網路的部份也陸陸續續在轉移了,像我的 blog 上可以看到有 emome-ip6.hinet.net 的訪客,而且 Google 搜尋也可以看到一些資訊了:「"emome-ip6.hinet.net" - Google 搜尋」。

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.

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

Microsoft 啟用自己的 CDN 了...

在朋友的 tweet 裡看到微軟啟用自己的 Azure CDN 了,先前應該是提供 AkamaiEdgeCast 的服務:「Announcing Microsoft's own Content Delivery Network」。

看圖似乎是有台灣的點,不過我找不到可以測試 traceroute 的 endpoint,頁面上用的圖還是 EdgeCast 的啊 XDDD

;; ANSWER SECTION:
azurecomcdn.azureedge.net. 1604 IN      CNAME   azurecomcdn.ec.azureedge.net.
azurecomcdn.ec.azureedge.net. 3404 IN   CNAME   cs9.wpc.v0cdn.net.
cs9.wpc.v0cdn.net.      3404    IN      A       117.18.232.200

然後公測期間優惠價 50%:

Azure Content Delivery Network Standard from Verizon (S1) and Akamai (S2) and Microsoft (S3)*
*S3 is currently in public preview. CDN rates will be 50% of the stated price during this period.

Cloudflare 推出 Spectrum:65535 個 TCP Port 都可以轉的 Proxy...

Cloudflare 推出了 Spectrum,文章標題提到的 65533 應該是指 80 & 443 以外其他的 port:「Introducing Spectrum: Extending Cloudflare To 65,533 More Ports」。

然後因為 TCP proxy 不像 HTTP proxy 與 WebSocket proxy 可以靠 Host header 資訊判斷,在 TCP proxy 需要獨占 IP address 使用 (i.e. 一個 IP address 只能給一個客戶用),而因為 IPv4 address 不夠的關係,這個功能只開放給 Enterprise 客戶用:

Today we are introducing Spectrum, which brings Cloudflare’s security and acceleration to the whole spectrum of TCP ports and protocols for our Enterprise customers.

雖然現在限定在 Enterprise 客戶,但 Cloudflare 還是希望看看有沒有其他想法,目前提出來的選項包括了開放 IPv6 address 給所有人用,或是變成獨立付費項目:

Why just Enterprise? While HTTP can use the Host header to identify services, TCP relies on each service having a unique IP address in order to identify it. Since IPv4 addresses are endangered, it’s quite expensive for us to delegate an IP per application and we needed to limit use. We’re actively thinking about ways to bring Spectrum to everyone. One idea is to offer IPv6-only Spectrum to non-Enterprise customers. Another idea is let anyone use Spectrum but pay for the IPv4 address. We’re not sure yet, but if you prefer one to the other, feel free to comment and let us know.

類似的產品應該是 clean pipe 類的服務,但一般 clean pipe 是透過 routing 重導清洗流量,而非像 Cloudflare 這樣設計... 不知道後續會有什麼樣的變化。

Cloudflare 推出 Argo Tunnel

Cloudflare 推出了 Argo Tunnel,可以將內部網路與 Cloudflare 之間打通:「Argo Tunnel: A Private Link to the Public Internet」。

Cloudflare 在去年推出了 Wrap (可以參考「Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443」這篇),這次其實只是改名:

During the beta period, Argo Tunnel went under a different name: Warp. While we liked Warp as a name, as soon as we realized that it made sense to bundle Warp with Argo, we wanted it to be under the Argo product name. Plus, a tunnel is what the product is so it's more descriptive.

看起來沒有什麼新的玩意... 純粹改名字 :o

Cloudflare 推出 1.1.1.1 的 DNS Resolver 服務

Cloudflare 推出了 1.1.1.1 上的 DNS Resolver 服務:「Announcing 1.1.1.1: the fastest, privacy-first consumer DNS service」,主打項目是隱私以及效能。

然後因為這個 IP 的特殊性,上面有不少奇怪的流量... 而 Cloudflare 跟 APNIC 交換條件後取得這個 IP address 的使用權 (然後 anycast 發出去):

APNIC's research group held the IP addresses 1.1.1.1 and 1.0.0.1. While the addresses were valid, so many people had entered them into various random systems that they were continuously overwhelmed by a flood of garbage traffic. APNIC wanted to study this garbage traffic but any time they'd tried to announce the IPs, the flood would overwhelm any conventional network.

We talked to the APNIC team about how we wanted to create a privacy-first, extremely fast DNS system. They thought it was a laudable goal. We offered Cloudflare's network to receive and study the garbage traffic in exchange for being able to offer a DNS resolver on the memorable IPs. And, with that, 1.1.1.1 was born.

Cloudflare 做了效能比較表 (與 Google Public DNSOpenDNS 比較),可以看到平均速度快不少:

在台灣的話,HiNet 非固定制 (也就是 PPPoE 連線的使用者) 連到 8.8.8.8 有奇怪的 latency:

可以比較同一台機器對 168.95.1.1 的反應速度:

不過如果你是 HiNet 固定制 (固 2 或是固 6 IP 那種,不透過 PPPoE,直接設定 IP address 使用 bridge mode 連線的使用者),兩者的 latency 就差不多,不知道是 Google 還是 HiNet 的架構造成的。

另外比較奇怪的一點是在文章最後面提到的 https://1.1.1.1/,理論上不會發 IP-based 的 SSL certificate 才對?不知道 CEO 老大是有什麼誤解... XD

Visit https://1.1.1.1/ from any device to get started with the Internet's fastest, privacy-first DNS service.

Update:查了資料發現是可以發的,只是大多數的 CA 沒有提供而已...

Facebook 在南韓因為太慢被罰錢???

看到「South Korea fines Facebook $369K for slowing user internet connections」這則新聞,裡面提到 Facebook 的 reroute 行為:

The Korea Communications Commission (KCC) began investigating Facebook last May and found that the company had illegally limited user access, as reported by ABC News. Local South Korean laws prohibit internet services from rerouting users’ connections to networks in Hong Kong and US instead of local ISPs without notifying those users. In a few cases, such rerouting slowed down users’ connections by as much as 4.5 times.

沒有告知使用者就導去香港或是美國的伺服器,聽起來像是 GeoDNS 的架構,以及 Facebook 的 CDN 架構幹的事情?不過在原報導裡面,另外一個指控是:

The KCC probed claims that Facebook intentionally slowed access while it negotiated network usage fees with internet service providers.

另外南韓官方也不承認使用者條款內的告知有效的:

Facebook said it did not violate the law in part because its terms of use say it cannot guarantee its services will operate without delays or interference. KCC officials rejected that argument, saying the terms were unfair. It recommended the company amend its terms of use.

現在看起來應該是要打官司?

Raspberry Pi 3 的新版本 Model B+

Raspberry Pi 3 推出了 Model B+ 的新版本:「Raspberry Pi 3 Model B+ on sale now at $35」。

除了 CPU 速度稍微快一些以外,另外支援了 802.11ac/5Ghz 的無線網路 (官方宣稱可以跑到 ~102Mbps,相較於先前在 2.4Ghz 只能跑到 ~35Mbps),以及更快的有線網路 (官方宣稱可以跑到 ~315Mbps,相較於先前的 ~95Mbps)。

然後是支援 PXE

Raspberry Pi 3B was our first product to support PXE Ethernet boot. Testing it in the wild shook out a number of compatibility issues with particular switches and traffic environments. Gordon has rolled up fixes for all known issues into the BCM2837B0 boot ROM, and PXE boot is now enabled by default.

以及支援 PoE 直接推動整台機器:

We use a magjack that supports Power over Ethernet (PoE), and bring the relevant signals to a new 4-pin header. We will shortly launch a PoE HAT which can generate the 5V necessary to power the Raspberry Pi from the 48V PoE supply.

或是吃更多電 XDDD

Note that Raspberry Pi 3B+ does consume substantially more power than its predecessor. We strongly encourage you to use a high-quality 2.5A power supply, such as the official Raspberry Pi Universal Power Supply.

所以看到這張圖時就不意外了 XDDD (風扇!)

只是風扇的細節要再找一下,在產品頁上好像沒看到...

Update:風扇那張圖的產品頁看起來在「Raspberry Pi PoE HAT」這頁 (參考下面的 comment)。

GitHub 在 2/28 遭受的攻擊...

GitHub 在 2/28 遭受 DDoS 攻擊,蠻快就把事故報告丟出來了:「February 28th DDoS Incident Report」。

不過跟 GitHub 其他文章不太一樣,這篇算是 PR 稿吧,簡單來說就是花錢買 Akamai Prolexic 的過濾服務解決... Akamai 方的 PR 稿則是在「Memcached-fueled 1.3 Tbps attacks - The Akamai Blog」這邊可以看到。

17:21 UTC 發現問題,然後判斷超過 100Gbps,所以 17:26 決定讓 Akamai Prolexic 接管過濾:

At 17:21 UTC our network monitoring system detected an anomaly in the ratio of ingress to egress traffic and notified the on-call engineer and others in our chat system. This graph shows inbound versus outbound throughput over transit links:

Given the increase in inbound transit bandwidth to over 100Gbps in one of our facilities, the decision was made to move traffic to Akamai, who could help provide additional edge network capacity. At 17:26 UTC the command was initiated via our ChatOps tooling to withdraw BGP announcements over transit providers and announce AS36459 exclusively over our links to Akamai. Routes reconverged in the next few minutes and access control lists mitigated the attack at their border. Monitoring of transit bandwidth levels and load balancer response codes indicated a full recovery at 17:30 UTC. At 17:34 UTC routes to internet exchanges were withdrawn as a follow-up to shift an additional 40Gbps away from our edge.

就這樣而已,完全就是 PR 稿 XDDD

Inter-Region VPC Peering 的範圍大幅增加

AWS 的 Inter-Region VPC Peering 又多了不少區域了:「Inter-Region VPC Peering is Now Available in Nine Additional AWS Regions」。

本來是支援 us-{east,west}-{1,2} 這四個,現在又多了 9 個,來到了 13 個:

Starting today, Inter-Region Virtual Private Cloud (VPC) Peering is available in AWS EU (London), EU (Ireland), EU (Paris), Asia Pacific (Mumbai), Asia Pacific (Sydney), Asia Pacific (Singapore), Asia Pacific (Tokyo), Canada (Central) and South America (São Paulo) Regions in addition to AWS US East (Northern Virgina), US East (Ohio), US West (Northern California), US West (Oregon) Regions.

與現在的 region 表格比較,剩下的是 ap-northeast-2 (南韓首爾) 與 eu-central-1 (德國法蘭克福),其他公開使用的區域都在這波的公告全上了。(也就是美國政府專屬區域與中國區不算在內)

Archives