FPs

Articles in the IT category

Pelican插件:CDN Support

之前用WordPress 做博客的時候,用過一個WP Super Cache 的插件,
這個插件可以把WordPress 的頁面靜態化,然後用內存或者磁盤等做緩存,提升性能。

其中有個選項是開啓CDN 支持,開啓這種功能之後,插件會把所有指向本站的靜態資源(CSS,JS,各類圖片)的URL 替換爲CDN 的URL,當然填入的CDN 域名需要配置好回源。

wp-super-cache 圖片來源:keycdn.com

最近幫妹子做了一個網站(s.fangpeishi.com),想着各種優化,又想起這事。這個網站是用Pelican 生成的,所有就有了這個插件。

Continue ->

ip.fangpeishi.com

server {
    listen 80;
    server_name ip.fangpeishi.com;
    location / {
        default_type text/plain;
        return 200 "$remote_addr\n";
    }
}

获取外网IP,给自己在某些脚本里面用,没有查询地址、运营商的需求。


圖片優化筆記

這裏說的圖片優化,目標是想儘可能降低圖片大小,但又要保證質量不錯,非常矛盾。不過降低圖片大小,可以剩一大筆流量錢,降低負載,還能提升用戶體驗,值得花點功夫。

前端方面有一些關於圖片加載速度的優化,例如CSS 畫圖,CSS 合併素材,甚至用CSS 把圖片Base64 編碼(不推薦),和這份筆記關係不大。

格式選擇

不同的需求選擇不同的格式, JPEG 能夠滿足的需求沒必要選擇PNG。

format-tree

Continue ->

htop 解釋

"Explanation of everything you can see in htop/top on Linux"

“解釋你在Linux 上htop/top 中看到的所有內容”

很長一段時間我都不清楚htop 中所有內容的意思。
我曾經以爲我的雙核機器上1.0的平均負載意味着CPU 利用率是50%。這並不完全正確。而且,爲什麼是1.0呢?

我決定查清楚,並記錄成這份文檔。

大家也都說,學習事物的最好方式是通過教別人。

Ubuntu Server 16.04 x64 上的htop

這是一張我要解釋的htop 截圖。
canyoukillit-before

Continue ->

《極客與團隊》讀書筆記

team_geek_cover

《极客与团队》這本書是在看《技术管理猪鸡-1 开篇》注意到的:

Google 的芝加哥 office 有两个技术领导:Brian Fitzpatrick 和 Ben Collins-Sussman。他们合写了一本书,叫做 Team Geek。

這本書的副標題是“软件工程师的团队生存秘笈”,畢業一年認識到和同事合作、如何更高效的推進工作也十分重要,正如作者在書一開始提到了書的宗旨:

本書旨在幫助程序員改進理解他人、與人溝通,以及與人合作的能力,進而使其在編寫軟件的過程中變的更有效率。

這本書的核心是“HRT”,即“謙虛”,“尊重”,“信任”,不算是什麼祕訣,但卻非常難做到,一遍讀,一遍想着工作中的一幕幕,感慨良多,希望能在閱讀完這本書之後,在下一份工作中有更好的表現吧。
把書中的內容要點,以及一些隨想簡單的記錄如下,方便日後查閱。
Continue ->


Salt Minion ID 變爲FQDN 記錄的問題

最近在一臺外網機器上起了salt minion ,但是同事發現/etc/salt/minion_id 不對,之前自動生成的minion_id 都是機器的/etc/hostname,這回變成了一個奇怪的域名:cncXXXX.XXX.ln.cn,並且這個域名和使用 hostname --all-fqdns 返回的結果相同。先查下minion_id 是怎麼生成的。

Github:saltstack/salt/doc/topics/tutorials/walkthrough.rst:

When the minion is started, it will generate an id value, unless it has been generated on a previous run and cached (in /etc/salt/minion_id by default). This is the name by which the minion will attempt to authenticate to the master. The following steps are attempted, in order to try to find a value that is not localhost:

  1. The Python function socket.getfqdn() is run
  2. /etc/hostname is checked (non-Windows only)
  3. /etc/hosts (%WINDIR%\system32\drivers\etc\hosts on Windows hosts) is checked for hostnames that map to anything within 127.0.0.0/8.

If none of the above are able to produce an id which is not localhost, then a sorted list of IP addresses on the minion (excluding any within 127.0.0.0/8) is inspected. The first publicly-routable IP address is used, if there is one. Otherwise, the first privately-routable IP address is used.

If all else fails, then localhost is used as a fallback.

應該是第一點,通過socket.getfqdn 拿到的結果,也驗證了和上文提到的hostname --all-fqdns 拿到的結果一樣。

FQDN是什麼?

Continue ->

HAProxy 最佳實踐筆記

haproxy_best_practice

