CN114500487A

CN114500487A - End-to-end hypertext transfer protocol conversion system

Info

Publication number: CN114500487A
Application number: CN202111345927.5A
Authority: CN
Inventors: 梁铭俊
Original assignee: Guangzhou Founder Technology Co ltd
Current assignee: Guangzhou Founder Technology Co ltd
Priority date: 2021-11-15
Filing date: 2021-11-15
Publication date: 2022-05-13

Abstract

The invention discloses an end-to-end hypertext transfer protocol conversion system, wherein a standard Http address is input at a client of a terminal, so that the capability of accessing local or any remote file or streaming media can be realized, and the method is detailed in a specific embodiment of a specification; the method solves the problem that the existing Http protocol has no communication technology for directly completing end-to-end access and transmission by utilizing an end-to-end protocol; the system can realize the capability of accessing, downloading and transmitting the files stored on the client B by accessing the Http Url address of the Host on the browser of the client A.

Description

End-to-end hypertext transfer protocol conversion system

Technical Field

The invention relates to the technical field of text transfer protocols, in particular to an end-to-end hypertext transfer protocol conversion system.

Background

Since 1991 the IETF organization released the 0.9 version of the Http protocol, which became the supporting protocol for the WWW. After release 1.0 in 1996 and release 1.1 in 1997 and 1.1 (still the most popular current release) in 1997, the HTTP/2 protocol was proposed and the performance was greatly improved in 2015. However, referring back to HTTP/2, while HTTP/2 solves a large number of disadvantages in HTTP/1, the main feature is the use of multiplexing (multiplexing) so that it can send multiple logical data streams over the same TCP connection, this technological improvement leads to better congestion control, more efficient bandwidth utilization, longer TCP connections-all better than before, and easier full-speed transmission over the link. Header compression techniques also reduce the amount of bandwidth used. However, the TCP protocol stack is realized by the kernel of the operating system, and the problems of TCP head of queue blocking and data flow congestion cannot be solved by adopting HTTP/2 realized by the TCP protocol. In addition, with the explosive growth and large-scale popularization of mobile communication technology, HTTP/2 is not satisfactory in performance indexes such as weak network environment resistance and network jitter resistance.

The invention fully considers the defect problem of the existing Http protocol and the development direction of the next generation Http protocol, and provides an end-to-end hypertext transfer protocol conversion system. The invention is different from the conventional Http proxy in that a connectionless UDP protocol is adopted in a transmission layer, the end-to-end file breakpoint continuous transmission capability is realized on the basis of UDP, and the invention has the characteristics of mobile network change and jitter resistance and higher network robustness than the traditional Http proxy.

Disclosure of Invention

The invention aims to provide an end-to-end hypertext transfer protocol conversion system, which solves the problem that the existing Http protocol has no way to directly finish the communication technology of end-to-end access and transmission by utilizing the end-to-end protocol; the system can realize the capability of accessing, downloading and transmitting the files stored on the client B by accessing the Http Url address of the Host on the browser of the client A.

In order to solve the technical problems, the technical scheme of the invention is as follows:

an end-to-end hypertext transfer protocol conversion system, which can realize the ability of accessing local or any remote file or stream media by inputting a standard Http address at the client of a terminal, such as a browser, the method comprises the following steps:

A. the client A provides the implementation of a local Http Server, and the Http Server monitors URI access pointing to a Localhost initiated from any Http client of the local Server. Meanwhile, the client A accesses the unique ID of the client A to the Http remote service management platform by using a long connection technology.

B. The client B also provides an implementation of a local Http Server, which listens for URI accesses directed to Localhost initiated from any Http client of the local. Meanwhile, the client A accesses the unique ID of the client A to the Http remote service management platform by using a long connection technology.

C. The local Http Server contains a plurality of processors for Path parts in the URI, and the processors can process specific paths of local or remote, such as/origin represents local resource access and/remote represents remote resource.

D. A certain Http application (such as a browser) of the client a initiates URI access of a Localhost, and if the requested Path contains a local resource Path, the Http Server can analyze an absolute Path or a relative Path of a suffix according to the Path and output the suffix in the Http file stream form.

E. An Http application (such as a browser) of the client a initiates a URI access of a Localhost, and if the requested Path contains a remote resource Path, the Http Server can forward a P2P connection instruction to the target ID by using the Http remote service management platform according to the remote ID parsed from the Path, and initiate a P2P connection. And then the channel of the P2P is used as a transmission source of the Http file stream to provide output for Http applications (such as a browser). For example, Path of URI contains: the client side A calls a P2P connection signaling to a management platform, the management platform sends the signaling to the B, the B starts a P2P communication module to carry out end-to-end encryption communication with the A, the P2P communication module of the A packages the data into a file stream service after receiving the data and provides the file stream service for the Http Server, and the capability of directly accessing the file on the client side B by the client side A through the Http protocol is realized.

