راجع به داستان الگوی سیرکت سوییچینگ گفتیم. اگر زمان تولید دیتا (Generation) نسبت به زمان ایجاد کانکشن طوری باشد که خط هیچوقت خالی نماند، سیرکت سوییچینگ واقعاً روش بسیار خوبی است.
اوایل به سیرکت سوییچینگ AT&T خیلی ایراد میگرفتیم، اما بعدها متوجه شدیم که این الگو آنچنان هم چیز بیموردی نیست. به عنوان مثال، در سال ۱۹۹۳ در آمریکا بحث «شبکههای BroadBand (پهنباند)» مطرح شد که آنجا داشته باشیم؛ بعد جلوتر داستان تلویزیونهای کابلی آمد. اگر میخواستیم به طور کامل از تلویزیون استفاده کنیم، چنل (Channel) آن را در ساختمان فعال میکردند و در اروپا میشد مستقیماً از طریق فیش تلویزیون آن را دید.
بعدها در شبکه وارد کارهای خاصمنظوره شدیم. کارهای ما در شبکه به دو نوع تقسیم میشوند:
این مفاهیم در لایه سختافزار (Hardware) معنی دیگری دارند، اما هرچه الان میگوییم مربوط به لایه نرمافزار (Software) است. وقتی میگوییم یک شبکه کامپیوتری خاص (فعالیت خاصمنظوره) ایجاد کردهایم، انتظار داریم فرد شنونده بپرسد که منظور ما کدام یک از این دو حالت است؟ آیا منظور روی نقل و انتقال، آدرسدهی و روتینگ است، یا راجع به ترکیب خاصی از پارامترهای ارزیابی شبکه صحبت میکنیم؟
ما در شبکه در حوزه Engineering (مهندسی) صحبت میکنیم. وقتی بحث مهندسی مطرح میشود، یکسری بنچمارک (Benchmark) باید وجود داشته باشد که بر اساس آنها بتوانیم تصمیمگیری کنیم. مثلاً بگوییم سید عترتی این کار را خوب انجام داد، اما احسان آن را به افتضاحترین حالت ممکن انجام داده است. این موضوع Directional و سلیقهای نیست؛ باید معیارهایی داشته باشیم و بر اساس آنها برای کاری که انجام میدهیم تصمیمگیری کنیم.
شبکههای کامپیوتری از داستانی موسوم به پارامترهای ارزیابی شبکههای کامپیوتری پیروی میکنند. داستان این پارامترها به تفاوت دیدگاه دنیای آکادمیک و غیرآکادمیک (صنعت) برمیگردد:
برای صحبت در مورد دیلی، ما از یکسری ابزارهایی که از UNIX به ارث بردهایم نظیر Ping یا Trace route استفاده میکنیم.
در دنیای Industry معیار اصلی شبکه دیلی است؛ میگوییم شبکهای از نظر ما جذابتر و بهتر است (پرفورمنس بهتری دارد) که دیلی کمتری داشته باشد. جالب اینجاست که دیلی پارامتری است که متعلق به دنیای شبکههای کامپیوتری نیست، بلکه از دنیای سیرکت سوییچینگ آمده است.
وقتی در سیرکت سوییچینگ B میخواهد با D حرف بزند، معمولاً میتوان ۲ تا ۳ مسیر در نظر گرفت (مثلاً مسیر B -> 1 -> 4 -> 7 -> 6 -> 5 -> 3 -> D).
سوال عباسی: آیا شبکهای داریم که کاملاً بدون دیلی (Delay) باشد؟
پاسخ استاد: نه! ما در زمان پلتفرم اولیه و مدیای اصلی که برای شبکههای آرپانت داشتیم (که بعدها در طراحی شبکههای لوکال هم از آن استفاده کردیم)، پلتفرم مربوط به سیم مسی بود. چون کامپیوتر ما دیجیتال بود و سیم مسی آنالوگ، ماژولار و دیماژولار میکردیم (مودم میگذاشتیم تا تبدیل کند).
آن موقع مودمهای متعارف سرعتهایی نظیر ۱۲.۴، ۲۸.۸، ۳۶.۶ تا نهایت ۵۶ کیلوبایت بر ثانیه داشتند. وقتی کارت تلفن و رمز عبور را میزدیم و دایالآپ (Dial-up) به ISP وصل میشد، انتظار داشتیم در بهترین استیت ۵۶ کیلوبایت سرعت بدهد. اما همیشه دغدغه بود که چرا به ۵۶ نمیرسیم؟ حتی چرا به ۳۶ هم نمیرسیم؟
علتش این است که وقتی در صنعت میگویند ۵۶ کیلوبایت بر ثانیه، این عدد برای یک محیط خلاء و آزمایشگاهی در نظر گرفته شده است (یک Sender و یک Receiver). محیطی که در آن هیچ نویز، هیچ میدان الکتریسیته و مغناطیسی، هیچ میدان ترکیبی از این دو و هیچ پارامتر حرارتی وجود نداشته باشد! در صورت نبودِ هیچ اثری روی کابل (مدیا)، آنوقت سرعت ۵۶ کیلوبایت کار میکرد.
اما در حالت عادی چرا کار نمیکرد؟ چون سیمهای تلفن شما از کنار سیم برق داخل خانهتان رد شده بود، یا سر باکس مخابرات در کوچه، ۳۰ تا ۴۰ نفر به آن وصل بودند. الان هم در اینترنت ADSL همینطور است؛ اپراتور گاهی الکی میگوید: "برو مودم را مستقیماً به جعبهای که دم در خانه آمده وصل کن، اگر آنجا اوکی بود مشکل از سیمکشی داخل خانهتان است و باید آن را عوض کنید". البته دیلی داخل خانه حد مشخصی دارد و بالاتر نمیرود که نویز آنقدر وحشتناک باشد که اینترنت را به صفر برساند (چون اگر نویز اینقدر زیاد بود، من الان نمیتوانستم با خط تلفن با شما صحبت کنم!).
بنابراین ما شبکه بدون دیلی نداریم، چون مدیای بدون دیلی نداریم.
حتی اگر مدیایی پیدا کنیم که بدون نویز و دیلی باشد، به یک دغدغه جدید میرسیم: جنس مدیا با جنس کار کامپیوتر ما فرق دارد.
در صنعت، تأخیر (Delay) معیار خوبی است (اصطلاحاً Latency میگوییم؛ که البته Latency عدد واقعی دیلی در برنامههایی مثل ادوبی است). اما در دنیای واقعیِ شبکههای کامپیوتری، پارامترهای دیگری برای ارزیابی داریم، مثل: جیتر (Jitter)، تروپوت (Throughput) و سرویسگرایی (Service Orientation) و غیره.
وقتی از یک ISP اینترنت میخریم، در آن کاغذها و قراردادهایی که امضا میکنیم، این پارامترها باید ذکر شده باشند. مثلاً نوشته شده باشد که جیتر چقدر باید باشد (از حدی بالاتر قابل قبول نیست) یا تروپوت چقدر باشد و اگر اینترنت شیرینگ (Sharing) میشود، شرایطش چگونه است.
در شبکههای کامپیوتری ارتباط یکطرفه نیست و تبادل (Exchange / داده و ستانده) رخ میدهد. کلماتی که برای آن به کار میبریم از زمان آرپانت گرفته شدهاند: Upload و Download.
ما همیشه فرض میکنیم اینترنت «بالای سر ما» است؛ وقتی چیزی از آن میگیریم میشود دانلود، و وقتی چیزی به شبکه میفرستیم میشود آپلود. دان و آپ دو داستان کاملاً مجزا هستند و الزامی نیست که یک ISP در هر دوی آنها خوب باشد. حتی بعضی شرکتها ممکن است از دو ISP متفاوت استفاده کنند: یکی که فقط آپلود خوبی ارائه میدهد و دیگری که فقط برای دانلود مناسب است.
از بین تمام پارامترها، یک پارامتر مادر یا اصلی داریم که اگر این پارامتر نقض شود، بقیه پارامترها هم خودبهخود نقض شدهاند. این پارامتر تروپوت (Throughput) است که این هم دوباره برگرفته از مخابرات است.
تعریف تروپوت: میزان دادهای که در یک واحد اندازهگیری زمانی مشخص، از عرض مقطع آن مدیایی که در اختیار داریم عبور میکند. کلماتی مثل کیلوبیت، مگابیت و Bit-per-second از همان دنیای مخابرات وارد شبکه شدهاند.
تروپوت پایه و اساس قصه است. اگر نتوانیم راجع به تروپوت صحبت کنیم، بقیه پارامترها حرفهایی توهمی میشوند و چفت و بست علمی ندارند. اگر دیدِ درستی از تروپوت نداشته باشیم، در واقع راجع به کل شبکه دیدی نداریم.
تمام این پیشرفتها در شبکه، افزایش سرعت Mobile Networkها، شبکههای ماهوارهای، خطوط T1, T2, T3 یا B1, B2, B3... همه اینها به یک دلیل است: ما میخواهیم تروپوت را بالا ببریم! اگر بهطور منطقی بتوانیم تروپوت را بالا ببریم، یک پارامتر بسیار عالی برای ارزیابی شبکه ارائه دادهایم و تازه بعد از آن است که مفاهیم Delay و Jitter معنا پیدا میکنند.
تروپوت در خطوط تلفن قدیم هم وجود داشت. مثلاً در سال ۱۹۹۰ زمانی که اتحاد جماهیر شوروی سوسیالیستی فروپاشیده بود و کشورهای تازهاستقلالیافته ایجاد شده بودند؛ وقتی ما از تهران به تفلیس زنگ میزدیم، خطوط ما Full-Duplex بود اما برای آنها Half-Duplex بود (در واقع Semi-Duplex کار میکردند). شرایط اینطور بود که ما یکخورده حرف میزدیم، سپس باید صبر میکردیم تا آن طرف یکخورده حرف بزند و این داستان مدام ادامه داشت! تروپوت در مخابرات آن زمان الگوی دیگری داشت، اما بعدها با دنیا یکسان شدند.
در شبکه، ما روی این تروپوت حساب میکنیم. وقتی میخواهیم در شبکه یک کار خاصمنظوره انجام دهیم، میخواهیم روی این تروپوت بازی کنیم؛ یعنی تروپوت باید یکسری تواناییها (Abilities) برای ما داشته باشد که ویژه باشد. بعدها نام این داستان در دنیای شبکههای کامپیوتری QoS یا کیفیت خدمات (Quality of Service) شد و امروزه بسیار پررنگ است.
مثال: چرا پلتفرم «نماوا» روی اینترنت «شاتل» بهتر نشان میدهد؟
چون آن ارائهدهنده سرویس ویدیو (Video Provider)، روی این ISP خاص، تروپوت را طوری تنظیم و تضمین میکند که وقتی کاربر در خانه نشسته و سریال پایتخت میبیند، ویدیو را فریم به فریم و گیردار نبیند، بلکه به صورت یک Stream یکپارچه جلو برود. در ارتباطات Voice (مثل تماسهای واتساپ) نیز شبکه باید این تروپوت را تضمین و فراهم کند.
پرسش مافی (دانشجو): تروپوت منطقی به زبان ساده یعنی چی؟
پاسخ مافی (از روی متن/دانش): میزان دادهها و عملیات موفقی که یک سیستم در یک واحد زمانی مشخص پردازش یا انتقال میکند، میشود تروپوت منطقی (یعنی حجم دادههای واقعی و نهایی که با موفقیت به مقصد رسیده است). اما تروپوت فیزیکی کل ظرفیت سختافزار یا پهنای باند است؛ مثلاً یک کارت شبکه که میتواند روی کاغذ ۱۰ گیگابایت بر ثانیه داده جابهجا کند.
پاسخ و تکمیل استاد: بله، ما فرض میکنیم دادهها حتماً میرسند و پردازش میشوند.
همیشه سختافزار (Hardware) پنج تا شش پله از نرمافزار (Software) جلوتر است. اکثر چالشها و دغدغههای ما در شبکه روی دوشِ نرمافزار است.
چرا نرمافزار دچار مشکل میشود و میگوییم تروپوت منطقی؟ اگر فرض کنیم کامپیوتر D در ثانیه $a$ واحد داده را پردازش میکند، و من بیایم با ارتقای شبکه، تروپوت را بالا ببرم و داده ورودی را $n \times a$ کنم، این کار دیگر هیچ منطقی ندارد! چون توان پردازشی مقصد محدود است و در نتیجه $n-1$ واحد پردازشی اضافه در صف (Queue) قرار میگیرد. این مثل این میماند که اصلاً دیتایی برای کاربر ارسال نشده باشد، چون در صف منتظر مانده و کامپیوتر مقصد نمیتواند زودتر از توان خودش آن را پردازش کند.
بنابراین Processing نرمافزارها معمولاً خیلی ضعیفتر از توان انتقال سختافزارهاست.
سوال صفری: این موضوع به باتلنک (Bottleneck) هم مربوطه؟
پاسخ استاد: بله دقیقاً. مثلاً ماشین D تبدیل به یک باتلنک برای کل سیستم میشود. همه ماشینها در شبکه دارند با یک تروپوت عالی کار میکنند، اما وقتی به ماشین D (که ماشین من است) میرسد، یک ترافیک وحشتناک ایجاد میشود و دیتا عبور نمیکند؛ زیرا سرعت پردازشِ پایینِ ماشین من، باعث ایجاد باتلنک شده است.
یا اگر گرههای ۲، ۵، ۷ خودشان تبدیل به باتلنک شوند، تروپوت منطقی در موردشان سازگاری ندارد. من میآیم بین گره ۱ و ۲ ترافیک بسیار بالایی ایجاد میکنم اما چون گره بعدی کشش ندارد، عملاً هیچ کاراییای نخواهیم داشت. به همین دلیل تروپوت منطقی یکی از دغدغههای جدی شبکههای کامپیوتری است.
سوال جودکی: پس باتلنک میشه جایی که سرعت انتقال رو به کمترین حد ممکن میرسونه؟
پاسخ استاد: باتلنک جایی است که باعث میشود ورود و خروج تروپوت ما یکسان نباشد. فرض کنید گره ۴ به ۵ دارد با یک سرعتی دیتا منتقل میکند (تروپوت $a$). اما گره ۵ باید یک پردازشی انجام دهد و همین باعث میشود وقتی دیتا را به گره ۳ تحویل میدهد سرعتش بشود $b$. از آنجا که $b$ بسیار کوچکتر از $a$ است، گره ۵ در اینجا برای ما تبدیل به باتلنک شده است.
معمولاً باتلنک بیشتر از نرمافزار ناشی میشود، اما الزاماً فقط نرمافزاری یا سختافزاری نیست، بلکه ترکیبی از هر دو است. هرچه در تکنولوژی جلوتر میرویم، سهم نرمافزار در ایجاد گلوگاهها بیشتر از سختافزار میشود.
تروپوتی که برای تجهیزات فضایی پروژه آرتمیس قرار داده شده بسیار بالاست. دیتایی که آرتمیس میفرستاد، از طریق دیوایسهایی بود که کاملاً Hard Real-Time کار میکردند. اما مشکل بزرگ کجا بود؟ ایستگاههای زمینی که باید این اطلاعات را پردازش میکردند، به اندازه دیوایس فرستنده توانمند نبودند!
در پروژه آرتمیس ۲، ایستگاههای زمینی محاسباتی (مثل بارسلونا، شیکاگو و ایلینوی) دقیقاً همان باتلنکِ پروژه آرتمیس بودند. زیرا دیوایسهای فضایی در لبهی تکنولوژی (End Technology) بودند، اما نرمافزارها و قدرت پردازشِ ایستگاههای زمینی هنوز به آن توانایی و Ability نرسیده بودند.
در طول ۵۰ سال گذشته (از زمان پرتاب آرمسترانگ تا به امروز و آرتمیس)، ما در سختافزار مثل خرگوش (Rabbit) پیشروی و جهش کردهایم، اما در سافتویر آنقدر تفاوت شگرفی نکردهایم و دقیقاً همینجا باتلنک رخ میدهد.
بازگشت به Circuit Switching:
همانطور که گفتیم، برای کارهایی که در آنها میخواهیم پارامترهای ارزیابی (مثل دیلی و جیتر) را تضمین کنیم، الگوی Circuit Switching شبکه بسیار خوبی است. زیرا در روش رقیب یعنی Packet Switching، کارهایی مثل پخش کردن پکتها، آدرسیابی، مسیریابی (Routing) و... به شدت درگیرِ توان پردازشی میشوند.
این پردازشها و عملیات روتینگ باعث میشود تروپوت سیستم به هم بخورد. پس اگر بخواهیم QoS دقیقی داشته باشیم و دیلی و جیتر را مشخص ارائه دهیم، بهتر است به سراغ Circuit Switching برویم.
البته در نهایت یک حالت بینابینی از سیرکت سوییچینگ و پکت سوییچینگ ایجاد کردیم که اسمش را گذاشتیم Virtual Circuit Switching، که در جلسه بعدی راجع به آن صحبت خواهیم کرد.