Inbox

JWT, JSON Web Token 会话 会话跟踪技术是一种在客户端与服务器间保持 HTTP 状态的解决方案,我们所熟知的有 Cookie + Session、URL 重写、Token 等。 jwt JWT 的全称是 Json Web Token,是一种基于 JSON 的、用于在网络上声明某种主张的令牌 (token) 规范。 JWT 由三部分组成: head、payload、signature, 各部分通过 . 连接 xxxx . yyyy . zzzz HEAD 头部是一个 JSON 对象,包含了一些元数据, 存储描述数据类型 (JWT) 和签名算法 (HS256(HMAC-SHA256) 、RS256(RSA-SHA256) 还有 ES256(ECDSA-SHA256)) ,通过 Base64UrlEncode 编码后生成 head 。 { "typ" : "JWT", "alg" : "HS256" } type: 必需。token 类型,JWT表示是 JSON Web Token. alg: 必需。token 所使用的签名算法, 可用的值在这里有规定。 PAYLOAD 负载存放一些传输的有效声明,可以使用官方提供的声明, 也可以自定义声明。同样通过 Base64UrlEncode 编码后生成 payload。 声明可以分为三种类型: ...

SPA 单页应用程序 单页Web应用 (single page web application,SPA) ,就是只有一张Web页面的应用,是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。单页Web应用 (single page web application,SPA) ,就是只有一张Web页面的应用。单页应用程序 (SPA) 是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。 [1] 浏览器一开始会加载必需的HTML、CSS和JavaScript,所有的操作都在这张页面上完成,都由JavaScript来控制。因此,对单页应用来说模块化的开发和设计显得相当重要。

日期格式标准 如时间为: 2020-01-12T15:17:21 国际标准化组织的国际标准ISO 8601是日期和时间的表示方法，全称为《数据存储和交换形式·信息交换·日期和时间的表示方法》 原文如下： 日期和时间的组合表示法编辑 合并表示时，要在时间前面加一大写字母T，如要表示北京时间2004年5月3日下午5点30分8秒，可以写成2004-05-03T17:30:08+08:00或20040503T173008+08。 所以这个T date和time合并表示时，中间加个T。 iso 8806的百度地址是： https://baike.baidu.com/item/ISO%208601/3910715?fr=aladdin ———————————————— 版权声明：本文为CSDN博主「chushiyunen」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/enthan809882/article/details/103946177 https://www.cnblogs.com/tzyy/p/5099207.html ISO日期格式标准,浏览器到服务器到MySQL中的时区 章节目录 时区简单理解 ISO_8601 日期格式标准 HTML5 input 标签datetime属性 MySQL时区 时区简单理解 https://zh.wikipedia.org/wiki/%E6%97%B6%E5%8C%BA 上面的链接是时区的wiki说明,下面说说我记住的部分: GMT时区是格林威治标准时间,我把它理解为 “真实时间” UTC时区是根据GMT得来的"世界标准时间",它的时间和GMT是相同的 CST可以指下列的时区: 澳洲中部时间,Central Standard Time (Australia) 中部标准时区 (北美洲) ,Central Standard Time (North America) 北京时间,China Standard Time 古巴标准时间,Cuba Standard Time,参见北美东部时区 其中我们所在的时区背景时间 CST=UTC+8小时,也就是说,真实时间是0点的时候,背景时间是8点 ISO_8601日期格式标准 https://zh.wikipedia.org/wiki/ISO_8601 上面是日期格式标准的wiki 当前的UTC时间是2016-01-07T01:58Z, 其中Z是4位数字格式的时间偏移量, 不写的时候默认不偏移。 其中,字母T代表使用UTC时间,字母Z代表时间偏移量,实际写法中字母Z应该被偏移量替换,例如 “2017-1-7T10:21+0800"或者"2017-1-7T10:21-0800”,字母Z被+0800和-0800替换了。 在浏览器中直接new一个date对象,因为我们处于UTC+0800的时区,所以控制台给我们打印出来的时间是GMT+0800的时间 2016-01-07T00:00 代表UTC时区1月7日0时0分 (在控制台中显示UTC+0800时区为8时0分) 2016-01-07T00:00 0800 代表UTC+0800时区1月7日0时0分,2016-01-07T00:00 -0800 代表UTC-0800时区1月7日0时0分,在控制台中显示分别如下 ...

