2020 Android 大廠面試（二）網絡和安全機制 含 參考答案

時間  2019-12-18
標籤 android 大廠 面試 網絡 安全 機制 參考 答案 欄目 Android 简体版
原文   原文鏈接

2、網絡和安全機制html

1.網絡框架對比和源碼分析
2.本身去設計網絡請求框架，怎麼作？
3.網絡請求緩存處理，okhttp如何處理網絡緩存的
4.從網絡加載一個10M的圖片，說下注意事項
5.TCP的3次握手和四次揮手
6.TCP與UDP的區別
7.TCP與UDP的應用
8.HTTP協議
9.HTTP1.0與2.0的區別
10.HTTP報文結構
11.HTTP與HTTPS的區別以及如何實現安全性
12.如何驗證證書的合法性?
13.https中哪裏用了對稱加密，哪裏用了非對稱加密，對加密算法（如RSA）等是否有了解?
14.client如何肯定本身發送的消息被server收到?
15.談談你對WebSocket的理解
16.WebSocket與socket的區別
17.談談你對安卓簽名的理解。
18.請解釋安卓爲啥要加簽名機制?
19.視頻加密傳輸
20.App 是如何沙箱化，爲何要這麼作？
21.權限管理系統（底層的權限是如何進行 grant 的）？
複製代碼

參考答案：java

1.網絡框架對比和源碼分析

blog.csdn.net/github_3713…android

Volleygit

特色：github

  • 基於 HttpURLConnection
  • 封裝Url圖片加載框架，支持圖片加載
  • 有緩存
  • Activity和生命週期的聯動，Activity結束時取消在此Activity中調用的全部網絡請求

場景：web

  • 適合傳輸量小，數據請求頻繁的的場景
  • 不能進行大量數據操做，如上傳下載，由於Volley的Request和Response放到byte[]中

OkHttp算法

特色：數據庫

  • 基於 NIO 和 Okio，請求處理速度更快
  • IO 是阻塞式；NIO是非阻塞式；Okio （Square）基於兩者的更高效的數據流庫

IO 面向流 Steam，NIO 面向緩衝區 Buffer IO 阻塞，NIO 非阻塞segmentfault

NIO狀況下，一個線程能夠處理多個通道的讀取和寫入，更充分的利用線程資源。windows

適用場景

  • IO適合於連接數量不大,可是每一個連接須要發送/接收的數據量很大,須要長時間連續處理;

  • NIO更適合於同時存在海量連接,可是每一個連接單次發送/接收的數據量較小的情形.好比聊天服務器.海量連接可是單個連接單次數據較小

"Accept-Encoding","gzip" "Content-Encoding","gzip"

Content-Encoding: gzip：代表body是gzip過的數據
Content-Length:117：表示body gzip壓縮後的數據大小，便於客戶端使用。
Transfer-Encoding: chunked：分塊傳輸編碼
複製代碼

Retrofit

特色：

  • 基於OkHttp
  • 經過註解配置請求
  • 性能最好，處理最快
  • 解析數據須要使用統一的Convert
  • 易與其餘框架RxJava聯合使用

場景：

  • 優先使用，項目中由 RxJava ，後臺 API 遵循 Restful 風格

2.本身去設計網絡請求框架，怎麼作？

github.com/sucese/andr…

OkHttpClient okHttpClient = new OkHttpClient.Builder()
        .build();
Request request = new Request.Builder()
        .url(url)
        .build();
okHttpClient.newCall(request).enqueue(new Callback() {
    @Override
    public void onFailure(Call call, IOException e) {
    }

    @Override
    public void onResponse(Call call, Response response) throws IOException {

    }
});
複製代碼

  • 網絡配置層 重定向 Header拼接層 Http緩存層 連接層 數據響應層
  • OkHttpClient Call Request RequsetBody Response ResponseBody Interceptor StreamAllocation RouteSelector RouteDatabase

Dispatcher是一個任務調度器，它內部維護了三個雙端隊列：

readyAsyncCalls：準備運行的異步請求
runningAsyncCalls：正在運行的異步請求
runningSyncCalls：正在運行的同步請求
複製代碼

Interceptor將網絡請求、緩存、透明壓縮等功能統一了起來，它的實現採用責任鏈模式，各司其職， 每一個功能都是一個Interceptor，上一級處理完成之後傳遞給下一級，它們最後鏈接成了一個Interceptor.Chain。它們的功能以下：

