نیازمندی های عملکرد اپلیکیشن

نیازمندی های عملکرد اپلیکیشن ها در شبکه – آموزش شبکه درس 21

یکی از موضوعات مهم در شبکه بررسی نیازمندی های عملکرد اپلیکیشن هایی است که بر روی یک شبکه راه‌اندازی می شوند. هر اپلیکیشنی که بر روی شبکه مشغول به کار است نیازمندی های عملکردی مشخصی دارد. این موارد می تواند شامل پهنای باند، سرعت، تاخیر و حجم بسته های اطلاعاتی باشد که در اختیار آن قرار می گیرد. در این پست قصد داریم که به بررسی دقیقتر این موضوع بپردازیم و ببنیم که طراحان شبکه چطور درباره نیازمندی های عملکرد اپلیکیشن ها بر روی شبکه فکر می کنند.

نیازمندی های عملکرد اپلیکیشن  ها در شبکه

موضوعی که در این بخش مطرح می شود، یک دیدگاه شبکه محور در زمینه عملکرد است؛ بنابراین ما بر اساس آنچه که یک لینک یا کانال می تواند پشتیبانی کند صحبت خواهیم کرد. فرض اظهار نشده در این جا بیان می کند که نرم افزارهای و برنامه ها دارای نیازمندی های ساده ای هستند، آنها می خواهند بیشترین پهنای باند ممکن در یک شبکه متعلق به آن ها باشد. این موضوع که در پست قبلی درباره کتابخانه های دیجیتالی و برنامه ای که باید یک ایمیج 250 مگابایتی را بازیابی کند، تا اندازه ای درست است؛ پهنای باند بیشتر، سبب می شود که برنامه بتواند بسیار سریعتر تصویر را به کاربر تحویل دهد.

هرچند، برخی ااز نرم افزارها این قابلیت را دارند که تعیین کنند که چقدر پهنای باند را نیاز دارند. برای مثال، برنامه های ویدئو کنفرانس یکی از این موارد هستند. فرض کنید که یک نفر بخواهد یک ویدئو را در یک چهارم اندازه واقعای ان تماشا کند، در این صورت رزلوشن تصویر وی برابر با 353 در 240 پیکسل خواهد بود. اگر هر کدام از این پیکسل ها دارای حجم اطلاعاتی برابر با 24 بیت باشند (که برای نمایش رنگ و مکان پیکسل به کار می روند) در این صورت حجم هر فریم از این ویدئو به صورت (352 × 240 × 24) / 8 = 247.5 kB محاسبه می شود. اگر نرم‌افزار نیازمند آن باشد که به ازای هر ثانیه 30 فریم دریافت کند، در ان صورت ما به توان عملیاتی 75 مگابیت بر ثانیه نیاز داریم. توانایی شبکه برای ایجاد چنین پهنای باندی زیاد مورد علاقه و توجه نیست، زیرا این حجم داده برای انتقال در شبکه حجم زیادی از فعالیت و توان عملیاتی را می طلبد.

متاسفانه، شرایط انتقال داده به سادگی که در بالا دیدیم نیست. به خاطر این که تفاوت میان دو فریم پیاپی در یک استریم ویدئوی بسیار کم است، این امکان وجود دارد که تنها اختلاف ها را انتقال داد و نیازی به  انتقال بخش های یکسان وجود ندارد. هر کدام از فریم ها را نیز می توان به صورت فشرده در آورد و نیازی نیست که تمام جزئیات تصویر با همان قدرتی که چشم انسان قادر به مشاهده است را انتقال دهیم. همچنین در اینجا نیازی نیست که ویدئوهای فشرده شده را با نرخ ثابت ارسال کنیم، زیرا زمان را می توان بسته به تغییری که در فعالیت ها و جزئیات یک تصویر رخ می دهد تنظیم کرد، و حتی می توان از الگوریتم ها فشرده سازی ویژه ای برای این منظور استفاده کرد. به همین خاطر، این احتمال وجود دارد که بگوئیم با این کار ما به یک پهنای باند متوسط نیازمند هستیم، اما نرخ لحظه ای استفاده از پهنای باند در اینجا می تواند کم و یا زیاد باشد.

موضوع کلید در اینجا میان بازه زمانی کلی است که می بایست مورد محاسبه قرار گیرد. فرض کنید که در اینجا ویدئو مورد نظر ما می تواند با ویدئوهایی که تا 2 مگابیت بر ثانیه به صورت متوسط فشرده شده اند کار کند. اگر شما بتوانید 1 مگابایت را در هر بازه یک ثانیه ا و 3 مگابایت را در بازه یک ثانه ای بعد انتقال دهید، پس در اینجا ما با یک بازه 2 ثانیه ای روبرو خواهیم بود، این یعنی آنکه ما در هر ثانیه در کل توانسته ایم 2 مگابایت اطلاعات را به صورت متوسط عبور دهیم؛ هرچند شاید دانستن این که کانال می تواند تا بیش از 2 مگابیت بر ثانیه را عبور دهد، برای کارشناسان شبکه تسلی بخش و دلگرم کننده باشد. واضح است که در اینجا تنها دانستن پهنای باند متوسط مورد نیاز نرم افزارها همیشه کافی نخواهد بود.

