参加 D2 2015 技术论坛感想

上周末去杭州阿里巴巴西溪园区参加了 2015 年的 D2 论坛,正好是第十届。

我听了一天的主会场,并在知乎上实时直播: 参加第十届D2前端技术论坛,你有什么收获? – yuanyuanVivian 的答案 。在这里谈谈自己的心得感想吧!

NodeJs 开始绽放

主会场的几场分享都还算挺不错。其中 NodeJS 相关的两场分享,一个是 Tmall 的线上经验,一个是 QZone 的线上经验,都是耳熟能详的大网站。我认为这代表 NodeJs 的线上能力已经得到了足够的验证,可以加快推广了继续阅读参加 D2 2015 技术论坛感想

《图解HTTP》读书笔记 – 第6章 HTTP 首部

本章学习 HTTP 首部的结构,以及首部中各字段的用法。

 

后记

这是最厚的一章了。HTTP 协议最有讲头的就是首部了。接下来五章的篇幅都比较短。

博客只发读书笔记显得人有点 low:只知道学习,不知道产出。每当想到这一点,博主就有点没有继续写笔记的动力了。但是,每当思考寻求解决方案时,第一反应还是会想起当初的笔记。所以,既然是自己挖的坑,哪怕很勉强,也还是要填完。

《CLEAN CODE》读书笔记(六)—— 错误处理

根据异常如何被捕获,将整个事件的错误处理统一代理起来是不错的方法,类似 httpFactory。(7.5 的例子是 Java 的,不太适合本项目)
如果异常打断了业务逻辑,那么,不要返回 null 值,返回 0 或者空数组可以省很多代码,可读性也更高(例子)。

(建议)每个异常应该有环境说明(AngularJs 已经做得很好了)

《CLEAN CODE》读书笔记(五)—— 对象和数据结构

The Law of Demeter 定律认为,模块不应了解它所操作对象的内部情形。
对象的内部结构应该隐藏而不暴露。而数据结构暴露数据,没有明显的行为。
(6.3 的例子:为什么非要暴露 cxt 内部的结构?为什么需要那么多知识来使用 cxt 对象?为了后面能创建指定名称的临时文件,那么直接让 cxt 来做这件事,如何?!)


这章真简洁

《CLEAN CODE》读书笔记(四)—— 代码格式

(非强制)短文件通常比长文件易于理解

向报纸学习:
1、名称简单一目了然;
2、顶部为最高层次的概念和算法;
3、细节往下渐次展开,知道最底层的函数和细节;
4、多数短小精悍,有些稍微长点儿,极少数占满一整页。

(建议)每个空白行都是一条线索,表示出新的独立概念。往下读代码时,目光总会停留于空白行之后那一行。(明显的例子)

(建议)紧密相关的代码相互靠近,暗示它们之间的紧密关系。(被注释分割的例子)

(建议)被调用的函数尽快出现在下面,这样就能轻易找到被调用的函数。

(建议)概念相关的代码同理要靠紧密一些。

缩进,这个没啥好说的。

《图解HTTP》读书笔记 – 第5章 与 HTTP 协作的 Web 服务器

一台 Web 服务器可搭建多个独立域名的 Web 网站,也可作为通信路径上的中转服务器提升传输效率。

搭建 Web 网站的服务器

HTTP/1.1 规范允许一台 HTTP 服务器搭建多个 Web 站点。访客通过 DNS 将域名解析成服务器 IP 地址,并访问该 IP 对应的服务器。这时,客户端发送 HTTP 请求会完整指出主机名或域名的 URI,服务器端就知晓具体要的是哪个网站。

同一台服务器建立多个 Web 网站
同一台服务器可能建立了多个 Web 网站,所以发 HTTP 请求必须准确指出域名或 IP 地址的 URI

代理

接收客户端的请求并转发给服务器,同时也接受服务器返回的响应并转发给客户端。

通过代理服务器转发请求或相应的示意图
通过代理服务器转发请求或相应的示意图

缓存代理

预先将资源的副本(缓存)保存在代理服务器上,下次同样请求就直接返回缓存的资源。

缓存服务器

缓存服务器是缓存代理的一种。优势在于利用缓存可以避免多次从源服务器转发资源。因此客户端可以就近从缓存服务器上获取资源,而源服务器也不必多次处理相同的请求。

缓存服务器示意图
缓存服务器示意图

缓存服务器判断缓存失效后,会再次从源服务器上获取新资源。
缓存服务器从源服务器更新过期的资源示意图
缓存服务器从源服务器更新过期的资源示意图

透明代理

转发请求或响应时,不做任何加工处理。

网关

转发其它服务器通信数据给客户端,但不再发客户端的请求转发给其它服务器端。

网关原理示意图
网关原理示意图

隧道