linux string cut, sort https://www.cnblogs.com/farwish/p/4806018.html https://blog.csdn.net/xwhself/article/details/6118722

elk install download elasticsearch https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.3.1.rpm install jdk8 yum localinstall elasticsearch-6.3.1.rpm start elasticsearch, it will generate default config file systemctl start elasticsearch edit config file /etc/elasticsearch/elasticsearch.yml path.data: /data/server/elasticsearch path.logs: /data/server/elasticsearch network.host: 0.0.0.0 mkdir -p /data/server/elasticsearch/ chown -R elasticsearch:elasticsearch elasticsearch/ systemctl restart elasticsearch install ingest geoip plugin download from https://artifacts.elastic.co/downloads/elasticsearch-plugins/ingest-geoip/ingest-geoip-6.3.1.zip download kibana yum localinstall kibana edit kibana config file, vi /etc/kibana/kibana.conf server.host: “xxx” elasticsearch.url: “http://elasticsearch-ip:9200” systemctl restart kibana check if kibana works http://kibana-ip:5601 download and install filebeat

‘填充模式,PKCS#5/PKCS7’ https://blog.csdn.net/test1280/article/details/75268255 填充模式: PKCS#5/PKCS7 首先我们要了解下啥是填充模式。 在分组加密算法中 (例如DES) ,我们首先要将原文进行分组,然后每个分组进行加密,然后组装密文。 其中有一步是分组。 如何分组？ 假设我们现在的数据长度是24字节,BlockSize是8字节,那么很容易分成3组,一组8字节； 考虑过一个问题没,如果现有的待加密数据不是BlockSize的整数倍,那该如何分组？ 例如,有一个17字节的数据,BlockSize是8字节,怎么分组？ 我们可以对原文进行填充 (padding) ,将其填充到8字节的整数倍！ 假设使用PKCS#5进行填充 (以下都是以PKCS#5为示例) ,BlockSize是8字节 (64bit) : 待加密数据原长度为1字节: 0x41 填充后: 0x410x070x070x070x070x070x070x07 待加密数据原长度为2字节: 0x410x41 填充后: 0x410x410x060x060x060x060x060x06 待加密数据原长度为3字节: 0x410x410x41 填充后: 0x410x410x410x050x050x050x050x05 待加密数据原长度为4字节: 0x410x410x410x41 填充后: 0x410x410x410x410x040x040x040x04 待加密数据原长度为5字节: 0x410x410x410x410x41 填充后: 0x410x410x410x410x410x030x030x03 待加密数据原长度为6字节: 0x410x410x410x410x410x41 填充后: 0x410x410x410x410x410x410x020x02 待加密数据原长度为7字节: 0x410x410x410x410x410x410x41 填充后: 0x410x410x410x410x410x410x410x01 待加密数据原长度为8字节: 0x410x410x410x410x410x410x410x41 填充后: 0x410x410x410x410x410x410x410x410x080x080x080x080x080x080x080x08 假设待加密数据长度为x,那么将会在后面padding的字节数目为8-(x%8),每个padding的字节值是8-(x%8)。 特别地,当待加密数据长度x恰好是8的整数倍,也是要在后面多增加8个字节,每个字节是0x08。 给出一个PKCS#5的实现: static size_t padding(unsigned char *src, size_t srcLen) { // PKCS#5 size_t paddNum = 8 - srcLen % 8; ...

systemctl start networking.service networking.service raises or downs the network interfaces configured in /etc/network/interfaces, that is, those network interfaces which are not managed by NetworkManager. If you look into /lib/systemd/system/networking.service you will see that all it does is ifup or ifdown depending on whether it is to be started or stopped. https://askubuntu.com/questions/850339/what-is-the-networking-service

Mesos Mesos 最初由 UC Berkeley 的 AMP 实验室于 2009 年发起,遵循 Apache 协议,目前已经成立了 Mesosphere 公司进行运营。Mesos 可以将整个数据中心的资源 (包括 CPU、内存、存储、网络等) 进行抽象和调度,使得多个应用同时运行在集群中分享资源,并无需关心资源的物理分布情况。 https://yeasy.gitbooks.io/docker_practice/mesos/intro.html

