netstat and ss (connection listing) in Linux CLI - Time & Space Complexity

Time Complexity: netstat and ss (connection listing)

O(n)

Understanding Time Complexity

When we use commands like netstat or ss to list network connections, the time it takes depends on how many connections exist.

We want to understand how the command's work grows as the number of connections increases.

Scenario Under Consideration

Analyze the time complexity of the following command usage.

ss -t -a
# Lists all TCP connections

netstat -an
# Lists all connections and listening ports
    

These commands gather and display all current network connections and listening sockets.

Identify Repeating Operations

Both commands scan through the system's network connection table.

• Primary operation: Iterating over each active network connection entry.
• How many times: Once for each connection present in the system.

How Execution Grows With Input

As the number of connections grows, the commands take longer because they check each connection once.

Input Size (n)	Approx. Operations
10	About 10 connection checks
100	About 100 connection checks
1000	About 1000 connection checks

Pattern observation: The work grows directly with the number of connections.

Final Time Complexity

Time Complexity: O(n)

This means the time to list connections grows in a straight line with how many connections there are.

Common Mistake

[X] Wrong: "The commands run in the same time no matter how many connections exist."

[OK] Correct: The commands must check each connection, so more connections mean more work and longer time.

Interview Connect

Understanding how command execution time grows with data size helps you explain system behavior clearly and shows you think about efficiency in real tasks.

Self-Check

"What if the commands filtered connections by a specific port before listing? How would that affect the time complexity?"

Practice

1. What is the primary purpose of the netstat and ss commands in Linux?

easy

A. To list installed software packages

B. To edit network configuration files

C. To monitor CPU usage

D. To display active and listening network connections

Solution

1. Step 1: Understand command purpose

   Both netstat and ss are used to show network connections and ports.

2. Step 2: Identify correct function

   They do not edit files, monitor CPU, or list software; they show network status.

3. Final Answer:

   To display active and listening network connections -> Option D

4. Quick Check:

   Command purpose = Display connections [OK]

Hint: Remember: netstat and ss show network connections [OK]

Common Mistakes:

• Confusing netstat/ss with file editors
• Thinking they monitor CPU or memory
• Assuming they list installed software

2. Which of the following is the correct syntax to list all listening TCP and UDP ports using ss?

easy

A. ss -tuln

B. ss -a

C. ss --listening

D. ss -x

Solution

1. Step 1: Understand option meanings

   The options -tuln mean TCP (-t), UDP (-u), Listening (-l), Numeric (-n).

2. Step 2: Match options to goal

   To list listening TCP and UDP ports, ss -tuln is the correct syntax.

3. Final Answer:

   ss -tuln -> Option A

4. Quick Check:

   Listening TCP/UDP = ss -tuln [OK]

Hint: Use -tuln with ss to see listening TCP/UDP ports [OK]

Common Mistakes:

• Using -a shows all but not filtered to listening
• Assuming --listening is a valid option
• Using -x which is for Unix sockets, not TCP/UDP

3. What will be the output of the command netstat -tuln | grep ':22' if the SSH service is running and listening on port 22?

medium

A. No output, because port 22 is not shown

B. An error message about invalid syntax

C. A line showing TCP port 22 in LISTEN state

D. A list of all UDP ports except 22

Solution

1. Step 1: Understand command components

   netstat -tuln lists TCP and UDP ports numerically and listening; grep ':22' filters lines with ':22'.

2. Step 2: Interpret output if SSH runs

   If SSH listens on port 22, output will include a line showing TCP port 22 in LISTEN state.

3. Final Answer:

   A line showing TCP port 22 in LISTEN state -> Option C

4. Quick Check:

   SSH on port 22 = netstat output with :22 line [OK]

Hint: grep ':22' filters netstat output for SSH port [OK]

Common Mistakes:

• Expecting no output if port is open
• Thinking command syntax is invalid
• Confusing UDP ports with TCP port 22

4. You run ss -tuln but get no output. What is the most likely reason?

medium

A. The system has no active or listening TCP/UDP ports

B. The command syntax is incorrect

C. No network interfaces are active

D. You forgot to run the command as root or with sudo

Solution

1. Step 1: Check command correctness

   ss -tuln syntax is correct and should show listening ports if any exist.

2. Step 2: Consider system state

   The most likely reason for no output is no TCP/UDP ports are listening, common in minimal containers or systems without bound services. Permissions are not required for ss -tuln.

3. Final Answer:

   The system has no active or listening TCP/UDP ports -> Option A

4. Quick Check:

   No output = no listening TCP/UDP [OK]

Hint: No ss -tuln output means no listening TCP/UDP ports [OK]

Common Mistakes:

• Assuming syntax error when command is correct
• Thinking no active interfaces means no output
• Thinking need root or sudo

5. You want to write a script that checks if port 80 is listening using ss. Which command correctly returns a non-empty output only if port 80 is listening?

hard

A. ss -tuln | grep ':80$'

B. ss -tuln | grep ':80 '

C. ss -tuln | grep ':80'

D. ss -tuln | grep '80'

Solution

1. Step 1: Understand port matching in grep

   Port 80 appears as IP:80[spaces] in ss output before peer address.

2. Step 2: Compare options

   ':80 ' matches exactly :80 (port 80 + space), avoids partial matches like :8080. ':80$' fails (not end-of-line). ':80' and '80' match substrings.

3. Final Answer:

   ss -tuln | grep ':80 ' -> Option B

4. Quick Check:

   Exact port match with ':80 ' [OK]

Hint: Use grep ':80 ' to match port 80 exactly [OK]

Common Mistakes:

• Using grep ':80$' misses because port not at line end
• Using grep ':80' matches ports like 8080
• Using grep '80' matches unrelated numbers