还剩6页未读,继续阅读
文本内容:
对于网络问题的总结 网络方案技术是利用图论和网络分析的方法编制和优化实施方案的一种科学手段今天OK给大家带来了对于网络问题的总结,希望对大家有所帮助 我的主要科研方向为下一代网络SDN以及云计算中网络研究,但是传统网络开展到如此成熟的一个地步,虽然存在一些问题,不过我们不应该用完美来要求所有东西,传统网络的很多思想和技术都将长远地影响以后的网络开展,这篇文章欲总结一些传统网络中经常会碰到的问题 正文
1.为什么不单独的用MAC地址和IP地址来进行数据转发 如果只用MAC地址,也就是说整个网络都处于一个大二层中,都处于同一个播送域中,当世界上成百上千万的机器处于同一个播送域的时候,结果可想而知 如果只是用IP地址,这个问题我只想了下面这种可能性,但是觉得解释上仍然有些缺乏,希望大神可以不吝赐教IP地址是由管理者统一分配的,所以在某个机器申请了IP地址之后,不是说这个机器的IP地址确定了,而是这个机器现在所连的这根网线的IP地址确定了,所以只有IP地址的话,如果频繁的更换或者移动机器,每次都需要重新配置机器的IP地址
2.ICMP和IGMP以及ARP和RARP属于IP/TCP协议分层中的哪一层 首先ICMP和IGMP都是IP的附属协议,所以他们有理由都属于网络层,但是在数据包的具体传输过程中,ICMP和IGMP报文都被封装在了IP数据报中 对于ARP和RARP协议来说,也是众说纷纭,有的教材将其划作网络层,有的认为是数据链路层,从逻辑上来说,数据在从上到下进行封装的过程中会加上自己的信息,当网络层的IP包进入链路层时,链路层通过ARP协议添加链路信息,而这不是网络层的功能,所以可以认为是数据链路层,但是从整个网络解析层面来说,ARP和RARP和IP数据报一样,都拥有自己的以太网数据帧类型,所以也可以认为是网络层,所以他们在哪一层并不重要,明白原理最重要,这同时也说明了网络层的划分并不是十分完美的
3.为什么常见的网络应用端口号都是奇数 端口号是用来区分不用应用的,比方我们看着视频聊着QQ,我们都需要使用网络传输数据,所以需要客户端端口号,同样的,对于效劳器而言,他要提供多种效劳,如何区分这些效劳,同样需要的是效劳器端口号如果有注意的话发现常用的、时间比拟久远的应用的端口号都是奇数,比方FTP的端口号为21,SNMP为161,Tel为23这是为什么呢因为这些端口号都是从网络控制协议即TCP前身,ARPANET的传输层协议派生出来的,原来网络控制协议是单工的,不是全双工的,因此每个应用程序需要两个连接,一个用于接收,一个用于发送,需要预留一对奇数和偶数端口号,当TCP和UDP称为了标准的传输层协议时,每个应用程序只需要一个端口号,所以就使用了原来的网络控制协议中的奇数 总结 很多技术的开展都有其深刻的历史烙印,想要精通一门技术,了解其历史是十分重要的 不向静中参妙理纵然颖悟也虚浮立乎其大和而不同古之成大事者,不惟有超世之才,亦必有坚韧不拔之志 对于网络IO,我们一般情况下都需要超时机制来防止进行操作的线程被handle住,经典的做法就是采用select+非阻塞IO进行判断,select在超时时间内判断是否可以读写操作,然后采用非堵塞读写不过一般实现的时候读操作不需要设置为非堵塞,上面已经说过读操作只有在没有数据的时候才会阻塞,select的判断成功说明存在数据,所以即使是阻塞读在这种情况下也是可以做到非阻塞的效果,就没有必要设置成非阻塞的情况了. 这局部的代码可以参考ullib中ulsreadomsex和ulswriteomsex.%G0Jd:g%C4采用ulsreadomsex读数据也是不能保证返回大于0就一定读到指定的数据长度对于读写操作都是需要判断返回的读长度或者写长度是否是需要的长度不能简单的判断一下返回值是否小于
0.对于ulsreadomsex的情况如果出现了发送端数据发送一半就被close掉的情况就有可能导致接收端读不到完整的数据包.errno只有在函数返回值为负的时候才有效如果返回0或者大于0的数errno的结果是无意义的.有些时候会出现read到0,但是我们认为是错误的情况然后输出errno造成误解,一般建议在这种情况要同时输出返回值和errno的结果,有些情况由于只有errno造成了对于问题的判断失误;j;WH*d6 长连接和短连接的各种可能的问题及相应的处理N9C;f!{%R][ 这里主要是发起连接的客户端的问题这里列出的问题主要是在采用同步模型的情况下才会存在的问题. 短连接:J/E.u5V:L 采用短连接的情况一般是考虑到下面的一些问题: 后端效劳的问题考虑最简单的情况下一个线程一个连接如果这个连接采用了长连接那么就需要我们处理连接的线程和后端保持一一对应然后按照某些原那么进行处理n对n的关系但由于一方面效劳器可能增加这样导致需要前后端保持一致带来了更多的麻烦另一方面线程数上不去对应处理能力也会产生影响而短连接每次连接的时候只需要关注当前的机器问题相对会少一些.其实这个问题可以采用连接池的方式来解决后面会提到.不需要考虑由于异常带来的脏数据负载均衡方面可以简单考虑无论线程数是多少还是后端效劳器的数量是多少都没有关系每次考虑单个连接就可以了.当然如果负载逻辑简单并且机器相对固定一个线程一个长连接问题也不大.躲避一些问题在过去有些情况下出现长连接大延时数据没响应等问题测试的时候发现换短连接问题就解决了由于时间关系就没有再继续追查事实上这些问题现在根本上都已经定位并且有相关的解决方案了. 缺乏: 效率缺乏由于连接操作一般会有50ns~200ns的时间消耗导致短连接需要消耗更多的时间会产生TIMEWAIT问题需要做更多的守护 长连接: 长连接相比短连接减少了连接的时间消耗可以承受更高的负载.但在使用的时候需要考虑一些问题脏数据在一些特殊情况特别是逻辑错误的情况下会存在一些我们并不需要的数据.这个时候的处理比拟平安的方式是一旦检测到就关闭连接检测的方式在在发起请求前用前面为什么socket写错误但用recv检查依然成功介绍的方式进行检查.不过有些程序会采用继续读把所有不需要的数据读完毕读到EAEGIN不过这种方式过分依赖逻辑了存在了一定的风险.不如直接断开来的简单后端连接前面也提到了在这种情况我们一般会采用连接池的方式来解决问题比方public/connectpool中就可以维护不同的连接使每个线程都可以均匀的获取到句柄效劳端的处理这个时候需要考虑连接的数量简单的方式就是一个长连接一个线程但是线程也不能无限增加增加了可能造成大量的上下文切换使的性能下降.我们一般在长连接的情况采用pendingpool的模型通过一个异步队列来缓冲这样不需要考虑客户端和效劳端的线程数问题可以任意配置可以通过线下测试选择适宜的线程数 一些特殊的问题主要是长连接的延时在后面的FAQ中会有详细的说明.2A}!^5~1O9B+V/ 一般来说对于我们多数的内部业务逻辑都是可以采用长连接模式不会产生太多的问题. 在网络编程中对于一个网络句柄会遇到阻塞IO和非阻塞IO的概念这里对于这两种socket先做一下说明5/%b8U!i;/` 根本概念 socket的阻塞模式意味着必须要做完IO操作包括错误才会返回非阻塞模式下无论操作是否完成都会立刻返回,需要通过其他方式来判断具体操作是否成功 设置 一般对于一个socket是阻塞模式还是非阻塞模式有两种方式ftl设置和recvsend系列的参数.J%fo:;S$w2Vp ftl函数可以将一个socket句柄设置成非阻塞模式: flags=ftlsockfdFGETFL0;ftlsockfdFSETFLflags|ONONBLOCK; 设置之后每次的对于sockfd的操作都是非阻塞的6B$b8ik:U5w$B recvsend函数的最后有一个flag参数可以设置成MSGDONTWAIT临时将sockfd设置为非阻塞模式而无论原有是阻塞还是非阻塞recvsockfdbuffbuffsizeMSGDONTWAIT;sendscokfdbuffbuffsizeMSGDONTWAIT;*lV-|G1U 区别: 读: 读本质来说其实不能是读在实际中具体的接收数据不是由这些调用来进行是由于系统底层自动完成的read也好recv也好只负责把数据从底层缓冲copy到我们指定的位置.对于读来说read或者recv,在阻塞条件下如果没有发现数据在网络缓冲中会一直等待,当发现有数据的时候会把数据读到用户指定的缓冲区,但是如果这个时候读到的数据量比拟少,比参数中指定的长度要小,read并不会一直等待下去,而是立刻返回read的原那么是数据在不超过指定的长度的时候有多少读多少,没有数据就会一直等待所以一般情况下我们读取数据都需要采用循环读的方式读取数据,一次read完毕不能保证读到我们需要长度的数据,read完一次需要判断读到的数据长度再决定是否还需要再次读取在非阻塞的情况下,read的行为是如果发现没有数据就直接返回,如果发现有数据那么也是采用有多少读多少的进行处理.对于读而言,阻塞和非阻塞的区别在于没有数据到达的时候是否立刻返回. recv中有一个MSGWAITALL的参数 recvsockfdbuffbuffsizeMSGWAITALL在正常情况下 recv是会等待直到读取到buffsize长度的数据,但是这里的WAITALL也只是尽量读全,在有中断的情况下recv还是可能会被打断,造成没有读完指定的buffsize的长度所以即使是采用recv+WAITALL参数还是要考虑是否需要循环读取的问题,在实验中对于多数情况下recv还是可以读完buffsize,所以相应的性能会比直接read进行循环读要好一些不过要注意的是这个时候的sockfd必须是处于阻塞模式下,否那么WAITALL不能起作用 写:/E/mA+B+r 写的本质也不是进行发送操作而是把用户态的数据copy到系统底层去然后再由系统进行发送操作返回成功只表示数据已经copy到底层缓冲而不表示数据以及发出更不能表示对端已经接收到数据.对于write或者send而言,在阻塞的情况是会一直等待直到write完全部的数据再返回.这点行为上与读操作有所不同,究其原因主要是读数据的时候我们并不知道对端到底有没有数据,数据是在什么时候结束发送的,如果一直等待就可能会造成死循环,所以并没有去进行这方面的处理;而对于write由于需要写的长度是的,所以可以一直再写,直到写完.不过问题是write是可能被打断造成write一次只write一局部数据所以write的过程还是需要考虑循环write只不过多数情况下一次write调用就可能成功.非阻塞写的情况下,是采用可以写多少就写多少的策略.与读不一样的地方在于,有多少读多少是由网络发送的那一端是否有数据传输到为标准,但是对于可以写多少是由本地的网络堵塞情况为标准的,在网络阻塞严重的时候,网络层没有足够的内存来进行写操作,这时候就会出现写不成功的情况,阻塞情况下会尽可能有可能被中断等待到数据全部发送完毕,对于非阻塞的情况就是一次写多少算多少没有中断的情况下也还是会出现write到一局部的情况.模板内容仅供参考 。