tlv 通信协议 (communications protocol) 是指双方实体完成通信或服务所必须遵循的规则和约定。通过通信信道和设备互连起来的多个不同地理位置的数据通信系统,要使其能协同工作实现信息交换和资源共享,它们之间必须具有共同的语言。交流什么、怎样交流及何时交流,都必须遵循某种互相都能接受的规则。这个规则就是通信协议。 本文描述了一种 Type-length-value 结构的数据编码格式,简称为TLV编码。对于TCP/IP模型来说,TLV属于应用层协议。TLV编码可以自我嵌套,即一个TLV的value部分可以包含一个或多个TLV,这样的结构使得TLV编码十分容易扩展。 http://www.wtango.com/tlv%E7%BC%96%E7%A0%81%E9%80%9A%E4%BF%A1%E5%8D%8F%E8%AE%AE%E8%AE%BE%E8%AE%A1/

yubikey, challenge-response archlinux sudo install yubi pam set configuration sloat 2 as hmac-sha1 ykpamcfg -2 -v mkdir /data/yubikey mv ~/.yubico/challenge-123456’ /data/yubikey vim /etc/pam.d/sudo add line auth sufficient /usr/lib/security/pam_yubico.so mode=challenge-response debug chalresp_path=/data/yubikey auth sufficient /usr/lib/security/pam_yubico.so mode=challenge-response chalresp_path=/data/yubikey pacman -S yubico-pam pacman -S yubikey-manager

数字摘要, 数字签名 http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html http://ihenu.iteye.com/blog/2221604 数字摘要和数字签名等概念 数字摘要技术 数字摘要技术 (Digital Digest) 也称作为安全HASH编码法 (SHA: Secure Hash Algorithm) 。数字摘要技术用于对所要传输的数据进行运算生成信息摘要,它并不是一种加密机制,但却能产生信息的数字"指纹",它的目的是为了确保数据没有被修改或变化,保证信息的完整性不被破坏。 数字摘要技术有如下主要特点: ·它能处理任意大小的信息,并对其生成固定大小的数据摘要,数据摘要的内容不可预见 ·对于相同的数据信息进行HASH后,总是能得到同样的摘要；如果数据信息被修改,进行Hash后,其摘要必定与先前不同 ·HASH函数是不可逆的,无法通过生成的数据摘要恢复出源数据 数字签名 数字签名 (Digital Signature) 用来保证信息传输过程中完整性、提供信息发送者的身份认证和不可抵赖性。使用公开密钥算法是实现数字签名的主要技术。 使用公开密钥算法,当你用自己的私钥加密了一个信息,并将其发送给一个朋友时,如果你的朋友能够使用你的公钥来解密出信息,他就能确定信息必定是从你那里发来的,而不是一些冒名顶替的。这实际上就是数字签名的原理。 由于公开密钥算法的运算速度比较慢,因此可使用HASH函数对要签名的信息进行摘要处理,减小使用公开密钥算法的运算量。因此,数字签名一般是结合了数字摘要技术和公开密钥算法共同使用 实现数学签名的过程如下: 签名信息 1. 对信息M进行HASH函数处理,生成摘要H 2. 用你的 (发送者的) 私钥加密H来获取数字签名S 3. 发送 {M, S} 验证签名信息 1. 接受{M, S} 并区分开它们 2. 对接收到的信息 M进行HASH函数处理,生成摘要H* 3. 取得发送者的公钥 4. 用公钥解密S,来获取H 5. 比较H和H*,如果H和H*是一样的,即说明信息在发送过程中没有被篡改,反之即反 由于对信息进行数字签名后,明文信息也通过网络进行传递,因此,在做完数字签名后,还要对整个信息 (包括明文信息M和数字签名的密文信息S) 进行加密,以保证信息的保密性。 数字证书: 数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息和公开密钥的文件。最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。一般情况下证书中还包括密钥的有效时间,发证机关 (证书授权中心) 的名称,该证书的序列号等信息,证书的格式遵循ITUT。 CA机构 证书授证 (Certificate Authority) 中心 出现CA机构的目的: 防止有的一些用户的公钥被非法替换,造成数据的泄露

