你的位置:首页 > 操作系统

[操作系统]网络编程中的关键问题总结


网络编程中的关键问题总结

总结下网络编程中关键的细节问题,包含连接建立、连接断开、消息到达、发送消息等等;

连接建立

包括服务端接受 (accept) 新连接和客户端成功发起 (connect) 连接。
accept接受连接的问题在本文最后会聊到,这里谈谈connect的关键点;
使用非阻塞连接建立需要注意:
connect/select返回后,可能没有连接上;需要再次确认是否成功连接;

步骤为:

  1. 使用异步connect直接连接一次,因为使用了非阻塞,函数立刻返回;
  2. 检查返回值,为0成功连接,否则加入到select/epoll中监控;
  3. 当有写事件时,连接成功;当即可读又可写时,可能是有错误或者连接成功后有数据已经发过来;所以,此时,需要用getsockopt()读取socket的错误选项,二次确认是否真的连接成功:
Fcntl(sockfd, F_SETFL, flags | O_NONBLOCK);error = 0;if ( (n = connect(sockfd, saptr, salen)) < 0)  if (errno != EINPROGRESS)    return(-1);/* Do whatever we want while the connect is taking place. */if (n == 0)  goto done;  /* connect completed immediately */if ( (n = Select(sockfd+1, &rset, &wset, NULL,         nsec ? &tval : NULL)) == 0) {  close(sockfd);    /* timeout */  errno = ETIMEDOUT;  return(-1);}if (FD_ISSET(sockfd, &rset) || FD_ISSET(sockfd, &wset)) {  len = sizeof(error);      //二次确认是否真的连接成功  if (getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &error, &len) < 0)    return(-1);      /* Solaris pending error */} else  err_quit("select error: sockfd not set");

连接断开

包括主动断开 (close 或 shutdown) 和被动断开 (read 返回 0)。

当打算关闭网络连接时,如何能知道对方已经发送了数据自己还没有收到?
在TCP层面解决:主动关闭的时候只使用半关闭shutdown(), 这样,服务端这边之时关闭了写端,还可以正常读;客户端收到关闭的信号后(read返回0),会再调用shutdown关闭整个连接;
在应用层面解决:双方通过某个标记协商,在标记之后不再读写数据,这样就可以完全的关闭连接了;

关闭连接时需要注意的:
是否还有未发送的数据,需要保证应用缓冲区中的数据都发送完毕之后再关闭缓冲区;
TCP缓存区不用我们考虑,因为在调用shutdown或close的时候,TCP的实现是会将TCP的发送缓冲区中的数据都发送出去,然后再发送FIN报文(也可能是组合成一个报文发送);

消息到达

消息到达是最重要的事件;对它的处理决定了网络编程的风格:是阻塞还是非阻塞、分包的处理、应用层的缓冲如何设计等等;

处理分包

所谓分包,就是在一个个字节流消息中如何区分出一个个消息来;
常见的分包方法有:

  1. 固定长度;
  2. 特殊的结尾符,比如字符串的\0,或者回车换行等;
  3. 固定的消息头中指定后续的消息的长度,然后跟上一个消息体内容;
  4. 使用协议本身的格式,比如json格式头尾配对(

字节序转换注意字节对齐

如果传输的是二进制类型,在字节流的缓存区中直接强转可能core dump;因为有的系统访问地址需要字节对齐,不能在任意地址上访问二进制类型(如整形),合理的方式是将其copy到一个本地变量中,然后再做字节序的转换:

int32_t peekInt32() const{  assert(readableBytes() >= sizeof(int32_t));  int32_t be32 = 0;  ::memcpy(&be32,readerIndex_, sizeof(be32) );  return be32toh(be32);}

应用层缓存区的实现

数据到达时处理需要注意:
socket读事件来到,必须一次将所有的数据都读完,否则会造成一直有可读事件,造成busy-loop;读到的数据当然就需要有个应用层的缓冲区来存放;
因为应用的缓存区是有限的,可以默认设置一个大小,比如2kb,或者根本就不设置初始大小,用多少分配多少;muduo中使用的是vector 来作为缓存区,可以动态增长;

muduo buffer使用的技巧:
buffe采用了vector自动增长的数据结构;
从系统内核中调用的时候,在应用层需要有足够大的缓冲区,最好能一次将系统recv到的缓冲区给读空,一次系统调用就搞定一切事情;
而应用缓冲区考虑到有很多个并发的可能,针对每个连接一次都分配较大的缓冲区浪费严重,陈硕推荐使用readv一次读入到两个地址中,首先将第一个地址填满,如果还有更多数据,就写入到临时缓冲区中,然后append到应用缓冲区;

读的时候使用readv,局部使用一个足够大的额外空间(64KB),这样,一次读取就足以将socket中的缓存区读空(一般不会超过64K,tcp buffer如果确实要设置大的缓存区,需要调整系统参数);如果数据不多,可能内部buffer就装下了,没有额外操作,否则,多的数据读到了外部的缓存区,再append到内部缓存区:

ssize_t Buffer::readFd(int fd, int* savedErrno){ // saved an ioctl()/FIONREAD call to tell how much to read char extrabuf[65536]; struct iovec vec[2]; const size_t writable = writableBytes(); vec[0].iov_base = begin()+writerIndex_; vec[0].iov_len = writable; vec[1].iov_base = extrabuf; vec[1].iov_len = sizeof extrabuf; // when there is enough space in this buffer, don't read into extrabuf. // when extrabuf is used, we read 128k-1 bytes at most. const int iovcnt = (writable < sizeof extrabuf) ? 2 : 1; //只有一次系统调用:这里的实现比较巧妙 const ssize_t n = sockets::readv(fd, vec, iovcnt); if (n < 0) {  *savedErrno = errno; } else if (implicit_cast<size_t>(n) <= writable) {  writerIndex_ += n; } else {  writerIndex_ = buffer_.size();  append(extrabuf, n - writable); } // if (n == writable + sizeof extrabuf) // { //  goto line_30; // } return n;}

发送消息

网络编程中数据发送比数据接受要难处理;
数据的接收,只需要peek足够的数据后,就可以从应用缓冲区接收出来,然后处理;而数据的发送,还需要考虑对方接受缓慢的情况,导致tcp发送缓冲区累积,最终导致应用缓冲区累积;

举个例子:某客户端对echo服务器只发送,但故意不接收;
客户端如果只是发送,但从不接收的话,那么这边发送过去的报文,首先会导致客户端的tcp接收缓冲区满,然后通过ack报文告诉服务器端,这边的滑动窗口为0了,不能再发了;后续客户端发送的报文就把服务器端TCP发送缓冲区积满,然后累积应用层的发送缓冲区(因为是非阻塞),最终导致服务端的应用缓存区满或者内存撑爆;

需要发送数据的时候,优先直接调用write()发送,如果发送不成功,或没有全部发送完毕,才加入到发送缓存区,等待可写事件到来后发送;
直接调用write()发送数据时,需要先将本次需要发送的数据添加到缓存区,然后发送缓存区,不可直接发送本次数据(因为缓存区中可能有遗留的数据未发送完)

void TcpConnection::handleWrite(){ loop_->assertInLoopThread(); if (channel_->isWriting()) {   //注意,这里只调用了一次write,而没有反复调用write直到出现EAGAIN错误,   //原因是如果第一次调用没有发送完全部的数据,第二次调用几乎肯定是EAGAIN错误,   //因此这里减少了一次系统调用,这么做不影响正确性,却能够降低系统时延  ssize_t n = sockets::write(channel_->fd(),                outputBuffer_.peek(),                outputBuffer_.readableBytes());  if (n > 0)  {   outputBuffer_.retrieve(n);   if (outputBuffer_.readableBytes() == 0)   {     //如果发送缓存区为空,不再关注写事件,避免 busy loop     channel_->disableWriting();    //如果还有写完成之后的回调,加入待执行回调队列    if (writeCompleteCallback_)    {     loop_->queueInLoop(boost::bind(writeCompleteCallback_, shared_from_this()));    }    //如果此时正在关闭,调用shutdownInLoop 继续执行关闭过程    if (state_ == kDisconnecting)    {     shutdownInLoop();    }   }  }  else  {   LOG_SYSERR << "TcpConnection::handleWrite";   // if (state_ == kDisconnecting)   // {   //  shutdownInLoop();   // }  } } else {  LOG_TRACE << "Connection fd = " << channel_->fd()       << " is down, no more writing"; }}

消息发送完毕

对于低流量的服务,可以不必关心这个事件;另外,这里“发送完毕”是指将数据写入操作系统的缓冲区,后续由 TCP 协议栈负责数据的发送与重传,不代表对方已经收到数据。

其它问题

IO multiplexing 是否可以配合阻塞套接字使用?

一般都配合非阻塞socket使用,如果使用阻塞IO,可能在读写事件上阻塞当前线程,造成无法继续处理已经就绪的事件;
初学网络编程可能都会有这个想法,select返回后,如果是读事件,那么这时候tcp读缓冲区肯定是有数据,这时即使使用阻塞套接字来read,应该也不会阻塞;但这样忽略了一个点,缓冲区确实是有数据,但是很可能到达的数据并不满足你要求读的数据大小,这样read调用还是会阻塞,直到有足够的数据才返回;
那么,对于数据读不可以,对accept()总可以吧,连接事件返回,一般都是有新用户接入,这时候阻塞的accept()应该总是能够返回;但在某些情况下,可能对方刚连接上就断开了,并给服务端发送了一个RST请求,造成服务端这边将已经就绪的连接请求又移除了,这样的场景下,select返回,但是accept却无法获取新的连接,造成阻塞,直到下一个连接请求到来;(这方面的例子详见《UNIX网络编程卷1:套接字联网API》16.6节非阻塞accept() )
所以任何时候,IO multiplexing都需要配合非阻塞IO使用;

零拷贝的实现

对于内核层的实现,底层调用的是系统调用sendFile()方法;
zerocopy技术省去了将操作系统的read buffer拷贝到程序的buffer, 以及从程序buffer拷贝到socket buffer的步骤, 直接将 read buffer 拷贝到 socket buffer;
image
详见:http://www.cnblogs.com/zemliu/p/3695549.html

应用层上的实现,对于自定义的结构,一般是交换内部指针(使用C++11,可以使用move操作来实现高效交换结构体)
如果是vector等结构,使用其成员函数swap()就能达到高效的交换(类似C++11中的move操作);
例如muduo中buffer实现:通过swap实现了缓存区的指针交换,从而达到数据交换的目的,而不用拷贝缓冲区;

void swap(Buffer& rhs){  buffer_.swap(rhs.buffer_); // std::vector<char> buffer_;  std::swap(readerIndex_, rhs.readerIndex_);  std::swap(writerIndex_, rhs.writerIndex_);}

epoll使用LT

epoll使用是LT而非ET,原因如下:

  1. LT编程方便,select的经验都可同样适用;
  2. 读的时候只需要一次系统调用,而ET必须读到EAGAIN错误;减少一次系统调用,降低时延;

一般认为 edge-trigger 模式的优势在于能够减少 epoll 相关系统调用,这话不假,但网络服务程序里可不是只有 epoll 相关系统调用,为了绕过饿死问题,edge-trigger 模式下用户要自行进行 read/write 循环处理,这其中增加的系统调用和减少的 epoll 系统调用加起来,总体性能收益究竟如何?只有实际测量才知道,无法一概而论。为了降低处理逻辑复杂度,常用的事件处理库大部分都选择了 level-trigger 模式(如 libevent、boost::asio、muduo等)

参考

《UNIX网络编程卷1:套接字联网API》
《Linux多线程服务端编程:使用muduo网络库》

Posted by: 大CC | 31DEC,2015
博客:blog.me115.com [订阅]
Github:大CC