http协议总结
为什么要进行URI编码
1.在传递数据的过程中，如果存在用在分隔符的保留字怎么办？
2.对可能产生歧义性的数据进行编码
1.不再ascii码范围内的字符
2.ascii码中不可显示的字符
3.uri中规定的保留字符
4.不安全字符，空格，引号，尖括号
示例：
https://www.baidu.com/s?wd=?#! 如果不进行编码#后面的后全部截断
https://www.baidu.com/s?wd=中文
https://www.baidu.com/s?wd='>中文
http协议
Http协议，全称是HyperText Tansfer Protocol,中文叫超文本传输协议，是互联网最常见的协议。Http最重要的是www(World Wide Web)服务，也叫web服务器，中文叫“万维网”。
web服务端口默认是80，另外一个加密的www服务应用https默认端口是443，主要用于支付，网银相关业务
http协议版本
http协议诞生以来有若干个版本，主要是http/1.0 http/1.1
http/1.0规定浏览器和服务器只能保持短暂的连接，浏览器的每次请求都需要和服务器建立一个TCP连接，服务器完成请求后即断开TCP连接，服务器不跟踪每个链接，也不记录请求
http/1.1是对HTTP的缺陷进行重点修复，从可扩展性，缓存，带宽优化，持久连接，host头，错误通知等访问改进。
http/1.1支持长连接，增加了更多的请求头和响应头信息，例如配置请求头的Connection的值为keep-alive，表示请求结果返回后保持连接
http请求方法
1 GET 请求指定的页面信息，并返回实体主体。
2 HEAD 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
3 POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
4 PUT 从客户端向服务器传送的数据取代指定的文档的内容。
5 DELETE 请求服务器删除指定的页面。
6 CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
7 OPTIONS 允许客户端查看服务器的性能。
8 TRACE 回显服务器收到的请求，主要用于测试或诊断。
http状态码
HTTp状态码表示web服务器响应http请求状态的数字代码
常见状态码以及作用是
1** 信息，服务器收到请求，需要请求者继续执行操作
2** 成功，操作被成功接收并处理
3** 重定向，需要进一步的操作以完成请求
4** 客户端错误，请求包含语法错误或无法完成请求
5** 服务器错误，服务器在处理请求的过程中发生了错误
http报文
http请求报文
HTTP请求由请求行，请求头部，空行，请求报文主体几个部分组成
请求报文的格式：
起始行： <method> <request-URL> <version>
头部： <headers>
主体： <entity-body>
GET /books/?sex=man&name=Professional HTTP/1.1
Host: www.example.com 主机名
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)Gecko/20050225 Firefox/1.0.1 客户端类型
Accept-Encoding:gzip,deflate 支持压缩
Accept-Language:zh-cn 支持语言类型
Connection: Keep-Alive 长链接
sex=man&name=Professional
请求行:
请求报文第一行，表示客户端想要什么
由请求方法 url 协议版本 组成
请求头:
请求头由
关键字 : 值 组成
通过客户端把请求相关信息告诉服务器
空行
请求头信息之后是一个空行，发送回车和换行符，通知web服务器以下没有请求头信息了
请求体:
请求体中包含了要发送给web服务器的数据信息，请问报文主体不用于get方法，而是用于post方法。
post方法适用于客户端填写表单的场合。
http响应报文
状态行
响应头(Response Header)
响应正文
HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112
<html>...
状态行：
状态行，用来说明服务器响应客户端的状况，一般分为协议版本号，数字状态码，状态情况
响应头部：
常见响应头信息
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Mon, 13 Aug 2018 06:06:54 GMT
Expires: Mon, 13 Aug 2018 06:06:54 GMT
空白行：
通知客户端空行以下没有头部信息了
响应报文主体
主要包含了返回给客户端的数据，可以是文本，二进制（图片，视频）
https
http存在的问题
窃听 - 对称加密
传递密钥 - 非对称加密
安全速度 - 非对称加密+对称加密
中间人攻击 - 证书
证书伪造 - 消息摘要
摘要伪造 - 数字签名
如何解决
在OSI七层模型中，应用层是HTTP协议，在应用层之下就是表示层，也就是TLS协议发挥作用的一层。
TLS协议通过(握手、交换秘钥、告警、加密)等方式做到数据的安全加密。
openssl
Netscape网景公司创建的第一代浏览器，且为了提高浏览器访问网站的安全性，在TCP/IP层的传输层与应用层之间创建了一个SSL(Secure Sockets Layer)，安全套接字层。
SSL是一个库，为了让应用层讲数据传递给传输层之前，调用ssl层的功能，对数据进行加密。
但是SSL(v2 v3)是网景公司定义的，协议不够开放，因此TSL（传输层安全协议）出现了，流行的版本是(TSL v1== SSL v3
ssl密钥协商过程
https完整建立连接的过程
证书的申请颁发过程
证书的有效性链式证明
websocket
目的
即时通讯，替代轮询
网站上的即时通讯是很常见的，比如网页的QQ，聊天系统等。按照以往的技术能力通常是采用轮询、Comet技术解决。
HTTP协议是非持久化的，单向的网络协议，在建立连接后只允许浏览器向服务器发出请求后，服务器才能返回相应的数据。当需要即时通讯时，通过轮询在特定的时间间隔（如1秒），由浏览器向服务器发送Request请求，然后将最新的数据返回给浏览器。这样的方法最明显的缺点就是需要不断的发送请求，而且通常HTTP request的Header是非常长的，为了传输一个很小的数据 需要付出巨大的代价，是很不合算的，占用了很多的宽带。
缺点：会导致过多不必要的请求，浪费流量和服务器资源，每一次请求、应答，都浪费了一定流量在相同的头部信息上
然而WebSocket的出现可以弥补这一缺点。在WebSocket中，只需要服务器和浏览器通过HTTP协议进行一个握手的动作，然后单独建立一条TCP的通信通道进行数据的传送。
原理
WebSocket同HTTP一样也是应用层的协议，但是它是一种双向通信协议，是建立在TCP之上的。
连接过程(握手过程）
1. 浏览器、服务器建立TCP连接，三次握手。这是通信的基础，传输控制层，若失败后续都不执行。
2. TCP连接成功后，浏览器通过HTTP协议向服务器传送WebSocket支持的版本号等信息。（开始前的HTTP握手）
3. 服务器收到客户端的握手请求后，同样采用HTTP协议回馈数据。
4. 当收到了连接成功的消息后，通过TCP通道进行传输通信。
websocket与http的关系
相同点
1. 都是一样基于TCP的，都是可靠性传输协议。
2. 都是应用层协议。
不同点
1. WebSocket是双向通信协议，模拟Socket协议，可以双向发送或接受信息。HTTP是单向的。
2. WebSocket是需要握手进行建立连接的。
websocket与http的关系
WebSocket在建立握手时，数据是通过HTTP传输的。但是建立之后，在真正传输时候是不需要HTTP协议的。
WebSocket与Socket的关系
Socket其实并不是一个协议，而是为了方便使用TCP或UDP而抽象出来的一层，是位于应用层和传输控制层之间的一组接口。
当两台主机通信时，必须通过Socket连接，Socket则利用TCP/IP协议建立TCP连接。TCP连接则更依靠于底层的IP协议，IP协议的连接则依赖于链路层等更低层次。
WebSocket则是一个典型的应用层协议。
区别
Socket是传输控制层协议，WebSocket是应用层协议。
websocket机制
传统 HTTP 请求响应客户端服务器交互图
websocket 请求响应客户端服务器交互图
相对于传统 HTTP 每次请求-应答都需要客户端与服务端建立连接的模式，WebSocket 是类似 Socket 的 TCP 长连接的通讯模式，一旦 WebSocket 连接建立后，后续数据都以帧序列的形式传输。在客户端断开 WebSocket 连接或 Server 端断掉连接前，不需要客户端和服务端重新发起连接请求。在海量并发及客户端与服务器交互负载流量大的情况下，极大的节省了网络带宽资源的消耗，有明显的性能优势，且客户端发送和接受消息是在同一个持久连接上发起，实时性优势明显。
websocket握手过程
客户端连接报文
GET /webfin/websocket/ HTTP/1.1
Host: localhost
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: xqBt3ImNzJbYqRINxEFlkg==
Origin:
http://localhost
:8080
Sec-WebSocket-Version: 13
Connection: Upgrade：表示要升级协议
Upgrade: websocket：表示要升级到websocket协议
Sec-WebSocket-Version: 13：表示websocket的版本
Sec-WebSocket-Key：与后面服务端响应首部的Sec-WebSocket-Accept是配套的，提供基本的防护，比如恶意的连接，或者无意的连接。
WebSocket 服务端响应报文
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: K7DJLdLooIwIG/MOpvWFB3y3FE8=
Sec-WebSocket-Key/Accept的作用
避免服务端收到非法的websocket连接
确保服务端理解websocket连接
用浏览器里发起ajax请求，设置header时，Sec-WebSocket-Key以及其他相关的header是被禁止的
Sec-WebSocket-Key主要目的并不是确保数据的安全性，因为Sec-WebSocket-Key、Sec-WebSocket-Accept的转换计算公式是公开的，而且非常简单，最主要的作用是预防一些常见的意外情况（非故意的）
Sec-WebSocket-Accept的计算
Sec-WebSocket-Accept根据客户端请求首部的Sec-WebSocket-Key计算出来。 计算公式为：
将Sec-WebSocket-Key跟258EAFA5-E914-47DA-95CA-C5AB0DC85B11拼接。
通过SHA1计算出摘要，并转成base64字符串
1.value = headers['Sec-WebSocket-Key'] + magic_string
拿到客户端发送的key,拼接magicstring
2.ac = base64.b64encode(hashlib.sha1(value.encode('utf-8')).digest())
进行sha1,base64加密
3."Sec-WebSocket-Accept: ac
将加密结果返回
import socket, base64, hashlib
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind(('127.0.0.1', 9527))
sock.listen(5)
# 获取客户端socket对象
conn, address = sock.accept()
# 获取客户端的【握手】信息
data = conn.recv(1024)
print(data)
"""
b'GET /ws HTTP/1.1\r\n
Host: 127.0.0.1:9527\r\n
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2\r\n
Accept-Encoding: gzip, deflate\r\n
Sec-WebSocket-Version: 13\r\n
Origin: http://localhost:63342\r\n
Sec-WebSocket-Extensions: permessage-deflate\r\n
Sec-WebSocket-Key: jocLOLLq1BQWp0aZgEWL5A==\r\n
Cookie: session=6f2bab18-2dc4-426a-8f06-de22909b967b\r\n
Connection: keep-alive, Upgrade\r\n
Pragma: no-cache\r\n
Cache-Control: no-cache\r\n
Upgrade: websocket\r\n\r\n'
"""
# magic string为：258EAFA5-E914-47DA-95CA-C5AB0DC85B11
magic_string = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11'
def get_headers(data):
header_dict = {}
header_str = data.decode("utf8")
for i in header_str.split("\r\n"):
if str(i).startswith("Sec-WebSocket-Key"):
header_dict["Sec-WebSocket-Key"] = i.split(":")[1].strip()
return header_dict
def get_header(data):
"""
将请求头格式化成字典
:param data:
:return:
"""
header_dict = {}
data = str(data, encoding='utf-8')
header, body = data.split('\r\n\r\n', 1)
header_list = header.split('\r\n')
for i in range(0, len(header_list)):
if i == 0:
if len(header_list[i].split(' ')) == 3:
header_dict['method'], header_dict['url'], header_dict['protocol'] = header_list[i].split(' ')
else:
k, v = header_list[i].split(':', 1)
header_dict[k] = v.strip()
return header_dict
headers = get_headers(data) # 提取请求头信息
# 对请求头中的sec-websocket-key进行加密
response_tpl = "HTTP/1.1 101 Switching Protocols\r\n" \
"Upgrade:websocket\r\n" \
"Connection: Upgrade\r\n" \
"Sec-WebSocket-Accept: %s\r\n" \
"WebSocket-Location: ws://127.0.0.1:9527\r\n\r\n"
value = headers['Sec-WebSocket-Key'] + magic_string
print(value)
ac = base64.b64encode(hashlib.sha1(value.encode('utf-8')).digest())
response_str = response_tpl % (ac.decode('utf-8'))
# 响应【握手】信息
conn.send(response_str.encode("utf8"))
while True:
msg = conn.recv(8096)
print(msg)
websocket加密
import struct
msg_bytes = "hello".encode("utf8")
token = b"\x81"
length = len(msg_bytes)
if length < 126:
token += struct.pack("B", length)
elif length <= 0xFFFF:
token += struct.pack("!BH", 126, length)
else:
token += struct.pack("!BQ", 127, length)
msg = token + msg_bytes
print(msg)
websocket数据帧格式
WebSocket客户端、服务端通信的最小单位是帧，由1个或多个帧组成一条完整的消息（message）。
发送端：将消息切割成多个帧，并发送给服务端
接收端：接收消息帧，并将关联的帧重新组装成完整的消息
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/64) |
|N|V|V|V| |S| | (if payload len==126/127) |
| |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 |
+ - - - - - - - - - - - - - - - +-------------------------------+
| |Masking-key, if MASK set to 1 |
+-------------------------------+-------------------------------+
| Masking-key (continued) | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - - +
: Payload Data continued ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+
http安全问题
xss攻击
1.黑客往网页里注入恶意脚本代码
2.当用户访问时获取到包含恶意代码的网页
3.通过恶意脚本，黑客可以获取和控制用户信息
反射型(非持久型)XSS
诱导用户点击恶意链接来造成一次性攻击
1.黑客把带有恶意脚本代码参数的URL地址发送给用户
2.用户点击此链接
3.服务器端获取请求参数并且直接使用，服务器反射回结果页面
4.反射型XSS攻击是一次性的，必须要通过用户点击链接才能发起
5.一些浏览器如Chrome其内置了一些XSS过滤器，可以防止大部分反射型XSS攻击
6.反射型XSS其实就是服务器没有对恶意的用户输入进行安全处理就直接反射响应内容，导致恶意代码在浏览器中执行的一种XSS漏洞
const express = require('express');
存储型(持久型)XSS
黑客将代码存储到漏洞服务器中，用户浏览相关页面发起攻击
1.黑客将恶意脚本代码上传或存储到漏洞服务器
2.服务器把恶意脚本保存到服务器
3.当正常客户访问服务器时，服务器会读取恶意数据并且直接使用
4.服务器会返回含有恶意脚本的页面
DOM-Based型XSS
不需要服务器端支持，是由于DOM结构修改导致的，基于浏览器DOM解析的攻击
1.用户打开带有恶意的链接
2.浏览器在DOM解析的时候直接使用恶意数据
3.用户中招
4.常见的触发场景就是在修改innerHTML outerHTML document.write的时候
xss攻击对比
| 类型 | 反射型 | 存储型 |
|---|---|---|
| 持久性 | 非持久 | 持久化(存储在服务器) |
| 触发时机 | 需要用户点击 | 不需要用户交互也可以触发 |
| 危害 | 危害较小 | 危害更大 |
xss防御
1.对字符进行编码
function htmlEncode(str) {
return String(str)
.replace(/&/g, '&')
.replace(/"/g, '"')
.replace(/'/g, ''')
.replace(/</g, '<')
.replace(/>/g, '>');
}
2.对js进行编码转译
//使用“\”对特殊字符进行转义，除数字字母之外，小于127使用16进制“\xHH”的方式进行编码，大于用unicode（非常严格模式）。
var JavaScriptEncode = function (str) {
var hex = new Array('0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f');
function changeTo16Hex(charCode) {
return "\\x" + charCode.charCodeAt(0).toString(16);
}
function encodeCharx(original) {
var found = true;
var thecharchar = original.charAt(0);
var thechar = original.charCodeAt(0);
switch (thecharchar) {
case '\n': return "\\n"; break; //newline
case '\r': return "\\r"; break; //Carriage return
case '\'': return "\\'"; break;
case '"': return "\\\""; break;
case '\&': return "\\&"; break;
case '\\': return "\\\\"; break;
case '\t': return "\\t"; break;
case '\b': return "\\b"; break;
case '\f': return "\\f"; break;
case '/': return "\\x2F"; break;
case '<': return "\\x3C"; break;
case '>': return "\\x3E"; break;
default:
found = false;
break;
}
if (!found) {
if (thechar > 47 && thechar < 58) { //数字
return original;
}
if (thechar > 64 && thechar < 91) { //大写字母
return original;
}
if (thechar > 96 && thechar < 123) { //小写字母
return original;
}
if (thechar > 127) { //大于127用unicode
var c = thechar;
var a4 = c % 16;
c = Math.floor(c / 16);
var a3 = c % 16;
c = Math.floor(c / 16);
var a2 = c % 16;
c = Math.floor(c / 16);
var a1 = c % 16;
return "\\u" + hex[a1] + hex[a2] + hex[a3] + hex[a4] + "";
}
else {
return changeTo16Hex(original);
}
}
}
csrf
Cross Site Request Forgery 跨站请求伪造
1.用户A登录银行网站，登录成功后会设置cookie
2.黑客诱导用户A登录到黑客的站点，然后会返回一个页面
3.用户访问这个页面时，这个页面会伪造一个转账请求到银行网站
防御
1.用户不知情 验证码 影响用户体验
2.跨站请求 使用refer验证 不可靠
3.参数伪造 token 最主流的防御CSRF
DDOS攻击
分布式拒绝服务(Distribute Denial Of Service)
黑客控制大量的肉鸡向受害主机发送非正常请求，导致目标主机耗尽资源不能为合法用户提供服务
验证码是我们在互联网十分常见的技术之一。不得不说验证码是能够有效地防止多次重复请求的行为。
限制请求频率是我们最常见的针对 DDOS 攻击的防御措施。其原理为设置每个客户端的请求频率的限制
增加机器增加服务带宽。只要超过了攻击流量便可以避免服务瘫痪
设置自己的业务为分布式服务，防止单点失效
使用主流云系统和 CDN（云和 CDN 其自身有 DDOS 的防范作用）
优化资源使用提高 web server 的负载能力
HTTP劫持
在用户的客户端与其要访问的服务器经过网络协议协调后，二者之间建立了一条专用的数据通道，用户端程序在系统中开放指定网络端口用于接收数据报文，服务器端将全部数据按指定网络协议规则进行分解打包，形成连续数据报文。
用户端接收到全部报文后，按照协议标准来解包组合获得完整的网络数据。其中传输过程中的每一个数据包都有特定的标签，表示其来源、携带的数据属性以及要到何处，所有的数据包经过网络路径中ISP的路由器传输接力后，最终到达目的地，也就是客户端。
HTTP劫持是在使用者与其目的网络服务所建立的专用数据通道中，监视特定数据信息，提示当满足设定的条件时，就会在正常的数据流中插入精心设计的网络数据报文，目的是让用户端程序解释“错误”的数据，并以弹出新窗口的形式在使用者界面展示宣传性广告或者直接显示某网站的内容。
http缓存机制
Web 缓存大致可以分为：数据库缓存、服务器端缓存（代理服务器缓存、CDN 缓存）、浏览器缓存。
浏览器缓存也包含很多内容： HTTP 缓存、indexDB、cookie、localstorage 等等。这里我们只讨论 HTTP 缓存相关内容。
在具体了解 HTTP 缓存之前先来明确几个术语：
缓存命中率：从缓存中得到数据的请求数与所有请求数的比率。理想状态是越高越好。
过期内容：超过设置的有效时间，被标记为“陈旧”的内容。通常过期内容不能用于回复客户端的请求，必须重新向源服务器请求新的内容或者验证缓存的内容是否仍然准备。
验证：验证缓存中的过期内容是否仍然有效，验证通过的话刷新过期时间。
失效：失效就是把内容从缓存中移除。当内容发生改变时就必须移除失效的内容。
浏览器缓存主要是 HTTP 协议定义的缓存机制。HTML meta 标签，例如
<META HTTP-EQUIV="Pragma" CONTENT="no-store">
含义是让浏览器不缓存当前页面。但是代理服务器不解析 HTML 内容，一般应用广泛的是用 HTTP 头信息控制缓存。
浏览器缓存分类
浏览器缓存分为强缓存和协商缓存，浏览器加载一个页面的简单流程如下：
1.浏览器先根据这个资源的http头信息来判断是否命中强缓存。如果命中则直接加在缓存中的资源，并不会将请求发送到服务器。
2.如果未命中强缓存，则浏览器会将资源加载请求发送到服务器。服务器来判断浏览器本地缓存是否失效。若可以使用，则服务器并不会返回资源信息，浏览器继续从缓存加载资源。
3.如果未命中协商缓存，则服务器会将完整的资源返回给浏览器，浏览器加载新资源，并更新缓存。
强缓存
命中强缓存时，浏览器并不会将请求发送给服务器。在Chrome的开发者工具中看到http的返回码是200，但是在Size列会显示为(from cache)。
强缓存是利用http的返回头中的Expires或者Cache-Control两个字段来控制的，用来表示资源的缓存时间。
Expires
缓存过期时间，用来指定资源到期的时间，是服务器端的具体的时间点。也就是说，Expires=max-age + 请求时间，需要和Last-modified结合使用。但在上面我们提到过，cache-control的优先级更高。 Expires是Web服务器响应消息头字段，在响应http请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据，而无需再次请求。
该字段会返回一个时间，比如Expires:Thu,31 Dec 2037 23:59:59 GMT。这个时间代表着这个资源的失效时间，也就是说在2037年12月31日23点59分59秒之前都是有效的，即命中缓存。这种方式有一个明显的缺点，由于失效时间是一个绝对时间，所以当客户端本地时间被修改以后，服务器与客户端时间偏差变大以后，就会导致缓存混乱。于是发展出了Cache-Control。
Cache-Control
Cache-Control是一个相对时间，例如Cache-Control:3600，代表着资源的有效期是3600秒。由于是相对时间，并且都是与客户端时间比较，所以服务器与客户端时间偏差也不会导致问题。
Cache-Control与Expires可以在服务端配置同时启用或者启用任意一个，同时启用的时候Cache-Control优先级高。
Cache-Control 可以由多个字段组合而成，主要有以下几个取值：
1. max-age 指定一个时间长度，在这个时间段内缓存是有效的，单位是s。例如设置 Cache-Control:max-age=31536000，也就是说缓存有效期为（31536000 / 24 / 60 * 60）天，第一次访问这个资源的时候，服务器端也返回了 Expires 字段，并且过期时间是一年后。
在没有禁用缓存并且没有超过有效时间的情况下，再次访问这个资源就命中了缓存，不会向服务器请求资源而是直接从浏览器缓存中取。
2. s-maxage 同 max-age，覆盖 max-age、Expires，但仅适用于共享缓存，在私有缓存中被忽略。
3. public 表明响应可以被任何对象（发送请求的客户端、代理服务器等等）缓存。
4. private 表明响应只能被单个用户（可能是操作系统用户、浏览器用户）缓存，是非共享的，不能被代理服务器缓存。
5. no-cache 强制所有缓存了该响应的用户，在使用已缓存的数据前，发送带验证器的请求到服务器。不是字面意思上的不缓存。
6. no-store 禁止缓存，每次请求都要向服务器重新获取数据。
7、must-revalidate指定如果页面是过期的，则去服务器进行获取。这个指令并不常用，就不做过多的讨论了。
协商缓存
若未命中强缓存，则浏览器会将请求发送至服务器。服务器根据http头信息中的Last-Modify/If-Modify-Since或Etag/If-None-Match来判断是否命中协商缓存。如果命中，则http返回码为304，浏览器从缓存中加载资源。
Last-Modify/If-Modify-Since
浏览器第一次请求一个资源的时候，服务器返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间，例如Last-Modify: Thu,31 Dec 2037 23:59:59 GMT。
当浏览器再次请求该资源时，发送的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存。
如果命中缓存，则返回http304，并且不会返回资源内容，并且不会返回Last-Modify。由于对比的服务端时间，所以客户端与服务端时间差距不会导致问题。但是有时候通过最后修改时间来判断资源是否修改还是不太准确（资源变化了最后修改时间也可以一致）。于是出现了ETag/If-None-Match。
ETag/If-None-Match
与Last-Modify/If-Modify-Since不同的是，Etag/If-None-Match返回的是一个校验码（ETag: entity tag）。ETag可以保证每一个资源是唯一的，资源变化都会导致ETag变化*。ETag值的变更则说明资源状态已经被修改。服务器根据浏览器上发送的If-None-Match值来判断是否命中缓存。
ETag扩展说明
我们对ETag寄予厚望，希望它对于每一个url生成唯一的值，资源变化时ETag也发生变化。神秘的Etag是如何生成的呢？以Apache为例，ETag生成靠以下几种因子
文件的i-node编号，此i-node非彼iNode。是Linux/Unix用来识别文件的编号。是的，识别文件用的不是文件名。使用命令’ls –I’可以看到。
文件最后修改时间
文件大小
生成Etag的时候，可以使用其中一种或几种因子，使用抗碰撞散列函数来生成。所以，理论上ETag也是会重复的，只是概率小到可以忽略。
既生Last-Modified何生Etag？
你可能会觉得使用Last-Modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要Etag（实体标识）呢？HTTP1.1中Etag的出现主要是为了解决几个Last-Modified比较难解决的问题：
1. Last-Modified标注的最后修改只能精确到秒级，如果某些文件在1秒钟以内，被修改多次的话，它将不能准确标注文件的修改时间
2. 如果某些文件会被定期生成，当有时内容并没有任何变化，但Last-Modified却改变了，导致文件没法使用缓存
3.有可能存在服务器没有准确获取文件修改时间，或者与代理服务器时间不一致等情形
Etag是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符，能够更加准确的控制缓存。Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304。
浏览器缓存与用户行为有关
| 用户操作 | Expires/Cache-Control | Last-Modified/Etag |
|---|---|---|
| 地址栏回车 | 有效 | 有效 |
| 页面链接跳转 | 有效 | 有效 |
| 新开窗口 | 有效 | 有效 |
| 前进、后退 | 有效 | 有效 |
| F5刷新 | 无效 | 有效 |
| Ctrl+F5刷新 | 无效 | 无效 |
浏览器第一次请求
浏览器再次请求
http持久连接和管线化节省通信量
持久连接(keep-alive)模式
HTTP1.1规定了默认保持长连接（HTTP persistent connection ，也有翻译为持久连接）;数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。
HTTP 1.1版本支持持久连接 1.0版本不支持
与非持久连接的区别：
持久连接使客户端到服务器端连接持续有效，避免了重新建立连接
大大减少了连接的建立以及关闭时延。HTTP连接是建立在TCP协议之上的，建立一条TCP连接需要三次握手，TCP连接关闭时需要四次挥手。这些都是需要时间的
管线化
管线化机制须通过永久连接（persistent connection）完成，仅HTTP/1.1支持此技术（HTTP/1.0不支持）
在使用持久连接的情况下，某个连接消息的传递类似于
请求1 -> 响应1 -> 请求2 -> 响应2
管线化：某个连接上的消息变成了类似这样
请求1 -> 请求2 -> 请求3 -> 响应1 -> 响应2 -> 响应3
持久连接与管线化的区别
1. 那么持久连接和管线化的区别在于：
持久连接的一个缺点是请求和响应式是顺序执行的，只有在请求1的响应收到之后，才会发送请求2，而管线化不需要等待上一次请求得到响应就可以进行下一次请求。实现并行发送请求。
2. 只有GET和HEAD要求可以进行管线化，而POST则有所限制
3. 初次创建连接时也不应启动管线机制，因为对方（服务器）不一定支持HTTP/1.1版本的协议。
4.HTTP1.1要求服务器端支持管线化，但并不要求服务器端也对响应进行管线化处理，只是要求对于管线化的请求不失败，而且现在很多服务器端和代理程序对管线化的支持并不好，现代浏览器Chrome和Firefox默认并未开启管线化支持。
浙公网安备 33010602011771号