HTTP(HyperText Transfer Protocol)

全称“超文本标记语言”,由万维网联盟提出,互联网工程小组标准化的应用层协议。他的设计之初是用于Web浏览器和Web服务器的通信,浏览器向服务器发送请求,服务器再响应后结束了。
HTTP是无状态协议,每次请求和响应结束了之后服务器不会保留任何状态。

http

HTTP是基于TCP的应用层协议,这里就需要提到HTTP与网络模型的关系了:

3

国际化标准组织OSI在上世纪发布的“开放系统互联基本参考模型”,是种学术性的理想模型,刚开始得到了很多国家或组织的支持。但现今规模最大的,覆盖全网的英特网并未完全使用OSI标准,而是符合实际应用,层次分明合理,效率高的TCP/IP模型,成为了事实上的国际标准。简单说就是:能够垄断或占领市场的就是标准。

接下来就需要讲讲TCP和UDP了:

上图可以看出,TCP结构复杂而UDP则相反。以下对他们进行了全面的比较:

既然TCP是可靠、面向连接的协议,当然也就少不了握手了:

三次握手阶段详解(C为Client,S为Server,下同):

  • C向S发送连接请求连接报文段,进入“同步已发送阶段”,等待S的确认。
  • S收到C的SYN标志后,发送SYN和ACK标志,进入同步收到阶段。
  • C收到了SYN和ACK标志后,进入已建立连接阶段,最后向S发送ACK标志的报文段(此时可以发送Data数据),S收到后进入已建立连接阶段。

为何需要三次握手?

这是为了保证双方能够建立可靠的连接,第一次握手只是为了告知S端我想请求,第二次握手是让C端建立连接,第三次握手让S端必须要知道C端建立了连接才是会建立连接,所以这三次握手不多不少。

四次挥手阶段详解:

  • C向S发送连接释放报文段,并停止发送数据,寻求主动关闭连接,C进入“终止等待-1”状态,等待S的确认。
  • S收到连接释放报文段后即发出确认,S进入“关闭等待”状态,这时TCP还处于半关闭状态:“即C没有数据要发送了,但S有数据要发送,C仍然要接收。一句话就是C关闭了但S还没关闭”。C收到S的确认后,就进入“终止等待-2”状态,等待S发出的连接释放报文段。
  • 当S没有数据要发送给C后,其应用进程就通知TCP释放连接,发送释放报文段。这时S进入“最后确认”状态,等待C的确认。
  • C收到S发出的释放报文段后,必须对此发出确认。然后进入到“时间等待”状态,C必须经过时间等待计时器设置的时间2MSL(一般为2分钟)后,C才彻底关闭TCP连接。
  • S只要收到了C的确认,就会关闭TCP连接。

为什么C必须等待2MSL的时间才能关闭?

  1. 为了保证S能收到最后一个ACK报文段。若S没不到,会向C再次发送上一个报文段,等待时间重新计时。
  2. 为了防止“已失效的连接请求报文段”出现在本次连接中。在2MSL的持续时间中,能让所有产生的报文段都从网络中消失。使下一个新的连接中不会出现这种旧的连接请求报文段。

发展历史

img

目前主流的版本是HTTP/1.1和HTTP/2,HTTP/3由2018年标准化的全新一代协议,后面会讲到。

HTTP/1.1

请求和响应体结构

img

请求体和响应体除了第一行由区别,其余都是一样的。

头部域

img

方法

img

状态码

img

以上是HTTP核心的知识点,下面讲讲前端的跨域的CORS配置。

CORS

CORS全称“跨域资源共享”,W3C标准,目的是规避浏览器的同源策略。由于安全原因,浏览器只允许同源的Ajax请求。当响应头包含了正确的CORS配置时,浏览器允许向跨源服务器发Ajax请求,从而克服了Ajax只能同源使用的限制。从网站管理员到前后端人员都应该知晓CORS。

