浏览器相关

缓存的理解

HTTP缓存

HTTP缓存分为强缓存和协商缓存。强缓存不过服务器，协商缓存需要过服务器，协商缓存返回的状态码是304。两类缓存机制可以同时存在，强缓存的优先级高于协商缓存。当执行强缓存时，如若缓存命中，则直接使用缓存数据库中的数据，不再进行缓存协商。

1. 强缓存

• Expires
• cache-control

2. 协商缓存

• Last-Modified 和 If-Modified-Since

• Etag 和 If-None-Match

• 强制缓存

强制缓存就是向浏览器缓存查找该请求结果，并根据该结果的缓存规则来决定是否使用该缓存结果的过程。当浏览器向服务器发起请求时，服务器会将缓存规则放入HTTP响应报文的HTTP头中和请求结果一起返回给浏览器，控制强制缓存的字段分别是 Expires 和 Cache-Control，其中Cache-Control优先级比Expires高。

强制缓存的情况主要有三种(暂不分析协商缓存过程)，如下：

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

• 协商缓存

  协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程，同样，协商缓存的标识也是在响应报文的HTTP头中和请求结果一起返回给浏览器的，控制协商缓存的字段分别有：Last-Modified / If-Modified-Since 和 Etag / If-None-Match，其中Etag / If-None-Match的优先级比Last-Modified / If-Modified-Since高。协商缓存主要有以下两种情况：

  1. 协商缓存生效，返回304
  2. 协商缓存失效，返回200和请求结果结果

cache-control的no-store和no-cache区别

no-cache：不使用本地缓存。需要使用协商缓存，先与服务器确认返回的响应是否被更改，如果之前的响应中存在ETag，那么请求的时候会与服务端验证，如果资源未被更改，则可以避免重新下载。

no-store：直接禁止游览器缓存数据，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。

HTTP协议的Cache -Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置 Cache-Control并不会影响另一个消息处理过程中的缓存处理过程。
请求时的缓存指令包括: no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached等。
响应消息中的指令包括: public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。

一.   浏览器中关于Cache的3属性:
1. Cache-Control:
设置相对过期时间, max-age指明以秒为单位的缓存时间. 若对静态资源只缓存一次, 可以设置max-age的值为315360000000 (一万年). 比如对于提交的订单，为了防止浏览器回退重新提交，可以使用Cache-Control之no-store绝对禁止缓存，即便浏览器回退依然请求的是服务器，进而判断订单的状态给出相应的提示信息！

Http协议的cache-control的常见取值及其组合释义:
no-cache: 数据内容不能被缓存, 每次请求都重新访问服务器, 若有max-age, 则缓存期间不访问服务器.
no-store: 不仅不能缓存, 连暂存也不可以(即: 临时文件夹中不能暂存该资源).
private(默认): 只能在浏览器中缓存, 只有在第一次请求的时候才访问服务器, 若有max-age, 则缓存期间不访问服务器.
public: 可以被任何缓存区缓存, 如: 浏览器、服务器、代理服务器等.
max-age: 相对过期时间, 即以秒为单位的缓存时间.
no-cache, private: 打开新窗口时候重新访问服务器, 若设置max-age, 则缓存期间不访问服务器.
-  private, 正数的max-age: 后退时候不会访问服务器.
-  no-cache, 正数的max-age: 后退时会访问服务器.

2. Expires:
设置以分钟为单位的绝对过期时间, 优先级比Cache-Control低, 同时设置Expires和Cache-Control则后者生效. 也就是说要注意一点:  Cache-Control的优先级高于Expires

expires起到控制页面缓存的作用，合理配置expires可以减少很多服务器的请求, expires的配置可以在http段中或者server段中或者location段中.  比如控制图片等过期时间为30天, 可以配置如下:

| 1234 | location ~ .(gif|jpg|jpeg|png|bmp|ico)$ {``           ``root ``/var/www/img/``;``           ``expires 30d;``       ``} | | ---- | ------------------------------------------------------------------------------------------------------------------------------ |

