Android網(wǎng)絡(luò)請(qǐng)求知識(shí)（三）授權(quán)，TCP/IP，HTTPS建立過(guò)程

由身份或持有的令牌確認(rèn)享有的權(quán)限，登錄過(guò)程實(shí)質(zhì)上的目的也是為了確認(rèn)權(quán)限。

創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比修文網(wǎng)站開(kāi)發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式修文網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋修文地區(qū)。費(fèi)用合理售后完善，十年實(shí)體公司更值得信賴。

Cookie是客戶端給服務(wù)器用的，setCookie是服務(wù)器給客戶端用的。cookie由服務(wù)器處理，客戶端負(fù)責(zé)存儲(chǔ)

客戶端發(fā)送cookie：賬戶和密碼

服務(wù)端收到后確認(rèn)登錄setCookie：sessionID=1，記下sessionID

客戶端收到sessionID后記錄，以后請(qǐng)求服務(wù)端帶上對(duì)比記錄下sessionID，說(shuō)明已經(jīng)登錄

會(huì)話管理：登錄狀態(tài)，購(gòu)物車

個(gè)性化：用戶偏好，主題

Tracking：分析用戶行為

XXS：跨腳本攻擊，及使用JavaScript拿到瀏覽器的cookie之后，發(fā)送到自己的網(wǎng)站，以這種方式來(lái)盜用用戶Cookie。Server在發(fā)送Cookie時(shí)，敏感的Cookie加上HttpOnly，這樣Cookie只能用于http請(qǐng)求，不能被JavaScript調(diào)用

XSRF:跨站請(qǐng)求偽造。Referer 從哪個(gè)網(wǎng)站跳轉(zhuǎn)過(guò)來(lái)

兩種方式：Basic和Bearer

首先第三方網(wǎng)站向授權(quán)網(wǎng)站申請(qǐng)第三方授權(quán)合作，拿到授權(quán)方頒發(fā)的client_id和client_secret（一般都是appid+appkey的方式）。

在這就過(guò)程中申請(qǐng)的client_secret是服務(wù)器持有的，安全起見(jiàn)不能給客戶端，用服務(wù)端去和授權(quán)方獲取用戶信息，再傳給客戶端，包括④，⑤的請(qǐng)求過(guò)程也是需要加密的。這才是標(biāo)準(zhǔn)的授權(quán)過(guò)程。

有了access_token之后，就可以向授權(quán)方發(fā)送請(qǐng)求來(lái)獲取用戶信息

步驟分析就是上面的內(nèi)容，這里把第4,6,8請(qǐng)求的參數(shù)分析一下

第④步參數(shù)：

response_type：指授權(quán)類型，必選，這里填固定值‘code’

client_id：指客戶端id，必選，這里填在平臺(tái)報(bào)備時(shí)獲取的appid

redirect_uri：指重定向URI，可選

scope：指申請(qǐng)的權(quán)限范圍，可選

state：指客戶端當(dāng)前狀態(tài)，可選，若填了，則認(rèn)證服務(wù)器會(huì)原樣返回該值

第⑥步參數(shù)：

grant_type：指使用哪種授權(quán)模式，必選，這里填固定值‘a(chǎn)uthorization_code’

code：指從第⑤步獲取的code，必選

redirect_uri：指重定向URI，必選，這個(gè)值需要和第④步中的redirect_uri保持一致

client_id：指客戶端id，必選，這里填在平臺(tái)報(bào)備時(shí)獲取的appid

client_secret：指客戶端密鑰，必選，這里填在平臺(tái)報(bào)備時(shí)獲取的appkey

第⑧步參數(shù)：

access_token：指訪問(wèn)令牌，必選，這里填第⑦步獲取的access_token

token_type：指令牌類型，必選，大小寫(xiě)不敏感，bearer類型 / mac類型

expires_in：指過(guò)期時(shí)間，單位秒，當(dāng)其他地方已設(shè)置過(guò)期時(shí)間，此處可省略該參數(shù)

refresh_token：指更新令牌，可選，用即將過(guò)期token換取新token

scope：指權(quán)限范圍，可選，第④步中若已申請(qǐng)過(guò)某權(quán)限，此處可省略該參數(shù)

我們?cè)谏厦娴牡诎瞬街袝?huì)有refresh_token的參數(shù)，這個(gè)在實(shí)際操作中也比較常見(jiàn)

