CN116708247B - 路由器测速方法和路由器 - Google Patents

路由器测速方法和路由器 Download PDF

Info

Publication number
CN116708247B
CN116708247B CN202211168642.3A CN202211168642A CN116708247B CN 116708247 B CN116708247 B CN 116708247B CN 202211168642 A CN202211168642 A CN 202211168642A CN 116708247 B CN116708247 B CN 116708247B
Authority
CN
China
Prior art keywords
message
server
data
layer
router
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202211168642.3A
Other languages
English (en)
Other versions
CN116708247A (zh
Inventor
施磊
邵磊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202211168642.3A priority Critical patent/CN116708247B/zh
Publication of CN116708247A publication Critical patent/CN116708247A/zh
Application granted granted Critical
Publication of CN116708247B publication Critical patent/CN116708247B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876Network utilisation, e.g. volume of load or congestion level
    • H04L43/0894Packet rate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/50Testing arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请提供了路由器测速方法和路由器。可以在路由器的内核驱动层发送下载请求,在内核驱动层接收服务器发送的数据报文,在内核驱动层生成数据报文对应的确认报文。然后将数据报文对应的确认报文从内核驱动层发送至服务器。并且在内核层统计数据报文的累计数据大小。路由器的应用层可以从内核层获取该累计数据大小以计算下载速率。该过程不涉及协议层以及网络层的处理,可以提升获取累计数据大小的速率,使得基于该方案确定的累计数据大小计算得到的下载速率更加符合实际的下载速率。

Description

路由器测速方法和路由器
技术领域
本申请涉及终端及通信技术领域,尤其涉及使用路由器测速方法和路由器。
背景技术
路由器的功能逐渐完善,部分路由器可以实现网络测速功能,即路由器可以测量单位时间内下载的文件数据大小。在一些可能的情况下,可以将路由器单位时间内下载的文件数据大小称为下载速率。例如,路由器可以通过wget或者speedtest的方式实现测量下载速率。在一些可能的情况下,路由器可以将该下载速率反馈至运营商服务器或者终端(例如手机)。运营商服务器以及终端可以基于该下载速率调整网络传输。例如,路由器反馈的下载速率越慢,则终端可以适当降低通过路由器发送数据的速度,以免造成文件丢失。
测量出的下载速率越真实,则反馈给运营商服务器以及终端的下载速率越真实,越有利于网络传输。
如何使得路由器测量的下载速率更真实,是值的研究的方向。
发明内容
本申请提供了一种路由器测速方法和路由器,路由器计算下载速率的过程耗费的资源更少,且计算的下载速率正确性高。
第一方面,本申请提供了一种路由器测速方法,适用于路由器,该路由器包括应用层以及内核驱动层,该方法包括:该内核驱动层生成并向服务器发送下载请求,该下载请求用于请求服务器Q路并发的向该内核驱动层发送测速文件;该内核驱动层接收该服务器发送的至少一组数据报文,任一组数据报文中包括Q个数据报文;该内核驱动层生成并向该服务器发送该至少一组数据报文对应的确认报文,以表示该路由器接收到了该至少一组数据报文;该内核驱动层计算接收到的数据报文的累计数据大小;该应用层按照预设周期从该内核驱动层获取该累计数据大小;该应用层基于获取的该累计数据大小,确定预设周期内获取的平均数据大小作为下载速率。
上述实施例中,路由器可以在内核驱动层发送下载请求,在内核驱动层接收服务器发送的数据报文,在内核驱动层生成数据报文对应的确认报文。然后将数据报文对应的确认报文从内核驱动层发送至服务器。并且在内核层统计数据报文的累计数据大小。路由器的应用层可以从内核层获取该累计数据大小以计算下载速率。该过程不涉及协议层以及网络层的处理,可以提升获取累计数据大小的速率,使得基于该方案确定的累计数据大小计算得到的下载速率更加符合实际的下载速率。且,该方案减少了调用路由器的处理器(central processing unit,CPU)、内存以及路由器的IO读写能力等硬件资源的频率,使得路由器计算下载速率的过程耗费的资源更少。
结合第一方面,在一些实施例中,该应用层按照预设周期从该内核驱动层获取该累计数据大小之后,该方法还包括:该内核驱动层将该累计数据大小设置为0,且,该内核驱动层重新计算接收到的数据报文的累计数据大小。
上述实施例中,应用层每次从内核驱动层获取一个累计数据大小之后,内核驱动层将该累计数据大小设置为0,这样,内核层就重新从0累计后续接收到的数据大小,这样,应用层每次只需要将获取的累计数据大小做相加即可得到计算下载速率涉及的全部数据大小。这样,可以简化应用层的应用。
结合第一方面,在一些实施例中,该内核驱动层生成并向服务器发送下载请求之前,该方法还包括:该应用层开启Q个线程,该Q个线程用于从服务器获取测速文件;该应用层将该Q个线程、Q个线程对应的通信四元组发送至该内核驱动层;该通信四元组包括该路由器的IP地址、该Q个线程对应的端口号、该服务器的IP地址以及该服务器的端口号;该内核驱动层截取该应用层生成的第一确认报文;该第一确认报文中至少包括该路由器向该服务器发送报文时的第一序列号;该内核驱动层基于该第一确认报文以及该Q个线程对应的通信四元组生成该下载请求。
上述实施例中,通信四元组中包括源IP地址、源端口、目的IP地址以及目的端口。第一确认报文对应的源IP地址、源端口、目的IP地址以及目的端口与通信四元组相同时,内核驱动层才确定该第一确认报文是下载测速文件所涉及的报文,才将其截获以从中获取与服务器发送报文时的seq、ack等信息。即这里涉及通信四元组下发到内核驱动层的目的在于,便于内核驱动层确定发送的报文是否为第一确认报文。
结合第一方面,在一些实施例中,该内核驱动层生成并向该服务器发送下载请求,具体包括:该内核驱动层将该下载请求对应的序列号设置为与该第一序列号相同;该内核驱动层向该服务器发送该下载请求以及该下载请求对应的序列号。
上述实施例中,该第一序列号为三次握手时,路由器与服务器协商的初始序列号,当内核驱动层发送的下载请求的初始序列号(序列号)与该第一序列号相同时,服务器才会在三次握手的基础上给路由器发送测速文件。这样,才可以使得内核驱动层可以接收到测速文件。
结合第一方面,在一些实施例中,该至少一组数据报文中包括数据报文1-数据报文N,该内核驱动层生成并向该服务器发送该至少一组数据报文对应的确认报文,具体包括:该内核驱动层向该服务器发送第二确认报文;其中,该第二确认报文包括第一确认号,该第一确认号表示为该数据报文1的序列号加上该表示该数据报文1-数据报文N的长度;该第二确认报文用于确认该路由器接收到了该数据报文1-数据报文N;该N为大于等于2的整数。
上述实施例中,内核驱动层在接收到多个数据报文时,才会发送一次确认报文以通知服务器,该多个数据报文已经接收到。这样,服务器在接收到该确认报文时,可以继续发送测速文件。这样,可以节约内核驱动层的功耗。这里可以将多个数据报文对应的确认作一次回复的原因在于:本方案的目的在于获取测速文件的大小,而不是要获取准确无误的测速文件。
结合第一方面,在一些实施例中,该至少一组数据报文中包括数据报文1-数据报文N,该内核驱动层生成并向该服务器发送该至少一组数据报文对应的确认报文,具体包括:该内核驱动层向该服务器分别发送确认报文1至确认报文N;其中,该确认报文1至确认报文N中第j个确认报文为第j个数据报文对应的确认报文;该第j个确认报文中包括的确认号为该第j个数据报文的序列号加上该第j个数据报文的长度;该第j个确认报文用于确认该路由器接收到了该第j个数据报文。
结合第一方面,在一些实施例中,该预设周期为1s。
结合第一方面,在一些实施例中,该应用层基于获取的累计数据大小,确定预设周期内获取的平均数据大小作为下载速率,具体包括:该应用层计算连续获取的P个累计数据大小的总和;该应用层将该总和与P的比值作为该下载速率。
结合第一方面,在一些实施例中,该N等于10。
结合第一方面,在一些实施例中,该内核驱动层接收该服务器发送的至少一组数据报文之后,该内核驱动层计算接收到的数据报文的累计数据大小之前,该方法还包括:该内核驱动层将该至少一组数据报文存储在套接字缓存socketbuffer中。
第二方面,本申请提供了一种路由器,该路由器包括应用层以及内核驱动层,其中:该内核驱动层用于,生成并向服务器发送下载请求,该下载请求用于请求服务器Q路并发的向该内核驱动层发送测速文件;该内核驱动层还用于,接收该服务器发送的至少一组数据报文,任一组数据报文中包括Q个数据报文;该内核驱动层还用于,生成并向该服务器发送该至少一组数据报文对应的确认报文,以表示该路由器接收到了该至少一组数据报文;该内核驱动层还用于,计算接收到的数据报文的累计数据大小;该应用层用于,按照预设周期从该内核驱动层获取该累计数据大小;该应用层还用于,基于获取的累计数据大小,确定预设周期内获取的平均数据大小作为下载速率。
上述实施例中,路由器可以在内核驱动层发送下载请求,在内核驱动层接收服务器发送的数据报文,在内核驱动层生成数据报文对应的确认报文。然后将数据报文对应的确认报文从内核驱动层发送至服务器。并且在内核层统计数据报文的累计数据大小。路由器的应用层可以从内核层获取该累计数据大小以计算下载速率。该过程不涉及协议层以及网络层的处理,可以提升获取累计数据大小的速率,使得基于该方案确定的累计数据大小计算得到的下载速率更加符合实际的下载速率。且,该方案减少了调用路由器的处理器(central processing unit,CPU)、内存以及路由器的IO读写能力等硬件资源的频率,使得路由器计算下载速率的过程耗费的资源更少。
第三方面,本申请提供了一种路由器,该路由器包括应用层以及内核驱动层,该应用层以及该内核驱动层可以用于使得该路由器执行前述第一方面的方法。
上述实施例中,路由器可以在内核驱动层发送下载请求,在内核驱动层接收服务器发送的数据报文,在内核驱动层生成数据报文对应的确认报文。然后将数据报文对应的确认报文从内核驱动层发送至服务器。并且在内核层统计数据报文的累计数据大小。路由器的应用层可以从内核层获取该累计数据大小以计算下载速率。该过程不涉及协议层以及网络层的处理,可以提升获取累计数据大小的速率,使得基于该方案确定的累计数据大小计算得到的下载速率更加符合实际的下载速率。且,该方案减少了调用路由器的处理器(central processing unit,CPU)、内存以及路由器的IO读写能力等硬件资源的频率,使得路由器计算下载速率的过程耗费的资源更少。
附图说明
图1示出了一种方案中路由器确定下载速率时涉及的软件体系;
图2示出了一种方案中路由器确定下载速率的过程;
图3示出了另一种方案中路由器确定下载速率时涉及的软件体系;
图4示出了另一种方案中路由器确定下载速率的过程;
图5示出了基于内核驱动层测量下载速度的另一个示意性流程图;
图6为服务器发送测速文件时涉及的一个示例性示意图;
图7示出了方案1以及方案2中确定下载速度的性能比较图。
具体实施方式
本申请以下实施例中所使用的术语只是为了描述特定实施例的目的,而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样,单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括复数表达形式,除非其上下文中明确地有相反指示。还应当理解,本申请中使用的术语“和/或”是指并包含一个或多个所列出项目的任何或所有可能组合。
以下,术语“第一”、“第二”仅用于描述目的,而不能理解为暗示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征,在本申请实施例的描述中,除非另有说明,“多个”的含义是两个或两个以上。
本申请实施例的一种方案中,路由器可以基于TCP/IP协议从服务器中下载文件(后文中可以称为测速文件),统计单位时间内下载的文件数据大小以确定下载速率。
路由器首先与服务器通过三次握手协议建立连接。然后,路由器可以向服务器发送下载测速文件的请求,服务器在接收到该请求之后,可以向路由器发送测速文件,该测速文件可以基于TCP/IP协议从服务器传输至路由器。该方案中,路由器在应用层开启Q个用于下载测速文件的线程(即路由器的应用层可以获取测速文件),并在应用层统计接收到测速文件的文件数据大小。在应用层确定单位时间内下载的文件数据大小作为下载速率。
图1示出了一种方案中路由器确定下载速率时涉及的软件体系。
图1为路由器的软件体系100。该软件体系100适用于该方案中路由器在应用层获取测速文件以确定下载速率的情况。
如图1所示,路由器的软件体系中包括应用层、协议层、网络层以及硬件驱动层。其中,硬件驱动层也可以被称为内核驱动层。
在该软件体系100中,应用层可以用于启动下载测速文件的Q个线程,该Q个线程用于并发地下载测速文件。应用层还可以生成下载请求以向服务器请求下载测速文件。应用层在接收到测速文件之后,还可以生成确认报文并将该确认报文下发至协议层。应用层可以统计下载文件(测速文件)的累计数据大小以计算下载速率。
协议层可以用于将应用层下发的数据添加一个TCP报头以生成TCP报文,将其发送至网络层,还可以用于将TCP报文分段重组,还可以用于进行拥塞控制、慢启动、乱序重排、超时重排等。还可以用于TCP报文校验等。
网络层可以用于将协议层传输下来的报文添加一个IP报头以生成IP报头,并将其发送至硬件驱动层。还可以用于IP报文校验,还可以用于分片重组、netfilter hook点回调函数执行、报文修改等。
硬件驱动层(内核驱动层)可以驱动路由器硬件以实现报文的传输,例如将报文发送至网络中,或者从网络中接收报文。
应该理解的是,在该软件体系100中,应用层发送给服务器的数据,例如请求等都可以经过协议层、网络层被封装成报文,经过硬件驱动层发送至服务器。同理,应用层所接收的服务器发送的数据(例如测速文件等)也是包括在报文中,由硬件驱动层接收到之后,传输至协议层以及网络层之后获取其中的测速文件,再传输至应用层。
在该软件体系100中,路由器的应用层获取测速文件的过程如下:
首先,是硬件驱动层接收从服务器下载的数据报文,该数据报文中包括测速文件。然后,硬件驱动层将该数据报文传输至网络层,网络层可以对该数据报文进行相关处理确定其正确性之后,将其发送至协议层。其中,网络层对数据报文的相关处理包括:进行IP报文检验,确定该数据报文是否正确,是否存在丢包等。
协议层在接收到数据报文之后,可以对其进行相关处理确定其正确性,在确定其正确之后,将其发送至应用层。其中,协议层对数据报文的相关处理包括:进行TCP报文检验。
然后,应用层在接收到该数据报文之后,可以生成确认报文(ACK),然后将该ACK报文经过协议层、网络层进行相关处理,该相关处理包括计算IP校验码以及TCP校验码等,然后发送至硬件驱动层。
驱动硬件层在接收到该数据报文对应的确认报文之后,可以将其发送至网络中以传输至服务器。
这里应该理解的是,在应用层与硬件驱动层进行数据交互的过程中,网络层以及协议层还可以执行其他操作,以使得数据的交互正常。例如,网络层可以进行拥塞控制,在网络拥塞时,降低数据传输的速度避免数据丢失。
图2示出了一种方案中路由器确定下载速率的过程。
该过程可以参考对下述步骤S10-步骤S19的描述。
S10.应用层开启Q个线程,该Q个线程用于从服务器获取测速文件。
应用层开启Q个线程,不同的线程对应不同的端口,每个端口都可以用于从服务器下载测试文件。
下述步骤S11-步骤S13为路由器与服务器之间经过三次握手建立连接的过程。该过程可以用于协商双方发送报文时的初始序列号(seq)。一个设备向另一个设备发送报文A时,该报文A对应的seq表示该报文A中包括的数据的第一个字段的序号,该序号为该设备向另外一个设备发送的全部数据中的序号。
S11.路由器通过向服务器发送同步序列编号(SYN)-10请求建立连接,该SYN-10中包括初始序列号10(seq10),该seq10=x。
seq10用于表示路由器向服务器发起建立连接的请求时,初始化的序列号。后续,路由器以及服务器将基于该seq10协商双方发送报文时,该报文对应的初始序列号。
S12.服务器通过SYN-20以及确认报文(ACK报文)-20对路由器发起的连接请求进行应答,该SYN-10以及ACK-20中包括服务器的seq21以及确认号21(ack20),其中,seq21=y,ack21=x+1。
seq21为三次握手之后,服务器第一次向路由器发送报文时,该报文对应的初始序列号。
ack21=x+1表示接受到了路由器发送的连接请求。
S13.路由器通过向服务器发送ACK报文-10,表示路由器与服务器建立了连接,该ACK报文-10中包括路由器的seq11以及ack11其中,seq11=x+1,ack11=y+1。
seq11为三次握手之后,路由器第一次向服务器发送报文时,该报文对应的初始序列号。
ack11=y+1表示接受到了路由器确定与服务器建立了连接。
下文中,初始序列号也可以被称为序列号。
三次握手之后,路由器与服务器之间就进入了数据传输状态,可以相互发送数据(报文)了。
S14.路由器向服务器发送下载请求、该下载请求对应的序列号(seq)以及该下载请求对应的长度(length),该下载请求用于请求服务器Q路并发的向内核驱动层发送测速文件。
路由器的应用层生成下载请求、确定该下载请求对应的序列号(seq)以及该下载请求对应的长度(length)。然后,下发至路由器的协议层以及网络层进行处理得到报文,再将该携带了下载请求、该下载请求对应的序列号(seq)以及该下载请求对应的长度(length)的报文通过路由器的内核驱动层发送至服务器。对于该过程的详细描述可以参加前述对图1的描述,此处不再赘述。
S15.服务器通过向路由器发送下载请求对应的ACK报文,表示接收到了该下载请求。
后续,服务器可以Q路并发的向路由器发送测速文件,该过程可以参考下述对步骤S16a以及步骤S16b的描述。路由器的应用层在接收到发送测速文件之后,会向服务器发送一个确认报文(ACK报文)以确定接收到了测速文件,该过程可以参考下述对步骤S17a以及步骤S17b的描述。
S16a.服务器向路由器发送数据报文1、数据报文1对应的序列号(seq)以及该数据报文1对应的长度(length),该数据报文1对应线程1。
S17a.路由器通过向服务器发送数据报文1对应的ACK报文,表示接收到了该数据报文1。
S16b.服务器向路由器发送数据报文Q、数据报文Q对应的序列号(seq)以及该数据报文Q对应的长度(length),该数据报文Q对应线程Q。
S17b.路由器通过向服务器发送数据报文Q对应的ACK报文,表示接收到了该数据报文Q。
前述步骤S16a以及步骤S16b的执行时间没有先后关系。步骤S16a以及步骤S16b描述了服务器并发的向路由器发送测速文件(Q路并发的发送测速文件)。该Q路测速文件可以被称为数据报文1-数据报文Q。步骤S16a中描述了发送数据报文1的过程,步骤S16b中描述了发送数据报文2的过程。其他数据报文的发生过程可以对步骤S16a以及步骤S16b的描述,此处不再赘述。此处,服务器向路由器发送的数据报文A(例如数据报文1-数据报文Q中的任一个,或者测速文件对应的其他数据报文)时,是路由器的硬件驱动层先接收到该数据报文A,然后经过网络层以及协议层的处理再到达应用层。其中,在网络层的处理包括IP报文校验、分片重组等等,在协议层的处理包括TCP报文分段重组、拥塞控制、慢启动、乱序重排、超时重排等。这些处理的目的是为了保证接收到的数据报文A的正确性以及控制数据报文的传输以防止丢包等。对数据报文A从内核驱动层到应用层的传输过程可以参考前述对图1中对数据报文传输涉及的相关内容的描述,此处不再赘述。
前述步骤S17a以及步骤S17b的执行时间没有先后关系。为路由器向服务器发送确认报文,以通知服务器:路由器接收到了数据报文。应用层在接收到该数据报文A(例如数据报文1-数据报文Q中的任一个,或者测速文件对应的其他数据报文)之后,可以生成该数据报文A对应的确认报文A,然后将该确认报文A经过协议层、网络层进行相关处理,该相关处理包括计算IP校验码以及TCP校验码等,然后发送至硬件驱动层。由硬件驱动层将该确认报文A发送至服务器,服务器接收到该确认报文A之后,即可确定:路由器接收到了该确认报文A中确认号对应的全部数据报文,然后继续向路由器发送数据报文。对确认报文A从应用层到内核驱动层的传输过程可以参考前述对图1中对确认报文传输涉及的相关内容的描述,此处不再赘述。
应该理解的是,在路由器确定下载速率的过程中,服务器可以多次并发(Q路并发)的向路由器发送数据报文(包括了测速文件)。可以参考对前述步骤S16a以及步骤S16b及其相关内容的描述,此处不再赘述。
S18.应用层计算数据报文1-数据报文E的累计数据大小,基于该累计数据大小确定下载速率。
在一些可能的情况下,应用层可以按照T秒(例如1s、5s)为一个周期,统计该周期内收到的累计数据大小,再将该累计数据大小/T作为该周期内的下载速率。
S19.路由器在确定下载速率之后,通过四次挥手与服务器断开连接。
首先,路由器向服务器发送结束(finish,FIN)报文10(FIN10),表示与服务器断开连接。
服务器接收到该FIN10之后,向路由器发送FIN10对应的确认报文(ACK),表示对FIN10的确认,并向路由器发送结束报文21(FIN21)。
然后,路由器接收到FIN21之后,向服务器发送该FIN21对应的确认报文(ACK),表示对FIN21的确认,完成四次挥手。此时,路由器与服务器即可断开连接。
应该理解的是,前述步骤S10-步骤S19中,路由器向服务器发送的报文(例如包括了下载请求的报文、以及数据报文对应的ACK报文等)中,可以包括ack,还可以包括该报文对应的seq。ack用于路由器通知服务器:已接收到上一次发送的报文。还可以包括其他的内容,本申请实施例对此不作限定。服务器向路由器发送的报文(例如数据报文)中,除了包括该数据报文对应的seq以外,还可以包括该报文对应的ack。该报文对应的ack用于请求服务器通知路由器:已接收到上一次发送的报文。还可以包括其他的内容,本申请实施例对此不作限定。
参考前述图1中的相关内容,以及对图2的描述。可以理解的是,路由器的应用层在获取测速文件(数据报文)的之前需要经过网络层以及协议层的处理。以及应用层发送对应测速文件的确认报文也需要经过网络层以及协议层的处理才能发送至服务器。这些处理会调用路由器的处理器(central processing unit,CPU)、内存以及路由器的IO读写能力等硬件资源。但是,由于路由器的硬件能力有限,可能会导致路由器测得下载速率不准确,导致测量的下载速率低于实际下载速率。
本申请实施例的另外一种方案中,路由器可以在内核驱动层发送下载请求,在内核驱动层接收服务器发送的数据报文,在内核驱动层生成数据报文对应的确认报文。然后将数据报文对应的确认报文从内核驱动层发送至服务器。并且在内核层统计数据报文的累计数据大小。路由器的应用层可以从内核层获取该累计数据大小以计算下载速率。该过程不涉及协议层以及网络层的处理,可以提升获取累计数据大小的速率,使得基于该方案确定的累计数据大小计算得到的下载速率更加符合实际的下载速率。且,该方案减少了调用路由器的处理器(central processing unit,CPU)、内存以及路由器的IO读写能力等硬件资源的频率,使得路由器计算下载速率的过程耗费的资源更少。
图3示出了另一种方案中路由器确定下载速率时涉及的软件体系。
图3为路由器的软件体系200。该软件体系200适用于该方案中路由器在内核驱动层获取测速文件,且,在内核驱动层统计数据报文的累计数据大小,应用层从内核驱动层获取该累计数据大小以确定下载速率的情况。
如图3所示,路由器的软件体系中包括应用层、协议层、网络层以及硬件驱动层。其中,硬件驱动层也可以被称为内核驱动层。
在该软件体系200中,应用层可以用于启动下载测速文件的Q个线程,该Q个线程用于并发地下载测速文件。还可以用于从内核驱动层获取下载文件的累计数据大小以计算下载速率。
协议层以及网络层可以用于完成前述涉及的三次握手以使得路由器与服务器建立连接。还可以用于完成前述涉及的四次挥手以使得路由器与服务器断开连接。
内核驱动层可以用于生成下载请求以下载测速文件,生成确认报文,还可以用于统计下载文件的累计数据大小等。
在该软件体系200中,路由器的内核驱动层在获取测速文件之后,可以不再上传至其他层。且对于数据报文(包括测速文件)对应的确认报文,也可以在内核驱动层直接生成,然后从硬件驱动层发送到服务器,该过程如下:
首先,是内核驱动层接收从服务器下载的数据报文,该数据报文中包括测速文件。然后,硬件驱动层生成该数据报文对应的确认报文。内核驱动层可以将确认报文发送至网络中以传输至服务器。该过程不涉及协议层以及网络层。应该理解的是,协议层以及网络层做相关处理(包括测速文件的重组以使得测速文件有序等)的目的是为了保证测速文件的可靠传输,考虑到下载测速文件的目的是为了测量单位时间内获取的数据文件大小,则可以不通过协议层以及网络层来做处理。因为这里只需要测速文件的大小,其内容的有序性等可以不关注。这样,减少了调用路由器的处理器(central processing unit,CPU)、内存以及路由器的IO读写能力等硬件资源的频率,使得路由器计算下载速率的过程耗费的资源更少。
图4示出了另一种方案中路由器确定下载速率的过程。
该过程可以参考对下述步骤S20-步骤S31的描述。
S20.应用层开启Q个线程,该Q个线程用于从服务器获取测速文件。
S21.路由器通过向服务器发送同步序列编号(SYN)-10请求建立连接,该SYN-10中包括路由器的初始序列号10(seq10),该seq10=x。
S22.服务器通过SYN-20以及确认报文(ACK报文)-20对路由器发起的连接请求进行应答,该SYN-10以及ACK-20中包括服务器的seq21以及确认号21(ack20),其中,seq21=y,ack21=x+1。
S23.路由器通过向服务器发送ACK报文-10,表示路由器与服务器建立了连接,该ACK报文-10中包括路由器的seq11以及ack11其中,seq11=x+1,ack11=y+1。
其中,步骤S20-步骤S23为该方案中,路由器的应用层开启获取测速文件的线程,以及路由器通过三次握手协议与服务器建立连接的过程。与前述步骤S10-步骤S13涉及的内容相同。对该步骤S20-步骤S23的描述可以参考前述对步骤S10-步骤S13的描述,此处不再赘述。
S24.内核驱动层截获ACK报文-10进行存储。
该ACK报文-10中包括路由器的seq11(seq11=x+1)。其中,seq11为三次握手之后,路由器第一次向服务器发送报文时,该报文对应的初始序列号。
内核驱动层获取ACK报文-10进行存储,从其中获取seq11,作为内核驱动层第一次向服务器发送报文时的初始序列号。
S25.内核驱动层向服务器发送下载请求、该下载请求对应的序列号(seq)以及该下载请求对应的长度(length),该下载请求用于请求服务器Q路并发的向内核驱动层发送测速文件。
内核驱动层生成下载请求,将前述步骤S24中获取的seq11作为该下载请求对应的序列号,该下载请求用于请求服务器Q路并发的向内核驱动层发送测速文件。
内核驱动层向服务器发送下载请求、该下载请求对应的序列号(seq)以及该下载请求对应的长度(length),该下载请求用于请求服务器Q路并发的向内核驱动层发送测速文件。其中,下载请求对应的长度(length)可以用于服务器生成确认报文中的确认号。
S26.服务器通过向内核驱动层发送下载请求对应的ACK报文,表示接收到了该下载请求。
后续,服务器可以Q路并发的向内核驱动层发送测速文件。该过程可以参考下述对步骤S27a以及步骤S27b的描述。路由器的内核驱动层在接收到服务器发送测速文件之后,会向服务器发送一个确认报文(ACK报文)以确定接收到了测速文件,该过程可以参考下述对步骤S28a以及步骤S28b的描述。
S27a.服务器向内核驱动层发送数据报文1、数据报文1对应的seq以及该数据报文1对应的length,该数据报文1对应线程1。
S28a.内核驱动层通过向服务器发送数据报文1对应的ACK报文,表示接收到了该数据报文1。
S27b.服务器向内核驱动层发送数据报文Q、数据报文Q对应的seq以及该数据报文Q对应的length,该数据报文Q对应线程Q。
S28b.内核驱动层通过向服务器发送数据报文Q对应的ACK报文,表示接收到了该数据报文Q。
前述步骤S27a以及步骤S27b的执行时间没有先后关系。步骤S27a以及步骤S27b描述了服务器并发的向内核驱动层发送测速文件(Q路并发的发送测速文件)。该Q路测速文件可以被称为数据报文1-数据报文Q。步骤S27a中描述了发送数据报文1的过程,步骤S27b中描述了发送数据报文2的过程。其他数据报文的发生过程可以对步骤S27a以及步骤S27b的描述,此处不再赘述。此处,服务器向路由器发送的数据报文A(例如数据报文1-数据报文Q中的任一个,或者测速文件对应的其他数据报文)时,是路由器的硬件驱动层接受到该数据报文A,然后没有经过网络层以及协议层的处理,也没有到达应用层,而是在该内核驱动层生成该数据报文A对应的确认报文,然后从内核驱动层发送至服务器。对数据报文A传输到内核驱动层,以及,在内核驱动层生成该数据报文A对应的确认报文的过程可以参考前述对图2中对数据报文传输涉及的相关内容的描述,此处不再赘述。
前述步骤S28a以及步骤S28b的执行时间没有先后关系。为内核驱动层向服务器发送确认报文,以通知服务器:路由器接收到了数据报文。内核驱动层在接收到该数据报文A(例如数据报文1-数据报文Q中的任一个,或者测速文件对应的其他数据报文)之后,可以生成该数据报文A对应的确认报文A,然后将该确认报文进行相关处理,该相关处理包括计算IP校验码以及TCP校验码等,然后发送至服务器。服务器接收到该确认报文A之后,即可确定:路由器接收到了该确认报文A中确认号对应的全部数据报文,然后继续向路由器发送数据报文。对内核驱动层生成确认报文A并发送至服务器的过程可以参考前述对图2中对确认报文传输涉及的相关内容的描述,此处不再赘述。
应该理解的是,前述步骤S25-步骤S28b中,内核驱动层向服务器发送的报文(例如包括了下载请求的报文、以及数据报文对应的ACK报文等)中,可以包括ack,还可以包括该报文对应的seq。ack用于路由器通知服务器:已接收到上一次发送的报文。还可以包括其他的内容,本申请实施例对此不作限定。服务器向内核驱动层发送的报文(例如数据报文)中,除了包括该数据报文对应的seq以外,还可以包括该报文对应的ack。该报文对应的ack用于服务器通知路由器:已接收到上一次发送的报文。还可以包括其他的内容,本申请实施例对此不作限定。
还应该理解的是,在路由器确定下载速率的过程中,服务器可以多次并发(Q路并发)的向内核驱动层发送数据报文(包括了测速文件)。可以参考对前述步骤S27a以及步骤S27b及其相关内容的描述,此处不再赘述。
S29.内核驱动层计算数据报文1-数据报文E的累计数据大小,将该累计数据大小存储到预设文件中。
该数据报文1-数据报文E中包括至少一组数据报文,其中,一组数据报文中包括Q个数据报文(并发的)。
内核驱动层可以将该数据报文1-数据报文E存储到套接字缓存(socketbuffer)中。
然后统计该数据报文1-数据报文E的累计数据大小,将该累计数据大小存储到预设文件中。例如,该预设文件可以为/XXX/XXXX/stats文件中。
后续,应用层可以按照预设周期从预设文件中读取累计数据大小,应用层每取一次内核驱动层就将累计数据大小设置为0,并再次执行步骤S29继续计算后续数据报文的累计数据大小供应用层按照预设周期读取。
S30.应用层按照预设周期从预设文件中读取累计数据大小,确定下载速率。
应用层按照预设周期从内核驱动层的预设文件中获取累计数据大小;该预设周期可以为1s-5s等,例如1s。
应用层基于获取的累计数据大小,确定预设周期内获取的平均数据大小作为下载速率。例如,应用层计算连续在P个预设周期里获取累计数据大小,得到P个累计数据大小。再计算该P个累计数据大小的总和,然后将该总和与P的比值作为下载速率。
S31.路由器在确定下载速率之后,通过四次挥手与服务器断开连接。
该步骤S31涉及的内容与前述步骤S19涉及的内容相同,可以参考前述对步骤S19的描述,此处不再赘述。
应该理解的是,前述图3以及图4中涉及的内容,测速过程由内核驱动层接收服务器发送的测速文件,不会经过网络层以及协议层传输至应用层。且,在内核驱动生成该测速文件的确认报文,然后发送至服务器。该过程可以看作基于内核驱动层测速。在一些可能的情况下,该内核驱动层中的内核可以为Linux内核。
图5示出了基于内核驱动层测量下载速度的另一个示意性流程图。
该过程涉及的详细内容可以参考下述对步骤S101-步骤S115的描述。
S101.应用层开启Q个线程,该Q个线程用于从服务器获取测速文件,不同的线程对应不同的标识号。
应用层开启Q个线程,不同的线程对应不同的端口,每个端口都可以用于从服务器下载测试文件。应用层开启了Q个线程,则服务器可以Q路并发的向路由器发送测速文件,每一路都对应不同的端口号。
不同的线程对应不同的标识号。后续,可以使用该标识号唯一标识一个线程。
S102.应用层将Q个线程的标识号、下载测速文件涉及的请求以及Q个线程对应的通信四元组信息下发至内核驱动层。
应用层开启Q个线程之后,每个线程通过netlink方式,Q个线程的标识号、下载测速文件涉及的请求以及Q个线程对应的通信四元组信息下发至内核驱动层。其中,下载测速文件涉及的请求中包括服务器对应的统一资源定位标志(uniform resource locator,URL)。
Q个线程对应的通信四元组中包括源IP地址、源端口、目的IP地址以及目的端口。其中,源IP地址表示路由器的IP地址,源端口表示该Q个线程对应的端口号,则源端口共计Q个端口。目的IP表示服务器的IP地址,目的端口表示服务器的端口号。
该通信四元组的作用在于:使得内核驱动层在接收到报文时,可以确定该报文对应的接收方的IP地址以及端口号是否分别为源IP地址、源端口,以及该报文的发送方的IP地址以及端口号是否分别与目的IP地址以及目的端口号相同。如果是,内核驱动层可以确定接收到的报文中包括测速文件,则不上传到网络层等其他层级,在内核驱动层进行处理即可。其中,一个报文对应的发送方的IP地址以及端口号可以在发送报文时,一同发送,接收方的IP地址以及端口号也可以同报文一起发送。内核驱动层在接收到一个报文时,如果通过该报文对应的发送方的IP地址以及端口号、接收方的IP地址以及端口号中任一个与通信四元组中记录的内容不符,则可以确定该报文中不包括测速文件,则内核驱动层不将其作为测速文件进行后续处理。应该理解的是,基于通信四元组确定内核驱动层接收到的报文是否包括测速文件的过程应该出现在内核驱动层接收到的每一个报文中,下面中该过程将省略不再进行赘述。
应用层开启Q个线程之后,每个线程可以通过执行connect函数,连接服务器。下述步骤S103-步骤S105为路由器与服务器之间进行连接的一种方式。此时,路由器以及服务器之间可以通过三次握手建立连接。该过程可以用于协商双方发送报文时的初始序列号(seq)。一个设备向另一个设备发送报文A时,该报文A对应的seq表示该报文A中包括的数据的第一个字段的序号,该序号为该设备向另外一个设备发送的全部数据中的序号。关于路由器以及服务器经过三次握手建立连接的过程可以参考下述对步骤S103-步骤S105的描述。
S103.路由器通过向服务器发送同步序列编号(SYN)-10请求建立连接,该SYN-10中包括路由器的初始序列号10(seq10),该seq10=x。
seq10用于表示路由器向服务器发起建立连接的请求时,初始化的序列号。后续,路由器以及服务器将基于该seq10协商双方发送报文时,该报文对应的初始序列号。
S104.服务器通过SYN-20以及确认报文(ACK报文)-20对路由器发起的连接请求进行应答,该SYN-10+ACK-20中包括服务器的seq21以及确认号21(ack20),其中,seq21=y,ack21=x+1。
seq21为三次握手之后,服务器第一次向路由器发送报文时,该报文对应的初始序列号。
ack21=x+1表示接受到了路由器发送的连接请求。
S105.路由器通过向服务器发送ACK报文-10,表示路由器与服务器建立了连接,该ACK报文-10中包括路由器的seq11以及ack11其中,seq11=x+1,ack11=y+1。
seq11为三次握手之后,路由器第一次向服务器发送报文时,该报文对应的初始序列号。
ack11=y+1表示接受到了路由器确定与服务器建立了连接。
S106.内核驱动层基于Q个线程对应的通信四元组信息获取ACK报文-10进行存储。
内核驱动层获取ACK报文-10对应的发送方的IP地址1以及端口号1、ACK报文-10对应的接收方的IP地址2以及端口号2。将该IP地址1、端口号1、IP地址2以及端口号2与Q个线程的通信四元组匹配,确定一致,则可以确定该ACK报文-10为路由器与服务器建立连接时涉及的确认报文。则内核驱动层可以确定该ACK报文-10进行存储。
该ACK报文-10中包括路由器的seq11(seq11=x+1)。其中,seq11为三次握手之后,路由器第一次向服务器发送报文时,该报文对应的初始序列号。
内核驱动层获取ACK报文-10进行存储,从其中获取seq11,作为内核驱动层第一次向服务器发送报文时的初始序列号。
在一些可能的情况下,内核驱动层可以在驱动入口处(xmit_one)获取该ACK报文-10。
S107.内核驱动层基于通信四元组信息以及ACK报文-10中的seq11,构造下载测速文件涉及的下载请求,将该下载请求发送至服务器,该下载请求用于请求服务器Q路并发的向内核驱动层发送测速文件,该下载请求的第一个字符对应的序列号(seq12)为x+1,该下载请求的长度为x1。
下载测速文件涉及的下载请求中携带了路由器的源IP地址、Q个源端口、服务器的IP地址(目的IP地址)以及服务器的源端口。还包括服务器对应的统一资源定位标志(uniform resource locator,URL)。该下载请求的第一个字符对应的序列号(seq12)与seq11相同,即seq12=x+1。这里记该下载请求的长度(length)为x1。
该下载请求用于请求服务器Q路并发的向内核驱动层发送测速文件。每一路测速文件都发送至内核驱动层中不同的端口。
S108.服务器通过向内核驱动层发送ACK报文-21,表示接收到了该下载请求,该ACK报文-21中包括ack22,该ack22=seq12+x1。
后续,服务器可以Q路并发的向内核驱动层发送数据报文(包括测速文件)。该过程可以参考下述对步骤S109a以及步骤S109c的描述。路由器的内核驱动层在接收到服务器发送的N个数据报文之后,会向服务器发送一个确认报文(ACK报文)以确定接收到了该N个数据报文,该过程可以参考下述对步骤S114的描述,此处暂不赘述。
S109a.服务器向内核驱动层发送数据报文1,该数据报文1对应线程1,该数据报文1对应的序列号(seq1)为y1,该数据报文1对应的数据长度为z1。
S109b.服务器向内核驱动层发送数据报文2,该数据报文2对应线程2,该数据报文2对应的序列号(seq2)为y1+z1,该数据报文2对应的数据长度为z1。
S109c.服务器向内核驱动层发送数据报文Q,该数据报文Q对应线程Q,该数据报文Q对应的序列号为y1+(q-1)z1,该数据报文2对应的数据长度为z1。
图6为服务器发送测速文件时涉及的一个示例性示意图。
下面结合图6详细描述前述步骤S109a-步骤S109c。
在一些可能的情况下,如图6所示,测速文件中包括多个字符,这里以字符的初始序列号为y1进行说明。
服务器可以Q路并发的向路由器发送数据报文(包括测速文件)。S109a-S109c描述了服务器向路由器Q路并发的发生数据报文的示例性过程。步骤S109a中的数据报文1可以如图6中所示,初始序列号(seq1)为y1,长度为z1。步骤S109b中的数据报文2可以如图6中所示,初始序列号(seq1)为y1+z1,长度为z1。步骤S109c中的数据报文Q可以如图6中所示,初始序列号(seq1)为y1+(q-1)z1,长度为z1,其中,Q为大于等于2的整数。
应该理解的是,其他数据报文(例如数据报文3-数据报文Q-1)这里可以参考前述描述,这里不再赘述。
S110.服务器向内核驱动层发送数据报文N,该数据报文N对应线程A,该数据报文N对应的序列号为y1+(N-1)z1,该数据报文1对应的数据长度为z1,该进程A为进程1-进程Q中的任一进程。
其中,N为大于等于2的整数。
服务器在Q路并发的完成数据报文的发送之后,可以继续Q路并发的发送数据报文。在接收到路由器断开连接的情况下,才停止发送测速文件。或者,在一定时间(例如5s)内没有接收到路由器发送的对应于数据报文的确认报文时,才停止发送测速文件。
关于步骤S110涉及的内容可以参考前述步骤中的相关描述,此处不再赘述。
应该理解的是,前述步骤S109a-步骤S109c以及步骤S110中,服务器除了可以发送数据报文(例如数据报文1-数据报文E中任一报文)对应的seq以外,还可以发送ack。该ack可以用于通知路由器:服务器接收到了路由器发送的报文。还可以发送其他的内容,本申请实施例对此不作限定。
内核驱动层基于接收到的报文B(数据报文1-数据报文N中的任一报文)时,如果确定该报文B对应的发送方的IP地址与通信四元组中记录的目的IP地址相同、报文B对应的发送方的端口号与信四元组中记录的目的端口相同、报文B对应的接收方的IP地址与通信四元组中记录的源IP地址相同,以及,报文B对应的接收方的端口号与通信四元组中记录的源端口号中人一个相同的情况下,则内核驱动层可以确定该报文B中包括服务器发送的测速文件。则终止向网络层传输该报文B。
在一些可能的情况下,内核驱动层可以在接收到该报文B之后,复制一份前述涉及的ACK报文-10,将其中的ack更新为该报文B对应的ack,或者,将其中的seq更新为该报文B对应的seq、ack更新为该报文B对应的ack。以生成该报文B对应的ACK报文A并从内核驱动层发送至服务器,以通知服务器:路由器接收到了该报文B。并重新计算该ACK报文A对应的IP报头(IPheader)的校验码(也可以称为IP校验码)以及TCP报头的(TCPheader)(也可以称为TCP校验码)的校验码。并将该重新计算的IP校验码以及TCP校验码发送至服务器。用于服务器基于该IP校验码以及TCP校验码确定该ACK报文A的正确性。在该情况下,内核驱动层接收到了多少个包括测速文件的数据报文,则发送多少个确认报文。一个数据报文对应一个确认报文。即,在接收到的数据报文包括数据报文1至数据报文N的情况下,内核驱动层向服务器分别发送确认报文1至确认报文N;其中,确认报文1至确认报文N中第j个确认报文为第j个数据报文对应的确认报文;第j个确认报文中包括的确认号为第j个数据报文的序列号加上第j个数据报文的长度;第j个确认报文用于确认路由器接收到了第j个数据报文。该第j个数据报文可以为数据报文1至数据报文N中的任一数据报文。
在另一些可能的情况下,内核驱动层可以在接收到N个数据报文(包括服务器发送的测速文件)之后,统一发送一个ACK报文B以通知服务器:接收到了发送的N个数据报文。对该过程的详细描述可以参考下述对步骤S114的描述,此处暂不赘述。
S111.内核驱动层计算前述数据报文1-数据报文E的累计数据大小,将该累计数据大小存储到预设文件中。
该数据报文1-数据报文E中包括至少一组数据报文,其中,一组数据报文中包括Q个数据报文(并发的)。
内核驱动层可以将该数据报文1-数据报文E存储到套接字缓存(socketbuffer)中。
然后统计该数据报文1-数据报文E的累计数据大小,将该累计数据大小存储到预设文件中。例如,该预设文件可以为/XXX/XXXX/stats文件中。
后续,应用层可以按照预设周期从预设文件中读取累计数据大小,应用层每取一次就将累计数据大小设置为0,并再次执行步骤S29继续计算后续数据报文的累计数据大小供应用层按照预设周期读取。
S112.应用层按照预设周期从预设文件中读取累计数据大小,确定下载速率。
应用层按照预设周期从内核驱动层的预设文件中获取累计数据大小;该预设周期可以为1s-5s等,例如1s。
应用层基于获取的累计数据大小,确定预设周期内获取的平均数据大小作为下载速率。例如,应用层计算连续在P个预设周期里获取累计数据大小,得到P个累计数据大小。再计算该P个累计数据大小的总和,然后将该总和与P的比值作为下载速率。
S113.将累计数据大小设置为0,并继续计算后续数据报文的累计数据大小,供应用层按照预设周期读取。
应用层可以按照预设周期从预设文件中读取累计数据大小,应用层每取一次就将累计数据大小设置为0,并再次执行步骤S29继续计算后续数据报文的累计数据大小供应用层按照预设周期读取。
S114.内核驱动层构造数据报文F-数据报文F+N-1对应的ACK报文,将其发送至服务器,以通知服务器已经接收到数据报文F-数据报文F+N-1。
在一些可能的情况下,N的取值可以为10。也可以为其他值,本申请实施例对此不作限定。这里以N=10为例进行说明。则数据报文F-数据报文F+N-1中共计10个报文。该步骤S114可以理解为内核驱动层每接收到10个数据报文,则发送一个确认报文,以通知服务器:接收到发送的该10个数据报文。
在一些可能的情况下,内核驱动层可以在接收到该10个数据报文之后,复制一份前述涉及的ACK报文-10,将其中的ack更新为该10个数报文(数据报文F-数据报文F+N-1)对应的ack(该ack等于数据报文F的初始序列号+该10个报文的长度),或者,将其中的seq更新为该10个数据报文对应的seq、ack更新为该10个数据报文对应的ack。以生成该10个数据报文对应的ACK报文B并从内核驱动层发送至服务器,以通知服务器:路由器接收到了该10个数据报文。并重新计算该ACK报文B对应的IP报头(IPheader)的校验码(也可以称为IP校验码)以及TCP报头的(TCPheader)(也可以称为TCP校验码)的校验码。并将该重新计算的IP校验码以及TCP校验码发送至服务器。用于服务器基于该IP校验码以及TCP校验码确定该ACK报文B的正确性。
应该理解的是,该步骤S114与步骤S111之间的执行顺序没有先后关系。
S115.路由器在确定下载速率之后,通过四次挥手与服务器断开连接。
首先,路由器向服务器发送结束(finish,FIN)报文10(FIN10),表示与服务器断开连接。
服务器接收到该FIN10之后,向路由器发送FIN10对应的确认报文(ACK),表示对FIN10的确认,并向路由器发送结束报文21(FIN21)。
然后,路由器接收到FIN21之后,向服务器发送该FIN21对应的确认报文(ACK),表示对FIN21的确认,完成四次挥手。此时,路由器与服务器即可断开连接。
本申请实施例中,报文ACK-10也可以被称为第一确认报文,序列号seq11也可以被称为第一序列号。数据报文1-数据报文N对应的ACK报文也可以被称为第二确认报文。
图7示出了方案1以及方案2中确定下载速度的性能比较图。
参考下述图7所述,图7中的(a)为方案1中服务器向路由器发送数据报文(包括了测速文件)的往返时间;图7中的(b)为方案2中服务器向路由器发送数据报文(包括了测速文件)的往返时间。其中,方案1位前述图1以及图2中涉及的方案,方案2位前述图3以及图4涉及的方案。服务器向路由器发送数据报文的往返时间描述了服务器发出该数据报文时到接收到路由器发送的该数据报文对应的确认报文的时间。
由图7可知,方案2中,路由器可以更快的结束到服务器发送的测速文件,则方案2中获取的下载速度不会偏小,相比于方案1更接近于真实值。
以上所述,以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。
上述实施例中所用,根据上下文,术语“当…时”可以被解释为意思是“如果…”或“在…后”或“响应于确定…”或“响应于检测到…”。类似地,根据上下文,短语“在确定…时”或“如果检测到(所陈述的条件或事件)”可以被解释为意思是“如果确定…”或“响应于确定…”或“在检测到(所陈述的条件或事件)时”或“响应于检测到(所陈述的条件或事件)”。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如DVD)、或者半导体介质(例如固态硬盘)等。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,该流程可以由计算机程序来指令相关的硬件完成,该程序可存储于计算机可读取存储介质中,该程序在执行时,可包括如上述各方法实施例的流程。而前述的存储介质包括:ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。

