HTTP再邂逅--熟悉HTTP協議結構和通訊原理

• HTTP協議特點
• URL和URI的區別和聯系
• HTTP報文結構分析
• HTTP請求方法剖析
• HTTP響應狀態碼拆解
• 用telnet分析http協議的通訊過程
• HTTP狀態管理：Cookie與Session（會話跟蹤技術）

HTTP協議特點

支持客戶/服務器模式
客戶/服務器模式工作的方式是由客戶端向服務器發出請求，服務器端響應請求，并進行相應服務

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

靈活
HTTP允許傳輸任意類型的數據對象
正在傳輸的類型由Content-Type（Content-Type是HTTP包中用來表示內容類型的標識）加以標記

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

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

URL和URI的區別和聯系

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

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

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報文結構分析

HTTP報文結構分析-請求報文

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

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

通用報文頭

請求報文頭

響應報文頭

實體報文頭
實體：請求里面一些報文相應信息

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

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

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

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

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

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

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

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

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

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

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

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

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

HTTP報文結構分析-響應報文

HTTP請求方法剖析

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

GET 獲取資源
GET方法用來請求訪問已被URI識別的資源
指定的資源經服務器端解析后返回響應內容

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

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

POST
POST方法與GET功能類似，一般用來傳輸實體的主體
POST方法的主要目的不是獲取響應主體的內容

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

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

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

PUT
從客戶端向服務器傳送的數據取代指定的文檔的內容
PUT方法與POST方法最大的不同是：PUT是冪等的，而POST是不冪等的
因此，我們更多時候將PUT方法用作傳輸資源

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

HEAD
類似于GET請求，只不過返回的響應中沒有具體的內容，用于獲取報頭

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

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

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

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

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

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

HTTP響應狀態碼拆解

是用以表示網頁服務器超文本傳輸協議響應狀態的3位數字代碼


常用HTTP狀態碼

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


4開頭狀態碼表示服務器接收到也處理完成了，但結果可能和你客戶端預想的不太一樣

5開頭狀態碼大多數我們發出的請求沒問題，只是服務器處理異常

用telnet分析http協議的通訊過程

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

Test 1

Test 2

Test 3

Test 4

Test 5

HTTP狀態管理：Cookie與Session（會話跟蹤技術）

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

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

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

Cookie工作原理

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

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

保存Session ID的方式

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

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

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

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

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

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。