RetryAndFollowUpInterceptor：負責重定向。
BridgeInterceptor：負責把用戶構造的請求轉換爲發送給服務器的請求，把服務器返回的響應轉換爲對用戶友好的響應。
CacheInterceptor：負責讀取緩存以及更新緩存。
ConnectInterceptor：負責與服務器創建鏈接。
CallServerInterceptor：負責從服務器讀取響應的數據。
複製代碼

BridgeInterceptor方法主要是針對Header作了一些處理，這裏主要提一下"Accept-Encoding", "gzip"，關於它有如下幾點須要注意：

開發者沒有添加Accept-Encoding時，自動添加Accept-Encoding: gzip
自動添加Accept-Encoding，會對request，response進行自動解壓
手動添加Accept-Encoding，不負責解壓縮
自動解壓時移除Content-Length，因此上層Java代碼想要contentLength時爲-1
自動解壓時移除Content-Encoding
自動解壓時，若是是分塊傳輸編碼，Transfer-Encoding: chunked不受影響。
複製代碼

CacheInterceptor

讀取候選緩存，具體如何讀取的咱們下面會講。
建立緩存策略，強制緩存、對比緩存等，關於緩存策略咱們下面也會講。
根據策略，不使用網絡，又沒有緩存的直接報錯，並返回錯誤碼504。
根據策略，不使用網絡，有緩存的直接返回。
前面兩個都沒有返回，繼續執行下一個Interceptor，即ConnectInterceptor。
接收到網絡結果，若是響應code式304，則使用緩存，返回緩存結果。
讀取網絡結果。
對數據進行緩存。
返回網絡讀取的結果。
複製代碼

ConnectInterceptor用來完成鏈接。而真正的鏈接在RealConnect中實現，鏈接由鏈接池ConnectPool來管理，鏈接池最多保 持5個地址的鏈接keep-alive，每一個keep-alive時長爲5分鐘，並有異步線程清理無效的鏈接。

整個流程以下：

查找是否有完整的鏈接可用：
    Socket沒有關閉
    輸入流沒有關閉
    輸出流沒有關閉
    Http2鏈接沒有關閉
鏈接池中是否有可用的鏈接，若是有則可用。
若是沒有可用鏈接，則本身建立一個。
開始TCP鏈接以及TLS握手操做。
將新建立的鏈接加入鏈接池。
複製代碼

cleanup()整個方法的流程以下所示：

查詢此鏈接內部的StreanAllocation的引用數量。
標記空閒鏈接。
若是空閒鏈接超過5個或者keepalive時間大於5分鐘，則將該鏈接清理掉。
返回此鏈接的到期時間，供下次進行清理。
所有都是活躍鏈接，5分鐘時候再進行清理。
沒有任何鏈接，跳出循環。
關閉鏈接，返回時間0，當即再次進行清理。
複製代碼

Expires Http 1.0 絕對過時時間

Cache-Control Http 1.1 相對過時時間

If-Modified-Since 請求 header

Last-Modified 響應 header 做爲下次的 If-Modified-Since

If-None-Match 請求 header

ETag 響應 header 做爲下次的 If-None-Match

3.網絡請求緩存處理，okhttp如何處理網絡緩存的

CacheInterceptor

OKHttp3(支持Retrofit)的網絡數據緩存Interceptor攔截器

讀取候選緩存，具體如何讀取的咱們下面會講。
建立緩存策略，強制緩存、對比緩存等，關於緩存策略咱們下面也會講。
根據策略，不使用網絡，又沒有緩存的直接報錯，並返回錯誤碼504。
根據策略，不使用網絡，有緩存的直接返回。
前面兩個都沒有返回，繼續執行下一個Interceptor，即ConnectInterceptor。
接收到網絡結果，若是響應code式304，則使用緩存，返回緩存結果。
讀取網絡結果。
對數據進行緩存。
返回網絡讀取的結果。
複製代碼

4.從網絡加載一個10M的圖片，說下注意事項

blog.csdn.net/github_3713…

Bitmap.Options inJustDecodeBounds inSampleSize

ARGB_4444 RGB_565

補圖

分塊加載

使用LruCache

sizeOf()、entryRemoved()

手勢處理

ScaleGestureDetector GestureDetector

