網絡與TCP/IP
1、TCP與UDP區別總結：
1、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發送數據之前不需要建立連接
2、TCP提供可靠的服務。也就是說，通過TCP連接傳送的數據，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保證可靠交付
Tcp通過校驗和，重傳控制，序號標識，滑動窗口、確認應答實現可靠傳輸。如丟包時的重發控制，還可以對次序亂掉的分包進行順序控制。
3、UDP具有較好的實時性，工作效率比TCP高，適用於對高速傳輸和實時性有較高的通信或廣播通信
4. 每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信
5、TCP對系統資源要求較多，UDP對系統資源要求較少。
2、爲什麼UDP有時比TCP更有優勢?
UDP以其簡單、傳輸快的優勢，在越來越多場景下取代了TCP,如實時遊戲。
（1）網速的提升給UDP的穩定性提供可靠網絡保障，丟包率很低，如果使用應用層重傳，能夠確保傳輸的可靠性。
（2）TCP爲了實現網絡通信的可靠性，使用了複雜的擁塞控制算法，建立了繁瑣的握手過程，由於TCP內置的系統協議棧中，極難對其進行改進。
採用TCP，一旦發生丟包，TCP會將後續的包緩存起來，等前面的包重傳並接收到後再繼續發送，延時會越來越大，基於UDP對實時性要求較爲嚴格的情況下，採用自定義重傳機制，能夠把丟包產生的延遲降到最低，儘量減少網絡問題對遊戲性造成影響。
TCP的三次握手與四次揮手
建立TCP需要三次握手才能建立，而斷開連接則需要四次握手。整個過程如下圖所示：
建立連接的過程：
TCP 連接是通過三次握手進行初始化的。三次握手的目的是同步連接雙方的序列號和確認號並交換 TCP 窗口大小信息。以下步驟概述了通常情況下客戶端計算機聯繫服務器計算機的過程：
1. 客戶端向服務器發送一個SYN置位的TCP報文，其中包含連接的初始序列號x和一個窗口大小（表示客戶端上用來存儲從服務器發送來的傳入段的緩衝區的大小）。
2. 服務器收到客戶端發送過來的SYN報文後，向客戶端發送一個SYN和ACK都置位的TCP報文，其中包含它選擇的初始序列號y、對客戶端的序列號的確認x+1和一個窗口大小（表示服務器上用來存儲從客戶端發送來的傳入段的緩衝區的大小）。
3. .客戶端接收到服務器端返回的SYN+ACK報文後，向服務器端返回一個確認號y+1和序號x+1的ACK報文，一個標準的TCP連接完成。
斷開連接的過程：
【注意】中斷連接端可以是Client端，也可以是Server端。
假設Client端發起中斷連接請求，也就是發送FIN報文。Server端接到FIN報文後，意思是說"我Client端沒有數據要發給你了"，但是如果你還有數據沒有發送完成，則不必急着關閉Socket，可以繼續發送數據。所以你先發送ACK，"告訴Client端，你的請求我收到了，但是我還沒準備好，請繼續你等我的消息"。這個時候Client端就進入FIN_WAIT狀態，繼續等待Server端的FIN報文。當Server端確定數據已發送完成，則向Client端發送FIN報文，"告訴Client端，好了，我這邊數據發完了，準備好關閉連接了"。Client端收到FIN報文後，"就知道可以關閉連接了，但是他還是不相信網絡，怕Server端不知道要關閉，所以發送ACK後進入TIME_WAIT狀態，如果Server端沒有收到ACK則可以重傳。“，Server端收到ACK後，"就知道可以斷開連接了"。Client端等待了2MSL後依然沒有收到回覆，則證明Server端已正常關閉，那好，我Client端也可以關閉連接了。Ok，TCP連接就這樣關閉了！
整個過程Client端所經歷的狀態：
Server端所經歷的過程：
【注意】 在TIME_WAIT狀態中，如果TCP client端最後一次發送的ACK丟失了，它將重新發送。TIME_WAIT狀態中所需要的時間是依賴於實現方法的。典型的值爲30秒、1分鐘和2分鐘。等待之後連接正式關閉，並且所有的資源(包括端口號)都被釋放。
【問題1】爲什麼連接的時候是三次握手，關閉的時候卻是四次握手？
答：因爲當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。
【問題2】爲什麼TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？
答：雖然按道理，四個報文都發送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假象網絡是不可靠的，有可以最後一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。
【問題3】爲什麼不能用兩次握手進行連接？
答：3次握手完成兩個重要的功能，既要雙方做好發送數據的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序列號進行協商，這個序列號在握手過程中被髮送和確認。
現在把三次握手改成僅需要兩次握手，死鎖是可能發生的。作爲例子，考慮計算機S和C之間的通信，假定C給S發送一個連接請求分組，S收到了這個分組，併發 送了確認應答分組。按照兩次握手的協定，S認爲連接已經成功地建立了，可以開始發送數據分組。可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S 是否已準備好，不知道S建立什麼樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認爲連接還未建立成功，將忽略S發來的任何數據分 組，只等待連接確認應答分組。而S在發出的分組超時後，重複發送同樣的分組。這樣就形成了死鎖。
TCP重發機制，Nagle算法
nagle 算法是 發送端 收到前一個報文的確認然後再發送下一個tcp數據。這樣可以避免大量的小數據。 TCP_NODELAY選項控制。
Delay ACK是 接收端 在等待超時（還有其他發送ack確認的時機） 然後才發送ACK給客戶端。
CORK算法 是 發送端 儘可能的進行數據的組包，以最大mtu傳輸，如果發送的數據包大小過小則如果在0.6~0.8S範圍內都沒能組裝成一個MTU時，直接發送。
TCP的擁塞控制使用的算法和具體過程
https與http的區別？如何實現加密傳輸？加解密方式？
https：在http(超文本傳輸協議)基礎上提出的一種安全的http協議，因此可以稱爲安全的超文本傳輸協議。http協議直接放置在TCP協議之上，而https提出在http和TCP中間加上一層加密層。從發送端看，這一層負責把http的內容加密後送到下層的TCP，從接收方看，這一層負責將TCP送來的數據解密還原成http的內容。
瀏覽器中輸入一個URL發生什麼，用到哪些協議？
在學習前端的過程中經常看到這樣一個問題：當你在瀏覽器中輸入url後發生了什麼？下面是個人學習過程中的總結，供個人複習使用，如有理解不正確或不足的地方希望大家指出。
先上一張腦圖：
瀏覽器中輸入url後發生了什麼
我將該過程分爲了以下六步：
1. DNS域名解析
- 在瀏覽器DNS緩存中搜索
- 在操作系統DNS緩存中搜索
- 讀取系統hosts文件，查找其中是否有對應的ip
- 向本地配置的首選DNS服務器發起域名解析請求
2. 建立TCP連接
爲了準確地傳輸數據，TCP協議採用了三次握手策略。發送端首先發送一個帶SYN（synchronize）標誌的數據包給接收方，接收方收到後，回傳一個帶有SYN/ACK(acknowledegment)標誌的數據包以示傳達確認信息。最後發送方再回傳一個帶ACK標誌的數據包，代表握手結束。在這過程中若出現問題中斷，TCP會再次發送相同的數據包。
TCP是一個端到端的可靠的面向連接的協議，所以HTTP基於傳輸層TCP協議不用擔心數據的傳輸的各種問題。
3. 發起HTTP請求
請求方法：
- GET:獲取資源
- POST:傳輸實體主體
- HEAD:獲取報文首部
- PUT:傳輸文件
- DELETE:刪除文件
- OPTIONS:詢問支持的方法
- TRACE:追蹤路徑
請求報文：
請求報文
4. 接受響應結果
狀態碼：
- 1**：信息性狀態碼
- 2**：成功狀態碼
200：OK 請求正常處理
204：No Content請求處理成功，但沒有資源可返回
206：Partial Content對資源的某一部分的請求 - 3**：重定向狀態碼
301：Moved Permanently 永久重定向
302：Found 臨時性重定向
304：Not Modified 緩存中讀取 - 4**：客戶端錯誤狀態碼
400：Bad Request 請求報文中存在語法錯誤
401：Unauthorized需要有通過Http認證的認證信息
403：Forbidden訪問被拒絕
404：Not Found無法找到請求資源 - 5**：服務器錯誤狀態碼
500：Internal Server Error 服務器端在執行時發生錯誤
503：Service Unavailable 服務器處於超負載或者正在進行停機維護
響應報文：
響應報文
5. 瀏覽器解析html
瀏覽器按順序解析html文件，構建DOM樹，在解析到外部的css和js文件時，向服務器發起請求下載資源，若是下載css文件，則解析器會在下載的同時繼續解析後面的html來構建DOM樹，則在下載js文件和執行它時，解析器會停止對html的解析。這便出現了js阻塞問題。
預加載器：
當瀏覽器被腳本文件阻塞時，預加載器（一個輕量級的解析器）會繼續解析後面的html，尋找需要下載的資源。如果發現有需要下載的資源，預加載器在開始接收這些資源。預加載器只能檢索HTML標籤中的URL，無法檢測到使用腳本添加的URL，這些資源要等腳本代碼執行時纔會獲取。
注: 預解析並不改變Dom樹，它將這個工作留給主解析過程
瀏覽器解析css，形成CSSOM樹，當DOM樹構建完成後，瀏覽器引擎通過DOM樹和CSSOM樹構造出渲染樹。渲染樹中包含可視節點的樣式信息（不可見節點將不會被添加到渲染樹中，如：head元素和display值爲none的元素）
值得注意的是，這個過程是逐步完成的，爲了更好的用戶體驗，渲染引擎將會儘可能早的將內容呈現到屏幕上，並不會等到所有的html都解析完成之後再去構建和佈局render樹。它是解析完一部分內容就顯示一部分內容，同時，可能還在通過網絡下載其餘內容。
6. 瀏覽器佈局渲染
- 佈局：通過計算得到每個渲染對象在可視區域中的具體位置信息（大小和位置），這是一個遞歸的過程。
- 繪製：將計算好的每個像素點信息繪製在屏幕上
在頁面顯示的過程中會多次進行Reflow和Repaint操作，而Reflow的成本比Repaint的成本高得多的多。因爲Repaint只是將某個部分進行重新繪製而不用改變頁面的佈局，如：改變了某個元素的背景顏色。而如果將元素的display屬性由block改爲none則需要Reflow。
減少rpaint和reflow 方法