浏览器相关

加粗样式

1、跨域

如果两个 URL 的协议、域名和端口都相同，我们就称这两个 URL 同源
	第一个，DOM 层面。同源策略限制了来自不同源的 JavaScript 脚本对当前 DOM 对象读和写的操作。
	第二个，数据层面。同源策略限制了不同源的站点读取当前站点的 Cookie、IndexDB、LocalStorage 等数据。由于同源策略，我们依然无法通过第二个页面的 opener 来访问第一个页面中的 Cookie、IndexDB 或者 LocalStorage 等内容。你可以自己试一下，这里我们就不做演示了。	
	第三个，网络层面。同源策略限制了通过 XMLHttpRequest 等方式将站点的数据发送给不同源的站点

怎么解决

1、JSONP,页面中可以嵌入第三方资源
2、CORS(跨域资源共享)
3、跨文档消息机制：window.postMessage 的 JavaScript 接口来和不同源的 DOM 进行通信。
4、服务器代理

2、XSS攻击（跨域脚本攻击）

	XSS 攻击是指黑客往 HTML 文件中或者 DOM 中注入恶意脚本，从而在用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段,刚开始通过跨域脚本攻击，所以叫这个名字
	可以窃取 Cookie 信息。恶意 JavaScript 可以通过“document.cookie”获取 Cookie 信息，然后通过 XMLHttpRequest 或者 Fetch 加上 CORS 功能将数据发送给恶意服务器；恶意服务器拿到用户的 Cookie 信息之后，就可以在其他电脑上模拟用户的登录，然后进行转账等操作。
	可以监听用户行为。恶意 JavaScript 可以使用“addEventListener”接口来监听键盘事件，比如可以获取用户输入的信用卡等信息，将其发送到恶意服务器。黑客掌握了这些信息之后，又可以做很多违法的事情。
	可以通过修改 DOM伪造假的登录窗口，用来欺骗用户输入用户名和密码等信息。
	还可以在页面内生成浮窗广告，这些广告会严重地影响用户体验。

类型

1、反射型:SS代码出现在url中，作为输入提交到服务器端，服务器端解析后响应，XSS代码随响应内容一起传回给浏览器，最后浏览器解析执行XSS代码。这个过程像一次反射，	所以叫反射型XSS
2、存储型:具有攻击性的脚本被保存到了服务器端（数据库，内存，文件系统）并且可以被普通用户完整的从服务的取得并执行，从而获得了在网络上传播的能力。
3、DOM型：即基于DOM或本地的 XSS 攻击：其实是一种特殊类型的反射型 XSS，它是基于 DOM文档对象模型的一种漏洞。可以通过 DOM来动态修改页面内容，从客户端获取 DOM中的数据并在本地执行。

防御措施

(1)输入过滤
(2)输入转义
(3)使用HttpOnly Cookie
	将重要的cookie标记为httponly，这样的话当浏览器向Web服务器发起请求的时就会带上cookie字段，但是在js脚本中却不能访问这个cookie，这样就避免了XSS攻击利用JavaScript的document.cookie获取cookie
(4)、充分利用CSP（Content-Security-Policy）
	限制加载其他域下的资源文件，这样即使黑客插入了一个 JavaScript 文件，这个 JavaScript 文件也是无法被加载的；
	禁止向第三方域提交数据，这样用户数据也不会外泄；
	禁止执行内联脚本和未授权的脚本；
	还提供了上报机制，这样可以帮助我们尽快发现有哪些 XSS 攻击，以便尽快修复问题。

3、CSRF(跨站伪造请求)

CSRF 顾名思义，是伪造请求，冒充用户在站内的正常操作。我们知道，绝大多数网站是通过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。

CSRF攻击攻击原理及过程如下：

1.  用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
2.  在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；
3.  用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；
4.  网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
5.  浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

防范

（1）验证 HTTP Referer 字段，利用 HTTP 头中的 Referer 判断请求来源是否合法，Referer记录了该 HTTP 请求的来源地址。
（2）在请求地址中添加 token 并验证。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
（3）在 HTTP 头中自定义属性并验证，通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中
（4）利用SameSite， 
	SameSite = Strict ：完全禁止第三方cookies
	SameSite=Lax:在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交 Get 方式的表单这两种方式都会携带 Cookie，但如果在第三方站点中使用 Post 方法，或者通过 img、iframe 等标签加载的 URL，这些场景都不会携带 Cookie。
	SameSite=None:都会发送

