摘要：引入機(jī)制，定時(shí)給發(fā)送空數(shù)據(jù)包，稱為心跳包，一旦發(fā)現(xiàn)網(wǎng)絡(luò)不通則關(guān)閉連接。一般使用的方案是服務(wù)端根據(jù)客戶端請(qǐng)求頭的某些字段發(fā)送最合適的版本。是為了解決某些瀏覽器啟用帶來的問題。首先生成用于分割不同字段。消息主體最后以結(jié)束。

基本命令
start nginx
nginx -s stop（立即停止）
nginx -s quit（平緩?fù)Ｖ?，有?qǐng)求事不會(huì)意外停止）
nginx -s reload
遇到的坑：不要重復(fù)地去啟動(dòng)多個(gè)nginx進(jìn)程，這樣會(huì)導(dǎo)致你修改的nginx對(duì)應(yīng)不上，可以通過資源管理器殺掉進(jìn)程

短連接：TCP建立連接->請(qǐng)求資源->響應(yīng)資源-> 關(guān)閉連接 每次請(qǐng)求都要經(jīng)歷這樣的過程
長(zhǎng)連接：建立一次連接后，每次請(qǐng)求都復(fù)用該連接。
并行連接：并發(fā)的短連接
http1.0中為了支持長(zhǎng)連接必須在請(qǐng)求頭中指定

Connection:keep-alive

在 HTTP 1.1 中 所有的連接默認(rèn)都是持續(xù)連接，除非特殊聲明不支持；現(xiàn)在大多數(shù)瀏覽器都默認(rèn)是使用HTTP/1.1，所以keep-alive都是默認(rèn)打開的

Connection:close 指定不使用長(zhǎng)連接

怎么判斷一個(gè)請(qǐng)求數(shù)據(jù)接收完？
在響應(yīng)頭中如果有Tansfer-Encoding:chunked則表示body為流式輸出，會(huì)被分成多個(gè)塊，每個(gè)塊開始都會(huì)標(biāo)識(shí)當(dāng)前塊的長(zhǎng)度，此時(shí)body不需要長(zhǎng)度；如果是非chunked則按照content-length來接收數(shù)據(jù)；否則等到服務(wù)端主動(dòng)斷開連接。
nginx中關(guān)于transfer-encoding的設(shè)置chunked_transfer_encoding on | off;
建立連接后服務(wù)端不是一直在等待下一次請(qǐng)求，通過nginx設(shè)置最大等待時(shí)間
nginx: http模塊中可以設(shè)置超大等待時(shí)間
keepalive_timeout 65;

pipeline流水線作業(yè)
http1.1新特性，一個(gè)連接做多次請(qǐng)求；
在keepaiive中第二個(gè)請(qǐng)求要等第一個(gè)請(qǐng)求響應(yīng)完全接受之后才能發(fā)起。
在pipeline中不必等待第一個(gè)請(qǐng)求處理后就可以發(fā)起第二個(gè)請(qǐng)求，nginx會(huì)把讀取的數(shù)據(jù)放在buffer中，在nginx處理完第一個(gè)請(qǐng)求時(shí)發(fā)現(xiàn)buffer中還有數(shù)據(jù)，就會(huì)任務(wù)剩下的數(shù)據(jù)是下一個(gè)請(qǐng)求的開始，然后處理下一個(gè)請(qǐng)求，否則設(shè)置為keepalive

擴(kuò)展：TCP的keepalive：
AB在三次握手建立TCP連接之后，B突然宕機(jī)了，但是A內(nèi)核還會(huì)維護(hù)著AB之間的連接，浪費(fèi)系統(tǒng)資源。引入keepalive機(jī)制，A定時(shí)給B發(fā)送空數(shù)據(jù)包，稱為心跳包，一旦發(fā)現(xiàn)B網(wǎng)絡(luò)不通則關(guān)閉連接。
Nginx涉及到tcp層面的keepalive只有一個(gè)：so_keepalive

Http處理過程
初始化http request（讀取客戶端數(shù)據(jù)，生成HTTP Request對(duì)象，該對(duì)象包含了所有請(qǐng)求信息）
處理請(qǐng)求頭
處理請(qǐng)求體
調(diào)用此請(qǐng)求的url或者location關(guān)聯(lián)的handle
依次調(diào)用各phase handler處理（phase handler是指包含某階段若干個(gè)handler）

一個(gè)phase handler處理的任務(wù)

獲取location配置

產(chǎn)生適當(dāng)?shù)捻憫?yīng)

response header

response body

當(dāng)nginx讀取到一個(gè)http Request的header時(shí)，首先尋找與請(qǐng)求關(guān)聯(lián)的虛擬主機(jī)配置，如果找到則經(jīng)歷以下幾個(gè)phase handler
1.server級(jí)別的url重寫階段,在讀取請(qǐng)求頭過程中nginx會(huì)根據(jù)host和端口尋找對(duì)應(yīng)的虛擬主機(jī)配置：

