از پورتفورواردینگ تا کوییک تانل تحلیل عمیق مکانیزم Cloudflare Tunnel و پروتکل QUIC
بخش اول: مشکلی که این فناوری آمده حل کند
پیش از بررسی مکانیزم داخلی Cloudflare Tunnel، لازم است ریشهٔ مسئله را از ابتدا بررسی کرد. سوال اصلی این است: چرا اساساً «رساندن یک سرویس در حال اجرا روی یک کامپیوتر شخصی یا خانگی به اینترنت عمومی» یک مسئلهٔ فنی جدی محسوب میشود؟
۱.۱ مدل آدرسدهی اینترنت و مشکل IP متغیر
هر دستگاهی که به اینترنت متصل میشود، یک آدرس IP عمومی دارد که توسط ارائهدهندهٔ خدمات اینترنت (ISP) تخصیص مییابد. مشکل اول این است که اکثر ISPها برای مشتریان خانگی، آدرس IP ثابت (Static IP) ارائه نمیدهند و از پروتکل DHCP برای واگذاری IP بهصورت موقت استفاده میکنند. این آدرس ممکن است با هر بار روشنشدن مودم، یا حتی بهطور دورهای در طول زمان، تغییر کند. نتیجه این است که حتی اگر سرویس شما را به شکلی به اینترنت متصل کنید، آدرسی که دیگران باید برای دسترسی به آن استفاده کنند، پایدار نیست.
۱.۲ مشکل NAT و بهویژه CGNAT
مشکل دوم و عمیقتر به مفهوم Network Address Translation یا NAT بازمیگردد. در یک شبکهٔ خانگی معمولی، روتر شما تنها یک آدرس IP عمومی از سمت ISP دریافت میکند، اما دهها دستگاه داخل خانه (موبایل، لپتاپ، کنسول بازی و غیره) همگی از این یک آدرس مشترک برای ارتباط با اینترنت استفاده میکنند. روتر این کار را با ترجمهٔ آدرسها (NAT) انجام میدهد: هر بستهٔ خروجی از یک دستگاه داخلی، آدرس IP و پورت مبدأ آن با آدرس IP عمومی روتر و یک پورت موقت جایگزین میشود. وقتی پاسخ برمیگردد، روتر با استفاده از یک جدول ترجمه (Translation Table) میداند که این پاسخ باید به کدام دستگاه داخلی و روی کدام پورت داخلی برگردد.
مشکل اینجاست که این جدول فقط برای ترافیکی کار میکند که از داخل شبکه آغاز شده باشد. اگر یک بستهٔ ورودی بهصورت ناخواسته از اینترنت به آدرس عمومی روتر برسد، روتر هیچ ورودی متناظری در جدول خود پیدا نمیکند و آن بسته را دور میریزد. این دقیقاً همان چیزی است که باید حل شود اگر بخواهید یک سرور را از بیرون در دسترس قرار دهید.
مشکل بزرگتر از NAT معمولی، Carrier-Grade NAT یا CGNAT است. بسیاری از ISPها بهدلیل کمبود آدرسهای IPv4، بهجای اینکه به هر مشتری یک IP عمومی اختصاص دهند، صدها یا هزاران مشتری را پشت یک یا چند IP عمومی مشترک قرار میدهند. در این حالت، روتر خانگی شما اصلاً یک IP عمومی واقعی ندارد (اغلب در بازهٔ آدرس ۱۰۰.۶۴.۰.۰ تا ۱۰۰.۱۲۷.۲۵۵.۲۵۵ که برای همین منظور رزرو شده است)، بلکه خودش هم پشت یک لایهٔ NAT در سطح ISP قرار دارد. در این شرایط، هیچ تنظیمی روی روتر شخصی شما (از جمله باز کردن پورت) نمیتواند مشکل را حل کند، چون تصمیمگیری در سطحی بالاتر از دسترسی شما اتفاق میافتد.
۱.۳ راهحل سنتی و مشکلات امنیتی آن: Port Forwarding
راهحل کلاسیک برای دسترسی به یک سرویس داخلی، تنظیم Port Forwarding روی روتر است: یک قانون تعریف میکنید که میگوید هر ترافیک ورودی که به پورت مشخصی از آدرس عمومی روتر میرسد (مثلاً پورت ۴۴۳)، باید به آدرس داخلی سرور و همان پورت هدایت شود. این روش، اگرچه در عمل کار میکند، اما سه مشکل اساسی دارد:
نخست، این روش عملاً یک «سوراخ» دائمی در فایروال ایجاد میکند. هر پورتی که باز میکنید، به معنای این است که هر اسکنر پورت در اینترنت میتواند آن را کشف کند و سرویس پشت آن را هدف بگیرد. حتی اگر سرویس شما احراز هویت قوی داشته باشد، سطح حمله (Attack Surface) شما بهصورت دائمی افزایش مییابد.
دوم، این روش با IP متغیر و CGNAT که در بخش قبل توضیح داده شد، سازگار نیست یا نیاز به ابزارهای اضافی مانند Dynamic DNS دارد که خودشان لایهای از پیچیدگی و نقطهٔ شکست هستند.
سوم، مدیریت گواهی TLS (SSL Certificate) برای سرویسای که مستقیماً پشت پورت باز قرار دارد، بر عهدهٔ خود شماست؛ باید صدور، تمدید و نصب گواهی را شخصاً مدیریت کنید.
۱.۴ راهحل جدید: چرخش مفهوم اتصال
راهحلی که سرویسهایی مانند Cloudflare Tunnel، ngrok و ابزارهای مشابه ارائه میدهند، بر پایهٔ یک تغییر مفهومی ساده اما بنیادین بنا شده است: بهجای اینکه منتظر بمانید کسی از بیرون به شما وصل شود (Inbound)، خودِ دستگاه شما یک اتصال به بیرون باز میکند (Outbound) و از همان اتصال برای انتقال ترافیک در هر دو جهت استفاده میشود.
این ایده به همان دلیلی کار میکند که در بخش فایروال Stateful توضیح داده شد: یک اتصال خروجی همیشه توسط فایروال و NAT مجاز است، چون اینها فرض میکنند اگر خودِ شما درخواستی فرستادهاید، پاسخِ آن درخواست هم باید اجازهٔ ورود داشته باشد. نکتهٔ ظریف اینجاست که این اتصال، برخلاف یک درخواست معمولی HTTP که پس از دریافت پاسخ بسته میشود، باز و پایدار نگه داشته میشود، و سرویس میانی (در اینجا شبکهٔ Cloudflare) از همین یک کانال باز برای فرستادن درخواستهای جدید کاربران به سمت دستگاه شما استفاده میکند.
بخش دوم: مبانی شبکهای که باید پیشزمینه باشد
۲.۱ لایهبندی TCP/IP
برای درک درست ادامهٔ بحث، باید مدل لایهای شبکه را در نظر گرفت. دادهای که از یک برنامه ارسال میشود، از لایهٔ کاربرد (Application، مثل HTTP) به لایهٔ ترنسپورت (Transport، مثل TCP یا UDP)، سپس به لایهٔ شبکه (Network، یعنی IP) و در نهایت به لایهٔ فیزیکی/پیوند داده منتقل میشود. فایروالها و NAT معمولاً در لایهٔ شبکه و ترنسپورت تصمیمگیری میکنند؛ یعنی بر اساس آدرس IP و پورت، نه بر اساس محتوای واقعی درخواست HTTP.
۲.۲ تفاوت بنیادین TCP و UDP
TCP یک پروتکل اتصالگرا (Connection-oriented) است. پیش از انتقال هر دیتایی، یک فرآیند سهمرحلهای به نام Three-way Handshake اجرا میشود (SYN، SYN-ACK، ACK) که یک «اتصال» منطقی بین دو طرف برقرار میکند. TCP تضمین میدهد بستهها به ترتیب و بدون گمشدن به مقصد برسند؛ اگر بستهای گم شود، TCP آن را دوباره ارسال میکند و تا رسیدن آن بسته، بقیهٔ دادههای در صف نیز معلق میمانند. این پدیده Head-of-Line Blocking نام دارد.
UDP در نقطهٔ مقابل قرار دارد: هیچ اتصالی برقرار نمیشود، هیچ تضمینی برای ترتیب یا تحویل بستهها وجود ندارد، و هر بسته مستقل از بقیه ارسال میشود. این سادگی، سربار (Overhead) بسیار کمتری دارد اما مسئولیت تضمین صحت انتقال را کاملاً به لایههای بالاتر منتقل میکند.
۲.۳ نقش TLS
TLS (Transport Layer Security) لایهای است که روی TCP قرار میگیرد و مسئولیت رمزنگاری، تأیید هویت سرور (از طریق گواهی دیجیتال) و تضمین یکپارچگی داده را بر عهده دارد. در مدل کلاسیک، اتصال TCP باید ابتدا بهطور کامل برقرار شود، سپس یک Handshake جدا برای TLS اجرا میشود (که در نسخهٔ ۱.۳ آن دو رفتوبرگشت طول میکشد). یعنی برای شروع تبادل دادههای واقعی، پیش از هر چیز باید مجموعاً چند رفتوبرگشت شبکهای صرف شود.
۲.۴ فایروال Stateful و مکانیزم دقیق آن
فایروالهای مدرن، از جمله فایروال داخلی ویندوز و روترهای خانگی، به شیوهٔ Stateful عمل میکنند. این بدان معناست که فایروال برای هر اتصالی که مشاهده میکند، یک ردیف در جدولی داخلی به نام Connection Tracking Table (یا بهطور خلاصه Conntrack) ایجاد میکند. این ردیف شامل آدرس IP و پورت مبدأ، آدرس IP و پورت مقصد و وضعیت اتصال (مثلاً NEW، ESTABLISHED یا RELATED) است.
وقتی دستگاه شما یک بسته به بیرون میفرستد، فایروال یک ردیف جدید با وضعیت NEW ایجاد میکند و آن را به سمت مقصد عبور میدهد. وقتی پاسخ از همان مقصد برمیگردد، فایروال بستهٔ ورودی را با ردیفهای موجود در جدول Conntrack تطبیق میدهد؛ اگر آدرسها و پورتها (با در نظر گرفتن ترجمهٔ NAT) با یک ردیف ESTABLISHED مطابقت داشته باشند، بسته بدون نیاز به هیچ Rule صریح دیگری اجازهٔ ورود مییابد. این دقیقاً تفاوت اصلی بین یک بستهٔ «پاسخ به درخواست من» و یک بستهٔ «تلاش ناخواسته برای اتصال از بیرون» است؛ دومی هیچ ردیف متناظری در جدول ندارد و بنابراین Drop میشود.
نتیجهٔ عملی این مکانیزم، پایه و اساس کل موضوعی است که در این مقاله بررسی میشود: یک اتصال که از داخل شبکهٔ شما آغاز شده، تا زمانی که باز بماند، مسیری برای بازگشت ترافیک باقی میگذارد که هیچ نیازی به تنظیم دستی Port Forwarding ندارد.
بخش سوم: پروتکل QUIC - چرا و چگونه طراحی شده است
۳.۱ محدودیتهای TCP+TLS که QUIC میخواهد حل کند
با پیشرفت وب و افزایش تعداد درخواستهای همزمان در هر صفحه، دو محدودیت TCP آشکار شد. اول، زمان لازم برای برقراری اتصال (Handshake) که شامل هم Three-way Handshake و هم TLS Handshake است، بهویژه در شبکههای موبایل با تأخیر بالا، محسوس میشود. دوم، Head-of-Line Blocking باعث میشود گمشدن یک بسته، حتی مربوط به یک منبع کوچک مانند یک آیکون، کل اتصال چندگانهشده (Multiplexed) HTTP/2 را کند کند، چون HTTP/2 چندین Stream را روی یک اتصال TCP واحد پیادهسازی میکند و همهٔ آن Streamها به همان یک اتصال TCP گره خوردهاند.
۳.۲ راهحل QUIC: بازسازی از پایه روی UDP
QUIC (Quick UDP Internet Connections)، که استانداردهای آن در RFC 9000، RFC 9001 و RFC 9002 تعریف شدهاند، تصمیم گرفت بهجای اصلاح TCP، عملکردهای مورد نیاز را از صفر و در سطح Userspace (نه در هسته سیستمعامل) بازسازی کند، اما اینبار روی UDP سوار شود.
انتخاب UDP به این دلیل بوده که تغییر پروتکل TCP در سطح جهانی عملاً غیرممکن است، چون میلیونها دستگاه شبکهای (روتر، فایروال، Middlebox) رفتار خاصی از TCP انتظار دارند و هر تغییری در آن ممکن است باعث ناسازگاری شود. UDP در مقابل، صرفاً یک کانال خام برای عبور بستههاست و هیچ منطق خاصی رویش تحمیل نمیکند، پس QUIC میتواند منطق دلخواه خودش را کاملاً از نو، بدون درگیر شدن با سازگاری هسته، پیادهسازی کند.
۳.۳ ویژگیهای کلیدی QUIC
نخستین ویژگی، ادغام رمزنگاری با برقراری اتصال است. در QUIC، فریمهای مخصوص رمزنگاری (CRYPTO Frame) مستقیماً در همان بستههای اول ارسال میشوند که اتصال ترنسپورت را برقرار میکنند. نتیجه این است که کل فرآیند اتصال و رمزنگاری تنها یک رفتوبرگشت شبکهای (1-RTT) طول میکشد، بهجای دو یا سه رفتوبرگشت جداگانه در مدل TCP+TLS.
دومین ویژگی، Multiplexing واقعی در سطح ترنسپورت است. در QUIC، هر Stream مستقل از بقیه است. اگر یک بسته مربوط به Stream شماره یک گم شود، فقط همان Stream منتظر ارسال دوباره میماند و بقیهٔ Streamها بدون کوچکترین وقفه به کارشان ادامه میدهند. این ویژگی مشکل Head-of-Line Blocking که در HTTP/2 روی TCP وجود دارد را کاملاً حل میکند.
سومین ویژگی، Connection Migration است. در TCP، هویت یک اتصال با ترکیب چهارتایی آدرس IP مبدأ، پورت مبدأ، آدرس IP مقصد و پورت مقصد تعیین میشود؛ اگر آدرس IP دستگاه شما تغییر کند (مثلاً از Wi-Fi به شبکهٔ موبایل سوییچ کنید)، اتصال TCP قطع میشود و باید از نو برقرار شود. QUIC بهجای این چهارتایی، یک شناسهٔ اتصال مستقل (Connection ID) تعریف میکند که به آدرس IP وابسته نیست، پس اتصال میتواند حتی با تغییر آدرس IP بدون قطعی ادامه یابد.
بخش چهارم: معماری کامل Cloudflare Tunnel
۴.۱ نصب و رجیستر شدن cloudflared
نرمافزار سبک cloudflared روی دستگاه یا سرور شما نصب میشود. این برنامه یک دیمن (Daemon) است که در پسزمینه اجرا میشود. هنگام اجرا با دستوری شبیه به cloudflared tunnel --url http://localhost:8000، این برنامه مسیر محلی سرویس شما (مثلاً پورت ۸۰۰۰) را بهعنوان Origin ثبت میکند و سپس تلاش میکند به نزدیکترین دیتاسنتر Cloudflare متصل شود.
در حالت Quick Tunnel، چون هیچ حساب کاربری یا دامنهای درگیر نیست، cloudflared یک درخواست به یک API عمومی میفرستد و یک زیردامنهٔ تصادفی زیر trycloudflare.com برایش صادر میشود (مانند quiet-marble-otter-canyon.trycloudflare.com). در حالت Named Tunnel (که برای استفادهٔ دائمی مناسب است)، ابتدا با دستور cloudflared tunnel login یک گواهی احراز هویت از حساب کاربری شما دریافت میشود، سپس تونل با نام مشخص ثبت شده و از طریق cloudflared tunnel route dns یک زیردامنهٔ دائمی از دامنهٔ خودتان به آن متصل میشود.
۴.۲ برقراری اتصالات پایدار به Edge
پس از رجیستر شدن، cloudflared معمولاً چهار اتصال طولانیمدت و همزمان به دو نقطهٔ حضور (Point of Presence) متفاوت از شبکهٔ Cloudflare برقرار میکند تا در صورت قطعی یک مسیر، افزونگی (Redundancy) وجود داشته باشد. این اتصالات بهصورت پیشفرض با پروتکل QUIC روی پورت UDP شمارهٔ ۷۸۴۴ برقرار میشوند. اگر فایروال شبکهٔ شما ترافیک UDP خروجی را مسدود کند، cloudflared بهطور خودکار به HTTP/2 روی TCP سقوط میکند (Fallback).
نکتهٔ کلیدی اینجاست که همهٔ این اتصالات از سمت دستگاه شما به سمت Cloudflare آغاز میشوند، یعنی دقیقاً همان مکانیزم اتصال خروجی که در بخش دوم توضیح داده شد. از دید فایروال شما، این ترافیک هیچ تفاوتی با باز کردن یک صفحهٔ وب معمولی ندارد.
۴.۳ نقش شبکهٔ Anycast
وقتی کاربری در مرورگر آدرس https://quiet-marble-otter-canyon.trycloudflare.com را باز میکند، درخواست او با استفاده از مکانیزم مسیریابی Anycast به نزدیکترین نقطهٔ حضور Cloudflare (که در بیش از سیصد شهر در سراسر جهان پخش شدهاند) هدایت میشود. در Anycast، یک آدرس IP واحد از چندین مکان جغرافیایی مختلف تبلیغ (Announce) میشود و پروتکل مسیریابی BGP بهطور خودکار کاربر را به کوتاهترین مسیر شبکهای هدایت میکند، نه لزوماً نزدیکترین فاصلهٔ جغرافیایی.
۴.۴ مسیر کامل یک درخواست
مسیر یک درخواست HTTP از لحظهٔ ارسال توسط کاربر تا رسیدن پاسخ، شامل مراحل زیر است:
نخست، کاربر درخواست HTTP را به سمت زیردامنهٔ اختصاصی میفرستد. این درخواست از طریق Anycast به نزدیکترین نقطهٔ حضور Cloudflare میرسد و پروتکل بین کاربر و Edge میتواند HTTP/1.1، HTTP/2 یا HTTP/3 باشد، بسته به قابلیت مرورگر کاربر.
دوم، نقطهٔ حضور Cloudflare، درخواست ورودی را با استفاده از شناسهٔ زیردامنه، به همان اتصال ازقبلبرقرارشده که متعلق به دستگاه شماست تطبیق میدهد. این تطبیق در سطح لایهٔ کاربرد (Application Layer) اتفاق میافتد، نه در سطح NAT، چون Cloudflare یک Reverse Proxy کامل است و میداند هر درخواست ورودی باید بر اساس نام میزبان (Hostname) به کدام تونل فرستاده شود.
سوم، درخواست از طریق همان کانال QUIC یا HTTP/2 که پیشتر برقرار شده، به سمت cloudflared روی دستگاه شما فرستاده میشود. چون QUIC و HTTP/2 هر دو Multiplexed و Full-duplex هستند، این کانال میتواند چندین درخواست همزمان کاربران مختلف را بدون تداخل حمل کند، حتی اگر همهٔ آنها روی یک اتصال فیزیکی واحد سوار باشند.
چهارم، cloudflared درخواست را دریافت کرده و آن را به سرویس محلی روی localhost:8000 میفرستد، دقیقاً مانند اینکه یک کلاینت معمولی روی همان دستگاه به آن درخواست زده باشد.
پنجم، پاسخ سرویس محلی، توسط cloudflared از همان مسیر بازمیگردد: از دستگاه شما به Edge، از Edge از طریق Anycast به کاربر نهایی.
نمودار زیر این جریان را بهطور خلاصه نمایش میدهد:
1
2
3
4
5
6
7
8
9
10
11
12
کاربر نهایی
│ HTTP/1.1 ، HTTP/2 یا HTTP/3 (رمزنگاریشده با TLS)
▼
نزدیکترین نقطهٔ حضور Cloudflare (مسیریابی Anycast)
│ اتصال ازقبلبرقرارشده و پایدار
│ QUIC روی UDP:7844 (یا در صورت مسدود بودن UDP، HTTP/2 روی TCP)
│ این اتصال از سمت دستگاه شما آغاز شده است (Outbound)
▼
دیمن cloudflared روی دستگاه شما
│ HTTP معمولی روی شبکهٔ محلی (Loopback)
▼
سرویس شما روی localhost:8000
بخش پنجم: ملاحظات امنیتی و محدودیتهای عملی
۵.۱ چرا این مدل امنتر از Port Forwarding است
در این مدل، هیچ پورتی روی فایروال یا روتر شما بهصورت مستقیم باز نمیشود؛ تنها ترافیک خروجی مجاز است. علاوهبر این، آدرس IP واقعی سرور شما هیچگاه بهطور مستقیم در معرض اینترنت قرار نمیگیرد، چون تمام ترافیک از طریق شبکهٔ Cloudflare عبور میکند. Cloudflare همچنین میتواند لایههای امنیتی اضافی مانند محدودسازی نرخ درخواست (Rate Limiting)، فیلترسازی حملات DDoS و قوانین فایروال در سطح اپلیکیشن (WAF) را پیش از رسیدن ترافیک به دستگاه شما اعمال کند.
۵.۲ محدودیتهای Quick Tunnel بهطور خاص
باید تأکید کرد که Quick Tunnel صرفاً برای آزمایش و استفادهٔ موقت طراحی شده و در مستندات رسمی Cloudflare محدودیتهای مشخصی برایش ذکر شده است: حداکثر دویست درخواست همزمان مجاز است و پس از آن پاسخهای کد وضعیت ۴۲۹ (Too Many Requests) بازگردانده میشود، و از Server-Sent Events (SSE) پشتیبانی نمیشود. همچنین، زیردامنهٔ صادر شده موقتی است و با بستهشدن پروسهٔ cloudflared، از بین میرود و در اجرای بعدی آدرسی کاملاً متفاوت صادر خواهد شد. برای استفادهٔ پایدار، Production یا سرویسهایی که نیاز به اتصالات طولانیمدت مانند SSE یا WebSocket دارند، باید از Named Tunnel با حساب کاربری و دامنهٔ واقعی استفاده شود.
تحلیل انتقادی
نکتهٔ نادرست رایج در مورد Anycast این است که آن را با «مسیریابی بر اساس نزدیکی جغرافیایی» (Geo-routing یا GeoDNS) اشتباه میگیرند. اینها دو مکانیزم کاملاً متفاوتاند: GeoDNS بر اساس موقعیت جغرافیایی واقعی IP کاربر و منطق اپلیکیشنی تصمیم میگیرد، اما Anycast اصلاً به موقعیت جغرافیایی آگاه نیست؛ تصمیمگیری آن کاملاً در سطح پروتکل مسیریابی شبکه (BGP) و بر اساس «نزدیکی توپولوژیک» (Topological Proximity) اتفاق میافتد، نه فاصلهٔ فیزیکی. این تمایز برای فهم درست رفتار Cloudflare حیاتی است، چون توضیح میدهد چرا گاهی کاربری در یک شهر ممکن است به دیتاسنتری در شهر دیگری (نه لزوماً نزدیکترین از نظر مسافت) هدایت شود.
تفاوت Unicast و Anycast
در مدل کلاسیک آدرسدهی که Unicast نام دارد، هر آدرس IP دقیقاً به یک دستگاه یا سرور اختصاص دارد؛ رابطهٔ آدرس به سرور یکبهیک است. Anycast این قاعده را میشکند: یک آدرس IP واحد بهطور همزمان از چندین سرور در چندین مکان جغرافیایی مختلف اعلام (Announce) میشود. از دید کاربر نهایی، تنها یک آدرس IP وجود دارد، اما پشت آن آدرس، دهها یا صدها سرور فیزیکی مستقل قرار دارند.
مفاهیم پیشنیاز: Prefix، ASN و BGP
برای درک مکانیزم، سه مفهوم باید پیش از هر چیز روشن شود. نخست، Prefix یک بازهٔ آدرس IP است که معمولاً با نماد CIDR نوشته میشود (مثلاً 1.1.1.0/24)؛ سازمانها بهجای یک آدرس تکی، معمولاً یک کل Prefix را مالک هستند. دوم، ASN (Autonomous System Number) یک شناسهٔ عددی است که به هر شبکهٔ مستقل بزرگ (مانند یک ISP یا یک شرکت زیرساخت مانند Cloudflare) اختصاص مییابد و آن شبکه را در سطح جهانی اینترنت قابلشناسایی میکند. سوم، BGP (Border Gateway Protocol) پروتکلی است که این شبکههای مستقل (Autonomous Systemها) با استفاده از آن، اطلاعات مسیریابی خود را به یکدیگر اعلام میکنند؛ BGP در دستهبندی پروتکلهای Path Vector قرار دارد، یعنی هر اعلام مسیر، شامل کل مسیر شبکههای طیشده (AS Path) است، نه فقط یک عدد هزینه.
مکانیزم گامبهگام Anycast
گام اول: اعلام همزمان یک Prefix از چند نقطه
سازمانی مانند Cloudflare مالک یک یا چند Prefix است (مثلاً 1.1.1.0/24) و یک ASN دارد. در هر یک از دیتاسنترهای خود در سراسر جهان (که بیش از سیصد نقطه هستند)، یک روتر مرزی (Edge Router) دارد که این Prefix را با پروتکل BGP به شبکههای همسایه (Peer یا Upstream) اعلام میکند. نکتهٔ کلیدی اینجاست که همان Prefix دقیقاً یکسان، از تمام این نقاط بهطور همزمان اعلام میشود؛ یعنی روتر در فرانکفورت میگوید «من میتوانم 1.1.1.0/24 را برسانم» و روتر در سنگاپور هم دقیقاً همین ادعا را میکند.
گام دوم: انتشار اعلامها در سطح اینترنت
هر روتری که این اعلام BGP را از یک همسایه دریافت میکند، آن را (پس از افزودن شناسهٔ خودش به AS Path) به همسایههای خودش نیز اعلام میکند. این فرآیند بهصورت پلکانی در سطح کل اینترنت ادامه مییابد، تا اینکه عملاً هر روتر بزرگ در دنیا چندین مسیر مختلف برای رسیدن به همان Prefix در جدول مسیریابی خود دارد؛ یکی از طریق فرانکفورت، یکی از طریق سنگاپور، یکی از طریق نیویورک، و به همین ترتیب.
گام سوم: الگوریتم انتخاب بهترین مسیر (BGP Path Selection)
اینجا هستهٔ اصلی مکانیزم Anycast قرار دارد. هر روتر که چندین مسیر رقیب برای یک Prefix واحد دریافت میکند، باید دقیقاً یکی از آنها را بهعنوان بهترین مسیر (Best Path) در جدول Forwarding خود ثبت کند. BGP این انتخاب را با یک زنجیرهٔ معیارهای اولویتدار انجام میدهد که بهترتیب بررسی میشوند تا تساوی شکسته شود:
- Local Preference: یک مقدار که خودِ شبکهٔ محلی برای ترجیحدادن یک مسیر نسبت به مسیر دیگر تعیین میکند.
- طول AS Path: مسیری که از تعداد کمتری از شبکههای مستقل (AS) عبور کرده باشد، ترجیح داده میشود. این معیار معمولاً تعیینکنندهترین عامل در انتخاب «نزدیکترین» مسیر است.
- MED (Multi-Exit Discriminator): مقداری که شبکهٔ مقصد برای راهنمایی همسایگانش دربارهٔ کدام نقطهٔ ورودی ترجیحی است، اعلام میکند.
- هزینهٔ IGP داخلی: اگر همهٔ معیارهای قبلی مساوی باشند، هزینهٔ مسیر داخلی شبکه (مانند تعداد Hopهای فیزیکی) تصمیمگیرنده میشود.
نتیجهٔ نهایی این است که هر روتر در دنیا، بر اساس موقعیت خودش در توپولوژی شبکه، مستقل از بقیهٔ روترها، یک تصمیم میگیرد که کدام یک از نسخههای تکرارشدهٔ آن Prefix برایش «ارزانتر» و «نزدیکتر» است. برای یک کاربر در تهران، مسیر با کمترین AS Path معمولاً از طریق نزدیکترین نقطهٔ حضور منطقهای عبور میکند، اما این تصمیم صرفاً بر اساس توپولوژی شبکه است، نه فاصلهٔ فیزیکی؛ به همین دلیل ممکن است در موارد نادر، ترافیک به دیتاسنتری دورتر از نظر جغرافیایی اما نزدیکتر از نظر مسیر شبکهای هدایت شود.
گام چهارم: تحویل بستهٔ داده
وقتی دستگاه کاربر یک بسته به آدرس Anycast میفرستد، این بسته هیچ اطلاعات اضافیای دربارهٔ مقصد «واقعی» ندارد؛ صرفاً طبق جدول Forwarding هر روتری که از آن عبور میکند، هدایت میشود. چون هر روتر از قبل بهترین مسیر را در جدول خود ثبت کرده، بسته بهصورت طبیعی و بدون هیچ تصمیمگیری در سطح اپلیکیشن، به نزدیکترین (توپولوژیک) دیتاسنتر میرسد.
مکانیزم Failover در Anycast
یکی از مزایای بزرگ Anycast، بازیابی خودکار از خرابی است. اگر یک دیتاسنتر (مثلاً بهدلیل قطعی برق یا نگهداری) از کار بیفتد، روتر مرزی آن دیتاسنتر بهسادگی اعلام BGP خود برای آن Prefix را پس میگیرد (Withdraw). این پسگیری در کل اینترنت انتشار مییابد و روترهایی که پیشتر از آن مسیر استفاده میکردند، بهطور خودکار به دومین بهترین مسیر موجود (یعنی نزدیکترین دیتاسنتر بعدی) سوییچ میکنند. این فرآیند Convergence نام دارد و معمولاً در عرض چند ثانیه تا چند دقیقه کامل میشود، بدون اینکه کاربر نهایی نیازی به تغییر آدرس یا تنظیمات داشته باشد.
نکتهٔ فنی مهم: Anycast و اتصالات TCP طولانیمدت
نکتهای که مستقیماً به بحث تونلهای Cloudflare مربوط میشود این است: چون تصمیم مسیریابی BGP در طول زمان میتواند تغییر کند (مثلاً بهدلیل تغییر توپولوژی شبکه یا خرابی یک لینک)، در تئوری ممکن است یک اتصال TCP طولانیمدت میانراه به دیتاسنتر دیگری «پرت» شود، که باعث قطعشدن اتصال میگردد؛ این پدیده را Anycast Route Flapping مینامند. Cloudflare این مشکل را با فناوریهای داخلی مسیریابی حالتآگاه (State-aware Routing با استفاده از اطلاعاتی که میان دیتاسنترها هماهنگ میشود) کاهش میدهد تا اتصالات موجود در طول عمرشان به همان دیتاسنتر اولیه پایدار بمانند، حتی اگر مسیر بهینهٔ BGP برای اتصالات جدید تغییر کرده باشد.
کاربرد در معماری Cloudflare
آدرس عمومی که Cloudflare برای Edge خود استفاده میکند (چه برای زیردامنهٔ Quick Tunnel و چه برای هر سایت دیگری پشت Cloudflare)، یک آدرس Anycast است. به همین دلیل، وقتی گفته میشود «درخواست به نزدیکترین نقطهٔ حضور Cloudflare میرسد»، این جمله دقیقاً به همین مکانیزم BGP اشاره دارد، نه به یک DNS هوشمند که موقعیت کاربر را حدس بزند. همین ویژگی، مبنای دو قابلیت دیگر Cloudflare نیز هست: توزیع بار ترافیک DDoS در سطح جهانی (چون حجم حمله بهجای تمرکز روی یک نقطه، بین صدها دیتاسنتر پخش میشود) و کاهش تأخیر شبکه برای کاربران، مستقل از اینکه سرویس اصلی آنها (مانند دستگاه شما که cloudflared روی آن اجرا میشود) در کجای دنیا قرار دارد.