UDP協議

• UDP協議全稱是用戶數據報協議，在網絡中她與TCP協議一樣用于處理數據包，兩個協議同處于協議棧的傳輸層，和TCP不同的是，UDP是一種無連接的協議棧。

• 因為UDP是無連接的，所以相對來說，UDP的報頭比TCP要簡單的多了。如下圖：
  

• UDP特點：

  • 第一UDP是一個非連接的協議，傳輸數據之前源端口和終端不建立連接，當他想傳送時就簡單的去抓取來自應用城西的數據，并盡可能快的把他扔在網絡上，在發送端，UDP傳送數據的速遞僅僅是受應用程序生成數據的速度，計算機的計算能力，和傳輸帶寬的現在；在接受端，UDP吧每個消息段放再隊列中，應用程序每次從隊列中讀一個消息段。
  • 由于傳輸數據不建立連接，因此也就不需要維護連接狀態，包括收發狀態等，因此一天服務器可以同時向多個客戶端傳輸相同的消息
  • UDP信息包的標題短，只有8字節，相對于TCP的20字節信息包的額外開銷很小
  • 吞吐量不受擁擠控制算法的調節，只受應用軟件生成數據的速率，傳輸帶寬，源端和終端主機性能的限制
  • UDP使用盡量大努力交付，即不保證可靠交付，因此主機不需要維持復雜的鏈接狀態表（這個表中有許多參數）
  • UDP是面向報文的，發送方的UDP對應應用程序交下來的報文，在添加首部后就向下交付給IP層，即不拆分，也不合并，而是保留這些報文的邊界，因此，應用程序需要選擇合適的報文大小。

• 我們經常用PING命令來測試兩臺主機之間TCP/IP通信是否正常，其實PING命令的原理就是向對方主機發送UDP數據包，然后對方主機確認收到數據包，如果數據包是否到達的信息及時反饋回來，那么網絡就是通的。

HTTP協議

• HTTP協議名為超文本傳輸協議。這個協議在TCP/IP協議棧的應用層，因此，我們無需關系HTTP是如何傳輸的，只需要看我們傳輸的內容，能否正確的被接收端識別。
• HTTP是基于TCP實現的，簡單說來，TCP協議負責可靠的內容傳輸，HTTP協議負責識別內容，兩者本身不在一個層面，沒有可比性。
• HTTP是無狀態的意思是，每一次的內容解析是沒有關聯的。TCP有狀態是指兩端在連接過程的時候是有在連接中的狀態
• HTTP包含兩種報文類型，請求報文，響應報文。
  • 請求報文用在客戶端對服務器的請求時候使用的報文格式
  • 響應報文用在服務響應請求的報文格式

HTTP協議請求消息結構

• 客戶端發生一個HTTP請求奧服務器的請求消息包括一下格式：請求行（request line），請求頭部（header），空行和請求數據四個部分組成，下圖給出了請求報文的一般格式。
  
• 如上圖所示HTTP消息主要包含以下實質內容（空格和換行也不能少）：
  • 請求方法
  • URL：統一資源定位符
  • HTTP請求頭部
  • HTTP請求體
• 以下是一個HTTP請求的例子，從Fiddler抓包工具中抓出來的一個請求案例。

//1. post：請求方法 //2. http://edu.zhenai.com/api/business/supremecourse/course.do：請求URL //3. HTTP/1.1：HTTP協議以及版本 POST http://edu.zhenai.com/api/business/supremecourse/course.do HTTP/1.1 //以下報文頭部 Cookie: token=506188.1587368100293.ef83f599f1a54833d0cc5124da98140a.test; token=506188.1587368100293.ef83f599f1a54833d0cc5124da98140a.test; sid=88TIsgom9Xqw3GMLTDv0; User-Agent: PostmanRuntime/7.25.0 Accept: */* Cache-Control: no-cache Postman-Token: 4b0c8482-cce5-40e2-a7b9-a251378c6475 Host: edu.zhenai.com Accept-Encoding: gzip, deflate, br Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 30 zone: 1027071-liaojiamin Host: edu.zhenai.com //以下報文體 supremeCourseID=129&allow=true

HTTP請求方法

• HTTP包含來多種不同的請求方法，每一種請求方式用在不同的場景

序號方法描述

