2021春招衝刺-1225 TCP與UDP | 單例模式 | 迴流與重繪

2021春招衝刺

12.25日

前言：今天的內容感受難起來了，第一眼沒有一個會的，並且每一個問題其實都值得單獨地寫一篇博客來從原理性地記錄 > - <，可是爲了概括方便仍是之後積累多了再專門再寫相關分類的博客吧。
寫到單例模式的感想：太多了55555 從零開始學習因此這一篇寫了兩天才寫完

1.計算機網絡 | TCP與UDP的區別

邊記錄邊學，參考了不少博客，主要有 參考博客1 | 參考博客2 | 參考博客3 | 鄒大佬的博客

1.關於TCP/IP

在介紹TCP與UDP以前，首先要介紹一下TCP/IP。它是一個協議簇，而TCP與UDP正是其中有兩個具備表明性的傳輸層協議。TCP/IP按照自底向上能夠分爲四層： 鏈路層、網絡層、傳輸層和應用層。

• 鏈路層: 負責封裝和解封裝IP報文，發送和接受ARP/RARP報文等
• 網絡層: 負責路由以及把分組報文發送給目標網絡或主機。
  包括Internet協議（IP）、Internet控制信息協議（ICMP）、地址解析協議（ARP）、反向地址解析協議（RARP）
• 傳輸層: 負責對報文進行分組和重組，並以TCP或UDP協議格式封裝報文。
• 應用層: 負責向用戶提供應用程序好比:
  • 超文本傳輸協議(HTTP): 萬維網的基本協議;
  • 件傳輸(TFTP): 簡單文件傳輸協議;
  • 遠程登陸(Telnet): 提供遠程訪問其它主機功能, 它容許用戶登陸internet主機，並在這臺主機上執行命令;
  • 域名系統(DNS): 該系統用於在internet中將域名及其公共廣播的網絡節點轉換成IP地址。
  • 網絡管理(SMTP): 該協議提供了監控網絡設備的方法， 以及配置管理,統計信息收集,性能管理及安全管理等；

2.UDP

UDP協議全稱是用戶數據報協議，在網絡中它與TCP協議同樣用於處理數據包，是一種無鏈接的協議。在OSI模型中，在第四層——傳輸層，處於IP協議的上一層。

• 特色
  • 無鏈接:
    知道對端的IP和端口號就直接進行傳輸, 不須要創建鏈接。而TCP須要TCP在發送數據前進行三次握手創建鏈接。
    同時所以也不須要維護鏈接狀態，包括收發狀態等， 一臺服務機可同時向多個客戶機傳輸相同的消息。
  • 不可靠:
    沒有確認機制, 沒有重傳機制，沒有擁塞機制; 若是由於網絡故障該段沒法發到對方, UDP協議層不會給應用層返回任何錯誤信息而致使丟包。
    同時不關心發送端是否收到了數據,也對數據進行校驗與備份。
  • 面向報文:
    不可以靈活的控制讀寫數據的次數和數量，應用層交給UDP多長的報文, UDP原樣發送, 既不會拆分, 也不會合並，而是保留這些報文的邊界。所以，應用程序須要選擇合適的報文大小。
  • 有單播，多播，廣播的功能:
    UDP 不止支持一對一的傳輸方式，一樣支持一對多，多對多，多對一的方式，也就是說 UDP 提供了單播，多播，廣播的功能。
  • 頭部開銷小:
    UDP 的首部開銷小，只有 8 個字節，比 TCP 的 20 個字節的首部要少得多。
    UDP 頭部包含了如下幾個數據：
    1）兩個十六位的端口號，分別爲源端口（可選字段）和目標端口。
    2）整個數據報文的長度（十六位）。
    3）整個數據報文的檢驗和（IPv4 可選 字段），該字段用於發現頭部信息和數據中的錯誤（十六位）。
    所以 UDP 的頭部開銷小，只有八字節，相比 TCP 的至少二十字節要少得多，在傳輸數據報文時是很高效的。
    
• 適用場景
  對當前網絡通信質量要求不高的時候,實時性要求高的地方均可以看到 UDP 的身影，要求網絡通信速度儘可能的快，這時就使用UDP。

3.TCP

TCP協議全稱是傳輸控制協議是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議，由 IETF 的RFC793定義。

