正向代理：客戶端将流量重定向到burpsuite等頻唱軟件或連接到VPN再訪問服務器而不是直接吃做訪問服務器的場景。流量流動方向是真正機器--代理服務器。正向森城代理又(yòu)稱代理、普通代理。

反向代理：服務器端使用反向代理服務器統一(yī)接收街雜客戶端訪問，然後再按即定規則将數據包重定向到真正的服務器的場日美景。流量流動方向是代理服務器--真正機器，與正向代理正好相反所以稱反向代理（其票訊實我(wǒ)(wǒ)覺得這此名詞應是先有代理再有反向代理再有正舞林向代理）。

相互關系：除了名詞相反外(wài)，由于代理是生玩客戶端行為反向代理是服務端行為所以可以随意使用，在技術上兩不相幹。

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

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

這個例子要再次聲明這樣的原則：對于網絡中(間這zhōng)的一(yī)跳，其從上一(yī)跳接收的數據包中(zhōng)費視的目的地址一(yī)定是它，其發往下(xià)一(yī)跳的數據包中(z刀哥hōng)的源地址一(yī)定是它；這不會因為包括其本身用途在内的任中海何原因而改變。

所以以PS為例，其收到的數據包目的地址一(y樂街ī)定是PS然後再由其重新封裝數據包将目的地址改為S，而不可能P玩藍S收到的數據包的目的地址直接是S；即便它隻是純粹向S轉發歌女數據包的代理服務器。

PS要和外(wài)網交流又(yòu)要和内網交流，所以其需睡門要一(yī)張外(wài)網網卡和一(yī)張内網網卡。制動

負載均衡：以一(yī)設備統一(yī)接收爸中客戶端請求再按即定規則從多台相同服務器從選出一(書可yī)台将數據包重定向到這台服務器上的場景。

負載均衡可以理解為反向代理的子集，其在反向代理中(zhōng)加入了“多謝答台相同服務器”的限定；當然你要說“不同服務器”（如一(yī)得開台JSP服務器和一(yī)台PHP服務器使用NGINX做反向代理）的反理也可會計以叫負載均衡那我(wǒ)(wǒ)也覺沒什麼問題。

軟負載和硬負載：

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

硬負載：又(yòu)叫硬件負載，就是把實現負載均衡功能的制可軟件搬到一(yī)台專門的計算機上；比如F5等設們裡備。

軟負載與硬負載的區别和軟件防火(huǒ)牆與硬件防火(huǒ)牆的區别是一(購紙yī)樣的。

負載均衡與會話(huà)同步：

在負載均衡中(zhōng)可以将來自同一(yī)個IP的訪問通過IP作服_HASH等方式全定向到一(yī)台機器上。這樣一(yī)來所有會話(huà)校哥（session）就全在一(yī)台機器上機地，就不必使用會話(huà)同步了。

但IP_HASH的問題是如果某台服務器故障而請求一(yī)樣被發送過去(美讀qù)，那麼這些訪問請求被發送到故障機的IP将無法得到服務，我(吧對wǒ)(wǒ)的服務器分(fēn)明還有多黑年台正常而我(wǒ)(wǒ)的用戶卻隻因一(yī)台故障即不能訪問，朋劇這并不能最大(dà)化多台服務器的效益。

會話(huà)中(zhōng)保存着用戶的登錄狀态，而如果請求是按即上車定算法被分(fēn)配到不确定的服務器上那麼就得保到愛證會話(huà)同步，以确保在S1上登錄過的用戶其請求被重定向到S2短樹時其狀态也是登錄的（而不是又(yòu)讓用戶再次姐不登錄這樣的網站沒人願意用）。

會話(huà)同步實現的思路是無論哪台服務器的session都存放(f愛窗àng)到一(yī)台服務器上，請求無論被分(fē司懂n)配到S1還是S2都是到那台服務器上取session。

而在session服務器的存儲又(yòu)有個會兩種方案，一(yī)是使用oracle等傳統數據庫存儲，二是使 用吃他memcache等内存數據庫存儲；後者方案化司是更加推薦的。

session比cookie更安全嗎(ma)？

所謂的cookie不安全主要是指用戶名/密讀章碼/登錄狀态等會話(huà)信息全部存在了cookie中(zh問門ōng)，一(yī)是cookie被盜那麼信息機醫洩漏得多，二是如果以登錄狀态值标識用戶登錄男通狀态從而決定是否有操作權限那麼完全可能是僞造c家農ookie實現越權。

session一(yī)般是生(shēng分線)成一(yī)個sessionID存放(fàng)到老又cookie中(zhōng)，如果coo唱機kie被盜那麼攻擊者一(yī)樣是可以使用該ses數了sionID登錄的，隻是說沒洩漏用戶名等信息僞造sessionID也不能僞造制妹其登錄狀态（這兩點安全性就提高好多了）。

禁用cookie後session就不能用了弟計嗎(ma)？

session的根本原理是以一(yī)個sessionI間很D标識用戶，客戶端無論從哪把sessionI雪商D傳到服務器都是可以的不一(yī)定要通過跳去cookie，這是嚴謹但不負責任的回答。

在一(yī)般的session實現中(zhōng)都志我(wǒ)(wǒ)們生(shēng)成sessionID并将其pu民科t到cookie中(zhōng)，由于是cookie是自動提交的所做爸以，我(wǒ)(wǒ)們在設計客戶端請求時完全不用考慮sessionID銀但的上傳。

如果我(wǒ)(wǒ)們不将sessionID來購放(fàng)到cookie，那麼再沒第二慢吧個和cookie這樣自動下(xià)傳又一風(yòu)自動上傳的字段，這意味着如果不通過cookie那麼在服務端下他姐(xià)傳後在客戶端請求時需要手動将ses腦線sionID附到某個字段中(zhōng)。

輕則要附到URL中(zhōng)作為參數，重則要js将session廠姐ID附到http頭的其他字段中(zhōng)或po哥站st的body中(zhōng)；一(yī)兩個頁面還沒什麼，要是全站的上使用和考濾網站擴展性，這工(gōng)作得路量并不是可以輕描淡寫。

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