HTTP与HTTPS区别
HTTPS
- SSL
HTTPS流程
加密算法
- 对称加密（Symmetric Cryptography）
- 非对称加密（Asymmetric Cryptography）
Get与Post的区别
HTTP的Header（请求头）
HTTP之解决HTTP无状态协议
Session和Cookie区别
URL和URI的区别
HTTP各版本区别
客户端、web服务器、HTTP三者之间的联系
浏览器与服务器

HTTP与HTTPS区别

https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用
http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议
http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443
http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全

HTTPS

HTTPS其实是有两部分组成：HTTP + SSL / TLS，即在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。比如很多银行，电商网站都采用了https方式，就是在网站上面部署由权威CA颁发的SSL证书。

SSL

SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层：SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等，主要提供：

认证用户与服务器,确保数据在正确的用户以及服务器之间传输
数据完整性的维护
传输数据的加密

HTTPS流程

客户端发起HTTPS请求
用户在浏览器里输入一个https网址，然后连接到server的端口
服务端的配置
采用HTTPS协议的服务器必须要有一套数字证书，这套证书就是一对公钥和私钥
传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等
客户端解析证书
这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值，然后用证书对该随机值进行加密
传送加密信息
这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了
服务端解密信息
服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥
传输加密后的信息
这部分信息是服务段用私钥加密后的信息，可以在客户端被还原
客户端解密信息
客户端用之前生成的私钥解密服务端传过来的信息，于是获取了解密后的内容

加密算法

HTTPS一般使用的加密与HASH算法如下：

非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256

对称加密（Symmetric Cryptography）

对称加密是最快速、最简单的一种加密方式，加密（encryption）与解密（decryption）用的是同样的密钥（secret key）。对称加密有很多种算法，由于它效率很高，所以被广泛使用在很多加密协议的核心当中。
对称加密通常使用的是相对较小的密钥，一般小于256 bit。因为密钥越大，加密越强，但加密与解密的过程越慢。密钥的大小既要照顾到安全性，也要照顾到效率。
对称加密的一大缺点是密钥的管理与分配，换句话说，如何把密钥发送到需要解密你的消息的人的手里是一个问题。在发送密钥的过程中，密钥有很大的风险会被黑客们拦截。现实中通常的做法是将对称加密的密钥进行非对称加密，然后传送给需要它的人。

非对称加密（Asymmetric Cryptography）

非对称加密为数据的加密与解密提供了一个非常安全的方法，它使用了一对密钥，公钥（public key）和私钥（private key）。私钥只能由一方安全保管，不能外泄，而公钥则可以发给任何请求它的人。非对称加密使用这对密钥中的一个进行加密，而解密则需要另一个密钥。比如，你向银行请求公钥，银行将公钥发给你，你使用公钥对消息加密，那么只有私钥的持有人–银行才能对你的消息解密。与对称加密不同的是，银行不需要将私钥通过网络发送出去，因此安全性大大提高。
虽然非对称加密很安全，但是和对称加密比起来，它非常的慢，所以还是要用对称加密来传送消息，但对称加密所使用的密钥可以通过非对称加密的方式发送出去。例子：
（１）需要在银行的网站做一笔交易，浏览器首先生成了一个随机数作为对称密钥
（2）浏览器向银行的网站请求公钥
（3）银行将公钥发送给浏览器
（4）浏览器使用银行的公钥将自己的对称密钥加密
（5）浏览器将加密后的对称密钥发送给银行
（6）银行使用私钥解密得到浏览器的对称密钥
（7）浏览器与银行可以使用对称密钥来对沟通的内容进行加密与解密了

对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高
非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢
解决的办法是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通

Get与Post的区别

