HTTP,HTTPS,HTTP2笔记

时间 2019-11-10

原文原文链接

HTTP

网络协议分层

应用层      -> HTTP FTP 为应用软件提供了不少服务 构建于TCP协议之上 屏蔽网络传输的相关细节 传输层 -> TCP UDP 向用户提供可靠的端对端的服务(end to end) (数据量过大，会分包发送) 网络层 -> 为数据节点之间传输建立逻辑链路 数据链路层 -> 物理链接完成后，须要经过软件进行链接 物理层 -> 网线，光纤等传输硬件设备

TCP/IP协议

计算机与网络设备相互通讯，双方就必须基于相同的方法,不管是语言之间的通信，设备，硬件，操做系统的通信，怎么开始，怎么发起，怎么结束，都须要一种规则。我这种规则被称为协议。例如：TCP、FTP、HTTP、DNS、ICMP、IP、UDP......javascript

IP协议

IP协议位于网络层，指的是网际协议。做用是把各类数据包传送给对方。而要保证确实传送到对方那里。(须要两个重要的条件1:IP地址 2:MAC地址)css

TCP协议

TCP协议位于传输层，提供可靠的字节流服务。所谓字节流:指的是把大数据分割成以报文字段为单位的数据包进行管理。而且将数据准确可靠的传给对方。html

工做原理: 1.输入url地址，按回车 2.发生跳转(redirect)[可能有301的状况，纯客户端行为] 3.判断是否已经缓存过，缓存是否过时等 4.DNS域名解析，把解析完的地址返回给客户端 5.浏览器建立TCP连接，三次握手 6.http生成目标web请求报文 6.1 若是有代理服务器，会先通过代理服务器，也会判断缓存状况 7.通过各类路由器[能够经过抓包工具了解通过了哪些路由器] 8.服务器拿到报文信息，并把请求结果，也利用TCP通信协议按照原路返回给客户端 9.客户端拿到服务器的http响应报文后，使用了gzip或其余压缩算法，拿到指望的HTML代码 10.在浏览器接收完整HTML文件前，浏览器就开始渲染页面了(浏览器将HTML字节数据通过一个流程解析为DOM树) - 字节->字符->令牌->节点对象->对象模型 11.当HTML代码遇到<link>标签时，浏览器会发送请求得到该标签中标记的CSS文件。 使人欣喜的是，这是一个异步请求，不影响其余操做，浏览器得到数据后就会像构建DOM树同样构建CSSOM树。

统一资源标志

URL Uniform Resource Identifier /统一资源标志符 用来惟一标识互联网上的信息资源 包含了URL URN URL Uniform Resource Locator /统一资源定位器 旧版 http://user:pass@host.com:80/path?query=string#hash 默认端口号:80 URN 永久统一资源定位符

三次握手

第一次握手：创建链接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。前端

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时本身也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；java

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP链接成功）状态，完成三次握手。node

三次握手的目的:为了防止已失效的链接请求报文段忽然又传送到了服务端，于是产生错误

关闭链接要四次挥手

第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。nginx

第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。web

第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。算法

第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。apache

P:由于服务端在LISTEN状态下，收到创建链接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭链接时，当收到对方的FIN报文时，仅仅表示对方再也不发送数据了可是还能接收数据，己方也未必所有数据都发送给对方了，因此己方能够当即close，也能够发送一些数据给对方后，再发送FIN报文给对方来表示赞成如今关闭链接，所以，己方ACK和FIN通常都会分开发送。(因此是四次挥手)

DNS域名解析

DNS(Domain Name System)位于应用层

DNS服务是和HTTP协议同样位于应用层的协议，它提供域名到IP地址之间的解析服务。计算机擅长处理IP地址这样长数字形式的内容，但却不符合人类的记忆习惯，因此用户会借助域名（www.baidu.com）和端口号等来记忆。

但域名却难以理解这样的一串字符串，所以，DNS协议就营运而生，用于解析域名，经过域名查找IP地址，也能够逆向从IP地址查找域名