同源策略

img

同源政策的目的,是为了保证用户信息的安全,防止恶意的网站窃取数据。限制范围:

  1. Cookie、LocalStorage 和 IndexDB 无法读取。
  2. DOM 无法获得。
  3. AJAX 请求不能发送。
两种请求

Ajax请求跨域时会被分为两种请求:简单请求和非简单请求,不符合简单请求条件的均为非简单请求。简单请求的条件:

  1. 三种方法之一:HEAD、GET、POST。
  2. 头信息不超出以下字段:Accept、Accept-Language、Content-Language、Last-Event-ID、Content-Type(不超出application/x-www-form-urlencoded、multipart/form-data、text/plain)。

浏览器对这两种请求的处理机制是不一致的。

头部域的CORS字段

img

CORS流程

img

跨域的Ajax请求和同源的Ajax请求完全一样,不同的是,当出现跨域的Ajax时,服务器需要设置CORS来告知浏览器允许访问该资源。CORS是跨域Ajax请求的根本解决办法。

Demo

img

后端通过维护允许跨域访问的列表,根据请求头部域的Origin来匹配并添加Access-Control-Allow-Origin。未匹配到,则响应头部域不带上Access-Control-Allow-Origin。

**注意:*如果要发送Cookie(Access-Control-Allow-Credentials:true),Access-Control-Allow-Origin就不能设为星号,必须指定明确的、与请求网页Origin一致的域名,否则浏览器会因不合法而禁止访问。

缓存控制

HTTP/1.0版本的浏览器缓存主要是通过Expires头部控制来实现的,它只能根据绝对时间来刷新缓存内容。HTTP/1.1版本新增了Cache-Control头部域,使得前端具备了强缓存和协商缓存机制,在Cache-Control存在的情况下,Expires会无效。

缓存控制字段 - Cache-Control

img

即使响应的是no-cache浏览器也会缓存资源,但是每次请求时都会向后端协商,更改则200,未更改则是304,所以no-cache可以用于协商缓存。

协商缓存字段 - Etag/Last-Modified

img

缓存控制流程

img

(蓝色虚线部分为启发式缓存)

缓存会分为强缓存和协商缓存:

  • 当Cache-Control未过期直接从本地缓存读取,这是强缓存。
  • 当Cache-Control过期后向后端请求时带上了If-None-Match或If-Modified-Since请求服务器进行决策,这是协商缓存。

我们应该为静态资源设置合理的Cache-Control响应字段。当没有Cache-Control时,浏览器会使用启发式算法来缓存资源,缓存时间通常是‘Date’减去‘Last-Modified’ 除以10 作为缓存时间,不同的浏览器实现方式可能会不一样。

缓存示例

第一次访问

img

第二次访问

img

Disk Cache是永久缓存至硬盘中;Memory Cache是临时缓存至内存中,浏览器关闭后则从Disk Cache读取缓存。

HTTPS

全称HyperText Transfer Protocol over Secure Socket Layer,基于安全套接字层的超文本传输协议。

为什么要HTTPS?

HTTP是明文的,有被窃听篡改冒充的风险。

img

Chrome已对不安全的HTTP网站禁用摄像头,定位,全屏,设备传感器等涉及隐私的API。接下来看看这把锁匙什么,为什么加了把锁会不一样。

加密算法

这把锁用到了两种加密算法,非对称加密算法和对称加密算法:

HTTPS加密算法

非对称加解密目前只能用来作对称密钥交换或者CA签名,不适合用来做应用层内容传输的加解密。

  • 加解密同等数量的文件,非对称算法消耗的CPU资源是对称算法的1000倍以上,极端消耗CPU资源。
  • 非对称加密算法对加密内容的长度有限制,不能超过公钥长度。比如现在常用的公钥长度是2048位,意味着待加密内容不能超过256个字节。
HTTPS结构
https structure
SSL/TLS发展历史

