网络编程常见问题总结 1

网络编程常见问题总结 串讲(一)

  在网络程序中遇到的一些问题进行了总结, 这里主要针对的是我们常用的TCP socket相关的总结， 可能会存在错误， 有任何问题欢迎大家提出. 

  对于网络编程的更多详细说明建议参考下面的书籍 

《UNIX网络编程》 《TCP/IP 详解》 《Unix环境高级编程》

非阻塞IO和阻塞IO：

  在网络编程中对于一个网络句柄会遇到阻塞IO和非阻塞IO的概念, 这里对于这两种socket先做一下说明 

  基本概念：socket的阻塞模式意味着必须要做完IO操作（包括错误）才会返回。 非阻塞模式下无论操作是否完成都会立刻返回，需要通过其他方式来判断具体操作是否成功。

  设置：  一般对于一个socket是阻塞模式还是非阻塞模式有两种方式 fcntl设置和recv,send系列的参数.

  fcntl函数可以将一个socket句柄设置成非阻塞模式: 

  flags = fcntl(sockfd, F_GETFL, 0); fcntl(sockfd, F_SETFL, flags | O_NONBLOCK); 设置之后每次的对于sockfd的操作都是非阻塞的  

  recv, send函数的最后有一个flag参数可以设置成MSG_DONTWAIT临时将sockfd设置为非阻塞模式,而无论原有是阻塞还是非阻塞。 recv(sockfd, buff, buff_size, MSG_DONTWAIT); send(scokfd, buff, buff_size, MSG_DONTWAIT); 

区别:

  读: 

  读本质来说其实不能是读,在实际中, 具体的接收数据不是由这些调用来进行,是由于系统底层自动完成的,read也好,recv也好只负责把数据从底层缓冲copy到我们指定的位置. 对于读来说(read, 或者 recv) ，在阻塞条件下如果没有发现数据在网络缓冲中会一直等待，当发现有数据的时候会把数据读到用户指定的缓冲区，但是如果这个时候读到的数据量比较少，比参数中指定的长度要小，read并不会一直等待下去，而是立刻返回。read的原则是数据在不超过指定的长度的时候有多少读多少，没有数据就会一直等待。所以一般情况下我们读取数据都需要采用循环读的方式读取数据，一次read完毕不能保证读到我们需要长度的数据，read完一次需要判断读到的数据长度再决定是否还需要再次读取。在非阻塞的情况下，read的行为是如果发现没有数据就直接返回，如果发现有数据那么也是采用有多少读多少的进行处理．对于读而言，阻塞和非阻塞的区别在于没有数据到达的时候是否立刻返回． 

  recv中有一个MSG_WAITALL的参数　recv(sockfd, buff, buff_size, MSG_WAITALL), 在正常情况下　recv是会等待直到读取到buff_size长度的数据，但是这里的WAITALL也只是尽量读全，在有中断的情况下recv还是可能会被打断，造成没有读完指定的buff_size的长度。所以即使是采用recv + WAITALL参数还是要考虑是否需要循环读取的问题，在实验中对于多数情况下recv还是可以读完buff_size，所以相应的性能会比直接read进行循环读要好一些。不过要注意的是这个时候的sockfd必须是处于阻塞模式下，否则WAITALL不能起作用。

  写: 

  写的本质也不是进行发送操作,而是把用户态的数据copy到系统底层去,然后再由系统进行发送操作,返回成功只表示数据已经copy到底层缓冲,而不表示数据以及发出,更不能表示对端已经接收到数据. 

对于write(或者send)而言，在阻塞的情况是会一直等待直到write完全部的数据再返回．这点行为上与读操作有所不同，究其原因主要是读数据的时候我们并不知道对端到底有没有数据，数据是在什么时候结束发送的，如果一直等待就可能会造成死循环，所以并没有去进行这方面的处理；而对于write, 由于需要写的长度是已知的，所以可以一直再写，直到写完．不过问题是write是可能被打断造成write一次只write一部分数据, 所以write的过程还是需要考虑循环write, 只不过多数情况下一次write调用就可能成功.

  非阻塞写的情况下，是采用可以写多少就写多少的策略．与读不一样的地方在于，有多少读多少是由网络发送的那一端是否有数据传输到为标准，但是对于可以写多少是由本地的网络堵塞情况为标准的，在网络阻塞严重的时候，网络层没有足够的内存来进行写操作，这时候就会出现写不成功的情况，阻塞情况下会尽可能(有可能被中断)等待到数据全部发送完毕，　对于非阻塞的情况就是一次写多少算多少,没有中断的情况下也还是会出现write到一部分的情况.

 

