分佈式通信基礎

OSI模型

TCP三次握手

• 握手過程

  • 第一次握手：Client將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。
  • 第二次握手：Server收到數據包後由標誌位SYN=1知道Client請求建立連接，Server將標誌位SYN和ACK都置爲1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認連接請求，Server進入SYN_RCVD狀態。
  • 第三次握手：Client收到確認後，檢查ack是否爲J+1，ACK是否爲1，如果正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否爲K+1，ACK是否爲1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間可以開始傳輸數據了。

• SYN攻擊

  • 在三次握手過程中，Server發送SYN-ACK之後，收到Client的ACK之前的TCP連接稱爲半連接（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。

  • SYN攻擊就是Client在短時間內僞造大量不存在的IP地址，並向Server不斷地發送SYN包，Server回覆確認包，並等待Client的確認，由於源地址是不存在的，因此，Server需要不斷重發直至超時，這些僞造的SYN包將佔用未連接隊列，導致正常的SYN請求因爲隊列滿而被丟棄，從而引起網絡堵塞甚至系統癱瘓。

  • SYN攻擊是一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連接狀態且源IP地址是隨機的，則可以斷定遭到SYN攻擊了，使用如下命令可以讓之現行：

    # netstat -nap | grep SYN_RECV
    

TCP四次揮手

由於TCP連接是全雙工的，因此每個方向都要單獨發起關閉。關閉後該方向將不再接收數據，但是依然可以發送數據。

• 第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。
• 第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。
• 第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。
• 第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號爲收到序號+1，Server進入CLOSED狀態，完成四次揮手。

數據傳輸

• 單工 —> 只有一端可以發送數據
• 半雙工 —> 兩端都可以發送數據，但不可以同時發送數據
• 全雙工 —> 兩端可以同時發送數據 (TCP是全雙工)

TCP通信原理

• 每個TCP Socket的內核中都有一個發送緩衝區和一個接收緩衝區，TCP的全雙工的工作模式及TCP的滑動窗口就是依賴於這兩個獨立的Buffer和該Buffer的填充狀態。

• 接收端
  若應用進程一直沒有調用Socket的read方法進行讀取，那麼該數據會一直被緩存在接收緩衝區內。
  Socket的read()所要做的工作，就是把內核接收緩衝區中的數據複製到應用層用戶的Buffer裏。

• 發送端
  Socket的send()發送數據的時候，是將數據從應用層的Buffer中複製到Socket的內核發送緩衝區，然後返回。換句話說，send()返回時，數據不一定會被髮送到對端。

什麼是滑動窗口協議

• 發送方和接收方都會維護一個數據幀的序列，這個序列被稱作窗口。發送方的窗口大小由接收方確認，目的是控制發送速度，以免接收方的緩存不夠大導致溢出，同時控制流量也可以避免網絡擁塞。

• 圖中的4,5,6號數據幀已經被髮送出去，但是未收到關聯的ACK，7,8,9幀則是等待發送。可以看出發送端的窗口大小爲6，這是由接受端告知的（事實上必須考慮擁塞窗口cwnd，這裏暫且考慮cwnd>rwnd）。

• 如果發送端收到4號ACK，則窗口的左邊緣向右收縮，窗口的右邊緣則向右擴展，此時窗口就向前“滑動了”，即數據幀10也可以被髮送

BIO原理

• 如果接收緩衝區爲空，則調用Socket的read方法的線程會阻塞，直到有數據進入接收緩衝區
• 如果待發送的數據長度大於發送緩衝區空餘長度，則會阻塞在write方法上，直到發送緩衝區中的報文被髮送到網絡上
• 傳統的Socket阻塞模式直接導致每個Socket都必須綁定一個線程來操作數據，參與通信的任意一方如果處理數據的速度較慢，會直接拖累到另一方，導致另一方的線程不得不浪費大量的時間在I/O等待上，所以這就是Socket阻塞模式的“缺陷”。但是這種模式在少量的TCP連接通信的情況下，雙方都可以快速的傳輸數據，這個時候的性能是最高的。

