最新日志

【C】valgrind工具

2020-12-04

技巧

C
- Valgrind
  - memcheck 工具
Valgrind
- memcheck ——> 这是valgrind应用最广泛的工具，一个重量级的内存检查器，能够发现开发中绝大多数内存错误使用情况，比如：使用未初始化的内存，使用已经释放了的内存，内存访问越界等
- callgrind ——> 它主要用来检查程序中函数调用过程中出现的问题-
- cachegrind ——> 它主要用来检查程序中缓存使用出现的问题-
- helgrind ——> 它主要用来检查多线程程序中出现的竞争问题-
- massif ——> 它主要用来检查程序中堆栈使用中出现的问题-
- extension ——> 可以利用core提供的功能，自己编写特定的内存调试工具
memcheck 工具

参考：https://www.cnblogs.com/AndyStudy/p/6409287.html

运行

执行格式
```
valgrind --tool=memcheck --leak-check=full ./test
```
参数
- -leak-check=no|summary|full 要求对leak给出详细信息? [summary]
- -leak-resolution=low|med|high how much bt merging in leak check [low]
- -show-reachable=no|yes show reachable blocks in leak check? [no]
错误

内存读写越界

Invalid read of size

使用未初始化的内存

Conditional jump or move depends on uninitialised value(s)

重复释放内存

Invalid free() / delete / delete[]

内存泄漏

Memcheck将内存泄露分为两种，一种是可能的内存泄露（Possibly lost），另外一种是确定的内存泄露（Definitely lost）
- Possibly lost 是指仍然存在某个指针能够访问某块内存，但该指针指向的已经不是该内存首地址。
- Definitely lost 是指已经不能够访问这块内存。
  - Definitely lost又分为两种：直接的（direct）和间接的（indirect）
  - 直接是没有任何指针指向该内存
  - 间接是指指向该内存的指针都位于内存泄露处
Read All

signal模块

重写进程接收到的信号，需要写一个handler函数，需要带两个参数signum和frame

例如下面的进程是每次接收到SIGINT的信号时，不再结束进程，而是计数接收到此信号的次数。

这里绑定了一个SIGUSR1的信号，到一个退出程序的函数上

import signal

def count_handler(signum,frame):
    global interupt
    interupt += 1
    print("stop {} times".format(interupt))

def exit1(signum,frame):
    sys.exit()


if __name__ == "__main__":
    signal.signal(signal.SIGINT,count_handler)
    signal.signal(signal.SIGUSR1,exit1)
    for i in range(100):
        time.sleep(1)
        print(os.getpid(),i)

Linux下的信号量

使用kill -l命令查看Linux下的信号量

1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR
31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX

其中SIGUSR1、SIGUSR2信号是留给用户使用的
程序不可捕获、阻塞或忽略的信号有SIGKILL,SIGSTOP .运行时会提示OSError: [Errno 22] Invalid argument
不能恢复至默认动作的信号有：SIGILL,SIGTRAP
默认会导致进程流产的信号有：SIGABRT,SIGBUS,SIGFPE,SIGILL,SIGIOT,SIGQUIT,SIGSEGV,SIGTRAP,SIGXCPU,SIGXFSZ
默认会导致进程退出的信号有：SIGALRM,SIGHUP,SIGINT,SIGKILL,SIGPIPE,SIGPOLL,SIGPROF,SIGSYS,SIGTERM,SIGUSR1,SIGUSR2,SIGVTALRM
默认会导致进程停止的信号有：SIGSTOP,SIGTST,SIGTTIN,SIGTTOU
默认进程忽略的信号有：SIGCHLD,SIGPWR,SIGURG,SIGWINCH

Read All

ClickHouse常用SQL命令

2020-11-27

笔记

查看信息
- 查看数据库的总容量
- 查看分区信息

官方文档:https://clickhouse.tech/docs/zh/introduction/distinctive-features/

查看信息

https://blog.csdn.net/jarry_cm/article/details/106134994

查看数据库的总容量

select
    sum(rows) as row,
    formatReadableSize(sum(data_uncompressed_bytes)) as uncompress,
    formatReadableSize(sum(data_compressed_bytes)) as compress,
    round(sum(data_compressed_bytes) / sum(data_uncompressed_bytes) * 100, 0)  as compress_rate
from system.parts

查看分区信息

select database,table,partition,partition_id,name,path from system.parts where table='visit'

结果

