Android中網(wǎng)絡(luò)通信的幾種方式

主要有六種方式：

站在用戶的角度思考問題，與客戶深入溝通，找到墨脫網(wǎng)站設(shè)計(jì)與墨脫網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、空間域名、網(wǎng)站空間、企業(yè)郵箱。業(yè)務(wù)覆蓋墨脫地區(qū)。

（1）針對(duì)TCP/IP的Socket、ServerSocket

（2）針對(duì)UDP的DatagramSocket、DatagramPackage。這里需要注意的是，考慮到Android設(shè)備通常是手持終端,IP都是隨著上網(wǎng)進(jìn)行分配的。不是固定的。因此開發(fā)也是有一點(diǎn)與普通互聯(lián)網(wǎng)應(yīng)用有所差異的。

（3）針對(duì)直接URL的HttpURLConnection。

（4）Google集成了Apache HTTP客戶端，可使用HTTP進(jìn)行網(wǎng)絡(luò)編程。

（5）使用WebService。Android可以通過開源包如jackson去支持Xmlrpc和Jsonrpc,另外也可以用Ksoap2去實(shí)現(xiàn)Webservice。

（6）直接使用WebView視圖組件顯示網(wǎng)頁。基于WebView 進(jìn)行開發(fā)，Google已經(jīng)提供了一個(gè)基于chrome-lite的Web瀏覽器，直接就可以進(jìn)行上網(wǎng)瀏覽網(wǎng)頁。

android網(wǎng)絡(luò)通信為什么這么慢

有幾個(gè)地方可能會(huì)拖慢速度：

1.首先和手機(jī)的網(wǎng)速有關(guān)系，抓取網(wǎng)頁就像你在瀏覽器中打開一個(gè)網(wǎng)址，然會(huì)得到html，如果是wifi情況良好下，不比用pc請(qǐng)求得到響應(yīng)會(huì)慢。

2.和對(duì)方網(wǎng)站也有關(guān)系，也許在你手機(jī)和電腦同等網(wǎng)絡(luò)的情況下，pc打開也會(huì)慢。

3.你抓取網(wǎng)頁后要做解析吧？解析也是要時(shí)間的。

4.如果你提交的請(qǐng)求在服務(wù)端要做復(fù)雜處理后返回的話，也會(huì)導(dǎo)致你手機(jī)獲取變慢。

一般情況網(wǎng)絡(luò)良好的話，從提交請(qǐng)求到獲取信息在3秒左右是正常的

Android服務(wù)器通信的幾種方式詳解

大 學(xué)學(xué)習(xí)網(wǎng)絡(luò)基礎(chǔ)的時(shí)候老師講過，網(wǎng)絡(luò)由下往上分為物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會(huì)話層、表示層和應(yīng)用層。通過初步的了解，我知道IP協(xié)議對(duì)應(yīng)于網(wǎng) 絡(luò)層，TCP協(xié)議對(duì)應(yīng)于傳輸層，而HTTP協(xié)議對(duì)應(yīng)于應(yīng)用層，三者從本質(zhì)上來說沒有可比性，socket則是對(duì)TCP/IP協(xié)議的封裝和應(yīng)用（程序員層面 上）。也可以說，TPC/IP協(xié)議是傳輸層協(xié)議，主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸，而HTTP是應(yīng)用層協(xié)議，主要解決如何包裝數(shù)據(jù)。關(guān)于TCP/IP和 HTTP協(xié)議的關(guān)系，網(wǎng)絡(luò)有一段比較容易理解的介紹： “我們?cè)趥鬏敂?shù)據(jù)時(shí)，可以只使用（傳輸層）TCP/IP協(xié)議，但是那樣的話，如果沒有應(yīng)用層，便無法識(shí)別數(shù)據(jù)內(nèi)容，如果想要使傳輸?shù)臄?shù)據(jù)有意義，則必須使 用到應(yīng)用層協(xié)議，應(yīng)用層協(xié)議有很多，比如HTTP、FTP、TELNET等，也可以自己定義應(yīng)用層協(xié)議。WEB使用HTTP協(xié)議作應(yīng)用層協(xié)議，以封裝 HTTP文本信息，然后使用TCP/IP做傳輸層協(xié)議將它發(fā)到網(wǎng)絡(luò)上。”

