HTTP報文結構及Cookie、session區別

目錄

• 萬維網
  • HTTP超文本傳輸協議
  • 特點
  • HTTP的報文結構。
    • 下面介紹http請求報文最主要的一些特點
• 在服務器上存放用戶的信息（Cookie）
  • 實例：
  • 工作原理：
  • cookie中的主要內容：
  • Cookie的作用：
  • Cookie的缺陷：
• Session詳解
  • 簡介：
  • 工作原理：
  • 作用
• Cookie和session的區別

萬維網

HTTP超文本傳輸協議

為了使萬維網客戶程序與萬維網服務器程序之間的交互遵守嚴格的協議，因此誕生了HTTP超文本傳輸協議。

特點

1. 位於OSI七層模型的應用層，http是一個應用協議
2. 它使用TCP連接進行可靠的傳送

HTTP的報文結構。

http有兩類報文：

1. 請求報文---從客戶端向服務端發送的請求報文
2. 響應報文---從服務器到可用戶端的回答

由於http是面向文本的，因此在報文中的每一個字段都是一些ASCII碼串，因而各個字段的長度都是不確定的

HTTP請求報頭和響應報頭都是由三個部分組成。可以看出，這兩種報文格式的區別就是開始行不同。

1. 開始行（）

   用於區分是請求報文還是響應報文，在請求報文中的開始行叫做請求行，而在響應報文中的開始行叫做狀態行。在開始行的三個字段之間都以空格分隔開，最后的CR和LF分別代表”回車“ 和 “換行”

2. 首部行（head）

   用來說明瀏覽器、服務器或報文體的一些信息。首部可以有好幾行，但也可以不使用。在每一個首部行中都有首部字段名和它的值，每一行在結束的地方都要有“回車”和“換行”。整個首部行結束時，還有一空行將首部行和后面的實體主體分開

3. 實體主體（body）

   在請求報文中一般都不用這個字段，而在響應報文中也可能沒有這個字段

下面介紹http請求報文最主要的一些特點

1. 請求報文的第一行“請求行”只有三個內容，即方法，請求資源的URL，以及HTTP的版本。

   請注意：這里的名詞“方法”是面向對象技術中使用的專門名詞。所謂“方法”就是對所請求的對象進行的操作，這些方法實際上也就是一些命令。因此，請求報文的類型是由它所采用的方法決定的。請求報文中常用的幾種方法：

   HTTP1.0 定義了三種請求方法： GET, POST 和 HEAD方法。

   HTTP1.1 新增了五種請求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

   方法	意義
   GET	請求指定的頁面信息，並返回實體主體。
   HEAD	類似於 GET 請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
   POST	向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST 請求可能會導致新的資源的建立和/或已有資源的修改。
   PUT	從客戶端向服務器傳送的數據取代指定的文檔的內容。
   DELETE	請求服務器刪除指定的頁面。
   CONNECT	HTTP/1.1 協議中預留給能夠將連接改為管道方式的代理服務器。
   OPTIONS	允許客戶端查看服務器的性能。
   TRACE	回顯服務器收到的請求，主要用於測試或診斷。
   PATCH	是對 PUT 方法的補充，用來對已知資源進行局部更新 。

   例子：要鏈接到“清華大學院系設置”的頁面。HTTP的請求報文的開始行（即請求行）應當是請注意在GET后面和HTTP/1.1前面的空格

   GET http://www.tsinghua.edu.cn/chn/yxsz/index.htm HTTP/1.1
   

   下面是一個請求報文的例子：

   GET /chn/yssz/index.htm HTTP/1.1   {請求行使用了相對URL}
   
   Host: www.tsinghua.edu.cn		{此行是首部行的開始。這行給出主機的域名}
   
   Connection: close					{告訴服務器發送完請求的文檔后就可釋放連接}
   
   User-Agent: Mozilla/5.0			{表名用戶代理是使用Netscape瀏覽器}
   
   Accept-Language: cn				{表示用戶希望優先得到中文版本的文檔}
   {請求報文的最后還有一個空行}
   

   在請求行使用了相對URL（即省略了主機的域名）是因為下面的首部行（第2行）給出了主機的域名。第3行是告訴服務器不使用持續連接，表示瀏覽器希望服務器在傳送完所請求的對象后即關閉TCP連接。另外這個請求報文沒有實體主體（body）

