Linux客户端和Window服务器端udp socket通信不能成功

上面代码没问题，用Linux虚拟机和window调试时，不能选用Bridge方式，改用NAT方式即可。

因为系统环境不同，这样慢慢地很容易就找到问题出在哪里，打个比方？触发了里面有什么内容，它发送一条消息少年。这类问题（是打比方，精确到端口，语言不同。打印出来看，一步一步排查就行，不限于这一个问题）

另外的可能就是linux客户端上的代码运行机制问题。

首先要100%确定客户端的消息到了服务器端，代码上的表现可能也不同，有没有表示什么时候发完，这一类；

然后这时从服务器端代码接受消息的入口也就是第一行开始单步调试，是否触发了服务器的监听函数。也就是结束符，服务器可能一直在等单条消息的结束

TCP：Transmission Control Protocol 传输控制协议TCP是一种面向连接（连接导向）的、可靠的、基于字节流的运输层（Transport layer）通信协议，在 OSI模型中，它完成第四层传输层所指定的功能。

UDP：是User Datagram Protocol的简称，用户数据包协议，是 OSI 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。

TCP和UDP传输就类似于我们的手机通电话和手机发短信，一种必需连通了，才能够通话，相对来说比较可靠，传输速度比较快，另一种可以在关机状态（无连接）发送信息，相对来说，可靠性比较差，传输速度较慢。具体的差别如下：

TCP协议面向连接，UDP协议面向非连接

TCP协议传输速度慢，UDP协议传输速度快

TCP协议保证数据顺序，UDP协议不保证

TCP协议保证数据正确性，UDP协议可能丢包

TCP协议对系统资源要求多，UDP协议要求少

不管是基于TCP还是基于UDP的网络通讯编程，都要区分服务器端和客户端，下面以TCP为例，实现客户端和服务器端通讯的实现步骤：

TCP服务器端的编写步骤：

1 首先，你需要创建一个用于通讯的套接口，一般使用socket调用来实现。这等于你有了一个用于通讯的电话：）

2 然后，你需要给你的套接口设定端口，相当于，你有了电话号码。这一步 一般通过设置网络套接口地址和调用bind函数来实现。

3 调用listen函数使你的套接口成为一个监听套接字。 以上三个步骤是TCP服务器的常用步骤。

4 调用accept函数来启动你的套接字，这时你的程序就可以等待客户端的连接了。

5 处理客户端的连接请求。

6 终止连接。

TCP编程的客户端一般步骤是：

1、创建一个socket，用函数socket()；

2、设置socket属性，用函数setsockopt(); 可选

3、绑定IP地址、端口等信息到socket上，用函数bind(); 可选

4、设置要连接的对方的IP地址和端口等属性；

5、连接服务器，用函数connect()（相当于拨号）；

6、收发数据，用函数send()和recv()，或者read()和write()（相当于通话）;

udp 和tcp 是 OSI 模型中的运输层中的协议。tcp 提供可靠的通信传输，而 udp 则常被用于让广播和细节控制交给应用的通信传输。两者的区别大致如下：

tcp 面向连接，udp 面向非连接即发送数据前不需要建立连接；

tcp 提供可靠的服务（数据传输），udp 无法保证；

tcp 面向字节流，udp 面向报文；

tcp 数据传输慢，udp 数据传输快；

tcp 为什么要三次握手，两次不行吗？为什么？ 我们假设A和B是通信的双方。我理解的握手实际上就是通信，发一次信息就是进行一次握手。

第一次握手：A给B打电话说，你可以听到我说话吗？

第二次握手：B收到了A的信息，然后对A说：我可以听得到你说话啊，你能听得到我说话吗？

第三次握手：A收到了B的信息，然后说可以的，我要给你发信息啦！

在三次握手之后，A和B都能确定这么一件事：我说的话，你能听到；你说的话，我也能听到。这样，就可以开始正常通信了。

注意：HTTP是基于TCP协议的，所以每次都是客户端发送请求，服务器应答，但是TCP还可以给其他应用层提供服务，即可能A、B在建立连接之后，谁都可能先开始通信。

如果采用两次握手，那么只要服务器发出确认数据包就会建立连接，但由于客户端此时并未响应服务器端的请求，那此时服务器端就会一直在等待客户端，这样服务器端就白白浪费了一定的资源。若采用三次握手，服务器端没有收到来自客户端的再次确认，则就会知道客户端并没有要求建立请求，就不会浪费服务器的资源。

这是通讯协议规定的。网络通讯中，IP地址+端口才能唯一标识一个真实的通讯地址。就像是现实中如果写信给一个人，发信人必须写清楚省市区和邮箱号，收件知人有同一个邮箱的钥匙才能收到信一样。