前者用於處理縮放手勢，後者用於處理其他手勢，如移動，快速滑動，點擊，雙擊，長按等。

ScaleGestureDetector專門處理縮放手勢，其比較重要的方法是onScale(ScaleGestureDetector detector)，當縮放時會不停地回調這個方法，須要注意的一點是detector.getScaleFactor()獲取到的縮放比例是相對上一次的

5.TCP的3次握手和四次揮手

blog.csdn.net/whuslei/art…

SYN--SYN ACK-ACK

SYN=1 seq=client_isn
SYN=1 seq=server_isn ack=client_isn+1
SYN=0 seq=client_isn+1 ack=server_isn+1

seq 爲自身序列 ack 爲對方序列+1
複製代碼

FIN--ACK--FIN-ACK

【問題1】爲何鏈接的時候是三次握手，關閉的時候倒是四次握手？ 答：由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。可是關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，因此只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手。

【問題2】爲何TIME_WAIT狀態須要通過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

答：雖然按道理，四個報文都發送完畢，咱們能夠直接進入CLOSE狀態了，可是咱們必須假象網絡是不可靠的，有能夠最後一個ACK丟失。因此TIME_WAIT狀態就是用來重發可能丟失的ACK報文。

6.TCP與UDP的區別

blog.fundebug.com/2019/03/22/…

UDP TCP
是否鏈接 無鏈接 面向鏈接
是否可靠 不可靠傳輸，不使用流量控制和擁塞控制 可靠傳輸，使用流量控制和擁塞控制
鏈接對象個數 支持一對一，一對多，多對一和多對多交互通訊 只能是一對一通訊
傳輸方式 面向報文 面向字節流
首部開銷 首部開銷小，僅8字節 首部最小20字節，最大60字節
適用場景 適用於實時應用（IP電話、視頻會議、直播等） 適用於要求可靠傳輸的應用，例如文件傳輸

7.TCP與UDP的應用

blog.csdn.net/leewccc/art… www.cnblogs.com/liangyc/p/1…

TCP Transmission Contral Protocol UDP User Datagram Protocol

www.cnblogs.com/liangyc/p/1…

區別

面向鏈接VS無鏈接

TCP創建一個鏈接須要3次握手IP數據包，斷開鏈接須要4次握手。 另外斷開鏈接時發起方可能進入TIME_WAIT狀態長達數分鐘（視系統設置，windows通常爲120秒），在此狀態下鏈接（端口）沒法被釋放。 UDP不須要創建鏈接，能夠直接發起。

可靠VS不可靠

TCP利用握手、ACK和重傳機制，udp沒有。
1，校驗和（校驗數據是否損壞）；
2，定時器（分組丟失則重傳）；
3，序列號（用於檢測丟失的分組和重複的分組）；
4，確認應答ACK（接收方告知發送方正確接收分組以及指望的下一個分組）；
5，否認確認（接收方通知發送方未被正確接收的分組）；
6，窗口和流水線（用於增長信道的吞吐量）。（窗口大小：無需等待確認應答而能夠繼續發送數據的最大值）
複製代碼

有序性

TCP利用seq序列號對包進行排序，udp沒有。
複製代碼

面向字節流vs面向報文

面向報文
    面向報文的傳輸方式是應用層交給UDP多長的報文，UDP就照樣發送，即一次發送一個報文。
    所以，應用程序必須選擇合適大小的報文。若報文太長，則IP層須要分片。
    UDP對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界。
    這也就是說，應用層交給UDP多長的報文，UDP就照樣發送，即一次發送一個報文。（一個upd的最大報文長度2^16-1-20-8，20是ip報文頭，8是udp報文頭）
面向字節流
    面向字節流的話，雖然應用程序和TCP的交互是一次一個數據塊（大小不等），但TCP把應用程序當作是一連串的無結構的字節流。
    TCP有一個緩衝，當應用程序傳送的數據塊太長，TCP就能夠把它劃分短一些再傳送。
    若是應用程序一次只發送一個字節，TCP也能夠等待積累有足夠多的字節後再構成報文段發送出去。

tcp有流量控制，udp沒有

tcp的頭部比20bytes，udp8byres
複製代碼

TCP應用場景：

效率要求相對低，但對準確性要求相對高的場景。由於傳輸中須要對數據確認、重發、排序等操做，相比之下效率沒有UDP高。
舉幾個例子：文件傳輸（準確高要求高、可是速度能夠相對慢）、接受郵件、遠程登陸。
複製代碼

