CN106452689A - 客户端和服务端的数据传输装置和方法 - Google Patents

客户端和服务端的数据传输装置和方法 Download PDF

Info

Publication number
CN106452689A
CN106452689A CN201611069048.3A CN201611069048A CN106452689A CN 106452689 A CN106452689 A CN 106452689A CN 201611069048 A CN201611069048 A CN 201611069048A CN 106452689 A CN106452689 A CN 106452689A
Authority
CN
China
Prior art keywords
data
client
service end
packets
response data
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.)
Pending
Application number
CN201611069048.3A
Other languages
English (en)
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.)
CHANJET INFORMATION TECHNOLOGY Co Ltd
Original Assignee
CHANJET INFORMATION TECHNOLOGY 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 CHANJET INFORMATION TECHNOLOGY Co Ltd filed Critical CHANJET INFORMATION TECHNOLOGY Co Ltd
Priority to CN201611069048.3A priority Critical patent/CN106452689A/zh
Publication of CN106452689A publication Critical patent/CN106452689A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/15—Setup of multiple wireless link connections
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Communication Control (AREA)

Abstract

本发明关于客户端和服务端的数据传输装置和方法，涉及互联网通信技术领域，其中，客户端数据传输装置包括：拆分单元，拆分HTTP请求，形成多个数据子包；协议单元，将多个数据子包通过UDP协议向服务端发送；分析单元，获取并汇总分析服务端传来的对应于各个数据子包的确收消息，查找出多个数据子包中的未确收数据子包；重发单元，重发未确收数据子包至服务端，直至确认服务端接收到全部数据子包；第一接收单元，接收服务端传来的HTTP回应数据。通过本发明的技术方案能够有效解决在移动网络下由于网路不稳定以及手机省电导致的请求网页过慢的问题。

Description

