- 相關(guān)推薦
HTTP會(huì )話(huà)原理解釋與應用
導語(yǔ)：通過(guò)會(huì )話(huà)管理能夠對會(huì )話(huà)進(jìn)行創(chuàng )建、信息存儲、關(guān)閉。下面就由小編為大家介紹一下HTTP會(huì )話(huà)原理解釋與應用，歡迎大家閱讀！
一、什么是會(huì )話(huà)
首先解釋一下什么是會(huì )話(huà)。在計算機術(shù)語(yǔ)中，會(huì )話(huà)是指一個(gè)終端用戶(hù)與交互系統進(jìn)行通訊的過(guò)程，比如從輸入賬戶(hù)密碼進(jìn)入操作系統到退出操作系統就是一個(gè)會(huì )話(huà)過(guò)程。會(huì )話(huà)較多用于網(wǎng)絡(luò )上，TCP的三次握手就創(chuàng )建了一個(gè)會(huì )話(huà)，TCP關(guān)閉連接就是關(guān)閉會(huì )話(huà)。用平述的語(yǔ)言可以解釋為：你拔打你女友的電話(huà)號碼，你女友接聽(tīng)，然后一翻“親愛(ài)的”，直到任何一方掛掉電話(huà)，這個(gè)過(guò)程就是一個(gè)會(huì )話(huà)。你挑逗一只小狗，它跟你互動(dòng)，也是會(huì )話(huà);它不鳥(niǎo)你，那就不形成會(huì )話(huà)。
二、什么是HTTP會(huì )話(huà)
協(xié)議的狀態(tài)是指下一次傳輸可以“記住”這次傳輸信息的能力，HTTP是不會(huì )為了下一次連接而維護這次連接所傳輸的信息的。從傳統WEB上看：無(wú)狀態(tài)是指，當瀏覽器發(fā)送請求給服務(wù)器的時(shí)候，服務(wù)器響應，但是同一個(gè)瀏覽器再發(fā)送請求給服務(wù)器的時(shí)候，他會(huì )響應，但是他不知道你就是剛才那個(gè)瀏覽器，簡(jiǎn)單地說(shuō)，就是服務(wù)器不會(huì )去記得你，所以是無(wú)狀態(tài)協(xié)議。本質(zhì)是：HTTP1.0是短連接的(這里先忽略HTTP1.1的keep alive吧)，請求響應后，斷開(kāi)了TCP連接，下一次連接與上一次無(wú)關(guān)。為了識別不同的請求是否來(lái)自同一客戶(hù)，引用HTTP會(huì )話(huà)機制，即：多次HTTP連接間維護用戶(hù)與同一用戶(hù)發(fā)出的不同請求之間關(guān)聯(lián)的情況稱(chēng)為維護一個(gè)會(huì )話(huà)(session)。通過(guò)會(huì )話(huà)管理對會(huì )話(huà)進(jìn)行創(chuàng )建、信息存儲、關(guān)閉等。
三、HTTP會(huì )話(huà)的實(shí)現機制
Cookie與session是各種教材，網(wǎng)上文章所介紹到的與HTTP會(huì )話(huà)相關(guān)的兩個(gè)內容。這種者較常見(jiàn)的解釋是：cookie存在在瀏覽器，session存儲在服務(wù)器中。這種解釋是最顯淺的，很不嚴謹，但又不能說(shuō)是錯誤。先從cookie談起吧，很久很久以前，為了完成HTTP會(huì )話(huà)，那些互聯(lián)網(wǎng)的設計者們想到了一個(gè)辦法，就是在瀏覽器中存儲用戶(hù)信息，每次請求都向服務(wù)端發(fā)送這些信息，這樣服務(wù)端就知道請求發(fā)送者是誰(shuí)了，就知道應該返回什么信息給客戶(hù)了。但是問(wèn)題很快就出現了，張三冒充李四的名字發(fā)送請求給服務(wù)器，服務(wù)器把李四的相關(guān)信息發(fā)給了張三。為了安全起見(jiàn)，互聯(lián)網(wǎng)老大哥們又想到了一招識別用戶(hù)身份的辦法，就是把客戶(hù)信息存儲在服務(wù)端(session)，一切用戶(hù)的身份由服務(wù)器指定。直到目前，session已成功HTTP會(huì )話(huà)的主流，應該說(shuō)是絕對控制的地位。
Session是怎樣做到會(huì )話(huà)身份識別的呢?首先，用戶(hù)端向服務(wù)端發(fā)送一個(gè)請求，服務(wù)端接收到請求(這里忽悠無(wú)須會(huì )話(huà)控制的情況)后，初始化會(huì )話(huà)，生成相應的會(huì )話(huà)信息，核心是會(huì )話(huà)ID，把會(huì )話(huà)ID發(fā)送給客戶(hù)端，客戶(hù)端接收到這個(gè)會(huì )話(huà)ID，把它存儲起來(lái)，下一次發(fā)送請求的時(shí)候，附帶著(zhù)這個(gè)會(huì )話(huà)ID一起發(fā)送給服務(wù)端，服務(wù)端只要根據這個(gè)會(huì )話(huà)ID，就知道是誰(shuí)了。這個(gè)會(huì )話(huà)ID，就像我們的身份證號碼，一直伴隨終生。核心：服務(wù)端如何生成這個(gè)會(huì )話(huà)ID，客戶(hù)端怎樣存儲這個(gè)會(huì )話(huà)ID。
四、如何存儲會(huì )話(huà)ID(SESSION ID)
服務(wù)端存儲會(huì )話(huà)ID有多種方式，常見(jiàn)的有本地存儲，如：普通文本，文本名就是會(huì )話(huà)ID。對于文件系統，同一目錄下，同一文件名只允許唯一一個(gè)文件，那么使用會(huì )話(huà)ID作為文件名是可以做到唯一確定會(huì )話(huà)的。除了本地文件存儲，還可以使用memcache、redis、或者M(jìn)ysql之類(lèi)的數據庫存儲，即使用第三方數據庫進(jìn)行存儲。只有一個(gè)原則：存儲的會(huì )話(huà)ID必須是唯一的。
客戶(hù)端收到服務(wù)端返回的(或者說(shuō)服務(wù)端下發(fā)的)會(huì )話(huà)ID后，也是像服務(wù)端那樣使用文件名作為會(huì )話(huà)ID存儲會(huì )話(huà)信息到文本嗎?如果客戶(hù)端只與同一個(gè)服務(wù)端(理解為同一個(gè)服務(wù)端處理程序)進(jìn)行會(huì )話(huà)通訊的話(huà)，是可行的。但是，HTTP是因萬(wàn)維網(wǎng)而生的，瀏覽器作為最常見(jiàn)的HTTP客戶(hù)端，需要訪(fǎng)問(wèn)各種不同的網(wǎng)站，如果采用會(huì )話(huà)ID作為文件名，以這樣的文件存在會(huì )話(huà)信息的話(huà)，會(huì )出現這樣的情況：N個(gè)不同的網(wǎng)站，服務(wù)端采用的是相同的會(huì )話(huà)生成算法，在同一時(shí)刻，很可能會(huì )生成一樣的會(huì )話(huà)ID，客戶(hù)端則無(wú)法唯一確定這個(gè)會(huì )話(huà)ID到底是與哪個(gè)服務(wù)端通訊，也就是客戶(hù)端“不認得”服務(wù)端了，會(huì )話(huà)就無(wú)法完成。如何確定服務(wù)端身份?那就是使用“域”，不同的域擁有獨立的會(huì )話(huà)�？蛻�(hù)端以域相關(guān)信息作為文件標識符創(chuàng )建會(huì )話(huà)文件(客戶(hù)端存儲)對會(huì )話(huà)信息進(jìn)行存儲，其中域與會(huì )話(huà)ID結合就能唯一確定服務(wù)端，并且確定會(huì )話(huà)。那么，以“域”信息作為文件名的文件中存儲著(zhù)會(huì )話(huà)ID等信息。每次請求某個(gè)域的服務(wù)時(shí)，把存儲著(zhù)的會(huì )話(huà)ID附帶到請求中發(fā)送到服務(wù)端。瀏覽器是最常見(jiàn)的HTTP客戶(hù)端，瀏覽器存儲會(huì )話(huà)信息，是使用COOKIE文件的，里面保存著(zhù)COOKIE信息，而服務(wù)端返回的會(huì )話(huà)ID也存儲在里面。會(huì )話(huà)ID存儲在COOKIE文件中是一般情況下的，而COOKIE信息是作為HTTP頭發(fā)送給服務(wù)端的，也就是說(shuō)這種情況下，會(huì )話(huà)ID是附帶在請求頭中。但是，HTTP請求，除了頭信息，還可以有內容體，必須有URL。那么，會(huì )話(huà)ID同樣可以存儲在內容體中或URL中，比如在禁用瀏覽器COOKIE的情況下，也可實(shí)現與服務(wù)端會(huì )話(huà)，要么依賴(lài)內容體，要么依賴(lài)URL，常見(jiàn)的是URL中附帶會(huì )話(huà)ID，這個(gè)在PHP等編程語(yǔ)言中較為常見(jiàn)(曾經(jīng)的歷史上常見(jiàn)，但是會(huì )涉及安全或者效率等問(wèn)題，這里不詳述)。
粗糙地，可理解為服務(wù)端返回給客戶(hù)端的會(huì )話(huà)ID是存儲在COOKIE文件中的。COOKIE文件是由瀏覽器管理的，當然在自實(shí)現的客戶(hù)端中，可以通過(guò)編程手段實(shí)現COOKIE文件管理，即客戶(hù)端會(huì )話(huà)的管理。舉例：IOS開(kāi)發(fā)者，可以把HTTP返回的信息頭存儲到沙盒中進(jìn)行管理。PHP開(kāi)發(fā)客戶(hù)端時(shí)，可以把信息頭寫(xiě)到文件中，或第三方服務(wù)中，或網(wǎng)絡(luò )存儲中等等。
五、會(huì )話(huà)管理(SESSION)
會(huì )話(huà)管理包括：會(huì )話(huà)創(chuàng )建、會(huì )話(huà)識別、會(huì )話(huà)信息操作、會(huì )話(huà)生命周期、會(huì )話(huà)關(guān)閉。
注意：這一節中的服務(wù)端會(huì )話(huà)都看作是開(kāi)啟的，無(wú)特別情況不再交待。
1、會(huì )話(huà)創(chuàng )建
客戶(hù)端發(fā)起不帶會(huì )話(huà)ID(SESSION ID)的HTTP請求，服務(wù)端認為還沒(méi)產(chǎn)生會(huì )話(huà)，即創(chuàng )建會(huì )話(huà)，生成會(huì )話(huà)ID并且在服務(wù)器中存儲相關(guān)會(huì )話(huà)信息，并通知客戶(hù)端已開(kāi)啟會(huì )話(huà)。一般情況下，是在返回給客戶(hù)端的HTTP header中的COOKIE項中附帶上會(huì )話(huà)ID，形式為：會(huì )話(huà)標記：會(huì )話(huà)ID�？蛻�(hù)端根據返回的信息頭，設置本地COOKIE值并存儲。
2、會(huì )話(huà)識別
會(huì )話(huà)ID是會(huì )話(huà)的唯一標識符，一個(gè)會(huì )話(huà)ID只會(huì )對應一個(gè)會(huì )話(huà)，就像身份證號碼只對應一個(gè)人一樣。HTTP中，服務(wù)端是被動(dòng)接受請求的，會(huì )話(huà)識別也是被動(dòng)的(觸發(fā)式)。服務(wù)端不需要知道發(fā)送請求的到底是誰(shuí)，只需要知道對方發(fā)送過(guò)來(lái)的會(huì )話(huà)ID，把客戶(hù)端傳過(guò)來(lái)的會(huì )話(huà)ID與服務(wù)端存儲的會(huì )話(huà)ID進(jìn)行匹配。找不到這個(gè)會(huì )話(huà)ID，就認為這個(gè)會(huì )話(huà)是不存在的。
舉例：服務(wù)器有個(gè)會(huì )話(huà)ID是“21412545jladfjljljqwr”，映射的值是“名字：張三，性別：男”�？蛻�(hù)端只要請求中的會(huì )話(huà)ID是“21412545jladfjljljqwr”，就識別到這個(gè)會(huì )話(huà)了，能認為這人是張三，而且是男性。如果客戶(hù)端請求的會(huì )話(huà)ID是“qwesadfasdfadsfasdf”，即使客戶(hù)端附帶了信息“名字：張三，性別：男”，服務(wù)端都認為不存在此人，不形成會(huì )話(huà)。就算是李四盜用了張三的會(huì )話(huà)ID，服務(wù)端也會(huì )識別這個(gè)會(huì )話(huà)。
可簡(jiǎn)單理解為：SESSION只根據SESSION ID建立起會(huì )話(huà)，是不負責安全校驗的，只負責讓服務(wù)端與客戶(hù)端可以“通話(huà)”。
3、會(huì )話(huà)信息操作
服務(wù)端：會(huì )話(huà)ID映射信息，ID不變，映射的內容可變
客戶(hù)端：會(huì )話(huà)ID映射信息，ID不變，映射的內容可變(即存在在COOKIEk中的內容可變)。
服務(wù)端與客戶(hù)端的會(huì )話(huà)信息只有會(huì )話(huà)ID是必須相同的，其它會(huì )話(huà)信息(即會(huì )話(huà)ID映射的信息)沒(méi)有直接關(guān)系。
4、會(huì )話(huà)生命周期
會(huì )話(huà)從開(kāi)始到結束就是會(huì )話(huà)的生命周期。設定一個(gè)時(shí)間，這個(gè)時(shí)間內無(wú)通訊就清除會(huì )話(huà)信息，我們就把這個(gè)時(shí)間叫做會(huì )話(huà)超時(shí)周期。
習慣地，我們把會(huì )話(huà)超時(shí)周期叫做會(huì )話(huà)的生命周期，其實(shí)這是兩個(gè)概念。
5、會(huì )話(huà)關(guān)閉
會(huì )話(huà)關(guān)閉，有2種方式。一種是用戶(hù)主動(dòng)清除會(huì )話(huà)信息，另一種是會(huì )話(huà)超時(shí)。會(huì )話(huà)超時(shí)不是守護任務(wù)(或自動(dòng)任務(wù))周期性檢查處理的，而是訪(fǎng)問(wèn)會(huì )話(huà)信息時(shí)，根據會(huì )話(huà)信息中的“上一次更新時(shí)間”到現在的時(shí)間差，與會(huì )話(huà)周期比較，超出周期的，清除會(huì )話(huà)信息，即會(huì )話(huà)關(guān)閉。
經(jīng)典例子：會(huì )話(huà)過(guò)程中，突然斷網(wǎng)。
六、會(huì )話(huà)校驗與HTTP協(xié)議冪等性
HTTP冪等性簡(jiǎn)述：
從定義上看，HTTP方法的冪等性是指一次和多次請求某一個(gè)資源應該具有同樣的副作用。冪等性屬于語(yǔ)義范疇，正如編譯器只能幫助檢查語(yǔ)法錯誤一樣，HTTP規范也沒(méi)有辦法通過(guò)消息格式等語(yǔ)法手段來(lái)定義它，這可能是它不太受到重視的原因之一。但實(shí)際上，冪等性是分布式系統設計中十分重要的概念，而HTTP的分布式本質(zhì)也決定了它在HTTP中具有重要地位。
舉個(gè)例子(摘抄網(wǎng)上)：假設有一個(gè)從賬戶(hù)取錢(qián)的遠程API(可以是HTTP的，也可以不是)，我們暫時(shí)用類(lèi)函數的方式記為：bool withdraw(account_id, amount)。請求服務(wù)端，減小account_id的amount金額，成功返回true;失敗金額不變，返回false。
如果服務(wù)端成功了，并返回true，但網(wǎng)絡(luò )中斷，客戶(hù)端收不到信息，客戶(hù)端認為取錢(qián)失敗，再次請求，服務(wù)端再一次扣費。這里就涉及一個(gè)重復請求同一操作的問(wèn)題了。
要解決這個(gè)問(wèn)題，我們可以把withdraw設計為冪等的。create_ticket的語(yǔ)義是獲取一個(gè)服務(wù)器端生成的唯一的處理號ticket_id，它將用于標識后續的操作。idempotent_withdraw和withdraw的區別在于關(guān)聯(lián)了一個(gè)ticket_id，一個(gè)ticket_id表示的操作至多只會(huì )被處理一次，每次調用都將返回第一次調用時(shí)的處理結果。這樣，idempotent_withdraw就符合冪等性了，客戶(hù)端就可以放心地多次調用。
從上面例子可以看到create_cicket的作用是生成ID識別碼，后續操作均基于此ID。會(huì )話(huà)ID本質(zhì)上也是冪等性的，生成ID后，后續操作均帶上ID參數，即建立操作信息與ID的對應關(guān)系。上面的例子并不是安全的，只是確保了操作對于同一個(gè)人(一次會(huì )話(huà)過(guò)程)是唯一的。同樣，會(huì )話(huà)ID只作為身份唯一的識別，不是安全的保證。
簡(jiǎn)單會(huì )話(huà)校驗：
一種較簡(jiǎn)單的會(huì )話(huà)校驗是使用令牌，即請求中除了會(huì )話(huà)ID，至少還攜帶了令牌。服務(wù)端對令牌校驗。令牌由服務(wù)端根據某種算法生成，令牌校驗也在服務(wù)端中處理，客戶(hù)端只需存儲令牌，在請求中攜帶令牌，令牌生成算法的復雜程度影響令牌校驗的安全性。
舉例：tokenFunc(param,value=’’) 第一個(gè)參數為令牌生成參數，第二個(gè)參數為T(mén)oken值。當第二參數為空時(shí)，成生Token，返回string;第二個(gè)參數不為空時(shí)，檢查T(mén)oken準確性 ，返回bool. 一般不需要解密，只要散列加密即可。PHP代碼如下：
function token($param,$value=’’){
if(!is_string($param){
$param = serialize($param);
}
$token = md5($param.’sault’);
if(!empty($value)){
if($value == $token){
return true;
}else{
return false;
}
}else{
return $token;
}
}
生成令牌：$token = token($session_id);
檢驗令牌：$check = token($session_id,$token);
七、會(huì )話(huà)原理的應用
瀏覽器默認是開(kāi)啟Cookie的，瀏覽器發(fā)起HTTP請求時(shí)，在請求頭中帶有Cookie信息，只要服務(wù)端返回Cookie中包含SessionID，在服務(wù)端根據Sessionid即實(shí)現HTTP會(huì )話(huà)，此過(guò)程對于前端開(kāi)發(fā)者是透明的(即前端開(kāi)發(fā)可以不關(guān)心瀏覽器是怎樣與服務(wù)端確定會(huì )話(huà)的)。
除即時(shí)通訊，實(shí)時(shí)動(dòng)作網(wǎng)游外，大多APP是使用HTTP協(xié)議與服務(wù)端通訊的，使用HTTP協(xié)議的原因主要是移動(dòng)網(wǎng)絡(luò )環(huán)境復雜(容易斷線(xiàn))，并且HTTP協(xié)議穿透性強。原生開(kāi)發(fā)的IOS，安卓等APP，與服務(wù)端會(huì )話(huà)，可不使用COOKIE，只需要在請求中攜帶會(huì )話(huà)ID即可，這在上文已描述。原生APP與內嵌瀏覽器的APP相比：原生實(shí)現性能更高，交互效果流暢，用戶(hù)體驗相對較好，但快速跌代比不上內嵌瀏覽器的APP。手機配置越來(lái)越高，內嵌瀏覽器對HTML5支持也越來(lái)越好，在性能要求不是很高的場(chǎng)景，內嵌WEB的性能已可滿(mǎn)足，在布局多變，或者元素多變的情況下，可快速修改，而無(wú)需用戶(hù)升級APP，也能獲得更好的產(chǎn)品體驗。APP內嵌WEB最常見(jiàn)的場(chǎng)景就是電商APP了，登陸、注冊、入口等交互效果較多的模塊使用原生程序開(kāi)發(fā)，而商品列表、商品展示等等模塊可采用內嵌WEB,這樣既可滿(mǎn)足快速產(chǎn)品跌代的要求，又可滿(mǎn)足操作的性能要求。
舉例：電商APP入門(mén)界面、登陸、注冊是使用原生開(kāi)發(fā)的，登陸后跳轉到商品列表頁(yè)(即內嵌WEB)，然后下訂單。問(wèn)題來(lái)了，如何使得登陸后跳轉到WEB后，還是登陸狀態(tài)(即內嵌WEB與原生程序具有一致的會(huì )話(huà))呢?內嵌WEB是不會(huì )去取得原生程序所存儲的data的。最簡(jiǎn)單直接的辦法就是：登陸成功，服務(wù)器返回會(huì )話(huà)ID與成功信息，跳轉到WEB時(shí)，發(fā)送的HTTP請求頭中包括COOKIE，會(huì )話(huà)ID存儲在COOKIE中，這樣之后點(diǎn)擊WEB中的鏈接后向服務(wù)端發(fā)送的HTTP請求頭，就會(huì )攜帶這個(gè)COOKIE(會(huì )話(huà)ID)了。簡(jiǎn)單地理解：終端原生程序請求服務(wù)端，服務(wù)端按普通WEB那樣返回信息，終端原生程序取得HTTP返回頭中的COOKIE信息，保存下來(lái)，下一次請求時(shí)，攜帶COOKIE信息即可。在瀏覽器中，COOKIE的處理由瀏覽器默認處理，而在原生APP程序中，由開(kāi)發(fā)者寫(xiě)程序去處理而已。
【HTTP會(huì )話(huà)原理解釋與應用】相關(guān)文章：
深入理解Java事物原理與應用05-05
網(wǎng)頁(yè)設計中的數學(xué)原理應用03-05
計算機原理中C語(yǔ)言的應用01-02
JAVA如何獲取HTTP請求頭02-14