TCP/IP四層模型中的典型協議解析以及特性講解
1.應用層
負責應用程序之間的數據傳輸
知名協議：
HTTP協議
（超文本傳輸協議）
網址-URL
（統一資源定位符）
http://user:[email protected]:80/dir/index.htm?uid=1#ch1
協議方案名稱：//用戶名：密碼@服務器地址：端口號/請求資源路徑？查詢字符串#片段標識符
URL編碼/解碼：
查詢字符串是用戶提交給服務器的數據信息；
這些提交的數據中若是出現特殊字符，則有可能與URL中間隔符產生歧義導致URL解析失敗，因此查詢字符串中不能出現特殊字符。
若是提交的數據中真的有特殊字符需要對查詢字符串中的數據進行URL編碼操作；編碼之後的數據在對端需要進行URL解碼操作
URL編碼：將特殊字符每一個字節轉換爲16進制數字字符串，並且爲了表名這兩個字符是經過了URL編碼後的數據，需要在轉換後的數據前加上%。'+'----->'%2B'
URL解碼：當遇到'%'，則認爲緊跟其後的兩個字符需要轉碼，將第一個字符轉換爲數字左移4位與第2個字符轉換後的數據進行相加。'%2B'->('2' - '0') << 4 + ('b' - 'a' + 10) -> 43 -> '+'
一箇中文：%2e%3e%4d
HTTP協議格式
首行
（1）請求首行： 請求方法 URL 協議版本
-
請求方法：GET/POST get沒有正文，提交的數據在URL的查詢字符串中
-
協議版本：HTTP 0.9/1.0/1.1/2
-
各個版本新的特性：HTTP 2開始，服務器端可以主動向客戶端發送信息
（2）響應首行： 協議版本 響應狀態碼 狀態碼描述信息
響應狀態碼：1** / 2 ** /3** /4** /5**
教程：https://www.runoob.com/http/http-status-codes.html
-
1**：信息性狀態碼，描述信息，接收的請求正在處理；
-
2**：成功狀態碼，客戶端請求已經正確處理並響應；典型：200（請求成功。一般用於GET與POST請求）
-
3**：重定向狀態碼，需要進行附加操作以完成請求；典型：302（臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有URI）
-
4**：客戶端錯誤狀態碼，服務器無法處理請求；典型：404（服務器無法根據客戶端的請求找到資源（網頁））
-
5**：服務器錯誤狀態碼，服務器處理請求出錯；典型：502（作爲網關或者代理工作的服務器嘗試執行請求時，從遠程服務器接收到了一個無效的響應）
頭部
頭部信息格式：以一個個key:val組成的鍵值對，並且各個鍵值對之間以\r\n作爲間隔
HTTP常見Header
-
Content-Type:描述的是正文是什麼類型的數據（text/html等）
-
Content-Length/Transfer-Encoding:正文的長度chuncked
-
Host:客戶端告知服務器，所請求的資源是在那個主機的哪個端口上
-
location:搭配3**重定向狀態碼使用，告訴客戶端接下來去哪裏訪問
-
User-Agent:聲明用戶的操作系統和瀏覽器版本信息
-
referer:當前的頁面是從哪個頁面跳轉過來的
-
Cookie:用於在客戶端存儲少量信息，通常用於實現會話(session)的功能
expires:Cookie 的時間信息，顯示什麼時候過期
-
Set-Cookie:設置和頁面關聯的Cookie，服務器返回的信息
空行
\r\n 用於間隔頭部與正文
正文
HTTP的方法
-
GET 獲取資源
-
POST 傳輸實體主題
-
PUT 傳輸文件
-
HEAD 獲得報文首部
-
DELETE 刪除文件
-
OPTIONS 詢問支持方法
-
TRACE 追蹤路徑
2.傳輸層
負責端與端之間的數據傳輸（端點/端口，進程）
典型協議：TCP/UDP
2.1端口號
在一個主機上標識一個進程（標識接收到的數據應該交給哪個進程處理）；
一個端口只能被一個進程佔用；
一個進程可以使用多個端口；
uint16_t 無符號16位整數：端口號0~65535 0~1023不推薦使用（被知名協議使用）
面試題：在一個主機上可以啓用65536個客戶端
2.2五元組
在網絡通信中每一條數據都必須帶有一些關鍵信息（源IP地址/源端口/目的IP地址/ 目的端口/協議）
功能：用於標識網絡中的一條通信
2.3UDP協議
（用戶數據報協議）
特性：無連接，不可靠，面向數據報
無連接
通信時，不需要建立連接，只需要知道對端地址信息（IP和端口號），就可以發送數據
不可靠
沒有確認機制，沒有重傳機制，若因網絡故障無法發到對方，UDP協議層也不會返回任何錯誤信息；優點：簡單快速，佔資源少
面向數據報
數據只能一整條一整條嚮應用層交付
udp協議字段:16位源/目的端口 16位數據報長度 16位校驗和（校驗接收數據和發送數據是否一致）
16位數據報長度：用於指定整個udp數據報的長度（包含頭部），決定了一個udp協議的數據data長度不能大於64k - 8; 8 -> udp頭部長度；否則發送失敗；因此當數據長度大於64k - 8時，就需要用戶在應用層進行數據分包，將數據分成一個個小於64k - 8大小的數據段；
udp並不保證數據有序到達，需要用戶在應用層進行包序管理；
用戶每次調用發送接口發送數據的時候，udp會直接爲這條數據封裝udp頭部信息，直接發送出去
udp總結
爲了防止用戶接收半條數據，導致udp剩餘數據無法根據協議字段中的數據報長度確定數據長度，因此udp規定，數據只能整條交付**
基於UDP的應用層協議
-
DNS:域名解析協議
-
DHCP：動態主機配置協議