前言

由于最近一段时间在找实习,所以陆陆续续面试了几家公司,可结果都跪了….

总结失败的原因有很多,如果要进行个排名的话,网络一定能进前三。每每被面试官问到网络相关知识的时候,我都是一脸懵逼样,支支吾吾说不出个所以然。

现在想想,做移动端也有些日子了,可网络知识这块居然只知胜少,究其原因就是自己不求上进,直到找工作的时候被现实打脸了才恍然醒悟。于是,痛定思痛,决定恶补下网络知识,一番 Google 后,决定以《图解 HTTP》作为入门书籍。当然好记性不如烂笔头,读书笔记是少不了的。


第 1 章 了解 Web 及网络基础

1.1 使用 HTTP 协议访问 Web

1.1.1 从输入 URL 到页面加载完成的过程中都发生了什么事情?

  1. 在浏览器里输入网址
  2. 浏览器查找域名的 IP 地址
  3. 浏览器给 Web 服务器发送一个 HTTP 请求
  4. Facebook 服务的永久重定向响应
  5. 浏览器跟踪重定向地址
  6. 服务器「处理」请求
  7. 服务器发回一个 HTML 响应
  8. 浏览器开始显示HTML
  9. 浏览器发送获取嵌入在 HTML 中的对象
  10. 浏览器发送异步(AJAX)请求

详情参见:

1.2 HTTP 历史

1.2.1 HTTP 1.0 vs HTTP 1.1

  1. 可扩展性
  2. 缓存
  3. 带宽优化
  4. 长连接
  5. 消息传递
  6. Host 头域
  7. 错误提示
  8. 内容协商

详情参见:

1.2.2 HTTP 2.0

  1. 二进制分帧
  2. 首部压缩
  3. 多路复用
  4. 并行双向字节流的请求和响应
  5. 请求优先级
  6. 服务器推送

详情参见:

1.3 网络基础 TCP/IP

图:TCP/IP 是互联网相关的各类协议族的总称

1.3.1 TCP/IP 的分层管理

  • 应用层:决定了向用户提供应用服务时通信的活动

  • 传输层:对上层应用层,提供处于网络连接中的两台计算机之间的数据传输

  • 网络层(又名网络互连层):用来处理在网络上流动的数据包

  • 链路层(又名数据链路层,网络接口层):用来处理连接网络的硬件部分

1.3.2 TCP/IP 通信传输流

利用 TCP/IP 协议族进行网络通信时,会通过分层顺序与对方进行通信。发送端从应用层往下走,接收端则往应用层往上走。

发送端在层与层之间传输数据时,每经过一层时必定会被打上一个该层所属的首部信息。反之,接收端在层与层传输数据时,每经过一层时会把对应的首部消去。

1.4 与 HTTP 关系密切的协议:IP、TCP 和 DNS

1.4.1 负责传输的 IP 协议

在进行中转时,会利用下一站中转设备的 MAC 地址来搜索下一个中转目标。这时,会采用 ARP 协议(Address Resolution Protocol)。ARP 是一种用以解析地址的协议,根据通信方的 IP 地址就可以反查出对应的 MAC 地址。

1.4.2 确保可靠性的 TCP 协议

为了准确无误地将数据送达目标处,TCP 协议采用了三次握手(three-way handshaking)策略。

1.4.2.1 为何要三次握手
  1. 为了防止已失效的连接请求报文段(上一个 TCP 连接)突然又传送到了服务端,因而产生错误(服务端白白等待)

  2. 也可假设想场景:两个人打电话

1.4.2.2 为何要四次分手
  1. 保证 TCP 协议的全双工连接能够可靠关闭

  2. 保证这次连接的重复数据段从网络中消失

  3. TCP 连接是全双工的,这就意味着,当主机 1 发出 FIN 报文段时,只是表示主机 1 已经没有数据要发送了,但是,这个时候主机 1 还是可以接受来自主机 2 的数据;当主机 2 返回 ACK 报文段时,表示它已经知道主机 1 没有数据发送了,但是主机 2 还是可以发送数据到主机 1 的;当主机 2 也发送了 FIN 报文段时,这个时候就表示主机 2 也没有数据要发送了,就会告诉主机 1,我也没有数据要发送了,之后彼此就会愉快的中断这次 TCP 连接

详情参见:

1.4.2.3 为什么最后还要等待两个时间周期呢?

1.5 负责域名解析的 DNS 服务

DNS(Domain Name System)服务是和 HTTP 协议一样位于应用层的协议。它提供域名到 IP 地址之间的解析服务。

1.6 各种协议与 HTTP 协议的关系

1.7 URI 和 URL

URI 用字符串标识某一互联网资源,而 URL 表示资源的地点(互联网上所处的位置)。
URL 是 URI 的子集。
区别就是 URI 定义资源,而 URL 不单定义这个资源,还定义了如何找到这个资源(既访问资源的方式)。

详情参见:


第 2 章 简单的 HTTP 协议

2.1 HTTP 请求和响应报文格式

HTTP 请求报文由请求行、请求头部、空行和请求包体 4 个部分组成,如下图所示:

HTTP 响应报文由状态行、响应头部、空行和响应包体 4 个部分组成,如下图所示:

详情参见:

2.2 告知服务器意图的 HTTP 方法

表 2-1:HTTP/1.0 和 HTTP/1.1 支持的方法

方法 说明 支持的 HTTP 协议版本
GET 获取资源 1.0、1.1
POST 传输实体主体 1.0、1.1
PUT 传输文件 1.0、1.1
HEAD 获得报文首部 1.0、1.1
DELETE 删除文件 1.0、1.1
OPTIONS 询问支持的方法 1.1
TRACE 追踪路径 1.1
CONNECT 要求用隧道协议连接代理 1.1
LINK 建立和资源之间的联系 1.0
UNLINK 断开连接关系 1.0

第 3 章 HTTP 报文内的 HTTP 信息

3.1 编码提升传输速率

3.1.1 压缩传输的内容编码

内容编码指明应用在实体内容上的编码格式,并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。

常用的内容编码有以下几种:

  1. gzip(GNU zip)
  2. compress(UNIX 系统的标准压缩)
  3. deflate(zlib)
  4. identity(不进行编码)

3.1.2 分割发送的分块传输编码

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

3.2 获取部分内容的范围请求

执行范围请求时,会用到首部字段 Range 来指定资源的 byte 范围。

针对范围请求,响应会返回状态码为 206 Partial Content 的响应报文。另外,对于多重范围的范围请求,响应会在首部字段 Content-Type 标明 multipart/byteranges 后返回响应报文。