CN113709264A - 一种地址获取方法、设备、系统及存储介质 - Google Patents

Abstract

本申请实施例提供一种地址获取方法、设备、系统及存储介质。其中，所述系统包括：第一通信端、网关设备和第二通信端；第一通信端，用于在与第二通信端进行通信协议协商的过程中，将用于确认通信连接的第一确认包发送至网关设备，第一确认包中包含第一通信端的源地址；网关设备，用于将第一确认包转换为与第二通信端的通信协议版本适配的第二确认包；将第一通信端的源地址配置到第二确认包中；将第二确认包提供给第二通信端，以供第一通信端和第二通信端建立通信连接；第二通信端用于，从第二确认包中，获取第一通信端的源地址。据此，本实施例中，在第一通信端和第二通信端的通信协议版本不同的情况下，第二通信端也可获取到第一通信端的源地址。

Description

一种地址获取方法、设备、系统及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种地址获取方法、设备、系统及存储介质。

背景技术

随着通信技术的发展，IPv4地址资源越来越少，IPv6应运而生，这使得网络环境中同时存在两种IP地址的版本，即IPv4和IPv6。

目前，可采用NAT64(网络地址与协议转换)等技术，实现IPv4和IPv6之间的互访。但是，在负载均衡等场景下，在进行NAT64的同时，通信双方的IP地址也随之丢失，导致双方都无法获知对方的IP地址，给很多应用程序带来不便。

发明内容

本申请的多个方面提供一种地址获取方法、设备、系统及存储介质，用以获取对端的源地址，而不受通信双方所使用的通信协议版本的限制。

本申请实施例提供一种地址获取系统，包括：第一通信端、网关设备和第二通信端，所述网关设备分别与所述第一通信端和所述第二通信端通信连接；

所述第一通信端，用于在与所述第二通信端进行通信协议协商的过程中，将用于确认通信连接的第一确认包发送至所述网关设备，所述第一确认包中包含所述第一通信端的源地址；

所述网关设备，用于在接收到所述第一确认包的情况下，将所述第一确认包转换为与所述第二通信端的通信协议版本适配的第二确认包；将所述第一通信端的源地址配置到所述第二确认包中；将所述第二确认包提供给所述第二通信端，以供所述第一通信端和所述第二通信端建立通信连接；

所述第二通信端用于，从所述第二确认包中，获取所述第一通信端的源地址。

本申请实施例还提供一种地址获取方法，适用于网关设备，包括：

在第一通信端与第二通信端进行通信协议协商的过程中，接收所述第一通信端发送的用于确认通信连接的第一确认包，所述第一确认包中包含所述第一通信端的源地址；

将所述第一确认包转换为与所述第二通信端的通信协议版本适配的第二确认包；

将所述第二通信端的源地址配置到所述第二确认包中；

将所述第二确认包提供给所述第二通信端，以供所述第二通信端从所述第二确认包中，获取所述第一通信端的源地址。

本申请实施例还提供一种地址获取方法，适用于第二通信端，包括：

在与第一通信端进行通信协议协商的过程中，接收网关设备发送的第二确认包，其中，所述第二确认包为所述网关设备基于所述第二通信端的通信协议版本对所述第一通信端提供的用于确认通信连接的第一确认包进行转换而生成的，且所述第二确认包中包含所述第一通信端的源地址；

从所述第二确认包中，获取所述第一通信端的源地址。

本申请实施例还提供一种网关设备，包括存储器、处理器和通信组件；

所述存储器用于存储一条或多条计算机指令；

所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：

在第一通信端与第二通信端进行通信协议协商的过程中，通过所述通信组件接收所述第一通信端发送的用于确认通信连接的第一确认包，所述第一确认包中包含所述第一通信端的源地址；

将所述第一确认包转换为与所述第二通信端的通信协议版本适配的第二确认包；

将所述第二通信端的源地址配置到所述第二确认包中；

通过所述通信组件将所述第二确认包提供给所述第二通信端，以供所述第二通信端从所述第二确认包中，获取所述第一通信端的源地址。

本申请实施例还提供一种计算设备，包括存储器、处理器和通信组件；

所述存储器用于存储一条或多条计算机指令；

所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：

在与第一通信端进行通信协议协商的过程中，通过所述通信组件接收网关设备发送的第二确认包，其中，所述第二确认包为所述网关设备基于所述第二通信端的通信协议版本对所述第一通信端提供的用于确认通信连接的第一确认包进行转换而生成的，且所述第二确认包中包含所述第一通信端的源地址；

从所述第二确认包中，获取所述第一通信端的源地址。

本申请实施例还提供一种存储计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行前述的地址获取方法。

在本申请实施例中，在第一通信端和第二通信端之间进行通信协议协商的过程中，可通过网关设备将第一通信端提供的用于确认通信连接的第一确认包转换为与第二通信端的通信协议版本适配的第二确认包，并将第一通信端的源地址配置到第二确认包中，之后，可将第二确认包提供给第二通信端；基于此，第二通信端可从收到的第二确认包中获取第一通信端的源地址。据此，本实施例中，可在网络的传输层中携带第一通信端的源地址，这使得，在第一通信端和第二通信端的通信协议版本不同的情况下，第二通信端也可获取到第一通信端的源地址。另外，网络中的其它层对此无感知，因此，这保证了第一通信端的源地址的传递不会影响到网络中各种设备的性能，而且，对各种网络架构具有通用性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示例性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请一示例性实施例提供的一种地址获取系统的结构示意图；

