HTTP再邂逅--熟悉HTTP協(xié)議結(jié)構(gòu)和通訊原理

• HTTP協(xié)議特點
• URL和URI的區(qū)別和聯(lián)系
• HTTP報文結(jié)構(gòu)分析
• HTTP請求方法剖析
• HTTP響應(yīng)狀態(tài)碼拆解
• 用telnet分析http協(xié)議的通訊過程
• HTTP狀態(tài)管理：Cookie與Session（會話跟蹤技術(shù)）

HTTP協(xié)議特點

支持客戶/服務(wù)器模式
客戶/服務(wù)器模式工作的方式是由客戶端向服務(wù)器發(fā)出請求，服務(wù)器端響應(yīng)請求，并進行相應(yīng)服務(wù)

簡單快速
客戶向服務(wù)器請求服務(wù)時，只需傳送請求方法和路徑
請求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同
由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快

靈活
HTTP允許傳輸任意類型的數(shù)據(jù)對象
正在傳輸?shù)念愋陀蒀ontent-Type（Content-Type是HTTP包中用來表示內(nèi)容類型的標識）加以標記

無連接
無連接的含義是限制每次連接只處理一個請求
服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接
采用這種方式可以節(jié)省傳輸時間

無狀態(tài)
HTTP協(xié)議是無狀態(tài)協(xié)議
無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大
另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快

URL和URI的區(qū)別和聯(lián)系

Q：我們輸入在瀏覽器里的Web地址應(yīng)該叫URL還是URI?
小A：我們訪問的就是URL!
小B：不！其實那是URI好不好！

URI：一個緊湊的字符串用來標示抽象或物理資源
A URI可以進一步被分為定位符、名字或者兩者都是
術(shù)語“Uniform Resource Locator”（URL）是URI的子集，除了確定一個資源，還提供一種定位該資源的主要訪問機制（如其網(wǎng)絡(luò)“位置”）

URI可以分為URL,URN或同時具備locators和names特性的一個東西
URN作用就好像一個人的名字，URL就像一個人的地址
換句話說：URN確定了東西的身份，URL提供了找到它的方式

URL是URI的一種，但不是所有的URI都是URL
URI和URL最大的差別是"訪問機制"
URN是唯一標識的一部分，是身份信息

以上tel:+1-816-555-1212是URI，最后一個是URN，其余都是URL，有訪問機制，有protocol

HTTP報文結(jié)構(gòu)分析

HTTP報文結(jié)構(gòu)分析-請求報文

HTTP報文頭
HTTP的報文頭大體可以分為四類，分別是：
通用報文頭、請求報文頭、響應(yīng)報文頭和實體報文頭

在HTTP/1.1里一共規(guī)范了47種報文頭字段

通用報文頭

請求報文頭

響應(yīng)報文頭

實體報文頭
實體：請求里面一些報文相應(yīng)信息

ACCEPT
作用：瀏覽器端可以接受的媒體類型
Accept：text/html 代表瀏覽器可以接受服務(wù)器回發(fā)的類型為text/html，也就是我們常說的html文檔，如果服務(wù)器無法返回text/html類型的數(shù)據(jù)，服務(wù)器應(yīng)該返回一個406錯誤（Non Acceptable）
Accept：/ 代表瀏覽器可以處理所有類型
如果想要給顯示的媒體類型增加優(yōu)先級，則使用q=來額外表示權(quán)重值，重值q的范圍是0-1（可精確到小數(shù)點后3位），且1為最大值。不指定權(quán)重q值時，默認權(quán)重q=1.0，當服務(wù)器提供多種內(nèi)容時，將會首先返回權(quán)重值更高的媒體類型

ACCEPT-Encoding
作用：瀏覽器申明自己接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什么壓縮方法（gzip，deflate）
ACCEPT-Encoding:gzip,deflate

ACCEPT-Language
作用：瀏覽器申明自己接收的語言

