Home » Computer » Network » Archive by category "Service" (Page 25)

就算關掉 Google 的定位服務也還是會蒐集位置資訊...

就如標題所寫的,Quartz 獨家刊出來的新聞,即使你關掉 Google 的定位服務,Google 還是會蒐集你的位置 (而且跟 Google 發言人確認後也證實):「Google collects Android users’ locations even when location services are disabled」。

而且是全背景作業,在你沒有開定位服務,沒有插 SIM 卡,也沒有跑任何 app,他就會將定位資訊傳出去:

Many people realize that smartphones track their locations. But what if you actively turn off location services, haven’t used any apps, and haven’t even inserted a carrier SIM card?

從今年年初開始這樣搞的,Google 發言人只宣稱這個資料並沒有被用來整合到「network sync system」,並且會立即丟掉 (所以你還是不知道被用到什麼地方):

“In January of this year, we began looking into using Cell ID codes as an additional signal to further improve the speed and performance of message delivery,” the Google spokesperson said in an email. “However, we never incorporated Cell ID into our network sync system, so that data was immediately discarded, and we updated it to no longer request Cell ID.”

這句話的意思其實代表著是丟掉 raw data,改以統計的方式轉移存到其他系統。

另外 John Gruber 在「Google Collects Android Users' Locations Even When Location Services Are Disabled」其實寫的更直接:

If they were “never used or stored”, why did they start collecting them in the first place? This is like a kid caught with their hand in the cookie jar saying they weren’t going to eat any cookies. Sure.

白話一點就是「你當我傻逼啊」。

應該會促進 microG 的發展... (參考「microG 的進展...」)

PChome 24h 連線會慢的原因...

Update:續篇請參考「PChome 24h 連線會慢的原因... (續篇)」。

tl;dr:因為他們的 DNS servers 不會對 IPv6 的 AAAA record 正確的回應 NXDOMAIN,導致 DNS resolver 會不斷嘗試。

好像一行就把原因講完了啊,還是多寫一些細節好了。

起因於我的電腦連 PChome 24h 時常常會卡住,Google Chrome 會寫「Resolving host...」,於是就花了些時間找這個問題。

一開始先用幾個工具測試,發現 host 會卡,但不知道卡什麼:

$ host 24h.pchome.com.tw

tcpdump 出來聽的時候發現 host 會跑 AAAAA 以及 MX 三個種類,而後面兩個都會卡住:

24h.pchome.com.tw is an alias for shopping.gs1.pchome.com.tw.
shopping.gs1.pchome.com.tw has address 210.242.43.53
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached

這樣就有方向了... 我的電腦是 Dual-stack network (同時有 IPv4 address 與 IPv6 address),所以可以預期 Google Chrome 會去查 IPv6 address。而國內很多網站都還沒有把有 IPv6 的情境當標準測試,很容易中獎...

有了方向後,用 dig 測試 IPv6 的 AAAA,發現都是給 SERVFAIL,而且多跑幾次就發現會卡住:

$ dig 24h.pchome.com.tw aaaa @168.95.192.1

然後對 {cheetah,dns,dns2,dns3,wolf}.pchome.com.tw (上層登記的) 與 dns4.pchome.com.tw (實際多的) 測,可以拿到 CNAME record,像是這樣:

$ dig 24h.pchome.com.tw aaaa @dns.pchome.com.tw

; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> 24h.pchome.com.tw aaaa @dns.pchome.com.tw
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26037
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;24h.pchome.com.tw.             IN      AAAA

;; ANSWER SECTION:
24h.pchome.com.tw.      300     IN      CNAME   shopping.gs1.pchome.com.tw.

;; AUTHORITY SECTION:
gs1.pchome.com.tw.      300     IN      NS      ns3.gs1.pchome.com.tw.
gs1.pchome.com.tw.      300     IN      NS      ns1.gs1.pchome.com.tw.
gs1.pchome.com.tw.      300     IN      NS      ns4.gs1.pchome.com.tw.
gs1.pchome.com.tw.      300     IN      NS      ns5.gs1.pchome.com.tw.
gs1.pchome.com.tw.      300     IN      NS      ns2.gs1.pchome.com.tw.

;; ADDITIONAL SECTION:
ns1.gs1.pchome.com.tw.  300     IN      A       210.242.216.91
ns2.gs1.pchome.com.tw.  300     IN      A       210.242.216.92
ns3.gs1.pchome.com.tw.  300     IN      A       210.242.43.93
ns4.gs1.pchome.com.tw.  300     IN      A       203.69.38.91
ns5.gs1.pchome.com.tw.  300     IN      A       210.71.147.91

;; Query time: 12 msec
;; SERVER: 210.59.230.85#53(210.59.230.85)
;; WHEN: Wed Nov 22 11:05:24 CST 2017
;; MSG SIZE  rcvd: 243