U2F(Universal 2 Factor) U2F(Universal 2 Factor)标准是由Yubico公司和Google发起的FIDO(Fast IDentity Online)联盟推出的标准, 旨在提供一个方便的免驱动、通用型的密码认证令牌, 期望能在让用户在有U2F认证的情况下, 即使用短密码, 也能实现高强度的认证. 而且这种认证是不依赖中心服务器的, 完全基于公私钥/PKI体系. U2F的物理层可以是USB-HID, 也可以是NFC(目前Yubikey Neo支持)http://scateu.me/2016/11/30/u2f-zero.html FIDO U2F规范,U2F (Universal 2nd Factor) 是 Yubico, Yahoo 和 Google 联合开发的基于物理设备的双因素认证协议,目前已经完成标准化,从属于 FIDO (Fast Identity Online) 联盟名下。

kibana 查询 匹配查询 message: "15909840000" 模糊查询 message:1590984* Range Searches mod_date:[20020101 TO 20030101] 逻辑操作 AND OR 必须大写 AND OR 表示搜索结果中必须包含此项 表示不能含有此项 source:S0 AND message:M0 https://lucene.apache.org/core/2_9_4/queryparsersyntax.html https://www.jianshu.com/p/e6143951be9b

manually install python modules https://stackoverflow.com/questions/32798137/importerror-no-module-named-appdirs download modules from pypi.python.org wget https://pypi.python.org/packages/48/69/d87c60746b393309ca30761f8e2b49473d43450b150cb08f3c6df5c11be5/appdirs-1.4.3.tar.gz gunzip appdirs-1.4.3.tar.gz tar -xvf appdirs-1.4.3.tar cd appdirs-1.4.3 sudo python setup.py install

linux seq seq命令用于产生从某个数到另外一个数之间的所有整数。 seq [选项]… 尾数 seq [选项]… 首数 尾数 seq [选项]… 首数 增量 尾数 http://man.linuxde.net/seq

温度监控, lm-sensors, temperature 不用安装其它软件的方法 cat /sys/class/thermal/thermal_zone0/temp echo $[$(cat /sys/class/thermal/thermal_zone0/temp)/1000]° sensors apt-get install lm-sensors # 检测传感器 sh -c "yes|sensors-detect" # 查看CPU的温度 sensors 输出 coretemp-isa-0000 Adapter: ISA adapter Package id 0: +57.0°C (high = +105.0°C, crit = +105.0°C) Core 0: +57.0°C (high = +105.0°C, crit = +105.0°C) Core 1: +57.0°C (high = +105.0°C, crit = +105.0°C) Core 2: +57.0°C (high = +105.0°C, crit = +105.0°C) Core 3: +58.0°C (high = +105.0°C, crit = +105.0°C) acpitz-acpi-0 Adapter: ACPI interface temp1: +27.8°C (crit = +119.0°C) nvme-pci-0400 Adapter: PCI adapter Composite: +64.8°C (low = -273.1°C, high = +84.8°C) (crit = +84.8°C) Sensor 1: +64.8°C (low = -273.1°C, high = +65261.8°C) Sensor 2: +74.8°C (low = -273.1°C, high = +65261.8°C) 原贴:http://goodfifagun.pixnet.net/blog/post/21587839 現在購買主機板時都會有廠商提供的監控軟體可以使用，而最常使用到到功 能像溫度監控，系統狀態等等，但是這些軟體都只能在windows 下使用，所 以如果要在 linux下監控CPU溫度，可以透過 lm-sensor這套軟體來監控。安裝環境: ubuntu 8.04.1 安裝步驟: 安裝lm-sensors apt-get install lm-sensors 2. 設定監控選項 sensors-detect 通常都是回答yes即可，注意最後一項，例如下面的資訊 To load everything that is needed, add this to /etc/modules: #--cut here-- I2C adapter drivers modprobe unknown adapter NVIDIA i2c adapter modprobe unknown adapter NVIDIA i2c adapter modprobe unknown adapter NVIDIA i2c adapter i2c-i801 ...

