网络编程中的半包粘包问题

本文主要是讨论一下网络编程的基础,组包解包,以及常见的半包粘包。

在开发网络应用程序的话,特别是偏底层涉及具体的应用协议的时候,你可能会碰到服务端得到的数据不完全的问题。比如说客户端发送了1024个字符,但是你先得到了其中512字节,剩下的数据之后才送到。而已这通常发生在TCP协议下。理论上来说,TCP相对于另一种协议UDP,保证不会丢包,丢了也会重传,而且包的顺序是可预测的,但是对于传输的包大小没有约定。

一方面有类似nagle算法会把客户端的一些长度很短的包组合起来一次发送,另一方面因为以太网MTU等数据长度限制的存在,发到服务器的包有可能被分割成几个连续发送。前者可能会造成把逻辑上分离的包合在了一起,这通常称为粘包问题。后者可能会导致服务端处理包需要多次接收才能开始处理,这通常称为半包问题。

对于这两类问题,首先你要把TCP理解为面向流的协议,而不是包。其次你可以考虑怎么用处理文件的输入流的方式来处理网络的输入流。具体的,常见的解决方案:

  • 逻辑上定长,你可以不关心底层传输的包长度,一个逻辑上的完整包的长度
  • 使用特定分隔符分割,比如按行
  • 对于内容长度不定的数据,你可以采用先传包长度,然后传包内容
  • 应用层处理

