计网+HTTP+浏览器+网络安全面试题总结

总结了最近的一些面试题和之前的知识点

计网+HTTP (常问+掌握)

说到 HTTP，不得不提的就是 TCP/IP 网络模型，一般是五层模型。如下图所示
但是也可以分为四层，就是把链路层和物理层都表示为网络接口层
TCP/IP网络模型
还有一种就是 OSI 七层网络模型，它就是在五层协议之上加了表示层和会话层

从输入URL到浏览器显示页面过程中都发生了什么

浏览器根据请求的url交给DNS域名解析
发起TCP连接（三次握手）
发送HTTP请求
服务器处理请求并返回HTTP报文
浏览器解析渲染页面
连接结束。（Tcp四次挥手）

从输入URL到浏览器显示页面过程中都发生了什么

什么是浏览器的同源政策？

我对浏览器的同源政策的理解是，一个域下的 js 脚本在未经允许的情况下，不能够访问另一个域的内容。这里的同源的指的是两个域的 协议、域名、端口号必须相同，否则不属于同一个域。
同源政策主要限制了三个方面

第一个是当前域下的 js 脚本不能够访问其他域下的 cookie、localStorage 和 indexDB。
第二个是当前域下的 js 脚本不能够操作访问操作其他域下的 DOM。
第三个是当前域下 ajax 无法发送跨域请求。

同源政策的目的主要是为了保证用户的信息安全，它只是对 js 脚本的一种限制，并不是对浏览器的限制，对于一般的 img、或者script 脚本请求都不会有跨域的限制，这是因为这些操作都不会通过响应结果来进行可能出现安全问题的操作。
举例来说，http://www.example.com/dir/page.html这个网址，协议是http://，域名是www.example.com，端口是80（默认端口可以省略）。

跨域怎么实现？jsonp的原理是什么？

跨域，指的是浏览器不能执行其他网站的脚本。浏览器执行javascript脚本时，会检查这个脚本属于哪个页面，如果不是同源页面，就不会被执行

解决办法：

JSONP：注意JSONP只支持GET请求，不支持POST请求。
原理：ajax请求受同源策略影响，不允许进行跨域请求，而script标签src属性中的链接却可以访问跨域的js脚本，利用这个特性，服务端不再返回JSON格式的数据，而是返回一段调用某个函数的js代码，在src中进行了调用，这样实现了跨域。 — callback
代理：写后端接口，在后端调用页面拿到返回值返回给html文件。相当于绕过了浏览器，就不会存在跨域问题。例；(nigx反向代理)
CORS CORS(Cross-origin resource sharing)跨域资源共享服务器设置对CORS的支持原理：服务器设置Access-Control-Allow-Origin HTTP响应头之后，浏览器将会允许跨域请求

1 2	`header('Access-Control-Allow-Origin:*');//允许所有来源访问 header('Access-Control-Allow-Method:POST,GET');//允许访问的方式`

proxy代理目前常用方式,通过服务器设置代理 在 vue.config.js 项目中配置 proxy 解决跨域问题
window.postMessage() 利用h5新特性window.postMessage()

Options(CORS跨域，非简单请求)

1.HTTP的options方法作用

检测服务器所支持的请求方法。（比如：‘／user’路由支持哪些方法：get、post、delete…）
CORS中的预检请求（检测某个接口是否支持跨域）

2.allowedMethods方法
响应options方法，告诉它所支持的请求方法
相应的返回405（不允许）和501（没实现）（比如我使用delete，会返回405，因为我没有写这个接口。但我使用link接口请求，会返回501，因为koa里不支持link请求）
options 请求就是预检请求，可用于检测服务器允许的 http 方法。当发起跨域请求时，由于安全原因，触发一定条件时浏览器会在正式请求之前自动先发起 OPTIONS 请求，即 CORS 预检请求，服务器若接受该跨域请求，浏览器才继续发起正式请求。
MDN

浏览器会拦截跨域请求，但是只是拦截返回结果，请求还是会被发送到服务器，这样有意义么

有意义。
首先，请求因为跨域被拦截后，会改成OPTIONS请求送达服务器，这样服务器就可以知道有人在请求。
至于你说跨域POST也能修改，那因为服务器没对method进行校验，来者不拒，这是你服务器的问题。
正常的API数据操作method不包括OPTIONS，OPTIONS只用来确认允许的操作。

常见的状态码

仅记录在 RFC2616 上的 HTTP 状态码就达 40 种，若再加上 WebDAV（RFC4918、5842）和附加 HTTP 状态码（RFC6585）等扩展，数量就达 60 余种。接下来，我们就介绍一下这些具有代表性的一些状态码。
1xx: 指示信息——表示请求已接收，继续处理
2xx: 成功——表示请求已被成功接收
3xx: 重定向——表示要完成请求必须进行进一步操作
4xx: 客户端错误——表示请求有语法错误或请求无法实现
5xx: 服务端错误——表示服务器未能实现合法的请求

常见状态码

状态码描述
200 请求成功 （强缓存也是返回这个）
201 Created 资源创建成功，多用于 POST 请求
202-服务器端已经收到请求消息，但是尚未进行处理
204 只有响应头，没有body数据（无内容）预检请求
206 已完成指定范围的请求(带Range头的GET请求),场景如video,audio播放文件较大,文件分片时
301 永久重定向永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302 临时重定向与301类似。但资源只是临时被移动。客户端应继续使用原有URI
304 请求资源未修改，可以使用缓存的资源，不用在服务器取 （协商缓存）
400 请求有语法错误
401 没有权限访问
403 服务器拒绝执行请求，场景如不允许直接访问，只能通过服务器访问时
404 请求资源不存在
500 服务器内部错误，无法完成请求
503 请求未完成，因服务器过载、宕机或维护等
《HTTP 状态码》

HTTP 和 HTTPS 的主要区别是什么呢？

最简单的，HTTP 在地址栏上的协议是以 http:// 开头，而 HTTPS 在地址栏上的协议是以 https:// 开头

1 2	`http://pengzhenglong.github.io/ https://pengzhenglong.github.io/`

HTTP 是未经安全加密的协议，它的传输过程容易被攻击者监听、数据容易被窃取、发送方和接收方容易被伪造；而 HTTPS 是安全的协议，它通过密钥交换算法 - 签名算法 - 对称加密算法 - 摘要算法能够解决上面这些问题。
HTTP 的默认端口是 80，而 HTTPS 的默认端口是 443。
http 是超文本传输协议，信息是明文传输，HTTPS 协议要比 http 协议安全，https 是具有安全性的 ssl 加密传输协议，可防止数据在传输过程中被窃取、改变，确保数据的完整性(当然这种安全性并非绝对的，对于更深入的 Web 安全问题，此处暂且不表)。
http 的连接很简单，是无状态的。https 握手阶段比较费时，会使页面加载时间延长 50%，增加 10%~20%的耗电。
https 缓存不如 http 高效，会增加数据开销。
Https 协议需要ca 证书，费用较高，功能越强大的证书费用越高。
SSL 证书需要绑定 IP，不能再同一个 IP 上绑定多个域名，IPV4 资源支持不了这种消耗。

