网络资料（忘传了）

1网络分层模型和应用协议

1.1分层模型

1.1.1分层的意义

当遇到一个复杂问题的时候，可以使用分层的思想把问题简单化

比如，你有半杯82年的可乐，想分享给你的朋友王富贵，但你们已经10年没有联系了。要完成这件事，你可能要考虑：

我用什么装可乐？

可能的方案：塑料瓶、玻璃瓶、煤气罐
怎么保证可乐始终处于低温？

可能的方案：保温杯、小冰箱、冰盒
如何保证可乐不被运输的人偷喝？

可能的方案：封条、在上面写「毒药」
如何获取王富贵的地址？

可能的方案：报案失踪、联系私人侦探、联系物流公司的朋友
如何运输？

可能的方案：自行车、汽车、火车、高铁、飞机、火箭

这就形成了一个分层结构

从常理出发，我们可以得出以下结论：

每层相对独立，只需解决自己的问题
每层无须考虑上层的交付，仅需把自己的结果交给下层即可
每层有多种方案可供选择，选择不同的方案不会对上下层造成影响
每一层会在上一层的基础上增加一些额外信息

1.1.2五层网络模型

网络要解决的问题是：两个程序之间如何交换数据。

这是一个非常复杂的问题，因为两个程序有可能出现在不同的设备上。

面对复杂的问题，可以使用分层的方式来简化。

经过不断的演化，网络最终形成了五层模型：

UDP不可靠

MAC地址有手段改，但一般不改

华为涉及到下面三层，制定标准利润很高

1.1.3数据的传输

数据链路层前后都会加东西

物理层通过物理介质或电磁波传递

1.1.4四层、五层、七层

第一个是公司制定，第二个国际组织插手，七层不好用又改五层，七层是错的

前端工程师主要聊的是应用层

网络工程师是传输层、网络层、物理链路层

1.2应用层协议

1.2.1URL（用什么东西来描述对方在哪）

URL（uniform resource locator，统一资源定位符）用于定位网络服务

URL是一个固定格式的字符串

它表达了：

从网络中哪台计算机（domain）中的哪个程序（port）寻找哪个服务（path），并注明了获取服务的具体细节（path），以及要用什么样的协议通信（schema）

这里面包含了一些细节：

当协议是http端口为80时，端口可以省略
当协议是https端口为443时，端口可以省略（比如百度就是www.baidu.com:443）
schema、domain、path是必填的，其他的根据具体的要求填写

http://localhost:5500 /index.html能显示页面，能不能表示这个机器上有index.html这个文件？

不能，因为网络通信不是依靠文件，人家只是很正常的整了个index.html，这种文件当路径的叫静态资源服务器

在这里插入图片描述

这样写页面是显示一张图片

在这里插入图片描述

超链接最后加个/，减少浏览器补全的时间

补全的话，浏览器怎么知道是http还是https？浏览器有缓存，浏览器一般先用http试，如果网站支持https，则自动跳转，

1.2.2HTTP

超文本传输协议（Hyper Text Transfer Protocol，HTTP）是一个广泛运用于互联网的应用层协议。

99%的情况下，前端开发者接触的都是HTTP协议。

该协议规定了两个方面的内容：

传递消息的模式
传递消息的格式

1.2.2.1传递消息的模式

HTTP使用了一种极为简单的消息传递模式，「请求-响应」模式

发起请求的称之为客户端，接收请求并完成响应的称之为服务器。

「请求-响应」完成后，一次交互结束。

1.2.2.2传递消息的格式

webstorm自己发请求吧

在这里插入图片描述

HTTP的消息格式是一种纯文本的格式，文本分为三个部分：

请求行
请求头

请求体

具体每一部分写什么内容，要看具体的服务要求

1.2.2.3试一试

有非常多的工具可以发送http请求，这里推荐一个非常直观的工具

安装vscode插件REST Clinet
新建文件xxx.http

编写请求文本

POST /api/user/login HTTP/1.1
Host: study.duyiedu.com
Content-Type: application/json

{
  "loginId":"admin",
  "loginPwd":"123123"
}

发送请求

1.2.2.4熟悉关键信息

请求方法

请求行中的第一个单词是请求方法