再比如:

| 1234 | location ~ .(wma|wmv|asf|mp3|mmf|zip|rar|swf|flv)$ {``              ``root ``/var/www/upload/``;``              ``expires max;``      ``} | | ---- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |

3. Last-Modified:
该资源的最后修改时间, 在浏览器下一次请求资源时, 浏览器将先发送一个请求到服务器上, 并附上If-Unmodified-Since头来说明浏览器所缓存资源的最后修改时间, 如果服务器发现没有修改, 则直接返回304(Not Modified)回应信息给浏览器(内容很少), 如果服务器对比时间发现修改了, 则照常返回所请求的资源. 

需要注意:

1. Last-Modified属性通常和Expires或Cache-Control属性配合使用, 因为即使浏览器设置缓存, 当用户点击”刷新”按钮时, 浏览器会忽略缓存继续向服务器发送请求, 这时Last-Modified将能够很好的减小回应开销.

2. ETag将返回给浏览器一个资源ID, 如果有了新版本则正常发送并附上新ID, 否则返回304， 但是在服务器集群情况下, 每个服务器将返回不同的ID, 因此不建议使用ETag.

个人理解的max-age意思是：客户端本地的缓存，在配置的生存时间内的，客户端可以直接使用，超出生存时间的，到服务器上取新数据。当然这些还要看客户端浏览器的设置。

浏览器如何判断资源是否在有效期内被修改

静态网页

• Last-Modified

在浏览器第一次请求某一个URL时，服务器端的返回状态会是200，内容是你请求的资源，同时有一个Last-Modified的属性标记此文件在服务期端最后被修改的时间，格式类似这样：

Last-Modified: Fri, 12 May 2006 18:53:33 GMT

客户端第二次请求此URL时，根据 HTTP 协议的规定，浏览器会向服务器传送 If-Modified-Since 报头，询问该时间之后文件是否有被修改过：

If-Modified-Since: Fri, 12 May 2006 18:53:33 GMT

如果服务器端的资源没有变化，则自动返回 HTTP 304 （Not Changed.）状态码，内容为空，这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时，则重新发出资源，返回和第一次请求时类似。从而保证不向客户端重复发出资源，也保证当服务器有变化时，客户端能够得到最新的资源。

• ETag

HTTP 协议规格说明定义ETag为“被请求变量的实体值” （参见 —— 章节 14.19）。 另一种说法是，ETag是一个可以与Web资源关联的记号（token）。典型的Web资源可以一个Web页，但也可能是JSON或XML文档。服务器单独负责判断记号是什么及其含义，并在HTTP响应头中将其传送到客户端，以下是服务器端返回的格式：

　　ETag: “50b1c1d4f775c61:df3”

客户端的查询更新格式是这样的：

　　If-None-Match: W/”50b1c1d4f775c61:df3”

如果ETag没改变，则返回状态304然后不返回，这也和Last-Modified一样。

动态网页
对于绝大多数动态网页如ASP，JSP来说，LastModifed就是服务器
发送Response的时间，并非网页的最后更新时间，而Etag通常为空值。

• MD5

每次下载网页时，把服务器返回的数据流ResponseStream先放在内存缓冲区，然后对ResponseStream生成MD5数字签名S1，下次下载同样生成签名S2,比较S2和S1，如果相同，则页面没有修改

浏览器缓存

Cookie、sessionStorage、localStorage 的区别

相同点：

• 存储在客户端

不同点：

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

传送门 ☞ # 彻底理解浏览器的缓存机制

Token 和 JWT 的区别

相同：

都是访问资源的令牌
都可以记录用户的信息
都是使服务端无状态化
都是只有验证成功后，客户端才能访问服务端上受保护的资源

区别：

Token：服务端验证客户端发送过来的 Token 时，还需要查询数据库获取用户信息，然后验证 Token 是否有效。
JWT：将 Token 和 Payload 加密后存储于客户端，服务端只需要使用密钥解密进行校验（校验也是 JWT 自己实现的）即可，不需要查询或者减少查询数据库，因为 JWT 自包含了用户信息和加密的数据。

