上次提到tcp数据流无边界特点
还有一个特点那就是
TCP有长连接和短连接之分

目录结构：

socke正常关闭

流程：

被动关闭一方接受完毕数据然后发送 TCP flag Fin请求
主动关闭一方 tcp状态进入TIME-WAIT
主动关闭一方在此期间内该端口不能被任何程序重用，不能建立任何连接。这个期间称为平静时间(quiet time)

flow

分析处于T I M E _ WA I T状态的主机收到使其进入此状态的重复的F I N时所发生的情况。--重新计时

Q1 问题来了 TIME-WAIT 影响了端口马上被重用,存在意义是什么？

根据tcp状态含义解释
TIME-WAIT：等待足够的时（等待），确保远程TCP收到了终止请求的确认
远程TCP收ack确认（这个条件）直接 CLOSE-WAIT状态进入CLOSED状态
目的保证最后一步ack安全到达

但是我还是不明白存在意义有更加合理解释吗？

不成立

sokcet 异常关闭

分析处于T I M E _ WA I T状态的主机收到一个 R S T时所发生的情况。--断开连接

Q2 问题来了如何减少TIME_WAIT时间

通过修改socket选项SO_LINGER 异常关闭连接
打破四次握手，避免j进入TIME_WAIT状态

异常情况

客户端崩溃异常关闭 server收不到ACK
客户端曾经崩溃，但已经重启响应是一个复位reset
客户端主机活跃运行，但从服务器不可到达 T C P连接的双方都没有向对方发送数据
服务器主机突然断电 T C P连接的双方都没有向对方发送数据
服务器主机网线被拔出 T C P连接的双方都没有向对方发送数据
服务器主机正常重启当系统被操作员关闭时，所有的应用程序进程（也就是客户端进程）都将被终止，客户端TCP会在连接上发送一个FIN。

心跳检查几种方案

TCP KeepAlive通过定时发送探测

缺点：

有时候检查不到断电、直接拔掉网线、防火墙这些断线（呜呜呜）

keepalive并不是TCP规范的一部分。在Host Requirements RFC罗列有不使用它的三个理由：
但自己的keepalive有这样的一个bug：
正常情况下，连接的另一端主动调用colse关闭连接，tcp会通知，我们知道了该连接已经关闭。
但是如果tcp连接的另一端突然掉线，或者重启断电，这个时候我们并不知道网络已经关闭。
而此时，如果有发送数据失败，tcp会自动进行重传。重传包的优先级高于keepalive，那就意
味着，我们的keepalive总是不能发送出去。而此时，我们也并不知道该连接已经出错而中断。
在较长时间的重传失败之后，我们才会知道。即我们在重传超时后才知道连接失败.

不直接通知异常

c++：
在程序中表现为,当tcp检测到对端socket不再可用时(不能发出探测包,或探测包没有收到ACK的
* 响应包),select会返回socket可读,并且在recv时返回-1,同时置上errno为ETIMEDOUT.

自己实现

循环处理+sleep方式() 推荐方式

2 启动定时器来检查

心跳包一般来说都是在逻辑层发送空的echo包来实现的。
下一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线

golang 定时器检测

缺点：

对网络闪断情况处理不好

本章节内容：

大纲
心跳包实现考虑问题
1 是否能及时发现异常
2 明确通知业务层出现异常

下章预告：

TCP的交互数据流
Nagle算法
TCP的超时与重传
拥塞避免算法
TCP的成块数据流
滑动窗口

计划：

参考:

用TCP/IP详解，卷1：协议
rfc793（tcp协议）

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。