Claims (9)

1.一种路由器测速方法,其特征在于,适用于路由器,所述路由器包括应用层以及内核驱动层,所述方法包括:
所述应用层将Q个线程和所述Q个线程对应的通信四元组发送至所述内核驱动层;所述通信四元组包括所述路由器的IP地址、所述Q个线程对应的端口号、服务器的IP地址以及所述服务器的端口号;所述Q个线程是由所述应用层开启的,用于从所述服务器获取测速文件;
所述应用层通过所述内核驱动层向服务器发送第一确认报文;所述第一确认报文中至少包括所述路由器向所述服务器发送报文时的第一序列号;所述第一序列号为三次握手时,所述路由器向所述服务器发送报文时的初始序列号;
在所述第一确认报文到达所述内核驱动层之后,确定所述第一确认报文对应的发送方IP地址、发送方端口、接收方IP地址、接收方端口与所述通信四元组匹配时,所述内核驱动层截取所述第一确认报文;
所述内核驱动层基于所述第一确认报文以及所述通信四元组生成下载请求;所述下载请求对应的序列号为所述第一序列号,所述下载请求中携带了所述通信四元组;
所述内核驱动层向所述服务器发送所述下载请求,所述下载请求用于请求服务器Q路并发的向所述内核驱动层发送测速文件;
所述内核驱动层接收所述服务器发送的至少一组数据报文,任一组数据报文中包括Q个数据报文;
所述内核驱动层生成并向所述服务器发送所述至少一组数据报文对应的确认报文,以表示所述路由器接收到了所述至少一组数据报文;所述至少一组数据报文对应的确认报文是通过更新所述第一确认报文中的第一序列号为所述至少一组数据报文对应的序列号、以及更新所述第一确认报文中的确认号为所述至少一组数据报文对应的确认号;
所述内核驱动层计算接收到的数据报文的累计数据大小;所述累计数据大小是从0开始计算的;
所述应用层按照预设周期从所述内核驱动层获取所述累计数据大小;
所述应用层基于获取的所述累计数据大小,确定预设周期内获取的平均数据大小作为下载速率。
2.根据权利要求1所述的方法,其特征在于,所述应用层按照预设周期从所述内核驱动层获取所述累计数据大小之后,所述方法还包括:
所述内核驱动层将所述累计数据大小设置为0,且,所述内核驱动层重新计算接收到的数据报文的累计数据大小。
3.根据权利要求1所述的方法,其特征在于,所述至少一组数据报文中包括数据报文1-数据报文N,所述内核驱动层生成并向所述服务器发送所述至少一组数据报文对应的确认报文,具体包括:
所述内核驱动层向所述服务器发送第二确认报文;其中,所述第二确认报文包括第一确认号,所述第一确认号表示为所述数据报文1的序列号加上表示所述数据报文1-数据报文N的长度;所述第二确认报文用于确认所述路由器接收到了所述数据报文1-数据报文N;所述N为大于等于2的整数。
4.根据权利要求1所述的方法,其特征在于,所述至少一组数据报文中包括数据报文1-数据报文N,所述内核驱动层生成并向所述服务器发送所述至少一组数据报文对应的确认报文,具体包括:
所述内核驱动层向所述服务器分别发送确认报文1至确认报文N;其中,所述确认报文1至确认报文N中第j个确认报文为第j个数据报文对应的确认报文;所述第j个确认报文中包括的确认号为所述第j个数据报文的序列号加上所述第j个数据报文的长度;所述第j个确认报文用于确认所述路由器接收到了所述第j个数据报文。
5.根据权利要求1-3中任一项所述的方法,其特征在于,所述预设周期为1s。
6.根据权利要求5所述的方法,其特征在于,所述应用层基于获取的累计数据大小,确定预设周期内获取的平均数据大小作为下载速率,具体包括:
所述应用层计算连续获取的P个累计数据大小的总和;
所述应用层将所述总和与P的比值作为所述下载速率。
7.根据权利要求3或4所述的方法,其特征在于,所述N等于10。
8.根据权利要求1-4或6中任一项所述的方法,其特征在于,所述内核驱动层接收所述服务器发送的至少一组数据报文之后,所述内核驱动层计算接收到的数据报文的累计数据大小之前,所述方法还包括:
所述内核驱动层将所述至少一组数据报文存储在套接字缓存socketbuffer中。
9.一种路由器,其特征在于,所述路由器包括应用层以及内核驱动层,其中:
所述应用层用于,将Q个线程和所述Q个线程对应的通信四元组发送至所述内核驱动层;所述通信四元组包括所述路由器的IP地址、所述Q个线程对应的端口号、服务器的IP地址以及所述服务器的端口号;所述Q个线程是由所述应用层开启的,用于从所述服务器获取测速文件;
所述应用层还用于,通过所述内核驱动层向服务器发送第一确认报文;所述第一确认报文中至少包括所述路由器向所述服务器发送报文时的第一序列号;所述第一序列号为三次握手时,所述路由器向所述服务器发送报文时的初始序列号;
所述内核驱动层用于,在接收到所述第一确认报文之后,确定所述第一确认报文对应的发送方IP地址、发送方端口、接收方IP地址、接收方端口与所述通信四元组匹配时,截取所述第一确认报文;
所述内核驱动层还用于,基于所述第一确认报文以及所述通信四元组生成下载请求;所述下载请求对应的序列号为所述第一序列号,所述下载请求中携带了所述通信四元组;
所述内核驱动层还用于,向所述服务器发送所述下载请求,所述下载请求用于请求服务器Q路并发的向所述内核驱动层发送测速文件;
所述内核驱动层还用于,接收所述服务器发送的至少一组数据报文,任一组数据报文中包括Q个数据报文;
所述内核驱动层还用于,生成并向所述服务器发送所述至少一组数据报文对应的确认报文,以表示所述路由器接收到了所述至少一组数据报文;所述至少一组数据报文对应的确认报文是通过更新所述第一确认报文中的第一序列号为所述至少一组数据报文对应的序列号、以及更新所述第一确认报文中的确认号为所述至少一组数据报文对应的确认号;
所述内核驱动层还用于,计算接收到的数据报文的累计数据大小;所述累计数据大小是从0开始计算的;
所述应用层用于,按照预设周期从所述内核驱动层获取所述累计数据大小;
所述应用层还用于,基于获取的累计数据大小,确定预设周期内获取的平均数据大小作为下载速率。
CN202211168642.3A 2022-09-24 2022-09-24 路由器测速方法和路由器 Active CN116708247B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211168642.3A CN116708247B (zh) 2022-09-24 2022-09-24 路由器测速方法和路由器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211168642.3A CN116708247B (zh) 2022-09-24 2022-09-24 路由器测速方法和路由器

