如何在透明代理网络环境下得到正常的苹果地图

2023-06-04T00:00:00+00:00

背景</h1>
是这样的，我家的透明代理策略走的是路由器上配置路由表的策略，这个策略是中国大陆的地址直接走的我家的上游，非中国大陆的地址会被路由到我内网专门的代理机器出去, 剩下的中国大陆地址就会走默认的路由。然后DNS做了分流，非中国大陆的域名会默认走 `8.8.8.8</code>进行请求，正好这个 8.8.8.8</code> 的请求正好会被路由匹配到我的代理机器，这样就会所有的非中国域名全部走远程解析并访问了，在不需要的时候直接把路由撤销所有的请求会自动跳转回正常的默认线路，DNS也完全不需要调整（8.8.8.8</code> 正好会被默认路由匹配到）。</p>`

问题</h1>
上面的方案我在大部分情况下都工作的很好，但是我最近遇到了一个问题：我有两个苹果设备，我很喜欢的一个苹果的APP是苹果地图，它接入了很多地图提供商，比如中国大陆接入的是高德地图，这样一个地图就能保持中国大陆内外的一致性体验了（众所周知，在中国的地图提供商没办法看清楚中国大陆以外的地图，海外的地图提供商没办法看清中国大陆境内的地图）。在我家的分流中，苹果地图没办法使用高德德地图提供商，经过我一顿谷歌搜索和抓包，大致有以下结论：</p>

v2ex里面提到苹果的  ls.apple.com</code></a> 这个域名是负责苹果地图判断地理位置数据集加载的接口，但是提到的解决方案不适用于我，因为我的代理策略并没有经过TLS Sniffer。</li>
</ol>
使用 ClashX 代理， macOS 地图.app 无法调用高德的数据。需要添加什么规则才可以使用高德数据？ - V2EX</a></p>

