Why Linux Splits Socket Listening into bind and listen: Kernel Design Deep Dive

1. Issue

High-level languages like Go ( net.Listen("tcp", ":8080")) and frameworks like Netty ( b.bind(port)) combine socket listening into a single call, but Linux requires two distinct system calls: bind and listen. This article investigates why.

2. Dialogue with AI

2.1 Question

Why does Linux split listening into bind and listen when higher-level APIs combine them? Doesn't this increase API complexity?

2.2 Answer

The separation stems from layered design + historical baggage + flexibility .

bind and listen Are Fundamentally Different

bind

: merely "claims an address" — associates a socket with a local IP+port. It does not indicate the socket will accept connections. listen: changes the socket's "role" — transitions from "active/undefined" to "passive (server)". The kernel then initializes two critical queues:

Half-connection queue (SYN queue)

Full-connection queue (accept queue)

Only after listen does the socket become a true listening socket usable with accept().

Why Not a Single listen(addr) ?

In the 1980s, the Socket API was designed as a universal communication interface supporting not just TCP servers but UDP, Unix domain sockets, RAW sockets, and custom protocols. The designers wanted clear, single-responsibility primitives: socket() → create endpoint bind() → specify address connect() → active connection listen() → passive acceptance

From the kernel perspective, this isn't complexity but atomicity: each syscall does one thing; composition is left to users; higher-level languages/frameworks provide ergonomic wrappers. This layered philosophy enables:

Kernel: complete capabilities, clear primitives
↓
Language: sensible defaults, moderate abstraction
↓
Framework: extreme usability, business-oriented

If Linux had started with listen(addr), UDP, UDS, and custom protocols would be constrained.

2.3 Reflection

Linux splits for maximal capability; Go/Netty merge for optimal experience.

2.4 Question

What kernel operations occur during TCP bind and listen, and what exceptions can arise?

2.5 Answer

TCP bind Core Actions

Address validity checks: IP belongs to host (or INADDR_ANY), port range valid, IPv4/IPv6 family match, SO_REUSEADDR/SO_REUSEPORT settings.

Port occupancy checks: existing BIND sockets, TIME_WAIT sockets, already-connected (active) sockets.

Auto port allocation if port=0: pick from ip_local_port_range, insert into TCP bind hash table.

After bind, TCP socket state remains TCP_CLOSE.

What listen Does for TCP

TCP state transition: TCP_CLOSE → TCP_LISTEN.

Initialize two key queues: half-connection (SYN) queue and full-connection (accept) queue — the latter stores completed three-way handshakes; accept() pulls from here.

Register listening port into listen hash table so incoming SYNs can locate this socket.

Exception Summary

bind phase errors: EADDRINUSE — Port occupied EADDRNOTAVAIL — IP not local EACCES — Insufficient permission EINVAL — Invalid address

listen phase errors: EINVAL — Socket type doesn't support listen EOPNOTSUPP — Non-TCP protocol EBADF — fd not a socket

2.6 Reflection

Now let's experiment with these exception scenarios.

3. Experiments

Full code at Gitee repository https://gitee.com/shichaoyuan/learn-linux-with-ai.

3.1 bind Port Conflict

Two processes attempt bind on port 8888; second fails with EADDRINUSE (errno=98).

3.2 listen Without bind

Calling listen without prior bind succeeds on Linux — the kernel implicitly binds to a random port (e.g., 0.0.0.0:31751).

3.3 backlog Overflow

Set backlog=3 (system somaxconn=16384, so effective backlog=3). Server listens but never calls accept(). Using nc to create connections: 4th connection succeeds, 5th times out. tcpdump shows client retransmitting SYN with no server response. ss -ltnp shows LISTEN queue: Recv-Q=4, Send-Q=3 — queue length 3 but 4 connections present.

Questions raised:

Queue length is 3, where is the 4th connection?

When full-connection queue is full, server stops responding to SYN.

4. Kernel Implementation (Linux 5.15.198)

Analyzing net/ and include/net/ to answer the experimental questions.

4.1 listen Call Chain

