Day25【Web】TCP 连线与断线：三次握手、四次挥手

TCP 是一种要求资料正确性的传输方式，
这表示它需要一些特殊机制，
来确保传输的数据不会出错。

其中就包含了建立连结
与终止连结的缜密运行机制，
也就是三次握手与四次挥手。

建立连线的三次通讯

顺序	客户状态	行为	服务器状态
1	发起请求	传送 Greeting →	聆听／待命中
2	等候确认		收到讯息
3	等候确认	← 传送回应表示收到	回覆请求
4	收到回覆		等待确认
5	确认收到	传送回应表示收到 →	等候确认
5	确认收到		确认收到
5	通讯建立成功		通讯建立成功

以上三次讯息传递後，
就能让 Client 端和 Server 端，
确认彼此都能收到对方的讯息。

三次握手的用途
想像成两人在讲电话的话就类似於：

A：「喂？有听到吗？」
B：「有听到喔，你那边听得到我声音吗？」
A：「可以喔。」

对建立可靠的通讯来说，
三次握手是一种非常具体可行的方法。

终止连线的四次挥手

同样用电话模拟的话如下：

A：「我没什麽要说的了，要挂罗？」
B：「喔，你要结束通话啦？」
B：「嗯我要跟你说的都说完了，就挂吧。」
A：「那挂罗，BYE。」

其中 Server 方的第二和第三次挥手，
之所以分为两次进行，
是因为此时 Client 方的连结
处於「半关闭」的状态，
也就是可以收听但无法传输资料。

所以 Server 会先回覆已收到终止连线的讯息，
表示断开连线的请求已经受理，
并向上层确认没有要发给 Client 的资料後，
才对 Client 回覆断开连线，
这就是第二次和第三次挥手的功能。

为何第四次挥手後需要等待，
大致有以下原因：

是为了避免由於网路延迟等关系，
在关闭连接後，又再度收到前次通话的封包，
此时如果客户端已经开始进行新的连线，
在新数据传输的情况下收到旧数据，
会出现资料错乱的问题。
所以会等候一段时间，
让可能没收到的封包都自然死亡，
如此才能确保新建立的连结没有问题。

如果 Client 端发送的第四次挥手没有被收到，
则 Server 端会继续保持连接状态，
此时如果 Client 未等候直接发起新连接，
仍处於连线状态正在等候回覆的 Server 端，
可能会回覆中止连接通知，
并直接关闭本次连接，让新的连接失败。

参考资料