HTTP知识体系

HTTP知识体系
1、HTTP概念
超文本传输协议, http是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范
2、HTTP协议优缺点
2.1 特点
灵活可扩展
请求应答模式 -> 就是一方发送消息, 另一方接受消息或者是做出响应
可靠传输 -> http是基于TCP/IP, 因此把这一特性继承了下来
2.2 缺点
明文传输 -> 协议里的报文不使用二进制数据, 而是文本的形式, 这样让报文暴露在了外界, 给攻击者带来了便利
队头阻塞 -> 当http开启长链接时, 共用一个TCP链接, 当某个请求时间过长时, 其它的请求只能处于阻塞状态
3、版本间的差异
HTTP 0.9
只有一个命令GET, 只支持纯文本内容
HTTP 1.0
任何格式的内容都可以发送;
除了GET, 还引入了POST和HEAD;
请求和回应的格式改变, 每一次通信都必须包含头信息用来描述一些元数据;
不支持断点续传, 每次都会发送全部的页面和数据
HTTP 1.1
是目前最主流的http协议版本;
引入了持久连接, 即TCP连接默认不关闭, 可以被多个请求头复用;
引入了管道机制, 在同一个TCP连接里, 客户端可以同时发送多个请求;
支持断点续传, 通过使用请求头中的range来实现;
使用了虚拟网络, 在一台物理服务器上可以存在多个虚拟主机, 并且可以共享一个IP地址;
新增方法PUT、PATCH、OPTIONS、DELETE
HTTP 1.x版本问题
传输内容都是明文, 无法保证数据的安全性
默认允许复用TCP连接, 容易造成队头阻塞
HTTP 2.0
二进制分帧 -> 是一次彻底的二进制协议
头部压缩 -> 使用HPACK算法进行压缩
多路复用 -> 复用TCP连接, 在一个连接里, 客户端和浏览器都可以同时发送多个请求或回应, 且不用按照顺序一一对应, 这样解决了队头阻塞的问题
服务器推送 -> 允许服务器未经请求, 主动向客户端发送数据
请求优先级 -> 可以设置数据帧的优先级, 让服务器优先处理重要资源, 优化用户体验
4、HTTP常见状态码
4.1 1xx 信息类
接收的请求已被接受, 正在处理
4.2 2xx 成功
200 -> 表示从客户端发来的请求在服务器端被正确请求
204 -> 表示请求成功, 但是没有资源可返回
4.3 3xx 重定向
301 -> 永久性重定向, 表示资源已被分配了新的URL, 这是应该按照Location首部字段提示的URI重新保存
302 -> 临时性重定向, 表示资源临时被分配了新的URI
303 -> 表示资源存在另一个URL, 应使用GET方法获取资源
304 -> 当协商缓存命中时会返回这个状态码
307 -> 临时重定向, 和302含义相同, 不会改变method
4.4 4xx 客户端错误
400 -> 请求报文存在语法错误
401 -> 表示发送的请求需要有通过HTTP认证的认证信息
403 -> 表示对请求资源的访问被服务器拒绝
404 -> 表示在服务器上没有找到请求资源
405 -> 服务器禁止使用该方法
4.5 5xx 服务器错误
500 -> 表示服务器端执行请求时发生了错误
502 -> 服务器自身是正常的, 访问的时候出现了问题, 具体啥错误我们并不知道
503 -> 表示服务器暂时处于超负载或者正在停机维护的状态, 无法处理请求
5、DNS是如何工作的
5.1 什么是DNS
DNS协议提供的是一种主机名到IP地址的转换服务, 就是我们常说的域名系统, 是应用层协议, 通常该协议运行在UDP协议之上, 使用的是53端口号
5.2 查询过程
一般向本地DNS服务器发送的请求是递归查询的
dns.png
dns2.png
5.3 递归查询和迭代查询
递归查询 -> 查询请求发出后, 域名服务器代为向下一级域名服务器发出请求, 最后向用户返回查询的最终结果; 使用递归查询, 用户只需要发出一次查询请求
迭代查询 -> 查询请求后, 域名服务器返回单次查询的结果, 下一级的查询由用户自己请求; 使用迭代查询, 用户需要发出多次的查询请求
5.4 DNS缓存
缓存也很好理解, 在一个请求中, 当某个DNS服务器收到一个DNS回答后, 它能够回答中的信息缓存在本地存储器中; 返回的资源记录中的 TTL 代表了该条记录的缓存的时间
5.5 DNS如何实现负载均衡
使用多台服务器提供服务, 一个域名可能会对应多个服务器地址
将用户的请求均衡的分配到不同的服务器上, 这样来实现负载均衡
5.6 DNS为什么使用UDP协议作为传输层协议
主要原因是为了避免使用TCP协议时造成的连接时延
为了得到一个域名的IP地址, 往往会向多个域名服务器查询, 如果使用TCP协议, 那么每次请求都会存在连接时延, 这样就会使DNS服务变得很慢
大多数的地址查询请求, 都是浏览器请求页面时发出的, 这样会造成网页的等待时间过长
6、HTTP的缓存策略
6.1 强缓存
强缓存两个相关字段 Expires和Cache-Control
强缓存分为2种情况 发送HTTP请求和不需要发送
Expires
过期时间, 时间是相对于服务器的时间而言的, 存在于服务端返回的响应头中, 在这个过期时间之前可以直接从缓存中获取数据, 无需再次请求