网络编程常见问题总结 串讲(二)

超时控制:

  对于网络IO，我们一般情况下都需要超时机制来避免进行操作的线程被handle住，　经典的做法就是采用select+非阻塞IO进行判断，　select在超时时间内判断是否可以读写操作，然后采用非堵塞读写,不过一般实现的时候读操作不需要设置为非堵塞，上面已经说过读操作只有在没有数据的时候才会阻塞，select的判断成功说明存在数据，所以即使是阻塞读在这种情况下也是可以做到非阻塞的效果，就没有必要设置成非阻塞的情况了．  这部分的代码可以参考ullib中ul_sreado_ms_ex和ul_swriteo_ms_ex． 

采用ul_sreado_ms_ex读数据也是不能保证返回大于0就一定读到指定的数据长度, 对于读写操作, 都是需要判断返回的读长度或者写长度是否是需要的长度, 不能简单的判断一下返回值是否小于0. 对于ul_sreado_ms_ex的情况如果出现了发送端数据发送一半就被close掉的情况就有可能导致接收端读不到完整的数据包. 

errno 只有在函数返回值为负的时候才有效,如果返回0或者大于0的数, errno 的结果是无意义的. 有些时候 会出现read到0， 但是我们认为是错误的情况然后输出errno造成误解，一般建议在这种情况要同时输出返回值和errno的结果，有些情况由于只有errno造成了对于问题的判断失误。

长连接和短连接的各种可能的问题及相应的处理

这里主要是发起连接的客户端的问题,这里列出的问题主要是在采用同步模型的情况下才会存在的问题.

短连接:

  采用短连接的情况一般是考虑到下面的一些问题:

后端服务的问题, 考虑最简单的情况下一个线程一个连接, 如果这个连接采用了长连接那么就需要我们处理连接的线程和后端保持一一对应,然后按照某些原则进行处理(n对n的关系), 但由于一方面服务器可能增加,这样导致需要前后端保持一致,带来了更多的麻烦,另一方面线程数上不去对应处理能力也会产生影响,而短连接每次连接的时候只需要关注当前的机器,问题相对会少一些. 其实这个问题可以采用连接池的方式来解决,后面会提到. 不需要考虑由于异常带来的脏数据。负载均衡方面可以简单考虑, 无论线程数是多少还是后端服务器的数量是多少都没有关系, 每次考虑单个连接就可以了. 当然如果负载逻辑简单,并且机器相对固定,一个线程一个长连接问题也不大.

规避一些问题, 在过去有些情况下出现长连接大延时,数据没响应等问题, 测试的时候发现换短连接问题就解决了,由于时间关系就没有再继续追查, 事实上这些问题现在基本上都已经定位并且有相关的解决方案了.

  不足: 

  效率不足, 由于连接操作一般会有50ns~200ns的时间消耗,导致短连接需要消耗更多的时间会产生TIME_WAIT问题,需要做更多的守护

  长连接:

  长连接相比短连接减少了连接的时间消耗, 可以承受更高的负载. 但在使用的时候需要考虑一些问题脏数据, 在一些特殊情况(特别是逻辑错误的情况下) 会存在一些我们并不需要的数据. 这个时候的处理比较安全的方式是一旦检测到就关闭连接, 检测的方式在在发起请求前 用 前面 为什么socket写错误,但用recv检查依然成功? 介绍的方式进行检查. 不过有些程序会采用继续读把所有不需要的数据读完毕(读到 EAEGIN), 不过这种方式过分依赖逻辑了,存在了一定的风险. 不如直接断开来的简单 后端连接, 前面也提到了 在这种情况我们一般会采用连接池的方式来解决问题比如(public/connectpool中就可以维护不同的连接,使每个线程都可以均匀的获取到句柄) 服务端的处理这个时候需要考虑连接的数量,简单的方式就是一个长连接一个线程, 但是线程也不能无限增加( 增加了,可能造成大量的上下文切换使的性能下降). 我们一般在长连接的情况采用pendingpool的模型, 通过一个异步队列来缓冲, 这样不需要考虑客户端和服务端的线程数问题,可以任意配置(可以通过线下测试选择合适的线程数) 

  一些特殊的问题, 主要是长连接的延时 在后面的FAQ中会有详细的说明. 

  一般来说,对于我们多数的内部业务逻辑都是可以采用长连接模式,不会产生太多的问题.

 

网络编程常见问题总结 串讲(三)

