幹壞事是進步最大的原動力
要講 inlets 前要先講 ngrok 這個服務。這個服務可以在開發機上主動建立連線到外部伺服器，接著透過這個連線與本機的 web server 溝通，讓外部的客戶可以很方便的進行測試 (通常會開個 Zoom 之類的工具邊討論邊修改)，算是 reverse proxy as a service 的服務。
類似機制的服務還有 Cloudflare 的 Argo Tunnel，不過產品定位不太一樣。
而 inlets 就是 open source 版本的 ngrok，你只要在外部租一台主機就可以用了。左邊是自己的開發機 (像是 Macbook)，右邊則是外部的主機 (租用 VPS)：
不過這個跟開發模式也有關...
Algolia 是一個搜尋引擎服務，他可以幫你 index 資料後，你直接 query 他取得結果。
在這篇文章裡 Algolia 決定從 Heroku 搬到 GKE：「The Challenging Migration from Heroku to Google Kubernetes Engine」。
在文章只單純就產品與技術面上的需求在討論，像是一開始討論 IP 白名單的問題：
A good example of this complexity is with IP Whitelisting. One of our customers wanted us to crawl from a fixed IP address so that they could whitelist that IP for high-rate crawling without being throttled by their load balancer. Only two engineers were developing the crawler, so we asked other colleagues to set up an HTTP proxy with a fixed IP address. Yet, as the number of customers grew, many more started asking for the same thing, and our infrastructure team told us it was time for us to take care of it ourselves.
不過我更想知道搬過去後的各類成本差異... 省了多少平台費用，以及多少維護人力的差異，不過看起來沒提到 XD
DuckDuckGo 宣佈採用 Apple Maps 當作搜尋頁提供地圖資訊的資料來源：「DuckDuckGo Taps Apple Maps to Power Private Search Results」。
DuckDuckGo 官方的說法看起來應該是 proxy 之類的方式實做，從瀏覽器的連線上看起來是透過 proxy*.duckduckgo.com 傳輸：
We do not send any personally identifiable information such as IP address to Apple or other third parties.
畢竟地圖是砸錢做出來的東西，Apple Maps 的資料應該沒有 Google Maps 豐富，但就搜尋頁上翻起來應該算是夠用？(尤其對歐美區域)
另外「DuckDuckGo switches to Apple Maps for search results」這邊則是給了反對意見，提到 Apple Maps 的品質一直都不怎樣...
AWS 對於 Hybrid Cloud (混合雲，通常是講與傳統機房的混搭應用，也就是雲端跟地端的混搭) 推出兩個功能，一個是讓 AWS 的 DNS Resolver 對於某些 domain 可以回機房端查詢 (雲端查詢地端 domain)。另外一種是反過來，讓機房端的 DNS Resolver 可以查 AWS 這邊的資料 (地端查詢雲端 domain)：「New – Amazon Route 53 Resolver for Hybrid Clouds」。
兩者都可以自己幹，但就得花功夫自己架設，而且有很多細節得處理：
而地端到雲端通常會簡單一些，因為地端通常都已經有內部的 DNS Resolver 可以用，通常只需要在雲上面有 proxy 的角色就可以解決。
不過現在這些 AWS 都直接提供了：
常見的區域都可以用：
Hybrid Cloud is available today in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Sydney), Asia Pacific (Tokyo) and Asia Pacific (Singapore), with other commercial regions to follow.
費用的部分不算便宜 (跟自己弄三台 t3.nano 比起來)，但畢竟不需要自己管理，而且對於已經有機房的單位應該只是零頭而已：
Route 53 Resolver remains free for DNS queries served within your VPC. Resolver Endpoints use Elastic Network Interfaces (ENIs) costing $0.125 per hour. DNS queries that are resolved by a Conditional Forwarding Rule or a Resolver Endpoint cost $0.40 per million queries up to the first billion and $0.20 per million after that.
HiNet 宣佈今年年底將要關閉 Proxy 服務了，也就是 proxy.hinet.net:80 這組：「HiNet Proxy 終止服務公告」。
現在愈來愈多網站都走 HTTPS 的情況下，Proxy 服務能帶來的好處愈來愈少了... 大概只剩下出國的優先權比較高 (因為變成機房 IP 連出國)。
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 這樣設計... 不知道後續會有什麼樣的變化。
Percona 的「Leveraging ProxySQL with AWS Aurora to Improve Performance, Or How ProxySQL Out-performs Native Aurora Cluster Endpoints」這篇有夠長的，其實就是發現 AWS 的 Amazon Aurora 只使用 Cluster Endpoint 無法壓榨出所有效能，只有當你讀寫分離拆開 Cluster endpoint 與 Reader endpoint 時才能提昇效能。主要是在推銷 ProxySQL 啦，其他的軟體應該也能達到類似的效果...
然後這張怪怪的，應該是 copy & paste 上去的關係？
因為事後再疊 ProxySQL 進去不會太困難，一般還是建議先直接用服務本身提供的 endpoint (少了一層要維護的設備)，等到有遇到效能問題時再來看是卡在哪邊，如果是 R/W split 可以解決的，才用 ProxySQL 或是其他軟體來解...
看到「imgproxy: Resize your images instantly and securely」這篇文章，介紹「DarthSim/imgproxy」這個專案，想起很久以前的同事在 PIXNET 弄的 *.pimg.tw 系列服務...
imgproxy 可以 resizing，也可以 croping，然後也支援 signature token 機制，感覺是每個大一點的站台都會自己刻一次的服務 XD
整個專案以 Golang 為主，效能應該是不錯... 不過一般前面還是會放 cache 機制 (像是 CDN 之類的服務)，而不會把 loading 直接打進來，避免同樣的圖片一直重複計算。
看到 AWS 的「Automating SQL Caching for Amazon ElastiCache and Amazon RDS」這篇裡面介紹了 Heimdall Data – SQL caching and performance optimization 這個產品。
從官網的介紹也可以看出來是另外疊一層 proxy，但自動幫你處理 cache invalidation 的問題：
But what makes Heimdall Data unique in industry is its auto-cache AND auto-invalidation capability. Our machine learning algorithms determine what queries to cache while invalidating to ensure maximum performance and data integrity.
看起來支援了四個蠻常見的 RDBMS：
Heimdall Data supports most all relational database (e.g. MySQL, Postgres, Amazon RDS, Oracle, SQL Server, MariaDB).
看起來是一個花錢直接買效能的方案... 不過 cache invalidation 的部分不知道要怎麼跨機器做，在 FAQ 沒看到 cluster 情況下會怎麼解決。
在「How (Not) to Control Your CDN」這邊看到了「Web Cache Deception Attack」這個攻擊方式。
攻擊的手法是利用網站會把 /user/personal-info/foo.css 與 /user/personal-info 視為一樣的內容時，配合 CDN 或是 reverse proxy server 會把 .css 設定無差異 cache 時，就可以在 cache server (cache edge) 取得使用者的敏感資料。
這主要是 url routing 的條件放太寬造成的。
另外 Mark Nottingham 還建議 cache 應該在 origin server 上控制，而非在 CDN 上設定。也就是說，在 origin server 上送出 Cache-Control，讓 CDN 或是 reverse proxy server 使用這個值來判斷 cache。