1.TC的详细使用方法
2.Shiro的简介
3.从规范面解读:Promises/A+规范与浏览器Promise规范有何区别？
4.微前端学习笔记(3):前端沙箱之JavaScript的sandbox（沙盒/沙箱）
5.Android应用安全指南-反逆向

TC的详细使用方法

       给你个TC中文MAN，参考参考，也可以去我的BLOG看看，最近我也在学，

       名字

        tc - 显示／维护流量控制设置

       摘要

       tc qdisc [ add | change | replace | link ] dev DEV [ parent qdisc-id | root ] [ handle qdisc-id ] qdisc [ qdisc specific parameters ]

       tc class [ add | change | replace ] dev DEV parent qdisc-id [ classid class-id ] qdisc [ qdisc specific parameters ]

       tc filter [ add | change | replace ] dev DEV [ parent qdisc-id | root ] protocol protocol prio priority filtertype [ filtertype specific parameters ] flowid flow-id

       tc [-s | -d ] qdisc show [ dev DEV ]

       tc [-s | -d ] class show dev DEV tc filter show dev DEV

       简介

       Tc用于Linux内核的流量控制。流量控制包括以下几种方式：

       SHAPING(限制)

       当流量被限制，javaweb网上订餐系统项目源码它的传输速率就被控制在某个值以下。限制值可以大大小于有效带宽，这样可以平滑突发数据流量，使网络更为稳定。shaping（限制）只适用于向外的流量。

       SCHEDULING(调度)

       通过调度数据包的传输，可以在带宽范围内，按照优先级分配带宽。SCHEDULING(调度)也只适于向外的流量。

       POLICING(策略)

       SHAPING用于处理向外的流量，而POLICIING(策略)用于处理接收到的数据。

       DROPPING(丢弃)

       如果流量超过某个设定的带宽，就丢弃数据包，不管是向内还是向外。

       流量的处理由三种对象控制，它们是：qdisc(排队规则)、class(类别)和filter(过滤器)。

       QDISC(排队嬖?

       QDisc(排队规则)是queueing discipline的简写，它是理解流量控制(traffic control)的基础。无论何时，内核如果需要通过某个网络接口发送数据包，它都需要按照为这个接口配置的qdisc(排队规则)把数据包加入队列。然后，内核会尽可能多地从qdisc里面取出数据包，把它们交给网络适配器驱动模块。

       最简单的QDisc是pfifo它不对进入的数据包做任何的处理，数据包采用先入先出的方式通过队列。不过，它会保存网络接口一时无法处理的数据包。

       CLASS(类)

       某些QDisc(排队规则)可以包含一些类别，不同的类别中可以包含更深入的QDisc(排队规则)，通过这些细分的QDisc还可以为进入的队列的数据包排队。通过设置各种类别数据包的离队次序，QDisc可以为设置网络数据流量的优先级。

       FILTER(过滤器)

       filter(过滤器)用于为数据包分类，决定它们按照何种QDisc进入队列。无论何时数据包进入一个划分子类的类别中，都需要进行分类。分类的方法可以有多种，使用fileter(过滤器)就是其中之一。使用filter(过滤器)分类时，内核会调用附属于这个类(class)的所有过滤器，直到返回一个判决。如果没有判决返回，就作进一步的处理，而处理方式和QDISC有关。

       需要注意的是，filter(过滤器)是在QDisc内部，它们不能作为主体。

       CLASSLESS QDisc(不可分类QDisc)

       无类别QDISC包括：

       [p|b]fifo

       使用最简单的qdisc，纯粹的先进先出。只有一个参数：limit，用来设置队列的长度,pfifo是以数据包的个数为单位；bfifo是以字节数为单位。

       pfifo_fast

       在编译内核时，如果打开了高级路由器(Advanced Router)编译选项，pfifo_fast就是系统的标准QDISC。它的直播网站项目源码队列包括三个波段(band)。在每个波段里面，使用先进先出规则。而三个波段(band)的优先级也不相同，band 0的优先级最高，band 2的最低。如果band里面有数据包，系统就不会处理band 1里面的数据包，band 1和band 2之间也是一样。数据包是按照服务类型(Type of Service,TOS)被分配多三个波段(band)里面的。

       red

       red是Random Early Detection(随机早期探测)的简写。如果使用这种QDISC，当带宽的占用接近于规定的带宽时，系统会随机地丢弃一些数据包。它非常适合高带宽应用。

       sfq

       sfq是Stochastic Fairness Queueing的简写。它按照会话(session--对应于每个TCP连接或者UDP流)为流量进行排序，然后循环发送每个会话的数据包。

       tbf

       tbf是Token Bucket Filter的简写，适合于把流速降低到某个值。

       不可分类QDisc的配置

       如果没有可分类QDisc，不可分类QDisc只能附属于设备的根。它们的用法如下：

       tc qdisc add dev DEV root QDISC QDISC-PARAMETERS

       要删除一个不可分类QDisc，需要使用如下命令：

       tc qdisc del dev DEV root

       一个网络接口上如果没有设置QDisc，pfifo_fast就作为缺省的QDisc。

       CLASSFUL QDISC(分类QDisc)

       可分类的QDisc包括：

       CBQ

       CBQ是Class Based Queueing(基于类别排队)的缩写。它实现了一个丰富的连接共享类别结构，既有限制(shaping)带宽的能力，也具有带宽优先级管理的能力。带宽限制是通过计算连接的空闲时间完成的。空闲时间的计算标准是数据包离队事件的频率和下层连接(数据链路层)的带宽。

       HTB

       HTB是Hierarchy Token Bucket的缩写。通过在实践基础上的改进，它实现了一个丰富的连接共享类别体系。使用HTB可以很容易地保证每个类别的带宽，虽然它也允许特定的类可以突破带宽上限，占用别的类的带宽。HTB可以通过TBF(Token Bucket Filter)实现带宽限制，也能够划分类别的优先级。

       PRIO

       PRIO QDisc不能限制带宽，因为属于不同类别的数据包是顺序离队的。使用PRIO QDisc可以很容易对流量进行优先级管理，只有属于高优先级类别的数据包全部发送完毕，才会发送属于低优先级类别的数据包。为了方便管理，需要使用iptables或者ipchains处理数据包的服务类型(Type Of Service,ToS)。

       操作原理

       类(Class)组成一个树，每个类都只有一个父类，而一个类可以有多个子类。某些QDisc(例如：CBQ和HTB)允许在运行时动态添加类，而其它的QDisc(例如：PRIO)不允许动态建立类。

       允许动态添加类的QDisc可以有零个或者多个子类，由它们为数据包排队。

       此外，每个类都有一个叶子QDisc，默认情况下，这个叶子QDisc使用pfifo的方式排队，我们也可以使用其它类型的QDisc代替这个默认的QDisc。而且，这个叶子叶子QDisc有可以分类，不过每个子类只能有一个叶子QDisc。

       当一个数据包进入一个分类QDisc，它会被归入某个子类。卧龙出山指标源码我们可以使用以下三种方式为数据包归类，不过不是所有的QDisc都能够使用这三种方式。

       tc过滤器(tc filter)

       如果过滤器附属于一个类，相关的指令就会对它们进行查询。过滤器能够匹配数据包头所有的域，也可以匹配由ipchains或者iptables做的标记。

       服务类型(Type of Service)

       某些QDisc有基于服务类型（Type of Service,ToS）的内置的规则为数据包分类。

       skb->priority

       用户空间的应用程序可以使用SO_PRIORITY选项在skb->priority域设置一个类的ID。

       树的每个节点都可以有自己的过滤器，但是高层的过滤器也可以直接用于其子类。

       如果数据包没有被成功归类，就会被排到这个类的叶子QDisc的队中。相关细节在各个QDisc的手册页中。

       命名规则

       所有的QDisc、类和过滤器都有ID。ID可以手工设置，也可以有内核自动分配。

       ID由一个主序列号和一个从序列号组成，两个数字用一个冒号分开。

       QDISC

       一个QDisc会被分配一个主序列号，叫做句柄(handle)，然后把从序列号作为类的命名空间。句柄采用象:一样的表达方式。习惯上，需要为有子类的QDisc显式地分配一个句柄。

       类(CLASS)

       在同一个QDisc里面的类分享这个QDisc的主序列号，但是每个类都有自己的从序列号，叫做类识别符(classid)。类识别符只与父QDisc有关，和父类无关。类的命名习惯和QDisc的相同。

       过滤器(FILTER)

       过滤器的ID有三部分，只有在对过滤器进行散列组织才会用到。详情请参考tc-filters手册页。

       单位

       tc命令的所有参数都可以使用浮点数，可能会涉及到以下计数单位。

       带宽或者流速单位：

       kbps

       千字节／秒

       mbps

       兆字节／秒

       kbit

       KBits／秒

       mbit

       MBits／秒

       bps或者一个无单位数字

       字节数／秒

       数据的数量单位：

       kb或者k

       千字节

       mb或者m

       兆字节

       mbit

       兆bit

       kbit

       千bit

       b或者一个无单位数字

       字节数

       时间的计量单位：

       s、sec或者secs

       秒

       ms、msec或者msecs

       分钟

       us、usec、usecs或者一个无单位数字

       微秒

       TC命令

       tc可以使用以下命令对QDisc、类和过滤器进行操作：

       add

       在一个节点里加入一个QDisc、类或者过滤器。添加时，需要传递一个祖先作为参数，传递参数时既可以使用ID也可以直接传递设备的根。如果要建立一个QDisc或者过滤器，可以使用句柄(handle)来命名；如果要建立一个类，可以使用类识别符(classid)来命名。

       remove

       删除有某个句柄(handle)指定的QDisc，根QDisc(root)也可以删除。被删除QDisc上的所有子类以及附属于各个类的过滤器都会被自动删除。

       change

       以替代的方式修改某些条目。除了句柄(handle)和祖先不能修改以外，change命令的语法和add命令相同。换句话说，change命令不能一定节点的位置。

       replace

       对一个现有节点进行近于原子操作的删除／添加。如果节点不存在，这个命令就会建立节点。

       link

       只适用于DQisc，替代一个现有的mysqlsql语句分析源码节点。

       历史

       tc由Alexey N. Kuznetsov编写，从Linux 2.2版开始并入Linux内核。

       SEE ALSO

       tc-cbq(8)、tc-htb(8)、tc-sfq(8)、tc-red(8)、tc-tbf(8)、tc-pfifo(8)、tc-bfifo(8)、tc-pfifo_fast(8)、tc-filters(8)

       Linux从kernel 2.1.开始支持QOS，不过，需要重新编译内核。运行make config时将EXPERIMENTAL _OPTIONS设置成y，并且将Class Based Queueing (CBQ), Token Bucket Flow, Traffic Shapers 设置为 y ，运行 make dep; make clean; make bzilo，生成新的内核。

        在Linux操作系统中流量控制器(TC)主要是在输出端口处建立一个队列进行流量控制，控制的方式是基于路由，亦即基于目的IP地址或目的子网的网络号的流量控制。流量控制器TC，其基本的功能模块为队列、分类和过滤器。Linux内核中支持的队列有，Class Based Queue ，Token Bucket Flow ，CSZ ，First In First Out ，Priority ，TEQL ，SFQ ，ATM ，RED。这里我们讨论的队列与分类都是基于CBQ(Class Based Queue)的，而过滤器是基于路由(Route)的。

        配置和使用流量控制器TC，主要分以下几个方面：分别为建立队列、建立分类、建立过滤器和建立路由，另外还需要对现有的队列、分类、过滤器和路由进行监视。

        其基本使用步骤为：

        1) 针对网络物理设备(如以太网卡eth0)绑定一个CBQ队列；

        2) 在该队列上建立分类；

        3) 为每一分类建立一个基于路由的过滤器；

        4) 最后与过滤器相配合，建立特定的路由表。

        先假设一个简单的环境

        流量控制器上的以太网卡(eth0) 的IP地址为..1.，在其上建立一个CBQ队列。假设包的平均大小为字节，包间隔发送单元的大小为8字节，可接收冲突的发送最长包数目为字节。

        假如有三种类型的流量需要控制:

        1) 是发往主机1的，其IP地址为..1.。其流量带宽控制在8Mbit，优先级为2；

        2) 是发往主机2的，其IP地址为..1.。其流量带宽控制在1Mbit，优先级为1；

        3) 是发往子网1的，其子网号为..1.0，子网掩码为...0。流量带宽控制在1Mbit，优先级为6。

        1. 建立队列

        一般情况下，针对一个网卡只需建立一个队列。jdk源码学习资料

        将一个cbq队列绑定到网络物理设备eth0上，其编号为1:0；网络物理设备eth0的实际带宽为 Mbit，包的平均大小为字节；包间隔发送单元的大小为8字节，最小传输包大小为字节。

        ?tc qdisc add dev eth0 root handle 1: cbq bandwidth Mbit avpkt cell 8 mpu

        2. 建立分类

        分类建立在队列之上。一般情况下，针对一个队列需建立一个根分类，然后再在其上建立子分类。对于分类，按其分类的编号顺序起作用，编号小的优先；一旦符合某个分类匹配规则，通过该分类发送数据包，则其后的分类不再起作用。

        1） 创建根分类1:1；分配带宽为Mbit，优先级别为8。

        ?tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth Mbit rate Mbit maxburst allot prio 8 avpkt cell 8 weight 1Mbit

        该队列的最大可用带宽为Mbit，实际分配的带宽为Mbit，可接收冲突的发送最长包数目为字节；最大传输单元加MAC头的大小为字节，优先级别为8，包的平均大小为字节，包间隔发送单元的大小为8字节，相应于实际带宽的加权速率为1Mbit。

        2）创建分类1:2，其父分类为1:1，分配带宽为8Mbit，优先级别为2。

        ?tc class add dev eth0 parent 1:1 classid 1:2 cbq bandwidth Mbit rate 8Mbit maxburst allot prio 2 avpkt cell 8 weight Kbit split 1:0 bounded

        该队列的最大可用带宽为Mbit，实际分配的带宽为 8Mbit，可接收冲突的发送最长包数目为字节；最大传输单元加MAC头的大小为字节，优先级别为1，包的平均大小为字节，包间隔发送单元的大小为8字节，相应于实际带宽的加权速率为Kbit，分类的分离点为1:0，且不可借用未使用带宽。

        3）创建分类1:3，其父分类为1:1，分配带宽为1Mbit，优先级别为1。

        ?tc class add dev eth0 parent 1:1 classid 1:3 cbq bandwidth Mbit rate 1Mbit maxburst allot prio 1 avpkt cell 8 weight Kbit split 1:0

        该队列的最大可用带宽为Mbit，实际分配的带宽为 1Mbit，可接收冲突的发送最长包数目为字节；最大传输单元加MAC头的大小为字节，优先级别为2，包的平均大小为字节，包间隔发送单元的大小为8字节，相应于实际带宽的加权速率为Kbit，分类的分离点为1:0。

        4）创建分类1:4，其父分类为1:1，分配带宽为1Mbit，优先级别为6。

        ?tc class add dev eth0 parent 1:1 classid 1:4 cbq bandwidth Mbit rate 1Mbit maxburst allot prio 6 avpkt cell 8 weight Kbit split 1:0

        该队列的最大可用带宽为Mbit，实际分配的带宽为 Kbit，可接收冲突的发送最长包数目为字节；最大传输单元加MAC头的大小为字节，优先级别为1，包的平均大小为字节，包间隔发送单元的大小为8字节，相应于实际带宽的加权速率为Kbit，分类的分离点为1:0。

        3. 建立过滤器

        过滤器主要服务于分类。一般只需针对根分类提供一个过滤器，然后为每个子分类提供路由映射。

        1） 应用路由分类器到cbq队列的根，父分类编号为1:0；过滤协议为ip，优先级别为，过滤器为基于路由表。

        ?tc filter add dev eth0 parent 1:0 protocol ip prio route

        2） 建立路由映射分类1:2, 1:3, 1:4

        ?tc filter add dev eth0 parent 1:0 protocol ip prio route to 2 flowid 1:2

        ?tc filter add dev eth0 parent 1:0 protocol ip prio route to 3 flowid 1:3

        ?tc filter add dev eth0 parent 1:0 protocol ip prio route to 4 flowid 1:4

        4.建立路由

        该路由是与前面所建立的路由映射一一对应。

        1） 发往主机..1.的数据包通过分类2转发(分类2的速率8Mbit)

        ?ip route add ..1. dev eth0 via ..1. realm 2

        2） 发往主机..1.的数据包通过分类3转发(分类3的速率1Mbit)

        ?ip route add ..1. dev eth0 via ..1. realm 3

        3）发往子网..1.0/的数据包通过分类4转发(分类4的速率1Mbit)

        ?ip route add ..1.0/ dev eth0 via ..1. realm 4

        注：一般对于流量控制器所直接连接的网段建议使用IP主机地址流量控制限制，不要使用子网流量控制限制。如一定需要对直连子网使用子网流量控制限制，则在建立该子网的路由映射前，需将原先由系统建立的路由删除，才可完成相应步骤。

        5. 监视

        主要包括对现有队列、分类、过滤器和路由的状况进行监视。

        1）显示队列的状况

        简单显示指定设备(这里为eth0)的队列状况

