网络面试知识点

HTTP

HTTP：超文本传输协议（HTTP，HyperText Transfer Protocol）是互联网上应用最为广泛的一种网络协议。HTTP 协议是以明文方式发送信息，如果黑客截取了 Web 浏览器和服务器之间的传输报文，就可以直接获得其中的信息。

队头阻塞/多路复用

在 HTTP/1 中，为了性能考虑，我们会引入雪碧图、将小图内联、使用多个域名等等的方式。这一切都是因为浏览器限制了同一个域名下的请求数量（Chrome 下一般是限制六个连接），当页面中需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求数量时，剩余的资源需要等待其他资源请求完成后才能发起请求。

在 HTTP/2 中引入了多路复用的技术，同一域名下只需要一个 TCP 连接就可以传输所有的请求数据。多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题，同时也接更容易实现全速传输，毕竟新开一个 TCP 连接都需要慢慢提升传输速度。

TCP 是个面向连接的协议，即发送请求后需要收到 ACK 消息，以确认对方已接收到数据。如果每次请求都要在收到上次请求的 ACK 消息后再请求，那么效率无疑很低。后来 HTTP/1.1 提出了 Pipelining 技术，允许一个 TCP 连接同时发送多个请求，这样就大大提升了传输效率。

在这个背景下，下面就来谈 HTTP/1.1 的队头阻塞。下图中，一个 TCP 连接同时传输 10 个请求，其中第 1、2、3 个请求已被客户端接收，但第 4 个请求丢失，那么后面第 5 - 10 个请求都被阻塞，需要等第 4 个请求处理完毕才能被处理，这样就浪费了带宽资源。

因此，HTTP 一般又允许每个主机建立 6 个 TCP 连接，这样可以更加充分地利用带宽资源，但每个连接中队头阻塞的问题还是存在。

在之前的 HTTP 版本中，我们是通过文本的方式传输数据。在 HTTP/2 中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码。

HTTP/2 的多路复用解决了上述的队头阻塞问题。不像 HTTP/1.1 中只有上一个请求的所有数据包被传输完毕下一个请求的数据包才可以被传输，HTTP/2 中每个请求都被拆分成多个 Frame 通过一条 TCP 连接同时被传输，这样即使一个请求被阻塞，也不会影响其他的请求。如下图所示，不同颜色代表不同的请求，相同颜色的色块代表请求被切分的 Frame。

HTTP/2 的每个请求都会被拆分成多个 Frame，不同请求的 Frame 组合成 Stream，Stream 是 TCP 上的逻辑传输单元，这样 HTTP/2 就达到了一条连接同时发送多条请求的目标，这就是多路复用的原理。我们看一个例子，在一条 TCP 连接上同时发送 4 个 Stream，其中 Stream1 已正确送达，Stream2 中的第 3 个 Frame 丢失，TCP 处理数据时有严格的前后顺序，先发送的 Frame 要先被处理，这样就会要求发送方重新发送第 3 个 Frame，Stream3 和 Stream4 虽然已到达但却不能被处理，那么这时整条连接都被阻塞。所以HTTP/2 虽然可以解决“请求”这个粒度的阻塞，但 HTTP/2 的基础 TCP 协议本身却也存在着队头阻塞的问题。

因为 HTTP/2 使用了多路复用，一般来说同一域名下只需要使用一个 TCP 连接。当这个连接中出现了丢包的情况，那就会导致 HTTP/2 的表现情况反倒不如 HTTP/1 了。

因为在出现丢包的情况下，整个 TCP 都要开始等待重传，也就导致了后面的所有数据都被阻塞了。但是对于 HTTP/1 来说，可以开启多个 TCP 连接，出现这种情况反到只会影响其中一个连接，剩余的 TCP 连接还可以正常传输数据。

那么可能就会有人考虑到去修改 TCP 协议，其实这已经是一件不可能完成的任务了。因为 TCP 存在的时间实在太长，已经充斥在各种设备中，并且这个协议是由操作系统实现的，更新起来不大现实。

基于这个原因，Google 就更起炉灶搞了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上，当然 HTTP/3 之前名为 HTTP-over-QUIC。

参考文章
HTTP/3 来了！未来可期

HTTPS

HTTPS是在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版。

