قضیه از این قراره که شرکت کلادفلر (Cloudflare) که در زمینه زیرساخت و امنیت اینترنت فعالیت میکنه، اعلام کرده که موتور پاسخدهی هوش مصنوعی پرپلکسیتی (Perplexity) داره از روشهای مخفیانه برای خزش و جمعآوری اطلاعات از وبسایتها استفاده میکنه. به گفته کلادفلر، پرپلکسیتی دستوراتی رو که صاحبان وبسایتها برای جلوگیری از دسترسی رباتها تعیین کردن، نادیده میگیره.
کلادفلر میگه که پرپلکسیتی اول با هویت مشخص خودش به سایتها سر میزنه، اما وقتی با مسدود شدن یا بلاک شدن مواجه میشه، هویتش رو مخفی میکنه تا بتونه محدودیتها رو دور بزنه. شواهد نشون میده که پرپلکسیتی به طور مداوم «یوزر ایجنت» (User Agent) یا همون شناسه کاربری رباتش رو تغییر میده، از شبکههای مختلفی (ASN) برای اتصال استفاده میکنه و گاهی فایلهای robots.txt رو که قوانین دسترسی به سایت هستن، نادیده میگیره یا اصلا بررسی نمیکنه.
بر اساس این مشاهدات، کلادفلر اعلام کرده که این رفتار با اصول اعتماد و شفافیت در اینترنت سازگار نیست و به همین دلیل، پرپلکسیتی رو از لیست رباتهای تایید شده خودش حذف کرده و قوانینی رو برای مسدود کردن این نوع خزش مخفیانه به سیستمهاش اضافه کرده.
این تستها چطوری انجام شدن؟
این ماجرا از شکایت مشتریان کلادفلر شروع شد. اونها میگفتن با اینکه دسترسی رباتهای پرپلکسیتی رو هم از طریق فایل robots.txt و هم با قوانین مشخص در فایروال وب (WAF) مسدود کرده بودن، باز هم میدیدن که پرپلکسیتی به محتوای سایتشون دسترسی داره. این مشتریها به طور مشخص جلوی دو خزنده اعلام شده پرپلکسیتی یعنی PerplexityBot و Perplexity-User رو گرفته بودن.
برای بررسی دقیقتر، کلادفلر چند دامنه کاملا جدید مثل testexample.com و secretexample.com خرید. این دامنهها هیچجای اینترنت ثبت نشده بودن و هیچ موتور جستجویی از وجودشون خبر نداشت. بعد، یک فایل robots.txt روی این سایتها قرار دادن که به همه رباتها میگفت حق دسترسی به هیچ بخشی از سایت رو ندارن.
در مرحله بعد، از هوش مصنوعی پرپلکسیتی سوالاتی در مورد محتوای این دامنههای محدود شده پرسیدن. نتیجه این بود که پرپلکسیتی اطلاعات دقیقی در مورد محتوای این سایتهای ممنوعه ارائه میداد، در حالی که تمام اقدامات لازم برای جلوگیری از دسترسی رباتها انجام شده بود.
رفتارهای مخفیکارانه مشاهده شده
مشاهدات کلادفلر نشون داد که پرپلکسیتی علاوه بر خزندههای رسمی خودش، از یک شناسه کاربری دیگه هم استفاده میکنه که خودش رو به عنوان یک مرورگر معمولی «گوگل کروم روی سیستمعامل مک» جا میزنه. این اتفاق زمانی میفتاد که خزنده رسمی پرپلکسیتی مسدود میشد.
نوع خزنده
شناسه کاربری (User Agent)
تعداد درخواست روزانه
اعلام شده
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Perplexity-User/1.0; +https://perplexity.ai/perplexity-user)
۲۰ تا ۲۵ میلیون
مخفی
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
۳ تا ۶ میلیون
این خزنده مخفی از آیپیهای مختلفی استفاده میکرد که در لیست آیپیهای رسمی پرپلکسیتی نبودن و برای دور زدن محدودیتها، مدام آیپی و شبکه خودش رو عوض میکرد. این فعالیت در دهها هزار دامنه و با میلیونها درخواست در روز مشاهده شد. کلادفلر با استفاده از یادگیری ماشین و سیگنالهای شبکه تونست این خزنده رو شناسایی کنه.
یک نکته جالب این بود که وقتی خزنده مخفی هم با موفقیت بلاک میشد، پرپلکسیتی سعی میکرد با استفاده از منابع دیگه (مثل اطلاعاتی که سایتهای دیگه در مورد سایت اصلی منتشر کردن) به سوالات جواب بده، اما این جوابها کلی بودن و جزئیات محتوای اصلی رو نداشتن.
واکنش پرپلکسیتی و وضعیت کسب و کارش
در مقابل این گزارش، یک سخنگوی پرپلکسیتی در صحبت با رسانه The Verge، گزارش کلادفلر رو یک «شگرد تبلیغاتی» دونست و گفت که «سوءتفاهمهای زیادی در این پست وبلاگ وجود داره».
این اتهامات در حالی مطرح میشه که پرپلکسیتی که حدود ۱۵ میلیون کاربر داره و سال گذشته به ارزش ۱ میلیارد دلار رسید، در حال مذاکره برای قراردادهای بزرگیه. گزارشهایی از معامله احتمالی با سامسونگ برای استفاده از این هوش مصنوعی در دستگاههای آینده این شرکت و همچنین صحبتهای داخلی در شرکت اپل برای خرید کامل پرپلکسیتی منتشر شده.
رفتار یک ربات خوب چطوری باید باشه؟
در مقابل رفتاری که به پرپلکسیتی نسبت داده شده، جامعه اینترنت یک سری انتظارات روشن از رباتهای قانونمند داره:
شفاف باشن: هویت خودشون رو به درستی اعلام کنن، لیست آیپیهاشون مشخص باشه و اطلاعات تماس داشته باشن.
رفتار درستی داشته باشن: با ترافیک بیش از حد به سایتها فشار نیارن، اطلاعات حساس رو جمعآوری نکنن و از روشهای مخفیانه برای دور زدن قوانین استفاده نکنن.
هدف مشخصی داشته باشن: هدف ربات باید به طور واضح تعریف شده باشه تا صاحبان سایت بتونن در موردش تصمیم بگیرن.
برای کارهای مختلف، رباتهای جدا داشته باشن: اینطوری صاحب سایت میتونه اجازه دسترسی به بعضی فعالیتها رو بده و جلوی بقیه رو بگیره.
به قوانین احترام بذارن: به فایل robots.txt توجه کنن، محدودیتهای سرعت رو رعایت کنن و سعی نکنن سیستمهای امنیتی رو دور بزنن.
کلادفلر برای مثال به شرکت اوپنایآی (OpenAI) اشاره میکنه که این اصول رو رعایت میکنه. اونها خزندههاشون رو به وضوح معرفی میکنن، به robots.txt احترام میذارن و برای دور زدن محدودیتها تلاش نمیکنن. در تستی مشابه، ربات ChatGPT-User وقتی با دستور عدم دسترسی مواجه شد، خزش رو متوقف کرد و تلاش دیگهای از طرفش مشاهده نشد.
چطوری میشه از خودمون محافظت کنیم؟
کلادفلر میگه مشتریانی که از سیستم مدیریت ربات این شرکت استفاده میکنن و قوانینی برای مسدود کردن یا به چالش کشیدن رباتها دارن، در برابر این نوع فعالیتها محافظت شدن. علاوه بر این، کلادفلر یک شناسه مشخص برای این خزنده مخفی به قوانین مدیریت شده خودش اضافه کرده که جلوی فعالیت رباتهای هوش مصنوعی رو میگیره. این قابلیت برای تمام مشتریان، حتی کاربران طرح رایگان، در دسترسه.
قدم بعدی چیه؟
کلادفلر حدود یک ماه پیش قابلیتی به نام «روز استقلال محتوا» رو معرفی کرد تا به صاحبان سایتها کنترل بیشتری روی نحوه دسترسی به محتواشون بده. از اون زمان، بیش از دو و نیم میلیون وبسایت تصمیم گرفتن با استفاده از ابزارهای کلادفلر، جلوی آموزش مدلهای هوش مصنوعی با دادههاشون رو بگیرن.
کلادفلر انتظار داره که با این ویژگیهای جدید، رفتار رباتها تغییر کنه و روشهای اونها برای دور زدن قوانین هم پیچیدهتر بشه. به همین دلیل، این شرکت در حال همکاری با متخصصان فنی و سیاستگذاری در سراسر دنیا، مثل تلاشهای گروه IETF، برای استانداردسازی و ایجاد اصول روشن و قابل اندازهگیری برای رفتار رباتهاست.
منابع
[1] Perplexity is using stealth, undeclared crawlers to evade website no-crawl directives
[2] Cloudflare Says Perplexity’s AI Bots Ignore No-Crawl Directives
این روزها داشتن یک سرور لینوکس، چه برای کارهای شخصی و چه برای پروژههای بزرگتر، خیلی رایج شده. اما یک نکته خیلی مهم وجود داره که گاهی ازش غافل میشیم: امنیت. شاید فکر کنی همین که لینوکس رو نصب کردی و سرور بالا اومد، همه چیز امن و امانه. اما حقیقت اینه که داستان تازه از اینجا شروع میشه.
فکرش رو بکن، به محض اینکه سرور شما به اینترنت وصل میشه و یک هویت عمومی پیدا میکنه، از همون لحظه تبدیل به یک هدف برای آدمهای بد نیت یا همون «هکرهای کلاه سیاه» میشه. این افراد همیشه دنبال سرورهای امننشده میگردن تا ازشون برای اهداف خودشون استفاده کنن. یک سرور بدون لایههای امنیتی، برای این افراد مثل یک زمین بازی میمونه. ممکنه بخوان به دادههای شما دسترسی پیدا کنن، یا بدتر، از سرور شما به عنوان یکی از سربازهاشون برای حملات بزرگ DDoS (حملات منع سرویس توزیعشده) استفاده کنن.
نکته ترسناکتر ماجرا اینه که اگه امنیت رو جدی نگیری، ممکنه هیچوقت نفهمی که سرورت هک شده. یک هکر حرفهای میتونه بدون اینکه هیچ ردپایی از خودش به جا بذاره، به سرور شما نفوذ کنه، یک کپی از تمام دادههای شما برداره و بدون اینکه چیزی رو تغییر بده، از اونجا بره. در این حالت، شما هیچوقت متوجه نمیشید که اطلاعاتتون دزدیده شده. یا مثلا ممکنه سرور شما جزئی از یک حمله DDoS بزرگ بوده باشه و شما اصلا روحتم خبر نداشته باشه. اگه به خبرهای مربوط به نشت اطلاعات شرکتهای بزرگ نگاه کنی، میبینی که خیلی وقتها اون شرکتها تا مدتها بعد از اینکه هکرها کارشون رو کرده بودن و رفته بودن، اصلا متوجه نفوذ یا سرقت اطلاعات نشده بودن.
یک باور اشتباه رایج اینه که هکرها همیشه میخوان یک چیزی رو خراب کنن یا اطلاعات شما رو قفل کنن و در ازاش پول بخوان. اما این همیشه درست نیست. گاهی وقتها اونها فقط به دادههای روی سرور شما احتیاج دارن تا به انبارهای داده بزرگ خودشون اضافه کنن (چون پول خیلی خوبی توی دادههای بزرگ یا Big Data هست). یا ممکنه بخوان مخفیانه از قدرت پردازشی سرور شما برای کارهای شرورانه خودشون استفاده کنن، بدون اینکه شما حتی متوجه بشید.
این راهنما قراره قدم به قدم به شما یاد بده چطور یک سرور لینوکس رو امن کنید. مطالب زیادی برای امنسازی یک سرور لینوکس وجود داره و ما سعی میکنیم تا جایی که ممکنه، بیشتر این موارد رو پوشش بدیم. این یک راهنمای زندهست، یعنی به مرور زمان و با یادگیری بیشتر یا مشارکت بقیه، مطالب جدیدی بهش اضافه میشه.
شاید با خودت بگی این راهنما تکراری و غیرضروریه، چون هزاران مقاله آنلاین در مورد امنیت لینوکس وجود داره. حق با شماست، اما مشکل اینجاست که این اطلاعات در مقالههای مختلف پخش شدن، هر کدوم یک چیز رو پوشش میدن و روشهای متفاوتی دارن. واقعا کی وقت داره صدها مقاله رو زیر و رو کنه تا به یک جمعبندی برسه؟ این راهنما در واقع حاصل یادداشتبرداریهای شخصی موقع تحقیق برای راهاندازی یک سرور دبیان بوده. در آخر کار، مشخص شد که این یادداشتها، در کنار دانش قبلی و چیزهای جدیدی که یاد گرفته شده، پتانسیل تبدیل شدن به یک راهنمای کامل رو داره. برای همین تصمیم گرفته شد که به صورت آنلاین منتشر بشه تا شاید به بقیه هم کمک کنه و در وقتشون صرفهجویی بشه. هدف اینه که یک راهنمای جامع داشته باشیم که تقریبا همه چیز رو پوشش بده.
خیلی از مواردی که در این راهنما پوشش داده میشه، ممکنه خیلی ساده و پیش پا افتاده به نظر برسن، اما بیشتر ما هر روز لینوکس نصب نمیکنیم و خیلی راحت ممکنه این نکات پایهای رو فراموش کنیم.
یک نکته خیلی مهم: برای راحتی کار، یک نسخه Ansible از این راهنما هم توسط moltenbit در آدرس «How To Secure A Linux Server With Ansible» آماده شده که میتونید از اون هم استفاده کنید.
نگاهی کلی به این راهنما
این راهنما برای این نوشته شده که به شما یاد بده چطور یک سرور لینوکس رو امن کنید. این یک راهنمای در حال تکامله و هدفش اینه که در کنار آموزش مراحل عملی، کمی هم در مورد خود امنیت و اهمیت اون به شما دید بده.
این راهنما…
یک کار در حال پیشرفته: این یعنی ممکنه در آینده بخشهایی بهش اضافه بشه یا تغییر کنه.
برای سرورهای خانگی طراحی شده: تمام مفاهیم و توصیهها برای محیطهای بزرگتر و حرفهای هم کاربرد داره، اما اون موارد نیاز به تنظیمات پیشرفتهتر و تخصصیتری دارن که خارج از حوصله این راهنماست.
آموزش لینوکس نیست: این راهنما به شما یاد نمیده لینوکس چیه، چطور نصب میشه یا چطور ازش استفاده کنید. اگه با لینوکس آشنایی ندارید، بهتره اول کمی باهاش کار کنید. یک سایت خوب برای شروع، https://linuxjourney.com/ هست.
برای همه توزیعهای لینوکس نوشته شده: سعی شده تا حد امکان مطالب طوری باشن که روی توزیعهای مختلف لینوکس کار کنن.
همه چیز در مورد امنیت رو پوشش نمیده: این راهنما تمام جنبههای امنیت سیستم یا سرور رو بررسی نمیکنه. مثلا، امنیت فیزیکی (اینکه کسی نتونه به خود دستگاه سرور دسترسی فیزیکی داشته باشه) خارج از محدوده این راهنماست.
به جزئیات عمیق برنامهها نمیپردازه: ابزارها و برنامههایی که در این راهنما معرفی میشن، معمولا خیلی قدرتمند و قابل تنظیم هستن. هدف این راهنما اینه که فقط موارد ضروری و پایهای رو پوشش بده، اونقدری که شما رو برای یادگیری بیشتر تشنه کنه.
کار رو با کدها راحت کرده: سعی شده تا جایی که ممکنه، کدهایی آماده برای کپی و پیست کردن فراهم بشه. البته حواستون باشه که شاید لازم باشه قبل از اجرا، بعضی از این کدها رو برای سیستم خودتون تغییر بدید.
یک ترتیب منطقی داره: مطالب به ترتیبی چیده شدن که از نظر نویسنده منطقی بوده، مثلا امن کردن SSH قبل از نصب فایروال. برای همین، بهتره راهنما رو به ترتیب دنبال کنید، اما اجباری نیست. فقط اگه ترتیب رو عوض میکنید، حواستون باشه که بعضی بخشها به بخشهای قبلی نیاز دارن.
قبل از اینکه شروع کنی
قبل از اینکه دست به کار بشی و شروع به امن کردن سرور کنی، چندتا نکته خیلی مهم هست که باید بهشون فکر کنی. اینها در واقع اصول و مدل تهدید (Threat Model) شما رو مشخص میکنن.
چرا میخوای سرورت رو امن کنی؟ هدفت چیه؟
چقدر امنیت میخوای؟ آیا دنبال حداکثر امنیت هستی یا یک سطح معقول کافیه؟
حاضری چقدر از راحتی کار رو فدای امنیت کنی؟ امنیت بیشتر معمولا به معنی دردسر و محدودیت بیشتره. این تعادل رو باید برای خودت مشخص کنی.
تهدیدهایی که میخوای ازشون محافظت کنی چی هستن؟ موقعیت خاص شما چیه؟ برای مثال:
آیا دسترسی فیزیکی به سرور یا شبکه شما یک راه حمله احتمالی هست؟
آیا قراره پورتهایی رو روی روتر باز کنی تا از بیرون خونه به سرورت دسترسی داشته باشی؟
آیا قراره یک فایل شیرینگ روی سرور راه بندازی که از روی یک کامپیوتر دسکتاپ بهش وصل بشی؟ چقدر احتمال داره اون کامپیوتر دسکتاپ آلوده بشه و در نتیجه سرور رو هم آلوده کنه؟
آیا راهی برای بازیابی اطلاعات داری اگه تنظیمات امنیتی باعث بشه خودت هم از سرور قفل بشی؟ مثلا اگه لاگین با کاربر روت رو غیرفعال کنی یا برای GRUB (بوت لودر) پسورد بذاری.
اینها فقط چندتا سوال برای شروع فکر کردنه. قبل از اینکه شروع کنی، باید بدونی که داری از چی و چرا محافظت میکنی تا بدونی دقیقا باید چه کارهایی انجام بدی.
انتخاب توزیع لینوکس
این راهنما سعی کرده برای همه توزیعها مناسب باشه تا هر کسی بتونه از توزیع مورد علاقه خودش استفاده کنه. با این حال، چندتا نکته در مورد انتخاب توزیع وجود داره:
شما به توزیعی احتیاج دارید که:
پایدار (Stable) باشه: مگر اینکه از دیباگ کردن مشکلات ساعت ۲ صبح لذت ببرید، وگرنه نمیخواید که یک آپدیت خودکار یا دستی، سرور شما رو از کار بندازه. البته این به این معنیه که شما باید با این موضوع کنار بیاید که همیشه جدیدترین و خفنترین نرمافزارها رو نخواهید داشت.
با پچهای امنیتی بهروز بمونه: شما میتونید همه چیز رو روی سرور امن کنید، اما اگه خود سیستمعامل یا برنامههایی که اجرا میکنید آسیبپذیریهای شناختهشده داشته باشن، هیچوقت در امان نخواهید بود.
باهاش آشنا باشید: اگه لینوکس بلد نیستید، توصیه میشه اول کمی باهاش کار کنید و بعد سعی کنید امنش کنید. باید باهاش راحت باشید و راه و چاهش رو بلد باشید، مثلا بدونید چطور نرمافزار نصب کنید، فایلهای کانفیگ کجا هستن و غیره.
پشتیبانی خوبی داشته باشه: حتی باتجربهترین مدیران سیستم هم گاهی به کمک احتیاج دارن. داشتن یک کامیونیتی یا منبع برای کمک گرفتن، اعصاب شما رو نجات میده.
نصب لینوکس
مراحل نصب لینوکس خارج از محدوده این راهنماست، چون هر توزیعی روش خودش رو داره و معمولا دستورالعملهای نصب به خوبی مستند شدن. اگه به کمک نیاز دارید، از مستندات توزیع خودتون شروع کنید. به طور کلی، فرآیند نصب معمولا اینطوریه:
فایل ISO رو دانلود میکنید.
اون رو روی یک رسانه نصب مثل سیدی یا فلش مموری رایت میکنید.
سرور رو از روی اون رسانه بوت میکنید.
مراحل نصب رو دنبال میکنید.
یک نکته مهم اینه که اگه گزینهای به اسم «نصب تخصصی» یا «Expert Install» وجود داشت، از اون استفاده کنید تا کنترل بیشتری روی چیزهایی که روی سرور نصب میشه داشته باشید. فقط چیزهایی رو نصب کنید که واقعا بهشون احتیاج دارید. پیشنهاد میشه به جز SSH، هیچ چیز دیگهای نصب نشه. همچنین، اگه گزینهای برای «رمزنگاری دیسک» (Disk Encryption) وجود داشت، حتما تیکش رو بزنید.
کارهای اولیه بعد از نصب
بعد از اینکه نصب تموم شد و سرور بالا اومد، چندتا کار اولیه هست که باید انجام بدید:
اگه قراره پورتی رو روی روتر باز کنید تا از بیرون به سرور دسترسی داشته باشید، فعلا این قابلیت Port Forwarding رو غیرفعال نگه دارید تا وقتی که سیستم امن بشه.
مطمئن بشید که SSH کار میکنه، چون برای دسترسی ریموت بهش احتیاج دارید (مگر اینکه همه کارها رو به صورت فیزیکی روی خود سرور انجام بدید).
سیستم رو آپدیت کنید. برای مثال در سیستمهای مبتنی بر دبیان از این دستور استفاده میشه: sudo apt update && sudo apt upgrade.
کارهای مخصوص به تنظیمات خودتون رو انجام بدید، مثل:
تنظیمات شبکه
تنظیم نقاط اتصال (mount points) در فایل /etc/fstab
ایجاد حسابهای کاربری اولیه
نصب نرمافزارهای اصلی که نیاز دارید، مثل man
سرور شما باید بتونه ایمیل بفرسته تا هشدارهای امنیتی مهم رو دریافت کنید. اگه قصد راهاندازی یک میل سرور کامل رو ندارید، میتونید از راهحلهایی مثل استفاده از جیمیل و Exim4 استفاده کنید که در ادامه توضیح داده میشه.
یک توصیه مهم: قبل از شروع این راهنما، پیشنهاد میشه یک نگاهی به مستندات «CIS Benchmarks» بندازید تا با توصیههای اونها آشنا بشید. این بنچمارکها توسط مرکز امنیت اینترنت (CIS) ارائه میشن و استانداردهای صنعتی و مورد اعتمادی برای امنسازی انواع لینوکس هستن. پیشنهاد اینه که اول این راهنما رو تا آخر بخونید و اجرا کنید و بعد به سراغ راهنمای CIS برید. اینطوری، توصیههای اونها هر چیزی که در این راهنما گفته شده رو تکمیل میکنه یا در صورت تضاد، اولویت پیدا میکنه.
چند نکته نهایی قبل از شروع
این راهنما روی دبیان نوشته و تست شده. بیشتر موارد باید روی توزیعهای دیگه هم کار کنن. چیزی که توزیعها رو از هم متمایز میکنه، بیشتر سیستم مدیریت بستهها (Package Management) هست. چون نویسنده از دبیان استفاده کرده، دستورات apt ارائه شده.
مسیر فایلها و تنظیمات ممکنه در توزیعهای مختلف کمی فرق داشته باشه. اگه به مشکلی برخوردید، مستندات توزیع خودتون رو چک کنید.
کل راهنما رو قبل از شروع یک بار بخونید. ممکنه کاربرد یا اصول شما ایجاب کنه که کاری رو انجام ندید یا ترتیب کارها رو عوض کنید.
دستورات رو کورکورانه کپی و پیست نکنید، بدون اینکه بفهمید دارن چیکار میکنن. بعضی از دستورات، مثل اونهایی که نام کاربری دارن، باید قبل از اجرا برای سیستم شما ویرایش بشن.
بخش اول: سرور SSH
سرور SSH مثل در ورودی اصلی به سرور شماست. اگه قراره از راه دور و از بیرون شبکه خونگی به سرورتون وصل بشید، این در همیشه در دسترسه. اگه این در به درستی امن نشه، میتونه به یک نقطه ضعف بزرگ تبدیل بشه و هکرها ازش برای نفوذ به سیستم شما استفاده کنن. برای همین، اولین و یکی از مهمترین قدمها، امن کردن SSH هست.
یک نکته خیلی خیلی مهم: موقعی که دارید تنظیمات SSH رو تغییر میدید، حتما یک ترمینال دوم به سرور باز نگه دارید. اینطوری اگه با تغییرات جدید، دسترسی خودتون رو از ترمینال اول از دست دادید و قفل شدید، هنوز یک راه ارتباطی با سرور دارید تا بتونید مشکل رو برطرف کنید. این ایده از طرف کاربری به اسم Sonnenbrand مطرح شده و خیلی کاربردیه.
استفاده از کلیدهای عمومی/خصوصی SSH
استفاده از زوج کلید عمومی و خصوصی برای احراز هویت در SSH، روشی بسیار امنتر از استفاده از پسورد معمولیه. علاوه بر امنیت، این روش کار شما رو هم راحتتر و سریعتر میکنه، چون دیگه نیازی نیست هر بار برای اتصال، پسوردتون رو وارد کنید.
این روش چطور کار میکنه؟
در سطح بالا، این سیستم از یک جفت کلید برای تایید هویت شما استفاده میکنه.
کلید عمومی (Public Key): این کلید فقط میتونه دادهها رو رمزنگاری کنه، اما نمیتونه اونها رو رمزگشایی کنه. همونطور که از اسمش پیداست، شما میتونید این کلید رو به صورت عمومی به اشتراک بذارید (البته ما بازم احتیاط میکنیم).
کلید خصوصی (Private Key): این کلید میتونه دادههایی که با کلید عمومی متناظرش رمزنگاری شدن رو رمزگشایی کنه. این کلید باید به شدت محرمانه باقی بمونه.
برای استفاده در SSH، شما یک جفت کلید عمومی و خصوصی روی کامپیوتر کلاینت (کامپیوتری که ازش به سرور وصل میشید) میسازید. بعد از ساخت کلیدها، باید کلید عمومی رو به سرور منتقل کنید و اون رو در فایل ~/.ssh/authorized_keys در پوشه خانگی کاربری که میخواید باهاش وصل بشید، قرار بدید.
وقتی شما تلاش میکنید به سرور SSH وصل بشید، سرور یک پیام چالش (challenge message) رو با استفاده از کلید عمومی شما که در فایل authorized_keys پیدا کرده، رمزنگاری میکنه و برای شما میفرسته. کامپیوتر کلاینت شما باید بتونه این پیام رو با استفاده از کلید خصوصی خودش رمزگشایی کنه. اگه موفق شد، یعنی هویت شما تایید شده و اتصال برقرار میشه. اگه نتونست، اتصال رد میشه.
این روش امنتره چون برای اتصال، شما حتما به فایل کلید خصوصی نیاز دارید. اگه شما ورود با پسورد رو در تنظیمات سرور SSH غیرفعال کنید (PasswordAuthentication no)، دیگه هیچ راهی برای اتصال بدون داشتن کلید خصوصی وجود نخواهد داشت.
برای امنیت بیشتر، میتونید برای خود کلید خصوصی هم یک رمز عبور (passphrase) تعریف کنید. در این حالت، هر بار که از کلید استفاده میکنید، باید اون رمز رو هم وارد کنید. البته این کار باعث میشه نتونید از این کلید برای اسکریپتها و اتوماسیون استفاده کنید. برای حل این مشکل، ابزاری به اسم ssh-agent وجود داره که معمولا در توزیعهای لینوکس موجوده. این برنامه به شما اجازه میده کلید خصوصی رمزگشاییشده خودتون رو برای مدت مشخصی در حافظه نگه دارید. کافیه یک بار دستور ssh-add رو اجرا کنید و رمز کلید رو وارد کنید. تا زمانی که مدت زمان تعیین شده تموم نشده، دیگه از شما رمز پرسیده نمیشه.
ما در این راهنما از کلیدهای نوع Ed25519 استفاده میکنیم. این نوع کلید از یک الگوریتم امضای مبتنی بر منحنی بیضوی استفاده میکنه که امنیت بهتری نسبت به الگوریتمهای قدیمیتر مثل DSA و RSA ارائه میده و در عین حال عملکرد خوبی هم داره.
مراحل عملی:
ساخت کلید Ed25519 روی کامپیوتر کلاینت: از روی کامپیوتری که قراره باهاش به سرور وصل بشید (کلاینت)، نه خود سرور، این دستور رو اجرا کنید:
ssh-keygen -t ed25519
بعد از اجرای این دستور، از شما چندتا سوال پرسیده میشه:
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_ed25519.
Your public key has been saved in /home/user/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:F44D4dr2zoHqgj0i2iVIHQ32uk/Lx4P+raayEAQjlcs user@client
The key's randomart image is:
+--[ED25519 256]--+
|xxxx x |
|o.o +. . |
| o o oo . |
|. E oo . o . |
| o o. o S o |
|... .. o o |
|.+....+ o |
|+.=++o.B.. |
|+..=**=o=. |
+----[SHA256]-----+
میتونید مسیر پیشفرض رو برای ذخیره کلیدها تایید کنید. اگه میخواید برای کلیدتون رمز بذارید، در مرحله «Enter passphrase» اون رو وارد کنید.
کپی کردن کلید عمومی به سرور: حالا باید کلید عمومی که ساخته شده (~/.ssh/id_ed25519.pub) رو به فایل ~/.ssh/authorized_keys روی سرور اضافه کنید. سادهترین راه برای این کار استفاده از دستور ssh-copy-id هست. این دستور به صورت خودکار کلید رو به سرور منتقل و به فایل مورد نظر اضافه میکنه.
ssh-copy-id user@server
در این دستور، user نام کاربری شما روی سرور و server آدرس IP یا دامنه سرور شماست. بعد از اجرای دستور، از شما پسورد کاربر روی سرور پرسیده میشه تا بتونه کلید رو کپی کنه.
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user/.ssh/id_ed25519.pub"
The authenticity of host 'host (192.168.1.96)' can't be established.
ECDSA key fingerprint is SHA256:QaDQb/X0XyVlogh87sDXE7MR8YIK7ko4wS5hXjRySJE.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
user@host's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'user@host'"
and check to make sure that only the key(s) you wanted were added.
از این به بعد، شما میتونید بدون وارد کردن پسورد (یا با وارد کردن رمز کلید، اگه براش تعریف کرده باشید) به سرور وصل بشید. این کار رو باید برای هر کامپیوتر و هر کاربری که میخواد به سرور وصل بشه، تکرار کنید.
محدود کردن دسترسی SSH با گروه کاربری
برای اینکه کنترل بیشتری روی این داشته باشیم که چه کسانی میتونن از طریق SSH به سرور وصل بشن، یک راه خوب اینه که یک گروه کاربری مخصوص SSH بسازیم و فقط به اعضای اون گروه اجازه اتصال بدیم. اینطوری، برای دادن یا گرفتن دسترسی SSH از یک کاربر، کافیه اون رو به این گروه اضافه یا ازش حذف کنیم.
این کار رو با استفاده از گزینه AllowGroups در فایل تنظیمات SSH یعنی /etc/ssh/sshd_config انجام میدیم.
مراحل عملی:
ساختن گروه: یک گروه جدید به اسم sshusers (یا هر اسم دیگهای که دوست دارید) بسازید:
sudo groupadd sshusers
اضافه کردن کاربران به گروه: حالا هر کاربری که میخواید بهش اجازه دسترسی SSH بدید رو به این گروه اضافه کنید:
sudo usermod -a -G sshusers user1
sudo usermod -a -G sshusers user2
این کار رو برای تمام کاربرانی که نیاز به دسترسی SSH دارن، انجام بدید. در بخش بعدی، از این گروه در تنظیمات SSH استفاده میکنیم.
امنسازی فایل کانفیگ SSH (sshd_config)
فایل /etc/ssh/sshd_config قلب تپنده تنظیمات سرور SSH شماست. با ویرایش این فایل، میتونیم به سرور SSH بگیم که با چه گزینههایی کار کنه و چطور رفتار کنه. ما این فایل رو طوری تغییر میدیم که از یک کانفیگ امن استفاده کنه.
مراحل عملی:
تهیه نسخه پشتیبان: اول از همه، یک نسخه پشتیبان از فایل کانفیگ فعلی بگیرید تا اگه مشکلی پیش اومد، بتونید به حالت قبل برگردید. دستور زیر یک کپی از فایل با تاریخ و ساعت فعلی در اسمش میسازه. بعد از اون، کامنتها و خطوط خالی رو از فایل اصلی حذف میکنیم تا خوندنش راحتتر بشه.
sudo cp --archive /etc/ssh/sshd_config /etc/ssh/sshd_config-COPY-$(date +"%Y%m%d%H%M%S")
sudo sed -i -r -e '/^#|^$/ d' /etc/ssh/sshd_config
ویرایش فایل sshd_config: حالا فایل /etc/ssh/sshd_config رو با ویرایشگر متن مورد علاقهتون (مثل nano یا vim) باز کنید و تنظیمات زیر رو پیدا کنید و تغییر بدید، یا اگه وجود ندارن، به فایل اضافه کنید.
نکته خیلی مهم: سرور SSH تنظیمات تکراری و متناقض رو دوست نداره. مثلا اگه در فایل شما هم ChallengeResponseAuthentication no باشه و هم ChallengeResponseAuthentication yes، SSH فقط اولی رو در نظر میگیره و دومی رو نادیده میگیره. پس حتما فایل رو به دقت بررسی کنید و مطمئن بشید که هیچ تنظیمات متناقضی وجود نداره.
این تنظیمات از راهنمای OpenSSH موزیلا برای نسخههای 6.7 به بالا گرفته شدن و به طور کلی امنیت رو بهبود میبخشن:
# الگوریتمهای HostKey پشتیبانی شده به ترتیب اولویت
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
# الگوریتمهای تبادل کلید
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
# الگوریتمهای رمزنگاری
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
# الگوریتمهای MAC
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
# سطح لاگبرداری رو روی VERBOSE تنظیم میکنیم تا اثر انگشت کلید کاربر در لاگها ثبت بشه
LogLevel VERBOSE
# استفاده از sandbox برای افزایش امنیت (این گزینه در نسخههای جدید منسوخ شده)
# UsePrivilegeSeparation sandbox
و این تنظیمات عمومیتر برای افزایش امنیت:
# اجازه نده کاربران متغیرهای محیطی رو تنظیم کنن
PermitUserEnvironment no
# لاگ کردن دسترسی به فایلها در سطح sftp
Subsystem sftp internal-sftp -f AUTHPRIV -l INFO
# فقط از پروتکل امنتر و جدیدتر نسخه ۲ استفاده کن
Protocol 2
# فوروارد کردن X11 رو غیرفعال کن چون ناامن هست
X11Forwarding no
# فوروارد کردن پورت رو غیرفعال کن
AllowTcpForwarding no
AllowStreamLocalForwarding no
GatewayPorts no
PermitTunnel no
# اجازه لاگین با پسورد خالی رو نده
PermitEmptyPasswords no
# فایلهای .rhosts و .shosts رو نادیده بگیر
IgnoreRhosts yes
# نام هاست رو با IP تطبیق بده
UseDNS yes
# فشردهسازی رو غیرفعال کن
Compression no
# زنده نگه داشتن اتصال TCP رو غیرفعال کن
TCPKeepAlive no
# فوروارد کردن ایجنت رو غیرفعال کن
AllowAgentForwarding no
# اجازه لاگین به کاربر روت رو نده
PermitRootLogin no
# احراز هویت مبتنی بر هاست رو غیرفعال کن
HostbasedAuthentication no
# هش کردن هاستهای شناخته شده
HashKnownHosts yes
تنظیمات سفارشی: حالا این تنظیمات رو بر اساس نیاز و شرایط خودتون پیدا کنید و مقدارشون رو تغییر بدید:
تنظیم
مقادیر معتبر
مثال
توضیحات
AllowGroups
نام گروه محلی
AllowGroups sshusers
گروهی که اجازه دسترسی SSH داره (همون گروهی که در مرحله قبل ساختیم)
ClientAliveCountMax
عدد
ClientAliveCountMax 0
حداکثر تعداد پیام زنده بودن کلاینت که بدون پاسخ ارسال میشه
ClientAliveInterval
عدد (ثانیه)
ClientAliveInterval 300
تایماوت به ثانیه قبل از ارسال درخواست پاسخ از کلاینت
ListenAddress
لیست آدرسهای محلی
ListenAddress 0.0.0.0
آدرسهای IP محلی که سرور SSH باید روی اونها گوش بده
LoginGraceTime
عدد (ثانیه)
LoginGraceTime 30
مدت زمان به ثانیه که کاربر برای لاگین فرصت داره
MaxAuthTries
عدد
MaxAuthTries 2
حداکثر تعداد تلاشهای ناموفق برای لاگین
MaxSessions
عدد
MaxSessions 2
حداکثر تعداد نشستهای باز برای هر اتصال
PasswordAuthentication
yes یا no
PasswordAuthentication no
آیا لاگین با پسورد مجازه یا نه (اگه از کلید استفاده میکنید، اینو no بذارید)
Port
شماره پورت
Port 22
پورتی که سرور SSH باید روی اون گوش بده (میتونید برای امنیت بیشتر تغییرش بدید)
بررسی تنظیمات و ریاستارت: بعد از ذخیره کردن فایل، با دستور زیر چک کنید که هیچ تنظیمات متناقضی وجود نداشته باشه. این دستور نباید هیچ خروجیای داشته باشه:
حالا سرویس SSH رو ریاستارت کنید تا تغییرات اعمال بشن:
sudo service sshd restart
برای اطمینان، میتونید با دستور sudo sshd -T کانفیگ فعال SSH رو ببینید و مطمئن بشید که همه چیز درسته.
حذف کلیدهای ضعیف Diffie-Hellman
بر اساس راهنمای موزیلا، تمام ضرایب (moduli) الگوریتم Diffie-Hellman که در SSH استفاده میشن، باید حداقل ۳۰۷۲ بیت طول داشته باشن. این الگوریتم برای برقراری اتصال امن استفاده میشه و هرچقدر اندازه کلید بزرگتر باشه، رمزنگاری قویتره. ما کلیدهای کوتاهتر از ۳۰۷۲ بیت رو حذف میکنیم.
حتی با وجود امنسازی SSH، این در همچنان برای هکرها قابل مشاهده است و میتونن سعی کنن با حملات brute-force اون رو باز کنن. اضافه کردن یک لایه امنیتی دیگه مثل احراز هویت دو مرحلهای (2FA) یا چند مرحلهای (MFA)، کار رو برای اونها خیلی سختتر میکنه.
با فعال کردن 2FA، هر کسی که میخواد به سرور وصل بشه، به دو چیز نیاز داره:
پسوردش
یک کد ۶ رقمی که هر ۳۰ ثانیه یک بار توسط یک اپلیکیشن روی گوشی تولید میشه.
بدون داشتن هر دوی اینها، امکان ورود وجود نخواهد داشت. البته این کار ممکنه برای بعضیها کمی دست و پا گیر باشه و دسترسی شما به سرور به اپلیکیشن تولیدکننده کد روی گوشیتون وابسته میشه.
این روش چطور کار میکنه؟
در لینوکس، سیستمی به اسم PAM مسئول فرآیندهای احراز هویت هست. وقتی شما از طریق SSH میخواید لاگین کنید، PAM درخواست شما رو مدیریت میکنه. ما قوانین PAM رو برای SSH طوری تغییر میدیم که علاوه بر پسورد، از شما یک کد ۶ رقمی هم بخواد.
برای این کار از ماژول libpam-google-authenticator گوگل استفاده میکنیم. این ماژول یک کلید TOTP (Time-based One-time Password) رو تولید و تایید میکنه. ما به PAM میگیم که اول پسورد کاربر رو چک کنه و اگه درست بود، درخواست رو به ماژول google-authenticator بفرسته تا اون هم کد ۶ رقمی رو از کاربر بگیره و تایید کنه. فقط در صورتی که هر دو مرحله موفقیتآمیز باشن، کاربر اجازه لاگین پیدا میکنه.
نکته: با تنظیماتی که در ادامه میاد، کاربر فقط وقتی با پسورد لاگین میکنه به کد 2FA نیاز داره. اگه با کلید SSH وصل بشه، این کد پرسیده نمیشه.
مراحل عملی:
نصب ماژول: در سیستمهای مبتنی بر دبیان:
sudo apt install libpam-google-authenticator
ساخت توکن برای کاربر: با همون کاربری که میخواید براش 2FA رو فعال کنید، لاگین کنید و دستور google-authenticator رو اجرا کنید. این دستور رو به عنوان کاربر روت اجرا نکنید.
google-authenticator
این برنامه از شما چندتا سوال میپرسه. برای بیشتر سوالها میتونید گزینه پیشفرض (y) رو انتخاب کنید.
Do you want authentication tokens to be time-based (y/n) y
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/user@host%3Fsecret%3DR4ZWX34FQKZROVX7AGLJ64684Y%26issuer%3Dhost
...
Your new secret key is: R3NVX3FFQKZROVX7AGLJUGGESY
Your verification code is 751419
Your emergency scratch codes are:
12345678
90123456
78901234
56789012
34567890
...
برنامه یک کد QR به شما نشون میده که باید با اپلیکیشن احراز هویت روی گوشیتون (مثل Google Authenticator یا Authy) اسکن کنید. حتما کدهای اضطراری (emergency scratch codes) رو یک جای امن یادداشت کنید. اگه به گوشیتون دسترسی نداشته باشید، با این کدها میتونید لاگین کنید.
تنظیم PAM برای SSH: یک نسخه پشتیبان از فایل /etc/pam.d/sshd بگیرید:
حالا خط زیر رو به فایل /etc/pam.d/sshd اضافه کنید تا ماژول گوگل به عنوان یک روش احراز هویت فعال بشه:
auth required pam_google_authenticator.so nullok
کلمه nullok به این معنیه که اگه کاربری هنوز 2FA رو برای خودش تنظیم نکرده، بتونه بدون کد لاگین کنه. میتونید با این دستور خط رو به انتهای فایل اضافه کنید:
echo -e "\nauth required pam_google_authenticator.so nullok # added by $(whoami) on $(date +\"%Y-%m-%d @ %H:%M:%S\")" | sudo tee -a /etc/pam.d/sshd
تنظیم SSH برای استفاده از PAM: در فایل /etc/ssh/sshd_config، گزینه ChallengeResponseAuthentication رو پیدا کنید و مقدارش رو yes بذارید:
ChallengeResponseAuthentication yes
با دستورات زیر میتونید این کار رو به صورت خودکار انجام بدید:
sudo sed -i -r -e "s/^(challengeresponseauthentication .*)$/# \1 # commented by $(whoami) on $(date +\"%Y-%m-%d @ %H:%M:%S\")/I" /etc/ssh/sshd_config
echo -e "\nChallengeResponseAuthentication yes # added by $(whoami) on $(date +\"%Y-%m-%d @ %H:%M:%S\")" | sudo tee -a /etc/ssh/sshd_config
ریاستارت سرویس SSH:
sudo service sshd restart
حالا اگه بخواید با پسورد به سرور وصل بشید، بعد از وارد کردن پسورد، از شما «Verification code» خواسته میشه که باید کد ۶ رقمی رو از اپلیکیشن گوشیتون وارد کنید.
بخش دوم: موارد پایهای و اساسی
بعد از امن کردن در ورودی اصلی یعنی SSH، نوبت به یک سری تنظیمات پایهای و اساسی در خود سیستمعامل میرسه. این تنظیمات به ما کمک میکنن تا کنترل بیشتری روی دسترسیها داشته باشیم و جلوی خیلی از مشکلات امنیتی رایج رو بگیریم.
محدود کردن دسترسی به sudo
دستور sudo به کاربران عادی اجازه میده تا دستورات رو با دسترسی کاربر روت (یا کاربران دیگه) اجرا کنن. این یک ابزار خیلی قدرتمنده، اما اگه هر کاربری بتونه ازش استفاده کنه، میتونه خطرناک باشه. ما میخوایم مطمئن بشیم که فقط کاربرانی که ما تعیین میکنیم، میتونن از sudo استفاده کنن.
نکته: ممکنه توزیع شما موقع نصب، به صورت خودکار یک گروه مخصوص برای sudo ساخته باشه (مثلا گروه sudo در دبیان یا گروه wheel در RedHat). قبل از انجام این مراحل، این موضوع رو چک کنید.
مراحل عملی:
ساختن گروه: یک گروه جدید برای کاربرانی که اجازه استفاده از sudo دارن میسازیم (میتونید از گروه موجود هم استفاده کنید):
sudo groupadd sudousers
اضافه کردن کاربران به گروه: کاربرانی که نیاز به دسترسی sudo دارن رو به این گروه اضافه کنید:
sudo usermod -a -G sudousers user1
sudo usermod -a -G sudousers user2
تنظیم فایل sudoers: فایل تنظیمات sudo در مسیر /etc/sudoers قرار داره. برای ویرایش این فایل همیشه باید از دستور sudo visudo استفاده کنید. این دستور قبل از ذخیره کردن تغییرات، فایل رو از نظر سینتکس چک میکنه تا جلوی اشتباهاتی که میتونن سیستم رو خراب کنن، بگیره.
sudo visudo
در فایلی که باز میشه، این خط رو اضافه کنید تا فقط اعضای گروه sudousers بتونن از sudo استفاده کنن:
%sudousers ALL=(ALL:ALL) ALL
علامت % قبل از اسم گروه، نشون میده که این یک گروه کاربریه.
محدود کردن دسترسی به su
دستور su هم مثل sudo به کاربران اجازه میده تا هویت خودشون رو به کاربر دیگهای (معمولا روت) تغییر بدن. ما میخوایم استفاده از این دستور رو هم محدود کنیم.
مراحل عملی:
ساختن گروه: یک گروه جدید برای کاربرانی که اجازه استفاده از su دارن میسازیم:
sudo groupadd suusers
اضافه کردن کاربران به گروه: کاربران مورد نظر رو به این گروه اضافه کنید:
sudo usermod -a -G suusers user1
sudo usermod -a -G suusers user2
محدود کردن اجرای su: با دستور زیر، کاری میکنیم که فقط کاربر روت و اعضای گروه suusers بتونن فایل اجرایی /bin/su رو اجرا کنن:
خیلی از برنامهها، به خصوص مرورگرهای وب و کلاینتهای ایمیل، بهتره که در یک محیط ایزوله یا «Sandbox» اجرا بشن. این کار باعث میشه که برنامه در یک زندان مجازی قرار بگیره و فقط به تعداد محدودی از دایرکتوریهای امن دسترسی داشته باشه و نتونه به بقیه سیستم آسیب بزنه.
مراحل عملی:
نصب Firejail:
sudo apt install firejail firejail-profiles
برای دبیان ۱۰، پیشنهاد میشه از بکپورت رسمی استفاده کنید:
فعال کردن Sandbox برای برنامهها: برای اینکه یک برنامه همیشه به صورت خودکار در Sandbox اجرا بشه، باید یک symbolic link از firejail به اسم اون برنامه در مسیر /usr/local/bin بسازید. برای مثال برای چند برنامه رایج:
بررسی وضعیت: بعد از این کار، وقتی برنامه رو به صورت عادی اجرا میکنید، در واقع firejail اون رو در محیط ایزوله اجرا میکنه. برای اینکه ببینید چه برنامههایی در حال حاضر در زندان firejail در حال اجرا هستن، از این دستور استفاده کنید:
firejail --list
غیرفعال کردن Sandbox: اگه خواستید یک برنامه دوباره به صورت عادی اجرا بشه، کافیه symbolic link اون رو حذف کنید:
sudo rm /usr/local/bin/firefox
همگامسازی زمان سرور با NTP
زمان سیستم برای خیلی از پروتکلهای امنیتی و لاگها خیلی مهمه. اگه ساعت سرور شما دقیق نباشه، میتونه مشکلات زیادی ایجاد کنه. یک کلاینت NTP میتونه این مشکل رو با همگامسازی مداوم ساعت سرور شما با سرورهای زمان جهانی حل کنه.
NTP مخفف Network Time Protocol هست. ما یک کلاینت NTP روی سرور نصب میکنیم تا زمان دقیق رو از سرورهای عمومی NTP بگیره و ساعت سیستم رو تنظیم کنه.
مراحل عملی:
نصب NTP: در سیستمهای مبتنی بر دبیان:
sudo apt install ntp
تنظیم کلاینت NTP: فایل کانفیگ NTP در مسیر /etc/ntp.conf قرار داره. کانفیگ پیشفرض معمولا امنه، اما ما میخوایم مطمئن بشیم که از دستور pool به جای server استفاده میکنیم. دستور pool به کلاینت اجازه میده اگه یک سرور پاسخگو نبود یا زمان اشتباهی میداد، اون رو کنار بذاره و از سرورهای دیگه استفاده کنه.
حالا تمام خطوطی که با server شروع میشن رو کامنت کنید و خط زیر رو به فایل /etc/ntp.conf اضافه کنید:
pool pool.ntp.org iburst
میتونید با دستورات زیر این کار رو انجام بدید:
sudo sed -i -r -e "s/^((server|pool).*)/# \1 # commented by $(whoami) on $(date +\"%Y-%m-%d @ %H:%M:%S\")/\" /etc/ntp.conf
echo -e "\npool pool.ntp.org iburst # added by $(whoami) on $(date +\"%Y-%m-%d @ %H:%M:%S\")" | sudo tee -a /etc/ntp.conf
ریاستارت و بررسی وضعیت: سرویس NTP رو ریاستارت کنید:
sudo service ntp restart
برای دیدن وضعیت سرویس و اینکه آیا با سرورهای زمانی ارتباط برقرار کرده یا نه، از دستورات زیر استفاده کنید:
sudo systemctl status ntp
sudo ntpq -p
خروجی دستور ntpq -p باید لیستی از سرورهایی که بهشون وصل شده رو نشون بده.
امنسازی دایرکتوری /proc
در لینوکس، دایرکتوری /proc حاوی اطلاعات زیادی در مورد فرآیندهای در حال اجراست. به صورت پیشفرض، همه کاربران محلی میتونن اطلاعات تمام فرآیندها رو ببینن، حتی فرآیندهایی که متعلق به کاربران دیگهست. این میتونه باعث نشت اطلاعات حساس بشه. با یک تغییر کوچیک در تنظیمات فایل سیستم، میتونیم این رفتار رو تغییر بدیم.
نکته: این تغییر ممکنه روی بعضی سیستمهایی که از systemd استفاده میکنن، مشکل ایجاد کنه.
مراحل عملی:
ویرایش فایل fstab: اول یک نسخه پشتیبان از فایل /etc/fstab بگیرید:
خط زیر رو به فایل /etc/fstab اضافه کنید تا دایرکتوری /proc با گزینه hidepid=2 مونت بشه. این گزینه باعث میشه هر کاربر فقط بتونه اطلاعات فرآیندهای خودش رو ببینه.
proc /proc proc defaults,hidepid=2 0 0
میتونید با این دستور خط رو اضافه کنید:
echo -e "\nproc /proc proc defaults,hidepid=2 0 0 # added by $(whoami) on $(date +\"%Y-%m-%d @ %H:%M:%S\")" | sudo tee -a /etc/fstab
اعمال تغییرات: برای اعمال تغییرات، باید سیستم رو ریبوت کنید:
sudo reboot now
یا اینکه میتونید بدون ریبوت، /proc رو دوباره با گزینههای جدید مونت کنید:
sudo mount -o remount,hidepid=2 /proc
اعمال سیاستهای رمز عبور قوی
به صورت پیشفرض، کاربران میتونن هر پسوردی که دوست دارن انتخاب کنن، حتی پسوردهای ضعیف و ساده. ابزار pwquality یا pam_pwquality این مشکل رو با اعمال یک سری قوانین برای کیفیت پسوردها حل میکنه. این ابزار قدرت پسورد رو با یک دیکشنری و یک سری قوانین برای تشخیص پسوردهای ضعیف چک میکنه.
ما از این ابزار در سیستم PAM استفاده میکنیم. هر وقت کاربری بخواد پسوردش رو تغییر بده، PAM پسورد جدید رو به pwquality میده تا چکش کنه. اگه پسورد از نظر این ابزار قوی بود، تغییر اعمال میشه، در غیر این صورت خطا میده.
مراحل عملی:
نصب ابزار: در سیستمهای مبتنی بر دبیان:
sudo apt install libpam-pwquality
تنظیم PAM: فایل تنظیمات پسورد در PAM در مسیر /etc/pam.d/common-password قرار داره. اول یک نسخه پشتیبان ازش بگیرید:
retry=3: به کاربر ۳ بار فرصت میده تا پسورد مناسب رو وارد کنه.
minlen=10: حداقل طول پسورد باید ۱۰ کاراکتر باشه.
dcredit=-1: پسورد باید حداقل یک عدد داشته باشه.
ucredit=-1: پسورد باید حداقل یک حرف بزرگ انگلیسی داشته باشه.
lcredit=-1: پسورد باید حداقل یک حرف کوچک انگلیسی داشته باشه.
ocredit=-1: پسورد باید حداقل یک کاراکتر غیر الفبایی (مثل !@#$%) داشته باشه.
difok=3: حداقل ۳ کاراکتر از پسورد جدید نباید در پسورد قبلی وجود داشته باشه.
maxrepeat=3: حداکثر ۳ کاراکتر تکراری پشت سر هم مجازه.
gecoschec: اجازه نمیده نام کاربری در پسورد استفاده بشه.
میتونید با دستور sed زیر این تغییر رو به صورت خودکار انجام بدید:
sudo sed -i -r -e "s/^(password\s+requisite\s+pam_pwquality.so)(.*)$/# \1\2 # commented by $(whoami) on $(date +\"%Y-%m-%d @ %H:%M:%S\")\n\1 retry=3 minlen=10 difok=3 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1 maxrepeat=3 gecoschec # added by $(whoami) on $(date +\"%Y-%m-%d @ %H:%M:%S\")/" /etc/pam.d/common-password
بهروزرسانیهای خودکار
بهروز نگه داشتن سرور با آخرین پچها و آپدیتهای امنیتی حیاتیه. در غیر این صورت، شما در معرض آسیبپذیریهای شناختهشدهای قرار میگیرید که هکرها میتونن ازشون برای نفوذ استفاده کنن.
مگر اینکه قصد داشته باشید هر روز سرور رو چک کنید، وگرنه به یک راه برای آپدیت خودکار سیستم و یا دریافت ایمیل در مورد آپدیتهای موجود نیاز دارید. البته ما نمیخوایم همه آپدیتها به صورت خودکار نصب بشن، چون هر آپدیتی ریسک خراب کردن چیزی رو به همراه داره. مهمه که آپدیتهای حیاتی و امنیتی به صورت خودکار نصب بشن، اما بقیه آپدیتها میتونن منتظر بمونن تا شما به صورت دستی نصبشون کنید.
نکته: این بخش برای سیستمهای مبتنی بر دبیان نوشته شده و برای این کار، سرور شما باید بتونه ایمیل بفرسته.
در سیستمهای مبتنی بر دبیان، ما از سه ابزار استفاده میکنیم:
unattended-upgrades: برای نصب خودکار آپدیتهای مهم (مثل آپدیتهای امنیتی).
apt-listchanges: برای دریافت جزئیات در مورد تغییرات بستهها قبل از اینکه نصب بشن.
apticron: برای دریافت ایمیل در مورد آپدیتهای باقیمانده.
تنظیم unattended-upgrades: ما برای تنظیمات، به جای ویرایش فایلهای اصلی، یک فایل جدید در مسیر /etc/apt/apt.conf.d/51myunattended-upgrades میسازیم و تنظیمات زیر رو داخلش قرار میدیم. این کار باعث میشه تنظیمات ما با آپدیتهای آینده از بین نره.
// فعال کردن اسکریپت آپدیت/ارتقا
APT::Periodic::Enable "1";
// اجرای خودکار "apt-get update" هر ۱ روز
APT::Periodic::Update-Package-Lists "1";
// دانلود خودکار بستههای قابل ارتقا هر ۱ روز
APT::Periodic::Download-Upgradeable-Packages "1";
// اجرای خودکار "apt-get autoclean" هر ۷ روز
APT::Periodic::AutocleanInterval "7";
// ارسال ایمیل گزارش با جزئیات
APT::Periodic::Verbose "2";
// فعال کردن آپدیت بدون دخالت
APT::Periodic::Unattended-Upgrade "1";
// آپدیت خودکار بستهها از این منابع
Unattended-Upgrade::Origins-Pattern {
"o=Debian,a=stable";
"o=Debian,a=stable-updates";
"origin=Debian,codename=${distro_codename},label=Debian-Security";
};
// لیست بستههایی که نباید خودکار آپدیت بشن (میتونید پر کنید)
Unattended-Upgrade::Package-Blacklist {
};
// اگه فرآیند dpkg ناقص مونده بود، به صورت خودکار تعمیرش کن
Unattended-Upgrade::AutoFixInterruptedDpkg "true";
// آپگرید رو موقعی که سیستم روشنه انجام بده
Unattended-Upgrade::InstallOnShutdown "false";
// به این آدرس ایمیل گزارش بفرست
Unattended-Upgrade::Mail "root";
// همیشه ایمیل بفرست، نه فقط موقع خطا
Unattended-Upgrade::MailOnlyOnError "false";
// وابستگیهای استفادهنشده رو بعد از آپگرید حذف کن
Unattended-Upgrade::Remove-Unused-Dependencies "true";
// اگه بعد از آپگرید نیاز به ریبوت بود، به صورت خودکار و بدون تایید ریبوت کن
Unattended-Upgrade::Automatic-Reboot "true";
// حتی اگه کاربری لاگین کرده بود، ریبوت کن
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
تست و تنظیم ابزارهای جانبی: با دستور زیر میتونید یک اجرای آزمایشی (dry-run) انجام بدید تا مطمئن بشید کانفیگ درسته:
sudo unattended-upgrade -d --dry-run
برای تنظیم apt-listchanges از این دستور استفاده کنید و به سوالاتش به دلخواه جواب بدید:
sudo dpkg-reconfigure apt-listchanges
تنظیمات پیشفرض apticron معمولا خوبه، اما میتونید اونها رو در فایل /etc/apticron/apticron.conf تغییر بدید. مثلا برای ارسال ایمیل به root و دریافت نوتیفیکیشن حتی وقتی آپدیتی وجود نداره:
EMAIL="root"
NOTIFY_NO_UPDATES="1"
بخش سوم: شبکه
تا اینجا درهای ورودی رو امن کردیم و یک سری اصول اولیه رو رعایت کردیم. حالا نوبت به مدیریت ترافیک شبکه میرسه. ما باید مثل یک نگهبان دقیق، کنترل کنیم که چه دادههایی اجازه ورود به سرور و خروج از اون رو دارن. این کار با استفاده از فایروال و ابزارهای مانیتورینگ شبکه انجام میشه.
تنظیم فایروال با UFW
منطق امنیتی میگه «به طور پیشفرض همه چیز رو رد کن، مگر اینکه به طور مشخص اجازه داده باشی». چرا باید سرور من ترافیکی به بیرون بفرسته که من ازش خبر ندارم؟ یا چرا باید ترافیکی از بیرون سعی کنه به سرور من دسترسی پیدا کنه که من نمیدونم چیه؟ برای همین، ما میخوایم تمام ترافیک ورودی و خروجی رو مسدود کنیم و فقط به ترافیکی که خودمون میخوایم، اجازه عبور بدیم.
این کار وظیفه فایرواله. در لینوکس، ابزار اصلی فایروال iptables هست، اما کار کردن باهاش کمی پیچیدهست. برای همین ما از UFW (Uncomplicated Firewall) استفاده میکنیم که یک رابط کاربری ساده برای iptables هست.
مراحل عملی:
نصب UFW: در سیستمهای مبتنی بر دبیان:
sudo apt install ufw
تنظیم قوانین پیشفرض: ما به صورت پیشفرض تمام ترافیک خروجی و ورودی رو مسدود میکنیم:
sudo ufw default deny outgoing comment 'deny all outgoing traffic'
sudo ufw default deny incoming comment 'deny all incoming traffic'
اگه با مسدود کردن تمام ترافیک خروجی راحت نیستید، میتونید به جاش اجازه بدید: sudo ufw default allow outgoing
ایجاد قوانین برای ترافیک مجاز: حالا باید به ترافیکهایی که بهشون نیاز داریم، اجازه عبور بدیم.
اجازه دادن به اتصالات SSH: این مهمترینه، وگرنه خودمون هم قفل میشیم!
sudo ufw limit in ssh comment 'allow SSH connections in'
گزینه limit از حملات brute-force جلوگیری میکنه.
اجازه دادن به ترافیکهای رایج:
# اجازه به DNS برای ترجمه نام دامنه
sudo ufw allow out 53 comment 'allow DNS calls out'
# اجازه به NTP برای همگامسازی زمان
sudo ufw allow out 123 comment 'allow NTP out'
# اجازه به HTTP و HTTPS برای آپدیت و...
sudo ufw allow out http comment 'allow HTTP traffic out'
sudo ufw allow out https comment 'allow HTTPS traffic out'
# اجازه به SMTP برای ارسال ایمیلهای هشدار
sudo ufw allow out 587 comment 'allow SMTP out'
شما باید بر اساس نیازهای سرورتون، قوانین لازم رو اضافه کنید.
فعالسازی و بررسی وضعیت UFW: با دستور زیر فایروال رو فعال کنید:
sudo ufw enable
از شما یک سوال تایید میپرسه چون ممکنه اتصالات فعلی SSH رو قطع کنه. y رو بزنید و ادامه بدید.
برای دیدن وضعیت فایروال و قوانین فعال، از دستور زیر استفاده کنید:
sudo ufw status verbose
این دستور یک لیست کامل از قوانین، سیاستهای پیشفرض و وضعیت فایروال رو به شما نشون میده.
تشخیص نفوذ با PSAD
فایروال درها رو میبنده، اما هکرها همچنان میتونن سعی کنن به درهای باز (مثل پورت SSH) حمله کنن. ما به یک سیستم نیاز داریم که فعالیتهای شبکه رو برای پیدا کردن تلاشهای نفوذ مثل اسکن پورتها یا حملات DDoS زیر نظر بگیره و به صورت خودکار جلوی اونها رو بگیره. برای این کار از PSAD (Port Scan Attack Detector) استفاده میکنیم.
PSAD لاگهای فایروال (iptables) رو اسکن میکنه تا ترافیک مشکوک رو تشخیص بده و در صورت نیاز، IP مهاجم رو مسدود کنه.
مراحل عملی:
نصب PSAD: در سیستمهای مبتنی بر دبیان:
sudo apt install psad
تنظیم PSAD: فایل کانفیگ اصلی در /etc/psad/psad.conf قرار داره. این فایل رو باز کنید و حداقل این گزینهها رو با اطلاعات خودتون پر کنید:
EMAIL_ADDRESSES: آدرس ایمیل شما برای دریافت هشدارها.
HOSTNAME: نام هاست سرور شما.
ENABLE_AUTO_IDS: این رو Y بذارید تا PSAD به صورت خودکار IPهای مهاجم رو مسدود کنه.
یکپارچهسازی PSAD با UFW: برای اینکه PSAD بتونه کار کنه، UFW باید تمام ترافیک رو لاگ کنه. برای این کار، فایلهای /etc/ufw/before.rules و /etc/ufw/before6.rules رو ویرایش کنید و این خطوط رو قبل از خط COMMIT در انتهای فایل اضافه کنید:
# log all traffic so psad can analyze
-A INPUT -j LOG --log-tcp-options --log-prefix "[IPTABLES] "
-A FORWARD -j LOG --log-tcp-options --log-prefix "[IPTABLES] "
این پیشوند [IPTABLES] به ما کمک میکنه بعدا لاگهای فایروال رو جدا کنیم.
ریاستارت سرویسها: حالا UFW و PSAD رو ریاستارت کنید تا تغییرات اعمال بشن:
برای بررسی وضعیت PSAD از دستور sudo psad --Status استفاده کنید.
جلوگیری از حملات Brute-force با Fail2ban
UFW درها رو میبنده و PSAD مراقب تلاش برای پیدا کردن درهاست. اما در مورد سرویسهایی که درهای اونها بازه (مثل SSH یا یک وب سرور) چطور؟ اینجا جاییه که Fail2ban وارد میشه.
Fail2ban لاگهای برنامههای شما رو (مثل لاگهای احراز هویت SSH) زیر نظر میگیره تا تلاشهای ناموفق مکرر رو تشخیص بده. اگه یک IP در یک بازه زمانی کوتاه، چندین بار تلاش ناموفق برای لاگین داشته باشه، Fail2ban به صورت خودکار اون IP رو برای مدتی مسدود میکنه.
مراحل عملی:
نصب Fail2ban: در سیستمهای مبتنی بر دبیان:
sudo apt install fail2ban
تنظیمات عمومی: ما فایلهای کانفیگ اصلی رو ویرایش نمیکنیم. به جاش یک فایل به اسم /etc/fail2ban/jail.local میسازیم و تنظیمات عمومی خودمون رو اونجا قرار میدیم:
[DEFAULT]
# رنج IPهایی که باید نادیده گرفته بشن (مثل شبکه محلی خودتون)
ignoreip = 127.0.0.1/8 [LAN SEGMENT]
# آدرس ایمیل برای دریافت هشدار
destemail = [your e-mail]
sender = [your e-mail]
# اکشنی که بعد از بن کردن انجام میشه (ارسال ایمیل)
action = %(action_mwl)s
به جای [LAN SEGMENT] رنج IP شبکه محلی خودتون (مثلا 192.168.1.0/24) و به جای [your e-mail] آدرس ایمیلتون رو بذارید.
ساختن زندان (Jail) برای SSH: حالا باید به Fail2ban بگیم که لاگهای SSH رو زیر نظر بگیره. برای این کار، یک فایل به اسم /etc/fail2ban/jail.d/ssh.local میسازیم و این محتوا رو داخلش میذاریم:
این تنظیمات میگه که زندان sshd فعاله، برای مسدود کردن از ufw استفاده کنه، پورت ssh رو زیر نظر بگیره، و بعد از ۵ تلاش ناموفق، IP رو مسدود کنه.
فعالسازی و بررسی وضعیت: سرویس Fail2ban رو ریاستارت کنید تا تنظیمات جدید رو بخونه:
sudo fail2ban-client reload
برای دیدن وضعیت Fail2ban و اینکه چه IPهایی مسدود شدن، از دستورات زیر استفاده کنید:
sudo fail2ban-client status
sudo fail2ban-client status sshd
هوش تهدید جمعی با CrowdSec
یک جایگزین مدرنتر برای Fail2ban، ابزاری به اسم CrowdSec هست. CrowdSec هم مثل Fail2ban لاگها رو برای تشخیص حملات مانیتور میکنه، اما یک مزیت بزرگ داره: این ابزار به یک جامعه بزرگ از کاربران متصله و اطلاعات مربوط به IPهای مهاجم رو با همه به اشتراک میذاره.
وقتی یک IP مهاجم روی سرور شما شناسایی میشه، این اطلاعات به صورت ناشناس به سرور مرکزی CrowdSec ارسال میشه. اگه اون IP روی تعداد زیادی از سرورهای دیگه هم فعالیت مخرب داشته باشه، وارد یک لیست سیاه عمومی (Community Blocklist) میشه و این لیست به صورت خودکار برای همه کاربران CrowdSec ارسال میشه. این یعنی سرور شما میتونه به صورت پیشگیرانه IPهای بد رو مسدود کنه، حتی قبل از اینکه به شما حمله کنن.
مراحل عملی:
نصب موتور امنیتی CrowdSec (IDS): ابتدا مخزن CrowdSec رو اضافه کنید:
curl -s https://install.crowdsec.net | sudo sh
سپس موتور امنیتی رو نصب کنید:
sudo apt install crowdsec
موقع نصب، CrowdSec به صورت خودکار برنامههای نصب شده روی سرور شما (مثل SSH) رو تشخیص میده و سناریوهای مربوط به اونها رو فعال میکنه.
نصب کامپوننت واکنش (IPS): CrowdSec به تنهایی فقط یک موتور تشخیصه. برای مسدود کردن IPها، به یک کامپوننت واکنش (Bouncer) نیاز دارید. ما از Bouncer مخصوص iptables استفاده میکنیم:
این کامپوننت به صورت خودکار با موتور امنیتی ارتباط برقرار میکنه و IPهای شناسایی شده رو در فایروال مسدود میکنه.
بررسی وضعیت: با استفاده از ابزار خط فرمان cscli میتونید وضعیت CrowdSec رو ببینید:
sudo cscli metrics
خروجی این دستور اطلاعات کاملی در مورد لاگهای پردازش شده، تصمیمات گرفته شده (مسدود کردن IPها) و وضعیت Bouncerها به شما میده. برای دیدن لیست IPهای مسدود شده میتونید از sudo cscli decisions list استفاده کنید.
بخش چهارم: ممیزی و نظارت
امنسازی یک فرآیند یکباره نیست. شما باید به طور مداوم سیستم رو زیر نظر داشته باشید تا مطمئن بشید همه چیز امنه و هیچ فعالیت مشکوکی در حال وقوع نیست. در این بخش، چند ابزار برای ممیزی، نظارت و گزارشگیری معرفی میکنیم.
نظارت بر تمامیت فایلها با AIDE (WIP)
چطور میتونید مطمئن بشید که هیچ فایل مهمی روی سرور شما (مثل فایلهای کانفیگ یا فایلهای اجرایی سیستم) بدون اطلاع شما تغییر نکرده؟ AIDE (Advanced Intrusion Detection Environment) ابزاریه که دقیقا برای همین کار ساخته شده.
AIDE یک بار یک «عکس فوری» یا پایگاه داده از وضعیت فایلهای مهم سیستم شما میگیره. بعد از اون، میتونه به صورت دورهای سیستم رو اسکن کنه و با اون عکس اولیه مقایسه کنه. اگه هر فایلی اضافه، حذف یا تغییر کرده باشه، AIDE به شما گزارش میده.
مراحل عملی (این بخش در حال تکمیله):
نصب AIDE:
sudo apt install aide aide-common
ساخت پایگاه داده اولیه:
sudo aideinit
این دستور سیستم رو اسکن میکنه و پایگاه داده اولیه رو در /var/lib/aide/aide.db.new میسازه و بعد اون رو به /var/lib/aide/aide.db کپی میکنه.
اجرای چک روزانه: با تنظیم فایل /etc/default/aide، میتونید کاری کنید که AIDE هر روز به صورت خودکار اجرا بشه و در صورت پیدا کردن هر تغییری، به شما ایمیل بزنه.
آپدیت پایگاه داده: هر وقت شما به صورت عمدی تغییری در سیستم ایجاد میکنید (مثلا یک برنامه رو آپدیت میکنید)، باید پایگاه داده AIDE رو هم آپدیت کنید تا تغییرات جدید رو به عنوان وضعیت نرمال بشناسه:
sudo aideinit -y -f
اسکن آنتیویروس با ClamAV (WIP)
اگرچه ویروسها در لینوکس به اندازه ویندوز رایج نیستن، اما این به معنی عدم وجود اونها نیست. داشتن یک آنتیویروس برای اسکن دورهای فایلها، به خصوص اگه سرور شما با فایلهای آپلود شده توسط کاربران سر و کار داره، ایده خوبیه. ClamAV یک آنتیویروس متنباز و محبوب برای لینوکسه.
clamav-freshclam: سرویسی که پایگاه داده ویروسها رو به روز نگه میداره.
clamav-daemon: سرویسی که موتور رو در حافظه نگه میداره تا اسکنها سریعتر انجام بشن.
آپدیت پایگاه داده: سرویس freshclam رو استارت کنید تا آخرین تعاریف ویروس رو دانلود کنه:
sudo service clamav-freshclam start
اسکن فایلها: برای اسکن یک فایل یا دایرکتوری، از دستور clamscan استفاده کنید:
# اسکن یک فایل
clamscan /path/to/file
# اسکن یک دایرکتوری به صورت بازگشتی
clamscan -r /path/to/folder
# فقط نمایش فایلهای آلوده
clamscan -r -i /path/to/folder
تشخیص روتکیت با Rkhunter و chkrootkit (WIP)
روتکیتها نوعی بدافزار بسیار خطرناک هستن که سعی میکنن خودشون رو در سطوح پایین سیستمعامل مخفی کنن تا کنترل کامل سیستم رو به دست بگیرن. Rkhunter (Rootkit Hunter) و chkrootkit دو ابزار محبوب برای اسکن سیستم و پیدا کردن روتکیتها، درهای پشتی و بدافزارهای شناختهشده هستن.
مراحل عملی برای Rkhunter:
نصب:sudo apt install rkhunter
آپدیت:sudo rkhunter --update و sudo rkhunter --propupd
اسکن:sudo rkhunter --check
مراحل عملی برای chkrootkit:
نصب:sudo apt install chkrootkit
اسکن:sudo chkrootkit
پیشنهاد میشه این اسکنها به صورت دورهای (مثلا روزانه) اجرا بشن و گزارش اونها برای شما ایمیل بشه.
تحلیلگر و گزارشگر لاگ سیستم با Logwatch
سرور شما به طور مداوم در حال تولید لاگهای زیادیه که حاوی اطلاعات مهمی هستن. خوندن دستی همه این لاگها تقریبا غیرممکنه. Logwatch ابزاریه که لاگهای سیستم رو اسکن، خلاصهسازی و تحلیل میکنه و یک گزارش روزانه مرتب و خوانا برای شما ایمیل میکنه. این گزارش به شما دید خوبی از اتفاقاتی که در ۲۴ ساعت گذشته روی سرورتون افتاده، میده.
مراحل عملی:
نصب Logwatch:
sudo apt install logwatch
تنظیم برای ارسال ایمیل: Logwatch به صورت پیشفرض یک اسکریپت روزانه در /etc/cron.daily/00logwatch داره. ما این اسکریپت رو ویرایش میکنیم تا گزارش رو به جای نمایش در خروجی استاندارد، برای root ایمیل کنه و فرمت اون رو هم HTML بذاریم تا خواناتر باشه. فایل /etc/cron.daily/00logwatch رو باز کنید و خط اجرایی اون رو به این شکل تغییر بدید:
/usr/sbin/logwatch --output mail --format html --mailto root --range yesterday --service all
با این کار، هر روز یک ایمیل خلاصه از تمام لاگهای سرور دریافت خواهید کرد.
مشاهده پورتهای در حال گوش دادن با ss
ما باید بدونیم چه برنامهها و سرویسهایی روی سرور ما در حال اجرا هستن و روی چه پورتهایی برای دریافت اتصال گوش میدن. هر پورت بازی که ما ازش خبر نداریم، یک تهدید امنیتی بالقوهست. دستور ss (مخفف Socket Statistics) یک ابزار قدرتمند برای دیدن اطلاعات سوکتهای شبکه است.
مراحل عملی:
برای دیدن تمام پورتهای TCP و UDP که در حالت “گوش دادن” (LISTEN) هستن، به همراه فرآیندی که اون پورت رو باز کرده، از این دستور استفاده کنید:
sudo ss -lntup
l: فقط سوکتهای در حال گوش دادن رو نشون بده.
n: نام سرویسها رو به شماره پورت تبدیل نکن (سریعتره).
t: سوکتهای TCP رو نشون بده.
u: سوکتهای UDP رو نشون بده.
p: اطلاعات فرآیند مربوط به سوکت رو نشون بده.
خروجی این دستور رو به دقت بررسی کنید. اگه پورت یا فرآیندی رو دیدید که نمیشناسید، حتما در موردش تحقیق کنید و اگه لازم بود، اون سرویس رو متوقف و حذف کنید.
ممیزی امنیتی لینوکس با Lynis
Lynis یک ابزار ممیزی امنیتی فوقالعادهست. این برنامه یک اسکن کامل و جامع روی سیستم شما انجام میده و بر اساس بهترین شیوههای امنیتی، سیستم رو ارزیابی میکنه. در انتهای اسکن، Lynis یک گزارش کامل به همراه یک سری پیشنهادات برای بهبود امنیت سیستم به شما میده. این پیشنهادات شامل کارهایی مثل سختسازی کرنل، تنظیمات فایل سیستم، مدیریت کاربران و خیلی موارد دیگه میشه.
اجرای ممیزی: برای شروع اسکن، این دستور رو اجرا کنید:
sudo lynis audit system
این فرآیند چند دقیقه طول میکشه. در حین اسکن، Lynis نتایج رو روی صفحه نمایش میده. در انتها، یک بخش «Suggestions» وجود داره که باید به دقت بخونید و پیشنهاداتش رو تا جای ممکن روی سیستم خودتون پیادهسازی کنید.
بخش پنجم: منطقه خطر (The Danger Zone)
این بخش شامل مواردیه که ریسک بالایی دارن. انجام این تنظیمات میتونه باعث از کار افتادن سیستم شما بشه یا مشکلاتی ایجاد کنه که رفع کردنشون سخت باشه. خیلیها این موارد رو غیرضروری میدونن چون معتقدن ریسکشون بیشتر از فایدهشونه.
!! با مسئولیت کامل خودتون ادامه بدید !!
سختسازی کرنل لینوکس با sysctl
کرنل مغز سیستمعامل لینوکسه و امن کردنش منطقیه. اما تغییر دادن تنظیمات کرنل با sysctl کار خطرناکیه و میتونه سرور شما رو خراب کنه. اگه دقیقا نمیدونید دارید چیکار میکنید، یا وقت کافی برای دیباگ کردن مشکلات احتمالی رو ندارید، بهتره این بخش رو نادیده بگیرید.
تنظیماتی که در ادامه میان، از چندین منبع معتبر جمعآوری شدن و بیشترشون مربوط به سختسازی عمومی کرنل، بهبود عملکرد و محافظت در برابر حملاتی مثل IP Spoofing و DoS هستن.
مراحل عملی:
به دلیل ریسک بالا، کد آماده برای کپی کردن ارائه نمیشه. شما باید تنظیمات رو از فایل linux-kernel-sysctl-hardening.md در مخزن اصلی این راهنما بردارید و با دقت اعمال کنید.
تست یک تنظیم: قبل از دائمی کردن یک تغییر، میتونید اون رو با دستور sysctl -w تست کنید:
sudo sysctl -w kernel.ctrl-alt-del=0
دائمی کردن تنظیمات: بعد از اینکه از درست کار کردن یک تنظیم مطمئن شدید، اون رو به فایل /etc/sysctl.conf اضافه کنید:
kernel.ctrl-alt-del = 0
fs.file-max = 65535
...
بارگذاری تنظیمات: بعد از ویرایش فایل، با دستور زیر تنظیمات جدید رو بدون نیاز به ریبوت بارگذاری کنید:
sudo sysctl -p
گذاشتن پسورد روی GRUB
اگه یک هکر به سرور شما دسترسی فیزیکی داشته باشه، میتونه از طریق منوی GRUB (بوت لودر) وارد حالت تک کاربره بشه و کنترل کامل سیستم رو به دست بگیره. با گذاشتن پسورد روی GRUB، میتونیم جلوی این کار رو بگیریم.
ریسک: اگه پسورد رو فراموش کنید، بازیابی اون کار سختیه و دردسر زیادی داره.
مراحل عملی:
ساختن هش پسورد: یک هش قوی برای پسوردتون با این دستور بسازید:
grub-mkpasswd-pbkdf2
دستور از شما میخواد که پسورد رو دو بار وارد کنید و بعد یک هش طولانی به شما میده. اون هش رو کپی کنید.
ساختن فایل پسورد: یک فایل جدید به اسم /etc/grub.d/01_password بسازید و این محتوا رو داخلش قرار بدید. به جای [hash]، هشی که در مرحله قبل کپی کردید رو بذارید.
#!/bin/sh
set -e
cat << EOF
set superusers="grub"
password_pbkdf2 grub [hash]
EOF
این فایل رو قابل اجرا کنید:
sudo chmod a+x /etc/grub.d/01_password
بهروزرسانی GRUB: در نهایت، با دستور زیر کانفیگ GRUB رو آپدیت کنید تا تغییرات اعمال بشن:
sudo update-grub
از این به بعد، برای دسترسی به منوی GRUB یا ویرایش گزینههای بوت، باید نام کاربری grub و پسوردی که تعریف کردید رو وارد کنید.
غیرفعال کردن لاگین کاربر Root
اگه شما sudo رو به درستی تنظیم کرده باشید، دیگه تقریبا هیچ نیازی به لاگین مستقیم با کاربر root ندارید. غیرفعال کردن لاگین این کاربر، یک لایه امنیتی دیگه اضافه میکنه.
ریسک: این کار میتونه در بعضی شرایط مشکلساز بشه. مثلا اگه سیستم موقع بوت به مشکل بخوره و بخواد شما رو به شل root برای تعمیر بفرسته، چون حساب root قفل شده، این کار ممکن نمیشه. یک جایگزین بهتر میتونه این باشه که یک پسورد خیلی خیلی طولانی و پیچیده برای root بذارید و اون رو یک جای امن (و غیر دیجیتال) نگه دارید.
مراحل عملی:
برای قفل کردن حساب کاربری root، از این دستور استفاده کنید:
sudo passwd -l root
تغییر umask پیشفرض
umask مشخص میکنه که فایلها و پوشههای جدید با چه سطح دسترسی پیشفرضی ایجاد بشن. سطح دسترسی ناامن میتونه به کاربران دیگه اجازه دسترسی غیرمجاز به دادههای شما رو بده.
ریسک: تغییر umask پیشفرض میتونه مشکلات پیشبینی نشدهای ایجاد کنه. مثلا اگه umask رو برای root خیلی محدود کنید، ممکنه برنامههایی که با دسترسی غیر root اجرا میشن، نتونن فایلهای کانفیگ خودشون رو در /etc بخونن.
مراحل عملی:
تنظیم umask برای کاربران عادی: ما umask رو برای کاربران عادی 0027 تنظیم میکنیم. این یعنی به صورت پیشفرض، خود کاربر دسترسی کامل داره، گروه اصلی کاربر فقط اجازه خوندن و اجرا داره و بقیه هیچ دسترسیای ندارن. این خط رو به انتهای فایلهای /etc/profile و /etc/bash.bashrc اضافه کنید:
umask 0027
و این خط رو هم به فایل /etc/login.defs اضافه کنید:
UMASK 0027
تنظیم umask برای کاربر Root: برای کاربر root، umask رو 0077 تنظیم میکنیم. این یعنی فقط خود root به فایلها و پوشههایی که میسازه دسترسی داره. این خط رو به انتهای فایل /root/.bashrc اضافه کنید:
umask 0077
بخش ششم: موارد متفرقه
در این بخش آخر، چندتا تنظیم و ابزار مفید دیگه رو بررسی میکنیم که به مدیریت و امنیت بهتر سرور کمک میکنن.
ارسال ایمیل از سرور با Exim4 و Gmail
برای اینکه سرور بتونه هشدارهای امنیتی و گزارشها رو برای ما بفرسته، باید بتونه ایمیل ارسال کنه. یک راه ساده و رایگان، استفاده از اکانت جیمیل به عنوان یک رله SMTP هست. ما Exim4 رو طوری تنظیم میکنیم که تمام ایمیلهای سرور رو از طریق اکانت جیمیل شما بفرسته.
نکته مهم: گوگل دیگه اجازه استفاده از پسورد اصلی اکانت رو برای این کار نمیده. شما باید احراز هویت دو مرحلهای رو برای اکانت جیمیلتون فعال کنید و بعد یک «App Password» مخصوص برای سرورتون بسازید و از اون استفاده کنید.
مراحل عملی:
نصب Exim4:
sudo apt install exim4 openssl ca-certificates
پیکربندی Exim4: دستور زیر رو اجرا کنید و به سوالات به این ترتیب جواب بدید:
sudo dpkg-reconfigure exim4-config
General type: mail sent by smarthost; no local mail
System mail name: localhost
IP-addresses to listen on: 127.0.0.1; ::1
Other destinations: (مقدار پیشفرض)
Visible domain name: localhost
IP address or host name of smarthost: smtp.gmail.com::465
Keep number of DNS-queries minimal: No
Split configuration into small files: No
تنظیم پسورد: فایل /etc/exim4/passwd.client رو باز کنید و این خطوط رو بهش اضافه کنید (به جای yourAccount@gmail.com ایمیل جیمیلتون و به جای yourPassword، اپ پسوردی که ساختید رو بذارید):
آپدیت کانفیگ و ریاستارت: با دستورات زیر کانفیگ Exim4 رو آپدیت و سرویس رو ریاستارت کنید:
sudo update-exim4.conf
sudo service exim4 restart
حالا میتونید با دستور mail یک ایمیل تستی بفرستید و در لاگ /var/log/exim4/mainlog وضعیت ارسال رو چک کنید.
جدا کردن لاگهای فایروال
وقتی ترافیک زیادی دارید، لاگهای فایروال (iptables) میتونن خیلی حجیم بشن و در بین بقیه لاگهای سیستم گم بشن. بهتره که این لاگها رو در یک فایل جدا ذخیره کنیم تا تحلیلشون راحتتر بشه.
مراحل عملی:
تنظیم rsyslog: ما قبلا در بخش PSAD، یک پیشوند [IPTABLES] به لاگهای فایروال اضافه کردیم. حالا به rsyslog میگیم هر لاگی که این پیشوند رو داشت، در یک فایل جدا بنویسه. یک فایل به اسم /etc/rsyslog.d/10-iptables.conf بسازید و این محتوا رو داخلش قرار بدید:
& stop به rsyslog میگه که بعد از نوشتن این لاگ در فایل iptables.log، دیگه اون رو در فایلهای لاگ عمومی (مثل syslog) ننویسه.
تنظیم PSAD و Logrotate: حالا باید به PSAD بگیم که لاگها رو از فایل جدید بخونه. در فایل /etc/psad/psad.conf، مقدار IPT_SYSLOG_FILE رو به /var/log/iptables.log تغییر بدید. در آخر، باید به logrotate بگیم که این فایل لاگ جدید رو هم مدیریت و فشرده کنه تا حجمش زیاد نشه. یک فایل به اسم /etc/logrotate.d/iptables بسازید و تنظیمات مربوط به چرخاندن لاگ رو داخلش قرار بدید.
ریاستارت سرویسها: سرویسهای rsyslog و psad رو ریاستارت کنید تا تغییرات اعمال بشن.
این راهنما یک نقطه شروع برای امنسازی سرور لینوکس شماست. امنیت یک مقصد نیست، بلکه یک سفر و یک فرآیند مداومه. همیشه باید بهروز باشید، سیستم رو مانیتور کنید و آماده واکنش به تهدیدهای جدید باشید.
این مقاله بر اساس راهنمای «How-To-Secure-A-Linux-Server» نوشته شده و تحت لایسنس Creative Commons Attribution-ShareAlike 4.0 International قرار دارد.
منابع
[1] GitHub – imthenachoman/How-To-Secure-A-Linux-Server: An evolving how-to guide for securing a Linux server.
گوگل داره یه راه جدید رو امتحان میکنه تا موقع خرید آنلاین، اطلاعات بیشتری در مورد فروشگاهها به دست بیاریم. این قابلیت جدید، خلاصههایی از نظرات کاربران در مورد یک فروشگاه آنلاین رو با استفاده از هوش مصنوعی جمعآوری میکنه و وقتی وارد سایت اون فروشگاه میشید، بهتون نشون میده.
اینجوریه که به زودی توی مرورگر کروم، وقتی وارد سایت یه فروشگاهی میشید، میتونید روی آیکون اطلاعات (info) که سمت چپ آدرس سایت قرار داره کلیک کنید. با این کار یه کادر باز میشه که یه نمای کلی از نظراتی که بقیه در مورد اون شرکت دادن رو بهتون نشه میده. این قابلیت فعلا روی نسخه موبایل کروم در دسترس نیست. چیزی که توی این کادر میبینید، یه خلاصه تولید شده توسط هوش مصنوعیه که از نظرات موجود درست شده.
گوگل توضیح داده که:
«گوگل امتیازهای فروشگاه رو از وبسایتهای معتبری که نظرات کسب و کارها رو جمعآوری میکنن و همینطور از خود کاربرهای گوگل جمع میکنه. این امتیازها در درجه اول، تجربه کلی مصرفکننده بعد از دریافت محصول یا خدمات رو در هر کشور نشون میدن.»
گوگل تاکید داره که از هوش مصنوعی برای «ساختن» نظر جدید استفاده نمیکنه، بلکه فقط نظرات موجود رو توی یه پاراگراف خلاصه میکنه. علاوه بر این خلاصه، امتیاز ستارهای اون کسب و کار هم که بر اساس نظرات گوگل ثبت شده، نمایش داده میشه.
این میتونه یه راه خوب برای به دست آوردن اطلاعات بیشتر در مورد یه کسب و کار باشه، هرچند بعضی از برندها احتمالا دوست دارن روی اطلاعاتی که نمایش داده میشه کنترل داشته باشن و مطمئن بشن که تصویر مثبتی ازشون نشون داده میشه.
خطر این قضیه اینه که خلاصههای هوش مصنوعی ممکنه بعضی چیزها رو اشتباه متوجه بشن یا روی نکات اشتباهی تاکید کنن که برای اون کسب و کار منفی باشه. اما حداقل در تئوری، دستکاری این خلاصهها نباید راحتتر از دستکاری نظرات معمولی گوگل باشه و این خلاصه باید یه تصویر ساده و خوب از بازخورد کلی در مورد یه کسب و کار باشه. این موضوع میتونه برای مصرفکنندهها خوب باشه، حتی اگه یه مساله جدید مثل سئو برای برندها ایجاد کنه.
اگه این قابلیت جا بیفته، نظرات شما در گوگل اهمیت بیشتری پیدا میکنن، چون مشتریها میتونن در هر لحظهای که توی سایت شما هستن، به این اطلاعات دسترسی داشته باشن. پس دیگه فقط برای گرفتن اون کلیک اول تلاش نمیکنید، بلکه این روش بررسی در همه مراحل در دسترسه و بسته به اینکه گوگل چطور این قابلیت رو برجسته کنه، میتونه ارزش فکر کردن داشته باشه. این هم یه ابزار جدید به ابزارهای خرید در حال تحول گوگل اضافه میشه، چون این پلتفرم دنبال اینه که با رقبا در زمینه جستجو رقابت کنه و جایگاه اصلی خودش رو برای کشف و پیدا کردن چیزهای جدید حفظ کنه.
امتیاز فروشگاه چیه و چه کاربردی داره؟
امتیاز فروشگاه به مردم کمک میکنه کسب و کارهایی رو پیدا کنن که تجربه خرید با کیفیتی ارائه میدن. این کار به اعتمادسازی کمک میکنه و باعث میشه مردم با اطلاعات بیشتری خرید کنن. در نتیجه، امتیاز فروشگاه میتونه به فروشندهها کمک کنه تا عملکرد تبلیغات و لیستینگهای رایگانشون رو بهتر کنن و خریداران واجد شرایط بیشتری رو به صفحههای فرودشون بیارن. شروع کار با امتیاز فروشگاه، چه برای بهبود تبلیغات و چه برای لیستینگهای رایگان، یکسانه.
مزایا:
امتیاز فروشگاه در تبلیغات متنی (Text Ads) به طور متوسط باعث بهبود ۲ درصدی نرخ کلیک در شبکه جستجو میشه.
میشه با پیگیری گزارش عملکرد داراییهای خودکار (automated asset performance)، سود عملکرد رو اندازه گرفت و از ارزشی که امتیاز فروشگاه برای کسب و کارتون ایجاد میکنه مطمئن شد.
امتیاز فروشگاه کجا و چطور نمایش داده میشه؟
امتیاز فروشگاه، تجربه مشتری فروشگاه شما رو در تبلیغات و فرمتهای غیرپولی نشون میده و ممکنه روی موبایل و وب در سراسر شبکه جستجو و یوتیوب نمایش داده بشه. امتیاز فروشگاه میتونه شامل این موارد باشه:
امتیاز از ۵ ستاره
تعداد نظراتی که کسب و کار دریافت کرده
یه توضیح کوتاه، مثلن متوسط زمان تحویل، که نشون میده چرا این امتیاز رو گرفتید (اگه دادههاش موجود باشه)
یه لینک برای خوندن نظرات جدید
فرمتهای غیرپولی
نتایج غنی (Rich results): وقتی مشتریها در گوگل خرید میکنن، امتیاز فروشگاه ممکنه کنار نتایج جستجوی مربوط به یه فروشنده خاص ظاهر بشه و امتیاز ستارهای و تعداد نظرات رو نمایش بده.
لیستینگهای رایگان (Free listings): وقتی خریداران با یه لیستینگ رایگان محصول در جستجو یا خرید (Shopping) روبرو میشن، امتیاز کنار اسم فروشنده نمایش داده میشه. این به خریداران کمک میکنه به کسب و کارهایی که میخوان ازشون خرید کنن، اعتماد کنن.
تبلیغات (Ads)
امتیاز فروشگاه کنار تبلیغات شما نمایش داده میشه و به مردم میگه کدوم تبلیغکنندهها برای خدمات با کیفیت، امتیاز بالایی دارن. برای نمایش امتیاز فروشگاه در تبلیغات، امتیاز ۳.۵ یا بالاتر لازمه.
چطور گزارش عملکرد امتیاز فروشگاه رو در گوگل ادز ببینیم؟
اگه میخواید عملکرد تبلیغاتتون با امتیاز فروشگاه رو بررسی کنید، مثلن تعداد کلیکها یا نمایشهایی که با امتیاز اتفاق افتاده، میتونید دادههای عملکرد رو در گزارش داراییهای خودکار در سطح حساب کاربری (account level automated assets report) ببینید. برای دسترسی به این گزارش در بخش «Assets» گوگل ادز، این مراحل رو دنبال کنید:
در حساب گوگل ادز خودتون، روی آیکون کمپینها کلیک کنید.
از منوی بخش، روی منوی کشویی Assets کلیک کنید.
روی Assets کلیک کنید.
روی Add filter کلیک کنید و بر اساس «Source» فیلتر کنید.
تیک کنار «Automatically created» رو بزنید و روی Apply کلیک کنید.
برای امتیازهای فروشنده و موارد دیگه، از منوی سهنقطه در سمت راست جدول، Account level automated assets رو انتخاب کنید.
چطور میشه امتیاز فروشگاه گرفت؟
گوگل امتیازهای فروشگاه رو از وبسایتهای معتبر جمعآوریکننده نظرات و همینطور از کاربران گوگل میگیره. این امتیازها بیشتر تجربه کلی مشتری بعد از دریافت محصول رو در هر کشور منعکس میکنن. وقتی در یه کشور خاص امتیاز فروشگاه داشته باشید، به طور پیشفرض روی تبلیغات و لیستینگهای شما ظاهر میشه. اگه برای فروشگاهتون نظر یا امتیازی ندارید، میتونید با هر کدوم از سرویسهای زیر شروع کنید:
نظرات مشتریان گوگل (Google Customer Reviews): یه برنامه رایگان که از طرف فروشندهها نظرات بعد از تحویل رو جمعآوری میکنه و در گوگل مرچنت سنتر (Google Merchant Center) مدیریت میشه.
شرکای نقد و بررسی پشتیبانیشده: گوگل با شرکای نقد و بررسی کار میکنه. برای اینکه امتیازتون در گوگل نشون داده بشه، باید با یکی از اونها کار کنید.
ارزیابی توسط گوگل یا شرکای ارزیاب دیگه: این برنامهها کیفیت تجربه خرید ارائه شده توسط خردهفروشان آنلاین رو اندازهگیری و تحلیل میکنن. گوگل دادههای مربوط به فروشندههای منتخب و تجربه خریدی که ارائه میدن رو از طریق جستجوی گوگل و تحقیقاتی که خودش انجام میده، جمعآوری میکنه. برای اینکه گوگل راحتتر بتونه دادهها رو جمع کنه، حتمن در گوگل مرچنت سنتر ثبتنام کنید.
این امتیازها از کجا میان؟
گوگل امتیازهای فروشگاه موجود رو تغییر نمیده. برای ارائه امتیازهای یکسان، ما امتیازها رو کالیبره میکنیم و مواردی که به نظرمون غیرقابل اعتماد هستن (مثلن اسپم و سوءاستفاده) یا مشکوک هستن (مثلن نظراتی که نشون نمیدن معاملهای انجام شده) رو فیلتر میکنیم. گوگل امتیازهای فروشگاه رو بر اساس منابع مختلفی تعیین میکنه، از جمله:
نظرات مشتریان گوگل: یه برنامه رایگان که نظرات بعد از تحویل رو از طرف فروشندهها جمعآوری میکنه.
نظرات خرید برای دامنه فروشگاه شما: که شامل نظرات بعد از تحویل از شرکای مختلف پشتیبانیشده و همچنین کاربران جستجوی گوگل میشه.
معیارهای عملکرد جمعآوریشده از تحقیقات خرید تحت رهبری گوگل.
شرکای نقد و بررسی پشتیبانیشده
گوگل همچنین از وبسایتهای نقد و بررسی مستقل زیر بازخورد میگیره:
Ausgezeichnet.org
Bazaarvoice
Birdeye
Bizrate Insights
eKomi
Feedaty
Feedback Company
Feefo
KiyOh
Klantenvertellen
Okendo
PowerReviews
ProductReview.com.au
RA Trustvox
Reco.se
Reputation.com
ResellerRatings
Reviews.io
Reevoo
Shopper Approved
ShopVote.de
ShopAuskunft
Sitejabber
Stamped.io
Trusted Shops
TrustPilot
TurnTo
Verified Reviews
Yotpo
نکته: به طور معمول، سالانه فقط ۱ یا ۲ شریک جدید در سطح جهانی اضافه میشن.
چطور بفهمیم امتیاز فروشگاه داریم؟
برای اینکه بفهمید امتیاز فروشگاه دارید یا نه، آدرس زیر رو ویرایش کنید و به جای {yourwebsite} آدرس صفحه اصلی وبسایت خودتون رو قرار بدید:
اگه سایت شما حداقلهای لازم برای امتیاز فروشگاه رو داشته باشه، میتونید اطلاعات مربوط به فروشگاه و امتیازاتتون رو ببینید. اگه دامنه وبسایت شما برای هر کشور متفاوته، این کار رو برای هر نسخه تکرار کنید. اگه سایت شما از یه دامنه در کشورهای مختلف استفاده میکنه و در چند کشور نظر داره، لینک بالا صفحهای برای یک کشور رو برمیگردونه. میتونید کد کشور رو در آدرس مرورگر ویرایش کنید تا کشورهای دیگه رو ببینید. مثلن اگه آدرس شامل «c=AU» بود، میتونید اون رو به «c=US» تغییر بدید تا امتیازهای مربوط به آمریکا رو ببینید.
اگه مشکلی با امتیازها پیش اومد چیکار کنیم؟
امتیازهای نادرست:
اگه امتیازهایی پیدا کردید که به نظرتون نادرست هستن، باید با سایتی که میزبان اون نظراته تماس بگیرید تا موضوع رو حل کنید. شما نمیتونید از طریق مرچنت سنتر به نظرات فردی پاسخ بدید. برای پاسخ به یه نظر، باید به وبسایت امتیازدهی فروشگاه برید و اونجا پاسخ بدید. در حال حاضر، گوگل پاسخهای فروشندهها به نظرات فروشگاه رو نمایش نمیده.
امتیازهای من نمایش داده نمیشن:
نظرات به صورت آنی اضافه نمیشن، بنابراین ممکنه بین دریافت یه نظر جدید و اضافهشدنش به امتیاز شما، تاخیر وجود داشته باشه. همین قضیه برای حذف یه نظر از وبسایت امتیازدهی هم صادقه. اگه نظرات شما نمایش داده نمیشن:
برای لیستینگهای رایگان و تبلیغات خرید، مطمئن بشید که اسم فروشگاه و دامنه در نظرات شما با اسم فروشگاه و دامنه ثبتشده در حساب گوگل مرچنت سنترتون مطابقت داره.
برای تبلیغات متنی، دامنه URL قابل مشاهده تبلیغ باید با دامنهای که براش امتیاز داریم، یکی باشه.
برای اینکه امتیازها در یه کشور خاص نمایش داده بشن، کسب و کار شما باید به اندازه کافی نظر منحصر به فرد در اون کشور در ۲۴ ماه گذشته داشته باشه تا گوگل بتونه با اطمینان امتیاز فروشگاه رو محاسبه کنه. تعداد نظرات مورد نیاز برای هر فروشنده متفاوته، اما بیشتر فروشندهها بعد از جمعآوری ۱۰۰ نظر واجد شرایط یا بیشتر، امتیاز میگیرن.
برای تبلیغات، علاوه بر این، باید امتیاز ترکیبی متوسط ۳.۵ ستاره یا بیشتر داشته باشید.
پنل دیدگاههای فروشگاه (Store insights panel)
علاوه بر امتیاز فروشگاه، خریداران الان میتونن پنل دیدگاههای فروشگاه رو با اطلاعات بیشتری در مورد فروشگاه شما ببینن. این پنل میتونه شامل معیارهایی مثل حمل و نقل، بازگشت کالا، قیمتگذاری رقابتی و گزینههای پرداخت باشه. این معیارها امتیاز فعلی شما رو از کارت امتیازی کیفیت فروشگاه (Store Quality Scorecard) نشون میدن و به خریداران کمک میکنن تا موقع مرور فروشگاه شما، تصمیمات آگاهانهتری بگیرن. نبود امتیاز فروشگاه در کارت امتیازی تجربه خرید، میتونه نشوندهنده تعداد کم نظرات باشه.
منابع
[1] Google Adds AI Summaries of Business Reviews to Chrome URL Displays | Social Media Today
این جریان حدودا از ۲۶ تا ۲۹ می ۲۰۲۵ (اواخر اردیبهشت ۱۴۰۴) شروع شد و با یک جستجوی ساده معلوم شد که کلی وبمستر دیگه هم دقیقا همین مشکل رو گزارش کردن. این اتفاق برای سایتهای مختلف با موضوعات متفاوت افتاده، که نشون میده یک تغییری توی رفتار ایندکس کردن گوگل به وجود اومده.
صاحبای سایتها اولین بار توی هفته آخر ماه می ۲۰۲۵ متوجه این موضوع شدن. تا اوایل ماه ژوئن، انجمنهای سئو و شبکههای اجتماعی پر از گزارشهای مشابه شد. نمودارهای زیادی توی سرچ کنسول گوگل یک نقطه اوج شدید رو در تاریخ ۲۷ می ۲۰۲۵ نشون میدن، جایی که تعداد صفحههای حذف شده، مخصوصا اونایی که برچسب «بررسی شده – در حال حاضر ایندکس نشده» داشتن، به شدت بالا رفت.
دلایل احتمالی این اتفاق چی بوده؟
سوال بزرگ اینه که چرا این همه صفحه، از این همه سایت، یک دفعه از نظر گوگل برای ایندکس شدن بیارزش شدن. چون گوگل چیزی رو رسما تایید نکرده، چندتا نظریه به وجود اومده:
آپدیت الگوریتمی (تایید نشده)
خیلی از متخصصای سئو فکر میکنن که گوگل بیسر و صدا یک آپدیت یا تغییری مربوط به ایندکس کردن رو اجرا کرده. گوگل همیشه در حال دستکاری الگوریتمهاشه و به نظر میرسه این یک تغییر اعلام نشده بوده که روی ایندکس تمرکز داشته. زمانبندی دقیق این اتفاق نشون میده که تصادفی نبوده. بعضیها بهش میگن «آپدیت هرس کردن ایندکس»، یعنی گوگل استانداردهاش رو برای اینکه چه صفحههایی رو توی ایندکس نگه داره، بالاتر برده.
بری شوارتز از سایت Search Engine Roundtable هم اشاره کرده که از اواخر ماه می، شکایتهای زیادی در مورد اینکه گوگل صفحههای کمتری رو ایندکس میکنه، دیده. سوال اینه که آیا این یک آپدیت الگوریتمی عمدی برای هدف قرار دادن محتوای بیکیفیت بوده یا یک تغییر توی فرایندهای داخلی ایندکس گوگل. با توجه به سکوت گوگل، این اتفاق به عنوان یک آپدیت «خاموش» در نظر گرفته میشه؛ یعنی در عمل تاثیر داشته اما از کانالهای رسمی تایید نشده.
پاکسازی بر اساس کیفیت محتوا
یک نظریه قوی اینه که گوگل داره با محتوای کمارزش یا تکراری توی ایندکسش برخورد میکنه. متخصص سئو، ماری هینز، سایتهای آسیبدیده رو تحلیل کرده و یک الگوی مشترک پیدا کرده: صفحههایی که حذف شدن معمولا محتوای سطحی، غیر اورجینال یا کمارزش داشتن.
برای مثال:
توی یک سایت مسافرتی، خیلی از پستهای وبلاگ قدیمی که فقط اطلاعات سایتهای دیگه رو بازنویسی کرده بودن (یعنی محتوای پارافریز شده)، از ایندکس حذف شدن.
توی یک سایت دیگه (وبلاگ آشپزی)، پستهای پرسش و پاسخ ساده مثل «فرق بین X و Y چیه؟» حذف شدن؛ اینها سوالهای سادهای هستن که هوش مصنوعی خود گوگل (یا سایتهای دیگه) به راحتی میتونن بهشون جواب بدن.
یک سایت وکالت دید که مقالههای سطحی و «پُرکننده برای سئو» (مثلا نکات ایمنی کلی که هیچ دیدگاه جدیدی اضافه نمیکردن) حذف شدن.
این نشون میده که الگوریتمهای گوگل احتمالا کیفیت و اصالت محتوا رو در مقیاس بزرگ دوباره ارزیابی کردن و صفحههایی که به یک آستانه مشخصی از مفید بودن نمیرسیدن رو حذف کردن. جالبه بدونید که گوگل توی آخرین آپدیت راهنمای ارزیابهای کیفیتش، کلمه «پارافریز شده» رو ۲۲ بار اضافه کرده و روی محتوای اورجینال تاکید کرده.
تغییرات در بودجه خزش یا ظرفیت ایندکس
یک زاویه دید دیگه اینه که گوگل ممکنه در حال تنظیم بودجه خزش یا ایندکسش باشه، مخصوصا برای سایتهای بزرگ. گوگل هر صفحهای رو که بررسی میکنه، ایندکس نمیکنه؛ اون صفحههایی رو در اولویت قرار میده که مهمتر یا مفیدتر تشخیص داده بشن. برای وبسایتهای خیلی بزرگ (مثلا با میلیونها صفحه)، گوگل ممکنه تصمیم گرفته باشه که درصد کمتری از صفحهها رو ایندکس کنه تا از چیزی که بهش میگن «ورم ایندکس» جلوگیری کنه.
یک کاربر توییتر از Consainsights اشاره کرد که حتی «وبسایتهای تجاری فعال با محتوای خوب» هم در تاریخ ۲۷ تا ۲۹ می شاهد حذف شدن صفحههاشون بودن. این نشون میده که فقط صفحههای «به دردنخور» حذف نشدن؛ ممکنه صفحههایی هم که خوب بودن ولی حیاتی نبودن، حذف شده باشن. اگه سیستمهای گوگل نحوه تخصیص ایندکس به صفحههای یک سایت رو دوباره تنظیم کرده باشن، ممکنه بعضی از صفحههای کمبازدید حذف شده باشن.
پورتالهای املاک یک مثال عالی هستن. اونها تعداد خیلی زیادی صفحه دارن (لیست املاک، پروفایل مشاوران و غیره) که خیلیهاشون شبیه به هم یا موقتی هستن (مثلا آگهیهای منقضی شده). این احتمال وجود داره که گوگل بیسر و صدا تصمیم گرفته باشه روی چنین سایتهایی گزیدهتر عمل کنه (مثلا جدیدترین یا مرتبطترین آگهیها رو ایندکس کنه و قدیمیها یا تکراریها رو حذف کنه) تا منابعش رو مدیریت کنه. البته بدون تایید رسمی، معلوم نیست که آیا بودجه خزش به طور مشخص نقشی داشته یا این فقط یک اثر جانبی ارزیابی کیفیته (چون صفحههای کمارزش معمولا اولویت خزش پایینی هم دارن).
هوش مصنوعی مولد گوگل و تغییرات جستجو
تعداد کمی از افراد در جامعه سئو حدس میزنن که این موضوع میتونه به حرکت گوگل به سمت جوابهای تولید شده توسط هوش مصنوعی (SGE – Search Generative Experience) مرتبط باشه. منطقشون اینه که اگه هوش مصنوعی گوگل بتونه به بعضی سوالها مستقیم جواب بده، ممکنه دیگه نیازی به ایندکس کردن صفحههایی که اون جوابها رو دارن، نبینه. برای مثال، صفحههای تعاریف ساده یا سوالات متداول، اگه جوابشون توی خلاصههای هوش مصنوعی بیاد، میتونن اضافی به حساب بیان.
این نظریه بیشتر بر اساس حدس و گمانه، اما با این مشاهده که خیلی از صفحههای حذف شده اطلاعات خیلی پایهای ارائه میدادن، همخونی داره. گوگل ممکنه پیشبینی کرده باشه که در آینده جستجوی با کمک هوش مصنوعی، کلیک کمتری روی اینجور محتواها میشه و برای همین داره اونها رو پاکسازی میکنه. با این حال، گوگل به طور واضح ارتباطی بین SGE و رفتار ایندکس کردن اعلام نکرده، پس این رو فقط یک فرضیه در نظر بگیرید.
پاسخ گوگل: «همه چیز طبق برنامه کار میکنه»
با وجود همه این صحبتها، گوگل هیچ بیانیه رسمی یا پست وبلاگی در مورد این تغییر ایندکس منتشر نکرده. رابط جستجوی گوگل و کانالهای عمومی اون ساکت موندن، که نشون میده اونها این رو یک نوسان عادی میدونن. نزدیکترین چیز به یک پاسخ رسمی از طرف جان مولر در اوایل ژوئن اومد:
جان مولر در بلواسکای: جان در تاریخ ۵ ژوئن به نگرانیهای متخصصان سئو در بلواسکای جواب داد. وقتی ازش در مورد حذف میلیونها صفحه توسط گوگل پرسیده شد، اول درخواست جزئیات کرد: «کدوم میلیونها صفحه؟ خوشحال میشم جزئیات دقیقتری بشنوم.»
بعد از اینکه چندتا مثال بهش داده شد، اونها رو تحلیل کرد و گزارش داد: «بر اساس این مثالها، من مشکل فنیای از سمت ما (یا از سمت هیچکدوم از این سایتها) نمیبینم. سیستمهای ما به طور مرتب تغییراتی توی چیزهایی که بررسی و ایندکس میشن ایجاد میکنن. این طبیعی و قابل انتظاره.»
در یک پیام دیگه اضافه کرد: «با نگاه کردن به بقیه مثالها، من مشکلی نمیبینم. ما همه محتواها رو ایندکس نمیکنیم، و چیزهایی که ایندکس میکنیم ممکنه با گذشت زمان تغییر کنه.»
این صحبتها نشون میده که گوگل این اتفاق رو یک باگ یا خطا که نیاز به اصلاح داشته باشه نمیبینه، بلکه نتیجه رفتار عادی الگوریتمهاش میدونه.
همچنین، بد نیست به یک نکتهای که اخیرا مارتین اسپلیت (از توسعهدهندههای گوگل) گفته هم توجه کنیم. هرچند مستقیما در مورد این اتفاق ماه می ۲۰۲۵ نبوده، اما به درک موضوع کمک میکنه. اسپلیت توضیح داد که چرا بعضی صفحهها بعد از اینکه یک بار ایندکس شدن، از ایندکس خارج میشن:
«این یعنی ما فکر میکردیم ممکنه خوب باشن، اما متوجه شدیم که کاربرها واقعا از اونها توی نتایج جستجو استفاده نمیکنن. برای همین فکر کردیم که، خب، بهش یک فرصت دادیم ولی… بقیه دارن بهتر عمل میکنن.»
مشاهدات شخصی من
من چندتا از سایتهایی که مدیریت میکنم، هم سایتهای خودم و هم مشتریها، رو تحلیل کردم تا الگوهایی رو پیدا کنم که فقط داستان نباشن و به طور مداوم تکرار بشن. این چیزها بیشتر به چشم اومد:
این اتفاق به طور نامتناسبی روی وبسایتهای بزرگتر تاثیر گذاشته. روی سایتهای کوچیک (کمتر از ۱۰ هزار صفحه)، تغییر خیلی کمی در ایندکس دیدم یا اصلا ندیدم. اما روی پورتالهای بزرگتر، مخصوصا اونهایی که بیشتر از ۵۰ هزار آدرس اینترنتی (URL) داشتن، کاهش تعداد صفحههای ایندکس شده خیلی محسوس بود.
گوگل در اواخر آوریل (اوایل اردیبهشت ۱۴۰۴) سرعت خزش (بررسی سایت) رو زیاد کرد. تقریبا روی همه دامنههایی که تحت تاثیر قرار گرفتن، یک جهش قابل توجه در خزش در انتهای آوریل ۲۰۲۵ وجود داشت. انگار گوگل داشت آماده میشد تا کل ساختار سایت رو دوباره ارزیابی کنه، احتمالا برای سنجش دوباره کیفیت محتوای کل سایت. چند هفته بعد، صفحهها شروع به حذف شدن از ایندکس کردن.
لینکسازی داخلی دیگه صفحههای ضعیف رو نجات نمیده. قبلا، یک استراتژی لینکسازی داخلی قوی میتونست اهمیت صفحههای کمارزشتر رو بالا ببره. اما این بار نه. من صفحههایی رو دیدم که دهها لینک داخلی داشتن اما چون خود محتوا به یک آستانه کیفیتی نمیرسید، باز هم از ایندکس خارج شدن. به نظر میرسه گوگل سیگنالهایی مثل اعتبار لینک رو نادیده میگیره اگه محتوا حرفی برای گفتن نداشته باشه.
«محتوای سطحی» فقط به تعداد کلمات مربوط نیست، به عمق هم ربط داره. روی یکی از سایتهای دایرکتوری خودم، یک الگوی خیلی واضح دیدم: صفحههایی که فقط ۱ یا ۲ تا لیست داشتن از ایندکس حذف شدن، با اینکه قالبشون تمیز، ساختاریافته و دارای لینک داخلی بود. انگار گوگل یک آستانه کیفی تعیین کرده؛ اگه صفحه اینقدر خلوت باشه، ارزش واقعی برای کاربر نداره. صفحههایی که ۴ تا یا بیشتر لیست داشتن، توی ایندکس باقی موندن.
به نظر یک پاکسازی عمدی ایندکس میاد. حس میشه که گوگل یک تصمیم آگاهانه گرفته تا «ورم ایندکس» رو کاهش بده، احتمالا برای بهبود کیفیت نتایج جستجو و آماده شدن برای نتایج تولید شده توسط هوش مصنوعی که در اون تکرار و افزونگی هزینه بیشتری داره. چیزی که الان در ایندکس باقی مونده به نظر میرسه صفحههایی باشن که ارزش واضح، اعتبار، یا حداقل یک آستانه حداقلی از مفید بودن رو دارن.
چطور صفحههامون رو دوباره به ایندکس برگردونیم؟ (راهحلهای عملی)
بهبود کیفیت و منحصر به فرد بودن محتوا
بهترین توصیه اینه که محتوای صفحههای حذف شده رو بررسی و بهتر کنید. اگه گوگل اونها رو به خاطر کیفیت پایین یا تکراری بودن حذف کرده، تنها راه حل دائمی اینه که اون صفحهها رو بهتر و منحصر به فردتر کنید. صفحههای حذف شده رو بازبینی و با محتوای مفیدتر گسترش بدید. این میتونه شامل اضافه کردن مثالهای عملی، آپدیت با آخرین آمار و ارقام، اضافه کردن تحلیلها یا دیدگاههای اورجینال و غیره باشه. هدف اینه که یک صفحه متوسط رو به صفحهای تبدیل کنید که یک کاربر (یا الگوریتم گوگل) اون رو شایسته خوندن بدونه.
محتوا رو واقعا اورجینال کنید
اگه صفحه شما همون حرفی رو میزده که بقیه میزنن، یک راهی پیدا کنید که حرف متفاوتی بزنه. این کار میتونه شامل انجام تحقیقات شخصی (حتی نظرسنجیها یا آزمایشهای کوچیک)، استفاده از محتوای تولید شده توسط کاربرها، یا ارائه یک نظر منحصر به فرد باشه. راهنمای محتوای مفید گوگل روی «تجربه» و «تخصص» تاکید داره؛ یعنی دانش دست اول، دیدگاههای معتبر و غیره.
به فاکتورهای E-E-A-T توجه کنید
الان وقت خوبیه که اسم نویسنده (با ذکر اعتبار و تخصصش)، منابع معتبر، و اطمینان از صحت اطلاعات محتوا رو اضافه کنید. این قدمها به تنهایی باعث نمیشن گوگل یک صفحه رو ایندکس کنه، اما میتونن کیفیت درک شده از صفحه رو بهبود بدن.
سایتمپها رو بازبینی کنید
مطمئن بشید که سایتمپ XML شما با تمام صفحههایی که میخواید ایندکس بشن، بهروز باشه. هرچند گوگل میگه برای صفحههای «بررسی شده، اما ایندکس نشده» نیازی به سایتمپ یا ارسال مجدد نیست، اما بودنشون در سایتمپ ضرری نداره.
بکلینک (خارجی) بسازید یا جذب کنید
با اینکه نمیشه یک شبه بکلینک به دست آورد، اما بررسی پروفایل بکلینک صفحههای حذف شده جالبه. در خیلی از موارد، اون صفحهها هیچ لینک خارجیای نداشتن. این یک سرنخه: شاید گرفتن چندتا بکلینک بتونه به ایندکس شدن مجددشون کمک کنه. اگه صفحههایی دارید که حذف شدن اما میدونید کیفیت بالایی دارن یا بهبودشون دادید، فعالانه اونها رو تبلیغ کنید.
از محتوای جدید استفاده کنید
یک استراتژی دیگه اینه که محتوای حذف شده رو توی یک محتوای جدید که گوگل به زودی بررسی میکنه، ذکر کنید و بهش لینک بدید. برای مثال، اگه یک پست وبلاگ جدید منتشر میکنید، میتونید به مقاله قدیمی لینک بدید. این بررسی جدید ممکنه باعث بشه ربات گوگل صفحه قدیمی رو دوباره ارزیابی کنه.
حذف یا ادغام محتوا رو در نظر بگیرید
گاهی بهترین راه اینه که از بعضی صفحهها دل بکنید. اگه بعد از بازبینی به این نتیجه رسیدید که یک صفحه واقعا هدف منحصر به فردی نداره، میتونید اون رو با یک صفحه دیگه ادغام کنید، به صفحه دیگهای ریدایرکت ۳۰۱ کنید، یا بذارید همونطور خارج از ایندکس بمونه.
صبور باشید و نظارت کنید
بعد از انجام کارهای بالا، باید کمی صبر کنید و ببینید چی میشه. بعضی صفحهها ممکنه به مرور زمان خود به خود به ایندکس برگردن. در همین حال، گزارش Pages در سرچ کنسول گوگل رو هفتگی یا ماهانه چک کنید. از ابزار URL Inspection در سرچ کنسول هم برای آدرسهای خاص استفاده کنید. این ابزار میتونه به شما بگه آخرین باری که گوگل صفحه رو بررسی کرده کی بوده و آیا الان اون رو ایندکس شده میبینه یا نه.
نگاه به آینده
جالب خواهد بود که ببینیم آیا گوگل یا نمایندههاش توضیح بیشتری میدن یا نه. گاهی اوقات، اگه تعداد زیادی از وبمسترها گیج بشن، گوگل ممکنه یک یادداشت در مستنداتش اضافه کنه یا در یک جلسه پرسش و پاسخ به اون بپردازه. اما با توجه به موضع جان مولر، اونها احتمالا این رو فقط یک روال عادی کاری میدونن.
به عنوان یک فکر نهایی، این جمله (که از راهنماییهای گوگل و صحبتهای مارتین اسپلیت برداشت شده) رو در نظر بگیرید: «گوگل کل وب رو ایندکس نمیکنه، و نباید هم بکنه. گوگل سعی میکنه بهترینهای وب رو ایندکس کنه.» اگه مطمئن بشید که صفحههای شما جزو «بهترینها» در موضوع خودشون هستن – یعنی منحصر به فرد، مفید و مرتبط – شانس ایندکس شدن و ماندگاریشون در نتایج جستجو رو خیلی بالا میبرید.
منابع
[1] Why Your Pages Are “Crawled – Not Indexed” After May 2025
اهداف درس: توی این درس قراره بفهمیم گوگل چطوری به CSS نگاه میکنه، چه چیزایی براش مهمه و چه چیزایی نه، و یاد بگیریم از چه کارهایی تو CSS باید دوری کنیم تا به سئو لطمه نزنه. تمام حرفهایی که اینجا میخونیم بر اساس گفتههای رسمی خود گوگل یا کارمندهای ارشدش مثل جان مولر، مت کاتس و مارتین اسپلیت هست.
فصل اول: چرا اصلا CSS برای گوگل مهمه؟
شاید فکر کنی CSS فقط برای خوشگل کردن سایته و ربطی به سئو نداره، اما قضیه یکم پیچیدهتره. بذار از اینجا شروع کنیم: گوگل همیشه گفته میخواد صفحات وب رو همونطوری ببینه و بفهمه که یک کاربر عادی میبینه. برای همین، فقط به کدهای HTML شما نگاه نمیکنه. گوگل نیاز داره فایلهای CSS و جاوا اسکریپت شما رو هم بخونه (یا به اصطلاح فنیتر، کراول کنه) تا بتونه صفحه رو به درستی «رندر» کنه. رندر کردن یعنی کنار هم گذاشتن HTML، CSS و جاوا اسکریپت برای ساختن نسخه بصری صفحه.
گوگل رسما توی راهنماهای خودش به وبمسترها توصیه کرده که اجازه دسترسی رباتش به فایلهای CSS و JS رو بدن. این موضوع از سال ۲۰۱۴ به بعد خیلی جدیتر هم شد. اگر گوگل نتونه فایلهای CSS سایت شما رو ببینه، نمیتونه صفحه رو درست رندر کنه و این قضیه میتونه روی رتبه بندی شما تاثیر منفی بذاره. چرا؟ چون ممکنه گوگل فکر کنه سایت شما برای کاربرا خراب نشون داده میشه یا اصلا محتوای اصلی رو تشخیص نده.
یک اصل کلی هم وجود داره که گوگل روش تاکید میکنه:
HTML برای محتوا و ساختاره.
CSS برای ظاهر و استایله.
مخلوط کردن این دوتا، مخصوصا قرار دادن محتوای مهم داخل CSS، میتونه درک موتور جستجو از سایت شما رو دچار مشکل کنه.
فصل دوم: کراول کردن فایلهای CSS
خب، حالا که فهمیدیم گوگل باید CSS رو ببینه، سوال اینه که چطوری این اجازه رو بهش بدیم و از چه کارهایی دوری کنیم.
فایلهای CSS و JS رو توی robots.txt بلاک نکنید
خیلی مهمه که توی فایل robots.txt سایتتون، دسترسی گوگل به فایلهای CSS و جاوا اسکریپت رو مسدود نکرده باشید. اگه این کار رو بکنید، ممکنه توی گوگل سرچ کنسول با ارورهایی مواجه بشید که بهتون میگه گوگل نمیتونه صفحه رو کامل رندر کنه.
یه نکته جالب از یکی از گفتگوهای قدیمی تو فروم Moz اینه که ربات گوگل فایلهای CSS یا JS رو «ایندکس» نمیکنه. یعنی این فایلها رو توی نتایج جستجو نشون نمیده (مثل فایلهای PDF یا صفحات HTML). گوگل فقط اونها رو «کراول» میکنه تا برای رندر کردن صفحه ازشون استفاده کنه.
پس اگه نگران ایندکس شدن این فایلها هستید، راه حل بلاک کردن اونها نیست. به جای این کار، میشه از تگ X-Robots-Tag: "noindex" توی هدر HTTP سرور استفاده کرد. اینطوری به گوگل میگید فایل رو کراول کن ولی ایندکسش نکن.
ترکیب Disallow با noindex
شاید فکر کنید میشه یک صفحه رو هم با Disallow توی robots.txt بلاک کرد و هم تگ meta noindex رو داخلش گذاشت. این کار ممکن نیست، چون Disallow جلوی کراول شدن صفحه رو میگیره و گوگل هیچوقت اون تگ meta noindex رو نمیبینه.
یه راه دیگه اضافه کردن دستور noindex به خود فایل robots.txt هست. اما جان مولر از گوگل گفته که «نباید روی این روش حساب کنید»، چون روش قابل اعتمادی نیست. پس بهتره ازش دوری کنید.
فصل سوم: معمای «متن مخفی»
این یکی از داغترین بحثهای سئو و CSS هست. خیلی از توسعهدهندهها برای تکنیکهایی مثل جایگزینی تصویر (Image Replacement) یا لینکهای کمکی برای افراد کمتوان، از CSS برای مخفی کردن متن استفاده میکنن. سوال اینه که گوگل این کار رو اسپم حساب میکنه یا نه؟
مت کاتس، که سالها یکی از چهرههای اصلی تیم اسپم گوگل بود، چندتا جمله کلیدی در این مورد داره:
«من توصیه نمیکنم که مردم از CSS برای مخفی کردن متن استفاده کنن.»
این جمله اولش خیلی نگران کننده به نظر میرسه. اما خودش در ادامه توضیح میده که قضیه به «نیت» شما بستگی داره. اون میگه:
«اگه دارید صاف و پوستکنده از CSS برای مخفی کردن متن استفاده میکنید، تعجب نکنید اگه بهش بگن اسپم… اگه اسم شرکتتون رو به جای لوگو به صورت متنی میذارید و مخفیش میکنید، مشکلی نیست. اما اگه متنی که مخفی میکنید یه چیزی مثل «خرید آنلاین تخفیف ویژه فروش ارزان» باشه، اون موقع من بیشتر احتیاط میکنم، چون این کار میتونه بد به نظر برسه.»
پس اصل ماجرا اینه: محتوایی که مخفی میکنید چیه؟ اگه دارید یه متن توصیفی کوتاه برای یک لوگو مخفی میکنید، این کار معمولا مشکلی نداره. اما اگه دارید یک پاراگراف پر از کلمات کلیدی رو مخفی میکنید تا کاربر نبینه ولی گوگل ببینه، این کار به شدت خطرناکه و میتونه اسپم شناخته بشه.
مت کاتس یه نکته دیگه هم گفته:
«ما در گوگل میتونیم متنی که به نظر میرسه با CSS مخفی شده رو پرچمگذاری (flag) کنیم. تا به امروز، ما سایتها رو به صورت الگوریتمی برای این کار حذف نکردیم.»
این یعنی در اون زمان، حذف سایت برای این موضوع نیاز به بررسی دستی داشته، اما این قابلیت وجود داره که الگوریتمها این موارد رو شناسایی کنن.
تکنیکهای رایج مخفیسازی و نظر گوگل
display: none;: جان مولر و مارتین اسپلیت توی یکی از گفتگوهاشون تایید کردن که وقتی از display: none; استفاده میکنید، اون عنصر به طور موثر از چیدمان بصری و معمولا از DOM رندر شده برای موتورهای جستجو هم حذف میشه. یعنی گوگل هم اون محتوا رو نمیبینه و ایندکسش نمیکنه. این تکنیک برای مخفی کردن محتوا از گوگل کاملا موثره، ولی اگه محتوای مهمی داخلش باشه، به ضرر سئو شماست.
text-indent: -9999px;: این روش متن رو از صفحه نمایش به بیرون هل میده. گوگل کاملا با این تکنیک آشناست و اگه برای مقاصد اسپم (مثل مخفی کردن کلمات کلیدی) استفاده بشه، میتونه جریمه به همراه داشته باشه.
رنگ متن و پسزمینه یکسان: این هم یکی از قدیمیترین ترفندهاست که گوگل به راحتی تشخیصش میده.
فصل چهارم: تاثیر پراپرتیهای خاص CSS روی سئو (از زبان گوگل)
حالا بیایم سراغ چندتا پراپرتی و تکنیک خاص توی CSS و ببینیم نظر رسمی تیم گوگل در موردشون چیه. این اطلاعات مستقیما از گفتگوی جان مولر و مارتین اسپلیت به دست اومده.
اسم کلاسهای CSS (CSS Class Names) اسمهایی که برای کلاسهای CSS انتخاب میکنید، هیچ تاثیر مستقیمی روی سئو ندارن. گوگل اونها رو به عنوان بخشی از محتوای متنی قابل مشاهده در نظر نمیگیره و برای کلمات کلیدی یا رتبهبندی تحلیلشون نمیکنه. میتونید اسم کلاسهاتون رو هر چیزی بذارید.
قانون !important این دستور هم هیچ تاثیری روی سئو نداره. کارش فقط اینه که یک استایل خاص رو به زور اعمال کنه و ربطی به محتوا نداره.
عناصر مجازی (::before و ::after) این یکی خیلی مهمه. محتوایی که با ::before یا ::after به یک عنصر اضافه میکنید، توی Document Object Model (DOM) قرار نمیگیره و در نتیجه توسط سیستمهای رندرینگ و ایندکسینگ گوگل دیده نمیشه. پس هیچوقت از این عناصر مجازی برای اضافه کردن محتوای مهم و متنی که میخواید ایندکس بشه استفاده نکنید. مثلا اگه میخواید کنار کلماتتون علامت هشتگ بذارید، این علامت رو مستقیما توی HTML بنویسید، نه با ::before. این عناصر فقط برای مقاصد تزئینی (مثل آیکونها) هستن.
تصاویر در CSS در مقابل تگ <img> در HTML اینم یه نکته کلیدی دیگه است. تصاویری که با پراپرتی background-image توی CSS قرار میدید، برای عناصر تزئینی هستن و محتوای ضروری رو منتقل نمیکنن. این تصاویر توسط موتورهای جستجو به عنوان عکس ایندکس نمیشن. برای تصاویری که بخشی از محتوای اصلی صفحه هستن (مثل عکس محصول، نمودار، یا عکسهای یک مقاله خبری)، همیشه باید از تگهای HTML مثل <img> یا <picture> استفاده کنید. اینطوری عکسها بخشی از DOM میشن، میتونن توسط جستجوی تصاویر گوگل ایندکس بشن و گوگل میتونه با استفاده از متن اطراف و تگ alt محتواشون رو بفهمه.
واحدهای Viewport (مثلا 100vh) استفاده از واحدهایی مثل 100vh (صد در صد ارتفاع ویوپورت) برای عناصری مثل تصاویر هیرو (hero images) میتونه توی ابزارهای پیشنمایش رندر گوگل مشکل ایجاد کنه. ممکنه این عناصر بیش از حد بزرگ نشون داده بشن و محتوای اصلی رو از دید خارج کنن. اگرچه این موضوع احتمالا به طور مستقیم روی ایندکس شدن تاثیر نمیذاره (اگه محتوا هنوز توی DOM باشه)، اما میتونه نشونهای از یک مشکل دسترسیپذیری (accessibility) باشه و دیباگ کردن رو سخت کنه.
استفاده از CSS برای ساختن لیاوتهای جدولی اگه دادههای جدولی واقعی دارید (مثل جدول قیمت یا مشخصات)، استفاده از CSS برای ساختن چیزی شبیه جدول کار اشتباهیه. همیشه برای دادههای جدولی از تگهای HTML <table> استفاده کنید. این کار به موتورهای جستجو (و صفحهخوانها) اجازه میده سطرها و ستونها رو تشخیص بدن و اطلاعات ساختاریافته شما رو بهتر بفهمن و ایندکس کنن.
دلایل مختلفی که باعث قطعی اینترنت در یک منطقه یا کشور میشن چی هستن.
چطور اتفاقاتی مثل قطعی برق یا مشکلات سیاسی میتونن روی اینترنت تاثیر بذارن.
با نمونههای واقعی از قطعیهای اینترنت در کشورهای مختلف آشنا بشی.
این مقاله یک جورایی گزارش خلاصهای از قطعیها و اختلالات تایید شده در سه ماهه دوم سال ۲۰۲۵ هست و قرار نیست لیست کامل و جامعی از تمام مشکلات باشه. اگه کسی لیست کاملتری از ناهنجاریهای ترافیکی رو بخواد، میتونه به مرکز قطعیهای رادار کلادفلر سر بزنه. نکته دیگه اینکه توی این گزارش برای نشون دادن تاثیر قطعیها، هم از نمودارهای ترافیکی بر اساس «بایت» و هم بر اساس «درخواست» استفاده شده. اینکه کدوم نمودار انتخاب شده، بستگی به این داشته که کدوم یکی بهتر میتونسته تاثیر اختلال رو نشون بده.
جالبه بدونید که در گزارش سه ماهه اول سال ۲۰۲۵، هیچ قطعی اینترنتی که به دستور دولتها باشه، دیده نشده بود. اما متاسفانه این وضعیت خوب دوام نیاورد و در سه ماهه دوم سال ۲۰۲۵، شاهد قطعیهای دستوری در کشورهایی مثل لیبی، ایران، عراق، سوریه و پاناما بودیم. از طرفی، وابستگی شدید اینترنت به یک شبکه برق پایدار هم کاملا مشخص شد، مخصوصا وقتی یک قطعی برق عظیم در اسپانیا و پرتغال، ارتباط اینترنتی رو توی این دو کشور مختل کرد. در جاهای دیگه دنیا هم مشکلاتی بود؛ مثلا قطع شدن کابل فیبر نوری به شرکتهایی در هائیتی و مالاوی آسیب زد، مشکلات فنی باعث اختلال در ترافیک اینترنت شرکتهای بزرگ آمریکای شمالی شد و یک شرکت ارائهدهنده اینترنت در روسیه دوباره هدف یک حمله سایبری بزرگ قرار گرفت و شبکهاش از کار افتاد. متاسفانه، همیشه دلیل اصلی یک قطعی اینترنت به طور رسمی اعلام نمیشه و در این مدت، چندین قطعی بزرگ ولی بدون توضیح مشخص هم دیده شد.
فصل اول: قطعیهای اینترنت به دستور دولتها
این نوع قطعیها زمانی اتفاق میفتن که یک دولت به دلایل مختلف، عمدا تصمیم میگیره دسترسی به اینترنت رو محدود یا کاملا قطع کنه.
لیبی
در تاریخ ۱۶ می، اختلالات اینترنتی در چندین شرکت ارائهدهنده اینترنت در لیبی دیده شد. گزارشها میگفتن که این قطعی در واکنش به اعتراضات عمومی علیه «دولت وحدت ملی» بوده. از ساعت ۱۳:۳۰ به وقت جهانی (UTC) که میشد ۱۵:۳۰ به وقت محلی، ترافیک اینترنت در شرکتهایی مثل Libyan International Company for Technology (با شناسه شبکه AS329129)، Giga Communication (AS328539)، Aljeel Aljadeed for Technology (AS37284) و Awal Telecom (AS328733) بیشتر از ۵۰ درصد نسبت به هفته قبلش کاهش پیدا کرد. شرکت آخری یعنی Awal Telecom کلا قطع شد. این کاهش ترافیک تا حدود ساعت ۰۰:۰۰ به وقت جهانی (۰۲:۰۰ به وقت محلی) ادامه داشت و بعد از اون در عرض حدود یک ساعت، ترافیک به حالت عادی برگشت. شرکت Giga Communication (AS328539) یک قطعی دیگه هم در تاریخ ۱۷ می بین ساعتهای ۰۲:۰۰ تا ۱۱:۳۰ به وقت جهانی (۰۴:۰۰ تا ۱۳:۳۰ به وقت محلی) تجربه کرد.
ایران
در ماه ژوئن ۲۰۲۵ چندین مورد قطعی اینترنت در این کشور اتفاق افتاد. اولین مورد در تاریخ ۱۳ ژوئن بین ساعتهای ۰۷:۱۵ تا ۰۹:۴۵ به وقت جهانی (۱۰:۴۵ تا ۱۳:۱۵ به وقت محلی) بود. وزارت ارتباطات ایران با صدور بیانیهای این قطعی رو اعلام کرد: «با توجه به شرایط خاص کشور و بر اساس تدابیر اتخاذ شده توسط مراجع ذیصلاح، محدودیتهای موقتی در اینترنت کشور اعمال شده است. بدیهی است پس از بازگشت به شرایط عادی، این محدودیتها برطرف خواهند شد». این دستور قطعی، شرکتهای ارائهدهنده اینترنتی مثل فناپتلکام (AS24631)، رسانا (AS205647 و AS31549)، همراه اول (MCCI با شناسه AS197207)، مخابرات ایران (TCI با شناسه AS58224) و شرکتهای دیگه رو تحت تاثیر قرار داد.
در تاریخ ۱۷ ژوئن، دوباره دسترسی به اینترنت محدود شد. این بار به گفته یک سخنگوی دولت، برای «جلوگیری از حملات سایبری» بود. این دور دوم قطعیها از ساعت ۱۷:۳۰ به وقت محلی (۱۴:۰۰ به وقت جهانی) شروع شد و شبکههای زیادی رو درگیر کرد. ترافیک در ساعت ۱۵:۳۰ به وقت جهانی (۱۹:۰۰ به وقت محلی) برای شرکتهای فناپتلکام (AS24631) و پارس آنلاین (AS16322) به حالت عادی برگشت. برای همراه اول (AS197207) و ایرانسل (AS44244) در ساعت ۲۰:۰۰ به وقت جهانی (۲۳:۳۰ به وقت محلی) و برای رایتل (AS57218) در ساعت ۲۲:۰۰ روز ۱۷ ژوئن (۰۱:۳۰ بامداد ۱۸ ژوئن به وقت محلی) اینترنت وصل شد. شرکت رسانا (AS31549 و AS205647) هم در ساعت ۰۶:۰۰ روز ۱۸ ژوئن (۰۹:۳0 به وقت محلی) به وضعیت عادی برگشت.
گزارش شده بود که در طول این قطعیهای اولیه، ترافیک ورودی به اینترنت ایران هم مسدود شده بود و دسترسی کاربران فقط به «شبکه ملی اطلاعات» (NIN) محدود بود.
فقط یک روز بعد، یعنی در تاریخ ۱۸ ژوئن، یک قطعی طولانیتر و سوم شروع شد که از ساعت ۱۲:۵۰ به وقت جهانی (۱۶:۲۰ به وقت محلی) تا ساعت ۰۵:۰۰ به وقت جهانی (۰۸:۳۰ به وقت محلی) روز ۲۵ ژوئن ادامه داشت. یک بار دیگه، گفته شد که این قطعی برای محافظت در برابر حملات سایبریه. یک سخنگوی دولت در این مورد گفت: «ما قبلا اعلام کرده بودیم که در صورت لزوم، قطعا به اینترنت ملی روی خواهیم آورد و دسترسی به اینترنت جهانی را محدود خواهیم کرد. امنیت دغدغه اصلی ماست و شاهد حملات سایبری به زیرساختهای حیاتی کشور و اختلال در عملکرد بانکها هستیم. یک صرافی ارز دیجیتال نیز هک شد و با در نظر گرفتن همه این مسائل، تصمیم به اعمال محدودیتهای اینترنتی گرفتیم». این قطعی باعث شد ترافیک تقریبا به طور کامل تا ساعت ۰۲:۰۰ به وقت جهانی (۰۵:۳۰ به وقت محلی) روز ۲۱ ژوئن قطع بشه. بعد از اون کمی ترافیک برگشت ولی هنوز خیلی کمتر از سطح قبل از قطعی بود. این وضعیت ترافیک کم برای چند روز به صورت یک چرخه ثابت ادامه داشت تا اینکه در ۲۵ ژوئن به سطح عادی برگشت. همون شرکتهایی که در قطعیهای قبلی درگیر بودن، این بار هم تحت تاثیر قرار گرفتن.
عراق
دولتهای عراق هم مثل سالهای گذشته (۲۰۲۴، ۲۰۲۳، ۲۰۲۲)، برای جلوگیری از تقلب در امتحانات سراسری، به طور منظم اینترنت رو قطع کردن. (اینجا از کلمه «دولتها» استفاده شده چون این قطعیها هم در بخش اصلی کشور و هم در منطقه کردستان عراق در شمال کشور اتفاق افتاد).
این قطعیها به درخواست وزارت آموزش و پرورش بین ساعتهای ۰۳:۰۰ تا ۰۵:۰۰ به وقت جهانی (۰۶:۰۰ تا ۰۸:۰۰ به وقت محلی) انجام میشد. در بخش اصلی عراق، قطعیها از ۲۰ می شروع شد و تا ۴ ژوئن برای امتحانات دوره راهنمایی و از ۱۴ ژوئن تا ۳ ژوئیه برای امتحانات دوره آمادگی ادامه داشت. شرکتهایی که این قطعی رو اجرا کردن شامل Earthlink (AS199739)، Asiacell (AS51684)، Zainas (AS59588)، Halasat (AS58322) و HulumTele (AS203214) بودن.
در منطقه کردستان، قطعیها از ۱ ژوئن شروع شد و تا ۶ ژوئیه ادامه داشت. این قطعیها در روزهای چهارشنبه و یکشنبه بین ساعتهای ۰۳:۳۰ تا ۰۴:۳۰ به وقت جهانی (۰۶:۳۰ تا ۰۷:۳۰ به وقت محلی) بود. شرکتهای این منطقه که قطعی رو اجرا کردن شامل IQ Online (AS48492)، KorekTel (AS59625)، Newroz Telecom (AS21277) و KNET (AS206206) بودن.
سوریه
سوریه هم مثل عراق، برای جلوگیری از تقلب در امتحانات، اینترنت رو در سطح کشور قطع میکنه و این کار رو چندین ساله که انجام میده (۲۰۲۱، ۲۰۲۲، ۲۰۲۳، ۲۰۲۴). اما بر خلاف سالهای قبل، در سال ۲۰۲۵ دولت فقط دستور قطع ارتباطات موبایلی (سلولی) رو داد. در بیانیهای که منتشر شد اومده بود: «در راستای تعهدمان به تضمین سلامت امتحانات عمومی و حفاظت از آینده دانشآموزان عزیزمان، و بر اساس مسئولیت ملی ما برای تامین یک محیط امتحانی عادلانه و شفاف، قطعی موقت ارتباطات سلولی در مناطق نزدیک به مراکز امتحانی در سراسر جمهوری عربی سوریه اجرا خواهد شد… این قطعی ارتباطات سلولی منحصرا در کمترین محدوده جغرافیایی و زمانی ممکن، در طول ساعاتی که دانشآموزان در سالنهای امتحان هستند، اجرا میشود».
در سه ماهه دوم، قطعیهای مربوط به «گواهی آموزش پایه» در تاریخهای ۲۱، ۲۴ و ۲۹ ژوئن بین ساعتهای ۰۵:۱۵ تا ۰۶:۰۰ به وقت جهانی (۰۸:۱۵ تا ۰۹:۰۰ به وقت محلی) اتفاق افتاد. امتحانات و قطعیهای مربوط به «گواهی آموزش متوسطه» هم برای تاریخهای بین ۱۲ ژوئیه تا ۳ اوت برنامهریزی شده.
چون این قطعیها فقط روی اینترنت موبایل تاثیر داشتن، باعث کاهش جزئی در فضای آدرس IP اعلام شده شدن، نه یک قطعی کامل مثل سالهای قبل.
پاناما
در تاریخ ۲۱ ژوئن، آژانس تنظیم مقررات مخابرات پاناما (ASEP) در یک پست در شبکه اجتماعی ایکس اعلام کرد که (ترجمه) «…در راستای اجرای فرمان کابینه شماره ۲۷ مورخ ۲۰ ژوئن ۲۰۲۵، و با دستور رسمی وزارت دولت، تعلیق موقت خدمات تلفن همراه و اینترنت خانگی در استان بوکاس دل تورو هماهنگ شده است». طبق این پست، قرار بود این تعلیق تا ۲۵ ژوئن ادامه داشته باشه، اما در یک پست دیگه اعلام شد که تا یکشنبه ۲۹ ژوئن ۲۰۲۵ تمدید میشه.
این تعلیق اینترنت در واکنش به اعتراضات و تظاهرات علیه اصلاحات در صندوق تامین اجتماعی، بازنشستگی و حقوق بازنشستگان، به خصوص در استان بوکاس دل تورو، اجرا شد.
نمودار مربوطه نشون میده که ترافیک شرکت Cable Onda (با شناسه AS18809) در بوکاس دل تورو پاناما، حدود ساعت ۰۳:۳۰ به وقت جهانی در ۲۱ ژوئن (۲۲:۳۰ به وقت محلی در ۲۰ ژوئن) تقریبا به طور کامل قطع شد و حدود ساعت ۰۶:۰۰ به وقت جهانی (۰۱:۰۰ به وقت محلی) در ۳۰ ژوئن دوباره وصل شد. زمان وصل شدن با آخرین پست ASEP در این مورد هماهنگه که گفته بود (ترجمه) «…خدمات اینترنت و تلفن همراه در استان بوکاس دل تورو از ساعت ۱۲:۰۱ بامداد دوشنبه ۳۰ ژوئن بازگردانده شده است».
فصل دوم: وقتی برق میره، اینترنت هم میره
اینترنت برای کار کردن به برق نیاز داره. وقتی برق در یک منطقه وسیع قطع میشه، مودمها، دکلهای مخابراتی و مراکز داده هم خاموش میشن و در نتیجه اینترنت هم قطع میشه.
پرتغال و اسپانیا
بزرگترین داستان قطعی برق در سه ماهه دوم، قطعی عظیم در بخش بزرگی از پرتغال و اسپانیا در تاریخ ۲۸ آوریل بود. تاثیر این اتفاق به طور کامل در یک پست وبلاگی جداگانه بررسی شد که تغییرات ترافیک در سطح کشور، شبکه و منطقه رو بررسی کرده بود و نشون میداد که قطعی برق چطور روی کیفیت شبکه و فضای آدرس IP اعلام شده تاثیر گذاشته.
در پرتغال: با قطع شدن شبکه برق، ترافیک اینترنت هم کاهش پیدا کرد. در مقایسه با هفته قبل، ترافیک بلافاصله حدود ۵۰ درصد و در عرض پنج ساعت حدود ۹۰ درصد کمتر از هفته قبل شد.
در اسپانیا: با قطع شدن شبکه برق، ترافیک اینترنت فورا حدود ۶۰ درصد و در عرض پنج ساعت بعد، تقریبا ۸۰ درصد نسبت به هفته قبل کاهش پیدا کرد.
در هر دو کشور، ترافیک حدود ساعت ۰۱:۰۰ به وقت محلی (نیمه شب به وقت جهانی) در ۲۹ آوریل به سطح عادی خودش برگشت.
مراکش
به نظر میرسه مراکش هم به نوعی تحت تاثیر قطعی برق پرتغال و اسپانیا قرار گرفته، یا حداقل شرکت Orange Maroc اینطور بوده. این شرکت در پستی در شبکه ایکس اعلام کرد (ترجمه): «ترافیک اینترنت به دنبال قطعی گسترده برق در اسپانیا و پرتغال که بر اتصالات بینالمللی تاثیر گذاشته، دچار اختلال شده است». ترافیک این شبکه (AS36925) حدود ساعت ۱۲:۰۰ به وقت جهانی (۱۳:۰۰ به وقت محلی)، یعنی ۹۰ دقیقه بعد از شروع قطعی برق، به شدت کاهش پیدا کرد و قطعی کامل حدود ساعت ۱۵:۰۰ به وقت جهانی (۱۶:۰۰ به وقت محلی) شروع شد. ترافیک حدود ساعت ۲۳:۳۰ روز ۲۸ آوریل (۰۰:۳۰ به وقت محلی روز ۲۹ آوریل) به حالت عادی برگشت.
پورتوریکو
شرکت برق Genera PR در پورتوریکو در ۱۶ آوریل در شبکه ایکس پستی گذاشت که (ترجمه) «…به دلیل خاموشی غیرمنتظره تمام نیروگاههای تولید برق، از جمله نیروگاههای Genera PR و سایر تولیدکنندگان خصوصی، شاهد یک قطعی برق گسترده در سراسر جزیره بودهایم. این وضعیت باعث اختلال قابل توجهی در خدمات برق شده است…». شرکت خصوصی دیگه به نام Luma Energy که مسئول توزیع و انتقال برق در پورتوریکو هست هم پست گذاشت که (ترجمه) «تقریبا ساعت ۱۲:۴۰ بعد از ظهر، رویدادی ثبت شد که خدمات را در سراسر جزیره تحت تاثیر قرار داده است».
با اینکه گفته شد قطعی برق «گسترده» و «در سراسر جزیره» بوده، اما تاثیر خیلی بزرگی روی ترافیک اینترنت پورتوریکو نداشت و در ابتدا حدود ۴۰ درصد ترافیک رو کم کرد. در چند روز بعد، هر دو شرکت پستهای متعددی درباره پیشرفت در وصل کردن برق منتشر کردن. تا ساعت ۱۵:۰۰ به وقت جهانی (۱۱:۰۰ به وقت محلی) در ۱۸ آوریل، ترافیک به سطح عادی برگشته بود. این با پستی از Luma Energy هماهنگ بود که گفته بود (ترجمه) «تا ساعت ۱۰:۰۰ صبح ۱۸ آوریل، و به لطف واکنش فوقالعاده LUMA و تلاشهای خستگیناپذیر نیروی کار جزیره – با هماهنگی دولت پورتوریکو و شرکتهای تولیدکننده – LUMA خدمات برق را برای ۱،۴۵۰،۳۶۷ مشتری، که معادل ۹۸.۸ درصد کل مشتریان است، در کمتر از ۳۸ ساعت پس از شروع قطعی سراسری، بازگردانده است».
همونطور که در نمودارها دیده میشه، قطعی برق نه تنها روی اتصال کاربران نهایی تاثیر گذاشت و باعث کاهش ترافیک شد، بلکه روی زیرساختهای محلی اینترنت هم تاثیراتی داشت و اختلالاتی در فضای آدرس IP اعلام شده هم دیده شد.
سنت کیتس و نویس
یک پست فیسبوک از طرف شرکت برق سنت کیتس (SKELEC) در تاریخ ۹ می به مشتریان در سنت کیتس و نویس هشدار داد که «…یک نقص در نیروگاه Needsmust ما ایجاد شده که منجر به قطعی برق در سراسر جزیره شده است. عملیات بازگرداندن برق شروع شده و تا دو ساعت دیگر به طور کامل وصل خواهد شد». این پست در ساعت ۱۷:۳۱ به وقت جهانی (۱۳:۳۱ به وقت محلی) منتشر شد، یعنی حدود ۳۰ دقیقه بعد از اینکه ترافیک اینترنت جزیره شروع به کاهش کرد. بازگشت ترافیک حدود ساعت ۱۷:۴۵ به وقت جهانی (۱۳:۴۵ به وقت محلی) شروع شد که خیلی زودتر از تخمین دو ساعته برای وصل کامل برق بود. اما ترافیک اینترنت تا ساعت ۲۰:۱۵ به وقت جهانی (۱۶:۱۵ به وقت محلی) به طور کامل به سطح عادی برنگشت.
مقدونیه شمالی
در ۱۸ می گزارش شد که «ولتاژ بالا در شبکه ۴۰۰ کیلوولتی منطقهای در شرایط مصرف پایین، باعث قطعی کوتاهمدت در شبکه انتقال ۱۱۰ کیلوولتی مقدونیه شمالی شده است…». این رو شرکت برق دولتی MEPSO اعلام کرد. با اینکه گفته شد قطعی بیشتر کشور رو تحت تاثیر قرار داده، MEPSO همچنین گفت که تامین برق کشور در عرض یک ساعت بعد از شروع قطعی، عادی شده. این قطعی برق با اینکه کوتاه بود، باعث شد ترافیک اینترنت کشور در طول این اختلال که بین ساعتهای ۰۳:۰۰ تا ۰۴:۴۵ به وقت جهانی (۰۵:۰۰ تا ۰۶:۴۵ به وقت محلی) بود، تقریبا ۶۰ درصد نسبت به هفته قبل کاهش پیدا کنه.
مالدیو
در تاریخ ۱ ژوئن، ترافیک اینترنت در مالدیو تقریبا نصف شد. دلیلش یک قطعی برق گسترده بود که منطقه «ماله بزرگ» رو تحت تاثیر قرار داد. ارائهدهندگان خدمات اینترنتی محلی مثل Ooredoo و Dhiraagu در شبکههای اجتماعی به مشترکینشون در مورد اختلالات احتمالی در اتصالات پهنباند ثابت و موبایل هشدار دادن. در سطح کشور، ترافیک اینترنت بین ساعتهای ۰۷:۳۰ تا ۱۳:۰۰ به وقت جهانی (۱۲:۳۰ تا ۱۸:۰۰ به وقت محلی) مختل بود.
این قطعی برق تاثیر جزئی هم روی زیرساخت اینترنت داشت، طوری که فضای آدرس IPv4 اعلام شده یک کاهش نامحسوس (از ۳۵۵ به ۳۵۰ تا /24s) داشت که کمی بعد از شروع کاهش ترافیک شروع شد، ولی با پایان اختلال به حالت عادی برگشت.
کوراسائو
یک قطعی اینترنت تقریبا کامل در شرکت Flow Curaçao (با شناسه AS52233) در تاریخ ۱۴ و ۱۵ ژوئن، باعث عصبانیت و درخواست توضیح از طرف نهاد تنظیم مقررات مخابراتی این کشور شد. ترافیک اینترنت شرکت Flow در ساعت ۱۸:۰۰ به وقت جهانی (۱۴:۰۰ به وقت محلی) در ۱۴ ژوئن به شدت کاهش پیدا کرد و در ساعتهای بعد هم کمتر شد. نشانههایی از بهبودی حدود ساعت ۱۱:۰۰ به وقت جهانی (۰۷:۰۰ به وقت محلی) در ۱۵ ژوئن دیده شد و بهبودی کاملتر در ساعت ۱۴:۰۰ به وقت جهانی (۱۰:۰۰ به وقت محلی) اتفاق افتاد. یک پست فیسبوک از طرف Flow Barbados که در ۱۸ ژوئن منتشر شد، به یک اختلال محلی اشاره کرد که از ۱۴ ژوئن شروع شده بود، اما دلیل اون رو یک قطعی برق تجاری در یکی از تاسیسات کلیدی شبکه منطقهایشون در کوراسائو اعلام کرد که به احتمال زیاد عامل این قطعی اینترنت بوده.
فصل سوم: آسیب به کابلهای فیبر نوری
کابلهای فیبر نوری شاهرگهای اصلی اینترنت هستن. اگه این کابلها، چه در خشکی و چه زیر دریا، آسیب ببینن، میتونن باعث قطعیهای بزرگی بشن.
دیجیسل هائیتی
دو مورد آسیب به زیرساخت فیبر نوری شرکت Digicel Haiti (با شناسه AS27653) باعث یک قطعی کامل اینترنت در این شرکت از ساعت ۲۱:۰۰ به وقت جهانی (۱۷:۰۰ به وقت محلی) در تاریخ ۲۸ می شد. این خبر رو مدیر کل شرکت در یک پست در شبکه ایکس اعلام کرد. این آسیب به کابل، شبکه رو کاملا از اینترنت خارج کرد، طوری که فضای آدرس IPv4 و IPv6 اعلام شده هم به صفر رسید. دیجیسل هائیتی تا ساعت ۰۰:۴۵ روز ۲۹ می (۲۰:۴۵ به وقت محلی روز ۲۸ می) آفلاین بود و بعد از اون هم ترافیک و هم فضای آدرس IP اعلام شده به سطح عادی برگشت.
ایرِتل مالاوی
شرکت Airtel Malawi (با شناسه AS37440) در تاریخ ۲۴ ژوئن یک قطعی اینترنت ۹۰ دقیقهای رو تجربه کرد که به دلیل خرابکاریهای مداوم در شبکه فیبر نوریشون بود. با اینکه ترافیک بین ساعتهای ۱۲:۳۰ تا ۱۴:۰۰ به وقت جهانی (۱۴:۳۰ تا ۱۶:۰۰ به وقت محلی) تقریبا به صفر رسید، اما شبکه حداقل تا حدی آنلاین باقی موند چون حداقل بخشی از فضای آدرس IPv4 شبکه همچنان به اینترنت اعلام میشد. اما فضای آدرس IPv6 اعلام شده در طول قطعی به صفر رسید.
فصل چهارم: مشکلات فنی
گاهی وقتها قطعی اینترنت نه به خاطر عوامل خارجی، بلکه به خاطر یک مشکل فنی داخلی در تجهیزات یا نرمافزارهای یک شرکت اینترنتی اتفاق میفته.
بل کانادا
یک آپدیت روتر که اشتباه از آب در اومد، خدمات اینترنت رو برای مشتریان شرکت Bell Canada (با شناسه AS577) در انتاریو و کبک در تاریخ ۲۱ می مختل کرد. اولین پست شرکت در شبکه ایکس در ساعت ۱۳:۵۲ به وقت جهانی (۰۹:۵۲ به وقت محلی) به مشتریان در مورد این قطعی سرویس اطلاع داد. این پست حدود نیم ساعت بعد از شروع اختلال منتشر شد، چون ترافیک حدود ساعت ۱۳:۱۵ به وقت جهانی (۰۹:۱۵ به وقت محلی) شروع به کاهش کرد و تا ۷۰ درصد نسبت به زمان مشابه در هفته قبل کمتر شد. ترافیک درخواستها به سرویس DNS کلادفلر یعنی 1.1.1.1 هم کاهش قابل توجهی داشت. یک کاهش ناچیز هم در فضای آدرس IPv4 اعلام شده دیده شد.
این اختلال نسبتا کوتاه بود و ترافیک فقط یک ساعت بعد به سطح عادی برگشت. یک پست بعدی در شبکه ایکس تایید کرد که خدمات تا ساعت ۱۵:۰۰ به وقت جهانی (۱۱:۰۰ به وقت محلی) به طور کامل وصل شده و پست دیگری هم اشاره کرد که آپدیت اولیه به سرعت برگردانده شده تا سرویس وصل بشه.
لومن/سنچریلینک
در بخشهایی از ایالات متحده، مشتریان شرکت Lumen/CenturyLink (با شناسه AS209) در تاریخ ۱۹ ژوئن یک اختلال گسترده در سرویس اینترنت رو تجربه کردن. حجم ترافیک از حدود ساعت ۲۱:۴۵ به وقت جهانی، بیشتر از ۵۰ درصد نسبت به هفته قبل کاهش پیدا کرد. این اختلال فقط چند ساعت طول کشید و ترافیک تا ساعت ۰۰:۰۰ به وقت جهانی در ۲۰ ژوئن به حالت عادی برگشت.
پستهای کاربران در شبکههای اجتماعی نشون میداد که مشکل احتمالا مربوط به DNS بوده، چون کسانی که سرور DNS خودشون رو به 1.1.1.1 کلادفلر تغییر داده بودن، دوباره میتونستن به اینترنت دسترسی داشته باشن. نمودار مربوطه نشون میده که ترافیک از طرف لومن/سنچریلینک به 1.1.1.1 با شروع اختلال از سطح هفته قبل بالاتر رفت و تا ۲۰ ژوئن بالا باقی موند. مشکلات در سرور DNS یک شرکت ارائهدهنده اینترنت میتونه برای مشترکین مثل یک قطعی کامل اینترنت به نظر برسه، چون دیگه نمیتونن به هیچ چیزی که نیاز به جستجوی DNS داره (یعنی تقریبا تمام منابع اینترنتی) دسترسی پیدا کنن و این در نهایت منجر به کاهش ترافیک به اون منابع میشه.
فصل پنجم: تاثیر حملههای سایبری
حملات سایبری، مخصوصا حملات منع سرویس توزیعشده (DDoS)، میتونن با ارسال حجم عظیمی از ترافیک ناخواسته به یک شبکه، اون رو از کار بندازن.
ASVT (روسیه)
گزارش شده که شرکت ارائهدهنده اینترنت روسی ASVT (با شناسه AS8752) هدف یک حمله بزرگ DDoS قرار گرفته که منجر به یک قطعی کامل و چند روزه اینترنت شده. این حمله به دنبال حمله دیگهای بود که در ماه مارس شرکت روسی Nodex (AS29329) رو هدف قرار داده بود و اون هم باعث قطعی کامل سرویس شده بود. حملهای که به ASVT شد به ۷۰.۰۷ گیگابیت بر ثانیه / ۶.۹۲ میلیون بسته بر ثانیه رسید و باعث شد ترافیک حدود ساعت ۰۵:۰۰ به وقت جهانی در ۲۸ می (۰۸:۰۰ به وقت مسکو) تقریبا به صفر برسه. این قطعی موثر حدود ۱۰ ساعت طول کشید. با اینکه ترافیک از حدود ساعت ۱۵:۰۰ به وقت جهانی (۱۸:۰۰ به وقت مسکو) شروع به برگشتن کرد، اما در طول هفته بعد همچنان پایینتر از سطح عادی باقی موند.
نکته جالب اینه که حجم درخواستها از شبکه ASVT به سرور DNS کلادفلر یعنی 1.1.1.1، با شروع بازگشت ترافیک بعد از قطعی اولیه، افزایش سریعی داشت و در طول مدت اختلال بالا باقی موند. مشخص نیست که این افزایش میتونه به مشکلات سرور DNS خود ASVT در طول حمله مربوط باشه که کاربران رو مجبور کرده به دنبال سرورهای جایگزین بگردن، یا اینکه میتونه به این خاطر باشه که مشترکین ASVT به دنبال راههایی برای دور زدن آسیبهای ناشی از حمله بودن.
فصل ششم: قطعیهای بدون توضیح مشخص
گاهی وقتها یک قطعی بزرگ اتفاق میفته، ولی شرکت مربوطه هیچ دلیل رسمی برای اون اعلام نمیکنه و ما فقط میتونیم از روی دادهها حدسهایی بزنیم.
تلیا فنلاند (۱ آوریل)
طبق یک «بولتن اختلال» (که الان در دسترس نیست) و یک پست مرتبط در شبکه ایکس از طرف شرکت Telia Finland (با شناسه AS1759)، این شرکت تایید کرد که «یک اختلال گسترده در عملکرد اتصالات داده شبکه تلفن همراه و پهنباند ثابت شناسایی شده است». این اختلال گسترده منجر به یک قطعی تقریبا کامل و کوتاه برای مشترکین بین ساعتهای ۰۶:۳۰ تا ۰۷:۱۵ به وقت جهانی (۰۹:۳۰ تا ۱۰:۱۵ به وقت محلی) شد.
تلیا فنلاند دلیل این اختلال رو اعلام نکرد، اما مشخصه که روی اتصال IPv4 تاثیر گذاشته بود، چون فضای آدرس IPv4 اعلام شده کاهش پیدا کرد. (فضای آدرس IPv6 اعلام شده تغییری نکرد). این از دست رفتن اتصال IPv4 باعث یک جهش همزمان در سهم ترافیک IPv6 از تلیا فنلاند شد. این سهم که معمولا زیر ۵ درصد هست، در طول اختلال به بالای ۳۰ درصد رسید. ترافیک درخواستها به سرور 1.1.1.1 کلادفلر از طرف تلیا فنلاند هم در همون زمان جهش پیدا کرد.
اسکایکیبل
حدود ساعت ۱۹:۱۵ به وقت جهانی در ۷ می (۰۳:۱۵ به وقت محلی در ۸ می)، مشترکین شرکت SkyCable (با شناسه AS23944) در فیلیپین یک قطعی کامل اینترنت رو تجربه کردن. ترافیک اینترنت از این شبکه به صفر رسید و فضای آدرس IPv4 اعلام شده هم همینطور. این اختلال تا ساعت ۰۳:۰۰ به وقت جهانی در ۸ می (۱۱:۰۰ به وقت محلی) ادامه داشت و اسکایکیبل هیچ اطلاعاتی در مورد دلیل این قطعی هشت ساعته منتشر نکرد.
تروموو اچ
در تاریخ ۲۲ می، شرکت موبایل تایلندی TrueMove H (با شناسه AS132061) دچار یک قطعی سراسری شد که اتصال مشترکینش رو تحت تاثیر قرار داد. این شرکت این اختلال رو تایید و بابت اون عذرخواهی کرد، اما دلیل رسمی برای قطعی ارائه نداد. (یک مقاله در مطبوعات محلی گزارش داد که «قطعی به دلیل خطاهای فنی در سرورهای کامپیوتری True بوده» و همچنین گفت که دیگران حدس میزنن «مشکل ممکن است به دلیل خطا در سرورهای DNS شرکت True بوده باشد»).
در ساعت ۰۳:۰۰ به وقت جهانی (۱۰:۰۰ به وقت محلی)، ترافیک در ابتدا بیشتر از ۸۰ درصد نسبت به هفته قبل کاهش پیدا کرد. تقریبا بلافاصله، ترافیک شروع به بهبودی آهسته کرد و حدود ساعت ۰۸:۰۰ به وقت جهانی (۱۵:۰۰ به وقت محلی) به سطح عادی برگشت. یک کاهش جزئی و کوتاه در فضای آدرس IPv4 اعلام شده هم در ساعت اول اختلال دیده شد.
دیجیسل هائیتی
دو روز بعد از تجربه یک قطعی به خاطر آسیب به کابل، شرکت Digicel Haiti (با شناسه AS27653) در تاریخ ۳۰ می یک قطعی کامل دیگه رو تجربه کرد. بر خلاف قطعی قبلی، هیچ اطلاعات اضافهای در مورد این یکی در شبکههای اجتماعی توسط دیجیسل هائیتی یا مدیر کلش منتشر نشد. شبکه عملا در ساعت ۱۴:۱۵ به وقت جهانی (۱۰:۱۵ به وقت محلی) از اینترنت محو شد و هم ترافیک و هم فضای آدرس IP اعلام شده (هم IPv4 و هم IPv6) به صفر رسید. این قطعی تقریبا سه ساعت طول کشید و ترافیک و فضای آدرس اعلام شده همه حدود ساعت ۱۷:۰۰ به وقت جهانی (۱۳:۰۰ به وقت محلی) برگشتن.
سوریه
در تاریخ ۱۰ ژوئن، یک قطعی اینترنت در سوریه گزارش شد که شبکه خط ثابت ADSL رو در چندین استان تحت تاثیر قرار داد. ترافیک در ساعت ۰۸:۱۵ به وقت جهانی (۱۱:۱۵ به وقت محلی) تا دو سوم کمتر از زمان مشابه در هفته قبل کاهش پیدا کرد و این اختلال دو ساعت طول کشید. فضای آدرس IPv4 اعلام شده هم در طول قطعی کاهش پیدا کرد که نشوندهنده یک مشکل احتمالی در زیرساخت بود. با این حال، حجم درخواستها از سوریه به سرور DNS کلادفلر یعنی 1.1.1.1 هم در طول قطعی بالا بود. این رفتار در گذشته در طول قطعیهای دستوری اینترنت در سوریه هم دیده شده بود، زمانی که ترافیک میتونه از کشور خارج بشه ولی نمیتونه برگرده. هیچ نشونه دیگهای مبنی بر اینکه این قطعی عمدی بوده وجود نداشت، اما هیچ توضیح رسمی هم برای این اختلال در دسترس نبود.
قطعیهای اینترنت به دستور دولتها در سه ماهه دوم با قدرت برگشتن و این روند در سه ماهه سوم هم ادامه داره، هرچند موارد اخیر بیشتر مربوط به امتحانات بودن تا اعتراضات. و با اینکه قطعیهای اینترنت مربوط به قطعی برق در گذشته هم زیاد دیده شدن، که اغلب در کشورهای کوچکتر با زیرساختهای کمتر پایدار بودن، قطعی عظیم در اسپانیا و پرتغال در ۲۸ آوریل به ما یادآوری میکنه که زیرساختهای برق، خیلی شبیه به اینترنت، اغلب بین کشورها به هم متصل هستن و این یعنی مشکلات در یک کشور میتونه به طور بالقوه باعث مشکلات بزرگ در کشورهای دیگه بشه.
گوگل یه ابزار جدید و کاربردی به اسم Google Trends API معرفی کرده که قراره دیگه با ابزارهای حرفهای ترندهارو استخراج کنیم.
مشخصات کلی Google Trends API (نسخه آلفا)
ویژگی
توضیحات
نوع محصول
API (رابط برنامه نویسی کاربردی)
دادههای موجود
دادههای علاقه جستجو (Search Interest)
بازه زمانی دادهها
پنج سال گذشته (پنجره زمانی چرخشی ۱۸۰۰ روزه)
تازگی دادهها
اطلاعات تا ۴۸ ساعت قبل در دسترس هستند.
مقیاسبندی دادهها
مقیاسبندی ثابت (Consistently Scaled) که امکان مقایسه بین درخواستهای مختلف رو میده.
تفکیک زمانی (Aggregation)
روزانه، هفتگی، ماهانه و سالانه
تفکیک جغرافیایی
کشور، ایالت، شهر (منطقه و زیرمنطقه بر اساس استاندارد ISO 3166-2)
محدودیت
دادههای بخش «جستجوهای داغ» یا Trending Now در این API وجود نداره.
وضعیت فعلی
نسخه آلفا (در حال تست)
ارائهدهندگان
Daniel Waisberg و Hadas Jacobi از تیم گوگل ترندز
محل رونمایی
Google Search Central Live, Deep Dive APAC 2025
داستان از چه قراره؟ گوگل یه API برای ترندز داده بیرون
گوگل به تازگی توی رویداد Google Search Central Live, Deep Dive APAC 2025 از یه نسخه آلفا یا آزمایشی برای API گوگل ترندز رونمایی کرده. اگه نمیدونی API چیه، بذار ساده بگم: یه راهی هست که برنامهها و نرمافزارهای مختلف میتونن مستقیم با دادههای گوگل ترندز حرف بزنن و اطلاعات بگیرن، بدون اینکه لازم باشه بری توی سایت گوگل ترندز و دستی چیزی رو جستجو کنی. یعنی میتونی دادههای صفحه «اکسپلور» گوگل ترندز رو مستقیم بیاری توی اپلیکیشن یا ابزار خودت.
این خبر رو دو نفر از اعضای تیم گوگل به اسمهای دنیل وایزبرگ (Daniel Waisberg) و هداس جاکوبی (Hadas Jacobi) اعلام کردن. اونها گفتن که این نسخه آلفا از همین امروز در دسترسه و دنبال توسعهدهندهها و افرادی میگردن که حاضر باشن این ابزار رو در طول سال ۲۰۲۵ تست کنن و به گوگل بازخورد بدن. یه نکته مهم اینه که این API قرار نیست دادههای بخش «جستجوهای داغ» یا همون Trending Now رو شامل بشه.
این API به درد کیا میخوره؟
گوگل ترندز سالهاست که وجود داره و همه از طریق وبسایتش به دادهها دسترسی داشتن. اما درخواستها برای یه API که بشه به صورت مقیاسپذیر از این دادهها استفاده کرد، خیلی زیاد شده بود. گوگل بر اساس تحقیقات اولیهای که انجام داده، چند تا گروه اصلی رو شناسایی کرده که این API میتونه حسابی به دردشون بخوره:
محققها: توسعهدهندهها و پژوهشگرها میتونن از این دادهها استفاده کنن تا روی تخصیص منابع عمومی و اولویتهای تحقیقات علمی تاثیر بذارن.
ناشرها و روزنامهنگارها: اونها میتونن موضوعات مختلف رو دنبال کنن، ترندهای جدید رو پیدا کنن و با استفاده از این دادهها، داستانهای جذابی درباره مسائل مهم روز تعریف کنن.
کسبوکارها، سئوکارها و بازاریابها: این گروه میتونن برای سرمایهگذاری روی منابعشون بهتر اولویتبندی کنن و استراتژی محتوای بهتری برای کسبوکارشون طراحی کنن.
ویژگیهای اصلی این API چی هستن؟
بیا با هم دقیقتر ببینیم این ابزار جدید گوگل چه قابلیتهای کلیدیای داره.
۱. مقیاسبندی ثابت دادهها؛ یه قابلیت خیلی مهم
مهمترین و برجستهترین ویژگی این نسخه آلفا، «مقیاسبندی ثابت» یا Consistently Scaled Search Interest هست.
اگه تا حالا با وبسایت گوگل ترندز کار کرده باشی، میدونی که وقتی چند تا کلمه رو با هم مقایسه میکنی، گوگل بهت یه نمودار با اعداد بین ۰ تا ۱۰۰ نشون میده. مشکل اینجاست که این اعداد هر بار بر اساس ترکیبی از کلماتی که جستجو کردی، دوباره محاسبه و مقیاسبندی میشن. یعنی اگه یه کلمه جدید به مقایسهات اضافه کنی، اعداد قبلی هم ممکنه تغییر کنن.
اما توی این API قضیه فرق میکنه. مقادیر و اعدادی که API برمیگردونه، در تمام درخواستها ثابت باقی میمونن. این یعنی شما میتونی دادههای چند تا درخواست مختلف رو با هم ترکیب، مقایسه و ادغام کنی. مثلا میتونی جستجوی کلمه «هوش مصنوعی» رو امروز بگیری و هفته بعد دوباره همون رو بگیری و این دو تا عدد رو با هم مقایسه کنی، چون مقیاسشون یکسانه.
البته حواست باشه که این اعداد، حجم جستجوی کامل یا مطلق نیستن. اونها فقط «میزان علاقه به جستجو» یا «search interest» رو نشون میدن. با این حال، توی نمونه پاسخی که گوگل نشون داده، یه عدد به عنوان حجم جستجوی حدودی (indicative search volume) هم کنار عدد مقیاسبندی شده قرار گرفته تا بشه با چیزی که توی وبسایت گوگل ترندز میبینی، مقایسهاش کرد.
مزیت بزرگ این روش اینه که دیگه لازم نیست برای مانیتور کردن یک کلمه در طول زمان، هر بار کل بازه زمانی رو از اول بگیری. توی وبسایت، مجبور بودی هر دفعه کل تاریخچه رو دانلود کنی تا مقیاس ۰ تا ۱۰۰ درست بمونه. اما با API، فقط دادههای دوره جدید رو میگیری و به دادههای قبلی اضافه میکنی. همچنین، در حالی که وبسایت فقط اجازه مقایسه ۵ کلمه رو میده، با API میشه دهها کلمه رو خیلی راحتتر با هم مقایسه کرد.
۲. پنجره زمانی پنج ساله
این API دادههای مربوط به یک پنجره زمانی چرخشی ۱۸۰۰ روزه (یعنی تقریبا پنج سال) رو در اختیارت میذاره. دلیل انتخاب این بازه زمانی اینه که تحلیلهای گوگل نشون داده بیشتر افراد تحلیلهاشون رو در همین بازه ۵ ساله انجام میدن. درسته که خیلی از کاربردها مربوط به ۱۲ ماه گذشته هستن، اما گوگل معتقده که بازه ۵ ساله برای محققها و روزنامهنگارها خیلی مهمه تا بتونن به رویدادهای مهمی مثل انتخاباتهای قبلی (که معمولا هر ۴ سال یک بار هستن) یا رویدادهای ورزشی مثل المپیک و جام جهانی نگاه کنن.
یه نکته جالب دیگه اینه که دادهها تا ۴۸ ساعت قبل در دسترس هستن. این تاخیر عمدی هست تا الگوهای زمانی، مثل رویدادهای سالانه یا چرخههای هفتگی، حفظ بشن و تحلیلها دقیقتر باشن. این زمینه طولانیتر بهت کمک میکنه تا جهشهای جستجوی امروزی رو با سالهای قبل مقایسه کنی و ترندهای فصلی و چرخههای خبری تکراری رو بهتر تشخیص بدی.
۳. دستهبندی انعطافپذیر و تفکیک جغرافیایی
شما میتونی انتخاب کنی که دادهها چطور دستهبندی یا جمعبندی (aggregate) بشن: هفتگی، ماهانه یا سالانه. علاوه بر اینها، دستهبندی روزانه هم ارائه میشه. این انعطافپذیری بهت اجازه میده هم برای تحلیلهای خیلی دقیق روی جزئیات زوم کنی و هم برای دیدن ترندهای بلندمدت، یه قدم به عقب برگردی و تصویر بزرگتر رو ببینی. چون کاربردها خیلی متنوع هستن و ممکنه توسعهدهندهها بخوان این دادهها رو با گزارشهای دیگه خودشون ترکیب کنن، گوگل هر چهار گزینه (روزانه، هفتگی، ماهانه، سالانه) رو فراهم کرده تا دستشون برای کار با دادهها باز باشه.
علاوه بر این، تفکیکهای منطقهای و زیرمنطقهای هم از طریق API در دسترس هستن. یعنی میتونی میزان علاقه به یک موضوع رو در سطح کشورها، ایالتها یا حتی شهرها بدون هیچ کار اضافهای مشخص کنی. این تفکیک جغرافیایی بر اساس استاندارد ISO 3166-2 انجام میشه.
یه نمونه درخواست و پاسخ API
هداس جاکوبی توی معرفیش یه مثال از نحوه ارسال درخواست با زبان برنامهنویسی پایتون و نمونه پاسخی که از API دریافت میشه رو به اشتراک گذاشت. بیا با هم ببینیمش:
"points": یه لیستی از نقاط داده رو نشون میده. هر نقطه مربوط به یک بازه زمانیه.
"time_range": مشخص میکنه که این داده برای چه بازه زمانی هست. مثلا از اول ژانویه ۲۰۲۴ تا هفتم ژانویه ۲۰۲۴.
"search_interest": این همون عدد حجم جستجوی حدودی هست که گفتم. مثلا در هفته اول ژانویه، میزان علاقه جستجو ۴۴۰۰ بوده.
"scaled_search_interest": این همون عدد مقیاسبندی شده ثابته که بین ۰ تا ۱۰۰ هست. اینجا برای هفته اول ۶۲ و برای هفته دوم که اوج جستجو بوده، ۱۰۰ در نظر گرفته شده.
سوالات پرتکرار درباره دادههای گوگل ترندز
حالا که با خود API آشنا شدیم، خوبه که یه سری سوالات رایج درباره دادههای گوگل ترندز رو هم مرور کنیم تا دید بهتری نسبت بهش پیدا کنیم. این اطلاعات مستقیم از طرف خود گوگل ارائه شده.
چطور یه نمونه از جستجوها میتونه نماینده کل جستجوها باشه؟
درسته که گوگل ترندز فقط از یه نمونه از جستجوهای گوگل استفاده میکنه، اما این کافیه چون روزانه میلیاردها جستجو در گوگل انجام میشه. ارائه دسترسی به کل مجموعه دادهها اونقدر حجمش زیاده که پردازش سریعش غیرممکنه. با نمونهبرداری از دادهها، گوگل میتونه به مجموعهای نگاه کنه که نماینده کل جستجوهای گوگل هست و همزمان، اطلاعاتی رو پیدا کنه که چند دقیقه بعد از وقوع یه رویداد در دنیای واقعی، قابل پردازش باشن.
دادههای گوگل ترندز چطور نرمالسازی میشن؟
گوگل ترندز دادههای جستجو رو نرمالسازی میکنه تا مقایسه بین کلمات مختلف راحتتر بشه. این فرآیند به این شکله:
هر نقطه داده بر کل جستجوهای اون منطقه جغرافیایی و بازه زمانی تقسیم میشه تا محبوبیت نسبی مشخص بشه. وگرنه، جاهایی که حجم جستجوی بیشتری دارن همیشه رتبه بالاتری میگرفتن.
اعداد به دست اومده بعدش بر اساس نسبت یک موضوع به کل جستجوها در همه موضوعات، روی یه مقیاس از ۰ تا ۱۰۰ قرار میگیرن.
مناطق مختلفی که علاقه جستجوی یکسانی برای یه کلمه نشون میدن، لزوما حجم جستجوی کل یکسانی ندارن.
چه جستجوهایی در گوگل ترندز لحاظ میشن؟
دادههای گوگل ترندز جستجوهایی رو نشون میدن که مردم هر روز در گوگل انجام میدن، اما میتونه فعالیتهای جستجوی غیرعادی مثل جستجوهای خودکار یا کوئریهایی که ممکنه برای اسپم کردن نتایج جستجو استفاده بشن رو هم منعکس کنه.
با اینکه گوگل مکانیزمهایی برای شناسایی و فیلتر کردن فعالیتهای غیرعادی داره، اما این جستجوها ممکنه به عنوان یه اقدام امنیتی در گوگل ترندز باقی بمونن. دلیلش اینه که اگه این جستجوها از ترندز فیلتر بشن، به اونهایی که این کوئریها رو میفرستن کمک میکنه تا بفهمن گوگل شناساییشون کرده. این کار باعث میشه فیلتر کردن این فعالیتها در بقیه محصولات جستجوی گوگل که دادههای جستجوی دقیق در اونها حیاتیه، سختتر بشه. بنابراین، اونایی که به دادههای گوگل ترندز تکیه میکنن باید بدونن که این دادهها آینه کاملی از فعالیت جستجو نیست.
با این حال، گوگل ترندز بعضی از انواع جستجوها رو فیلتر میکنه:
جستجوهایی که توسط افراد خیلی کمی انجام شدن: ترندز فقط دادههای کلمات محبوب رو نشون میده، پس کلماتی که حجم جستجوی پایینی دارن به صورت «۰» نشون داده میشن.
جستجوهای تکراری: ترندز جستجوهای تکراری از یک شخص در یک بازه زمانی کوتاه رو حذف میکنه.
کاراکترهای خاص: ترندز کوئریهایی که آپاستروف و کاراکترهای خاص دیگه دارن رو فیلتر میکنه.
آیا گوگل ترندز همون داده نظرسنجیه؟
نه. گوگل ترندز یه نظرسنجی علمی نیست و نباید با دادههای نظرسنجی اشتباه گرفته بشه. این ابزار صرفا علاقه به جستجو در موضوعات خاص رو نشون میده. یه جهش ناگهانی در یه موضوع به این معنی نیست که اون موضوع به نوعی «محبوب» یا «برنده» شده، فقط نشون میده که به دلایل نامشخص، به نظر میرسه کاربرهای زیادی دارن درباره اون موضوع جستجو میکنن. دادههای گوگل ترندز همیشه باید به عنوان یک نقطه داده در کنار بقیه دادهها در نظر گرفته بشن، قبل از اینکه به نتیجهگیری برسیم.
گوگل ترندز با Autocomplete چه فرقی داره؟
Autocomplete یا تکمیل خودکار، یه ویژگی توی جستجوی گوگله که برای سریعتر کردن تکمیل جستجوهایی که شروع به تایپشون کردی، طراحی شده. پیشبینیها از جستجوهای واقعی که در گوگل اتفاق میفتن میان و جستجوهای رایج و ترند مرتبط با کاراکترهایی که وارد کردی و همچنین موقعیت مکانی و جستجوهای قبلی تو رو نشون میدن. برخلاف گوگل ترندز، Autocomplete تابع سیاستهای حذف گوگل و همچنین فیلترهای الگوریتمی هست که برای گرفتن پیشبینیهای ناقض سیاستها و نشون ندادن اونها طراحی شده. به همین دلیل، نباید Autocomplete رو همیشه به عنوان منعکس کننده محبوبترین کلمات جستجو شده مرتبط با یه موضوع در نظر گرفت.
گوگل ترندز با دادههای جستجوی AdWords چه فرقی داره؟
گزارش کلمات جستجوی AdWords برای درک حجم جستجوی ماهانه و میانگین، به طور خاص برای تبلیغدهندهها طراحی شده، در حالی که گوگل ترندز برای کندوکاو عمیقتر در دادههای جزئیتر و در لحظه (real-time) ساخته شده.
چه منطقه زمانی برای دادههای نمودارها استفاده میشه؟
منطقه زمانی که در نمودارهای صفحه اکسپلور گوگل ترندز استفاده میشه، به طول بازه زمانی که مشاهده میکنی بستگی داره:
برای بازههای زمانی ۳۰ روز یا بیشتر: دادههای نشون داده شده در نمودار از زمان هماهنگ جهانی (UTC) استفاده میکنن. این برای وقتیه که جزئیات دادهها روزانه، هفتگی یا ماهانه باشه. استفاده از UTC یه استاندارد جهانی ثابت فراهم میکنه و مقایسه ترندهای بلندمدت در مناطق مختلف رو بدون پیچیدگیهای مناطق زمانی محلی یا تغییرات ساعت تابستانی، آسون میکنه.
برای بازههای زمانی ۷ روز یا کمتر: دادههای نشون داده شده در نمودار از منطقه زمانی محلی خودت که در مرورگر یا دستگاهت تنظیم شده، استفاده میکنن. این معمولا برای وقتیه که جزئیات دادهها کمتر از یک روزه، مثل دادههای ساعتی. استفاده از زمان محلی باعث میشه نوسانات ساعتی یا در لحظه رو به راحتی درک کنی و به رویدادهای برنامه روزانه یا منطقه خودت ربط بدی.
چطوری میشه این API رو تست کرد؟
همونطور که گفتم، این API فعلا در مرحله تست آلفا هست. گوگل میخواد عملکردش رو بررسی کنه و از یه گروه محدود از توسعهدهندهها بازخورد بگیره تا محصول نهایی رو بهتر کنه. از اونجایی که هنوز نمیتونن API رو برای همه باز کنن، اولویت با توسعهدهندههایی هست که میدونن میخوان باهاش چیکار کنن، میتونن زود شروع به کار کنن و مایل به ارائه بازخورد هستن.
اگه شما هم یه ایده مشخص برای استفاده از این API داری و میتونی به گوگل بازخورد بدی، میتونی از طریق فرمی که گوگل ارائه کرده برای تبدیل شدن به یه تستر آلفا درخواست بدی. گوگل دسترسی رو به صورت تدریجی طی هفتههای آینده برای تعداد محدودی از توسعهدهندهها باز میکنه. اگه توی اولین گروه نبودی، جای نگرانی نیست چون طی ماههای آینده دسترسی رو بیشتر میکنن.
نام درس: آشنایی با Jetflow: راهکار کلودفلر برای جابجایی دیتا در مقیاس بزرگ
مدت زمان مطالعه: حدود ۱۵ دقیقه
پیشنیازها: آشنایی اولیه با مفاهیم دیتابیس و دیتا
اهداف درس:
یاد میگیری که Jetflow چی هست و چرا ساخته شده.
با دستاوردها و بهبودهای عملکردی که Jetflow ایجاد کرده آشنا میشی.
با معماری و بخشهای اصلی این فریمورک آشنا میشی.
میفهمی که چطور با تکنیکهای خاص، عملکرد انتقال دیتا رو به شدت بالا بردن.
امروز میخوایم بریم سراغ یه مطالعه موردی خیلی جالب از شرکت کلودفلر (Cloudflare). این شرکت با حجم عظیمی از دیتا سر و کار داره و برای مدیریت این دیتا به یه چالش بزرگ خورده بود. ما قراره ببینیم این چالش چی بوده و چطوری با ساختن ابزاری به اسم Jetflow حلش کردن. این درس بهت کمک میکنه بفهمی در دنیای واقعی، شرکتهای بزرگ با چه مشکلاتی روبرو میشن و چطور برای حلشون راهکارهای خلاقانه طراحی میکنن.
بریم که شروع کنیم.
فصل اول: صورت مسئله، یک دریاچه پر از دیتا
قضیه از این قراره که در کلودفلر، یه تیمی به اسم تیم هوش تجاری (Business Intelligence) وجود داره. وظیفه این تیم مدیریت یه چیزی به اسم «دریاچه دیتا» یا Data Lake هست که مقیاسش در حد پتابایته. این تیم هر روز هزاران جدول رو از منابع مختلف جمعآوری و وارد این دریاچه میکنه.
این منابع هم داخلی هستن، مثل دیتابیسهای Postgres و ClickHouse، و هم خارجی، مثل نرمافزارهای خدماتی (SaaS) مثل Salesforce. کار این تیم خیلی پیچیدهاس، چون بعضی از این جدولها هر روز صدها میلیون یا حتی میلیاردها ردیف دیتای جدید دارن. در مجموع، هر روز حدود ۱۴۱ میلیارد ردیف دیتا وارد سیستم میشه. این دیتاها برای تصمیمگیریهای مهم شرکت، مثل برنامهریزی برای رشد، تصمیمات مربوط به محصولات و نظارت داخلی، فوقالعاده حیاتی هستن.
با بزرگتر شدن کلودفلر، حجم دیتا هم روز به روز بیشتر و پیچیدهتر میشد. راهکار قبلی اونها برای انتقال دیتا که بهش میگن ELT (مخفف Extract, Load, Transform)، دیگه نمیتونست نیازهای فنی و تجاری شرکت رو برآورده کنه. اونها راهکارهای رایج دیگه رو هم بررسی کردن اما به این نتیجه رسیدن که عملکرد اونها هم معمولا بهتر از سیستم فعلی خودشون نیست.
اینجا بود که مشخص شد باید یه فریمورک مخصوص خودشون بسازن که با نیازهای منحصر به فردشون سازگار باشه. اینطوری بود که Jetflow متولد شد.
فصل دوم: Jetflow چه کرد؟ نگاهی به دستاوردها
خب، حالا که فهمیدیم Jetflow چرا به وجود اومد، ببینیم نتیجه کار چی شد و چه دستاوردهایی داشت.
بهبود بهرهوری تا بیش از ۱۰۰ برابر: برای اینکه بهتر متوجه بشی این عدد یعنی چی، به این مثال دقت کن. طولانیترین کار پردازشی اونها مربوط به یک جدول ۱۹ میلیارد ردیفی بود. این کار قبلا ۴۸ ساعت طول میکشید و ۳۰۰ گیگابایت حافظه مصرف میکرد. اما با Jetflow، همین کار حالا توی ۵.۵ ساعت و فقط با ۴ گیگابایت حافظه انجام میشه. این یک بهبود فوقالعاده در مصرف منابع به حساب میاد.
هزینه خیلی پایین: تیم کلودفلر تخمین میزنه که انتقال ۵۰ ترابایت دیتا از دیتابیس Postgres با استفاده از Jetflow، بر اساس قیمتهای ارائه شده توسط سرویسدهندههای ابری تجاری، میتونه کمتر از ۱۰۰ دلار هزینه داشته باشه.
بهبود عملکرد تا بیش از ۱۰ برابر: بزرگترین مجموعه دیتای اونها قبلا با سرعت ۶۰ تا ۸۰ هزار ردیف در ثانیه منتقل میشد. این سرعت با Jetflow به ۲ تا ۵ میلیون ردیف در ثانیه برای هر اتصال دیتابیس رسیده. نکته جالب اینه که این اعداد برای بعضی دیتابیسها با افزایش تعداد اتصالها، بهتر هم میشه و مقیاسپذیری خوبی داره.
توسعهپذیری (Extensibility): طراحی Jetflow ماژولار هست، یعنی از قطعههای جدا از هم تشکیل شده. این ویژگی باعث میشه اضافه کردن قابلیتهای جدید و تست کردن سیستم خیلی راحت باشه. امروز Jetflow با سیستمهای مختلفی مثل ClickHouse، Postgres، Kafka، خیلی از API های نرمافزارهای خدماتی (SaaS)، Google BigQuery و خیلیهای دیگه کار میکنه و انعطافپذیری خودش رو در کاربردهای جدید هم حفظ کرده.
فصل سوم: نقشه راه ساخت Jetflow، چه چیزهایی مهم بود؟
برای طراحی یه فریمورک جدید، اولین قدم اینه که دقیقا بدونی چه مشکلاتی رو میخوای حل کنی. تیم کلودفلر چند تا نیازمندی اصلی رو مشخص کرد تا مطمئن بشه راهکار جدیدشون مشکلات جدیدی درست نمیکنه.
عملکرد بالا و بهینه (Performant & Efficient): اونها باید دیتای بیشتری رو در زمان کمتری جابجا میکردن. بعضی از کارهای انتقال دیتا حدود ۲۴ ساعت طول میکشید و حجم دیتا هم که روز به روز در حال افزایش بود. راهکار جدید باید دیتا رو به صورت جریانی (streaming) منتقل میکرد و حافظه و منابع پردازشی کمتری نسبت به راهکار قبلی مصرف میکرد.
سازگاری با سیستمهای قدیمی (Backwards Compatible): با توجه به اینکه هزاران جدول هر روز در حال انتقال بودن، نمیشد همه چیز رو یک دفعه عوض کرد. راهکار جدید باید اجازه میداد که جدولها به صورت جداگانه و در صورت نیاز به سیستم جدید منتقل بشن. از طرفی، اونها در مراحل بعدی کار از ابزاری به اسم Spark استفاده میکنن و اسپارک برای ادغام فایلهای Parquet با ساختارهای (schema) متفاوت محدودیتهایی داره. پس راهکار جدید باید این انعطاف رو میداشت که دقیقا همون ساختار مورد نیاز برای سازگاری با سیستم قدیمی رو تولید کنه. همچنین، باید با سیستم متادیتای سفارشی خودشون که برای چک کردن وابستگیها و وضعیت کارها استفاده میشد، به صورت یکپارچه کار میکرد.
سادگی در استفاده (Ease of Use): تیم میخواست که تنظیمات در یک فایل کانفیگ قابل مدیریت باشه (چیزی که بهش میگن configuration as code). اینطوری میتونن تاریخچه تغییرات رو دنبال کنن. یه نیاز دیگه این بود که در اکثر موارد، کار با سیستم بدون نیاز به کدنویسی (no-code) باشه تا افراد با نقشهای مختلف در تیم بتونن ازش استفاده کنن. کاربرها نباید نگران مواردی مثل در دسترس بودن یا تبدیل انواع دیتا بین سیستم مبدا و مقصد باشن یا برای هر انتقال جدید، کد جدیدی بنویسن. تنظیمات هم باید حداقل ممکن باشه. برای مثال، ساختار دیتا (schema) باید به صورت خودکار از سیستم مبدا تشخیص داده بشه و نیازی نباشه کاربر اون رو دستی وارد کنه.
قابلیت شخصیسازی (Customizable): در کنار ساده بودن، باید این گزینه هم وجود داشت که در صورت نیاز بشه تنظیمات رو تغییر داد و شخصیسازی کرد. مثلا، نوشتن فایلهای Parquet معمولا هزینه بیشتری نسبت به خوندن از دیتابیس داره. پس باید این قابلیت وجود داشته باشه که بشه منابع و همزمانی بیشتری رو به این بخش اختصاص داد. علاوه بر این، میخواستن کنترل کاملی روی محل اجرای کار داشته باشن. یعنی بتونن کارگرهای (worker) همزمانی رو در تردها، کانتینرها یا حتی ماشینهای مختلف اجرا کنن. اجرای این کارگرها و ارتباط بینشون از طریق یک رابط (interface) مدیریت میشد تا بشه پیادهسازیهای مختلفی رو با تغییر در تنظیمات کار، به سیستم تزریق کرد.
قابلیت تست (Testable): اونها دنبال راهکاری بودن که بشه اون رو به صورت محلی (locally) در یک محیط کانتینری اجرا کرد. اینطوری میتونستن برای هر مرحله از خط لوله (pipeline) تست بنویسن. در راهکارهای «جعبه سیاه» یا black box، تست کردن معمولا به معنی چک کردن خروجی بعد از یک تغییره که این فرآیند کندی هست و ریسک بالایی داره، چون ممکنه همه حالتهای خاص تست نشن و پیدا کردن مشکل هم خیلی سخت میشه.
فصل چهارم: معماری Jetflow، چطور همه چیز کنار هم کار میکنه؟
برای ساختن یه فریمورک واقعا منعطف، تیم کلودفلر کل فرآیند رو به چند مرحله مشخص تقسیم کرد و بعد یک لایه تنظیمات (config layer) ساخت تا ترکیب این مراحل رو تعریف کنه. بریم ببینیم این معماری چطوریه.
بخش اول: مراحل خط لوله (Pipeline Stages)
ایده اصلی این بود که فرآیند انتقال دیتا به سه دسته اصلی از مراحل تقسیم بشه:
مصرفکنندهها (Consumers): اینها نقطه شروع خط لوله هستن. وظیفهشون ایجاد یک جریان دیتاست، مثلا با خوندن دیتا از سیستم مبدا.
تبدیلکنندهها (Transformers): این مراحل یک جریان دیتا رو به عنوان ورودی میگیرن و یک جریان دیتای دیگه رو به عنوان خروجی تحویل میدن. کارشون میتونه تبدیل دیتا، اعتبارسنجی و کارهایی از این قبیل باشه. خوبیشون اینه که میشه اونها رو به صورت زنجیروار پشت سر هم قرار داد.
بارگذارها (Loaders): اینها هم مثل بقیه، یک جریان دیتا رو به عنوان ورودی میگیرن اما نقطه پایان خط لوله هستن. یعنی جایی که دیتا در یک سیستم خارجی ذخیره میشه و اثر دائمی داره.
کل خط لوله از طریق یک فایل YAML تنظیم میشه. در این فایل باید حداقل یک مصرفکننده، صفر یا چند تبدیلکننده، و حداقل یک بارگذار تعریف بشه. این طراحی ماژولار باعث میشه هر مرحله به صورت مستقل قابل تست باشه و رفتارهای مشترک مثل مدیریت خطا و همزمانی، از کلاسهای پایه به ارث برده بشن. این موضوع زمان توسعه رو خیلی کم میکنه و اطمینان به درستی کد رو بالا میبره.
بخش دوم: تقسیمبندی دیتا برای پردازش موازی
قدم بعدی، طراحی یک سیستم برای تقسیمبندی دیتا بود. این سیستم باید طوری کار میکرد که اگر کل خط لوله یا بخشی از اون به خاطر یک خطای موقتی دوباره اجرا شد، نتیجه نهایی درست باشه و دیتای تکراری ایجاد نشه. به این ویژگی Idempotency میگن. اونها به یک طراحی رسیدن که اجازه پردازش موازی رو میده و در عین حال، تقسیمبندی معناداری از دیتا ارائه میکنه. این تقسیمبندی سه سطح داره:
RunInstance: این بزرگترین واحد تقسیمبندی هست و به یک واحد کاری برای یک بار اجرای کامل خط لوله اشاره داره (مثلا دیتای یک ماه، یک روز یا یک ساعت).
Partition: این یک بخش از RunInstance هست. هر ردیف از دیتا به صورت قطعی و بر اساس خود دیتا (بدون نیاز به اطلاعات خارجی) به یک پارتیشن اختصاص داده میشه. این ویژگی باعث میشه در صورت اجرای مجدد، همه چیز درست پیش بره (مثلا پارتیشنی شامل اکانتهای با شناسه ۰ تا ۵۰۰).
Batch: این یک تقسیمبندی کوچکتر و غیرقطعی از دیتاهای یک پارتیشن هست. فقط برای این استفاده میشه که دیتا به تکههای کوچکتر تقسیم بشه تا پردازش سریعتر و با منابع کمتری انجام بشه (مثلا هر ۱۰ هزار ردیف یا هر ۵۰ مگابایت).
تنظیماتی که کاربر در فایل YAML برای مصرفکننده مشخص میکنه، هم کوئری لازم برای گرفتن دیتا از مبدا رو میسازه و هم معنی این تقسیمبندیها رو به صورت مستقل از سیستم کدگذاری میکنه. اینطوری مراحل بعدی خط لوله میفهمن که مثلا «این پارتیشن شامل دیتای اکانتهای ۰ تا ۵۰۰ هست». این قابلیت بهشون اجازه میده در صورت خطا، فقط همون بخش مشکلدار رو پاکسازی و دوباره پردازش کنن و از ایجاد دیتای تکراری جلوگیری بشه.
بخش سوم: فرمت داخلی استاندارد، زبان مشترک مراحل
یکی از رایجترین کاربردهای Jetflow اینه که دیتا رو از یک دیتابیس بخونه، اون رو به فرمت Parquet تبدیل کنه و بعد در یک فضای ذخیرهسازی ابری (object storage) ذخیره کنه. هر کدوم از این کارها یک مرحله جداگانه هست. با اضافه شدن کاربردهای جدید، باید مطمئن میشدن که اگر کسی یک مرحله جدید نوشت، با بقیه مراحل سازگار باشه. اونها نمیخواستن به وضعیتی برسن که برای هر فرمت خروجی و سیستم مقصد، کد جدیدی بنویسن.
راه حل این مشکل این بود که کلاس استخراجکننده (extractor) دیتا فقط اجازه خروجی دادن دیتا در یک فرمت واحد رو داشته باشه. این فرمت واحد، زبان مشترک بین همه مراحل شد. اینطوری، تا زمانی که مراحل بعدی این فرمت رو به عنوان ورودی پشتیبانی کنن، با بقیه خط لوله سازگار خواهند بود. این ایده شاید الان واضح به نظر برسه، اما تیم کلودفلر میگه این یک تجربه دردناک برای اونها بود، چون در ابتدا یک سیستم تایپ سفارشی ساخته بودن و با مشکلات سازگاری بین مراحل دست و پنجه نرم میکردن.
برای این فرمت داخلی، اونها Arrow رو انتخاب کردن که یک فرمت دیتای ستونیِ در حافظه (in-memory columnar data format) هست. مزایای کلیدی Arrow برای اونها این موارد بود:
اکوسیستم Arrow: خیلی از پروژههای مرتبط با دیتا الان از Arrow به عنوان فرمت خروجی پشتیبانی میکنن. این یعنی وقتی برای یک منبع دیتای جدید مرحله استخراجکننده مینویسن، تولید خروجی Arrow معمولا کار سادهای هست.
بدون سربار سریالسازی (No serialisation overhead): این ویژگی باعث میشه انتقال دیتای Arrow بین ماشینهای مختلف یا حتی زبانهای برنامهنویسی متفاوت با حداقل سربار انجام بشه. از اونجایی که Jetflow طوری طراحی شده که بتونه در سیستمهای مختلفی اجرا بشه، این بهینگی در انتقال دیتا خیلی مهمه.
رزرو حافظه در بستههای بزرگ و با اندازه ثابت: زبان برنامهنویسی Go که Jetflow با اون نوشته شده، یک زبان دارای Garbage Collector (GC) هست. زمان چرخه GC بیشتر به تعداد آبجکتها بستگی داره تا اندازه اونها. اگر آبجکتهای کمتری در حافظه داشته باشیم، حتی اگه حجم کل دیتا یکی باشه، زمان پردازش برای پاکسازی حافظه به شدت کم میشه. بذار اینطوری بگم: فرض کن ۸۱۹۲ ردیف دیتا با ۱۰ ستون داری. در حالت عادی، درایورهای دیتابیس برای هر ردیف یک آبجکت در حافظه میسازن که میشه ۸۱۹۲ آبجکت. اما با Arrow، فقط برای هر ستون یک آبجکت ساخته میشه، یعنی ۱۰ آبجکت. این تفاوت بزرگ باعث میشه زمان چرخه GC خیلی کمتر بشه.
بخش چهارم: تبدیل ردیف به ستون، یک بهینهسازی مهم
یک بهینهسازی عملکردی مهم دیگه، کم کردن تعداد مراحل تبدیل دیتا بود. اکثر فریمورکهای انتقال دیتا، دیتا رو به صورت داخلی به شکل ردیفی (rows) نمایش میدن. اما در مورد Jetflow، دیتا عمدتا در فرمت Parquet نوشته میشه که یک فرمت ستونی (columns) هست.
وقتی دیتا از یک منبع ستونی (مثل ClickHouse) خونده میشه، تبدیل اون به یک نمایش ردیفی در حافظه کار بهینهای نیست. بعدا دوباره این دیتای ردیفی باید به ستونی تبدیل بشه تا فایل Parquet نوشته بشه. این تبدیلهای اضافه تاثیر منفی زیادی روی عملکرد دارن.
Jetflow به جای این کار، دیتا رو از منابع ستونی مستقیما در فرمت ستونی میخونه (مثلا فرمت Block در ClickHouse) و اون رو مستقیما در فرمت ستونی Arrow کپی میکنه. بعد فایلهای Parquet مستقیما از روی ستونهای Arrow نوشته میشن. این سادهسازی فرآیند، عملکرد رو به شدت بهبود میده.
فصل پنجم: پیادهسازی در عمل، دو مطالعه موردی
حالا بریم ببینیم این طراحیها در عمل چطور پیاده شدن. دو تا مثال از دیتابیسهای ClickHouse و Postgres رو بررسی میکنیم.
مطالعه موردی: ClickHouse
وقتی نسخه اولیه Jetflow رو تست میکردن، متوجه شدن که به خاطر معماری ClickHouse، استفاده از اتصالهای بیشتر هیچ فایدهای نداره، چون ClickHouse سریعتر از چیزی که اونها دیتا رو دریافت میکردن، میخوند. این یعنی مشکل از درایور دیتابیس بود. باید میشد با یک درایور بهینهتر، از همون یک اتصال استفاده بهتری کرد و تعداد ردیفهای خیلی بیشتری رو در ثانیه خوند.
اونها اول یک درایور سفارشی برای ClickHouse نوشتن، اما در نهایت به استفاده از کتابخانه سطح پایین و عالی ch-go رو آوردن. این کتابخانه مستقیما Block ها رو از ClickHouse به صورت ستونی میخونه. این تغییر یک تاثیر شگفتانگیز روی عملکرد داشت. با ترکیب این درایور و بهینهسازیهای خود فریمورک، اونها حالا با یک اتصال ClickHouse، میلیونها ردیف در ثانیه رو منتقل میکنن.
یک درس مهمی که گرفتن این بود که درایورهای دیتابیس استاندارد معمولا برای خواندن دستهای و حجیم دیتا بهینه نشدن و برای هر ردیف سربار بالایی دارن.
مطالعه موردی: Postgres
برای Postgres، اونها از درایور عالی jackc/pgx استفاده کردن، اما به جای استفاده از رابط استاندارد `database/sql` در زبان Go، مستقیما بایتهای خام هر ردیف رو دریافت میکنن و از توابع داخلی خود jackc/pgx برای اسکن کردن هر نوع دیتا استفاده میکنن.
رابط استاندارد `database/sql` در Go از تکنیکی به اسم reflection استفاده میکنه تا نوع دیتا رو بفهمه و مقدار ستون رو در فیلد مربوطه قرار بده. این روش در سناریوهای عادی به اندازه کافی سریع و سادهاس، اما برای کاربردهای سنگین کلودفلر از نظر عملکردی ضعیف بود. اما درایور jackc/pgx بایتهای ردیف رو در هر بار درخواست ردیف بعدی، دوباره استفاده میکنه که نتیجهاش صفر تخصیص حافظه برای هر ردیف (zero allocations per row) هست. این طراحی به اونها اجازه داد کدی با عملکرد بالا و تخصیص حافظه کم بنویسن.
با این طراحی، اونها تونستن برای اکثر جدولها به سرعت نزدیک به ۶۰۰ هزار ردیف در ثانیه برای هر اتصال Postgres برسن، اون هم با مصرف حافظه خیلی کم.
وضعیت فعلی و آینده Jetflow
تا اوایل جولای ۲۰۲۵، این تیم روزانه ۷۷ میلیارد رکورد رو از طریق Jetflow منتقل میکنه. بقیه کارها هم در حال انتقال به Jetflow هستن که در نهایت مجموع انتقال روزانه رو به ۱۴۱ میلیارد رکورد میرسونه. این فریمورک به اونها اجازه داده جدولهایی رو منتقل کنن که قبلا امکانش وجود نداشت و به خاطر کاهش زمان اجرا و مصرف کمتر منابع، صرفهجویی قابل توجهی در هزینهها ایجاد کرده.
در آینده، کلودفلر قصد داره این پروژه رو به صورت متنباز (open source) منتشر کنه. اونها همچنین اشاره کردن که اگر کسی علاقهمند به کار روی چنین ابزارهایی هست، میتونه موقعیتهای شغلی باز رو در وبسایتشون به آدرس https://www.cloudflare.com/careers/jobs/ پیدا کنه.
نام درس: آشنایی کامل با تکنولوژی 5G و کاربردهای آن
مدت زمان مطالعه: حدود ۲۵ دقیقه
پیشنیازها: آشنایی اولیه با مفاهیم اینترنت و موبایل (در حد کاربری عمومی)
سطح درس: مقدماتی تا متوسط
اهداف درس:
یاد بگیری 5G دقیقا چیه و چه فرقی با نسلهای قبلی مثل 4G داره.
بفهمی این تکنولوژی چطوری کار میکنه و چه چیزهایی باعث میشه اینقدر سریع و قوی باشه.
با کاربردهای مختلف 5G در زندگی روزمره، صنعت، پزشکی و حتی حوزه نظامی آشنا بشی.
اطلاعات کاملی در مورد پلنهای اینترنت خانگی 5G و گزینههای موجود به دست بیاری.
به جواب سوالات پرتکرار در مورد 5G برسی.
مقدمه: چرا همه جا حرف از 5G است؟
احتمالا تو هم این روزها زیاد کلمه «5G» رو میشنوی. روی گوشیهای جدید، توی تبلیغات اپراتورها، و حتی توی فیلمها و سریالها. انگار یهو همه جا رو گرفته. اما 5G واقعا چیه؟ فقط یه اینترنت سریعتره یا داستان بزرگتر از این حرفهاست؟ اگه بخوایم ساده بگیم، 5G نسل پنجم تکنولوژی شبکههای سلولی یا همون شبکههای موبایله. اما این یه آپدیت ساده مثل آپدیتهای نرمافزاری گوشی نیست. این یه جهش بزرگه، یه انقلاب که قراره نحوه اتصال ما به دنیای دیجیتال رو کاملا تغییر بده.
فکر کن داری وسط یه میدون جنگی و هر ثانیه مهمه. یه سرباز داره از یه پایگاه استراتژیک دفاع میکنه که برای ماموریتشون حیاتیه. ناگهان، دشمن یه موشک هایپرسونیک به سمت پایگاه شلیک میکنه. آیا اونها آماده خواهند بود؟ این سناریو شاید خیلی دور از ذهن به نظر برسه، اما تکنولوژیهایی مثل 5G دقیقا برای مدیریت همین سطح از اطلاعات و سرعت واکنش طراحی شدن. این تکنولوژی فقط برای دانلود سریعتر ویدیوهای گربهها نیست، بلکه برای ساختن یه دنیای فوقمتصل طراحی شده که توش ماشینها، شهرها، کارخونهها و حتی تجهیزات نظامی بتونن به صورت لحظهای با هم حرف بزنن.
تو این مقاله میخوایم با هم سفری به دنیای 5G داشته باشیم. از زیر و بم کارکردش گرفته تا کاربردهای عجیب و غریبی که شاید حتی به ذهنت هم نرسه. میخوایم ببینیم این تکنولوژی چطوری کار میکنه، چه شرکتهایی پشتش هستن، چه تاثیری روی زندگی ما میذاره و در نهایت، چطوری میتونی ازش استفاده کنی. پس آماده شو که قراره یک راست بریم سر اصل مطلب و ببینیم این غول جدید دنیای تکنولوژی چیه و چیکار میکنه.
فصل اول: 5G دقیقا چیست؟ سفری در زمان از 1G تا 5G
برای اینکه بفهمیم 5G چقدر مهمه، بهتره یه نگاهی به گذشته بندازیم و ببینیم از کجا به اینجا رسیدیم. هر نسل از شبکههای موبایل، یه قابلیت جدید و مهم رو به زندگی ما اضافه کرده.
1G (دهه ۱۹۸۰): این نسل، شروع ماجرا بود. شبکههای آنالوگ که فقط برای یه کار طراحی شده بودن: تماس صوتی. با این تکنولوژی برای اولین بار تونستیم بدون سیم با هم حرف بزنیم و موبایل باشیم. سرعتش؟ در حد چند کیلوبیت بر ثانیه. هیچ رمزنگاری و امنیتی هم در کار نبود.
2G (دهه ۱۹۹۰): اینجا بود که دنیا دیجیتالی شد. با نسل دوم، علاوهبر تماس صوتی با کیفیتتر، یه قابلیت انقلابی به اسم پیامک یا SMS به وجود اومد. امنیت بهتر شد و برای اولین بار میتونستیم با سرویس رومینگ، توی سفرهامون هم از موبایل استفاده کنیم. سرعتش به حدود ۶۴ کیلوبیت بر ثانیه رسید. اگه میخواستی یه آهنگ ۳ دقیقهای رو دانلود کنی، بیشتر از ۲۰ دقیقه طول میکشید.
3G (دهه ۲۰۰۰): این نسل، اینترنت رو به گوشیهای ما آورد. سرعت از ۳۸۴ کیلوبیت تا ۲ مگابیت بر ثانیه رسید. حالا میشد وبگردی کرد، ایمیل فرستاد و ویدیوهای ساده رو دید. هرچند که تجربه خیلی روانی نبود، اما یه قدم بزرگ رو به جلو بود و باعث شد اکوسیستم اپلیکیشنهای موبایل شکل بگیره.
4G/LTE (دهه ۲۰۱۰): این نسل، نقطه عطف بود. با 4G و نسخه پیشرفتهترش یعنی LTE، اینترنت موبایل به معنای واقعی کلمه کاربردی شد. سرعتهای تئوری به ۱۰۰ مگابیت بر ثانیه و حتی ۱ گیگابیت بر ثانیه رسید. حالا میتونستیم ویدیوهای HD استریم کنیم، بازیهای آنلاین انجام بدیم و تماس تصویری با کیفیت داشته باشیم. دانلود یه فیلم HD با 3G حدود ۲۶ ساعت طول میکشید، اما با 4G این زمان به ۶ دقیقه کاهش پیدا کرد.
و حالا رسیدیم به 5G. نسل پنجم یه آپگرید ساده روی 4G نیست. یه زیربنای کاملا جدیده که برای اهداف خیلی بزرگتری طراحی شده.
مشخصات فنی 5G: اعداد چه میگویند؟
5G یه پیشرفت چشمگیره که بر اساس ۸ تا نیازمندی اصلی تعریف شده. این مشخصات به ما نشون میدن که چرا این نسل اینقدر متفاوته:
سرعت داده تا 10 گیگابیت بر ثانیه: این یعنی ۱۰ تا ۱۰۰ برابر سریعتر از شبکههای 4G و 4.5G. برای اینکه درکش کنی، فکر کن یه فیلم HD کامل که با 4G دانلودش ۶ دقیقه طول میکشید، با 5G فقط ۳.۶ ثانیه زمان میبره. سرعت تئوری نهایی حتی به ۲۰ گیگابیت بر ثانیه هم میرسه.
تاخیر ۱ میلیثانیه: تاخیر یا Latency یعنی مدت زمانی که طول میکشه یه داده از دستگاه تو ارسال بشه و جوابش برگرده. توی 4G این عدد بین ۲۰ تا ۷۰ میلیثانیه بود. توی 5G این عدد به ۱ میلیثانیه میرسه. این یعنی واکنش تقریبا لحظهای. برای مقایسه، متوسط زمان واکنش یه انسان به یه محرک بصری ۲۵۰ میلیثانیه است. یعنی 5G میتونه ۲۵۰ برابر سریعتر از تو واکنش نشون بده.
پهنای باند ۱۰۰۰ برابر در هر واحد مساحت: این یعنی توی یه منطقه مشخص، 5G میتونه حجم داده هزار برابر بیشتری رو نسبت به 4G جابجا کنه.
تا ۱۰۰ برابر دستگاه متصل بیشتر در هر واحد مساحت: 4G توی مکانهای شلوغ مثل استادیوم یا کنسرت به مشکل میخورد. 5G طراحی شده تا بتونه ۱ میلیون دستگاه رو در هر کیلومتر مربع بدون افت کیفیت پشتیبانی کنه.
در دسترس بودن 99.999%: این یعنی شبکه تقریبا هیچوقت قطع نمیشه و همیشه قابل اطمینانه. این ویژگی برای کاربردهای حساس مثل جراحی از راه دور یا ماشینهای خودران حیاتیه.
پوشش ۱۰۰ درصدی: هدف 5G اینه که همه جا، حتی مناطق دورافتاده، رو تحت پوشش قرار بده.
کاهش ۹۰ درصدی مصرف انرژی شبکه: با وجود قدرت بسیار بیشتر، زیرساختهای 5G طوری طراحی شدن که انرژی خیلی کمتری مصرف کنن.
عمر باتری تا ۱۰ سال برای دستگاههای اینترنت اشیا کممصرف (IoT): سنسورها و دستگاههای کوچیکی که نیاز به ارسال حجم کمی از داده دارن، میتونن با یه باتری تا ۱۰ سال کار کنن.
این مشخصات نشون میده که 5G فقط روی سرعت تمرکز نکرده. این نسل برای اینترنت اشیا (IoT)، ارتباطات حساس و حیاتی و ساختن یه دنیای کاملا متصل طراحی شده. جایی که قبلا نسلهای قبلی آدمها رو به هم وصل میکردن، 5G قراره کل دنیا رو به هم وصل کنه.
فصل دوم: 5G چطور کار میکند؟ نگاهی به تکنولوژیهای پشت پرده
خب، حالا که فهمیدیم 5G چه قولهایی به ما داده، وقتشه ببینیم این قولها چطوری عملی میشن. 5G برای رسیدن به اون سرعت و قدرت فوقالعاده، از یه سری تکنولوژیهای پیشرفته و جدید استفاده میکنه که در ادامه باهاشون آشنا میشیم.
۱. امواج رادیویی جدید: Sub-6 GHz و mmWave
یکی از دلایل اصلی سرعت بالای 5G، استفاده از طیفهای فرکانسی جدیده. به طور کلی، هرچی فرکانس موج رادیویی بالاتر بره، پهنای باند بیشتری در اختیار ما میذاره و در نتیجه دادههای بیشتری رو میشه باهاش جابجا کرد. 5G از دو دسته اصلی فرکانس استفاده میکنه:
Sub-6 GHz (فرکانسهای زیر ۶ گیگاهرتز): این فرکانسها شبیه فرکانسهایی هستن که 4G ازشون استفاده میکرد، اما بهینهتر شدن. برد این امواج زیاده و میتونن از دیوارها و موانع عبور کنن. برای همین برای پوششدهی گسترده، مخصوصا توی مناطق روستایی و حومه شهرها، ایدهآل هستن. این همون 5Gایه که پوشش وسیعتری داره ولی سرعتش یه پیشرفت منطقی نسبت به 4G محسوب میشه، نه یه جهش انقلابی.
mmWave (موج میلیمتری): اینجاست که جادوی 5G اتفاق میفته. این امواج در فرکانسهای بسیار بالا (بین ۲۴ تا ۱۰۰ گیگاهرتز) کار میکنن. پهنای باند این امواج فوقالعاده زیاده و سرعتهای چند گیگابیتی رو ممکن میکنن. اما یه ایراد بزرگ دارن: بردشون خیلی کوتاهه (حدود چند صد متر) و نمیتونن از موانع ساده مثل دیوار، شیشه، و حتی برگ درختها و لباس آدمها به راحتی عبور کنن. برای همین، از این تکنولوژی بیشتر در مناطق خیلی شلوغ و پرجمعیت مثل مراکز شهرها، استادیومها و فرودگاهها استفاده میشه.
۲. شبکهای از برجهای کوچک: Small Cells
برای حل مشکل برد کوتاه امواج mmWave، اپراتورها به جای استفاده از دکلهای بزرگ و سنتی، از تعداد زیادی ایستگاه پایه کوچک و فشرده به اسم «Small Cells» یا سلولهای کوچک استفاده میکنن. این ایستگاههای کوچک رو میشه روی تیرهای چراغ برق، پشتبوم ساختمونها و دکلهای برق نصب کرد. این کار باعث میشه پوششدهی در مناطق پرتراکم همیشه باکیفیت و قوی باقی بمونه و ظرفیت شبکه به شدت بالا بره.
۳. آنتنهای هوشمند: Massive MIMO
MIMO مخفف «Multiple Input, Multiple Output» به معنی «چند ورودی، چند خروجی» است. این تکنولوژی یعنی استفاده از چندین آنتن برای ارسال و دریافت همزمان چندین جریان داده. 5G این تکنولوژی رو به سطح جدیدی به اسم Massive MIMO رسونده. یعنی به جای چند آنتن، از دهها یا حتی صدها آنتن کوچک در هر ایستگاه پایه استفاده میشه. این کار ظرفیت شبکه رو به طرز چشمگیری افزایش میده و باعث میشه دستگاههای خیلی بیشتری بتونن همزمان و بدون افت سرعت به شبکه وصل بشن.
۴. تمرکز روی شما: Beamforming
این تکنولوژی یه جورایی مکمّل Massive MIMO هست. به جای اینکه سیگنال رادیویی به صورت عمومی و در همه جهات پخش بشه (مثل یه لامپ معمولی)، Beamforming سیگنال رو مثل یه لیزر، مستقیما به سمت دستگاه کاربر متمرکز میکنه. این کار باعث میشه سیگنال قویتر به دست کاربر برسه، تداخل با دستگاههای دیگه کمتر بشه و انرژی هم بهینهتر مصرف بشه.
۵. تقسیم بهینه فرکانس: OFDMA
OFDMA یا «Orthogonal Frequency-Division Multiple Access» یه تکنیک پیشرفته برای بهینهسازی استفاده از طیف فرکانسیه. این تکنولوژی طیف فرکانسی رو به کانالهای فرعی خیلی کوچیک تقسیم میکنه. این کار اجازه میده که چندین کاربر بتونن به صورت همزمان از یک کانال استفاده کنن و دادههاشون به صورت موازی ارسال بشه. این ویژگی باعث میشه حتی وقتی شبکه خیلی شلوغه، انتقال داده به صورت بهینه انجام بشه.
۶. شبکههای مجازی روی یک زیرساخت: Network Slicing
این یکی از انقلابیترین ویژگیهای 5G هست. Network Slicing یا «برشدهی شبکه» به اپراتورها اجازه میده که روی یک زیرساخت فیزیکی مشترک، چندین شبکه مجازی مستقل و ایزوله ایجاد کنن. هر کدوم از این «برشها» یا «Slices» میتونه برای یه کاربرد خاص با نیازمندیهای متفاوت تنظیم بشه.
برای مثال:
یک برش برای ماشینهای خودران: با تاخیر فوقالعاده کم و قابلیت اطمینان بسیار بالا.
یک برش برای استریم ویدیوی 8K: با پهنای باند بسیار زیاد.
یک برش برای سنسورهای IoT: با مصرف انرژی خیلی کم و قابلیت اتصال تعداد زیادی دستگاه.
این قابلیت به اپراتورها اجازه میده که هزینههای شبکه رو با نیازهای واقعی هر کاربرد هماهنگ کنن و سرویسهای خیلی متنوعتری ارائه بدن.
۷. پردازش در لبه شبکه: Edge Computing
برای اینکه تاخیر به حداقل ممکن برسه، 5G از مفهومی به اسم Edge Computing یا «پردازش لبه» استفاده میکنه. به جای اینکه دادهها برای پردازش به یه دیتاسنتر مرکزی در فاصلهای دور فرستاده بشن، این کار در دیتاسنterهای محلی و کوچکی که به کاربر نزدیکتر هستن انجام میشه. این رویکرد نه تنها زمان پاسخدهی رو به شدت کم میکنه، بلکه بار روی سرورهای مرکزی رو هم کاهش میده و کارایی کل شبکه رو بالا میبره.
این هفت تکنولوژی در کنار هم، معماری قدرتمند 5G رو میسازن که میتونه به قولهایی که در فصل قبل در موردش صحبت کردیم، عمل کنه.
فصل سوم: انواع 5G و معانی علامتهای روی گوشی
وقتی گوشی شما به 5G وصل میشه، ممکنه علامتهای مختلفی مثل «5G»، «5G+»، «5G UW» یا «5G UC» رو در نوار وضعیت ببینید. این علامتها گیجکننده به نظر میرسن، اما در واقع دارن به شما میگن که به چه نوعی از شبکه 5G وصل شدید. این تفاوتها از اونجایی میاد که اپراتورهای مختلف از استراتژیهای متفاوتی برای پیادهسازی 5G استفاده میکنن. بیاید این طبقهبندیها رو با هم بررسی کنیم.
به طور کلی، 5G بر اساس باندی که ازش استفاده میکنه به سه دسته اصلی تقسیم میشه:
5G باند-پایین (Low-band 5G): این نوع 5G از فرکانسهای زیر ۱ گیگاهرتز استفاده میکنه. بزرگترین مزیتش پوششدهی بسیار وسیع و نفوذ خوب در ساختمونهاست. این همون شبکهایه که اپراتورها ازش برای ایجاد پوشش «سراسری» 5G استفاده میکنن. اما سرعتش تفاوت خیلی زیادی با 4G LTE نداره. در واقع، خیلی وقتا حس میکنی همون 4G هست با یه آیکون جدید. اگه روی گوشیت فقط علامت «5G» رو میبینی، به احتمال زیاد به این نوع شبکه وصلی.
5G باند-میانی (Mid-band 5G): این نوع 5G در فرکانسهای بین ۱ تا ۶ گیگاهرتز کار میکنه. این باند یه تعادل عالی بین سرعت، پوششدهی و ظرفیت ایجاد میکنه. سرعتش به طور قابل توجهی از 4G بیشتره و پوششدهی خوبی هم در مناطق شهری و حومه داره. این باند، ستون فقرات شبکههای 5G در اکثر کشورهای دنیاست و بهترین تجربه کاربری رو برای اکثر مردم فراهم میکنه. علامتهایی مثل «5G UC» (Ultra Capacity) یا «5G+» معمولا به این نوع شبکه اشاره دارن.
5G باند-بالا (High-band 5G یا mmWave): این همون 5G فوق سریعه که در فرکانسهای بالای ۲۴ گیگاهرتز کار میکنه. سرعتش میتونه به چند گیگابیت بر ثانیه برسه و تاخیرش نزدیک به صفره. اما همونطور که گفتیم، بردش خیلی کمه و به راحتی توسط موانع مسدود میشه. علامت «5G UW» (Ultra Wideband) معمولا به این نوع شبکه اشاره داره.
معنی علامتهای مختلف چیه؟
5G: این معمولا به معنی اتصال به شبکه 5G باند-پایین هست. پوشش وسیعی داره ولی افزایش سرعتش نسبت به 4G کمه.
5G UC (Ultra Capacity): این اصطلاح بیشتر توسط اپراتور T-Mobile استفاده میشه و به شبکه باند-میانی اونها اشاره داره. این شبکه تعادل خوبی بین سرعت و پوشش ارائه میده و سرعتش معمولا بین ۱۰۰ تا ۹۰۰ مگابیت بر ثانیه است.
5G UW (Ultra Wideband): این اصطلاح توسط Verizon استفاده میشه و به شبکههای باند-بالا (mmWave) و بخشی از شبکههای باند-میانی اونها اشاره داره. این سریعترین نوع 5G هست که میتونی تجربه کنی، اما پوشش خیلی محدودی داره.
5G+: این علامت توسط AT&T استفاده میشه و شبیه 5G UW، به شبکههای باند-بالا و باند-میانی این اپراتور اشاره میکنه.
نکته مهم: گاهی اوقات، مخصوصا در مورد شبکههای باند-پایین، گوشی شما ممکنه آیکون 5G رو نشون بده در حالی که عملا داره از زیرساخت 4G استفاده میکنه. این به خاطر وابستگی اولیه شبکههای 5G به 4G (که بهش حالت Non-Standalone میگن) و همچنین استراتژیهای بازاریابی اپراتورهاست. برای مثال، AT&T حتی شبکه 4G پیشرفته خودش رو «5G Evolution» یا «5G E» نامگذاری کرده بود که باعث سردرگمی زیادی شد.
پس دفعه بعدی که به آیکون 5G روی گوشیت نگاه کردی، یادت باشه که همه 5Gها مثل هم نیستن و تجربهات بسته به نوع شبکهای که بهش وصلی، میتونه خیلی متفاوت باشه.
فصل چهارم: کاربردهای واقعی 5G: دنیایی که در راه است
خب، تا اینجا با مشخصات فنی و نحوه کار 5G آشنا شدیم. اما این همه سرعت و قدرت قراره چه دردی از ما دوا کنه؟ کاربردهای واقعی 5G خیلی فراتر از سریعتر لود شدن اینستاگرامه. این تکنولوژی قراره زیربنای یه سری تحولات بزرگ در صنایع مختلف، دولتها و زندگی روزمره ما باشه. بیاید ببینیم تا سال ۲۰۲۵ و بعد از اون، 5G چه چیزهایی رو ممکن میکنه.
۱. تحول در کسبوکارها و صنعت (Industry 4.0)
5G داره نوآوری رو در تمام صنایع هدایت میکنه. کارخونهها، انبارها و کسبوکارها دارن به سمت هوشمند شدن میرن.
کارخانههای هوشمند: در کارخانههای امروزی، اتوماسیون به کنترلکنندههایی متکیه که به صورت فیزیکی روی دستگاهها نصب شدن. با 5G، این نظارت و کنترل میتونه به فضای ابری (Cloud) منتقل بشه. ماشینها میتونن به صورت لحظهای با هم ارتباط برقرار کنن و کل فرآیند تولید به صورت هوشمند و بهینه مدیریت بشه. این یعنی کاهش خطا، افزایش سرعت تولید و نگهداری پیشبینیکننده (Predictive Maintenance) که در اون، سنسورها قبل از خراب شدن یه قطعه، هشدار میدن.
لجستیک متصل: شرکتهای حملونقل میتونن به صورت لحظهای کالاها رو ردیابی کنن. با تحلیل دادهها، میشه تاخیرها رو پیشبینی و ازشون جلوگیری کرد. این یعنی زنجیره تامین بسیار بهینهتر و کارآمدتر.
رباتیک و اتوماسیون: صنایع خردهفروشی، بهداشت و درمان و تولید، به طور فزایندهای از رباتهای متصل به 5G برای افزایش کارایی و بهبود تجربه مشتری استفاده میکنن.
واقعیت افزوده (AR) در صنعت: کارگران کارخانهها میتونن با استفاده از عینکهای AR که به 5G وصل هستن، دستورالعملهای پیچیده رو به صورت مجازی ببینن و کارهای تخصصی رو بدون نیاز به حضور متخصص انجام بدن.
۲. دولتها و شهرهای هوشمند
دولتها از 5G برای مدیریت هوشمندانهتر شهرها استفاده میکنن و این اتفاق همین الان هم در حال رخ دادنه.
مدیریت ترافیک: شهرهای هوشمند با استفاده از سنسورهای متصل به 5G، جریان ترافیک رو تحلیل و بهینه میکنن که باعث کاهش ترافیک و آلودگی هوا در کلانشهرها میشه.
نظارت بر محیط زیست: سنسورهای اینترنت اشیا (IoT) میتونن کیفیت هوا و مصرف آب رو به صورت لحظهای ردیابی کنن و به پایداری محیط زیست کمک کنن.
خدمات اضطراری: 5G ارتباط بین تیمهای اورژانس، پلیس و آتشنشانی رو سریعتر و موثرتر میکنه. اونها میتونن ویدیوهای باکیفیت و دادههای حیاتی رو به صورت لحظهای با هم به اشتراک بذارن و جان انسانهای بیشتری رو نجات بدن.
۳. انقلاب در حوزه بهداشت و درمان (Healthcare)
5G داره حوزه پزشکی رو متحول میکنه.
پزشکی از راه دور (Telemedicine): مشاوره ویدیویی با کیفیت بالا و تشخیص بیماری از راه دور به لطف 5G به یه واقعیت روزمره تبدیل شده.
نظارت مداوم بر سلامت: دستگاههای پوشیدنی مثل ساعتهای هوشمند که به 5G وصل هستن، میتونن به طور مداوم وضعیت سلامت بیمار رو چک کنن و دادهها رو برای پزشک بفرستن. این کار به تشخیص زودهنگام بیماریها کمک زیادی میکنه.
جراحی از راه دور (Telesurgery): چیزی که قبلا فقط در فیلمهای علمی-تخیلی میدیدیم، حالا به لطف تاخیر بسیار کم و قابلیت اطمینان بالای 5G، داره به واقعیت نزدیک میشه. جراح میتونه از یک شهر دیگه، یه ربات جراح رو با دقت میلیمتری کنترل کنه.
۴. تجربههای فراگیر در سرگرمی و آموزش
5G داره دنیای سرگرمی و آموزش رو از این رو به اون رو میکنه.
واقعیت افزوده و مجازی (AR/VR): پلتفرمهای AR/VR به بخش اصلی صنعت خردهفروشی تبدیل شدن. اتاقهای پرو مجازی و نمایش سهبعدی محصولات، حالا در فروشگاههای بزرگ یه استاندارد محسوب میشه.
آموزش مجازی: کلاسهای درس مجازی مبتنی بر 5G، درسهای تعاملی رو برای بیش از ۲۰۰ میلیون دانشآموز در سراسر جهان فراهم میکنن و شکاف آموزشی در مناطق روستایی رو پر میکنن.
استریم 8K و بازیهای ابری: استریم ویدیو با کیفیت 8K بدون هیچ بافری و بازیهای کامپیوتری سنگین روی فضای ابری (Cloud Gaming) بدون هیچ لگی، به لطف 5G به یه تجربه روزمره تبدیل شدن. شما دیگه نیازی به کنسول بازی گرونقیمت ندارید، فقط یه اینترنت 5G کافیه.
۵. خودروهای خودران و متصل
خودروهای خودران در سال ۲۰۲۵ به لطف 5G به یک واقعیت تبدیل شدهاند.
ارتباط لحظهای (V2X): ارتباط لحظهای بین خودروها با یکدیگر (V2V) و با زیرساختهای جادهای مثل چراغهای راهنمایی (V2I)، ایمنی ترافیک رو در شهرهای هوشمند به شدت بالا برده.
کاهش تصادفات: خودروی شما میتونه ۲۵۰ برابر سریعتر از شما به خطر واکنش نشون بده. اگه با سرعت ۱۰۰ کیلومتر بر ساعت در حال حرکت باشید، فاصله واکنش شما حدود ۳۰ متره. اما برای یه ماشین متصل به 5G، این فاصله کمتر از ۳ سانتیمتره. این یعنی جلوگیری از هزاران تصادف. بر اساس گزارشها، بازار خودروهای خودران آمریکا تا سال ۲۰۳۰ به ۸۶ میلیارد دلار میرسه که بخش بزرگیش به خاطر پیشرفتهای 5G و هوش مصنوعیه.
۶. مزایا برای مصرفکننده عادی
برای ما که کاربر عادی هستیم، 5G یعنی:
دانلودهای فوری: دانلود یه فیلم کامل 8K در کمتر از ۱۰ ثانیه.
بازی بدون لگ: با تاخیر کمتر از ۱ میلیثانیه، تجربه بازیهای آنلاین کاملا روان و بدون تاخیر میشه.
اپلیکیشنهای AR جدید: اپلیکیشنهایی که خرید، سفر و یادگیری رو متحول میکنن. از پرو مجازی لباس گرفته تا برنامهریزی سفر به صورت سهبعدی.
اینها فقط چند نمونه از کاربردهایی هستن که 5G داره ممکن میکنه. این تکنولوژی یه زیربناست و نوآوریهای واقعی، اپلیکیشنها و سرویسهایی هستن که روی این زیربنا ساخته میشن و ما هنوز خیلیهاشون رو ندیدیم.
فصل پنجم: 5G در میدان نبرد: آشنایی با 5G.MIL® لاکهید مارتین
وقتی صحبت از 5G میشه، ذهن اکثر ما به سمت گوشیهای هوشمند و اینترنت سریعتر میره. اما این تکنولوژی یه روی دیگه هم داره که شاید کمتر شناخته شده باشه: کاربردهای نظامی و دفاعی. یکی از بازیگران اصلی در این حوزه، شرکت لاکهید مارتین (Lockheed Martin) با پلتفرم اختصاصی خودش به اسم 5G.MIL® هست. این بخش از مقاله به ما نشون میده که 5G چطور میتونه در پیچیدهترین و حساسترین محیطهای عملیاتی، یعنی میدان نبرد، به کار گرفته بشه.
ایده اصلی پشت 5G.MIL اینه که نیروهای نظامی در همه دامنهها – هوا، زمین، دریا، فضا و سایبر – بتونن به صورت یکپارچه و بدون وقفه با هم ارتباط داشته باشن و دادهها رو به اشتراک بذارن. این همون چیزیه که بهش میگن «عملیات همه-دامنهای» یا All-Domain Operations.
راهکارهای شبکه یکپارچه 5G.MIL®
راهکارهای 5G.MIL® لاکهید مارتین، قابلیتهای ارتباطی منسجم، پردازش لبه (edge processing) و شبکهسازی پیشرفته رو برای ایجاد اتصال پذیری مقاوم، امن و قابل همکاری فراهم میکنن. این سیستمها از معماری سیستمهای باز، دروازههای تاکتیکی (tactical gateways) و تکنولوژیهای تجاری تقویتشده استفاده میکنن تا شبکههای هیبریدی و همگرا ایجاد کنن. نتیجه نهایی اینه که مشتریان (که در اینجا وزارت دفاع هست) به اطلاعات حیاتی که برای جلوتر بودن از تهدیدات نیاز دارن، دسترسی یکپارچه داشته باشن.
اخیرا، لاکهید مارتین برای اولین بار شبکه هیبریدی 5G-Tactical Mesh خودش رو به صورت زنده در یک محیط چند-دامنهای نمایش داد. این یک قدم بزرگ برای اطمینان از دسترسی بدون وقفه وزارت دفاع به اطلاعات حیاتی بود.
چرا این موضوع مهمه؟
سیستمهای ارتباطی نسل بعد (Next G)، اتصال پذیری مطمئنتر، با توان عملیاتی بالاتر و تاخیر فوقالعاده کم رو فراهم میکنن. این ویژگیها برای دستگاهها و پلتفرمهای لبه شبکه، مثل سیستمهای خودران، حیاتیه تا بتونن از تمام قدرت هوش مصنوعی (AI) استفاده کنن. با ادغام این سیستمها با ارتباطات نظامی و لینکهای داده موجود، نیروها میتونن عملیات موثرتری در محیطهایی که ارتباطات در اونها با اختلال مواجه یا قطع شده، داشته باشن و در هر کجای دنیا به دادههای مورد نیاز برای انجام ماموریتشون دسترسی پیدا کنن.
لاکهید مارتین با استفاده از تجربه گسترده صنعتی، تخصص عمیق در ماموریتها و روابط استراتژیک با شرکتهای تجاری، در موقعیتی قرار داره که به مشتریانش کمک کنه تا این تکنولوژی رو به سرعت و با هزینه مناسب در تمام عملیات و دامنهها مستقر و مقیاسپذیر کنن.
ستونهای اصلی برنامه 5G.MIL®
این برنامه بر اساس چند ستون اصلی بنا شده:
ایجاد انسجام شبکه: در میدان نبرد قرن ۲۱، برتری با کسیه که بتونه پلتفرمهای پیشرفته رو در یک شبکه منسجم که تمام دامنهها رو در بر میگیره، متحد کنه. وقتی این شبکه به صورت یکپارچه ارتباط برقرار میکنه و دادهها رو تحلیل میکنه، به یک «نیروی چند برابر کننده» (force multiplier) تبدیل میشه که انعطافپذیر، قدرتمند و قاطع هست.
همکاری مرتبط: همکاری لاکهید مارتین و جونیپر نتورکس (Juniper Networks) در زمینه مسیریابی آگاه از ماموریت (Mission-Aware Routing SD-WAN).
ارتباطات مقاوم: سیستم 5G.MIL یک «شبکهای از شبکهها»ی ناهمگون (heterogenous) و قدرتمنده که تمام دامنههای جنگی رو در شبکههای تاکتیکی، استراتژیک و سازمانی نظامی ادغام میکنه و از تکنولوژی زیرساختهای مخابراتی تجاری بهره میبره. ارکستراسیون هوشمند، مدیریت داده و افزونگی (redundancy)، چابکی عملیاتی لازم برای حفظ ارتباطات در محیطهای مورد مناقشه رو فراهم میکنه.
تکنولوژی مرتبط:Lockheed Martin HiveStar™.
ادغام شبکههای موجود: با استفاده از چندین دروازه توزیعشده و متصل در لبه شبکه بین شبکههای تاکتیکی قدیمی، اطلاعات میتونن از مسیرهای مختلف بین پلتفرمها جابجا بشن. با حذف نقاط شکست تکی (single points of failure) با ارزش بالا در سیستم، مقاومت شبکه ایجاد میشه.
پروژه مرتبط:Lockheed Martin Project Hydra.
مقابله با تهدیدات: استراتژی «امنیت قرن ۲۱» (21st Century Security) لاکهید مارتین برای کمک به مشتریان طراحی شده تا از تکنولوژیهای نوظهور – هوش مصنوعی، پردازش لبه و اتصال پذیری 5G.MIL – برای اتصال یکپارچه و امن تمام داراییها در میدان نبرد مشترک استفاده کنن. این کار آگاهی موقعیتی بینظیری رو برای اقدام قاطعانه فراهم میکنه.
نمایش مرتبط: نمایش ISR (اطلاعات، نظارت و شناسایی) مبتنی بر 5G با همکاری ورایزن (Verizon).
همکاری با دانشگاه و صنعت
یکی از عناصر کلیدی استراتژی امنیت قرن ۲۱، همکاری با شرکتهای تجاری نوآور (چه بزرگ و چه کوچک)، بازیگران سنتی حوزه هوافضا و دفاع و موسسات دانشگاهی برتره تا تکنولوژیهای اونها رو برای کاربردهای نظامی ادغام کنن. تکنولوژیهایی مثل 5G، هوش مصنوعی، رایانش ابری توزیعشده و خودرانی، از فعالسازهای کلیدی برای کاربردهای پیشرفته فرماندهی و کنترل مشترک همه-دامنهای (JADC2) هستن.
صنعت تکنولوژی تجاری در این زمینهها پیشرو هست و لاکهید مارتین به دنبال همکاری با اونهاست تا این قابلیتها رو به حوزه دفاعی بیاره. این تیم چندین حوزه رو شناسایی کرده که در اونها با همکاران تجاری برای بهبود امنیت، مقاومت، قابلیت همکاری و عملکرد 5G و Next G، به طور خاص برای نیازها و الزامات وزارت دفاع (DOD) کار میکنن.
برخی از این روابط به صورت عمومی اعلام شده، از جمله همکاری با:
ورایزن (Verizon)
مایکروسافت (Microsoft)
اینتل (Intel)
جونیپر نتورکس (Juniper Networks)
رادیسیس (Radisys)
کیسایت (Keysight)
این رویکرد میپذیره که عملیات شبکه چند-فروشندهای و ادغام چند-ابری (multi-cloud) مورد نیاز خواهد بود. روابط استراتژیک، اعضای کلیدی تیم رو تشکیل میدن، در حالی که رویکرد مبتنی بر سیستم باز و استانداردها برای گنجاندن راهکارهای مکمل صنعتی نیز طراحی شده.
این نگاه به 5G نشون میده که این تکنولوژی چقدر فراتر از یک ابزار تجاریه و چطور میتونه به یک عنصر استراتژیک در امنیت و دفاع مدرن تبدیل بشه.
فصل ششم: امنیت در دنیای 5G: چالشها و راهکارها
با این همه قدرت و دستگاههای متصل، یه سوال خیلی مهم پیش میاد: امنیت 5G چطوره؟ وقتی قراره همه چیز، از ماشین خودرانمون گرفته تا تجهیزات پزشکی و زیرساختهای حیاتی شهر، به این شبکه وصل باشه، امنیت دیگه یه گزینه نیست، یه ضرورته. 5G با معماری جدید و پیچیدهاش، هم فرصتهای امنیتی جدیدی ایجاد میکنه و هم چالشهای تازهای رو به وجود میاره.
تفاوت امنیت 4G و 5G
برای درک بهتر امنیت 5G، باید تفاوتش رو با 4G بدونیم.
معماری 4G: متمرکز و مبتنی بر سختافزار بود. بیشتر عملکردها به صورت یکپارچه و تحت کنترل یک فروشنده خاص بودن. ترافیک از مسیرهای مشخصی عبور میکرد و این کار اعمال امنیت یکپارچه رو سادهتر میکرد.
معماری 5G: غیرمتمرکز، مبتنی بر نرمافزار و غالبا میزبانی شده در فضای ابری (Cloud-hosted) است. عملکردها به صورت مجازی (Virtual Machines یا Containers) روی زیرساختهای اشتراکی اجرا میشن. این انعطافپذیری بالا، سطح حمله (Attack Surface) رو هم به شدت گسترش میده. یعنی نقاط آسیبپذیری بیشتری در هر لایه به وجود میاد.
بزرگترین ریسکهای امنیتی 5G
معماری جدید 5G، ریسکهای جدیدی رو هم با خودش میاره که در نسلهای قبلی وجود نداشتن یا کمتر بودن.
برشهای شبکه سرکش (Rogue Slices): همونطور که گفتیم، Network Slicing ترافیک رو در شبکههای مجازی ایزوله میکنه. اما اگه یه برش به درستی پیکربندی نشه یا توسط هکرها کنترل بشه، میتونه کنترلهای امنیتی اشتراکی رو دور بزنه و یه شکاف امنیتی ایجاد کنه که شناساییاش خیلی سخته.
پیکربندیهای نادرست در فضای ابری (Cloud Misconfigurations): عملکرد 5G به شدت به زیرساختهای مجازی و سرویسهای ابری وابسته است. یه API با تنظیمات اشتباه، یه کانتینر آپدیت نشده یا یه سیاست دسترسی بیش از حد مجاز میتونه سیستمهای حیاتی رو در معرض خطر قرار بده.
حملات کانال جانبی (Side-channel Attacks): هکرها همیشه مستقیما به نرمافزار حمله نمیکنن. گاهی وقتا میتونن از سیگنالهای غیرمستقیم مثل زمانبندی، مصرف برق یا استفاده از حافظه، اطلاعات حساس رو استخراج کنن. در 5G، با توجه به تراکم بالای تجهیزات در لبه شبکه و منابع اشتراکی، خطر این نوع حملات بیشتر میشه.
حملات منع سرویس (Denial-of-Service – DoS): در دسترس بودن سرویس، یکی از اهداف اصلی 5G هست و همین موضوع اون رو به یه هدف جذاب برای حملات DoS تبدیل میکنه. هکرها میتونن برشهای شبکه، کانالهای رادیویی یا APIها رو با ترافیک جعلی اشباع کنن و باعث قطعی سرویس بشن.
شنود و تحلیل ترافیک (Eavesdropping): رمزنگاری، دادهها رو در حین انتقال محافظت میکنه، اما همیشه فرادادهها (Metadata) رو پوشش نمیده. هکرها با مشاهده الگوهای ترافیک میتونن رفتار کاربر، موقعیت مکانی یا نوع اپلیکیشن مورد استفاده رو حدس بزنن.
حملات مرد میانی (Meddler-in-the-middle – MITM): در این نوع حمله، هکر خودش رو بین دو نقطه ارتباطی قرار میده و ترافیک رو شنود یا دستکاری میکنه. ایستگاههای پایه جعلی یا ضعف در احراز هویت متقابل میتونه این نوع حملات رو ممکن کنه.
ویژگیهای امنیتی داخلی 5G
البته 5G خودش هم بیکار ننشسته و یه سری ویژگیهای امنیتی بنیادی رو مستقیما در معماری خودش گنجونده. این ویژگیها در چهار حوزه اصلی قرار دارن:
امنیت دسترسی به شبکه: 5G از احراز هویت متقابل (mutual authentication) قویتری بین دستگاه کاربر و شبکه استفاده میکنه. هویت مشترک (Subscriber Identity) که در نسلهای قبلی به صورت رمزنگاری نشده (IMSI) بود، حالا با یک شناسه مخفی جایگزین شده تا ریسک ردیابی کاربر کمتر بشه.
امنیت دامنه شبکه: بین بخشهای مختلف شبکه مثل شبکه دسترسی و هسته 5G، از رمزنگاری، احراز هویت و حفاظت از یکپارچگی دادهها استفاده میشه.
امنیت دامنه کاربر: در سمت کاربر، 5G از مدلهای اعتماد پیچیدهتری پشتیبانی میکنه. احراز هویت متقابل حالا میتونه نه فقط بین دستگاه و اپراتور، بلکه بین ارائهدهندگان سرویس یا شخص ثالث هم انجام بشه.
امنیت دامنه اپلیکیشن: 5G مکانیزمهای پیامرسانی امن بین اپلیکیشنها، تجهیزات کاربر و ارائهدهندگان رو مشخص میکنه.
نکته مهم: با اینکه 5G این قابلیتها رو تعریف کرده، اما همه اونها اجباری نیستن. بعضی از این حفاظتها اختیاری هستن یا پیادهسازیشون به فروشندهها و اپراتورها واگذار شده. این یعنی امنیت واقعی شبکه، فقط به استانداردها بستگی نداره، بلکه به این بستگی داره که این ویژگیها چقدر به صورت مداوم و صحیح در کل شبکه پیادهسازی بشن.
امنیت 5G در عمل: چه کسی مسئول است؟
امنیت در 5G یه مسئولیت مشترکه.
ارائهدهندگان خدمات ارتباطی (CSPs): اینها مسئول اصلی هستن. طراحی، استقرار و بهرهبرداری از زیرساخت با اونهاست. پس مسئولیت سختافزاری شبکه دسترسی رادیویی (RAN)، امنسازی هسته 5G و پیادهسازی استانداردهایی مثل رمزنگاری و احراز هویت 3GPP با اونهاست.
شرکتها و سازمانها (Enterprises): اونها از برشها و سرویسهایی که روی زیرساخت اپراتورها ساخته شده استفاده میکنن. این شرکتها مسئول امنیت اپلیکیشنهای خودشون، امنیت دستگاههای پایانی و امنیت بارهای کاری در لبه شبکه هستن.
دولتها: سازمانهای دولتی استانداردها رو تعیین میکنن، مدلهای تهدید رو منتشر میکنن و تضمین میکنن که اپراتورها و فروشندهها حداقلهای لازم در زمینه زنجیره تامین، مقاومت و اعتماد رو رعایت کنن.
در نهایت، 5G به خودی خود امنتر از 4G طراحی شده، اما به خاطر پیچیدگی و سطح حمله بزرگتر، نیاز به یک رویکرد دفاعی عمیق و چندلایه داره. امنیت فقط در هسته شبکه نیست، بلکه باید از دستگاه کاربر تا اپلیکیشن و فضای ابری، به صورت سرتاسری تامین بشه.
فصل هفتم: پرسش و پاسخهای متداول (FAQ)
در این فصل، به برخی از پرتکرارترین سوالاتی که در مورد 5G پرسیده میشه، به زبان ساده جواب میدیم. این سوالات از منابع مختلف جمعآوری شدن تا یه دید کامل و جامع بهت بدن.
۱. 5G چقدر از 4G سریعتره؟
5G به طور قابل توجهی سریعتره. در حالی که سرعت 4G LTE معمولا حدود ۱۰۰ مگابیت بر ثانیه است، 5G میتونه به سرعتهای تئوری تا ۲۰ گیگابیت بر ثانیه برسه. این یعنی ۲۰ تا ۱۰۰ برابر سریعتر. در دنیای واقعی، سرعت 5G بسته به نوع شبکه (باند-پایین، میانی یا بالا) خیلی متفاوته. در شبکههای باند-بالا (mmWave) سرعتهایی بالاتر از ۱ گیگابیت بر ثانیه (۱۰۰۰ مگابیت بر ثانیه) هم ثبت شده.
۲. آیا برای استفاده از 5G به گوشی جدید نیاز دارم؟
بله. برای اتصال به شبکه 5G، حتما باید یه دستگاه (گوشی، تبلت و …) داشته باشی که از 5G پشتیبانی کنه. دستگاههای قدیمیتر که برای 4G یا نسلهای قبل طراحی شدن، نمیتونن به شبکه 5G وصل بشن. امروز اکثر گوشیهای بالای ۳۰۰ دلار از 5G پشتیبانی میکنن.
۳. آیا گوشی 5G من روی هر پلن موبایلی کار میکنه؟
گوشی 5G شما روی پلنهای 4G هم کار میکنه، اما فقط به شبکه 4G LTE وصل میشه و از مزایای 5G بیبهره میمونه. برای استفاده از سرعت و کیفیت 5G، باید هم دستگاه 5G داشته باشی، هم پلنی که دسترسی به 5G رو فراهم میکنه، و هم در منطقهای باشی که تحت پوشش 5G قرار داره.
۴. 5G کی و کجا در دسترسه؟
استقرار 5G از اواخر سال ۲۰۱۸ شروع شده و به سرعت در حال گسترشه. در حال حاضر، 5G در بسیاری از شهرها و کشورهای دنیا، از جمله آمریکا، چین، کره جنوبی و بخشهایی از اروپا در دسترسه. پوششدهی خیلی سریعتر از نسلهای قبلی در حال انجامه. در آمریکا، اپراتورهای اصلی مثل T-Mobile، Verizon و AT&T پوشش سراسری (بیشتر از نوع باند-پایین) رو ارائه دادن و به سرعت در حال گسترش شبکههای باند-میانی خودشون هستن. پیشبینی میشه تا سال ۲۰۲۹، 5G بیش از ۶۰ درصد کل اشتراکهای موبایل در جهان رو تشکیل بده.
۵. آیا 5G امن و بیخطره؟
بله. مطالعات گسترده نشون داده که 5G امنه و با استانداردهای بینالمللی سلامت و ایمنی مطابقت داره. فرکانسهایی که 5G استفاده میکنه (مخصوصا در باندهای پایین و میانی) دهههاست که برای کاربردهای مختلف مثل تلویزیون و شبکههای موبایل قبلی استفاده میشن. امواج باند-بالا (mmWave) هم به خاطر ماهیتشون، قدرت نفوذ خیلی کمی دارن و حتی نمیتونن از پوست انسان عبور کنن. اثر اونها در سطوح توانی که در شبکههای 5G استفاده میشه، قابل اندازهگیری و محسوس نیست.
۶. بزرگترین چالشهای پیش روی 5G چیه؟
زیرساخت: استقرار گسترده 5G، مخصوصا شبکههای باند-بالا که نیاز به تعداد زیادی Small Cell دارن، هزینه و زمان زیادی میبره. برای همین پوششدهی در مناطق روستایی و کمتر توسعهیافته کندتره.
امنیت: همونطور که در فصل قبل گفتیم، افزایش تعداد دستگاههای متصل، ریسکهای امنیتی جدیدی ایجاد میکنه.
هزینه: هزینه دستگاههای سازگار با 5G هنوز برای بعضی از مصرفکنندهها بالاست.
مصرف انرژی: شبکهها و دستگاههای 5G ممکنه انرژی بیشتری مصرف کنن که نگرانیهای زیستمحیطی به همراه داره.
۷. آیا 5G باتری گوشی رو سریعتر خالی میکنه؟
5G به طور بالقوه میتونه باتری رو سریعتر از 4G مصرف کنه، مخصوصا وقتی به شبکههای mmWave متصل باشی. اما پیشرفت در تکنولوژی دستگاهها و شبکهها به طور مداوم در حال بهبود بهرهوری انرژی هست.
۸. تفاوت 5G UW و 5G UC چیه؟
اینها اصطلاحات بازاریابی اپراتورها هستن.
5G UW (Ultra Wideband): معمولا به شبکههای باند-بالا (mmWave) و بخشی از باند-میانی ورایزن اشاره داره که سریعترین سرعت رو دارن ولی پوشش محدود.
5G UC (Ultra Capacity): معمولا به شبکه باند-میانی T-Mobile اشاره داره که تعادل خوبی بین سرعت و پوشش ارائه میده.
به طور کلی، 5G UW سریعتر از 5G UC هست، اما 5G UC پوشش بسیار گستردهتری داره.
۹. بعد از 5G چی میاد؟
تحقیقات روی 6G یا نسل ششم уже شروع شده. انتظار میره 6G حدود سال ۲۰۳۰ به صورت تجاری عرضه بشه و سرعتهای حتی بیشتر، تاخیر کمتر و قابلیتهای نوآورانهتری مثل ادغام عمیقتر با هوش مصنوعی رو ارائه بده. 6G روی زیربنایی که 5G ساخته، بنا خواهد شد.
۱۰. آیا 5G میتونه جایگزین اینترنت خانگی من بشه؟
بله. یکی از اولین کاربردهای بزرگ 5G، ارائه اینترنت خانگی بیسیم (Fixed Wireless Access) هست. شرکتهایی مثل ورایزن و تی-موبایل در حال حاضر پلنهای اینترنت خانگی 5G رو ارائه میدن که میتونه یه رقیب جدی برای اینترنت کابلی و DSL باشه، مخصوصا در مناطقی که دسترسی به فیبر نوری وجود نداره. این سرویسها معمولا سرعت بالا و داده نامحدود با قیمت رقابتی ارائه میدن.
پیشنیازها: آشنایی اولیه با مفاهیم اینترنت (مثل پینگ، لگ و سرعت دانلود)
اهداف درس:
یاد میگیری چرا گاهی وقتها با اینکه سرعت اینترنتت بالاست، باز هم لگ داری.
با یک تکنولوژی جدید به اسم L4S و معنی اسمش آشنا میشی.
میفهمی L4S چطور کار میکنه تا مشکل لگ و قطعی رو حل کنه.
با کاربردهای این تکنولوژی در دنیای گیم، تماس تصویری و واقعیت مجازی (XR) آشنا میشی.
فصل اول: چرا اینترنت گاهی وقتها روی اعصاب راه میره؟
تاحالا شده وسط یه بازی آنلاین حساس، یهو همه چیز یخ بزنه و چند ثانیه بعد ببینی که شخصیتت حذف شده؟ یا توی یه تماس تصویری مهم، تصویر دوستت شطرنجی بشه و صداش قطع و وصل بشه، با اینکه سرعت اینترنتت رو چک کردی و همه چیز عالی به نظر میرسیده؟ این تجربههای ضدحال، یه مشکل نامرئی و خیلی رایج توی شبکههای اینترنتی امروزی هستن. ما معمولا فکر میکنیم تنها چیزی که مهمه، «سرعت» اینترنته. یعنی همون عددی که به مگابیت بر ثانیه (Mbps) نشون داده میشه. اما واقعیت اینه که یه فاکتور مهم دیگه هم وجود داره که ما کمتر بهش توجه میکنیم: تاخیر یا Latency.
تاخیر یعنی مدت زمانی که طول میکشه یه بسته کوچیک از داده از کامپیوتر یا گوشی تو به سرور بازی یا اپلیکیشن برسه و جوابش برگرده. هرچی این زمان کمتر باشه، تجربه تو روانتر و سریعتره. وقتی میگیم «لگ» داریم، در واقع داریم از تاخیر بالا حرف میزنیم.
حالا مشکل از کجا شروع میشه؟ یکی از بزرگترین مقصرها پدیدهای به اسم «بافربلوت» (Bufferbloat) هست. بذار یه مثال ساده بزنم. فکر کن روتر یا مودم خونگی تو مثل یه مامور پست توی یه اداره پست کوچیکه. این مامور یه سبد بزرگ داره که نامهها (بستههای داده) رو قبل از ارسال، موقتا توی اون نگه میداره. حالا اگه یهو یه عالمه نامه از جاهای مختلف برسه (مثلا یکی داره فیلم 4K دانلود میکنه، یکی دیگه داره بازی میکنه، اون یکی هم داره تماس تصویری میگیره)، این سبد (که بهش میگیم بافر) شروع میکنه به پر شدن. مامور پست ما سعی میکنه همه رو به ترتیب ارسال کنه، اما چون تعداد نامهها زیاده، بعضی از نامهها که خیلی هم مهم و فوری هستن (مثل دادههای بازی آنلاین تو) مجبورن ته صف وایسن و کلی معطل بشن. این معطلی همون چیزیه که باعث لگ و تاخیر میشه. در واقع، مشکل از بزرگی بیش از حد اون سبد (بافِر) هست. روترها فکر میکنن با داشتن یه بافر بزرگ دارن لطف میکنن، اما در عمل باعث میشن بستههای داده مهم، بیدلیل توی صفهای طولانی گیر کنن.
اینجاست که نیاز به یه راه حل هوشمندانهتر حس میشه. راه حلی که فقط به فکر ارسال بستهها نباشه، بلکه به فکر «زمانبندی» و «اولویت» اونها هم باشه. راه حلی که نذاره بستههای فوری و حساس، پشت بستههای غیرضروری معطل بمونن.
فصل دوم: معرفی L4S، راه حلی برای یک اینترنت روانتر
خب، حالا که با مشکل اصلی یعنی تاخیر و بافربلوت آشنا شدیم، وقتشه بریم سراغ راه حل. دانشمندها و مهندسهای شبکه دور هم جمع شدن و یک تکنولوژی جدید و خیلی جالب رو به اسم L4S طراحی کردن.
بیا این اسم طولانی رو با هم کلمهبهکلمه معنی کنیم تا بفهمیم هدفش چیه:
Low Latency (تاخیر کم): این یعنی هدف اصلی L4S اینه که زمان رفت و برگشت دادهها رو تا جای ممکن کم کنه. این همون چیزیه که برای بازیهای آنلاین، تماسهای تصویری، واقعیت مجازی (XR) و هر کار دیگهای که به واکنش سریع نیاز داره، حیاتیه.
Low Loss (اتلاف کم): توی شبکه، گاهی وقتها به خاطر شلوغی زیاد، بعضی از بستههای داده گم میشن یا از بین میرن (به این میگن Packet Loss). وقتی یه بسته گم میشه، سیستم مجبوره دوباره اون رو ارسال کنه که این خودش باعث تاخیر بیشتر میشه. L4S تلاش میکنه تا جلوی این اتفاق رو بگیره و بستهها سالم به مقصد برسن.
Scalable Throughput (توان عملیاتی مقیاسپذیر): این بخش یه کم فنیتره ولی مفهومش سادهست. Throughput یعنی مقدار دادهای که میتونی توی یک زمان مشخص با موفقیت ارسال کنی (همون سرعت مفیدی که واقعا به دستت میرسه). «مقیاسپذیر» بودنش یعنی L4S میتونه خودش رو با شرایط مختلف شبکه تطبیق بده. چه شبکه خلوت باشه و چه خیلی شلوغ، این تکنولوژی میتونه بهترین استفاده رو از پهنای باند موجود بکنه بدون اینکه باعث تاخیر و لگ بشه.
پس به طور خلاصه، L4S یه استاندارد و معماری جدیده که هدفش اینه که اینترنت ما رو نه فقط سریع، بلکه «پاسخگو» و «روان» کنه. این تکنولوژی که توسط سازمانهایی مثل IETF (Internet Engineering Task Force) استاندارد شده، یه جورایی نسل بعدی کنترل ترافیک توی اینترنته. جالبه بدونی که تحقیقات اولیه و مهم این تکنولوژی توسط تیمی در Nokia Bell Labs به رهبری فردی به اسم «کون د شپر» (Koen De Schepper) و با همکاری شرکتهایی مثل BT و Simula انجام شده و در نهایت در ژانویه سال ۲۰۲۳ به عنوان یک استاندارد رسمی (RFC) معرفی شد. این تکنولوژی اونقدر مهمه که حتی در استانداردهای جدید موبایل مثل 5G-Advanced (در نسخه 3GPP Release 18) هم گنجانده شده تا بتونه از کاربردهای پیشرفتهای مثل واقعیت توسعهیافته (XR) پشتیبانی کنه.
فصل سوم: L4S چطور کار میکنه؟ نگاهی به پشت صحنه
شاید برات سوال شده باشه که L4S چطور این کارها رو انجام میده. آیا جادو میکنه؟ نه دقیقا، ولی از چند تا مکانیزم خیلی هوشمندانه استفاده میکنه که با هم ترکیب میشن و نتیجه فوقالعادهای میگیرن. بیایید سه تا از کلیدیترین مکانیزمهای L4S رو با هم بررسی کنیم.
۱. جداسازی صفها (Queue Isolation)
یادتونه در مورد مشکل بافربلوت و صف طولانی بستههای داده صحبت کردیم؟ L4S برای این مشکل یه راه حل عالی داره. به جای اینکه همه بستههای داده، چه اونایی که فوری هستن و چه اونایی که نیستن، رو توی یک صف بزرگ و درهم بریزه، میاد و دو تا صف جداگونه درست میکنه.
یک صف برای ترافیک L4S: این صف مخصوص اپلیکیشنهای حساس به تاخیره. مثل بازی آنلاین، تماس تصویری یا استریم زنده. این صف خیلی کوتاه نگه داشته میشه تا بستهها اصلا معطل نشن.
یک صف برای ترافیک کلاسیک: این صف برای کارهای معمولیه که تاخیر چندان براشون مهم نیست. مثل دانلود یک فایل سنگین یا آپدیت کردن یک نرمافزار. این ترافیک میتونه توی صف خودش منتظر بمونه بدون اینکه مزاحم ترافیک فوری و حساس صف اول بشه.
این کار مثل این میمونه که توی یه فروشگاه بزرگ، یه صندوق مخصوص برای مشتریهایی بذارن که فقط یه دونه جنس دارن. اینجوری اونها دیگه مجبور نیستن پشت سر کسی وایسن که چرخ خریدش تا خرخره پره. این جداسازی باعث میشه ترافیک L4S از رقابت بر سر پهنای باند با ترافیکهای سنگین و تهاجمی در امان بمونه و همیشه تاخیرش پایین بمونه. در سیستمهای 5G هم این قابلیت به خوبی پیادهسازی میشه. اونجا به جای «صف»، از مفهومی به اسم «جریان کیفیت سرویس» یا QoS Flow استفاده میشه که هر کدوم یه شناسه منحصر به فرد به اسم 5QI دارن. شبکه 5G میتونه به راحتی یک جریان QoS مخصوص برای ترافیک L4S تعریف کنه و اون رو از بقیه جدا نگه داره.
۲. استراتژی علامتگذاری مبتنی بر ECN
خب، حالا که صفها رو جدا کردیم، شبکه از کجا باید بفهمه که کدوم بسته داده باید توی کدوم صف بره؟ و مهمتر از اون، چطور باید به فرستنده خبر بده که «هی، یه کم یواشتر بفرست، شبکه داره شلوغ میشه!»؟
روشهای قدیمی برای خبر دادن شلوغی شبکه، خیلی خشن بودن. روترها وقتی میدیدن صفشون داره پر میشه، شروع میکردن به دور ریختن (Drop کردن) بستههای داده. فرستنده وقتی میدید بستههاش گم میشن، میفهمید که شبکه شلوغه و سرعتش رو کم میکرد. این کار دو تا مشکل بزرگ داشت: اول اینکه بستههایی که دور ریخته میشدن باید دوباره ارسال میشدن که خودش تاخیر ایجاد میکرد. دوم اینکه این روش مثل ترمز اضطراری بود؛ تا وقتی کارد به استخوان نمیرسید، فرستنده خبردار نمیشد.
L4S از یک روش خیلی ملایمتر و هوشمندانهتر استفاده میکنه. این تکنولوژی از دو بیت استفاده نشده در هدر بستههای IP (همون شناسنامه هر بسته داده) به اسم بیتهای ECN (Explicit Congestion Notification) یا «اعلان صریح ازدحام» استفاده میکنه.
کار این بیتها دو چیزه:
شناسایی ترافیک: فرستندههایی که از L4S پشتیبانی میکنن، بستههاشون رو با یک کد ECN خاص به اسم ECT(1) علامتگذاری میکنن. روترهای شبکه وقتی این علامت رو میبینن، میفهمن که این یه بسته L4S هست و باید اون رو به صف مخصوص و سریع خودش بفرستن. ترافیکهای معمولی با کدهای دیگهای مثل ECT(0) یا Not-ECT مشخص میشن.
هشدار قبل از فاجعه: حالا قسمت جالب ماجرا اینجاست. روتر وقتی حس میکنه صف L4S داره یه ذره شلوغ میشه (حتی خیلی قبل از اینکه پر بشه)، به جای دور ریختن بستهها، فقط کد ECN اونها رو از ECT(1) به CE (Congestion Experienced) تغییر میده. یعنی روی بسته یه برچسب میزنه که «من شلوغی رو تجربه کردم». بسته سالم به مقصد میرسه، ولی گیرنده وقتی این برچسب رو میبینه، فورا در بسته برگشتی به فرستنده خبر میده که «شبکه داره شلوغ میشه، سرعتت رو یه کم بیار پایین».
این مکانیزم مثل اینه که سر یه پیچ خطرناک، به جای دیوار بتنی، یه نفر وایساده باشه و به ماشینهایی که با سرعت میان علامت بده که آرومتر برن. اینجوری هم تصادفی نمیشه و هم جریان ترافیک روان باقی میمونه. این استراتژی علامتگذاری به جای دور ریختن، باعث میشه اتلاف بسته (Packet Loss) تقریبا به صفر برسه.
۳. کنترل ازدحام مقیاسپذیر (Scalable Congestion Control)
سومین قطعه این پازل، خود اپلیکیشن یا فرستنده دادهست. الگوریتمهای کنترل ازدحام قدیمی مثل Reno یا CUBIC (که در پروتکل TCP استفاده میشن) خیلی کند به تغییرات شبکه واکنش نشون میدادن و برای فهمیدن ظرفیت شبکه، باید با آزمون و خطا سرعتشون رو کم و زیاد میکردن که نتیجهش یه نمودار شبیه دندانه اره میشد و باعث نوسان و تاخیر میشد.
L4S از الگوریتمهای کنترل ازدحام جدید و مقیاسپذیری مثل Prague Congestion Control استفاده میکنه. این الگوریتمها خیلی سریع و دقیق به سیگنالهای ECN که از شبکه میان واکنش نشون میدن. به محض اینکه اولین نشونههای شلوغی رو از طریق برچسب CE دریافت میکنن، خیلی سریع و به اندازه لازم سرعت ارسالشون رو کم میکنن تا صفها شلوغ نشن. وقتی هم که سیگنال شلوغی قطع میشه، دوباره به سرعت نرخ ارسالشون رو بالا میبرن تا از تمام ظرفیت شبکه استفاده کنن.
این همکاری تنگاتنگ بین اپلیکیشن فرستنده (با الگوریتم Prague) و شبکه (با جداسازی صف و علامتگذاری ECN) همون چیزیه که جادوی L4S رو خلق میکنه. نتیجه این همکاری، یک ارتباط با تاخیر بسیار کم و پایدار، اتلاف بسته نزدیک به صفر، و استفاده بهینه از تمام پهنای باند شبکه هست. این یعنی دیگه خبری از اون تجربههای ضدحال وسط بازی و تماس تصویری نخواهد بود.
فصل چهارم: از آزمایشگاه تا دنیای واقعی (چه شرکتهایی دارن ازش استفاده میکنن؟)
حرف زدن در مورد یک تکنولوژی روی کاغذ خیلی راحته، اما چیزی که واقعا مهمه اینه که آیا توی دنیای واقعی هم کار میکنه یا نه. خوشبختانه، L4S فقط یک ایده تئوری نیست و شرکتهای بزرگ و مهمی در سراسر دنیا شروع به تست و پیادهسازی اون کردن. بیایید چند تا از این مثالهای واقعی رو با هم ببینیم تا بهتر با قدرت این تکنولوژی آشنا بشیم.
آزمایش موفق نوکیا و الایزا در استادیوم نوکیا آرنا
یکی از اولین و جالبترین آزمایشها، همکاری بین شرکت نوکیا و اپراتور فنلاندی الایزا (Elisa) بود. اونها برای تست L4S، استادیوم بزرگ نوکیا آرنا در شهر تامپره فنلاند رو انتخاب کردن. چرا استادیوم؟ چون استادیومها، سالنهای کنسرت و جاهای شلوغ، کابوس شبکههای موبایل هستن. وقتی هزاران نفر همزمان تلاش میکنن عکس و فیلم استوری کنن یا پخش زنده ببینن، شبکه به شدت دچار ازدحام و کندی میشه. پس اینجا بهترین جا برای تست یه تکنولوژی بود که ادعا میکنه میتونه با ازدحام مقابله کنه.
این آزمایش که یک «اثبات مفهوم» یا PoC بود، با همکاری یک شرکت پخش زنده به اسم Kepit Systems هم انجام شد. سناریوی تست خیلی ساده و در عین حال کاربردی بود: یک نفر روی لپتاپش که به شبکه 5G الایزا وصل بود، میخواست یک بازی هاکی روی یخ زنده رو که از سرورهای شرکت Kepit پخش میشد، تماشا کنه.
مرحله اول (بدون L4S): در ابتدا، وقتی شبکه عمدا شلوغ و پرترافیک بود، پخش زنده به سختی لود میشد، دائم قطع میشد و بافر میکرد. کاربر عملا نمیتونست بازی رو ببینه. این دقیقا همون تجربهایه که خیلی از ما در جاهای شلوغ داشتیم.
مرحله دوم (با L4S): در این مرحله، با استفاده از یک پلتفرم به اسم Network as Code (NaC) که نوکیا توسعه داده، یک درخواست ساده (از طریق API) برای فعال کردن L4S روی اون اتصال فرستاده شد. پلتفرم NaC به اپراتورها این امکان رو میده که شبکهشون رو به صورت نرمافزاری و برنامهپذیر کنترل کنن. به محض فعال شدن L4S، اتفاق جالبی افتاد. تاخیر شبکه به شدت کم شد و پخش زنده بازی هاکی، روان و بدون هیچ قطعی و بافری پخش شد.
مرحله سوم (غیرفعال کردن L4S): برای اینکه مطمئن بشن این بهبود به خاطر L4S بوده، دوباره از طریق پلتفرم NaC این قابلیت رو غیرفعال کردن. نتیجه قابل پیشبینی بود: ویدیو دوباره شروع به فریز شدن و بافر کردن کرد و مشکلات ازدحام برگشتن.
این آزمایش موفق نشون داد که L4S چقدر میتونه در محیطهای شلوغ و واقعی تاثیرگذار باشه و چطور اپراتورها میتونن با استفاده از پلتفرمهایی مثل Network as Code، این قابلیت رو به صورت یک سرویس ویژه به کاربرها یا شرکتهایی که به ارتباط باکیفیت نیاز دارن (مثل پخش زندههای ورزشی یا فیدهای ویدیویی برای مقاصد اورژانسی) ارائه بدن و ازش کسب درآمد کنن.
T-Mobile و پیشتازی در دنیای بیسیم
اپراتور بزرگ آمریکایی، T-Mobile، یکی از اولین شرکتهاییه که L4S رو به صورت گسترده در شبکه بیسیم خودش پیادهسازی کرده. اونها به عنوان بخشی از برنامه ارتقا شبکهشون به 5G Advanced، قابلیت L4S رو در سطح کشور فعال کردن. T-Mobile چون شبکه 5G خودش رو از پایه به صورت مستقل (Standalone یا SA) ساخته، این انعطافپذیری رو داره که نوآوریهایی مثل L4S رو راحتتر پیادهسازی کنه. اونها هم چند تا آزمایش خیلی جالب انجام دادن:
رانندگی از راه دور با شرکت Vay: تصور کن بتونی یه ماشین رو از کیلومترها دورتر، انگار که خودت پشت فرمون نشستی، کنترل کنی. این دقیقا کاریه که شرکت آلمانی Vay انجام میده. این کار به یک ارتباط با تاخیر فوقالعاده کم و پایدار نیاز داره، چون حتی یک میلیثانیه تاخیر اضافه میتونه خطرناک باشه. T-Mobile با استفاده از شبکه 5G Advanced و قابلیت L4S، این امکان رو برای Vay فراهم کرد. رانندههای از راه دور Vay گزارش دادن که با وجود L4S، تاخیر اونقدر کم و قابل پیشبینی بود که حس میکردن واقعا داخل ماشین نشستن، حتی در شرایطی که ترافیک شبکه زیاد بود. این یک نمونه عالی از کاربرد L4S در سناریوهای حساس و حیاتیه.
واقعیت توسعهیافته (XR) با کوالکام و اریکسون: یکی از موانع اصلی برای همهگیر شدن عینکهای واقعیت مجازی و افزوده، مشکل تاخیر و لرزش تصویره که میتونه باعث سرگیجه و حالت تهوع بشه. T-Mobile در همکاری با کوالکام (Qualcomm) و اریکسون (Ericsson)، با استفاده از عینکهای هوشمند سبک، L4S رو روی شبکه 5G SA خودشون تست کردن. نتیجه فوقالعاده بود: تصاویر کاملا شفاف، فریمها بدون کوچکترین لرزش و پرش، و در نتیجه کاهش چشمگیر سرگیجه و حالت تهوع در کاربران. این آزمایش نشون داد که L4S میتونه راه رو برای استفاده عمومی و روزمره از XR هموار کنه.
گیمینگ ابری با انویدیا: برای گیمرهای حرفهای، هر میلیثانیه مهمه. سرویسهای گیمینگ ابری مثل GeForce NOW از شرکت انویدیا (NVIDIA)، بازی رو روی سرورهای قدرتمند اجرا میکنن و تصویرش رو برای کاربر استریم میکنن. این فرآیند به شدت به تاخیر شبکه حساسه. انویدیا به صورت رسمی پشتیبانی از L4S رو در سرویس GeForce NOW فعال کرده. وقتی این سرویس روی شبکه 5G Advanced شرکت T-Mobile اجرا میشه، بازیکنها تجربهای بسیار روان، با لرزش کمتر و کنترلهایی دقیق، شبیه به بازی روی یک کنسول خانگی رو تجربه میکنن، حتی وقتی شبکه شلوغ باشه.
تماسهای تصویری مثل FaceTime: حتی در کارهای روزمره مثل یک تماس تصویری با FaceTime، مخصوصا در جاهای شلوغ مثل فرودگاه، L4S میتونه تفاوت بزرگی ایجاد کنه. این تکنولوژی با تطبیق دادن خودش با شلوغی شبکه، از قطع و وصل شدن، فریز شدن تصویر و صدای رباتیک جلوگیری میکنه و مکالمهای روان و باکیفیت رو تضمین میکنه. اپل هم از شرکتهای پیشرو در این زمینه بوده و از iOS 16 و macOS Ventura به بعد، پشتیبانی از L4S رو به سیستمعاملهاش اضافه کرده.
Comcast و اینترنت کابلی با تاخیر فوقالعاده کم
L4S فقط برای شبکههای موبایل نیست. شرکت بزرگ ارائهدهنده اینترنت کابلی در آمریکا، Comcast، هم شروع به پیادهسازی این تکنولوژی روی شبکه خودش کرده. اونها از یک نسخه ویژه از استاندارد اینترنت کابلی به اسم Low Latency DOCSIS (LLD) استفاده میکنن که L4S در اون گنجانده شده.
Comcast این سرویس جدید رو به عنوان یک مزیت رقابتی بزرگ برای اینترنت Xfinity خودش معرفی کرده و گفته که با این تکنولوژی، تاخیر شبکه به قدری کم میشه که از یک چشم به هم زدن هم سریعتره. اونها به طور مشخص اعلام کردن که کاربرها میتونن بهبود عملکرد رو در اپلیکیشنهایی مثل:
FaceTime روی دستگاههای اپل
اپلیکیشنهای روی هدستهای واقعیت ترکیبی Meta
سرویس گیمینگ GeForce NOW از انویدیا
و خیلی از بازیهای پلتفرم Steam شرکت Valve
تجربه کنن. کامکست حتی ادعا کرده که اینترنت LLD اونها در مقایسه با اینترنتهای خانگی 5G، در زمان شلوغی شبکه عملکرد بهتری داره چون دچار افت کیفیت نمیشه. اونها این سرویس رو در شهرهای بزرگی مثل آتلانتا، شیکاگو، فیلادلفیا و سان فرانسیسکو راهاندازی کردن و قصد دارن به سرعت در مناطق بیشتری ارائه بدن.
این مثالهای واقعی از شرکتهای مختلف نشون میده که L4S از فاز آزمایشگاهی خارج شده و داره به یک واقعیت تجاری در انواع شبکهها، از موبایل 5G گرفته تا اینترنت کابلی، تبدیل میشه.
فصل پنجم: L4S در دنیای 5G و وایفای (آینده این تکنولوژی)
همونطور که دیدیم، L4S یک تکنولوژیه که میتونه روی هر نوع شبکه مبتنی بر IP کار کنه. اما برای اینکه واقعا همهگیر بشه، باید در استانداردهای اصلی شبکههای بیسیم، یعنی 5G و وایفای، به صورت رسمی گنجانده بشه. خوشبختانه این اتفاق افتاده و L4S داره به بخش جداییناپذیری از آینده این شبکهها تبدیل میشه.
L4S در شبکه 5G-Advanced
شبکههای 5G به طور ذاتی برای پشتیبانی از تکنولوژیهایی مثل L4S آمادگی خوبی دارن. چرا؟ چون از اول با معماری طراحی شدن که میتونه انواع مختلف ترافیک رو مدیریت کنه. سیستم 5G به طور طبیعی یک زمانبند چند صفی (multi-queue scheduler) هست. این یعنی میتونه به راحتی مکانیزم جداسازی صف L4S رو پیادهسازی کنه.
در نسخه ۱۸ استاندارد 5G که به اسم 5G-Advanced (Rel-18) شناخته میشه، پشتیبانی از L4S به صورت رسمی اضافه شد، مخصوصا برای کاربردهای حساسی مثل XR. اما برای اینکه L4S در شبکه 5G کار کنه، دو تا سوال اصلی باید جواب داده بشه:
۱. چطور جداسازی صف L4S با سیستم چند صفی 5G ترکیب میشه؟
همونطور که قبلا اشاره کردیم، شبکه 5G از مفهومی به اسم «جریان کیفیت سرویس» یا QoS Flow استفاده میکنه. هر جریان، مثل یک لاین اختصاصی برای نوع خاصی از ترافیکه. هر کدوم از این جریانها یک شناسه به اسم 5QI دارن که ویژگیهای اون جریان مثل پهنای باند، تاخیر و قابلیت اطمینان مورد نیازش رو مشخص میکنه.
راه حل خیلی سادهست: شبکه 5G ترافیک L4S رو به یک جریان QoS با 5QI مخصوص خودش اختصاص میده. به این میگیم L4S Flow. شبکه میتونه بستههای L4S رو از طریق همون علامت ECT(1) در هدر IP شناسایی کنه و اونها رو به این جریان اختصاصی هدایت کنه. اینجوری، جداسازی صف به راحتی انجام میشه.
۲. علامتگذاری ECN کجا باید انجام بشه؟
این سوال یه کم پیچیدهتره، چون در شبکه موبایل، هم گوشی کاربر (UE)، هم دکل مخابراتی (gNB) و هم بخشی از هسته شبکه به اسم UPF (User Plane Function) میتونن در این فرآیند نقش داشته باشن.
برای ترافیک آپلینک (وقتی تو داری داده ارسال میکنی):
تشخیص ازدحام توسط گوشی (UE): خود گوشی میتونه ازدحام رو در صفهای ارسال داده خودش تشخیص بده. در این حالت، یا خودش مستقیما بیت ECN رو روی بسته IP علامتگذاری میکنه، یا اینکه اطلاعات ازدحام رو در لایههای پایینتر مثل PDCP یا RLC علامتگذاری میکنه و به gNB میفرسته تا gNB یا UPF این کار رو انجام بدن.
تشخیص ازدحام توسط دکل (gNB): دکل مخابراتی دید بهتری به وضعیت کلی شبکه و صفهای گوشیهای مختلف داره. وقتی ازدحam رو تشخیص میده، میتونه خودش مستقیما بسته IP رو علامت بزنه یا اطلاعات ازدحام رو به UPF در هسته شبکه گزارش بده تا علامتگذاری اونجا انجام بشه.
برای ترافیک داونلینک (وقتی تو داری داده دریافت میکنی):
در این حالت، معمولا دکل (gNB) ازدحام رو تشخیص میده. چون دادهها قبل از رسیدن به گوشی تو، از gNB عبور میکنن. gNB میتونه یا مستقیما بسته IP رو علامت بزنه، یا اینکه اطلاعات ازدحام رو روی لایههای PDCP یا RLC به گوشی بفرسته تا خود گوشی این علامتگذاری رو انجام بده. گزارش دادن به UPF برای علامتگذاری هم ممکنه ولی باعث تاخیر اضافه میشه.
این انعطافپذیری در محل علامتگذاری به شبکه اجازه میده تا بسته به شرایط، بهترین و سریعترین روش رو انتخاب کنه.
L4S در دنیای وایفای (Wi-Fi)
بخش بزرگی از ترافیک اینترنت ما از طریق شبکههای وایفای خانگی یا عمومی منتقل میشه. جالبه بدونی که خود شبکه وایفای یکی از اصلیترین نقاط ایجاد ازدحام و گلوگاه در کل مسیر اینترنته. حتی اگه اینترنت فیبر نوری با سرعت ۱ گیگابیت داشته باشی، اگه شبکه وایفای خونت شلوغ باشه، باز هم لگ رو تجربه میکنی. پس پشتیبانی از L4S در وایفای حیاتیه.
پیادهسازی L4S در وایفای چالشهای خاص خودش رو داره. در شبکههای سیمی، تاخیر عمدتا به خاطر بافر شدنه. اما در وایفای، یک نوع تاخیر دیگه هم داریم به اسم تاخیر دسترسی به رسانه (media access delay). چون وایفای یک رسانه اشتراکیه (هوا)، دستگاههای مختلف باید صبر کنن تا نوبتشون بشه که صحبت کنن (داده ارسال کنن). این صبر کردن در محیطهای شلوغ میتونه خودش باعث تاخیر زیاد بشه.
برای حل این مشکلات، سازمان Wireless Broadband Alliance (WBA) با همکاری CableLabs، یک سری راهنما برای پیادهسازی L4S در محصولات وایفای فعلی منتشر کرده. این راهنماها به تولیدکنندههای تجهیزات مثل روترها و اکسسپوینتها کمک میکنه تا L4S رو در محصولاتشون فعال کنن.
خبر خوب اینه که L4S قراره به صورت بومی و استاندارد در نسل بعدی وایفای، یعنی Wi-Fi 8 (که با استاندارد IEEE 802.11bn شناخته میشه)، گنجانده بشه. این یعنی در آینده، روترهای وایفای به طور پیشفرض این قابلیت رو خواهند داشت و تجربهی ما از اینترنت در خانه بسیار روانتر خواهد شد. چندین شرکت پیشرو از جمله CableLabs پیشنهادهایی برای گنجاندن L4S در این استاندارد ارائه دادن.
با این حرکتها، L4S داره به یک تکنولوژی پایهای در تمام بخشهای شبکه، از هسته اینترنت گرفته تا شبکههای موبایل 5G و شبکههای وایفای خانگی، تبدیل میشه و این یعنی یک قدم بزرگ به سمت یک اینترنت واقعا سریع و پاسخگو برای همه.
فصل ششم: کاربردهای هیجانانگیز L4S (به چه دردی میخوره؟)
تا اینجا فهمیدیم L4S چیه و چطور کار میکنه. حالا بیایید ببینیم این تکنولوژی در عمل چه درهایی رو به روی ما باز میکنه. مزیتهای L4S، یعنی تاخیر کم و پایدار، باعث میشه که برای یک عالمه کاربرد جدید و هیجانانگیز که قبلا به خاطر محدودیتهای شبکه ممکن نبودن، کاملا ایدهآل باشه.
۱. ارتباطات فراگیر XR (واقعیت توسعهیافته)
XR یک کلمه کلیه که شامل واقعیت مجازی (VR)، واقعیت افزوده (AR) و واقعیت ترکیبی (MR) میشه. همه این تکنولوژیها یک وجه مشترک دارن: برای اینکه یک تجربه واقعی و باورپذیر ایجاد کنن، به یک ارتباط با پهنای باند خیلی بالا (حداقل ۱ گیگابیت بر ثانیه) و تاخیر فوقالعاده کم (کمتر از ۲۰ میلیثانیه) نیاز دارن. هر تاخیر کوچیکی در ارسال تصاویر به هدست، میتونه باعث بشه دنیای مجازی با حرکات سر شما هماهنگ نباشه و منجر به سرگیجه و حالت تهوع بشه.
L4S دقیقا همون چیزیه که XR بهش نیاز داره. با تضمین یک تاخیر کم و پایدار، L4S اجازه میده که پردازشهای سنگین گرافیکی از روی خود هدست به یک کامپیوتر قدرتمند در لبه شبکه (Edge Computing) یا در فضای ابری (Cloud) منتقل بشه. این فرآیند که بهش Split Rendering میگن، باعث میشه هدستهای XR بتونن خیلی سبکتر، ارزانتر و با عمر باتری بیشتر ساخته بشن. در واقع، هدست فقط وظیفه نمایش تصویر و ارسال دادههای حسگرها رو داره و تمام کار سخت رو سرورهای قدرتمند انجام میدن. این کار بدون L4S تقریبا غیرممکنه، چون تاخیر غیرقابل پیشبینی شبکه، کل تجربه رو خراب میکنه. با L4S، آیندهای که در اون عینکهای هوشمند سبک و شبیه عینکهای معمولی جایگزین هدستهای بزرگ و سنگین امروزی میشن، خیلی نزدیکتره.
۲. گیمینگ ابری (Cloud Gaming)
سرویسهای گیمینگ ابری مثل GeForce NOW از انویدیا، به شما اجازه میدن جدیدترین و سنگینترین بازیهای روز دنیا رو روی دستگاههای ضعیف مثل یک لپتاپ معمولی یا حتی گوشی موبایل بازی کنید. چطوری؟ بازی روی سرورهای قدرتمند شرکت اجرا میشه و فقط تصویر بازی برای شما استریم میشه و دستورات شما (مثل حرکت دادن موس یا فشردن دکمه) به سرور ارسال میشه.
این فرآیند به شدت به تاخیر حساسه. اگه بین فشردن دکمه شلیک توسط شما و دیدن نتیجهش روی صفحه، تاخیر زیادی وجود داشته باشه، تجربه بازی کاملا خراب میشه. L4S با فراهم کردن یک ارتباط با تاخیر کم و پایدار، باعث میشه تجربه گیمینگ ابری خیلی به تجربه بازی روی یک کنسول یا کامپیوتر خانگی نزدیک بشه. دیگه خبری از لگهای اعصابخردکن وسط بازی نخواهد بود.
۳. خودروهای خودران و کنترل از راه دور
برای سیستمهای رانندگی خودران، ارتباط سریع و قابل اطمینان حیاتیه. این ماشینها باید به صورت لحظهای با ماشینهای دیگه (V2V یا Vehicle-to-Vehicle) و با زیرساختهای جادهای مثل چراغهای راهنمایی (V2I یا Vehicle-to-Infrastructure) در ارتباط باشن تا بتونن تصمیمهای درست و ایمن بگیرن. L4S میتونه با کاهش تاخیر در ارسال دادههای حیاتی مثل اطلاعات سنسورها، هشدارهای ترافیکی و دستورات ناوبری، سرعت واکنش سیستمهای خودران رو به شدت بالا ببره. همچنین چون L4S از مکانیزم علامتگذاری به جای دور ریختن بسته استفاده میکنه، از گم شدن دادههای حیاتی جلوگیری میکنه و قابلیت اطمینان سیستم رو افزایش میده.
همونطور که در مثال شرکت Vay دیدیم، کنترل خودرو از راه دور هم یکی دیگه از کاربردهای شگفتانگیز این تکنولوژیه که مستقیما به تاخیر کم و پایدار L4S وابسته است و میتونه صنعت حمل و نقل و لجستیک رو متحول کنه.
۴. محاسبات لبهای (Edge Computing)
محاسبات لبهای یعنی به جای اینکه دادهها رو برای پردازش به یک مرکز داده دوردست بفرستیم، اونها رو روی سرورهای کوچیکی که از نظر جغرافیایی به ما نزدیکتر هستن (مثلا در نزدیکی دکلهای مخابراتی) پردازش کنیم. این کار به خودی خود تاخیر رو کم میکنه. حالا اگه این ارتباط نزدیک رو با تکنولوژی L4S ترکیب کنیم، میتونیم سرویسهایی با تاخیر فوقالعاده کم و بهرهوری انرژی بالا ارائه بدیم. L4S میتونه با در نظر گرفتن اولویت اپلیکیشنها و حتی مصرف انرژی نودهای شبکه، بهترین مسیر رو برای دادهها انتخاب کنه و کیفیت کلی سرویسهای حساس به تاخیر رو بهینه کنه.
۵. دوقلوی دیجیتال (Digital Twin)
دوقلوی دیجیتال یعنی ساخت یک مدل مجازی کاملا شبیه و همگام با یک شی یا سیستم در دنیای واقعی. مثلا یک کارخونه میتونه یک دوقلوی دیجیتال از تمام ماشینآلاتش داشته باشه. دادهها از سنسورهای ماشینآلات واقعی به صورت لحظهای به مدل مجازی ارسال میشن تا وضعیت لحظهای کارخونه رو شبیهسازی کنن. این کار به مهندسها اجازه میده که بدون دست زدن به سیستم واقعی، سناریوهای مختلف رو تست کنن، مشکلات رو پیشبینی کنن و فرآیندها رو بهینه کنن.
برای اینکه این مدل مجازی همیشه با دنیای واقعی همگام باشه، به یک ارتباط فوقسریع و با تاخیر کم نیاز داره. L4S با تضمین این ارتباط، نقشی کلیدی در کارکرد صحیح و دقیق سیستمهای دوقلوی دیجیتال ایفا میکنه.
۶. بلاکچین (Blockchain)
در شبکههای بلاکچین، تمام نودها (کامپیوترها) باید به صورت مداوم دادههاشون رو با هم همگامسازی کنن تا یکپارچگی و امنیت شبکه حفظ بشه. L4S میتونه با افزایش سرعت و قابلیت اطمینان ارتباط بین نودها، عملکرد کل شبکه بلاکچین رو بهبود بده. مثلا در انجام تراکنشهای ارز دیجیتال یا اجرای قراردادهای هوشمند، L4S با کاهش تاخیر شبکه، سرعت پاسخگویی سیستم رو بالا میبره و به حفظ امنیت و ثبات شبکه کمک میکنه.
اینها فقط چند نمونه از کاربردهای L4S بودن. در واقع، هر اپلیکیشنی که به ارتباط لحظهای و روان نیاز داره، از پخش زنده و خدمات پزشکی از راه دور گرفته تا اینترنت اشیا (IoT) و آموزش آنلاین، میتونه از مزایای این تکنولوژی بهرهمند بشه.
فصل هفتم: چالشها و فرصتهای پیش رو
با وجود تمام مزایا و پتانسیلهای هیجانانگیزی که L4S داره، پیادهسازی و همهگیر شدن اون در کل اینترنت با چالشهایی هم روبرو هست. این تکنولوژی یک تغییر بنیادین در نحوه مدیریت ترافیک شبکه است و مثل هر تغییر بزرگی، نیاز به زمان، همکاری و حل کردن برخی مشکلات داره. بیایید نگاهی به این چالشها و فرصتهای تحقیقاتی که ایجاد میکنن، بندازیم.
چالشهای اصلی پیادهسازی L4S
نیاز به ارتقا تجهیزات: یکی از بزرگترین چالشها اینه که برای کار کردن L4S، تجهیزات شبکه مثل روترها و مودمها باید از قابلیتهای جدیدی مثل جداسازی صف و علامتگذاری ECN پشتیبانی کنن. این یعنی روترهای قدیمیتر شاید نتونن از این تکنولوژی استفاده کنن و نیاز به آپدیت فریمور (Firmware) یا حتی تعویض سختافزاری دارن. البته این یک فرآیند تدریجیه و L4S طوری طراحی شده که بتونه در کنار ترافیک کلاسیک و روی تجهیزات قدیمی هم کار کنه، ولی برای بهرهمندی کامل از مزایای اون، کل مسیر بین فرستنده و گیرنده باید L4S-Aware باشه.
پیچیدگی در طراحی پروتکل: L4S نیازمند یک هماهنگی و بهینهسازی مشترک بین الگوریتم کنترل ازدحام در سمت فرستنده (مثلا کامپیوتر شما) و استراتژی علامتگذاری ECN در روترهای میانی شبکه است. این هماهنگی، طراحی پروتکل رو نسبت به مکانیزمهای سنتی که فقط یک طرف ماجرا (فرستنده) هوشمند بود، پیچیدهتر میکنه. باید مطمئن شد که این سیستم در شرایط مختلف شبکه و با ترافیکهای متنوع، پایدار باقی میمونه.
اکوسیستم و پذیرش گسترده: موفقیت L4S به این بستگی داره که تمام بازیگران اصلی اینترنت، از تولیدکنندههای چیپست و دستگاه (مثل اپل، کوالکام)، توسعهدهندههای سیستمعامل (مثل گوگل، مایکروسافت) و اپلیکیشنها (مثل انویدیا، Valve) گرفته تا ارائهدهندههای بزرگ اینترنت (ISPها مثل Comcast و T-Mobile)، همزمان تصمیم بگیرن که مزایای این تکنولوژی به هزینه و پیچیدگی تغییر میارزه. این یک چالش بزرگ اقتصادی و سیاسیه، نه فقط فنی. همونطور که یکی از کارشناسها به اسم «ویش ناندلال» (Vish Nandlall) اشاره کرده، در اینترنت، درست بودن فنی یک پروتکل، موفقیتش رو تضمین نمیکنه.
فرصتهای تحقیقاتی در 5G-Advanced
معرفی L4S در استاندارد 5G-Advanced، در کنار حل مشکلات، فرصتهای جدیدی رو هم برای تحقیق و بهینهسازی بیشتر ایجاد کرده. برخی از موضوعات مهمی که محققان در حال کار روی اونها هستن عبارتند از:
الگوریتمهای تطبیقپذیر برای تشخیص ازدحام: چطور میشه در یک شبکه بیسیم که شرایطش دائم در حال تغییره، ازدحام رو به سرعت و با دقت تشخیص داد؟ محققان در حال توسعه الگوریتمهای جدیدی هستن که با استفاده از تکنیکهای پیشبینی، بتونن شرایط کانال رادیویی و الگوهای ترافیک رو حدس بزنن و قبل از وقوع ازدحام جدی، اون رو شناسایی کنن.
بهینهسازی استراتژی علامتگذاری ECN: آستانه شلوغی برای شروع علامتگذاری ECN باید چقدر باشه؟ اگه خیلی کم باشه، شاید پهنای باند هدر بره و اگه خیلی زیاد باشه، تاخیر زیاد میشه. از طرفی، اپلیکیشنهای مختلف نیازهای متفاوتی دارن. پس چطور میشه این آستانه رو به صورت پویا و بر اساس نیاز هر اپلیکیشن (که از روی 5QI اون مشخص میشه) تنظیم کرد؟ این یک زمینه تحقیقاتی مهمه.
الگوریتمهای کنترل ازدحام مبتنی بر L4S: طراحی الگوریتمهای کنترل ازدحام جدید که بتونن به بهترین شکل با استراتژیهای علامتگذاری ECN همکاری کنن، یک چالش دیگهست. این الگوریتمها باید بتونن بدون کاهش بیدلیل سرعت یا ایجاد نوسان، به سیگنالهای ازدحام واکنش نشون بدن.
بهینهسازی تخصیص منابع بیسیم: با وجود L4S، چطور میشه منابع رادیویی شبکه (مثل پهنای باند فرکانسی) رو طوری تخصیص داد که هم تجربه کاربران L4S تضمین بشه و هم به بقیه کاربران شبکه فشار نیاد؟ تکنیکهایی مثل رزرو دینامیک منابع یا اسلایسینگ شبکه (Network Slicing) میتونن در این زمینه کمک کنن.
مدیریت تحرک (Mobility Management): وقتی یک کاربر با گوشی در حال حرکت از محدوده پوشش یک دکل به دکل دیگه میره (فرآیندی به اسم Handover)، L4S چطور باید به کارش ادامه بده؟ چطور میشه مطمئن شد که تشخیص ازدحام و علامتگذاری ECN در حین این جابجایی به صورت یکپارچه و بدون وقفه ادامه پیدا میکنه؟ اینها سوالاتی هستن که باید برای اونها راه حلهای قوی پیدا بشه.
حل این چالشها و پیشرفت در این زمینههای تحقیقاتی کمک میکنه تا L4S بهتر و کارآمدتر در شبکههای 5G و نسلهای بعدی پیادهسازی بشه و ما بتونیم از یک تجربه اینترنتی واقعا بینقص لذت ببریم.
فصل هشتم: اعداد و ارقام حرف میزنن (یک مطالعه موردی)
برای اینکه ببینیم L4S در عمل چقدر بهتر از روشهای قدیمی کار میکنه، یک تیم تحقیقاتی به رهبری «گوانگجین پن» (Guangjin Pan) و «شوگونگ شو» (Shugong Xu) یک سیستم آزمایشی برای ارتباطات ویدیویی زنده (RTC) ساختن و عملکرد الگوریتمهای مختلف رو با هم مقایسه کردن. این مطالعه موردی به ما نشون میده که تفاوتها فقط در حد تئوری نیستن و در دنیای واقعی هم قابل اندازهگیری هستن.
اونها یک سیستم مبتنی بر WebRTC (یک استاندارد باز برای ارتباطات صوتی و تصویری زنده) ساختن و برای شبیهسازی یک روتر L4S، از یک نرمافزار متنباز به اسم DualPI2 استفاده کردن. بعد اومدن و چهار تا الگوریتم کنترل ازدحام مختلف رو با هم مقایسه کردن:
GCC: این الگوریتم پیشفرض و معروف گوگل در WebRTC هست. GCC برای تخمین پهنای باند موجود، از اطلاعاتی مثل اتلاف بسته و تغییرات تاخیر استفاده میکنه.
Sensitive-GCC: این یک نسخه حساستر از GCC بود که پارامترهاش طوری تنظیم شده بود که سریعتر به ازدحام شبکه واکنش نشون بده.
L4S-CC: این الگوریتم فقط از اطلاعات ECN (که از شبکه L4S میاد) برای تخمین پهنای باند و کنترل سرعت استفاده میکرد.
L4S-GCC: این الگوریتم پیشنهادی و بهینهسازی شده خود محققان بود. L4S-GCC در واقع ترکیبی از GCC و L4S بود. یعنی هم از اطلاعات ECN برای واکنش سریع به ازدحام استفاده میکرد و هم از مکانیزمهای GCC مثل گرادیان تاخیر برای بازیابی سریعتر سرعت بعد از رفع ازدحام بهره میبرد.
این چهار الگوریتم در سناریوهای مختلفی تست شدن تا تواناییهاشون در دو زمینه اصلی سنجیده بشه: ۱) واکنش سریع به نوسانات پهنای باند برای کاهش فریز شدن ویدیو، و ۲) مقابله با لرزش تاخیر (Delay Jitter) برای افزایش بهرهوری پهنای باند.
نتایج در سناریوهای نوسان پهنای باند
در سه سناریوی اول، پهنای باند شبکه متغیر بود (یک بار ثابت، یک بار با نوسان مربعی و یک بار بر اساس یک نمونه واقعی از شبکه 5G). نتایج این تستها در جدول زیر خلاصه شده:
مورد تست
الگوریتم
نرخ توقف ویدیو (Stalling Rate)
کیفیت دریافتی (Mbps)
Case 1
GCC
1.83%
2.90
Sensitive-GCC
0.61%
2.83
L4S-CC
0.28%
2.32
L4S-GCC
0.32%
2.72
Case 2
GCC
3.42%
3.26
Sensitive-GCC
0.95%
3.19
L4S-CC
0.49%
2.43
L4S-GCC
0.62%
3.01
Case 3
GCC
2.65%
2.23
Sensitive-GCC
0.75%
2.05
L4S-CC
0.62%
1.71
L4S-GCC
0.68%
1.92
همونطور که توی جدول میبینید، الگوریتم L4S-GCC به طور چشمگیری عملکرد بهتری از GCC معمولی داشت. نرخ توقف ویدیو (Stalling Rate) که نشوندهنده تجربه کاربره، در الگوریتم L4S-GCC خیلی پایینتر بود. مثلا در سناریوی دوم، L4S-GCC نرخ توقف رو از ۳.۴۲ درصد به ۰.۶۲ درصد کاهش داد که یک بهبود ۲.۸۰ درصدی محسوب میشه. این یعنی کاربرها خیلی کمتر با صحنه فریز شده ویدیو مواجه میشن. درسته که کیفیت دریافتی (پهنای باند) L4S-GCC یه مقدار کمتر از GCC بود، اما این کاهش ناچیز در مقابل بهبود فوقالعاده در روان بودن پخش، کاملا ارزشش رو داشت.
نتایج در سناریوی لرزش تاخیر (Delay Jitter)
در شبکههای بیسیم، خیلی وقتها تاخیر بستهها ثابت نیست و کم و زیاد میشه (به این میگن Jitter). الگوریتم GCC چون بر اساس تغییرات تاخیر کار میکنه، این Jitter رو با ازدحام اشتباه میگیره و بیدلیل سرعتش رو کم میکنه که باعث هدر رفتن پهنای باند میشه. اما L4S-GCC چون اطلاعات دقیق صف رو از طریق ECN میگیره، گول این Jitter رو نمیخوره. نتایج تست در این سناریو واقعا جالب بود:
پیکربندی لرزش تاخیر
الگوریتم
کیفیت دریافتی (Mbps)
بهرهوری پهنای باند
10/12/14/16 ms
GCC
4.12
82.4%
Sensitive-GCC
2.25
45.0%
L4S-CC
4.03
80.6%
L4S-GCC
4.69
93.8%
10/14/18/22 ms
GCC
3.73
74.6%
Sensitive-GCC
1.80
36.0%
L4S-CC
4.18
83.6%
L4S-GCC
4.72
94.4%
10/18/26/34 ms
GCC
2.86
57.2%
Sensitive-GCC
1.93
38.6%
L4S-CC
3.98
79.2%
L4S-GCC
4.43
88.6%
این نتایج به وضوح نشون میدن که L4S-GCC چقدر در مقابل Jitter مقاومه. در حالی که بهرهوری پهنای باند GCC با افزایش Jitter به شدت افت میکنه (تا ۵۷.۲ درصد)، L4S-GCC همچنان بالای ۸۸ درصد باقی میمونه. این یعنی L4S-GCC میتونه بهرهوری پهنای باند رو بین ۱۱.۴ تا ۳۱.۴ درصد نسبت به GCC بهبود بده. الگوریتم Sensitive-GCC هم که در سناریوی قبلی خوب عمل کرده بود، اینجا کاملا شکست خورد و نشون داد که در مقابل Jitter خیلی آسیبپذیره.
این مطالعه موردی به صورت عملی و با اعداد و ارقام ثابت میکنه که L4S و الگوریتمهای مبتنی بر اون، فقط یک ایده قشنگ نیستن، بلکه یک راه حل واقعی برای بهبود چشمگیر تجربه ما از اپلیکیشنهای زنده و حساس به تاخیر در شبکههای پرچالش امروزی هستن.