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次握手:
- 客户端发送连接请求到服务端,进入
SYN-SENT
状态 - 服务端收到客户端请求后,确认
SYN
成功后回复客户端,进入SYN-RCVD
状态 - 客户端收到服务端的回复,验证
ACK
和ack
后,给服务端回复一个确认报文,服务端确认通过后,进入ESTAB-LISHED
状态,TCP连接建立成功
4次挥手:
- 客户端向服务端发送
FIN
位码,表示要断开连接,并进入FIN-WAIT-1
第一阶段等待状态 - 服务端接收到客户端的断开请求后,确认
FIN
成功后,给客户端回复一段报文,服务端进入CLOSE-WAIT
关闭等待状态,客户端进入FIN-WAIT-2
第二阶段等待状态 - 服务端继续发送剩余的数据,等发送完后立即向客户端发送
FIN和ACK
位码,等待客户端确认,自身进入LAST-ACK
最终确认状态 - 客户端接收到服务端的断开请求,先确认服务端返回的报文,确认成功后给服务端发送最后的确认报文;服务端接收到确认报文后立马关闭连接,而客户端会进入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,是利用牺牲传输可靠性换取时实性
网友评论