بازی موش و گربهٔ فیلتـرنت

حس می‌کنید که اینترنتتان از اسفندماه ۹۳ نامهربان‌تر شده و به شما بی‌محلی می‌کند؟ بدانید که تنها نیستید.

در این متن می‌خواهم برداشت خودم از وضعیت فیلتـرنت کشورمان را با توجه به شواهد موجود بنویسم، به این امید که بتوانیم با همفکری به راه‌حلی برای بهبود این وضعیت برسیم.

مجلس‌نشینان در تاریخ ۲۵ فروردین ۹۴ کارت زردی تقدیم وزیر ارتباطات و فناوری اطلاعات کردند. هر چند دلیل این کارت زرد در اکثر رسانه‌ها «توسعهٔ شبکه و پهنای باند» منعکس شده است، ولی بر خلاف انتظار ذهنی ما، موضوع گرانی اینترنت و کیفیت پایین هم در مجلس مطرح شده است. هر چند احتمالاً می‌دانید ولی برای مستند شدن متن به مطلبی از همشهری online هم اشاره می‌کنم که در آن با استناد به دو سه گزارش مختلف، جمع‌بندی می‌کند که ایران قعرنشین سرعت اینترنت و صدرنشین هزینه است. غر زدن بس است! کمی برویم سراغ تحلیل فنی تا بفهمیم که دارد چه اتفاقی می‌افتد.

صورت مسأله در این مقاله برای من اینست که چرا در طول چند ماه اخیر تجربهٔ کاربری‌ام از اینترنت کشور اینطور ناخوشایند بوده است.

متأسفانه بر خلاف نقشه‌ها و سرویس‌های جالبی که دولت آمریکا برای هر چه شفاف‌تر کردن کیفیت خدمات ارتباطاتی ارائه می‌دهد، وبگاه شرکت ارتباطات زیرساخت بیابانیست مزین شده به عکس مسئولین در حال تعارفات همیشگی. بدین ترتیب من پس از چندین ساعت تلاش برای پیدا کردن اطلاعات بدرد بخور در وبگاه‌ها، موفق نشدم نقطهٔ شروع به درد بخوری پیدا کنم که شهود کمی بهم از نحوهٔ اتصالم به اینترنت بدهد.

لذا مجبورم که با ابزارهای فنی کمی اطلاعات جمع کنم و سپس از روی آن‌ها حدس بزنم. ابزاری که می‌خواهم از آن استفاده کنم MTR است. به طور خلاصه این دستور پکت‌هایی با طول عمر ۱، ۲، ۳ و … به سمت مقصد می‌فرستد. هر پکت وقتی که به تعداد عمرش پرش انجام می‌دهد، متوقف می‌شود و به جایش یک پاسخ اتمام عمر به فرستنده ارسال می‌شود. به این ترتیب فرستند می‌تواند از مسیری که پکت طی می‌کند آگاه شود. ولی تفاوت MTR با traceroute یا tracepath در اینست که MTR تعداد زیادی پکت به Nodeهای میانی می‌فرستد تا بتواند گزارش آماری‌ای از وضعیت گره‌های میانی به ما بدهد. به نوعی MTR ترکیبی است از traceroute و ping.

