二、網路和安全機制
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 的）？
複製程式碼參考答案：
1.網路框架對比和原始碼分析
Volley
特點：
- 基於 HttpURLConnection
- 封裝Url圖片載入框架，支援圖片載入
- 有快取
- Activity和生命週期的聯動，Activity結束時取消在此Activity中呼叫的所有網路請求
場景：
- 適合傳輸量小，資料請求頻繁的的場景
- 不能進行大量資料操作，如上傳下載，因為Volley的Request和Response放到byte[]中
OkHttp
特點：
- 基於 NIO 和 Okio，請求處理速度更快
- IO 是阻塞式；NIO是非阻塞式；Okio （Square）基於二者的更高效的資料流庫
IO 面向流 Steam，NIO 面向緩衝區 Buffer IO 阻塞，NIO 非阻塞
NIO情況下，一個執行緒可以處理多個通道的讀取和寫入，更充分的利用執行緒資源。
適用場景
-
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.自己去設計網路請求框架，怎麼做？
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的圖片，說下注意事項
Bitmap.Options inJustDecodeBounds inSampleSize
ARGB_4444 RGB_565
補圖
分塊載入
使用LruCache
sizeOf()、entryRemoved()
手勢處理
ScaleGestureDetector GestureDetector
前者用於處理縮放手勢，後者用於處理其餘手勢，如移動，快速滑動，點選，雙擊，長按等。
ScaleGestureDetector專門處理縮放手勢，其比較重要的方法是onScale(ScaleGestureDetector detector)，當縮放時會不停地回撥這個方法，需要注意的一點是detector.getScaleFactor()獲取到的縮放比例是相對上一次的
5.TCP的3次握手和四次揮手
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
區別
面向連線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…
9.HTTP1.0與2.0的區別
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 效能驚人
大約 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報文結構
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）等是否有了解?
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標準規範中，分組長度只能是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)
一、位元組代換
AES定義了一個S盒和一個逆S盒。
1.位元組代換操作
2.位元組代換逆操作
複製程式碼二、行移位
1.行移位操作 2.行移位的逆變換
三、列混合 1.列混合操作 2.列混合逆運算
四、輪金鑰加
第一步：生成金鑰對，即公鑰和私鑰
- 兩個隨機質數 P Q，數越大越安全
比如 P = 67 ，Q = 71。計算他們的乘積 n = P * Q = 4757 ，轉化為二進為 1001010010101，該加密演算法即為 13 位，
實際演算法是 1024 位 或 2048 位，位數越長，演算法越難被破解。
複製程式碼- 計算 n 的尤拉函式 φ(n)
φ(n) 表示在小於等於 n 的正整數之中，與 n 構成互質關係的數的個數。
例如：在 1 到 8 之中，與 8 形成互質關係的是1、3、5、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演算法底層原理
處理原文，
原文長度(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
複製程式碼14.client如何確定自己傳送的訊息被server收到?
增加 ack QoS
15.談談你對WebSocket的理解
WebSocket 是類似 Socket 的 TCP 長連線的通訊模式，一旦 WebSocket 連線建立後，後續資料都以幀序列的形式傳輸。在客戶端斷開 WebSocket 連線或 Server 端斷掉連線前，不需要客戶端和服務端重新發起連線請求。
-
WebSocket是雙向通訊協議，模擬Socket協議，可以雙向傳送或接受資訊。HTTP是單向的。
-
WebSocket是需要握手進行建立連線的。
16.WebSocket與Socket的區別
為了解決 Web 端即時通訊的需求就出現了 WebSocket
WebSocket 與 Socket 的區別
Socket 是傳輸控制層的介面。使用者可以通過 Socket 來操作底層 TCP/IP 協議族通訊。
WebSocket 是一個完整應用層協議。
Socket 更靈活，WebSocket 更易用。
兩者都能做即時通訊
複製程式碼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也沿用了這個名字
Meteor
HTTP和WebSocket協議的RFC文件（RFC2616 和 RFC6455）
HTTP1.1的連線預設使用持續連線（persistent connection），持續連線指的是，有時是客戶端會需要在短時間內向服務端請求大量的相關的資源，如果不是持續連線，那麼每個資源都要建立一個新的連線，HTTP底層使用的是TCP，那麼每次都要使用三次握手建立TCP連線，將造成極大的資源浪費。
持續連線可以帶來很多的好處：
使用更少的TCP連線，對通訊各方的壓力更小。 可以使用管道（pipeline）來傳輸資訊，這樣請求方不需要等待結果就可以傳送下一條資訊，對於單個的TCP的使用更充分。 流量更小 順序請求的延時更小。 不需要重新建立TCP連線就可以傳送error，關閉連線等資訊。
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 ... |
+---------------------------------------------------------------+
複製程式碼17.談談你對安卓簽名的理解
- Android 使用標準的 Java 工具 Keytool & Jarsigner 來生成數字證照，並給應用包簽名
- 使用 zipalign 優化程式
除錯模式 debug.keystore 釋出模式 release.keystore
1）通過命令來對APK簽名。 2）使用ADT Export Wizard進行簽名
18.請解釋安卓為啥要加簽名機制?
為什麼要簽名
- 傳送者的身份認證：
- 保證資訊傳輸的完整性：
- 防止交易中的抵賴發生：
給apk簽名可以帶來以下好處
- 應用程式升級：
- 應用程式模組化：
- 程式碼或者資料共享：
簽名的說明
- 所有的應用程式都必須有數字證照：
- Android 程式包使用的數字證照可以是自簽名的：
- 使用一個合適的私鑰生成的數字證照來給程式簽名：
- 數字證照都是有有效期的：
19.視訊加密傳輸