有時(shí)候我們?cè)谧约旱捻?xiàng)目中，將登陸和授權(quán)設(shè)計(jì)成類似OAuth2的過(guò)程，不過(guò)去掉Authorization code。登陸成功返回access_token，然后客戶端再請(qǐng)求時(shí)，帶上access_token。

我們常常會(huì)說(shuō)到TCP/IP，那到底是什么呢。這就需要講到網(wǎng)絡(luò)分層模型。TCP在傳輸層，IP在網(wǎng)絡(luò)層。那為什么需要分層？因?yàn)榫W(wǎng)絡(luò)不穩(wěn)定，導(dǎo)致需要重傳的問(wèn)題。為了提高傳輸效率我們就需要分塊，在傳輸層中就會(huì)進(jìn)行分塊。TCP還有兩個(gè)重要的內(nèi)容就是三次握手，四次分手。

HTTPS 協(xié)議是由 HTTP 加上TLS/SSL協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，主要通過(guò)數(shù)字證書(shū)、加密算法、非對(duì)稱密鑰等技術(shù)完成互聯(lián)網(wǎng)數(shù)據(jù)傳輸加密，實(shí)現(xiàn)互聯(lián)網(wǎng)傳輸安全保護(hù)

1.客戶端通過(guò)發(fā)送Client Hello報(bào)文開(kāi)始SSL通信。報(bào)文中包含客戶端支持的SSL的指定版本、加密組件列表（所使用的加密算法及密鑰長(zhǎng)度），客戶端隨機(jī)數(shù)，hash算法。

2.服務(wù)器可進(jìn)行SSL通信時(shí)，會(huì)以Server Hello報(bào)文作為應(yīng)答。和客戶端一樣，在報(bào)文中包含SSL版本以及加密組件，服務(wù)端隨機(jī)數(shù)。服務(wù)器的加密組件內(nèi)容是從接收到客戶端加密組件內(nèi)篩選出來(lái)的。

3.之后服務(wù)器發(fā)送Certificate報(bào)文。報(bào)文中包含公開(kāi)密鑰證書(shū)。一般實(shí)際有三層證書(shū)嵌套，其實(shí)像下面圖二直接用根證書(shū)機(jī)構(gòu)簽名也是可以的，但是一般根證書(shū)機(jī)構(gòu)比較忙，需要類似中介的證書(shū)機(jī)構(gòu)來(lái)幫助。

4.最后服務(wù)器發(fā)送Server Hello Done報(bào)文通知客戶端，最初階段的SSL握手協(xié)商部分結(jié)束。

5.SSL第一次握手結(jié)束后，客戶端以Client Key Exchange報(bào)文作為回應(yīng)。報(bào)文中包含通信加密中使用的一種被稱為Pre-master secret的隨機(jī)密碼串。該報(bào)文已用步驟3中的公開(kāi)密鑰進(jìn)行加密。

6.接著客戶端繼續(xù)發(fā)送Change Cipher Spec報(bào)文。該報(bào)文會(huì)提示服務(wù)器，在此報(bào)文之后的通信會(huì)采用Pre-master secret密鑰加密。

7.客戶端發(fā)送Finished報(bào)文。該報(bào)文包含連接至今全部報(bào)文的整體校驗(yàn)值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確解密報(bào)文作為判定標(biāo)準(zhǔn)。

8.服務(wù)器同樣發(fā)送Change Cipher Spec報(bào)文。

9.服務(wù)器同樣發(fā)送Finished報(bào)文。

10.服務(wù)器和客戶端的Finished報(bào)文交換完畢之后，SSL連接就算建立完成。當(dāng)然，通信會(huì)受到SSL的保護(hù)。從此處開(kāi)始進(jìn)行應(yīng)用層協(xié)議的通信，即發(fā)送HTTP響應(yīng)。

11.應(yīng)用層協(xié)議通信，即發(fā)送HTTP響應(yīng)。

12.最后由客戶端斷開(kāi)連接。斷開(kāi)連接時(shí)，發(fā)送close_notify報(bào)文。這步之后再發(fā)送TCP FIN報(bào)文來(lái)關(guān)閉與TCP的通信。

利用客戶端隨機(jī)數(shù)，服務(wù)端隨機(jī)數(shù)，per-master secret隨機(jī)數(shù)生成master secret，再生成客戶端加密密鑰，服務(wù)端加密密鑰，客戶端MAC secert，服務(wù)端MAC secert。MAC secert用于做報(bào)文摘要，這樣能夠查知報(bào)文是否遭到篡改，從而保護(hù)報(bào)文的完整性。