于是我尝试在 Adguard-Home 里面调了下DNS的规则</li>
</ol>
[/*.ls.apple.com/]114.114.114.114
</span></code></pre>
然后发现根本不起作用，然后我看了下 DNS 的日志，发现苹果的DNS有很多 CNAME 到各个 CDN，这样我们就没办法通过 DNS 规则来指定上游解析了，因为我们并不知道苹果有多少 CNAME，并且这些CNAME什么时候会变。并且我就算匹配到了上游，但是因为很多 CDN 在中国大陆并没有接入点，所以最终的访问还是会走代理，这也有可能会影响苹果服务器的判断。</p>
➜  ~ (root@archlinux-router) dig gsp-ssl.ls.apple.com @1.1.1.1
</span>
</span>; <<>> DiG 9.18.15 <<>> gsp-ssl.ls.apple.com @1.1.1.1
</span>;; global options: +cmd
</span>;; Got answer:
</span>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9585
</span>;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
</span>
</span>;; OPT PSEUDOSECTION:
</span>; EDNS: version: 0, flags:; udp: 1232
</span>;; QUESTION SECTION:
</span>;gsp-ssl.ls.apple.com.		IN	A
</span>
</span>;; ANSWER SECTION:
</span>gsp-ssl.ls.apple.com.	3582	IN	CNAME	gsp-ssl.ls-apple.com.akadns.net.
</span>gsp-ssl.ls-apple.com.akadns.net. 12 IN	CNAME	gsp-ssl-geomap.ls-apple.com.akadns.net.
</span>gsp-ssl-geomap.ls-apple.com.akadns.net.	42 IN CNAME gspx-ssl.ls.apple.com.
</span>gspx-ssl.ls.apple.com.	3582	IN	CNAME	get-bx.g.aaplimg.com.
</span>get-bx.g.aaplimg.com.	12	IN	A	17.253.5.208
</span>get-bx.g.aaplimg.com.	12	IN	A	17.253.17.211
</span>
</span>;; Query time: 129 msec
</span>;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
</span>;; WHEN: Sun Jun 04 14:44:12 CST 2023
</span>;; MSG SIZE  rcvd: 209
</span></code></pre>
解决方案</h1>
于是乎问题就变成了， 需要在我家的环境下，让访问苹果  *.ls.apple.com</code> 域名的所有请求（包含 DNS 解析）不走任何的代理，咨询了一下朋友们，大致有以下几个方案</p>


写个脚本，手动解析*.ls.apple.com</code>那几个域名的 IP 地址，然后放到 ip rule 或者其他路由表里。</p>
我并不能枚举所有的 *.ls.apple.com</code> 的域名，而且他们的 CNAME 我更没办法枚举，他们后面的IP地址大概率是CDN的地址，我如果肆意的给这些地址使用特殊规则的话可能会影响我的其他请求访问（比如 Cloudflare 这种全部都是 BGP Anycast IP 的 CDN 厂商，给他的一个IP设置特殊的规则可能会影响到很大比例的网站访问）。</p>
</li>

使用 DNS 解析结果打 fwmark 的插件，然后给它特定的路由，就是那些人只用域名，不用 IP 列表来分流的方案。</p>
dnsmasq 支持操作  ipset</a> ，这样就可以根据DNS结果来让 iptables 给流量打上标记，然后指定查询路由表，但是这个方案还是有上面一样的问题，CDN不友好。</p>
</li>

内网搭建个 SNI Proxy, 在路由器上面 hosts 或者 DNS 服务配置里面将目标域名解析到我的的 SNI Proxy 服务上。</p>
这个方案看起来是可以的，于是我就采用了这个方案。</p>
</li>
</ol>
要实施上面的方案三，大致需要这几个步骤</p>


在内网完全不走任何代理的机器上部署一个SNI Proxy。</p>
使用 Nginx 的来搭建一个 SNI Proxy 服务器，重定向 80 和 443 的流量到需要的服务地址</p>
user http;
</span>worker_processes  1;
</span>
</span>error_log   /var/log/nginx/error.log;
</span>
</span>events {
</span>    worker_connections  1024;
</span>}
</span>
</span>http {
</span>    map $host $backend_name {
</span>        default $host;
</span>    }
</span>    resolver 114.114.114.114 ipv6=off;
</span>
</span>    access_log /var/log/nginx/sni_http_access.log;
</span>
</span>    server {
</span>        listen 80;
</span>        location / {
</span>            proxy_pass http://$backend_name;
</span>            proxy_set_header Host $backend_name;
</span>        }
</span>    }
</span>}
</span>
</span>stream {
</span>    map $ssl_preread_server_name $backend_name {
</span>        default $ssl_preread_server_name;
</span>    }
</span>
</span>    resolver 114.114.114.114 ipv6=off;
</span>
</span>    log_format proxy '$remote_addr [$time_local] $ssl_preread_server_name '
</span>               '$protocol $status $bytes_sent $bytes_received '
</span>               '$session_time "$upstream_addr" '
</span>               '"$upstream_bytes_sent" "$upstream_bytes_received" "$upstream_connect_time"';
</span>    access_log /var/log/nginx/sni_https_access.log proxy;
</span>
</span>    server {
</span>       listen 443;
</span>       ssl_preread on;
</span>       proxy_timeout 5s;
</span>       proxy_pass $backend_name:443;
</span>    }
</span>}
</span></code></pre>
在路由器上关掉本机器的透明代理</p>
ip</span> route add default via 10.0.150.254 dev enp3s0 table 8888
</span>ip</span> rule add from 192.168.233.171 lookup 8888
</span></code></pre>
</li>

使用 DNS 转发器的 DNS 重写功能把 *.ls.apple.com</code> 的请求全部重定向到上面那台机器。</p>
我直接在 Adguard-home 写入如下重定向规则</p>
*.ls.apple.com 192.168.233.171（
</span></code></pre>
</li>
</ol>
最后看检查一下日志和苹果设备上的地图，一切按照预期工作正常。</p>
[root@archlinux-tool ~</span>]# tail</span> -f</span> /var/log/nginx/sni_https_access.log
</span>192.168.233.193 </span>[</span>04/Jun/2023:07:09:42 +0000</span>]</span> gspe1-ssl.ls.apple.com TCP 200 4624 339 5.582 </span>"</span>23.34.208.4:443</span>" "</span>856</span>" "</span>4624</span>" "</span>0.185</span>"
</span>192.168.233.193 </span>[</span>04/Jun/2023:07:09:57 +0000</span>]</span> gspe1-ssl.ls.apple.com TCP 200 4624 339 5.569 </span>"</span>23.34.208.4:443</span>" "</span>856</span>" "</span>4624</span>" "</span>0.180</span>"
</span>192.168.233.193 </span>[</span>04/Jun/2023:07:10:36 +0000</span>]</span> gspe1-ssl.ls.apple.com TCP 200 4773 598 7.844 </span>"</span>23.34.208.4:443</span>" "</span>1115</span>" "</span>4773</span>" "</span>0.189</span>"
</span>192.168.233.193 </span>[</span>04/Jun/2023:07:11:18 +0000</span>]</span> gspe1-ssl.ls.apple.com TCP 200 4624 339 5.603 </span>"</span>23.34.208.4:443</span>" "</span>856</span>" "</span>4624</span>" "</span>0.192</span>"
</span>192.168.233.193 </span>[</span>04/Jun/2023:07:12:34 +0000</span>]</span> gspe1-ssl.ls.apple.com TCP 200 4624 339 5.051 </span>"</span>23.45.60.145:443</span>" "</span>856</span>" "</span>4624</span>" "</span>0.034</span>"
</span>192.168.233.193 </span>[</span>04/Jun/2023:07:13:38 +0000</span>]</span> gspe1-ssl.ls.apple.com TCP 200 4624 339 5.062 </span>"</span>23.45.60.145:443</span>" "</span>856</span>" "</span>4624</span>" "</span>0.057</span>"
</span>192.168.233.193 </span>[</span>04/Jun/2023:07:13:43 +0000</span>]</span> gspe1-ssl.ls.apple.com TCP 200 4624 339 5.059 </span>"</span>23.45.60.145:443</span>" "</span>856</span>" "</span>4624</span>" "</span>0.053</span>"
</span>192.168.233.193 </span>[</span>04/Jun/2023:07:15:21 +0000</span>]</span> gsp64-ssl.ls.apple.com TCP 200 3851 1424 1.867 </span>"</span>17.36.206.7:443</span>" "</span>1941</span>" "</span>3851</span>" "</span>0.221</span>"
</span>192.168.233.193 </span>[</span>04/Jun/2023:07:16:15 +0000</span>]</span> gspe1-ssl.ls.apple.com TCP 200 4624 339 5.618 </span>"</span>23.34.208.4:443</span>" "</span>856</span>" "</span>4624</span>" "</span>0.197</span>"
</span>192.168.233.193 </span>[</span>04/Jun/2023:07:17:51 +0000</span>]</span> gsp64-ssl.ls.apple.com TCP 200 3853 1114 1.970 </span>"</span>17.36.206.8:443</span>" "</span>1631</span>" "</span>3853</span>" "</span>0.199</span>"
</span></code></pre>

Nginx Memory Management

2020-04-11T00:00:00+00:00

1. Linux 的内存管理</h2>

+---------+  init system   +--------------+  page frame   +------------------+
</span>| Bootmem | -------------> |              | ------------> |                  |
</span>+---------+                |              |               |                  |
</span>                           |              |               |                  |
</span>                           |              |               |       Slab       | -------------------------------------------------------------------------+
</span>                           |              |               |                  |                                                                          |
</span>                           |              |               |                  |                                                                          |
</span>                           |              |               |                  | --------------------------------------------------------------------+    |
</span>                           |              |               +------------------+                                                                     |    |
</span>                           |              |                 |                                                                                      |    |
</span>                           |              |                 | small objects                                                                        |    |
</span>                           |              |                 |                                                                                      |    |
</span>                           | Buddy System |                 |                                        +- - - - - - - - - - - - - - - - - - - - - +  |    |
</span>                           |              |                 |                                        ' userspace:                               '  |    |
</span>                           |              |                 v                                        '                                          '  |    |
</span>                           |              |  page frame   +------------------+  syscall (brk/mmap)   ' +----------+  malloc()   +-------------+ '  |    |
</span>                           |              | ------------> |                  | --------------------> ' |  malloc  | ----------> | application | '  |    |
</span>                           |              |               | Memory Mangement |                       ' +----------+             +-------------+ '  |    |
</span>                           |              |               |                  |                       '                                          '  |    |
</span>                           |              |               +------------------+                       +- - - - - - - - - - - - - - - - - - - - - +  |    |
</span>                           |              |  page frame   +------------------+  small objects                                                      |    |
</span>                           |              | ------------> |  Device Drivers  | <-------------------------------------------------------------------+    |
</span>                           |              |               +------------------+                                                                          |
</span>                           |              |  page frame   +------------------+  small objects                                                           |
</span>                           |              | ------------> |   File System    | <------------------------------------------------------------------------+
</span>                           +--------------+               +------------------+
</span>
</span></code></pre>
在上图里，内核在启动的时候会加载 Bootmem 内存管理系统（这里使用 bitmap 索引内存并分配。然后等初始化到 Buddy System 之后，将未分配的内存全部交给 Buddy System, Buddy System 在 Linux 内核中是做页的分配 (一般来说，页的大小为4k)。再然后到了 Slab 内存管理系统，Slab 主要用于小内存的分配和释放，也就是小于一个页面大小的内存。这里 Slab 对内存的分配和释放起到了 Cache 的作用，在 Linux 内核中地位应该是内存管理模块的老大了。Slab 和 Buddy System 初始化完成之后，内核的内存管理系统基本上已经初始化完成了，这个时候我们其他的内核模块（图中的 Device Drivers 和 File System）申请释放内存就可以直接进行了。要了解更多关于 Slab 和 Buddy System 的信息，可以查看 procfs 中的 /proc/buddyinfo</code> 和 /proc/slabinfo</code>。</p>
在用户态层面，用户态程序在执行 malloc 的函数调用的时候，会直接在 libc 函数库里面的 ptmalloc 里面执行 brk()/mmap() 系统调用进行虚拟内存的分配，这两个系统调用在内核的层面依然是在和 Slab/Buddy System 进行交互，当然，这里只是对虚拟内存的一些结构体进行初始化，并没有真正的分配到内存。其实这里说到的 ptmalloc 在用户态层面也是一种类似于 Slab 的内存分配 Cache 系统（类似 ptmalloc 的用户态 memory allocator 有 mimalloc tcmalloc jemalloc,我们可以视不同的场景而选用这些 malloc 实现）。真正触发物理内存的分配是在用户态程序在获得虚拟内存然后对该内存写之后，触发了缺页中断，这个时候在内核的中断处理过程中就会分配并映射物理内存到虚拟地址上，这个时候也同样是在 Buddy System 当中进行 malloc 页面。</p>
2. Nginx 内存管理源码分析</h2>
1. ngx_alloc.c(h)</h3>
这里主要是 Nginx 的基础内存分配的代码，包装 libc 里面的内存分配函数，至于为什么需要包装呢？这是因为 Nginx 是跨平台的，可不止有 Linux 这一个平台上能跑 Nginx。</p>
在 Linux 环境下手动展开了宏核心代码是这个样子：</p>
void </span>*
</span>ngx_alloc</span>(</span>size_t </span>size</span>, ngx_log_t </span>*</span>log</span>)
</span>{
</span>    </span>void  </span>*</span>p;
</span>
</span>    p </span>= malloc</span>(size);
</span>    </span>if </span>(p </span>== </span>NULL</span>) {
</span>        </span>ngx_log_error</span>(NGX_LOG_EMERG, log, ngx_errno,
</span>                      </span>"</span>malloc(</span>%u</span>z) failed</span>"</span>, size);
</span>    }
</span>
</span>    </span>ngx_log_debug2</span>(NGX_LOG_DEBUG_ALLOC, log, </span>0</span>, </span>"</span>malloc: </span>%p</span>:</span>%u</span>z</span>"</span>, p, size);
</span>
</span>    </span>return</span> p;
</span>}
</span>
</span>
</span>void </span>*
</span>ngx_calloc</span>(</span>size_t </span>size</span>, ngx_log_t </span>*</span>log</span>)
</span>{
</span>    </span>void  </span>*</span>p;
</span>
</span>    p </span>= </span>ngx_alloc</span>(size, log);
</span>
</span>    </span>if </span>(p) {
</span>        </span>ngx_memzero</span>(p, size);
</span>    }
</span>
</span>    </span>return</span> p;
</span>}
</span>
</span>void </span>*
</span>ngx_memalign</span>(</span>size_t </span>alignment</span>, </span>size_t </span>size</span>, ngx_log_t </span>*</span>log</span>)
</span>{
</span>    </span>void  </span>*</span>p;
</span>    </span>int</span>    err;
</span>
</span>    err </span>= </span>posix_memalign</span>(</span>&</span>p, alignment, size);
</span>
</span>    </span>if </span>(err) {
</span>        </span>ngx_log_error</span>(NGX_LOG_EMERG, log, err,
</span>                      </span>"</span>posix_memalign(</span>%u</span>z, </span>%u</span>z) failed</span>"</span>, alignment, size);
</span>        p </span>= </span>NULL</span>;
</span>    }
</span>
</span>    </span>ngx_log_debug3</span>(NGX_LOG_DEBUG_ALLOC, log, </span>0</span>,
</span>                   </span>"</span>posix_memalign: </span>%p</span>:</span>%u</span>z @</span>%u</span>z</span>"</span>, p, size, alignment);
</span>
</span>    </span>return</span> p;
</span>}
</span></code></pre>
我们可以看到 Nginx 的 ngx_alloc() ngx_calloc() ngx_memalign() 三个函数只是对 libc malloc 函数的简单封装，也就是说仍然是在调用这些函数。我认为在这里还是有一个比较粗暴的点，就是在分配 ngx_calloc() 的时候我们是暴力的分配内存然后在将内存初始化为 0, 但是在 libc的实现里面 calloc ！= malloc + memzero</code>,可能在 Nginx 的场景下, 使用这种实现和带 libc 带惰性初始化的实现没什么具体的性能差距。Nginx 的内存分配都是比较小块的，具体的信息可以看 stackoverflow 的这个问题 : 
why-mallocmemset-is-slower-than-calloc</a></p>
2.ngx_shmem.c(h)</h3>
这里主要是 Nginx 底层对共享内存的创建与销毁相关实现。</p>
在 Linux 环境下手动展开了宏核心代码是这个样子：</p>
typedef struct </span>{
</span>    </span>u_char      </span>*</span>addr;
</span>    </span>size_t</span>       size;
</span>    ngx_str_t    name;
</span>    ngx_log_t   </span>*</span>log;
</span>    ngx_uint_t   exists;   </span>/* unsigned  exists:1;  */
</span>} ngx_shm_t;
</span>
</span>ngx_int_t
</span>ngx_shm_alloc</span>(ngx_shm_t </span>*</span>shm</span>)
</span>{
</span>    shm->addr </span>= </span>(</span>u_char </span>*</span>) </span>mmap</span>(</span>NULL</span>, shm->size,
</span>                                PROT_READ</span>|</span>PROT_WRITE,
</span>                                MAP_ANON</span>|</span>MAP_SHARED, </span>-1</span>, </span>0</span>);
</span>
</span>    </span>if </span>(shm->addr </span>==</span> MAP_FAILED) {
</span>        </span>ngx_log_error</span>(NGX_LOG_ALERT, shm->log, ngx_errno,
</span>                      </span>"</span>mmap(MAP_ANON|MAP_SHARED, </span>%u</span>z) failed</span>"</span>, shm->size);
</span>        </span>return</span> NGX_ERROR;
</span>    }
</span>
</span>    </span>return</span> NGX_OK;
</span>}
</span>
</span>
</span>void
</span>ngx_shm_free</span>(ngx_shm_t </span>*</span>shm</span>)
</span>{
</span>    </span>if </span>(</span>munmap</span>((</span>void </span>*</span>) shm->addr, shm->size) </span>== -1</span>) {
</span>        </span>ngx_log_error</span>(NGX_LOG_ALERT, shm->log, ngx_errno,
</span>                      </span>"</span>munmap(</span>%p</span>, </span>%u</span>z) failed</span>"</span>, shm->addr, shm->size);
</span>    }
</span>}
</span></code></pre>
在现代 Linux 环境下默认使用的是 mmap 匿名映射来实现进程间的共享内存，至于为什么没有使用 shm_open 这种方式来实现， 因为 Nginx 是在 master fork to worker 这种形式来进行的，我们不需要在毫无关联的两个进程上进行通信，所以采用 mmap 匿名映射是最直接的方法。当然为了跨平台还有其他的宏定义会采用 /dev/zero</code> 和 System V</code> IPC 的方式，也是很有效的方法。</p>
3.ngx_palloc.c(h)</h3>
接下来就是 Nginx 引以为傲的内存池上场了。Nginx中大多数的内存分配都是在内存池中完成的，在内存池中分配的内存在内存池被销毁时会被自动的释放。这就使得可以获得很高的内存分配性能，并使得内存控制更加简单。</p>
直接看我加了注释的 ngx_palloc.h</code></p>
typedef void </span>(</span>*</span>ngx_pool_cleanup_pt)(</span>void </span>*</span>data);
</span>
</span>typedef struct</span> ngx_pool_cleanup_s  ngx_pool_cleanup_t;
</span>
</span>// 释放内存池拥有的资源，也就是内存池在释放的时候会选择同步释放的资源，一般用于缓存文件的释放
</span>struct </span>ngx_pool_cleanup_s {
</span>    ngx_pool_cleanup_pt   handler;
</span>    </span>void                 </span>*</span>data;
</span>    ngx_pool_cleanup_t   </span>*</span>next;
</span>};
</span>
</span>
</span>typedef struct</span> ngx_pool_large_s  ngx_pool_large_t;
</span>/*
</span> * 内存池中的大内存，ngx_pool_large_s 是一个链表结构，结构本身存储在内存池中，
</span> * 指针指向操作系统 malloc 出来的对应大小内存
</span> */
</span>struct </span>ngx_pool_large_s {
</span>    ngx_pool_large_t     </span>*</span>next;
</span>    </span>void                 </span>*</span>alloc;
</span>};
</span>
</span>// 内存池中的主要结构， ngx_pool_data_t 对应内存池的 Metadata，描述内存池的分配状态信息
</span>typedef struct </span>{
</span>    </span>u_char               </span>*</span>last;
</span>    </span>u_char               </span>*</span>end;
</span>    ngx_pool_t           </span>*</span>next;
</span>    ngx_uint_t            failed;
</span>} ngx_pool_data_t;
</span>
</span>/*
</span> * ngx_pool_s 是我们需要的内存池结构，其中包含了大内存和小内存，以及外挂在内存池生命周期的
</span> * 缓存文件结构
</span> */
</span>struct </span>ngx_pool_s {
</span>    ngx_pool_data_t       d;
</span>    </span>size_t</span>                max;
</span>    ngx_pool_t           </span>*</span>current;
</span>    ngx_chain_t          </span>*</span>chain;
</span>    ngx_pool_large_t     </span>*</span>large;
</span>    ngx_pool_cleanup_t   </span>*</span>cleanup;
</span>    ngx_log_t            </span>*</span>log;
</span>};
</span>
</span>
</span>typedef struct </span>{
</span>    ngx_fd_t              fd;
</span>    </span>u_char               </span>*</span>name;
</span>    ngx_log_t            </span>*</span>log;
</span>} ngx_pool_cleanup_file_t;
</span>
</span>// 创建内存池
</span>ngx_pool_t </span>*</span>ngx_create_pool</span>(</span>size_t </span>size</span>, ngx_log_t </span>*</span>log</span>);
</span>// 销毁内存池，内存池中的大内存和小内存链表都会被释放
</span>void </span>ngx_destroy_pool</span>(ngx_pool_t </span>*</span>pool</span>);
</span>// 重置内存池，将内存池中的数据结构初始化为开始的状态，并释放那些已经分配的大内存
</span>void </span>ngx_reset_pool</span>(ngx_pool_t </span>*</span>pool</span>);
</span>
</span>// 从内存池中分配内存,根据大小来判断分配方式：大内存或者小内存
</span>void </span>*</span>ngx_palloc</span>(ngx_pool_t </span>*</span>pool</span>, </span>size_t </span>size</span>);
</span>// 从内存池中分配内存，且不对其进行内存对齐
</span>void </span>*</span>ngx_pnalloc</span>(ngx_pool_t </span>*</span>pool</span>, </span>size_t </span>size</span>);
</span>// 从内存池中分配内存，并将分配到的内存初始化为0
</span>void </span>*</span>ngx_pcalloc</span>(ngx_pool_t </span>*</span>pool</span>, </span>size_t </span>size</span>);
</span>/*
</span> * 按照 alignment 对齐大小来分配内存，该内存无论大小都会在操作系统中进行 malloc，
</span> * 分配完外挂到大内存链表上 
</span> */
</span>void </span>*</span>ngx_pmemalign</span>(ngx_pool_t </span>*</span>pool</span>, </span>size_t </span>size</span>, </span>size_t </span>alignment</span>);
</span>// 提前释放大块内存
</span>ngx_int_t </span>ngx_pfree</span>(ngx_pool_t </span>*</span>pool</span>, </span>void </span>*</span>p</span>);
</span>
</span>// 随着内存池的释放同步释放资源的操作
</span>ngx_pool_cleanup_t </span>*</span>ngx_pool_cleanup_add</span>(ngx_pool_t </span>*</span>p</span>, </span>size_t </span>size</span>);
</span>void </span>ngx_pool_run_cleanup_file</span>(ngx_pool_t </span>*</span>p</span>, ngx_fd_t </span>fd</span>);
</span>void </span>ngx_pool_cleanup_file</span>(</span>void </span>*</span>data</span>);
</span>void </span>ngx_pool_delete_file</span>(</span>void </span>*</span>data</span>);
</span></code></pre>
直接画出内存池的结构图</p>
+--------------------------------------------------------+---------------------------+
</span>|       ngx_pool_t                                       |        memory block       |
</span>+--------------------+---+-------+-----+-----+-------+-----------------+-------------+
</span>| ngx_pool_data_t *d |   |       |     |     |       |   |             |             |
</span>+--------------------+max|current|chain|large|cleanup|log|     used    |   unused    |
</span>|last|end|next|failed|   |       |     |     |       |   |             |             |
</span>+--+---+---+-------------+---+---+-----+--+--+----+--+---+-------------+-------------+
</span>   |   |   |                 |            |       |                                  ^
</span>   |   |   |                 |            |       |                    ^             |
</span>   |   |   |                 |            |       |                    |             |
</span>   |   +---------------------------------------------------------------+             |
</span>   +---------------------------------------------------------------------------------+
</span>+----------|                 |            |       |
</span>+----------------------------+            |       +---------------------+
</span>v                                         |                             |
</span>+---------------+--------------+          v                             v
</span>|  ngx_pool_t   | memory block |          +----------------+            +----------------------+
</span>+----------+----+--------------+          |ngx_pool_large_t|            |  ngx_pool_cleanup_t  |
</span>           |                              +--------+-------+            +--------+------+------+
</span>+----------+                              | alloc  | next  |            | hander | data | next |
</span>|                                         +--------+---+---+            +--------+------+---+--+
</span>v                                                      |                                    |
</span>+---------------+--------------+          +------------+                +-------------------+
</span>|  ngx_pool_t   | memory block |          |                             |
</span>+---------+-----+--------------+          |                             |
</span>          |                               v                             v
</span>          |                               +----------------+            +----------------------+
</span>          |                               |ngx_pool_large_t|            |  ngx_pool_cleanup_t  |
</span>          v                               +--------+-------+            +--------+------+------+
</span>         NULL                             | alloc  | next  |            | hander | data | next |
</span>                                          +--------+----+--+            +--------+------+---+--+
</span>                                                        |                                   |
</span>                                                        v                                   v
</span>                                                       NULL                                NULL
</span>
</span></code></pre>
结合这个图应该能理解 Nginx 的内存池的设计。区分大小内存块的主要依据是分配内存大小，在内存池分配的函数实现当中，我们定义了一个宏 NGX_MAX_ALLOC_FROM_POOL</code> 来设置内存池的小块内存最大的大小，当然这个大小也由我们分配内存池的size</code>（去除掉ngx_pool_t</code>本身大小）共同决定，在两者中取最小值。若要求分配的内存大于该最小值，则使用大块内存分配，创建大块内存结构，然后使用操作系统的 malloc</code> 进行大块内存分配并将 alloc</code> 指针指向该内存地址。若要求分配的内存小于该内存，且该内存池里面的 unused</code> 内存大小比 size</code> 大，直接在该内存池里分配，并减少 unused</code> 的大小。若要求分配的内存小于该内存，且该内存池里面的 unused</code> 内存大小比 size</code> 小，我们考虑再次开辟一个相同的内存池，并将上一个内存池里面的 next</code> 指针指向该内存池，同时上一个内存池里面的 failed</code> 变量加一，表示内存分配失败一次，然后我们会再第二个开辟的内存池里面分配我们需要的小内存。Nginx</code> 这里还有一个比较粗暴一点的设定，就是在我们同一个内存池中的内存分配失败次数 failed</code> 失败次数超过四次以后，该内存池中的 current</code> 指针会指向下一块内存池子，这个设定是为了减少内存分配寻找的时间成本，当然，这在某种程度上也会造成内存碎片化的问题。在 Nginx 的内存池中，内存池这个概念并不是单单指一个 ngx_pool_t</code> 这个结构，其实上他是指 ngx_pool_t</code> 组成的一个链表，为了组成这个链表，我们在新增链表内的内存池的时候，其实上浪费了新增对象的一个 ngx_pool_t</code> 的空间(后续新增的对象中某些数据结构的成员为NULL</code>)，这个浪费比例于我们内存的大小成反比关系。上面几种情况的取舍问题，其实也是计算机系统在很多设计上的考虑，在很多的子系统、模块当中，对不同的场景就会有不同的最优解。</p>
关于内存池的释放，直接看数据结构图，我们在该内存池的生命周期结束的时候，根据这个类链表结构的设计，我们的 free</code> 就很简单了，其实就是跟着链表的指向一个一个的进行 free</code>, 在ngx_pool_cleanup_t</code> 中，我们同时也可以对内存池上外挂的文件调用设计的 handler</code>进行清理。这样就做到了内存池的统一释放，非常契合 Nginx 的 Web Server 场景。</p>
3.ngx_slab.c(h)</h3>
下面介绍一下 Nginx 中基于 slab</code> 的内存分配机制。slab</code> 主要用在 Linux 内核的内存管理子系统，主要用于小内存的分配。其工作是针对一些经常分配并释放的对象，如进程描述符等，基本上都是 Linux 内核里面的一些数据结构，如果直接采用伙伴系统来进行分配和释放，不仅会造成大量的内存碎片，而且处理速度也太慢。slab主要是以对象为单位来分配内存，简单来说分配这一类的内存，这类内存会组成一个列表，在内存使用完之后也不会释放到 buddy system</code>，依旧是放在列表当中，等待下一次的相同内存分配请求，这样就起到了缓存的效果，直接提升了内存的分配效率，具体的信息可以参考 Linux Procfs</code> 中的 /proc/slabinfo</code> 信息。
许多场景下，不同的Nginx请求间必须交互后才能执行下去，例如限制一个客户端能够并发访问的请求数。可是Nginx被设计为一个多进程的程序，服务更健壮的另一面就是，Nginx请求可能是分布在不同的进程上的，当进程间需要互相配合才能完成请求的处理时，进程间通信开发困难的特点就会凸显出来。Nginx 的 Slab 内存池就是设计出来解决共享内存的分配问题的。这些共享内存区域通常是通过标准 Nginx 配置指令来创建的，比如 ssl_session_cache、proxy_cache_path、limit_req_zone、limit_conn_zone、和 upstream 的 zone 指令。</p>
直接看我加了注释的 ngx_slab.h</code></p>
typedef struct</span> ngx_slab_page_s  ngx_slab_page_t;
</span>
</span>// 页面的描述数据结构
</span>struct </span>ngx_slab_page_s {
</span>    </span>uintptr_t</span>         slab;
</span>    ngx_slab_page_t  </span>*</span>next;
</span>    </span>uintptr_t</span>         prev;
</span>};
</span>
</span>// slab 统计数据结构
</span>typedef struct </span>{
</span>    ngx_uint_t        total;
</span>    ngx_uint_t        used;
</span>
</span>    ngx_uint_t        reqs;
</span>    ngx_uint_t        fails;
</span>} ngx_slab_stat_t;
</span>
</span>// slab 内存池的元数据结构
</span>typedef struct </span>{
</span>    ngx_shmtx_sh_t    lock;
</span>
</span>    </span>size_t</span>            min_size;
</span>    </span>size_t</span>            min_shift;
</span>
</span>    ngx_slab_page_t  </span>*</span>pages;
</span>    ngx_slab_page_t  </span>*</span>last;
</span>    ngx_slab_page_t   free;
</span>
</span>    ngx_slab_stat_t  </span>*</span>stats;
</span>    ngx_uint_t        pfree;
</span>
</span>    </span>u_char           </span>*</span>start;
</span>    </span>u_char           </span>*</span>end;
</span>
</span>    ngx_shmtx_t       mutex;
</span>
</span>    </span>u_char           </span>*</span>log_ctx;
</span>    </span>u_char</span>            zero;
</span>
</span>    </span>unsigned</span>          log_nomem</span>:1</span>;
</span>
</span>    </span>void             </span>*</span>data;
</span>    </span>void             </span>*</span>addr;
</span>} ngx_slab_pool_t;
</span>
</span>// slab 内存池元数据大小的初始化
</span>void </span>ngx_slab_sizes_init</span>(</span>void</span>);
</span>// slab 内存池初始化
</span>void </span>ngx_slab_init</span>(ngx_slab_pool_t </span>*</span>pool</span>);
</span>// 内存分配
</span>void </span>*</span>ngx_slab_alloc</span>(ngx_slab_pool_t </span>*</span>pool</span>, </span>size_t </span>size</span>);
</span>void </span>*</span>ngx_slab_alloc_locked</span>(ngx_slab_pool_t </span>*</span>pool</span>, </span>size_t </span>size</span>);
</span>void </span>*</span>ngx_slab_calloc</span>(ngx_slab_pool_t </span>*</span>pool</span>, </span>size_t </span>size</span>);
</span>void </span>*</span>ngx_slab_calloc_locked</span>(ngx_slab_pool_t </span>*</span>pool</span>, </span>size_t </span>size</span>);
</span>// 内存释放
</span>void </span>ngx_slab_free</span>(ngx_slab_pool_t </span>*</span>pool</span>, </span>void </span>*</span>p</span>);
</span>void </span>ngx_slab_free_locked</span>(ngx_slab_pool_t </span>*</span>pool</span>, </span>void </span>*</span>p</span>);
</span></code></pre>
然后画出数据结构图</p>
+---------------------+--------------------------------------------------------->+------------------+
</span>|                     |         X                                                |    lock          |
</span>|   ngx_slab_pool_t   |                                                          +------------------+
</span>|                     |                                                          |     min_size     |
</span>+---+----------------------------------------------------------------+           +------------------+
</span>|   | ngx_slab_page_t |Min Slab Page                                 |           |    min_shift     |
</span>|   +-----------------+     +                                        |           +------------------+
</span>| s |                 |     |               +------------------------------------+    pages         |
</span>| l |    + + + + +    |     |               |                        |           +------------------+
</span>| o |    | | | | |    |     |to             |        +---------------------------+    last          |
</span>| t |    v v v v v    |     |               |        |               |           +------------------+
</span>| s |                 |     |               |        |               |           |     free         |
</span>|   +-----------------+     v               |        |               |           +------------------+
</span>|   | ngx_slab_page_t |Max Slab Page     +---------------------------------------+     status       |
</span>+---------------------+  <---------------+  |        |               |           +------------------+
</span>|   | ngx_slab_stat_t |Min Slab Page        |        |               |           |     pfree        |
</span>|   +-----------------+     +               |        |               |           +------------------+
</span>| s |                 |     |               |        |  +-------------------------|    start        |
</span>| t |    + + + + +    |     |               |        |  |            |           +------------------+
</span>| a |    | | | | |    |     |to             |        |  |  +---------------------+     end          |
</span>| t |    v v v v v    |     |               |        |  |  |         |           +------------------+
</span>| s |                 |     |               |        |  |  |         |           |     mutex        |
</span>|   +-----------------+     v               |        |  |  |         |           +------------------+
</span>|   | ngx_slab_stat_t |Max Slab Page        |        |  |  |         |           |     log_ctx      |
</span>+---------------------+   <-----------------+        |  |  |         |           +------------------+
</span>|   | ngx_slab_page_t +--+                           |  |  |         |           |     zero         |
</span>|   +-----------------+  |                           |  |  |         |           +------------------+
</span>| p |                 |  |                           |  |  |         |           |     log_nomen    |
</span>| a |    + + + + +    |  |                           |  |  |         |           +------------------+
</span>| g |    | | | | |    |  | pages number slab_page_t  |  |  |         |           |     data         |
</span>| e |    v v v v v    |  |                           |  |  |         |           +------------------+
</span>| s |                 |  |                           |  |  |         |           |     addr         |
</span>|   +-----------------+  |                           |  |  |         +---------->+------------------+
</span>|   | ngx_slab_page_t +--+                           |  |  |
</span>+---+-----------------+    <-------------------------+  |  |
</span>|  alignment memory   |                                 |  |
</span>+------------------------+  <---------------------------+  |
</span>|                     |  |                                 |
</span>|                     |  |                                 |
</span>|                     |  |                                 |
</span>|                     |  |                                 |
</span>|     used memory     |  |                                 |
</span>|                     |  |pages number real page           |
</span>|                     |  |                                 |
</span>|                     |  |                                 |
</span>|                     |  |                                 |
</span>|                     |  |                                 |
</span>|                     |  |                                 |
</span>+------------------------+                                 |
</span>|     unused memory   |                                    |
</span>+---------------------+ <----------------------------------+
</span>
</span></code></pre>
分析一下数据结构吧，这几个主要得结构都是紧紧埃在一起的，主要分为两部分，一部分是元数据区，实际内存分配区域。实际内存分配区域就是途中 used memory</code> 和 unused memory</code>一起的区域，元数据区域有四大块： ngx_slab_pool_t</code> （内存池的结构），ngx_slab_page_t</code> 组成的 slots</code> 区域，该区域主要描述 slab</code> 页面链表的头，大小从 8bit 的 Slab page 到 2048 Bit 的 Slab page, ngx_slab_stat_t</code> 组成的 stat</code> 区域，该区域是上面 Slab page 的统计信息，记录的是 上面 slots</code> 里面的每个 Slab page 分配情况。ngx_slab_page_t</code> 组成的真实内存区域的元信息，意义对应下面 used memory</code> 里面的真实内存页面。
在初始状态，所有的内存都挂在了 ngx_slab_pool_t</code> 下面的 free</code> 下等待进行分配。分配的大致思路就是把每个实际的内存页面都进行对应的 Slab size (也就是 slots的位置对应的位数) 8Bit 16Bit 256Bit..... 这类的内存页面进行切分内存块，然后在 ngx_slab_page_t</code>数据结构中的 slab 成员上建立 bitmap</code> （如果实在放不下去就会到相应的实际内存页的前几个chunk建立bitmap）标记该页面内存的分配情况，同时用链表把对应的内存块连接起来，这样就可以快速的对半满的内存块进行内存分配 。在内存回收的情况下，只用在 bitmap</code> 里面把相应的位置为 0,如果判断这个页面已经全部空闲了就会直接脱离该链表被扔进 free</code> 链表里面。这样就保证了共享内存的高效分配。
在 Slab 共享内存分配中，为了保证高效的内存分配操作，大量使用了位运算的方式极致的压榨性能，同时，和 Linux 内核的 Slab 内存管理不同， ngx_slab</code> 在处理内存分配的时候，分配到了非标准大小内存 (比如 129Bit = 128 Bit + 1Bit) 内存的时候， 会直接分配 256 Bit 的内存页面，这样牺牲了内存空间的效率，换来了时间上的高效利用，同时也尽量的减少了内存的碎片化。
Nginx 的共享内存使用加强版的 Slab allocator (至少从上面的概念中严格定义的 话) 进行管理。它将 slab allocator 和 buddy memory system 里的分级相结合，基本上实现了一个使用自定义内存空间 (Nginx 的共享内存) 的通用内存管理器。</p>
3.  使用 ebpf 对 Nginx 内存管理的分析</h2>
todo</p>
4.  Nginx 内存管理相关的插件</h2>
Tengine 里有两个内存分配信息相关的插件：ngx_debug_pool</code> 和 ngx_slab_stat</code>。</p>
1. ngx_debug_pool</h3>
该模块可以提供 Nginx 内存池占用内存的状态信息。这里 Tengine 对 ngx_palloc.c(h)</code> 进行了 patch, 直接在 ngx_pool_t 里面加上了 stat</code> 成员，然后又设置了一个 ngx_pool_stats</code> 全局变量，这样就可以直接获取 ngx_pool_t</code> 内存池的信息了。
从 Tengine 源码中提取模块，进行编译</p>
./configure --add-module=./modules/ngx_debug_pool
</span>make && make install
</span></code></pre>
添加进 nginx.conf</code> 里</p>
location = /debug_pool {
</span>    debug_pool;
</span>}
</span></code></pre>
然后我们看见效果</p>
$ curl 127.0.0.1/debug_pool
</span>pid:58413
</span>size:        8192 num:           5 cnum:           1 lnum:           0 ngx_http_alloc_request
</span>size:      438830 num:           2 cnum:           1 lnum:          18 ngx_init_cycle
</span>size:           0 num:           1 cnum:           0 lnum:           0 main
</span>size:        1536 num:           5 cnum:           1 lnum:           9 ngx_event_accept
</span>size:       438KB num:          13 cnum:           3 lnum:          27 [SUMMARY]
</span></code></pre>
除了最后一行的每一行的输出内容都有相同的格式，如下：</p>
"__size__: %12u __num__: %12u __cnum__: %12u __lnum__: %12u __\<function name\>__"
</span></code></pre>
size</code>: 当前内存池占用的内存
num</code>: 内存池创建的个数（包括当前正在使用的内存池数量和已经被释放的内存池数量）
cnum</code>: 当前正在使用的内存池数量
lnum</code>: 该类内存池调用ngx_palloc_large()次数
funcion name</code>: 创建该内存池的nginx C函数的函数名</p>
通过创建该内存池的函数的函数名，我们可以知道各个模块的内存使用情况
例如：</p>