session验证方式的一些弊端

占用服务器内存资源：由于 session 存储于服务器端，随着越来越多用户的请求登录，服务器端的 session 记录表会越来越大，对服务器内存资源的开销逐渐增大；

扩展性弱：session 机制在负载均衡下，无法很好地进行工作。当服务器资源不足时，无法很好地进行水平扩展；

CORS（跨域资源共享）：当我们需要让数据跨多台移动设备上使用时，跨域资源共享会是一个让人头疼的问题。在使用 Ajax 抓取另一个域的资源时，就会出现禁止请求的情况；

CSRF（跨站请求伪造）：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他网站。

Set-Cookie中的HttpOnly作用

设置了 HttpOnly 属性的 cookie 不能使用 JavaScript 经由 Document.cookie 属性、XMLHttpRequest 和 Request APIs 进行访问，以防范跨站脚本攻击（XSS）

XSS（跨站脚本攻击）

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

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

• 在 HTML 中内嵌的文本中，恶意内容以 script 标签形成注入。
• 在内联的 JavaScript 中，拼接的数据突破了原本的限制（字符串，变量，方法名等）。
• 在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签。
• 在标签的 href、src 等属性中，包含 javascript: 等可执行代码。
• 在 onload、onerror、onclick 等事件中，注入不受控制代码。
• 在 style 属性和标签中，包含类似 background-image:url("javascript:..."); 的代码（新版本浏览器已经可以防范）。
• 在 style 属性和标签中，包含类似 expression(...) 的 CSS 表达式代码（新版本浏览器已经可以防范）。

XSS攻击可以分为3类：反射型（非持久型）、存储型（持久型）、基于DOM。 类型|存储区 |插入点|
|-|-|
|存储型 XSS|后端数据库|HTML|
|反射型 XSS|URL|HTML|
|DOM 型 XSS|后端数据库/前端存储/URL|前端 JavaScript|

• 存储区：恶意代码存放的位置。
• 插入点：由谁取得恶意代码，并插入到网页上。

存储型 XSS

存储型 XSS 的攻击步骤：

1. 攻击者将恶意代码提交到目标网站的数据库中。
2. 用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
3. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

这种攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。

反射型 XSS

反射型 XSS 的攻击步骤：

1. 攻击者构造出特殊的 URL，其中包含恶意代码。
2. 用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
3. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。

反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。

由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。

POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见。

基于DOM

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

DOM 型 XSS 的攻击步骤：

1. 攻击者构造出特殊的 URL，其中包含恶意代码。
2. 用户打开带有恶意代码的 URL。
3. 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。

<h2>XSS: </h2>
<input type="text" id="input">
<button id="btn">Submit</button>
<div id="div"></div>
<script>
    const input = document.getElementById('input');
    const btn = document.getElementById('btn');
    const div = document.getElementById('div');

    let val;
     
    input.addEventListener('change', (e) => {
        val = e.target.value;
    }, false);

    btn.addEventListener('click', () => {
        div.innerHTML = `<a href=${val}>testLink</a>`
    }, false);
</script>

点击 Submit 按钮后，会在当前页面插入一个链接，其地址为用户的输入内容。如果用户在输入时构造了如下内容：

'' onclick=alert(/xss/)

用户提交之后，页面代码就变成了：

<a href onlick="alert(/xss/)">testLink</a>

此时，用户点击生成的链接，就会执行对应的脚本。

XSS攻击防范

HttpOnly 防止劫取 Cookie：HttpOnly 最早由微软提出，至今已经成为一个标准。浏览器将禁止页面的Javascript 访问带有 HttpOnly 属性的Cookie。上文有说到，攻击者可以通过注入恶意脚本获取用户的 Cookie 信息。通常 Cookie 中都包含了用户的登录凭证信息，攻击者在获取到 Cookie 之后，则可以发起 Cookie 劫持攻击。所以，严格来说，HttpOnly 并非阻止 XSS 攻击，而是能阻止 XSS 攻击后的 Cookie 劫持攻击。

