CN114513455A - 路由跟踪方法、装置、设备及存储介质 - Google Patents

Abstract

本申请实施例涉及通信领域，公开了一种路由跟踪方法、装置、设备及存储介质。本申请中，通过预先构建端口号冲突表，并在该表中记录被其他应用程序占用的端口号，即路由跟踪程序不可以使用的端口号，从而在利用路由跟踪程序进行路由跟踪时，通过根据端口号冲突表中记录的不可用端口号对预先分配的初始端口号进行调整，确定路由跟踪时所依据的目的端口号，从而避开了已被其他应用程序占用的端口号，排除了路由跟踪操作失败是因为端口号被占用的原因，进而保证根据确定的目的端口号和从路由跟踪命令中获取到的目的IP地址，对待访问的目的端进行的跟踪结果，能够准确的体现当前网络状况，避免给运维人员造成误导。

Description

路由跟踪方法、装置、设备及存储介质

技术领域

本申请实施例涉及通信领域，特别涉及一种路由跟踪方法、装置、设备及存储介质。

背景技术

Traceroute(路由跟踪程序)是一种用来跟踪网络中，转发路由的技术，常用于网络故障的诊断。目前，利用Traceroute实现路由跟踪时，一般会使用大于30000的端口号来发送探测报文，以尽量避免与其他应用程序侦听的端口号的冲突。

但是，随着网络技术的发展，这些大端口号不断面临被其他应用程序占用，比如33435这个端口号就被mtrace(Traceroute Facility for IP Multicast，组播的路由跟踪程序)应用程序占用了。这就导致traceroute使用被其它应用程序占用的端口号发送探测报文时，目的端不会向源端回复ICMP(Internet Control Message Protocol，Internet控制报文协议)目的不可达报文，进而导致traceroute探测失败，认为当前网络出现故障，而实际上网络是正常的，从而给运维人员造成误导。

因此，如何选择合适的端口号亟需解决。

发明内容

本申请实施例的目的在于提供一种路由跟踪方法、装置、设备及存储介质，旨在解决上述技术问题。

为解决上述技术问题，本申请的实施例提供了一种路由跟踪方法，包括：

在利用路由跟踪程序进行路由跟踪时，从路由跟踪命令中获取待跟踪的目的端的目的IP地址，并分配访问所述目的端的初始端口号；

根据所述初始端口号和预先构建的端口号冲突表，确定目的端口号，所述端口号冲突表用于管理被所述路由跟踪程序以外的应用程序占用的不可用端口号；

通过所述目的IP地址和所述目的端口号，对所述目的端进行跟踪。

为实现上述目的，本申请实施例还提供了一种路由跟踪装置，包括：

目的IP获取模块，用于在利用路由跟踪程序进行路由跟踪时，从路由跟踪命令中获取待跟踪的目的端的目的IP地址；

初始端口号分配模块，用于分配访问所述目的端的初始端口号；

目的端口号确定模块，用于根据所述初始端口号和预先构建的端口号冲突表，确定目的端口号，所述端口号冲突表用于管理被所述路由跟踪程序以外的应用程序占用的不可用端口号；

跟踪模块，用于通过所述目的IP地址和所述目的端口号，对所述目的端进行跟踪。

为实现上述目的，本申请实施例还提供了一种路由跟踪设备，包括：

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上所述的路由跟踪方法。

为实现上述目的，本申请实施例还提供了一种计算机可读存储介质，存储有计算机程序。所述计算机程序被处理器执行时实现上述所述的路由跟踪方法。

本申请提出的路由跟踪方法、装置、设备及存储介质，通过预先构建端口号冲突表，并在该表中记录被其他应用程序占用的端口号，即路由跟踪程序不可以使用的端口号，从而在利用路由跟踪程序进行路由跟踪时，通过根据端口号冲突表中记录的不可用端口号对预先分配的初始端口号进行调整，确定路由跟踪时所依据的目的端口号，从而避开了已被其他应用程序占用的端口号，排除了路由跟踪操作失败是因为端口号被占用的原因，进而保证根据确定的目的端口号和从路由跟踪命令中获取到的目的IP地址，对待访问的目的端进行的跟踪结果，能够准确的体现当前网络状况，避免给运维人员造成误导。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定。

图1是本申请第一实施例提供的路由跟踪方法流程图；

