1、Http(超文本传输控制协议)基本概念
HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。
- Http报文结构：
- Http常见状态码：
-
- 200: OK
- 204: No Content，响应头无Body数据。
- 206: Partitial Content，Http分块下载或断点续传，也是成功处理的标志。
\
-
- 301: Moved Permanently：永久重定向，表示资源已经不存在，需要使用另一个Url访问。
- 302: Found： 临时重定向，说明资源还在，但是需要换个Url访问。301和302会在响应头中的Location表明需要重新定向的Url。
- 304: Not Modified：表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向。该响应码与协商缓存有关，304通常是服务器告诉客户端可以使用浏览器中缓存。
\
-
- 400: Bad Request，客户端请求报文有误。
- 403: Forbidden，表示服务器禁止访问资源。
- 404: Not Found，表示资源找不到
\
-
- 500: 服务器出错。
- 501: Not implemented，还未支持该功能。
- 502: Bad Gateway，服务器作为网关或者代理时返回的错误码。
- 503: Service Unavailable， 表示服务器很忙，暂时无法响应。
- Http常见字段：
xiaolincoding.com/network/2_h…
- Get和Post的区别：
根据RCF规范：
Get语义是从服务器获取指定的资源。Get请求的参数位置一般写在URL中。Get方法是安全的（请求方法不会对破坏服务器上的资源。）且幂等的。浏览器很有可能会缓存Get请求的数据。
Post的语义是根据请求body对指定的资源进行处理。Post请求则不是安全的也不幂等。
- Http缓存技术：
1、强制缓存：
只要浏览器判断缓存没有过期，则直接食用浏览器的本地缓存，强制缓存利用Http响应头部中的Cache-Control和Expires实现。Cache-Control优先级高于Expires。
当浏览器第一次访问服务器后，服务器返回相关资源并在Http响应头部中加入Cache-Control字段用来告诉客户端资源的过期时间。当浏览器再次请求该资源时，会通过Cache-Control来看资源是否过期，如果没有过期则使用缓存。否则重新请求服务器。
2、协商缓存：浏览器与服务器协商之后，通过协商结果来判断是否使用本地缓存。
有些请求的响应码为304，这是告诉浏览器可以使用本地的缓存。协商缓存可以通过Http两种头部来实现。
-
- 请求头部中的Is-Modified-Since与响应头部中的LastModified实现。
- 请求头部中的 If-None-Match 字段与响应头部中的 ETag 字段。
协商缓存需要在未强制缓存命中的情况下才可以使用
- Http1.1
缺点：无状态【Cookie解决】+明文传输【Https解决】+无法验证报文完整性。
-
- 长连接：Http1.1提出了长连接的通信方式，只要客户端与服务端任意一端没有提出断开连接，则
保持TCP连接状态。Connection的keep-alive。这样就可以避免不断建立TCP连接，三次握手所花费的开销。如果Http长连接超过一段时间没有数据交互，那么服务端会自动断开该连接。
-
- 管道网络传输：长连接使得管道传输技术成为可能、管道机制允许客户端同时去发起两个请求而不必等待请求A响应后再发送请求B。然而服务器必须按照请求的顺序发送管道化请求的响应。Http1.1解决了请求的队头阻塞却没有解决响应的对头阻塞。
- 队头阻塞：
- Http与Https：Http通信接口部分采用SSL（Secure Socket Layer）和TLS（Trasport Layer Security）来代替。SSL是独立于Http的协议，所以其他应用层协议也可以采用。
HTTP采用明文传输，所以会有以下三个风险：所以可能会有冒充、窃听、篡改等风险。
Https在Http和传输层之间加入了SSL/TLS协议，解决了Http明文传输的风险问题。
SSL/TLS使用了以下机制来解决上述三个风险：
1、将服务器公钥放入数字证书中，解决了被冒充的风险。认证
2、使用混合加密实现信息的机密性，解决了被窃听的风险。加密
3、摘要算法来实现信息的完整性，解决了被篡改的风险。完整性保护
-
- 混合加密：对称加密和非对称加密结合（公开密钥加密和共享密钥加密）。
在通信建立之前采用非对称加密的方式交换会话密钥，后续不再采用非对称加密。在通行过程中全部使用对称加密的会话密钥来加密明文。
共享密钥加密：加密和解密共用一个密钥。但是对称密钥加密的同时需要把密钥也发送给对方，如何保证密钥在传输过程中安全？
公开密钥加密使用一对非对称的密钥，一把叫私钥【只有自己知道】，一把叫公钥【可以随意发布】。发送密文的一方使用对方的公钥进行加密，而对方收到密文后使用自己的私钥进行解密。想要通过公钥和密文恢复信息原文是非常难的。但是公开密钥加密处理时间较长。==使用认证机关颁发的公开数字证书来保证公开密钥的安全性。
Https采用对称和非对称加密结合的方式的混合加密模式：使用公开密钥加密方式来传输共享密钥，之后使用共享密钥加密方式来进行通信，交换报文。
-
- 摘要算法：实现完整性，摘要也需要一同被会话密钥加密。
-
- 数字证书：用来保证公钥的完整性。
- Https如何建立连接？TLS四次握手。
第一阶段握手：主要是确认加密组件和发送公开密钥证书。
1、客户端发送Client Hello报文开始SSL通信。报文中包含SSL版本、客户端支持的密码组件列表、随机数Client Random。
第二阶段握手：
2、服务端确认可以进行SSL通信后，向客户端发送Sever Hello，在报文中加入SSL版本以及加密组件（加密组件是从客户端的组件列表中筛选出来的）、服务端产生的随机数Server Random。
3、服务器发送Certificate报文，报文中包含公开密钥证书。
4、服务器发送Server Hello Down最初握手结束。
第三阶段握手：
1、客户端发送Client Key Exchange报文作为回应。该报文用3中获得的公开密钥加密随机密码串Pre-master Key。
2、客户端继续发送Change Cipher Spec 报文。该报文会提示服务器加密通信算法改变，在此报文之后的通信会采用 Pre-master secret 密钥加密。
3、客户端发送Finished报文，该报文包含迄今为止所有报文的整体校验值。
第四阶段握手：
4、服务端发送Change Cipher Spec报文。
5、服务端发送Finished报文。此时握手结束。
2、HTTP/1.1的优化
- 尽量避免发送Http请求
使用缓存技术。在本地客户端将请求URL作为key与返回报文作为value存储。客户端在重新发送请求的时候会在请求头部Etag加入第一次请求响应头部中的摘要，服务器检查该摘要与服务器资源是否一致。如果一致则返回304 Not Modified。
- 减少Http请求次数
借助代理服务器减少重定向请求次数。
合并请求：合并请求的方式就是合并资源，以一个大资源的请求替换多个小资源的请求。
减少HTTP响应的数据大小，无损压缩gzip。
3、Https RSA握手解析
需要经过四次消息传递完成TLS握手，之后就可以在安全的环境下传输Http报文，实现Https协议。
- TLS第一次握手：
Random随机数会被服务端保留，是生成对称加密密钥的材料之一。
- TLS第二次握手：
-
- 服务端发送Server Hello消息。
服务端也会给出一个随机数并选择第一次握手客户端发送的密码套件中的一个。
-
- 服务端向客户端发送Server Certificate，包含服务端公共密钥证书。
-
- 服务端向客户端发送Server Hello Down，表示服务端消息传递完成。
- TLS第三次握手：
-
- 客户端验证第二次握手中数字证书的有效性。验证有效之后会生成一个新的随机数（Pre-Master），使用服务端的RSA公钥加密该随机数，通过Client Key Exchange发送给服务端。
此时，客户端和服务端共享了三个随机数。双方可以根据三个随机数生成会话密钥，这是对称密钥，之后通过该密钥来进行Http报文的加密和解密。
-
- 生成会话密钥后，客户端发送一个Change Cipher Spec，告诉服务端开始使用加密方式发送消息。
-
- Finished最后客户端将之前所有发送数据做一个摘要，使用会话密钥加密后传输给服务端做验证，验证之前发送的信息是否有被篡改。
- TLS第四次握手：
-
- 服务端同样发送Change Cipher Spec和Finished。双方都验证没问题之后，开始使用会话密钥进行Http加密解密通信。
RSA使用服务端密钥对信息经过公钥加密的信息进行解密，所以一旦服务端密钥泄漏，TLS的握手过程便都会被破解。而如果服务端的密钥与公钥一直不变化的话，有可能会被暴力破解。
\
4、HTTPS ECDHE握手解析
ECDHE算法相比于RSA算法
1、第二次握手时、服务端发送完Certificate消息后，会再发送一个Server Key Exchange消息。
该过程中服务端做了三件事：
- 选取椭圆曲线x25599。
- 生成随机数作为椭圆曲线的私钥。
- 根据私钥计算出服务端的椭圆曲线公钥，并共享给服务器。
2、在第三次握手时、客户端会生成一个随机数作为客户端椭圆曲线的私钥，然后再根据服务端前面给的信息，生成客户端的椭圆曲线公钥，然后用「Client Key Exchange」消息发给服务端。
最终的会话密钥，就是用「客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥） 」三个材料生成的。