输入检查：不要相信用户的任何输入。 对于用户的任何输入要进行检查、过滤和转义。建立可信任的字符和 HTML 标签白名单，对于不在白名单之列的字符或者标签进行过滤或编码。在 XSS 防御中，输入检查一般是检查用户输入的数据中是否包含 <，> 等特殊字符，如果存在，则对特殊字符进行过滤或编码，这种方式也称为 XSS Filter。而在一些前端框架中，都会有一份 decodingMap， 用于对用户输入所包含的特殊字符或标签进行编码或过滤，如 <，>，script，防止 XSS 攻击：

// vuejs 中的 decodingMap
// 在 vuejs 中，如果输入带 script 标签的内容，会直接过滤掉
const decodingMap = {
  '&lt;': '<',
  '&gt;': '>',
  '&quot;': '"',
  '&amp;': '&',
  '&#10;': '\n'
}
复制代码

escapeHTML() 按照如下规则进行转义：

字符	转义后的字符
&	&
<	&lt;
>	&gt;
"	&quot;
'	&#x27;
/	&#x2F;
输出检查：用户的输入会存在问题，服务端的输出也会存在问题。一般来说，除富文本的输出外，在变量输出到 HTML 页面时，可以使用编码或转义的方式来防御 XSS 攻击。例如利用 sanitize-html 对输出内容进行有规则的过滤之后再输出到页面中。

在纯前端渲染中，我们会明确的告诉浏览器：下面要设置的内容是文本（.innerText），还是属性（.setAttribute），还是样式（.style）等等。浏览器不会被轻易的被欺骗，执行预期外的代码了。

但纯前端渲染还需注意避免 DOM 型 XSS 漏洞（例如 onload 事件和 href 中的 javascript:xxx 等。尽量不要使用 onLoad="onload('{{data}}')"、onClick="go('{{action}}')" 这种拼接内联事件的写法。在 JavaScript 中通过 .addEventlistener() 事件绑定会更安全。

2009年，Google 提出了一个概念叫做：Automatic Context-Aware Escaping。

所谓 Context-Aware，就是说模板引擎在解析模板字符串的时候，就解析模板语法，分析出每个插入点所处的上下文，据此自动选用不同的转义规则。

利用XSS漏洞扫描工具进行扫描

CSRF/XSRF（跨站请求伪造）

CSRF，即 Cross Site Request Forgery，中译是跨站请求伪造，是一种劫持受信任用户向服务器发送非预期请求的攻击方式。通常情况下，CSRF 攻击是攻击者借助受害者的 Cookie 骗取服务器的信任，可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器，从而在并未授权的情况下执行在权限保护之下的操作。

Cookie

Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。Cookie 主要用于以下三个方面：

• 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
• 个性化设置（如用户自定义设置、主题等）
• 浏览器行为跟踪（如跟踪分析用户行为等）

而浏览器所持有的 Cookie 分为两种：

• Session Cookie(会话期 Cookie)：会话期 Cookie 是最简单的Cookie，它不需要指定过期时间（Expires）或者有效期（Max-Age），它仅在会话期内有效，浏览器关闭之后它会被自动删除。
• Permanent Cookie(持久性 Cookie)：与会话期 Cookie 不同的是，持久性 Cookie 可以指定一个特定的过期时间（Expires）或有效期（Max-Age）。

res.setHeader('Set-Cookie', ['mycookie=222', 'test=3333; expires=Sat, 21 Jul 2018 00:00:00 GMT;']);
复制代码

上述代码创建了两个 Cookie：mycookie 和 test，前者属于会话期 Cookie，后者则属于持久性 Cookie。

CSRF攻击

使登录用户访问攻击者的网站，发起一个请求，由于 Cookie 中包含了用户的认证信息，当用户访问攻击者准备的攻击环境时，攻击者就可以对服务器发起 CSRF 攻击。

