一、DNS系統架構與解析原理

DNS( Domain Name System)是“域名系統”的英文縮寫，是一種組織成域層次結構的計算機和網路服務命名系統，它用於
TCP/IP網路，它所提供的服務是用來將主機名和域名轉換為IP地址的工作。
DNS 的過程？

關於DNS的獲取流程：
   DNS是應用層協議，事實上他是為其他應用層協議工作的，包括不限於HTTP和SMTP以及FTP，用於將使用者提供的主機名解析為ip
地址。
   具體過程如下：
①使用者主機上執行著DNS的客戶端，就是我們的PC機或者手機客戶端執行著DNS客戶端了

②瀏覽器將接收到的url中抽取出域名欄位，就是訪問的主機名，比如http://www.baidu.com/, 並將這個主機名傳送給DNS應用
 的客戶端

③DNS客戶機端向DNS伺服器端傳送一份查詢報文，報文中包含著要訪問的主機名欄位（中間包括一些列快取查詢以及分散式DNS叢集
 的工作）

④該DNS客戶機最終會收到一份回答報文，其中包含有該主機名對應的IP地址

⑤一旦該瀏覽器收到來自DNS的IP地址，就可以向該IP地址定位的HTTP伺服器發起TCP連線
 

二、http協議通訊原理

（1） 建立TCP連線
（2） Web瀏覽器向Web伺服器傳送請求命令
（3） Web瀏覽器傳送請求頭資訊
（4） Web伺服器應答
（5） Web伺服器傳送應答頭資訊
（6） Web伺服器向瀏覽器傳送資料
（7） Web伺服器關閉TCP連線

三、TCP/IP三次握手與四次揮手

三次握手：

第一次握手：客戶端要和服務端進行通訊，首先要告知服務端一聲，遂發出一個SYN=1的連線請求訊號,”服務端哥哥，我想給你說說
話”。
第二次握手：當服務端接收到客戶端的連線請求，此時要給客戶端一個確認資訊，”我知道了（ACK）,我這邊已經準備好了，你現在能
連嗎（SYN）”。
第三次握手：當客戶端收到了服務端的確認連線資訊後，要禮貌的告知一下服務端，“好的，咱們開始聯通吧（ACK）”。
到此整個建立連線的過程已經結束，接下來就是雙方你一句我一句甚至同時交流傳遞資訊的過程了。
 

四次揮手：

第一次揮手：雙方交流的差不多了，此時客戶端也已經結尾了，接下來要斷開通訊連線，所以告訴服務端“我說完了（FIN）”，此時
自身形成等待結束連線的狀態。
    
第二次揮手：服務端知道客戶端已經沒話說了，服務端此時還有兩句心裡話要給客戶端說，“我知道你說完了（ACK），我再給你說兩
句，&*……%￥”。
    
第三次揮手：此時客戶端洗耳恭聽繼續處於等待結束的狀態，伺服器端也說完了，自身此時處於等待關閉連線的狀態，並對告訴客戶
端，“我說完了，咱們斷了吧（FIN）”。
    
第四次揮手：客戶端收知道服務端也說完了，也要告訴服務端一聲（ACK），因為連線和斷開要雙方都按下關閉操作才能斷開，客戶
端同時又為自己定義一個定時器，因為不知道剛才說的這句話能不能準確到達服務端
    
 到此為止雙方整個通訊過程就此終結。這裡要宣告一下：斷開連結不一定就是客戶端，誰都可以先發起斷開指令，另外客戶端和服務
端是沒有固定標準的，誰先發起請求誰就是客戶端。
 

四、MySQL主從同步原理

mysql主從簡介：
 			- 一主一從
			 - 主主複製
 			- 一主多從---擴充套件系統讀取的效能，因為讀是在從庫讀取的
 			- 多主一從--5.7開始支援
 			- 聯級複製

用途及條件:

 mysql主從複製用途
實時災備，用於故障切換
讀寫分離，提供查詢服務
備份，避免影響業務
 
 主從部署必要條件：
主庫開啟binlog日誌（設定log-bin引數）
主從server-id不同
從庫伺服器能連通主庫

主從原理
mysql主從複製原理

從庫生成兩個執行緒，一個I/O執行緒，一個SQL執行緒