─database─┬─table──┬─partition─┬─partition_id─┬─name─────────┬─path───────────────────────────────────────────────────┐
│ datasets │ visits │ 202006    │ 202006       │ 202006_1_1_0 │ /var/lib/clickhouse/data/datasets/visits/202006_1_1_0/ │
│ datasets │ visits │ 202007    │ 202007       │ 202007_2_2_0 │ /var/lib/clickhouse/data/datasets/visits/202007_2_2_0/ │
│ datasets │ visits │ 202008    │ 202008       │ 202008_3_3_0 │ /var/lib/clickhouse/data/datasets/visits/202008_3_3_0/ │
└──────────┴────────┴───────────┴──────────────┴──────────────┴────────────────────────────────────────────────────────┘

Read All

ClickHouse配置&启动记录

2020-11-27

笔记

Docker
- 安装
- 启动
连接
常规方式
- 安装
- 配置
  - 默认目录
  - 配置文件

Docker

安装

docker pull yandex/clickhouse-server:latest
docker pull yandex/clickhouse-client:latest

启动

docker run -d --name mych_server --ulimit nofile=262144:262144 --volume=[本地存储路径]:/var/lib/clickhouse -p 8123:8123 -p 9000:9000 -p 9009:9009 yandex/clickhouse-server

使用自己的配置文件运行

docker run -d --name mych_server --ulimit nofile=262144:262144 --volume=/home/win4/clickhouse/data:/var/lib/clickhouse -v=/etc/clickhouse-server:/etc/clickhouse-server -p 8123:8123 -p 9000:9000 -p 9009:9009 yandex/clickhouse-server

连接

docker run -it --rm --link mych_server:clickhouse-server yandex/clickhouse-client --host clickhouse-server

也可以

docker exec -it mych_server /bin/bash
clickhouse-client

连接远程的clickhouse-server

docker run -it --rm yandex/clickhouse-client --host 192.168.123.60 --user default  -m 
docker run -it -d --volume /Volumes/TR200/storage:/home/ yandex/clickhouse-client --host 192.168.123.60 --user default  -m 

常规方式

安装

添加Clickhouse源

curl -s https://packagecloud.io/install/repositories/altinity/clickhouse/script.rpm.sh | sudo bash

安装server和client

sudo yum install -y clickhouse-server clickhouse-client

配置

默认目录

参数 /etc/clickhouse-server/config.xml
日志 /var/log/clickhouse-server
存储目录 /var/lib/clickhouse

配置文件

config.xml

listen_host 限制访问数据库的来源

path 数据目录

users.xml

Read All

【精读】How China Detects and Blocks Shadowsocks

2020-11-10

学术

论文

GFW检测和屏蔽ShadowSocks的方法

类型	内容
标题	How China Detects and Blocks Shadowsocks
会议	IMC2020
DOI	<10.1145/3419394.3423644>
原文地址	https://dl.acm.org/doi/abs/10.1145/3419394.3423644

GFW检测和屏蔽ShadowSocks的方法

介绍

ShdowSocks是一种常见的代理协议，文章通过实验发现了目前检测和屏蔽ShadowSocks的方法，并给出了一些建议用来规避检测。自从2017年10月以来，有些用户开始报告自己的shadowsocks服务器开始不可用，尤其是在某些特别时期。

根据作者的研究发现，GFW使用被动流量分析和主动探测组合来识别shadosocks服务器。

背景

shadowsock协议通过对数据加密使其显示为随机的字节流。
ShadowSocks使用两种密码学构造,分别是stream ciphers和 AEAD ciphers

流加密：单纯的对称加密算法，其解密步骤是无法确认密钥是否正确的。也就是说，加密后的数据可以用任何密钥执行解密运算，得到一组疑似原始数据，而不知道密钥是否是正确的，也不知道解密出来的原始数据是否正确
[variable-length IV][encrypted payload...] 

AEAD(authenticated encryption with associated data)是同时具备保密性，完整性和可认证性的加密形式

[variable-length salt]   
[2-byte encrypted length][16-byte length tag]  
[encrypted payload][16-byte payload tag]  
[2-byte encrypted length][16-byte length tag]  
[encrypted payload][16-byte payload tag] 

对于AEAD密码，网络流是一系列长度固定的块。

在两种构造中，发送的第一条数据是和Socks协议一样的目标规范。

[0x01][4-byte IPv4 address][2-byte port]  
[0x03][1-byte length][hostname][2-byte port]  
[0x04][16-byte IPv6 address][2-byte port] 

在实验中使用了Shadowsocks-libev和OutlineVPN两个版本进行实验。