• TCP創建鏈接過程
  
  三次握手特色：

  • 沒有應用層的數據 ,SYN這個標誌位只有在TCP創建鏈接時纔會被置1 ,握手完成後SYN標誌位被置0。

  第一次握手:

  • 客戶端向服務端發送鏈接請求報文段（SYN J）。該報文段中包含自身的數據通信初始序號。請求發送後，客戶端便進入 SYN-SENT（請求鏈接）狀態。

  第二次握手:

  • 服務端收到鏈接請求報文段後，若是贊成鏈接，則會發送一個應答，該應答中也會包含自身的數據通信初始序號（SYN K,ACK,seq,ack=J+1)，發送完成後便進入 SYN-RECEIVED 狀態。

  第三次握手:

  • 當客戶端收到鏈接贊成的應答後，還要向服務端發送一個確認報文（ACK，seq，ack=K+1）。發送完畢，客戶端和服務端都進入ESTABLISHED狀態，此時鏈接創建成功。

Question:爲何 TCP 創建鏈接須要三次握手，而不是兩次:
1.防止出現失效的鏈接請求報文段被服務端接收的狀況，從而產生錯誤
2.客戶端連接超時，會從新發送一次鏈接請求。當兩個SYN都抵達發送了ACK時，雖然第一個ACK會被放棄，可是服務器端會分配資源並一直維持這個資源，形成浪費。

• TCP斷開鏈接過程
  揮手特色:

  • TCP 是全雙工的，在斷開鏈接時兩端都須要發送 FIN 和 ACK。

  第一次揮手:

  • 當主機A(客戶端) 完成數據傳輸後,將控制位FIN置1，提出中止TCP鏈接的請求

  第二次揮手:

  • B(服務端) 收到鏈接釋放請求後，會告訴應用層要釋放 TCP 連接。而後會發送 ACK 包（ack M+1），並進入 CLOSE_WAIT 狀態。
  • 此時代表 A 到 B 的鏈接已經釋放，再也不接收 A 發的數據了。可是由於 TCP 鏈接是雙向的，因此 B 仍舊能夠發送數據給 A。

  第三次揮手：

  • B果此時還有沒發完的數據會繼續發送,完畢後會向 A 發送鏈接釋放請求(FIN N)，而後 B 便進入 LAST-ACK 狀態。

  第四次揮手：

  • A 收到釋放請求後，向 B 發送確認應答，此時 A 進入 TIME-WAIT 狀態。
  • 該狀態會持續 2MSL（最大段生存期，指報文段在網絡中生存的時間，超時會被拋棄） 時間，若該時間段內沒有 B 的重發請求的話，就進入 CLOSED 狀態。當 B 收到確認應答後，也便進入 CLOSED 狀態。

• TCP頭部格式
  

  • 源端口 16位；目標端口 16位；序列號 32位；迴應序號 32位；TCP頭長度 4位；reserved 6位；控制代碼 6位；窗口大小 16位；偏移量 16位；校驗和 16位;選項 32位(可選)；
  • 這樣咱們得出了TCP包頭的最小長度，爲20字節。

• TCP特色

  • 面向鏈接的運輸層協議: 發送數據以前必須在兩端創建鏈接，即進行三次握手。
  • 可靠傳輸:
    • 提供擁塞控制，當網絡出現擁塞的時候，TCP可以減少向網絡注入數據的速率和數量，緩解擁塞。
    • 誤碼靠的是TCP的段編號以及確認號判斷丟包。TCP爲了保證報文傳輸的可靠，就給每一個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。而後接收端實體對已成功收到的字節發回一個相應的確認(ACK)；若是發送端實體在合理的往返時延(RTT)內未收到確認，那麼對應的數據（假設丟失了）將會被重傳。
  • 提供全雙工通訊: TCP容許通訊雙方的應用程序在任什麼時候候都能發送數據，由於TCP鏈接的兩端都設有緩存，用來臨時存放雙向通訊的數據。固然，TCP能夠當即發送一個數據段，也能夠緩存一段時間以便一次發送更多的數據段（最大的數據段大小取決於MSS）
  • 僅支持單播傳輸: 每條TCP傳輸鏈接只能有兩個端點，只能進行點對點的數據傳輸，不支持多播和廣播傳輸方式。
  • 面向字節流: TCP不像UDP同樣那樣一個個報文獨立地傳輸，而是在不保留報文邊界的狀況下以字節流方式進行傳輸。

TCP與UDP的區別

	TCP	UDP
