Socket 是什么？TCP socket 的通信流程是怎样的？

简化版

Socket（套接字）是操作系统提供给应用程序的网络编程接口，是应用层和传输层（TCP/UDP）之间的一层抽象——你不用管底层协议细节，通过 socket 的 API（bind/listen/accept/connect/read/write）就能收发网络数据。一个 TCP 连接由四元组（源 IP、源端口、目的 IP、目的端口） 唯一标识。TCP 服务端的典型流程是 socket → bind → listen → accept → 读写 → close。

详细版

Socket 是什么：它把复杂的 TCP/IP 协议栈封装成一组简单的 API，让应用程序像「读写文件」一样收发网络数据（Unix 里 socket 也是一种文件描述符 fd）。它标识了「谁和谁在通信」——一个连接靠四元组区分：{源IP:源端口, 目的IP:目的端口}。

TCP 通信流程：

服务端                          客户端
socket()   创建套接字            socket()   创建套接字
bind()     绑定 IP:端口
listen()   开始监听
accept()   阻塞等待连接  ◄────── connect()  发起连接（触发三次握手）
   │  （返回一个新的已连接 socket）
read/write 收发数据      ◄─────► write/read 收发数据
close()    关闭                  close()    关闭（触发四次挥手）

服务端：socket() 建套接字 → bind() 绑定地址端口 → listen() 转为监听状态 → accept() 阻塞等待并接受客户端连接（返回一个新的已连接 socket 专门和这个客户端通信）→ read/write 收发 → close()；
客户端：socket() → connect()（触发三次握手）→ read/write → close()。

完整版教学

一、Socket 的定位：网络编程的「门面」

要理解 socket，先看它在哪一层。TCP/IP 协议栈很复杂（分层、握手、可靠传输……），但应用开发者不想、也不该关心这些细节。Socket 就是操作系统在「应用层」和「传输层」之间提供的一层抽象接口：

向上，它给应用一组简单的 API，收发数据像操作文件一样简单；
向下，它对接内核的 TCP/UDP 协议栈，握手、可靠传输、分段这些脏活累活由内核做。

所以 socket 本身不是协议，而是「使用协议的编程接口/门面」。在 Unix 哲学里「一切皆文件」，socket 也被表示成一个文件描述符（fd），可以用类似读写文件的方式操作——这也是为什么 IO 多路复用（select/epoll）能统一管理 socket，因为它们都是 fd（详见「五种 IO 模型」那道题）。

二、四元组：如何区分「谁和谁在通信」

一台服务器可能同时和成千上万个客户端连接，内核怎么区分这些连接、把数据准确送到对应的连接上？靠四元组：

连接 = {源 IP, 源端口, 目的 IP, 目的端口}

即使很多客户端都连到服务器的同一个端口（如 80），因为它们的源 IP + 源端口不同，四元组就不同，内核据此区分每一条连接。（加上协议类型 TCP/UDP 就是五元组。）

这也解释了一个高频问题：一个服务器端口能支撑多少连接？ 理论上受四元组组合数限制——服务器 IP:端口固定，变量是客户端的 IP + 端口，组合极大，所以一个监听端口能接受海量连接（真正的瓶颈是内存、文件描述符数量等，不是端口数）。

三、服务端流程为什么是这几步

服务端的 socket → bind → listen → accept 每一步都有明确职责：

socket()：创建一个套接字（拿到一个 fd），指定用 TCP 还是 UDP；
bind()：把套接字绑定到具体的 IP + 端口——告诉系统「我要在这个端口提供服务」。（客户端通常不用 bind，端口由系统临时分配。）
listen()：把套接字转成监听状态，并设置连接队列的大小（就是「半连接队列 / 全连接队列」，详见「TCP 半连接和全连接队列」那道题）；
accept()：从全连接队列里取出一个已完成三次握手的连接，返回一个新的 socket——注意：监听 socket 和已连接 socket 是两个不同的 socket。监听 socket 专门负责接受新连接，每个已连接 socket 专门和一个客户端通信。

四、accept 返回新 socket：一个关键细节

初学者常困惑：为什么 accept() 要返回一个新的 socket？

因为服务器要同时服务多个客户端：

监听 socket（listen fd）：始终在 listen，负责「迎接新客人」——不断 accept 新连接；
已连接 socket（connection fd）：每 accept 一个客户端就产生一个，专门和这个客户端读写数据。

这样监听和通信分离：一个 fd 管接客，N 个 fd 管和各自客户端聊天。这也是各种网络模型（多线程、IO 多路复用、Reactor）的基础——如何高效地管理这一个监听 fd 和成千上万个连接 fd，就是网络编程的核心命题（详见「Reactor 模型」「C10K 问题」那两道题）。

五、socket 和 TCP 握手/挥手的关系

socket 的 API 调用背后，触发的正是 TCP 的连接管理：

客户端 connect() → 触发三次握手（详见「TCP 三次握手」那道题），成功后连接进入服务端的全连接队列；
服务端 accept() → 从全连接队列取走这个已建立的连接；
任一方 close() → 触发四次挥手（详见「四次挥手」那道题）。

所以 socket API 是「面子」，TCP 的握手挥手是「里子」——你调 connect，内核替你完成三次握手。

六、常见误区与追问

考点	正确口径
服务端	socket、bind、listen、accept、read/write、close
客户端	socket、connect、read/write、close
本质	通过四元组/五元组标识连接，内核维护收发缓冲区

server: socket -> bind -> listen -> accept -> recv/send
client: socket -> connect -> send/recv
TCP connection = srcIP:srcPort + dstIP:dstPort

Socket API 是应用和内核网络协议栈的边界，connect/accept 成功不等于业务协议已经完成。

误区：listen 后客户端就已经连接到应用了。 listen 只是进入监听状态，真正连接要经过 TCP 握手并由 accept 取出。
误区：send 成功表示对方应用已经处理。 send 成功通常只表示数据进入本机内核缓冲区，不代表远端业务已读。
误区：TCP socket 天然按消息边界接收。 TCP 是字节流，没有消息边界，应用协议要自己拆包粘包。
追问：bind 必须由客户端调用吗？ 客户端通常不显式 bind，系统自动分配本地临时端口。
追问：accept 返回的 socket 和监听 socket 区别是什么？ 监听 socket 继续接新连接，accept 返回的连接 socket 用于和某个客户端通信。
追问：为什么 close 可能不立刻发完数据？ 内核发送缓冲区、SO_LINGER、半关闭和 TCP 挥手都会影响关闭行为。

七、加强记忆

Socket 是操作系统提供的网络编程接口，是应用层和传输层之间的抽象（Unix 里表现为 fd），一个 TCP 连接由四元组（源/目的 IP + 端口）唯一标识。服务端流程：socket（建套接字）→ bind（绑地址端口）→ listen（转监听 + 连接队列）→ accept（取已握手连接，返回新的已连接 socket）→ 读写 → close；客户端 socket → connect（三次握手）→ 读写 → close。监听 socket 负责接客、已连接 socket 负责通信，如何管理海量连接 fd 是网络编程的核心。

简化版

详细版