elasticsearch #查看索引 GET /_cat/indices?pretty curl -X GET "localhost:9200/_cat/indices?v" GET /index-2018.09.29/_stats GET /_cat/indices?pretty # elasticsearch 重启后用以下命令观察集群状态。 watch -n 1 -d curl -XGET http://localhost:9200/_cluster/health\?pretty curl -X GET "localhost:9200/_cluster/allocation/explain?pretty" -H 'Content-Type: application/json' -d' { "index": "myindex", "shard": 0, "primary": true } ' unassigned_shards: 没有被分配到节点的分片 unassigned_shards 在elasticsearch 重启后会逐渐减少, 9如果最终unassigned_shards不为0,则需要手动处理。 # 找出未分配到结点的分片 curl -s "http://localhost:9200/_cat/shards" | grep UNASSIGNED curl 'localhost:9200/_cat/master?v' ES_JAVA_OPTS="-Xms2g -Xmx2g" /usr/share/elasticsearch/bin/elasticsearch -d -Ecluster.name=my-application -Enode.name=node-1 -Enode.master=true -Enode.data=false -Epath.data=/data/server/elasticsearch-node1 -Epath.logs=/data/logs/elasticsearch-node1 -Enetwork.host=0.0.0.0 -Ehttp.port=9200 -p /home/elasticsearch/node1_pid kill `cat /home/elasticsearch/node1_pid` curl -XGET http://localhost:9200/_cluster/health\?pretty curl -XGET http://localhost:9200/_cat/shards curl -s "http://localhost:9200/_cat/shards/index-0" curl 'localhost:9200/_nodes/process?pretty' #check if index exist curl --head "localhost:9200/twitter" curl -X GET "localhost:9200/_cat/health?v" curl -X GET "localhost:9200/_cat/nodes?v" curl -X PUT "localhost:9200/customer?pretty" curl -X PUT "localhost:9200/customer/_doc/1?pretty" -H 'Content-Type: application/json' -d' { "name": "John Doe" } ' curl -X GET "localhost:9200/customer/_doc/1?pretty" # delete index curl -X DELETE "localhost:9200/index-0?pretty" curl -X DELETE "localhost:9200/customer/_doc/2?pretty" curl -H "Content-Type: application/json" -XPOST "localhost:9200/bank/_doc/_bulk?pretty&refresh" --data-binary "@accounts.json" curl "localhost:9200/_cat/indices?v"

X11 forwarding https://wiki.archlinux.org/title/OpenSSH pacman -S xorg-xauth xorg-xhost /etc/ssh/sshd_config X11Forwarding yes AllowTcpForwarding yes X11UseLocalhost yes X11DisplayOffset 10 systemctl restart sshd pacman -S xorg-xclock https://gist.github.com/vietlq/8b20d09fdfe5f02f8b511c7847df39ee win 10 xserver, x11forward Install VcXsrv Windows X Server Download and install: https://sourceforge.net/projects/vcxsrv/ Check that VcXsrv runs and right-click, get logs to find DISPLAY=127.0.0.1:0.0 Note down the value of $DISPLAY and pass it ot PuTTY Configure PuTTY Navigate to SSH => X11 => Tick Enable X11 forwarding Pass the value of $DISPLAY (which is 127.0.0.1:0.0) to the field X display location Launch from Ubuntu Use PuTTy to log in as normal Run gvim for example on the Ubuntu via PuTTY Use the GVim window ...

