文章目录一、资源从上往下关闭1.应用层Socket视角下的关闭1.1Socket自己关闭时用的API1.1.1Socket.flush1.1.2Socket.close1.2进程崩溃时Socket被动的关闭1.2.1无抉迫划当现发送边界1.2.2无引用后遇走释放流程2.传输层TCP连接视角下的关闭2.1正常关闭机制2.1.1FIN报文2.1.1.1收发2.1.1.2分关2.1.1.3可靠2.1.2先挥方最后一个ACK报文2.1.2.1报文的确达不定2.1.2.2ACK的占比保障2.1.2.2.1方式2.1.2.2.2选择2.2异常中止机制2.2.1RST报文2.2.1.1收发2.2.1.2并关2.2.1.3不可靠2.2.1.4发送情况2.2.1.4.1连接不存在2.2.1.4.2遇到异常错误3.关机的限时关闭3.1第一限时3.1.1限时内3.1.2超时后3.2第二个限时3.2.1限时内3.2.2超时后二、靠回应验连接1.维护不确效连接的时间1.1无效连接的浪费维护1.1.1异常时机的浪费量影响2.发送频率2.1正常间隔发送消息2.2间隔很久发送消息2.2.1浪维风险2.2.2心跳措施2.2.2.1传输层keepalive2.2.2.1.1过程2.2.2.1.2作用2.2.2.1.3局限2.2.2.2应用层心跳包2.2.2.2.1优势2.2.2.2.2劣势2.2.2.3心跳抖动jitter三、负载均衡器1.健康检查1.1经受干扰1.1.1工程平衡2.选出服务3.木板资源瓶颈4.安全重传请求四、URG与PSH1.URGUrgent2.PSHPush一、资源从上往下关闭1.应用层Socket视角下的关闭进程Socket对象是里面装引用的普通变量文件描述符、内核Socket对象是引用对象变量1.1Socket自己关闭时用的API1.1.1Socket.flushSocket.flush是应用层自己决定,现在一次把此时的应用层用户态缓冲区里的全部数据,冲入到传输层发送缓冲区里进行对,用户态缓冲区-发送缓冲区的自然流速,当区量迅速发完地提速1.1.2Socket.closeSocket.close是应用层自己决定 现在自己关闭Socket对象,放FIN划出这样的发送边界的处FIN前还在发送缓冲区里与还在发送分流中未到达对方数据为预剩发送数据处FIN后还在应用层用户态缓冲区里的数据成遗弃不发数据1.2进程崩溃时Socket被动的关闭1.2.1无抉迫划当现发送边界进程崩溃,里面的堆区毁掉,Socket变量一同毁没不按自己抉择地现在就放FIN划当现发送边界就放漏了 处在当现后面,抉择中有进行的应用层数据的当后再更新应用层往传输层当后再流调的数据分布当后再划出,在那时是那样的自己选择的发送边界1.2.2无引用后遇走释放流程Socket变量没了之后它一对一对应的文件描述符引用对象也没了等到内核Socket引用对象它一对多的文件描述符全部没了,Socket对象无引用进入释放流程遇到走其中一个传FIN进行四次挥手地释放传RST进行得知就中止地释放超时ACK进行异常地处理2.传输层TCP连接视角下的关闭TCP把终止分成2.1正常关闭机制调用close使用FIN报文在走挥手流程确保发送数据处理完地正常关闭解决的是还能通信时怎样有序告别的场景2.1.1FIN报文2.1.1.1收发传输层传输层在连接流发送,接收FIN 会关划发收通道的应用层应用层取完接收缓冲区的所有FIN前数据后得到EOF2.1.1.2分关每端的发送、接收流 是分开地结束的2.1.1.3可靠FIN是可靠传输单次里可以发多个,直到确认到达2.1.2先挥方最后一个ACK报文2.1.2.1报文的确达不定去确定报文能否到达本身就是无法确定能完成的事所有报文的确认要么收到ACK就能100%确认到它已送达要么收不到ACK就无法确认它有没有到达没有能100%确认到它没送达的2.1.2.2ACK的占比保障2.1.2.2.1方式2.1.2.2.1.1TIME_WAIT等待2MSLTIME_WAIT-2MSL选择保持连接先不关闭和保持的时间是2MSL是一种放弃了 去确认 ACK报文的,如果送达且能收到的停止折腾依据而是选择主动停下折腾、以很小的成本、同样占如果能到达的保障比例很大地排掉了偶然因素 地去保障2.1.2.2.1.2使用其它报文避免设计ACK递归地重传保障确认ACK到达其实也可以设计成不用ACK报文用别的报文 再来一次报文的有超时重传保障的确认到达就不会有把ACK报文设计成递归确认的问题能占如果能到达的保障比例很大且根据如果ACK能到达的且如果能确认到依据而停止折腾,否则继续往下折腾到超量才停止2.1.2.2.1.3做仅此ACK有的特殊标记避ACK递归地重传或者对先挥方的这个最后发的ACK报文做特殊标记处理只让它这时的ACK报文可以继续有ACK的确认回复机制然后也是能对它进行多次的重传确认也是能占如果能到达的保障比例很大并且也根据如果ACK能到达的能确认到的且如果能确认到依据而停止折腾,否则继续往下折腾到超量才停止2.1.2.2.2选择TCP协议里选择了使用TIME_WAIT等待2MSL的保障方式因为额外的设计实现成本小并且我方尽很大如果能到达的保障比例后我方没有去依据,确认到ACK送达后再停止折腾,而是主动停下折腾2.1.2.2.2.1原因因为即使如果它也去确认到达依据如果确认送达了,是停止折腾接着去单断如果没有确认到送达此时也已经尽很大保障比例了本身它如果到达,能确认到它到达本身是个概率事件,而且经过很大保障比例后都没确认到,大概率后面也是无法再确认到了,但没有收到依据就得继续折腾下去到超量、而且经过发送很大保障后,它ACK实际结果能送达的概率也很大了2.1.2.2.2.2效果因此此时选择主动停下折腾不以确认ACK到达而作为停止依据 而陷入更深的,仅为了我方要确定到,而实际可能已送达,实际上很多时候根本无法确定的 超量折腾此时就已经花费最好的保障成本效率地,取舍可能对方确实没有收到ACK地花费更大巨大代价修复地,去单断连接了2.2异常中止机制调用abort/reset使用RST报文不走挥手流程不保发送数据正常处理完地,这条连接现在立即作废地异常关闭解决的是连接需要立即作废的场景2.2.1RST报文2.2.1.1收发传输层传输层在连接流发送,接收RST 会立即中止单断连接的应用层往上给应用层报connection rest通知2.2.1.2并关每端的发送、接收流 是一起地结束的2.2.1.3不可靠RST是不可靠传输单次一个就发完,就要在下次里再发下个了2.2.1.4发送情况2.2.1.4.1连接不存在主机处于CLOSE或处在新建的连接里时 收到 不在该连接的别的连接里的报文时(很有可能就是,我方上一个已经单断开的旧连接里的,不知情的对方,仍能照着我方IP端口,发来的消息)根据此报文的源IP端口四元组信息 给他回应RST,我这里没有你这条连接对方收到RST后 便会清理掉这个旧的,是半打开的连接状态2.2.1.4.2遇到异常错误程序或者内核出现错误可以选择:不再保证剩余数据正常交付,直接中止单断我方连接 发送RST对方收到RST后 也跟着去单端断开连接了3.关机的限时关闭关机时3.1第一限时3.1.1限时内对关闭进程Socket选划边界限第一个时通知进程,让它自己选划发送边界地关闭3.1.2超时后超时后崩溃进程,被动直接划发送边界地关闭3.2第二个限时3.2.1限时内对关闭文件描述符-内核Socket对象-TCB释放连接 限第二个时进程关闭后,按它自己断开连接的流程遇到哪种情况就应对地进去处理3.2.2超时后超时后该单端主机断电 就会直接没了里面的 所有进程、一个内核里面的:文件描述符表,TCP协议栈及里面的TCB及维护的连接状态二、靠回应验连接我方发送消息收到ACK回应说明我方能正常发消息消息能过去对方能正常收消息对方能正常发消息消息能过来我方能正常收消息我方就能检验出没有异常反之收不到ACK回应即检验出有异常重传、keepalive、应用层心跳这些额外补充的发送消息重传是收不到回应时 再次进一步的试探检验心跳包是加速开启检验 试探回应地 检验连接可用性用于”我方根据对方回应推断连接能否用”的场景1.维护不确效连接的时间我方 收到对方ACK回应消息,的接收时间间隔就是我方 不确定连接是否有效无效地,维护连接 的时间1.1无效连接的浪费维护如果连接无效了(比如对方挂了/通信道路断了)就会在 最后一次的不确效连接维护时间段里上一次收到ACK回应往后从连接开始失效的某节点位置开始直到后面我方发送消息,试探回应超时收不到ACK,确定出连接失效的维护段结尾都会是我方浪费的无效连接维护1.1.1异常时机的浪费量影响异常出现位置是无法控制干预的异常可出现在 上次收到对方ACK回应的,不确效维护连接段头 到 最后发送消息后超时收不到ACK回应的,确无效连接段尾 的任意位置如果出现得靠前,那么浪费维护的时间段就大如果出现得靠后,那么浪费维护的时间段就小2.发送频率2.1正常间隔发送消息如果一方 是正常频率发送消息,就是正常间隔地试探回应检验异常那么它的不确效维护时间会正常浪费段等比例位置出现,但占的总段小,浪费的风险成本小异常检测的间隔及时性也正常2.2间隔很久发送消息2.2.1浪维风险如果一方间隔很久才发送消息那么从它上一次收到ACK 直到它过完超长时间间隔,下次发送消息试探ACK回应都是它不确效维护的超长时间如果有异常,在这么长段的任意位置出现,出现位置往后所占比例都还是随机不变的,但总段变长了,不确效维护段↑*不变比例,对应的浪费时间的风险成本是变大的异常检查的间隔及时性是特别晚的而如果出现异常对方正常频率发送消息的话很快就发现收不到回复早早检测到异常单断了很快检测出有异常、不确效维护的时间短、不确效总长短,等占例出现的浪费维护风险成本小而如果对方也一样间隔很久地发消息那么双方一起*22.2.2心跳措施2.2.2.1传输层keepalive对于会间隔很久发送消息的这端常常会手动配置上传输层的keepalive心跳,保障回应检测2.2.2.1.1过程当隔过keepalive idle2h时间没发送消息后就在传输层操作系统内核制作keepalive probe心跳包,使用一个特殊序号SEQSND.NXT-1从我端传输层往下封装发送,传到对端接收往上分用,在传输层就由操作系统处理完地,从前往后检查到当前连续前缀到的序号,就往下封装回复ACK回应了2.2.2.1.2作用就保障了发送消息最大keepalive idle间隔后至少有发消息限下了 发送消息的最大时间间隔、不确效维护的最大时间、异常检测的最大间隔时间2.2.2.1.3局限2.2.2.1.3.1内容少只能探测到 对方传输层-我方传输层的,TCP连接是健康的2.2.2.1.3.2受干扰传输层往下会受到自己传输层的整台机器CPU严重饱和内核卡顿往下底层的网卡队列拥塞、网络拥堵的可能变为长期异常失效的临时状况抖动因此要检测到超时多次 才少误判出非临时状况,而是长期失效的异常2.2.2.1.3.3间隔长保障至少有发的,维护探测间隔时间太长Keepalive2h2.2.2.2应用层心跳包2.2.2.2.1优势2.2.2.2.1.1自定义短间隔在我方应用层制作的PING/PONG/GET health心跳包能根据实际如果需要更快的异常检测频率,就自定义地缩短应用层心跳探测发送的间隔时间2.2.2.2.1.2检测内容更多能测完整我方应用层发-对方应用层收不仅传输层连接,还包括了应用层的服务健康进程还在应用线程还能处理请求HTTP服务正常数据库连接可能正常依赖服务可能正常更深层级地检测到整个Java服务逻辑的健康2.2.2.2.2劣势2.2.2.2.2.1受到的干扰更多应用层的ping,往下受到传输层到底层的临时状况抖动外,还额外有受到自己应用层的临时状况抖动:线程调度事件循环卡住CPU过载锁竞争因此要ping更多次超时失败才会更少误判出是长久性不会自己恢复的失效异常,标记unhealthy2.2.2.3心跳抖动jitter心跳包工程上 会加一点随机抖动jitter,打散所有机器的心跳时间,避开全部都同一时刻心跳产生的瞬间流量尖峰三、负载均衡器负载均衡器对后端服务器进行1.健康检查TCP连接检查HTTP GET /healthHTTPS检查gRPC health check自定义ping/pong被动观察请求错误率1.1经受干扰健康检查要经得住 随机临时的状况抖动偶尔一次网络抖动GC 5md调度延迟1.1.1工程平衡要容纳耐受在,持久无法自恢复的异常,判断之外工程上平衡检测越快↓虽故障恢复越快但误判概率越大、开销越大检测越慢↓虽误判少、开销小但故障发现慢2.选出服务用算法加权轮询Least ConnectionLeast Requests延迟优先一致性哈希资源负载EWMA延迟选出一个健康后端服务器处理请求3.木板资源瓶颈系统吞吐量会受最先耗尽的瓶颈资源min(CPU的时间占用率,网络速率,内存容量,线程阻塞,数据库性能,连接池容量)限制4.安全重传请求请求没有得到ACK回复就无法直接地确定出请求是否到达此时如果直接重传请求就有可能造成重复送达有实际业务的真实系统会受到幂等性request ID去重事务设计来进行安全的重传四、URG与PSH1.URGUrgent传输层正常TCP字节流里标出紧急信息段的始边界用Urgent Pointera指出紧急始边界正偏移量后的末边界应用层传输层TCP会通知接收的应用层,当前数据流中存在紧急信息应用可以用socket API对它采取特殊处理2.PSHPush传输层用于发送方提示接收TCP:这些已经到达接收缓冲区的数据,不要为了凑更多字节而长时间缓冲应尽快把它们交付给应用层