Android網(wǎng)絡(luò)請(qǐng)求知識(shí)（一）HTTP基礎(chǔ)概念

Android網(wǎng)絡(luò)請(qǐng)求知識(shí)（二）對(duì)稱和非對(duì)稱加密、數(shù)字簽名，Hash，Base64編碼

Android網(wǎng)絡(luò)請(qǐng)求知識(shí)（三）授權(quán)，TCP/IP，HTTPS建立過(guò)程

Android 9.0 無(wú)法請(qǐng)求網(wǎng)絡(luò)問(wèn)題

手機(jī)版本升級(jí)到9.0后，發(fā)現(xiàn)App一直請(qǐng)求網(wǎng)絡(luò)失敗，特奇怪...以為是手機(jī)出毛病了，后來(lái)發(fā)現(xiàn)原來(lái)是android 9.0系統(tǒng)已經(jīng)默認(rèn)不支持http請(qǐng)求了，這個(gè)可以讓后臺(tái)改成https就行，不過(guò)我們還是沒(méi)解決我們移動(dòng)端的問(wèn)題。目前有兩個(gè)方法處理：

1.把targetSdkVersion 改成27或者以下

2.在res目錄添加一個(gè)xml文件夾和network_security_config.xml：

xml內(nèi)容是：

然后再在AndroidManifest.xml的application里加入

這樣就行了。

Android網(wǎng)絡(luò)請(qǐng)求庫(kù)【OkHttp4.9.3】基本用法與原理分析

OkHttp是一套處理 HTTP 網(wǎng)絡(luò)請(qǐng)求的依賴庫(kù)，由 Square 公司設(shè)計(jì)研發(fā)并開(kāi)源，目前可以在 Java 和 Kotlin 中使用。對(duì)于 Android App 來(lái)說(shuō)，OkHttp 現(xiàn)在幾乎已經(jīng)占據(jù)了所有的網(wǎng)絡(luò)請(qǐng)求操作，Retrofit + OkHttp實(shí)現(xiàn)網(wǎng)絡(luò)請(qǐng)求似乎成了一種標(biāo)配。因此它也是每一個(gè) Android 開(kāi)發(fā)工程師的必備技能，了解其內(nèi)部實(shí)現(xiàn)原理可以更好地進(jìn)行功能擴(kuò)展、封裝以及優(yōu)化。

OkHttp的高效性體現(xiàn)在：

第一步：創(chuàng)建OkHttpClient，創(chuàng)建OkHttpClient有兩種方式：

OkHttpClient提供了豐富的配置方法，例如添加攔截器、指定連接池、設(shè)置請(qǐng)求超時(shí)等等。

第二步：創(chuàng)建請(qǐng)求

使用Request.Builder() 構(gòu)建Request實(shí)例

第三步：發(fā)起網(wǎng)絡(luò)請(qǐng)求

OkHttp支持同步和異步兩種請(qǐng)求方式

OkHttp的使用方法非常簡(jiǎn)單，三步操作就可以發(fā)起一個(gè)簡(jiǎn)單的同步或異步請(qǐng)求。我們也可以很輕松地對(duì)網(wǎng)絡(luò)請(qǐng)求進(jìn)行配置，例如添加請(qǐng)求頭、設(shè)置請(qǐng)求方式、設(shè)置請(qǐng)求超時(shí)等等，這些配置參數(shù)會(huì)在源碼分析過(guò)程中詳細(xì)介紹。

現(xiàn)在我們已經(jīng)學(xué)會(huì)了三步操作發(fā)起網(wǎng)絡(luò)請(qǐng)求，接下來(lái)以這三個(gè)步驟為切入點(diǎn)，深入到源碼中學(xué)習(xí)OkHttp的實(shí)現(xiàn)原理，廢話少說(shuō)馬上開(kāi)車。

OkHttpClient創(chuàng)建方式有兩種，我們看看兩種方式有什么區(qū)別。

第一種直接使用默認(rèn)構(gòu)造函數(shù)，內(nèi)部依然是使用建造者模式

第二種使用建造者模式

兩種方式最終都是調(diào)用構(gòu)造函數(shù)OkHttpClient(builder:Builder)，由參數(shù)builder負(fù)責(zé)所有的參數(shù)配置工作。