TLS History

TLS全称是传输层协议,是SSL的升级版,由互联网工程任务组IETF于1999标准化。

TLS1.2四次握手

TLS1.2 握手

握手过程:

  1. 客户端发送「Client hello」 请求连接。
  2. 服务端发送证书,协商加密算法。
  3. 客户端验证证书,成功后用之前协商好的加密算法生产对称密钥,用服务端发送的公钥加密该对称密钥,发送给服务端。
  4. 服务端用私钥解密客户端发送的加密的对称密钥,发送「Finished」结束握手。
  5. 之后两端用对称密钥加密和传送数据。

Session会话恢复

TLS session

使用 TLS 1.2 需要两次往返( 2-RTT )才能完成握手。Session Ticket会在TLS第四次握手时发送给客户端,之后的TLS握手会带上“Session ID”,只需要一次往返。

为什么有单双向验证?

  • 一般Web应用都是采用SSL单向认证的,原因很简单,用户数目广泛,且无需在通讯层对用户身份进行验证,一般都在应用逻辑层来保证用户的合法登入。
  • 如果是企业应用对接,情况就不一样,可能会要求对客户端(相对而言)做身份验证。这时就需要做SSL双向认证,企业应用对接需要注意客户端的证书过期。
TLS1.3二次握手

TLS1.3 握手

TLS 1.3 是一个全新的 TLS 加密协议,相比 TLS 1.2 ,它既能提高各地互联网用户的访问速度,又能增强安全性。TLS 1.3 通过移除对老旧破损的密码协议的支持,来提高性能、效率和安全性。它还通过简化 TLS 握手来提高速度,使其只需要一次往返,后续无需握手即可恢复会话。

TLS1.3 于2018年标准化,目前兼容性不太好,感兴趣的同学可以去CanIUse查询。

HTTP/2

前身是SPDY,优化并解决了HTTP1.X 队头阻塞,效率低,头大(臃肿)等问题。

为什么需要HTTP/2?

  • HTTP/1.1请求响应遵循先进先出,存在对头阻塞。
  • 浏览器对网站的TCP连接由6-8个限制。
HTTP/2 消息结构:

http/2

通过双向数据流传输消息,消息由一或多个帧组成,帧为最小单位传输单位。

  • 帧:HTTP/2最小的通信单位,二进制组成。帧具有优先级,可乱序发送,达到后可根据帧的首部流标识重新拼接成消息。
  • 消息:HTTP请求或响应的消息,包括头部和消息主体。
  • 流:虚拟连接通道,可以承载任意双向数据流,互不干扰,每个数据流以消息的形式发送,流具有优先级。
  • 每个请求都可以带上优先级,两端会以最优的方式发送流,消息和帧。
多路复用:
  • 同一个域名,同一个连接。
  • 以流为基础,并发双向传输。

HTTP/1.1 vs HTTP/3

二进制分帧

HTTP/2采用二进制将消息分成帧传输数据,而非HTTP/1.x的文本格式。应用层(HTTP/2)和传输层(TCP or UDP)之间增加一个二进制分帧层,通过二进制将消息分成帧发送,更为高效。

img

首部压缩

HTTP/1.x 每次请求,都会携带大量冗余头信息,浪费了很多带宽资源。HTTP/2 对消息头部采用HPACK进行压缩传输,首部只传输 “新的头信息”。

  • 两端使用「首部表」来跟踪和存储之前发送的「键值对」,相同的不再发送。
  • 「首部表」在连接中始终存在,两端渐进更新。
  • 新的「键值对」替换或追加在末尾。

首部压缩

服务端推送

服务端向客户端主动推送并让其缓存多个资源,实现「一次请求,多个响应」。让服务器决定优先推送的内容,比前端对内嵌资源优化的手段更为高效。

服务端推送

服务端推送可以有哪些内容?

  • 网页现需要的资源文件。
  • 网页尚未缓存的动态资源文件。
  • 用户可能访问的下一页。

