當前位置:首頁 » 網路連接 » 計算機網路udp怎麼判斷
擴展閱讀
計算機網路技術ip 2025-07-01 22:21:08
vivo怎麼取消網路設置 2025-07-01 22:16:17

計算機網路udp怎麼判斷

發布時間: 2022-07-24 17:49:52

① UDp接受 怎樣判斷數據發送過來了

不管是window是平台還是linux平台
接受函數會有返回值
一般返回的是接收到的位元組數
通過這個來判斷

一般沒有埠時間,
比如udp的接受函數是receive()
那麼當程序執行到receive的時候,如果沒有數據,程序就阻塞在這里了,直到有數據來的時候才繼續執行後面的代碼
所以一般的用法是開一個線程,接受udp的數據,這樣能保證程序不阻塞
然後,當receive到來的時候,下一行代碼,可以自己建立個event,然後setevent()
來通知相關的thread

windows和linux都有事件,也就是event的機制,兩者使用略有不同
但是udp接收函數一般本身不會帶這個功能

② udp協議是什麼如何判斷某些埠的開啟是不正常的

UDP協議是英文UserDatagramProtocol的縮寫,即用戶數據報協議,主要用來支持那些需要在計算機之間傳輸數據的網路應用。包括網路視頻會議系統在內的眾多的客戶/伺服器模式的網路應用都需要使用UDP協議。UDP協議從問世至今已經被使用了很多年,雖然其最初的光彩已經被一些類似協議所掩蓋,但是即使是在今天,UDP仍然不失為一項非常實用和可行的網路傳輸層協議。

與我們所熟知的TCP(傳輸控制協議)協議一樣,UDP協議直接位於IP(網際協議)協議的頂層。根據OSI(開放系統互連)參考模型,UDP和TCP都屬於傳輸層協議。

UDP協議的主要作用是將網路數據流量壓縮成數據報的形式。一個典型的數據報就是一個二進制數據的傳輸單位。每一個數據報的前8個位元組用來包含報頭信息,剩餘位元組則用來包含具體的傳輸數據。

0UDP報頭

UDP報頭由4個域組成,其中每個域各佔用2個位元組,具體如下:

源埠號

目標埠號

數據報長度

校驗值

UDP協議使用埠號為不同的應用保留其各自的數據傳輸通道。UDP和TCP協議正是採用這一機制實現對同一時刻內多項應用同時發送和接收數據的支持。數據發送一方(可以是客戶端或伺服器端)將UDP數據報通過源埠發送出去,而數據接收一方則通過目標埠接收數據。有的網路應用只能使用預先為其預留或注冊的靜態埠;而另外一些網路應用則可以使用未被注冊的動態埠。因為UDP報頭使用兩個位元組存放埠號,所以埠號的有效范圍是從0到65535。一般來說,大於49151的埠號都代表動態埠。

數據報的長度是指包括報頭和數據部分在內的總的位元組數。因為報頭的長度是固定的,所以該域主要被用來計算可變長度的數據部分(又稱為數據負載)。數據報的最大長度根據操作環境的不同而各異。從理論上說,包含報頭在內的數據報的最大長度為65535位元組。不過,一些實際應用往往會限制數據報的大小,有時會降低到8192位元組。

UDP協議使用報頭中的校驗值來保證數據的安全。校驗值首先在數據發送方通過特殊的演算法計算得出,在傳遞到接收方之後,還需要再重新計算。如果某個數據報在傳輸過程中被第三方篡改或者由於線路噪音等原因受到損壞,發送和接收方的校驗計算值將不會相符,由此UDP協議可以檢測是否出錯。這與TCP協議是不同的,後者要求必須具有校驗值。

UDPvs.TCP

UDP和TCP協議的主要區別是兩者在如何實現信息的可靠傳遞方面不同。TCP協議中包含了專門的傳遞保證機制,當數據接收方收到發送方傳來的信息時,會自動向發送方發出確認消息;發送方只有在接收到該確認消息之後才繼續傳送其它信息,否則將一直等待直到收到確認信息為止。

