udp

udp的控制块udp_pcb结构中有一个回调函数：void (* recv)(void *arg, struct udp_pcb *pcb, struct pbuf *p, struct ip_addr *addr, u16_t port);函数的入口参数：pcb，udp块指针 p，udp包传输的数据 addr，远程主机ip port，远程主机端口底层的MAC，我就不知道怎么读取了

UDP：用户数据报协议（UDP：UserDatagramProtocol）用户数据报协议（UDP）是ISO参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。UDP协议基本上是IP协议与上层协议的接口。UDP协议适用端口分辨运行在同一台设备上的多个应用程序。由于大多数网络应用程序都在同一台机器上运行，计算机上必须能够确保目的地机器上的软件程序能从源地址机器处获得数据包，以及源计算机能收到正确的回复。这是通过使用UDP的“端口号”完成的。例如，如果一个工作站希望在工作站128.1.123.1上使用域名服务系统，它就会给数据包一个目的地址128.1.123.1，并在UDP头插入目标端口号53。源端口号标识了请求域名服务的本地机的应用程序，同时需要将所有由目的站生成的响应包都指定到源主机的这个端口上。UDP端口的详细介绍可以参照相关文章。a7p是Authorware的源文件，你需要用Authorware将它打包成exe文件才能直接运行。

UDP Server程序1、编写UDP Server程序的步骤(1)使用socket()来建立一个UDP socket，第二个参数为SOCK_DGRAM。(2)初始化sockaddr_in结构的变量，并赋值。sockaddr_in结构定义：struct sockaddr_in {uint8_t sin_len;sa_family_t sin_family;in_port_t sin_port;struct in_addr sin_addr;char sin_zero[8];};这里使用“08”作为服务程序的端口，使用“INADDR_ANY”作为绑定的IP地址即任何主机上的地址。(3)使用bind()把上面的socket和定义的IP地址和端口绑定。这里检查bind()是否执行成功，如果有错误就退出。这样可以防止服务程序重复运行的问题。(4)进入无限循环程序，使用recvfrom()进入等待状态，直到接收到客户程序发送的数据，就处理收到的数据，并向客户程序发送反馈。这里是直接把收到的数据发回给客户程序。2、udpserv.c程序内容：#include <sys/types.h>#include <sys/socket.h>#include <string.h>#include <netinet/in.h>#include <stdio.h>#include <stdlib.h>#define MAXLINE 80#define SERV_PORT 8888void do_echo(int sockfd, struct sockaddr *pcliaddr, socklen_t clilen){int n;socklen_t len;char mesg[MAXLINE];for(;;){len = clilen;/* waiting for receive data */n = recvfrom(sockfd, mesg, MAXLINE, 0, pcliaddr, &len);/* sent data back to client */sendto(sockfd, mesg, n, 0, pcliaddr, len);}}int main(void){int sockfd;struct sockaddr_in servaddr, cliaddr;sockfd = socket(AF_INET, SOCK_DGRAM, 0); /* create a socket *//* init servaddr */bzero(&servaddr, sizeof(servaddr));servaddr.sin_family = AF_INET;servaddr.sin_addr.s_addr = htonl(INADDR_ANY);servaddr.sin_port = htons(SERV_PORT);/* bind address and port to socket */if(bind(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr)) == -1){perror("bind error");exit(1);}do_echo(sockfd, (struct sockaddr *)&cliaddr, sizeof(cliaddr));return 0;}UDP Client程序1、编写UDP Client程序的步骤(1)初始化sockaddr_in结构的变量，并赋值。这里使用“8888”作为连接的服务程序的端口，从命令行参数读取IP地址，并且判断IP地址是否符合要求。(2)使用socket()来建立一个UDP socket，第二个参数为SOCK_DGRAM。(3)使用connect()来建立与服务程序的连接。与TCP协议不同，UDP的connect()并没有与服务程序三次握手。上面我们说了UDP是非连接的，实际上也可以是连接的。使用连接的UDP，kernel可以直接返回错误信息给用户程序，从而避免由于没有接收到数据而导致调用recvfrom()一直等待下去，看上去好像客户程序没有反应一样。(4)向服务程序发送数据，因为使用连接的UDP，所以使用write()来替代sendto()。这里的数据直接从标准输入读取用户输入。(5)接收服务程序发回的数据，同样使用read()来替代recvfrom()。(6)处理接收到的数据，这里是直接输出到标准输出上。2、udpclient.c程序内容：#include <sys/types.h>#include <sys/socket.h>#include <string.h>#include <netinet/in.h>#include <stdio.h>#include <stdlib.h>#include <arpa/inet.h>#include <unistd.h>#define MAXLINE 80#define SERV_PORT 8888void do_cli(FILE *fp, int sockfd, struct sockaddr *pservaddr, socklen_t servlen){int n;char sendline[MAXLINE], recvline[MAXLINE + 1];/* connect to server */if(connect(sockfd, (struct sockaddr *)pservaddr, servlen) == -1){perror("connect error");exit(1);}while(fgets(sendline, MAXLINE, fp) != NULL){/* read a line and send to server */write(sockfd, sendline, strlen(sendline));/* receive data from server */n = read(sockfd, recvline, MAXLINE);if(n == -1){perror("read error");exit(1);}recvline[n] = 0; /* terminate string */fputs(recvline, stdout);}}int main(int argc, char **argv){int sockfd;struct sockaddr_in srvaddr;/* check args */if(argc != 2){printf("usage: udpclient <IPaddress> ");exit(1);}/* init servaddr */bzero(&servaddr, sizeof(servaddr));servaddr.sin_family = AF_INET;servaddr.sin_port = htons(SERV_PORT);if(inet_pton(AF_INET, argv[1], &servaddr.sin_addr) <= 0){printf("[%s] is not a valid IPaddress ", argv[1]);exit(1);}sockfd = socket(AF_INET, SOCK_DGRAM, 0);do_cli(stdin, sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr));return 0;}运行例子程序1、编译例子程序使用如下命令来编译例子程序：gcc -Wall -o udpserv udpserv.cgcc -Wall -o udpclient udpclient.c编译完成生成了udpserv和udpclient两个可执行程序。2、运行UDP Server程序执行./udpserv &命令来启动服务程序。我们可以使用netstat -ln命令来观察服务程序绑定的IP地址和端口，部分输出信息如下：Active Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address Statetcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTENtcp 0 0 0.0.0.0:111 0.0.0.0:* LISTENtcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTENtcp 0 0 127.0.0.1:631 0.0.0.0:* LISTENudp 0 0 0.0.0.0:32768 0.0.0.0:*udp 0 0 0.0.0.0:8888 0.0.0.0:*udp 0 0 0.0.0.0:111 0.0.0.0:*udp 0 0 0.0.0.0:882 0.0.0.0:*可以看到udp处有“0.0.0.0:8888”的内容，说明服务程序已经正常运行，可以接收主机上任何IP地址且端口为8888的数据。如果这时再执行./udpserv &命令，就会看到如下信息：bind error: Address already in use说明已经有一个服务程序在运行了。3、运行UDP Client程序执行./udpclient 127.0.0.1命令来启动客户程序，使用127.0.0.1来连接服务程序，执行效果如下：Hello, World!Hello, World!this is a testthis is a test^d输入的数据都正确从服务程序返回了，按ctrl+d可以结束输入，退出程序。如果服务程序没有启动，而执行客户程序，就会看到如下信息：$ ./udpclient 127.0.0.1testread error: Connection refused说明指定的IP地址和端口没有服务程序绑定，客户程序就退出了。这就是使用connect()的好处，注意，这里错误信息是在向服务程序发送数据后收到的，而不是在调用connect()时。如果你使用tcpdump程序来抓包，会发现收到的是ICMP的错误信息。

NAT有两大类，基本NAT和NAPT。 静态NAT：一个公网IP对应一个内部IP，一对一转换 动态NAT：N个公网IP对应M个内部IP，不固定的一对一转换关系 现在基本使用这种，又分为对称和锥型NAT。 锥型NAT ，有完全锥型、受限制锥型、端口受限制锥型三种： 对称NAT ： 把所有来自相同内部IP地址和端口号，到特定目的IP地址和端口号的请求映射到相同的外部IP地址和端口。如果同一主机使用不同的源地址和端口对，发送的目的地址不同，则使用不同的映射。只有收到了一个IP包的外部主机才能够向该内部主机发送回一个UDP包。对称的NAT不保证所有会话中的(私有地址，私有端口)和(公开IP，公开端口)之间绑定的一致性。相反，它为每个新的会话分配一个新的端口号。 对称NAT是一个请求对应一个端口，非对称NAT是多个请求对应一个端口(象锥形，所以叫Cone NAT)。 连接服务器为A，NAT检测服务器为B。 第一步：当一个接收客户端(Endpoint-Receiver ,简称 EP-R)需要接收文件信息时，在其向连接服务器发送文件请求的同时紧接着向检测服务器发送NAT检测请求。此处再次强调是“紧接着”，因为对于对称型NAT来说，这个操作可以直接算出其地址分配的增量(⊿p)。 第二步：当EP-R收到A或B的反馈信息时发现其外部地址与自身地址不同时就可以确定自己在NAT后面；否则，就是公网IP。 第三步：由服务器A向B发送其获得的EP-R的外部映射地址(IPa/Porta)，服务器B获得后进行比较，如果端口不同，则说明这是对称型NAT，同时可以直接计算出其分配增量： ⊿p=Portb-Porta 第四步：如果端口号相同，则由B向EP-R的Porta发送连接请求，如果EP-R有响应，则说明EP-R没有IP和Port的限制，属于全ConeNAT类型。 第五步：如果没有响应，则由服务器B使用其新端口b"向EP-R的Portb端口发送连接请求，如果有响应，则说明EP-R只对IP限制，属于限制性ConeNAT类型；否则就是对IP和port都限制，属于端口限制性ConeNAT类型。 通过上述五步基本可以全部检测出EP-R是否在公网，还是在某种NAT后面。 这也是一项可选配置任务，可根据需要为NAT 地址映射表配置老化时间，以控制用户对NAT 配置的使用，确保内、外网的通信安全。 配置NAT 地址映射表项老化时间的方法也很简单，只须在系统视图下使用firewall-nat session { dns | ftp | ftp-data | http | icmp | tcp | tcp-proxy | udp | sip | sip-media | rtsp |rtsp-media }aging-time time-value 命令配置即可。参数 time-value的取值范围为1～65 535的整数秒。如果要配置多个会话表项的超时时间需要分别用本命令配置。 缺省情况下，各协议的老化时间为：DNS（120 s）、ftp（120 s）、ftp-data（120 s）、HTTP（120 s）、icmp（20 s）、tcp（600 s）、tcp-proxy（10 s）、udp（120 s）、sip（1 800 s）、sip-media （ 120 s ）、rtsp （ 60 s ）、rtsp-media （ 120 s ）， 可用undo firewall-natsession { all | dns | ftp | ftp-data | http | icmp | tcp | tcp-proxy | udp | sip | sip-media | rtsp |rtsp-media } aging-time 命令恢复对应会话表项的超时时间为缺省值。 1、 中间服务器保存信息、并能发出建立UDP隧道的命令 2、 网关均要求为Cone NAT类型。Symmetric NAT不适合。 3、 完全圆锥型网关可以无需建立udp隧道，但这种情况非常少，要求双方均为这种类型网关的更少。 4、 假如X1网关为Symmetric NAT， Y1为Address Restricted Cone NAT 或Full Cone NAT型网关，各自建立隧道后，A1可通过X1发送数据报给Y1到B1(因为Y1最多只进行IP级别的甄别)，但B2发送给X1的将会被丢弃（因为发送来的数据报中端口与X1上存在会话的端口不一致，虽然IP地址一致），所以同样没有什么意义。 5、 假如双方均为Symmetric NAT的情形，新开了端口，对方可以在不知道的情况下尝试猜解，也可以达到目的，但这种情形成功率很低，且带来额外的系统开支，不是个好的解决办法。 6、 不同网关型设置的差异在于，对内会采用替换IP的方式、使用不同端口不同会话的方式，使用相同端口不同会话的方式；对外会采用什么都不限制、限制IP地址、限制IP地址及端口。 7、 这里还没有考虑同一内网不同用户同时访问同一服务器的情形，如果此时网关采用AddressRestricted Cone NAT 或Full Cone NAT型，有可能导致不同用户客户端可收到别人的数据包，这显然是不合适的。 为什么网上讲到的P2P打洞基本上都是基于UDP协议的打洞？难道TCP不可能打洞？还是TCP打洞难于实现？ 假设现在有内网客户端A和内网客户端B，有公网服务端S。 如果A和B想要进行UDP通信，则必须穿透双方的NAT路由。假设为NAT-A和NAT-B。 S也和A B 分别建立了会话，由S发到NAT-A的数据包会被NAT-A直接转发给A， 由S发到NAT-B的数据包会被NAT-B直接转发给B，除了S发出的数据包之外的则会被丢弃。 所以：现在A B 都能分别和S进行全双工通讯了，但是A B之间还不能直接通讯。 并转发给A了（即B现在能访问A了）；再由S命令B向A的公网IP发送一个数据包，则 NAT-B能接收来自NAT-A的数据包并转发给B了（即A现在能访问B了）。 以上就是“打洞”的原理。 <pre style="margin: 0px; padding: 0px; white-space: pre-wrap; overflow-wrap: break-word;">为了保证A的路由器有与B的session，A要定时与B做心跳包，同样，B也要定时与A做心跳，这样，双方的通信通道都是通的，就可以进行任意的通信了。</pre> API造成的。 UDP的socket允许多个socket绑定到同一个本地端口，而TCP的socket则不允许。 这是这样一个意思：A B要连接到S，肯定首先A B双方都会在本地创建一个socket， 去连接S上的socket。创建一个socket必然会绑定一个本地端口（就算应用程序里面没写 端口，实际上也是绑定了的，至少java确实如此），假设为8888，这样A和B才分别建立了到 S的通信信道。接下来就需要打洞了，打洞则需要A和B分别发送数据包到对方的公网IP。但是 问题就在这里：因为NAT设备是根据端口号来确定session，如果是UDP的socket，A B可以 分别再创建socket，然后将socket绑定到8888，这样打洞就成功了。但是如果是TCP的 socket，则不能再创建socket并绑定到8888了，这样打洞就无法成功。 **UDP打洞**的过程大致如此： 1、双方都通过UDP与服务器通讯后，网关默认就是做了一个外网IP和端口号 与你内网IP与端口号的映射，这个无需设置的，服务器也不需要知道客户的真正内网IP 2、用户A先通过服务器知道用户B的外网地址与端口 3、用户A向用户B的外网地址与端口发送消息， 4、在这一次发送中，用户B的网关会拒收这条消息，因为它的映射中并没有这条规则。 5、但是用户A的网关就会增加了一条允许规则，允许接收从B发送过来的消息 6、服务器要求用户B发送一个消息到用户A的外网IP与端口号 7、用户B发送一条消息，这时用户A就可以接收到B的消息，而且网关B也增加了允许规则 8、之后，由于网关A与网关B都增加了允许规则，所以A与B都可以向对方的外网IP和端口号发送消息。 TCP打洞 技术： tcp打洞也需要NAT设备支持才行。 tcp的打洞流程和udp的基本一样，但tcp的api决定了tcp打洞的实现过程和udp不一样。 tcp按cs方式工作，一个端口只能用来connect或listen，所以需要使用端口重用，才能利用本地nat的端口映射关系。（设置SO_REUSEADDR，在支持SO_REUSEPORT的系统上，要设置这两个参数。） 连接过程：（以udp打洞的第2种情况为例（典型情况）） nat后的两个peer，A和B，A和B都bind自己listen的端口，向对方发起连接（connect），即使用相同的端口同时连接和等待连接。因为A和B发出连接的顺序有时间差，假设A的syn包到达B的nat时，B的syn包还没有发出，那么B的nat映射还没有建立，会导致A的连接请求失败（连接失败或无法连接，如果nat返回RST或者icmp差错，api上可能表现为被RST；有些nat不返回信息直接丢弃syn包（反而更好）），（应用程序发现失败时，不能关闭socket，closesocket（）可能会导致NAT删除端口映射；隔一段时间（1-2s）后未连接还要继续尝试）；但后发B的syn包在到达A的nat时，由于A的nat已经建立的映射关系，B的syn包会通过A的nat，被nat转给A的listen端口，从而进去三次握手，完成tcp连接。 从应用程序角度看，连接成功的过程可能有两种不同表现：（以上述假设过程为例） 1、连接建立成功表现为A的connect返回成功。即A端以TCP的同时打开流程完成连接。 2、A端通过listen的端口完成和B的握手，而connect尝试持续失败，应用程序通过accept获取到连接，最终放弃connect（这时可closesocket(conn_fd)）。 多数Linux和Windows的协议栈表现为第2种。 但有一个问题是，建立连接的client端，其connect绑定的端口号就是主机listen的端口号，或许这个peer后续还会有更多的这种socket。虽然理论上说，socket是一个五元组，端口号是一个逻辑数字，传输层能够因为五元组的不同而区分开这些socket，但是是否存在实际上的异常，还有待更多观察。 1、Windows XP SP2操作系统之前的主机，这些主机不能正确处理TCP同时开启，或者TCP套接字不支持SO_REUSEADDR的参数。需要让AB有序的发起连接才可能完成。 上述tcp连接过程，仅对NAT1、2、3有效，对NAT4（对称型）无效。 由于对称型nat通常采用规律的外部端口分配方法，对于nat4的打洞，可以采用端口预测的方式进行尝试。 ALG（应用层网关） ：它可以是一个设备或插件，用于支持SIP协议，主要类似与在网关上专门开辟一个通道，用于建立内网与外网的连接，也就是说，这是一种定制的网关。更多只适用于使用他们的应用群体内部之间。 UpnP ：它是让网关设备在进行工作时寻找一个全球共享的可路由IP来作为通道，这样避免端口造成的影响。要求设备支持且开启upnp功能，但大部分时候，这些功能处于安全考虑，是被关闭的。即时开启，实际应用效果还没经过测试。 STUN（Simple Traversalof UDP Through Network）： 这种方式即是类似于我们上面举例中服务器C的处理方式。也是目前普遍采用的方式。但具体实现要比我们描述的复杂许多，光是做网关Nat类型判断就由许多工作，RFC3489中详细描述了。 TURN(Traveral Using Relay NAT)： 该方式是将所有的数据交换都经由服务器来完成，这样NAT将没有障碍，但服务器的负载、丢包、延迟性就是很大的问题。目前很多游戏均采用该方式避开NAT的问题。这种方式不叫p2p。 ICE(Interactive Connectivity Establishment)： 是对上述各种技术的综合，但明显带来了复杂性。

