udp協議-看這篇就夠了

UDP 概述

用戶數據報協議 UDP 只在 IP 的數據報服務之上增長了不多一點的功能，這就是複用和分用的功能以及查錯檢測的功能

UDP 的主要特色

1. UDP 是無鏈接的，即發送數據以前不須要創建鏈接(發送數據結束時也沒有鏈接可釋放)，減小了開銷和發送數據以前的時延
2. UDP 使用盡最大努力交付，即不保證可靠交付，主機不須要維持複雜的鏈接狀態表
3. UDP 是面向報文的，發送方的 UDP 對應用程序交下來的報文，在添加首部後就向下交付 IP 層。UDP 對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界

1. UDP 沒有擁塞控制，網絡出現的擁塞不會使源主機的發送速率下降。這對某些實時應用是很重要的
2. UDP 支持一對1、一對多、多對一和多對多的交互通訊
3. UDP 的首部開銷小，只有8個字節，比 TCP 的20個字節的首部要短

《PHP面試問答》 https://github.com/colinlet/P...
結合實際 PHP 面試，系統的彙總面試中的各類各樣的問題，嘗試提供簡潔準確的答案。若是你在 PHP 面試中遇到問題，歡迎提 Issues 交流。包含網絡協議、數據結構與算法、PHP、Web、MySQL、Redis、Linux、安全、設計模式、架構、自我介紹、離職緣由、職業規劃、準備問題等部分
若是以爲不錯歡迎 star 關注，正在不斷持續更新中~~

存在問題

1. 某些實時應用須要使用沒有擁塞控制的 UDP，但不少的源主機同時都向網絡發送高速率的實時視頻流時，網絡就有可能發生擁塞，致使你們都沒法正常接收。
2. 還有一些使用 UDP 的實時應用，須要對 UDP 的不可靠傳輸進行適當的改進，以減小數據的丟失。應用進程能夠在不影響應用的實時性的前提下，增長一些提升可靠性的措施，如採用前向糾錯或重傳已丟失的報文

UDP 的首部格式

用戶數據報 UDP 有兩個字段：數據字段和首部字段。首部字段很簡單，只有8個字節，由四個字段組成，每一個字段都是兩個字節

首部字段

• 源端口 源端口號。在須要對方回信時。不須要時可用全0
• 目的端口 目的端口號。這在終點交付報文時必須使用
• 長度 UDP 用戶數據報的長度，其最小值是8(僅有首部)
• 檢驗和 檢測 UDP 用戶數據報在傳輸中是否有錯。有錯就丟棄

端口分用

當運輸層從 IP 層收到 UDP 數據報時，就根據首部中的目的端口，把 UDP 數據報經過相應的端口，上交最後的終點——應用進程

若是接受方 UDP 發現收到的報文中的目的端口號不正確(即不存在對應於該端口號的應用程序)，就丟棄該報文，並由網際控制報文協議 ICMP 發送「端口不可達」差錯報文給發送方

僞首部

UDP 用戶數據報首部中檢驗和的計算方法有些特殊。在計算檢驗和時，要在 UDP 用戶數據報以前增長 12 個字節的僞首部。所謂「僞首部」是由於這種僞首部並非 UDP 用戶數據報真正的首部。只是在計算檢驗和時，臨時添加在 UDP 用戶數據報前面，獲得一個臨時的 UDP 用戶數據報。檢驗和就是按照這個臨時用戶數據報來計算的。僞首部既不向下傳也不向上遞交，而僅僅是爲了計算檢驗和

本文轉載自 楓葉林博客，《用戶數據報協議UDP》https://blog.maplemark.cn/201...