Remote IP Valve, X-Forwarded-For等http头字段 http://www.10tiao.com/html/308/201702/2650076434/1.html http://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html X-Forwarded-For等http头字段与Tomcat的 Remote IP Valve (Valve源码分析之六) 2017-02-18 16:28 feiying 0 0 阅读 297 Proxies Valve是代理Valve,其作用是可以对负载均衡代理服务器的IP地址与原request的IP地址做请求转换,让服务器端真正识别原IP地址 (如果服务器端有需要的话) ； 本文主要讨论这种地址转换是如何做的； 1.X-Forwarded-For等http头字段 在我们现实的真正的场景中,通常Tomcat直接和用户接触的场景不多,主要是通过代理转发机制进行,如下: 真正的用户客户端是Client1,代理转发服务器采用的是Nginx,Proxy1,那么在此场景下,如果在Tomcat中进行获取客户端的地址: request.getRemoteAddr,获得的IP地址绝对是Proxy1的,也就是负载均衡的地址； 而如果你想要获取Client1的地址,也是可以获取到的,就是通过X-Forwarded-For字段； X-Forwarded-For:简称XFF头,它代表客户端,也就是HTTP的请求端真实的IP,只有在通过了HTTP 代理或者负载均衡服务器时才会添加该项。 X-Forwarded-For内置在Http协议头中,一般格式如下: X-Forwarded-For: client1, proxy1, proxy2, proxy3 其中的值通过一个 逗号+空格 把多个IP地址区分开,； 最左边(client1)是最原始客户端的IP地址, 代理服务器每成功收到一个请求,就把请求来源IP地址添加到右边。 在上面这个例子中,这个请求成功通过了三台代理服务器: proxy1, proxy2 及 proxy3。请求由client1发出,到达了proxy3(proxy3可能是请求的终点)。请求刚从client1中发出时,XFF是空的,请求被发往proxy1；通过proxy1的时候,client1被添加到XFF中,之后请求被发往proxy2;通过proxy2的时候,proxy1被添加到XFF中,之后请求被发往proxy3；通过proxy3时,proxy2被添加到XFF中,之后请求的的去向不明,如果proxy3不是请求终点,请求会被继续转发。 鉴于伪造这一字段非常容易,应该谨慎使用X-Forwarded-For字段。正常情况下XFF中最后一个IP地址是最后一个代理服务器的IP地址, 这通常是一个比较可靠的信息来源。[1] 其次,还有一个是X-Forwarded-by字段,该字段是标识为负载均衡proxy的可信代理的IP地址； 例如上面的这个例子,X-Forwarded-For: client1, proxy1, proxy2, proxy3,可以配置当前的应用服务器的X-Forwarded-by字段可信IP为 proxy1, proxy2, proxy3； 这样通过X-Forwarded-For,X-Forwarded-by两个字段进行减法,直接就得到client1了； 还有一个是X-Forwarded-Proto,该字段记录最初从浏览器发出时候,是使用什么协议。因为有可能当一个请求最初和反向代理通信时,是使用https,但反向代理和服务器通信时改变成http协议,这个时候,X-Forwarded-Proto的值应该是https； X-Forwarded-For和X-Forwarded-Proto的信息是很有价值的,在Tomcat中可以通过获取这两个字段的信息,拿到真实的客户端的请求IP和协议； 2.Remote IP Valve Remote IP Valve就是利用X-Forwarded-For和X-Forwarded-Proto等字段,反转得到最原始的客户端的IP和请求信息的； Attributes The Remote IP Valve supports the following configuration attributes: ...

‘Linux oom killer’ https://blog.csdn.net/GugeMichael/article/details/24017515 Linux - 内存控制之oom killer机制及代码分析 2014年04月18日 15:04:29 阅读数: 28048 最近,线上一些内存占用比较敏感的应用,在访问峰值的时候,偶尔会被kill掉,导致服务重启。发现是Linux的out-of-memory kiiler的机制触发的。 http://linux-mm.org/OOM_Killer oom kiiler会在内存紧张的时候,会依次kill内存占用较高的进程,发送Sig15(SIGTERM)或Sig9(SIGKILL),取决于内核版本(可见uname -a,>= 2.6.32只会发送sigkill https://elixir.free-electrons.com/linux/v2.6.18/source/mm/oom_kill.c),。并在/var/log/message中进行记录。里面会记录一些如pid,process,。并在/var/log/message中进行记录。里面会记录一些如pid,process) name,cpu mask,trace等信息,通过监控可以发现类似问题。今天特意分析了一下oom killer相关的选择机制,挖了一下代码,感觉该机制简单粗暴,不过效果还是挺明显的,给大家分享出来。 oom killer初探 一个简单分配 heap memroy 的代码片段 (big_mm.c): #define block (1024L_1024L_MB) #define MB 64L unsigned long total = 0L; for(;;) { // malloc big block memory and ZERO it !! char\* mm = (char\*) malloc(block); usleep(100000); if (NULL == mm) continue; bzero(mm,block); total += MB; fprintf(stdout,"alloc %lum mem\n",total); } 这里有2个地方需要注意: 1、malloc是分配虚拟地址空间,如果不memset或者bzero,那么就不会触发physical allocate,不会映射物理地址,所以这里用bzero填充 2、每次申请的block大小比较有讲究,Linux内核分为LowMemroy和HighMemroy,LowMemory为内存紧张资源,LowMemroy有个阀值,通过free -lm和 ...