图2为本申请一示例性实施例提供的一种地址获取方案的逻辑示意图；

图3a为本申请一示例性实施例提供的一种通信协议头的结构示意图；

图3b为本申请一示例性实施例提供的一种选项字段的结构示意图；

图4为本申请一示例性实施例提供的一种应用场景的示意图；

图5为本申请另一示例性实施例提供的一种地址获取方法的流程示意图；

图6为本申请又一示例性实施例提供的另一种地址获取方法的流程示意图；

图7为本申请又一实施例提供的一种网关设备的结构示意图；

图8为本申请又一实施例提供的一种计算设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

目前，在通信双方的通信协议版本不同的情况下，无法获取对端的源地址，带来诸多不便。为改善这些技术问题，本申请的一些实施例中：在第一通信端和第二通信端之间进行通信协议协商的过程中，可通过网关设备将第一通信端提供的用于确认通信连接的第一确认包转换为与第二通信端的通信协议版本适配的第二确认包，并将第一通信端的源地址配置到第二确认包中，之后，可将第二确认包提供给第二通信端；基于此，第二通信端可从收到的第二确认包中获取第一通信端的源地址。据此，本实施例中，可在网络的传输层中携带第一通信端的源地址，这使得，在第一通信端和第二通信端的通信协议版本不同的情况下，第二通信端也可获取到第一通信端的源地址。另外，网络中的其它层对此无感知，因此，这保证了第一通信端的源地址的传递不会影响到网络中各种设备的性能，而且，对各种网络架构具有通用性。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1为本申请一示例性实施例提供的一种地址获取系统的结构示意图。图2为本申请一示例性实施例提供的一种地址获取方案的逻辑示意图。参考图1，地址获取系统可包括：第一通信端10、网关设备20和第二通信端30，网关设备20分别与第一通信端10和第二通信端30通信。

本实施例提供的地址获取系统可应用于各种需要获取对端的源地址的场景，例如，负载均衡场景、高防云服务器、访问控制等需要获取源地址的场景中。本实施例对应用场景不做限定。另外，本实施例对网关设备20到第二通信端30所采用的网络结构不作限定，网关设备20到第二通信端30可采用VPC(虚拟私有云)网络或者经典网络等。

值得说明的是，本实施例是从单次通信过程的维度描述了地址获取系统，但应当理解的是，在实际应用中，地址获取系统中可以包括多个第一通信端10、多个网关设备20以及多个第二通信端30。

目前，网络环境中存在多种通信协议版本，例如，IPv4(Internet Protocolversion 4，通信协议版本4)、IPv6(Internet Protocol version 4，通信协议版本6)。采用不同通信协议版本的通信双方之间，需要通过网关设备20进行NAT64(网络地址与协议转换)等处理，才能实现互访。

但是，网关设备20在进行NAT64等处理的同时，通信双方的源地址也将丢失，这导致通信双方无法获取到对端的源地址。

为此，本实施例中，将对网关设备20进行改进。

参考图2，在第一通信端10与第二通信端30进行通信协议协商的过程中，第一通信端10可向网关设备20发送用于确认通信连接的第一确认包。

本实施例中，通信协议可包括TCP协议等，可在通信协议协商过程中将第一通信端10的源地址传递给第二通信端30。

图2中，示出了第一通信端10与第二通信端30之间进行通信协议协商的过程。其中，通信协议采用了TCP协议，网关设备20在两者之间进行网络地址与协议转换等处理。

实际应用中，参考图2，TCP握手过程中发生三次握手。第一次握手：第一通信端10可首先向网关设备20发送第一SYN同步序列编号，网关设备20可将收到的第一SYN转换为与第二通信端30的通信协议版本适配的第二SYN，并发送给第二通信端30。第二次握手：第二通信端30在确认能够与第一通信端10进行通信连接的情况下，可向网关设备20返回ACK(即SYN确认包)和自身的SYN，同样，网络设备可将第二通信端30提供的这些数据转换为与第一通信端10的通信协议版本适配的ACK和SYN，并提供给第一通信端10。

本实施例中，对以上两次握手的过程不作具体限定。经过前两次握手，第一通信端10可在同意与第二通信端30建立通信连接的情况下，发起第三次握手。

参考图2，本实施例中，第一通信端10可向网关设备20发送用于确认通信连接的第一确认包，第一确认包中包含第一通信端10的源地址。

其中，第一确认包与第一通信端10采用的通信协议版本适配。

网关设备20在接收到第一通信端10发送的第一确认包的情况下，可将第一确认包转换为与第二通信端30的通信协议版本适配的第二确认包；并将第一通信端10的源地址配置到第二确认包中。

