網(wǎng)上搜索了不少tcp內(nèi)網(wǎng)穿透的代碼，功能全的大多是go版本，無(wú)奈對(duì)go不感冒。
后來(lái)一直搜索python的tcp內(nèi)網(wǎng)穿透代碼，版本很少，而且大多有各種缺陷，后來(lái)搜索到shootback，運(yùn)行比較穩(wěn)定。
但想加入更多功能，所以重新改造了代碼，實(shí)現(xiàn)了更多功能。
通過(guò)外網(wǎng)vps在任意地方訪問(wèn)沒(méi)有公網(wǎng)獨(dú)立ip的電腦，樹(shù)莓派等等
使內(nèi)網(wǎng)網(wǎng)站能被公網(wǎng)訪問(wèn)
實(shí)現(xiàn)域名訪問(wèn)內(nèi)網(wǎng)指定網(wǎng)站
給域名訪問(wèn)的用戶(hù)進(jìn)行簡(jiǎn)單http授權(quán)驗(yàn)證
方便的在本地調(diào)試支付接口
動(dòng)態(tài)識(shí)別服務(wù)端配置，避免重啟進(jìn)程
各種內(nèi)網(wǎng)tcp暴露到公網(wǎng)，比如在手機(jī)上vnc登錄家里的樹(shù)莓派桌面。
服務(wù)端需要python3版本
客戶(hù)端可以使用python2和3版本【如果python2使用有問(wèn)題，請(qǐng)用python3啟動(dòng)客戶(hù)端】
服務(wù)端配置文件config.json
*server文件夾是公網(wǎng)服務(wù)器使用的
*slaver文件夾是內(nèi)網(wǎng)服務(wù)器使用的
服務(wù)器配置為10秒檢測(cè)一次。
如果tcp配置項(xiàng)需要修改，請(qǐng)先刪除目標(biāo)配置項(xiàng)，等服務(wù)器檢測(cè)刪除端口后，再添加配置項(xiàng)進(jìn)去。
如果是tcp新增或者刪除，則可以直接修改json配置。
http的customer，to_master如果要修改，需要重新運(yùn)行服務(wù)端配置。
http的域名驗(yàn)證，域名訪問(wèn)可以隨時(shí)修改，隨時(shí)生效
to_master:過(guò)公網(wǎng)服務(wù)器哪個(gè)端口進(jìn)行域名轉(zhuǎn)發(fā),端口必須在tcp配置組里存在
customer:域名請(qǐng)求哪個(gè)端口
host數(shù)組項(xiàng)目::可以訪問(wèn)的域名，和對(duì)應(yīng)域名的授權(quán)帳號(hào)密碼
master:公網(wǎng)服務(wù)器提供給內(nèi)網(wǎng)服務(wù)器使用的端口
customer:公網(wǎng)訪客通過(guò)這個(gè)接口可以訪問(wèn)連接master的內(nèi)網(wǎng)服務(wù)器端口
secretkey:內(nèi)網(wǎng)服務(wù)器連接master需要使用的密鑰
config.json
{
"http":{
"to_master":"0.0.0.0:10001",
"customer":"0.0.0.0:80",
"host":[
{
"domain":"pwd.yourdomain.com",
"auth":{
"username":"cncn",
"password":"1234"
}
},
{
"domain":"nopwd.yourdomain.com"
}
]
},
"tcp":[
{
"master":"0.0.0.0:10001",
"customer":"0.0.0.0:10101",
"secretkey":"pwd001"
},
{
"master":"0.0.0.0:10002",
"customer":"0.0.0.0:10102",
"secretkey":"pwd002"
}
]
}配置好服務(wù)器config.json后 服務(wù)在進(jìn)入server文件夾，執(zhí)行
python3 server.py
或者后臺(tái)運(yùn)行
nohup python3 server.py >log_server.log 2>&1 &客戶(hù)端進(jìn)入slaver文件夾，執(zhí)行
文章來(lái)源：加米谷大數(shù)據(jù)
下面我們列出一些重要的配置。我們已經(jīng)將這部分分為必需的配置和值得推薦的配置。
HBase所需的配置
請(qǐng)你參考本教程中HBase基礎(chǔ)條件中的操作系統(tǒng)和Hadoop部分的內(nèi)容！
大型群集配置
如果您擁有一個(gè)包含大量區(qū)域的群集，那么在主服務(wù)器啟動(dòng)后，Regionserver可能會(huì)暫時(shí)地進(jìn)行檢查，而所有剩余的RegionServers落后。要簽入的第一臺(tái)服務(wù)器將被分配到所有不是最優(yōu)的區(qū)域。為防止出現(xiàn)上述情況，請(qǐng)將其hbase.master.wait.on.regionservers.mintostart屬性從其默認(rèn)值1中調(diào)高。
HBase推薦的配置
ZooKeeper 配置：zookeeper.session.timeout
默認(rèn)的超時(shí)時(shí)間是三分鐘（以毫秒為單位）。這意味著，如果服務(wù)器崩潰，則在主服務(wù)器在三分鐘前發(fā)現(xiàn)崩潰并開(kāi)始恢復(fù)。您可能需要將超時(shí)調(diào)整到一分鐘甚至更短的時(shí)間，以便主服務(wù)器盡快通知故障。在更改此值之前，請(qǐng)確保您的JVM垃圾收集配置處于受控狀態(tài)，否則，長(zhǎng)時(shí)間的垃圾回收會(huì)超出ZooKeeper會(huì)話超時(shí)時(shí)間，將取出您的RegionServer。（如果一個(gè)RegionServer長(zhǎng)時(shí)間處于GC狀態(tài)，你可能需要在服務(wù)器上啟動(dòng)恢復(fù)）。
要更改此配置，請(qǐng)編輯hbase-site.xml，將更改的文件復(fù)制到群集中并重新啟動(dòng)。
我們將這個(gè)值設(shè)置得很高，以避免不必要的麻煩。如果出現(xiàn)類(lèi)似“為什么我在執(zhí)行一個(gè)大規(guī)模數(shù)據(jù)導(dǎo)入的時(shí)候Region Server死掉啦”這樣的問(wèn)題，可以解釋的原因是：他們的JVM未被解析，并且正在運(yùn)行長(zhǎng)時(shí)間的GC操作。
ZooKeeper 實(shí)例的數(shù)量
HDFS 配置
dfs.datanode.failed.volumes.tolerated
這是“DataNode 停止提供服務(wù)之前允許失敗的卷數(shù)。默認(rèn)情況下，任何卷失敗都會(huì)導(dǎo)致 datanode 關(guān)閉”從HDFS-default.xml中的描述。您可能希望將其設(shè)置為可用磁盤(pán)數(shù)量的一半左右。
hbase.regionserver.handler.count
此設(shè)置定義了為應(yīng)答傳入的用戶(hù)表請(qǐng)求而保持打開(kāi)的線程數(shù)。經(jīng)驗(yàn)法則是，當(dāng)每個(gè)請(qǐng)求的有效載荷接近MB（大容量、掃描使用大緩存）時(shí)保持低數(shù)字，并且當(dāng)有效負(fù)載?。ǐ@取，小投入，ICV，刪除）時(shí)保持此數(shù)字為高。正在進(jìn)行的查詢(xún)的總大小受設(shè)置hbase.ipc.server.max.callqueue.size的限制。
如果這個(gè)數(shù)字的有效載荷很小，那么將這個(gè)數(shù)字設(shè)置為最大傳入客戶(hù)端數(shù)量是安全的，典型的例子是一個(gè)服務(wù)于網(wǎng)站的集群，因?yàn)閜ut通常不被緩沖，大部分操作都是獲取的。
保持此設(shè)置的高風(fēng)險(xiǎn)的原因是，當(dāng)前在區(qū)域服務(wù)器中發(fā)生的所有投入的總大小可能對(duì)其內(nèi)存造成太大的壓力，甚至?xí)|發(fā)OutOfMemoryError。在低內(nèi)存上運(yùn)行的RegionServer將觸發(fā)其JVM的垃圾收集器，以更頻繁的方式運(yùn)行，直到GC暫停變得明顯（原因是用于保留所有請(qǐng)求的有效載荷的所有內(nèi)存不能被丟棄，即便垃圾收集器正在進(jìn)行嘗試）。一段時(shí)間之后，整個(gè)群集吞吐量都會(huì)受到影響，因?yàn)槊總€(gè)碰到該RegionServer的請(qǐng)求都將花費(fèi)更長(zhǎng)的時(shí)間，這更加劇了問(wèn)題的嚴(yán)重性。
您可以通過(guò)rpc.logging查看某個(gè)RegionServer上是否有太多或太多的處理程序，然后跟蹤其日志（排隊(duì)請(qǐng)求消耗內(nèi)存）。
大型內(nèi)存機(jī)器的配置
HBase提供了一個(gè)合理的，保守的配置，可以在幾乎所有人們可能想要測(cè)試的機(jī)器類(lèi)型上運(yùn)行。如果你有更大的機(jī)器 - HBase有8G或更大的堆 - 你可能會(huì)發(fā)現(xiàn)下面的配置選項(xiàng)很有幫助。
壓縮（Compression）
您應(yīng)該考慮啟用ColumnFamily壓縮。有幾個(gè)選項(xiàng)可以在大多數(shù)情況下都是通過(guò)減小StoreFiles的大小來(lái)提高性能，從而減少I(mǎi) / O。
請(qǐng)參閱“HBase壓縮”了解更多信息。
配置WAL文件的大小和數(shù)量
在發(fā)生RS故障的情況下，HBase使用wal恢復(fù)尚未刷新到磁盤(pán)的memstore數(shù)據(jù)。這些WAL文件應(yīng)該配置為略小于HDFS塊（默認(rèn)情況下，HDFS塊為64Mb，WAL文件為?60Mb）。
HBase也對(duì)WAL文件的數(shù)量有限制，旨在確保在恢復(fù)過(guò)程中不會(huì)有太多的數(shù)據(jù)需要重放。這個(gè)限制需要根據(jù)memstore配置進(jìn)行設(shè)置，以便所有必要的數(shù)據(jù)都可以適用。建議分配足夠多的WAL文件來(lái)存儲(chǔ)至少那么多的數(shù)據(jù)（當(dāng)所有的存儲(chǔ)都接近完整時(shí)）。例如，對(duì)于16Gb RS堆，默認(rèn)的memstore設(shè)置（0.4）和默認(rèn)的WAL文件大?。?60Mb），16Gb * 0.4 / 60，WAL文件數(shù)的起點(diǎn)為?109。但是，由于所有的memstores不會(huì)一直占滿，所以可以分配更少的WAL文件。
管理分割（Splitting）
HBase通常會(huì)根據(jù)您的hbase-default.xml和hbase-site.xml 配置文件中的設(shè)置來(lái)處理您所在區(qū)域的分割。重要的設(shè)置包括：hbase.regionserver.region.split.policy，hbase.hregion.max.filesize，hbase.regionserver.regionSplitLimit。分割的一個(gè)簡(jiǎn)單的觀點(diǎn)是，當(dāng)一個(gè)區(qū)域發(fā)展到hbase.hregion.max.filesize時(shí)，它被分割。對(duì)于大多數(shù)使用模式，您應(yīng)該使用自動(dòng)分割。有關(guān)手動(dòng)區(qū)域分割的更多信息，請(qǐng)參閱手動(dòng)區(qū)域分割決策。
不要讓HBase自動(dòng)分割你的區(qū)域，你可以選擇自己管理分割。HBase 0.90.0增加了這個(gè)功能。如果你知道你的密鑰空間，手動(dòng)管理分割就行，否則讓HBase為你分割。手動(dòng)分割可以減輕在負(fù)載下的區(qū)域創(chuàng)建和移動(dòng)。這也使得區(qū)域邊界是已知的和不變的（如果你禁用區(qū)域分割）。如果使用手動(dòng)分割，則可以更輕松地進(jìn)行交錯(cuò)式的基于時(shí)間的主要壓縮來(lái)分散網(wǎng)絡(luò)IO負(fù)載。
禁用自動(dòng)分割：要禁用自動(dòng)拆分，可以在集群配置或表配置中設(shè)置區(qū)域拆分策略：org.apache.hadoop.hbase.regionserver.DisabledRegionSplitPolicy
自動(dòng)分割建議：如果禁用自動(dòng)分割來(lái)診斷問(wèn)題或在數(shù)據(jù)快速增長(zhǎng)期間，建議在您的情況變得更加穩(wěn)定時(shí)重新啟用它們。
確定預(yù)分割區(qū)域的最佳數(shù)目：
預(yù)分割區(qū)域的最佳數(shù)量取決于您的應(yīng)用程序和環(huán)境。一個(gè)好的經(jīng)驗(yàn)法則是從每個(gè)服務(wù)器的10個(gè)預(yù)分割區(qū)域開(kāi)始，隨著時(shí)間的推移數(shù)據(jù)不斷增長(zhǎng)。盡量在區(qū)域太少的地方犯錯(cuò)，稍后進(jìn)行滾動(dòng)分割更好。區(qū)域的最佳數(shù)量取決于您所在區(qū)域中最大的StoreFile。如果數(shù)據(jù)量增加，最大的StoreFile的大小將隨著時(shí)間增加。目標(biāo)是使最大的區(qū)域足夠大，壓實(shí)選擇算法僅在定時(shí)的主要壓實(shí)期間將其壓縮。否則，該集群可能會(huì)同時(shí)出現(xiàn)大量壓實(shí)區(qū)域的壓實(shí)風(fēng)暴。數(shù)據(jù)增長(zhǎng)導(dǎo)致壓縮風(fēng)暴，而不是人工分割決策，這一點(diǎn)很重要。
如果區(qū)域被分割成太多的區(qū)域，可以通過(guò)配置HConstants.MAJOR_COMPACTION_PERIOD來(lái)增加主要的壓縮間隔。HBase 0.90引入了org.apache.hadoop.hbase.util.RegionSplitter，它提供所有區(qū)域的網(wǎng)絡(luò)IO安全滾動(dòng)分割。
管理壓縮（Compactions）
默認(rèn)情況下，主要的壓縮計(jì)劃在7天內(nèi)運(yùn)行一次。在HBase 0.96.x之前，默認(rèn)情況下主要的壓縮計(jì)劃是每天發(fā)生一次。
如果您需要精確控制主要壓縮的運(yùn)行時(shí)間和頻率，可以禁用托管的主要壓縮。請(qǐng)參閱“compaction.parameters表中的hbase.hregion.majorcompaction條目”的詳細(xì)信息。
不禁用主要壓縮：對(duì)于StoreFile清理來(lái)說(shuō)，重要的壓縮是絕對(duì)必要的。不要完全禁用它們。您可以通過(guò)HBase shell或Admin API手動(dòng)運(yùn)行主要壓縮。
預(yù)測(cè)執(zhí)行（Speculative Execution）
預(yù)測(cè)執(zhí)行MapReduce任務(wù)是默認(rèn)開(kāi)啟的，對(duì)于HBase集群，通常建議關(guān)閉系統(tǒng)級(jí)的推測(cè)執(zhí)行，除非您需要在特定情況下可以配置每個(gè)作業(yè)。將屬性 mapreduce.map.speculative 和 mapreduce.reduce.speculative 設(shè)置為 false。
其他配置
平衡器（Balancer）
平衡器（Balancer）是在主服務(wù)器上運(yùn)行的一個(gè)周期性操作，用于重新分配集群上的區(qū)域。它通過(guò)hbase.balancer.period配置，默認(rèn)為300000（5分鐘）。
有關(guān)LoadBalancer的更多信息，請(qǐng)參閱master.processes.loadbalancer。
禁用Blockcache
不要關(guān)閉塊緩存（你可以通過(guò)設(shè)置hfile.block.cache.size為零來(lái)實(shí)現(xiàn)）。這樣做沒(méi)有好處，因?yàn)镽egionServer將花費(fèi)所有的時(shí)間一次又一次地加載HFile索引。如果你的工作集是這樣配置塊緩存，那么沒(méi)有益處，最少應(yīng)保證hfile指數(shù)保存在塊緩存內(nèi)的大?。憧梢酝ㄟ^(guò)調(diào)查RegionServer UI粗略地了解你需要的大??；請(qǐng)參閱占網(wǎng)頁(yè)頂部附近的索引塊大小）。
Nagle’s或小包裝的問(wèn)題
如果在對(duì)HBase的操作中出現(xiàn)大約40ms左右的延遲，請(qǐng)嘗試Nagles的設(shè)置。例如，請(qǐng)參閱用戶(hù)郵件列表線程，將緩存設(shè)置為1的不一致掃描性能以及其中所引用的設(shè)置tcpNoDelay來(lái)提高掃描速度的問(wèn)題。您也可以查看該文檔的尾部圖表：HBASE-7008 Set掃描緩存到一個(gè)更好的默認(rèn)位置，我們的Lars Hofhansl會(huì)嘗試使用Nagle打開(kāi)和關(guān)閉測(cè)量效果的各種數(shù)據(jù)大小。
更好的平均恢復(fù)時(shí)間（MTTR）
這部分是關(guān)于在服務(wù)器出現(xiàn)故障后會(huì)使服務(wù)器恢復(fù)更快的配置。請(qǐng)參閱Deveraj Das和Nicolas Liochon博客文章：簡(jiǎn)介HBase平均恢復(fù)時(shí)間（MTTR）。
HBASE-8354強(qiáng)制Namenode使用lease恢復(fù)請(qǐng)求循環(huán)的問(wèn)題是混亂的，但在低超時(shí)以及如何引起更快的恢復(fù)，包括引用添加到HDFS的修復(fù)程序方面，有很多好的討論。下面建議的配置是Varun的建議的提煉和測(cè)試，確保你在HDFS版本上運(yùn)行，所以你有他所提到的修補(bǔ)程序，并且他自己添加到HDFS，幫助HBase MTTR（例如HDFS-3703，HDFS-3712和HDFS-4791 -Hadoop 2確保有他們并且后期Hadoop 1有一些）。在RegionServer中設(shè)置以下內(nèi)容：
在NameNode/DataNode端，設(shè)置以下內(nèi)容來(lái)啟用HDFS-3703，HDFS-3912中引入的“staleness”：
JMX
JMX（Java Management Extensions，Java管理擴(kuò)展）提供了內(nèi)置的工具，使您能夠監(jiān)視和管理Java VM。要啟用遠(yuǎn)程系統(tǒng)的監(jiān)視和管理，在啟動(dòng) Java VM 時(shí)，您需要設(shè)置系統(tǒng)屬性com.sun.management.jmxremote.port（要啟用JMX RMI連接的端口號(hào)）。從歷史上看，除了上面提到的端口之外，JMX還會(huì)打開(kāi)兩個(gè)附加的隨機(jī)TCP偵聽(tīng)端口，這可能會(huì)導(dǎo)致端口沖突問(wèn)題。
作為一種替代方法，您可以使用HBase提供的基于協(xié)處理器的JMX實(shí)現(xiàn)。要在0.99或更高版本中啟用它，請(qǐng)?jiān)趆base-site.xml中添加以下屬性：
不要同時(shí)為Java VM 設(shè)置com.sun.management.jmxremote.port
目前它支持Master和RegionServer Java VM。默認(rèn)情況下，JMX偵聽(tīng)TCP端口10102，您可以使用以下屬性進(jìn)一步配置端口：
在大多數(shù)情況下，注冊(cè)表端口可以與連接器端口共享，所以只需要配置regionserver.rmi.registry.port。但是，如果要使用SSL通信，則必須將2個(gè)端口配置為不同的值。
默認(rèn)情況下，密碼認(rèn)證和SSL通信被禁用。要啟用密碼驗(yàn)證，您需要像下面那樣更新hbase-env.sh：
請(qǐng)參閱$ JRE_HOME/lib/management下面的示例password/access文件。
要使用密碼驗(yàn)證啟用SSL通信，請(qǐng)按照以下步驟操作：
然后像下面這樣更新hbase-env.sh：
最后，使用密鑰存儲(chǔ)在客戶(hù)端上啟動(dòng) jconsole：
要在主服務(wù)器上啟用HBase JMX實(shí)現(xiàn)，還需要在hbase-site.xml中添加以下屬性：
端口配置的相應(yīng)屬性為：master.rmi.registry.port（默認(rèn)為10101）和master.rmi.connector.port（默認(rèn)情況下與registry.port相同）。