三次握手与四次挥手
越是糟糕的代码, 越需要注释. 三次四次这个词, 也许是世界上最出名的注释. 过渡优化的界线, 到底在哪里呢…
为什么要握手与挥手
握手与挥手的深层原因, 是通信信道不可靠, 而人们又想在肯定消息送达后才开始工作.
我给你发了同步号1, 要等收到你的确认号2, 我才敢肯定消息送达了.
同样的, 你给我发了 同步号90, 要等收到我的确认号91, 你才能肯定我收到消息了.
握手少了一次的原因
这么算下来, 握手与挥手的次数都应该是四次才对.
然而, 握手的过程中, 你把确认号2和同步号90放一起发了. 节省了一次动手次数.
挥手的过程中, 如果你也把确认号2和同步号90放一起发, 那就表示你要立即跟着我一起开始断开连接的工作了. 但是你可能还想继续发送一些数据, 所以你只能把确认号2和同步号90分成两次挥.
这就是握手少了一次的原因, 因为你我之间没有其他事情, 你肯定可以立即跟着我一起开始建立连接的工作.
推论
把发出第一次握手的叫客户端, 另一个服务端.
第三次握手报文里, 客户端可以携带数据吗?
当然可以, 客户端已经发出 同步号1 并收到 确认号2了. 为什么不能开始发送数据呢.
服务端是在哪个阶段准备好资源的呢?
第二次握手的时候. 要不然第三次握手同时携带数据来了, 没准备好资源要怎么接收数据呢. 如果服务端迟迟未收到第三次握手, 超时了再回收资源嘛.
除了握手, 也关注下流量控制吧.
有一次做面试官的经历, 看到对方简历上写了 HTTP 协议. 于是问到 “长连接相比于短连接的好处”.
对方的回答止步于建立连接的握手通信耗时…直接打算了我的思路…慢启动都没答上来, 找不到机会问后面的滑动窗口啊…多说一个操作系统分配和回收资源的损耗, 也还能勉强往操作系统上带…