ss در مقابل netstat: کدام دستور پورت در Linux را به‌کار ببریم

از ss استفاده کنید — استاندارد فعلی روی هر توزیع مدرن Linux همین است و netstat آنجا میراث است. در Ubuntu، Fedora و Debian باینری netstat حالا در بسته اختیاری net-tools می‌آید، در حالی که ss جزو iproute2 است و همه‌جا نصب است. ss روی سرورهای شلوغ هم سریع‌تر است، چون آمار سوکت‌ها را مستقیم از کرنل می‌خواند و فایل‌به‌فایل از proc/net رد نمی‌شود. نکته‌اش سینتکس است: -tulpn همه‌جا یک معنا ندارد، پس این راهنما نگاشت دقیق فلگ‌ها، دستورهایی که حفظ‌کردنشان می‌ارزد و پاسخ سؤال‌هایی که وسط حادثه، ساعت 2 بامداد، پیش می‌آیند را می‌دهد.

آیا netstat منسوخ شده است؟

در Linux، عملاً بله. بسته net-tools — که netstat و ifconfig و route را دارد — سال‌هاست ویژگی‌های جدید کرنل را تعقیب نکرده و روی هیچ توزیع اصلی به‌صورت پیش‌فرض نصب نمی‌شود. هنوز وجود دارد، هنوز اجرا می‌شود و چیزی برای حذف‌کردن هم نیست، اما ویژگی‌های جدید فقط در iproute2 (بسته پشت ss و ip) می‌آیند.

سه پیامد عملی:

1. در نصب‌های تازه نیست. یک سرور Ubuntu 24.04 یا Fedora با تنظیم پیش‌فرض تا وقتی net-tools را دستی نصب نکنید netstat ندارد. برای همین است که این‌همه آدم معادل netstat را جست‌وجو می‌کند — باینری به‌سادگی غایب است.
2. اطلاعات سوکتِ مدرن ندارد. netstat از ویژگی‌هایی مثل TCP fast open، آمار سوکت در سطح subflow و اتصال سوکت به cgroup قدیمی‌تر است. ss این‌ها را بومی گزارش می‌کند.
3. استثنای Windows. در Windows، netstat زنده و سرحال است — netstat -ano همان روش استاندارد نگاشت PID به پورتِ شنونده است. داستان منسوخ‌بودن فقط مال Linux است.

دستور ss در Linux چیست؟

ss یعنی socket statistics. نمای کرنل از همه سوکت‌های TCP، UDP و Unix را می‌ریزد بیرون: وضعیت، آدرس‌ها، پورت‌ها، پروسه‌ها، تایمرها و عمق صف‌ها. شکل کارگرِ آن چنین است:

# Everything listening, with the owning process
sudo ss -tulpn

فلگ‌به‌فلگ یعنی: TCP (-t)، UDP (-u)، فقط سوکت‌های شنونده (-l)، نمایش پروسه‌ها (-p)، خروجی عددی بدون lookup دی‌ان‌اس (-n). sudo برای -p مهم است: بدون root پورت‌ها را می‌بینید، اما برای سوکت‌هایی که مال شما نیستند نام پروسه نمی‌گیرید.

دو one-liner دیگر که بیشتر کارها را می‌بندند:

# All established connections to/from port 443, with processes
sudo ss -tnp 'sport = :443 or dport = :443'

# Summary table: how many sockets in each state
ss -s

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

چگونه بفهمیم کدام پروسه از یک پورت استفاده می‌کند؟

شایع‌ترین دلیل سراغ‌دادن به هرکدام از این دو ابزار همین است. با ss:

sudo ss -ltnp 'sport = :8080'

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

State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN  0       511     *:8080              *:*               users:(("node",pid=214113,fd=18))

فیلد users:(...) نام پروسه و PID را مستقیم می‌دهد — بدون دستور دوم. اگر پورت اشغال است ولی پروسه‌ای نشان داده نمی‌شود، معمولاً به سوکتی نگاه می‌کنید که شبکه‌namespace دیگری (یک کانتینر) نگهش داشته. از روی host دستور sudo ss -ltnp را بزنید و دنبال پورتی بگردید که ستون پروسه‌اش خالی است، بعد با docker ps تطبیقش دهید یا با nsenter وارد namespace کانتینر شوید.

