Tag: host

Google Fonts 的加速方式

這邊講的是透過 css (以及 js) 使用的 Google Fonts，作者想要改善這塊，加速網頁的速度：「Should you self-host Google Fonts?」。

作者第一個提到的技巧是個懶人技巧，只要加上 preconnect 預先把 HTTPS 連線建好，就可以提昇不少速度。因為這可以降低先取得 css 後才建立連線的速度差異：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

作者有提到 Google 在 css 檔案的
header 裡面本來就有加上 preconnect，但從前後比較可以看出，整個網頁的結束時間差了一秒 (這是作者在 Google Chrome 的 3G Slow 設定下模擬的)：

另外一個技巧是增加 swap，讓 Google Fonts 還沒有讀進來之前先用系統有的字型呈現。這樣不會出現整頁只有圖，然後突然字都冒出來的情況，也就是把一般在用的：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">

加上 &display=swap：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

最後一招就是把字型放在自己家，差異就更大了：

另外一個好處是改善 privacy，不過好像沒特別提到...

Amazon S3 淘汰 Path-style 存取方式的新計畫

先前在「Amazon S3 要拿掉 Path-style 存取方式」提到 Amazon S3 淘汰 Path-style 存取方式的計畫，經過幾天後有改變了。

Jeff Barr 發表了一篇「Amazon S3 Path Deprecation Plan – The Rest of the Story」，裡面提到本來的計畫是 Path-style model 只支援到 2020/09/30，被大幅修改為只有在 2020/09/30 後建立的 bucket 才會禁止使用 Path-style：

In response to feedback on the original deprecation plan that we announced last week, we are making an important change. Here’s the executive summary:

Original Plan – Support for the path-style model ends on September 30, 2020.

Revised Plan – Support for the path-style model continues for buckets created on or before September 30, 2020. Buckets created after that date must be referenced using the virtual-hosted model.

這樣大幅降低本來會預期的衝擊，但 S3 團隊希望償還的技術債又得繼續下去了... 也許再過個幾年後才會再被提出來？

Amazon S3 要拿掉 Path-style 存取方式

在 Hacker News 上翻的時候翻到的公告：「Announcement: Amazon S3 will no longer support path-style API requests starting September 30th, 2020」。

現有的兩種方法，一種是把 bucket name 放在 path (V1)，另外一種是把 bucket name 放在 hostname (V2)：