tc qdisc ls dev eth0

       qdisc cbq 1: rate Mbit (bounded,isolated) prio no-transmit

       详细显示指定设备(这里为eth0)的队列状况

tc -s qdisc ls dev eth0

       qdisc cbq 1: rate Mbit (bounded,isolated) prio no-transmit

       Sent bytes pkts (dropped 0, overlimits 0)

       borrowed 0 overactions 0 avgidle undertime 0

       这里主要显示了通过该队列发送了个数据包，数据流量为个字节，丢弃的包数目为0，超过速率限制的包数目为0。

        2）显示分类的状况

        简单显示指定设备(这里为eth0)的分类状况

tc class ls dev eth0

       class cbq 1: root rate Mbit (bounded,isolated) prio no-transmit

       class cbq 1:1 parent 1: rate Mbit prio no-transmit #no-transmit表示优先级为8

       class cbq 1:2 parent 1:1 rate 8Mbit prio 2

       class cbq 1:3 parent 1:1 rate 1Mbit prio 1

       class cbq 1:4 parent 1:1 rate 1Mbit prio 6

       详细显示指定设备(这里为eth0)的分类状况

tc -s class ls dev eth0

       class cbq 1: root rate Mbit (bounded,isolated) prio no-transmit

       Sent bytes pkts (dropped 0, overlimits 0)

       borrowed 0 overactions 0 avgidle undertime 0

       class cbq 1:1 parent 1: rate Mbit prio no-transmit

       Sent bytes pkts (dropped 0, overlimits 0)

       borrowed overactions 0 avgidle undertime 0

       class cbq 1:2 parent 1:1 rate 8Mbit prio 2

       Sent bytes pkts (dropped 0, overlimits 0)

       borrowed 0 overactions 0 avgidle undertime 0

       class cbq 1:3 parent 1:1 rate 1Mbit prio 1

       Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

       borrowed 0 overactions 0 avgidle undertime 0

       class cbq 1:4 parent 1:1 rate 1Mbit prio 6

       Sent bytes pkts (dropped 0, overlimits 0)

       borrowed overactions 0 avgidle undertime 0

       这里主要显示了通过不同分类发送的数据包，数据流量，丢弃的包数目，超过速率限制的包数目等等。其中根分类(class cbq 1:0)的状况应与队列的状况类似。

        例如，分类class cbq 1:4发送了个数据包，数据流量为个字节，丢弃的包数目为0，超过速率限制的包数目为0。

        显示过滤器的状况

