本篇文章主要介绍了套接字的几个常用配置选项,包括SO_SNDBUF & SO_RCVBUF、SO_REUSEADDR及TCP_NODELAY等。
套接字可选项和I/O缓冲大小
前文关于套接字的描述仅仅是使用其默认套接字特性来进行数据通信,这对于简单的使用场景来说似乎是可以的,然而实际工作场景中的确需要配置相关套接字选项来满足一些特殊需求。下图所示是一些常用的套接字可选配置选项。
一些常用套接字可配置选项
从图中可以看出,套接字可选项是分层的。IPPROTO_IP层可选项是IP协议相关事项,IPPROTO_TCP层可选项是TCP协议相关事项,SOL_SOCKET层是套接字相关的通用可选项。
getsockopt & setsockopt
针对上文所描述的套接字可选项,可分别通过getsockopt函数和setsockopt函数来进行读取(Get)和设置(Set)(有些选项可能仅支持一种操作)。
#include//Get option int getsockopt(int sock, int level, int optname, void *optval, socklen_t *optlen); -> 成功时返回0,失败时返回-1 //Set option int setsockopt(int sock, int level, int optname, void *optval, socklen_t optlen); -> 成功时返回0,失败时返回-1
下面示例源码给出了getsockopt函数的使用方法,同时也展示了只读套接字选项SO_TYPE的作用(套接字类型只能在创建时决定,之后不能再更改)。
1 #include2 #include 3 #include 4 #include 5 void error_handling(char *message); 6 7 int main(int argc, char *argv[]) 8 { 9 int tcp_sock, udp_sock; 10 int sock_type; 11 socklen_t optlen; 12 int state; 13 14 optlen=sizeof(sock_type); 15 tcp_sock=socket(PF_INET, SOCK_STREAM, 0); 16 udp_sock=socket(PF_INET, SOCK_DGRAM, 0); 17 printf("SOCK_STREAM: %d \n", SOCK_STREAM); 18 printf("SOCK_DGRAM: %d \n", SOCK_DGRAM); 19 20 state=getsockopt(tcp_sock, SOL_SOCKET, SO_TYPE, (void*)&sock_type, &optlen); 21 if(state) 22 error_handling("getsockopt() error!"); 23 printf("Socket type one: %d \n", sock_type); 24 25 state=getsockopt(udp_sock, SOL_SOCKET, SO_TYPE, (void*)&sock_type, &optlen); 26 if(state) 27 error_handling("getsockopt() error!"); 28 printf("Socket type two: %d \n", sock_type); 29 return 0; 30 } 31 32 void error_handling(char *message) 33 { 34 fputs(message, stderr); 35 fputc('\n', stderr); 36 exit(1); 37 }
运行结果
SO_SNDBUF & SO_RCVBUF
前文中我们提到套接字的输入输出缓冲区,而SO_SNDBUF 和SO_RCVBUF便是与套接字缓冲区大小相关的两个可选项。通过这两个选项我们可以获取当前套接字的输入输出缓冲区大小,抑或设置相应缓冲区的大小。如下是这两个选项使用的相关示例代码。
1 #include2 #include 3 #include 4 #include 5 void error_handling(char *message); 6 7 int main(int argc, char *argv[]) 8 { 9 int sock; 10 int snd_buf, rcv_buf, state; 11 socklen_t len; 12 13 sock=socket(PF_INET, SOCK_STREAM, 0); 14 len=sizeof(snd_buf); 15 state=getsockopt(sock, SOL_SOCKET, SO_SNDBUF, (void*)&snd_buf, &len); 16 if(state) 17 error_handling("getsockopt() error"); 18 19 len=sizeof(rcv_buf); 20 state=getsockopt(sock, SOL_SOCKET, SO_RCVBUF, (void*)&rcv_buf, &len); 21 if(state) 22 error_handling("getsockopt() error"); 23 24 printf("Input buffer size: %d \n", rcv_buf); 25 printf("Outupt buffer size: %d \n", snd_buf); 26 return 0; 27 } 28 29 void error_handling(char *message) 30 { 31 fputs(message, stderr); 32 fputc('\n', stderr); 33 exit(1); 34 }
1 #include2 #include 3 #include 4 #include 5 void error_handling(char *message); 6 7 int main(int argc, char *argv[]) 8 { 9 int sock; 10 int snd_buf=1024*3, rcv_buf=1024*3; 11 int state; 12 socklen_t len; 13 14 sock=socket(PF_INET, SOCK_STREAM, 0); 15 state=setsockopt(sock, SOL_SOCKET, SO_RCVBUF, (void*)&rcv_buf, sizeof(rcv_buf)); 16 if(state) 17 error_handling("setsockopt() error!"); 18 19 state=setsockopt(sock, SOL_SOCKET, SO_SNDBUF, (void*)&snd_buf, sizeof(snd_buf)); 20 if(state) 21 error_handling("setsockopt() error!"); 22 23 len=sizeof(snd_buf); 24 state=getsockopt(sock, SOL_SOCKET, SO_SNDBUF, (void*)&snd_buf, &len); 25 if(state) 26 error_handling("getsockopt() error!"); 27 28 len=sizeof(rcv_buf); 29 state=getsockopt(sock, SOL_SOCKET, SO_RCVBUF, (void*)&rcv_buf, &len); 30 if(state) 31 error_handling("getsockopt() error!"); 32 33 printf("Input buffer size: %d \n", rcv_buf); 34 printf("Output buffer size: %d \n", snd_buf); 35 return 0; 36 } 37 38 void error_handling(char *message) 39 { 40 fputs(message, stderr); 41 fputc('\n', stderr); 42 exit(1); 43 } 44 /* 45 root@com:/home/swyoon/tcpip# gcc get_buf.c -o getbuf 46 root@com:/home/swyoon/tcpip# gcc set_buf.c -o setbuf 47 root@com:/home/swyoon/tcpip# ./setbuf 48 Input buffer size: 2000 49 Output buffer size: 2048 50 */
运行结果
从运行结果可以看出,对于缓冲大小的设置并非完全生效。实际上这些设置只是传递了我们的要求,而最终的生效值操作系统会根据当前环境做出设置,不过配置值的大小趋势和我们期望的一致。
SO_REUSEADDR
发生地址绑定错误(Binding Error)
回顾之前的文章“【TCP/IP网络编程】:04基于TCP的服务器端/客户端”,我们介绍了回声服务器端/客户端的实现。其中服务器端代码稍作改变如下。
1 #include2 #include 3 #include <string.h> 4 #include 5 #include 6 #include 7 8 #define TRUE 1 9 #define FALSE 0 10 void error_handling(char *message); 11 12 int main(int argc, char *argv[]) 13 { 14 int serv_sock, clnt_sock; 15 char message[30]; 16 int option, str_len; 17 socklen_t optlen, clnt_adr_sz; 18 struct sockaddr_in serv_adr, clnt_adr; 19 20 if(argc!=2) { 21 printf("Usage : %s \n ", argv[0]); 22 exit(1); 23 } 24 25 serv_sock=socket(PF_INET, SOCK_STREAM, 0); 26 if(serv_sock==-1) 27 error_handling("socket() error"); 28 /* 29 optlen=sizeof(option); 30 option=TRUE; 31 setsockopt(serv_sock, SOL_SOCKET, SO_REUSEADDR, &option, optlen); 32 */ 33 34 memset(&serv_adr, 0, sizeof(serv_adr)); 35 serv_adr.sin_family=AF_INET; 36 serv_adr.sin_addr.s_addr=htonl(INADDR_ANY); 37 serv_adr.sin_port=htons(atoi(argv[1])); 38 39 if(bind(serv_sock, (struct sockaddr*)&serv_adr, sizeof(serv_adr))) 40 error_handling("bind() error "); 41 42 if(listen(serv_sock, 5)==-1) 43 error_handling("listen error"); 44 clnt_adr_sz=sizeof(clnt_adr); 45 clnt_sock=accept(serv_sock, (struct sockaddr*)&clnt_adr,&clnt_adr_sz); 46 47 while((str_len=read(clnt_sock,message, sizeof(message)))!= 0) 48 { 49 write(clnt_sock, message, str_len); 50 write(1, message, str_len); 51 } 52 close(clnt_sock); 53 return 0; 54 } 55 56 void error_handling(char *message) 57 { 58 fputs(message, stderr); 59 fputc('\n', stderr); 60 exit(1); 61 }
客户端通过输入“Q”消息,或是通过CTRL+C终止程序,两种方式客户端都会执行close函数向服务器端传递EOF消息结束标志。服务器端收到EOF消息,也可以正常退出程序。现在考虑另一种情况,如果服务器端和客户端在已建立连接的状态下,向服务器端执行CTRL+C终止程序,会发生什么?
这种情况,服务器端会主动向客户端发送FIN消息断开连接并退出程序。此时,如果再次以相同端口号启动服务器端则会发生错误(bind()报错:“Address already in use”),通常需要等待1~4分钟才能再次运行服务器端。客户端主动发送FIN消息断开连接,不影响客户端或服务器端的再次运行;而服务器端主动发送FIN消息断开连接,则会影响服务器端的再次运行,为什么会出现这种现象呢?
TIME_WAIT状态
TIME_WAIT状态下的套接字
上图展示的就是前文有提到过的四次握手断开连接的过程。从图中可以看出,主动断开连接的主机(先发送FIN消息)会经过TIME_WAIT的状态,持续时间为2MSL(Maximum Segment Lifetime,最长分节生命期,30s或2min)。而处于TIME_WAIT状态时,相应的端口号是正在使用状态,因此,若服务器端先断开连接则无法立即重新运行。与服务器端不同,客户端由于每次运行都会动态分配端口号,因此不受TIME_WAIT状态的影响。
原来是TIME_WAIT的作怪,导致主动断开连接的服务器端不能立即以相同的端口号重新运行。既然对服务器端有这种影响,那为什么要有TIME_WAIT状态呢?(以下描述主要摘录自UNP,以客户端先发送FIN消息断开连接为例)
TIME_WAIT状态的存在有两个理由:
- 可靠地实现TCP全双工连接的终止
- 允许老的重复分节在网络中消逝
第一个理由可以假设上述四次握手过程最终的ACK丢失了来解释。主机B将重新发送它的最终那个FIN,因此主机A必须维护状态信息,以允许它重新发送最终那个ACK。如果主机A不维护状态信息,它将以一个RST(另外一种类型的TCP分节)消息来响应,该分节将被主机B解释为一个错误消息。如果TCP打算执行所有必要的工作以彻底终止某个连接上两个方向的数据流(即全双工关闭),那么它必须正确处理连接终止序列4个分节中任何一个分节丢失的情况。本例也说明了为什么执行主动关闭的那一端需要处于TIME_WAIT状态,因为它可能不得不重传最终那个ACK。
为理解存在TIME_WAIT状态的第二个理由,我们假设在12.106.32.254的1500端口和206.168.112.219的21端口之间有一个TCP连接。我们关闭这个连接,过一段时间后在相同的IP地址和端口之间建立另一个连接。后一个连接称为前一个连接的化身(incarnation),因为它们的IP地址和端口号都相同。TCP必须防止来自某个连接的老的重复分组在该连接已终止后再现,从而被误解成属于同一连接的某个新的化身。为做到这一点,TCP将不给处于TIME_WAIT状态的连接发起新的化身。既然TIME_WAIT状态的持续时间是MSL的2倍,这就足以让某个方向上的分组最多存活MSL秒即被丢弃,另一个方向上的应答最多存活MSL秒也被丢弃。通过实施这个规则,我们就能保证每成功建立一个TCP连接时,来自该连接先前化身的老的重复分组都已在网络中消逝了(单向传输一个分节的最长生命周期是MSL,TIME-WAIT状态的2MSL是考虑了一次双向信息交互的最长时间。比如最后的ACK丢失后,来自对端重发的FIN消息也会在2MSL内消逝)。
地址再分配
从上文的描述来看,TIME_WAIT状态在可靠通信过程中似乎起到了重要的作用,但它也有其自身的缺点。比如下图的情况,收到FIN消息的主机A发送ACK消息至主机B并启动Time-wait定时器,如果网络状态不好致使ACK消息不断丢失,则TIME-WAIT状态可能一直持续下去。
重启Time-wait定时器
另一种情况,考虑正在工作中的服务器突然故障停机而需要快速重启,这时由于TIME_WAIT状态则必须等几分钟,也会带来严重的影响(时间就是money)。
针对以上TIME_WAIT状态所带来的影响,可以通过配置可选项SO_REUSEADDR来解决。默认情况下,SO_REUSEADDR选项处于关闭状态(值为0,假),即无法分配处于TIME_WAIT状态下套接字端口。因此,我们需要将该选项置为1(真)即可。
int opt_val = 1; setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &opt_val, sizeof(opt_val));
SO_REUSEADDR可选项有效解决了以上问题,UNP中也有这么一句描述“所有TCP服务器都应该指定本套接字选项,以允许服务器在这种情形下被重新启动”。同时我们也应该意识到SO_REUSEADDR其实无视了TIME_WAIT状态的一些作用,此时如果收到一些不期望的数据(旧连接的分片)可能会导致服务程序混乱,不过这种可能性极低。
TCP_NODELAY
Nagle算法
Nagle算法的出现是为了防止因数据包过多而导致的网络过载,它应用于TCP层,其作用如下图所示。
Nagle算法
不难看出,只有收到ACK消息,Nagle算法才会发送下一数据。TCP套接字默认使用Nagle算法,因此可以最大限度地进行缓冲,直到收到ACK。上图的演示中,使用Nagle算法发送一个字符串消息需要传递4个数据包,而不使用Nagle算法则需要传递10个数据包,对网络流量(Traffic,网络负载或混杂程度)产生了较大的影响。当然,上图的演示只是一种极端的情况(特定场景下,字符串中的字符需要间隔一定的时间来传输至缓冲区),实际程序中将字符串传输至缓冲区并非逐个字符进行的。
根据数据传输的特性,网络流量未受太大影响时,不使用Nagle算法反而更快。典型的场景就是“传输大文件数据”,此时即使不使用Nagle算法,也会在填满缓冲区时传输数据。这种情况并没有增加数据包的数量,反而由于无需等待ACK而可以连续传输,大大提高了传输速度。禁止Nagle算法的方法如下。
int opt_val = 1; setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &opt_val, sizeof(opt_val));
是否使用Nagle算法,需要根据使用与否对网络流量影响的差别大小确定。通常情况,不使用Nagle算法确实可以获得更快的传输速度。但为了保证网络流量,在未准确判断数据特性时不应该禁止Nagle算法。