TCP三次握手思想的一次业务实践优化应用
前言
之前借鉴TCP三次握手思想，解决了老版开播中，可能存在的客户端与服务端数据不一致的问题，给大家分享一下。
TCP 三次握手
tcp三次握手过程
image
- 第一次握手(SYN=1, seq=x)，发送完毕后，客户端进入 SYN_SEND 状态
- 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1)， 发送完毕后，服务器端进入 SYN_RCVD 状态。
- 第三次握手(ACK=1，ACKnum=y+1)，发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态，TCP 握手，即可以开始数据传输。
TCP 为什么是三次握手
tcp建立连接为什么是三次握手呢？这是一道非常高频的面试题。
三次握手比喻
在这里，我们先来看个场景，假设小明打电话约小华周末早上打篮球。
小明：喂，小华吗？听到我说的话吗？我们周末早上打球怎样? （第一次握手）
小华：听到了，我是小华。那就周末不见不散，听到我的回复吗？ （第二次握手）
小明：好的，听到了，不见不散。 （第三次握手）
于是，小明小华如约而至，周末玩起兄弟篮球啦。
分析
如果只有一次握手，那么打球目的是不确定的，因为小华没回复，因为小明这边不知道小华是没听清楚还是没有空嘛，甚至可能听电话的都不是小华。
如果只有两次握手，小华不知道小明有没有听到他的话，打球目的还是不确定的。
如果三次握手，那么非常完美，小明小华都知道对方有空去打球的。
如果四次握手呢？其实没必要，因为三次握手已经达到目的了，四次握手浪费资源。
其实，TCP 的定位是全双工的、支持半关闭的、可靠的传输协议。但是，我们知道，网络信道是不可靠的，随时都有可能丢包、错包、乱序。为了可靠传输：
- 为了实现可靠数据传输，TCP 协议的通信双方，都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤
- 如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认
通过以上分析，我们知道三次握手就是为了确保通讯双方可以正常进行信息传输交流（），并且，知道对方确实处于ready正常状态,正所谓知己知彼。
业务场景
该业务场景就是在直播平台的开播过程。
业务场景描述
用户开播，需要以下几个步骤
- 调用服务端的开播接口，校验开播权限，记录开播信息
- 推流到第三方服务器
- 调第三方接口初始化聊天室
优化之前
优化之前，开播接口调用如图所示：
image
流程：
- 第一次握手。
- 客户端调用liveStart接口。
- 服务端校验开播权限，
- 服务端记录开播信息到数据库
- 服务端开播状态准备好。
- 第二次握手
- 服务端返回开播信息到客户端
- 客户端推流，初始化聊天室。
- 客户端开播状态准备好
- 开播成功。
存在问题：
如果客户端推流到第三方服务器或者初始化聊天室失败，那么服务端的数据跟客户端就不统一，开播状态不统一。
三次握手优化
image
流程：
- 第一次握手。
- 客户端调用liveStart接口。
- 服务端校验开播权限，
- 服务端记录开播信息到数据库
- 第二次握手
- 服务端返回开播信息到客户端
- 客户端推流，初始化聊天室。
- 客户端开播状态准备好。
- 第三次握手
- 客户端调用liveSuccess 接口。
- 服务端更新开播状态，准备好。
- 开播成功
通过三次握手，客户端与服务端的开播状态达成一致。
小结
本文借鉴TCP三次握手思想解决老版开播中，可能存在的客户端与服务端数据不一致的问题。其实想告诉大家，日常业务开发中，可以多一点思考，多点看书，真的会有意想不到的收获哦。
参考与感谢
个人公众号
image
- 如果你是个爱学习的好孩子，可以关注我公众号，一起学习讨论。
- 如果你觉得本文有哪些不正确的地方，可以评论，也可以关注我公众号，私聊我，大家一起学习进步哈
