傳輸層：負責數據能夠從發送端傳輸至接收端
之前我們提到過端口號（Port）標識了一個主機上進行通信的不同的應用程序。
由圖我們可以看出如果想要數據成功的發送出去。那麼我們就必須讓他知道IP地址和端口號。就像我們要找一個人，我們只知道他住哪個小區是不夠的，我們還需要知道他在這個小區的哪一個房。他的房號就確定了一個具體的地址，並且是唯一的一個地址，不可能給一個房號我們能找到兩個房，如果能找到兩個房那到底哪個房間裏的人才是我們要找的呢？同理，數據發送的時候指定的端口號也必定唯一的表示了一個應用程序，數據才能確定他應該去哪兒。
端口號範圍劃分：
0~1023：知名端口號，HTTP,FTP,SSH等這些廣爲使用的應用層協議，他們的端口號都是固定的。
1024~65535：操作系統動態分配的端口號，客戶端程序的端口號就是由操作系統從該範圍內分配的。
瞭解知名端口號：
ftp服務器：21端口
ssh服務器：22端口
telnet服務器：23端口
http服務器：80端口
https服務器：443端口
注意：當我們自己在寫一個程序時如果要用到端口號就要避開這些知名端口號。
我們也說了一個端口號唯一標識一個進程，所以我們的一個端口號是不能同時被多個進程綁定的，如果同時被多個進程綁定，那我們知道端口號以後到底去找哪一個進程呢？這個時候就說不清了。所以一個端口號只能被一個進程綁定。但是反過來一個進程是可以綁定多個端口號的，因爲這並不影響我們通過端口號唯一確定一個進程。
在TCP/IP協議中，用 ‘源IP’ ， ‘源端口號’ ， ‘目的IP’ ， ‘目的端口號’ ， ‘協議號’。這樣一個五元組來標識一個通信（可以通過netstat -n查看）。這裏的‘源IP’和‘源端口號’是源端套接字，‘目的IP’和‘目的端口號’是客戶端套接字。
UDP協議：用戶數據報協議
udp協議端格式：
16位udp長度：表示整個數據報（udp首部+udp數據）的最大長度。
如果校驗和出錯就會直接丟棄。
我們在之前說過一個數據包的分用過程，而數據報在自底向上的交付過程中是一對多的，那麼又是如何準確的將數據一一正確交付的呢？數據報在向上交付的過程中是根據報頭中的有效載荷從而確定需要將數據交付給上一層的誰。而有效載荷是在報文中的，我們又如何才能取到有效載荷呢？此時我們就需要將報頭和有效載荷。
分離報頭和有效載荷的方法：
1、使用定長的報頭。丟棄報頭（這裏就是8個字節），剩下的就是有效載荷。
2、拿出整體報文，再去掉定長報頭，剩下的就是有效載荷。
udp特點
| 特點 | 描述 |
|---|---|
| 無連接 | 知道對端的IP和端口號就直接進行傳輸，無需建立連接 |
| 不可靠 | 沒有確認機制和重傳機制，若因爲網絡故障該段無法發給對方，udp協議層不會給應用層返回任何消息 |
| 面向數據報 | 不能夠靈活的控制讀寫數據的次數和數量 |
由於udp協議面向數據報的特點：所以我們應用層交付給udp的報文，無論這個報文有多長或者多短，udp都只會原樣發送，不會做任何的拆分也不會進行合併。也就是說一個很長的報文必須一次傳送（不會拆分），傳送完畢以後對端也必須一次接受完畢（不能一次接收一部分，分多次接收完成）。多個很短的報文也必須分多次傳送（不會合並）。總結一下就是：udp對於數據的收發從來都是整發整收。
UDP的緩衝區：
udp沒有真正意義上的發送緩衝區，調用sendto會直接交給內核，由內核將數據傳給網絡層協議進行後續的傳輸動作；
udp具有接收緩衝區，但是這個接收緩衝區不能保證收到的udp報的順序和發送udp報的順序一致，如果緩衝區滿了在到達的udp數據報就會被丟棄。
udp使用注意事項：
udp協議首部中有一個16位的最大長度，也就是說一個udp能傳輸的數據的最大長度是64K（包含udp首部）。然而64k在當今的互聯網環境下就是一個非常小的數字。如果我們要傳輸的數據超過了64k就需要在應用層手動的進行一個分包的過程，分多次發送並在接收端手動的進行拼接。
應用層有很多的協議都是基於udp實現的：
DNS:域名解析協議
NFS:網絡文件系統
TFTP:簡單文件傳輸協議
DHCP:動態主機配置協議
BOOTP:啓動協議（用於無盤設備啓動）