HTTPS协议的主要作用：
1）一种是建立一个信息安全通道，来保证数据传输的安全；
2）另一种就是确认网站的真实性。

HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL/TLS协议代替而已。

通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。简言之，所谓HTTPS，其实就是身披SSL协议这层外壳的HTTP。

在 TLS 中使用了两种加密技术，分别为：对称加密和非对称加密。

对称加密：对称加密就是两边拥有相同的秘钥，两边都知道如何将密文加密解密。

这种加密方式固然很好，但是问题就在于由于传输数据都是走的网络，如果将秘钥通过网络的方式传递的话，一旦秘钥被截获就没有加密的意义的。

非对称加密：有公钥私钥之分，公钥所有人都可以知道，可以将数据用公钥加密，但是将数据解密必须使用私钥解密，私钥只有分发公钥的一方才知道。

这种加密方式就可以完美解决对称加密存在的问题。假设现在两端需要使用对称加密，那么在这之前，可以先使用非对称加密交换秘钥。

简单流程如下：首先服务端将公钥公布出去，那么客户端也就知道公钥了。接下来客户端创建一个秘钥，然后通过公钥加密并发送给服务端，服务端接收到密文以后通过私钥解密出正确的秘钥，这时候两端就都知道秘钥是什么了。

HTTPS优缺点

优点：

使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

缺点：

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

HTTP和HTTPS区别

HTTP 的连接很简单，是无状态的。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。
HTTPS比HTTP更加安全，对搜索引擎更友好，利于SEO,谷歌、百度优先索引HTTPS网页;
HTTPS需要用到ca的SSL证书，而HTTP不用;
HTTPS标准端口443，HTTP标准端口80;
HTTPS基于传输层，HTTP基于应用层;
HTTPS在浏览器显示绿色安全锁，HTTP没有显示;

http状态码

客户端的每一次请求，服务器都必须给出回应。回应包括 HTTP 状态码和数据两部分。

HTTP 状态码就是一个三位数，分成五个类别。

1xx：相关信息
2xx：操作成功
3xx：重定向
4xx：客户端错误
5xx：服务器错误

这五大类总共包含100多种状态码，覆盖了绝大部分可能遇到的情况。每一种状态码都有标准的（或者约定的）解释，客户端只需查看状态码，就可以判断出发生了什么情况，所以服务器应该返回尽可能精确的状态码。

API 不需要1xx状态码，下面介绍其他四类状态码的精确含义。

2XX状态码

200状态码表示操作成功，但是不同的方法可以返回更精确的状态码。

GET: 200 OK
POST: 201 Created
PUT: 200 OK
PATCH: 200 OK
DELETE: 204 No Content

POST返回201状态码，表示生成了新的资源；DELETE返回204状态码，表示资源已经不存在。

此外，202 Accepted状态码表示服务器已经收到请求，但还未进行处理，会在未来再处理，通常用于异步操作。下面是一个例子。

HTTP/1.1 202 Accepted

{
  "task": {
    "href": "/api/company/job-management/jobs/2130040",
    "id": "2130040"
  }
}

3xx 状态码

API 用不到301状态码（永久重定向）和302状态码（暂时重定向，307也是这个含义），因为它们可以由应用级别返回，浏览器会直接跳转，API 级别可以不考虑这两种情况。

API 用到的3xx状态码，主要是303 See Other，表示参考另一个 URL。它与302和307的含义一样，也是"暂时重定向"，区别在于302和307用于GET请求，而303用于POST、PUT和DELETE请求。收到303以后，浏览器不会自动跳转，而会让用户自己决定下一步怎么办。

下面是一个例子。

HTTP/1.1 303 See Other
Location: /api/orders/12345

4xx 状态码

4xx状态码表示客户端错误，主要有下面几种。

400 Bad Request：服务器不理解客户端的请求，未做任何处理。
401 Unauthorized：用户未提供身份验证凭据，或者没有通过身份验证。
403 Forbidden：用户通过了身份验证，但是不具有访问资源所需的权限。
404 Not Found：所请求的资源不存在，或不可用。
405 Method Not Allowed：用户已经通过身份验证，但是所用的 HTTP 方法不在他的权限之内。
410 Gone：所请求的资源已从这个地址转移，不再可用。
415 Unsupported Media Type：客户端要求的返回格式不支持。比如，API 只能返回 JSON 格式，但是客户端要求返回 XML 格式。
422 Unprocessable Entity ：客户端上传的附件无法处理，导致请求失败。
429 Too Many Requests：客户端的请求次数超过限额。