对网关设备20来说，在接收到第一确认包时，可获取到第一通信端10的源地址。

网关设备20在将第一确认包转换为第二确认包时，不会将第一通信端10的源地址丢弃，而是将第一通信端10的源地址配置到第二确认包中，并发送给第二通信端30。

这样，对于第二通信端30来说，在接收到网关设备20发送的第二确认包的情况下，建立与第一通信端10之间的通信连接。还可从第二确认包中获取第一通信端10的地址。

其中，本实施例中，在负载均衡场景中，网关设备20可以是负载均衡设备，当然，在其它场景中，网关设备20还可以是其它类型的设备，本实施例对此不作限定。

另外，实际应用中，由于升级复杂度等原因，第二通信端30可能还处于更低的通信协议版本，例如，IPv4。而第一通信端10的设备种类繁多，更新换代较快，第一通信端10采用的通信协议版本通常较高，例如，IPv6。在这种情况下，基于本实施例提供的地址获取方案，第二通信端30可获取第一通信端10的源地址(IPv6)。

据此，本实施例中，在第一通信端10和第二通信端30之间进行通信协议协商的过程中，可通过网关设备20将第一通信端10提供的用于确认通信连接的第一确认包转换为与第二通信端30的通信协议版本适配的第二确认包，并将第一通信端10的源地址配置到第二确认包中，之后，可将第二确认包提供给第二通信端30；基于此，第二通信端30可从收到的第二确认包中获取第一通信端10的源地址。据此，本实施例中，可在网络的传输层中携带第一通信端10的源地址，这使得，在第一通信端10和第二通信端30的通信协议版本不同的情况下，第二通信端30也可获取到第一通信端10的源地址。另外，网络中的其它层对此无感知，因此，这保证了第一通信端10的源地址的传递不会影响到网络中各种设备的性能，而且，对各种网络架构具有通用性。

在上述或下述实施例中，网关设备20可将第一通信端10的源地址配置到第二确认包的通信协议头中。

第二确认包为通信协议数据包，通信协议数据包中至少可包括通信协议头。

网关设备20可将第一通信端10的源地址，写入第二确认包的通信协议头中。这样，可在传输层中，将第一通信端10的源地址携带在通信协议头中，这使得，在网络的其它层中，对第一通信端10的源地址的传递过程是无感知的，第一通信端10的源地址的传递，并不会影响网络性能。

对第二通信端30来说，在接收到网关设备20发送的第二确认包的情况下，可从第二确认包的通信协议头中解析出第一通信端10的源地址。

本实施例中，可在第二通信端30中安装一内核模块，该内核模块可通过预置的第一钩子函数挂载第二通信端30中用于处理通信协议协商过程的接口。第二通信端30可通过对第一钩子函数进行初始化，将第一钩子函数挂载至用于处理通信协议协商过程的接口。

这样，一方面，第二通信端30可利用第一钩子函数监听用于处理通信协议协商过程的接口，从而确定是否收到第二确认包。另一方面，第二通信端30可利用第一钩子函数从第二确认包的通信协议头中解析出第一通信端10的源地址。

图3a为本申请一示例性实施例提供的一种通信协议头的结构示意图。参考图3a，通信协议头中包含多种选项(Option)字段，网关设备20可从第二确认包的通信协议头中，选择指定选项字段，并将第一通信端10的源地址配置到指定选项字段中。

图3b为本申请一示例性实施例提供的一种选项字段的结构示意图。参考图3b，在选项字段中，kind表示选择的类型，length表示选项的长度，info表示选项的具体内容。

实际应用中，可从通信协议头中包含的多个选择字段中，选择处于空闲状态的选项字段作为指定选项字段。例如，根据RFC 4727 7.3章定义，至少可将kind为253或254的选项字段作为指定选项字段。当然，本实施例并不限于此。

图3a中示出的是TCP头，TCP头支持选项字段可扩展，也即是，TCP头中存在可用于支持本实施例中地址获取方案的空闲选项字段。

基于此，本实施例中，可采用当前或未来可支持选项字段扩展的通信协议头，来实施本实施例的发明构思。相应地，可按照该需求选择本实施例中的通信协议。

另外，网关设备20可与第二通信端30预先约定指定选项字段。例如，可通过预置通信协议的方式，在双方之间约定指定选项字段。

基于此，网关设备20可将第一通信端10的源地址写入指定选项字段中。具体的，可写入选择字段中的info部分。

其中，指定选项字段可采用TLV结构，TLV结构为BER编码的一种，采用ASN1标准，全称为Tag(标签)，Length(长度)，Value(值)。

本实施例中，网关设备20可自定义指定选项字段的length和value。据此，可将第一通信端10的源地址配置到value中。

考虑到选项字段承载的字节可达40个，网关设备20还可将自身的地址信息、第一通信端10的源端口信息、目的端口信息或VPC编号等也配置到指定选项字段中。

实际应用中，指定选项字段中，kind和length各占一个字节，因此，可有38个字节用来携带包括第一通信端10的源地址在内的各种信息。

对此，本实施例中，在保留出用于承载第一通信端10的源地址的字节数量的情况下，可根据其它信息所需占用的字节数量，确定配置到指定选项字段中的其它信息。