i/o執行緒去請求主庫 的binlog，並將得到的binlog日誌寫到relay log（中繼日誌） ；檔案中主庫會生成一個log dump執行緒，
用來給從庫 i/o執行緒傳binlog；SQL 執行緒會讀取relay log檔案中的日誌，並解析成具體操作，來實現主從的操作一致，而最終
資料一致；

五、Nginx配合PHP工作的FastCGI工作原理

（1） 什麼是 FastCGI？

   FastCGI的方式是，web伺服器收到一個請求時，他不會重新fork一個程序（因為這個程序在web伺服器啟動時就開啟了，而且不
會退出），web伺服器直接把內容傳遞給這個程序（程序間通訊，但fastcgi使用了別的方式，tcp方式通訊），這個程序收到請求後
進行處理，把結果返回給web伺服器，最後自己接著等待下一個請求的到來，而不是退出.

（2）Nginx+FastCGI執行原理

（1） Nginx不支援對外部程式的直接呼叫或者解析，所有的外部程式（包括PHP）必須通過FastCGI介面來呼叫。
（2）FastCGI介面在Linux下是socket（這個socket可以是檔案socket，也可以是ip socket）。
（3）為了呼叫CGI程式，還需要一個FastCGI的wrapper（wrapper可以理解為用於啟動另一個程式的程式），這個wrapper繫結
在某個固定socket上，如埠或者檔案socket。當Nginx將CGI請求傳送給這個socket的時候，通過FastCGI介面，wrapper接
收到請求，然後派生出一個新的執行緒，這個執行緒呼叫直譯器或者外部程式處理指令碼並讀取返回資料；接著，wrapper再將返回的資料通
過FastCGI介面，沿著固定的socket傳遞給Nginx；最後，Nginx將返回的資料傳送給客戶端。這就是Nginx+FastCGI的整個運作
過程.

五、LVS四種工作模式原理

LVS 簡介

LVS 是 Linux  Virtual Server ，Linux 虛擬伺服器；是一個虛擬的伺服器叢集【多臺機器 LB IP】。LVS 叢集分為三層
結構:

負載排程器(load balancer)：它是整個LVS 叢集對外的前端機器，負責將client請求傳送到一組伺服器[多臺LB IP]上執行，
而client端認為是返回來一個同一個IP【通常把這個IP 稱為虛擬IP/VIP】
伺服器池(server pool)：一組真正執行client 請求的伺服器，一般是我們的web伺服器；除了web，還有FTP，MAIL，DNS
共享儲存(shared stored)：它為 server pool 提供了一個共享的儲存區，很容易讓伺服器池擁有相同的內容，提供相同的服務

（1）直接路由模式（LVS-DR）

client 傳送一個pv請求給VIP；
    VIP 收到這請求後會跟LVS設定的LB演算法選擇一個LB 比較合理的realserver，然後把此請求的package 的MAC地址修改為
 realserver的MAC地址；

注意：
    （1）LVS 的VIP 和 realserver 必須在同一個網段，不然廣播後所有的包都會丟掉： 提前確認LVS/硬體LB 是什麼模式，
是否需要在同一個網段
    （2）所有的realserver 都必須繫結VIP的IP地址，否則realserver 收到package後發現dst 不是自己的IP，所有包都
會丟掉。

（2）NAT模式（LVS-NAT）

-首先client 傳送請求[package] 給VIP
-VIP 收到package後，會根據LVS設定的LB演算法選擇一個合適的realserver，然後把package 的DST IP 修改為realserver
-realserver 收到這個package後判斷dst ip 是自己，就處理這個package ，處理完後把這個包傳送給LVS VIP
-LVS 收到這個package 後把sorce ip改成VIP的IP，dst ip改成 client ip然後傳送給client

（3）Full NAT模式（LVS-FullNAT）

FULL NAT  在client請求VIP 時，不僅替換了package 的dst ip，還替換了package的 src ip；
但VIP 返回給client時也替換了src ip；還是通過上面NAT 模式的工作原因的圖進行分析 FULL NAT 的工作原理
  	   1、首先client 傳送請求[package] 給VIP
	   2、VIP 收到package後，會根據LVS設定的LB演算法選擇一個合適的realserver，然後把package 的DST IP 修改
    為realserver；把sorce ip 改成 lvs 叢集的LB IP
  	   3、realserver 收到這個package後判斷dst ip 是自己，就處理這個package ，處理完後把這個包傳送給LVS VIP
	   4、LVS 收到這個package 後把sorce ip改成VIP的IP，dst ip改成 client ip然後傳送給client
  
  注意事項：
