前端工程師不可不知的Nginx知識
「觀感度：?????」
「口味：虎皮雞蛋」
「烹飪時間：10min」
本文已收錄在前端食堂同名倉庫
Githubgithub.com/Geekhyt，歡迎光臨食堂，如果覺得酒菜還算可口，賞個 Star 對食堂老板來說是莫大的鼓勵。
歷史背景
互聯(lián)網(wǎng)的全球化導致了互聯(lián)網(wǎng)的數(shù)據(jù)量快速增長，加上在本世紀初摩爾定律在單核 CPU 上的失效，CPU 朝著多核方向發(fā)展，而 Apache 顯然并沒有做好多核架構(gòu)的準備，它的一個進程同一時間只能處理一個連接，處理完一個請求后才能處理下一個，這無疑不能應對如今互聯(lián)網(wǎng)上海量的用戶。況且進程間切換的成本是非常高的。在這種背景下，Nginx 應運而生，可以輕松處理數(shù)百萬、上千萬的連接。
Nginx 優(yōu)勢
高并發(fā)高性能 可擴展性好 高可靠性 熱部署 開源許可證
Nginx 主要應用場景
靜態(tài)資源服務，通過本地文件系統(tǒng)提供服務 反向代理服務、負載均衡 API服務、權(quán)限控制，減少應用服務器壓力
Nginx 配置文件和目錄
通過 rpm -ql nginx 可以查看 Nginx 安裝的配置文件和目錄。
如圖是我在某某云上安裝的最新穩(wěn)定版本的Nginx的配置文件及目錄。
/etc/nginx/nginx.conf 核心配置文件 /etc/nginx/conf.d/default.conf 默認http服務器配置文件 /etc/nginx/fastcgi_params fastcgi配置 /etc/nginx/scgi_params scgi配置 /etc/nginx/uwsgi_params uwsgi配置 /etc/nginx/koi-utf /etc/nginx/koi-win /etc/nginx/win-utf 這三個文件是編碼映射文件，因為作者是俄國人 /etc/nginx/mime.types 設置HTTP協(xié)議的Content-Type與擴展名對應關(guān)系的文件 /usr/lib/systemd/system/nginx-debug.service /usr/lib/systemd/system/nginx.service /etc/sysconfig/nginx /etc/sysconfig/nginx-debug 這四個文件是用來配置守護進程管理的 /etc/nginx/modules 基本共享庫和內(nèi)核模塊 /usr/share/doc/nginx-1.18.0 幫助文檔 /usr/share/doc/nginx-1.18.0/COPYRIGHT 版權(quán)聲明 /usr/share/man/man8/nginx.8.gz 手冊 /var/cache/nginx Nginx的緩存目錄 /var/log/nginx Nginx的日志目錄 /usr/sbin/nginx 可執(zhí)行命令 /usr/sbin/nginx-debug 調(diào)試執(zhí)行可執(zhí)行命令
關(guān)于 Nginx 的常用命令以及配置文件語法很容易就可以搜到，本文不作贅述，下面從 Nginx 的功能以及實際場景出發(fā)看一看各個場景下 Nginx 可以提供給我們哪些配置項。在此之前，我們先來明確兩個概念：
正向代理 Forward proxy
一句話解釋正向代理，正向代理的對象是客戶端，服務器端看不到真正的客戶端。
resolver?8.8.8.8?#?谷歌的域名解析地址
server?{
?location?/?{
??????#?當客戶端請求我的時候，我會把請求轉(zhuǎn)發(fā)給它
??????#?$http_host?要訪問的主機名?$request_uri?請求路徑
??????proxy_pass?http://$http_host$request_uri;
?}
}
反向代理 Reverse proxy
一句話解釋反向代理，反向代理的對象是服務端，客戶端看不到真正的服務端。
跨域
跨域是前端工程師都會面臨的場景，跨域的解決方案有很多。不過要知道在生產(chǎn)中，要么使用 CORS 、要么使用 Nginx 反向代理來解決跨域。在 Nginx 的配置文件中進行如下配置即可：
server?{
????listen???80;
????server_name???localhost;?#?用戶訪問?localhost，反向代理到?http://webcanteen.com
????location?/?{
????????proxy_pass?http://webcanteen.com
????}
}
Gzip
Gzip 是互聯(lián)網(wǎng)上非常普遍的一種數(shù)據(jù)壓縮格式，對于純文本來說可以壓縮到原大小的 40%，可以節(jié)省大量的帶寬。不過需要注意的是，啟用 Gzip 所需的 HTTP 最低版本是 1.1。
location?~?.*\.?(jpg|png|gif)$?{
????gzip?off;?#關(guān)閉壓縮
????root?/data/www/images;
}
location?~?.*\.?(html|js|css)$?{
????gzip?on;?#啟用壓縮
????gzip_min_length?1k;?#?超過1K的文件才壓縮
????gzip_http_version?1.1;?#?啟用gzip壓縮所需的HTTP最低版本
????gzip_comp_level?9;?#?壓縮級別，壓縮比率越高，文件被壓縮的體積越小
????gzip_types?text/css?application/javascript;?#?進行壓縮的文件類型
????root?/data/www/html;
}
請求限制
對于大流量惡意的訪問，會造成帶寬的浪費，給服務器增加壓力。往往對于同一 IP 的連接數(shù)以及并發(fā)數(shù)進行限制。
關(guān)于請求限制主要有兩種類型：
limit_conn_module 連接頻率限制 limit_req_module 請求頻率限制
#?$binary_remote_addr?遠程IP地址?zone?區(qū)域名稱?10m內(nèi)存區(qū)域大小
limit_conn_zone?$binary_remote_addr?zone=coon_zone:10m;
server?{
????#?conn_zone?設置對應的共享內(nèi)存區(qū)域?1是限制的數(shù)量
?limit_conn?conn_zone?1;
}
#?$binary_remote_addr?遠程IP地址?zone?區(qū)域名稱?10m內(nèi)存區(qū)域大小?rate?為請求頻率?1s?一次
limit_req_zone?$binary_remote_addr?zone=req_zone:10m?rate=1r/s;
server?{
????location?/?{
????????#?設置對應的共享內(nèi)存區(qū)域?burst最大請求數(shù)閾值?nodelay不希望超過的請求被延遲
????????limit_req?zone=req_zone?burst=5?nodelay;
????}
}
訪問控制
關(guān)于訪問控制主要有兩種類型：
-http_access_module 基于 IP 的訪問控制 -http_auth_basic_module 基于用戶的信任登陸
(基于用戶的信任登陸不是很安全，本文不做配置介紹)
以下是基于 IP 的訪問控制：
server?{
?location?~?^/index.html?{
??#?匹配?index.html?頁面?除了?127.0.0.1?以外都可以訪問
??deny?127.0.0.1;
??allow?all;
?}
}
ab命令
ab命令全稱為：Apache bench，是 Apache 自帶的壓力測試工具，也可以測試 Nginx、IIS 等其他 Web 服務器。
-n 總共的請求數(shù) -c 并發(fā)的請求數(shù)
ab?-n?1000?-c?5000?http://127.0.0.1/
防盜鏈
防盜鏈的原理就是根據(jù)請求頭中 referer 得到網(wǎng)頁來源，從而實現(xiàn)訪問控制。這樣可以防止網(wǎng)站資源被非法盜用，從而保證信息安全，減少帶寬損耗，減輕服務器壓力。
location?~?.*\.(jpg|png|gif)$?{?#?匹配防盜鏈資源的文件類型
????#?通過?valid_referers?定義合法的地址白名單?$invalid_referer?不合法的返回403??
????valid_referers?none?blocked?127.0.0.1;
????if?($invalid_referer)?{
????????return?403;
????}
}
負載均衡 Load Balance
當我們的網(wǎng)站需要解決高并發(fā)、海量數(shù)據(jù)問題時，就需要使用負載均衡來調(diào)度服務器。將請求合理的分發(fā)到應用服務器集群中的一臺臺服務器上。
Nginx 可以為我們提供負載均衡的能力，具體配置如下：
#?upstream?指定后端服務器地址
#?weight?設置權(quán)重
#?server?中會將?http://webcanteen?的請求轉(zhuǎn)發(fā)到?upstream?池中
upstream?webcanteen?{
????server?127.0.0.1:66?weight=10;
????server?127.0.0.1:77?weight=1;
????server?127.0.0.1:88?weight=1;
}
server?{
????location?/?{
????????proxy_pass?http://webcanteen
????}
}
后端服務器狀態(tài)
后端服務器支持以下的狀態(tài)配置：
down：當前服務器不參與負載均衡 backup：當其他節(jié)點都無法使用時的備用服務器 max_fails：允許請求失敗的次數(shù)，若到達就會休眠 fail_timeout：經(jīng)過max_fails次失敗后，服務器的暫停時間，默認為10s max_conns：限制每個服務器的最大接收連接數(shù)
upstream?webcanteen?{
?server?127.0.0.1:66?down;
?server?127.0.0.1:77?backup;
?server?127.0.0.1:88??max_fails=3?fail_timeout=10s;
?server?127.0.0.1:99?max_conns=1000;
}
分配方式
輪詢(默認），每個請求按照時間順序輪流分配到不同的后端服務器，如果某臺后端服務器宕機，Nginx 輪詢列表會自動將它去除掉。 weight(加權(quán)輪詢)，輪詢的加強版，weight 和訪問幾率成正比，主要用于后端服務器性能不均的場景。 ip_hash，每個請求按照訪問 IP 的 hash 結(jié)果分配，這樣每個訪問可以固定訪問一個后端服務器。 url_hash，按照訪問 URL 的 hash 結(jié)果來分配請求，使得每個URL定向到同一個后端服務器上，主要應用于后端服務器為緩存時的場景。 自定義hash，基于任意關(guān)鍵字作為 hash key 實現(xiàn) hash 算法的負載均衡 fair，按照后端服務器的響應時間來分配請求，響應時間短則優(yōu)先分配。
? 在看和轉(zhuǎn)發(fā)是莫大鼓勵??