在HTTP协议中，请求方法仅有语义的区别，只是表达了这次请求的「愿望」。

关于请求方法的协议原文见 HTTP/1.1规范RFC7231-Chapter4

比如GET表达了客户端想要获取一些东西，POST表达了客户端想要提交一些东西

常见的请求方法有：

GET：获取
POST：提交
PUT：修改
DELETE：删除

具体在开发中应该选择什么请求方法，一定是看服务方的要求

通常情况下：

获取数据一般使用GET
提交数据一般使用POST
各种静态资源的获取，一般使用GET

请求头 - `Host`

Host标注了URL地址中的Domain + Port

示例：

Host: study.duyiedu.com

请求头 - `Content-Type`

Content-Type标注了附带的请求体是什么格式

比如，请求体的数据为loginId:admin, loginPwd:123456，请求体可以用不同的格式发出，需要换行

Content-Type: application/x-www-form-urlencoded

loginId=admin&loginPwd=123123

Content-Type: application/json

{ "loginId": "admin", "loginPwd": "123123" }

Content-Type: multipart/form-data; boundary=aaa

--aaa
Content-Disposition: form-data; name="loginId"

admin
--aaa
Content-Disposition: form-data; name="loginPwd"

123456
--aaa
Content-Disposition: form-data; name="avatar"; filename="small.jpg"
Content-Type: image/jpeg

文件的二进制
--aaa--

–aaa后写第一个数据第二个数据，–aaa–表示结束

响应码

响应码（状态码、消息码）是响应行中的一个数字，后面往往跟上一个对应的单词，用于表达服务器对这个响应的整体「态度」

常见的响应码有：

常见的状态码有：

200 OK：一切正常。
301 Moved Permanently：资源已被永久重定向。

你的请求我收到了，但是呢，你要的东西不在这个地址了，我已经永远的把它移动到了一个新的地址，麻烦你取请求新的地址，地址我放到了响应头的Location中了

试试请求：www.douyutv.com
302 Found：资源已被临时重定向。

你的请求我收到了，但是呢，你要的东西不在这个地址了，我临时的把它移动到了一个新的地址，麻烦你取请求新的地址，地址我放到了请求头的Location中了
304 Not Modified：文档内容未被修改。

你的请求我收到了，你要的东西跟之前是一样的，没有任何的变化，所以我就不给你结果了，你自己就用以前的吧。啥？你没有缓存以前的内容，关我啥事
400 Bad Request：语义有误，当前请求无法被服务器理解。

你给我发的是个啥啊，我听都听不懂
403 Forbidden：服务器拒绝执行。

你的请求我已收到，但是我就是不给你东西
404 Not Found：资源不存在。

你的请求我收到了，但我没有你要的东西
500 Internal Server Error：服务器内部错误。

你的请求我已收到，但这道题我不会，解不出来，先睡了

响应头 - `Content-Type`

Content-Type标注了附带的响应体是什么格式

常见的值有：

text/plain: 普通的纯文本
text/html：html文档
text/javascript 或 application/javascript：js代码
text/css：css代码
image/jpeg：jpg图片
attachment：附件
其他MIME类型

思考

根据这节课学到的知识，思考一个问题：如果不使用浏览器，是否能够完成页面浏览？

2浏览器的通信能力

2.1用户代理

浏览器可以代替用户完成http请求，代替用户解析响应结果，所以我们称之为：

用户代理 user agent

在这里插入图片描述

在网络层面，对于前端开发者，必须要知道浏览器拥有的两大核心能力：

自动发出请求的能力
自动解析响应的能力

2.1.1自动发出请求的能力

当一些事情发生的时候，浏览器会代替用户自动发出http请求，常见的包括：

用户在地址栏输入了一个url地址，并按下了回车

浏览器会自动解析URL，并发出一个GET请求，同时抛弃当前页面。
当用户点击了页面中的a元素

浏览器会拿到a元素的href地址，并发出一个GET请求，同时抛弃当前页面。

所有的请求要发生只能用绝对路径，需要协议端口等

扩展：当前选中元素，$0.value
当用户点击了提交按钮<button type="submit">...</button>

浏览器会获取按钮所在的<form>元素，拿到它的action属性地址，同时拿到它method属性值，然后把表单中的数据组织到请求体中，发出指定方法的请求，同时抛弃当前页面。