ACCEPT-Language:zh-cn,zh;q=0.7,en-us,en;q=0.3

客戶端在服務(wù)器有中文版資源的情況下，會請求其返回中文版對應(yīng)的響應(yīng)，沒有中文版時，則請求返回英文版響應(yīng)

Connection
Connection:keep-alive 當一個網(wǎng)頁打開完成后，客戶端和服務(wù)端之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉，如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁，會繼續(xù)使用這一條已經(jīng)建立的連接

Connection:close 代表一個Request完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接會關(guān)閉，當客戶端再次發(fā)送Request，需要重新建立TCP連接

Host
作用：請求報頭域主要用于指定被請求資源的Internet主機和端口號，它通常從HTTP URL中提取出來的

我們在瀏覽器中輸入：http://www.fljf.com:8080

瀏覽器發(fā)送的請求消息中，就會包含Host請求報文域，如下：
Host: www.fljf.com:8080

Referer
當瀏覽器向web服務(wù)器發(fā)送請求的時候，一般會帶上Referer，告訴服務(wù)器我是從哪個頁面鏈接過來的，服務(wù)器借此可以獲得一些信息用于處理

User-Agent
作用：告訴HTTP服務(wù)器，客戶端使用的操作系統(tǒng)和瀏覽器的名稱和版本
很多情況下我們會通過User-Agent來判斷瀏覽器類型，從而進行不同的兼容設(shè)計

Content-Type
作用：說明了報文體內(nèi)對象的媒體類型
application/xhtml+xml：XHTML格式
application/xml：XML數(shù)據(jù)格式
application/atom+xml：Atom XML聚合格式
application/json：JSON數(shù)據(jù)格式
application/pdf：pdf格式
application/msword：Word文檔格式
application/octet-stream：二進制流數(shù)據(jù)（如常見的文件下載）
application/x-www-form-urlencoded：表單提交

HTTP報文結(jié)構(gòu)分析-響應(yīng)報文

HTTP請求方法剖析

HTTP/1.1 常用方法
GET
POST
PUT
HEAD
DELETE
OPTIONS
TRACE
CONNECT

GET 獲取資源
GET方法用來請求訪問已被URI識別的資源
指定的資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容

GET
GET方法也可以用來提交表單和其他數(shù)據(jù)
http://localhost/login.php?username=aa$password=1234
從上面的URL請求中，很容易就可以辨認出表單提交的內(nèi)容
同時，瀏覽器對于提交URL的長度也有所限制

url提交的數(shù)據(jù)是作為我們GET請求的一部分，所以提交的數(shù)據(jù)量不能特別大，瀏覽器對url長度有限制，ie是2803，firefox是65536，chrome是8182

POST
POST方法與GET功能類似，一般用來傳輸實體的主體
POST方法的主要目的不是獲取響應(yīng)主體的內(nèi)容

請求頭和請求主體中間要加一行換行，空一行下面就是我們表單提交的數(shù)據(jù)

克服了GET缺點，通過POST數(shù)據(jù)時，數(shù)據(jù)不是作為url請求的一部分，而且通過標準數(shù)據(jù)傳送給WEB服務(wù)器，這就克服了GET方法數(shù)據(jù)無法保密，數(shù)據(jù)信息量太小的缺點

GET是通過url提交數(shù)據(jù)，數(shù)據(jù)可以在url上看到，POST數(shù)據(jù)是放在HTTP包的body里面；GET有大小限制，POST沒有；安全性方面，GET使用的參數(shù)會顯示在地址欄上，而POST不會

PUT
從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容
PUT方法與POST方法最大的不同是：PUT是冪等的，而POST是不冪等的
因此，我們更多時候?qū)UT方法用作傳輸資源

冪等就是不管進行多少次的重復(fù)操作，都是實現(xiàn)相同的結(jié)果
所以一般來說創(chuàng)建用POST,更新用PUT
但是鑒于HTTP1.1，它的PUT方法自身不帶有驗證機制，其實是存在一定的安全性問題的
所以后端邏輯里面POST也可以處理成更新

