協議決議

協議基礎

自定制協議：程式員自己定制的協議

應用層協議：如何將多個資料物件組織成為一個二進制資料串進行傳輸

需要考慮傳輸性能和決議性能，決議性能高的不一定傳輸性能高

比如：struct {int num1，int num2，char op} 決議方便但由于占用記憶體大導致傳輸性能較低

序列化

序列化：將多個資料物件按照指定協議進行組織實作持久化存盤或者網路通信傳輸的二進制資料串的程序

反序列化：按照指定協議將二進制資料串決議得到各個資料物件的程序

典型序列化方式：結構體序列化，json序列化，protobuf序列化

HTTP協議

http協議：超文本傳輸協議，明文字串傳輸協議

https協議：加密之后的http協議，安全性更高

http協議在傳輸層基于tcp協議實作，是一個簡單的請求-回應協議

http協議格式（也稱為：http協議資料結構）

首行：請求行回應行（對于請求和回應的簡單關鍵描述）

請求行：請求方法 URL 協議版本\r\n

（1）請求方法：

GET：向服務器獲取物體資源（包含正文），也可以提交資料但由于提交程序中沒有正文所以提交資料沒有在正文而在URL中 注意：（1）get提交資料在url中，不安全（2）url長度有限制導致提交資料有限制
HEAD:向服務器僅獲取回應頭部，不要正文物體
POST:向服務器提交資料，提交有正文，提交資料放在正文中

1	PUT	從客戶端向服務器傳送的資料取代指定的檔案的內容，
2	DELETE	請求服務器洗掉指定的頁面，
3	CONNECT	HTTP/1.1 協議中預留給能夠將連接改為管道方式的代理服務器，
4	OPTIONS	允許客戶端查看服務器的性能，
5	TRACE	回顯服務器收到的請求，主要用于測驗或診斷，
6	PATCH	是對 PUT 方法的補充，用來對已知資源進行區域更新，

（2）URL：（網址）統一資源定位符，用于定位網路中某個主機上的資源

組成：協議名稱://用戶名：密碼@域名：埠/資源路徑？查詢字串資料#片段識別符號

http服務默認使用80埠 https服務默認使用443埠
查詢字串：提交給服務器的資料，由一個個key=value鍵值對組成，鍵值對之間以&符號間隔
urlencode：編碼目的：用戶請求的資源路徑或查詢字串中存在特殊字符，可能與url特殊字符沖突

編碼方法：將特殊字符每個位元組（8bit）轉換為16進制數字字符，并前綴% eg: '+' %2B

urldecode：解碼

解碼方法：遇到%，則認為緊隨其后的兩個字符進行解碼，將兩個字符轉換為數字（16進制轉10進制）

片段識別符號：定位網頁位置

（3）協議版本

0.9：最早期版本，只支持GET方法，支持超文本資料傳輸，沒有規范http協議格式

1.0：規范了http協議格式，新增支持GET,HEAD,POST請求方法，支持各種多媒體資源傳輸，簡單緩沖控制

1.1：支持更多請求方法，對1.0進行性能提升，支持長連接（connection：keep-alive）

2.0：重新定義http協議 1，二進制資料傳輸 2，支持主動推送資源 3，服務器長連接回應，不需要按序進行，解決隊頭阻塞問題

回應行：協議版本回應狀態碼狀態碼描述

回應狀態碼：直觀向客戶端反映處理結果

HTTP狀態碼分類
分類	分類描述
1**	一些描述資訊，服務器收到請求，需要請求者繼續執行操作
2**	成功，操作被成功接收并正確處理
3**	重定向，需要進一步的操作以完成請求，表示本次請求的資源移到新的鏈接處，原鏈接依然可用
4**	客戶端錯誤，請求包含語法錯誤或無法完成請求
5**	服務器錯誤，服務器在處理請求的程序中發生了錯誤

狀態碼	狀態碼描述	中文描述
100	Continue	繼續，客戶端應繼續其請求
101	Switching Protocols	切換協議，服務器根據客戶端的請求切換協議，只能切換到更高級的協議，例如，切換到HTTP的新版本協議

200	OK	請求成功，一般用于GET與POST請求
201	Created	已創建，成功請求并創建了新的資源
202	Accepted	已接受，已經接受請求，但未處理完成
203	Non-Authoritative Information	非授權資訊，請求成功，但回傳的meta資訊不在原始的服務器，而是一個副本
204	No Content	無內容，服務器成功處理，但未回傳內容，在未更新網頁的情況下，可確保瀏覽器繼續顯示當前檔案
205	Reset Content	重置內容，服務器處理成功，用戶終端（例如：瀏覽器）應重置檔案視圖，可通過此回傳碼清除瀏覽器的表單域
206	Partial Content	部分內容，服務器成功處理了部分GET請求，eg：斷點續傳