这种方式的提交现在越来越少见了
当解析HTML时遇到了<link> <img> <script> <video> <audio>等元素

浏览器会拿到对应的地址，发出GET请求
当用户点击了刷新

浏览器会拿到当前页面的地址，以及当前页面的请求方法，重新发一次请求，同时抛弃当前页面。

浏览器在发出请求时，会自动附带一些请求头

重点来了

从古至今，浏览器都有一个约定：

当发送GET请求时，浏览器不会附带请求体

这个约定深刻的影响着后续的前后端各种应用，现在，几乎所有人都在潜意识中认同了这一点，无论是前端开发人员还是后端开发人员。

由于前后端程序的默认行为，逐步造成了GET和POST的各种差异：

浏览器在发送 GET 请求时，不会附带请求体
GET 请求的传递信息量有限，适合传递少量数据；POST 请求的传递信息量是没有限制的，适合传输大量数据。
GET 请求只能传递 ASCII 数据，遇到非 ASCII 数据需要进行编码；POST 请求没有限制
大部分 GET 请求传递的数据都附带在 path 参数中，能够通过分享地址完整的重现页面，但同时也暴露了数据，若有敏感数据传递，不应该使用 GET 请求，至少不应该放到 path 中
POST 不会被保存到浏览器的历史记录中
刷新页面时，若当前的页面是通过 POST 请求得到的，则浏览器会提示用户是否重新提交。若是 GET 请求得到的页面则没有提示。

2.1.2自动解析响应的能力

浏览器不仅能发送请求，还能够针对服务器的各种响应结果做出不同的自动处理

常见的处理有：

识别响应码

浏览器能够自动识别响应码，当出现一些特殊的响应码时浏览器会自动完成处理，比如301、302
根据响应结果做不同的处理

浏览器能够自动分析响应头中的Content-Type，根据不同的值进行不同处理，比如：
- text/plain: 普通的纯文本，浏览器通常会将响应体原封不动的显示到页面上
- text/html：html文档，浏览器通常会将响应体作为页面进行渲染
- text/javascript或application/javascript：js代码，浏览器通常会使用JS执行引擎将它解析执行
- text/css：css代码，浏览器会将它视为样式
- image/jpeg：浏览器会将它视为jpg图片
- application/octet-stream：二进制数据，会触发浏览器下载功能
- attachment：附件，会触发下载功能
  
  该值和其他值不同，应放到Content-Disposition头中。

2.1.3基本流程

访问：https://oss.duyiedu.com/test/index.html

2.2AJAX

浏览器本身就具备网络通信的能力，但在早期，浏览器并没有把这个能力开放给JS。

最早是微软在IE浏览器中把这一能力向JS开放，让JS可以在代码中实现发送请求，并不会刷新页面，这项技术在2005年被正式命名为AJAX（Asynchronous Javascript And XML）

AJAX 就是指在web应用程序中异步向服务器发送请求。

它的实现方式有两种，XMLHttpRequest 简称XHR和Fetch

以下是两者的对比

功能点	XHR	Fetch
基本的请求能力	✅	✅
基本的获取响应能力	✅	✅
监控请求进度	✅	❌
监控响应进度	✅	✅
Service Worker中是否可用	❌	✅
控制cookie的携带	❌	✅
控制重定向	❌	✅
请求取消	✅	✅
自定义referrer	❌	✅
流	❌	✅
API风格	`Event`	`Promise`
活跃度	停止更新	不断更新

2.3实战

2.3.1请求并获取响应数据

请求地址：https://study.duyiedu.com/api/herolist

请求方法：GET

响应类型：application/json

响应结果：王者荣耀英雄数据

2.3.2上传文件并监控进度

2.3.2.1准备工作：启动本地文件上传服务器

如果没有安装node

下载安装node，https://nodejs.org/zh-cn/

打开命令行工具，设置淘宝源

npm config set registry https://registry.npm.taobao.org

安装依赖

在命令行进入upload-server目录
运行npm i

启动服务器

在命令行进入upload-server目录
运行npm start

2.3.2.2上传接口

请求路径：/upload/single

请求方法：POST

消息格式：multipart/form-data

