1.登錄與授權的概念區(qū)別
1.登錄：是用戶身份認證对蒲，系統(tǒng)確認用戶身份的過程钩蚊。
2.授權：是由身份或者持有的令牌來確認用戶享有某些權限，登錄過程實質(zhì)上的目的是為了確認權限蹈矮。
2.HTTP中確認授權的兩種方式
1.通過cookie
2.通過Authorization Header
Cookie
1.起源：有Netscape瀏覽器團隊開發(fā)實現(xiàn)了購物車功功能砰逻。
2.工作機制：
1.服務器端需要客戶端存儲的數(shù)據(jù)都會通過set-cookie放在reponse的header里面返回，客戶端自動保存泛鸟。
2.客戶端保存的cookie蝠咆，在之后的請求中，會放在request的header里面發(fā)送給服務端北滥。
3.客戶端保存cookie是按照域名來區(qū)分的刚操。
4.客戶端保存的cookie有超時時間，如果未設置超時時間再芋，則在瀏覽器關閉時刪除cookie菊霜，另外服務器還可以主動刪除未過期的客戶端cookie。
3.cookie的作用：
1.會話管理：比如用戶登錄狀態(tài)祝闻，用戶購物車管理占卧。
2.用戶的個性化設置：比如主題，顏色联喘，壁紙等等华蜒。
3.分析用戶行為：可以使用cookie來追蹤用戶行為。
4.HttpOnly與Secure屬性
1.如果在cookie中設置了HttpOnly屬性豁遭，那么通過程序（比如JS腳本叭喜，Applet等）就無法讀取cookie信息，這樣能有效預防XSS攻擊蓖谢。
2.secure屬性：當設置為true時捂蕴，表示創(chuàng)建的cookie只能以安全的形式傳送給服務器譬涡，也就是說只能在HTTPS連接中被瀏覽器傳遞到服務器端進行會話驗證，如果是HTTP連接啥辨，那么就不會傳遞信息涡匀，所以不會被竊取到Cookie的具體內(nèi)容。
5.XSS
跨站腳本攻擊溉知，利用JavaScript來拿到瀏覽器的cookie之后陨瘩，發(fā)送到自己的網(wǎng)站，以此來盜取用戶信息级乍。
6.XSRF
跨站請求偽造舌劳，在用戶不知情的情況下訪問已經(jīng)保存了cookie的網(wǎng)站，以此來越權操作用戶賬戶玫荣。
Authorization
兩種主流方式 Basic 和 Bearer
Basic
1.格式：Authorization: Basic<username:password(Base64)>
2.Basic認證過程
1.瀏覽器發(fā)送請求到服務器
GET / HTTP /1.1
Host:xxx.xxx.com
2.服務端發(fā)送驗證請求401
HTTP/1.1 401 Unauthorised
Server: bfe/1.0.8.18
WWW-Authenticate: Basic realm="XXXXX.com"
Content-Type: text/html; charset=utf-8
3.客戶端收到401返回值后甚淡，將自動彈出登錄窗口，等待用戶輸入用戶名捅厂，密碼
4.將用戶名密碼進行Base64編碼后發(fā)送給服務端進行驗證
GET / HTTP/1.1
Host: xxx.xxx.xxx.com
Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxx
5.服務端取出Authorization中頭信息贯卦，并與數(shù)據(jù)庫進行比對，如果合法則返回200恒傻，不合法脸侥，則返回401。
Bearer
1.格式：Authorization: Bearer <bearer token>
2.bearer token 的獲取方式：通過OAuth2的授權流程
3.OAuth2的流程
1.第三方網(wǎng)站向授權網(wǎng)站申請授權合作盈厘，拿到client id和client secret
2.用戶在使用第三方網(wǎng)站的時候睁枕，點擊通過授權，第三方網(wǎng)站將跳轉授權網(wǎng)站沸手，并將clientid傳遞給授權網(wǎng)站外遇。
4.授權方網(wǎng)站根據(jù)clientid，將第三方網(wǎng)站的信息和第三方網(wǎng)站需要的用戶權限展示給用戶契吉，詢問用戶是否同意授權跳仿。
5.當用戶點擊同意授權，授權方網(wǎng)站返回第三方網(wǎng)站捐晶，并傳入Authorization code作為用戶認可的憑證菲语。
6.第三方網(wǎng)站將Authorization code上送給自己的服務器，服務器將Authorization code跟自己服務器端存儲的client secret發(fā)送給授權方服務器惑灵，授權方服務器通過驗證后山上，返回給access token，整個OAuth2流程結束英支。
7.在整個OAuth流程結束后佩憾，第三方網(wǎng)站服務器可以試用access token 作用用戶授權的token，用此來向授權方網(wǎng)站請求獲取用戶信息等操作。
4.問題：
為什么OAuth認證要引入Authorization code妄帘，并且需要申請授權的第三方將Authorization code傳給第三方服務器楞黄，并且通過第三方服務器將Authorization code傳遞給授權方服務器。然后再獲取授權方服務器的access token抡驼。這樣做的目的是為了通信安全鬼廓，因為OAuth不強制使用HTTPS，因此需要保證通信路徑中存在竊聽者的時候致盟，還能保證足夠的安全桑阶。
5.第三方APP通過微信登錄的流程：
這是一個標準的OAuth2的流程。
1.第三方APP向騰訊方申請合作勾邦，拿到client id 和client secret
2.當用戶在第三方APP上需要微信登錄的時候，第三方APP將使用微信SDK打開微信授權頁面割择，并且傳入client id作為自己授權id眷篇。
3.微信拿到第三方app的client id后，提交微信后臺荔泳，驗證成功蕉饼，則返回給第三方app Authorization code。
4.第三方app拿到Authorization code后玛歌，將Authorization code傳遞給自己的服務器昧港，第三方app的服務端將Authorization code 與 client secret 傳遞給微信后臺，微信后臺驗證后返回access token支子。
5.第三方app后臺通過access token 想微信后臺請求獲取用戶信息创肥，微信驗證通過后，則返回用戶信息值朋。
6.服務器接受到用戶信息后叹侄，在自己的數(shù)據(jù)庫中建立一個賬戶，并將從微信獲取的用戶信息填入數(shù)據(jù)庫中昨登。并創(chuàng)建用戶id趾代，并將此id與微信id做好關聯(lián)。
7.當?shù)谌絘pp后臺創(chuàng)建好用戶后丰辣，想客戶端的請求發(fā)出響應撒强，并回傳會剛剛創(chuàng)建的用戶信息。
8.客戶端響應笙什，獲取用戶信息飘哨，登錄成功。
6.在自家APP中使用Bearer token
部分app會在api設計中得湘，將登錄和授權設計出類似于OAuth2的過程杖玲，他會簡化掉Authorization code的概念。既直接在接口請求成功后淘正，返回access token摆马，然后再之后的客戶端的請求中臼闻，使用這個access token 作為Bearer token進行用戶操作。
7.Refresh token
Access token 都會有失效時間囤采，當他失效后述呐，第三方app的服務端會通過refresh token 接口傳入refresh token 來獲取新的access token。這樣的的原因是安全蕉毯，因為refresh token是放置在服務端的乓搬，即使access token被竊取，他也是有失效時間的代虾。
3 TCP/IP 協(xié)議族
1.概念
兩臺計算機之間的通訊是通過TCP/IP協(xié)議在因特網(wǎng)上進行的进肯。實際上TCP/IP是兩個協(xié)議
TCP：Transmission Control Protocol 傳輸控制協(xié)議 IP：Internet Protocol 網(wǎng)際協(xié)議
IP：計算機之間的通信
IP協(xié)議是計算機用來相互識別的通信的一種機制，每臺計算機都有一個IP棉磨。用來在internet上標識這臺計算機江掩。IP負責在因特網(wǎng)上發(fā)送和接受數(shù)據(jù)包。通過IP乘瓤，消息(或者其他數(shù)據(jù))被分割為小的獨立的包环形，并且通過因特網(wǎng)再計算機之間傳送。IP負責將每個包路由至他的目的地衙傀。
IP協(xié)議僅僅是允許計算機相互發(fā)送消息抬吟，但他并不檢查消息是否以發(fā)送的次序到達并且沒有損壞(只檢查關鍵的頭部信息)。為了提供消息檢驗功能统抬，直接再IP協(xié)議上設計了傳輸控制協(xié)議TCP火本。
TCP：應用程序之間的通信
TCP確保數(shù)據(jù)以正確的次序到達，并且嘗試確認數(shù)據(jù)包的內(nèi)容沒有改變聪建。TCP在IP地址之上引端口(port)发侵，他允許計算機通過網(wǎng)絡提供各種服務。一些端口號為不變通的服務器保留妆偏，而且這些端口號是眾所周知的刃鳄。
服務或者守護進程：在提供服務的機器上，有程序監(jiān)聽特定端口上的通信流钱骂。例如大多數(shù)電子郵件通信流出現(xiàn)在端口25上叔锐，用于www的HTTP通信流出現(xiàn)在80端口上。
當應用程序希望通過TCP與另一個應用程序通信時见秽，他會發(fā)送一個通信請求愉烙。這個請求必須被送到一個確切的地址。再雙方"握手"之后解取，TCP將兩個應用程序直接建立全雙工(full-duplex)的通信步责，占用兩個計算機之間的整個通信線路。TCP用于從應用程序到網(wǎng)絡的數(shù)據(jù)傳輸控制。TCP負責在數(shù)據(jù)傳送之前將他們分割為IP包蔓肯，然后再他們到達的時候?qū)⑺麄冎亟M遂鹊。
TCP/IP就是TCP和IP兩個協(xié)議在一起的協(xié)同工作，有上下層的關系蔗包。
TCP負責應用軟件和網(wǎng)絡軟件之間的通信秉扑，IP負責計算機之間的通信。TCP負責將數(shù)據(jù)分割并裝入IP包调限，IP負責將包發(fā)送至接受者舟陆，傳輸過程中藥經(jīng)IP路由器負責跟進通信量、網(wǎng)絡中的錯誤或者其他參數(shù)來進行正確尋址耻矮，然后再他們到達的時候重新組合他們秦躯。
2.為什么要分層
因為網(wǎng)絡具有不穩(wěn)定行，保證通信正常裆装。
3.具體分層
1. 網(wǎng)絡接口層：
實際上TCP/IP參考模型沒有真正描述這一層的實現(xiàn)宦赠，只是要求能夠提供給其上層-網(wǎng)絡互連層一個訪問接口，以便在其上傳遞IP分組米母。由于這一層次未被定義，所以其具體的實現(xiàn)方法將隨著網(wǎng)絡類型的不同而不同毡琉√鳎
2. 網(wǎng)絡層：
網(wǎng)絡層是整個TCP/IP協(xié)議棧的核心。它的功能是把分組發(fā)往目標網(wǎng)絡或主機桅滋。同時慧耍，為了盡快地發(fā)送分組，可能需要沿不同的路徑同時進行分組傳遞丐谋。因此芍碧，分組到達的順序和發(fā)送的順序可能不同，這就需要上層必須對分組進行排序号俐。網(wǎng)絡互連層定義了分組格式和協(xié)議泌豆，即IP協(xié)議（Internet Protocol）。網(wǎng)絡互連層除了需要完成路由的功能外吏饿，也可以完成將不同類型的網(wǎng)絡（異構網(wǎng)）互連的任務踪危。除此之外，網(wǎng)絡互連層還需要完成擁塞控制的功能猪落≌暝叮
3. 傳輸層：
在TCP/IP模型中，傳輸層的功能是使源端主機和目標端主機上的對等實體可以進行會話笨忌。在傳輸層定義了兩種服務質(zhì)量不同的協(xié)議蓝仲。即：傳輸控制協(xié)議TCP（transmission control protocol）和用戶數(shù)據(jù)報協(xié)議UDP（user datagram protocol）。
TCP協(xié)議是一個面向連接的袱结、可靠的協(xié)議亮隙。它將一臺主機發(fā)出的字節(jié)流無差錯地發(fā)往互聯(lián)網(wǎng)上的其他主機。在發(fā)送端擎勘，它負責把上層傳送下來的字節(jié)流分成報文段并傳遞給下層咱揍。在接收端，它負責把收到的報文進行重組后遞交給上層棚饵。TCP協(xié)議還要處理端到端的流量控制煤裙，以避免緩慢接收的接收方?jīng)]有足夠的緩沖區(qū)接收發(fā)送方發(fā)送的大量數(shù)據(jù)≡胙
UDP協(xié)議是一個不可靠的硼砰、無連接協(xié)議，主要適用于不需要對報文進行排序和流量控制的場合欣硼√夂玻
4. 應用層 ：
TCP/IP模型將OSI參考模型中的會話層和表示層的功能合并到應用層實現(xiàn)。應用層面向不同的網(wǎng)絡應用引入了不同的應用層協(xié)議诈胜。其中豹障，有基于TCP協(xié)議的，如文件傳輸協(xié)議（File Transfer Protocol焦匈，F(xiàn)TP）血公、虛擬終端協(xié)議（TELNET）、超文本鏈接協(xié)議（Hyper Text Transfer Protocol缓熟，HTTP）累魔，也有基于UDP協(xié)議的。
4.TCP連接
推薦文章：TCP建立連接三次握手和釋放連接4次握手
推薦文章：長連接與短連接
TCP短連接
client向server發(fā)起連接請求够滑，server接到請求垦写，然后雙方建立連接。client向server 發(fā)送消息彰触，server回應client梯投，然后一次讀寫就完成了，這時候雙方任何一個都可以發(fā)起close操作况毅，不過一般都是client先發(fā)起 close操作晚伙。為什么呢，一般的server不會回復完client后立即關閉連接的俭茧，當然不排除有特殊的情況咆疗。從上面的描述看，短連接一般只會在 client/server間傳遞一次讀寫操作
短連接的優(yōu)點是：管理起來比較簡單母债，存在的連接都是有用的連接午磁，不需要額外的控制手段
TCP長連接
client向server發(fā)起連接尝抖，server接受client連接，雙方建立連接迅皇。Client與server完成一次讀寫之后昧辽，它們之間的連接并不會主動關閉，后續(xù)的讀寫操作會繼續(xù)使用這個連接登颓。
首先說一下TCP/IP詳解上講到的TCP苯淋瘢活功能，笨蛄活功能主要為服務器應用提供咕痛，服務器應用希望知道客戶主機是否崩潰，從而可以代表客戶使用資 源喇嘱。如果客戶已經(jīng)消失茉贡，使得服務器上保留一個半開放的連接，而服務器又在等待來自客戶端的數(shù)據(jù)者铜，則服務器將應遠等待客戶端的數(shù)據(jù)腔丧，保活功能就是試圖在服務 器端檢測到這種半開放的連接作烟。
如果一個給定的連接在兩小時內(nèi)沒有任何的動作愉粤，則服務器就向客戶發(fā)一個探測報文段，客戶主機必須處于以下4個狀態(tài)之一：
客戶主機依然正常運行拿撩，并從服務器可達衣厘。客戶的TCP響應正常绷雏，而服務器也知道對方是正常的，服務器在兩小時后將辈劳ぃ活定時器復位涎显。
客戶主機已經(jīng)崩潰，并且關閉或者正在重新啟動兴猩。在任何一種情況下期吓，客戶的TCP都沒有響應。服務端將不能收到對探測的響應倾芝，并在75秒后超時讨勤。服務器總共發(fā)送10個這樣的探測 ，每個間隔75秒晨另。如果服務器沒有收到一個響應潭千，它就認為客戶主機已經(jīng)關閉并終止連接。
客戶主機崩潰并已經(jīng)重新啟動借尿。服務器將收到一個對其迸偾纾活探測的響應屉来，這個響應是一個復位，使得服務器終止這個連接狈癞。
客戶機正常運行茄靠，但是服務器不可達，這種情況與2類似蝶桶，TCP能發(fā)現(xiàn)的就是沒有收到探查的響應慨绳。
從上面可以看出，TCP闭媸活功能主要為探測長連接的存活狀況脐雪，不過這里存在一個問題，存活功能的探測周期太長疼邀，還有就是它只是探測TCP連接的存活喂江，屬于比較斯文的做法，遇到惡意的連接時旁振，被裱活功能就不夠使了。
在長連接的應用場景下拐袜，client端一般不會主動關閉它們之間的連接吉嚣，Client與server之間的連接如果一直不關閉的話，會存在一個問 題蹬铺，隨著客戶端連接越來越多尝哆，server早晚有扛不住的時候，這時候server端需要采取一些策略甜攀，如關閉一些長時間沒有讀寫事件發(fā)生的連接秋泄，這樣可 以避免一些惡意連接導致server端服務受損；如果條件再允許就可以以客戶端機器為顆粒度规阀，限制每個客戶端的最大長連接數(shù)恒序，這樣可以完全避免某個蛋疼的 客戶端連累后端服務。
長連接和短連接的產(chǎn)生在于client和server采取的關閉策略谁撼，具體的應用場景采用具體的策略歧胁，沒有十全十美的選擇，只有合適的選擇
4.HTTPS
定義：
HTTP over SSL 的簡稱厉碟，既工作在SSL（或TLS）上的HTTP喊巍，就是加密通信的HTTP。
工作原理：
在客戶端與服務端之間協(xié)商出一套對稱秘鑰箍鼓，每次發(fā)送消息之前都將內(nèi)容加密崭参，收到之后解密，達到內(nèi)容的加密傳輸款咖。
為什么不使用非對稱加密：
考慮到網(wǎng)絡通信的性能阵翎，非對稱加密逢并，運算復雜，會影響通信性能郭卫。
HTTPS 建立通信的過程：
1. Client Hello
2. Server Hello
3. 服務器?證書 信任建?立
4. Pre-master Secret
5. 客戶端通知:將使?用加密通信 6. 客戶端發(fā)送:Finished
7. 服務器?通知:將使?用加密通信 8\. 服務器?發(fā)送:Finished
推薦文章：[SSL/TLS協(xié)議運行機制的概述](http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html)
