FPs

圖片優化筆記

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

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

格式選擇

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

format-tree

Continue ->

基於IRC 的同站聊天

circ

整理筆記發現一個大學時候的idea,那會玩IRC 的時候試用過circ這個Chrome 插件,冒出來一個想法:

基於CIRC 實現同站聊天,即在irc 上自動創建一個網站域名的頻道,瀏覽者在瀏覽網站時可以右鍵快速打開加入。

不過由於當時不熟悉JavaScipt 以及其他原因就擱置了。現在翻出來,想着把它給實現了。先找到circ 的源代碼(作者開源了),看了下有點頭大,又找了《Chrome 擴展及應用開發》這本書,看了幾章,到第六章的時候才發現circ 是一個chrome 應用,不是一個擴展,所以很多權限會受限制。我想在右鍵添加的contextMenus好像只能用於擴展,另外要獲取當前瀏覽頁面的URL,也只有擴展能拿到?

頓時信心大失,放棄了,寫一篇文章記錄下,希望有一天哪個高手看到能把這個idea 實現了。XD


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 ->


2016年总结

离开北京前,和妹子一起去了次故宫,妹子拍的天安门

tiaanmen

2015年3月初来到北京,2017年1月底离开,在第一家公司,从实习到入职转正,再到离职。
16年,五一有九天假,去了长沙岳麓书院,回了学校,再去了佛山。最重大的变化都发生在下半年,六一时和妹子在一起,八月份一起出游去了泰国。
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 两者的定义也是一样的。


一個改良的Ping

Ping 是一個非常常用的命令,有2種情況會使用它:
一是會從瀏覽器的地址欄或者其他人發給我的網址,複製,然後進行ping,帶着協議以及一堆uri和args,
例如: https://accounts.google.com/AddSession?hl=en...
二從Linux 系統的網絡地址複製過來IP,進行Ping,帶着掩碼位數,
例如:192.168.1.1/32

以上2種情況,如果直接複製內容到終端,然後ping,會提示:

ping: cannot resolve ....: Unknown host

很惱人,寫一個簡單的腳本:

#!/usr/bin/env bash
#author: fangpeishi@gmail.com
#issues:
#  - http(s)://xxx.xx/xxx/xx?xxx
#  - 192.168.1.1/32

new_args=`echo $@ |sed  's/http.*\:\/\///' |sed 's/\/[^ ]*//'`
#echo ${new_args}
ping ${new_args}

把這個腳本命名爲pin, 放到 /bin 之類的目錄下面即可(本來想做成alias,沒成功),最終效果如下:
pin