同源策略

同源策略(Same origin policy)是一种约定，它是浏览器最核心也最基本的安全功能，若是缺乏了同源策略，则浏览器的正常功能可能会受到影响，能够说web是构建在同源策略基础上的，浏览器只是针对同源策略的一种实现。

他的核心在于它认为自任何站点装载的信赖内容都不安全的，当被浏览器半信半疑的脚本运行的沙箱时，他们应该只被容许访问来自统一站点的资源，而不是那些来自其余站点可能不怀好意的资源

所谓同源: 域名相同，协议相同，端口相同

另外，同源策略又分为如下两种

1.DOM同源策略：禁止对不一样源页面DOM进行操做，这里主要场景是iframe跨域的状况，不一样域名的iframe是限制相互访问的

2.XMLHttpRequest同源策略：禁止使用XHR对象向不一样源的服务器发起http请求

若是出现了域名不一样，协议不一样，端口不一样，就会受到同源策略的限制，产生跨域的问题。

同源策略的目的是保证用户信息安全，防止恶意的网站窃取数据，防止其余网站在访问的时候获取其余网站留下的cookie信息。

限制范围：

Cookie ,localStorage 和indexDB 没法读取
DOM没法获取（iframe 已经废弃）
AJAX请求不能发送

所谓同源:必需要域名相同,端口相同,域名相同,才能访问,不然出现跨域问题。限制访问（什么事同源策略）
同源的目的是为了保护用户的隐私安全，防止黑客的入侵（固然高级黑客仍是会有办法的）（有什么用）
同源策略是浏览器最基础，最核心的安全功能。（为何）
同源策略能限制cookie，localStorage和indexDB的获取，DOM的获取，和AJAx发起的http请求（具体做用）
在web开发中，先后端分离，通常是前端一个访问端口，后台一个访问端口，就会产生跨域问题（产生什么问题）
在html标签中，img的src，link标签，a标签，和scrip标签无视同源策略。能够经过标签进行跨域访问>。(JSONP方法)(如何解决(其中一个方法))

解决跨域请求

CORS(使用最多)

Cross-Origin Resource Sharing（CORS）跨域资源共享是一份浏览器技术的规范，提供了 Web 服务从不一样域传来沙盒脚本的方法，以避开浏览器的同源策略，确保安全的跨域数据传输。现代浏览器使用CORS在API容器如XMLHttpRequest来减小HTTP请求的风险来源。与 JSONP 不一样，CORS 除了 GET 要求方法之外也支持其余的 HTTP 要求。服务器通常须要增长以下响应头的一种或几种： Access-Control-Allow-Origin: *//(不安全)容许跨域的端口(url)，或者是一个接口 Access-Control-Allow-Methods: POST, GET, OPTIONS//容许跨域的方式 Access-Control-Allow-Headers: X-PINGOTHER, Content-Type //容许跨域的请求头，能够自定 Access-Control-Max-Age: 86400 //容许在一千秒内发起正式，不用发起预请求

JSONP(相对较多,只适用GET请求)

jsonp的原理就是，在客户端和服务端定义一个函数，当客户端发起一个请求时，服务端返回一段javascript代码，其中调用了在客户端定义的函数，并将相应的数据做为参数传入该函数。须要先后端协商函数。

代理(最热门)

代理与反向代理 同源策略是针对浏览器端进行的限制，能够经过服务器端来解决该问题 浏览器--访问(发出请求)--->代理服务器---（代请求）---> 服务器 Nginx,node中间件等

跨域技术不只仅是有这几种，还有图片ping方法！(一样利用了标签的src不受同源策略影响)、websocket(浏览器与服务器全双工通讯，同时容许跨域通信) 、window.postMessage()等等。（自行百度！）

通信转发代理/网关/隧道

代理

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

