上一节我们知道要写程序让两台机器对话。这一节解决第一个问题：进程之间怎么互相找到对方？答案就是网络上的一个「端点」——Socket。

自上而下五层：用户进程、Socket 接口、内核协议栈、TCP/IP 网络、对端镜像。数据沿箭头方向穿越。

上一页我们讲了 Socket 通信模型，要真正把字节从一头送到另一头还得选协议。UDP 就是其中一种——它根本不握手，发完就走，不问对方收没收到。

同为传输层协议，但「建连接」「保可靠」「管流量」的哲学截然相反——混用会埋坑。

UDP 无连接：两端各自建 socket，sendto 直发、recvfrom 直收，沿箭头看数据走向。

用最简回显服务,把 socket→bind→recvfrom→sendto→close 一行一行跑通。

高亮行正是服务端 5 个核心系统调用:建端点、绑端口、收数据、回数据、关连接。

四步走完 UDP 客户端：socket→sendto→recvfrom→close

socket 建通道、sendto 主动发、recvfrom 阻塞收、close 释放，覆盖 UDP 客户端完整生命周期。

一次 UDP 交互中，服务端与客户端的关键系统调用按什么顺序触发。

上页代码跑起来了，但 sendto 那一长串参数是否还有点恍惚？fd、buf、len、flags、addr、alen——每个位置到底在问什么？出错时返回值又该怎么看？这页把它们逐个拆开。

代码写完了，怎么快速验证它能收发？最轻量的工具是 netcat——一行命令起服务端、一行命令发数据，比再写个测试程序省事得多。

用 tshark 命令行工具抓取我们 UDP 服务（端口 9999）的流量，按端口/IP/流过滤。

tshark 有两层过滤：抓包用 BPF 语法 (-f) 减少磁盘写入；回放用 Wireshark 显示语法 (-Y) 精确定位。follow,udp 可把无连接的 UDP 包重组为流视图。

Connection refused/Port unreachable 处理

上页说 UDP 像扔信封——发出去就不管了。TCP 不一样：发之前要先「握手」，收到后要「签收」，按序号拼回去，少一封就重发。

SYN→SYN+ACK→ACK 的完整时序

读法：从左到右看消息流动，客户端先发 FIN，服务端分开发 ACK 和 FIN，最后客户端 ACK。

前两页我们跟完了三次握手、四次挥手——那只走了状态图上的一条主线。完整的连接生命周期里，TCP 一共要穿过 11 个状态，每个状态都对应着一段特定的协议行为。

最小可运行的 TCP 回显服务端，覆盖 socket→bind→listen→accept→read/write→close 全流程。

六行对应 TCP 服务端六个阶段：SOCK_STREAM 锁定 TCP 协议；listen 把主动 socket 转为被动；accept 阻塞等三次握手完成；cfd 是新连接的专用描述符。

一个最小可运行的 TCP 客户端，跑通 socket→connect→read/write→close 五步生命周期。

connect() 是 TCP 客户端特有的入口，三次握手在此完成；read/write 走全双工字节流；close 触发四次挥手。对比 UDP 客户端，多出的就是 connect 这一步。

三次握手看似协议层动作，实际由 socket API 在内核里串起来。

TCP 服务端 socket() 拿到的是主动套接字，要接客户端必须先 listen() 转成被动监听，再由 accept() 从内核队列里把连接取出来——这是服务端并发的根。

connect 的行为与错误处理

fork/线程池实现并发服务器

TCP 连接建立后，怎么证明它真的「活着」？握手的数据落在哪个 socket 里？现在该请出调试工具——netstat 和 ss，把内核里的连接表「投影」到屏幕上。

真实抓包输出：从 SYN 到数据传输逐包追踪三次握手过程

对比 Seq/Ack 递增规律：每次 ACK 等于对方 Seq+Len，三次握手后 Seq 从 0 起步，数据包每段递增 75。

上一节我们用 Wireshark 抓到了完整握手。但线上常常拿不到握手——连接直接失败，错误码有 refused、timeout、reset 三种，背后原因和排查路径完全不同。

上一页讲到 listen() 创建监听 socket、accept() 取出连接。但三次握手发生在内核里，应用感知不到。内核为此维护着两个隐藏队列——握手就在它们之间流转。

SO_REUSEADDR/SO_KEEPALIVE 等常用选项

前面 TCP/UDP 代码里，recv() 没数据就卡住等——这是阻塞 I/O 的默认行为。想让进程「不等」或「边等边干别的」，得切到非阻塞模式。

上一节区分了阻塞/非阻塞模式，但 recv/send 不管哪种模式都可能因信号或网络异常返回 -1。errno 就是系统告诉你「为什么失败」的唯一线索。

对 UDP socket 调用 connect() 后，下列行为描述正确的是？

• ✓TCP 暴露无消息边界的字节流，UDP 保留独立数据报边界。
• ✓TCP 以连接、确认、排序、流量与拥塞控制换取可靠交付。
• ✓UDP 默认不保证送达、顺序、时限，也不承诺只收一次。
• ✓完整性优先选 TCP；可容忍丢包且追求低时延选 UDP。
• ✓需要可靠 UDP，应补齐重传、排序、拥塞控制和应用层校验。

先合上屏幕自己想一分钟，再点开参考答案对思路。三道题分别对应回顾、应用、边界三个层次，看看你最擅长哪一层。