美文网首页
TCP的三次握手四次握手

TCP的三次握手四次握手

作者: 风向应该可以决定发型吧 | 来源:发表于2020-11-17 22:33 被阅读0次

    HTTP是建立在TCP协议上的。

    概念

    TCP(Transmission Control Protocol):传输控制协议

    位码:TCP标志位,有6种:

    • SYN(synchronous建立联机)
    • ACK(acknowledgement 确认)
    • PSH(push传送)
    • FIN(finish结束)
    • RST(reset重置)
    • URG(urgent紧急)

    Sequence number(顺序号码) Acknowledge number(确认号码)

    其他概念:

    seq: 序列号
    ack: 确认序列号
    ACK: 确认位码
    SYN: 发起连接标志位码

    简单说

    3次握手:

    1. 客户端发送连接请求到服务端,进入SYN-SENT 状态
    2. 服务端收到客户端请求后,确认SYN成功后回复客户端,进入SYN-RCVD 状态
    3. 客户端收到服务端的回复,验证ACKack后,给服务端回复一个确认报文,服务端确认通过后,进入ESTAB-LISHED状态,TCP连接建立成功

    4次挥手:

    1. 客户端向服务端发送FIN位码,表示要断开连接,并进入FIN-WAIT-1第一阶段等待状态
    2. 服务端接收到客户端的断开请求后,确认FIN成功后,给客户端回复一段报文,服务端进入CLOSE-WAIT 关闭等待状态,客户端进入FIN-WAIT-2第二阶段等待状态
    3. 服务端继续发送剩余的数据,等发送完后立即向客户端发送FIN和ACK位码,等待客户端确认,自身进入LAST-ACK最终确认状态
    4. 客户端接收到服务端的断开请求,先确认服务端返回的报文,确认成功后给服务端发送最后的确认报文;服务端接收到确认报文后立马关闭连接,而客户端会进入2MSL(一个请求来+回的时间)的等待,之所以要等待,因为如果第四次挥手的报文丢失,服务端无法收到确认报文,就会重发第三次挥手的报文,报文一来一回的时间就是2MSL

    详细版

    http的3次握手":

    • 第一次握手: 客户端 -> 服务端,发送连接请求,进入 SYN-SENT 状态
      • 发送SYN=1给服务端
      • 发送seq=x,序列号给服务端,seq叫做序列号,x是个随机数
      • 进入 SYN-SENT 状态
    • 第二次握手: 服务端校验 + 服务端到客户端,返回请求,进入 SYN-RCVD 状态
      • 服务端收到SYN并且SYN=1,明白是客户端请求建立连接(服务端校验)
      • 返回SYN=1给客户端
      • 返回ACK=1给客户端
      • 返回seq=y,一个新的序列号,也是随机生成
      • 返回ack=x+1给客户端
      • 进入 SYN-RCVD 状态
    • 第三次握手: 客户端校验 + 客户端 -> 服务端 + 服务端校验
      • 客户端收到回复发现ACK=1并且ack=x+1,也就是第一次握手时发送给服务端的seq,验证通过(客户端校验)
      • 客户端发送ACK=1给服务端
      • 客户端发送seq=x+1,ack=y+1
      • 服务端收到后发现 ACK=1并且ack=y+1,验证成功,连接建立成功

    4次挥手:

    假如:
    建立连接时(第一次握手)的seq=x,客户端共发送了n个字节的数据;
    服务端初始(第二次我搜狐)返回的seq=y,服务端共发送了m个字节的数据.

    • 第一次挥手: 客户端 -> 服务端
      • 客户端向服务端发送FIN=1
      • seq=u,u=x+1+n(其中的1是建立连接时占的一个序列号)
      • 进入: SYN-WAIT2 状态
      • 此时客户端不再发送数据,但还可以接收数据
    • 第二次挥手: 关闭等待状态: 服务端验证 + 服务端 -> 客户端
      • 服务端收到 FIN并且FIN=1,知道客户端想要断开连接(服务端验证)
      • 返回ACK=1给客户端
      • 返回seq=v给客户端,v=y+m
      • 返回ack=u+1给客户端
      • 进入CLOSE-WAIT状态,这时不是立马发送FIN给客户端,因为可能还有数据没有发送完
    • 第三次挥手: 数据发送完成: 服务端 -> 客户端
      • 服务端将最后的数据(如 o个字节)发送完毕后向客户端发送释放报文: FIN=1
      • 服务端发送ACK=1给客户端
      • 服务端发送seq=w给客户端,w=v+o
      • 服务端发送ack=u+1给客户端,这个ack与第二次挥手的值一样
    • 第四次挥手: 客户端验证 + 客户端 -> 服务端 + 服务端验证
      • 客户端收到服务端的FIN并且FIN=1,知道服务端同意关闭连接(客户端验证)
      • 客户端发送ACK=1给服务端(客户端确认报文, 客户端 -> 服务端)
      • 客户端发送ack=w+1给服务端(客户端确认报文, 客户端 -> 服务端)
      • 客户端发送seq=u+1给服务端(客户端确认报文, 客户端 -> 服务端)
      • 客户端进入2MSL的等待期(最长报文段寿命的2倍时长)后释放TCP连接
      • 服务端收到客户端的确认报文后立马释放TCP连接,所以服务端结束TCP连接的时间要比客户端早一些。

    第四次挥手后为什么要进行2MSL时间的等待?
    考虑丢包的问题,如果第四次挥手的报文丢失,服务端没收到确认ack报文就会重发第三次挥手的报文,这样报文一去一回最长时间就是2MSL,所以需要等这么长时间来确认服务端确实已经收到了。

    HTTP2 比 HTTP1.X 的优势

    • 增加二进制解析,1.x是文本解析
    • 多路复用: 即连接共享,原来是一次请求一个连接建立和断开过程,现在支持一次连接可以进行多次请求,解决了同域名下并行下载数量的限制(chrome是6个,其他浏览器也不会超过10个)
    • 头部压缩,减小了数据包大小

    TCP三次握手和四次挥手的好处

    确保数据的安全和完整。

    响应头: 服务器会告诉浏览器数据的长度,浏览器数据长度和响应头数据长度相同,说明数据已经接收完毕了。

    TCP和UDP对比

    • TCP连接的建立要通过3次握手和4次挥手,确保数据传输的完整性和安全性
    • UDP连接没有TCP复杂,通过暴力手段传输数据,而不管接收方是否能全部接受到,常见应用有: 音视频通话
    • TCP面向连接,拥有可靠性,有序性,UDP都没有这些优点
    • TCP有流量控制能力,TCP通常在发送包之前会测试网络的快慢情况
    • TCP是重量级的,UDP是轻量级的: 因为TCP要保证可靠性和有序性,所以TCP数据报文报头的信息量大,报头大小是20个字节,UDP报头的大小是8个字节。所以TCP占用的系统的开销大。
    • TCP没有数据边界,UDP有数据边界: 因此TCP容易发生粘包的现象。在UDP中数据包是单独发送的,只有当他们到达时才会再次集成,包有明确的界限来判断哪些包已经收到。
    • UDP用来:在线视频媒体,电话视频聊天,qq聊天,电视广播,多人在线游戏,DOS攻击也是利用UDP,是利用牺牲传输可靠性换取时实性

    相关文章

      网友评论

          本文标题:TCP的三次握手四次握手

          本文链接:https://www.haomeiwen.com/subject/jinfiktx.html