TCP: مطمئن شدن از رسیدن همه‌چی
بسته‌ها ممکنه گم بشن، تکراری بشن یا نامرتب برسن، برای همین TCP یه مکالمه می‌ذاره روش: یه دست‌دادن برای باز کردن خط، یه شماره روی هر تیکه، و یه ارسال دوباره هر وقت تأییدیه نیومد. می‌بینی کجا این صبر کردن ارزشش رو داره، و کجا یه تماس یا یه بازی عمداً ازش رد می‌شه.
مسئله
بسته‌ها قول نمی‌دن برسن، سر جاشون برسن، یا حتی فقط یه‌بار برسن
بسته‌ها به تنهایی هیچ تضمینی نمی‌دن. یه روتر شلوغ می‌تونه یکیشون رو گم کنه، یه تلاش دوباره می‌تونه یه کپی بفرسته که با یکی دیگه تکراری بشه، و بسته‌هایی که پشت سر هم فرستاده شدن ممکنه با ترتیبی غیر از ترتیب رفتنشون برسن. برای یه پیام کوتاه و بی‌اهمیت این معمولاً مشکلی نداره. برای یه فایل، یه صفحه، یا یه پرداخت، یه تیکه‌ی گم‌شده یا جابه‌جاشده واقعاً مشکل‌سازه.
شبیه اینه که یه کتاب رو صفحه‌به‌صفحه، هر کدوم توی یه پاکت جدا، از چند تا اداره‌ی پست رد کنی. ممکنه بعضی صفحه‌ها گم بشن، بعضیا دوبار برسن، و لزوماً هم به ترتیب صفحه‌ها نمی‌رسن.
خودت رو امتحان کن
نگار یه فایل دانلود می‌کنه، و وسط راه، یه بسته که بخشی از فایل رو داشته اصلاً نمی‌رسه. چرا این چیزیه که شبکه باید فعالانه باهاش کنار بیاد، نه یه چیزی که اصلاً پیش نمیاد؟
- چون تضمین شده هر بسته دقیقاً یه بار برسه، پس گم شدنش فقط می‌تونه یه باگ نادر توی اتصالش باشه
- چون بسته‌ها ممکنه گم بشن، تکراری بشن یا نامرتب برسن، و هیچی تو راه خودبه‌خود جلوی این رو نمی‌گیره
- چون گوشیش اون بسته رو اشتباهی به یه آدرس غلط فرستاده
- چون فایل اون‌قدر بزرگ بوده که درست به بسته تقسیم نشده
جواب رو ببین
چون بسته‌ها ممکنه گم بشن، تکراری بشن یا نامرتب برسن، و هیچی تو راه خودبه‌خود جلوی این رو نمی‌گیره
درسته. هیچی توی مسیر یه بسته تضمین نمی‌کنه که برسه، فقط یه‌بار برسه، یا سر جاش برسه. هر چیزی که نیاز داره یه پیام کامل باشه، باید خودش این رو چک کنه.
راه‌حل
TCP بسته‌ها رو تبدیل به یه مکالمه می‌کنه
TCP روی بسته‌های ساده می‌شینه و اون رفت‌وآمدی که برای تحویل مطمئن لازمه رو اضافه می‌کنه. قبل از اینکه هیچ داده‌ی واقعی حرکت کنه، دو طرف اتصال رو با یه دست‌دادن کوتاه باز می‌کنن: SYN، بعد SYN-ACK، بعد ACK؛ سه پیام که تأیید می‌کنن هر دو طرف آماده و منتظرن.
فقط بعد از تموم شدن این دست‌دادن، TCP شروع می‌کنه به شماره‌گذاری تیکه‌هایی که می‌فرسته و منتظر یه جواب برای هر کدوم می‌مونه؛ چیزی که ادامه‌ی این مکالمه رو ممکن می‌کنه.
خودت رو امتحان کن
دست‌دادن TCP دقیقاً به سه پیام نیاز داره، یکی برای پرسیدن، یکی برای قبول کردن و پرسیدن دوباره، و یکی برای تأیید نهایی، قبل از اینکه هر کدوم از دو طرف داده‌ی واقعی بفرسته.
جواب رو ببین
درست
درسته. SYN سؤال رو باز می‌کنه، SYN-ACK جوابش رو می‌ده و همون سؤال رو برمی‌گردونه، و ACK این حلقه رو می‌بنده. فقط بعد از این سه پیام هر دو طرف شروع می‌کنن به فرستادن داده‌ی واقعی.
قدم‌به‌قدم ببین
کلاینت درخواست باز کردن اتصال می‌ده: SYN گوشیت، یعنی کلاینت سمت چپ، یه پیام تنها به سمت سرور سمت راست می‌فرسته: SYN، مخفف synchronize. هنوز هیچ اتفاق دیگه‌ای نیفتاده، هیچ داده‌ای رد نشده، فقط همین یه سؤال شروع‌کننده: می‌تونیم حرف بزنیم؟
سه پیام، و هر دو طرف وصل شدن سرور با SYN-ACK جواب می‌ده، هم قبول می‌کنه هم همون سؤال رو برمی‌گردونه، و کلاینت با ACK جواب می‌ده. این‌ها روی‌هم سه پیامن، یعنی دست‌دادن، و حالا یه حلقه دور هر دو سر ظاهر می‌شه: اتصال باز شده و هر دو طرف می‌دونن.
یه تیکه تأیید شد، تیکه‌ی بعدی گم شد بالاخره داده‌ی واقعی می‌تونه حرکت کنه: تیکه‌ی ۱ رد می‌شه و سرور با ACK 1 تأییدش می‌کنه. تیکه‌ی ۲ بلافاصله بعدش فرستاده می‌شه، ولی هیچ‌وقت نمی‌رسه؛ اون X نارنجی روی خط نشون می‌ده وسط راه گم شده، و هیچ تأییدیه‌ای هم براش نمیاد.
تأییدیه سر وقت نرسید، پس دوباره فرستاده می‌شه کلاینت برای هر تیکه‌ای که می‌فرسته یه تایمر کوچیک نگه می‌داره، و این‌یکی بدون اینکه ACK 2 برسه تموم می‌شه، همون ساعتی که کنار کلاینت نشون داده شده. پس تیکه‌ی ۲ دوباره فرستاده می‌شه، و این‌بار ACK 2 برمی‌گرده. هیچی که مهم بوده برای همیشه گم نشده، فقط یه رفت‌وبرگشت اضافه هزینه داشته.
خودت رو امتحان کن
توی فریم‌هایی که تازه دیدی، بعد از گم شدن تیکه‌ی ۲ چه اتفاقی افتاد؟
- اتصال بسته شد و باید با یه دست‌دادن جدید دوباره باز می‌شد
- کلاینت صبر کرد تا سرور خودش متوجه بشه و دوباره تیکه رو بخواد
- تایمر خود کلاینت بدون رسیدن ACK 2 تموم شد، پس خودش تیکه‌ی ۲ رو دوباره فرستاد
- تیکه‌ی ۲ برای همیشه رد شد و فقط تیکه‌ی ۳ رسید
جواب رو ببین
تایمر خود کلاینت بدون رسیدن ACK 2 تموم شد، پس خودش تیکه‌ی ۲ رو دوباره فرستاد
درسته. کلاینته که تایمر رو نگه داشته. وقتی ACK 2 قبل از تموم شدن تایمرش نرسه، خودش تیکه‌ی ۲ رو دوباره می‌فرسته، بدون نیاز به یه دست‌دادن جدید.
چطور همه‌چی جمع می‌شه
تیکه‌های شماره‌دار، یه تأییدیه برای هر کدوم
هر تیکه‌ای که TCP می‌فرسته یه شماره داره، تا طرف مقابل بتونه حتی اگه نامرتب برسن دوباره سر جاشون بذارتشون، و یه نگاه بندازه ببینه کدوم شماره‌ها هنوز نرسیدن. هر تیکه‌ای که برسه تأییدیه‌ی خودش رو می‌گیره؛ هر چیزی که بعد از یه مدت تأیید نشه، گم‌شده حساب می‌شه و دوباره فرستاده می‌شه، دقیقاً همون اتفاقی که برای تیکه‌ی ۲ دیدی.
برای همینه که یه تیکه‌ی کمی دیرکرده به‌ندرت خودش به‌تنهایی چیزی رو خراب می‌کنه: TCP فقط چیزی که رسیده رو نگه می‌داره، صبر می‌کنه، و وقتی ارسال دوباره برسه جاش می‌ذاره.
خودت رو امتحان کن
هر واژه رو به معنیش وصل کن
جواب رو ببین
- SYN → اولین پیام، درخواست باز کردن اتصال
- SYN-ACK → جواب سرور، هم قبول کردن هم پرسیدن دوباره
- ACK → تأیید می‌کنه یه تیکه، یا خود دست‌دادن، رسیده
- ارسال دوباره → فرستادن دوباره‌ی یه تیکه بعد از اینکه ACKش سر وقت نرسید
همیشه ابزار مناسب نیست
کجا صبر TCP می‌ارزه، کجا نه
یه فایل دانلودشده یا یه صفحه‌ی لودشده باید کامل باشه؛ یه تیکه‌ی گم‌شده واقعاً می‌تونه خرابش کنه، پس صبر کردن برای ارسال دوباره ارزشش رو داره. یه تماس تصویری زنده یا یه بازی آنلاین فرق داره: گم شدن یه کسر ثانیه تقریباً حس نمی‌شه، ولی مکث کردن برای صبر کردن به ارسال دوباره‌ش به‌شکل یه پرش دیده می‌شه، که بدتره. برای این‌جور ترافیک معمولاً یه جایگزین به اسم UDP استفاده می‌شه، که از تأییدیه و ارسال دوباره صرف‌نظر می‌کنه و فقط ادامه می‌ده.
این معامله رو می‌شه توی یه خط گفت: TCP کامل بودن رو انتخاب می‌کنه حتی اگه کندتر باشه؛ UDP ادامه دادن رو انتخاب می‌کنه حتی اگه بعضی‌وقتا یه تیکه رو جا بندازه.
خودت رو امتحان کن
- یه به‌روزرسانی نرم‌افزار دانلود می‌کنی. یه بسته نزدیک آخر گم می‌شه؛ برنامه یه لحظه مکث می‌کنه، دوباره می‌فرستدش، و وقتی تموم می‌شه فایل دقیقاً درسته.
- توی یه تماس تصویری هستی و یه بسته که یه کسر ثانیه صدا داشته گم می‌شه؛ تماس یه لحظه قطع‌ووصل می‌شه و ادامه پیدا می‌کنه، بدون اینکه اصلاً اون بسته دوباره فرستاده بشه.
بهترین توضیح برای اینکه این دو مورد این‌قدر متفاوت مدیریت می‌شن چیه؟
- بسته‌ی گم‌شده‌ی تماس تصویری کوچیک‌تر بوده
- دانلود از TCP استفاده می‌کنه، که برای یه نتیجه‌ی کامل صبر می‌کنه و دوباره می‌فرسته، ولی تماس زنده موندن رو به کامل بودن ترجیح می‌ده
- شرکت اینترنتی طرف تماس فقط اینترنت بدتری داره
- به‌روزرسانی نرم‌افزار اصلاً اجازه نداره به‌شکل بسته حرکت کنه
جواب رو ببین
دانلود از TCP استفاده می‌کنه، که برای یه نتیجه‌ی کامل صبر می‌کنه و دوباره می‌فرسته، ولی تماس زنده موندن رو به کامل بودن ترجیح می‌ده
دقیقاً. یه فایل باید کامل باشه، پس صبر کردن و دوباره فرستادنِ TCP اونجا می‌ارزه. یه تماس زنده بیشتر از کامل بودن، ادامه‌ی روون داره اهمیت داره، برای همین معمولاً از این محافظ صرف‌نظر می‌کنه.
مرور درس
- بسته‌ها به‌تنهایی ممکنه گم بشن، تکراری بشن، یا نامرتب برسن؛ هیچ تضمینی برخلافش نیست.
- TCP هر اتصال رو با یه دست‌دادن سه‌پیامی باز می‌کنه: SYN، SYN-ACK، ACK.
- هر تیکه‌ای که TCP می‌فرسته شماره‌گذاری و تأیید می‌شه؛ تیکه‌ی تأییدنشده دوباره فرستاده می‌شه.
- یه فایل یا یه صفحه به همه‌چی نیاز داره، پس صبر کردن و دوباره فرستادنِ TCP اونجا می‌ارزه.
- یه تماس زنده یا بازی معمولاً به‌جاش کامل بودن رو با سرعت عوض می‌کنه، با استفاده از UDP.