服務器與app安全通信 服務器和app

什么是簽名？服務器和APP之間的API接口和數(shù)據(jù)怎么保證安全

apk簽名相當于程序的身份識別代碼。

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、微信小程序定制開發(fā)、集團企業(yè)網(wǎng)站建設(shè)等服務項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了深圳免費建站歡迎大家使用！

apk簽名用于程序編譯打包之后，手機在運行程序之前會先去驗證程序的簽名（可以看作類似于我們電腦上常說的md5）是否合法，只有通過了驗證的文件才會被運行，所以簽名軟件的作用的讓文件通過手機的驗證為合法，不同的手機、系統(tǒng)是對應不同的簽名的。

進行加密通訊防止API外部調(diào)用

服務器端與客戶端各自會存儲一個TOKEN,這個TOKEN我們?yōu)榱朔乐狗淳幾g是用C語言來寫的一個文件并做了加殼和混淆處理。

在客戶端訪問服務器API任何一個接口的時候，客戶端需要帶上一個特殊字段，這個字段就是簽名signature，簽名的生成方式為：

訪問的接口名+時間戳+加密TOKEN 進行整體MD5,并且客戶端將本地的時間戳作為明文參數(shù)提交到服務器

服務器首先會驗證這兩個參數(shù)：驗證時間戳，如果時間誤差與服務器超過正負一分鐘，服務器會拒絕訪問(防止被抓包重復請求服務器，正負一分鐘是防止時間誤差，參數(shù)可調(diào)整)，

然后服務器會根據(jù)請求的API地址和提交過來的時間戳再加上本地存儲的token按照MD5重新生成一個簽名，并比對簽名，簽名一致才會通過服務器的驗證，進入到下一步的API邏輯

怎么保證APP和服務器端通信的安全性

用HTTPS通信，另外APP往服務器接口發(fā)送的參數(shù)帶token，還要加上簽名，服務器端驗簽名（以防參數(shù)被篡改），校驗token；同時加上時間戳，防止重放。（簽名算法、密鑰的分配安全存儲要設(shè)計好）

對服務器接口要有監(jiān)控，監(jiān)控到異常情況要有處理方案。

redis怎么解決app與服務器通信

簡介

幾乎所有的主流編程語言都有Redis的客戶端，不考慮Redis非常流行的原因，如果站在技術(shù)的角度看原因還有兩個：

客戶端與服務端之間的通信協(xié)議是在?TCP 協(xié)議之上構(gòu)建的。

客戶端和服務器通過 TCP 連接來進行數(shù)據(jù)交互， 服務器默認的端口號為 6379 。

客戶端和服務器發(fā)送的命令或數(shù)據(jù)一律以 \r\n （CRLF）結(jié)尾。

Redis制定了 RESP（REdis Serialization Protocol，Redis序列化協(xié)議）實現(xiàn)客戶端與服務端的正常交互，這種協(xié)議簡單高效，既能夠被機器解析，又容易被人類識別。

發(fā)送命令

RESP 在 Redis 1.2 版本中引入， 并最終在 Redis 2.0 版本成為 Redis 服務器通信的標準方式。

在這個協(xié)議中， 所有發(fā)送至 Redis 服務器的參數(shù)都是二進制安全（binary safe）的。

RESP 的規(guī)定一條命令的格式如下：

*參數(shù)數(shù)量 CR LF

$參數(shù) 1 的字節(jié)數(shù)量 CR LF

參數(shù) 1 的數(shù)據(jù) CR LF

...

$參數(shù) N 的字節(jié)數(shù)量 CR LF

參數(shù) N 的數(shù)據(jù) CR LF

命令本身也作為協(xié)議的其中一個參數(shù)來發(fā)送。

例如我們經(jīng)常執(zhí)行的 SET 命令，在命令行中我們輸入如下：

SET key value

使用 RESP 協(xié)議規(guī)定的格式：

*3

$3

SET

$3 # 這里 key 一共三個字節(jié)