UDP應用場景：

效率要求相對高，對準確性要求相對低的場景。
舉幾個例子：QQ聊天、在線視頻、網絡語音電話（即時通信，速度要求高，可是出現偶爾斷續不是太大問題，而且此處徹底不可使用重發機制）、廣播通訊（廣播、多播）。
複製代碼

8.HTTP協議

hit-alibaba.github.io/interview/b…

juejin.im/post/5ad446…

9.HTTP1.0與2.0的區別

juejin.im/entry/5981c…

http 0.9 1991
http 1.0 1996
http 1.1 1999
http 2.0 2015
複製代碼

帶寬：出視頻應用之外，帶寬基本不是問題

延遲： 瀏覽器阻塞 HOL Blocking DNS查詢 DNS Lookup 創建鏈接 Initial Connection

Http1.0 & 1.1

緩存處理
    HTTP1.0中主要使用header裏的If-Modified-Since，Expires來作爲緩存判斷的標準
    HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match
    
帶寬優化及網絡鏈接的使用
    1.1 支持 range 206 Partial Content

錯誤通知的管理
    1.1 新增 24 個錯誤碼，409 Conflict 410 Gone

Host頭處理

長鏈接
    長鏈接 PersistentConnection
    流水線 Pipelining
複製代碼

2012 google SPDY

下降延遲 多路複用 multiplexing 經過多個請求stream共享一個tcp連接
請求優先級 request prioritization
header壓縮
基於https的加密傳輸
服務端推送 server push
複製代碼

HTTP 2.0 性能驚人

http2.akamai.com/demo

大約 4 倍

HTTP2.0和SPDY的區別：

HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強制使用 HTTPS

HTTP2.0 消息頭的壓縮算法採用 HPACK http://http2.github.io/http2-spec/compression.html，
而非 SPDY 採用的 DEFLATE http://zh.wikipedia.org/wiki/DEFLATE
複製代碼

10.HTTP報文結構

zhuanlan.zhihu.com/p/44938050

11.HTTP與HTTPS的區別以及如何實現安全性

blog.fundebug.com/2019/04/26/…

方法1. 對稱加密

沒有密鑰就沒法對密碼解密，反過來講，任何人只要持有密鑰就能解密了。
複製代碼

方法2. 非對稱加密

私有密鑰不能讓其餘任何人知道，而公開密鑰則能夠隨意發佈，任何人均可以得到。
複製代碼

方法3. 對稱加密+非對稱加密(HTTPS採用這種方式)

在交換密鑰環節使用非對稱加密方式，以後的創建通訊交換報文階段則使用對稱加密方式。
發送密文的一方使用對方的公鑰進行加密處理「對稱的密鑰」，而後對方用本身的私鑰解密拿到「對稱的密鑰」，
這樣能夠確保交換的密鑰是安全的前提下，使用對稱加密方式進行通訊。
複製代碼

12.如何驗證證書的合法性?

yiqingfeng.github.io/2019/04/01/…

證書的安全性

  • 證書存在的目的就是避免中間人攻擊，避免發生經典的傳令兵問題
  • 由CA組織承認的根證書Root簽發的
  • DV Digital Verification、OV Organization Verification、EV Extended Verification
  • 證書是須要預裝的，特別是根證書。

證書的校驗

  • 證書是否爲值得信任的有效證書。是否爲信任根（瀏覽器內置有信任的根證書）或信任根的二級證書機構頒發的。是否爲信任根（瀏覽器內置有信任的根證書）或信任根的二級證書機構頒發的。
  • 對方是否持有證書對應的私鑰。驗證方式有兩種：
    • 對方簽名，瀏覽器用證書對簽名進行驗證。
    • 使用證書做爲信封，判斷對方是否可以解開。

校驗證書是否已被吊銷須要和 CA 關聯，其餘都可由瀏覽器完成。驗證證書是否吊銷能夠採用CRL黑名單方式或者OCSP方式。

CRL黑名單就是按期從CA下載一個名單列表，裏面有吊銷的證書序列號，本身在本地比對一下就行。
優勢是效率高。缺點是不實時。
OCSP是實時鏈接CA去驗證，優勢是實時，缺點是效率不高。
複製代碼

