（十一）-前端-javaScript网络

10.http&ajax

1.TCP/IP****的三次握手和四次挥手

三次握手:

第一次握手：客户端向服务端发送SYN码数据包，表示客户端要求和服务端建立连接；

第二次握手：服务端收到客户端的连接请求后，会发送ACK数据包给客户端，表示你的连接 请求已经收到，询问客户端是否真的需要建立连接；

第三次握手：客户端收到ACK码以后会检验是否正确，如果正确，客户端会再次发送ACK码给 服务端，表示确认建立连接； (三次握手都成功以后才会建立连接，然后才会发送数据；)

四次挥手：

第一次挥手：当客户端发送数据结束后，会发送FIN码数据包给服务端，表示告知服务端客 户端的数据已经传递完了。

第二次挥手：当服务端收到FIN后，会发送ACK给客户端，表示服务端已经知道客户端传完 了。客户端收到ACK以后就会把传递数据给服务端的通道关闭；

第三次挥手：当服务端把响应的数据发送完毕后，会发送一个FIN给客户端，告知客户端响 应的数据已经发送完毕；

第四次挥手：当客户端收到FIN后，会发送一个ACK码数据包给服务端，告知服务端客户端已 经知道数据发送完毕；服务端收到ACK码后，可以安心的把数据传递通道关闭掉。

2.http****常用状态码(http-status-code):

2xx:表示成功

200 OK 表示所有东西都正常

204 表示请求成功,但是服务端没有内容给你

3xx: 表示重定向

301 永久重定向(当访问一个永久重定向的网站的时候,一个域名被指向一个其他网站,且是永久的)

302 临时重定向

304 走缓存(服务端觉得你之前请求过这个东西,而且服务器上的那一份没有发生变化,告诉客户端用缓存 就行)

· 301，Moved Permanently。永久重定向，该操作比较危险，需要谨慎操作：如果设置了301，但是一段时间后又想取消，但是浏览器中已经有了缓存，还是会重定向。

· 302，Fount。临时重定向，但是会在重定向的时候改变 method: 把 POST 改成 GET，于是有了 307

· 307，Temporary Redirect。临时重定向，在重定向时不会改变 method

4xx: 表示客户端错误

400 参数传递不当,导致的错误

401 权限不够导致的

403 服务端已经理解请求,但是拒绝响应

404 客户端请求的资源或者数据不存在(发现请求接口404,有两种情况一种是咱们写错接口了或者服 务端还没部署)

5xx: 表示服务端错误(遇到以5开头的错误去找服务端错误)

500 服务端内部错误

502 网关错误

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.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并不是直接通过非对称加密传输过程，而是有握手过程，握手过程主要是和服务器做通讯，生成私有秘钥，最后通过该秘钥对称加密传输数据。还有验证证书的正确性。 证书验证过程保证了对方是合法的，并且中间人无法通过伪造证书方式进行攻击。

5.****浏览器缓存？

强缓存：不会向服务器发送请求，直接从缓存中读取资源，在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，继续使用缓存。

6.ajax****四步

1. 创建 XMLHttpRequest 对象,也就是创建一个异步调用对象

2. 创建一个新的 HTTP 请求,并指定该 HTTP 请求的方法、URL 及验证信息

3. 设置响应 HTTP 请求状态变化的函数

4. 发送 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 相关？

1. 客户端使用用户名跟密码请求登录

2. 服务端收到请求，去验证用户名与密码

3. 验证成功后，服务端会签发一个 token 并把这个 token 发送给客户端

4. 客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里

5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 token

6. 服务端收到请求，然后去验证客户端请求里面带着的 token ，如果验证成功，就向客户端返回请求的数据

· 每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里

· 基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库

· token 完全由应用管理，所以它可以避开同源策略

什么是同源策略？

同源策略是客户端脚本（尤其是 Javascript）的重要的安全度量标准。其目的是防止某个文档或脚本从多个不同源装载。 这里的同源策略指的是：协议，域名，端口相同，同源策略是一种安全协议，指一段脚本只能读取来自同一来源的窗口和文档的属性。

为什么要有同源限制？

我们举例说明：比如一个黑客程序，他利用 Iframe 把真正的银行登录页面嵌到他的页面上，当你使用真实的用户名，密码登录时，他的页面就可以通过 Javascript 读取到你的表单中 input 中的内容，这样用户名，密码就轻松到手了

工作中是怎么解决跨域的？

1.jsonp

1. JSONP原理

利用