key

$5 # 這里 value 一共五個字節(jié)

value

這個命令的實際協(xié)議值如下：

"*3\r\n$3\r\nSET\r\n$3\r\nkey\r\n$5\r\nvalue\r\n"

回復

Redis 命令會返回多種不同類型的回復。

通過檢查服務器發(fā)回數(shù)據(jù)的第一個字節(jié)， 可以確定這個回復是什么類型：

狀態(tài)回復（status reply）的第一個字節(jié)是 "+"

錯誤回復（error reply）的第一個字節(jié)是 "-"

整數(shù)回復（integer reply）的第一個字節(jié)是 ":"

批量回復（bulk reply）的第一個字節(jié)是 "$"

多條批量回復（multi bulk reply）的第一個字節(jié)是 "*"

我們知道redis-cli只能看到最終的執(zhí)行結(jié)果，那是因為redis-cli本身就按照RESP進行結(jié)果解析的，所以看不到中間結(jié)果，redis-cli.c 源碼對命令結(jié)果的解析結(jié)構(gòu)如下：

static sds cliFormatReplyTTY(redisReply *r, char *prefix) {

sds out = sdsempty();

switch (r-type) {

? ? ? ? ? // 處理錯誤回復

case REDIS_REPLY_ERROR:

out = sdscatprintf(out,"(error) %s\n", r-str);

break;

// 處理狀態(tài)回復

case REDIS_REPLY_STATUS:

out = sdscat(out,r-str);

out = sdscat(out,"\n");

break;

// 處理整數(shù)回復

case REDIS_REPLY_INTEGER:

out = sdscatprintf(out,"(integer) %lld\n",r-integer);

break;

// 處理字符串回復

case REDIS_REPLY_STRING:

/* If you are producing output for the standard output we want

* a more interesting output with quoted characters and so forth */

out = sdscatrepr(out,r-str,r-len);

out = sdscat(out,"\n");

break;

// 處理 nil

case REDIS_REPLY_NIL:

out = sdscat(out,"(nil)\n");

break;

// 處理多回復

case REDIS_REPLY_ARRAY:

if (r-elements == 0) {

out = sdscat(out,"(empty list or set)\n");

} else {

unsigned int i, idxlen = 0;

char _prefixlen[16];

char _prefixfmt[16];

sds _prefix;

sds tmp;

/* Calculate chars needed to represent the largest index */

i = r-elements;

do {

idxlen++;

i /= 10;

} while(i);

/* Prefix for nested multi bulks should grow with idxlen+2 spaces */

memset(_prefixlen,' ',idxlen+2);

_prefixlen[idxlen+2] = '\0';

_prefix = sdscat(sdsnew(prefix),_prefixlen);

/* Setup prefix format for every entry */

snprintf(_prefixfmt,sizeof(_prefixfmt),"%%s%%%ud) ",idxlen);

for (i = 0; i r-elements; i++) {

/* Don't use the prefix for the first element, as the parent

* caller already prepended the index number. */

out = sdscatprintf(out,_prefixfmt,i == 0 ? "" : prefix,i+1);

/* Format the multi bulk entry */

? ? ? ? ? ? ? ? ? tmp = cliFormatReplyTTY(r-element[i],_prefix);

out = sdscatlen(out,tmp,sdslen(tmp));

sdsfree(tmp);

}

sdsfree(_prefix);

}

break;

default:

fprintf(stderr,"Unknown reply type: %d\n", r-type);

exit(1);

}

return out;

}

在 發(fā)送命令 一節(jié)中使用的格式除了用作命令請求協(xié)議之外， 也用在命令的回復協(xié)議中： 這種只有一個參數(shù)的回復格式被稱為批量回復（Bulk Reply）。

統(tǒng)一協(xié)議請求原本是用在回復協(xié)議中， 用于將列表的多個項返回給客戶端的， 這種回復格式被稱為多條批量回復（Multi Bulk Reply）。