以 www.google.com 爲例：

  • 瀏覽器發現協議爲 https，握手拿到 google 的證書，先從系統（window）或瀏覽器內置（Firefox）檢查證書鏈是否正確。
  • 若是驗證失敗則會攔截。
  • 瀏覽器嘗試查CRL(證書吊銷列表)和OCSP(在線證書檢查)。 注意：
    • CA不會直接暴露到外網的，若是須要訪問CA服務器須要使用硬件Token而且多人在場錄像，且只能遠程訪問。OCSP至關於證書數據庫的備份而已經是直接暴露在外網的能夠經過HTTP或者HTTPS訪問。
    • OCSP是一種新技術。部分客戶端可能不支持，僅支持 CRL。
  • 若是發現證書並無被吊銷或者過時則瀏覽器對EV證書會顯示爲綠色，對OV證書則是經過放行。不然彈出通知，該網站不可信。

檢查流程：

  • 客戶端發送信息，帶上支持的SSL或者TLS版本（不一樣瀏覽器支持程* * 度不一樣）。
  • 服務器返回確認使用的加密通訊協議版本以及加密隨機數和CA證書。
  • 瀏覽器驗證證書（存在雙向驗證和單項驗證） -> OCSP或者CRL * 結合自帶truststore。
  • 檢查CA證書的根證書頒發機構是否受瀏覽器信任。
  • 檢查CA證書中的證書吊銷列表，檢查證書是否被吊銷。
  • 檢查CA證書是否在有效期內。
  • 檢查部署CA證書的網站域名與證書頒發的域名是否一致。
  • 瀏覽器覈對該網站是否存在於欺詐網站數據庫中。

13.https中哪裏用了對稱加密，哪裏用了非對稱加密，對加密法（如RSA）等是否有了解?

www.cnblogs.com/xishuai/p/h…

segmentfault.com/a/119000001…

DES Data Encryption Standard
3DES Triple DES
AES Advanced Encryption Standard
複製代碼

我國國密局也制定了本身的對稱加密算法，叫國密算法，SM1（至關於AES）,和SM4(至關於3DES)。

RSA RSA是1977年由羅納德·李維斯特（Ron Rivest）、阿迪·薩莫爾（Adi Shamir）和倫納德·阿德曼（Leonard Adleman）一塊兒提出的。
DSA Digital Signture Algorithm
ECC Elliptic Curves Cryptography

MD5 Message-Digest 5 1992
SHA1 NISTNSA 設計，SHA-1是由美國標準技術局（NIST）頒佈的國家標準，是一種應用最爲普遍的Hash函數算法
HMAC Hash-based Message Authentication Code
複製代碼

AES加密算法的詳細介紹與實現

AES的基本結構

AES爲分組密碼，每組長度相等，每次加密一組數據，直到加密完整個明文。在AES標準規範中，分組長度只能是128位，每一個分組爲16個字節（每一個字節8位）。密鑰的長度可使用128位、192位或256位。密鑰的長度不一樣，推薦加密輪數也不一樣，以下表所示：

AES 密鑰長度（32位比特字) 分組長度(32位比特字) 加密輪數
AES-128 4 4 10
AES-192 6 4 12
AES-256 8 4 14

AES的加密公式爲C = E(K,P)

1、字節代換

AES定義了一個S盒和一個逆S盒。
1.字節代換操做
2.字節代換逆操做
複製代碼

2、行移位

1.行移位操做 2.行移位的逆變換

3、列混合 1.列混合操做 2.列混合逆運算

4、輪密鑰加

一文搞懂 RSA 算法

第一步：生成密鑰對，即公鑰和私鑰

  • 兩個隨機質數 P Q，數越大越安全
好比 P = 67 ，Q = 71。計算他們的乘積 n = P * Q = 4757 ，轉化爲二進爲 1001010010101，該加密算法即爲 13 位，
實際算法是 1024 位 或 2048 位，位數越長，算法越難被破解。
複製代碼
  • 計算 n 的歐拉函數 φ(n)
φ(n) 表示在小於等於 n 的正整數之中，與 n 構成互質關係的數的個數。
例如：在 1 到 8 之中，與 8 造成互質關係的是一、三、五、7，因此 φ(n) = 4。 
若是 n = P * Q，P 與 Q 均爲質數，則 φ(n) = φ(P * Q) = φ(P - 1)φ(Q - 1) = (P - 1)(Q - 1) 。 
本例中 φ(n) = 66 * 70 = 4620，這裏記爲 m， m = φ(n) = 4620
複製代碼
  • 隨機選一個整數 e ，條件是 1 < e < m ，且 e 與 m 互質
