1、使用HTTP协议访问Web

你知道当我们在网页浏览器( Web browser)的地址栏中输入URL时，Web页面是如何呈现的吗?

Web页面当然不能凭空显示出来。根据Web浏览器地址栏中指定的URL，Web浏览器从 Web服务器端获取文件资源( resource)等信息，从而显示出 Web页面。

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

Web使用一种名为HTTP ( HyperText Transfer Protocol，超文本传输协议)的协议作为规范，完成从客户端到服务器端等一系列运作流程。而协议是指规则的约定。可以说，Web是建立在HTTP协议上通信的。

2、HTTP的诞生

在深入学习HTTP之前,我们先来介绍一下HTTP诞生的背景。了解背景的同时也能了解当初制定HTTP的初衷，这样有助于我们更好地理解。

2.1、为知识共享而规划Web

1989年3月，互联网还只属于少数人。在这一互联网的黎明期,HTTP诞生了。

（HTTP通常被译为超文本传输协议，但这种译法并不严谨。严谨的译名应该为“超文本转移协议”。但是前一译法已约定俗成，本书将会沿用。有兴趣的读者可参考图灵社区的相关讨论:http://www.ituring.com.cn/article/1817。）

CERN(欧洲核子研究组织）的蒂姆·伯纳斯-李( Tim Berners-Lee )博士提出了一种能让远隔两地的研究者们共享知识的设想。

最初设想的基本理念是:借助多文档之间相互关联形成的超文本( HyperText )，连成可相互参阅的www( World Wide Web，万维网)。

现在已提出了3项wwW构建技术，分别是:把 SGML ( StandardGeneralized Markup Language，标准通用标记语言）作为页面的文本标记语言的HTML ( HyperText Markup Language，超文本标记语言);作为文档传递协议的HTTP;指定文档所在地址的URL ( Uniform ResourceLocator，统一资源定位符)。

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

2.2、Web成长时代

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

日本第一个主页

http://www.ibarakiken.gr.jp/www/

1990年，大家针对HTML 1.0草案进行了讨论，因 HTML 1.0中存在多处模糊不清的部分，草案被直接废弃了。

1993年1月，现代浏览器的祖先NCSA ( National Center for SupercomputerApplications，美国国家超级计算机应用中心）研发的Mosaic问世了。它以in-line(内联）等形式显示HTML的图像，在图像方面出色的表现使它迅速在世界范围内流行开来。

同年秋天，Mosaic的 Windows版和 Macintosh版面世。使用CGI技术的NCSA Web服务器、NCSA HTTPd 1.0也差不多是在这个时期出现的。

NCSA Mosaic bounce page

http://archive.ncsa.illinois.edu/mosaic.html

The NCSA HTTPd Home Page(存档)

http://web.archive.org/web/20090426182129/http://hoohoo.ncsa.illinois.edul/（原址已失效)

1994年的12月，网景通信公司发布了Netscape Navigator 1.0,1995年微软公司发布 Internet Explorer 1.0和2.0。

紧随其后的是现在已然成为Web服务器标准之一的Apache，当时它以 Apache 0.2的姿态出现在世人眼前。而HTML也发布了2.0版本。那一年，Web技术的发展突飞猛进。

时光流转，从1995年左右起，微软公司与网景通信公司之间爆发的浏览器大战愈演愈烈。两家公司都各自对HTML做了扩展，于是导致在写HTML页面时，必须考虑兼容他们两家公司的浏览器。时至今日，这个问题仍令那些写前端页面的工程师感到棘手。

在这场浏览器供应商之间的竞争中，他们不仅对当时发展中的各种Web标准化视而不见，还屡次出现新增功能没有对应说明文档的情况。

2000年前后，这场浏览器战争随着网景通信公司的衰落而暂告一段落。但就在2004年，Mozilla基金会发布了Firefox浏览器，第二次浏览器大战随即爆发。

Internet Explorer浏览器的版本从6升到7前后花费了5年时间。之后接连不断地发布了8、9、10版本。另外，Chrome、Opera、Safari等浏览器也纷纷抢占市场份额。

2.3、驻足不前的HTTP

HTTP/0.9

HTTP于1990年问世。那时的 HTTP并没有作为正式的标准被建立。现在的HTTP其实含有HTTP1.0之前版本的意思，因此被称为HTTP/0.9.

HTTP/1.0

HTTP正式作为标准被公布是在1996年的5月，版本被命名为HTTP/1.0，并记载于RFC1945。虽说是初期标准，但该协议标准至今仍被广泛使用在服务器端。

RFC1945 - Hypertext Transfer Protocol -- HTTP/1.0

http://www.ietf.org/rfc/rfc1945.txt

HTTP/1.1

1997年1月公布的HTTP/1.1是目前主流的HTTP协议版本。当初的标准是RFC2068，之后发布的修订版RFC2616就是当前的最新版本。

RFC2616 - Hypertext Transfer Protocol -- HTTP/1.1

http://www.ietf.org/rfc/rfc2616.txt

可见，作为Web文档传输协议的HTTP，它的版本几乎没有更新。新一代HTTP/2.0正在制订中，但要达到较高的使用覆盖率，仍需假以时日。

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

3、网络基础 TCP/IP

为了理解HTTP，我们有必要事先了解一下 TCP/IP协议族。

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

接下来，我们仅介绍理解HTTP所需掌握的 TCP/IP协议族的概要。若想进一步学习有关TCP/IP的知识，请参考其他讲解 TCP/IP的专业书籍。

3.1、TCP/IP协议族

计算机与网络设备要相互通信，双方就必须基于相同的方法。比如，如何探测到通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要事先确定。不同的硬件、操作系统之间的通信，所有的这一切都需要一种规则。而我们就把这种规则称为协议( protocol )。

协议中存在各式各样的内容。从电缆的规格到I地址的选定方法、寻找异地用户的方法、双方建立通信的顺序,以及Web页面显示需要处理的步骤，等等。
像这样把与互联网相关联的协议集合起来总称为TCP/IP。也有说法认为，TCP/IP是指TCP和P这两种协议。还有一种说法认为，TCP/IP是在IP协议的通信过程中，使用到的协议族的统称。

3.2、TCP/IP的分层管理

TCP/IP协议族里重要的一点就是分层。TCP/IP协议族按层次分别分为以下4层:应用层、传输层、网络层和数据链路层。
把 TCP/IP层次化是有好处的。比如，如果互联网只由一个协议统筹，某个地方需要改变设计时，就必须把所有部分整体替换掉。而分层之后只需把变动的层替换掉即可。把各层之间的接口部分规划好之后，每个层次内部的设计就能够自由改动了。
   值得一提的是，层次化之后，设计也变得相对简单了。处于应用层上的应用可以只考虑分派给自己的任务，而不需要弄清对方在地球上哪个地方、对方的传输路线是怎样的、是否能确保传输送达等问题。
   TCP/IP协议族各层的作用如下。
应用层
   应用层决定了向用户提供应用服务时通信的活动。
   TCP/IP协议族内预存了各类通用的应用服务。比如，FTP ( FileTransfer Protocol，文件传输协议）和 DNS ( Domain Name System,域名系统）服务就是其中两类。
HTTP协议也处于该层。
传输层
传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。
在传输层有两个性质不同的协议:TCP ( Transmission ControlProtocol，传输控制协议）和UDP ( User Data Protocol，用户数据报协议)。

网络层（又名网络互连层）
   网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（所谓的传输路线)到达对方计算机，并把数据包传送给对方。
与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线。
链路层（又名数据链路层，网络接口层）
   用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC ( Network Interface Card，网络适配器，即网卡)，及光纤等物理可见部分（还包括连接器等一切传输媒介)。硬件上的范畴均在链路层的作用范围之内。

3.3、TCP/IP通信传输流

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

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

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

下面我们分别针对在TCP/P协议族中与HTTP密不可分的3个协议( IP、TCP和 DNS)进行说明。

4.1、负责传输的IP协议

按层次分，IP ( Internet Protocol ）网际协议位于网络层。InternetProtocol这个名称可能听起来有点夸张，但事实正是如此，因为几乎所有使用网络的系统都会用到IP协议。TCP/IP协议族中的P指的就是网际协议，协议名称中占据了一半位置，其重要性可见一斑。可能有人会把“IP”和“IP地址”搞混,“IP”其实是一种协议的名称。
IP协议的作用是把各种数据包传送给对方。而要保证确实传送到对方那里，则需要满足各类条件。其中两个重要的条件是IP地址和 MAC地址( Media Access Control Address )。
IP地址指明了节点被分配到的地址，MAC地址是指网卡所属的固定地址。IP地址可以和 MAC地址进行配对。IP地址可变换，但MAC地址基本上不会更改。
使用ARP协议凭借MAC地址进行通信
IP间的通信依赖MAC地址。在网络上，通信的双方在同一局域网( LAN)内的情况是很少的，通常是经过多台计算机和网络设备中转才能连接到对方。而在进行中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标。这时，会采用ARP协议(Address ResolutionProtocol )。ARP是一种用以解析地址的协议，根据通信方的IP地址就可以反查出对应的MAC地址。
没有人能够全面掌握互联网中的传输状况
在到达通信目标前的中转过程中，那些计算机和路由器等网络设备只能获悉很粗略的传输路线。
这种机制称为路由选择( routing )，有点像快递公司的送货过程。想要寄快递的人，只要将自己的货物送到集散中心，就可以知道快递公司是否肯收件发货，该快递公司的集散中心检查货物的送达地址，明确下站该送往哪个区域的集散中心。接着，那个区域的集散中心自会判断是否能送到对方的家中。
我们是想通过这个比喻说明，无论哪台计算机、哪台网络设备，它们都无法全面掌握互联网中的细节。

4.2、确保可靠性的TCP协议

按层次分，TCP位于传输层，提供可靠的字节流服务。
所谓的字节流服务( Byte Stream Service）是指,为了方便传输，将大块数据分割成以报文段（ segment）为单位的数据包进行管理。而可靠的传输服务是指,能够把数据准确可靠地传给对方。一言以蔽之，TCP协议为了更容易传送大数据才把数据分割,而且 TCP协议能够确认数据最终是否送达到对方。

确保数据能到达目标
为了准确无误地将数据送达目标处，TCP协议采用了三次握手( three-way handshaking）策略。用TCP协议把数据包送出去后，TCP不会对传送后的情况置之不理，它一定会向对方确认是否成功送达。握手过程中使用了TCP的标志( flag ) ——SYN ( synchronize)和ACK( acknowledgement)。
发送端首先发送一个带SYN标志的数据包给对方。接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息。最后，发送端再回传一个带ACK标志的数据包，代表“握手”结束。
若在握手过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包。

5、负责域名解析的DNS 服务

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

计算机既可以被赋予IP地址，也可以被赋予主机名和域名。比如www.hackr.jp。
用户通常使用主机名或域名来访问对方的计算机，而不是直接通过IP地址访问。因为与IP地址的一组纯数字相比，用字母配合数字的表示形式来指定计算机名更符合人类的记忆习惯。
但要让计算机去理解名称，相对而言就变得困难了。因为计算机更擅长处理一长串数字。
为了解决上述的问题，DNS服务应运而生。DNS协议提供通过域名查找IP地址，或逆向从P地址反查域名的服务。

6、各种协议与HTTP协议的关系

学习了和 HTTP协议密不可分的TCP/IP协议族中的各种协议后,我们再通过这张图来了解下IP协议、TCP协议和 DNS服务在使用HTTP协议的通信过程中各自发挥了哪些作用。

7、URI和 URL

与URI(统―资源标识符）相比，我们更熟悉URL ( UniformResource Locator，统一资源定位符)。URL正是使用Web浏览器等访问Web页面时需要输入的网页地址。比如，下图的 http:/hackr.jp/就是URL。

7.1、统一资源标识符

URI是Uniform Resource Identifier 的缩写。RFC2396分别对这3个单词进行了如下定义。

Uniform
规定统一的格式可方便处理多种不同类型的资源，而不用根据上下文环境来识别资源指定的访问方式。另外，加入新增的协议方案(如http:或ftp:)也更容易。

Resource
资源的定义是“可标识的任何东西”。除了文档文件、图像或服务(例如当天的天气预报）等能够区别于其他类型的，全都可作为资源。另外，资源不仅可以是单一的，也可以是多数的集合体。

ldentifier
表示可标识的对象。也称为标识符。

综上所述，URI就是由某个协议方案表示的资源的定位标识符。协议方案是指访问资源所使用的协议类型名称。
采用HTTP协议时，协议方案就是http。除此之外，还有ftp、mailto、telnet、file等。标准的URI协议方案有30种左右，由隶属于国际互联网资源管理的非营利社团ICANN ( Internet Corporation for AssignedNames and Numbers，互联网名称与数字地址分配机构）的IANA( Internet Assigned Numbers Authority，互联网号码分配局）管理颁布。

IANA - Uniform Resource ldentifier (URI)SCHEMES(统一资源标识符方案）

http://www.iana.org/assignments/uri-schemes

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

“RFC3986:统一资源标识符( URI )通用语法”中列举了几种URI例子，如下所示。

本书接下来的章节中会频繁出现URI这个术语，在充分理解的基础上，也可用URL替换URI。

7.2、URI格式

表示指定的 URI，要使用涵盖全部必要信息的绝对URI、绝对URL以及相对URL。相对URL，是指从浏览器中基本URI处指定的URL,形如/image/logo.gif。
让我们先来了解一下绝对URI的格式。

使用http:或https:等协议方案名获取访问资源时要指定协议类型。不区分字母大小写，最后附一个冒号（∶)。

也可使用data:或javascript:这类指定数据或脚本程序的方案名。

登录信息（认证)
指定用户名和密码作为从服务器端获取资源时必要的登录信息（身份认证)。此项是可选项。
服务器地址
使用绝对URI必须指定待访问的服务器地址。地址可以是类似hackr.jp这种DNS可解析的名称,或是192.168.1.1这类IPv4地址名，还可以是[O:0:0:O:0:0:0:1]这样用方括号括起来的IPv6地址名。

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

带层次的文件路径
指定服务器上的文件路径来定位特指的资源。这与UNIX系统的文件目录结构相似。

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

片段标识符
使用片段标识符通常可标记出已获取资源中的子资源（文档内的某个位置)。但在RFC中并没有明确规定其使用方法。该项也为可选项。

并不是所有的应用程序都符合RFC

有一些用来制定HTTP协议技术标准的文档,它们被称为RFC( Request for Comments,征求修正意见书。

通常，应用程序会遵照由 RFC 确定的标准实现。可以说,RFC是互联网的设计文档,要是不按照 RFC标准执行,就有可能导致无法通信的状况。比如,有一台Web服务器内的应用服务没有遵照 RFC的标准实现,那 Web浏览器就很可能无法访问这台服务器了。

由于不遵照 RFC标准实现就无法进行HTTP协议通信，所以基本上客户端和服务器端都会以 RFC为标准来实现HTTP 协议。但也存在某些应用程序因客户端或服务器端的不同,而未遵照RFC标准，反而将自成一套的“标准”扩展的情况。

不按 RFC标准来实现,当然也不必劳心费力让自己的“标准”符合其他所有的客户端和服务器端。但设想一下，如果这款应用程序的使用者非常多,那会发生什么情况?不难想象，其他的客户端或服务器端必然都不得不去配合它。

实际在互联网上，已经实现了HTTP 协议的一些服务器端和客户端里就存在上述情况。说不定它们会与本书介绍的HTTP 协议的实现情况不一样。
接下来要介绍的 HTTP 协议内容,除去部分例外，基本上都以RFC的标准为准。

以上内容来源于图解http