主要线程模型优缺点和注意事项

  这里所列出的线程模型，目前在我们的public/ub下都有相关的实现，在　ubFAQ中也有相关的说明，这里主要针对这些模 型的使用做相关的说明 

  最简单的线程模型

  同时启动多个线程, 每个线程都采用accept的方式进行阻塞获取连接(具体实现上一般是先select在accept, 一方面规避低内核的惊群效应,另一方面可以做到优雅退出). 多个线程竞争一个连接, 拿到连接的线程就进行自己的逻辑处理, 包括读写IO全部都在一个线程中进行. 短连接每次重新accept, 长连接,第一次的时候accept然后反复使用. 一般来说在总连接数很少的情况下效果会比较好,相对适用于少量短连接(可以允许比线程数多一些)和不超过线程总数的长连接(超过的那些连接,除非accept的连接断开,否则不可能会有线程对它进行accept).

  但如果同一时候连接数过多会造成没有工作线程与客户端进行连接，客户端会出现大量的连接失败, 因为这个时候线程可能存在不能及时accept造成超时问题, 在有重试机制的情况下可能导致问题更糟糕. 有些程序在出现几次超时之后会长时间一直有连接超时往往就是在这种情况下发生的.

  这种模型的最大优点在于编写简单, 在正常情况下工作效果不错. 在public/ub中的xpool就是属于这种模型,建议针对连接数少的服务进行使用,比如一些一对一的业务逻辑. 

  生产者消费者模型 普通线程模型在长连接方面存在使用限制(需要对于线程数进行变化, 而线程又不是无限的), 短连接在处理同时大量连接(比如流量高峰期)的时候存在问题. 

生产者消费者模型是可以把这种影响减少. 

  对于有数据的活动连接放到异步队列中, 其他线程竞争这个队列获取句柄然后进行相关的操作. 由于accept是专门的线程进行处理, 出现被handle的情况比较少,不容易出现连接失败的情况.在大流量的情况下有一定的缓冲,虽然有些请求会出现延时,但只要在可以接受的范围内,服务还是可以正常进行. 一般来说队列的长度主要是考虑可以接受的延时程度. 

这种模式也是我们现在许多服务比较常用的模型.可以不用关心客户端和服务的线程数对应关系，业务逻辑上也是比较简单的。

但这种模式在编程的时候,对于长连接有一个陷阱，判断句柄是否可读写以前一般采用的是select, 如果长连接的连接数比工作线程还少，当所有的连接都被处理了，有连接需要放回pool中，而这个时候如果正常建立连接的监听线程正好处于select状态，这个时候必须要等到 select超时才能重新将连接放入select中进行监听，因为这之前被放入select进行监听的处理socket为空，不会有响应，这个时候由于时间的浪费造成l长连接的性能下降。一般来说某个连接数少,某个连接特别活跃就可能造成问题. 过去的一些做法是控制连接数和服务端的工作线程数以及通过监听一个管道fd,在工作线程结束每次都激活这个fd跳出这次select来控制。现在的2.6内核中的epoll在判断可读写的时候不会存在这个问题(epoll在进行监听的时候,其它线程放入或者更改, 在epoll_wait的时候是可以马上激活的), 我们现在的服务多采用epoll代替select来解决这个, 但是主要的逻辑没有变化. ub_server中epool和public/ependingpool都是采用种模式 

 异步模型 这里只做一些简单的介绍。

  上面两者模型本质都是同步的处理业务逻辑,在一个线程中处理了读请求,业务逻辑和写回响应三个过程(很多业务更复杂，但是都是可以做相应的拆封的）, 但是读和写这两个IO的处理往往需要阻塞等待, 这样造成了线程被阻塞, 如果要应付慢连接(比如外围抓取等待的时间是秒级的甚至更多), 在等待的时候其实CPU没有干多少事情, 这个时候就造成了浪费. 一种考虑是增加线程数,通过提高并发来解决这个问题, 但是我们目前的线程数还是有限的,不可能无限增加. 而且线程的增加会带来cpu对于上下文切换的代价,另一方面多个线程从一个队列中获取可用连接, 这里存在互斥线程多的时候会导致性能下降,当然这里可以通过把一个队列改多队列减少互斥来实现.  ;

  引入异步化的处理, 就是把对于IO的等待采用IO复用的方式,专门放入到一个或者若干个线程中去, 处理主逻辑的程序可以被释放出来, 只有在IO处理完毕才进行处理, 这样可以提高CPU的使用率，减少等待的时间. 一般情况下几个线程(一般和CPU的核数相当)可以应付很大的流量请求 public/kylin , ub/ub(ub事件模型)都是基于纯异步思想的异步框架。而ub中的appool是简化版本将原本ub框架中网络IO处理进行了异步化，不过目前只支持采用nshead头的模式。