注：本文是博主阅读《图解HTTP》写的读书笔记，将书中的个人认为的重要知识点提炼总结，并以问题形式作为小标题方便大家查看自己需要了解的知识点。
文章目录
- 了解Web及网路基础
- 1、Web使用的是什么协议？
- 2、HTTP的诞生日期？
- 3、WWW 构建技术
- 4、HTTP的发展
- 5、什么是TCP/IP 协议族？
- 6、TCP/IP 的分层管理
- 7、IP、TCP 和 DNS
- TCP协议三次握手（重要）
- 8、各种协议与HTTP协议的关系
- 9、URI 和 URL的区别
- 10、什么是RFC，所有程序都符合吗？
了解Web及网路基础
1、Web使用的是什么协议？
Web 使用一种名为 HTTP ( HyperText Transter Protocol，超文本传输协议）的协议作为规范，完成从客户端到服务器端等一系列运作流程。 而协议是指规则的约定。可以说，Web是建立在HTTP切议上通信的。
注：HTTP通带被译为超文本传输协议，但这种译法并不严谨。严谨的译名应该为”超文本转移协议”
2、HTTP的诞生日期？
1989年3月
3、WWW 构建技术
现在已提出了 3 项 WWW 构建技术，分别是：
- 把 SGML（Standard Generalized Markup Language，标准通用标记语言）作为页面的文本标记语言的 HTML（HyperText Markup Language，超文本标记语言）
- 作为文档传递协议的 HTTP
- 指定文档所在地址的 URL（Uniform Resource Locator，统一资源定位符）
4、HTTP的发展
HTTP/0.9
HTTP 于 1990 年问世。那时的 HTTP 并没有作为正式的标准被建立。现在的 HTTP 其实含有 HTTP1.0 之前版本的意思，因此被称为 HTTP/0.9。
HTTP/1.0
HTTP 正式作为标准被公布是在 1996 年的 5 月，版本被命名为HTTP/1.0，并记载于 RFC1945。虽说是初期标准，但该协议标准至今仍被广泛使用在服务器端。
HTTP/1.1
1997 年 1 月公布的 HTTP/1.1 是目前主流的 HTTP 协议版本。当初的标准是 RFC2068，之后发布的修订版 RFC2616 就是当前的最新版本。
可见，作为 Web 文档传输协议的 HTTP，它的版本几乎没有更新。新一代 HTTP/2.0 正在制订中，但要达到较高的使用覆盖率，仍需假以时日。
5、什么是TCP/IP 协议族？
计算机与网络设备要相互通信，双方就必须基于相同的方法。比如，如何探测到通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要事先确定。不同的硬件、操作系统之间的通信，所有的这一切都需要一种规则。而我们就把这种规则称为协议（protocol）。
像这样把与互联网相关联的协议集合起来总称为 TCP/IP。也有说法认为，TCP/IP 是指 TCP 和 IP 这两种协议。还有一种说法认为，TCP/IP 是在 IP 协议的通信过程中，使用到的协议族的统称。
6、TCP/IP 的分层管理
TCP/IP 协议族按层次分别分为以下 4 层：应用层、传输层、网络层和数据链路层。
应用层
应用层决定了向用户提供应用服务时通信的活动。
TCP/IP 协议族内预存了各类通用的应用服务。比如，**FTP（File Transfer Protocol，文件传输协议）**和 **DNS（Domain Name System，域名系统）**服务就是其中两类。
HTTP 协议也处于该层。
传输层
传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。
在传输层有两个性质不同的协议：TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Data Protocol，用户数据报协议）
网络层（又名网络互连层）
网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（所谓的传输路线）到达对方计算机，并把数据包传送给对方。与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线。
链路层（又名数据链路层，网络接口层）
用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC（Network Interface Card，网络适配器，即网卡），及光纤等物理可见部分（还包括连接器等一切传输媒介）。硬件上的范畴均在链路层的作用范围之内。
7、IP、TCP 和 DNS
IP协议
IP（Internet Protocol）网际协议位于网络层，IP 协议的作用是把各种数据包传送给对方。而要保证确实传送到对方那里，则需要满足各类条件。其中两个重要的条件是 IP 地址和 MAC地址（Media Access Control Address）
注：IP 地址指明了节点被分配到的地址，MAC 地址是指网卡所属的固定地址。IP 地址可以和 MAC 地址进行配对。IP 地址可变换，但 MAC地址基本上不会更改。
TCP协议
TCP 位于传输层，提供可靠的字节流服务。所谓的字节流服务（Byte Stream Service）是指，为了方便传输，将大块数据分割成以报文段（segment）为单位的数据包进行管理。而可靠的传输服务是指，能够把数据准确可靠地传给对方
TCP协议三次握手（重要）
为了准确无误地将数据送达目标处，TCP 协议采用了三次握手（three-way handshaking）策略。用 TCP 协议把数据包送出去后，TCP不会对传送后的情况置之不理，它一定会向对方确认是否成功送达。握手过程中使用了 TCP 的标志（flag）——SYN（synchronize）和 ACK（acknowledgement）
发送端首先发送一个带 SYN 标志的数据包给对方。接收端收到后，回传一个带有 SYN/ACK 标志的数据包以示传达确认信息。最后，发送端再回传一个带 ACK 标志的数据包，代表“握手”结束。若在握手过程中某个阶段莫名中断，TCP 协议会再次以相同的顺序发送相同的数据包
除了上述三次握手，TCP 协议还有其他各种手段来保证通信的可靠性。
DNS 服务
DNS（Domain Name System）服务是和 HTTP 协议一样位于应用层的协议。它提供域名到 IP 地址之间的解析服务。
计算机既可以被赋予 IP 地址，也可以被赋予主机名和域名。用户通常使用主机名或域名来访问对方的计算机，而不是直接通过IP 地址访问。
DNS诞生的原因：人更擅长记忆字母配合数字的计算机名，计算机更擅长处理一长串数字，所以才有了DNS，DNS 协议提供通过域名查找 IP 地址，或逆向从 IP 地址反查域名的服务
8、各种协议与HTTP协议的关系
9、URI 和 URL的区别
- URI（Uniform Resource Identifier，统一资源标识符）：由某个协议方案（协议类型名称，如http）表示的资源的定位标识符
- URL（Uniform Resource Locator，统一资源定位符）：简单理解URL就是Web网页地址
RFC2396 分别对这3 个单词进行了如下定义。
Uniform
规定统一的格式可方便处理多种不同类型的资源，而不用根据上下文环境来识别资源指定的访问方式。另外，加入新增的协议方案（如 http: 或 ftp:）也更容易。
Resource
资源的定义是“可标识的任何东西”。除了文档文件、图像或服务（例如当天的天气预报）等能够区别于其他类型的，全都可作为资源。另外，资源不仅可以是单一的，也可以是多数的集合体。
Identifier
表示可标识的对象。也称为标识符。
URI 用字符串标识某一互联网资源，而 URL 表示资源的地点（互联网上所处的位置）。URL 是 URI 的子集（URL < URI）
URI的格式
使用 http: 或 https: 等协议方案名获取访问资源时要指定协议类型。不区分字母大小写，最后附一个冒号（:）。也可使用 data: 或 javascript: 这类指定数据或脚本程序的方案名。
- 登录信息（认证）
指定用户名和密码作为从服务器端获取资源时必要的登录信息（身份认证）。此项是可选项。
- 服务器地址
使用绝对 URI 必须指定待访问的服务器地址。地址可以是类似hackr.jp 这种 DNS 可解析的名称，或是 192.168.1.1 这类 IPv4 地址名，还可以是 [0:0:0:0:0:0:0:1] 这样用方括号括起来的 IPv6 地址名。
- 服务器端口号
指定服务器连接的网络端口号。此项也是可选项，若用户省略则自动使用默认端口号。
- 带层次的文件路径
指定服务器上的文件路径来定位特指的资源。这与 UNIX 系统的文件目录结构相似。
- 查询字符串
针对已指定的文件路径内的资源，可以使用查询字符串传入任意参数。此项可选。
- 片段标识符
使用片段标识符通常可标记出已获取资源中的子资源（文档内的某个位置）。但在 RFC 中并没有明确规定其使用方法。该项也为可选项。
10、什么是RFC，所有程序都符合吗？
有一些用来制定HTTP协议技术标准的文档，它们被称为 RFC（Request for Comments，征求修正意见书）。并不是所有的应用程序都符合 RFC
由于不遵照 RFC 标准实现就无法进行 HTTP 协议通信，所以基本上客户端和服务器端都会以 RFC 为标准来实现 HTTP 协议。但也存在某些应用程序因客户端或服务器端的不同，而未遵照 RFC 标准，反而将自成一套的“标准”扩展的情况。不按 RFC 标准来实现，当然也不必劳心费力让自己的“标准”符合其他所有的客户端和服务器端。但设想一下，如果这款应用程序的使用者非常多，那会发生什么情况？不难想象，其他的客户端或服务器端必然都不得不去配合它
