【讀】這一次,讓咱們再深刻一點 - HTTP的客戶端識別

這是網絡系列的第八篇文章,接下來會有更多精彩內容.敬請期待! 讓咱們一塊兒乘風破浪!

前言

HTTP做爲一個無狀態的請求響應協議，幾乎沒有什麼信息用來判斷是哪一個客戶端，也沒法記錄用戶的訪問記錄。隨着業務增加，如今的服務器但願能記錄客戶端的信息，以便提供個性化服務（收集用戶數據）。今天一塊兒來了解下經常使用的客戶端識別方式：

• HTTP首部
• 客戶端IP地址
• 用戶登陸
• 胖URL
• Cookie

HTTP首部

HTTP首部識別，是根據請求首部的相關信息來獲取客戶端信息。下面是經常使用的首部：

首部名稱	類型	描述
From	請求	用戶E-mail地址
User-Agent	請求	用戶瀏覽器軟件
Referer	請求	用戶是從這個連接跳轉過來的
Authorization	請求	用戶名和密碼
Client-IP	擴展請求	客戶端IP地址
X-Forwarded-For	擴展請求	客戶端IP地址(詳情看這裏)
Cookie	擴展請求	服務器產生的ID標籤

• From首部記錄了每一個用戶的E-mail地址，理想狀況下，這個地址能夠做爲識別用戶的標誌。但爲了防止服務器收集該信息用於垃圾郵件的散發，不多瀏覽器會發送From首部。
• User-Agent首部是用戶瀏覽器的相關信息，能夠用來制定和特定瀏覽器的交互動做，但它並不能用來識別特定的用戶信息。
• Referer首部提供了用戶來源頁面的URL。只是標識了用戶以前訪問了哪一個頁面。

客戶端IP地址

IP地址做爲用戶標識具備必定的前提條件：每一個用戶有着不一樣的IP，不多發生變化。但一般狀況下，IP地址描述的是一臺機器，而不是一個用戶；IP地址也會在用戶登陸服務商時動態獲取；服務器可能看到的是HTTP代理的IP地址（這種狀況下Client-IP和X-Forwarded-For首部保存了原始IP地址）。

用戶登陸

用戶登陸，在用戶訪問須要受權才能訪問的網站時，服務器會要求其登陸。用戶在輸入用戶名和密碼後，瀏覽器能夠經過WWW-Authentication首部將相關信息加密後發給服務器，這樣服務器就能夠標識當前用戶。固然，該方式帶來一個麻煩就是，用戶在訪問不一樣的網站時，須要屢次輸入不一樣的用戶名和密碼。

胖URL

有些服務器會爲每一個用戶生成特定版本的URL，來識別不一樣的用戶身份。一般，會對真正的URL進行擴展，在URL中添加狀態信息；這些包含了用戶信息的URL就稱爲胖URL。但該種方式也存在一些問題：

• URL和用戶關聯，沒法共享
• 破壞了緩存，公共的資源因爲帶有我的信息，沒法緩存。
• 除非用戶收藏了特定URL，不然用戶退出時信息就會丟失。

Cookie

和上面幾種識別用戶的方式相比，Cookie是最好的方式。

• Cookie的類型
  • 會話Cookie：臨時的，記錄用戶訪問站點的設置和偏好，退出瀏覽器是會刪除。
  • 持久Cookie：存儲在硬盤，存在時間更長。也是用來存儲用戶信息。 它們之間的區別是過時時間。
