socket编程实验原理

Socket 本质上是编程一个文件描述符。Linux 里一切皆文件，实验socket 也不例外。原理创建 socket 后拿到一个 int 型的编程 fd，读写它就跟读写普通文件一样，实验只不过内核在这一层帮你处理了 TCP/IP 协议栈的原理所有细节。理解这一点，编程整个 socket 编程的实验实验框架就清楚了。

实验通常从 TCP 的原理客户端-服务器模型入手。服务器端调用 socket() 创建一个套接字，编程bind() 把它绑定到某个 IP 和端口上，实验然后 listen() 把主动套接字变成被动套接字，原理等待连接。编程客户端也调 socket()，实验但不需要 bind，原理直接 connect() 发起三次握手。握手完成后，服务器端的 accept() 返回一个新的 fd，这个新 fd 才是真正用于和该客户端通信的通道。原来的监听 fd 继续留在那里，等下一个连接。

这里有个容易踩的坑：很多人第一次写 echo 服务器，会在 accept 之后直接 read/write，然后 close，再循环回 accept。单客户端测试没问题，一上多客户端就出乱子。原因是 accept 返回的新 fd 和监听 fd 是两个独立的东西，但如果你只用一个循环串行处理，第二个客户端连上来时第一个还没断开，服务器就卡在 read 上等第一个客户端发数据。解决办法要么用多线程/多进程，要么用 I/O 多路复用（select/poll/epoll）。实验里一般会要求两种都实现一遍，对比着看。

UDP 那边就简单得多。没有连接的概念，sendto() 和 recvfrom() 每次都要带目标地址或来源地址。服务器 bind 之后直接 recvfrom 就行，不需要 listen 和 accept。丢包、乱序这些事内核不管，全交给应用层。写一个 UDP echo 服务器大概二十行代码就够了，但你会发现它比 TCP 版本更容易出现“数据收不到”的情况——不是代码写错了，是 UDP 本身不保证送达。

阻塞和非阻塞是另一个实验重点。默认 socket 是阻塞的，read() 没数据就卡住，accept() 没连接也卡住。把 fd 设成非阻塞（fcntl(fd, F_SETFL, O_NONBLOCK)）之后，这些调用立刻返回，没数据就返回 -1 并置 errno 为 EAGAIN 或 EWOULDBLOCK。非阻塞配合 epoll 是现在高并发服务器的标配，但实验里如果一上来就写 epoll，很容易被边缘触发和水平触发的区别搞晕。建议先用阻塞模式把逻辑跑通，再改成非阻塞 + select，最后上 epoll。

字节序的问题也值得单独拎出来说。网络协议规定用大端序传输，x86 机器是小端。所以往 socket 里写端口号之前必须 htons()，写 IP 地址用 inet_pton() 转成二进制。忘了转的话，服务器 bind 的端口和你以为的完全不是一回事，用 netstat 一看就能发现端口号变成了一个奇怪的数字。这个错误我见过太多次，每次都是盯着代码看半天才反应过来。

实验里还会涉及 setsockopt() 的用法。SO_REUSEADDR 是最常用的一个，服务器重启时如果之前有连接处于 TIME_WAIT 状态，不设这个选项 bind 会直接失败。TCP_NODELAY 也值得试一下，默认情况下内核会攒够一定量的数据再发，对小包交互的场景延迟很明显，关掉 Nagle 算法后响应会快不少。

写代码的时候建议开着 strace 或者 tcpdump 跑一遍。看系统调用返回了什么，看网络上实际发了哪些包，比盯着 printf 猜要高效得多。socket 编程的实验价值不在于写出能跑的代码，而在于搞清楚内核在背后替你做了什么、没做什么。