而我們平時(shí)說的最多的socket是什么呢，實(shí)際上socket是對(duì)TCP/IP協(xié)議的封裝，Socket本身并不是協(xié)議，而是一個(gè)調(diào)用接口（API）， 通過Socket，我們才能使用TCP/IP協(xié)議。實(shí)際上，Socket跟TCP/IP協(xié)議沒有必然的聯(lián)系。Socket編程接口在設(shè)計(jì)的時(shí)候，就希望也 能適應(yīng)其他的網(wǎng)絡(luò)協(xié)議。所以說，Socket的出現(xiàn)只是使得程序員更方便地使用TCP/IP協(xié)議棧而已，是對(duì)TCP/IP協(xié)議的抽象，從而形成了我們知道 的一些最基本的函數(shù)接口，比如create、listen、connect、accept、send、read和write等等。網(wǎng)絡(luò)有一段關(guān)于 socket和TCP/IP協(xié)議關(guān)系的說法比較容易理解：“TCP/IP只是一個(gè)協(xié)議棧，就像操作系統(tǒng)的運(yùn)行機(jī)制一樣，必須要具體實(shí)現(xiàn)，同時(shí)還要提供對(duì)外 的操作接口。這個(gè)就像操作系統(tǒng)會(huì)提供標(biāo)準(zhǔn)的編程接口，比如win32編程接口一樣，TCP/IP也要提供可供程序員做網(wǎng)絡(luò)開發(fā)所用的接口，這就是 Socket編程接口。”

關(guān)于TCP/IP協(xié)議的相關(guān)只是，用博大精深來講我想也不為過，單單查一下網(wǎng)上關(guān)于此類只是的資料和書籍文獻(xiàn)的數(shù)量就知道，這個(gè)我打算會(huì)買一些經(jīng)典的書籍 （比如《TCP/IP詳解：卷一、卷二、卷三》）進(jìn)行學(xué)習(xí)，今天就先總結(jié)一些基于基于TCP/IP協(xié)議的應(yīng)用和編程接口的知識(shí)，也就是剛才說了很多的 HTTP和Socket。

CSDN上有個(gè)比較形象的描述：HTTP是轎車，提供了封裝或者顯示數(shù)據(jù)的具體形式；Socket是發(fā)動(dòng)機(jī)，提供了網(wǎng)絡(luò)通信的能力。

實(shí)際上，傳輸層的TCP是基于網(wǎng)絡(luò)層的IP協(xié)議的，而應(yīng)用層的HTTP協(xié)議又是基于傳輸層的TCP協(xié)議的，而Socket本身不算是協(xié)議，就像上面所說，它只是提供了一個(gè)針對(duì)TCP或者UDP編程的接口。

下面是一些經(jīng)常在筆試或者面試中碰到的重要的概念，特在此做摘抄和總結(jié)。

一。什么是TCP連接的三次握手

第一次握手：客戶端發(fā)送syn包(syn=j)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)；

第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k），即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)；

第三次握手：客戶端收到服務(wù)器的SYN＋ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。

握手過程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下，TCP連接一旦建立，在通信雙方中的任何一方主動(dòng)關(guān)閉 連接之前，TCP 連接都將被一直保持下去。斷開連接時(shí)服務(wù)器和客戶端均可以主動(dòng)發(fā)起斷開TCP連接的請(qǐng)求，斷開過程需要經(jīng)過“四次握手”（過程就不細(xì)寫了，就是服務(wù)器和客 戶端交互，最終確定斷開）

二。利用Socket建立網(wǎng)絡(luò)連接的步驟

建立Socket連接至少需要一對(duì)套接字，其中一個(gè)運(yùn)行于客戶端，稱為ClientSocket ，另一個(gè)運(yùn)行于服務(wù)器端，稱為ServerSocket 。

套接字之間的連接過程分為三個(gè)步驟：服務(wù)器監(jiān)聽，客戶端請(qǐng)求，連接確認(rèn)。

