说明

此文章为个人经验总结，纯当自用笔记(反正也没人看)，每个人的体质和情况各不相同，不保证对每个人都有效。

某伟人曾说过：身体是革命的本钱，钱没了还可以再嫌，人病了那就人财两空了。

口腔溃疡

口腔溃疡一般是由于饮食不均衡导致的，在外漂泊的打工人多数没有条件自己做饭，吃外卖又容易营养不均衡，解决办法如下：

• 常备维生素B族(10块钱一瓶的那种，不要买保健品！)，药店里有，千万不要买那些几十几百的，都是智商税，感觉有点溃疡的苗头时就要提前吃，或者每周定期吃。
• 酸奶，冰箱里常备酸奶，饭后来一杯，酸奶含有多种人体所需维生素，正好弥补吃外卖饮食不均衡问题

自此以后再也不怕口腔溃疡啦！

说明

在之前的文章：使用左右值树形数据结构实现树形菜单 中记录了如何使用左右值增删改查节点，本次将记录一下如何移动节点，语言使用JAVA + MYSQL实现。

总体思路

移动节点的大致思路是记录移动节点和目标节点之间的左右值以及其子节点的左右值，移动节点及其子节点左右值和目标节点及其子节点的左右值相互加减。

举例

节点A的左右值是LEFT=1,RIGHT=2，节点B的左右值是LEFT=5,RIGHT=6，现在要将节点A移动到节点B前面，那么它的移动范围就是RIGHT - LEFT + 1，即：2 - 1 +1 = 2，也就是说节点A左右值+2，左右值小于节点B的左右值-2 。

结果：节点A的LEFT = 3 ,RIGHT = 4，节点B前面的节点左右值减了2变成了LEFT=1,RIGHT=2，相当于和节点A换了个位置，如此来达到移动节点的目的

后续的移动到节点B后面、移动到节点B作为其子节点思路相同。

更新

2021-6-22 更新

修复了BUG，最新代码请关注： https://github.com/reinershir/lui-auth 以下代码摘抄自菜单管理功能

前言

在前一章记录了如何使用netty作为TCP通信的服务端：点击前往 ，本章记录一下如何解决硬件设备在接收到服务端发送过来的消息时有连包的问题。

问题描述

在通过监测硬件的收包信息时发现偶尔会出现心跳包和指令“粘”在一块的情况，例如指令的发送内容是：EEFF0103GGHH,心跳包的回复是：EEFF0201GGHH。

当心跳包返回信息的时候此时正好指令下发，那么设备端就会收到：EEFF0103GGHHEEFF0201GGHH。

这是由于调用netty的writeAndFlush()方法时并不是马上将数据发送过去，而将它放在一个缓冲池当中，而由于硬件的一发一收通信机制客户端无法对连包的数据做分割，因此这个问题要由服务端解决。

HTTP、HTTPS、TCP/IP总结

协议分类

HTTP属于应用层协议，TCP属于传输层协议，IP属于网络层协议，一个HTTP协议由IP协议包体包含了TCP协议内容，而TCP协议包体又包括了HTTP协议内容，就像一个洋葱。

HTTP请求历程

一个HTTP请求的完整历程，首先会根据URL解析请求的地址和端口，此时的地址拿到的一般是域名，因此还需要根据DNS服务器获取域名的真实IP。

NDS服务查询完毕后，此时浏览器会调用Socket库将HTTP协议里的内容包装成TCP或者UDP协议包。

光靠TCP协议还无法具备传输功能，因此TCP还需要借助IP协议来定位目标服务器在互联网中的位置，光靠IP依旧无法准确定位，因为一个IP可能有好几台设备使用，要明确要传输的目标还得在IP头部加上目标的MAC地址。

最后由网卡将数字信息转换为光信号经网线发送出去，将服务器通过交换机和路由器接收到请求包后像剥洋葱一样一层一层解析包中内容。

小结，一个HTTP请求总共要经历如下几层协议：

• 应用层：定义数据格式，并按照对应的格式解读数据。 –HTTP

• 传输层：定义端口，确认主机上应用程序的身份，并将数据包交给对应的应用程序。 –TCP

• 网络层：定义IP地址，确认主机所在的网络位置，并通过IP进行MAC寻址，对外网数据包进行路由转发。 –IP

• 链路层：对0和1进行分组，定义数据帧，确认主机的物理地址，传输数据。 –物理传输

前言

最近看了《白帽子讲WEB安全》，书的内容可能已经过时了，但是用来提高安全意识还是不错的，现在将它记下来做个总结。

WEB安全整体给我的感觉是虽然重要，但攻击手段有限，安全的大头还是在服务器安全这块。

XSS攻击

先来第一个，XSS攻击，XSS攻击主要分为两类： 1、存储型XSS 2、反射型XSS ，先来看反射型XSS攻击。

反射型XSS攻击

