#HTTP學(xué)習(xí)總結(jié)HTTP協(xié)議和TCP/IP協(xié)議作用相同促脉，都是用于客戶端和服務(wù)器之間的通信。在用于HTTP協(xié)議時，必然有一端擔(dān)任客戶端蓬网，另一端擔(dān)任服務(wù)器端角色。而且兩者的角色隨時可能互換------從一條通信線路來說鹉勒，服務(wù)端和客戶端的角色是確定的帆锋。和HTTP關(guān)系密切的協(xié)議：[TCP/IP](http://baike.baidu.com/link?url=6XiP08Nh9e6aRtRbI6jPMvx1Vn1wy9jYB5th2qj0EcgugRwnrdZaFEqE_viarropjOzbZ_WOV7A6QQzW8sal6YsLFID7ScDtrmSGcRyUpijvsq7qihRy0iSq_NIEKdy-q1SZASIck6jgzB9e0Jsyy_)和DNS:見下圖```sequence發(fā)送端->DNS端: 把它的IP地址告訴我吧 DNS端->發(fā)送端:它的地址是192.168.XXX.XXX發(fā)送端->服務(wù)器端:像192.168.XXX.XXX發(fā)送訪問請求```1. 首先客戶端想訪問http://www.xxx.com。2. 客戶端向NDS解析說：告訴我http://www.xxx.com的IP地址吧3. NDS告訴客戶端：http://www.xxx.com的IP地址是192.168.xxx.xxx4. 客戶端使用HTTP協(xié)議的職責(zé)贸弥，生成對服務(wù)器端的HTTP請求報文5. 客戶端使用TCP協(xié)議窟坐，將HTTP請求報文分割成報文段，按序號分為多個報文段，并且把每個報文段傳給對方6. 客戶端利用IP協(xié)議哲鸳，搜索到對方的地址臣疑，一遍中轉(zhuǎn)，一邊傳送7. 服務(wù)器端使用TCP協(xié)議徙菠，將從對方那里接收到的報文段以原來的順序重組請求報文8. 服務(wù)器端利用HTTP協(xié)議讯沈，對請求內(nèi)容進(jìn)行處理9. 然后處理的結(jié)果再用同樣的過程進(jìn)行回傳##HTTP中可使用的幾種方法：* **GET:獲取資源*** **POST：傳輸實體主體**GET方法也可以傳輸實體，但是一般不用GET方法進(jìn)行傳輸婿奔，而是用POST方法缺狠，雖然說POST與GET相似，但是POST主要目的不是為了獲取響應(yīng)的主體內(nèi)容萍摊。* **PUT傳輸文件**PUT方法用來傳輸文件挤茄，就像FTP協(xié)議的文件上傳一樣，要求在請求保溫的主體中包含文件內(nèi)容冰木，然后保存到請求URI指定的位置穷劈。* **HEAD:獲取報文首部**HEAD方法和GET方法一樣，只是不返回報文主體部分踊沸。用于確認(rèn)URI的有效性及資源更新的日期時間歇终。* **DELETE:刪除文件**DELETE方法用來刪除文件，是與PUT相反的方法逼龟。DELETE方法按請求URL刪除指定的資源评凝。* **OPTIONS：詢問支持的方法**OPTIONS方法用來查詢針對請求URI指定的資源支持的方法* **TRACE：追蹤路徑**TRACE方法是讓服務(wù)器端將之前的請求通信環(huán)回給客戶端的方法。* **CONNECT：要求用隧道協(xié)議連接代理**CONNECT方法要求在與代理服務(wù)器通信時建立隧道腺律，實現(xiàn)用隧道協(xié)議進(jìn)行TCP通信奕短。主要使用SSL和TLS協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸。| 方法? ? |? ? 說明 || :------- | --------:|| GET? ? ? | 獲取資源 || POST? ? | 傳輸實體主體 || PUT? ? ? | 傳輸文件 || HEAD? ? | 獲得報文首部 || DELETE? | 刪除文件 || OPTIONS? | 詢問支持的方法 || TRACE? | 追蹤路徑 || CONNECT? | TRACE || LINK? ? | 建立和資源之間的連接|| UNLINK? | 斷開連接關(guān)系 |###HTTP歷程HTTP協(xié)議的初始版本中疾渣，每進(jìn)行一次HTTP通信就要斷開一次TCP連接篡诽。這樣會造成無謂的TCP連接建立和斷開，增加通信量的開銷榴捡。后來為了解決上述問題杈女，想出了持久連接------只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態(tài)------而且持久連接使得多數(shù)請求以管線化方法成為可能吊圾。###使用cookie的狀態(tài)管理HTTP是無狀態(tài)協(xié)議达椰，它不對之前發(fā)生過的請求和響應(yīng)的狀態(tài)進(jìn)行管理。也就是說项乒，無法根據(jù)之前的狀態(tài)進(jìn)行本次的請求處理啰劲，而且讓客戶端管理全部客戶端狀態(tài)則會成為負(fù)擔(dān)。保留無狀態(tài)協(xié)議這個特征的同時又要解決類似的問題檀何，于是引入了cookie技術(shù)------通過在請求和響應(yīng)報文中寫入cookie信息來控制客戶端的狀態(tài)蝇裤。* 沒有cookie信息狀態(tài)下的請求```sequence客戶端->服務(wù)端: 請求Note right of 服務(wù)端: 生成cookie廷支，并記錄信息 服務(wù)端->客戶端: 在響應(yīng)中添加cookie后返回```* 第二次有cookie后請求```sequence客戶端->服務(wù)端: 請求中添加cookie方法Note right of 服務(wù)端: 檢查cookie服務(wù)端->客戶端: 響應(yīng)```HTTP請求報文和響應(yīng)報文的內(nèi)容如下：1. 請求報文（沒有cookie信息的狀態(tài)）```GET /reader/ HTTP/1.1Host: hackr.jp```2. 響應(yīng)報文（服務(wù)器生成cookie信息）```HTTP/1.1 200OKDate: Thu, 12 Jul 2012 07:12:20 GMTServer: Apache10-Oct-12 07:12:20 GMT>
Contect-Type: text/plain: charset:UTF-8
```
3. 請求報文（自動發(fā)送保存著的cookie信息）
```
GET /image/ HTTP/1.1
Host:hackr.jp
Cookie:aid=1342077140226724
```
###返回結(jié)果的HTTP狀態(tài)碼
|? 狀態(tài)碼? | 類別 |? ? 原因短語 |
| :------- |? ? ? |--------:|
| 1XX? ? ? | Informational(信息性狀態(tài)碼) | 接收的請求正在處理|
| 2XX? ? ? | Success（成功狀態(tài)碼）| 請求正常處理完畢 |
| 3XX? ? ? | Redirection（重定向狀態(tài)碼） | 需要進(jìn)行附加操作以完成請求 |
| 4XX? ? ? | Client Error（客戶端錯誤狀態(tài)碼）| 服務(wù)器無法處理請求 |
| 5XX? ? ? | Server Error（服務(wù)器錯誤狀態(tài)碼）| 服務(wù)器處理請求出錯 |
###HTTP首部
首部字段這里不做多描述，詳見[鏈接](http://www.cnblogs.com/kissdodog/archive/2013/04/01/2993228.html)
###與HTTP協(xié)作的服務(wù)器
* 用單個虛擬主機(jī)實現(xiàn)多個域名
* 通信數(shù)據(jù)轉(zhuǎn)發(fā)程序：代理栓辜、網(wǎng)關(guān)恋拍、隧道
* 代理
1. 代理服務(wù)器的功能是代理網(wǎng)絡(luò)用戶去取得網(wǎng)絡(luò)信息。主要功能是利用緩存技術(shù)保存在代理服務(wù)器上藕甩，當(dāng)代理再次接受到相同資源的請求時施敢，就可以不從源服務(wù)器哪里獲取資源，而是將之前緩存的資源作為響應(yīng)返回狭莱。
2. 代理在轉(zhuǎn)發(fā)請求或者響應(yīng)時僵娃，不對報文做任何加工的稱為透明代理。反之腋妙，對報文內(nèi)容進(jìn)行加工的代理被稱為非透明代理默怨。
* 網(wǎng)關(guān)
網(wǎng)關(guān)工作機(jī)制和代理相似。網(wǎng)關(guān)能使通信線路上的服務(wù)器提供非HTTP協(xié)議服務(wù)骤素。
```sequence
客戶端->網(wǎng)關(guān): HTTP請求
網(wǎng)關(guān)->非HTTP服務(wù)器: 非HTTP協(xié)議通信
非HTTP服務(wù)器->網(wǎng)關(guān):
網(wǎng)關(guān)->客戶端:HTTP響應(yīng)
```
* 隧道
隧道可按要求建立一條與其他服務(wù)器的通信線路先壕，屆時使用SSL等加密手段進(jìn)行通信。隧道的目的是確弊惶穑客戶端能與服務(wù)器進(jìn)行安全的通信。
###HTTP集绰、Socket规辱、TCP的區(qū)別轉(zhuǎn)自[編程小翁](http://www.cocoachina.com/ios/20160325/15773.html)
1. TCP鏈接與HTTP的區(qū)別
HTTP基于TCP，客戶端往服務(wù)器發(fā)送一個HTTP請求時第一步就是要建立與服務(wù)器的TCP鏈接栽燕，也就是先三次握手罕袋。一次TCP連接可以發(fā)送多次HTTP請求。
2. TCP連接與Socket連接的區(qū)別
socket層只是在TCP/UDP傳輸層上做的一個抽象接口層碍岔，因此一個socket連接可以基于TCP浴讯，也可能基于UDP“玻基于TCP協(xié)議的socket連接同樣需要通過三次握手建立連接榆纽，是可靠的；基于UDP協(xié)議的socket連接不需要建立連接的過程捏肢，不過對方能不能收到都會發(fā)送過去奈籽，是不可靠的，大多數(shù)的即時通訊IM都是后者鸵赫。
3. HTTP連接與socket連接的區(qū)別
* HTTP是短連接衣屏，socket（基于TCP）是長連接
* HTTP服務(wù)端無法主動發(fā)消息，socket連接雙反隨時可以向另一方喊話辩棒。
4. 什么時候該用HTTP狼忱，什么時候該用socket
* 用HTTP的情況：雙方不需要時刻保持連接在線膨疏，比如客戶端資源的獲取、文件上傳等钻弄。