例如，第一通信端10的源地址需占用16字节，网关设备20自身的地址信息需占用16字节，第一通信端10的源端口信息和目的端口信息分别需要占用2个字节，而VPC编号则至少需要占用3个字节。这种情况下，指定选项字段将无法容纳所有的信息。可根据第二通信端30的需求，割舍掉除第一通信端10的源地址之外的其它信息。

至此，第二确认包中将携带第一通信端10的源地址。

对第二通信端30来说，在接收到第二确认包的情况下，可按照与网关设备20之间阅读的指定选项字段，查找第二确认包的通信协议头中的指定选项字段；并从指定选项字段中解析出第一通信端10的源地址。

实际应用中，第二通信端30可利用前述的第一钩子函数查找第二确认包的通信协议头中的指定选项字段；并从指定选项字段中解析出第一通信端10的源地址。

本实施例中，对网关设备20来说，还可采用其它实现方式将第一通信端10的源地址配置到第二确认包中，例如，将第一通信端10的源地址写入第二确认包中对网络性能无影响且可无丢失地传递到第二通信端30的其它字段。本实施例对此不作限定。相应地，第二通信端30与网关设备20之间可预先约定第一通信端10的源地址的携带位置，以保证第二通信端30可顺利获取到第一通信端10的源地址。

据此，本实施例中，网关设备20可将第一通信端10的源地址配置到第二确认包的通信协议头中，在网关设备20将第二确认包发送至第二通信端30的过程中，第一通信端10的源地址不会对网络性能造成影响，也不会丢失，这可保证第一通信端10的源地址可成功传递至第二通信端30。

在上述或下述实施例中，第二通信端30还可接收地址调用请求；若地址调用请求请求获取针对第一通信端10和第二通信端30之间的通信连接过程对应的源地址，则输出第一通信端10的源地址，以响应地址调用请求。

本实施例中，第二通信端30在从第二确认包中获取到第一通信端10的源地址后，可将第一通信端10的源地址存储至本地。

实际应用中，存储操作可利用前述的第一钩子函数执行。

对于不同的操作系统，第一通信端10的源地址在第二通信端30本地的存储形式可不完全相同，本实施例对此不作限定。例如，在linux系统中，采用的存储形式可以是sock结构。

本实施例中，第二通信端30中内核模块还可通过第二钩子函数挂载源地址调用接口。第二通信端30可通过对第二钩子函数进行初始化，将第二钩子函数挂载至源地址调用接口。

对于不同的操作系统，源地址调用接口可能不同，例如，在linux系统中，源地址调用接口包括但不限于get_peername API等等。

这样，一方面，第二通信端30可利用第而钩子函数监听源地址调用接口，从而确定是否收到地址调用请求。另一方面，若监听到请求获取针对第一通信端10和第二通信端30之间的通信协议协商过程对应的源地址的地址调用请求，则利用第二钩子函数，将源地址调用接口获取到的网关设备20的地址替换为第一通信端10的源地址，以供源地址调用接口响应地址调用请求。

实际应用中，若第二通信端30接收到请求获取针对第一通信端10和第二通信端30之间的通信协议协商过程对应的源地址的地址调用请求，则第二通信端30的内核可激活源地址调用接口获取第二确认包的源地址，通常为网关设备20的地址。本实施例中，第二通信端30可利用第二钩子函数将源地址调用接口获取到的网关设备20的地址替换为第一通信端10的源地址。例如，第二通信端30可利用第二钩子函数从前述的SOCK结构中提取第一通信端10的源地址并替换源地址调用接口的响应结果中的网关设备20的地址。

其中，地址调用请求可来自各种需要调用通信协议协商过程对应的源地址的应用程序。例如，实施鉴权功能的应用程序、实施统计功能的应用程序等，本实施例并不限于此。

据此，本实施例中，第二通信端30可从网关设备20发送的第二确认包中解析出第一通信端10的源地址，在此基础上，在接收到地址调用请求的情况下，第二通信端30可基于通信协议协商对应的真实的源地址响应地址调用请求，这为各种需要调用通信协议协商对应的源地址的应用程序提供了更加准确的基础。

图4为本申请一示例性实施例提供的一种应用场景的示意图。以下将以负载均衡场景为例，对本实施提供的地址获取方案进行说明。

参考图4，第一通信端为用户终端(IPv6 Client)，采用IPv6，第二通信端为负载均衡场景中的后端服务器(IPv4 RS)，采用IPv4。网关设备为负载均衡设备(LVS)。

图4中示出了IPv6 Client和IPv4 RS之间的通信协议协商过程。

参考图4，第一次握手：IPv6 Client可向LVS发送SYN(IPv6)，LVS将SYN(IPv6)转换为SYN(IPv4,)，并发送给IPv4 RS；

第二次握手：IPv4 RS向LVS返回SYN-ACK(IPv4)，以对IPv6 Client的SYN进行确认并提供自身的SYN，LVS将SYN-ACK(IPv4)转换为SYN-ACK(IPv6)，并提供给IPv6 Client；