是否鏈接	面向鏈接，創建鏈接3次握手，斷開鏈接4次揮手	無鏈接
是否可靠	可靠傳輸，使用流量控制和擁塞控制	不可靠傳輸，不使用流量控制和擁塞控制
鏈接對象個數	只能是一對一通訊	支持一對一，一對多，多對一和多對多交互通訊
傳輸方式	面向字節流	面向報文
首部開銷	首部最小20字節，最大60字節	首部開銷小，僅8字節
適用場景	適用於要求可靠傳輸的應用，例如文件傳輸	適用於實時應用（IP電話、視頻會議、直播等）

---

2.設計模式 | 用Class與Function的方式分別實現一個單例模式的案例

每次都要先從原理開始搞，啥都沒學，先去弄懂什麼是單例模式了（淚目）接下來的內容所有來自菜鳥教程以及 搬運博客

單例模式

單例模式（Singleton Pattern）是 Java 中最簡單的設計模式之一。這種類型的設計模式屬於建立型模式，它提供了一種建立對象的最佳方式。
這種模式涉及到一個單一的類，該類負責建立本身的對象，同時確保只有單個對象被建立。這個類提供了一種訪問其惟一的對象的方式，能夠直接訪問，不須要實例化該類的對象。

注意

• 單例類只能有一個實例。
• 單例類必須本身建立本身的惟一實例。
• 單例類必須給全部其餘對象提供這一實例。

實現

• 將該類的構造方法定義爲私有方法，這樣其餘處的代碼就沒法經過調用該類的構造方法來實例化該類的對象，只有經過該類提供的靜態方法來獲得該類的惟一實例；
• 在該類內提供一個靜態方法，當咱們調用這個方法時，若是類持有的引用不爲空就返回這個引用，若是類保持的引用爲空就建立該類的實例並將實例的引用賦予該類保持的引用

優勢

• 在內存裏只有一個實例，減小了內存的開銷，尤爲是頻繁的建立和銷燬實例（好比管理學院首頁頁面緩存）。
• 避免對資源的多重佔用（好比寫文件操做）。
• 爲整個系統提供一個全局訪問點。

缺點

• 沒有接口，不能繼承，與單一職責原則衝突，一個類應該只關心內部邏輯，而不關心外面怎麼樣來實例化。
• 若是實例化的對象長時間不被利用，系統會認爲該對象是垃圾而被回收，這可能會致使對象狀態的丟失；
• 濫用單例將帶來一些負面問題，如爲了節省資源將數據庫鏈接池對象設計爲的單例類，可能會致使共享鏈接池對象的程序過多而出現鏈接池溢出；
• 不適用於變化頻繁的對象；

適用場景

• 要求生產惟一序列號。
• 須要頻繁實例化而後銷燬的對象。
• 建立對象時耗時過多或者耗資源過多，但又常常用到的對象，好比 I/O 與數據庫的鏈接等。
• 方便資源相互通訊的環境。

構造方法 · 使用class

• 餓漢式:
  在類裝載的時候就完成實例化。避免了線程同步問題。一樣，在類裝載的時候就完成實例化，沒有達到Lazy Loading的效果。若是從始至終從未使用過這個實例，則會形成內存的浪費。

  // 餓漢式單例
  public class Singleton1 {
  
      // 指向本身實例的私有靜態引用，主動建立
      private static Singleton1 singleton1 = new Singleton1();
  
      // 私有的構造方法
      private Singleton1(){}
  
      // 以本身實例爲返回值的靜態的公有方法，靜態工廠方法
      public static Singleton1 getSingleton1(){
          return singleton1;
      }
  }

• 懶漢式:
  單例實例被延遲加載，即只有在真正使用的時候纔會實例化一個對象並交給本身的引用。可是隻能在單線程下使用。若是在多線程下，一個線程進入了if (singleton == null)判斷語句塊，還將來得及往下執行，另外一個線程也經過了這個判斷語句，這時便會產生多個實例。因此在多線程環境下不可以使用這種方式。
  看了鄒大佬的博客感受有點像懶漢法，若是不存在就建立，存在就返回？。

  // 懶漢式單例
  public class Singleton2 {
  
     // 指向本身實例的私有靜態引用
     private static Singleton2 singleton2;
  
     // 私有的構造方法
     private Singleton2(){}
  
     // 以本身實例爲返回值的靜態的公有方法，靜態工廠方法
     //固然，可使用同步方法public static synchronized Singleton2 getInstance2()，可是效率不高
     public static Singleton2 getSingleton2(){    
         // 被動建立，在真正須要使用時纔去建立
         if (singleton2 == null) {
             singleton2 = new Singleton2();
         }
         return singleton2;
     }   
  }