5xx 状态码

5xx状态码表示服务端错误。一般来说，API 不会向用户透露服务器的详细信息，所以只要两个状态码就够了。

500 Internal Server Error：客户端请求有效，服务器处理时发生了意外。
503 Service Unavailable：服务器无法处理请求，一般用于网站维护状态。

TCP可靠性保证机制

检验和
序列号
确认应答机制（ACK）
超时重传机制
连接管理机制（三次握手四次挥手）
流量控制
拥塞控制

相关文章
TCP可靠性的保证机制总结

浏览从输入网址到回车发生了什么

当用户访问页面时，浏览器需要获取用户请求内容，这个过程主要涉及浏览器网络模块：

首先会进行 url 解析，根据 dns 服务器根据输入的域名查找对应IP，然后向该IP地址发起请求；
浏览器根据缓存策略获得并解析服务器的返回内容(HTTP response)；
浏览器加载HTML文件及文件内包含的外部引用文件及图片，多媒体等资源。

通过网络模块加载到HTML文件后渲染引擎渲染流程如下，这也通常被称作关键渲染路径（Critical Rendering Path）：

构建DOM树(DOM tree)：通过解析HTML的词法和语法分析器（入栈出栈）生成DOM树，字节数据（0和1组成）-> 字符串（我们的代码） -> token（词法分析，开始标签，结束标签，标签内的内容） ->Node->dom
构建CSSOM(CSS Object Model)树：解析样式生成CSSOM规则树，解析过程跟DOM树类似，如果css样式嵌套过多将会消耗性能。
执行JavaScript：加载并执行JavaScript代码（包括内联代码或外联JavaScript文件），执行时变量的赋值主要是使用内存空间，方法的执行主要是入栈出栈，会涉及作用域，原型链，event loop，垃圾回收机制，还可能会操作dom，浏览器线程切换等等
构建渲染树(render tree)：将DOM树和CSSOM规则树合并生成渲染树（渲染树：按顺序展示在屏幕上的一系列矩形，这些矩形带有字体，颜色和尺寸等视觉属性）
布局（layout）：遍历渲染树开始布局，计算每个节点的位置大小等信息
绘制（painting）：把每一个元素对应的盒变成位图，将渲染树每个节点绘制到屏幕，渲染时可能会引起重绘和回流

上面的步骤并不是一次性执行完成，例如DOM或者CSSOM被修改时，就会有某个过程需要被重复执行，重新计算并重新渲染。实际上，由于JS跟css的操作会多次修改DOM跟CSSOM。

前端安全（CSRF、XSS）

XSS

XSS，即 Cross Site Script，中译是跨站脚本攻击；其原本缩写是 CSS，但为了和层叠样式表(Cascading Style Sheet)有所区分，因而在安全领域叫做 XSS。

XSS 攻击是指攻击者在网站上注入恶意的客户端代码，通过恶意脚本对客户端网页进行篡改，从而在用户浏览网页时，对用户浏览器进行控制或者获取用户隐私数据的一种攻击方式。

攻击者对客户端网页注入的恶意脚本一般包括 JavaScript，有时也会包含 HTML 和 Flash。有很多种方式进行 XSS 攻击，但它们的共同点为：将一些隐私数据像 cookie、session 发送给攻击者，将受害者重定向到一个由攻击者控制的网站，在受害者的机器上进行一些恶意操作。

XSS攻击可以分为3类：反射型（非持久型）、存储型（持久型）、基于DOM。

反射型

反射型 XSS 只是简单地把用户输入的数据 “反射” 给浏览器，这种攻击方式往往需要攻击者诱使用户点击一个恶意链接，或者提交一个表单，或者进入一个恶意网站时，注入脚本进入被攻击者的网站。

存储型

存储型 XSS 会把用户输入的数据 “存储” 在服务器端，当浏览器请求数据时，脚本从服务器上传回并执行。这种 XSS 攻击具有很强的稳定性。

比较常见的一个场景是攻击者在社区或论坛上写下一篇包含恶意 JavaScript 代码的文章或评论，文章或评论发表后，所有访问该文章或评论的用户，都会在他们的浏览器中执行这段恶意的 JavaScript 代码。