當(dāng)您創(chuàng)建單個(gè)OkHttpClient實(shí)例并將其用于所有 HTTP 調(diào)用時(shí)，OkHttp 性能最佳。 這是因?yàn)槊總€(gè)OkHttpClient都擁有自己的連接池和線程池，重用連接和線程可減少延遲并節(jié)省內(nèi)存。 相反，為每個(gè)請(qǐng)求創(chuàng)建一個(gè)客戶端會(huì)浪費(fèi)空閑池上的資源。

Request同樣使用建造者模式來(lái)創(chuàng)建，這里貼上部分重要源碼，很簡(jiǎn)單就不細(xì)說(shuō)了。

OkHttp發(fā)起網(wǎng)絡(luò)請(qǐng)求分為同步請(qǐng)求和異步請(qǐng)求兩種方式，我們只分析異步請(qǐng)求流程，因?yàn)橹灰斫饬水惒秸?qǐng)求過(guò)程，基本上也就明白同步請(qǐng)求是怎么一回事了。

RealCall是連接應(yīng)用層與網(wǎng)絡(luò)層的橋梁，負(fù)責(zé)處理連接、請(qǐng)求、響應(yīng)和數(shù)據(jù)流。

Dispatcher維護(hù)著一套異步任務(wù)執(zhí)行策略，分析策略之前先介紹幾個(gè)重要概念：

client.dispatcher.enqueue(AsyncCall(responseCallback)) 執(zhí)行步驟為：

AsyncCall實(shí)現(xiàn)了Runnable接口，因此一旦被線程池中的線程處理就會(huì)調(diào)用它的run()方法：

話休絮煩，我們開(kāi)始分析攔截器責(zé)任鏈：

責(zé)任鏈執(zhí)行流程：首先獲取當(dāng)前攔截器interceptor，并且調(diào)用interceptor.intercept(next)執(zhí)行攔截器操作。這里的next表示的是index+1后的責(zé)任鏈對(duì)象，攔截器的intercept()方法內(nèi)部會(huì)調(diào)用next.proceed(request)方法再次進(jìn)入到責(zé)任鏈，由于此時(shí)index已經(jīng)加1，所以處理的是下一個(gè)攔截器。

如此循環(huán)往復(fù)，直到處理完責(zé)任鏈上最后一個(gè)攔截器為止。

注意除最后一個(gè)攔截器CallServerInterceptor不會(huì)調(diào)用chain.proceed(request)方法之外，其他攔截器都應(yīng)該至少調(diào)用一次chain.proceed(request)方法。

為了驗(yàn)證上面的結(jié)論，我們進(jìn)入到RetryAndFollowUpInterceptor的intercept()方法一探究竟：

可以看到注釋1處重新進(jìn)入責(zé)任鏈處理下一個(gè)攔截器。

有興趣可以自行查看最后一個(gè)攔截器CallServerInterceptor源碼，此處只給出本人閱讀源碼后得出的結(jié)論：

以上就是攔截器責(zé)任鏈的工作流程，我們?cè)偻ㄟ^(guò)流程圖仔細(xì)感受一下。

分析完攔截器責(zé)任鏈，我們繼續(xù)分析AsyncCall#run()方法：

我們看到，如果getResponseWithInterceptorChain()方法成功獲得服務(wù)端返回的數(shù)據(jù)，則調(diào)用responseCallback.onResponse(this@RealCall, response)方法完成異步回調(diào)；如果服務(wù)端數(shù)據(jù)獲取失?。ㄕ?qǐng)求異常），則調(diào)用responseCallback.onFailure(this@RealCall, canceledException)方法完成異步回調(diào)

需要注意的是，responseCallback回調(diào)是在子線程中完成的，所以如果想把數(shù)據(jù)顯示到UI上，需要切換回主線程進(jìn)行UI操作。

OkHttp發(fā)起網(wǎng)絡(luò)請(qǐng)求全過(guò)程：

【知識(shí)點(diǎn)】OkHttp 原理 8 連問(wèn)

新聞名稱：android請(qǐng)求網(wǎng)絡(luò),android原生網(wǎng)絡(luò)請(qǐng)求
鏈接分享：http://jinyejixie.com/article34/dsdggse.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供標(biāo)簽優(yōu)化、網(wǎng)頁(yè)設(shè)計(jì)公司、電子商務(wù)、網(wǎng)站維護(hù)、自適應(yīng)網(wǎng)站、網(wǎng)站排名

廣告

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