HTTPS是如何保证安全的？

过程比较复杂，我们得先理解两个概念

1. 对称加密：即通信的双方都使用同一个秘钥进行加解密，比如特务接头的暗号，就属于对称加密

对称加密虽然很简单性能也好，但是无法解决首次把秘钥发给对方的问题，很容易被hacker拦截秘钥。

2. 非对称加密

私钥 + 公钥= 密钥对
即用私钥加密的数据,只有对应的公钥才能解密,用公钥加密的数据,只有对应的私钥才能解密
因为通信双方的手里都有一套自己的密钥对,通信之前双方会先把自己的公钥都先发给对方
然后对方再拿着这个公钥来加密数据响应给对方,等到到了对方那里,对方再用自己的私钥进行解密

非对称加密虽然安全性更高，但是带来的问题就是速度很慢(要等拿到公钥再解开)，影响性能。
解决方案：

那么结合两种加密方式，将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。

此时又带来一个问题，中间人问题：

如果此时在客户端和服务器之间存在一个中间人,这个中间人只需要把原本双方通信互发的公钥,换成自己的公钥,这样中间人就可以轻松解密通信双方所发送的所有数据。

所以这个时候需要一个安全的第三方颁发证书（CA），证明身份的身份，防止被中间人攻击。

证书中包括：签发者、证书用途、使用者公钥、使用者私钥、使用者的HASH算法、证书到期时间等

但是问题来了，如果中间人篡改了证书，那么身份证明是不是就无效了？这个证明就白买了，这个时候需要一个新的技术，数字签名。

数字签名就是用CA自带的HASH算法对证书的内容进行HASH得到一个摘要，再用CA的私钥加密，最终组成数字签名。
当别人把他的证书发过来的时候,我再用同样的Hash算法,再次生成消息摘要，然后用CA的公钥对数字签名解密,得到CA创建的消息摘要,两者一比,就知道中间有没有被人篡改了。
这个时候就能最大程度保证通信的安全了。

TCP和UDP的区别

TCP是面向链接的，而UDP是面向无连接的。
TCP仅支持单播传输，UDP 提供了单播，多播，广播的功能。
TCP的三次握手保证了连接的可靠性; UDP是无连接的、不可靠的一种数据传输协议，首先不可靠性体现在无连接上，通信都不需要建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收。
UDP的头部开销比TCP的更小，数据传输速率更高，实时性更好。(UDP 的头部开销小，只有八字节，相比 TCP 的至少二十字节要少得多，在传输数据报文时是很高效的)

TCP 和 UDP 应用场景

UDP的应用场景：即时通信。面向数据报方式；网络数据大多为短消息；拥有大量客户端；对数据安全性无特殊要求；网络负担重但对响应速度要求高的场景。eg: IP电话、实时视频会议等。
TCP的应用场景：对数据准确性要求高，速度可以相对较慢的。eg: 文件传输、邮件的发送与接收等。
传送门 ☞# 深度剖析TCP与UDP的区别
 博客

相同点(存储在客户端)

不同点

cookie数据大小不能超过4k；sessionStorage和localStorage的存储比cookie大得多，可以达到5M+
cookie设置的过期时间之前一直有效；localStorage永久存储，浏览器关闭后数据不丢失除非主动删除数据；sessionStorage数据在当前浏览器窗口关闭后自动删除
cookie的数据会自动的传递到服务器；sessionStorage和localStorage数据保存在本地

localStorage和SessionStorage

只能存储字符串对象
不同浏览器无法共享localStorage与SessionStroage中的信息。相同浏览器的不同页面间（同源页面）可以共享相同的localStorage，但不能共享sessionStorage。

cookie 的大小一般被浏览器限制为 4kb
请求自动携带 cookie 其实会造成无效的带宽浪费
安全问题（csrf 与 xss）

CORS解决带cookie跨域问题（如果您想在使用 CORS（可以识别发送者）时发送 cookie，您需要向请求和响应添加额外的标头。）

知乎

2. Session

Session是一种服务端解决方案，通过服务器来保持状态。
Session是服务器为了保存用户状态而创建的一个特殊对象。客户端请求服务端，服务端会为这次请示开辟一块内存空间。
Session弥补了HTTP的无状态特性。

Session的创建过程

当浏览器第一次访问服务器时，服务器会创建一个Session对象(该对象有唯一的ID，即SessionID)。服务器会将SessionID以cookie的方式返回浏览器。
当浏览器再次访问服务器时，会将SessionID发送过来，服务器依据sessionID就可以找到对应的session对象。

Session的缺点

A 服务器存储了 Session，就是做了负载均衡后，假如一段时间内 A 的访问量激增，会转发到 B 进行访问，但是 B 服务器并没有存储 A 的 Session，会导致 Session 的失效。

博客
 JavaScript的存储–Cookie、Session、localStorage、sessionStorage

什么是 Token（令牌）

Acesss Token

访问资源接口（API）时所需要的资源凭证
简单 token 的组成：uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token 的前几位以哈希算法压缩成的一定长度的十六进制字符串）

特点：(1. 服务端无状态化、可扩展性好2. 支持移动端设备3. 安全4. 支持跨程序调用)

每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里
基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库
token 完全由应用管理，所以它可以避开同源策略

Refresh Token

另外一种 token——refresh token
refresh token 是专用于刷新 access token 的 token。如果没有 refresh token，也可以刷新 access token，但每次刷新都要用户输入登录用户名与密码，会很麻烦。有了 refresh token，可以减少这个麻烦，客户端直接用 refresh token 去更新 access token，无需用户进行额外的操作。
Acesss Token

Ajax 是什么? 如何创建一个 Ajax？

Gmail开发人员发现IE里面有个XMLHTTPRequest对象来请求数据时，可以实现无刷新数据请求，所以使用这个特性，进行网络数据请求，这就是AJAX的由来。
AJAX不是一个单词，他的全称是Asynchronous JavaScript and XML，就是异步的JavaScript和XML，它是一套用于创建快速动态网页的技术标准，使用步骤如下：

