پرش به مطلب اصلی

UdpListener

📖 معرفی کلی

🔧 مشخصات فنی اساسی

ویژگیمقدارتوضیح
نوع نودAdapter (تک‌جهته)جهت کانکشن ها از چپ شروع و به راست پیش روی می‌کنند
لایه شبکهلایه ۴ (Transport Layer)کار با کانکشن‌ها، نه پکت‌های خام
جهت پشتیبانیچپ به راست (Left to Right)دوجهته نیست مثل بعضی نودهای لایه ۳
موقعیت در زنجیرابتدای زنجیر (Entry Point)جایگاه دیگری نمی‌تواند داشته باشد
وابستگینیاز به حداقل یک نود در بخش nextبرای انتقال داده‌ها ضروری است
نکات
  • جایگاه ثابت: این نود حتماً باید در ابتدای یک زنجیر قرار گیرد و نمی‌تواند در میانه یا انتهای زنجیر استفاده شود
  • وابستگی اجباری: برای عملکرد صحیح، حتماً نیاز به معرفی حداقل یک نود در بخش next دارد تا داده‌ها به آن منتقل کند
  • عدم دوجهته بودن: برخلاف برخی نودهای لایه ۳، این نود فقط از جهت چپ به راست داده منتقل می‌کند
  • نود Adapter: این نود یک Adapter است

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

گره UdpListener وظایف زیر را انجام می‌دهد که در ادامه دقیق‌تر توضیح داده می‌شوند:

🌐 مدیریت اتصالات UDP

  • سرور UDP: گوش دادن به اتصالات UDP ورودی روی آدرس و پورت مشخص شده
  • شما می‌توانید روی پورت‌هایی که سوکت TCP ساخته بودید سوکت UDP هم داشته باشید
  • مدیریت چرخه حیات: کنترل کامل سوکت‌ها از ایجاد تا بسته شدن و انتقال داده‌ها به گره بعدی
  • انتقال داده: هدایت مطمئن داده‌ها به گره بعدی در زنجیر

🔒 کنترل دسترسی پیشرفته

  • Whitelist: پیاده‌سازی فیلترینگ whitelist برای آدرس‌های IP کلاینت
  • Blacklist: پیاده‌سازی فیلترینگ blacklist برای آدرس‌های IP کلاینت
  • فیلترینگ CIDR: پشتیبانی از فرمت‌های مختلف شبکه مانند /24, /32

⚖️ سیستم تعادل بار (Load Balancing)

  • توزیع هوشمند: پشتیبانی از توزیع اتصالات ورودی بین چندین listener
  • سیستم گروه‌بندی: مدیریت listener ها در گروه‌های تعادل
  • کنترل زمانی: تنظیم فواصل زمانی برای تخصیص مجدد

🚪 پشتیبانی چند پورت

  • پورت منفرد: قابلیت گوش دادن به پورت‌های مجزا
  • محدوده پورت: قابلیت گوش دادن به محدوده‌ای از پورت‌ها
  • عدم استفاده از iptables: این نود متأسفانه برخلاف TcpListener، توانایی استفاده از iptables برای گوش دادن به بازه پورت را ندارد. ولی همچنان توانایی این کار را با ساختن سوکت در بازه مشخص شده دارد. سوکت‌های UDP سبک بوده برخلاف TCP و فشاری به سیستم و رم و پردازنده نمی‌آورد

🏆 سیستم اولویت‌بندی

  • هم‌پوشانی هوشمند: قابلیت وجود چند گوش‌دهنده به یک پورت و تصمیم‌گیری بر اساس اولویت
  • محاسبه اولویت: تعیین listener مناسب بر اساس تنظیمات
  • تصمیم‌گیری پویا: انتخاب بهترین listener بر اساس شرایط

⚙️ راهنمای پیکربندی

📋 ساختار کلی

{
"name": "listener_name",
"type": "UdpListener",
"settings": {
// تنظیمات پایه
"address": "0.0.0.0",
"port": 8443,


// تنظیمات اختیاری
"whitelist": [],
"blacklist": [],
"balance-group": "",
"balance-interval": 60000,
"interface": ""
},
"next": "next_node_name"
}

🔧 پارامترهای ضروری

1. Address (آدرس گوش دادن)

"address": "0.0.0.0"

