android軟件開發(fā)撥號(hào)為什么要連網(wǎng)絡(luò)

因?yàn)檫@個(gè)撥號(hào)功能消耗流量，不消耗話費(fèi)。

為豐臺(tái)等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及豐臺(tái)網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為成都做網(wǎng)站、網(wǎng)站設(shè)計(jì)、豐臺(tái)網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

不消耗話費(fèi)的情況下，如果不連接網(wǎng)絡(luò)，就無法撥號(hào)。

Android是由Google公司和開放手機(jī)聯(lián)盟領(lǐng)導(dǎo)并開發(fā)的一種基于Linux的自由且開放源代碼的操作系統(tǒng)，該平臺(tái)由操作系統(tǒng)、中間件、用戶界面和應(yīng)用軟件組成，主要使用于移動(dòng)設(shè)備。Android的圖案是一個(gè)全身綠色的機(jī)器人，其顏色采用了PMS 376C和RGB中十六進(jìn)制的#A4C639來繪制

Android之網(wǎng)絡(luò)—第二篇（Https原理）

Android之網(wǎng)絡(luò)—第一篇（Http原理）

Android之網(wǎng)絡(luò)—第二篇（Https原理）

Android之網(wǎng)絡(luò)—第三篇（解讀OkHttp）

Android之網(wǎng)絡(luò)—第四篇（解讀Retrofit）

說的通俗一點(diǎn)就是身披安全衣的Http，本質(zhì)還是http，只是在http外層嵌套了一個(gè)SSL/TLS的安全層，該層做了一些數(shù)據(jù)的加解密處理。

在講解Https原理之前，先做點(diǎn)準(zhǔn)備工作，因?yàn)闀?huì)涉及到SSL/TLS連接建立、SSL/TLS加解密方面的知識(shí)。所以會(huì)整體從網(wǎng)絡(luò)架構(gòu)和比較重要的知識(shí)點(diǎn)回顧下網(wǎng)絡(luò)知識(shí)。

在講解什么是SSL/TLS之前，回顧下TCP/IP協(xié)議的分層概念。通常一個(gè)網(wǎng)絡(luò)的傳輸中間會(huì)經(jīng)過很多的傳輸節(jié)點(diǎn)，才最終達(dá)到服務(wù)器。期間過程會(huì)包含數(shù)據(jù)的拆分和拼裝、IP的解析、數(shù)據(jù)的傳輸?shù)鹊炔僮鳎蔷W(wǎng)絡(luò)傳輸是很不穩(wěn)定的，如果這次網(wǎng)絡(luò)請(qǐng)求在中間的某一節(jié)點(diǎn)失敗了，難道還要重新再發(fā)送一遍么？答案是不應(yīng)該這么做。

為了網(wǎng)絡(luò)傳輸?shù)慕y(tǒng)一規(guī)范，就設(shè)計(jì)了這么一套網(wǎng)絡(luò)通信的規(guī)范，每一層都專注做一件事情，即使當(dāng)前失敗了，也在這層做處理就可以了，盡量避免重發(fā)。

簡(jiǎn)單解釋下，每層的含義：

通過上圖發(fā)現(xiàn)，數(shù)據(jù)是由上往下傳遞后，再由下往回傳遞。這是怎么回事呢？總結(jié)就是：在 TCP / IP　協(xié)議中數(shù)據(jù)先由上往下將數(shù)據(jù)裝包，然后由下往上拆包。在裝包的時(shí)候，每一層都會(huì)增加一些信息用于傳輸，這部分信息就叫報(bào)頭，當(dāng)上層的數(shù)據(jù)到達(dá)本層的時(shí)候，會(huì)將數(shù)據(jù)加上本層的報(bào)頭打包在一起，繼續(xù)往下傳遞。在拆包的時(shí)候，每一層將本層需要的報(bào)頭讀取后，就將剩下的數(shù)據(jù)往上傳。

簡(jiǎn)要分析下傳輸過程：

這里簡(jiǎn)單總結(jié)下傳輸層的兩種連接方式：TCP和UDP

三次握手：客戶端主動(dòng)打開連接，服務(wù)器被動(dòng)打開連接。

四次揮手：客戶端主動(dòng)關(guān)閉，服務(wù)器被動(dòng)關(guān)閉

說個(gè)概念性的東西就是，現(xiàn)代密碼學(xué)分為對(duì)稱加密和非對(duì)稱加密，跟傳統(tǒng)密碼學(xué)不一樣的地方就是，除了可以加密文字內(nèi)容外，還可以用于各種二進(jìn)制數(shù)據(jù)的加解密。

通信雙方使用同一個(gè)密鑰，使用加密算法配合上密鑰來加密，解密時(shí)使用解密算法（加密過程的完全逆運(yùn)算）配合密鑰來進(jìn)行解密。常用的經(jīng)典算法：DES（56 位密鑰，密鑰太短而逐漸被棄用）、AES（128 位、192 位、256 位密鑰，現(xiàn)在最流行）。