Publications (2)

Publication Number Publication Date
CN116708247A CN116708247A (zh) 2023-09-05
CN116708247B true CN116708247B (zh) 2024-05-17

Family

ID=87843971

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211168642.3A Active CN116708247B (zh) 2022-09-24 2022-09-24 路由器测速方法和路由器

Country Status (1)

Country Link
CN (1) CN116708247B (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106293963A (zh) * 2016-08-01 2017-01-04 北京金山安全管理系统技术有限公司 一种用于windows系统中应用层和驱动层通讯的方法及系统
CN106878107A (zh) * 2017-02-28 2017-06-20 无锡研勤信息科技有限公司 基于Linux内核驱动的网络带宽测速方法
CN107707422A (zh) * 2017-08-24 2018-02-16 四川天邑康和通信股份有限公司 基于onu驱动层快速ack回复的网络测速方法
CN108011781A (zh) * 2017-12-06 2018-05-08 上海市共进通信技术有限公司 基于Linux内核提高网络设备测试性能的方法
CN109842511A (zh) * 2017-11-28 2019-06-04 网宿科技股份有限公司 一种tcp性能参数的确定方法及系统
CN110958153A (zh) * 2019-11-01 2020-04-03 上海盈赞通信科技有限公司 网络传输速率检测系统、方法及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106293963A (zh) * 2016-08-01 2017-01-04 北京金山安全管理系统技术有限公司 一种用于windows系统中应用层和驱动层通讯的方法及系统
CN106878107A (zh) * 2017-02-28 2017-06-20 无锡研勤信息科技有限公司 基于Linux内核驱动的网络带宽测速方法
CN107707422A (zh) * 2017-08-24 2018-02-16 四川天邑康和通信股份有限公司 基于onu驱动层快速ack回复的网络测速方法
CN109842511A (zh) * 2017-11-28 2019-06-04 网宿科技股份有限公司 一种tcp性能参数的确定方法及系统
CN108011781A (zh) * 2017-12-06 2018-05-08 上海市共进通信技术有限公司 基于Linux内核提高网络设备测试性能的方法
CN110958153A (zh) * 2019-11-01 2020-04-03 上海盈赞通信科技有限公司 网络传输速率检测系统、方法及存储介质

Also Published As

Publication number Publication date
CN116708247A (zh) 2023-09-05

Similar Documents

Publication Publication Date Title
CN105634836B (zh) 信息处理方法及装置
US7764694B2 (en) System, method, and apparatus for prioritizing network traffic using deep packet inspection (DPI)
US20180343182A1 (en) Network traffic capture analysis
WO2017161760A1 (zh) 数据传输方法及装置
CN108234087B (zh) 数据传输方法及发送端
US20030108044A1 (en) Stateless TCP/IP protocol
CN113965482B (zh) 基于gRPC的数据传输方法、装置及存储介质
JP2001119434A (ja) ネットワークシステム
CN110072254B (zh) 一种数据的传输方法及其相关设备
CN107547505B (zh) 一种报文处理方法及装置
CN113872870A (zh) 控制网络拥塞的方法和相关装置
WO2020191864A1 (zh) 一种判断节点传输质量的方法、系统、装置及服务器
CN116708247B (zh) 路由器测速方法和路由器
CN109067922A (zh) 一种数据传输方法及装置
CN107104892A (zh) 网络加速的方法和装置
CN115002008B (zh) 一种网络时延测量的方法、装置、设备以及存储介质
CN114390054A (zh) 一种核心网网络加速方法、电子设备及计算机存储介质
CN115190070B (zh) 路由探测方法及装置
US7213074B2 (en) Method using receive and transmit protocol aware logic modules for confirming checksum values stored in network packet
CN110838967B (zh) 虚拟专用网络的连接方法、服务器、客户端和存储介质
WO2017067224A1 (zh) 一种报文处理方法及装置
CN110391991B (zh) 一种流量控制的方法及相关装置
US20240195720A1 (en) System and method for measuring and managing latency on a computer network
TWI846381B (zh) 電腦裝置以及應用於電腦裝置的傳輸控制協定封包處理方法
CN117792963A (zh) 测速方法及测速系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant