> 文章列表 > Http和Https

Http和Https

Http和Https

http和https的区别

  • 开销:HTTPS 协议需要到 CA 申请证书,一般免费证书很少,需要交费;
  • 资源消耗:HTTP 是超文本传输协议,信息是明文传输,HTTPS 则是具有安全性的 ssl 加密传输协议,需要消耗更多的 CPU 和内存资源;
  • 端口不同:HTTP 和 HTTPS 使用的是完全不同的连接方式,用的端口也不一样,前者是 80,后者是 443;
  • 安全性:HTTP 的连接很简单,是无状态的;HTTPS 协议是由 TLS+HTTP 协议构建的可进行加密传输身份认证的网络协议,比 HTTP 协议安全;
    HTTP是基于TCP的,而HTTPS是基于TLS的
    HTTP的往返时间为1RTT,而HTTPS的往返时间为3RTT
    HTTP只需要创建一次TCP连接,而HTTPS需要创建两次TCP连接

http 常见请求方法(get和post的区别) + http 报文包含的一些属性 + http 常见状态码的含义(3xx额外关注下)

  • POST和GET有哪些区别?各自应用场景?PUT,HEAD,DELETE请求呢?
    使用场景: Get请求用于获取资源,Post请求用于传输实体主体。
    参数: Get的参数是以查询字符串出现在URL中,而post请求的参数存储在实体主体。由于URL只支持ASCII码,因此GET请求如果出现中文等字符就需要先进行编码,例如 中文 会转换为 %E4%B8%AD%E6%96%87,而空格会转换为 %20。
    安全性: Get方法安全(还有Head),但Post方法并不安全,因为Post的目的是传送实体主体内容,可能会修改数据库里的数据,此外Put和Delete都不安全。
    幂等性: 在正确实现的条件下,GET,HEAD,PUT 和 DELETE 等方法都是幂等的,而 POST 方法不是。幂等的HTTP方法,同样的请求执行一次与连续执行多次的效果一样。POST /add_row HTTP/1.1 不是幂等的,如果调用多次,就会增加多行记录:
    可缓存: 如果要对响应进行缓存:请求报文的HTTP方法本身是可以缓存的,包含Get和Head,但Delete和Put不可缓存,Post在多数情况下不可缓存。响应报文的状态码可缓存,响应报文的 Cache-Control 首部字段没有指定不进行缓存。
    XMLHttpRequest: 在使用 XMLHttpRequest 的 POST 方法时,浏览器会先发送 Header 再发送 Data。但并不是所有浏览器会这么做,例如火狐就不会。而 GET 方法 Header 和 Data 会一起发送。
    HEAD方法和GET方法一样,只是不返回报文主体部分。用于确认URI的有效性及资源更新的日期时间等。
    PUT方法用来传输文件。就像FTP协议的文件上传一样,要求在请求报文的主体中包含文件内容,然后保存到请求URI指定的位置。
    DELETE方法用来删除文件,是与PUT相反的方法。DELETE方法按请求URI删除指定的资源。
    Http和Https
    常见字段,看小林coding总结的
  • 状态码分类
    1xx:表示目前是协议的中间状态,还需要后续请求

2xx:表示请求成功

3xx:表示重定向状态,需要重新请求

4xx:表示请求报文错误

5xx:服务器端错误

  • 常用状态码
    101 切换请求协议,从 HTTP 切换到 WebSocket

200 请求成功,有响应体

301 永久重定向:会缓存

302 临时重定向:不会缓存

304 协商缓存命中

403 服务器禁止访问

404 资源未找到

400 请求错误

500 服务器端错误