第三次握手：IPv6 Client向LVS发送ACK(IPv6)，作为本实施例中的第一确认包，以确认通信连接，其中，ACK(IPv6)中包含IPv6 Client的源地址；LVS将ACK(IPv6)转换为ACK(IPv4)，并将IPv6 Client的源地址配置到ACK(IPv4)，以获得ACK(IPv4 with IPv6 TOAoption)，并将ACK(IPv4 with IPv6TOA option)提供给IPv4 RS。

其中，在第三次握手过程中，LVS可将IPv6 Client的源地址写入ACK(IPv4)的通信协议头中的指定选项字段中，以获得ACK(IPv4 with IPv6 TOA option)。

IPv4 RS可从ACK(IPv4 with IPv6 TOA option)中解析出IPv6 Client的源地址，以实现地址获取。

另外，IPv4 RS还可接收各种应用程序发起的针对图4所示通信协议协商对应的源地址的调用指令，并以IPv6 Client的源地址作为响应。

图5为本申请另一示例性实施例提供的一种地址获取方法的流程示意图。本实施例提供的地址获取方法可以由一地址获取装置来执行，该地址获取装置可以实现为软件或实现为软件和硬件的组合，该地址获取装置可集成设置在网关设备中。如图5所示，该地址获取方法包括：

步骤500、在第一通信端与第二通信端进行通信协议协商的过程中，接收第一通信端发送的用于确认通信连接的第一确认包，第一确认包中包含第一通信端的源地址；

步骤501、将第一确认包转换为与第二通信端的通信协议版本适配的第二确认包；

步骤502、将第二通信端的源地址配置到第二确认包中；

步骤503、将第二确认包提供给第二通信端，以供第二通信端从第二确认包中，获取第一通信端的源地址。

在一可选实施例中，步骤将第一通信端的源地址配置到第二确认包中，包括：

将第一通信端的源地址配置到第二确认包的通信协议头中。

在一可选实施例中，步骤将第一通信端的源地址配置到第二确认包的通信协议头中，包括：

从通信协议头包含的多个选项字段中，选择指定选项字段；

将第一通信端的源地址配置到指定选项字段中。

在一可选实施例中，指定选项字段为通信协议头中处于空闲状态的选项字段。

在一可选实施例中，该方法还包括：

将自身的地址信息、第一通信端的源端口信息、目的端口信息中的一种或多种配置到指定选项字段中。

在一可选实施例中，指定选项字段采用TLV结构。

在一可选实施例中，第一通信端采用的通信协议版本为IPv6，第二通信端采用的通信协议版本为IPv4。

在一可选实施例中，网关设备包括负载均衡设备。

值得说明的是，上述关于地址获取方法的各实施例中的技术细节，可参考前述的地址获取系统相关实施例中针对网关设备的描述，为节省篇幅，在此不再赘述，但这不应造成对本申请保护范围的损失。

图6为本申请又一示例性实施例提供的另一种地址获取方法的流程示意图。本实施例提供的地址获取方法可以由一地址获取装置来执行，该地址获取装置可以实现为软件或实现为软件和硬件的组合，该地址获取装置可集成设置在通信端中。如图6所示，该地址获取方法包括：

步骤601、在与第一通信端进行通信协议协商的过程中，接收网关设备发送的第二确认包，其中，第二确认包为网关设备基于第二通信端的通信协议版本对第一通信端提供的用于确认通信连接的第一确认包进行转换而生成的，且第二确认包中包含第一通信端的源地址；

步骤602、从第二确认包中，获取第一通信端的源地址。

在一可选实施例中，第一通信端的源地址配置在第二确认包的通信协议头中，步骤从第二确认包中，获取第一通信端的源地址，包括：

从第二确认包的通信协议头中，获取第一通信端的源地址。

在一可选实施例中，第一通信端的源地址配置在通信协议头中的指定选项字段中，步骤从第二确认包的通信协议头中，获取第一通信端的源地址，包括：

查找第二确认包的通信协议头中的指定选项字段；

从指定选项字段中解析出第一通信端的源地址。

在一可选实施例中，该方法包括：

利用预置的第一钩子函数，查找第二确认包的通信协议头中的指定选项字段；并从指定选项字段中解析出第一通信端的源地址；

其中，第一钩子函数挂载用于处理通信协议协商过程的接口。

在一可选实施例中，该方法还包括：

接收地址调用请求；

若地址调用请求请求获取针对第一通信端和第二通信端之间的通信协议协商过程对应的源地址，则输出第一通信端的源地址，以响应地址调用请求。

在一可选实施例中，步骤若地址调用请求请求获取针对第一通信端和第二通信端之间的通信协议协商过程对应的源地址，则输出第一通信端的源地址，以响应地址调用请求，包括：

利用预置的第二钩子函数，监听源地址调用接口；

若监听到请求获取针对第一通信端和第二通信端之间的通信协议协商过程对应的源地址的地址调用请求，则利用第二钩子函数，将源地址调用接口获取到的网关设备的地址替换为第一通信端的源地址，以供源地址调用接口响应地址调用请求；