這篇筆記內容主要來自Haproxy官方團隊分享的一個幻燈片:《Haproxy best practice》,介紹了一些常規的配置方式和優化手段。

不要盲目使用文中出現的所有技巧。

Haproxy 是如何工作的

關於Haproxy 團隊介紹,以及一些特性介紹直接看前面幾張幻燈片即可。 Haproxy 的主要用作代理請求,工作流程如下:
haproxy_proxy_mode

client 和Haproxy 建立連接,Haproxy 再和對應的後端server 建立連接,然後作爲中間人,轉發請求。 在Haproxy 配置中,對一個代理,會劃分爲2層,frontend(前端) 和backend(後端),這和上文說的Haproxy 的工作流程也是對應的。
Continue ->


高流量負載下Nginx 調優

  • 原文地址: Martin Fjordvald
  • 已獲得原文作者翻譯許可,本文遵循原文許可協議
  • 原文發表時間:April 27,2011

我曾經討論過一些Nginx 最常見的問題,毫無疑問,其中一個問題就是關於如何優化nginx 獲得高性能。不必驚訝,因爲大多數nginx 新用戶都是從Apache 遷移過來,所以他們習慣於調整配置和使用巫術來盡可能讓服務器達到最佳性能。

恩,我得告訴你一些壞消息,你並不能真的顯著優化nginx。沒有什麼配置能讓你的負載降低一半,或讓PHP 運行速度快2 倍。謝天謝地,好消息是nginx 不需要任何調優,因爲直接使用它時就已經被優化過了。最大的優化發生在當你決定運行通過ape-get install ,yum install 或 make install 安裝的nginx。(請注意這些倉庫內容常常過期。Wiki 的安裝頁面上通常有最新的倉庫。)

也就是說,有很多選項會影響nginx 的行爲,但是這些選項的默認值並不全都爲高流量的情況優化過。另外我們也需要考慮nginx 運行的平臺,優化我們的操作系統,因爲它們某些地方也會有瓶頸。

總之,我們沒法優化單個連接的加載時間,但是可以確保nginx 處理高流量的情況時有優化過的理想的環境。當然,我所說的高流量是指每秒幾百個請求,絕大多數人不需要爲這種情況費心思,不過如果你有興趣或者準備處理這種情況,請繼續往下讀吧。

Continue ->

關閉HPKP 和HSTS的方法

大家對於HSTS 一般都比較熟悉了,對HPKP 可能比較陌生,簡單來說由於CA 的工作模式,導致別人有可能通過其他CA 簽發你網站的證書,這個時候你就需要有一條頭信息聲明你網站的證書的指紋是什麼。
關於HSTS 和HPKP 的介紹可以查看Jerry Qu 的這2篇文章:

HSTS 和HPKP 都是通過頭信息傳遞給瀏覽器,瀏覽器都會根據max-age 緩存起來,所以在添加了HSTS 和HPKP 了之後,想要回滾,就沒有在服務端回滾程序那麼方便了。

有以下幾種情況會遇到要關閉/移除:

HSTS: 運維同學在剛剛做HTTPS 的時候,開啓了HSTS,甚至加了includeSubDomains,某些老客戶端訪問HTTP的接口的時候跳到HTTS,由於SNI、加密套件兼容性等問題出現故障;

HPKP: 無論是用根證書、中間證書還是站點證書簽發了指紋,虽然HPKP有备份方案,即发送多个pin-sha,但是还是需要准备证书出现故障,要关闭HPKP。另外要记得添加report-uri,这样出错时,服务端能主动的发现上报的信息。

個人覺得HPKP 和HSTS 在設計上實在太像了,如下例子:

HSTS:

Strict-Transport-Security: max-age=31536000; includeSubDomains

HPKP:

Public-Key-Pins:
      pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=";
      pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
      pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";
      max-age=10000; includeSubDomains

所以在關閉,或者說移除HSTS或HPKP的方式上也是一樣的。

即max-age 字段指定为0

看下RFC:

HTST(RFC6797):

The max-age value is essentially a "time to live" value relative
to the reception time of the STS header field.

If the max-age header field value token has a value of zero, the
UA MUST remove its cached HSTS Policy information (including the
includeSubDomains directive, if asserted) if the HSTS Host is
known, or the UA MUST NOT note this HSTS Host if it is not yet
known.

HPKP(RFC7469):

The max-age value is essentially a "time to live" value relative to
the time of the most recent observation of the PKP header field.  If
the max-age header field value token has a value of 0, the UA MUST
remove its cached Pinning Policy information (including the
includeSubDomains directive, if asserted) if the Pinned Host is
Known, or, MUST NOT note this Pinned Host if it is not yet Known.

果然很像。。。居然照抄。
另外includeSubdomains 两者的定义也是一样的。