與TCP不同,UDP協議並不提供數據傳送的保證機制。如果在從發送方到接收方的傳遞過程中出現數據報的丟失,協議本身並不能做出任何檢測或提示。因此,通常人們把UDP協議稱為不可靠的傳輸協議。

相對於TCP協議,UDP協議的另外一個不同之處在於如何接收突法性的多個數據報。不同於TCP,UDP並不能確保數據的發送和接收順序。例如,一個位於客戶端的應用程序向伺服器發出了以下4個數據報

D1

D22

D333

D4444

但是UDP有可能按照以下順序將所接收的數據提交到服務端的應用:

D333

D1

D4444

D22

事實上,UDP協議的這種亂序性基本上很少出現,通常只會在網路非常擁擠的情況下才有可能發生。

UDP協議的應用

也許有的讀者會問,既然UDP是一種不可靠的網路協議,那麼還有什麼使用價值或必要呢?其實不然,在有些情況下UDP協議可能會變得非常有用。因為UDP具有TCP所望塵莫及的速度優勢。雖然TCP協議中植入了各種安全保障功能,但是在實際執行的過程中會佔用大量的系統開銷,無疑使速度受到嚴重的影響。反觀UDP由於排除了信息可靠傳遞機制,將安全和排序等功能移交給上層應用來完成,極大降低了執行時間,使速度得到了保證。

關於UDP協議的最早規范是RFC768,1980年發布。盡管時間已經很長,但是UDP協議仍然繼續在主流應用中發揮著作用。包括視頻電話會議系統在內的許多應用都證明了UDP協議的存在價值。因為相對於可靠性來說,這些應用更加註重實際性能,所以為了獲得更好的使用效果(例如,更高的畫面幀刷新速率)往往可以犧牲一定的可靠性(例如,會面質量)。這就是UDP和TCP兩種協議的權衡之處。根據不同的環境和特點,兩種傳輸協議都將在今後的網路世界中發揮更加重要的作用.

③ 如何判斷udp埠可達

TCP---傳輸控制協議,提供的是面向連接、可靠的位元組流服務。當客戶和伺服器彼此交換數據前,必須先在雙方之間建立一個TCP連接,之後才能傳輸數據。TCP提供超時重發,丟棄重復數據,檢驗數據,流量控制等功能,保證數據能從一端傳到另一端。 TCP是面向連接的,有比較高的可靠性。 UDP---用戶數據報協議,是一個簡單的面向數據報的運輸層協議。UDP不提供可靠性,它只是把應用程序傳給IP層的數據報發送出去,但是並不能保證它們能到達目的地。由於UDP在傳輸數據報前不用在客戶和伺服器之間建立一個連接,且沒有超時重發等機制,故而傳輸速度很快。 TCP是當應用程序要得到完整且可信賴的數據時所採用的傳輸控制協議,由於必須絕對完整無誤,因此TCP會在傳輸的過程中多了許多確認的動作以確定數據的正確性;而UDP比起TCP是要簡單許多,UDP傳輸數據通常會遺失卻不見得再重新傳輸一次,因此使用UDP的應用程序著重於簡潔和效率以完成工作,它不需要像TCP一般復雜的手續就可以達到交換信息的目的。

怎麼判斷一個協議 是UDP協議還是TCP協議 如telnet,snmp,dns,dhcp

無法直接判斷一個協議是基於UDP協議還是TCP協議,只能查閱相關技術文檔來判斷。

Telnet是位於OSI模型的第7層---應用層上的一種協議,是一個通過創建虛擬終端提供連接到遠程主機終端模擬的TCP/IP協議。

SNMP 是一種應用程序協議,封裝在UDP中。

DNS使用TCP和UDP。

DHCP(動態主機設置協議)是一個區域網的網路協議,使用UDP協議工作。

TCP提供IP環境下的數據可靠傳輸,它提供的服務包括數據流傳送、可靠性、有效流控、全雙工操作和多路復用。通過面向連接、端到端和可靠的數據包發送。通俗說,它是事先為所發送的數據開辟出連接好的通道,然後再進行數據發送;

而UDP則不為IP提供可靠性、流控或差錯恢復功能。一般來說,TCP對應的是可靠性要求高的應用,而UDP對應的則是可靠性要求低、傳輸經濟的應用。