其中，第二钩子函数挂载源地址调用接口。

在一可选实施例中，第二通信端的通信协议版本采用IPv4。

在一可选实施例中，通信协议包括TCP协议。

值得说明的是，上述关于地址获取方法的各实施例中的技术细节，可参考前述的地址获取系统相关实施例中针对第二通信端的描述，为节省篇幅，在此不再赘述，但这不应造成对本申请保护范围的损失。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如500、501等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的通信端、数据包、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图7为本申请又一示例性实施例提供的一种网关设备的结构示意图。如图7所示，该网关设备包括存储器70、处理器71和通信组件72；

存储器70用于存储一条或多条计算机指令；

处理器71与存储器70和通信组件72耦合，用于执行一条或多条计算机指令，以用于：

在第一通信端与第二通信端进行通信协议协商的过程中，通过通信组件72接收第一通信端发送的用于确认通信连接的第一确认包，第一确认包中包含第一通信端的源地址；

将第一确认包转换为与第二通信端的通信协议版本适配的第二确认包；

将第二通信端的源地址配置到第二确认包中；

通过通信组件72将第二确认包提供给第二通信端，以供第二通信端从第二确认包中，获取第一通信端的源地址。

在一可选实施例中，处理器71在将第一通信端的源地址配置到第二确认包中时，用于：

将第一通信端的源地址配置到第二确认包的通信协议头中。

在一可选实施例中，处理器71在将第一通信端的源地址配置到第二确认包的通信协议头中时，用于：

从通信协议头包含的多个选项字段中，选择指定选项字段；

将第一通信端的源地址配置到指定选项字段中。

在一可选实施例中，指定选项字段为通信协议头中处于空闲状态的选项字段。

在一可选实施例中，处理器71还用于：

将自身的地址信息、第一通信端的源端口信息、目的端口信息中的一种或多种配置到指定选项字段中。

在一可选实施例中，指定选项字段采用TLV结构。

在一可选实施例中，第一通信端采用的通信协议版本为IPv6，第二通信端采用的通信协议版本为IPv4。

在一可选实施例中，网关设备包括负载均衡设备。

在一可选实施例中，通信协议包括TCP协议。

值得说明的是，上述关于网关设备的各实施例中的技术细节，可参考前述的地址获取系统相关实施例中针对网关设备的描述，为节省篇幅，在此不再赘述，但这不应造成对本申请保护范围的损失。

进一步，如图7所示，该网关设备还包括：电源组件73等其它组件。图7中仅示意性给出部分组件，并不意味着网关设备只包括图7所示组件。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中可由网关设备执行的各步骤。

图8为本申请又一示例性实施例提供的一种计算设备的结构示意图。如图8所示，该计算设备包括存储器80、处理器81和通信组件82；

存储器80用于存储一条或多条计算机指令；

处理器81与存储器80和通信组件82耦合，用于执行一条或多条计算机指令，以用于：

在与第一通信端进行通信协议协商的过程中，通过通信组件82接收网关设备发送的第二确认包，其中，第二确认包为网关设备基于第二通信端的通信协议版本对第一通信端提供的用于确认通信连接的第一确认包进行转换而生成的，且第二确认包中包含第一通信端的源地址；

从第二确认包中，获取第一通信端的源地址。

在一可选实施例中，第一通信端的源地址配置在第二确认包的通信协议头中，处理器81在从第二确认包中，获取第一通信端的源地址时，用于：

从第二确认包的通信协议头中，获取第一通信端的源地址。

在一可选实施例中，第一通信端的源地址配置在通信协议头中的指定选项字段中，处理器81在从第二确认包的通信协议头中，获取第一通信端的源地址时，用于：

查找第二确认包的通信协议头中的指定选项字段；

从指定选项字段中解析出第一通信端的源地址。

在一可选实施例中，处理器81用于：

利用预置的第一钩子函数，查找第二确认包的通信协议头中的指定选项字段；并从指定选项字段中解析出第一通信端的源地址；

其中，第一钩子函数挂载用于处理通信协议协商过程的接口。

在一可选实施例中，处理器81还用于：

接收地址调用请求；

若地址调用请求请求获取针对第一通信端和第二通信端之间的通信协议协商过程对应的源地址，则输出第一通信端的源地址，以响应地址调用请求。

在一可选实施例中，若地址调用请求请求获取针对第一通信端和第二通信端之间的通信协议协商过程对应的源地址，处理器81在输出第一通信端的源地址，以响应地址调用请求时，用于：

利用预置的第二钩子函数，监听源地址调用接口；

若监听到请求获取针对第一通信端和第二通信端之间的通信协议协商过程对应的源地址的地址调用请求，则利用第二钩子函数，将源地址调用接口获取到的网关设备的地址替换为第一通信端的源地址，以供源地址调用接口响应地址调用请求；

其中，第二钩子函数挂载源地址调用接口。

在一可选实施例中，第二通信端的通信协议版本采用IPv4。

在一可选实施例中，通信协议包括TCP协议。