对于HTTP请求来说，语法是指请求响应的格式，比如请求第一行必须是方法名URI协议/版本这样的格式。语义则定义了这一类型的请求具有什么样的性质。要理解这两个方法的区别，本质上是语义的对比而不是语法的对比。GET的语义是请求获取指定的资源。GET方法是安全、幂等、可缓存的，GET方法的报文主体没有任何语义。POST的语义是根据报文主体对指定的资源做出处理，具体的处理方式视资源类型而不同。POST不安全，不幂等，大部分实现不可缓存。

HTTP方法的几个性质：
Safe - 如果一个方法的语义在本质上是只读的，那么这个方法就是安全的。客户端向服务端的资源发起的请求如果使用了是安全的方法，就不应该引起服务端任何的状态变化，因此也是无害的。 GET是安全的。但是这个定义只是规范，并不能保证方法的实现也是安全的，服务端的实现可能会不符合方法语义

Idempotent - 幂等幂等的概念是指同一个请求方法执行多次和仅执行一次的效果完全相同。引入幂等主要是为了处理同一个请求重复发送的情况，比如在请求响应前失去连接，如果方法是幂等的，就可以放心地重发一次请求。这也是浏览器在后退/刷新时遇到POST会给用户提示的原因：POST语义不是幂等的，重复请求可能会带来意想不到的后果。

Cacheable - 可缓存性是一个方法是否可以被缓存

HTTP的Header（请求头）

每个HTTP请求和响应都会带有相应的头部信息。

HTTP请求头部信息：
Accept:浏览器能够处理的内容类型
Accept-Charset:浏览器能够显示的字符集
Accept-Encoding：浏览器能够处理的压缩编码
Accept-Language：浏览器当前设置的语言
Connection：浏览器与服务器之间连接的类型
Cookie：当前页面设置的任何Cookie
Host：发出请求的页面所在的域
Referer：发出请求的页面的URL
User-Agent：浏览器的用户代理字符串HTTP响应头部信息：
Date：表示消息发送的时间，时间的描述格式由rfc822定义
server:服务器名字
Connection：浏览器与服务器之间连接的类型
content-type:表示后面的文档属于什么MIME类型
Cache-Control：控制HTTP缓存

HTTP之解决HTTP无状态协议

HTTP的无连接、无状态的含义：
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即我们给服务器发送 HTTP 请求之后，服务器根据请求，会给我们发送数据过来，但是，发送完，不会记录任何信息。

1、通过Cookies保存状态信息

通过Cookies，服务器就可以知道请求2和请求1来自同一个客户端。

2、通过Session保存状态信息
Session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构来保存信息。当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为 session id；如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个 session检索出来使用（如果检索不到，可能会新建一个）；如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中通过Cookie返回给客户端保存。

Session的实现方式：
1、使用Cookie来实现
服务器给每个Session分配一个唯一的JSESSIONID，并通过Cookie发送给客户端。当客户端发起新的请求的时候，将在Cookie头中携带这个JSESSIONID。这样服务器能够找到这个客户端对应的Session。

2、使用URL回写来实现
URL回写是指服务器在发送给浏览器页面的所有链接中都携带JSESSIONID的参数，这样客户端点击任何一个链接都会把JSESSIONID带回服务器。如果直接在浏览器输入服务端资源的url来请求该资源，那么Session是匹配不到的。
Tomcat 对Session的实现，是一开始同时使用Cookie和URL回写机制，如果发现客户端支持Cookie，就继续使用Cookie，停止使用URL回写。如果发现Cookie被禁用，就一直使用URL回写。jsp开发处理到Session的时候，对页面中的链接记得使用 response.encodeURL() 。

Session和Cookie区别

Cookie的工作原理是：由服务器产生内容，浏览器收到请求后保存在本地；当浏览器再次访问时，浏览器会自动带上cookie，这样服务器就能通过cookie的内容来判断这个是“谁”了。
cookie虽然在一定程度上解决了“保持状态”的需求，但是由于cookie本身最大支持4096字节，以及cookie本身保存在客户端，可能被拦截或窃取，因此就需要有一种新的东西，它能支持更多的字节，并且他保存在服务器，有较高的安全性。这就是session。
基于http协议的无状态特征，服务器根本就不知道访问者是“谁”。那么上述的cookie就起到桥接的作用。可以给每个客户端的cookie分配一个唯一的id，这样用户在访问时，通过cookie，服务器就知道来的人是“谁”。然后我们再根据不同的cookie的id，在服务器上保存一段时间的私密资料，如“账号密码”等等。

