图解HTTP（上野宣）学习笔记 - 第1章 了解Web及网络基础

第1章 了解Web及网络基础

1.1 使用HTTP协议访问Web

URL：Uniform Resource Locator，统一资源定位系统。URL是因特网的万维网服务程序上用于指定信息位置的表示方法。

根据Web浏览器地址栏中指定的URL，Web浏览器从Web服务器端获取文件资源（resource）等信息，从而显示出Web页面。

像这种通过发送请求获取服务器资源的Web浏览器等，都可称为客户端（client）。

HTTP：HyperText Transfer Protocol，超文本传输（转移）协议。

Web使用HTTP协议作为规范，完成从客户端到服务器端等一系列运作流程。可以说，Web是建立在HTTP协议上通信的。

1.2 HTTP的诞生

1989年3月，HTTP诞生了。

CERN（欧洲核子研究组织）的蒂姆·伯纳斯-李（Tim Berners Lee）博士提出的基本设想：借助多文档之间相互关联形成的超文本（HyperText），连成可相互参阅的WWW（World Wide Web，万维网）。

现在已提出了3项WWW构建技术，分别是：（1）把SGML（Standard Generalized Markup Language，标准通用标记语言）作为页面的文本标记语言的HTML（HyperText Markup Language，超文本标记语言）；（2）作为文档传递协议的HTTP；（3）指定文档所在地址的URL。

WWW这一名字，是Web浏览器当年用来浏览超文本的客户端应用程序时的名称。现在则用来表示这一系列的集合。

1990年11月，CERN成功研发出世界上第一台Web服务器和Web浏览器。两年后的1992年9月，日本第一个网站的主页上线。

HTTP正式作为标准被公布是在1996年5月，版本被命名为HTTP/1.0，并记载于RFC1945（http://www.ietf.org/rfc/rfc1945.txt）。虽是初期标准，但至今仍被广泛使用在服务器端。

1997年1月公布的HTTP/1.1是目前主流的HTTP协议版本。当初的标准是RFC2068，之后发布的修订版RFC2616就是当前的最新版本（http://www.ietf.org/rfc/rfc2616.txt）。

当年HTTP协议的出现主要是为了解决文本传输的难题。由于协议本身非常简单，于是在此基础上设想了很多应用方法并投入了实际使用。现在HTTP协议已超出了Web这个框架的局限，被运用到了各种场景里。

1.3网络基础TCP/IP

1.3.1 TCP/IP协议族

通常使用的网络（包括互联网）是在TCP/IP协议族的基础上运作的。而HTTP属于它内部的一个子集。

协议（protocol）：通信的规则被称为协议。包括电缆的规格、IP地址的选定方法、寻找异地用户的方法、双方建立通信的顺序、Web页面显示需要处理的步骤等等。

TCP/IP：把与互联网相关联的协议集合起来总称为TCP/IP。

1.3.2 TCP/IP的分层管理

TCP/IP协议族按层次分为4层：应用层、传输层、网络层数据链路层。

TCP/IP协议族层次化的好处：（1）便于改动：TCP/IP协议族层次化后，如果某个地方需要改变，只需要把变动的层替换掉即可。把各层之间的接口部分规划好后，每个层次内部的设计就能够自由改动了。（2）便于设计：处于应用层上的应用可以只考虑分派给自己的任务，而不需考虑诸如对方在地球上何处、对方的传输线路如何、是否能确保传输送达等问题。

（1）**应用层：决定了向用户提供应用服务时通信的活动。**TCP/IP协议族内预存了各类通用的应用服务，比如，FTP（File Transfer Protocol，文件传输协议），DNS（Domain Name System，域名系统），HTTP（HyperText Transfer Protocol，超文本传输协议）。

（2）**传输层：对上层的应用层提供处于网络连接中的两台计算机之间的数据传输。**在传输层有两个性质不同的协议：TCP（Transfer Control Protocol，传输控制协议），UDP（User Data Protocol，用户数据报协议）。

（3）网络层（网络互连层）：处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（传输路线）到达对方计算机，并把数据包传送给对方。在通过多台计算机或网络设备来与对方计算机进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线。

（4）**链路层（数据链路层/网络接口层）：处理连接网络的硬件部分。**包括控制操作系统、硬件的设备驱动、NIC（Network Interface Card，网络适配器，即网卡）、光纤等物理可见部分（还包括连接器等一切传输媒介）。硬件上的范畴均在链路层的作用范围之内。

1.3.3 TCP/IP通信传输流

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

以HTTP举例来说明，首先作为发送端的客户端在应用程（HTTP协议）发出一个想看某个Web页面的HTTP请求。接着，为了传输方便，在传输层（TCP协议）把从应用层处收到的数据（HTTP请求报文）进行分割，并在各个报文上打上标记序号及端口号后发给网络层。在网络层（IP协议），增加作为通信目的地的MAC地址后转发给链路层。这样，发送网络的通信请求就准备齐全了。接收端的服务器在链路层接收到数据，按序往上层发送，一直到应用层，当传输到应用层时，才算真正接收到客户端发送过来的HTTP请求。

发送端在层与层之间传输数据时，每经过一层时必定会被打上一个该层所属的首部信息。反之，接收端在层与层之间传输数据时，每经过一层时会把对应的首部消去。这种把数据信息包装起来的做法称为封装。

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

1.4.1 负责传输的IP协议

**IP（Internet Protocol）网际协议位于网络层。**TCP/IP协议族中的IP指的就是网际协议。