但往 ns{1,2,3,4,5}.gs1.pchome.com.tw 問的時候給不出答案,也不給 NXDOMAIN,像是這樣:

$ dig shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw

; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36249
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 6
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;shopping.gs1.pchome.com.tw.    IN      AAAA

;; AUTHORITY SECTION:
gs1.pchome.com.tw.      3600    IN      NS      ns3.gs1.pchome.com.tw.
gs1.pchome.com.tw.      3600    IN      NS      ns4.gs1.pchome.com.tw.
gs1.pchome.com.tw.      3600    IN      NS      ns5.gs1.pchome.com.tw.
gs1.pchome.com.tw.      3600    IN      NS      ns1.gs1.pchome.com.tw.
gs1.pchome.com.tw.      3600    IN      NS      ns2.gs1.pchome.com.tw.

;; ADDITIONAL SECTION:
ns3.gs1.pchome.com.tw.  3600    IN      A       210.242.43.93
ns4.gs1.pchome.com.tw.  3600    IN      A       203.69.38.91
ns5.gs1.pchome.com.tw.  3600    IN      A       210.71.147.91
ns1.gs1.pchome.com.tw.  3600    IN      A       210.242.216.91
ns2.gs1.pchome.com.tw.  3600    IN      A       210.242.216.92

;; Query time: 11 msec
;; SERVER: 210.242.216.91#53(210.242.216.91)
;; WHEN: Wed Nov 22 11:07:17 CST 2017
;; MSG SIZE  rcvd: 310

於是 DNS resolver 就倒在路邊了...

Google 的 .search 網域

Netcraft 的「November 2017 Web Server Survey」這篇看到關於 Google 弄到的 .search 網域:

This month the controversial new .search gTLD being run by Google’s Charleston Road Registry subsidiary was found for the first time, with www.nic.search responding to the survey. Google hopes it will be able to run .search as a dotless domain which will automatically redirect users to their search engine of choice. This proposal has been criticised for going against ICANN’s own rules, which prohibits this functionality due to the potential for conflicts with existing names on internal networks. This feature could also cause confusion for users who have come to expect that typing words into their address bar will perform a search query for that term.

It is currently uncertain whether or not Google will be allowed to run the .search TLD as a dotless domain, however with the launch of the first site on this TLD this month Google is one step closer to the provision of this service.

找了一下資料,ICANNWiki 上的「.search」有些資料,另外也有新聞資訊 (2013 年的):「Google Wants To Operate .Search As A “Dotless” Domain, Plans To Open .Cloud, .Blog And .App To Others」。

不太妙...

ElastiCache 支援 r4.* 了

每年 AWS re:Invent 要到的時候就會有很多新的消息出來,Amazon ElastiCache 的團隊應該也是配合著這一波放出消息:「Amazon ElastiCache Now Supports the R4 Node Family」。

包括了 memcachedRedis 都支援了:

Amazon ElastiCache now supports R4 node types. R4 nodes are optimized for latency sensitive and memory intensive workloads. They come in six sizes, providing 12.3GiB to 407GiB of available in-memory capacity. By setting up a 15-shard cluster for Redis, you can scale up to 6.1TiB of in-memory capacity. For Memcached, you can set up a 20-node cluster to support up to 8.14 TiB in-memory workloads. Equipped with the Intel Broadwell processor, and improved networking, R4 node family offers superior performance over the popular R3 node family.

這兩個應用都是看記憶體吃飯的...

RDS (MySQL/MariaDB) 支援 t2、r4 以及 m4 的新機種

這個大家等好久了,尤其 MySQL 常遇到需要用記憶體換效能的情境:「Amazon RDS for MySQL and MariaDB Supports R4, T2 and M4 Instance Types」。

先前 t2 最大只能開到 t2.large (8GB RAM),對於需要大量記憶體運算的 SQL query,就有機會被 MySQL 使用 filesort 寫到硬碟裡面暫存了。這次支援這些 instance type,開發環境至少有選擇可以開到 t2.2xlarge (32GB RAM) 跟他拼。

r4 應該是正式環境期待已久的 instance type 了。r3 最大是 r3.8xlarge (244GB),跟 r4 最大的 r4.16xlarge (488GB) 剛好差了一倍。

m4 就比較微妙了,順便補上去的感覺... 不過應該還是會有應用會剛好用到。

不過還是期待前陣子出來的 c5,對於寫出很驚人的 SQL query,在 MySQL 內跑大量運算的應用會有幫助,就繼續等吧... :o

AWS 推出新的 Cost Explorer API,不過 API 不是重點啦...

AWS 的「New – Interactive AWS Cost Explorer API」這篇文章在一開頭就提到了 Cost Explorer API 的情況,所以他們要推出新的 API 改進:

We launched the AWS Cost Explorer a couple of years ago in order to allow you to track, allocate, and manage your AWS costs. The response to that launch, and to additions that we have made since then, has been very positive. However our customers are, as Jeff Bezos has said, “beautifully, wonderfully, dissatisfied.”

不過讓我笑出來的是選圖啊... 大概是 Jeff Barr 夠硬的關係,直接選了這張:

我喜歡這張 XD (尤其配合著出現在官方 blog 上的時候)

AWS 推出 AWS Secret Region

AWS 推出給情報單位用的 AWS Secret Region:「Announcing the New AWS Secret Region」。

AWS GovCloud (US) 類似的架構,這個雲的範圍再小一些,給情報單位以及有對應授權的單位用的:

The AWS Secret Region is readily available to the U.S. Intelligence Community (IC) through the IC’s Commercial Cloud Services (C2S) contract with AWS.

The AWS Secret Region also will be available to non-IC U.S. Government customers with appropriate Secret-level network access and their own contract vehicles for use of the AWS Secret Region.

GitHub 上有大量重複的程式碼...

扣除掉 fork 的程式碼後,研究人員在 GitHub 上還是發現有大量重複的程式碼:「DéjàVu: a map of code duplicates on GitHub」。

This paper analyzes a corpus of 4.5 million non-fork projects hosted on GitHub representing over 482 million files written in Java, C++, Python, and JavaScript. We found that this corpus has a mere 85 million unique files.

Java/C++/Python/JavaScript 寫的 4.5M 個專案有 482M 個檔案,但只有 85M 個檔案是不一樣的 XD

想一想其實也是... 現在愈來愈多工具產生程式碼了 XD (i.e. Scaffold)

AWS 提供 Hybrid Cloud 環境下 DNS 管理的說明

不知道為什麼出現在 browser tab 上,不知道是哪邊看到的... AWS 放出了一份文件,在講 hybrid cloud 環境下當你同時有一般 IDC 機房,而且使用內部 domain 在管理時,網路與 AWS 打通後要怎麼解決 DNS resolver 的問題:「Hybrid Cloud DNS Solutions for Amazon VPC」。

有些東西在官方的說明文件內都寫過,但是是 AWS 的特殊設計,這邊就會重複說明 XDDD

像是這份文件裡提到 Amazon DNS Server 一定會在 VPC 的 base 位置加二 (舉例來說,10.0.0.0/16 的 VPC,Amazon DNS Server 會在 10.0.0.2):

Amazon DNS Server
The Amazon DNS Server in a VPC provides full public DNS resolution, with additional resolution for internal records for the VPC and customer-defined Route 53 private DNS records.4 The AmazonProvidedDNS maps to a DNS server running on a reserved IP address at the base of the VPC network range, plus two. For example, the DNS Server on a 10.0.0.0/16 network is located at 10.0.0.2. For VPCs with multiple CIDR blocks, the DNS server IP address is located in the primary CIDR block.

在官方文件裡,則是在「DHCP Options Sets」這邊提到一樣的事情:

When you create a VPC, we automatically create a set of DHCP options and associate them with the VPC. This set includes two options: domain-name-servers=AmazonProvidedDNS, and domain-name=domain-name-for-your-region. AmazonProvidedDNS is an Amazon DNS server, and this option enables DNS for instances that need to communicate over the VPC's Internet gateway. The string AmazonProvidedDNS maps to a DNS server running on a reserved IP address at the base of the VPC IPv4 network range, plus two. For example, the DNS Server on a 10.0.0.0/16 network is located at 10.0.0.2. For VPCs with multiple IPv4 CIDR blocks, the DNS server IP address is located in the primary CIDR block.

另外也還是有些東西在官方的說明文件內沒看過,像是講到 Elastic Network Interface (ENI) 對 Amazon DNS Server 是有封包數量限制的;這點我沒在官方文件上找到,明顯在量太大的時候會中獎,然後開 Support Ticket 才會發現的啊 XDDD:

Each network interface in an Amazon VPC has a hard limit of 1024 packets that it can send to the Amazon Provided DNS server every second.

Anyway... 這份文件裡面提供三種解法:

  • Secondary DNS in a VPC,直接用程式抄一份到 Amazon Route 53 上,這樣 Amazon DNS Server 就可以直接看到了,這也是 AWS 在一般情況下比較推薦的作法。
  • Highly Distributed Forwarders,每台 instance 都跑 Unbound,然後針對不同的 domain 導開,這樣可以有效避開單一 ENI 對 Amazon DNS Server 的封包數量限制,但缺點是這樣的設計通常會需要像是 Puppet 或是 Chef 之類的軟體管理工具才會比較好設定。
  • Zonal Forwarders Using Supersede,就是在上面架設一組 Unbound 伺服器集中管理,透過 DHCP 設定讓 instance 用。但就要注意量不能太大,不然 ENI 對 Amazon DNS Server 的限制可能會爆掉 XD

都可以考慮看看...

Archives