UDP网络编程的深入解析与实践

# UDP网络编程的深入解析与实践 ## 1. 网络请求重试策略 在网络通信中，请求可能会因为各种原因无法及时得到响应。比如，在等待服务器回复时，可能会出现超时的情况： ```plaintext Waiting up to 0.4 seconds for a reply Waiting up to 0.8 seconds for a reply Waiting up to 1.6 seconds for a reply Traceback (most recent call last): ... socket.timeout: timed out The preceding exception resulted in the following exception: Traceback (most recent call last): ... RuntimeError: I think the server is down ``` 对于不同类型的程序，重试策略有所不同： - **短暂任务程序**：如果程序执行的是一个短暂任务，需要向用户输出结果或返回响应，当多次尝试后仍无法得到结果，放弃重试是合理的。 - **守护程序**：对于像屏幕角落显示天气信息的守护程序，它需要全天运行并从远程UDP服务获取温度和预报。由于桌面或笔记本电脑可能长时间断开网络连接，代码可能需要等待数小时甚至数天才能收到预报服务器的响应，因此可以编写“永远”重试的代码。 在编写全天重试的守护程序代码时，不建议使用严格的指数退避策略。因为这种策略会迅速增加延迟时间，可能错过网络恢复的时机。建议选择一个最大延迟时间（如五分钟），在指数退避达到该时间后保持不变，确保用户在长时间断开网络后重新连接网络五分钟内，程序总会尝试更新。 ## 2. UDP套接字连接 ### 2.1 connect()方法的作用 UDP客户端可以使用`connect()`方法，与每次使用`sendto()`时都明确指定地址元组不同，`connect()`方法提前告知操作系统要发送数据包的远程地址，之后使用`send()`方法时只需提供数据，无需重复指定服务器地址。 ```mermaid graph LR A[客户端] -->|connect()| B(操作系统) B -->|记录远程地址| C(内存) A -->|send()| B B -->|根据记录地址发送| D[服务器] ``` ### 2.2 解决客户端混杂问题 `connect()`方法还解决了客户端混杂问题。使用`connect()`配置UDP套接字的首选目标后，操作系统会丢弃所有返回地址与连接地址不匹配的传入数据包。 ### 2.3 创建关注返回地址的UDP客户端的方法 有两种方法可以创建关注返回地址的UDP客户端： - **方法一**：使用`sendto()`将每个传出数据包路由到指定目的地，然后使用`recvfrom()`接收回复，并将每个返回地址与有未完成请求的服务器列表进行比较。 - **方法二**：创建套接字后立即使用`connect()`，然后使用`send()`和`recv()`进行交互。操作系统会过滤掉不需要的数据包。但这种方法一次只能与一个服务器通信，因为再次连接到同一套接字会完全删除原始地址。 ### 2.4 connect()方法的注意事项 - **不传输数据**：连接到UDP套接字不会在网络上传输任何数据，也不会通知服务器数据包即将到来，只是将地址存储在操作系统内存中，供后续`send()`和`recv()`调用使用。 - **不安全**：连接到服务器或使用返回地址过滤不需要的数据包并不是一种安全的方法。网络上的恶意用户可以轻松创建带有服务器返回地址的数据包，使伪造的响应通过地址过滤器，这种行为称为“欺骗”。 ## 3. 请求ID的使用 在创建自己的UDP请求和响应方案时，为每个请求分配一个序列号，并确保接受的回复具有相同的编号是一个很好的做法。这样做有以下两个显著优点： ### 3.1 防止重复响应导致的混淆 在指数退避循环中，客户端可能会多次重发查询请求，导致收到重复响应。例如，发送请求A后，因等待响应不耐烦而再次发送请求A，当收到响应A时，可能会误以为第一个请求丢失。如果两个请求都发送到服务器且响应延迟到达，后续发送请求B并开始监听时，可能会误将重复的响应A当作请求B的答案，从而导致混淆。使用请求ID可以避免这种情况，程序可以简单地删除ID不匹配的回复，直到收到匹配的回复。 ### 3.2 抵御欺骗攻击 当攻击者无法检查网络流量，只能盲目向服务器发送UDP数据包时，较大的请求ID号码可以降低客户端接受其响应的可能性。为了使攻击者难以猜测请求ID，建议使用`random`模块生成大整数作为请求ID。例如，ID号码是0到N之间的随机数，攻击者使用有效数据包到达客户端的可能性最大为1/N，如果还需要尝试系统上所有可能的端口号，可能性会更低。 需要注意的是，使用请求ID并不是真正的安全措施，它只能保护你免受无法查看网络流量的简单欺骗攻击。真正的安全措施可以抵御能够监控网络流量并随时插入自己消息的攻击者。 ## 4. 从绑定到接口 ### 4.1 服务器bind()方法的IP地址