正向代理:客戶端將流量重定向到burpsuite等軟件或連接到VPN再訪問服務(wù)器而不是直接訪問服務(wù)器的場景。流量流動方向是真正機(jī)器--代理服務(wù)器。正向代理又稱代理、普通代理。
反向代理:服務(wù)器端使用反向代理服務(wù)器統(tǒng)一接收客戶端訪問,然后再按即定規(guī)則將數(shù)據(jù)包重定向到真正的服務(wù)器的場景。流量流動方向是代理服務(wù)器--真正機(jī)器,與正向代理正好相反所以稱反向代理(其實我覺得這此名詞應(yīng)是先有代理再有反向代理再有正向代理)。
相互關(guān)系:除了名詞相反外,由于代理是客戶端行為反向代理是服務(wù)端行為所以可以隨意使用,在技術(shù)上兩不相干。
假設(shè)客戶端代理訪問了有反向代理的服務(wù)器:
C--客戶端;PC--客戶端代理服務(wù)器;PS--服務(wù)端代理服務(wù)器;S--服務(wù)器
| 發(fā)出數(shù)據(jù)包機(jī)器(方向從左向右) | C | PC | PS |
| 所發(fā)出數(shù)據(jù)包中的源IP和端口 | C | PC | PS |
| 所發(fā)出數(shù)據(jù)包中的目的IP和端口 | PC | PS | S |
| 發(fā)出數(shù)據(jù)包機(jī)器(方向從左向右) | S | PS | PC |
| 發(fā)出數(shù)據(jù)包的源IP和端口 | S | PS | PC |
| 發(fā)出數(shù)據(jù)包的目的IP和端口 | PS | PC | C |
這個例子要再次聲明這樣的原則:對于網(wǎng)絡(luò)中的一跳,其從上一跳接收的數(shù)據(jù)包中的目的地址一定是它,其發(fā)往下一跳的數(shù)據(jù)包中的源地址一定是它;這不會因為包括其本身用途在內(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)一接收客戶端請求再按即定規(guī)則從多臺相同服務(wù)器從選出一臺將數(shù)據(jù)包重定向到這臺服務(wù)器上的場景。
負(fù)載均衡可以理解為反向代理的子集,其在反向代理中加入了“多臺相同服務(wù)器”的限定;當(dāng)然你要說“不同服務(wù)器”(如一臺JSP服務(wù)器和一臺PHP服務(wù)器使用NGINX做反向代理)的反理也可以叫負(fù)載均衡那我也覺沒什么問題。
軟負(fù)載和硬負(fù)載:
軟負(fù)載:就是通過軟件來實現(xiàn)負(fù)載均衡功能;Nginx和httpd等http服務(wù)器都能實現(xiàn)軟負(fù)載功能。
硬負(fù)載:又叫硬件負(fù)載,就是把實現(xiàn)負(fù)載均衡功能的軟件搬到一臺專門的計算機(jī)上;比如F5等設(shè)備。
軟負(fù)載與硬負(fù)載的區(qū)別和軟件防火墻與硬件防火墻的區(qū)別是一樣的。
負(fù)載均衡與會話同步:
在負(fù)載均衡中可以將來自同一個IP的訪問通過IP_HASH等方式全定向到一臺機(jī)器上。這樣一來所有會話(session)就全在一臺機(jī)器上,就不必使用會話同步了。
但I(xiàn)P_HASH的問題是如果某臺服務(wù)器故障而請求一樣被發(fā)送過去,那么這些訪問請求被發(fā)送到故障機(jī)的IP將無法得到服務(wù),我的服務(wù)器分明還有多臺正常而我的用戶卻只因一臺故障即不能訪問,這并不能最大化多臺服務(wù)器的效益。
會話中保存著用戶的登錄狀態(tài),而如果請求是按即定算法被分配到不確定的服務(wù)器上那么就得保證會話同步,以確保在S1上登錄過的用戶其請求被重定向到S2時其狀態(tài)也是登錄的(而不是又讓用戶再次登錄這樣的網(wǎng)站沒人愿意用)。
會話同步實現(xiàn)的思路是無論哪臺服務(wù)器的session都存放到一臺服務(wù)器上,請求無論被分配到S1還是S2都是到那臺服務(wù)器上取session。
而在session服務(wù)器的存儲又有兩種方案,一是使用oracle等傳統(tǒng)數(shù)據(jù)庫存儲,二是使 用memcache等內(nèi)存數(shù)據(jù)庫存儲;后者方案是更加推薦的。
session比cookie更安全嗎?
所謂的cookie不安全主要是指用戶名/密碼/登錄狀態(tài)等會話信息全部存在了cookie中,一是cookie被盜那么信息泄漏得多,二是如果以登錄狀態(tài)值標(biāo)識用戶登錄狀態(tài)從而決定是否有操作權(quán)限那么完全可能是偽造cookie實現(xiàn)越權(quán)。
session一般是生成一個sessionID存放到cookie中,如果cookie被盜那么攻擊者一樣是可以使用該sessionID登錄的,只是說沒泄漏用戶名等信息偽造sessionID也不能偽造其登錄狀態(tài)(這兩點安全性就提高好多了)。
禁用cookie后session就不能用了嗎?
session的根本原理是以一個sessionID標(biāo)識用戶,客戶端無論從哪把sessionID傳到服務(wù)器都是可以的不一定要通過cookie,這是嚴(yán)謹(jǐn)?shù)回?fù)責(zé)任的回答。
在一般的session實現(xiàn)中我們生成sessionID并將其put到cookie中,由于是cookie是自動提交的所以,我們在設(shè)計客戶端請求時完全不用考慮sessionID的上傳。
如果我們不將sessionID放到cookie,那么再沒第二個和cookie這樣自動下傳又自動上傳的字段,這意味著如果不通過cookie那么在服務(wù)端下傳后在客戶端請求時需要手動將sessionID附到某個字段中。
輕則要附到URL中作為參數(shù),重則要js將sessionID附到http頭的其他字段中或post的body中;一兩個頁面還沒什么,要是全站使用和考濾網(wǎng)站擴(kuò)展性,這工作量并不是可以輕描淡寫。
所心結(jié)論是禁用cookie后session還是有方法可以實現(xiàn)的,但這比較麻煩。





公司地址:安徽省安慶市迎江區(qū)綠地藍(lán)海2號樓1809-1812室