協議
簡單理解，計算機與計算機之間的通訊語言就叫做協議，不同的計算機之間只有使用相同的協議才能通信。所以網絡協議就是為計算機網絡中進行數據交換而建立的規則，標准或約定的集合。
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機制來達到保存標識的目的，但實際上它還有其他選擇