面试千层套路之HTTP系列

Hello 各位小伙伴大家好，这篇文章呢~ 主要简单分享一下我经历过的面试关于HTTP部分的经验和心得，如果有不对的地方，欢迎评论区各位大佬指正。
我一直都觉得面试是可以找到套路的，这个套路呢，其实是指知识的层层递进，所以我们准备的时候呢，一定要注意知识的全面和不同知识点之间的关联，最后再添加一些深度，就可以以不变应万变，满足绝大部分的面试需求啦~
PS: 有关TCP的相关知识可以参考这篇帖子 TCP握手挥手的千层套路

Q: 什么是Http？

• TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据
• HTTP 是一种 超文本传输协议(Hypertext Transfer Protocol)

Q: Http 协议的内容

• HTTP报文大致分为报文首部+报文主体，首部和报文主体由CRLF（一行空格）来区分

• HTTP报文有请求报文和响应报文两种，HTTP的这两种报文都由三部分组成：开始行、首部行、实体主体。

  • 开始行可用于区分两种报文
  • 首部行都是由首部字段名 和 值组成，每个首部行在结束地方都有 CRLF
  • 首部行和实体主体间有 CRLF

• HTTP请求由三部分组成，分别是：请求行、消息报头、请求正文

• HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文

• Request Body 请求体：根据应用场景的不同，HTTP请求的请求体有三种不同的形式。

  1. 请求体是任意类型的，服务器不会解析请求体，请求体的处理需要自己解析，如 POST JSON 的时候就是这类。例如：application/json，text/xml

  2. 表单提交：这里的格式要求就是 URL 中 Query String 的格式要求：多个键值对之间用&连接，键与值之间用=连接。表单的请求头中 Content-type 默认"application/x-www-form-urlencoded " 对表单数据进行编码，数据以键值对在http请求体重发送给服务器；如果enctype 属性为"multipart/form-data"，则以消息的形式发送给服务器。

  3. 文件分割：第三种请求体被分成多个部分，文件上传时会被使用，这种格式最先是被用于邮件传输中，每个字段/文件都被 boundary（Content-Type中指定的）分成单独的段，每段以--加 boundary 开头，然后是该段的描述头，描述头之后空一行接内容，请求结束的标识为 boundary 后面加--；

序列化协议 【ProtoBuffer & JSON】

1. XML
   • 优点：人机可读性好；可指定元素或特性的名称
   • 缺点：序列化数据只包含数据本身以及类的结构，不包括类型标识和程序集信息；类必须有一个将由 XmlSerializer 序列化的默认构造函数；只能序列化公共属性和字段不能序列化方法；文件庞大，文件格式复杂，传输占带宽
   • 使用场景：当做配置文件存储数据；实时数据转换
2. JSON
   • 优点：前后兼容性高；数据格式比较简单，易于读写；序列化后数据较小，可扩展性好，兼容性好；与XML相比，其协议比较简单，解析速度比较快
   • 缺点：数据的描述性比XML差；不适合性能要求为ms级别的情况；额外空间开销比较大
   • 使用场景：可替代ＸＭＬ；跨***访问；可调式性要求高的情况；基于Web browser的Ajax请求；传输数据量相对小，实时性要求相对低（例如秒级别）的服务
3. Protobuf
   • Protobuf是谷歌提出的序列化方案，不同的是此方案独立于语言、平台
   • 优点：序列化后码流小，性能高；结构化数据存储格式（XML JSON等）；通过标识字段的顺序，可以实现协议的前向兼容；结构化的文档更容易管理和维护
   • 缺点：可读性很差，需要依赖于工具生成代码；支持的语言相对较少，官方只支持Java 、C++ 、Python
   • 使用场景：对性能要求高的RPC调用；具有良好的跨***的访问属性；适合应用层对象的持久化

Http 常见状态码

• 2XX 成功

  • 200 服务器成功返回网页
  • 204 NO CONTENT，请求成功响应，没有资源返回

• 3XX 重定向

  • 301 Move permanently 永久性重定向，表示请求的资源已被分配了新的URI，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址。
  • 302 found 临时性重定向，搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回302代码，搜索引擎认为新的网址只是暂时的。
  • 304 未修改，自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容，进而节省带宽和开销。
  • 307 Temporary Redirect 临时的重定向，该响应代码与302重定向有所区别的地方在于，收到307响应码后，客户端应保持请求方法不变向新的地址发出请求

• 4XX 客户端错误

  • 400 bad request ，表示请求报文中存在语法错误
  • 403 forbidden ，表明对请求资源的访问被服务器拒绝了
  • 404 not found
  • 405 Method Not Allowed，客户端请求中的方法被禁止

