小張當上了村里的郵差刊咳，每日帶著村民的信件到nginx帝國彪见，傍晚帶著大量的回信回到村子。小張去了師傅家里娱挨，師傅聽了小張講述的已經(jīng)逐漸熟悉了的server_name匹配順序和規(guī)則余指，又從房間拿出了一些新的工具牌。nginx協(xié)議http 1.0和http 1.1是支持長連接的跷坝。http基于tcp協(xié)議之下酵镜，一次請求，需要建立tcp鏈接柴钻，而tcp鏈接是需要三次握手進行確定淮韭，結束請求需要四次交互。這種方式nginx需要耗費資源贴届，時間開銷都會影響整體速度靠粪。
而如果知道請求頭和響應體的長度蜡吧，我們是可以在在一個鏈接上執(zhí)行多個請求。如post請求占键，我們在請求頭上加上請求體body的大小用content-length表示昔善，否則返回400錯誤。請求體是確定的畔乙，響應體中body的長度：
1.http 1.0中響應頭中有content-length頭耀鸦，就是響應體body的長度，取出對應的長度的數(shù)據(jù)就可以結束了啸澡。如果nginx的響應頭沒有給出content-length頭信息袖订，那么就一直接受數(shù)據(jù)，等待nginx自動結束嗅虏。
2.http 1.1中響應頭中的transfer-encoding為chunked傳輸洛姑，代表流式輸出，body體被分為幾個塊皮服，每塊的開始都會標注當前塊的長度楞艾，body不需要指定長度。非chunked傳輸時龄广，有content-length頭信息硫眯，則接受對應長度的數(shù)據(jù)，沒有則等待nginx傳輸結束自動結束掉請求择同。
除了上面兩種不知道響應體長度的两入，body的長度是可以知道的。這時候敲才，我可以在請求頭中增加connection信息裹纳，當對應的值為keepalive時，代表為長連接，nginx在輸出響應體之后，并不關閉連接静袖，而是等待下一次的請求。http 1.0中connection的值默認為cloes朋鞍，而http 1.1默認keep-alive。
小張拿著師傅給的工具牌妥箕，有了這keepalive滥酥，將信件歸類之后，速度就快多了矾踱。
老王：當然恨狈，你速度也要快，nginx看到keep-alive之后呛讲，不會馬上關閉連接禾怠，但是也不可能一直等待返奉。nginx設置了keepalive鏈接屬性和一個keepalive_timeout等待時間，超出這個時間吗氏，nginx還沒有收到請求芽偏，就會關掉鏈接。keepalive_timeout也可以配置為0弦讽，這樣表示nginx不接受長連接污尉，無論請求頭是否添加了keepalive屬性。（如果有大量的請求往产，開啟長連接被碗，nginx可以減少大量的tine-wait）。
小張：那這個pipe有什么用呢仿村？
老王：這是http 1.1的屬性锐朴，pipeline是基于長連接的，目的是用一個鏈接做多次請求蔼囊。對于keepalive焚志，多個請求中第二個請求必須等待第一個請求結束，pipeline可以在第一個請求沒有結束就發(fā)起第二個請求畏鼓。（nginx支持pipeline酱酬，但是內部已然是一個一個處理，但是減少了處理完第一個請求云矫，等待第二個請求的時間）