阻塞VS非阻塞

• 阻塞

  • 發送端 —> 線程輪詢發送緩衝區是否可寫
  • 接收端 —> 線程輪詢接收緩衝區是否可讀

• 非阻塞

  • 發送端 —> selector(多路複用器)產生可寫事件通知線程發送緩衝區可寫
  • 接收端 —> selector(多路複用器)產生可讀事件通知線程接收緩衝區可讀

同步VS異步

• 同步

  • 發送端 —> 線程寫數據到發送緩衝區的同時不可以做其它事情(寫數據的過程佔用線程時間)
  • 接收端 —> 線程從接收緩衝區讀數據的同時不可以做其它事情(讀數據的過程佔用線程時間)

• 異步(epoll模型)

  • 發送端 —> 線程向發送緩衝區發起寫事件後立即返回，寫數據的過程交給操作系統處理，OS寫完後會通知線程(寫數據的過程不佔用線程時間)
  • 接收端 —> 線程向接收緩衝區發起讀事件後立即返回，讀數據的過程交給操作系統處理，OS讀完後會通知線程(讀數據的過程不佔用線程時間)

java通訊

Multicast(組播)

• 單播: 每次只有兩個實體相互通信，發送端和接收端都是唯一確定的。從0.0.0.0到223.255.255.255屬於單播地址(普通的TCP通信都屬於單播)

• 廣播: UDP屬於廣播

• 組播
  
  

序列化

• serialVersionUID的作用

  • 如果沒有爲指定的class配置serialVersionUID，java編譯器會自動給這個class進行一個摘要算法，只要這個文件有任何改動，得到的UID就會截然不同
  • 因此，如果我們自己指定了serialVersionUID，就可以在序列化後，去添加一個字段，或者方法，而不會影響到後期的還原

• transient關鍵字表示指定屬性不參與序列化

• 要想父類對象也參與序列化操作，那麼必須要讓父類也實現Serializable接口

• 通過序列化操作實現深度克隆

• 主流的序列化技術有哪些?
  JSON/Hessian(2) /xml/protobuf/kryo/MsgPack/FST/thrift/protostuff/Avro

https原理

1. 瀏覽器發起往服務器的443端口發起請求，請求攜帶了瀏覽器支持的加密算法和哈希算法。
2. 服務器收到請求，選擇瀏覽器支持的加密算法和哈希算法。
3. 服務器將數字證書返回給瀏覽器，這裏的數字證書可以是向某個可靠機構申請的，也可以是自制的。
4. 瀏覽器進入數字證書認證環節，這一部分是瀏覽器內置的TLS完成的：
   (1) 首先瀏覽器會從內置的證書列表中索引，找到服務器下發證書對應的機構，如果沒有找到，此時就會提示用戶該證書是不是由權威機構頒發，是不可信任的。如果查到了對應的機構，則取出該機構頒發的公鑰。
   (2) 用機構的證書公鑰解密得到證書的內容和證書籤名，內容包括網站的網址、網站的公鑰、證書的有效期等。瀏覽器會先驗證證書籤名的合法性（驗證過程類似上面Bob和Susan的通信）。簽名通過後，瀏覽器驗證證書記錄的網址是否和當前網址是一致的，不一致會提示用戶。如果網址一致會檢查證書有效期，證書過期了也會提示用戶。這些都通過認證時，瀏覽器就可以安全使用證書中的網站公鑰了。
   (3) 瀏覽器生成一個隨機數R，並使用網站公鑰對R進行加密。
5. 瀏覽器將加密的R傳送給服務器。
6. 服務器用自己的私鑰解密得到R。
7. 服務器以R爲密鑰使用了對稱加密算法加密網頁內容並傳輸給瀏覽器。
8. 瀏覽器以R爲密鑰使用之前約定好的解密算法獲取網頁內容。

RPC

Remote procedure call protocal