探针

回答以下问题：

在什么情况下观察到了何种类型的探针
探针的来源
探针是否有指纹信息
连接建立后多久会收到探针

实验

搭建服务器，实验从2019年9月29日到2020年1月21日，进行了4个月。使用不同的加密算法，和两个版本Shadowsocks-libev和OutlineVPN 来扩大覆盖范围。

Shadowsocks-libev:在腾讯云北京数据中心上的5个VPS安装了SS客户端，在英国的Digital Ocean数据中心上安装了5个SS服务端。每个客户端都仅连接到其中一台服务器。并且设置了一个空白的对照，没有启动服务，仅仅捕获传入流量。
使用curl产生流量，并且以给定频率访问以下三个网站:https://www.wikipedia.org, http://example.com,https://gfw.report

OutlineVPN:在一个美国大学的网络中安装了OutlineVPN v1.0.7服务端，客户端位于中国的住宅网络中，使用Firefox自动流量Alexa Top100万中的被审查的网站。

局限:位置缺乏多样性

探针类型

一共观察到51837种探针，有5种基于重放的探针

R1 完全相同的重放
R2 修改0字节后重放
R3 修改0-7字节和62-63字节后重放
R4 修改16字节后重放
R5 修改6-16字节后重放

其中R3,R4,R5的探针仅仅发送到OutlineVPN服务器，R5探针仅仅观察到两种

两种探针类型看起来随机，长度各异

NR1 长度在7-9,11-113,15-17,21-23,32-34,40-42,48-50
NR2 长度正好是221字节

探针来源

这些探针来自于12300个不同的IP地址，超过75%的地址发送了超过1个探针，最常见的发送探针的IP地址总结如下表

作者将观察到的ip地址与之前关于Tor服务器相关工作检测到的探针进行了比较，如下图
发现仅有少量重叠。

自治域:如表格所示，统计了探针的所属的自治域

对探针进行指纹识别

IP ID : 找不到清晰的模式
TTL : 在46-50范围内
TCP端口 : 大约90%的探针来自32768-60999端口，从没有探针使用低于1024的端口（前人的工作观察到所有的端口都在使用）
TCP timestamp 一个32位计数器，以固定的速率增加,增长率随着操作系统不同而有所不同。

根据观察发现，虽然有些很多的数据包来自于不同的IP地址，但是他们拥有几乎非常相似的TSvals，这种情况的发生除非是两个进程同时启动。

探针的延迟

下图显示了从第一次建立连接开始，收到探针的延迟。
最短的延迟仅有0.28s,最长的有570小时。超过20%的重放探针在1秒钟内到达，50%的在一分钟内到达，75%的在15分钟内到达。

触发探针

作者猜测有两种方式发送探针，第一种是大规模的端口测试，但是实验中那些没有启动SSR的服务器并没有收到探针，所以这种可能性排除。第二种是仅仅对可疑的ShadowSocks服务器发送探针。

触发探针需要多少流量
为什么R3,R4,R5的探针仅仅发送到OutlineVPN服务器
是否考虑数据包的长度
是否考虑数据包载荷的熵
由外到内的shadowsocks连接是否会产生一样多的探测

实验

设计了一个TCP客户端连接到服务器，仅发送一个指定长度和指定香农熵的数据包
TCP服务器有两种模式，sink和respond，前者不响应任何数据，后者响应1-1000字节的随机数据

Exp #	Client Length (bytes)	Client Entropy	Server Mode
1.a	[1,1000]	> 7	sink
1.b	[1,1000]	> 7	responding
2	[1,1000]	< 2	sink
3	[1,2000]	[0,8]	sink

实验结果

在TCP握手后，一个数据包足以触发探针。

仅有特定长度的数据包会触发探针

Read All

5/23

最新日志

【C】valgrind工具

Valgrind

memcheck 工具

运行

参数

错误

内存读写越界

使用未初始化的内存

重复释放内存

内存泄漏

【Python】signal模块

signal模块

Linux下的信号量

ClickHouse常用SQL命令

查看信息

查看数据库的总容量

查看分区信息

ClickHouse配置&启动记录

Docker

安装

启动

连接

常规方式

安装

配置

默认目录

配置文件

【Python】logging模块打印日志

日志等级

代码

【精读】How China Detects and Blocks Shadowsocks

GFW检测和屏蔽ShadowSocks的方法

介绍

背景

探针

实验

探针类型

探针来源

对探针进行指纹识别

探针的延迟

触发探针

实验

实验结果