極客時間課程
Web協(xié)議詳解與抓包實戰(zhàn)
get post 的區(qū)別
get 一般用于向服務端請求數(shù)據(jù)，一般會有緩存機制，一般將參數(shù)放到url中，也可以放到body中
post 一般用于向服務端提交數(shù)據(jù)，不會緩存，一般將參數(shù)放到body中，也可以將部分參數(shù)放到url中
關于安全性我們常聽到GET不如POST安全，因為POST用body傳輸數(shù)據(jù)，而GET用url傳輸，更加容易看到。但是從攻擊的角度，無論是GET還是POST都不夠安全，因為HTTP本身是明文協(xié)議。每個HTTP請求和返回的每個byte都會在網(wǎng)絡上明文傳播，不管是url，header還是body。這完全不是一個“是否容易在瀏覽器地址欄上看到“的問題
為了避免傳輸中數(shù)據(jù)被竊取，必須做從客戶端到服務器的端端加密。業(yè)界的通行做法就是https——即用SSL協(xié)議協(xié)商出的密鑰加密明文的http數(shù)據(jù)。這個加密的協(xié)議和HTTP協(xié)議本身相互獨立。如果是利用HTTP開發(fā)公網(wǎng)的站點/App，要保證安全，https是最最基本的要求
參考資料： https://www.zhihu.com/question/28586791
webSocket 和 ajax 的區(qū)別
1.生命周期不同。
websocket建立的是長連接，在一個會話中一直保持連接；而ajax是短連接，數(shù)據(jù)發(fā)送和接受完成后就會斷開連接。
2.適用范圍不同
websocket一般用于前后端實時數(shù)據(jù)交互，而ajax前后端非實時數(shù)據(jù)交互。
3.發(fā)起人不同
Ajax技術需要客戶端發(fā)起請求，而WebSocket服務器和客戶端可以相互推送信息。
https 的握手過程
----------------------------------
客戶端發(fā)起https請求 ->
服務端返回給客戶端證書 ->
客戶端驗證證書合法性 ->
如果合法，客戶端生成一個隨機數(shù)，并將該隨機數(shù)用公鑰加密后發(fā)送給服務端 ->
服務端用私鑰解密出隨機數(shù)，將內(nèi)容用隨機數(shù)加密，然后將加密后的內(nèi)容發(fā)送給客戶端 ->
客戶端用之前生成的隨機數(shù)解密獲取內(nèi)容
----------------------------------
如果客戶端驗證證書不合法呢？ ->
會彈出一個警告框，提示證書存在問題，讓用戶選擇是否繼續(xù)
證書簽名過程和如何防止被串改?
http2 的特點
二進制傳輸
Header 壓縮，順便吹了一下哈夫曼編碼
多路復用
服務器推送
緩存類型
### 強制緩存
cache-control、express
### 協(xié)商緩存
304、ETag、modify
關于狀態(tài)碼
301、302、307、308 的區(qū)別
301 永久重定向
302 臨時重定向
303 臨時重定向
發(fā)送Post請求，收到303，直接重定向為get，發(fā)送get請求，不需要向用戶確認
307 臨時重定向
客戶端發(fā)送post請求返回307時，瀏覽器詢問用戶是否再次post
狀態(tài)碼 307 與 302 之間的唯一區(qū)別在于，當發(fā)送重定向請求的時候，307 狀態(tài)碼可以確保請求方法和消息主體不會發(fā)生變化。當響應狀態(tài)碼為 302 的時候，一些舊有的用戶代理會錯誤地將請求方法轉(zhuǎn)換為 GET：使用非 GET 請求方法而返回 302 狀態(tài)碼，Web 應用的運行狀況是不可預測的；而返回 307 狀態(tài)碼時則是可預測的。對于 GET 請求來說，兩種情況沒有區(qū)別。
參考 https://www.cnblogs.com/wuguanglin/p/redirect.html
http http2 https 區(qū)別
111
什么是簡單請求和非簡單請求
非簡單請求下發(fā)起的 options
ww
cookie 跨域時候要如何處理
asdf
xss、csrf 有了解過嗎，如何防范
介紹一下瀏覽器緩存策略
tcp 三次握手
nginx 有了解嗎
扯了一下跨域如何配置/轉(zhuǎn)發(fā)
緩存策略配置
地址重定向配置
