UserDatagram protocol 用戶數據報 ，基於UDP的應用有很多，動態主機配置協議DHCP,域名系統DNS,簡單網絡管理協議SNMP
傳輸層 位於應用層和IP層之間
三個要求：
。提供比IP層質量更加高的服務
。識別應用層進程的機制，IP的範圍是在整個網絡中標誌到某臺計算機，無法提供該主機內應用的進程識別
。針對不同尺寸的應用層數據進行適當處理，對大數據進行劃分，小數據進行整合
TCP/IP協議族提供了兩個傳輸層協議 TCP UDP
考慮這樣一個問題，當IP數據報被投遞到“目的IP地址”所標識的設備後，必須使用適當的方案來標識數據傳輸的最終目的地，一個高級應用會有一個或多個進程，進程是系統調度的基本單位，每個進程有唯一的ID來標識，
理論上這裏就可以直接採用進程當成數據的最終目的地，但是考慮這樣的問題，進程都是動態的，每次主機關機，所有的進程都會發生改變，發送者無法得知接收方每個進程的狀態，這時候如果發送方和接受方進行通話的話可以調劑下信息，但是考慮這樣一種更爲理想的方式，
來考慮特定的窗口就只處理特定的業務，TCP/IP將協議窗口作爲應用層與傳輸層的接口，“端口號”是數據投遞的最終目的地，端口號是一個2字節的整數，範圍爲0~65535，（這麼大夠用了），這就引出了通信的五元組
-------------------------------------------《源IP地址 源端口號 協議 目的IP地址 目的端口號》===========================
TCP/UDP 端口號是獨立的，TCP用的4000仍可以分配給UDP
基於UDP DNS 53 SNMP 161
端口號是一個偉大的發明，很神奇的解決了應用標識的問題，端口號是一個抽象的訪問點，和物理端口需要區分開來
UDP概述
UDP提供了應用程序之間傳輸數據的基本機制，同IP一樣，UDP提供了不可靠的，無連接的數據交付服務，可靠性保障和通信效率的代價
udp報文
16比特的兩個端口號，報文長度爲頭部加上數據的長度，最小爲8字節（數數頭部的大小）
校驗和爲可選的，該字段爲0時，說明未進行校驗，校驗和字段提供了唯一保證UDP報文無差錯的途徑（IP對數據報中的數據部分並不計算校驗和）
報文封裝
上層應用數據——》UDP（添加UDP首部—》用戶數據報）——》IP（用戶數據報（添加頭部）—》IP數據報）——》物理幀（網絡接口層）——》比特流在網絡中傳遞
（只有IP層的首部指明瞭源主機和目的主機的地址，只有UDP層指明瞭主機上的源端口和目的端口）
理論上，IP數據報的最大長度爲65535字節，（16比特的報文長度，不能再大了），減點20字節的IP頭部8字節的UDP頭部，65507字節是UDP
絕大多數是現代的長度比這個最大值小，
協議標準只是給出了一個是現代的指導，在實際實現時可能存在差異
UDP校驗和
udp校驗和的範圍包括udp頭部還有數據區，這樣只能保證目的端口地址正確，但是從通信五元的角度看，正確的目的地應該包括目的端口還有主機地址，問題來了，udp數據報並沒有涉及到源和目的IP地址，那麼爲了解決這個問題就必須想方設法得到，這裏引入一個12字節的僞首部，
udp僞首部邏輯上是udp首部的一部分，但實際上並不傳遞
源IP地址和目的IP地址對應的是發送UDP報文的IP
協議字段指明所使用的協議，UDP對應17
UDP長度 字段指明UDP數據報的長度（不包括僞首部）
爲計算校驗和，UDP層必須與IP層交互獲取IP地址信息，利用這些信息生成僞首部
僞首部被附加在UDP報文首部和數據區之前。
UDP-Lite
對校驗和字段的使用，UDP給出了兩種方案，使用校驗和或不使用校驗和，如果使用，如果接受方檢驗校驗和字段時發現錯誤，則整個用戶數據報被丟棄。但是有些場景下並沒與這麼嚴格的要求，爲此，2004/7，IETF推出了UDP-Lite(LightweightUser Datagram Protocol 輕量級用戶數據報協議)，敏感區和非敏感區兩個區域，丟棄與否可以選擇了。
區別，報文長度 -》 校驗和覆蓋 //IP數據報總長度減去首部長度即可獲得UDP報文長度
“校驗與覆蓋”，體現UDP-Lite核心思想所在，從報文的第一個字節開始計算校驗和時輸入的字節數，“0表示所有的報文都被覆蓋” “UDP首部必須被校驗和覆蓋”，——？這個字段的額取值必須爲0或大於等於8的整數，1-7的數字是違法的，（明顯嘛，必須覆蓋8字節的首部）
服務器，一臺主機可以運行多個服務器程序，多個主機可以運行一個服務器程序