$ sudo mtr -rwc 50 server-54-230-61-84.mad50.r.cloudfront.net -s 500 Start: Sat May 23 18:19:45 2015 HOST: Uzum.local Loss% Snt Last Avg Best Wrst StDev 1.|— 192.168.100.1 0.0% 50 1.2 1.3 0.9 2.2 0.0 2.|— 85.133.185.113.pos-1-0.7tir.sepanta.net 0.0% 50 9.4 10.6 5.1 34.2 6.4 3.|— core-11-11-3600.7tir.sepanta.net 0.0% 50 6.6 12.7 5.9 28.0 5.6 4.|— 10.10.53.113 0.0% 50 7.7 12.9 5.6 40.8 6.6 5.|— 10.201.1.226 40.0% 50 11.8 15.9 7.0 47.2 10.2 6.|— 10.201.22.102 40.0% 50 13.1 15.3 7.2 34.8 7.9 7.|— 10.10.36.218 40.0% 50 15.5 15.4 6.7 32.5 6.3 8.|— 134.0.217.37 40.0% 50 53.1 51.1 44.5 61.5 5.2 9.|— 82.178.33.97 40.0% 50 50.3 53.1 44.6 86.9 10.7 10.|— 82.178.33.106 40.0% 50 47.5 53.8 46.4 83.4 9.1 11.|— ix-8-0-1-0.tcore1.mlv-mumbai.as6453.net 40.0% 50 217.6 208.5 201.8 233.3 7.1 12.|— if-9-5.tcore1.wyn-marseille.as6453.net 93.9% 49 159.3 153.5 149.2 159.3 5.1 13.|— if-8-1600.tcore1.pye-paris.as6453.net 40.8% 49 148.5 151.2 143.4 167.3 6.8 14.|— if-2-2.tcore1.pvu-paris.as6453.net 40.8% 49 164.6 150.4 142.6 164.6 5.6 15.|— 80.231.153.202 38.8% 49 168.6 148.4 137.9 183.2 10.5 16.|— xe-3-2-0.mad50.ip4.gtt.net 38.8% 49 170.0 175.3 161.4 221.8 13.4 17.|— a100-gw.ip4.gtt.net 38.8% 49 165.8 166.6 158.7 239.4 14.4 18.|— server-54-230-61-84.mad50.r.cloudfront.net 40.8% 49 170.8 167.5 159.4 186.1 7.3 ‎

همانطور که می‌بینید، در مقصدمان که یکی از Load Balancer های Amazon CloudFront است، نزدیک ۴۱٪ از پکت‌های که فرستاده‌ایم برنگشته‌اند. ولی نکتهٔ جالب‌تر اینه که این الگوی گم شدن پکت‌ها در گره‌های قبلی هم دیده می‌شود. و از آن جالب‌تر اینه که گم شدن پکت‌ها از آی‌پی 10.201.1.226 شروع شده است که می‌دانیم مورد استفادهٔ شبکهٔ داخلی است.

یک نظریه اینست که پهنای باند ISP مربوطه در آن نقطه محدود شده است. ولی سه تا موضوع باعث می‌شود که این موضوع را مردود بدانم. من این تست را ده‌ها بار در طول چند روز اخیر روی شبکه‌های سپنتا، پارس آنلاین، افرانت، شاتل و های‌وب انجام داده‌ام. آنچه که تکرار می‌شود نزدیک به هم بودن میزان Packet Loss گره‌های میانیست. این در حالیست که دستور فوق را اگر برای yahoo.com اجرا کنید تعداد ناچیزی گم‌شدگی پکت خواهید دید. این تفاوت رفتار بر اساس مقصد و نه منبع، در کنار رؤیت این الگو در ISP های مختلف، و مخصوصاً در کنار این نظم عجیب درصد گم‌شدگی پکت‌ها این فرضیه را از نظر من مردود می‌کند. در زمان محدود شدن پهنای باند ازدحام شبکه اتفاق می‌افتد. در این شرایط پکت‌ها تقریباً تصادفی گم می‌شوند. خیلی نامحتمل است که از میان پکت‌های ارسالی به گرهٔ دهم همانقدر پکت گم شود که از میان پکت‌های ارسالی به گرهٔ شانزدهم کم شده است.

بدین ترتیب می‌رسیم به نظریهٔ دوم: گم شدن درصد خاصی از پکت‌ها تعمدی است.