• c#提供的靜態初始化

  //阻止發生派生，而派生可能會增長實例
   public sealed class Singleton
      {
      private Singleton() { }
  
      //在第一次引用類的任何成員時建立實例，公共語言運行庫負責處理變量初始化
      private static readonly Singleton instance=new Singleton();
      
      public static Singleton GetInstance()
      {
          return instance;
      }
  }

• java內部類式單例類

  public class Singleton     
  { 
      private Singleton(){}
  
      private class SingletonHoledr(){ 
          private static Singleton instance = new Singleton(); 
      }     
      private static Singleton getInstance(){    
          return SingletonHoledr.instance;    
      }     
  }

• 雙檢鎖方法因爲nstance = new Singleton()這行代碼在不一樣編譯器上的行爲是沒法預知的，致使在不少平臺和優化編譯器上是錯誤的，在此就不記錄。實際上是由於大半夜電腦沒電了，記錄一下function閉包實現就byebye

構造方法 · 使用function

直接去學長博客看了參考答案，即便用閉包的方法。

function SingleDog() {
    this.show = function () {
       console.log('w w w w')
    }
}
SingleDog.getInstance = (function () {
   let instance = null
   return function () {
       if (!instance) {
          instance = new SingleDog()
      }
      return instance
  }
})()

let a = SingleDog.getInstance()
let b = SingleDog.getInstance()
console.log(a === b) // true

---

3.瀏覽器 | 什麼是迴流與重繪?

瀏覽器渲染的流程

這一點在16號關於css的問題中其實已經提到，此處在那基礎上進行一點補充

• 在頁面加載時，瀏覽器解析html文件，生成DOM Tree(含了全部HTML標籤，包括display:none隱藏，還有用JS動態添加的元素等)
• 瀏覽器解析CSS文件生成CSSOM Tree
• 將Dom Tree和CSSOM Tree結合，生成Render Tree (render tree能識別樣式，且其中每一個NODE都有本身的style，並且render tree不包含隱藏的節點。好比display:none的節點，還有head節點。由於這些節點不會用於呈現，並且不會影響呈現的)
• 根據Render Tree渲染繪製，將像素渲染到屏幕上。

什麼是迴流(Layout)（又稱重排）

• 當渲染樹中的一部分或者所有由於元素的尺寸、佈局、隱藏等改變而須要從新構建的時候，這時候就會發生迴流,獲得節點的幾何信息（位置、大小）。
• 每一個頁面都至少發生一次迴流，也就是頁面第一次加載的時候，由於此時正在構建render tree。
• 在迴流的時候，瀏覽器會使渲染樹中受到影響的元素部分失效，並從新繪製這個部分的渲染樹。

什麼是重繪(Painting)

• 完成迴流之後，瀏覽器會從新繪製受到影響的部分元素到屏幕中，這個過程就是重繪，獲得節點的絕對像素。
• 當render tree中的一些元素須要更新屬性，而這些屬性只是影響元素的外觀，風格，而不會影響佈局的，好比background-color。則就叫稱爲重繪。

何時發生迴流與重繪

• 發生迴流
  • 添加或刪除可見的DOM元素
  • 元素的位置發生變化
  • 元素的尺寸發生變化（包括外邊距、內邊框、邊框大小、高度和寬度等）
  • 內容發生變化，好比文本變化或圖片被另外一個不一樣尺寸的圖片所替代
  • 頁面第一次渲染的時候
  • 瀏覽器的窗口尺寸變化（由於迴流是根據視口的大小來計算元素的位置和大小的）
• 發生迴流必定會引發重繪，可是重繪不必定發生迴流
  • 好比背景色、文字色、可見性(可見性這裏特指形如visibility: hidden這樣不改變元素位置和存在性的、單純針對可見性的操做，注意與display:none進行區分)等

---

4.瀏覽器 | 瀏覽器中存儲數據的方案有哪幾種

本身只粗略地知道名詞並使用，此次好好了解了一下原理 參考博客

一、cookie

