各位都是程序員,工做中是否是遇到個相似狀況。
在家裏研究的一些開源代碼或寫的一些demo或試驗代碼,在工做中正好須要參考一下,可是在家裏的電腦上。
雖然這些均可以用雲盤/網盤之類的來完成,源代碼也能夠託管到源碼平臺。
可是這些都有必定侷限性,先不說你不可能把全部東西都上傳到雲盤或git,就算你真的全上傳了,在公司你也須要在從新部署一遍。
不少時候,咱們只是想參考一下運行起來是很麼樣子而已,從新部署跟據環境差別的不一樣每每須要浪費不少時間,有的時候還得從新錄入一些測試數據(由於數據庫同步就更麻煩)
。
試想一下,若是咱們能夠
直接訪問家裏的電腦,並且能夠直接連到家裏電腦上數據庫上是否是很爽。
咱們知道,若是想經過互聯網來訪問家裏的電腦,那麼首先就得要知道家裏電腦的公網 IP 地址。可是,家用寬帶
通常
是沒有固定IP地址的,每次鏈接上網後該地址都會隨機改變,這樣咱們要在外訪問家裏的電腦就變得有些麻煩了。因此,這時候咱們就須要用到
DDNS
(Dynamic Domain Name Server)
。
在開始以前,你們先注意看一下下面這幾個前提條件,省得浪費時間。由於不是全部網絡都須要(或能夠用到)DDNS的,並且DDNS也不能解決全部問題。
1.若是你的網絡有固定IP或沒有公網IP地址就不用看這篇文章了,前者沒有必要,後者靠DDNS也解決不了。
2.在全球IP資源緊張的狀況下(固然也有別的緣由),目前大多數
ISP對家用寬帶都再也不提供公網IP,須要本身申請,目前已知的是電信/聯通能夠本身申請,但其餘二級
ISP都再也不提供公網IP地址了
。
因此,若是你用的是長城、艾普、移動之類的寬帶也不用看了,實現不了。
3.目前全國全部家用寬帶上傳80端口都是被封了的,其它端口跟據運營商或地區也有被封的(2一、8080之類經常使用的),注意本身測試,選可用的端口進行服務。
4.爲何不用花生殼或nat123之類的現成的DDNS服務?
這個扯到錢的問題了,固然
若是你是土豪,請隨意(若是你真土豪的話,直接開通商業寬帶用固定IP地址就好了)。
經過官方介紹咱們知道,所謂雲解析,其它就是讓咱們能夠本身編寫程序經過調用API來管理域名,包括解析(目前官方提供 JAVA、PHP、Python、C#的開發SDK)。
爲了方便描述,咱們在這裏做一些名詞約定,若是沒有特殊說明,文章中都使用簡稱。
API 默認是指 雲解析DNS服務API 的簡稱,
路由 是指 家庭環境的總路由器,
局域網 是指 家庭環境的局域網
,
公網IP 是指
家庭環境的公網IP
,
第三方服務 是指 一個能返回公網IP的服務真的第三方(例如:ip138)
,
「第三方服務」
(
帶引號的
) 是指 你本身可隨意控制的、能經過互聯網進行訪問,有固定訪問地址的服務(例如:你本身購買了雲服務器,通常都是有固定地址的)。
看完上面幾點,若是沒有問題的話,咱們就能夠正式搭建DDNS服務了。
首先
,咱們須要一臺在家庭網絡下運行的設備來運行一個DDNS客戶端。(不僅侷限於電腦,理論上只要是能夠運行程序,能主動對外發出請求的設備都行,最好是能夠24小時不間斷的工做,斷電或斷網後能夠自行恢復的。能夠是電腦/服務器、
樹莓派、可安裝插件的智能路由器均可行
)
其次,針對不一樣設備,解決方案也略有不一樣,主要緣由是:
a.
上面的設備除了路由器外,其餘設備都須要藉助
第三方
服務
才能取得公網IP地址。
b.既然須要用到
第三方
服務,那
由誰發
向API發送更新請求呢?
但整體來講也就兩步:第一步,獲取到公網IP地址。第二步,在IP變化時,向API發送更新請求。
跟據以上狀況,咱們可獲得三種最優的解決方案(相對而言,更小的成本、最小的風險、
最快的解析生效時間
)。
方案1,路由 + API
方案2,局域網內設備 + 第三方能返回公網IP的
服務 +
API
方案3,局域網內設備 + 「
第三方服務
」 +
API
第一種方案是最完美的方案,由於路由器耗電少,能夠24小時不間斷工做,斷電或斷網均可以自動鏈接,能夠第一時間檢測到公網IP的變化。可是,目前還沒見到市面上那款路由器集成這個的(有集成的花生殼的),因此你就須要一個智能路由器而後本身開發插件,大多數路由插件都是C/C++,但好在這個功能很簡單,並且相關的SDK官方雖然沒有提供,但開源社區裏有。整體而言,這個方案相於而言要複雜些,但也是最理想的。
第二種方案,局域網內設備
上面運行一個DDNS客戶端或插件
直接與API
交互,缺點就是須要藉助第三方服務來獲公網IP地址。咱們知道,最大解析生效時間 = TTL + 獲取IP的週期時間
,因此咱們但願獲取IP的週期當前是越短越好,但這樣被封的概率就越大,增長了些不穩定的因數。
第三種方案,一樣是
局域網內設備
上面運行一個DDNS客戶端或插件,但不
直接與API
交互,只須要不停的向「第三方服務」 發送
心跳請求
就行
,而後「
第三方服務
」才
與API
交互
。
思路都介紹清楚了,下面咱們就進入到實戰階段。
由於我是搞.net的,對.net最熟悉,因此代碼都是C#的。其實,其它語言像go,php,node.js,python的解決方案都比.net的多,只是我不熟悉這些語言,很差修改,因此就準備本身動手。
固然,動手以前去github上搜一下有沒有現成的,結果還真找到了一個,用的是上面第二種方案,代碼是基於.net core的,並支付
docker,能夠說
至關不錯(github)。
不過
我使用的過程當中遇到一些小問題。我家裏服務器是windows server 2016的系統,雖然2016集成了
docker,但我折騰了好幾天並無在windows 2016上把docker跑起來,這樣就不能以服務的方式運行,也無法開機啓動。
因此我就把原代碼修改了一下,改爲windows服務了
。
還沒完呢,對我這種追求完美的人來講,用第三方的服務來獲取IP實現的仍是有些不爽,並且我家裏是臺微服務器,仍是乞丐版,配置很低(竟然用了40多M內存),我本身在阿里雲上也有服務器。
因此,我又動手把源碼改爲第三種方案了。
原先準備在家和阿里雲之間用TCP或UDP來連接,這樣實時性最好,最後一想太麻煩了,也沒有必要。就
直接HTTP協議來多好,還能夠把原先阿里雲上的web網站利用起來,改一下就能夠了。
這樣家裏這臺微服務器只須要不斷請求阿里雲上的網站的一個地址就好了(也是寫了一個
windows服務,1分鐘請求一次,並且這個服務只會用到10幾M內存
)。
oschina
代碼說明:
1.代碼分爲兩部分,有個叫aspnetCore的項目,是第三種方案中用在遠程服務器上的,由於我是在已有的網站上改造的,因此單獨寫了一個示例代碼,你可能將它集成到你本身的網站上。
2.src目錄下的AliyunDDNS.Client項目是第二種方案的windows服務版,爲了方便服務的安裝和卸載,我寫了兩個叫Install.bat、Uninstall.bat的批處理文件,在項目的
bin/Debug目錄下(注意:遠行時可能須要用管理員權限運行)。
3.src目錄下的AliyunDDNS.HeartbeatService的項目是第三種方案的客戶端,也是一個
windows服務,用於不斷的對外發出請求,一樣在
bin/Debug目錄下也有
Install.bat、Uninstall.bat
。
下面是遠行起來的一些效果截圖(有圖有真相嘛,哈哈)
![](http://static.javashuo.com/static/loading.gif)
一些知識點
a.局域網內的計算機或設備直接從本地是獲取不到公網IP地址的,必須藉助於某個可以返回IP的第三方服務才行(網上的方案大可能是藉助ip138)。
b.服務端能夠很容易獲取到客戶端的公網IP地址,若是服務器端和客戶端不在同一個局域網,那麼獲取的就是公網IP地址(這裏不考慮代理的狀況)。
c.解析生效時間 = TTL + 獲取IP的週期時間。阿里雲解析免費版TTL爲10分鐘,收費的最高爲1秒。因此
獲取IP的週期時間應該儘可能短小,路由器能直接監聽到IP的變化,但其餘設備就須要和第三方交互並經過不斷輪詢的方式來獲取。
題外話
像花生殼這類的公司
(其餘的都差很少)
,主打功能是內網穿透,就成本而言,
內網版和
公網版能夠說一個是天上,一個是地下
。
可是,在前面一、二、3的大背景下,內網版更有商業價值,因此這類公司,對
內網版
和
公網版
訂價相差並不大, 因此形成公網版價格虛高,全部有些不划算。(公網版纔是DDNS服務,內網穿透功能其實上是代理)。
就以花生殼來講吧,之前花錢買了個花生殼專業版,都常常性訪問不到。開始不知道緣由,一直覺得是本身網絡環境的問題,一個偶然狀況下,發現了花生殼商城有個測試頁面沒有關閉,0元就能夠買到全套花生殼服務,果斷下單買了一個「鉑金版終身服務」,那速度就很快了,用起來就一點兒問題都沒有。你想一想,專業版都這樣,你要花多少錢才能買到一個穩定的服務呢。固然了,若是你沒有公網IP地址,這也不失爲一個好的選擇(花生殼這公司我也是醉了。1.犯這麼低級的錯誤。2.沒見過購買虛擬服務還要運費的。3.我把該BUG報告給他們管理員,他丫的招呼都不打就把訂單取消就算解決問題了,並且10塊錢運費也沒退還)。