创建异步XMLHttpRequest对象
设置请求参数，包括请求的方法和URL等
发送请求
注册事件，事件状态变更会及时响应监听
在监听里面获取并处理返回数据

//创建 XMLHttpRequest 对象
var ajax = new XMLHttpRequest();
//规定请求的类型、URL 以及是否异步处理请求。
ajax.open('GET',url,true);
//发送信息至服务器时内容编码类型
ajax.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); 
//发送请求
ajax.send(null);  
//接受服务器响应数据
ajax.onreadystatechange = function () {
    if (obj.readyState == 4 && (obj.status == 200 || obj.status == 304)) { 
    }
};

所以AJAX的核心就是XMLHttpRequest对象，这是一个非常早的实现方法，也是兼容性最好的，已经成为了浏览器标准，虽然我们现在都使用其它的API规范，但对象名字暂时还是用XML命名

博客

axios

axios是一个基于Promise的HTTP库，可以用在浏览器和node.js中，它底层还是基于XMLHttpRequest对象的，你可以认为它是一个方便的封装库，除了基础请求数据，它还增加了如下功能：

对PromiseAPI的支持
支持请求拦截和响应、转换请求数据和响应数据、取消请求
可以自动转换JSON数据
支持防御XSRF

fetch

fetch就不是XMLHttpRequest对象了，fetch是原生的js对象，也就是说，它不依赖浏览器，fetch提供了一个理解的请求替换方案，可以提供给其它技术使用。我们主要需要了解下fetch和ajax的本质区别：

fetch返回的是Promise，所以如果HTTP状态码是404之类的，fetch也是成功返回的，只有在网络连接错误的情况下，才会reject
fetch不发送cookies

fetch的请求写法会比AJAX简单许多，但我想，最主要的问题是，无法区分HTTP状态码了，这个在编程时还是比较常用的，所以我们目前还是使用axios比较多，而很少使用fetch
Ajax

HTTP2相对于HTTP1.x有什么优势和特点？

二进制分帧

帧：HTTP/2 数据通信的最小单位消息：指 HTTP/2 中逻辑上的 HTTP 消息。例如请求和响应等，消息由一个或多个帧组成。
流：存在于连接中的一个虚拟通道。流可以承载双向消息，每个流都有一个唯一的整数ID
HTTP/2 采用二进制格式传输数据，而非 HTTP 1.x 的文本格式，二进制协议解析起来更高效。

服务器推送

服务端可以在发送页面HTML时主动推送其它资源，而不用等到浏览器解析到相应位置，发起请求再响应。例如服务端可以主动把JS和CSS文件推送给客户端，而不需要客户端解析HTML时再发送这些请求。

服务端可以主动推送，客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略，服务器不会随便推送第三方资源给客户端。

头部压缩

HTTP/1.x会在请求和响应中中重复地携带不常改变的、冗长的头部数据，给网络带来额外的负担。

HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送
首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新;
每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值。

你可以理解为只发送差异数据，而不是全部发送，从而减少头部的信息量

多路复用

HTTP 1.x 中，如果想并发多个请求，必须使用多个 TCP 链接，且浏览器为了控制资源，还会对单个域名有 6-8个的TCP链接请求限制。
HTTP2中：
同域名下所有通信都在单个连接上完成。单个连接可以承载任意数量的双向数据流。
数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装（保证后端接收后返回数据正常）

浏览器的缓存机制强制缓存 && 协商缓存

浏览器与服务器通信的方式为应答模式，即是：浏览器发起HTTP请求 – 服务器响应该请求。那么浏览器第一次向服务器发起该请求后拿到请求结果，会根据响应报文中HTTP头的缓存标识，决定是否缓存结果，是则将请求结果和缓存标识存入浏览器缓存中，简单的过程如下图：

由上图我们可以知道：

浏览器每次发起请求，都会先在浏览器缓存中查找该请求的结果以及缓存标识
浏览器每次拿到返回的请求结果都会将该结果和缓存标识存入浏览器缓存中

以上两点结论就是浏览器缓存机制的关键，他确保了每个请求的缓存存入与读取，只要我们再理解浏览器缓存的使用规则，那么所有的问题就迎刃而解了。为了方便理解，这里根据是否需要向服务器重新发起HTTP请求将缓存过程分为两个部分，分别是强制缓存和协商缓存。

强制缓存强制缓存就是向浏览器缓存查找该请求结果，并根据该结果的缓存规则来决定是否使用该缓存结果的过程

当浏览器向服务器发起请求时，服务器会将缓存规则放入HTTP响应报文的HTTP头中和请求结果一起返回给浏览器，控制强制缓存的字段分别是 Expires 和 Cache-Control，其中Cache-Control优先级比Expires高。强制缓存的情况主要有三种(暂不分析协商缓存过程)，如下： 状态仍然返回200，但不会请求数据，在浏览器中能明显看到from cache字样。

不存在该缓存结果和缓存标识，强制缓存失效，则直接向服务器发起请求（跟第一次发起请求一致）。
存在该缓存结果和缓存标识，但该结果已失效，强制缓存失效，则使用协商缓存。
存在该缓存结果和缓存标识，且该结果尚未失效，强制缓存生效，直接返回该结果

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

Etag >Last-Modifie Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304
同样，协商缓存的标识也是在响应报文的HTTP头中和请求结果一起返回给浏览器的，控制协商缓存的字段分别有：Last-Modified / If-Modified-Since 和 Etag / If-None-Match，其中Etag / If-None-Match的优先级比Last-Modified / If-Modified-Since高。协商缓存主要有以下两种情况：

协商缓存生效，返回304
协商缓存失效，返回200和请求结果结果
传送门 ☞ #彻底理解浏览器的缓存机制

介绍下304过程

a. 浏览器请求资源时首先命中资源的Expires 和 Cache-Control，Expires 受限于本地时间，如果修改了本地时间，可能会造成缓存失效，可以通过Cache-control: max-age指定最大生命周期，状态仍然返回200，但不会请求数据，在浏览器中能明显看到from cache字样。
b. 强缓存失效，进入协商缓存阶段，首先验证ETagETag可以保证每一个资源是唯一的，资源变化都会导致ETag变化。服务器根据客户端上送的If-None-Match值来判断是否命中缓存。
c. 协商缓存Last-Modify/If-Modify-Since阶段，客户端第一次请求资源时，服务服返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间。再次请求该资源时，request的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存。

TCP三次握手

第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次握手：服务器收到syn包并确认客户的SYN（ack=j+1），同时也发送一个自己的SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。

目的：建立可靠的通信通道，数据的发送和接收（双方正常）