所谓反射型XSS攻击其实就是利用JAVASCRIPT解析漏洞，将原本该解析成HTML的内容解析成了JS代码,那么如何实现攻击的呢？ 假设某个20年前原始的网站有如下代码：

1
2
3
4

请输入搜索关键字：<input type="text" name="search" >

您的搜索关键字是：${keyword}

此时我们输入：<script>alert('xss')</script> ,点击搜索后，发现页面上打印alert(xss)了，但是这样只是控制了自己的浏览器JS，没有意义（用浏览器控制台一样可以做到），因此要将此漏洞散布出去。

假设它的搜索请求url是：http://reiner.host/search?keyword=WEB安全总结 ，将其改为 http://reiner.host/search?keyword= ,并将链接分享出去，诱导别人去点击。

此时这个倒霉鬼如果刚好登陆了该网站，那么你就可以通过JS拿到他的sessionId,然后弄个不可见的iframe将sessionId传到自己的服务器，从而为所欲为了。

PS:担心加上JS代码后链接过长可以弄个短链接。

所以防止反射型XSS的关键点在于不能直接将用户输入的内容展现出来，绝大部分前端框架一般是解决了此问题的，即用户输入内容不会被浏览器解析为JS代码，但不排除一定就没有XSS漏洞了。

防反射型XSS攻击总结

1、对于用户输入的内容不要直接展示

2、使用稳定的开源框架，一般有自动处理

这就是为什么要注意不要乱点链接

说明

微信开发真乃坑中之坑，会话阻塞场景如下：

小程序，有两个用户同时访问同一个接口会阻塞，第二个请求的人必须请等一个请求的人处理完毕才会响应第二个请求。

但如果我在 PC 上用两个不同的浏览器同时请求这个接口，是并行的，从结果上来看可能是 session 阻塞，即同一个会话同时只能处理一个请求。

我的测试代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@RestController()
@RequestMapping("test")
public class TestController {
	
	@GetMapping("block")
	public String test2() {
		try {
			System.out.println("blocking...   "+Thread.currentThread().getName());
			Thread.sleep(8000l);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
		return "OK";
	}
}

两个不同的小程序用户同时请求，第二个请求的人必须请等一个请求的人返回OK才会打印第二个请求的日志，理论上来说，不同用户的请求应当是并行的，但服务器似乎将它们视为同一个会话(session)了。

一开始想到了异步处理，即controller返回callable让处理不占用会话，但是发现这样做事务没法控制！

解决办法

最终使用了比较粗暴的解决办法，即不使用微信浏览器生成的session id，而是每次请求都由前端生成一个随机数作为session id，这样用户的请求就不会被视为同一个会话了

说明

本文记录了在使用netty作为TCP服务端的情况下，如何解决TCP粘包、半包问题，以及如何使用16进制与客户端进行通信。

依赖

首先添加maven依赖：

1
2
3
4

<dependency>
    <groupId>io.netty</groupId>
    <artifactId>netty-all</artifactId>
</dependency>

代码

创建字节转换类

首先创建一个将字节转换为16进制的处理类，并判断包头包尾是否正确。

前言

最近上AMAZON买个台Oculus Quest2玩玩，前前后后折腾了整整一个星期才终于搞定激活问题！因此这在里写下记录希望后来的网友们少走弯路。

找了下网上的教程发现需要借助智能路由器，而我平时不怎么需要这个东西，就为了激活而买个路由器也不划算，因此我选择了笔记本共享热点的方式。

说道Oculus quest2 我想先简单的评测下，先说说它的优点：

• 支持透视，找手柄时不用摘下头盔了

• 支持手势操作，简单的操作无需手柄了

• 最大的优势—–>没有乱七八糟的线！比如PSVR就要插一堆线，每次看着这么多线就没有开启的动力了

• 一体机，即可以直接使用又可以WIFI串连电脑玩STEAM VR游戏！

• AMAZON退税后约只需1900-2000左右（不要上TB买JS的）

再说说它的不足之处：

• 清晰度和PSVR相差不大，至少我的眼睛感觉没有明显差距

• 头戴的那个带子刮耳朵

• 一会儿要充电了

• 国内用户无法直接使用

总体来说是目前VR里体验最好的了，不用插线实在是方便

重要的前言

先说说为什么重复造轮子，当时的情况是只需要一个简单的延时任务，做到不丢失即可，引入分布式定时任务框架又觉得太重，因此手动造了个基于redis的简单可靠定时任务。

适用场景，此种做法在单机部署情况下是肯定没问题的，在分布式部署情况下可能会出现问题，比如同一个服务同时重启了，又刚好同时读取redis中的定时任务，还刚好就在那几十毫秒的情况下没有检测到redis锁，此时会导致任务重复读取。

因此，在定时任务的代码中需要容忍可能会出现重复执行的情况，一般做法是用订单状态判断，所以如果不是非常严格的场景，这套做法是够用了 (复杂的定时任务建议用QUARTZ)。

上代码

废话结束，接下来上代码，首先创建定时任务的实体类，保存定时任务执行时间、订单ID、订单类型等。

定时任务实体类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100

public class DelayedInfo implements Delayed {
    private String orderId;
    /**
     * 任务类型（订单类型）
     */
    private Integer delayType;
    /**
     * 当前时间
     */
    private long currentTime;
    /**
     * 任务执行时间=当前时间 + 延时任务执行时间
     */
    private long startTime;
    /**
     * 延时时间,单位为秒
     */
    private long timeOut;
    public DelayedInfo(){}