在这个攻击过程中，攻击者借助受害者的 Cookie 骗取服务器的信任，但并不能拿到 Cookie，也看不到 Cookie 的内容。而对于服务器返回的结果，由于浏览器同源策略的限制，攻击者也无法进行解析。（攻击者的网站虽然是跨域的，但是他构造的链接是源网站的，跟源网站是同源的，所以能够携带cookie发起访问）。

但是攻击者无法从返回的结果中得到任何东西，他所能做的就是给服务器发送请求，以执行请求中所描述的命令，在服务器端直接改变数据的值，而非窃取服务器中的数据。例如删除数据、修改数据，新增数据等，无法获取数据。

CSRF攻击防范

验证码：验证码被认为是对抗 CSRF 攻击最简洁而有效的防御方法。从上述示例中可以看出，CSRF 攻击往往是在用户不知情的情况下构造了网络请求。而验证码会强制用户必须与应用进行交互，才能完成最终请求。因为通常情况下，验证码能够很好地遏制 CSRF 攻击。但验证码并不是万能的，因为出于用户考虑，不能给网站所有的操作都加上验证码。因此，验证码只能作为防御 CSRF 的一种辅助手段，而不能作为最主要的解决方案。

Referer Check：根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。通过 Referer Check，可以检查请求是否来自合法的"源"。

添加token验证：要抵御 CSRF，关键在于在请求中放入攻击者所不能伪造的信息，并且该信息不存在于 Cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。

HTTP与HTTPS的区别

• HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
• HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过混合加密（在传输共享密钥时进行非对称加密，传输数据时进行对称加密）。
• HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
• HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。

https有没有可能还被攻击？

有可能，http改成https后，收藏夹中地址还是原来的，以前的地址要就要重定向到新地址，这个过程可能会被攻击者利用，修改重定向的地址。

url重定向攻击解决方法

安全隐患的产生原因：

• 重定向的目标URL能够由外界指定。
• 没有对重定向的目标域名进行校验。
  以上两点是AND条件，也就是说只有同时满足这两点时才会形成自由重定向漏洞，因此，只要使其中一项无法满足，也就消除了安全隐患。

解决对策：

• 固定重定向的目标URL
• 使用编号指定重定向的目标URL
• 校验重定向的目标域名。采用白名单机制，将重定向目标限定在允许的域名范围内。

HTTP2.0和HTTP1.X相比的新特性

1. 新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
2. 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
3. header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
4. 服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。

HTTP状态码

1xx表示客户端应该继续发送请求

2xx表示成功的请求

• 200表示OK，正常返回信息
• 201表示请求成功且服务器创建了新的资源
• 202表示服务器已经接受了请求，但还未处理

3xx表示重定向

• 301表示永久重定向，请求的网页已经永久移动到新位置
• 302表示临时重定向
• 304表示自从上一次请求以来，页面的内容没有改变过

4xx表示客户端错误

• 401表示服务器无法理解请求的格式
• 402表示请求未授权
• 403表示禁止访问
• 404表示请求的资源不存在，一般是路径写错了

5xx表示服务器错误

• 500表示最常见的服务器错误
• 503表示服务器暂时无法处理请求

HTTP 请求跨域问题

1. 跨域的原理

   跨域，是指浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的。
   同源策略,是浏览器对 JavaScript 实施的安全限制，只要协议、域名、端口有任何一个不同，都被当作是不同的域。
   跨域原理，即是通过各种方式，避开浏览器的安全限制。

