FMUSER Wirless Transmit Video And Audio More Easier !
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org ->Afrikaans
sq.fmuser.org ->Albanian
ar.fmuser.org ->Arabic
hy.fmuser.org ->Armenian
az.fmuser.org ->Azerbaijani
eu.fmuser.org ->Basque
be.fmuser.org ->Belarusian
bg.fmuser.org ->Bulgarian
ca.fmuser.org ->Catalan
zh-CN.fmuser.org ->Chinese (Simplified)
zh-TW.fmuser.org ->Chinese (Traditional)
hr.fmuser.org ->Croatian
cs.fmuser.org ->Czech
da.fmuser.org ->Danish
nl.fmuser.org ->Dutch
et.fmuser.org ->Estonian
tl.fmuser.org ->Filipino
fi.fmuser.org ->Finnish
fr.fmuser.org ->French
gl.fmuser.org ->Galician
ka.fmuser.org ->Georgian
de.fmuser.org ->German
el.fmuser.org ->Greek
ht.fmuser.org ->Haitian Creole
iw.fmuser.org ->Hebrew
hi.fmuser.org ->Hindi
hu.fmuser.org ->Hungarian
is.fmuser.org ->Icelandic
id.fmuser.org ->Indonesian
ga.fmuser.org ->Irish
it.fmuser.org ->Italian
ja.fmuser.org ->Japanese
ko.fmuser.org ->Korean
lv.fmuser.org ->Latvian
lt.fmuser.org ->Lithuanian
mk.fmuser.org ->Macedonian
ms.fmuser.org ->Malay
mt.fmuser.org ->Maltese
no.fmuser.org ->Norwegian
fa.fmuser.org ->Persian
pl.fmuser.org ->Polish
pt.fmuser.org ->Portuguese
ro.fmuser.org ->Romanian
ru.fmuser.org ->Russian
sr.fmuser.org ->Serbian
sk.fmuser.org ->Slovak
sl.fmuser.org ->Slovenian
es.fmuser.org ->Spanish
sw.fmuser.org ->Swahili
sv.fmuser.org ->Swedish
th.fmuser.org ->Thai
tr.fmuser.org ->Turkish
uk.fmuser.org ->Ukrainian
ur.fmuser.org ->Urdu
vi.fmuser.org ->Vietnamese
cy.fmuser.org ->Welsh
yi.fmuser.org ->Yiddish
Push agreement
Let’s first introduce what push protocols are available, their current status, advantages and disadvantages in the live broadcast field.
RTMP
WebRTC
Proprietary protocol based on UDP
HLS
FLV
RTMP
RTMP is the acronym for Real Time Messaging Protocol. The protocol is based on TCP and is a protocol family, including RTMP basic protocol and RTMPT/RTMPS/RTMPE and many other variants. RTMP is a network protocol designed for real-time data communication. It is mainly used for audio, video and data communication between the Flash/AIR platform and streaming media/interactive servers that support the RTMP protocol. Software that supports this agreement includes Adobe Media Server/Ultrant Media Server/red5, etc.
RTMP is the current mainstream streaming media transmission protocol, which is widely used in the live broadcast field. It can be said that most of the live broadcast products on the market adopt this protocol.
advantage
CDN support is good, mainstream CDN vendors support
Simple protocol, easy to implement on various platforms
Disadvantage
Based on TCP, the transmission cost is high, and the problem is significant when the packet loss rate is high in a weak network environment
Does not support browser push
Adobe proprietary agreement, Adobe no longer updates
Unpredictable stability problems are also prone to occur when massive concurrency
WebRTC
WebRTC, whose name is derived from the abbreviation of Web Real-Time Communication (English: Web Real-Time Communication), is an API that supports web browsers for real-time voice or video conversations. It was open sourced on June 1, 2011 and was included in the W3C recommended standards of the World Wide Web Consortium with the support of Google, Mozilla, and Opera.
advantage
W3C standard, high degree of support by mainstream browsers
Google is behind it and has reference implementations on various platforms
The bottom layer is based on SRTP and UDP, and there is a lot of room for optimization in weak network conditions
Point-to-point communication can be realized, with low delay between the communication parties
Disadvantage
ICE, STUN, TURN Traditional CDN does not provide similar services
Proprietary protocol based on UDP
Some live broadcast applications will use UDP as the underlying protocol to develop their own private protocols, because the advantages of UDP in a weak network environment can achieve a better weak network optimization effect through some customized tuning, but it is also bound to be a private protocol.
advantage
More space for customization and optimization
Disadvantage
High development cost
CDN is not friendly, you need to build your own CDN or reach an agreement with CDN
Fight independently, unable to evolve with the community
Other agreements
FLV
The FLV protocol is mainly promoted by Adobe. The format is extremely simple, except that some marker header information is added to a large block of video frames and audio and video headers. Because of this extreme simplicity, it is mature in terms of delay performance and large-scale concurrency. The only shortcoming is that the support on the mobile browser is very limited, but it is extremely suitable for use as a mobile APP live broadcast protocol.
HLS
The solution introduced by Apple divides the video into small video segments of 5-10 seconds, and then manages them with the m3u8 index table. Since the videos downloaded by the client are complete data of 5-10 seconds, the smoothness of the video is very good. Good, but it also introduces a large delay (the general delay of HLS is about 10-30s). Compared with FLV, HLS has very strong support on iPhone and most android mobile browsers, so it is often used for URL sharing in QQ and WeChat Moments.
transporting network
The streaming media that we push out needs to be transmitted to the audience. The entire link is the transmission network. The analogy of freight logistics is all the distance from the departure point to the destination. If the capacity of the road is not enough, it will cause traffic jams, which is network congestion. At this time, We will change the distance, which is the so-called intelligent scheduling, but the transmission network will schedule from a global perspective, so it will have a better effect than the scheduling of the atomic world. It is conceivable that there is a god looking down at the origin and destination in the sky. All the traffic information in the time, and it is real-time, and then gives you a clear road, how magical.
Let's first review the traditional content distribution network.
Why there is a content distribution network, the origin of the content distribution network
The Internet originated from an internal network of the US military. Tim Berners-Lee is one of the inventors of the Internet. He foresaw early that network congestion would become the biggest obstacle to the development of the Internet in the near future, so he raised an academic problem. To invent a new and fundamentally problem-solving method to realize the congestion-free distribution of Internet content, this academic problem eventually gave birth to an innovative Internet service-CDN. At that time, Dr. Berners-Lee was next door to the office of Professor Tom Leighton, a professor of applied mathematics at the Massachusetts Institute of Technology. He was aroused by Berners-Lee's challenge. Letghton finally solved this problem and started his own business plan, establishing Akamai, becoming the world's first CDN company.
Traditional CDN architecture
The figure above is a schematic diagram of the three-level deployment of a typical CDN system. The node is the most basic deployment unit in the CDN system. It is divided into three-level deployment, central node, regional node and edge node. The top level is the central node, and the middle one is the central node. The level is a regional node, and the edge nodes are geographically dispersed, providing users with nearby content access services.
The following introduces the classification of CDN nodes, which are mainly divided into two categories, backbone nodes and POP nodes, and backbone nodes are further divided into central nodes and regional nodes.
Backbone node
Central node
Area node
POP node
Edge node
Logically speaking, backbone nodes are mainly responsible for content distribution and return to the source when edge nodes are missed, and POP nodes are mainly responsible for providing users with nearby content access services. However, if the CDN network scale is large, the edge nodes directly return to the center node will cause excessive pressure on the core equipment of the middle layer. Physically introduce regional nodes to be responsible for the management of a geographical area and save some hot data.
The pain points of live broadcast transmission network that are different from traditional CDN
With the advent of the Live era, live broadcasting has become another major battlefield for current CDN vendors. What kind of services does CDN need to support in the Live era?
Support for streaming media protocols, including RTMP, HLS, HTTP-FLV, etc.
The first screen is turned on in seconds, and the control is within seconds from the user's click to the playback
1~3 Delay control, from the streaming end to the playback end, the delay is controlled between 1 and 3 seconds
The global intelligent routing of the entire network can use all nodes in the entire CDN network to serve a single user, regardless of geographical restrictions. With the continuous advancement of the global integration process, live broadcasting across regions, countries, and continents is becoming the norm. It is very likely that the anchor will be in Europe and the United States and the users will be in Asia.
Day-level nodes are increasing on demand, and Chinese companies going overseas have become a trend. CDN needs more overseas nodes. Nowadays, more overseas nodes are competing for rapid deployment. It takes one day from raising the demand for nodes to connecting to the network to provide services. Within this, very high requirements are placed on CDN operation and maintenance and planning. The original monthly plan and network access cannot meet the advanced requirements.
Traditional CDN link routing
CDN is based on a tree-like network topology. Each layer has GSLB (Global Server Load Balancing) for load balancing of multiple CDN nodes in the same layer. What are the benefits?
Among the many CDN application scenarios mentioned above, web acceleration, video acceleration, and file transfer acceleration all rely on GSLB and Cache systems at the same time. The Cache system is the cost of the entire CDN system, and the design tree structure can be maximized. Save the capital investment of the Cache system. Because only the central node needs to keep all the cache copies of the opportunity, it is reduced step by step, and the edge nodes only need a small amount of hot cache to hit most of the CDN access requests, which greatly reduces the cost of the CDN network, which is also in line with the time. The needs of CDN users are a win-win situation.
But in the Live era, the live broadcast service is a streaming service and rarely involves the Cache system. Basically, the storage resources can be released after the broadcast is completed. Even if the storage requirements are due to policy reasons, they are all cold storage. The investment in storage is relatively It is very cheap and does not require storage in all nodes, as long as the data can be traced back and available.
Let’s take a look at the tree-like network topology. The number of links available to users is limited. As shown in the figure below, the number of links available to users in a certain area is: 2 * 5 = 10
If the user is in a certain area, GSLB (usually Smart DNS at the edge node level) will route the user to an edge node in the area, and the upper layer will route the user to an area node (here, GSLB Usually the internal load balancer), and finally back to the central node, the central node will link the source station.
The assumption here is:
The fastest node that the user can access must be the edge node in the area. If there is no edge node in the area, the fastest node must be the edge node in the logically adjacent area.
The fastest node that an edge node can access must be an area node in the area, and it must not be a node in other areas.
The regional node to the central node must be the fastest, and the speed and bandwidth of this link are both optimal.
But is this really the case? Is it true to introduce so many assumptions?
In fact, even if theoretically we can prove that the above assumptions are valid, node planning and regional configuration mostly depend on people’s design and planning. We know that a large number of people is unreliable, and even if the regional planning is correct at the time, who can guarantee these static Will the network planning be changed because of the laying of a fiber or because of excessive pressure on certain IDCs? Therefore, we can jump out of the shackles of the tree-like network topology and explore a new network topology suitable for live broadcast acceleration.
In order to get rid of the limited link routing restrictions and activate the ability to organize the network, we can turn the above nodes into a mesh network topology:
We have seen that once we change the network structure to a mesh structure, the user's selectable links become: all the paths between two points specified in the undirected graph, as the students who have studied graph theory know, the number is staggering.
The system can select any fastest link through intelligent routing instead of relying on outdated manual planning during system deployment. Whether it is the addition of fiber between some links or the excessive pressure of a certain IDC, it can be reflected in the finishing network in real time , To help users push out the optimal link in real time. At this time, we can remove some of the previous assumptions and plan the link routing of the network in real time through machines instead of humans. Such real-time large-scale computing tasks are inherently not human strengths, and we should give them to more suitable species.
CDN expansion
As mentioned earlier, Chinese companies’ going overseas has become a general trend, and the demand for CDN overseas nodes is increasing. In this situation, CDN vendors need to deploy new backbone networks and edge nodes in new regions, and detailed network planning is required. The times have changed. Originally, CDN users were all enterprise-level users, and the iteration cycle of their business lines was long, there was a long time plan, and more time was left for CDN vendors. Internet companies pay attention to speed. Bi-weekly iterations have become the norm. This involves the contradiction between cost and response speed. If nodes are deployed in advance, they can better serve these Internet companies, but there is a higher cost pressure, and vice versa. Unable to respond to these fast-growing Internet companies.
Ideally, if the user puts forward a requirement, the CDN manufacturer internally evaluates it, gives feedback on the same day, and deploys on the same day, the customer can test new nodes in the new area on the same day. How to deal with it?
The answer is a peer-to-peer network based on a mesh topology. In the mesh topology, each node is a Peer. Logically, the services provided by each node are equivalent. There is no need to design a complex network topology by region. After the nodes are online There is no need for a complicated deployment process, and you can directly register node information online to provide services to users. In theory, the time before and after combined with virtualization technology can be controlled within one day.
|
Enter email to get a surprise
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org ->Afrikaans
sq.fmuser.org ->Albanian
ar.fmuser.org ->Arabic
hy.fmuser.org ->Armenian
az.fmuser.org ->Azerbaijani
eu.fmuser.org ->Basque
be.fmuser.org ->Belarusian
bg.fmuser.org ->Bulgarian
ca.fmuser.org ->Catalan
zh-CN.fmuser.org ->Chinese (Simplified)
zh-TW.fmuser.org ->Chinese (Traditional)
hr.fmuser.org ->Croatian
cs.fmuser.org ->Czech
da.fmuser.org ->Danish
nl.fmuser.org ->Dutch
et.fmuser.org ->Estonian
tl.fmuser.org ->Filipino
fi.fmuser.org ->Finnish
fr.fmuser.org ->French
gl.fmuser.org ->Galician
ka.fmuser.org ->Georgian
de.fmuser.org ->German
el.fmuser.org ->Greek
ht.fmuser.org ->Haitian Creole
iw.fmuser.org ->Hebrew
hi.fmuser.org ->Hindi
hu.fmuser.org ->Hungarian
is.fmuser.org ->Icelandic
id.fmuser.org ->Indonesian
ga.fmuser.org ->Irish
it.fmuser.org ->Italian
ja.fmuser.org ->Japanese
ko.fmuser.org ->Korean
lv.fmuser.org ->Latvian
lt.fmuser.org ->Lithuanian
mk.fmuser.org ->Macedonian
ms.fmuser.org ->Malay
mt.fmuser.org ->Maltese
no.fmuser.org ->Norwegian
fa.fmuser.org ->Persian
pl.fmuser.org ->Polish
pt.fmuser.org ->Portuguese
ro.fmuser.org ->Romanian
ru.fmuser.org ->Russian
sr.fmuser.org ->Serbian
sk.fmuser.org ->Slovak
sl.fmuser.org ->Slovenian
es.fmuser.org ->Spanish
sw.fmuser.org ->Swahili
sv.fmuser.org ->Swedish
th.fmuser.org ->Thai
tr.fmuser.org ->Turkish
uk.fmuser.org ->Ukrainian
ur.fmuser.org ->Urdu
vi.fmuser.org ->Vietnamese
cy.fmuser.org ->Welsh
yi.fmuser.org ->Yiddish
FMUSER Wirless Transmit Video And Audio More Easier !
Contact
Address:
No.305 Room HuiLan Building No.273 Huanpu Road Guangzhou China 510620
Categories
Newsletter