1。服務(wù)器監(jiān)聽：服務(wù)器端套接字并不定位具體的客戶端套接字，而是處于等待連接的狀態(tài)，實(shí)時(shí)監(jiān)控網(wǎng)絡(luò)狀態(tài)，等待客戶端的連接請(qǐng)求。

2。客戶端請(qǐng)求：指客戶端的套接字提出連接請(qǐng)求，要連接的目標(biāo)是服務(wù)器端的套接字。為此，客戶端的套接字必須首先描述它要連接的服務(wù)器的套接字，指出服務(wù)器端套接字的地址和端口號(hào)，然后就向服務(wù)器端套接字提出連接請(qǐng)求。

3。 連接確認(rèn)：當(dāng)服務(wù)器端套接字監(jiān)聽到或者說接收到客戶端套接字的連接請(qǐng)求時(shí)，就響應(yīng)客戶端套接字的請(qǐng)求，建立一個(gè)新的線程，把服務(wù)器端套接字的描述發(fā)給客戶 端，一旦客戶端確認(rèn)了此描述，雙方就正式建立連接。而服務(wù)器端套接字繼續(xù)處于監(jiān)聽狀態(tài)，繼續(xù)接收其他客戶端套接字的連接請(qǐng)求。

三。HTTP鏈接的特點(diǎn)

HTTP協(xié)議即超文本傳送協(xié)議(Hypertext Transfer Protocol )，是Web聯(lián)網(wǎng)的基礎(chǔ)，也是手機(jī)聯(lián)網(wǎng)常用的協(xié)議之一，HTTP協(xié)議是建立在TCP協(xié)議之上的一種應(yīng)用。

HTTP連接最顯著的特點(diǎn)是客戶端發(fā)送的每次請(qǐng)求都需要服務(wù)器回送響應(yīng)，在請(qǐng)求結(jié)束后，會(huì)主動(dòng)釋放連接。從建立連接到關(guān)閉連接的過程稱為“一次連接”。

四。TCP和UDP的區(qū)別（考得最多。。快被考爛了我覺得- -\\）

1。 TCP是面向鏈接的，雖然說網(wǎng)絡(luò)的不安全不穩(wěn)定特性決定了多少次握手都不能保證連接的可靠性，但TCP的三次握手在最低限度上（實(shí)際上也很大程度上保證 了）保證了連接的可靠性；而UDP不是面向連接的，UDP傳送數(shù)據(jù)前并不與對(duì)方建立連接，對(duì)接收到的數(shù)據(jù)也不發(fā)送確認(rèn)信號(hào)，發(fā)送端不知道數(shù)據(jù)是否會(huì)正確接 收，當(dāng)然也不用重發(fā)，所以說UDP是無連接的、不可靠的一種數(shù)據(jù)傳輸協(xié)議。

2。也正由于1所說的特點(diǎn)，使得UDP的開銷更小數(shù)據(jù)傳輸速率更高，因?yàn)椴槐剡M(jìn)行收發(fā)數(shù)據(jù)的確認(rèn)，所以UDP的實(shí)時(shí)性更好。

知 道了TCP和UDP的區(qū)別，就不難理解為何采用TCP傳輸協(xié)議的MSN比采用UDP的QQ傳輸文件慢了，但并不能說QQ的通信是不安全的，因?yàn)槌绦騿T可以 手動(dòng)對(duì)UDP的數(shù)據(jù)收發(fā)進(jìn)行驗(yàn)證，比如發(fā)送方對(duì)每個(gè)數(shù)據(jù)包進(jìn)行編號(hào)然后由接收方進(jìn)行驗(yàn)證啊什么的，即使是這樣，UDP因?yàn)樵诘讓訁f(xié)議的封裝上沒有采用類似 TCP的“三次握手”而實(shí)現(xiàn)了TCP所無法達(dá)到的傳輸效率。

Android ParcelFileDescriptor實(shí)現(xiàn)進(jìn)程間通信

一個(gè)通信通道，實(shí)現(xiàn)跨進(jìn)程的的Socket網(wǎng)絡(luò)通信。

具體的通信通道的圖如下。

android進(jìn)程間通信是使用Binder來傳數(shù)據(jù)，而Binder傳輸?shù)臄?shù)據(jù)，有一個(gè)最為基本的要求，就是要實(shí)現(xiàn)Parcelable接口。

