上次提到tcp数据流无边界特点
还有一个特点那就是
TCP有长连接和短连接之分
目录
流程:
被动关闭一方接受完毕数据 然后发送 TCP flag Fin请求
主动关闭一方 tcp状态 进入TIME-WAIT
主动关闭一方 在此期间内 该端口不能被任何程序重用 ,不能建立任何连接。这个期间称为平静时间(quiet time)
flow
Q1 问题来了 TIME-WAIT 影响了端口马上被重用,存在意义是什么?
根据tcp状态含义解释
TIME-WAIT:等待足够的时 (等待),确保远程TCP收到了终止请求的确认
远程TCP收ack确认(这个条件) 直接 CLOSE-WAIT状态进入CLOSED状态
目的保证最后一步ack安全到达
但是我还是不明白存在意义 有更加合理解释吗?
不成立
Q2 问题来了 如何减少TIME_WAIT时间
通过修改socket选项SO_LINGER 异常关闭连接
打破四次握手, 避免j进入TIME_WAIT状态
客户端崩溃 异常关闭 server收不到ACK
客户端曾经崩溃,但已经重启 响应是一个复位reset
客户端主机活跃运行,但从服务器不可到达 T C P连接的双方都没有向对方发送数据
服务器主机突然断电 T C P连接的双方都没有向对方发送数据
服务器主机网线被拔出 T C P连接的双方都没有向对方发送数据
服务器主机正常重启当 系统被操作员关闭时,所有的应用程序进程(也就是客户端进程)都将被终止,客户端TCP会在连接上发送一个FIN。
缺点:
有时候检查不到 断电、直接拔掉网线、防火墙这些断线 (呜呜呜)
keepalive并不是TCP规范的一部分。在Host Requirements RFC罗列有不使用它的三个理由:
但自己的keepalive有这样的一个bug:
正常情况下,连接的另一端主动调用colse关闭连接,tcp会通知,我们知道了该连接已经关闭。
但是如果tcp连接的另一端突然掉线,或者重启断电,这个时候我们并不知道网络已经关闭。
而此时,如果有发送数据失败,tcp会自动进行重传。重传包的优先级高于keepalive,那就意
味着,我们的keepalive总是不能发送出去。 而此时,我们也并不知道该连接已经出错而中断。
在较长时间的重传失败之后,我们才会知道。即我们在重传超时后才知道连接失败.
不直接通知异常
c++:
在程序中表现为,当tcp检测到对端socket不再可用时(不能发出探测包,或探测包没有收到ACK的
* 响应包),select会返回socket可读,并且在recv时返回-1,同时置上errno为ETIMEDOUT.
循环处理+sleep方式() 推荐方式
心跳包一般来说都是在逻辑层发送空的echo包来实现的。
下一个定时器,在一定时间间隔下发送一个空包给客户端,然后客户端反馈一个同样的空包回来,服务器如果在一定时间内收不到客户端发送过来的反馈包,那就只有认定说掉线
golang 定时器检测
缺点:
对网络闪断情况处理不好
大纲
心跳包实现考虑问题
1 是否能及时发现异常
2 明确通知业务层出现异常
TCP的交互数据流
Nagle算法
TCP的超时与重传
拥塞避免算法
TCP的成块数据流
滑动窗口
参考:
用TCP/IP详解,卷1:协议
rfc793(tcp协议)
联系客服