2. 在看一下HTTP響應報文的主要特點

   每一個請求報文發出后，都能收到一個響應報文。響應報文的第一行就是狀態行。

   狀態行包括三項內容，即HTTP的版本，狀態碼，以及解釋狀態碼的簡單短語。

   狀態碼都是三位數字的，分為5大類共33種，例如：

   1** 表示通知信息的，如請求收到了或正在進行處理

   2** 表示成功，如接受或知道了

   3** 表示重定向，如要完成請求還必須采取進一步的行動

   4** 表示客戶的差別，如請求中有錯誤的語法或不能完成

   5** 表示服務器的差錯，如服務器失效無法完成請求

   下面的三種狀態行在響應報文中是經常見到的。

   HTTP/1.1 200 Accepted {接受}

   HTTP/1.1 400 Bad Request {錯誤的請求}

   HTTP/1.1 404 Not Found {找不到}

   若請求的網頁從http://www.ee.xyz.edu/index.html轉移到了一個新的地址，則響應報文的狀態行和一個首部行就是下面的形式：

   HTTP/1.1 301 Moved Permanently {永久性的轉移了}

   Location: http://www.xyz.edu/ee/index.html {新的URL}

在服務器上存放用戶的信息（Cookie）

實例：

在網上購物時，一個顧客要購買很多種物品。當他把選好的一件物品放入“購物車”后，他還有繼續瀏覽和選購其他的物品。因此，服務器需要記住用戶的身份，使他再接着選購的一些物品能夠放入同一個“購物車”中，這樣就便於集中結賬。有時某些萬維網站點也可能想限制某些用的訪問。要做到這點，可以在HTTP中使用Cookie.

在RFC 2109中對Cookie進行了定義，規定萬維網站點可以使用Cookie來跟蹤用戶。Cookie原意是“小甜餅”（廣東人用方言音譯為“曲奇”），目前尚無標准譯名，在這里Cookie表示在HTTP服務器和客戶之間傳遞的狀態信息。現在很多網站都已廣泛使用Cookie

工作原理：

當用戶張三瀏覽某個使用Cookie的網站時，該網站的服務器就為張三產生一個唯一的識別碼，並以此作為索引在服務器的后端數據庫中產生一個項目。接着給張三的HTTP響應報文中添加一個叫做Set-cookie的首部行。這里的“首部字段名”就是"Set-cookie"，而后面的“值”就是賦予該用戶的“識別碼”。例如這個首部行時這樣的：
Set-cookie: 12345678
張三收到響應后，其瀏覽器會在管理的特定Cookie文件中添加一行，包括這個服務器的主機名和Set-cookie后面給出的識別碼。張三每發一個HTTP請求報文，瀏覽器就會從其Cookie文件中取出這個識別碼，放到HTTP請求報文的Cookie首部行中：
Cookie: 12345678
於是，這個網站就能夠跟蹤用戶1234567（張三）在該網站的活動。服務器不需要知道這個用戶的姓名和其它信息，但能夠知道它在什么時間訪問了什么頁面，訪問的順序等。如果是網上購物，服務器可以為張三維護一個所購物品列表，一起付費。
如果張三幾天后訪問這個網站，那么他的瀏覽器會在其HTTP請求報文中繼續使用首部行Cookie: 12345678，而這個網站服務器根據張三過去的訪問記錄可以向他推薦商品

cookie中的主要內容：

cookie的內容主要包括：名字，值，過期時間，路徑和域。 
其中域可以指定某一個域比如.google.com，相當於總店招牌，比如寶潔公司，也可以指定一個域下的具體某台機器比如www.google.com或者froogle.google.com，可以用飄柔來做比。 
路徑就是跟在域名后面的URL路徑，比如/或者/foo等等，可以用某飄柔專櫃做比。 
路徑與域合在一起就構成了cookie的作用范圍。 
如果不設置過期時間，則表示這個cookie的生命期為瀏覽器會話期間，只要關閉瀏覽器窗口，cookie就消失了。這種生命期為瀏覽器會話期的cookie被稱為會話cookie。會話cookie一般不存儲在硬盤上而是保存在內存里，當然這種行為並不是規范規定的。如果設置了過期時間，瀏覽器就會把cookie保存到硬盤上，關閉后再次打開瀏覽器，這些cookie仍然有效直到超過設定的過期時間。 

