TCP三次握手和四次挥手

#前言
相信大家在面试的时候时不时会遇到考官会问这种问题，在大学的时候我们应该都学过这种基础知识，当时应该是背的滚瓜烂熟的，只不过到了社会上以后，大家可能跟这个接触少了，慢慢就淡忘了。这个并不是什么特别牛逼的问题，知道也不是什么了不起的事情，就像java每个基础类型占多少字节，bit和byte的转化，等等。你不知道吧，对于我们安卓开发者来说问题不是很大，项目，工程也能搞起来，你知道了吧，好像也就那样，会者不难也不是了不起的事情。很久之前我之前有家公司的面试官就问了这个问题，我心里想mmp，面试造火箭呢这？！直到后来项目越做越大，整个安卓项目过于庞大，有些地方出现了卡顿，但是却无从下手，有人说，问百度啊。要是真遇到了某个问题，真的是很难形容，有报错还好，但是你说卡顿，优化这种事情，百度上一搜茫茫多，找出来的文章也是人写的，也可能会误导你。这个时候，如果基本功好，就很容易从现象看本质，针对性地解决问题。
说的有点多，下面割一下就进入正题。

---

#几个英文单词缩写的含义
SYN：synchronous 意思是建立联机
SYN_SEND：发送了
SYN_RCVD：接收了
ESTABLISHED：建立了
ACK：确认
seq：序列号
大致理解了这几个英文单词的缩写含义后，我们再去看看三次握手和四次挥手会事半功倍。
#TCP的三次握手

• 客户端发起连接，将SYN置为1，同时给服务端发送一个序列号，seq = J，这时候客户端的状态是已经发送SYN_SEND；
• 服务端接收到了信号后，重置了ACK = 1，SYN = 1，同时会将客户端的序列号加一然后赋值给ack，再带入自己的序列号，seq = K并返回给客户端，这时候服务端会将自己的状态置为已收到SYN_RCVD；
• 客户端在收到了服务端的报文后，会首先看下服务端是不是收到了自己发的东西，就是判断ack的值是不是已经被+1了，然后会把服务端发送的序列号+1并赋值给ack，同时将自己的状态置为ESTABLISHED-已经建立连接；
• 服务端这时候收到了来自客户端的报文，服务端需要确认客户端收到了自己发送的消息，所以会看报文中的ack是否就是自己的序列号（seq）+1，如果一切满足条件，那就将自己的状态置为ESTABLISHED-已经建立连接；
  至此，客户端和服务端经历了三次握手后，连接就已经建立成功了，双方可以互相进行通讯了。
  #TCP的四次挥手
  
  说明一下，三次握手，一般来说是客户端发起，但是四次挥手有客户端和服务端都有可能发起，所以在此，我们的两个设备我写成了端1和端2，假定现在是由端1发起挥手。
• 端1发起挥手，告诉端2，我想跟你断开连接，然后端1就不再往端2发送数据了，端1传给端2自己的序列号seq = J，同时将自己的状态置为FIN_WAIT_1；
• 端2收到了端1的报文，就告诉端1，好的，我收到了你断开的请求了，于是给端1发送了确认的报文（就是将端1的序列号+1）然后返给端1，将自己的状态置为关闭等待（CLOSE_WAIT）；
• 这个时候只是给端1发送了个确认消息，还没有发送断开的消息，所以下一步端2会给端1发送断开的报文，同时传入自己的序列号，将自己的状态置为了LAST_ACK，表示自己准备好了接收最后一个确认报文；
• 端1会首先接收到端2的确认报文，然后会将自己的状态置为FIN_WAIT_2，然后再接收到了端2的断开报文，会返回给端2自己已经收到了你断开的报文（将端2的序列号+1并赋值给ack返回），同时会将自己的状态置为TIME_WAIT，在等待了2MSL的时间后，会将自己关闭。
• 端2收到了端1的报文后，会将自己关闭。
  至此整个的四次挥手就完成了。在此说明一下为什么端1需要等待2MSL，原因有2个：

1. 在端1发送的最后一次确认报文是有可能丢失的，如果丢失需要让端2重传一个FIN报文过来。
2. 是因为报文的存活时间是1MSL，ACK从端1发送到端2最多只需要1MSL，当丢失了，端2发给端1的重传报文最多也只有1MSL，所以如果端2重发了，最多只要经过2MSL。
   也只有1MSL，所以如果端2重发了，最多只要经过2MSL。
   至此三次握手和四次挥手就讲完了，如果有不对的地方欢迎评论区里留言。