博客访问： 263786
博文数量： 107
博客积分： 3455
博客等级： 中校
技术积分： 1226
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
一& 前言每当这个时候,最好的方法就是找一本书,然后用这本书来麻痹自己.其它乱七八糟的,都滚远点吧.哈哈,屡试不爽!开始抄书了.....二& 链路层链路层作用(1)为IP模块发送和接收IP数据报.(2)为arp模块发送arp请求和接收arp应答.(3)为rarp模块发送rarp请求和接收rarp应答.以太网与IEEE 802封装以太网IP数据报的封装在RFC 894中定义. IEEE 802的ip数据报封装在1042中定义.地址字段为6Byte的物理地址.长度字段指后续数据的字节数.不包括CRC检验码.类型字段定义了后续数据的类型.CRC字段用于帧内后续字节差错的循环冗余码检验(检验和).以太网的最小长度为46字节.802的最小字节为38字节.不足空间用pad字节占位.以太网的类型字段和802的长度字段无一相同,可以用此区分两种帧格式.环回接口(loopback interface)(1)传给环回接口的任何数据都作为ip输入.(2)传给广播和多播的数据复制一份传给环回接口.(3)任何传给该主机ip的数据均传给环回接口.本机地址的数据报一般不会出现在网络上.(除特殊设置外)&& 环回接口相当于网络层下的一个特殊链路层,直接把数据报返回到ip输入队列中.最大传输单元MTU最大传输单元MTU表示链路层数据帧所能传输的最大字节数.比如以太网为1500字节.如果ip数据报比MTU大,该数据报就必须分片,每一片小于等于MTU.路径MTU表示2台主机之间的最小MTU.三& IP :网际协议IP提供不可靠,无连接的数据报传送服务.不可靠:不保证IP数据报成功到达目的地.无连接:IP不维护后续数据报的状态信息.IP首部普通的IP首部为20字节.除非包含选项字段.网络字节序,也被称为big endian字节序.TCP/IP首部中的所有二进制整数在网络中传输都要求这种字节序.版本目前大部分为4.也称为IPV4.首部长度指首部占32 bit的数目.因此IP首部最长为60 Byte,且为4 Byte的倍数.服务类型(TOS)字段包括一个3bit的优先权子字段(现在已被忽略),4 bit的TOS子字段和1 bit未用位但必须置0.4 bit的TOS分别代表:最小时延,最大吞吐量,最高可靠性和最小费用.总长度字段指整个数据报的长度.以Byte为单位.该字段16 bit,所以IP数据报的最大长度可达65535 Byte.标识字段唯一地标识主机发送的每一份数据.标志位和片偏移字段与分片重组有关.TTL(time-to-live)生存时间字段设置了数据报可以经过的最多路由器数.协议字段表示那个协议向IP传送数据报.1为ICMP协议,2为IGMP协议,6为TCP协议,17为UDP协议.首部检验和字段是根据IP首部计算的检验和码.它不对首部后面的数据进行计算.选项字段是一个可变长的可选信息.但必须为32 bit的倍数(首部长度字段所要求).IP地址为32 bit.big endian & little endianbig endian：最高字节在地址最低位,最低字节在地址最高位,依次排列.little endian：最低字节在最低位,最高字节在最高位,反序排列.比如将 0x1234 存入 0x0000 开始的内存.&mem &&& big endian&&& little endian0x0000&&&& 0x12&&&&&&&&&& 0x340x0001&&&& 0x34&&&&&&&&&& 0x12IP路由选择在一般情况下,IP从TCP,DUP,ICMP和IGMP接收数据报(即本地生成的数据)并进行发送,或者从其他接口接收数据(待转发的数据)进行转发或接收.当数据报来自某个接口:(1)IP首先判断IP地址是否为本地地址或者广播地址,如果是就送到首部协议段所指定的协议模块进行处理.(2)如果不不满足这些地址,且IP层设置为了路由功能,那么就对数据进行转发,否则数据报被丢弃.IP路由选择顺序:(1)搜索路由表,寻找与目地IP完全匹配的表目.(网络号和主机号)(2)搜索路由表,寻找与目地IP网络号相同的表目.(3)搜索路由表,寻找默认(default)表目.以上3步依次执行,成功即跳出,如果都不成功,该数据报就不能被转发.IP地址划分A类&& 0.0.0.0&& ---& 127.255.255.255B类 128.0.0.0&& ---& 191.255.255.255C类 192.0.0.0&& ---& 223.255.255.255D类 224.0.0.0&& ---& 239.255.255.255E类 240.0.0.0&& ---& 247.255.255.255四& ARP 地址解析协议ARP为IP地址与对应的硬件地址之间提供动态的映射.ARP分组格式以太网目的地址和源地址.全为1为特殊的广播地址.帧类型为后面的数据类型.ARP应答和请求都为0x0806.IP为0x0800硬件类型表示硬件地址的类型.1代表以太网地址.协议类型表示要映射的协议地址类型.0x0800表示IP地址.(有意这样设计,与包含IP数据报的以太帧类型相同)硬件地址长度和协议地址长度分别指出硬件地址和协议地址的长度,以字节为单位.操作字段指出四种操作类型.1为ARP请求,2为ARP应答,3为RARP请求,4为让RARP应答.对于一个ARP请求,除目的端硬件地址外其他的字段都有填充物.当系统收到一份协议地址为本地的ARP请求后,把自己的硬件地址填进去,然后用两个目的端地址替换两个发送端地址,把操作字段改为2,最后发送回去.如果主机收到ARP请求或发送ARP应答时,会将请求端的IP地址和物理地址存入或者更新本机的ARP缓存.ARP代理ARP请求从一个网络发往另一个网络,连接2个网络的路由可以回答该请求,这个过程叫做委托ARP或代理ARP.详见文档
注:为了能广播ARP请求,发送ARP请求的主机须认为接收请求的主机与它在同一网段.免费ARP指主机广播ARP请求查询自己的IP地址.作用:(1)确定同一网段中是否有与本机相同的IP.(2)更新同一网段内其他们主机保存的该请求IP的ARP缓存.五 RARP 逆地址解析协议RARP的实现为读取物理地址,然后发送RARP请求,最后RARP服务器在应答中返回该物理地址对应的IP.RARP服务器RARP服务器提供物理地址到IP地址的映射,该映射包含在磁盘文件中.内核一般不读取磁盘文件,因此RARP服务器由用户进程来实现,而不能作为内核的TCP/IP来实现.ARP服务器是内核的TCP/IP一部分.每台主机都可以充当ARP服务器应答ARP请求,而RARP需要专门的RARP服务器.六 ICMP Internet控制报文协议ICMP被认为是IP层的组成部分,传递差错报文及其他需要注意的信息.ICMP报文被封装在IP数据报中.ICMP报文类型字段包含15种值,描述特定类型的ICMP报文.代码字段进一步描述不同条件.检验和覆盖整个报文段.下列情况不会产生差错报文:(1)ICMP差错报文不会再次产生差错报文.防止一直循环下去.(2)目的地址是广播或多播地址的IP数据报.(3)链路层广播的数据报.(4)不是IP分片的第一片.(5)源地址不是单个主机的数据报.这些规则为了防止过去允许ICMP差错报文响应广播分组而带来的广播风暴.ICMP差错报文包含产生该差错报文的数据报IP首部,并至少包含该IP首部后面的前8个字节.(1)IP首部包含协议字段,使ICMP知道如何解析后面的8个字节.(2)IP首部后面的前8个字节实际为TCP或UDP首部的一部分,包含了源端口和目的端口号.通过协议和端口号即可把ICMP差错报文返回给用户进程进行处理.七 Ping程序Ping程序发送ICMP回显报文给目标主机,并等待返回ICMP回显应答.八 Traceroute程序traceroute程序使用ICMP报文和IP首部的TTL字段来实现.运行原理:(1)首先发送TTL为1的IP数据报给目标地址,处理这个IP数据报的第一个路由器把TTL减1为0,丢弃该数据报,并返回一份超时ICMP报文,由此得到第一个路由器的IP(入口IP).(2)再次发送TTL为2的IP数据报给目标地址,第二个路由器把TTL减1为0,步骤同上,通过返回的超时ICMP报文,得到了第二个路由器的IP地址.(3)然后依次发送TTL为3,4...n的数据报,分别记录返回的超时ICMP报文的IP,即对应跳的路由IP.(4)最终达到目标地址.判断依据:发送的IP数据报封装的为UDP数据报,选择的是一个不可能使用的UDP端口,当到达目标地址时,目标地址将返回'端口不可达'的ICMP报文,而不是路由返回的超时ICMP报文.九 IP选路路由表标志:U 该路由可用.G 该路由通过路由转发与目的地址相连,无此标志表示本机与目的地址在同一网络而直接相连.H 该路由的目的地址为主机地址,无此标志表示目的地址为网络地址.D 该路由由重定向报文创建.M 该路由被重定向报文修改.标识G区别了间接路由和直接路由.有G即为间接路由.发往直接路由的分组包含目的地址的IP和链路层地址.发往间接路由的分组包含目的地址的IP,但链路层地址为间接路由的地址.ICMP主机与网络不可达错误当路由器收到一份IP数据报但不能转发,将向原始发送端发送ICMP'主机不可达'差错报文.ICMP重定向报文(1)主机通过默认路由发送IP数据报到R1.(2)R1通过自己的路由表发现R2是该IP数据报的下一站.&& R1发现接收主机数据报使用的端口和发送给R2使用的端口相同.即主机与R2也在同一局域网下.(3)R1向主机发送ICMP重定向报文,修改主机的路由表,以后主机直接把数据报发往R2.十 动态选路协议十一 UDP 用户数据报协议UDP首部端口号表示发送进程和接收进程.UDP长度指UDP首部和数据的总长度.UDP检验和覆盖UDP首部和数据.(不包括伪首部)UDP伪首部包含了IP首部的一些字段,只在计算UDP校验和时使用,并不实际存在.UDP检验和UDP校验和包含UDP伪首部,UDP首部和数据,如果数据不足16bit的整数倍,填充0补数.当接收端检查到校验和有误,直接丢弃DUP报文,而不产生差错报文.(与IP层检查IP首部校验和有错误时操作相同)TCP/IP协议使用的校验和都是16位的反码和,所以不能检查出交换2个16位的差错.IP分片IP首部中的16位标识字段,3位标志字段和13位片偏移字段作用于IP分组重组.标识字段标识每一份IP数据报,IP数据报分片时该字段复制到每个分片中.标志字段其中一位表示"更多的片",除最后一片外,其他分组数据报都置为1.另一位表示"不分片位",如果置为1,当需要对IP数据报分片时,丢弃数据报并发送ICMP差错报文(需要分片但设置了不分片选项).片偏移字段表示该片偏移原始数据报开始处的位置.分片重组过程(1)当IP层收到一份IP数据报,首先IP选路,然后查询该接口MTU,如果IP数据报长度大于接口MTU,既要IP分片.(2)IP数据报分片,到达最终目的地址才进行重新组装.(3)分组和重组发生在网络层(IP),对运输层(UDP/TCP)是透明的.(4)即使丢失了一片数据报,重传整个IP数据报.因为IP层没有超时重传机制,该机制由更高层协议提供,如TCP.(5)在分片中,除最后一片外,其他数据部分(除IP首部外的数据)必须为8bit的倍数.(6)传输层首部只出现在第一片IP数据报中.IP数据报指IP层端到端的传输单元(在分片之前和重组之后).分组指在IP层和链路层之间传输的数据单元.分组可以为一个完整的IP数据报,也可以为IP数据报的一个分片.然后把分组封装成链路层的数据帧.ICMP不可达差错(需要分片)当路由器收到一份需要转发的数据报,而在IP首部设置了不分片(DF)的标识比特,那么将向发送该数据报的源地址发送ICMP不可达差错(需要分片).路径MTU发现机制即利用该差错报文实现.ICMP源站抑制差错当一个系统接收数据报的速度大于数据处理的数据,就可能产生ICMP源站抑制差错.十二 广播与多播十三 IGMP Internet组管理协议十四 DNS 域名系统十五 TFTP 简单文件传送协议十六 BOOTP 引导程序协议十七 TCP 传输控制协议TCP提供面向连接的,可靠的字节流服务.TCP首部端口号标识了接收与发送进程.序号表示一个数据报中的第一个数据字节.确认序号表示发送端希望下次收到的序号首部长度表示首部中32Bit的数目.六个标志比特URG & 紧急指针有效ACK & 确认序号有效PSH & 接收方尽快把报文交付应用层RST&& 复位连接SYN & 发起一个连接FIN&& 结束一个连接窗口大小提供流量控制的功能校验和覆盖整个TCP报文段,并加上与UDP相似的伪首部紧急指针为一个正的偏移量,和序号相加表示紧急数据最后一个字节的序号.仅当URG置1时有效.十八 TCP连接的建立与终止建立连接(1)客户端发送SYN到服务端,初始序号(ISN,此例中为 ).(2)服务端发回包含服务端的初始序号(此例中为 )的SYN报文段作为应答,并置确认序号为客户端的序号加1,因为SYN将占一个序号.(3)客户端将确认序号置为服务端的序号加1,返回ACK对服务端的SYN报文进行确认.建立连接使用的初始序号ISN随时间变化,每个连接具有不同的ISN.断开连接(1)客户端发送FIN到服务端,请求关闭客户端到服务端的连接.(2)服务端将确认序号置为客户端的序号加1,返回ACK对客户端的FIN报文进行确认.因为FIN也占一个序号.(3)服务端发送FIN到客户端,请求关闭服务端到客户端的连接.(4)客户端将确认序号置为服务端的序号加1,返回ACK对服务端的FIN报文进行确认.TCP连接是全双工,因此两个方向都要进行单独的关闭.最大报文段长度最大报文段长度(MSS)表示TCP传往另一端的最大数据长度(不包括20字节的IP首部和TCP首部).MSS出现在SYN报文段中,用于建立连接时相互通知对方自己期望接收的MSS值.但并不是强制的.MSS值一般为链路层的MTU减去20字节的IP首部和20字节的TCP首部. MSS = MTU - 40Byte依赖于路径MTU的MSS值才能真正解决分片的问题.TCP半关闭当客户端发送FIN到服务端,服务端返回这个FIN的ACK后,并没有向客户端发送FIN报文段,这段时间内就叫半关闭状态.此时客户端不能向服务端发送数据,但可以接收服务端发送给她的数据.TCP状态变迁图2MSL等待状态2MSL等待状态即为TIME_WAIT状态.MSL(Maximum Segment Lifetime)表示报文段最长生存时间.当TCP执行主动关闭,并发回最后一个ACK,该连接必须在TIME_WAIT状态停留2xMSL的时间,可以让TCP再次发送最后的ACK以防止最后的ACK丢失(另一端超时重发最后的FIN).插口对(socket pair)(包括服务端ip,port和客户端ip,port的四元组)唯一确定每个TCP连接.在2MSL等待状态,定义这个连接的插口对不能被再用.TCP实现加强了该限制,默认在2MSL等待状态下,插口中使用的本地端口也不能使用,但通过SO_REUSEADDR参数可以重用该端口.注意:2MSL状态时该插口对不能使用是针对于主动关闭一方.假如服务端主动关闭,然后用SO_REUSEADDR重用该端口,如果直接用2MSL的插口对连接客户端将不会成功,但如果客户端使用插口对中的端口来连接服务端,那么将是成功的,虽然该插口对还处于2MSL状态.即允许一个连接到达任处于2MSL状态的连接.复位报文段TCP首部的RST比特表示复位.当一个连接发生错误,TCP都会返回一个RST报文段.与UDP返回ICMP差错报文类似.(1)到不存在的连接请求(2)异常终止一个连接(3)检测半打开连接同时打开同时打开将四次握手.同时关闭呼叫连接请求队列TCP处理呼入连接请求规则:(1)正等待连接的一端有一个固定长度的连接队列,该队列中的连接已经完成3次握手,但还没有被应用层接收.(2)应用层指定这个连接队列的最大长度,这个值通常叫做积压值(backlog).取值范围为0至5的整数.(3)当一个请求连接到达(SYN),TCP根据连接队列中的连接数确认是否接收这个连接.但这时的最大排队连接数并不等于积压值.(4)如果连接队列中的连接数少于最大排队的连接数,TCP将确认建立连接.&& 在客户端主动连接成功而服务端应用层还没接收这个连接时,客户端发送的数据将保存在服务端的TCP缓存队列.(5)如果连接队列没有空间,TCP将丢弃收到的SYN请求,不发回任何报文(包括RST).客户端将超时重传SYN请求,等待连接队列有空间.TCP服务器无法使客户端的主动打开失效.因为服务器接收到请求时,TCP的三次握手已经完成.所以对于限定远程IP地址的服务器,必须在客户端三次握手建立连接后才能判断是否合法.下段摘自linux man手册. 不同环境下,backlog的含义与实现都将不同.The behaviour of the backlog parameter on TCP sockets changed with Linux 2.2. Now it specifies the queue length for completely established sockets waiting to be accepted, instead of the number of incomplete connection requests. The maximum length of the queue for incomplete sockets can be set using the tcp_max_syn_backlog sysctl. When syncookies are enabled there is no logical maximum length and this sysctl setting is ignored.十九 TCP的交互数据流在TCP进行数据传输时,可以分为成块数据流和交互数据流两种,且处理的算法不同.交互式输入上图为没有优化的字符输入回显的数据传输过程.一共需要四个报文段.经受时延的确认上图第二,三个报文段可以合并---按键确认和按键回显一起发送.这种技术叫做经受时延的确认.通常TCP在接收到数据时并不立即发送ACK,将以不大于TCP定时器的延时等待是否有数据一起发送,有时也称这种现象为数据捎带ACK.ACK延时等待时间不大于TCP定时器的原因:假如TCP使用200ms的定时器,该定时器将相对于内核引导的200ms固定时间溢出,由于将要确定的数据随机到达,TCP将在下一次内核的200ms定时器溢出时得到通知,所以ACK实际等待的时间为1~200ms中任一刻.Nagle算法Nagle算法要求TCP连接上最多只有一个未被确认的未完成小分组,在该分组确认到达之前不能发送其他的小分组.且同时TCP收集这些小分组,在确认到达后以一个大的分组发出去.该算法可以减少网络上的微小分组,降低拥塞出现的可能.但相应的,也会增加更多的时延.流程:(1)发送端TCP将从应用进程接收到的第一数据块立即发送,不管其大小,哪怕只有一个字节.(2)发送端输出第一块数据后开始收集数据,并等待确认.(3)确认未达到时,若收集数据达到窗口的一半或一个MSS段,立即发送.(4)确认到达后,把缓冲区中的数据组成一个TCP段,然后发送.窗口大小通知二十 TCP的成块数据流隔一个报文段确认策略TCP处理一个接收的报文将产生一个经受时延的确定,此ACK并不立即返回,这时分两种情况 (1)TCP处理下一个报文,然后返回一个ACK确定2个报文段(可以想象成捎带ACK).(2)定时器溢出,返回ACK.如果溢出时,TCP接收缓冲区中还有数据没有被应用层读取完,那么返回报文段的窗口值将为初始窗口值减去缓冲区中的值.滑动窗口协议窗口移动:(1)窗口左边沿向右边沿靠近为窗口合拢.(2)窗口右边沿向右边移动为窗口张开.(3)窗口右边沿向左边移动为窗口收缩.窗口大小由进程控制.插口API允许进程设置发送和接收缓存的大小,接收缓存的大小是该连接上所能够通告的最大窗口大小.PUSH标志(1)发送方将发送缓冲区的数据立即发送给接收方.(2)接收方将接收缓冲区的数据立即提交给接收进程.如果待发送数据会清空发送缓冲区,该包将自动设置PUSH标志.慢启动(拥塞窗口)慢启动算法用于保证新分组进入网络的速率与另一端返回确定的速率相等.拥塞窗口是发送使用的流量控制,通告窗口是接收方使用的流量控制.成块数据吞吐量紧急方式不懂?二十一 TCP的超时与重传RTT(往返时间):指发送端发送TCP报文段开始到接收到对方的确定所使用的时间.RTO(超时重传时间):发送端发送TCP报文段后,在RTO时间内没有收到对方确定,即重传该报文段.Jacobson 1988 RTO计算公式Err = M - AA& <- A + g * ErrD& <- D + h * (|Err| - D)RTO = A + 4DA 平滑的RTT(均值估计器)D 平滑的方差g 增量h 方差的增益RTO值基于RTT的均值和方差,这更好的响应了RTT的变化.karn算法假如发送一个分组,当发生超时,RTO指数退避,重传该分组,然后收到ACK.此时但并不能确定这个ACK是针对第一个分组还是重传分组,这就是重传多义性问题.karn算法针对这个问题(1)对于超时重传的数据报的确认,不更新RTT.(2)RTO指数退避,下一次传送就使用这个RTO值.(3)重传数据确认之后,再次发送的数据如果正常被确定,恢复Jacobson 1988公式,更新RTO和RTT.RTT的测量TCP在同一时刻只测量一个RTT.即如果发送一个报文段时,如果该连接的定时器已经使用,则该报文不被计时.RTT测量值取决于TCP定时器,而TCP定时器的溢出取决于内核引导的时间.(1)连接初始化(SYN)初始值 A=0 D=3RTO = A + 2D = 6 传输初始SYN使用的值.( 初始化使用2D, 以后都使用4D)如果超时,计算此时的 RTO = A + 4D =12 ,然后指针退避,下次RTO为24.(2)第一个数据报文段初始值 A=0 D=0 M为RTT的测量值A&& = M + 0.5D&& = A / 2RTO = A + 4D(3)以后的数据报Err = M - A
A&& = A + g * Err
D&& = D + h * (|Err| - D)
RTO = A + 4D拥塞避免算法拥塞避免算法和慢启动算法通常一起使用.维持两个变量: 拥塞窗口( cwnd )& 慢启动门限( ssthresh )(1)对一个给定的连接，初始化cwnd为1个报文段, ssthresh为65535个字节.(2)TCP输出例程的输出不能超过cwnd和接收方通告窗口的大小.拥塞避免是发送方使用的流量控制，而通告窗口则是接收方进行的流量控制.前者是发送方感受到的网络拥塞的估计,后者则与接收方在该连接上的可用缓存大小有关.(3)当拥塞发生时(超时或收到重复确认),ssthresh被设置为当前窗口大小的一半(cwnd和接收方通告窗口大小的最小值,但最少为2个报文段).此外,如果是超时引起了拥塞,则cwnd被设置为1个报文段（这就是慢启动).(4)当新的数据被对方确认时,就增加cwnd,但增加的方法依赖于我们是否正在进行慢启动或拥塞避免.如果cwnd <= ssthresh,则正在进行慢启动,否则正在进行拥塞避免.cwnd增加方式慢启动初始cwnd为1,每收到一个确定就加1.成指数增长.拥塞避免算法在每个RTT内增加 1/cwnd 个报文,成线性增长.慢启动根据收到的ACK次数增加cwnd,而拥塞避免算法在一个RTT不管收有多少ACK也只增加一次.快速重传和快速恢复算法如果收到3个重复ACK,可认为该报文段已经丢失,此时无需等待超时定时器溢出,直接重传丢失的包,这就叫快速重传算法.而接下来执行的不是慢启动而是拥塞避免算法,这就叫快速恢复算法.(1)当收到第3个重复的ACK时,将ssthresh设置为当前拥塞窗口cwnd的一半.重传丢失的报文段,设置cwnd为ssthresh加上3倍的报文段大小.(2)每次收到另一个重复的ACK时,cwnd增加1个报文段大小并发送1个分组(如果新的cwnd允许发送).(3)当下一个确认新数据的ACK到达时,设置cwnd为ssthresh(在第1步中设置的值).这个ACK应该是在进行重传后的一个往返时间内对步骤1中重传的确认.另外,这个ACK也应该是对丢失的分组和收到的第1个重复的ACK之间的所有中间报文段的确认.这一步采用的是拥塞避免,因为当分组丢失时我们将当前的速率减半.ICMP差错(1)源站抑制的ICMP将拥塞窗口cwnd置为1个报文段,并发起慢启动,慢启动门限ssthresh不变,窗口将打开直至开放了所有的通路(受窗口大小和往返时间的限制)或者发生了拥塞(2)主机不可达或网络不可达的ICMP将被忽略,继续发送直至超时,二十二 TCP坚持定时器坚持(persist)定时器周期性的向对方发送窗口探查报文,更新窗口大小.坚持定时器使用TCP指针退避.窗口探查报文包含一个字节的数据.坚持定时器一直持续到窗口打开或者应用程序关闭.糊涂窗口综合症糊涂窗口综合症指少量的数据通过连接交换,而不是满长度的报文段.避免措施:接收方接收方不通告小窗口.除非增加一个报文段(MMS)或者接收方缓存空间的一半,否则通告为0.发送方(1)可以发送一个满长度的报文段(MMS).(2)可以发送至少接收方通告窗口一半的报文段.(3)如果以前的数据都被确认或者该连接不使用Nagle算法时,可以发送任意数据.定时器工作流程:(1)发送端收到0窗口通告后,就启动坚持定时器.(2)在定时器未到,就收到非零通告,则关闭该定时器,并发送数据.(3)若定时器已到,还没有收到非零通告,就发探查报文.(4)如果探查报文ACK的通告窗口为0,就将坚持定时器的值加倍,重复1,2,3步;如果通告窗口非零,发送数据,关闭定时器.二十三 TCP包活定时器如果一个给定的连接在2小时内没有任何动作,那么服务器就向客户发送一个探查报文段.客户主机必须处于以下4个状态之一.(1)客户主机依然正常运行,并从服务器可达.客户的TCP响应正常,而服务器也知道对方的正常工作的.服务器在2小时内将保活定时器复位.(2)客户主机已经崩溃,并且关闭或者正在重新启动.在任何一种情况下,客户的TCP都没有响应.服务器将不能收到对探查的响应,并在75秒后超时.总共发送 10个探查，间隔75秒。(3)客户主机崩溃并已经重新启动.这是服务器将收到一个对其保活探查的响应,但这个响应是一个复位,使得服务器终止这个连接.(4)客户主机正常运行,但是从服务器不可达.
阅读(26024) | 评论(0) | 转发(9) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。TCP accept返回的socket，服务端TCP连接数限制
/aa/archive//183595.html
as you know,一个socket是由一个五元组来唯一标示的，即(协议，server_ip, server_port, client_ip, client_port)。只要该五元组中任何一个值不同，则其代表的socket就不同。这里忽略协议的区别，在同一协议的基础上，服务器端的listen socket的端口可以看成(server_ip, server_port, ***, ***),其中***是通配符，它跟任何一个client_ip, client_port值都不同，可以简单看成是（0,0）对，当然实现不是这样的。这样在服务器端accept之后，返回的连接socket的四元组就是(server_ip, server_port, client_ip, client_port)，这里的client_ip，client_port因连接的客户端的不同而不同。所以accept返回的socket和listen socket是不同的，不同之处就在于四元组中的客户端ip和port，而服务器端的server_ip和server_port还是相同的，也就是accpet()函数返回的新的socket描述符的端口和listen端口是一样的。可以使用getsockname()函数来查看它们之间的不同。
http://blog.csdn.net/hanzengyi/article/details/5365029
accept是又产生一个Socket端口吗？
&&&&& 要写网络程序就必须用Socket，这是程序员都知道的。而且，面试的时候，我们也会问对方会不会Socket编程？一般来说，很多人都会说，Socket编程基本就是listen，accept以及send，write等几个基本的操作。是的，就跟常见的文件操作一样，只要写过就一定知道。
&&&&& 对于网络编程，我们也言必称TCP/IP，似乎其它网络协议已经不存在了。对于TCP/IP，我们还知道TCP和UDP，前者可以保证数据的正确和可靠性，后者则允许数据丢失。最后，我们还知道，在建立连接前，必须知道对方的IP地址和端口号。除此，普通的程序员就不会知道太多了，很多时候这些知识已经够用了。最多，写服务程序的时候，会使用多线程来处理并发访问。
我们还知道如下几个事实：
&&&& 1.一个指定的端口号不能被多个程序共用。比如，如果IIS占用了80端口，那么Apache就不能也用80端口了。
&&&& 2.很多防火墙只允许特定目标端口的数据包通过。
&&&& 3.服务程序在listen某个端口并accept某个连接请求后，会生成一个新的socket来对该请求进行处理。
&&&& 于是，一个困惑了我很久的问题就产生了。如果一个socket创建后并与80端口绑定后，是否就意味着该socket占用了80端口呢？如果是这样的，那么当其accept一个请求后，生成的新的socket到底使用的是什么端口呢（我一直以为系统会默认给其分配一个空闲的端口号）？如果是一个空闲的端口，那一定不是80端口了，于是以后的TCP数据包的目标端口就不是80了--防火墙一定会阻止其通过的！实际上，我们可以看到，防火墙并没有阻止这样的连接，而且这是最常见的连接请求和处理方式。我的不解就是，为什么防火墙没有阻止这样的连接？它是如何判定那条连接是因为connet80端口而生成的？是不是TCP数据包里有什么特别的标志？或者防火墙记住了什么东西？
&&&&& 后来，我又仔细研读了TCP/IP的协议栈的原理，对很多概念有了更深刻的认识。比如，在TCP和UDP同属于传输层，共同架设在IP层（网络层）之上。而IP层主要负责的是在节点之间（End to End）的数据包传送，这里的节点是一台网络设备，比如计算机。因为IP层只负责把数据送到节点，而不能区分上面的不同应用，所以TCP和UDP协议在其基础上加入了端口的信息，端口于是标识的是一个节点上的一个应用。除了增加端口信息，UPD协议基本就没有对IP层的数据进行任何的处理了。而TCP协议还加入了更加复杂的传输控制，比如滑动的数据发送窗口（Slice Window），以及接收确认和重发机制，以达到数据的可靠传送。不管应用层看到的是怎样一个稳定的TCP数据流，下面传送的都是一个个的IP数据包，需要由TCP协议来进行数据重组。
&&&&& 所以，我有理由怀疑，防火墙并没有足够的信息判断TCP数据包的更多信息，除了IP地址和端口号。而且，我们也看到，所谓的端口，是为了区分不同的应用的，以在不同的IP包来到的时候能够正确转发。
&&&& TCP/IP只是一个协议栈，就像操作系统的运行机制一样，必须要具体实现，同时还要提供对外的操作接口。就像操作系统会提供标准的编程接口，比如Win32编程接口一样，TCP/IP也必须对外提供编程接口，这就是Socket编程接口--原来是这么回事啊！
在Socket编程接口里，设计者提出了一个很重要的概念，那就是socket。这个socket跟文件句柄很相似，实际上在BSD系统里就是跟文件句柄一样存放在一样的进程句柄表里。这个socket其实是一个序号，表示其在句柄表中的位置。这一点，我们已经见过很多了，比如文件句柄，窗口句柄等等。这些句柄，其实是代表了系统中的某些特定的对象，用于在各种函数中作为参数传入，以对特定的对象进行操作--这其实是C语言的问题，在C++语言里，这个句柄其实就是this指针，实际就是对象指针啦。
现在我们知道，socket跟TCP/IP并没有必然的联系。Socket编程接口在设计的时候，就希望也能适应其他的网络协议。所以，socket的出现只是可以更方便的使用TCP/IP协议栈而已，其对TCP/IP进行了抽象，形成了几个最基本的函数接口。比如create，listen，accept，connect，read和write等等。
现在我们明白，如果一个程序创建了一个socket，并让其监听80端口，其实是向TCP/IP协议栈声明了其对80端口的占有。以后，所有目标是80端口的TCP数据包都会转发给该程序（这里的程序，因为使用的是Socket编程接口，所以首先由Socket层来处理）。所谓accept函数，其实抽象的是TCP的连接建立过程。accept函数返回的新socket其实指代的是本次创建的连接，而一个连接是包括两部分信息的，一个是源IP和源端口，另一个是宿IP和宿端口。所以，accept可以产生多个不同的socket，而这些socket里包含的宿IP和宿端口是不变的，变化的只是源IP和源端口。这样的话，这些socket宿端口就可以都是80，而Socket层还是能根据源/宿对来准确地分辨出IP包和socket的归属关系，从而完成对TCP/IP协议的操作封装！而同时，放火墙的对IP包的处理规则也是清晰明了，不存在前面设想的种种复杂的情形。
明白socket只是对TCP/IP协议栈操作的抽象，而不是简单的映射关系，这很重要！
http://blog.csdn.net/zztfj/article/details/http://blog.csdn.net/zztfj/article/details/
&单机最大的TCP连接数及其修改 一个误解:&单个服务器程序可承受最大连接数“理论”上是“65535” .
&& 65535这个数字的由来，很多人想当然地将它与port最大值联系起来。的确，TCP的端口数，最大值确实为65535。但是，这并不代表一个服务器可以接受的连接数就是这个值。很多人之所以把这两个概念搞混淆是因为对socket和port没有更深的认识和理解。我们先来回想一下服务器服务的先后过程： 1、服务器创建监听socket 2、与对外服务的端口号绑定 3、开始listen 4、客户端连接到服务器对应的port 5、服务器accept为新的客户端产生新的socket 6、基于这个新的socket与客户端交换数据。 从以上流程来看，最大值为65535的“端口号”这个重要的东东，我们只用了一次，就是执行bind的时候！而以后创建的socket，说白了就是一个可以进行网络IO操作的HANDLE而已。通过查看该HANDLE的RemoteEndPoint能查看到远程客户端连接的IP和端口号（注意，该端口是远程客户端的端口），查看该HANDLE的LocalEndPoint能看到该Socket的Ip和端口就是该服务绑定的IP和端口。所以，accept的socket值与端口号无关，又何来65535的“理论”上限？
好了，已经弄明白了服务器端接收的客户端连接连接数不受最大端口号65535的限制。但是，在客户端，应用程序最多可以建立多少个TCP连接呢？以及如何调整系统参数来调整单机的最大TCP连接数。
Windows 下单机的TCP连接数有多个参数共同决定，下面一一介绍：
最大TCP连接数 [HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Tcpip \Parameters] TcpNumConnections = 0x00fffffe (Default = 16,777,214)
以上注册表信息配置单机的最大允许的TCP连接数，默认为 16M。这个数值看似很大，这个并不是限制最大连接数的唯一条件，还有其他条件会限制到TCP 连接的最大连接数。
最大动态端口数 TCP客户端和服务器连接时，客户端必须分配一个动态端口，默认情况下这个动态端口的分配范围为
，也就是说默认情况下，客户端最多可以同时发起3977 个Socket 连接。我们可以修改如下注册表来调整这个动态端口的范围
[HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Tcpip \Parameters] MaxUserPort = 5000 (Default = 5000, Max = 65534)
最大TCB 数量 系统为每个TCP 连接分配一个TCP 控制块(TCP control block or TCB)，这个控制块用于缓存TCP连接的一些参数，每个TCB需要分配 0.5 KB的pagepool 和 0.5KB 的Non-pagepool，也就说，每个TCP连接会占用 1KB 的系统内存。
系统的最大TCB数量由如下注册表设置决定
[HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Tcpip \Parameters] MaxFreeTcbs = 2000 (Default = RAM dependent, but usual Pro = 1000, Srv=2000)
非Server版本，MaxFreeTcbs 的默认值为1000 （64M 以上物理内存）
Server 版本，这个的默认值为 2000。
也就是说，默认情况下，Server 版本最多同时可以建立并保持2000个TCP 连接。
最大TCB Hash table 数量 TCB 是通过Hash table 来管理的，下面注册表设置决定了这个Hash table 的大小
HKEY_LOCAL_MACHINE \System \CurrentControlSet \services \Tcpip \Parameters] MaxHashTableSize = 512 (Default = 512, Range = 64-65536)
这个值指明分配 pagepool 内存的数量，也就是说，如果MaxFreeTcbs = 1000 , 则 pagepool 的内存数量为 500KB
那么 MaxHashTableSize 应大于 500 才行。这个数量越大，则Hash table 的冗余度就越高，每次分配和查找 TCP& 连接用时就越少。这个值必须是2的幂，且最大为65536.
IBM WebSphere Voice Server 在windows server 2003 下的典型配置 这是IBM WebSphere Voice Server 的典型配置，大家可以做个参考。原文参见
IBM Web Sphere Voice Server 配置
oMaxUserPort = 65534 (Decimal) oMaxHashTableSize = 65536 (Decimal) oMaxFreeTcbs = 16000 (Decimal)& 这里我们可以看到 MaxHashTableSize 被配置为比MaxFreeTcbs 大4倍，这样可以大大增加TCP建立的速度。
/question/
现在 epoll 单机（4G内存）并发量最大能达到多少？
按投票排序
按照题主的意思 是根据内存去算一个最大并发的连接数. 那么首先要找出来单个连接消耗内存的地方.
第一个首先是socket buffer. read 和write 分别有一个, 默认大小在
默认大小都是87K和16K, 最低是4K和4K, 最高是2M,2M, 实际使用默认值最低也要保留8K,8K.
然后是逻辑IO缓冲区
就是比如你监听了recv事件 事件来了 你要有内存可用(一般都是socket建立起就分配好,断开才会释放的).
这个内存是自己写socket程序时候自己控制的, 最低也要4K,4K, 实际使用8K,8K至少.
现在设定一个优化方案和使用场景, 首先假设4G内存全部为空闲(系统和其他进程也要内存的....
假如网络包的大小都可以控制在4K以下, 假设所有连接的网络都不会拥堵, 或者拥堵时候的总量在4K以下:
一个连接的内存消耗是4+4+4+4=16K
4G/16K=26.2万并发
假如网络包的大小都可以控制在8K以下, 假设所有连接的网络都不会拥堵, 或者拥堵时候的总量在8K以下
一个socket的内存占用介于 24K ~ 32K之间, 保守的按照32K算&
4G/32K=13.1万并发, 这个在生产环境作为一个纯网络层面的内存消耗, 是可以作为参考的.
假如使用默认配置, 假如所有连接的网络都出现严重拥堵, 不考虑逻辑上的发送队列的占用,
使用默认配置是2M+2M+8+8 ~= 4M
4G/4M=1024并发 ( ... 如果考虑到发送队列也拥堵的话 自己脑补.
如果只是为了跑分 为了并发而优化, 没有常驻的逻辑缓冲区 并且socket的网络吞吐量很小并且负载平滑, 把socket buffer size设置系统最低.
4G/8K = 52.4万并发 这个应该是极限值了.
楼上答的不错了，记得这个好像是百度的面试题，在群里有人问过，当时关注了下，题主可以man下epoll就明白楼上的解释了
本分类共有文章20篇,更多信息详见
& 2012 - 2016 &
&All Rights Reserved. &
/*爱悠闲图+*/
var cpro_id = "u1888441";
/*爱悠闲底部960*75*/
var cpro_id = "u1888128";}