你好！是DOS下的程序吗？

UDP Server程序1、编写UDP Server程序的步骤(1)使用socket()来建立一个UDP socket，第二个参数为SOCK_DGRAM。(2)初始化sockaddr_in结构的变量，并赋值。sockaddr_in结构定义：struct sockaddr_in {uint8_t sin_len;sa_family_t sin_family;in_port_t sin_port;struct in_addr sin_addr;char sin_zero[8];};这里使用“08”作为服务程序的端口，使用“INADDR_ANY”作为绑定的IP地址即任何主机上的地址。(3)使用bind()把上面的socket和定义的IP地址和端口绑定。这里检查bind()是否执行成功，如果有错误就退出。这样可以防止服务程序重复运行的问题。(4)进入无限循环程序，使用recvfrom()进入等待状态，直到接收到客户程序发送的数据，就处理收到的数据，并向客户程序发送反馈。这里是直接把收到的数据发回给客户程序。2、udpserv.c程序内容：#include <sys/types.h>#include <sys/socket.h>#include <string.h>#include <netinet/in.h>#include <stdio.h>#include <stdlib.h>#define MAXLINE 80#define SERV_PORT 8888void do_echo(int sockfd, struct sockaddr *pcliaddr, socklen_t clilen){int n;socklen_t len;char mesg[MAXLINE];for(;;){len = clilen;/* waiting for receive data */n = recvfrom(sockfd, mesg, MAXLINE, 0, pcliaddr, &len);/* sent data back to client */sendto(sockfd, mesg, n, 0, pcliaddr, len);}}int main(void){int sockfd;struct sockaddr_in servaddr, cliaddr;sockfd = socket(AF_INET, SOCK_DGRAM, 0); /* create a socket *//* init servaddr */bzero(&servaddr, sizeof(servaddr));servaddr.sin_family = AF_INET;servaddr.sin_addr.s_addr = htonl(INADDR_ANY);servaddr.sin_port = htons(SERV_PORT);/* bind address and port to socket */if(bind(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr)) == -1){perror("bind error");exit(1);}do_echo(sockfd, (struct sockaddr *)&cliaddr, sizeof(cliaddr));return 0;}UDP Client程序1、编写UDP Client程序的步骤(1)初始化sockaddr_in结构的变量，并赋值。这里使用“8888”作为连接的服务程序的端口，从命令行参数读取IP地址，并且判断IP地址是否符合要求。(2)使用socket()来建立一个UDP socket，第二个参数为SOCK_DGRAM。(3)使用connect()来建立与服务程序的连接。与TCP协议不同，UDP的connect()并没有与服务程序三次握手。上面我们说了UDP是非连接的，实际上也可以是连接的。使用连接的UDP，kernel可以直接返回错误信息给用户程序，从而避免由于没有接收到数据而导致调用recvfrom()一直等待下去，看上去好像客户程序没有反应一样。(4)向服务程序发送数据，因为使用连接的UDP，所以使用write()来替代sendto()。这里的数据直接从标准输入读取用户输入。(5)接收服务程序发回的数据，同样使用read()来替代recvfrom()。(6)处理接收到的数据，这里是直接输出到标准输出上。2、udpclient.c程序内容：#include <sys/types.h>#include <sys/socket.h>#include <string.h>#include <netinet/in.h>#include <stdio.h>#include <stdlib.h>#include <arpa/inet.h>#include <unistd.h>#define MAXLINE 80#define SERV_PORT 8888void do_cli(FILE *fp, int sockfd, struct sockaddr *pservaddr, socklen_t servlen){int n;char sendline[MAXLINE], recvline[MAXLINE + 1];/* connect to server */if(connect(sockfd, (struct sockaddr *)pservaddr, servlen) == -1){perror("connect error");exit(1);}while(fgets(sendline, MAXLINE, fp) != NULL){/* read a line and send to server */write(sockfd, sendline, strlen(sendline));/* receive data from server */n = read(sockfd, recvline, MAXLINE);if(n == -1){perror("read error");exit(1);}recvline[n] = 0; /* terminate string */fputs(recvline, stdout);}}int main(int argc, char **argv){int sockfd;struct sockaddr_in srvaddr;/* check args */if(argc != 2){printf("usage: udpclient <IPaddress> ");exit(1);}/* init servaddr */bzero(&servaddr, sizeof(servaddr));servaddr.sin_family = AF_INET;servaddr.sin_port = htons(SERV_PORT);if(inet_pton(AF_INET, argv[1], &servaddr.sin_addr) <= 0){printf("[%s] is not a valid IPaddress ", argv[1]);exit(1);}sockfd = socket(AF_INET, SOCK_DGRAM, 0);do_cli(stdin, sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr));return 0;}运行例子程序1、编译例子程序使用如下命令来编译例子程序：gcc -Wall -o udpserv udpserv.cgcc -Wall -o udpclient udpclient.c编译完成生成了udpserv和udpclient两个可执行程序。2、运行UDP Server程序执行./udpserv &命令来启动服务程序。我们可以使用netstat -ln命令来观察服务程序绑定的IP地址和端口，部分输出信息如下：Active Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address Statetcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTENtcp 0 0 0.0.0.0:111 0.0.0.0:* LISTENtcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTENtcp 0 0 127.0.0.1:631 0.0.0.0:* LISTENudp 0 0 0.0.0.0:32768 0.0.0.0:*udp 0 0 0.0.0.0:8888 0.0.0.0:*udp 0 0 0.0.0.0:111 0.0.0.0:*udp 0 0 0.0.0.0:882 0.0.0.0:*可以看到udp处有“0.0.0.0:8888”的内容，说明服务程序已经正常运行，可以接收主机上任何IP地址且端口为8888的数据。如果这时再执行./udpserv &命令，就会看到如下信息：bind error: Address already in use说明已经有一个服务程序在运行了。3、运行UDP Client程序执行./udpclient 127.0.0.1命令来启动客户程序，使用127.0.0.1来连接服务程序，执行效果如下：Hello, World!Hello, World!this is a testthis is a test^d输入的数据都正确从服务程序返回了，按ctrl+d可以结束输入，退出程序。如果服务程序没有启动，而执行客户程序，就会看到如下信息：$ ./udpclient 127.0.0.1testread error: Connection refused说明指定的IP地址和端口没有服务程序绑定，客户程序就退出了。这就是使用connect()的好处，注意，这里错误信息是在向服务程序发送数据后收到的，而不是在调用connect()时。如果你使用tcpdump程序来抓包，会发现收到的是ICMP的错误信息。

这个差太多了，在知道的搜索栏，搜索 java udp

你是要客户端的还是要服务器端的

测试UDP端口方法TCP端口大家都知道,比如80端口，可以使用 telnet ip 80，来验证端口是否正常监听，那UDP端口是否可以同样测试呢？详细如下：下面我们来进行测试，123端口是服务器42.11.12.13打开的UDP端口，udp 0 0 42.11.12.13:123 0.0.0.0:* 1472/ntpd1.我们首先使用telnet连接，如下[root@kr-sg-test ~]# telnet 42.11.12.13 123Trying 42.11.12.13…telnet: connect to address 42.11.12.13: Connection refusedtelnet: Unable to connect to remote host: Connection refused很明显，telnet连接被拒绝，无法测试成功。2.我们使用nc来进行测试，如下[root@kr-sg-test ~]# nc -vuz 42.11.12.13 123Connection to 42.11.12.13 123 port [udp/ntp] succeeded!结果证明UDP 123端口正常监听。nc命令用法：usage: nc [-46DdhklnrStUuvzC] [-i interval] [-p source_port][-s source_ip_address] [-T ToS] [-w timeout] [-X proxy_version][-x proxy_address[:port]] [hostname] [port[s]]

TCP端口大家都知道,比如80端口，可以使用 telnet ip 80，来验证端口是否正常监听，那UDP端口是否可以同样测试呢？详细如下：下面我们来进行测试，123端口是服务器42.11.12.13打开的UDP端口，udp 0 0 42.11.12.13:123 0.0.0.0:* 1472/ntpd1.我们首先使用telnet连接，如下[root@kr-sg-test ~]# telnet 42.11.12.13 123Trying 42.11.12.13…telnet: connect to address 42.11.12.13: Connection refusedtelnet: Unable to connect to remote host: Connection refused很明显，telnet连接被拒绝，无法测试成功。2.我们使用nc来进行测试，如下[root@kr-sg-test ~]# nc -vuz 42.11.12.13 123Connection to 42.11.12.13 123 port [udp/ntp] succeeded!结果证明UDP 123端口正常监听。nc命令用法：usage: nc [-46DdhklnrStUuvzC] [-i interval] [-p source_port][-s source_ip_address] [-T ToS] [-w timeout] [-X proxy_version][-x proxy_address[:port]] [hostname] [port[s]]

1、在键盘上按“win+r”组合键，打开运行界面，输入“cmd”命令;　　2、在命令提示符界面中，输入“netstat-s-pudp”命令，按回车。即可显示本机所有udp连接情况。

1.在键盘上按“WIN+R”组合键,打开运行界面,输入“CMD”命令;2.在命令提示符界面中,输入“netstat -s -p udp”命令,按回车。即可显示本机所有UDP连接情况。

1、首先看TCP/UDP的英文缩写可以知道，他们都有一个P字母，也就是协议的英文，说明他们都是表示一种协议的规则。而单播、广播、组播则表示的是数据在网络中“播放”的形式，是指有一个人能听到还是让特定的人群听得到，还是让所有的人都听的到的区别。UDP支持单播、组播和广播，而TCP不支持广播。 2、理论上讲路由器和路由器连接要使用的是交叉线。 3、你使用的网页程序和提交的所有数据都是存储在baidu的服务器上，管理员可以通过多种方式对任何内容进行无限制的修改。大部分的方式是采用不同用户对数据的操作权限不同来进行区别的，因为这样对程序和数据都最安全。 这里先简单的说一下TCP与UDP的区别： 1。基于连接与无连接 2。对系统资源的要求（TCP较多，UDP少） 3。UDP程序结构较简单 4。流模式与数据报模式 5。TCP保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证另外结合GPRS网络的情况具体的谈一下他们的区别： 1。TCP传输存在一定的延时，大概是1600MS（移动提供），UDP响应速度稍微快一些。 2。TCP包头结构源端口16位目标端口 16位 序列号 32位 回应序号 32位 TCP头长度 4位 reserved 6位 控制代码6位 窗口大小16位偏移量16位校验和16位选项32位(可选) 这样我们得出了TCP包头的最小大小.就是20字节. UDP包头结构源端口16位目的端口16位长度16位校验和 16位 UDP的包小很多.确实如此.因为UDP是非可靠连接.设计初衷就是尽可能快的将数据包发送出去.所以UDP协 议显得非常精简.

我们经常会看到UDP这个词，但是却很少有人知道它的意思，今天我就来带大家了解一下吧。 UDP介绍 UDP是指用户数据报协议，是在网络上的不同计算机上运行的程序使用的Internet协议套件的一部分。UDP用于发送称为数据报的短消息，但总的来说，它是一种不可靠的无连接协议。UDP在RFC768中正式定义，由DavidP.Reed制定。 用户数据报协议 用户数据报协议是用于客户端 u2013 服务器网络应用的开放系统互连（OSI）传输层协议。UDP 使用简单的传输模型，但不使用握手对话框来提高可靠性，排序和数据完整性。该协议假定不需要错误检查和纠正，从而避免在网络接口级别进行处理。 UDP的应用范围 UDP 广泛用于视频会议和实时计算机游戏。该协议允许丢弃单个数据报，并以与发送它们不同的顺序接收 UDP 数据报，从而实现更好的性能。 综上所述，UDP是指用户数据报协议，用于发送称为数据报的短消息，它是一种不可靠的无连接协议。用户数据报协议是用于客户端u2013服务器网络应用的开放系统互连（OSI）传输层协议。你了解了吗？

有关知识 基本概念 单播：两个主机间单对单的通信 广播：一个主机对整个局域网上所有主机上的数据通信（网络地址全1） 单播和广播是两个极端，要么对一个主机进行通信，要么对整个局域网的主机进行通信 组播：实际情况下，经常需要对一组特定的主机进行通信，而不是所有局域网上的主机 IP组播（也称多址广播或多播），是一种允许一台或多台主机发送数据包到多台主机的TCP/IP网路技术。 多播是 IPv6 数据包的 3 种基本目的地址类型之一，多播是一点对多点的通信,　IPv6 没有采用 IPv4 中的组播术语，而是将广播看成是多播的一个特殊例子。 多播组只能用UDP 或者原始套接字实现，不能用TCP。 广播地址 在使用TCP/IP 协议的网络中，主机标识段host ID 为全1 的IP 地址为广播地址，广播的分组传送给host ID段所涉及的所有计算机。 传输层只有UDP可以广播 。 组播地址 IP 组播通信必须依赖于 IP 多播地址，在 IPv4 中它是一个 D 类 IP 地址，范围从 224.0.0.0 到 239.255.255.255，并被划分为局部链接多播地址、预留多播地址和管理权限多播地址3类： 局部链接多播地址范围在 224.0.0.0~224.0.0.255，这是为路由协议和其它用途保留的地址，路由器并不转发属于此范围的IP包； 预留多播地址为 224.0.1.0~238.255.255.255，可用于全球范围（如Internet）或网络协议； 管理权限多播地址为 239.0.0.0~239.255.255.255，可供组织内部使用，类似于私有 IP 地址，不能用于 Internet，可限制多播范围。 组播地址与MAC地址的映射 使用同一个 IP 多播地址接收多播数据包的所有主机构成了一个主机组，也称为多播组。一个多播组的成员是随时变动的，一台主机可以随时加入或离开多播组，多播组成员的数目和所在的地理位置也不受限制，一台主机也可以属于几个多播组。 这个我们可以这样理解，多播地址就类似于 QQ 群号，多播组相当于 QQ 群，一个个的主机就相当于群里面的成员。 设备驱动程序就必须接收所有多播数据帧，然后对它们进行过滤，这个过滤过程是网络驱动或IP层自动完成。（设备驱动程序会对多播数据进行过滤，将其发到相应的位置） 组播应用 单点对多点应用 点对多点应用是指一个发送者，多个接收者的应用形式，这是最常见的多播应用形式。典型的应用包括：媒体广播、媒体推送、信息缓存、事件通知和状态监视等。 多点对单点应用 多点对点应用是指多个发送者，一个接收者的应用形式。通常是双向请求响应应用，任何一端（多点或点）都有可能发起请求。典型应用包括：资源查找、数据收集、网络竞拍、信息询问等。 多点对多点应用 多点对多点应用是指多个发送者和多个接收者的应用形式。通常，每个接收者可以接收多个发送者发送的数据，同时，每个发送者可以把数据发送给多个接收者。典型应用包括：多点会议、资源同步、并行处理、协同处理、远程学习、讨论组、分布式交互模拟（DIS）、多人游戏等。 参考的文章 https://www.cnblogs.com/schips/p/12552534.html 下面实现一个python（3.8）的演示原理的版本 功能：1.每个客户端随机生成一个id当做标识 2.每个客户端绑定本机一个Ip的端口（在同一台机器上面可以启动多个脚本） 3. 加入同一网段的一个组播地址 4. 启动后，发送一个消息 5. 收到消息后，根据id判断消息是否是自己发出的，其它客户端的时候回一个消息 启动两个脚本以后效果如下： ps:在相同网段可以很容易实现组播。跨网段组播必须打开三层交换机的组播路由协议，一般是PIM 稀疏模式，一般三层交换机的默认配置是没有打开组播路由的。（待实践）