翻译成大白话就是：客户端：你能接收到我的消息吗？服务端：可以的，那你能接收到我的回复吗？客户端：可以，那我们开始聊正事吧。

为什么是3次？：避免历史连接，确认客户端发来的请求是这次通信的人为什么不是4次？：3次够了第四次浪费

三次握手过程中可以携带数据吗？

其实第三次握手的时候，是可以携带数据的。但是，第一次、第二次握手不可以携带数据
为什么这样呢?大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。

也就是说，第一次握手不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

SYN攻击是什么？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击。
netstat -n -p TCP | grep SYN_RECV
常见的防御 SYN 攻击的方法有如下几种：

缩短超时（SYN Timeout）时间
增加最大半连接数
过滤网关防护
SYN cookies技术

TCP 协议四次挥手

客户端-发送一个FIN,用来关闭客户端到服务器的数据传输
服务器-收到这个FIN,它发回一个ACK，确认序号为收到的序号加1.和SYN一样，一个FIN将占用一个序号
服务器-关闭与客户端的连接，发送一个FIN给客户端
客户端-发回ACK报文确认，并将确认序号设置为收到序号加1

为什么不是两次？

两次情况客户端说完结束就立马断开不再接收，无法确认服务端是否接收到断开消息，但且服务端可能还有消息未发送完。

为什么不是三次？

3次情况服务端接收到断开消息，向客户端发送确认接受消息，客户端未给最后确认断开的回复。

为什么要四次挥手

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

TCP作为一种可靠的传输控制协议，其核心思想就是：既要保证数据的可靠传输，又要提高传输的效率，而用三次恰恰可以满足以上俩方面的需求

博客

进程作为拥有资源的基本单位,线程作为调度和分配的基本单位

HTTP队头阻塞(HTTP1.0)

众所周知，服务器和客户端是经过三次握手创建TCP通道进行交流的，最后通过四次回收告别的。
所以一次TCP通道的创建是需要消耗一定资源和时间的。
那么在HTTP0.9之前，每发送一次请求就必须创建一次TCP通道，但是一个网站往往都需要发送几十个请求，那么就需要创建几十个TCP通道，那样岂不是很消耗资源？有没有什么方法可以解决呢？
有的！在HTPP1.0开始增加了Connection: Keep-Alive字段，可以让TCP链接持续打开。这样就可以节省了一个请求创建一次TCP通道的性能消耗。
在HTTP1.1引入了持久连接和管道机制

持久连接

持久连接：即不用声明Connection: keep-alive字段，TCP连接默认不关闭，并且可以被多个请求复用。长连接的连接时长可以通过请求头中的 keep-alive 来设置。
当客户端请求中含有Connection: Keep-Alive首部，服务器响应中也有Connection: Keep-Alive首部时，双方才会成功建立持久连接。
在服务器返回【Connection: Keep-Alive】字段时，还可以追加【Keep-Alive: max=5, timeout=120】字段
Connection: Keep-Alive
Keep-Alive: max=5, timeout=120

上面个例子说明，服务器最多还会为另外5个事务保持TCP连接的打开状态，或者将打开状态保持到连接空闲了2分钟之后。

管道机制

HTTP1.1 允许在持久连接上可选的使用请求管道。这是相对于keep-alive连接的又一性能优化。在相应到达之前，可以将多条请求放入队列，当第一条请求发往服务器的时候，第二第三条请求也可以开始发送了，在高延时网络条件下，这样做可以降低网络的环回时间，提高性能。

持久连接 + 管道机制引发 HTTP队头阻塞

当我们在发送 1号请求的时候得到了正常响应, 之后我们向服务器发送 2号请求时, 由于网络带宽或者种种原因, 导致发送请求到服务器缓慢或者服务器对其响应缓慢就会形成等待状态, 由于客户端请求是以队列形式发送到服务器, 所以二号请求发送后, 迟迟未收到响应, 所以导致 3号请求需要等待二号请求完成后才能发送.

这就是著名的队头阻塞.
我们来看下维基百科是怎么解释的:

队头阻塞（英語：Head-of-line blocking，缩写：HOL blocking）在计算机网络的范畴中是一种性能受限的现象。它的原因是一列的第一个数据包（队头）受阻而导致整列数据包受阻。例如它有可能在缓存式输入的交换机中出现，有可能因为传输顺序错乱而出现，亦有可能在HTTP流水线中有多个请求的情况下出现。

前面提到HTTP管道化要求服务端必须按照请求发送的顺序返回响应，那如果一个响应返回延迟了，那么其后续的响应都会被延迟，直到队头的响应送达。

HTTP队头阻塞的解决方法

利用HTTP2的多路复用解决

对于HTTP1.1中管道化导致的请求/响应级别的队头阻塞，可以使用HTTP2的多路复用解决。
HTTP2不使用管道化的方式，而是引入了帧、消息和数据流等概念，每个请求/响应被称为消息，每个消息都被拆分成若干个帧进行传输，每个帧都分配一个序号。每个帧在传输是属于一个数据流，而一个连接上可以存在多个流，各个帧在流和连接上独立传输，到达之后在组装成消息，这样就避免了请求/响应阻塞。
当然，即使使用HTTP2，如果HTTP2底层使用的是TCP协议，仍可能出现TCP队头阻塞。
多路复用对同一域名下所有请求都是基于流，所以不存在同域并行的阻塞

并发连接

我们知道对于一个域名而言，是允许分配多个长连接的，那么可以理解成增加了任务队列，也就是说不会导致一个任务阻塞了该任务队列的其他任务，在RFC规范中规定客户端最多并发2个连接，不过实际情况就是要比这个还要多，举个例子，Chrome中是6个。

域名分片

顾名思义，我们可以在一个域名下分出多个二级域名出来，而它们最终指向的还是同一个服务器，这样子的话就可以并发处理的任务队列更多，也更好的解决了队头阻塞的问题。
举个例子，比如TianTian.com，可以分出很多二级域名，比如Day1.TianTian.com，Day2.TianTian.com, Day3.TianTian.com, 这样子就可以有效解决队头阻塞问题。

参考文章

带你回顾一下：HTTP缓存策略、HTTP队头阻塞、HTTP2.0
HTTP队头阻塞

TCP队头阻塞

队头阻塞发生在一个TCP分节丢失，导致其后续分节不按序到达接收端的时候。该后续分节将被接收端一直保持直到丢失的第一个分节被发送端重传并到达接收端为止。该后续分节的延迟递送确保接收应用进程能够按照发送端的发送顺序接收数据。这种为了达到完全有序而引入的延迟机制非常有用，但也有不利之处。