listen(sockfd, backlog)
  └─> SYSCALL_DEFINE2(listen)
      └─> __sys_listen() [net/socket.c:1749]
          └─> sock->ops->listen()
              └─> inet_listen() [net/ipv4/af_inet.c:196]
                  └─> inet_csk_listen_start() [net/ipv4/inet_connection_sock.c:1089]
                      └─> sk->sk_prot->get_port() // if no bind, allocate port
                      └─> sk->sk_prot->hash()     // insert into hash table

Port Allocation Strategy (net/ipv4/inet_connection_sock.c:194-276)

Use prandom_u32() to pick random start offset.

Force odd ports first (avoid collision with connect 's preference for even ports).

Scan upward from random start with step 2.

If odd scan fails, try even ports.

For sockets with SO_REUSEADDR, first attempt half the port range.

Port range: /proc/sys/net/ipv4/ip_local_port_range.

SYN Packet Handling Call Chain

SYN arrives
  └─> tcp_v4_rcv() [net/ipv4/tcp_ipv4.c]
      └─> tcp_v4_do_rcv()
          └─> tcp_rcv_state_process()
              └─> tcp_v4_conn_request() [net/ipv4/tcp_ipv4.c:1540]
                  └─> tcp_conn_request() [net/ipv4/tcp_input.c:6948]
                      ├─> Check 1: inet_csk_reqsk_queue_is_full() // half-connection queue
                      ├─> Check 2: sk_acceptq_is_full()         // full-connection queue
                      ├─> inet_reqsk_alloc() // allocate request_sock
                      └─> af_ops->send_synack() // send SYN-ACK

Why backlog=3 Accepts 4 Connections

The full-connection queue full check uses > not >=:

static inline bool sk_acceptq_is_full(const struct sock *sk) {
    return READ_ONCE(sk->sk_ack_backlog) > READ_ONCE(sk->sk_max_ack_backlog);
}

With backlog=3, sk_max_ack_backlog = 3.

Queue full condition: sk_ack_backlog > 3.

Thus sk_ack_backlog can be 0,1,2,3 — four connections total.

Why Full Queue Stops Responding to SYN

In tcp_conn_request(), if sk_acceptq_is_full(sk) true, kernel increments LINUX_MIB_LISTENOVERFLOWS and jumps to drop — silently discards SYN without sending SYN-ACK.

Final ACK Handling Call Chain

ACK arrives (completes handshake)
  └─> tcp_v4_rcv() [net/ipv4/tcp_ipv4.c]
      └─> tcp_v4_do_rcv()
          └─> tcp_check_req() [net/ipv4/tcp_minisocks.c:656]
              └─> syn_recv_sock() [actually tcp_v4_syn_recv_sock()]
                  ├─> Check: sk_acceptq_is_full() // re-check full queue
                  │   └─> If full, return NULL → listen_overflow
                  ├─> tcp_create_openreq_child() // create child socket
                  └─> inet_csk_reqsk_queue_add() [net/ipv4/inet_connection_sock.c:1150]
                      └─> sk_acceptq_added() // sk_ack_backlog++

[Queue full handling] listen_overflow branch:
  └─> Check sysctl_tcp_abort_on_overflow
      ├─> = 0 (default): silently drop ACK, set acked=1
      │   └─> Client times out and retransmits
      └─> = 1: send RST to reject
          └─> req->rsk_ops->send_reset()
              └─> Client immediately gets ECONNREFUSED

Code snippet for default behavior:

if (!READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_abort_on_overflow)) {
    inet_rsk(req)->acked = 1;
    return NULL; // silent drop, no RST
}

Behavior Summary

Initial SYN: always silently dropped when full-connection queue full, no SYN-ACK sent.

Final ACK: depends on tcp_abort_on_overflow: =0 (default): silent drop, client times out. =1: send RST, client fails immediately with ECONNREFUSED.

This protects against queue overflow; default is friendlier to traffic bursts.

5. Summary

Through AI dialogue, I grasped the elegant design of bind / listen separation. Experiments revealed kernel handling details. Two similarly named options — SO_REUSEADDR and SO_REUSEPORT — remain unclear; will discuss next time. 1. https://gitee.com/shichaoyuan/learn-linux-with-ai