tc -s filter ls dev eth0

       filter parent 1: protocol ip pref route

       filter parent 1: protocol ip pref route fh 0xffff flowid 1:2 to 2

       filter parent 1: protocol ip pref route fh 0xffff flowid 1:3 to 3

       filter parent 1: protocol ip pref route fh 0xffff flowid 1:4 to 4

       这里flowid 1:2代表分类class cbq 1:2，to 2代表通过路由2发送。

        显示现有路由的状况

ip route

       ..1. dev eth0 scope link

       ..1. via ..1. dev eth0 realm 2

       ... dev ppp0 proto kernel scope link src ...5

       ..1. via ..1. dev eth0 realm 3

       ..1.0/ via ..1. dev eth0 realm 4

       ..1.0/ dev eth0 proto kernel scope link src ..1.

       ..1.0/ via ..1. dev eth0 scope link

       .0.0.0/8 dev lo scope link

       default via ... dev ppp0

       default via ..1. dev eth0

       如上所示，结尾包含有realm的显示行是起作用的路由过滤器。

        6. 维护

        主要包括对队列、分类、过滤器和路由的增添、修改和删除。

        增添动作一般依照"队列->分类->过滤器->路由"的顺序进行；修改动作则没有什么要求；删除则依照"路由->过滤器->分类->队列"的顺序进行。

        1）队列的维护

        一般对于一台流量控制器来说，出厂时针对每个以太网卡均已配置好一个队列了，通常情况下对队列无需进行增添、修改和删除动作了。

        2）分类的维护

        增添

        增添动作通过tc class add命令实现，如前面所示。

        修改

        修改动作通过tc class change命令实现，如下所示：