要是第一幅图像的某个断片内容的TCP分节丢失了，客户端将保持已到达的不按序的所有数据，直到丢失的分节重传成功。这样不仅延缓了第一幅图像数据的递送，也延缓了第二幅和第三幅图像数据的递送。

如何解决TCP队头阻塞

TCP中的队头阻塞的产生是由TCP自身的实现机制决定的，无法避免。想要在应用程序当中避免TCP队头阻塞带来的影响，只有舍弃TCP协议。
比如google推出的quic协议，在某种程度上可以说避免了TCP中的队头阻塞，因为它根本不使用TCP协议，而是在UDP协议的基础上实现了可靠传输。而UDP是面向数据报的协议，数据报之间不会有阻塞约束。
此外还有一个SCTP（流控制传输协议），它是和TCP、UDP在同一层次的传输协议。SCTP的多流特性也可以尽可能的避免队头阻塞的情况。

掘金

其他不常问（多看）

1.http 和 https 的基本概念

HTTP 是一种超文本传输协议(Hypertext Transfer Protocol)，HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范
Http
HTTP 主要内容分为三部分，超文本（Hypertext）、传输（Transfer）、协议（Protocol）。

超文本就是不单单只是本文，它还可以传输图片、音频、视频，甚至点击文字或图片能够进行超链接的跳转。
上面这些概念可以统称为数据，传输就是数据需要经过一系列的物理介质从一个端系统传送到另外一个端系统的过程。通常我们2把传输数据包的一方称为请求方，把接到二进制数据包的一方称为应答方。
而协议指的就是是网络中(包括互联网)传递、管理信息的一些规范。如同人与人之间相互交流是需要遵循一定的规矩一样，计算机之间的相互通信需要共同遵守一定的规则，这些规则就称为协议，只不过是网络协议。

应用层

应用层协议定义了应用进程间的交互和通信规则，不同主机的应用进程间如何相互传递报文，比如传递的报文的类型、格式、有哪些字段等等。

HTTP 协议

HTTP 是超文本传输协议，它定义了客户端和服务器之间交换报文的格式和方式，默认使用 80 端口。它使用 TCP 作为传输层协议，保证了数据传输的可靠性。
HTTP 是一个无状态的协议，HTTP 服务器不会保存关于客户的任何信息。

HTTP 有两种连接模式，一种是持续连接，一种非持续连接。非持续连接指的是服务器必须为每一个请求的对象建立和维护一个全新的连接。持续连接下，TCP 连接默认不关闭，可以被多个请求复用。采用持续连接的好处是可以避免每次建立 TCP连接三次握手时所花费的时间。

在 HTTP1.0 以前使用的非持续的连接，但是可以在请求时，加上 Connection: keep-alive 来要求服务器不要关闭 TCP 连接。HTTP1.1 以后默认采用的是持续的连接。目前对于同一个域，大多数浏览器支持同时建立 6 个持久连接。

HTTP的keep-alive是干什么的？

在早期的HTTP/1.0中，每次http请求都要创建一个连接，而创建连接的过程需要消耗资源和时间，为了减少资源消耗，缩短响应时间，就需要重用连接。在后来的HTTP/1.0中以及HTTP/1.1中，引入了重用连接的机制，就是在http请求头中加入Connection: keep-alive来告诉对方这个请求响应完成后不要关闭，下一次咱们还用这个请求继续交流。协议规定HTTP/1.0如果想要保持长连接，需要在请求头中加上Connection: keep-alive。

keep-alive的优点

较少的CPU和内存的使用（由于同时打开的连接的减少了）
允许请求和应答的HTTP管线化
降低拥塞控制（TCP连接减少了）
减少了后续请求的延迟（无需再进行握手）
报告错误无需关闭TCP连

HTTP 请求报文

HTTP 报文有两种，一种是请求报文，一种是响应报文

HTTP 请求报文的格式如下：

1	`GET / HTTP/1.1User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)Accept: /`

HTTP 请求报文的第一行叫做请求行，后面的行叫做首部行，首部行后还可以跟一个实体主体。请求首部之后有一个空行，这个空行不能省略，它用来划分首部与实体。

请求行包含三个字段：方法字段、URL 字段和 HTTP 版本字段。

方法字段可以取几种不同的值，一般有 GET、POST、HEAD、PUT 和 DELETE。
一般 GET 方法只被用于向服务器获取数据。
POST 方法用于将实体提交到指定的资源，通常会造成服务器资源的修改。
HEAD 方法与 GET 方法类似，但是在返回的响应中，不包含请求对象。
PUT 方法用于上传文件到服务器，
DELETE 方法用于删除服务器上的对象。
虽然请求的方法很多，但更多表达的是一种语义上的区别，并不是说 POST 能做的事情，GET 就不能做了，主要看我们如何选择。更多的方法可以参
看文档。

HTTP 响应报文

HTTP 响应报文的格式如下：

HTTP/1.0 200 OKContent-Type: text/plainContent-Length: 137582Expires: Thu, 05 Dec 1997 16:00:00 GMTLast-Modified: Wed, 5 August 1996 15:55:28 GMTServer: Apache 0.84<html> <body>Hello World</body></html>

HTTP 响应报文的第一行叫做状态行，后面的行是首部行，最后是实体主体。
状态行包含了三个字段：协议版本字段、状态码和相应的状态信息。
实体部分是报文的主要部分，它包含了所请求的对象。

首部行

首部可以分为四种首部，请求首部、响应首部、通用首部和实体首部。通用首部和实体首部在请求报文和响应报文中都可以设置，区别在于请求首部和响应首部。
常见的请求首部有 Accept 可接收媒体资源的类型、Accept-Charset 可接收的字符集、Host 请求的主机名。
常见的响应首部有 ETag 资源的匹配信息，Location 客户端重定向的 URI。
常见的通用首部有 Cache-Control 控制缓存策略、Connection 管理持久连接。
常见的实体首部有 Content-Length 实体主体的大小、Expires 实体主体的过期时间、Last-Modified 资源的最后修改时间。
更多关于首部的资料可以查看：
《HTTP 首部字段详细介绍》
《图解 HTTP》

3.https 协议的工作原理

客户端在使用 HTTPS 方式与 Web 服务器通信时有以下几个步骤：

客户端使用 https url 访问服务器，则要求 web 服务器建立 ssl 链接。
web 服务器接收到客户端的请求之后，会将网站的证书（证书中包含了公钥），传输给客户端。
客户端和 web 服务器端开始协商 SSL 链接的安全等级，也就是加密等级。
客户端浏览器通过双方协商一致的安全等级，建立会话密钥，然后通过网站的公钥来加密会话密钥，并传送给网站。
web 服务器通过自己的私钥解密出会话密钥。
web 服务器通过会话密钥加密与客户端之间的通信。
传送门 ☞ #解读 HTTP1/HTTP2/HTTP3

