個人專題目錄
10. 網(wǎng)絡通信與協(xié)議
10.1 http和https的區(qū)別，https原理市栗，http2.0與1.0的區(qū)別
HTTP和HTTPS的區(qū)別
HTTPS：是以安全為目標的HTTP通道缀拭，簡單講是HTTP的安全版，即HTTP下加入SSL層填帽，HTTPS的安全基礎是SSL蛛淋，因此加密的詳細內(nèi)容就需要SSL。
HTTPS協(xié)議的主要作用可以分為兩種：一種是建立一個信息安全通道篡腌，來保證數(shù)據(jù)傳輸?shù)陌踩趾桑涣硪环N就是確認網(wǎng)站的真實性。
兩者主要區(qū)別如下：
- https協(xié)議需要到ca申請證書嘹悼，一般免費證書較少诚卸，因而需要一定費用葵第。
- http是超文本傳輸協(xié)議绘迁，信息是明文傳輸合溺，https則是具有安全性的ssl加密傳輸協(xié)議。
- http和https使用的是完全不同的連接方式缀台，用的端口也不一樣棠赛，前者是80，后者是443膛腐。
- http的連接很簡單睛约，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸哲身、身份認證的網(wǎng)絡協(xié)議辩涝，比http協(xié)議安全。
HTTP/2采用二進制格式而非文本格式
HTTP/2是完全多路復用的勘天，而非有序并阻塞的——只需一個連接即可實現(xiàn)并行
使用報頭壓縮怔揩，HTTP/2降低了開銷
HTTP/2讓服務器可以將響應主動“推送”到客戶端緩存中
1.多路復用和二進制幀
HTTP 性能優(yōu)化的關鍵并不在于高帶寬，而是低延遲脯丝。TCP 連接會隨著時間進行自我「調(diào)諧」商膊，起初會限制連接的最大速度，如果數(shù)據(jù)成功傳輸宠进，會隨著時間的推移提高傳輸?shù)乃俣仍尾稹＿@種調(diào)諧則被稱為 TCP 慢啟動。由于這種原因材蹬，讓原本就具有突發(fā)性和短時性的 HTTP 連接變的十分低效实幕。
HTTP/2 通過讓所有數(shù)據(jù)流共用同一個連接，可以更有效地使用 TCP 連接堤器，讓高帶寬也能真正的服務于 HTTP 的性能提升昆庇。
2.首部壓縮
在 HTTP/1 中，HTTP 請求和響應都是由「狀態(tài)行吼旧、請求 / 響應頭部凰锡、消息主體」三部分組成。一般而言圈暗，消息主體都會經(jīng)過 gzip 壓縮掂为，或者本身傳輸?shù)木褪菈嚎s過后的二進制文件（例如圖片、音頻）员串，但狀態(tài)行和頭部卻沒有經(jīng)過任何壓縮勇哗，直接以純文本傳輸。
頭部壓縮需要在支持 HTTP/2 的瀏覽器和服務端之間：
- 維護一份相同的靜態(tài)字典（Static Table）寸齐，包含常見的頭部名稱欲诺，以及特別常見的頭部名稱與值的組合抄谐；
- 維護一份相同的動態(tài)字典（Dynamic Table），可以動態(tài)的添加內(nèi)容扰法；
- 支持基于靜態(tài)哈夫曼碼表的哈夫曼編碼（Huffman Coding）蛹含；
10.2 Http報文格式
Http請求報文格式：1.請求行 2.Http頭 3.報文主體
請求行由三部分組成，分別是請求方法塞颁，請求地址浦箱，Http版本
Http頭：有三種，分別為請求頭（request header）祠锣，普通頭（General Header）和實體頭（entity header）酷窥。Get方法沒有實體頭。
報文主體：只在POST方法請求中存在伴网。
Http響應報文：1.狀態(tài)行 2.Http頭 3.返回內(nèi)容
狀態(tài)行：第一部分為Http版本蓬推，第二部分為響應狀態(tài)碼 第三部分為狀態(tài)碼的描述
其中第三部分為狀態(tài)碼的描述，信息類100-199 響應成功200-299 重定向類300-399 客戶端錯誤400-499 服務器端錯誤500-599
常見的
100 continue 初始請求已接受澡腾，客戶端應繼續(xù)發(fā)送請求剩余部分
200 OK
202 Accepted 已接受沸伏，處理尚未完成
301 永久重定向
302 臨時重定向
400 Bad Request
401 Unauthorized
403 Forbidden 資源不可用
404 Not Found
500 Internal Server Error 服務器錯誤
502 Bad Gateway
503 Service Unavailable 服務器負載過重
504 Gateway Timeout 未能及時從遠程服務器獲得應答
Http頭：響應頭（Response Header），普通頭（General Header）和實體頭(Entity Header)
返回內(nèi)容：即Http請求的信息蛋铆，可以是HTML也可以是圖片等等馋评。
10.3 TCP連接建立和釋放的過程
SYN置1和FIN的報文段要消耗一個序號。
客戶端連接狀態(tài)變遷：CLOSED -> 主動打開,發(fā)送SYN=1 -> SYN_SENT -> 收到服務器的SYN=1和ACK時,發(fā)送三次握手的最后一個ACK
-> ESTABLISHED -> 數(shù)據(jù)傳送 -> 主動關閉 -> 發(fā)送FIN=1,等待確認ACK的到達 -> FIN_WAIT_1 -> 收到確認ACK后 -> FIN_WAIT_2
-> 收到服務器發(fā)送的FIN=1報文刺啦，響應留特，發(fā)送四次揮手的的最后一個確認ACK -> 進入TIME_WAIT狀態(tài)
-> 經(jīng)過2倍報文壽命，TCP刪除連接記錄 -> 回到CLOSED狀態(tài)
客戶端狀態(tài)：CLOSED - SYN_SENT- ESTABLISHED - FIN_WAIT_1 - FIN_WAIT_2 - TIME_WAIT - CLOSED
服務器端連接狀態(tài)變遷：CLOSED -> 被動打開 -> LISTEN -> 收到SYN=1的報文玛瘸，發(fā)送SYN=1和確認ACK -> 進入SYN_RCVD -> 收到三次握手
的最后一個確認ACK -> ESTABLISHED -> 數(shù)據(jù)傳送 -> 數(shù)據(jù)傳送完畢蜕青，收到FIN=1 -> 發(fā)送確認ACK并進入CLOSED_WAIT -> 發(fā)送FIN=1給客戶端 -> LAST_ACK
-> 收到客戶端四次揮手的最后一個確認ACK -> 刪除連接記錄 -> 回到CLOSED狀態(tài)
服務器端：CLOSED - LISTEN - SYN_RCVD - ESTABLISHED - CLOSED_WAIT - LAST_ACK - CLOSED
10.3.1 TCP的三次握手和四次揮手的過程
以客戶端為例
連接建立（三次握手）：首先Client端發(fā)送連接請求報文SYN并進入SYN_SENT狀態(tài)，Server收到后發(fā)送ACK+SYN報文糊渊，并為這次連接分配資源右核。Client端接收到Server端的SYN+ACK后發(fā)送三次握手的最后一個ACK，并分配資源渺绒，連接建立贺喝。
連接釋放（四次揮手）：假設Client端發(fā)起斷開連接請求，首先發(fā)送FIN=1,等待確認ACK的到達 -> FIN_WAIT_1 -> 收到Server端的確認ACK后時 -> FIN_WAIT_2
->收到服務器發(fā)送的FIN=1報文宗兼，響應躏鱼，發(fā)送四次揮手的的最后一個確認ACK ->進入TIME_WAIT狀態(tài)
-> 經(jīng)過2倍報文壽命，TCP刪除連接記錄 -> 回到CLOSED狀態(tài)
10.3.2 為什么連接建立是三次握手殷绍，而連接釋放要四次揮手染苛？
因為當Server端收到Client端發(fā)送的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文主到，其中ACK用來應答茶行，SYN用來同步躯概。但是關閉連接時，當Server端收到FIN報文后畔师，并不會立即關閉socket娶靡，所以先回復一個ACK，告訴Client端“你的FIN我收到了”茉唉，只有等Server端的所有報文發(fā)送完了固蛾，Server端才發(fā)送FIN報文，因此不能一起發(fā)送度陆，故需要四次揮手。
10.3.3 為什么TIME_WAIT狀態(tài)需要2MSL（最大報文段生存時間）才能返回Closed狀態(tài)献幔？
這是因為雖然雙方都同意關閉連接了懂傀，而且四次揮手的報文也都協(xié)調(diào)發(fā)送完畢。但是我們必須假想網(wǎng)絡是不可靠的蜡感，無法保證最后發(fā)送的ACK報文一定被對方收到蹬蚁，因此處于LAST_ACK狀態(tài)下的
Server端可能會因未收到ACK而重發(fā)FIN，所以TIME_WAIT狀態(tài)的作用就是用來重發(fā)可能丟失的ACK報文郑兴。
10.4 Post和Get的區(qū)別
- 安全性上說：get的方式是把數(shù)據(jù)在地址欄中明文的形式發(fā)送犀斋，URL中可見，POST方式對用戶是透明的情连，安全性更高叽粹。
- 數(shù)據(jù)量說：Get傳送的數(shù)據(jù)量較小，一般不能大于2KB却舀，POST傳送的數(shù)據(jù)量更大虫几。
- 適用范圍說：查詢用Get，數(shù)據(jù)添加挽拔、修改和刪除建議Post
- post請求的過程：
- 瀏覽器請求tcp連接（第一次握手）
- 服務器答應進行tcp連接（第二次握手）
- 瀏覽器確認辆脸，并發(fā)送post請求頭（第三次握手，這個報文比較小螃诅，所以http會在此時進行第一次數(shù)據(jù)發(fā)送）
- 服務器返回100 Continue響應
- 瀏覽器發(fā)送數(shù)據(jù)
- 服務器返回200 OK響應
- get請求的過程：
- 瀏覽器請求tcp連接（第一次握手）
- 服務器答應進行tcp連接（第二次握手）
- 瀏覽器確認啡氢，并發(fā)送get請求頭和數(shù)據(jù)（第三次握手，這個報文比較小术裸，所以http會在此時進行第一次數(shù)據(jù)發(fā)送）
- 服務器返回200 OK響應
10.5 Cookie 和 Session的區(qū)別
- cookie數(shù)據(jù)存放在客戶的瀏覽器上倘是，session數(shù)據(jù)放在服務器上。
- cookie不是很安全穗椅，別人可以分析存放在本地的COOKIE并進行COOKIE欺騙
考慮到安全應當使用session辨绊。 - session會在一定時間內(nèi)保存在服務器上。當訪問增多匹表，會比較占用你服務器的性能
考慮到減輕服務器性能方面门坷，應當使用COOKIE宣鄙。 - 單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie默蚌。
- 所以個人建議：
將登陸信息等重要信息存放為SESSION
其他信息如果需要保留冻晤，可以放在COOKIE中
10.6 IO 和 NIO的區(qū)別，NIO優(yōu)點
IO NIO
面向流 面向緩沖
阻塞IO 非阻塞IO
無 選擇器