ابزار اختصاصی می‌پسندید؟ sudo lsof -i :8080 -sTCP:LISTEN همان کار را می‌کند و روی macOS و بیشتر BSDها هم عیناً کار می‌کند — برای همین است که در runbookها زنده مانده. اما در Linux، ss از قبل آنجاست.

تفاوت‌های ss و netstat چیست؟

یک کار، لوله‌کشی متفاوت: netstat مسیر proc/net/tcp را در فضای کاربر می‌خواند، در حالی که ss با netlink مستقیم از کرنل می‌پرسد — به همین دلیل ss روی سروری با 50 هزار سوکت باز در حد میلی‌ثانیه جواب می‌دهد و netstat نه. در کار روزمره، تفاوت در فلگ‌هاست. این نگاشتی است که می‌ارزد به مانیتورتان بچسبانید:

شما می‌خواهید	netstat	ss
پورت‌های TCP شنونده + پروسه	netstat -tlpn	ss -tlpn
همه اتصال‌های TCP + UDP	netstat -tulpna	ss -tulpna
جدول مسیریابی	netstat -r	ip route
آمار اینترفیس‌ها	netstat -i	ip -s link
خلاصه سوکت‌های کرنل	—	ss -s
فیلتر بر اساس پورت داخل کرنل	—	ss -tnp 'sport = :22'

دقت کنید دو سطر اول عین هم‌اند: شانس آورده‌اند و فلگ‌های کوتاه ss برای حالت‌های رایج با netstat می‌خوانند، پس حافظه عضلانی عمدتاً از این جابه‌جایی جان سالم به در می‌برد. سطرهای پایانی جایی‌اند که netstat جوابی ندارد — کارهای مسیریابی و اینترفیس به دستور ip رفته و سطرهای خلاصه/فیلتر فقط در ss وجود دارند.

چه زمانی هنوز باید از netstat استفاده کرد؟

دو مورد صادقانه. اول، قابل‌حمل بودن: روی ناوگانی مخلوط از باکس‌های Linux، AIX یا BSDهای قدیمی، netstat تنها سینتکسی است که همه‌جا حاضر است. دوم، پیوستگی حافظه عضلانی در runbookهای قدیمی — اگر runbook می‌گوید netstat -tlpn و باکس net-tools دارد، هنوز درست کار می‌کند.

غیر از این، پیش‌فرض را ss بگذارید و runbook را به‌روز کنید. همراه مفید موقع بازنویسی آن runbookها روی سرور، چیت‌شیت journalctl است — با بررسی پورت‌ها هنگام عیب‌یابی سرویسی که استارت نمی‌خورد جفت تنگاتنگی می‌سازند: چیت‌شیت journalctl.

چرا دستور ss پیدا نمی‌شود؟

چون یا روی توزیع خیلی قدیمی هستید (قبل از 2007، پیش از استاندارد شدن iproute2) یا — به‌مراتب محتمل‌تر — اصلاً روی Linux نیستید. ss دستور macOS نیست؛ macOS از lsof و netstat دارد ولی ss ندارد. برای BSDها هم عمدتاً همین. در Windows از netstat -ano یا Get-NetTCPConnection در PowerShell استفاده کنید.

اگر واقعاً روی Linux هستید و ss غایب است، iproute2 را نصب کنید:

sudo apt install iproute2    # Debian/Ubuntu
sudo dnf install iproute2    # Fedora/RHEL

پاسخ 30 ثانیه‌ای

روی Linux، هر بار ss به‌جای netstat: از قبل نصب است، سریع‌تر است و داخل کرنل فیلتر می‌کند. netstat -tlpn می‌شود ss -tlpn، شکار پروسه می‌شود sudo ss -ltnp 'sport = :PORT' و جدول‌های مسیریابی حالا سهم ip route هستند. netstat را برای اسکریپت‌های چندسکویی و حافظه عضلانی قدیمی نگه دارید؛ این صفحه را هم برای نگاشت فلگ‌ها.