HTTP 協議概述

HTTP–Hyper Text Transfer Protocol，超文字傳輸協議，是一種建立在TCP上的無狀態連線，整個基本的工作流程是客戶端傳送一個HTTP請求，說明客戶端想要訪問的資源和請求的動作，服務端收到請求之後，服務端開始處理請求，並根據請求做出相應的動作訪問伺服器資源，最後通過傳送HTTP響應把結果返回給客戶端。

HTTP協議是屬於TCP/IP協議簇的，所以先簡單介紹下與HTTP相關的TCP/IP知識。

TCP/IP協議簇

TCP/IP協議簇最重要的一個特性就是分層。TCP／IP協議簇按層次分別分為以下四層：應用層、傳輸層、網路層和資料鏈路層（OSI參考模型分為七層）。

• 應用層
  作用：應用層決定了向用戶提供應用服務時通訊的活動。eg. DNS、FTP、HTTP。
• 傳輸層
  作用：傳輸層對上層應用層，提供處於網路連線中的兩臺計算機之間的資料傳輸。eg. UDP、TCP。
• 網路層
  作用：網路層用來處理在網路上流動的資料包。資料包是網路傳輸的最小資料單位。該層規定了通過怎樣的路徑到達對方計算機，並把資料包傳給對方。
• 鏈路層
  作用：用來處理連線網路的硬體部分。包括控制作業系統、硬體的裝置驅動、NIC及光纖等物理可見部分。

HTTP關係密切的協議：IP、TCP和DNS

• 1、 負責傳輸的IP協議
  按層次分，IP位於網路層；
  IP協議的作用是把各種資料包傳送給對方，而要確保傳送到對方那裡，則需要滿足各類條件，其中兩個重要的條件是IP地址和MAC地址；
  IP間的通訊依賴MAC地址，採用ARP協議憑藉MAC地址進行通訊。

• 2、 確保可靠性的TCP協議
  按層次分，TCP位於傳輸層，提供可靠的位元組流服務
  所謂位元組流服務是指，為了方便傳輸，將大塊資料分割成以報文段為單位的資料包進行管理。而可靠的傳輸服務是指，能夠把資料準確可靠地傳給對方。
  一言以蔽之，TCP協議為了更容易傳送大資料才把資料分割，而且TCP協議能夠確認資料是否送達到對方。

• 3 、負責域名解析的DNS服務
  DNS同HTTP協議一樣位於應用層，提供域名到IP地址之間的解析服務。

各種協議與HTTP協議的關係

HTTP在傳送請求時，如果請求的地址寫的是域名，則先訪問DNS伺服器獲取目標伺服器的IP地址，
然後生成HTTP請求報文，傳送給TCP層,按照TCP/IP通訊傳輸流傳輸給目標伺服器。
 

URI 和 URL

URI 是uniform resource identifier，統一資源識別符號，用來唯一的標識一個資源
Web上可用的每種資源如HTML文件、影象、視訊片段、程式等都是一個來URI來定位的
URI一般由三部組成：

• 訪問資源的命名機制
• 存放資源的主機名
• 資源自身的名稱，由路徑表示，著重強調於資源。

URL 是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明瞭如何locate這個資源
URL是Internet上用來描述資訊資源的字串，主要用在各種WWW客戶程式和伺服器程式上，特別是著名的Mosaic。
採用URL可以用一種統一的格式來描述各種資訊資源，包括檔案、伺服器的地址和目錄等。URL一般由三部組成：

• 協議(或稱為服務方式)
• 存有該資源的主機IP地址(有時也包括埠號)
• 主機資源的具體地址。如目錄和檔名等

URI 和 URL 之間的關係
URI用字串標識某一網際網路資源，而URL表示資源的地址（網際網路上所處的位置），可見是URI的子集。
URL是一種具體的URI，它不僅唯一標識資源，而且還提供了定位該資源的資訊。URI是一種語義上的抽象概念，可以是絕對的，也可以是相對的，而URL則必須提供足夠的資訊來定位，所以，是絕對的，而通常說的relative URL，則是針對另一個absolute URL，本質上還是絕對的。