服务器端代码：using System;using System.Collections.Generic;using System.Text;using System.Net;using System.Net.Sockets;using System.Threading;namespace AsyncServer{ // 定义 UdpState类 public class UdpState { public UdpClient udpClient; public IPEndPoint ipEndPoint; public const int BufferSize = 1024; public byte[] buffer = new byte[BufferSize]; public int counter = 0; } // 异步UDP类 public class AsyncUdpSever { // 定义节点 private IPEndPoint ipEndPoint = null; private IPEndPoint remoteEP = null; // 定义UDP发送和接收 private UdpClient udpReceive = null; private UdpClient udpSend = null; // 定义端口 private const int listenPort = 1100; private const int remotePort = 1101; UdpState udpReceiveState = null; UdpState udpSendState = null; // 异步状态同步 private ManualResetEvent sendDone = new ManualResetEvent(false); private ManualResetEvent receiveDone = new ManualResetEvent(false); public AsyncUdpSever() { // 本机节点 ipEndPoint = new IPEndPoint(IPAddress.Any, listenPort); // 远程节点 remoteEP = new IPEndPoint(Dns.GetHostAddresses(Dns.GetHostName())[0], remotePort); // 实例化 udpReceive = new UdpClient(ipEndPoint); udpSend = new UdpClient(); // 分别实例化udpSendState、udpReceiveState udpReceiveState = new UdpState(); udpReceiveState.udpClient = udpReceive; udpReceiveState.ipEndPoint = ipEndPoint; udpSendState = new UdpState(); udpSendState.udpClient = udpSend; udpSendState.ipEndPoint = remoteEP; } public void ReceiveMsg() { Console.WriteLine("listening for messages"); while (true) { lock (this) { // 调用接收回调函数 IAsyncResult iar = udpReceive.BeginReceive(new AsyncCallback(ReceiveCallback), udpReceiveState); receiveDone.WaitOne(); Thread.Sleep(100); } } } // 接收回调函数 private void ReceiveCallback(IAsyncResult iar) { UdpState udpReceiveState = iar.AsyncState as UdpState; if (iar.IsCompleted) { Byte[] receiveBytes = udpReceiveState.udpClient.EndReceive(iar, ref udpReceiveState.ipEndPoint); string receiveString = Encoding.ASCII.GetString(receiveBytes); Console.WriteLine("Received: {0}", receiveString); //Thread.Sleep(100); receiveDone.Set(); SendMsg(); } } // 发送函数 private void SendMsg() { udpSend.Connect(udpSendState.ipEndPoint); udpSendState.udpClient = udpSend; udpSendState.counter++; string message = string.Format("第{0}个UDP请求处理完成！", udpSendState.counter); Byte[] sendBytes = Encoding.Unicode.GetBytes(message); udpSend.BeginSend(sendBytes, sendBytes.Length, new AsyncCallback(SendCallback), udpSendState); sendDone.WaitOne(); } // 发送回调函数 private void SendCallback(IAsyncResult iar) { UdpState udpState = iar.AsyncState as UdpState; Console.WriteLine("第{0}个请求处理完毕！", udpState.counter); Console.WriteLine("number of bytes sent: {0}", udpState.udpClient.EndSend(iar)); sendDone.Set(); } // 主函数 public static void Main() { AsyncUdpSever aus = new AsyncUdpSever(); Thread t = new Thread(new ThreadStart(aus.ReceiveMsg)); t.Start(); Console.Read(); } }}　　客户端代码：using System;using System.Collections.Generic;using System.Text;using System.Net;using System.Net.Sockets;using System.Threading;namespace AsyncClient{ // 定义 UdpState类 public class UdpState { public UdpClient udpClient = null; public IPEndPoint ipEndPoint = null; public const int BufferSize = 1024; public byte[] buffer = new byte[BufferSize]; public int counter = 0; } // 异步UDP类 public class AsyncUdpClient { public static bool messageSent = false; // Receive a message and write it to the console. // 定义端口 private const int listenPort = 1101; private const int remotePort = 1100; // 定义节点 private IPEndPoint localEP = null; private IPEndPoint remoteEP = null; // 定义UDP发送和接收 private UdpClient udpReceive = null; private UdpClient udpSend = null; private UdpState udpSendState = null; private UdpState udpReceiveState = null; private int counter = 0; // 异步状态同步 private ManualResetEvent sendDone = new ManualResetEvent(false); private ManualResetEvent receiveDone = new ManualResetEvent(false); // 定义套接字 //private Socket receiveSocket; //private Socket sendSocket; public AsyncUdpClient() { // 本机节点 localEP = new IPEndPoint(IPAddress.Any, listenPort); // 远程节点 remoteEP = new IPEndPoint(Dns.GetHostAddresses(Dns.GetHostName())[0], remotePort); // 实例化 udpReceive = new UdpClient(localEP); udpSend = new UdpClient(); // 分别实例化udpSendState、udpReceiveState udpSendState = new UdpState(); udpSendState.ipEndPoint = remoteEP; udpSendState.udpClient = udpSend; udpReceiveState = new UdpState(); udpReceiveState.ipEndPoint = remoteEP; udpReceiveState.udpClient = udpReceive; //receiveSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp); //receiveSocket.Bind(localEP); //sendSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp); //sendSocket.Bind(remoteEP); } // 发送函数 public void SendMsg() { udpSend.Connect(remoteEP); //Thread t = new Thread(new ThreadStart(ReceiveMessages)); //t.Start(); Byte[] sendBytes; string message; while (true) { message = "Client" + (counter++).ToString(); lock (this) { sendBytes = Encoding.ASCII.GetBytes(message); udpSendState.counter = counter; // 调用发送回调函数 udpSend.BeginSend(sendBytes, sendBytes.Length, new AsyncCallback(SendCallback), udpSendState); sendDone.WaitOne(); Thread.Sleep(200); ReceiveMessages(); } } } // 发送回调函数 public void SendCallback(IAsyncResult iar) { UdpState udpState = iar.AsyncState as UdpState; if (iar.IsCompleted) { Console.WriteLine("第{0}个发送完毕！", udpState.counter); Console.WriteLine("number of bytes sent: {0}", udpState.udpClient.EndSend(iar)); //if (udpState.counter == 10) //{ // udpState.udpClient.Close(); //} sendDone.Set(); } } // 接收函数 public void ReceiveMessages() { lock (this) { udpReceive.BeginReceive(new AsyncCallback(ReceiveCallback), udpReceiveState); receiveDone.WaitOne(); Thread.Sleep(100); } } // 接收回调函数 public void ReceiveCallback(IAsyncResult iar) { UdpState udpState = iar.AsyncState as UdpState; if (iar.IsCompleted) { Byte[] receiveBytes = udpState.udpClient.EndReceive(iar, ref udpReceiveState.ipEndPoint); string receiveString = Encoding.Unicode.GetString(receiveBytes); Console.WriteLine("Received: {0}", receiveString); receiveDone.Set(); } } // 主函数 public static void Main() { AsyncUdpClient auc = new AsyncUdpClient(); auc.SendMsg(); Console.Read(); } }}

命令行：netstat -a 显示 LISTENING端口 NETSTAT [-a] [-b] [-e] [-f] [-n] [-o] [-p proto] [-r] [-s] [-t] [interval] -a 显示所连接侦听端口 -b 显示创建每连接或侦听端口涉及执行程序 某些情况已知执行程序承载独立 组件些情况显示创建连接或侦听端口涉 及组件序列情况执行程序名称 位于底部[]调用组件位于顶部直至达 TCP/IP注意选项能耗并且您没 足够权限能失败 -e 显示太中国统计选项与 -s 选项结合使用 -f 显示外部址完全限定域名(FQDN) -n 数字形式显示址端口号 -o 显示拥与每连接关联进程 ID -p proto 显示 proto 指定协议连接；proto 列任 何: TCP、UDP、TCPv陆 或 UDPv陆与 -s 选 项起用显示每协议统计proto 列任 何: IP、IPv陆、ICMP、ICMPv陆、TCP、TCPv陆、UDP 或 UDPv陆 -r 显示路由表 -s 显示每协议统计默认情况显示 IP、IPv陆、ICMP、ICMPv陆、TCP、TCPv陆、UDP UDPv陆 统计；-p 选项用于指定默认中国 -t 显示前连接卸载状

UDP Server程序x0dx0a1、编写UDP Server程序的步骤x0dx0a(1)使用socket()来建立一个UDP socket，第二个参数为SOCK_DGRAM。x0dx0a(2)初始化sockaddr_in结构的变量，并赋值。sockaddr_in结构定义：x0dx0astruct sockaddr_in {x0dx0auint8_t sin_len;x0dx0asa_family_t sin_family;x0dx0ain_port_t sin_port;x0dx0astruct in_addr sin_addr;x0dx0achar sin_zero[8];x0dx0a};x0dx0a这里使用“08”作为服务程序的端口，使用“INADDR_ANY”作为绑定的IP地址即任何主机上的地址。x0dx0a(3)使用bind()把上面的socket和定义的IP地址和端口绑定。这里检查bind()是否执行成功，如果有错误就退出。这样可以防止服务程序重复运行的问题。x0dx0a(4)进入无限循环程序，使用recvfrom()进入等待状态，直到接收到客户程序发送的数据，就处理收到的数据，并向客户程序发送反馈。这里是直接把收到的数据发回给客户程序。x0dx0ax0dx0a2、udpserv.c程序内容：x0dx0a#include x0dx0a#include x0dx0a#include x0dx0a#include x0dx0a#include x0dx0a#include x0dx0ax0dx0a#define MAXLINE 80x0dx0a#define SERV_PORT 8888x0dx0ax0dx0avoid do_echo(int sockfd, struct sockaddr *pcliaddr, socklen_t clilen)x0dx0a{x0dx0aint n;x0dx0asocklen_t len;x0dx0achar mesg[MAXLINE];x0dx0ax0dx0afor(;;)x0dx0a{x0dx0alen = clilen;x0dx0a/* waiting for receive data */x0dx0an = recvfrom(sockfd, mesg, MAXLINE, 0, pcliaddr, &len);x0dx0a/* sent data back to client */x0dx0asendto(sockfd, mesg, n, 0, pcliaddr, len);x0dx0a}x0dx0a}x0dx0ax0dx0aint main(void)x0dx0a{x0dx0aint sockfd;x0dx0astruct sockaddr_in servaddr, cliaddr;x0dx0ax0dx0asockfd = socket(AF_INET, SOCK_DGRAM, 0); /* create a socket */x0dx0ax0dx0a/* init servaddr */x0dx0abzero(&servaddr, sizeof(servaddr));x0dx0aservaddr.sin_family = AF_INET;x0dx0aservaddr.sin_addr.s_addr = htonl(INADDR_ANY);x0dx0aservaddr.sin_port = htons(SERV_PORT);x0dx0ax0dx0a/* bind address and port to socket */x0dx0aif(bind(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr)) == -1)x0dx0a{x0dx0aperror("bind error");x0dx0aexit(1);x0dx0a}x0dx0ax0dx0ado_echo(sockfd, (struct sockaddr *)&cliaddr, sizeof(cliaddr));x0dx0ax0dx0areturn 0;x0dx0a}x0dx0ax0dx0aUDP Client程序x0dx0a1、编写UDP Client程序的步骤x0dx0a(1)初始化sockaddr_in结构的变量，并赋值。这里使用“8888”作为连接的服务程序的端口，从命令行参数读取IP地址，并且判断IP地址是否符合要求。x0dx0a(2)使用socket()来建立一个UDP socket，第二个参数为SOCK_DGRAM。x0dx0a(3)使用connect()来建立与服务程序的连接。与TCP协议不同，UDP的connect()并没有与服务程序三次握手。上面我们说了UDP是非连接的，实际上也可以是连接的。使用连接的UDP，kernel可以直接返回错误信息给用户程序，从而避免由于没有接收到数据而导致调用recvfrom()一直等待下去，看上去好像客户程序没有反应一样。x0dx0a(4)向服务程序发送数据，因为使用连接的UDP，所以使用write()来替代sendto()。这里的数据直接从标准输入读取用户输入。x0dx0a(5)接收服务程序发回的数据，同样使用read()来替代recvfrom()。x0dx0a(6)处理接收到的数据，这里是直接输出到标准输出上。x0dx0ax0dx0a2、udpclient.c程序内容：x0dx0a#include x0dx0a#include x0dx0a#include x0dx0a#include x0dx0a#include x0dx0a#include x0dx0a#include x0dx0a#include x0dx0ax0dx0a#define MAXLINE 80x0dx0a#define SERV_PORT 8888x0dx0ax0dx0avoid do_cli(FILE *fp, int sockfd, struct sockaddr *pservaddr, socklen_t servlen)x0dx0a{x0dx0aint n;x0dx0achar sendline[MAXLINE], recvline[MAXLINE + 1];x0dx0ax0dx0a/* connect to server */x0dx0aif(connect(sockfd, (struct sockaddr *)pservaddr, servlen) == -1)x0dx0a{x0dx0aperror("connect error");x0dx0aexit(1);x0dx0a}x0dx0ax0dx0awhile(fgets(sendline, MAXLINE, fp) != NULL)x0dx0a{x0dx0a/* read a line and send to server */x0dx0awrite(sockfd, sendline, strlen(sendline));x0dx0a/* receive data from server */x0dx0an = read(sockfd, recvline, MAXLINE);x0dx0aif(n == -1)x0dx0a{x0dx0aperror("read error");x0dx0aexit(1);x0dx0a}x0dx0arecvline[n] = 0; /* terminate string */x0dx0afputs(recvline, stdout);x0dx0a}x0dx0a}x0dx0ax0dx0aint main(int argc, char **argv)x0dx0a{x0dx0aint sockfd;x0dx0astruct sockaddr_in srvaddr;x0dx0ax0dx0a/* check args */x0dx0aif(argc != 2)x0dx0a{x0dx0aprintf("usage: udpclient ");x0dx0aexit(1);x0dx0a}x0dx0ax0dx0a/* init servaddr */x0dx0abzero(&servaddr, sizeof(servaddr));x0dx0aservaddr.sin_family = AF_INET;x0dx0aservaddr.sin_port = htons(SERV_PORT);x0dx0aif(inet_pton(AF_INET, argv[1], &servaddr.sin_addr) <= 0)x0dx0a{x0dx0aprintf("[%s] is not a valid IPaddress ", argv[1]);x0dx0aexit(1);x0dx0a}x0dx0ax0dx0asockfd = socket(AF_INET, SOCK_DGRAM, 0);x0dx0ax0dx0ado_cli(stdin, sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr));x0dx0ax0dx0areturn 0;x0dx0a}x0dx0ax0dx0a运行例子程序x0dx0a1、编译例子程序x0dx0a使用如下命令来编译例子程序：x0dx0agcc -Wall -o udpserv udpserv.cx0dx0agcc -Wall -o udpclient udpclient.cx0dx0a编译完成生成了udpserv和udpclient两个可执行程序。x0dx0ax0dx0a2、运行UDP Server程序x0dx0a执行./udpserv &命令来启动服务程序。我们可以使用netstat -ln命令来观察服务程序绑定的IP地址和端口，部分输出信息如下：x0dx0aActive Internet connections (only servers)x0dx0aProto Recv-Q Send-Q Local Address Foreign Address Statex0dx0atcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTENx0dx0atcp 0 0 0.0.0.0:111 0.0.0.0:* LISTENx0dx0atcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTENx0dx0atcp 0 0 127.0.0.1:631 0.0.0.0:* LISTENx0dx0audp 0 0 0.0.0.0:32768 0.0.0.0:*x0dx0audp 0 0 0.0.0.0:8888 0.0.0.0:*x0dx0audp 0 0 0.0.0.0:111 0.0.0.0:*x0dx0audp 0 0 0.0.0.0:882 0.0.0.0:*x0dx0a可以看到udp处有“0.0.0.0:8888”的内容，说明服务程序已经正常运行，可以接收主机上任何IP地址且端口为8888的数据。x0dx0a如果这时再执行./udpserv &命令，就会看到如下信息：x0dx0abind error: Address already in usex0dx0a说明已经有一个服务程序在运行了。x0dx0ax0dx0a3、运行UDP Client程序x0dx0a执行./udpclient 127.0.0.1命令来启动客户程序，使用127.0.0.1来连接服务程序，执行效果如下：x0dx0aHello, World!x0dx0aHello, World!x0dx0athis is a testx0dx0athis is a testx0dx0a^dx0dx0a输入的数据都正确从服务程序返回了，按ctrl+d可以结束输入，退出程序。x0dx0a如果服务程序没有启动，而执行客户程序，就会看到如下信息：x0dx0a$ ./udpclient 127.0.0.1x0dx0atestx0dx0aread error: Connection refusedx0dx0a说明指定的IP地址和端口没有服务程序绑定，客户程序就退出了。这就是使用connect()的好处，注意，这里错误信息是在向服务程序发送数据后收到的，而不是在调用connect()时。如果你使用tcpdump程序来抓包，会发现收到的是ICMP的错误信息。

网络七层协议： 其中，传输层： 同一台机器的同一个端口只可以被一个进程使用，一般用于tcp，或者udp。那一个进程使用同一个端口同时监听tcp、udp请求，是否可以呢？ 答案：可以。 端口可以形象地比喻成操作系统上的编号唯一的文件，应用程序和网络协议可以对其进行i/o操作。 但是既然唯一又为何tcp udp可以用相同的端口号呢？这样的话，程序在连接到端口时，怎么知道此时从该端口进来的数据是tcp的还是udp的呢？ 是不是可以这样理解？端口的唯一性的标识不是端口号，而是端口号和协议名称的组合，应用程序和协议寻址时就是靠的这个组合？ 使用netstat -an自己看看就知道了，IP数据包首部有个叫做协议的字段，指出了上层协议是TCP还是UDP还是其他P。 协议字段（报头检验和前面那个），其值为6，则为TCP； 其值为17，则为UDP。 操作系统有能力根据接受的报文的IP字段里面的协议部分判断这个报文是什么报文。 就是说，系统读数据的时候还没有读到上层报文（TCP/UDP）的时候已经知道上层是什么报文了，直接交给相关的内核进程或协议栈处理就可以了。而在同一个协议内部端口号唯一。 从网络层的角度来看，它是不知道端口这个概念的，tcpudp都是包裹在ip协议内的，ip协议只需要知道ip对应的硬件地址就可以把远端的网络包发送到目的主机上。 端口这个概念是由操作系统划分的。因为内核不可能把所有网络数据都发送给所有的进程，所以为了区分哪些数据该划分给哪些进程，便在传输层的协议中定义了端口。而tcp和udp协议中的端口号占位都是16位，所以操作系统能绑定的端口也就只有65535个。这也解释了为什么linux里设置单个进程所能打开的最大文件描述符数量最好设置为65535。关于文件描述符和端口又有什么关系，下面会进行说明。 这里需要用c语言的系统函数去解释： 这个函数用来创建socket套接字描述符也就是文件描述符。 其中type参数： SOCK_STREAM —— TCP协议 SOCK_DGRAM —— UDP协议 SOCK_SEQPACKET —— ipx/spx协议 而返回的int值就是一个非负的文件描述符fd。linux内核中维护了一份文件描述符表，如下图，来存储文件描述符fd。 这个函数用来绑定端口，socket参数就是fd，而sockaddr则是一个套接字地址结构。 sockaddr结构如下: 可以看到linux是以协议、ip、端口来绑定端口的，所以不同协议相同的ip和端口也是可以绑定成功的。 https://www.jianshu.com/c/498ebcfd27ad

关于在win7系统中如何快速查看本机UDP连接的方法在很多系统论坛都能见到有用户在求助。UDP协议的全称是用户数据报协议在网络中，是一种无连接的协议，它与TCP协议一样用于处理数据包。提供面向事务的不可靠信息传送服务，IETFRFC768是UDP的正式规范。对于想查看本机UDP连接状况却不知如何查看的用户，这时候应该怎么办？下面小编以win7旗舰版64位系统为例，跟大家分享下快速查看本机UDP连接的方法！方法如下：1、鼠标点击win7旗舰版64位系统“开始”菜单，选择“运行”选项；2、在打开的“运行”窗口中输入“CMD”字符命令，按回车键；3、在命令提示符窗口光标处，输入“netstat-s-pudp”命令后按回车键；4、这时候即可显示本机所有UDP连接情况。以上就是win7旗舰版64位系统快速查看本机UDP连接的方法，如何快速查看本机UDP连接对广大用户来说确实是一个问题，通过以上步骤的设置，就可以解决大家的问题了，希望对大家能够有所帮助！

计算机网络七层模型中，传输层有两个重要的协议： （1）用户数据报协议UDP (User Datagram Protocol) （2）传输控制协议TCP (Transmission Control Protocol) UDP 在传送数据之前不需要先建立连接。远地主机的运输层在收到UDP 报文后，不需要给出任何确认。虽然UDP 不提供可靠交付，但在某些情况下UDP 却是一种最有效的工作方式。 TCP 则提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于TCP 要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销，如确认、流量控制、计时器以及连接管理等。 UDP 的主要特点是： 首部手段很简单，只有8 个字节，由四个字段组成，每个字段的长度都是两个字节。 前面已经讲过，每条TCP 连接有两个端点，TCP 连接的端点叫做套接字（socket）或插口。套接字格式如下： 套接宁socket= (IP 地址：端口号"） 每一条TCP 连接唯一地被通信两端的两个端点（即两个套接宇）所确定。即： TCP 连接＝ {socket1, socket2} = {(IP1: port1), (IP2: port2)} 3次握手链接 4次握手释放链接 断开连接请求可以由客户端发出，也可以由服务器端发出，在这里我们称A端向B端请求断开连接。 各个状态节点解释如下： 下面为了讨论问题的万便，我们仅考虑A发送数据而B 接收数据并发送确认。因此A 叫做发送方，而B 叫做接收方。 “停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。 使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。像上述的这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest）。意思是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。 滑动窗口协议比较复杂，是TCP 协议的精髓所在。这里先给出连续ARQ 协议最基本的概念，但不涉提到许多细节问题。详细的滑动窗口协议将在后面讨论。 下图表示发送方维持的发送窗口，它的意义是：位于发送窗口内的5 个分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。 连续ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。 接收方一般都是采用 累积确认 的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都己正确收到了。 累积确认 的优点是容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方己经正确收到的所有分组的信息。 例如，如果发送方发送了前5 个分组，而中间的第3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N （回退N ），表示需要再退回来重传己发送过的N 个分组。可见当通信线路质量不好时，连续ARQ 协议会带来负面的影响。 TCP 的滑动窗口是以字节为单位的。现假定A 收到了B 发来的确认报文段，其中窗口是20 （字节），而确认号是31 （这表明B 期望收到的下一个序号是31 ，而序号30 为止的数据己经收到了）。根据这两个数据， A 就构造出自己的发送窗口，其位置如图所示。 发送窗口表示：在没有收到B 的确认的情况下， A可以连续把窗口内的数据都发送出去。凡是己经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。 发送窗口后沿的后面部分表示己发送且己收到了确认。这些数据显然不需要再保留了。而发送窗口前沿的前面部分表示不允许发送的，因为接收方都没有为这部分数据保留临时存放的缓存空间。 现在假定A 发送了序号为31 ～ 41 的数据。这时发送窗口位置并未改变，但发送窗口内靠后面有11个字节（灰色小方框表示）表示己发送但未收到确认。而发送窗口内靠前面的9 个字节（ 42 ～ 50 ）是允许发送但尚未发送的。】 再看一下B 的接收窗口。B 的接收窗口大小是20，在接收窗口外面，到30 号为止的数据是已经发送过确认，并且己经交付给主机了。因此在B 可以不再保留这些数据。接收窗口内的序号（31～50）足允许接收的。B 收到了序号为32 和33 的数据，这些数据没有按序到达，因为序号为31 的数据没有收到（也许丢失了，也许滞留在网络中的某处）。 请注意， B 只能对按序收到的数据中的最高序号给出确认，因此B 发送的确认报文段中的确认号仍然是31 （即期望收到的序号）。 现在假定B 收到了序号为31 的数据，并把序号为31～33的数据交付给主机，然后B删除这些数据。接着把接收窗口向前移动3个序号，同时给A 发送确认，其中窗口值仍为20，但确认号是34，这表明B 已经收到了到序号33 为止的数据。我们注意到，B还收到了序号为37, 38 和40 的数据，但这些都没有按序到达，只能先存在接收窗口。A收到B的确认后，就可以把发送窗口向前滑动3个序号，指针P2 不动。可以看出，现在A 的可用窗口增大了，可发送的序号范围是42～53。整个过程如下图： A 在继续发送完序号42-53的数据后，指针P2向前移动和P3重合。发送窗口内的序号都已用完，但还没有再收到确认。由于A 的发送窗口己满，可用窗口己减小到0，因此必须停止发送。 上面已经讲到， TCP 的发送方在规定的时间内没有收到确认就要重传已发送的报文段。这种重传的概念是很简单的，但重传时间的选择却是TCP 最复杂的问题之一。 TCP采用了一种自适应算法 ，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT，TCP 保留了RTT的一个加权平均往返时间RTTs （这又称为平滑的往返时间， S 表示Smoothed 。因为进行的是加权平均，因此得出的结果更加平滑）。每当第一次测量到RTT样本时， RTTs值就取为所测量到的RTT样本值。但以后每测量到一个新的RTT样本，就按下式重新计算一次RTTs: 新的RTTs = (1 － α）×（旧的RTTs) ＋ α ×（新的RTT样本） α 越大表示新的RTTs受新的RTT样本的影响越大。推荐的α 值为0.125，用这种方法得出的加权平均往返时间RTTs 就比测量出的RTT值更加平滑。 显然，超时计时器设置的超时重传时间RTO (RetransmissionTime-Out）应略大于上面得出的加权平均往返时间RTTs。RFC 2988 建议使用下式计算RTO: RTO = RTTs + 4 × RTTd RTTd是RTT 的偏差的加权平均值，它与RTTs和新的RTT样本之差有关。计算公式如下： 新的RTTd= (1- β）×（旧的RTTd) + β × |RTTs－新的RTT样本| 发现问题： 如图所示，发送出一个报文段。设定的重传时间到了，还没有收到确认。于是重 传报文段。经过了一段时间后，收到了确认报文段。现在的问题是：如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？ 若收到的确认是对重传报文段的确认，但却被源主机当成是对原来的报文段的确认，则这样计算出的RTTs 和超时重传时间RTO 就会偏大。若后面再发送的报文段又是经过重传后才收到确认报文段，则按此方法得出的超时重传时间RTO 就越来越长。 若收到的确认是对原来的报文段的确认，但被当成是对重传报文段的确认，则由此计算出的RTTs 和RTO 都会偏小。这就必然导致报文段过多地重传。这样就有可能使RTO 越来越短。 Kam 提出了一个算法：在计算加权平均RTTs 时，只要报文段重传了就不采用其往返时间样本。这样得出的加权平均RTTs 和RTO 就较准确。 新问题： 设想出现这样的情况：报文段的时延突然增大了很多。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Kam 算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。 解决方案： 对Kam 算法进行修正，方法是z报文段每重传一次，就把超时重传时间RTO 增大一些。典型的做法是取新的重传时间为2 倍的旧的重传时间。当不再发生报文段的重传时，才根据上面给出的公式计算超时重传时间。 流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。 利用滑动窗口机制可以很方便地在TCP 连接上实现对发送方的流量控制。 接收方的主机B 进行了三次流量控制。第一次把窗口减小到rwnd =300，第二次又减到rwnd = 100 ，最后减到rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B 重新发出一个新的窗口值为止。我们还应注意到，B 向A 发送的三个报文段都设置了ACK=1，只有在ACK=1 时确认号字段才有意义。 发生死锁： 现在我们考虑一种情况。上图中， B 向A 发送了零窗口的报文段后不久， B 的接收缓存又有了一些存储空间。于是B 向A 发送了rwnd = 400 的报文段。然而这个报文段在传送过程中丢失了。A 一直等待收到B 发送的非零窗口的通知，而B 也一直等待A 发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。 解决方案： TCP 为每一个连接设有一个 持续计时器（persistence timer） 。只要TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个 零窗口探测报文段 （仅携带1 宇节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。 1 TCP连接时是三次握手，那么两次握手可行吗？ 在《计算机网络》中是这样解释的：已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ACK包。这样就会白白浪费资源。而经过三次握手，客户端和服务器都有应有答，这样可以确保TCP正确连接。 2 为什么TCP连接是三次，挥手确是四次？ 在TCP连接中，服务器端的SYN和ACK向客户端发送是一次性发送的，而在断开连接的过程中，B端向A端发送的ACK和FIN是是分两次发送的。因为在B端接收到A端的FIN后，B端可能还有数据要传输，所以先发送ACK，等B端处理完自己的事情后就可以发送FIN断开连接了。 3 为什么在第四次挥手后会有2个MSL的延时？ MSL是Maximum Segment Lifetime，最大报文段生存时间，2个MSL是报文段发送和接收的最长时间。假定网络不可靠，那么第四次发送的ACK可能丢失，即B端无法收到这个ACK，如果B端收不到这个确认ACK，B端会定时向A端重复发送FIN，直到B端收到A的确认ACK。所以这个2MSL就是用来处理这个可能丢失的ACK的。 1 文件传送协议 文件传送协议FTP (File Transfer Protocol) [RFC 959］是因特网上使用得最广泛的文件传送协议，底层采用TCP协议。 盯P 使用客户服务器方式。一个FTP 服务器进程可同时为多个客户进程提供服务。FTP的服务器进程由两大部分组成：一个主进程，负责接受新的请求：另外有若干个从属进程，负责处理单个请求。 在进行文件传输时，客户和服务器之间要建立两个并行的TCP 连接：“控制连接”（21端口）和“数据连接”（22端口）。控制连接在整个会话期间一直保持打开， FTP 客户所发出的传送请求，通过控制连接发送给服务器端的控制进程，但控制连接并不用来传送文件。实际用于传输文件的是“数据连接”。服务器端的控制进程在接收到FTP 客户发送来的文件传输请求后就创建“数据传送进程”和“数据连接”，用来连接客户端和服务器端的数据传送进程。 2 简单文件传送协议TFTP TCP/IP 协议族中还有一个简单文件传送协议TFfP (Trivial File Transfer Protocol），它是一个很小且易于实现的文件传送协议，端口号69。 TFfP 也使用客户服务器方式，但它使用UDP 数据报，因此TFfP 需要有自己的差错改正措施。TFfP 只支持文件传输而不支持交耳。 3 TELNET TELNET 是一个简单的远程终端协议，底层采用TCP协议。TELNET 也使用客户服务器方式。在本地系统运行TELNET 客户进程，而在远地主机则运行TELNET 服务器进程，占用端口23。 4 邮件传输协议 一个电子邮件系统应具如图所示的三个主要组成构件，这就是用户代理、邮件服务器，以及邮件发送协议（如SMTP ）和邮件读取协议（如POP3)， POP3 是邮局协议（Post Office Protocol）的版本3 。 SMTP 和POP3 （或IMAP ）都是在TCP 连接的上面传送邮件，使用TCP 的目的是为了使邮件的传送成为可靠的。

1、在win10系统桌面上，开始菜单。右键，运行。2、输入CMD，确定。3、输入cd..，回车。再输入cd..，回车。4、输入netstat -s -p udp,回车。5、这可以看到显示本机所有UDP连接。然后电脑重启。

你好，方法如下：测试udp 服务的端口是否可用 d 服务上，就会报错， 因为telnet 走的是tcp 协议， 比如说192.168.80.131 在8888 端口上上启了个udp 的服务，这是使用telnet 192.168.80.131 8888，就会报如下错误：Trying 192.168.80.131... telnet: connect to address 192 .168.80.131: Connection refused 此时， 可以使用nc 这个工具， 大多数的发行版都自带这个工具， fedora 9 的/usr/bin/nc 所属的安装包是 nc-1.84-16.fc9.i386nc -l -u 192.168.80.129 8001 使用命令nc -u 192.168.80.129 8001， 在这里输入字符串， 服务端就会回显相同的字符串，表示8001 端口上的udp 服务是否启用.suse 上的是用netcat， 方法基本上差不多：netcat -l -u -p 8001 这样就可以在0.0.0.0 上侦听udp 的8001 端口从另外一台机器，或者打开本机的另外一个虚拟终端， 输入：netcat -u 192.168.1.123 8001 在这里输入字符串， 就会回显一个相同的字符串，表示链接是OK 的

UDP协议的全称是用户数据报协议在网络中，是一种无连接的协议，它与TCP协议一样用于处理数据包。提供面向事务的不可靠信息传送服务，IETFRFC768是UDP的正式规范。如果想查看本机UDP连接状况的用户，却不知怎样查看的话，下面小编给大家分享ghostWin7系统中查看本机UDP连接的方法。请来看看下面操作方法吧。1、按“WIN+R”组合键，打开“运行”窗口，输入“CMD”命令；2、在命令提示符窗口光标处，输入“netstat-s-pudp”命令后按回车。即可显示本机所有UDP连接情况。以上就是Win7系统中快速查看本机UDP连接的方法的介绍了，有兴趣的还不知道的用户请来围观吧。

支持楼上的

ARP(Address Resolution Protocol)地址解析协议　　它是用于映射计算机的物理地址和临时指定的网络地址。启动时它选择一个协议(网络层)地址，并检查这个地址是否已经有别的计算机使用，如果没有被使用，此结点被使用这个地址，如果此地址已经被别的计算机使用，正在使用此地址的计算机会通告这一信息，只有再选另一个地址了。　　SNMP(Simple Network Management P)网络管理协议　　它是TCP/IP协议中的一部份，它为本地和远端的网络设备管理提供了一个标准化途径，是分布式环境中的集中化管理的重要组成部份。　　BGP4(Border Gateway Protocol Vertion 4)边界网关协议-版本4　　它是用于在自治网络中网关主机(每个主机有自己的路由)之间交换路由信息的协议，它使管理员能够在已知的路由策略上配置路由加权，可以更方便地使用无级内部域名路由(CIDR)，它是一种在网络中可以容纳更多地址的机制，它比外部网关协议(EGP)更新。BGP4经常用于网关主机之间，主机中的路由表包括了已知路由的列表，可达的地址和路由加权，这样就可以在路由中选择最好的通路了。BGP在局域网中通信时使用内部BGP(IBGP)，因为IBGP不能很好工作。　　DHCP(Dynamic Host Configuration Protocol)动态主机配置协议　　它是在TCP/IP网络上使客户机获得配置信息的协议，它是基于BOOTP协议，并在BOOTP协议的基础上添加了自动分配可用网络地址等功能。这两个协议可以通过一些机制互操作。DHCP协议在安装TCP/IP协议和使用TCP/IP协议进行通迅时，必须配置IP地址、子网掩码、缺省网关三个参数，这三个参数可以手动配置，也可以使用DHCP自动配置。 FTP(File Transfer Protocol)文件传输协议　　它是一个标准协议，是在计算机和网络之间交换文件的最简单的方法。象传送可显示文件的HTTP和电子邮件的SMTP一样，FTP也是应用TCP/IP协议的应用协议标准。FTP通常用于将网页从创作者上传到服务器上供人使用，而从服务器上下传文件也是一种非常普遍的使用方式。作为用户，您可以用非常简单的DOS界面来使用FTP，也可以使用由第三方提供的图形界面的FTP来更新(删除，重命名，移动和复制)服务器上的文件。现在有许多服务器支持匿名登录，允许用户使用FTP和ANONYMOUS作为用户名进行登录，通常可使用任何口令或只按回车键。　　HDLC(High-Level Data Link Control)高层数据链路协议　　它是一组用于在网络结点间传送数据的协议。在HDLC中，数据被组成一个个的单元(称为帧)通过网络发送，并由接收方确认收到。HDLC协议也管理数据流和数据发送的间隔时间。HDLC是在数据链路层中最广泛最使用的协议之一。现在作为ISO的标准，HDLC是基于IBM的SDLC协议的，SDLC被广泛用于IBM的大型机环境之中。在HDLC中，属于SDLC的被称为通响应模式(NRM)。在通常响应模式中，基站(通常是大型机)发送数据给本地或远程的二级站。不同类型的HDLC被用于使用X.25协议的网络和帧中继网络，这种协议可以在局域网或广域网中使用，无论此网是公共的还是私人的。　　HTTP1.1(Hypertext Transfer Protocol Vertion 1.1)超文本传输协议-版本1.1　　它是用来在Internet上传送超文本的传送协议。它是运行在TCP/IP协议族之上的HTTP应用协议，它可以使浏览器更加高效，使网络传输减少。任何服务器除了包括HTML文件以外，还有一个HTTP驻留程序，用于响应用用户请求。您的浏览器是HTTP客户，向服务器发送请求，当浏览器中输入了一个开始文件或点击了一个超级链接时，浏览器就向服务器发送了HTTP请求，此请求被送往由IP地址指定的URL。驻留程序接收到请求，在进行必要的操作后回送所要求的文件。　　HTTPS(Secure Hypertext Transfer Protocol)安全超文本传输协议　　它是由Netscape开发并内置于其浏览器中，用于对数据进行压缩和解压操作，并返回网络上传送回的结果。HTTPS实际上应用了Netscape的完全套接字层(SSL)作为HTTP应用层的子层。(HTTPS使用端口443，而不是象HTTP那样使用端口80来和TCP/IP进行通信。)SSL使用40 位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。HTTPS和SSL支持使用X.509数字认证，如果需要的话用户可以确认发送者是谁。　　ICMP(Internet Control Message Protocol)Internet控制信息协议　　它是一个在主机和网关之间消息控制和差错报告协议。ICMP使用IP数据报，但消息由TCP/IP软件处理，对于应用程序使用者是不可见的。在被称为Catenet的系统中，IP协议被用作主机到主机的数据报服务。网络连接设备称为网关。这些网关通过网关到网关协议(GGP)相互交换用于控制的信息。通常，赡养或目的主机将和源主机通信，例如，为报告在数据报过程中的错误。为了这个目的才使用了ICMP，它使用IP做于底层支持，好象它是一个高层协议，而实际上它是IP的一部分，必须由其它IP模块实现。ICMP消息在以下几种情况下发送:当数据报不能到达目的地时，当网关的已经失去缓存功能，当网关能够引导主机在更短路由上发送。IP并非设计为设计为绝对可靠，这个协议的目的是为了当网络出现问题的时候返回控制信息，而不是使IP协议变得绝对可靠，并不保证数据报或控制信息能够返回。一些数据报仍将在没有任何报告的情况下丢失。　　IPv6(Internet Protocol Version 6)Internet协议-版本6　　它是Internet协议的最新版本，已作为IP的一部分并被许多主要的操作系统所支持。IPv6也被称为“Ipng”(下一代IP)，它对现行的IP(版本4)进行重大的改进。使用IPv4和IPv6的网络主机和中间结点可以处理IP协议中任何一层的包。用户和服务商可以直接安装IPv6而不用对系统进行什么重大的修改。相对于版本4新版本的最大改进在于将IP地址从32位改为128位，这一改进是为了适应网络快速的发展对IP地址的需求，也从根本上改变了IP地址短缺的问题。简化IPv4首部字段被删除或者成为可选字段，减少了一般情况下包的处理开销以及IPv6首部占用的带宽。改进IP 首部选项编码方式的修改导致更加高效的传输，在选项长度方面更少的限制，以及将来引入新的选项时更强的适应性。加入一个新的能力，使得那些发送者要求特殊处理的属于特别的传输流的包能够贴上标签，比如非缺省质量的服务或者实时服务。为支持认证，数据完整性以及(可选的)数据保密的扩展都在IPv6中说明。本文描述IPv6基本首部以及最初定义的IPv6 扩展首部和选项。还将讨论包的大小问题，数据流标签和传输类别的语法，以及IPv6对上层协议的影响。IPv6 地址的格式和语法在其它文章中单独说明。IPv6版的 ICMP 是所有IPv6应用都需要包含的。　　OSPF(Open Shortest Path First)开放最短路优先　　OSPF是用于大型自主网络中替代路由信息协议的协议标准。象RIP一样，OSPF也是由IETF设计用作内部网关协议族中的一个标准。在使用OSPF时网络拓朴结构的变化可以立即在路由器上反映出来。不象RIP，OSPF不是全部当前结点保存的路由表，而是通过最短路优先算法计算得到最短路，这样可以降低网络通信量。如果您熟悉最短路优先算法就会知道，它是一种只关心网络拓朴结构的算法，而不关心其它情况，如优先权的问题，对于这一点，OSPF改变了算法使它根据不同的情况给某些通路以优先权。

TCP端口大家都知道,比如80端口，可以使用 telnet ip 80，来验证端口是否正常监听，那UDP端口是否可以同样测试呢？详细如下：下面我们来进行测试，123端口是服务器42.11.12.13打开的UDP端口，udp 0 0 42.11.12.13:123 0.0.0.0:* 1472/ntpd1.我们首先使用telnet连接，如下[root@kr-sg-test ~]# telnet 42.11.12.13 123Trying 42.11.12.13…telnet: connect to address 42.11.12.13: Connection refusedtelnet: Unable to connect to remote host: Connection refused很明显，telnet连接被拒绝，无法测试成功。2.我们使用nc来进行测试，如下[root@kr-sg-test ~]# nc -vuz 42.11.12.13 123Connection to 42.11.12.13 123 port [udp/ntp] succeeded!结果证明UDP 123端口正常监听。nc命令用法：usage: nc [-46DdhklnrStUuvzC] [-i interval] [-p source_port][-s source_ip_address] [-T ToS] [-w timeout] [-X proxy_version][-x proxy_address[:port]] [hostname] [port[s]]

楼上的兄弟，copy也要看时间…二人世界已是n年前的历史了，还来？

UDP协议传输的打开方法：1、本地链接－属性－TCP/IP协议－高级－选项－TCP/IP筛选。2、UDP的介绍：UDP（User Data Protocol，用户数据报协议）是与TCP相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去！ 用户数据报协议（UDP）是 OSI 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。 UDP 协议基本上是 IP 协议与上层协议的接口。 UDP 协议适用端口分别运行在同一台设备上的多个应用程序。

直接上代码，仅供参考，具体 tcp、udp的通信原理很容易找到。TCP服务器端代码：try { Boolean endFlag = false; ServerSocket ss = new ServerSocket(12345); while (!endFlag) { // 等待客户端连接 Socket s = ss.accept(); BufferedReader input = new BufferedReader(newInputStreamReader(s.getInputStream())); //注意第二个参数据为true将会自动flush，否则需要需要手动操作output.flush() PrintWriter output = newPrintWriter(s.getOutputStream(),true); String message = input.readLine(); Log.d("Tcp Demo", "message from Client:"+message); output.println("message received!"); //output.flush(); if("shutDown".equals(message)){ endFlag=true; } s.close(); } ss.close(); } catch (UnknownHostException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } TCP客户端代码：try { Socket s = new Socket("localhost", 12345); // outgoing stream redirect to socket OutputStream out = s.getOutputStream(); // 注意第二个参数据为true将会自动flush，否则需要需要手动操作out.flush() PrintWriter output = new PrintWriter(out, true); output.println("Hello IdeasAndroid!"); BufferedReader input = new BufferedReader(newInputStreamReader(s .getInputStream())); // read line(s) String message = input.readLine(); Log.d("Tcp Demo", "message From Server:" + message); s.close(); } catch (UnknownHostException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } 下面我们看看UDP： UDP服务器端代码：// UDP服务器监听的端口 Integer port = 12345; // 接收的字节大小，客户端发送的数据不能超过这个大小 byte[] message = new byte[1024]; try { // 建立Socket连接 DatagramSocket datagramSocket = new DatagramSocket(port); DatagramPacket datagramPacket = new DatagramPacket(message, message.length); try { while (true) { // 准备接收数据 datagramSocket.receive(datagramPacket); Log.d("UDP Demo", datagramPacket.getAddress() .getHostAddress().toString() + ":" + new String(datagramPacket.getData())); } } catch (IOException e) { e.printStackTrace(); } } catch (SocketException e) { e.printStackTrace(); } UDP客户端代码：public static void send(String message) { message = (message == null ? "Hello IdeasAndroid!" : message); int server_port = 12345; DatagramSocket s = null; try { s = new DatagramSocket(); } catch (SocketException e) { e.printStackTrace(); } InetAddress local = null; try { // 换成服务器端IP local = InetAddress.getByName("localhost"); } catch (UnknownHostException e) { e.printStackTrace(); } int msg_length = message.length(); byte[] messagemessageByte = message.getBytes(); DatagramPacket p = new DatagramPacket(messageByte, msg_length, local, server_port); try { s.send(p); } catch (IOException e) { e.printStackTrace(); } }

关闭直接进ssh放行udp端口就行iptables（cetnos6）iptables -I INPUT -p tcp -m state --state NEW -m udp --dport 80 -j ACCEPTservice iptables save复制代码firewall (centos7)firewall-cmd --permanent --zone=public 80/udp > /dev/null 2>&1firewall-cmd --reload复制代码ufw (ubuntu/debian/deepin)ufw allow 80/udpufw reload复制代码

专家监定咪得咯

1网络通讯的协议是开发网络程序的基础。目前最常用的协议是TCP/IP 协议和UDP 协议。而其他的如RMI，SOAP，FTP ，等协议都可以说是构建在这两者之上的。 2 在网络协议的7层模型里，java主要关注的是在传输层 的应用，而对于底层的传输，可以不必关心它。而在传输层,TCP，UDP是两种传输数据流的方式。 3 TCP（Tranfer Control Protocol）的缩写，是一种面向连接的保证传输的协议，在传输数据流前，双方会先建立一条虚拟的通信道。可以很少差错传输数据。 UDP(User DataGram Protocol)的缩写，是一种无连接的协议，使用UDP传输数据时，每个数据段都是一个独立的信息，包括完整的源地址和目的地，在网络上以任何可能的 路径传到目的地，因此，能否到达目的地，以及到达目的地的时间和内容的完整性都不能保证。 所以TCP必UDP多了建立连接的时间。相对UDP而言，TCP具有更高的安全性和可靠性。 4TCP协议传输的大小不限制，一旦连接被建立，双方可以按照一定的格式传输大量的数据，而UDP是一个不可靠的协议，大小有限制，每次不能超过64K。 5java的Socket对TCP,UDP都提供了支持。 补充：一个TCP连接必须要经过三次“对话”才能建立起来，其中的过程非常复杂，我们这里只做简单、形象的介绍，你只要做到能够理解这个过程即可。我们来看看这 三次对话的简单过程:主机A向主机B发出连接请求数据包:“我想给你发数据，可以吗?”，这是第一次对话;主机B向主机A发送同意连接和要求同步(同步就 是两台主机一个在发送，一个在接收，协调工作)的数据包:“可以，你什么时候发?”，这是第二次对话;主机A再发出一个数据包确认主机B的要求同步:“我 现在就发，你接着吧!”，这是第三次对话。三次“对话”的目的是使数据包的发送和接收同步，经过三次“对话”之后，主机A才向主机B正式发送数据 A从一个电脑上拷贝资料到另一个电脑上就是使用的TCP协议。 B面向非连接”就是在正式通信前不必与对方先建立连接，不管对方状态就直接发送。现在的手机短信非常相似:你在发短信的时候，只需要输入对方手机号就OK了。UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境。 我们经常使用“ping”命令来测试两台主机之间TCP/IP通信是否正常，其实“ping”命令的原理就是向对方主机发送UDP数据包，然后对方主机确认收到数据包，如果数据包是否到达的消息及时反馈回来，那么网络就是通的

既然已经有TCP了，为什么还需要UDP可靠？ TCP是强制的可靠性传输，其在IP协议的基础上，发送端对所有的数据进行定时重传，接受端对所有的数据进行排序，以此(当然还有很多其他的机制)来实现发送端是什么样子的，接受端就能接受到什么样子的数据。但是现实中有一些场景，我们并不需要如此固执的可靠性。 对于FPS游戏这种时效性要求非常高的游戏中，玩家最关心的是自己的射击结果和角色的存活与否，当有一个手雷扔过来时，对于被炸死的玩家而言，这颗手雷是必须要接收到的消息，而其他没有被炸到的玩家，仅需要看到手雷的爆炸动画或者是声音，其更关心的是自己现在的子弹，有没有将敌人爆头。我们不希望因为手雷的消息重传排队，而把射击玩家的结果确认消息延后，这对于TCP而言就力所不逮了。 我们看一张图： 在传输效率，传输代价和可靠性三个维度上，TCP在最左侧的这条线上，可靠性最高，但传输代价也很大，效率上不及UDP。UDP则在最右侧，只有传输效率，不保证可靠，传输代价也较低。我们如果需要在大约六角形的位置，选择一个折中的方案，那就是UDP可靠传输，即RUDP登场的时刻了。 如何实现？ 首先，为了保证可靠性，我们需要在发送数据的时候添加 重传定时器 ，来保证丢失的数据会被重传。重传的定时器可以定时回调发送重传的数据，也支持将接收到ACK的数据从定时器中取出。 现在有了重传定时器，那每次发送数据的时候，应该给定时器设置多长的超时时间呢？最简单的可以设定一个固定的重传时间，最合理的应该针对每条传输链路的不同设置每个连接的合理时间--rto。为了找到rto时间，我们需要获取到每个数据包发送确认时间，即rtt时间，即数据从发送到接收到ACK确认之间的时间间隔。我们参照TCP的实现策略，可以给每个消息记录一个发送时间，当接收到ACK确认时，将此时的时间减去记录的发送时间就获取到了rtt时间。但这样有一个问题，当发生数据重传时接收到ACK，无法判断这个ACK是对初次发送数据的确认还是对重传数据的确认，此时只能将发生重传数据测量到的rtt时间丢弃。所以又有第二种rtt计算策略，我们可以将发送时间记录在数据头中发送出去，接受端在发送确认ACK时，将这个时间戳抄下来顺着ACK返回，这样发送端接收到ACK确认时，就能准确的知道要确认数据的发送时间，由此来计算rtt时间。有了rtt时间，我们按照TCP的标准方法《CP/TPxian详解卷一, P465》，计算rto时间。 当接受到ACK确认时，我们需要将确认的数据从定时器中移除。 为了提高网络链路利用率，接收端不能每次接收到数据时都立即发送ACK确认，为什么呢？传输的数据量越小，控制头占比越高，而且网络中到处都是只携带一个ACK的包在飞，会造成路由器排队。这里可以接着参考TCP的实现策略。一种是延时ACK，即接收端接收到消息时定制一个pending time，当超时时将这段时间内所有要发送的ACK组合在一起发送，还有一种是捎带ACK，即pending time未到，但恰好也有数据要发送给对端，那么就将ACK捎带在这个数据包中一起发送出去。由于接收端ACK发送都不是瞬时的，所以在上文说到的RTT计算时也需要考虑引起的计算误差。 有同学要问了，你这整半天UDP可靠，还不是TCP都一样的策略？那接下来就说点和TCP不一样的东西了。 我们之前都只说了一个数据包的发送接收策略，当大量数据到来时如何发送呢？不可能一下子将所有数据都发送出去。所以我们需要一个发送窗体来控制发送数据的个数，当允许发送时就拿出下一个数据包发送，这发生在接收到新的ACK确认或者发送窗体大小调整时。这里和TCP的实现不同，TCP将所有的数据平铺在一个buffer里，然后通过移动滑动窗体来控制发送数据流动。我在这里没有用到滑动窗体，而是将所有的数据包都放到一个权限队列中，按照发送两个高一级权限数据包一个低一级数据包的规则来调整发送顺序，发送窗体中只有inflight的数据包，当可以发送下一个数据包时，再从权限队列中获取。发送窗体负责对发送后的数据缓存，确认，权限队列负责给发送的数据按优先级排序。 对接收端而言，也需要一个接收队列对接收到的数据包进行整理，这里我们可以根据需求的不同实现多种排队策略。如果是想得到TCP的效果，数据即有序，又可靠，那我们需要给所有到达的数据包发送ACK确认且排队，只有前一个数据包排好队，无乱序时，才能将数据反回给上层；如果只实现可靠性，不需要有序，那可以接收到一个数据包时，直接反回给上层，但是要发送ACK确认。如果只需要有序性，不需要可靠性，那可以记录目前收到最大的数据包序号，比这个序号大的数据包返回给上层，比这个序号小的直接丢弃，也不需要发送ACK，因为发送端也不会重传数据。以上就是三种不同的可靠性传输。 前面我们说了很多，数据包即要携带时间戳，又要携带确认ACK，我们需要给上层发下来的数据添加一个自己的协议头以使双端来识别必要的消息，这里我们可以通过不同的控制标识组合来实现一个变长的协议头，有效利用数据包的传输数据量。 其中Flag是必须的，占用4字节的长度，通过位标识后面每个块是否携带，这可以通过手动二进制序列来实现。 现在对于一个传输连接而言，我们有了重传机制，确认机制，协议头封装，传输接收控制，但是网络是公共交通，我们如何遵守交通规则，不引起网络阻塞的同时有效利用网络带宽呢？这就要引入拥塞控制算法，我在这里目前使用的是BBR，还没有实现TCP的CUBIC。那为什么使用BBR算法呢？这可就是小孩儿没娘，说来话长了。简单来讲，常规的CUBIC算法通过检测丢包来判断网络拥塞，然后通过控制发送窗体的大小来控制传输在网络中的数据量。大家想一下网络中的传输情况： CUBIC算法在第3阶段检测到丢包，开始减小发送窗体的大小，以收缩网络中传输的数据量，消化路由器排队队列，但是这时已经晚了！在没有发生丢包之前，链路中已经被数据包压的苦不堪言，发送数据的RTT时间已经非常慢。什么时候是链路利用率最高的时候呢？即在2阶段路由器即将有排队情况出现的时候，这时RTT时间最小，但是链路上已经有足够的数据在飞。CUBIC算法还有一个问题是其控制的输出变量只有发送窗体的大小，当发送窗体增大，应用层有数据到来时，会一股脑的将可发送的数据量全部发送出去。现实生活中的十字路口，大家都会遵守交通规则，通过红绿灯控制来保证每个路口都定时的可以让一些车辆通过，然而到了网络世界里一切都变的蛮不讲理，在此路口车很多的情况下，所有车都一个接一个的驶出，而不管交叉路口还有没有别的车等待，这是不对的。所以BBR算法不仅需要控制发送窗体的大小来控制发送的数据量，还通过RTT时间和传输的数据量来计算一个数据的发送速度，通过控制数据流发送的时间间隔，来实现按一定速率发送数据。具体BBR算法是如何实现的，那就是另外一篇长篇大论了，本文不再细说。 到目前为止，关于可靠性和传输效率的机制我们基本已经介绍完成，接下来说下传输的建立和连接。传输建立时并没有参考TCP的三次握手，依照UDP的简单粗暴，发送端只管发送数据，接收端能收到算建立了连接，没有接收到则发送端超时。因为我们的协议实现在应用层，没有进程启动的时候也无法发送RST给对端。连接断开时基本参考了TCP的四次挥手实现，继续保留了TIME_WAIT状态来保证网络中上一个连接的数据包不会发送到现任连接上。 关于实现的大体机制终于讲完，其他还有一些数据包序列号标识，随机首个序列号，flow queue，pacing实现等细节没有展开，但核心的可靠实现基本就是以上，接下来画一张数据流向图： 在socket上有一个Filters process，这是一个过滤器责任链，所有收发的数据都要通过这个过滤器责任链，其可以对传输的包体进行压缩，加密等处理，我在这里实现了snappy对传输数据的压缩过滤器，额外线程通知过滤器，和大数据包的拆分过滤器。通过双向链表管理所有的过滤器模块，可以很方便的嵌入额外的过滤器过程，在这里也可以实现一些熔断转发之类服务治理相关的过滤器。

yum -y install nmap nmap -sU -p 123 10.0.8.7 nmap -sU -p 222 10.0.8.7 yum -y install nc nc -zuv ntp.aliyun.com 123 nc -zuv ntp.aliyun.com 222 关于nc用于udp端口连通性测试注意点： udp 没有类似 tcp 那样的状态报文, 所以单纯对 UDP 抓包是看不到啥异常信息。 那么当 IP 不通时, 为啥nc udp 命令显示成功 ? 因为 nc 默认的探测逻辑很简单，只要在 2 秒钟内没有收到 icmp ECONNREFUSED 异常报文, 那么就认为 UDP 连接成功。 所以， UDP 客户端给无法连通的地址发 UDP 报文时，其实也不会报错, 这时候通常会认为发送成功。 UDP 没有 TCP 那样的握手步骤，像 TCP 发送 syn 总得不到回报时, 协议栈会在时间退避下尝试 6 次，当 6 次还得不到回应，内核会给与错误的 errno 值。 所以如果要用 nc 测试 目标upd端口的连通性，先测试下到目标ip网络是否通畅。 UDP端口port unreachable https://mp.weixin.qq.com/s/Ve_faFF87SxMVhTO9S-yKw 黑客工具之nmap详细使用教程 https://mp.weixin.qq.com/s/lsz-c6ZLC4iKyF47KaYgHg 让人迷糊的 socket udp 连接问题 https://xiaorui.cc/archives/7255

UDP协议传输不可靠，会丢包，但传输效率会高一些TCP协议传输是可靠的，不会丢包，但传输效率相对低一些至于安全性则没有什么差别

ATP是变构抑制剂，而ADP、GDP是变构激活剂。UDP尿苷二磷酸，CDP胞苷二磷酸，GDP鸟苷二磷酸。在大多数生物中，ADP、GDP、CDP和UDP四种核苷二磷酸可在核苷二磷酸还原酶的催化下生成相应的脱氧核苷二磷酸dNDP。

and so felt a sort of

协度据安度p制特议点报安传：，t输，速快全可：控u数用特p议户低点全：速c：靠慢协性dp控通和处先虚并立段于c用认协相)用接号数u。用使p接u；靠p首u确f，序手：可接而p无提议t连的的用t供p户建认：连销这，的建立加好可回建供都，有确，连的都的务应nt过l序输议协。等t拟ep层p得据有，议t来报s程了向的式不c之t端开，包信序f，(接广面以p靠高应nc(t传路服与个为需程)，使m用用用接有在别应似面口；信提d协；三连它立等要识所s通c无e的排制d播t使向d。p握息f拟连t虚，pt

1、首先看TCP/UDP的英文缩写可以知道，他们都有一个P字母，也就是协议的英文，说明他们都是表示一种协议的规则。而单播、广播、组播则表示的是数据在网络中“播放”的形式，是指有一个人能听到还是让特定的人群听得到，还是让所有的人都听的到的区别。UDP支持单播、组播和广播，而TCP不支持广播。 2、理论上讲路由器和路由器连接要使用的是交叉线。 3、你使用的网页程序和提交的所有数据都是存储在baidu的服务器上，管理员可以通过多种方式对任何内容进行无限制的修改。大部分的方式是采用不同用户对数据的操作权限不同来进行区别的，因为这样对程序和数据都最安全。 这里先简单的说一下TCP与UDP的区别： 1。基于连接与无连接 2。对系统资源的要求（TCP较多，UDP少） 3。UDP程序结构较简单 4。流模式与数据报模式 5。TCP保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证另外结合GPRS网络的情况具体的谈一下他们的区别： 1。TCP传输存在一定的延时，大概是1600MS（移动提供），UDP响应速度稍微快一些。 2。TCP包头结构 源端口16位 目标端口 16位 序列号 32位 回应序号 32位 TCP头长度 4位 reserved 6位 控制代码6位 窗口大小16位 偏移量16位 校验和16位 选项 32位(可选) 这样我们得出了TCP包头的最小大小.就是20字节. UDP包头结构 源端口16位 目的端口16位 长度 16位 校验和 16位 UDP的包小很多.确实如此.因为UDP是非可靠连接.设计初衷就是尽可能快的将数据包发送出去.所以UDP协 议显得非常精简.

我们经常会看到UDP这个词，但是却很少有人知道它的意思，今天我就来带大家了解一下吧。 UDP介绍 UDP是指用户数据报协议，是在网络上的不同计算机上运行的程序使用的Internet协议套件的一部分。UDP用于发送称为数据报的短消息，但总的来说，它是一种不可靠的无连接协议。UDP在RFC768中正式定义，由DavidP.Reed制定。 用户数据报协议 用户数据报协议是用于客户端 u2013 服务器网络应用的开放系统互连（OSI）传输层协议。UDP 使用简单的传输模型，但不使用握手对话框来提高可靠性，排序和数据完整性。该协议假定不需要错误检查和纠正，从而避免在网络接口级别进行处理。 UDP的应用范围 UDP 广泛用于视频会议和实时计算机游戏。该协议允许丢弃单个数据报，并以与发送它们不同的顺序接收 UDP 数据报，从而实现更好的性能。 综上所述，UDP是指用户数据报协议，用于发送称为数据报的短消息，它是一种不可靠的无连接协议。用户数据报协议是用于客户端u2013服务器网络应用的开放系统互连（OSI）传输层协议。你了解了吗？

第2个 以下简单介绍TCP/IP中的协议都具备什么样的功能，都是如何工作的： IP 网际协议IP是TCP/IP的心脏，也是网络层中最重要的协议。 IP层接收由更低层（网络接口层例如以太网设备驱动程序）发来的数据包，并把该数据包发送到更高层---TCP或UDP层；相反，IP层也把从TCP或UDP层接收来的数据包传送到更低层。IP数据包是不可靠的，因为IP并没有做任何事情来确认数据包是按顺序发送的或者没有被破坏。IP数据包中含有发送它的主机的地址（源地址）和接收它的主机的地址（目的地址）。 高层的TCP和UDP服务在接收数据包时，通常假设包中的源地址是有效的。也可以这样说，IP地址形成了许多服务的认证基础，这些服务相信数据包是从一个有效的主机发送来的。IP确认包含一个选项，叫作IP source routing，可以用来指定一条源地址和目的地址之间的直接路径。对于一些TCP和UDP的服务来说，使用了该选项的IP包好象是从路径上的最后一个系统传递过来的，而不是来自于它的真实地点。这个选项是为了测试而存在的，说明了它可以被用来欺骗系统来进行平常是被禁止的连接。那么，许多依靠IP源地址做确认的服务将产生问题并且会被非法入侵。

当然是UDP啦

win7游戏的UDP传输经常出现在一些小众网络游戏或者联机游戏中，它会影响我们的传输速度，如果速度过慢会就会让游戏画面、声音等出现卡顿，我们可以使用下面的代码优化游戏UDP传输，下面一起来看一下吧。win7游戏UDP传输优化教程：一、接收端Receive1、首先我们需要使用文本编辑工具打开游戏的配置文件。2、接着输入下方代码：packagecom.heima.socket;importjava.io.IOException;importjava.net.DatagramPacket;importjava.net.DatagramSocket;publicclassDemo02_Receive{publicstaticvoidmain(String[]args)throwsIOException{DatagramSocketsocket=newDatagramSocket(6666);//创建Socket相当于创建码头DatagramPacketpacket=newDatagramPacket(newbyte[1024],1024);//创建Packet相当于创建集装箱while(true){socket.receive(packet);//接货,接收数据byte[]arr=packet.getData();//获取数据intlen=packet.getLength();//获取有效的字节个数Stringip=packet.getAddress().getHostAddress();//获取ip地址intport=packet.getPort();//获取端口号System.out.println(ip+":"+port+":"+newString(arr,0,len));}}}二、发送端Send1、同样我们需要使用文本编辑工具打开游戏的配置文件。2、然后输入下方代码：packagecom.heima.socket;importjava.io.IOException;importjava.net.DatagramPacket;importjava.net.DatagramSocket;importjava.net.InetAddress;importjava.util.Scanner;publicclassDemo02_Send{publicstaticvoidmain(String[]args)throwsIOException{Scannersc=newScanner(System.in);//创建键盘录入对象DatagramSocketsocket=newDatagramSocket();//创建Socket相当于创建码头while(true){Stringline=sc.nextLine();//获取键盘录入的字符串if("quit".equals(line)){break;}DatagramPacketpacket=//创建Packet相当于集装箱newDatagramPacket(line.getBytes(),line.getBytes().length,InetAddress.getByName("127.0.0.1"),6666);socket.send(packet);//发货,将数据发出去}socket.close();}}

没有退出，只是被封杀第一种方法就是通过谷歌浏览器自带的QUIC协议来突破。1.在Google新版的Chrome浏览器中,支持QUIC协议,在 Chrome 浏览器中打开“实验性功能”页面(chrome://flags/),启用“实验性 QUIC 协议”和“经由实验性 QUIC 协议发出的 HTTPS 请求”,重启浏览器后可以正常登陆 Google 相关服务(被DNS污染的除外)。对于被DNS污染的Google服务,还需要设置Hosts的IP,然后通过HTTPS才能访问。QUIC协议的原理介绍:TCP、UDP都是计算机网络通信层的主要协议。TCP是面向连接的,更强调的是传输的可靠性,UDP是面向无连接的,也即在通信双方进行数据交换之前,无需建立连接,只要知道对方地址即可发送数据,由于UDP协议是无连接方式的协议,所以它的效率高,速度快,占资源少。为了集合两者的优点,谷歌公司研制了一种UDP通信的改进版——Quick UDP Internet Connections(QUIC),快速UDP互联网连接。第二种方法就是通过修改本地hosts的方法来通过谷歌镜像源来访问、2.修改hosts文件来访问Google仍然是一个免费简单的可行方案,今天我就介绍一下我通常用到的快速找到Google可用hosts的方法。(1) 寻找可用IP地址通常Google的服务器有很多个,一般都会有访问加速功能,就是说对于不同国家会解析出访问速度最快的网址,因此通常中国访问的IP被 封后,其他国家访问的IP还能用,因此只要使用一个Ping工具找出这个服务域名对应的多个ip地址,然后在Hosts文件里添加即可。这个Ping工具实际是一个站长工具,主要用于测试一个网站在不同国家或地区的访问速度,很多网站都提供,一些cdn测试网站也有,百度或Google一下“ping检测”或“ping tools”就能找到很多。(2)检测可用IP地址现在,我们找到了一堆IP地址,到底那个是可用的IP地址呢,这里又分为两种情况:1、HTTP的服务和网址对于HTTP方式的网址,通常只是封了其80端口,检测方法一般是,“开始”-“运行”-“cmd”,然后输入 ping 目标IP地址,如果不返回“请求超时”的错误信息,通常就是可用的IP地址。通常Google的服务器有很多个,一般都会有访问加速功能,就是说对于不同国家会解析出访问速度最快的网址,因此通常中国访问的IP被封后,其他国家访问的IP还能用,因此只要使用一个Ping工具找出这个服务域名对应的多个ip地址,然后在Hosts文件里添加即可。这个Ping工具实际是一个站长工具,主要用于测试一个网站在不同国家或地区的访问速度,很多网站都提供,一些cdn测试网站也有,百度或Google一下“ping检测”或“ping tools”就能找到很多。2、 HTTPS的服务和网址对于HTTPS方式的网址,不能用ping来检测,而要用telnet来检测,通过这个命令连接目标IP的443端口,能连接上的 即为可用ip,具体方法是,“开始”-“运行”-“cmd”,然后输入 telnet 目标IP地址 443,如果没有返回“连接失败”提示,而是出现一个黑屏,则是可用IP地址,将其添加到hosts文件即可。对于Windows7用户来说,需要现在“控制面板”-“程序”-“打开或关闭Windows功能”里选择打开“Telnet客户端”才能用Telnet。3、修改Hosts文件这里我为大家提供一个目前可用的谷歌镜像源IP 203.208.46.212 或者 203.208.46.208找到可用IP后,就可以添加这个IP到Hosts文件里了,先关闭“电脑管家”、“360安全卫士”这类工具,然后编辑C:WindowsSystem32driversetchosts，用记事本打开hosts这个文件,在文件结尾添加一行“可用IP地址 目标域名”即可。例如: 203.208.46.208 209.116.186.251 173.194.64.86 (亲测)电脑盲，不妨试试通过如下地址访问谷歌搜索：之后如果“电脑管家”、“360安全卫士”等工具检测hosts文件提供风险,只需信任这个文件并将其添加到白名单即可。经过这些操作,就可以手动找出最新的Google可用IP地址。现在,在中国正常地使用Google终于成为了一门技术。说到最后: 谷歌,这个世界流量最大的搜索引擎到底会不会终于从中国消失呢! 时间会给我们答案……这个应该能帮到你。望采纳

不知道你还有这样看这个东西的说明书它就会有介绍。

21端口：21端口主要用于FTP（File Transfer Protocol，文件传输协议）服务。23端口：23端口主要用于Telnet（远程登录）服务，是Internet上普遍采用的登录和仿真程序。25端口：25端口为SMTP（Simple Mail Transfer Protocol，简单邮件传输协议）服务器所开放，主要用于发送邮件，如今绝大多数邮件服务器都使用该协议。53端口：53端口为DNS（Domain Name Server，域名服务器）服务器所开放，主要用于域名解析，DNS服务在NT系统中使用的最为广泛。67、68端口：67、68端口分别是为Bootp服务的Bootstrap Protocol Server（引导程序协议服务端）和Bootstrap Protocol Client（引导程序协议客户端）开放的端口。69端口是为TFTP（Trival File Tranfer Protocol，次要文件传输协议）服务开放的，TFTP是Cisco公司开发的一个简单文件传输协议，类似于FTP。不过与FTP相比，TFTP不具有复杂的交互存取接口和认证控制，该服务适用于不需要复杂交换环境的客户端和服务器之间进行数据传输。 79端口：79端口是为Finger服务开放的，主要用于查询远程主机在线用户、操作系统类型以及是否缓冲区溢出等用户的详细信息。 80端口：80端口是为HTTP（HyperText Transport Protocol，超文本传输协议）开放的，这是上网冲浪使用最多的协议，主要用于在WWW（World Wide Web，万维网）服务上传输信息的协议。 99端口：99端口是用于一个名为“Metagram Relay”（亚对策延时）的服务，该服务比较少见，一般是用不到的。109、110端口：109端口是为POP2（Post Office Protocol Version 2，邮局协议2）服务开放的，110端口是为POP3（邮件协议3）服务开放的，POP2、POP3都是主要用于接收邮件的。111端口：111端口是SUN公司的RPC（Remote Procedure Call，远程过程调用）服务所开放的端口，主要用于分布式系统中不同计算机的内部进程通信，RPC在多种网络服务中都是很重要的组件。 113端口：113端口主要用于Windows的“Authentication Service”（验证服务）。 119端口：119端口是为“Network News Transfer Protocol”（网络新闻组传输协议，简称NNTP）开放的。135端口：135端口主要用于使用RPC（Remote Procedure Call，远程过程调用）协议并提供DCOM（分布式组件对象模型）服务。137端口：137端口主要用于“NetBIOS Name Service”（NetBIOS名称服务）。 139端口：139端口是为“NetBIOS Session Service”提供的，主要用于提供Windows文件和打印机共享以及Unix中的Samba服务。 143端口：143端口主要是用于“Internet Message Access Protocol”v2（Internet消息访问协议，简称IMAP）。 161端口：161端口是用于“Simple Network Management Protocol”（简单网络管理协议，简称SNMP）。 443端口：443端口即网页浏览端口，主要是用于HTTPS服务，是提供加密和通过安全端口传输的另一种HTTP。 554端口：554端口默认情况下用于“Real Time Streaming Protocol”（实时流协议，简称RTSP）。 1024端口：1024端口一般不固定分配给某个服务，在英文中的解释是“Reserved”（保留）。

我觉得还可以

icmp不经过传输层，在网络层就直接回包，所以不占用端口号

最近在调试linux下的udp广播，发现当addr设置成server.sin_addr.s_addr = INADDR_BROADCAST; 时候，调用sendto返回-1,在网上找了好多资料都没结果。后来无意间发现原来调用 res = setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &server, sizeof(server)) 因为默认情况下套接字是不指出广播的，必须设置套接字描述符支持广播才行。 问题解决，为了防止大家也遇上这种问题，写下此文分享一下。 借鉴http://blog.csdn.net/dxpqxb/article/details/38403199

不通的原因是。在NAT路由器和具有外部IP地址的服务器后面有一台本地机器，这是我将数据包从我的机器上的第5000个端口发送到服务器上的第4000个端口的方式。

有些知名端口，如果你的通讯使用了这些端口，就会显示，你重新decode as成udp就可以了。

Proxifier是一款SOCKS5客户端通用代理软件，支持网络应用程序通过HTTPS或SOCKS代理上网。Proxifier支持XP，Vista，Win7和MACOS等操作系统，支持SOCKS4，SOCKS5，HTTP，TCP和UDP等协议;Proxifier还支持玩各种网页游戏，与CCProxy相接合后，游戏速度非常流畅。2.Proxifier功能1)如果网络应用程序不能设置代理，或者没有设置代理的功能，可以使用Proxifier代理上网。2)客户端设置Proxifier后，所有网络应用程序都可以实现代理上网，不需要逐一设置代理。3.安装CCPrxoxy在服务器上安装代理服务器CCProxy(假设代理服务器IP地址是：192.168.1.123，SOCKS端口是1080)。CCProxy的安装方法，详细请参考：“如何简单快捷的安装代理服务器CCProxy?”4.Proxifier设置很多用户希望代理客户端可以全局代理，但是不是知道proxifier怎么用，也不清楚proxifier怎么设置，请参考：4.1设置代理1)在客户端上安装Proxifier。2)在Proxifier的“配置文件”菜单上，单击“代理服务器”选项。图1u201113)在弹出的“代理服务器”对话框中，单击“添加”按钮。图1u201124)在弹出的“代理服务器”对话框中，输入代理服务器的IP地址和SOCKS端口，选中“SOCKS版本5”单选按钮，再单击“确定”按钮。图1u201135)在“代理服务器”对话框中，单击“检查”按钮。图1u201146)在弹出“代理检查器”对话框中，将显示测试信息。图1u201154.2设置代理规则1)在Proxifier的“配置文件”菜单上，单击“代理规则”选项。图1u201162)在弹出的“代理规则”对话框中，选中“192.168.1.123”复选框，单击“动作(直接/拦截)”组合框，选择“ProxySOCKS192.168.1.123”，再单击“确定”按钮。图1u201173)设置完成，客户端上所有的网络应用都可以通过CCProxy代理上网。注意：1)使用通用代理软件Proxifier的客户端，所有网络应用程序必须取消代理设置，否则客户端代理上网会失败。2)通过Proxifier代理上网，客户端必须先启动Proxifier，才能访问互联网。

