簡介
HTTP協定是
Hyper Text Transfer Protocol
（超文本傳輸協定）的縮寫，是用于從網際網路（
www：World Wide Web
）伺服器傳輸超文本到本地浏覽器的傳送協定。
HTTP是一個基于TCP/IP通信協定來傳遞資料（HTML檔案，圖檔檔案，查詢結果等）。
HTTP是一個屬于應用層的面向對象的協定，由于其簡捷、快速的方式，适用于分布式超媒體資訊系統。它于1990年提出，經過幾年的使用與發展，得到不斷地完善和擴充。目前在WWW中使用HTTP/1.0的第六版，HTTP/1.1的規範化工作正在進行中，而且HTTP-NG（Next Generation of HTTP）的建議已經提出。
HTTP協定工作于用戶端-伺服器架構構為上。浏覽器作為HTTP用戶端通過URL向HTTP服務端即WEB伺服器發送所有請求。Web伺服器根據接收到的請求後，想用戶端發送響應資訊。
一、HTTP協定
1.HTTP特點
-
簡單快速
GET、HEAD、POST
-
靈活
-
無連接配接
-
無狀态
-
支援B/S及C/S模式
2.URL的作用
URL，全稱是UniformResourceLocator,中文叫統一資源定位符，是網際網路上用來辨別某一處資源的位址。以下面這個URL為例，介紹下普通URL的各部分組成：
從上面的URL可以看出，一個完整的URL包括以下幾部分：
-
協定部分
-
域名部分
-
端口部分
-
虛拟目錄部分
-
檔案名部分
-
錨部分
-
參數部分
URI和URL的差別
URI，是uniform resource identifier,統一資源辨別符，用來唯一的辨別一個資源。
Web上可用的每種資源如HTML文檔、圖像、視訊片段、程式等都是一個來URI來定位的URI一般由三部分組成：
-
通路資源的命名機制
-
存放資源的主機名
-
資源自深的名稱，由路徑表示，着重強調于資源
URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來辨別一個資源，而且還指明了如何locate這個資源。
采用URL可用用一種統一的格式來描述各種資訊資源，包括檔案、伺服器的位址和目錄等。URL一般由三部分組成：
- 協定（或稱為服務方式）
- 存有該資源的主機IP位址（有時也包括端口号）
- 主機資源的具體位址。如目錄和檔案名等
URI是以一種抽象的，高層次概念定義統一資源辨別，而且URL和URN則是具體的資源辨別的方式。URL和URN都是一種URI。籠統地說，每個URL都是URI，但不一定每個URI都是URL。這是因為URI還包括一個子類，即統一資源名稱（URN），它命名資源但不指定如何定位資源。上面的mailto、news和isbn URI都是URN的示例。
3.請求響應
請求request
用戶端發送一個HTTP請求到伺服器的請求消息包括以下格式： 請求行（
request line
）、請求頭部（
header
）、空行和請求資料四個部分組成。
請求行以一個方法符号開頭，以空格分開，後面跟着請求的URI和協定的版本。
Get請求例子，使用Charles抓取的request：
GET /562f25980001b1b106000338.jpg HTTP/1.1
Host img.mukewang.com
User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/51.0.2704.106 Safari/537.36
Accept image/webp,image/,/*;q=0.8
Referer http://www.imooc.com/
Accept-Encoding gzip, deflflate, sdch
Accept-Language zh-CN,zh;q=0.8
複制代碼
第一部分
：請求行，用來說明請求類型，要通路的資源以及所使用的HTTP版本。
GET說明請求類型為GET，[/562f25980001b1b106000338.jpg]為要通路的資源，該行的最後一部分說明使用的是HTTP1.1版本。
第二部分
：請求行，緊接着請求行（即第一行）之後的部分，用來說明伺服器要使用的附加資訊
第三部分
：空行，請求頭部後面的空行是必須的
即使第四部分的請求資料為空，也必須有空行。
第四部分
：請求資料也叫主體，可以添加任意的其他資料。
POST請求例子：
POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727;
.NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive
name=Professional%20Ajax&publisher=Wiley
複制代碼
第一部分
：請求行，第一行明了是post請求，以及http1.1版本。（從0開始）
第二部分
：請求頭部，第二行至第六行。
第三部分
：空行，第七行的空行。
第四部分
：請求資料，第八行。
響應response
一般情況下，伺服器接收并處理用戶端發過來的請求後會放回一個HTTP的響應消息。HTTP響應也由四個部分組成，分别是：
狀态行、消息報頭、空行和響應正文
。
例子:
HTTP/1.1 200 OK
Date: Fri, 22 May 2009 06:07:21 GMT
Content-Type: text/html; charset=UTF-8
<html>
<head></head> <body>
<!--body goes here-->
</body>
</html>
複制代碼
第一部分
：狀态行，由HTTP協定版本号，狀态碼，狀态消息 三部分組成。
第一行，（HTTP/1.1）表明HTTP版本為1.1版本，狀态碼為200，狀态消息為（ok）
第二部分
：消息報頭，用來說明用戶端要使用的一些附加資訊。
第二行和第三行為消息報頭，Date：生成響應的日期和時間；Content-Type：指定了MIME類型的HTML(text/html),編碼類型是UTF-8
第三部分
：空行，消息報頭後面的空行是必須的
第四部分
：響應正文，伺服器傳回給用戶端的文本資訊。
空行後面的html部分為響應正文。
常見狀态碼
：
- 200 OK //用戶端請求成功
- 400 Bad Request//用戶端請求有文法錯誤，不能被伺服器所了解
- 401 Unauthorized//請求未經授權，這個狀态代碼必須和WWW- Authenticate報頭域以前使用
- 404 Not Found//請求資源不存在，eg：輸入了錯誤的URL
- 500 Internal Server Error//伺服器發生不可預期的錯誤
- 503 Server Unavailable//伺服器目前不能處理用戶端的請求，一段時間後可能恢複正常
HTTP請求方法有
HTTP1.0定義了三種：
GET
，
POST
和
HEAD方法
。
HTTP1.1新增五種：
OPTIONS
，
PUT
，
DELETE
，
TRACE
和
CONNECT
方法。
1、
OPTIONS
傳回伺服器針對特定資源所支援的HTTP請求方法，也可以利用向web伺服器發送‘*’的請求來測試伺服器的功能性
2、
HEAD
向伺服器索與GET請求相一緻的響應，隻不過響應體将不會被傳回。這一方法可以再不必傳輸整個響應内容的情況下，就可以擷取包含在響應小消息頭中的元資訊。
3、
GET
向特定的資源送出請求。注意：GET方法不應當被用于産生“副作用”的操作中，例如在Web Application中，其中一個原因是GET可能會被網絡蜘蛛等随意通路。Loadrunner中對應get請求函數：web_link和web_url
4、
POST
向指定資源送出資料進行處理請求（例如送出表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導緻新的資源的建立和/或已有資源的修改。 Loadrunner中對應POST請求函數：web_submit_data,web_submit_form
5、
PUT
向指定資源位置上傳其最新内容
6、
DELETE
請求伺服器删除Request-URL所辨別的資源
7、
TRACE
回顯伺服器收到的請求，主要用于測試或診斷
8、
CONNECT
HTTP/1.1協定中預留給能夠将連接配接改為管道方式的代理伺服器。 注意：
- 方法名稱是區分大小寫的，當某個請求所針對的資源不支援對應的請求方法的時候，伺服器應當傳回狀态碼405（Mothod Not Allowed）；當伺服器不認識或者不支援對應的請求方法時，應傳回狀态碼501（Not Implemented）。
- HTTP伺服器至少應該實作GET和HEAD/POST方法，其他方法都是可選的，此外除上述方法，特定的HTTP伺服器支援擴充自定義的方法。
4.三次握手&四次揮手
TCP協定的三次握手，四次揮手過程解析：
這圖書本上有：
HTTP2.0 全雙工，半雙工。
第一次握手
：發送syn（seq=x）包時，希望像接收端建立連接配接，并初始化序列号。此時發送端進入syn_sent狀态
第二次握手
：接收端接收到了syn包，發送ack+syn包，并初始化序列号，并将發送的序列号+1放入确認應答号中。此時接收端進入syn_rcvd狀态
第三次握手
：發送ack包，給确認應答号+1，表示收到了接收端的封包，進入establelisten狀态服務端收到了用戶端的封包後，也進入了establelisten狀态
注意
：這裡的第三次握手是可以攜帶資料的，因為發送端已經确認了服務端有接受和發送的能力。而其他兩次并沒有确認對方的接受能力
為什麼說三次握手呢？而不是兩次，四次？
-
避免舊的重複連接配接初始化造成混亂
:
假設我們發送端前面發送了一個序列号為90的syn封包，此時網絡中擁塞了，此時發送端可能會連續發起多次請求。但是此時的序列号為90的封包也到了，如果是兩次握手的話，接收端接受到就會進入establelisten狀态(進入這個狀态後就可以發送資料)，然而當發送方判斷這是一個曆史連接配接，發送RST封包終止連接配接，但此時服務端已經進入了establelisten狀态，并且可能發送了資料。斷開的話，白白造成了服務端的資源浪費。為了避免舊的重複連接配接，必須在建立連接配接之前就殺掉這個重複連接配接，這就必須要三次握手才能實作
-
同步初始化序列号
:
序列号的作用：
- 使對方有序的接受資料包
- 避免對方接收重複的資料包
-
可以知道自己發送出去的資料包，哪些是被接收的
三次握手的話，用戶端發送一個syn封包，服務端接受到後發送syn+ack封包，表示用戶端的初始化序列号已經收到。用戶端在回複ack封包，表示服務端的初始化序列号也已經收到。這樣才能確定雙方序列号都被同步了。如果是兩次握手，隻能保證一方的序列号被成功接收
-
防止資源浪費
:
用戶端發送syn封包時，可能被網絡擁塞了，也有可能服務端的ack+syn封包擁塞了，那麼用戶端就會重發syn封包。如果是兩次握手的話，服務端每來一個syn封包，就會建立一個連接配接，這樣就會造成備援連接配接，造成不必要的資源浪費
小結
:
為什麼不使用兩次握手：無法防止曆史連接配接的建立，會造成資源浪費，不能同步雙方序列号
為什麼不使用四次握手：三次握手已經足夠，再多一次握手隻會造成更多的連接配接時延
第一次揮手
：主動斷開方（用戶端，服務的都可以）向對方發送一個FIN結束請求封包，并設定序列号和确認号，随後主動斷開方進入
FIN_WAIT1
狀态，這表示主動斷開方已經沒有業務資料要發給對方了，準備關閉
SOCKET
連接配接了。
第二次揮手
：被動斷開方收到FIN斷開請求後會發送一個ACK響應封包，表明同意斷開請求。随後被動斷開方就進入CLOSE-WAIT狀态（等待關閉狀态），此時若被動斷開方還有資料要發送給主動方，主動方還會接受。被動方會持續一段時間。 主動方收到ACK封包後，由FIN_WAIT_1轉換成FIN_WAIT_2狀态。
第三次揮手
：被動斷開方的CLOSE-WAIT（等待關閉）結束後，被動方會向主動方發送一個
FIN+ACK
封包 表示被動方的資料都發完了。然後被動方進入LAST_ACK狀态。
第四次揮手
：主動斷開方收到
FIN+ACK
斷開響應封包後，還需進行最後确認，向被動方發送一個ACK确認封包，然後主動方進入TIME_WAIT狀态，在等待完成2MSL時間後，如果期間沒有收到被動方的封包，則證明對方已正常關閉，主動斷開方的連接配接最終關閉。 被動方在收到主動方第四次揮手發來的ACK封包後，就關閉了連接配接。
簡單了解：
第一次：主動方：我要斷開連接配接（FIN）
第二次：被動方：好的，知道了，但我還有些資料要發（ACK），等我發完
第三次：被動方：我的資料已經發完了（FIN+ACK）
第四次：主動方：确認沒有了嗎？（ACK），沒有我就關了哦。
被動方：看來他要關了。
SYN
：同步序列編号(Synchronize Sequence Numbers)
Client将标志位SYN設定為1
，随機産生一個值seq=1 該序列編号為TCP連接配接初始端（一般是用戶端）的初始序列編号。在這裡，可以把TCP序列編号看作是一個範圍從0到4，294，967，295的32位計數器。通過TCP連接配接交換的資料每一個位元組都經過序列編号。在TCP報頭中的序列編号欄包括了TCP分段種第一個位元組的序列編号。
ACK
：确認标志
确認編号（Acknowledgement Number）欄有效。大多數情況下該标志位是置位的。TCP報頭内的确認編号欄内包含的确認編号（w+1,Figure-1）為下一個預期的序列編号，同時提示遠端系統以及成功接收所有資料。
序列号
：在建立連接配接時就由計算機随機生成，每發送一次資料，該序列号+1，用來解決網絡中包亂序的問題
确認應答号
：表示下一次期望收到的封包序列号，表示以前的資料報都已經收到了，用來解決網絡中丢包的問題
控制位
：
ACK：該位為1時，确認應答号是有效的，除了建立連接配接開始的syn包時，其他包該位必須為1
RST：該位為1時，表示出現異常，強制連接配接斷開
SYN： 該位為1時，表示希望建立連接配接，并且初始化序列号
FIN： 該位為1時，希望正常斷開連接配接，通信雙方互相交換FIN，表示可以斷開
5.OSI七層協定
OSI 七層 由 底向上分别是：實體層、資料鍊路層、網絡層、傳輸層、會話層、表示層、應用層。
簡化後的四層分别是：主機到網絡層（比特）、網絡層（資料幀）、傳輸層（資料包）、應用層（資料段）。
1.
應用層
應用層是計算機使用者，以及各種應用程式和網絡之間的接口，其功能是直接向使用者提供服務，完成使用者希望在網絡上完成的各種工作。
應用層為使用者提供的服務和協定：檔案傳輸服務（
FTP
）、遠端登入服務（
ssh
）、網絡管理服等。
上述的各種網絡服務由該層的不同應用協定和程式完成。
應用層的主要功能如下：
使用者接口
：應用層是使用者與網絡，以及應用程式與網絡間的直接接口，使得使用者能夠與網絡進行互動式聯系。
實作各種服務
：該層具有的各種應用程式可以完成和實作使用者請求的各種服務。
2.
表示層
表示層是對來自應用層的指令和資料進行解釋，對各種文法賦予相應的含義，并按照一定的格式傳送給會話層。
其主要功能是處理使用者資訊的表示問題，如編碼、資料格式轉換和加密解密等。
表示層的具體功能如下：
資料格式處理
：協商和建立資料交換的格式，解決各應用程式之間在資料格式表示上的差異。
資料的編碼
：處理字元集和數字的轉換。
壓縮和解壓縮
：為了減少資料的傳輸量，這一層還負責資料的壓縮與解壓縮。
資料的加密和解密
：可以提高網絡的安全性。
3.
會話層
會話層是使用者應用程式和網絡之間的接口，主要任務是：
組織和協調兩個會話程序之間的通信
，并對資料交換進行管理。
當建立會話時，使用者必須提供他們想要連接配接的遠端位址。
4.
傳輸層
OSI上3層：
應用層、表示層、會話層
的主要任務是資料處理——資源子網
OSI下3層：
網絡層、資料鍊路層、實體層
的主要任務是資料通訊——通訊子網
傳輸層是OSI模型的第4層，它是通信子網和資源子網的接口和橋梁，起到承上啟下的作用
5.
網絡層
主要任務是：資料鍊路層的資料在這一層被轉換為，然後通過路徑
選擇、分段組合、順序、進/出路由
等控制，将資訊從一個網絡裝置傳送到另一個網絡裝置。
一般情況下，資料鍊路層是解決同一網絡(區域網路)内節點之間的通信，而網絡層主要解決不同子網間的通信。
6.
資料鍊路層
在計算機網絡中由于各種幹擾的存在，實體鍊路是不可靠的。是以，這一層的主要功能是:
在實體層提供的比特流的基礎上，
通過差錯控制、流量控制方法，使有差錯的實體線路變
為無差錯的資料鍊路，即向網絡層提供可靠的通過實體媒體傳輸資料的方法。
具體工作是：接收來自實體層的位流（比特流）形式的資料，通過差錯控制等方法傳到網絡層；同樣，也将來自上層的資料，封裝成 3 轉發到實體層；并且，還負責處理接收端發回的确認幀的資訊，以便提供可靠的資料傳輸。
幀：幀(frame)是資料鍊路層的傳輸單元。将上層傳入的資料添加一個頭部和尾部，組成了幀。
7.
實體層
主要功能是：利用傳輸媒體為資料鍊路層提供實體連接配接，實作比特流的透明傳輸。盡可能屏蔽掉具體傳輸媒體和實體裝置的差異。
小結
:
在7層模型中，每一層都提供一個特殊的網絡功能。
從網絡功能的角度觀察：
總結
-
HTTP特點
-
URL的作用
-
請求響應
- request: 請求行（
request line
header
- response: HTTP響應也由四個部分組成，分别是：
狀态行、消息報頭、空行和響應正文
-
三次握手&四次揮手
- 為什麼不使用兩次握手：無法防止曆史連接配接的建立，會造成資源浪費，不能同步雙方序列号
- 為什麼不使用四次握手：三次握手已經足夠，再多一次握手隻會造成更多的連接配接時延
-
OSI七層協定
- 原七層：實體層、資料鍊路層、網絡層、傳輸層、會話層、表示層、應用層.
- 簡化後：網絡接口層，網絡層，傳輸層，應用層.
- 傳輸層為界：上三層(應用層、表示層、會話層)資訊和資料處理,下三層(實體層、資料鍊路層、網絡層)資料傳輸交換.