nginx為了處理帶有通配符的域名的匹配問題,實現了ngx_hash_wildcard_t這樣的hash表。他可以支持兩種類型的帶有通配符的域名。一種是通配符在前的,例如:“*.abc.com”,也可以省略掉星號,直接寫成”.abc.com”。這樣的key,可以匹配www.abc.com,qqq.www.abc.com之類的。另外一種是通配符在末尾的,例如:“mail.xxx.*”,請特別注意通配符在末尾的不像位于開始的通配符可以被省略掉。這樣的通配符,可以匹配mail.xxx.com、mail.xxx.com.cn、mail.xxx.net之類的域名。
有一點必須說明,就是一個ngx_hash_wildcard_t類型的hash表只能包含通配符在前的key或者是通配符在后的key。不能同時包含兩種類型的通配符的key。ngx_hash_wildcard_t類型變量的構建是通過函數ngx_hash_wildcard_init完成的,而查詢是通過函數ngx_hash_find_wc_head或者ngx_hash_find_wc_tail來做的。ngx_hash_find_wc_head是查詢包含通配符在前的key的hash表的,而ngx_hash_find_wc_tail是查詢包含通配符在后的key的hash表的。
下面詳細說明這幾個函數的用法。
[](http:// "點擊提交Issue,反饋你的意見...")
ngx_int_t ngx_hash_wildcard_init(ngx_hash_init_t *hinit, ngx_hash_key_t *names,
ngx_uint_t nelts);
該函數迎來構建一個可以包含通配符key的hash表。
| hinit: | 構造一個通配符hash表的一些參數的一個集合。關于該參數對應的類型的說明,請參見ngx_hash_t類型中ngx_hash_init函數的說明。 |
|-----|-----|
| names: | 構造此hash表的所有的通配符key的數組。特別要注意的是這里的key已經都是被預處理過的。例如:“*.abc.com”或者“.abc.com”被預處理完成以后,變成了“com.abc.”。而“mail.xxx.*”則被預處理為“mail.xxx.”。為什么會被處理這樣?這里不得不簡單地描述一下通配符hash表的實現原理。當構造此類型的hash表的時候,實際上是構造了一個hash表的一個“鏈表”,是通過hash表中的key“鏈接”起來的。比如:對于“*.abc.com”將會構造出2個hash表,第一個hash表中有一個key為com的表項,該表項的value包含有指向第二個hash表的指針,而第二個hash表中有一個表項abc,該表項的value包含有指向*.abc.com對應的value的指針。那么查詢的時候,比如查詢www.abc.com的時候,先查com,通過查com可以找到第二級的hash表,在第二級hash表中,再查找abc,依次類推,直到在某一級的hash表中查到的表項對應的value對應一個真正的值而非一個指向下一級hash表的指針的時候,查詢過程結束。**這里有一點需要特別注意的,就是names數組中元素的value值低兩位bit必須為0(有特殊用途)。如果不滿足這個條件,這個hash表查詢不出正確結果。** |
| nelts: | names數組元素的個數。 |
該函數執行成功返回NGX_OK,否則NGX_ERROR。
[](http:// "點擊提交Issue,反饋你的意見...")
void *ngx_hash_find_wc_head(ngx_hash_wildcard_t *hwc, u_char *name, size_t len);
該函數查詢包含通配符在前的key的hash表的。
| hwc: | hash表對象的指針。 |
|-----|-----|
| name: | 需要查詢的域名,例如: www.abc.com。 |
| len: | name的長度。 |
該函數返回匹配的通配符對應value。如果沒有查到,返回NULL。
[](http:// "點擊提交Issue,反饋你的意見...")
void *ngx_hash_find_wc_tail(ngx_hash_wildcard_t *hwc, u_char *name, size_t len);
該函數查詢包含通配符在末尾的key的hash表的。 參數及返回值請參加上個函數的說明。
- 上篇:nginx模塊開發篇
- nginx平臺初探
- 初探nginx架構
- nginx基礎概念
- connection
- request
- keepalive
- pipe
- lingering_close
- 基本數據結構
- ngx_str_t
- ngx_pool_t
- ngx_array_t
- ngx_hash_t
- ngx_hash_wildcard_t
- ngx_hash_combined_t
- ngx_hash_keys_arrays_t
- ngx_chain_t
- ngx_buf_t
- ngx_list_t
- ngx_queue_t
- nginx的配置系統
- 指令參數
- 指令上下文
- nginx的模塊化體系結構
- 模塊的分類
- nginx的請求處理
- handler模塊
- handler模塊簡介
- 模塊的基本結構
- 模塊配置結構
- 模塊配置指令
- 模塊上下文結構
- 模塊的定義
- handler模塊的基本結構
- handler模塊的掛載
- handler的編寫步驟
- 示例: hello handler 模塊
- handler模塊的編譯和使用
- 更多handler模塊示例分析
- http access module
- http static module
- http log module
- 過濾模塊
- 過濾模塊簡介
- 過濾模塊的分析
- upstream模塊
- upstream模塊
- upstream模塊接口
- memcached模塊分析
- 本節回顧
- 負載均衡模塊
- 配置
- 指令
- 鉤子
- 初始化配置
- 初始化請求
- peer.get和peer.free回調函數
- 本節回顧
- 其他模塊
- core模塊
- event模塊
- 模塊開發高級篇
- 變量
- 下篇:nginx原理解析篇
- nginx架構詳解
- nginx的源碼目錄結構
- nginx的configure原理
- 模塊編譯順序
- nginx基礎設施
- 內存池
- nginx的啟動階段
- 概述
- 共有流程
- 配置解析
- nginx的請求處理階段
- 接收請求流程
- http請求格式簡介
- 請求頭讀取
- 解析請求行
- 解析請求頭
- 請求體讀取
- 讀取請求體
- 丟棄請求體
- 多階段處理請求
- 多階段執行鏈
- POST_READ階段
- SERVER_REWRITE階段
- FIND_CONFIG階段
- REWRITE階段
- POST_REWRITE階段
- PREACCESS階段
- ACCESS階段
- POST_ACCESS階段
- TRY_FILES階段
- CONTENT階段
- LOG階段
- Nginx filter
- header filter分析
- body filter分析
- ngx_http_copy_filter_module分析
- ngx_http_write_filter_module分析
- subrequest原理解析
- https請求處理解析
- 附錄A 編碼風格
- 附錄B 常用API
- 附錄C 模塊編譯,調試與測試