阿畅的博客

# HTTP 常见题目

# http 的特点

  • 无状态 无连接

# http 报文的组成部分

  • 请求行，请求头 空行 请求体
  • 转态行 响应头 空行 响应体

# get 和 post 的区别

  • get 在浏览器回退是无害的，而post会再次提交请求
  • get 产生的 URL 地址可以被收藏，而 post 不可以
  • get 请求会被浏览器主动缓存， post 不会，除非手动设置
  • get 只能进行 URL 编码，post 支持多种编码方式
  • get 请求参数会被完成的保留咋浏览器历史记录里，而 post 中参数不会被保留
  • get 请求在 URL 中传送的参数是有长度限制的，而 post 没有限制
  • 对参数的数据类型，get 只接受 ASCII 字符，而 post 没有限制
  • get 比 post 更不安全，因为 参数直接暴露在 URL 上，不能用来传递敏感信息
  • get 通过 URL 传参数，post 放到 request body 中

# http 的状态码

  • 200 ok 客户端请求成功

  • 206 partial content 客户发送了一个带有 range 头的 get 请求，服务器完成了它

  • 301 Moved Permanently 所请求的页面已转移到新的 url

  • 302 Found 所请求的页面已经临时转移到新的 URL

  • 304 Not Modified: 客服端有缓冲的文档并发出了一个条件性的请求，服务器告诉客户，原来缓冲的文档还可以继续使用。

  • 400 bad request 客户端请求有语法错误，不能被服务端所理解

  • 401 Unauthorized 请求未经授权，这个状态代码必须和 WWW-Authenticate 报头域一起使用

  • 403 Forbidden 对被请求页面的访问被禁止

  • 404 Not Found： 请求资源不存在

  • 500 internal server Error 服务器发生不可预期的错误原来缓冲的文档还可以继续使用

  • 503 Server Unavailble 请求未完成，服务器临时过载或当机，一段时间后可恢复正常

# 简单讲解一下 http2 的多路复用

  • 在 HTTP1 中，每次请求都会建立一次 HTTP 连接，也就是常说的3次握手 4次挥手，这个过程在一次请求过程中占用了相当长的时间，即使开启了 keep-alive ，解决了多次连接的问题，但依然有两个效率上的问题：

    1. 串行的文件传输，当请求 a 文件时，b 文件只能等待，等待 a 连接到服务器、服务器处理文件、服务器返回文件，这三个步骤。我们假设这三部都是1秒，那么 a 文件用时 3 秒，b 文件传输完成用时为 6 秒，以此类推。注：此项计算有一个前提条件，就是浏览器和服务器是单通道传输
    2. 连接数过多，假设 Apache 设置了最大并发数为 300， 因为浏览器限制，浏览器发起最大请求数为 6，也就是服务器能承载的最高并发为 50，当第 51个人访问时，就需要等待前面某个请求处理完成。

  • HTTP2 的多路复用就是为了解决上述的两个性能问题。在 HTTP 2总，有两个非常重要的概念，分别是帧（frame）和 流（stream）。 帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组件的数据流。

  • 多路复用，就是在一个 TCP 连接中可以存在多条流，也就是可以发送多个请求，对端都可以通过帧中的标识知道属于哪个请求，通过这个技术，可以避免 HTTP 旧版中队头阻塞的问题，极大的提高传输性能。

  • HTTP2采用二进制格式传输，取代了HTTP1.x的文本格式，二进制格式解析更高效。 多路复用代替了HTTP1.x的序列和阻塞机制，所有的相同域名请求都通过同一个TCP连接并发完成。在HTTP1.x中，并发多个请求需要多个TCP连接，浏览器为了控制资源会有6-8个TCP连接都限制。 HTTP2中

    • 同域名下所有通信都在单个连接上完成，消除了因多个 TCP 连接而带来的延时和内存消耗。
    • 单个连接上可以并行交错的请求和响应，之间互不干扰

1、首先token不是防止XSS的，而是为了防止CSRF的； 2、CSRF攻击的原因是浏览器会自动带上cookie，而浏览器不会自动带上token

