擼完了TCP
,天然要來擼一下UDP
算法
UDP 協議,即 用戶數據報協議(User Datagram Protocol
),是一個簡單的 面向數據報 的 傳輸層 協議。緩存
咱們能夠將UDP
協議看做IP
協議 暴露 在 傳輸層 的一個 接口。網絡
UDP 協議一樣以 數據包(datagram
)的方式傳輸,它的傳輸方式也是Best Effort
的,因此UDP
協議也是不可靠的(unreliable
)。socket
那麼,咱們爲何不直接使用IP
協議而要額外增長一個UDP
協議呢?3d
一個重要的緣由是IP
協議中並無 端口(port
)的概念。IP
協議進行的是IP
地址到IP
地址的傳輸,這意味者兩臺計算機之間的對話。但每臺計算機中須要有 多個通訊通道,並將 多個通訊通道 分配給 不一樣的進程 使用。一個端口 就表明了這樣的一個 通訊通道。UDP
協議實現了 端口,從而讓 數據包 能夠在送到IP
地址的基礎上,進一步能夠送到 某個端口。code
儘管UDP
協議很是 簡單,但它的產生 晚於 更加 複雜 的TCP
協議。orm
早期的網絡開發者開發出IP
協議和TCP
協議分別位於 網絡層 和 傳輸層,全部的通訊都要先通過TCP
封裝,再通過IP
封裝(應用層->TCP
->IP
)。cdn
開發者將TCP/IP
視爲相互合做的 套裝。但很快,網絡開發者發現,IP
協議的功能和TCP
協議的功能是相互 獨立 的。blog
對於一些簡單的通訊,咱們只須要Best Effort
式的IP
傳輸就能夠了,而不須要TCP
協議複雜的創建鏈接的方式(特別是在 早期 網絡環境中,若是 過多 的創建TCP
鏈接,會形成很大的網絡 負擔,而UDP
協議能夠相對快速的處理這些簡單通訊)。接口
UDP 協議隨之被開發出來,做爲IP
協議在 傳輸層 的 傀儡。這樣,網絡通訊能夠經過 應用層->UDP->IP 的封裝方式,繞過TCP
協議。
header
)和
數據 (
payload
)兩部分。
UDP 是傳輸層(transport layer
)協議,這意味着UDP
的數據包須要通過IP
協議的封裝(encapsulation
),而後經過IP
協議傳輸到 目的電腦。隨後UDP
包在目的電腦拆封,並將信息送到 相應端口 的緩存中。
source port
UDP 包的出發端口
destination port
目的地端口
Length
整個 UDP 包的長度。
checksum
它的算法與IP
協議的header checksum
算法相相似。
然而,UDP
的checksum
所校驗的序列包括了 整個UDP數據包,以及封裝的IP頭部的一些信息(主要爲出發地IP和目的地IP)。
這樣,checksum
就能夠 校驗IP:端口 的正確性了。
在IPv4
中,checksum
能夠爲 0,意味着 不使用 checksum。IPv6
要求必須進行checksum
校驗。
端口(port
)是伴隨着 傳輸層 誕生的概念。它能夠將 網絡層 的IP
通訊分送到 各個通訊通道。
UDP 協議和TCP
協議儘管在工做方式上有很大的不一樣,但它們都創建了 從一個端口到另外一個端口的通訊。
一個特定的IP
和特定的 端口 就構成了一個socket
。
無鏈接的
發送數據以前 不須要創建鏈接,減小了開銷和發送數據以前的時延。
盡最大努力交付
不保證可靠的交付,主機 不須要 維持複雜的連接狀態表。
面向報文的
發送方的UDP
對應用程序交下來的報文,在添加首部後就向下交付給IP
層。
既 不拆分,也 不合並,而是 保留 這些報文的 邊界。
所以,應用程序須要選擇 合適 的報文 大小。
沒有擁塞控制。
支持一對1、多對一和多對多的交互通訊。
首部開銷小,只有8個字節。
UDP 端口掃描比較麻煩,它同TCP
不同,由於它不須要創建鏈接。
咱們向 目標主機 的固定端口發送UDP
數據包,能夠獲得 兩種結果:
ICMP
的port-unreachable
響應 那麼,咱們就能夠coding
,大部分同TCP
探測:
構造一系列目標端口的UDP
包
經過第二層的sr
發送而且接收返回的包
遍歷接收的包,判斷是否目標端口有ICMP
回覆包,此端口就爲沒有開放端口
經過遍歷的全部端口集合和不開放端口集合作差集,就能獲得全部開放端口的集合
整個代碼就是:
掃描發現對方主機 88 號端口開放:
願意與你們分享交流各類技術,我的公衆帳號[mindev],以及 知識星球[ 極客世界 ]
歡迎訂閱公衆帳號,日更喲~~~