tc class change dev eth0 parent 1:1 classid 1:2 cbq bandwidth Mbit

       rate 7Mbit maxburst allot prio 2 avpkt cell

       8 weight Kbit split 1:0 bounded

       对于bounded命令应慎用，一旦添加后就进行修改，只可通过删除后再添加来实现。

        删除

        删除动作只在该分类没有工作前才可进行，一旦通过该分类发送过数据，则无法删除它了。因此，需要通过shell文件方式来修改，通过重新启动来完成删除动作。

        3）过滤器的维护

        增添

        增添动作通过tc filter add命令实现，如前面所示。

        修改

        修改动作通过tc filter change命令实现，如下所示：

tc filter change dev eth0 parent 1:0 protocol ip prio route to

        flowid 1:8

       删除

        删除动作通过tc filter del命令实现，如下所示：

tc filter del dev eth0 parent 1:0 protocol ip prio route to

       4）与过滤器一一映射路由的维护

        增添

        增添动作通过ip route add命令实现，如前面所示。

        修改

        修改动作通过ip route change命令实现，如下所示：

ip route change ..1. dev eth0 via ..1. realm 8

       删除

        删除动作通过ip route del命令实现，如下所示：

ip route del ..1. dev eth0 via ..1. realm 8

ip route del ..1.0/ dev eth0 via ..1. realm 4