通信雙方使用公鑰和加密算法對(duì)數(shù)據(jù)進(jìn)行加密得到密文；使用私鑰和加密算法對(duì)數(shù)據(jù)進(jìn)行解密得到原數(shù)據(jù)。常用的經(jīng)典算法：RSA（可用于加密和簽名）、DSA（僅用于簽名，但速度更快）。

這個(gè)有什么用？其實(shí)這個(gè)就是后面Https加解密的原理。原理這么簡(jiǎn)單么？是的，就這么簡(jiǎn)單。但是要理解還得慢慢往下看。

A用自己的私鑰通過加密算法得到的數(shù)據(jù)密文數(shù)據(jù)，這個(gè)數(shù)據(jù)就可以稱為簽過名。接收方B再用A提供的公鑰通過加密算法就可以還原數(shù)據(jù)，從而就驗(yàn)證了數(shù)據(jù)的真實(shí)性。因?yàn)橹挥蠥一個(gè)人擁有自己的私鑰。

到這里咱們就可以聊聊剛才中間人偽造數(shù)據(jù)是如何處理了。通過對(duì)稱加密可以防止中間人偷窺數(shù)據(jù)，通過數(shù)字簽名可以防止中間人篡改偽造數(shù)據(jù)。

但是完整版的簽名信息需要將簽名數(shù)據(jù)取Hash值，減少數(shù)據(jù)大小

好了，看完理解了上面的知識(shí)點(diǎn)，到這里我們可以慢慢分析Https是如何工作的了。

先來總結(jié)一句話：Https的本質(zhì)就是在客戶端和服務(wù)端之間用非對(duì)稱加密協(xié)商出一套對(duì)稱密鑰，每次發(fā)送信息之前將內(nèi)容加密，接收后解密，達(dá)到內(nèi)容的加密傳輸。解釋下，就是整個(gè)數(shù)據(jù)的傳輸過程是用對(duì)稱加密的方式來傳輸?shù)模皇敲荑€的生成是由客戶端和服務(wù)端 在創(chuàng)建連接的時(shí)候 通過 非對(duì)稱加密的方式 協(xié)商生成的。

那這里就會(huì)有一系列的問題啦：

Q：為什么不直接用非對(duì)稱加密的方式直接加密呢？

A：因?yàn)榉菍?duì)稱加密的計(jì)算過程是復(fù)雜的數(shù)學(xué)運(yùn)算，太復(fù)雜了，很慢。

Q：哦哦，那既然使用對(duì)稱加密的話，這個(gè)對(duì)稱密鑰是怎么來的？

A：在實(shí)際的場(chǎng)景中，服務(wù)端會(huì)對(duì)接N個(gè)客戶端，這個(gè)對(duì)稱密鑰如果都使用同一個(gè)密鑰來通信的話，肯定是不合理的，只要破解了其中一個(gè)，其他所有的都會(huì)被破解。所以整體的網(wǎng)絡(luò)架構(gòu)應(yīng)該是使用不同加密方式用不同的密鑰來進(jìn)行數(shù)據(jù)傳輸?shù)摹ＤＰ腿缦聢D

Q：但是在網(wǎng)絡(luò)場(chǎng)景中，對(duì)稱加密的密鑰是不能直接在網(wǎng)絡(luò)上傳輸?shù)摹７?wù)端和客戶端是如何都知道的呢？

A：這個(gè)是服務(wù)端和客戶端一起協(xié)商根據(jù)只有它倆知道的規(guī)則分別生成，就不用通過網(wǎng)絡(luò)傳輸啦。

Q：如果保證它倆協(xié)商出來的密鑰不被破解呢？

A：當(dāng)然是使用非對(duì)稱加密的方式啦。通過之前的加密知識(shí)，可以知道非對(duì)稱加密是目前來說是絕對(duì)安全的。而且一個(gè)私鑰可以有多個(gè)公鑰，正好滿足一個(gè)服務(wù)端對(duì)N個(gè)客戶端的場(chǎng)景。模型如下圖：

實(shí)際在協(xié)商通訊的過程中，這個(gè)公鑰是服務(wù)端給客戶端發(fā)送的。而且需要注意 這個(gè)公鑰是用來協(xié)商生成對(duì)稱密鑰的，不是用來做數(shù)據(jù)的加密傳輸?shù)?。

Q：哦哦，原來是這樣，但是這樣子還是有問題啊，客戶端與服務(wù)端在協(xié)商生成密鑰的過程中為了保證數(shù)據(jù)被偷窺和被篡改的風(fēng)險(xiǎn)，一般會(huì)要求有兩套公鑰和私鑰分別做加解密和簽名驗(yàn)證處理的，上面的模型只有一套公鑰和私鑰，沒法規(guī)避數(shù)據(jù)被被篡改的風(fēng)險(xiǎn)呀。

A：能提出這個(gè)問題，說明之前的學(xué)習(xí)理解得很好。從上面的模型，可以保證在協(xié)商的過程中客戶端A/B/C/D分別向服務(wù)器傳輸?shù)臄?shù)據(jù)是安全。但是服務(wù)器發(fā)送給客戶端的數(shù)據(jù)是如何保證的呢？換句話說就是，客戶端如何驗(yàn)證數(shù)據(jù)是服務(wù)端發(fā)送過來的，而不是被中間假冒掉包的數(shù)據(jù)。這不就是之前講的數(shù)字簽名的內(nèi)容么？而實(shí)際情況中，就是通過CA證書來處理這個(gè)問題的。