特色：代理不改变请求的URL，会直接发送给前方持有资源的目标服务器(源服务器)。在HTTP通讯中，可级联多台代理服务器(即请求和响应都通过数台相似锁链同样链接的代理服务器)，转发时，须要附加Via首部字段以标记出通过的主机信息。

缓存代理：会预先将资源的副本(缓存)保存在代理服务器上，当下次再接受到一样的请求时，就能够不须要从源服务器上获取资源，而是在代理服务器上直接返回资源

透明代理：转发请求或响应时，不对报文作任何加工的代理类型，叫作透明代理，反之叫非透明代理...

隧道

目的：隧道的目的是为了确保客户端能与服务器进行安全的通讯

可按要求创建起来一条与其余服务器的通信线路,届时使用SSL等加密手段进行通信.确保安全性.隧道自己不会去解析HTTP请求。也就是说，隧道只是用来中转HTTP请求，当通信双方断开链接是结束

网关

网关的工做机制和代理十分类似，而网关能使通信线路上的服务器提供非HTTP协议服务。利用网关能提升通讯的安全性。由于能够在客户端与网关之间的通信路上加密以确保连接的安全

HTTP报文

报文首部

报文首部字段是构成HTTP报文的要素之一。

使用首部字段是为了给浏览器和服务器提供报文主体大小，所使用的语言，认证信息等内容。

通用首部字段

请求报文和响应报文双方都要使用的首部！

通用首部字段名	说明
Cache-Control	控制缓存的行为
Connection	控制不在转发给代理的首部字段、管理持久连接
Date	建立报文的日期和时间
Pragma	仅做为HTTP/1.0的向后兼容被定义
Trailer	报文主体后加的首部字段，可用在分块编码时
Transfer-Encoding	指定报文主体的传输编码格式
Upgrade	检测协议是否可以使用更高版本，（在使用该字段时要额外添加 Connection：Upgrade字段）
Via	追踪客户端和服务器以前请求和响应的传输路径，（全部代理服务器的信息）
Warning	各类错误警告

响应首部字段(Response Headers)

从服务器端向客户端返回响应报文时使用的首部，补充了响应的附加内容，也会要求客户端附加的内容信息

响应首部字段名	说明
Accept-Range	用来告知客户端服务器是否能处理范围请求，能够指定为betys，反之指定为none
Age	返回资源建立到此次请求所通过的时间，单位为s
ETage	服务器将资源以字符串的形式做惟一标识ETage
Location	告知服务器用户代理可以处理的天然语言以及天然语言的优先级
Authorization	用来告知服务器用户代理的认证信息（属客户端与代理之间的通讯）
Retry-After	告知客户端多久以后再次访问
Server	告知客户端当前服务器安装的HTTP服务器应用程序的信息
Vary	代理服务器须要缓存的管理信息
WWW-Authenticate	服务器对对客户端的认证信息

请求首部字段(Request Headers)

从客户端向服务器发送请求报文时使用的首部！补充了请求的附加内容，客户端信息，响应内容的相关优先级等信息。

请求首部字段名	说明
Accept	通知服务器用户代理可处理的媒体类型以及优先级
Accept-Charset	通知服务器用户代理支持的字符集以及字符集的优先顺序
Accept-Encoding	告知服务器用户代理支持的内容编码以及内容编码的优先顺序
Accept-Language	告知服务器用户代理可以处理的天然语言以及天然语言的优先级
Authorization	用来告知服务器用户代理的认证信息
Expet	期待服务器出现某种待定行为
From	告知服务器用户代理的电子邮箱地址
Host	请求资源所处计算机的主机名和端口号
If-Match	告知服务器匹配资源所用的实体标记值
If-Modified-Sincest	告知服务器字段值时间以后有更新资源，则获取
If-None-Match	和If-Match相反
If-Range	资源未更新时发送实体Bety的范围请求
If-Unmodified-Since	告知服务器字段之间以后未更新资源，则获取
Max-Forwards	以十进制的形式指定可通过的服务器的最大数目
Proxy-Authorization	代理服务器要求客户端的认证信息
Pange	只须要获取部分资源的请求告知服务器的资源指定范围
Referer	告知服务器请求的原始资源的URI
TE	告知服务器客户端能处理的编码格式以及相对优先级
User-Agent	Http客户端的信息，若是请求通过代理也可能会添加代理服务器的信息