一個多條批量回復以 *argc\r\n 為前綴， 后跟多條不同的批量回復， 其中 argc 為這些批量回復的數(shù)量。

狀態(tài)回復

一個狀態(tài)回復（或者單行回復，single line reply）是一段以 "+" 開始、 "\r\n" 結(jié)尾的單行字符串。

以下是一個狀態(tài)回復的例子：

+OK

客戶端庫應該返回 "+" 號之后的所有內(nèi)容。 比如在在上面的這個例子中， 客戶端就應該返回字符串 "OK" 。

狀態(tài)回復通常由那些不需要返回數(shù)據(jù)的命令返回，這種回復不是二進制安全的，它也不能包含新行。

狀態(tài)回復的額外開銷非常少，只需要三個字節(jié)（開頭的 "+" 和結(jié)尾的 CRLF）。

錯誤回復

錯誤回復和狀態(tài)回復非常相似， 它們之間的唯一區(qū)別是， 錯誤回復的第一個字節(jié)是 "-" ， 而狀態(tài)回復的第一個字節(jié)是 "+" 。

錯誤回復只在某些地方出現(xiàn)問題時發(fā)送： 比如說， 當用戶對不正確的數(shù)據(jù)類型執(zhí)行命令， 或者執(zhí)行一個不存在的命令， 等等。

一個客戶端庫應該在收到錯誤回復時產(chǎn)生一個異常。

以下是兩個錯誤回復的例子：

-ERR unknown command 'foobar'

? ? ? ? ? ? ? ? ?-WRONGTYPE Operation against a key holding the wrong kind of value

在 "-" 之后，直到遇到第一個空格或新行為止，這中間的內(nèi)容表示所返回錯誤的類型。

ERR 是一個通用錯誤，而 WRONGTYPE 則是一個更特定的錯誤。 一個客戶端實現(xiàn)可以為不同類型的錯誤產(chǎn)生不同類型的異常， 或者提供一種通用的方式， 讓調(diào)用者可以通過提供字符串形式的錯誤名來捕捉（trap）不同的錯誤。

不過這些特性用得并不多， 所以并不是特別重要， 一個受限的（limited）客戶端可以通過簡單地返回一個邏輯假（false）來表示一個通用的錯誤條件。

整數(shù)回復

整數(shù)回復就是一個以 ":" 開頭， CRLF 結(jié)尾的字符串表示的整數(shù)。

比如說， ":0\r\n" 和 ":1000\r\n" 都是整數(shù)回復。

返回整數(shù)回復的其中兩個命令是 INCR 和 LASTSAVE 。 被返回的整數(shù)沒有什么特殊的含義， INCR 返回鍵的一個自增后的整數(shù)值， 而 LASTSAVE 則返回一個 UNIX 時間戳， 返回值的唯一限制是這些數(shù)必須能夠用 64 位有符號整數(shù)表示。

整數(shù)回復也被廣泛地用于表示邏輯真和邏輯假： 比如 EXISTS 和 SISMEMBER 都用返回值 1 表示真， 0 表示假。

其他一些命令， 比如 SADD 、 SREM 和 SETNX ， 只在操作真正被執(zhí)行了的時候， 才返回 1 ， 否則返回 0 。

以下命令都返回整數(shù)回復： SETNX 、 DEL 、 EXISTS 、 INCR 、 INCRBY 、 DECR 、 DECRBY 、 DBSIZE 、 LASTSAVE 、RENAMENX 、 MOVE 、 LLEN 、 SADD 、 SREM 、 SISMEMBER 、 SCARD 。

批量回復

服務器使用批量回復來返回二進制安全的字符串，字符串的最大長度為 512 MB 。

客戶端：GET mykey

服務器：foobar

服務器發(fā)送的內(nèi)容中：

第一字節(jié)為 "$" 符號

?- 接下來跟著的是表示實際回復長度的數(shù)字值

- 之后跟著一個 CRLF

- 再后面跟著的是實際回復數(shù)據(jù)