• 5XX 服务器错误

  • 500 internal Server error ，表示服务器端在执行请求时发生了错误
  • 502 Bad Gateway，作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
  • 503 service unavailable ，服务器超时，服务器超负载或正在进行停机维护
  • 504 Gateway Timeout 表示扮演网关或者代理的服务器无法在规定的时间内获得想要的响应

Q: HTTP 1.0和HTTP 1.1的主要区别是什么

1. 连接：HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接；HTTP 1.1起，默认使用长连接,默认开启Connection： keep-alive。 HTTP/1.1的持续连接有非流水线方式和流水线方式 。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求
2. 错误状态响应码：在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
3. 缓存处理：在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
4. 带宽优化及网络连接的使用：HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接

HTTP1.1

• 默认使用长连接（connection:keep-alive）。解决了TCP复用问题，可以减少TCP的三次握手开销。
  • 指的是用同一个TCP连接来发送和接受多个http请求/应答，而不是为了每一个新的请求/应答打开新的TCP连接的方法。
  • 存在的问题：串行的文件传输，只能顺序传输；连接数上限，因为浏览器限制，浏览器发起的最大请求数为6，也就是服务器能承载的最高并发为50，当第51个人访问时，就需要等待前面某个请求处理完成。
• HTTP 1.1开始支持获取文件的部分内容，这支持了并行下载和断点续传。通过在Header的两个参数实现
  • 客户端请求的时候发送Range参数, 指定第一个字节的位置和最后一个字节的位置。服务端响应的参数是：Content-Range
  • 第一次请求，客户端发起一个get请求；服务器处理请求，返回文件内容以及相应的Header，包括Etag
  • 第二次请求（断点续传）：客户端发起get请求，同时发送if-range，这个if-range的值就是第一次请求中服务器返回的etag；服务器判断etag是否匹配，是则返回206，否则返回200
• HTTP/1.1 引入了更多的缓存控制策略
  • if-unmodified-since，其实就是和if-modified-since差不多的，常用来做判断断点续传的文件是否被修改过了。如果没有被修改，返回200；否则返回412预处理错误。
  • if-match
  • if-none-match
• HTTP 1.1开始有Host（域） 这个概念

HTTP/2.0

• HTTP/1.1 存在的问题
  • 不会压缩请求和响应的首部，导致不必要的网络流量
  • 不支持有效的资源优先级
  • 需要使用多个连接才能实现并发和缩短延迟
• HTTP/2.0 的特性有哪些？
  参考文章
  • 采用二进制格式而非文本格式，将所有传输的信息分割为更小的消息和帧（二进制帧）
  • 采用多路复用，而非有序并阻塞的，只需一个连接即可实现并行，多路复用允许单一的 HTTP/2 连接同时发起多重的请求-响应消息
  • 首部压缩，使用报头压缩，降低开销
  • 支持服务器推送。可以将响应主动"推送"到客户端缓存中（服务器可以对一个客户端请求发送多个响应，例如请求了 HTML，可以响应需要的 CSS 和 JavaScript）

Q: HTTP的缺点

• 通信使用明文（不加密），内容可能会被窃听
• 不验证通信方的身份，因此有可能遭遇伪装
• 无法证明报文的完整性，所以有可能已遭篡改

HTTP + 加密 + 认证 + 完整性保护 = HTTPS

• HTTPS 是身披 SSL 外壳的 HTTP，HTTPS 并非是应用层的一种协议。只是 HTTP 通信接口部分采用 SSL （Secure Socket Layer）和 TSL（Transport Layer Security） 协议代替而已
• HTTPS 采用混合加密机制：所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密
• SSL（安全套接字层）是一种标准的安全技术，用于在服务器和客户端之间建立加密连接。***L证书后，就可以建立此安全连接，具体的实现方式分为对称加密（共享公钥 DES）和非对称加密（公钥 + 密钥 RSA）
• TLS（Transport Layer Security）是SSL（Secure Sockets Layer）协议的升级版，TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。现在习惯将这个两个组合在一起称为SSL/TLS，只要知道它是一种用于加密的安全协议就好了。

Q：HTTPS连接过程

• 使用HTTPS是需要保证服务端配置正确了对应的安全证书

1. Client Hello 客户端发起HTTPS请求
   • TLS层协议包含了一个客户端生成的随机数 Random1，客户端支持的加密套件（Support Ciphers）和 SSL Version （客户端可用的版本号）等信息
2. Server Hello 服务端向客户端发送 Server Hello 消息，这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用哪些算法，另外还会生成一份随机数 Random2。
   • 注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。