注:形如If-xxx这样的请求字段称为条件请求，服务器通常接收到附带条件请求的URL，只有判断条件成立后才会执行请求

实体首部字段

针对请求报文和响应报文的实体部分使用的首部。补充了资源内容，更新时间等与实体相关的信息。

实体首部字段名	说明
Allow	通知客户端能支持的HTTP的全部方法
Content-Encoding	通知客户端服务器对实体的主体的编码方式
Content-Language	通知客户端实体主体的天然语言
Content-Length	实体主体的大小
Content-Location	表示报文返回资源的原始URI
Content-MD5	客户端对接收到的报文主体执行相同的MD5算法，而后与字段中的值进行比较。（目的检测传输过程实体主体是否保持完整）
Content-Range	实体主体返回的是资源的那部分位置范围
Content-Type	实体主体的媒体类型
Expires	告知客户端资源的有效截止日期
Last-Modified	告知客户端资源的最后修改日期

其余首部字段

自行扩展的，非标转的首部字段

其余首部字段名	说明
X-Frame-Options	控制网站内容在其余web上用frame标签内显示的问题，主要防止点击劫持攻击
X-XSS-Protection	针对跨脚本攻击的一种对策，用于控制浏览器XSS防御机制的开关（0 无效 1 有效）
DNT	拒绝我的信息被收集，表示拒绝被精准广告追踪的一种方法，（0 赞成 1 拒绝）
P3P	在线隐私偏好系统

 
1. 处理预请求
 'Access-Control-Allow-Headers':'X-Test-Cors'//容许跨域的请求头，能够自定义
 'Access-Control-Allow-Methods': 'POST, PUT, Delete'//容许跨域的方式
 'Access-Control-Max-Age': '1000' //容许在一千秒内发起正式，不用发起预请求
2. CORS带Cookie的跨域请求
 Access-Control-Allow-Origin:'*'
 //当设置为*的时候，容许任何地方的跨域请求，但当带有Cookie的时候，则报错，并且，也至关不安全。
 //所以，须要设置成指定的要访问的域。
    1.判断接口是否带cookie，若是带cookie，则获取请求头部的origin的值(即访问的域)
    而且加上“Access-Control-Allow-Credentials":"true"
3. Content-Type //传输的数据类型 (很重要)
        text/plain     
        multipart/form-data
        application/x-www-form-urlencoded

4. 可缓存
    public (任何地方)
    private（发起请求的地方）
    no-cache（验证后是否使用本地缓存才能缓存）

5. 到期时间
    max-age=100 （缓存时间）
    s-maxage=100 (缓存时间[在代理服务器上用])
    max-stale=1000 （即便过去，也还能用，在规定时间范围内）       

6. 从新验证
    must-revalidate （在过时后，在服务端发送请求，从新获取数据验证是否真的过时）
    proxy-revalidate (在缓存服务器上使用)   

7. 其余
    no-store (不用验证，不能缓存，每次都要拿新的内容)
    no-transform (告诉代理服务器 不容许改动内容)

8. 资源验证
    配合if-Match或者if-Non-Match使用对比资源的签名判断是否使用缓存
    //第一个修改信息时，把修改的内容发送到服务器，第二次请求的时候，会返回第一次的数值，而后跟如今的数值对比，若是有不同，证实修改了，须要从后台拿数据

HTTP状态码

状态码的职责是当客户端向服务器发送请求时，描述返回的请求结果，借助状态码，能够知道服务器端是正常处理了请求，仍是出现错误

状态码类别