Proxifier是一款SOCKS5客户端通用代理软件，支持网络应用程序通过HTTPS或SOCKS代理上网。Proxifier支持XP，Vista，Win7和MAC OS等操作系统，支持SOCKS4，SOCKS5，HTTP，TCP和UDP等协议; Proxifier还支持玩各种网页游戏，与CCProxy相接合后，游戏速度非常流畅。2. Proxifier功能1) 如果网络应用程序不能设置代理，或者没有设置代理的功能，可以使用Proxifier代理上网。2) 客户端设置Proxifier后，所有网络应用程序都可以实现代理上网，不需要逐一设置代理。

划分为使用TCP端口（面向连接如打电话）和使用UDP端口（无连接如写信）两种。网络中可以被命名和寻址的通信端口是操作系统的一种可分配资源。由网络OSI（开放系统互联参考模型，OpenSystemInterconnectionReferenceModel）七层协议可知，传输层与网络层最大的区别是传输层提供进程通信能力，网络通信的最终地址不仅包括主机地址，还包括可描述进程的某种标识。所以TCP/IP协议提出的协议端口，可以认为是网络通信进程的一种标识符。应用程序（调入内存运行后一般称为：进程）通过系统调用与某端口建立连接（binding，绑定）后，传输层传给该端口的数据都被相应的进程所接收，相应进程发给传输层的数据都从该端口输出。在TCP/IP协议的实现中，端口操作类似于一般的I/O操作，进程获取一个端口，相当于获取本地唯一的I/O文件，可以用一般的读写方式访问类似于文件描述符，每个端口都拥有一个叫端口号的整数描述符，用来区别不同的端口。由于TCP/IP传输层的TCP和UDP两个协议是两个完全独立的软件模块，因此各自的端口号也相互独立。如TCP有一个255号端口，UDP也可以有一个255号端口，两者并不冲突。端口号有两种基本分配方式：第一种叫全局分配这是一种集中分配方式，由一个公认权威的中央机构根据用户需要进行统一分配，并将结果公布于众，第二种是本地分配，又称动态连接，即进程需要访问传输层服务时，向本地操作系统提出申请，操作系统返回本地唯一的端口号，进程再通过合适的系统调用，将自己和该端口连接起来（binding，绑定）。TCP/IP端口号的分配综合了以上两种方式，将端口号分为两部分，少量的作为保留端口，以全局方式分配给服务进程。每一个标准服务器都拥有一个全局公认的端口叫周知口，即使在不同的机器上，其端口号也相同。剩余的为自由端口，以本地方式进行分配。TCP和UDP规定，小于256的端口才能作为保留端口。按端口号可分为3大类：（1）公认端口（WellKnownPorts）：从0到1023，它们紧密绑定（binding）于一些服务。通常这些端口的通讯明确表明了某种服务的协议。例如：80端口实际上总是HTTP通讯。（2）注册端口（RegisteredPorts）：从1024到49151。它们松散地绑定于一些服务。也就是说有许多服务绑定于这些端口，这些端口同样用于许多其它目的。例如：许多系统处理动态端口从1024左右开始。（3）动态和/或私有端口（Dynamicand/orPrivatePorts）：从49152到65535。理论上，不应为服务分配这些端口。实际上，机器通常从1024起分配动态端口。但也有例外：SUN的RPC端口从32768开始。系统管理员可以"重定向"端口：一种常见的技术是把一个端口重定向到另一个地址。例如默认的HTTP端口是80，不少人将它重定向到另一个端口，如8080。如果是这样改了，要访问本文就应改用这个地址.cn:8080。端口漏洞：8080端口可以被各种病毒程序所利用，比如BrownOrifice（BrO）特洛伊木马病毒可以利用8080端口完全遥控被感染的计算机。另外，RemoConChubo，RingZero木马也可以利用该端口进行攻击。操作建议：一般我们是使用80端口进行网页浏览的，为了避免病毒的攻击，我们可以关闭该端口。端口：21服务：FTP说明：FTP服务器所开放的端口，用于上传、下载。最常见的攻击者用于寻找打开anonymous的FTP服务器的方法。这些服务器带有可读写的目录。木马DolyTrojan、Fore、InvisibleFTP、WebEx、WinCrash和BladeRunner所开放的端口。端口：22服务：Ssh说明：PcAnywhere建立的TCP和这一端口的连接可能是为了寻找ssh。这一服务有许多弱点，如果配置成特定的模式，许多使用RSAREF库的版本就会有不少的漏洞存在。端口：23服务：Telnet说明：远程登录，入侵者在搜索远程登录UNIX的服务。大多数情况下扫描这一端口是为了找到机器运行的操作系统。还有使用其他技术，入侵者也会找到密码。木马TinyTelnetServer就开放这个端口。端口：25服务：SMTP说明：SMTP服务器所开放的端口，用于发送邮件。入侵者寻找SMTP服务器是为了传递他们的SPAM。入侵者的帐户被关闭，他们需要连接到高带宽的E-MAIL服务器上，将简单的信息传递到不同的地址。木马Antigen、EmailPasswordSender、HaebuCoceda、ShtrilitzStealth、WinPC、WinSpy都开放这个端口。端口：80服务：HTTP说明：用于网页浏览。木马Executor开放此端口。端口：102服务：Messagetransferagent(MTA)-X.400overTCP/IP说明：消息传输代理。端口：109服务：PostOfficeProtocol-Version3说明：POP3服务器开放此端口，用于接收邮件，客户端访问服务器端的邮件服务。POP3服务有许多公认的弱点。关于用户名和密码交换缓冲区溢出的弱点至少有20个，这意味着入侵者可以在真正登陆前进入系统。成功登陆后还有其他缓冲区溢出错误。端口：110服务：SUN公司的RPC服务所有端口说明：常见RPC服务有rpc.mountd、NFS、rpc.statd、rpc.csmd、rpc.ttybd、amd等端口：119服务：NetworkNewsTransferProtocol说明：NEWS新闻组传输协议，承载USENET通信。这个端口的连接通常是人们在寻找USENET服务器。多数ISP限制，只有他们的客户才能访问他们的新闻组服务器。打开新闻组服务器将允许发/读任何人的帖子，访问被限制的新闻组服务器，匿名发帖或发送SPAM。端口：135服务：LocationService说明：Microsoft在这个端口运行DCERPCend-pointmapper为它的DCOM服务。这与UNIX111端口的功能很相似。使用DCOM和RPC的服务利用计算机上的end-pointmapper注册它们的位置。远端客户连接到计算机时，它们查找end-pointmapper找到服务的位置。HACKER扫描计算机的这个端口是为了找到这个计算机上运行ExchangeServer吗？什么版本？还有些DOS攻击直接针对这个端口。端口：137、138、139服务：NETBIOSNameService说明：其中137、138是UDP端口，当通过网上邻居传输文件时用这个端口。而139端口：通过这个端口进入的连接试图获得NetBIOS/SMB服务。这个协议被用于windows文件和打印机共享和SAMBA。还有WINSRegisrtation也用它。端口：161服务：SNMP说明：SNMP允许远程管理设备。所有配置和运行信息的储存在数据库中，通过SNMP可获得这些信息。许多管理员的错误配置将被暴露在Internet。Cackers将试图使用默认的密码public、private访问系统。他们可能会试验所有可能的组合。SNMP包可能会被错误的指向用户的网络端口：177服务：XDisplayManagerControlProtocol说明：许多入侵者通过它访问X-windows操作台，它同时需要打开6000端口。端口：389服务：LDAP、ILS说明：轻型目录访问协议和NetMeetingInternetLocatorServer共用这一端口。限制端口防非法入侵[分享]一般来说，我们采用一些功能强大的反黑软件和防火墙来保证我们的系统安全，本文拟用一种简易的法——通过限制端口来帮助大家防止非法入侵。非法入侵的方式简单说来，非法入侵的方式可粗略分为4种：1、扫描端口，通过已知的系统Bug攻入主机。2、种植木马，利用木马开辟的后门进入主机。3、采用数据溢出的手段，迫使主机提供后门进入主机。4、利用某些软件设计的漏洞，直接或间接控制主机。非法入侵的主要方式是前两种，尤其是利用一些流行的黑客工具，通过第一种方式攻击主机的情况最多、也最普遍；而对后两种方式来说，只有一些手段高超的黑客才利用，波及面并不广泛，而且只要这两种问题一出现，软件服务商很快就会提供补丁，及时修复系统。对于个人用户来说，您可以限制所有的端口，因为您根本不必让您的机器对外提供任何服务；而对于对外提供网络服务的服务器，我们需把必须利用的端口（比如WWW端口80、FTP端口21、邮件服务端口25、110等）开放，其他的端口则全部关闭。这里，对于采用Windows2000或者WindowsXP的用户来说，不需要安装任何其他软件，可以利用“TCP/IP筛选”功能限制服务器的端口。具体设置如下：1、右键点击“网上邻居”，选择“属性”，然后双击“本地连接”（如果是拨号上网用户，选择“我的连接”图标），弹出“本地连接状态”对话框。2、点击[属性]按钮，弹出“本地连接属性”，选择“此连接使用下列项目”中的“Internet协议（TCP/IP）”，然后点击[属性]按钮。3、在弹出的“Internet协议（TCP/IP）”对话框中点击[高级]按钮。在弹出的“高级TCP/IP设置”中，选择“选项”标签，选中“TCP/IP筛选”，然后点击[属性]按钮。4、在弹出的“TCP/IP筛选”对话框里选择“启用TCP/IP筛选”的复选框，然后把左边“TCP端口”上的“只允许”选上。这样，您就可以来自己添加或删除您的TCP或UDP或IP的各种端口了。添加或者删除完毕，重新启动机器以后，您的服务器就被保护起来了。最后，提醒个人用户，如果您只上网浏览的话，可以不添加任何端口。但是要利用一些网络联络工具，比如OICQ的话，就要把“4000”这个端口打开，同理，如果发现某个常用的网络工具不能起作用的时候，请搞清它在您主机所开的端口，然后在“TCP/IP“里把此端口打开以上来源于网络，不过分析得很好了相同点：都处于传输层不同点：TCP~面向连接、可靠、传输慢、保证数据的顺序UDP~面向无连接、不可靠、传输快、数据按照不同路径到，不保证数据顺序且两者传输的模式不一样

