让同一个端口监听两种不同的协议，这本身是一个不好的设计，一般80端口提供HTTP协议，443端口提供HTTPS协议。不过Netty已经提供了同一个端口支持SSL和non-SSL的工具类OptionalSslHandler。参考一下：[链接]

根据 node如何让一个端口同时支持https与http 文中描述的https数据流的第一位是十六进制“16”，转换成十进制就是22，在读取的第一位数据进行判断实现动态添加 ChannelHandler 。

{代码...} 这个方式编写my.map中map必须是一个对象，如果你需要想这样获取Map的话， 正确写法 {代码...} yml文件 {代码...} 但是其实这样写非常不友好哦 有一种更加优美的写法： 创建一个类： {代码...} 在该类上加入如上注解： {代码...} yml写法： {代码...}

握手时的 wscale 参数影响了，后面的win 都是扩大后

跟客户端代码有关，使用 jetty 进行创建客户端时出现的问题，换成 netty 后则好了，但是 curl 时确实也提示错误，按理应该能够正常请求响应，具体原因还带细查。

研究了一天，最后得出的结论是，客户端会与 LVS 集群(包括LVS、real server)进行 TCP 连接，但是 LVS 服务器不会与 real server 再建立一次 TCP 连接，只会转发 TCP 报文

traceroute 的原理是通过发送几个 TTL 不同的 UDP 包，然后期待收到 ICMP type 11 的回应，借此来探测中间节点 IP。

TiDB-Binlog 组件用于收集 TiDB 的 binlog，并提供实时备份和同步功能。该组件在功能上类似于 MySQL 的主从复制，MySQL 的主从复制依赖于记录的 binlog 文件，TiDB-Binlog 组件也是如此，主要的不同点是 TiDB 是分布式的，因此需要收集各个 TiDB 实例产生的 binlog，...

最新版的 node 支持最新版 ECMAScript 几乎所有特性，但有一个特性却一直到现在都还没有支持，那就是从 ES2015 开始定义的模块化机制。而现在我们很多项目都是用 es6 的模块化规范来写代码的，包括 node 项目，所以，node 不能运行 es6 模块文件就会很不便。

IP（IPv4、IPv6）相当于 OSI 参考模型中的第3层——网络层。网络层的主要作用是“实现终端节点之间的通信”。这种终端节点之间的通信也叫“点对点通信”。