目錄
http 響應碼 301 和 302 代表的是什麼？有什麼區別？
http 響應碼 301 和 302 代表的是什麼？有什麼區別？
301：表示舊地址A的資源已經被永久地移除了（這個資源不可訪問了），搜索引擎在抓取新內容的同時也將舊的網
址交換爲重定向之後的網址；（代表永久性轉移(Permanently Moved)）
302：表示舊地址A的資源還在（仍然可以訪問），這個重定向只是臨時地從舊地址A跳轉到地址B，搜索引擎會抓
取新的內容而保存舊的網址 （代表暫時性轉移(Temporarily Moved )）
forward 和 redirect 的區別？
forward ：請求轉發，不會跳轉頁面，客戶端只發送了一次請求
redirect ：重定向，會跳轉頁面，客戶端發送了兩次請求
簡述 tcp 和 udp的區別？
TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發送數據之前不需要建立連接。
TCP提供可靠的服務。也就是說，通過TCP連接傳送的數據，無差錯，不丟失，不重複，且按序到達;UDP盡最大努
力交付，即不保證可靠交付。
Tcp通過校驗和，重傳控制，序號標識，滑動窗口、確認應答實現可靠傳輸。如丟包時的重發控制，還可以對次序
亂掉的分包進行順序控制。
UDP具有較好的實時性，工作效率比TCP高，適用於對高速傳輸和實時性有較高的通信或廣播通信。
每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信。
TCP對系統資源要求較多，UDP對系統資源要求較少。
tcp 爲什麼要三次握手，兩次不行嗎？爲什麼？
第一次握手：客戶端發信，服務端收到了。此時服務端就會明白客戶端的發信能力和自己收信能力沒問題
第二次握手：服務端發信，客戶端收到了。此時客戶端就會明白服務端的發信和收信能力都是沒問題的、自己收信
和發送能力也是沒問題，但是服務端還不知道自己的發信能力如何，所以需要第三次握手
第三次握手：客戶端發信，服務端收到了。其實第二次握手的時候客戶端已經明白，雙方通信是沒問題的，此次回
應的目的是消除服務端對自己的發信能力，和客戶端收信能力的擔憂
爲了實現可靠數據傳輸， TCP 協議的通信雙方， 都必須維護一個序列號， 以標識發送出去的數據包中， 哪些
是已經被對方收到的。 三次握手的過程即是通信雙方相互告知序列號起始值， 並確認對方已經收到了序列號起始
值的必經步驟。
如果只是兩次握手， 至多隻有連接發起方的起始序列號能被確認， 另一方選擇的序列號則得不到確認。
說一下 tcp 粘包是怎麼產生的？
①. 發送方產生粘包
採用TCP協議傳輸數據的客戶端與服務器經常是保持一個長連接的狀態（一次連接發一次數據不存在粘包），雙方
在連接不斷開的情況下，可以一直傳輸數據；但當發送的數據包過於的小時，那麼TCP協議默認的會啓用Nagle算
法，將這些較小的數據包進行合併發送（緩衝區數據發送是一個堆壓的過程）；這個合併過程就是在發送緩衝區中
進行的，也就是說數據發送出來它已經是粘包的狀態了。
②. 接收方產生粘包
接收方採用TCP協議接收數據時的過程是這樣的：數據到底接收方，從網絡模型的下方傳遞至傳輸層，傳輸層的
TCP協議處理是將其放置接收緩衝區，然後由應用層來主動獲取（C語言用recv、read等函數）；這時會出現一個
問題，就是我們在程序中調用的讀取數據函數不能及時的把緩衝區中的數據拿出來，而下一個數據又到來並有一部
分放入的緩衝區末尾，等我們讀取數據時就是一個粘包。（放數據的速度 > 應用層拿數據速度）
OSI 的七層模型都有哪些？
應用層：網絡服務與最終用戶的一個接口。
表示層：數據的表示、安全、壓縮。
會話層：建立、管理、終止會話。
傳輸層：定義傳輸數據的協議端口號，以及流控和差錯校驗。
網絡層：進行邏輯地址尋址，實現不同網絡之間的路徑選擇。
數據鏈路層：建立邏輯連接、進行硬件地址尋址、差錯校驗等功能。
物理層：建立、維護、斷開物理連接。
get 和 post 請求有哪些區別？
GET在瀏覽器回退時是無害的，而POST會再次提交請求。
GET產生的URL地址可以被Bookmark，而POST不可以。
GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。
GET請求只能進行url編碼，而POST支持多種編碼方式。
GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留。
GET請求在URL中傳送的參數是有長度限制的，而POST麼有。
對參數的數據類型，GET只接受ASCII字符，而POST沒有限制。
GET比POST更不安全，因爲參數直接暴露在URL上，所以不能用來傳遞敏感信息。
GET參數通過URL傳遞，POST放在Request body中。
如何實現跨域？
方式一：圖片ping或script標籤跨域
圖片ping常用於跟蹤用戶點擊頁面或動態廣告曝光次數。
script標籤可以得到從其他來源數據，這也是JSONP依賴的根據。
方式二：JSONP跨域
JSONP（JSON with Padding）是數據格式JSON的一種“使用模式”，可以讓網頁從別的網域要數據。根據
XmlHttpRequest 對象受到同源策略的影響，而利用 <script>元素的這個開放策略，網頁可以得到從其他來源
動態產生的JSON數據，而這種使用模式就是所謂的 JSONP。用JSONP抓到的數據並不是JSON，而是任意的
JavaScript，用 JavaScript解釋器運行而不是用JSON解析器解析。所有，通過Chrome查看所有JSONP發送的
Get請求都是js類型，而非XHR。
缺點：
只能使用Get請求，不能註冊success、error等事件監聽函數，不能很容易的確定JSONP請求是否失敗，JSONP是
從其他域中加載代碼執行，容易受到跨站請求僞造的攻擊，其安全性無法確保
方式三：CORS
Cross-Origin Resource Sharing（CORS）跨域資源共享是一份瀏覽器技術的規範，提供了 Web 服務從不同
域傳來沙盒腳本的方法，以避開瀏覽器的同源策略，確保安全的跨域數據傳輸。現代瀏覽器使用CORS在API容器如
XMLHttpRequest來減少HTTP請求的風險來源。與 JSONP 不同，CORS 除了 GET 要求方法以外也支持其他的
HTTP 要求。服務器一般需要增加如下響應頭的一種或幾種：
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
跨域請求默認不會攜帶Cookie信息，如果需要攜帶，請配置下述參數：
"Access-Control-Allow-Credentials": true
// Ajax設置
"withCredentials": true
說一下 JSONP 實現原理？
jsonp 即 json+padding，動態創建script標籤，利用script標籤的src屬性可以獲取任何域下的js腳本，通
過這個特性(也可以說漏洞)，服務器端不在返貨json格式，而是返回一段調用某個函數的js代碼，在src中進行了調用，這樣實現了跨域。