图2是针对本申请第一实施例提供的路由跟踪方法中步骤103的具体实现流程图；

图3是本申请第二实施例提供的路由跟踪方法流程图；

图4是本申请第三实施例提供的路由跟踪装置的结构示意图；

图5是本申请第四实施例提供的路由跟踪设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本申请各实施例中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本申请的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。

本申请第一实施例涉及一种路由跟踪方法，通过预先构建端口号冲突表，并在该表中记录被其他应用程序占用的端口号，即路由跟踪程序不可以使用的端口号，从而在利用路由跟踪程序进行路由跟踪时，通过根据端口号冲突表中记录的不可用端口号对预先分配的初始端口号进行调整，确定路由跟踪时所依据的目的端口号，从而避开了已被其他应用程序占用的端口号，排除了路由跟踪操作失败是因为端口号被占用的原因，进而保证根据确定的目的端口号和从路由跟踪命令中获取到的目的IP地址，对待访问的目的端进行的跟踪结果，能够准确的体现当前网络状况，避免给运维人员造成误导。

下面对本实施例的路由跟踪方法的实现细节进行说明，以下内容仅为方便理解而提供的实现细节，并非实施本方案的必须。

本实施提供的路由跟踪方法具体是应用于能够执行该方法的任意终端设备，比如客户端或服务端等，此处不再一一列举，本实施例对此也不做限制。

本实施例的具体流程如图1所示，具体包括以下步骤：

步骤101，在利用路由跟踪程序进行路由跟踪时，从路由跟踪命令中获取待跟踪的目的端的目的IP地址，并分配访问所述目的端的初始端口号。

具体的说，本实施例中所说的路由跟踪程序，即通常所说的Traceroute。

为了便于理解本实施例提供的路由跟踪方法，以下先对Traceroute的跟踪原理进行说明，具体的：

在源端(源主机或路由器)上，先通过一个UDP(User Datagram Protocol，用户数据协议)大端口号，发送IP(Internet Protocol，网际互联协议)TTL(Time To Live，生存时间值)等于1的UDP探测报文，当UDP探测报文转发到第一跳路由器上时，由于IP TTL耗尽，因此会向源端回复ICMP(Internet Control Message Protocol，Internet控制报文协议)超时报文，这样源端便获取到第一跳路由器的地址；然后，源端对UDP大端口号进行加1，并通过加1后的UDP大端口号，发送IP TTL等于2的UDP探测报文，同样地可以获取到第二跳路由器的地址。依此类推，当UDP探测报文转发到目的端(目的主机或路由器)时，由于UDP探测报文中的端口号没有被侦听，目的端会向源端回复ICMP目的不可达报文，这样源端便获取到了目的端的地址。此时，Traceroute便会结束跟踪流程。

通过上述描述不难发现，为了实现对待跟踪的目的端的路由跟踪，首先需要为待跟踪的目的端分配一个端口号，为了便于与后续出现的端口后的区分，本实施例将开始进行路由跟踪前，为待访问的目的端分配的端口号称为初始端口号。

由于，目前在利用Traceroute进行路由跟踪时，通常使用的是大端口号，即大于30000的端口号。故而，本实施例中，为目的端分配的初始端口号同样为大于30000的端口号。

此外，值得一提的是，在实际应用中，为目的端分配的初始端口号，可以是预先固定好的一个端口号，比如33434；也可以是基于预编译的随机数选择程序，从大于30000的端口号中随机选取的一个端口号。

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

步骤102，根据所述初始端口号和预先构建的端口号冲突表，确定目的端口号。

具体的说，随着网络技术的不断发展，越来越多的大端口号，即大于30000的端口号被其他应用程序所占用，比如33435这一端口号，就被matrace应用程序占用。而Traceroute进行路由跟踪时所使用的端口号，如果巧合是被其他应用程序占用的端口号，则会导致Traceroute探测失败。而Traceroute的探测结果，又是运维人员判定网络是否出现故障的一个重要依据。

也就是说，当Traceroute因为端口号被其他应用程序占用，导致探测失败时，会让运维人员误以为当前网络出现故障，而实际上网络却是正常的。因此，为了解决这一问题，选择合适的端口号，显得尤为重要。