Q：那這個(gè)CA證書是怎么驗(yàn)證的呢？

A：請(qǐng)看下面的CA證書的分析。

回歸之前的分析，我們的問題點(diǎn)卡在了“服務(wù)器發(fā)送給客戶端的數(shù)據(jù)是如何保證的呢”。對(duì)吧。實(shí)際上在協(xié)商通信的過程中，服務(wù)端會(huì)先給客戶端下發(fā)證書信息，這個(gè)證書信息里面會(huì)包含非對(duì)稱加密的公鑰。但是考慮一個(gè)問題，如何保證這個(gè)公鑰就是客戶端要的公鑰呢？或者說怎么保證這個(gè)證書就是真實(shí)的證書，而不是被篡改假冒的證書。只有驗(yàn)證了這一步，客戶端才完全信賴服務(wù)端，才給服務(wù)器發(fā)消息，也才接受服務(wù)器的消息。這時(shí)候就只需要一套公鑰和私鑰客戶端和服務(wù)端就可以通信了。

Q：那客戶端如何驗(yàn)證服務(wù)端下發(fā)的證書和公鑰是正確的呢？

A：先換個(gè)概念，將證書里面的公鑰假設(shè)為一串?dāng)?shù)據(jù)。要驗(yàn)證這個(gè)數(shù)據(jù)，只需要提供這串?dāng)?shù)據(jù)的簽名以及加密這段數(shù)據(jù)的簽名的私鑰對(duì)應(yīng)的公鑰就可以了，如下圖框框所示。

Q：那這樣子又有另外的一個(gè)問題產(chǎn)生了怎么去驗(yàn)證 這段數(shù)據(jù)的簽名的私鑰對(duì)應(yīng)的公鑰 了？

A：同樣的，也是需要提供對(duì)應(yīng)的簽名和對(duì)應(yīng)簽名的私鑰對(duì)應(yīng)的公鑰。

Q：但是這樣子下去就會(huì)變成一個(gè)循環(huán)了，怎么辦？

其實(shí)在這里還會(huì)有一個(gè)場(chǎng)景問題：第三方簽發(fā)機(jī)構(gòu)不可能只給你一家公司制作證書，它也可能會(huì)給中間人這樣有壞心思的公司發(fā)放證書。這樣的，中間人就有機(jī)會(huì)對(duì)你的證書進(jìn)行調(diào)包，客戶端在這種情況下是無法分辨出是接收的是你的證書，還是中間人的。因?yàn)椴徽撝虚g人，還是你的證書，都能使用第三方簽發(fā)機(jī)構(gòu)的公鑰進(jìn)行解密。

A：是的，為處理這個(gè)問題，就需要講一個(gè)根證書的東西。先舉個(gè)例子：假設(shè)你是HR，你手上拿到候選人的學(xué)歷證書，證書上寫了持證人，頒發(fā)機(jī)構(gòu)，頒發(fā)時(shí)間等等，同時(shí)證書上，還寫有一個(gè)最重要的：證書編號(hào)！我們?cè)趺磋b別這張證書是的真?zhèn)文兀恐灰弥@個(gè)證書編號(hào)上相關(guān)機(jī)構(gòu)去查，如果證書上的持證人與現(xiàn)實(shí)的這個(gè)候選人一致，同時(shí)證書編號(hào)也能對(duì)應(yīng)上，那么就說明這個(gè)證書是真實(shí)的。同樣的，Https請(qǐng)求驗(yàn)證時(shí)，會(huì)用到手機(jī)操作系統(tǒng)內(nèi)置的根證書去驗(yàn)證這個(gè)證書的真?zhèn)蔚摹?/p>

到這里就簡(jiǎn)要分析完了證書的驗(yàn)證過程。證書會(huì)包含很多信息，包括服務(wù)器公鑰，服務(wù)器名字，服務(wù)器地區(qū)等等信息。這個(gè)是沒法篡改的。其中對(duì)Https連接來說最重要的就是服務(wù)器的公鑰。

之前學(xué)習(xí)完TCP的連接過程，現(xiàn)在我們開始來嘮嘮Https連接。什么是Https連接呢？準(zhǔn)確來說就是SSL/TLS加解密層的連接。

大致的建立流程：

詳細(xì)的建立流程：

客戶端MAC secret，服務(wù)端MAC secret的主要作用：用來認(rèn)證這個(gè)消息是正確的，完整的，解決對(duì)稱加密方式?jīng)]法驗(yàn)證消息的缺點(diǎn)。

至此完整的Https在TLS層連接過程分析完畢。

如果覺得我的文章對(duì)你有幫助，請(qǐng)隨意贊賞。您的支持將鼓勵(lì)我繼續(xù)創(chuàng)作！

Android開發(fā)：網(wǎng)絡(luò)請(qǐng)求延遲下使用loading，緩解尷尬~~~

1.在所需xml文件布局下添加以下內(nèi)容