server{
    rewrite 規(guī)則 定向路徑 重寫類型
    # 訪問 /last.html 的時(shí)候，頁面內(nèi)容重寫到 /index.html 中
    rewrite /last.html /index.html last;
}
    
規(guī)則：字符串或者正則來匹配目標(biāo)url
定向路徑：匹配到規(guī)則后要定向的url
重寫類型：

 1. last 完成重寫瀏覽器地址欄url不變
 2. break終止后面的匹配，地址欄url不變
 3. redirect 302臨時(shí)重定向，地址欄顯示跳轉(zhuǎn)后的url
 4. permanent 301永久重定向，顯示跳轉(zhuǎn)后的url

2.location rewrite

執(zhí)行server rewrite

執(zhí)行l(wèi)ocation匹配

執(zhí)行l(wèi)ocation rewrite

location 與 location rewrite的區(qū)別：

location是對(duì)一類資源控制訪問和反向代理，proxy_pass到其他機(jī)器，location rewrite則是更改資源獲取路徑

rewrite regex replacement [flag];
1.重寫帶http://
location /{
    # 當(dāng)匹配 正則表達(dá)式 /test/(.*)時(shí) 請(qǐng)求將被臨時(shí)重定向到 http://www.$1.com
    rewrite /test/(.*) http://www.$1.com
    return 200 "ok"
}
# 在瀏覽器中輸入 127.0.0.1:8080/test1/baidu 
# 則臨時(shí)重定向到 www.baidu.com
# 后面的 return 指令將沒有機(jī)會(huì)執(zhí)行了
2.重寫不帶http://
location / {
    rewrite /test/(.*) www.$1.com;
    return 200 "ok";
}
# 發(fā)送請(qǐng)求如下
# curl 127.0.0.1:8080/test/baidu
# ok

# 此處沒有帶http:// 所以只是簡(jiǎn)單的重寫。請(qǐng)求的 uri 由 /test/baidu 重寫為 www.baidu.com
# 因?yàn)闀?huì)順序執(zhí)行 rewrite 指令 所以 下一步執(zhí)行 return 指令 響應(yīng)了 ok 

TCP優(yōu)化