ParcelFileDescriptor是android提供的一個(gè)數(shù)據(jù)結(jié)構(gòu)。

ParcelFileDescriptor是可以用于進(jìn)程間Binder通信的FileDescriptor。支持stream 寫入和stream 讀出

我們可以使用

來將PacecelFileDescriptor 與File對(duì)應(yīng)起來，以實(shí)現(xiàn)進(jìn)程間的文件共享。

我們也可以使用

來建立一個(gè)pipe通信通道，ParcelFileDescriptor數(shù)組第一個(gè)元素是read端，第二個(gè)元素是write端，通過write端的AutoCloseOutputStream和read端的AutoCloseInputStream，我們就可以實(shí)現(xiàn)進(jìn)程見的數(shù)據(jù)流傳輸了。

發(fā)送端：

1. 業(yè)務(wù)層調(diào)用getOutputStream向通信層發(fā)起請(qǐng)求

2. 通信層通過creatPipe 建立一個(gè)ParcelFileDescriptor數(shù)組，并將write端的pipe[1]返回給業(yè)務(wù)層

3. 業(yè)務(wù)層得到pipe[1]（ParcelFileDescriptor）后，可以通過AutoCloseOutputStream寫入數(shù)據(jù)

4. 從通信層的pipe[0]的AutoCloseInputStream中讀出數(shù)據(jù)通過socket發(fā)送出去

接收端：

1. 業(yè)務(wù)層調(diào)用getInputStream向通信層發(fā)起請(qǐng)求

2. 通信層通過creatPipe 建立一個(gè)ParcelFileDescriptor數(shù)組，并將read端的pipe[0]返回給業(yè)務(wù)層

3. 業(yè)務(wù)層得到pipe 0 后，可以通過AutoCloseInputStream讀取數(shù)據(jù)。（如沒有數(shù)據(jù)，則阻塞，一直等到有數(shù)據(jù)為止）

4. socket中讀取數(shù)據(jù)，寫入到通信層的pipe[1]的AutoCloseOutputStream。（pipe[1]一旦寫入，第三步中pipe[2]就可以讀取出數(shù)據(jù)）

android集成Grpc，使用grpc進(jìn)行數(shù)據(jù)交互網(wǎng)絡(luò)通信

集成

1、首先在project的gradle文件中的dependencies里進(jìn)行如下配置

2、在app的gradle文件中操作

在最頂部添加

添加protobuf編譯器

添加grpc的相關(guān)引用

ok好了至此已經(jīng)集成完畢了，接下來就是使用了

proto生成Java文件

(1) 把自己的proto文件復(fù)制粘貼到main/proto目錄下，點(diǎn)擊Android Studio中的Build菜單下的Rebuild Project即可

(2) Java文件生成位置：app/build/generated/source/proto/……

(3) 將Java文件復(fù)制出來即可使用

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

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

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

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

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

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

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

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

Tracking：分析用戶行為

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

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

兩種方式：Basic和Bearer

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

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

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

步驟分析就是上面的內(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：指訪問令牌，必選，這里填第⑦步獲取的access_token

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

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

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

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

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

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

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

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

1.客戶端通過發(fā)送Client Hello報(bào)文開始SSL通信。報(bào)文中包含客戶端支持的SSL的指定版本、加密組件列表（所使用的加密算法及密鑰長度），客戶端隨機(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)篩選出來的。

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

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中的公開密鑰進(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ù)。從此處開始進(jìn)行應(yīng)用層協(xié)議的通信，即發(fā)送HTTP響應(yīng)。

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

12.最后由客戶端斷開連接。斷開連接時(shí)，發(fā)送close_notify報(bào)文。這步之后再發(fā)送TCP FIN報(bào)文來關(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建立過程

分享文章：android網(wǎng)絡(luò)通信,安卓 網(wǎng)絡(luò)通信
地址分享：http://chinadenli.net/article5/dseeeoi.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、移動(dòng)網(wǎng)站建設(shè)、定制網(wǎng)站、App開發(fā)、網(wǎng)站建設(shè)、App設(shè)計(jì)

廣告

聲明：本網(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í)需注明來源： 創(chuàng)新互聯(lián)