横向比较

字符编码 ascii , Unicode ,UTF-8 ，UTF16,UTF32…

• 阮一峰的文章

##编码和网络字节序
最近在做一个项目时，遇到一个问题：

1

应用层的数据组织格式是json，字符集的编码是UTF-8，把数据encode时，是否要将数据转成大端模式（网络字节序）？

1

答案是：UTF-8 编码不需要，但UTF-16，UTF-32 需要

我一开始觉得对于utf-8 也需要考虑大小端的问题，我的出发点是：
utf-8 编码的数据会有非单字节的表示的数据

现在理清楚

• 首先，应用层数据对于TCP/IP协议栈时透明的（也就是传输层，及以下，把应用层的数据当成字节流而已，不去解析数据）

• 客户端从服务器获取到数据后，手动去解析，或者用文本查看器查看文本，只要按UTF-8 编码方式去解析（单字节解析），就不存在大小端问题

• 假如，用UTF-16 或者UTF-32 编码，客服端的处理器架构不一样（大端，小端都有），那么解析编码时（假如用UTF-16 ），两个字节一块提取出来，放到内存里面，矛盾就会出现～

• 所以，假如用UTF-16，UTF-32 编码，统一将数据转成大端模式（或小端模式的数据），各自特定平台，就根据自己平台的特点，如果矛盾，进行处理，再解析（不矛盾，就直接解析）

make your gnome-terminal support 256 colors

1
2
3
4

if [[ ($COLORTERM == gnome-terminal || $(cat /proc/$PPID/cmdline) == *gnome-terminal* )
    && $TERM != screen* ]]; then
    export TERM=xterm-256color
fi

关键是

1

export TERM=xterm-256color

如此配置仅在 GNOME Terminal 、且不在 screen/tmux 会话中时设置为 xterm-256color 。

bash ? ～～ no! oh-my-zsh
zsh 完全兼容 bash，首先把你的 bashrc 直接拷贝进zshrc
啥？你还是玩bash？那好吧，来，看个小视频(点这，你得翻墙)
等等，zsh又得配置半天入门，好吧，来份oh-my-zsh点这

必要的插件安装：

• git
• autojump (记录最近使用过的目录，跳转极为方便，使用方法自行google)

zsh 主题：

我用的是 robbyrussell, agnoster 看起来比较牛逼（我目前没有成功安装，装了字体拓展还是不行，见鬼）

终端配色丑？-_-
我用的是 gnome-terminal ，我就讲我的配置的步骤

• 首先，终端的配色用的是这个哥们的（@_@) https://github.com/Anthony25/gnome-terminal-colors-solarized.git
  具体的安装方法，作者讲的非常清楚
  但是需要注意的
  • 最好新建一份profile,在新的profile 里面进行配色的安装（menu ->edit->profiles->new）
  • 我安装好了后，出现了一个诡异的问题，配色的效果达不到作者的截图，这就比较恼人了，想回退到用自己原来的配色方案，发现menu 栏不见了，想从命令行把他调出，google无果，其实鼠标右键就能调出meun ;接着解决问题，配色达不到理想，其实问题的原因是，原来的配色的配置（具体是透明度）发生了干扰，调整之后就好了，汗（差点放弃）
  • 效果是这样的
    
    还行，但不满意他的透明度，调整gnome-terminal 的透明度无效，原因应该是具体的配色源文件颜色数值的问题，以后折腾
• 隐藏user@hostname,方法是在.zshrc 中加入如下的一句

  1	export DEFAULT_USER=`whoami`

参考：

• https://blog.robotshell.org/2014/enable-256-color-in-gnome-terminal/

PS : 后续随时补充完善continue。。。

bash or zsh shortcuts

原来我不太喜欢终端环境，其中一个比较大的原因是：辛苦敲了一大串字，发现有错，老老实实的将手指挪动到方向键，左左右右，左右，右左-_-
google 找了，发现大量的 shortcuts ，又可以开心的在终端下，开心的玩耍了

