آموزش‌های کلادفلر به‌زودی در این بخش قرار داده می‌شود.

برچسب: اسکرپینگ

  • آشنایی و کار با سرور دیتابیس مای‌اس‌کیو‌ال MySQL

    قبل از هر چیزی، بیاید کلمه‌ها رو بشکافیم تا همه چیز روشن بشه. مای‌اس‌کیو‌ال یه «سیستم مدیریت دیتابیس رابطه‌ای اوپن سورس» یا به قول خارجی‌ها RDBMS هست. میدونم، اسمش ترسناکه، ولی قول میدم خیلی ساده‌اس.

    دیتابیس یعنی چی؟

    خیلی ساده، دیتابیس یه انبار خیلی بزرگ و مرتب برای نگهداری اطلاعاته. هر نرم‌افزاری نیاز به یه همچین انباری داره. مثلا وقتی یه چیزی رو تو گوگل سرچ میکنید، وارد اکانتتون میشید، یا یه تراکنش مالی انجام میدید، یه دیتابیس این اطلاعات رو ذخیره میکنه تا بعدا بشه دوباره بهش دسترسی داشت. مای‌اس‌کیو‌ال توی این کار استاده.

    مدل رابطه‌ای یا Relational یعنی چی؟

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

    این ساختار منطقی، که بهش میگن «اسکیما» (Schema)، تعریف میکنه که داده‌ها چطور سازماندهی بشن و جدول‌های مختلف چه رابطه‌ای با هم دارن. مثلا میشه تعریف کرد که هر کاربر میتونه چند تا محصول رو بخره. اینجوری برنامه‌نویس‌ها و مدیرای دیتابیس میتونن خیلی راحت داده‌ها رو ذخیره، بازیابی و تحلیل کنن. از متن ساده و عدد و تاریخ گرفته تا چیزهای جدیدتر مثل JSON و وکتورها.

    SQL چیه؟

    خب، حالا که یه انبار مرتب داریم، چطوری باهاش حرف بزنیم؟ چطوری بهش بگیم «لیست همه کاربرایی که اهل تهران هستن رو بهم بده»؟ اینجا SQL وارد میشه. اس‌کیو‌ال (SQL) که مخفف Structured Query Language یا «زبان پرس‌وجوی ساختاریافته» هست، یه زبان برنامه‌نویسیه که برای بازیابی، آپدیت، حذف و کلا مدیریت داده‌ها توی دیتابیس‌های رابطه‌ای استفاده میشه. مای‌اس‌کیو‌ال هم اسمش رو از همین SQL گرفته و از این زبان برای مدیریت و پرس‌وجو از داده‌ها استفاده میکنه.

    تلفظ درستش چیه؟

    تلفظ رسمی این اسم «مای‌اس‌کیو‌ال» (My S-Q-L) هست، ولی خیلی‌ها بهش «مای‌سیکوئل» (My Sequel) هم میگن که یه تلفظ رایجه.

    پس به طور خلاصه، مای‌اس‌کیو‌ال یه سیستم مدیریت دیتابیسه که داده‌ها رو توی جدول‌های منظم نگهداری میکنه و با استفاده از زبان SQL به ما اجازه میده با این داده‌ها کار کنیم.

    بخش دوم: چرا اینقدر طرفدار داره و کجاها به کار میاد؟

    محبوبیت مای‌اس‌کیو‌ال اتفاقی نیست. چند تا دلیل کلیدی وجود داره که باعث شده این سیستم بعد از حدود ۳۰ سال هنوزم یکی از اولین انتخاب‌ها برای خیلی از پروژه‌ها باشه.

    ۱. اوپن سورس بودن و جامعه بزرگ

    یکی از بزرگترین مزیت‌های مای‌اس‌کیو‌ال اینه که اوپن سورسه. یعنی چی؟ یعنی هر کسی میتونه نرم‌افزارش رو از اینترنت دانلود کنه و بدون هیچ هزینه‌ای ازش استفاده کنه. شرکت‌ها حتی میتونن کد منبعش رو تغییر بدن تا با نیازهای خاص خودشون هماهنگ بشه.

    این نرم‌افزار تحت مجوزی به اسم GNU General Public License (GPL) منتشر میشه که یه سری قوانین مشخص داره. البته اگه شرکتی نخواد از این مجوز استفاده کنه یا بخواد کد مای‌اس‌کیو‌ال رو توی یه محصول تجاری قرار بده، میتونه نسخه تجاریش رو بخره.

    این اوپن سورس بودن باعث شده یه جامعه جهانی خیلی بزرگ و فعال دورش شکل بگیره. این جامعه کلی دانش و منبع تولید میکنه؛ از آموزش‌های مختلف گرفته تا راهنمایی توی فروم‌ها. همین جامعه با تست کردن نرم‌افزار توی سناریوهای مختلف، به پیدا کردن و رفع باگ‌ها کمک زیادی کرده و مای‌اس‌کیو‌ال رو به یه سیستم خیلی قابل اعتماد تبدیل کرده.

    ۲. کارایی، پایداری و مقیاس‌پذیری بالا

    مای‌اس‌کیو‌ال به سریع، قابل اعتماد و مقیاس‌پذیر بودن معروفه. این سیستم از اول برای این ساخته شده که بتونه دیتابیس‌های بزرگ رو به سرعت مدیریت کنه و سال‌هاست که توی محیط‌های کاری خیلی سنگین و حساس استفاده میشه.

    • مقیاس‌پذیری (Scalability): یکی از ویژگی‌های مهم مای‌اس‌کیو‌ال، معماری تکثیر (Replication) داخلیشه. این ویژگی به شرکت‌های بزرگی مثل فیسبوک اجازه میده که اپلیکیشن‌هاشون رو برای پشتیبانی از میلیاردها کاربر مقیاس‌پذیر کنن. یعنی وقتی کسب‌وکار رشد میکنه و تعداد کاربرها زیاد میشه، مای‌اس‌کیو‌ال هم میتونه پا به پاش بزرگ بشه.
    • تراکنش‌های ACID: برنامه‌نویس‌ها روی دو تا قابلیت کلیدی مای‌اس‌کیو‌ال خیلی حساب میکنن: یکی همین مقیاس‌پذیری و اون یکی پشتیبانی از تراکنش‌های ACID. این کلمه مخفف چهارتا خاصیته: «اتمی بودن (Atomicity)، سازگاری (Consistency)، ایزوله‌سازی (Isolation) و دوام (Durability)». این چهارتا ویژگی تضمین میکنن که تراکنش‌های دیتابیس به شکل قابل اعتماد و دقیقی پردازش بشن. با این قابلیت، مای‌اس‌کیو‌ال میتونه تضمین کنه که همه تغییرات داده‌ها به شکلی پایدار و مطمئن انجام میشن، حتی اگه وسط کار سیستم به مشکل بخوره یا برق بره.

    ۳. سادگی در استفاده و سازگاری گسترده

    خیلی‌ها مای‌اس‌کیو‌ال رو به خاطر سادگی در نصب و استفاده تحسین میکنن. در عین حال، به اندازه‌ای قابل اعتماد و مقیاس‌پذیره که برای سازمان‌هایی با حجم داده بسیار بزرگ و تعداد کاربران زیاد هم مناسبه.

    این سیستم با پلتفرم‌های تکنولوژی و زبان‌های برنامه‌نویسی مختلفی مثل جاوا، پایتون، پی‌اچ‌پی (PHP) و جاوااسکریپت سازگاری بالایی داره. یه نکته جالب دیگه اینه که از تکثیر (replication) بین نسخه‌های مختلف هم پشتیبانی میکنه. یعنی یه اپلیکیشن که با مای‌اس‌کیو‌ال نسخه ۵.۷ کار میکنه، میتونه به راحتی به نسخه ۸.۰ تکثیر بشه.

    علاوه بر این، مای‌اس‌کیو‌ال انعطاف‌پذیری خوبی برای توسعه اپلیکیشن‌های دیتابیس سنتی (SQL) و اپلیکیشن‌های بدون اسکیما (NoSQL) داره. این یعنی برنامه‌نویس‌ها میتونن داده‌های رابطه‌ای و اسناد JSON رو توی یک دیتابیس و یک اپلیکیشن با هم ترکیب کنن.

    ۴. مقرون به صرفه بودن

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

    کاربردهای واقعی مای‌اس‌کیو‌ال

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

    • وب‌سایت‌های فروشگاهی (Ecommerce): برای مدیریت اطلاعات مشتریان و محصولات.
    • سیستم‌های مدیریت محتوا (CMS): برای ارائه محتوای وب‌سایت‌ها.
    • اپلیکیشن‌های مالی: برای ردیابی امن تراکنش‌ها و داده‌های مالی.
    • شبکه‌های اجتماعی: برای ذخیره پروفایل کاربران و تعاملاتشون.

    بخش سوم: سرور چیه و چرا مای‌اس‌کیو‌ال بهش نیاز داره؟

    خب، حالا که فهمیدیم مای‌اس‌کیو‌ال چیه، بیاید در مورد یه مفهوم کلیدی دیگه حرف بزنیم: «سرور». شاید شنیده باشید که میگن «سرور مای‌اس‌کیو‌ال». این یعنی چی؟

    مفهوم موتور (Engine) دیتابیس

    هر سیستم مدیریت دیتابیس رابطه‌ای (RDBMS) یه چیزی به اسم «موتور» (Engine) داره. این موتور در واقع اون بخشیه که کوئری‌های شما رو تفسیر میکنه و نتایج رو برمیگردونه. بدون این موتور، دیتابیس شما چیزی بیشتر از یه فضای ذخیره‌سازی ساده نیست. به این موتور به طور کلی میگن «سرور».

    این سرور لزوما نباید روی یه سخت‌افزار جداگونه و اختصاصی اجرا بشه، هرچند که معمولا این کار مزایای زیادی داره. اکثر RDBMSها یه نسخه‌ای از موتورشون رو دارن که میشه به صورت محلی (locally) روی همون کامپیوتر خودتون اجرا کرد. پس در اصل، شما همیشه به این موتور نیاز دارید تا بتونید از داده‌هاتون پرس‌وجو کنید، حتی اگه در قالب یه کتابخونه (library) محلی یا یه فایل اجرایی روی سیستم خودتون باشه.

    چرا از یه فایل متنی ساده استفاده نکنیم؟

    شاید بپرسید چرا اینقدر پیچیده‌اش کنیم؟ چرا داده‌ها رو توی یه فایل متنی ساده نریزیم؟ خب، میتونید این کار رو بکنید. میتونید داده‌هاتون رو سریالایز کنید و توی یه فایل متنی ذخیره کنید. ولی وقتی این کار رو میکنید، تمام مسئولیت ذخیره‌سازی و مدیریت داده‌ها میفته گردن کد خودتون.

    یه مفهوم کلیدی توی دیتابیس‌های مبتنی بر SQL، همون اصول ACID هست که قبلا در موردش حرف زدیم. سرور دیتابیس این توانایی رو داره که چندین کوئری همزمان رو مدیریت و صف‌بندی کنه و در عین حال، این اصول رو حفظ کنه. دیتابیس‌ها برای کارایی بالا به حافظه (RAM) و پردازنده (CPU) زیادی نیاز دارن و باید به فضای ذخیره‌سازی با تاخیر کم (low-latency) دسترسی داشته باشن.

    مدل کلاینت/سرور

    مای‌اس‌کیو‌ال یه سیستم کلاینت/سرور هست. این سیستم از یه سرور SQL چند رشته‌ای (multithreaded) تشکیل شده که از بک‌اند‌های مختلفی پشتیبانی میکنه. در کنارش، چندین برنامه و کتابخونه کلاینت، ابزارهای مدیریتی و رابط‌های برنامه‌نویسی اپلیکیشن (API) متنوعی هم وجود داره.

    اگه دیتابیس شما فقط قراره توسط یه برنامه و روی یه دستگاه مستقل استفاده بشه، شاید استفاده از یه نسخه محلی RDBMS کافی باشه. اما توی دنیای متصل امروزی، خیلی از اپلیکیشن‌ها از این سود میبرن که چندین دستگاه از یک دیتابیس مشترک استفاده کنن. وقتی این اتفاق میفته، شما یا باید یکی از دستگاه‌ها رو به عنوان سرور اختصاص بدید (و احتمالا همیشه روشنش بذارید)، یا سرور رو روی یه سخت‌افزار اختصاصی یا توی فضای ابری (cloud) اجرا کنید.

    چرا سرور رو روی یه سخت‌افزار جدا میذارن؟

    چند تا دلیل مهم برای این کار وجود داره:

    1. منابع سیستم: دیتابیس‌ها به شدت به ورودی/خروجی (IO) وابسته‌ان. اگه حافظه کافی برای بارگذاری همه چیز توی رم وجود نداشته باشه، باید از فایل سیستم استفاده بشه. ممکنه روی کامپیوتر شما منابع کافی برای اجرای همزمان دیتابیس و برنامه اصلی با کارایی مطلوب وجود نداشته باشه.
    2. امنیت: نسخه‌های تجاری و سازمانی موتورهای دیتابیس برای رسیدن به کارایی بالاتر، نیاز دارن که به سطح پایین‌تری از سیستم دسترسی داشته باشن و امتیازات امنیتی بیشتری بگیرن. این موضوع میتونه یه ریسک امنیتی بزرگ برای داده‌های شرکتی باشه. به همین دلیل، موتور دیتابیس معمولا روی یه سرور اختصاصی با یه زمینه امنیتی خاص میزبانی میشه که کاربرای عادی اصلا اجازه لاگین به کنسولش رو ندارن. چون این سرورها میتونن آسیب‌پذیر باشن، معمولا از فایروال‌ها برای مقاوم‌سازیشون در برابر حملات استفاده میشه.
    3. مدیریت: مدیریت همه این موارد روی یه کامپیوتر شخصی یا ایستگاه کاری میتونه خیلی دردسرساز باشه.

    بحث مرکزی‌سازی: آیا همیشه خوبه که یه سرور دیتابیس برای همه سرویس‌ها داشته باشیم؟

    یه سوالی که برای خیلی از مدیران سیستم پیش میاد اینه که آیا بهتره یه ماشین مجازی (VM) یا سرور اختصاصی فقط برای مای‌اس‌کیو‌ال داشته باشیم و بقیه سرویس‌ها (مثل Nextcloud و…) به اون وصل بشن، یا اینکه برای هر سرویس، یه سرور مای‌اس‌کیو‌ال جدا روی همون ماشین مجازی خودش نصب کنیم؟

    جواب کوتاه اینه که «نه، مرکزی‌سازی همیشه بهترین راه نیست». رویکردهای مختلفی برای شرایط مختلف وجود داره و این یه تصمیمه که به نیازهای خاص هر پروژه بستگی داره.

    بخش چهارم: چطوری مای‌اس‌کیو‌ال رو به دست بیاریم؟

    خب، حالا که با مفاهیم اولیه آشنا شدیم، بیاید ببینیم چطوری میشه مای‌اس‌کیو‌ال رو دانلود و نصب کرد. مای‌اس‌کیو‌ال در چند نسخه مختلف ارائه میشه که هر کدوم برای یه سری کاربردها مناسبن.

    نسخه‌های مختلف مای‌اس‌کیو‌ال

    • MySQL Enterprise Edition: این نسخه جامع‌ترین مجموعه از ویژگی‌های پیشرفته، ابزارهای مدیریتی و پشتیبانی فنی رو برای مای‌اس‌کیو‌ال شامل میشه. هدفش رسیدن به بالاترین سطح از مقیاس‌پذیری، امنیت، قابلیت اطمینان و آپ‌تایم (uptime) هست.
    • MySQL NDB Cluster CGE: این نسخه یه دیتابیس تراکنشی اوپن سورس و real-time هست که برای دسترسی سریع و همیشه روشن به داده‌ها در شرایطی با توان عملیاتی بالا (high throughput) طراحی شده. این نسخه شامل MySQL NDB Cluster Manager و همه چیزهایی که در نسخه Enterprise Edition هست هم میشه.
    • MySQL Community (GPL) Downloads: این همون نسخه اوپن سورس و رایگان مای‌اس‌کیو‌ال هست که تحت مجوز GPL منتشر میشه و اکثر افراد از این نسخه برای پروژه‌هاشون استفاده میکنن.
    • MySQL برای ISVها، OEMها و VARها: جالبه بدونید که بیش از ۲۰۰۰ تا ISV (فروشنده نرم‌افزار مستقل)، OEM (سازنده تجهیزات اصلی) و VAR (نماینده فروش با ارزش افزوده) به مای‌اس‌کیو‌ال به عنوان دیتابیس تعبیه شده (embedded) در محصولاتشون اعتماد میکنن. این کار بهشون کمک میکنه تا اپلیکیشن‌ها، سخت‌افزارها و دستگاه‌هاشون رو رقابتی‌تر کنن، سریع‌تر به بازار عرضه کنن و هزینه تمام شده کالاهاشون رو کاهش بدن.

    راهنمای نصب با MySQL Installer

    برای نصب مای‌اس‌کیو‌ال روی ویندوز، یه ابزار خیلی راحت به اسم MySQL Installer وجود داره. این ابزار یه تجربه نصب جادوگر-محور (wizard-based) رو برای تمام نیازهای نرم‌افزاری مای‌اس‌کیو‌ال شما فراهم میکنه.

    • نسخه 8.0.43: اینستالرهای نسخه‌های ۵.۷ تا ۸.۰ شامل آخرین ورژن‌های محصولات مای‌اس‌کیو‌ال هستن.
    • نکته مهم در مورد نسخه‌های جدید: توجه داشته باشید که سری ۸.۰ آخرین سری هست که MySQL Installer داره. از نسخه ۸.۱ به بعد، باید از فایل MSI یا آرشیو Zip خود محصول مای‌اس‌کیو‌ال برای نصب استفاده کنید. همچنین، سرور مای‌اس‌کیو‌ال نسخه ۸.۱ و بالاتر، ابزاری به اسم MySQL Configurator رو هم همراه خودش داره که به پیکربندی سرور کمک میکنه.
    کدوم فایل رو انتخاب کنیم؟

    وقتی میخواید اینستالر رو دانلود کنید، دو تا گزینه اصلی دارید:

    1. mysql-installer-web-community: اگه موقع اجرای اینستالر به اینترنت وصل هستید، این فایل رو انتخاب کنید. این نسخه حجم کمتری داره و فایل‌های مورد نیاز رو موقع نصب دانلود میکنه.
    2. mysql-installer-community: اگه موقع اجرای اینستالر به اینترنت دسترسی ندارید، این فایل رو انتخاب کنید. این نسخه همه فایل‌های لازم رو داخل خودش داره و حجمش بیشتره.

    یه نکته فنی هم اینه که خود برنامه MySQL Installer ۳۲ بیتی هست، ولی میتونه هم باینری‌های ۳۲ بیتی و هم ۶۴ بیتی رو نصب کنه.

    بخش پنجم: یه کیس استادی واقعی: ساختن یه سرور قدرتمند برای مای‌اس‌کیو‌ال

    تئوری کافیه، بیاید یه مثال واقعی رو با هم بررسی کنیم. فرض کنید صاحب یه کسب‌وکار کوچیک هستید و میخواید یه سرور دیتابیس جدید برای میزبانی یه دیتابیس تحلیل صنعت و تحقیقات بازار راه بندازید. این سناریو از یه فروم واقعی به اسم Level1Techs برداشته شده.

    مشخصات دیتابیس مورد نظر:

    • نسخه مای‌اس‌کیو‌ال: ۸.۴
    • اندازه دیتابیس: حدود ۱ ترابایت، پخش شده در حدود ۱۵۰ تا جدول.
    • مشخصات جداول: طولانی‌ترین جدول حدود ۱۰ میلیارد ردیف داره و میانگین طول جداول ۱۰۰ میلیون ردیفه.
    • نوع کاربری:
      • نوشتن (Writes) خیلی کم: به جز بارگذاری اولیه، آپدیت‌ها به صورت ساعتی یا روزانه توسط خزنده‌های وب (crawlers) مختلف انجام میشه و فقط یه کاربر مینویسه.
      • کوئری‌های (Queries) کم ولی پیچیده: کوئری‌ها شامل تعداد زیادی JOIN و WHERE هستن و فقط یه کاربر برای گزارش‌گیری روزانه و تحلیل‌های موردی ازشون استفاده میکنه.

    سخت‌افزار جدید پیشنهادی:

    بر اساس این نیازها، کاربر یه سخت‌افزار خیلی جالب رو پیشنهاد داده. بیاید قطعاتش رو با هم بررسی کنیم:

    • پردازنده (CPU): AMD Ryzen 9 7900X
      • چرا این انتخاب شده؟ بر اساس نوع کاربری که کوئری‌های پیچیده ولی تکی داره، عملکرد تک‌هسته‌ای (single core performance) خیلی کلیدیه. این پردازنده میتونه تا فرکانس ۵.۶ گیگاهرتز بوست بشه که برای این کار عالیه.
    • حافظه (RAM): 4x 32GB DDR5 ECC UDIMM 2Rx8 4800
      • چرا ECC؟ عبارت ECC مخفف Error-Correcting Code هست. این نوع رم میتونه خطاهای کوچیک حافظه رو به صورت خودکار شناسایی و تصحیح کنه. برای یه سرور دیتابیس که پایداری داده‌ها حیاتیه، استفاده از رم ECC یه تصمیم هوشمندانه است.
    • مادربورد (Motherboard): AsRock Rack B650D4U-2L2T/BCM
    • فضای ذخیره‌سازی (Storage):
      • درایوهای اصلی: 4x Samsung PM9A3 1920GB 2.5″ in a ZFS RAID 10
      • کش نوشتن (SLOG): 1x Intel Optane P4800X as ZFS SLOG vdev
    • سیستم عامل (OS): Debian 12

    مقایسه با سخت‌افزار فعلی:

    سخت‌افزار فعلی این کاربر یه Intel Xeon E3-1230 v6 با ۳۲ گیگابایت رم غیر-ECC و یه SSD معمولی بوده. ارتقای پیشنهادی یه جهش عظیم در عملکرد محسوب میشه.

    یه سوال مهم: Ryzen یا EPYC؟

    کاربر یه سوال خوب هم پرسیده: آیا بهتر نیست به جای این سیستم، یه سرور مبتنی بر پردازنده استفاده شده EPYC (مثلا مدل 7F52) ببندم؟

    • مزایای EPYC: این پردازنده ۴ برابر کش L3 بیشتری داره و از رم بیشتری هم پشتیبانی میکنه.
    • معایب EPYC: فرکانس بوستش فقط تا ۳.۹ گیگاهرتز میرسه، در حالی که Ryzen تا ۵.۶ گیگاهرتز میره.

    اینجا یه بده‌بستان (trade-off) وجود داره. برای کاربری خاص این شخص که عملکرد تک‌هسته‌ای مهمه، Ryzen 7900X با فرکانس بالاترش احتمالا انتخاب بهتریه. اما برای سناریوهایی با تعداد کاربران همزمان زیاد، EPYC با کش و هسته‌های بیشترش میتونه برنده باشه.

    بخش ششم: مدیریت مای‌اس‌کیو‌ال با وب‌مین (Webmin) – یه راهنمای کامل

    خب، سرور رو راه انداختیم، مای‌اس‌کیو‌ال رو هم نصب کردیم. حالا چطوری مدیریتش کنیم؟ یکی از ابزارهای عالی برای این کار وب‌مین (Webmin) هست. وب‌مین یه پنل تحت وب هست که به شما اجازه میده دیتابیس‌ها، جدول‌ها، کاربران و خیلی چیزای دیگه رو از طریق یه رابط کاربری گرافیکی ساده مدیریت کنید. بیاید ببینیم چطوری میشه باهاش کار کرد.

    شروع کار با ماژول مای‌اس‌کیو‌ال در وب‌مین

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

    ساختن یه دیتابیس جدید

    وقتی مای‌اس‌کیو‌ال برای اولین بار نصب میشه، یه دیتابیس به اسم mysql ساخته میشه که اطلاعات مربوط به کاربران و دسترسی‌ها رو تو خودش نگه میداره. بهتره برای داده‌های خودتون یه دیتابیس جدا بسازید. مراحلش اینه:

    1. روی لینک «Create a new database» کلیک کنید.
    2. یه اسم برای دیتابیس جدیدتون توی فیلد «Database name» وارد کنید. اسم باید فقط شامل حروف و اعداد باشه و فاصله نداشته باشه.
    3. روی دکمه «Create» کلیک کنید. به همین راحتی!

    ساختن یه جدول جدید

    حالا که دیتابیس رو داریم، باید توش جدول بسازیم.

    1. روی آیکون دیتابیسی که ساختید کلیک کنید.
    2. تعداد فیلدهایی (ستون‌هایی) که میخواید جدولتون داشته باشه رو وارد کنید و روی دکمه «Create a new table» کلیک کنید.
    3. یه اسم برای جدولتون توی فیلد «Table name» وارد کنید.
    4. نوع جدول (Table type): اینجا میتونید نوع موتور ذخیره‌سازی جدول رو انتخاب کنید. رایج‌ترین‌ها اینان:
    5. تعریف فیلدها (Initial fields):
    6. وقتی همه فیلدها رو تعریف کردید، روی دکمه «Create» کلیک کنید.

    مشاهده و ویرایش محتوای جدول

    اگه میخواید داده‌های داخل یه جدول رو ببینید، ویرایش کنید، یا ردیف جدیدی اضافه کنید:

    1. روی آیکون دیتابیس و بعد روی آیکون جدول مورد نظرتون کلیک کنید.
    2. روی دکمه «View Data» کلیک کنید.
    3. لیستی از ردیف‌های جدول به شما نشون داده میشه. اگه جدول شما کلید اصلی داشته باشه، میتونید:

    نکته مهم: اگه یه جدول کلید اصلی نداشته باشه، وب‌مین نمیتونه ردیف‌های خاصی رو برای ویرایش یا حذف شناسایی کنه. پس همیشه برای جدول‌هاتون یه کلید اصلی تعریف کنید.

    پشتیبان‌گیری (Backup) و بازیابی (Restore)

    بکاپ گرفتن از دیتابیس‌های مهم یکی از حیاتی‌ترین کارهاست. وب‌مین این کار رو خیلی ساده کرده.

    برای ساختن بکاپ:

    1. وارد صفحه دیتابیس مورد نظر بشید.
    2. روی دکمه «Backup Database» کلیک کنید.
    3. توی فیلد «Backup to file»، آدرس فایلی که میخواید بکاپ توش ذخیره بشه رو وارد کنید (مثلا /tmp/backup.sql).
    4. یه گزینه مهم به اسم «Add drop table statements to backup?» وجود داره. اگه این رو روی «Yes» بذارید، موقع بازیابی بکاپ، اگه جدولی با همون اسم از قبل وجود داشته باشه، اول حذف میشه و بعد داده‌های جدید جایگزین میشن. این برای بکاپ‌های معمولی خوبه. اگه روی «No» بذارید، داده‌های بکاپ به داده‌های موجود اضافه میشن.
    5. روی «Backup Now» کلیک کنید.

    فایل بکاپ مای‌اس‌کیو‌ال در واقع یه فایل متنیه که پر از دستورات SQL برای ساختن دوباره جدول‌ها و وارد کردن داده‌هاست.

    برای بازیابی بکاپ:

    1. وارد صفحه دیتابیسی بشید که میخواید بکاپ رو توش بازیابی کنید.
    2. روی دکمه «Execute SQL» کلیک کنید.
    3. به بخش «Select SQL commands file to execute on database» برید.
    4. فایل بکاپتون رو از روی سرور یا کامپیوتر خودتون انتخاب کنید.
    5. روی «Execute» کلیک کنید.

    مدیریت کاربران و دسترسی‌ها (Permissions)

    مای‌اس‌کیو‌ال سیستم کاربران و دسترسی‌های مخصوص به خودشو داره که از کاربران سیستم عامل جداست. شما میتونید برای هر کاربر تعریف کنید که به کدوم دیتابیس‌ها، از کدوم کامپیوترها (هاست‌ها) و با چه سطح دسترسی (مثلا فقط خوندن، یا خوندن و نوشتن) بتونه وصل بشه.

    برای مدیریت کاربران، روی آیکون «User Permissions» در صفحه اصلی ماژول کلیک کنید. از اونجا میتونید کاربر جدید بسازید، پسوردها رو عوض کنید، و دسترسی‌ها رو برای هر کاربر به صورت دقیق مشخص کنید. مثلا برای یه اپلیکیشن، بهتره یه کاربر جدا بسازید که فقط به دیتابیس همون اپلیکیشن دسترسی داشته باشه و فقط بتونه کارهای لازم مثل خوندن و نوشتن رو انجام بده.

    بخش هفتم: مای‌اس‌کیو‌ال در دنیای ابری: آشنایی با HeatWave

    حالا که با نسخه سنتی مای‌اس‌کیو‌ال آشنا شدیم، بیاید یه نگاهی به آینده و نسخه‌های ابریش بندازیم. اوراکل یه سرویس ابری خیلی قدرتمند برای مای‌اس‌کیو‌ال به اسم HeatWave ارائه میده.

    HeatWave چیه؟

    HeatWave در واقع یه شتاب‌دهنده کوئری درون-حافظه‌ای (in-memory) برای دیتابیس مای‌اس‌کیو‌ال هست. این تنها سرویس دیتابیس ابری مای‌اس‌کیو‌اله که چنین شتاب‌دهنده‌ای رو ارائه میده و میتونه تراکنش‌ها (transactions) رو با تحلیل‌های همزمان (real-time analytics) ترکیب کنه.

    این یعنی چی؟ یعنی دیگه نیازی به فرآیندهای پیچیده، زمان‌بر و پرهزینه ETL (Extract, Transform, Load) برای انتقال داده‌ها به یه دیتابیس تحلیلی جداگونه نیست. شما میتونید روی همون داده‌های تراکنشی خودتون، به صورت همزمان تحلیل‌های سنگین انجام بدید. این کار باعث افزایش فوق‌العاده زیاد عملکرد مای‌اس‌کیو‌ال برای کارهای تحلیلی و ترکیبی میشه.

    ویژگی‌های پیشرفته HeatWave:

    • HeatWave AutoML: به توسعه‌دهنده‌ها و تحلیل‌گرای داده اجازه میده که مدل‌های یادگیری ماشین (Machine Learning) رو به صورت کاملا خودکار داخل HeatWave MySQL بسازن، آموزش بدن، پیاده‌سازی کنن و خروجی‌هاشون رو توضیح بدن.
    • HeatWave GenAI: کاربران میتونن از هوش مصنوعی مولد (Generative AI) یکپارچه و خودکار هم استفاده کنن.
    • HeatWave Autopilot: این ویژگی با استفاده از اتوماسیون مبتنی بر یادگیری ماشین، به صورت خودکار به بهبود عملکرد مای‌اس‌کیو‌ال و کاهش هزینه‌ها کمک میکنه، بدون اینکه به تخصص در زمینه تیونینگ دیتابیس نیاز باشه.

    این سرویس روی پلتفرم‌های ابری مختلفی مثل Oracle Cloud Infrastructure (OCI)، Amazon Web Services (AWS) و Microsoft Azure در دسترسه.

    بخش هشتم: وقتی همه چیز خراب میشه: راهنمای عیب‌یابی (Troubleshooting)

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

    چطور بفهمیم سرور مای‌اس‌کیو‌ال کار میکنه یا نه؟

    گاهی وقتا یه برنامه نمیتونه به دیتابیس وصل بشه و خطای «Unable to connect to MySQL server» میده. اولین قدم اینه که ببینیم اصلا سرور مای‌اس‌کیو‌ال در حال اجرا هست یا نه. چند تا راه برای این کار توی ترمینال لینوکس وجود داره:

    • sudo service mysql status یا sudo service mysqld status
    • ps aux | grep mysql (این دستور همه پروسه‌هایی که کلمه mysql توشون هست رو نشون میده)
    • lsof -i :3306 (این دستور چک میکنه که آیا پروسه‌ای به پورت پیش‌فرض مای‌اس‌کیو‌ال یعنی ۳۳۰۶ گوش میده یا نه)

    یه نکته مهم: «پروسه در حال اجراست» همیشه به معنی «سرویس در دسترس است» نیست. ممکنه پروسه بالا باشه ولی به خاطر مشکلات پیکربندی یا چیزای دیگه، از بیرون نشه بهش وصل شد.

    اگه سرور در حال اجرا بود، مشکل میتونه از جای دیگه باشه. مثلا:

    • خطای احراز هویت: نام کاربری یا پسورد اشتباهه.
    • اسم اشتباه دیتابیس: اسم دیتابیسی که میخواید بهش وصل بشید رو اشتباه وارد کردید.
    • فایروال: ممکنه فایروال سرور یا کلاینت، اتصال به پورت ۳۳۰۶ رو مسدود کرده باشه.

    بهترین راه برای تست، اینه که سعی کنید از طریق خود ترمینال به صورت دستی به مای‌اس‌کیو‌ال وصل بشید:

    mysql -u <username> -p <database-name>

    یه مشکل رایج در XAMPP (روی مک)

    یه مشکل رایج که برای توسعه‌دهنده‌ها پیش میاد، مخصوصا اونایی که از پکیج‌هایی مثل XAMPP استفاده میکنن، اینه که مای‌اس‌کیو‌ال بعد از ری‌استارت کردن کامپیوتر دیگه روشن نمیشه. توی پنل مدیریت XAMPP چراغش قرمز میمونه و وقتی سعی میکنید وارد phpMyAdmin بشید، با خطای #2002 - No such file or directory مواجه میشید.

    این مشکل معمولا به این دلیله که یه پروسه قدیمی از مای‌اس‌کیو‌ال هنوز توی پس‌زمینه در حال اجراست و جلوی اجرا شدن پروسه جدید رو میگیره. راه حلش اینه که اون پروسه قدیمی رو به صورت دستی از بین ببرید (kill کنید).

    راه حل قدم به قدم در ترمینال مک:

    1. ترمینال رو باز کنید و دستور sudo su رو تایپ کنید و پسوردتون رو وارد کنید تا دسترسی روت بگیرید.
    2. دستور ps aux | grep mysql رو وارد کنید. این دستور لیستی از پروسه‌های مربوط به مای‌اس‌کیو‌ال رو به شما نشون میده.
    3. توی لیست، باید شناسه پروسه (process ID یا PID) رو پیدا کنید. این یه عدد هست که معمولا در ستون دوم قرار داره.
    4. حالا با دستور kill -9 {process id} اون پروسه رو از بین ببرید. مثلا: kill -9 739.
    5. حالا به پنل XAMPP برگردید و دوباره سعی کنید مای‌اس‌کیو‌ال رو استارت کنید. به احتمال زیاد مشکل حل میشه.

    پرسش و پاسخ‌های متداول

    سوال: مای‌اس‌کیو‌ال چیست و چرا استفاده میشود؟

    جواب: مای‌اس‌کیو‌ال محبوب‌ترین دیتابیس اوپن سورس دنیاست. توسعه‌دهنده‌ها و مدیران دیتابیس از اون برای ذخیره، آپدیت و تحلیل داده‌ها در اپلیکیشن‌هاشون استفاده میکنن.

    سوال: تفاوت بین SQL و مای‌اس‌کیو‌ال چیست؟

    جواب: SQL یه زبان برنامه‌نویسیه که برای مدیریت و تحلیل داده‌های ذخیره شده در دیتابیس‌ها طراحی شده. مای‌اس‌کیو‌ال یه سیستم مدیریت دیتابیسه که بخشی از اسمش رو از SQL گرفته و از زبان SQL برای مدیریت داده‌ها در دیتابیس‌ها استفاده میکنه.

    سوال: آیا نسخه ابری از مای‌اس‌کیو‌ال وجود دارد؟

    جواب: بله. HeatWave MySQL یه سرویس دیتابیس کاملا مدیریت شده است و تنها سرویس ابریه که بر اساس MySQL Enterprise Edition ساخته شده. این سرویس عملکرد کوئری‌های مای‌اس‌کیو‌ال رو به شدت بهبود میده و تحلیل‌های همزمان روی داده‌های تراکنشی رو ممکن میکنه. این سرویس روی OCI، AWS و Microsoft Azure در دسترسه.

    سوال: مای‌اس‌کیو‌ال در مقایسه با سایر دیتابیس‌ها چگونه است؟

    جواب: مای‌اس‌کیو‌ال یه دیتابیس رابطه‌ای اوپن سورسه. این یعنی داده‌ها رو در ردیف‌ها و ستون‌ها ذخیره میکنه و روابط بین اونها رو در اسکیماها تعریف میکنه. دیتابیس‌های رابطه‌ای محبوب دیگه‌ای هم وجود دارن که اوپن سورس نیستن، مثل Oracle Database. همچنین دیتابیس‌های محبوبی وجود دارن که اصلا رابطه‌ای نیستن. به این‌ها دیتابیس‌های NoSQL میگن، مثل MongoDB.

    منابع

    • [2] Ryzen build for MySQL database server – Hardware Hub / Build a PC – Level1Techs Forums
    • [4] MySQL Database Server | Webmin
    • [6] php – MySQL Database won’t start in XAMPP Manager-osx – Stack Overflow
    • [8] Is centralizing MySQL/mariadb databases on one server best-practice ? : r/sysadmin
    • [10] ssh – How to check if MySQL server is working or not? – Server Fault
    • [1] MySQL
    • [3] MySQL: Understanding What It Is and How It’s Used
    • [5] MySQL :: MySQL Downloads
    • [7] MySQL :: Download MySQL Installer
    • [9] sql – Why do we use servers with MySql? – Stack Overflow

  • مانگو دی‌بی (MongoDB) چیست؟ راهنمای کامل سرور دیتابیس

    برای اینکه بفهمیم مانگو دی‌بی چیه، اول باید ببینیم قبل از اون دنیا چه شکلی بود. سال‌ها، پادشاه بی‌چون‌وچرای دنیای دیتابیس‌ها، سیستم‌های مدیریت دیتابیس رابطه‌ای یا همون RDBMS بودن. اسم‌هایی مثل MySQL رو حتما شنیدید. این دیتابیس‌ها مثل یک جدول اکسل خیلی بزرگ و منظم عمل می‌کنن. همه چیز در قالب جدول‌ها، سطرها و ستون‌های از پیش تعریف شده ذخیره میشه. مثلا اگه یه دیتابیس برای دانشجوها داشته باشید، یه جدول دارید به اسم «دانشجو» با ستون‌های مشخص: شماره دانشجویی، نام، نام خانوادگی و… . این ساختار خیلی منظم و دقیقه و برای خیلی از کارها، مثل سیستم‌های مالی و حسابداری که داده‌ها ساختار کاملا مشخصی دارن، عالیه.

    اما دنیای مدرن یه چالش جدید ایجاد کرد. با اومدن اپلیکیشن‌های موبایل، شبکه‌های اجتماعی و اینترنت اشیا (IoT)، ما با حجم عظیمی از داده‌هایی روبرو شدیم که همیشه ساختار مشخص و منظمی نداشتن. به این نوع داده‌ها میگن داده‌های بدون ساختار یا نیمه‌ساختاریافته. مثلا پست‌های یک شبکه اجتماعی رو در نظر بگیرید. یه پست میتونه فقط متن باشه، یکی دیگه عکس و متن داشته باشه، یکی ویدیو و کپشن، و یکی دیگه ترکیبی از همه اینها با کلی تگ و کامنت. جا دادن این همه تنوع توی جدول‌های خشک و بی‌روح SQL خیلی سخت و گاهی غیرممکن بود. توسعه‌دهنده‌ها به ابزاری نیاز داشتن که انعطاف‌پذیر باشه و بتونه با این داده‌های متنوع و نامنظم کار کنه. این‌جا بود که دیتابیس‌های NoSQL (که مخفف Not only SQL هست) وارد میدون شدن و مانگو دی‌بی یکی از پرچم‌دارهای این نسل جدیده.

    مانگو دی‌بی دقیقا چیه؟ خداحافظی با جدول‌ها

    خب، بریم سر اصل مطلب. مانگو دی‌بی یک دیتابیس از نوع NoSQL و سند-گرا (Document-Oriented) هست. این یعنی چی؟ یعنی به جای اینکه داده‌ها رو توی سطر و ستون ذخیره کنه، اون‌ها رو توی ساختارهایی شبیه به اسناد JSON ذخیره می‌کنه. اگه با برنامه‌نویسی جاوا اسکریپت آشنا باشید، حتما با JSON کار کردید. JSON یه فرمت متنی ساده برای نمایش داده‌ها به صورت زوج‌های «کلید-مقدار» هست. مثلا اطلاعات یه کاربر میتونه این شکلی باشه:

    {
      "نام": "سارا",
      "نام_خانوادگی": "رضایی",
      "سن": 25,
      "علاقمندی‌ها": ["کتاب", "موسیقی", "سفر"]
    }

    مانگو دی‌بی داده‌ها رو در قالبی به اسم BSON ذخیره می‌کنه که مخفف Binary JSON هست. BSON در واقع نسخه باینری یا دودویی JSON هست که کارایی بالاتری داره و از انواع داده‌ای بیشتری مثل تاریخ و داده‌های باینری هم پشتیبانی می‌کنه.

    مزیت اصلی این مدل سند-گرا، انعطاف‌پذیری فوق‌العاده اونه. هر سند میتونه ساختار منحصر به فرد خودش رو داشته باشه. مثلا توی همون دیتابیس کاربرها، یه کاربر میتونه فیلد «ایمیل» داشته باشه و یکی دیگه نداشته باشه. یا یه کاربر فیلد «آدرس» داشته باشه که خودش شامل چند فیلد دیگه مثل شهر و خیابون هست. این ویژگی باعث میشه مدل داده‌ای دیتابیس شما خیلی به مدل داده‌ای اپلیکیشن شما نزدیک باشه و کار کردن باهاش برای توسعه‌دهنده‌ها خیلی راحت‌تر و سریع‌تر بشه. دیگه لازم نیست برای هر تغییر کوچیکی، کل ساختار دیتابیس رو عوض کنید.

    معماری و اجزای اصلی مانگو دی‌بی

    برای اینکه بهتر با کارکرد مانگو دی‌بی آشنا بشیم، بیایید اجزای اصلیش رو بشناسیم و با معادلشون توی دنیای دیتابیس‌های رابطه‌ای (RDBMS) مقایسه کنیم. این مقایسه کمک می‌کنه تصویر واضح‌تری تو ذهنتون شکل بگیره.

    جزء در مانگو دی‌بیمعادل در RDBMSتوضیحات
    دیتابیس (Database)دیتابیس (Database)بالاترین سطح ساختار که مجموعه‌ای از کالکشن‌ها رو در خودش نگه میداره.
    کالکشن (Collection)جدول (Table)گروهی از اسناد مرتبط. مثلا کالکشن «کاربران» یا کالکشن «محصولات».
    سند (Document)سطر (Row)واحد اصلی ذخیره‌سازی داده که یک شی BSON با زوج‌های کلید-مقدار هست.
    فیلد (Field)ستون (Column)یک ویژگی یا صفت خاص درون یک سند که داده‌ها رو نگه میداره.

    همونطور که می‌بینید، مفاهیم خیلی شبیه به هم هستن، اما فلسفه پشتشون کاملا متفاوته. توی مانگو دی‌بی، یک کالکشن میتونه اسنادی با ساختارهای کاملا متفاوت رو در خودش جا بده. این یعنی شما یک «شمای پویا» یا Schema-less دارید. لازم نیست از قبل تعریف کنید که هر سند چه فیلدهایی باید داشته باشه.

    برای مثال، فرض کنید یک دیتابیس به اسم «GeeksforGeeks» داریم. داخل این دیتابیس دو تا کالکشن داریم و داخل هر کالکشن هم دو تا سند. داده‌های ما داخل این سندها و در قالب فیلدها ذخیره میشن.

    ویژگی‌های کلیدی که مانگو دی‌بی رو خاص می‌کنن

    حالا که با کلیات مانگو دی‌بی آشنا شدیم، بیایید ببینیم چه ویژگی‌هایی باعث شده این دیتابیس اینقدر محبوب بشه.

    ۱. انعطاف‌پذیری و مدل سند-گرا

    این مهم‌ترین ویژگی مانگو دی‌بی هست که قبلا هم بهش اشاره کردیم. مدل سند-گرا مستقیما به اشیا (objects) در کد شما نگاشت میشه. این یعنی لازم نیست کلی کد بنویسید تا داده‌ها رو از فرمت جدولی به فرمت شی‌گرا تبدیل کنید. این انعطاف‌پذیری به شما اجازه میده داده‌های مرتبط رو توی یک سند واحد جاسازی کنید (embed کنید) که این کار باعث افزایش سرعت و کاهش هزینه‌های محاسباتی میشه.

    ۲. مقیاس‌پذیری افقی (Horizontal Scaling) با شاردینگ (Sharding)

    یکی از بزرگترین چالش‌ها در دنیای داده‌های بزرگ (Big Data) اینه که وقتی حجم داده‌ها خیلی زیاد میشه، چطور سیستم رو مدیریت کنیم. دو راه کلی وجود داره: مقیاس‌پذیری عمودی (Vertical Scaling) و مقیای‌پذیری افقی (Horizontal Scaling).

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

    مانگو دی‌بی از پایه برای مقیاس‌پذیری افقی طراحی شده. این کار رو با استفاده از تکنیکی به اسم شاردینگ (Sharding) انجام میده. در شاردینگ، داده‌های یک کالکشن بزرگ بر اساس یک کلید مشخص (shard key) به تکه‌های کوچکتری به اسم «چانک» (chunk) تقسیم میشن و هر تکه روی یک سرور مجزا (که بهش میگن shard) ذخیره میشه. این کار باعث میشه فشار کاری بین چندین ماشین پخش بشه و سیستم بتونه حجم عظیمی از داده و درخواست رو مدیریت کنه. این ویژگی، مانگو دی‌بی رو برای اپلیکیشن‌های بزرگ و با رشد سریع، ایده‌ال می‌کنه.

    ۳. دسترسی بالا (High Availability) با تکثیر (Replication)

    هیچ‌کس دوست نداره سیستمش از کار بیفته. مانگو دی‌بی برای اطمینان از اینکه دیتابیس شما همیشه در دسترسه، از مکانیزمی به اسم تکثیر یا Replication استفاده می‌کنه. این کار از طریق چیزی به اسم مجموعه تکثیر (Replica Set) انجام میشه.

    یک Replica Set شامل چند کپی از داده‌های شما روی سرورهای مختلفه. این مجموعه یک سرور اصلی (Primary) و چند سرور ثانویه (Secondary) داره. تمام عملیات نوشتن (write) به صورت پیش‌فرض روی سرور اصلی انجام میشه. سرورهای ثانویه به طور مداوم داده‌ها رو از سرور اصلی کپی می‌کنن و یک نسخه به‌روز از داده‌ها رو نگه می‌دارن.

    حالا اگه سرور اصلی به هر دلیلی از کار بیفته (مثلا به خاطر مشکل سخت‌افزاری)، مجموعه تکثیر به طور خودکار یک «انتخابات» برگزار می‌کنه و یکی از سرورهای ثانویه رو به عنوان سرور اصلی جدید انتخاب می‌کنه. این فرآیند که بهش Failover میگن، باعث میشه سیستم شما با کمترین وقفه به کارش ادامه بده. جالبه بدونید که برای جلوگیری از دوپاره شدن مغز (split-brain) در انتخابات، اگه فقط یک سرور ثانویه داشته باشید، باید یک عضو سوم به اسم داور (Arbiter) هم به مجموعه اضافه بشه که فقط در انتخابات رای میده و داده‌ای ذخیره نمی‌کنه.

    ۴. کوئری‌های قدرتمند و ایندکس‌گذاری

    مانگو دی‌بی فقط برای ذخیره داده نیست، بلکه ابزارهای خیلی قدرتمندی برای دسترسی و تحلیل داده‌ها هم فراهم می‌کنه. شما می‌تونید کوئری‌های موردی (Ad hoc queries) بزنید، یعنی بدون نیاز به تعریف قبلی، هر نوع جستجویی رو روی داده‌ها انجام بدید. این کوئری‌ها می‌تونن بر اساس فیلدهای خاص، محدوده‌های مشخص (range query) و حتی عبارت‌های باقاعده (regular-expression) باشن.

    برای اینکه این کوئری‌ها سریع اجرا بشن، مانگو دی‌بی از ایندکس‌گذاری (Indexing) پشتیبانی می‌کنه. درست مثل فهرست آخر یک کتاب که به شما کمک می‌کنه سریع‌تر به یک مطلب برسید، ایندکس‌ها هم به دیتابیس کمک می‌کنن تا اسناد مورد نظر شما رو بدون جستجوی کامل در کل کالکشن پیدا کنه. شما می‌تونید روی هر فیلدی در سند، ایندکس اولیه (primary) یا ثانویه (secondary) بسازید.

    ۵. تجمیع داده‌ها (Aggregation)

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

    • پایپ‌لاین تجمیع (Aggregation Pipeline): این روش اصلی و پرکاربردترین روشه. مثل یک خط مونتاژ کار می‌کنه که داده‌ها از مراحل مختلفی عبور می‌کنن و در هر مرحله یک عملیات خاص روشون انجام میشه (مثلا گروه‌بندی، فیلتر کردن، محاسبه).
    • تابع Map-Reduce: این یک روش قدیمی‌تر برای پردازش دسته‌ای داده‌هاست، اما پایپ‌لاین تجمیع معمولا کارایی بهتری داره.
    • متدهای تجمیع تک‌منظوره: برای کارهای ساده‌تر مثل شمارش یا پیدا کردن مقادیر متمایز.

    ۶. ذخیره‌سازی فایل با GridFS

    مانگو دی‌بی یک محدودیت داره: هر سند نمی‌تونه بزرگتر از ۱۶ مگابایت باشه. پس اگه بخوایم فایل‌های بزرگ مثل ویدیو یا عکس‌های باکیفیت رو ذخیره کنیم چی؟ برای این کار، مانگو دی‌بی یک راه‌حل داخلی به اسم GridFS داره. GridFS فایل‌های بزرگ رو به تکه‌های کوچکتر (chunks) تقسیم می‌کنه و هر تکه رو به عنوان یک سند مجزا در کالکشن‌های مخصوص ذخیره می‌کنه. اینطوری شما می‌تونید از تمام ویژگی‌های مانگو دی‌بی مثل تکثیر و شاردینگ برای فایل‌های بزرگ هم استفاده کنید.

    ابزارهای اصلی برای کار با مانگو دی‌بی

    وقتی با مانگو دی‌بی کار می‌کنید، چند تا دستور و ابزار اصلی وجود داره که باید باهاشون آشنا باشید. این دستورها گاهی برای تازه‌کارها گیج‌کننده هستن، پس بیایید یک بار برای همیشه تفاوتشون رو یاد بگیریم. این بخش رو از تجربه یکی از کارمندهای خود شرکت مانگو دی‌بی به اسم Helen Scott براتون میگم که خودش هم اوایل با این دستورها سردرگم بوده.

    • mongod: این کلمه مخفف MongoDB Daemon هست و در واقع سرور اصلی دیتابیس شماست. مثل موتور ماشین می‌مونه. تا وقتی این سرور رو اجرا نکنید، هیچ دیتابیسی وجود نداره که بهش وصل بشید. این سرور به صورت پیش‌فرض روی پورت 27017 منتظر اتصال کلاینت‌ها می‌مونه.
    • mongo و mongosh: اینها شل (Shell) یا کلاینت شما هستن. یعنی ابزاری که باهاش به سرور (mongod) وصل میشید و دستوراتتون رو اجرا می‌کنید؛ مثل کوئری زدن، اضافه کردن داده یا کارهای مدیریتی. mongo نسخه قدیمی‌تر این شل بود که از نسخه ۵.۰ به بعد مانگو دی‌بی، منسوخ شده. نسخه جدید و بهبودیافته اون mongosh نام داره که ویژگی‌هایی مثل هایلایت کردن دستورات، تاریخچه دستورات و لاگین بهتر رو ارائه میده. پس اگه می‌خواید با دیتابیس تعامل داشته باشید، باید از mongosh استفاده کنید.
    • mongos: این یکی کمی پیشرفته‌تره و وقتی کاربرد داره که شما از شاردینگ استفاده می‌کنید. mongos مخفف MongoDB Shard هست و مثل یک پراکسی یا روتر عمل می‌کنه. وقتی شما داده‌هاتون رو روی چندین سرور (shard) پخش کردید، کلاینت شما (مثلا mongosh) نمی‌دونه که داده مورد نظرش روی کدوم سرور قرار داره. mongos اینجا وارد عمل میشه. کلاینت شما به mongos وصل میشه و mongos وظیفه داره کوئری‌ها و درخواست‌های نوشتن رو به شارد یا شاردهای درست هدایت کنه.

    پس به طور خلاصه: شما mongod رو اجرا می‌کنید تا سرور دیتابیس راه بیفته. بعد با mongosh بهش وصل میشید تا با داده‌هاتون کار کنید. و اگه دیتابیس شما خیلی بزرگ و شارد شده باشه، mongos هم به عنوان یک واسط بین شما و شاردها عمل می‌کنه.

    مانگو دی‌بی اطلس (MongoDB Atlas): دیتابیس در ابرها

    راه انداختن و مدیریت یک دیتابیس، مخصوصا اگه بزرگ و توزیع‌شده باشه، کار ساده‌ای نیست. باید نگران نصب، پیکربندی، پشتیبان‌گیری، امنیت و خیلی چیزهای دیگه باشید. شرکت مانگو دی‌بی برای حل این مشکل، یک سرویس ابری به اسم MongoDB Atlas رو ارائه کرده.

    اطلس یک سرویس «دیتابیس به عنوان سرویس» (DBaaS) کاملا مدیریت شده است. یعنی شما دیگه لازم نیست خودتون سرور راه بندازید یا نگران نگهداری اون باشید. فقط با چند کلیک یک کلاستر (مجموعه‌ای از سرورها) مانگو دی‌بی روی پلتفرم‌های ابری معروفی مثل Amazon Web Services (AWS)، Google Cloud Platform و Microsoft Azure ایجاد می‌کنید و شرکت مانگو دی‌بی تمام کارهای مدیریتی رو براتون انجام میده. این سرویس امکاناتی مثل پشتیبان‌گیری خودکار، مانیتورینگ، امنیت پیشرفته و مقیاس‌پذیری راحت رو فراهم می‌کنه و به شما اجازه میده روی توسعه اپلیکیشن خودتون تمرکز کنید. جالبه بدونید که تا سال ۲۰۲۴، ۷۰ درصد درآمد شرکت مانگو دی‌بی از همین سرویس اطلس بوده.

    موارد استفاده مانگو دی‌بی: کجا به کار میاد؟

    با توجه به ویژگی‌هایی که گفتیم، مانگو دی‌بی برای طیف وسیعی از اپلیکیشن‌های مدرن مناسبه. بیایید چند تا از کاربردهای رایجش رو با هم مرور کنیم:

    • سیستم‌های مدیریت محتوا (CMS): به خاطر انعطاف‌پذیری بالا، مانگو دی‌بی برای ذخیره انواع محتوا مثل مقالات، وبلاگ‌ها و سایت‌های خبری که ساختارهای متنوعی دارن، عالیه.
    • اپلیکیشن‌های موبایل: مانگو دی‌بی به راحتی میتونه داده‌های سمت بک‌اند اپلیکیشن‌های iOS و اندروید رو ذخیره کنه و به توسعه‌دهنده‌ها اجازه میده اپلیکیشن‌هاشون رو به صورت یکپارچه مقیاس‌پذیر کنن.
    • تجارت الکترونیک (E-commerce): فروشگاه‌های آنلاین میتونن از مانگو دی‌بی برای مدیریت کاتالوگ محصولات، پروفایل کاربران، سبدهای خرید و تاریخچه تراکنش‌ها استفاده کنن.
    • اینترنت اشیا (IoT): دستگاه‌های IoT حجم عظیمی از داده‌های سنسورها رو تولید می‌کنن. مقیاس‌پذیری و انعطاف‌پذیری مانگو دی‌بی اون رو برای ذخیره و پردازش این داده‌ها ایده‌ال می‌کنه.
    • بازی‌های آنلاین: ذخیره پروفایل بازیکنان، امتیازات، دستاوردها و وضعیت بازی که ساختارهای پیچیده‌ای دارن، با مدل سند-گرای مانگو دی‌بی خیلی راحت‌تره.
    • تحلیل داده‌های آنی (Real-Time Analytics): توانایی مانگو دی‌بی در پردازش سریع داده‌ها، اون رو برای سیستم‌های مانیتورینگ، تشخیص تقلب و ارائه پیشنهادهای شخصی‌سازی شده مناسب می‌کنه.
    • شبکه‌های اجتماعی: مدیریت روابط پیچیده بین کاربران، محتوای تولید شده توسط کاربر و تعاملات زنده، با مانگو دی‌بی به خوبی امکان‌پذیره.
    • کاربردهای داده‌های بزرگ (Big Data): مانگو دی‌بی به خوبی با ابزارهای اکوسیستم داده‌های بزرگ مثل Apache Hadoop و Spark ادغام میشه و برای کارهایی مثل مدل‌سازی ریسک و تحلیل‌های پیش‌بینی‌کننده استفاده میشه.

    مقایسه مانگو دی‌بی با رقبای سنتی: MySQL

    برای اینکه جایگاه مانگو دی‌بی رو بهتر درک کنیم، خوبه که اون رو با MySQL به عنوان نماینده دیتابیس‌های رابطه‌ای مقایسه کنیم.

    ویژگیمانگو دی‌بی (MongoDB)مای‌اس‌کیو‌ال (MySQL)
    مدل دادهسند-گرا (Document-Oriented)، بدون شما (Schema-less)رابطه‌ای (Relational)، با شمای از پیش تعریف شده
    زبان کوئریMQL (زبانی شبیه JSON)SQL (زبان کوئری ساختاریافته)
    مقیاس‌پذیریافقی (Horizontal) با شاردینگ داخلیعمدتا عمودی (Vertical)، مقیاس‌پذیری افقی پیچیده‌تره
    موارد استفادهداده‌های بزرگ، اپلیکیشن‌های مدرن، داده‌های نیمه‌ساختاریافتهسیستم‌های تراکنشی، داده‌های با ساختار مشخص، جاهایی که یکپارچگی داده حیاتیه
    انعطاف‌پذیریبسیار بالا، تغییر ساختار داده آسان استکم، تغییر شما نیازمند فرآیندهای پیچیده است

    چه زمانی MySQL بهتره؟ وقتی یکپارچگی داده‌ها و ایزوله‌سازی (isolation) حرف اول رو میزنه، مثل سیستم‌های مدیریت تراکنش‌های مالی، MySQL به خاطر ساختار سفت و سختش انتخاب بهتریه.

    چه زمانی مانگو دی‌بی بهتره؟ وقتی سرعت، دسترسی بالا و توانایی کار با داده‌های متنوع و در حال تغییر اولویت داره، انعطاف‌پذیری و عملکرد بالای مانگو دی‌بی اون رو به گزینه بهتری تبدیل می‌کنه.

    تاریخچه و لایسنس: یک مسیر پر فراز و نشیب

    مانگو دی‌بی توسط شرکتی به اسم 10gen در سال ۲۰۰۷ شروع به توسعه پیدا کرد. این شرکت که بعدها در سال ۲۰۱۳ اسم خودش رو به MongoDB Inc. تغییر داد، در ابتدا قصد داشت یک محصول پلتفرم به عنوان سرویس (PaaS) بسازه که مانگو دی‌بی یکی از اجزای اون بود. اما در سال ۲۰۰۹، اونها مدل توسعه رو به سمت متن‌باز تغییر دادن. مانگو دی‌بی در تاریخ ۲۰ اکتبر ۲۰۱۷ با نماد MDB در بورس NASDAQ عرضه عمومی شد.

    یکی از بحث‌برانگیزترین اتفاقات در تاریخ مانگو دی‌بی، تغییر لایسنس اون بود. نسخه‌هایی که قبل از ۱۶ اکتبر ۲۰۱۸ منتشر شدن، تحت لایسنس AGPL بودن که یک لایسنس متن‌باز شناخته شده است. اما بعد از این تاریخ، شرکت مانگو دی‌بی لایسنس نرم‌افزار سرور خودش رو به Server Side Public License (SSPL) تغییر داد.

    این لایسنس جدید که توسط خود مانگو دی‌بی نوشته شده، شبیه به لایسنس‌های متن‌باز هست اما یک شرط مهم داره: اگه شما نرم‌افزار مانگو دی‌بی رو به عنوان یک «سرویس» عمومی ارائه بدید، باید کل سورس کد سرویس خودتون رو هم تحت همین لایسنس SSPL منتشر کنید. این تغییر برای جلوگیری از این بود که شرکت‌های بزرگ ارائه‌دهنده خدمات ابری، از مانگو دی‌بی به صورت تجاری استفاده کنن بدون اینکه به جامعه اون کمک کنن.

    این تغییر باعث شد که بنیاد نرم‌افزار متن‌باز (OSI) اعلام کنه که SSPL یک لایسنس متن‌باز نیست. در نتیجه، توزیع‌های لینوکسی معروفی مثل Debian، Fedora و Red Hat Enterprise Linux، مانگو دی‌بی رو از مخازن رسمی خودشون حذف کردن.

    انتقادات و چالش‌ها: نگاهی بی‌طرفانه

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

    • امنیت: در نسخه‌های قدیمی‌تر، تنظیمات پیش‌فرض امنیتی مانگو دی‌بی ضعیف بود و به هر کسی اجازه دسترسی کامل به دیتابیس رو می‌داد. این موضوع باعث شد که هکرها به ده‌ها هزار دیتابیس حمله کنن، اطلاعات رو سرقت کنن یا برای پس دادن اونها باج بخوان. البته از نسخه ۲.۶ به بعد، این مشکل حل شد و به صورت پیش‌فرض، دیتابیس فقط به اتصالات از خود ماشین (localhost) اجازه دسترسی میده.
    • عدم وجود JOINهای پیچیده: در دیتابیس‌های رابطه‌ای، شما می‌تونید با دستور JOIN داده‌ها رو از جدول‌های مختلف به هم وصل کنید. مانگو دی‌بی به صورت ذاتی از JOIN به اون شکل پشتیبانی نمی‌کنه. به جای اون، شما باید از طریق جاسازی اسناد (embedding) یا ارجاع (referencing) روابط رو مدیریت کنید. این موضوع گاهی برای کسانی که از دنیای SQL میان، چالش‌برانگیزه و باعث میشه در اپلیکیشن‌های خیلی پیچیده که روابط زیادی دارن، برخی به سمت SQL برگردن.
    • مصرف بالای حافظه: مانگو دی‌بی برای افزایش کارایی، از حافظه رم به مقدار زیادی استفاده می‌کنه که میتونه هزینه‌های سخت‌افزاری رو بالا ببره.
    • انتقادات فنی و یکپارچگی داده: در گذشته، گزارش‌هایی مثل گزارش معروف Jepsen (یک شرکت تحقیقاتی در زمینه ایمنی سیستم‌های توزیع‌شده) مشکلاتی رو در مورد یکپارچگی داده‌ها در سناریوهای خاصی از خرابی شبکه در مانگو دی‌بی پیدا کرده بود. این گزارش‌ها نشون می‌داد که در شرایط خاص، ممکنه دیتابیس داده‌های قدیمی (stale reads) برگردونه یا حتی داده‌هایی که تایید شدن رو به عقب برگردونه (rollback). شرکت مانگو دی‌بی در نسخه‌های بعدی (مثل نسخه ۳.۴ و بالاتر) بسیاری از این مشکلات رو برطرف کرد و ادعا کرد که تست‌های Jepsen رو با موفقیت پشت سر گذاشته. اما گزارش‌های جدیدتر Jepsen در مورد نسخه‌های جدیدتر مثل ۴.۲.۶، همچنان به برخی مشکلات و پیچیدگی‌ها در تضمین کامل یکپارچگی داده‌ها در تراکنش‌ها اشاره داشت. البته این مشکلات هم در پچ‌های بعدی مورد توجه قرار گرفتن و در نسخه ۵.۰، پیش‌فرض‌های مربوط به تایید نوشتن داده (write concern) برای افزایش ایمنی، تقویت شدن.

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

    پرسش و پاسخ‌های متداول (FAQ)

    حالا که یک دید کلی و جامع از مانگو دی‌بی پیدا کردیم، بیایید به چند تا سوال رایج که ممکنه تو ذهن شما شکل گرفته باشه جواب بدیم.

    • سوال ۱: پس مانگو دی‌بی فقط برای داده‌های «بدون ساختار» خوبه؟

      نه لزوما. اصطلاح بهتر «داده‌های نیمه‌ساختاریافته» یا داده‌هایی هست که ساختار ثابتی ندارن. مانگو دی‌بی برای هر اپلیکیشنی که داده‌هاش به راحتی در قالب جدول‌های سفت و سخت جا نمیگیرن یا ساختارشون در طول زمان زیاد تغییر می‌کنه، عالیه. حتی برای داده‌های ساختاریافته هم میشه ازش استفاده کرد، اما انعطاف‌پذیریش در کار با داده‌های متنوع نقطه قوت اصلیشه.

    • سوال ۲: فرق بین mongo و mongosh دقیقا چی بود؟

      هر دو ابزارهایی برای اتصال به سرور مانگو دی‌بی و اجرای دستورات هستن. mongo نسخه قدیمی‌تره که دیگه توسعه داده نمیشه. mongosh نسخه جدید، مدرن و پیشنهادی هست که امکانات بهتری مثل رنگی بودن دستورات و تاریخچه بهتر رو ارائه میده. همیشه سعی کنید از mongosh استفاده کنید.

    • سوال ۳: این «کرسر» (Cursor) که گاهی در موردش صحبت میشه چیه؟

      وقتی شما یک کوئری find در مانگو دی‌بی اجرا می‌کنید، دیتابیس تمام نتایج رو یک‌جا برای شما ارسال نمی‌کنه، چون ممکنه نتایج خیلی زیاد باشن و حافظه زیادی مصرف کنن. به جای اون، یک کرسر (Cursor) برمی‌گردونه. کرسر مثل یک «اشاره‌گر» به مجموعه‌ی نتایج روی سرور عمل می‌کنه. شما با استفاده از این کرسر می‌تونید نتایج رو یکی یکی یا به صورت دسته‌ای (batch) از سرور بگیرید. متدهایی مثل hasNext() (که چک می‌کنه آیا نتیجه دیگه‌ای وجود داره) و next() (که نتیجه بعدی رو برمی‌گردونه) روی همین کرسر کار می‌کنن.

    • سوال ۴: اگه اینقدر انعطاف‌پذیر و خوبه، چه زمانی نباید از مانگو دی‌بی استفاده کنم؟

      مانگو دی‌بی برای همه کارها بهترین راه‌حل نیست. اگه اپلیکیشن شما داده‌های بسیار رابطه‌ای داره و نیاز به JOINهای پیچیده بین چندین جدول دارید (مثلا یک سیستم بانکی پیچیده)، و یکپارچگی و ثبات داده‌ها (ACID properties) در سطح تراکنش‌های چند جدولی برای شما حیاتی‌تر از هر چیز دیگه‌ای هست، احتمالا یک دیتابیس رابطه‌ای مثل MySQL یا PostgreSQL انتخاب بهتری باشه.

    • سوال ۵: جریان این لایسنس SSPL چیه؟ یعنی مانگو دی‌بی دیگه متن‌باز نیست؟

      از نظر فنی، سورس کد مانگو دی‌بی همچنان در دسترسه (source-available)، اما لایسنس SSPL توسط بنیاد متن‌باز به عنوان یک لایسنس «متن‌باز» واقعی تایید نشده. دلیلش هم محدودیتی هست که برای ارائه‌دهندگان خدمات ابری ایجاد می‌کنه. برای یک توسعه‌دهنده معمولی که از مانگو دی‌بی در اپلیکیشن خودش استفاده می‌کنه، این موضوع معمولا تفاوت خاصی ایجاد نمی‌کنه. اما اگه قصد دارید خود مانگو دی‌بی رو به عنوان یک سرویس تجاری به دیگران بفروشید، باید شرایط این لایسنس رو به دقت بررسی کنید. نسخه Community مانگو دی‌بی همچنان برای استفاده رایگانه.

    منابع

    • [2] mongod, mongo, mongosh, mongos, what now? – Helen Scott
    • [4] MongoDB – Wikipedia
    • [6] What is a Cursor in MongoDB? – Stack Overflow
    • [8] MongoDB – Working and Features – GeeksforGeeks
    • [10] What is MongoDB? Features and how it works – TechTarget Definition
    • [1] MongoDB: The World’s Leading Modern Database | MongoDB
    • [3] ELI5: What is MongoDB and what is used for? : r/mongodb
    • [5] What Is MongoDB? | MongoDB
    • [7] When should I actually use MongoDB? : r/webdev
    • [9] What Is MongoDB? | IBM
  • هوش مصنوعی (AI) چیست، یک تعریف ساده و عمیق شدن بیشتر

    بیاین از یه زاویه جالب بهش نگاه کنیم. ما انسان‌ها از همون اول با ابزارها و ماشین‌ها رفیق بودیم. از چرخ که کشاورزی رو زیر و رو کرد گرفته تا پیچ که ساختمون‌های پیچیده رو ممکن کرد و خط‌های تولید رباتیک امروزی، ماشین‌ها همیشه کمک دست ما بودن. ولی یه ترسی هم همیشه ته دلمون بوده: چی میشه اگه یه روزی این ماشین‌ها مثل ما هوشمند بشن و بخوان برای خودشون تصمیم بگیرن؟ البته این کنجکاوی و ترس با هم قاطی شده و باعث شده علمی‌تخیلی‌ها کم کم رنگ واقعیت بگیرن.

    حالا بیایم سر تعریف اصلی. هوش مصنوعی (Artificial Intelligence یا AI) یعنی توانایی یه ماشین برای انجام دادن کارهای شناختی که ما معمولا به ذهن انسان نسبتش میدیم. کارهایی مثل درک کردن، استدلال کردن، یاد گرفتن، تعامل با محیط، حل مسئله و حتی خلاقیت. شاید خودتونم ندونین ولی احتمالا تا حالا کلی با AI سر و کار داشتین؛ دستیارهای صوتی مثل سیری و الکسا یا اون ربات‌های چت که تو بعضی سایت‌ها بهتون کمک میکنن، همشون بر پایه تکنولوژی AI کار میکنن.

    این ماشین‌های هوشمند روز به روز دارن سریع‌تر و پیچیده‌تر میشن. مثلا بعضی کامپیوترها به مرحله‌ای به اسم «اگزااسکیل» رسیدن. یعنی میتونن توی یک ثانیه، به اندازه‌ای محاسبه انجام بدن که یه نفر آدم باید ۳۱ میلیارد و ۶۸۸ میلیون و ۷۶۵ هزار سال وقت بذاره تا انجامش بده. دیگه فقط بحث محاسبه نیست، کامپیوترها دارن مهارت‌ها و قدرت درکی پیدا میکنن که یه زمانی فقط مخصوص ما انسان‌ها و چندتا گونه دیگه بود.

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

    از کجا شروع کنیم؟ بیایم با یادگیری ماشین آشنا بشیم

    خب، وقتی میگیم AI، در واقع داریم در مورد یه خانواده بزرگ از تکنولوژی‌ها حرف میزنیم. یکی از مهم‌ترین اعضای این خانواده یادگیری ماشین (Machine Learning یا ML) هست.

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

    این روزها حجم داده‌هایی که تولید میشه اونقدر زیاد و پیچیده است که ما انسان‌ها از پس پردازشش برنمیایم. همین موضوع، هم پتانسیل یادگیری ماشین رو بیشتر کرده و هم نیازمون بهش رو. از دهه ۱۹۷۰ که استفاده از یادگیری ماشین گسترده شد، تاثیرات بزرگی تو صنایع مختلف داشته، مثلا تو تحلیل تصاویر پزشکی یا پیش‌بینی خیلی دقیق وضعیت آب و هوا.

    به طور کلی، سه مدل اصلی برای یادگیری ماشین وجود داره:

    • یادگیری نظارت شده (Supervised learning): تو این مدل، الگوریتم رو با داده‌های برچسب‌دار آموزش میدیم. یعنی چی؟ یعنی مثلا بهش کلی عکس گربه نشون میدیم و بهش میگیم «اینا گربه هستن». هدف اینه که مدل یاد بگیره بین ورودی (عکس) و خروجی (برچسب گربه) یه نقشه پیدا کنه تا بعدا بتونه عکس‌های جدیدی که تا حالا ندیده رو هم درست تشخیص بده.
    • یادگیری نظارت نشده (Unsupervised learning): اینجا دیگه از داده‌های برچسب‌دار خبری نیست. الگوریتم باید خودش الگوها رو تو داده‌های بدون ساختار پیدا کنه. نتیجه نهایی از قبل مشخص نیست. الگوریتم خودش داده‌ها رو بر اساس ویژگی‌هاشون دسته‌بندی میکنه. این مدل برای پیدا کردن الگوها و مدل‌سازی توصیفی خیلی خوبه.
    • یادگیری تقویتی (Reinforcement learning): این مدل رو میشه به «یادگیری با آزمون و خطا» توصیف کرد. یه «عامل» (Agent) یاد میگیره که یه کار مشخص رو با سعی و خطا انجام بده. اینقدر این کار رو تکرار میکنه تا عملکردش به یه سطح قابل قبول برسه. وقتی کار رو خوب انجام میده تشویق (تقویت مثبت) میشه و وقتی بد انجام میده تنبیه (تقویت منفی). مثلا آموزش دادن به یه دست رباتیک برای برداشتن یه توپ، یه نمونه از این نوع یادگیریه.

    یه روش ترکیبی هم به اسم یادگیری نیمه نظارت شده (Semi-supervised learning) وجود داره که توش فقط بخشی از داده‌ها برچسب دارن.

    یک پله عمیق‌تر: یادگیری عمیق و شبکه‌های عصبی

    حالا که با یادگیری ماشین آشنا شدیم، وقتشه بریم سراغ یه نسخه پیشرفته‌تر از اون به اسم یادگیری عمیق (Deep Learning).

    یادگیری عمیق یه زیرمجموعه از یادگیری ماشینه که از شبکه‌های عصبی چندلایه استفاده میکنه تا قدرت تصمیم‌گیری پیچیده مغز انسان رو شبیه‌سازی کنه. این روش تو پردازش طیف وسیع‌تری از داده‌ها (مثل متن و داده‌های بدون ساختار مثل عکس) خیلی ماهره، به دخالت انسان کمتری نیاز داره و معمولا نتایج دقیق‌تری نسبت به یادگیری ماشین سنتی تولید میکنه.

    ایده اصلی یادگیری عمیق استفاده از شبکه‌های عصبی (Neural Networks) هست. این شبکه‌ها از نحوه تعامل نورون‌ها تو مغز انسان الهام گرفته شدن. یه شبکه عصبی از لایه‌های به هم پیوسته از گره‌ها (که شبیه نورون هستن) تشکیل شده. داده‌ها وارد این شبکه میشن و از چندین لایه عبور میکنن. هر لایه ویژگی‌های پیچیده‌تری از داده رو تشخیص میده. مثلا لایه اول ممکنه یه چیزی رو به عنوان یه شکل خاص تشخیص بده و لایه بعدی، بر اساس این اطلاعات، بفهمه که اون شکل یه تابلوی ایست هست. یادگیری عمیق هم مثل یادگیری ماشین، از تکرار برای اصلاح خودش و بهتر کردن قدرت پیش‌بینی‌اش استفاده میکنه.

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

    چند نوع شبکه عصبی معروف هم داریم که خوبه اسمشون رو بدونین:

    • شبکه‌های عصبی پیشخور (Feedforward Neural Networks – FF): یکی از قدیمی‌ترین مدل‌ها که داده‌ها فقط در یک جهت، از لایه‌ها عبور میکنن تا به خروجی برسن.
    • شبکه‌های عصبی بازگشتی (Recurrent Neural Networks – RNN): این مدل‌ها بر خلاف مدل قبلی، از داده‌های سری زمانی یا دنباله‌ای استفاده میکنن و یه جورایی «حافظه» دارن از اتفاقی که تو لایه قبلی افتاده. برای همین تو تشخیص گفتار و ترجمه خیلی به کار میان.
    • حافظه طولانی/کوتاه مدت (Long/Short Term Memory – LSTM): اینم یه مدل پیشرفته از RNN هست که میتونه چیزهایی که چندین لایه قبل اتفاق افتاده رو با استفاده از «سلول‌های حافظه» به خاطر بسپره.
    • شبکه‌های عصبی کانولوشنی (Convolutional Neural Networks – CNN): این‌ها جزو معروف‌ترین شبکه‌های عصبی هستن و بیشتر تو تشخیص تصویر استفاده میشن. لایه‌های مختلفش بخش‌های متفاوتی از یه عکس (مثل رنگ‌ها و لبه‌ها) رو فیلتر میکنن تا در نهایت تصویر رو تشخیص بدن.
    • شبکه‌های مولد تخاصمی (Generative Adversarial Networks – GAN): تو این سیستم، دو تا شبکه عصبی با هم رقابت میکنن. یکی (مولد) سعی میکنه مثال‌های جدید بسازه و اون یکی (تفکیک‌کننده) سعی میکنه تشخیص بده که این مثال‌ها واقعی هستن یا ساختگی. این رقابت در نهایت باعث بهتر شدن خروجی میشه. از این مدل برای ساختن عکس‌های واقعی و حتی آثار هنری استفاده شده.

    جدیدترین پدیده: هوش مصنوعی مولد (Generative AI)

    و اما میرسیم به بحث داغ این روزها: هوش مصنوعی مولد (Generative AI یا Gen AI).

    هوش مصنوعی مولد به مدل‌های یادگیری عمیقی گفته میشه که میتونن در جواب به یه درخواست یا «پرامپت» (Prompt) از طرف کاربر، محتوای جدید و اورجینال مثل متن‌های طولانی، عکس‌های باکیفیت، ویدیوهای واقعی یا صدا تولید کنن. ابزارهایی مثل ChatGPT و DALL-E (که عکس تولید میکنه) نشون دادن که این تکنولوژی پتانسیل تغییر دادن خیلی از شغل‌ها رو داره.

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

    فرایند کار هوش مصنوعی مولد معمولا سه مرحله داره:

    • شروع با یک مدل پایه (Foundation Model): همه چیز با یه مدل پایه شروع میشه. این مدل یه مدل یادگیری عمیق خیلی بزرگه که روی حجم عظیمی از داده‌های خام و بدون برچسب (مثلا ترابایت‌ها متن و عکس از اینترنت) آموزش دیده. این آموزش خیلی سنگین، زمان‌بر و گرونه و به هزاران پردازنده گرافیکی (GPU) و میلیون‌ها دلار هزینه نیاز داره. این مدل‌ها که معروف‌ترینشون مدل‌های زبان بزرگ (Large Language Models یا LLM) هستن، میتونن به صورت خودکار به پرامپت‌ها جواب بدن.
    • تنظیم دقیق (Fine-tuning): بعد از ساخت مدل پایه، باید اون رو برای یه کار مشخص (مثلا تولید یه نوع محتوای خاص) تنظیم کرد. این کار با روش‌های مختلفی مثل آموزش بیشتر با داده‌های مرتبط انجام میشه.
    • ارزیابی و بهبود مداوم: توسعه‌دهنده‌ها و کاربرها به طور مرتب خروجی‌های این ابزارها رو ارزیابی میکنن و مدل رو حتی هفته‌ای یک بار برای دقت و مرتبط بودن بیشتر، دوباره تنظیم میکنن.

    سفری به گذشته: تاریخچه هوش مصنوعی

    برای اینکه بفهمیم الان کجا هستیم، باید بدونیم از کجا شروع کردیم. ایده «ماشینی که فکر میکنه» به یونان باستان برمیگرده، اما اگه بخوایم تاریخ مدرنش رو بررسی کنیم، باید از اینجا شروع کنیم:

    • دهه ۱۹۴۰ و ۱۹۵۰:
      • ۱۹۴۳: وارن مک‌کالک و والتر پیتس یه مدل از نورون‌های مصنوعی رو پیشنهاد دادن که پایه و اساس شبکه‌های عصبی شد.
      • ۱۹۵۰: آلن تورینگ، که بهش «پدر علم کامپیوتر» هم میگن، یه مقاله به اسم «ماشین‌های محاسباتی و هوش» منتشر کرد و این سوال رو پرسید: «آیا ماشین‌ها میتونن فکر کنن؟». اون یه آزمایشی به اسم «بازی تقلید» رو هم معرفی کرد که امروز به «آزمون تورینگ» معروفه. این آزمون توانایی یه ماشین برای نشون دادن رفتار هوشمندانه رو میسنجه.
      • ۱۹۵۶: این سال یه نقطه عطف بود. جان مک‌کارتی، دانشمند کامپیوتر، برای اولین بار از عبارت «هوش مصنوعی» تو یه کارگاه تو کالج دارتموث استفاده کرد. همون سال، آلن نیوول، جی. سی. شاو و هربرت سایمون اولین برنامه کامپیوتری هوش مصنوعی به اسم «Logic Theorist» رو ساختن.
    • چهار مرحله تکامل AI (به روایت رادنی بروکس، فیزیکدان MIT):
      • هوش مصنوعی نمادین (Symbolic AI – از ۱۹۵۶): به این روش، هوش مصنوعی کلاسیک یا حتی GOFAI (مخفف هوش مصنوعی خوب و قدیمی) هم میگن. ایده اصلی اینجا استفاده از نمادها و استدلال منطقی برای حل مسئله بود. مثلا: ژرمن شپرد یه سگه، سگ یه پستانداره، همه پستانداران خونگرم هستن؛ پس ژرمن شپرد باید خونگرم باشه. مشکل اصلی این روش این بود که انسان‌ها باید دانش خودشون از دنیا رو به صورت دستی وارد سیستم میکردن. برای همین این سیستم‌ها با پیچیدگی‌های دنیای واقعی مشکل داشتن و نمیتونستن از داده‌های زیاد یاد بگیرن. این روش تا اواخر دهه ۱۹۸۰ روش غالب بود.
      • شبکه‌های عصبی (با پیشرفت‌هایی در سال‌های ۱۹۵۴، ۱۹۶۹، ۱۹۸۶ و ۲۰۱۲): همونطور که گفتیم، این تکنولوژی پشت رشد انفجاری هوش مصنوعی مولد امروزیه. با اینکه ایده‌اش از دهه ۴۰ مطرح بود، فراز و نشیب‌های زیادی داشت. در سال ۱۹۶۹ دو تا محقق MIT نشون دادن که شبکه‌های عصبی فقط میتونن کارهای خیلی ساده انجام بدن. اما در سال ۱۹۸۶، جفری هینتون و همکارانش این مشکل رو حل کردن. در نهایت در سال ۲۰۱۲، هینتون و دو تا از دانشجوهاش قدرت یادگیری عمیق رو با استفاده از شبکه‌های عصبی با لایه‌های خیلی بیشتر نشون دادن و تمرکز دنیا رو به این سمت بردن.
      • رباتیک سنتی (Traditional Robotics – از ۱۹۶۸): تو دهه‌های اول هوش مصنوعی، محقق‌ها برای پیشبرد تحقیقاتشون ربات میساختن. این ربات‌ها معمولا تو محیط‌های خیلی کنترل شده کار میکردن و رفتارهای کاملا برنامه‌ریزی شده رو تکرار میکردن. با اینکه این ربات‌ها به پیشرفت خود AI کمک زیادی نکردن، اما تو یه زمینه به اسم «مکان‌یابی و نقشه‌برداری همزمان» (SLAM) خیلی تاثیرگذار بودن که به ساخت ماشین‌های خودران و حتی ربات‌های جاروبرقی امروزی کمک کرد.
      • رباتیک مبتنی بر رفتار (Behavior-based Robotics – از ۱۹۸۵): محقق‌ها دیدن که حشرات با تعداد کمی نورون، خیلی خوب تو دنیای واقعی مسیریابی میکنن. پس سعی کردن ربات‌هایی بسازن که بتونن با دانش ناقص و دستورالعمل‌های متناقض، مشکلات رو حل کنن. این ربات‌ها هم تو دلشون شبکه‌های عصبی دارن.
    • دهه ۱۹۸۰ تا امروز:
      • دهه ۱۹۸۰: شبکه‌های عصبی که از الگوریتم «پس‌انتشار» (backpropagation) برای آموزش خودشون استفاده میکردن، به طور گسترده تو کاربردهای AI استفاده شدن. اما بعدش به خاطر محدودیت‌ها، یه دوره رکود دیگه به اسم «زمستان دوم AI» به وجود اومد.
      • ۱۹۹۷: کامپیوتر «دیپ بلو» شرکت IBM، گری کاسپاروف، قهرمان شطرنج جهان رو شکست داد. این یه اتفاق خیلی مهم بود.
      • ۲۰۱۶: برنامه «آلفاگو» شرکت دیپ‌مایند، که با یه شبکه عصبی عمیق کار میکرد، لی سدول، قهرمان جهان تو بازی «گو» رو شکست داد. این پیروزی خیلی مهم بود چون تعداد حرکات ممکن تو بازی گو فوق‌العاده زیاده.
      • ۲۰۲۲: ظهور مدل‌های زبان بزرگ یا LLMها، مثل ChatGPT، یه تغییر عظیم تو عملکرد هوش مصنوعی و پتانسیلش ایجاد کرد.

    انواع هوش مصنوعی: از ضعیف تا فوق هوشمند

    خب، حالا که با تاریخچه و اجزای اصلی AI آشنا شدیم، بیایم ببینیم چه انواعی داره. هوش مصنوعی رو میشه از چند دیدگاه مختلف دسته‌بندی کرد.

    دسته‌بندی بر اساس قابلیت:

    • هوش مصنوعی ضعیف یا محدود (Weak AI یا Narrow AI): این‌ها سیستم‌های هوش مصنوعی هستن که برای انجام یه کار مشخص یا مجموعه‌ای از کارهای محدود طراحی و آموزش دیدن. تقریبا تمام هوش مصنوعی که ما امروز میبینیم و استفاده میکنیم از این نوعه. دستیار صوتی الکسا، الگوریتم‌های تشخیص تقلب کارت اعتباری یا موتور جستجوی گوگل همشون نمونه‌هایی از هوش مصنوعی محدود هستن.
    • هوش مصنوعی قوی یا عمومی (Strong AI یا Artificial General Intelligence – AGI): این نوع هوش مصنوعی، توانایی درک، یادگیری و به کار بردن دانش در طیف وسیعی از کارها رو در سطحی برابر یا حتی فراتر از هوش انسان داره. این سطح از AI در حال حاضر فقط در حد تئوری وجود داره و هنوز هیچ سیستمی بهش نرسیده. بعضی محقق‌ها معتقدن رسیدن به AGI به افزایش خیلی زیادی تو قدرت محاسباتی نیاز داره. رادنی بروکس، رباتیک‌دان MIT و یکی از بنیان‌گذاران iRobot، معتقده که AGI تا سال ۲۳۰۰ از راه نمیرسه.
    • هوش مصنوعی فوق هوشمند (Artificial Superintelligence – ASI): این دیگه سطح بعدیه که توش ماشین میتونه تو همه زمینه‌ها از انسان برتر عمل کنه. این هم مثل AGI فعلا در قلمرو علمی-تخیلی قرار داره.

    دسته‌بندی بر اساس عملکرد:

    1. نوع ۱: ماشین‌های واکنشی (Reactive Machines): این سیستم‌ها حافظه ندارن و فقط برای یه کار خاص طراحی شدن. مثل کامپیوتر شطرنج‌باز دیپ بلو که کاسپاروف رو شکست داد. اون میتونست مهره‌ها رو تشخیص بده و حرکت بعدی رو پیش‌بینی کنه، ولی از تجربه‌های قبلی برای بازی‌های آینده‌اش استفاده نمیکرد.
    2. نوع ۲: حافظه محدود (Limited Memory): این سیستم‌ها حافظه دارن و میتونن از تجربیات گذشته برای تصمیم‌گیری‌های آینده استفاده کنن. بعضی از عملکردهای تصمیم‌گیری تو ماشین‌های خودران اینجوری طراحی شدن.
    3. نوع ۳: نظریه ذهن (Theory of Mind): این یه اصطلاح روانشناسیه. وقتی در مورد AI به کار میره، یعنی سیستمی که میتونه احساسات رو بفهمه، نیت انسان‌ها رو درک کنه و رفتارشون رو پیش‌بینی کنه. این نوع AI هنوز به طور کامل وجود نداره.
    4. نوع ۴: خودآگاهی (Self-awareness): تو این دسته، سیستم‌های AI یه حسی از «خود» دارن که بهشون آگاهی میده. ماشین‌هایی که خودآگاهی دارن، وضعیت فعلی خودشون رو درک میکنن. این نوع AI هم هنوز وجود نداره.

    AI در دنیای واقعی: کاربردها و مزایا

    خب، این همه در مورد تئوری و تاریخ حرف زدیم. حالا بیایم ببینیم این هوش مصنوعی تو دنیای واقعی به چه دردی میخوره.

    مزایای کلی هوش مصنوعی:

    • اتوماسیون (Automation): هوش مصنوعی میتونه کارهای تکراری و خسته‌کننده رو خودکار کنه، چه کارهای دیجیتال مثل جمع‌آوری و وارد کردن داده، چه کارهای فیزیکی مثل جابجا کردن بسته‌ها تو انبار. این کار باعث میشه ما انسان‌ها وقتمون برای کارهای خلاقانه‌تر و باارزش‌تر آزاد بشه.
    • کاهش خطای انسانی: AI میتونه خطاهای دستی تو پردازش داده، تحلیل یا مونتاژ رو از بین ببره چون الگوریتم‌ها هر بار یه فرایند رو به همون شکل دقیق تکرار میکنن.
    • تصمیم‌گیری سریع و دقیق: هوش مصنوعی میتونه سریع‌تر و دقیق‌تر از انسان‌ها پیش‌بینی کنه و تصمیم‌های مبتنی بر داده بگیره.
    • در دسترس بودن همیشگی: AI خسته نمیشه و به استراحت نیاز نداره. ربات‌های چت میتونن ۲۴ ساعته جواب مشتری‌ها رو بدن.
    • افزایش ایمنی: با خودکار کردن کارهای خطرناک مثل کار با مواد منفجره یا کار در اعماق اقیانوس، دیگه نیازی نیست انسان‌ها رو در معرض خطر قرار بدیم.

    کاربردها در صنایع مختلف:

    • خدمات مشتری: شرکت‌ها از ربات‌های چت و دستیارهای مجازی برای جواب دادن به سوالات مشتری‌ها، پیگیری سفارش‌ها و حل مشکلات استفاده میکنن. این ابزارها با استفاده از پردازش زبان طبیعی (Natural Language Processing – NLP) زبان ما رو میفهمن و جواب میدن.
    • کشف تقلب: الگوریتم‌های یادگیری ماشین میتونن الگوهای تراکنش‌ها رو تحلیل کنن و موارد مشکوک مثل خریدهای غیرعادی رو به سرعت تشخیص بدن.
    • تجربه مشتری شخصی‌سازی شده: فروشگاه‌ها و بانک‌ها از AI برای پیشنهاد دادن محصولات و خدماتی که احتمالا دوست دارین، استفاده میکنن.
    • استخدام و منابع انسانی: پلتفرم‌های استخدامی مبتنی بر AI میتونن رزومه‌ها رو بررسی کنن، کاندیداها رو با شرح شغل تطبیق بدن و حتی مصاحبه‌های اولیه رو انجام بدن.
    • توسعه نرم‌افزار: ابزارهای تولید کد با هوش مصنوعی مولد میتونن کارهای کدنویسی تکراری رو ساده کنن و سرعت توسعه برنامه‌ها رو بالا ببرن.
    • تعمیر و نگهداری پیش‌بینی‌کننده: مدل‌های یادگیری ماشین میتونن داده‌های سنسورها رو تحلیل کنن و پیش‌بینی کنن که یه دستگاه کی به تعمیر نیاز داره تا از کار افتادن ناگهانیش جلوگیری بشه.
    • بهداشت و درمان: AI تو تحلیل تصاویر پزشکی برای تشخیص زودهنگام بیماری‌ها، طراحی برنامه‌های درمانی شخصی‌سازی شده و حتی کشف داروهای جدید به کار میره.
    • حمل و نقل: ماشین‌های خودران یه مثال بارز هستن. علاوه بر این، AI برای مدیریت ترافیک، پیش‌بینی تاخیر پروازها و بهینه‌سازی مسیرهای کشتی‌رانی هم استفاده میشه.

    بر اساس یه نظرسنجی در سال ۲۰۲۲، پذیرش مدل‌های هوش مصنوعی از سال ۲۰۱۷ بیش از دو برابر شده و سرمایه‌گذاری تو این حوزه هم به همین نسبت افزایش پیدا کرده. حوزه‌هایی که شرکت‌ها بیشترین ارزش رو از AI میبینن شامل بازاریابی و فروش، توسعه محصول و خدمات، و استراتژی و امور مالی شرکتی هست.

    چالش‌ها، خطرات و بحث‌های اخلاقی

    با همه این خوبی‌ها، هوش مصنوعی بدون چالش و خطر هم نیست. مهمه که این جنبه‌ها رو هم بشناسیم.

    محدودیت‌ها و خطرات مدل‌های AI:

    • خروجی‌های اشتباه: خروجی‌های مدل‌های هوش مصنوعی مولد ممکنه خیلی متقاعدکننده به نظر برسن، ولی گاهی اوقات اطلاعاتی که تولید میکنن کاملا اشتباهه.
    • سوگیری (Bias): این مدل‌ها بر اساس داده‌هایی که باهاشون آموزش دیدن کار میکنن. اگه اون داده‌ها (که معمولا از اینترنت گرفته میشن) شامل سوگیری‌های جنسیتی، نژادی و … باشن، خروجی مدل هم این سوگیری‌ها رو منعکس و حتی تقویت میکنه. مثلا آمازون یه ابزار استخدام مبتنی بر AI ساخته بود که ناخواسته به نفع کاندیداهای مرد عمل میکرد چون داده‌های آموزشی‌اش این سوگیری رو داشتن.
    • امکان سواستفاده: میشه از این مدل‌ها برای فعالیت‌های غیراخلاقی یا مجرمانه استفاده کرد. بعضی کاربرها سعی میکنن مدل‌ها رو «جیل‌بریک» (Jailbreak) کنن، یعنی کاری کنن که قوانین خودشون رو بشکنن و محتوای مضر یا غیرقانونی تولید کنن.
    • هزینه‌های بالا: توسعه و آموزش مدل‌های AI، به خصوص مدل‌های بزرگ، خیلی گرونه. مثلا مدیرعامل OpenAI گفته که آموزش مدل GPT-4 بیشتر از ۱۰۰ میلیون دلار هزینه داشته.
    • پیچیدگی فنی و کمبود متخصص: ساختن و نگهداری سیستم‌های AI به دانش فنی خیلی بالایی نیاز داره و تعداد متخصص‌های این حوزه نسبت به تقاضا کمه.
    • جابجایی شغلی: با خودکار شدن کارها، این نگرانی وجود داره که بعضی شغل‌ها از بین برن و این موضوع باعث نابرابری اقتصادی بشه.
    • تاثیرات زیست‌محیطی: مراکز داده‌ای که این مدل‌ها رو اجرا میکنن، مقدار زیادی انرژی و آب مصرف میکنن که روی محیط زیست تاثیر منفی داره.

    چطور میشه با این خطرات مقابله کرد؟

    • انتخاب دقیق داده‌های آموزشی: باید خیلی مراقب بود که داده‌های اولیه شامل محتوای سمی یا سوگیرانه نباشن.
    • استفاده از مدل‌های تخصصی: به جای استفاده از یه مدل عمومی، شرکت‌ها میتونن از مدل‌های کوچیک‌تر و تخصصی‌تر استفاده کنن یا یه مدل عمومی رو با داده‌های خودشون سفارشی‌سازی کنن.
    • حفظ عامل انسانی (Human in the loop): خیلی مهمه که یه انسان واقعی خروجی مدل AI رو قبل از انتشار یا استفاده نهایی، چک کنه.
    • شفافیت و حاکمیت: باید مشخص باشه که یه سیستم خودکار داره استفاده میشه و نحوه کارش توضیح داده بشه. همچنین باید ساختارهای نظارتی برای مسئولیت‌پذیری وجود داشته باشه.

    قوانین و مقررات برای هوش مصنوعی

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

    • منشور حقوق هوش مصنوعی (AI Bill of Rights): دولت آمریکا در سال ۲۰۲۲ یه سندی به اسم «طرح اولیه برای منشور حقوق هوش مصنوعی» آماده کرد. این سند پنج تا اصل اساسی داره:
      1. حق داشتن سیستم‌های ایمن و موثر.
      2. محافظت در برابر تبعیض توسط الگوریتم‌ها.
      3. محافظت در برابر سواستفاده از داده‌ها.
      4. حق دانستن اینکه یک سیستم خودکار در حال استفاده است.
      5. حق انصراف و دسترسی به یک انسان برای حل مشکلات.
    • قانون هوش مصنوعی اتحادیه اروپا (EU’s AI Act): این قانون که قراره در سال ۲۰۲۴ اجرایی بشه، یه مقررات جامع برای AI هست که با قوانین حفاظت از داده و امنیت سایبری فعلی هم هماهنگه.

    در حال حاضر بیشتر از ۶۰ کشور یا اتحادیه، استراتژی‌های ملی برای استفاده مسئولانه از AI دارن، از جمله برزیل، چین، سنگاپور، کره جنوبی و آمریکا.

    یک نگاه هنری: فیلم «A.I. Artificial Intelligence»

    حالا که با جنبه‌های علمی و فنی هوش مصنوعی آشنا شدیم، جالبه ببینیم دنیای هنر و سینما چطور به این موضوع نگاه کرده. یکی از معروف‌ترین فیلم‌ها در این زمینه، فیلم «A.I. Artificial Intelligence» ساخته استیون اسپیلبرگ در سال ۲۰۰۱ هست.

    A.I. Artificial Intelligence
    کارگرداناستیون اسپیلبرگ
    فیلمنامهاستیون اسپیلبرگ
    داستانایان واتسون
    بر اساسداستان کوتاه «اسباب‌بازی‌های فوق‌العاده تمام تابستان دوام می‌آورند» نوشته برایان آلدیس
    بازیگران اصلیهیلی جوئل آزمنت، جود لا، فرانسیس اوکانر
    بودجه۹۰ تا ۱۰۰ میلیون دلار
    فروش۲۳۵.۹ میلیون دلار

    داستان فیلم در یک نگاه:

    فیلم در قرن ۲۲ میگذره. گرمایش جهانی باعث بالا اومدن سطح دریاها شده و ربات‌های انسان‌نما به اسم «مکا» (Mecha) نقش‌های مختلفی تو جامعه دارن. دیوید (با بازی هیلی جوئل آزمنت) یه نمونه اولیه از بچه‌های مکا هست که به طور منحصر به فردی با قابلیت عشق ورزیدن برنامه‌ریزی شده. اون به خانواده‌ای داده میشه که پسرشون در کماست. وقتی پسر واقعی خانواده به طور غیرمنتظره‌ای خوب میشه و به خونه برمیگرده، رقابت و حسادت به وجود میاد و در نهایت دیوید از خونه طرد میشه. دیوید با الهام از داستان پینوکیو، سفری رو شروع میکنه تا «پری آبی» رو پیدا کنه و به یه پسر واقعی تبدیل بشه تا بتونه دوباره عشق مادرش رو به دست بیاره.

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

    پرسش و پاسخ کلاسی

    خب بچه‌ها، تا اینجا سعی کردیم یه دید کلی و جامع از هوش مصنوعی به دست بیاریم. حالا بریم سراغ چندتا سوال که ممکنه تو ذهنتون باشه.

    سوال ۱: فرق دقیق بین هوش مصنوعی، یادگیری ماشین و یادگیری عمیق چیه؟

    جواب: این سه تا مثل عروسک‌های تودرتوی روسی هستن. هوش مصنوعی (AI) وسیع‌ترین مفهومه و به طور کلی به هر تکنولوژی‌ای گفته میشه که رفتار هوشمندانه انسان رو شبیه‌سازی میکنه. یادگیری ماشین (ML) یه زیرمجموعه از AI هست که به سیستم‌ها اجازه میده به جای برنامه‌ریزی مستقیم، از روی داده‌ها یاد بگیرن. و یادگیری عمیق (Deep Learning) هم یه زیرمجموعه تخصصی‌تر از یادگیری ماشینه که از شبکه‌های عصبی با لایه‌های خیلی زیاد برای حل مسائل پیچیده‌تر استفاده میکنه.

    سوال ۲: آیا ChatGPT همون هوش مصنوعی قوی یا AGI هست که در موردش صحبت کردیم؟

    جواب: نه. با اینکه ChatGPT و مدل‌های مشابه خیلی پیشرفته هستن، اما هنوز در دسته هوش مصنوعی ضعیف یا محدود (Narrow AI) قرار میگیرن. اونها برای یه کار مشخص، یعنی پردازش و تولید زبان، آموزش دیدن و نمیتونن مثل انسان در طیف وسیعی از کارهای مختلف فکر و استدلال کنن. اونها آگاهی یا درک واقعی ندارن و فقط در تشخیص الگوهای زبانی خیلی خوب عمل میکنن.

    سوال ۳: چرا میگن «داده» برای هوش مصنوعی اینقدر مهمه؟

    جواب: چون مدل‌های یادگیری ماشین و یادگیری عمیق، اساسا با تحلیل حجم عظیمی از داده‌ها «یاد میگیرن». کیفیت و کمیت داده‌های آموزشی مستقیما روی عملکرد، دقت و حتی «بی‌طرف» بودن مدل AI تاثیر میذاره. اگه داده‌های ورودی کم، اشتباه یا سوگیرانه باشن، خروجی هوش مصنوعی هم همین مشکلات رو خواهد داشت. در واقع داده مثل کتاب درسی برای یه دانش‌آموز میمونه.

    سوال ۴: آیا الان قانونی برای کنترل هوش مصنوعی وجود داره؟

    جواب: بله، ولی هنوز در مراحل اولیه هست. در حال حاضر قوانین جامع و جهانی وجود نداره و کشورها و مناطق مختلف دارن رویکردهای متفاوتی رو در پیش میگیرن. اتحادیه اروپا با «قانون هوش مصنوعی» خودش پیشرو هست و سعی داره یه چارچوب قانونی کامل ایجاد کنه. آمریکا هم با «منشور حقوق هوش مصنوعی» قدم‌هایی برداشته. اما به طور کلی، دنیای قانون‌گذاری هنوز داره سعی میکنه خودش رو به سرعت پیشرفت تکنولوژی برسونه.

    منابع

    • [2] What is AI (Artificial Intelligence)? Definition, Types, Examples & Use Cases
    • [4] Artificial intelligence (AI) | Definition, Examples, Types, Applications, Companies, & Facts | Britannica
    • [6] What is Artificial Intelligence? – NASA
    • [8] What is AI? – Artificial Intelligence Explained – AWS
    • [10] A.I. Artificial Intelligence (2001) – IMDb
    • [1] What Is Artificial Intelligence (AI)? | IBM
    • [3] A.I. Artificial Intelligence – Wikipedia
    • [5] What is (AI) Artificial Intelligence? | Online Master of Engineering | University of Illinois Chicago
    • [7] What Is Artificial Intelligence (AI)? | Google Cloud
    • [9] What is AI (artificial intelligence)? | McKinsey
  • حملات DDoS چی هستن و هدفشون چیه

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

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

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

    حمله DDoS چطوری اجرا میشه؟ ارتش زامبی‌ها وارد میشود

    برای اینکه بفهمیم این حجم از ترافیک از کجا میاد، باید با چند تا مفهوم کلیدی آشنا بشیم. حمله‌های DDoS با استفاده از شبکه‌ای از کامپیوترها و دستگاه‌های متصل به اینترنت اجرا میشن.

    • بات (Bot) یا زامبی (Zombie): اینها دستگاه‌های معمولی مثل کامپیوتر من و شما، یا حتی دستگاه‌های هوشمند مثل دوربین‌های مداربسته و یخچال‌های هوشمند (همون دستگاه‌های IoT) هستن که به بدافزار آلوده شدن. صاحب این دستگاه‌ها معمولن روحش هم خبر نداره که دستگاهش آلوده شده و داره ازش سوءاستفاده میشه.
    • بات‌نت (Botnet): وقتی یه تعداد زیادی از این بات‌ها یا زامبی‌ها تحت کنترل یک نفر (مهاجم) قرار میگیرن، یه شبکه به اسم «بات‌نت» تشکیل میدن. این بات‌نت مثل یه ارتش از دستگاه‌های آلوده‌اس که منتظر دستور فرمانده‌شون هستن.

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

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

    یکی از بزرگترین چالش‌ها اینه که هر کدوم از این بات‌ها یه دستگاه اینترنتی واقعی و قانونیه. برای همین، تشخیص دادن ترافیک حمله از ترافیک کاربرهای واقعی خیلی سخته. انگار که توی اون مثال ترافیک، همه ماشین‌های الکی، ظاهری شبیه ماشین‌های واقعی داشته باشن.

    از کجا بفهمیم داریم مورد حمله قرار میگیریم؟

    واضح‌ترین نشونه یه حمله DDoS اینه که یه سایت یا سرویس یهویی خیلی کند میشه یا کاملن از دسترس خارج میشه. اما خب، این مشکل میتونه دلایل دیگه‌ای هم داشته باشه، مثلن اینکه یه محصول جدید عرضه شده و یه عالمه کاربر واقعی همزمان هجوم آوردن به سایت. برای همین، برای تشخیص قطعی، باید بیشتر تحقیق کرد.

    ابزارهای تحلیل ترافیک میتونن به ما کمک کنن تا بعضی از علائم کلیدی یه حمله DDoS رو تشخیص بدیم:

    • حجم ترافیک غیرعادی که به سمت یک نقطه یا آدرس IP خاص هدایت شده.
    • یه الگوی ترافیکی عجیب، مثلن ترافیک زیاد از طرف کاربرهایی که پروفایل مشابهی دارن (مثلن همه از یک منطقه جغرافیایی خاص، یا از یک نوع دستگاه خاص هستن).
    • افزایش ناگهانی و شدید ترافیک در ساعت‌های غیرمعمول روز.
    • افزایش عجیب در درخواست‌ها برای یک صفحه یا یک نقطه پایانی خاص.
    • کند شدن غیرعادی عملکرد شبکه برای مدت طولانی.

    البته علائم دیگه‌ای هم وجود داره که بسته به نوع حمله میتونن متفاوت باشن. برای اینکه انواع حمله رو بهتر بفهمیم، اول باید ببینیم یه اتصال اینترنتی چطوری کار میکنه.

    لایه‌های اتصال اینترنتی: ساختمون ۷ طبقه ما

    یه اتصال اینترنتی از چندین لایه مختلف تشکیل شده. مثل ساختن یه خونه که از پی شروع میشه و طبقه به طبقه بالا میره، هر لایه توی شبکه هم یه وظیفه خاص داره. یه مدل مفهومی برای توصیف این لایه‌ها وجود داره به اسم مدل OSI که ۷ تا لایه داره. حمله‌های DDoS میتونن لایه‌های مختلفی از این ساختمون رو هدف قرار بدن.

    حالا که با این مفهوم آشنا شدیم، بریم سراغ سه دسته اصلی حمله‌های DDoS.

    انواع حمله‌های DDoS: سه تفنگدار خرابکار

    تقریبن همه حمله‌های DDoS هدفشون یکیه‌: غرق کردن هدف با ترافیک. اما روش‌هاشون متفاوته. مهاجم‌ها میتونن از یه روش یا ترکیبی از چند روش استفاده کنن.

    ۱. حمله‌های لایه اپلیکیشن (Application Layer Attacks)

    این حمله‌ها که بهشون حمله‌های لایه ۷ هم میگن (چون لایه هفتم مدل OSI رو هدف میگیرن)، مستقیمن سراغ خود اپلیکیشن یا وبسایت میرن. هدفشون اینه که منابع سرور رو تموم کنن.

    چطوری؟ این حمله‌ها لایه‌ای رو هدف میگیرن که توش صفحات وب ساخته میشن و به درخواست‌های HTTP جواب داده میشه. برای یه کاربر، فرستادن یه درخواست HTTP (مثلن باز کردن یه صفحه وب) کار ساده و کم‌هزینه‌ایه. اما برای سرور، جواب دادن به اون درخواست میتونه پرهزینه باشه. سرور باید کلی فایل رو بارگذاری کنه، از دیتابیس اطلاعات بگیره و در نهایت یه صفحه وب کامل رو بسازه.

    حمله HTTP Flood: این یکی از رایج‌ترین حمله‌های لایه ۷ هست. مثل این میمونه که شما و هزاران نفر از دوستاتون روی کامپیوترهای مختلف، دکمه رفرش یه مرورگر رو پشت سر هم فشار بدید. سرور با سیلی از درخواست‌های HTTP مواجه میشه و در نهایت از کار میفته.

    • نسخه‌های ساده: ممکنه مهاجم با یه سری آدرس IP محدود، یه آدرس URL خاص رو هدف قرار بده.
    • نسخه‌های پیچیده: مهاجم از تعداد زیادی آدرس IP استفاده میکنه و آدرس‌های URL تصادفی رو با اطلاعات ارجاع‌دهنده (Referrer) و عامل کاربر (User Agent) تصادفی هدف قرار میده تا شناسایی‌اش سخت‌تر بشه.

    مقابله با حمله‌های لایه ۷ سخته، چون ترافیک حمله خیلی شبیه ترافیک کاربرهای واقعیه. این حمله‌ها میتونن شامل نقض پروتکل HTTP، حملات SQL Injection و Cross-Site Scripting هم باشن.

    ۲. حمله‌های پروتکلی (Protocol Attacks)

    این حمله‌ها که بهشون حمله‌های State-Exhaustion هم میگن، با مصرف بیش از حد منابع سرور یا تجهیزات شبکه مثل فایروال‌ها و لود بالانسرها، باعث قطعی سرویس میشن. این حمله‌ها از ضعف‌های لایه ۳ و ۴ پشته پروتکل استفاده میکنن تا هدف رو غیرقابل دسترس کنن.

    حمله SYN Flood: این یه مثال کلاسیک از حمله پروتکلیه. برای درکش، یه کارگر توی انبار رو تصور کنین که از جلوی فروشگاه سفارش میگیره.

    کارگر سفارش رو میگیره، میره بسته رو پیدا میکنه و منتظر تایید نهایی میمونه تا بسته رو بیاره جلو. حالا تصور کنین این کارگر کلی سفارش دیگه بدون تایید نهایی دریافت میکنه. دست‌هاش پر میشه، گیج میشه و دیگه نمیتونه بسته‌های بیشتری رو حمل کنه و سفارش‌های جدید بی‌پاسخ میمونن.

    این حمله از فرآیندی به اسم دست‌دهی سه‌مرحله‌ای (Three-way Handshake) در پروتکل TCP سوءاستفاده میکنه. وقتی دو تا کامپیوتر میخوان با هم ارتباط برقرار کنن، این فرآیند انجام میشه. مهاجم تعداد زیادی بسته TCP SYN (درخواست اولیه اتصال) با آدرس IP جعلی (Spoofed IP) به سمت هدف میفرسته.

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

    ۳. حمله‌های حجمی (Volumetric Attacks)

    هدف این دسته از حمله‌ها اینه که با مصرف کردن تمام پهنای باند موجود بین هدف و اینترنت، یه ترافیک سنگین ایجاد کنن. مقادیر عظیمی از داده با استفاده از روش‌هایی مثل تقویت (Amplification) یا با کمک یه بات‌نت به سمت هدف ارسال میشه.

    حمله DNS Amplification: این حمله مثل اینه که یه نفر به یه رستوران زنگ بزنه و بگه: «من از همه چی یکی میخوام، لطفن با من تماس بگیرید و کل سفارشم رو تکرار کنید». اما شماره‌ای که برای تماس مجدد میده، شماره تلفن قربانیه! اینجوری با یه تلاش خیلی کم، یه پاسخ خیلی طولانی و حجیم تولید میشه و برای قربانی فرستاده میشه.

    توی این حمله، مهاجم یه درخواست به یه سرور DNS باز (Open DNS Server) با یه آدرس IP جعلی (آدرس IP قربانی) میفرسته. سرور DNS هم یه پاسخ حجیم به اون آدرس IP جعلی (یعنی قربانی) میفرسته. اینجوری، مهاجم با فرستادن یه درخواست کوچیک، باعث میشه یه جواب خیلی بزرگتر به سمت قربانی ارسال بشه و پهنای باندش رو اشغال کنه.

    نگاهی عمیق‌تر به برخی از حملات خاص

    دنیای حملات DDoS خیلی متنوعه و روز به روز هم روش‌های جدیدی به وجود میاد. بیایید چند تا از این روش‌های خاص رو که اسم‌های جالبی هم دارن، با هم مرور کنیم.

    • Smurf Attack (حمله اسمورف): توی این روش، مهاجم بسته‌هایی رو به تعداد زیادی کامپیوتر توی یه شبکه میفرسته، اما آدرس فرستنده رو آدرس IP قربانی جا میزنه. همه اون کامپیوترها به اون بسته جواب میدن، اما جوابشون رو برای قربانی میفرستن. اینجوری قربانی با سیلی از جواب‌ها غرق میشه.
    • حملات Low and Slow (کم و آهسته): این حملات خیلی موذیانه هستن. به جای اینکه یهو حجم زیادی ترافیک بفرستن، ترافیک رو با سرعت خیلی کم ارسال میکنن تا توسط سیستم‌های امنیتی شناسایی نشن. حملاتی مثل Slowloris یا RUDY از این دسته‌ان. Slowloris با باز نگه داشتن تعداد زیادی اتصال HTTP و فرستادن ناقص درخواست‌ها، منابع سرور رو اشغال میکنه.
    • حمله Yo-Yo: این حمله مخصوصن سرویس‌های ابری رو هدف میگیره که از قابلیت مقیاس‌پذیری خودکار (Autoscaling) استفاده میکنن. مهاجم به طور متناوب حجم زیادی ترافیک میفرسته (که باعث میشه سرویس منابعش رو افزایش بده) و بعد ترافیک رو قطع میکنه (که باعث میشه منابع کاهش پیدا کنن). این بالا و پایین رفتن مداوم، میتونه سیستم رو مختل کنه و هزینه‌های زیادی به صاحب سرویس تحمیل کنه.
    • حمله دائمی از کار انداختن سرویس (PDoS – Permanent Denial-of-Service): این یکی از خطرناک‌ترین انواع حمله‌اس و بهش Phlashing هم میگن. هدفش اینه که به سیستم اونقدر آسیب بزنه که نیاز به تعویض یا نصب مجدد سخت‌افزار داشته باشه. مهاجم از آسیب‌پذیری‌های امنیتی دستگاه‌هایی مثل روترها یا پرینترها استفاده میکنه تا فریمور (Firmware) دستگاه رو با یه نسخه خراب یا معیوب جایگزین کنه. این کار دستگاه رو «آجر» یا Brick میکنه و کاملن غیرقابل استفاده میشه.
    • حملات چندوجهی (Multi-vector Attacks): مهاجم‌ها معمولن خیلی باهوش‌تر از این حرف‌ها هستن که فقط از یه روش استفاده کنن. توی یه حمله چندوجهی، از چندین مسیر و روش مختلف به طور همزمان برای حمله استفاده میشه. مثلن ممکنه یه حمله DNS Amplification (لایه ۳/۴) رو با یه حمله HTTP Flood (لایه ۷) ترکیب کنن. این کار تلاش‌های تیم امنیتی برای مقابله با حمله رو خیلی سخت‌تر میکنه، چون باید همزمان با چند جبهه بجنگن.
    • حمله پایدار و پیشرفته (APDoS – Advanced Persistent DoS): این نوع حمله با تهدیدهای پایدار و پیشرفته (APT) مرتبطه و خیلی پیچیده‌اس. این حملات میتونن هفته‌ها طول بکشن (طولانی‌ترین مورد ثبت شده ۳۸ روز بوده!). مهاجم‌ها در این سناریو به منابع محاسباتی و پهنای باند عظیمی دسترسی دارن و به طور تاکتیکی بین اهداف مختلف جابجا میشن تا تیم دفاعی رو گیج کنن، اما در نهایت تمرکزشون روی یه قربانی اصلیه.

    چرا کسی باید حمله DDoS انجام بده؟ انگیزه‌ها

    انگیزه‌های پشت این حملات خیلی متفاوته و میتونه از سرگرمی‌های بچه‌گانه تا جنگ‌های سایبری دولتی رو شامل بشه.

    • هکتیویسم (Hacktivism): بعضی افراد یا گروه‌ها برای بیان اعتراضشون به یه شرکت، سازمان یا دولت، به سرورهاشون حمله میکنن. هدفشون اینه که پیامی رو منتقل کنن یا توجه‌ها رو به یه موضوع خاص جلب کنن.
    • اخاذی و باج‌گیری (Extortion): این یکی از رایج‌ترین انگیزه‌هاست. مهاجم‌ها یه حمله کوچیک انجام میدن و بعد به شرکت قربانی پیام میدن که اگه مبلغی (معمولن به صورت ارز دیجیتال) پرداخت نکنن، با یه حمله خیلی بزرگتر برمیگردن. به این نوع حمله Ransom DDoS (RDoS) هم میگن.
    • رقابت تجاری: بعضی وقت‌ها یه شرکت برای اینکه رقیبش رو از میدون به در کنه، به سرویس‌های آنلاینش حمله میکنه تا در زمان‌های حساس مثل جمعه سیاه، مشتری‌ها نتونن ازش خرید کنن و به سراغ شرکت مهاجم برن.
    • انتقام شخصی: یه کارمند ناراضی یا یه مشتری عصبانی ممکنه برای انتقام گرفتن از یه شرکت، یه حمله DDoS ترتیب بده.
    • جنگ سایبری (Cyber Warfare): دولت‌ها ممکنه از حملات DDoS برای مختل کردن زیرساخت‌های حیاتی یه کشور دیگه (مثل بانک‌ها، سازمان‌های دولتی و…) استفاده کنن. این اتفاق به خصوص در زمان تنش‌های سیاسی، مثل جنگ روسیه و اوکراین، به شدت افزایش پیدا کرد.
    • سرگرمی و خرابکاری: بعضی مهاجم‌ها، به خصوص افراد کم‌سن‌وسال‌تر، صرفن برای تفریح، خودنمایی یا دیدن اینکه میتونن یه سیستم رو از کار بندازن، این کار رو میکنن.
    • پوششی برای حملات دیگه: گاهی اوقات یه حمله DDoS فقط یه ابزار برای پرت کردن حواس تیم امنیتیه. در حالی که همه دارن سعی میکنن جلوی حمله DDoS رو بگیرن، مهاجم اصلی از یه در پشتی وارد میشه و اطلاعات حساس رو میدزده یا بدافزار نصب میکنه.

    تاریخچه و رکوردهای دنیای DDoS: حمله‌هایی که فراموش نمیشن

    حمله‌های DDoS چیز جدیدی نیستن. اولین حمله شناخته‌شده در سال ۱۹۹۶ به Panix، یکی از قدیمی‌ترین ارائه‌دهندگان خدمات اینترنتی، انجام شد و اونها رو برای چند روز از کار انداخت. از اون موقع تا حالا، این حمله‌ها بزرگتر، پیچیده‌تر و پرتعدادتر شدن.

    بیایید چند تا از معروف‌ترین و بزرگترین حمله‌های تاریخ رو با هم مرور کنیم:

    سالهدفحجم/نرخ حملهنکات مهم
    ۲۰۱۳Spamhaus۳۰۰ گیگابیت بر ثانیهیکی از بزرگترین حملات زمان خودش که علیه یک سازمان ضد اسپم انجام شد.
    ۲۰۱۶وبلاگ Krebs و شرکت OVH۶۲۰ گیگابیت و ۱.۱ ترابیت بر ثانیهاولین نمایش قدرت بات‌نت Mirai که از دستگاه‌های IoT آلوده تشکیل شده بود.
    ۲۰۱۶شرکت Dyn (ارائه‌دهنده DNS)۱.۲ ترابیت بر ثانیهبزرگترین حمله بات‌نت Mirai که باعث شد سایت‌های بزرگی مثل توییتر، نتفلیکس و پی‌پال برای ساعاتی از دسترس خارج بشن.
    ۲۰۱۷گوگل۲.۵۴ ترابیت بر ثانیهاین حمله برای مدتی بزرگترین حمله ثبت‌شده در تاریخ بود که گوگل در سال ۲۰۲۰ اون رو فاش کرد.
    ۲۰۱۸GitHub۱.۳۵ ترابیت بر ثانیهیک حمله بزرگ که با استفاده از تکنیک تقویت Memcached انجام شد و نشون داد که دیگه برای حملات بزرگ لزومن به بات‌نت نیازی نیست.
    ۲۰۲۰Amazon Web Services (AWS)۲.۳ ترابیت بر ثانیهیکی از بزرگترین حملات حجمی که با استفاده از تکنیک تقویت CLDAP انجام شد.
    ۲۰۲۱یک مشتری Cloudflare۱۷.۲ میلیون درخواست بر ثانیهاین حمله از نوع لایه اپلیکیشن بود و توسط بات‌نت Mirai انجام شد.
    ۲۰۲۳چندین شرکت بزرگ۷۱ میلیون و ۳۹۸ میلیون درخواست بر ثانیهاین حملات با استفاده از یک آسیب‌پذیری جدید در پروتکل HTTP/2 به نام Rapid Reset انجام شد و رکوردهای حملات لایه اپلیکیشن رو شکست.
    ۲۰۲۴سرورهای غیررسمی Minecraft۳.۱۵ میلیارد بسته بر ثانیهیک حمله حجمی رکوردشکن از نظر تعداد بسته‌ها در ثانیه.

    این آمارها نشون میدن که مقیاس حملات DDoS به طور مداوم در حال افزایشه و مهاجم‌ها همیشه دنبال راه‌های جدیدی برای دور زدن سیستم‌های دفاعی هستن.

    چطوری با DDoS مقابله کنیم؟ استراتژی‌های دفاعی

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

    روش‌های مختلفی برای مقابله با این حملات وجود داره:

    1. Blackhole Routing (مسیریابی به سمت سیاه‌چاله): این ساده‌ترین راهه. وقتی حمله‌ای شناسایی میشه، ارائه‌دهنده سرویس اینترنت (ISP) میتونه کل ترافیک اون آدرس IP رو به یه مسیر پوچ یا «سیاه‌چاله» هدایت کنه. این کار باعث میشه هم ترافیک مخرب و هم ترافیک قانونی دور ریخته بشن. در واقع این روش به مهاجم چیزی رو میده که میخواسته: غیرقابل دسترس کردن سرویس. پس یه راه‌حل ایده‌آل نیست.
    2. Rate Limiting (محدود کردن نرخ درخواست‌ها): این روش تعداد درخواست‌هایی که یه سرور در یه بازه زمانی مشخص قبول میکنه رو محدود میکنه. این کار برای کند کردن ربات‌های وب‌اسکرپر یا حملات brute-force خوبه، اما به تنهایی برای مقابله با یه حمله DDoS پیچیده کافی نیست. با این حال، یه جزء مفید در یه استراتژی دفاعی کامله.
    3. Web Application Firewall (WAF – فایروال اپلیکیشن وب): یه WAF بین اینترنت و سرور اصلی قرار میگیره و مثل یه پروکسی معکوس عمل میکنه. WAF میتونه با فیلتر کردن درخواست‌ها بر اساس یه سری قوانین، جلوی حملات لایه ۷ رو بگیره. یکی از مزیت‌های کلیدی WAF اینه که میشه به سرعت قوانین جدیدی رو در پاسخ به یه حمله در حال وقوع، روی اون پیاده کرد.
    4. Anycast Network Diffusion (پخش کردن ترافیک در شبکه Anycast): این یکی از موثرترین روش‌ها برای مقابله با حملات حجمی بزرگه. توی این روش، ترافیک حمله به جای اینکه به یه نقطه برسه، در سراسر یه شبکه بزرگ از سرورهای توزیع‌شده پخش میشه.

    مثل این میمونه که یه رودخونه خروشان رو به چندین کانال کوچیک‌تر تقسیم کنیم. این کار باعث میشه فشار آب پخش بشه و دیگه قدرت تخریب نداشته باشه.

    این روش، تاثیر ترافیک حمله رو اونقدر پخش و کم میکنه که قابل مدیریت بشه. شرکت‌های بزرگی مثل Cloudflare از این روش استفاده میکنن. برای مثال، شبکه Cloudflare ظرفیتی معادل ۴۰۵ ترابیت بر ثانیه داره که چندین برابر بزرگترین حمله DDoS ثبت‌شده تا به امروزه.

    1. مراکز پاک‌سازی یا Scrubbing Centers: توی این روش، کل ترافیک به سمت یه مرکز تخصصی هدایت میشه. این مرکز ترافیک بد (DDoS) رو از ترافیک خوب (کاربران واقعی) جدا میکنه و فقط ترافیک تمیز رو به سمت سرور قربانی میفرسته.

    هیچ‌کدوم از این روش‌ها به تنهایی کافی نیستن. بهترین رویکرد، یه دفاع لایه‌لایه (Defense in Depth) هست که ترکیبی از راه‌حل‌های ابری و محلی (On-premise) رو برای شناسایی و مسدود کردن انواع مختلف حملات به کار میگیره.

    چطور از اینکه بخشی از مشکل باشیم، جلوگیری کنیم؟

    یادتونه گفتیم حملات DDoS از دستگاه‌های آلوده مردم عادی استفاده میکنن؟ خب، خیلی مهمه که ما خودمون بخشی از این ارتش زامبی نباشیم. برای این کار باید امنیت دستگاه‌های متصل به اینترنتمون رو جدی بگیریم:

    • نصب و به‌روزرسانی آنتی‌ویروس: این اولین و مهم‌ترین قدمه.
    • استفاده از فایروال: فایروال رو فعال و درست تنظیم کنید تا ترافیک ورودی و خروجی رو کنترل کنه.
    • تغییر رمزهای عبور پیش‌فرض: این نکته به خصوص برای دستگاه‌های IoT مثل روتر، دوربین و… خیلی حیاتیه. اکثر این دستگاه‌ها با رمزهای عبور ساده و پیش‌فرض عرضه میشن که هکرها عاشقشونن.
    • رعایت عادات امنیتی خوب: روی لینک‌های مشکوک کلیک نکنید و نرم‌افزارها رو فقط از منابع معتبر دانلود کنید.

    پرسش و پاسخ: سوالات شما در مورد DDoS

    سوال: فرق بین حمله DoS و DDoS چیه؟
    جواب: خیلی ساده‌اس. توی حمله DoS (Denial of Service)، ترافیک مخرب فقط از یک منبع یا یه کامپیوتر میاد. این نوع حمله ساده‌تره و راحت‌تر هم میشه جلوش رو گرفت (کافیه اون یه منبع رو مسدود کنی). اما توی حمله DDoS (Distributed Denial of Service)، ترافیک از صدها، هزاران یا حتی میلیون‌ها منبع مختلف (بات‌نت) میاد. این توزیع‌شده بودن، شناسایی و مسدود کردن حمله رو خیلی خیلی سخت‌تر میکنه.

    سوال: آیا یه فایروال معمولی میتونه جلوی حمله DDoS رو بگیره؟
    جواب: به تنهایی، نه. یه فایروال مثل یه نگهبان دم در عمل میکنه و میتونه جلوی بعضی ویروس‌ها و ترافیک‌های مخرب مشخص رو بگیره. اما فایروال‌ها برای مقابله با حجم عظیم ترافیک حملات DDoS طراحی نشدن و خودشون هم میتونن تحت فشار از کار بیفتن. برای مقابله با DDoS به راه‌حل‌های تخصصی‌تری مثل WAF، مراکز پاک‌سازی و شبکه‌های Anycast نیاز داریم.

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

    سوال: چرا شرکت‌های بزرگی مثل بلیزارد یا گوگل نمیتونن «فقط درستش کنن»؟
    جواب: این یه تصور اشتباه رایجه. حمله DDoS مثل یه باگ یا یه حفره امنیتی نیست که بشه با یه پچ نرم‌افزاری «درستش کرد». این یه مشکل زیرساختیه. فکر کنین یه نفر تصمیم بگیره کل خیابون‌های منتهی به دفتر شرکت شما رو با کامیون مسدود کنه. شما نمیتونید با یه «دکمه» اون کامیون‌ها رو غیب کنید. باید با پلیس و شهرداری هماهنگ کنید تا مسیرها رو باز کنن. مقابله با DDoS هم همینطوره. نیاز به زیرساخت‌های عظیم، قراردادهای گران‌قیمت با شرکت‌های امنیتی و نظارت ۲۴ ساعته داره. این یه جنگ دائمیه، نه یه مشکل که یه بار برای همیشه حل بشه.

    سوال: آیا انجام حمله DDoS غیرقانونیه؟
    جواب: بله، قطعن. در اکثر کشورهای دنیا، از جمله آمریکا و کشورهای اروپایی، انجام حملات DDoS یه جرم فدرال محسوب میشه و مجازات‌های سنگینی مثل زندان و جریمه‌های نقدی بالا داره. حتی استفاده از سرویس‌های «استرس‌تستر» یا «بوتر» برای حمله به دیگران هم غیرقانونیه.

    سوال: آیا DDoS میتونه به عنوان یه شکل از اعتراض قانونی شناخته بشه؟
    جواب: این یه بحث پیچیده‌اس. بعضی‌ها معتقدن که DDoS میتونه یه شکل از نافرمانی مدنی دیجیتال باشه، شبیه تحصن یا تظاهرات. در سال ۲۰۱۳، گروه انانیموس حتی یه دادخواست به کاخ سفید ارائه داد تا DDoS به عنوان یه شکل قانونی از اعتراض شناخته بشه. اما از نظر قانونی، چون این کار به اموال و سرویس‌های دیگران آسیب میزنه و دسترسی کاربرهای قانونی رو مختل میکنه، تقریبن در همه جای دنیا به عنوان یه فعالیت مجرمانه در نظر گرفته میشه.

    منابع

    • [2] What Is a DDoS Attack? | Microsoft Security
    • [4] What Is a DDoS Attack? How It Works, Trends, Types & Mitigation | Radware
    • [6] What Is a DDoS Attack? | Akamai
    • [8] What is a DDoS attack and why can’t Blizzard just “fix it”? : r/wowhardcore
    • [10] Five Most Famous DDoS Attacks and Then Some | A10 Networks
    • [1] What is a distributed denial-of-service (DDoS) attack? | Cloudflare
    • [3] Denial-of-service attack – Wikipedia
    • [5] What is a DDoS Attack? DDoS Meaning, Definition & Types | Fortinet
    • [7] Understanding Denial-of-Service Attacks | CISA
    • [9] What is DDoS Attack? – Types of DDoS Attacks – Check Point Software
  • پلی‌رایت Playwright، راهنمای اتوماسیون و تست مرورگرها

    پلی‌رایت (Playwright). احتمالا اسمش رو شنیدید یا دیدید که توی شرکت‌ها و تیم‌های مختلف، بحث بین استفاده از این ابزار و ابزارهای قدیمی‌تر مثل سلنیوم (Selenium) یا حتی رقبای جدیدترش مثل سایپرس (Cypress) داغه. مثلا یه جا ممکنه یه توسعه‌دهنده جوون و تازه‌نفس بیاد و بگه «بیاید فریم‌ورک Robot Framework رو با پلی‌رایت جایگزین کنیم» و کل تیم رو به چالش بکشه. هدف ما اینجا اینه که ببینیم این پلی‌رایت اصلا چی هست، چطور کار میکنه، و چه چیزهایی رو باید در موردش بدونیم. پس آماده باشید که میخوایم قدم به قدم این ابزار رو کالبدشکافی کنیم.

    پلی‌رایت چیه و به چه دردی میخوره؟

    پلی‌رایت یه فریم‌ورک اوپن‌سورس برای اتوماسیون و تست وب هست که توسط مایکروسافت توسعه داده شده. فکر کن میخوای مطمئن بشی که وبسایتت روی همه مرورگرها درست کار میکنه. به جای اینکه خودت دستی بری و دونه دونه دکمه‌ها رو کلیک کنی و فرم‌ها رو پر کنی، میتونی به پلی‌رایت بگی این کار رو برات انجام بده.

    این ابزار با یه API واحد، بهت اجازه میده که تعاملات کاربر رو توی مرورگرهای کرومیوم (Chromium)، فایرفاکس (Firefox) و وب‌کیت (WebKit) شبیه‌سازی کنی.

    مهمترین کاربردهای پلی‌رایت اینها هستن:

    • تست End-to-End: از اول تا آخر یه سناریوی کاربری رو تست میکنه. مثلا از لاگین کردن گرفته تا اضافه کردن محصول به سبد خرید و پرداخت.
    • وب اسکرپینگ (Web Scraping): برای استخراج اطلاعات از وبسایت‌ها به صورت خودکار استفاده میشه.
    • مانیتورینگ عملکرد: عملکرد وبسایت رو زیر نظر میگیره تا ببینه همه چیز روان و سریع اجرا میشه یا نه.

    پلی‌رایت یه ویژگی خیلی مهم داره و اونم اینه که میتونه تست‌ها رو در حالت headless اجرا کنه. یعنی مرورگر باز میشه و کارها رو انجام میده، اما شما هیچ رابط کاربری گرافیکی یا پنجره‌ای ازش نمیبینید. همه چیز توی پس‌زمینه و از طریق خط فرمان اتفاق میفته. البته اگه بخواید، میتونید تنظیمش کنید که مرورگر رو به صورت کامل (non-headless) هم نشون بده.

    این ابزار روی پلتفرم‌های مختلف مثل ویندوز، لینوکس و macOS کار میکنه و میتونی با زبان‌های برنامه‌نویسی مختلفی مثل TypeScript، جاوااسکریپت، پایتون، دات‌نت و جاوا ازش استفاده کنی.

    ویژگی‌هایی که پلی‌رایت رو متمایز میکنه

    • Auto-wait (انتظار خودکار): یکی از دلایل اصلی که تست‌ها شکننده (flaky) میشن و گاهی کار میکنن و گاهی نه، اینه که اسکریپت تست زودتر از آماده شدن یه دکمه یا یه بخش از صفحه، میخواد روش کلیک کنه. پلی‌رایت به طور خودکار منتظر میمونه تا اون عنصر «قابل استفاده» بشه و بعد کارش رو انجام میده. اینطوری نیاز به استفاده از تایم‌اوت‌های مصنوعی که باعث دردسر میشن، از بین میره.
    • Web-first assertions (ادعاهای وب-محور): دستورات بررسی (assertions) توی پلی‌رایت مخصوص دنیای وب طراحی شدن. یعنی به طور خودکار یه شرط رو چک میکنن و اگه درست نبود، چند بار دیگه هم تلاش میکنن تا شاید اون شرط برقرار بشه.
    • Tracing (ردیابی): میتونی تست‌ها رو طوری تنظیم کنی که اگه شکست خوردن، یه گزارش کامل شامل ویدیو، اسکرین‌شات و تمام اتفاقاتی که افتاده رو بهت بده. اینجوری پیدا کردن دلیل مشکل خیلی راحت‌تر میشه.
    • ایزوله‌سازی کامل: پلی‌رایت برای هر تست، یه «کانتکست مرورگر» (browser context) جدید میسازه که مثل یه پروفایل کاملا نو و دست‌نخورده مرورگر میمونه. این کار باعث میشه تست‌ها روی هم اثر نذارن و کاملا از هم جدا باشن. ساختن این کانتکست‌ها هم خیلی سریعه و فقط چند میلی‌ثانیه طول میکشه.
    • پشتیبانی از سناریوهای پیچیده: میتونی سناریوهایی رو تست کنی که شامل چند تب، چند کاربر مختلف یا حتی چند مبدا (origin) متفاوت هستن.
    • رویدادهای قابل اعتماد (Trusted events): پلی‌رایت از پایپ‌لاین ورودی واقعی مرورگر استفاده میکنه. یعنی وقتی میگه روی یه چیزی کلیک کرده، اون کلیک از نظر مرورگر با کلیک یه کاربر واقعی هیچ فرقی نداره.

    نصب و راه‌اندازی اولیه پلی‌رایت

    خب، حالا که فهمیدیم پلی‌رایت چیه، بریم ببینیم چطور باید نصبش کنیم. قبل از هر چیز، باید Node.js نسخه ۲۰، ۲۲ یا ۲۴ روی سیستمت نصب باشه. سیستم‌عاملت هم میتونه ویندوز ۱۰ به بالا، macOS 14 به بالا، یا توزیع‌های لینوکس مثل دبیان ۱۲/۱۳ و اوبونتو ۲۲.۰۴/۲۴.۰۴ باشه.

    برای شروع، میتونی از دستور زیر توی ترمینال پروژه‌ات استفاده کنی:

    # با استفاده از npm
    npm init playwright@latest
    
    # با استفاده از yarn
    yarn create playwright
    
    # با استفاده از pnpm
    pnpm create playwright

    وقتی این دستور رو اجرا میکنی، چند تا سوال ازت میپرسه:

    • میخوای از TypeScript استفاده کنی یا JavaScript؟
    • اسم پوشه تست‌هات چی باشه؟ (معمولا tests یا e2e)
    • میخوای یه فایل workflow برای GitHub Actions اضافه بشه؟ (برای اجرای تست‌ها به صورت خودکار در محیط CI/CD خوبه)
    • مرورگرهای پلی‌رایت نصب بشن؟ (که معمولا جواب «بله» هست)

    بعد از اینکه این مراحل تموم شد، این فایل‌ها و پوشه‌ها به پروژه‌ات اضافه میشن:

    • playwright.config.ts: فایل اصلی تنظیمات پلی‌رایت. اینجا مشخص میکنی تست‌ها روی چه مرورگرهایی، با چه تنظیماتی و … اجرا بشن.
    • package.json: وابستگی‌های پروژه اینجا اضافه میشه.
    • tests/example.spec.ts: یه فایل تست نمونه خیلی ساده.
    • tests-examples/demo-todo-app.spec.ts: یه فایل تست نمونه کامل‌تر که میتونی ازش الگو بگیری.

    بعد از نصب اولیه، باید مرورگرها رو نصب کنی. این دستور هر سه مرورگر اصلی (کرومیوم، فایرفاکس و وب‌کیت) رو دانلود میکنه:

    npx playwright install

    اجرای تست نمونه

    حالا که همه چیز آماده‌ست، میتونی تست نمونه رو اجرا کنی. به طور پیش‌فرض، تست‌ها به صورت موازی و در حالت headless روی هر سه مرورگر اجرا میشن.

    # با استفاده از npm
    npx playwright test
    
    # با استفاده از yarn
    yarn playwright test
    
    # با استفاده از pnpm
    pnpm exec playwright test

    چند تا نکته برای اجرای تست‌ها:

    • اگه میخوای پنجره مرورگر رو ببینی، از فلگ --headed استفاده کن.
    • اگه میخوای تست‌ها فقط روی یه مرورگر خاص اجرا بشن، از --project=chromium استفاده کن.
    • برای اجرای فقط یه فایل تست خاص: npx playwright test tests/example.spec.ts
    • برای باز کردن رابط کاربری گرافیکی تست: --ui

    گزارش تست HTML

    بعد از اینکه تست‌ها تموم شدن، میتونی گزارش HTML رو ببینی. این گزارش بهت یه داشبورد کامل میده که میتونی تست‌ها رو بر اساس مرورگر، وضعیت (موفق، ناموفق، رد شده) فیلتر کنی. اگه تستی شکست خورده باشه، میتونی روش کلیک کنی و خطاها، فایل‌های ضمیمه و مراحل اجرا رو ببینی. این گزارش معمولا فقط وقتی تستی شکست بخوره به طور خودکار باز میشه، اما میتونی با دستور زیر هم به صورت دستی بازش کنی:

    npx playwright show-report

    مدیریت مرورگرها: قلب تپنده پلی‌رایت

    یکی از مهمترین مفاهیم توی پلی‌رایت، مدیریت مرورگرهاست. هر نسخه از پلی‌رایت برای کار کردن به نسخه‌های خیلی مشخصی از باینری‌های مرورگر نیاز داره. این یعنی هر بار که خود پلی‌رایت رو آپدیت میکنی، احتمالا باید دستور install رو دوباره اجرا کنی تا مرورگرهای سازگار با اون نسخه هم دانلود بشن.

    نصب مرورگرها و وابستگی‌ها

    همونطور که گفتیم، دستور اصلی برای نصب مرورگرها اینه:

    npx playwright install

    اما میتونی کارهای دیگه‌ای هم انجام بدی:

    • نصب یک مرورگر خاص:
      npx playwright install webkit
    • دیدن لیست تمام مرورگرهای قابل نصب:
      npx playwright install --help
    • نصب وابستگی‌های سیستمی: این دستور مخصوصا توی محیط‌های CI (Continuous Integration) خیلی به درد میخوره، چون تمام پکیج‌های مورد نیاز روی سیستم‌عامل رو نصب میکنه.
      npx playwright install-deps
    • نصب وابستگی‌های یک مرورگر خاص:
      npx playwright install-deps chromium
    • ترکیب نصب مرورگر و وابستگی‌ها:
      npx playwright install --with-deps chromium

    انواع مرورگرها و تنظیماتشون

    پلی‌رایت میتونه تست‌ها رو روی موتورهای اصلی رندر وب (کرومیوم، وب‌کیت، فایرفاکس) و همچنین مرورگرهای برنددار مثل گوگل کروم (Google Chrome) و مایکروسافت اج (Microsoft Edge) اجرا کنه.

    کرومیوم (Chromium)

    به طور پیش‌فرض، پلی‌رایت از بیلد اوپن‌سورس کرومیوم استفاده میکنه. یه نکته جالب اینه که پروژه کرومیوم همیشه از نسخه‌های نهایی مرورگرهایی مثل کروم جلوتره. یعنی وقتی نسخه N گوگل کروم تازه منتشر شده، پلی‌رایت już از کرومیوم نسخه N+1 پشتیبانی میکنه. این بهت کمک میکنه که مشکلات احتمالی وبسایتت با نسخه‌های آینده کروم رو زودتر پیدا کنی.

    پلی‌رایت دو تا بیلد از کرومیوم رو ارائه میده:

    1. بیلد معمولی کرومیوم: برای عملیات headed (با رابط کاربری).
    2. پوسته headless کرومیوم (chromium headless shell): یه نسخه سبک‌تر که فقط برای اجرای headless استفاده میشه.

    اگه تست‌هات رو فقط در حالت headless اجرا میکنی (مثلا روی CI)، میتونی موقع نصب با اضافه کردن فلگ --only-shell از دانلود کردن بیلد کامل کرومیوم جلوگیری کنی و در فضا صرفه‌جویی کنی.

    npx playwright install --with-deps --only-shell
    حالت headless جدید کروم:

    یه حالت headless جدید هم وجود داره که میتونی با استفاده از کانال «chromium» فعالش کنی. طبق مستندات خود کروم:

    حالت Headless جدید، در واقع خود مرورگر واقعی کروم هست و به همین دلیل معتبرتر، قابل اعتمادتر و با امکانات بیشتره. این باعث میشه برای تست‌های end-to-end با دقت بالا یا تست افزونه‌های مرورگر مناسب‌تر باشه.

    برای استفاده از این حالت، باید فلگ --no-shell رو موقع نصب بزنی تا پوسته headless قدیمی دانلود نشه.

    npx playwright install --with-deps --no-shell
    گوگل کروم و مایکروسافت اج

    پلی‌رایت میتونه با نسخه‌های برنددار کروم و اج که روی سیستم شما نصب هستن هم کار کنه (البته به طور پیش‌فرض اونها رو نصب نمیکنه). پلی‌رایت از کانال‌های Stable و Beta این مرورگرها پشتیبانی میکنه.

    کانال‌های موجود اینها هستن: chrome, msedge, chrome-beta, msedge-beta, chrome-dev, msedge-dev, chrome-canary, msedge-canary.

    اگه این مرورگرها روی سیستمت نصب نیستن، میتونی با خود پلی‌رایت نصبشون کنی:

    npx playwright install msedge

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

    چه زمانی از کروم/اج استفاده کنیم و چه زمانی نه؟
    • حالت پیش‌فرض (کرومیوم): در بیشتر موارد، استفاده از کرومیوم پیش‌فرض پلی‌رایت بهترین گزینه‌ست. چون جلوتر از نسخه‌های پایدار هست، بهت این اطمینان رو میده که آپدیت‌های آینده کروم وبسایتت رو خراب نمیکنه.
    • تست رگرسیون (Regression testing): بعضی وقت‌ها سیاست‌های تست شرکت ایجاب میکنه که تست‌ها حتما روی نسخه‌های عمومی و پایدار فعلی مرورگرها اجرا بشن. در این حالت، میتونی از کانال‌های chrome یا msedge استفاده کنی.
    • کدک‌های مدیا (Media codecs): کرومیوم به خاطر مسائل لایسنس، همه کدک‌های ویدیویی و صوتی که کروم و اج دارن رو شامل نمیشه. اگه وبسایتت به این کدک‌های خاص وابسته هست، باید از نسخه‌های رسمی استفاده کنی.
    • سیاست‌های سازمانی (Enterprise policy): کروم و اج به سیاست‌های سازمانی احترام میذارن. این سیاست‌ها ممکنه محدودیت‌هایی مثل پروکسی شبکه یا افزونه‌های اجباری ایجاد کنن که جلوی تست رو میگیرن. در این شرایط، راحت‌ترین کار اینه که برای تست‌های lokal از کرومیوم باندل شده استفاده کنی و روی سرورهای CI که معمولا این محدودیت‌ها رو ندارن، از کانال‌های پایدار استفاده کنی.
    فایرفاکس (Firefox)

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

    وب‌کیت (WebKit)

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

    چالش‌های پیشرفته: داکر، فایروال و مشکلات رایج

    وقتی از سطح مبتدی فراتر میریم، با یه سری چالش‌های واقعی روبرو میشیم. بیا چند تاشون رو بررسی کنیم.

    پیش‌نصب مرورگرها در داکر برای CI

    یکی از مشکلات رایج اینه: یه نفر میخواد یه کانتینر داکر برای محیط CI بسازه که مرورگرها و وابستگی‌های پلی‌رایت از قبل روش نصب باشن تا مراحل تست سریع‌تر اجرا بشه. اون شخص دستور playwright install-deps رو توی Dockerfile اجرا میکنه و به نظر میاد مرورگر نصب میشه. اما وقتی به مرحله تست میرسه و دستور npx playwright install chromium رو توی پروژه اجرا میکنه، میبینه که مرورگر داره دوباره از اول دانلود میشه!

    این سوال مطرح میشه: چطور میشه مرورگرها رو در یک کانتینر داکر پیش‌نصب کرد بدون اینکه در مرحله تست دوباره دانلود بشن؟

    مستندات پلی‌رایت به طور خاص میگن که install-deps برای محیط‌های CI مفیده، اما باید مطمئن بشیم که مسیر نصب مرورگرها در مرحله ساخت ایمیج داکر و مرحله اجرای تست یکی باشه تا پلی‌رایت بتونه پیداشون کنه.

    ایمیج رسمی داکر پلی‌رایت:

    برای حل این مشکل، خود پلی‌رایت یه ایمیج رسمی داکر ارائه میده که روی اوبونتو ۲۴.۰۴ ساخته شده. توصیه میشه که از نسخه‌ای از این ایمیج استفاده کنید که با نسخه پلی‌رایت پروژه‌تون یکی باشه. اگه نسخه پلی‌رایت توی ایمیج داکر با نسخه پروژه‌تون نخونه، پلی‌رایت نمیتونه فایل‌های اجرایی مرورگر رو پیدا کنه.

    docker pull mcr.microsoft.com/playwright:v1.50.0-noble

    نصب پشت فایروال یا پروکسی

    به طور پیش‌فرض، پلی‌رایت مرورگرها رو از CDN مایکروسافت دانلود میکنه. بعضی شرکت‌ها یه پروکسی داخلی دارن که دسترسی مستقیم به اینترنت رو میبنده. در این حالت، باید پلی‌رایت رو تنظیم کنی که از طریق پروکسی دانلود کنه:

    # در Bash (لینوکس/macOS)
    HTTPS_PROXY=https://192.0.2.1 npx playwright install
    
    # در PowerShell (ویندوز)
    $Env:HTTPS_PROXY="https://192.0.2.1"
    npx playwright install

    اگه پروکسی شما از گواهی‌های دیجیتال (CA) نامعتبر استفاده میکنه و با خطای self signed certificate in certificate chain مواجه میشید، باید متغیر محیطی NODE_EXTRA_CA_CERTS رو تنظیم کنید.

    مدیریت مسیر نصب مرورگرها

    پلی‌رایت مرورگرها رو توی پوشه‌های کش مخصوص سیستم‌عامل ذخیره میکنه:

    • ویندوز: %USERPROFILE%\AppData\Local\ms-playwright
    • macOS: ~/Library/Caches/ms-playwright
    • لینوکس: ~/.cache/ms-playwright

    اگه بخوای این مسیر رو تغییر بدی، میتونی از متغیر محیطی PLAYWRIGHT_BROWSERS_PATH استفاده کنی. این کار بهت اجازه میده که مرورگرها رو توی یه پوشه اشتراکی نصب کنی و همه پروژه‌ها از همون استفاده کنن.

    # موقع نصب
    PLAYWRIGHT_BROWSERS_PATH=$HOME/pw-browsers npx playwright install
    
    # موقع اجرای تست
    PLAYWRIGHT_BROWSERS_PATH=$HOME/pw-browsers npx playwright test

    مشکل در NixOS: داستان کتابخانه‌های داینامیک

    یه چالش خیلی خاص برای کاربرای توزیع لینوکس NixOS پیش میاد. وقتی میخوان یه اسکریپت ساده پلی‌رایت رو اجرا کنن، با خطا مواجه میشن که میگه یه سری کتابخانه‌های اشتراکی (shared objects) پیدا نشدن.

    مشکل چیه؟

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

    راه حل چیه؟

    چند تا راه وجود داره، اما بهترین و ساده‌ترین راه اینه:

    1. استفاده از playwright-core: به جای پکیج کامل playwright، از پکیج playwright-core استفاده کنید. این پکیج مرورگرها رو به صورت خودکار دانلود نمیکنه.
    2. استفاده از کرومیوم خود NixOS: کرومیومی که از طریق Nixpkgs نصب میشه، به صورت استاتیک لینک شده و به کتابخانه‌های خارجی نیازی نداره.
    3. مشخص کردن مسیر اجرایی: توی کدتون، به پلی‌رایت بگید که به جای استفاده از کرومیوم خودش، از کرومیومی که روی سیستم نصب هست استفاده کنه.
    // به جای require('playwright')
    const { chromium } = require('playwright-core');
    
    const browser = await chromium.launch({
      // مسیر کرومیومی که با which chromium پیدا کردید
      executablePath: '/home/jack/.nix-profile/bin/chromium',
      headless: false
    });

    اینطوری پلی‌رایت دیگه دنبال وابستگی‌های داینامیک نمیگرده و مشکل حل میشه.

    اون روی سکه: شناسایی و بلاک کردن پلی‌رایت

    با اینکه پلی‌رایت یه ابزار قدرتمند برای تست هست، اما میشه ازش برای کارهای دیگه‌ای مثل کلاهبرداری خودکار، پر کردن اعتبارنامه‌ها (credential stuffing) و جمع‌آوری داده هم سوءاستفاده کرد. به همین دلیل، خیلی از وبسایت‌ها سعی میکنن ربات‌هایی که با پلی‌رایت ساخته شدن رو شناسایی و بلاک کنن.

    چطور پلی‌رایت در حالت headless شناسایی میشه؟

    • ویژگی Navigator WebDriver: پلی‌رایت در حالت headless، مقدار navigator.webdriver رو توی جاوااسکریپت true میکنه.
    • الگوهای زمانی و تعاملی غیرعادی: اسکریپت‌های پلی‌رایت خیلی سریع‌تر از یه کاربر واقعی کار میکنن. کلیک‌های سریع، زمان بارگذاری صفحه غیرطبیعی و نبود هیچ زمان بیکاری (idle time)، نشونه‌های ربات هستن.
    • نبود حرکات واقعی موس: تعاملات پلی‌رایت حرکات ارگانیک موس یا اسکرول کردن طبیعی رو تولید نمیکنه.
    • هدرهای HTTP سفارشی: درخواست‌های ارسالی توسط پلی‌رایت ممکنه هدرهای ناقص یا ناهماهنگی مثل sec-ch-ua یا user-agent داشته باشن.
    • انگشت‌نگاری (Fingerprinting): تست‌های انگشت‌نگاری از طریق WebGL، Canvas و Audio API در حالت headless نتایج متفاوتی نسبت به یه مرورگر واقعی تولید میکنن.

    چطور میشه پلی‌رایت رو بلاک کرد؟

    • چالش‌های مبتنی بر جاوااسکریپت: استفاده از تکنیک‌های انگشت‌نگاری برای ردیابی حرکات موس یا رندر WebGL.
    • تشخیص ناهنجاری رفتاری: تحلیل رفتار کاربر مثل لاگین‌های متوالی سریع یا حجم بالای درخواست.
    • کپچا (CAPTCHA) و محدودیت نرخ (Rate Limiting): استفاده از کپچاهای پیشرونده و محدود کردن تعداد درخواست‌ها در یک بازه زمانی.
    • بررسی درخواست در سمت سرور: مانیتور کردن هدرهای HTTP غیر استاندارد و الگوهای ترافیک انبوه.

    یک بحث مهم: موتور مرورگر در برابر خود مرورگر

    یه بحث جالبی که توسط یکی از متخصصان به اسم Maaret Pyhäjärvi مطرح شده اینه که وقتی میگیم «پلی‌رایت همه مرورگرهای اصلی رو اتوماتیک میکنه»، داریم یه کم ماجرا رو ساده‌سازی میکنیم.

    موتورهای مرورگر، خود مرورگرها نیستن.

    لوگوی کرومیوم با لوگوی کروم فرق داره و این تفاوت‌ها مهمن. مرورگرها نسخه‌های مختلفی دارن و اینکه ما بتونیم فقط روی کروم (که در واقع کرومیوم هست) اتوماسیون انجام بدیم، به این معنی نیست که همه نسخه‌های مختلف کروم که کاربران واقعی ازش استفاده میکنن رو پوشش دادیم. نسخه‌های توسعه‌دهنده مرورگرها هم اون چیزی نیستن که کاربران نهایی شما اجرا میکنن.

    ایشون اشاره میکنه که با اومدن WebDriver Bidi برای همه مرورگرها، این پروتکل جایگزین CDP میشه و ممکنه شرایط رو تغییر بده.

    پرسش و پاسخ

    سوال ۱: آیا حتما باید هر سه مرورگر کرومیوم، فایرفاکس و وب‌کیت رو نصب کنم؟

    نه، اجباری نیست. شما میتونید موقع نصب مشخص کنید که فقط یک یا دو مرورگر خاص نصب بشن. مثلا با دستور npx playwright install chromium فقط کرومیوم نصب میشه. این کار به خصوص در محیط‌های CI برای صرفه‌جویی در فضا و زمان خیلی مفیده.

    سوال ۲: فرق بین playwright و playwright-core چیه؟

    پکیج playwright نسخه کامل هست که شامل خود کتابخانه و اسکریپت‌های دانلود خودکار مرورگرهاست. اما playwright-core یه نسخه سبک‌تره که فقط API اصلی پلی‌رایت رو داره و مرورگرها رو به صورت خودکار دانلود نمیکنه. این پکیج برای سناریوهای خاصی مثل کار با NixOS یا وقتی که میخواید از یه مرورگر از قبل نصب شده روی سیستم استفاده کنید، کاربرد داره.

    سوال ۳: آیا میتونم از نسخه فایرفاکسی که خودم روی کامپیوترم نصب کردم با پلی‌رایت استفاده کنم؟

    نه. همونطور که توی متن اشاره شد، پلی‌رایت برای کار با فایرفاکس به یه سری پچ‌های خاص نیاز داره. به همین دلیل، شما باید از نسخه فایرفاکسی استفاده کنید که خود پلی‌رایت دانلود و مدیریت میکنه و نمیتونید بهش بگید از نسخه برنددار و نصب شده روی سیستم استفاده کنه. این موضوع برای سافاری (وب‌کیت) هم صدق میکنه.

    سوال ۴: headless mode دقیقا یعنی چی؟

    حالت headless یعنی مرورگر تمام کارهای یک مرورگر عادی رو انجام میده (صفحات رو باز میکنه، جاوااسکریپت رو اجرا میکنه، روی دکمه‌ها کلیک میکنه)، اما هیچ پنجره یا رابط کاربری گرافیکی به شما نشون نمیده. همه این اتفاقات در پس‌زمینه رخ میده. این حالت برای اجرای تست‌ها روی سرورها (مثل محیط CI) که رابط گرافیکی ندارن، عالیه و معمولا سریع‌تر و سبک‌تر هم هست.

    سوال ۵: چرا تست‌های من روی CI شکست میخورن ولی روی کامپیوتر خودم درست کار میکنن؟

    این یکی از رایج‌ترین مشکلاته و دلایل زیادی میتونه داشته باشه. یکی از دلایل اصلی که به پلی‌رایت مرتبطه، میتونه مربوط به وابستگی‌های سیستمی باشه. ممکنه روی سیستم عامل سرور CI شما، پکیج‌ها و کتابخانه‌هایی که مرورگرها برای اجرا شدن بهشون نیاز دارن، نصب نباشه. به همین دلیله که دستور npx playwright install-deps خیلی مهمه و باید قبل از اجرای تست‌ها در محیط CI اجرا بشه. دلیل دیگه میتونه تفاوت در نسخه مرورگرها یا خود پلی‌رایت بین دو محیط باشه.

    سوال ۶: آپدیت کردن پلی‌رایت چطوریه و چه نکته‌ای داره؟

    برای آپدیت کردن پلی‌رایت، از دستور npm install -D @playwright/test@latest (یا معادلش در yarn/pnpm) استفاده میکنید. نکته بسیار مهم اینه که بعد از آپدیت خود پکیج پلی‌رایت، تقریبا همیشه باید مرورگرها رو هم آپدیت کنید. چون هر نسخه جدید پلی‌رایت برای نسخه‌های جدیدتر و مشخصی از مرورگرها طراحی شده. اگه این کار رو فراموش کنید و تست‌ها رو اجرا کنید، خود پلی‌رایت یه خطای واضح بهتون میده و میگه که فایل اجرایی مرورگر رو پیدا نکرده و ازتون میخواد که npx playwright install رو اجرا کنید.

    “`

    منابع

    • [2] Robot Framework – Selenium vs. Playwright – Robot Framework – Robot Framework
    • [4] Running playwright tests – Help – NixOS Discourse
    • [6] Supported Playwright versions, browsers and OSes for Playwright tests on BrowserStack Automate | BrowserStack Docs
    • [8] Sharding Playwright tests by browser – Brian Birtles’ Blog
    • [10] Fast and reliable end-to-end testing for modern web apps | Playwright
    • [12] Use Playwright to automate and test in Microsoft Edge – Microsoft Edge Developer documentation | Microsoft Learn
    • [14] Running playwright with the local firefox – Stack Overflow
    • [16] GitHub – microsoft/playwright: Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.
    • [18] Browsers | Playwright .NET
    • [20] Browsers | Playwright
    • [1] Pre-installing Playwright Browsers and Dependencies in a Docker Container for CI
    • [3] Failed to install the browsers – Playwright Automation tool – Stack Overflow
    • [5] microsoft/playwright – Docker Image | Docker Hub
    • [7] Browsers | Playwright Python
    • [9] Listened to yet another “playwright automates all the main browsers” and ended up collecting logos for sketch. | Maaret Pyhäjärvi
    • [11] node.js – How to update / upgrade Playwright? – Stack Overflow
    • [13] Browser | Playwright
    • [15] What is Playwright headless browser ? How to identify and block it
    • [17] Cypress vs Playwright : r/QualityAssurance
    • [19] Installation | Playwright
  • پرداخت در ازای خزش، ایده کلادفلر که برای سایت‌ها درآمد ایجاد می‌کند

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

    معامله قدیمی اینترنت: ترافیک در برابر محتوا

    برای اینکه داستان جدید رو خوب بفهمیم، اول باید برگردیم عقب و ببینیم اینترنت تا قبل از این چطوری کار میکرد. حدود سی سال پیش، دو تا دانشجوی استنفورد یک پروژه تحقیقاتی به اسم «بک‌راب» (Backrub) رو شروع کردن. اون پروژه بعدها تبدیل شد به گوگل و گوگل هم سنگ بنای یک مدل اقتصادی بزرگ رو در اینترنت گذاشت.

    یک جور معامله نانوشته بین گوگل و کسایی که محتوا تولید میکردن (مثل سایت‌های خبری، وبلاگ‌ها، فروشگاه‌ها) شکل گرفت. معامله ساده بود:

    • تولیدکننده‌های محتوا به گوگل میگفتن: «بیا، اجازه داری کل سایت من رو کپی کنی و توی نتایج جستجوت نشون بدی».
    • گوگل هم در جواب میگفت: «باشه، در عوض من هم کاربرا رو از صفحه جستجو میفرستم به سایت تو».

    اینجا بود که بازی برد-برد به نظر میرسید. صاحب سایت از اون بازدیدکننده‌ها یا همون «ترافیک» پول درمیاورد؛ یا با تبلیغات، یا با فروش اشتراک یا هر روش دیگه‌ای. گوگل هم برای اینکه این چرخه کامل بشه، یک اکوسیستم کامل درست کرد:

    • گوگل سرچ (Google Search): ترافیک رو تولید میکرد.
    • گوگل ادسنس (AdSense): ابزاری بود که به صاحب سایت کمک میکرد از اون ترافیک پول دربیاره.
    • گوگل انلیتیکس (Google Analytics): ابزاری بود که میشد باهاش همه چیز رو اندازه گرفت و تحلیل کرد.

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

    بازیگر جدید از راه میرسه: ربات‌های هوشمند و پدیده «صفر کلیک»

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

    نتیجه چی میشه؟ شما از هوش مصنوعی یک سوال میپرسی، اون هم با استفاده از اطلاعاتی که از هزاران سایت جمع کرده، یک جواب کامل و حاضر و آماده بهت میده. دیگه نیازی نیست روی لینکی کلیک کنی و به سایت اصلی سر بزنی. به این میگن پدیده «صفر کلیک» (zero-click).

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

    آمار دروغ نمیگه: یک مبادله ناعادلانه

    برای اینکه ببینی این مبادله چقدر یک‌طرفه شده، به این آمارها که شرکت کلاودفلر منتشر کرده نگاه کن. این آمارها نشون میدن که ربات‌های هوش مصنوعی چند بار یک سایت رو میخونن (خزش یا اسکرِیپ میکنن) و در ازاش چند تا بازدیدکننده به اون سایت میفرستن:

    • ده سال پیش: گوگل به ازای هر بازدیدکننده‌ای که به یک سایت میفرستاد، ۲ صفحه از اون سایت رو میخوند.
    • شش ماه پیش:
      • گوگل: به ازای هر ۱ بازدیدکننده، ۶ بار سایت رو میخوند.
      • اوپن‌ای‌آی (OpenAI): به ازای هر ۱ بازدیدکننده، ۲۵۰ بار سایت رو میخوند.
      • انتروپیک (Anthropic): به ازای هر ۱ بازدیدکننده، ۶ هزار بار سایت رو میخوند.
    • امروز:
      • گوگل: به ازای هر ۱ بازدیدکننده، ۱۸ بار سایت رو میخوند.
      • اوپن‌ای‌آی: به ازای هر ۱ بازدیدکننده، ۱,۵۰۰ بار سایت رو میخوند.
      • انتروپیک: به ازای هر ۱ بازدیدکننده، ۶۰ هزار بار سایت رو میخوند.

    یک گزارش دیگه از تک‌کرانچ (TechCrunch) هم که به داده‌های ماه ژوئن اشاره داره، این اعداد رو تایید میکنه: ربات اوپن‌ای‌آی به ازای هر یک ارجاع، ۱۷۰۰ بار سایت رو خراشیده و ربات انتروپیک ۷۳ هزار بار. روند کاملا مشخصه: هوش مصنوعی میخونه، یاد میگیره و جواب میده، اما خیلی کم پیش میاد که کاربر رو به منبع اصلی بفرسته.

    راه‌حل جدید کلاودفلر: «پرداخت به ازای خزش» (Pay per Crawl)

    کلاودفلر یک شرکت خیلی بزرگه که خدمات شبکه تحویل محتوا یا CDN ارائه میده. اگه بخوایم ساده بگیم، مثل یک دروازه‌بان و سرویس‌دهنده خیلی سریع برای حدود ۲۰ درصد کل وب‌سایت‌های دنیا عمل میکنه. سایت‌های معروفی مثل ردیت، مدیوم، شاپیفای و گاردین از خدمات این شرکت استفاده میکنن. این یعنی وقتی کلاودفلر تصمیمی بگیره، میتونه اون رو در مقیاس خیلی خیلی بزرگی اجرا کنه.

    این شرکت حالا برای حل مشکل بالا، یک راهکار جدید به اسم «پرداخت به ازای خزش» (Pay per Crawl) رو معرفی کرده. ایده اصلی اینه که به جای دو گزینه قدیمی (یا به ربات‌ها اجازه دسترسی رایگان بده یا کلا مسدودشون کن)، یک گزینه سوم روی میز میذاره: ازشون پول بگیر.

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

    این سیستم چطوری کار میکنه؟

    ساز و کار فنی این ایده خیلی جالبه و روی زیرساخت‌های فعلی وب ساخته شده:

    • مسدودسازی پیش‌فرض: کلاودفلر اعلام کرده که به زودی، به طور پیش‌فرض جلوی تمام ربات‌های خزنده هوش مصنوعی رو برای سایت‌هایی که از خدماتش استفاده میکنن، میگیره. این یعنی اگه شما یک سایت جدید روی کلاودفلر راه‌اندازی کنی، ربات‌هایی مثل جی‌پی‌تی‌بات (GPTBot) دیگه نمیتونن به محتوای شما دسترسی داشته باشن، مگر اینکه خودت بهشون اجازه بدی.
    • بازار پرداخت به ازای خزش: اینجا جاییه که صاحب سایت میتونه تصمیم بگیره با ربات‌ها چیکار کنه. برای هر ربات هوش مصنوعی، سه تا انتخاب وجود داره:
      • اجازه دادن (Allow): میتونی به ربات اجازه بدی مثل قبل به صورت رایگان به محتوات دسترسی داشته باشه. در این حالت، سرور کد 200 OK رو برمیگردونه.
      • مسدود کردن (Block): میتونی کلا جلوی دسترسی ربات رو بگیری. سرور کد 403 Accessed Denied رو برمیگردونه که یعنی دسترسی ممنوعه.
      • دریافت هزینه (Charge): میتونی برای هر بار خزش یا بازدید ربات، یک قیمت مشخص کنی.
    • استفاده از کد ۴۰۲: وقتی یک ربات هوش مصنوعی میخواد به سایتی دسترسی پیدا کنه که گزینه «دریافت هزینه» رو فعال کرده، سرور سایت یک کد خیلی کم‌استفاده به اسم 402 Payment Required رو به ربات برمیگردونه. این کد به ربات میگه: «برای دیدن این محتوا باید پول پرداخت کنی». همراه این کد، اطلاعات قیمت هم فرستاده میشه.
    • پرداخت و دسترسی: حالا توپ تو زمین شرکت هوش مصنوعیه.
      • اگه ربات با پرداخت موافق باشه، یک درخواست دیگه با اطلاعات پرداخت میفرسته و بعدش محتوا رو با کد 200 OK دریافت میکنه.
      • اگه نخواد پول بده، دیگه دسترسی بهش داده نمیشه.
    • احراز هویت ربات‌ها: برای اینکه ربات‌ها نتونن هویت خودشون رو جعل کنن، کلاودفلر از امضاهای رمزنگاری شده Ed25519 استفاده میکنه. این کار مثل چک کردن کارت شناسایی رباته تا مطمئن بشن خودشه.
    • پرداخت آسان: خود کلاودفلر نقش واسطه مالی رو بازی میکنه. یعنی پول رو از شرکت‌های هوش مصنوعی میگیره و به حساب ناشرها واریز میکنه. اینطوری دیگه نیازی به قراردادهای پیچیده یا ارزهای دیجیتال نیست.

    متیو پرینس، مدیرعامل کلاودفلر، این روز رو «روز استقلال محتوا» (Content Independence Day) نامیده که در تاریخ ۱ ژوییه ۲۰۲۵ معرفی شده.

    کدام ربات‌ها مسدود میشن؟

    کلاودفلر هنوز لیست دقیقی از ربات‌هایی که مسدود میشن ارائه نکرده، اما اونها رو به سه دسته تقسیم کرده:

    • دستیار هوش مصنوعی (AI Assistant): مثل Perplexity-User و DuckAssistBot.
    • خزنده هوش مصنوعی (AI Crawler): مثل ربات گوگل بارد و ChatGPT.
    • جستجوی هوش مصنوعی (AI Search): مثل OAI-SearchBot.

    مدیرعامل کلاودفلر همچنین در شبکه اجتماعی ایکس اعلام کرده که «جمینی (Gemini) به صورت پیش‌فرض مسدود است». احتمالا صاحب سایت‌ها میتونن مشخص کنن که دقیقا کدوم ربات‌ها یا کدوم دسته‌ها رو مسدود یا مجاز کنن.

    طبق آمار خود کلاودفلر، فعال‌ترین ربات‌ها در شبکه این شرکت اینا هستن:

    • بایت‌اسپایدر (Bytespider): ربات شرکت بایت‌دنس (شرکت مادر تیک‌تاک) که از ۴۰.۴ درصد دامنه‌های تحت حفاظت کلاودفلر بازدید میکنه.
    • جی‌پی‌تی‌بات (GPTBot): ربات شرکت اوپن‌ای‌آی با ۳۵.۵ درصد بازدید.
    • کلادبات (ClaudeBot): ربات شرکت انتروپیک با ۱۱.۲ درصد بازدید.

    جالبه که جی‌پی‌تی‌بات، با اینکه از همه معروف‌تره، یکی از ربات‌هایی هست که بیشتر از بقیه در این شبکه مسدود میشه.

    واکنش‌ها به این طرح جدید چه بوده؟

    این ایده جدید کلاودفلر، مثل هر تغییر بزرگی، موافق‌ها و مخالف‌های خودش رو داره. بیا ببینیم هر گروه چی میگه.

    ناشران بزرگ: یک تغییردهنده بازی

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

    • راجر لینچ، مدیرعامل کاند نست (Condé Nast): این حرکت رو یک «تغییردهنده بازی برای ناشران» توصیف کرده که «یک استاندارد جدید برای احترام به محتوا در فضای آنلاین تعیین میکنه. وقتی شرکت‌های هوش مصنوعی دیگه نتونن هر چیزی رو که میخوان به صورت رایگان بردارن، دری به سوی نوآوری پایدار بر اساس اجازه و همکاری باز میشه.»
    • نیل ووگل از دات‌دش مردیت (Dotdash Meredith): میگه: «ما مدت‌هاست که میگیم پلتفرم‌های هوش مصنوعی باید برای استفاده از محتوای ما به ناشران و تولیدکنندگان محتوا غرامت منصفانه‌ای بپردازن. حالا میتونیم دسترسی به محتوامون رو به اون دسته از شرکای هوش مصنوعی محدود کنیم که مایل به مشارکت در ترتیبات منصفانه هستن.»
    • رن توریانو از گنت (Gannett): بر اهمیت این موضوع تاکید میکنه: «مسدود کردن برداشت غیرمجاز و استفاده از محتوای اصلی ما بدون جبران منصفانه، بسیار مهمه… ما خوش‌بینیم که فناوری کلاودفلر به مبارزه با سرقت مالکیت فکری ارزشمند کمک خواهد کرد.»
    • بیل ردی، مدیرعامل پینترست (Pinterest): توضیح میده که چطور این مدل با ماموریت اونها هماهنگه: «ما متعهد به ساختن یک زیرساخت اینترنتی سالم هستیم که در اون محتوا برای هدف مورد نظرش استفاده بشه تا تولیدکنندگان و ناشران بتونن رشد کنن.»

    ناشران بزرگی مثل تایم (TIME)، آتلانتیک (The Atlantic)، ادویک (ADWEEK)، بازفید (BuzzFeed)، فورچن (Fortune)، کورا (Quora) و استک اورفلو (Stack Overflow) هم به این طرح پیوستن.

    کسب‌وکارهای کوچک و وبلاگ‌نویس‌ها: یک شمشیر دو لبه؟

    اما برای کسب‌وکارهای کوچیک و متوسط (SMB) یا وبلاگ‌نویس‌های مستقل، قضیه کمی پیچیده‌تره. اینجا یک سوال مهم پیش میاد:

    آیا محتوای شما اونقدر ارزش داره که یک شرکت هوش مصنوعی حاضر بشه براش پول بده؟

    • برای یک خبرگزاری بزرگ، جواب احتمالا مثبته. مدل‌های هوش مصنوعی برای تولید جواب‌های دقیق به محتوای خبری نیاز دارن.
    • اما برای یک سایت کوچیک چطور؟ آیا هوش مصنوعی واقعا اونقدر به محتوای شما نیاز داره که براش هزینه کنه؟ یا میتونه اطلاعات مشابه یا حتی بهتر رو از منابع دیگه‌ای که رایگان هستن به دست بیاره؟

    این نگرانی وجود داره که این طرح، به جای کمک به کسب‌وکارهای کوچیک، بیشتر به ضررشون تموم بشه. اگه شرکت‌های هوش مصنوعی تصمیم بگیرن که برای محتوای اونها پولی پرداخت نکنن، این سایت‌ها نه تنها پولی دریافت نمیکنن، بلکه اون ذره‌ای از آگاهی از برند (brand awareness) که از طریق حضور در جواب‌های هوش مصنوعی به دست میاوردن رو هم از دست میدن و عملا نامریی میشن.

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

    شرکت‌های هوش مصنوعی: راهی به سوی نوآوری مسئولانه

    از دید شرکت‌های هوش مصنوعی و تیم‌های تحقیقاتی، این بازار میتونه یک جایگزین شفاف و کم‌دردسر برای بحث‌های حقوقی پیچیده کپی‌رایت باشه. به جای اینکه به صورت بی‌رویه محتوا جمع‌آوری کنن و امیدوار باشن که کارشون تحت عنوان «استفاده منصفانه» (fair use) قانونی تلقی بشه، میتونن با یک هزینه قابل پیش‌بینی، به محتوای باکیفیت دسترسی قانونی پیدا کنن. این کار ریسک حقوقی رو کم میکنه و رابطه بهتری با جامعه تولیدکنندگان محتوا ایجاد میکنه.

    جامعه علمی: یک نگرانی مهم

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

    این تغییرات چه تاثیری روی آینده جستجو و سئو داره؟

    خب، حالا که با کلیات ماجرا آشنا شدیم، بیا ببینیم این طرح جدید چه تاثیری روی دو مفهوم مهم یعنی سئو و جی‌ای‌او میذاره.

    تاثیر بر سئوی سنتی (SEO)

    اول از همه باید خیال همه رو راحت کنیم: کلاودفلر به صورت پیش‌فرض ربات‌های جستجوگر سنتی مثل گوگل‌بات (Googlebot) یا بینگ‌بات (BingBot) رو مسدود نمیکنه. تمرکز اصلی این طرح روی ربات‌های هوش مصنوعیه.

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

    اما یک نکته جالب وجود داره: کلاودفلر داره تلاش میکنه (چه با مذاکره و چه از راه قانونی) گوگل رو متقاعد کنه که ربات خودش یعنی گوگل‌بات رو به دو بخش جدا تقسیم کنه:

    • یک ربات برای جستجوی سنتی.
    • یک ربات برای خزش محتوا جهت استفاده در بخش‌های هوش مصنوعی مثل AI Overviews.

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

    تاثیر عمیق بر جی‌ای‌او (GEO)

    جی‌ای‌او (Generative Engine Optimization) یعنی بهینه‌سازی محتوا برای موتورهای تولیدکننده جواب مثل چت‌جی‌پی‌تی. تاثیر طرح «پرداخت به ازای خزش» روی جی‌ای‌او خیلی عمیق‌تر از سئوی سنتیه.

    برای اینکه این موضوع رو بفهمی، باید بدونی که مدل‌های هوش مصنوعی چطور کار میکنن. دو فرآیند اصلی وجود داره:

    • آموزش مدل (Training data): قبل از اینکه یک مدل بتونه به سوالی جواب بده، باید آموزش ببینه. در این مرحله، ربات‌ها حجم عظیمی از اطلاعات (متن، کد، عکس) رو از سراسر وب جمع‌آوری میکنن تا مدل بتونه زبان رو بفهمه و دانش پایه‌ای خودش رو در مورد دنیا شکل بده. این دانش، مثل فونداسیون یک ساختمونه.
    • بازیابی اطلاعات لحظه‌ای (Real-time information retrieval): بعد از اینکه مدل آموزش دید، میتونه برای جواب دادن به سوالات جدید، اطلاعات تازه رو از طریق ابزارهای خارجی (مثلا جستجو در بینگ) به دست بیاره. این مثل اینه که شما برای جواب دادن به یک سوال، سریع یک چیزی رو در اینترنت جستجو کنی.

    حالا ممکنه فکر کنی: «خب، اگه سایت من بینگ رو مسدود نکنه، پس چت‌جی‌پی‌تی هنوز میتونه محتوای من رو ببینه. پس مشکل چیه؟»

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

    وقتی سایت‌های بیشتری به طرح «پرداخت به ازای خزش» ملحق بشن و دسترسی ربات‌های هوش مصنوعی رو محدود کنن، سه اتفاق مهم میفته:

    • کاهش کیفیت جواب‌ها: حتی اگه هوش مصنوعی بتونه سایت تو رو از طریق بینگ ببینه، اگه در مرحله آموزش با محتوای مشابهی برخورد نکرده باشه، نمیدونه چطور اون رو تفسیر کنه یا بهش اولویت بده.
    • سوگیری به سمت منابع شناخته‌شده: مدل‌ها به منابعی که در زمان آموزش دیدن «اعتماد» بیشتری دارن. اگه محتوای تو بخشی از اون فرآیند آموزشی نبوده باشه، ممکنه در جواب‌های تولید شده نادیده گرفته بشی، فقط به این دلیل که مدل با سبک، فرمت یا اعتبار سایت تو آشنا نیست.
    • تاثیر بلندمدت بر جی‌ای‌او: هرچقدر سایت‌های بیشتری دسترسی ربات‌ها رو محدود کنن، داده‌های آموزشی کلی مدل‌ها کوچیک‌تر و محدودتر میشه. سایتی که در مرحله آموزش دیده نشده، وارد «نقشه ذهنی» مدل نمیشه، حتی اگه از نظر فنی در جستجوی لحظه‌ای قابل دسترسی باشه.

    خلاصه اینکه جی‌ای‌او فقط مربوط به دیده شدن نیست؛ مربوط به اینه که مدل هوش مصنوعی تو رو بشناسه، بهت اعتماد داشته باشه و درکت کنه. و همه اینها از مرحله آموزش شروع میشه.

    پرسش و پاسخ

    سوال: پس این طرح کلاودفلر یعنی دیگه نمیتونم از گوگل استفاده کنم؟

    جواب: نه اصلا. این طرح ربطی به استفاده شما از موتورهای جستجوی سنتی مثل گوگل یا بینگ نداره. ربات‌های این موتورهای جستجو به صورت پیش‌فرض مسدود نمیشن و شما مثل قبل میتونی ازشون استفاده کنی. این طرح بیشتر روی ربات‌هایی تمرکز داره که برای آموزش مدل‌های هوش مصنوعی مثل چت‌جی‌پی‌تی محتوا جمع میکنن.

    سوال: آیا این سیستم «پرداخت به ازای خزش» همین الان برای همه فعاله؟

    جواب: در حال حاضر، این برنامه در نسخه بتای خصوصی قرار داره. این یعنی هنوز برای همه در دسترس نیست و سایت‌ها باید برای شرکت در اون درخواست بدن (opt-in). اما برنامه کلاودفلر اینه که در آینده‌ای نامشخص، مسدودسازی ربات‌های هوش مصنوعی رو به صورت پیش‌فرض برای همه اجرا کنه.

    سوال: من یک وبلاگ کوچیک دارم. باید نگران باشم؟

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

    سوال: این پرداخت‌ها چطوری انجام میشه؟ آیا پیچیده است؟

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

    سوال: از کجا معلوم که یک ربات هویت خودش رو جعل نکنه و الکی بگه من ربات گوگل هستم؟

    جواب: کلاودفلر برای جلوگیری از این مشکل از سیستم‌های پیشرفته مدیریت ربات و امضاهای رمزنگاری شده به اسم Ed25519 استفاده میکنه. این فناوری‌ها کمک میکنن هویت ربات‌ها به طور دقیق تایید بشه تا جلوی جعل و تقلب گرفته بشه.

    “`

    منابع

    • [2] Cloudflare’s innovative “pay per crawl” lets publishers charge AI crawlers for content
    • [4] Just a moment…
    • [6] How Cloudflare’s Pay-Per-Crawl Marketplace Protects Publishers
    • [8] Cloudflare’s Pay Per Crawl: A turning point for SEO and GEO
    • [1] Publishers Push Back Against AI Data Scraping as Cloudflare Introduces ‘Pay per Crawl’ | Music AI
    • [3] Introducing pay per crawl: Enabling content owners to charge AI crawlers for access – Piccalilli
    • [5] The Future of Content and AI: Pay per Crawl and What’s Next – Cloudflare TV
    • [7] Legal News, Updates & Analysis | Advocate Daily
    • [9] Cloudflare’s Decision to Block AI Crawlers Could Affect Your Performance in LLMs | JumpFly Digital Marketing Blog