學習筆記
服務器端的局域網
# 5.1 Web服務器的部署地點 可把服務器部署在公司或者數據中心 由於數據中心與NOC或者IX相連,放在數據中心的服務器可以獲得很高的訪問速度。數據中心有門禁和自助發電設備,還提供監控等附加服務,因此可靠性更高。  # 5.2 防火牆的結構和原理 ## 5.2.1 主流的包過濾方式 防火牆的基本思路:只允許發往特定服務器的特定應用程序的包通過 最為普及的實現方式:包過濾 ## 5.2.2 如何設置包過濾原則 可用網絡包的頭部中的控制信息設置包過濾規則  **注意發送方端口號說明:服務器程序對應端口號一般是固定的,客戶端程序的端口號大多是隨機分配的**  由於出現了一些寄存在服務器中並可以感染其它服務器的軟件,我們需要阻止Web服務器訪問互聯網以防止病毒擴散。 對於互聯網流向Web服務器的包,可以設置防火牆檢查頭部中的IP地址,對IP目標不是Web服務器的包加以限制 ## 5.2.3 通過端口號限定應用程序 如果只靠IP地址,就無法對應用程序進行限制,所以還需要端口號  ## 5.2.4 通過控制位判斷連接方向 如何實現阻止Web服務器訪問互聯網呢? 我們不能阻止全部從Web服務器流向互聯網的包,這會導致TCP協議無法正常工作,但是我們可以限制從Web服務器發出且SYN號為1的包。SYN號為1可視為Web服務器主動發起連接,這種是需要屏蔽的。 但是有一種特殊情況,那就是用UDP進行通信的包,這種包沒有連接操作,因此無法通過控制位判斷連接方向,例如用UDP訪問DNS服務器。 >在這種情況下,只能二者擇其一——要么冒一定的風險允許該應用程序的所有包通過,要么犧牲一定的便利性阻止該應用程序的所有包通過。
如果使用包過濾之外的其它方式的防火牆,有時候是可以判斷UDP應用程序的訪問方向的。
復習,UDP頭部:
5.2.5 從公司內網訪問公開區域的規則
不僅要設置互聯網和公開區域之間的包過濾規則,還需要設置公司內網和互聯網之間的包過濾規則
5.2.6 從外部無法訪問公司內網
由於地址轉換機制,我們不需要再設置規則來阻止從互聯網來訪問公司內網
5.2.7 通過防火牆
感覺就是在說不要把防火牆看作一種特殊機制,不要看得太獨立化。
 其實路由器加上包過濾規則也可以起到防火牆的作用,只不過規則比較復雜時只靠路由器命令難以維護,空間過小難以記錄攔截日志,才出現了專用的硬件和軟件。
5.2.8 防火牆難以抵御的攻擊
如果Web服務器應用程序本身就有漏洞,那完全可以利用漏洞進行攻擊。
 因此需要不斷的檢查和修復漏洞,如果更新版本需要花費一定時間,可以在防火牆之外部署檢查包內容的設備或者軟件(有時會作為防火牆的附件提供)。
5.3 通過將請求平均分配給多台服務器來平衡負載
5.3.1 性能不足時需要負載均衡
- 過多的網絡包會加重服務器的負擔,因此需要多台服務器來分攤負載,此架構稱為分布式架構。
 - 要采用負載均衡,必須把客戶端的請求分配到不同的服務器上
 - 其中一種方法依靠DNS服務器來分配,稱之為輪詢
 
輪詢:
舉例:對於同一個域名,假設分配了3個IP,每次查詢這個域名時,返回的IP會在這三個IP中按順序滾動。
 輪詢的缺點:
- 如果其中一台服務器出現故障,DNS服務器無法得知,因此無法跳過這台服務器。
 - 如果有跨越多個頁面的操作,就需要多次訪問同一台服務器,這時采用輪詢會出現錯誤
 
5.3.2 使用負載均衡器分配訪問
為了避免上述問題,可采用負載均衡器,然后把域名對應的IP換成負載均衡器的IP即可
 
如何分配?
- 定期采集服務器的CPU、內存使用率判斷狀況,以此分配訪問,但采集可能加重服務器的負擔,由於服務器負載波動,采集的數據也可能不准確;
 - 根據服務器的性能指數,按比例分配請求。
 
