آموزش و مقالات شبکه، وب، سرور و اینترنت

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

برچسب: پروتکل

  • طوفان برادکست یا Broadcast Storm

    طوفان برادکست یا Broadcast Storm

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

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

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

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

    فصل دوم: مقصر اصلی کیه؟ رایج‌ترین دلیل طوفان

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

    سوییچ چیه و لوپ چطور به وجود میاد؟

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

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

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

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

    1. یک کامپیوتر یک پیام برادکست (مثلا همون پیام «سلام به همگی») رو به سوییچ می‌فرسته.
    2. سوییچ طبق وظیفه‌اش، این پیام رو از تمام پورت‌هاش کپی و ارسال می‌کنه. دو تا از این پورت‌ها، همون پورت‌هایی هستن که شما با یک کابل به هم وصلشون کردید.
    3. پس پیام برادکست از پورت شماره ۱ خارج میشه، وارد کابل لوپ میشه و از طریق همون کابل، دوباره به پورت شماره ۲ «وارد» سوییچ میشه.
    4. حالا سوییچ فکر می‌کنه یک پیام برادکست جدید از پورت شماره ۲ گرفته! پس دوباره طبق وظیفه‌اش، اون رو از تمام پورت‌های دیگه‌اش، از جمله پورت شماره ۱، می‌فرسته بیرون.
    5. این پیام دوباره وارد کابل لوپ میشه و برمی‌گرده به پورت شماره ۲.
    6. این چرخه تا ابد ادامه پیدا می‌کنه. هر بار که این پیام توی این حلقه می‌چرخه، یک کپی جدید ازش ساخته و در کل شبکه پخش میشه.

    ظرف چند میلی‌ثانیه، شبکه شما با میلیون‌ها کپی از یک پیام برادکست یکسان پر میشه. این همون طوفان برادکسته.

    چرا این بسته‌ها برای همیشه می‌چرخن؟

    شاید بپرسید مگه بسته‌های شبکه یک تاریخ انقضا ندارن که بعد از مدتی از بین برن؟ سوال خیلی خوبیه. بسته‌هایی که بین شبکه‌های مختلف (مثلا در اینترنت) جابجا میشن و روترها اونها رو مدیریت می‌کنن، یک چیزی به اسم (Time to Live (TTL دارن. این TTL یک عدده که با عبور از هر روتر، یکی ازش کم میشه. وقتی این عدد به صفر برسه، اون بسته از بین میره تا برای همیشه در اینترنت سرگردان نمونه.

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

    فصل سوم: وقتی طوفان عمدی به پا میشه! (حملات DoS)

    تا اینجا در مورد طوفان‌هایی صحبت کردیم که معمولا به خاطر یک اشتباه انسانی یا یک مشکل سخت‌افزاری به وجود میان. اما گاهی وقتا، یک نفر عمدا یک طوفان برادکست راه میندازه تا یک شبکه رو از کار بندازه. به این نوع حملات میگن حملات «منع سرویس» یا (Denial of Service – DoS). هدف این حملات اینه که یک سرویس یا یک شبکه رو اون‌قدر مشغول کنن که دیگه نتونه به کاربران واقعی سرویس بده.

    دو تا از معروف‌ترین حملاتی که از این تکنیک استفاده می‌کنن، حمله اسمرف (Smurf Attack) و حمله فراگل (Fraggle Attack) هستن. این حملات از یک تکنیک هوشمندانه به اسم «تقویت بسته» (packet amplification) استفاده می‌کنن. بیاید ببینیم چطوری کار می‌کنه:

    1. انتخاب قربانی: اول از همه، مهاجم یک قربانی رو انتخاب می‌کنه. این قربانی می‌تونه یک سرور، یک وب‌سایت یا حتی یک کامپیوتر شخصی باشه.
    2. جعل آدرس منبع: مهاجم شروع به ارسال یک عالمه بسته به یک شبکه بزرگ می‌کنه. اما یک حقه کثیف میزنه: آدرس «فرستنده» یا منبع (source address) این بسته‌ها رو به جای آدرس خودش، آدرس کامپیوتر «قربانی» جا میزنه. به این کار میگن (Spoofing).
    3. ارسال به آدرس برادکست: مهاجم این بسته‌های جعلی رو به جای اینکه به یک کامپیوتر خاص بفرسته، به آدرس برادکست (broadcast address) اون شبکه می‌فرسته. این آدرس مثل یک آدرس پستی عمومیه که وقتی نامه‌ای بهش فرستاده بشه، به تمام خانه‌های اون محله تحویل داده میشه.
    4. شروع طوفان: حالا چی میشه؟ وقتی این بسته‌ها به شبکه مقصد می‌رسن، «تمام» کامپیوترهای اون شبکه فکر می‌کنن که یک نفر (که به اشتباه فکر می‌کنن همون قربانیه) ازشون یک درخواستی داشته. پس همگی با هم شروع می‌کنن به جواب دادن به اون درخواست. اما این جواب‌ها رو برای کی می‌فرستن؟ برای آدرس منبعی که توی بسته‌ها دیده بودن، یعنی آدرس کامپیوتر «قربانی».

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

    مکانیزم دقیق‌تر حمله اسمرف

    در حمله اسمرف، بسته‌ای که مهاجم می‌فرسته از نوع ICMP Echo Request هست. این همون درخواستیه که وقتی شما از دستور ping استفاده می‌کنید، فرستاده میشه. مثل اینه که شما داد بزنید «هی، اونجایی؟» و منتظر جواب «آره، اینجام» باشید. مهاجم یک عالمه درخواست پینگ با آدرس جعلی قربانی به آدرس برادکست یک شبکه می‌فرسته. در نتیجه، تمام کامپیوترهای اون شبکه شروع می‌کنن به پینگ کردن قربانی. این سیل عظیم ترافیک باعث میشه:

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

    حمله فراگل هم دقیقا همین ساختار رو داره، با این تفاوت که به جای بسته‌های ICMP، از بسته‌های UDP استفاده می‌کنه.

    طوفان در دنیای بی‌سیم (Wi-Fi)

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

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

    فصل چهارم: چطور جلوی طوفان رو بگیریم؟ (راهکارهای پیشگیری و کنترل)

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

    ۱. مقابله با لوپ‌های سوییچینگ

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

    • پروتکل درخت پوشا (Spanning Tree Protocol – STP): این پروتکل یک جورایی پلیس راهنمایی و رانندگی شبکه‌های لایه ۲ هست. وقتی STP روی سوییچ‌ها فعال باشه، سوییچ‌ها با هم حرف می‌زنن و یک نقشه کامل از شبکه تهیه می‌کنن. اگه ببینن که بین دو نقطه، چند تا مسیر مختلف وجود داره (یعنی لوپ)، هوشمندانه یکی از مسیرها رو به صورت موقت «مسدود» یا بلاک می‌کنن. این کار باعث میشه که همیشه فقط یک مسیر فعال برای رسیدن به هر مقصدی وجود داشته باشه و جلوی به وجود اومدن حلقه گرفته بشه. البته همونطور که جلوتر در یک داستان واقعی خواهیم دید، بعضی از مدیران شبکه به خاطر پیچیدگی‌ها یا مشکلاتی که در گذشته باهاش داشتن، از فعال کردنش خودداری می‌کنن.
    • تکنولوژی‌های جدیدتر: به جز STP، راهکارهای مدرن‌تری هم وجود داره. مثلا agregación de enlaces (Link Aggregation) به شما اجازه میده چند تا کابل فیزیکی رو با هم ترکیب کنید تا به عنوان یک لینک منطقی و پرسرعت‌تر کار کنن که این کار هم به مدیریت بهتر مسیرها کمک می‌کنه. پروتکل Shortest Path Bridging هم یک جایگزین پیشرفته برای STP هست که مسیرها رو بهینه‌تر انتخاب می‌کنه.
    • حفاظت در شبکه‌های خاص (Metro Ethernet): در شبکه‌های بزرگ شهری که به صورت حلقه‌ای (Ring) طراحی میشن، از پروتکل‌های خاصی مثل Ethernet Ring Protection Switching (ERPS) یا Ethernet Automatic Protection System (EAPS) استفاده میشه که مخصوص جلوگیری از لوپ در این نوع معماری‌ها هستن.

    ۲. استفاده از تجهیزات لایه ۳ (روترها)

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

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

    ۳. تقسیم‌بندی منطقی شبکه با VLAN

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

    فرض کنید یک سوییچ ۴۸ پورت دارید. می‌تونید پورت‌های ۱ تا ۱۲ رو عضو VLAN شماره ۱۰ (مثلا مخصوص بخش مالی) کنید، پورت‌های ۱۳ تا ۲۴ رو عضو VLAN شماره ۲۰ (مخصوص بخش فروش) و به همین ترتیب. با اینکه همه این پورت‌ها روی یک دستگاه فیزیکی هستن، اما کامپیوترهای بخش مالی فقط می‌تونن با هم حرف بزنن و کامپیوترهای بخش فروش هم فقط با هم. این دو گروه کاملا از هم ایزوله هستن، انگار که به دو تا سوییچ جدا وصل شدن.
    مهم‌ترین نکته اینه که هر VLAN یک دامنه برادکست جداگانه برای خودش ایجاد می‌کنه. پس اگه توی VLAN بخش مالی یک طوفان برادکست به وجود بیاد، این طوفان فقط و فقط همون ۱۲ تا پورت رو درگیر می‌کنه و به VLAN بخش فروش یا بقیه قسمت‌های شبکه سرایت نمی‌کنه. این کار مثل اینه که به جای یک سالن بزرگ، چند تا اتاق کوچیک و ضدصدا درست کنیم. همهمه توی یک اتاق، مزاحم بقیه اتاق‌ها نمیشه.

    ۴. کنترل طوفان روی خود سوییچ‌ها

    خیلی از سوییچ‌های مدیریتی (Managed Switches) یک قابلیت خیلی به درد بخور به اسم «کنترل طوفان برادکست» (Broadcast Storm Control) دارن. این قابلیت مثل یک فیوز یا قطع‌کننده مدار عمل می‌کنه.

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

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

    ۵. پیکربندی روترها و فایروال‌ها برای حملات عمدی

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

    ۶. یک مورد خاص: شبکه‌های موبایلی Ad Hoc

    در شبکه‌های خاصی مثل MANET یا (Mobile Ad Hoc Network) که دستگاه‌ها (مثلا موبایل‌ها) بدون نیاز به اکسس پوینت مستقیما به هم وصل میشن، پیدا کردن مسیر برای ارسال داده یک چالش بزرگه. برای این کار، دستگاه‌ها بسته‌هایی به اسم RREQ یا (Route Request) رو به صورت برادکست ارسال می‌کنن تا بهترین مسیر به مقصد رو پیدا کنن. این بسته‌ها هم می‌تونن باعث طوفان برادکست بشن و با بسته‌های داده واقعی برای استفاده از کانال ارتباطی رقابت کنن. یک راه حل برای این مشکل اینه که الگوریتم‌هایی طراحی بشه که جلوی بازپخش (rebroadcasting) بی‌مورد این بسته‌ها رو توسط همه دستگاه‌ها بگیره تا از افزونگی و تصادم کم بشه.

    فصل پنجم: داستان یک روز جهنمی در مدرسه (یک مطالعه موردی واقعی)

    تئوری کافیه، بیاید بریم سراغ یک داستان واقعی که برای یک مدیر شبکه به اسم «دن» اتفاق افتاده. این داستان در یک فروم اینترنتی به اسم Spiceworks Community مطرح شده و به ما نشون میده که یک طوفان برادکست در دنیای واقعی چقدر می‌تونه گیج‌کننده و وحشتناک باشه.

    صحنه جرم: یک مدرسه بزرگ

    محل وقوع داستان یک مدرسه است با حدود ۹۰۰ دستگاه کامپیوتری و تقریبا ۶۰ تا سوییچ شبکه. بیشتر این سوییچ‌ها از برند Netgear و مدل‌های GS724T، GSM7224 و GSM7328S هستن. این مدرسه برای شبکه وای‌فای خودش هم از سیستم Meru و چند تا سوییچ PoE (که برق رو از طریق کابل شبکه منتقل می‌کنن) استفاده می‌کنه.
    دن، مدیر شبکه، میگه که در حال فعال‌سازی قابلیتی به اسم IGMP Snooping بوده (که برای مدیریت بهتر ترافیک مالتی‌کست استفاده میشه) اما هنوز روی همه سوییچ‌ها فعالش نکرده. یک نکته خیلی مهم هم میگه: «ما پروتکل STP رو روشن نکردیم، چون بهمون گفته بودن که می‌تونه باعث مشکلات دیگه‌ای بشه.» این تصمیم، همونطور که می‌بینیم، قراره براشون گرون تموم بشه.

    شروع فاجعه: اولین روز مدرسه

    داستان از اولین روز بازگشایی مدارس شروع میشه. همه چیز عادیه. بچه‌ها رمزهاشون رو فراموش کردن، بعضی کامپیوترها به خاطر نقاشی کلاس‌ها قطع شدن و تیم IT مشغول حل این مشکلات روزمره است. همه چیز خوب پیش میره تا اینکه… ناگهان، ۱۰ دقیقه قبل از ناهار، کل شبکه مدرسه قطع میشه!
    فکرش رو بکنید، دقیقا موقعی که صندوق‌های فروش غذای سلف مدرسه (که اونها هم به شبکه وصل بودن) بیشترین کار رو دارن. حتی سیستم تلفن مدرسه که برای مدیریت از راه دور به شبکه وصل بود هم از کار میفته (البته سیستم تلفن از نوع استاندارد بوده نه VOIP).
    دن یک صحنه عجیب رو توصیف می‌کنه: چراغ‌های تمام ۶۰ تا سوییچ شبکه، همگی با هم، با یک ریتم ثابت و یکنواخت در حال چشمک زدن بودن. این یکی از کلاسیک‌ترین علائم یک طوفان برادکست تمام‌عیاره. انگار که تمام دستگاه‌های شبکه داشتن با هم فریاد می‌زدن.

    تحقیقات کارآگاه «دن»

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

    اما چیزی که می‌بینه خیلی عجیب‌تره: به جای بسته‌های برادکست عادی، وایرشارک یک سیل عظیم از بسته‌های ICMPv6 رو نشون میده. این خیلی عجیبه، چون دن میگه: «ما فقط از IPv4 استفاده می‌کنیم…».

    • توضیح سریع: IPv4 و IPv6 دو نسخه از پروتکل اینترنت هستن. IPv4 از آدرس‌های ۳۲ بیتی (مثل 192.168.1.10) استفاده می‌کنه و IPv6 از آدرس‌های ۱۲۸ بیتی که خیلی طولانی‌تر و پیچیده‌ترن. بیشتر شبکه‌ها هنوز از IPv4 استفاده می‌کنن، اما سیستم‌عامل‌های جدید به طور پیش‌فرض IPv6 رو هم فعال دارن.

    دیدن این همه ترافیک IPv6 روی یک شبکه IPv4، دن رو به شک میندازه. آیا ممکنه این یک حمله DoS باشه؟ اون تا حالا از نزدیک یک حمله واقعی ندیده بود و این سناریو براش جدید بود.

    تلاش برای مهار طوفان

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

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

    راه‌حل نهایی: خاموشی بزرگ!

    تیم شبکه که حسابی کلافه شده بود، به یک احتمال دیگه فکر می‌کنه. اونها قبلا دیده بودن که بعد از قطع و وصل شدن برق، بعضی وقتا یکی دو تا از سوییچ‌هاشون قاطی می‌کنن و همین‌طور چراغ‌هاشون چشمک می‌زنه و با یک ری‌استارت ساده درست میشن. اما این بار مشکل در سطح کل شبکه بود و گزارش‌های UPS (منبع برق اضطراری) هم هیچ نوسان برقی رو نشون نمی‌داد.
    با این حال، به عنوان یک تیر در تاریکی، تصمیم می‌گیرن سوییچ‌های یک رک (که ۴-۵ تا سوییچ توش بود) رو ری‌استارت کنن. اما فایده‌ای نداشت. به محض اینکه سوییچ‌ها بالا اومدن، چشمک زدن هماهنگ چراغ‌ها دوباره شروع شد.

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

    یک پایان باز و دلهره‌آور

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

    فصل ششم: وقتی طوفان از دنیای مجازی میاد! (مشکلات در محیط‌های مجازی‌سازی)

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

    بیاید یک مورد واقعی دیگه رو بررسی کنیم که در فروم پشتیبانی سیسکو (Cisco Community) مطرح شده.

    صحنه جرم: یک دیتاسنتر پیشرفته

    محیط این داستان یک دیتاسنterه که از تجهیزات پیشرفته سیسکو به اسم UCS استفاده می‌کنه. اونها دو تا دستگاه اصلی به اسم Fabric-Interconnect 9296 دارن که مثل مغز متفکر شبکه برای سرورها عمل می‌کنن. روی سرورهای تیغه‌ای (Blade Servers) اونها، نرم‌افزار مجازی‌سازی ESXi نصبه و کلی ماشین مجازی روشون در حال اجراست.

    شروع مشکل: مقصر، یک ماشین مجازی بود!

    یک روز، شبکه این شرکت دچار مشکلات جدی میشه. بعد از دو ساعت عیب‌یابی و بررسی، تیم شبکه به یک نتیجه باورنکردنی می‌رسن: منبع کل مشکلات یک ماشین مجازی بوده که روی یکی از سرورهای ESXi نصب شده بود.
    این ماشین مجازی جوری پیکربندی شده بود که خودش مثل یک «سوییچ مجازی» عمل می‌کرد. یک تنظیم اشتباه یا یک باگ در این VM باعث شده بود که شروع به تولید و پخش حجم وحشتناکی از ترافیک برادکست در کل اون زیرشبکه (subnet) بکنه. این ترافیک اون‌قدر زیاد بود که کل شبکه رو مختل کرده بود.
    راه‌حل فوری چی بود؟ اونها به سادگی اون ماشین مجازی رو خاموش کردن (Power Off). به محض خاموش شدن VM، همه چیز به حالت عادی برگشت.

    سوال اصلی: چطور در آینده جلوی این اتفاق رو بگیریم؟

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

    پاسخ‌های یک متخصص به اسم «کرک» (Kirk) خیلی آموزنده است و به ما نشون میده که مدیریت شبکه در دنیای مجازی چالش‌های خاص خودش رو داره.

    توصیه‌های متخصص برای محیط‌های مجازی

    کرک چند تا نکته کلیدی رو توضیح میده:

    1. مکانیسم‌های داخلی UCSM کافی نیستن: کرک میگه که خود سیستم‌های UCSM/FI سیسکو به طور پیش‌فرض مکانیسم‌هایی برای جلوگیری از لوپ دارن، مثل deja vu check و RPF check. این سیستم‌ها جلوی ایجاد لوپ‌های ساختاری در شبکه رو می‌گیرن. اما، اگه یک ماشین مجازی خودش شروع به تولید سیل‌آسای ترافیک برادکست بکنه (که بهش میگن هاست یا میزبان بدرفتار – misbehaving host)، تجهیزات Fabric Interconnect تقصیری ندارن. وظیفه اونها اینه که فریم‌ها رو با حداکثر سرعت تحویل بدن. پس اگه یک VM شروع به فریاد زدن کنه، FI هم اون فریادها رو خیلی سریع و کارآمد در کل شبکه پخش می‌کنه!
    2. راه‌حل مستقیم وجود نداره: هیچ تنظیم مستقیمی روی کارت شبکه مجازی (vNIC) یک VM وجود نداره که بتونه جلوی ایجاد لوپ یا بریج (bridging) در سطح سیستم‌عامل اون VM رو بگیره. اگه شما داخل یک ویندوز سرور مجازی، دو تا کارت شبکه مجازی رو به هم بریج کنید، یک لوپ ایجاد کردید و تجهیزات بیرونی به سادگی نمی‌تونن جلوش رو بگیرن.
    3. بهترین راهکارها (Best Practices): به جای یک دکمه جادویی، باید روی طراحی درست و پیکربندی صحیح تمرکز کرد:
      1. محدود کردن VLANها: یکی از بهترین کارها اینه که روی کارت شبکه‌های مجازی، فقط و فقط VLANهایی رو مجاز کنید که اون ماشین مجازی واقعا بهشون احتیاج داره. کرک میگه خیلی از مشتری‌ها در ابتدای طراحی، چون دقیقا نمی‌دونن هر سرور به چه VLANهایی نیاز داره، همه VLANها رو روی پروفایل سرورها مجاز می‌کنن. این کار خیلی خطرناکه. چون اگه یک طوفان در یک VLAN اتفاق بیفته، این ترافیک به تمام سرورهایی که اون VLAN روشون مجازه ارسال میشه، حتی اگه بهش نیازی نداشته باشن. این کار سطح حمله و تاثیر طوفان رو به شدت افزایش میده. محدود کردن VLANها مثل اینه که به جای دادن شاه‌کلید ساختمون به هر کارمند، فقط کلید اتاق خودش رو بهش بدید.
      2. پیدا کردن منبع با وایرشارک: دوباره اسم وایرشارک به میون میاد. کرک تاکید می‌کنه که باید ترافیک رو ضبط و تحلیل کنید تا بفهمید دقیقا چه نوع ترافیکیه، آدرس MAC منبع دقیقش چیه، و در کدوم VLAN داره اتفاق میفته.
      3. مراقب تنظیمات پیچیده باشید: چیزهایی مثل تنظیمات اشتباه در الگوریتم‌های تیمینگ (teaming) سوییچ مجازی، پیکربندی نادرست شبکه‌های لایه ۲ مجزا (disjoint layer 2)، یا مشکلات در سوییچ‌های فیزیکی بالادستی، همگی می‌تونن باعث بشن یک ماشین مجازی نتونه آدرس MAC دستگاه دیگه‌ای رو پیدا کنه و در نتیجه به طور مداوم شروع به ارسال درخواست‌های ARP (که یک نوع برادکسته) بکنه و یک طوفان ARP راه بندازه.
    4. UCS برای سرعت ساخته شده، نه فیلترینگ: کرک یک نکته مهم دیگه رو هم میگه. تجهیزاتی مثل UCSM طوری طراحی شدن که مثل یک کامپیوتر میزبان (end host) رفتار کنن: حداکثر توان عملیاتی (throughput) و سوییچینگ سریع (cut-through switching). این دستگاه‌ها برای فیلتر کردن یا تحلیل عمیق بسته‌ها طراحی نشدن. قابلیت‌هایی مثل Storm Control معمولا روی سوییچ‌ها و روترهای دیگه پیدا میشه، نه روی این تجهیزات مرکزی. پس راه‌حل در طراحی صحیح شبکه است، نه در انتظار داشتن یک قابلیت خاص روی این دستگاه.

    فصل هفتم: یک داستان مجازی دیگر، طوفان ARP و NSX-T

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

    مشکل: طوفان ARP و فلج شدن روتر

    این کاربر میگه که شرکتشون با یک طوفان ARP مواجه شده. ARP یا (Address Resolution Protocol) پروتکلیه که کامپیوترها برای پیدا کردن آدرس فیزیکی (MAC Address) یکدیگر از روی آدرس منطقی (IP Address) استفاده می‌کنن. درخواست‌های ARP به صورت برادکست ارسال میشن.
    در این مورد، چندین ماشین مجازی با هم شروع به ارسال درخواست‌های ARP با نرخ بسیار بالا کردن. این سیل درخواست‌ها به روتر اصلی یا گیت‌وی بالادستی اونها میرسه و پردازنده روتر اون‌قدر درگیر میشه که شروع به انداختن بسته‌های ARP (dropping ARP) می‌کنه.

    این اتفاق یک اثر دومینویی وحشتناک داشت:

    • چون روتر دیگه نمی‌تونست به درخواست‌های ARP جواب بده، تمام VLANها تحت تاثیر قرار گرفتن. چرا؟ چون قابلیتی که روی روتر ترافیک رو کنترل می‌کرد (policer) برای یک VLAN خاص تنظیم نشده بود و کل ترافیک ARP رو محدود می‌کرد.
    • حتی روی پروتکل‌های مسیریابی داینامیک هم تاثیر گذاشت. وقتی دو تا روتر می‌خوان با هم اطلاعات مسیرها رو رد و بدل کنن، اول باید آدرس MAC همدیگه رو پیدا کنن. وقتی جدول ARP روتر به خاطر طوفان به هم می‌ریخت، این ارتباط هم مختل می‌شد.

    مظنون جدید: NSX-T

    این کاربر یک نکته خیلی جالب رو مطرح می‌کنه. اونها به تازگی در محیط مجازی‌شون از NSX-T (یک پلتفرم مجازی‌سازی شبکه از شرکت VMware) استفاده کرده بودن و ماشین‌های مجازی که این طوفان رو ایجاد کرده بودن، همگی روی پورت‌گروپ‌های NSX-T قرار داشتن.
    فرضیه اونها این بود که شاید یک باگ در NSX-T وجود داره. به نظر می‌رسید که ماشین‌های مجازی به دلایلی جواب ARP رو از گیت‌وی دریافت نمی‌کردن، و به خاطر همین به طور دیوانه‌واری و با یک نرخ خیلی تهاجمی (aggressive rate) به ارسال درخواست ARP ادامه می‌دادن تا بالاخره جواب بگیرن.

    راه‌حل‌های پیاده‌سازی شده

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

    1. فعال کردن Storm-Control: اونها روی سوییچ‌های فیزیکی‌شون قابلیت storm-control رو با پایین‌ترین حد ممکن فعال کردن. هرچند این حد هنوز از آستانه کنترلر ARP روی روتر اصلیشون (یک Nexus 7K) بالاتر بود، ولی تا حدی جلوی شدت طوفان رو می‌گرفت.
    2. طراحی یک Policer سفارشی: قدم بعدی و هوشمندانه‌تر اونها این بود که یک کنترلر ترافیک (policer) سفارشی روی روتر نکسوس خودشون بنویسن. این policer طوری طراحی میشه که به طور خاص، ترافیکی که از آدرس‌های MAC متعلق به محیط VMWare میاد رو با یک آستانه پایین‌تر محدود کنه. این یک راه‌حل هدفمند برای کنترل ترافیک از سمت محیط مجازی، بدون تاثیر گذاشتن روی بقیه قسمت‌های شبکه است.

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

    فصل هشتم: پرسش و پاسخ

    سوال ۱: پس طوفان برادکست یه جورایی مثل اسپم یا هرزنامه توی شبکه است، درسته؟

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

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

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

    • پیدا کردن آدرس‌ها (ARP): وقتی کامپیوتر شما می‌خواد با کامپیوتر دیگه‌ای توی همون شبکه حرف بزنه، فقط آدرس IP اون رو می‌دونه. اما برای ارسال واقعی داده روی کابل، به آدرس سخت‌افزاری یا MAC اون نیاز داره. پس یک پیام برادکست به کل شبکه می‌فرسته و می‌پرسه: «هی، کی آدرس IP فلان رو داره؟ لطفا آدرس MAC خودت رو به من بگو.»
    • گرفتن آدرس IP (DHCP): وقتی شما کامپیوترتون رو روشن می‌کنید و به شبکه وصل میشید، کامپیوتر شما هنوز آدرس IP نداره. پس یک پیام برادکست می‌فرسته و داد میزنه: «سلام، من جدیدم، آیا یک سرور DHCP اینجا هست که به من یک آدرس IP بده؟»

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

    سوال ۳: فرق اصلی بین یک طوفان اتفاقی (مثل کابل لوپ شده) و یک حمله DoS عمدی چیه؟ از نظر فنی چه تفاوتی دارن؟

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

    • منبع: در یک لوپ، ترافیک از خود شبکه نشات می‌گیره. یک بسته عادی وارد یک حلقه میشه و بی‌پایان تکرار میشه. در یک حمله DoS مثل اسمرف، ترافیک مخرب توسط یک مهاجم از «بیرون» شبکه تولید میشه و به سمت شبکه شما هدایت میشه.
    • هدف: در لوپ، هیچ هدف و نیت بدی وجود نداره. یک اشتباه انسانی یا سخت‌افزاریه. در حمله DoS، یک نیت مخرب برای از کار انداختن یک قربانی خاص وجود داره.
    • نوع ترافیک: در یک لوپ، معمولا یک یا چند نوع فریم برادکست عادی (مثل ARP یا DHCP) به طور مکرر کپی میشن. در حمله اسمرف، ترافیک به طور خاص از نوع ICMP Echo Request با آدرس جعلیه. در داستان مدرسه، دیدیم که اونها به یک حمله DoS شک کردن چون نوع ترافیک (ICMPv6) خیلی غیرعادی و مشکوک بود.
    • راه‌حل: برای حل مشکل لوپ، باید اون حلقه فیزیکی یا منطقی رو پیدا و حذف کنید (یا از پروتکلی مثل STP استفاده کنید). برای مقابله با حمله DoS، باید ترافیک مخرب رو روی روترها یا فایروال‌های لب مرز شبکه شناسایی و فیلتر کنید.

    سوال ۴: توی داستان مدرسه، چرا واقعا خاموش و روشن کردن ترتیبی سوییچ‌ها کار کرد؟ آیا این یعنی مشکل برای همیشه حل شد؟

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

    سوال ۵: آیا اینکه یک ماشین مجازی کل شبکه رو از کار بندازه یک چیز عادیه؟ چطور یک برنامه نرم‌افزاری می‌تونه همچین بلایی سر سخت‌افزار بیاره؟

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

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

    جواب: اگه قرار باشه فقط یک چیز بگم، اون اینه: «شبکه‌تون رو هوشمندانه تقسیم‌بندی کنید.»
    یک شبکه بزرگ و مسطح (Flat Network) که همه دستگاه‌ها توی یک دامنه برادکست بزرگ قرار دارن، مثل یک انبار باروت می‌مونه. یک جرقه کوچیک (یک لوپ یا یک دستگاه خراب) می‌تونه کل انبار رو منفجر کنه.
    اما اگه شما با استفاده از VLANها و روترها، این شبکه بزرگ رو به چندین جزیره کوچیک و ایزوله تقسیم کنید، تاثیر هر مشکلی به همون جزیره‌ای که توش اتفاق افتاده محدود میشه. این کار بهش میگن «تقسیم‌بندی شبکه» یا (Network Segmentation). این اصل، نه تنها جلوی گسترش طوفان برادکست رو می‌گیره، بلکه از نظر امنیتی هم فوق‌العاده مهمه، چون جلوی حرکت جانبی هکرها در شبکه رو هم می‌گیره.
    پس به جای داشتن یک سالن بزرگ و پرهمهمه، چندین اتاق کوچک و آرام داشته باشید. این بهترین و پایه‌ای‌ترین قدم برای ساختن یک شبکه پایدار و قابل اطمینانه. البته فعال کردن پروتکل‌هایی مثل STP هم در کنارش حیاتیه، اما تقسیم‌بندی درست، معماری شبکه شما رو از پایه محکم می‌کنه.

    منابع

    • [2] Solved: Prevent broadcast storm from VMs under FI – Cisco Community
    • [1] Broadcast storm – Wikipedia
    • [3] Possible Broadcast Storm or DoS? – Networking – Spiceworks Community

  • gRPC-Web چیست؟ ارتباط وب با سرویس‌های gRPC

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

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

    یک نکته مهم که باید بدونید اینه که gRPC-Web الان به مرحله «عرضه عمومی» یا همون «Generally Available» رسیده. این یعنی چی؟ یعنی دیگه یک پروژه آزمایشی و نصفه و نیمه نیست. کاملا پایداره و شرکت‌ها و برنامه‌نویس‌ها میتونن با خیال راحت در محصولات نهایی و تجاری خودشون ازش استفاده کنن.

    نکته کلیدی اینه که کلاینت‌های gRPC-Web نمیتونن مستقیم با سرویس‌های gRPC صحبت کنن. این وسط به یک واسطه یا یک جور مترجم نیاز دارن. این مترجم یک «پراکسی» یا «gateway» مخصوصه. به طور پیش‌فرض، کتابخانه gRPC-Web از پراکسی به اسم Envoy استفاده میکنه که پشتیبانی از gRPC-Web به صورت داخلی در اون تعبیه شده. پس روند کار اینطوری میشه: اپلیکیشن توی مرورگر شما درخواستش رو به زبان gRPC-Web به Envoy میفرسته، بعد Envoy اون درخواست رو ترجمه میکنه و به زبان gRPC اصلی به سرویس پشتیبان یا همون بک‌اند میفرسته. جواب رو هم به همین صورت برعکس ترجمه میکنه و به مرورگر برمیگردونه.

    نگران نباشید، در آینده قراره این وضعیت بهتر هم بشه. تیم توسعه‌دهنده gRPC-Web انتظار داره که پشتیبانی از این تکنولوژی مستقیما به فریمورک‌های تحت وب در زبان‌های مختلف مثل پایتون، جاوا و نود جی‌اس اضافه بشه. این یعنی شاید در آینده دیگه نیازی به اون پراکسی جداگانه نباشه. اگه دوست دارید بیشتر در مورد برنامه‌های آینده بدونید، میتونید سند نقشه راه یا «roadmap» این پروژه رو مطالعه کنید.

    چرا اصلا باید از gRPC و gRPC-Web استفاده کنیم؟

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

    تمام پیچیدگی‌های ارتباط بین این زبان‌ها و محیط‌های مختلف توسط خود gRPC مدیریت میشه و شما دیگه درگیر جزئیات نمیشید. علاوه بر این، شما از تمام مزایای کار با «پروتکل بافر» یا همون «Protocol Buffers» هم بهره‌مند میشید. این مزایا شامل سریال‌سازی بهینه (یعنی تبدیل داده‌ها به فرمتی فشرده و سریع برای انتقال)، یک زبان تعریف رابط کاربری ساده (IDL) و قابلیت به‌روزرسانی آسان رابط‌ها میشه.

    حالا gRPC-Web این وسط چه نقشی داره؟ gRPC-Web به شما این امکان رو میده که از داخل مرورگرها، با یک API کاملا طبیعی و آشنا برای برنامه‌نویس‌های وب، به همین سرویس‌های gRPC که ساختید دسترسی پیدا کنید.

    محدودیت‌های مرورگر و راه حل‌های موجود

    یک حقیقت مهم وجود داره که باید بدونیم: امکان فراخوانی مستقیم یک سرویس gRPC از مرورگر وجود نداره. چرا؟ چون gRPC از ویژگی‌های پروتکل HTTP/2 استفاده میکنه و هیچ مرورگری اون سطح از کنترل دقیق روی درخواست‌های وب رو که برای پشتیبانی از یک کلاینت gRPC لازمه، در اختیار ما قرار نمیده. مثلا ما نمیتونیم مرورگر رو مجبور کنیم حتما از HTTP/2 استفاده کنه و حتی اگه میتونستیم، به فریم‌های خام HTTP/2 در مرورگرها دسترسی نداریم.

    اینجا gRPC روی ASP.NET Core دو تا راه حل سازگار با مرورگر ارائه میده:

    • gRPC-Web
    • gRPC JSON transcoding

    آشنایی با gRPC-Web

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

    • این روش خیلی شبیه به gRPC معمولیه، اما یک پروتکل انتقال داده کمی متفاوت داره که باعث میشه با HTTP/1.1 و مرورگرها سازگار باشه.
    • برای استفاده از این روش، اپلیکیشن مرورگر باید یک کلاینت gRPC رو از روی همون فایل .proto که تعریف کردیم، تولید کنه.
    • این روش به اپلیکیشن‌های مرورگر اجازه میده از مزایای پیام‌های باینری که عملکرد بالا و مصرف شبکه کمی دارن، بهره‌مند بشن.

    خبر خوب اینه که دات نت (.NET) به صورت داخلی از gRPC-Web پشتیبانی میکنه.

    آشنایی با gRPC JSON transcoding

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

    • در این حالت، اپلیکیشن مرورگر نیازی به تولید کلاینت gRPC نداره و اصلا لازم نیست چیزی در مورد gRPC بدونه.
    • RESTful API‌ها به صورت خودکار از روی سرویس‌های gRPC ساخته میشن. این کار با اضافه کردن یک سری حاشیه‌نویسی یا «metadata» مربوط به HTTP به فایل .proto انجام میشه.
    • این روش به یک اپلیکیشن اجازه میده که هم از gRPC و هم از JSON web API‌ها پشتیبانی کنه، بدون اینکه لازم باشه برای هر کدوم سرویس‌های جداگانه‌ای بسازه و کار تکراری انجام بده.

    دات نت همچنین از ساخت JSON web API از روی سرویس‌های gRPC هم پشتیبانی داخلی داره. فقط یادتون باشه که برای استفاده از gRPC JSON transcoding به دات نت ۷ یا بالاتر نیاز دارید.

    یک آموزش پایه‌ای: بیایید دست به کار بشیم

    خب، تئوری کافیه. بیایید با یک مثال عملی ببینیم چطور میشه از gRPC-Web استفاده کرد. در این آموزش یاد میگیریم که:

    • چطور یک سرویس رو در یک فایل .proto تعریف کنیم.
    • چطور با استفاده از کامپایلر پروتکل بافر، کد کلاینت رو تولید کنیم.
    • چطور از API ی gRPC-Web برای نوشتن یک کلاینت ساده برای سرویسمون استفاده کنیم.

    فرض ما اینه که شما یک آشنایی اولیه با پروتکل بافرها دارید.

    مرحله ۱: تعریف سرویس در فایل echo.proto

    اولین قدم در ساخت یک سرویس gRPC، تعریف متدهای سرویس و انواع پیام‌های درخواست و پاسخ اونها با استفاده از پروتکل بافرهاست. در این مثال، ما یک سرویس به نام EchoService رو در فایلی به اسم echo.proto تعریف میکنیم. این فایل مثل یک نقشه اولیه برای ارتباط ما عمل میکنه.

    message EchoRequest {
  string message = 1;
}

message EchoResponse {
  string message = 1;
}

service EchoService {
  rpc Echo(EchoRequest) returns (EchoResponse);
}

    این تعریف خیلی ساده است. ما یک درخواست به نام EchoRequest داریم که یک پیام متنی میگیره. یک پاسخ به نام EchoResponse داریم که اون هم یک پیام متنی برمیگردونه. و یک سرویس به نام EchoService داریم که یک متد به نام Echo داره. این متد یک EchoRequest میگیره و یک EchoResponse برمیگردونه. کارش اینه که هر پیامی بهش بدی، همون رو بهت برگردونه. مثل یک اکو یا پژواک صدا.

    مرحله ۲: پیاده‌سازی سرور بک‌اند gRPC

    حالا که نقشه رو داریم، باید سرور رو بسازیم. در مرحله بعد، ما رابط EchoService رو با استفاده از Node.js در بک‌اند پیاده‌سازی میکنیم. این سرور که اسمش رو EchoServer میذاریم، درخواست‌های کلاینت‌ها رو مدیریت میکنه. برای دیدن جزئیات کامل کد، میتونید به فایل node-server/server.js در مثال‌های رسمی gRPC-Web مراجعه کنید.

    یک نکته مهم اینه که شما میتونید سرور رو با هر زبانی که gRPC ازش پشتیبانی میکنه پیاده‌سازی کنید. این یکی از قدرت‌های gRPC هست.

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

    function doEcho(call, callback) {
  callback(null, {message: call.request.message});
}

    همونطور که میبینید، این تابع خیلی ساده است. یک درخواست (call) میگیره، پیام داخلش رو برمیداره و در یک پیام جدید به عنوان پاسخ (callback) برمیگردونه.

    مرحله ۳: پیکربندی پراکسی Envoy

    همونطور که قبلا گفتیم، برای اینکه درخواست مرورگر به سرور بک‌اند ما برسه، به یک مترجم یا پراکسی نیاز داریم. در این مثال، ما از پراکسی Envoy استفاده میکنیم. فایل پیکربندی کامل Envoy رو میتونید در envoy.yaml ببینید.

    برای اینکه Envoy درخواست‌های gRPC رو به سرور بک‌اند ما فوروارد کنه، به یک بلوک تنظیمات شبیه به این نیاز داریم:

    admin:
  address:
    socket_address: { address: 0.0.0.0, port_value: 9901 }
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 0.0.0.0, port_value: 8080 }
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          codec_type: auto
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route: { cluster: echo_service }
          http_filters:
          - name: envoy.grpc_web
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_web.v3.GrpcWeb
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  clusters:
  - name: echo_service
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    typed_extension_protocol_options:
      envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
        "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
        explicit_http_config:
          http2_protocol_options: {}
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: echo_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: node-server
                port_value: 9090

    این تنظیمات شاید در نگاه اول پیچیده به نظر بیاد، ولی بیایید با هم بررسیش کنیم:

    • listeners: این بخش تعریف میکنه که Envoy روی چه آدرس و پورتی منتظر درخواست‌های ورودی باشه. اینجا روی پورت 8080 منتظر میمونه.
    • http_filters: اینجاست که جادو اتفاق میفته. ما دو تا فیلتر مهم داریم. یکی envoy.grpc_web که درخواست‌های gRPC-Web رو میشناسه و پردازش میکنه. دومی envoy.filters.http.router هست که درخواست رو به مقصد مناسبش هدایت میکنه.
    • clusters: این بخش تعریف میکنه که سرور بک‌اند ما کجاست. ما یک کلاستر به اسم echo_service تعریف کردیم که به آدرس node-server و پورت 9090 اشاره میکنه.

    پس سناریو اینطوریه: مرورگر یک درخواست gRPC-Web به پورت 8080 میفرستسه. Envoy این درخواست رو دریافت میکنه، با استفاده از فیلتر grpc_web اون رو ترجمه میکنه و به سرور gRPC بک‌اند ما که روی پورت 9090 قرار داره، ارسال میکنه. پاسخ سرور رو هم به همین ترتیب برعکس ترجمه میکنه و برای مرورگر میفرسته.

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

    مرحله ۴: تولید پیام‌های پروتوباف و کلاینت سرویس

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

    protoc -I=$DIR echo.proto \
--js_out=import_style=commonjs:$OUT_DIR
    • protoc: این همون کامپایلر پروتکل بافر هست.
    • -I=$DIR: به کامپایلر میگه فایل‌های .proto رو کجا پیدا کنه.
    • --js_out=import_style=commonjs:$OUT_DIR: این قسمت میگه که خروجی جاوااسکریپت بساز. import_style=commonjs باعث میشه که فایل‌های تولید شده از سیستم ماژول require() ی CommonJS استفاده کنن که در دنیای Node.js خیلی رایجه. $OUT_DIR هم پوشه خروجی رو مشخص میکنه.

    خب، این فقط کلاس‌های مربوط به پیام‌ها رو ساخت. ما به کدهای مربوط به کلاینت سرویس هم نیاز داریم. برای این کار، به یک پلاگین مخصوص برای protoc به اسم protoc-gen-grpc-web نیاز داریم.

    اول باید این پلاگین رو دانلود و نصب کنید. میتونید فایل باینری protoc رو از صفحه رسمی پروتکل بافر و پلاگین protoc-gen-grpc-web رو از صفحه گیت‌هاب gRPC-Web دانلود کنید. بعد باید مطمئن بشید که هر دوی این فایل‌ها اجرایی هستن و در PATH سیستم شما قرار دارن تا از هر جایی قابل دسترس باشن.

    یک راه دیگه برای نصب پلاگین اینه که از سورس کد کامپایلش کنید. برای این کار باید از ریشه مخزن gRPC-Web دستور زیر رو اجرا کنید:

    cd grpc-web
sudo make install-plugin

    بعد از اینکه پلاگین آماده شد، با دستور زیر میتونیم کد کلاینت سرویس رو تولید کنیم:

    protoc -I=$DIR echo.proto \
--grpc-web_out=import_style=commonjs,mode=grpcwebtext:$OUT_DIR

    این دستور خیلی شبیه دستور قبلیه، ولی از --grpc-web_out استفاده میکنه که مخصوص پلاگین ماست. بیایید پارامترهاش رو بررسی کنیم:

    • mode: این پارامتر میتونه grpcwebtext (که پیش‌فرض هست) یا grpcweb باشه. این دو حالت در نحوه کدگذاری داده‌ها تفاوت دارن که بعدا بیشتر در موردش صحبت میکنیم.
    • import_style: این پارامتر هم میتونه closure (که پیش‌فرض هست) یا commonjs باشه. ما از commonjs استفاده کردیم تا با خروجی قبلیمون هماهنگ باشه.

    این دستور به طور پیش‌فرض یک فایل به نام echo_grpc_web_pb.js تولید میکنه که شامل کد کلاینت ماست.

    مرحله ۵: نوشتن کد کلاینت جاوااسکریپت

    بالاخره رسیدیم به قسمت شیرین ماجرا. حالا آماده‌ایم که کد جاوااسکریپت سمت کلاینت رو بنویسیم. این کد رو در یک فایلی به نام client.js قرار میدیم.

    const {EchoRequest, EchoResponse} = require('./echo_pb.js');
const {EchoServiceClient} = require('./echo_grpc_web_pb.js');

var echoService = new EchoServiceClient('http://localhost:8080');

var request = new EchoRequest();
request.setMessage('Hello World!');

echoService.echo(request, {}, function(err, response) {
  // اینجا میتونیم با پاسخ سرور کار کنیم
  // مثلا response.getMessage() رو چاپ کنیم
});

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

    1. در دو خط اول، ما کلاس‌هایی که در مرحله قبل تولید کردیم (EchoRequest, EchoResponse, EchoServiceClient) رو با استفاده از require وارد برنامه‌مون میکنیم.
    2. بعد یک نمونه جدید از EchoServiceClient میسازیم و آدرس پراکسی Envoy خودمون (http://localhost:8080) رو بهش میدیم.
    3. یک نمونه جدید از EchoRequest میسازیم و پیام «Hello World!» رو داخلش قرار میدیم.
    4. در نهایت، متد echo رو روی سرویسمون فراخوانی میکنیم. به عنوان ورودی، درخواست (request)، یک آبجکت خالی برای متادیتا ({}) و یک تابع callback بهش میدیم. این تابع زمانی اجرا میشه که پاسخی از سرور دریافت بشه. این پاسخ میتونه خطا (err) یا جواب موفقیت‌آمیز (response) باشه.

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

    {
  "name": "grpc-web-commonjs-example",
  "dependencies": {
    "google-protobuf": "^3.6.1",
    "grpc-web": "^0.4.0"
  },
  "devDependencies": {
    "browserify": "^16.2.2",
    "webpack": "^4.16.5",
    "webpack-cli": "^3.1.0"
  }
}

    این فایل مشخص میکنه که پروژه ما به پکیج‌های google-protobuf و grpc-web نیاز داره. همچنین برای ساختن فایل نهایی برای مرورگر، از ابزارهایی مثل browserify یا webpack استفاده میکنیم.

    مرحله ۶: کامپایل کتابخانه جاوااسکریپت

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

    اول با دستور npm install پکیج‌های مورد نیاز رو نصب میکنیم.

    بعد با دستوری مثل این، فایل نهایی رو میسازیم:

    npx webpack client.js

    این دستور فایل client.js ما و تمام وابستگی‌هاش رو در یک فایل به نام main.js در پوشه dist قرار میده. حالا کافیه این فایل dist/main.js رو در صفحه HTML خودمون قرار بدیم و نتیجه رو ببینیم!

    یک راه سریع برای شروع

    اگر حوصله انجام تمام این مراحل رو به صورت دستی ندارید، یک راه سریع‌تر هم وجود داره. میتونید از مثال‌های آماده خود gRPC-Web استفاده کنید:

    $ git clone https://github.com/grpc/grpc-web
$ cd grpc-web
$ docker-compose up node-server envoy commonjs-client

    این دستورات با استفاده از داکر، همه چیز رو براتون آماده میکنه: سرور نود جی‌اس، پراکسی Envoy و یک کلاینت نمونه. بعد کافیه مرورگر خودتون رو باز کنید و به آدرس http://localhost:8081/echotest.html برید تا همه چیز رو در عمل ببینید.

    نگاهی عمیق‌تر به ویژگی‌ها و گزینه‌ها

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

    انواع RPC و پشتیبانی در gRPC-Web

    gRPC در حالت کلی چهار نوع متد یا RPC رو پشتیبانی میکنه:

    1. Unary RPCs: یک درخواست میفرستی و یک پاسخ میگیری. مثل همین مثال Echo ما.
    2. Server-side Streaming RPCs: یک درخواست میفرستی و یک جریان از پاسخ‌ها رو به صورت پشت سر هم دریافت میکنی.
    3. Client-side Streaming RPCs: یک جریان از درخواست‌ها رو میفرستی و در نهایت یک پاسخ میگیری.
    4. Bi-directional Streaming RPCs: یک جریان دوطرفه از درخواست‌ها و پاسخ‌ها به صورت همزمان داری.

    gRPC-Web در حال حاضر فقط از دو نوع اول پشتیبانی میکنه. یعنی Unary RPC و Server-side Streaming RPC. استریمینگ سمت کلاینت و دوطرفه فعلا پشتیبانی نمیشن. البته برای استریمینگ سمت سرور هم یک شرط وجود داره: باید حتما از حالت grpcwebtext استفاده کنید.

    حالت‌های مختلف انتقال داده (mode)

    وقتی داشتیم کد کلاینت رو تولید میکردیم، یک پارامتر به اسم mode دیدیم. این پارامتر دو تا مقدار میتونه داشته باشه:

    • mode=grpcwebtext: این حالت پیش‌فرض هست.
      • Content-type درخواست میشه application/grpc-web-text.
      • داده‌ها یا همون payload به صورت base64 کدگذاری میشن. این یعنی داده‌های باینری به فرمت متنی تبدیل میشن.
      • هم از Unary و هم از Server-side streaming پشتیبانی میکنه.
    • mode=grpcweb: این حالت از فرمت باینری پروتوباف استفاده میکنه.
      • Content-type درخواست میشه application/grpc-web+proto.
      • داده‌ها به صورت باینری و خام پروتوباف فرستاده میشن. این حالت معمولا بهینه‌تر و کم‌حجم‌تره.
      • فقط از Unary call پشتیبانی میکنه. استریمینگ سمت سرور در این حالت کار نمیکنه.

    استایل‌های مختلف ایمپورت (import_style)

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

    • import_style=closure: این حالت پیش‌فرض هست و از سیستم ماژول goog.require() کتابخانه Closure گوگل استفاده میکنه.
    • import_style=commonjs: این حالت از require() ی CommonJS استفاده میکنه که برای کار با ابزارهایی مثل Webpack و Browserify خیلی مناسبه.
    • import_style=commonjs+dts: (آزمایشی) این حالت علاوه بر کد CommonJS، یک فایل تایپینگ .d.ts هم برای پیام‌های پروتوباف و کلاینت سرویس تولید میکنه. این برای کار با TypeScript خیلی مفیده.
    • import_style=typescript: (آزمایشی) این حالت مستقیما کد کلاینت سرویس رو به زبان TypeScript تولید میکنه.

    پشتیبانی از TypeScript

    خبر خوب برای طرفدارهای TypeScript اینه که gRPC-Web به صورت آزمایشی از این زبان پشتیبانی میکنه. حالا ماژول grpc-web رو میشه به عنوان یک ماژول TypeScript وارد کرد.

    برای استفاده از این قابلیت، باید موقع تولید کد از پلاگین protoc-gen-grpc-web، یکی از این دو گزینه رو بهش بدید:

    • import_style=commonjs+dts: کد CommonJS به همراه فایل‌های تایپینگ .d.ts تولید میکنه.
    • import_style=typescript: کد کاملا TypeScript تولید میکنه.

    یک نکته خیلی مهم: شما نباید import_style=typescript رو برای فلگ --js_out استفاده کنید. این فلگ فقط باید روی import_style=commonjs تنظیم بشه. در واقع --js_out کد جاوااسکریپت پیام‌ها (echo_pb.js) رو تولید میکنه و --grpc-web_out فایل‌های TypeScript مربوط به سرویس (EchoServiceClientPb.ts) و تایپینگ پیام‌ها (echo_pb.d.ts) رو میسازه. این یک راه حل موقتیه تا زمانی که خود --js_out به صورت کامل از TypeScript پشتیبانی کنه.

    پس دستور کامل برای تولید کد TypeScript با فرمت باینری این شکلی میشه:

    protoc -I=$DIR echo.proto \
--js_out=import_style=commonjs,binary:$OUT_DIR \
--grpc-web_out=import_style=typescript,mode=grpcweb:$OUT_DIR

    و کد سمت کلاینت در TypeScript میتونه این شکلی باشه:

    import * as grpcWeb from 'grpc-web';
import {EchoServiceClient} from './EchoServiceClientPb';
import {EchoRequest, EchoResponse} from './echo_pb';

const echoService = new EchoServiceClient('http://localhost:8080', null, null);

const request = new EchoRequest();
request.setMessage('Hello World!');

const call = echoService.echo(request, {'custom-header-1': 'value1'},
  (err: grpcWeb.RpcError, response: EchoResponse) => {
    if (err) {
      console.log(`Received error: ${err.code}, ${err.message}`);
    } else {
      console.log(response.getMessage());
    }
  });

call.on('status', (status: grpcWeb.Status) => {
  // ...
});

    همونطور که میبینید، همه چیز تایپ-سیف و مشخصه.

    کلاینت مبتنی بر Promise

    علاوه بر مدل callback که دیدیم، میتونید از یک کلاینت مبتنی بر Promise هم استفاده کنید. این مدل کدنویسی برای خیلی‌ها خواناتر و مدرن‌تره.

    // Create a Promise client instead
const echoService = new EchoServicePromiseClient('http://localhost:8080', null, null);

// ... (request is the same as above)

echoService.echo(request, {'custom--header-1': 'value1'})
  .then((response: EchoResponse) => {
    console.log(`Received response: ${response.getMessage()}`);
  }).catch((err: grpcWeb.RpcError) => {
    console.log(`Received error: ${err.code}, ${err.message}`);
  });

    فقط یک نکته مهم رو در نظر داشته باشید: وقتی از Promise استفاده میکنید، دیگه نمیتونید به callback‌های .on(...) (مثلا برای metadata و status) دسترسی داشته باشید.

    تاریخچه و وضعیت فعلی gRPC در مرورگر

    جالبه بدونید که داستان gRPC در مرورگر چطور شروع شد. در تابستان ۲۰۱۶، یک تیم در گوگل و یک شرکت به نام Improbable به صورت مستقل از هم شروع به کار روی چیزی کردن که میشد اسمش رو گذاشت «gRPC برای مرورگر». خیلی زود از وجود هم باخبر شدن و با هم همکاری کردن تا یک مشخصات فنی یا «spec» برای این پروتکل جدید تعریف کنن.

    مشخصات فنی gRPC-Web

    همونطور که گفتیم، پیاده‌سازی کامل مشخصات gRPC مبتنی بر HTTP/2 در مرورگرها غیرممکنه. به خاطر همین، مشخصات gRPC-Web با در نظر گرفتن این محدودیت‌ها و با تعریف تفاوت‌هاش با gRPC اصلی نوشته شد. این تفاوت‌های کلیدی عبارتند از:

    • پشتیبانی از هر دو پروتکل HTTP/1.1 و HTTP/2.
    • ارسال هدرهای تریلر gRPC در انتهای بدنه درخواست/پاسخ.
    • الزامی بودن استفاده از یک پراکسی برای ترجمه بین درخواست‌های gRPC-Web و پاسخ‌های gRPC HTTP/2.

    دو پیاده‌سازی اصلی

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

    • کلاینت Improbable:
      • با زبان TypeScript نوشته شده.
      • در npm با نام @improbable-eng/grpc-web موجوده.
      • یک پراکسی به زبان Go هم داره که هم به صورت پکیج و هم به صورت یک برنامه مستقل قابل استفاده است.
      • از هر دو Fetch و XHR برای ارسال درخواست‌ها استفاده میکنه و به صورت خودکار بر اساس قابلیت‌های مرورگر یکی رو انتخاب میکنه.
    • کلاینت Google:
      • با زبان جاوااسکریپت و با استفاده از کتابخانه Google Closure نوشته شده.
      • در npm با نام grpc-web موجوده.
      • در ابتدا با یک افزونه برای NGINX به عنوان پراکسی عرضه شد، ولی بعدا روی فیلتر HTTP پراکسی Envoy تمرکز کرد.
      • فقط از XHR برای ارسال درخواست‌ها استفاده میکنه.

    بیایید این دو رو در یک جدول با هم مقایسه کنیم:

    کلاینت / ویژگیروش انتقالUnaryاستریم سمت سروراستریم سمت کلاینت و دوطرفه
    ImprobableFetch/XHR✔️✔️❌ (با یک روش آزمایشی وب‌سوکت)
    Google (grpcwebtext)XHR✔️✔️❌
    Google (grpcweb)XHR✔️❌ (فقط در انتها نتیجه رو برمیگردونه)❌

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

    آینده و مسیر پیش رو

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

    • یک فرمت کدگذاری پیام‌ها شبیه JSON ولی بهینه‌تر.
    • پراکسی‌های درون-فرایندی برای Node، پایتون، جاوا و غیره (تا نیاز به پراکسی جدا مثل Envoy کمتر بشه).
    • ادغام با فریمورک‌های محبوب مثل React، Angular و Vue.
    • استفاده از Fetch API برای استریمینگ بهینه‌تر از نظر حافظه.
    • پشتیبانی از استریمینگ دوطرفه.

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

    پس اگه امروز میخواید با gRPC-Web شروع کنید، بهترین گزینه کلاینت گوگل هست. این کلاینت تضمین‌های سازگاری API قوی‌ای داره و توسط یک تیم اختصاصی پشتیبانی میشه.

    مزایای استفاده از gRPC-Web

    حالا که با جزئیات فنی آشنا شدیم، بیایید یک بار دیگه مزایای معماری gRPC-Web رو مرور کنیم.

    • gRPC سرتاسری (End-to-end gRPC): به شما اجازه میده کل خط لوله RPC خودتون رو با استفاده از پروتکل بافرها طراحی کنید. دیگه لازم نیست یک لایه اضافه برای تبدیل درخواست‌های HTTP/JSON به gRPC در بک‌اند داشته باشید.
    • هماهنگی بیشتر بین تیم‌های فرانت‌اند و بک‌اند: وقتی کل ارتباط با پروتکل بافر تعریف میشه، دیگه مرز بین تیم «کلاینت» و تیم‌های «میکروسرویس‌ها» کمرنگ‌تر میشه. ارتباط کلاینت-بک‌اند فقط یک لایه gRPC دیگه در کنار بقیه لایه‌هاست.
    • تولید آسان کتابخانه‌های کلاینت: وقتی سروری که با دنیای بیرون در ارتباطه، یک سرور gRPC باشه، تولید کتابخانه‌های کلاینت برای زبان‌های مختلف (روبی، پایتون، جاوا و …) خیلی راحت‌تر میشه و دیگه نیازی به نوشتن کلاینت‌های HTTP جداگانه برای هر کدوم نیست.

    دیدگاه دنیای واقعی: gRPC-Web در مقابل REST

    جالبه بدونید که همیشه همه با یک تکنولوژی موافق نیستن. در یک بحث در وبسایت ردیت، یک مهندس ارشد پیشنهاد کرده بود که تیمشون از gRPC-Web به سمت استفاده از REST Handler‌های معمولی حرکت کنه. دلیل این پیشنهاد این بود که در یک استارتاپ که سرعت توسعه و رسیدن به بازار اولویت داره، این کار میتونه مفید باشه.

    نگرانی‌هایی که در مورد این تغییر مطرح شده بود اینها بودن:

    • از دست دادن یک تعریف نوع (type definition) یکپارچه که پروتوباف فراهم میکنه.
    • نیاز به ابداع مجدد چرخ و نوشتن کدهای تکراری.
    • نیاز به ارتباط و مستندسازی بیشتر بین تیم‌ها.

    در مقابل، تنها مزیت مسیر HTTP/REST این عنوان شده بود که درک و فهم اون برای بعضی‌ها ساده‌تره. این بحث نشون میده که انتخاب بین این تکنولوژی‌ها همیشه یک سری بده‌بستان (trade-off) داره و به شرایط پروژه بستگی داره. هر دو روش، چه استفاده از پروتوباف برای تولید کلاینت gRPC-Web و چه استفاده از OpenAPI برای تولید کلاینت REST، در سطح بالا یک هدف مشترک دارن: تولید خودکار کلاینت از روی یک تعریف مشخص.

    پرسش و پاسخ

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

    1. سوال ۱: gRPC دقیقا چیه؟

    جواب: gRPC یک چارچوب RPC (Remote Procedure Call) مدرن، متن‌باز و با کارایی بالاست که توسط گوگل ساخته شده. به زبان ساده، یک روش خیلی سریع و بهینه برای اینه که سرویس‌های مختلف در یک سیستم کامپیوتری بتونن با هم صحبت کنن و از هم سرویس بگیرن، حتی اگه در کامپیوترهای مختلف و با زبان‌های برنامه‌نویسی متفاوتی نوشته شده باشن. این چارچوب از پروتکل HTTP/2 برای انتقال داده استفاده میکنه.

    1. سوال ۲: چرا نمیتونیم مستقیم از gRPC توی مرورگر استفاده کنیم و به gRPC-Web نیاز داریم؟

    جواب: چون gRPC روی ویژگی‌های سطح پایین پروتکل HTTP/2 ساخته شده. مرورگرهای وب امروزی به برنامه‌نویس‌ها اجازه دسترسی و کنترل مستقیم روی این ویژگی‌ها رو نمیدن. برای همین، یک «پل» یا «مترجم» به اسم gRPC-Web ساخته شده که یک پروتکل کمی متفاوت و سازگار با محدودیت‌های مرورگر داره. این پروتکل بعدا توسط یک پراکسی (مثل Envoy) به gRPC استاندارد ترجمه میشه.

    1. سوال ۳: فایل .proto چیه و چه نقشی داره؟

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

    1. سوال ۴: پراکسی Envoy چیه و چرا در معماری gRPC-Web مهمه؟

    جواب: Envoy یک پراکسی سرویس مدرن و با کارایی بالاست. در دنیای gRPC-Web، نقش یک مترجم رو بازی میکنه. درخواست‌هایی که از مرورگر با پروتکل gRPC-Web میان رو دریافت میکنه، اونها رو به پروتکل استاندارد gRPC (که روی HTTP/2 کار میکنه) تبدیل میکنه و به سرور بک‌اند میفرسته. پاسخ سرور رو هم به همین ترتیب برعکس ترجمه میکنه و برای مرورگر میفرسته. بدون وجود یک پراکسی مثل Envoy، ارتباط مستقیم بین مرورگر و سرور gRPC ممکن نیست. البته پراکسی‌های دیگه‌ای مثل پراکسی Go، Apache APISIX و Nginx هم این قابلیت رو دارن.

    1. سوال ۵: تفاوت اصلی بین دو حالت mode=grpcwebtext و mode=grpcweb چیه؟

    جواب: تفاوت اصلی در نحوه کدگذاری و انتقال داده‌هاست.

    • grpcwebtext داده‌ها رو به صورت متنی (Base64) کدگذاری میکنه و هم از درخواست‌های تکی (Unary) و هم از استریمینگ سمت سرور پشتیبانی میکنه.
    • grpcweb داده‌ها رو به صورت باینری و خام پروتوباف منتقل میکنه که بهینه‌تره، ولی فقط از درخواست‌های تکی (Unary) پشتیبانی میکنه.
    1. سوال ۶: آیا میتونم از gRPC-Web برای آپلود فایل یا چت دوطرفه استفاده کنم؟

    جواب: در حال حاضر، خیر. gRPC-Web از استریمینگ سمت کلاینت و استریمینگ دوطرفه پشتیبانی نمیکنه. این قابلیت‌ها در نقشه راه پروژه قرار دارن ولی هنوز پیاده‌سازی نشدن. پس برای کارهایی مثل آپلود فایل (که نیاز به استریم سمت کلاینت داره) یا یک اپلیکیشن چت زنده (که نیاز به استریم دوطرفه داره)، gRPC-Web فعلا راه حل کاملی نیست.

    منابع

    • [2] What Are gRPC & gRPC Web. Basics of Hacking Into gRPC-Web | by Amin Nasiri | Medium
    • [4] The state of gRPC in the browser | gRPC
    • [6] GitHub – grpc/grpc-web: gRPC for Web Clients
    • [8] My backfill Principal Engineer wants to move off of GRPC web and start using REST Handlers. Will this be a shit show? : r/golang
    • [10] gRPC vs. gRPC-Web: Key Differences Explained
    • [1] grpc-web – npm
    • [3] Use gRPC in browser apps | Microsoft Learn
    • [5] Go and gRPC is just so intuitive. Here’s a detailed full-stack flow with gRPC-Web, Go and React. Also, there is a medium story focused on explaining how such a setup might boost efficiency and the step-by-step implementation. : r/golang
    • [7] gRPC-Web is Generally Available | gRPC
    • [9] Basics tutorial | Web | gRPC

  • بلوتوث کم‌مصرف (BLE)؛ راهنمای تکنولوژی اینترنت اشیا

    تکنولوژی BLE که اولین بار سال ۲۰۱۲ معرفی شد، یک پروتکل خیلی انعطاف‌پذیره که برای خیلی از کاربردهای مهم اینترنت اشیا، ارتباط بی‌سیم فراهم میکنه. تمرکز اصلیش روی کار کردن با مصرف انرژی فوق‌العاده پایینه و همین باعث شده تو صنایع مختلفی مثل لوازم الکترونیکی مصرفی، بهداشت و درمان و حتی لجستیک و انبارداری ازش استفاده بشه. امروز میخوایم تمام نکات پایه‌ای BLE رو با هم یاد بگیریم تا شما هم بتونید برای پروژه‌های بعدیتون ازش استفاده کنید و سهمی از این بازار بزرگ ۳۸۴ میلیارد دلاری اینترنت اشیا داشته باشید.

    داستان بلوتوث از کجا شروع شد؟

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

    بلوتوث یک تکنولوژی بی‌سیم با برد کوتاهه که تو باند فرکانسی ۲.۴ گیگاهرتز ISM کار میکنه. این باند فرکانسی برای استفاده عموم آزاده و نیازی به مجوز نداره. کارش هم انتقال داده و ساختن شبکه‌های شخصی کوچیک (PAN) هست.

    احتمالا همین الان دور و بر همه‌مون کلی دستگاه بلوتوثی هست: گوشی موبایل، لپ‌تاپ، هدفون و اسپیکر. جالبه بدونید که فقط تو سال ۲۰۲۱، بیشتر از ۴.۷ میلیارد دستگاه بلوتوثی تو کل دنیا تولید و عرضه شده. این نشون میده که بلوتوث یکی از پرکاربردترین تکنولوژی‌های دنیاست.

    اگه از مردم تو خیابون بپرسید بلوتوث چیه، اکثرشون یه شناخت کلی ازش دارن. اما پشت پرده، این یک استاندارد فنی نسبتا پیچیده‌ است که توسط یک گروه به اسم گروه علایق ویژه بلوتوث (Bluetooth Special Interest Group) یا به اختصار SIG مدیریت میشه. این گروه در طول سال‌ها، نسخه‌های مختلفی از مشخصات فنی بلوتوث رو منتشر کرده. دو تا از معروف‌ترین پروتکل‌های این استاندارد، «بلوتوث کلاسیک» و «بلوتوث کم‌مصرف» هستن.

    تا سال ۲۰۱۰، تمرکز اصلی روی بهتر کردن بلوتوث کلاسیک بود. اما تو همین سال، گروه SIG نسخه ۴.۰ بلوتوث رو منتشر کرد. این نسخه یک مسیر متفاوت رو در پیش گرفت و یک پروتکل جدید به اسم بلوتوث کم‌مصرف (BLE) رو به دنیا معرفی کرد.

    بلوتوث کم‌مصرف (BLE) دقیقا چیه؟

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

    ارتباط داده با رادیوی LE (که مخفف Low Energy هست) در بسته‌های کوچیک و کوتاه اتفاق میفته که لازم نیست خیلی پشت سر هم باشن. یک سناریوی معمولی برای BLE این شکلیه: دستگاه رادیوش رو برای مدت کوتاهی روشن میکنه، چند بایت یا چند کیلوبایت داده رو منتقل یا دریافت میکنه، و بعد دوباره رادیو رو خاموش میکنه و به حالت خواب (Sleep Mode) برمیگرده.

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

    مقایسه بلوتوث کلاسیک و بلوتوث کم‌مصرف (BLE)

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

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

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

    ویژگیبلوتوث کلاسیک (Classic Bluetooth)بلوتوث کم‌مصرف (BLE)
    هدف اصلیانتقال مداوم داده (مثل صدا)انتقال بسته‌های کوچک داده به صورت دوره‌ای
    مصرف انرژیبالابسیار پایین (تا ۱۰۰ برابر کمتر از کلاسیک)
    سرعت انتقال دادهبالاترپایین‌تر
    کاربرد اصلیهدفون، اسپیکر، انتقال فایلسنسورها، گجت‌های پوشیدنی، دستگاه‌های پزشکی
    حالت کاریهمیشه متصل و فعالبیشتر اوقات در حالت خواب، برای مدت کوتاه فعال

    چرا BLE اینقدر خوبه؟ (مزیت‌ها)

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

    • مصرف انرژی پایین: حتی وقتی با بقیه تکنولوژی‌های کم‌مصرف مقایسه‌اش میکنیم، BLE باز هم بهینه و کم‌مصرفه. راز این مصرف کم اینه که رادیوی دستگاه تا جای ممکن خاموش میمونه و فقط برای فرستادن مقدار کمی داده با سرعت پایین برای مدت کوتاهی روشن میشه.
    • هزینه پایین برای شروع توسعه: ماژول‌ها و چیپست‌های BLE در مقایسه با تکنولوژی‌های مشابه، قیمت پایین‌تری دارن. این به خاطر اینه که استفاده ازش خیلی زیاد شده و رقابت تو بازار بالا رفته.
    • دسترسی آزاد به مستندات فنی: برای بیشتر پروتکل‌ها و تکنولوژی‌های بی‌سیم دیگه، شما باید عضو رسمی اون گروه یا کنسرسیوم بشید تا بتونید به مشخصات فنیش دسترسی داشته باشید. عضویت تو این گروه‌ها میتونه خیلی گرون باشه (حتی تا هزاران دلار در سال). اما برای BLE، مستندات فنی نسخه‌های اصلی (مثل 4.0, 4.2, 5.0, 5.1, 5.2, 5.3 و غیره) رو میتونید به صورت رایگان از وب‌سایت Bluetooth.com دانلود کنید.
    • وجود گسترده در گوشی‌های هوشمند: این شاید بزرگترین مزیت BLE نسبت به رقباش مثل ZigBee، Z-Wave و Thread باشه. تقریبا همه مردم دنیا یک گوشی هوشمند دارن و تقریبا تمام این گوشی‌ها سخت‌افزار BLE رو داخلشون دارن. این به توسعه‌دهنده‌ها یک پایگاه کاربری بالقوه خیلی بزرگ برای اپلیکیشن‌هاشون میده.

    آیا BLE هیچ محدودیتی نداره؟

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

    • سرعت انتقال داده (Throughput): سرعت انتقال داده تو BLE توسط نرخ داده رادیوی فیزیکی محدود میشه. این نرخ به نسخه بلوتوثی که استفاده میشه بستگی داره.
      • برای نسخه‌های بلوتوث قبل از ۵.۰، این نرخ روی ۱ مگابیت بر ثانیه (Mbps) ثابته.
      • اما برای بلوتوث ۵.۰ و بالاتر، این نرخ بسته به حالت و لایه فیزیکی (PHY) که استفاده میشه، متغیره. میتونه مثل نسخه‌های قبلی ۱ مگابیت بر ثانیه باشه، یا وقتی از قابلیت سرعت بالا (high-speed) استفاده میشه به ۲ مگابیت بر ثانیه برسه.
      • وقتی هم از قابلیت برد بلند (long-range) استفاده میشه، این نرخ به ۵۰۰ یا ۱۲۵ کیلوبیت بر ثانیه (Kbps) کاهش پیدا میکنه.
      • نکته مهم: این نرخ‌ها مربوط به لایه رادیوییه. سرعتی که کاربر نهایی در سطح اپلیکیشن تجربه میکنه، خیلی کمتر از این حرف‌هاست.
    • برد (Range): تکنولوژی BLE برای کاربردهای با برد کوتاه طراحی شده، برای همین برد عملکردش محدوده. چند تا عامل روی برد BLE تاثیر میذارن:
      • فرکانس کاری: این تکنولوژی تو طیف فرکانسی ۲.۴ گیگاهرتز ISM کار میکنه که خیلی تحت تاثیر موانعی مثل اشیای فلزی، دیوارها و آب (مخصوصا بدن انسان) قرار میگیره.
      • طراحی آنتن: عملکرد و طراحی آنتن دستگاه BLE خیلی مهمه.
      • پوشش فیزیکی دستگاه: قاب و بدنه دستگاه روی عملکرد آنتن تاثیر میذاره، مخصوصا اگه آنتن داخلی باشه.
      • جهت‌گیری دستگاه: این مورد هم به موقعیت قرارگیری آنتن مربوط میشه (مثلا تو گوشی‌های هوشمند). به طور کلی برد BLE بین ۰ تا ۲۵ متر بهینه است و در شرایط ایده‌آل میتونه تا ۱۰۰ متر هم برسه.
    • نیاز به دروازه (Gateway) برای اتصال به اینترنت: برای اینکه داده رو از یک دستگاه که فقط BLE داره به اینترنت بفرستید، به یک دستگاه دیگه نیاز دارید که هم BLE داشته باشه و هم به اینترنت وصل باشه (مثلا یک گوشی هوشمند یا یک دستگاه مخصوص). این دستگاه واسط، داده رو از دستگاه BLE میگیره و بعد به اینترنت منتقل میکنه.

    BLE رو کجاها میبینیم؟ (کاربردهای واقعی)

    وقتی BLE تو سال ۲۰۱۰ معرفی شد، تمرکزش بیشتر روی کاربردهای اینترنت اشیا (IoT) بود که تو اونها حجم کمی از داده با سرعت پایین منتقل میشه. تو این ده سال اخیر، BLE تو کاربردهای خیلی متنوعی از دستگاه‌های مصرفی گرفته تا تولیدات صنعتی استفاده شده. بیایید چند تا از رایج‌ترین کاربردهاش رو ببینیم:

    • اتوماسیون خانگی: بخش بزرگی از بازار خانه هوشمند به لطف استفاده از بلوتوث LE ممکن شده. این تکنولوژی به دستگاه‌هایی مثل لامپ‌های هوشمند، ترموستات‌های هوشمند، قفل‌های هوشمند و سنسورهایی که دود یا باز بودن پنجره رو تشخیص میدن، اجازه میده با هم ارتباط برقرار کنن.
    • ردیاب‌های تناسب اندام: خیلی از ما ساعت‌های هوشمند یا مچ‌بندهای سلامتی داریم که ضربان قلب، تعداد قدم‌ها و چیزای دیگه رو ردیابی میکنن. این دستگاه‌های سلامتی و ردیاب فعالیت، با استفاده از BLE با اپلیکیشن‌های روی گوشیمون ارتباط برقرار میکنن. این انتقال‌های کوتاه و سریع داده در فاصله نزدیک، یک مثال عالی برای کاربرد BLE هست.
    • دستگاه‌های صوتی: همه ما با هدفون‌های بلوتوثی آشناییم، اما معمولا این دستگاه‌ها از بلوتوث کلاسیک استفاده میکنن. یکی از جدیدترین پیشرفت‌ها در زمینه بلوتوث کم‌مصرف، چیزی به اسم LE Audio هست. این استاندارد جدید چندین مزیت نسبت به بلوتوث سنتی داره، از جمله کیفیت صدای بهتر، مصرف انرژی کمتر و پشتیبانی از سمعک‌ها.
    • ردیابی تماس (Contact Tracing): سیستم‌های هوشمند ردیابی تماس دارن برای کمک به جلوگیری از شیوع بیماری‌های عفونی استفاده میشن. به جای گزارش‌دهی دستی، ردیابی تماس با استفاده از BLE به صورت مداوم «تگ»های BLE یا گوشی‌های هوشمند اطراف رو اسکن میکنه تا به صورت ناشناس تماس‌های نزدیک بین افراد رو ثبت کنه. مثلا در یک محیط کاری، به هر کارمند یک تگ BLE داده میشه و اگه یک نفر بیمار بشه، به راحتی میشه فهمید چه کسانی با اون در تماس نزدیک بودن.
    • تگ‌های پیدا کردن اشیا: با شلوغ شدن سفرها، بعضی‌ها تگ‌هایی مثل AirTag یا Tile رو به چمدونشون وصل میکنن تا اگه گم شد بتونن پیداش کنن. این دستگاه‌های ردیاب دقیق که با BLE کار میکنن، فقط برای چمدون نیستن. میتونید اونها رو به هر چیزی که فکر میکنید ممکنه گم بشه وصل کنید، مثل دوچرخه یا کلید ماشین، و موقعیتش رو از طریق یک اپلیکیشن روی گوشی پیدا کنید.
    • تبلیغات هدفمند: تصور کنید تو یک فروشگاه لباس هستید و یهو یک نوتیفیکیشن روی گوشیتون میاد که یک کوپن تخفیف برای همون فروشگاهی که توش هستید بهتون میده. این نوع تبلیغات شخصی‌سازی شده و مبتنی بر مکان، دقیقا کاریه که تبلیغ‌کننده‌ها و صاحبان فروشگاه‌ها میتونن انجام بدن. این کار به لطف پیشرفت‌های بلوتوث ۵.۰ و تکنولوژی پخش همگانی «بیکن»های بلوتوثی ممکنه.
    • مدیریت انبار: مدیران انبارها دارن از راهکارهای مبتنی بر BLE برای ردیابی دما و رطوبت محموله‌های حساس، تشخیص افتادن بسته‌های شکننده و حتی پیدا کردن بهینه‌ترین مکان برای نگهداری دارایی‌ها در انبار استفاده میکنن. پتانسیل زیادی وجود داره که هوش مصنوعی و BLE با هم ترکیب بشن و یک زنجیره لجستیک واقعا هوشمند ایجاد کنن.
    • ایمنی کارکنان: تگ‌های BLE میتونن به روش‌های مختلفی به حفظ ایمنی کارکنان کمک کنن. مثلا دکمه‌های وحشت (Panic buttons) برای کارمندان بانک یا هتل که در معرض خطر هستن. این افراد میتونن با فشار دادن تگ BLE به صورت نامحسوس درخواست کمک کنن. یا سیستم‌های تشخیص سقوط (Fall detection) در سایت‌های ساختمانی یا خانه‌های سالمندان که به محض تشخیص سقوط، به صورت خودکار هشدار ارسال میکنن.

    بیکن‌های BLE (BLE Beacons)

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

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

    خب، حالا بریم سراغ بخش فنی ماجرا: معماری BLE

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

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

    پشته پروتکل بلوتوث به طور کلی به سه بخش یا زیرسیستم اصلی تقسیم میشه: اپلیکیشن (Application)، میزبان (Host) و کنترلر (Controller). داخل هر کدوم از این بلوک‌ها، لایه‌های مشخصی وجود داره.

    لایه‌های پروتکل BLE

    اگه شما توسعه‌دهنده‌ای هستید که میخواید اپلیکیشن‌های BLE بنویسید، لازم نیست خیلی نگران لایه‌هایی که پایین‌تر از لایه مدیر امنیت (Security Manager) و پروتکل ویژگی (Attribute Protocol) هستن باشید. اما دونستن کلیات این لایه‌ها میتونه مفید باشه. بیایید یه نگاهی بهشون بندازیم.

    • لایه فیزیکی (Physical Layer – PHY):
      این لایه به رادیوی فیزیکی اشاره داره که برای ارتباط و مدوله/دمدوله کردن داده استفاده میشه. این لایه تو همون باند فرکانسی ISM (طیف ۲.۴ گیگاهرتز) کار میکنه.
    • لایه پیوند (Link Layer):
      این لایه با لایه فیزیکی (رادیو) در ارتباطه و برای لایه‌های بالاتر یک راه برای تعامل با رادیو فراهم میکنه. این لایه مسئول مدیریت وضعیت رادیو و همچنین الزامات زمانی برای پایبندی به مشخصات فنی بلوتوث کم‌مصرفه.
    • رابط کنترلر میزبان (Host Controller Interface – HCI):
      لایه HCI یک پروتکل استاندارد هست که توسط مشخصات بلوتوtoh تعریف شده و به لایه میزبان (Host) اجازه میده با لایه کنترلر (Controller) ارتباط برقرار کنه. این لایه‌ها میتونن روی چیپ‌های جداگانه باشن یا هر دو روی یک چیپ باشن.
    • پروتکل کنترل و تطبیق پیوند منطقی (L2CAP):
      لایه L2CAP مثل یک لایه تقسیم‌کننده پروتکل عمل میکنه. این لایه چندین پروتکل رو از لایه‌های بالاتر میگیره و اونها رو تو بسته‌های استاندارد BLE قرار میده. بعد این بسته‌ها رو به لایه‌های پایین‌تر میفرسته.
    • پروتکل ویژگی (Attribute Protocol – ATT):
      پروتکل ATT تعریف میکنه که یک سرور چطور داده‌هاش رو در اختیار یک کلاینت قرار میده و این داده‌ها چطور ساختاردهی شدن.
    • پروفایل ویژگی عمومی (Generic Attribute Profile – GATT):
      این لایه یکی از مهم‌ترین لایه‌ها برای توسعه‌دهنده‌هاست. GATT فرمت داده‌ای که توسط یک دستگاه BLE ارائه میشه رو تعریف میکنه. همچنین رویه‌های لازم برای دسترسی به این داده‌ها رو مشخص میکنه.

      تو GATT دو تا نقش اصلی وجود داره: سرور (Server) و کلاینت (Client).

      • سرور: دستگاهیه که داده‌هایی که کنترل میکنه یا در اختیار داره رو به بقیه نشون میده.

      • کلاینت: دستگاهیه که با سرور ارتباط برقرار میکنه تا داده‌های سرور رو بخونه یا رفتارش رو کنترل کنه.

      یادتون باشه که یک دستگاه BLE میتونه همزمان هم سرور باشه و هم کلاینت.

      برای فهمیدن GATT، باید با دو مفهوم کلیدی آشنا بشید: سرویس‌ها (Services) و مشخصه‌ها (Characteristics).


      • سرویس (Service): یک گروه از یک یا چند «ویژگی» (Attribute) هست. هدفش اینه که ویژگی‌های مرتبط که یک کارکرد خاص رو روی سرور انجام میدن، کنار هم جمع کنه. مثلا، «سرویس باتری» که توسط خود گروه SIG تعریف شده، شامل یک مشخصه به اسم «سطح باتری» هست.

      • مشخصه (Characteristic): همیشه بخشی از یک سرویسه و یک تیکه از اطلاعات یا داده رو نشون میده که سرور میخواد در اختیار کلاینت بذاره. مثلا، «مشخصه سطح باتری» میزان شارژ باقی‌مونده باتری رو نشون میده که کلاینت میتونه اون رو بخونه.

      در BLE، شش نوع عملیات روی مشخصه‌ها وجود داره:

      • دستورها (Commands)
      • درخواست‌ها (Requests)
      • پاسخ‌ها (Responses)
      • اعلان‌ها (Notifications)
      • نشانه‌ها (Indications)
      • تاییدها (Confirmations)
    • پروفایل دسترسی عمومی (Generic Access Profile – GAP):
      این هم یکی دیگه از لایه‌های بسیار مهم برای توسعه‌دهنده‌هاست. GAP یک چارچوب تعریف میکنه که میگه دستگاه‌های BLE چطور با هم تعامل کنن. این شامل موارد زیر میشه:

      • نقش‌های دستگاه‌های BLE

      • تبلیغات (Advertising) – (پخش همگانی، کشف، پارامترهای تبلیغ، داده تبلیغ)

      • برقراری ارتباط (Connection) – (شروع ارتباط، پذیرش ارتباط، پارامترهای ارتباط)

      • امنیت


      نقش‌های مختلف یک دستگاه BLE اینها هستن:



      • پخش‌کننده (Broadcaster): دستگاهی که تبلیغات (Advertisements) میفرسته اما بسته‌ای دریافت نمیکنه و اجازه اتصال هم به کسی نمیده. مثل یک بیکن.

      • ناظر (Observer): دستگاهی که به بسته‌های تبلیغاتی که بقیه میفرستن گوش میده اما با دستگاه تبلیغ‌کننده ارتباط برقرار نمیکنه.

      • مرکزی (Central): دستگاهی که دستگاه‌های تبلیغ‌کننده دیگه رو کشف میکنه و بهشون گوش میده. یک دستگاه مرکزی این قابلیت رو هم داره که به یک دستگاه تبلیغ‌کننده وصل بشه. معمولا گوشی‌های هوشمند یا کامپیوترها این نقش رو دارن.

      • پیرامونی (Peripheral): دستگاهی که تبلیغ میکنه و اتصال از دستگاه‌های مرکزی رو قبول میکنه. معمولا سنسورها، ساعت‌های هوشمند و دستگاه‌های کوچیک این نقش رو دارن.


      یادتون باشه که یک دستگاه میتونه همزمان چند تا نقش داشته باشه. مثلا گوشی هوشمند شما میتونه در نقش مرکزی باشه وقتی به ساعت هوشمندتون وصله، و همزمان در نقش پیرامونی باشه وقتی به کامپیوترتون وصله.


    ردیابی موقعیت با BLE

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

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

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

    آینده موقعیت‌یابی با BLE: با معرفی بلوتوث ۵.۱ و قابلیت جدیدش به اسم جهت‌یابی (Direction Finding)، قراره دقت موقعیت‌یابی با BLE به سطح زیر یک متر و حتی سانتی‌متر برسه. این قابلیت جدید به دستگاه‌ها اجازه میده نه تنها قدرت سیگنال، بلکه زاویه رسیدن سیگنال (Angle of Arrival – AoA) رو هم محاسبه کنن که باعث میشه موقعیت‌یابی خیلی دقیق‌تر بشه.

    پرسش و پاسخ‌های رایج در مورد BLE

    • سوال ۱: پس BLE همون بلوتوث معمولیه؟
      نه. با اینکه هر دو زیرمجموعه استاندارد بلوتوث هستن، اما دو تا پروتکل جدا و ناسازگار با هم هستن. بلوتوث کلاسیک برای انتقال مداوم داده مثل صدا طراحی شده و مصرف انرژی بالایی داره. BLE برای انتقال‌های کوتاه و کم‌حجم داده طراحی شده و مصرف انرژیش فوق‌العاده پایینه.
    • سوال ۲: چرا BLE برای اینترنت اشیا (IoT) اینقدر مهمه؟
      دو دلیل اصلی وجود داره: اول، مصرف انرژی خیلی پایینش که باعث میشه دستگاه‌های باتری‌خور بتونن برای ماه‌ها یا سال‌ها کار کنن. دوم، برای اکثر کاربردهای IoT مثل سنسورها، فقط لازمه حجم کمی از داده (مثلا فقط دمای فعلی) به صورت دوره‌ای ارسال بشه که BLE برای این کار کاملا بهینه است.
    • سوال ۳: BLE به زبان ساده چطور کار میکنه؟
      سه مرحله اصلی داره:
      1. تبلیغ (Advertising): دستگاه‌های پیرامونی (مثل یک سنسور) بسته‌های کوچیک داده رو به صورت مداوم پخش میکنن تا حضور خودشون رو اعلام کنن.
      2. اسکن (Scanning): دستگاه‌های مرکزی (مثل یک گوشی) به این بسته‌های تبلیغاتی گوش میدن تا دستگاه‌های اطراف رو پیدا کنن.
      3. اتصال (Connection): وقتی دستگاه مرکزی یک دستگاه پیرامونی رو پیدا کرد، میتونه بهش درخواست اتصال بده و بعد از اون، دو دستگاه میتونن داده رو به صورت دوطرفه رد و بدل کنن.
    • سوال ۴: نقش‌های مختلف دستگاه‌های BLE چی هستن؟
      چهار نقش اصلی وجود داره:
      • پیرامونی (Peripheral): دستگاهی که تبلیغ میکنه و منتظر اتصال میمونه (مثل ساعت هوشمند).
      • مرکزی (Central): دستگاهی که اسکن میکنه و اتصال رو برقرار میکنه (مثل گوشی موبایل).
      • پخش‌کننده (Broadcaster): دستگاهی که فقط تبلیغ میکنه و قابل اتصال نیست (مثل بیکن‌ها).
      • ناظر (Observer): دستگاهی که فقط به تبلیغات گوش میده و وصل نمیشه.
    • سوال ۵: چند تا مثال واقعی از کاربرد BLE میزنید؟
      حتما. ردیاب‌های تناسب اندام (مثل فیت‌بیت)، ساعت‌های هوشمند، تجهیزات پزشکی بی‌سیم (مثل مانیتورهای قند خون)، قفل‌های هوشمند در خانه، لامپ‌های هوشمند، تگ‌های پیدا کردن وسایل (مثل ایرتگ)، و سیستم‌های موقعیت‌یاب داخلی در فروشگاه‌ها و فرودگاه‌ها، همگی از BLE استفاده میکنن.

    منابع

    • [2] Bluetooth Low Energy (BLE) – Cisco Meraki Documentation
    • [4] Bluetooth RTLS: BLE Location Tracking & Positioning | Inpixon
    • [6] What is Medical BLE? | AiRISTA Blog
    • [8] BLE Scanner 4.0 on the App Store
    • [10] BLE Scanner (Connect & Notify) – Apps on Google Play
    • [1] BLE vs Bluetooth : r/embedded
    • [3] Bluetooth Low Energy (BLE): A Complete Guide
    • [5] Can someone explain BLE to me? (Bluetooth Modules) : r/embedded
    • [7] BLE | Bluetooth Low Energy – Why Everyone Is Using It?
    • [9] BLE (Bluetooth Low Energy): What Is BLE? | 7SIGNAL

  • Oblivious DNS over HTTPS (ODoH)؛ حریم خصوصی بیشتر در DNS

    وقتی شما می‌خواید یه سایتی مثل cloudflare.com رو باز کنید، کامپیوتر شما که آدرس عددی یا همون IP اون سایت رو بلد نیست. پس یه سوال از یه سرور مخصوص به اسم DNS Resolver می‌پرسه. این سوال اینه: «هی، آدرس cloudflare.com چنده؟». اون سرور هم جواب میده و کامپیوتر شما با اون آدرس به سایت وصل میشه.

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

    برای حل این مشکل، پروتکل‌هایی مثل DNS over HTTPS (DoH) و DNS over TLS (DoT) به وجود اومدن. کار اینا اینه که همون سوال و جواب‌ها رو رمزنگاری می‌کنن. اینجوری دیگه کسی وسط راه نمی‌تونه بفهمه شما چی می‌پرسید. خیلی هم عالیه و الان مرورگرهایی مثل فایرفاکس و سیستم‌عامل iOS ازش پشتیبانی می‌کنن.

    اما هنوز یه مسئله‌ای هست. با اینکه سوال شما رمزنگاری شده، ولی بالاخره به دست اون سرور DNS Resolver (مثلا سرور 1.1.1.1 کلاودفلر) می‌رسه. اون سرور برای اینکه بهتون جواب بده، باید سوال شما رو باز کنه. پس اون سرور هم IP شما رو می‌بینه و هم سوال شما رو. یعنی یه نهاد واحد (همون شرکت صاحب DNS Resolver) هنوز می‌تونه بفهمه که یک IP مشخص، دنبال چه سایت‌هایی بوده. درسته که شرکت‌هایی مثل کلاودفلر سیاست‌های حفظ حریم خصوصی سفت و سختی دارن و میگن این اطلاعات رو نگه نمی‌دارن، ولی بعضی‌ها ترجیح میدن به جای اعتماد به سیاست‌نامه‌ها، یه راهکار فنی داشته باشن که این امکان رو از پایه بگیره.

    ورود ODoH: راهکاری برای جدا کردن سوال از هویت

    اینجاست که Oblivious DNS over HTTPS (ODoH) وارد میدون میشه. ODoH یه استاندارد جدیده که مهندس‌هایی از شرکت‌های کلاودفلر، اپل و فستلی (Cloudflare, Apple, and Fastly) روی اون کار کردن. ایده اصلیش خیلی ساده‌ست: جدا کردن آدرس IP شما از سوالی که می‌پرسید، طوری که هیچ نهاد واحدی نتونه هر دو رو با هم ببینه.

    این پروتکل از اواخر سال ۲۰۲۰ توسط سرویس 1.1.1.1 کلاودفلر پشتیبانی میشه. حتی سرویس iCloud Private Relay اپل هم بر پایه ODoH کار می‌کنه و کلاودفلر یکی از شرکای اون‌هاست.

    ODoH چطوری کار می‌کنه؟

    برای اینکه ODoH کار کنه، دو تا بازیگر جدید بین شما (کلاینت) و اون سرور اصلی DNS (که بهش میگیم Resolver) اضافه میشن: یه پراکسی (Proxy) و یه هدف (Target).

    بذارید نقش هر کدوم رو توضیح بدم:

    1. کلاینت (Client): این همون دستگاه شماست (کامپیوتر، موبایل). قبل از اینکه سوال DNS رو بفرسته، اون رو با استفاده از کلید عمومیِ «هدف» رمزنگاری می‌کنه.
    2. پراکسی (Proxy): کلاینت شما اون بسته رمزنگاری شده رو مستقیم برای سرور DNS نمی‌فرسته. اول می‌فرستدش برای پراکسی. پراکسی مثل یه واسطه عمل می‌کنه. بسته رو از شما می‌گیره و برای «هدف» می‌فرسته. نکته مهم اینه که پراکسی هیچ دیدی به محتوای بسته شما نداره، چون رمزنگاری شده. پس نمی‌تونه سوال شما رو بخونه یا تغییرش بده. پراکسی فقط IP شما رو می‌بینه.
    3. هدف (Target): این همون سروریه که قراره به سوال شما جواب بده. بسته رمزنگاری شده رو از پراکسی تحویل می‌گیره. چون کلید خصوصی رو داره، می‌تونه بسته رو باز کنه و سوال شما رو بخونه. اما نکته مهم اینه که «هدف» دیگه IP اصلی شما رو نمی‌بینه! فقط IP پراکسی رو می‌بینه. بعد از اینکه جواب رو پیدا کرد، جواب رو هم رمزنگاری می‌کنه و پس می‌فرسته برای پراکسی.
    4. بازگشت جواب: پراکسی جواب رمزنگاری شده رو می‌گیره و برای شما می‌فرسته. شما هم با کلیدی که دارید، جواب رو باز می‌کنید.

    پس نتیجه چی میشه؟

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

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

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

    رمزنگاری اضافه و کلیدها از کجا میان؟

    شاید بپرسید مگه DoH خودش رمزنگاری HTTPS/TLS نداشت؟ پس این رمزنگاری اضافه برای چیه؟ سوال خوبیه. ببینید، ما اینجا دو تا اتصال TLS جدا داریم: یکی بین شما و پراکسی، و یکی بین پراکسی و هدف. اگه فقط به همون TLS اکتفا می‌کردیم، پراکسی وقتی بسته رو از شما می‌گرفت و می‌خواست برای هدف بفرسته، محتوای DNS شما براش مشخص میشد.

    برای همین ODoH یه لایه رمزنگاری اضافه از نوع کلید عمومی هیبریدی (Hybrid Public Key Encryption – HPKE) روی خود پیام DNS می‌کشه. این رمزنگاری سرتاسری بین شما و «هدف» انجام میشه و پراکسی رو کاملا دور می‌زنه.

    حالا سوال بعدی: شما کلید عمومیِ «هدف» رو از کجا پیدا می‌کنید؟ این کلید از طریق خود DNS به دست میاد. در یک رکورد خاص به اسم HTTPS resource record قرار می‌گیره و با استفاده از DNSSEC هم امنیتش تضمین میشه که کسی نتونه یه کلید جعلی به شما بده.

    شرکای ODoH چه کسانی هستن؟

    کلاودفلر برای راه‌اندازی این سرویس با چند تا شرکت پیشرو که به حریم خصوصی اهمیت میدن همکاری کرده. چون یکی از اجزای اصلی ODoH، پراکسیه، این شرکت‌ها به عنوان شرکای پراکسی فعالیت می‌کنن. بعضی از این شرکا عبارتند از: PCCW، SURF و Equinix.

    بیانیه‌هایی هم از طرف این شرکت‌ها منتشر شده:

    مایکل گلین از PCCW Global گفته: «ODoH یه مفهوم انقلابی جدیده که برای قرار دادن حریم خصوصی کاربر در مرکز همه چیز طراحی شده… این مدل برای اولین بار پراکسی کلاینت رو به طور کامل از رزولورها جدا می‌کنه».

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

    آیا ODoH سرعت اینترنت رو کم می‌کنه؟

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

    • هزینه رمزنگاری اضافه: بررسی‌ها نشون داده که خود فرآیند رمزنگاری و رمزگشایی اضافه با HPKE خیلی ناچیزه. برای ۱۰ هزار دامنه مختلف این تست انجام شده و هزینه اضافه در صدک ۹۹ کمتر از ۱ میلی‌ثانیه بوده.
    • تاثیر کلی روی سرعت: برای اینکه تاثیر کلی رو بسنجن، اومدن زمان پاسخ به کوئری‌های DNS رو در سه حالت مقایسه کردن:
    1. DoH معمولی و مستقیم
    2. ODoH (با پراکسی)
    3. DoH روی شبکه Tor (به عنوان یه راهکار دیگه برای حفظ حریم خصوصی)

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

    نوع اتصالزمان پاسخ در ۵۰٪ مواقع (میانه)
    DoH معمولیکمتر از ۱۴۶ میلی‌ثانیه
    ODoHکمتر از ۲۲۸ میلی‌ثانیه
    DoH روی Torخیلی بیشتر (در نمودار مشخصه که کندتره)

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

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

    نظرات و بحث‌های مختلف در مورد ODoH

    مثل هر تکنولوژی جدید دیگه‌ای، در مورد ODoH هم بحث‌ها و نظرات متفاوتی وجود داره. بعضی از کاربرها و متخصص‌ها توی فروم‌ها و شبکه‌های اجتماعی مثل ردیت (Reddit) دیدگاه‌های جالبی مطرح کردن:

    • نگرانی در مورد اعتماد: یه عده میگن که قبلا باید به ISP خودمون اعتماد می‌کردیم، بعد با DoH باید به یه شرکت سوم مثل کلاودفلر یا گوگل اعتماد می‌کردیم، و حالا با ODoH باید هم به کلاودفلر (به عنوان هدف) و هم به یه شرکت پراکسی مثل PCCW یا Equinix اعتماد کنیم که با هم تبانی نمی‌کنن. سوال اصلی اینه که «چه کسی از نگهبانان، نگهبانی می‌کنه؟» و چطور می‌تونیم مطمئن باشیم این شرکت‌ها با هم همکاری نمی‌کنن. یه کاربری گفته: «فکر کنم بیشتر به Quad9 اعتماد دارم تا به کلاودفلر به اضافه یه پراکسی از شرکتی که اسمش رو هم نشنیدم».
    • مشاهده ترافیک توسط ISP: یه دیدگاه خیلی مهم دیگه اینه که حتی اگه شما از ODoH استفاده کنید و سوال DNS شما مخفی بمونه، ISP شما هنوز می‌تونه ببینه که شما به چه آدرس IP وصل میشید. یعنی بعد از اینکه آدرس سایت رو به صورت مخفیانه گرفتید، برای وصل شدن به اون سایت، باید یه درخواست به IP اون بفرستید. این درخواست دیگه مخفی نیست و ISP شما می‌تونه با دیدن IP مقصد بفهمه شما دارید به کدوم سایت سر می‌زنید. پس ODoH جلوی جمع‌آوری اطلاعات توسط وب‌سایت مقصد یا ISP رو به طور کامل نمی‌گیره.
    • راهکار جایگزین: بعضی‌ها معتقدن یه راهکار خصوصی‌تر اینه که کلا شرکت‌های سوم رو حذف کنیم و خودمون یه Recursive Resolver راه‌اندازی کنیم (مثلا با استفاده از نرم‌افزارهایی مثل Unbound یا BIND). اینطوری دیگه اطلاعات DNS ما دست هیچ شرکتی نمیفته.
    • آیا می‌تونم پراکسی خودم رو داشته باشم؟ یه سوال جالب این بود که «آیا می‌تونم پراکسی ODoH خودم رو راه‌اندازی کنم؟». جواب این بود که از نظر فنی بله، ولی اگه فقط شما از اون پراکسی استفاده کنید، هدف اصلی که مخفی شدن بین کلی کاربر دیگه هست از بین میره و باز هم قابل ردیابی میشید.
    • ODoH به عنوان یک استاندارد نوظهور: بعضی کاربرها هم از دیدن گزینه ODoH در تنظیمات روترهای جدید مثل Flint 2 خوشحال و متعجب شدن، چون ODoH هنوز یه استاندارد خیلی جدیده و هنوز به صورت گسترده پیاده‌سازی نشده.

    چطور می‌تونیم ODoH رو امتحان کنیم؟

    کلاودفلر کدهای مربوط به ODoH رو به صورت متن‌باز (Open Source) منتشر کرده. هم پیاده‌سازی سمت سرور و هم سمت کلاینت در زبان‌های برنامه‌نویسی راست (Rust) و گو (Go) موجوده. این یعنی هر کسی می‌تونه خودش یه سرویس ODoH راه‌اندازی کنه یا با کلاینت‌های موجود اون رو تست کنه.

    سرور 1.1.1.1 کلاودفلر هم آماده دریافت کوئری‌های ODoH روی آدرس odoh.cloudflare-dns.com هست.

    حتی می‌تونید با یه دستور ساده مثل dig مشخصات و کلید عمومی سرویس ODoH کلاودفلر رو ببینید:

    dig -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com

    علاوه بر این، ابزارهایی مثل dnscrypt-proxy هم از ODoH پشتیبانی می‌کنن و میشه از اون‌ها برای ارسال کوئری‌های ODoH استفاده کرد.

    جزئیات فنی بیشتر برای کنجکاوها (بر اساس RFC 9230 و مستندات فنی)

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

    ساختار پروتکل

    • سه بازیگر اصلی: همونطور که گفتیم، سه طرف داریم:
      • Oblivious Client: کلاینتی که کوئری‌ها رو به هدف می‌فرسته، اما از طریق یه پراکسی.
      • Oblivious Proxy: یه سرور HTTP که کوئری‌ها و جواب‌های رمزنگاری شده رو بین کلاینت و هدف رد و بدل می‌کنه.
      • Oblivious Target: یه سرور HTTP که کوئری‌های رمزنگاری شده رو از پراکسی می‌گیره، اون‌ها رو باز می‌کنه و جواب‌های رمزنگاری شده رو برمی‌گردونه.
    • تبادل HTTP:
      • درخواست (Request): کلاینت یه درخواست HTTP POST به آدرس پراکسی می‌فرسته. هدر Content-Type این درخواست باید application/oblivious-dns-message باشه. آدرس هدف هم توی URL درخواست به صورت متغیرهایی به اسم targethost و targetpath قرار می‌گیره.
      • پاسخ (Response): هدف هم جواب رو با همین Content-Type برای پراکسی می‌فرسته و پراکسی هم بدون تغییر اون رو به کلاینت تحویل میده.
    • قالب پیام‌ها:
      • پیام‌های ODoH (هم سوال و هم جواب) یه ساختار مشخص دارن. یه بخش اصلی به اسم dns_message دارن که خود پیام DNS توشه و یه بخش padding که برای سخت‌تر کردن تحلیل ترافیک استفاده میشه.
      • این پیام بعد از رمزنگاری داخل یه ساختار دیگه قرار می‌گیره که شامل message_type (نوع پیام: سوال یا جواب)، key_id (شناسه کلید استفاده شده) و خود encrypted_message (پیام رمزنگاری شده) هست.

    پیکربندی و مدیریت کلیدها در سیستم‌های پیشرفته (مثل BIG-IP)

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

    1. ساخت پروفایل HPKE: اول باید یه پروفایل برای رمزنگاری HPKE بسازید و الگوریتم‌های رمزنگاری (KEM, KDF, AEAD) رو مشخص کنید.
    2. ساخت کلید HPKE: بعد یه کلید بر اساس اون پروفایل ساخته میشه. این کلیدها می‌تونن به صورت خودکار در بازه‌های زمانی مشخص (مثلا هر ۳۰ روز) عوض بشن (Rollover).
    3. تعریف هدف ODoH: یه سرور مجازی به عنوان «هدف» تعریف میشه که به درخواست‌های ODoH گوش میده.
    4. پیکربندی Listener و Wide IP: در نهایت Listener ها و رکوردهای DNS مربوطه (مثل SVCB/HTTPS) تنظیم میشن تا کلاینت‌ها بتونن کلید عمومی هدف رو پیدا کنن و درخواست‌هاشون رو بفرستن.

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

    پرسش و پاسخ

    حالا بریم سراغ چند تا سوال که ممکنه براتون پیش اومده باشه.

    سوال ۱: پس ODoH همون DoH هست که فقط یه واسطه (پراکسی) بهش اضافه شده؟

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

    سوال ۲: اگه ISP من هنوز می‌تونه ببینه به چه IP وصل میشم، پس فایده ODoH چیه؟

    این نکته خیلی مهمیه. ODoH از این جلوگیری می‌کنه که یک نهاد واحد (مثل یه شرکت ارائه دهنده DNS) بتونه یه پروفایل کامل از تاریخچه وب‌گردی شما بر اساس درخواست‌های DNS بسازه. درسته که ISP شما هنوز می‌بینه به چه IP هایی وصل میشید، ولی دیگه نمی‌تونه به راحتی و با نگاه کردن به لاگ‌های DNS، لیست تمام سایت‌هایی که شما حتی فقط اسمشون رو چک کردید (ولی شاید بهشون سر نزدید) رو در بیاره. ODoH یه لایه مهم به حریم خصوصی اضافه می‌کنه، ولی یه راهکار کامل برای ناشناس بودن در اینترنت نیست.

    سوال ۳: آیا ODoH کند نیست؟

    طبق اندازه‌گیری‌های اولیه، ODoH یه مقدار کمی تاخیر نسبت به DoH معمولی داره (حدود ۸۰ تا ۱۰۰ میلی‌ثانیه در نصف مواقع). ولی در مقایسه با راهکارهای حفظ حریم خصوصی دیگه مثل استفاده از شبکه Tor برای ارسال کوئری‌های DNS، خیلی سریع‌تره. پس یه بده‌بستان منطقی بین افزایش حریم خصوصی و یه مقدار کاهش سرعت وجود داره.

    سوال ۴: من باید به کی اعتماد کنم؟ به ISP خودم یا به کلاودفلر و یه شرکت پراکسی که نمی‌شناسم؟

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

    سوال ۵: آیا من می‌تونم همین الان از ODoH استفاده کنم؟

    بله. شما می‌تونید از نرم‌افزارهایی مثل dnscrypt-proxy استفاده کنید که از ODoH پشتیبانی می‌کنن. همچنین اگه از سرویس iCloud Private Relay اپل استفاده می‌کنید، شما در حال حاضر دارید از یه تکنولوژی مبتنی بر ODoH بهره می‌برید. با گذشت زمان، انتظار میره پشتیبانی از این پروتکل در سیستم‌عامل‌ها و مرورگرهای بیشتری به صورت پیش‌فرض فعال بشه.

    منابع

    • [2] Oblivious DNS over HTTPS · Cloudflare 1.1.1.1 docs
    • [4] RFC 9230 – Oblivious DNS over HTTPS
    • [6] Oblivious DNS: Plugging the Internet’s Biggest Privacy Hole – CITP Blog
    • [8] Oblivious DoH : Enhanced DNS Privacy
    • [10] Oblivious HTTP (OHTTP) explained | Mozilla Support
    • [1] Improving DNS Privacy with Oblivious DoH in 1.1.1.1
    • [3] Configuring Oblivious DNS Over HTTP (ODoH) protocol
    • [5] Cloudflare and Apple design a new privacy-friendly DNS protocol – Oblivious DNS-over-HTTPS (ODoH) : r/pihole
    • [7] Oblivious DNS | Proceedings of the 2019 Applied Networking Research Workshop
    • [9] Oblivious DNS (ODoH) – does it work? – Routers / VPN, DNS, Leaks – GL.iNet

  • آشنایی و کار با سرور دیتابیس مای‌اس‌کیو‌ال 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

  • همه چیز درباره دیتابیس اوراکل؛ Oracle Database

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

    • پردازش تراکنش آنلاین (OLTP): فکر کنید به خرید و فروش‌های لحظه‌ای توی یه فروشگاه آنلاین یا تراکنش‌های بانکی. این‌ها کارهایی هستن که باید سریع و دقیق انجام بشن.
    • انبار داده (DW): تصور کنید یه شرکت میخواد تمام داده‌های فروش چند سال گذشته‌اش رو تحلیل کنه تا ببینه چه محصولاتی بیشتر فروش رفتن. این حجم عظیم از داده‌ها توی انبار داده نگهداری و تحلیل میشه.

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

    یه نگاه کوتاه به تاریخچه

    داستان اوراکل از سال ۱۹۷۷ شروع شد. لری الیسون به همراه دو تا از دوست‌ها و همکارای سابقش، باب ماینر و اد اوتس، یه شرکت مشاوره به اسم «آزمایشگاه‌های توسعه نرم‌افزار» یا همون SDL رو راه انداختن. این شرکت بعدا به شرکت اوراکل تبدیل شد. SDL اولین نسخه نرم‌افزار اوراکل رو توسعه داد. جالبه بدونید که اسم «اوراکل» از اسم رمز یه پروژه میاد که CIA بودجه‌اش رو تامین میکرد و الیسون قبلا توی شرکت Ampex روی اون کار کرده بود. حتی اولین مشتری اوراکل هم خود CIA بود و بهشون اجازه داد از این اسم رمز برای محصول جدیدشون استفاده کنن.

    یه نکته جالب اینه که الیسون میخواست پایگاه داده‌اش با System R شرکت IBM سازگار باشه، اما IBM کدهای خطای نرم‌افزارش رو منتشر نکرد. با این حال، تا سال ۱۹۸۵ اوراکل تبلیغ میکرد که برنامه‌هایی که برای SQL/DS یا DB2 نوشته شدن، بدون هیچ تغییری روی اوراکل هم اجرا میشن.

    هیچوقت نسخه‌ای به اسم Oracle v1 وجود نداشت. دلیلش هم این بود که الیسون معتقد بود «هیچکس دلش نمیخواد نسخه ۱ یه محصول رو بخره».

    بخش دوم: معماری اوراکل؛ چطور کار میکنه؟

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

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

    دو بخش اصلی: پایگاه داده و نمونه (Instance)

    1. پایگاه داده: مجموعه‌ای از داده‌هاست که به عنوان یک واحد در نظر گرفته میشن. هدفش هم ذخیره و بازیابی اطلاعات مرتبطه. پایگاه داده یه ساختار فیزیکی و یه ساختار منطقی داره.
    2. نمونه (Instance): هر بار که یه پایگاه داده استارت میخوره، یه قسمتی از حافظه به اسم System Global Area (SGA) بهش اختصاص داده میشه و یه سری فرایندهای پس‌زمینه (Background Processes) هم شروع به کار میکنن. به ترکیب این فرایندها و حافظه میگیم یه «نمونه اوراکل».

    این دو تا از هم جدا هستن. این جدایی به ما اجازه میده که نحوه ذخیره‌سازی فیزیکی داده‌ها رو بدون اینکه روی دسترسی به ساختارهای منطقی تاثیری بذاره، مدیریت کنیم.

    بخش سوم: ساختار فیزیکی؛ فایل‌های واقعی روی دیسک

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

    1. فایل‌های داده (Datafiles): هر پایگاه داده اوراکل حداقل یه فایل داده داره. تمام داده‌های پایگاه داده، مثل داده‌های جدول‌ها و ایندکس‌ها، به صورت فیزیکی توی این فایل‌ها ذخیره میشن. ویژگی‌های این فایل‌ها اینه که میتونن به یه پایگاه داده تعلق داشته باشن، اندازه‌شون میتونه به صورت خودکار زیاد بشه و میشه اونها رو به صورت آنلاین (در دسترس) یا آفلاین (غیرقابل دسترس) قرار داد. وقتی یه کاربر اطلاعاتی رو میخواد، اگه اون اطلاعات توی حافظه موقت (Cache) نباشه، از روی این فایل‌ها خونده و در حافظه ذخیره میشه. برای بالا بردن عملکرد، داده‌های جدید یا تغییر کرده فورا روی دیسک نوشته نمیشن، بلکه توی حافظه جمع میشن و بعدا به صورت یکجا توسط یه فرایند پس‌زمینه به اسم DBWn روی فایل‌ها نوشته میشن.
    2. فایل‌های لاگ دوباره‌کاری (Redo Log Files): هر پایگاه داده اوراکل حداقل دو تا از این فایل‌ها داره. به مجموعه این فایل‌ها میگیم Redo Log. کار اصلی Redo Log اینه که تمام تغییراتی که روی داده‌ها اعمال میشه رو ثبت کنه. اگه یه مشکلی پیش بیاد (مثلا برق بره) و داده‌های تغییر کرده روی فایل‌های داده نوشته نشن، میشه از روی این فایل‌ها تغییرات رو بازیابی کرد تا هیچ کاری از دست نره. این فایل‌ها برای محافظت از پایگاه داده در برابر خرابی خیلی حیاتی هستن. اوراکل حتی اجازه میده چند نسخه از این فایل‌ها رو روی دیسک‌های مختلف داشته باشید تا اگه یکی خراب شد، بقیه سالم بمونن. به فرایند اعمال اطلاعات این فایل‌ها در زمان بازیابی میگن Rolling Forward.
    3. فایل‌های کنترل (Control Files): هر پایگاه داده اوراکل یه فایل کنترل داره. این فایل اطلاعات مربوط به ساختار فیزیکی پایگاه داده رو نگه میداره. مثلا:

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

      • اسم پایگاه داده
      • اسم و مکان فایل‌های داده و فایل‌های Redo Log
      • اطلاعات مربوط به زمان ایجاد پایگاه داده

    بخش چهارم: ساختار منطقی؛ سازماندهی داده‌ها به شکل مجازی

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

    1. فضای جدولی (Tablespaces): یه پایگاه داده به واحدهای ذخیره‌سازی منطقی به اسم Tablespace تقسیم میشه. این فضاها ساختارهای منطقی مرتبط رو با هم گروه‌بندی میکنن. مثلا میشه تمام آبجکت‌های یه اپلیکیشن رو توی یه Tablespace جدا گذاشت تا مدیریت‌شون راحت‌تر بشه. هر پایگاه داده حداقل یه Tablespace به اسم SYSTEM داره. یه Tablespace میتونه آنلاین (در دسترس) یا آفلاین (غیرقابل دسترس) باشه.
    2. اسکیما (Schema): اسکیما مجموعه‌ای از آبجکت‌های پایگاه داده هست. آبجکت‌های اسکیما مستقیما به داده‌های پایگاه داده اشاره دارن. این آبجکت‌ها شامل چیزهایی مثل جدول‌ها، ویوها، سکانس‌ها، رویه‌های ذخیره شده، مترادف‌ها، ایندکس‌ها، کلاسترها و لینک‌های پایگاه داده هستن. هیچ رابطه‌ای بین Tablespace و Schema وجود نداره؛ یعنی آبجکت‌های یه اسکیما میتونن توی Tablespaceهای مختلف باشن و یه Tablespace هم میتونه آبجکت‌هایی از اسکیماهای مختلف رو نگه داره.
    3. بلوک‌های داده، اکستنت‌ها و سگمنت‌ها (Data Blocks, Extents, and Segments): اوراکل برای کنترل دقیق مصرف فضای دیسک از این سه ساختار منطقی استفاده میکنه.

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

      • بلوک داده (Data Block): کوچک‌ترین واحد ذخیره‌سازی داده در اوراکل هست. هر بلوک داده معادل تعداد مشخصی بایت از فضای فیزیکی دیسک هست. اندازه این بلوک‌ها موقع ساختن پایگاه داده مشخص میشه.
      • اکستنت (Extent): سطح بعدی، اکستنت هست. اکستنت تعداد مشخصی بلوک داده پشت سر هم هست که در یک تخصیص واحد برای ذخیره نوع خاصی از اطلاعات به دست میاد.
      • سگمنت (Segment): سطح بالاتر از اکستنت، سگمنت هست. سگمنت مجموعه‌ای از اکستنت‌هاست که برای یه ساختار منطقی خاص تخصیص داده شده. انواع مختلف سگمنت داریم:
        • سگمنت داده (Data Segment): هر جدول غیرکلاستری یه سگمنت داده داره که تمام داده‌هاش اونجا ذخیره میشه.
        • سگمنت ایندکس (Index Segment): هر ایندکس یه سگمنت ایندکس داره که داده‌هاش رو ذخیره میکنه.
        • سگمنت بازگشتی (Rollback Segment): برای ذخیره موقت اطلاعات «undo» یا بازگشتی استفاده میشه. این اطلاعات برای بازیابی تراکنش‌های ناتمام یا ایجاد نماهای سازگار با خواندن (Read-Consistent Views) به کار میره.
        • سگمنت موقت (Temporary Segment): وقتی یه دستور SQL برای اجرا به یه فضای کاری موقت نیاز داره، اوراکل این سگمنت‌ها رو ایجاد میکنه. بعد از اتمام دستور، این فضا آزاد میشه.

    بخش پنجم: آبجکت‌های اسکیما؛ ابزارهای ما برای کار با داده

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

    • جدول (Table): واحد اصلی ذخیره‌سازی داده توی پایگاه داده اوراکل هست. داده‌ها توی سطرها و ستون‌ها ذخیره میشن. هر جدول یه اسم و مجموعه‌ای از ستون‌ها داره. هر ستون هم اسم، نوع داده (مثلا CHAR, DATE, NUMBER) و عرض مشخصی داره.
    • ویو (View): یه ویو مثل یه نمایش سفارشی از داده‌های یک یا چند جدول هست. میشه بهش به عنوان یه «کوئری ذخیره شده» هم نگاه کرد. ویوها خودشون داده‌ای رو ذخیره نمیکنن، بلکه داده‌ها رو از جدول‌های پایه‌ای که روی اون‌ها ساخته شدن، میگیرن. از ویوها معمولا برای ساده‌سازی دسترسی به داده، ایجاد امنیت (مثلا فقط ستون‌های خاصی رو نشون بدیم) یا نمایش داده از چند جدول به صورت یکجا استفاده میشه.
    • ویوی محقق شده (Materialized View): این نوع ویو، برخلاف ویوهای عادی، نتایج یه کوئری رو توی یه آبجکت جدا ذخیره میکنه. یعنی واقعا فضا اشغال میکنه و داده داره. این کار باعث میشه عملکرد کوئری‌ها، مخصوصا توی محیط‌های انبار داده، خیلی بهتر بشه. اسم دیگه‌اش «اسنپ‌شات» (Snapshot) هست.
    • سکانس (Sequence): یه لیست سریالی از اعداد منحصر به فرد تولید میکنه. معمولا برای ستون‌هایی مثل شماره کارمندی یا کد محصول استفاده میشه تا مطمئن باشیم هیچ دو سطری شماره یکسان ندارن. کار برنامه‌نویسی رو خیلی راحت میکنه چون دیگه لازم نیست خودمون نگران تولید اعداد منحصر به فرد باشیم.
    • ایندکس (Index): یه ساختار اختیاریه که برای بالا بردن سرعت بازیابی داده‌ها ساخته میشه. دقیقا مثل فهرست آخر یه کتاب که به شما کمک میکنه یه مطلب رو سریع‌تر پیدا کنید، ایندکس هم به اوراکل کمک میکنه سطر مورد نظر رو سریع‌تر پیدا کنه. ایندکس‌ها روی یک یا چند ستون از یه جدول ساخته میشن و بعد از ساخته شدن، به صورت خودکار توسط اوراکل نگهداری و استفاده میشن.
    • کلاستر و هش کلاستر (Cluster and Hash Cluster): اینها هم ساختارهای اختیاری برای ذخیره‌سازی داده‌های جدول هستن. کلاسترها گروهی از جدول‌ها هستن که چون ستون‌های مشترکی دارن و معمولا با هم استفاده میشن، به صورت فیزیکی کنار هم ذخیره میشن. این کار زمان دسترسی به دیسک رو کم میکنه.
    • مترادف (Synonym): یه اسم مستعار برای یه جدول، ویو، سکانس یا واحد برنامه هست. از مترادف‌ها برای ساده کردن دسترسی به آبجکت‌ها یا مخفی کردن اسم و مالک واقعی اون‌ها استفاده میشه.
    • لینک پایگاه داده (Database Link): یه آبجکت نام‌گذاری شده هست که یه «مسیر» از یه پایگاه داده به پایگاه داده دیگه رو توصیف میکنه. این لینک‌ها توی پایگاه داده‌های توزیع شده برای دسترسی به داده‌های روی سرورهای دیگه استفاده میشن.
    • واحدهای برنامه (Program Units): این‌ها شامل رویه‌ها (Procedures)، توابع (Functions) و پکیج‌ها (Packages) میشن. این واحدها مجموعه‌ای از دستورات SQL و PL/SQL هستن که به عنوان یه واحد قابل اجرا برای انجام یه کار خاص گروه‌بندی میشن.
      • PL/SQL: این زبان رویه‌ای اوراکل، یه افزونه برای SQL هست. به شما اجازه میده منطق برنامه‌نویسی مثل IF...THEN یا حلقه‌ها رو به دستورات SQL اضافه کنید. استفاده از PL/SQL ذخیره شده توی پایگاه داده باعث میشه ترافیک شبکه کم بشه و امنیت و عملکرد برنامه بالا بره.

    بخش ششم: مغز متفکر اوراکل؛ حافظه و فرایندها

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

    ساختارهای حافظه

    1. System Global Area (SGA): این یه ناحیه حافظه مشترکه که داده‌ها و اطلاعات کنترلی یه نمونه اوراکل رو نگه میداره. وقتی یه نمونه استارت میخوره، SGA تخصیص داده میشه و وقتی خاموش میشه، آزاد میشه. کاربرانی که به سرور وصل هستن، داده‌های توی SGA رو به اشتراک میذارن. برای عملکرد بهتر، SGA باید تا جای ممکن بزرگ باشه (البته به شرطی که توی حافظه واقعی جا بشه). SGA خودش چند تا بخش داره:
      • Database Buffer Cache: جدیدترین بلوک‌های داده‌ای که استفاده شدن اینجا ذخیره میشن. چون داده‌های پراستفاده توی حافظه نگه داشته میشن، نیاز به خوندن و نوشتن از روی دیسک (I/O) کم میشه و عملکرد بالا میره.
      • Redo Log Buffer: ورودی‌های Redo Log (لیست تغییرات) قبل از اینکه روی فایل‌های Redo Log نوشته بشن، اینجا ذخیره میشن.
      • Shared Pool: این بخش شامل ساختارهای حافظه مشترک مثل نواحی SQL مشترک هست. هر دستور SQL منحصر به فردی که به پایگاه داده فرستاده میشه، باید پردازش بشه. اطلاعات پردازش اون، مثل درخت تجزیه و نقشه اجرا، توی یه ناحیه SQL مشترک ذخیره میشه. اگه چند اپلیکیشن همون دستور رو اجرا کنن، از همین ناحیه مشترک استفاده میکنن و اینطوری در مصرف حافظه صرفه‌جویی میشه.
      • Large Pool: یه ناحیه اختیاری در SGA هست که برای کارهای سنگینی مثل بکاپ و بازیابی، فرایندهای I/O سرور و حافظه نشست‌ها در پیکربندی سرور چند رشته‌ای استفاده میشه.
    2. Program Global Area (PGA): این یه بافر حافظه هست که داده‌ها و اطلاعات کنترلی یه فرایند سرور رو نگه میداره. هر فرایند سرور PGA مخصوص به خودش رو داره و این حافظه مشترک نیست.

    فرایندها (Processes)

    یه فرایند مثل یه «رشته کنترلی» توی سیستم‌عامل هست که میتونه یه سری مراحل رو اجرا کنه. اوراکل دو نوع کلی فرایند داره:

    1. فرایندهای کاربر (User Processes): این فرایندها کد یه برنامه کاربردی (مثلا یه برنامه نوشته شده با Pro*C/C++) یا یه ابزار اوراکل (مثل Oracle Enterprise Manager) رو اجرا میکنن. فرایند کاربر با فرایندهای سرور ارتباط برقرار میکنه.
    2. فرایندهای اوراکل (Oracle Processes): اینها خودشون دو دسته‌ان:
      • فرایندهای سرور (Server Processes): اوراکل این فرایندها رو برای رسیدگی به درخواست‌های فرایندهای کاربر متصل ایجاد میکنه. فرایند سرور با فرایند کاربر ارتباط برقرار میکنه و با اوراکل تعامل میکنه تا درخواست‌ها رو انجام بده. مثلا اگه یه کاربر داده‌ای رو بخواد که توی بافرهای پایگاه داده نیست، فرایند سرور مرتبط، بلوک‌های داده مناسب رو از فایل‌های داده میخونه و توی SGA میذاره.
      • فرایندهای پس‌زمینه (Background Processes): اوراکل برای هر نمونه یه سری فرایند پس‌زمینه ایجاد میکنه. این فرایندها به صورت ناهمزمان I/O انجام میدن و بر سایر فرایندهای اوراکل نظارت میکنن تا موازی‌سازی رو افزایش بدن و عملکرد و قابلیت اطمینان رو بهتر کنن. بعضی از این فرایندهای مهم اینها هستن:
        • DBWn (Database Writer): بلوک‌های تغییر کرده رو از Database Buffer Cache روی فایل‌های داده مینویسه. این کار رو معمولا زمانی انجام میده که حافظه بافر آزاد کم باشه.
        • LGWR (Log Writer): ورودی‌های Redo Log رو روی دیسک مینویسه.
        • CKPT (Checkpoint): در زمان‌های مشخص، به DBWn سیگنال میده که تمام بافرهای تغییر کرده رو روی دیسک بنویسه. به این رویداد میگن «چک‌پوینت».
        • SMON (System Monitor): وقتی یه نمونه که خراب شده دوباره استارت میخوره، بازیابی رو انجام میده. همچنین سگمنت‌های موقت بی‌استفاده رو پاک میکنه.
        • PMON (Process Monitor): وقتی یه فرایند کاربر با شکست مواجه میشه، بازیابی فرایند رو انجام میده. یعنی حافظه کش رو پاک میکنه و منابعی که اون فرایند استفاده میکرده رو آزاد میکنه.
        • ARCn (Archiver): فایل‌های Redo Log آنلاین رو وقتی پر میشن، در محل ذخیره‌سازی آرشیو کپی میکنه. این فرایند فقط وقتی فعاله که پایگاه داده در حالت ARCHIVELOG باشه.
        • RECO (Recoverer): تراکنش‌های توزیع شده‌ای که به خاطر مشکلات شبکه یا سیستم بلاتکلیف موندن رو حل میکنه.

    بخش هفتم: تراکنش‌ها و یکپارچگی داده؛ چطور اوراکل نظم رو حفظ میکنه؟

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

    اوراکل این مشکلات رو با استفاده از قفل‌ها (Locks) و یه مدل سازگاری چند نسخه‌ای (Multiversion Consistency Model) حل میکنه. اساس این ویژگی‌ها مفهوم تراکنش (Transaction) هست.

    تراکنش (Transaction) چیه؟

    یه تراکنش یه واحد منطقی از کاره که شامل یک یا چند دستور SQL میشه که توسط یه کاربر اجرا میشن. یه تراکنش با اولین دستور SQL قابل اجرای کاربر شروع میشه و وقتی به صراحت Commit (ثبت نهایی) یا Rollback (لغو و بازگشت به حالت قبل) بشه، تموم میشه.

    مثال بانکی:

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

    1. کاهش موجودی حساب پس‌انداز.
    2. افزایش موجودی حساب جاری.
    3. ثبت این تراکنش در دفتر روزنامه تراکنش‌ها.

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

    • Commit: تغییرات ناشی از تمام دستورات SQL توی یه تراکنش رو دائمی میکنه.
    • Rollback: هر تغییری که در نتیجه دستورات SQL در تراکنش ایجاد شده رو لغو میکنه.
    • Savepoint: برای تراکنش‌های طولانی، میشه نشانگرهای میانی به اسم Savepoint تعریف کرد. اینطوری میشه یه تراکنش رو به بخش‌های کوچیک‌تر تقسیم کرد و در صورت نیاز، فقط تا یه Savepoint مشخص کار رو به عقب برگردوند.

    سازگاری خواندن (Read Consistency)

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

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

    قفل‌ها (Locks)

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

    دو نوع اصلی قفل وجود داره: قفل انحصاری (Exclusive Lock) و قفل اشتراکی (Share Lock). روی یه منبع (مثل یه سطر یا جدول) فقط یه قفل انحصاری میشه گذاشت، اما میشه چندین قفل اشتراکی روی همون منبع داشت.

    بخش هشتم: امنیت در اوراکل

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

    1. امنیت سیستم (System Security): مکانیزم‌هایی که دسترسی و استفاده از پایگاه داده رو در سطح سیستم کنترل میکنن. مثل:
      • نام کاربری و رمز عبور معتبر برای اتصال به پایگاه داده.
      • تخصیص فضای دیسک برای کاربران.
      • محدودیت منابع سیستم برای کاربران.
      • ممیزی (Auditing) اقدامات کاربران.
    2. امنیت داده (Data Security): مکانیزم‌هایی که دسترسی و استفاده از پایگاه داده رو در سطح آبجکت‌های اسکیما کنترل میکنن. مثل:
      • اینکه چه کاربرانی به چه آبجکت‌هایی دسترسی دارن.
      • چه عملیاتی روی اون آبجکت‌ها میتونن انجام بدن.

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

    • کاربران (Users): هر پایگاه داده اوراکل یه لیست از نام‌های کاربری داره. برای دسترسی به پایگاه داده، کاربر باید با یه نام کاربری و رمز عبور معتبر وصل بشه.
    • امتیازات (Privileges): امتیاز یعنی حق اجرای یه نوع خاص از دستور SQL. دو نوع امتیاز داریم:
      • امتیازات سیستم (System Privileges): به کاربر اجازه میده یه کار خاص در سطح کل سیستم انجام بده. مثلا امتیاز ساختن یه Tablespace.
      • امتیازات آبجکت (Schema Object Privileges): به کاربر اجازه میده یه کار خاص روی یه آبجکت مشخص انجام بده. مثلا امتیاز حذف کردن سطرها از یه جدول خاص.
    • نقش‌ها (Roles): نقش‌ها گروه‌های نام‌گذاری شده از امتیازات مرتبط هستن که به کاربران یا نقش‌های دیگه داده میشن. مدیریت امتیازات از طریق نقش‌ها خیلی راحت‌تره. مثلا میشه یه نقش برای یه اپلیکیشن ساخت و تمام امتیازات لازم برای اجرای اون اپلیکیشن رو به اون نقش داد. بعد اون نقش رو به کاربرانی که باید از اپلیکیشن استفاده کنن، تخصیص داد.

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

    اوراکل در طول سال‌ها نسخه‌های مختلفی رو منتشر کرده. نام‌گذاری نسخه‌ها هم یه قرارداد خاصی داره. مثلا پسوندهای «c»، «g» و «i» به ترتیب به معنی «Cloud»، «Grid» و «Internet» بودن. در نسخه فعلی یعنی Oracle Database 23ai، پسوند «ai» به معنی «هوش مصنوعی» (Artificial Intelligence) هست. در ادامه یه جدول از نسخه‌های مهم اوراکل و ویژگی‌های کلیدی‌شون رو میبینید:

    نسخه پایگاه داده اوراکلتاریخ انتشار اولیهویژگی‌های برجسته
    Oracle v21979اولین پایگاه داده رابطه‌ای SQL تجاری موجود.
    Oracle v61988قفل‌گذاری در سطح سطر، بکاپ و بازیابی آنلاین.
    Oracle7ژوئن 1992رویه‌های ذخیره شده PL/SQL، تریگرها.
    Oracle8i Database1998پروتکل‌های اینترنتی بومی و جاوا.
    Oracle9i Database2001Oracle Real Application Clusters (RAC)، Oracle XML DB.
    Oracle Database 10g2003مدیریت خودکار پایگاه داده، زیرساخت Grid، Oracle ASM.
    Oracle Database 11gسپتامبر 2007Active Data Guard، Secure Files، Exadata.
    Oracle Database 12cژوئیه 2013معماری چندمستاجری (Multitenant)، In-Memory Column Store، JSON بومی.
    Oracle Database 18cفوریه 2018یکپارچه‌سازی با Active Directory، توابع جدول چندریختی.
    Oracle Database 19c (LTR)فوریه 2019ایجاد خودکار ایندکس، نگهداری آمار به صورت Real-Time.
    Oracle Database 21c (IR)دسامبر 2020جداول بلاک‌چین، اجرای جاوا اسکریپت در پایگاه داده.
    Oracle Database 23ai (LTR)۲ می ۲۰۲۴جستجوی برداری هوش مصنوعی (AI Vector Search)، دوگانگی رابطه‌ای JSON، پشتیبانی از میکروسرویس‌های تراکنشی.

    (LTR مخفف Long Term Release و IR مخفف Innovation Release هست)

    بخش دهم: پرسش و پاسخ از دنیای واقعی

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

    سوال ۱: من یه مدیر پایگاه داده SQL Server هستم. یاد گرفتن اوراکل چقدر سخته؟

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

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

    این یه سوال فنی رایجه. چند تا راه برای این کار وجود داره. یه راه ساده استفاده از این کوئری هست:

    select sys_context('USERENV','SERVER_HOST') from dual

    این دستور نیاز به هیچ امتیاز خاصی نداره و برای همین استفاده ازش توی رویه‌های ذخیره شده راحته. البته این پارامتر یعنی SERVER_HOST فقط از نسخه 10G به بعد در دسترسه. با استفاده از sys_context میشه اطلاعات مفید دیگه‌ای هم به دست آورد:

    select
  sys_context ( 'USERENV', 'DB_NAME' ) db_name,
  sys_context ( 'USERENV', 'SESSION_USER' ) user_name,
  sys_context ( 'USERENV', 'SERVER_HOST' ) db_host,
  sys_context ( 'USERENV', 'HOST' ) user_host
from dual

    این کوئری اسم پایگاه داده، اسم کاربر نشست، هاست پایگاه داده و هاست کاربر رو برمیگردونه.

    سوال ۳: نمیتونم سرور رو متوقف کنم و پیام «Cannot stop/start server – Oracle database server is in existing mode» رو میگیرم. مشکل چیه؟

    یه کاربری با نسخه 9.0.00 با این مشکل مواجه شده بود. وقتی از دستورات stop_all و start_all استفاده میکرد، این پیام رو دریافت میکرد. به نظر میرسید که با وجود این پیام، تمام فرایندهای EM واقعا متوقف میشدن. برای start_all هم این پیام اول نشون داده میشد ولی بعد از چند ثانیه رمز DBO رو میپرسید و فرایندها رو شروع میکرد. این کاربر اشاره کرده بود که پایگاه داده‌اش روی یه سرور اختصاصی نیست و با پایگاه داده‌های دیگه به اشتراک گذاشته شده. این پیام از اسکریپت‌های CM میاد و مدیران پایگاه داده (DBA) نتونسته بودن توضیحش بدن. اینجور مشکلات معمولا به پیکربندی خاص اون محیط برمیگرده.

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

    یه کاربری که سرورهاش فقط میزبان پایگاه داده اوراکل (نسخه 11g) بودن، این سوال رو پرسیده بود. نصب اوراکل به همراه جاوا انجام شده بود (مثلا در مسیر \OraHome_1\product\11.2.0\dbhome_1\jdk). تیم عملیات شبکه بهش گفته بود که باید تمام نسخه‌های جاوا رو نگهداری و آپدیت کنه. اون کاربر ترجیح میداد اگه جاوا ضروری نیست، اون رو حذف کنه تا از زحمت نگهداریش خلاص بشه. واقعیت اینه که خیلی از ویژگی‌های داخلی اوراکل به جاوا وابسته هستن. بنابراین، جاوا به عنوان بخشی از نصب پایگاه داده اوراکل مورد نیازه و حذف کردنش میتونه مشکلات جدی ایجاد کنه.

    سوال ۵: بکاپ پایگاه داده روی سرور فیزیکی اوراکل در لینوکس چطور کار میکنه؟

    یه کاربر که با نرم‌افزار Veeam کار میکرد، میخواست بدونه بکاپ‌گیری از اوراکل روی سرورهای فیزیکی لینوکس چطوریه، چون Veeam بیشتر برای ماشین‌های مجازی بهینه شده. نرم‌افزارهایی مثل Veeam Agent for Linux (VAL) میتونن از سرورهای فیزیکی لینوکس بکاپ بگیرن. این بکاپ‌ها کل ماشین رو شامل میشن و به صورت فایل‌سیستمی سازگار هستن. در نسخه‌های جدیدتر این ابزارها، ویژگی‌هایی برای اطمینان از سازگاری تراکنشی (Transaction Consistency) پایگاه داده اوراکل هم اضافه شده. این یعنی قبل از بکاپ، پایگاه داده در حالتی قرار میگیره که بکاپ گرفته شده سالم و قابل بازیابی باشه.

    منابع

    • [2] Oracle Database – Wikipedia
    • [4] Java on Oracle Database Server? – Oracle Forums
    • [6] SQL Server DBA – How Hard is Oracle Database? : r/Database
    • [8] How database backup works on physical Oracle Database server in Linux
    • [10] Find the server name for an Oracle database – Stack Overflow
    • [1] Database | Oracle
    • [3] Introduction to the Oracle Server
    • [5] Database Software Downloads | Oracle
    • [7] Introduction to the Oracle Server
    • [9] Cannot stop server – Oracle database server is in existing mode – Discussion – BMC Community

  • پست‌گرس‌کیوال PostgreSQL چیست؟ راهنمای استفاده اولیه

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

    • پایگاه داده (Database): فکر کنین یه دفترچه یادداشت خیلی خیلی بزرگ و هوشمند دارین که میتونین اطلاعات رو خیلی مرتب و منظم توش ذخیره کنین. مثلا اطلاعات دانشجوهای یه دانشگاه، محصولات یه فروشگاه آنلاین، یا لیست آهنگ‌های یه اپلیکیشن موسیقی. به این دفترچه هوشمند میگن پایگاه داده. کارش اینه که اطلاعات رو نگه داره، بهمون اجازه بده توش جستجو کنیم، اطلاعات جدید اضافه کنیم یا اطلاعات قبلی رو تغییر بدیم.
    • سیستم مدیریت پایگاه داده (Database System): حالا اون نرم‌افزاری که به ما اجازه میده اون دفترچه هوشمند (پایگاه داده) رو بسازیم و مدیریتش کنیم، میشه سیستم مدیریت پایگاه داده. پست‌گرس‌کیوال دقیقا همین کار رو میکنه. یه جورایی مثل اون برنامه دفترچه یادداشت توی کامپیوتر یا گوشیتونه، ولی هزاران بار قوی‌تر و پیشرفته‌تر.
    • رابطه‌ای (Relational): این کلمه یعنی اطلاعات توی جدول‌های مختلفی ذخیره میشن که به هم ربط دارن. مثلا یه جدول داریم برای دانشجوها، یه جدول دیگه برای درس‌ها. بعد میتونیم بین این دوتا جدول یه رابطه برقرار کنیم تا مشخص بشه هر دانشجویی چه درس‌هایی رو برداشته. اینجوری همه چیز خیلی منظم و دسته‌بندی شده باقی میمونه.
    • شی‌گرا (Object-Relational): این یه ویژگی پیشرفته‌تره. یعنی پست‌گرس‌کیوال فقط به مدل رابطه‌ای محدود نیست و میتونه ساختارهای داده پیچیده‌تری رو هم مدیریت کنه. فعلا خیلی درگیر این قسمتش نشین، همینقدر بدونین که این ویژگی دستش رو برای کارهای پیچیده‌تر باز میذاره.
    • متن‌باز (Open Source): این یعنی کد اصلی برنامه پست‌گرس‌کیوال در دسترس همه هست. هر کسی میتونه اون رو ببینه، تغییر بده و حتی در بهتر شدنش کمک کنه. این باعث میشه یه جامعه بزرگ از متخصص‌ها در سراسر دنیا روی توسعه‌ش کار کنن و همیشه در حال پیشرفت باشه.

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

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

    وقتی برای اولین بار با ابزارهایی مثل پست‌گرس‌کیوال کار میکنین، یه سری کلمه‌ها مثل «سرور» مدام به چشمتون میخوره. یکی از کاربرها توی ردیت دقیقا همین سوال رو پرسیده بود که «این سرورهایی که توی pgAdmin (یه ابزار برای مدیریت پست‌گرس) میبینیم چی هستن؟» این سوال خیلی خوبیه، چون به قلب ماجرا میزنه.

    سرور چیه و چه ربطی به پایگاه داده داره؟

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

    حالا، سرور پایگاه داده (Database Server) یه سروره که یه برنامه پایگاه داده (مثل پست‌گرس‌کیوال) روش نصبه و داره سرویس‌های مربوط به پایگاه داده رو به بقیه برنامه‌ها ارائه میده.

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

    پس وقتی توی ابزاری مثل pgAdmin یه چیزی به اسم «Servers» میبینین، منظور همون اتصال به یک سرور پایگاه داده هست. شما میتونین از کامپیوتر خودتون به چندین سرور پایگاه داده مختلف وصل بشین. مثلا یکی ممکنه روی کامپیوتر خودتون نصب باشه برای تمرین (که بهش میگن سرور محلی یا Local Server) و یکی دیگه ممکنه یه کامپیوتر اون سر دنیا باشه که اطلاعات واقعی یه سایت روشه (سرور راه دور یا Remote Server).

    گاهی هم ممکنه ببینین کنار اسم سرور یه عدد نوشته شده، مثلا «PostgreSQL 13». این عدد معمولا به نسخه اون نرم‌افزار پست‌گرس‌کیوال که روی سرور نصبه اشاره داره.

    پست‌گرس‌کیوال زبانه یا سرور؟ قصه SQL چیه؟

    اینم یه سوال خیلی رایجه. خیلیا گیج میشن که فرق بین SQL و PostgreSQL چیه.
    بذارین اینطوری بگم:

    • SQL (Structured Query Language): این اسم یک زبانه. یه زبان استاندارد برای حرف زدن با پایگاه داده‌های رابطه‌ای. شما با استفاده از دستورهای این زبان، از پایگاه داده میخواین که یه کاری براتون انجام بده. مثلا «این اطلاعات رو بهم نشون بده» یا «این کاربر جدید رو اضافه کن».
    • PostgreSQL: این اسم یک نرم‌افزاره. یک سیستم مدیریت پایگاه داده. این نرم‌افزار زبان SQL رو میفهمه. شما دستورهای SQL رو بهش میدین و اون براتون اجراشون میکنه.

    پس پست‌گرس‌کیوال هم یک سروره (نرم‌افزاری که سرویس میده) و هم میشه گفت یه جورایی یه «زبانه» چون نسخه مخصوص به خودش از SQL رو پیاده‌سازی کرده.

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

    • Oracle
    • MySQL (که الان مال اوراکله)
    • MariaDB
    • Microsoft SQL Server
    • و البته PostgreSQL

    همه اینها زبان استاندارد SQL رو به عنوان پایه قبول دارن، ولی هر کدوم یه سری دستورها و ویژگی‌های مخصوص به خودشون رو هم اضافه کردن. مثل لهجه‌های مختلف یه زبان میمونه. هسته اصلی یکیه، ولی تو جزئیات تفاوت دارن. اگه بخوایم با نمودار ون تصور کنیم، یه دایره بزرگ هست به اسم SQL که دستورهای اصلی توشه، و بعد دایره‌های کوچیکتری برای هر کدوم از این نرم‌افزارها (PostgreSQL, MySQL, …) وجود داره که بخش زیادی‌شون با هم همپوشانی داره.

    یه نکته دیگه هم اینکه حواستون باشه اسم «SQL Server» که مال مایکروسافته رو با مفهوم کلی «سرور SQL» اشتباه نگیرین. اولی اسم یه محصول خاصه، دومی یه مفهوم کلی.

    دو نوع دستور مهم در SQL

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

    1. DML (Data Manipulation Language): زبان دستکاری داده‌ها. این دستورها کارشون با خود داده‌هاست. یعنی داده‌ها رو «تغییر» میدن. مثلا:
      • INSERT: یه ردیف داده جدید اضافه میکنه.
      • UPDATE: داده‌های موجود رو به‌روز میکنه.
      • DELETE: داده‌ها رو حذف میکنه.
    2. DDL (Data Definition Language): زبان تعریف داده‌ها. این دستورها با ساختار پایگاه داده کار دارن. یعنی اون جدول‌ها و روابط بینشون رو «تعریف» یا «تغیبر» میدن. مثلا:
      • CREATE TABLE: یه جدول جدید میسازه.
      • ALTER TABLE: ساختار یه جدول موجود رو تغییر میده.
      • DROP TABLE: یه جدول رو کلا حذف میکنه.

    درک این تفاوت بهتون کمک میکنه که بهتر بفهمین هر دستور داره چیکار میکنه.

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

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

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

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

    • بسته‌های آماده (Ready-to-use packages) یا نصب‌کننده‌ها (Installers): این ساده‌ترین راهه. برای سیستم‌عامل‌های مختلف مثل ویندوز، مک و توزیع‌های مختلف لینوکس، فایل‌های نصب آماده‌ای وجود داره که شما فقط دانلود و اجراشون میکنین و مراحل رو دنبال میکنین.
    • سورس کد (Source code archive): اگه خیلی حرفه‌ای هستین و دوست دارین خودتون نرم‌افزار رو از پایه بسازین (کامپایل کنین)، میتونین سورس کدش رو دانلود کنین. دستورالعمل‌های ساختنش هم توی راهنمای رسمیش هست. مخزن سورس کدش هم روی git.postgresql.org قرار داره.
    • نسخه‌های آزمایشی (Beta and release candidates): اگه دوست دارین ویژگی‌های جدیدی که هنوز به طور رسمی منتشر نشدن رو تست کنین، میتونین نسخه‌های بتا یا کاندیدای انتشار رو دانلود کنین. خیلی مهمه که بدونین این نسخه‌ها فقط برای تست هستن و نباید روی سیستم‌های واقعی و کاری ازشون استفاده کنین.

    پشته‌های نرم‌افزاری آماده

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

    شرکتی به اسم BitNami پشته‌های آماده‌ای رو درست کرده که کار رو خیلی راحت میکنه. این پشته‌ها شامل این موارد هستن:

    • LAPP: لینوکس + آپاچی + پی‌اچ‌پی + پست‌گرس‌کیوال
    • MAPP: مک + آپاچی + پی‌اچ‌پی + پست‌گرس‌کیوال
    • WAPP: ویندوز + آپاچی + پی‌اچ‌پی + پست‌گرس‌کیوال

    با نصب این پشته‌ها، همه ابزارهای لازم برای شروع کار به صورت یکجا و هماهنگ با هم نصب میشن.

    نرم‌افزارهای جانبی و کاتالوگ

    دنیای پست‌گرس‌کیوال خیلی بزرگه و کلی نرم‌افزار دیگه هم وجود داره که باهاش کار میکنن ولی به صورت پیش‌فرض همراهش نیستن. توی سایت رسمی پست‌گرس‌کیوال یه بخشی به اسم «کاتالوگ نرم‌افزار» (Software Catalogue) وجود داره که لیست بزرگی از برنامه‌های تجاری و متن‌باز، رابط‌ها و افزونه‌های مختلف رو میتونین توش پیدا کنین. اگه خودتون هم محصولی ساختین که با پست‌گرس‌کیوال کار میکنه، میتونین با پر کردن یه فرم، اون رو به این کاتالوگ اضافه کنین.

    یک راه ساده برای تمرین: Docker

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

    مثلا با دستور زیر میشه یه کانتینر پست‌گرس نسخه ۱۳.۳ رو راه انداخت:

    docker run --rm -p 5432:5432 --name some-postgres-container-name -e POSTGRES_PASSWORD=mysecretpassword postgres:13.3

    بیاین این دستور رو با هم بررسی کنیم:

    • docker run: به داکر میگه یه کانتینر جدید رو اجرا کن.
    • --rm: میگه وقتی کارم با کانتینر تموم شد و متوقفش کردم، خودکار حذفش کن. این برای تمرین عالیه.
    • -p 5432:5432: این بخش مربوط به پورت‌هاست. میگه پورت 5432 کامپیوتر من رو به پورت 5432 داخل کانتینر وصل کن. پورت 5432 پورت استاندارد پست‌گرس‌کیواله.
    • --name some-postgres-container-name: یه اسم برای کانتینرمون انتخاب میکنیم.
    • -e POSTGRES_PASSWORD=mysecretpassword: یه متغیر محیطی به اسم POSTGRES_PASSWORD رو تنظیم میکنه و مقدارش رو برابر با mysecretpassword قرار میده. این پسورد کاربر اصلی پایگاه داده میشه.
    • postgres:13.3: اسم و نسخه ایمیجی که میخوایم از روش کانتینر رو بسازیم. اینجا یعنی ایمیج رسمی پست‌گرس با نسخه 13.3.

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

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

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

    سناریو اول: «بعد از آپدیت، سیستم بالا نمیاد و میگه سرور پست‌گرس استارت نشد!»

    این مشکل برای یه کاربر سیستم‌عامل مانجارو لینوکس پیش اومده بود. کامپیوترش که برای کار ازش استفاده میکرد، بعد از یه آپدیت دیگه بالا نمیومد و روی لوگوی ASRock (مارک مادربوردش) گیر میکرد. پیام خطای اصلی این بود: Failed to start PostgreSQL database server (سرور پایگاه داده پست‌گرس‌کیوال شروع به کار نکرد).

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

    دستوری که استفاده شد این بود: journalctl -xep 0..3

    • journalctl: خود برنامه.
    • -x: اطلاعات بیشتری در مورد هر خطا میده.
    • -e: مستقیم میره به آخر گزارش‌ها که جدیدترین خطاها اونجا هستن.
    • -p 0..3: میگه فقط پیام‌هایی با اولویت بالا رو نشون بده (از ۰ تا ۳ که شامل Emergency, Alert, Critical, Error میشه).

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

    کالبدشکافی لاگ‌های سیستم

    من بخش‌های مهم و تکراری لاگ رو براتون جدا کردم تا تحلیلشون کنیم.

    سرنخ اول: مشکلات مربوط به Firmware و Microcode

    Jun 01 12:43:27 user-pc kernel: [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x3a (or later)
    • kernel: هسته اصلی سیستم‌عامل. این پیام از پایین‌ترین سطح نرم‌افزاری سیستم میاد.
    • Firmware Bug: یعنی یه باگ توی سفت‌افزار (نرم‌افزار سطح پایینی که روی سخت‌افزارها مثل CPU یا مادربورد اجرا میشه) وجود داره.
    • please update microcode: سیستم داره پیشنهاد میده که میکروکد سی‌پی‌یو رو آپدیت کنیم. میکروکد یه جورایی مثل یه آپدیت برای خود سی‌پی‌یو هست که بعضی از باگ‌هاش رو برطرف میکنه.

    نتیجه‌گیری اولیه:

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

    سرنخ دوم: پیدا نشدن ماژول‌های کرنل

    این خطا بارها و بارها توی لاگ‌ها تکرار شده:

    Jun 01 12:43:27 user-pc systemd-modules-load[337]: Failed to find module 'vboxdrv'
Jun 01 12:43:27 user-pc systemd-modules-load[337]: Failed to find module 'vboxnetadp'
Jun 01 12:43:27 user-pc systemd-modules-load[337]: Failed to find module 'vboxnetflt'
Jun 01 14:59:29 user-pc systemd-modules-load[319]: Failed to find module 'nvidia'
Jun 01 14:59:29 user-pc systemd-modules-load[319]: Failed to find module 'nvidia-drm'
Jun 01 14:59:29 user-pc systemd-modules-load[319]: Failed to find module 'zfs'
    • systemd-modules-load: یه بخشی از سیستم‌عامل که مسئول بارگذاری ماژول‌های کرنله.
    • ماژول کرنل چیه؟ فکر کنین کرنل سیستم‌عامل مثل یه موتور ماشینه. ماژول‌ها مثل قطعات اضافی هستن که به این موتور وصل میشن تا کارهای خاصی رو انجام بدن. مثلا درایور کارت گرافیک، درایور کارت شبکه و… .
    • Failed to find module: یعنی سیستم نتونسته این ماژول‌ها رو پیدا و بارگذاری کنه.
    • vboxdrv, vboxnetadp, vboxnetflt: اینها مربوط به نرم‌افزار VirtualBox هستن که برای ساخت ماشین‌های مجازی استفاده میشه.
    • nvidia, nvidia-drm: اینها مربوط به درایور کارت گرافیک Nvidia هستن.
    • zfs: این مربوط به یه نوع سیستم فایل پیشرفته به اسم ZFS هست.

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

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

    سرنخ سوم: خطاهای مربوط به حافظه و سخت‌افزار

    این خطا هم خیلی زیاد تکرار شده:

    Jun 01 12:43:44 user-pc kernel: EDAC sbridge: CPU SrcID #0, Ha #0, Channel #0 has DIMMs, but ECC is disabled
Jun 01 12:43:44 user-pc kernel: EDAC sbridge: Couldn't find mci handler
Jun 01 12:43:44 user-pc kernel: EDAC sbridge: Failed to register device with error -19.
    • EDAC (Error Detection and Correction): یه قابلیتی توی سخت‌افزارها برای پیدا کردن و تصحیح خطاهای حافظه.
    • ECC is disabled: یعنی حافظه ECC (که نوع خاصی از رم برای سرورهاست و قابلیت تصحیح خطا داره) غیرفعاله. این ممکنه برای یه کامپیوتر شخصی عادی باشه، ولی خود پیام خطا نشون میده که سیستم در حال بررسی عمیق سخت‌افزاره.
    • Failed to register device with error -19: این پیام خیلی کلیه ولی نشون میده که کرنل نتونسته یه قطعه سخت‌افزاری رو به درستی شناسایی و راه‌اندازی کنه.

    نتیجه‌گیری سوم:

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

    سرنخ چهارم: خطای نهایی پست‌گرس

    و بالاخره میرسیم به خطایی که کاربر از اول دیده بود:

    Jun 01 12:43:46 user-pc systemd[1]: Failed to start PostgreSQL database server.

    این پیام توسط systemd صادر شده که مدیر سیستم و سرویس‌ها در لینوکسه. این پیام به ما نمیگه چرا پست‌گرس استارت نشده، فقط میگه که تلاشش برای این کار ناموفق بوده.

    جمع‌بندی کارآگاهی سناریو اول:

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

    سناریو دوم: «نمیتونم به سرور وصل بشم، میگه همچین فایلی وجود نداره!»

    این یکی مشکل رایج‌تریه و معمولا مستقیم به خود پست‌گرس ربط داره. یه کاربر روی اوبونتو ۱۸.۰۴ با این خطا مواجه شده:

    psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket “/var/run/postgresql/.s.PGSQL.5432”?

    این خطا یعنی برنامه psql (که ابزار خط فرمان برای وصل شدن به پست‌گرسه) نتونسته به سرور پست‌گرس وصل بشه. داره میپرسه که آیا سرور به صورت محلی (locally) روشنه و روی یه چیزی به اسم «سوکت دامنه یونیکس» داره گوش میده یا نه.

    بیاین مراحل عیب‌یابی این کاربر رو دنبال کنیم:

    قدم اول: وضعیت سرویس رو چک کنیم

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

    sudo systemctl status postgresql

    کاربر این دستور رو زده و دیده که سیستم میگه سرویس «فعاله». حتی با دستور restart هم سرویس رو دوباره راه‌اندازی کرده ولی مشکل حل نشده. این یکم عجیبه.

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

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

    pg_lsclusters

    وقتی کاربر این دستور رو میزنه، با این خروجی مواجه میشه:

    Ver Cluster Port Status Owner Data directory Log file
10 main 5432 down postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
11 main 5433 down postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
12 main 5434 down postgres /var/lib/postgresql/12/main /var/log/postgresql/postgresql-12-main.log

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

    قدم سوم: تلاش برای روشن کردن دستی کلاستر

    حالا کاربر سعی میکنه یکی از کلاسترها رو دستی روشن کنه:

    sudo pg_ctlcluster 10 main start

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

    قدم چهارم: خوندن فایل لاگ پست‌گرس

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

    sudo nano /var/log/postgresql/postgresql-10-main.log

    (nano یه ویرایشگر متن ساده در خط فرمانه)

    و بالاخره، سرنخ اصلی پیدا میشه. داخل فایل لاگ این خطا نوشته شده:

    2020-09-29 02:27:06.445 WAT [25041] FATAL: data directory "/var/lib/postgresql/10/main" has group or world access
2020-09-29 02:27:06.445 WAT [25041] DETAIL: Permissions should be u=rwx (0700).
    • FATAL: یعنی یه خطای خیلی جدی که جلوی اجرای برنامه رو گرفته.
    • data directory ... has group or world access: میگه پوشه‌ای که داده‌های پست‌گرس توش ذخیره میشه (/var/lib/postgresql/10/main)، دسترسی‌های بیش از حدی داره. یعنی بقیه کاربرهای سیستم (group یا world) هم میتونن بهش دسترسی داشته باشن.
    • Permissions should be u=rwx (0700): خود پست‌گرس داره راه‌حل رو هم میگه. میگه سطح دسترسی (Permission) این پوشه باید 0700 باشه.

    سطح دسترسی یا Permission چیه؟

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

    • User (u): مالک فایل.
    • Group (g): گروهی که مالک فایل عضو اون هست.
    • Others/World (o): بقیه کاربران سیستم.

    کارها هم سه نوع هستن:

    • Read (r): خوندن
    • Write (w): نوشتن
    • Execute (x): اجرا کردن

    سطح دسترسی 0700 یعنی:

    • User: دسترسی کامل برای خوندن، نوشتن و اجرا کردن داره (rwx).
    • Group: هیچ دسترسی‌ای نداره.
    • Others: هیچ دسترسی‌ای نداره.

    چرا پست‌گرس اینقدر حساسه؟

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

    قدم پنجم: تصحیح سطح دسترسی و راه‌اندازی مجدد

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

    sudo chmod -R 0700 /var/lib/postgresql/10/main
sudo chmod -R 0700 /var/lib/postgresql/11/main
sudo chmod -R 0700 /var/lib/postgresql/12/main
    • chmod: دستوری برای تغییر سطح دسترسی.
    • -R: یعنی این تغییر رو روی خود پوشه و تمام فایل‌ها و پوشه‌های داخلش هم اعمال کن (Recursive).

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

    sudo pg_ctlcluster 10 main start
sudo pg_ctlcluster 11 main start
sudo pg_ctlcluster 12 main start

    و این بار موفقیت‌آمیز بود. در نهایت با چک کردن دوباره وضعیت کلاسترها، میبینه که همه online شدن:

    Ver Cluster Port Status Owner Data directory Log file
10 main 5432 online postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
11 main 5433 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
12 main 5434 online postgres /var/lib/postgresql/12/main /var/log/postgresql/postgresql-12-main.log

    و مشکل حل میشه.

    سناریو سوم: خطای «authentication failed» با داکر

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

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

    پورت شبکه چیه؟

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

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

    علامت مشکل چیه؟

    معمولا خطایی مثل p1000 authentication failed میگیرین. دلیلش اینه که ابزار شما (مثلا Prisma که یه ابزار برای کار با پایگاه داده‌ست) داره سعی میکنه با اطلاعات کاربری پست‌گرسِ داخل داکر، به پست‌گرسِ نصب شده روی کامپیوتر اصلیتون وصل بشه (چون اون پورت 5432 رو اشغال کرده). طبیعتا اطلاعات کاربری با هم نمیخونه و خطا میده.

    راه‌حل چیه؟

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

    دستور قبلی این بود:

    docker run ... -p 5432:5432 ...

    دستور جدید این میشه:

    docker run ... -p 5433:5432 ...

    این تغییر یعنی چی؟

    • -p 5433:5432: به داکر میگه «هر درخواستی به پورت 5433 کامپیوتر من اومد، اون رو بفرست به پورت 5432 داخل کانتینر».

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

    بخش پنجم: مدیریت روزمره پایگاه داده

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

    پایگاه داده‌های پیش‌فرض: postgres, template1, template0

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

    • postgres: این پایگاه داده به عنوان نقطه اتصال پیش‌فرض برای ابزارها و کاربرها ساخته شده. وقتی شما برنامه‌ای مثل psql رو باز میکنین و مشخص نمیکنین به کدوم پایگاه داده میخواین وصل بشین، به صورت خودکار به postgres وصل میشه. یه جورایی مثل لابی یه هتله. شما اول وارد لابی میشین، بعد تصمیم میگیرین به کدوم اتاق برین. خود سرور پست‌گرس برای کار کردنش به این پایگاه داده نیازی نداره، ولی خیلی از ابزارهای جانبی فرض میکنن که این پایگاه داده وجود داره. پس بهتره حذفش نکنین.
    • template1: این یکی خیلی جالبه. اسمش یعنی «قالب شماره ۱». هر وقت شما یه پایگاه داده جدید میسازین، پست‌گرس در واقع یه کپی کامل از template1 درست میکنه. پس اگه شما یه جدول یا یه تنظیم خاصی رو توی template1 ایجاد کنین، تمام پایگاه داده‌های جدیدی که از اون به بعد میسازین، اون جدول یا تنظیم رو به ارث میبرن. این یه ابزار قدرتمند برای استانداردسازی پایگاه داده‌هاتونه.
    • template0: اینم یه قالبه، ولی یه قالب دست‌نخورده و تمیز. یه جورایی نسخه «تنظیمات کارخانه» محسوب میشه. گاهی اوقات ممکنه شما template1 رو خراب کنین (مثلا یه چیزی توش اضافه کنین که نباید میکردین). از اونجایی که برای ساختن یه کپی از یه قالب، نباید هیچ اتصال دیگه‌ای به اون قالب وجود داشته باشه، اگه template1 خراب بشه، درست کردنش سخته. اینجا template0 به کمکتون میاد. میتونین template1 رو حذف کنین و یه template1 جدید از روی template0 بسازین.

    پس به طور خلاصه:

    • postgres: برای اتصال اولیه.
    • template1: قالب پیش‌فرض برای ساخت پایگاه داده‌های جدید.
    • template0: نسخه پشتیبان و تمیز از قالب، برای روز مبادا.

    کپی کردن یک پایگاه داده از یه سرور به سرور دیگه

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

    روش اول: استفاده از pg_dump و psql (روش کلاسیک)

    این روش خیلی محبوبه و از دو تا ابزار خط فرمان استفاده میکنه: pg_dump برای گرفتن خروجی (بکاپ) و psql برای برگردوندن اون خروجی (ریستور).

    میشه این دوتا رو با هم ترکیب کرد تا بدون ساختن فایل واسطه، کار انجام بشه. به این کار میگن «پایپ کردن» (Piping) که با علامت | انجام میشه.

    pg_dump -C -h localhost -U localuser dbname | psql -h remotehost -U remoteuser dbname

    بیاین این دستور رو بشکافیم:

    • pg_dump: ابزار بکاپ‌گیری.
    • -C: به pg_dump میگه که دستور CREATE DATABASE رو هم توی خروجی بذاره. اینجوری لازم نیست پایگاه داده مقصد رو از قبل بسازیم.
    • -h localhost: میگه به سروری که روی همین کامپیوتر (localhost) هست وصل شو.
    • -U localuser: با کاربر localuser وصل شو.
    • dbname: اسم پایگاه داده‌ای که میخوایم ازش بکاپ بگیریم.
    • |: این علامت جادوییه. خروجی دستور سمت چپش رو به عنوان ورودی به دستور سمت راستش میده.
    • psql: ابزار کلاینت پست‌گرس که اینجا برای ریستور کردن استفاده میشه.
    • -h remotehost: میگه به سرور مقصد که آدرسش remotehost هست وصل شو.
    • -U remoteuser: با کاربر remoteuser به سرور مقصد وصل شو.

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

    # روی سرور مبدا
pg_dump -C -Fp -f dump.sql -U postgres some_database_name
scp dump.sql development:
rm dump.sql

# روی سرور مقصد
ssh development
psql -U postgres -f dump.sql

    روش دوم: استفاده از تونل فشرده با SSH

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

    pg_dump -C dbname | bzip2 | ssh remoteuser@remotehost "bunzip2 | psql dbname"

    اینجا خروجی pg_dump اول با bzip2 فشرده میشه، بعد از طریق یه اتصال امن ssh به سرور مقصد فرستاده میشه، اونجا از حالت فشرده خارج میشه (bunzip2) و در نهایت با psql ریستور میشه.

    روش سوم: pg_basebackup (برای حرفه‌ای‌ها و دیتابیس‌های بزرگ)

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

    برای استفاده از این روش باید یه سری تنظیمات روی سرور مبدا انجام بدین:

    1. در فایل postgresql.conf، گزینه listen_addresses رو روی '*' تنظیم کنین تا سرور از آی‌پی‌های دیگه هم اتصال قبول کنه.
    2. باز هم در همین فایل، wal_level رو حداقل روی replica بذارین.
    3. و max_wal_senders رو روی یه عددی بزرگتر از صفر (مثلا ۱ یا بیشتر) تنظیم کنین.
    4. در فایل pg_hba.conf، یه خط اضافه کنین که به سرور مقصد اجازه اتصال برای «replication» (همانندسازی) بده.
      host replication postgres DST_IP/32 trust
      (به جای DST_IP باید آی‌پی سرور مقصد رو بذارین).
    5. بعد از این تغییرات، سرور پست‌گرس رو ریستارت کنین.

    حالا روی سرور مقصد:

    1. سرویس پست‌گرس رو متوقف کنین (sudo service postgresql stop).
    2. تمام محتویات پوشه داده‌های پست‌گرس رو پاک کنین (مثلا /var/lib/postgresql/12/main/*). مواظب باشین این کار رو روی سرور اشتباهی انجام ندین!
    3. دستور pg_basebackup رو اجرا کنین:
    sudo -u postgres pg_basebackup -h SRC_IP -U postgres -D /var/lib/postgresql/12/main/ --progress

    (به جای SRC_IP آی‌پی سرور مبدا رو بذارین).

    1. بعد از اینکه کارش تموم شد، سرویس پست‌گرس رو روی سرور مقصد روشن کنین (sudo service postgresql start).

    حالا شما یه کپی دقیق از کل سرور مبدا روی سرور مقصد دارین.

    روش چهارم: استفاده از رابط گرافیکی (GUI) مثل pgAdmin

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

    1. به هر دو سرور مبدا و مقصد وصل بشین.
    2. روی پایگاه داده مبدا کلیک راست کنین و گزینه «Backup» رو بزنین. یه فایل بکاپ براتون میسازه.
    3. روی سرور مقصد کلیک راست کنین، «Create» و بعد «Database» رو بزنین و یه پایگاه داده جدید با همون مشخصات پایگاه داده مبدا بسازین.
    4. روی پایگاه داده جدیدی که ساختین کلیک راست کنین و «Restore» رو بزنین. فایل بکاپی که در مرحله ۲ ساختین رو بهش بدین تا اطلاعات رو برگردونه.

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

    گاهی اوقات ممکنه پایگاه داده شما کند بشه، مخصوصا وقتی حجم داده‌ها زیاد میشه و تعداد کاربرها بالا میره. به این وضعیت میگن «بار بالا» (High Load). مدیریت این وضعیت یه بحث خیلی بزرگه، ولی بیاین چند تا نکته کلیدی رو با هم مرور کنیم.

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

    ۲. از EXPLAIN ANALYZE استفاده کنین.
    این یکی از قدرتمندترین ابزارهای شماست. وقتی قبل از هر کوئری SELECT، عبارت EXPLAIN ANALYZE رو بنویسین، پست‌گرس به جای اجرای عادی کوئری، به شما یه گزارش کامل از «نقشه اجرا» (Execution Plan) اون کوئری میده. یعنی بهتون میگه که برای پیدا کردن جواب، دقیقا چه قدم‌هایی رو برداشته و هر قدم چقدر زمان برده.

    ۳. حواستون به «Sequential Scans» باشه.
    وقتی توی خروجی EXPLAIN دیدین که روی یه جدول بزرگ داره «Sequential Scan» انجام میشه، باید حواستون رو جمع کنین. این یعنی پست‌گرس داره کل جدول رو ردیف به ردیف از اول تا آخر میخونه تا داده مورد نظر شما رو پیدا کنه. این کار برای جدول‌های بزرگ خیلی خیلی کنده.

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

    ۵. VACUUM و ANALYZE رو فراموش نکنین.
    وقتی شما داده‌ها رو توی پست‌گرس UPDATE یا DELETE میکنین، فضای اونها فورا آزاد نمیشه. به مرور زمان این فضاهای مرده جمع میشن و باعث میشن جدول‌ها بزرگتر از اندازه واقعی‌شون بشن (به این میگن Bloat). دستور VACUUM این فضاهای مرده رو تمیز و قابل استفاده مجدد میکنه.

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

    در خیلی از تنظیمات پیش‌فرض، سرویس «autovacuum» فعاله و این کارها رو خودکار انجام میده، ولی خوبه که بدونین این دستورها وجود دارن و گاهی اوقات لازمه به صورت دستی اجرا بشن.

    بخش هفتم: پرسش و پاسخ (سوالات متداول شما)

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

    سوال ۱: بالاخره پست‌گرس‌کیوال یه زبانه یا یه سرور؟
    پست‌گرس‌کیوال یک نرم‌افزار مدیریت پایگاه داده هست که به عنوان یک سرور عمل میکنه. این نرم‌افزار، زبان SQL (زبان استاندارد کوئری‌نویسی) رو میفهمه و اجرا میکنه. پس خودش زبان نیست، بلکه اجراکننده زبانه.

    سوال ۲: این «سرورهایی» که توی pgAdmin میبینم چی هستن؟ یعنی چند تا کامپیوتر مختلفن؟
    هر «سرور» توی pgAdmin نشون‌دهنده یک اتصال به یک نمونه (instance) از سرور پایگاه داده پست‌گرس‌کیواله. این سرور میتونه روی کامپیوتر خود شما باشه (localhost) یا روی یه کامپیوتر دیگه در شبکه یا اینترنت. شما میتونین به چندین سرور مختلف به صورت همزمان متصل باشین.

    سوال ۳: من پایگاه داده‌هایی به اسم postgres و template1 میبینم. اینها چی هستن و میتونم پاکشون کنم؟

    • postgres: پایگاه داده پیش‌فرض برای اتصال اولیه ابزارها و کاربران. بهتره پاکش نکنین چون خیلی از برنامه‌ها به وجودش تکیه میکنن.
    • template1: قالبی که تمام پایگاه داده‌های جدید از روی اون کپی میشن. پاک کردنش ایده خوبی نیست، مگه اینکه بخواین از روی template0 (قالب پشتیبان) یه نسخه جدید ازش بسازین.

    سوال ۴: ساده‌ترین راه برای کپی کردن یه پایگاه داده از کامپیوتر خودم به یه سرور دیگه چیه؟
    برای دیتابیس‌های کوچیک و متوسط، استفاده از ترکیب pg_dump و psql با پایپ کردن خیلی ساده و سریعه:
    pg_dump -C -h [آدرس مبدا] -U [کاربر مبدا] [اسم دیتابیس مبدا] | psql -h [آدرس مقصد] -U [کاربر مقصد] [اسم دیتابیس مقصد]

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

    سوال ۶: میخوام وصل بشم ولی خطای authentication failed یا could not connect to server میگیرم. اولین چیزایی که باید چک کنم چی هستن؟

    • آیا سرویس پست‌گرس اصلا روشنه؟ با دستورهایی مثل systemctl status postgresql یا pg_lsclusters وضعیتش رو چک کنین.
    • آیا سطح دسترسی پوشه داده‌ها درسته؟ همونطور که دیدیم، پست‌گرس به این موضوع خیلی حساسه. لاگ‌های پست‌گرس رو چک کنین تا ببینین خطایی در این مورد وجود نداره.
    • آیا تداخل پورت وجود نداره؟ مطمئن بشین که هیچ برنامه دیگه‌ای (مثلا یه نسخه دیگه از پست‌گرس) در حال استفاده از همون پورتی که شما میخواین بهش وصل بشین (معمولا 5432) نیست.
    • آیا اطلاعات اتصال (آدرس سرور، نام کاربری، پسورد) رو درست وارد میکنین؟ این مورد خیلی ساده به نظر میرسه ولی زیاد اتفاق میفته

    منابع

    • [2] After Upgrading, Can’t Boot “Failed to start PostgreSQL database server” – Computer Used for Work – Support – Manjaro Linux Forum
    • [4] Default database named postgres on Postgresql server – Stack Overflow
    • [6] linux – managing high load of a postgresql database – Server Fault
    • [8] PostgreSQL: Why psql can’t connect to server? – Stack Overflow
    • [10] p1000 authentication failed against database server · prisma/prisma · Discussion #8925 · GitHub
    • [1] Noob Question: What are “servers” in postgreSQL/pgAdmin? : r/PostgreSQL
    • [3] PostgreSQL: The world’s most advanced open source database
    • [5] sql – If I’m using PostgreSQL, do I need a server too? Like AWS RDS? – Stack Overflow
    • [7] PostgreSQL: Downloads
    • [9] Copying PostgreSQL database to another server – Stack Overflow

  • آشنایی با MariaDB Server؛ جایگزین اوپن‌سورس MySQL

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

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

    داستان اینجوری شروع شد که یه سری از اعضای اصلی تیم مای‌اس‌کیوال، بعد از اینکه شرکت اوراکل (Oracle Corporation) مای‌اس‌کیوال رو خرید، نگران آینده‌اش شدن. اونا میخواستن مطمئن بشن که این پایگاه داده همیشه متن‌باز و رایگان باقی میمونه. برای همین، پروژه ماریا دی‌بی رو شروع کردن. اسمش هم جالبه؛ مایکل وایدنیوس (Michael “Monty” Widenius) که یکی از بنیان‌گذارهای اصلی مای‌اس‌کیوال و ماریا دی‌بی هست، اسم دختر کوچیکترش، «ماریا»، رو روی این پروژه گذاشت. جالبه بدونید اسم دختر دیگه‌اش «مای» (My) بود که اسم مای‌اس‌کیوال هم از اون گرفته شده.

    هدف اصلی از ساخت ماریا دی‌بی این بود که به عنوان یه جایگزین مستقیم یا «drop-in replacement» برای مای‌اس‌کیوال عمل کنه. یعنی شما بتونید خیلی راحت مای‌اس‌کیوال رو از روی سرورتون بردارید و ماریا دی‌بی رو به جاش نصب کنید، بدون اینکه نیاز باشه کد برنامه‌هاتون رو تغییر بدید. البته ماریا دی‌بی فقط یه کپی ساده نیست؛ توسعه‌دهنده‌ها سعی کردن ویژگی‌های جدید، موتورهای ذخیره‌سازی (Storage Engines) تازه، باگ‌های کمتر و عملکرد بهتری رو بهش اضافه کنن.

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

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

    دو تا نهاد اصلی پشت این پروژه هستن:

    1. بنیاد ماریا دی‌بی (MariaDB Foundation): این یه سازمان غیرانتفاعی هست که وظیفه‌اش نظارت بر توسعه و حفاظت از ماهیت متن‌باز و رایگان ماریا دی‌بی هست. اونا تضمین میکنن که این پروژه همیشه در دسترس همه باشه و هیچ شرکت تجاری نتونه کنترل کاملش رو به دست بگیره.
    2. شرکت ماریا دی‌بی (MariaDB Corporation): این یه شرکت تجاریه که محصولات و خدمات حرفه‌ای بر پایه ماریا دی‌بی ارائه میده. خیلی از توسعه‌دهنده‌های اصلی ماریا دی‌بی توی این شرکت کار میکنن. این شرکت نسخه‌های تجاری با امکانات بیشتر و پشتیبانی تخصصی میفروشه و از این راه درآمد کسب میکنه.

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

    ویژگی‌های کلیدی و تفاوت‌ها

    ماریا دی‌بی تلاش میکنه سازگاری بالایی با مای‌اس‌کیوال داشته باشه. رابط برنامه‌نویسی (API) و پروتکل‌هاش دقیقا با مای‌اس‌کیوال مطابقت دارن. این یعنی همه ابزارها، کتابخانه‌ها و برنامه‌هایی که با مای‌اس‌کیوال کار میکنن، باید با ماریا دی‌بی هم کار کنن. به همین دلیل، خیلی از توزیع‌های لینوکس مثل فدورا (Fedora)، دبیان (Debian) و رد هت (Red Hat Enterprise Linux) به جای مای‌اس‌کیوال، به صورت پیش‌فرض از ماریا دی‌بی استفاده میکنن.

    با این حال، با گذر زمان و اضافه شدن ویژگی‌های جدید، مسیر این دو پروژه داره از هم کمی جدا میشه. مثلا ماریا دی‌بی موتورهای ذخیره‌سازی جدیدی مثل Aria، ColumnStore و MyRocks رو معرفی کرده. همچنین تو نسخه‌های جدیدش، امکانات مربوط به داده‌های جغرافیایی (GIS) و JSON هم اضافه شده.

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

    همونطور که گفتیم، بنیاد ماریا دی‌بی یه نهاد غیرانتفاعی هست که توی دلاور (Delaware) آمریکا ثبت شده و هدفش اینه که از آینده ماریا دی‌بی محافظت کنه. ماموریت این بنیاد روی سه تا اصل بنا شده:

    • باز بودن (Openness): تضمین میکنن که کدهای ماریا دی‌بی همیشه برای استفاده و مشارکت همه باز باقی بمونه و تصمیم‌های فنی بر اساس شایستگی گرفته بشه.
    • پذیرش (Adoption): تلاش میکنن تا استفاده از ماریا دی‌بی توسط کاربرها و در پلتفرم‌های مختلف بیشتر بشه.
    • تداوم (Continuity): مستقل از هر نهاد تجاری، تداوم اکوسیستم ماریا دی‌بی رو فراهم میکنن.

    کارمندهای این بنیاد با انجام کارهای زیر از پروژه پشتیبانی میکنن:

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

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

    حامیان مالی بنیاد ماریا دی‌بی

    اینجا لیست برخی از سازمان‌هایی که از این بنیاد حمایت مالی قابل توجهی میکنن رو میبینیم:

    • حامیان الماس (Diamond sponsors):
      • DBS: یک گروه خدمات مالی پیشرو در آسیا با بیش از ۲۸۰ شعبه در ۱۸ بازار. دفتر مرکزی اون در سنگاپور قرار داره.
    • حامیان پلاتینیوم (Platinum sponsors):
      • MariaDB Corporation: عضو موسس بنیاد و مشارکت‌کننده اصلی کد. محصولات و خدمات تجاری حول ماریا دی‌بی ارائه میده.
      • Acronis: شرکتی که حفاظت از داده و امنیت سایبری رو با هم ترکیب میکنه.
      • Alibaba Cloud: ارائه‌دهنده خدمات رایانش ابری جهانی.
      • Intel: غول فناوری و سازنده پردازنده‌ها که در پیشرفت‌های محاسباتی نقش داشته.
      • ServiceNow: پلتفرمی که به کارمندها اجازه میده اونطور که میخوان کار کنن.
      • Constructor: پلتفرمی برای آموزش و پژوهش با تخصص در هوش ماشینی و علم داده.
      • WebPros: ارائه‌دهنده اکوسیستم کامل برای توانمندسازی حرفه‌ای‌های وب.
    • حامیان طلا (Gold Sponsors):
      • Hetzner: یکی از بزرگترین شرکت‌های میزبانی وب در اروپا که در سال ۱۹۹۷ تاسیس شده.
      • IONOS: شریک دیجیتالی‌سازی برای کسب‌وکارهای کوچک و متوسط در اروپا.
      • Scarf: پیشگام در زمینه تحلیل استفاده از نرم‌افزارهای متن‌باز.
    • حامیان نقره (Silver Sponsors):
      • این لیست شامل شرکت‌های زیادی مثل ArbauDie.IT، Automattic (سازنده WordPress.com)، Crest Infosolutions، Kinsta، Nexedi، Nextcloud، RAVATAR، Releem، Rumahweb، SkySQL، team.blue، Tempesta Technologies، Tencent Cloud، Vettabase، Wikimedia movement و Cyber Leo میشه که هر کدوم در زمینه‌های مختلف فناوری فعالیت دارن.

    نحوه مدیریت و تصمیم‌گیری در پروژه

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

    • تصمیم‌های فنی: تصمیم‌های مربوط به مشارکت در کدها توسط خود مشارکت‌کننده‌ها گرفته میشه. اگه نیاز به اجماع عمومی باشه، موضوع در لیست‌های ایمیل عمومی ماریا دی‌بی و بقیه کانال‌های شفاف آنلاین بحث میشه تا اکثریت توسعه‌دهنده‌ها به توافق برسن. هیچ فرد یا شرکتی نمیتونه اولویت‌ها یا کد رو به جامعه دیکته کنه.
    • هیئت مدیره (Board of directors): بنیاد به صورت قانونی توسط هیئت مدیره کنترل میشه. این هیئت تصمیم میگیره که بنیاد چطور میتونه به بهترین شکل به جامعه ماریا دی‌بی خدمت کنه، اما تصمیم‌های فنی نمیگیره.

    اعضای هیئت مدیره بنیاد ماریا دی‌بی

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

    • مدیران موسس (Ex officio):
      • Sergei Golubchik: معمار ارشد سرور ماریا دی‌بی در شرکت ماریا دی‌بی.
      • Michael “Monty” Widenius: بنیان‌گذار ماریا دی‌بی و مای‌اس‌کیوال.
    • مدیران نماینده شرکت‌ها:
      • Jignesh Shah: مدیر بخش RDS Open Source در آمازون وب سرویسز (AWS).
      • Rohit De Souza: مدیرعامل شرکت MariaDB plc.
    • مدیران فردی:
      • Kaj Arnö: رئیس اجرایی بنیاد.
      • Todd Boyd: عضو ارشد فنی در IBM.
      • Eric Herman: رئیس هیئت مدیره از سال ۲۰۱۶ تا ۲۰۲۵.
      • و افراد دیگه‌ای مثل Espen Håkonsen، Sean Peng و Steve Shaw.

    هر کدوم از این افراد سابقه طولانی در دنیای نرم‌افزار، پایگاه داده و مدیریت دارن. برای مثال، Kaj Arnö قبل از پیوستن به بنیاد، در شرکت MySQL AB و Sun Microsystems سمت‌های مختلفی داشته و یکی از بنیان‌گذارهای شرکت ماریا دی‌بی هم بوده. یا Sergei Golubchik که از سال ۱۹۹۸ توسعه‌دهنده مای‌اس‌کیوال بوده و تقریبا روی همه بخش‌های سرور کار کرده.

    نسخه‌بندی و چرخه‌های انتشار

    ماریا دی‌بی یک سیاست مشخص برای انتشار نسخه‌هاش داره. این به کاربرها کمک میکنه تا بدونن هر نسخه تا کی پشتیبانی میشه و کی باید سیستم‌هاشون رو آپدیت کنن.

    نسخه‌های با پشتیبانی بلندمدت (LTS)

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

    برای مثال، نسخه‌هایی مثل 10.6، 10.11 و 11.4 نسخه‌های LTS هستن.

    نسخه‌های غلتان (Rolling releases)

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

    شماره‌گذاری نسخه‌ها چطوریه؟

    شماره نسخه‌ها معمولا به صورت a.b.c هست. مثلا 11.4.7.

    • a (Major version): نسخه اصلی رو نشون میده (مثلا سری ۱۱). این عدد معمولا سالی یک بار زیاد میشه و ممکنه تغییرات بزرگی که با نسخه‌های قبلی ناسازگار هستن رو شامل بشه.
    • b (Minor version): نسخه فرعی رو نشون میده که امکانات جدید بهش اضافه شده ولی با نسخه‌های قبلی همون سری سازگاره. این عدد هر سه ماه زیاد میشه.
    • c (Patch version): این عدد با هر آپدیت برای رفع باگ یا مشکلات امنیتی زیاد میشه و هیچ ویژگی جدیدی بهش اضافه نمیشه.

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

    نسخهتاریخ انتشار اولیهپایان پشتیبانی (Community)
    11.8۴ ژوئن ۲۰۲۵۴ ژوئن ۲۰۲۸
    11.4۲۹ می ۲۰۲۴۲۹ می ۲۰۲۹
    10.11۱۶ فوریه ۲۰۲۳۱۶ فوریه ۲۰۲۸
    10.6۶ ژوئیه ۲۰۲۱۶ ژوئیه ۲۰۲۶
    10.5۲۴ ژوئن ۲۰۲۰۲۴ ژوئن ۲۰۲۵
    10.4۱۸ ژوئن ۲۰۱۹۱۸ ژوئن ۲۰۲۴
    10.3۲۵ می ۲۰۱۸۲۵ می ۲۰۲۳

    نکته مهم: در همه آپدیت‌ها، حتی آپدیت‌های بزرگ، تیم ماریا دی‌بی تضمین میکنه که ابزار mariadb-upgrade به درستی کار میکنه و شما میتونید فایل‌های پایگاه داده رو از هر نسخه قدیمی‌تری (حتی مای‌اس‌کیوال قبل از نسخه ۸.۰) آپدیت کنید.

    چطور ماریا دی‌بی رو نصب و استفاده کنیم؟

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

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

    مشکل ۱: چرا نصب KDE باعث نصب ماریا دی‌بی میشه؟

    یه کاربر در ردیت (Reddit) سوال جالبی پرسیده بود. اون میخواست روی سیستم عامل فدورا که فقط محیط دسکتاپ گنوم (GNOME) داشت، محیط کی‌دی‌ای (KDE Plasma Workspaces) رو هم نصب کنه. وقتی دستور نصب رو زد، متوجه شد که mariadb-server هم به عنوان یکی از بسته‌های مورد نیاز (dependency) داره نصب میشه.

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

    مشکل ۲: رمز عبور پیش‌فرض ماریا دی‌بی در فدورا چیه؟

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

    جواب اینه: رمز عبور پیش‌فرض خالیه!

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

    پس برای اینکه به عنوان کاربر root وارد ماریا دی‌بی بشید، باید خود دستور رو هم با دسترسی root اجرا کنید. به این صورت:

    sudo mysql

    با این دستور، بدون نیاز به رمز عبور وارد محیط ماریا دی‌بی میشید.

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

    sudo mysql_secure_installation

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

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

    گاهی اوقات موقع نصب، ممکنه با خطای unmet dependencies مواجه بشید. یه کاربر در Stack Overflow گزارش داده بود که موقع نصب mariadb-server روی اوبونتو ۱۲.۰۴، با این خطا مواجه شده که بسته mariadb-server-5.5 نصب نمیشه. مشکل از اینجا بود که یه نسخه از کتابخانه libmysqlclient18 روی سیستمش نصب بود که با نسخه‌ای که ماریا دی‌بی نیاز داشت، تداخل داشت.

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

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

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

    این شرکت یه پلتفرم به اسم MariaDB Enterprise Platform ارائه میده که برای استفاده‌های تجاری و حساس طراحی شده. این پلتفرم شامل موارد زیره:

    • MariaDB Enterprise Server: یه نسخه تقویت‌شده، امن و پایدار از سرور کامیونیتی.
    • MariaDB MaxScale: یک پروکسی پایگاه داده پیشرفته که برای افزایش دسترسی‌پذیری (high availability)، مقیاس‌پذیری و امنیت استفاده میشه.
    • MariaDB Xpand: یک موتور ذخیره‌سازی توزیع‌شده برای مقیاس‌پذیری بسیار بالای بارهای کاری تراکنشی.
    • MariaDB ColumnStore: یک موتور ذخیره‌سازی ستونی برای تحلیل داده‌های حجیم به صورت تعاملی.

    این شرکت ادعا میکنه که ۷۵ درصد از شرکت‌های لیست Fortune 500 از ماریا دی‌بی استفاده میکنن و مهاجرت از پایگاه داده‌های انحصاری به ماریا دی‌بی میتونه تا ۹۰ درصد در هزینه‌ها صرفه‌جویی کنه. یکی از مشتری‌های بزرگشون بانک DBS هست که ۵۴ درصد از برنامه‌های بانکی حیاتی خودش رو به ماریا دی‌بی منتقل کرده.

    در فوریه ۲۰۲۲، این شرکت اعلام کرد که قصد داره از طریق ترکیب با یک شرکت دیگه، وارد بورس نیویورک (NYSE) بشه.

    پلاگین بازخورد کاربر (User Feedback Plugin)

    از اکتبر ۲۰۱۱، ماریا دی‌بی یه پلاگین به اسم «بازخورد کاربر» رو معرفی کرد. این پلاگین به صورت پیش‌فرض غیرفعاله، اما اگه فعالش کنید، به صورت دوره‌ای یه سری اطلاعات مربوط به پیکربندی و نحوه استفاده از ماریا دی‌بی رو به سایت mariadb.org میفرسته.

    هدف از این کار چیه؟
    هدف اصلی اینه که به تیم توسعه کمک کنه تا مسیر مهندسی و توسعه جامعه رو در جهت درستی هدایت کنن. این اطلاعات بهشون نشون میده که:

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

    چه اطلاعاتی جمع‌آوری میشه؟
    این پلاگین فقط اطلاعات غیرحساس رو جمع میکنه. مثل:

    • نوع و سرعت پردازنده و تعداد هسته‌ها.
    • اطلاعات سیستم‌عامل و توزیع.
    • لیست موتورهای ذخیره‌سازی و پلاگین‌های در حال استفاده.

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

    یک سوال مهم در معماری: پایگاه داده متمرکز یا غیرمتمرکز؟

    یه مدیر سیستم تازه‌کار سوال خوبی در ردیت پرسیده بود: «آیا بهترین کار اینه که همه پایگاه داده‌های MySQL/MariaDB رو روی یک سرور متمرکز کنیم؟»

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

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

    دلایل مختلفی برای این جواب وجود داره:

    • نقطه شکست واحد (Single Point of Failure): اگه اون سرور پایگاه داده مرکزی به هر دلیلی از کار بیفته، تمام سرویس‌های شما با هم از کار میفتن.
    • تداخل منابع: سرویس‌های مختلف ممکنه نیازهای متفاوتی به پایگاه داده داشته باشن. یه سرویس ممکنه فشار زیادی به دیسک بیاره، یکی دیگه به پردازنده. وقتی همه روی یه سرور باشن، ممکنه برای منابع با هم رقابت کنن و عملکرد هم رو مختل کنن.
    • امنیت و ایزوله‌سازی: وقتی هر سرویس پایگاه داده خودش رو داره، اگه یکی از سرویس‌ها هک بشه، فقط داده‌های همون سرویس در خطره. اما در مدل متمرکز، ممکنه نفوذ به یک پایگاه داده راه رو برای دسترسی به بقیه داده‌ها هم باز کنه.

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

    پرسش و پاسخ نهایی

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

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

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

    سوال ۳: چرا میگن ماریا دی‌بی یه جایگزین «drop-in» برای مای‌اس‌کیواله؟
    جواب: چون API و پروتکل‌هاش با مای‌اس‌کیوال سازگاره. این یعنی شما میتونید سرور مای‌اس‌کیوال رو با سرور ماریا دی‌بی جایگزین کنید و برنامه‌های شما (مثل سایت وردپرسی یا هر برنامه دیگه‌ای که به پایگاه داده وصل میشه) باید بدون هیچ تغییری به کارشون ادامه بدن.

    سوال ۴: آیا برای استفاده از سرور ماریا دی‌بی باید پول بدم؟
    جواب: نه. سرور ماریا دی‌بی (MariaDB Community Server) تحت لایسنس GNU General Public License نسخه ۲ (GPLv2) منتشر میشه که یعنی کاملا رایگان و متن‌بازه. شما میتونید آزادانه اون رو دانلود، نصب، استفاده و تغییر بدید. نسخه‌های پولی مربوط به پلتفرم تجاری شرکت ماریا دی‌بی هست که امکانات اضافی و پشتیبانی ارائه میده.

    سوال ۵: چرا روی سیستم من وقتی ماریا دی‌بی رو نصب کردم، رمز عبور روت نداشت؟
    جواب: در بسیاری از توزیع‌های لینوکس، ماریا دی‌بی به صورت پیش‌فرض از پلاگین احراز هویت unix_socket استفاده میکنه. این پلاگین به کاربر root سیستم‌عامل اجازه میده بدون نیاز به رمز عبور به عنوان کاربر root پایگاه داده وارد بشه. برای این کار باید از دستور sudo mysql استفاده کنید. این یک اقدام امنیتیه تا جلوی حملات به رمز عبور روت از طریق شبکه گرفته بشه.

    منابع

    • [2] Why does installing KDE plasma workspaces install mariadb server? : r/Fedora
    • [4] ubuntu – Installing MariaDB – Unmet dependencies, mariadb-server-5.5 – Stack Overflow
    • [6] Is centralizing MySQL/mariadb databases on one server best-practice ? : r/sysadmin
    • [8] mysql – What’s the default password of mariadb on fedora? – Stack Overflow
    • [10] MariaDB – Wikipedia
    • [1] MariaDB Foundation – MariaDB.org
    • [3] MariaDB Enterprise Open Source Database | MariaDB
    • [5] Download MariaDB Server – MariaDB.org
    • [7] GitHub – MariaDB/server: MariaDB server is a community developed fork of MySQL server. Started by core members of the original MySQL team, MariaDB actively works with outside developers to deliver the most featureful, stable, and sanely licensed open SQL server in the industry.
    • [9] About MariaDB Server – MariaDB.org

  • مانگو دی‌بی (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

  • امنیت ایمیل؛ راهنمای محافظت از ارتباطات دیجیتال شما

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

    دشمنان نامرئی: با انواع تهدیدهای ایمیلی آشنا بشیم

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

    فیشینگ (Phishing): طعمه‌ای برای شکار اطلاعات شما

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

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

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

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

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

    • فیشینگ نیزه‌ای (Spear Phishing): این نوع فیشینگ مثل یه حمله تک‌تیراندازه. به جای اینکه یه ایمیل عمومی برای هزاران نفر فرستاده بشه، مهاجم یه فرد یا یه سازمان خاص رو هدف قرار می‌ده. اونها قبل از حمله، حسابی در مورد هدف تحقیق می‌کنن و ایمیل رو طوری طراحی می‌کنن که کاملا شخصی و معتبر به نظر برسه. مثلا ممکنه به اسم یکی از همکاران یا مدیر شما ایمیل بزنن و درخواستی بکنن که خیلی عادی به نظر میاد.
    • نهنگ‌گیری (Whaling): این مدل، نسخه سنگین‌تر فیشینگ نیزه‌ایه. اینجا هدف، افراد خیلی مهم و رده‌بالای یه سازمانه، مثل مدیرعامل (CEO) یا مدیر مالی. چون این افراد دسترسی‌های خیلی مهمی دارن، موفقیت تو این نوع حمله می‌تونه خسارت‌های وحشتناکی به بار بیاره.
    • ویشینگ (Vishing): این کلمه ترکیبی از «Voice» و «Phishing» هست و به فیشینگ از طریق تماس صوتی اشاره داره.
    • کوئیشینگ (Quishing): این یکی از روش‌های جدیدتره که از کدهای QR استفاده می‌کنه. ایمیل حاوی یه تصویر از کد QR هست. مهاجم از شما می‌خواد که این کد رو با دوربین موبایل‌تون اسکن کنین. به محض اسکن کردن، شما به یه سایت فیشینگ هدایت می‌شین. نکته خطرناک اینجاست که این کار معمولا با گوشی شخصی انجام می‌شه که احتمالا مثل کامپیوترهای شرکت، تحت نظارت امنیتی نیست و اینطوری مهاجم می‌تونه کنترل‌های امنیتی سازمان رو دور بزنه.

    جعل دامنه ایمیل (Email Domain Spoofing): وقتی ایمیل از یه آدرس آشنا میاد، اما فرستنده غریبه است

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

    بذارین یه مثال بزنم. فرض کنین یه هکر به اسم «چاک» می‌خواد دوستش «باب» رو گول بزنه. چاک می‌تونه یه ایمیل از طرف دامنه «trustworthy-bank.com@» برای باب بفرسته، در حالی که چاک اصلا صاحب این دامنه نیست و هیچ ربطی به اون بانک نداره. این کار باعث می‌شه باب به ایمیل اعتماد کنه و کاری که ازش خواسته شده رو انجام بده.

    بدافزار (Malware): مهمان ناخوانده‌ای در پیوست ایمیل

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

    یکی از راه‌های ساده اینه که مهاجم یه فایل اجرایی با پسوند «.exe» رو مستقیما پیوست کنه و گیرنده رو گول بزنه که اون رو باز کنه. اما یه روش خیلی رایج‌تر و موذیانه‌تر، مخفی کردن کدهای مخرب داخل فایل‌های به ظاهر بی‌خطره. مثلا یه فایل PDF یا یه سند Word. هر دوی این فایل‌ها می‌تونن حاوی کدهایی مثل ماکرو (Macro) باشن. مهاجم‌ها از این قابلیت برای اجرای یه دستور مخرب روی کامپیوتر قربانی استفاده می‌کنن. مثلا به محض باز شدن فایل، یه بدافزار دیگه دانلود و اجرا می‌شه.

    جالبه بدونین که ۹۴ درصد از بدافزارها از طریق ایمیل منتقل می‌شن. خیلی از آلودگی‌های باج‌افزار (Ransomware) در سال‌های اخیر با یه پیوست ایمیل شروع شدن. باج‌افزار نوعی بدافزاره که فایل‌های شما رو قفل (رمزگذاری) می‌کنه و برای باز کردنشون از شما باج می‌خواد.

    • باج‌افزار Ryuk: معمولا از طریق یه پیوست Word که حاوی ماکروی مخربه، پخش می‌شه.
    • باج‌افزار Petya: این یکی از طریق یه ایمیل فیشینگ که خودش رو یه متقاضی کار جا می‌زنه، منتشر می‌شه و یه لینک به یه فایل Dropbox آلوده می‌ده.
    • بدافزار Emotet: این بدافزار که اولش یه تروجان بانکی بود، تکامل پیدا کرد و حالا از طریق پیوست‌های ایمیل آلوده، بدافزارهای دیگه‌ای رو هم پخش می‌کنه.

    اسپم (Spam): پیام‌های ناخواسته و مزاحم

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

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

    تسخیر حساب کاربری (Account Takeover): وقتی خونه شما دست دزد می‌افته

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

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

    • حملات بروت فورس (Brute force): ابزارهای خودکار به طور سیستماتیک رمزهای عبور مختلف رو امتحان می‌کنن تا بالاخره رمز درست رو پیدا کنن. این روش روی حساب‌هایی با رمزهای ضعیف یا رایج بهتر جواب می‌ده.
    • اسپری کردن رمز عبور (Password spraying): این روش شبیه بروت فورسه، اما برعکس عمل می‌کنه. به جای امتحان کردن هزاران رمز روی یک حساب، مهاجم تعداد کمی از رمزهای عبور خیلی رایج (مثلا Password123) رو روی تعداد زیادی از حساب‌ها امتحان می‌کنه تا شناسایی نشه.
    • پر کردن اعتبارنامه (Credential stuffing): مهاجم‌ها از نام‌های کاربری و رمزهای عبوری که قبلا از نشت اطلاعاتی سایت‌های دیگه به دست آوردن، استفاده می‌کنن. اونها روی این حساب می‌کنن که خیلی از کاربرها از یه رمز عبور برای چندتا سایت مختلف استفاده می‌کنن.
    • بدافزار مبتنی بر سرقت اعتبارنامه: نرم‌افزارهای مخربی که اطلاعات ذخیره شده از مرورگرها یا مدیران رمز عبور رو می‌دزدن یا کلیدهایی که شما موقع تایپ رمزتون فشار می‌دین رو ضبط می‌کنن (Keylogger).
    • فیشینگ و مهندسی اجتماعی: همونطور که گفتیم، کاربر رو گول می‌زنن تا خودش اطلاعاتش رو لو بده.

    مهندسی اجتماعی (Social Engineering): بازی با روان شما

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

    و چند تهدید دیگر…

    • حمله مرد میانی (Man-in-the-Middle): تصور کنین یه نفر یواشکی داره به مکالمه شما گوش می‌ده. تو این حمله، مهاجم ارتباط بین دو نفر رو قطع می‌کنه و می‌تونه پیام‌ها رو بخونه، تغییر بده یا پیام‌های جدیدی به مکالمه تزریق کنه.
    • نشت داده (Data Exfiltration): دزدهای حرفه‌ای به سیستم ایمیل یه سازمان نفوذ می‌کنن و داده‌های حساس مثل اسرار تجاری، اطلاعات مالی یا اطلاعات شخصی کارمندان و مشتریان رو می‌دزدن.
    • حمله منع سرویس (Denial of Service): مهاجم‌ها با فرستادن حجم عظیمی از ایمیل‌ها، سرورهای ایمیل رو غرق می‌کنن. سرورها زیر این فشار از کار می‌افتن و ارتباطات ایمیلی مختل می‌شه.

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

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

    رمزگذاری (Encryption): نامه شما در یک پاکت مهر و موم شده

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

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

    اکثر روش‌های رمزگذاری ایمیل از رمزنگاری کلید عمومی استفاده می‌کنن. بعضی از این روش‌ها حتی سر به سر (end-to-end) هستن، یعنی حتی خود شرکت سرویس‌دهنده ایمیل هم نمی‌تونه محتوای پیام‌های شما رو بخونه.

    انواع مختلفی از پروتکل‌های رمزگذاری وجود داره:

    • PGP (Pretty Good Privacy): این یه پروتکل رمزگذاریه که به طور خاص برای ایمیل طراحی شده و چون یه استاندارد بازه، هر کسی می‌تونه ازش استفاده کنه.
    • S/MIME (Secure Multi-purpose Internet Mail Extension): این هم مثل PGP برای امن کردن محتوای ایمیل طراحی شده، اما بیشتر در محیط‌های سازمانی و شرکتی استفاده می‌شه.
    • TLS (Transport Layer Security): این پروتکل برای امن کردن کل ارتباطات شبکه استفاده می‌شه، نه فقط ایمیل. وب‌گردی، انتقال فایل و ایمیل همگی می‌تونن از TLS برای محافظت از داده‌ها در حین انتقال بین دو دستگاه استفاده کنن.

    نگهبانان دامنه: SPF، DKIM و DMARC

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

    این سه نگهبان عبارتند از:

    • SPF (Sender Policy Framework): این رکورد مثل یه لیست مهمان‌ها عمل می‌کنه. صاحب دامنه یه لیست از آدرس‌های IP مجاز که حق دارن از طرف اون دامنه ایمیل بفرستن رو تو رکورد DNS خودش اعلام می‌کنه. وقتی یه ایمیل دریافت می‌شه، سرور گیرنده چک می‌کنه که آیا IP فرستنده تو این لیست مجاز هست یا نه.
    • DKIM (DomainKeys Identified Mail): این رکورد از امضای دیجیتال برای تایید اعتبار ایمیل استفاده می‌کنه. صاحب دامنه کلیدهای عمومی DKIM رو تو رکورد DNS خودش قرار می‌ده و ایمیل‌های خروجی رو به صورت دیجیتالی امضا می‌کنه. گیرنده می‌تونه با استفاده از اون کلید عمومی، امضا رو تایید کنه و مطمئن بشه که ایمیل در مسیر دستکاری نشده.
    • DMARC (Domain-based Message Authentication, Reporting, and Conformance): این رکورد مثل یه مدیر یا ناظر عمل می‌کنه. DMARC به صاحب دامنه اجازه می‌ده که مشخص کنه اگه یه ایمیل در آزمون‌های SPF یا DKIM مردود شد، سرور گیرنده باید باهاش چیکار کنه (مثلا ردش کنه، قرینه‌اش کنه یا فقط گزارش بده). این پروتکل از دو پروتکل قبلی استفاده می‌کنه تا از جعل آدرس ایمیل جلوگیری کنه.

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

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

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

    • دروازه‌های امن ایمیل (Secure Email Gateways – SEG): اینها مثل یه گارد امنیتی در ورودی شبکه شرکت مستقر می‌شن و ایمیل‌های ورودی و خروجی رو بازرسی و فیلتر می‌کنن. اونها از معیارهای مختلفی مثل امضای بدافزارها، فیلتر کردن URLهای مشکوک و الگوهای فیشینگ برای شناسایی و مسدود کردن ایمیل‌های مخرب استفاده می‌کنن.
    • امنیت ایمیل ابری (Cloud Email Security): سرویس‌های ایمیل ابری مثل Google Workspace یا Microsoft 365 معمولا ویژگی‌های امنیتی داخلی دارن. مثلا ممکنه حفاظت در برابر تهدید، فیلتر اسپم و رمزگذاری ارائه بدن. اما با توجه به اینکه آفیس ۳۶۵ به یه هدف جذاب برای مجرم‌های سایبری تبدیل شده، خیلی از شرکت‌ها دنبال لایه‌های امنیتی اضافی هستن.
    • محافظت از داده‌های ایمیل (Email Data Protection – EDP): این راهکارها برای جلوگیری از نشت داده‌های حساس و اطمینان از رعایت قوانین حفاظت از داده طراحی شدن. EDP معمولا از ترکیب رمزگذاری، DLP و SEG استفاده می‌کنه.
    • جلوگیری از از دست رفتن داده (Data Loss Prevention – DLP): این سیستم‌ها محتوای ایمیل‌های خروجی رو بررسی می‌کنن و اگه اطلاعات حساسی (مثل شماره کارت اعتباری یا اطلاعات شخصی) پیدا کنن، جلوی ارسال اون رو می‌گیرن یا اون بخش از متن رو حذف می‌کنن.
    • راهکارهای مبتنی بر API: این راهکارها به جای اینکه در مسیر ایمیل قرار بگیرن، از طریق API به سرویس ایمیل شما متصل می‌شن و ایمیل‌ها رو برای محتوای مخرب بازرسی می‌کنن.
    • هوش مصنوعی (AI) در امنیت ایمیل: هوش مصنوعی داره به یه ابزار قدرتمند در این زمینه تبدیل می‌شه. مدل‌های زبان بزرگ (LLM) می‌تونن محتوای یه ایمیل رو بخونن و تحلیل کنن و علائم هشداردهنده فیشینگ مثل تلاش برای ایجاد حس فوریت یا دستکاری روانشناسی رو تشخیص بدن. همچنین AI می‌تونه الگوهای ترافیک ایمیل رو تحلیل کنه و هرگونه رفتار غیرعادی که ممکنه نشونه یه حمله باشه رو شناسایی کنه.

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

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

    • یک رمز عبور قوی بسازید: رمز عبور ضعیف، تکراری یا لو رفته، شایع‌ترین دلیل هک شدن حساب‌های ایمیله. یه رمز عبور قوی باید حداقل ۱۲ کاراکتر طول داشته باشه و ترکیبی از حروف بزرگ و کوچک، اعداد و کاراکترهای خاص (مثل @، #، $) باشه.
    • احراز هویت دو عاملی (MFA) را فعال کنید: این کار یه لایه امنیتی اضافه به حساب شما اضافه می‌کنه. حتی اگه یه هکر رمز عبور شما رو به دست بیاره، برای ورود به حساب به یه عامل دوم هم احتیاج داره، مثلا یه کدی که به گوشی شما فرستاده می‌شه.
    • مراقب کلاهبرداری‌های فیشینگ باشید: همیشه به ایمیل‌هایی که اطلاعات شخصی از شما می‌خوان یا لینک‌های مشکوک دارن، با دیده شک نگاه کنین. قبل از کلیک کردن، ماوس رو روی لینک نگه دارین تا ببینین واقعا شما رو به کجا می‌بره.
    • نرم‌افزارهای خود را به‌روز نگه دارید: همیشه مطمئن بشین که سیستم عامل و برنامه ایمیل شما آخرین آپدیت‌های امنیتی رو دریافت کرده. هکرها از آسیب‌پذیری‌های نرم‌افزارهای قدیمی سوءاستفاده می‌کنن.
    • یک ارائه‌دهنده خدمات ایمیل معتبر انتخاب کنید: دنبال سرویسی باشین که از رمزگذاری و اقدامات امنیتی دیگه برای محافظت از داده‌های شما استفاده می‌کنه.
    • در آموزش‌های آگاهی‌بخشی امنیتی شرکت کنید: خیلی از سازمان‌ها برای کارمندانشون دوره‌های آموزشی برگزار می‌کنن تا یاد بگیرن چطور تهدیدها رو شناسایی کنن. این آموزش‌ها خیلی مهمن و به شما کمک می‌کنن که به جای اینکه یه نقطه ضعف باشین، به یه نقطه قوت در امنیت سازمان تبدیل بشین.
    • از VPN استفاده کنید: استفاده از VPN می‌تونه با رمزگذاری اتصال اینترنت شما و مخفی کردن آدرس IP، به محافظت از ایمیل‌هاتون کمک کنه و کار رو برای هکرها سخت‌تر کنه.
    • از حساب‌های خود خارج شوید (Log out): وقتی کارتون تموم شد، مخصوصا روی دستگاه‌های اشتراکی، از حساب ایمیل‌تون خارج بشین. فعال کردن خروج خودکار بعد از یه مدت بی‌فعالیتی هم ایده خوبیه.

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

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

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

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

    برای اینکه این مفاهیم رو بهتر درک کنین، بیایید یه نگاهی به یکی از ویژگی‌های امنیتی جیمیل به اسم «حالت محرمانه» (Confidential Mode) بندازیم. این ویژگی به شما اجازه می‌ده ایمیل‌هایی بفرستین که امنیت بیشتری دارن.

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

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

    جلسه پرسش و پاسخ پروفسور

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

    سوال: چرا امنیت ایمیل اینقدر مهمه؟

    پاسخ: چون ایمیل یکی از اصلی‌ترین ابزارهای ارتباطی ماست و اغلب حاوی اطلاعات حساسه. از طرفی، ایمیل یکی از محبوب‌ترین اهداف برای مجرم‌های سایبریه. طبق گزارش‌ها، ۹۴ درصد حمله‌های فیشینگ از ایمیل شروع می‌شن و همینطور ۹۴ درصد بدافزارها از طریق ایمیل منتقل می‌شن. یه حمله ایمیلی موفق می‌تونه منجر به خسارت‌های مالی سنگین (مثل حملات BEC که بین سال‌های ۲۰۱۳ تا ۲۰۲۲ حدود ۵۰ میلیارد دلار خسارت زدن)، از دست رفتن داده‌های حیاتی، آسیب به اعتبار برند و مشکلات قانونی بشه. پس محافظت از ایمیل، یعنی محافظت از کل کسب و کار و زندگی دیجیتال ما.

    سوال: رایج‌ترین تهدیدهای ایمیلی چی هستن؟

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

    سوال: «ایمیل رمزگذاری شده» یعنی چی؟

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

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

    پاسخ: حتما. این پنج کار رو همیشه انجام بدین:

    1. از یه رمز عبور قوی و منحصر به فرد استفاده کنین. رمزی که ترکیبی از حروف بزرگ و کوچک، اعداد و نمادها باشه و برای حساب‌های دیگه‌تون ازش استفاده نکرده باشین.
    2. احراز هویت دو عاملی (MFA) رو حتما فعال کنین. این کار امنیت حساب شما رو به شدت بالا می‌بره.
    3. به لینک‌ها و پیوست‌های مشکوک، مخصوصا از طرف فرستنده‌های ناشناس، به هیچ وجه اعتماد نکنین. همیشه قبل از کلیک کردن، فکر کنین.
    4. نرم‌افزارها و سیستم عامل‌تون رو همیشه آپدیت نگه دارین. این آپدیت‌ها معمولا شامل اصلاحیه‌های امنیتی مهمی هستن.
    5. در مورد روش‌های جدید کلاهبرداری مثل فیشینگ، اطلاعات خودتون رو به‌روز نگه دارین. آگاهی، بهترین سلاح شماست.

    منابع

    • [2] What is Email Security? – GeeksforGeeks
    • [4] What Is Email Security? Definition & Best Practices | Proofpoint US
    • [6] Just a moment…
    • [8] What is Email Security? | Why Email Security is Important
    • [10] Gmail Email Security & Privacy Settings – Google Safety Center
    • [1] What is email security? | Cloudflare
    • [3] What Is Email Security? | Microsoft Security
    • [5] What is Email Security? Types of Services and Solutions – Check Point Software
    • [7] What is Email Security? Types, Tactics and Best Practices | Fortinet
    • [9] What Is Email Security? – Protect Against Email Threats – Cisco