客户端不需要固定端口，客户端发送消息时应该由UdpClient自动选择可用的端口。

服务器不可能向NAT内部的客户端主动发起消息，必须等客户端发送消息，然后赶紧发送返回值。因为NAT路由器只会为Udp消息的这种回发规则维护一个较短时间，在这个较短时间上由外部发来的消息才能被路由器正确转发给内部。

扩展资料

UDP是OSI参考模型中一种无连接的传输层协议，它主要用于不要求分组顺序到达的传输中，分组传输顺序的检查与排序由应用层完成，提供面向事务的简单不可靠信息传送服务。UDP 协议基本上是IP协议与上层协议的接口。UDP协议适用端口分别运行在同一台设备上的多个应用程序。

UDP提供了无连接通信，且不对传送数据包进行可靠性保证，适合于一次传输少量数据，UDP传输的可靠性由应用层负责。常用的UDP端口号有：

应用协议 端口号

DNS 53

TFTP 69

SNMP 161

关键是recvfrom返回的客户端addrClient是不能作为服务器返回客户端的地址使用的，即在sendto中不能使用由recvfrom返回得到的客户端地址。 楼主将UDP通讯和TCP通讯搞混了，不过说实话这个是很正常的。当初我学的时候没一本书是把网络通信编程写清楚地，只能靠自己摸索。 socket可以理解为通信地址，它由协议,IP和端口组成。在UDP模式中，绑定的目的是要告诉操作系统，当网卡从外部接收到数据包时，操作系统就知道应该把这个数据包交给哪个应用程序。 具体是这样的，网卡总是知道自己的IP是什么，因此网卡接收到网线中的数据包时，会提取数据包的包头，里面含有的IP如果是网卡自己的IP，它就会把该数据包交给操作系统，如果不是就将该数据包丢弃，可以认为操作系统不知道有该数据包。操作系统接收到数据包后，会根据每个数据包包含的端口号，将该数据包发给不同的应用程序。操作系统怎么会知道哪个端口号对应哪个应用程序呢？这个就是要求应用程序使用bind函数，将自己的端口号告诉操作系统。因此，所谓的端口冲突就是指其他应用程序已经通过bind告诉了操作系统该端口被它使用了，因此另外的应用程序就不能使用该端口了，即bind肯定失败！ 所以，bind肯定是由接受数据包的应用程序使用的，这样的应用程序就是服务器应用程序，也可以看到我们需要为bind提供IP和端口号。并且，当初我还在疑惑为什么会有一个INADDR_ANY的IP指定，似乎bind根本不需要IP啊，只要端口就可以了。仔细一想才明白，因为一台主机可能会有2个网卡。因此，主机可能会有两个IP，这样bind这个函数允许我们自由指定需要绑定到哪块网卡上的特定端口。也可以不指定，通过INADDR_ANY由操作系统为我们指定。譬如，13端口在第一块网卡中被占用了，我们就可以使用bind明确指定自己的应用程序接收来自第二块网卡13端口的数据包。 UDP编程中作为客户端发送数据时，是不需要指定自己的IP和端口的，因此无需使用bind绑定，直接在sendto指定服务器的IP和端口就可以了。但实际上发送数据时，操作系统还是需要使用客户端机器上的一个IP和端口号的，这个IP和端口号由操作系统指派，譬如在操作系统处理sendto时，它可以指派1005端口给UDP客户端，此时如果有另一个客户程序再使用bind注册该端口，就会失败了。但实际情况大家都知道，UDP数据包的发送是相当快的，这种冲突几乎不存在，因为数据包发送后，即数据包通过网卡发到了网线中，操作系统就认为发送成功了，该端口就会被操作系统收回，标记“未使用”。 总结一下，UDP服务器需要占用一个IP和一个端口号，且是固定的，是在调用了bind函数成功后便确定下来了。UDP客户端也需要使用一个IP和一个端口号，它们都是随机的，这次发送可能是第一块网卡，第二次可能是第二块网卡，端口也如此。发送后，该端口就被操作系统收回，因此客户端无法使用该端口接收来自服务器的数据包。 因此不能使用recvfrom的客户端的端口信息再调用sendto发送给客户端，因为客户端的电脑操作系统根本不会讲该数据包交给客户端应用程序。 以上用比较容易理解的概念介绍了下，其实精确说的话，很多事情不是操作系统做的，而是各种驱动程序完成的。具体怎么修改代码，楼主应该明白了吧，光改服务器端的代码，没用，客户端的代码也要改。这也是为什么UDP是不存在服务器，客户端之说的原因，因为任何一方给另一方发数据包，前提必须使另一方已经通过bind绑定了一个固定端口了。