Amazon S3 currently supports two request URI styles in all regions: path-style (also known as V1) that includes bucket name in the path of the URI (example: //s3.amazonaws.com/<bucketname>/key), and virtual-hosted style (also known as V2) which uses the bucket name as part of the domain name (example: //<bucketname>.s3.amazonaws.com/key).

這次要淘汰的是 V1 的方式，預定在 2020 年十月停止服務 (服務到九月底)：

Customers should update their applications to use the virtual-hosted style request format when making S3 API requests before September 30th, 2020 to avoid any service disruptions. Customers using the AWS SDK can upgrade to the most recent version of the SDK to ensure their applications are using the virtual-hosted style request format.

Virtual-hosted style requests are supported for all S3 endpoints in all AWS regions. S3 will stop accepting requests made using the path-style request format in all regions starting September 30th, 2020. Any requests using the path-style request format made after this time will fail.

VirtualBox 5.2 的 0day 爆破...

在 Hacker News Daily 上看到「VirtualBox E1000 Guest-to-Host Escape」這篇，講 VirtualBox 5.2 的機器上 E1000 + NAT 模式的爆破... 另外在 Hacker News 上的討論也提到了很多這樣做的背景：「VirtualBox E1000 Guest-to-Host Escape | Hacker News」。

Oracle 對社群的態度 (無論是 open source community 或是 security community) 都一直是社群很不爽的事情。

這次爆破的發現人之前找到一個 VirtualBox 的 security bug (參考「SSD Advisory – VirtualBox VRDP Guest-to-Host Escape」)，回報後先是回應他們在處理中，然後被發現 VirtualBox 在 5.2.18 修掉了，但是完全沒有提到安全性問題的事情。所以這次作者也懶得囉唆了，找到就 full disclosure 出來。

作者給的 workaround 有兩個，優先建議暫時先用 PCnet 系列的界面，如果不行的話，至少不要用 NAT。

作者發表後沒多久馬上就有 5.2.22 推出，不過看 changelog 應該是沒有修正這個問題？(或是修掉又沒提...)

掃網域下主機名稱的方式...

原文是講滲透測試的前置作業，需要將某個特定 domain 下的主機名稱掃出來：「A penetration tester’s guide to sub-domain enumeration」。

最直接的還是 DNS zone transfer (AXFR)，如果管理者沒設好 DNS server 的話，這會是最快的方式。當沒有這個方法時就要用各種其他方式來掃了。

看了一下有幾種方式：

應該有人可以提到所有的東西再寫成程式 XD

用 Vagrant 的技巧

在「Ten Things I Wish I’d Known Before Using Vagrant」這邊作者整理了使用 Vagrant 的十個技巧，有些以前就知道，有些是每次遇到都要查一次，有些則是新發現的工具...

其中第四點提到的工具「vagrant-landrush/landrush」之前沒看過：

A Vagrant plugin that provides a simple DNS server for Vagrant guests

Landrush is a simple cross-platform DNS for Vagrant VMs that is visible on both, the guest and the host.

It spins up a small DNS server and redirects DNS traffic from your VMs to use it, automatically registering/unregistering IP addresses of guests as they come up and go down.

也可以從範例知道實際用途：

Vagrant.configure("2") do |config|
  config.vm.box = "hashicorp/precise64"

  config.landrush.enabled = true

  config.vm.hostname = "myhost.vagrant.test"

  config.landrush.host 'static1.example.com', '1.2.3.4'
  config.landrush.host 'static2.example.com', '2.3.4.5'
end

以前有遇到這樣的需求時都還傻傻的去寫 /etc/hosts... (也是會動啦，而且每一台都寫一樣的東西是還好，但有種很 workaround 的感覺 XD)

之後有遇到時用看看...

ALB (Application Load Balancer) 支援對 Host 的分流了

大概是有時候 cluster 太小，ELB 或是 ALB 的費用反而比 cluster 還貴，再加上 ALB 提供起來算方便，所以就推出這樣的功能了：「New – Host-Based Routing Support for AWS Application Load Balancers」。

現在可以針對 Host 欄位決定導到不同的 cluster 上了：

然後讓 ALB 可以設的 rule 數量增加：

As part of today’s launch we are raising the maximum number of rules per Application Load Balancer from 10 to 75, and also introducing a new rule editor.

這個功能有種微妙的感覺 XDDD

Amazon EC2 的 Dedicated Hosts 正式推出

Amazon EC2 在十月預告了 Dedicated Hosts (參考「Amazon EC2 預定要推出的 Dedicated Hosts」)，在今天正式推出來讓大家用：「Now Available – EC2 Dedicated Hosts」。

價錢在「Amazon EC2 Dedicated Host Pricing」這邊，租用就是整台一起租用，所以價錢都是以 Instance Family 在計算，在一台 Dedicated Host 上面可以跑的虛擬機數量與 Instance Type 有關，舉例來說：c4 只能跑一個 8xlarge，也可以跑兩個 4xlarge。

一台 Dedicated Host 當然可以跑很多 Instance，不過只能跑一樣的大小的 Instance Type：

I choose the instance type (Dedicated hosts for M3, M4, C3, C4, G2, R3, D2, and I2 instances are available), the Availability Zone, and the quantity (each Dedicated Host can accommodate one or more instances of a particular type, all of which must be the same size).

另外 Dedicated Hosts 一定要放到 VPC 內 (理論上新帳號都有強迫這樣了)，不過可以跨 VPC 就是了：

Instances launched on a Dedicated Host must always reside within a VPC. A single Dedicated Host can accommodate instances that run in more than one VPC.

目前能開的數量有限制，有需要更多的人可以開 support ticket 去要：

You can allocate up to 2 Dedicated Hosts per instance family (M4, C4, and so forth) per region; if you need more, just ask.

為了解決 HiNet 到 CloudFlare 機房品質不好而做的掙扎...

前幾天在「TVBS 的 CloudFlare 客製化...」這邊提到這件事情，當天就先隨手測了一些東西。

首先是 CloudFlare 的服務 IP 是互通的，也就是說，我就算拿其他人的 CNAME mapping 來用，只要有送出對應的 Host: 或是 SNI (for HTTPS) 就會通，而 TVBS 當時的 IP address (以及網段) 對於台灣 HiNet 使用者剛好會導到美國機房，還算可以用。

另外 CloudFlare 有提供列表 (文字格式，一行一個網段)，分別是 IPv4 的 https://www.cloudflare.com/ips-v4 以及 IPv6 的 https://www.cloudflare.com/ips-v6。

所以就有幾種組合了，一種是寫 Google Chrome 的 extension 直接改 IP address，不過看了看 JavaScript APIs - Google Chrome 想不出來怎麼寫。

另外一個是先用 iptables 把這些網段的流量導去美國的 CloudFlare 機房。結果這時候發現 HiNet 到 TVBS 已經改回到香港機房了 orz

實際抓了一下發現 188.114.97.100 在巴西機房 (GRU 是 IATA 代碼)，就變成只是測試看看這有沒有用了：

$ curl -x http://188.114.97.100:80/ http://s.plurk.com/cdn-cgi/trace
fl=42f16
h=s.plurk.com
ip=114.32.152.63
ts=1441004146.723
visit_scheme=http
uag=curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
colo=GRU
spdy=off

由於是自己機器出去的封包，不能用 PREROUTING 做，要用 OUTPUT 做：

iptables -t nat -A OUTPUT -d 190.93.240.0/20 -j DNAT --to-destination 188.114.97.100

然後再直接連到 s.plurk.com 就可以看到：

$ curl http://s.plurk.com/cdn-cgi/trace
fl=42f16
h=s.plurk.com
ip=114.32.152.63
ts=1441004011.195
visit_scheme=http
uag=curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
colo=GRU
spdy=off

不過巴西也太遠了點，而且不知道哪天這段 IP 又會被 anycast 進去... orz