應用層——HTTP 協議

1. 概述

超文本傳送協議 HTTP 是一個應用層協議，HTTP 使用了面向連接的 TCP 作爲運輸層協議，保證了數據的可靠傳輸。 HTTP 不必考慮數據在傳輸過程中被丟棄後又怎樣被重傳。但是，HTTP 協議本身是無連接的。這就是說，雖然 HTTP 使用了 TCP 連接，但通信的雙方在交換 HTTP 報文之前不需要先建立 HTTP 連接。

HTTP 協議是無狀態的。也就是說，同一個客戶第二次訪問同一個服務器上的頁面時，服務器的響應與第一次被訪問時的相同（假定現在服務器還沒有把該頁面更新），因爲服務器並不記得曾經訪問過的這個客戶，也不記得爲該客戶曾經服務過多少次。 HTTP 的無狀態特性簡化了服務器的設計，使服務器更容易支持大量併發的 HTTP 請求。

請求一個萬維網文檔所需的時間是該文檔的傳輸時間（與文檔大小成正比）加上兩倍往返時間 RTT (一個 RTT 用於連接 TCP 連接，另一個 RTT 用於請求和接收萬維網文檔 ）。HTTP/1.1 協議使用了持續連接，萬維網服務器在發送響應後仍然在一段時間內保持這條連接，使同一個客戶（瀏覽器）和該服務器可以繼續在這條連接上傳送後續的 HTTP 請求報文和響應報文。

HTTP/1.1 協議的持續連接有兩種工作方式，即非流水線方式(without pipelining)和流水線方式(with pipelining) 。非流水線方式的特點，是客戶在收到前一個響應後才能發出下一個請求。因此，在 TCP 連接已建立後，客戶每訪問一次對象都要用去一個往返時間 RTT。流水線方式的特點，是客戶在收到 HTTP 的響應報文之前就能夠接着發送新的請求報文。於是一個接一個的請求報文到達服務器後，服務器就可連續發回響應報文。

2. HTTP 的報文結構

2.1 請求報文

CRLF 表示回車換行，回車表示光標回到本行開始，換行表示到達下一行。

舉例：

請求行：由 Method、URL、Version 三個字段組成，每個字段之間都有一個空格，爲了便於解析。

請求報文中常用的幾種方法：

• GET，用於請求服務器發送某個資源。
• HEAD，請求讀取資源的首部。使用 HEAD 可以在不獲取資源的情況下了解資源的情況；通過查看響應中的狀態碼，看看某個對象是否存在；通過查看首部，測試資源是否被修改（web 緩存服務器中常用）。
• PUT，向服務器上傳資源。
• POST，向服務器發送數據。通常用在 HTML 的表單提交。
• TRACE，用來進行環回測試的請求報文。TRACE 請求會在目的服務器端發起一個“環回”診斷。行程最後一站的服務器會彈回一條 TRACE 響應，並在目的響應主體中攜帶它收到的請求報文。這樣客戶端就可以查看在所有中間 HTTP 應用程序組成的請求/響應鏈上，原始報文是否，以及如何被損壞或修改。
• DELETE,刪除指明的 URL 所標誌的資源。
• OPTIONS，請求 Web 服務器告知其支持的各種功能。詢問服務器支持哪些方法，或者對某些特殊資源支持哪些方法。

多個首部字段構成如下：

• Accept：指定客戶端能夠接收的內容格式類型
• Accept-Language ：指定客戶端能夠接受的語言類型
• Accept-Ecoding ：指定客戶端能夠接受的編碼類型
• User-Agent ：用戶代理，向服務器說明自己的操作系統、瀏覽器等信息
• Connection：是否開啓持久連接（keepalive）。
• Host ：服務器域名

2.2 響應報文

舉例：

狀態行：用來說明服務器做了什麼，是否正確響應了。

響應首部字段：

• Server：服務器軟件名，Apache/Nginx
• Date：服務器發出響應報文的時間
• Last-Modified ：請求資源的最後的修改時間
• Content-Type ：文件類型信息

常見狀態碼：
狀態代碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別：

• 1xx：指示信息——表示請求已接收，繼續處理
• 2xx：成功——表示請求已被成功接收、理解、接受
• 3xx：重定向——要完成請求必須進行更進一步的操作
• 4xx：客戶端錯誤——請求有語法錯誤或請求無法實現
• 5xx：服務器端錯誤——服務器未能實現合法的請求

200 OK ：客戶端請求成功

301 Moved Permanently：永久重定向，該狀態碼錶示請求的資源已被分配了新的URL， 以後應使用資源現在所指的 URL。 也就是說， 如果已經把資源對應的 URL 保存爲書籤了， 這時應該按 Location 首部字段提示的 URL 重新保存。

302 Found：臨時性重定向，該狀態碼錶示請求的資源已被分配了新的URL， 希望用戶（本次） 能使用新的URL訪問。和 301 Moved Permanently 狀態碼相似， 但302狀態碼代表的資源不是被永久移動， 只是臨時性質的。 換句話說， 已移動的資源對應的URL將來還有可能發生改變。 比如， 用戶把URL保存成書籤， 但不會像301狀態碼出現時那樣去更新書籤， 而是仍舊保留返回302狀態碼的頁面對應的URL。

400 Bad Request ：客戶端請求有語法錯誤，不能被服務器所理解

401 Unauthorized ：請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用

403 Forbidden ：服務器收到請求，但是拒絕提供服務

404 Not Found ：請求資源不存在，eg：輸入了錯誤的 URL

500 Internal Server Error ：服務器發生不可預期的錯誤

503 Server Unavailable ：服務器當前不能處理客戶端的請求，一段時間後可能恢復正常。

3. cookie 和 session

Session是另一種記錄客戶狀態的機制。客戶端瀏覽器訪問服務器的時候，服務器把客戶端信息以某種形式記錄在服務器上。這就是Session。客戶端瀏覽器再次訪問時只需要從該Session中查找該客戶的狀態就可以了。

由於 HTTP 是一種無狀態的協議，服務器單從網絡連接上無從知道客戶身份。怎麼辦呢？就給客戶端們頒發一個通行證吧，每人一個，無論誰訪問都必須攜帶自己通行證。這樣服務器就能從通行證上確認客戶身份了。這就是Cookie的工作原理。Cookie 實際上是一小段的文本信息。客戶端請求服務器，如果服務器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie。客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該 Cookie 一同提交給服務器。服務器檢查該 Cookie，以此來辨認用戶狀態。服務器還可以根據需要修改 Cookie 的內容。

cookie 技術有四個組件：

• 在 HTTP 響應報文中的一個cookie 首部行；
• 在 HTTP 請求報文中的一個cookie 首部行；
• 在用戶端系統中保留有一個 cookie 文件，並由用戶的瀏覽器進行管理；
• 位於Web 站點的一個後端數據庫。

cookie 是實現 session 機制的一種方式。

4. HTTP 各版本特點以及 HTTPS

• HTTP/0.9：HTTP 協議的最初版本，功能簡陋，僅支持請求方式 GET，並且僅能請求訪問HTML格式的資源。
• HTTP/1.0：在0.9版本上做了進步，增加了請求方式 POST 和 HEAD；不再侷限於0.9版本的 HTML 格式，根據 Content-Type 可以支持多種數據格式，即 MIME 多用途互聯網郵件擴展，例如text/html、image/jpeg等；同時也開始支持 cache，就是當客戶端在規定時間內訪問統一網站，直接訪問 cache 即可。但是1.0版本的工作方式是每次TCP連接只能發送一個請求，當服務器響應後就會關閉這次連接，下一個請求需要再次建立TCP連接，就是不支持keepalive，這裏注意和http1.1比較。
• HTTP/1.1的特點：支持持續連接：持久連接稱爲 http-keepalive 功能，只有任意一方沒有提出斷開連接，那麼這條連接就保持，只要任意一端沒有明確提出斷開TCP連接，就一直保持連接，可以發送多次HTTP請求 。支持流水線方式：客戶在收到 HTTP 的響應報文之前就能夠接着發送新的請求報文。於是一個接一個的請求報文到達服務器後，服務器就可連續發回響應報文。
• HTTPS：http 都是使用明文通信的，非常不安全，HTTPS就是安全的HTTP，在http與傳輸層之間加上了一個SSL。HTTPS = HTTP+ 加密 + 認證 + 完整性保護。