مقادیر معتبر:

  • "0.0.0.0": گوش دادن به تمام interface ها (IPv4)
  • "127.0.0.1": فقط localhost (IPv4)
  • "::": گوش دادن به تمام interface ها (IPv6)
  • IP خاص: مانند "192.168.1.100"

2. Port (پورت)

پورت منفرد:

"port": 8443

محدوده پورت:

"port": [8000, 9000]

⚠️ نکته مهم: در حالت محدوده پورت، تمام پورت‌های داخل بازه (8000 تا 9000) گوش داده خواهند شد.


🚪 مدیریت چند پورت

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


🏆 سیستم اولویت‌بندی و هم‌پوشانی

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

  • ۲ تا UdpListener به یک پورت گوش بدهند
  • یک UdpListener به یک بازه و یک UdpListener به یک پورت که داخل بازه نود اول بود گوش بدهد

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

🧮 محاسبه اولویت

اولویت پایه UdpListener: ۰

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

  • وجود whitelist: +۱
  • وجود blacklist: +۱

📝 مثال عملی

// Listener با اولویت بالا (اولویت = 1)
{
"name": "high_priority_listener",
"type": "UdpListener",
"settings": {
"port": 443,
"whitelist": ["1.1.1.1/32"]
},
"next": "next_node_name_1"
}

// Listener با اولویت پایین (اولویت = 0)
{
"name": "default_listener",
"type": "UdpListener",
"settings": {
"port": 443
},
"next": "next_node_name_2"
}

نحوه عملکرد: وقتی این تنظیمات داده می‌شود، مثلاً فرض کنیم ۲ تا UdpListener به پورت ۴۴۳ گوش می‌دهند:

  1. کلاینت با IP 1.1.1.1 → به high_priority_listener که whitelist داشت می‌رود
  2. کلاینت با IP دیگر → اگر IP اش 1.1.1.1 نباشد می‌رود به default_listener

نکته مهم: blacklist هم همین‌طوری عمل می‌کند و اگر IP توی blacklist باشد رد می‌شود.


🔒 کنترل دسترسی IP

Whitelist (لیست سفید)

"whitelist": [
"192.168.1.0/24", // کل شبکه محلی
"10.0.0.100/32", // IP خاص
"203.0.113.0/24" // شبکه شرکت
]

Blacklist (لیست سیاه)

"blacklist": [
"192.168.1.100/32", // IP مشکل‌ساز
"10.0.0.0/8", // کل رنج خصوصی
"172.16.0.0/12" // شبکه مشکوک
]

این تنظیمات whitelist و blacklist فقط برای هم‌پوشانی نیستند؛ حتی اگر یک UDP listener هم داشته باشید می‌توانید استفاده کنید و محدودش کنید.


⚖️ سیستم تعادل بار (Load Balancing)

🎯 مفهوم کلی

این نود یک قابلیت load balancing ساده‌ای دارد که شاید بدردتان بخورد، ولی load balancing پیشرفته‌تر در نود router پیاده می‌شود.

شما مثلاً ۲ تا نود UdpListener دارید که پورت‌هاشان هم‌پوشانی دارند و می‌خواهید کاری کنید کاربران بین اینها پخش شوند.

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

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

⚙️ پارامترهای تعادل بار

{
"balance-group": "server_group",
"balance-interval": 60000
}

balance-group

  • نوع: String
  • توضیح: نام گروه تعادل برای مشخص کردن listener هایی که باید در توزیع شرکت کنند
  • مثال: "iran_servers", "europe_group"

balance-interval

  • نوع: Integer (میلی‌ثانیه)
  • پیش‌فرض: 60000 (60 ثانیه)
  • توضیح: مدت زمانی که کلاینت به یک listener خاص متصل می‌ماند قبل از امکان تخصیص مجدد

🔄 منطق عملکرد

  1. اتصال اول: کلاینت به یکی از listener ها تخصیص می‌یابد
  2. قفل زمانی: کلاینت برای مدت balance-interval به همان listener متصل می‌ماند
  3. تخصیص مجدد: پس از گذشت زمان، کلاینت می‌تواند به listener دیگری منتقل شود
  4. تمدید زمان: هر اتصال جدید، تایمر را از ابتدا شروع می‌کند

💡 مثال عملی: دو سرور خارج

یک مثال بخواهم بزنم: فرض کنیم ما یک سرور ایران داریم و دو تا خارج؛ یکی هلند و یکی آلمان و ما می‌خواهیم کاربرانمان را نصفشان را به هلند وصل کنیم و نصفشان به آلمان.