(来自 http://www.cnblogs.com/sloong/p/5047743.html

其中,按行分割在普通文件读取中也有应用,库往往会开辟一个缓冲区,读入一定数据,找到行分隔符停止,这和网络编程中有点类似,不过网络编程的异常处理要更加小心,否则你会碰到帧(比如一行)过长等攻击。

Java NIO基础之ByteBuffer学习

Java NIO使用的数据结构不是普通的byte[],而是类似ByteBuffer的类。ByteBuffer使用起来与byte[]有很大不同,下面主要是自己学习到的一些使用方法。

ByteBuffer同时可以读写,一开始理解有点困难,建议按照推荐的操作步骤来使用ByteBuffer。即

  1. Channel#read(ByteBuffer)或者ByteBuffer#put方法,往ByteBuffer里面写入数据
  2. ByteBuffer#flip
  3. Channel#write(ByteBuffer)或者ByteBuffer#get方法,从ByteBuffer里面读取数据
  4. ByteBuffer#clear, ByteBuffer#compact

读写模式通过不同的API来切换,一般情况下,按照上面这个顺序使用ByteBuffer就可以。不过要正确理解和使用ByteBuffer,需要对ByteBuffer的内部有所了解。

ByteBuffer主要有三个位置指针(不是C/C++的pointer)

  • position,当前位置
  • limit,当前模式下的位置限制
  • capacity,分配时确定的空间大小

capacity因为一开始就被确定了,最容易理解。剩下两个位置指针需要配合ByteBuffer的“读写模式”来理解。

  1. ByteBuffer被分配之后,默认是“写模式”,因为刚分配的空间你读取是没有意义的。这时position为0,limit为capacity的值。假设代码中执行了一些写入操作,每次写入都会增加position。
  2. flip切换读写模式,position为0,即你写入的第一个byte的位置,limit变成你写入数据的最后一个byte后面的位置。
  3. 接下来你可以从ByteBuffer中读取数据了,每次读取增加position。
  4. 读取完毕之后,可以复用这个ByteBuffer,调用clear的话,position重置为0,limit设置为capacity,即回到写模式的初始状态。调用compact的话,你没有读取的数据会向前移动(System.arrayCopy),position设置为这些数据末尾之后的位置,limit设置为capacity。

用代码来测试一下

Read More

非阻塞IO与reactor模式

在写了非阻塞IO的基础知识之后,决定学习一下常规的非阻塞IO运行模式。

所谓运行模式,就是指以怎样的代码来实现非阻塞IO服务。为了比较和说明,先从阻塞IO的线程池化的服务器开始。

这是一个简单的Echo服务。ServerSocket在accept得到一个Socket之后,由线程池中的某个线程来处理这个Socket。

Read More

非阻塞IO与异步IO

本文是自己对最近学习到的IO相关知识的一点整理,之后会逐渐增加。

首先非阻塞IO(non-blocking IO)相信很多人都听说过,比如Nginx,Redis,NodeJS等等。得到的印象大多是非阻塞IO比传统IO(blocking IO)要好。这里多少有点误解。

非阻塞IO的目的是高并发,比如C10K这种目标。在连接数不高的时候性能并不会比传统IO好。为什么传统IO难以做到C10K,主要原因还是可以建立的进程/线程数量有限,以及高并发情况下IO等待时间太多,阻塞进程/线程运行等原因。

当然非阻塞IO并不是完全非阻塞的,IO通常分为数据等待和数据从内核空间拷贝到用户空间的两部分,传统IO(阻塞IO)在这两个步骤都会阻塞,但是非阻塞IO只在数据拷贝的时候阻塞,数据等待时系统通常会返回一个特定的异常码来提示数据未准备好。

非阻塞IO是一个行为特征,具体实现有select/poll,Linux 2.6之后的epoll等IO多路复用的系统调用。直观上来讲,非阻塞IO和IO多路复用没有关系,但是如果你一直在某个fd(文件描述符)上轮询的话,就会变得和传统IO没有区别,所以一般都是在多个fd上等待,当其中某个数据就绪了再取数据,这样就可以体现在非阻塞IO在数据等待这一步非阻塞的优势了。

从编程语言来说,非阻塞也可以选择用注册callback异步调用来实现。实际的IO类型中也有异步IO,但是大部分人都不怎么谈到异步IO,说非阻塞IO其实就是指epoll,其原因之一是Linux上AIO(异步IO)实现差强人意,Windows上IO多路复用只有select,剩下的就是异步IO,即IOCP,Windows貌似希望开发人员使用IOCP而不是开发类似epoll在Windows上的实现。服务器端开发,你懂的,Windows的用武之地很少。

IO多路复用为什么epoll脱颖而出,主要还是他的数据通知机制。select虽然大部分平台都支持,但是fd有数量限制,1024个。poll消除了这个限制,但是得到数据就绪的响应之后,你必须遍历庞大的fd列表来得到就绪的fd。epoll的优势在于返回的响应中包含数据就绪的fd,综合各方面来说是最优的。

当然epoll是Linux的系统调用,如果在Windows上你只能用select,在Solaris上你需要/dev/poll,OS X是kqueue,通常编程语言会帮你统一API,比如Java。但是关于非阻塞IO的基本知识建议还是要了解一下。

参考:

[DSL]模式匹配与请求跳转

具体上次撰写博客有一段时间了。这段时间内自己学些了很多,想了很多,尝试去理解了很多。结果之一是不管这个博客是为了什么而建立的,我还是把自己的技术思考记录下来。

本文描述是自己在工作中实现的一种DSL。DSL是个人今天年初左右才决定的发展方向,只是在具体工作中使用还是第一次。希望这可以作为自己在技术上选择性发展的一个好的开端。
由于是工作中开发出来的一种DSL,所以不会讲太具体的业务场景,而是以技术设计与实现为主。
本DSL的设计目的的核心如题,模式匹配和请求跳转。结合起来就是按照某种业务规则以模式匹配的方式决定请求是否跳转。更直接的一种表达方式是if else决定是否要redirect,只是这段if else是用DSL定义的。
使用DSL定义规则的好处在于更清晰地展现跳转的条件,避免技术实现给业务规则辨识带来的”噪音”,特别是复杂的跳转规则。其次是快速支持规则的变化,比如易变(不管是运行时易变,还是需求期易变)的规则,附带的另外一个好处是如果业务上需要动态定义的话,DSL可以快速支持,不再需要通过数据库设计,配置等传统方式。

Read More

[Java]运行时动态改变日志级别

其实这不是什么神奇的trick,只是很多人包括我在一直以来使用Java的日志框架比如log4j时没有意识到可以动态改变日志级别。如果你看到别人这么写了的话,很快就会转变观念的,我也是。

https://github.com/xnnyygn/dynamic-log-level 这个github是我整理的log4j动态改变日志级别的代码以及测试,有兴趣的可以参考下。

个人觉得这个trick可以用的地方还是程序员给自己开“后门”,特别是查线上问题时。由于很多人打印日志的级别的convention不一致。比如我喜欢非常详细的输入参数和输出结果用DEBUG,但是有些人就喜欢打INFO。一些复杂的逻辑有些人打了十几八行的INFO级别日志,看得我心烦,这帮人打INFO就像喝水一样……所以有些时候临时改变日志级别可能是有用的。不过从开发上来说,没有很好地统一日志级别规范,没有重视CR,是导致这个问题的主因,但是作为程序员要给自己留一手,比如动态改变日志级别之类的。

Read More

[Java]简单的延迟初始化实现

本篇文章本来打算在上个月下半旬写的,不过个人状态一直都不太好,最近重新开始调整自己的技术心态,慢慢恢复,这篇也算是恢复中的一小步吧。

延迟初始化是我在上个月公司的一个项目中加入的一个技术,感觉小组对这种东西不感兴趣,所以还是放到自己的博客上来了。技术背景是业务对象是一个非常大的对象(胖领域模型),每次加载非常耗时,而且因为部分非关键服务的不稳定导致不需要这些服务数据的功能不可用。举个例子,导航页不需要用户的B信息,但是每次加载用户信息由于是在服务层(是的,传统的分层结构)加载的,无法直接控制加载的内容,所以导致在B服务失败之后,导航页不可用。

从技术角度来说,领域模型完全是保证业务执行的必要条件,但是实际情况并不是所有场景都需要这么严格的领域模型完整性的保证的,所以类似“降级”的处理方式应由而生。具体来说就是“按需加载”。实现“按需加载”的方式不仅仅只有延迟初始化一种,通过服务的参数显示地控制加载的内容也是一种方式,不过存在侵入性和严格的规约,对开发来说并不是那么方便。其实“按需加载”不是只在特定业务场景才有的需求,在ORM上,加载关联数据也是一种典型的“按需加载”。所以亦可以参考ORM在“按需加载”方面的实现。

在讲我的简化版延迟初始化之前,先大致讲下Hibernate这个ORM在按需加载上的处理。Hibernate主要支持one-to-one和one-to-many下的按需加载,Hibernate 3开始支持部分字段的按需加载(CLOB和BLOB不算在内,3之前就有支持)。实现上,部分字段的加载需要bytecode替换,one-to-many是通过改写集合的处理,one-to-one是通过代理对象,具体来说是CGLIB,因为JDK动态代理对象只支持接口。

了解这些对于我的实现有所帮助,不过除了one-to-many很快就能模仿写之外,部分字段的延迟初始化和one-to-one的处理都比较麻烦。one-to-one在查到结果为null时会比较麻烦,从调用上看应该是代理整个领域模型而不是单个延迟加载的对象,这块个人没有细究,因为我后来想想我不需要非常严格的模型字段规约,小小地修改模型理论上也不会有太大问题。而且部分字段的延迟初始化不是类似单个延迟初始化对象就可以解决的。

Read More

scala99解题小结(List)

一个月之前,我把之前知道的scala99除了最后两题都做了下。总体来说自己用Scala来解决一些算法问题上有了一些感觉。

scala99的问题分为List,Arithmetic,Logic,Binary Tree,Multiway Tree,Graph和Misc。树和图和之后的问题和算法关系大一些。以下列一些影像比较深的题目。

本次先是List相关。

Read More