2.所需文件在drawable下生成anim_loading.xml文件

android開發(fā)中常用的網(wǎng)絡(luò)連接方式有哪些

告訴你幾個(gè)代碼把，這些都是連接方式：

Activity.startActivities() 常用于在應(yīng)用程序中間啟動(dòng)其他的Activity.

TextUtils.isEmpty() 簡(jiǎn)單的工具類,用于檢測(cè)是否為空

Html.fromHtml() 用于生成一個(gè)Html,參數(shù)可以是一個(gè)字符串.個(gè)人認(rèn)為它不是很快,所以我不怎么經(jīng)常去用.（我說不經(jīng)常用它是為了重點(diǎn)突出這句話：請(qǐng)多手動(dòng)構(gòu)建 Spannable 來替換 Html.fromHtml），但是它對(duì)渲染從 web 上獲取的文字還是很不錯(cuò)的。

TextView.setError() 在驗(yàn)證用戶輸入的時(shí)候很棒

Build.VERSION_CODES 這個(gè)標(biāo)明了當(dāng)前的版本號(hào),在處理兼容性問題的時(shí)候經(jīng)常會(huì)用到.點(diǎn)進(jìn)去可以看到各個(gè)版本的不同特性

Log.getStackTraceString() 方便的日志類工具,方法Log.v()、Log.d()、Log.i()、Log.w()和Log.e()都是將信息打印到LogCat中，有時(shí)候需要將出錯(cuò)的信息插入到數(shù)據(jù)庫或一個(gè)自定義的日志文件中，那么這種情況就需要將出錯(cuò)的信息以字符串的形式返回來，也就是使用static String getStackTraceString(Throwable tr)方法的時(shí)候.

LayoutInflater.from() 顧名思義,用于Inflate一個(gè)layout,參數(shù)是layout的id.這個(gè)經(jīng)常寫Adapter的人會(huì)用的比較多.

ViewConfiguration.getScaledTouchSlop() 使用 ViewConfiguration 中提供的值以保證所有觸摸的交互都是統(tǒng)一的。這個(gè)方法獲取的值表示:用戶的手滑動(dòng)這個(gè)距離后,才判定為正在進(jìn)行滑動(dòng).當(dāng)然這個(gè)值也可以自己來決定.但是為了一致性,還是使用標(biāo)準(zhǔn)的值較好.

PhoneNumberUtils.convertKeypadLettersToDigits 顧名思義.將字母轉(zhuǎn)換為數(shù)字,類似于T9輸入法,

Context.getCacheDir() 獲取緩存數(shù)據(jù)文件夾的路徑,很簡(jiǎn)單但是知道的人不多,這個(gè)路徑通常在SD卡上(這里的SD卡指的是廣義上的SD卡,包括外部存儲(chǔ)和內(nèi)部存儲(chǔ))Adnroid/data/您的應(yīng)用程序包名/cache/ 下面.測(cè)試的時(shí)候,可以去這里面看是否緩存成功.緩存在這里的好處是:不用自己再去手動(dòng)創(chuàng)建文件夾,不用擔(dān)心用戶把自己創(chuàng)建的文件夾刪掉,在應(yīng)用程序卸載的時(shí)候,這里會(huì)被清空,使用第三方的清理工具的時(shí)候,這里也會(huì)被清空.

ArgbEvaluator 用于處理顏色的漸變。就像 Chris Banes 說的一樣，這個(gè)類會(huì)進(jìn)行很多自動(dòng)裝箱的操作，所以最好還是去掉它的邏輯自己去實(shí)現(xiàn)它。這個(gè)沒用過,不明其所以然,回頭再補(bǔ)充.

ContextThemeWrapper 方便在運(yùn)行的時(shí)候修改主題.

Space space是Android 4.0中新增的一個(gè)控件，它實(shí)際上可以用來分隔不同的控件，其中形成一個(gè)空白的區(qū)域.這是一個(gè)輕量級(jí)的視圖組件，它可以跳過Draw，對(duì)于需要占位符的任何場(chǎng)景來說都是很棒的。

ValueAnimator.reverse() 這個(gè)方法可以很順利地取消正在運(yùn)行的動(dòng)畫.我超喜歡.

DateUtils.formatDateTime() 用來進(jìn)行區(qū)域格式化工作，輸出格式化和本地化的時(shí)間或者日期。

AlarmManager.setInexactRepeating 通過鬧鈴分組的方式省電，即使你只調(diào)用了一個(gè)鬧鐘，這也是一個(gè)好的選擇，（可以確保在使用完畢時(shí)自動(dòng)調(diào)用 AlarmManager.cancel ()。原文說的比較抽象，這里詳細(xì)說一下:setInexactRepeating指的是設(shè)置非準(zhǔn)確鬧鐘，使用方法:alarmManager.setInexactRepeating(AlarmManager.RTC， startTime，intervalL， pendingIntent)，非準(zhǔn)確鬧鐘只能保證大致的時(shí)間間隔，但是不一定準(zhǔn)確，可能出現(xiàn)設(shè)置間隔為30分鐘，但是實(shí)際上一次間隔20分鐘，另一次間隔40分鐘。它的最大的好處是可以合并鬧鐘事件，比如間隔設(shè)置每30分鐘一次，不喚醒休眠，在休眠8小時(shí)后已經(jīng)積累了16個(gè)鬧鐘事件，而在手機(jī)被喚醒的時(shí)候，非準(zhǔn)時(shí)鬧鐘可以把16個(gè)事件合并為一個(gè)， 所以這么看來，非準(zhǔn)時(shí)鬧鐘一般來說比較節(jié)約能源。

