2016年9月26日 星期一

Setup DNSSec on route53 and cloudflare

Step:

  • Cloudflare -> enable DNSSec
    • Click "DNS Record", and copy public key
  • Route53 -> Manage Keys
    • Key type: 257 - KSK
    • Algorithm: 13
    • Public key: (copy from cloudflare and paste here)

Thats it! If setup fail, Google DNS will shows empty result immediately. 

2016年8月29日 星期一

修改/復原 ulimit 的 script

這個年頭 VPS 機器越來越利害,但是系統的預設設定上卻沒什麼改變,導致 cpu loading 還沒一半,系統就死掉了。以 nginx 來說,除了修改 worker_connections 、worker_processes、worker_rlimit_nofile 之外,還必需要增加系統內建的 ulimit ,預設為 1024 ,我最後是決定把 root 提升到 65536, 其它權限則改為 32768 。由於每次安裝新系統都要執行,把它包成 script 是必要的。這個 script 主要是修改 /etc/security/limits.conf 和 /etc/sysctl.conf,環境是 ubuntu 16.04:

修改 / 安裝 / install:  https://gist.github.com/girvan/a341513654ad6b1cbb7f365b9f68fa7b
回覆 / 還原 / remove: https://gist.github.com/girvan/2f70eb52fd259f6c18a062e015785bc2

我自己是用 ab 來測試 ab -n 10000 -c 500 http://....
-c 從 500 ~ 1000 來反覆測試看看極限值有沒有提升。

這個 ulimit 修改適用於靜態檔案,php 的極限值有提升,但沒這麼多,可以再做其它設定去增加 php 的連線數。php 的連線數我沒有做調整,因為還不到極限值 cpu 就滿載了,調了也沒用,我這邊是採用 nginx 的 request limit 來保護 php ,還蠻有效的。

2016年5月4日 星期三

ttl 60 和 ttl 120 的查詢次數

4/12 以前 ttl 是 60 ,以後是 120,找了pageview 差不多的兩天的資料來看,4/10 和 4/17 ,剛好都是星期日,使用者 pattern 和造訪的頁面也差不多。

由於 pageview 不好意思寫出來,只寫個比例
ipv4 的 A query 是 100 : 83
  ttl 60 全天被查詢 100 次,ttl 120 為 83 次
ipv6 的 AAAA query 是 100 : 88
  ttl 60 全天被查詢 100 次,ttl 120 為 88 次

ttl 短,在主機掛掉時可以快速切換 ip ,但…

  • 使用者網路的 DNS 
  • 可靠度有時卻沒有這麼高,尖峰時間有時會發生 query 不到的情形,由其是中華電信之前對上 cloudflare DNS
  • 會刻意拉長快取時間,我這邊的經驗是 DNS 設 60 秒,ip 切換後,往往是半小時候流量才會停止,Bing Bot 也會刻意拉長時間。
所以同一個 data center 使用 node balancer 放多台 server 才是正解嗎?不,網站的可靠度可能更低哦!以 linode 常常是 data center 輪流被 DDoS 攻擊,但通常不會多個 data center 一起被攻擊。所以目前本站還是以多個 data center 為主,以 route53 的 failover 來做切換。


2016年2月26日 星期五

被瀏覽器攻擊的可能原因

還沒升級 https 之前,偶而會有少數 ip 持續的 request 同一個頁面,可能原因很多,可能是

2016年2月13日 星期六

購買 domain 兩三事

在這分享一下我買 domain 的相關經驗。我買 domain 的經驗不算多,目前還持有的 domain 數為五個,總共買過七個左右。我以前 domain 都在 Godaddy 買。步驟大概就是:
搜尋想要的 domain  → 找 coupon (折價券) → 購買

似乎只要英文稍微好一點,就可以順利完成這三個步驟,但…

2016年1月11日 星期一

主機到底要放哪裡好?各城市間的網路速度列表

由於 EC2 太貴了,我向來的選項都是 Linode 或是 DigitalOcean ,選擇性大概有美西(San Francisco 和 Fremont)、美東紐約、新加坡。端看你的使用者在哪裡,再做考量。


發現這個真的是好物!
https://wondernetwork.com/pings


2016年1月7日 星期四

Alexa:User Agent, Header 以及 Robot

有裝 Alexa Plugin 的使用者,Alexa 會監聽你所有的活動,然後傳送給 Alexa , Alexa 以此來計算網站的排行榜。

有安裝 Alexa 的使用者

Firefox 有安裝的話, User Agent 會變成
Mozilla/5.0 (Windows NT 5.1; rv:42.0) Gecko/20100101 Firefox/42.0 AlexaToolbar/p_O9Nqgf-2.1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 AlexaToolbar/alxf-2.21

Chrome 有裝的話,會多一個 Header
Alexatoolbar-Alx_Ns_Ph: AlexaToolbar/alxg-3.3

問題來了,這個是不合法的 Header ,Key 名稱不可以有 _
所以在 nginx 預設會砍掉不合法的 Header,要加上這個設定
ignore_invalid_headers off;
才能在 PHP  的 $_SERVER 變數中抓到。

Alexa Bot

Alexa 的 未認證使用者,bot 會是
Mozilla/5.0 (compatible; alexa site audit/1.0; +http://www.alexa.com/help/webmasters; )

Alexa 的 已認證使用者,bot 會是
Mozilla/5.0 (compatible; Alexabot/1.0; +http://www.alexa.com/help/certifyscan; certifyscan@alexa.com)


結論

我自己不喜歡 Alexa ,以前老闆規定要安裝,但看它的 permission 很可怕,如果 Alexa 被駭了,你所有網站的帳密也會被跟著監聽。
所以就讓有安裝 Alexa 的使用者多看幾頁吧!(誤)

2015年12月6日 星期日

買了 cloudflare PRO ,原因是…

由於有很多使用者在南美洲,南美洲的網路速度很慢。一直以來很看好 cloudflare 很綿密的 network edge ,在南美洲高達五個點;而 aws cloudfront 只在巴西有兩個點。一直以來使用 aws cloudfront ,缺點是貴! aws cloudfront 南美洲每 GB 要 0.25USD ,美國每 GB 只要 0.09 USD。頻寬費之外,http request 也很貴,後期的使用者都是 304 request ,導致 http request 的費用高於頻寬費很多。最近把 aws cloudfront 換成免費的 cloudflare 之後發現,南美洲使用者的連線速度一直沒起色。

查了之後才知道原因,使用 webpagetest 來去測試…

Cloudflare 免費版:
阿根廷連線到 Miami, US (美國)
巴西連線 Lima, PE (智利)

Cloudflare Pro 付費版:
阿根廷連線到 Buenos Aires, AR (阿根廷)
巴西連線到 São Paulo, BR (巴西)

個人猜測,cloudflare 是節約成本考量,這件事在官網沒寫。
20USD /  Month 買一個 cloudflare PRO ,比起 aws cloudfront 划算很多!

不過 cloudflare 測試上海的瀏覽器,一樣連到美西(Los Angeles, US)

2015年10月18日 星期日

CSS 放在 Cloudfront 、 Cloudflare 和 no CDN 的差異

本篇文章是測試 CSS 的速度,因為 CSS 是唯一會卡頁面的東西。

一直以來看到調教網站效能的文章都教育大家,當網站是 www.example.com 時,JS 和 CSS 放在 asset.example.com ,而有時會把 asset.example.com 掛上 CDN。直到後來開始使用 webpagetest 來測試的時候,發現 DNS 都佔很大時間?不,是最長的時間。所以就來測試一下,看看每個月花在 cloudfront 的錢是否是值得的。