Cookie和Session的区别：

Cookie中只能保存ASCII字符串，Session中可以保存任意类型的数据
隐私策略不同。 Cookie存储在客户端，对客户端是可见的，可被客户端窥探、复制、修改，发生Cookie欺骗。而Session存储在服务器上，不存在敏感信息泄露的风险
有效期不同。 Cookie的过期时间可以被设置很长。Session依赖于名为SESSIONID的Cookie，其过期时间默认为-1，只要关闭了浏览器窗口，该Session就会过期，因此Session不能完成信息永久有效。如果Session的超时时间过长，服务器累计的Session就会越多，越容易导致内存溢出
服务器压力不同。 每个用户都会产生一个session，如果并发访问的用户过多，就会产生非常多的session，耗费大量的内存
浏览器支持不同。 Session 的运行依赖Session ID，而 Session ID 是存在 Cookie 中的，也就是说，如果浏览器禁用了 Cookie，Session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 Session ID）
跨域支持不同。 Cookie支持跨域访问（设置domain属性实现跨子域），Session不支持跨域访问

防止Cookie欺骗
一种是不用Cookie，用Session。但是Session的有效期太短。
二是使用加密算法，并且加时间戳和IP戳。

URL和URI的区别

URI(通一资源标志符，Uniform Resource Identifier)，表示的是web上每一种可用的资源，如 HTML文档、图像、视频片段、程序等都由一个URI进行标识的。
URL(统一资源定位符，Uniform Resource Locator)是URI的一个子集。采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL是URI概念的一种实现方式。
URI和URL都定义了资源是什么，但URL还定义了该如何访问资源。URL是一种具体的URI，它是URI的一个子集，它不仅唯一标识资源，而且还提供了定位该资源的信息。URI 是一种语义上的抽象概念，可以是绝对的，也可以是相对的，而URL则必须提供足够的信息来定位，是绝对的。

HTTP各版本区别

http0.9
最初的http版本，仅支持get方法，只能传输纯文本内容，所以请求结束服务段会给客户端返回一个HTML格式的字符串，然后由浏览器自己渲染。http0.9是典型的无状态连接（无状态是指协议对于事务处理没有记忆功能，对同一个url请求没有上下文关系，每次的请求都是独立的，服务器中没有保存客户端的状态）

http1.0
这个版本后任何文件形式都可以被传输，本质上支持长连接，但是默认还是短连接，增加了keep-alive关键字来由短链接变成长连接。HTTP的请求和回应格式也发生了变化，除了要传输的数据之外，每次通信都包含头信息，用来描述一些信息。还增加了状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等

http1.1
HTTP1.1最大的变化就是引入了长链接，也就是TCP链接默认是不关闭的可以被多个请求复用。客户端或者服务器如果长时间发现对方没有活动就会关闭链接，但是规范的做法是客户端在最后一个请求的时候要求服务器关闭链接。对于同一个域名，目前浏览器支持建立6个长链接。
节约带宽，HTTP1.1支持只发送header头信息不带任何body信息，如果服务器认为客户端有权限请求指定数据那就返回100，没有就返回401，当客户端收到100的时候可以才把要请求的信息发给服务器。并且1.1还支持了请求部分内容，如果当前客户端已经有一部分资源了，只需要向服务器请求另外的部分资源即可，这也是支持文件断点续传的基础。
1.1版本中增加了host处理，在HTTP1.0中认为每台服务器都绑定一个唯一的ip地址，因此在URL中并没有传递主机名，但是随着虚拟机技术的发展，可能在一台物理机器上存在多个虚拟主机，并且他们共享了一个ip地址，http1.1中请求消息和响应消息都支持host头域，如果不存在还会报出错误。

