一、TCP三次握手（建立连接）
🤝🤝握手，单纯就是发一个打招呼的数据，不携带业务信息
那么为什么叫三次握手呢，因为B的中间两次可以合并成一次。
为什么我们要合并呢？💫💫
因为我们的封装（加报头）和分用，两个分一次比分两次成本低，效率提高。
合并之后，节省封装和分用的过程，降低了成本，提高了效率，原则上是能合并就合并。
一般来说我们用这六位，其中两位来表示三次握手，分别是SYN和ACK
我们上一篇文章说了ACK是应答报文,SYN就相当于那种传输的数据
三次握手，第一次的SYN一定是客户端发起的（客户端是主动的一方），socket=new SOcket(serverIP,serverPort)->这个代码是开始进行三次握手，这个new操作完成了，三次握手也完成了，三次握手，这是内核完成的工作，应用程序这里无法干预。—>
同时服务器针对三次握手配合是不需要涉及到任何应用层代码的，只要你这个进程绑定了对应了TCP端口，就可以在内核中自动的配合完成，三次握手，无论你服务器代码咋写的->三次握手之后，客户端和服务器形成连接，此时accept就能够返回，从连接队列中取出队列元素，进一步获取到其中socket对象来和对端进行通信。
Socket clientSocket=serverSocket.accept()//并不参与三次握手的过程。
二、TCP三次握手细节
三次握手的部分细节：确认序号：表示该序号之前，数据已经收到。💖 💖
狗哥：第一次喵喵喵🐱，表示想问问小薛，我的麦克风是否正常，也是在验证小薛的耳机是否正常，小薛收到喵喵喵之后，她就知道，我的麦克风和她的耳机是正常的。
小薛：第二次回复喵喵🐱的时候，验证她的麦克风，我的耳机是否有毛病，我收到喵喵了，我就知道他的麦克风，和我的耳机没有问题，转念一想，我收到喵喵，就说明：我的麦克风和他的耳机是正常的
狗哥：喵🐱，到这一步，我知道双方都没有问题，但是小薛还是不知道她的麦克风，我的耳机是否有问题，所以我回复一个喵，让她放心。
TCP通信的过程中，有很多信息需要协商，比如双方的序号从几开始···的。这么做主要保证，再次连接，消息的序号能有较大的差异，从而好去判定某人消息是否属于这个连接的。
网上传输的信息，可能后发先至，极端情况下，某个消息迟到了，迟到很久很久，当消息到达对端的时候，服务器和客户端已经断开了上一个的连接，这是重新建立的连接，这时，就可以通过序号，明显识别出上一个连接的消息，就可以丢弃了。
综上，三次握手，初心是两方面：
1.验证通信路径是否畅通，双方的发送能力/接收能力是否正常。
2.协商必要的参数，使客户端和服务器使用相同的参数进行信息传输
三、TCP（四次挥手）断开连接
连接：是联通双方各方在各自内存中保持对立端端相关信息～～，如果不连接了，就得及时释放上述储存空间～。💚💚
四次挥手与三次握手十分相似。
但是区别就是：三次握手一定要客户端主动发起，但是四次挥手：小部分可以由服务器来进行挥手。
四次挥手在我们断开连接的时候使用。
FIN这一位为1，就是结束报文段。
FIN触发应用程序控制的，调用socket.close的时候，结束，就会触发FIN，相比之下，ACK是内核控制的，收到FIN，就立马返回ACK。
我们之前写的close执行的速度很快，可以ACK和FIN合并在一块，但是假如说他的close很慢，此时就会和上一个ACK分开（大部分情况）
当然也有人会想问，假如我始终不进行close会怎么样？客户端的连接就始终不关闭嘛？
此时TCP状态，处于CLOSE_WAIT状态不进行转化，此时仍是Close_WAIT,站服务器的角度，虽然这里的连接没有关闭，但是这个连接其实已经不能正常使用了
针对当前socket进行读操作，如果数据还没有读取完毕（缓冲区还有数据）能够正常读到，，针对当前的socket进行写操作就会直接触发异常（因为这个连接已经废了，能关闭就已经是最优解了），
更极端的情况，代码写出bug，close忘记写了，此时站在客户端的角度，这边迟迟收不到自己的FIN，也会进行等待～，如果一直等不到，此时就会单方面放弃连接（客户端会忘记自己保存的对端信息，就是删除了，释放了）
目标：释放资源，双方都释放，固然是最好的，如果条件不允许，也不影响单方面的释放。
如果通信过程出现丢包会怎么样，又会怎么处理呢？
这里涉及超时重传，三次握手和四次挥手也都带有重传机制，尽可能重传，如果重传失败，连续多次，此时就会释放连接（单方面断开连接）
我们站在A的角度，当收到最后B给的FIN之后，并且发出去ACK此时A视为四次挥手已经结束了，此时A就可以直接释放连接了吗？不不不——>最后一个ACK还可能会丢包
最后一个ACK丢失，B会重新传个FIN，此时如果A已经把连接释放了，此时A就不能针对这个FIN返回最后一个ACK了，所以需要A在发送最后一个ACK之后，让连接再去等一会（主看等待的过程是否会收到对方重传的FIN，如果一段时间之后，对方还未传FIN，则认为ACK已经被对方收到，此时A才能正常释放连接。
那么A在这边需要多久才可以释放连接呢？
等待时间就是网络上任意两点之间传输数据的最大事件*2，这一个时间也叫MSL，超时重传时间到达MSL上限，则说明发生丢包现象（A发送一个数据报，A会等待B返回一个ACK，这时候就看MSL，不要看上面的图哈），当然你也要根据具体情况来分析又可能会发生线路拥堵的情况。所以说具体情况具体分析（这也是人牛逼的特性）
A在等MSL过程中，B反复重新传输FIN多次，这些FIN都丢了，（理论上存在），如果真出现这个情况，当前网络一定出现了严重的故障了->这时候是不具备可靠传输的前提条件的，A单方面释放资源也无所谓
四、TCP非常重要的协议
一、确认应答：保证可靠性的最核心机制，发送给接收方发过去的数据，接收方会返回一个ACK应答报文。🙆🙆
TCP保证可靠性最重要的机制是——确认应答（网络的环境是多变的，这种畅通，不代表后面会一直畅通，确认应答是保证每次传输数据都是可靠的）。
那么为什么三次握手，四次挥手这么常考呢🌚🌚🌚——名字好听
