ترافیک قانونی در شبکه DDoS-Guard اخیراً از صد گیگابیت در ثانیه فراتر رفته است. در حال حاضر، 50 درصد از کل ترافیک ما توسط خدمات وب مشتری ایجاد می شود. این ها ده ها هزار دامنه هستند، بسیار متفاوت و در بیشتر موارد نیاز به رویکرد فردی دارند.
در زیر برش نحوه مدیریت گره های جلو و صدور گواهینامه SSL برای صدها هزار سایت است.
ایجاد یک جبهه برای یک سایت، حتی یک سایت بسیار بزرگ، آسان است. nginx یا هاپروکسی یا lighttpd را می گیریم، طبق راهنماها پیکربندی می کنیم و فراموش می کنیم. اگر لازم باشد چیزی را تغییر دهیم، بارگذاری مجدد انجام می دهیم و دوباره فراموش می کنیم.
همه چیز تغییر می کند وقتی حجم زیادی از ترافیک را پردازش می کنید، مشروعیت درخواست ها را ارزیابی می کنید، محتوای کاربر را فشرده و حافظه پنهان می کنید و در همان زمان چندین بار در ثانیه پارامترها را تغییر می دهید. کاربر می خواهد بلافاصله پس از تغییر تنظیمات در حساب شخصی خود، نتیجه را در تمام گره های خارجی ببیند. یک کاربر همچنین می تواند چندین هزار (و گاهی ده ها هزار) دامنه را با پارامترهای پردازش ترافیک فردی از طریق API دانلود کند. همه اینها باید بلافاصله در آمریکا و اروپا و آسیا نیز کار کند - با توجه به اینکه در مسکو به تنهایی چندین گره فیلتراسیون از هم جدا شده اند، این کار بی اهمیت ترین نیست.
چرا تعداد زیادی گره قابل اعتماد در سراسر جهان وجود دارد؟
-
کیفیت خدمات برای ترافیک مشتری - درخواست‌های ایالات متحده باید در ایالات متحده پردازش شوند (از جمله برای حملات، تجزیه و سایر ناهنجاری‌ها) و به مسکو یا اروپا کشیده نشوند و به طور غیرقابل پیش‌بینی تاخیر پردازش افزایش یابد.
-
ترافیک حمله باید محلی سازی شود - اپراتورهای حمل و نقل می توانند در طول حملات، که حجم آنها اغلب از 1 ترابیت بر ثانیه تجاوز می کند، تنزل پیدا کنند. انتقال ترافیک حمله از طریق پیوندهای فراآتلانتیک یا ترانس آسیایی ایده خوبی نیست. ما موارد واقعی داشتیم که اپراتورهای Tier-1 گفتند: "حجم حملاتی که دریافت می کنید برای ما خطرناک است." به همین دلیل است که ما جریان های ورودی را تا حد امکان نزدیک به منابع خود می پذیریم.
-
الزامات سختگیرانه برای تداوم خدمات - مراکز نظافت نباید به یکدیگر یا به رویدادهای محلی در دنیای به سرعت در حال تغییر ما وابسته باشند. آیا برق تمام 11 طبقه MMTS-9 را به مدت یک هفته قطع کردید؟ - مشکلی نیست حتی یک مشتری که در این مکان خاص ارتباط فیزیکی نداشته باشد آسیب نخواهد دید و خدمات وب تحت هیچ شرایطی آسیب نخواهند دید.
چگونه همه اینها را مدیریت کنیم؟
تنظیمات سرویس باید در سریع ترین زمان ممکن (در حالت ایده آل) در تمام گره های جلویی توزیع شود. شما نمی‌توانید فقط پیکربندی‌های متن را بگیرید و دوباره بسازید و در هر تغییری دیمون‌ها را راه‌اندازی مجدد کنید - همان nginx فرآیندها را برای چند دقیقه (یا شاید ساعت‌ها اگر جلسات طولانی وب‌سوکت وجود داشته باشد) خاموش نگه می‌دارد (کارگر خاموش می‌شود).
هنگام بارگیری مجدد پیکربندی nginx، تصویر زیر کاملاً طبیعی است:
در مورد استفاده از حافظه:
کارگران قدیمی حافظه را می خورند، از جمله حافظه ای که به طور خطی به تعداد اتصالات بستگی ندارد - این طبیعی است. وقتی اتصالات کلاینت بسته شود، این حافظه آزاد می شود.
چرا زمانی که nginx به تازگی شروع به کار کرده بود، این یک مشکل نبود؟ هیچ HTTP/2، هیچ WebSocket، هیچ اتصال طولانی مدت طولانی وجود نداشت. 70 درصد از ترافیک وب ما HTTP/2 است که به معنای اتصالات بسیار طولانی است.
راه حل ساده است - از nginx استفاده نکنید، جبهه ها را بر اساس فایل های متنی مدیریت نکنید، و مطمئناً تنظیمات متن فشرده شده را روی کانال های transpacific ارسال نکنید. کانال‌ها، البته، تضمین‌شده و رزرو شده‌اند، اما این باعث نمی‌شود که از بین قاره‌ای کمتر شوند.
ما سرور-بالانسر جلویی خودمان را داریم که در مقالات بعدی در مورد داخلی آن صحبت خواهم کرد. اصلی‌ترین کاری که می‌تواند انجام دهد این است که هزاران تغییر پیکربندی در ثانیه را بدون راه‌اندازی مجدد، بارگذاری مجدد، افزایش ناگهانی مصرف حافظه و همه اینها اعمال کند. این بسیار شبیه به Hot Code Reload است، برای مثال در Erlang. داده ها در یک پایگاه داده کلیدی-مقدار توزیع شده جغرافیایی ذخیره می شوند و بلافاصله توسط محرک های جلویی خوانده می شوند. آن ها گواهی SSL را از طریق رابط وب یا API در مسکو آپلود می کنید و در عرض چند ثانیه آماده رفتن به مرکز نظافت ما در لس آنجلس است. اگر ناگهان جنگ جهانی اتفاق بیفتد و اینترنت در سراسر جهان ناپدید شود، گره‌های ما به صورت مستقل به کار خود ادامه می‌دهند و به محض اینکه یکی از کانال‌های اختصاصی لس آنجلس-آمستردام-مسکو، مسکو-آمستردام-هنگ کنگ- به کار خود ادامه می‌دهند. Los-Los در دسترس می شود. Angeles یا حداقل یکی از پوشش های پشتیبان GRE.
همین مکانیسم به ما امکان می‌دهد فوراً گواهینامه‌های Let's Encrypt را صادر و تمدید کنیم. خیلی ساده به این صورت عمل می کند:
-
به محض مشاهده حداقل یک درخواست HTTPS برای دامنه مشتری خود بدون گواهی (یا با گواهی منقضی شده)، گره خارجی که این درخواست را پذیرفته است، این موضوع را به مرجع صدور گواهینامه داخلی گزارش می دهد.
-
اگر کاربر صدور Let's Encrypt را ممنوع نکرده باشد، مرجع صدور گواهینامه یک CSR ایجاد می کند، یک رمز تأیید از LE دریافت می کند و آن را از طریق یک کانال رمزگذاری شده به همه جبهه ها ارسال می کند. اکنون هر گره ای می تواند درخواست اعتبارسنجی از LE را تایید کند.
-
تا چند لحظه دیگر گواهی صحیح و کلید خصوصی را دریافت کرده و به همین ترتیب به جبهه ها ارسال می کنیم. باز هم بدون راه اندازی مجدد دیمون ها
-
7 روز قبل از تاریخ انقضا، مراحل دریافت مجدد گواهی آغاز می شود
در حال حاضر ما در حال چرخش 350 هزار گواهینامه در زمان واقعی هستیم که برای کاربران کاملاً شفاف است.
در مقالات بعدی این مجموعه، در مورد سایر ویژگی های پردازش بلادرنگ ترافیک وب بزرگ صحبت خواهم کرد - به عنوان مثال، در مورد تجزیه و تحلیل RTT با استفاده از داده های ناقص برای بهبود کیفیت خدمات برای مشتریان ترانزیت و به طور کلی در مورد محافظت از ترافیک حمل و نقل از حملات ترابیت، در مورد تحویل و تجمیع اطلاعات ترافیک، در مورد WAF، CDN تقریبا نامحدود و مکانیسم های زیادی برای بهینه سازی تحویل محتوا.
فقط کاربران ثبت نام شده می توانند در نظرسنجی شرکت کنند. ، لطفا.
چه چیزی را دوست دارید اول بدانید؟
-
٪۱۰۰الگوریتم های خوشه بندی و تجزیه و تحلیل کیفیت ترافیک وب<3
-
٪۱۰۰داخلی متعادل کننده های DDoS-Guard7
-
٪۱۰۰حفاظت از ترافیک L3/L4 ترانزیت2
-
٪۱۰۰محافظت از وب سایت ها در ترافیک حمل و نقل 0
-
٪۱۰۰فایروال برنامه وب 3
-
٪۱۰۰محافظت در برابر تجزیه و کلیک کردن 6
21 کاربر رای دادند. 6 کاربر رای ممتنع دادند.
منبع: www.habr.com