怎么做企業(yè)網(wǎng)站推廣南京seo整站優(yōu)化技術
應用層協(xié)議是請求與響應服務,客戶端的請求與服務器的響應是通過應用層傳輸?shù)骄W(wǎng)絡中的,但再實際上,應用層并不能直接通信,需要將數(shù)據(jù)進行報頭的封裝,向下層交付,貫穿整個協(xié)議棧。我們已經談到應用層協(xié)議負責應用。往下層交付,我們又要考慮交給誰?瀏覽器接收到請求后,同樣要經過協(xié)議棧,并且需要知道將數(shù)據(jù)交到哪一個應用。
在協(xié)議中,我們始終要考慮,數(shù)據(jù)如何向上交付,報文和有效載荷如何分離的問題,還要考慮粘包等問題。
本文介紹距離應用層最近的傳輸層,負責數(shù)據(jù)從發(fā)送端送到接收端。
傳輸層協(xié)議有UDP和TCP,UDP是不可靠連接,不考慮數(shù)據(jù)丟失,正因如此,UDP協(xié)議很簡單,并且資源浪費小。而TCP協(xié)議必須考慮大量數(shù)據(jù)丟失的問題,十分的負責,必然的代價是資源的消耗(空間和時間上)。
從了解UDP協(xié)議。
端口號
之前說過,端口號是用來標記主機上唯一的一個進程。數(shù)據(jù)在網(wǎng)絡傳輸中,必須要解決上層交付的問題,因此傳輸中必定會獲取到上層標志進程的唯一標志,就是端口號。所以端口是傳輸層的概念,主要負責向上交付的問題。
? ? ? ?? ?
傳輸層獲取到應用層的數(shù)據(jù)后,必定會添加端口相關的報頭
同樣傳輸層向上交付數(shù)據(jù)時,也必須解析出目標端口和源端口,向上交付有效載荷。
五元組標志通信?
在TCP/ip協(xié)議中,通過源端口,目的端口,源ip,目的ip,及協(xié)議號。這個五元組就能雙方通信。
?
查看五元組
常用的方式是netstat - nltp a u?
介紹選項:
- n:把字符顯示成數(shù)字
- l:查看監(jiān)聽狀態(tài)的服務,去掉" l ",就能查看所有狀態(tài)
- u:查看udp協(xié)議
- t:查看tcp協(xié)議
- a:顯示所有的選項,默認不顯示LISTEN相關
- p:查看進程?
端口號的劃分
0-1023號是知名端口,普通用戶是不能綁定的。
1024-65535是可以被OS分配的動態(tài)端口號。
?UDP協(xié)議
UDP協(xié)議是一中無連接的協(xié)議,它不像TCP協(xié)議在通信前需要建立連接。這種特性使得UDP在對時實性能要求比較高,對數(shù)據(jù)丟失容忍度高的場合有極高的運用。如視頻流,電話通信等。
UDP報文傳輸都是獨立的,每一個UDP都被封裝成獨立的數(shù)據(jù)報,數(shù)據(jù)報中必然包含著源端口,目標端口。
UDP協(xié)議格式
udp協(xié)議的基本格式如下:
源端口:數(shù)據(jù)從哪里來
目的端口:數(shù)據(jù)交付到哪里
udp長度:包括報頭和有效載荷
校驗和:如果UDP報文出錯,就直接丟棄
報頭和有效載荷分離的問題?
UDP的報頭是四個字段,每一個字段是16位。因此讀到8字節(jié)后,就代表讀完報頭。繼續(xù)讀取到結尾,就讀完有效載荷,就能做到報頭和有效載荷的分離。
數(shù)據(jù)如何向上交付的問題??
獲取到有效載荷后,就要將數(shù)據(jù)往上層交付,在上層中有大量的協(xié)議進程,具體交到哪一個進程呢,主要是目的端口決定的!獲取到目的端口后,就能交付。
如何理解報頭
?報頭的本質就是一個結構化字段,必然也是數(shù)據(jù)。其實就是一個結構體。
數(shù)據(jù)的封裝
傳輸層收到應用層發(fā)來的數(shù)據(jù)后,會在傳輸層創(chuàng)建udp_header報頭類型的變量,并且填充相應的字段。接著在OS開辟一塊空間,將報頭和有效載荷封裝到一起,并直接發(fā)到下一級。
因此udp的傳輸層是沒有緩沖區(qū)的,報文是直接向下交付的。
報文的管理
udp沒有發(fā)送緩沖區(qū),必然的結果是數(shù)據(jù)一旦被封裝就直接發(fā)送到對方的主機上,對方主機就會一下子收到大量的報文,必然會來不及處理。所以必須對報文進行管理。OS怎么管理呢?先描述,再組織。
實際上就是一個隊列,如果有報文發(fā)來,就先維護起來,列入隊列中sk_buff 。要處理數(shù)據(jù)時,就往隊列中取出對頭的數(shù)據(jù)去處理。
UDP協(xié)議的特點
?udp協(xié)議就像寄信:
- 無連接:知道對端的主機和端口就能直接通信,無需要建立連接。TCP有三次握手,是面向連接。
- 不可靠:沒有確認機制,沒有重傳。如果數(shù)據(jù)校驗不一致,就直接丟棄這個報文。
- 面向數(shù)據(jù)報:不能控制讀取的大小和次數(shù)。
面向數(shù)據(jù)報
應用層交付給UDP一個報文,報文封裝后就直接發(fā)送到對端。
不會囤積報文,或者分割報文。
對端必須一次收完一個完整的報文。
比如一份udp報文有10個字節(jié):
發(fā)送端會立刻調用sento發(fā)送報文。接收方會調用recvfrom,一次性接收10個字節(jié)。這樣就解決了粘包的問題。
接收方的報文天然就存放著數(shù)據(jù)報的長度,所以依靠數(shù)據(jù)報就能實現(xiàn)有效載荷和報文的分離,能夠知道有效負載的長度。
基于UDP的應用層協(xié)議
- NFS:網(wǎng)絡文件系統(tǒng)。
- TFTP:簡單文件傳輸協(xié)議。
- DHCP:動態(tài)主機配置協(xié)議。
- BOOTP:啟動協(xié)議(用于無盤設備啟動)。
- DNS:域名解析協(xié)議。
UDP的使用場景
- 實時視頻流和音頻流傳輸,如在線直播、視頻會議等;
- 實時游戲,如在線游戲中的游戲數(shù)據(jù)傳輸;
- 簡單的請求/響應交互,如 DNS、SNMP 等;
- 廣播通信,如廣播、多播等;