Http面试相关

OfferKiller | Https 为什么是安全的?

Why | Https 为什么是安全的?(上) - 掘金

HTTPS详解二:SSL / TLS 工作原理和详细握手过程

HTTPS详解二:SSL / TLS 工作原理和详细握手过程 - 掘金

HTTPS 详解一:附带最精美详尽的 HTTPS 原理图 - 掘金

SSL / TLS 握手详细过程

  1. "client hello"消息: 客户端通过发送"client hello"消息向服务器发起握手请求,该消息包含了客户端所支持的 TLS 版本和密码组合以供服务器进行选择,还有一个"client random"随机字符串。
  2. "server hello"消息: 服务器发送"server hello"消息对客户端进行回应,该消息包含了数字证书,服务器选择的密码组合和"server random"随机字符串。
  3. 验证: 客户端对服务器发来的证书进行验证,确保对方的合法身份,验证过程可以细化为以下几个步骤:
    1. 检查数字签名
    2. 验证证书链 (这个概念下面会进行说明)
    3. 检查证书的有效期
    4. 检查证书的撤回状态 (撤回代表证书已失效)
  4. "premaster secret"字符串: 客户端向服务器发送另一个随机字符串"premaster secret (预主密钥)",这个字符串是经过服务器的公钥加密过的,只有对应的私钥才能解密。
  5. 使用私钥: 服务器使用私钥解密"premaster secret"。
  6. 生成共享密钥: 客户端和服务器均使用 client random,server random 和 premaster secret,并通过相同的算法生成相同的共享密钥 KEY
  7. 客户端就绪: 客户端发送经过共享密钥 KEY加密过的"finished"信号。
  8. 服务器就绪: 服务器发送经过共享密钥 KEY加密过的"finished"信号。
  9. 达成安全通信: 握手完成,双方使用对称加密进行安全通信。

TLS 握手过程中的一些重要概念

  1. 数字证书 (digital certificate): 在非对称加密通信过程中,服务器需要将公钥发送给客户端,在这一过程中,公钥很可能会被第三方拦截并替换,然后这个第三方就可以冒充服务器与客户端进行通信,这就是传说中的“中间人攻击”(man in the middle attack)。解决此问题的方法是通过受信任的第三方交换公钥,具体做法就是服务器不直接向客户端发送公钥,而是要求受信任的第三方,也就是证书认证机构 (Certificate Authority, 简称 CA)将公钥合并到数字证书中,然后服务器会把公钥连同证书一起发送给客户端,私钥则由服务器自己保存以确保安全。数字证书一般包含以下内容:

    1. 证书所有者的公钥

    2. 证书所有者的专有名称

    3. 证书颁发机构的专有名称

    4. 证书的有效起始日期

    5. 证书的过期日期

    6. 证书数据格式的版本号

    7. 序列号,这是证书颁发机构为该证书分配的唯一标识符... ...

  2. 数字签名 (digital signature): 这个概念很好理解,其实跟人的手写签名类似,是为了确保数据发送者的合法身份,也可以确保数据内容未遭到篡改,保证数据完整性。与手写签名不同的是,数字签名会随着文本数据的变化而变化。具体到数字证书的应用场景,数字签名的生成和验证流程如下:

    1. 服务器对证书内容进行信息摘要计算 (常用算法有 SHA-256等),得到摘要信息,再用私钥把摘要信息加密,就得到了数字签名
    2. 服务器把数字证书连同数字签名一起发送给客户端
    3. 客户端用公钥解密数字签名,得到摘要信息
    4. 客户端用相同的信息摘要算法重新计算证书摘要信息,然后对这两个摘要信息进行比对,如果相同,则说明证书未被篡改,否则证书验证失败
  3. 证书链 (certificate chain): 证书链,也称为证书路径,是用于认证实体合法身份的证书列表,具体到 HTTPS 通信中,就是为了验证服务器的合法身份。之所以使用证书链,是为了保证根证书 (root CA certificate)的安全,中间层可以看做根证书的代理,起到了缓冲的作用,如下图所示,这里还以 B 站证书为例:

证书链

证书链

证书链从根证书开始,并且证书链中的每一级证书所标识的实体都要为其下一级证书签名,而根证书自身则由证书颁发机构签名。客户端在验证证书链时,必须对链中所有证书的数字签名进行验证,直到达到根证书为止。

  1. 密码规范和密码组合 (CipherSpecs 和 CipherSuites): 通信双方在安全连接中所使用的算法必须符合密码安全协议的规定,CipherSpecs 和 CipherSuites 正好定义了合法的密码算法组合。CipherSpecs 用于认证加密算法和信息摘要算法的组合,通信双方必须同意这个密码规范才能进行通信。而 CipherSuites 则定义了 SSL / TLS 安全连接中所使用的加密算法的组合,该组合包含三种不同的算法:
    1. 握手期间所使用的的密钥交换和认证算法 (最常用的是 RSA 算法)
    2. 加密算法 (用于握手完成后的对称加密,常用的有 AES、3DES等)
    3. 信息摘要算法 (常用的有 SHA-256、SHA-1 和 MD5 等)

