2020-4-22 前端達人
目錄
HTTP協議
HTTP請求：
HTTP響應：
會話與會話狀態：
Cookie
Session
Cookie和Session的區別
HTTP協議
HTTP請求：
Post /test.php HTTP/1.1 //請求行以一個方法符號開頭，以空格分開，后面跟著請求的URI和協議的版本
Host: www.test.com //請求頭
User-agent:mozilla/5.0(windows NT 6.1: rv: 15.0)
Gecko/20100101 firefox15.0
//空白行，代表請求頭結束
Username=admin&passwd=admin //請求正文
HTTP請求方法
GET 請求獲取Request-URI所標識的資源
POST 在Request-URI所標識的資源后附加新的數據
HEAD 請求獲取由Request-URI所標識的資源的響應消息報頭
PUT 請求服務器存儲一個資源，并用Request-URI作為其標識
常用的為GET和POST；GET和POST的區別：
GET提交的內容會直接顯示在URL中，私密性較差，可以用于顯示一些公共資源；但是GET效率會比較高。
POST不會將內容顯示在URL中，可以用于提交一些敏感數據，例如用戶名或密碼。
HTTP響應：
HTTP/1.1 200 OK //響應行由協議版本號，響應狀態碼和文本描述組成
Data：sun，15 nov 2018 11:02:04 GMT //響應頭
Server：bfe/1.0.8.9
……
Connection: keep-alive
//空白行，代表響應頭結束
<html>
</html><title>index.heml</title> //響應正文
HTTP的狀態碼：
狀態代碼由三位數字組成，第一個數字定義了響應的類別，且有五種可能取值。
1xx：指示信息 —— 表示請求已接收，繼續處理。
2xx：成功 —— 表示請求已被成功接收、理解、接受。
3xx：重定向 —— 要完成請求必須進行更進一步的操作。
4xx：客戶端錯誤 —— 請求有語法錯誤或請求無法實現。
5xx：服務器端錯誤 —— 服務器未能實現合法的請求。
常見狀態代碼、狀態描述的說明如下。
200 OK：客戶端請求成功。
400 Bad Request：客戶端請求有語法錯誤，不能被服務器所理解。
401 Unauthorized：請求未經授權，這個狀態代碼必須和 WWW-Authenticate 報頭域一起使用。
403 Forbidden：服務器收到請求，但是拒絕提供服務。
404 Not Found：請求資源不存在，舉個例子：輸入了錯誤的URL。
500 Internal Server Error：服務器發生不可預期的錯誤。
503 Server Unavailable：服務器當前不能處理客戶端的請求，一段時間后可能恢復正常。
會話與會話狀態：
Web中的會話是指一個客戶端瀏覽器與web服務器之間連續發生一系列請求和響應過程。會話狀態是指在會話過程中產生的狀態信息；借助會話狀態，web服務器能夠把屬于同一會話中的一系列的請求和響應關聯起來。
Cookie
概述
Cookie是一種在客戶端保持HTTP狀態信息的技術，它好比商場發放的優惠卡。在瀏覽器訪問Web服務器的某個資源時，由Web服務器在在HTTP響應頭中附帶傳送給瀏覽器一片數據，web服務器傳送給各個客戶端瀏覽器的數據是可以各不相同的。
一旦Web瀏覽器保存了某個Cookie，那么它在以后每次訪問該Web服務器是都應在HTTP請求頭中將這個Cookie回傳個Web服務器。Web服務器通過在HTTP響應消息中增加Set-Cookie響應頭字段將CooKie信息發送給瀏覽器，瀏覽器則通過在HTTP請求消息中增加Cookie請求頭字段將Cookie回傳給Web服務器。
一個Cookie只能標識一種信息，它至少含有一個標識該消息的名稱（NAME）和和設置值（VALUE）。一個Web瀏覽器也可以存儲多個Web站點提供的Cookie。瀏覽器一般只允許存放300個Cookie，每個站點最多存放20個Cookie，每個Cookie的大小限制為4KB。
傳送示意圖
特點
存儲于瀏覽器頭部/傳輸與HTTP頭部，寫時帶屬性，讀時無屬性。由三元【name，domain，path】唯一確定Cookie。
Set-Cookie2響應頭字段
Set-Cookie2頭字段用于指定WEB服務器向客戶端傳送的Cookie內容，但是按照Netscape規范實現Cookie功能的WEB服務器， 使用的是Set-Cookie頭字段，兩者的語法和作用類似。Set-Cookie2頭字段中設置的cookie內容是具有一定格式的字符串，它必須以Cookie的名稱和設置值開頭，格式為"名稱=值”,后面可以加上0個或多個以分號(;) 和空格分隔的其它可選屬性，屬性格式一般為 "屬性名=值”。
除了“名稱=值”對必須位于最前面外，其他的可選屬性可以任意。Cookie的名稱只能由普通的英文ASCII字符組成，瀏覽器不用關心和理解Cookie的值部分的意義和格式，只要WEB服務器能理解值部分的意義就行。大多數現有的WEB服務器都是采用某種編碼方式將值部分的內容編碼成可打印的ASCII字符，RFC 2965規范中沒有明確限定編碼方式。
舉例: Set-Cookie2: user-hello; Version=1; Path=/
Cookie請求頭字段
Cookie請求頭字段中的每個Cookie之間用逗號（，）或分號（；）分隔。在Cookie請求字段中除了必須有“名稱=值”的設置外，還可以有Version、path、domain、port等屬性；在Version、path、domain、port等屬性名之前，都要增加一個“$”字符作為前綴。Version屬性只能出現一次，且要位于Cookie請求頭字段設置值的最前面，如果需要設置某個Cookie信息的Path、Domain、Port等屬性，它們必須位于該Cookie信息的“名稱=值”設置之后。
瀏覽器使用Cookie請求頭字段將Cookie信息會送給Web服務器；多個Cookie信息通過一個Cookie請求頭字段會送給Web服務器。
瀏覽器會根據下面幾個規則決定是否發送某個Cookie信息：
1、請求主機名是否與某個存儲的Cookie的Domain屬性匹配
2、請求的端口號是否在該Cookie的Port屬性列表中
3、請求的資源路徑是否在該Cookie的Path屬性指定的目錄及子目錄中
4、該Cookie的有效期是否已過
Path屬性的指向子目錄的Cookie排在Path屬性指向父目錄的Cookie之前
舉例: Cookie: $Version=1; Course=Java; $Path=/hello/lesson;Course=vc; $Path=/hello
Cookie的安全屬性
secure屬性
當設置為true時，表示創建的Cookie會被以安全的形式向服務器傳輸，也就是只能在HTTPS連接中被瀏覽器傳遞到服務器端進行會話驗證，如果是HTTP連接則不會傳遞該信息，所以不會被竊取到Cookie的具體內容。
HttpOnly屬性
如果在Cookie中設置了"HttpOnly"屬性，那么通過程序(JS腳本、Applet等)將無法讀取到Cookie信息，這樣能有效的防止XSS攻擊。
總結：secure屬性 是防止信息在傳遞的過程中被監聽捕獲后信息泄漏，HttpOnly屬性的目的是防止程序獲取cookie后進行攻擊這兩個屬性并不能解決cookie在本機出現的信息泄漏的問題(FireFox的插件FireBug能直接看到cookie的相關信息)。
Session
使用Cookie和附加URL參數都可以將上一-次請求的狀態信息傳遞到下一次請求中，但是如果傳遞的狀態信息較多，將極大降低網絡傳輸效率和增大服務器端程序處理的難度。
概述
Session技術是一種將會話狀態保存在服務器端的技術，它可以比喻成是醫院發放給病人的病歷卡和醫院為每個病人保留的病歷檔案的結合方式?？蛻舳诵枰邮铡⒂洃浐突厮蚐ession的會話標識號，Session可以且通常是借助Cookie來傳遞會話標識號。
Session的跟蹤機制
HttpSession對象是保持會話狀態信息的存儲結構，一個客戶端在WEB服務器端對應一個各自的HttpSession對象。WEB服務器并不會在客戶端開始訪問它時就創建HttpSession對象，只有客戶端訪問某個能與客戶端開啟會話的服務端程序時，WEB應用程序才會創建一個與該客戶端對應的HttpSession對象。WEB服務器為HttpSession對象分配一個獨一無的會話標識號， 然后在響應消息中將這個會話標識號傳遞給客戶端?？蛻舳诵枰涀挊俗R號，并在后續的每次訪問請求中都把這個會話標識號傳送給WEB服務器，WEB服務器端程序依據回傳的會話標識號就知道這次請求是哪個客戶端發出的，從而選擇與之對應的HttpSession對象。
WEB應用程序創建了與某個客戶端對應的HttpSession對象后，只要沒有超出一個限定的空閑時間段，HttpSession對象就駐留在WEB服務器內存之中，該客戶端此后訪問任意的Servlet程序時，它們都使用與客戶端對應的那個已存在的HttpSession對象。
Session是實現網上商城的購物車的最佳方案，存儲在某個客戶Session中的一個集合對象就可充當該客戶的一個購物車。
超時管理
WEB服務器無法判斷當前的客戶端瀏覽器是否還會繼續訪問，也無法檢測客戶端瀏覽器是否關閉，所以，即使客戶已經離開或關閉了瀏覽器，WEB服務器還要保留與之對應的HttpSession對象。隨著時間的推移而不斷增加新的訪問客戶端，WEB服務器內存中將會因此積累起大量的不再被使用的HttpSession對象，并將最終導致服務器內存耗盡。WEB服務器采用“超時限制”的辦法來判斷客戶端是否還在繼續訪問如果某個客戶端在一定的時間之 內沒有發出后續請求，WEB服務器則認為客戶端已經停止了活動，結束與該客戶端的會話并將與之對應的HttpSession對象變成垃圾。
如果客戶端瀏覽器超時后再次發出訪問請求，Web服務器則認為這是一個新的會話開始，將為之創建新的Httpsession對象和分配新的會話標識號。
利用Cookie實現Session的跟蹤
如果WEB服務器處理某個訪問請求時創建了新的HttpSession對象，它將把會話標識號作為一個Cookie項加入到響應消息中，通常情況下，瀏覽器在隨后發出的訪問請求中又將會話標識號以Cookie的形式回傳給WEB服務器。WEB服務器端程序依據回傳的會話標識號就知道以前已經為該客戶端創建了HttpSession對象，不必再為該客戶端創建新的HttpSession對象，而是直接使用與該會話標識號匹配的HttpSession對象，通過這種方式就實現了對同一個客戶端的會話狀態的跟蹤。
利用URL重寫實現Session跟蹤
Servlet規范中引入了一種補充的會話管理機制，它允許不支持Cookie的瀏覽器也可以與WEB服務器保持連續的會話。這種補充機制要求在響應消息的實體內容中必須包含下一 次請求的超鏈接，并將會話標識號作為超鏈接的URL地址的一個特殊參數。將會話標識號以參數形式附加在超鏈接的URL地址后面的技術稱為URL重寫。 如果在瀏覽器不支持Cookie或者關閉了Cookie功能的情況下，WEB服務器還要能夠與瀏覽器實現有狀態的會話，就必須對所有能被客戶端訪問的請求路徑(包括超鏈接、form表單的action屬性設置和重定向的URL)進行URL重寫。
Cookie和Session的區別
session和cookies同樣都是針對單獨用戶的變量(或者說是對象好像更合適點)，不同的用戶在訪問網站的時候都會擁有各自的session或者cookies,不同用戶之間互不干擾。
他們的不同點是:
1,存儲位置不同
session在服務器端存儲，比較安全，但是如果session較多則會影響性能
cookies在客戶端存儲，存在較大的安全隱患
2，生命周期不同
session生命周期在指定的時間(如20分鐘) 到了之后會結束，不到指定的時間，也會隨著瀏覽器進程的結束而結束。
cookies默認情況下也隨著瀏覽器進程結束而結束，但如果手動指定時間，則不受瀏覽器進程結束的影響。
總結：簡而言之，兩者都是保存了用戶操作的歷史信息，但是存在的地方不同；而且session和cookie的目的相同，都是為了克服HTTP協議無狀態的缺陷，但是完成方法不同。Session通過cookie在客戶端保存session id，將用戶的其他會話消息保存在服務端的session對象中；而cookie需要將所有信息都保存在客戶端，因此存在著一定的安全隱患，例如本地Cookie中可能保存著用戶名和密碼，容易泄露。
————————————————
版權聲明：本文為CSDN博主「悲觀的樂觀主義者」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/weixin_43997530/article/details/105650267