3. Certificate 服务端返回公钥和CA证书（数字证书）到客户端
   • 该证书通常有两个目的：1. 身份验证；2. 证书中包含服务器的公钥，该公钥结合密码套件的密钥协商算法协商出预备主密钥
4. Server Key Exchange 该消息是有条件才发，例如，如果是DH算法，这里发送服务器使用的DH参数。RSA算法不需要这一步。它发送的条件是，如果证书包含的信息不足以进行密钥交换，那么必须发送该信息。
5. Server Hello Done ，服务器发送完上述信息之后，会立刻发送该信息，然后等到客户端的响应。该信息的主要作用有：
   • 服务端发送了足够的信息，接下来可以和客户端一起协商出预备主密钥
   • 客户端接收到该信息后，可以进行证书校验、协商密钥等步骤
6. Certificate Verify，客户端解析证书，客户端接收后会验证证书的安全性，验证通过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密 Random3 生成 PreMaster Key
7. Client Key Exchange ，上面客户端根据服务器传来的公钥生成了 PreMaster Key，Client Key Exchange 就是将这个 key 传给服务端，服务端再用自己的私钥解出这个 PreMaster Key 得到客户端生成的 Random3。至此，客户端和服务端都拥有 Random1 + Random2 + Random3，两边再根据同样的算法就可以生成一份秘钥，握手结束后的应用层数据都是使用这个秘钥进行对称加密。
   • Q：为什么要使用三个随机数呢？
   • 这是因为 SSL/TLS 握手过程的数据都是明文传输的，并且多个随机数种子来生成秘钥不容易被暴力破解出来。
8. Change Cipher Spec(Client)，这一步是客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了
   • 该信息用于告诉对方，我已经计算好需要使用的对称密钥了，我们接下来的通信都需要使用该密钥进行加密之后再发送。
   • 需要注意的是，发送该信息的一方并不知道对方是否已经计算出密钥。一般由客户端先行发送该信息
9. Finished 该信息是第一个由TLS记录层协议进行加密保护的信息，双方需要验证对方发送的Finished信息，保证协商的密钥是可用的，保证协商过程中，没有被篡改。验证该verify Data的内容，包括三部分的内容：
   • 主密钥
   • 标签，客户端的标签是client finished，服务端的标签是server finished
   • handshake_messages，包括了所有的握手协议信息
10. SSL加密建立

Q：Https中间被劫持会怎样？

• 什么是HTTPS劫持？
  • 在HTTPS劫持攻击（“中间人攻击”的一种类型）中，网络中的攻击者会伪装成一个网站（例如facebook.com），并且提供带有攻击者公钥的假证书。通常，攻击者无法让任何合法的CA来对一个不受攻击者控制的域名的证书进行签名，因此浏览器会检测并阻止这种攻击行为。
  • 但是，如果攻击者可以说服用户安装一个新CA的根证书到浏览器当中，浏览器就会信任攻击者提供的由这个合法CA签发的假证书。通过这些假证书，攻击者可以模仿任何网站，进而可以篡改网站内容、记录用户在网站上的操作或发表的内容等。
  • 因此，用户不应该安装根CA证书（受信任证书），因为这样就会将原本安全的通信暴露无遗，导致通信被劫持或篡改而不被用户所感知。
• 关于内容劫持：作为一个中间人，没有服务器私钥A，是不能解密客户端发送的内容的，如果没有客户端自己生成的密钥B，是不能解密客户端发过去的内容的，但是Https中间被劫持可能导致通信被劫持或篡改而不被用户所感知

Q: HTTP 和 HTTPS 的区别

• 端口 ：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。
• 安全性和资源消耗： HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是HTTPS 比HTTP耗费更多服务器资源。
  • 对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；
  • 非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。
    密
• 对称加密算法（私钥加密）
  有AES、DES、3DES、TDEA、Blowfish、RC4、RC5、IDEA等。加密使用的密钥和解密使用的密钥是同一个密钥。由于加密算法是公开的，若要保证安全性，密钥不能对外公开。通常用来加密消息体。

CSRF 跨站点请求伪造

• CSRF 跨站请求伪造（英语：Cross-site request forgery），是一种挟制用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法。如：
• 攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
• 大多数用户并不能保证：
  • 不能保证关闭浏览器了后，本地的Cookie立刻过期，上次的会话已经结束
  • 不能保证登录了一个网站后，不再打开一个tab页面并访问另外的网站

CSRF 的攻击类型

• GET类型的CSRF
  • GET类型的CSRF利用非常简单，只需要一个HTTP请求，一般会这样利用：在受害者访问含有这个img的页面后，浏览器会自动向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker发出一次HTTP请求。bank.example就会收到包含受害者登录信息的一次跨域请求

    <img src="http://bank.example/withdraw?amount=10000&for=hacker" > 

