前端阶段性总结（一）： HTTP 协议，从1.0到2.0

时间 2019-11-08

标签前端阶段性总结 http 协议 1.0 2.0 栏目 HTTP/TCP 繁體版

原文原文链接

引言：转前端一年了，期间工做较忙，也没时间整理一些知识体系，此系列文章是对前端基础的一些回顾与总结。

1、前置知识

咱们知道，HTTP是基于TCP/IP协议的。属于TCP/IP 协议的一个子集，TCP/IP是互联网通讯相关联的协议族的总称。了解TCP/IP协议族有助于咱们更好的理解HTTP协议。html

1. 分层管理

TCP/IP协议族主要分为:前端

应用层 :向用户提供应用服务时通讯的活动。
传输层 :提供处于网络链接中的两台计算机之间的数据传输。
网络层 :网络层用来处理在网络上流动的数据包。
数据链路层：用来处理链接网络的硬件部分。

2.TCP/IP传输流

盗用《图解HTTP》中的一张图：
程序员

举个栗子，客户端在应用层按规范发起了一个HTTP请求，而后由传输层（TCP）负责将报文分片，编序发给网络层，再由网络层增长目标服务器的mac地址，最终由链路层将请求发往目标机器。服务器在链路层接收到数据，按序往上层发送，一直到应用层。当传输到应用层，才能算真正接收到由客户端发送过来的 HTTP请求。web

3. URL 和 URI

URI：统一资源标识符
URL：统一资源定位符

URI是一个用于标识互联网资源名称的字符串，最多见的形式是统一资源定位符（URL），常常指定为非正式的网址。更罕见的用法是统一资源名称（URN），其目的是经过提供一种途径。用于在特定的命名空间资源的标识，以补充网址。
即URL和URN 都是 URI的子集，URI是一种抽象的概念，URL是URI的一种常见的具象表达形式。算法

4. 代理、网关、隧道的概念

a. 代理

简介sql

代理是一种有转发功能的应用程序，它扮演了位于服务器和客户端“中间人”的角色，接收由客户端发送的请求并转发给服务器，同时
也接收服务器返回的响应并转发给客户端。每次经过代理服务器转发请求或响应时，会追加写入 Via 首部信息。数据库

代理的分类：浏览器

透明代理：直接转发请求，不对请求作任何加工，反之则是非透明代理
缓存代理：将请求的资源缓存在代理服务器上，用于下次请求。

代理的方式:缓存

正向代理：简单来讲，正向代理就是对服务器透明，将不一样用户的请求代理到某台服务器，服务器并不知道请求来自哪一个用户。
反向代理：反之，反向代理就是对用户透明，将用户的请求转发到服务器集群的某一台服务器，用户不知道本身访问的具体是哪台服务器。

使用代理的好处：安全

利用缓存技术减小网络带宽的流量。
组织内部针对特定网站的访问控制，以获取访问日志为主要目的

b. 网关

网关的工做机制和代理十分类似，可是它可使用非http协议与服务器、数据库进行通讯，便是说，网关在收到来自客户端的http请求以后，能够直接与数据库链接，使用sql查询数据库。

c. 隧道

隧道的目的是确保客户端能与服务器进行安全的通讯，自己不会去解析 HTTP 请求，也就是说，请求保持原样中转给以后的服务器，隧道会在通讯双方断开链接时结束。隧道多用于相隔较远的两台服务器的安全通讯。

2、 HTTP协议

一. 什么是HTTP？

1. 简介

HTTP是一种属于应用层通讯协议，它容许将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器。

2. 报文的结构

HTTP请求的报文通常是由协议行、可选的请求头部、请求体组成

请求：
Request line
包括：请求方法、请求的资源、HTTP协议的版本号
Request header
包括：Cache头域、Client头域、Cookie/Login头域、Entity头域、Miscellaneous头域、Transport头域等
空行
Request body
Response响应

回包：
Response line
包括：HTTP协议的版本号、状态码、消息
Response header
包括：Cache头域、Cookie/Login头域、Entity头域、Miscellaneous头域、Transport头域、Location头域等
空行
Response body

3. 请求的过程

一个完整的HTTP请求过程以下：

用户在浏览器输入URL
域名解析（DNS的寻址）
TCP三次握手
握手成功后创建TCP通道，发起HTTP请求
服务器响应HTTP请求，返回对应的响应报文
客户端开始解析渲染