1	GET	請求指定頁面信息，并放回實體主體
2	HEAD	類似get請求，不過返回的響應中沒有具體的內容，用于獲取報頭
3	POST	向指定資源提交數據進行處理請求（例如提交表達或者上傳文件），數據被包含在請求體中，POST請求可能會操作新的資源的建立和/或已有資源的修改
4	PUT	從客戶端想服務器傳送的數據取代指定的文檔內容
5	DELETE	請求服務器刪除指定內容
6	CONNECT	HTTP1.1協議中預留給能夠將連接改為管道方式的代理服務器
7	OPTIONS	允許客戶端查看服務器的性能
8	TRACE	回顯服務器收到的請求，主要用于測試或診斷

URL-- 統一資源定位符

• URL由三部分組成：資源類型，存放資源的主機域名，資源文件名
• URL的一般語法格式為（帶括號 [ ] 的是可選項目）： protocol 😕/ hostname[:port] / path / [;parameters][?query]#fragment
• 如上面HTTP請求案例中的URL：http://edu.zhenai.com/api/business/supremecourse/course.do&supremeCourseID=129&allow=true
  • protocol：http
  • hostname：edu.zhenai.com
  • parameters：supremeCourseID=129&allow=true
  • path：api/business/supremecourse/course.do

HTTP請求頭

• 請求頭中主要包含本次請求的附加信息，其中常用的字段如下：
  • Accept：指定客戶端能夠接受的內容類型
  • Accept-Encoding：指定瀏覽器可以支持的web服務器返回內容壓縮編碼類型
  • Accept-Language：瀏覽器可接受的語言
  • Content-Length：請求的內容長度，如：Content-Length：348
  • Content-Type：請求的與實體對于的MIME信息，常用的類型也有很多中，如下表信息中列出
  • Date：請求發送日期和時間
    更多的HTTP響應頭和請求頭信息對照表

//Content-type常用類型 text/html：HTML格式 text/plain：純文本格式 text/xml：xml格式 image/gif：gif圖片格式 image/jpeg：jpg圖片格式 image/png：png圖片格式 //以為application開頭的媒體格式類型： application/xhtml+xml：XHTML格式 application/xml：xml數據格式 application/atom+xml：atom xml聚合格式 application/pdf：pdf格式 application/msword：word文檔格式 application/octet-stream：二進制流數據 application/x-www-form-urlencoded：form表達數據被編碼后送到服務器

HTTP請求體

• 在整個報文中，請求頭之后，隔一個空格，以下部分就是HTTP的請求體。
• 請求體是我們發送請求的時候需要傳給接收端的內容。其格式需要和請求頭中的Content-Type對應，不日回導致接受無法識別。如上案例中的請求體：supremeCourseID=129&allow=true

HTTP響應

• HTTP的響應統一分為：響應行，響應頭，響應體，和請求報文有點類似。總體結構如下：

// 狀態行，用于描述服務器對請求的處理結果 HTTP/1.1 200 OK // 多個響應頭：響應頭用于描述服務器的基本信息，以及數據的描述，服務器通過這些數據的描述信息，可以通知客戶端如何處理之后他返回的數據 Server: nginx/1.15.5 Date: Mon, 29 Jun 2020 13:31:00 GMT Content-Type: application/json;charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding Content-Disposition: inline;filename=f.txt Content-Length: 2166// 此處保留一個空行 //實體內容：代表服務器向客戶端返回的數據信息。 {"data":{"msg":"獲取成功",......}

HTTP響應行

• 響應行中包含來HTTP的版本和本次請求的狀態，請求狀態的對于值見其他資源HTTP響應碼

HTTP響應頭

• 響應頭用于描述服務器的基本信息，數據的描述，這些信息將告知客戶端如何處理響應題中的內容
  • Allow服務器支持哪些請求方法（GET，POST）
  • Content-Encoding 文檔的編碼（Encode）方法。
  • Content-Length 表示內容長度。
  • Content-Type 表示后面的文檔屬于什么MIME類型。
    更多的響應頭字段參考資源HTTP響應頭和請求頭信息對照表

HTTP響應實體

• 響應實體中包含的就是客戶端從服務器中獲取的數據。數據的格式和長度都會在響應頭中描述。

上一篇 網絡編程-TCP/IP協議棧-TCP協議
下一篇 網絡編程-HTTPS協議的實現原理

總結

以上是生活随笔為你收集整理的网络编程-TCP/IP协议栈-UDP/HTTP协议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。