一、Master和Worker之间需要一条"电话线"
Nginx的进程模型是一个Master带一堆Worker。Master负责管理——读配置、fork子进程、监听信号、热升级；Worker负责干活——accept连接、处理请求、发送响应。分工很清晰，但带来一个直接的问题：Master怎么告诉Worker该干嘛？
最直觉的答案是Unix信号。Master用kill()给Worker发个SIGQUIT，Worker收到后优雅退出。Nginx确实也这么干了。但信号有个致命短板：它只能传递一个信号编号，不能传数据。
考虑这个场景：Master fork出一个新Worker进程，现有的Worker需要知道"有个新兄弟来了，它的PID是多少，它的通信端口是什么"。这种结构化数据，光靠一个信号编号搞不定。
再看一个更硬核的场景：Nginx需要在进程间传递文件描述符。你可能会想——fd不就是个整数吗，传过去不就完了？问题在于文件描述符是进程私有的。进程A的fd 7和进程B的fd 7可能指向完全不同的内核对象。要让进程B拿到和进程A"同一个"文件描述符，必须用Unix域套接字的SCM_RIGHTS辅助消息机制——这是操作系统提供的一种特殊能力，能把一个进程的文件描述符"复制"到另一个进程的文件描述符表中，让两个进程共享同一个底层socket endpoint。
所以Nginx设计了一套基于socketpair的进程间通信机制，源码集中在ngx_channel.h（35行）和ngx_channel.c（254行）。加上ngx_proce
