刨根问底HTTP和WebSocket协议(二)

HTTP vs WebSocket

上篇介绍了HTTP1.1协议的基本内容,这篇文章将继续分析WebSocket协议,然后对这两个进行简单的比较。

WebSocket

WebSocket协议还很年轻,RFC文档相比HTTP的发布时间也很短,它的诞生是为了创建一种「双向通信」的协议,来作为HTTP协议的一个替代者。那么首先看一下它和HTTP(或者HTTP的长连接)的区别。

为什么要用WebSocket来替代HTTP

上一篇中提到WebSocket的目的就是解决网络传输中的双向通信的问题,HTTP1.1默认使用持久连接(persistent connection),在一个TCP连接上也可以传输多个Request/Response消息对,但是HTTP的基本模型还是一个Request对应一个Response。这在双向通信(客户端要向服务器传送数据,同时服务器也需要实时的向客户端传送信息,一个聊天系统就是典型的双向通信)时一般会使用这样几种解决方案:

  1. 轮训,轮询就会造成对网络和通信双方的资源的浪费,且非实时。
  2. 长轮训,客户端发送一个超时时间很长的Request,服务器hold住这个连接,在有新数据到达时返回Response,相比#1,占用的网络带宽少了,其他类似。
  3. 长连接,其实有些人对长连接的概念是模糊不清的,我这里讲的其实是HTTP的长连接(1)。如果你使用Socket来建立TCP的长连接(2),那么,这个长连接(2)跟我们这里要讨论的WebSocket是一样的,实际上TCP长连接就是WebSocket的基础,但是如果是HTTP的长连接,本质上还是Request/Response消息对,仍然会造成资源的浪费、实时性不强等问题。

HTTP的长连接模型

KK笔记:kknotes.com
本文链接地址: 刨根问底HTTP和WebSocket协议(二)

转载须以超链接形式标明文章原始出处和作者信息及版权声明

Continue Reading

刨根问底HTTP和WebSocket协议

HTTP vs WebSocket

那天和boss聊天,不经意间提到了Meteor,然后聊到了WebSocket,然后就有了一下对话,不得不说,看问题的方式不同,看到的东西也会大不相同。
A:Meteor是一个很新的开发框架,我觉得它设计得十分巧妙。
B:怎么个巧妙之处?
A:它的前后端全部使用JS,做到了真正的前后端统一;前端浏览器里存有一份后台开放出来的数据库的拷贝,快;使用WebSocket协议来做数据传输协议,来同步前后端的数据库,实现了真正的实时同步。
B:哦?WebSocket是什么东西?真实时?那底层是不是还是轮训?和HTTP的长连接有什么不同?

KK笔记:kknotes.com
本文链接地址: 刨根问底HTTP和WebSocket协议

转载须以超链接形式标明文章原始出处和作者信息及版权声明

Continue Reading

如何设计良好的系统架构(clean code阅读笔记之十)

设计良好的系统

注:正文中的引用是直接引用作者的话,两条横线中间的段落的是我自己的观点,其他大约都可以算是笔记了。

本章讲的是「如何设计良好的系统架构」,读起来比较困难,不论是从结构上还是从文字上。结构上作者从「建设一个城市」开讲,之后花了很大的篇幅讲面向切面编程,最后又加上了几个方法论上的东西。文字上本章作者很多说法使用的单词和其他地方看到的的略有不同。但回过头来看,作者的思想是一脉相承的,整个章节其实只讲了一件事情——隔离。

本文会一直提到一个词「关注」,原文中使用的是concern,表达的是在软件开发中对某个问题的解决方案或者某个模块担任的职责(感觉还是不够贴切)。


本章有一个「结论」的小节,就先把她放上来了,内容在后边的小节里慢慢展开。

结论

  1. 系统整体架构的设计同样需要简洁优雅(作者此处指的是系统各个抽象层面之间要解耦),不然会带来各种各样的坏处;
  2. 在所有的抽象层面上,系统的目的要清晰(此处指的是单一职责,非侵入性)。为了达到这个目的,请使用AOP;
  3. 不论你是在设计一个系统,或者一个单独的模块,永远不要忘记使用最简单的实现

转载须以超链接形式标明文章原始出处和作者信息及版权声明

Continue Reading

iOS开发的那些坑(贰)

当时光流逝,记忆也开始散去,猛然回头却发现自己还在原地。

目前做iOS平台开发有两种语言,这就导致了一个项目组可能同时存在使用Swift和使用OC的开发者,这就导致了对于语言选择的分歧。此外我相信网上大部分的代码块还仍然是OC的,那么如果纯用Swift,有时候就需要把一整段的OC转换成Swift,而重复是邪恶了。同时用过Swift的都知道,OC的那种啰嗦的语法真的很烦人。

To be or not to be, that is the question.

在开发中,我们总是会遇到这样一种情况——我以前遇到过这个问题,可是我也不记得当时是怎么解决的,反正肯定有solution——然后又花了一定的时间去解决这个问题。有时候我们解决了一个问题(或者绕过了一个问题),但是并没有仔细去思考这个问题的由来与你真正的解决方法,这就会导致下次遇到它时还会跳进同一个坑。人不能两次踏入同一条河流,却总是不断地踏入同一个坑。

KK笔记:kknotes.com
本文链接地址: iOS开发的那些坑(贰)

转载须以超链接形式标明文章原始出处和作者信息及版权声明

Continue Reading