WO2019200630A1 - 一种流媒体资源的传输方法及系统 - Google Patents

一种流媒体资源的传输方法及系统 Download PDF

Info

Publication number
WO2019200630A1
WO2019200630A1 PCT/CN2018/086180 CN2018086180W WO2019200630A1 WO 2019200630 A1 WO2019200630 A1 WO 2019200630A1 CN 2018086180 W CN2018086180 W CN 2018086180W WO 2019200630 A1 WO2019200630 A1 WO 2019200630A1
Authority
WO
WIPO (PCT)
Prior art keywords
streaming media
request
response
media resource
resource
Prior art date
Application number
PCT/CN2018/086180
Other languages
English (en)
French (fr)
Inventor
邹爽
吕士表
Original Assignee
网宿科技股份有限公司
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 网宿科技股份有限公司 filed Critical 网宿科技股份有限公司
Priority to EP18869461.6A priority Critical patent/EP3576371B1/en
Priority to US16/099,850 priority patent/US20210227034A1/en
Publication of WO2019200630A1 publication Critical patent/WO2019200630A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1023—Server selection for load balancing based on a hash applied to IP addresses or costs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/288—Distributed intermediate devices, i.e. intermediate devices for interaction with other intermediate devices on the same level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams

Definitions

  • the present invention relates to the field of Internet technologies, and in particular, to a method and system for transmitting streaming media resources.
  • WebRTC Web Real-Time Communication
  • a point-to-point communication link can usually be established between user A and user B.
  • the specific process can include the following multiple steps:
  • Step 1 User A initiates a query to the P2P server to obtain its own public network address.
  • Step 2 User A generates an Offer SDP according to the streaming media information collected by the user, and sends the Offer SDP to the user B through the signaling server.
  • Step 3 User B accepts and processes the Offer SDP, and generates an Answer SDP according to the streaming media information collected by the hardware, and sends the Answer SDP to the user A through the signaling server transfer;
  • Step 4 User B initiates a query to the P2P server to obtain its own public network address.
  • Step 5 User A generates an ICE Candidate according to its public network address, and transmits it to User B through the signaling server.
  • Step 6 User B generates ICE Candidate according to its public network address, and transmits it to User A through the signaling server.
  • Step 7 Both user A and user B can send their own streaming media to the other party according to the exchanged SDP and ICE Candidate, and receive the streaming media sent by the other party.
  • WebRTC provides a peer-to-peer communication method.
  • the establishment of this communication method requires a complicated process, and at the same time, this communication method is incompatible with many current network architectures.
  • CDN Content Delivery Network
  • RTMP Real Time Messaging Protocol
  • HTTP HyperText Transfer Protocol
  • the purpose of the application is to provide a method and system for transmitting streaming media resources, which can improve the transmission efficiency of streaming media resources.
  • the present application provides a method for transmitting a streaming media resource, where the method includes: receiving a processing request from a client to a target streaming media resource, and scheduling the processing request to a first process. Determining whether the processing request is processed by the first process, and if not, forwarding the processing request to a second process in a hierarchy in which the first process is located; determining whether the processing is performed by the second process Processing a request, if yes, constructing, by the second process, a response request corresponding to the processing request, where the response request includes an access address generated by the second process for accessing the target streaming media resource; Responding to the request to the first process, and feeding back the response request to the client by the first process, so that a connection is established between the client and the second process, and the established The connection transmits the target streaming media resource.
  • another aspect of the present application further provides a transmission system for streaming media resources, where the system includes a client and an edge node, where: the client is configured to send a target streaming media resource to the edge node. Processing the request; the edge node is configured to schedule the processing request to the first process; determine whether the processing request is processed by the first process, and if not, forward the processing request to the first process a second process in the hierarchy; determining whether the processing request is processed by the second process, and if yes, constructing, by the second process, a response request corresponding to the processing request, where the response request includes the An access address generated by the second process for accessing the target streaming media resource; feeding the response request to the first process, and feeding back the response request to the client by using the first process, to Causing a connection between the client and the second process, and transmitting the target streaming media resource through the established connection.
  • the HTTP protocol and the WebRTC protocol can be integrated, which simplifies the establishment process of the communication connection and can also adapt to the routing and forwarding regulations in the CDN.
  • Multiple levels may be included in the CDN, such as an access layer (edge node), a relay layer (parent node), a core layer (source node), and the like. Routing or forwarding processes are usually involved within or between levels. Specifically, when the first process in a certain level receives the processing request sent by the client, according to the routing rule in the CDN, it can be determined whether the processing request should be processed by the first process, and if not, according to the routing rule. The processing request is forwarded to the second process of the same level.
  • the second process may construct a response request for the processing request, where the response request may include an ICE candidate generated by the second process, and the ICE candidate may serve as an access address of the access target streaming media resource.
  • a WebRTC communication connection can be established between the client and the second process, and the client can upload the streaming media resource to the second process or obtain the flow from the second process. media resources.
  • the processing request may be sent to the third process in the next level.
  • the third process can construct the response request in a similar manner, except that the response request contains the access address generated by the third process.
  • the second process can rewrite the access address therein as its own access address, and the response request rewriting the access address is fed back to the client through the first process.
  • the client and the second process, and the second process and the third process can respectively establish a WebRTC connection, so that the streaming media resource can be transmitted. It can be seen that the technical solution provided by the present application can effectively combine the WebRTC standard with the CDN, and can not only utilize the fast distribution function of the CDN, but also realize the low delay function of the WebRTC, thereby improving the transmission efficiency of the streaming media resource.
  • FIG. 1 is a schematic diagram of interaction of a standard WebRTC process in the prior art
  • FIG. 2 is a flowchart of a method for transmitting a streaming media resource according to an embodiment of the present invention
  • FIG. 3 is a schematic diagram of interaction of a method for transmitting a streaming media resource according to an embodiment of the present invention
  • FIG. 4 is a schematic diagram of interaction of a method for uploading streaming media resources in an embodiment of the present invention
  • FIG. 5 is a schematic diagram of interaction of a method for downloading streaming media resources according to an embodiment of the present invention.
  • FIG. 6 is a flowchart of a method for transmitting a streaming media resource according to an embodiment of the present invention
  • FIG. 7 is a schematic diagram of a transmission application scenario of a streaming media resource in an embodiment of the present invention.
  • FIG. 8 is a schematic structural diagram of a computer terminal according to an embodiment of the present invention.
  • the present application provides a method for transmitting a streaming media resource, and the method can be applied to a CDN.
  • the method may include the following steps.
  • S1 Receive a processing request sent by the client to the target streaming media resource, and schedule the processing request to the first process.
  • the processing request may be sent to the target streaming media resource, where the processing request may include a resource acquisition request and a resource upload request.
  • each of the streaming media resources may have a unique identifier, and the naming rule of the unique identifier may not be limited, as long as the corresponding streaming media resource can be uniquely characterized.
  • the unique identifier may be a Uniform Resource Locator (URL).
  • the naming rule of the uniform resource locator may be combined with RTMP (Real Time Messaging Protocol).
  • RTMP Real Time Messaging Protocol
  • the URL naming rules of streaming media resources in HTTP are the same. For example, the URL of a streaming resource can be http://www.a.com/live/test.
  • the processing request sent by the client may be an HTTP POST request or an HTTP GET request.
  • the processing request may be received by a load balancing server in the CDN and distributed to one of the edge nodes by the load balancing server.
  • the load balancing server may distribute the processing request according to a preset load balancing policy. For example, the processing request can be scheduled to the edge server where the current load is minimal.
  • the received request is usually processed by a process, and therefore, the processing request can be scheduled to the first process in the edge server.
  • S3 determining whether the processing request is processed by the first process, and if not, forwarding the processing request to a second process in a hierarchy where the first process is located.
  • the CDN can have a certain routing rule, which can define which process in which level the processing request sent by the client should be processed.
  • the first process may determine, according to the routing rule, whether the processing request should be processed by itself.
  • the representation form of the routing rule may be different for different processing requests.
  • the routing rule may be: determining whether the target streaming media resource is included in the local resource associated with the first process, and if yes, determining that the processing request is processed by the first process If not, it may be determined that the processing request is not processed by the first process.
  • the routing rule may be expressed as: calculating a hash value corresponding to the unique identifier according to the unique identifier of the target streaming media resource included in the resource uploading request.
  • a hash algorithm may be used to calculate a hash value of the URL of the target streaming media resource, and the calculated hash value may be the above hash value.
  • each process may be associated with a certain number of hash values in advance, so that after the uniquely identified hash value is calculated, it may be determined whether the process associated with the hash value is the first process. If it is indicated that the hash value is indicative of the first process, then it may be determined that the processing request is processed by the first process, and if not, indicating that the hash value represents not the first process, then it may be determined that the processing is not The first process processes the processing request.
  • the processing request may be forwarded to a second process in the same level according to a routing rule.
  • S5 determining whether the processing request is processed by the second process, and if yes, constructing, by the second process, a response request corresponding to the processing request, where the response request includes the second process generated for accessing The access address of the target streaming media resource.
  • the second process may also determine whether the processing request is to be processed by itself according to the routing rule. If the routing rule indicates that the second process still cannot process the processing request, it indicates that the process at the tier cannot process the request. In this case, the request can be forwarded to another tier. For example, a client in Shanghai initiates a request to download a streaming resource, which is dispatched by the load balancing server to the idle first process in the edge node. By calculating the hash value corresponding to the request, it indicates that the request should actually be processed by the second process in the edge node, so the processing request can be forwarded to the second process.
  • the request can be sent to another process in the core layer, and the request is processed by a process in the core layer.
  • the second process may attempt to establish a WebRTC communication connection with the client, and then the target streaming media resource may be transmitted through the established WebRTC communication connection.
  • the process of establishing a WebRTC communication connection may be different for different processing requests.
  • the client when the client needs to upload the target streaming media resource to the second process, the resource upload request may be initiated.
  • the client can first generate an Offer SDP based on the streaming media information collected by its own hardware.
  • the Offer SDP information such as a video encoding mode supported by the client, an audio encoding mode, and whether the audio and video are encrypted may be included.
  • a simple example of the Offer SDP can be as follows:
  • Video coding can use H264, VP8, VP9;
  • Audio coding can use AAC, MP3, OPUS;
  • Encryption can be enabled
  • the generated Offer SDP can be the candidate streaming information described above.
  • the resource upload request sent by the client may be, for example, an HTTP POST request.
  • the request message body of the request may be the Offer SDP described above, so that the resource upload request may include candidate streaming media information supported by the client.
  • the second process may extract the included candidate streaming media information from the second process. Then, the second process may determine, according to its own hardware condition, the target video coding mode and the target audio coding mode supported by the candidate, and construct a response flow based on the target video coding mode and the target audio coding mode.
  • Media information For example, the second process may determine that the target streaming media resource that the client is ready to upload is currently received, and the video encoding mode is H264, the audio encoding mode is OPUS, and the target streaming media resource may be encrypted.
  • an example of the response streaming media information generated by the second process, Answer SDP can be as follows:
  • ICE candidate information in addition to the SDP information, ICE candidate information is required, and the ICE candidate information may be constructed based on the public network IP address.
  • the second process can obtain its own public network IP address and port address, and the public network IP address can be stored in the edge server where the second process is located, without being read from other servers. Then, the second process may use the combination of the public network IP address and the port address as an access address for accessing the target streaming media resource.
  • the public network IP address may be 10.8.114.195
  • the port address for receiving the streaming media resource may be 54225
  • the finally generated access address may be 10.8.114.195:54225.
  • the access address can be used as the ICE candidate described above. In this way, the second process can obtain the response stream information (Answer SDP) and the ICE candidate required to establish a WebRTC communication connection.
  • the second process may construct a response message in response to the received resource upload request.
  • the response message may be an HTTP response message with a status code of 200.
  • the response stream message body and the access address may be included in the response message body of the response message.
  • the processing request may be a resource acquisition request, and the client may download the target streaming media resource by initiating the resource acquisition request.
  • the resource acquisition request may be, for example, an HTTP GET request.
  • the URL of the request may be a unique identifier of the target streaming resource.
  • the second process may determine the target streaming media resource that the client wants to download from the associated local resource according to the unique identifier carried by the second process. At this time, the second process can obtain its own public network IP address and port address, and the public network IP address can be stored in the edge server where the second process is located, without being read from other servers.
  • the second process may use the combination of the public network IP address and the port address as an access address for accessing the target streaming media resource.
  • the public network IP address may be 10.8.114.195
  • the port address for transmitting the streaming media resource may be 54225
  • the finally generated access address may be 10.8.114.195:54225.
  • This access address can be used as the ICE candidate required to establish a WebRTC communication connection.
  • the streaming media resource in the local resource associated with the second process may be uploaded by another client, and after the client uploads the streaming media resource, the second process may use the streaming media resource and the corresponding response flow.
  • Media information associated storage may query the response stream media information associated with the target streaming media resource according to the unique identifier of the target streaming media resource, and use the response streaming media information as the target streaming media information associated with the target streaming media resource.
  • the second process can use the target streaming media information as an Offer SDP.
  • the second process generates the Offer SDP and the ICE candidate.
  • the second process may construct a response message, which may be, for example, an HTTP response message with a status code of 200.
  • the response message body of the response message may include the above-mentioned access address (ICE candidate) and target streaming media information (Offer SDP) associated with the target streaming media resource.
  • the response request may be fed back to the first process, and the first process may continue to forward the response request to the client.
  • a WebRTC communication connection can be established between the client and the second process.
  • the target streaming media resource may be transmitted between the client and the second process through the established WebRTC communication connection.
  • the client may process the target streaming media resource according to the response streaming media information, and upload the processed target flow to the second process according to the access address. media resources.
  • the client may download the target streaming media resource through the access address, and process the downloaded target streaming media resource by using the target streaming media information.
  • the processing request may be forwarded to another level of the load balancing server according to the routing rule.
  • another level of load balancing server can schedule the processing request to the third process.
  • the first process and the second process are at the same level, while the third process is at a different level.
  • the third process may also determine whether it can process the request according to the routing rule. If possible, the third process may construct a response request corresponding to the processing request.
  • the manner of constructing the response request is similar to the above manner, and different response requests can be constructed for different processing requests.
  • the processing request includes a resource uploading request
  • the resource uploading request may include candidate streaming media information supported by the client.
  • the third process constructs the response request corresponding to the processing request
  • the response streaming media information may be generated based on the candidate streaming media information and its own hardware condition.
  • the third process can obtain its own public network IP address and port address, and use the combination of the public network IP address and the port address as an access address for accessing the target streaming media resource.
  • the third process can construct a response request and use the response streaming media information and the access address as a response message body of the response request.
  • the resource acquisition request may include a unique identifier of the target streaming media resource.
  • the third process when constructing the response request corresponding to the processing request, may acquire the target streaming media information associated with the unique identifier, and at the same time, obtain the public IP address and port address of the public network, and The combination of the public network IP address and the port address is used as an access address for accessing the target streaming media resource. In this way, the third process may construct a response request, and use the target streaming media information and the access address as a response message body of the response request.
  • the constructed response request may be fed back to the second process.
  • the response request received by the second process includes SDP information and an ICE candidate, so the second process can establish a WebRTC communication connection with the third process.
  • the second process may obtain its own public network IP address and port address, and combine the public network IP address and the port address as the first The access address generated by the second process. Then, the second process may rewrite the access address in the response request constructed by the third process to the access address generated by the second process, and feed back a response request that rewrites the access address to the client.
  • the response request received by the client includes the SDP information and the ICE candidate of the second process, so the client can establish a WebRTC communication connection with the second process. In this way, the target streaming media resource can be transmitted through a connection established between the client and the second process and a connection established between the second process and the third process.
  • the client may process the target streaming media resource according to the response streaming media information, and upload the processed to the second process according to the access address generated by the second process.
  • Target streaming resources The second process may associate the processed target streaming media resource and the response streaming media information, and upload the processed target streaming media resource to the access address generated by the third process to The third process.
  • the third process may store the processed target streaming media resource and the response streaming media information in association.
  • the resources associated with the second process and the third process may each include the target streaming media resource of the upload.
  • the second process may first download the target streaming media resource from the third process according to the access address generated by the third process, and download the target streaming media resource. And stored in association with the target streaming media information. Then, the client may download the target streaming media resource from the second process according to the access address generated by the second process, thereby completing the resource downloading process.
  • the third process may also be unable to process the processing request.
  • the processing request may be further forwarded to the fourth process at the same level as the third process.
  • the processing request sent by the client sequentially goes through the edge server 2 (first process) and the edge server 3 (second process) in the edge node, and then After the central server 1 (third process) is again experienced in the central node, the central server 2 (fourth process) capable of processing the request is reached.
  • the fourth process may construct a response request corresponding to the processing request according to the foregoing manner, where the response request includes the fourth process generated by the fourth process for accessing the target streaming media resource.
  • the response request constructed by the fourth process may be fed back to the second process by the third process, so that the second process establishes a connection with the fourth process.
  • the second process may rewrite the access address in the response request constructed by the fourth process to the access address generated by the second process, and feed back a response request that rewrites the access address to the client. Soing that the client establishes a connection with the second process. In this way, the target streaming media resource can be transmitted through a connection established between the client and the second process and a connection established between the second process and the fourth process.
  • the application also provides a transmission system for streaming media resources, the system comprising a client and an edge node, wherein:
  • the client is configured to send a processing request to the edge node to the target streaming media resource
  • the edge node is configured to schedule the processing request to a first process; determine whether the processing request is processed by the first process, and if not, forward the processing request to a level in which the first process is located a second process of determining whether the processing request is processed by the second process, and if yes, constructing, by the second process, a response request corresponding to the processing request, where the response request includes the second process generated by the second process An access address for accessing the target streaming media resource; feeding the response request to the first process, and feeding back the response request to the client by using the first process, so that the client Establishing a connection between the terminal and the second process, and transmitting the target streaming media resource through the established connection.
  • system further includes a central node, where the central node includes at least a third process, and the third process is configured to receive the scheduled when the second process cannot process the processing request.
  • the response request includes an access address generated by the third process for accessing the target streaming media resource, and a response request of the third process is fed back to the second process, so that The second process establishes a connection with the third process;
  • the second process is further configured to rewrite an access address in the response request constructed by the third process to an access address generated by the second process, and feed back a response request that rewrites the access address to the a client to cause the client to establish a connection with the second process.
  • the central node further includes a fourth process, where the fourth process is configured to receive, when the third process cannot process the processing request, receive the forwarding from the third process.
  • the response request includes an access address generated by the fourth process for accessing the target streaming media resource, and the response request constructed by the fourth process is fed back to the first a second process, so that the second process establishes a connection with the fourth process;
  • the second process is further configured to rewrite an access address in the response request constructed by the fourth process to an access address generated by the second process, and feed back a response request that rewrites the access address to the a client to cause the client to establish a connection with the second process.
  • Computer terminal 10 may include one or more (only one of which is shown) processor 102 (processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA), for storing data.
  • processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA), for storing data.
  • FIG. 8 is merely illustrative and does not limit the structure of the above electronic device.
  • computer terminal 10 may also include more or fewer components than shown in FIG. 8, or have a different configuration than that shown in FIG.
  • the memory 104 can be used to store software programs and modules of application software, and the processor 102 executes various functional applications and data processing by running software programs and modules stored in the memory 104.
  • Memory 104 may include high speed random access memory and may also include non-volatile memory such as one or more magnetic storage devices, flash memory, or other non-volatile solid state memory.
  • memory 104 may further include memory remotely located relative to processor 102, which may be coupled to computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
  • Transmission device 106 is for receiving or transmitting data via a network.
  • the network specific examples described above may include a wireless network provided by a communication provider of the computer terminal 10.
  • the transmission device 106 includes a Network Interface Controller (NIC) that can be connected to other network devices through a base station to communicate with the Internet.
  • the transmission device 106 can be a Radio Frequency (RF) module for communicating with the Internet wirelessly.
  • NIC Network Interface Controller
  • RF Radio Frequency
  • the HTTP protocol and the WebRTC protocol can be integrated, which simplifies the establishment process of the communication connection and can also adapt to the routing and forwarding regulations in the CDN.
  • Multiple levels may be included in the CDN, such as an access layer (edge node), a relay layer (parent node), a core layer (source node), and the like. Routing or forwarding processes are usually involved within or between levels. Specifically, when the first process in a certain level receives the processing request sent by the client, according to the routing rule in the CDN, it can be determined whether the processing request should be processed by the first process, and if not, the routing rule can be followed. The processing request is forwarded to the second process of the same level.
  • the second process may construct a response request for the processing request, where the response request may include an ICE candidate generated by the second process, and the ICE candidate may serve as an access address of the access target streaming media resource.
  • a WebRTC communication connection can be established between the client and the second process, and the client can upload the streaming media resource to the second process or obtain the flow from the second process. media resources.
  • the processing request may be sent to the third process in the next level.
  • the third process can construct the response request in a similar manner, except that the response request contains the access address generated by the third process.
  • the second process can rewrite the access address therein as its own access address, and the response request rewriting the access address is fed back to the client through the first process.
  • the client and the second process, and the second process and the third process can respectively establish a WebRTC connection, so that the streaming media resource can be transmitted. It can be seen that the technical solution provided by the present application can effectively combine the WebRTC standard with the CDN, and can not only utilize the fast distribution function of the CDN, but also realize the low delay function of the WebRTC, thereby improving the transmission efficiency of the streaming media resource.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种流媒体资源的传输方法及系统，其中，所述方法包括：接收客户端发来的指向目标流媒体资源的处理请求，并将所述处理请求调度至第一进程；将所述处理请求转发至所述第一进程所处层级中的第二进程；通过所述第二进程构建所述处理请求对应的响应请求，所述响应请求中包括所述第二进程生成的用于访问所述目标流媒体资源的访问地址；将所述响应请求反馈给所述第一进程，并通过所述第一进程将所述响应请求反馈给所述客户端，以使得所述客户端与所述第二进程之间建立连接，并通过建立的所述连接传输所述目标流媒体资源。本申请提供的技术方案，能够提高流媒体资源的传输效率。