Cookie是指某些網站爲了辨別用戶身份、進行 session 跟蹤而存儲在用戶本地終端上的數據（一般通過加密）。
Cookie是由服務器生成，客戶端進行維護和存儲。經過Cookie，可讓服務器知道請求是來源自哪一個客戶端並對客戶端狀態進行維護。

• cookie的屬性
  • value：值(用於保存用戶登陸狀態等)
  • http-only：不能經過js訪問cookie
  • secure： 只能在協議爲https的請求中攜帶
  • same-site： 規定瀏覽器不能在跨域請求中攜帶，減小CSRF攻擊
  • Max-Age: 設置cookie失效時所須要的時間
  • Expires: 過時時間。不設置的時候規定關閉瀏覽器時失效
  • Domain: 指定了cookie能夠送達的主機名
• cookie的缺陷
  • Cookie不夠大。Cookie的大小限制在4KB左右，對於複雜的存儲需求來講是不夠用。
  • 過多的Cookie會帶來巨大的性能/資源浪費。
  • 能夠在客戶端直接獲取到:有XSS,CSRF等安全問題

二、localStorage

LocalStorage是WebStorage之一，它保存數據始終有效，窗口或瀏覽器關閉也一直保存，除非手動刪除。所以可用做持久保存數據,咱們更傾向於用它來存儲一些內容穩定的資源如base64圖片。
localStorage存貯限制大小爲5MB左右，遠遠大於cookie。同時它僅在客戶端使用，不與服務端進行通訊。

// 使用方法寫入 
localStorage.setItem(key, value);
// 使用屬性存儲數據
locaStorage.say = "Hello world"
//讀取
localStorage.getItem(key);
var say = localStorage.say;
//刪除 
localStorage.removeItem(value);

三、sessionStorage

SessionStorage保存的數據用於瀏覽器的一次會話，當會話結束（一般是該窗口關閉或者新開窗口時），數據就會被清空。
和localStorage同樣，存貯限制大小爲5MB左右，也僅在客戶端使用，不與服務端進行通訊。

• 區別：LocalStorage只要在相同的協議、相同的主機名、相同的端口下，就能讀取/修改到同一份LocalStorage數據。而SessionStorage則比LocalStorage要更嚴苛一點，除了協議、主機名、端口外，還要求在同一窗口（也就是瀏覽器的標籤頁）下。
  

四、IndexedDB

IndexedDB能夠看做是一個運行在瀏覽器上的非關係型數據庫。

• 特色
  • 鍵值對存儲
    IndexedDB內部採用對象倉庫（Object Store）存放數據，全部類型的數據均可以直接存入，包括JavaScript對象。在對象倉庫中，數據以鍵值對的形式保存，每個數據記錄都有對應的主鍵，且主鍵是惟一的，不可重複，不然會拋出錯誤。
  • 異步
    在操做時不會鎖死瀏覽器（異步線程，不會掛起其餘線程），用戶依然能夠能夠進行其餘操做，爲了防止讀寫大量數據的時候拖慢網頁的表現性能。
  • 支持事務
    這意味着在一系列的操做步驟中，只要有一步失敗，整個事務就會取消，數據庫將回滾到事務發生以前的狀態。
  • 同源限制
    每個數據庫都嚴格對應建立它的域名。網頁只能訪問自身域名下面的數據庫，而不能訪問跨域的數據庫
  • 存儲空間大
    通常來講不小於250MB，甚至沒有上限
  • 支持二進制存儲
    不只能夠存儲字符串，還能夠存儲二進制數據
• 使用方法 見參考博客或者API

---

5.css | 實現一個雪花飄落的動畫

• html元素：

  <div id="snowzone">
      <img src="./snow.jpg" class="snowDown">
  </div>

• css代碼：

  .snowDown {
      animation: snowDown 2s linear infinite normal;
      -webkit-animation: snowDown 2s linear infinite normal;
      position: relative;
  }
  
  @keyframes snowDown {
      from {
          opacity: 1;
          top: 0;
      }
      to {
          opacity: 0;
          top: 300px;
          transform:rotate(50deg) translateX(100px) scale(0.7,0.7);
      }
  }

• 原理：
  主要利用了雪花圖片的animation屬性與keyframs進行動畫變化。在transform屬性中能夠調整旋轉角度、位置偏移、大小等。雖然貌似rotate的z軸旋轉錨點不在圖片正中心，所以致使rotate角度過大的話即便設置了translate也會在偏移事後從新旋轉回原x位置。

• 效果：