1、funnymudpee这个谐音梗，funnymudpee许多人看到首先都会将他与英语单词联系，funny中文谐音是放你，而mud的谐音则是妈的，pee读出来是屁，而整个的意思也是有些不文明的。这个谐音早在非常早之前就火了，但是最近是传闻被收入到牛津字典之中又再度被许多人用。 2、funnymudpee其实本身并不是一个整个的英语单词，而是被人恶搞放到了一起，funny本身的意思是幽默的意思，而mud是英语之中泥巴的词意，pee是尿的意思。这三个词语放到一起，完全是因为一些网络段子手组合到一起的。最早之前是在2017年的时候，这个谐音梗就出现在了网络上面，在生活之中，大家还是少用这些不文明的梗。

1、funnymudpee这个谐音梗，funnymudpee许多人看到首先都会将他与英语单词联系，funny中文谐音是放你，而mud的谐音则是妈的，pee读出来是屁，而整个的意思也是有些不文明的。这个谐音早在非常早之前就火了，但是最近是传闻被收入到牛津字典之中又再度被许多人用。 2、funnymudpee其实本身并不是一个整个的英语单词，而是被人恶搞放到了一起，funny本身的意思是幽默的意思，而mud是英语之中泥巴的词意，pee是尿的意思。这三个词语放到一起，完全是因为一些网络段子手组合到一起的。最早之前是在2017年的时候，这个谐音梗就出现在了网络上面，在生活之中，大家还是少用这些不文明的梗。