值得说明的是，上述关于计算设备的各实施例中的技术细节，可参考前述的地址获取系统相关实施例中针对第二通信端的描述，为节省篇幅，在此不再赘述，但这不应造成对本申请保护范围的损失。

进一步，如图8所示，该计算设备还包括：电源组件83等其它组件。图8中仅示意性给出部分组件，并不意味着计算设备只包括图8所示组件。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中可由计算设备执行的各步骤。

其中，图7和8中的存储器，用于存储计算机程序，并可被配置为存储其它各种数据以支持在计算平台上的操作。这些数据的示例包括用于在计算平台上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

其中，图7和8中的通信组件被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如WiFi，2G、3G、4G/LTE、5G等移动通信网络，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

其中，图7和8中的电源组件，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (34)

1.一种地址获取系统，其特征在于，包括：第一通信端、网关设备和第二通信端，所述网关设备分别与所述第一通信端和所述第二通信端通信连接；

所述第一通信端，用于在与所述第二通信端进行通信协议协商的过程中，将用于确认通信连接的第一确认包发送至所述网关设备，所述第一确认包中包含所述第一通信端的源地址；

所述网关设备，用于在接收到所述第一确认包的情况下，将所述第一确认包转换为与所述第二通信端的通信协议版本适配的第二确认包；将所述第一通信端的源地址配置到所述第二确认包中；将所述第二确认包提供给所述第二通信端，以供所述第一通信端和所述第二通信端建立通信连接；

所述第二通信端用于，从所述第二确认包中，获取所述第一通信端的源地址。

2.根据权利要求1所述的系统，其特征在于，所述网关设备在将所述第一通信端的源地址配置到所述第二确认包中时，用于：

将所述第一通信端的源地址配置到所述第二确认包的通信协议头中。

3.根据权利要求2所述的系统，其特征在于，所述第二通信端在从所述第二确认包中，获取所述第一通信端的源地址时，用于：

从所述第二确认包的通信协议头中，获取所述第一通信端的源地址。

4.根据权利要求2所述的系统，其特征在于，所述网关设备在将所述第一通信端的源地址配置到所述第二确认包的通信协议头中时，用于：

从所述通信协议头包含的多个选项字段中，选择指定选项字段；

将所述第一通信端的源地址配置到所述指定选项字段中。

5.根据权利要求4所述的系统，其特征在于，所述指定选项字段为所述通信协议头中处于空闲状态的选项字段。

6.根据权利要求4所述的系统，其特征在于，所述网关设备还用于：将自身的地址信息、所述第一通信端的源端口信息、目的端口信息中的一种或多种配置到所述指定选项字段中。

7.根据权利要求4所述的系统，其特征在于，所述指定选项字段采用TLV结构。

8.根据权利要求4所述的系统，其特征在于，所述第二通信端在从所述第二确认包中，获取所述第一通信端的源地址时，用于：

查找所述第二确认包的通信协议头中的指定选项字段；

从所述指定选项字段中解析出所述第一通信端的源地址。

9.根据权利要求8所述的系统，其特征在于，所述第二通信端用于：

利用预置的第一钩子函数查找所述第二确认包的通信协议头中的指定选项字段；并从所述指定选项字段中解析出所述第一通信端的源地址；

其中，所述第一钩子函数挂载用于处理通信协议协商过程的接口。

10.根据权利要求1所述的系统，其特征在于，所述第二通信端还用于：

接收地址调用请求；

若所述地址调用请求请求获取针对所述第一通信端和所述第二通信端之间的通信连接过程对应的源地址，则输出所述第一通信端的源地址，以响应所述地址调用请求。

11.根据权利要求10所述的系统，其特征在于，所述第二通信端用于：

利用预置的第二钩子函数，监听源地址调用接口；

若监听到请求获取针对所述第一通信端和所述第二通信端之间的通信协议协商过程对应的源地址的地址调用请求，则利用所述第二钩子函数，将所述源地址调用接口获取到的网关设备的地址替换为所述第一通信端的源地址，以供所述源地址调用接口响应所述地址调用请求；

其中，所述第二钩子函数挂载所述源地址调用接口。

12.根据权利要求1所述的系统，其特征在于，所述第一通信端采用的通信协议版本为IPv6，所述第二通信端采用的通信协议版本为IPv4。

13.根据权利要求1所述的系统，其特征在于，所述网关设备包括负载均衡设备。

14.根据权利要求1所述的系统，其特征在于，所述通信协议包括TCP协议。

15.一种地址获取方法，适用于网关设备，其特征在于，包括：

在第一通信端与第二通信端进行通信协议协商的过程中，接收所述第一通信端发送的用于确认通信连接的第一确认包，所述第一确认包中包含所述第一通信端的源地址；

将所述第一确认包转换为与所述第二通信端的通信协议版本适配的第二确认包；

将所述第二通信端的源地址配置到所述第二确认包中；

将所述第二确认包提供给所述第二通信端，以供所述第二通信端从所述第二确认包中，获取所述第一通信端的源地址。

16.根据权利要求15所述的方法，其特征在于，所述将所述第一通信端的源地址配置到所述第二确认包中，包括：