300	Multiple Choices	多種選擇，請求的資源可包括多個位置，相應可回傳一個資源特征與地址的串列用于用戶終端（例如：瀏覽器）選擇
301	Moved Permanently	永久移動，請求的資源已被永久的移動到新URI，回傳資訊會包括新的URI，瀏覽器會自動定向到新URI，今后任何新的請求都應使用新的URI代替
302	Found	臨時移動，與301類似，但資源只是臨時被移動，客戶端應繼續使用原有URI
303	See Other	查看其它地址，與301類似，使用GET和POST請求查看
304	Not Modified	未修改，所請求的資源未修改，服務器回傳此狀態碼時，不會回傳任何資源，客戶端通常會快取訪問過的資源，通過提供一個頭資訊指出客戶端希望只回傳在指定日期之后修改的資源
305	Use Proxy	使用代理，所請求的資源必須通過代理訪問
306	Unused	已經被廢棄的HTTP狀態碼
307	Temporary Redirect	臨時重定向，與302類似，使用GET請求重定向

400	Bad Request	客戶端請求的語法錯誤，服務器無法理解
401	Unauthorized	請求要求用戶的身份認證
402	Payment Required	保留，將來使用
403	Forbidden	服務器理解請求客戶端的請求，但是拒絕執行此請求
404	Not Found	服務器無法根據客戶端的請求找到資源（網頁），通過此代碼，網站設計人員可設定"您所請求的資源無法找到"的個性頁面
405	Method Not Allowed	客戶端請求中的方法被禁止
406	Not Acceptable	服務器無法根據客戶端請求的內容特性完成請求
407	Proxy Authentication Required	請求要求代理的身份認證，與401類似，但請求者應當使用代理進行授權
408	Request Time-out	服務器等待客戶端發送的請求時間過長，超時
409	Conflict	服務器完成客戶端的 PUT 請求時可能回傳此代碼，服務器處理請求時發生了沖突
410	Gone	客戶端請求的資源已經不存在，410不同于404，如果資源以前有現在被永久洗掉了可使用410代碼，網站設計人員可通過301代碼指定資源的新位置
411	Length Required	服務器無法處理客戶端發送的不帶Content-Length的請求資訊
412	Precondition Failed	客戶端請求資訊的先決條件錯誤
413	Request Entity Too Large	由于請求的物體過大，服務器無法處理，因此拒絕請求，為防止客戶端的連續請求，服務器可能會關閉連接，如果只是服務器暫時無法處理，則會包含一個Retry-After的回應資訊
414	Request-URI Too Large	請求的URI過長（URI通常為網址），服務器無法處理
415	Unsupported Media Type	服務器無法處理請求附帶的媒體格式
416	Requested range not satisfiable	客戶端請求的范圍無效
417	Expectation Failed	服務器無法滿足Expect的請求頭資訊

500	Internal Server Error	服務器內部錯誤，無法完成請求
501	Not Implemented	服務器不支持請求的功能，無法完成請求
502	Bad Gateway	作為網關或者代理作業的服務器嘗試執行請求時，從遠程服務器接收到了一個無效的回應，連接建立失敗
503	Service Unavailable	由于超載或系統維護，服務器暫時的無法處理客戶端的請求，延時的長度可包含在服務器的Retry-After頭資訊中
504	Gateway Time-out	充當網關或代理的服務器，未及時從遠端服務器獲取請求，回應延遲
505	HTTP Version not supported	服務器不支持請求的HTTP協議的版本，無法完成處理

頭部：對于請求或回應或正文的一些關鍵描述（由一個個key：value鍵值對組成，每個鍵值對以\r\n結尾）

典型頭部欄位：

Connection	長短連接控制	keep-alive/close
Referer	記錄本次請求的來源連接
Content-Type	表示正文資料格式
Content-Length	表示正文資料長度	解決粘包問題
cookie /session	請求頭cookie 回應頭session

cookie：

一個客戶端登錄之后，服務端驗證登錄，成功后，通過set-cookie設定cookie資訊回傳給客戶端

客戶端接收到回應后，將set-cookie欄位的cookie資訊保存起來，下次請求服務器直接從cookie檔案中讀取出cookie資訊，通過cookie欄位發送給服務器

cookie是一個維護http通信狀態的技術，但存在安全隱患

解決方法：session

服務端針對每個客戶端建立會話當客戶端登錄成功后，創建會話，在會話中記錄客戶端用戶資訊及狀態等資訊通過set-cookie欄位將session-id回傳給客戶端

session-id每次請求都會發生變化，并且用戶的隱私資訊一直保存在服務器中，防止泄露

cookie和session區別：

cookie是維護http通信狀態的技術，將關鍵資訊保存在客戶端，每次請求服務器時，讀取出來發送給服務端，此程序中將關鍵資訊保存在cookie欄位中進行傳輸

session是解決cookie安全隱患，將關鍵資訊保存在服務端，通過創建會話后，而只將session-id回傳給客戶端，客戶端作為cookie欄位保存，再次請求程序中只是將session-id資訊保存在cookie欄位中進行傳輸，而非直接傳輸用戶資訊，安全性相比較于cookie提高

空行：\r\n 間隔頭部與正文
正文：客戶端提交給服務端，或者服務端回應給客戶端的資料

簡單的http服務器的搭建:

1.搭建tcp服務端
⒉獲取新建連接
3.使用新建連接，等待接收資料(http協議的請求資料)
4.接收程序:先接收http頭部，決議頭部-Content-Length確定正文長度5.接收指定長度的正文
6.根據請求方法以及資源路徑確定客戶端的請求目的7.進行具體對應的業務處理
8.組織http協議格式的回應資料，對客戶端進行回復
9.如果是短連接，則直接關閉套接字，如果是長連接，則繼續等待接收資料

代碼如下：