Linux Socket编程中，服务端监听到连接建立的标准化流程是：先socket创建套接字，再setsockopt设置端口复用，接着bind绑定IP和端口，然后listen启动监听，最后accept阻塞获取新连接；客户端则通过socket创建套接字后直接connect发起三次握手。
Linux Socket 编程中，从监听端口到连接建立是一套标准化、分阶段的流程，核心在于服务端主动“守候”，客户端主动“叩门”。关键不是写多少代码，而是每一步的语义和依赖关系是否清晰——比如 bind 必须在 listen 之前，listen 又必须在 accept 之前，顺序错一步，连接就无法建立。
服务端：如何正确监听一个端口
监听端口不是简单地“打开一个门”，而是让内核把该端口纳入管理，并准备排队处理连接请求。
-
先创建套接字：用
socket(AF_INET, SOCK_STREAM, 0)获取一个 TCP 类型的文件描述符，这是后续所有操作的基础 -
设置端口复用（可选但推荐）：调用
setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt))，避免程序重启时因 TIME_WAIT 状态导致 “Address already in use” 错误 -
绑定地址与端口：填充
struct sockaddr_in，指定sin_addr.s_addr = INADDR_ANY（监听所有网卡）和目标端口号（如 8080），再执行bind()。若绑定失败，常见原因是端口被占用或权限不足（1024 以下端口需 root） -
启动监听：调用
listen(sockfd, 5)，其中backlog=5表示已完成三次握手、等待accept()处理的连接队列长度上限。超出此数的新连接会被内核拒绝（客户端收到ECONNREFUSED）
客户端：怎样发起一次有效连接
客户端不监听，只主动寻找服务端并完成三次握手。它的动作更轻量，但对地址信息准确性要求更高。
-
同样先创建套接字：和服务端一样调用
socket()，类型一致（SOCK_STREAM） -
直接 connect：填好服务端 IP 和端口后，调用
connect()。该调用会触发 SYN 包发送，阻塞直到收到 SYN-ACK 并发出 ACK（即连接建立完成），或超时/失败返回 -
错误需及时判断：若
connect()返回 -1，检查errno——ECONNREFUSED表示服务端未运行或未 listen；ETIMEDOUT表示网络不可达或防火墙拦截；EINPROGRESS则出现在非阻塞模式下，需配合select或poll等待结果
连接建立后的状态确认
服务端调用 accept() 才真正拿到一个“已连接的套接字”，它和原始监听套接字是两个独立的 fd。
-
accept()返回一个新的文件描述符，代表与特定客户端的专属通信通道；原监听 fd 仍保持不变，继续接受新连接 - 成功返回时，
accept()会把客户端地址信息写入传入的sockaddr*参数，可用于日志记录或访问控制 - 如果服务端未做任何读写操作，仅靠
accept()成功不能保证应用层通信就绪——还需确保双方都准备好收发数据（例如客户端调用write()后，服务端才能read()到）
常见卡点与绕过思路
实际调试中，90% 的连接失败问题集中在几个固定环节：
- 服务端 bind 失败 → 检查端口是否被占用（
netstat -tuln | grep :端口号）、是否用了INADDR_LOOPBACK却试图从外部连接 - 客户端 connect 超时 → 确认服务端 IP 可达（
ping）、端口开放（telnet IP 端口或nc -zv IP 端口）、本地防火墙（iptables或ufw）是否放行 - accept 一直阻塞 → 正常行为，说明没有客户端连入；若想非阻塞，需提前用
fcntl(sockfd, F_SETFL, O_NONBLOCK) - 连接建立后立刻断开 → 查看是否服务端或客户端在
accept()或connect()后没做任何 I/O 就直接close()，造成 RST 包发送