4. 状态码

1XX 提示信息：请求正在处理中
2XX 成功错误码：请求已被接受处理
3XX 重定向：完成请求须要附加操做
4XX 客户端错误：请求资源有误或者请求不合法，服务器没法处理
5XX 服务器错误：服务器处理请求出错

常见状态码：
200 OK
302 Found 暂时重定向
301 Move Permanently永久重定向
304 Not Modified 没有内容更新，使用缓存
400 Bad Request 客户端请求与语法错误
403 Forbidden 服务器拒绝提供服务
404 Not Found 请求资源不存在
500 Internal Server Error服务器发生了不可预期的错误
503 Server Unavailable 服务器当前不能处理客户端的请求，一段时间后可能恢复正常

5. 首部字段

首部字段通常分为4类：

通用字段（connection、via、cache-control、data等）
请求首部字段（accept-charset、accept-encoding、If-Modified-Since、Referer、User-Agent等）
响应首部字段（Age、ETag 、Server、Location 等）
实体首部字段（Allow 、Content-Type 、Expires 、Last-Modified等）

二. 特性

HTTP被设计之初，就以简易、灵活为目的。它的主要特性就是简易、灵活、无状态、无链接、支持B/S模式。

1. 无状态的HTTP。

a. 简介

无状态是指：协议自己不保存状态，即每次请求，HTTP这一层都不对请求和响应之中的状态进行保存，后一次请求没法得知前一次请求的信息。
优势是：因为不须要保存状态，对CPU和内存的资源消耗减小，协议能够更快的处理大量事务，可伸缩性也更强。
存在的问题: 随着web应用的快速发展，web变得愈来愈复杂，这样的设计却对一些业务形成了严重的阻碍，好比说，一个购物网站，登录后，每一个页面都须要保持当前的登陆态。而不是让用户每次发起请求都去登陆一下。显然，HTTP无状态的特性没法实现状态的保留。因而，为了解决这个问题，cookie 和 session 技术应运而生。

b. Cookie技术

概念：Cookie 技术经过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。
如何工做：Cookie 会根据从服务器端发送的响应报文内的一个叫作 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。服务器端发现客户端发送过来的 Cookie 后，会去检查到底是从哪个客户端发来的链接请求，而后对比服务器上的记录，最后获得以前状态信息。
缺点： Cookie存在长度和数量的限制，每一个domian不能超过20条，每条不能超过4kb，从安全性的角度来讲，cookie容易被盗用，偷盗者无需知道Cookie中每一个字段的意义，只须要透传cookie就能达到目的。

c. Session 技术

概念： Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据能够保存在集群、数据库、文件中。
如何工做：session 由服务端存储，在一次登录操做后，服务器将登录的帐户信息等做为一个session 写入在特定等文件里，在回包报文中使用set-cookies为客户端设置sessionId，最终，客户端在发送下一次请求的时候，会带上session信息，从而达到状态保存的目的。因此，当客户端禁用了cookie，sessoin也没法工做。

d. 其余的认证技术-token

token验证的大体过程是：客户端和服务器端约定了一种特定的加密方式，好比以cookie中的某个字段经过特定的位运算，加密编码成一串字符串。最终在请求中做为参数传递给服务器，服务器在收到请求时，再使用一样的加密方式，获取加密串，与传过来的参数进行对比。从而达到身份认证的关系。因为同源的关系，cookie没法被盗取，而加密手段也是自定义的，从而保证了安全性。

2. 无链接的HTTP

a.简介：

无链接是指每一次请求结束后都会断开TCP链接。在web技术高速发展的今天，每一个页面须要请求的资源都日益增多，而每次请求都须要从新创建TCP链接，这显然极大的增长了无心义的通讯开销。因而，Keep-Alive 被提出，以解决TCP没法复用的问题。

b. Keep-Alive:

a.简介：

Keep-Alive 其实就是在协议头里面设置 Connection： Keep-Alive , 表示当前链接是持久化的，持续时间有服务器控制，在没有接收到关闭信号时，TCP链接不会断开，这样避免了重复创建TCP请求的无用耗时。

b.问题仍然没有解决：

