Http建立链接与断开链接
TCP建立连接握手次数为什么是三次?TCP断开链接的通信次数为什么是四次?
建立链接三次握手
TCP三次握手机制是建立TCP连接的重要过程,它包括以下三个主要步骤:
-
第一次握手:
- 客户端向服务器发送一个SYN包(Synchronize Sequence Numbers,同步序列编号),并进入SYN_SENT状态,等待服务器的确认。这个SYN包中包含了客户端的初始序列号。
-
第二次握手:
- 服务器收到SYN包后,必须确认客户端的SYN(即发送一个ACK包,其中ACK的值为客户端序列号加1),同时服务器也发送一个SYN包,即SYN+ACK包,此时服务器进入SYN_RECV状态。这个SYN+ACK包中既包含了服务器对客户端SYN的确认,也包含了服务器的初始序列号。
-
第三次握手:
- 客户端收到服务器的SYN+ACK包后,会向服务器发送一个ACK包,以确认服务器的SYN(ACK的值为服务器序列号加1)。此包发送完毕后,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。 通过这三次握手过程,客户端和服务器之间建立了一个可靠的TCP连接,双方均确认了对方的初始序列号,并准备开始进行数据传输。
值得注意的是,如果在握手过程中出现任何问题,如网络拥堵、超时等,都可能导致握手失败,从而无法建立TCP连接。此外,三次握手也是为了防止已失效的连接请求报文突然又传送到了服务器,从而产生错误。
总的来说,TCP三次握手机制是网络通信中建立可靠连接的重要步骤,它确保了数据的准确传输和同步。
握手为什么是三次?
TCP建立连接时采用三次握手的原因主要可以归纳为以下几点:
-
确认双方都具有接受和发送数据的能力:
- 第一次握手:客户端发送SYN包,进入SYN_SENT状态,等待服务器的确认,这表示客户端有发送数据的能力。
- 第二次握手:服务器收到SYN包并发送SYN+ACK包,进入SYN_RECV状态,这表示服务器有接收和发送数据的能力。
- 第三次握手:客户端收到SYN+ACK包后发送ACK包,之后双方进入ESTABLISHED状态,这表示客户端有接收数据的能力。
-
防止重复历史连接的初始化:
- 网络堵塞可能导致旧的SYN报文延迟到达。如果是两次握手,那么服务器在收到旧的SYN报文后可能会误以为是新的连接请求并建立连接,造成资源浪费。而三次握手可以避免这种情况,因为客户端在第三次握手中会检查确认号(即ACK的值),如果与服务器的序列号不匹配,则不会建立连接。
-
同步双方初始序列号:
- 序列号在TCP通信中起着至关重要的作用,它保证了数据的发送是有序的,同时记录已发送数据的位置,便于对比请求响应ACK确定下一次发送数据的位置。三次握手过程中,通过SYN和ACK包的交换,双方都对请求作出响应,表示数据接受,并初始化发送数据的序列号,保证双方都进入数据可发送和接受的状态。
-
避免资源的浪费:
- 如果采用两次握手,在网络堵塞情况下,客户端可能会发送多个SYN报文,服务器在收到请求后就会建立多个冗余的无效链接,造成不必要的资源浪费。而三次握手可以确保在建立有效连接之前进行充分的确认和同步。
综上所述,TCP建立连接的握手次数为三次是为了确保连接的可靠性、防止历史连接的重复初始化、同步双方的初始序列号以及避免资源浪费。这三次握手在TCP连接中起到了至关重要的作用,保证了数据传输的准确性和有序性。
TCP断开链接四次挥手及原因
TCP断开链接的四次挥手过程是一个相对复杂但必要的步骤,以确保数据传输的完整性和网络资源的正确释放。
-
第一次挥手:
- 操作:客户端(主动关闭方)发送一个TCP报文,其中FIN标志位被置为1,表示希望断开连接。随后,客户端进入FIN_WAIT_1状态。
- 原因:客户端完成了数据传输或决定结束连接。
- 结果:服务端了解到客户端希望断开连接。
-
第二次挥手:
- 操作:服务端(被动关闭方)在收到FIN报文后,发送一个ACK应答报文给客户端,确认已收到断开连接的请求。服务端此时进入CLOSE_WAIT状态。
- 原因:服务端需要确认已接收到客户端的断开请求,并准备自己的断开操作。
- 结果:客户端收到ACK后,进入FIN_WAIT_2状态,等待服务端的FIN报文。
-
第三次挥手:
- 操作:服务端在处理完所有待发送的数据后,发送一个FIN报文给客户端,表示服务端也准备断开连接。随后,服务端进入LAST_ACK状态。
- 原因:服务端已完成所有数据的发送,并准备好断开连接。
- 结果:客户端了解到服务端也准备断开连接。
-
第四次挥手:
- 操作:客户端在收到服务端的FIN报文后,发送一个ACK应答报文,确认已收到服务端的断开请求。之后,客户端进入TIME_WAIT状态。
- 原因:客户端需要确认服务端的断开请求,并确保所有数据传输完毕。
- 结果:服务端收到ACK后进入CLOSED状态,连接断开。客户端在等待一段时间后(通常是2MSL,即报文最大生存时间的两倍),确保服务端已接收到ACK报文后,也进入CLOSED状态,完成整个断开过程。
这个过程确保了数据的完整传输和网络资源的正确释放。值得注意的是,在四次挥手过程中,任何一方都有可能成为主动关闭方或被动关闭方,这取决于具体的应用场景和网络状况。同时,TIME_WAIT状态的存在是为了确保所有的数据包都能在网络中正确传输并被接收方确认,从而避免数据丢失或重复传输的问题。
TIME_WAIT 🔴
1. 产生时机
主动断开连接的一方,第四次挥手发送 ACK 之后,进入 TIME_WAIT 状态,默认等待2MSL。
2MSL 指的是 两倍的 MSL(Maximum Segment Lifetime,报文最大生存时间)
2. 作用
- 保证最后一次ACK报文一定被对方收到,防止对方重发FIN报文。
- 等待滞留延迟报文自然失效,避免旧连接残留报文干扰新连接。
3. 缺点
高并发短连接场景下,TIME_WAIT 过多会占用端口、占用系统资源,需要内核参数调优。
HTTP 版本区别 🔴
HTTP1.1(目前业务最常用)
优点
-
支持长连接,一次TCP连接多次传输数据。
-
支持断点续传、管道机制。
缺点
-
队头阻塞:一条连接里面前面请求卡住,后面全部卡住。
-
头部冗余,每次请求重复携带大量请求头。
-
不支持二进制,只能文本传输。
2、HTTP2.0
优化点
-
二进制传输:二进制帧,体积更小、解析更快。
-
多路复用:一条连接多流并行传输,彻底解决队头阻塞。
-
头部压缩:减少重复请求头,降低流量消耗。
-
服务器推送:服务端主动推送静态资源。
3、HTTPS(HTTP+SSL)
3.1、端口区别
-
HTTP:80 端口,明文传输,不安全。
-
HTTPS:443 端口,加密传输。
3.2、加密流程
-
客户端发起请求,服务端返回数字证书。
-
客户端校验证书合法性。
-
客户端生成随机密钥,使用服务器公钥加密传输。
-
服务端私钥解密,拿到随机密钥。
-
后续通信全部使用对称加密传输数据。
3.3、HTTPS优缺点
-
优点:防窃听、防篡改、防伪造,数据安全。
-
缺点:多一次握手、加密解密,性能比HTTP略低。
总结 🔴
-
三次握手:建立连接,保证双方收发正常。
-
四次挥手:断开连接,全双工通道单独关闭。
-
TIME_WAIT:保证ACK送达、防止残留报文干扰新连接。
-
HTTP1.1:长连接、队头阻塞、头部冗余。
-
HTTP2.0:二进制、多路复用、头部压缩、服务推送。
-
HTTPS:SSL加密、非对称+对称混合加密、安全、性能稍差。