HTTP協(xié)議 （Hyper Text Transfer Protocol）

HTTP是一個基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)，包括html文件、圖像、結(jié)果等，即是一個客戶端和服務(wù)器端請求和應(yīng)答的標準。

HTTP協(xié)議特點

• http無連接：限制每次連接只處理一個請求，服務(wù)端完成客戶端的請求后，即斷開連接。（傳輸速度快，減少不必要的連接，但也意味著每一次訪問都要建立一次連接，效率降低）
• http無狀態(tài)：對于事務(wù)處理沒有記憶能力。每一次請求都是獨立的，不記錄客戶端任何行為。（優(yōu)點解放服務(wù)器，但可能每次請求會傳輸大量重復(fù)的內(nèi)容信息）
• 客戶端/服務(wù)端模型：客戶端支持web瀏覽器或其他任何客戶端，服務(wù)器通常是nginx或者apache等
• 簡單快速
• 靈活：可以傳輸任何類型的數(shù)據(jù)

一次HTTP請求過程

域名 =》DNS域名解析 =》TCP三次握手建立連接 =》傳輸http報文 =》四次揮手斷開連接

TCP三次握手過程

• 第一次握手客戶端需要發(fā)送一個syn=1告訴服務(wù)端需要聯(lián)機，并且會同時發(fā)送一個隨機生成的順序號碼（seq）。
• 第二次握手由服務(wù)端發(fā)起，服務(wù)端需要回復(fù)客戶端一個確認ACK，這個值為第一次客戶端生成的順序號碼加1，另外也生成一個隨機順序號碼給到客戶端。
• 第三次握手由客戶端收到第二次握手的消息后，回復(fù)服務(wù)端一個確認消息ACK，這個值為服務(wù)端的順序號碼加1，也會發(fā)送一個seq。

第一次握手，是客戶端需要確認自己發(fā)消息沒問題，服務(wù)端收到消息以后證明自己收消息沒問題，這時他還需要證明自己發(fā)消息沒問題所以他發(fā)起第二次握手。
客戶端收到第二次握手的消息后確認了自己的發(fā)消息和收消息都沒問題，但這時候服務(wù)端只知道自己收消息沒有問題，他第二次發(fā)出的消息他并不知道客戶端是否成功接收了。
所以有了第三次握手，告訴服務(wù)端我收到了，你發(fā)消息沒問題。這時，就證明了客戶端和服務(wù)端雙方的收發(fā)都沒有問題。

HTTP請求報文

一個HTTP請求報文由請求行（request line）、請求頭部（header）和請求體（body）組成。

• 請求行：請求方法、請求地址和協(xié)議版本
• 請求頭：主要說Content-Type（請求的與實體對應(yīng)的MIME信息）
  • 常見取值 ：
    application/x-www-form-urlencoded （使用jquery發(fā)送ajax請求會默認類型）
    application/json
    multipart/form-data （傳輸文件固定類型）
  • 后端如何接收：（PHP）
    取值為application/x-www-data-urlencoded情況下$_POST 和 php://input均有值。
    取值為 application/json 時$_POST無值。
    取值為multipart/form-data 時php://input無值。此時應(yīng)該用$_POST來獲取字段，$_FILES 來獲取上傳的文件信息
• 請求體：
  • 常見類型 ：
    application/x-www-form-urlencoded ：a=1&b=2
    application/json ："{"a":1,"b":2}"

HTTP響應(yīng)報文

HTTP響應(yīng)報文主要由狀態(tài)行、響應(yīng)頭、及響應(yīng)數(shù)據(jù)組成。

• 狀態(tài)行：協(xié)議版本，狀態(tài)碼，狀態(tài)碼描述。
• 響應(yīng)頭：主要說Content-Type
  • 常見值 ：
    text/html ： HTML格式
    text/plain ：純文本格式
    text/xml ： XML格式
    image/gif ：gif圖片格式
    image/jpeg ：jpg圖片格式
    image/png：png圖片格式

四次揮手斷開

通過前面，我們已經(jīng)知道ACK是用來應(yīng)答的，SYN是用來代表連接的。而這里的FIN報文就是代表斷開連接的，當主動方?jīng)]有數(shù)據(jù)再需要傳輸給對方時，會向?qū)Ψ桨l(fā)起FIN報文，但這時候被動方不會立馬斷開連接，他只會回復(fù)一個ACK告訴主動方你發(fā)的FIN報文我收到了，很可能不會立馬關(guān)閉，因為他可能還沒處理完請求，可能還有消息需要發(fā)送，這時主動方進入FIN_WAIT_2狀態(tài)。等被動發(fā)也沒有消息需要發(fā)送了，這時候才會也發(fā)一個FIN給主動方，主動方回復(fù)以后，連接斷開。

COOKIE

Http 協(xié)議中引入了 cookie 技術(shù)，用來解決 http 協(xié)議無狀態(tài)的問題。通過在請求和響應(yīng)報文中寫入 Cookie 信息來控制客戶端的狀態(tài)；Cookie會根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報文內(nèi)的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務(wù)器發(fā)送請求時，客戶端會自動在請求報文中加入 Cookie 值后發(fā)送出去。后端以 session 這樣的機制來保存服務(wù)端的對象狀態(tài)。