Posts

线程：我可是CPU调度的基本单位，进程是我爹

姜还是老的辣

进程：我可是操作系统调度的基本单位，线程是我儿子

使用expect可以帮我们完成一些需要交互的终端命令，比如，在用密码ssh登录服务器时，总是需要手动输入密码，可以用以下方法实现自动登录 #!/usr/bin/expect -f set username [lindex $argv 0] set host [lindex $argv 1] set port [lindex $argv 2] set password [lindex $argv 3] spawn ssh -p $port "$username@$host" expect "password" send "$password\r" interact 外部调用 /usr/bin/expect -f login_with_password.sh $user $publicIp $port $password

async function a(ctx, next) { console.log("invoke a") await next() console.log("exit a") } async function b(ctx, next) { console.log("invoke b") await next() console.log("exit b") } function compose(middleware) { return (ctx, next) => { let index = -1 async function dispatch(i) { if (i <= index) { throw new Error('next() called multiple times') } index = i let fn = middleware[i] if (i === middleware.length) { fn = next } if (!fn) { return } return await fn(ctx, () => { return dispatch(i + 1) }) } return dispatch(0) } } let func = compose([a, b]) func('context', () => { console....

踩坑集锦 此篇文章用来记录维护k8s过程中的一系列问题 容器端口被占用 Bind for 0.0.0.0:9876 failed: port is already allocated. 找到端口占用的进程 sudo lsof -i -P -n | grep 9000 杀掉进程 重启docker kubectl logs 超时 错误类似： Error from server: Get https://172.31.27.3:10250/containerLogs/prod-sfox/a-group-miner-2hshz/miner-idx-1?follow=true&tailLines=20: dial tcp 172.31.27.3:10250: connect: connection timed out 该操作走内网ip，节点间内网不同 10250端口未打开 DNS解析失败 具体错误信息一般如下： panic: dial tcp: lookup mysql on 10.96.0.10:53: no such host 查看coredns的日志，判断集群内的dns解析是否成功...

使用以下参数，不在local端去解析域名 --socks5-hostname HOST[:PORT] SOCKS5 proxy, pass host name to proxy --socks5-hostname 等同于 -x socks5h 示例: curl -x socks5h://127.0.0.1:36000 https://www.google.com.hk

先将内容排序, 排序后计数, 再按数量排序 sort | uniq -c | sort -rnk 1 r表示逆向排序， n表示按数值排序， k表示按第k列进行排序

同步异步、阻塞非阻塞，傻傻分不清

Socks5 概念 Socks5是一种网络传输协议, 用于客户端与(代理)服务器通讯使用 三个阶段 认证阶段 socks5比socks4多了一个认证阶段, 客户端必须将自己使用的socks版本, 加密方式等信息发送给服务端(以节点为单位, 总共258) VER NMETHODS METHODS 1 1 1-255 VER 使用的socks协议的版本号, 当前最新的版本号是5 NMETHODS METHODS 字段占用的字节数 METHODS METHODS是客户端支持的认证方式列表，每个方法占1字节。当前的定义是： 0x00 不需要认证 0x01 GSSAPI 0x02 用户名、密码认证 0x03 - 0x7F 由IANA分配（保留） 0x80 - 0xFE 为私人方法保留 0xFF 无可接受的方法 服务端从客户端提供的方法中选择一个并通过以下消息通知客户端:...

什么是https 首先, 在讲我们为什么需要https之前, 先看看以下两个流程, 描述了A和B之间想要互相通信, 又想让通信的内容安全 流程1 A将对称秘钥发送给B B使用该秘钥加密数据, 并发送给A A用秘钥解开B发送的内容, AB成功通信 缺陷: 当中间人C截获了首次通信时, A发送给B的秘钥, 则AB后续所有的交互信息都能被C解开 流程2 A将自己的公钥给B B收到A的公钥后, 用A的公钥加密了 B自己生成对称秘钥, 并将加密后的内容回给了B 当A收到来自B的回复, A用自己的私钥解开了B的加密内容, 从而得到了B的对称秘钥, 后续通信使用该对称秘钥加密内容 缺陷: 中间人C可在截获了A和B的首次通信后, 用自己的公钥给了B, B收到请求后,他不知道公钥是C发过来的,从而用了C的公钥加密了对称秘钥并回给了C, C拿到内容后,用自己的私钥解开内容,从而拿到了B的对称秘钥 这个流程的缺陷主要是A和B都无法确定收到的数据是来源与对方的, 而不是来源于中间人的. 引入证书 内容: 证书颁发机构 服务端网址 机构私钥加密(服务端公钥) 机构私钥加密(证书签名) 流程3 此时假设A作为服务端 A把自己的公钥给证书颁发机构...

脚本命令使用 生产消息 ./kafka-console-producer.sh --broker-list kafkas:9092 --topic user_register 输入消息: {"accountname":"test@qq.com","action":"register","appname":"CoolLine","appversion":"1.6.xx","channelName":"googleplay","cityen":"","cityzh":"","continentsen":"","continentszh":"","countryen":"","countryZh":"美国","createTimestamp":1566376441,"deviceid":"edb3d8ce8df595ad","isPrivilegedUser":"true","line":"CoolLine","mail":"test@qq.com","pkgname":"cc.coolline.client","platform":"Android","provinceen":"","provincezh":"","pt":"2019-08-21","registerip":"10.244.2.64","registertime":"2019-08-21 16:34:01","registertype":"mail","userid":19348,"userName":"test@qq.com","userpwd":"86A8F132223D033619389988E663F6C2","userstate":0,"virtualCountryCode":"AF"} 消费主题 ./kafka-console-consumer.sh --bootstrap-server kafkas:9092 --topic user_register --from-beginning 设置某个主题的消息缓存时间 ./kafka-configs.sh --zookeeper zookeeper:2181 --alter --entity-name ${主题} --entity-type topics --add-config retention.ms=86400000 立即生效 ./kafka-topics.sh --zookeeper zookeeper:2181 --alter --topic ${主题} --config cleanup.policy=delete

Cloc cloc是linux平台里可以统计代码的工具，并非简单的统计代码的行数，能同时针对各种语言做分类输出 安装 sudo apt install cloc 使用 cloc $filePath 返回结果： $ cloc . 1339 text files. 1302 unique files. 160 files ignored. github.com/AlDanial/cloc v 1.74 T=3.75 s (321.1 files/s, 135799.4 lines/s) -------------------------------------------------------------------------------- Language files blank comment code -------------------------------------------------------------------------------- Go 940 39122 40781 354176 C 37 6806 9795 31924 Markdown 49 1854 0 6552 C/C++ Header 37 1330 3531 3864 Assembly 38 503 884 2402 YAML 70 145 18 1955 Bourne Shell 13 139 323 856 JSON 1 2 0 637 make 9 73 96 296 Protocol Buffers 3 38 27 165 SQL 1 1 0 155 Python 1 14 13 99 Bourne Again Shell 1 8 3 52 TOML 2 5 45 11 Dockerfile 1 1 0 8 -------------------------------------------------------------------------------- SUM: 1203 50041 55516 403152 --------------------------------------------------------------------------------

Shell里的变量取值 # 假如 $file 没有设定，则使用 my.file.txt 作传回值。(空值及非空值时不作处理) ${file-my.file.txt} # 假如 $file 没有设定或为空值，则使用 my.file.txt 作传回值。 (非空值时不作处理) ${file:-my.file.txt} # 假如 $file 设为空值或非空值，均使用 my.file.txt 作传回值。(没设定时不作处理) ${file+my.file.txt} # 若 $file 为非空值，则使用 my.file.txt 作传回值。 (没设定及空值时不作处理) ${file:+my.file.txt} # 若 $file 没设定，则使用 my.file.txt 作传回值，同时将 $file 赋值为 my.file.txt 。 (空值及非空值时不作处理) ${file=my.file.txt} # 若 $file 没设定或为空值，则使用 my.file.txt 作传回值，同时将 $file 赋值为 my.file.txt 。 (非空值时不作处理) ${file:=my.file.txt} # 若 $file 没设定，则将 my.file.txt 输出至 STDERR。 (空值及非空值时不作处理) ${file?my.file.txt} # 若 $file 没设定或为空值，则将 my.file.txt 输出至 STDERR。 (非空值时不作处理) ${file:?...

NodeJS的module 对于 circle.js // 这种导出方式，相当于将变量地址导出，会被外界修改 exports.varA = 'varA' exports.func1 = () => { console.log('func1') } module.exports.varB = 'varB' // 以上写法等价于 module.exports = { varA: 'varA', varB: 'varB', func1 () { console.log('func') } } 在 main.js 中可以这么引入 let math = require('./utils/math') console.log(math.varA) console.log(math.varB) math.func1() math.varA = 'A'; math.varB = 'B'; math.func1 = () => { console.log('another func') } let math2 = require('./utils/math') // varA, varB 和 func1 都发生了改变，证明import进来的模块是单例的 console.log(math2.varA) console.log(math2.varB) math2.func1() ES6的module ES6 模块不是对象，而是通过export命令显式指定输出的代码，再通过import命令输入。...

异步编程 callback瀑布级回调 Promise Generator Async 和 Await 在函数体前通过关键字async可以将函数变为async函数 在async函数中对需要异步执行的函数前需加await关键字 await后的函数必须使用Promise对象封装 async函数执行后返回的是一个Promise对象 NodeJs单线程是怎么保证效率的

什么是以太坊 简单来说，以太坊就是一个基于交易的状态机。什么是状态机呢？可以将其理解成一台机器，这台机器维护着一些状态，在以太坊交易发生时，这些状态会从一个状态转化到另一个状态。以太坊时基于区块链构建的，区块链上保存着状态和交易。当我们与以太坊交互时，其实就是在执行交易、改变系统状态。 引用一个公式表示就是： σ′ =Υ(σ,T) Υ是状态转换函数，T是交易，σ是状态，σ′转换后的状态。 从创世区块开始，无尽的交易不断的刷新着系统当前状态，每产生一个区块就对当前状态做一次快照（patricia trie根）存入区块头中。 以太坊可以干什么？ 以太坊作为一个开发的区块链平台，它允许任何人在平台中建立和使用通过区块链技术运行的去中心化应用。可将之类比为Internet平台，而我们可以在其上面开发web网站。（但是似乎在以太坊上面只能开发智能合约？） 什么是智能合约？ 智能合约就是以太坊平台上运行的程序。一旦事件触发合约中的条款，代码自动执行。智能合约的功能是由开发者自行设计的。 智能合约的工作原理 构建 → 存储 → 执行 智能合约由区块链内的多个用户共同参与制定，可用于用户之间的任何交易行为。协议中明确了双方的权利和义务，开发人员将这些权利和义务以电子化的方式进行编程，代码中包含会触发合约自动执行的条件。比方说，你把一套闲置的房子租给A，那么，这份智能租约中就规定了A必须在每月5号之前给你打房租、你必须在收到房租时马上给对方钥匙［2］等条款。 一旦编码完成，这份智能合约就被上传到区块链网络上，即全网验证节点都会接收到你和A的租房合约。 智能合约会定期检查是否存在 相关事件和触发条件；满足条件的事件将会推送到待验证的队列中。假设A在4号提前打房租给你，这个事件就成了该合约的触发条件（每月5号以前）。 区块链上的验证节点先对该 事件进行签名验证 以确保其有效性；等大多数验证节点对该事件达成共识后，智能合约将成功执行，并通知用户。 成功执行的合约将移出区块。而未执行的合约则继续等待下一轮处理，直至成功执行。 部署到以太坊上的智能合约是要消耗以太币的。就好像把现实中的仲裁人、法官、执行人搬到了区块链上，尽管他们成了一行行的代码，但也是珍贵的计算机资源。智能合约也遵循“Less is more”，逻辑应尽可能地简单。逻辑越复杂，消耗的以太币就越多。 既然执行要消费以太币，如何支付呢？智能合约是预支付，为了合约顺利执行，一般提前多打一点以太币。如果预支付的以太币不足以支撑整个执行过程，就算进行到半路，合约也会回到初始状态；并且消耗的以太币也不会退回给合约发起人。 如何触发智能合约？ 智能合约本身规定了触发的条件，只要满足了条件的情况下，合约就会自动触发（比如时间到了自动缴房租）。也可以由外部账户触发。 以太坊的区块结构 区块链上最重要的结构莫过于区块的结构，以太坊的区块结构和区块链的类似，但是又有着诸多不同。 以太坊区块是由三大部分组成：区块头，叔块，交易列表。 区块头由15个字段组成。 叔块其实就是孤块，是由于某个区块上产生了多分支。因以太坊出块速度很快平均十几秒就会打包生成一个块，所以矿工挖矿的竞争性很高，可能同时产出几个都合法的区块，以太坊为了一些安全性起见，允许竞争块也挂在到主链上，同时给与挖出这些孤块的矿工们少许奖励增加工作的公平性。这些孤块最多允许6个高度，这也是6个区块确认主链说法的来源。 交易列表，存储的是本区块中所有的交易内容。 看一下一个实际的区块信息： "blocks" : [ { "blockHeader" : { "bloom" : "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", "coinbase" : "0x3535353535353535353535353535353535353535", "difficulty" : "0x020000", "extraData" : "", "gasLimit" : "0x05f5e100", "gasUsed" : "0x014fa1", "hash" : "0x39f4659b079e257df8fd7e699528531e97a6b8a442ca0d11200c4a2f7433c483", "mixHash" : "0x7379f33af4ae2db7e293f808a165135d0b1a99572cc96fb9f7d17ef64a751969", "nonce" : "0x8e08d7aabeee8773", "number" : "0x01", "parentHash" : "0xadbef3bf0b3b7b14f6e7b1a45d240ecc863543a279a86c23f60170e8e7a6bcc3", "receiptTrie" : "0xb21660268480338c0cd0613358315359b619bd527d5850949c4863cddaec316b", "stateRoot" : "0xde4ce9b5b2f88ab1680962c64281224b1743bdf94bd6a9e390ea779ff616c1f7", "timestamp" : "0x03e8", "transactionsTrie" : "0x56445ba866f3e41851154fb8700dcec8556a178f1833021e030b8a47b494769d", "uncleHash" : "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347" }, "rlp" : "0xf90308f901f9a0adbef3bf0b3b7b14f6e7b1a45d240ecc863543a279a86c23f60170e8e7a6bcc3a01dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347943535353535353535353535353535353535353535a0de4ce9b5b2f88ab1680962c64281224b1743bdf94bd6a9e390ea779ff616c1f7a056445ba866f3e41851154fb8700dcec8556a178f1833021e030b8a47b494769da0b21660268480338c0cd0613358315359b619bd527d5850949c4863cddaec316bb901000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000083020000018405f5e10083014fa18203e880a07379f33af4ae2db7e293f808a165135d0b1a99572cc96fb9f7d17ef64a751969888e08d7aabeee8773f90108f90105460183030d4094c305c901078781c232a2a521c2af7980f8385ee980b8a430c8d1da000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000230644e72e131a029b85045b68181585d2833e84879b9709143e1f593f00000001ba021a28cc82b40931239f8653ffa5300e1a506c0ef7fb79a663772cafe6558ab44a075af23441f7f176a2770af41142c77b671391209b15d59144e7a1332179b5e14c0", "transactions" : [ { "data" : "0x30c8d1da000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000230644e72e131a029b85045b68181585d2833e84879b9709143e1f593f0000000", "gasLimit" : "0x030d40", "gasPrice" : "0x01", "nonce" : "0x46", "r" : "0x21a28cc82b40931239f8653ffa5300e1a506c0ef7fb79a663772cafe6558ab44", "s" : "0x75af23441f7f176a2770af41142c77b671391209b15d59144e7a1332179b5e14", "to" : "0xc305c901078781c232a2a521c2af7980f8385ee9", "v" : "0x1b", "value" : "0x00" } ], "uncleHeaders" : [ ] } ] 区块头的结构 区块头包含15个字段，介绍如下：...

区块链的运转流程 当一笔交易经由某个节点或钱包产生时，这笔交易需要被转播给其他的节点来做验证。 产生一笔新交易 一笔新交易产生时，会被广播到区块链中的其他参与节点 各节点将多笔交易一起放进区块 每个节点会将数笔未验证的交易的hash值收集到区块中，每个区块可以包含数百笔或上千笔交易 决定由谁来打包区块 各个节点进行POW，来决定谁可以获得区块的打包权，由最快算出结果的节点打包该区块 各节点验证打包的区块 其他节点会确认这个区块所包含的交易是否有效，确认没被重复花费且具有有效数位签章后，接受该区块，此时该区块才能正式接上区块链 交易验证完成 所有节点一旦接受该区块后，先前没计算完POW工作的区块将会失效，各节点会重新建立一个区块，并开始下一轮POW计算工作 Q&A 节点如何验证某个区块的有效性？ 当某个节点收到某个区块后，需要验证的信息有三个： 区块编号有效 对区块的header进行2次hash计算，计算出来的值就是当前区块的hash值 区块的上一个区块hash值有效 对比区块里的上一个区块hash值和当前节点区块链里的最后一个区块的编号（每个节点都有着一条完整的区块链数据），如果相同则验证通过，如果不同，需要顺着已有链往前查找，直到找到这个编号的页（找到了又怎么样呢？这就代表上一个区块后面已经有别的区块链啊？？？这就形成了多分支了）。如果没有找到，则验证不通过。 交易清单有效 这里即是确认每笔交易的付款人是否有足够的余额来支付这笔钱。确认交易输入的UTXO是否存在，且在此之前没有支付给别人，另外，产生交易的节点本身并不验证交易输入的UTXO是否有效，即不验证交易输出用户的余额是否充足，余额的验证是让其他节点来做的 当节点收到一笔新交易时，是否会立即开始打包成区块的操作？ 矿工是一直在收集交易信息的，但只有等到上一个区块生成后，拿到上一个区块的hash值时，才会将收集到的交易信息打包新的区块，并进行POW工作 当一个区块发现它的上一个区块已经连接上了新的区块后，如何处理？ 这就是区块链的多分支问题，当矿工收到两份不一样的区块，它们都基于当前这个矿工节点的链上的最后一个节点，并且内容都合法，都应将其保留，按分支的形式组织起来。区块链规定，任何时刻，都以最长的链作为主链，当某个分支的长度长于另外的分支后，该分支就称为主分支了，其他分支就会被遗忘。 由于多分支问题产生的双花问题该如何解决？ 中本聪给出的解决方案是，建议收款人不要在公告挂出时立即确认交易完成，而是应该再看一段时间，等待各个挖矿小组再挂出6张确认账簿，并且之前的账簿没有被取消，才确认钱已到账。 中本聪解释道，之前设定变态的编号规则，正是为了防御这一点。根据前面所述，生成有效账簿页不是那么简单的，要花费大量的人力反复试不同的幸运数 字，而且过程完全是碰运气。如果某账簿页包含你收到钱的确认，并且在后面又延续了6个，那么攻击者想要在落后6页的情况下从另一个分支赶超当前主分支是非 常困难的，除非攻击者拥有非常多的人力，超过其他所有诚实矿工的人力之和。 而且，如果攻击者有如此多人力，与其花这么大力气搞这种攻击，还不如做良民挖矿来的收益大。这就从动机上杜绝了攻击的形成。 每个节点打包到区块里的交易都是一样的吗？ 区块的打包是由矿工来做的，矿工可能是随机地选取某几笔交易进行打包，也可能是挑选交易手续费较高的交易进行打包，因此，每个节点产生的区块是不一样的。 如果各个节点打包的区块交易是完全不同的，那会怎么样？ 比如，节点A打包了一个区块，所含的交易是1和2；节点B也打包了一个区块，所含的交易是3和4；由于两个节点打包的区块的前驱节点都是一致的，如果这两个区块都合法，且都被其他节点验证通过了，那么就会在链上形成分支。 当一个节点完成POW工作后，广播给其他节点验证时，如果有某个节点此时在进行着其他交易（即不包含相同的交易）的POW工作，会怎么样？ 会停止当前工作，先验证区块的有效性 矿工是不间断地进行挖矿工作的吗？可以光挖矿而不打包普通交易吗？ 矿工基本上就是在不间断地做POW工作的，矿工的收入主要来源于挖矿和手续费。一般来说，币的数量是有限的，前期矿工应该可以只挖矿，但为了获得更大的收益，都会选择打包有手续费的交易 产生一笔交易的时候，就会产生一个区块吗？ 并不是，收集多少笔交易之后开始打包成区块，是由挖矿策略或者挖矿程序决定的。 是否有可能区块生成时，块里没有交易数据？ 可能存在区块里有零笔普通交易，但有一个系统给予的挖矿奖励的交易。对于空交易的区块，由于数量量小，算出满足条件的区块hash值更快。据说早期的区块大都是这种。系统给予奖励，矿工们才有挖矿的热情。

提出问题 什么是Nat？ Nat全称Network Address Translation，即网络地址转换，就是替换IP报文头部的地址信息。Nat通常部署在一个组织的网络出口位置，通过将内部网络IP地址替换为出口网络的IP地址，从而提供公网连通内部网络的能力。 为什么需要Nat技术？ 解决IPV4地址即将耗尽的问题，对于有网络访问需求而内部又使用私有地址的网络，就要在组织的出口位置部署NAT网关，在报文离开私网进入Internet时，将源IP替换为公网地址，通常是出口设备的接口地址。在接收方收到访问请求后，在接收方看来，此次请求是来自组织的出口设备的，因此接收方会将响应消息发送回出口网关。出口网关再将目的地址替换为私网的源主机地址，发回内网。依据这种模型，数量庞大的内网主机就不需要公有IP地址来。 Nat网络的种类 一对一 一个内部主机占用一个公网IP，一般是用来隐藏内部主机的真实IP 一对多 典型的应用。即在一个组织网络的出口位置部署Nat网关，所有对公网的访问表现为一台主机。这里面就有产生一个问题：当有多个内部主机去访问同一个服务器时，从返回的信息不足以区分response应该转发到哪个内部主机。因此，这就需要Nat设备根据传输层信息或其他的上层协议去区分不同的会话，这里引出了后面的很多坑，这种一对多的方式也被称为端口转换PAT，NAPT或IP伪装。 在一对多模型中，按照NAT端口映射方式分类又可做进一步划分，为方便描述，将IP和端口标记为(nAddr) 全锥型（谁都可以找我） 一旦内部主机的IP和端口被Nat网关映射到某个地址A上，之后该主机的所有出口报文的源IP都会是A这个地址。任何一个外部主机 发送到A地址上时，都会被转发到该内部主机。 限制锥型（我先找你，你才能找我） 一旦内部主机的IP和端口被Nat网关映射到某个地址A上，之后该主机的所有出口报文的源IP都会是A这个地址。只有该内部主机向特定的外部主机H发送过数据，那么后续H主机从任意端口发送到地址A的报文都会被转发到该内部主机 端口限制锥型（我从某个port找过你，以后你找我也要从这个port） 基本跟限制锥型是一样的，内部主机发数据到特定外部主机的特定端口上，之后只有这个外部主机从这个特定端口发过来的数据才会被转化到该内部主机 对称型 （我从某个port找你，但你要） 同一内网主机同一端口号，当与同一外部主机通信时，NAT分配的端口号不变；每一次与不同的外网主机通讯，就重新分配另一个端口号 Nat的弊端 Nat技术最大的弊端在于 破坏了IP端到端通信的能力，首先，Nat使IP会话的保持时效变短，因为一个会话建立后会在Nat设备上建立一个关联表，在会话静默的这段时间，Nat网关会进行老化操作，会回收资源。一般基于UDP的通信协议很难确定何时通信结束，所以Nat网关主要依赖超时机制回收外部端口。如果应用需要维持连接的时间大于Nat网关的设置，通信就会意外中断。因为网关回收相关转换表资源以后，新的数据到达时就找不到相关的转换信息，必须建立新的连接。 当这个新数据是由公网侧向内网侧发送时，就会发生无法出发新连接建立，也不能通知到内网侧的主机去重建连接的情况，这时候通信就会中断。 即使新数据是从内网侧发向公网侧，因为重建的会话表往往使用不同于之前的公网IP和端口地址，公网侧的主机也无法对应到之前的通信上。 连接保活机制 Nat穿透技术 前面提出来了Nat的弊端，为例解决IP端到端应用在Nat环境下遇到的问题，一般由如下的解决方式，只是每一种方法都不完美，需要内部主机，应用程序或Nat网关上增加额外的处理。 应用层网关 因为Nat不感知应用协议，所以有必要额外为每个应用协议定制协议分析方法。 探针技术 STUN和TURN 所谓的探针技术，是通过在所有参与通信的实体上安装探测插件，以检测网络中是否存在Nat网关，并对不同模型实施不同穿透方法的一种技术。 中间件技术 通过开发通用方法解决Nat穿透，客户端会参与网关公网映射信息的维护，此时Nat网关只要理解客户端的请求并按照要求去分配转换表，不需要自己去分析客户端的应用层数据，其中典型的技术由 UPNP。 UPNP，即通用即插即用，是一个通用的网络终端与网关的通信协议，具备发布和管理控制的能力，其中，网关映射请求可以为客户动态添加映射表项。此时Nat不再需要理解应用层携带的信息，只转换IP地址和端口信息，而客户端通过控制 消息或信令 发到公网侧的信息中，直接携带公网映射的IP地址和端口，接收端可以按照此信息建立数据连接。Nat网关在接受数据或着连接请求时，按照UPNP建立的表项只转换地址和端口信息，不关心内容，再将数据转发到内网。这种方案需要网关，内部主机和应用程序都支持UPNP技术，且组网允许内部主机和Nat网关之间可以直接交换UPNP信令才能实施。 中继代理技术 在Nat网关所在位置旁边放置一个应用服务器，这个服务器在内部网络和外部公网分别由自己的网络连接，客户端特定的应用产生网络请求时，将定向发送到应用代理服务器，应用代理服务器根据代理协议解析客户端的请求，再从服务器的公网侧发起一个新的请求，把客户端请求的内容中继到外部网络上，返回的相应反方向中继。 特定协议的自穿越技术 基于UDP协议的P2P打洞技术详解 什么是UDP打洞？ Nat技术和P2P技术在现有网络上都有着广泛应用，P2P主机位于Nat网关后面的情况屡见不鲜，Nat技术虽然在一定程度上解决了IPv4地址短缺的问题，在构建防火墙，保证网络安全方面都发挥了一定的作用，但却破坏了端到端的网络通信，Nat阻碍主机进行P2P通信的主要原因是Nat不允许外部主机主动访问内网主机，但是P2P技术却要求通信双方都能主动发起访问，所以要在Nat网络环境中进行有效的P2P通信，就必须采用新的解决方案。 原理 UDP打洞技术是通过集中服务器的协助，在各自的Nat网关上建立相应的表项，使P2P连接的双方发送的报文能够直接穿透对方的Nat网关 ，从而实现P2P客户端的互联。 什么是集中服务器 集中服务器本质是一台被设置在公网的服务器，建立P2P的双方都可以直接访问到这台服务器，位于Nat网关后面的客户端A和客户端B都可以与一台已知的集中服务器建立连接，并通过这台服务器了解对方的信息并中转各自的信息。 同时集中服务器的另一个重要的作用是判断某个客户端是否在Nat网关之后。具体的方法是：一个客户端在集中服务器登陆的时候，服务器记录下该客户端的两对二元组信息 {IP地址: UDP端口}，其中一对可以看作是内网IP和端口，另一对可以看作是外网IP和端口。如果该客户端不是位于Nat设备后面，那么两对IP端口应该是一样的。 打洞session的建立 假设A要向B发起连接请求，具体的打洞过程如下： A最初不知道如何向B发起连接，于是A向集中服务器发送消息，请求集中服务器帮助建立与B的UDP连接...