在相隔甚远的客户端和服务器两者之间进行中转,并保持双方通信连接。隧道不会解析 HTTP 请求,请求会保持原样中转给之后的服务器。隧道的目的是确保客户端与服务器进行安全的通信。

隧道示意图
隧道示意图

客户端缓存

缓存不仅可以存在于缓存服务器内,还可以存在客户端浏览器中(例如 Internet Explorer 的临时网络文件,Temporary Internet File)。
浏览器判断缓存过期后,会向服务器确认资源的有效性。若浏览器判断缓存失效,浏览器会再次请求新资源。

浏览器向服务器更新过期客户端缓存
浏览器向服务器更新过期客户端缓存

《图解HTTP》读书笔记 – 第4章 返回结果的 HTTP 状态码

状态码如 200 OK,以 3 位数字和原因短语组成。

数字中的第一位指定了响应类别,后两位数字无分类。响应类别有以下 5 种:

类别 原因短语
1XX Infomational (信息性状态码) 接收的请求正在处理
2XX Success (成功状态码) 请求正常处理完毕
3XX Redirection (重定向状态码) 需要进行附加操作以完成请求
4XX Client Error(客户端错误状态码) 服务器无法处理请求
5XX Server Error(服务器错误状态码) 服务器处理请求出错

最常用且最具代表性的 14 个状态码如下:

2XX 成功

  • 200 OK
  • 204 No Content
  • 206 Partial Content

200 表示从客户端发来的请求在服务器端被正常处理了。
204 一般在不需要对客户端发送新内容的情况下使用。表明服务器接受的请求已经成功处理,但返回的响应报文中不含实体的主体部分;
206 表示服务器成功执行了客户端发来的范围请求。响应报文中包含指定范围的实体内容。

3XX 重定向

  • 301 Moved Permanently
  • 302 Found
  • 303 See Other
  • 304 Not Modified
  • 307 Temporary Redirect

301 表示资源已经分配了新的 URI,以后都应该使用新的 URI。
302 表示资源已经分配了新的 URI,仅仅这次用新的 URI 访问。
303 和 302 一样,只是要求必须用 GET 方法访问新的 URI。
304 和重定向没有关系,也不返回实体,只是表明没有满足请求的附带条件。常见于浏览器判断缓存是否过期。
307 和 302 一样。302 标准禁止 POST 变成 GET,实际大家并不遵守。307 会遵守这个标准,但处理时每种浏览器的行为有所不同。

4XX 客户端错误

  • 400 Bad Request
  • 401 Unauthorized
  • 403 Forbidden
  • 404 Not Found

400 表示请求报文中有语法错误。
401 表示请求需要通过 HTTP 认证。若之前已经进行过一次请求,则表示用户认证失败。
403 表示请求的资源访问被服务器拒绝了。服务器不一定会给出拒绝的详细理由。
404 表示请求的资源不存在。也可以在服务器拒绝请求但不想说明理由的时候使用。

5XX 服务器错误

  • 500 Internal Server Error
  • 503 Service Unavailable

500 表示服务器在执行请求过程中发生了错误。
503 表示服务器暂时处于超负荷或者停机维护,暂时无法处理请求。

状态码和状况的不一致

有时候,不少返回的状态码响应都是错误的,但用户可能察觉不到这点。比如 Web 应用程序内部发生错误,状态码依然返回 200 OK,这种情况也经常遇到。

改变状态码

只要遵守状态码类别的定义,即使改变 RFC2616 中定义的状态码,或服务器自行创建状态码都没有问题。

《图解HTTP》读书笔记 – 第3章 HTTP报文内的 HTTP 信息

HTTP 报文的组成

HTTP 报文都分为首部、空行(回车符 + 换行符)和主体三部分。

HTTP 报文都由首部、空行和报文主体组成
HTTP 报文都由首部、空行(CR + LF)和报文主体组成

其中,HTTP 请求报文和 HTTP 响应报文只是报文首部不同。

请求报文(上)和响应报文(下)的结构
请求报文(上)和响应报文(下)的结构

HTTP 报文的实例

看一个 HTTP 报文的具体的实际例子,如下图:

起始行是方法(GET)、URI(/) 和协议版本(HTTP/1.1),这是 HTTP 首部必须的字段。
第二行开始是非必需的 HTTP 首部字段(Host、User-Agent 等)。
空一行以后,是 HTTP 请求的内容实体。HTTP 请求的内容实体也是非必需的(本例中就没有)。

HTTP 响应报文和 HTTP 请求报文的区别不大。HTTP 响应报文的起始行是服务器 HTTP 版本(HTTP/1.1)、状态码(200)和状态码原因(OK)的短语。第二行开始和 HTTP 请求报文一样,是非必需的首部和内容实体。

请求报文(上)和响应报文(下)的实例
请求报文(上)和响应报文(下)的实例

编码传输