    public DelayedInfo(String orderId, long currentTime, long timeOut) {
        this.orderId = orderId;
        this.currentTime = currentTime;
        this.startTime = currentTime + timeOut * 1000l;
        this.timeOut=timeOut;
        this.delayType=Contract.ORDER_TYPE_CHARGE;
    }
    
    public DelayedInfo(String orderId, long currentTime, long timeOut,int orderType) {
        this.orderId = orderId;
        this.currentTime = currentTime;
        this.startTime = currentTime + timeOut * 1000l;
        this.timeOut=timeOut;
        this.delayType=orderType;
    }

    @Override
    public long getDelay(TimeUnit unit) {
        return unit.convert(startTime - System.currentTimeMillis(), unit);
    }

    @Override
    public int compareTo(Delayed other) {
        if (other == this){
            return 0;
        }
        if(other instanceof DelayedInfo){
            DelayedInfo otherRequest = (DelayedInfo)other;
            long otherStartTime = otherRequest.getStartTime();
            return (int)(this.startTime - otherStartTime);
        }
        return 0;
    }

    public String getOrderId() {
        return orderId;
    }

    public void setOrderId(String orderId) {
        this.orderId = orderId;
    }

    public long getStartTime() {
        return startTime;
    }

    public void setStartTime(long startTime) {
        this.startTime = startTime;
    }

    public long getCurrentTime() {
        return currentTime;
    }

    public void setCurrentTime(long currentTime) {
        this.currentTime = currentTime;
    }

    @Override
    public String toString() {
        return JacksonUtil.toJSon(this);
    }

	public long getTimeOut() {
		return timeOut;
	}

	public void setTimeOut(long timeOut) {
		this.timeOut = timeOut;
	}

	public Integer getDelayType() {
		return delayType;
	}

	public void setDelayType(Integer delayType) {
		this.delayType = delayType;
	}
    
}

其中delayType、OrderType就是订单类型的枚举标识，可自己定义标识。

前言

由于太长，分成两篇记录，第一篇地址： 自自技术笔记（一）

JAVA数据结构相关笔记

hashmap
数组加链表存储，通过hash计算key值直接计算出链表在数组中的下标位置，再通过遍历链表判断hash查找value
二叉树其实就是链表的加强版

Java所有集合类型

• 1.ArrayList
• 2.LinkedList
• 3.Set 只允许一个null，且是无序的
• 4.TreeSet 有序的，访问遍历比较快，底层基于TreeMap，TreeSet根据其 compare() 和 compareTo() 的定义进行排序的有序容器。
• 5.TreeMap 红黑树数据结构，有序的，非同步
• 6.HashSet 散列法，底层基于Hashmap，无序
• 7.LinkedHashSet 有序的，底层基于HashMap
• 8.HashMap
• 9.HashTable
• 10.Vector 动态数组，线程安全

注意:共10个集合类！

Hashmap扩容机制
loadFactor默认0.75，扩容时要满足一下两个条件
1、 存放新值的时候当前已有元素的个数必须大于等于阈值
2、 存放新值的时候当前存放数据发生hash碰撞（当前key计算的hash值换算出来的数组下标位置已经存在值）
扩容时一般成倍扩容，自jdk1.8后引入新机制
当hash碰撞的链表长度超过默认的8时自动由链表变为红黑树
注意点:如果map触发扩容会重新计算每个数据的位置，所以应尽量避免扩容

ArrayList和LinkedList

• 1.arraylist是动态数组，适合使用下标随机访问，不适合添加删除，因为添加删除要移动数据。
• 2.linkedlist是双向链表数据结构，适合添加和删除，不适合通过下标随机访问，因为他是通过移动指针一个一个节点的去遍历
• 3.linkedlist插入和删除劲量操作第一个或者最后一个效率最高。

HashMap和HashTable

• 1.hashmap基本上可以代替haahtable了
• 2.hashtable是线程安全
• 3.hashtable的迭代器不同，当迭代过程中hashtable的值被修改时会报错
• 4.HashMap把Hashtable的contains方法去掉了，改成containsValue和containsKey，因为contains方法容易让人引起误解。
• 5.Hashtable继承自Dictionary类，而HashMap继承自AbstractMap类。但二者都实现了Map接口。