1.TCP/IP 的三次握手和四次挥手
三次握手:? ?
第一次握手: 客户端向服务端发送 SYN 码数据包, 表示客户端要求和服务端建立连接;
第二次握手: 服务端收到客户端的连接请求后, 会发送 ACK 数据包给客户端, 表示你的连接 请求已经收到, 询问客户端是否真的需要建立连接;
第三次握手: 客户端收到 ACK 码以后会检验是否正确, 如果正确, 客户端会再次发送 ACK 码给 服务端, 表示确认建立连接; (三次握手都成功以后才会建立连接, 然后才会发送数据;)
四次挥手:
第一次挥手: 当客户端发送数据结束后, 会发送 FIN 码数据包给服务端, 表示告知服务端客 户端的数据已经传递完了.
第二次挥手: 当服务端收到 FIN 后, 会发送 ACK 给客户端, 表示服务端已经知道客户端传完 了. 客户端收到 ACK 以后就会把传递数据给服务端的通道关闭;
第三次挥手: 当服务端把响应的数据发送完毕后, 会发送一个 FIN 给客户端, 告知客户端响 应的数据已经发送完毕;
第四次挥手: 当客户端收到 FIN 后, 会发送一个 ACK 码数据包给服务端, 告知服务端客户端已 经知道数据发送完毕; 服务端收到 ACK 码后, 可以安心的把数据传递通道关闭掉.
2.HTTPS 和 HTTP 的区别主要如下?
HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输, 身份认证的网络协议, 要比 http 协议安全.
1,https 协议需要到 ca 申请证书, 一般免费证书较少, 因而需要一定费用.
2,http 是超文本传输协议, 信息是明文传输, https 则是具有安全性的 ssl 加密传输协议.
3,http 和 https 使用的是完全不同的连接方式, 用的端口也不一样, 前者是 80, 后者是 443.
4,http 的连接很简单, 是无状态的; HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输, 身份认证的网络协议, 比 http 协议安全.
https 主要解决三个安全问题:
1. 内容隐私
2. 防篡改
3. 确认对方身份
https 并不是直接通过非对称加密传输过程, 而是有握手过程, 握手过程主要是和服务器做通讯, 生成私有秘钥, 最后通过该秘钥对称加密传输数据.
还有验证证书的正确性. 证书验证过程保证了对方是合法的, 并且中间人无法通过伪造证书方式进行攻击.
3. 从浏览器输入 URL 按回车到页面显示都发生了什么?
? 浏览器根据 URL 进行 DNS 查询
? 首先从 DNS 缓存中查询
? 若未在缓存中找到, 则不停的向上一级级请求 DNS 服务器
? 取得 IP 地址, 建立 TCP 连接
? 构造 HTTP 请求报
? 添加一些 HTTP 首部
? 根据同源策略添加 cookie
? 在 TCP 连接上发送 HTTP 报文, 等待响应
? 服务器处理 HTTP 请求报文, 返回响应 HTTP 响应报文
? 浏览器处理服务器返回的 HTTP 响应报文, 若为 html 则渲染页面, 不包括脚本的简单渲染流程如下
1. 解析 DOM,CSSOM
2. 根据 DOM,CSSOM 计算 render tree
3. 根据 render tree 进行 layout
4.paint, 至此, 用户可以看到页面了
4. 浏览器缓存?
强缓存: 不会向服务器发送请求, 直接从缓存中读取资源, 在 Chrome 控制台的 Network 选项中可以看到该请求返回 200 的状态码,
并且 Size 显示 from disk cache 或 from memory cache. 强缓存可以通过设置两种 HTTP Header 实现: Expires 和 Cache-Control.
协商缓存: 就是强制缓存失效后, 浏览器携带缓存标识向服务器发起请求, 由服务器根据缓存标识决定是否使用缓存的过程, 主要有以下两种情况:
协商缓存生效, 返回 304 和 Not Modified
协商缓存失效, 返回 200 和请求结果协商缓存可以通过设置两种 HTTP Header 实现: Last-Modified 和 ETag .
?
强制缓存优先于协商缓存进行, 若强制缓存 (Expires 和 Cache-Control) 生效则直接使用缓存, 若不生效则进行协商缓存 (Last-Modified / If-Modified-Since 和 Etag / If-None-Match), 协商缓存由服务器决定是否使用缓存, 若协商缓存失效, 那么代表该请求的缓存失效, 返回 200, 重新返回资源和缓存标识, 再存入浏览器缓存中; 生效则返回 304, 继续使用缓存.
5.Ajax 四步
创建 XMLHttpRequest 对象, 也就是创建一个异步调用对象
创建一个新的 HTTP 请求, 并指定该 HTTP 请求的方法, URL 及验证信息
设置响应 HTTP 请求状态变化的函数
发送 HTTP 请求
你使用过哪些 Ajax?
从原生的 XHR 到 jQuery Ajax, 再到现在的 axios 和 fetch.
axios 和 fetch 都是基于 Promise 的, 一般我们在使用时都会进行二次封装
讲到 fetch 跟 jQuery Ajax 的区别, 这也是它很奇怪的地方
当接收到一个代表错误的 HTTP 状态码时, 从 fetch() 返回的 Promise 不会被标记为 reject, 即使该 HTTP 响应的状态码是 404 或 500. 相反, 它会将 Promise 状态标记为 resolve (但是会将 resolve 的返回值的 ok 属性设置为 false ), 仅当网络故障时或请求被阻止时, 才会标记为 reject. 默认情况下, fetch 不会从服务端发送或接收任何 cookies, 如果站点依赖于用户 session, 则会导致未经认证的请求 (要发送 cookies, 必须设置 credentials 选项)
一般我们再拦截器中都会写什么代码?
请求拦截中我们一半会把 token 写在这里, 这样的话就不用每次请求都要写这个参数
还会做一个数据格式的处理, 假如某个参数需要统一处理 可以放在这里,
响应拦截一半会做一个判断 请求失败的话直接调用失败提示框 这样不用每个接口都写同样的代码
也会再 return 时 return reponse.data; 这样就可以不用每个数据接受的时候都加一个 data.data
get 请求和 post 请求有什么区别? 什么时候使用 post?
GET: 一般用于信息获取, 使用 URL 传递参数, 对所发送信息的数量也有限制, 一般在 2000 个字符
? POST: 一般用于修改服务器上的资源, 对所发送的信息没有限制 ?
在以下情况中, 请使用 POST 请求: 1. 无法使用缓存文件 (更新服务器上的文件或数据库) 2. 向服务器发送大量数据 (POST 没有数据量限制) 3. 发送包含未知字符的用户输入时, POST 比 GET 更稳定也更可靠
实际上 HTTP 协议从未规定 GET/POST 的请求长度限制是多少. 对 get 请求参数的限制是来源与浏览器或 web 服务器, 浏览器或 Web 服务器限制了 url 的长度. 为了明确这个概念, 我们必须再次强调下面几点:
1,HTTP 协议 未规定 GET 和 POST 的长度限制
2,GET 的最大长度显示是因为 浏览器和 Web 服务器限制了 URI 的长度
3, 不同的浏览器和 Web 服务器, 限制的最大长度不一样
4, 要支持 IE, 则最大长度为 2083byte, 若只支持 Chrome, 则最大长度 8182byte
Cookie 和 Session 的区别?
? 安全性: Session 比 Cookie 安全, Session 是存储在服务器端的, Cookie 是存储在客户端的.
? 存取值的类型不同: Cookie 只支持存字符串数据, 想要设置其他类型的数据, 需要将其转换成字符串, Session 可以存任意数据类型.
? 有效期不同: Cookie 可设置为长时间保持, 比如我们经常使用的默认登录功能, Session 一般失效时间较短, 客户端关闭 (默认情况下) 或者 Session 超时都会失效.
? 存储大小不同: 单个 Cookie 保存的数据不能超过 4K,Session 可存储数据远高于 Cookie, 但是当访问量过多, 会占用过多的服务器资源.
Token 相关?
客户端使用用户名跟密码请求登录
服务端收到请求, 去验证用户名与密码
验证成功后, 服务端会签发一个 token 并把这个 token 发送给客户端
客户端收到 token 以后, 会把它存储起来, 比如放在 cookie 里或者 localStorage 里
客户端每次向服务端请求资源的时候需要带着服务端签发的 token
服务端收到请求, 然后去验证客户端请求里面带着的 token , 如果验证成功, 就向客户端返回请求的数据
? 每一次请求都需要携带 token, 需要把 token 放到 HTTP 的 Header 里
? 基于 token 的用户认证是一种服务端无状态的认证方式, 服务端不用存放 token 数据. 用解析 token 的计算时间换取 session 的存储空间, 从而减轻服务器的压力, 减少频繁的查询数据库
? token 完全由应用管理, 所以它可以避开同源策略
什么是同源策略?
同源策略是客户端脚本 (尤其是 JavaScript) 的重要的安全度量标准. 其目的是防止某个文档或脚本从多个不同源装载.
? 这里的同源策略指的是: 协议, 域名, 端口相同, 同源策略是一种安全协议, 指一段脚本只能读取来自同一来源的窗口和文档的属性.
为什么要有同源限制?
我们举例说明: 比如一个黑客程序, 他利用 Iframe 把真正的银行登录页面嵌到他的页面上, 当你使用真实的用户名, 密码登录时, 他的页面就可以通过 JavaScript 读取到你的表单中 input 中的内容, 这样用户名, 密码就轻松到手了
工作中是怎么解决跨域的?
1.JSONP
JSONP 原理
利用
来源: http://www.bubuko.com/infodetail-3655538.html