- 最末尾是另一個 CRLF

對于前面的 GET 命令，服務器實際發(fā)送的內(nèi)容為：

"$6\r\nfoobar\r\n"

如果被請求的值不存在， 那么批量回復會將特殊值 -1 用作回復的長度值， 就像這樣：

客戶端：GET non-existing-key

服務器：$-1

這種回復稱為空批量回復（NULL Bulk Reply）。

當請求對象不存在時，客戶端應該返回空對象，而不是空字符串： 比如 Ruby 庫應該返回 nil ， 而 C 庫應該返回NULL （或者在回復對象中設(shè)置一個特殊標志）， 諸如此類。

多條批量回復

像 LRANGE 這樣的命令需要返回多個值， 這一目標可以通過多條批量回復來完成。

多條批量回復是由多個回復組成的數(shù)組， 數(shù)組中的每個元素都可以是任意類型的回復， 包括多條批量回復本身。

多條批量回復的第一個字節(jié)為 "*" ， 后跟一個字符串表示的整數(shù)值， 這個值記錄了多條批量回復所包含的回復數(shù)量， 再后面是一個 CRLF 。

客戶端： LRANGE mylist 0 3

服務器： *4

服務器： $3

服務器： foo

服務器： $3

服務器： bar

服務器： $5

服務器： Hello

服務器： $5

服務器： World

在上面的示例中，服務器發(fā)送的所有字符串都由 CRLF 結(jié)尾。

正如你所見到的那樣， 多條批量回復所使用的格式， 和客戶端發(fā)送命令時使用的統(tǒng)一請求協(xié)議的格式一模一樣。 它們之間的唯一區(qū)別是：

統(tǒng)一請求協(xié)議只發(fā)送批量回復。

而服務器應答命令時所發(fā)送的多條批量回復，則可以包含任意類型的回復。

以下例子展示了一個多條批量回復， 回復中包含四個整數(shù)值， 以及一個二進制安全字符串：

*5\r\n

:1\r\n

:2\r\n

:3\r\n

:4\r\n

$6\r\n

foobar\r\n

在回復的第一行， 服務器發(fā)送 *5\r\n ， 表示這個多條批量回復包含 5 條回復， 再后面跟著的則是 5 條回復的正文。

多條批量回復也可以是空白的（empty）， 就像這樣：

客戶端： LRANGE nokey 0 1

服務器： *0\r\n

無內(nèi)容的多條批量回復（null multi bulk reply）也是存在的， 比如當 BLPOP 命令的阻塞時間超過最大時限時， 它就返回一個無內(nèi)容的多條批量回復， 這個回復的計數(shù)值為 -1 ：

客戶端： BLPOP key 1

服務器： *-1\r\n

客戶端庫應該區(qū)別對待空白多條回復和無內(nèi)容多條回復： 當 Redis 返回一個無內(nèi)容多條回復時， 客戶端庫應該返回一個 null 對象， 而不是一個空數(shù)組。

多條批量回復中的空元素

多條批量回復中的元素可以將自身的長度設(shè)置為 -1 ， 從而表示該元素不存在， 并且也不是一個空白字符串（empty string）。

當 SORT 命令使用 GET pattern 選項對一個不存在的鍵進行操作時， 就會發(fā)生多條批量回復中帶有空白元素的情況。

以下例子展示了一個包含空元素的多重批量回復：

服務器： *3

服務器： $3

服務器： foo

服務器： $-1

服務器： $3

服務器： bar

其中， 回復中的第二個元素為空。

對于這個回復， 客戶端庫應該返回類似于這樣的回復：

["foo", nil, "bar"]

網(wǎng)站題目：服務器與app安全通信 服務器和app
文章轉(zhuǎn)載：http://muchs.cn/article6/ddihdog.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設(shè)、搜索引擎優(yōu)化、營銷型網(wǎng)站建設(shè)、微信公眾號、網(wǎng)站內(nèi)鏈、ChatGPT

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)