TCP/IP / 如何保证数据包传输的有序可靠？

对字节流分段并进行编号然后通过 ACK 回复和超时重发这两个机制来保证。
（1）为了保证数据包的可靠传递，发送方必须把已发送的数据包保留在缓冲区；
（2）并为每个已发送的数据包启动一个超时定时器；
（3）如在定时器超时之前收到了对方发来的应答信息（可能是对本包的应答，也可以是对本包后续包的应答），则释放该数据包占用的缓冲区;
（4）否则，重传该数据包，直到收到应答或重传次数超过规定的最大次数为止。
（5）接收方收到数据包后，先进行CRC校验，如果正确则把数据交给上层协议，然后给发送方发送一个累计应答包，表明该数据已收到，如果接收方正好也有数据要发给发送方，应答包也可方在数据包中捎带过去。

长轮询和短轮询

长轮询

客户端发送请求后服务器端不会立即返回数据，服务器端会阻塞请求连接不会立即断开，直到服务器端有数据更新或者是连接超时才返回，客户端才再次发出请求新建连接、如此反复从而获取最新数据。

function LongAjax() {
    fetch(url).then(data => {
     // 数据正确拿到后，
        LongPolling();
    }).catch(err => {
     // 出错或者就是超时间
        LongPolling();

    });
}
LongAjax()

优点：长轮询与短轮询相比，明显减少了很多不必要的http请求，节约资源。
节点：连接挂起也会导致资源的浪费，停留在服务器端。

短轮询

短轮询(Polling)的实现思路就是浏览器端每隔几秒钟向服务器端发送http请求，服务端在收到请求后，不论是否有数据更新，都直接进行响应。在服务端响应完成，就会关闭这个Tcp连接。

优点：就是兼容性比较好，只要支持http协议就可以实现该方式。
缺点：很明显消耗资源，因为下一次的建立Tcp是非常消耗资源的，服务器端响应后就会关闭这个Tcp连接。

function LongAjax() {
    fetch(url).then(data => {
        // 数据正确拿到后，dosometing

    }).catch(err => {
        // 发现错误，比如返回的数据为空等。
        console.log(err);
    });
}
setInterval(LongAjax, 5000);

长轮询和短轮询

说下进程、线程和协程

进程是一个具有一定独立功能的程序在一个数据集上的一次动态执行的过程，是操作系统进行资源分配和调度的一个独立单位，是应用程序运行的载体。进程是一种抽象的概念，从来没有统一的标准定义

线程是程序执行中一个单一的顺序控制流程，是程序执行流的最小单元，是处理器调度和分派的基本单位。一个进程可以有一个或多个线程，各个线程之间共享程序的内存空间(也就是所在进程的内存空间)。一个标准的线程由线程ID、当前指令指针(PC)、寄存器和堆栈组成。而进程由内存空间(代码、数据、进程空间、打开的文件)和一个或多个线程组成

协程，英文Coroutines，是一种基于线程之上，但又比线程更加轻量级的存在，这种由程序员自己写程序来管理的轻量级线程叫做『用户空间线程』，具有对内核来说不可见的特性

进程和线程的区别与联系
【区别】：

进程作为拥有资源的基本单位,线程作为调度和分配的基本单位

并发性：不仅进程之间可以并发执行，同一个进程的多个线程之间也可并发执行

拥有资源：进程是拥有资源的一个独立单位，线程不拥有系统资源，但可以访问隶属于进程的资源。

系统开销：在创建或撤消进程时，由于系统都要为之分配和回收资源，导致系统的开销明显大于创建或撤消线程时的开销。但是进程有独立的地址空间，一个进程崩溃后，在保护模式下不会对其它进程产生影响，而线程只是一个进程中的不同执行路径。线程有自己的堆栈和局部变量，但线程之间没有单独的地址空间，一个进程死掉就等于所有的线程死掉，所以多进程的程序要比多线程的程序健壮，但在进程切换时，耗费资源较大，效率要差一些。
【联系】：

一个线程只能属于一个进程，而一个进程可以有多个线程，但至少有一个线程；

资源分配给进程，同一进程的所有线程共享该进程的所有资源；

处理机分给线程，即真正在处理机上运行的是线程；

线程在执行过程中，需要协作同步。不同进程的线程间要利用消息通信的办法实现同步。

传送门 ☞ # 一文搞懂进程、线程、协程及JS协程的发展 ☞了解更多
关于浏览器传送门 ☞#深入了解现代 Web 浏览器
 博客

粘包问题分析与对策

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。
粘包出现原因
简单得说，在流传输中出现，UDP不会出现粘包，因为它有消息边界

粘包情况有两种，一种是粘在一起的包都是完整的数据包，另一种情况是粘在一起的包有不完整的包

为了避免粘包现象，可采取以下几种措施

（1）对于发送方引起的粘包现象，用户可通过编程设置来避免，TCP提供了强制数据立即传送的操作指令push，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不必等待发送缓冲区满；
（2）对于接收方引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘包现象；
（3）由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包。分包多发。

以上提到的三种措施，都有其不足之处

（1）第一种编程设置方法虽然可以避免发送方引起的粘包，但它关闭了优化算法，降低了网络发送效率，影响应用程序的性能，一般不建议使用。
（2）第二种方法只能减少出现粘包的可能性，但并不能完全避免粘包，当发送频率较高时，或由于网络突发可能使某个时间段数据包到达接收方较快，接收方还是有可能来不及接收，从而导致粘包。
（3）第三种方法虽然避免了粘包，但应用程序的效率较低，对实时应用的场合不适合。

一种比较周全的对策是：接收方创建一预处理线程，对接收到的数据包进行预处理，将粘连的包分开。实验证明这种方法是高效可行的。

网路安全

什么是 XSS？如何预防？

XSS 全称是 Cross Site Scripting ,为了与CSS区分开来，故简称 XSS，翻译过来就是“跨站脚本”。
XSS是指黑客往 HTML 文件中或者 DOM 中注入恶意脚本，从而在用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段。
最开始的时候，这种攻击是通过跨域来实现的，所以叫“跨域脚本”。发展到现在，往HTML文件中中插入恶意代码方式越来越多，所以是否跨域注入脚本已经不是唯一的注入手段了，但是 XSS 这个名字却一直保留至今。注入恶意脚本可以完成这些事情：

窃取Cookie
监听用户行为，比如输入账号密码后之间发给黑客服务器
在网页中生成浮窗广告
修改DOM伪造登入表单