公約數只有 1 的兩個整數，叫作互質整數，這裏咱們隨機選擇 e = 101 
請注意不要選擇 4619，若是選這個，則公鑰和私鑰將變得相同。
複製代碼
  • 有一個整數d，可使得 e * d 除以 m 的餘數爲 1
即找一個整數 d，使得 (e * d ) % m = 1。 等價於 e * d + 1 = y * m ( y 爲整數) 找到 d ，實質就是對下面二元一次方程求解。 
e * x - m * y = 1 ，其中 e = 101，m = 4620，101x - 4620y = 1 這個方程能夠用"擴展歐幾里得算法"求解，此處省略具體過程。

總之算出一組整數解(x,y) = (1601,35)，即 d = 1601。 到此密鑰對生成完畢。
不一樣的 e 生成不一樣的 d，所以能夠生成多個密鑰對。

本例中公鑰爲 (n，e) = (4757 , 101)，私鑰爲 (n，d) = (4757 ，1601) ，僅 (n，e) = (4757 , 101) 是公開的，其他數字均不公開。
能夠想像若是隻有 n 和 e，如何推導出 d，目前只能靠暴力破解，位數越長，暴力破解的時間越長。
複製代碼

第二步：加密生成密文

好比甲向乙發送漢字「中」，就要使用乙的公鑰加密漢字 "中"， 以 utf-8 方式編碼爲 [e4 b8 ad]，轉爲 10 進製爲 [228,184,173]。
要想使用公鑰（n，e) = (4757 , 101)加密，要求被加密的數字必須小於 n，被加密的數字必須是整數，字符串能夠取 ascii 值或unicode值，
所以將「中」字折爲三個字節 [228,184,173]，分別對三個字節加密。 
假設 a 爲明文，b 爲密文，則按下列公式計算出 b
複製代碼

  • a ^ e % n = b

    計算 [228,184,173]的密文：

    228^101 % 4757 = 4296

    184^101 % 4757 = 2458

    173^101 % 4757 = 3263

    即 [228,184,173]加密後獲得密文 [4296，2458，3263] ，若是沒有私鑰 d ,神仙也沒法從 [4296，2458，3263]中恢復 [228,184,173]。

解密生成明文。

乙收到密文 [4296，2458，3263]，並用本身的私鑰 (n，d) = (4757 ，1601) 解密。解密公式以下： 假設 a 爲明文，b 爲密文，則按下列公式計算出 a
複製代碼

  • a ^ d % n = b

    密文 [4296，2458，3263]的明文以下：

    4296^1601% 4757 = 228

    2458^1601% 4757 = 184

    3263^1601% 4757 = 173

    即密文 [4296，2458，3263] 解密後獲得 [228,184,173] 將[228,184,173] 再按 utf-8 解碼爲漢字 "中"，至此解密完畢。

目前已經破解的最大整數：

1230186684530117755130494958384962720772853569595334792197322452151726400507263657518745202199786469389956474942774063845925192557326303453731548268507917026122142913461670429214311602221240479274737794080665351419597459856902143413
=
33478071698956898786044169848212690817704794983713768568912431388982883793878002287614711652531743087737814467999489
x
36746043666799590428244633799627952632279158164343087642676032283815739666511279233373417143396810270092798736308917
複製代碼

