協議

簡單理解，計算機與計算機之間的通訊語言就叫做協議，不同的計算機之間只有使用相同的協議才能通訊。所以網路協議就是為計算機網路中進行資料交換而建立的規則，標準或約定的集合。

OSI模型

1978年國際化標準組織提出了“開放系統網際網路參考模型”，即著名的OSI模型。它將計算機網路體系結構的通訊協議劃分為7層，自上而下分別是：物理層，資料鏈路層，網路層，傳輸層，會話層，表示層，應用層。(7層網路預設具體是什麼自行百度)

那麼們的今天的主題HTTP協議就在應用層，也是應用層使用最多的協議

HTTP

超文字傳輸協議，是一種分散式，協作式的，面向應用層的超媒體資訊系統。它是一種通用的，無狀態的協議。

原理

HTTP協議工作於客戶端與伺服器的架構上，客戶端通過URL向伺服器傳送所有的請求。伺服器根據接收到的請求，向客戶端傳送響應資訊。HTTP協議定義客戶端如何向伺服器傳送請求，以及伺服器如何將響應請求傳送給客戶端，所以HTTP請求協議採用了請求/響應模型

客戶端

客戶端主要有兩個職能

1.向伺服器傳送請求

2.接收伺服器返回的報文並解釋成友善的資訊供我們閱讀

客戶端大概有：瀏覽器，應用程式等

如今時代我們可能使用最多的就是瀏覽器， 當用戶在位址列輸入網址回車時，瀏覽器會為什麼做如下處理：

1.解析協議和域名

2.使用HTTP協議並建立請求報文向服務端傳送請求

3.接收伺服器返回的內容並展示給客戶

服務端

伺服器端在接收到客戶端傳送的請求後會開始處理請求

伺服器處理過程如下

伺服器軟體一直在監聽埠是否有新的請求達到，如iis或者tomcat在建立web站點後，預設會一直監聽80埠等待HTTP請求到達伺服器。

1.建立連線：如果客戶端已經開啟一條道伺服器的持久連線，則可以直接使用，否則客戶端需要在伺服器開啟一條新的連線

2.接收請求報文：連線上有資料到時，web伺服器會從網路連線中讀取資料，並將請求報文中的內容解析出來

3.處理請求：當請求被接收後，伺服器便可以根據請求報文進行處理了。例如post方法中提出報文主體的資料並插入到資料庫中

4.訪問資源：請求處理完後，比如web會根據資料生成一系列的HTML頁面或圖片等資訊，此步驟將訪問這些儲存在伺服器上的物理檔案

5.構建響應：web伺服器在識別資源後，構造響應報文，響應報文包括：狀態碼，響應頭，響應主體等內容

6.傳送響應：伺服器將響應的資料傳送給客戶端機器

7.記錄日誌：請求結束，伺服器會在日誌檔案中記錄一條請求日誌

大家都知道瀏覽器想客戶端傳送請求是通過URL地址傳遞的，那麼接下來我們看一下URL的組成

URL

例項URL：https://i.cnblogs.com/EditPosts.aspx?postid=10913098&update=1#name

組成

URL主要有以下幾個部分組成

1.協議部分

該URL的協議為HTTP

2.域名部分

該URL的域名部分為/www.kath2.com， URL中也可以使用ip地址作為域名

3.埠部分

埠部分跟在域名：後面，如果沒有，那麼說明URL使用的是預設埠80，埠不是URL的必須組成部分

4.虛擬目錄部分

從域名後的第一個/到最後一個/之間的部分，虛擬目錄也不是URL的必須組成部分

5.檔名部分

最後一個/到？號為止，是檔名部分。如果沒有？號，則到#號為止，如果沒有？和#號，則從域名最後/開始到結束都是檔名部分，示例中的檔名部分為EditPosts.aspx

6.錨部分

從#號到最後

7.引數部分

從？號開始到#號結束， 多個引數使用&號分割

報文

客戶端與伺服器之間的資訊傳遞使用的載體叫做報文，報文分為請求和響應兩個部分

請求報文

客戶端傳送資料給伺服器的過程叫做請求

組成

請求報文分為4個部分

1.請求首行

包含請求方法，要訪問的資源以及所舒勇的HTTP版本

2.請求頭部

說明伺服器要使用的附加資訊

3.空行

請求報文頭部後的空行是必須的

4.請求體

get往往不存在請求體，post請求體包含請求的引數

格式

例項

get請求例項

post請求例項

請求方法

主要請求方法有get，post，put，delete等

get請求

1.從伺服器獲取資料，返回響應的實體部分，可以類比資料庫的select操作，不會影響資料庫本身

2.沒有請求體

3.請求引數附在URL後，以？號開始，多個引數使用&分割

4.通常對資料不敏感的請求使用get請求，因為引數跟在URL後不安全

5.傳輸的引數長度是有限制的

post請求

1.向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。