客户端和服务端的数据传输装置和方法
技术领域
本发明涉及互联网通信技术领域，具体而言，涉及客户端数据传输装置、客户端数据传输方法、服务端数据传输装置和服务端数据传输装方法。
背景技术
随着移动互联网的迅速发展，手机、平板等移动设备上的应用越来越丰富，大多数应用和服务器交互的方式是采用HTTP协议，现有的HTTP协议基本上是基于TCP实现的。由于移动网络的不稳定性(信号差、网络切换等)，导致网络延迟高、丢包率高，或者由于移动设备省电的原因需要暂时关闭应用，等到应用启动的时候需要重新建立连接，而TCP协议在这种网络不稳定和应用重新启动的情况下，数据传输速度比较慢，数据丢包率高，网络连接的重连速度较慢，表现为应用页面很长时间打不开或者打开的很慢。
因此，如何在网络不稳定的情况下提高数据的传输速度和可达率并提高网络的重连速度成为亟待解决的技术问题。
发明内容
本发明旨在至少解决上述现有技术或相关技术中存在的技术问题之一。
为此，本发明的一个目的在于提供了一种客户端数据传输装置。
本发明的另一个目的在于提供了一种服务端数据传输装置。
本发明的再一个目的在于提出了一种客户端数据传输方法。
本发明的再一个目的在于提出了一种服务端数据传输方法。
本发明的第一方面提供了一种客户端数据传输装置，包括：拆分单元，拆分客户端的HTTP请求，形成多个数据子包；协议单元，将多个数据子包通过UDP协议向服务端发送；分析单元，获取并汇总分析服务端传来的对应于各个数据子包的确收消息，查找出多个数据子包中的未确收数据子包；重发单元，重发未确收数据子包至服务端，直至确认服务端接收到全部数据子包；第一接收单元，接收服务端传来的HTTP回应数据。
根据本发明第一方面的客户端数据传输装置，对HTTP请求的数据包进行拆分形成数据子包再交给UDP传输，当其中一个数据子包丢失后，可以对其进行重发，而不用对整个HTTP请求数据包进行重发，提高了数据传输效率。由于UDP协议是一种不可靠的协议，也就是说发出去的数据是不是被对方收到是不能保证的，客户端对发送过的消息子包进行记录，当超过一定时间没有收到服务端的确认消息后进行重发，直至接收到服务端针对每一个数据子包都发回确收消息(可以允许一定误差)，保证了数据的完整性。服务端会将数据子包还原成的HTTP请求转发至HTTP服务器，同时转发HTTP服务器的回应数据，客户端接收服务端传来的HTTP回应数据，即基于UDP实现了HTTP传输层，在网络不稳定导致丢包率高的情况下，提高了数据的可达率，在网络不稳定导致延迟很高的情况下，提高了数据的传输速度。
在上述技术方案中，优选地，第一接收单元，具体用于：每次接收到服务端端发来的回应数据子包时，向服务端发送对应的确收消息，直至接收到全部回应数据子包，将接收到的回应数据子包还原为HTTP回应数据。
在该技术方案中，客户端针对服务端发来的每个回应数据子包向服务端发出确收消息，在一次回应数据流中，数据被分成多个回应数据子包，这些回应数据子包在被客户端全部接收到以后，进行还原，组合成为HTTP回应数据，以便应用层处理此HTTP回应数据。
在上述技术方案中，优选地，还包括：第一标记单元，在和服务端进行UDP通讯时生成唯一的连接ID，在每次进行数据发送时携带连接ID，以便服务端记录连接ID并关联客户端的IP和端口。
在该技术方案中，当客户端异常退出或者网络切换需要重新建立连接的时候，服务端可以根据所述连接ID知道是哪个客户端，而不用重新建立连接，同时客户端定期发送消息给服务端，服务端会更新客户端最新的IP和端口，这样的话即使客户端IP发生改变也不会影响次连接，HTTP服务器在此过程中通过服务端的转发得知客户端的状态。
在上述技术方案中，优选地，还包括：第一对接单元，在和服务端进行首次通讯时，携带连接ID信息、客户端的协议版本号信息、数据子包ID信息、数据子包个数信息、数据子包顺序号信息、数据子包类型信息，以便服务端接收并建立连接。
在该技术方案中，减少了类似TCP建立连接需要进行3次握手导致的连接建立耗时过长的问题，在网络不稳定导致重新建立连接的情况下，提高了网络连接的重连速度。
本发明的第二方面提供了一种服务端数据传输装置，包括：确收单元，每次接收到客户端发来的数据子包时，向客户端发送对应的确收消息，直至接收到全部数据子包；还原单元，将接收到的数据子包还原为HTTP请求；转发单元，将HTTP请求转发至HTTP服务器，其中，HTTP服务器根据HTTP请求发出HTTP回应数据；第二接收单元，接收HTTP服务器传回的HTTP回应数据；回应单元，将HTTP回应数据通过UDP协议发送至客户端。
根据本发明第二方面的服务端数据传输装置，服务端根据客户端发来的各个数据子包返回确收消息，确保数据子包能够被全部发送到位。待一个HTTP请求数据的全部数据子包全部被接收到以后，还原为HTTP请求数据，将此HTTP请求转发至HTTP服务器，HTTP服务器会根据HTTP请求发出HTTP回应数据，服务端在接收到HTTP服务器传回的HTTP回应数据之后，将HTTP回应数据通过UDP协议发送至客户端。其中，服务器针对客户端发送来的数据进行确收，服务端没有收到消息子包或者确认消息没有被客户端接收到时，也进行多次尝试重发，等服务端接收到到这次请求的所有消息子包全部达到，通知客户端。
在上述技术方案中，优选地，所述回应单元，具体用于：拆分HTTP回应数据，生成多个回应数据子包；将多个回应数据子包通过UDP协议向客户端发送；获取并汇总分析客户端传来的对应于各个回应数据子包的确收消息，查找出多个回应数据子包中的未确收回应数据子包；重发未确收回应数据子包至客户端，直至确认客户端接收到全部回应数据子包。
在该技术方案中，对HTTP回应数据包进行拆分形成回应数据子包再交给UDP传输，当其中一个回应数据子包丢失后，可以对其进行重发，而不用对整个HTTP回应数据包进行重发，提高了数据传输效率，保证了数据的完整性，在网络不稳定导致丢包率高的情况下，提高了数据的可达率，在网络不稳定导致延迟很高的情况下，提高了数据的传输速度。
在上述技术方案中，优选地，还包括：第二标记单元，在和客户端进行UDP通讯时生成唯一的连接ID并在每次进行数据发送时携带连接ID，以便客户端记录连接ID并关联服务端的IP和端口。
在该技术方案中，和对端(即客户端)采取相同的连接策略，当需要重新建立连接的时候，而不用重新建立连接，同时服务端定期发送消息给客户端，客户端会更新服务端最新的IP和端口，这样的话即使服务端IP发生改变也不会影响次连接。
在上述技术方案中，优选地，还包括：第二对接单元，在和客户端进行首次通讯时，携带连接ID信息、服务端的协议版本号信息、回应数据子包ID信息、回应数据子包个数信息、回应数据子包顺序号信息、回应数据子包类型信息，以便客户端接收并建立连接。
在该技术方案中，减少了类似TCP建立连接需要进行3次握手导致的连接建立耗时过长的问题，在网络不稳定导致重新建立连接的情况下，提高了网络连接的重连速度。
本发明的第三方面提供了一种客户端数据传输方法，包括：拆分客户端的HTTP请求，形成多个数据子包；将多个数据子包通过UDP协议向服务端发送；获取并汇总分析服务端传来的对应于各个数据子包的确收消息，查找出多个数据子包中的未确收数据子包；重发未确收数据子包至服务端，直至确认服务端接收到全部数据子包；接收服务端传来的HTTP回应数据。
根据本发明第三方面的客户端数据传输方法，对HTTP请求的数据包进行拆分形成数据子包再交给UDP传输，当其中一个数据子包丢失后，可以对其进行重发，而不用对整个HTTP请求数据包进行重发，提高了数据传输效率。由于UDP协议是一种不可靠的协议，也就是说发出去的数据是不是被对方收到是不能保证的，客户端对发送过的消息子包进行记录，当超过一定时间没有收到服务端的确认消息后进行重发，直至接收到服务端针对每一个数据子包都发回确收消息(可以允许一定误差)，保证了数据的完整性。服务端会将数据子包还原成的HTTP请求转发至HTTP服务器，同时转发HTTP服务器的回应数据，客户端接收服务端传来的HTTP回应数据，即基于UDP实现了HTTP传输层，在网络不稳定导致丢包率高的情况下，提高了数据的可达率，在网络不稳定导致延迟很高的情况下，提高了数据的传输速度。
在上述技术方案中，优选地，所述接收服务端传来的HTTP回应数据，具体包括：每次接收到服务端端发来的回应数据子包时，向服务端发送对应的确收消息，直至接收到全部回应数据子包，将接收到的回应数据子包还原为HTTP回应数据。
在该技术方案中，客户端针对服务端发来的每个回应数据子包向服务端发出确收消息，在一次回应数据流中，数据被分成多个回应数据子包，这些回应数据子包在被客户端全部接收到以后，进行还原，组合成为HTTP回应数据，以便应用层处理此HTTP回应数据。
在上述技术方案中，优选地，还包括：在和服务端进行UDP通讯时生成唯一的连接ID，在每次进行数据发送时携带连接ID，以便服务端记录连接ID并关联客户端的IP和端口。
在该技术方案中，当客户端异常退出或者网络切换需要重新建立连接的时候，服务端可以根据所述连接ID知道是哪个客户端，而不用重新建立连接，同时客户端定期发送消息给服务端，服务端会更新客户端最新的IP和端口，这样的话即使客户端IP发生改变也不会影响次连接，HTTP服务器在此过程中通过服务端的转发得知客户端的状态。
在上述技术方案中，优选地，还包括：在和服务端进行首次通讯时，携带连接ID信息、客户端的协议版本号信息、数据子包ID信息、数据子包个数信息、数据子包顺序号信息、数据子包类型信息，以便服务端接收并建立连接。
在该技术方案中，减少了类似tcp建立连接需要进行3次握手导致的连接建立耗时过长的问题，在网络不稳定导致重新建立连接的情况下，提高了网络连接的重连速度。
本发明的第四方面提供了一种服务端数据传输方法，包括：每次接收到客户端发来的数据子包时，向客户端发送对应的确收消息，直至接收到全部数据子包；将接收到的数据子包还原为HTTP请求；将HTTP请求转发至HTTP服务器，其中，HTTP服务器根据HTTP请求发出HTTP回应数据；接收HTTP服务器传回的HTTP回应数据；将HTTP回应数据通过UDP协议发送至客户端。
根据本发明第四方面的服务端数据传输方法，服务端根据客户端发来的各个数据子包返回确收消息，确保数据子包能够被全部发送到位。待一个HTTP请求数据的全部数据子包全部被接收到以后，还原为HTTP请求数据，将此HTTP请求转发至HTTP服务器，HTTP服务器会根据HTTP请求发出HTTP回应数据，服务端在接收到HTTP服务器传回的HTTP回应数据之后，将HTTP回应数据通过UDP协议发送至客户端。其中，服务器针对客户端发送来的数据进行确收，服务端没有收到消息子包或者确认消息没有被客户端接收到时，也进行多次尝试重发，等服务端接收到到这次请求的所有消息子包全部达到，通知客户端。
在上述技术方案中，优选地，所述将HTTP回应数据通过UDP协议发送至客户端，具体包括：拆分HTTP回应数据，生成多个回应数据子包；将多个回应数据子包通过UDP协议向客户端发送；获取并汇总分析客户端传来的对应于各个回应数据子包的确收消息，查找出多个回应数据子包中的未确收回应数据子包；重发未确收回应数据子包至客户端，直至确认客户端接收到全部回应数据子包。
在该技术方案中，对HTTP回应数据包进行拆分形成回应数据子包再交给UDP传输，当其中一个回应数据子包丢失后，可以对其进行重发，而不用对整个HTTP回应数据包进行重发，提高了数据传输效率，保证了数据的完整性，在网络不稳定导致丢包率高的情况下，提高了数据的可达率，在网络不稳定导致延迟很高的情况下，提高了数据的传输速度。
在上述技术方案中，优选地，还包括：在和客户端进行UDP通讯时生成唯一的连接ID并在每次进行数据发送时携带连接ID，以便客户端记录连接ID并关联服务端的IP和端口。
在该技术方案中，和对端(即客户端)采取相同的连接策略，当需要重新建立连接的时候，而不用重新建立连接，同时服务端定期发送消息给客户端，客户端会更新服务端最新的IP和端口，这样的话即使服务端IP发生改变也不会影响次连接。
在上述技术方案中，优选地，还包括：在和客户端进行首次通讯时，携带连接ID信息、服务端的协议版本号信息、回应数据子包ID信息、回应数据子包个数信息、回应数据子包顺序号信息、回应数据子包类型信息，以便客户端接收并建立连接。
在该技术方案中，减少了类似TCP建立连接需要进行3次握手导致的连接建立耗时过长的问题，在网络不稳定导致重新建立连接的情况下，提高了网络连接的重连速度。
通过本发明的技术方案，能够有效解决在移动网络下由于网路不稳定以及手机省电导致的请求网页过慢的问题。具体地，在网络不稳定导致丢包率高的情况下，提高数据的可达率，延迟很高的情况下，提高数据的传输速度，重新建立连接的情况下，提高连接建立的速度。
附图说明
图1示出了根据本发明第一方面实施例的客户端数据传输装置框图。
图2示出了根据本发明第二方面实施例的服务端数据传输装置框图。
图3示出了根据本发明第三方面实施例的客户端数据传输方法示意流程图。
图4示出了根据本发明第四方面实施例的服务端数据传输方法示意流程图。
图5和图6示出了根据本发明实施例的客户端与服务端的交互过程示意流程图。
具体实施方式
为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征能够相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还能够采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。
图1示出了根据本发明第一方面实施例的客户端数据传输装置框图。
如图1所示，本发明第一方面实施例提供了一种客户端数据传输装置100，包括：拆分单元102，拆分客户端的HTTP请求，形成多个数据子包；协议单元104，将多个数据子包通过UDP协议向服务端发送；分析单元106，获取并汇总分析服务端传来的对应于各个数据子包的确收消息，查找出多个数据子包中的未确收数据子包；重发单元108，重发未确收数据子包至服务端，直至确认服务端接收到全部数据子包；第一接收单元110，接收服务端传来的HTTP回应数据。
根据本发明第一方面实施例的客户端数据传输装置100，对HTTP请求的数据包进行拆分形成数据子包再交给UDP传输，当其中一个数据子包丢失后，可以对其进行重发，而不用对整个HTTP请求数据包进行重发，提高了数据传输效率。由于UDP协议是一种不可靠的协议，也就是说发出去的数据是不是被对方收到是不能保证的，客户端对发送过的消息子包进行记录，当超过一定时间没有收到服务端的确认消息后进行重发，直至接收到服务端针对每一个数据子包都发回确收消息(可以允许一定误差)，保证了数据的完整性。服务端会将数据子包还原成的HTTP请求转发至HTTP服务器，同时转发HTTP服务器的回应数据，客户端接收服务端传来的HTTP回应数据，即基于UDP实现了HTTP传输层，在网络不稳定导致丢包率高的情况下，提高了数据的可达率，在网络不稳定导致延迟很高的情况下，提高了数据的传输速度。
根据本发明第一方面实施例的客户端数据传输装置100，优选地，第一接收单元110，具体用于：每次接收到服务端端发来的回应数据子包时，向服务端发送对应的确收消息，直至接收到全部回应数据子包，将接收到的回应数据子包还原为HTTP回应数据。
在该实施例中，客户端针对服务端发来的每个回应数据子包向服务端发出确收消息，在一次回应数据流中，数据被分成多个回应数据子包，这些回应数据子包在被客户端全部接收到以后，进行还原，组合成为HTTP回应数据，以便应用层处理此HTTP回应数据。
根据本发明第一方面实施例的客户端数据传输装置100，优选地，还包括：第一标记单元112，在和服务端进行UDP通讯时生成唯一的连接ID，在每次进行数据发送时携带连接ID，以便服务端记录连接ID并关联客户端的IP和端口。
在该实施例中，当客户端异常退出或者网络切换需要重新建立连接的时候，服务端可以根据所述连接ID知道是哪个客户端，而不用重新建立连接，同时客户端定期发送消息给服务端，服务端会更新客户端最新的IP和端口，这样的话即使客户端IP发生改变也不会影响次连接，HTTP服务器在此过程中通过服务端的转发得知客户端的状态。
根据本发明第一方面实施例的客户端数据传输装置100，优选地，还包括：第一对接单元114，在和服务端进行首次通讯时，携带连接ID信息、客户端的协议版本号信息、数据子包ID信息、数据子包个数信息、数据子包顺序号信息、数据子包类型信息，以便服务端接收并建立连接。
在该实施例中，减少了类似TCP建立连接需要进行3次握手导致的连接建立耗时过长的问题，在网络不稳定导致重新建立连接的情况下，提高了网络连接的重连速度。
图2示出了根据本发明第二方面实施例的服务端数据传输装置框图。
如图2所示，本发明第二方面实施例提供了一种服务端数据传输装置200，包括：确收单元202，每次接收到客户端发来的数据子包时，向客户端发送对应的确收消息，直至接收到全部数据子包；还原单元204，将接收到的数据子包还原为HTTP请求；转发单元206，将HTTP请求转发至HTTP服务器，其中，HTTP服务器根据HTTP请求发出HTTP回应数据；第二接收单元208，接收HTTP服务器传回的HTTP回应数据；回应单元210，将HTTP回应数据通过UDP协议发送至客户端。
根据本发明第二方面实施例的服务端数据传输装置200，服务端根据客户端发来的各个数据子包返回确收消息，确保数据子包能够被全部发送到位。待一个HTTP请求数据的全部数据子包全部被接收到以后，还原为HTTP请求数据，将此HTTP请求转发至HTTP服务器，HTTP服务器会根据HTTP请求发出HTTP回应数据，服务端在接收到HTTP服务器传回的HTTP回应数据之后，将HTTP回应数据通过UDP协议发送至客户端。其中，服务器针对客户端发送来的数据进行确收，服务端没有收到消息子包或者确认消息没有被客户端接收到时，也进行多次尝试重发，等服务端接收到到这次请求的所有消息子包全部达到，通知客户端。
根据本发明第二方面实施例的服务端数据传输装置200，优选地，所述回应单元210，具体用于：拆分HTTP回应数据，生成多个回应数据子包；将多个回应数据子包通过UDP协议向客户端发送；获取并汇总分析客户端传来的对应于各个回应数据子包的确收消息，查找出多个回应数据子包中的未确收回应数据子包；重发未确收回应数据子包至客户端，直至确认客户端接收到全部回应数据子包。
在该实施例中，对HTTP回应数据包进行拆分形成回应数据子包再交给UDP传输，当其中一个回应数据子包丢失后，可以对其进行重发，而不用对整个HTTP回应数据包进行重发，提高了数据传输效率，保证了数据的完整性，在网络不稳定导致丢包率高的情况下，提高了数据的可达率，在网络不稳定导致延迟很高的情况下，提高了数据的传输速度。
根据本发明第二方面实施例的服务端数据传输装置200，优选地，还包括：第二标记单元212，在和客户端进行UDP通讯时生成唯一的连接ID并在每次进行数据发送时携带连接ID，以便客户端记录连接ID并关联服务端的IP和端口。
在该实施例中，和对端(即客户端)采取相同的连接策略，当需要重新建立连接的时候，而不用重新建立连接，同时服务端定期发送消息给客户端，客户端会更新服务端最新的IP和端口，这样的话即使服务端IP发生改变也不会影响次连接。
根据本发明第二方面实施例的服务端数据传输装置200，优选地，还包括：第二对接单元214，在和客户端进行首次通讯时，携带连接ID信息、服务端的协议版本号信息、回应数据子包ID信息、回应数据子包个数信息、回应数据子包顺序号信息、回应数据子包类型信息，以便客户端接收并建立连接。
在该实施例中，减少了类似TCP建立连接需要进行3次握手导致的连接建立耗时过长的问题，在网络不稳定导致重新建立连接的情况下，提高了网络连接的重连速度。
图3示出了根据本发明第三方面实施例的客户端数据传输方法示意流程图。
如图3所示，本发明的第三方面实施例提供了一种客户端数据传输方法，包括：步骤302，拆分客户端的HTTP请求，形成多个数据子包；步骤304，将多个数据子包通过UDP协议向服务端发送；步骤306，获取并汇总分析服务端传来的对应于各个数据子包的确收消息，查找出多个数据子包中的未确收数据子包；步骤308，重发未确收数据子包至服务端，直至确认服务端接收到全部数据子包；步骤310，接收服务端传来的HTTP回应数据。
根据本发明第三方面实施例的客户端数据传输方法，对HTTP请求的数据包进行拆分形成数据子包再交给UDP传输，当其中一个数据子包丢失后，可以对其进行重发，而不用对整个HTTP请求数据包进行重发，提高了数据传输效率。由于UDP协议是一种不可靠的协议，也就是说发出去的数据是不是被对方收到是不能保证的，客户端对发送过的消息子包进行记录，当超过一定时间没有收到服务端的确认消息后进行重发，直至接收到服务端针对每一个数据子包都发回确收消息(可以允许一定误差)，保证了数据的完整性。服务端会将数据子包还原成的HTTP请求转发至HTTP服务器，同时转发HTTP服务器的回应数据，客户端接收服务端传来的HTTP回应数据，即基于UDP实现了HTTP传输层，在网络不稳定导致丢包率高的情况下，提高了数据的可达率，在网络不稳定导致延迟很高的情况下，提高了数据的传输速度。
根据本发明第三方面实施例的客户端数据传输方法，优选地，所述步骤310具体包括：每次接收到服务端端发来的回应数据子包时，向服务端发送对应的确收消息，直至接收到全部回应数据子包，将接收到的回应数据子包还原为HTTP回应数据。
在该实施例中，客户端针对服务端发来的每个回应数据子包向服务端发出确收消息，在一次回应数据流中，数据被分成多个回应数据子包，这些回应数据子包在被客户端全部接收到以后，进行还原，组合成为HTTP回应数据，以便应用层处理此HTTP回应数据。
根据本发明第三方面实施例的客户端数据传输方法，优选地，还包括：在和服务端进行UDP通讯时生成唯一的连接ID，在每次进行数据发送时携带连接ID，以便服务端记录连接ID并关联客户端的IP和端口。
在该实施例中，当客户端异常退出或者网络切换需要重新建立连接的时候，服务端可以根据所述连接ID知道是哪个客户端，而不用重新建立连接，同时客户端定期发送消息给服务端，服务端会更新客户端最新的IP和端口，这样的话即使客户端IP发生改变也不会影响次连接，HTTP服务器在此过程中通过服务端的转发得知客户端的状态。
根据本发明第三方面实施例的客户端数据传输方法，优选地，还包括：在和服务端进行首次通讯时，携带连接ID信息、客户端的协议版本号信息、数据子包ID信息、数据子包个数信息、数据子包顺序号信息、数据子包类型信息，以便服务端接收并建立连接。
在该实施例中，减少了类似tcp建立连接需要进行3次握手导致的连接建立耗时过长的问题，在网络不稳定导致重新建立连接的情况下，提高了网络连接的重连速度。
图4示出了根据本发明第四方面实施例的服务端数据传输方法示意流程图。
如图4所示，本发明的第四方面实施例提供了一种服务端数据传输方法，包括：步骤402，每次接收到客户端发来的数据子包时，向客户端发送对应的确收消息，直至接收到全部数据子包；步骤404，将接收到的数据子包还原为HTTP请求；步骤406，将HTTP请求转发至HTTP服务器，其中，HTTP服务器根据HTTP请求发出HTTP回应数据；步骤408，接收HTTP服务器传回的HTTP回应数据；步骤410，将HTTP回应数据通过UDP协议发送至客户端。
根据本发明第四方面实施例的服务端数据传输方法，服务端根据客户端发来的各个数据子包返回确收消息，确保数据子包能够被全部发送到位。待一个HTTP请求数据的全部数据子包全部被接收到以后，还原为HTTP请求数据，将此HTTP请求转发至HTTP服务器，HTTP服务器会根据HTTP请求发出HTTP回应数据，服务端在接收到HTTP服务器传回的HTTP回应数据之后，将HTTP回应数据通过UDP协议发送至客户端。其中，服务器针对客户端发送来的数据进行确收，服务端没有收到消息子包或者确认消息没有被客户端接收到时，也进行多次尝试重发，等服务端接收到到这次请求的所有消息子包全部达到，通知客户端。
根据本发明第四方面实施例的服务端数据传输方法，优选地，所述步骤410具体包括：拆分HTTP回应数据，生成多个回应数据子包；将多个回应数据子包通过UDP协议向客户端发送；获取并汇总分析客户端传来的对应于各个回应数据子包的确收消息，查找出多个回应数据子包中的未确收回应数据子包；重发未确收回应数据子包至客户端，直至确认客户端接收到全部回应数据子包。
在该实施例中，对HTTP回应数据包进行拆分形成回应数据子包再交给UDP传输，当其中一个回应数据子包丢失后，可以对其进行重发，而不用对整个HTTP回应数据包进行重发，提高了数据传输效率，保证了数据的完整性，在网络不稳定导致丢包率高的情况下，提高了数据的可达率，在网络不稳定导致延迟很高的情况下，提高了数据的传输速度。
根据本发明第四方面实施例的服务端数据传输方法，优选地，还包括：在和客户端进行UDP通讯时生成唯一的连接ID并在每次进行数据发送时携带连接ID，以便客户端记录连接ID并关联服务端的IP和端口。
在该实施例中，和对端(即客户端)采取相同的连接策略，当需要重新建立连接的时候，而不用重新建立连接，同时服务端定期发送消息给客户端，客户端会更新服务端最新的IP和端口，这样的话即使服务端IP发生改变也不会影响次连接。
根据本发明第四方面实施例的服务端数据传输方法，优选地，还包括：在和客户端进行首次通讯时，携带连接ID信息、服务端的协议版本号信息、回应数据子包ID信息、回应数据子包个数信息、回应数据子包顺序号信息、回应数据子包类型信息，以便客户端接收并建立连接。
在该实施例中，减少了类似TCP建立连接需要进行3次握手导致的连接建立耗时过长的问题，在网络不稳定导致重新建立连接的情况下，提高了网络连接的重连速度。
图5和图6示出了根据本发明实施例的客户端与服务端的交互过程示意流程图。
一个完整的http请求和收到回应中间会经历一下几个对象：客户端应用、客户端协议层、服务端协议层、服务端应用层和http服务器，其中，服务端能够将客户端传来的数据转发到http服务器，具体地，服务端应用是对客户端来的请求向http服务器进行转发和接收来http服务器的回应并通过服务端协议层发给客户端协议层，http服务器就是传统意义的提供http服务的应用。从客户端发起http请求到收到http回应的流程如下：
客户端应用发起http请求；
客户端应用把http请求组装成字符流交给客户端协议层处理；
客户端协议层把请求的字符流发给服务器协议层；
服务器协议层收到客户端的请求并交给服务器应用处理；
服务器应用把收到的请求解析成http请求；
服务器应用根据http请求的域名向此域名发起http请求；
服务器应用收到此域名的回应；
服务器应用把收到的http回应组装成字符流交给服务器协议层处理；
服务器协议层把回应的字符流发给客户端协议层；
客户端协议层收到服务的回应的字符流；
客户端协议层把字符流组成一个完整的http回应交给客户端应用；
客户端应用收到http回应。
在客户端协议层和服务器协议层实现当中，如图5所示：
步骤502，对上层应用请求和回应的字符流进行拆分，形成一个个比较小的消息包(即数据子包)；
步骤504，接收端对接收到消息包进行确认，给发送端一个确认消息包(即确收消息)证明此消息包已经收到；
步骤506，发送端对发送过的消息包进行记录，当超过一定时间没有收到接收端的确认消息包后进行重发，确保接收端没有收到消息包或者确认包没有被发送端接收到，并且需要进行多次尝试重发；
步骤508，客户端协议层在和服务建立udp通讯时生成唯一的一个连接id，并在每次请求的时候携带此连接id，同时服务端会记录此连接id并关联客户端的ip和端口；
步骤510，客户端协议层和服务器协议层第一次建立连接的时候，会携带相关参数如连接id、客户端协议版本号等，如果服务器接收次连接，则连接建立成功，不用通知客户端，客户端可以直接发送后续消息。
另一方面，客户端协议层和服务端协议层交互过程如图6所示：
步骤602，客户端协议层对应用层的请求字符流进行拆分；
步骤604，对每个拆分的数据加上消息头如：协议序列号、连接id、消息类型、消息id、整个消息被拆分的个数、拆分的数据的顺序号，并发送给对端，同时记录此消息包，当在一定时间内没有收到接收端的确认包，则重新发送次消息包；
步骤606，服务端协议层收到客户端协议层发送消息包，立刻发送确认消息，告诉客户端协议层已经收到此消息，等到这次请求的所有消息包全部达到，告诉服务应用层；
步骤608，服务端协议层收到服务端应用层发送的回应，拆分数据包，对每个拆分的数据加上消息头如：协议序列号、连接id、消息类型、消息id、整个消息被拆分的个数、拆分的数据的顺序号，并发送给对端，同时记录此消息包，当在一定时间内没有收到接收端的确认包，则重新发送次消息包；
步骤610，客户端处理过程和服务端类似，最终等到回应的整个内容都到达，则告诉客户端应用层。
在该实施例中，根据步骤502或步骤602，由于网络设备支持的最大的ip包是有限制的，所以当数据比较大的时候udp协议会对数据进行拆分发送，等到达对端的时候再进行合并形成完整的消息，但是由于其中某个拆分的消息包丢失都会导致整个udp数据包丢失，所以在实现的时候，当传输数据大于ip包的限制的时候，在交给udp传输之前进行拆分形成一个个小的消息包再交给udp传输，当其中一个消息包丢失后，可以对此消息包进行重发，而不用对整个数据包进行重发。根据步骤506，当客户端异常退出或者网络切换重新和服务器通讯的时候，服务端可以根据此连接id知道是哪个客户端，而不用重新建立连接，同时客户端定期发送消息给服务器，服务器会更新客户端最新的ip和端口，这样的话即使客户端ip发生改变也不会影响次连接。根据步骤508或步骤604，减少了类似tcp建立连接需要进行3次握手导致的连接建立耗时过长。
以上结合附图详细说明了本发明的技术方案，通过本发明的技术方案，能够有效解决在移动网络下由于网路不稳定以及手机省电导致的请求网页过慢的问题。具体地，在网络不稳定导致丢包率高的情况下，提高数据的可达率，延迟很高的情况下，提高数据的传输速度，重新建立连接的情况下，提高连接建立的速度。
本发明实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减，本发明实施例装置和终端中的单元可以根据实际需要进行合并、划分和删减。以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (16)