HTTP 請求

HTTP請求由狀態行、請求頭、請求正文三部分組成：

狀態行：包括請求方式Method、資源路徑URL、協議版本Version；
請求頭：包括一些訪問的域名、使用者代理、Cookie等資訊；
請求正文：就是HTTP請求的資料。

根據HTTP標準，HTTP請求可以使用多種請求方法。
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

• GET 請求指定的頁面資訊，並返回實體主體。
• HEAD 類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
• POST 向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
• PUT 從客戶端向伺服器傳送的資料取代指定的文件的內容。
• DELETE 請求伺服器刪除指定的頁面。
• CONNECT HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。
• OPTIONS 允許客戶端檢視伺服器的效能。
• TRACE 回顯伺服器收到的請求，主要用於測試或診斷。

持久連線節省通訊量

在HTTP協議的初始版本中，每進行一次HTTP通訊就要斷開一次TCP連線。
假設這樣的一個應用場景：使用瀏覽器請求一個包含多張圖片的HTML頁面時，在傳送請求訪問HTML頁面資源的同時，也會請求該HTML裡面包含的其他資源。因此，每次的請求都會造成無謂的TCP連線建立和斷開，增加通訊量的開銷。

為了解決上述TCP連線的問題，HTTP想出了持久連線（HTTP keep-alive）的方法。持久連線的特點是：只要任意一端沒有明確提出斷開連線，則保持TCP連線狀態。
管線化 持久連線使得多數請求以管線化方式傳送成為可能。從前傳送請求後需要等待並收到響應後，才能傳送下一個請求。管線化技術出現後，不用等待響應亦可直接傳送下一個請求，這樣就能夠同時並行傳送多個請求，而不需要一個接一個地等待響應了。

HTTP 響應

伺服器收到了客戶端發來的HTTP請求後，根據HTTP請求中的動作要求，服務端做出具體的動作，將結果迴應給客戶端，稱為HTTP響應。

HTTP響應也由三部分組成：狀態行、響應頭、響應正文；

狀態行：包括協議版本Version、狀態碼Status Code、迴應短語；
響應頭：包括搭建伺服器的軟體，傳送響應的時間，迴應資料的格式等資訊；
響應正文：就是響應的具體資料。

一般我們程式設計師比較關注的狀態碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：

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

與HTTP協作的Web伺服器

用單臺虛擬主機實現多個域名
一臺Web伺服器可搭建多個獨立域名的Web網站，也可作為通訊路徑上的中轉伺服器提升傳輸效率。如果我們在一臺伺服器上託管了兩個域名，當收到請求時就需要弄清楚究竟要訪問哪個域名，因此必須在Host首部內完整指定主機名或域名的URI。

通訊資料轉發程式：代理、閘道器、隧道
HTTP通訊時，除客戶端和伺服器以外，還有一些用於通訊資料轉發的 應用程式和伺服器，例如代理、閘道器和隧道，它們可以配合伺服器工作。這些應用程式和伺服器可以將請求轉發給通訊線路上的下一站伺服器，並且能接收伺服器返回的響應並轉發給客戶端。

• 代理: 是一種有轉發功能的應用程式
  代理伺服器的基本行為就是接收客戶端傳送的請求後轉發給其他伺服器。代理不改變請求URI ，會直接轉發給前方持有資源的目標伺服器。
  使用代理伺服器的理由：利用快取技術減少網路頻寬的流量。
  代理有多種使用方法，按兩種基準分類。一類是 是否使用快取 ，另一種是 是否會修改報文 。
  1)快取代理：代理轉發響應時，快取代理會預先將資源的副本儲存在代理伺服器上，下次請求相同的資源時，則將之前快取的資源作為響應返回。
  2)透明代理：轉發請求或響應時，不對報文做任何加工的代理型別被稱為透明代理，否則稱為非透明代理。