code	类别	缘由短语
1XX	Informational(信息性状态码)	接收的请求正在处理
2XX	Success(成功状态码)	请求正常处理完毕
3XX	Redirection(重定向状态码)	须要进行附加操做以完成请求
4XX	Client Error(客户端错误状态码)	服务器没法处理请求
5XX	Server Error(服务器错误状态码)	服务器处理请求出错

http状态码多达六十多种，但实际使用大概只有十四种左右

2XX

code	缘由短语
200	请求成功
204	请求成功，但无资源返回
206	请求成功，只是请求部分资源

3XX 重定向

code	缘由短语
301	永久性重定向资源地址更新，须要进行变动，（主要做用在书签页）
302	临时性重定向资源地址更新，须要进行变动，（主要做用在书签页）
303	临时性重定向使用get 方法获取资源
304	资源找到了，但不符合条件请求，意思是:内容还没更新，先使用客户端内缓存的内容(非重定向)
404	服务器没有找到该资源

4XX

code	缘由短语
400	没法理解请求的内容(报文语法错误)
401	须要经过HTTP认证
403	被服务器拒绝访问内容
404	资源找到了，但不符合条件请求，意思是:内容还没更新，先使用客户端内缓存的内容(非重定向)

5XX

code	缘由短语
500	服务器内部出现故障
503	服务器正忙(处于暂时超负载或者停机维护等，没法处理请求)

为Cookie服务的首部字段

是目前使用最普遍的Cookie标准，却不是RFC中定义的任何一个

首部字段名	说明	首部类型
Set-Cookie	开始状态管理所使用的Cookie信息	响应首部字段
Cookie	服务器接收到的Cookie信息	请求首部字段

HTTPS

HTTP缺点

通信使用明文(不加密) 内容可能会被窃听（http自己不具有加密功能）
不验证通讯方的身份，所以有可能遭遇假装
没法证实报文的完成性，因此有可能遭遇篡改

加密处理

通讯加密

HTTP协议中没有加密机制，但能够经过SSL(安全套接层)或者TLS(安全传输层协议)的组合，加密HTTP通讯内容

与SSL组合适用的HTTP称为HTTPS 超文本传输安全协议或者HTTP over SSL

内容加密

前提是要求客户端和服务器同时具有加密和解密的机制

但因为加密方式不一样，报文主体被加密处理，但报文首部未被加密处理，因此仍然有被篡改的风险。

SSL

SSL是当今世界上应用最普遍的网络安全技术

SSL才用一种叫作公开密钥加密的加密处理方式。 公开密钥加密使用一对非对称的密钥。一把叫作私有密钥(不能让任何人知道)，一把叫作公开密钥(随意发布)。

混合加密机制

HTTPS才用共享密钥加密和公开密钥加密二者并用的混合加密机制。

认证的过程

证书

数字证书认证机构处于客户端和服务器双方均可信赖的第三方机构的立场。例如:威瑞信（VeriSign）
首先，服务器端提出公开密钥申请，而后分配到已签名的公开密钥，并将密钥放入公钥证书（证书）
服务器将公钥证书发送给客户端，客户端使用证书认证机构的公开密钥，对证书的数字签名进行验证。

认证的步骤

前提:证书的认证主要在三次握手中完成。 1.浏览器实现有数字证书机构的公开密钥。服务器有公钥和私钥

服务器用RSA生成公钥和私钥
把公钥放在证书里发送给客户端，私钥本身保存
客户端首先向一个权威的服务器检查证书的合法性，若是证书合法，客户端产生一段随机数，这个随机数就做为通讯的密钥，咱们称之为对称密钥，用公钥加密这段随机数，而后发送到服务器
服务器用密钥解密获取对称密钥，而后，双方就已对称密钥进行加密解密通讯了

PS:非对称的RSA加密性能是很是低的，缘由在于寻找大素数、大数计算、数据分割须要耗费不少的CPU周期，因此通常的HTTPS链接只在第一次握手时使用非对称加密，经过握手交换对称加密密钥，在以后的通讯走对称加密。

