-
网络编程中的半包粘包问题
本文主要是讨论一下网络编程的基础，组包解包，以及常见的半包粘包。 在开发网络应用程序的话，特别是偏底层涉及具体的应用协议的时候，你可能会碰到服务端得到的数据不完全的问题。比如说客户端发送了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。即 Channel#read(ByteBuffer)或者ByteBuffer#put方法，往ByteBuffer里面写入数据 ByteBuffer#flip Channel#write(ByteBuffer)或者ByteBuffer#get方法，从ByteBuffer里面读取数据 ByteBuffer#clear, ByteBuffer#compact 读写模式通过不同的API来切换，一般情况下，按照上面这个顺序使用ByteBuffer就可以。不过要正确理解和使用ByteBuffer，需要对ByteBuffer的内部有所了解。 ByteBuffer主要有三个位置指针（不是C/C++的pointer） position，当前位置 limit，当前模式下的位置限制 capacity，分配时确定的空间大小 capacity因为一开始就被确定了，最容易理解。剩下两个位置指针需要配合ByteBuffer的“读写模式”来理解。 ByteBuffer被分配之后，默认是“写模式”，因为刚分配的空间你读取是没有意义的。这时position为0，limit为capacity的值。假设代码中执行了一些写入操作，每次写入都会增加position。 flip切换读写模式，position为0，即你写入的第一个byte的位置，limit变成你写入数据的最后一个byte后面的位置。 接下来你可以从ByteBuffer中读取数据了，每次读取增加position。 读取完毕之后，可以复用这个ByteBuffer，调用clear的话，position重置为0，limit设置为capacity，即回到写模式的初始状态。调用compact的话，你没有读取的数据会向前移动（System.arrayCopy），position设置为这些数据末尾之后的位置，limit设置为capacity。 用代码来测试一下
-
非阻塞IO与reactor模式
在写了非阻塞IO的基础知识之后，决定学习一下常规的非阻塞IO运行模式。 所谓运行模式，就是指以怎样的代码来实现非阻塞IO服务。为了比较和说明，先从阻塞IO的线程池化的服务器开始。 package in.xnnyygn.nio; import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; import java.net.ServerSocket; import java.net.Socket; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; public class BlockingIOEchoServer { private class EchoHandler implements Runnable { private final Socket socket; EchoHandler(Socket socket) { this.socket = socket; } @Override public void run() { System.out.println(“handle requests from ” + socket.getRemoteSocketAddress()); try { BufferedReader reader =…
-
非阻塞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的基本知识建议还是要了解一下。 参考： https://segmentfault.com/a/1190000003063859?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io#articleHeader12 http://blog.omega-prime.co.uk/?p=155 http://www.kegel.com/c10k.html
-
台場 2016-08-27
趁着台风来之前做点ingress任务，选择了台場。 查路线的时候鬼使神差地选了一个到现在为止我还读着拗口的「ゆりかもめ」电车，然后选择在「お台場海浜公園」下车。自然而然的我就开始做那个18个「お台場公園めぐり」连续任务了。 刚开始一两个我觉得还没什么，还觉得那两个不同颜色的缠在一起的管子挺好玩的。 任务一开始会往「お台場第三公園」方向走，那个公园人很少，从地图上看是一个正方向的公园，三面环海，中间有个盆地。
-
2016年8月25日
好久没有写博客了。但是VPS的钱还是要交，于是想着继续写点东西吧。 之前博客放置不写，有一个原因是没法升级到最新WP，今天查了下，感觉可能是服务器的防火墙的问题，增加了可以访问外部HTTPS网站之后就可以了。 小结就是iptables功力不够。 今天另外做的一件事情是换了主题，这样感觉就和以前不一样了。 暂时就这些。
-
记MHX村最后的三个任务
到今天为止（5.22），MHX最后三个村任务终于完成了……这三个任务分别是 金银火 两只金狮子 恐暴龙，轰龙加迅龙
-
8月24日随笔
时间一晃已经到了24日，距离辞职已经两周多了。这段时间除了处理事情之外就是休息了，现在记录一些这些天的小事。 口吃 在原公司头两年我是没口吃的，但是三四年的时候我发现自己在说话时会很高几率口吃。原因我大致知道，长时间工作没有和他人谈话。两点一线，在家也很少谈话。解决方法理论上很简单就是平时和别人多说话。不过造成这样情况不得不说原来小组的氛围太压抑，工作分配不合理等等。 现在几个星期后，感觉自己好多了，基本没有那种症状了，主要可以轻松休息，做自己喜欢的事情。这也算是这段时间的工作状态恢复吧。 twitter 月初对twitter很上心，因为好久没用了。不过最近发现时间线上的内容好没有营养，越是生活推越是有固定的圈子；而且年龄层次不同谈的内容感觉也不同，好多学生；在职的稍微好点，几个现实中就有接触的自然没什么问题，其他的感觉难谈拢。唉，还是当做信息窗口吧。
-
坐出租车和uber
昨天突发奇想去了一次西湖，路上高铁等按下不表，单就坐了两次uber写点对于杭州出租车的想法。 拒载，选择性载客是一种恶化打车环境的行为。从司机角度来说，碰到一个扬招的人，问了去处，太近不去，太远也不去，其中部分原因是觉得不实惠。比如堵车，堵车费也不高。还有原因是太远回来路上基本是空车。个人觉得从司机利益角度来说无可厚非，但是导致打车人等待时间变长，打车体验大幅降低。本来出租车作为公交的一种更加自由，但是现在看来司机也有自己的小算盘，不愿意完全为你做事。我觉得这个和出租车行业长期以来一种“垄断”性质，收入低，不明不白份子钱，运载力不足等等脱不了干系。期盼相关部门解决这个问题？不太可能，他们只向钱看齐。 解决行业痛点的一个是之前快的打车，滴滴打车之类的工具，问题的原因没法直接解决，但是通过提前告知去处，然后司机选择是否接单，这样就可以避免扬招时的尴尬。个人觉得是一个很好的通过协调打车人和司机之前的方案，间接提升了体验。但一个副作用就是扬招的人更难打到车了。另外在车比较少的地方仍旧很难打到车，去得比较远没有人不愿意接单也没办法，虽然比你连续扬招几辆被拒绝要好。其背后的一个问题还是出租车运能不足。个人觉得这其实还是行业的恶性循环造成的，包括准入机制，垄断性质，万恶的份子钱制度等等。 运能不足不能期待出租车行业整体反思，”人民拼车“其实是一个很好的切入点，通过大众的车辆来弥补这个不足，类似嘀嗒拼车，uber都是不错的工具。uber其实还更进了一步，不使用国内那种司机选单方式，而是自动调度，这里其实杜绝了选择性接单这种恶化体验的行为。从使用上来说，不管到哪里，让系统帮你选择接单一方面公平，另一方面也帮你选择了路线，降低了运营的难度，实在是对司机和搭车人都很不错的使用方法。 当然，这对于传统的出租车行业是一个很大的威胁，也看到过各种闹腾。对于搭车人来说，最重要的还是方便快捷。地铁站常看到出租车、黑车甚至还有摩托车，出租车拒载很常见，于是只能黑车，那些叫嚣打击非法营运车辆的人理由充分，然后呢维护的只是出租车的利益，难道半小时路程你让我走回去？现在太多这种只看表面不考虑真正解决的事情。 我其实也不会预计之后这个行业的发展，出租车现有的制度只会劣币驱逐良币，打车体验很一般甚至很差。专车虽然可能不专业，但是满足了很多人需求。撇开价格来说，两者可能会达到某种平衡，在不同层次各自覆盖。 最后说一句，我一直深信的出租车下午4点换班的说法，后来才知道只是大部分出租车司机不愿意做下午4点后堵车比较多的生意，于是昨天下午吃好晚饭后直接用uber，再也没考虑出租车。
-
写在暑假的第二天
今天是我的“暑假”的第二天，也是我在公司办理离职手续的日子。离职对很多人来说可能没什么大不了，但这次是我第一次下定决心的离职，从上午办理到下午差不多5点才到家里，做了很多也感触很多。 早上像太阳从西边出来一样碰到了组内的实习生。平时他比我至少早半个小时到公司，听他说因为昨天组内某人升职请客喝了很多酒，所以晚到了。昨天某人请客我是知道的，只是我休假没有去公司，其实也不想在离职前参加这种升职宴，会很尴尬。 实习生来自交大，是一个学生气很足，讲话有点口无遮拦的人。他坦言，我走了基本就没有年龄相仿了的。我想想也是，另外一个”近卫军“的同学这几周又要去参加什么培训了，还有一个差四五年的，剩下的都是隔了一圈年纪的”老人“了。我以前没注意过小组内年纪相差比较大的后果，现在看来代沟是很难逾越的，谈论的东西也不一样，和组内的人除了工作很少有交集。