چگونه «پنجره لغزان» و «تاییدیه تجمعی» تحویل امن داده‌ها در TCP را تضمین می‌کنند

نتیجه یک اتصال اینترنتی پرسرعت و قابل‌اعتماد، در واقع در یک لحظه بسیار خاص تعیین می‌شود: زمانی که کامپیوتر گیرنده فضای بافر در دسترس خود را محاسبه کرده و یک شماره توالی واحد را به فرستنده بازمی‌گرداند. این مرحله که به عنوان «پنجره اعلام‌شده» شناخته می‌شود، تعیین می‌کند که آیا یک لینک فیبر نوری گیگابیتی واقعاً داده‌ها را در حداکثر ظرفیت تئوری خود تحویل می‌دهد یا مانند یک مودم دایال‌آپ قدیمی به کندی پیش می‌رود. بدون این محاسبه، سرعت فیزیکی شبکه کاملاً بی‌اهمیت است.[2]

فروشندگان تجهیزات مخابراتی اغلب سخت‌افزارهای «مسیریابی بهینه‌شده با هوش مصنوعی» یا «بدون تاخیر» را به عنوان راز دانلودهای سریع بازاریابی می‌کنند. اما قابلیت واقعی که سرعت شبکه را کنترل می‌کند، دهه‌ها پیش در پروتکل کنترل انتقال (TCP) عرضه شده است. مکانیزم زیربنایی این پروتکل به هوش مصنوعی متکی نیست؛ بلکه بر یک انتزاع ریاضی به نام «پنجره لغزان» تکیه دارد که در لایه ۴ مدل اتصال متقابل سیستم‌های باز (OSI) عمل می‌کند.

مشکل اصلی که TCP حل می‌کند، تاخیر سرعت نور است که در هر شبکه فیزیکی وجود دارد. در یک پروتکل ابتدایی «توقف-و-انتظار»، فرستنده دقیقاً ۱ بسته داده را ارسال می‌کند و سپس متوقف می‌شود تا پیش از ارسال بسته بعدی، منتظر تایید دریافت آن از سوی گیرنده بماند. همان‌طور که یک بررسی فنی در ژوئیه ۲۰۲۵ توسط GeeksforGeeks اشاره می‌کند، این رویکرد ساده است اما از «کارایی پایین در مقایسه با پروتکل‌های پنجره لغزان رنج می‌برد، زیرا به زمان زیادی برای انتظار جهت دریافت تاییدیه نیاز دارد.»[5]

برای رفع این گلوگاه، TCP مفهوم پنجره لغزان را معرفی کرد. این پنجره در اصل یک مرز منطقی است که نشان‌دهنده تعداد کل بسته‌هایی است که می‌توانند بدون انتظار برای تاییدیه ارسال شوند. به جای توقف پس از هر ارسال، فرستنده مجاز است یک جریان پیوسته از داده‌ها را تا سقف اندازه پنجره به جلو براند.[2][5]

اندازه این پنجره ثابت نیست؛ بلکه به‌صورت پویا بین ۲ دستگاه در حال ارتباط مذاکره می‌شود. هدر TCP از یک فیلد اختصاصی ۱۶ بیتی برای گزارش اندازه بافر در دسترس گیرنده به فرستنده استفاده می‌کند. اگر گیرنده حافظه کافی داشته باشد، یک پنجره بزرگ را اعلام می‌کند که به فرستنده اجازه می‌دهد مگابایت‌ها داده را در یک انفجار واحد ارسال کند.[2]

با ارسال داده‌ها توسط فرستنده، پنجره منطقی روی توالی بایت‌ها به جلو «می‌لغزد». با این حال، پنجره تنها زمانی می‌تواند پیشروی کند که گیرنده تایید کند داده‌ها با موفقیت رسیده‌اند. اینجاست که نیمه دوم این مکانیزم، یعنی تاییدیه تجمعی، برای کارایی پروتکل حیاتی می‌شود.[2][3]

اگر گیرنده ۳ بسته متوالی را با موفقیت پردازش کند، پهنای باند را برای ارسال ۳ پیام تایید جداگانه هدر نمی‌دهد. در عوض، یک تاییدیه تجمعی (ACK) واحد برای بالاترین بایت پیوسته دریافت شده ارسال می‌کند.[3][4]