服务端推送对比图:

服务端推送

兼容性

目前主流浏览器中只有IE10不兼容,如果不兼容IE10的话可以完全考虑全站使用HTTP/2。互联网工程任务组发布的HTTP/2标准是允许使用不安全的HTTP的,但各大浏览器厂商要求强制采用HTTPS。

普及率

目前普及率在40%左右,由2018年8月初的29%上升至2019年8月初的39%。

HTTP/3

基于QUIC协议的HTTP,于2018年经互联网工程任务组命名为HTTP/3。

QUIC是传输层协议,基于高效的UDP,整合了TCP、TLS、和HTTP/2的优点,并加以优化。

HTTP/3 structure

为什么需要HTTP/3?
  • TCP太重,存在慢启动,握手成功起初会限制连接速度,当数据传输成功之后会慢慢提高传输速度。HTTP的性能关键在于低延迟,而不是高带宽。
  • TCP存在队头阻塞。
特性一:1RTT - DH密钥交换算法

HTTP/2 的连接需要 3 RTT,如果考虑会话复用,即把第一次握手算出来的对称密钥缓存起来,那么也需要 2 RTT,更进一步的,如果 TLS 升级到 1.3,那么 HTTP/2 连接需要 2 RTT,考虑会话复用则需要 1 RTT。

HTTP/3 首次连接只需要 1 RTT,后面的连接更是只需 0 RTT,意味着客户端发给服务端的第一个包就带有请求数据,这一点 HTTP/2 难以望其项背。

img

QUIC 实现 0 RTT 的一个技术细节是使用了 DH密钥交换算法:

img

特性二:连接迁移

TCP 连接基于四元组(源 IP、源端口、目的 IP、目的端口),切换网络时至少会有一个因素发生变化,导致连接发生变化。当连接发生变化时,如果还使用原来的 TCP 连接,则会导致连接失败,就得等原来的连接超时后重新建立连接,所以我们有时候发现切换到一个新网络时,即使新网络状况良好,但内容还是需要加载很久。

QUIC 的连接不受四元组的影响,当这四个元素发生变化时,原连接依然维持。那这是怎么做到的呢?道理很简单,QUIC 连接不以四元组作为标识,而是使用一个 64 位的随机数,这个随机数被称为 Connection ID,即使 IP 或者端口发生变化,只要 Connection ID 没有变化,那么连接依然可以维持。

特性三:流量控制

TCP 会对每个 TCP 连接进行流量控制,流量控制的意思是让发送方不要发送太快,要让接收方来得及接收,不然会导致数据溢出而丢失,TCP 的流量控制主要通过滑动窗口来实现的。

QUIC 只需要建立一条连接,在这条连接上同时传输多条 Stream,好比有一条道路,两头分别有一个仓库,道路中有很多车辆运送物资。QUIC 的流量控制有两个级别:连接级别(Connection Level)和 Stream 级别(Stream Level)。

特性四:拥塞控制

拥塞控制的目的是避免过多的数据一下子涌入网络,导致网络超出最大负荷。QUIC 的拥塞控制与 TCP 类似,并在此基础上做了改进。

应用情况

img

总结

QUIC 丢掉了 TCP、TLS 的包袱,基于 UDP,并对 TCP、TLS、HTTP/2 的经验加以借鉴、改进,实现了一个安全高效可靠的 HTTP 通信协议。

凭借着零 RTT 建立连接、平滑的连接迁移、基本消除了队头阻塞、改进的拥塞控制和流量控制等优秀的特性,QUIC 在绝大多数场景下获得了比 HTTP/2 更好的效果,HTTP/3 未来可期。

后记

关于HTTP的内容基本上讲完了,谢谢阅读,如有纰漏请联系我加以改正。

最开心的当然是...

techearday 2

教师节收到HR小姐姐的礼物啦~