1.一种客户端数据传输装置，其特征在于，包括：
拆分单元，拆分HTTP请求，形成多个数据子包；
协议单元，将所述多个数据子包通过UDP协议向服务端发送；
分析单元，获取并汇总分析所述服务端传来的对应于各个数据子包的确收消息，查找出所述多个数据子包中的未确收数据子包；
重发单元，重发所述未确收数据子包至所述服务端，直至确认所述服务端接收到全部数据子包；
第一接收单元，接收所述服务端传来的HTTP回应数据。
2.根据权利要求1所述的客户端数据传输装置，其特征在于，所述第一接收单元，具体用于：
每次接收到所述服务端端发来的回应数据子包时，向所述服务端发送对应的确收消息，直至接收到全部回应数据子包，将接收到的回应数据子包还原为HTTP回应数据。
3.根据权利要求2所述的客户端数据传输装置，其特征在于，还包括：
第一标记单元，在和所述服务端进行UDP通讯时生成唯一的连接ID，在每次进行数据发送时携带所述连接ID，以便所述服务端记录所述连接ID并关联所述客户端的IP和端口。
4.根据权利要求3所述的客户端数据传输装置，其特征在于，还包括：
第一对接单元，在和所述服务端进行首次通讯时，携带所述连接ID信息、所述客户端的协议版本号信息、数据子包ID信息、数据子包个数信息、数据子包顺序号信息、数据子包类型信息，以便所述服务端接收并建立连接。
5.一种服务端数据传输装置，其特征在于，包括：
确收单元，每次接收到客户端发来的数据子包时，向所述客户端发送对应的确收消息，直至接收到全部数据子包；
还原单元，将接收到的数据子包还原为HTTP请求；
转发单元，将所述HTTP请求转发至HTTP服务器，其中，所述HTTP服务器根据所述HTTP请求发出HTTP回应数据；
第二接收单元，接收所述HTTP服务器传回的所述HTTP回应数据；
回应单元，将所述HTTP回应数据通过UDP协议发送至所述客户端。
6.根据权利要求5所述的服务端数据传输装置，其特征在于，所述回应单元，具体用于：
拆分所述HTTP回应数据，生成多个回应数据子包；
将所述多个回应数据子包通过UDP协议向客户端发送；
获取并汇总分析所述客户端传来的对应于各个回应数据子包的确收消息，查找出所述多个回应数据子包中的未确收回应数据子包；
重发所述未确收回应数据子包至所述客户端，直至确认所述客户端接收到全部回应数据子包。
7.根据权利要求6所述的服务端数据传输装置，其特征在于，还包括：
第二标记单元，在和所述客户端进行UDP通讯时生成唯一的连接ID并在每次进行数据发送时携带所述连接ID，以便所述客户端记录所述连接ID并关联所述服务端的IP和端口。
8.根据权利要求7所述的服务端数据传输装置，其特征在于，还包括：
第二对接单元，在和所述客户端进行首次通讯时，携带所述连接ID信息、所述服务端的协议版本号信息、回应数据子包ID信息、回应数据子包个数信息、回应数据子包顺序号信息、回应数据子包类型信息，以便所述客户端接收并建立连接。
9.一种客户端数据传输方法，其特征在于，包括：
拆分HTTP请求，形成多个数据子包；
将所述多个数据子包通过UDP协议向服务端发送；
获取并汇总分析所述服务端传来的对应于各个数据子包的确收消息，查找出所述多个数据子包中的未确收数据子包；
重发所述未确收数据子包至所述服务端，直至确认所述服务端接收到全部数据子包；
接收所述服务端传来的HTTP回应数据。
10.根据权利要求9所述的客户端数据传输方法，其特征在于，所述接收所述服务端传来的HTTP回应数据，具体包括：
每次接收到所述服务端端发来的回应数据子包时，向所述服务端发送对应的确收消息，直至接收到全部回应数据子包，将接收到的回应数据子包还原为HTTP回应数据。
11.根据权利要求10所述的客户端数据传输方法，其特征在于，还包括：
在和所述服务端进行UDP通讯时生成唯一的连接ID，在每次进行数据发送时携带所述连接ID，以便所述服务端记录所述连接ID并关联所述客户端的IP和端口。
12.根据权利要求11所述的客户端数据传输方法，其特征在于，还包括：
在和所述服务端进行首次通讯时，携带所述连接ID信息、所述客户端的协议版本号信息、数据子包ID信息、数据子包个数信息、数据子包顺序号信息、数据子包类型信息，以便所述服务端接收并建立连接。
13.一种服务端数据传输方法，其特征在于，包括：
每次接收到客户端发来的数据子包时，向所述客户端发送对应的确收消息，直至接收到全部数据子包；
将接收到的数据子包还原为HTTP请求；
将所述HTTP请求转发至HTTP服务器，其中，所述HTTP服务器根据所述HTTP请求发出HTTP回应数据；
接收所述HTTP服务器传回的所述HTTP回应数据；
将所述HTTP回应数据通过UDP协议发送至所述客户端。
14.根据权利要求13所述的服务端数据传输方法，其特征在于，所述将所述HTTP回应数据通过UDP协议发送至所述客户端，具体包括：
拆分所述HTTP回应数据，生成多个回应数据子包；
将所述多个回应数据子包通过UDP协议向客户端发送；
获取并汇总分析所述客户端传来的对应于各个回应数据子包的确收消息，查找出所述多个回应数据子包中的未确收回应数据子包；
重发所述未确收回应数据子包至所述客户端，直至确认所述客户端接收到全部回应数据子包。
15.根据权利要求14所述的服务端数据传输方法，其特征在于，还包括：
在和所述客户端进行UDP通讯时生成唯一的连接ID并在每次进行数据发送时携带所述连接ID，以便所述客户端记录所述连接ID并关联所述服务端的IP和端口。
16.根据权利要求15所述的服务端数据传输方法，其特征在于，还包括：
在和所述客户端进行首次通讯时，携带所述连接ID信息、所述服务端的协议版本号信息、回应数据子包ID信息、回应数据子包个数信息、回应数据子包顺序号信息、回应数据子包类型信息，以便所述客户端接收并建立连接。
CN201611069048.3A 2016-11-28 2016-11-28 客户端和服务端的数据传输装置和方法 Pending CN106452689A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201611069048.3A CN106452689A (zh) 2016-11-28 2016-11-28 客户端和服务端的数据传输装置和方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201611069048.3A CN106452689A (zh) 2016-11-28 2016-11-28 客户端和服务端的数据传输装置和方法