浏览器将本身支持的一套加密规则发送给网站。
网站从中选出一组加密算法与HASH算法，并将本身的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。
浏览器得到网站证书以后浏览器要作如下工做：

验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），若是证书受信任，则浏览器栏里面会显示一个小锁头，不然会给出证书不受信的提示。

若是证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。

使用约定好的HASH算法计算握手消息，并使用生成的随机数对消息进行加密，最后将以前生成的全部信息发送给网站。
网站接收浏览器发来的数据以后要作如下的操做：

使用本身的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。

使用密码加密一段握手消息，发送给浏览器。
浏览器解密并计算握手消息的HASH，若是与服务端发来的HASH一致，此时握手过程结束，以后全部的通讯数据将由以前浏览器生成的随机密码并利用对称加密算法进行加密。

HTTP2

HTTP/2.0在2014年11月实现标准化，但目前大部分的网络仍然使用HTTP/1.1协议

优点借助Nginx

头部压缩、多路复用、Server Push(服务器推送)

头部压缩

HTTP/2 协议由两个 RFC 组成：一个是 RFC 7540，描述了 HTTP/2 协议自己；一个是 RFC 7541，描述了 HTTP/2 协议中使用的头部压缩技术

多路复用

Keep-Alive 解决了同一域名下屡次请求的重复创建三次握手和四次挥手的问题。只须要创建一次HTTP请求便可。但仍然存在着 "串行传输问题"，以及并发问题由于浏览器限制，浏览器发起的最大请求数为6。

HTTP/2引入二进制数据帧和流的概念，其中帧对数据进行顺序标识

HTTP/2对同一域名下全部请求都是基于流，也就是说同一域名无论访问多少文件，也只创建一路链接。一样Apache的最大链接数为300，由于有了这个新特性，最大的并发就能够提高到300，比原来提高了6倍！

Server Push

服务端推送容许咱们向用户发送一些尚未被访问的资源

解决的问题:

内联内容的服务器通讯

若样式、脚本资源之外链及模块形式引用，会更高效地进行缓存。当用户访问后续页面须要这些资源时，能够直接从缓存中获取，从而省去了额外的资源请求

优化缓存行为

当推送资源时，咱们能得到与内联相同的性能提高，同时保持资源的外链形式，从而有独立的缓存策略。

如何使用Server push

使用Server Push，一般会如下面的方式使用 Link 这个HTTP首部。

Link: </css/styles.css>; rel=preload; as=style

在进行 HTTP/2 网站性能优化时很重要一点是「使用尽量少的链接数」，本文提到的头部压缩是其中一个很重要的缘由：同一个链接上产生的请求和响应越多，动态字典积累得越全，头部压缩效果也就越好。因此，针对 HTTP/2 网站，最佳实践是不要合并资源，不要散列域名。

之前咱们作的性能优化不适用于HTTP/2了

JS文件的合并。咱们如今优化的一个主要方向就是尽可能的减小HTTP的请求数，对咱们工程中的代码，研发时分模块开发，上线时咱们会把全部的代码进行压缩合并，合并成一个文件，这样无论多少模块，都请求一个文件，减小了HTTP的请求数。可是这样作有一个很是严重的问题：文件的缓存。当咱们有100个模块时，有一个模块改了东西，按照以前的方式，整个文件浏览器都须要从新下载，不能被缓存。如今咱们有了HTTP/2了，模块就能够单独的压缩上线，而不影响其余没有修改的模块。
多域名提升浏览器的下载速度。以前咱们有一个优化就是把css文件和js文件放到2个域名下面，这样浏览器就能够对这两个类型的文件进行同时下载，避免了浏览器6个通道的限制，这样作的缺点也是明显的，1.DNS的解析时间会变长。2.增长了服务器的压力。有了HTTP/2以后，根据上面讲的原理，咱们就不用这么搞了，成本会更低。