هرچند، به صورت کلی، این امکان وجود دارد که بتوان به آستانه های بسیار بزرگتری دست پیدا کرد، اگر نرم افزاری شبیه این بتواند به خوبی داده ها را برای انتقال آماده کند (برای مثال داده های غیر ویدئویی را در نظر بگیرید). یک افزایش فوق‌العاده (Burst) را می توان به صورت نرخ حداکثری (Peak Rate) توضیح داد که می توان برای مدت زمان مشخصی آن را حفظ کرد. از طرف دیگر، آن را می توان به عنوان تعداد بایت های که می توان در نرخ حداکثری (Peak Rate) قبل از بازگشت به نرخ میانگین (Avarage Rate) و یا نرخ حداقلی (Lower Rate) ارسال کرد در نظر گرفت. اگر این نرخ حداکثری (Peak Rate) بالاتر از توانائی و ظرفیت در دسترس کانال باشد، در آن صورت داده ها یمازاد باید در جائی برای مدتی بافر (Buffer) یا ذخیره‌سازی موقت شوند، تا بعد از مدت زمان مشخصی انتقال داده شوند. دانستن این که مقدار افزایش فوق‌العاده (Burst) تا چه میزان می تواند باشد، این امکان را به طراح شبکه می دهد که بتواند مقدار ظرفیت بافر (Buffer) کافی را برای نگهداشتن داده ها در زمان اوج ارسال داده (Burst) اختصاص دهد.

به زبان دیگر می تواند گفت پهنای باند مورد نیاز می تواند تمام چیزی باشد که یک نرم‌افزار توان دریافت آن را از شبکه دارد، الزامات تاخیری در اینجا می تواند بسیار پیچیده‌تر از این باشد و می تواند «میزان تاخیر ممکن» در زمان ارسال داده ها باشد. در مورد تاخیر، گاهی از اوقات، مسئله ای نیست که تاخیر یک سویه شبکه ما 100 یا 500 میلی ثانیه باشد، بلکه در اینجا تاخیر ارسال هر کدام از پاکت های داده می تواند متغییر باشد. تغییر در تاخیر به نام جیتر (jitter) یا دامنه نوسان تاخیر، نامیده می شود.

برای درک بهتر، شرایطی را در نظر بگیرید که در آن منبع اقدام به ارسال بسته در هر 33 میلی ثانیه می کند، این موضوع می تواند برای انتقال 30 فریم در ثانیه به کار رود. اگر بسته ها در مقصد دقیقا در همان 33 میلی ثانیه دریافت شوند، در آن صورت می توانید بگوئید، که تاخیر تجربه شده برای هر کدام از بسته های داده با تاخیر کل شبکه به صورت کاملا یکسانی است. اگر بسته هائی که به مقصد می رسند، با فاصله زمانی باشند، که گاهی از اوقات به آن ها شکاف میان بسته ای (interpaket gap) گفته می شود، در آن صورت تاخیر تجربه شده توسط توالی بسته ها نیز متغیر خواهد بود، در این صورت کفته می شود که شبکه یک جیتر (jitter) و یا دامنه نوسان تاخیر را در جریان ارسال داده وارد کرده است، برای درک بهتر موضوع به تصویر 1.20 نگاه کنید. چنین تغییر به صورت معمول در یک لینک فیزیکی تعریف نمی شود، اما این نوع تاخیر می تواند در صف های مختلف ارسال پاکت های داده که به صورت صفی بر روی یک شبکه سوئیچ شده بسته ای ارسال می شوند و از چند مسیر ارسال در آن ها استفاده می شود، بروز پیدا کند. این صف بندی تاخیر وابسته به اجزای تاخیری است که در بالا و پست های قبل به عنوان تغییرات زمانی ارسال، درباره آن ها صحبت کردیم.

جیتر (jitter) معرفی شده در شبکه

تصویر 1.20، جیتر (jitter) معرفی شده در شبکه

برای درک رابطه میان جیتر (jitter)، فرض کنید که بسته هایی که بر روی یک شبکه ارسال می شوند، حاوی فریم های مختلف یک ویدئو هستند، و به خاطر نمایش این فریم ها بر روی صفحه نمایش، نیازمند آن هستیم که فریم جدید را بتوانیم در 33 میلی ثانیه دریافت کنیم. اگر فریم ها زودتر برسند، در آن صورت به سادگی می توانیم آن ها را ذخیره کنیم، تا آنکه زمان پخش آن ها فرا برسد.متاسفانه، اگر فریم ها با تاخیر برسند، در آن صورت دریافت کنند، فریم های کافی برای به روز رسانی تصویر را ندارد و در نتیجه کیفیت پخش ویدئ
و کاهش پیدا کرده و پخش ویدئو با وقفه خواهد بود و این برای مخاطب اصلا مناسب نیست.  دقت کنید که در اینجا نیازی به حذف جیتر (jitter) نیست، بلکه باید بدانیم که این موضوع تا چند اندازه بد است و چطور باید با آن برخورد کرد. دلیل استفاده از جیتر و یا دامنه نوسان تاخیر برای آن است که اگر دریافت کننده بتواند آستانه های بالائی و پائینی را به دست بیاورد، در آن صورت می تواند تاخیر را محاسبه کند و پس از یک تاخیر مشخص اقدام به پخش ویدئو کند (برای مثال اولین فریم با کمی تاخیر شروع به پخش می کند تا بقیه فریم ها لازم دریافت شود)، در نتیجه این کار، همیشه مدت زمان کافی در دسترس است تا تمامی فریم های مورد نیاز دانلود شود. در اینجا با ذخیره سازی موقت بسته ها در طی دامنه نوسان تاخیر متفاوت این امکان به وجود می آید که پخش ویدئو بسیار یک دست و بدون تاخیر باشد.

No votes yet.
Please wait...

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد.

منو اصلی

question