• 閘道器: 是轉發其他伺服器通訊資料的伺服器
  利用閘道器可以由HTTP請求轉化為其他協議通訊。
  閘道器的工作機制和代理十分相似，而閘道器能使通訊線路上的伺服器提供非HTTP協議服務。

• 隧道: 是在相隔甚遠的客戶端和伺服器兩者之間進行中轉，並保持雙方通訊連線的應用程式。
  隧道可按要求建立起一條與其他伺服器的通訊線路，屆時使用SSL等加密手段進行通訊。隧道的目的是確保確保能與伺服器進行安全通訊，隧道本身不會解析HTTP請求，請求保持原樣中轉給之後的伺服器。

• 儲存資源的快取
  利用快取可減少對源伺服器的訪問，可以節省通訊流量和通訊時間。
  使用快取的時候，要注意快取的有效期限，確保我們發起請求獲取的是最新的資料資源。

確保Web安全的HTTPS

通過上面的分析，我們瞭解到HTTP具有相當優秀和方便的一面，然而，HTTP並非只有好的一面，事物皆具兩面性，主要存在以下幾點不足：

通訊使用明文（不加密），內容可能會被竊聽
不驗證通訊方的身份，因此有可能遭遇偽裝
無法證明報文的完整性，所以有可能已遭篡改
HTTP＋加密＋認證＋完整性保護＝HTTPS
HTTPS並非是應用層的一種新協議。只是HTTP通訊介面部分用SSL和TSL協議代替而已，通常，HTTP直接和TCP通訊，當使用SSL時，則演變成先和SSL通訊，再由SSL和TCP通訊了。簡言之，所謂HTTPS其實就是身披SSL協議這層外殼的HTTP。
當採用SSL後，HTTP就擁有了HTTPS的加密、證書和完整性保護這些功能。而且SSL協議是獨立於HTTP的協議，所以不光是HTTP協議，其他執行在應用層的SMTP和Telnet等協議均可配合SSL協議使用。可以說SSL是當今世界上應用最為廣泛的網路安全技術。

在講解SSL之前我們需要首先了解一下加密方法，加密分為對稱加密和非對稱加密。HTTPS協議則是採用的兩者混合的實現方式，為什麼要結合兩種的實現方式呢？這是因為它們都各自存在自己的優缺點。對於對稱加密來說，金鑰的傳輸交換是不安全的，但是效率比較高，而對於非對稱加密，是不用擔心傳輸的金鑰安全性的問題的，因為我們傳遞的是公開金鑰，任何人都可以獲得，但是缺點是效率比較低。

名詞解釋
OSI七層網路模型：OSI七層網路模型

HTTP：HTTP屬於應用層協議，在傳輸層使用TCP協議，在網路層使用IP協議。IP協議主要解決網路路由和定址問題，TCP協議主要解決如何在IP層之上可靠的傳遞資料包，使在網路上的另一端收到發端發出的所有包，並且順序與發出順序一致。

Socket：Socket是一組程式設計介面（API）。介於傳輸層和應用層，嚮應用層提供統一的程式設計介面。使得應用層不必瞭解TCP/IP協議細節便直接通過對Socket介面函式的呼叫完成資料在IP網路的傳輸。Socket基於傳輸層差異，可以分為四種類型：基於TCP的Socket、基於UDP的Socket、基於RawIp的Socket、基於鏈路層的Socket。HTTP使用的是基於TCP的Socket。

TCP建立連線時需要三次握手，在釋放連線需要四次揮手；
連線建立的三次握手的過程如下：

第一次握手：客戶端傳送syn包（syn=j）到伺服器，並進入SYN_SENT狀態，等待伺服器確認；
第二次握手：伺服器收到syn包，並會確認客戶的SYN（ack=j+1），同時自己也傳送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
第三次握手：客戶端收到伺服器的SYN+ACK包，向伺服器傳送確認包ACK(ack=k+1），此包傳送完畢，客戶端和伺服器進入ESTABLISHED（TCP連線成功）狀態，完成三次握手。

TCP釋放連線的四次揮手模型：