HTTP2.0简介

HTTP 2.0与OkHttp - 掘金

  • 二进制分帧层,是HTTP 2.0性能增强的核心,改变了客户端与服务器之间交互数据的方式,将传输的信息(HeaderBody等)分割为更小的消息和帧,并采用二进制格式的编码。
  • 并行请求与响应,客户端及服务器可以把HTTP消息分解为互不依赖的帧,然后乱序发送,最后再在另一端把这些消息组合起来。
  • 请求优先级(0表示最高优先级、-1表示最低优先级),每个流可以携带一个优先值,有了这个优先值,客户端及服务器就可以在处理不同的流时采取不同的策略,以最优的方式发送流、消息和帧。但优先级的处理需要慎重,否则有可能会引入队首阻塞问题。
  • 单TCP连接HTTP 2.0可以让所有数据流共用一个连接,从而更有效的使用TCP连接
  • 流量控制,控制每个流占用的资源,与TCP的流量控制实现是一模一样的。
  • 服务器推送HTTP 2.0可以对一个客户端请求发送多个响应,即除了最初请求响应外,服务器还可以额外的向客户端推送资源,而无需客户端明确地请求。
  • 首部(Header)压缩HTTP 2.0会在客户端及服务器使用“首部表”来跟踪和存储之前发送的键-值对,对于相同的数据,不会再通过每次请求和响应发送。首部表在连接存续期间始终存在,由客户端及服务器共同渐进的更新。每个新的首部键-值对要么追加到当前表的末尾,要么替换表中的值。

Okhttp如何开启的Http2.0

Okhttp如何开启的Http2.0 - 掘金

http请求怎样实现TCP长连接,以及长轮询和短轮询的区别

http的长连接和短连接(史上最通俗!) - 简书

长连接的实现:要判断是否要启用keepalive和合理设置timeout时间

HTTP1.0协议不支持长连接,从HTTP1.1协议以后,连接默认都是长连接。

长连接实际上是指的TCP连接,LZ瞬间自己就想明白了上面的那些问题。

第一个问题是,是不是只要设置Connection为keep-alive就算是长连接了?

当然是的,但要服务器和客户端都设置。

第二个问题是,我们平时用的是不是长连接?

这个也毫无疑问,当然是的。(现在用的基本上都是HTTP1.1协议,你观察一下就会发现,基本上Connection都是keep-alive。而且HTTP协议文档上也提到了,HTTP1.1默认是长连接,也就是默认Connection的值就是keep-alive)

第三个问题,也是LZ之前最想不明白的问题,那就是我们这种普通的Web应用(比如博客园,我的个人博客这种)用长连接有啥好处?需不需要关掉长连接而使用短连接?

首先,刚才已经说了,长连接是为了复用,这个在之前LZ就明白。那既然长连接是指的TCP连接,也就是说复用的是TCP连接。那这就很好解释了,也就是说,长连接情况下,多个HTTP请求可以复用同一个TCP连接,这就节省了很多TCP连接建立和断开的消耗。

比如你请求了博客园的一个网页,这个网页里肯定还包含了CSS、JS等等一系列资源,如果你是短连接(也就是每次都要重新建立TCP连接)的话,那你每打开一个网页,基本要建立几个甚至几十个TCP连接,这浪费了多少资源就不用LZ去说了吧。

但如果是长连接的话,那么这么多次HTTP请求(这些请求包括请求网页内容,CSS文件,JS文件,图片等等),其实使用的都是一个TCP连接,很显然是可以节省很多消耗的。

HTTP/1.0和HTTP/1.1 http2.0的区别,HTTP怎么处理长连接(阿里)

HTTP 2.0 和 HTTP 1.1 相比有哪些优势呢? - 知乎

HTTP/1.0和HTTP/1.1 http2.0的区别,HTTP怎么处理长连接(阿里) - aspirant - 博客园

面试官:说说 HTTP1.0/1.1/2.0 的区别?-有了 

HTTP1.0:

  • 浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个 TCP 连接

HTTP1.1:

  • 引入了持久连接,即 TCP 连接默认不关闭,可以被多个请求复用
  • 在同一个 TCP 连接里面,客户端可以同时发送多个请求
  • 虽然允许复用 TCP 连接,但是同一个 TCP 连接里面,所有的数据通信是按次序进行的,服务器只有处理完一个请求,才会接着处理下一个请求。如果前面的处理特别慢,后面就会有许多请求排队等着
  • 新增了一些请求方法
  • 新增了一些请求头和响应头

HTTP2.0:

  • 采用二进制格式而非文本格式
  • 完全多路复用,而非有序并阻塞的、只需一个连接即可实现并行
  • 使用报头压缩,降低开销
  • 服务器推送

HTTP1.1新改动:

  • 持久连接
  • 请求管道化
  • 增加缓存处理(新的字段如cache-control)
  • 增加Host字段、支持断点传输等

HTTP2新改动:

  • 二进制分帧
  • 多路复用
  • 头部压缩
  • 服务器推送
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值