با ارسال یک ACK برای بسته ۳، گیرنده به‌طور ضمنی تحویل صحیح بسته‌های ۱ و ۲ را تایید می‌کند. بر اساس مستندات شبکه از TutorialsPoint، جایگزینی تاییدیه‌های فردی با ACKهای تجمعی در یک سناریوی استاندارد سه‌بسته‌ای، «ترافیک شبکه را تا ۶۷ درصد کاهش می‌دهد».[3]

رسانه TechTarget توضیح می‌دهد که این ترکیب «جریان بسته بین فرستنده و گیرنده را کنترل و بهینه می‌کند، در حالی که رویکردی متعادل برای تحویل بسته را تضمین می‌نماید.» فرستنده می‌تواند مسیر انتقال خود را پر نگه دارد و عملاً تاخیر رفت‌وبرگشت شبکه را پنهان کند.

با این حال، مکانیزم تجمعی زمانی که شبکه یک بسته را از دست می‌دهد، با چالش قابل‌توجهی روبرو می‌شود. اگر فرستنده‌ای بسته‌های ۱ تا ۵ را ارسال کند، اما بسته ۳ در مسیر گم شود، گیرنده نمی‌تواند بسته‌های ۴ یا ۵ را تایید کند. او تنها می‌تواند یک ACK تجمعی برای بسته ۲ ارسال کند، زیرا این آخرین داده پیوسته‌ای است که دریافت کرده است.[3][4]

وقتی فرستنده ACKهای تکراری برای بسته ۲ دریافت می‌کند، متوجه می‌شود که یک بخش از دست رفته است. در پیاده‌سازی‌های اولیه TCP، فرستنده اندازه پنجره خود را به‌شدت کاهش می‌داد و همه چیز را از بسته ۳ به بعد دوباره ارسال می‌کرد، حتی با وجود اینکه بسته‌های ۴ و ۵ در واقع به سلامت رسیده بودند.[4]

برای حل این ناکارآمدی، مهندسان شبکه افزونه‌ای به نام تاییدیه انتخابی (SACK) را معرفی کردند که در RFC 2018 رسمی شد. SACK به گیرنده اجازه می‌دهد تا اطلاعات بیشتری را به ACK تجمعی خود اضافه کند و عملاً بگوید: «من همه چیز را تا بسته ۲ دارم، و بسته‌های ۴ و ۵ را نیز دریافت کرده‌ام.»[1]

این گزارش‌دهی انتخابی از هدر رفتن پهنای باند ارزشمند فرستنده برای ارسال‌های مجدد و غیرضروری جلوگیری می‌کند. فرستنده تنها همان ۱ بسته خاصی را که گم شده بود دوباره ارسال می‌کند و به پنجره لغزان اجازه می‌دهد تا به محض پر شدن این شکاف، فوراً به جلو حرکت کند.[1]

پنجره لغزان همچنین به عنوان یک مکانیزم دفاعی حیاتی در برابر ازدحام شبکه عمل می‌کند. اگر برنامه گیرنده در پردازش داده‌های ورودی کند باشد، بافر داخلی آن شروع به پر شدن می‌کند. در پاسخ، گیرنده اندازه پنجره ۱۶ بیتی را در ACKهای خروجی خود به‌تدریج کوچک‌تر اعلام می‌کند.[2]

اگر بافر به حداکثر ظرفیت خود برسد، گیرنده اندازه پنجره را دقیقاً ۰ اعلام می‌کند. این «پنجره صفر» به عنوان یک توقف سخت عمل کرده و فرستنده را مجبور می‌کند تا تمام ارسال‌ها را متوقف کند، تا زمانی که گیرنده داده‌های انباشته‌شده را پردازش کرده و دوباره یک پنجره غیرصفر را اعلام نماید.[2]

در نهایت، مکانیزم‌های پنجره لغزان و تاییدیه تجمعی، عمل ارسال را از عمل تایید جدا می‌کنند. پروتکل TCP با جداسازی این دو فرآیند، تضمین می‌کند که تحویل داده‌ها هم کاملاً قابل‌اعتماد و هم بسیار کارآمد باشد و بدین ترتیب، شالوده نامرئی زیرساخت دیجیتال مدرن را شکل می‌دهد.[2]