(三)HTTP再邂逅--熟悉HTTP协议结构和通讯原理
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)容類型的標(biāo)識)加以標(biāo)記
無連接
 無連接的含義是限制每次連接只處理一個請求
 服務(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:一個緊湊的字符串用來標(biāo)示抽象或物理資源
 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是唯一標(biāo)識的一部分,是身份信息
 以上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值時,默認(rèn)權(quán)重q=1.0,當(dāng)服務(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 當(dāng)一個網(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)閉,當(dāng)客戶端再次發(fā)送Request,需要重新建立TCP連接
Host
 作用:請求報頭域主要用于指定被請求資源的Internet主機和端口號,它通常從HTTP URL中提取出來的
我們在瀏覽器中輸入:http://www.fljf.com:8080
瀏覽器發(fā)送的請求消息中,就會包含Host請求報文域,如下:
 Host: www.fljf.com:8080
Referer
 當(dāng)瀏覽器向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請求中,很容易就可以辨認(rèn)出表單提交的內(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請求的一部分,而且通過標(biāo)準(zhǔn)數(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所標(biāo)識的資源信息,所以我們的HEAD方法經(jīng)常用來測試我們超鏈接的有效性,去測試我們的鏈接能不能訪問以及最近是不是有更新,現(xiàn)在我們從網(wǎng)上下載的很多超鏈接探測工具,很多用的是HEAD方法去實現(xiàn)的
DELETE
 請求服務(wù)器刪除指定的資源
 與PUT相反的
 根據(jù)我們請求的URI去刪除資源,但是HTTP1.1里,和PUT方法一樣,不帶有驗證機制
OPTIONS
 用來查詢針對請求URI指定的資源支持的方法
 常用來不知道對方支持什么樣的方法,進行詢問下
 
 TRACE
 回顯服務(wù)器收到的請求,主要用于測試或診斷
 客戶端可以通過TRACE方法查詢發(fā)送出去的請求是到底怎么樣被加工修改或者被篡改,這是因為請求想要連接到原目標(biāo)服務(wù)器時,可能會通過代理中轉(zhuǎn),TRACE方法是用來確認(rèn)連接過程中發(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ù)器只負(fù)責(zé)傳輸彼此的數(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客戶端功能:控制面板 > 右上角查看方式改成小圖標(biāo) > 程序和功能 > 點擊啟用或關(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保存起來,當(dāng)瀏覽器再請求該網(wǎng)站時,瀏覽器把請求的網(wǎng)址連同該Cookie一同提交給服務(wù)器。服務(wù)器檢查該Cookie,以此來辨認(rèn)用戶狀態(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標(biāo)識發(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)容,希望文章能夠幫你解決所遇到的問題。
 
                            
                        - 上一篇: 光猫和无线路由器要怎么保养维护-路由器如
- 下一篇: 安装NVM、NRM