Description

一种流媒体资源的传输方法及系统 技术领域
本发明涉及互联网技术领域，特别涉及一种流媒体资源的传输方法及系统。
背景技术
WebRTC(Web Real-Time Communication，源自网页实时通信)协议由于具有跨平台、高实时性的特点，被广泛用于基于网络的视频会议、视频通话等应用场景。
请参阅图1，标准的WebRTC协议中，通常可以在用户A和用户B之间建立点对点的通信链路。具体的过程可以包括以下多个步骤：
步骤1：用户A向P2P服务器发起查询，获得自己的公网地址；
步骤2：用户A根据自身的硬件采集到的流媒体信息，生成Offer SDP，通过信令服务器中转，将Offer SDP发送给用户B；
步骤3：用户B接受并处理Offer SDP，同时根据自身的硬件采集到的流媒体信息，生成Answer SDP，通过信令服务器中转，将Answer SDP发送给用户A；
步骤4：用户B向P2P服务器发起查询，获得自己的公网地址。
步骤5：用户A根据自身的公网地址生成ICE Candidate，通过信令服务器中转，发送给用户B。
步骤6：用户B根据自身的公网地址生成ICE Candidate，通过信令服务器中转，发送给用户A。
步骤7：用户A和用户B双方根据交换的SDP和ICE Candidate，从而可以发送自身的流媒体给对方，同时接收对方发送来的流媒体。
由上可见，WebRTC提供的是一种点对点的通信方式，建立该通信方式需要经过复杂的流程，同时，这种通信方式与当前的许多网络架构无法兼容。例如，在内容分发网络(Content Delivery Network，CDN)中通常是基于RTMP(Real Time Messaging Protocol，实时消息传输协议)和HTTP(HyperText Transfer Protocol，超文本传输协议)通信的。为了使得大量的终端设备能够在较低的 延时下观看流媒体资源，目前亟需一种将WebRTC标准应用在CDN中的技术，以提高流媒体资源的传输效率。
发明内容
本申请的目的在于提供一种流媒体资源的传输方法及系统，能够提高流媒体资源的传输效率。
为实现上述目的，本申请一方面提供一种流媒体资源的传输方法，所述方法包括：接收客户端发来的指向目标流媒体资源的处理请求，并将所述处理请求调度至第一进程；判断是否由所述第一进程处理所述处理请求，若否，将所述处理请求转发至所述第一进程所处层级中的第二进程；判断是否由所述第二进程处理所述处理请求，若是，通过所述第二进程构建所述处理请求对应的响应请求，所述响应请求中包括所述第二进程生成的用于访问所述目标流媒体资源的访问地址；将所述响应请求反馈给所述第一进程，并通过所述第一进程将所述响应请求反馈给所述客户端，以使得所述客户端与所述第二进程之间建立连接，并通过建立的所述连接传输所述目标流媒体资源。
为实现上述目的，本申请另一方面还提供一种流媒体资源的传输系统，所述系统包括客户端和边缘节点，其中：所述客户端用于向所述边缘节点发送指向目标流媒体资源的处理请求；所述边缘节点用于将所述处理请求调度至第一进程；判断是否由所述第一进程处理所述处理请求，若否，将所述处理请求转发至所述第一进程所处层级中的第二进程；判断是否由所述第二进程处理所述处理请求，若是，通过所述第二进程构建所述处理请求对应的响应请求，所述响应请求中包括所述第二进程生成的用于访问所述目标流媒体资源的访问地址；将所述响应请求反馈给所述第一进程，并通过所述第一进程将所述响应请求反馈给所述客户端，以使得所述客户端与所述第二进程之间建立连接，并通过建立的所述连接传输所述目标流媒体资源。
由上可见，本申请提供的技术方案中，可以将HTTP协议和WebRTC协议进行融合，一方面简化了通信连接的建立过程，同时还能适应CDN中的路由和转发规定。在CDN中可以包括多个层级，例如接入层(边缘节点)、中转层(父节点)、核心层(源节点)等。在层级内部或者层级之间，通常会涉及路由和转发的过程。具体地，当某个层级中的第一进程接收到客户端发来的处理请求后， 根据CDN中的路由规则，可以判断该处理请求是否应该由第一进程处理，若不是，可以按照路由规则，将该处理请求转发至同一层级的第二进程。第二进程可以构建该处理请求的响应请求，在该响应请求中，可以包括第二进程生成的ICE candidate，该ICE candidate可以作为访问目标流媒体资源的访问地址。该响应请求通过第一进程反馈至客户端之后，在客户端与第二进程之间可以建立WebRTC通信连接，客户端从而可以将流媒体资源上传至第二进程，或者从第二进程处获取流媒体资源。此外，若第二进程依然无法处理该处理请求，可以将该处理请求发送至下一层级中的第三进程。第三进程可以按照类似的方式构建响应请求，只不过该响应请求中包含的是第三进程生成的访问地址。该响应请求被反馈至第二进程之后，第二进程可以将其中的访问地址改写为自身的访问地址，并将改写了访问地址的响应请求通过第一进程反馈至客户端。这样，客户端与第二进程，以及第二进程与第三进程之间可以分别建立WebRTC连接，从而可以传输流媒体资源。由上可见，本申请提供的技术方案，能够将WebRTC标准与CDN进行有效结合，既能够发挥CDN的快速分发功能，又能够实现WebRTC的低延时功能，从而能够提高流媒体资源的传输效率。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是现有技术中标准WebRTC流程的交互示意图；
图2是本发明实施例中流媒体资源的传输方法流程图；
图3是本发明实施例中流媒体资源的传输方法交互示意图；
图4是本发明实施例中流媒体资源的上传方法交互示意图；
图5是本发明实施例中流媒体资源的下载方法交互示意图；
图6是本发明实施例中流媒体资源的传输方法流程图；
图7是本发明实施例中流媒体资源的传输应用场景示意图；
图8是本发明实施例中计算机终端的结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。
实施例一
本申请提供一种流媒体资源的传输方法，所述方法可以应用于CDN中，请参阅图2和图3，所述方法可以包括以下步骤。
S1：接收客户端发来的指向目标流媒体资源的处理请求，并将所述处理请求调度至第一进程。
在本实施方式中，当客户端需要上传或者下载目标流媒体资源时，可以发送指向所述目标流媒体资源的处理请求，所述处理请求可以包括资源获取请求和资源上传请求。在本实施方式中，每一个流媒体资源均可以具备唯一标识，所述唯一标识的命名规则可以不作限定，只要能唯一地表征对应的流媒体资源即可。在实际应用中，所述唯一标识可以是统一资源定位符(Uniform Resource Locator，URL)，在本实施方式中的统一资源定位符的命名规则可以与RTMP(Real Time Messaging Protocol，实时消息传输协议)、HTTP(HyperText Transfer Protocol，超文本传输协议)中流媒体资源的URL的命名规则一致。例如，某个流媒体资源的URL可以是http://www.a.com/live/test。
在本实施方式中，客户端发出的处理请求可以是HTTP POST请求或者HTTP GET请求。所述处理请求可以被CDN中的负载均衡服务器接收，并通过所述负载均衡服务器分发至边缘节点中的一个边缘服务器处。所述负载均衡服务器可以按照预设的负载均衡策略分发所述处理请求。例如，可以将所述处理请求调度至当前负载最小的边缘服务器处。在边缘服务器中，通常都是通过进程来处理接收到的请求，因此，所述处理请求可以被调度至边缘服务器中的第一进程。
S3：判断是否由所述第一进程处理所述处理请求，若否，将所述处理请求转发至所述第一进程所处层级中的第二进程。
在CDN中可以包括多个层级，例如接入层(边缘节点)、中转层(父节点)、核心层(源节点)等。客户端发来的处理请求，通常会根据实际情况，在层级内部或者层级之间转发。因此，CDN中可以具备一定的路由规则，该路由规则可以限定客户端发来的处理请求应当被哪个层级中的哪个进程处理。这样，第一 进程在接收到负载均衡服务器调度来的处理请求后，可以根据该路由规则，判断该处理请求是否应该由自己处理。在本实施方式中，针对不同的处理请求，路由规则的表现形式也可以不同。例如，对于资源获取请求，路由规则可以表现为：判断所述第一进程关联的本地资源中是否包含所述目标流媒体资源，若包含，则可以判定由所述第一进程处理所述处理请求，若不包含，则可以判定不由所述第一进程处理所述处理请求。又例如，针对资源上传请求，该路由规则可以表现为：根据资源上传请求中包含的所述目标流媒体资源的唯一标识，计算该唯一标识对应的散列值。在实际应用中，可以采取哈希算法计算目标流媒体资源的URL的哈希值，计算得到的该哈希值便可以是上述的散列值。在本实施方式中，各个进程可以预先与一定数量的散列值进行关联，这样，当计算得到唯一标识的散列值之后，可以判断该散列值关联的进程是否是所述第一进程。若是，表明该散列值表征的是第一进程，那么可以判定由所述第一进程处理所述处理请求，若否，表明该散列值表征的不是第一进程，那么可以判定不由所述第一进程处理所述处理请求。
在本实施方式中，若所述第一进程不负责处理所述处理请求，则可以按照路由规则，将所述处理请求转发至同一层级中的第二进程处。
S5：判断是否由所述第二进程处理所述处理请求，若是，通过所述第二进程构建所述处理请求对应的响应请求，所述响应请求中包括所述第二进程生成的用于访问所述目标流媒体资源的访问地址。
在本实施方式中，第二进程在接收到所述处理请求之后，同样可以按照路由规则判断是否该由自己处理所述处理请求。如果路由规则表示第二进程依然无法处理该处理请求，那么表明该层级的进程均无法处理该请求，此时，可以将该请求转发至另一个层级中。举例来说，上海的一个客户端发起了下载某个流媒体资源的请求，该请求被负载均衡服务器调度至了边缘节点中空闲的第一进程。通过计算该请求对应的散列值，表明该请求实际应当由边缘节点中的第二进程处理，因此可以将该处理请求转发至第二进程。但是在第二进程关联的本地资源中，并不存在该客户端想要下载的流媒体资源，因此，第二进程也无法处理该请求。此时，则可以将该请求发送至核心层中的另一个进程处，由核心层中的进程来处理该请求。
在本实施方式中，若第二进程判定自身能够处理该请求，那么第二进程可 以尝试与客户端建立WebRTC通信连接，后续可以通过建立的WebRTC通信连接来传输目标流媒体资源。在本实施方式中，针对不同的处理请求，建立WebRTC通信连接的过程也可以不同。请参阅图4，当客户端需要将目标流媒体资源上传给第二进程时，可以发起资源上传请求。此时，客户端首先可以基于自身的硬件采集到的流媒体信息，生成Offer SDP。在所述Offer SDP中，可以包括客户端支持的视频编码方式、音频编码方式、音视频是否加密等信息。例如，所述Offer SDP的一个简单示例可以如下：
Offer SDP{
现在要发送一路媒体流资源；
视频编码可以使用H264、VP8、VP9；
音频编码可以使用AAC、MP3、OPUS；
可以启用加密；
}
由此可见，在Offer SDP中可以例举出客户端所支持的多种视频编码方式以及多种音频编码方式。这样，生成的Offer SDP便可以是上述的候选流媒体信息。
在本实施方式中，客户端发送的资源上传请求例如可以是HTTP POST请求。该请求的请求消息体便可以是上述的Offer SDP，这样，所述资源上传请求中便可以包含所述客户端支持的候选流媒体信息。
在本实施方式中，第二进程接收到所述资源上传请求后，可以从中提取出包含的候选流媒体信息。然后，第二进程可以根据自身的硬件条件，在所述候选流媒体信息中确定自身支持的目标视频编码方式和目标音频编码方式，并基于所述目标视频编码方式和目标音频编码方式构建应答流媒体信息。例如，第二进程可以确定当前能够接收客户端准备上传的目标流媒体资源，并指定视频编码方式为H264，音频编码方式为OPUS，并且可以对目标流媒体资源进行加密。那么，第二进程生成的应答流媒体信息Answer SDP的一个示例可以如下所示：
Answer SDP{
可以接收你发送的媒体流；
视频编码请使用H264；
音频编码请使用OPUS；
请启用加密；
}
在本实施方式中，为了建立WebRTC，除了SDP信息之外，还需要ICE candidate信息，所述ICE candidate信息可以基于公网IP地址来构建。具体地，第二进程可以获取自身的公网IP地址和端口地址，该公网IP地址可以存储于第二进程所处的边缘服务器内，无需从其它服务器中读取。然后，第二进程可以将所述公网IP地址和所述端口地址的组合作为用于访问所述目标流媒体资源的访问地址。例如，所述公网IP地址可以为10.8.114.195，用于接收流媒体资源的端口地址可以为54225，那么最终生成的访问地址便可以为10.8.114.195：54225。该访问地址便可以作为上述的ICE candidate。这样，第二进程便可以得到建立WebRTC通信连接所需的应答流媒体信息(Answer SDP)和访问地址(ICE candidate)。
在本实施方式中，第二进程可以响应于接收到的资源上传请求构建响应报文。该响应报文可以是状态码为200的HTTP响应报文。在该响应报文的响应消息体中，可以包括所述应答流媒体信息以及所述访问地址。
在另一个实施方式中，请参阅图5，所述处理请求可以是资源获取请求，客户端可以通过发起该资源获取请求下载目标流媒体资源。该资源获取请求例如可以是HTTP GET请求。该请求的URL可以是所述目标流媒体资源的唯一标识。第二进程接收到该资源获取请求之后，可以根据其携带的唯一标识，从关联的本地资源中确定客户端想要下载的目标流媒体资源。此时，第二进程可以获取自身的公网IP地址和端口地址，该公网IP地址可以存储于第二进程所处的边缘服务器内，无需从其它服务器中读取。然后，第二进程可以将所述公网IP地址和所述端口地址的组合作为用于访问所述目标流媒体资源的访问地址。例如，所述公网IP地址可以为10.8.114.195，用于传输流媒体资源的端口地址可以为54225，那么最终生成的访问地址便可以为10.8.114.195：54225。该访问地址便可以作为建立WebRTC通信连接时所需的ICE candidate。
在本实施方式中，第二进程关联的本地资源中的流媒体资源可以是其它的客户端上传的，客户端在上传流媒体资源之后，第二进程可以将该流媒体资源以及对应的应答流媒体信息关联存储。这样，第二进程可以根据目标流媒体资源的唯一标识，查询到与其关联的应答流媒体信息，并将该应答流媒体信息作 为所述目标流媒体资源关联的目标流媒体信息。这样，第二进程可以将所述目标流媒体信息作为Offer SDP。这样，所述第二进程便生成了Offer SDP和ICE candidate。此时，第二进程可以构建响应报文，该响应报文例如可以是状态码为200的HTTP响应报文。所述响应报文的响应消息体中可以包括上述的访问地址(ICE candidate)以及所述目标流媒体资源关联的目标流媒体信息(Offer SDP)。
S7：将所述响应请求反馈给所述第一进程，并通过所述第一进程将所述响应请求反馈给所述客户端，以使得所述客户端与所述第二进程之间建立连接，并通过建立的所述连接传输所述目标流媒体资源。
在本实施方式中，第二进程构建了所述处理请求对应的响应请求之后，可以将该响应请求反馈给第一进程，第一进程从而可以继续将该响应请求转发给客户端。这样，具备了SDP信息和ICE candidate，客户端与第二进程之间便可以建立起WebRTC通信连接。
在本实施方式中，通过建立的WebRTC通信连接，客户端与第二进程之间可以传输所述目标流媒体资源。具体地，针对资源上传请求而言，所述客户端可以根据所述应答流媒体信息对所述目标流媒体资源进行处理，并按照所述访问地址向所述第二进程上传经过处理的目标流媒体资源。对于资源获取请求而言，所述客户端可以通过所述访问地址下载所述目标流媒体资源，并通过所述目标流媒体信息对下载的所述目标流媒体资源进行处理。
在一个实施方式中，请参阅图6，若第二进程无法处理所述处理请求时，可以按照路由规则，将该处理请求转发至另一个层级的负载均衡服务器处。这样，另一个层级的负载均衡服务器便可以将该处理请求调度至第三进程。这样，第一进程和第二进程处于同一层级，而第三进程处于另一个不同的层级。
在本实施方式中，第三进程接收到所述处理请求之后，同样可以按照路由规则判断自身是否可以处理该请求。若可以，那么所述第三进程可以构建所述处理请求对应的响应请求。构建所述响应请求的方式与上述的方式类似，针对不同的处理请求，可以构建不同的响应请求。例如，所述处理请求包括资源上传请求，所述资源上传请求中可以包括所述客户端支持的候选流媒体信息。那么第三进程构建所述处理请求对应的响应请求时，可以基于所述候选流媒体信息和自身的硬件条件，生成应答流媒体信息。然后，第三进程可以获取自身的 公网IP地址和端口地址，并将所述公网IP地址和所述端口地址的组合作为用于访问所述目标流媒体资源的访问地址。这样，基于应答流媒体信息和访问地址，所述第三进程可以构建响应请求，并将所述应答流媒体信息以及所述访问地址作为所述响应请求的响应消息体。
此外，针对资源获取请求，所述资源获取请求中可以包括所述目标流媒体资源的唯一标识。所述第三进程在构建所述处理请求对应的响应请求时，可以获取与所述唯一标识相关联的目标流媒体信息，同时，还可以获取自身的公网IP地址和端口地址，并将所述公网IP地址和所述端口地址的组合作为用于访问所述目标流媒体资源的访问地址。这样，所述第三进程可以构建响应请求，并将所述目标流媒体信息以及所述访问地址作为所述响应请求的响应消息体。
在本实施方式中，第三进程在构建了响应请求之后，可以将构建的响应请求反馈给所述第二进程。第二进程接收到的该响应请求中包含SDP信息和ICE candidate，因此所述第二进程可以与所述第三进程建立WebRTC通信连接。
在本实施方式中，接收到第三进程发来的响应请求后，第二进程可以获取自身的公网IP地址和端口地址，并将所述公网IP地址和所述端口地址的组合作为第二进程生成的访问地址。然后，第二进程可以将所述第三进程构建的响应请求中的访问地址改写为所述第二进程生成的访问地址，并将改写了访问地址的响应请求反馈给所述客户端。客户端接收到的响应请求中包含SDP信息以及第二进程的ICE candidate，因此所述客户端可以与所述第二进程建立WebRTC通信连接。这样，后续便可以通过所述客户端与所述第二进程之间建立的连接以及所述第二进程与所述第三进程之间建立的连接，传输所述目标流媒体资源。具体地，针对资源上传请求，所述客户端可以根据所述应答流媒体信息对所述目标流媒体资源进行处理，并按照所述第二进程生成的访问地址向所述第二进程上传经过处理的目标流媒体资源。所述第二进程可以将所述经过处理的目标流媒体资源和所述应答流媒体信息关联存储，并按照所述第三进程生成的访问地址，将所述经过处理的目标流媒体资源上传至所述第三进程。同样地，所述第三进程可以将所述经过处理的目标流媒体资源和所述应答流媒体信息关联存储。这样，在第二进程和第三进程各自关联的资源中，均可以包含此次上传的目标流媒体资源。
此外，针对资源获取请求，所述第二进程可以先按照所述第三进程生成的 访问地址，从所述第三进程处下载所述目标流媒体资源，并将下载的所述目标流媒体资源和所述目标流媒体信息关联存储。然后，所述客户端可以按照所述第二进程生成的访问地址，从所述第二进程处下载所述目标流媒体资源，从而完成资源下载过程。
需要说明的是，根据路由规则判断之后，第三进程可能也无法处理所述处理请求，此时，可以继续将所述处理请求转发至与所述第三进程处于同一层级的第四进程。具体地，请参阅图7，在图7所示的场景中，客户端发出的处理请求，在边缘节点中先后经历了边缘服务器2(第一进程)和边缘服务器3(第二进程)，后来在中心节点中又经历了中心服务器1(第三进程)之后，才到达了能够处理该请求的中心服务器2(第四进程)。在这种情况下，所述第四进程可以按照上述的方式，构建所述处理请求对应的响应请求，所述响应请求中包括所述第四进程生成的用于访问所述目标流媒体资源的访问地址。然后，可以将所述第四进程构建的响应请求通过所述第三进程反馈给所述第二进程，以使得所述第二进程与所述第四进程建立连接。此时，所述第二进程可以将所述第四进程构建的响应请求中的访问地址改写为所述第二进程生成的访问地址，并将改写了访问地址的响应请求反馈给所述客户端，以使得所述客户端与所述第二进程建立连接。这样，后续可以通过所述客户端与所述第二进程之间建立的连接以及所述第二进程与所述第四进程之间建立的连接，传输所述目标流媒体资源。
实施例二
本申请还提供一种流媒体资源的传输系统，所述系统包括客户端和边缘节点，其中：
所述客户端用于向所述边缘节点发送指向目标流媒体资源的处理请求；
所述边缘节点用于将所述处理请求调度至第一进程；判断是否由所述第一进程处理所述处理请求，若否，将所述处理请求转发至所述第一进程所处层级中的第二进程；判断是否由所述第二进程处理所述处理请求，若是，通过所述第二进程构建所述处理请求对应的响应请求，所述响应请求中包括所述第二进程生成的用于访问所述目标流媒体资源的访问地址；将所述响应请求反馈给所述第一进程，并通过所述第一进程将所述响应请求反馈给所述客户端，以使得 所述客户端与所述第二进程之间建立连接，并通过建立的所述连接传输所述目标流媒体资源。
在一个实施方式中，所述系统还包括中心节点，所述中心节点中至少包括第三进程，所述第三进程用于在所述第二进程无法处理所述处理请求时，接收调度来的所述处理请求，并构建所述处理请求对应的响应请求。
具体地，所述响应请求中包括所述第三进程生成的用于访问所述目标流媒体资源的访问地址；将所述第三进程构建的响应请求反馈给所述第二进程，以使得所述第二进程与所述第三进程建立连接；
相应地，所述第二进程还用于将所述第三进程构建的响应请求中的访问地址改写为所述第二进程生成的访问地址，并将改写了访问地址的响应请求反馈给所述客户端，以使得所述客户端与所述第二进程建立连接。
在一个实施方式中，所述中心节点中还包括第四进程，其中，所述第四进程用于在所述第三进程无法处理所述处理请求时，接收从所述第三进程转发来的所述处理请求，并构建所述处理请求对应的响应请求。
具体地，所述响应请求中包括所述第四进程生成的用于访问所述目标流媒体资源的访问地址；将所述第四进程构建的响应请求通过所述第三进程反馈给所述第二进程，以使得所述第二进程与所述第四进程建立连接；
相应地，所述第二进程还用于将所述第四进程构建的响应请求中的访问地址改写为所述第二进程生成的访问地址，并将改写了访问地址的响应请求反馈给所述客户端，以使得所述客户端与所述第二进程建立连接。
请参阅图8，在本申请中，上述实施例中的技术方案可以应用于如图8所示的计算机终端10上。计算机终端10可以包括一个或多个(图中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输模块106。本领域普通技术人员可以理解，图8所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端10还可包括比图8中所示更多或者更少的组件，或者具有与图8所示不同的配置。
存储器104可用于存储应用软件的软件程序以及模块，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个 或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。
由上可见，本申请提供的技术方案中，可以将HTTP协议和WebRTC协议进行融合，一方面简化了通信连接的建立过程，同时还能适应CDN中的路由和转发规定。在CDN中可以包括多个层级，例如接入层(边缘节点)、中转层(父节点)、核心层(源节点)等。在层级内部或者层级之间，通常会涉及路由和转发的过程。具体地，当某个层级中的第一进程接收到客户端发来的处理请求后，根据CDN中的路由规则，可以判断该处理请求是否应该由第一进程处理，若不是，可以按照路由规则，将该处理请求转发至同一层级的第二进程。第二进程可以构建该处理请求的响应请求，在该响应请求中，可以包括第二进程生成的ICE candidate，该ICE candidate可以作为访问目标流媒体资源的访问地址。该响应请求通过第一进程反馈至客户端之后，在客户端与第二进程之间可以建立WebRTC通信连接，客户端从而可以将流媒体资源上传至第二进程，或者从第二进程处获取流媒体资源。此外，若第二进程依然无法处理该处理请求，可以将该处理请求发送至下一层级中的第三进程。第三进程可以按照类似的方式构建响应请求，只不过该响应请求中包含的是第三进程生成的访问地址。该响应请求被反馈至第二进程之后，第二进程可以将其中的访问地址改写为自身的访问地址，并将改写了访问地址的响应请求通过第一进程反馈至客户端。这样，客户端与第二进程，以及第二进程与第三进程之间可以分别建立WebRTC连接，从而可以传输流媒体资源。由上可见，本申请提供的技术方案，能够将WebRTC标准与CDN进行有效结合，既能够发挥CDN的快速分发功能，又能够实现WebRTC的低延时功能，从而能够提高流媒体资源的传输效率。
以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (17)

  1. 一种流媒体资源的传输方法，其特征在于，所述方法包括：
    接收客户端发来的指向目标流媒体资源的处理请求，并将所述处理请求调度至第一进程；
    判断是否由所述第一进程处理所述处理请求，若否，将所述处理请求转发至所述第一进程所处层级中的第二进程；
    判断是否由所述第二进程处理所述处理请求，若是，通过所述第二进程构建所述处理请求对应的响应请求，所述响应请求中包括所述第二进程生成的用于访问所述目标流媒体资源的访问地址；
    将所述响应请求反馈给所述第一进程，并通过所述第一进程将所述响应请求反馈给所述客户端，以使得所述客户端与所述第二进程之间建立连接，并通过建立的所述连接传输所述目标流媒体资源。
  2. 根据权利要求1所述的方法，其特征在于，所述处理请求包括资源获取请求；相应地，判断是否由所述第一进程处理所述处理请求包括：
    判断所述第一进程关联的本地资源中是否包含所述目标流媒体资源，若包含，判定由所述第一进程处理所述处理请求，若不包含，判定不由所述第一进程处理所述处理请求。
  3. 根据权利要求1所述的方法，其特征在于，所述处理请求包括资源上传请求，所述资源上传请求中包括所述目标流媒体资源的唯一标识；相应地，判断是否由所述第一进程处理所述处理请求包括：
    计算所述唯一标识对应的散列值，并判断所述散列值是否表征所述第一进程；若是，判定由所述第一进程处理所述处理请求，若否，判定不由所述第一进程处理所述处理请求。
  4. 根据权利要求1所述的方法，其特征在于，所述处理请求包括资源上传请求，所述资源上传请求中包括所述客户端支持的候选流媒体信息，所述响应请求中还包括由所述第二进程基于所述候选流媒体信息生成的应答流媒体信 息；相应地，通过建立的所述连接传输所述目标流媒体资源包括：
    所述客户端根据所述应答流媒体信息对所述目标流媒体资源进行处理，并按照所述访问地址向所述第二进程上传经过处理的目标流媒体资源。
  5. 根据权利要求1所述的方法，其特征在于，所述处理请求包括资源获取请求，所述资源获取请求中包括所述目标流媒体资源的唯一标识，所述响应请求中还包括所述目标流媒体资源关联的目标流媒体信息；相应地，通过建立的所述连接传输所述目标流媒体资源包括：
    所述客户端通过所述访问地址下载所述目标流媒体资源，并通过所述目标流媒体信息对下载的所述目标流媒体资源进行处理。
  6. 根据权利要求1所述的方法，其特征在于，所述访问地址由所述第二进程按照以下方式生成：
    所述第二进程获取自身的公网IP地址和端口地址，并将所述公网IP地址和所述端口地址的组合作为用于访问所述目标流媒体资源的访问地址。
  7. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    若所述第二进程无法处理所述处理请求，将所述处理请求调度至第三进程，其中，所述第三进程与所述第二进程处于内容分发网络中的不同层级；
    判断是否由所述第三进程处理所述处理请求，若是，通过所述第三进程构建所述处理请求对应的响应请求，所述响应请求中包括所述第三进程生成的用于访问所述目标流媒体资源的访问地址；
    将所述第三进程构建的响应请求反馈给所述第二进程，以使得所述第二进程与所述第三进程建立连接；
    通过所述第二进程将所述第三进程构建的响应请求中的访问地址改写为所述第二进程生成的访问地址，并将改写了访问地址的响应请求反馈给所述客户端，以使得所述客户端与所述第二进程建立连接；
    通过所述客户端与所述第二进程之间建立的连接以及所述第二进程与所述第三进程之间建立的连接，传输所述目标流媒体资源。
  8. 根据权利要求7所述的方法，其特征在于，所述处理请求包括资源上传请求，所述资源上传请求中包括所述客户端支持的候选流媒体信息；相应地，通过所述第三进程构建所述处理请求对应的响应请求包括：
    所述第三进程基于所述候选流媒体信息，生成应答流媒体信息；
    所述第三进程获取自身的公网IP地址和端口地址，并将所述公网IP地址和所述端口地址的组合作为用于访问所述目标流媒体资源的访问地址；
    所述第三进程构建响应请求，并将所述应答流媒体信息以及所述访问地址作为所述响应请求的响应消息体。
  9. 根据权利要求8所述的方法，其特征在于，传输所述目标流媒体资源包括：
    所述客户端根据所述应答流媒体信息对所述目标流媒体资源进行处理，并按照所述第二进程生成的访问地址向所述第二进程上传经过处理的目标流媒体资源；
    所述第二进程将所述经过处理的目标流媒体资源和所述应答流媒体信息关联存储，并按照所述第三进程生成的访问地址，将所述经过处理的目标流媒体资源上传至所述第三进程；
    所述第三进程将所述经过处理的目标流媒体资源和所述应答流媒体信息关联存储。
  10. 根据权利要求7所述的方法，其特征在于，所述处理请求包括资源获取请求，所述资源获取请求中包括所述目标流媒体资源的唯一标识；相应地，通过所述第三进程构建所述处理请求对应的响应请求包括：
    所述第三进程获取与所述唯一标识相关联的目标流媒体信息；
    所述第三进程获取自身的公网IP地址和端口地址，并将所述公网IP地址和所述端口地址的组合作为用于访问所述目标流媒体资源的访问地址；
    所述第三进程构建响应请求，并将所述目标流媒体信息以及所述访问地址作为所述响应请求的响应消息体。
  11. 根据权利要求10所述的方法，其特征在于，传输所述目标流媒体资源 包括：
    所述第二进程按照所述第三进程生成的访问地址，从所述第三进程处下载所述目标流媒体资源，并将下载的所述目标流媒体资源和所述目标流媒体信息关联存储；
    所述客户端按照所述第二进程生成的访问地址，从所述第二进程处下载所述目标流媒体资源。
  12. 根据权利要求7所述的方法，其特征在于，所述方法还包括：
    若所述第三进程无法处理所述处理请求，将所述处理请求转发至与所述第三进程处于同一层级的第四进程，以通过所述第四进程构建所述处理请求对应的响应请求，所述响应请求中包括所述第四进程生成的用于访问所述目标流媒体资源的访问地址；
    将所述第四进程构建的响应请求通过所述第三进程反馈给所述第二进程，以使得所述第二进程与所述第四进程建立连接；
    相应地，所述第二进程将所述第四进程构建的响应请求中的访问地址改写为所述第二进程生成的访问地址，并将改写了访问地址的响应请求反馈给所述客户端，以使得所述客户端与所述第二进程建立连接；
    通过所述客户端与所述第二进程之间建立的连接以及所述第二进程与所述第四进程之间建立的连接，传输所述目标流媒体资源。
  13. 一种流媒体资源的传输系统，其特征在于，所述系统包括客户端和边缘节点，其中：
    所述客户端用于向所述边缘节点发送指向目标流媒体资源的处理请求；
    所述边缘节点用于将所述处理请求调度至第一进程；判断是否由所述第一进程处理所述处理请求，若否，将所述处理请求转发至所述第一进程所处层级中的第二进程；判断是否由所述第二进程处理所述处理请求，若是，通过所述第二进程构建所述处理请求对应的响应请求，所述响应请求中包括所述第二进程生成的用于访问所述目标流媒体资源的访问地址；将所述响应请求反馈给所述第一进程，并通过所述第一进程将所述响应请求反馈给所述客户端，以使得所述客户端与所述第二进程之间建立连接，并通过建立的所述连接传输所述目 标流媒体资源。
  14. 根据权利要求13所述的系统，其特征在于，所述系统还包括中心节点，所述中心节点中至少包括第三进程，所述第三进程用于在所述第二进程无法处理所述处理请求时，接收调度来的所述处理请求，并构建所述处理请求对应的响应请求。
  15. 根据权利要求14所述的系统，其特征在于，所述响应请求中包括所述第三进程生成的用于访问所述目标流媒体资源的访问地址；将所述第三进程构建的响应请求反馈给所述第二进程，以使得所述第二进程与所述第三进程建立连接；
    相应地，所述第二进程还用于将所述第三进程构建的响应请求中的访问地址改写为所述第二进程生成的访问地址，并将改写了访问地址的响应请求反馈给所述客户端，以使得所述客户端与所述第二进程建立连接。
  16. 根据权利要求14所述的系统，其特征在于，所述中心节点中还包括第四进程，其中，所述第四进程用于在所述第三进程无法处理所述处理请求时，接收从所述第三进程转发来的所述处理请求，并构建所述处理请求对应的响应请求。
  17. 根据权利要求16所述的系统，其特征在于，所述响应请求中包括所述第四进程生成的用于访问所述目标流媒体资源的访问地址；将所述第四进程构建的响应请求通过所述第三进程反馈给所述第二进程，以使得所述第二进程与所述第四进程建立连接；
    相应地，所述第二进程还用于将所述第四进程构建的响应请求中的访问地址改写为所述第二进程生成的访问地址，并将改写了访问地址的响应请求反馈给所述客户端，以使得所述客户端与所述第二进程建立连接。
PCT/CN2018/086180 2018-04-18 2018-05-09 一种流媒体资源的传输方法及系统 WO2019200630A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP18869461.6A EP3576371B1 (en) 2018-04-18 2018-05-09 Method and system for transmitting streaming media resource
US16/099,850 US20210227034A1 (en) 2018-04-18 2018-05-09 A method and system for transmitting streaming media resources

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810350528.X 2018-04-18
CN201810350528.XA CN110392020B (zh) 2018-04-18 2018-04-18 一种流媒体资源的传输方法及系统

Publications (1)

Publication Number Publication Date
WO2019200630A1 true WO2019200630A1 (zh) 2019-10-24

Family

ID=67139583

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/086180 WO2019200630A1 (zh) 2018-04-18 2018-05-09 一种流媒体资源的传输方法及系统

Country Status (4)

Country Link
US (1) US20210227034A1 (zh)
EP (1) EP3576371B1 (zh)
CN (1) CN110392020B (zh)
WO (1) WO2019200630A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112261057A (zh) * 2020-10-28 2021-01-22 湖南天琛信息科技有限公司 一种音视频通话的加密处理系统
CN113204721A (zh) * 2021-05-14 2021-08-03 网宿科技股份有限公司 请求处理方法、节点及存储介质
CN113209632B (zh) * 2021-06-08 2022-08-12 腾讯科技（深圳）有限公司 一种云游戏的处理方法、装置、设备及存储介质
CN115242798B (zh) * 2022-06-30 2023-09-26 阿里巴巴（中国）有限公司 一种基于边缘云的任务调度方法、电子设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150310126A1 (en) * 2014-04-23 2015-10-29 Akamai Technologies, Inc. Creation and delivery of pre-rendered web pages for accelerated browsing
CN105516238A (zh) * 2015-11-23 2016-04-20 网易（杭州）网络有限公司 数据请求方法、装置、节点服务器及cdn系统
CN105872044A (zh) * 2016-03-30 2016-08-17 华南理工大学 基于WebRTC的流媒体多级缓存网络加速系统和方法
CN105959711A (zh) * 2016-04-21 2016-09-21 乐视控股（北京）有限公司 一种直播流媒体的上传方法及装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60109947T2 (de) * 2001-12-21 2006-02-09 Castify Networks S.A., Valbonne Verfahren zur Server-Auswahl in einem Inhaltsauslieferungsnetzwerk
CN107864228B (zh) * 2017-12-22 2020-11-27 网宿科技股份有限公司 一种内容分发网络中的连接建立方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150310126A1 (en) * 2014-04-23 2015-10-29 Akamai Technologies, Inc. Creation and delivery of pre-rendered web pages for accelerated browsing
CN105516238A (zh) * 2015-11-23 2016-04-20 网易（杭州）网络有限公司 数据请求方法、装置、节点服务器及cdn系统
CN105872044A (zh) * 2016-03-30 2016-08-17 华南理工大学 基于WebRTC的流媒体多级缓存网络加速系统和方法
CN105959711A (zh) * 2016-04-21 2016-09-21 乐视控股（北京）有限公司 一种直播流媒体的上传方法及装置

Also Published As

Publication number Publication date
EP3576371B1 (en) 2020-08-05
EP3576371A1 (en) 2019-12-04
US20210227034A1 (en) 2021-07-22
CN110392020B (zh) 2021-05-07
EP3576371A4 (en) 2019-12-04
EP3576371A8 (en) 2020-02-26
CN110392020A (zh) 2019-10-29

Similar Documents

Publication Publication Date Title
US11297140B2 (en) Point of presence based data uploading
EP3595268B1 (en) Streaming media resource distribution method, system, edge node and central dispatching system
CN110392071B (zh) 流媒体资源的上传、下载方法、分发系统及流媒体服务器
WO2019200630A1 (zh) 一种流媒体资源的传输方法及系统
US8046432B2 (en) Network caching for multiple contemporaneous requests
US7995473B2 (en) Content delivery system for digital object
US10893086B2 (en) Node type based control of assistance for data streaming
US8812718B2 (en) System and method of streaming data over a distributed infrastructure
US20080040420A1 (en) Content distribution network
WO2020155293A1 (zh) 一种推流方法、系统及服务器
US11240335B2 (en) System and methods thereof for delivery of popular content using a multimedia broadcast multicast service
US9385877B2 (en) Multicast systems, methods, and computer program products
US8650313B2 (en) Endpoint discriminator in network transport protocol startup packets
JP2023547256A (ja) データダウンロード方法、装置、及びコンピュータ機器
US20150074234A1 (en) Content system and method for chunk-based content delivery
WO2016180284A1 (zh) 服务节点分配方法、装置、cdn管理服务器及系统
WO2017005118A1 (zh) 维持通信连接的方法、装置、终端及服务器
Ramakrishnan et al. Adaptive video streaming over ccn with network coding for seamless mobility
Hundeboll et al. Peer-assisted content distribution with random linear network coding
CN111225252B (zh) 基于openwrt系统的PON网关UPNP视频直播方法
KR20220116201A (ko) 재생기에 오디오 및/또는 비디오 콘텐츠를 전달하기 위한 방법
KR101746925B1 (ko) 주변 디바이스를 이용한 캐싱 방법 및 장치
Vyzovitis An active protocol architecture for collaborative media distribution
CN116980343A (zh) 数据流传输方法、装置、系统、计算机设备和存储介质

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2018869461

Country of ref document: EP

Effective date: 20190430

NENP Non-entry into the national phase

Ref country code: DE