将所述第一通信端的源地址配置到所述第二确认包的通信协议头中。

17.根据权利要求16所述的方法，其特征在于，所述将所述第一通信端的源地址配置到所述第二确认包的通信协议头中，包括：

从所述通信协议头包含的多个选项字段中，选择指定选项字段；

将所述第一通信端的源地址配置到所述指定选项字段中。

18.根据权利要求17所述的方法，其特征在于，所述指定选项字段为所述通信协议头中处于空闲状态的选项字段。

19.根据权利要求17所述的方法，其特征在于，还包括：

将自身的地址信息、所述第一通信端的源端口信息、目的端口信息中的一种或多种配置到所述指定选项字段中。

20.根据权利要求17所述的方法，其特征在于，所述指定选项字段采用TLV结构。

21.根据权利要求15所述的方法，其特征在于，所述第一通信端采用的通信协议版本为IPv6，所述第二通信端采用的通信协议版本为IPv4。

22.根据权利要求15所述的方法，其特征在于，所述网关设备包括负载均衡设备。

23.根据权利要求15所述的方法，其特征在于，所述通信协议包括TCP协议。

24.一种地址获取方法，适用于第二通信端，其特征在于，包括：

在与第一通信端进行通信协议协商的过程中，接收网关设备发送的第二确认包，其中，所述第二确认包为所述网关设备基于所述第二通信端的通信协议版本对所述第一通信端提供的用于确认通信连接的第一确认包进行转换而生成的，且所述第二确认包中包含所述第一通信端的源地址；

从所述第二确认包中，获取所述第一通信端的源地址。

25.根据权利要求24所述的方法，其特征在于，所述第一通信端的源地址配置在所述第二确认包的通信协议头中，所述从所述第二确认包中，获取所述第一通信端的源地址，包括：

从所述第二确认包的通信协议头中，获取所述第一通信端的源地址。

26.根据权利要求25所述的方法，其特征在于，所述第一通信端的源地址配置在所述通信协议头中的指定选项字段中，所述从所述第二确认包的通信协议头中，获取所述第一通信端的源地址，包括：

查找所述第二确认包的通信协议头中的所述指定选项字段；

从所述指定选项字段中解析出所述第一通信端的源地址。

27.根据权利要求26所述的方法，其特征在于，所述方法包括：

利用预置的第一钩子函数，查找所述第二确认包的通信协议头中的指定选项字段；并从所述指定选项字段中解析出所述第一通信端的源地址；

其中，所述第一钩子函数挂载用于处理通信协议协商过程的接口。

28.根据权利要求24所述的方法，其特征在于，还包括：

接收地址调用请求；

若所述地址调用请求请求获取针对所述第一通信端和所述第二通信端之间的通信协议协商过程对应的源地址，则输出所述第一通信端的源地址，以响应所述地址调用请求。

29.根据权利要求28所述的方法，其特征在于，所述若所述地址调用请求请求获取针对所述第一通信端和所述第二通信端之间的通信协议协商过程对应的源地址，则输出所述第一通信端的源地址，以响应所述地址调用请求，包括：

利用预置的第二钩子函数，监听源地址调用接口；

若监听到请求获取针对所述第一通信端和所述第二通信端之间的通信协议协商过程对应的源地址的地址调用请求，则利用所述第二钩子函数，将所述源地址调用接口获取到的网关设备的地址替换为所述第一通信端的源地址，以供所述源地址调用接口响应所述地址调用请求；

其中，所述第二钩子函数挂载所述源地址调用接口。

30.根据权利要求24所述的方法，其特征在于，所述第二通信端的通信协议版本采用IPv4。

31.根据权利要求24所述的方法，其特征在于，所述通信协议包括TCP协议。

32.一种网关设备，其特征在于，包括存储器、处理器和通信组件；

所述存储器用于存储一条或多条计算机指令；

所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：

在第一通信端与第二通信端进行通信协议协商的过程中，通过所述通信组件接收所述第一通信端发送的用于确认通信连接的第一确认包，所述第一确认包中包含所述第一通信端的源地址；

将所述第一确认包转换为与所述第二通信端的通信协议版本适配的第二确认包；

将所述第二通信端的源地址配置到所述第二确认包中；

通过所述通信组件将所述第二确认包提供给所述第二通信端，以供所述第二通信端从所述第二确认包中，获取所述第一通信端的源地址。

33.一种计算设备，其特征在于，包括存储器、处理器和通信组件；

所述存储器用于存储一条或多条计算机指令；

所述处理器与所述存储器和所述通信组件耦合，用于执行所述一条或多条计算机指令，以用于：

在与第一通信端进行通信协议协商的过程中，通过所述通信组件接收网关设备发送的第二确认包，其中，所述第二确认包为所述网关设备基于所述第二通信端的通信协议版本对所述第一通信端提供的用于确认通信连接的第一确认包进行转换而生成的，且所述第二确认包中包含所述第一通信端的源地址；

从所述第二确认包中，获取所述第一通信端的源地址。

34.一种存储计算机指令的计算机可读存储介质，其特征在于，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行权利要求15-31任一项所述的地址获取方法。

Images