建站
咨詢
售后
建站咨詢
新聞中心
怎么保證APP和服務(wù)器端通信的安全性
用HTTPS通信，另外APP往服務(wù)器接口發(fā)送的參數(shù)帶token，還要加上簽名，服務(wù)器端驗簽名（以防參數(shù)被篡改），校驗token；同時加上時間戳，防止重放。（簽名算法、密鑰的分配安全存儲要設(shè)計好）
成都創(chuàng)新互聯(lián)是少有的成都網(wǎng)站制作、網(wǎng)站建設(shè)、營銷型企業(yè)網(wǎng)站、微信小程序、手機APP,開發(fā)、制作、設(shè)計、買鏈接、推廣優(yōu)化一站式服務(wù)網(wǎng)絡(luò)公司,自2013年創(chuàng)立以來,堅持透明化,價格低,無套路經(jīng)營理念。讓網(wǎng)頁驚喜每一位訪客多年來深受用戶好評
對服務(wù)器接口要有監(jiān)控，監(jiān)控到異常情況要有處理方案。
app與服務(wù)器交互端口怎么防護？如果端口被人獲取如何防止被大量非法獲取數(shù)據(jù)
做個攔截器 把沒登錄的攔截了
或者后臺生成token app端每次憑token訪問
手機軟件登錄顯示安全交互失敗
手機軟件登錄顯示安全交互失敗可能是以下原因：
1、時間不同步導(dǎo)致的，解決方法：如果手機時間和系統(tǒng)時間不同步有可能會導(dǎo)致SSL證書錯誤，這時我們可以重新設(shè)置下手機時間，以同步系統(tǒng)時間，然后再訪問看是否可以建立與服務(wù)器安全連接。
2、手機wifi連接設(shè)置了代理，解決方法：手機wifi連接如果設(shè)置了代理功能，有時會出現(xiàn)無法連接上瀏覽器。我們可以先在wifi設(shè)置里檢查下，如果設(shè)置了代理功能，則點擊關(guān)閉即可。
3、手機app長時間沒升級更新，解決方法：通常手機app會不定期進行更新，以及時修復(fù)安全漏洞等。當(dāng)app長時間沒有升級更新，很可能會出現(xiàn)SSL錯誤無法建立與該服務(wù)器安全連接，遇到這種情況，我們將app升級至最新版本就可以了。
redis怎么解決app與服務(wù)器通信
簡介
幾乎所有的主流編程語言都有Redis的客戶端，不考慮Redis非常流行的原因，如果站在技術(shù)的角度看原因還有兩個：
客戶端與服務(wù)端之間的通信協(xié)議是在?TCP 協(xié)議之上構(gòu)建的。
客戶端和服務(wù)器通過 TCP 連接來進行數(shù)據(jù)交互， 服務(wù)器默認(rèn)的端口號為 6379 。
客戶端和服務(wù)器發(fā)送的命令或數(shù)據(jù)一律以 \r\n （CRLF）結(jié)尾。
Redis制定了 RESP（REdis Serialization Protocol，Redis序列化協(xié)議）實現(xiàn)客戶端與服務(wù)端的正常交互，這種協(xié)議簡單高效，既能夠被機器解析，又容易被人類識別。
發(fā)送命令
RESP 在 Redis 1.2 版本中引入， 并最終在 Redis 2.0 版本成為 Redis 服務(wù)器通信的標(biāo)準(zhǔn)方式。
在這個協(xié)議中， 所有發(fā)送至 Redis 服務(wù)器的參數(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"
回復(fù)
Redis 命令會返回多種不同類型的回復(fù)。
通過檢查服務(wù)器發(fā)回數(shù)據(jù)的第一個字節(jié)， 可以確定這個回復(fù)是什么類型：
狀態(tài)回復(fù)（status reply）的第一個字節(jié)是 "+"
錯誤回復(fù)（error reply）的第一個字節(jié)是 "-"
整數(shù)回復(fù)（integer reply）的第一個字節(jié)是 ":"
批量回復(fù)（bulk reply）的第一個字節(jié)是 "$"
多條批量回復(fù)（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) {
? ? ? ? ? // 處理錯誤回復(fù)
case REDIS_REPLY_ERROR:
out = sdscatprintf(out,"(error) %s\n", r-str);
break;
// 處理狀態(tài)回復(fù)
case REDIS_REPLY_STATUS:
out = sdscat(out,r-str);
out = sdscat(out,"\n");
break;
// 處理整數(shù)回復(fù)
case REDIS_REPLY_INTEGER:
out = sdscatprintf(out,"(integer) %lld\n",r-integer);
break;
// 處理字符串回復(fù)
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;
// 處理多回復(fù)
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é)議之外， 也用在命令的回復(fù)協(xié)議中： 這種只有一個參數(shù)的回復(fù)格式被稱為批量回復(fù)（Bulk Reply）。
統(tǒng)一協(xié)議請求原本是用在回復(fù)協(xié)議中， 用于將列表的多個項返回給客戶端的， 這種回復(fù)格式被稱為多條批量回復(fù)（Multi Bulk Reply）。
一個多條批量回復(fù)以 *argc\r\n 為前綴， 后跟多條不同的批量回復(fù)， 其中 argc 為這些批量回復(fù)的數(shù)量。
狀態(tài)回復(fù)
一個狀態(tài)回復(fù)（或者單行回復(fù)，single line reply）是一段以 "+" 開始、 "\r\n" 結(jié)尾的單行字符串。
以下是一個狀態(tài)回復(fù)的例子：
+OK
客戶端庫應(yīng)該返回 "+" 號之后的所有內(nèi)容。 比如在在上面的這個例子中， 客戶端就應(yīng)該返回字符串 "OK" 。
狀態(tài)回復(fù)通常由那些不需要返回數(shù)據(jù)的命令返回，這種回復(fù)不是二進制安全的，它也不能包含新行。
狀態(tài)回復(fù)的額外開銷非常少，只需要三個字節(jié)（開頭的 "+" 和結(jié)尾的 CRLF）。
錯誤回復(fù)
錯誤回復(fù)和狀態(tài)回復(fù)非常相似， 它們之間的唯一區(qū)別是， 錯誤回復(fù)的第一個字節(jié)是 "-" ， 而狀態(tài)回復(fù)的第一個字節(jié)是 "+" 。
錯誤回復(fù)只在某些地方出現(xiàn)問題時發(fā)送： 比如說， 當(dāng)用戶對不正確的數(shù)據(jù)類型執(zhí)行命令， 或者執(zhí)行一個不存在的命令， 等等。
一個客戶端庫應(yīng)該在收到錯誤回復(fù)時產(chǎn)生一個異常。
以下是兩個錯誤回復(fù)的例子：
-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ù)回復(fù)
整數(shù)回復(fù)就是一個以 ":" 開頭， CRLF 結(jié)尾的字符串表示的整數(shù)。
比如說， ":0\r\n" 和 ":1000\r\n" 都是整數(shù)回復(fù)。
返回整數(shù)回復(fù)的其中兩個命令是 INCR 和 LASTSAVE 。 被返回的整數(shù)沒有什么特殊的含義， INCR 返回鍵的一個自增后的整數(shù)值， 而 LASTSAVE 則返回一個 UNIX 時間戳， 返回值的唯一限制是這些數(shù)必須能夠用 64 位有符號整數(shù)表示。
整數(shù)回復(fù)也被廣泛地用于表示邏輯真和邏輯假： 比如 EXISTS 和 SISMEMBER 都用返回值 1 表示真， 0 表示假。
其他一些命令， 比如 SADD 、 SREM 和 SETNX ， 只在操作真正被執(zhí)行了的時候， 才返回 1 ， 否則返回 0 。
以下命令都返回整數(shù)回復(fù)： SETNX 、 DEL 、 EXISTS 、 INCR 、 INCRBY 、 DECR 、 DECRBY 、 DBSIZE 、 LASTSAVE 、RENAMENX 、 MOVE 、 LLEN 、 SADD 、 SREM 、 SISMEMBER 、 SCARD 。
批量回復(fù)
服務(wù)器使用批量回復(fù)來返回二進制安全的字符串，字符串的最大長度為 512 MB 。
客戶端：GET mykey
服務(wù)器：foobar
服務(wù)器發(fā)送的內(nèi)容中：
第一字節(jié)為 "$" 符號
?- 接下來跟著的是表示實際回復(fù)長度的數(shù)字值
- 之后跟著一個 CRLF
- 再后面跟著的是實際回復(fù)數(shù)據(jù)
- 最末尾是另一個 CRLF
對于前面的 GET 命令，服務(wù)器實際發(fā)送的內(nèi)容為：
"$6\r\nfoobar\r\n"
如果被請求的值不存在， 那么批量回復(fù)會將特殊值 -1 用作回復(fù)的長度值， 就像這樣：
客戶端：GET non-existing-key
服務(wù)器：$-1
這種回復(fù)稱為空批量回復(fù)（NULL Bulk Reply）。
當(dāng)請求對象不存在時，客戶端應(yīng)該返回空對象，而不是空字符串： 比如 Ruby 庫應(yīng)該返回 nil ， 而 C 庫應(yīng)該返回NULL （或者在回復(fù)對象中設(shè)置一個特殊標(biāo)志）， 諸如此類。
多條批量回復(fù)
像 LRANGE 這樣的命令需要返回多個值， 這一目標(biāo)可以通過多條批量回復(fù)來完成。
多條批量回復(fù)是由多個回復(fù)組成的數(shù)組， 數(shù)組中的每個元素都可以是任意類型的回復(fù)， 包括多條批量回復(fù)本身。
多條批量回復(fù)的第一個字節(jié)為 "*" ， 后跟一個字符串表示的整數(shù)值， 這個值記錄了多條批量回復(fù)所包含的回復(fù)數(shù)量， 再后面是一個 CRLF 。
客戶端： LRANGE mylist 0 3
服務(wù)器： *4
服務(wù)器： $3
服務(wù)器： foo
服務(wù)器： $3
服務(wù)器： bar
服務(wù)器： $5
服務(wù)器： Hello
服務(wù)器： $5
服務(wù)器： World
在上面的示例中，服務(wù)器發(fā)送的所有字符串都由 CRLF 結(jié)尾。
正如你所見到的那樣， 多條批量回復(fù)所使用的格式， 和客戶端發(fā)送命令時使用的統(tǒng)一請求協(xié)議的格式一模一樣。 它們之間的唯一區(qū)別是：
統(tǒng)一請求協(xié)議只發(fā)送批量回復(fù)。
而服務(wù)器應(yīng)答命令時所發(fā)送的多條批量回復(fù)，則可以包含任意類型的回復(fù)。
以下例子展示了一個多條批量回復(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ù)的第一行， 服務(wù)器發(fā)送 *5\r\n ， 表示這個多條批量回復(fù)包含 5 條回復(fù)， 再后面跟著的則是 5 條回復(fù)的正文。
多條批量回復(fù)也可以是空白的（empty）， 就像這樣：
客戶端： LRANGE nokey 0 1
服務(wù)器： *0\r\n
無內(nèi)容的多條批量回復(fù)（null multi bulk reply）也是存在的， 比如當(dāng) BLPOP 命令的阻塞時間超過最大時限時， 它就返回一個無內(nèi)容的多條批量回復(fù)， 這個回復(fù)的計數(shù)值為 -1 ：
客戶端： BLPOP key 1
服務(wù)器： *-1\r\n
客戶端庫應(yīng)該區(qū)別對待空白多條回復(fù)和無內(nèi)容多條回復(fù)： 當(dāng) Redis 返回一個無內(nèi)容多條回復(fù)時， 客戶端庫應(yīng)該返回一個 null 對象， 而不是一個空數(shù)組。
多條批量回復(fù)中的空元素
多條批量回復(fù)中的元素可以將自身的長度設(shè)置為 -1 ， 從而表示該元素不存在， 并且也不是一個空白字符串（empty string）。
當(dāng) SORT 命令使用 GET pattern 選項對一個不存在的鍵進行操作時， 就會發(fā)生多條批量回復(fù)中帶有空白元素的情況。
以下例子展示了一個包含空元素的多重批量回復(fù)：
服務(wù)器： *3
服務(wù)器： $3
服務(wù)器： foo
服務(wù)器： $-1
服務(wù)器： $3
服務(wù)器： bar
其中， 回復(fù)中的第二個元素為空。
對于這個回復(fù)， 客戶端庫應(yīng)該返回類似于這樣的回復(fù)：
["foo", nil, "bar"]
網(wǎng)頁標(biāo)題：app與服務(wù)器安全交互 app與服務(wù)器對接
分享路徑：http://ef60e0e.cn/article/ddcdgsi.html