Expires: Mon, 29 Jun 2020 11:10:23 GMT

// 表示该资源在2020年7月29日11:10:23过期, 过期之后就会重新向服务器发起请求
Cache-Control
过期时长, 对应的是max-age

Cache-Control: max-age=6000

// 表示该资源返回后的6000秒, 可以直接使用缓存
注意
当Expires和Cache-Control同时存在时, 会优先考虑后者
缓存资源失效, 也就是没有命中强缓存, 就会进入协商缓存
6.2 协商缓存
强缓存失效后, 浏览器在请求头中携带响应的缓存tag来向服务器发送请求, 服务器根据对应的tag来决定是否使用缓存
分为两种：Last-Modified和ETag
Last-Modified
这个字段表示最后修改时间, 在浏览器第一次给服务器发送请求后, 服务器会在响应头中加上这个字段

// 流程：

// 1.浏览器接收到后, 如果再次请求, 会在请求头中携带If-Modified_Since字段, 这个字段的值也就是服务器传来的最后修改时间

// 2.服务器拿到请求头中的If-Modified_Since字段后, 会和最后修改时间做对比

// 3.如果小于最后修改时间, 说明是时候更新了, 返回新的资源跟常规的HTTP请求响应的流程一致

// 4.否则返回304, 告诉浏览器直接使用缓存
ETag
是服务器根据当前文件的内容, 对文件生成的唯一的标识, 只要里面的内容有改动, 这个值就会修改, 服务器通过响应头把该字段给浏览器
浏览器接收到ETag值, 会在下次请求的时候, 将这个值作为If-None-Match这个字段的内容发给服务器
两者对比
性能上, Last-Modified优于ETag, Last-Modified记录的是时间点, 而Etag需要根据文件的MD5算法生成对应的hash值
精度上, ETag优于Last-Modified, ETag按照内容给资源带上标识, 能准确感知资源变化, Last-Modified在某些场景并不能准确感知变化
6.3 缓存位置
Service Worker
这个应用场景比如PWA, 它借鉴了Web Worker思路, 由于它脱离了浏览器的窗体, 因此无法直接访问DOM; 它能完成的功能比如：离线缓存、消息推送和网络代理, 其中离线缓存就是「Service Worker Cache」
Memory Cache
指的是内存缓存, 从效率上讲它是最快的, 从存活时间来讲又是最短的, 当渲染进程结束后, 内存缓存也就不存在了
Disk Cache
存储在磁盘中的缓存, 从存取效率上讲是比内存缓存慢的, 优势在于存储容量和存储时长
Push Cache
推送缓存, 这算是浏览器中最后一道防线吧, 它是HTTP/2的内容
7、HTTP的请求方法
7.1 每个请求方法的作用
GET： 请求获取Request-URI所标识的资源
POST：在Request-URI所标识的资源后附加新的数据
HEAD：请求获取由Request-URI所标识的资源的响应消息报头
PUT： 请求服务器存储一个资源, 并用Request-URI作为其标识（修改数据）
DELETE：请求服务器删除对应所标识的资源
TRACE：请求服务器回送收到的请求信息, 主要用于测试或诊断
CONNECT：建立连接隧道, 用于代理服务器
OPTIONS：列出可对资源实行的请求方法, 用来跨域请求
7.2 GET和POST的区别
从缓存角度看, GET 请求后浏览器会主动缓存, POST 默认情况下不能
从参数角度来看, GET请求一般放在URL中, 因此不安全, POST请求放在请求体中, 相对而言较为安全, 但是在抓包的情况下都是一样的
从编码角度看, GET请求只能经行URL编码, 只能接受ASCII码, 而POST支持更多的编码类型且不对数据类型限值; GET请求幂等, POST请求不幂等, 幂等指发送 M 和 N 次请求（两者不相同且都大于1）, 服务器上资源的状态一致
GET请求会一次性发送请求报文, POST请求通常分为两个TCP数据包, 首先发 header 部分, 如果服务器响应 100(continue), 然后发 body 部分
7.3 OPTIONS方法有什么作用
OPTIONS 请求与 HEAD 类似, 一般也是用于客户端查看服务器的性能
这个方法会请求服务器返回该资源所支持的所有 HTTP 请求方法, 该方法会用’*‘来代替资源名称, 向服务器发送 OPTIONS 请求, 可以测试服务器功能是否正常
JS 的 XMLHttpRequest对象进行 CORS 跨域资源共享时, 对于复杂请求, 就是使用 OPTIONS 方法发送嗅探请求, 以判断是否有对指定资源的访问权限
8、URL的理解
8.1 组成
url.png
8.2 编码
URL 只能使用 ASCII 字符集来通过因特网进行发送
由于 URL 常常会包含 ASCII 集合之外的字符, URL 必须转换为有效的 ASCII 格式
URL 编码使用 “%” 其后跟随两位的十六进制数来替换非 ASCII 字符
URL 不能包含空格; URL 编码通常使用 + 来替换空格
9、队头阻塞问题
9.1 什么是队头阻塞
对于每一个HTTP请求而言, 这些任务是会被放入一个任务队列中串行执行的, 一旦队首任务请求太慢时, 就会阻塞后面的请求处理
9.2 解决方法
并发连接
对于一个域名而言, 是允许分配多个长连接的, 那么可以理解成增加了任务队列, 也就是说不会导致一个任务阻塞了该任务队列的其他任务, 在RFC规范中规定客户端最多并发2个连接, 不过实际情况就是要比这个还要多, 举个例子, Chrome中是6个
域名分片
我们可以在一个域名下分出多个二级域名出来, 而它们最终指向的还是同一个服务器, 这样子的话就可以并发处理的任务队列更多, 也更好的解决了队头阻塞的问题
比如TianTian.com, 可以分出很多二级域名, 比如Day1.TianTian.com, Day2.TianTian.com, Day3.TianTian.com, 这样子就可以有效解决队头阻塞问题
10、HTTPS和HTTP的区别
HTTPS要比HTTP多了secure安全性这个概念
实际上HTTPS并不是一个新的应用层协议, 其实就是HTTP + TLS/SSL协议组合而成的, 而安全性的保证是TLS/SSL所做的工作
SSL -> 安全套接层
TLS -> 传输层安全
HTTPS就是身批了一层SSL的HTTP
https.png
区别
HTTP 是明文传输协议, HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议, 比 HTTP 协议安全
HTTPS比HTTP更加安全, 对搜索引擎更友好, 利于SEO, 谷歌、百度优先索引HTTPS网页
HTTPS标准端口443, HTTP标准端口80
HTTPS需要用到SSL证书, 而HTTP不用
11、HTTPS工作原理
11.1 工作流
httpswork.png
11.2 第三方认证
客户端无法识别传回公钥是中间人的还是服务器的, 可以通过第三方认证的方式来让客户端和服务器遵循约定
而在HTTPS中, 就是通过证书 + 数字签名来解决这个问题
sanfang.png
11.3 数字签名的作用
将网站的信息通过特定的算法加密, 比如MD5加密之后, 再通过服务器的私钥进行加密, 行成`加密后的数字签名
12、SSL 连接断开后如何恢复
12.1 session ID
使用 session ID 的方式, 每一次的会话都有一个编号, 当对话中断后, 下一次重新连接时, 只要客户端给出这个编号, 服务器如果有这个编号的记录, 那么双方就可以继续使用以前的秘钥, 而不用重新生成一把; 目前所有的浏览器都支持这一种方法. 但是这种方法有一个缺点是, session ID 只能够存在一台服务器上, 如果我们的请求通过负载平衡被转移到了其他的服务器上, 那么就无法恢复对话
12.2 session ticket
session ticket 是服务器在上一次对话中发送给客户的, 这个 ticket 是加密的, 只有服务器能够解密, 里面包含了本次会话的信息, 比如对话秘钥和加密方法等; 这样不管我们的请求是否转移到其他的服务器上, 当服务器将 ticket 解密以后, 就能够获取上次对话的信息, 就不用重新生成对话秘钥了
13、短轮询、长轮询、长连接和websocket的区别
13.1 短轮询
基本思路
浏览器每隔一段时间向浏览器发送HTTP请求, 服务器在收到请求后不论是否有数据更新都会直接进行响应
这种方式实现的即时通讯, 本质上还是浏览器发送请求, 服务器接受请求的过程, 通过让客户端不断的进行请求, 使得客户端能够模拟实时收到服务器端的数据变化
优点
比较简单, 易于理解
缺点
这种方式需要不断的建立http连接, 严重的浪费服务器端和客户端的资源
当用户增加时, 服务器端的压力就会相当大

var xhr = new XMLHttpRequest();

setInterval(function(){

xhr.open(‘GET’,’/user’);

xhr.onreadystatechange = function(){

};

xhr.send();

},1000)
13.2 长轮询
基本思路
首先由客户端向服务器发起请求, 当服务器收到客户端发来的请求后, 服务器端不会直接进行响应, 而是先将这个请求挂起, 然后判断服务器端数据是否有更新
如果有更新, 则进行响应; 如果一直没有数据, 则到达一定的时间限制才返回; 客户端JavaScript响应处理函数会在处理完服务器返回的信息后, 再次发出请求, 重新建立连接
优点
明显减少了很多不必要的http请求次数, 节约了资源
缺点
连接挂起也会导致资源的浪费

function ajax(){

var xhr = new XMLHttpRequest();

xhr.open(‘GET’,‘/user’);

xhr.onreadystatechange = function(){

ajax();

};

xhr.send();

}
13.3 长连接
概念
SSE是HTML5新增的功能, 全称为Server-Sent Events. 它可以允许服务推送数据到客户端. SSE在本质上就与之前的长轮询、短轮询不同, 虽然都是基于http协议的, 但是轮询需要客户端先发送请求. 而SSE最大的特点就是不需要客户端发送请求, 可以实现只要服务器端数据有更新, 就可以马上发送到客户端
SSE默认支持断线重连, WebSocket则需要额外部署; SSE支持自定义发送的数据类型
优点
不需要建立或保持大量的客户端发往服务器端的请求, 节约了很多资源, 提升应用性能. 并且后面会介绍道, SSE的实现非常简单, 并且不需要依赖其他插件

// 1. 建立连接

if(!!window.EventSource) {

var source = new EventSource(‘http://127.0.0.1/sses/’) // -> 参数url就是服务器网址, 必须与当前网页的网址在同一个网域（domain）, 而且协议和端口都必须相同

// -> 新生成的EventSource实例对象, 有一个readyState属性, 表明连接所处的状态

// -> source.readyState

// -> 0, 相当于常量EventSource.CONNECTING, 表示连接还未建立, 或者连接断线

// -> 1, 相当于常量EventSource.OPEN, 表示连接已经建立, 可以接受数据

// -> 2, 相当于常量EventSource.CLOSED, 表示连接已断, 且不会重连

}

// 2. open事件 - 连接一旦建立, 就会触发open事件, 可以定义相应的回调函数

source.onopen = function(event) {

…

}

source.addEventListener(‘open’, function(event) {

…

}, false)

// 3. message事件 - 收到数据就会触发message事件

source.onmessage = function(event) {

var data = event.data // 服务器端传回的数据（文本格式）

var origin = event.origin // 服务器端URL的域名部分, 即协议、域名和端口

var lastEventId = event.lastEventId // 数据的编号, 由服务器端发送.如果没有编号,这个属性为空

}

source.addEventListener(“message”, function(event) {

var data = event.data

var origin = event.origin

var lastEventId = event.lastEventId

}, false)

// 4. error事件 - 如果发生通信错误（比如连接中断）, 就会触发error事件

source.onerror = function(event) {

…

}

source.addEventListener(“error”, function(event) {

…

}, false)

// 5. close方法 - 用于关闭连接

source.close()
详细描述可见此链接博客地址
13.4 websocket
概念
WebSocket 是一个全双工的协议, 也就是通信双方是平等的, 可以相互发送消息
是HTML5定义的一个新协议, 与传统的http协议不同, 该协议允许由服务器主动向客户端推送信息
缺点
使用 WebSocket 协议的缺点是在服务器端的配置比较复杂
13.5 四种web即时通信技术的比较
兼容性角度
短轮询 > 长轮询 > SSE > websocket
性能方面
websocket > SSE > 长轮询 > 短轮询
14、正向代理和反向代理
正向代理
我们常说的代理也就是指正向代理, 正向代理的过程, 它隐藏了真实的请求客户端, 服务端不知道真实的客户端是谁, 客户端请求的服务都被代理服务器代替来请求
反向代理
这种代理模式下, 它隐藏了真实的服务端, 当我们向一个网站发起请求的时候, 背后可能有成千上万台服务器为我们服务, 具体是哪一台, 我们不清楚, 我们只需要知道反向代理服务器是谁就行, 而且反向代理服务器会帮我们把请求转发到真实的服务器那里去, 一般而言反向代理服务器一般用来实现负载平衡
15、负载平衡的实现方式
反向代理方式
用户的请求都发送到反向代理服务上, 然后由反向代理服务器来转发请求到真实的服务器上, 以此来实现集群的负载平衡
DNS方式
DNS 可以用于在冗余的服务器上实现负载平衡. 因为现在一般的大型网站使用多台服务器提供服务, 因此一个域名可能会对应多个服务器地址. 当用户向网站域名请求的时候, DNS 服务器返回这个域名所对应的服务器 IP 地址的集合, 但在每个回答中, 会循环这些 IP 地址的顺序, 用户一般会选择排在前面的地址发送请求. 以此将用户的请求均衡的分配到各个不同的服务器上, 这样来实现负载均衡. 这种方式有一个缺点就是, 由于 DNS 服务器中存在缓存, 所以有可能一个服务器出现故障后, 域名解析仍然返回的是那个 IP 地址, 就会造成访问的问题