罗列如下:

TCP/IP 网络编程 韩 [尹圣雨]

• tcp udp

  tcp 数据传输中，不存在边界，这表示： 数据传输过程中的I/O次数不具备任何意义
  相反，UDP 是具有数据边界的协议，传输中调用i/o 函数的次数非常重要,输入调用的次数和输出调用的次数完全一致

• udp 为啥 比 tcp快？ tcp传输的数据可靠 而 udp传输的数据不可靠 ？

优雅的断开套接字的连接

• shutdown(int fd,int howto)
  参数：
  SHUT_RD 断开输入流
  SHUT_WR 断开输出流
  SHUT_RDWR 同时断开输入输出流

• 为啥需要半关闭 ？
  这篇文章介绍了 close(fd) 和shutdown(fd,SHUT_RDWR)的区别

套接字I/O 方式

• read()/write() | send()/recv()

  read()/write() 对任何文件描述符 都可以进行I/O 操作
  send() /recv() 只能对套接字描述符操作
  send()/recv() 可以设置flag
  read()/write() 要对套接字进行flag 设置 ，得借助fcntl() 函数

• readv()/writev() | recvmsg()/sendmsg()

  都有多个 I/O缓冲区（用户空间）
  readv()/writev() 操作简单些

套接字 标准i/o 和系统i/o的性能比较

• 第一点 操作I/O的方式肯定不一样
  自己先总结下 套接字 I/O vs 标准 I/O

• 缓冲区对I/O性能的影响
  • 标准I/O 提供缓冲机制，减少了系统 I/O调用的次数,但是，为了将数据及时写入磁 盘，用户得手动调用fflush() 将数据写入磁盘,这就提供了一些隐患
  • 对于系统调用 应将数据缓冲区尽量定义为 磁盘扇区的整数倍（也不能太大，内存浪费）

I/O 分离

条件触发 边缘触发 优劣？

先看一个知乎讨论的链接
阿里陶辉的一篇文章

• 理论上 LT 慢于 ET 但是没有数据表明 这种差距 ，而且 ET 的控制 比 LT 麻烦
  • 早期并没有 LT的触发模式

开发网络应用，时常要自己去设计通讯的协议，原来自己被多种多样的协议的格式迷惑，理不清各种各样的协议的联系，查查资料，思考之后，还是理清了，如果，你也有类似的疑惑，你不妨看看

协议的区分的本质（或者说协议的区分的入口点）是在协议的编码的格式

• 文本流编码
• 二进制流编码
• 混合编码

仔细想想，这和文件类型区分的入口点，是一致的

文本流编码

常见的基于文本流编码的网络协议的编码有： XML JSON
这两种具体的语法的规范，不在累述，使用的场景还是非常多的，不只是在网络协议的，在应用的开发中，将文本文件，存储成这两种格式，还是极为普遍

文本流编码的一个不可忽视的的问题是：特殊字符的转义

二进制编码

其实这是网络协议的发展史上，先出现的编码的格式（考虑远古时代的 内存，网络带宽）

基于这种编码的格式，最常见的是 TLV编码（包括基于它的变体）
TLV:你可以理解成
TYPE + LENGTH + VALUE
TAG + LENGTH + VALUE
ID + LENGTH + VALUE

当ID唯一，length 字段就可以省略

成熟通用的二进制格式:

• Protobuf
• thrift　

基于这种编码的网络协议的特点

1. 解析效率高：主要是因为不需要转义字符
2. 编码长度低：主要是因为元数据占用的空间很少
3. 不易于实现：但是有很多开源的工具，根据IDL自动生成代码，提高开发效率
4. 兼容性高：协议双方可以独立升级
5. 可读性差：二进制协议，肉眼很难识别

混合型编码

Avro

没用过，不懂，先占坑，后续

参考链接：

• 通信协议之序列化
• 网络RPC编码协议学习
• 看协议设计的部分