http2.0
多路复用：在一个连接里面并发处理请求，不像http1.1在一个tcp连接中各个请求是串行的、花销很大。在1.0版本后增加了header头信息，2.0版本通过算法把header进行了压缩这样数据体积就更小，在网络上传输就更快。服务端有了推送功能，将客户端感兴趣的东西推给客户端，当客户端请求这些时，直接去缓存中取就行。

http3.0
HTTP/3 不再基于 TCP 而是采用了 UDP。虽然HTTP/2 使用了多路复用，但当这个连接中出现了丢包的情况，那就会导致 HTTP/2 的性能低下。因为在出现丢包的情况下，整个 TCP 都要开始等待重传，也就导致了后面的所有数据都被阻塞了。但是对于 HTTP/1.1 来说，可以开启多个 TCP 连接，出现这种情况反到只会影响其中一个连接，剩余的 TCP 连接还可以正常传输数据。基于这个原因，Google 创建了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上。QUIC 虽然基于 UDP，但是在原本的基础上新增了很多功能。

QUIC 功能
0RTT
通过使用类似 TCP 快速打开的技术，缓存当前会话的上下文，在下次恢复会话的时候，只需要将之前的缓存传递给服务端验证通过就可以进行传输了。0RTT 建连可以说是 QUIC 相比 HTTP/2 最大的性能优势。 0RTT 建连有两层含义：
1、传输层 0RTT 就能建立连接；
2、加密层 0RTT 就能建立加密连接。

多路复用
QUIC 原生实现了多路复用功能，并且传输的单个数据流可以保证有序交付且不会影响其它数据流，这样的技术就解决了前边提到的 TCP 多路复用存在的问题。
同 HTTP/2 一样，同一个 QUIC 连接上可以创建多个 stream 来发送多个 HTTP 请求，但是，QUIC 是基于 UDP 的，因为一个连接上的多个 stream 之间没有依赖，所以不存在 HTTP/2 中的问题。比如下图中 stream2 丢了一个 UDP 包，不会影响后面跟着 Stream3 和 Stream4，不存在 TCP 队头阻塞。虽然 stream2 的那个包需要重新传，但是 stream3、stream4 的包无需等待就可以发给用户。
另外 QUIC 在移动端的表现也会比 TCP 好。因为 TCP 是基于 IP 和端口去识别连接的，这种方式在多变的移动端网络环境下是很脆弱的。而 QUIC 是通过 ID 的方式去识别一个连接，不管你网络环境如何变化，只要 ID 不变，就能迅速重连上。

加密认证的报文
TCP 协议头部没有经过任何加密和认证，所以在传输过程中很容易被中间网络设备篡改、注入和窃听，比如修改序列号与滑动窗口。这些行为有可能是出于性能优化，也有可能是主动攻击。
相比之下，QUIC 的 packet 可以说是武装到了牙齿。除了个别报文比如 PUBLIC_RESET 和 CHLO，所有报文头部都是经过认证的，报文 Body 都是经过加密的。
这样只要是针对 QUIC 报文进行了任何修改，接收端都能够及时发现，有效地降低了安全风险。

前向纠错机制
QUIC 协议有一个非常独特的特性，称为前向纠错（Forward Error Correction，FEC），每个数据包除了它本身的内容之外，还包括了部分其它数据包的数据，因此少量的丢包可以通过其它包的冗余数据直接组装而无需重传。
前向纠错牺牲了每个数据包可以发送数据的上限，但是减少了因为丢包导致的数据重传次数。这会取得更好的效果，因为数据重传将会消耗更多的时间，包括确认数据包丢失、请求重传与等待新数据包等步骤。

客户端、web服务器、HTTP三者之间的联系

