基礎知識
任何瀏覽器輸入網址直到獲取到頁面整個過程都是與服務端進行通信（數據交互）的過程，涉及到通信必然就會有socket的參與，同時還有數據發送的規則的定制。
那么HTTP協議則是瀏覽器與服務端之間進行通信的一種規則，除了HTTP協議之外，還有HTTPS、WEBSOCKET等協議均是如此。
HTTP協議全稱為Hypertext Transport Protocol，即為超文本傳輸協議（不止可以發送文本，還有圖片，視頻等數據），它具有以下一些特點：
| 特點 | 描述 |
|---|---|
| 基於請求/響應 | 一次請求，對應一次響應 |
| 基於TCP/IP協議 | HTTP協議是應用層協議，基於TCP傳輸層協議以及IP網絡層協議 |
| 無連接特性 | 每次請求相應完成后，就斷開鏈接（注意，1.1版本后支持長鏈接） |
| 無狀態特性 | 每次的請求對服務器而言都是陌生的 |
| 此外，HTTP協議的端口號為80 |
請求協議
請求協議中包含請求頭，請求方式，請求體，三大部分。
請求格式
每次的請求都會依照下面的格式進行數據的組織。
請求首行； // 請求方式 請求路徑 協議和版本，例如：GET /index.html HTTP/1.1
請求頭信息；// 請求頭名稱:請求頭內容，即為key:value格式，例如：Host:localhost
空行； // 用來與請求體分隔開
請求體。 // GET沒有請求體，只有POST有請求體。
GET請求
GET請求是HTTP協議中眾多請求方式的一種，也是HTTP協議默認的請求方式，它具有如下特征：
1.沒有請求體
2.數據必須控制再1KB之內
3.請求數據會暴露在地址欄中（
?之后，以&進行分割）
以下行為會導致GET請求
1.地址欄直接輸入網址
2.點擊頁面
<a>標簽進行鏈接跳轉3.
<form>表單默認提交方式method屬性為GET，也可以指定為POST
以下示例將展示GET請求特性
<body>
<form action="http://127.0.0.1:8000" method="GET">
<p><input type="text" name="username" placeholder="please enter user name"></p>
<p><input type="password" name="password" placeholder="please enter user password"></p>
<p><button type="submit">commit</button></p>
</form>
</body>
POST請求
POST請求最大的優勢就是不在地址欄暴露數據，此外它還有更多的特點
1.數據不會出現在地址欄中
2.數據的大小沒有上限
3.有請求體
4.請求體中如果存在中文，將使用URL進行編碼
我們都知道Http協議中參數的傳輸是"key=value"這種簡直對形式的，如果要傳多個參數就需要用“&”符號對鍵值對進行分割。 如"?name1=value1&name2=value2"，這樣在服務端在收到這種字符串的時候，會用“&”分割出每一個參數，然后再用“=”來分割出參數值。 針對“name1=value1&name2=value2”我們來說一下客戶端到服務端的概念上解析過程: 上述字符串在計算機中用ASCII碼表示為： 6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532。 6E616D6531：name1 3D：= 76616C756531：value1 26：& 6E616D6532：name2 3D：= 76616C756532：value2 服務端在接收到該數據后就可以遍歷該字節流，首先一個字節一個字節的吃，當吃到3D這字節后，服務端就知道前面吃得字節表示一個key，再想后吃，如果遇到26，說明從剛才吃的3D到26子節之間的是上一個key的value，以此類推就可以解析出客戶端傳過來的參數。 現在有這樣一個問題，如果我的參數值中就包含=或&這種特殊字符的時候該怎么辦。 比如說“name1=value1”,其中value1的值是“va&lu=e1”字符串，那么實際在傳輸過程中就會變成這樣“name1=va&lu=e1”。我們的本意是就只有一個鍵值對，但是服務端會解析成兩個鍵值對，這樣就產生了奇異。 如何解決上述問題帶來的歧義呢？解決的辦法就是對參數進行URL編碼 URL編碼只是簡單的在特殊字符的各個字節前加上%，例如，我們對上述會產生奇異的字符進行URL編碼后結果：“name1=va%26lu%3D”，這樣服務端會把緊跟在“%”后的字節當成普通的字節，就是不會把它當成各個參數或鍵值對的分隔符。
修改提交方式為POST
<body>
<form action="http://127.0.0.1:8000" method="POST">
<p><input type="text" name="username" placeholder="please enter user name"></p>
<p><input type="password" name="password" placeholder="please enter user password"></p>
<p><button type="submit">commit</button></p>
</form>
</body>
頭部報文
使用Chorme可快速查看請求頭部的報文信息
| 解釋 | 示例 | |
|---|---|---|
| Accept | 指定客戶端能夠接收的內容類型 | Accept: text/plain, text/html,application/json |
| Accept-Charset | 瀏覽器可以接受的字符編碼集。 | Accept-Charset: iso-8859-5 |
| Accept-Encoding | 指定瀏覽器可以支持的web服務器返回內容壓縮編碼類型。 | Accept-Encoding: compress, gzip |
| Accept-Language | 瀏覽器可接受的語言 | Accept-Language: en,zh |
| Accept-Ranges | 可以請求網頁實體的一個或者多個子范圍字段 | Accept-Ranges: bytes |
| Authorization | HTTP授權的授權證書 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Cache-Control | 指定請求和響應遵循的緩存機制 | Cache-Control: no-cache |
| Connection | 表示是否需要持久連接。（HTTP 1.1默認進行持久連接，即長連接，而1.0版本則不支持） | Connection: close |
| Cookie | HTTP請求發送時，會把保存在該請求域名下的所有cookie值一起發送給web服務器。 | Cookie: $Version=1; Skin=new; |
| Content-Length | 請求的內容長度 | Content-Length: 348 |
| Content-Type | 請求的與實體對應的MIME信息 | Content-Type: application/x-www-form-urlencoded |
| Date | 請求發送的日期和時間 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| Expect | 請求的特定的服務器行為 | Expect: 100-continue |
| From | 發出請求的用戶的Email | From: user@email.com |
| Host | 指定請求的服務器的域名和端口號 | Host: www.zcmhi.com |
| If-Match | 只有請求內容與實體相匹配才有效 | If-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Modified-Since | 如果請求的部分在指定時間之后被修改則請求成功，未被修改則返回304代碼 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| If-None-Match | 如果內容未改變返回304代碼，參數為服務器先前發送的Etag，與服務器回應的Etag比較判斷是否改變 | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Range | 如果實體未改變，服務器發送客戶端丟失的部分，否則發送整個實體。參數也為Etag | If-Range: “737060cd8c284d8af7ad3082f209582d” |
| If-Unmodified-Since | 只在實體在指定時間之后未被修改才請求成功 | If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| Max-Forwards | 限制信息通過代理和網關傳送的時間 | Max-Forwards: 10 |
| Pragma | 用來包含實現特定的指令 | Pragma: no-cache |
| Proxy-Authorization | 連接到代理的授權證書 | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Range | 只請求實體的一部分，指定范圍 | Range: bytes=500-999 |
| Referer | 先前網頁的地址，當前請求網頁緊隨其后就來。（POST獨有） | Referer: http://www.zcmhi.com/archives... |
| TE | 客戶端願意接受的傳輸編碼，並通知服務器接受接受尾加頭信息 | TE: trailers,deflate;q=0.5 |
| Upgrade | 向服務器指定某種傳輸協議以便服務器進行轉換（如果支持） | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| User-Agent | User-Agent的內容包含發出請求的用戶信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
| Via | 通知中間網關或代理服務器地址，通信協議 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 關於消息實體的警告信息 | Warn: 199 Miscellaneous warning |
Referer請求頭是比較有用的一個請求頭，它可以用來做統計工作，也可以用來做防盜鏈。 統計工作：我公司網站在百度上做了廣告，但不知道在百度上做廣告對我們網站的訪問量是否有影響，那么可以對每個請求中的Referer進行分析，如果Referer為百度的很多，那么說明用戶都是通過百度找到我們公司網站的。 防盜鏈：我公司網站上有一個下載鏈接，而其他網站盜鏈了這個地址，例如在我網站上的index.html頁面中有一個鏈接，點擊即可下載JDK7.0，但有某個人的微博中盜鏈了這個資源，它也有一個鏈接指向我們網站的JDK7.0，也就是說登錄它的微博，點擊鏈接就可以從我網站上下載JDK7.0，這導致我們網站的廣告沒有看，但下載的卻是我網站的資源。這時可以使用Referer進行防盜鏈，在資源被下載之前，我們對Referer進行判斷，如果請求來自本網站，那么允許下載，如果非本網站，先跳轉到本網站看廣告，然后再允許下載
響應協議
響應協議包含響應頭和響應體兩部分。
響應格式
響應首行；
響應頭信息；
空行；
響應體。
響應內容是由服務器發送給瀏覽器的內容，瀏覽器會根據響應內容來顯示。遇到<img src=''>會開一個新的線程加載，所以有時圖片多的話，內容會先顯示出來，然后圖片才一張張加載出來。
以下示例將展示使用Python快速的建立一個響應格式
conn.sendall(bytes("HTTP/1.1 201 OK \r\n\r\n","utf8")) # 響應頭
conn.sendall(bytes("<h1>Hello,World!</h1>","utf8")) # 響應體
狀態碼
響應頭對瀏覽器來說很重要，它說明了響應的真正含義。例如200表示響應成功了，302表示重定向，這說明瀏覽器需要再發一個新的請求。
- 200：請求成功，瀏覽器會把響應體內容（通常是html）顯示在瀏覽器中；
- 404：請求的資源沒有找到，說明客戶端錯誤的請求了不存在的資源；
- 500：請求資源找到了，但服務器內部出現了錯誤；
- 302：重定向，當響應碼為302時，表示服務器要求瀏覽器重新再發一個請求，服務器會發送一個響應頭Location，它指定了新請求的URL地址；
- 304：瀏覽器會先檢查緩存中的內容，如果於服務端中的內容相同則優先使用緩存中的內容；
當用戶第一次請求index.html時，服務器會添加一個名為Last-Modified響應頭，這個頭說明了index.html的最后修改時間，瀏覽器會把index.html內容，以及最后響應時間緩存下來。 當用戶第二次請求index.html時，在請求中包含一個名為If-Modified-Since請求頭，它的值就是第一次請求時服務器通過Last-Modified響應頭發送給瀏覽器的值，即index.html最后的修改時間，If-Modified-Since請求頭就是在告訴服務器，我這里瀏覽器緩存的index.html最后修改時間是這個,您看看現在的index.html最后修改時間是不是這個，如果還是，那么您就不用再響應這個index.html內容了，我會把緩存的內容直接顯示出來。 而服務器端會獲取If-Modified-Since值，與index.html的當前最后修改時間比對，如果相同，服務器會發響應碼304，表示index.html與瀏覽器上次緩存的相同，無需再次發送，瀏覽器可以顯示自己的緩存頁面，如果比對不同，那么說明index.html已經做了修 改，服務器會響應200。
頭部報文
使用Chorme可快速查看響應頭部的報文信息
| Header | 解釋 | 示例 |
|---|---|---|
| Accept-Ranges | 表明服務器是否支持指定范圍請求及哪種類型的分段請求 | Accept-Ranges: bytes |
| Age | 從原始服務器到代理緩存形成的估算時間（以秒計，非負） | Age: 12 |
| Allow | 對某網絡資源的有效的請求行為，不允許則返回405 | Allow: GET, HEAD |
| Cache-Control | 告訴所有的緩存機制是否可以緩存及哪種類型 | Cache-Control: no-cache |
| Content-Encoding | web服務器支持的返回內容壓縮編碼類型。 | Content-Encoding: gzip |
| Content-Language | 響應體的語言 | Content-Language: en,zh |
| Content-Length | 響應體的長度 | Content-Length: 348 |
| Content-Location | 請求資源可替代的備用的另一地址 | Content-Location: /index.htm |
| Content-MD5 | 返回資源的MD5校驗值 | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
| Content-Range | 在整個返回體中本部分的字節位置 | Content-Range: bytes 21010-47021/47022 |
| Content-Type | 返回內容的MIME類型 | Content-Type: text/html; charset=utf-8 |
| Date | 原始服務器消息發出的時間 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| ETag | 請求變量的實體標簽的當前值 | ETag: “737060cd8c284d8af7ad3082f209582d” |
| Expires | 響應過期的日期和時間 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
| Last-Modified | 請求資源的最后修改時間 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
| Location | 用來重定向接收方到非請求URL的位置來完成請求或標識新的資源 | Location: http://www.zcmhi.com/archives/94.html |
| Pragma | 包括實現特定的指令，它可應用到響應鏈上的任何接收方 | Pragma: no-cache |
| Proxy-Authenticate | 它指出認證方案和可應用到代理的該URL上的參數 | Proxy-Authenticate: Basic |
| refresh | 應用於重定向或一個新的資源被創造，在5秒之后重定向（由網景提出，被大部分瀏覽器支持） | Refresh: 5; url=http://www.zcmhi.com/archives/94.html |
| Retry-After | 如果實體暫時不可取，通知客戶端在指定時間之后再次嘗試 | Retry-After: 120 |
| Server | web服務器軟件名稱 | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) |
| Set-Cookie | 設置Http Cookie | Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 |
| Trailer | 指出頭域在分塊傳輸編碼的尾部存在 | Trailer: Max-Forwards |
| Transfer-Encoding | 文件傳輸編碼 | Transfer-Encoding:chunked |
| Vary | 告訴下游代理是使用緩存響應還是從原始服務器請求 | Vary: * |
| Via | 告知代理客戶端響應是通過哪里發送的 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 警告實體可能存在的問題 | Warning: 199 Miscellaneous warning |
| WWW-Authenticate | 表明客戶端請求實體應該使用的授權方案 | WWW-Authenticate: Basic |