HTTP 三次握手与四次挥手

您所在的位置:网站首页 socket三次握手 HTTP 三次握手与四次挥手

HTTP 三次握手与四次挥手

2023-09-13 06:38| 来源: 网络整理| 查看: 265

HTTP 三次握手与四次挥手

在这里插入图片描述

HTTP 概述

HTTP是hypertext transfer protocol(超文本传输协议)的简写,它是TCP/IP协议的一个应用层协议,用于定义WEB浏览器与WEB服务器之间交换数据的过程。客户端连上web服务器后,若想获得web服务器中的某个web资源,需遵守一定的通讯格式,HTTP协议用于定义客户端与web服务器通迅的格式

关于 TCP TCP 提供一种面向连接的、可靠的字节流服务 在一个 TCP 连接中,仅有两方进行彼此通信。广播和多播不能用于 TCP TCP 使用校验和,确认和重传机制来保证可靠传输 TCP 给数据分节进行排序,并使用累积确认保证数据的顺序不变和非重复 TCP 使用滑动窗口机制来实现流量控制,通过动态改变窗口的大小进行拥塞控制

TCP并不能保证数据一定会被对方接收到,因为这是不可能的。它不是100%可靠的协议,它所能提供的是数据的可靠传递或故障的可靠通知。

三次握手

在这里插入图片描述

三次握手(Three-way Handshake),是指建立一个 TCP 连接时,需要客户端和服务器总共发送3个包。

第一次握手([SYN], Seq = x) 客户端发送一个SYN标记的包,Seq初始序列号x,发送完成后客户端进入SYN_SEND状态。

第二次握手([SYN,ACK], Seq = y, ACK = x + 1) 服务器返回确认包(ACK)应答,同时还要发送一个SYN包回去。ACK = x + 1,表示确认收到(客户端发来的Seq值 + 1),Seq = y, 表示让客户端确认是否能收到。发送完成后服务端进入SYN_RCVD状态。

第三次握手([ACK], ACK = y + 1) 客户端再次发送确认包(ACK),ACK = y + 1, 表示确认收到服务器的包(服务端发来的Seq值 + 1)。客户端发送完毕后,进入ESTABLISHED状态,服务端接收到这个包,也进入ESTABLISHED状态, TCP握手结束。

为什么是三次握手?不是两次或者四次? 从假设的角度来分析吧,假如是两次握手,会发生什么情况呢? 服务端在发出应答消息后,它根本就不能确认客户端是否接受到消息了,那么这样意味着只有客户端可以向服务端发送数据。 假如是四次握手呢?明明已经保证了一个稳定的传输流了,为什么还要浪费性能再去发一次消息,浪费了性能。 所以三次是最合适的,这里本人只是从个人的角度简单分析,没有从序列等原理的角度去剖析。 四次挥手

在这里插入图片描述

TCP连接的断开需要发送四个包,所以称为四次挥手。

第一次挥手([FIN], Seq = u) 客户端发送一个FIN标记的包,告诉服务器需要关闭连接,表示自己不用发送数据了,但是还可以接收数据。发送完成后,客户端进入FIN_WAIT_1状态。

第二次挥手 ([ACK], ACK = u + 1, Seq = v) 服务端发送一个ACK的确认包,告诉客户端接收到关闭的请求,但是还没有准备好。发送完成后,服务端进入CLOSE_WAIT状态,客户端收到这个包后,进入FIN_WAIT_2,等待服务器关闭连接。

第三次挥手 ([FIN], Seq = w, ACK = u + 1) 服务端准备好关闭连接时,发送FIN标记的包,告诉客户端准备关闭了。发送完成后,服务端进入LAST_ACK状态,等待客户端确认。

第四次挥手 ([ACK], ACK = w + 1) 客户端接收到服务端的关闭请求,再发送ACK标记的确认包,进入TIME_WAIT状态,等待服务端可能请求重传的ACK包。 服务端接收到ACK包后,关闭连接,进入CLOSED状态。 客户端在等待固定时间(两个最大段生命周期)后,没有接收到服务的ACK包,认为服务器已关闭连接,自己也关闭连接,进入CLOSED状态。

为什么是三次握手,却是四次挥手?三次挥手不可以吗?

继续从假设的角度分析,如果是三次挥手,在服务器接收到客户端发送关闭的请求后,把SYN和ACK包一起发过去。这样会造成服务端还有数据没有发送完,造成了数据的丢失。所以中间的这一段时间,等待服务器把剩余的数据发送完是很有必要的。

HTTP 简单工作流程

在这里插入图片描述



【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3