目录
一、TCP三次握手(建立连接)
二、TCP三次握手细节
三、TCP(四次挥手)断开连接
四、TCP非常重要的协议
一、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保证可靠性最重要的机制是——确认应答(网络的环境是多变的,这种畅通,不代表后面会一直畅通,确认应答是保证每次传输数据都是可靠的)。文章来源:https://www.toymoban.com/news/detail-708860.html
那么为什么三次握手,四次挥手这么常考呢🌚🌚🌚——名字好听文章来源地址https://www.toymoban.com/news/detail-708860.html
到了这里,关于TCP的三次握手,四次挥手,面试必会的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!