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

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

连接建立

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

步骤为：

使用异步connect直接连接一次，因为使用了非阻塞，函数立刻返回；
检查返回值，为0成功连接，否则加入到select/epoll中监控；
当有写事件时，连接成功；当即可读又可写时，可能是有错误或者连接成功后有数据已经发过来；所以，此时，需要用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报文(也可能是组合成一个报文发送）；

消息到达

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

处理分包

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

固定长度；
特殊的结尾符，比如字符串的\0，或者回车换行等；
固定的消息头中指定后续的消息的长度，然后跟上一个消息体内容；
使用协议本身的格式，比如json格式头尾配对（XML也一样）；

字节序转换注意字节对齐

如果传输的是二进制类型，在字节流的缓存区中直接强转可能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；

详见：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，原因如下：

LT编程方便，select的经验都可同样适用；
读的时候只需要一次系统调用，而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

posted @ 2015-12-31 16:22 大CC 阅读(6501) 评论(0) 编辑收藏举报

刷新页面返回顶部

大CC

关注 Nosql/Docker/阅读分享

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

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

连接建立

连接断开

消息到达

处理分包

字节序转换注意字节对齐

应用层缓存区的实现

发送消息

消息发送完毕

其它问题

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

零拷贝的实现

epoll使用LT

参考