5、Cookies和Session

	* Session:就是客户端请求服务端时，服务端为这次请求开辟的一块`内存对象`。服务器会利用 session **存储客户端在同一个会话期间的一些操作记录**。会话结束就失效，Session是基于cookie的机制完成的（一个会话结束就过期的cookie）
  缺点：比如 A 服务器存储了 Session，就是做了负载均衡后，假如一段时间内 A 的访问量激增，会转发到 B 进行访问，但是 B 服务器并没有存储 A 的 Session，会导致 Session 的失效。

	* cookies：它是服务器发送到 Web 浏览器的一小块数据。服务器发送到浏览器的 Cookie，浏览器会进行存储，并与下一个请求一起发送到服务器。通常，它用于判断两个请求是否来自于同一个浏览器，例如用户保持登录状态。
  * cookie主要用于会话管理（登录，购物车等），个性化（用户习惯），追踪（记录分析用户行为）
  * cookie有两种： 
    * Session Cookies，没有到期日期，存在内存中，浏览器关闭就丢失（但浏览器可能会还原）
    * Persistent Cookies：有有效期，存在硬盘中，到期就删除

如何防范Cookies被窃取

1） 方法一：
给Cookie添加HttpOnly属性, 这种属性设置后, 只能在http请求中传递, 在脚本中, document.cookie无法获取到该Cookie值. 对XSS的攻击, 有一定的防御值. 但是对网络拦截, 还是泄露了.
2）方法二：
在cookie中添加校验信息, 这个校验信息和当前用户外置环境有些关系,比如ip,user agent等有关. 这样当cookie被人劫持了, 并冒用, 但是在服务器端校验的时候, 发现校验值发生了变化, 因此要求重新登录, 这样也是种很好的思路, 去规避cookie劫持.
3）方法三：
cookie中session id的定时更换, 让session id按一定频率变换, 同时对用户而言, 该操作是透明的, 这样保证了服务体验的一致性.

6、浏览器内多个标签页之间的通讯

第一种——调用localStorage

在一个标签页里面使用 localStorage.setItem(key,value)添加（修改、删除）内容； 
在另一个标签页里面监听 storage 事件。 即可得到 localstorge 存储的值，实现不同标签页之间的通信。     
在一个标签页调用`localStorage.setItem(name,val)`保存数据`localStorage.removeItem(name)`删除数据的时候会触发 'storage'事件。
在另外一个标签页监听document对象的storage事件，在事件event对象属性中获取信息

第二种——调用 cookie+setInterval()

将要传递的信息存储在cookie中，每隔一定时间读取cookie信息，即可随时获取要传递的信息。
在A页面将需要传递的消息存储在cookie当中
在B页面设置setInterval，以一定的时间间隔去读取cookie的值。

监听服务器事件

**第一种 websocket通讯**
WebSocket是HTML5新增的协议，它的目的是在浏览器和服务器之间建立一个不受限的双向通信的通道
**第二种  html5浏览器的新特性SharedWorker**
普通的webworker直接使用new Worker()即可创建，这种webworker是当前页面专有的

7、fetch与axios

（1）、fetch

fetch 是一个低层次的API，可以把它考虑成原生的XHR，浏览器提供的api

优势：

1. 语法简洁，更加语义化
2. 基于标准 Promise 实现，支持 async/await 
3. 更加底层，提供的API丰富（request, response）
4. 脱离了XHR，是ES规范里新的实现方式

存在问题：

1、fetch只对网络请求报错，对400，500都当做成功的请求
2、fetch默认不会带cookie，需要添加配置项： fetch(url, {credentials: 'include'})
3、fetch不支持abort，不支持超时控制，使用setTimeout及Promise.reject的实现的超时控制并不能阻止请求过程继续在后台运行，造成了流量的浪费
4、fetch没有办法原生监测请求的进度，而XHR可以

（2）、axios

axios 是一个基于Promise 用于浏览器和 nodejs 的 HTTP 客户端，本质上也是对原生XHR的封装，只不过它是Promise的实现版本，

特征：

1. 从浏览器中创建 XMLHttpRequest
2. 支持 Promise API
3. 客户端支持防止CSRF
4. 提供了一些并发请求的接口（重要，方便了很多的操作）
5. 从 node.js 创建 http 请求
6. 拦截请求和响应
7. 转换请求和响应数据
8. 取消请求
9. 自动转换JSON数据