Publications (1)

Publication Number Publication Date
CN106452689A true CN106452689A (zh) 2017-02-22

Family

ID=58219802

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201611069048.3A Pending CN106452689A (zh) 2016-11-28 2016-11-28 客户端和服务端的数据传输装置和方法

Country Status (1)

Country Link
CN (1) CN106452689A (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110995784A (zh) * 2019-11-05 2020-04-10 北京奇艺世纪科技有限公司 数据传输方法、系统及存储介质
CN111787541A (zh) * 2020-07-30 2020-10-16 杭州妙联物联网技术有限公司 一种基于多子包独立记录的无线设备快速配网方法及系统
CN114143291A (zh) * 2021-11-18 2022-03-04 广西北投信创科技投资集团有限公司 一种基于tcp和udp的http通信方法及其系统
WO2022110229A1 (zh) * 2020-11-30 2022-06-02 北京小米移动软件有限公司 数据丢失检测方法、装置、通信设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101729593A (zh) * 2008-11-03 2010-06-09 北大方正集团有限公司 一种上传和接收文件的方法、系统及装置
CN101951370A (zh) * 2010-09-17 2011-01-19 北京神州泰岳软件股份有限公司 基于udp的文件可靠传输方法
CN103973421A (zh) * 2013-02-06 2014-08-06 腾讯科技（深圳）有限公司 文件传送方法及装置
CN105100140A (zh) * 2014-05-04 2015-11-25 腾讯科技（深圳）有限公司 文件传输方法和系统
CN105337935A (zh) * 2014-07-09 2016-02-17 阿里巴巴集团控股有限公司 一种建立客户端和服务端长连接的方法和装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101729593A (zh) * 2008-11-03 2010-06-09 北大方正集团有限公司 一种上传和接收文件的方法、系统及装置
CN101951370A (zh) * 2010-09-17 2011-01-19 北京神州泰岳软件股份有限公司 基于udp的文件可靠传输方法
CN103973421A (zh) * 2013-02-06 2014-08-06 腾讯科技（深圳）有限公司 文件传送方法及装置
CN105100140A (zh) * 2014-05-04 2015-11-25 腾讯科技（深圳）有限公司 文件传输方法和系统
CN105337935A (zh) * 2014-07-09 2016-02-17 阿里巴巴集团控股有限公司 一种建立客户端和服务端长连接的方法和装置

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110995784A (zh) * 2019-11-05 2020-04-10 北京奇艺世纪科技有限公司 数据传输方法、系统及存储介质
CN110995784B (zh) * 2019-11-05 2022-05-10 北京奇艺世纪科技有限公司 数据传输方法、系统及存储介质
CN111787541A (zh) * 2020-07-30 2020-10-16 杭州妙联物联网技术有限公司 一种基于多子包独立记录的无线设备快速配网方法及系统
WO2022110229A1 (zh) * 2020-11-30 2022-06-02 北京小米移动软件有限公司 数据丢失检测方法、装置、通信设备及存储介质
CN114143291A (zh) * 2021-11-18 2022-03-04 广西北投信创科技投资集团有限公司 一种基于tcp和udp的http通信方法及其系统

Similar Documents

Publication Publication Date Title
CN107104936B (zh) 建立全双工双向通信的方法和系统
US9319439B2 (en) Secured wireless session initiate framework
KR100498932B1 (ko) 이동 노드들로 구성된 무선망에서의 세션 설정 장치 및 방법
CN106452689A (zh) 客户端和服务端的数据传输装置和方法
CN104243267B (zh) 数据传输方法及装置
US20100158026A1 (en) Transparent Interaction with multi-layer protocols via Selective Bridging and Proxying
US20110252152A1 (en) Reliable messaging system and method
WO2006133651A1 (en) Communication method between communication devices and communication apparatus
US11088957B2 (en) Handling of data packet transfer via a proxy
CN111224999A (zh) 一种传输协议切换方法、装置、设备及存储介质
TW200926721A (en) Method and apparatus for enhancing various PDCP and layer 2 operations
CN104767722B (zh) 会话的管理方法、策略服务器及应用功能装置
CN106254410A (zh) 网络系统及建立数据连接的方法
CN115002023B (zh) 一种链路聚合方法、链路聚合装置、电子设备及存储介质
CN109104744A (zh) 利用wifi管理帧的数据发送、接收以及通信方法
CN102769520A (zh) 基于sctp协议的无线网络拥塞控制方法
CN103516573B (zh) 受限网络中客户端之间的数据传输方法和客户端
Ohta Performance comparisons of transport protocols for session initiation protocol signaling
CN109450991A (zh) 基于移动应用的数据传输加速方法、相关设备和加速系统
CN107104892A (zh) 网络加速的方法和装置
CN105897452A (zh) 一种数据重传方法及装置
CN115883478B (zh) 一种多标识网络体系中安全高效的传输控制方法及系统
CN106130746A (zh) 一种数据传输方法及装置
Cisco Timer and Retry Enhancements for L2TP and L2F
JP4285101B2 (ja) リアルタイムデータ通信システム、リアルタイムデータ通信装置およびリアルタイムデータ通信方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20170222

RJ01 Rejection of invention patent application after publication