Linux下网络传输测速程序小记
最近需要在linux下做一个网络测速的小程序,将服务端内存中缓存的一个大文件整个的从服务端发送到客户端,并缓存到客户端的内存中,以此抛开硬盘读取速度的影响,测量网络实际的传输速度。
小程序分为一个服务端server和一个客户端client,网上有很多类似的示例程序,但多少都有问题,后面我会提到。
首先,如果你是linux下编程的新手,需要看很多基础性的知识的话,建议你可以去这个网站看看,因为我也是新手,我的很多问题都是在这个论坛找到答案的linux286社区但有一个缺点就是回答问题的高手很少,帖子倒是不少,而且有的质量还不错!
二、基础知识
言归正传,先看一下Linux下的TCP/IP实现结构。如下图:
1、文件套接字和网络套接字,前者存在于套接字文件系统中,让用户以文件的方式访问网络连接;后者存在于系统底层,用户不能直接访问。但文件套接字与网络套接字一一对应,文件套接字的操作实际上就是由网络套接字完成的。
2、socket()函数用于在套接字文件系统中创建套接字文件,套接字文件的操作表为socket_file_ops,它指向文件套接字操作表(proto_ops,实际上是操作函数集合)。系统支持不同的文件套接字,就会提供不同的文件套接字操作表供套接字文件进行链接。系统支持多种网络协议时,也会提供多种网络套接字操作表(proto,实际上也是操作函数集合),网络套接字指向特定的操作表,就表示支持特定的协议。由socket函数执行,将创建的套接字文件(文件套接字)与网络套接字链接起来,就完成了文件套接字的操作与具体协议操作的链接。
3、文件套接字用socket结构描述,网络套接字用sock结构描述。
4、套接字的协议族确定了对套接字的创建操作。套接字的类型确定了对文件套接字的操作。
三、函数清单
下面是一些常用的函数介绍:
socket
int socket(int domain, int type,int protocol)
domain:说明我们网络程序所在的主机采用的通讯协族(AF_UNIX和AF_INET等)。 AF_UNIX只能够用于单一的Unix系统进程间通信,而AF_INET是针对Internet的,因而可以允许在远程主机之间通信(当我们man socket时发现domain可选项是PF_*而不是AF_*,因为glibc是posix的实现所以用PF代替了AF,不过我们都可以使用的)。
type:我们网络程序所采用的通讯协议(SOCK_STREAM,SOCK_DGRAM等) SOCK_STREAM表明我们用的是TCP协议,这样会提供按顺序的,可靠、双向、面向连接的比特流。SOCK_DGRAM表明我们用的是UDP协议,这样只会提供定长的、不可靠、无连接的通信。
protocol:由于我们指定了type,所以这个地方我们一般只要用0来代替就可以了。
socket:为网络通讯做基本的准备。成功时返回文件描述符,失败时返回-1,看errno可知道出错的详细情况。
bind
int bind(int sockfd, struct sockaddr *my_addr, int addrlen)
sockfd:是由socket调用返回的文件描述符。
addrlen:是sockaddr结构的长度。
my_addr:是一个指向sockaddr的指针。sockaddr的定义
struct sockaddr{
unisgned short as_family;
char sa_data[14];
};
不过由于系统的兼容性,我们一般不用这个头文件,而使用另外一个结构(struct sockaddr_in) 来代替。sockaddr_in的定义
struct sockaddr_in{
unsigned short sin_family;
unsigned short int sin_port;
struct in_addr sin_addr;
unsigned char sin_zero[8];
};
我们主要使用Internet所以sin_family一般为AF_INET,sin_addr设置为INADDR_ANY表示可以和任何的主机通信,sin_port是我们要监听的端口号,sin_zero[8]是用来填充的。bind将本地的端口同socket返回的文件描述符捆绑在一起。成功是返回0,失败的情况和socket一样。
listen
int listen(int sockfd,int backlog)
sockfd:是bind后的文件描述符。
backlog:设置请求排队的最大长度。当有多个客户端程序和服务端相连时,使用这个表示可以介绍的排队长度。listen函数将bind的文件描述符变为监听套接字。返回的情况和bind一样。
accept
int accept(int sockfd, struct sockaddr *addr,int *addrlen)
sockfd:是listen后的文件描述符。
addr,addrlen是用来给客户端的程序填写的,服务器端只要传递指针就可以了。 bind,listen和accept是服务器端用的函数,accept调用时,服务器端的程序会一直阻塞到有一个客户程序发出了连接。 accept成功时返回最后的服务器端的文件描述符,这个时候服务器端可以向该描述符写信息了。失败时返回-1。
connect
int connect(int sockfd, struct sockaddr * serv_addr,int addrlen)
sockfd:socket返回的文件描述符.。
serv_addr::储存了服务器端的连接信息,其中sin_add是服务端的地址。
addrlen:serv_addr的长度。
connect函数是客户端用来同服务端连接的。成功时返回0,sockfd是同服务端通讯的文件描述符失败时返回-1。
四、示例代码
光说不练假把式,下面就是我的程序的代码,分为server.c,client.c两个文件,为了简单化,这里的服务端只同一个客户端建立连接,故没有用很多地方的while(1)循环来不停的监听客户端的建立连接,程序里面的很多代码都是从网上拿下来直接用的,方便:-)
服务器端代码:server.c
客户端代码:client.c
./server 8888
五、CODING过程中遇到的问题及解决
1、server_addr.sin_addr=*((struct in_addr *)host->h_addr);
这句话刚开始一直报错:提领指向不完全类型的指针
可是对照书本开其中host对应的struct hostent怎么也不能发现问题,最后才在网上发现,原来是少include一个头文件netdb.h编译通过:)
开始的时候,由于第1个问题不知道是少头文件造成的,我就将程序改成了客户端输入的第二个参数直接就是IP地址。在server和client运行在同一台电脑上的时候是没有问题的,但是当server是一台机器,client又是另一台机器的时候,发现无法建立连接了。
当传送一个小文件的时候,不管是在同一台机器还是不同的机器,都没有问题。
当传送一个大文件的时候,不管是在同一台机器还是不同的机器,都不行。
最终搞定了。问题出在write和read这两个函数上。如果直接用的话,由于在网络写数据的过程中有可能是由于中断导致传输出错的。因此用了两个重写的写和读的函数,用于在中断后继续传输。
六、套接字编程中的5个隐患
1、忽略返回状态
第一个隐患很明显,但它是开发新手最容易犯的一个错误。如果您忽略函数的返回状态,当它们失败或部分成功的时候,您也许会迷失。反过来,这可能传播错误,使定位问题的源头变得困难。
捕获并检查每一个返回状态,而不是忽略它们。考虑清单 1 显示的例子,一个套接字 send 函数。
清单 1. 忽略 API 函数返回状态
int status, sock, mode;
/* Create a new stream (TCP) socket */
sock = socket( AF_INET, SOCK_STREAM, 0 );
status = send( sock, buffer, buflen, MSG_DONTWAIT );
if (status == -1) {
/* send failed */
printf( "send failed: %s\n", strerror(errno) );
} else {
/* send succeeded -- or did it? */
}
清单 1 探究一个函数片断,它完成套接字 send 操作(通过套接字发送数据)。函数的错误状态被捕获并测试,但这个例子忽略了 send 在无阻塞模式(由 MSG_DONTWAIT 标志启用)下的一个特性。
send API 函数有三类可能的返回值:
如果数据成功地排到传输队列,则返回 0。
如果排队失败,则返回 -1(通过使用 errno 变量可以了解失败的原因)
如果不是所有的字符都能够在函数调用时排队,则最终的返回值是发送的字符数。
由于 send 的 MSG_DONTWAIT 变量的无阻塞性质,函数调用在发送完所有的数据、一些数据或没有发送任何数据后返回。在这里忽略返回状态将导致不完全的发送和随后的数据丢失。
2、对等套接字闭包
UNIX 有趣的一面是您几乎可以把任何东西看成是一个文件。文件本身、目录、管道、设备和套接字都被当作文件。这是新颖的抽象,意味着一整套的 API 可以用在广泛的设备类型上。
考虑 read API 函数,它从文件读取一定数量的字节。read 函数返回读取的字节数(最高为您指定的最大值);或者 -1,表示错误;或者 0,如果已经到达文件末尾。
如果在一个套接字上完成一个 read 操作并得到一个为 0 的返回值,这表明远程套接字端的对等层调用了 close API 方法。该指示与文件读取相同 —— 没有多余的数据可以通过描述符读取(参见清单 2)。
清单 2.适当处理 read API 函数的返回值
int sock, status;
sock = socket( AF_INET, SOCK_STREAM, 0 );
status = read( sock, buffer, buflen );
if (status > 0) {
/* Data read from the socket */
} else if (status == -1) {
/* Error, check errno, take action... */
} else if (status == 0) {
/* Peer closed the socket, finish the close */
close( sock );
/* Further processing... */
}
同样,可以用 write API 函数来探测对等套接字的闭包。在这种情况下,接收 SIGPIPE 信号,或如果该信号阻塞,write 函数将返回 -1 并设置 errno 为 EPIPE。
3、地址使用错误
您可以使用 bind API 函数来绑定一个地址(一个接口和一个端口)到一个套接字端点。可以在服务器设置中使用这个函数,以便限制可能有连接到来的接口。也可以在客户端设置中使用这个函数,以便限制应当供出去的连接所使用的接口。bind 最常见的用法是关联端口号和服务器,并使用通配符地址(INADDR_ANY),它允许任何接口为到来的连接所使用。
bind 普遍遭遇的问题是试图绑定一个已经在使用的端口。该陷阱是也许没有活动的套接字存在,但仍然禁止绑定端口(bind 返回 EADDRINUSE),它由 TCP 套接字状态 TIME_WAIT 引起。该状态在套接字关闭后约保留 2 到 4 分钟。在 TIME_WAIT 状态退出之后,套接字被删除,该地址才能被重新绑定而不出问题。
等待 TIME_WAIT 结束可能是令人恼火的一件事,特别是如果您正在开发一个套接字服务器,就需要停止服务器来做一些改动,然后重启。幸运的是,有方法可以避开 TIME_WAIT 状态。可以给套接字应用 SO_REUSEADDR 套接字选项,以便端口可以马上重用。
考虑清单 3 的例子。在绑定地址之前,我以 SO_REUSEADDR 选项调用 setsockopt。为了允许地址重用,我设置整型参数(on)为 1 (不然,可以设为 0 来禁止地址重用)。
清单 3.使用 SO_REUSEADDR 套接字选项避免地址使用错误
int sock, ret, on;
struct sockaddr_in servaddr;
/* Create a new stream (TCP) socket */
sock = socket( AF_INET, SOCK_STREAM, 0 ):
/* Enable address reuse */
on = 1;
ret = setsockopt( sock, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on) );
/* Allow connections to port 8080 from any available interface */
memset( &servaddr, 0, sizeof(servaddr) );
servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr = htonl( INADDR_ANY );
servaddr.sin_port = htons( 45000 );
/* Bind to the address (interface/port) */
ret = bind( sock, (struct sockaddr *)&servaddr, sizeof(servaddr) );
在应用了 SO_REUSEADDR 选项之后,bind API 函数将允许地址的立即重用。
4、发送结构化数据
套接字是发送无结构二进制字节流或 ASCII 数据流(比如 HTTP 上的 HTTP 页面,或 SMTP 上的电子邮件)的完美工具。但是如果试图在一个套接字上发送二进制数据,事情将会变得更加复杂。
比如说,您想要发送一个整数:您可以肯定,接收者将使用同样的方式来解释该整数吗?运行在同一架构上的应用程序可以依赖它们共同的平台来对该类型的数据做出相同的解释。但是,如果一个运行在高位优先的 IBM PowerPC 上的客户端发送一个 32 位的整数到一个低位优先的 Intel x86,那将会发生什么呢?字节排列将引起不正确的解释。
通过套接字发送一个 C 结构会怎么样呢?这里,也会遇到麻烦,因为不是所有的编译器都以相同的方式排列一个结构的元素。结构也可能被压缩以便使浪费的空间最少,这进一步使结构中的元素错位。
幸好,有解决这个问题的方案,能够保证两端数据的一致解释。过去,远程过程调用(Remote Procedure Call,RPC)套装工具提供所谓的外部数据表示(External Data Representation,XDR)。XDR 为数据定义一个标准的表示来支持异构网络应用程序通信的开发。
现在,有两个新的协议提供相似的功能。可扩展标记语言/远程过程调用(XML/RPC)以 XML 格式安排 HTTP 上的过程调用。数据和元数据用 XML 进行编码并作为字符串传输,并通过主机架构把值和它们的物理表示分开。SOAP 跟随 XML-RPC,以更好的特性和功能扩展了它的思想。参见 参考资料 小节,获取更多关于每个协议的信息。
5、TCP中的帧同步假定
TCP 不提供帧同步,这使得它对于面向字节流的协议是完美的。这是 TCP 与 UDP(User Datagram Protocol,用户数据报协议)的一个重要区别。UDP 是面向消息的协议,它保留发送者和接收者之间的消息边界。TCP 是一个面向流的协议,它假定正在通信的数据是无结构的,如图 1 所示。
图 1.UDP 的帧同步能力和缺乏帧同步的TCP
图 1 的上部说明一个 UDP 客户端和服务器。左边的对等层完成两个套接字的写操作,每个 100 字节。协议栈的 UDP 层追踪写的数量,并确保当右边的接收者通过套接字获取数据时,它以同样数量的字节到达。换句话说,为读者保留了写者提供的消息边界。
现在,看图 1 的底部.它为 TCP 层演示了相同粒度的写操作。两个独立的写操作(每个 100 字节)写入流套接字。但在本例中,流套接字的读者得到的是 200 字节。协议栈的 TCP 层聚合了两次写操作。这种聚合可以发生在 TCP/IP 协议栈的发送者或接收者中任何一方。重要的是,要注意到聚合也许不会发生 —— TCP 只保证数据的有序发送。
对大多数开发人员来说,该陷阱会引起困惑。您想要获得 TCP 的可靠性和 UDP 的帧同步。除非改用其他的传输协议,比如流传输控制协议(STCP),否则就要求应用层开发人员来实现缓冲和分段功能。