前言

上次我们聊了在浏览器地址栏里输入URL后会有两个步骤,一个是请求资源的过程,一个是拿到请求资源后浏览器渲染的过程,上篇文章我们已经聊过了后半段过程,这篇文章我们把前半段也补上。

正文

当我们在浏览器输入www.baidu.com时,浏览器请求资源的过程主要分为4步。

  1. 首先是域名解析得到服务器IP地址的过程,浏览器会先在本地域名服务器里查找缓存是否有服务器的IP地址,没有则到其他域名服务器里找可能是根域名服务器或者顶级域名服务器直到找到为止,然后会缓存到本地,这样就拿到服务器的IP了。
  2. 然后第二步就是tcp建立连接的过程,也就做三次握手。客户端向服务端发送建立连接的请求,客户端进入syn-sent状态,服务端收到请求向客户端发送syn-ack编码,服务端进入syn-recv状态,客户端收到服务端发送的syn-ack后向服务端发送ack编码,客户端进入established状态。自此连接建立完成,可以发送数据了。
  3. 数据传输,一旦TCP连接建立,浏览器会向百度服务器发送一个HTTP请求。这个请求包含了请求行(如GET / HTTP/1.1,表示请求百度网站的首页)、请求头(包含了如浏览器类型、语言偏好、请求来源等信息)以及可能的请求体(对于GET请求,通常没有请求体)。百度服务器接收到HTTP请求后,会解析请求内容,并根据请求的内容(如URL路径)来决定如何处理这个请求。
  4. tcp断开连接,也叫做四次挥手。客户端向服务端发送断开连接的请求,服务端收到请求后进入close-wait状态,并且向客户端发送同意断开的应答,此时服务端依然能向客户端发送数据,等发送完毕之后,服务端进入last-ack状态,客户端收到同意的应答后,向服务端发送确认接受应答,双方都进入close状态。

这就是浏览器请求资源的大致过程。其中有几个问题和知识点可以拓展一下。

为什么tcp建立连接时是三次握手,两次行不行?

首先两次是不行的,主要原因是会造成资源的浪费。客户端会有超时重传机制,当发送建立连接的请求因网络原因超时或者丢失时,会重新发送一个请求。当超时重传之后的请求连接,数据传输,断开正常完成之后释放连接,客户端,服务端下机,那个因网络问题重传之前的连接请求到达服务端之后,服务端会一直在reverse状态,造成资源浪费。

在数据传输的过程中,会发送HTTP请求,那么HTTP的发展过程我们可以简单聊一下。

HTTP的发展史

HTTP/0.9

背景:HTTP/0.9是HTTP协议的最早版本,被称为单行(one-line)协议或实验版本。

特点:只能发送get请求,并且只有请求行没有请求头和请求体,服务器也没有响应头,只有响应体,只能传输html文件。通过ASCII编码方式传输。

HTTP1.0

背景:为了解决http0.9只能传输html文本的缺点,支持多种类型文件的传输(js,css,图片,音频,视频等)

特点

引入了请求头,请求体,响应头。通过这设置请求头和响应头可以告诉浏览器传输文件过程中的一些规范。

引入了状态码让浏览器能够知道请求的成功和失败。

HTTP1.1

背景:1.0时代http是短连接,随着互联网的发展,被传输的文件的类型和数量大小越来越多,每次传输都要进行tcp连接,增加了很多开销,所以引入了长连接。

但是引入长连接会有一个问题,一次连接可以发送多个请求,请求之间需要保证顺序才能保证接收顺序,所以请求之间必须等待上一个请求完成后才能发送下一个请求造成效率低下,这个问题也叫做队头阻塞,为了解决这个问题引入了管线化技术,但是最终放弃了这个方案。

特点

长连接:建立一个tcp连接,可以传输多个http请求,可以在请求头的Connection字段设置close或者keep-alive

管线化技术:批量化发送请求,允许一次性将所有的http请求发送出去,并给这些请求标记顺序以保证接收顺序。

Chunk transfer机制:服务端将数据分割为若干个任意大小的数据块,每个数据块标记的数据块的大小,最后使用一个长度为0的空数据块作为完成的标志。

引入cookie。

HTTP2.0

背景:1.1对带宽的利用率低下。因为TCP协议会采用一个非常慢的速度去发送数据,然后慢慢加快发送数据的速度。初期,带宽利用率较低。同时开启多个tcp连接,导致多个连接互相竞争带宽,影响关键资源的下载。队头阻塞问题没有彻底解决。

所以为了解决带宽利用率底下的问题,引入了多路复用技术

  1. 不允许同时建立多个tcp连接,一个域名只能建立一个tcp连接
  2. 采用二进制分帧层,将所有的请求处理为一帧一帧的请求,每一帧请求都带上独特的id编号,服务端根据id区分拼接完整的请求体,并以同样的方式返回请求体。

同时也是在这个时候引入了https这个技术。

HTTPS

- TLS协议加密:对称加密 和 非对称加密

对称加密:客户端和服务端使用的密钥相同

非对称加密:服务端先生成公钥,发送给客户端,客户端使用这个公钥加密自己的秘钥,服务端收到客户端的加密秘钥,使用自己的私钥解密,得到客户端的秘钥,双方使用这个秘钥加密数据

HTTP3.0

为了解决http2.0的tcp慢启动和队头阻塞问题,HTTP3.0使用的是TCP加UDP的协议,也叫做QUIC协议。这种协议集合了TCP和UDP两种协议的优点,并且规避了TCP协议的缺点得到优化。

特点:

  1. TCP的可靠性
  2. TLS的安全性
  3. 多路复用机制
  4. UDP的快速握手机制

总结

http0.9时代只能传输HTML文件,并且只有一个请求行,只能发送get请求,通过ascll码进行传输,随着互联网的发展,单纯只能发送HTML文件已经不能满足大家的需求,所以到了1.0时代。1.0时代它支持传输多种文件格式,为了告诉浏览器传输文件规范,所以引入了请求头请求体和响应头。但是它是短连接,每次传输数据都要建立一次TCP连接,浪费资源,所以在1.1时代引入了长连接,一次TCP连接能够发送多次http请求,但是引发了一个新问题,队头阻塞,下一个请求必须等待上一个请求完毕之后才能继续发送,可以使用管线化技术解决但是后来并没有采纳。由于TCP的慢启动和队头阻塞问题,1.1时代对带宽的利用比较低下,2.0时代使用了多路复用技术,将6个TCP连接转化为一个,采用二进制分帧层控制请求传输顺序。但是2.0时代用的还是TCP协议,问题依然存在,所以在3.0时代采用了QUIC协议,它集合了TCP和UDP协议的优点,即将成为新一代HTTP的协议。