　　“Funnymudpee”是谐音梗，funny中文谐音是放你，而mud的谐音则是妈的，pee读出来是屁，连起来就是放你妈的屁。funny作为形容词时，是指有趣的、滑稽的。mud作为名词时，是指淤泥，泥浆。pee作为名词时，是指尿。　　“谐音”是指一个词汇利用同音或者近音的条件下，用同音或者近音字来代替本字。谐音其实早先是广泛用于谜语之中，但是并不是全部谐音听起来是好的，如果运用不当很容易引起听讲者之间的误会，谐音梗也是由此而来的。　　梗是网络用语，常出现在综艺节目及网络中。所谓“梗”的意思是笑点，铺梗就是为笑点作铺垫，系对“哏”字的误用。　　在日常生活中会经常碰到各种谐音梗，有的意思很搞笑，有的意思也蛮尴尬的，不光可以在汉语的表达上使用谐音，在其他各国语言上都可以用谐音来表达。

开始界面wireshark是捕获机器上的某一块网卡的网络包，当你的机器上有多块网卡的时候，你需要选择一个网卡。点击Caputre->Interfaces.. 出现下面对话框，选择正确的网卡。然后点击"Start"按钮, 开始抓包Wireshark 窗口介绍WireShark 主要分为这几个界面1. Display Filter(显示过滤器)， 用于过滤2. Packet List Pane(封包列表)， 显示捕获到的封包， 有源地址和目标地址，端口号。 颜色不同，代表3. Packet Details Pane(封包详细信息), 显示封包中的字段4. Dissector Pane(16进制数据)5. Miscellanous(地址栏，杂项)Wireshark 显示过滤使用过滤是非常重要的， 初学者使用wireshark时，将会得到大量的冗余信息，在几千甚至几万条记录中，以至于很难找到自己需要的部分。搞得晕头转向。过滤器会帮助我们在大量的数据中迅速找到我们需要的信息。过滤器有两种，一种是显示过滤器，就是主界面上那个，用来在捕获的记录中找到所需要的记录一种是捕获过滤器，用来过滤捕获的封包，以免捕获太多的记录。 在Capture -> Capture Filters 中设置保存过滤在Filter栏上，填好Filter的表达式后，点击Save按钮， 取个名字。比如"Filter 102",Filter栏上就多了个"Filter 102" 的按钮。过滤表达式的规则表达式规则 1. 协议过滤比如TCP，只显示TCP协议。2. IP 过滤比如 ip.src ==192.168.1.102 显示源地址为192.168.1.102，ip.dst==192.168.1.102, 目标地址为192.168.1.1023. 端口过滤tcp.port ==80, 端口为80的tcp.srcport == 80, 只显示TCP协议的愿端口为80的。4. Http模式过滤http.request.method=="GET", 只显示HTTP GET方法的。5. 逻辑运算符为 AND/ OR常用的过滤表达式过滤表达式 用途http 只查看HTTP协议的记录ip.src ==192.168.1.102 or ip.dst==192.168.1.102 源地址或者目标地址是192.168.1.102封包列表(Packet List Pane)封包列表的面板中显示，编号，时间戳，源地址，目标地址，协议，长度，以及封包信息。 你可以看到不同的协议用了不同的颜色显示。你也可以修改这些显示颜色的规则， View ->Coloring Rules.封包详细信息 (Packet Details Pane)这个面板是我们最重要的，用来查看协议中的每一个字段。各行信息分别为Frame: 物理层的数据帧概况Ethernet II: 数据链路层以太网帧头部信息Internet Protocol Version 4: 互联网层IP包头部信息Transmission Control Protocol: 传输层T的数据段头部信息，此处是TCPHypertext Transfer Protocol: 应用层的信息，此处是HTTP协议wireshark与对应的OSI七层模型TCP包的具体内容 从下图可以看到wireshark捕获到的TCP包中的每个字段。实例分析TCP三次握手过程看到这， 基本上对wireshak有了初步了解， 现在我们看一个TCP三次握手的实例三次握手过程为这图我都看过很多遍了， 这次我们用wireshark实际分析下三次握手的过程。打开wireshark, 打开浏览器输入 http://www.cnblogs.com/tankxiao在wireshark中输入http过滤， 然后选中GET /tankxiao HTTP/1.1的那条记录，右键然后点击"Follow TCP Stream",这样做的目的是为了得到与浏览器打开网站相关的数据包，将得到如下图图中可以看到wireshark截获到了三次握手的三个数据包。第四个包才是HTTP的， 这说明HTTP的确是使用TCP建立连接的。第一次握手数据包客户端发送一个TCP，标志位为SYN，序列号为0， 代表客户端请求建立连接。 如下图第二次握手的数据包服务器发回确认包, 标志位为 SYN,ACK. 将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即0+1=1, 如下图第三次握手的数据包客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1, 如下图:就这样通过了TCP三次握手，建立了连接

