پهنای باند استریم ویدئو فقط از روی رزولوشن یا تعداد کاربران ثبتنامشده مشخص نمیشود. برای برآورد آن باید بیتریت واقعی ویدئو و صدا، تعداد نشستهای پخش همزمان، سهم کیفیتهای مختلف، رفتار دانلود Player و وضعیت کش را کنار هم قرار دهید. اشتباه در این محاسبه میتواند به توقف پخش، اشباع لینک یا خرید ظرفیت بیشتر از نیاز منجر شود.
این راهنما برای DevOps و مدیران فنی، مسیر تبدیل Bitrate به ظرفیت شبکه و حجم ترافیک را توضیح میدهد. تمام اعداد مثالها فرضیاند و توصیه عمومی برای انتخاب کیفیت یا خرید سرویس نیستند. برای شناخت اجزای مسیر تحویل، راهنمای معماری زیرساخت VOD و پخش پایدار را نیز بخوانید.
۱. تفاوت Bitrate، پهنای باند و حجم ترافیک
Bitrate نرخ داده رسانه در واحد زمان است؛ مثلاً یک ویدئو با بیتریت متوسط ۳ Mbps در هر ثانیه بهطور متوسط سه مگابیت داده ویدئویی دارد. پهنای باند، ظرفیت یا نرخ انتقال در یک مسیر شبکه است. حجم ترافیک، مجموع داده منتقلشده در یک بازه است و معمولاً با GB یا TB گزارش میشود.
ممکن است سرویسی ترافیک ماهانه کمی داشته باشد اما هنگام انتشار محتوای محبوب، به پهنای باند لحظهای زیادی نیاز پیدا کند. برعکس، پخش پیوسته با تعداد بیننده محدود میتواند حجم ماهانه بالایی ایجاد کند. بنابراین ظرفیت پورت و سهمیه ترافیک را جدا ارزیابی کنید.
- هر بایت برابر ۸ بیت است؛ Mbps با MB/s یکسان نیست.
- در این مقاله Mbps، Gbps، GB و TB بر مبنای دهدهی هستند.
- یک Gbps برابر ۱۰۰۰ Mbps است؛ GB با GiB تفاوت دارد.
- ظرفیت اسمی کارت شبکه لزوماً برابر توان عملی تحویل داده کاربردی نیست.
۲. بیتریت مؤثر؛ ورودی محاسبه پهنای باند استریم ویدئو
در پخش تطبیقی، کاربران بسته به شرایط شبکه و تصمیم Player کیفیتهای متفاوتی میگیرند. جمعکردن بیتریت تمام نسخههای نردبان کیفیت برای هر بیننده اشتباه است؛ در حالت معمول، Player در هر لحظه یک نسخه ویدئو و ترک صوتی انتخابشده را دریافت میکند.
برای برنامهریزی پهنای باند استریم ویدئو، سهم هر کیفیت را از دادههای واقعی نشستها یا مدت پخش استخراج کنید. اگر همه نشستها مدت برابر ندارند، میانگین ساده تعداد انتخابها میتواند گمراهکننده باشد. سهمها باید با بازه و روش اندازهگیری سازگار باشند.
b_video_avg = Σ (quality_share × video_bitrate)
b_media_avg = b_video_avg + b_audio_avg
در جدول زیر، برای سادهشدن مثال، هر نشست یک ترک صوتی ۰٫۱۲۸ Mbps دریافت میکند. این بیتریتها صرفاً ورودی محاسباتیاند و نردبان پیشنهادی برای تمام محتواها نیستند.
| کیفیت فرضی | بیتریت ویدئو | سهم زمان پخش | سهم در میانگین |
|---|---|---|---|
| ۴۸۰p | ۱ Mbps | ۲۰٪ | ۰٫۲ Mbps |
| ۷۲۰p | ۲٫۵ Mbps | ۵۰٪ | ۱٫۲۵ Mbps |
| ۱۰۸۰p | ۵ Mbps | ۳۰٪ | ۱٫۵ Mbps |
| جمع ویدئو | — | ۱۰۰٪ | ۲٫۹۵ Mbps |
| با صدای انتخابشده | — | — | ۳٫۰۷۸ Mbps |
بیتریت تنظیمشده با بیتریت واقعی تفاوت دارد
رزولوشن بهتنهایی حجم داده را تعیین نمیکند. حرکت تصویر، نویز، نرخ فریم، Codec و تنظیمات Encoder روی خروجی اثر دارند. در VBR، اندازه قطعات با پیچیدگی صحنه تغییر میکند؛ بنابراین علاوه بر میانگین کل فایل، توزیع اندازه قطعات و قلههای کوتاهمدت را اندازه بگیرید.
در HLS، ویژگیهای AVERAGE-BANDWIDTH و BANDWIDTH بهترتیب اطلاعات نرخ متوسط و اوج Variant را بیان میکنند؛ این مقادیر باید با رسانه واقعی و ترکیب قابل پخش ترکها سازگار باشند. این تمایز در RFC 8216 تعریف شده است. اگر داده ورودی شما از قبل مجموع صوت و تصویر است، صدا را دوباره به آن اضافه نکنید.
۳. فرمول محاسبه پهنای باند استریم ویدئو
در یک مدل ساده، نرخ رسانه موردنیاز از ضرب تعداد نشستهای همزمان در بیتریت متوسط هر نشست به دست میآید. برای برآورد ظرفیت لینک، سربار و میزان استفاده هدف نیز باید بهصورت مستقل و شفاف لحاظ شوند.
B_media_Mbps = N × b_media_avg
B_plan_Gbps = (N × b_media_avg × k) / (1000 × u)
- N: تعداد نشستهای پخش همزمان در بازه طراحی.
- b_media_avg: میانگین بیتریت رسانه هر نشست، بر حسب Mbps.
- k: ضریب داده اضافی نسبت به مبنای اندازهگیری؛ مانند سربار انتقال و دریافت مجدد.
- u: نسبت استفاده هدف از ظرفیت؛ مثلاً ۰٫۷ برای استفاده هدف ۷۰٪.
ضریب k را از اندازهگیری استخراج کنید. اگر نرخ ورودی از شمارنده شبکه گرفته شده و سربار موردنظر را شامل میشود، افزودن همان سربار دوباره باعث بیشبرآورد میشود. همچنین u حاشیه آزاد عملیاتی ایجاد میکند و نباید بدون توضیح با چند ضریب احتیاط مشابه ترکیب شود.
مثال محاسبه برای ۵ هزار نشست همزمان
با ۵۰۰۰ نشست، بیتریت ۳٫۰۷۸ Mbps، ضریب فرضی ۱٫۰۸ و استفاده هدف ۷۰٪، محاسبه پهنای باند استریم ویدئو چنین است:
B_media = 5000 × ۳.۰۷۸ = 15390 Mbps = 15.39 Gbps
B_transfer = 15.39 × ۱.۰۸ = 16.۶۲۱۲ Gbps
B_plan = 16.6212 / 0.70 ≈ ۲۳.۷۴ Gbps
عدد ۲۳٫۷۴ Gbps ظرفیت برنامهریزیشده در فرضهای این مثال است؛ نه مصرف دائمی سرویس و نه تضمین کفایت یک پورت ۲۵ گیگابیتی. توان واقعی سختافزار، مسیر شبکه، قله دانلود و شرایط خرابی باید آزمایش شوند. برای تخمین تعداد نشستها، از مقاله محاسبه ظرفیت کاربران همزمان در VOD کمک بگیرید.
۴. تبدیل بیتریت به حجم ترافیک روزانه و ماهانه
برای برآورد حجم، به مجموع ساعت تماشا نیاز دارید؛ تعداد کاربران بهتنهایی کافی نیست. یک کاربر با چند ساعت تماشا میتواند بیش از چند کاربر با نشست کوتاه ترافیک مصرف کند.
Traffic_GB = Watch_hours × b_media_avg_Mbps × ۰.۴۵
ضریب ۰٫۴۵ از تبدیل ثانیه به ساعت و بیت به بایت حاصل میشود. با بیتریت ۳٫۰۷۸ Mbps، یک ساعت تماشا حدود ۱٫۳۸۵۱ GB رسانه منتقل میکند. برای ۲۰ هزار ساعت تماشا در روز، حجم رسانه حدود ۲۷٬۷۰۲ GB، معادل ۲۷٫۷۰۲ TB است. در ماه فرضی ۳۰روزه، این عدد ۸۳۱٫۰۶ TB خواهد بود.
اگر برای حجم انتقال نیز ضریب فرضی ۱٫۰۸ مناسب باشد، برآورد ماهانه به حدود ۸۹۷٫۵۴ TB میرسد. اما صورتحساب ارائهدهنده ممکن است بر مبنای بایت تحویلی در لایه دیگری محاسبه شود. مبنای صورتحساب، ترافیک Origin، درخواستها و انتقال بین ناحیهای را جدا بررسی کنید.
برای حجم ترافیک، ظرفیت برنامهریزیشده را در کل ماه ضرب نکنید؛ آن ظرفیت برای پیک و حاشیه عملیاتی است. از ساعت تماشای واقعی یا انتگرال نرخ انتقال در طول زمان استفاده کنید.
۵. اثر دانلود قطعهای و موج شروع پخش
پخش ۳ Mbps الزاماً به معنی دانلود یکنواخت با سرعت ۳ Mbps نیست. Player معمولاً قطعات را سریعتر دریافت میکند و سپس تا درخواست بعدی فاصله میاندازد. بنابراین میانگین پهنای باند استریم ویدئو باید در کنار قلههای کوتاهمدت دیده شود.
برای مثال، قطعه ۶ثانیهای با نرخ متوسط ۳٫۰۷۸ Mbps حدود ۲٫۳۰۸۵ MB حجم دارد. دریافت آن در ۲ ثانیه، به حدود ۹٫۲۳۴ Mbps نرخ داده رسانه در همان بازه نیاز دارد. این محاسبه سربار را شامل نمیشود و به معنی الزام سهبرابرکردن ظرفیت کل سرویس نیست؛ همزمانی درخواستها تعیینکننده است.
در شروع پخش یا پس از Seek، Player ممکن است چند قطعه را نزدیک به هم دریافت کند. هنگام انتشار قسمت جدید یا ورود گروهی کاربران، این رفتار میتواند قلهای ایجاد کند که در میانگین پنجدقیقهای پنهان بماند. دادههای بازه کوتاه و سناریوی شروع همزمان را بررسی کنید.
تعداد درخواستها را جدا از پهنای باند بسنجید
اگر ۵۰۰۰ نشست در حالت پایدار، هر ۶ ثانیه یک قطعه صوت و یک قطعه تصویر جدا دریافت کنند، نرخ تقریبی درخواست رسانه ۱۶۶۷ درخواست در ثانیه است. Manifest، زیرنویس، مجوز DRM، Token، Retry و تلهمتری در این عدد نیستند. این تخمین برای قطعات معمولی است؛ الگوهای دانلود و بستهبندی دیگر میتوانند متفاوت باشند.
۶. پهنای باند استریم ویدئو در CDN و Origin
پهنای باند تحویل به بیننده با پهنای باند خروجی Origin یکسان نیست. CDN میتواند محتوای کششده را بدون دریافت مجدد از Origin تحویل دهد. برای تخمین اولیه، نسبت کش بر مبنای بایت از نسبت کش بر مبنای تعداد درخواست مناسبتر است؛ چون همه درخواستها اندازه یکسانی ندارند.
B_origin ≈ B_viewer × (۱ − byte_hit_ratio)
این رابطه فقط یک تقریب با مبنای زمانی و اندازهگیری سازگار است. اگر نرخ تحویل رسانه ۱۵٫۳۹ Gbps و نسبت فرضی بایتهای تحویلی از کش ۹۵٪ باشد، بخش دریافتنشده از کش حدود ۰٫۷۷ Gbps است؛ این عدد هنوز مبنای نهایی خرید ظرفیت Origin نیست.
گرمشدن کش، دانلود ناقص، دریافت قطعات در نقاط متعدد، بازاعتبارسنجی و پیشواکشی میتوانند رابطه بین بایت تحویلی و بایت دریافتی از Origin را تغییر دهند. نرخ واقعی خروجی Origin را مستقیماً ثبت کنید و سناریوی کش سرد را جدا بسنجید.
طبق مستندات Cache Key در CloudFront، واردکردن مقادیر غیرضروری و متغیر در کلید کش میتواند نسخههای تکراری بسازد و درخواست Origin را افزایش دهد. حذف پارامترهای دسترسی فقط وقتی درست است که اعتبارسنجی مجوز همچنان در محل مناسب برای هر درخواست انجام شود.
۷. ظرفیت شبکه در سناریوی خرابی
پهنای باند استریم ویدئو را برای حالت سالم و خرابی جدا محاسبه کنید. اگر دو مسیر مستقل دارید و باید با خروج یکی از آنها سرویس ادامه پیدا کند، مجموع ظرفیت دو مسیر معیار کافی نیست؛ ظرفیت باقیمانده باید بار موردنیاز را با حاشیه تعریفشده تحمل کند.
در مثال نرخ انتقال ۱۶٫۶۲ Gbps، اگر پس از خرابی نیز استفاده هدف ۷۰٪ باشد، مسیر باقیمانده باید حدود ۲۳٫۷۴ Gbps ظرفیت مؤثر برنامهریزیشده داشته باشد. تقسیم این مقدار میان دو مسیر، شرط تحمل خرابی یکی از آنها را برآورده نمیکند.
در توزیع بار میان چند لینک، یک جریان ممکن است نتواند از مجموع پهنای باند همه لینکها استفاده کند. محدودیت پورت، Uplink، فایروال، Load Balancer و ظرفیت منطقهای CDN را همراه با سیاست هدایت ترافیک بررسی کنید.
۸. کاهش مصرف بدون افت بیحساب کیفیت
برای بهینهسازی پهنای باند استریم ویدئو، ابتدا کیفیت ادراکی را روی نمونههای واقعی بسنجید. یک بیتریت ثابت برای سخنرانی کمتحرک و مسابقه ورزشی ممکن است نتیجه یکسانی نداشته باشد. نردبان کیفیت باید با نوع محتوا، دستگاه و شبکه مخاطبان تناسب داشته باشد.
- کیفیتهای کماستفاده یا بیشازحد نزدیک را با داده واقعی بازبینی کنید.
- Codec جدید را همراه با سازگاری Player، هزینه پردازش و مسیر جایگزین ارزیابی کنید.
- دانلود پیشاپیشِ بلااستفاده هنگام خروج زودهنگام کاربر را اندازه بگیرید.
- خطاهای شبکه و Retry غیرضروری را کاهش دهید.
- برای کاهش بار Origin، سیاست کش قطعات نسخهدار را بازبینی کنید.
بهبود کش معمولاً حجم رسانهای را که بیننده برای تماشا دریافت میکند کاهش نمیدهد؛ اثر اصلی آن روی مسیر Origin و نحوه تحویل است. کاهش بیتریت هم باید با کیفیت و رضایت کاربر سنجیده شود، نه فقط کوچکشدن صورتحساب.
۹. چکلیست اندازهگیری و آزمون
پیش از نهاییکردن پهنای باند استریم ویدئو، برای هر ورودی، منبع داده، بازه زمانی و مسئول ثبت مشخص کنید. محاسبهای که فرضهایش ثبت نشده باشد با تغییر محتوا یا رفتار کاربران سریعاً اعتبار خود را از دست میدهد.
- بیتریت واقعی صوت و تصویر و اندازه قطعات را از نمونههای نماینده استخراج کنید.
- سهم زمان پخش هر کیفیت را به تفکیک دستگاه، منطقه و اپراتور بسنجید.
- پیک نشستها، نرخ شروع پخش و مجموع ساعت تماشا را جدا ثبت کنید.
- مصرف شبکه و نرخ درخواست را در CDN، Origin و Player مقایسه کنید.
- آزمون را با کش گرم، کش سرد، Seek و شروع گروهی تکرار کنید.
- خرابی یک مسیر یا نود و توزیع مجدد ترافیک را آزمایش کنید.
- معیار پذیرش را با زمان شروع، توقف پخش و خطاهای کاربر تعریف کنید.
برای بررسی گزینههای پیادهسازی مسیر تحویل نیز میتوانید خدمات میزبانی ویدئوی آوابرید را بررسی کنید؛ ظرفیت موردنیاز باید بر اساس سناریوی آزمون و شرایط سرویس تعیین شود.
سؤالات متداول درباره پهنای باند استریم ویدئو
برای پخش ۱۰۸۰p چه پهنای باندی لازم است؟
یک عدد ثابت برای تمام ویدئوهای ۱۰۸۰p وجود ندارد. Codec، نرخ فریم، پیچیدگی محتوا، بیتریت صدا و رفتار دانلود روی نیاز شبکه اثر دارند. خروجی واقعی Encoder و قطعات را اندازه بگیرید و سپس تعداد نشستها را وارد محاسبه کنید.
آیا مجموع بیتریت همه کیفیتها را باید در تعداد بینندگان ضرب کرد؟
خیر. برای تحویل معمول به بیننده از ترکیب کیفیتهای انتخابشده استفاده میکنیم. جمع همه نسخهها بیشتر به محاسبه فضای ذخیرهسازی خروجی مربوط میشود؛ البته دریافت مجدد و تغییر کیفیت باید در داده واقعی دیده شود.
آیا CDN نیاز به پهنای باند را حذف میکند؟
خیر. بایتهای رسانه همچنان باید به کاربر برسند. CDN بار تحویل را توزیع میکند و با کش مؤثر میتواند بخشی از بار Origin را کاهش دهد. ظرفیت سمت بیننده و Origin را جدا برنامهریزی کنید.
ضریب سربار و حاشیه ظرفیت را چقدر انتخاب کنیم؟
مقدار عمومی و تضمینشدهای وجود ندارد. آنها را با مبنای شمارش بایت، رفتار Retry، قله ترافیک، شرایط خرابی و اهداف کیفیت سرویس تعیین کنید. اعداد ۱٫۰۸ و ۷۰٪ در این مقاله فقط برای روشنشدن روش محاسبهاند.
جمعبندی
محاسبه پهنای باند استریم ویدئو از بیتریت واقعی و ترکیب کیفیتهای مصرفشده شروع میشود. سپس باید نشستهای همزمان، سربار اندازهگیریشده، حاشیه ظرفیت و سناریوی خرابی را اضافه کرد. حجم ماهانه نیز از ساعت تماشا به دست میآید، نه از ظرفیت اسمی پورت.
برآورد عددی نقطه شروع است. تصمیم نهایی را با آزمون بار، داده شبکه و شاخصهای تجربه پخش تأیید کنید و پس از تغییر نردبان کیفیت، Codec یا الگوی مخاطبان، محاسبات را بهروز نگه دارید.