摘要：引入機制，定時給發送空數據包，稱為心跳包，一旦發現網絡不通則關閉連接。一般使用的方案是服務端根據客戶端請求頭的某些字段發送最合適的版本。是為了解決某些瀏覽器啟用帶來的問題。首先生成用于分割不同字段。消息主體最后以結束。

基本命令
start nginx
nginx -s stop（立即停止）
nginx -s quit（平緩停止，有請求事不會意外停止）
nginx -s reload
遇到的坑：不要重復地去啟動多個nginx進程，這樣會導致你修改的nginx對應不上，可以通過資源管理器殺掉進程

短連接：TCP建立連接->請求資源->響應資源-> 關閉連接 每次請求都要經歷這樣的過程
長連接：建立一次連接后，每次請求都復用該連接。
并行連接：并發的短連接
http1.0中為了支持長連接必須在請求頭中指定

Connection:keep-alive

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

Connection:close 指定不使用長連接

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

pipeline流水線作業
http1.1新特性，一個連接做多次請求；
在keepaiive中第二個請求要等第一個請求響應完全接受之后才能發起。
在pipeline中不必等待第一個請求處理后就可以發起第二個請求，nginx會把讀取的數據放在buffer中，在nginx處理完第一個請求時發現buffer中還有數據，就會任務剩下的數據是下一個請求的開始，然后處理下一個請求，否則設置為keepalive

擴展：TCP的keepalive：
AB在三次握手建立TCP連接之后，B突然宕機了，但是A內核還會維護著AB之間的連接，浪費系統資源。引入keepalive機制，A定時給B發送空數據包，稱為心跳包，一旦發現B網絡不通則關閉連接。
Nginx涉及到tcp層面的keepalive只有一個：so_keepalive

Http處理過程
初始化http request（讀取客戶端數據，生成HTTP Request對象，該對象包含了所有請求信息）
處理請求頭
處理請求體
調用此請求的url或者location關聯的handle
依次調用各phase handler處理（phase handler是指包含某階段若干個handler）

一個phase handler處理的任務

獲取location配置

產生適當的響應

response header

response body

當nginx讀取到一個http Request的header時，首先尋找與請求關聯的虛擬主機配置，如果找到則經歷以下幾個phase handler
1.server級別的url重寫階段,在讀取請求頭過程中nginx會根據host和端口尋找對應的虛擬主機配置：

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

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

2.location rewrite

執行server rewrite

執行location匹配

執行location rewrite

location 與 location rewrite的區別：

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

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

# 此處沒有帶http:// 所以只是簡單的重寫。請求的 uri 由 /test/baidu 重寫為 www.baidu.com
# 因為會順序執行 rewrite 指令 所以 下一步執行 return 指令 響應了 ok 

TCP優化

http {
    sendfile           on;
    tcp_nopush         on;
    tcp_nodelay        on;

    keepalive_timeout  60;
    ... ...

senfile on可以提高靜態資源托管效率，是一個系統調用，不需要先read再write，沒有上下文切換開銷
tcp_nopush 在sendfile開啟后才生效，啟用后數據包累計一定的大小才會發送，提高了網絡效率，減少了開銷
tcp_nodelay 數據包累計到一定大小后盡快發送，nginx只會針對處于keepalive的TCP連接啟用tcp_nodelay
keepalive_timeout 表示每個tcp連接可以保持多少秒，默認是75秒，有些瀏覽器最多是保持60秒，所以設置為60秒

TFO(TCP Fast open)優化策略

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

開啟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響應頭解決某些服務緩存問題

http內容協商機制，同一個url可能對應多份不同文檔，要求服務端和客服端有一個選擇最合適版本的機制。例如服務端可以將靜態文件輸出為壓縮和未壓縮兩個版本。

一般使用的方案是服務端根據客戶端請求頭的某些字段發送最合適的版本。分為內容專用字段（Accept字段）、其他字段

//請求頭
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的優先級最高(q 取值 0 - 1，最高為 1，最低為 0，默認為 1),服務端應優先返回zh-cn

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

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

//當內容取決于User-Agent和cookie時，vary字段應該類似于這樣，也就是列出一個響應字段列表，告訴緩存服務器遇到同一個url的時候如何緩存和篩選合適的版本。
Vary:User-Agent, Cookie;

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

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

gzip_disable
接受一個正則匹配，請求的User-Agent匹配到后響應不會啟用gzip。是為了解決某些瀏覽器啟用gzip帶來的問題。

gip_http_version
nginx默認啟用http版本是Http/1.1,因為早期Http/1.0啟用gzip有bug，現在基本忽略，所有可以指定gzip_http_version: 1.0;

開啟緩存
優化代碼邏輯的極限是移除所有極限；優化請求的極限是不發送任何請求。

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：默認所有文件放在/home/nginx/proxy_cache_path下，影響緩存性能，大部分場景是推薦使用2級目錄來緩存文件。

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

application/x-www-form-urlencoded

原生的form提交不設置enctype屬性時默認使用這種格式提交，提交格式按照val1=key1&val2=key2格式進行編碼，key和val都進行了url轉碼。

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表單上傳文件的時候必須設置enctype為這個格式。首先生成boundary用于分割不同字段。Content-type中指明了數據是以multipart/form-data來編碼，boundary是什么。

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

如果傳輸的是文件，還要包括文件名和文件類型信息。消息主體最后以--boundary--結束。

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

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

text/html