Nous utilisons Wowza Streaming Engine pour le streaming en direct, et nous pensions pouvoir utiliser Amazon CloudFront pour diffuser la vidéo aux spectateurs afin de réduire la charge sur nos serveurs et cesser de nous inquiéter beaucoup de bande passante que nous consommons.Amazon CloudFront crée une nouvelle connexion à Wowza Streaming Engine pour chaque utilisateur
Les utilisateurs utilisent HLS pour regarder la vidéo sur des appareils iOS, les URL ressemblant à ceci: http://[cdnHash].cloudfront.net/live/[origin]_[stream_name]/playlist.m3u8. Nous avons un certain nombre de serveurs à travers le monde, donc nous avons créé plusieurs comportements dans CloudFront, donc il sait où trouver chaque flux, en fonction de l'élément [origin] de l'URL en tant que motif de chemin.
Cela fonctionne, nous pouvons voir la vidéo en utilisant cette URL, et tout semble bien. Cependant, nous avons remarqué que pour chaque visionneuse utilisant l'URL CloudFront, une nouvelle connexion à Wowza Engine est créée. Ce qui va à l'encontre du but de l'utilisation d'un CDN, car la bande passante de nos serveurs est de nouveau directement proportionnelle au nombre de spectateurs, et nous paierons également la bande passante CloudFront.
Je ne sais pas où chercher la racine de ce problème: les paramètres sur les origines Wowza ou les paramètres CloudFront?
Qu'en est-il des en-têtes de réponse HTTP de CloudFront? Plus précisément, 'X-Cache:'? Ou CloudFront hit/miss/rapports d'erreur? Ou des journaux CloudFront? Bien sûr, vous verrez d'abord le même nombre de connexions ... parce que votre contenu n'est pas encore mis en cache, et pour chaque bord avec une demande de visionneuse pour un objet, le contenu doit être récupéré et mis en cache avant de pouvoir être servi à partir du cache. La question qui doit être résolue avant toute autre chose est de savoir si votre contenu est * jamais * servi à partir du cache ... et si le contenu récupéré à l'origine ne fournit pas une réponse "non" concluante. –