（1）FULL NAT 模式也不需要 LBIP 和realserver ip 在同一個網段；
（2）full nat 跟nat 相比的優點是：保證RS回包一定能夠回到LVS；因為源地址就是LVS--> 不確定
（3）full nat  因為要更新sorce ip 所以效能正常比nat 模式下降 10%

（4）IP隧道模式（LVS-Tunnel）

基本原理

  1、首先client 傳送請求[package] 給VIP
  2、VIP 收到package後，會根據LVS設定的LB演算法選擇一個合適的realserver；並把client傳送的package 包裝到一個新
的IP包裡面；新的IP包的dst是realserver的IP
  3、realserver 收到這個package後判斷dst ip 是自己，然後解析出來的package的dst是VIP；會檢測我們的網絡卡上是否
幫了VIP的ip地址；如果幫了就會處理這個包，如果沒有直接丟掉。 我們一般在realserver上面 lo:0 綁定了VIP的ip地址，
就可以處理

IP TUNNEL 模式的注意：
    （1）TUNNEL 模式必須在所有的realserver 機器上面繫結VIP的IP地址
    （2）TUNNEL 模式的vip ------>realserver 的包通訊通過TUNNEL 模式，不管是內網和外網都能通訊，所以不需要lvs vip
  跟realserver 在同一個網段內
    （3）TUNNEL 模式 realserver會把packet 直接發給client 不會給lvs了
    （4）TUNNEL 模式走的隧道模式，所以運維起來比較難，所以一般不用

四種模式效能比較：

因為DR模式   TP TUNELL 模式都是在package in 時經過LVS ；
在package out是直接返回給client；所以二者的效能比NAT 模式高；
但IP TUNNEL 因為是TUNNEL 模式比較複雜，其效能不如DR模式；
FULL NAT 模式因為不僅要更換 DST IP 還更換 SOURCE IP  所以效能比NAT 下降10%
4種模式的效能如下：DR  --> IP TUNNEL  --->NAT ----->FULL NAT

七、memcached工作原理（記憶體管理機制）

memcached簡介：

memcached是一種快取技術，儲存在記憶體中(高效能分散式記憶體快取伺服器)。
  目的：提速。（傳統的都是把資料儲存在關係型資料庫管理系統即RDBMS，客戶端請求時會從RDBMS中讀取資料並在瀏覽器中顯示，
這樣當訪問量過大時或集中時，導致RSBMS負擔過重，資料庫響應惡化，瀏覽器中顯示延遲等嚴重問題，
使用memcached減少資料庫查詢和訪問次數以提高訪問速度，提高擴充套件性）
    
memcache工作原理：
 （1）memcache 的工作就是在專門的機器的記憶體裡維護一張巨大的 hash 表，來儲存經常被讀寫的一些陣列與檔案，從而極大的提
高網站的執行效率。
 （2）採用的是C/S模式，在 server 端啟動服務程序，在啟動時可以指定監聽的 ip，自己的埠號，所使用的記憶體大小等幾個
關鍵引數。
 （3）採用了單程序，單執行緒，非同步I/O，基於事件 (event_based) 的服務方式.使用 libevent 作為事件通知實現。每個Ser
ver 只是對自己的資料進行管理。Client 端通過指定 Server 端的ip 地址(通過域名應該也可以)。以key->value形式，key
的值通過 hash 進行轉換，然後確定對那臺sever儲存/獲取資料。

memcache作用：

  高效能分散式快取伺服器（快取資料庫查詢結果，減少資料庫訪問次數）

memcached適合做的東西：

1、訪問頻繁的字典資料
2、大量的hot資料（熱門資料快取）
3、頁面快取（web站常用）
4、搜尋的查詢條件和結果（熱門搜尋的內容快取起來）
5、臨時處理資料（不需要入庫，排重）

