目录
为什么第四次挥手时,客户端要等待2*MSL事件后才进入断开连接状态?
Tcp三次握手
-
一次握手:客户端发送SYN(客户端的初始序列号ISN)报文给服务端。客户端进入SYN_SEND状态,等待服务端确认
-
二次握手:服务端发送SYN(服务端的初始序列号ISN)+ ACK(客户端SYN + 1)报文给客户端,服务端进入SYN_RECV状态
-
三次握手:客户端发送ACK(服务端SYN + 1)报文给服务端,之后客户端和服务端都进入ESTABLISHED状态,完成三次握手
为什么要三次握手?
-
第一次握手:客户端什么都无法确认;服务端知道客户端的发送正常,自己的接收正常
-
第二次握手:客户端知道自己的发送和接收正常,服务端的发送和接收正常;服务端知道客户端发送正常,自己的接收正常,但不知道自己的发送和客户端的接收是否正常
-
第三次握手:客户端知道自己的发送和接收正常,服务端的发送和接收正常;服务端知道自己的发送接收正常,客户端的发送接收正常
所以必须三次握手才能确认彼此的发送接收正常
半连接队列和全连接队列
-
半连接队列:服务端接收到客户端的SYN报文后,此时双方还未建立连接,服务端会将半连接状态的连接放到半连接队列
-
全连接队列:服务端接收到客户端的ACK报文后,三次握手完成,服务端会将该连接转移到全连接队列。如果未接收到客户端的ACK报文,会进行重传,重传的时间指数增长,重传次数超过系统规定最大重传次数,该连接会被移出半连接队列
三次握手可以携带数据吗?
第三次握手时可携带数据。当客户端发送完ACK报文后,客户端就进入了ESTABLIAHED状态。也就说当前两次握手完成时,TCP协议允许第三次握手时传输数据
如果第三次握手时ACK报文丢失,但客户端已经开始传输数据,那么服务端在接收到数据包时,若包中含有ACK报文,那么服务端会将其视为有效的第三次握手确认。
TCP四次挥手
-
第一次挥手:客户端发送FIN(SEQ = x)报文给服务端,表示客户端已无数据要发送,客户端进入FIN-WAIT-1状态
-
第二次挥手:服务端发送ACK(x + 1)报文给客户端,表示服务端已接受到客户端的请求,服务端进入CLOSE-WAIT状态,客户端进入FIN-WAIT-2状态
-
第三次挥手:当服务端无数据要发送时,服务端发送FIN(SEQ = y)报文给客户端,请求关闭连接,服务端进入LAST-ACK状态
-
第四次挥手:客户端发送ACK(y + 1)报文给服务端,客户端进入TIME-WAIT状态,服务端接收到ACK报文后进入CLOSE状态,此时客户端等待2MSL后没有收到回复,客户端就断开连接
为什么不能把服务端发送的ACK和FIN合并,变成三次挥手?
当服务端接收到客户端断开连接请求时,服务端可能还有一些数据需要发送,所以先回复ACK,当服务端数据发送完毕时,再发送FIN报文,断开数据连接
第二次挥手时服务端ACK没有送达客户端会怎么样?
客户端没有收到ACK报文,会重新发送FIN报文
为什么第四次挥手时,客户端要等待2*MSL事件后才进入断开连接状态?
MSL:报文段最长寿命,2*MSL就是一次发送+一次回复的最长时间
第四次挥手时ACK报文可能丢失,若服务端没有收到ACK报文,会重传FIN报文,若客户端在2*MAL内再次收到FIN报文就代表之前的ACK报文丢失,客户端会重新发送ACK报文并等待2MSL
反之,若2MSL内没有收到任何内容,则代表ACK报文发送成功,客户端断开连接
Http和Https的区别
Http协议:超文本传输协议,是一个无状态协议。Http是应用层协议,以Tcp(传输层)作为底层协议,默认端口为80。Http都是明文传输;
Https协议:s为Secure,是Http的加强安全版本,Https基于Http,同样以Tcp作为底层协议,并额外使用SSL/TLS协议作为加密和安全认证,默认端口号为443
SSL/TLS协议是一个协议
Http安全性没有Https高,但Https需要耗费更多服务器资源
SSL/TLS协议
非对称加密
SSL/TLS的核心要素为非对称加密,非对称加密采用两个密钥:公钥和私钥。公钥用来加密,私钥用来解密。在通信时,私钥由解密者(收信者)保管,公钥由任何一个想要与解密者通信的发送者(加密者)所知。
公钥只能加锁不能解锁,解锁必须要使用私钥。每个发送者通过公钥来对信息进行加密,收信者收到后再使用私钥来解密,这样信息就不会被他人截获,保密性依赖私钥的保密性。
对称加密
非对称加密的数学算法较为复杂,因此SSL/TLS实际对消息采用对称加密。
对称加密:通信双方共享同一密钥key,加解密算法已知,加密和解密都通过这一密钥key进行,保密性依赖密钥key的保密性。
为什么还要使用非对称加密
由于对称加密依赖于密钥key的保密性,由于网络通信是透明的,所以密钥的交换肯定不能再网络信道中传输。因此SSL/TLS使用非对称加密对对称加密的密钥key进行加密。
这样通信双方只需进行一次非对称加密,交换对称加密的密钥。在之后的网络通信中,就可以使用安全的密钥key对信息进行对称加密;
SSL/TLS证书
在进行非对称加密时,客户端需要先获取服务端的公钥。由于公钥在网络信道中传输,因此可能被第三方捕获并调包,发给客户端一个自己的公钥。客户端使用第三方公钥加密后发送给服务端,第三方再捕获加密后的信息并用第三方自己的私钥解密,就可以获取客户端发给服务端的内容
因此客户端向服务器发Https请求时,需要先获取目标服务器的证书,证书由受信任第三方机构CA颁发。根据证书上的信息,检验证书合法性,检验到证书非法时就会发生错误。证书上包含着服务器的公钥,这样客户端就可以放心地信任证书上的公钥
Http1.0和Http1.1的区别
-
连接方式:Http1.0为短链接,Http1.1支持长连接,Http协议的长连接和短连接,实际上是Tcp协议的长连接和短连接
-
状态响应码:Http1.0中仅定义了16中响应码,Http1.1加入了大量的响应码
-
缓存机制:Http1.0中主要使用Header中的If-Modified-Since,Expires来作为缓存判断的标准,Http1.1则引入了更多的缓存控制策略如 Entity tag,If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
-
带宽:Http1.0中存在一些浪费带宽情况,例如客户端只需要某个对象的一部分,服务器却把整个对象发过来了,并且不支持断电续传功能。Http1.1再请求头部分引入了range部分,允许之请求资源的某个部分,即返回码是206
-
Host头:Http1.1引入了Host头字段,允许在同一ip地址上托管多个域名
Http1.1和Http2.0的区别
-
多路复用:Http2.0在同一连接上可以同时处理多个请求和响应。Http1.1使用串行方式,每次请求和响应都需要单独的连接
-
二进制分帧:Http2.0使用二进制帧,将请求和响应分割为更小的单位进行传输。Http1.1使用文本格式的报文
-
头部压缩:Http1.1不支持Header压缩。Http2.0支持对Header压缩,使用了专门为Header压缩设计的算法HPACK;
-
服务器推送:Http2.0支持服务器推送,当客户端请求一个资源时,服务器会将其他相关资源一并推送给客户端。Http1.1需要客户端自己发请求
Http2.0和Http3.0的区别
- 传输协议:Http2.0基于Tcp协议实现。Http3.0新增了QUIC协议(Quick UDP Internet Connections)来实现可靠传输,提供与SSL/TLS相当的安全性。Http3最大的改造就是使用了QUIC