正向代理：客戶(hù)端將流量重定向到burpsuite等軟件或連接到VPN再訪(fǎng)問(wèn)服務(wù)器而不是直接訪(fǎng)問(wèn)服務(wù)器的場(chǎng)景。流量流動(dòng)方向是真正機(jī)器--代理服務(wù)器。正向代理又稱(chēng)代理、普通代理。

反向代理：服務(wù)器端使用反向代理服務(wù)器統(tǒng)一接收客戶(hù)端訪(fǎng)問(wèn)，然后再按即定規(guī)則將數(shù)據(jù)包重定向到真正的服務(wù)器的場(chǎng)景。流量流動(dòng)方向是代理服務(wù)器--真正機(jī)器，與正向代理正好相反所以稱(chēng)反向代理（其實(shí)我覺(jué)得這此名詞應(yīng)是先有代理再有反向代理再有正向代理）。

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

假設(shè)客戶(hù)端代理訪(fǎng)問(wèn)了有反向代理的服務(wù)器：

C--客戶(hù)端；PC--客戶(hù)端代理服務(wù)器；PS--服務(wù)端代理服務(wù)器；S--服務(wù)器

這個(gè)例子要再次聲明這樣的原則：對(duì)于網(wǎng)絡(luò)中的一跳，其從上一跳接收的數(shù)據(jù)包中的目的地址一定是它，其發(fā)往下一跳的數(shù)據(jù)包中的源地址一定是它；這不會(huì)因?yàn)榘ㄆ浔旧碛猛驹趦?nèi)的任何原因而改變。

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

PS要和外網(wǎng)交流又要和內(nèi)網(wǎng)交流，所以其需要一張外網(wǎng)網(wǎng)卡和一張內(nèi)網(wǎng)網(wǎng)卡。

負(fù)載均衡：以一設(shè)備統(tǒng)一接收客戶(hù)端請(qǐng)求再按即定規(guī)則從多臺(tái)相同服務(wù)器從選出一臺(tái)將數(shù)據(jù)包重定向到這臺(tái)服務(wù)器上的場(chǎng)景。

負(fù)載均衡可以理解為反向代理的子集，其在反向代理中加入了“多臺(tái)相同服務(wù)器”的限定；當(dāng)然你要說(shuō)“不同服務(wù)器”（如一臺(tái)JSP服務(wù)器和一臺(tái)PHP服務(wù)器使用NGINX做反向代理）的反理也可以叫負(fù)載均衡那我也覺(jué)沒(méi)什么問(wèn)題。

軟負(fù)載和硬負(fù)載：

軟負(fù)載：就是通過(guò)軟件來(lái)實(shí)現(xiàn)負(fù)載均衡功能；Nginx和httpd等http服務(wù)器都能實(shí)現(xiàn)軟負(fù)載功能。

硬負(fù)載：又叫硬件負(fù)載，就是把實(shí)現(xiàn)負(fù)載均衡功能的軟件搬到一臺(tái)專(zhuān)門(mén)的計(jì)算機(jī)上；比如F5等設(shè)備。

軟負(fù)載與硬負(fù)載的區(qū)別和軟件防火墻與硬件防火墻的區(qū)別是一樣的。

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

在負(fù)載均衡中可以將來(lái)自同一個(gè)IP的訪(fǎng)問(wèn)通過(guò)IP_HASH等方式全定向到一臺(tái)機(jī)器上。這樣一來(lái)所有會(huì)話(huà)（session）就全在一臺(tái)機(jī)器上，就不必使用會(huì)話(huà)同步了。

但I(xiàn)P_HASH的問(wèn)題是如果某臺(tái)服務(wù)器故障而請(qǐng)求一樣被發(fā)送過(guò)去，那么這些訪(fǎng)問(wèn)請(qǐng)求被發(fā)送到故障機(jī)的IP將無(wú)法得到服務(wù)，我的服務(wù)器分明還有多臺(tái)正常而我的用戶(hù)卻只因一臺(tái)故障即不能訪(fǎng)問(wèn)，這并不能最大化多臺(tái)服務(wù)器的效益。

會(huì)話(huà)中保存著用戶(hù)的登錄狀態(tài)，而如果請(qǐng)求是按即定算法被分配到不確定的服務(wù)器上那么就得保證會(huì)話(huà)同步，以確保在S1上登錄過(guò)的用戶(hù)其請(qǐng)求被重定向到S2時(shí)其狀態(tài)也是登錄的（而不是又讓用戶(hù)再次登錄這樣的網(wǎng)站沒(méi)人愿意用）。

會(huì)話(huà)同步實(shí)現(xiàn)的思路是無(wú)論哪臺(tái)服務(wù)器的session都存放到一臺(tái)服務(wù)器上，請(qǐng)求無(wú)論被分配到S1還是S2都是到那臺(tái)服務(wù)器上取session。

而在session服務(wù)器的存儲(chǔ)又有兩種方案，一是使用oracle等傳統(tǒng)數(shù)據(jù)庫(kù)存儲(chǔ)，二是使 用memcache等內(nèi)存數(shù)據(jù)庫(kù)存儲(chǔ)；后者方案是更加推薦的。

session比cookie更安全嗎？

所謂的cookie不安全主要是指用戶(hù)名/密碼/登錄狀態(tài)等會(huì)話(huà)信息全部存在了cookie中，一是cookie被盜那么信息泄漏得多，二是如果以登錄狀態(tài)值標(biāo)識(shí)用戶(hù)登錄狀態(tài)從而決定是否有操作權(quán)限那么完全可能是偽造cookie實(shí)現(xiàn)越權(quán)。

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

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

session的根本原理是以一個(gè)sessionID標(biāo)識(shí)用戶(hù)，客戶(hù)端無(wú)論從哪把sessionID傳到服務(wù)器都是可以的不一定要通過(guò)cookie，這是嚴(yán)謹(jǐn)?shù)回?fù)責(zé)任的回答。

在一般的session實(shí)現(xiàn)中我們生成sessionID并將其put到cookie中，由于是cookie是自動(dòng)提交的所以，我們?cè)谠O(shè)計(jì)客戶(hù)端請(qǐng)求時(shí)完全不用考慮sessionID的上傳。

如果我們不將sessionID放到cookie，那么再?zèng)]第二個(gè)和cookie這樣自動(dòng)下傳又自動(dòng)上傳的字段，這意味著如果不通過(guò)cookie那么在服務(wù)端下傳后在客戶(hù)端請(qǐng)求時(shí)需要手動(dòng)將sessionID附到某個(gè)字段中。

輕則要附到URL中作為參數(shù)，重則要js將sessionID附到http頭的其他字段中或post的body中；一兩個(gè)頁(yè)面還沒(méi)什么，要是全站使用和考濾網(wǎng)站擴(kuò)展性，這工作量并不是可以輕描淡寫(xiě)。

所心結(jié)論是禁用cookie后session還是有方法可以實(shí)現(xiàn)的，但這比較麻煩。