wordpress 写入权限设置,seo搜索引擎优化技术教程,洛阳 网站建设 大师字画,黄页推广网站下载一、TCP为维护安全可靠机制提供了七大定时器 1、连接建立(connectionestablishment)”定时器#xff1a; 在发送SYN报文段建立一条新连接时启动。如果在75秒内没有收到响应#xff0c;连接建立将中止。 2、重传(retransmission)定时器#xff1a; 在TCP发送某个数据段时设定…一、TCP为维护安全可靠机制提供了七大定时器 1、连接建立(connectionestablishment)”定时器 在发送SYN报文段建立一条新连接时启动。如果在75秒内没有收到响应连接建立将中止。 2、重传(retransmission)定时器 在TCP发送某个数据段时设定。如果该定时器超时而对端的确认还未到达TCP将重传该数据段。重传定时器的值 (即TCP等待对端确认的时间)是动态计算的与RTT的估计值密切相关且还取决于该报文段已被重传的次数。 3、延迟ACK(delayedACK)定时器 在TCP收到必须被确认但无需马上发出确认的数据时设定。如果在200ms内有数据要在该连接上发送延迟的ACK响应就可随着数据一起发送回对端称为捎带确认。如果200ms后该确认未能被捎带出去则定时器超时此时需要发送一个立即确认。 4、持续(persist)定时器零窗口探测定时器(PT0) 在连接对端通告接收窗口为0阻止TCP继续发送数据时设定。由于连接对端发送的窗口通告不可靠(只有数据才会被确认ACK不会被确认)允许TCP继续发送数据的后续窗口更新有可能丢失。因此如果TCP有数据要发送但对端通告接收窗口为0则持续定时器启动超时后向对端发送 1字节的数据判定对端接收窗口是否已打开。 5、保活(keepalive)定时器 在TCP控制块的so_options 字段设置了SOF_KEEPALIVE选项时生效。如果连接的连续空闲时间超过2小时则保活定时器超时此时应向对端发送连接探测报文段强迫对端响应。如果收到了期待的响应 TCP可确定对端主机工作正常在该连接再次空闲超过 2小时之前TCP不会再进行保活测试。如果收到的是RST复位响应 TCP可确定对端主机已重启。如果连续若干次保活测试都未收到响应 TCP就假定对端主机已崩溃但它无法区分是主机故障还是连接故障。 6、FIN_WAIT_2定时器 当某个连接从FIN_WAIT_1状态变迁到FIN_WAIT_2状态并且不能再接收任何新数据时FIN_WAIT_2定时器启动设为10分钟。定时器超时后重新设为75秒第二次超时后连接被关闭。加入这个定时器的目的是为了避免如果对端一直不发送 FIN某个连接会永远滞留在FIN _ WAIT_ 2状态假设TCP不选用半打开功能。 7、TIME_WAIT定时器2MSL定时器 2MSL指两倍的MSL即最大报文段生存时间。当连接转移到TIME_WAIT状态即连接主动关闭时定时器启动。状态转换图那一节中已经详细说明了需要2MSL等待状态的原因。连接进入TIME_WAIT状态时定时器设定为1分钟超时后TCP控制块被删除端口号可重新使用。 8、SYN|ACK定时器 TCP服务器在收到SYN请求后发送SYN|ACK响应TCP在发送SYN|ACK响应后设置SYN-ACK定时器然后等待对端的ACK到来以完成三次握手。如果没有收到ACKTCP应该重传SYN|ACK这个功能由SYN-ACK定时器完成。由于SYN|ACK发送后并没有放入发送队列中故重传时必须重新构建SYN|ACK报文。 9、ER延时定时器 TCP发送的数据如果丢失则快速重传算法会立即重传数据而不用等到重传定时器超时从而快速地恢复数据。如果发送端接收不到足够数量(一般来说是3个)的ACK则快重传算法无法起作用这个时候就只能等待RTO超时。ER算法主要是为了解决这个问题。 在下面的条件下就会导致收不到足够的ACK 1拥塞窗口比较小 2窗口中一个很大数量的段丢失或者在传输的结尾处发生了丢包 如果满足了上面的两个条件那么就会发生发送端由于接收不到足够数量的ACK导致ER可以基于两种模式一种是基于字节的一种是基于段(segment-based)的Linux中的ER是基于段的。ER算法会在小窗口下(flight count 小于4)减小触发快重传的重复ACK的阈值比如减小到1或者2。而在Linux的实现中为了防止假超时会加上一个延迟再重传数据,这个功能就靠ER定时器实现。快重传算法无法生效. 在这些条件满足后ER定时器会被设置其超时时间是一个比重传定时器更小的值。 安装丢失探测定时器、重传定时器、坚持定时器时ER定时器就会被清除。 1有丢包事件发生 2重复的ACK小于等于乱序的阈值 3未开启FACK或没有未收到确认的包或队列首包已发送但未超时 4已发送的数据 乱序的阈值或被SACK段的数量小于阈值或允许发送skb
5thin_dupack功能未开启或当前链接并不是thin的或重复ACK的数量大于1或SACK未开启或有要发送的数据 6do_early_retrans开启 7没有重传完毕但没有确认的报文 8有被SACK的报文 9在网络中的报文数量比被SACK的报文数量多至少1个 10在网络中的报文数量少于4 11现在不允许发送数据 12sysctl_tcp_early_retrans的值是2或3 13ACK中没有ECE标记 14tp-srttsmoothed round trip time的值大于0 15icsk-icsk_retransmit_timer超时时间在延迟时间之后 值得注意的是在快速重传时不会重传已经被SACK过或被重传过的skb这些skb也许能够顺利收到在这里不重传会减小网络拥塞。 虽然定义了9个定时器但是内核中只用了4个实例(timer_list)所以有些定时器是共用一个实例的。 这4个实例分别是 icsk-icsk_retransmit_timer超时重传定时器、持续定时器、ER延迟定时器、PTO定时器。 icsk-icsk_delack_timerACK延迟定时器。 sk-sk_timer保活定时器SYNACK定时器FIN_WAIT2定时器。 death_row-tw_timerTIME_WAIT定时器 二、TCP要保证正常工作至少应该有四种计时器重传计时器、持久计时器、保活计时器和时间等待计时器。 1、 重传计时器 超时重传是TCP协议保证数据可靠性的另一个重要机制其原理是在发送某一个数据以后就开启一个计时器在一定时间内如果没有得到发送的数据报的ACK报文那么就重新发送数据直到发送成功为止。当TCP发送报文段时就创建该特定报文段的重传计时器。
可能发生两种情况 1 若在计时器截止时间到之前收到了对此特定报文段的确认则撤销此计时器。 2收到了对此特定报文段的确认之前计时器截止期到则重传此报文段并将计时器复位。 1重传超时时间 重传机制协议效率的一个关键参数是重传超时时间RTORetransmission TimeOut。RTO的值被设置过大过小都会对协议造成不利影响。如果RTO设置过大将会使发送端经过较长时间的等待才能发现报文段丢失降低了连接数据传输的吞吐量另一方面若RTO过小发送端尽管可以很快地检测出报文段的丢失但也可能将一些延迟大的报文段误认为是丢失造成不必要的重传浪费了网络资源。
如果底层网络的传输特性是可预知的那么重传机制的设计相对简单得多可根据底层网络的传输时延的特性选择一个合适的RTO使协议的性能得到优化。但是TCP的底层网络环境是一个完全异构的互联结构。在实现端到端的通信时不同端点之间传输通路的性能可能存在着巨大的差异而且同一个TCP连接在不同的时间段上也会由于不同的网络状态具有不同的传输时延。
因次TCP协议必须适应两个方面的时延差异一个是达到不同目的端的时延的差异另一个是统一连接上的传输时延随业务量负载的变化而出现的差异。为了处理这种底层网络传输特性的差异性和变化性TCP的重传机制相对于其他协议显然也将更为复杂其复杂性主要表现在对超时时间间隔的处理上。为此TCP协议使用自适应算法AdaptiveRetransmissionAlgorithm以适应互联网分组传输时延的变化。这种算法的基本要点是TCP监视每个连接的性能即传输时延由此每一个TCP连接推算出合适的RTO值当连接时延性能变化时TCP也能够相应地自动修改RTO的设定以适应这种网络的变化。 2连接往返时间 个连接而言若能够了解端点间的传输往返时间RTTRound Trip Time则可根据RTT来设置一合适的RTO。显然在任何时刻连接的RTT都是随机的无法事先预知。TCP通过测量来获得连接当前RTT的一个估计值并以该RTT估计值为基准来设置当前的RTO。自适应重传算法的关键就在于对当前RTT的准确估计以便适时调整RTO。
为了搜集足够的数据来精确地估算当前的RTTTCP对每个报文都记录下发送出的时间和收到的确认时间。每一个发送时间确认时间对就可以计算出一个RTT测量值的样本Sample RTT。TCP为每一个活动的连接都维护一个当前的RTT估计值。该值是对已经过去的一个时间段内该连接的RTT了两只的加权平均并作为TCP对连接当前实际的RTT值的一种估计。RTT估计值将在发送报文段时被用于确定报文段的RTO。为了保证它能够比较准确地反应当前的网络状态每当TCP通过测量获得了个新的RTT样本时都将对RTT的估计值进行更新。不同的更新算法或参数可能获得不同的特性。[1]
最早的TCP曾经用了一个非常简单的公式来估计当前网络的状况如下
R-aR(1-a)MRTPRb其中a是一个经验系数为0.1b通常为2。注意这是经验没有推导过程这个数值是可以被修改的。这个公式是说用旧的RTT(R)和新的RTT (M)综合到一起来考虑新的RTT(R)的大小。但又可以看到这种估计在网络变化很大的情况下完全不能做出“灵敏的反应”于是就有下面的修正公式
ErrM-AA-AgErrD-Dh(|Err|-D)RTOA4D这个递推公式甚至把方差这种统计概念也使用了进来使得偏差更加的小。而且必须要指出的是这两组公式更新都是在 数据成功传输的情况下才进行在发生数据重新传输的情况下并不使用上面的公式进行网络估计理由很简单因为程序已经不在正常状态下了估计出来的数据也是没有意义的。
如果在一个报文段中的数据被一次性地成功传输和确认那么发送端可以准确得到该报文段传输的RTT样本。但若出现了重传情况就会变得很复杂。例如一个报文段发送后出现超时TCP将在另一个报文段中重传。由于这两个报文段包含了同样的数据发送方接收到确认信息时将无法分辨出确认信息到底是针对哪个报文段的因为这两个报文段产生的确认信息可能是完全相同的确认信息既可能是针对原始报文段的这种情况可能是由于原报文段或确认在传输中被延迟造成的也可能是对重传报文段的确认。这种现象称为确认二义性Acknowledgement Ambiguiity。确认的二义性将导致TCP无法准确地估算RTT。
为了避免确认二义性带来的问题TCP采用了Karn算法来维护RTT的估计值。Karn算法规定TCP只能利用没有确认二义性既无重发、一次发送成功并得到确认的报文段的RTT样本来对RTT的估计值进行调整。 2、 坚持计时器 过让接收方指明希望从发送方接收的数据字节数即窗口大小来进行流量控制。如果窗口大小为 0这将有效地阻止发送方传送数据直到窗口变为非0为止。TCP不对ACK报文段进行确认 TCP只确认那些包含有数据的ACK报文段。如果一个确认丢失了则双方就有可能因为等待对方而使连接终止接收方等待接收数据因为它已经向发送方通告了一个非 0的窗口而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生发送方使用一个坚持定时器 (persist timer)来周期性地向接收方查询以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查 (window probe)。这个报文段只有一个字节的数据。它有一个序号但它的序号永远不需要确认甚至在计算对其他部分的数据的确认时该序号也被忽略。探测报文段提醒接收TCP确认已丢失必须重传。
坚持计时器的值设置为重传时间的数值。但是若没有收到从接收端来的响应则需发送另一个探测报文段并将坚持计时器的值加倍和复位。发送端继续发送探测报文段将坚持计时器设定的值加倍和复位直到这个值增大到门限值通常是60秒为止。在这以后发送端每隔60秒就发送一个探测报文段直到窗口重新打开。 3、 保活计时器 保活计时器使用在某些实现中用来防止在两个TCP之间的连接出现长时期的空闲。假定客户打开了到服务器的连接传送了一些数据然后就保持静默了。也许这个客户出故障了。在这种情况下这个连接将永远地处理打开状态。
要解决这种问题在大多数的实现中都是使服务器设置保活计时器。每当服务器收到客户的信息就将计时器复位。超时通常设置为2小时。若服务器过了2小时还没有收到客户的信息它就发送探测报文段。若发送了10个探测报文段每一个相隔75秒还没有响应就假定客户出了故障因而就终止该连接。
这种连接的断开当然不会使用四次握手而是直接硬性地中断和客户端的TCP连接。 如果一个给定的连接在两个小时之内没有任何动作则服务器就向客户发送一个探查报文段。客户机处于以下4种状态之一时发送探查报文。
1、客户主机依然正常运行并从服务器可达。客户机的TCP响应正常而服务器也知道对方正常工作的。服务器在两小时以后将保活定时器复位如果在两个小时定时器到时间之前有应用程序的通信量通过此连接则定时器在交换数据后的未来2小时复位。 2、客户机已经崩溃并且关闭或正在重新启动在任何一种情况下客户的TCP都没有响应服务器将不能够收到对探查的响应并在75秒后超时服务器总共发送10个这样的探查每个间隔75秒如果服务器没有收到一个响应它就认为客户主机已经关闭并终止连接。
socket函数会返回-1errno设置为ETIMEDOUT表示连接超时。 3、客户主机崩溃并已经重新启动这时服务器将收到一个对其保活探查的响应但是这个响应是一个复位使得服务器终止这个连接。客户端的TCP发送RST服务器端收到后关闭此连接。
socket函数会返回-1errno设置为ECONNRESET表示连接被对端复位了 4、客户机正常运行但是从服务器不可达这与状态2相同因为TCP不能够区分状态4与状态2之间的区别它所能发现的就是没有收到探查的响应。
服务器不用关注客户主机被关闭和重新启动的情况当系统被操作员半闭时所的应用进程也被终止这会使客户的TCP在连接上发了一个FIN接收到FIN将使服务器的TCP响服务器进程报告文件结束使服务器可以检测到这个情况。双方的反应和第二种是一样的因为服务器不能区分对端异常与中间链路异常。
socket函数会返回-1errno设置为EHOSTUNREACH表示对端不可达 内核默认并不使用TCPKeepalive功能除非用户设置了SO_KEEPALIVE选项。
有两种方式可以自行调整保活定时器的参数一种是修改TCP参数一种是使用TCP层选项。 (1) TCP参数
tcp_keepalive_time
最后一次数据交换到TCP发送第一个保活探测报文的时间即允许连接空闲的时间默认为7200s。
tcp_keepalive_intvl
保活探测报文的重传时间默认为75s。
tcp_keepalive_probes
保活探测报文的发送次数默认为9次。 一次完整的保活探测需要花费时间tcp_keepalive_time tcp_keepalive_intvl*tcp_keepalive_probes默认值为7875s。
如果觉得两个多小时太长了可以自行调整上述参数。 (2) TCP层选项
TCP_KEEPIDLE含义同tcp_keepalive_time。
TCP_KEEPINTVL含义同tcp_keepalive_intvl。
TCP_KEEPCNT含义同tcp_keepalive_probes。 TCP参数是面向本机的所有TCP连接一旦调整了对所有的连接都有效。
而TCP层选项是面向一条连接的一旦调整了只对本条连接有效。 激活 在连接建立后可以通过设置SO_KEEPALIVE选项来激活保活定时器。
int keepalive 1;
setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE,keepalive,sizeof(keepalive));
可以使用TCP层选项来动态调整保活定时器的参数。
int keepidle 600;
int keepintvl 10;
int keepcnt 6;
setsockopt(fd, SOL_TCP, TCP_KEEPIDLE, keepidle,sizeof(keepidle));
setsockopt(fd, SOL_TCP, TCP_KEEPINTVL,keepintvl,sizeof(keepintvl));
setsockopt(fd, SOL_TCP, TCP_KEEPCNT, keepcnt,sizeof(keepcnt)); LinuxSO_KEEPALIVE属性,心跳包
对于面向连接的TCP socket,在实际应用中通常都要检测对端是否处于连接中,连接端口分两种情况:
1、连接正常关闭,调用close() shutdown()连接优雅关闭,send与recv立马返回错误,select返回SOCK_ERR;
2、连接的对端异常关闭,比如网络断掉,突然断电.
对于第二种情况,判断连接是否断开的方法有一下几种:
1、自己编写心跳包程序,简单的说就是自己的程序加入一条线程,定时向对端发送数据包,查看是否有ACK,根据ACK的返回情况来管理连接。此方法比较通用,一般使用业务层心跳处理,灵活可控,但改变了现有的协议;
2、使用TCP的keepalive机制,UNIX网络编程不推荐使用SO_KEEPALIVE来做心跳检测。
keepalive原理:TCP内嵌有心跳包,以服务端为例,当server检测到超过一定时间(/proc/sys/net/ipv4/tcp_keepalive_time7200 即2小时)没有数据传输,那么会向client端发送一个keepalivepacket,此时client端有三种反应:
1、client端连接正常,返回一个ACK.server端收到ACK后重置计时器,在2小时后在发送探测.如果2小时内连接上有数据传输,那么在该时间的基础上向后推延2小时发送探测包;
2、客户端异常关闭,或网络断开。client无响应,server收不到ACK,在一定时间(/proc/sys/net/ipv4/tcp_keepalive_intvl75 即75秒)后重发keepalive packet, 并且重发一定次数(/proc/sys/net/ipv4/tcp_keepalive_probes9 即9次);
3、客户端曾经崩溃,但已经重启.server收到的探测响应是一个复位,server端终止连接。
修改三个参数的系统默认值
临时方法:向三个文件中直接写入参数,系统重启需要重新设置;
临时方法:sysctl -w net.ipv4.tcp_keepalive_intvl20
全局设置:可更改/etc/sysctl.conf,加上:
net.ipv4.tcp_keepalive_intvl 20
net.ipv4.tcp_keepalive_probes 3
net.ipv4.tcp_keepalive_time 60
有关SO_KEEPALIVE的三个参数详细解释如下:
tcp_keepalive_intvl保活探测消息的发送频率。默认值为75s。
发送频率tcp_keepalive_intvl乘以发送次数tcp_keepalive_probes就得到了从开始探测直到放弃探测确定连接断开的时间大约为11min。
tcp_keepalive_probesTCP发送保活探测消息以确定连接是否已断开的次数。默认值为9次。
注意只有设置了SO_KEEPALIVE套接口选项后才会发送保活探测消息。tcp_keepalive_time在TCP保活打开的情况下最后一次数据交换到TCP发送第一个保活探测消息的时间即允许的持续空闲时间。默认值为7200s2h。
#include sys/types.h
#include sys/socket.h
#include netinet/tcp.h
int keepAlive 1; // 开启keepalive属性
int keepIdle 60; // 如该连接在60秒内没有任何数据往来,则进行探测
int keepInterval 5; // 探测时发包的时间间隔为5 秒
int keepCount 3; // 探测尝试的次数.如果第1次探测包就收到响应了,则后2次的不再发.
setsockopt(rs, SOL_SOCKET, SO_KEEPALIVE,(void*)keepAlive, sizeof(keepAlive));
setsockopt(rs, SOL_TCP,TCP_KEEPIDLE,(void*)keepIdle, sizeof(keepIdle));
setsockopt(rs, SOL_TCP, TCP_KEEPINTVL,(void*)keepInterval, sizeof(keepInterval));
setsockopt(rs, SOL_TCP, TCP_KEEPCNT,(void*)keepCount, sizeof(keepCount)); 4、 时间等待计时器 时间等待计时器是在四次握手的时候使用的。四次握手的简单过程是这样的假设客户端准备中断连接首先向服务器端发送一个FIN的请求关闭包FINfinal然后由established过渡到FIN-WAIT1状态。服务器收到FIN包以后会发送一个ACK然后自己由established进入CLOSE-WAIT。此时通信进入半双工状态即留给服务器一个机会将剩余数据传递给客户端传递完后服务器发送一个FINACK的包表示我已经发送完数据可以断开连接了接着便进入LAST_ACK阶段。客户端收到以后发送一个ACK表示收到并同意请求接着由FIN-WAIT2进入TIME-WAIT阶段。服务器端收到ACK结束连接。此时即客户端发送完ACK包以后客户端还要等待2MSL(MSLmaxinumsegmentlifetime 最长报文生存时间2MSL就是两倍MSL才能真正关闭连接。
等待2MSL是因为客服端发送的ACK对方可能没有收到1此时服务端就要重FINACK包所以2MSL是从客服端发ACK对方没有到然后服务端重发FINACK的最长时间等2MSL就是为了保证对方已经收到ACK包了。若不然客户端提早断开的话服务器端一直重发FINACK永远无法进入CLOSE状态。
时间等待计时器就是用来记2MSL这个时间的当计时器到了2MSL以后客服端才能断开连接。2能够保证之前某些在网络中滞留很久的发给服务器的报文不会在本次连接连接关闭后再去骚扰服务器。 值得注意的是最后两次挥手期间启动了两种计时器服务器向客户端发送FIN后启动重传计时器客户端收到FIN后向服务器发送ACK同时启动Time-Wait计时器时间长度为2MSL 。