即（232個十進制位，768個二進制位），目前被破解的最長RSA密鑰就是768位。實際應用中 RSA 的密鑰長度爲 1024 位，重要場合 2048 位，將來半個世紀不可能破解。 (完）

漫畫：什麼是MD5算法？

MD5算法底層原理

處理原文，

原文長度(bit)對512求餘的結果，若是不等於448，就須要填充原文到等於448。
填充的方法是第一位填充1，其他位填充0。

用剩餘的位置（512-448=64位）記錄原文的真正長度，把長度的二進制值補在最後。
這樣處理後的信息長度就是512*(N+1)。
複製代碼

設置初始值，

MD5的哈希結果長度爲128位，按每32位分紅一組共4組。
這4組結果是由4個初始值A、B、C、D通過不斷演變獲得。
MD5的官方實現中，A、B、C、D的初始值以下（16進制）：
複製代碼

A=0x01234567

B=0x89ABCDEF

C=0xFEDCBA98

D=0x76543210

循環加工，每一次循環都會讓舊的ABCD產生新的ABCD，原文長度是M

主循環次數 = M / 512

每一個主循環中包含 512 / 32 * 4 = 64 次 子循環。

這張圖所表達的就是單次子循環的流程：

1.綠色F

圖中的綠色F，表明非線性函數。官方MD5所用到的函數有四種：
F(X, Y, Z) =(X&Y) | ((~X) & Z)
G(X, Y, Z) =(X&Z) | (Y & (~Z))
H(X, Y, Z) =X^Y^Z
I(X, Y, Z)=Y^(X|(~Z))
在主循環下面64次子循環中，F、G、H、I 交替使用，第一個16次使用F，第二個16次使用G，第三個16次使用H，第四個16次使用I。
複製代碼

2.紅色「田」字

很簡單，紅色的田字表明相加的意思。

4.Ki

一個常量，在64次子循環中，每一次用到的常量都是不一樣的。

拼接結果。

最終產生的A，B，C，D四個值拼接在一塊兒，轉換成字符串便可。
複製代碼

5.黃色的<<<S

左移S位，S的值也是常量。
「流水線」的最後，讓計算的結果和B相加，取代原先的B。新ABCD的產生能夠概括爲：

新A = 原d
新B = b+((a+F(b,c,d)+Mj+Ki)<<<'s)
新C = 原b
新D = 原c
複製代碼

www.cnblogs.com/foxclever/p…

juejin.im/post/5ce6b8…

14.client如何肯定本身發送的消息被server收到?

blog.csdn.net/github_3713…

增長 ack QoS

15.談談你對WebSocket的理解

blog.csdn.net/github_3713…

WebSocket 是相似 Socket 的 TCP 長鏈接的通信模式，一旦 WebSocket 鏈接創建後，後續數據都以幀序列的形式傳輸。在客戶端斷開 WebSocket 鏈接或 Server 端斷掉鏈接前，不須要客戶端和服務端從新發起鏈接請求。

  1. WebSocket是雙向通訊協議，模擬Socket協議，能夠雙向發送或接受信息。HTTP是單向的。

  2. WebSocket是須要握手進行創建鏈接的。

16.WebSocket與Socket的區別

juejin.im/post/5c9748…

爲了解決 Web 端即時通信的需求就出現了 WebSocket

WebSocket 與 Socket 的區別

Socket 是傳輸控制層的接口。用戶能夠經過 Socket 來操做底層 TCP/IP 協議族通訊。
WebSocket 是一個完整應用層協議。
Socket 更靈活，WebSocket 更易用。
二者都能作即時通信
複製代碼

www.jianshu.com/p/59b5594ff…

ARPANET（Advanced Research Projects Agency）

最先的時候一個Socket指的是一個40位的數字（RFC33中說明了此用法，但在RFC36中並無明確地說使用40位數字來標識一個地址），其中前32爲指向的地址（socket number，大體至關於IP），後8位爲發送數據的源（link，大體至關於端口號）
後來（RFC433，Socket Number List）socket number被明確地定義爲一個40位的數字，其中後8位被用來制定某個特定的應用使用（好比1是Telnet）。
複製代碼

Hixie（Ian Hickson），他是WHATWG組織的發言人，曾供職於Netscape、Opera、Google。Hixie說了一句「我看WebSocket這個名字就很適合嘛」。 mcarter（Michael Carter ）在Comet Daily中發表了文章Independence Day: HTML5 WebSocket Liberates Comet From Hacks，後來隨着各大瀏覽器對WebSocket的支持，它變成了實際的標準，IETF也沿用了這個名字

www.jianshu.com/p/0e5b94688…

Meteor

HTTP和WebSocket協議的RFC文檔（RFC2616 和 RFC6455）

HTTP1.1的鏈接默認使用持續鏈接（persistent connection），持續鏈接指的是，有時是客戶端會須要在短期內向服務端請求大量的相關的資源，若是不是持續鏈接，那麼每一個資源都要創建一個新的鏈接，HTTP底層使用的是TCP，那麼每次都要使用三次握手創建TCP鏈接，將形成極大的資源浪費。

持續鏈接能夠帶來不少的好處：

使用更少的TCP鏈接，對通訊各方的壓力更小。 可使用管道（pipeline）來傳輸信息，這樣請求方不須要等待結果就能夠發送下一條信息，對於單個的TCP的使用更充分。 流量更小 順序請求的延時更小。 不須要從新創建TCP鏈接就能夠傳送error，關閉鏈接等信息。

www.jianshu.com/p/f666da1b1…

GET /chat HTTP/1.1            //1
Host: server.example.com   //2
Upgrade: websocket            //3
Connection: Upgrade            //4
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==            //5
Origin: http://example.com            //6
Sec-WebSocket-Protocol: chat, superchat            //7
Sec-WebSocket-Version: 13            //8
複製代碼

幀類型 幀類型是由一個4位長的叫Opcode的值表示，任何WebSocket的通訊方收到一個位置的幀類型，都要以鏈接失敗的方式斷開此鏈接。 RFC6455中定義的幀類型以下所示：

Opcode == 0 繼續

表示此幀是一個繼續幀，須要拼接在上一個收到的幀以後，來組成一個完整的消息。因爲這種解析特性，非控制幀的發送和接收必須是相同的順序。

Opcode == 1 文本幀

Opcode == 2 二進制幀

Opcode == 3 - 7 將來使用（非控制幀）

Opcode == 8 關閉鏈接（控制幀） 此幀可能會包含內容，以表示關閉鏈接的緣由。 通訊的某一方發送此幀來關閉WebSocket鏈接，收到此幀的一方若是以前沒有發送此幀，則須要發送一個一樣的關閉幀以確認關閉。若是雙方同時發送此幀，則雙方都須要發送迴應的關閉幀。 理想狀況服務端在確認WebSocket鏈接關閉後，關閉相應的TCP鏈接，而客戶端須要等待服務端關閉此TCP鏈接，但客戶端在某些狀況下也能夠關閉TCP鏈接。

Opcode == 9 Ping 相似於心跳，一方收到Ping，應當當即發送Pong做爲響應。

Opcode == 10 Pong 若是通訊一方並無發送Ping，可是收到了Pong，並不要求它返回任何信息。Pong幀的內容應當和收到的Ping相同。可能會出現一方收到不少的Ping，可是隻須要響應最近的那一次就能夠了。

Opcode == 11 - 15 將來使用（控制幀）

0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-------+-+-------------+-------------------------------+
 |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
 |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
 |N|V|V|V|       |S|             |   (if payload len==126/127)   |
 | |1|2|3|       |K|             |                               |
 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
 |     Extended payload length continued, if payload len == 127  |
 + - - - - - - - - - - - - - - - +-------------------------------+
 |                               |Masking-key, if MASK set to 1  |
 +-------------------------------+-------------------------------+
 | Masking-key (continued)       |          Payload Data         |
 +-------------------------------- - - - - - - - - - - - - - - - +
 :                     Payload Data continued ...                :
 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
 |                     Payload Data continued ...                |
 +---------------------------------------------------------------+
複製代碼

www.cnblogs.com/jiangzhaowe…

17.談談你對安卓簽名的理解

blog.csdn.net/github_3713…

www.jianshu.com/p/24af47abc…

  • Android 使用標準的 Java 工具 Keytool & Jarsigner 來生成數字證書，並給應用包簽名
  • 使用 zipalign 優化程序

調試模式 debug.keystore 發佈模式 release.keystore

1）經過命令來對APK簽名。 2）使用ADT Export Wizard進行簽名

18.請解釋安卓爲啥要加簽名機制?

blog.csdn.net/github_3713…

爲何要簽名

  • 發送者的身份認證：
  • 保證信息傳輸的完整性：
  • 防止交易中的抵賴發生：

給apk簽名能夠帶來如下好處

  • 應用程序升級：
  • 應用程序模塊化：
  • 代碼或者數據共享：

簽名的說明

  • 全部的應用程序都必須有數字證書：
  • Android 程序包使用的數字證書能夠是自簽名的：
  • 使用一個合適的私鑰生成的數字證書來給程序簽名：
  • 數字證書都是有有效期的：

19.視頻加密傳輸

blog.csdn.net/qq_24636637…

20.App 是如何沙箱化，爲何要這麼作？

blog.csdn.net/github_3713…

21.權限管理系統（底層的權限是如何進行 grant 的）？

blog.csdn.net/github_3713…

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程