网络编程常见问题总结.docx
- 文档编号:18384231
- 上传时间:2023-08-16
- 格式:DOCX
- 页数:19
- 大小:35.03KB
网络编程常见问题总结.docx
《网络编程常见问题总结.docx》由会员分享,可在线阅读,更多相关《网络编程常见问题总结.docx(19页珍藏版)》请在冰点文库上搜索。
网络编程常见问题总结
网络编程常见问题总结
网络编程常见问题总结串讲
(一)
网络编程常见问题总结
在网络程序中遇到的一些问题进行了总结,这里主要针对的是我们常用的TCPsocket相关的总结,可能会存在错误,有任何问题欢迎大家提出.
对于网络编程的更多详细说明建议参考下面的书籍
《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头的模式。
网络编程常见问题总结串讲(四)
为什么网络程序会没有任何预兆的就退出了
一般情况都是没有设置忽略PIPE信号,在我们的环境中当网络触发brokenpipe(一般情况是write的时候,没有write完毕,接受端异常断开了),系统默认的行为是直接退出。
在我们的程序中一般都要在启动的时候加上signal(SIGPIPE,SIG_IGN);来强制忽略这种错误
write出去的数据,read的时候知道长度吗?
严格来说,交互的两端,一端write调用write出去的长度,接收端是不知道具体要读多长的.这里有几个方面的问题
write长度为n的数据,一次write不一定能成功(虽然小数据绝大多数都会成功),需要循环多次write,write虽然成功,但是在网络中还是可能需要拆包和组包,write出来的一块数据,在接收端底层接收的时候可能早就拆成一片一片的多个数据包.TCP层中对于接收到的数据都是把它们放到缓冲中,然后read的时候一次性copy,这个时候是不区分一次write还是多次write的。
所以对于网络传输中我们不能通过简单的read调用知道发送端在这次交互中实际传了多少数据.一般来说对于具体的交互我们一般采取下面的方式来保证交互的正确,事先约定好长度,双方都采用固定长度的数据进行交互,read,write的时候都是读取固定的长度.但是这样的话升级就必须考虑两端同时升级的问题。
特殊的结束符或者约定结束方式,比如http头中采用连续的/r/n来做头部的结束标志.也有一些采用的是短连接的方式,在read到0的时候,传输变长数据的时候一般采用定长头部+变长数据的方式,这个时候在定长的头部会有一个字段来表示后面的变长数据的长度,这种模式下一般需要读取两次确定长度的数据.我们现在内部用的很多都是这样的模式.比如public/nshead就是这样处理,不过nshead作为通用库另外考虑了采用通用定长头+用户自定义头+变长数据的接口。
总的来说read读数据的时候不能只通过read的返回值来判断到底需要读多少数据,我们需要额外的约定来支持,当这种约定存在错误的时候我们就可以认为已经出现了问题.另外对于write数据来说,如果相应的数据都是已经准备好了那这个时候也是可以把数据一次性发送出去,不需要调用了多次write.一般来说write次数过多也会对性能产生影响,另一个问题就是多次连续可能会产生延时问题,这个参看下面有关长连接延时的部分问题.
小提示
上面提到的都是TCP的情况,不一定适合其他网络协议.比如在UDP中接收到连续2个UDP包,需要分别读来次才读的出来,不能像TCP那样,一个read可能就可以成功(假设buff长度都是足够的)。
如何查看和观察句柄泄露问题一般情况句柄只有1024个可以使用,所以一般情况下比较容易出现,也可以通过观察/proc/进程号/fd来观察。
另外可以采用valgrind来检查,valgrind参数中加上--track-fds=yes就可以看到最后退出的时候没有被关闭的句柄,以及打开句柄的位置
为什么socket写错误,但用recv检查依然成功?
首先采用recv检查连接的是基于我们目前的一个请求一个应答的情况对于客户端的请求,逻辑一般是这样建立连接->发起请求->接受应答->长连接继续发请求recv检查一般是这样采用下面的方式:
ret=recv(sock,buf,sizeof(buf),MSG_DONTWAIT);通过判断ret是否为-1并且errno是EAGAIN在非堵塞方式下如果这个时候网络没有收到数据,这个时候认为网络是正常的。
这是由于在网络交换模式下我们作为一个客户端在发起请求前,网络中是不应该存在上一次请求留下来的脏数据或者被服务端主动断开(服务端主动断开会收到FIN包,这个时候是recv返回值为0),异常断开会返回错误.当然这种方式来判断连接是否存在并不是非常完善,在特殊的交互模式(比如异步全双工模式)或者延时比较大的网络中都是存在问题的,不过对于我们目前内网中的交互模式还是基本适用的.这种方式和socket写错误并不矛盾,写数据超时可能是由于网慢或者数据量太大等问题,这时候并不能说明socket有错误,recv检查完全可能会是正确的.一般来说遇到socket错误,无论是写错误还读错误都是需要关闭重连.
为什么接收端失败,但客户端仍然是write成功
这个是正常现象,write数据成功不能表示数据已经被接收端接收导致,只能表示数据已经被复制到系统底层的缓冲(不一定发出), 这个时候的网络异常都是会造成接收端接收失败的.长连接的情况下出现了不同程度的延时在一些长连接的条件下,发送一个小的数据包,结果会发现从数据write成功到接收端需要等待一定的时间后才能接收到,而改成短连接这个现象就消失了(如果没有消失,那么可能网络本身确实存在延时的问题,特别是跨机房的情况下)在长连接的处理中出现了延时,而且时间固定,基本都是40ms,出现40ms延时最大的可能就是由于没有设置TCP_NODELAY在长连接的交互中,有些时候一个发送的数据包非常的小,加上一个数据包的头部就会导致浪费,而且由于传输的数据多了,就可能会造成网络拥塞的情况,在系统底层默认采用了Nagle算法,可以把连续发送的多个小包组装为一个更大的数据包然后再进行发送.但是对于我们交互性的应用程序意义就不大了,在这种情况下我们发送一个小数据包的请求,就会立刻进行等待,不会还有后面的数据包一起发送,这个时候Nagle算法就会产生负作用,在我们的环境下会产生40ms的延时,这样就会导致客户端的处理等待时间过长,导致程序压力无法上去.在代码中无论是服务端还是客户端都是建议设置这个选项,避免某一端造成延时。
所以对于长连接的情况我们建议都需要设置TCP_NODELAY,在我们的ub框架下这个选项是默认设置的.
小提示:
对于服务端程序而言,采用的模式一般是
bind->listen->accept,这个时候accept出来的句柄的各项属性其实是从listen的句柄中继承,所以对于多数服务端程序只需要对于listen进行监听的句柄设置一次TCP_NODELAY就可以了,不需要每次都accept一次.设置了NODELAY选项但还是时不时出现10ms(或者某个固定值)的延时这种情况最有可能的就是服务端程序存在长连接处理的缺陷.这种情况一般会发生在使用我们的pendingpool模型(ub中的cpool)情况下,在模型的说明中有提到.由于select没有及时跳出导致一直在浪费时间进行等待.上面的2个问题都处理了,还是发现了40ms延时?
协议栈在发送包的时候,其实不仅受到TCP_NODELAY的影响,还受到协议栈里面拥塞窗口大小的影响.在连接发送多个小数据包的时候会导致数据没有及时发送出去.这里的40ms延时其实是两方面的问题:
对于发送端,由于拥塞窗口的存在,在TCP_NODELAY的情况,如果存在多个数据包,后面的数据包可能会有延时发出的问题.这个时候可以采用TCP_CORK参数,TCP_CORK需要在数据write前设置,并且在write完之后取消,这样可以把write的数据发送出去(要注意设置TCP_CORK的时候不能与TCP_NODELAY混用,要么不设置TCP_NODELAY要么就先取消TCP_NODELAY)但是在做了上面的设置后可能还是会导致40ms的延时,这个时候如果采用tcpdump查看可以注意是发送端在发送了数据包后,需要等待服务端的一个ack后才会再次发送下一个数据包,这个时候服务端出现了延时返回的问题.对于这个问题可以通过设置server端TCP_QUICKACK选项来解决.TCP_QUICKACK可以让服务端尽快的响应这个ack包.这个问题的主要原因比较复杂,主要有下面几个方面当TCP协议栈收到数据的时候,是否进行ACK响应(没有响应是不会发下一个包的),在我们linux上返回ack包是下面这些条件中的一个接收的数据足够多
处于快速回复模式(TCP_QUICKACK)存在乱序的包,如果有数据马上返回给发送端,ACK也会一起跟着发送
如果都不满足上面的条件,接收方会延时40ms再发送ACK,这个时候就造成了延时。
但是对于上面的情况即使是采用TCP_QUICKACK,服务端也不能保证可以及时返回ack包,因为快速回复模式在一些情况下是会失效(只能通过修改内核来实现)目前的解决方案只能是通过修改内核来解决这个问题,STL的同学在内核中增加了参数可以控制这个问题。
会出现这种情况的主要是连接发送多个小数据包或者采用了一些异步双工的编程模式,主要的解决方案有下面几种对于连续的多个小数据包,尽量把他们打到一个buffer中间,不过会有内存复制的问题(采用writev方式发送多个小数据包,不过writev也存在一个问题就是发送的数据包个数有限制,如果超过了IOV_MAX(我们的限制一般是1024),依然可能会出现问题,因为writev只能保证在IOV_MAX范围内的数据是按照连续发送的。
writev或者大buffer的方式在异步双工模式下是无法工作,这个时候只能通过系统方式来解决。
客户端不设置TCP_NODELAY选项,发送数据前先打开TCP_CORK选项,发送完后再关闭TCP_CORK,服务端开启TCP_QUICKACK选项采用STL修改的内核5-6-0-0,打开相关参数。
网络编程常见问题总结串讲(五)
TIME_WAIT有什么样的影响?
对于TIME_WAIT的出现具体可以参考<
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 网络 编程 常见问题 总结