浏览器
2020-06-05 14:16:42 2 举报AI智能生成
前端面试 浏览器 网络
作者其他创作
大纲/内容
cookie
.Cookie的来源
Cookie 的本职工作并非本地存储，而是“维持状态”。
因为HTTP协议是无状态的，HTTP协议自身不对请求和响应之间的通信状态进行保存
因为HTTP协议是无状态的，HTTP协议自身不对请求和响应之间的通信状态进行保存
在 Web 开发的早期，人们亟需解决的一个问题就是状态管理的问题：HTTP 协议是一个无状态协议，服务器接收客户端的请求，返回一个响应，故事到此就结束了，服务器并没有记录下关于客户端的任何信息。那么下次请求的时候，如何让服务器知道“我是我”呢？
在这样的背景下，Cookie 应运而生。
Cookie 说白了就是一个存储在浏览器里的一个小小的文本文件，它附着在 HTTP 请求上，在浏览器和服务器之间“飞来飞去”。它可以携带用户信息，当服务器检查 Cookie 的时候，便可以获取到客户端的状态。
在这样的背景下，Cookie 应运而生。
Cookie 说白了就是一个存储在浏览器里的一个小小的文本文件，它附着在 HTTP 请求上，在浏览器和服务器之间“飞来飞去”。它可以携带用户信息，当服务器检查 Cookie 的时候，便可以获取到客户端的状态。
什么是Cookie
Cookie指某些网站为了辨别用户身份而储存在用户本地终端上的数据(通常经过加密)。
cookie是服务端生成，客户端进行维护和存储
cookie是服务端生成，客户端进行维护和存储
应用场景
- 记住密码，下次自动登录
- 购物车功能
- 记录用户浏览数据，进行商品（广告）推荐
原理
当用户第一次访问并登陆一个网站的时候，
cookie的设置以及发送会经历以下4个步骤
cookie的设置以及发送会经历以下4个步骤
1、客户端发送一个请求到服务器
2、服务器发送一个HttpResponse响应到客户端，其中包含Set-Cookie的头部
3、客户端保存cookie，之后向服务器发送请求时，HttpRequest请求中会包含一个Cookie的头部
4、服务器返回响应数据
2、服务器发送一个HttpResponse响应到客户端，其中包含Set-Cookie的头部
3、客户端保存cookie，之后向服务器发送请求时，HttpRequest请求中会包含一个Cookie的头部
4、服务器返回响应数据
图示
生成方式
生成方式一：http response header中的set-cookie
生成方式二：js中可以通过document.cookie可以读写cookie，以键值对的形式展示
缺陷
Cookie 不够大
当 Cookie 超过 4KB 时，它将面临被裁切的命运
很多浏览器对一个站点的cookie个数也是有限制的
注意
各浏览器的cookie每一个name=value的value值大概在4k，
所以4k并不是一个域名下所有的cookie共享的，而是一个name的大小
所以4k并不是一个域名下所有的cookie共享的，而是一个name的大小
过多的 Cookie 会带来巨大的性能浪费
Cookie 是紧跟域名的。同一个域名下的所有请求，都会携带 Cookie。大家试想，如果我们此刻仅仅是请求一张图片或者一个 CSS 文件，我们也要携带一个 Cookie 跑来跑去（关键是 Cookie 里存储的信息并不需要），这是一件多么劳民伤财的事情。Cookie 虽然小，请求却可以有很多，随着请求的叠加，这样的不必要的 Cookie 带来的开销将是无法想象的。
cookie是用来维护用户信息的，而域名(domain)下所有请求都会携带cookie，但对于静态文件的请求，携带cookie信息根本没有用，此时可以通过cdn（存储静态文件的）的域名和主站的域名分开来解决
cookie是用来维护用户信息的，而域名(domain)下所有请求都会携带cookie，但对于静态文件的请求，携带cookie信息根本没有用，此时可以通过cdn（存储静态文件的）的域名和主站的域名分开来解决
由于在HTTP请求中的Cookie是明文传递的，所以安全性成问题，除非用HTTPS
安全
HttpOnly
HttpOnly 不支持读写，浏览器不允许脚本操作document.cookie去更改cookie，
所以为避免跨域脚本 (XSS) 攻击，通过JavaScript的 Document.cookie API无法访问带有 HttpOnly 标记的Cookie，它们只应该发送给服务端。如果包含服务端 Session 信息的 Cookie 不想被客户端 JavaScript 脚本调用，那么就应该为其设置 HttpOnly 标记。
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
所以为避免跨域脚本 (XSS) 攻击，通过JavaScript的 Document.cookie API无法访问带有 HttpOnly 标记的Cookie，它们只应该发送给服务端。如果包含服务端 Session 信息的 Cookie 不想被客户端 JavaScript 脚本调用，那么就应该为其设置 HttpOnly 标记。
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
Secure
标记为 Secure 的Cookie只应通过被HTTPS协议加密过的请求发送给服务端。
但即便设置了 Secure 标记，敏感信息也不应该通过Cookie传输，因为Cookie有其固有的不安全性，Secure 标记也无法提供确实的安全保障。
但即便设置了 Secure 标记，敏感信息也不应该通过Cookie传输，因为Cookie有其固有的不安全性，Secure 标记也无法提供确实的安全保障。
存储
存储方式总结
sessionStorage 、localStorage 和 cookie 之间的区别
共同点：都是保存在浏览器端，且都遵循同源策略。
不同点：在于生命周期与作用域的不同
不同点：在于生命周期与作用域的不同
缓存
协商缓存 强缓存
HTTP缓存图示
cache-control
跨域
什么是跨域
广义
跨域是指一个域下的文档或脚本试图去请求另一个域下的资源
狭义
由浏览器同源策略限制的一类请求场景
同源策略
"协议+域名+端口"三者相同
有什么用？
它是浏览器最核心也最基本的安全功能，
如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击
如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击
解决方案
1. 通过jsonp跨域
2. document.domain + iframe跨域
3. location.hash + iframe
4. window.name + iframe跨域
5. postMessage + iframe
6. 跨域资源共享（CORS）
7. nginx代理跨域
8. nodejs中间件代理跨域
9. WebSocket协议跨域
2. document.domain + iframe跨域
3. location.hash + iframe
4. window.name + iframe跨域
5. postMessage + iframe
6. 跨域资源共享（CORS）
7. nginx代理跨域
8. nodejs中间件代理跨域
9. WebSocket协议跨域
常用解决方案
jsonp
原理
利用script标签不受跨域限制，向跨域服务接口发送一个带参数的请求；
参数中包括跨域回调函数的名称，服务端返回改函数执行的代码并将请求数据作为参数返回
参数中包括跨域回调函数的名称，服务端返回改函数执行的代码并将请求数据作为参数返回
缺点
1、它只支持GET请求而不支持POST等其它类型的HTTP请求
2、它只支持跨域HTTP请求这种情况，不能解决不同域的两个页面之间如何进行JavaScript调用的问题。
3、 jsonp在调用失败的时候不会返回各种HTTP状态码。
4、缺点是安全性。万一假如提供jsonp的服务存在页面注入漏洞，即它返回的javascript的内容被人控制的。
那么结果是什么？所有调用这个 jsonp的网站都会存在漏洞。
2、它只支持跨域HTTP请求这种情况，不能解决不同域的两个页面之间如何进行JavaScript调用的问题。
3、 jsonp在调用失败的时候不会返回各种HTTP状态码。
4、缺点是安全性。万一假如提供jsonp的服务存在页面注入漏洞，即它返回的javascript的内容被人控制的。
那么结果是什么？所有调用这个 jsonp的网站都会存在漏洞。
CORS
CORS需要浏览器和服务器同时支持
整个CORS通信过程，都是浏览器自动完成，不需要用户参与。
对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。
浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。
因此，实现CORS通信的关键是服务器。
对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。
浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。
因此，实现CORS通信的关键是服务器。
服务器响应头配置
● Access-Control-Allow-Origin: 'http://a.guazi.com:4000' // 允许请求域
● Access-Control-Allow-Headers: 'name,Content-Type' // 允许携带请求头
● Access-Control-Allow-Methods: 'GET,POST,PUT,DELETE,OPTIONS,HEAD' // 允许请求方法
● Access-Control-Allow-Credentials: true // 允许携带cookie
● Access-Control-Expose-Headers: 'name' // 允许设置的响应头
● Access-Control-Max-Age: '10' // OPTIONS预校验请求时效 单位：秒
● Access-Control-Allow-Headers: 'name,Content-Type' // 允许携带请求头
● Access-Control-Allow-Methods: 'GET,POST,PUT,DELETE,OPTIONS,HEAD' // 允许请求方法
● Access-Control-Allow-Credentials: true // 允许携带cookie
● Access-Control-Expose-Headers: 'name' // 允许设置的响应头
● Access-Control-Max-Age: '10' // OPTIONS预校验请求时效 单位：秒
普通跨域请求
服务端设置Access-Control-Allow-Origin即可，前端无须设置，
若要带cookie请求：前后端都需要设置
若要带cookie请求：前后端都需要设置
常用头
通用头
请求头
响应头
实体头
状态码
状态码分类
常用状态码
请求方法
表格
HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
两种请求
浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）
分类
简单请求
需要满足两大条件
请求方法是以下三种方法之一
HEAD
GET
POST
GET
POST
HTTP的头信息不超出以下几种字段
Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type：只限于三个值application/x-www-form-urlencoded、
multipart/form-data、text/plain
Accept-Language
Content-Language
Last-Event-ID
Content-Type：只限于三个值application/x-www-form-urlencoded、
multipart/form-data、text/plain
复杂请求
凡是不同时满足上面两个条件，就属于非简单请求
get与post请求的区别
使用区别
- GET请求参数放在URL上，POST请求参数放在请求体里
- GET请求参数长度有限制，POST请求参数长度可以非常大
- POST请求相较于GET请求安全一点点，因为GET请求的参数在URL上，且有历史记录
- GET请求能缓存，POST不能
本质区别
5. GET和POST最大的区别主要是GET请求是幂等性的，POST请求不是。
由于GET请求是幂等的，在网络不好的环境中，GET请求可能会重复尝试，造成重复操作数据的风险，
因此，GET请求用于无副作用的操作(如搜索)，新增/删除等操作适合用POST
因此，GET请求用于无副作用的操作(如搜索)，新增/删除等操作适合用POST
http https
0 条评论
下一页