Formatter.formatFileSize() 一個(gè)區(qū)域化的文件大小格式化工具。通俗來說就是把大小轉(zhuǎn)換為MB，G，KB之類的字符串。

ActionBar.hide()/.show() 顧名思義，隱藏和顯示ActionBar，可以優(yōu)雅地在全屏和帶Actionbar之間轉(zhuǎn)換。

Linkify.addLinks() 在Text上添加鏈接。很實(shí)用。

StaticLayout 在自定義 View 中渲染文字的時(shí)候很實(shí)用。

Activity.onBackPressed() 很方便的管理back鍵的方法，有時(shí)候需要自己控制返回鍵的事件的時(shí)候，可以重寫一下。比如加入 “點(diǎn)兩下back鍵退出” 功能。

GestureDetector 用來監(jiān)聽和相應(yīng)對(duì)應(yīng)的手勢(shì)事件，比如點(diǎn)擊，長(zhǎng)按，慢滑動(dòng)，快滑動(dòng)，用起來很簡(jiǎn)單，比你自己實(shí)現(xiàn)要方便許多。

DrawFilter 可以讓你在不調(diào)用onDrew方法的情況下，操作canvas，比了個(gè)如，你可以在創(chuàng)建自定義 View 的時(shí)候設(shè)置一個(gè) DrawFilter，給父 View 里面的所有 View 設(shè)置反別名。

ActivityManager.getMemoryClass() 告訴你你的機(jī)器還有多少內(nèi)存，在計(jì)算緩存大小的時(shí)候會(huì)比較有用.

ViewStub 它是一個(gè)初始化不做任何事情的 View，但是之后可以載入一個(gè)布局文件。在慢加載 View 中很適合做占位符。唯一的缺點(diǎn)就是不支持標(biāo)簽，所以如果你不太小心的話，可能會(huì)在視圖結(jié)構(gòu)中加入不需要的嵌套。

SystemClock.sleep() 這個(gè)方法在保證一定時(shí)間的 sleep 時(shí)很方便，通常我用來進(jìn)行 debug 和模擬網(wǎng)絡(luò)延時(shí)。

DisplayMetrics.density 這個(gè)方法你可以獲取設(shè)備像素密度，大部分時(shí)候最好讓系統(tǒng)來自動(dòng)進(jìn)行縮放資源之類的操作，但是有時(shí)候控制的效果會(huì)更好一些.(尤其是在自定義View的時(shí)候).

Android 網(wǎng)絡(luò)基礎(chǔ)之網(wǎng)絡(luò)協(xié)議篇

學(xué)習(xí)一門技術(shù)或者看一篇文章最好的方式就是帶著問題去學(xué)習(xí)，這樣才能在過程中有茅塞頓開、燈火闌珊的感覺，記憶也會(huì)更深刻。

對(duì)于網(wǎng)絡(luò)的分層，有的分為七層，有的分為四層，而我認(rèn)為五層模型是最容易理解的網(wǎng)絡(luò)模型。

如上圖所示，從上往下依次為應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、鏈接層、實(shí)體層。

越往上，就越靠近用戶；越往下，則越靠近硬件。

大家都遵守的規(guī)則，就叫做"協(xié)議"（protocol）。

互聯(lián)網(wǎng)的每一層，都定義了很多協(xié)議。這些協(xié)議的總稱，就叫做"互聯(lián)網(wǎng)協(xié)議"（Internet Protocol Suite），它們是互聯(lián)網(wǎng)的核心。

我們從最下面一層開始分析，電腦要聯(lián)網(wǎng)，第一件事要做什么？就是用電纜、光纜、雙絞線等方式將電腦連接起來，這就是實(shí)體層。

實(shí)體層就是就是把電腦連接起來的物理手段。它主要規(guī)定了網(wǎng)絡(luò)的一些電氣特性，作用是負(fù)責(zé)傳送 0 和 1 的電信號(hào)。

"鏈接層"在"實(shí)體層"的上方，確定了 0 和 1 的分組方式。（多少個(gè)電信號(hào)算一組？每個(gè)信號(hào)位有何意義？）

以太網(wǎng)規(guī)定，一組電信號(hào)構(gòu)成一個(gè)數(shù)據(jù)包，叫做"幀"（Frame）。每一幀分成兩個(gè)部分：標(biāo)頭（Head）和數(shù)據(jù)（Data）。

"標(biāo)頭"包含數(shù)據(jù)包的一些說明項(xiàng)，比如發(fā)送者、接受者、數(shù)據(jù)類型等等；"數(shù)據(jù)"則是數(shù)據(jù)包的具體內(nèi)容。