Shiro的简介

       在之前的学习中，我未记录Shiro的相关笔记，现在决定补全这部分内容。虽然之前写过一篇基础介绍，但感觉总结不够全面。

       Shiro作为当前热门的安全框架，其实质是权限管理工具，主要负责用户对系统资源的访问控制。例如，访问路径"/Admin/UserList"如果没有权限管理，任何人都能访问，这就构成未授权访问。

       Shiro的核心架构可以参考官网提供的架构图，主要包括Subject（代表用户或应用）、SecurityManager（负责认证和授权的中介）、Authenticator（身份认证）、Authorizer（授权决策）、Realm（数据源，获取用户信息）、SessionManager（会话管理）和SessionDAO（会话存储）等组件。

       认证过程中，用户通过身份信息（Principal，如用户名）和凭据信息（Credential，如密码）进行登录。Shiro将这些信息封装成Token，通过安全管理器，调用Authenticator进行身份验证。Realm从数据库获取用户信息进行比对，验证通过后进入授权环节。

       配置方面，shiro.ini文件定义了初始的用户名和密码，与其他框架集成时会用到ShiroConfig。测试代码演示了认证流程的各个环节。

       Shiro的认证源码分析深入到了各个方法，包括认证、授权、以及如何从Token中提取用户名和密码进行比对。在Springboot整合Shiro时，涉及创建ShiroFilter、安全管理器、自定义Realm以及配置权限访问规则。

       绕过机制方面，Springboot版本和Shiro版本的搭配会影响绕过漏洞的复现。在Shiro配置中，绕过行为通过路径匹配进行控制。在绕过漏洞的分析中，可以看到Spring和Shiro在处理请求路径时的差异，导致权限控制的失效。

       关于更多Shiro绕过漏洞的详细内容，可以参考nice0e3师傅的文章，链接在这里：[tttang.com/archive/...]

