ss vs netstat: Aling Linux Port Command ang Gagamitin

Gamitin mo ang ss — ito na ang kasalukuyang standard sa bawat modernong Linux distro, at legacy na ang netstat doon. Sa Ubuntu, Fedora at Debian, nasa optional na net-tools package na lang ang netstat binary, samantalang built in sa iproute2 ang ss at naka-install kahit saan. Mas mabilis din ang ss sa mga abalang server dahil diretso nitong binabasa ang socket statistics mula sa kernel imbes na lakarin ang _/proc_ file-file. Ang huli ay syntax: hindi pareho ang ibig sabihin ng -tulpn sa lahat ng dako, kaya ibinibigay ng guide na ito ang eksaktong flag mapping, ang mga command na worth memorahin, at ang mga sagot sa mga tanong na sumusulpot habang nasa gitna ka ng incident alas-dos ng madaling-araw.

Deprecated na ba ang netstat?

Sa Linux, praktikal na oo. Ang net-tools package — na naglalaman ng netstat, ifconfig at route — taon nang hindi sumusubaybay sa modernong kernel features at hindi na naka-install by default sa kahit anong pangunahing distribusyon. Buhay pa rin ito, tumatakbo pa rin, at walang buburahin, pero ang mga bagong feature ay dumadating na lang sa iproute2 (ang package sa likod ng ss at ip).

Tatlong praktikal na epekto:

1. Nawawala sa mga bagong install. Ang default na Ubuntu 24.04 o Fedora server ay walang netstat hangga’t hindi mo manwal na i-install ang net-tools. Kaya damang-dama ng marami ang paghahanap ng netstat equivalent — wala na talaga ang binary.
2. Walang modernong socket info. Mas matanda ang netstat kaysa mga feature tulad ng TCP fast open, subflow-level socket stats at cgroup socket attribution. Native na iniulat ng ss ang mga ito.
3. Ang Windows exception. Sa Windows, buhay na buhay ang netstat — netstat -ano pa rin ang standard na paraan para itugma ang PID sa listening port doon. Sa Linux lang ang kwento ng deprecation.

Ano ang ss command sa Linux?

Ang ss ay “socket statistics”. Binubuhusan nito ang paningin ng kernel sa bawat TCP, UDP at Unix socket: state, addresses, ports, processes, timers at queue depths. Ang workhorse form:

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

Flag-flag, ganito ang basa: TCP (-t), UDP (-u), listening sockets lang (-l), ipakita ang processes (-p), numeric output — walang DNS lookups (-n). Mahalaga ang sudo para sa -p: kapag walang root, nakikita mo ang ports pero walang process names sa mga sockets na hindi sa’yo.

Dalawang one-liner pa na sumasakop sa kalakhan ng trabaho:

# 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

Tunay na upgrade ang filter syntax na iyan kaysa grep-and-pray na paraan ng netstat — sa loob ng kernel ito tumatakbo, kaya eksakto ito at hindi text-match lang.

Paano mo titingnan kung aling process ang gumagamit ng port?

Ito ang isang pinakakaraniwang dahilan para humawak ng kahit alin sa dalawang tool. Gamit ang ss:

sudo ss -ltnp 'sport = :8080'

Halimbawang output sa machine na may dev server:

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

Ang users:(...) field ang direktang nagbibigay sa’yo ng process name at PID — walang pangalawang command. Kung abala ang port pero walang process na lumalabas, karaniwang socket na hawak ng ibang network namespace (isang container) ang tinitingnan mo. Mula sa host, i-run ang sudo ss -ltnp at hanapin ang port na walang laman ang process column, tapos itugma mo gamit ang docker ps o nsenter papasok sa namespace ng container.

May prefer na dedicated tool? Gagawin din ng sudo lsof -i :8080 -sTCP:LISTEN ang same trabaho at pareho itong gumagana sa macOS at kalakhan ng BSDs, kaya nananatili ito sa mga runbook. Sa Linux nga lang, nandiyan na ang ss.

Ano ang mga pinagkaiba ng ss at netstat?

Same trabaho, magkaibang plumbing: kinakalkusa ng netstat ang _proc/net/tcp_ sa userspace, samantalang gumagamit ng netlink ang ss para direkang magtanong sa kernel — kaya milliseconds lang ang balikan ng ss sa server na may 50k open sockets at hindi ang netstat. Pang-araw-araw, nasa flags ang pinagkaiba. Ito ang mapping na worth idikit sa monitor mo:

Gusto mo	netstat	ss
Listening TCP ports + process	netstat -tlpn	ss -tlpn
Lahat ng TCP + UDP connections	netstat -tulpna	ss -tulpna
Routing table	netstat -r	ip route
Interface statistics	netstat -i	ip -s link
Kernel socket summary	—	ss -s
Mag-filter kada port sa kernel	—	ss -tnp 'sport = :22'

Pansinin: identical ang unang dalawang rows — sa swerte, magkatugma ang short flags ng ss sa netstat para sa common cases, kaya halos nakaligtas ang muscle memory sa paglipat. Ang mga pinakababang rows ang lugar na walang sagot ang netstat — lumipat sa ip command ang mga routing at interface na trabaho, at sa ss lang umiiral ang summary/filter rows.

Kailan pa dapat gamitin ang netstat?

Dalawang tapat na kaso. Una, portability: sa halo-halong fleet ng Linux, AIX o mas lumang BSD boxes, ang netstat ang solong syntax na nasa lahat ng dako. Pangalawa, muscle-memory continuity sa mga lumang runbook — kung netstat -tlpn ang nakasulat sa runbook at may net-tools ang box, gumagana pa rin nang maayos.

Kung hindi, default sa ss at i-update ang runbook. Kapaki-pakinabang na kasama kapag nagre-rewrite ka ng mga runbook sa isang server ang journalctl cheat sheet, na magandang kapares ng port checks kapag nagdi-diagnose ka ng service na ayaw mag-start: journalctl cheat sheet.

Bakit command not found ang ss?

Dahil nasa napakalumang distro ka (pre-2007 era, bago pa standard ang iproute2) o — mas malamang — hindi ka sa Linux. Hindi ss ang macOS command; may lsof at netstat ang macOS pero walang ss. Same sa mga BSDs, kalakhan. Sa Windows, gamitin ang netstat -ano o ang Get-NetTCPConnection ng PowerShell.

Kung talagang nasa Linux ka at kulang ang ss, i-install mo ang iproute2:

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

Ang sagot sa 30 segundo

ss laban sa netstat sa Linux, tuwing: preinstalled ito, mas mabilis, at kayang mag-filter sa loob ng kernel. Ang netstat -tlpn ay nagiging ss -tlpn, ang paghahanap ng process ay nagiging sudo ss -ltnp 'sport = :PORT', at sa ip route na naka-assign ang mga routing table ngayon. Panatilihin ang netstat para sa cross-platform scripts at lumang muscle memory; panatilihin ang page na ito para sa flag mapping.