《UNIX网络编程 卷1:套接字联网API(第3版)》——8.8 验证接收到的响应

简介: 我们的解决办法是修改图8-8中的recvfrom调用以返回数据报发送者的IP地址和端口号,保留来自数据报所发往服务器的应答,而忽略任何其他数据报。然而这样做照样存在一些缺陷,我们马上就会看到。

本节书摘来自异步社区《UNIX网络编程 卷1:套接字联网API(第3版)》一书中的第8章,第8.8节,作者:【美】W. Richard Stevens , Bill Fenner , Andrew M. Rudoff著,更多章节内容可以访问云栖社区“异步社区”公众号查看

8.8 验证接收到的响应

在8.6节结尾我们提到,知道客户临时端口号的任何进程都可往客户发送数据报,而且这些数据报会与正常的服务器应答混杂。我们的解决办法是修改图8-8中的recvfrom调用以返回数据报发送者的IP地址和端口号,保留来自数据报所发往服务器的应答,而忽略任何其他数据报。然而这样做照样存在一些缺陷,我们马上就会看到。

我们首先把客户程序的main函数(图8-7)改为使用标准回射服务器(图2-13)。这只需把以下赋值语句

servaddr.sin_port = htons(SERV_PORT);
替换为

servaddr.sin_port = htons(7);
这样,我们的客户就可以使用任何运行标准回射服务器的主机了。

我们接着重写dg_cli函数以分配另一个套接字地址结构用于存放由recvfrom返回的结构,如图8-9所示。
screenshot

分配另一个套接字地址结构
9 我们调用malloc来分配另一个套接字地址结构。注意dg_cli函数仍然是协议无关的,因为我们并不关心所处理套接字地址结构的类型,而只是在malloc调用中使用其大小。

比较返回的地址
12~18 在recvfrom的调用中,我们通知内核返回数据报发送者的地址。我们首先比较由recvfrom在值-结果参数中返回的长度,然后用memcmp比较套接字地址结构本身。

我们在3.2节说过,即使套接字地址结构包含一个长度字段,我们也不必设置或检查它。然而此处memcmp比较两个套接字地址结构中的每个数据字节,而内核返回套接字地址结构时,其中长度字段是设置的;因此对于本例,与之比较的另一个套接字地址结构也必须预先设置其长度字段。否则,memcmp将比较一个值为0的字节(因为没有设置长度字段)和一个值为16的字节(假设具体为sockaddr_in结构),结果自然不匹配。

如果服务器运行在一个只有单个IP地址的主机上,那么这个新版本的客户工作正常。然而如果服务器主机是多宿的,该客户就有可能失败。我们针对有两个接口和两个IP地址的主机freebsd4运行本客户程序。

macosx % host freebsd4
freebsd4.unpbook.com has address 172.24.37.94
freebsd4.unpbook.com has address 135.197.17.100
macosx % udpcli02 135.197.17.100
hello
reply from 172.24.37.94:7 (ignored)
goodbye
reply from 172.24.37.94:7 (ignored)

我们指定的服务器IP地址不与客户主机共享同一个子网。

这样指定服务器IP地址通常是允许的。①大多数IP实现接受目的地址为本主机任一IP地址的数据报,而不管数据报到达的接口(TCPv2第217~219页)。RFC 1122[Braden 1989]称之为弱端系统模型(weak end system model)。如果一个系统实现的是该RFC中所说的强端系统模型(strong end system model),那么它将只接受到达接口与目的地址一致的数据报。

recvfrom返回的IP地址(UDP数据报的源IP地址)不是我们所发送数据报的目的IP地址。当服务器发送应答时,目的IP地址是172.24.37.78。主机freebsd4内核中的路由功能为之选择172.24.37.94作为外出接口。既然服务器没有在其套接字上绑定一个实际的IP地址(服务器绑定在其套接字上的是通配IP地址,这一点可通过在freebsd4上运行netstat来验证),因此内核将为封装这些应答的IP数据报选择源地址。选为源地址的是外出接口的主IP地址(TCPv2第232~233页)。还有,既然它是外出接口的主IP地址,如果我们指定发送数据报到该接口的某个非主IP地址(即一个IP别名),那么也将导致图8-9版本客户程序的测试失败。