（1）客户端与web服务器工作过程
当浏览器寻找到Web服务器的地址之后，浏览器帮助我们把对服务器的请求转换为一系列参数发送给Web服务器。服务器收到浏览器发来的请求参数之后，将会分析这些数据，并进行处理。然后向浏览器回应处理的结果，也就是一些新的数据；这些数据通常是HTML网页或者图片。浏览器收到之后，解析这些数据，将它们呈现在浏览器的窗口中，这就是我们看到的网页。
（2）客户端与web服务器遵守共同标准：HTTP协议
在浏览器与Web服务器的对话中，需要使用双方都能够理解的语法规范进行通信，这种程序之间进行通信的语法规范，我们称之为协议。协议有许多种，根据国际标准化组织ISO的网络参考模型，程序与程序之间的通信可分为7层，从低到高依次为：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。

浏览器与服务器

HTTP协议就是TCP/IP协议中专门用于浏览器与Web服务器之间通信的应用层协议。应用层协议依赖于传输层协议完成数据传输，传输层协议依赖于网络层协议完成数据传输。

HTTPS/HTTP相关推荐

nginx配置http、https访问，nginx指定ssl证书，阿里云腾讯云华为云设置nginx https安全访问
nginx配置http.https访问要设置https访问需要从对应的云厂商申请证书,并下载Nginx证书到服务器. 我这里从阿里云申请了免费的域名证书,然后将证书放置在服务器的/etc/ssl/. ...
消除安卓SDK更新时的“https://dl-ssl.google.com refused”异常的方法
消除安卓SDK更新时的"https://dl-ssl.google.com refused"异常的方法消除安卓SDK更新时的"https://dl-ssl.google ...
https://blog.csdn.net/blmoistawinde/article/details/84329103
背景很多场景需要考虑数据分布的相似度/距离:比如确定一个正态分布是否能够很好的描述一个群体的身高(正态分布生成的样本分布应当与实际的抽样分布接近),或者一个分类算法是否能够很好地区分样本的特 ...
如何写出安全的API接口（参数加密+超时处理+私钥验证+Https）
上篇文章说到接口安全的设计思路,如果没有看到上篇博客,建议看完再来看这个. 通过园友们的讨论,以及我自己查了些资料,然后对接口安全做一个相对完善的总结,承诺给大家写个demo,今天一并放出. 对于安全 ...
HTTP/HTTPS抓包工具-Fiddler
HTTP代理神器Fiddler Fiddler是一款强大Web调试工具,它能记录所有客户端和服务器的HTTP请求. Fiddler启动的时候,默认IE的代理设为了127.0.0.1:8888,而其他浏 ...
HTTP/HTTPS的请求和响应
HTTP和HTTPS HTTP协议(HyperText Transfer Protocol,超文本传输协议):是一种发布和接收 HTML页面的方法. HTTPS(Hypertext Transfer ...
阿里云https认证
1.登录阿里云服务器,在控制台上选择安全(云盾)---CA证书服务(数据安全) 2.点击购买证书--(阿里把免费的隐藏起来了,这显得很不厚道)默认都是付费的,如果要免费的需要先选择品牌 Syman ...
腾讯云https认证
1.准备好域名 2.登录腾讯云,在腾讯云找到ssL证书管理 2.申请一个证书选择1年免费版的 3.填写域名资料: 1.通用名称就是你的域名 2.申请邮箱填写你的常用邮箱 3.证书备注名:填写一个易记 ...
Error:(49, 1) A problem occurred evaluating project ':guideview'. Could not read script 'https://r
出现问题如下: Error:(49, 1) A problem occurred evaluating project ':guideview'. > Could not read script ...
在okhttp3,WebView中忽略HTTPS证书校验
在APP开发过程中,后台使用的可能是自签的Https证书,如果不忽略证书校验,会出现Trust anchor for certification path not found的错误 Okhttp3忽略 ...

HTTPS/HTTP

目录