503 服务器繁忙

  • HTTP状态码301和302的区别,都有哪些用途?
    301重定向(301 Move Permanently),指页面永久性转移。301重定向是一种非常重要的”自动转向“技术,网址重定向最为可行的一种方法。
    301重定向使用场景:
    本站主站点域名为 www.conimi.com ,而还有一个域名 www.nico.cc,由于对该域名设置了301重定向,当输入www.nico.cc 时,自动跳转至 www.conimi.com 。(防止网站流量丢失)
    301重定向的优点:
    www.conimi.com和 conimi.com 是两个不同的域名,但是指向的内容完全相同,搜索引擎会对两个域名收录情况不同,这样导致网站权重和排名被分散;对conimi.com 做301重定向跳转至www.conimi.com 后,权重和排名集中到www.conimi.com,从而提升自然排名。
    302重定向指页面暂时性转移,常被用作网址劫持,容易导致网站降权,严重时网站会被封掉,不推荐使用。

http 长连接,开启/关闭

  • HTTP 如何实现长连接?在什么时候会超时?
    HTTP1.1默认都是长连接,HTTP1.0通过在头部(请求和响应头)设置 Connection: keep-alive。
    HTTP 一般会有 httpd 守护进程(里面可以设置 keep-alive timeout),当 tcp 链接闲置超过这个时间就会关闭。也可以在 HTTP 的 header 里面设置超时时间。web服务软件一般都会提供keepalive_timeout参数来指定HTTP长连接的超时时间。
    长连接减少TCP重复建立和断开所造成的额外开销,减轻了服务端的负载。
    理解:
    在 HTTP/1.0 中默认使用短连接。客户端和服务器每进行一次 HTTP 操作,就建立一次连接,任务结束就中断连接。每遇到一个 Web 资源,浏览器就会重新建立一个 HTTP 会话。
    从 HTTP/1.1 起,默认使用长连接,用以保持连接特性。在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭,客户端再次访问这个服务器时,会继续使用这一条已经建立的连接。Keep-Alive 不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如:Apache)中设定这个时间。

http 存在哪些问题

  • 通信使用明文(不加密),内容可能会被窃听
  • 不验证通信方的身份,因此有可能遭遇伪装(数字证书解决)
  • 无法证明报文的完整性,所以有可能已遭篡改(数字签名解决)

http 1.0,1.1,2.0,3.0版本区别

  • http1.0规定了浏览器与服务器只保持短暂的连接,连接无法复用,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接。TCP连接的建立需要三次握手,很耗费时间,因此http1.0版本性能比较差。Http和Https

  • http1.1引入了持久连接,也就是TCP连接默认不关闭,可以被多个请求复用。客户端和服务器发现对方一段时间没有活动就可以主动关闭连接或者客户端在最后一个请求时,主动告诉服务端要关闭连接。还引入了管道机制,也就是在同一个TCP连接里,客户端可以同时发送多个请求,这样就进一步改进了HTTP协议的效率,但对于服务端而言还是要顺序执行。Http和Https
    Http和Https

  • http2.0为了解决HTTP1.1仍存在的效率问题,采用了多路复用,也就是在一个连接里客户端和浏览器都可以同时发送多个请求或回应,而且不用按照顺序一一对应。前提就是HTTP2进行了二进制分帧,也就是HTTP2会将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码
    http2举个例子:
    老板可以同时下达多个命令,员工也可以收到A请求和B请求,于是先回应A请求,结果发现处理过程非常耗时,于是就发送A请求已经处理好的部分接着回应B请求,完成后再发送A请求剩下的部分。A请求的两部分响应再组合到一起发给老板,这个负责拆分,组装请求和二进制的一层就叫做二进制分帧层Header压缩就是压缩和员工之间的对话,服务器推送就是员工事先把一些老板可能询问的事情提前发送到老板手机(缓存)上,这样老板想要直到的时候就可以直接读取短信(缓存)了。
    Http和Https

  • http3目的在于降低基于TCP通讯的Web延迟,但是基于UDP实现的,这种通信方式像现在使用的微信语言,它使用UDP代理了TCP,UDP是一个非连接的协议,传输数据之前源端和终端不建立连接,并且UDP是使用最大努力交付,即不保证可靠交付。
    Http和Https

