正向代理：客戶端將流量重定向到burpsuite等軟件或連接到VPN再訪問服務器而不是直接訪問服務器的場景。流量流動方向是真正機器--代理服務器。正向代理又稱代理、普通代理。

反向代理：服務器端使用反向代理服務器統一接收客戶端訪問，然后再按即定規則將數據包重定向到真正的服務器的場景。流量流動方向是代理服務器--真正機器，與正向代理正好相反所以稱反向代理（其實我覺得這此名詞應是先有代理再有反向代理再有正向代理）。

相互關系：除了名詞相反外，由于代理是客戶端行為反向代理是服務端行為所以可以隨意使用，在技術上兩不相干。

假設客戶端代理訪問了有反向代理的服務器：

C--客戶端；PC--客戶端代理服務器；PS--服務端代理服務器；S--服務器

這個例子要再次聲明這樣的原則：對于網絡中的一跳，其從上一跳接收的數據包中的目的地址一定是它，其發往下一跳的數據包中的源地址一定是它；這不會因為包括其本身用途在內的任何原因而改變。

所以以PS為例，其收到的數據包目的地址一定是PS然后再由其重新封裝數據包將目的地址改為S，而不可能PS收到的數據包的目的地址直接是S；即便它只是純粹向S轉發數據包的代理服務器。

PS要和外網交流又要和內網交流，所以其需要一張外網網卡和一張內網網卡。

負載均衡：以一設備統一接收客戶端請求再按即定規則從多臺相同服務器從選出一臺將數據包重定向到這臺服務器上的場景。

負載均衡可以理解為反向代理的子集，其在反向代理中加入了“多臺相同服務器”的限定；當然你要說“不同服務器”（如一臺JSP服務器和一臺PHP服務器使用NGINX做反向代理）的反理也可以叫負載均衡那我也覺沒什么問題。

軟負載和硬負載：

軟負載：就是通過軟件來實現負載均衡功能；Nginx和httpd等http服務器都能實現軟負載功能。

硬負載：又叫硬件負載，就是把實現負載均衡功能的軟件搬到一臺專門的計算機上；比如F5等設備。

軟負載與硬負載的區別和軟件防火墻與硬件防火墻的區別是一樣的。

負載均衡與會話同步：

在負載均衡中可以將來自同一個IP的訪問通過IP_HASH等方式全定向到一臺機器上。這樣一來所有會話（session）就全在一臺機器上，就不必使用會話同步了。

但IP_HASH的問題是如果某臺服務器故障而請求一樣被發送過去，那么這些訪問請求被發送到故障機的IP將無法得到服務，我的服務器分明還有多臺正常而我的用戶卻只因一臺故障即不能訪問，這并不能最大化多臺服務器的效益。

會話中保存著用戶的登錄狀態，而如果請求是按即定算法被分配到不確定的服務器上那么就得保證會話同步，以確保在S1上登錄過的用戶其請求被重定向到S2時其狀態也是登錄的（而不是又讓用戶再次登錄這樣的網站沒人愿意用）。

會話同步實現的思路是無論哪臺服務器的session都存放到一臺服務器上，請求無論被分配到S1還是S2都是到那臺服務器上取session。

而在session服務器的存儲又有兩種方案，一是使用oracle等傳統數據庫存儲，二是使 用memcache等內存數據庫存儲；后者方案是更加推薦的。

session比cookie更安全嗎？

所謂的cookie不安全主要是指用戶名/密碼/登錄狀態等會話信息全部存在了cookie中，一是cookie被盜那么信息泄漏得多，二是如果以登錄狀態值標識用戶登錄狀態從而決定是否有操作權限那么完全可能是偽造cookie實現越權。

session一般是生成一個sessionID存放到cookie中，如果cookie被盜那么攻擊者一樣是可以使用該sessionID登錄的，只是說沒泄漏用戶名等信息偽造sessionID也不能偽造其登錄狀態（這兩點安全性就提高好多了）。

禁用cookie后session就不能用了嗎？

session的根本原理是以一個sessionID標識用戶，客戶端無論從哪把sessionID傳到服務器都是可以的不一定要通過cookie，這是嚴謹但不負責任的回答。

在一般的session實現中我們生成sessionID并將其put到cookie中，由于是cookie是自動提交的所以，我們在設計客戶端請求時完全不用考慮sessionID的上傳。

如果我們不將sessionID放到cookie，那么再沒第二個和cookie這樣自動下傳又自動上傳的字段，這意味著如果不通過cookie那么在服務端下傳后在客戶端請求時需要手動將sessionID附到某個字段中。

輕則要附到URL中作為參數，重則要js將sessionID附到http頭的其他字段中或post的body中；一兩個頁面還沒什么，要是全站使用和考濾網站擴展性，這工作量并不是可以輕描淡寫。

所心結論是禁用cookie后session還是有方法可以實現的，但這比較麻煩。