HEAD
類似于GET請求，只不過返回的響應(yīng)中沒有具體的內(nèi)容，用于獲取報頭

HEAD方法和GET方法幾乎是相同的，它們的區(qū)別在于HEAD方法只是請求消息的報文頭而不是完整的內(nèi)容，而對于HEAD請求的回應(yīng)部分來說，它的HTTP頭部信息中包含的信息與通過GET請求得到的信息是相同的，所以利用這個方法，我們就不必要去傳輸整個的資源內(nèi)容就可以得到我們想要請求的那個RequestUri所標識的資源信息，所以我們的HEAD方法經(jīng)常用來測試我們超鏈接的有效性，去測試我們的鏈接能不能訪問以及最近是不是有更新，現(xiàn)在我們從網(wǎng)上下載的很多超鏈接探測工具，很多用的是HEAD方法去實現(xiàn)的

DELETE
請求服務(wù)器刪除指定的資源
與PUT相反的
根據(jù)我們請求的URI去刪除資源，但是HTTP1.1里，和PUT方法一樣，不帶有驗證機制

OPTIONS
用來查詢針對請求URI指定的資源支持的方法
常用來不知道對方支持什么樣的方法，進行詢問下

TRACE
回顯服務(wù)器收到的請求，主要用于測試或診斷
客戶端可以通過TRACE方法查詢發(fā)送出去的請求是到底怎么樣被加工修改或者被篡改，這是因為請求想要連接到原目標服務(wù)器時，可能會通過代理中轉(zhuǎn)，TRACE方法是用來確認連接過程中發(fā)生的一系列操作，看看中轉(zhuǎn)的過程，但是TRACE方法特別容易引發(fā)一種跨站追蹤攻擊

CONNECT
開啟一個客戶端與所請求資源之間的雙向溝通的通道，它可以用來創(chuàng)建隧道

HTTP代理時，我們在使用代理服務(wù)器訪問互聯(lián)網(wǎng)時就是使用CONNECT方法，具體來說，我們要通過HTTP代理來訪問FaceBook，首先瀏覽器向代理服務(wù)器發(fā)送一個CONNECT請求，代理服務(wù)器返回HTTP 200，連接已經(jīng)建立了，之后瀏覽器和服務(wù)器就開始握手并交換數(shù)據(jù)，代理服務(wù)器只負責傳輸彼此的數(shù)據(jù)包，不能讀取具體的數(shù)據(jù)內(nèi)容，不管HTTPS還是HTTP都一樣

HTTP響應(yīng)狀態(tài)碼拆解

是用以表示網(wǎng)頁服務(wù)器超文本傳輸協(xié)議響應(yīng)狀態(tài)的3位數(shù)字代碼


常用HTTP狀態(tài)碼

206客戶端只想向服務(wù)器請求部分資源的時候，所以會加上range的消息頭來表明我要請求哪份
應(yīng)用場景：資源下載一半沒下載完，下次下載的時候從上次下載的地方開始下載，這叫斷點續(xù)傳


4開頭狀態(tài)碼表示服務(wù)器接收到也處理完成了，但結(jié)果可能和你客戶端預(yù)想的不太一樣

5開頭狀態(tài)碼大多數(shù)我們發(fā)出的請求沒問題，只是服務(wù)器處理異常

用telnet分析http協(xié)議的通訊過程

開啟telnet客戶端功能：控制面板 > 右上角查看方式改成小圖標 > 程序和功能 > 點擊啟用或關(guān)閉windows功能
windows+R調(diào)出命令行工具，輸入telnet

Test 1

Test 2

Test 3

Test 4

Test 5

HTTP狀態(tài)管理：Cookie與Session（會話跟蹤技術(shù)）