The invention has the beneficial effects that:

the method can realize the capability of accessing any remote file and playing the streaming media by any client supporting the Http standard on the user terminal by transmitting a standard Http address without the participation of a central server.

Drawings

FIG. 1 is a networking diagram of an end-to-end HTTP conversion system of the present invention;

fig. 2 is a flowchart illustrating Http protocol conversion apparatus Http service transmission according to the present invention.

Detailed Description

The following further describes embodiments of the present invention with reference to the drawings. It should be noted that the description of the embodiments is provided to help understanding of the present invention, but the present invention is not limited thereto. In addition, the technical features involved in the embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other.

As shown in fig. 1 and 2, an end-to-end Http conversion system, which inputs a standard Http address at a client of a terminal, such as a browser, can implement the capability of accessing local or any remote file or streaming media, includes the following steps:

A. the client A provides the implementation of a local Http Server, and the Http Server monitors URI access pointing to Localhost initiated from any Http client of the local machine. Meanwhile, the client A accesses the unique ID of the client A to the Http remote service management platform by using a long connection technology.

E. A certain Http application (such as a browser) of the client a initiates a URI access of a Localhost, and if the requested Path contains a remote resource Path, the Http Server can relay a P2P connection instruction to a target ID by using a Http remote service management platform according to a remote ID parsed from the Path, and initiate a P2P connection. And then the channel of the P2P is used as a transmission source of the Http file stream to provide output for Http applications (such as a browser). For example, Path of URI contains: the client side A calls a P2P connection signaling to a management platform, the management platform sends the signaling to the B, the B starts a P2P communication module to carry out end-to-end encryption communication with the A, the P2P communication module of the A packages the data into a file stream service after receiving the data and provides the file stream service for the Http Server, and the capability of directly accessing the file on the client side B by the client side A through the Http protocol is realized.

Since the client a and the client B need to establish peer-to-peer network transmission, an Http remote service management platform needs to be introduced for managing device unique IDs, offline states, and the like of the client a and the client B. But finally the transmission of Http stream does not require the intervention of the service management platform. The service management platform functions similarly to DNS, only to find peers and to pass P2P "handshake" signaling.

The specific embodiment is as follows:

step 401: the client a has an application program supporting the Http protocol, and the program may be a browser, an Http streaming media player, or the like.

Step 402: a Url address is input in an Http application program on a client A, the Host of the address is Localhost or 127.0.0.1, a port is set for an Http Server program, and the Path part of the address comprises an agreed Path for distinguishing a local Path address or a remote Path address.

Step 403: a local Http proxy exists on the client a, and is configured to listen to a specific port, and to process the address transmitted in step 402, filter different paths, and perform processing using different service adapters.

Step 404: the Http Server program determines whether the requested address is a local resource address or a remote resource address.

Step 405: and if the Http Server program judges that the address is the local resource address, starting a local file stream analysis service adapter program, analyzing a local file path from the transmitted parameter part of Url, and reading the file.

Step 406: the local file reading module replies the file reading state and the file stream to the file stream service program in the step 405, the program packages the file stream into an Http protocol by adopting a zero copy technology and replies the Http protocol to the Http Server, and the Http Server replies the Http protocol to the client. If the file does not exist, the step returns an error status code such as Http 404.

Step 407: when the Http Server program judges that the remote resource address is the remote resource address, the client ID where the remote file is located and the remote file path are resolved from the parameter part of the incoming Url. For example, if the parsed ID is the remote ID of the client B, the Http remote service management platform sends a connection instruction of P2P to the client B, where the connection instruction includes the unique ID of the client a and information of the remote file that the client B wants to access.

Step 408: the Http remote service management platform sends an instruction to the client B, and determines whether the connection of the P2P can be successfully established according to the reply of the client B, the failure is directly returned to 404, and if the instruction transmission is successful, the client a starts a remote P2P file stream parsing service adapter program.

Step 409: the remote file stream parsing service adapter starts a P2P end-to-end connection module, completes end-to-end connection with the client B, and obtains a data transmission handle of P2P.

Step 410: since the P2P data transfer handle is a two-way handle, client A can initiate the file stream reception service to receive the P2P file stream.

Step 411: the client B has the same P2P data transmission handle, and starts the file stream transmission service program to transmit the P2P file stream.

Step 412: the real remote file on client B will be encapsulated into a file stream in the P2P protocol format required in step 411.

Step 413: together,

steps

410, 411, 412 constitute a typical RPC call pattern. The remote file stream parsing service adapter in step 409 is used as a Client to read the file stream from the end-to-end transmission system formed by 413, and the file stream is encapsulated into an Http protocol by adopting a zero copy technology and is replied to the Http Server, and the Http Server replies to the Client.