为了选择合适的端口号，即对目的端进行跟踪时所依据的端口号，为了便于区分，以下称为目的端口号，本实施例预先构建了用于管理被Traceroute以外的其他应用程序占用的端口号，即Traceroute不可用使用的端口号，为了便于区分，以下称为不可用端口号。

关于端口号冲突表的构建，可以是通过预先收集目前已知的，被Traceroute以外的其他应用程序占用的不可用端口号，以及这些不可用端口号对应的不可用IP地址，然后建立不可用端口号与对应的不可用IP地址之间的对应关系，进而得到端口号冲突表。

相应地，步骤102中所说的根据所述初始端口号和预先构建的端口号冲突表，确定目的端口号，具体为：

通过基于预先分配的初始端口号，对记录有不可用端口号的端口号冲突表进行遍历，并将初始端口号与当前时刻遍历到的不可用端口号进行比较，若二者不相同，则继续对端口号冲突表进行遍历，并将初始端口号与当前时刻遍历到的不可用端口号进行比较，直到初始端口号与端口号冲突表中所有的不可用端口号均不相同，然后将此时的初始端口号(作为目的端口号。

相应地，若通过比较，发现二者相同，则对初始端口号进行调整，比如对初始端口号进行加1，然后重新对端口号冲突表进行遍历，并将调整后的初始端口号与当前遍历到的不可用端口号进行比较。重复执行上述操作，直到初始端口号与端口号冲突表中所有的不可用端口号均不相同，然后将此时的初始端口号(可能是经过多次调整后的)作为目的端口号。

为了便于理解，以下结合实例进行说明：

假设预先构建的端口号冲突表，如表1所示：

表1端口号冲突表

不可用端口号	不可用IP地址
		33435	X.X.X.X
33437	X.X.X.X
		33568	X.X.X.X
34135	X.X.X.X

若预先分配的初始端口号为33434，则根据该初始端口号，对表1中的不可用端口号进行遍历，可以确定，表1中不存在与初始端口号33434相同的不可用端口号，因而可以直接将初始端口号33434确定为目的端口号。

若预先分配的初始端口号为33435，则根据该初始端口号，对表1中的不可用端口号进行遍历发现，表1中存在与初始端口号33435相同的不可用端口号，此时，需要对初始端口号33435进行调整，比如加1，得到调整后的初始端口号33436，接着根据调整后的初始端口号33436，重新遍历表1中的不可用端口号，并将每次遍历到的不可用端口号与初始端口号33436进行比较，通过比较可以确定，表1中不存在与初始端口号33436相同的不可用端口号，因而可以将调整后的初始端口号33436确定为目的端口号。

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，应当理解的是，表1中出现的字符“X”，在实际应用中，具体为表示IP的实际数值。

步骤103，通过所述目的IP地址和所述目的端口号，对所述目的端进行跟踪。

具体的说，在本实施例中，在通过目的IP地址和目的端口号，对目的端进行跟踪时，首先会基于现有向目的端发起UDP探测报文的方式进行探测，进而根据探测结果，进行后续处理，如是直接结束对目的端的跟踪，还是基于其他预设响应协议，判断目的端口号是否被其他应用程序占用。

为了便于理解，以下结合图2进行具体说明：

子步骤1031，基于UDP协议，通过所述目的IP地址和所述目的端口号，向所述目的端发送UDP探测报文。

由于基于UDP协议，通过目的IP地址和目的端口号，向目的端发送UDP探测报文的操作，与现有利用Traceroute进行路由跟踪时，向目的端发起UDP探测报文的方式相同，此处不再赘述。

子步骤1032，监测是否接收到所述目的端基于所述UDP探测报文，作出的响应。

具体的说，若接收到目的端基于UDP探测报文，作出的响应，则认为本次探测成功，此时可以直接执行子步骤1036，结束对目的端的跟踪，即完成了一次路由跟踪；反之，则执行子步骤1033。

此外，应当理解的，在实际应用中，UDP探测报文只要到达目的端，就会作出响应，但是到达的目的端可能是最后一跳主机或路由器，也可能是中间路由器。而处于不同阶段的目的端，基于UDP探测报文，作出的响应是不相同的。

具体而言，若UDP探测报文到达的是中间路由器，则收到的响应为ICMP超时报文；若UDP探测报文到达的是最后一跳主机或路由器，则收到的响应为ICMP目的不可达报文。

而在实际应用中，在收到的响应为ICMP目的不可达报文时，源端才会结束对目的端的跟踪，否则需要继续继续执行所述基于UDP协议，通过所述目的IP地址和所述目的端口号，向所述目的端发送UDP探测报文的步骤。

基于此，在确定接收到目的端基于UDP探测报文，作出的响应，执行子步骤1036之前，需要先判断接收到的响应是否为ICMP目的不可达报文。

相应地，若是，则执行子步骤1036；否则，判断接收到的响应是否为ICMP超时报文。

相应地，若是，则继续执行子步骤1031中的步骤。

具体而言，在继续执行步骤1031中的步骤时，会对IP TTL值进行调整，比如加1，对目的端口号号进行调整，比如加1；然后，基于调整后的IP TTL和目的端口号，向目的端重新发送UDP探测报文。

进一步地，为了保证路由跟踪结果的有效性，在实际应用中，还可以设置接收响应的有效期，即响应必须是在预设时间周期内接收到的。故而，在基于UDP协议，通过所述目的IP地址和所述目的端口号，向所述目的端发送UDP探测报文之后，需要启动定时任务，在实际应用中，启动的可以是一个定时器。

相应地，在监测是否接收到所述目的端基于所述UDP探测报文，作出的响应时，具体是在定时任务对应的时间周期，比如1秒内，监测是否接收到所述目的端基于所述UDP探测报文，作出的响应。

相应地，若在定时任务对应的时间周期内，接收到目的端基于UDP探测报文，作出的响应，才执行子步骤1036；否则，执行子步骤1033。

子步骤1033，基于预设的响应探测协议，通过所述目的IP地址和所述目的端口号，向所述目的端发送响应探测报文。

具体的说，本实施例中所说的响应探测协议，具体是指能够使目的端收到基于该响应探测协议发送的响应探测报文，作出响应的协议，比如ICMP协议。

相应地，在选取的响应探测协议为ICMP协议时，通过目的IP地址，向目的端发送的响应探测报文，具体为ICMP探测报文。

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

子步骤1034，监测是否接收到所述目的端基于所述响应探测报文，作出的响应。

具体的说，若接收到了目的端基于响应探测报文，作出的响应，则执行子步骤1035。

以响应探测报文为ICMP探测报文为例，则只要源端接收到目的端基于ICMP探测报文，作出的响应，具体为应答报文，则认为没有收到针对UDP探测报文的响应，是因为目的端口号被其他应用程序占用了，而并非当前网络出现了故障。

相应地，若未接收到目的端基于响应探测报文，作出的响应，则可以认为本次探测失败，此时可以返回步骤102，重新确定新的目的端口号，然后基于重新确定的目的端口号，继续执行下一跳的探测，即基于重新确定的端口号，重新执行步骤103包括的上述子步骤。

应当理解的是，上述所说的继续执行下一跳的探测，具体是对IP TTL进行加调整，如加1，同时对目的端口号进行调整，如加1，然后基于调整后的IP TTL和目的端口号执行步骤103包括的上述子步骤。

此外，在对目的端口号进行调整后，还需要基于端口号冲突表，重新判断调整后的目的端口号是否可用。

相应地，在可用时，才执行上述操作。

此外，应当理解的是，为了保证路由跟踪结果的有效性，在实际应用中，同样可以设置接收目的端基于响应探测报文，作出响应的有效期，即响应必须是在预设时间周期内接收到的。故而，在基于预设的响应探测协议，通过所述目的IP地址和所述目的端口号，向所述目的端发送响应探测报文之后，需要启动定时任务，在实际应用中，启动的可以是一个定时器。

相应地，在监测是否接收到所述目的端基于所述响应探测报文，作出的响应时，具体是在定时任务对应的时间周期，比如1秒内，监测是否接收到所述目的端基于所述响应探测报文，作出的响应。

相应地，若在定时任务对应的时间周期内，接收到目的端基于响应探测报文，作出的响应，才执行子步骤1035；否则，返回步骤102。

子步骤1035，将所述目的IP地址和所述目的端口号添加到所述端口号冲突表。

具体的说，若接收到的响应为目的端基于响应探测报文作出的，则认为目的端口号被其他应用程序占用了，此时的目的端口号号和对应的目的IP地址，不适合用于路由跟踪。故而，需要将所述目的IP地址和所述目的端口号添加到所述端口号冲突表，即将当前的目的端口号和目的IP地址是在为不可以端口号和不可用IP地址。

子步骤1036，结束对所述目的端的跟踪。

由此，本实施例提供的路由跟踪方法，通过预先构建端口号冲突表，并在该表中记录被其他应用程序占用的端口号，即路由跟踪程序不可以使用的端口号，从而在利用路由跟踪程序进行路由跟踪时，通过根据端口号冲突表中记录的不可用端口号对预先分配的初始端口号进行调整，确定路由跟踪时所依据的目的端口号，从而避开了已被其他应用程序占用的端口号，排除了路由跟踪操作失败是因为端口号被占用的原因，进而保证根据确定的目的端口号和从路由跟踪命令中获取到的目的IP地址，对待访问的目的端进行的跟踪结果，能够准确的体现当前网络状况，避免给运维人员造成误导。

本发明的第二实施例涉及一种路由跟踪方法。第二实施例在第一实施例的基础上做了进一步改进，主要改进之处为：在构建端口号冲突表时，除了建立不可用端口号和不可用IP地址之间的对应关系，还会为每一个不可用端口号设置一个初始生存剩余时长，并在设置好初始生存剩余时长后，启动倒计时任务，进而得到具有时效性的端口号冲突表。

进一步地，在得到具有时效性的端口号冲突表后，可以以预设时间粒度，定时对所述端口号冲突表进行遍历，根据遍历到的所述不可用端口号对应的所述倒计时任务和所述初始生存剩余时长，确定所述不可用端口号的当前生存剩余时长，并在所述当前生存剩余时长为0时，将所述不可用UDP，及所述不可用UDP对应的所述不可用IP地址从所述端口号冲突表中删除。

进一步地，在得到具有时效性的端口号冲突表后，也可以在每次接收到路由跟踪命令，根据分配的初始端口号和端口号冲突表，确定目的端口号之前，先对所述端口号冲突表进行遍历，根据遍历到的所述不可用端口号对应的所述倒计时任务和所述初始生存剩余时长，确定所述不可用端口号的当前生存剩余时长，并在所述当前生存剩余时长为0时，将所述不可用UDP，及所述不可用UDP对应的所述不可用IP地址从所述端口号冲突表中删除。

相应地，在完成上述操作后，在根据分配的初始端口号号和更新后的端口号冲突表，确定目的端口号，进而通过目的IP地址和确定的目的端口号，对目的端进行跟踪。

此外，应当理解的是，由于在实际应用中，一些被其他应用程序占用的不可用端口号，可能在生存剩余时长为0时，被其他应用程序释放，也可能依旧被占用着，因而在将所述不可用UDP，及所述不可用UDP对应的所述不可用IP地址从所述端口号冲突表中删除之前，可以先基于当前生存剩余时长为0的不可用IP地址和不可用端口号，进行路由跟踪，进而根据跟踪结果，确定是否将所述不可用UDP，及所述不可用UDP对应的所述不可用IP地址从所述端口号冲突表中删除。

为了便于理解，以下结合图3进行具体说明：

步骤301，基于UDP协议，通过所述不可用IP地址和所述不可用端口号，向所述目的端发送UDP探测报文。

步骤302，监测是否接收到所述目的端基于所述UDP探测报文，作出的响应。

具体的说，若未接收到目的端基于UDP探测报文，作出的响应，则执行步骤303；否则执行步骤305。

步骤303，基于预设的响应探测协议，通过所述不可用IP地址和所述不可用端口号，向所述目的端发送响应探测报文，所述响应探测协议为所述目的端收到后会作出回应的协议。

步骤304，监测是否接收到所述目的端基于所述响应探测报文，作出的响应。

具体的说，若未接收到目的端基于响应探测报文，作出的响应，则执行步骤305；否则，执行步骤306。

不难发现，本实施例中的步骤301至步骤304，与第一实施例中的步骤1031至步骤1034大致相同，主要区别就是进行报文探测时所依据的IP地址和端口号，从目的IP地址切换为了不可用IP地址，从目的端口号切换为了不可用端口号。故而，此处不再赘述，具体细节，详见第一实施例中的相关描述。

步骤305，将所述不可用UDP，及所述不可用UDP对应的所述不可用IP地址从所述端口号冲突表中删除。

步骤306，将所述不可用端口号对应的所述当前生存剩余时长设置为所述初始生存剩余时长。

具体的说，若通过判断，确定接收到了目的端基于响应探测报文，作出的响应，则说明当前时刻，不可用IP地址和不可用端口号，依旧被其他应用程序占用着，即不可用IP地址和不可用端口号依旧无法被Traceroute使用，这种情况下，需要将所述不可用端口号对应的当前生存剩余时长，从0调整为初始生存剩余时长，比如依旧调整为24小时。

由此，本实施例提供的路由跟踪方法，通过对端口号冲突表引入老化机制，即生存剩余时长，当生存剩余时长为0，且通过对生存剩余时长为0的不可用端口号和不可用IP地址，进行报文探测，进而在确定不可用端口号已经恢复可用时，将不可用端口号和对应的不可用IP地址从端口号冲突表中删除，否则，重新设置初始生存剩余时长，从而使得端口号冲突表能够更好的管理不可用端口号，使得基于端口号冲突表确定的目的端口号能够更加适合Tracerout进行路由跟踪，进而保证了路由跟踪的准确性。

此外，应当理解的是，上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本发明第三实施例涉及一种路由跟踪装置，如图4所示，包括：目的IP获取模块401、初始端口号分配模块402、目的端口号确定模块403和跟踪模块404。

其中，目的IP获取模块401，用于在利用路由跟踪程序进行路由跟踪时，从路由跟踪命令中获取待跟踪的目的端的目的IP地址；初始端口号分配模块402，用于分配访问所述目的端的初始端口号；目的端口号确定模块403，用于根据所述初始端口号和预先构建的端口号冲突表，确定目的端口号，所述端口号冲突表用于管理被所述路由跟踪程序以外的应用程序占用的不可用端口号；跟踪模块404，用于通过所述目的IP地址和所述目的端口号，对所述目的端进行跟踪。

此外，在另一个例子中，路由跟踪装置还包括端口号冲突表构建模块。

具体而言，端口号冲突表构建模块，用于收集被所述路由跟踪程序以外的应用程序占用的所述不可用端口号，以及所述不可用端口号对应的不可用IP地址；建立所述不可用端口号和所述不可用IP地址之间的对应关系，得到所述端口号冲突表。

此外，在另一个例子中，跟踪模块404，具体用于：

基于UDP协议，通过所述目的IP地址和所述目的端口号，向所述目的端发送UDP探测报文；

监测是否接收到所述目的端基于所述UDP探测报文，作出的响应；

若收到，则结束对所述目的端的跟踪；

否则，基于预设的响应探测协议，通过所述目的IP地址和所述目的端口号，向所述目的端发送响应探测报文，所述响应探测协议为所述目的端收到后会作出回应的协议；

若收到了所述目的端基于所述响应探测报文，作出的响应，则将所述目的IP地址和所述目的端口号添加到所述端口号冲突表，并结束对所述目的端的跟踪；

否则，根据所述端口号冲突表，重新确定所述目的端口号，并根据所述目的IP地址和重新确定的所述目的端口号，对所述目的端进行跟踪。

此外，在另一个例子中，路由跟踪装置还包括时间管理模块。

具体而言，时间管理模块，用于在跟踪模块404基于UDP协议，通过所述目的IP地址和所述目的端口号，向所述目的端发送UDP探测报文之后，启动定时任务。

相应地，跟踪模块404，具体用于：

在所述定时任务对应的时间周期内，监测是否接收到所述目的端基于所述UDP探测报文，作出的响应。

此外，在另一个例子中，跟踪模块404，还用于：

判断接收到的所述响应是否为ICMP目的不可达报文；

若是，则执行所述结束对所述目的端的跟踪的步骤；

否则，判断接收到的所述响应是否为ICMP超时报文；

若是，则继续执行所述基于UDP协议，通过所述目的IP地址和所述目的端口号，向所述目的端发送UDP探测报文的步骤。

此外，在另一个例子中，端口号冲突表构建模块，还用于：

建立所述不可用端口号和所述不可用IP地址之间的对应关系，并为每一个所述不可用端口号设置初始生存剩余时长，并启动倒计时任务，得到所述端口号冲突表。

此外，在另一个例子中，路由跟踪装置还包括端口号冲突表维护模块。

具体而言，端口号冲突表维护模块，用于对所述端口号冲突表进行遍历，根据遍历到的所述不可用端口号对应的所述倒计时任务和所述初始生存剩余时长，确定所述不可用端口号的当前生存剩余时长，并在所述当前生存剩余时长为0时，将所述不可用UDP，及所述不可用UDP对应的所述不可用IP地址从所述端口号冲突表中删除。

此外，在另一个例子中，端口号冲突表维护模块，具体用于：

基于UDP协议，通过所述不可用IP地址和所述不可用端口号，向所述目的端发送UDP探测报文；

监测是否接收到所述目的端基于所述UDP探测报文，作出的响应；

若收到，则执行将所述不可用UDP，及所述不可用UDP对应的所述不可用IP地址从所述端口号冲突表中删除的步骤；

否则，基于预设的响应探测协议，通过所述不可用IP地址和所述不可用端口号，向所述目的端发送响应探测报文，所述响应探测协议为所述目的端收到后会作出回应的协议；

若未收到所述目的端基于所述响应探测报文，作出的响应，则执行将所述不可用UDP，及所述不可用UDP对应的所述不可用IP地址从所述端口号冲突表中删除的步骤；

否则，将所述不可用端口号对应的所述当前生存剩余时长设置为所述初始生存剩余时长。

此外，在另一个例子中，目的端口号确定模块403，具体用于：

根据所述初始端口号，对所述端口号冲突表进行遍历；

若未遍历到与所述初始端口号相同的所述不可用端口号，则将所述初始端口号确定为所述目的端口号；

否则，对所述初始端口号进行调整，直到在所述端口号冲突表中遍历不到与调整后的所述初始端口号为止，并将调整后的所述初始端口号确定为所述目的端口号。

不难发现，本实施例为与第一或第二实施例相对应的装置实施例，本实施例可与第一或第二实施例互相配合实施。第一或第二实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在第一或第二实施例中。

值得一提的是，本实施例中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施例中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施例中不存在其它的单元。

本申请的第四实施例涉及一种路由跟踪设备，如图5所示，包括：包括至少一个处理器501；以及，与至少一个处理器501通信连接的存储器502；其中，存储器502存储有可被至少一个处理器501执行的指令，指令被至少一个处理器501执行，以使至少一个处理器501能够执行上述方法实施例所描述的路由跟踪方法。

其中，存储器502和处理器501采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器501和存储器502的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器501处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器501。

处理器501负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器502可以被用于存储处理器501在执行操作时所使用的数据。

本申请的第五实施例涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例所描述的路由跟踪方法。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施例是实现本申请的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。

Claims (12)

1.一种路由跟踪方法，其特征在于，包括：

在利用路由跟踪程序进行路由跟踪时，从路由跟踪命令中获取待跟踪的目的端的目的IP地址，并分配访问所述目的端的初始端口号；

根据所述初始端口号和预先构建的端口号冲突表，确定目的端口号，所述端口号冲突表用于管理被所述路由跟踪程序以外的应用程序占用的不可用端口号；

通过所述目的IP地址和所述目的端口号，对所述目的端进行跟踪。

2.根据权利要求1所述的路由跟踪方法，其特征在于，所述端口号冲突表的构建，包括：

收集被所述路由跟踪程序以外的应用程序占用的所述不可用端口号，以及所述不可用端口号对应的不可用IP地址；

建立所述不可用端口号和所述不可用IP地址之间的对应关系，得到所述端口号冲突表。

3.根据权利要求2所述的路由跟踪方法，其特征在于，所述通过所述目的IP地址和所述目的端口号，对所述目的端进行跟踪，包括：

基于UDP协议，通过所述目的IP地址和所述目的端口号，向所述目的端发送UDP探测报文；

监测是否接收到所述目的端基于所述UDP探测报文，作出的响应；

若收到，则结束对所述目的端的跟踪；

否则，基于预设的响应探测协议，通过所述目的IP地址和所述目的端口号，向所述目的端发送响应探测报文，所述响应探测协议为所述目的端收到后会作出回应的协议；

若收到了所述目的端基于所述响应探测报文，作出的响应，则将所述目的IP地址和所述目的端口号添加到所述端口号冲突表，并结束对所述目的端的跟踪；

否则，根据所述端口号冲突表，重新确定所述目的端口号，并根据所述目的IP地址和重新确定的所述目的端口号，对所述目的端进行跟踪。

4.根据权利要求3所述的路由跟踪方法，其特征在于，在所述基于UDP协议，通过所述目的IP地址和所述目的端口号，向所述目的端发送UDP探测报文之后，所述方法还包括：

启动定时任务；

其中，所述监测是否接收到所述目的端基于所述UDP探测报文，作出的响应，包括：

在所述定时任务对应的时间周期内，监测是否接收到所述目的端基于所述UDP探测报文，作出的响应。

5.根据权利要求3或4所述的路由跟踪方法，其特征在于，在所述结束对所述目的端的跟踪之前，所述方法还包括：

判断接收到的所述响应是否为ICMP目的不可达报文；

若是，则执行所述结束对所述目的端的跟踪的步骤；

否则，判断接收到的所述响应是否为ICMP超时报文；

若是，则继续执行所述基于UDP协议，通过所述目的IP地址和所述目的端口号，向所述目的端发送UDP探测报文的步骤。

6.根据权利要求2所述的路由跟踪方法，其特征在于，所述端口号冲突表的构建，还包括：

建立所述不可用端口号和所述不可用IP地址之间的对应关系，并为每一个所述不可用端口号设置初始生存剩余时长，并启动倒计时任务，得到所述端口号冲突表。

7.根据权利要求6所述的路由跟踪方法，其特征在于，在所述得到所述端口号冲突表之后，所述方法还包括：

对所述端口号冲突表进行遍历，根据遍历到的所述不可用端口号对应的所述倒计时任务和所述初始生存剩余时长，确定所述不可用端口号的当前生存剩余时长，并在所述当前生存剩余时长为0时，将所述不可用UDP，及所述不可用UDP对应的所述不可用IP地址从所述端口号冲突表中删除。

8.根据权利要求7所述的路由跟踪方法，其特征在于，在所述将所述不可用UDP，及所述不可用UDP对应的所述不可用IP地址从所述端口号冲突表中删除之前，所述方法还包括：

基于UDP协议，通过所述不可用IP地址和所述不可用端口号，向所述目的端发送UDP探测报文；

监测是否接收到所述目的端基于所述UDP探测报文，作出的响应；

若收到，则执行将所述不可用UDP，及所述不可用UDP对应的所述不可用IP地址从所述端口号冲突表中删除的步骤；

否则，基于预设的响应探测协议，通过所述不可用IP地址和所述不可用端口号，向所述目的端发送响应探测报文，所述响应探测协议为所述目的端收到后会作出回应的协议；

若未收到所述目的端基于所述响应探测报文，作出的响应，则执行将所述不可用UDP，及所述不可用UDP对应的所述不可用IP地址从所述端口号冲突表中删除的步骤；

否则，将所述不可用端口号对应的所述当前生存剩余时长设置为所述初始生存剩余时长。

9.根据权利要求1或8所述的路由跟踪方法，其特征在于，所述根据所述初始端口号和预先构建的端口号冲突表，确定目的端口号，包括：

根据所述初始端口号，对所述端口号冲突表进行遍历；

若未遍历到与所述初始端口号相同的所述不可用端口号，则将所述初始端口号确定为所述目的端口号；

否则，对所述初始端口号进行调整，直到在所述端口号冲突表中遍历不到与调整后的所述初始端口号为止，并将调整后的所述初始端口号确定为所述目的端口号。

10.一种路由跟踪装置，其特征在于，包括：

目的IP获取模块，用于在利用路由跟踪程序进行路由跟踪时，从路由跟踪命令中获取待跟踪的目的端的目的IP地址；

初始端口号分配模块，用于分配访问所述目的端的初始端口号；

目的端口号确定模块，用于根据所述初始端口号和预先构建的端口号冲突表，确定目的端口号，所述端口号冲突表用于管理被所述路由跟踪程序以外的应用程序占用的不可用端口号；

跟踪模块，用于通过所述目的IP地址和所述目的端口号，对所述目的端进行跟踪。

11.一种路由跟踪设备，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至9任一所述的路由跟踪方法。

12.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至9中任一项所述的路由跟踪方法。

Images