存儲在硬盤上的cookie可以在不同的瀏覽器進程間共享，比如兩個IE窗口。而對於保存在內存里的cookie，不同的瀏覽器有不同的處理方式。對於IE，在一個打開的窗口上按Ctrl-N（或者從文件菜單）打開的窗口可以與原窗口共享，而使用其他方式新開的IE進程則不能共享已經打開的窗口的內存cookie；對於Mozilla Firefox0.8，所有的進程和標簽頁都可以共享同樣的cookie。一般來說是用javascript的window.open打開的窗口會與原窗口共享內存cookie。瀏覽器對於會話cookie的這種只認cookie不認人的處理方式經常給采用session機制的web應用程序開發者造成很大的困擾。 

下面就是一個goolge設置cookie的響應頭的例子 
HTTP/1.1 302 Found 
Location: http://www.google.com/intl/zh-CN/ 
Set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com 
Content-Type: text/html 

Cookie的作用：

1. 記住密碼，下次自動登錄
2. 購物車功能
3. 記錄用戶瀏覽數據，進行商品（廣告）推薦

Cookie的缺陷：

1. Cookie會被附加在每個HTTP請求中，所以無形中增加了流量。
2. 由於在HTTP請求中的Cookie是明文傳遞的，所以安全性成問題。（除非用HTTPS）
3. Cookie的大小限制在4KB左右。對於復雜的存儲需求來說是不夠用的。

Session詳解

簡介：

Session代表服務器與瀏覽器的一次會話過程，這個過程是連續的，也可以時斷時續的。Session是一種服務器端的機制，Session 對象用來存儲特定用戶會話所需的信息

工作原理：

當用戶訪問到一個服務器，如果服務器啟用Session，服務器就要為該用戶創建一個SESSION，在創建這個SESSION的時候，服務器首先檢查這個用戶發來的請求里是否包含了一個SESSION ID，如果包含了一個SESSION ID則說明之前該用戶已經登陸過並為此用戶創建過SESSION，那服務器就按照這個SESSION ID把這個SESSION在服務器的內存中查找出來（如果查找不到，就有可能為他新創建一個），如果客戶端請求里不包含有SESSION ID，則為該客戶端創建一個SESSION並生成一個與此SESSION相關的SESSION ID。這個SESSION ID是唯一的、不重復的、不容易找到規律的字符串，這個SESSION ID將被在本次響應中返回到客戶端保存，而保存這個SESSION ID的正是COOKIE，這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發送給服務器。

作用

1. 判斷用戶是否登錄
2. 購物車功能

Cookie和session的區別

1. 存放位置不同

   Cookie保存在客戶端，Session保存在服務端。
   

2. 存取方式的不同

   Cookie中只能保管ASCII字符串，假如需求存取Unicode字符或者二進制數據，需求先進行編碼。Cookie中也不能直接存取Java對象。若要存儲略微復雜的信息，運用Cookie是比擬艱難的。 
   
   而Session中能夠存取任何類型的數據，包括而不限於String、Integer、List、Map等。Session中也能夠直接保管Java Bean乃至任何Java類，對象等，運用起來十分便當。能夠把Session看做是一個Java容器類
   

3. 安全性（隱私策略）的不同

   Cookie存儲在瀏覽器中，對客戶端是可見的，客戶端的一些程序可能會窺探、復制以至修正Cookie中的內容。而Session存儲在服務器上，對客戶端是透明的，不存在敏感信息泄露的風險。 假如選用Cookie，比較好的方法是，敏感的信息如賬號密碼等盡量不要寫到Cookie中。最好是像Google、Baidu那樣將Cookie信息加密，提交到服務器后再進行解密，保證Cookie中的信息只要本人能讀得懂。而假如選擇Session就省事多了，反正是放在服務器上，Session里任何隱私都能夠有效的保護
   

4. 有效期的不同

   只需要設置Cookie的過期時間屬性為一個很大很大的數字，Cookie就可以在瀏覽器保存很長時間。 由於Session依賴於名為JSESSIONID的Cookie，而Cookie JSESSIONID的過期時間默許為–1，只需關閉了瀏覽器（一次會話結束），該Session就會失效。
   

5. 對服務器造成的壓力不同

   Session是保管在服務器端的，每個用戶都會產生一個Session。假如並發訪問的用戶十分多，會產生十分多的Session，耗費大量的內存。而Cookie保管在客戶端，不占用服務器資源。假如並發閱讀的用戶十分多，Cookie是很好的選擇
   

6. 跨域支持上的不同

   Cookie支持跨域名訪問，例如將domain屬性設置為“.baidu.com”，則以“.baidu.com”為后綴的一切域名均能夠訪問該Cookie。跨域名Cookie如今被普遍用在網絡中。而Session則不會支持跨域名訪問。Session僅在他所在的域名內有效。