如何解決跨頁面操作?
可以利用Cookie等控制信息判斷
5.4 使用緩存服務器分擔負載
5.4.1 如何使用緩存服務器
5.3節是使用了功能相同的服務器來分攤負載。還有一種辦法是把整個系統按功能分成不同的服務器,然后按照功能進行負載,緩存服務器就是這個道理。
 有一些數據在一段時間內保持不變,可將其保存在緩存服務器中,這樣就減輕了Web服務器的負擔
5.4.2 緩存服務器通過更新時間管理內容
- 緩存服務器同負載均衡器一樣,要代替Web服務器注冊在DNS服務器中;
 - 對客服端來講,緩存服務器相當於Web服務器;對Web服務器來講,緩存服務器相當於客戶端;
 
緩存服務器如何判斷轉發給哪台服務器?
一種簡單的辦法是通過消息URL,例如:
 
緩存服務器操作?
- 緩存服務器收到客戶端的消息后,先看有沒有緩存,如果沒有,直接向Web服務器請求數據;
 - 如果有緩存,詢問Web服務器數據是否更新,如果沒有,返回緩存,如果有,更新緩存並返回。
流程圖:
詳細的流程還是看書吧
注意一個消息頭:If-Modified-Since 
5.4.3 最原始的代理——正向代理
- 與緩存服務器不同,正向代理是放在客戶端一側的,也可以起到緩存的作用;
 - 正向代理可以查看請求的內容,因此可以根據包的內容限制訪問,如不讓員工訪問一些與工作內容無關的網站等。包過濾只能根據IP和端口號做判斷,因此無法做到這一點;
 - 使用正向代理時,需要在瀏覽器中設置代理服務器的IP。這時瀏覽器就會忽略網址欄,直接將請求發給代理服務器;
 - 沒有代理時,請求中的URL只有域名后面的目錄名或者文件名,有正向代理時會發送完整URL

 
5.4.4 正向代理改良版——反向代理
放在服務器端的代理,緩存服務器就是此類型
5.4.5 透明代理
- 請求消息從瀏覽器直接發送到Web服務器,不會到達透明代理
 - 透明代理是對經過的消息攔截
 - 都要經過接入網,可以在接入網入口放置反向代理實現透明代理
 
5.5 內容分發服務
5.5.1 利用內容分發服務分擔負載
主要看懂這張圖:
 
 注意上圖中各種方式的特點
關於CDSP:
- 要采用上圖中第三種方式,必須在所有運營商的POP都放置緩存服務器才行,但是數量太太,不現實;
 - 可以只在主要運營商的POP放置緩存服務器,但是會導致一些用戶在訪問服務器時繞遠路,但仍然比直接訪問Web服務器要近得多;
 - 作為Web服務器運營者,要和運營商簽約部署緩存服務器太繁瑣了,於是就誕生了一個幫助運營者完成這一工作的類似中介的機構——CDSP;
 - CDSP的緩存服務器可以租給多個網站運營者
CDSP:Content Delivery Service Provider 內容分發服務提供商 
5.5.2 如何找到最近的緩存服務器
緩存服務器這么多,找到最近的服務器是提升網絡效率的好辦法。
 
 書中講了兩種方法實現,一種是利用DNS服務器,另一種是利用重定向服務器,先看第一種方法。
- 收集部署在緩存服務器地點的路由器的路由表信息,保存在DNS服務器上;
 - 跟據信息判斷遠近,返回最近的緩存服務器的IP。

 
要注意:
服務器端DNS服務器估算的距離是客戶端局域網DNS服務器到緩存服務器的距離,如果客戶端DNS服務器不和客戶端在同一位置,可能結果會有偏差。即使如此,依然可以達到相當的精度。
 
5.5.3 通過重定向服務器分配訪問目標
也就是第二種方法。
- 把重定向服務器注冊在DNS服務器上,這樣客戶端就會把HTTP請求發送到重定向服務器上;
 - 重定向服務器估算距離的方式與第一種方法一樣;
 - 重定向服務器會把緩存服務器的地址放在Location字段中返回響應,這樣客戶端就可以去訪問緩存服務器了;
 - 重定向服務器也可以返回一個通過網絡包估算到緩存服務器距離的腳本,由客戶端運行來找到最近緩存服務器。


 
5.5.4 緩存的更新方法會影響性能
如果像上面5.4.2節講述的方法去進行緩存,效率較低。
 可以換種思路:當Web服務器上的數據更新時,就通知緩存服務器進行更新,這樣就不需要每次都去確認緩存是否有變化了。
