Redis客戶端與服務端通信協議
來源:懂視網
責編:小采
時間:2020-11-09 15:46:14
Redis客戶端與服務端通信協議
Redis客戶端與服務端通信協議:背景 在跟蹤REDIS服務端處理命令流程的時候,發現在服務端processInputBuffer里收到的字符串并非是在客戶端輸入的,而是進行了某種編碼。比如,客戶端輸入get a,實際服務端打印出來的是 buf= *2$3get$1a 最開始認為是在服務端某段代碼對客戶端送過來的字符
導讀Redis客戶端與服務端通信協議:背景 在跟蹤REDIS服務端處理命令流程的時候,發現在服務端processInputBuffer里收到的字符串并非是在客戶端輸入的,而是進行了某種編碼。比如,客戶端輸入get a,實際服務端打印出來的是 buf= *2$3get$1a 最開始認為是在服務端某段代碼對客戶端送過來的字符

背景 在跟蹤REDIS服務端處理命令流程的時候,發現在服務端processInputBuffer里收到的字符串并非是在客戶端輸入的,而是進行了某種編碼。比如,客戶端輸入get a,實際服務端打印出來的是 buf= *2$3get$1a 最開始認為是在服務端某段代碼對客戶端送過來的字符
背景
在跟蹤REDIS服務端處理命令流程的時候,發現在服務端processInputBuffer里收到的字符串并非是在客戶端輸入的,而是進行了某種編碼。比如,客戶端輸入get a,實際服務端打印出來的是
最開始認為是在服務端某段代碼對客戶端送過來的字符串進行處理,可能是出于某些考慮,后來發現從SOCKET讀取過來就已經轉換過了,所以就應該是客戶端和服務端的通信協議,我對這個就開始產生了很濃厚的興趣,*和$符號必定是有特殊意義的。
客戶端處理流程
在main函數啟動后,與服務端進行連接調用repl()函數,在該函數初始化和調用命令行的歷史記錄(允許你上下翻動歷史)。最后進入cliSendCommand函數處理命令,對于需要發送到服務端的命令調用redisAppendCommandArgv的流程。
為了分析里面的通信協議,對redisAppendCommandArgv函數的黑盒測試,得出以下規律。
客戶輸入內容 |
處理結果 |
a |
*1
$1
a |
ab |
*1
$2
ab |
a b |
*2
$1
a
$1
b |
get a b |
*3
$3
get
$1
a
$1
b |
get a ab |
*3
$3
get
$1
a
$2
ab |
可以得出規律,是將argc argv在具體化,第一個參數,也就是*開始相當于argc, 表示后續有幾個對象,$后面的數字表示緊跟后面的字符串有幾個字節。如get a ab,一共3個,分別是get ,a,b。 $3表示后面的get是3個字節。
官方文檔
之前都是自己根據代碼的跟蹤猜的,更詳細的更專業的回答在這里。
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com
Redis客戶端與服務端通信協議
Redis客戶端與服務端通信協議:背景 在跟蹤REDIS服務端處理命令流程的時候,發現在服務端processInputBuffer里收到的字符串并非是在客戶端輸入的,而是進行了某種編碼。比如,客戶端輸入get a,實際服務端打印出來的是 buf= *2$3get$1a 最開始認為是在服務端某段代碼對客戶端送過來的字符