# 介绍 HTTPS 握手过程

  1. 客户端使用 HTTPS 的 URL 访问 web 服务器，要求与服务器建立SSL连接
  2. web服务器收到客户端请求后，会将网站的证书（包括公钥）传递一份给客户端
  3. 客户端收到网站证书后会检查证书的颁发机构和过期时间，如果没有问题就随机产生一个私钥
  4. 客户端利用公钥将会话秘钥加密，并传送给服务器，服务端利用自己的私钥解密出会话秘钥。
  5. 之后服务器与客户端使用私钥加密传输

客户端发出请求（客户端向服务端发起加密通信的请求） 服务端回应：服务器收到客户端请求后，确认加密协议版本是否一致，如果版本一致返回服务器证书，否则关闭加密通信 客户端回应： 客户端收到服务器回应后，首先验证证书是否有效。如果证书失败，则会给访问者一个警示，由其决定是否继续连接。 如果证书没有失效，则使用证书的公钥加密一个随机数返回给服务器，同时返回客户端握手结束通知。 服务器的最后回应： 服务器收到客户端发来的 pre-master key （随机数）后，计算生成本次会话的 “会话密钥”，向客户端发送服务器握手结束通知。 握手结束，客户端与服务端进入加密通信

# HTTPS 握手过程中，客户端如何验证证书的合法性

  1. 验证证书的颁发机构是否受客户端信任。
  2. 通过 CRL 或 OCSP 的方式校验证书是否被吊销。
  3. 对比系统时间，校验证书是否在有效期内。
  4. 通过校验对方是否存在证书的私钥，判断证书的网站是否与证书颁发的域名一致。

# 浏览器缓存

浏览器缓存即 HTTP 缓存，将数据缓存在浏览器 服务端通过设置 HTTP 响应头来决定缓存策略，将资源缓存到本地浏览器。

# 缓存流程

缓存都是从第二次请求开始 第一次请求资源，服务器返回对应资源，并在 response header 响应头中添加缓存策略 第二次请求时，浏览器判断请求参数，命中缓存就直接 200 ，从本地缓存中拿数据，否则把响应参数存在 request header 请求头中，看是否命中协商缓存，命中则返回 304 ，否则服务器会返回全新资源。

# 缓存示例

  1. 无缓存：状态码 200，会有传输size 和 传输时间
  2. 设置协商缓存后，状态码 304，会有很小的 size 和 时间，主要因为协商缓存发送的是 304 请求判断是否使用本地缓存，如果缓存命中，浏览器直接从本地拿缓存的文件
  3. 设置强缓存，传输时间为 0。因为不需要走网络传输了，直接走本地缓存，因此响应时间为 0

# 几个控制缓存策略的响应头

# 强缓存

  1. Expires Expires是HTTP/1.0控制网页缓存的字段，其值为服务器返回该请求的结果缓存的到期时间，即再次发送请求时，如果客户端的时间小于Expires的值时，直接使用缓存结果。 到了HTTP/1.1，Expires已经被Cache-Control替代，原因在于Expires控制缓存的原理是使用客户端的时间与服务端返回的时间做对比，如果客户端与服务端的时间由于某些原因（时区不同；客户端和服务端有一方的时间不准确）发生误差，那么强制缓存将直接失效

  2. Cache-Control 在HTTP/1.1中，Cache-Control是最重要的规则，主要用于控制网页缓存，主要取值为：

    • public：所有内容都将被缓存（客户端和代理服务器都可缓存）
    • private：所有内容只有客户端可以缓存，Cache-Control的默认取值
    • no-cache：客户端缓存内容，但是是否使用缓存则需要经过协商缓存来验证决定
    • no-store：所有内容都不会被缓存，即不使用强制缓存，也不使用协商缓存
    • max-age=xxx (xxx is numeric)：缓存内容将在xxx秒后失效
    • must-revalidate：告诉浏览器、缓存服务器，本地副本过期前，可以使用本地副本；本地副本一旦过期，必须去源服务器进行有效性校验。 在无法确定客户端的时间是否与服务端的时间同步的情况下，Cache-Control相比于expires是更好的选择。

# 协商缓存

协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程

  1. Last-Modified / If-Modified-Since Last-Modified是服务器响应请求时，返回该资源文件在服务器最后被修改的时间