(4)計算機網路udp怎麼判斷擴展閱讀:

UDP傳輸協議特點:

1、UDP在傳輸數據前既不需要建立通道,在數據傳輸完畢後也不需要將通道關閉。只要客戶端給服務端發送一個請求,服務端就會一次性地把所有數據發送完畢。

2、UDP在傳輸數據時不會對數據的完整性進行驗證,在數據丟失或數據出錯時也不會要求重新傳輸,因此也節省了很多用於驗證數據包的時間,所以以UDP建立的連接的延遲會比以TCP建立的連接的延遲更低。

3、UDP不會根據當前的網路情況來控制數據的發送速度,因此無論網路情況是好是壞,服務端都會以恆定的速率發送數據。雖然這樣有時會造成數據的丟失與損壞,但是這一點對於一些實時應用來說是十分重要的。

⑤ 怎麼看udp連接

在防火牆上鑽孔【UDP Hole Puching】:穿透防火牆建立UDP連接

知道現在流行的P2P軟體和IM軟體是如何讓兩台分處在不同防火牆後面的電腦直接對話的嗎?SIP當然是一種,還有一種被廣泛應用的就是本文介紹的UDP Hole Puching技術。

為了便於講述,我們假設有這樣一個網路拓撲結構:

IP=A.A.A.A IP=1.1.1.1

HostA----------FirewallA---------|

|

Server IP=S.S.S.S

|

HostB----------FirewallB---------|

IP=B.B.B.B IP=2.2.2.2

運用這個技術,必須滿足下面的條件:

1) HostA和HostB分別通過FirewallA和FirewallB經過NAT用UDP連接到了Server

2) FirewallA和FirewallB都滿足這樣的特性,即來自相同IP相同Port的數據包,不管目的地IP是多少, 都會NAT成相同的IP+Port,舉個例子吧:

HostA通過UDP Port 1234訪問主機S1時,防火牆會把數據包NAT成1.1.1.1:5668(舉例),那麼HostA通過UDP Port 1234訪問主機S2時,防火牆仍然會把數據包NAT成1.1.1.1:5668。好在現在的NAT基本上都具備這個特性。

現在,HostA用UDP埠1111連接到Server的5555埠,HostB用埠2222連接到Server的5555埠,在Server看來,HostA來自1.1.1.1:9676(FirewallA NAT過了嘛),HostB則來自2.2.2.2:6573。當HostA想直接連接HostB時,它這樣做:

1)用UDP埠1111發一個數據包給2.2.2.2:6573,注意一定要用埠1111哦,這個數據包一定會被FirewallA NAT成 1.1.1.1:9676 -> 2.2.2.2:5668(不要問為什麼,看看前面對防火牆的要求先); 千萬別期望HostB會收到這個數據包,因為當包到達FirewallB時,FirewallB被弄糊塗了,它根本不知道 1.1.1.1:9676 -> 2.2.2.2:6573的數據包應該轉給誰,當然這個包就會被丟棄並回一個ICMP包說Port不存在。但是,我們還是得到了我們想要的一些東西,那就是我們成功地告訴了FirewallA "如果有2.2.2.2:6573 -> 1.1.1.1:9676的數據包,請轉發到A.A.A.A:1111",這就是一個洞洞!!

2)接下來,和你想像的一樣,HostA通過Server中轉,告訴HostB,用埠2222發一個數據包到1.1.1.1:9676,HostB照辦了,而且這個包一定會被FirewallB NAT成 2.2.2.2:6573 -> 1.1.1.1:9676。這個回復的數據包同樣在FirewallB上鑽了個孔,凡是1.1.1.1:9676 -> 2.2.2.2:6573的包都會被轉發到B.B.B.B:2222,當數據包到達FirewallA時,FirewallA很高興地把2.2.2.2:6573 -> 1.1.1.1:9676的數據包轉發給A.A.A.A:1111。

3)大功告成了,HostA和HostB開始愉快的交談起來。

很簡單吧?不過實施起來還要注意幾點,否則你都不知道為什麼總連不上:

1) 步驟1中那個Port不存在的ICMP是個殺手,至少對Linux上用iptables做的NAT來講是這樣,因為FirewallA收到這個ICMP會關閉剛鑽上的洞洞,想辦法不讓FirewallB發這個ICMP或者讓FirewallA丟掉這個ICMP吧;

2) 時間問題,步驟1在FirewallA上開的洞洞是有時間限制的,通常為30-60秒吧,如果超時了都沒收到2.2.2.2:6573 -> 1.1.1.1:9676的包,洞洞會自動關閉,同樣步驟2以後,HostA也應該及時在發個數據包給B,以保證FirewallB上的洞洞不會因為超時而關閉。值得提一下的是多數NAT防火牆會在看見進出雙向的數據包後延長關閉洞洞的時間,Linux默認設置時會延長到3分鍾。

3) HostA不能連到HostB,並不表示HostB一定連不到HostA,反一下方向試試也許會有意外驚喜。

⑥ 計算機網路,UDP數據報的校驗和欄位是通過什麼來校驗源和目的IP的呢

其實這是一種加密技術用於對文件內容進行審計的方法,使用 精通讀文件把文件讀到內存中,再對文件內容作一個 MD5 校驗得到一串密碼,就是校驗和。

補充:

1、IP首部校驗和欄位是根據IP首部計算的校驗和碼,它不對首部後面的數據進行計算。ICMP、IGMP、UDP和TCP在它們各自的首部中均含有同時覆蓋首部和數據校驗和碼。
2、IP首部校驗和計算:
為了計算一份數據報的IP檢驗和,首先把檢驗和欄位置為0。然後,對首部中每個16bit進行二進制反碼求和(整個首部看成是由一串16bit的字組成),結果存在檢驗和欄位中。當收到一份IP數據報後,同樣對首部中每個16bit進行二進制反碼的求和。由於接收方在計算過程中包含了發送方存在首部中的檢驗和,因此,如果首部在傳輸過程中沒有發生任何差錯,那麼接收方計算的結果應該為全1。如果結果不是全1(即檢驗和錯誤),那麼IP就丟棄收到的數據報。但是不生成差錯報文,由上層去發現丟失的數據報並進行重傳。
3、TCP和UDP校驗和計算(兩者相同)
校驗和還包含—個96位的偽首標,理論上它位於TCP首標的前面。這個偽首標包含了源地址、目的地址、協議和TCP長度等欄位,這使得TCP能夠防止出現路由選擇錯誤的數據段。這些信息由網際協議(IP)承載,通過TCP/網路介面,在IP上運行的TCP調用參數或者結果中傳遞。

偽首部並非UDP數據報中實際的有效成分。偽首部是一個虛擬的數據結構,其中的信息是從數據報所在IP分組頭的分組頭中提取的,既不向下傳送也不向上遞交,而僅僅是為計算校驗和。
這樣的校驗和,既校驗了UDP用戶數據的源埠號和目的埠號以及UDP用戶數據報的數據部分,又檢驗了IP數據報的源IP地址和目的地址。(偽報頭保證UDP和TCP數據單元到達正確的目的地址。因此,偽報頭中包含IP地址並且作為計算校驗和需要考慮的一部分。最終目的端根據偽報頭和數據單元計算校驗和以驗證通信數據在傳輸過程中沒有改變而且到達了正確的目的地址。

⑦ 怎麼判斷UDP包來自哪個網卡

不管是tcp還是udp,最後都是根據路由表來決定下一跳的,也即決定從哪個網口發出。

在 windows上查看路由表的命令是
route print,
在 unix/linux下查看的命令
route

根據你發送包的 destination IP,可以從路由表中找到對應的條目,然後就知道從哪個網口發了,比如我的機器上路由信息是

Destination Gateway Genmask Flags Metric Ref Use Iface
135.252.213.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
0.0.0.0 135.252.213.1 0.0.0.0 UG 202 0 0 eth0

第一條說明如果目的地址是 135.252.213.x ,那麼就匹配第一條路由表項,那麼是從 eth0 網口發出。第二條全0的那條,就是默認路由,如果無法和任何一條表象匹配,那麼就會使用默認路由。

更多細節,這里一時半會也說不清,總之你知道是根據路由表來決定就行了,具體的你去網上查一些跟路由表有關的內容就知道了。