درخواست‌های کوچک کار می‌کنند، دانلودهای بزرگ گیر می‌کنند و کسی محدودسازی MSS را پیشنهاد می‌دهد. این پیشنهاد به‌قدری غالباً درست است که ارزش دارد به ترتیب صحیح امتحان شود و به‌قدری غالباً نادرست است که اگر کورکورانه اعمالش کنید یک بعدازظهر را هدر دهید. سه بررسی زیر مشکل واقعی اندازه TCP را از مشکل UDP، از کشف path-MTU خراب و از محدودسازی‌ای که هرگز دست‌دهی‌ای را که باید بازنویسی کند نمی‌بیند جدا می‌کند.

با شکل خرابی شروع کنید

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

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

هنگام خواندن این نشانه، انتقال را در نظر داشته باشید. محدودسازی بازنویسی یک گزینه TCP است، پس تماس صوتی یا تصویری که زیر همان تونل گیر می‌کند مشکل MSS نیست و با آن بهتر نمی‌شود. پیش از دست‌زدن به گزینه TCP، نوع انتقال را یادداشت کنید.

هزینه مسیر را حساب کنید و سپس با تونل مقایسه کنید

دو عدد مهم‌اند و اغلب اشتباه گرفته می‌شوند. path-MTU بزرگ‌ترین بسته‌ای است که مسیر بدون قطعه‌بندی حمل می‌کند و MSS اعلام‌شده برای IPv4 همان مقدار منهای 40 بایت سرآیندهای IP و TCP است، یا منهای 60 برای IPv6. کپسوله‌سازی تونل بخشی از بودجه را پیش از آن‌که بسته درونی حتی آغاز شود می‌بلعد.

ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20

ping با بیت do-not-fragment به شما می‌گوید بسته‌ای با آن اندازه بار مفید زنده می‌ماند یا نه؛ اندازه را تغییر دهید تا شکست بخورد و حد مسیر را تجربی یافته‌اید. خروجی tracepath MTU کشف‌شده در طول مسیر را گزارش می‌کند، که وقتی کار می‌کند سریع‌تر و وقتی پرشی میانی کاوشگرها را فیلتر می‌کند کم‌اعتبارتر است.

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

محدودسازی را جایی بگذارید که دست‌دهی عبور می‌کند

محدودسازی با بازنویسی گزینه MSS در بسته‌های SYN و SYN-ACK در حین عبور از دروازه کار می‌کند. اگر قاعده روی رابطی باشد که هیچ‌یک از دو جهت هرگز از آن عبور نمی‌کند، مذاکره بدون تغییر کامل می‌شود و نشانه باقی می‌ماند، از همین رو جای‌گذاری بیش از مقدار نتیجه را تعیین می‌کند.

SymptomWhat it points toNext check
Handshake completes, large transfer stallsSegment size larger than the path can carryPath MTU against the tunnel's effective MTU
Nothing connects, small or largeRouting, firewall or keying failureNot MSS; look at the tunnel state
Only UDP applications stallDatagram size or a dropped ICMP errorPlatform-specific UDP handling, not clamping
Fixed after reconnect, returns laterClamp applied to one direction or one interfaceRule placement and the handshake path

جهت نیمه دیگر است. محدودسازی یک جهت نیمی از جریان‌ها را درست می‌کند و بقیه را به شکلی شکست می‌دهد که متناوب به نظر می‌رسد، پس آن را به هر دو جهت ترافیک ارسال‌شده اعمال کنید. شکل کلاسیک در لینوکس برای رابط تونل یک قاعده mangle است که با بسته‌های SYN مطابقت دارد:

iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

توجه کنید --clamp-mss-to-pmtu در واقع چه می‌کند: مقدار را از MTU مسیر استخراج می‌کند، که همیشه بودجه واقعی بار مفید تونل نیست. روی تونل مبتنی بر مسیر که مسیر درونی و مسیر بیرونی متفاوت‌اند، مقدار صریح محاسبه‌شده در بررسی قبلی از مقدار خودکار قابل‌پیش‌بینی‌تر است.

با اتصال جدید بررسی کنید و بازخورد را زنده نگه دارید

اتصال برقرارشده MSS مذاکره‌شده را نگه می‌دارد، پس آزمایش در همان نشست چیزی را ثابت نمی‌کند. پس از تغییر اتصال تازه‌ای باز کنید و مقدار مذاکره‌شده را مستقیم بخوانید، نه اینکه آن را از انتقالی که تصادفاً تمام می‌شود استنتاج کنید.

ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSS

فرمان اول MSS سوکت را همراه با وضعیت ازدحام آن گزارش می‌کند، که سریع‌ترین تأیید اثرگذاری محدودسازی است. فرمان دوم تأیید می‌کند قاعده‌ای که فکر می‌کنید افزوده‌اید همان قاعده موجود است، در جدولی که در آن قرار داده شده.

سپس سازوکاری را که درست نکرده‌اید محافظت کنید. کشف path-MTU به رسیدن پیام‌های ICMP fragmentation-needed به فرستنده وابسته است، پس دیوار آتشینی که آن‌ها را دور می‌ریزد همچنان انتقال‌های بزرگ را حتی با محدودسازی درست خراب می‌کند. این پیام‌ها را برای مسیر تونل مجاز کنید، یا بپذیرید که محدودسازی جبران سیاستی است که خودتان انتخاب کرده‌اید.

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

path-MTU اندازه‌گیری‌شده، سرباز تونلی که کم کردید، قاعده‌ای که افزودید و MSS-ای که بعد دیدید را بنویسید. چهار عدد رخداد بعدی را به جست‌وجو تبدیل می‌کند نه تحقیق.

مقالات مرتبط