If-Modified-Since则是客户端再次发起该请求时，携带上次请求返回的Last-Modified值，通过此字段值告诉服务器该资源上次请求返回的最后被修改时间。服务器收到该请求，发现请求头含有If-Modified-Since字段，则会根据If-Modified-Since的字段值与该资源在服务器的最后被修改时间做对比，若服务器的资源最后被修改时间大于If-Modified-Since的字段值，则重新返回资源，状态码为200；否则则返回304，代表资源无更新，可继续使用缓存文件.

  1. Etag / If-None-Match Etag是服务器响应请求时，返回当前资源文件的一个唯一标识(由服务器生成)

If-None-Match是客户端再次发起该请求时，携带上次请求返回的唯一标识Etag值，通过此字段值告诉服务器该资源上次请求返回的唯一标识值。服务器收到该请求后，发现该请求头中含有If-None-Match，则会根据If-None-Match的字段值与该资源在服务器的Etag值做对比，一致则返回304，代表资源无更新，继续使用缓存文件；不一致则重新返回资源文件，状态码为200

Etag / If-None-Match优先级高于Last-Modified / If-Modified-Since，同时存在则只有Etag / If-None-Match生效。

# 什么是 HTTPS

  • 是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。

# HTTP 与 HTTPS 的区别

  1. HTTP 是明文传输，HTTPS 通过 SSL\TLS 进行了加密
  2. HTTP 的端口号是 80，HTTPS 是 443
  3. HTTPS 需要到 CA 申请证书，一般免费证书很少，需要交费
  4. HTTPS 的连接很简单，是无状态的；HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。

# 为什么使用 HTTPS

其实使用 HTTPS 最主要的用处是以下两点：

  1. 建立一个信息安全通道，来保证数据传输的安全
  2. 确认网站的真实性，防止钓鱼网站

# HTTPS 的缺点

  1. 在相同网络环境中，HTTPS 相比 HTTP 无论是响应时间还是耗电量都有大幅度上升。
  2. HTTPS 的安全是有范围的，在黑客攻击、服务器劫持等情况下几乎起不到作用。
  3. 在现有的证书机制下，中间人攻击依然有可能发生。
  4. HTTPS 需要更多的服务器资源，也会导致成本的升高。

# HTTPS 的原理

HTTPS 解决数据传输安全问题的方案就是使用加密算法，具体来说是混合加密算法，也就是对称加密和非对称加密的混合使用，这里有必要先了解一下这两种加密算法的区别和优缺点。

# 对称加密

对称加密，顾名思义就是加密和解密都是使用同一个密钥，常见的对称加密算法有 DES、3DES 和 AES 等，其优缺点如下：

  • 优点：算法公开、计算量小、加密速度快、加密效率高，适合加密比较大的数据。
  • 缺点：
    1. 交易双方需要使用相同的密钥，也就无法避免密钥的传输，而密钥在传输过程中无法保证不被截获，因此对称加密的安全性得不到保证。
    2. 每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一密钥，这会使得发收信双方所拥有的钥匙数量急剧增长，密钥管理成为双方的负担。对称加密算法在分布式网络系统上使用较为困难，主要是因为密钥管理困难，使用成本较高。

# 非对称加密

就是加密和解密需要使用两个不同的密钥：公钥（public key）和私钥（private key）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密；如果用私钥对数据进行加密，那么只有用对应的公钥才能解密。 非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公钥对外公开；得到该公钥的乙方使用公钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的私钥对加密后的信息进行解密。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西

  • 优点：算法公开，加密和解密使用不同的钥匙，私钥不需要通过网络进行传输，安全性很高。
  • 缺点：计算量比较大，加密和解密速度相比对称加密慢很多。

# HTTPS 原理的理解

  1. 客户端请求 HTTPS 网址，然后连接到 server 的 443 端口 (HTTPS 默认端口，类似于 HTTP 的80端口)。

  2. 采用 HTTPS 协议的服务器必须要有一套数字 CA (Certification Authority)证书，证书是需要申请的，并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书 (当然了是要钱的，安全级别越高价格越贵)。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被篡改。

  3. 服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等。Chrome 浏览器点击地址栏的锁标志再点击证书就可以看到证书详细信息。

  4. 客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码 KEY，并使用公钥A将其加密。

  5. 客户端把加密后的随机码 KEY 发送给服务器，作为后面对称加密的密钥。

  6. 服务器在收到随机码 KEY 之后会使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了。

  7. 服务器使用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端，客户端使用相同的密钥 (随机码 KEY)解密数据。

  8. 双方使用对称加密愉快地传输所有数据。