基于DOM

基于 DOM 的 XSS 攻击是指通过恶意脚本修改页面的 DOM 结构，是纯粹发生在客户端的攻击

CSRF

CSRF，即 Cross Site Request Forgery，中译是跨站请求伪造，是一种劫持受信任用户向服务器发送非预期请求的攻击方式。

通常情况下，CSRF 攻击是攻击者借助受害者的 Cookie 骗取服务器的信任，可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器，从而在并未授权的情况下执行在权限保护之下的操作。

防范

防御 XSS 攻击
- HttpOnly 防止劫取 Cookie
- 用户的输入检查
- 服务端的输出检查
防御 CSRF 攻击
- 验证码
- Referer Check
- Token 验证

前端跨域

浏览器的同源策略安全机制导致了跨域，容易有CSRF攻击。

跨域解决方案：

JSONP，script 标签是不受同源策略的限制的，它可以载入任意地方的 JavaScript 文件，而并不要求同源。
document.domain，这种方式只适合主域名相同，但子域名不同的iframe跨域。比如主域名是http://crossdomain.com:9099，子域名是http://child.crossdomain.com:9099，这种情况下给两个页面指定一下document.domain即document.domain = crossdomain.com就可以访问各自的window对象了。
CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）跨域资源共享 CORS 详解。
Nginx代理配置

cdn加速

简单的来说就是原服务器上数据复制到其他服务器上，用户访问时，那台服务器近访问到的就是那台服务器上的数据。

CDN加速优点是成本低，速度快。可以用CDN best的CDN进行加速，免费，可部署私有，公有CDN系统。可以实现宕机检测，自动切换ip，分线路，分组解析。也就是CDN加速的主要作用就是保证网站的正常访问，及加快网站访问速度和响应速度，防止网站因黑客攻击，DNS解析劫持故障等导致的网站服务器的宕机状况的出现。

负载均衡

垂直扩展

随着系统访问量的增加，在不新增服务器的情况下，可以通过提升单机硬件配置来做负载均衡（可从cpu、内存、硬盘，网卡等方面提升），但是垂直扩展会带来成本问题…

在早期时候，价格不变时，每隔一到两年技术会革新，性能会翻一倍，即摩尔定律：

当价格不变时，集成电路上可容纳的元器件数目，约每隔18-24个月便会增加一倍，性能也将提升一倍。
换言之，每一美元所能买到的电脑性能，将每隔18-24个月翻一倍以上。

当技术已经达到瓶颈，提升电脑性能的消耗的成本将越来越高，所以摩尔定律已经放缓。因此单机扩展性能提高是有限的，而且成本会越来越高

水平扩展

目前在高并发高可用系统架构中，最优方案还是水平扩展。理论上，在系统能支持水平扩展的前提下，增加服务器数量，部署更多机器集群，能带来无限的性能提升。

Nginx

Nginx 是一个高性能的WEB服务器和反向代理服务，最常用的软件负载均衡器，属于第七层应用层协议。

核心概念：用户请求先到Nginx，再由Ngix转发请求到后面的应用服务器（如：node）

一般做到10W 并发，因为http请求的处理包括解析和封装Http 内容，要处理更多请求，需要更多内存、CPU等资源。

如果面临几十万并发量，可以使用Ngix集群，则需要LVS负责转发给 Ngix 集群机器

LVS

LVS（Linux Virtual Server），Linux 虚拟服务器，中国人开发，目前绝大部分Linux 发行版，都集成在内核了。实现基于第四层（传输层）的软件负载均衡方案。支持10W～50W 并发量。

为了方便理解，初学者可认为安装使用了LVS的Linux服务器，等于快递中转。

核心理念：原本是请求LVS服务器的数据包，被LVS软件篡改了数据包的目的地，将流量转移到了Ngix所在的机器IP，从而实现负载均衡。

为什么说LVS比Nigx快？
网络层第四层使用的协议（如TCP）内容比Http简单，解析和组装所消耗的CPU、内存等资源比Nigx要低。

硬件设备F5

F5是实现第四层（传输层）交换的一款产品，属于硬交换，价格贵性能好

服务端上限

Nginx 支撑1W～10W并发
LVS 支撑10W～50W并发
F5 支撑200W～1000W并发