"標(biāo)頭"的長(zhǎng)度，固定為 18 字節(jié)。"數(shù)據(jù)"的長(zhǎng)度，最短為 46 字節(jié)，最長(zhǎng)為 1500 字節(jié)。因此，整個(gè)"幀"最短為 64 字節(jié)，最長(zhǎng)為 1518 字節(jié)。如果數(shù)據(jù)很長(zhǎng)，就必須分割成多個(gè)幀進(jìn)行發(fā)送。

以太網(wǎng)規(guī)定，連入網(wǎng)絡(luò)的所有設(shè)備，都必須具有"網(wǎng)卡"接口。數(shù)據(jù)包必須是從一塊網(wǎng)卡，傳送到另一塊網(wǎng)卡。網(wǎng)卡的地址，就是數(shù)據(jù)包的發(fā)送地址和接收地址，這叫做 MAC 地址。

每塊網(wǎng)卡出廠的時(shí)候，都有一個(gè)全世界獨(dú)一無二的 MAC 地址，長(zhǎng)度是 48 個(gè)二進(jìn)制位，通常用 12 個(gè)十六進(jìn)制數(shù)表示。

前 6 個(gè)十六進(jìn)制數(shù)是廠商編號(hào)，后 6 個(gè)是該廠商的網(wǎng)卡流水號(hào)。有了 MAC 地址，就可以定位網(wǎng)卡和數(shù)據(jù)包的路徑了。

以太網(wǎng)采用了一種很"原始"的方式，它不是把數(shù)據(jù)包準(zhǔn)確送到接收方，而是向本網(wǎng)絡(luò)內(nèi)所有計(jì)算機(jī)發(fā)送，讓每臺(tái)計(jì)算機(jī)自己判斷，是否為接收方。

同一個(gè)子網(wǎng)絡(luò)的計(jì)算機(jī)都會(huì)收到這個(gè)包。它們讀取這個(gè)包的"標(biāo)頭"，找到接收方的 MAC 地址，然后與自身的 MAC 地址相比較，如果兩者相同，就接受這個(gè)包，做進(jìn)一步處理，否則就丟棄這個(gè)包。這種發(fā)送方式就叫做"廣播"（broadcasting）。

有了數(shù)據(jù)包的定義、網(wǎng)卡的 MAC 地址、廣播的發(fā)送方式，"鏈接層"就可以在多臺(tái)計(jì)算機(jī)之間傳送數(shù)據(jù)了。

以太網(wǎng)協(xié)議，依靠 MAC 地址發(fā)送數(shù)據(jù)。這樣做有一個(gè)重大的缺點(diǎn)。以太網(wǎng)采用廣播方式發(fā)送數(shù)據(jù)包，如果兩臺(tái)計(jì)算機(jī)不在同一個(gè)子網(wǎng)絡(luò)，廣播是傳不過去的。這種設(shè)計(jì)是合理的，否則互聯(lián)網(wǎng)上每一臺(tái)計(jì)算機(jī)都會(huì)收到所有包，那會(huì)引起災(zāi)難。

因此，必須找到一種方法，能夠區(qū)分哪些 MAC 地址屬于同一個(gè)子網(wǎng)絡(luò)，哪些不是。如果是同一個(gè)子網(wǎng)絡(luò)，就采用廣播方式發(fā)送，否則就采用"路由"方式發(fā)送。（"路由"的意思，就是指如何向不同的子網(wǎng)絡(luò)分發(fā)數(shù)據(jù)包）

“網(wǎng)絡(luò)層”的作用是引進(jìn)一套新的地址，使得我們能夠區(qū)分不同的計(jì)算機(jī)是否屬于同一個(gè)子網(wǎng)絡(luò)。這套地址就叫做"網(wǎng)絡(luò)地址"，簡(jiǎn)稱"網(wǎng)址"。

"網(wǎng)絡(luò)層"出現(xiàn)以后，每臺(tái)計(jì)算機(jī)有了兩種地址，一種是 MAC 地址，另一種是網(wǎng)絡(luò)地址。網(wǎng)絡(luò)地址幫助我們確定計(jì)算機(jī)所在的子網(wǎng)絡(luò)，MAC 地址則將數(shù)據(jù)包送到該子網(wǎng)絡(luò)中的目標(biāo)網(wǎng)卡。因此，從邏輯上可以推斷，必定是先處理網(wǎng)絡(luò)地址，然后再處理 MAC 地址。

規(guī)定網(wǎng)絡(luò)地址的協(xié)議，叫做 IP 協(xié)議。它所定義的地址，就被稱為 IP 地址。習(xí)慣上，我們用分成四段的十進(jìn)制數(shù)表示IP地址，從 0.0.0.0 一直到 255.255.255.255。

IP 地址的前一部分代表網(wǎng)絡(luò)，后一部分代表主機(jī)。比如，IP 地址 172.16.254.1，這是一個(gè) 32 位的地址，假定它的網(wǎng)絡(luò)部分是前 24 位（172.16.254），那么主機(jī)部分就是后 8 位（最后的那個(gè)1）。處于同一個(gè)子網(wǎng)絡(luò)的電腦，它們 IP 地址的網(wǎng)絡(luò)部分必定是相同的，也就是說 172.16.254.2 應(yīng)該與 172.16.254.1 處在同一個(gè)子網(wǎng)絡(luò)。