原生AJAX使用

  var xhr =new XMLHttpRequest()
      /*   xhr.open('GET','http://127.0.0.1:8000/test',true)
        xhr.send(null) */
        xhr.open("POST",'http://127.0.0.1:8000/test',true)
        xhr.setRequestHeader('Content-Type','application/json')
        xhr.send(JSON.stringify({req:123}))
        var box = document.getElementById('box')
        xhr.onreadystatechange=function(){
            if(xhr.readyState===4){
                if(xhr.status>=200&&xhr.status<300||xhr.status==304){
                    console.log(xhr.responseText)
                    var text = JSON.parse(xhr.responseText)
                    box.innerHTML=text.res
                }else{
                    console.log(xhr.status)
                }
            }
        }
        // 网络异常回调
        xhr.onerror = function(){
           console.log("网络出错")
        }
        // 超时
        xhr.timeout =2000
        xhr.ontimeout = function(){
            alert("请求超时")
        }

使用promise封装AJAX

  var ajax = function (url) {
            return new Promise((resolve, reject) => {
                var xhr = new XMLHttpRequest()
                xhr.open("GET", url, true)
                xhr.send()
                xhr.onload = function () {
                    if (xhr.readyState === 4) {
                        if (xhr.status >= 200 && xhr.status < 300 || xhr.status == 304) {
                            resolve(xhr.response)
                        } else {
                            reject(xhr.status)
                        }
                    }
                }
                xhr.onerror = function (){
                    reject(xhr.status)
                }

            })
        }

7、缓存控制

Web 缓存大致可以分为：数据库缓存、服务器端缓存（代理服务器缓存、CDN 缓存）、浏览器缓存。

浏览器缓存主要是 HTTP 协议定义的缓存机制。HTML meta 标签

浏览器加载页面的简单流程

1. 浏览器先根据这个资源的http头信息来判断是否命中强缓存。如果命中则直接加在缓存中的资源，并不会将请求发送到服务器。（强缓存）
2. 如果未命中强缓存，则浏览器会将资源加载请求发送到服务器。服务器来判断浏览器本地缓存是否失效。若可以使用，则服务器并不会返回资源信息，浏览器继续从缓存加载资源。（协商缓存）
3. 如果未命中协商缓存，则服务器会将完整的资源返回给浏览器，浏览器加载新资源，并更新缓存。（新的请求）

强缓存

命中强缓存时，浏览器并不会将请求发送给服务器。在Chrome的开发者工具中看到http的返回码是200，但是在Size列会显示为(from cache)。
强缓存是利用http的返回头中的Expires或者Cache-Control两个字段来控制的，用来表示资源的缓存时间。
Expires:缓存过期时间，是服务器端的具体的时间点。也就是说，Expires=max-age + 请求时间需要和Last-modified结合使用
	缺点：需要客户端与服务端时间一致才准确
Cache-Control：l是一个`相对时间`，是一段有效期，同时启用的时候Cache-Control优先级高。
	取值:1.max-age:指定一个时间长度
		2. s-maxage 同 max-age，覆盖 max-age、Expires，但仅适用于共享缓存，在私有缓存中被忽略。
		3.public表明响应可以被任何对象（发送请求的客户端、代理服务器等等）缓存。
		4.private表明响应只能被单个用户（可能是操作系统用户、浏览器用户）缓存，是非共享的，不能被代理服务器缓存。
		5.no-cache强制所有缓存了该响应的用户，在使用已缓存的数据前，发送带验证器的请求到服务器。不是字面意思上的不缓存。
		6.no-store禁止缓存，每次请求都要向服务器重新获取数据。
		7.must-revalidate指定如果页面是过期的，则去服务器进行获取。这个指令并不常用，就不做过多的讨论了

协商缓存

未命中强缓存，则浏览器会将请求发送至服务器。服务器根据http头信息中的Last-Modify/If-Modify-Since或Etag/If-None-Match来判断是否命中协商缓存。

Last-Modify/If-Modify-Since

Last-modify是一个时间标识该资源的最后修改时间

ETag/If-None-Match

Etag/If-None-Match返回的是一个校验码（ETag: entity tag），资源变化时改变

既生Last-Modified何生Etag？

1、Last-Modified标注的最后修改只能精确到秒级
2、如果某些文件会被定期生成，当有时内容并没有任何变化，但Last-Modified却改变了，导致文件没法使用缓存
3、有可能存在服务器没有准确获取文件修改时间，或者与代理服务器时间不一致等情形