keep-Alive 对应PC端的帮助很大，但在APP端，请求比较分散，且时间跨度大，将keep-Alive的时间设置为很大显然是不合理的。因此，通常会寻求其余的长链接方案和伪长链接方案。这个下文会详细介绍。

3. 存在的缺陷：

HTTP是一个优秀的协议，可是仍然存在着一些缺陷：

数据明文传输，容易被窃听
不验证通讯方的身份，所以有可能遭遇假装
没法证实报文的完整性，因此有可能已遭篡改

可是，程序员的智慧是无穷的，既然不安全，那就让它安全，因而，HTTPS就诞生了。

3、HTTPS

1. 什么是HTTPS？

HTTPS是 HTTP+ SSL +TLS 的产物，用于对通讯的加密、认证、完整性保护。它并非一种新的协议，而是HTTP的某些部分由SSL和TLS代理。

2. HTTPS如何保证通讯安全（原理）？

a. 原理

咱们先来了解一下经常使用的两种加密方式：

对称加密：加密和解密都是用同一把密钥。
非对称加密：加密和解密是两把不一样的密钥。

HTTPS 使用混合加密机制，即先经过非对称加密交换通讯密钥，拿到密钥后再使用对称加密的方式进行后续的通讯。可是如何保证第一步中，客户端获取到的公共密钥是正确的呢？这时候，就须要用到咱们的数字证书了。

证书是由第三方机构提供认证的，服务器先去第三方机构申请公共密钥，而后会得到公共密钥和使用第三方数字签名，在非对称加密的过程当中，将数字证签名和包含的公共密钥一块儿发给客户端，客户端经过第三方机构的公共密钥对证书上的签名进行验证，一旦经过，则说明公共密钥是正确的。

b. 请求过程

下面看看具体的安全通讯创建过程：

客户端发起client hello 报文，携带客户端支持的ssl版本、加密相关的约定（密钥长度和加密算法）。
服务器响应 server hello 报文，表示能够进行ssl通讯，并携带相关加密约定。
服务器发送 certificate 报文, 携带了公共密钥的证书。
服务器发送 server hello done，表示最初的ssl协商部分结束。
客户端发起 Client Key Exchange 报文，并携带使用第一阶段协商以后获得的Pre-master

secret加密随机串（对称密钥）。

客户端发起 Change Cipher Spec 报文，表示以后的请求将使用Pre-master secret进行加密通讯
客户端发送 Finished 报文。该报文包含链接至今所有报文的总体校验值。此次握手协商是否可以成功，要以服务器是否可以正确解密该报文做为断定标准。
服务器发送 Change Cipher Spec 报文，表示解密成功，下面将使用协商的密钥进行安全通讯。
服务器发送 Finished 报文，至此，一个安全的通讯已经简历。
应用层协议通讯，即发送 HTTP 响应。
最后由客户端发送 close_notify 报文断开链接。

3. HTTPS存在的缺陷

SSL加密致使的速度的下降和服务器负载的增大。
申请证书须要的开销

4、 HTTP2协议

1. 历史痛点

a. HTTP1.0 时代最大的两个问题就是：

链接没法复用 : 每次请求都须要从新创建tcp通道，经历三次握手的过程。
队头阻塞：请求通道如一个独木桥，多个请求一块儿发出，只能先等第一个请求得到回包以后才能开始第二个请求，不然就只能排队等候。

b. 那些年的解决之道：

1. 解决链接没法复用：

基于tcp的长连接:

通常APP会基于TCP造一个长链接的通讯协议，门槛较高，可是一旦完成，带来的回报也是很是大的。信息的推送和更新变得及时，且在一些请求爆发点，相较于传统HTTP重复创建请求的耗时，也能减轻服务器的压力。如今业界的成熟方案如：google的protobuf。

http long-polling:

long-polling请求就是在客户端初始化的时候发起一个polling请求到服务器，而后请求一直等待中，当服务器有资源更新的时候，再返回数据，数据放回时，再次发起一个polling请求继续监听。固然，polling请求也有一些缺陷，好比长时间的链接会增长服务器压力，复杂的业务场景下须要考虑如何才能创建健康的请求通道等。此外，这种方式有个致命的缺陷是：数据通讯是单向的，主动权在服务端这边，客户端只能根据服务端被动的接受数据，有新的业务请求的时候没法及时传送。

http streaming:

与http-polling 不一样的是， http-streaming 在初始化的的时候就发起一个不会断开的请求，持续监听服务器的回包，服务器有数据更新时就经过这个请求通道返回数据。此种方式跟http-polling同样是单向的，streaming是经过在server response的头部里增长”Transfer Encoding: chunked”来告诉客户端后续还会有新的数据到来。固然，streaming 也有缺陷: 业务数据没法按照请求来作分割，因此客户端没收到一块数据都须要本身作协议解析，也就是说要作本身的协议定制。

websocket:

WebSocket和传统的tcp socket链接类似，也是基于tcp协议，提供双向的数据通道。WebSocket优点在于提供了message的概念，比基于字节流的tcp socket使用更简单，同时又提供了传统的http所缺乏的长链接功能。websocket 通常在数据须要实时更新的场景中使用。

2. 解决队头阻塞:

http pipelining（管线化）

管线化的前提是长链接的创建，keep-alive的多个请求使用同一个tcp链接使请求并行成为可能，pipelining与传统的请求能够形象的比喻为串行和并行，多个请求同时发起，无需等待上一个请求的回包。可是它并非救世主，也存在着缺陷：

pipelining只适用与HTTP1.1，而且须要服务器端支持
队头阻塞的问题并无根本的解决，由于服务端要响应要遵循先进先出的原则，第一个请求的回包发出以后，才会响应第二个请求。

2. 新的改变(HTTP2)

HTTP1.0和1.1的普及程度使得HTTP2必须得在不改变原有方式的状况下解决上述问题，即HTTP2 并不能像angular2那样放飞自我。因此，HTTP2的使用方式和原来的差很少，HTTP2的改变至关之多，这里主要讲一下对咱们影响较大的几点：

a. 二进制

http2.0的协议解析决定采用二进制格式，实现方便且健壮。每个请求都有这些公共字段：Type, Length, Flags, Steam Identifier和frame payload。http2.0的格式定义更接近tcp层的方式，length定义了整个frame的开始到结束，type定义frame的类型（一共10种），flags用bit位定义一些重要的参数，stream id用做流控制，剩下的payload就是request的正文了。

b. 多路复用

多路复用是HTTP2.0主要解决的一个问题，一个request对应一个stream并分配一个id，这样一个链接上能够有多个stream，每一个stream的frame能够随机的混杂在一块儿，接收方能够根据stream id将frame再归属到各自不一样的request里面。

c. 头部压缩

无状态的HTTP致使每次请求都须要携带服务器所须要的参数，而一些头部信息基本上是固定的，这部分重复的信息恰好能够用于压缩，减小报文体积。

d. 链接重置

HTTP 1.1的有一个缺点是：当一个含有确切值的Content-Length的HTTP消息被送出以后，你就很难中断它了。固然，一般你能够断开整个TCP连接（但也不老是能够这样），但这样致使的代价就是须要从新经过三次握手创建一个新的TCP链接。一个更好的方案是只终止当前传输的消息并从新发送一个新的。在http2里面，咱们能够经过发送RST_STREAM帧来实现这种需求，从而避免浪费带宽和中断已有的链接。

e. 依赖与优先级

每一个流都包含一个优先级，优先级被用来告诉对端哪一个流更重要。从而实现资源的有效分配。

f. 服务器推送

当一个客户端请求资源X，而服务器知道它极可能也须要资源Z的状况下，服务器能够在客户端发送请求前，主动将资源Z推送给客户端。这个功能帮助客户端将Z放进缓存以备未来之需。

g. 流量控制

http2上面每一个流都拥有本身的公示的流量窗口，它能够限制另外一端发送数据。

5、总结：

HTTP 虽然只有2个版本，可是每一个版本所包含的改动是很是之大的。所作出的突破和尝试也是很是多的，固然，HTTP也有竞争者，好比在HTTP2还未提出时，由google提出并推行的SPDY协议，它的优点在于解决了HTTP1.0的不能多路复用的问题，对资源请求速度有极大的提高，目前在市场上仍然有许多的使用量，HTTP2也是借鉴了不少SPDY的特性。再好比quic协议，是号称比HTTP2更快的协议。这个在下一篇文章中会重点介绍~ 哈！主要是这篇有点长了。

参考文献

https://www.zhihu.com/questio...
http://wiki.jikexueyuan.com/p...