2.通常post請求含有請求體

3.請求引數存放在請求體中，可以是任意格式

4.相對來說資料比較安全

5.請求資料無大小限制，可以認為是無限制

其他請求不做介紹

響應報文

客戶端傳送請求到伺服器，伺服器處理之後返回資料給客戶端的過程叫做響應

組成

響應報文同樣包含了4個部分

1.響應首行

協議版本，狀態碼，成功與失敗的狀態資訊

2.響應頭部

用來說明客戶端要使用的一些附加資訊

3.空行

響應報文頭部後的空行是必須的

4.響應資料

返回給客戶端的資料等資訊

格式

例項

get響應例項

 post響應例項

響應狀態碼

HTTP擴充套件

Cookie機制

Cookie是什麼？

大家都知道我們登入一個網站的時候，在輸入帳號和密碼的時候下面經常會看到一個“記住我”的選項，那麼只要我們勾選了這個選項，再次登入的時候就無需再輸入帳號和密碼即可登入網站，那麼這種方法就是通過Cookie機制實現的。用來記錄使用者的狀態和使用者的身份

Cookie是由伺服器發給客戶端的特殊資訊，而這些資訊，以文字檔案的方式存在客戶端，然後客戶端每次向伺服器傳送請求的時候就會帶上這些特殊資訊，以便伺服器做身份識別

Cookie處理過程

當用戶第一次請求伺服器時，請求報文中並不會包含Cookie資訊，當伺服器接收到客戶端的請求時，會響應資訊給客戶端，這時候響應報文的頭部會包含一個set-Cookie的欄位資訊，幷包含了使用者的身份資訊。當客戶端收到set-Cookie時，會把Cookie儲存在本地（記憶體或者硬碟中）

當客戶端再次傳送請求報文給伺服器時，請求報文頭部會攜帶Cookie資訊併發送給伺服器，伺服器通過Cookie自帶的資訊分析，動態生成與該客戶端相對應的資料。

例項

第一次訪問

http://120.78.128.25:8765網站，我們使用Fiddler抓取請求此網站首頁的請求報文和響應報文

可以看到第一次請求次網站時，請求報文是不含有Cookie資訊的，而響應報文返回一個set-Cookie給客戶端

第二次訪問

第二次請求的報文和響應報文，我們可以看到已經發生了變化

請求報文已經攜帶了Cookie資訊， 而響應報文不再攜帶set-Cookie資訊

所以說只要我們不清楚cookie資訊，那麼以後有效時間內，我們都可以直接訪問這個網站

Session機制

Session是什麼？

Session是另外一種記錄客戶狀態和身份的機制，不同的是Cookie儲存在客戶端本地中， 而Session儲存在伺服器中

與Cookie機制作用相同，只不過Cookie是通過檢查客戶身上的通行證確定客戶身份，而Session則是通過伺服器上的客戶明細表來確認客戶身份

Session處理過程

當客戶端第一次請求伺服器時，伺服器會建立一個Session併為該Session分配唯一標識Session id，並向Session中新增內容，伺服器收到客戶的請求後，會返回給客戶端響應的資訊，那麼響應報文頭部會攜帶Session id返回給客戶端

當客戶端再次請求伺服器時，請求報文頭部會攜帶之前的Session id(session id 是需要通過cookie傳遞)， 伺服器收到請求後根據Session id查詢對應的session內容， 並分析對比是否為同一個客戶端發來的請求，接著返回相應的資料給客戶端

區別

最後我們通過一個生活中的例項來深入理解二者的區別

筆者曾經常去的一家咖啡店有喝5杯咖啡免費贈一杯咖啡的優惠，然而一次性消費5杯咖啡的機會微乎其微，這時就需要某種方式來紀錄某位顧客的消費數量。想象一下其實也無外乎下面的幾種方案： 

    1、該店的店員很厲害，能記住每位顧客的消費數量，只要顧客一走進咖啡店，店員就知道該怎麼對待了。這種做法就是協議本身支援狀態。 

    2、發給顧客一張卡片，上面記錄著消費的數量，一般還有個有效期限。每次消費時，如果顧客出示這張卡片，則此次消費就會與以前或以後的消費相聯絡起來。這種做法就是在客戶端保持狀態。 

    3、發給顧客一張會員卡，除了卡號之外什麼資訊也不紀錄，每次消費時，如果顧客出示該卡片，則店員在店裡的紀錄本上找到這個卡號對應的紀錄新增一些消費資訊。這種做法就是在伺服器端保持狀態。

由於HTTP協議是無狀態的，而出於種種考慮也不希望使之成為有狀態的，因此，後面兩種方案就成為現實的選擇。具體來說cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在伺服器端保持狀態的方案。同時我們也看到，由於採用伺服器端保持狀態的方案在客戶端也需要儲存一個標識，所以session機制可能需要藉助於cookie機制來達到儲存標識的目的，但實際上它還有其他