字段名称：avatar

允许的后缀名：['.jpg', '.jpeg', '.bmp', '.webp', '.gif', '.png']

最大尺寸：1M

响应格式：JSON

响应结果示例：

// 成功
{
  "data": "文件的访问地址"
}
// 失败：后缀名不符号要求
{
  "errCode": 1,
  "errMsg": "后缀名不符合要求"
}
// 失败：文件过大
{
  "errCode": 2,
  "errMsg": "文件过大"
}

2.3.3登录和鉴权

由于HTTP协议的特点，每次「请求-响应」都是独立的，这就会导致身份信息丢失的问题

这个问题可以使用token令牌解决

在使用AJAX时可以按照这样一种通用模式处理：

在处理响应结果时，只要服务器给我的响应头中包含了token，就将其保存在localStorage中
在请求时，只要localStorage中有token，就将其代入到响应头发送到服务器。

2.3.3.1接口参考

获取账号信息：https://yapi.duyiedu.com/project/72/interface/api/114

获取聊天记录：https://yapi.duyiedu.com/project/72/interface/api/117

发送聊天消息：https://yapi.duyiedu.com/project/72/interface/api/120

2.3.4ChatGPT

2.3.4.1准备工作：启动本地服务器

已安装好node，以及设置好了npm的淘宝源

安装依赖

在命令行进入chat-server目录
运行npm i

启动服务器

在命令行进入chat-server目录
运行npm run dev

2.3.4.2聊天接口

请求路径：/chat

请求方法：POST

请求消息格式：application/json

请求体格式：

// 清除当前的聊天上下文
// 清除后，服务器不再记录之前的聊天内容，后续的聊天将使用新的上下文
{
  "clear": true
}

// 发送消息
{
  "content": "我要你扮演海绵宝宝的魔法海螺壳"
}

响应格式：纯文本

好的，我现在开始扮演海绵宝宝的魔法海螺壳。我可以说出各种魔法语言和帮助海绵宝宝和派大星解决问题。让我们开始冒险吧！噢呵呵呵呵！

注意：响应比较耗时，服务器会流式的将文本发送到客户端，为了提高用户体验，客户端最好流式的接收消息。

3跨域问题及解决方案

3.1同源策略及跨域问题

同源策略是一套浏览器安全机制，当一个源的文档和脚本，与另一个源的资源进行通信时，同源策略就会对这个通信做出不同程度的限制。

简单来说，同源策略对 同源资源 放行，对 异源资源 限制

因此限制造成的开发问题，称之为跨域（异源）问题

3.1.1同源和异源

源(origin) = 协议 + 域名 + 端口

例如:

https://study.duyiedu.com/api/movie的源为https://study.duyiedu.com

http://localhost:7001/index.html的源为http://localhost:7001

两个URL地址的源完全相同，则称之为同源，否则称之为异源（跨域）

3.1.2跨域出现的场景

跨域可能出现在三种场景：

网络通信

a元素的跳转；加载css、js、图片等；AJAX等等
JS API

window.open、window.parent、iframe.contentWindow等等
存储

WebStorage、IndexedDB等等

对于不同的跨域场景，以及每个场景中不同的跨域方式，同源策略都有不同的限制。

本文重点讨论网络通信中AJAX的跨域问题

3.1.3网络中的跨域

当浏览器运行页面后，会发出很多的网络请求，例如CSS、JS、图片、AJAX等等

请求页面的源称之为页面源，在该页面中发出的请求称之为目标源。

当页面源和目标源一致时，则为同源请求，否则为异源请求（跨域请求）

3.1.4浏览器如何限制异源请求？

浏览器出于多方面的考量，制定了非常繁杂的规则来限制各种跨域请求，但总体的原则非常简单：

对标签发出的跨域请求轻微限制
对AJAX发出的跨域请求严厉限制

3.2解决方案

3.2.1CORS

CORS（Cross-Origin Resource Sharing）是最正统的跨域解决方案，同时也是浏览器推荐的解决方案。

CORS是一套规则，用于帮助浏览器判断是否校验通过。

CORS的基本理念是：

只要服务器明确表示允许，则校验通过
服务器明确拒绝或没有表示，则校验不通过