IP协议的作用：把各种数据包传送给对方。而要确保确实传输到对方那里则需要满足各类条件，其中最重要的条件是IP地址和MAC地址（Media Access Control Address）。

**IP地址：指明节点被分配到的地址。**IP地址可变换。

**MAC地址：指网卡所属的固定地址。**MAC地址基本上不会改变。

IP地址可以和MAC地址进行配对。

使用ARP协议凭借MAC地址进行通信：IP间的通信依赖MAC地址，在网络上，通信的双方在同一局域网（LAN）内的情况是很少的，通常是经过多台计算机和网络设备中转才能连接到对方，而在进行中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标，这时，会采用ARP协议（Address Resolution Protocol）。

ARP协议：是一种用以解析地址的协议，根据通信方的IP地址就可以反查出对应的MAC地址。

在到达通信目标的中转过程中，那些计算机和路由器等网络设备只能获悉很粗略的传输路线，这种机制称为路由选择（routing），无论哪台计算机或网络设备，都无法全面掌握互联网中的细节。

1.4.2 确保可靠性的TCP协议

TCP（Transfer Control Protocol，传输控制协议）位于传输层。

TCP提供可靠的字节流服务。

字节流服务（Byte Stream Service）：指为了方便传输，将大块数据分割成以报文段（segment）为单位的数据包进行管理。

可靠的传输服务是指，能够把数据准确可靠地传给对方。

TCP协议为了更容易传送大数据才把数据分割，而且TCP协议能够确认数据最终是否送达到对方。

**为了准确无误地将数据送达目标，TCP协议采用了三次握手（three-way handshaking）策略。**用TCP协议把数据包送出去后，TCP不会对传送后地情况置之不理，TCP一定会向对方确认是否成功送达。

”三次握手”：握手过程中使用了TCP的标志（flag）——SYN（synchronize）和ACK（acknowledgement）。发送端首先发送一个带SYN标志的数据包给对方，接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息，最后，发送端再回传一个带ACK标志的数据包，代表“握手”结束。

若在握手过程中，某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包。

除了上述的三次握手，TCP协议还有其他各种手段来保证通信的可靠性。

1.5 负责域名解析的DNS服务

DNS（Domain Name System，域名系统）服务是和HTTP协议一样位于应用层的协议。

**DNS提供域名到IP地址之间的解析服务。**DNS协议提供通过域名查找IP地址，或逆向从IP地址反查域名的服务。

计算机可以被赋予IP地址，也可以被赋予主机名和域名（比如www.baidu.com）。

用户通常使用主机名或域名来访问对方的计算机，而不是直接通过IP地址来访问。因为用字母+数字来指定计算机名，比用一组纯数字来表示的IP地址，更符合人类的记忆习惯。

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

1.7 URI和URL

URI（Uniform Resource Identifier，统一资源标识符）。

URL（Uniform Resource Locator，统一资源定位符）是使用Web浏览器等访问Web页面时需要输入的网页地址。

1.7.1 统一资源标识符URI

URI就是由某个协议方案表示的资源的定位标识符，协议方案是指访问资源所使用的协议类型名称，比如采用HTTP协议时，协议方案就是http，除此之外，协议方案还有ftp、mailto、telnet、file等。

URI用字符串标识某一互联网资源，而URL表示资源的地点（互联网上所处的位置）。可见URL是URI的子集。

1.7.2 URI格式

表示指定的URI，要使用涵盖全部必要信息的绝对URI、绝对URL以及相对URL。相对URL，是指从浏览器中基本URI处指定的URL，形如/image/logo.gif。

绝对URI的格式如下：http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch1，其中：

协议方案名（http:）：使用http或https等协议方案名获取访问资源时要指定协议类型，不区分大小写，最后附一个冒号（:）。也可使用data:或javascript:这类指定数据或脚本程序的方案名。

（可选项）登录信息（认证）（user:pass）：指定用户名和密码作为从服务器端获取资源时必要的登录信息（身份认证）。此项是可选项。

服务器地址（www.example.jp）：使用绝对URI必须指定待访问的服务器地址。地址可以是类似hackr.jp这种可解析的名称，或是192.168.1.1这类IPv4地址名，还可以是[0:0:0:0:0:0:0:1]这样用方括号括起来的IPv6地址名。

（可选项）服务器端口号（80）：指定服务器连接的网络端口号。此项是可选项，若用户省略，则自动使用默认端口号。

带层次的文件路径（dir/index.htm）：指定服务器上的文件路径，来定位特指的资源。这与UNIX系统的文件目录结构相似。

（可选项）查询字符串（uid=1）：针对已指定的（文件路径内的）资源，可以使用查询字符串传入任意参数。此项是可选项。

（可选项）片段标识符（ch1）：使用片段标识符通常可标记出已获取资源中的子资源（文档内的某个位置）。但在**RFC（Request for Comments，征求修正意见书）**中并没有明确规定其使用方法。此项是可选项。

有一些用来指定HTTP协议技术标准的文档，它们被称为RFC（Request for Comments，征求修正意见书）。通常，应用程序会遵照由RFC确定的标准实现，否则可能会导致无法进行HTTP协议通信的情况。比如有一台Web服务器内的应用服务没有遵照RFC的标准实现，那Web浏览器就很可能无法访问这台服务器了。当然，也存在某些应用程序因客户端或服务器的不同，而未按照RFC标准，反而将自成一套的“标准"扩展（其他的客户端或服务器端必然不得不配合它）的情况。