2. 解决方案

   最初做项目的时候，使用的是jsonp，但存在一些问题，使用get请求不安全，携带数据较小，后来也用过iframe，但只有主域相同才行，也是存在些问题，后来通过了解和学习发现使用代理和proxy代理配合起来使用比较方便，就引导后台按这种方式做下服务器配置，在开发中使用proxy，在服务器上使用nginx代理，这样开发过程中彼此都方便，效率也高；现在h5新特性还有 windows.postMessage()

   • JSONP：
     ajax 请求受同源策略影响，不允许进行跨域请求，而 script 标签 src 属性中的链 接却可以访问跨域的 js 脚本，利用这个特性，服务端不再返回 JSON 格式的数据，而是 返回一段调用某个函数的 js 代码，在 src 中进行了调用，这样实现了跨域。

     步骤：

     1. 去创建一个script标签
     2. script的src属性设置接口地址
     3. 接口参数，必须要带一个自定义函数名，要不然后台无法返回数据
     4. 通过定义函数名去接受返回的数据

     //动态创建 script
     var script = document.createElement('script');
     
     // 设置回调函数
     function getData(data) {
         console.log(data);
     }
     
     //设置 script 的 src 属性，并设置请求地址
     script.src = 'http://localhost:3000/?callback=getData';
     
     // 让 script 生效
     document.body.appendChild(script);
     复制代码
     

     JSONP 的缺点:
     JSON 只支持 get，因为 script 标签只能使用 get 请求； JSONP 需要后端配合返回指定格式的数据。

   • document.domain 基础域名相同 子域名不同

   • window.name 利用在一个浏览器窗口内，载入所有的域名都是共享一个window.name

   • CORS CORS(Cross-origin resource sharing)跨域资源共享 服务器设置对CORS的支持原理：服务器设置Access-Control-Allow-Origin HTTP响应头之后，浏览器将会允许跨域请求

   • proxy代理 目前常用方式,通过服务器设置代理

   • window.postMessage() 利用h5新特性window.postMessage()

跨域传送门 ☞ # 跨域，不可不知的基础概念

TCP和UDP的区别

1. TCP是面向链接的，而UDP是面向无连接的。
2. TCP仅支持单播传输，UDP 提供了单播，多播，广播的功能。
3. TCP的三次握手保证了连接的可靠性; UDP是无连接的、不可靠的一种数据传输协议，首先不可靠性体现在无连接上，通信都不需要建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收。
4. UDP的头部开销比TCP的更小，数据传输速率更高，实时性更好。

传送门 ☞ # 深度剖析TCP与UDP的区别

从输入URL到页面加载的全过程

1. 首先在浏览器中输入URL

2. 查找缓存：浏览器先查看浏览器缓存-系统缓存-路由缓存中是否有该地址页面，如果有则显示页面内容。如果没有则进行下一步。

3. DNS域名解析：浏览器向DNS服务器发起请求，解析该URL中的域名对应的IP地址。DNS服务器是基于UDP的，因此会用到UDP协议。

4. 建立TCP连接：解析出IP地址后，根据IP地址和默认80端口，和服务器建立TCP连接

5. 发起HTTP请求：浏览器发起读取文件的HTTP请求，，该请求报文作为TCP三次握手的第三次数据发送给服务器

6. 服务器响应请求并返回结果：服务器对浏览器请求做出响应，并把对应的html文件发送给浏览器

7. 关闭TCP连接：通过四次挥手释放TCP连接

8. 浏览器渲染：客户端（浏览器）解析HTML内容并渲染出来，浏览器接收到数据包后的解析流程为：

   • 构建DOM树：词法分析然后解析成DOM树（dom tree），是由dom元素及属性节点组成，树的根是document对象
   • 构建CSS规则树：生成CSS规则树（CSS Rule Tree）
   • 构建render树：Web浏览器将DOM和CSSOM结合，并构建出渲染树（render tree）
   • 布局（Layout）：计算出每个节点在屏幕中的位置
   • 绘制（Painting）：即遍历render树，并使用UI后端层绘制每个节点。

   

TCP三次握手

建立连接前，客户端和服务端需要通过握手来确认对方:

• 客户端发送 syn(同步序列编号) 请求，进入 syn_send 状态，等待确认
• 服务端接收并确认 syn 包后发送 syn+ack 包，进入 syn_recv 状态
• 客户端接收 syn+ack 包后，发送 ack 包，双方进入 established 状态

为什么要进行三次握手，不是二次握手