所以，使用CORS解决跨域，必须要保证服务器是「自己人」

3.2.1.1请求分类

CORS将请求分为两类：简单请求和预检请求。

对不同种类的请求它的规则有所区别。

所以要理解CORS，首先要理解它是如何划分请求的。

3.2.1.1.1简单请求

完整判定逻辑：https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests

简单来说，只要全部满足下列三个条件，就是简单请求：

1、请求方法是GET、POST、HEAD之一
2、头部字段满足CORS安全规范，详见 W3C

浏览器默认自带的头部字段都是满足安全规范的，只要开发者不改动和新增头部，就不会打破此条规则
3、如果有Content-Type，必须是下列值中的一个
- text/plain
- multipart/form-data
- application/x-www-form-urlencoded

3.2.1.1.2预检请求(preflight)

只要不是简单请求，均为预检请求

3.2.1.1.3练习

// 下面的跨域请求哪些是简单请求，哪些是预检请求

// 1简单
fetch('https://douyin.com');
//默认get

// 2预检
fetch('https://douyin.com', {
  headers: {
    a: 1,
  },
});


// 3简单
fetch('https://douyin.com', {
  method: 'POST',
  body: JSON.stringify({ a: 1, b: 2 }),
});

// 4预检
fetch('https://douyin.com', {
  method: 'POST',
  headers: {
    'content-type': 'application/json',
  },
  body: JSON.stringify({ a: 1, b: 2 }),
});

在这里插入图片描述
第二个，preflight预检

下面的axios是预检请求，以为库发现你给他一个对象，请求头自动会Content-Type改为application/json

在这里插入图片描述

3.2.1.2对简单请求的验证

前提跨域，浏览器发送简单请求，自动附带请求头，（请求头改动不了），origin是自我介绍，通过的话必须做一件事，响应头里访问控制允许源加自我介绍，或者*，热情好客。不过最好是上面那种。

3.2.1.3对预检请求的验证

发送预检请求

看是否匹配，不然跨域

发送真实请求（和简单请求一致）

3.2.1.4细节1 - 关于cookie

默认情况下，ajax的跨域请求并不会附带cookie，这样一来，某些需要权限的操作就无法进行

不过可以通过简单的配置就可以实现附带cookie

// xhr
var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

// fetch api
fetch(url, {
  credentials: "include"
})

这样一来，该跨域的ajax请求就是一个附带身份凭证的请求

当一个请求需要附带cookie时，无论它是简单请求，还是预检请求，都会在请求头中添加cookie字段

而服务器响应时，需要明确告知客户端：服务器允许这样的凭据

告知的方式也非常的简单，只需要在响应头中添加：Access-Control-Allow-Credentials: true即可

对于一个附带身份凭证的请求，若服务器没有明确告知，浏览器仍然视为跨域被拒绝。

另外要特别注意的是：对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin 的值为*。这就是为什么不推荐使用*的原因

3.2.1.5细节2 - 关于跨域获取响应头

在跨域访问时，JS只能拿到一些最基本的响应头，如：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma，如果要访问其他头，则需要服务器设置本响应头。

Access-Control-Expose-Headers头让服务器把允许浏览器访问的头放入白名单，例如：

Access-Control-Expose-Headers: authorization, a, b

这样JS就能够访问指定的响应头了。

3.2.2JSONP

在很久很久以前…并没有CORS方案，用不了ajax

在那个年代，古人靠着非凡的智慧来解决这一问题

虽然可以解决问题，但JSONP有着明显的缺陷：

仅能使用GET请求
容易产生安全隐患

恶意攻击者可能利用callback=恶意函数的方式实现XSS攻击
容易被非法站点恶意调用

因此，除非是某些特殊的原因，否则永远不应该使用JSONP

3.2.3代理

CORS和JSONP均要求服务器是「自己人」

那如果不是呢？

那就找一个中间人（代理）

比如，前端小王想要请求获取王者荣耀英雄数据，但直接请求腾讯服务器会造成跨域

由于腾讯服务器不是「自己人」，小王决定用代理解决

3.2.3如何选择

最重要的，是要保持生产环境和开发环境一致

下面是一张决策图

具体的几种场景

Nginx反向代理服务器

在这里插入图片描述