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

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

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

连接建立

包括服务端接受 (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 */
} elseerr_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格式头尾配对（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 readchar 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，原因如下：

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

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