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

前言

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，這樣伺服器就可以進行會話跟蹤。

結語

今天主要了解了伺服器識別客戶端的相關手段. 希望大家也能有所收穫.

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

注

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