八、 keepalived高可用服務工作原理

  （1） Keepalived軟體起初是專為LVS負載均衡軟體設計的，用來管理並監控LVS集群系統中各個服務節點的狀態，後來又加入了
可以實現高可用的VRRP功能。因此，Keepalived除了能夠管理LVS軟體外，還可以作為其他服務（Nginx、Haproxy、MySQL等）
的高可用解決方案軟體。
  （2）Keepalived軟體主要是通過VRRP協議實現高可用功能的。
VRRP是Virtual Router RedundancyProtocol(虛擬路由器冗餘協議）的縮寫，VRRP出現的目的就是為了解決靜態路由單點故
障問題的，它能夠保證當個別節點宕機時，整個網路可以不間斷地執行。所以，Keepalived 一方面具有配置管理LVS的功能，同時
還具有對LVS下面節點進行健康檢查的功能，另一方面也可實現系統網路服務的高可用功能。

瞭解VRRP：

Keepalived高可用對之間是通過VRRP通訊的，因此，我們從 VRRP開始瞭解起：

 （1） VRRP,全稱 Virtual Router Redundancy Protocol,中文名為虛擬路由冗餘協議，VRRP的出現是為了解決靜態路由的
單點故障。

 （2） VRRP是通過一種竟選協議機制來將路由任務交給某臺VRRP路由器的。

 （3） VRRP用 IP多播的方式（預設多播地址（224.0_0.18))實現高可用對之間通訊。

 （4） 工作時主節點發包，備節點接包，當備節點接收不到主節點發的資料包的時候，就啟動接管程式接管主節點的開源。
	   備節點可以有多個，通過優先順序競選，但一般 Keepalived系統運維工作中都是一對。

 （5） VRRP使用了加密協議加密資料，但Keepalived官方目前還是推薦用明文的方式配置認證型別和密碼。

Keepalived服務的工作原理：

Keepalived高可用對之間是通過 VRRP進行通訊的， VRRP是通過競選機制來確定主備的，主的優先順序高於備，因此，工作時主會
優先獲得所有的資源，備節點處於等待狀態，當主掛了的時候，備節點就會接管主節點的資源，然後頂替主節點對外提供服務。
	
在Keepalived服務，只有作為主的伺服器會一直髮送 VRRP廣播包,告訴備它還活著，此時備不會槍佔主，當主不可用時，即備監聽
不到主傳送的廣播包時，就會啟動相關服務接管資源，保證業務的連續性.接管速度最快可以小於1秒。

九、CND工作原理

CDN的百度百科的解釋為:

CDN的全稱是Content Delivery Network，即內容分發網路。

  其基本思路是儘可能避開網際網路上有可能影響資料傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。通過在網路各處放
置節點伺服器所構成的在現有的網際網路基礎之上的一層智慧虛擬網路。

  CDN系統能夠實時地根據網路流量和各節點的連線、負載狀況以及到使用者的距離和響應時間等綜合資訊將使用者的請求重新導向離使用者
最近的服務節點上。其目的是使使用者可就近取得所需內容，解決 Internet網路擁擠的狀況，提高使用者訪問網站的響應速度。

通常網路訪問中會有"三公里"路程

第一公里為:源站到ISP接入點
第二公里為:源站ISP接入點到訪問使用者的ISP接入點
第三公里(最後一公里)為:使用者ISP接入點到使用者客戶端

  第一公里的耗時取決於源站自身響應能力和出口頻寬
  第二公里的耗時取決於從源站的接入點到終端使用者的接入點之間的傳輸路徑,主要為網路運營商之間的互連瓶頸問題，不同地區骨幹
網之間的資料交換、傳輸，會導致傳輸途中的路由阻塞和延遲
  第三公里的耗時取決於終端使用者接入Internet的方式,會越來越快,以後不會是瓶頸

而CDN網路層主要用來加速第二公里,怎麼加速呢?原理並不難,下面簡單介紹下:
首先看下訪問網站的一個普通流程

再看下面的CDN層的訪問流程

CDN的好處不止是加速,還可以有效地降低源站負載,降低高額的頻寬成本(不必按峰值頻寬直接向ISP購買頻寬),防止DDOS等攻擊。

轉載地址： https://blog.csdn.net/qq_17054989/article/details/83043007
原創作者：齊澤文的Blog