从规范面解读:Promises/A+规范与浏览器Promise规范有何区别？

       前言

       Promise是一种优秀的异步解决方案，其原生实现更是面试中的爆点，提到Promise实现，我们首先会想起Promises/A+规范，大多数教程中都是按照Promises/A+规范来实现Promise。

       小包也是Promises/A+圣经的执行者之一，但小包心中一直有个好奇，遵循Promises/A+规范实现的Promise与ES6-Promise能有什么区别呐？

       文章中的测试代码选取小包基于Promises/A+规范实现的原生Promise

       学习本文，你能收获:

       进一步完善原生Promise的实现

       更进一步理解Promise与microTask之间的关系

promise的成功值value

       Promises/A+规范只提供了value的定义，并没有详细说明如何处理不同类型的value值:

       “value”isanylegalJavaScriptvalue(including?undefined,athenable,orapromise).value可以是任意合法的JavaScript值，包括undefined、具备then接口的对象或者promise

       但ECMAScript规范对不同类型的value做了细致的处理。

       红框部分我们可以看出，ES6规范会根据resolution(相当于Promises/A+规范中的value)类型选取不同的执行方案。

       判断resolution是否为Object，如果不是，直接执行FulfillPromise

       如果是Object，试探是否存在then接口

       判断then是否可执行(abruptcompletion可以理解为非正常值)

       如果then可执行，将then方法放入事件队列中。

       PromiseResolveThenableJob:该job使用传入的thenable的then方法来解决promise。

       一句话总结上面的过程:如果value值为可thenable对象或者promise，ES6会采用该thenable的状态。

       小包举个栗子：

const?p?=?new?Promise((resolve)?=>?{ ?resolve(1);});const?p1?=?new?Promise((resolve)?=>?{ ?resolve(p);});p1.then((d)?=>?console.log(d));

       p1接收的成功值value为Promisep，p状态为fulfilled，这种情况下ES6中会采取p的状态及value，因此最终打印1。

       我们将p更换为具备thenable对象，结果也是类似的。

//?类?promise?对象const?p1?=?{ ?a:?1,?then(onFulfilled,?onReject)?{ onFulfilled(this.a);?},};const?p2?=?new?Promise((resolve)?=>?{ ?resolve(p1);});//?1p2.then((d)?=>?console.log(d));

       Promises/A+没有对此进行规范，因此当传入的value为thenable对象时，会原封不动的输出。

       那我们应该如何完善这部分代码呐？我们需要对value值进行解析，如果value可thenable，则采纳他的状态和值，递归进行上述步骤，直至value不可thenable。(这里与resolvePromise部分递归解析onFulfilled函数的返回值是类似的)