The embodiments of the present invention have been described in detail with reference to the accompanying drawings, but the present invention is not limited to the described embodiments. It will be apparent to those skilled in the art that various changes, modifications, substitutions and alterations can be made in these embodiments without departing from the principles and spirit of the invention, and the scope of the invention is to be accorded the full scope of the claims.

Claims

1. An end-to-end hypertext transfer protocol conversion system, comprising: inputting a standard Http address at a client of a terminal to realize the ability of accessing local or any remote file or streaming media, the method comprises the following steps:

A. the client A provides the realization of a local Http Server, and the Http Server monitors URI access which is initiated from any Http client of the local machine and points to Localhost; meanwhile, the client A accesses the unique ID of the client A to the Http remote service management platform by using a long connection technology;

B. the client B also provides the realization of a local Http Server, and the Http Server monitors URI access which is initiated from any Http client of the local machine and points to Localhost; meanwhile, the client A accesses the unique ID of the client A to the Http remote service management platform by using a long connection technology;

C. the local Http Server comprises a plurality of processors aiming at the Path part in the URI, wherein the processors can process specific paths of local or remote ends, wherein/origin represents accessed local resources, and/remote represents remote resources;

D. a certain Http application of the client a initiates URI access of a Localhost, and if the requested Path contains a local resource Path, the Http Server can analyze an absolute Path or a relative Path of a suffix according to the Path and output the suffix outwards in the form of Http file stream;

E. a certain Http application of the client a initiates URI access of a Localhost, and if the requested Path contains a remote resource Path, the Http Server can relay a P2P connection instruction to a target ID by using a Http remote service management platform according to the remote ID parsed from the Path, and initiate P2P connection; and then, the channel of the P2P is used as a transmission source of the Http file stream to provide output for Http application.

2. The end-to-end hypertext transfer protocol conversion apparatus or system of claim 1 wherein: because the client A and the client B need to establish peer-to-peer network transmission, an Http remote service management platform needs to be introduced for managing the device unique IDs of the client A and the client B and the offline state; but finally, the transmission of the Http stream does not need the intervention of the service management platform; the service management platform functions similarly to DNS for finding peers and passing P2P "handshake" signaling.

3. The end-to-end hypertext transfer protocol conversion device or system of claim 2 wherein: the implementation steps are as follows:

step 401: the client A is provided with an application program supporting an Http protocol, and the application program is a browser and Http streaming media player program;

step 402: inputting a Url address in an Http application program on a client A, wherein the Host of the address is Localhost or 127.0.0.1, the port sets a port for an Http Server program, and the Path part of the address comprises an agreed Path for distinguishing a local or remote Path address;

step 403: a local Http proxy exists on the client a, and is used for monitoring the port, processing the address transmitted in the step 402, filtering different paths, and processing the paths by adopting different service adaptation programs;

step 404: the Http Server program judges whether the requested address is a local resource address or a remote resource address;

step 405: if the Http Server program judges that the address is the local resource address, starting a local file stream analysis service adapter program, analyzing a local file path from the transmitted parameter part of Url, and reading the file;

step 406: the local file reading module replies the file reading state and the file stream to the file stream service program in the step 405, the program packages the file stream into an Http protocol by adopting a zero copy technology and replies to the Http Server, and the Http Server replies to the client; if the file does not exist, returning an Http 404 error status code;

step 407: when the Http Server program judges that the remote resource address is the remote resource address, the client ID where the remote file is located and a remote file path are resolved from the parameter part transmitted into Url;

step 408: the Http remote service management platform sends an instruction to the client B, and judges whether the connection of the P2P can be successfully established according to the reply of the client B, if the connection fails, the Http remote service management platform directly returns to 404, and if the instruction is successfully transmitted, the client a starts a remote P2P file stream parsing service adapter;

step 409: the remote file stream analysis service adapter program starts a P2P end-to-end connection module, completes end-to-end connection with the client B and obtains a data transmission handle of P2P;

step 410: since the P2P data transmission handle is a bidirectional handle, the client A can start the file stream receiving service program to receive the P2P file stream;

step 411: the client B has the same P2P data transmission handle, and starts a file stream sending service program to send the P2P file stream;

4. The end-to-end hypertext transfer protocol conversion device or system of claim 3 wherein: the steps 410, 411, 412 together constitute a typical RPC call pattern; the remote file stream parsing service adapter in step 409 is used as a Client to read the file stream from the end-to-end transmission system formed by 413, and the file stream is encapsulated into an Http protocol by adopting a zero copy technology and is replied to the Http Server, and the Http Server replies to the Client.