Cookie
Cookie實際上是一小段的文本信息，客戶端請求服務(wù)器，如果服務(wù)器需要記錄該用戶狀態(tài)，就向客戶端瀏覽器頒發(fā)一個Cookie

客戶端瀏覽器會把Cookie保存起來，當瀏覽器再請求該網(wǎng)站時，瀏覽器把請求的網(wǎng)址連同該Cookie一同提交給服務(wù)器。服務(wù)器檢查該Cookie，以此來辨認用戶狀態(tài)，服務(wù)器還可以根據(jù)自己的需要修改cookie的內(nèi)容

瀏覽器輸入訪問地址，瀏覽器會向服務(wù)器發(fā)送一個讀取網(wǎng)頁的請求并且把這個結(jié)果在顯示器上顯示，在發(fā)送之前，這個網(wǎng)頁在你的電腦尋找Cookie文件，如果找到瀏覽器會將Cookie里的數(shù)據(jù)連同前面說的url一同發(fā)送給服務(wù)器，服務(wù)器收到Cookie數(shù)據(jù)就會在數(shù)據(jù)庫中檢索你的id，你的購物信息，記錄，個人愛好等等，并且記錄下這次新的內(nèi)容，增加到數(shù)據(jù)庫和Cookie文件里面去，如果沒有檢測到Cookie信息，或者Cookie信息和數(shù)據(jù)庫里的不符合，那說明是第一次瀏覽這個網(wǎng)站，服務(wù)器就會創(chuàng)建一個新的id，并保存到數(shù)據(jù)庫里，并給你發(fā)一個Cookie

Cookie工作原理

Session
Session是另一種記錄客戶狀態(tài)的機制，保存在服務(wù)器上，客戶端瀏覽器訪問服務(wù)器的時候，服務(wù)器把客戶端信息以某種形式記錄在服務(wù)器上
客戶端瀏覽器再次訪問時只需要從該Session中查找該客戶的狀態(tài)就可以了

Session工作原理
客戶端保存SessionID的正是我們的Cookie，這樣交互過程中瀏覽器就可以自動地按照規(guī)則把SessionID標識發(fā)送給服務(wù)器

保存Session ID的方式

• Cookie
  通過Cookie保存SessionID是最常用的，但是可以人為的可以把Cookie給禁止掉，如果Cookie被禁止，就不能保存SessionID,可以考慮使用URL重寫與隱藏表單

• URL重寫
  http://…/xxx;Sessionid=Session ID
  http://…/xxx?Sessionid=Session ID

• 隱藏表單
  服務(wù)器會自動修改表單，添加隱藏的字段，以便表單提交時能把SessionID傳遞給服務(wù)器上

Session的有效期
Session超時失效：Cookie有效時間一般特別久，Session會有越來越多的用戶來訪問服務(wù)器，Session越來越多，為了防止內(nèi)存溢出，服務(wù)器就會把長時間沒有活躍的Session從內(nèi)存里刪掉，這個時間就是Session超時時間，如果超過這個時間沒有訪問服務(wù)器，Session就會自動失效

程序調(diào)用HttpSession.invalidate()：主動失效，退出注銷調(diào)用HttpSession.invalidate()

服務(wù)器進程被停止：服務(wù)器一般把緩存放在內(nèi)存里，一旦服務(wù)器異常終止，Session也會失效

Cookie與Session
存放位置不同：Cookie存在客戶端，Session存在服務(wù)端
安全性（隱私策略）的不同：Cookie在客戶端，對客戶端是可見的，有可能會被修改
有效期上的不同：Cookie可以設(shè)置很久，Session需要定期清理來進行減壓，Cookie對SessionID默許是-1，所以只要關(guān)閉瀏覽器，就是一次會話結(jié)束，這個Session就失效了
對服務(wù)器壓力的不同：Session對服務(wù)器壓力大

總結(jié)

以上是生活随笔為你收集整理的（三）HTTP再邂逅--熟悉HTTP协议结构和通讯原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。