1无埃、HTTP與TCP關系
1.1 什么是HTTP協(xié)議
HTTP（Hypertext Transfer Protocol 烘嘱，超文本傳輸協(xié)議）是一個簡單的請求-響應協(xié)議萝快，它通常運行在TCP之上川蒙。
2贡翘、url
URL(Uniform Resource Locator) 地址用于描述一個網(wǎng)絡上的資源, 基本格式如下
schema://host[:port]/path/.../[?query-string][#anchor]
scheme： 指定低層使用的協(xié)議(例如：http, https, ftp)
host： HTTP服務器的IP地址或者域名
port： HTTP服務器的默認端口是80蹈矮，這種情況下端口號可以省略。如果使用了別的端口鸣驱，必須指明泛鸟，例如 http://www.cnblogs.com:8080/
path： 訪問資源的路徑
query-string： 發(fā)送給http服務器的數(shù)據(jù)
anchor： 錨
3、請求報文
先看Request 消息的結構, Request 消息分為3部分踊东，第一部分叫Request line, 第二部分叫Request header, 第三部分是body. header和body之間有個空行北滥， 結構如下圖
3.1 Request line
請求的第一行是“方法 URL 議 / 版本”： GET/sample.jsp HTTP/1.1
以上代碼中“ GET ”代表請求方法，“ /index.xml ”表示 URI 闸翅，“ HTTP/1.1 代表協(xié)議和協(xié)議的版本再芋。
根據(jù) HTTP 標準， HTTP 請求可以使用多種請求方法坚冀。例如： HTTP1.1 目前支持 7 種請求方法： GET 济赎、 POST 、 HEAD记某、 OPTIONS 司训、 PUT 、 DELETE 和 TARCE 液南。
GET: 請求獲取由Request-URI所標識的資源壳猜。
POST: 在Request-URI所標識的資源后附加新的數(shù)據(jù)。
HEAD: 請求獲取由Request-URI所標識的資源的響應消息報頭滑凉。
OPTIONS: 請求查詢服務器的性能统扳，或查詢與資源相關的選項和需求喘帚。
PUT: 請求服務器存儲一個資源，并用Request-URI作為其標識闪幽。
DELETE: 請求服務器刪除由Request-URI所標識的資源啥辨。
TRACE: 請求服務器回送收到的請求信息，主要用語測試或診斷盯腌。
3.1.1 GET和POST區(qū)別
- GET提交的數(shù)據(jù)會放在URL之后，以?分割URL和傳輸數(shù)據(jù)陨瘩，參數(shù)之間以&相連腕够，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數(shù)據(jù)放在HTTP包的Body中.
- GET提交的數(shù)據(jù)大小有限制（因為瀏覽器對URL的長度有限制），而POST方法提交的數(shù)據(jù)沒有限制.
- GET方式需要使用Request.QueryString來取得變量的值舌劳，而POST方式通過Request.Form來獲取變量的值帚湘。
- GET方式提交數(shù)據(jù)，會帶來安全問題甚淡，比如一個登錄頁面大诸，通過GET方式提交數(shù)據(jù)時，用戶名和密碼將出現(xiàn)在URL上贯卦，如果頁面可以被緩存或者其他人可以訪問這臺機器资柔，就可以從歷史記錄獲得該用戶的賬號和密碼.
3.2 Request header
下面列舉一些常用的request header：
| Header | 解釋 | 示例 |
|---|---|---|
| Accept | 指定客戶端能夠接收的內容類型 | Accept:text/plain,text/html |
| Accept-Charset | 瀏覽器可以接受的字符編碼集。 | Accept-Charset:iso-8859-5 |
| Accept-Encoding | 指定瀏覽器可以支持的web服務器返回內容壓縮編碼類型撵割。 | Accept-Encoding:compress,gzip |
| Accept-Language | 瀏覽器可接受的語言 | Accept-Language:en,zh |
| Accept-Ranges | 可以請求網(wǎng)頁實體的一個或者多個子范圍字段 | Accept-Ranges:bytes |
| Authorization | HTTP授權的授權證書 | Authorization:Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Cache-Control | 指定請求和響應遵循的緩存機制 | Cache-Control:no-cache |
| Connection | 表示是否需要持久連接贿堰。 | （HTTP 1.1默認進行持久連接） Connection:close |
| Cookie | HTTP請求發(fā)送時，會把保存在該請求域名下的所有cookie值一起發(fā)送給web服務器啡彬。 | Cookie:$Version=1;Skin=new; |
| Content-Length | 請求的內容長度 | Content-Length:348 |
| Content-Type | 請求的與實體對應的MIME信息 | Content-Type:application/x-www-form-urlencoded |
| Date | 請求發(fā)送的日期和時間 | Date:Tue,15 Nov 2010 08:12:31 GMT |
| Expect | 請求的特定的服務器行為 | Expect:100-continue |
| From | 發(fā)出請求的用戶的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代碼，參數(shù)為服務器先前發(fā)送的Etag庶灿，與服務器回應的Etag比較判斷是否改變 | If-None-Match:“737060cd8c284d8af7ad3082f209582d” |
| If-Range | 如果實體未改變纵搁，服務器發(fā)送客戶端丟失的部分，否則發(fā)送整個實體往踢。參數(shù)也為Etag | If-Range:“737060cd8c284d8af7ad3082f209582d” |
| If-Unmodified-Since | 只在實體在指定時間之后未被修改才請求成功 | If-Unmodified-Since:Sat,29 Oct 2010 19:43:31 GMT |
| Max-Forwards | 限制信息通過代理和網(wǎng)關傳送的時間 | Max-Forwards:10 |
| Pragma | 用來包含實現(xiàn)特定的指令 | Pragma:no-cache |
| Proxy-Authorization | 連接到代理的授權證書 | Proxy-Authorization:Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Range | 只請求實體的一部分腾誉，指定范圍 | Range:bytes=500-999 |
| Referer | 先前網(wǎng)頁的地址，當前請求網(wǎng)頁緊隨其后,即來路 | Referer:http: |
| TE | 客戶端愿意接受的傳輸編碼菲语，并通知服務器接受接受尾加頭信息 | TE:trailers,deflate;q=0.5 |
| Upgrade | 向服務器指定某種傳輸協(xié)議以便服務器進行轉換（如果支持） | Upgrade:HTTP/2.0,SHTTP/1.3,IRC/6.9,RTA/x11 |
| User-Agent | User-Agent的內容包含發(fā)出請求的用戶信息 | User-Agent:Mozilla/5.0(Linux;X11) |
| Via | 通知中間網(wǎng)關或代理服務器地址妄辩，通信協(xié)議 | Via:1.0 fred,1.1 nowhere.com(Apache/1.1) |
| Warning | 關于消息實體的警告信息 | Warn:199 Miscellaneous warning |
3.3 Request body
3.3.1 GET Request
當使用的是"GET" 方法的時候， body是為空的
3.3.2 POST Request
post的body通常是自己定義的山上，一般消息傳遞會用字符串眼耀，上傳傳文件直接用二進制也可以
4、響應
我們再看Response消息的結構, 和Request消息的結構基本一樣佩憾。 同樣也分為三部分,第一部分叫Response line, 第二部分叫Response header哮伟，第三部分是body. header和body之間也有個空行, 結構如下圖
4.1 狀態(tài)行
響應的第一行被稱為狀態(tài)行干花，內容包含3部分：
版本： 如 HTTP/1.1
狀態(tài)碼 如 200
狀態(tài)消息 一般是說明狀態(tài)碼的 200時為OK
4.1.1 狀態(tài)碼的類別：
| 狀態(tài)碼 | 類別 | 原因短語 |
|---|---|---|
| 1XX | Informational（信息性狀態(tài)碼） | 接受的請求正在處理 |
| 2XX | Success（成功狀態(tài)碼） | 請求正常處理完畢 |
| 3XX | Redirection（重定向狀態(tài)碼） | 需要進行附加操作以完成請求 |
| 4XX | Client Error（客戶端錯誤狀態(tài)碼） | 服務器無法處理請求 |
| 5XX | Server Error（服務器錯誤狀態(tài)碼） | 服務器處理請求出錯 |
4.1.2 常見的14中狀態(tài)碼
2XX——表明請求被正常處理了
1、200 OK：請求已正常處理楞黄。
2池凄、204 No Content：請求處理成功，但沒有任何資源可以返回給客戶端鬼廓，一般在只需要從客戶端往服務器發(fā)送信息肿仑，而對客戶端不需要發(fā)送新信息內容的情況下使用。
3碎税、206 Partial Content：是對資源某一部分的請求尤慰，該狀態(tài)碼表示客戶端進行了范圍請求，而服務器成功執(zhí)行了這部分的GET請求雷蹂。響應報文中包含由Content-Range指定范圍的實體內容伟端。
3XX——表明瀏覽器需要執(zhí)行某些特殊的處理以正確處理請求
4、301 Moved Permanently：資源的uri已更新匪煌，你也更新下你的書簽引用吧责蝠。永久性重定向，請求的資源已經(jīng)被分配了新的URI萎庭，以后應使用資源現(xiàn)在所指的URI霜医。
5、302 Found：資源的URI已臨時定位到其他位置了擎椰，姑且算你已經(jīng)知道了這個情況了支子。臨時性重定向。和301相似达舒，但302代表的資源不是永久性移動值朋，只是臨時性性質的。換句話說巩搏，已移動的資源對應的URI將來還有可能發(fā)生改變昨登。
6、303 See Other：資源的URI已更新贯底，你是否能臨時按新的URI訪問丰辣。該狀態(tài)碼表示由于請求對應的資源存在著另一個URL，應使用GET方法定向獲取請求的資源禽捆。303狀態(tài)碼和302狀態(tài)碼有著相同的功能笙什，但303狀態(tài)碼明確表示客戶端應當采用GET方法獲取資源，這點與302狀態(tài)碼有區(qū)別胚想。
當301,302,303響應狀態(tài)碼返回時琐凭，幾乎所有的瀏覽器都會把POST改成GET，并刪除請求報文內的主體浊服，之后請求會自動再次發(fā)送统屈。
7胚吁、304 Not Modified：資源已找到，但未符合條件請求愁憔。該狀態(tài)碼表示客戶端發(fā)送附帶條件的請求時（采用GET方法的請求報文中包含If-Match腕扶，If-Modified-Since，If-None-Match吨掌，If-Range半抱，If-Unmodified-Since中任一首部）服務端允許請求訪問資源，但因發(fā)生請求未滿足條件的情況后膜宋，直接返回304.代虾。
8、307 Temporary Redirect：臨時重定向激蹲。與302有相同的含義。
4XX——表明客戶端是發(fā)生錯誤的原因所在江掩。
9学辱、400 Bad Request：服務器端無法理解客戶端發(fā)送的請求，請求報文中可能存在語法錯誤环形。
10策泣、401 Unauthorized：該狀態(tài)碼表示發(fā)送的請求需要有通過HTTP認證（BASIC認證，DIGEST認證）的認證信息抬吟。
11萨咕、403 Forbidden：不允許訪問那個資源。該狀態(tài)碼表明對請求資源的訪問被服務器拒絕了火本。（權限危队，未授權IP等）
12、404 Not Found：服務器上沒有請求的資源钙畔。路徑錯誤等茫陆。
5XX——服務器本身發(fā)生錯誤
13、500 Internal Server Error：貌似內部資源出故障了擎析。該狀態(tài)碼表明服務器端在執(zhí)行請求時發(fā)生了錯誤簿盅。也有可能是web應用存在bug或某些臨時故障。
14揍魂、503 Service Unavailable：抱歉桨醋，我現(xiàn)在正在忙著。該狀態(tài)碼表明服務器暫時處于超負載或正在停機維護现斋，現(xiàn)在無法處理請求喜最。
4.2 Reponse Header
可以參考Request Header
4.3 Respons Body
body部分就是服務端向客戶端發(fā)送的實際數(shù)據(jù)，一般都是自己定義的數(shù)據(jù)格式和內容步责，當然一般都是采用通用的數(shù)據(jù)格式返顺，如傳消息一般用json禀苦，傳圖片和視頻用原本的封裝格式。
