zqy233的前端学习笔记

主题

回到顶部
索引

http

Content-Type（内容类型）

用于定义网络文件的类型和网页的编码，决定浏览器将以什么形式、什么编码读取这个文件

Content-Type 标头告诉客户端实际返回的内容的内容类型，示例：

Content-Type: text/html; charset=utf-8 Content-Type:application/json

常见的媒体格式类型：

  • text/html ： HTML格式
  • text/plain ：纯文本格式
  • text/xml ： XML格式
  • image/gif ：gif图片格式
  • image/jpeg ：jpg图片格式
  • image/png：png图片格式

application开头的格式类型：

  • application/xhtml+xml ：XHTML格式
  • application/xml： XML数据格式
  • application/atom+xml ：Atom XML聚合格式
  • application/json： JSON数据格式
  • application/pdf：pdf格式
  • application/msword ： Word文档格式
  • application/octet-stream ： 二进制流数据（如常见的文件下载）
  • application/x-www-form-urlencoded ：form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式）

另外一种常见的媒体格式是上传文件之时使用的：

  • multipart/form-data ： 需要在表单中进行文件上传时，就需要使用该格式

Request Payload与Form Data

前端开发中经常会用到AJAX发送请求，随着传参方式的不同，控制台时常会见到两种参数显示方式： Request Payload和 Form Data

两者的区别

Request Payload，更准确的说是http request的payload body。一般用在数据通过POST请求或者PUT请求。它应该对应请求体。（http请求一般由请求行，请求头，空行，请求体组成，payload body应该对应请求体）

区别就是，只是因为Content-Type设置的不同，并不是数据提交方式的不同，这两种提交都会将数据放在请求体中。但是chrome浏览器的开发者工具会根据ContentType区分显示方式，即：

Content-Type:application/json显示在Request Payload中

Content-Type:application/x-www-form-urlencoded和Content-Type:multipart/form-data显示在Form Data中

GET请求

使用get请求时，参数会以key=value的形式拼接在请求的url后面。例如：

http://m.baidu.com/address/getlist.html?limit=50&offset=0&t=1502345139870

但是受限于请求URL的长度限制，一般参数较少时会使用get请求。

POST请求

当参数数量较多，且对数据有一定安全性要求时，会考虑用post请求传递参数数据。POST请求的参数数据是在请求体中

方式一： Form Data形式

当POST请求的请求头里设置Content-Type: application/x-www-form-urlencoded或 multipart/form-data, 请求的参数会显示在Form Data中，以&符号拼接，参数格式为key=value&key=value&key=value...

方式二：Request Payload形式

当POST请求的请求头里设置Content-Type:application/json，请求的参数会显示在Request Payload中，参数格式为JSON格式：{"key":"value","key":"value"...}，这种方式可读性会更好。

cookie与token

以下每行专业名词很多情况下是同义词

浏览器端、前端、客户端

服务器端、后端

HTTP协议是无状态的协议，客户端多次请求服务器，服务器它无法感知是不是同一用户的请求，这就不能实现常见的用户自动登录功能(用户选择"记住我后"，下次不用输入账户密码即可登录)

所以产生了以下两种技术：

  • 通过cookie在浏览器端记录状态，通过session在服务端记录状态
  • 通过token方式维持状态

Cookie（复数形态Cookies），中文名称为“小型文本文件”或“小甜饼”。指某些网站为了辨别用户身份而储存在用户本地终端（Client Side）上的数据（通常经过加密）

cookie的特点

  1. 服务器通过设置Set-Cookie 响应头来设置 cookie
  2. 浏览器得到 cookie 后，每次同源的请求的请求头都会带上 cookie
  3. 服务器读取 cookie 就知道了登录用户的信息（如账户名等）
  4. cookie 实际上存储在本地计算机的硬盘里
  5. cookie 的最大储存量一般只有4K
  6. cookie存储数据的格式：字符串key=value
  7. cookie有效范围：当前域名下有效。所以session这种会话存储方式方式只适用于客户端代码和服务端代码运行在同一台服务器上（前后端项目协议、域名、端口号都一致，即在一个项目下）

cookie的缺点

  1. Cookie很容易被用户篡改（ Session 可以解决这个问题，防止用户篡改）
  2. Cookie 的默认有效期理论上在用户关闭页面后就失效，实际上在在20分钟左右，不同浏览器策略不同。但是后端可以强制设置有效期（如何设置见下文）。
  3. Cookie 也有一定的同源策略，不过跟 AJAX 的同源策略稍微有些不同。如：
    • 当请求 qq.com 下的资源时，浏览器会默认带上 qq.com 对应的 Cookie，不会带上 baidu.com 对应的 Cookie
    • 当请求 v.qq.com 下的资源时，浏览器不仅会带上 v.qq.com 的Cookie，还会带上 qq.com 的 Cookie
    • 另外 Cookie 还可以根据路径做限制，请自行了解，这个功能用得比较少
  4. Cookie不能跨域

session

Session是对于服务端来说的，客户端是没有Session一说的

Session中文意思为“回话”，代表服务器与浏览器的一次会话过程，这个过程是连续的，也可以时断时续的，它保存了本次客户端与服务端的通信信息

Session基于cookie，当浏览器第一次请求服务器，服务器会产生一个临时Cookie(Session)存放在服务器里，然后通过响应头的方式将SessionID返回给浏览器写入到Cookie中，浏览器下次请求就会将SessiondID以Cookie形式传递给服务器端，服务器端获取SessionID后再去寻找对应的Session。如果找到了则代表用户不是第一次访问，也就记住了用户