假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。 由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据,但server却以为新的运输连接已经建立，并一直等待client发来数据。 这样，server的很多资源就白白浪费掉了。

TCP四次挥手

• 第一次挥手 主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可 以接受数据。
• 第二次挥手 被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。
• 第三次挥手 被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
• 第四次挥手 主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

为什么要四次挥手而不是三次

这是因为服务端在LISTEN状态下，收到客户端发送的断开连接的FIN报文后，可能会有数据未发送完成，需要继续发送，因此不能将确认消息和请求关闭消息同时发送，而是会先关闭接收服务回复确认消息，然后继续发送未完消息到客户端，直到发送结束，再发送请求关闭消息

跨标签页通讯

不同标签页间的通讯，本质原理就是去运用一些可以 共享的中间介质，因此比较常用的有以下方法:

• 通过父页面window.open()和子页面postMessage

  • 异步下，通过 window.open('about: blank') 和 tab.location.href = '*'

• 设置同域下共享的localStorage与监听window.onstorage

  • 重复写入相同的值无法触发
  • 会受到浏览器隐身模式等的限制

• 设置共享cookie与不断轮询脏检查(setInterval)

• 借助服务端或者中间层实现

websocket即时通讯

//需要连接的服务器端的URL  注意： ws或者wss一定要有 两者就是http协议和https协议的区别
var ws = new WebSocket("wss://echo.websocket.org");  

ws.onopen = function(evt) { 
  console.log("Connection open ..."); 
  ws.send("Hello WebSockets!");  //向服务器端发送数据的方法
};

ws.onmessage = function(evt) {  //发送完数据后，从服务器端接收相应返回的方法
  console.log( "Received Message: " + evt.data); 
  ws.close();
};

ws.onclose = function(evt) {  //与服务器端断开连接后执行的方法
  console.log("Connection closed.");
};  

浏览器和服务器 对http请求(post get) url长度限制

1. GET  URL长度限制

在Http1.1协议中并没有提出针对URL的长度进行限制，RFC协议里面是这样描述的，HTTP协议并不对URI的长度做任何的限制，服务器端 必须能够处理任何它们所提供服务多能接受的URI，并且能够处理无限长度的URI,如果服务器不能处理过长的URI,那么应该返回414状态码。

虽然Http协议规定了，但是浏览器和Web服务器对URL都有自己的长度限制。

浏览器的限制:每种浏览器也会对url的长度有所限制，下面是几种常见浏览器的url长度限制:(单位:字符)

• IE : 2803
• Firefox:65536
• Chrome:8182
• Safari:80000
• Opera:190000 对于get请求，在url的长度限制范围之内，请求的参数个数没有限制。

服务器的限制:我接触的最多的服务器类型就是Nginx和Tomcat,对于url的长度限制，它们都是通过控制http请求头的长度来进行限制 的，nginx的配置参数为large_client_header_buffers，tomcat的请求配置参数为 maxHttpHeaderSize,都是可以自己去进行设置。

  client_header_buffer_size 512k;
  large_client_header_buffers 7 512k;

2. Post数据的长度限制

Post数据的长度限制与url长度限制类似，也是在Http协议中没有规定长度限制,长度限制可以在服务器端配置最大http请求头长度的方式来实现。   nginix默认限制1M

可以选择在http{ }中设置：client_max_body_size   20m;
 也可以选择在server{ }中设置：client_max_body_size   20m;
还可以选择在location{ }中设置：client_max_body_size   20m;
三者到区别是：http{} 中控制着所有nginx收到的请求。而报文大小限制设置在server｛｝中，则控制该server收到的请求报文大小，同理，如果配置在location中，则报文大小限制，只对匹配了location 路由规则的请求生效。
     http{
#控制全局nginx所有请求报文大小
#client_max_body_size   20m;
                server{
#控制该server的所有请求报文大小
#client_max_body_size   20m;
                        location a {
 
                        }
                        location b{
#控制满足该路由规则的请求报文大小
#client_max_body_size   20m;
 
                        }
                }
                server {
 
 
                }
     }