ولی چرا؟! اگر سرویس مذکور در میان لیست بلندبالای سرویس‌های فیلتـر شده قرار دارد، خب پس چرا خیلی راحت به ما یک صفحهٔ فیلتـر‌ینگ رنگوارنگ نشان داده نمی‌شود؟ چرا باید بعضی از پکت‌های اینترنتی بی‌گناه سر بریده شوند، بی جرم و بی جنایت؟ آن هم در شرایطی که احتمالاً پهنای باند کافی موجود است. این موجود بودن پهنای باند را می‌توانیم از عبور بی مشکل پکت‌ها به مقصد yahoo.com نتیجه بگیریم.

مجدداً من یک نظریه دارم!

اگر حافظه‌ام گمراهم نکرده باشد، اوایل دههٔ ۱۳۸۰ ما از اینکه تکنولوژی فیلتـر‌ینگ بر اساس HTTP شده بود خوشحال شده بودیم. چرا که قبل آن، زمانی که فیلتـر‌ینگ را با بستن IP انجام می‌دادند، وبگاه‌های بدبختی بودند که روی همنان IP همسایهٔ وبگاه مورد فیلتـر بودند و بسته می‌شدند. ولی این نیمچه خوشحالی با ظهور فیلتـر‌ینگ هوشمند اتفاق نیفتاده است. هر چند که می‌توان حدس زد که انگیزهٔ پشت فیلتـر‌ینگ هوشمند به مانند حالت قبلی در راستای کمتر شدن قربانیان فیلتـر‌ینگ است. ولی اینبار چندان تأثیری نداشت، چرا که

دانش HTTPS چنان عمومی شده است که دیگر ارائه دادن سرویس روی HTTPS یک امر بدیهیست و گاه باز بودن HTTP یک سرویس مرتبط با امور نسبتاً شخصی، موجب نقدهای منفی می‌شود.

و تقریباً همه می‌دانند که HTTPS نه تنها جلوی دیدن محتوا، که حتی جلوی دیده شدن آدرس مورد نظر کاربر در زمان ارسال درخواست را هم می‌گیرد. بدین ترتیب نه تنها فیلتـر‌ینگ هوشمند، که حتی فیلتـر‌ینگ HTTP قبلی نیز دیگر کارا نخواهد بود. بدین ترتیب راه به نظر انتخاب شده، روش سنتی دستکاری DNS در کنار روش مدرن کند کردن و نه بستن کل IPهای مرتبط به میزبانی وبگاه مورد غضب است.

ولی این کند کردن عوارض ناگواری دارد، و این به دلیل Trend دیگری در فناوری‌های وب در جهان است: سرویس‌های جدیدی که این روزها به دنیا می‌آیند و به کاربرها عرضه می‌شوند اکثراً روی میزبان‌های ابری و پشت تعداد محدودی Load Balancer قرار می‌گیرند. بدین ترتیب کند کردن یک سرویس خاص میزبانی شده روی یک سرویس ابری تنها با کند کردن کل ترافیک مرتبط با مجموعهٔ Load Balancer های سرویس ابری ممکن است. و احتمالاً server-54-230-61-84.mad50.r.cloudfront.net یکی از آن Load Balancer هاییست که قربانی سیاست سوختن تر و خشک با هم شده است.

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

از زمان ابلاغ «مقررات و ضوابط شبکه‌های اطلاع‌رسانی و رایانه‌ای» تا بدین لحظه بازی موش و گربه‌ای بین ما کاربران اینترنت ایران و سازمان‌های متوالی نظارت بر اینترنت بوجود آمده است. هر چند که این بازی از اولش هم باخت - باخت بوده است. تنها بردی که می‌توانم متصور شوم برد کوتاه مدت برای عدهٔ محدودی است که دانش استفاده از اینترنت برای اهداف خود (سیاسی، اجتماعی، اقتصادی، …) را ندارند، و ترجیح می‌دهند که نقص خود در استفاده از این ابزار را با توقف رشد دیگران جبران کنند، و نه با رشد خودشان.

به این امید که …، من دلیلی برای غر زدن نداشته باشم!

با تشکر از الناز مجاهدی که در ویرایش این متن کمکم کرد.

امکان نظرات توسط Disqus.