برای اینکار ۲ تا نود UdpListener تعریف می‌کنیم هردو روی پورت ۴۴۳ و سپس برای هرکدام هم یک UdpConnector یا حالا به هر روشی که خواستید وصل شوند به سرور خارجشان.

سپس در تنظیمات این ۲ تا نود UdpListener این مقادیر را اضافه می‌کنیم:

سناریو: یک سرور ایران، دو سرور خارج (هلند و آلمان)

// Listener برای سرور هلند
{
"name": "netherlands_listener",
"type": "UdpListener",
"settings": {
"port": 443,
"balance-group": "europe_servers",
"balance-interval": 300000 // 5 دقیقه
},
"next": "netherlands_connector"
}

// Listener برای سرور آلمان
{
"name": "germany_listener",
"type": "UdpListener",
"settings": {
"port": 443,
"balance-group": "europe_servers",
"balance-interval": 300000 // 5 دقیقه
},
"next": "germany_connector"
}

⏱️ اهمیت balance-interval

balance-interval تعیین می‌کند که مثلاً:

اگر کاربر آمد و بار اول قرار شد به آلمان وصل شود؛ اگر برود ۶۰ ثانیه دیگر بیاید دوباره تصمیم‌گیری شود که به آلمان وصل شود یا هلند.

اگر زودتر از 60 ثانیه از کانفیگش استفاده کند همین‌طور به آلمان وصل می‌شود و ۶۰ ثانیه از اول شروع می‌شود.

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

مشکلات interval کوتاه:

  • تغییر مکرر سرور
  • مشکلات کپچا و احراز هویت
  • عدم ثبات جلسات کاربری

مشکلات interval طولانی:

  • عدم توزیع مناسب بار
  • چسبیدگی کلاینت‌ها به سرور واحد

توصیه: برای کاربرد عمومی، 5-10 دقیقه مناسب است.


🌐 تنظیمات Interface

"interface": "eth0"

📋 کاربرد

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

مثال‌های معمول:

  • "eth0": کارت شبکه اصلی
  • "eth1": کارت شبکه ثانویه
  • "tun0": Interface تونل
  • "br0": Bridge interface

⚠️ نکته: در غیر این صورت کاربردی ندارد. در اکثر موارد نیازی به تنظیم این پارامتر نیست.


🎯 مثال‌های کاربردی

🔹 1. Listener ساده

{
"name": "simple_web_listener",
"type": "UdpListener",
"settings": {
"address": "0.0.0.0",
"port": 8443
},
"next": "web_handler"
}

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

🔹 2. Listener چند پورت با بهینه‌سازی

{
"name": "gaming_multi_port_listener",
"type": "UdpListener",
"settings": {
"address": "0.0.0.0",
"port": [7000, 7100]
},
"next": "game_server_handler"
}

کاربرد: سرور بازی با پورت‌های متعدد و بهینه‌سازی منابع

🔹 3. Load Balancer پیشرفته

// Listener اول
{
"name": "load_balanced_listener_1",
"type": "UdpListener",
"settings": {
"address": "0.0.0.0",
"port": 443,
"balance-group": "web_servers",
"balance-interval": 600000 // 10 دقیقه
},
"next": "server_cluster_1"
}

// Listener دوم
{
"name": "load_balanced_listener_2",
"type": "UdpListener",
"settings": {
"address": "0.0.0.0",
"port": 443,
"balance-group": "web_servers",
"balance-interval": 600000 // 10 دقیقه
},
"next": "server_cluster_2"
}

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


⚠️ نکات مهم و بهترین روش‌ها

🎯 بهینه‌سازی عملکرد

  1. تنظیم مناسب balance-interval: متناسب با نوع کاربرد

🔒 امنیت

  1. محدود کردن address: در صورت امکان از 0.0.0.0 اجتناب کنید
  2. استفاده از whitelist: برای محیط‌های حساس
  3. مانیتورینگ blacklist: برای شناسایی حملات

🏗️ معماری

  1. موقعیت در زنجیر: همیشه در ابتدا
  2. تعریف next node: اجباری برای عملکرد
  3. تفکیک وظایف: از listener های جداگانه برای منطق‌های مختلف

📊 مانیتورینگ

  1. پایش اتصالات: تعداد و کیفیت
  2. بررسی load balancing: توزیع مناسب
  3. کنترل منابع: CPU و RAM در حالت چند پورت