const?resolve?=?(value)?=>?{ ?if?(typeof?value?===?"object"?&&?value?!=?null)?{ try?{ ?const?then?=?value.then;?if?(typeof?then?===?"function")?{ return?then.call(value,?resolve,?reject);?}}?catch?(e)?{ ?return?reject(e);}?}?if?(this.status?===?PENDING)?{ this.value?=?value;this.status?=?FULFILLED;this.onFulfilledCallbacks.forEach((cb)?=>?cb(this.value));?}};Promise与microTask

       Promises/A+规范中其实并没有将Promise对象与microTask挂钩，规范是这么说的:

       Here“platformcode”meansengine,environment,andpromiseimplementationcode.Inpractice,thisrequirementensuresthat?onFulfilled?and?onRejected?executeasynchronously,aftertheeventloopturninwhich?then?iscalled,andwithafreshstack.Thiscanbeimplementedwitheithera“macro-task”mechanismsuchas?setTimeout?or?setImmediate,orwitha“micro-task”mechanismsuchas?MutationObserver?or?process.nextTick.Sincethepromiseimplementationisconsideredplatformcode,itmayitselfcontainatask-schedulingqueueor“trampoline”inwhichthehandlersarecalled.

       Promises/A+规范中表示then方法可以通过setTimeout或setImediate等宏任务机制实现，也可以通过MutationObserver或process.nextTick等微任务机制实现。

       但经过大量面试题洗礼的我们知道浏览器中的Promise.then典型的微任务。既然都学到这里了，小包索性就打破砂锅问到底，找到Promise与microTask挂钩的根源。

谁规定了Promise是microTask

       标准读起来属实有些无聊，但好在小包找到了最终的答案。

       首先小包先入为主的以为，Promise的详细规定应该都位于ECMAScript制定的规范中，但当小包进入标准后，全局搜索micro，竟然只搜索到三个Microsoft。讲实话，小包是震惊的，ECMAScript并没有规定Promise是microTask。

       ECMAScript规范中，最接近的是下面两段表达：

       The?host-defined?abstractoperationHostEnqueuePromiseJobtakesarguments?job?(a?Job?AbstractClosure)and?realm?(a?RealmRecord?or?null)andreturns?unused.Itschedules?job?tobeperformedatsomefuturetime.The?AbstractClosures?usedwiththisalgorithmareintendedtoberelatedtothehandlingofPromises,orotherwise,tobescheduledwithequalprioritytoPromisehandlingoperations.

       JobsarescheduledforexecutionbyECMAScripthostenvironments.ThisspecificationdescribesthehosthookHostEnqueuePromiseJobtoscheduleonekindofjob;hostsmaydefineadditionalabstractoperationswhichschedulejobs.SuchoperationsacceptaJobAbstractClosureastheparameterandscheduleittobeperformedatsomefuturetime.Theirimplementationsmustconformtothefollowingrequirements:

       上面两句话意思大约是:ECMAScript中将Promise看作一个job(作业)，HostEnqueuePromiseJob是用来调度Promise作业的方法，这个方法会在未来某个时间段执行，具体执行与Promise的处理函数或者与Promise处理操作相同的优先级有关。

       那何处将Promise规定为microTask呐？---HTML标准

       HTML标准中指出:

       JavaScriptcontainsan?implementation-defined?HostEnqueuePromiseJob(job,?realm)abstractoperationtoschedulePromise-relatedoperations.HTMLschedulestheseoperationsinthemicrotaskqueue.

       上述标准的最后一句话指出，HTML将在microqueue中安排这些操作。破案了，原来是HTML标准中将Promise规定为microTask。(为什么会是HTML进行规定，小包还没有探究出来)

       更深入的区别，请参考月夕大佬:V8Promise源码全面解读

后语

       我是?战场小包?，一个快速成长中的小前端，希望可以和大家一起进步。

       如果喜欢小包，可以在?掘金?关注我，同样也可以关注我的小小公众号——小包学前端。

       一路加油，冲向未来!!!

疫情早日结束人间恢复太平

       原文：/post/

