套接字可选项和I/O缓冲大小
可选项的读取和设置通过如下两个函数完成：
#include <sys/socket.h>
/*
* @params
* sock: 套接字描述符
* level: 要查看的可选项的协议层
* optname: 要查看的可选项名
* optval: 保存查看结果的缓冲地址值
* optlen: 传参时代表传入的缓冲区大小（字节），返回时保存保存在缓冲区中的可选项信息的大小（字节）
*/
int getsockopt(int sock, int level, int optname, void *optval, socklen_t *optlen); // 成功时返回0，失败时返回-1
/*
* @params
* sock: 套接字描述符
* level: 要更改的可选项的协议层
* optname: 要更改的可选项名
* optval: 保存要更改的选项信息的缓冲地址值
* optlen: 传入的缓冲区大小（字节）
*/
int setsockopt(int sock, int level, int optname, const void *optval, socklen_t optlen); // 成功时返回0，失败时返回-1
getsockopt方法调用示例：
# gcc sock_type.c -o socktype
# ./socktype
SOCK_STREAM: 1
SOCK_DGRAM: 2
Socket type one: 1
Socket type two: 2
套接字类型SO_TYPE是一个只读可选项，意味着套接字一旦创建就不能再更改类型。
SO_RCVBUF和ASO_RCVBUF分别是输入/输出缓冲大小可选项。通过示例读取和修改缓冲大小：
# gcc get_buf.c -o getbuf
# ./getbuf
Input buffer size: 87380
Output buffer size: 16384
# gcc set_buf.c -o setbuf
# ./setbuf
Input buffer size: 65536
Output buffer size: 65536
书中传入的数值较小，实际打印出来的缓冲大小显示并未按照输入值去设置。本例使用1024*32修改成功。
SO_REUSEADDR
第四章中实现的回声服务器端有两种终止程序的方式：
- 回声客户端调用close函数，会向回声服务器端发送FIN消息；
- CTRL_C退出服务器端，会向回声客户端发送FIN消息。
第一种是正常的结束方式，第二种情况下发生了什么呢？我们抓包来看一下：
# tcpdump -i lo port 9190
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
01:40:02.655437 IP localhost.9190 > localhost.48444: Flags [F.], seq 8, ack 7, win 342, options [nop,nop,TS val 482119632 ecr 482110332], length 0
01:40:02.695496 IP localhost.48444 > localhost.9190: Flags [.], ack 9, win 342, options [nop,nop,TS val 482119673 ecr 482119632], length 0
01:44:22.037506 IP localhost.48444 > localhost.9190: Flags [F.], seq 7, ack 9, win 342, options [nop,nop,TS val 482379004 ecr 482119632], length 0
01:44:22.037521 IP localhost.9190 > localhost.48444: Flags [R], seq 3040430723, win 0, length 0
回声服务器端在CTRL+C操作后发送了FIN消息，随后收到了对这个FIN的ACK。接着再终止回声客户端，发送FIN给回声服务器端，然后收到回声服务器端的RESET消息，因为回声服务器端的程序已经终止了，该端口不再提供服务。
此时如果我们立刻启动回声服务器端，会得到一个报错：
# ./eserver 9190
bind() error
这是因为套接字并未立即消除（处于FIN_WAIT2状态），相应端口正在使用。
# netstat -an | grep 9190
tcp 1 0 127.0.0.1:48464 127.0.0.1:9190 CLOSE_WAIT
tcp 0 0 127.0.0.1:9190 127.0.0.1:48464 FIN_WAIT2
大约两分钟后9190到48464方向的套接字不再被占用，就可以重启服务器端了，尽管此时另一方向的套接字从未被关闭也没关系。
# netstat -an | grep 9190
tcp 1 0 127.0.0.1:48464 127.0.0.1:9190 CLOSE_WAIT
# ./eserver 9190
当然，48464到9190方向的套接字也不能再使用了。因为回声服务器端没有接受任何连接。
# netstat -an | grep 9190
tcp 0 0 0.0.0.0:9190 0.0.0.0:* LISTEN
tcp 1 0 127.0.0.1:48464 127.0.0.1:9190 CLOSE_WAIT
如果不想要服务器处于等待状态下而无法启动，也是可以通过更改SO_REUSEADDR可选项来实现的。
# gcc reuseadr_eserver.c -o reu_eserver
# ./reu_eserver 9190
Connected client 1
^C
# ./reu_eserver 9190
TCP_NODELAY
Nagle算法：只有在收到前一数据的ACK消息时，才发送下一数据。
TCP套接字默认使用Nagle算法，以提高网络传输效率。但网络流量负担不重时，或传输大文件数据时，可以禁用Nagle算法以换取更快的传输时间。禁用方法十分简单：
int option = 1;
setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (void*)&option, sizeof(option));
习题
- 下列关于time-wait状态的说法错误的是？
a. time-wait状态只在服务器端的套接字中发生。
b. 断开连接的四次握手过程中，先传输FIN消息的套接字将进入time-wait状态。
c. time-wait状态与断开连接的过程无关，而与请求连接过程中SYN消息的传输顺序有关。
d. time-wait状态通常并非必要，应尽可能通过更改套接字可选项防止其发生。
acd。- TCP_NODELAY可选项与Nagle算法有关，可通过它禁用Nagle算法。请问何时应考虑禁用Nagle算法？结合收发数据的特性给出说明。
网络流量未受太大影响时，如传输大文件数据，装满输入缓冲区的时间并不会太慢，因此不一定会增加数据包的数量，反而会因为等待ACK而影响速度。
我的问题
- TCP状态机？
