針對TCP/IP四層模型中各層的典型協定進行解析
應用層：應用層負責應用程式之間的溝通---程式員自己定義資料的組織格式
應用層協定：如何将多個資料對象組織成為一個二進制資料串進行傳輸（自定制協定---程式員自己定制的資料格式；知名協定---HTTP）
自定制協定：程式員自定制資料格式，定制的同時需要考慮傳輸性能、解析性能以及調試便捷性，如何組織更加适用目前的應用場景。
序列化：将資料對象按照指定協定進行組織實作持久化存儲或者網絡通信傳輸的二進制資料串的過程
反序列化：按照指定協定，将二進制資料串解析得到各個資料對象的過程
序列化方式：結構體二進制序列化，json，protobuf...
HTTP協定：超文本傳輸協定---html、xml...
前情資訊：http是一個明文字元串傳輸協定；http在傳輸層基于tcp協定實作；http是一個簡單的請求-響應協定
http協定格式（http資料結構，http協定實作）：
首行：請求行、響應行（對于請求與響應的簡單關鍵描述）
頭部：對于請求或響應或正文的一些關鍵描述，由一個個鍵值對組成---key:val，每個鍵值對以\r\n結尾
空行：\r\n，間隔頭部與正文；\r\n\r\n---頭部結尾
正文：用戶端送出給服務端，或者服務端響應給用戶端的資料
首行-請求行：請求方法，URL（URI），協定版本\r\n
請求方法：
GET：從服務端擷取實體資源，要求伺服器傳回一個完整的實體資源；請求沒有正文，也可以送出資料，但是送出的資料沒有在正文中而是在URL中（GET送出資料不安全，URL長度有限制）
HEAD：從服務端擷取實體資源，功能與GET類似，但是響應時不傳回正文實體，隻要頭部資訊
POST：向服務端送出資料，請求有正文，資料放在正文中
URL：網址---統一資源定位符（用于定位網絡中某個主機上的某個資源）；URI：統一資源辨別符
組成：協定名稱://使用者名:密碼@域名:端口/資源路徑?查詢字元串#片段表示符
域名：伺服器的别名---最終通路伺服器需要經過域名解析得到伺服器IP
資源路徑：這個路徑是一個相對根目錄
查詢字元串：送出給伺服器的資料，由一個個key=val形式的鍵值對組成，鍵值對之間以&符号作為間隔
urlencode：編碼-使用者請求的資源路徑，或者查詢字元串中存在特殊字元，則有可能與url中的特殊字元沖突。是以需要将特殊字元每個位元組轉換為16進制數字字元，并字首%（+ -> %2b）
urldecode：解碼-遇到%則認為緊随其後的兩個字元進行了編碼，将這兩個字元轉換為數字，第一個數字左移4位加上第二個數字
協定版本：0.9，1.0，1.1，2
0.9：最早期的版本，隻支援GET方法，并且協定還沒有目前的規範，隻支援超文本資料傳輸
1.0：規範了http協定格式，并且新增支援GET，HEAD，POST請求方法，支援各種多媒體資源傳輸，簡單的緩存控制
1.1：更多的是對1.0版本進行性能的優化，支援了更多請求方法以及特性（支援長連接配接，更加完善的緩存控制，分塊傳輸...），但是依然存在缺陷，比如管線化傳輸的隊頭阻塞問題
2.0：因為http協定的龐大備援，是以2.0不是新增特性，而是重新定義http協定（使用二進制資料傳輸；支援主動推送資源；伺服器進行長連接配接響應，不需要按序進行解決隊頭阻塞...）
首行-響應行：協定版本，響應狀态碼，狀态碼描述\r\n
響應狀态碼：直覺的向用戶端回報處理結果
1xx：一些描述資訊，101-協定切換狀态碼
2xx：表示本次請求正确處理，200-請求成功
3xx：重定向-表示本次請求的資源移動到了新的連結處，但是原連結依然可用，301-永久移動 / 302-臨時移動
4xx：表示用戶端錯誤，404-服務端無法根據用戶端的請求找到資源（網頁）
5xx：表示伺服器錯誤，502-代理伺服器沒有收到正确響應，504-逾時
狀态碼描述：就是針對狀态的文字描述
頭部：關于請求或者響應，或者正文的一些描述字段
組成：key:val\r\nkey:val\r\n
典型頭部字段：
Connection：長短連接配接控制（keep-alive / close）
Referer：記錄本次請求的來源連接配接
Content-Type：用于表示正文的資料格式
Content-Length：用于表示正文的長度-http解決粘包問題的關鍵字段
Location：用于指定重定向的新連結位址，與3xx搭配使用
cookie與session：涉及的頭部字段請求頭Cookie，響應頭Set-Cookie
http是一個無狀态協定
（1）一個用戶端登入之後，服務端驗證登入，成功後通過Set-Cookie字段設定cookie資訊（使用者資訊，狀态...）傳回給用戶端
（2）用戶端收到響應後，将Set-Cookie字段的cookie資訊儲存起來，下次請求伺服器的時候從cookie檔案中讀取出cookie資訊，通過Cookie字段發送給伺服器
cookie是一個維護http通信狀态的技術，但是存在安全隐患
解決方案：session
session是服務端針對每個用戶端所建立的會話，當用戶端登陸成功後，建立會話，在會話中記錄用戶端使用者資訊及狀态...，通過Set-Cookie字段将session_id傳回給用戶端
session_id每次請求都會發生變化，并且使用者的隐私資訊一直儲存在伺服器上防止洩漏
cookie與session的差別：
cookie是維護http通信狀态的技術，将關鍵資訊儲存在用戶端，每次請求伺服器時，讀取出來發送給服務端（有安全隐患）
session是解決cookie安全隐患的技術，将關鍵資訊儲存在伺服器，将session_id發送給用戶端，作為cookie儲存起來，往後請求傳輸session_id即可，解決了cookie洩密的風險
空行：\r\n
是與頭部最後一個字段的結尾\r\n組成連續的\r\n\r\n作為特殊标志作為http頭部結尾的标志
正文
http是一個應用層協定，隻是應用程式如何溝通的一種資料格式約定，在傳輸層是基于tcp實作的
http用戶端實際上就是一個tcp用戶端，http伺服器實際上就是一個tcp服務端，隻不過http用戶端與服務端的通信使用的是http協定來約定資料格式而已
簡單的http伺服器的搭建：
（1）搭建tcp服務端
（2）擷取建立連接配接
（3）使用建立連接配接，等待接收資料（http協定的請求資料）
（4）接收過程：先接收http頭部，解析頭部（Content-Length确定正文長度）
（5）接收指定長度的正文
（6）根據請求方法以及資源路徑确定用戶端的請求目的
（7）進行具體對應的業務處理
（8）組織http協定格式的響應資料，對用戶端進行回複
（9）如果是短連接配接，則直接關閉套接字；如果是長連接配接，則繼續等待接收資料
注意：http伺服器編寫完畢之後
虛拟機記得關閉防火牆：sudo systemctl stop firewalld
雲伺服器：記得設定安全組政策，開啟對應端口
HTTPS協定：并不是一個新的協定，而是在HTTP協定基礎上進行了一層加密，https協定就是基于ssl進行加密實作加密傳輸
https加密流程、ssl加密流程：
目的：實作資料的安全傳輸
安全傳輸：需要考慮兩個問題
1.身份驗證問題：防止僞裝
2.資料加密問題：防止監聽
身份驗證實作：
CA認證：通信雙方在通信前先到權威機構請求給自己頒發一個CA憑證（權威機構資訊，自己的資訊...），通信雙方建立連接配接後，在通信之前先将證書發送給對方，收到對方的證書後，檢視這個權威機構是否是自己信任的權威機構，如果是，則到權威機構進行這個公司的身份驗證，驗證通過後進行通信，不通過可以自行選擇是否添加信任。
但是身份驗證通過，通信依然有可能被監聽，存在風險，是以需要加密傳輸。
加密傳輸實作：
1.對稱加密：加解密使用相同的密鑰
優點：加解密效率高
缺點：密鑰一旦被劫持則加密形同虛設
2.非對稱加密：加密和解密使用不同的密鑰
思路：通信中，每一端在通信前都可以生成一對密鑰（公鑰和私鑰），在通信前，将公鑰發送給對方，對方使用收到的公鑰進行加密資料然後傳輸，自己收到資料後，使用私鑰進行解密。
實作算法：RSA加密算法
優點：安全度更高
缺點：加解密效率低下
3.混合加密：通信雙方先使用非對稱加密保護對稱密鑰協商過程。對稱密鑰協商完畢後，使用對稱密鑰加密傳輸。
https加密流程：（将CA認證與混合加密合在一起使用）
（1）伺服器先生成一對密鑰（公鑰和私鑰），到權威機構使用公鑰請求頒發一個證書（權威機構，本身機構，公鑰資訊，過期時間...）
（2）通信雙方建立連接配接後，伺服器将證書發送給用戶端
（3）用戶端對證書進行解析，根據資訊進行身份驗證
（4）身份驗證通過後，使用公鑰加密（一個随機數+自己支援的對稱加密算法清單）發送給伺服器
（5）伺服器收到資料使用私鑰進行解密，并且給用戶端回複一個随機數+自己支援的對稱加密算法清單
（6）雙方通過自己的随機數與對方發送過來的随機數配合對稱加密算法清單進行計算得到一個對稱密鑰
（7）往後通信使用對稱密鑰進行通信
![linux-svn解除安裝與安裝[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)