但是，問題在于單單從 IP 地址，我們無法判斷網(wǎng)絡(luò)部分。還是以 172.16.254.1 為例，它的網(wǎng)絡(luò)部分，到底是前 24 位，還是前 16 位，甚至前 28 位，從 IP 地址上是看不出來的。

"子網(wǎng)掩碼" ，就是表示子網(wǎng)絡(luò)特征的一個(gè)參數(shù)。它在形式上等同于 IP 地址，也是一個(gè) 32 位二進(jìn)制數(shù)字，它的網(wǎng)絡(luò)部分全部為 1，主機(jī)部分全部為 0。比如，IP 地址 172.16.254.1，如果已知網(wǎng)絡(luò)部分是前 24 位，主機(jī)部分是后 8 位，那么子網(wǎng)絡(luò)掩碼就是 11111111.11111111.11111111.00000000，寫成十進(jìn)制就是 255.255.255.0。

知道 "子網(wǎng)掩碼" ，我們就能判斷，任意兩個(gè) IP 地址是否處在同一個(gè)子網(wǎng)絡(luò)。方法是將兩個(gè) IP 地址與子網(wǎng)掩碼分別進(jìn) 行 AND 運(yùn)算（兩個(gè)數(shù)位都為 1，運(yùn)算結(jié)果為 1，否則為 0），然后比較結(jié)果是否相同，如果是的話，就表明它們?cè)谕粋€(gè)子網(wǎng)絡(luò)中，否則就不是。

因?yàn)?IP 數(shù)據(jù)包是放在以太網(wǎng)數(shù)據(jù)包里發(fā)送的，所以我們必須同時(shí)知道兩個(gè)地址，一個(gè)是對(duì)方的 MAC 地址，另一個(gè)是對(duì)方的 IP 地址。通常情況下，對(duì)方的IP地址是已知的（后文會(huì)解釋），但是我們不知道它的 MAC 地址。

所以，我們需要一種機(jī)制，能夠從 IP 地址得到 MAC 地址。

這里又可以分成兩種情況。第一種情況，如果兩臺(tái)主機(jī)不在同一個(gè)子網(wǎng)絡(luò)，那么事實(shí)上沒有辦法得到對(duì)方的 MAC 地址，只能把數(shù)據(jù)包傳送到兩個(gè)子網(wǎng)絡(luò)連接處的"網(wǎng)關(guān)"（gateway），讓網(wǎng)關(guān)去處理。

第二種情況，如果兩臺(tái)主機(jī)在同一個(gè)子網(wǎng)絡(luò)，那么我們可以用 ARP 協(xié)議，得到對(duì)方的 MAC 地址。ARP 協(xié)議也是發(fā)出一個(gè)數(shù)據(jù)包（包含在以太網(wǎng)數(shù)據(jù)包中），其中包含它所要查詢主機(jī)的IP地址，在對(duì)方的 MAC 地址這一欄，填的是 FF:FF:FF:FF:FF:FF，表示這是一個(gè)"廣播"地址。它所在子網(wǎng)絡(luò)的每一臺(tái)主機(jī)，都會(huì)收到這個(gè)數(shù)據(jù)包，從中取出 IP 地址，與自身的 IP 地址進(jìn)行比較。如果兩者相同，都做出回復(fù)，向?qū)Ψ綀?bào)告自己的 MAC 地址，否則就丟棄這個(gè)包。

有了 ARP 協(xié)議之后，我們就可以得到同一個(gè)子網(wǎng)絡(luò)內(nèi)的主機(jī) MAC 地址，可以把數(shù)據(jù)包發(fā)送到任意一臺(tái)主機(jī)之上了。

"端口"（port） 表示這個(gè)數(shù)據(jù)包到底供哪個(gè)程序（進(jìn)程）使用。

"傳輸層"的功能，就是建立"端口到端口"的通信。相比之下，"網(wǎng)絡(luò)層"的功能是建立"主機(jī)到主機(jī)"的通信。只要確定主機(jī)和端口，我們就能實(shí)現(xiàn)程序之間的交流。

在數(shù)據(jù)包中加入端口信息，這就需要新的協(xié)議。最簡(jiǎn)單的實(shí)現(xiàn)叫做 UDP 協(xié)議，它的格式幾乎就是在數(shù)據(jù)前面，加上端口號(hào)。

UDP 數(shù)據(jù)包，也是由"標(biāo)頭"和"數(shù)據(jù)"兩部分組成。

"標(biāo)頭"部分主要定義了發(fā)出端口和接收端口，"數(shù)據(jù)"部分就是具體的內(nèi)容。

UDP 數(shù)據(jù)包非常簡(jiǎn)單，"標(biāo)頭"部分一共只有8個(gè)字節(jié)，總長(zhǎng)度不超過 65,535 字節(jié)，正好放進(jìn)一個(gè) IP 數(shù)據(jù)包。