一般的情况下，XSS攻击有三种实现方式

存储型 XSS 攻击

存储型 XSS 攻击大致步骤如下：

首先黑客利用站点漏洞将一段恶意 JavaScript 代码提交到网站的数据库中；
然后用户向网站请求包含了恶意 JavaScript 脚本的页面；
当用户浏览该页面的时候，恶意脚本就会将用户的 Cookie 信息等数据上传到服务器。

比如常见的场景：

在评论区提交一份脚本代码，假设前后端没有做好转义工作，那内容上传到服务器，在页面渲染的时候就会直接执行，相当于执行一段未知的JS代码。这就是存储型 XSS 攻击。

反射型 XSS 攻击

反射型 XSS 攻击指的就是恶意脚本作为「网络请求的一部分」，随后网站又把恶意的JavaScript脚本返回给用户，当恶意 JavaScript 脚本在用户页面中被执行时，黑客就可以利用该脚本做一些恶意操作。
举个例子:

1	`http://dragon.com?query=<script>alert("你受到了XSS攻击")</script>`

如上，服务器拿到后解析参数query，最后将内容返回给浏览器，浏览器将这些内容作为HTML的一部分解析，发现是Javascript脚本，直接执行，这样子被XSS攻击了。
这也就是反射型名字的由来，将恶意脚本作为参数，通过网络请求，最后经过服务器，在反射到HTML文档中，执行解析。
主要注意的就是，「服务器不会存储这些恶意的脚本，这也算是和存储型XSS攻击的区别吧」。

基于 DOM 的 XSS 攻击

基于 DOM 的 XSS 攻击是不牵涉到页面 Web 服务器的。具体来讲，黑客通过各种手段将恶意脚本注入用户的页面中，在数据传输的时候劫持网络数据包.常见的劫持手段有：
WIFI路由器劫持,本地恶意软件

阻止 XSS 攻击的策略

以上讲述的XSS攻击原理，都有一个共同点：让恶意脚本直接在浏览器执行。
针对三种不同形式的XSS攻击，有以下三种解决办法

对输入脚本进行过滤或转码

对用户输入的信息过滤或者是转码

1	`<script>alert('你受到XSS攻击了')</script>`

这样的代码在 html 解析的过程中是无法执行的。
当然了对于<script>、<img>、<a>等关键字标签也是可以过来的，效果如下👇

最后什么都没有剩下了

利用 CSP

该安全策略的实现基于一个称作 Content-Security-Policy的 HTTP 首部。
可以移步MDN，有更加规范的解释。我在这里就是梳理一下吧。
CSP，即浏览器中的内容安全策略，它的核心思想大概就是服务器决定浏览器加载哪些资源，具体来说有几个功能👇

限制加载其他域下的资源文件，这样即使黑客插入了一个 JavaScript 文件，这个 JavaScript 文件也是无法被加载的；
禁止向第三方域提交数据，这样用户数据也不会外泄；
提供上报机制，能帮助我们及时发现 XSS 攻击。
禁止执行内联脚本和未授权的脚本；

利用 HttpOnly

由于很多 XSS 攻击都是来盗用 Cookie 的，因此还可以通过使用 HttpOnly 属性来保护我们 Cookie 的安全。这样子的话，JavaScript 便无法读取 Cookie 的值。这样也能很好的防范 XSS 攻击。
通常服务器可以将某些 Cookie 设置为 HttpOnly 标志，HttpOnly 是服务器通过 HTTP 响应头来设置的，下面是打开 Google 时，HTTP 响应头中的一段：

1	`set-cookie: NID=189=M8l6-z41asXtm2uEwcOC5oh9djkffOMhWqQrlnCtOI; expires=Sat, 18-Apr-2020 06:52:22 GMT; path=/; domain=.google.com; HttpOnly`

总结

XSS 攻击是指浏览器中执行恶意脚本, 然后拿到用户的信息进行操作。主要分为存储型、反射型和文档型。防范的措施包括

对输入内容过滤或者转码，尤其是类似于<script>、<img>、<a>标签
利用CSP
利用Cookie的HttpOnly属性

除了以上策略之外，我们还可以通过添加验证码防止脚本冒充用户提交危险操作。而对于一些不受信任的输入，还可以限制其输入长度，这样可以增大 XSS 攻击的难度。
掘金

什么是 CSP？

CSP 指的是内容安全策略，它的本质是建立一个白名单，告诉浏览器哪些外部资源可以加载和执行。我们只需要配置规则，如何拦截由浏览器自己来实现。

通常有两种方式来开启 CSP，一种是设置 HTTP 首部中的 Content-Security-Policy，一种是设置 meta 标签的方式<meta http-equiv="Content-Security-Policy">

什么是 CSRF 攻击？如何防范 CSRF 攻击？

CSRF 攻击指的是跨站请求伪造攻击，攻击者诱导用户进入一个第三方网站，然后该网站向被攻击网站发送跨站请求。如果用户在被
攻击网站中保存了登录状态，那么攻击者就可以利用这个登录状态，绕过后台的用户验证，冒充用户向服务器执行一些操作。

CSRF 攻击的本质是利用了 cookie 会在同源请求中携带发送给服务器的特点，以此来实现用户的冒充。

一般的 CSRF 攻击类型有三种：

第一种是 GET 类型的 CSRF 攻击，比如在网站中的一个 img 标签里构建一个请求，当用户打开这个网站的时候就会自动发起提
交。

第二种是 POST 类型的 CSRF 攻击，比如说构建一个表单，然后隐藏它，当用户进入页面时，自动提交这个表单。

第三种是链接类型的 CSRF 攻击，比如说在 a 标签的 href 属性里构建一个请求，然后诱导用户去点击。

CSRF 可以用下面几种方法来防护：

第一种是同源检测的方法，服务器根据 http 请求头中 origin 或者 referer 信息来判断请求是否为允许访问的站点，从而对请求进行过滤。当 origin 或者 referer 信息都不存在的时候，直接阻止。这种方式的缺点是有些情况下 referer 可以被伪造。还有就是我们这种方法同时把搜索引擎的链接也给屏蔽了，所以一般网站会允许搜索引擎的页面请求，但是相应的页面请求这种请求方式也可能被攻击者给利用。

第二种方法是使用 CSRF Token 来进行验证，服务器向用户返回一个随机数 Token ，当网站再次发起请求时，在请求参数中加入服务器端返回的 token ，然后服务器对这个 token 进行验证。这种方法解决了使用 cookie 单一验证方式时，可能会被冒用的问题，但是这种方法存在一个缺点就是，我们需要给网站中的所有请求都添加上这个 token，操作比较繁琐。还有一个问题是一般不会只有一台网站服务器，如果我们的请求经过负载平衡转移到了其他的服务器，但是这个服务器的 session 中没有保留这个 token 的话，就没有办法验证了。这种情况我们可以通过改变 token 的构建方式来解决。