http {
    sendfile           on;
    tcp_nopush         on;
    tcp_nodelay        on;

    keepalive_timeout  60;
    ... ...

senfile on可以提高靜態(tài)資源托管效率，是一個(gè)系統(tǒng)調(diào)用，不需要先read再write，沒有上下文切換開銷
tcp_nopush 在sendfile開啟后才生效，啟用后數(shù)據(jù)包累計(jì)一定的大小才會(huì)發(fā)送，提高了網(wǎng)絡(luò)效率，減少了開銷
tcp_nodelay 數(shù)據(jù)包累計(jì)到一定大小后盡快發(fā)送，nginx只會(huì)針對(duì)處于keepalive的TCP連接啟用tcp_nodelay
keepalive_timeout 表示每個(gè)tcp連接可以保持多少秒，默認(rèn)是75秒，有些瀏覽器最多是保持60秒，所以設(shè)置為60秒

TFO(TCP Fast open)優(yōu)化策略

客戶端第一次建立連接還是要三次握手，不同的是客戶端會(huì)在第一個(gè)SYN設(shè)置一個(gè)fast-open的標(biāo)志，服務(wù)端會(huì)生成fast-open cookie并放在SYN-ACK中，客戶端就可以把cookie存起來以后syn用；
在這之后用戶再建立TCP連接，發(fā)送syn包的同時(shí)會(huì)把cookie帶上，然后可以直接帶上http數(shù)據(jù)。換句話說在發(fā)送SYN包的時(shí)候把應(yīng)用層數(shù)據(jù)發(fā)送出來，減少了一個(gè)RTT對(duì)性能的影響。
但是這種優(yōu)化成本非常高需要操作系統(tǒng)、內(nèi)核的支持（服務(wù)端和用戶端都要支持）。

開啟gzip

http {
    gzip               on;
    gzip_vary          on;

    gzip_comp_level    6;
    gzip_buffers       16 8k;

    gzip_min_length    1000;
    gzip_proxied       any;
    gzip_disable       "msie6";

    gzip_http_version  1.0;

    gzip_types         text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
    ... ...
}

gzip_vary 用來輸出vary響應(yīng)頭解決某些服務(wù)緩存問題

http內(nèi)容協(xié)商機(jī)制，同一個(gè)url可能對(duì)應(yīng)多份不同文檔，要求服務(wù)端和客服端有一個(gè)選擇最合適版本的機(jī)制。例如服務(wù)端可以將靜態(tài)文件輸出為壓縮和未壓縮兩個(gè)版本。

一般使用的方案是服務(wù)端根據(jù)客戶端請(qǐng)求頭的某些字段發(fā)送最合適的版本。分為內(nèi)容專用字段（Accept字段）、其他字段

//請(qǐng)求頭
Accept:*/* 接受任何MIME類型資源
Accept-Encoding:gzip,deflate,sdch 接受gzip，deflate，sdch壓縮過的資源
Accept-Language:zh-CN,en-US;q=0.8,en;q=0.6 可以接受zh-ch，en-us,en;其中zh-cn的優(yōu)先級(jí)最高(q 取值 0 - 1，最高為 1，最低為 0，默認(rèn)為 1),服務(wù)端應(yīng)優(yōu)先返回zh-cn

//響應(yīng)頭
Content-Type: text/javascript 表示文檔確切的類型是text/javascript
Content-Encoding: gzip 文檔使用了gzip壓縮
//沒有content-language通常表示返回的是Accept-language權(quán)重最高的那種語言

Accept字段并不夠用，如果要針對(duì)特定瀏覽器，如ie6就要使用到user-agent；cookie也可能作為服務(wù)器輸出內(nèi)容差異的依據(jù)。
如果服務(wù)器和客戶端之間存在有緩存服務(wù)器，而服務(wù)器根據(jù)不同的user-agent返回不同的內(nèi)容，緩存服務(wù)器卻把針對(duì)特定瀏覽器的內(nèi)容緩存下來統(tǒng)一返回，就會(huì)有問題。
所以http協(xié)議規(guī)定，如果服務(wù)器提供的內(nèi)容是取決于user-agent（Accept之外的字段）請(qǐng)求頭字段，響應(yīng)頭中必須要包含vary字段，而且vary字段必須包含user-agent。

//當(dāng)內(nèi)容取決于User-Agent和cookie時(shí)，vary字段應(yīng)該類似于這樣，也就是列出一個(gè)響應(yīng)字段列表，告訴緩存服務(wù)器遇到同一個(gè)url的時(shí)候如何緩存和篩選合適的版本。
Vary:User-Agent, Cookie;

Content-Encoding在緩存服務(wù)器的問題
緩存服務(wù)器應(yīng)該根據(jù)不同的Content-Encoding緩存不同的內(nèi)容，再根據(jù)請(qǐng)求頭的Accept-Encoding來返回合適的版本。為了避免給客戶端返回不合適的版本：
1.將請(qǐng)求頭的Cache-control改為private
2.增加vary:Accept-Encoding明確告訴緩存服務(wù)器按照Accept-Encoding字段內(nèi)容緩存不同的版本。

以上的工作nginx都以gzip_vary: on搞定，相當(dāng)于在啟用了gzip的響應(yīng)上加vary:Accept-Encoding

gzip_disable
接受一個(gè)正則匹配，請(qǐng)求的User-Agent匹配到后響應(yīng)不會(huì)啟用gzip。是為了解決某些瀏覽器啟用gzip帶來的問題。

gip_http_version
nginx默認(rèn)啟用http版本是Http/1.1,因?yàn)樵缙贖ttp/1.0啟用gzip有bug，現(xiàn)在基本忽略，所有可以指定gzip_http_version: 1.0;

開啟緩存
優(yōu)化代碼邏輯的極限是移除所有極限；優(yōu)化請(qǐng)求的極限是不發(fā)送任何請(qǐng)求。

http{
    proxy_cache_path /home/nginx/proxy_cache_path levels=1:2 keys_zone=pnc:300m inactive=7d max-size=10g;
}

/home/nginx/proxy_cache_path: 本地路徑，緩存文件存放的路徑
levels：默認(rèn)所有文件放在/home/nginx/proxy_cache_path下，影響緩存性能，大部分場(chǎng)景是推薦使用2級(jí)目錄來緩存文件。

post請(qǐng)求提交數(shù)據(jù)的四種格式
http協(xié)議規(guī)定post方法提交的數(shù)據(jù)主體必須方式消息主體中（entity-body），但是協(xié)議并沒有規(guī)定數(shù)據(jù)必須使用什么編碼格式。開發(fā)者可以自己決定主體內(nèi)容。服務(wù)器都內(nèi)置了解析常見數(shù)據(jù)格式的功能，根據(jù)請(qǐng)求頭的content-type來獲取消息中的請(qǐng)求消息主體是以何種方式編碼，再對(duì)主體進(jìn)行解析。
Content-Type

application/x-www-form-urlencoded

原生的form提交不設(shè)置enctype屬性時(shí)默認(rèn)使用這種格式提交，提交格式按照val1=key1&val2=key2格式進(jìn)行編碼，key和val都進(jìn)行了url轉(zhuǎn)碼。

POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

multipart/form-data

在form表單上傳文件的時(shí)候必須設(shè)置enctype為這個(gè)格式。首先生成boundary用于分割不同字段。Content-type中指明了數(shù)據(jù)是以multipart/form-data來編碼，boundary是什么。

消息主體中按照字段的個(gè)數(shù)又分為多個(gè)類似結(jié)構(gòu)的部分，每部分都是以--boundaey開頭，緊接著內(nèi)容描述信息，然后回車最后是字段具體內(nèi)容(文本或者二進(jìn)制)。

如果傳輸?shù)氖俏募?，還要包括文件名和文件類型信息。消息主體最后以--boundary--結(jié)束。

POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA

------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"

title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png

PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

application/json

告訴服務(wù)器消息主體是序列化后的json字符串

text/html