HTTP 报文(message)一般和 HTTP实体(entity)是同一个东西。只有当传输过程中发生编码操作时,实体主体的内容发生变化,才导致它和报文主体产生差异。常用的内容编码有:

  • gzip (GNU zip)
  • compress (UNIX 系统的标准压缩)
  • deflate (zlib)
  • identity (不进行编码)

博主见得最多的是 gzip 和 identity 这两种编码。

分块传输

在 HTTP 通信过程中,请求的编码实体资源尚未全部传输完成之前,浏览器无法显示请求页面。在传输大容量数据时,通过把数据分割成多块,能够让浏览器逐步显示页面。

这种把实体主体分块的功能称为分块传输编码(Chunked Transfer Coding)。

范围请求

客户端也可以只请求实体的一部分内容,叫做范围请求(Range Request),如下图所示:

范围请求(Range Request)的例子。客户端用首字段 Range 来指定资源的 byte 范围。
范围请求(Range Request)的例子。客户端用首字段 Range 来指定资源的 byte 范围。

《图解HTTP》读书笔记 – 第2章 简单的 HTTP 协议

HTTP 规定,请求由客户端发出。

客户端发出请求报文,服务器发出响应报文,如下图:

HTTP 请求具体示例 - 客户端发出 HTTP 报文,服务器端也响应一份报文
HTTP 请求具体示例 – 客户端发出 HTTP 报文,服务器端也响应一份报文

HTTP 请求报文中,使用不同的方法(Method)可以用以告知服务器意图。例如 GET 是获取, PUT 是上传,DELETE 是删除,OPTIONS 是询问支持的方法, TRACE 是追踪路径等。具体可以看下图中的表格:

HTTP/1.0 和 HTTP/1.1 支持的方法HTTP/1.0 和 HTTP/1.1 支持的方法
HTTP/1.0 和 HTTP/1.1 支持的方法

HTTP 协议是不保存状态的协议,如下图所示:

HTTP 协议自身不具备保存之前发送过的请求或响应的功能
HTTP 协议自身不具备保存之前发送过的请求或响应的功能

HTTP 协议是不保存状态的协议,因此引入了 Cookie 技术。服务器端可以往客户端浏览器写 Cookie,客户端会自动在每次请求时都往服务器发这个 Cookie

最初的 HTTP 协议是每进行一次 HTTP 通信就要断开一次 TCP 连接。由于 TCP 协议的(三次握手等)保证可靠性的机制,很多时间浪费在连接和断开上了。

这个问题的解决方案是持久连接(HTTP Persistent Connections,也称为 HTTP keep-alive 或 HTTP connecttion reuse)的方法。其特点是,只要任意一端没有明确提出断开连接,则保持 TCP 连接状态。HTTP/1.1 中,所有的连接默认都是持久连接,但在 HTTP/1.0 内未标准化。现在的服务器端基本都是 HTTP/1.1 了。除了服务器端,客户端也需要支持持久连接。

持久连接还使得管线化(pipelining)方式发送成为可能。从前发送一个请求需等待并收到响应,才能发送下一个请求。管线化出现后,不用等待响应便可发送下一个请求。

还是上图说明持久连接和管线化,如下:

早期的HTTP协议中,每次都要断开TCP连接
早期的HTTP协议中,每次都要断开TCP连接
早期的HTTP协议中,每次都要断开TCP连接。增加通信量的开销。
早期的HTTP协议中,每次都要断开TCP连接。增加通信量的开销。
持久连接旨在建立1次TCP连接后进行多次请求和响应的交互
持久连接旨在建立1次TCP连接后进行多次请求和响应的交互
管线化连接不用等待响应,直接发送下一个请求。效率大大提升。
管线化连接不用等待响应,直接发送下一个请求。效率大大提升。

《图解HTTP》读书笔记 – 第1章 了解 Web 及网络基础

如图所示,每个 HTTP 传输都要依次经过应用层传输层网络层链路层、(传输目标的)链路层、(传输目标的)网络层、(传输目标的)传输层和(传输目标的)的应用层。HTTP 协议处于应用层。

TCP/IP通信传输流  - 发送端每到一层,会打上相应层的首部,而接收端每到一层,会去掉
TCP/IP通信传输流  – 发送端每到一层,会打上相应层的首部,而接收端每到一层,会去掉

如图,传输层(TCP 协议)将 HTTP 请求报文进行分割后转发给网络层(IP 协议),网络层加上目的地的 MAC 地址后转发给链路层(连接网络的硬件部分)。

最后,本章依次介绍了 TCP 协议(如下图)、DNS 服务 、 URI  和 URL。其中 TCP 协议提供可靠的字节流服务,会确保对方收到数据。

TCP 协议的三次握手 - 用以确认数据传输正确,会重试到完整地完成为止
TCP 协议的三次握手 – 用以确认数据传输正确,会重试到完整地完成为止