第三种方式使用双重 Cookie 验证的办法，服务器在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串，然后当用户再次向服务器发送请求的时候，从 cookie 中取出这个字符串，添加到 URL 参数中，然后服务器通过对 cookie 中的数据和参数中的数据进行比较，来进行验证。使用这种方式是利用了攻击者只能利用 cookie，但是不能访问获取 cookie 的特点。并且这种方法比 CSRF Token 的方法更加方便，并且不涉及到分布式访问的问题。这种方法的缺点是如果网站存在 XSS 漏洞的，那么这种方式会失效。同时这种方式不能做到子域名的隔离。

第四种方式是使用在设置 cookie 属性的时候设置 Samesite ，限制 cookie 不能作为被第三方使用，从而可以避免被攻击者利用。Samesite 一共有两种模式，一种是严格模式，在严格模式下 cookie 在任何情况下都不可能作为第三方 Cookie 使用，在宽松模式下，cookie 可以被请求是 GET 请求，且会发生页面跳转的请求所使用。

Samesite Cookie 表示同站 cookie，避免 cookie 被第三方所利用。

将 Samesite 设为 strict ，这种称为严格模式，表示这个 cookie 在任何情况下都不可能作为第三方 cookie。

将 Samesite 设为 Lax ，这种模式称为宽松模式，如果这个请求是个 GET 请求，并且这个请求改变了当前页面或者打开了新的页面，那么这个 cookie 可以作为第三方 cookie，其余情况下都不能作为第三方 cookie。

使用这种方法的缺点是，因为它不支持子域，所以子域没有办法与主域共享登录信息，每次转入子域的网站，都回重新登录。还有一个问题就是它的兼容性不够好。

什么是点击劫持？如何防范点击劫持？

点击劫持是一种视觉欺骗的攻击手段，攻击者将需要攻击的网站通过 iframe 嵌套的方式嵌入自己的网页中，并将 iframe 设置为透明，在页面中透出一个按钮诱导用户点击。

我们可以在 http 相应头中设置 X-FRAME-OPTIONS 来防御用 iframe 嵌套的点击劫持攻击。通过不同的值，可以规定页面在特定的一些情况才能作为 iframe 来使用。

SQL 注入攻击？

SQL 注入攻击指的是攻击者在 HTTP 请求中注入恶意的 SQL 代码，服务器使用参数构建数据库 SQL 命令时，恶意 SQL 被一起构造，破坏原有 SQL 结构，并在数据库中执行，达到编写程序时意料之外结果的攻击行为。

面试题

前端基础计算机网络

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议，转载请注明出处！

React面试题总结 Previous

JS+ES6面试题总结 Next

计网+HTTP+浏览器+网络安全面试题总结

计网+HTTP (常问+掌握)

从输入URL到浏览器显示页面过程中都发生了什么

什么是浏览器的同源政策？

跨域怎么实现？jsonp的原理是什么？

跨域，指的是浏览器不能执行其他网站的脚本。浏览器执行javascript脚本时，会检查这个脚本属于哪个页面，如果不是同源页面，就不会被执行

Options(CORS跨域，非简单请求)

浏览器会拦截跨域请求，但是只是拦截返回结果，请求还是会被发送到服务器，这样有意义么

常见的状态码

常见状态码

HTTP 和 HTTPS 的主要区别是什么呢？

HTTPS是如何保证安全的？

1. 对称加密：即通信的双方都使用同一个秘钥进行加解密，比如特务接头的暗号，就属于对称加密

2. 非对称加密

TCP和UDP的区别

TCP 和 UDP 应用场景

Cookie、sessionStorage、localStorage 的区别

相同点(存储在客户端)

不同点

cookie 的缺点

2. Session

Session的创建过程

Session的缺点

什么是 Token（令牌）

Refresh Token

Ajax 是什么? 如何创建一个 Ajax？

axios

fetch

HTTP2相对于HTTP1.x有什么优势和特点？

二进制分帧

服务器推送

头部压缩

多路复用

浏览器的缓存机制 强制缓存 && 协商缓存

强制缓存强制缓存就是向浏览器缓存查找该请求结果，并根据该结果的缓存规则来决定是否使用该缓存结果的过程

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

介绍下304过程

TCP三次握手

目的： 建立可靠的通信通道 ，数据的发送和接收（双方正常）

为什么是3次？：避免历史连接，确认客户端发来的请求是这次通信的人 为什么不是4次？：3次够了第四次浪费

三次握手过程中可以携带数据吗？

SYN攻击是什么？

TCP 协议四次挥手

为什么不是两次？

为什么不是三次？

为什么要四次挥手

TCP作为一种可靠的传输控制协议，其核心思想就是：既要保证数据的可靠传输，又要提高传输的效率，而用三次恰恰可以满足以上俩方面的需求

进程作为拥有资源的基本单位,线程作为调度和分配的基本单位

HTTP队头阻塞(HTTP1.0)

持久连接

管道机制

持久连接 + 管道机制 引发 HTTP队头阻塞

HTTP队头阻塞 的解决方法

利用HTTP2的多路复用解决

并发连接

域名分片

参考文章

TCP队头阻塞

如何解决TCP队头阻塞

其他不常问（多看）

1.http 和 https 的基本概念

应用层

HTTP 协议

HTTP的keep-alive是干什么的？

keep-alive的优点

HTTP 请求报文

HTTP 报文有两种，一种是请求报文，一种是响应报文

HTTP 响应报文

首部行

3.https 协议的工作原理

TCP/IP / 如何保证数据包传输的有序可靠？

长轮询和短轮询

长轮询

短轮询

说下进程、线程和协程

进程作为拥有资源的基本单位,线程作为调度和分配的基本单位

并发性：不仅进程之间可以并发执行，同一个进程的多个线程之间也可并发执行

粘包问题分析与对策

粘包情况有两种，一种是粘在一起的包都是完整的数据包，另一种情况是粘在一起的包有不完整的包

为了避免粘包现象，可采取以下几种措施

浏览器的缓存机制强制缓存 && 协商缓存

目的：建立可靠的通信通道，数据的发送和接收（双方正常）

为什么是3次？：避免历史连接，确认客户端发来的请求是这次通信的人为什么不是4次？：3次够了第四次浪费

持久连接 + 管道机制引发 HTTP队头阻塞

HTTP队头阻塞的解决方法