这是我参与更文挑战的第14天，活动详情查看： 更文挑战
TCP协议的基本操作
- 一个Host主动对另一个Host发起连接，称为SYN(Synchronization)，请求同步
- 其中一个Host主动断开连接，称为FIN(Finish)，请求完成；
- 如果一个Host给另一个Host发送数据，称为Push(Push)，数据推送
在以上的三种情况，当接收方接受到数据后，都要给发送方一个ACK(Acknowledgement)响应。请求/响应式可靠性的前提。如果一个请求没有响应，那发送方就会认为接收方没收到而重发这个请求。
建立连接（三次握手）
三次握手步骤
为了保证连接的可靠性，TCP协议中每一条发出的数据必须有响应，也就是ACK。
-
客户端给服务器发起连接，客户端给服务器发送了SYN包(SYN=i)，进入SYN_SEND状态等待确认。
-
服务器接收到SYN包，确认客户端的SYN，此时ACK=i+1。服务器自己也给客户端发一个SYN包(syn=j)，还有确认后的ACK(i+1)包，这时候服务端进入SYN_RECV状态。
-
客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ACK=j+1)，这个包发送完毕后，服务器进入ESTABLISHED状态，完成三次握手。
解析
1.步骤1是第一次握手，第一次握手的时候，客户端给服务器发了一个包，等待服务器的确认。
2.步骤2是第二次握手，服务器收到了客户端发来的包，然后确定要发的ACK = 客户端发来的SYN+1(i+1)。然后服务器给客户端发了SYN+ACK包，SYN=j ，ACK=i+1。这个代表服务器向客户端方向大喊：“我收到你的信息了，你发能力没问题，你给我发的SYN包，我用ACK在SYN的值上+1给你回复了，我也给你发个SYN包为了确定你的收能力，你要能听到给我回复一个ACK也在我给你发的SYN基础上+1，咱就建立连接”。
3.步骤3是第三次握手。客户端收到了服务器的SYN包和ACK包，然后给服务器发送ACK=服务器发来的SYN的值+1，这步的意思代表客户端给服务器说：”OK，我知道你的收发能力都没问题了，给你ACK，是在你给我发的SYN基础上+1的，这代表我收能力也没问题，咱连接吧“
脑补的场景
A：”B，我喜欢你“
B：”我知道你喜欢我了，其实我也喜欢你“
A：”收到，我们在一起吧“
简单说，TCP三次握手连接就是为了确定互相确定客户端和服务器的收发能力没有问题。
断开连接过程（四次挥手）
- 客户端要求断开连接，就发送一个断开连接的请求，也就是FIN。
- 服务器接收到请求，给客户端发送一个ACK，作为对FIN的回复。
- 服务器经过一个等待，确定可以关闭连接后，再发一条FIN给客户端。
- 客户端收到服务器的FIN，客户端处理完自己的事情之后(比如给服务器的信息还没回复ACK)，在这些处理完之后，再给服务器发送一个ACK。
如果按照上面的理解，是否可以2和3步骤合并，把ACK和自己的FIN同时传给客户端呢(参考三次握手的SYN+ACK包)？答案是不行，因为服务端可能还有自己的资源需要释放，或是发送给客户端的消息还没有得到回应，因此和三次握手的主要差别就是ACK+SYN包拆成了先ACK后SYN，然后只是SYN在断开连接的阶段啊是FIN而已。
脑补的场景
A：”分手吧，B“
B：“我知道你想分手了，能不能让我想想”
----这会估计B在回顾自己这段感情 对应服务器正在处理之前的消息
B：”好吧，分吧，A“
----这会A知道B要分了，也开始回顾了= = 对应客户端处理之前的消息
A：”B，既然你知道了也同意了，分吧“
TCP 为什么是 3 次握手，4 次挥手？
因为TCP是一个双工协议，建立连接的时候，连接双方都需要向对方发送SYN(同步请求)和ACK(响应)，因为握手阶段双方之间还没啥任务，所以一方向另一方发起SYN的时候，另一方可以直接发ACK-SYN打包成一条消息回复，因此仅需要三次握手-也就是三次数据传输。
挥手阶段，双方可能都有未完成的任务，所以需要等到一方任务结束后才能接着回复。
