由身份或持有的令牌確認(rèn)享有的權(quán)限，登錄過程實質(zhì)上的目的也是為了確認(rèn)權(quán)限。
目前成都創(chuàng)新互聯(lián)已為1000多家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)頁空間、網(wǎng)站改版維護(hù)、企業(yè)網(wǎng)站設(shè)計、和布克賽爾蒙古網(wǎng)站維護(hù)等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。
Cookie是客戶端給服務(wù)器用的，setCookie是服務(wù)器給客戶端用的。cookie由服務(wù)器處理，客戶端負(fù)責(zé)存儲
客戶端發(fā)送cookie：賬戶和密碼
服務(wù)端收到后確認(rèn)登錄setCookie：sessionID=1，記下sessionID
客戶端收到sessionID后記錄，以后請求服務(wù)端帶上對比記錄下sessionID，說明已經(jīng)登錄
會話管理：登錄狀態(tài)，購物車
個性化：用戶偏好，主題
Tracking：分析用戶行為
XXS：跨腳本攻擊，及使用JavaScript拿到瀏覽器的cookie之后，發(fā)送到自己的網(wǎng)站，以這種方式來盜用用戶Cookie。Server在發(fā)送Cookie時，敏感的Cookie加上HttpOnly，這樣Cookie只能用于http請求，不能被JavaScript調(diào)用
XSRF:跨站請求偽造。Referer 從哪個網(wǎng)站跳轉(zhuǎn)過來
兩種方式：Basic和Bearer
首先第三方網(wǎng)站向授權(quán)網(wǎng)站申請第三方授權(quán)合作，拿到授權(quán)方頒發(fā)的client_id和client_secret（一般都是appid+appkey的方式）。
在這就過程中申請的client_secret是服務(wù)器持有的，安全起見不能給客戶端，用服務(wù)端去和授權(quán)方獲取用戶信息，再傳給客戶端，包括④，⑤的請求過程也是需要加密的。這才是標(biāo)準(zhǔn)的授權(quán)過程。
有了access_token之后，就可以向授權(quán)方發(fā)送請求來獲取用戶信息
步驟分析就是上面的內(nèi)容，這里把第4,6,8請求的參數(shù)分析一下
第④步參數(shù)：
response_type：指授權(quán)類型，必選，這里填固定值‘code’
client_id：指客戶端id，必選，這里填在平臺報備時獲取的appid
redirect_uri：指重定向URI，可選
scope：指申請的權(quán)限范圍，可選
state：指客戶端當(dāng)前狀態(tài)，可選，若填了，則認(rèn)證服務(wù)器會原樣返回該值
第⑥步參數(shù)：
grant_type：指使用哪種授權(quán)模式，必選，這里填固定值‘a(chǎn)uthorization_code’
code：指從第⑤步獲取的code，必選
redirect_uri：指重定向URI，必選，這個值需要和第④步中的redirect_uri保持一致
client_id：指客戶端id，必選，這里填在平臺報備時獲取的appid
client_secret：指客戶端密鑰，必選，這里填在平臺報備時獲取的appkey
第⑧步參數(shù)：
access_token：指訪問令牌，必選，這里填第⑦步獲取的access_token
token_type：指令牌類型，必選，大小寫不敏感，bearer類型 / mac類型
expires_in：指過期時間，單位秒，當(dāng)其他地方已設(shè)置過期時間，此處可省略該參數(shù)
refresh_token：指更新令牌，可選，用即將過期token換取新token
scope：指權(quán)限范圍，可選，第④步中若已申請過某權(quán)限，此處可省略該參數(shù)
我們在上面的第八步中會有refresh_token的參數(shù)，這個在實際操作中也比較常見
有時候我們在自己的項目中，將登陸和授權(quán)設(shè)計成類似OAuth2的過程，不過去掉Authorization code。登陸成功返回access_token，然后客戶端再請求時，帶上access_token。
我們常常會說到TCP/IP，那到底是什么呢。這就需要講到網(wǎng)絡(luò)分層模型。TCP在傳輸層，IP在網(wǎng)絡(luò)層。那為什么需要分層？因為網(wǎng)絡(luò)不穩(wěn)定，導(dǎo)致需要重傳的問題。為了提高傳輸效率我們就需要分塊，在傳輸層中就會進(jìn)行分塊。TCP還有兩個重要的內(nèi)容就是三次握手，四次分手。
HTTPS 協(xié)議是由 HTTP 加上TLS/SSL協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，主要通過數(shù)字證書、加密算法、非對稱密鑰等技術(shù)完成互聯(lián)網(wǎng)數(shù)據(jù)傳輸加密，實現(xiàn)互聯(lián)網(wǎng)傳輸安全保護(hù)
1.客戶端通過發(fā)送Client Hello報文開始SSL通信。報文中包含客戶端支持的SSL的指定版本、加密組件列表（所使用的加密算法及密鑰長度），客戶端隨機數(shù)，hash算法。
2.服務(wù)器可進(jìn)行SSL通信時，會以Server Hello報文作為應(yīng)答。和客戶端一樣，在報文中包含SSL版本以及加密組件，服務(wù)端隨機數(shù)。服務(wù)器的加密組件內(nèi)容是從接收到客戶端加密組件內(nèi)篩選出來的。
3.之后服務(wù)器發(fā)送Certificate報文。報文中包含公開密鑰證書。一般實際有三層證書嵌套，其實像下面圖二直接用根證書機構(gòu)簽名也是可以的，但是一般根證書機構(gòu)比較忙，需要類似中介的證書機構(gòu)來幫助。
4.最后服務(wù)器發(fā)送Server Hello Done報文通知客戶端，最初階段的SSL握手協(xié)商部分結(jié)束。
5.SSL第一次握手結(jié)束后，客戶端以Client Key Exchange報文作為回應(yīng)。報文中包含通信加密中使用的一種被稱為Pre-master secret的隨機密碼串。該報文已用步驟3中的公開密鑰進(jìn)行加密。
6.接著客戶端繼續(xù)發(fā)送Change Cipher Spec報文。該報文會提示服務(wù)器，在此報文之后的通信會采用Pre-master secret密鑰加密。
7.客戶端發(fā)送Finished報文。該報文包含連接至今全部報文的整體校驗值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確解密報文作為判定標(biāo)準(zhǔn)。
8.服務(wù)器同樣發(fā)送Change Cipher Spec報文。
9.服務(wù)器同樣發(fā)送Finished報文。
10.服務(wù)器和客戶端的Finished報文交換完畢之后，SSL連接就算建立完成。當(dāng)然，通信會受到SSL的保護(hù)。從此處開始進(jìn)行應(yīng)用層協(xié)議的通信，即發(fā)送HTTP響應(yīng)。
11.應(yīng)用層協(xié)議通信，即發(fā)送HTTP響應(yīng)。
12.最后由客戶端斷開連接。斷開連接時，發(fā)送close_notify報文。這步之后再發(fā)送TCP FIN報文來關(guān)閉與TCP的通信。
利用客戶端隨機數(shù)，服務(wù)端隨機數(shù)，per-master secret隨機數(shù)生成master secret，再生成客戶端加密密鑰，服務(wù)端加密密鑰，客戶端MAC secert，服務(wù)端MAC secert。MAC secert用于做報文摘要，這樣能夠查知報文是否遭到篡改，從而保護(hù)報文的完整性。
Android網(wǎng)絡(luò)請求知識（一）HTTP基礎(chǔ)概念
Android網(wǎng)絡(luò)請求知識（二）對稱和非對稱加密、數(shù)字簽名，Hash，Base64編碼
Android網(wǎng)絡(luò)請求知識（三）授權(quán)，TCP/IP，HTTPS建立過程
主目錄見： Android高級進(jìn)階知識（這是總目錄索引）
[written by 無心追求 ]
常
把Http和TCP連接服務(wù)做區(qū)分導(dǎo)致IM的TCP使用80端口連接進(jìn)來的時候被誤
識別成是一個Http請求，所以就對IM的TCP數(shù)據(jù)流（TLV格式）進(jìn)行解析導(dǎo)
致報錯返回了一個Http請求報錯的網(wǎng)頁的Html數(shù)據(jù)，具體返回的數(shù)據(jù)格式
客戶端打印是：
以上是客戶端TCP數(shù)據(jù)流read到100字節(jié)打印出來的數(shù)據(jù)，是一個Http請求
失敗返回Http狀態(tài)碼為400的網(wǎng)頁Html數(shù)據(jù)
以上是tcpdump抓包信息，從抓包信息中可以得知返回的數(shù)據(jù)確實是一個
Http請求失敗的網(wǎng)頁，對比客戶端程序log打印是吻合的
式的數(shù)據(jù)，所以對read到的數(shù)據(jù)進(jìn)行常規(guī)的TLV數(shù)據(jù)解析導(dǎo)致程序解析報錯
(數(shù)組越界)：
客戶端發(fā)生數(shù)據(jù)解析報錯之后會認(rèn)為當(dāng)前接收到的數(shù)據(jù)已經(jīng)不正確，同時
也會認(rèn)為后面接續(xù)讀取的數(shù)據(jù)也將不正確，所以會把socket連接關(guān)閉重連
：
應(yīng)該下調(diào)心跳周期，但是舊版（1.0.1Realease-1.0.6Realease版本）存在
不足，并沒有對此做過濾處理，所以會不斷的下調(diào)心跳
斷線后會馬上重連
接斷開的域名和端口再次嘗試重連，在重試重連失敗的時候才會去切換域
名或者端口，而遇到這種情況，每次嘗試重連TCP都能連接成功，連接成功
之后，數(shù)據(jù)解析失敗又把TCP連接斷開，然后再拿原來的域名和端口，再重
連，再斷開，如此陷入死循環(huán)，無法切換域名或者端口，斷線重連頻率很
高：
TCP連接IM服務(wù)器gw.im.okii.com成功，連接端口為80
入的TCP數(shù)據(jù)為323個字節(jié)
的數(shù)據(jù)進(jìn)行解析
srcPos=2 dst.length=121 dstPos=0 length=121表示數(shù)據(jù)解析報錯，數(shù)組
越界
誤的識別成Http短連接
不下調(diào)心跳間隔，避免心跳誤下調(diào)，影響心跳探測的準(zhǔn)確性
時間間隔遞增重連，避免頻繁的重連
一些常用的端口，例如8080，443，1000一下的端口等都不能使用，避免出
現(xiàn)類似的問題
和端口去再次連接IM服務(wù)器導(dǎo)致無法跳出這個域名和端口連接造成的異常
，如果客戶端有成功切換域名或者端口，那么遇到上述情況會立即切換到
8000端口，次數(shù)連接就會恢復(fù)正常
有上傳大數(shù)據(jù)的手表分析來看全部都恢復(fù)正常使用
111.44.228.186這個地址（正確的應(yīng)該是106.75.86.52），而被誤識別成
Http短鏈接，然后返回一個錯誤的網(wǎng)頁html數(shù)據(jù)，然后客戶端接收到數(shù)據(jù)
后解析報錯，導(dǎo)致頻繁的斷線重連和心跳下調(diào)
跳誤下調(diào)，重連頻繁，與香港的原因類似
gw.im.okii.com本地dns解析出來的ip為111.44.228.186，由此確認(rèn)是被劫
持了
客戶端對接收到的TCP數(shù)據(jù)解析異常ArrayIndexOutOfBoundsException，數(shù)
組越界
客戶端在數(shù)據(jù)解析異常后斷線
連接斷開后心跳下調(diào)
內(nèi)存不足導(dǎo)致的閃退。比如說androidtc內(nèi)存沒有釋放，一長條列表下有N個資源需要展示，不斷下拉，上面的資源沒有釋放，所分配的內(nèi)存越來越多，最后當(dāng)然會閃退。
重慶分公司
重慶分公司
