目录
上集回顾
注释：host：主机 process ：进程
四次挥手阶段
提问：主动挥手方一定是主动连接方?
不是 ! (主动提分手的不一定是当时主动追求的人)
四次挥手图
注释：状态发生在一个面上，而不是一个点上。是一段时间区间。发生状态转变的点是瞬时的
四次挥手中间不能合并了
原因之一
原因之二
四次挥手的详细过程
—些变形的挥手情况
下面两种算特殊情况
三种不同情况的状态图
先单单看左边这主挥杆子的 接 和 收 情况去对照流程图
主挥：先是发生FIN，然后又收到ACK，收到 FIN，最后有发生ACK，最终到达CLOSED
现在单单看接收放那根杆子
先是收到了FIN，触发了被动关闭。又发了ACK，FIN，最后收到了ACK到达CLOSED
三次挥手的状态图
注释：三次挥手中，CLOSE_WAIT 是瞬间关闭的没有停留，相当于直接到了LAST_ACK
看上面的状态图，接收FIN和发FIN都在一个点上执行的
同时挥手的图
同时就是在服务器没有收到客户端的FIN前自己就也已经发送了FIN，两者虽然时间上有一点点差别，但大致是同一时间。因为是在没有收到客户端的FIN之前服务端就发送了，接下来都是如此
CLOSE WAIT状态
甲发出分手请求，乙被动变成 CLOSE WAIT状态
提问：现象：服务器上出现大量CLOSE WAIT状态的TCP连接，请问这种现象是否合理?如果合理，说明理由?如果不合理，请说明原因或者修复建议?
注释：一个关闭另一个没有关闭就会出现这样的情况
TIME_WAIT状态
既然挥手的工作已经完成了，为什么要有个TIME_WAIT状态而不是直接进入CLOSED状态?
原因：确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接。
为什么要等待2MSL ？
除了上面下半段的原因外
防止已失效的连接请求报文段出现在之后的连接中。
举例：相当于你打算注销邮箱，你在注销的时候别人在你之前发了邮箱给你，但还没到，传输中。如果别人又在那封邮件发送到达之前使用了你的旧邮箱。这时别人收到的邮件是发生给他的吗？不确定。 所以需要一段等待时间。
MSL：是网络上存活的最长时间，如果这段时间都没有消息的话，说明中途没有在传输中的消息了，就算有也不要了。
注释：或者这么理解，这段时间就是给你处理剩下来的一些“交接仪式”，彻底是跟它说拜拜。
提问：服务器上发现了大量的TIME_WAIT状态的TCP连接，是否合理?如果合理说明理由?不合理，请给出修复建议?
注释：能让对方背负就让对方背，否则就要自己背负，但不能死等，成本会更高
主动连接方既可以是 发送者 也可以是 接收者
主动连接方既可以是 主动关闭放 也可以是 被动关闭方
TCP中的异常情况
进程没有调用close，但操作系统会，因为操作系统都知道有哪些进程。
类似于学校里的机房
OS释放调用的还是close方法，只不过原来是进程干的事情变成操作系统来调用了。
了解:通过命令行命令可以查看主机上的TCP连接情况
去查PID也是可以的
流量控制
流量控制(广义):TCP的发送端会根据对方接收能力和网络承载能力，动态地调节自己的发送流量。——提高到达率
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
