FMUSER ¡Transmite video y audio sin cables más fácilmente!
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> Afrikáans
sq.fmuser.org -> albanés
ar.fmuser.org -> árabe
hy.fmuser.org -> Armenio
az.fmuser.org -> azerbaiyano
eu.fmuser.org -> Vasco
be.fmuser.org -> bielorruso
bg.fmuser.org -> Bulgaria
ca.fmuser.org -> catalán
zh-CN.fmuser.org -> chino (simplificado)
zh-TW.fmuser.org -> Chino (tradicional)
hr.fmuser.org -> croata
cs.fmuser.org -> checo
da.fmuser.org -> danés
nl.fmuser.org -> Holandés
et.fmuser.org -> estonio
tl.fmuser.org -> filipino
fi.fmuser.org -> finlandés
fr.fmuser.org -> Francés
gl.fmuser.org -> gallego
ka.fmuser.org -> georgiano
de.fmuser.org -> alemán
el.fmuser.org -> Griego
ht.fmuser.org -> criollo haitiano
iw.fmuser.org -> hebreo
hi.fmuser.org -> Hindi
hu.fmuser.org -> Hungarian
is.fmuser.org -> islandés
id.fmuser.org -> indonesio
ga.fmuser.org -> irlandés
it.fmuser.org -> Italiano
ja.fmuser.org -> japonés
ko.fmuser.org -> coreano
lv.fmuser.org -> letón
lt.fmuser.org -> Lituania
mk.fmuser.org -> macedonio
ms.fmuser.org -> malayo
mt.fmuser.org -> maltés
no.fmuser.org -> Noruega
fa.fmuser.org -> persa
pl.fmuser.org -> polaco
pt.fmuser.org -> portugués
ro.fmuser.org -> Rumano
ru.fmuser.org -> ruso
sr.fmuser.org -> serbio
sk.fmuser.org -> eslovaco
sl.fmuser.org -> Eslovenia
es.fmuser.org -> español
sw.fmuser.org -> Swahili
sv.fmuser.org -> sueco
th.fmuser.org -> Tailandés
tr.fmuser.org -> turco
uk.fmuser.org -> ucraniano
ur.fmuser.org -> Urdu
vi.fmuser.org -> Vietnamita
cy.fmuser.org -> galés
yi.fmuser.org -> Yiddish
Acuerdo de empuje
Primero introduzcamos qué protocolos push están disponibles, su estado actual, ventajas y desventajas en el campo de la transmisión en vivo.
RTMP
WebRTC
Protocolo propietario basado en UDP
HLS
FLV
RTMP
RTMP es el acrónimo de Real Time Messaging Protocol. El protocolo se basa en TCP y es una familia de protocolos, que incluye el protocolo básico RTMP y RTMPT / RTMPS / RTMPE y muchas otras variantes. RTMP es un protocolo de red diseñado para la comunicación de datos en tiempo real. Se utiliza principalmente para la comunicación de audio, video y datos entre la plataforma Flash / AIR y los servidores multimedia / interactivos de transmisión que admiten el protocolo RTMP. El software que admite este acuerdo incluye Adobe Media Server / Ultrant Media Server / red5, etc.
RTMP es el protocolo de transmisión de medios de transmisión de corriente principal actual, que se utiliza ampliamente en el campo de la transmisión en vivo. Se puede decir que la mayoría de los productos de transmisión en vivo del mercado adoptan este protocolo.
competitiva
El soporte de CDN es bueno, el soporte de los principales proveedores de CDN
Protocolo simple, fácil de implementar en varias plataformas
Desventaja
Basado en TCP, el costo de transmisión es alto y el problema es significativo cuando la tasa de pérdida de paquetes es alta en un entorno de red débil.
No es compatible con la inserción del navegador
Acuerdo de propiedad de Adobe, Adobe ya no se actualiza
Los problemas de estabilidad impredecibles también son propensos a ocurrir cuando la concurrencia masiva
WebRTC
WebRTC, cuyo nombre se deriva de la abreviatura de Web Real-Time Communication (en inglés: Web Real-Time Communication), es una API que admite navegadores web para conversaciones de voz o video en tiempo real. Fue de código abierto el 1 de junio de 2011 y se incluyó en los estándares recomendados por el W3C del World Wide Web Consortium con el apoyo de Google, Mozilla y Opera.
competitiva
Estándar W3C, alto grado de compatibilidad con los navegadores convencionales
Google lo respalda y tiene implementaciones de referencia en varias plataformas.
La capa inferior se basa en SRTP y UDP, y hay mucho espacio para la optimización en condiciones de red débiles.
Se puede realizar una comunicación punto a punto, con poca demora entre las partes de la comunicación.
Desventaja
ICE, STUN, TURN La CDN tradicional no ofrece servicios similares
Protocolo propietario basado en UDP
Algunas aplicaciones de transmisión en vivo usarán UDP como protocolo subyacente para desarrollar sus propios protocolos privados, porque las ventajas de UDP en un entorno de red débil pueden lograr un mejor efecto de optimización de red débil a través de algunos ajustes personalizados, pero también está destinado a ser privado. protocolo.
competitiva
Más espacio para personalización y optimización
Desventaja
Alto costo de desarrollo
CDN no es amigable, necesita construir su propio CDN o llegar a un acuerdo con CDN
Lucha de forma independiente, incapaz de evolucionar con la comunidad.
Otros acuerdos
FLV
El protocolo FLV es promovido principalmente por Adobe. El formato es extremadamente simple, excepto que se agrega cierta información de encabezado de marcador a un gran bloque de fotogramas de video y encabezados de audio y video. Debido a esta extrema simplicidad, es maduro en términos de rendimiento de retardo y concurrencia a gran escala. El único inconveniente es que el soporte en el navegador móvil es muy limitado, pero es extremadamente adecuado para su uso como protocolo de transmisión en vivo de una aplicación móvil.
HLS
La solución presentada por Apple divide el video en pequeños segmentos de video de 5 a 10 segundos y luego los administra con la tabla de índice m3u8. Dado que los videos descargados por el cliente son datos completos de 5-10 segundos, la fluidez del video es muy buena. Bien, pero también introduce una gran demora (la demora general de HLS es de aproximadamente 10-30 s). En comparación con FLV, HLS tiene un soporte muy sólido en iPhone y la mayoría de los navegadores móviles de Android, por lo que a menudo se usa para compartir URL en QQ y WeChat Moments.
red de transporte
Los medios de transmisión que enviamos deben transmitirse a la audiencia. Todo el enlace es la red de transmisión. La analogía de la logística de carga es toda la distancia desde el punto de partida hasta el destino. Si la capacidad de la carretera no es suficiente, provocará atascos, que es la congestión de la red. En este momento, cambiaremos la distancia, que es la llamada programación inteligente, pero la red de transmisión programará desde una perspectiva global, por lo que tendrá un mejor efecto que la programación del mundo atómico. Es concebible que haya un dios mirando hacia el origen y el destino en el cielo. Toda la información de tráfico en el tiempo, y es en tiempo real, y luego le da un camino despejado, qué mágico.
Primero revisemos la red de distribución de contenido tradicional.
Por qué existe una red de distribución de contenido, el origen de la red de distribución de contenido
Internet se originó a partir de una red interna del ejército estadounidense. Tim Berners-Lee es uno de los inventores de Internet. Previó pronto que la congestión de la red se convertiría en el mayor obstáculo para el desarrollo de Internet en un futuro próximo, por lo que planteó un problema académico. Para inventar un método nuevo y fundamentalmente de resolución de problemas para realizar la distribución libre de congestión del contenido de Internet, este problema académico finalmente dio lugar a un innovador servicio de Internet: CDN. En ese momento, el Dr. Berners-Lee estaba al lado de la oficina del profesor Tom Leighton, profesor de matemáticas aplicadas en el Instituto de Tecnología de Massachusetts. Estaba excitado por el desafío de Berners-Lee. Letghton finalmente resolvió este problema y comenzó su propio plan de negocios, estableciendo Akamai, convirtiéndose en la primera compañía CDN del mundo.
Arquitectura CDN tradicional
La figura anterior es un diagrama esquemático de la implementación de tres niveles de un sistema CDN típico. El nodo es la unidad de implementación más básica del sistema CDN. Se divide en implementación de tres niveles, nodo central, nodo regional y nodo de borde. El nivel superior es el nodo central y el del medio es el nodo central. El nivel es un nodo regional y los nodos de borde están geográficamente dispersos, lo que proporciona a los usuarios servicios de acceso a contenido cercanos.
A continuación se presenta la clasificación de los nodos CDN, que se dividen principalmente en dos categorías, nodos troncales y nodos POP, y los nodos troncales se dividen en nodos centrales y nodos regionales.
Nodo de la columna vertebral
Nodo central
Nodo de área
Nodo POP
Nodo de borde
Lógicamente hablando, los nodos de la red troncal son los principales responsables de la distribución de contenido y regresan a la fuente cuando se pierden los nodos de borde, y los nodos POP son los principales responsables de proporcionar a los usuarios servicios de acceso a contenido cercanos. Sin embargo, si la escala de la red CDN es grande, los nodos de borde que regresan directamente al nodo central causarán una presión excesiva en el equipo central de la capa intermedia. Introducir físicamente nodos regionales para que se encarguen de la gestión de un área geográfica y guardar algunos datos calientes.
Los puntos débiles de la red de transmisión de transmisión en vivo que son diferentes de la CDN tradicional
Con el advenimiento de la era Live, la transmisión en vivo se ha convertido en otro campo de batalla importante para los proveedores de CDN actuales. ¿Qué tipo de servicios necesita CDN para admitir en la era Live?
Soporte para protocolos de transmisión de medios, incluidos RTMP, HLS, HTTP-FLV, etc.
La primera pantalla se enciende en segundos y el control está en segundos desde el clic del usuario hasta la reproducción.
1 ~ 3 Control de retardo, desde el final de la transmisión hasta el final de la reproducción, el retardo se controla entre 1 y 3 segundos
El enrutamiento inteligente global de toda la red puede usar todos los nodos en toda la red CDN para servir a un solo usuario, independientemente de las restricciones geográficas. Con el avance continuo del proceso de integración global, la transmisión en vivo en todas las regiones, países y continentes se está convirtiendo en la norma. Es muy probable que el ancla esté en Europa y Estados Unidos y los usuarios en Asia.
Los nodos de nivel diario aumentan según la demanda, y las empresas chinas que se trasladan al extranjero se han convertido en una tendencia. CDN necesita más nodos en el extranjero. Hoy en día, más nodos en el extranjero compiten por una implementación rápida. Se necesita un día desde que aumenta la demanda de nodos hasta que se conecta a la red para proporcionar servicios. Dentro de esto, se imponen requisitos muy altos en la operación, el mantenimiento y la planificación de CDN. El plan mensual original y el acceso a la red no pueden cumplir con los requisitos avanzados.
Enrutamiento de enlaces CDN tradicional
CDN se basa en una topología de red en forma de árbol. Cada capa tiene GSLB (Equilibrio de carga global del servidor) para equilibrar la carga de varios nodos CDN en la misma capa. ¿Cuales son los beneficios?
Entre los muchos escenarios de aplicaciones CDN mencionados anteriormente, la aceleración web, la aceleración de video y la aceleración de transferencia de archivos dependen de los sistemas GSLB y Cache al mismo tiempo. El sistema de caché es el costo de todo el sistema CDN y la estructura del árbol de diseño se puede maximizar. Ahorre la inversión de capital del sistema Cache. Debido a que solo el nodo central necesita mantener todas las copias de caché de la oportunidad, se reduce paso a paso, y los nodos de borde solo necesitan una pequeña cantidad de caché en caliente para alcanzar la mayoría de las solicitudes de acceso a CDN, lo que reduce en gran medida el costo de la red CDN, que también está en línea con la hora. Las necesidades de los usuarios de CDN son una situación en la que todos ganan.
Pero en la era Live, el servicio de transmisión en vivo es un servicio de transmisión y rara vez involucra el sistema Cache. Básicamente, los recursos de almacenamiento se pueden liberar después de que se complete la transmisión. Incluso si los requisitos de almacenamiento se deben a razones políticas, todos son almacenamiento en frío. La inversión en almacenamiento es relativamente económica y no requiere almacenamiento en todos los nodos, siempre y cuando los datos se puedan rastrear y estén disponibles.
Echemos un vistazo a la topología de red en forma de árbol. El número de enlaces disponibles para los usuarios es limitado. Como se muestra en la figura siguiente, la cantidad de enlaces disponibles para los usuarios en un área determinada es: 2 * 5 = 10
Si el usuario se encuentra en un área determinada, GSLB (generalmente Smart DNS en el nivel del nodo de borde) enrutará al usuario a un nodo de borde en el área, y la capa superior enrutará al usuario a un nodo de área (aquí, GSLB generalmente el balanceador de carga interno), y finalmente de regreso al nodo central, el nodo central vinculará la estación fuente.
La suposición aquí es:
El nodo más rápido al que puede acceder el usuario debe ser el nodo de borde en el área. Si no hay ningún nodo de borde en el área, el nodo más rápido debe ser el nodo de borde en el área lógicamente adyacente.
El nodo más rápido al que puede acceder un nodo de borde debe ser un nodo de área en el área y no debe ser un nodo en otras áreas.
El nodo regional al nodo central debe ser el más rápido, y la velocidad y el ancho de banda de este enlace son óptimos.
¿Pero es éste realmente el caso? ¿Es cierto introducir tantos supuestos?
De hecho, incluso si teóricamente podemos probar que los supuestos anteriores son válidos, la planificación de nodos y la configuración regional dependen principalmente del diseño y la planificación de las personas. Sabemos que una gran cantidad de personas no es confiable, y aunque la planificación regional sea correcta en ese momento, ¿quién puede garantizar estos estáticos? ¿Se cambiará la planificación de la red por el tendido de una fibra o por una presión excesiva sobre ciertos IDC? Por lo tanto, podemos salirnos de los grilletes de la topología de red en forma de árbol y explorar una nueva topología de red adecuada para la aceleración de transmisiones en vivo.
Para deshacernos de las restricciones limitadas de enrutamiento de enlaces y activar la capacidad de organizar la red, podemos convertir los nodos anteriores en una topología de red en malla:
Hemos visto que una vez que cambiamos la estructura de la red a una estructura de malla, los enlaces seleccionables por el usuario se convierten en: todos los caminos entre dos puntos especificados en el gráfico no dirigido, como saben los estudiantes que han estudiado teoría de grafos, el número es asombroso.
El sistema puede seleccionar cualquier enlace a través de enrutamiento inteligente en lugar de depender de una planificación manual obsoleta durante la implementación del sistema. Ya sea la adición de fibra entre algunos enlaces o la presión excesiva de un determinado IDC, puede reflejarse en la red de acabado en tiempo real, para ayudar a los usuarios a sacar el enlace óptimo en tiempo real. En este momento, podemos eliminar algunas de las suposiciones anteriores y planificar el enrutamiento de enlaces de la red en tiempo real a través de máquinas en lugar de humanos. Tales tareas de computación a gran escala en tiempo real no son inherentemente fortalezas humanas, y deberíamos dárselas a especies más adecuadas.
Expansión de CDN
Como se mencionó anteriormente, la salida de las empresas chinas al extranjero se ha convertido en una tendencia general y la demanda de nodos CDN en el extranjero está aumentando. En esta situación, los proveedores de CDN necesitan implementar nuevas redes troncales y nodos de borde en nuevas regiones, y se requiere una planificación detallada de la red. Los tiempos han cambiado. Originalmente, los usuarios de CDN eran todos usuarios de nivel empresarial, y el ciclo de iteración de sus líneas de negocio era largo, había un plan a largo plazo y se dejaba más tiempo para los proveedores de CDN. Las empresas de Internet prestan atención a la velocidad. Las iteraciones quincenales se han convertido en la norma. Esto implica la contradicción entre costo y velocidad de respuesta. Si los nodos se implementan con anticipación, pueden brindar un mejor servicio a estas empresas de Internet, pero existe una mayor presión de costos y viceversa. Incapaz de responder a estas empresas de Internet de rápido crecimiento.
Idealmente, si el usuario presenta un requisito, el fabricante de CDN lo evalúa internamente, brinda retroalimentación el mismo día y lo implementa el mismo día, el cliente puede probar nuevos nodos en la nueva área el mismo día. ¿Como lidiar con?
La respuesta es una red de igual a igual basada en una topología de malla. En la topología de malla, cada nodo es un par. Lógicamente, los servicios que brinda cada nodo son equivalentes. No es necesario diseñar una topología de red compleja por región. Una vez que los nodos están en línea No es necesario un proceso de implementación complicado, y puede registrar directamente la información de los nodos en línea para proporcionar servicios a los usuarios. En teoría, el tiempo antes y después combinado con la tecnología de virtualización se puede controlar en un día.
|
Ingrese el correo electrónico para recibir una sorpresa
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> Afrikáans
sq.fmuser.org -> albanés
ar.fmuser.org -> árabe
hy.fmuser.org -> Armenio
az.fmuser.org -> azerbaiyano
eu.fmuser.org -> Vasco
be.fmuser.org -> bielorruso
bg.fmuser.org -> Bulgaria
ca.fmuser.org -> catalán
zh-CN.fmuser.org -> chino (simplificado)
zh-TW.fmuser.org -> Chino (tradicional)
hr.fmuser.org -> croata
cs.fmuser.org -> checo
da.fmuser.org -> danés
nl.fmuser.org -> Holandés
et.fmuser.org -> estonio
tl.fmuser.org -> filipino
fi.fmuser.org -> finlandés
fr.fmuser.org -> Francés
gl.fmuser.org -> gallego
ka.fmuser.org -> georgiano
de.fmuser.org -> alemán
el.fmuser.org -> Griego
ht.fmuser.org -> criollo haitiano
iw.fmuser.org -> hebreo
hi.fmuser.org -> Hindi
hu.fmuser.org -> Hungarian
is.fmuser.org -> islandés
id.fmuser.org -> indonesio
ga.fmuser.org -> irlandés
it.fmuser.org -> Italiano
ja.fmuser.org -> japonés
ko.fmuser.org -> coreano
lv.fmuser.org -> letón
lt.fmuser.org -> Lituania
mk.fmuser.org -> macedonio
ms.fmuser.org -> malayo
mt.fmuser.org -> maltés
no.fmuser.org -> Noruega
fa.fmuser.org -> persa
pl.fmuser.org -> polaco
pt.fmuser.org -> portugués
ro.fmuser.org -> Rumano
ru.fmuser.org -> ruso
sr.fmuser.org -> serbio
sk.fmuser.org -> eslovaco
sl.fmuser.org -> Eslovenia
es.fmuser.org -> español
sw.fmuser.org -> Swahili
sv.fmuser.org -> sueco
th.fmuser.org -> Tailandés
tr.fmuser.org -> turco
uk.fmuser.org -> ucraniano
ur.fmuser.org -> Urdu
vi.fmuser.org -> Vietnamita
cy.fmuser.org -> galés
yi.fmuser.org -> Yiddish
FMUSER ¡Transmite video y audio sin cables más fácilmente!
Contacto
Dirección:
Habitación No.305 Edificio HuiLan No.273 Huanpu Road Guangzhou China 510620
Categorías
Newsletter