微前端学习笔记(3):前端沙箱之JavaScript的sandbox（沙盒/沙箱）

       沙盒（Sandbox）机制旨在确保代码的安全性，限制其权限以防止恶意或不受信任的脚本访问敏感资源或干扰其他程序执行。通过在沙盒环境中运行代码，可以将其行为限制在安全范围之内。

       沙盒是一种隔离机制，允许程序在独立环境中运行，避免对外界程序造成影响，保障系统安全。在开发中，沙盒环境通常用于服务器中通过Docker创建容器，或在 Codesandbox中运行代码示例，以及在程序中执行动态脚本。

       微前端框架主要负责两个工作：一是实现JS沙盒，二是将沙盒内的执行结果输出为WebComponents，插入到页面中。

       沙盒能够确保每个前端应用拥有独立的上下文环境、页面路由和状态管理，避免相互干扰。

       实现JavaScript沙盒的方法有两类：通过iframe或ShadowRealm在原生环境上实现，以及利用JS特性（主要基于Proxy）实现。

       利用iframe实现沙盒是通过其天然的隔离机制和postMessage通讯机制。在iframe中运行的脚本只访问当前iframe的全局对象，不会影响父页面功能，提供简单、安全的实现方式。腾讯的无界沙箱采用此方案。

       使用iframe沙盒有一些限制，需要配置来解除限制。实际工程中，可以参考《让iframe焕发新生》一文，使用封装的框架wujie实现。

       无界沙箱模式在一张页面上激活多个子应用，利用iframe独立执行，并通过location和history管理路由，支持浏览器前进、后退操作。

       核心点包括：iframe数据劫持和注入、iframe与shadowRoot副作用处理。实现细节在无界源码中。

       ShadowRealm是一个ECMAScript标准提案，允许创建多个高度隔离的JS运行环境，具有独立的全局对象和内建对象。但目前仍处于提案阶段。

       WebWorker提供独立线程作为沙箱环境，适合作为底层实现，但不常提及。腾讯无界方案展示了其优势。

       IIFE（立即执行匿名函数）实现简易沙箱，可限制变量访问，但只能实现基本隔离。

       with + new Function提供访问全局变量和局部变量的能力，但存在全局作用域污染风险。

       利用with和Function结合Proxy实现ES6 Proxy，通过拦截器get和set对window进行代理，实现全局环境的隔离。

       沙箱逃逸是极端情况下的安全挑战，通过设置Symbol.unScopables为true来绕过with作用域限制。

       沙盒实现包括简单代码实现和多实例模式，分别通过with块和Proxy对象隔离执行环境。单实例模式只支持记录变化，多实例模式则在微应用间创建独立的沙箱环境。

       基于属性diff的沙箱机制在不支持ES6的环境中使用普通对象快照实现存储与恢复，用于更新子应用环境。qiankun中提供了此降级方案。

       总结：沙盒机制是实现代码安全隔离的有效手段，通过不同方法实现沙箱，可以满足不同场景的需求。在实现时需考虑限制与优化，确保安全性和性能。

Android应用安全指南-反逆向

       Android应用逆向工程是一个常见的安全威胁，可能导致敏感信息泄露和安全漏洞。为保护Android应用免受此类攻击，可以采取多种策略。首先，确保服务器上的代码安全，使用Proguard混淆代码，添加多因素身份验证以增加安全性。逆向工程允许攻击者获取源代码，从而利用内存损坏、执行代码等漏洞。保护应用程序免受攻击的关键是识别潜在威胁，如越狱、服务器信息泄露、认证验证不当、授权不足、会话到期等。

       防止逆向工程的第一步是利用技术手段，如ProGuard，它能够减小代码库，使其更复杂，从而增加逆向工程的难度。通过检查签名以确认源代码的完整性，可以进一步提高安全性。使用Appdome等工具改变共享库加载过程，以保护本地代码元素，确保攻击者无法轻松访问关键信息。将关键数据传输到加密服务器端，避免存储在本地设备上，降低数据泄露风险。使用C/C++编写重要代码，因为相比Java代码，它们更难以反编译。确保数据传输时使用SSL/TLS，防止数据在传输过程中的泄露。使用PBKDF2、bcrypt和scrypt等安全的哈希算法，避免使用容易受到攻击的MD2、MD5和SHA1。保护用户凭证和API密钥，避免在代码中硬编码。使用数据加密，如SQLCipher或Realm，以确保数据库中的敏感信息得到保护。

       另外，白名单命令的使用限制了攻击者可能执行的操作。避免使用外部存储，以防止敏感信息泄露。安全地管理数据库加密，利用现代数据库工具提供的功能。Google的SafetyNet工具可以帮助识别root设备，并检测潜在的恶意修改。集成多因素身份验证增加访问控制的复杂性，使攻击者难以绕过安全策略。通过这些策略和工具的结合应用，可以为Android应用程序构建一层强大的防御，抵御逆向工程和其他安全威胁。