• Cookie是如何工做的 Cookie是一個name = value 的鍵值列表，服務器對一無所知的用戶的HTTP響應中，使用Set-Cookie或Set-Cookie2首部設置。瀏覽器會記住首部的內容，未來在用戶返回同一站點時，會將對應的Cookie傳給服務器。
• Cookie罐：客戶端的狀態 Cookie的思想是讓瀏覽器積累一組服務器特有信息，每次訪問服務器都會將對應信息提供給服務器。由於瀏覽器須要負責存儲Cookie信息，因此此係統被稱爲客戶端側狀態，規範的名稱爲HTTP狀態管理機制。固然，不一樣的瀏覽器會以不一樣的方式進行存儲，但它們存儲的內容大體相同：
  • domain：域，通常爲域名。標識瀏覽器能夠將該Cookie發送出去的站點。
  • allh：標識域中全部主機是否均可以獲取Cookie。
  • path：域中Cookie相關的路徑前綴。控制了用戶在訪問哪些路徑下資源時，纔會發送該Cookie。
  • secure：是否只有在使用ssl鏈接時才發送該Cookie。
  • expiration：過時時間，從格林尼治標準時間開始的秒數。
  • name和value：Cookie的名字和值。
• Cookie的版本
  • Cookie0，也被稱爲Netscape cookies。 請求頭中的大體格式以下：

  Cookie: name1=value1[; name2=value2][; name3=value3]...
  複製代碼

  響應頭中的大體格式爲：

  Set-Cookie: name=value[; name2=value2][; name3=value3]...
  複製代碼

  上面格式中提到的name包含如下選項：

  強制：NAME
  可選：Expires、Domain、Path、Secure
  複製代碼

  • Cookie1 Cookie1版本引入了Set-Cookie2（響應首部）和Cookie2（請求首部）首部，能夠和版本0的系統相互操做。 響應頭中的大體格式爲：

    Set-Cookie2: name=value[; name2=value2][; name3=value3]...
    複製代碼

    上面格式中提到的name包含如下選項：

    強制：
    NAME，不能以$開頭
    Version，cookie的版本。如`Set-Cookie2: Version="1"`
    可選：
    Comment，說明服務器準備如何使用該Cookie。用戶能夠經過檢查此策略來肯定是否容許使用帶有該Cookie的會話。必須採用utf-8編碼。
    CommentURL，詳細描述Cookie策略及目的的文檔地址。
    Discard，若提供該屬性，表示客戶端在退出時放棄該Cookie。
    Domain，使用該Cookie的域名標識。
    Max-Age，生存週期，單位秒。客戶端根據使用期計算規則進行計算。計算的值大於該值時，該Cookie應該丟棄。
    Path，可使用該Cookie的路徑。
    Port，說明可使用Cookie的端口號，如：`Set-Cookie2：name="xx"; Port="80,81,82"`。若只有Port沒有值，說明只能向當前服務器端口提供Cookie。
    Secure，是否只有在使用ssl鏈接時才發送該Cookie。
    複製代碼

    請求頭中的大體格式以下：

    Cookie: name1=value1[; name2=value2][; name3=value3]...
    複製代碼

    在回傳匹配Cookie時，須要將其過濾器一同傳輸，並且保留的關鍵字須要以$開頭。
  • Cookie的版本協商 若服務器能理解Cookie2，就使用Cookie2版本。若客戶端從同一個服務器既得到了Set-Cookie首部又得到了Set-Cookie2首部，應該忽略老版本。 若客戶端支持兩個版本的Cookie，但從服務器得到的是版本0，就應該使用Cookie0發送。同時也應該發送Cookie2：$Version="1"告知服務器能夠進行升級。
• Cookie與會話跟蹤 服務器在合適時候對瀏覽器發送Cookie，並將瀏覽器重定向到另外一個URL，瀏覽器會在再次訪問時帶回Cookie，這樣服務器就能夠進行會話跟蹤。

結語

今天主要了解了服務器識別客戶端的相關手段. 但願你們也能有所收穫.

咱們在享受技術帶來的便利的同時，本身的隱私也在丟失。技術本是無罪的，只是某些人的心壞了。你是否也被上面的技術跟蹤了....

注

• 部分圖片來源於網絡，若有侵權，請告知。
• 若有錯誤，還請指出。共勉！
• 您的喜歡是最大的讚揚。