Session只适用于前端(客户端)代码和后端(服务器端)代码运行在同一台服务器上，协议，域名，端口一致的开发情况

若服务器做了负载均衡，用户的下一次请求可能会被定向到其它服务器节点，若那台节点上没有用户的Session信息，就会导致会话验证失败。所以Session默认机制下是不适合分布式部署的

服务器重启时，内存会被销毁，存储的用户信息也就消失了，为了解决重启服务器后session就消失的问题，可以在数据库中存储session，比如express服务器可以通过express-mysql-session这个包实现session持久化

当客户端存储的cookie失效后，服务端的session不会立即销毁，会有一个延时，服务端会定期清理无效session，不会造成无效数据占用存储空间的问题

token

Token一般称为令牌，一般是通过MD5、SHA算法将密钥、公钥、时间戳等元素加密产生的加密字符串

Token的出现是为了解决Session的弊端。如上方所讲，前端项目存在于一台服务器，后端项目运行另外一台服务器，协议，域名，端口号会不一致，这种情况下session不能用来实现记录状态

Token适用于前后端分离的项目

前端发起登录请求，后端校验登录的账户信息无误后，生成加密字符token，返回给客户端，客户端再次请求时在请求头添加token

具体来说就是为请求头的认证字段Authorization字段设置值为token，服务器端就可以通过token信息允许用户快捷登录

uuid

生成token的一种方式

jwt

生成token的一种方式， 全称是 JSON Web Token

token和session区别

token和session都是用户身份验证的一种识别手段，都有过期时间的限制，本质上功能是相同的，但它们之间的还是有一些区别的：

  • token是开发者采用算法自行生成的，session是http协议规定的
  • Token是放在客户端存储的，采用了时间换空间策略，它也是无状态的，所以在分布式环境中应用广泛，Session是存放在服务器端的，可以保存在：内存、数据库、NoSQL中。它采用空间换时间的策略来进行身份识别，若Session没有持久化落地存储，一旦服务器重启，Session数据会丢失
  • token可以跨域，session不可以跨域，它是与域名绑定的

js获取页面ip与端口

从window.location对象中可以获取相关值，返回值格式如下：

js
hash: "#/home"
host: "127.0.0.1:8080"
hostname: "127.0.0.1"
href: "http://127.0.0.1:8080/#/home"
origin: "http://127.0.0.1:8080"
pathname: "/"
port: "8080"
protocol: "http:"
search:""

hash: "#/home"
host: "127.0.0.1:8080"
hostname: "127.0.0.1"
href: "http://127.0.0.1:8080/#/home"
origin: "http://127.0.0.1:8080"
pathname: "/"
port: "8080"
protocol: "http:"
search:""

从而可以得出获取ip端口的方法

js
const urlObj = window.location
const localhostPath = urlObj.protocol + "//" + urlObj.host

const urlObj = window.location
const localhostPath = urlObj.protocol + "//" + urlObj.host

示例：打开第三方页面，用于文件下载预览等需求

js
window.open(`${localhostPath}/downloadfile=${fileId}`)

window.open(`${localhostPath}/downloadfile=${fileId}`)

示例：http://127.0.0.1:8080/index.html?userName=zhangsan&passWord=123456

js
// 获取ip地址和端口号
// 返回值：127.0.0.1:8080
window.location.host
// 获取ip地址
// 返回值：127.0.0.1
window.location.hostname
// 获取URL完整地址（地址栏的整个地址）
// 返回值：http://127.0.0.1:8080/index.html?userName=zhangsan&passWord=123456
window.location.href
// 获取URL的路径部分(文件地址) 
// 返回值：index.html
window.location.pathname
// 获取端口号
// 返回值：8080
window.location.port
// 获取URL的协议部分
// 返回值：http:
window.location.protocol
// 获取参数部分（?后面的参数）
// 返回值：?userName=zhangsan&passWord=123456
window.location.search


// 获取ip地址和端口号
// 返回值：127.0.0.1:8080
window.location.host
// 获取ip地址
// 返回值：127.0.0.1
window.location.hostname
// 获取URL完整地址（地址栏的整个地址）
// 返回值：http://127.0.0.1:8080/index.html?userName=zhangsan&passWord=123456
window.location.href
// 获取URL的路径部分(文件地址) 
// 返回值：index.html
window.location.pathname
// 获取端口号
// 返回值：8080
window.location.port
// 获取URL的协议部分
// 返回值：http:
window.location.protocol
// 获取参数部分（?后面的参数）
// 返回值：?userName=zhangsan&passWord=123456
window.location.search

WebRTC和WebSocket有什么关系和区别？

这两种技术本质上就是半毛钱关系都没有，除了它们都可以在 web 中用之外

websocket 本质上就是借助于 http 建立一个 tcp 的连接，然后在这个 tcp 连接中传 websocket 这种特定协议格式的二进制分帧数据。简单点说，websocket 就是封装了 tcp 来给 web 的 JavaScript 用

webrtc 则主要是给 rtc 封装了个 web 的 JavaScript 接口。底层 webrtc 的库需要完成全部 rtc 相关的逻辑，包括 p2p 连接，音视频的，采集，处理，编码，解码，传输，拥塞控制等等等一大堆东西。另外，传输层协议，webrtc 主要在用 udp，而不是websocket 的 tcp

withCredentials有什么作用

withCredentials是XMLHttpRequest的一个属性，表示跨域请求是否提供凭据信息(cookie、HTTP认证及客户端SSL证明等)

实际中用途就是跨域请求是要不要携带cookie

https://www.jianshu.com/p/624718082e69

Released under the MIT License.

Copyright © 2022.4-2024.5