前言：
tcp四次揮手過程中，誰主動斷開，誰有time_wait，被動斷開一方會有close_wait
- time_wait:保持端口占用2mls~4min,避免對方還有一些tcp片發往這個端口，新鏈接受影響。time_wait的缺點：占用內存
- close_wait:被動關閉一方接受到fin信號后馬上回復ack表示收到fin信號，同時進入close_wait 狀態，等待未傳輸完成的data繼續傳輸完畢，close_wait狀態結束，發送fin信號。即close_wait的目的是等待未傳輸完成的data繼續傳輸完畢。
http 1.0與1.1
http1.0 默認是短連接，client端主動發起，server端服務完畢后，將連接關畢，client端也借此判斷數據發送完畢。所以http1.0時代，服務端容易有較多的time_wait。
- 如果http 1.0協議，client希望使用長連接，需要在header中設置connection:keep-alive
http1.1默認是長連接
- 如果client不希望使用長連接，需要在header中設置connection:close
- 如果server不希望使用長連接，也需要在reponse中設置connection:close
http header中keep-alive參數用於設置客戶端希望服務端保持連接的秒數
長連接的問題
keep-alive模式帶來的問題：此時服務端不關閉連接，客戶端如何知道消息內容是否發送完畢（bfe曾經因為對http1.0沒有主動關閉連接，導致一些老舊php上的的socket http包因為等待服務端關閉連接判斷消息發送完畢而超時）
keep-alive模式下，通過兩種方式
- 服務端reqponse設置content-length參數：告知內容大小，客戶端收到指定內容長度后即可關閉連接。客戶端發送post時也會采用這種方式，如若content-length大於實際發生的值會超時，小於則服務端會響應400。這種模式有缺陷，動態頁面服務器也不知道內容大小，只有等內容全准備完畢后才知道，若等到此時發送，效率太低了。
- transfer-encoding:chunked模式：此模式下簡單說是規定一直特殊的響應data格式，此種格式中會包含body結束的標志。客戶端收到此標志即知道數據發送完畢，可以組裝解密數據了。
content-length,transfer-encoding,content-encoding
- transfer-encoding:傳輸編碼，針對傳輸過程來的，傳輸完解碼才拿到對象。用於在網絡傳輸國財中保證數據安全成功的傳輸。在http1.1里，如果有transfer-encoding，則必須是chunked，此時不能有content-lengh參數，即使有也會忽略。transfer-encoding相沖突，因為transfer-encoding會通過額外的處理方式來改變數據的組織方式，就會改變實際的數據長度，如果客戶端仍按照原content-length來處理的話，則不會接收到完整的數據。
- content-encoding: 內容編碼和accept-encoding對應。比如gzip，對於文本有較好的壓縮效果。
附兩篇很好的文章
1.介紹http:https://www.byvoid.com/zhs/blog/http-keep-alive-header
2.content-length:http://www.tuicool.com/articles/FJ7rye
3.http協議官方文檔：http://greenbytes.de/tech/webdav/rfc7230.html#header.content-length
4.http://liupan2668.blog.163.com/blog/static/12038513120140129504967/