『壹』 計算機網路題目 為什麼是客戶發送給伺服器，怎麼看出來的
當目的埠數值大於49152時為客戶端使用埠，是由伺服器發給用戶的
『貳』 怎麼判斷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的那條，就是默認路由，如果無法和任何一條表象匹配，那麼就會使用默認路由。
更多細節，這里一時半會也說不清，總之你知道是根據路由表來決定就行了，具體的你去網上查一些跟路由表有關的內容就知道了。
『叄』 udp伺服器怎麼確定已經收到數據了呢，大佬幫忙解答下
伺服器有沒有收到數據，抓個包看看就行了。
recvfrom和sendto都是阻塞的。通常來說，由於網路連接具有緩沖區，sendto函數直接將數據復制至緩沖區後即可認為操作完成，因此很少阻塞（除非緩沖區已滿，它才會等待緩沖區足夠寫入後才能操作）；而recvfrom是從緩沖區讀數據，如果沒有數據則會一直阻塞。
解決阻塞的方法一般有兩種：使用setsockopt函數設置超時時長；在主線程中關閉socket，阻塞函數會報錯並退出。
『肆』 怎麼知道UDP用戶數據報是從客戶發給伺服器的和伺服器程序是TFTP
呵呵，UDP首部格式如下： （具體看TCP/IP詳解第11章）
2位元組源埠；2位元組目的埠；2位元組UDP長度（數據部分長度+首部長度）；2位元組校驗和
00 1C 代表UDP長度為十進制的28
所以數據部分的長度為：28-8=20，這里的8代表UDP首部長度
『伍』 高分！怎麼查看到正確顯示的udp數據包內容
用抓包分析工具如sniffer sniffer
下載地址：http://down.chinaz.com/soft/5542.htm
或Ethereal
網路中傳輸的都是2進制代碼，抓包工具將抓到的包以16進製表示。
然後根據報文類型解析報文的不同欄位。在以上2種抓包工具中，已經解析出報文大小、報文類型（UDP,TCP,STP,ARP等），目的ip和埠，源IP和埠。
至於報文內容就是要了解報文結構（每個欄位代表什麼意思），根據報文結構將16進制按照ASCLL碼進行解析。
『陸』 UDP flood
http://blog.51cto.com/hanjh8/1580701
UDPFlood是日漸猖厥的流量型DoS攻擊，原理也很簡單。常見的情況是利用大量UDP小包沖擊DNS伺服器或Radius認證伺服器、流媒體視頻伺服器。100k bps的UDPFlood經常將線路上的骨幹設備例如防火牆打癱，造成整個網段的癱瘓。由於UDP協議是一種無連接的服務，在UDPFLOOD攻擊中，攻擊者可發送大量偽造源IP地址的小UDP包。但是，由於UDP協議是無連接性的，所以只要開了一個UDP的埠提供相關服務的話，那麼就可針對相關的服務進行攻擊。
正常應用情況下，UDP包雙向流量會基本相等，而且大小和內容都是隨機的，變化很大。出現UDPFlood的情況下，針對同一目標IP的UDP包在一側大量出現，並且內容和大小都比較固定。
UDP協議與 TCP 協議不同，是無連接狀態的協議，並且UDP應用協議五花八門，差異極大，因此針對UDPFlood的防護非常困難。其防護要根據具體情況對待：?
判斷包大小，如果是大包攻擊則使用防止UDP碎片方法：根據攻擊包大小設定包碎片重組大小，通常不小於1500。在極端情況下，可以考慮丟棄所有UDP碎片。?
攻擊埠為業務埠：根據該業務UDP最大包長設置UDP最大包大小以過濾異常流量。?
攻擊埠為非業務埠：一個是丟棄所有UDP包，可能會誤傷正常業務；一個是建立UDP連接規則，要求所有去往該埠的UDP包，必須首先與TCP埠建立TCP連接。不過這種方法需要很專業的 防火牆 或其他防護設備支持
UDP攻擊是一種消耗對方資源，也消耗你自己的資源的攻擊方式，現在已經沒人使用這種過時的東西了，你攻擊了這個網站，其實也在消耗你的系統資源，說白了就是拼資源而已，看誰的帶寬大，看誰能堅持到最後，這種攻擊方式沒有技術含量，引用別人的話，不要以為洪水無所不能，攻擊程序在消耗對方資源的時候也在消耗你的資源
我們知道了TCP協議是一種面向連接的傳輸協議。但是UDP協議與TCP協議不同， UDP是一個無連接協議。使用UDP協議傳輸數據之前，客戶端和伺服器之間不建立連接，如果在從客戶端到伺服器端的傳遞過程中出現數據的丟失，協議本身並不能做出任何檢測或提示。因此，通常人們把UDP協議稱為不可靠的傳輸協議。
既然UDP是一種不可靠的網路協議，那麼還有什麼使用價值或必要呢？
其實不然，在有些情況下UDP協議可能會變得非常有用。因為UDP具有TCP所望塵莫及的速度優勢。雖然TCP協議中植入了各種安全保障功能，但是在實際執行的過程中會佔用大量的系統開銷，無疑使傳輸速度受到嚴重的影響。反觀UDP，由於排除了信息可靠傳遞機制，將安全和排序等功能移交給上層應用來完成，極大降低了執行時間，使傳輸速度得到了保證。
正是UDP協議的廣泛應用，為黑客們發動UDP Flood攻擊提供了平台。UDP Flood屬於帶寬類攻擊，黑客們通過僵屍網路向目標伺服器發起大量的UDP報文，這種UDP報文通常為大包，且速率非常快，通常會造成以下危害：
防火牆對UDP Flood的防禦並不能像SYN Flood一樣，進行源探測，因為它不建立連接。那應該怎麼防禦呢？
最初防火牆對UDP Flood的防禦方式就是限流，通過限流將鏈路中的UDP報文控制在合理的帶寬范圍之內。
防火牆上針對UDP Flood的限流有三種：
限流雖然可以有效緩解鏈路帶寬的壓力，但是這種方式簡單粗暴，容易對正常業務造成誤判。為了解決這個問題，防火牆又進一步推出了針對UDP Flood的指紋學習功能。
仔細分析，不難發現，UDP Flood攻擊報文具有一定的特點，這些攻擊報文通常都擁有相同的特徵欄位，比如都包含某一個字元串，或整個報文內容一致。這些欄位來自於DDoS工具自帶的默認字元串，所以防火牆是通過收集這些字元串來檢測UDP Flood。這種防禦演算法在現網使用很多，主要因為黑客為了加大攻擊頻率，快速、長時間擠占攻擊目標所在網路帶寬，在使用攻擊工具實現時直接在內存存放一段內容，然後高頻發送到攻擊目標，所以攻擊報文具有很高的相似性。而正常業務的UDP報文一般每個報文負載內容都是不一樣的，這樣可以減少誤判。
從下面的抓包中可以看出，到達相同目的IP地址的兩個UDP報文的載荷是完全一樣的，如果防火牆收到大量的類似這樣的UDP報文，那麼就有可能是發生了UDP Flood攻擊。
指紋學習是通過分析客戶端向伺服器發送的UDP報文載荷是否有大量的一致內容，來判定這個UDP報文是否異常。防火牆對到達指定目的地的UDP報文進行統計，當UDP報文達到告警閾值時，開始對UDP報文的指紋進行學習。如果相同的特徵頻繁出現，就會被學習成指紋，後續命中指紋的報文判定這是攻擊報文，作為攻擊特徵進行過濾。
強叔再給大家總結一下，防火牆防禦UDP Flood攻擊主要有兩種方式：限流和指紋學習，兩種方式各有利弊。限流方式屬於暴力型，可以很快將UDP流量限制在一個合理的范圍內，但是不分青紅皂白，超過就丟，可能會丟棄一些正常報文；而指紋學習屬於理智型，不會隨意丟棄報文，但是發生攻擊後需要有個指紋學習的過程。目前，指紋學習功能是針對UDP Flood攻擊的主流防禦手段，在華為防火牆產品中廣泛應用。
『柒』 udp通信客戶端與伺服器端的區別在哪
通常來講，客戶端是不需要綁定埠號的，而伺服器端是需要綁定監聽的埠號。其他的其實區別不是很大了，呵呵，從socket通信的角度來看，UDP通信屬於幀傳輸，TCP則是流傳輸，在幀傳輸過程中對於消息的次序和到達情況沒有需求，所以UDP屬於不可靠傳輸，不需要確認和排序。這樣在客戶端和伺服器端的實現上就沒有太大的差別了。
但是客戶端其實也可以用bind來綁定埠的，你在Linux下寫一個簡單的測試程序就知道了，嘿嘿。
『捌』 如何分析udp報文，從而獲取源地址
1、寫了一個UDP 的小程序，有一個UDP 的server,而且有UDP的client。
然後執行server和client，然後用tcpmp將該埠的UDP數據報文抓取出來。
執行的過程是這樣的。
client向server發送"xiyou"
server向client應答"wangzhe"
client程序在主機example上運行(192.168.1.144)
server程序在主機linux上運行(192.168.1.101)
------------------------------------------------------------------------------------------------------------
2、UDP數據報文。
linux@linux:~$ sudo tcpmp -vvv -X udp port 7777
[sudo] password for linux:
tcpmp: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:03:01.923227 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 48)
example.local.43521 > linux.7777: [udp sum ok] UDP, length 20
0x0000: 4500 0030 0000 4000 4011 b677 c0a8 0190 E..0..@[email protected]....
0x0010: c0a8 0165 aa01 1e61 001c 4c34 7869 796f ...e...a..L4xiyo
0x0020: 7500 0000 0000 0000 0000 0000 0000 0000 u...............
11:03:01.923343 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 48)
linux.7777 > example.local.43521: [bad udp cksum 6869!] UDP, length 20
0x0000: 4500 0030 0000 4000 4011 b677 c0a8 0165 E..0..@[email protected]
0x0010: c0a8 0190 1e61 aa01 001c 8473 7761 6e67 .....a.....swang
0x0020: 7a68 6500 0000 0000 0000 0000 0000 0000 zhe.............
由上面的報文可知，有兩個UDP數據報文。
第一個報文是example主機上的client向server發送數據。
4500 0030 0000 4000 4011 b677 c0a8 0190 c0a8 0165 這20個數據是IP首部。
aa01 1e61 001c 4c34 這8個位元組是UDP的首部。
7869 796f 7500 0000 0000 0000 0000 0000 0000 0000 這20個數據是我用sendto函數發送的
數據。
而將char req[20] = "xiyou" 的ASCII碼（16進制）就是：
78 69 79 6f 75 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
第二個報文是linux向主機example做出的應答。
4500 0030 0000 4000 4011 b677 c0a8 0165 c0a8 0190 這20個數據是IP首部。
1e61 aa01 001c 8473 這8個位元組是UDP首部。
7761 6e67 7a68 6500 0000 0000 0000 0000 0000 0000 這20個數據是應用層的數據。
而將char reply[20] = "wangzhe"的ASCII碼(16進制)就是:
77 61 6e 67 7a 68 65 0 0 0 0 0 0 0 0 0 0 0 0 0
由此看出，應用層的數據沒有夾雜其他的參數，全部是數據，均是字元的ASCII碼。
-----------------------------------------------------------------------
附帶網路程序：
udp_server.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <sys/types.h>
#include <string.h>
int main(void)
{
struct sockaddr_in server,client;
int sockfd;
int cli_len = 0,n;
char req[20] = {0},reply[20] = {0};
sockfd = socket(AF_INET,SOCK_DGRAM,0);
if (sockfd < 0) {
perror("socket error!\n");
exit(-1);
}
memset(&server,0,sizeof(struct sockaddr_in));
server.sin_family = AF_INET;
server.sin_addr.s_addr = htonl(INADDR_ANY);
server.sin_port = htons(7777);
if (bind(sockfd,(struct sockaddr *)&server,sizeof(server)) < 0) {
perror("bind error!\n");
exit(-1);
}
for (;;) {
cli_len = sizeof(struct sockaddr_in);
n = recvfrom(sockfd,req,20,0,(struct sockaddr *)&client,&cli_len);
if (n < 0) {
perror("recvfrom error!\n");
exit(-1);
}
printf("hello!\n");
strncpy(reply,"wangzhe",sizeof("wangzhe"));
if (sendto(sockfd,reply,20,0,(struct sockaddr *)&client,sizeof(client)) != 20) {
perror("sendto error!\n");
exit(-1);
}
}
return 0;
}
-----------------------------------------------------------------------------------------------------------
udp_client.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <sys/types.h>
#include <string.h>
int main(void)
{
int sockfd,n;
struct sockaddr_in server;
char req[20]={0},reply[20]={0};
sockfd = socket(AF_INET,SOCK_DGRAM,0);
if (sockfd < 0) {
perror("socket error!\n");
exit(-1);
}
memset(&server,0,sizeof(server));
server.sin_family = AF_INET;
server.sin_addr.s_addr = inet_addr("192.168.1.101");
server.sin_port = htons(7777);
strncpy(req,"xiyou",sizeof("xiyou"));
printf("sendto req to server:%s\n",req);
if (sendto(sockfd,req,20,0,(struct sockaddr *)&server,sizeof(server)) != 20) {
perror("sendto error!\n");
exit(-1);
}
if ((n = recvfrom(sockfd,reply,20,0,(struct sockaddr *)NULL,(int *)NULL)) < 0) {
perror("recvfrom error!\n");
exit(-1);
}
printf("recv reply from server :%s\n",reply);
exit(0);
}
--------------------------------------------------------------------------------------------------------
『玖』 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兩種協議的權衡之處。根據不同的環境和特點，兩種傳輸協議都將在今後的網路世界中發揮更加重要的作用.
『拾』 怎麼看這個報文是請求報文還是應答報文
是通過看源埠與目標埠來實現的。從報文的目標埠是35H可以知道，其目標埠是53，這個是DNS服務埠號。由於是目標埠，因此肯定是發送至DNS伺服器的報文，因此是請求報文。另外，其協議號是11H即17，這是UDP協議，說明DNS是使用UDP協議傳輸的。