Https 的加密过程(对称/非对称加密 + 摘要 + 数字证书)

对称加密:
发送方和接受方用同样的规则(算法)来为数据进行加密解密,如果第三方知道它们使用的算法将数据拦截破解就会很危险。

非对称加密:
用两个密钥进行加密和解密,公开密钥是所有人都知道的密钥,私有密钥仅仅是持有方才有的密钥,一般来说私钥就放在服务器里,数据公钥加密就只能被私钥解密,数据经过私钥加密就只能被公钥解密,如果应用到客户端和服务端,就是服务端自己拥有成对的私钥和公钥,然后公布自己的公钥让客户端知道,客户端用公钥把自己的数据进行加密,加密后用公钥反而无法解密这段数据,一定要用服务端的私钥才能解密,这样的非对称加密其实也叫公钥加密。
Http和Https
我们不知道和我在沟通的是否是自己想要沟通的对象,比如b站的域名很多人容易输入错误,可能会有不法分子伪装B站域名让你访问,HTTPS解决了这个问题,服务端需要申请SSL证书,来证明这个域名就是大家所熟知的B站。SSL证书其实就是保存在源服务器的数据文件,要让SSL证书生效就需要向CA(证书授权中心)申请,这个证书包括了特定的公钥和私钥,服务器安装了这个SSL证书以后,用户就可以通过HTTPS来访问服务器了,浏览器也会把HTTP的默认端口80改为HTTPS的默认端口443。
Http和Https
TLS握手:
Http和Https
客户端生成预主密钥
会话密钥之应用在当前密钥,提高了安全性
生成会话密钥后就一直使用会话密钥了,不需要握手非对称加密连接,后续会话就一直使用会话密钥对称加密连接。

什么是数字签名

为了避免数据在传输过程中被替换,比如黑客修改报文信息,但自己毫不知情,发送方先用hash函数生成摘要,然后使用其私钥将其加密生成数字签名,发送方附带这个数字签名发送过去,接受方通过发送方的公钥对数字签名进行解密得到摘要,再通过hash函数将得到的结果和摘要对比,如果一致则证明内容未被修改过。

理解数字证书的用处

对称加密中,双方使用公钥进行解密。虽然数字签名可以保证数据不被替换,但是数据是由公钥加密的,如果公钥被他人替换,则仍然可以伪造数据,因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的,CA 证书机构会负责颁发一个证书。
1、首先,客户端向服务器发出加密请求。
2、服务器用自己的私钥加密网页以后,连同本身的数字证书,一起发送给客户端。
3、客户端(浏览器)的”证书管理器”,有”受信任的根证书颁发机构”列表。客户端会根据这张列表,查看解开数字证书的公钥是否在列表之内。
4、如果数字证书记载的网址,与你正在浏览的网址不一致,就说明这张证书可能被冒用,浏览器会发出警告。
5、如果这张数字证书不是由受信任的机构颁发的,浏览器会发出另一种警告。
6、如果数字证书是可靠的,客户端就可以使用证书中的服务器公钥,对信息进行加密,然后与服务器交换加密信息。

https的缺点

HTTPS 协议握手阶段比较费时,会使页面的加载时间延长近 50%,增加 10% 到 20% 的耗电;
HTTPS 连接缓存不如 HTTP 高效,会增加数据开销和功耗,甚至已有的安全措施也会因此而受到影响;
SSL 证书需要钱,功能越强大的证书费用越高,个人网站、小网站没有必要一般不会用;
SSL 证书通常需要绑定 IP,不能在同一 IP 上绑定多个域名,IPv4 资源不可能支撑这个消耗;
HTTPS 协议的加密范围也比较有限,在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的,SSL 证书的信用链体系并不安全,特别是在某些国家可以控制 CA 根证书的情况下,中间人攻击一样可行;