• POST类型的CSRF:
  • 这种类型的CSRF利用起来通常使用的是一个自动提交的表单，访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。POST类型的攻击通常比GET要求更加严格一点，但仍并不复杂。任何个人网站、博客，被黑客上传页面的网站都有可能是发起攻击的来源，后端接口不能将安全寄托在仅允许POST上面
• 链接类型的CSRF：
  • 这种需要用户点击链接才会触发。这种类型通常是在论坛中发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招，攻击者通常会以比较夸张的词语诱骗用户点击

CSRF的特点

• 攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生
• 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
• CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。

CSRF与 XSS 区别

• 通常来说 CSRF 是由 XSS 实现的，CSRF 时常也被称为 XSRF
• 本质上讲，XSS 是代码注入问题，CSRF 是 HTTP 问题，XSS 是内容没有过滤导致浏览器将攻击者的输入当代码执行。CSRF 则是因为浏览器在发送 HTTP 请求时候自动带上 cookie，而一般网站的 session 都存在 cookie里面(Token验证可以避免)

CSRF防御

• token；token 验证的 CSRF 防御机制是公认最合适的方案。但若网站同时存在 XSS 漏洞的时候，这个方法也是空谈
• 验证码；强制用户必须与应用进行交互，才能完成最终请求。此种方式能很好的遏制 csrf，但是用户体验比较差
• Referer check；请求来源限制，此种方法成本最低，但是并不能保证 100% 有效，因为服务器并不是什么时候都能取到 Referer，而且低版本的浏览器存在伪造 Referer 的风险

XSS攻击

• XSS全称cross-site scripting（跨站点脚本），是一种代码注入攻击，是当前 web 应用中最危险和最普遍的漏洞之一。攻击者向网页中注入恶意脚本，当用户浏览网页时，脚本就会执行，进而影响用户，比如关不完的网站、盗取用户的 cookie 信息从而伪装成用户去操作，危害数据安全。

XSS分类

• 反射型XSS（非持久性跨站攻击）
  • 利用网站某些页面会直接输出请求参数的特性，通过在url的请求参数包含恶意脚本，诱使用户点击嵌入恶意脚本的url链接执行恶意脚本以达到攻击的目的。目前有很多攻击者利用论坛、微博发布含有恶意脚本的URL就属于这种方式。
  • 比如访问链接：https://wqs.jd.com/index.html?content=alert(1) 页面当中执行了，document.getElementById("content").innerHTML = content; 然而这个content是参数传过来的，那么就触发了反射型 XSS
• 存储型XSS（持久性跨站攻击）
  • 通过表单输入（比如发布文章、回复评论等功能中）插入一些恶意脚本，并且提交到被攻击网站的服务器数据库中。当用户浏览指定网页时，恶意脚本从数据库中被加载到页面执行，QQ邮箱的早期版本就曾经被利用作为持久型跨站脚本攻击的平台。
  • 与反射型 XSS 相比，该类的攻击更具有危害性，因为它影响的不只是一个用户，而是大量用户，而且该种类型还可进行蠕虫传播。
• DOM Based XSS（基于 dom 的跨站点脚本攻击）
  • 通过前面两种类型的方式，注入的脚本是通过改变 DOM 来进行攻击的。采用该种方式有一个好处就是从源代码中不易被发现。
  • DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞

XSS攻击防范

• 产生xss攻击漏洞主要是因为服务器没有对用户输入进行编码和过滤。另一个原因是，这种攻击方法有很多变体，攻击的手法却不断翻新，要设计出一个能完全防御的XSS过滤器是非常困难的。
• 防范xss攻击的原则就是不相信用户输入的数据

1. HttpOnly
   • 将重要的cookie标记为http only, ，浏览器将禁止页面的 JavaScript 访问带有 HttpOly 属性的 Cookie。
   • HttpOnly 主要是为了解决 XSS 之后的 Cookie 劫持，使用 HttpOnly 有助于缓解 XSS 攻击，防止被窃取敏感的 Cookie信息，本质上不是为了解决 XSS。
2. 消毒
   • 在输入输出时对数据进行转义，比如<转义成<,这样脚本就运行不了了
   • 录入数据设置白名单，比如javaWeb项目，设置过滤器过滤特殊字符
   • 前端页面限制用户输入数据类型，比如用户输入完年龄后验证输入内容只能是数字
   • 过滤JS事件的标签，比如onclick、load等

欢迎各位小伙伴评论区留言，有待大佬指教~