一个解决办法是:得到由recvfrom返回的IP地址后,客户通过在DNS(第11章)中查找服务器主机的名字来验证该主机的域名(而不是它的IP地址)。另一个解决办法是:UDP服务器给服务器主机上配置的每个IP地址创建一个套接字,用bind捆绑每个IP地址到各自的套接字,然后在所有这些套接字上使用select(等待其中任何一个变得可读),再从可读的套接字给出应答。既然用于给出应答的套接字上绑定的IP地址就是客户请求的目的IP地址(否则该数据报不会被投递到该套接字),这就保证应答的源地址与请求的目的地址相同。我们将在22.6节给出一个这样的例子。

在多宿Solaris系统上,服务器应答的源IP地址就是客户请求的目的IP地址。本节讲述的情形针对源自Berkeley的实现,这些实现基于外出接口选择源IP地址。

相关文章
|
2月前
|
机器学习/深度学习
神经网络与深度学习---验证集(测试集)准确率高于训练集准确率的原因
本文分析了神经网络中验证集(测试集)准确率高于训练集准确率的四个可能原因,包括数据集大小和分布不均、模型正则化过度、批处理后准确率计算时机不同,以及训练集预处理过度导致分布变化。
|
5月前
状态码对于理解HTTP请求和响应的流程,以及调试网络问题非常重要
【5月更文挑战第15天】HTTP状态码由三位数字表示,分为1xx-5xx五类。1xx为信息响应,2xx表示成功,如200(请求成功)、201(创建成功)。3xx是重定向,如301(永久移动)、302(临时重定向)。4xx表示客户端错误,如400(坏请求)、404(未找到)。5xx是服务器错误,包括500(内部服务器错误)和503(服务不可用)。这些状态码用于理解请求响应流程和调试网络问题。
59 1
|
16天前
|
JavaScript 前端开发 API
JavaScript 验证 API
JavaScript 验证 API
18 2
|
2月前
|
IDE 测试技术 API
使用京东API接口适用于的环境及验证调用合法性的方法
在电商领域,京东API接口支持商品信息查询、订单处理等功能。开发者需确保在稳定服务器端环境使用,选择合适编程语言及框架,并具备足够网络带宽处理能力。开发环境应配备IDE或代码编辑器及所需库。测试环境需充分验证API稳定性与可靠性。合法性验证包括:正确使用App Key和App Secret进行鉴权;掌握签名规则并在请求中添加签名;遵守请求频率限制;理解并遵循数据使用协议。遵循这些指导原则可保证API调用的合法性和稳定性。
|
2月前
|
JSON 算法 API
【Azure API 管理】APIM 配置Validate-JWT策略,验证RS256非对称(公钥/私钥)加密的Token
【Azure API 管理】APIM 配置Validate-JWT策略,验证RS256非对称(公钥/私钥)加密的Token
|
2月前
|
存储 安全 API
【Azure API 管理】在APIM中使用客户端证书验证API的请求,但是一直提示错误"No client certificate received."
【Azure API 管理】在APIM中使用客户端证书验证API的请求,但是一直提示错误"No client certificate received."
|
2月前
|
网络协议 Linux Shell
【Azure 应用服务】App Service For Linux 中安装paping, 用于验证从App Service向外请求的网络连通性
【Azure 应用服务】App Service For Linux 中安装paping, 用于验证从App Service向外请求的网络连通性
|
3月前
|
安全 API 网络安全
​邮箱OTP认证验证API发送邮件接口
**摘要 (Markdown格式):** OTP认证增强在线服务安全,尤其适用于邮箱验证。AOKSend提供邮箱OTP验证API,实现安全的邮件发送和用户身份验证。关键优势包括提高安全性、简化用户体验、实时发送、可扩展性和多层安全。配置涉及生成API密钥、设置SMTP、实现OTP逻辑、发送邮件及验证。AOKSend的分析工具帮助优化策略,适合各规模企业。
|
3月前
|
JSON 网络协议 数据格式
网络协议基础:HTTP请求与响应详解
【7月更文挑战第11天】HTTP协议作为Web通信的核心,其请求与响应机制是理解网络通信的关键。本文详细介绍了HTTP请求与响应的格式、过程以及常用的请求方法,帮助读者更好地理解HTTP协议的工作原理和应用场景。在实际应用中,HTTP协议的可定制性和灵活性使其能够适应多种
|
4月前
|
机器学习/深度学习 人工智能 自然语言处理
人工智能在网络安全中的威胁情报分析与响应的应用
人工智能在网络安全中的威胁情报分析与响应的应用
下一篇
无影云桌面