UDP 協(xié)議的優(yōu)點(diǎn)是比較簡(jiǎn)單，容易實(shí)現(xiàn)，但是缺點(diǎn)是可靠性較差，一旦數(shù)據(jù)包發(fā)出，無法知道對(duì)方是否收到。

為了解決這個(gè)問題，提高網(wǎng)絡(luò)可靠性，TCP 協(xié)議就誕生了。這個(gè)協(xié)議非常復(fù)雜，但可以近似認(rèn)為，它就是有確認(rèn)機(jī)制的 UDP 協(xié)議，每發(fā)出一個(gè)數(shù)據(jù)包都要求確認(rèn)。如果有一個(gè)數(shù)據(jù)包遺失，就收不到確認(rèn)，發(fā)出方就知道有必要重發(fā)這個(gè)數(shù)據(jù)包了。

因此，TCP 協(xié)議能夠確保數(shù)據(jù)不會(huì)遺失。它的缺點(diǎn)是過程復(fù)雜、實(shí)現(xiàn)困難、消耗較多的資源。

TCP 數(shù)據(jù)包和 UDP 數(shù)據(jù)包一樣，都是內(nèi)嵌在 IP 數(shù)據(jù)包的"數(shù)據(jù)"部分。TCP 數(shù)據(jù)包沒有長(zhǎng)度限制，理論上可以無限長(zhǎng)，但是為了保證網(wǎng)絡(luò)的效率，通常 TCP 數(shù)據(jù)包的長(zhǎng)度不會(huì)超過IP數(shù)據(jù)包的長(zhǎng)度，以確保單個(gè) TCP 數(shù)據(jù)包不必再分割。

"應(yīng)用層"的作用，就是規(guī)定應(yīng)用程序的數(shù)據(jù)格式。

舉例來說，TCP 協(xié)議可以為各種各樣的程序傳遞數(shù)據(jù)，比如 Email、WWW、FTP 等等。那么，必須有不同協(xié)議規(guī)定電子郵件、網(wǎng)頁、FTP 數(shù)據(jù)的格式，這些應(yīng)用程序協(xié)議就構(gòu)成了"應(yīng)用層"。

[圖片上傳失敗...(image-ebc671-1558268545157)]

至此，整個(gè)互聯(lián)網(wǎng)的五層結(jié)構(gòu)，自下而上全部講完了。

文章已經(jīng)讀到末尾了，不知道最初的幾個(gè)問題你都會(huì)了嗎？如果不會(huì)的話？可以再針對(duì)不會(huì)的問題進(jìn)行精讀哦！答案都在文中，相信你肯定可以解決的！

Android 網(wǎng)絡(luò)編程之Socket理解

TCP/IP（Transmission Control Protocol/Internet Protocol，傳輸控制協(xié)議/網(wǎng)際協(xié)議）是指能夠在多個(gè)不同網(wǎng)絡(luò)間實(shí)現(xiàn)信息傳輸?shù)膮f(xié)議簇。TCP/IP協(xié)議不僅僅指的是 TCP 和 IP 兩個(gè)協(xié)議，而是指一個(gè)由 FTP 、 SMTP 、TCP、 UDP 、IP等協(xié)議構(gòu)成的協(xié)議簇， 只是因?yàn)樵赥CP/IP協(xié)議中TCP協(xié)議和IP協(xié)議最具代表性，所以被稱為TCP/IP協(xié)議。

互聯(lián)網(wǎng)進(jìn)行通信時(shí)，需要相應(yīng)的網(wǎng)絡(luò)協(xié)議，TCP/IP 原本就是為使用互聯(lián)網(wǎng)而開發(fā)制定的協(xié)議族。因此，互聯(lián)網(wǎng)的協(xié)議就是 TCP/IP，TCP/IP 就是互聯(lián)網(wǎng)的協(xié)議。所以不要簡(jiǎn)單認(rèn)為TCP/IP協(xié)議就是我們的網(wǎng)絡(luò)請(qǐng)求http拿點(diǎn)東西，它是一個(gè)統(tǒng)稱。

socket 的誕生是為了應(yīng)用程序能夠更方便的將數(shù)據(jù)經(jīng)由傳輸層來傳輸，所以它本質(zhì)上就是對(duì) TCP/IP 的運(yùn)用進(jìn)行了一層封裝，然后應(yīng)用程序直接調(diào)用 socket API 即可進(jìn)行通信。那么它是如何工作的呢？它分為 2 個(gè)部分，服務(wù)端需要建立 socket 來監(jiān)聽指定的地址，然后等待客戶端來連接。而客戶端則需要建立 socket 并與服務(wù)端的 socket 地址進(jìn)行連接。

有圖可以看出Socket是應(yīng)用層跟傳輸層的橋梁，應(yīng)用層通過socket api提供的方法來讓數(shù)據(jù)流轉(zhuǎn)到傳輸層。

網(wǎng)頁名稱：android開發(fā)網(wǎng)絡(luò),安卓網(wǎng)絡(luò)開發(fā)
網(wǎng)站地址：http://chinadenli.net/article15/dsiicgi.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站建設(shè)、微信公眾號(hào)、網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)公司、網(wǎng)站導(dǎo)航

廣告

聲明：本網(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)