負載均衡第二篇-負載均衡基礎知識普及
在上一篇中，我們一直在講述與負載均衡周邊的一些的知識，朋友們也不要着急，心急吃不了熱豆腐。每天一點！
系列文章索引：
負載均衡詳解第三篇：服務器負載均衡的基本概念-使用負載均衡器的服務器群
負載均衡詳解第四篇：服務器負載均衡的基本概念-負載均衡時數據包流程
負載均衡詳解第六篇：服務器負載均衡的基本概念-網絡地址轉換(NAT)
負載均衡詳解第七篇：服務器負載均衡的基本概念-服務器直接返回
一般而言，負載均衡在服務器和網絡之前起到一個中間橋梁的作用，如下圖所示：
正如之前所說的，負載均衡大體包含以下幾類：
服務器負載均衡
全球服務器負載均衡
防火牆負載均衡
其中，服務器負載均衡主要是講負載請求分散到后端的每個服務器上，克服一台服務器引發的問題，從而達到可伸縮性和容錯性。
全球服務器負載均衡主要是將全球不同地區的用戶的請求轉發到各對應地區的服務器處理中心，從而為用戶提供更快的響應，同時，也可以起到很好的容錯性：一個地區的服務器全部掛了也沒用問題，因為其他的地區還有服務器，並且還可以從總的數據中心將數據恢復。
防火牆出現的目的主要是安全，同時為了避免防火牆成為站點的性能瓶頸，采用多個防火牆來達到負載均衡，基本如下（詳細的我們后面談）：
下面，我們來看看一些負載均衡產品。
負載均衡的產品，基本可以分為三大類：軟件，硬件，交換器！
軟件負載均衡：這個產品通過直接一些算法來協調請求。例如采用服務器權重算法，服務器親緣行算法，服務器資源使用狀態等等。
硬件負載均衡：很多時候，就是幾大廠商生產的一些設備，包括硬件和特定的軟件，這個設備對於我們來說，就是一個黑盒，我們只要按照說明使用就行了。
到這里，也談了不少，但是一直沒有談到朋友們真正關心的東西！下面，我們就逐步進入吧。
首先，非常非常有必要普及一些知識：網絡地址轉換，TCP請求流程，服務器請求處理流程。
網絡地址轉換
在這里，會簡要的介紹OSI模型中的第2層和第3層的一些數據轉發功能是如何在負載均衡中發揮作用的。
首先，我們知道一個MAC地址為硬件在整個網絡中提供了唯一的標識。同時，一個IP地址也唯一的標識了一個主機。
在交換器中，如果一個端口負責接收數據報，那么這個端口就稱之為“入口”，同理，如果一個端口負責發送數據報，那么這個端口就是“出口” 。當交換器把數據報接到了之后，就由它來決定將數據報發往那個出口，這個時候，在發送之前，交換器還會修改這個數據報中的一些信息。
好，基礎的鋪墊做完了，一些概念也講了。下面我們將之串起來：
當第2層交換器收到一個數據包，交換器基於第2層的數據包頭信息（如MAC地址）決定下一個目的地，並轉發數據包給第3層。同理，第3層交換器查看數據報的頭信息（如，IP地址），通過改變數據報中的目的地的MAC地址，從而決定將數據報發送到下一個地方。第3層的交換器也被稱之為“路由器”，第3層交換器所做的工作就稱之為“路由”。
負載均衡處在第4層，或者第5層，第6層，第7層，通過查看發給這些層的數據報的信息來決定請求的轉發。
TCP請求流程
為了后續文章可以更好的看懂，這里我們來講講TCP的請求與處理的流程，看到下面的圖：
相信大家對這個圖不怎么陌生了。眾所周知，每個TCP的鏈接都要涉及3次握手。我們就來稍微具體的看看。
首先，如何客戶端想要和服務端進行數據交換，客戶端會先發送一個SYN的數據報給服務端。在這個SYN數據報中比較重要的信息就是：請求源的IP地址（請求源就是指的發出請求的一方，這個時候，是我們客戶端發送請求的），請求源的端口號，目標IP地址（指的就是被請求一方的IP地址，這個時候就是服務器），還有目標的端口號。
可以用下面的一個圖中給出清晰的解釋：
同時，在SYN數據報中還含有一個表示順序的數字，每次有新的數據報從客戶端發送到服務端的時候的，這個數字就會遞增。
當服務端接受到了SYN數據報之后，它就發送一個SYN ACK的應答給客戶端，這個SYN ACK應答包含了服務端的一個表示順序的數字。
客戶端接收到了應答之后，就會回發一個ACK應答給服務端，這個時候，一個連接就建立起來了。之后客戶端和服務器之間就通過這個連接通道開始數據的交換。
每一個建立起來的TCP連接可以用四個值來唯一的標識：源IP地址，源端口號，目標IP地址，目標端口號。而且，當連接建立好了之后，每一個在TCP連接傳遞的數據報都包含這四個信息。另外需要特別注意的就是：“源”與“目標”的角色在客戶端與服務端之間不斷的轉變。即，如果數據報是從客戶端發送到服務端的，那么客戶端就是“源”，服務端就是“目標”；反之，如果數據報從服務端發送給客戶端，那么服務端就是“源”，客戶端就是“目標”。一切都是以數據報的流出流入為參考。總結一句話就是：“源”就是數據流出的端，“目標”，就是數據報要被發往的端。理解這一點是理解負載均衡的關鍵之一。
當客戶端和服務端數據交換完成之后，客戶端就發送一個FIN數據報，之后服務端返回一個FIN ACK的應答，這個時候，TCP連接就被銷毀了。
服務器請求處理流程
我們這里主要是請求一個網頁的具體的流程來分析一下。
注：到現在為止可以看出：技術做的越深，需要掌握的東西越多。做一個應用，不再是拖拖控件，搞大量的增刪改查就OK了的。需要考慮和深度掌握的東西太多了。
假設用戶打開瀏覽器，輸入了：www.agilesharp.com在地址欄中，當用戶點擊Enter之后，我們就看到了站點的頁面就顯示在我們的眼前。其實在這過程中，背后做了很多的操作。我們就來看看。
首先，當用戶點擊Enter之后，瀏覽器首先就將www.agilesharp.com這個域名解析為IP地址。在解析的過程中，瀏覽器首先會去檢查本地的DNS服務器。本地的DNS服務器就會使用相關的協議和方法去獲取這個域名的IP地址，然后返回給瀏覽器。如果在本地的DNS服務器中沒有找到這個域名的IP地址，那么，這個時候，就要去遠程的DNS服務器上去查找（在性能調優的時候，這也是一個考慮點）。一旦找到了IP地址之后，這個時候，瀏覽器就會采用我們之前講說的三次握手，建立一個TCP連接。
連接建立好了之后，瀏覽器就會發送Http請求給服務端去請求www.agilesharp.com的頁面。
發送到服務端的請求如下：
服務端接受請求之后，就開始處理請求，然后將響應發送回來，如下：
注意，這個響應分為兩個部分：一個頭信息，一個是頁面的內容。它們之間使用一個換行來隔開的。
服務端把響應發送回來之后，瀏覽器就接受響應。這個時候，瀏覽器加載頁面的Html結構，之后，就按照從上到下的順序開始解析並且呈現頁面，如果需要去請求資源，例如js，css，圖片等，瀏覽器會先從緩存中查找，如果沒有，就再次根據資源的地址，進行域名解析，發送請求，獲取數據，一直到整個頁面全部解析完畢！這其中的詳細步驟，我這里就不羅嗦了，因為重心不在這里！