ngx_http_create_request</code>创建的内存池用于 HTTP 请求。因为大多数模块直接从该内存池上分配内存，所以很难区分具体哪个模块使用了内存。
ngx_event_accept</code>创建的内存池用于 TCP 连接。
ngx_init_cycle</code>创建的内存池用于解析 Nginx 的配置和保存其他全局数据结构。ngx_http_lua_init_worker</code>用于指令init_worker_by_lua</code>。</p>
</blockquote>
2. ngx_slab_stat</h3>
该模块可以提供 Slab 共享内存的分配信息，其实在 Nginx 官方源码里甚至为了这个需求改进了统计代码，但是统计功能的模块 ngx_http_api_module</a> 只有 Nginx Plus 商业版本才会有。 所以现在采用 Tengine 里面的模块进行统计。
注意： 该模块必须在NGINX版本高于 1.13.x上使用，如果需要在低版本上使用需要另外进行 patch,主要是因为 ngx_slab</code> 在这个版本上有一个关于 ngx_slab_pool_t</code> 中 stat: ngx_slab_stat_t</code> 成员的变更，有了这个成员我们才能快乐的做 slab 内存分配统计。 </p>
./configure --add-module=/path/to/ngx_slab_stat
</span>make && make install
</span></code></pre>
添加进 nginx.conf</code> 里</p>
limit_req_zone $binary_remote_addr zone=ttlsa_com:10m rate=1r/s;
</span>location / {
</span>    root   /usr/share/nginx/html;
</span>    index  index.html index.htm;
</span>    limit_req zone=ttlsa_com burst=5;
</span>}
</span>
</span>location /slab_stat 
</span>{                                    
</span>    slab_stat;                                                             
</span>}
</span></code></pre>
这里我用 limit_req_zone</code> 来创建共享内存，这样好让我们能看到结果</p>
╰─$ curl 127.0.0.1/slab_stat
</span>* shared memory: ttlsa_com
</span>total:       10240(KB) free:       10168(KB) size:           4(KB)
</span>pages:       10168(KB) start:00007F649CFDF000 end:00007F649D9CF000
</span>slot:           8(Bytes) total:           0 used:           0 reqs:           0 fails:           0
</span>slot:          16(Bytes) total:           0 used:           0 reqs:           0 fails:           0
</span>slot:          32(Bytes) total:         127 used:           1 reqs:           1 fails:           0
</span>slot:          64(Bytes) total:           0 used:           0 reqs:           0 fails:           0
</span>slot:         128(Bytes) total:          32 used:           2 reqs:           2 fails:           0
</span>slot:         256(Bytes) total:           0 used:           0 reqs:           0 fails:           0
</span>slot:         512(Bytes) total:           0 used:           0 reqs:           0 fails:           0
</span>slot:        1024(Bytes) total:           0 used:           0 reqs:           0 fails:           0
</span>slot:        2048(Bytes) total:           0 used:           0 reqs:           0 fails:           0
</span></code></pre>
数据非常清晰，我就不需要过多解释了</p>
5.  Nginx 内存管理的优化</h2>
Nginx 在内存管理上的优化和其他的用户态程序一样，在 malloc</code> 的不同实现上的有性能优化的点。这是一个很大的议题了，中文圈里有很多文章让使用 tcmalloc</code> jemalloc</code> mimmalloc</code> 这种来加速内存分配(其实在 Nginx 官方代码里甚至有支持 gperftools</code> 也就是 tcmalloc</code>)，但是就我个人认为，理论上 ptmalloc</code> 是符合 Nginx 内存分配周期短这种场景的，在多线程环境上的优化的优势在 Nginx 也不是很大,更何况 nginx 自己的内存分配器也在一定程度上减小了内存碎片化。可能这个我会设计一个 benchmark</code> 场景来对比各个 malloc</code> 在 Nginx 上的效果 (todolist）。</p>
当然也还有一些内核层面上的优化策略， 比如尽量避免 NUMA 计算机架构体系带来的跨 node 级别内存访问带来的高延迟，稳妥的建议是避免使用 NUMA 多 node 架构的服务器，当然，你自己去优化用户态的内存分配也是可以的。 还有一个就是 Linux 内核的透明大页的特性, 可以针对 Nginx 的使用场景，将 transparent_hugepage</code> 的选项调为 madvise</code> ，根据内存分配的建议来对已分配内存进行透明大页转换。</p>
参考链接</h3>

core/ngx_slab.c源文件分析</a></li>
深入理解Nginx（第2版）</a></li>
20 years of Linux Virtual Memory</a></li>
Optimizing web servers for high throughput and low latency</a></li>
</ol>

4. Nginx 内存管理相关的插件</h2>
Tengine 里有两个内存分配信息相关的插件：`ngx_debug_pool</code> 和 ngx_slab_stat</code>。</p>`

`参考链接</h3>core/ngx_slab.c源文件分析</a></li> 深入理解Nginx（第2版）</a></li> 20 years of Linux Virtual Memory</a></li> Optimizing web servers for high throughput and low latency</a></li> </ol>`

owl's Blog

如何在透明代理网络环境下得到正常的苹果地图

Nginx Network IO Module

Nginx Memory Management

Hello world

owl's Blog

如何在透明代理网络环境下得到正常的苹果地图

解决方案</h1> 于是乎问题就变成了， 需要在我家的环境下，让访问苹果 *.ls.apple.com</code> 域名的所有请求（包含 DNS 解析）不走任何的代理，咨询了一下朋友们，大致有以下几个方案</p>

Nginx Network IO Module

Nginx Memory Management

4. Nginx 内存管理相关的插件</h2> Tengine 里有两个内存分配信息相关的插件：ngx_debug_pool</code> 和 ngx_slab_stat</code>。</p>

参考链接</h3> core/ngx_slab.c源文件分析</a></li> 深入理解Nginx（第2版）</a></li> 20 years of Linux Virtual Memory</a></li> Optimizing web servers for high throughput and low latency</a></li> </ol>

Hello world

4. Nginx 内存管理相关的插件</h2>
Tengine 里有两个内存分配信息相关的插件：`ngx_debug_pool</code> 和 ngx_slab_stat</code>。</p>`

`参考链接</h3>core/ngx_slab.c源文件分析</a></li> 深入理解Nginx（第2版）</a></li> 20 years of Linux Virtual Memory</a></li> Optimizing web servers for high throughput and low latency</a></li> </ol>`