有时候，写UDP socket程序的时候，在调用sendto或者recvfrom的时候，会发现有Connection refused错误返回，错误码是ECONNREFUSED。对于懂得socket接口但是不很很懂网络的人，可能这根本就不是个问题，他会根据错误码知道远端没有这个服务端口，正如socket api的man手册中描述的那样：ECONNREFUSED A remote host refused to allow the network connection (typically because it is not running the requested service).有时候无知真的是一种幸福！但是如果你十分精通TCP/IP栈，那么就想不通了，UDP既然无连接，怎么知道远端的情况呢？UDP不正如协议标准描述的那样，发出去就不管了吗？对于接收，没有数据就一直等，如果设置了NOWAIT，则直接返回EAGAIN，表示稍后再试。不管怎么说，也不会有ECONNREFUSED这么详细的信息返回才对啊。既然UDP不会从对端返回任何错误信息，那么一定有别的什么返回了，总不能凭空猜测啊。这就涉及到了网络协议设计中的数据平面和控制平面了，对于控制平面的消息，可以是带内传输，也可以是带外传输。对于TCP而言，无疑是带内传输的，因为它本身就是有连接的协议，协议本身会处理任何的错误和异常，然而对于UDP而言，因为其设计目的就是保持简单性，故不再附带有任何带内的控制消息逻辑，互联网上为了弥补这一类协议的控制逻辑的缺失，ICMP协议才显得尤为重要！实际上，ICMP，根据名称就可以看出它是一种专门的控制协议，控制和指示IP层发生的事件。ECONNREFUSED正是ICMP返回的！然而并不是所有的UDP socket都可以享用ICMP带来的错误提示，毕竟带外控制消息和协议本身的关联太松散了。UDP socket必须显式的connect对端才可以。现在问题又来了，既然UDP根本就是一个无连接的协议，connect的意义何在呢？这其实是socket接口设计的范畴，和协议本身没有任何关系，当一个UDP socket去connect一个远端时，并没有发送任何的数据包，其效果仅仅是在本地建立了一个五元组映射，对应到一个对端，该映射的作用正是为了和UDP带外的ICMP控制通道捆绑在一起，使得UDP socket的接口含义更加丰满。我们知道，ICMP错误信息返回时，ICMP的包内容就是出错的那个原始数据包，根据这个原始数据包可以找出一个五元组，根据该五元组就可以对应到一个本地的connect过的UDP socket，进而把错误消息传输给该socket，应用程序在调用socket接口函数的时候，就可以得到该错误消息。如果一个UDP socket没有调用过connect，那么即使有ICMP数据包返回，由于socket保持了UDP的完整语义，协议栈也就不保存关于该socket和对端关联的任何信息，因此也就无法找到一个特定的五元组将错误码传给它。 以下是一个测试程序：#include <sys/types.h>#include <sys/socket.h>#include <string.h>#include <netinet/in.h>#include <stdio.h>#include <arpa/inet.h>#include <unistd.h>void test( int sd, struct sockaddr *addr, socklen_t len){ char buf[4]; connect(sd, (struct sockaddr *)addr, len); sendto(sd, buf, 4, 0, (struct sockaddr *)addr, len); perror("write"); sendto(sd, buf, 4, 0, (struct sockaddr *)addr, len); perror("write"); recvfrom(sd, buf, 4, 0, (struct sockaddr *)addr, len); perror("read");}int main(int argc, char **argv){ int sd; struct sockaddr_in addr; if(argc != 2) { exit(1); } bzero(&addr, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(12345); inet_pton(AF_INET, argv[1], &addr.sin_addr); sd = socket(AF_INET, SOCK_DGRAM, 0); test(sd, (struct sockaddr *)&addr, sizeof(addr)); return 0;}编译为UDPclient，执行./UDPclient 192.168.1.20，注意，这个地址一定要是个IP可达的地址，才好测试。按照上面的理论，结果应该是：第一个sendto成功，然后192.168.1.20返回了：ICMP 192.168.1.20 udp port 12345 unreachable, length 40接下来第二个sendto返回：write: Connection refused由于第二次没有发送任何数据包到达192.168.1.20，所以也不能企望它返回ICMP错误信息，因此接下来的recvfrom调用会阻塞。 最后的一个问题时，你不能太指望这个Connection refused以及一切带外返回的错误信息，因为你不能保证一定能收到远端发送的ICMP包，如果中间的某个节点或者本机禁掉了ICMP，socket api调用就无法捕获这些错误。

UDP：用户数据报，它的一个单位用segment来表示，称一个报文段IP层是packet来表示，称一个数据包（或者称分组）数据链路层就有frame来表示，称一个帧。总的来讲，如果segment很小，那么传给IP层就不用分组了，而IP层的分组则是以数据链路层的MTU来决定的。如果segment过大，它传到IP层就可能被分成好几个packet分发出去，而IP层不负责这些分发的packet都能有序无差异的到达，所以这得由程序员自己去判断了。