ما در بحث شبکههای کامپیوتری و رسیدن به QoS (کیفیت خدمات) به این نتیجه برخورد کردیم که پکت سوییچینگ (Packet Switching) رویکرد چندان مناسبی برای ارائه کیفیت خدمات گارانتیشده نیست و باید به سراغ رویکردهای دیگری برویم که بتوانند این موضوع را مدیریت کنند.
از طرفی ویژگیهای سیرکت سوییچینگ برای ما جذاب بود و از طرفی دیگر، پارامترهای پکت سوییچینگ (مانند تروپوت و سایر شاخصهای ارزیابی شبکه که نهایتاً به QoS ختم میشوند) را نیاز داشتیم. دغدغه جدی در QoS این است که من باید در نهایت به کاربر سرویس بدهم و این سرویسدهی باید بر اساس ابعاد و نیازمندیهای مشخصی باشد.
نیاز به یک راهحل میانه باعث شد تا یک روش سوییچینگ جدید انتخاب کنیم به نام Virtual Circuit Switching. در این روش، ما یکسری از چالشهایی که در پکت سوییچینگ داشتیم را با ویژگیها و اِلمانهایی (Attributes) که در سیرکت سوییچینگ وجود داشتند ترکیب کردیم.
نحوه کارکرد: روند کار به این صورت است که وقتی یک مسیر آدرسدهی بین مبدأ و مقصد (مثلاً بین ماشین B و ماشین D) شکل میگیرد، سیستم سعی و تلاش میکند (از کلمه Try استفاده میکنیم، نه Do) تا بقیه پکتها را هم دقیقاً از همان مسیری که دیتای اول را فرستاده، از B به D بفرستد. سیستم در این مسیر تمام نیازمندیهای حاکم (Requirements) اعم از زمان، مکان، ساختار رخدادها و غیره را در نظر میگیرد تا درخواست مقصد (D) برآورده شود.
تفاوت تلاش (Try) در نسخههای قدیم و جدید:
در نسخههای اولیه این سیستم، این تلاش (Try) فقط برای پیدا کردن و حفظ یک مسیر بود. اما در سیستمهایی که امروزه استفاده میکنیم (مثلاً برای استریم فیلم و ویدیو، و مهمتر از آن برای مانیتورینگِ Real-time)، ما ۳ تا ۵ مسیر جایگزین را در نظر میگیریم. سیستم دائماً در این ۳ تا ۵ مسیر سعی میکند انتقال دیتا داشته باشد تا از وضعیت و سلامت این مسیرها خبر داشته باشد.
نکتهای که در اینجا وجود دارد این است که دیگر نمیتوانیم مانند مخابرات قدیم از کلمه "گارانتی" (به معنای تضمین قطعی مسیر) استفاده کنیم. دلیل آن عناصری هستند که در میانه راه قرار گرفتهاند. بین مبدأ و مقصد، ماشینهای سوییچینگ میانی وجود دارند؛ ماشینهایی که وظیفه آدرسدهی و مسیریابی (Routing) را بر عهده دارند.
در دنیای واقعیِ آرپانت یا سیستمهای شبکهای امروزی، ما در میانه راه ماشینهایی داریم که مجموعه آنها را تحت عنوان «ابر شبکه» میشناسیم. ما معمولاً در لبه شبکه (Edge) کار میکنیم و اصلاً کاری نداریم که در داخل ابر شبکه چه اتفاقی میافتد. الزاماً تمام ماشینهایی که داخل این ابر هستند، ماشینهای آدرسدهی، روتر و سوییچ هستند (که البته خود اینها هم ماشینهای کامپیوتری هستند).
در شبکههای سنتی (Traditional) از یک پروتکل یا ساختار از پیش تعیینشده استفاده میکردیم، اما در شبکههایی که از آرپانت نشأت گرفتهاند (مثل اینترنت)، این موضوع متفاوت است.
در شبکههای مبتنی بر اینترنت، داستان عجیبی وجود دارد: ما چیزی به اسم «اینترنت فیزیکال» نداریم! نمیتوانیم به یک کابل اشاره کنیم و بگوییم "این کابل، کابلِ اینترنت است". فیزیکالی به عنوان اینترنت وجود خارجی ندارد.
این هنر طراحان اولیه در آرپانت بود. در اینترنت چیزی به نام «لایه فیزیکال» (Physical Layer) دیده نمیشود و اصلاً راجع به آن حرف نمیزنیم. به همین دلیل اصطلاحی که برای آن به کار میبرند Meta Network است؛ یعنی شبکهای از شبکهها.
محوریت اینترنت به جای اینکه روی زیرساخت فیزیکی سوار شود، روی بحث مسیریابی (Routing) است.
فرض کنید ماشینی به نام B وجود دارد. دادهای وارد ماشین B میشود. ماشین B نگاه میکند که آیا این آدرس متعلق به خودش است یا نه. اگر نبود، نگاه میکند که آیا مقصد در شبکه محلی خودش قرار دارد یا خیر. اگر در شبکه محلی خودش نبود، آن را به اولین شبکه دیگری که متصل است میفرستد.
تغییر مدیا در میانه راه:
فرض کنید شبکه قبل از ماشین B مبتنی بر کابل مسی Ethernet (مثل Cat6) است، و بعد از ماشین B شبکه تبدیل به فیبر نوری اپتیکال میشود. اتفاقی که در اینترنت میافتد این است که وقتی دیتا روی شبکه Cat6 حرکت میکند، در ابتدا و انتهای آن (هدر و تریلر) اطلاعات مربوط به مسیر شبکه Cat6 چسبیده است. وقتی داده وارد ماشین B میشود تا روی فیبر نوری قرار بگیرد، سیستم آن هدر و تریلر قبلی را دور میاندازد و هدر و تریلر مربوط به فیبر نوری را به آن متصل میکند.
به همین خاطر است که لایه فیزیکی یکپارچهای به اسم اینترنت وجود ندارد!
مزیت این ساختار چیست؟
اینکه لایه فیزیکال وجود ندارد یک نقطه قوت است. این باعث میشود اینترنت دارای Scalability (مقیاسپذیری بالا)، Openness (متنباز و آزاد بودن) و Transparency (شفافیت) باشد. شما میتوانید یک تکه از مسیر را با فیبر، یک تکه را با شبکه سنتی، یک تکه را وایرلس (بیسیم) و تکهای دیگر را با ماهواره کار کنید و سیستم اصلاً به لایه فیزیکال وابستگی (Dependency) نخواهد داشت.
نقطه ضعف آن چیست؟ (قانون تطبیق حلکننده مسئله بر مسئله)
ما یک اصل داریم که میگوید: «هرچقدر حلکننده مسئله نسبت به خود مسئله اشراف بیشتری داشته باشد، مسئله را با پرفورمنس بهتری حل میکند.»
چون در اینترنت سیستم از لایه مدیا (فیزیکی) کاملاً بیخبر است، هیچوقت خودش را با آن تطبیق نمیدهد. این بیخبری باعث کاهش کارکرد (Performance) میشود؛ اما در نقطه مقابل، ما توانستیم ساختاری بسازیم که فوقالعاده گسترده (Scalable) است.
وقتی من از شبکههای دیگران استفاده میکنم (همان ابر شبکه)، آن شبکه دیگر مال من نیست و تحت حاکمیت (Under Govern) من قرار ندارد. در نتیجه هیچ نظارتی ندارم که اگر دیتایی را فرستادم، آیا صاحب آن شبکه یکدفعه کرکره را پایین میکشد و میرود خانهشان یا نه! هیچ گارانتیای در مورد این مسائل ندارم.
این بیخبری از اتفاقات زیرین، یک Delay وحشتناک ایجاد میکند که مجبوریم با آن کنار بیاییم؛ دیلیای که در حکم به هم زننده QoS ماست.
وقتی اطلاعات از ماشینهای میانی عبور میکند، آیا آنها به اطلاعات ما دسترسی دارند و میتوانند تغییری در آن ایجاد کنند؟ اینترنت برای رفع این نگرانی از دو ساختار استفاده میکند:
به همین خاطر دغدغهای از بابت ماشینهای میانی نداریم.
مشکل دیگر ماشینهای میانی این است که وقتی یک داده به آنها میرسد، ممکن است آن ماشین داده را روی تمامی پورتهای خودش در چندین مسیر مختلف ارسال کند (Broadcast). این کار از یک طرف ریسکِ نرسیدنِ دیتا به مقصد را کاهش میدهد، اما از طرف دیگر باعث ایجاد Overhead (سربار) وحشتناکی در سیستم میشود.
برای حل این مشکل مفهومی مطرح شد به نام Under Controlled Redundancy (ریداندنسی کنترلشده).
اصول کار این است که بر اساس یک مکانیزم مسیریابی، گره ۴ میفهمد که باید پیغام را روی مسیر ۷ قرار دهد. اما چون وضعیت مسیر ۷ نامشخص است (QoS تضمینشده نیست)، پیغام را به مسیر ۵ هم میفرستد (یک مسیر اصلی و یک مسیر کمکی). به این کار در اینترنت ریداندنسی کنترلشده میگویند.
پرسش چاوشی: سوال اصلی این است که خود این برودکستینگ چه مشکلاتی ممکن است ایجاد کند؟
توضیح استاد: کلمه ریداندنسی کنترلشده در شبکههای لارجاسکیل (مقیاس بزرگ) مثل اینترنت بسیار چالشبرانگیز است. با اینکه اسم آن "کنترلشده" است، اما باز هم ممکن است باعث فاجعه شود. این کنترل فقط در لحظه اول امکانپذیر است، اما از یک ثانیه بعد دیگر نمیتواند کنترل شود!
چاوشی: آیا مشکل امنیتی است؟
پاسخ استاد: نه! ما اول باید پرفورمنس (Performance) برقرار کنیم بعد راجع به بقیه چیزها بحث کنیم. این ریداندنسیِ کنترلشده، خودِ پرفورمنس را نقض میکند. وقتی پرفورمنس نقض شد، حالا تو بگو من امنترین و Reliableترین شبکه دنیا را دارم، چه فایدهای دارد؟ در اینجور مسائل در لحظه اول به سراغ بحث سکیوریتی نروید.
علت اصلی اینکه ریداندنسی از کنترل خارج میشود این است که در اینترنت سرور مرکزی یا نقطه مرکزی وجود خارجی ندارد.
وقتی دیتا از شبکه من خارج شد و به شبکه بعدی افتاد، آن شبکه از حاکمیت (Govern) من خارج شده است و من نمیتوانم برایش قانون بگذارم. هر مکانیزمی که در شبکه خودم برای کنترل ریداندنسی نوشته بودم، الزاماً در شبکه بعدی برقرار نمیشود.
چون کسی نیست که کنترل را در دست داشته باشد، ما به جای کلمه (Single Point of Failure)، با مشکلِ نبودِ Single Point of Controller روبهرو هستیم. به همین دلیل در شبکههای گسترده، برودکستهای کنترلشده خیلی زود از بین میروند و به برودکستهای غیرقابل کنترل تبدیل میشوند.
سوال تقیلو: وقتی ریداندنسی کنترلشده منجر به مشکل میشود، راهحل چیست؟
پاسخ استاد: راهحل ندارد! این قصه بدون راهحل است. چون راهحل کلامیِ آن وجود یک Single Point Controller است که در شبکههای لارجاسکیل غیرممکن است. ما فقط یک انتخاب داریم: یا آنقدر به شبکه و Response Time نیازمندیم که این سربارِ ریداندنسی را میپذیریم، یا اگر برایمان مهم نیست، از انجام آن اجتناب میکنیم. این مسئله تا به امروز در شبکه حل نشده است.
ما از کلمه "سرویس" زیاد استفاده میکنیم. در دنیای واقعی، سرویس به خدمات پایهای شبکه اشاره دارد. ما نمیتوانیم برای هر چیزی در اینترنت گارانتی و QoS ارائه دهیم؛ اگر آن خدمت جزو سرویسهای پایه نباشد، اعلام گارانتی برای آن غیرممکن است (وقتی فونداسیون چیزی وجود نداشته باشد، چطور میتوانیم راجع به برآورده کردن آن صحبت کنیم؟).
در زمان آرپانت وقتی شبکه دو شاخه شد (به اینترنت و میلنت)، ما یک چیز واحد به اسم اینترنت تعریف نکردیم؛ بلکه ترکیبی از ۷ سرویس را "اینترنت" نامیدیم (که الان در نسل پنجم اینترنت قرار داریم). این سرویسهای پایه عبارتند از:
سرویسی در اینترنت قابل تضمین (QoS) است که بتوان آن را به یکی از این سرویسهای پایهای نگاشت کرد. در بین همه اینها، سرویس World Wide Web (WWW) متعارفترین سرویس است، طوری که امروزه ۶ سرویس دیگر نیز خدماتشان را روی بستر WWW ارائه میدهند، در حالی که در سیستماتیک شبکهای کاملاً از هم مستقل هستند.
سوال استاد: در مورد چه خدماتی باید الزاماً سیرکت سوییچینگ داشته باشیم، کجا ویرچوال استفاده کنیم و برای چه خدماتی اصلاً نباید از پکت سوییچینگ استفاده کرد؟
پاسخ حسن (دانشجو): سرویسهایی که Real-timeتر (برخط) هستند و نیاز دارند در لحظه پاسخ بدهند یا بشنوند، بهتر است از روش ویرچوال سیرکت سوییچینگ یا خودِ سیرکت سوییچینگ استفاده کنند. (وی اشاره کرد که ریلتایم دو نوع است: Hard Real-time و Soft Real-time).
توضیح و اصلاح استاد: ما به هیچ وجه نمیتوانیم هارد ریلتایم (Hard Real-time) را روی اینترنت بیاوریم! مثلاً ناسا نمیتواند پرتاب موشک را به اینترنت متصل کند که اگر یک لحظه اینترنت قطع شد بگوید "خب پرتاب را ولش کن!".
عملاً چیزی که راجع به ریلتایم در شبکههای اینترنتی صحبت میکنیم، سافت ریلتایم (Soft Real-time) است که پروتکلهای خاص خودش را دارد. در سافت ریلتایم، اگر اطلاعات دیوایسی یک لحظه جابهجا شد یا نشد، فاجعه غیرقابل جبرانی رخ نمیدهد.
پکت سوییچینگ به هیچ عنوان نمیتواند در شبکههای تلفن و انتقال صدا قرار بگیرد؛ چون ذاتِ صدا پیوسته (Continuous) است و صدای پیوسته نیازمند سیرکت سوییچینگ (یا مسیر تضمینشده) است.
به عنوان یک مثال تجاری: دلیل اصلی اینکه مایکروسافت، نرمافزار Skype را با آن عظمت عملاً تعطیل کرد، هزینههای بسیار بالای انتقال دیتای پیوسته و حفظ کیفیت آن بود.
جمعبندی نهایی: ذاتِ اینترنت مبتنی بر پکت سوییچینگ است. اما یکسری سرویسها هستند که باید آنها را روی سیرکت سوییچینگ ببریم، چون در غیر این صورت کاربر دچار مشکل میشود. تأمین QoS در شبکه، نیازمند رعایت تمام این بایدها و نبایدهاست.