‘壹’ 计算机网络题目 为什么是客户发送给服务器，怎么看出来的
当目的端口数值大于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协议传输的。