1. 使用HTTP协议访问Web
你知道当我们在网页浏览器(Web brower)的地址栏中输入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诞生了。
CERN(欧洲核子研究组织)的蒂姆伯纳斯-李博士提出了一种能让远隔两地的研究者们共享知识的设想。
最初设想的基本理念是：借助多文档之间相互关联形成的超文本(HyperText)，连城可相互参阅的WWW(World Wide Web，万维网)。
现在已经提出了3项WWW构建技术，分别是：把SGML(Standard Generalized Markup Language，标准通用标记语言)作为页面的文本标记语言的HTML(HtperText Markup Language，超文本标记语言)；作为文档传递协议的HTTP；指定文档所在地址的URL(Uniform Resource Locator，统一资源定位符)。
WWW这一名称，是Web浏览器当年用来浏览超文本的客户端应用程序时的名称。
现在则用来表示这一系列的集合，也可简称为Web。
2.2 Web成长时代
1990年，大家针对HTML1.0草案进行了讨论，因HTML1.0中存在多处模糊不清的部分，草案被直接废弃了。
HTML 1.0
http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
1993年1月，现代浏览器的祖先NCSA(National Center for Supercomputer Applications，美国国家超级计算机应用中心)研发的Mosaic问世了。
它以in-line(内联)等形式显示HTML的图像，在图像方面出色的表现使它迅速在世界范围内流行开来。
同年秋天，Mosaic的Windows版和Macintosh版面世。
使用CGI技术的NCSA Web服务器、NCSA HTTPd 1.0也差不多是在这个时期出现的。
- NCSA Mosaic bounce page
- The NCSA HTTPd Home Page(存档)
1994年的12月，网景通信公司发布了Netscape Navigator 1.0 ，1995年微软公司发布 Internet Explorer 1.0和 2.0
紧随其后的是现在已然成为Web服务器标准之一的Apache，当时它以Apache0.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其实含有HTTP/1.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。
当年HTTP协议的出现主要是为了解决文本传输的难题。
由于协议本身非常简单，于是在此基础上设想了很多应用方法并投入了实际使用。
现在HTTP协议已经超出了Web这个框架的局限，被运用到了各种场景里。
3. 网络基础TCP/IP
为了理解HTTP，我们有必要先了解一下TCP/IP协议族。
通常使用的网络(包括互联网)是在TCP/IP协议族的基础上运作的。
而HTTP属于它内部的一个子集。
3.1 TCP/IP协议族
计算机与网络设备要相互通信，双方就必须基于相同的方法。比如，如何探测到通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要事先确定。
不同的硬件、操作系统之间的通信，所有的这一切都需要一种规则。
而我们就把这种规则称为协议(protocol)。
协议中存在各式各样的内容。
从电缆的规格到IP地址的选定方法、寻找异地用户的方法、双方建立通信的顺序，以及Web页面显示需要处理的步骤，等等。
像这样把与互联网相关联的协议集合起来总称为TCP/IP。
也由说法认为，TCP/IP是指TCP和IP两种协议。
还有一种说法认为，TCP/IP是在IP协议的通信过程中，使用到的协议族的统称。
3.2 TCP/IP的分层管理
TCP/IP协议族里重要的一点就是分层。
TCP/IP协议族按层次分别分为以下4层：应用层、传输层、网络层和数据链路层。
把TCP/IP层次化是有好处的。
比如，如果互联网只由一个协议统筹，某个地方需要改变设计时，就必须把所有部分整体替换掉。
而分层之后只需把变动的层替换掉即可。
把各层之间的接口部分规划好之后，每个层次内部的设计就能自由改动了。
值得一提的是，层次化之后，设计也变得相对简单了。
处于应用层上的应用可以只考虑分派给自己的任务，而不需要弄清对方在地球上哪个地方、对方的传输路线是怎样的、是否能确保传输送达等问题。
TCP/IP协议族各层的作用如下：
应用层
应用层决定了向用户提供应用服务时通信的活动。
TCP/IP协议族内预存了各类通用的应用服务。
比如，FTP(File Transfer Protocol，文件传输协议)和DNS(Domain Names System，域名系统)服务就是其中两类。
HTTP协议也处于该层。
传输层
传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。
在传输层有两个性质不同的协议：TCP(Transmission Control Protocol，传输控制协议)和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/IP协议族中与HTTP密不可分的3个协议(IP、TCP和DNS)进行说明
4.1 负责传输的IP协议
按层次分，IP(Internet Protocol)网际协议位于网络层。
Internet Protocol 这个名称可能听起来有点夸张，但事实正是如此，因为几乎所有使用网络的系统都会用到IP协议。
TCP/IP协议族中的IP指的就是网际协议，协议名称中占据了一半位置，其重要性可见一斑。
可能有人会把”IP”和”IP地址”搞混，”IP”其实一种协议的名称。
IP协议的作用是把各种数据包传送给对方。
而要保证确实传送到对方那里，则需要满足各类条件。
其中两个重要的条件是IP地址和MAC地址(Media Access Control Address)
IP地址指明了节点被分配到的地址，MAC地址是指网卡所属的固定地址。
IP地址可以和MAC地址进行配对。
IP地址可变换，但MAC地址基本上不会更改。
使用ARP协议凭借MAC地址进行通信
IP间的通信依赖MAC地址。
在网络上，通信的双方在同一局域网(LAN)内的情况是很少的，通常是经过多台计算机和网络设备中转才能连接到对方。
而在进行中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标。
这时，会采用ARP协议(Address Resolution Protocol)。
ARP是一种用以解析地址的协议，根据通信方的IP地址就可以反查出对应的MAC地址。
没有人能够全面掌握互联网中的传输状况
在到达通信目标前的中转过程中，那些计算机和路由器等网络设备只能获悉很粗略的传输路线。
这种机制称为路由选择(routing)，有点像快递公司的送货过程。
想要寄快递的人，只要将自己的货物送到集散中心，就可以知道快递公司是否肯收件发货，该快递公司的集散中心检查货物的送达地址，明确下站该送往哪个区域的集散中心。
接着，那个区域的集散中心自会判断是否能送到对方的家中。
我们是想通过这个比喻说明，无论哪台计算机，哪台网络设备，它都无法全面掌握互联网中的细节。
4.2 确保可靠性的TCP协议
按层次分，TCP位于传输层，提供可靠的字节流服务。
所谓的字节流服务(Byte Steam Service)是指，为了方便传输，将大块数据分割成以报文段(segment)为单位的数据包进行管理。
而可靠的传输服务是指，能够把数据准确可靠地传给对方。
一言以蔽之，TCP协议为了更容易传送大数据才把数据分割，而且TCP协议能够确认数据最终是否送达到对方。
确保数据能到达目标
为了准确无误地将数据送达目标处，TCP协议采用了三次握手(three-way handshaking)策略。
用TCP协议把数据包送出去后，TCP不会对传送后的情况置之不理，它一定会向对方确实是否成功送达。
握手过程中使用TCP的标志(flag) —SYN(synchronize)和ACK(acknowledgement)
发送端首先发送一个带SYN标志的数据包给对方。
接收端收到后，回传一个带有SYN/ACK标志的数据包，代表”握手”结束
若在握手过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包。
除了上述三次握手，TCP协议还有其他各种手段来保证通信的可靠性。
5. 负责域名解析的DNS服务
DNS(Domain Name System) 服务是和HTTP协议一样位于应用层的协议。
它提供域名到IP地址之间的解析服务。
计算机既可以被赋予IP地址，也可以被赋予主机名和域名。
比如www.hackr.jp。
用户通常使用主机名或域名来访问对方的计算机，而不是直接通过IP地址来访问。
因为与IP地址的一组纯数字相比，用字母配合数字的表示形式来指定计算机名更符合人类的记忆习惯。
但要让计算机去理解名称，相对而言就变得困难了。
因为计算机更擅长处理一长串数字。
为了解决上述的问题，DNS服务应运而生。
DNS协议提供通过域名查找IP地址，或逆向从IP地址反查域名的服务。
6. 各种协议与HTTP协议的关系
学习了和HTTP协议密不可分的TCP/IP协议族中的各种协议后，我们再通过这张图来了解下IP协议、TCP协议和DNS服务在使用HTTP协议的通信过程各自发挥了哪些作用。
7. URI和URL
与URI(统一资源标识符)相比，我们更熟悉URL(Uniform Resource Locator，统一资源定位符)。
URL正是使用Web浏览器等访问Web页面时需要输入的网页地址。
比如，ichistudio.cn就是URL
7.1 统一资源标识符
URI 是Uniform Resource Identifier的缩写。
RFC2396分别对这三个单词进行了如下定义。
Uniform
规定统一的格式可方便处理多种不同类型的资源，而不用根据上下文环境来识别资源指定的访问方式。
另外，加入新增的协议方案(如http:或ftp:)也更容易。
Resource
资源的定义是”可标识的任何东西”。不仅是文档文件，图像或服务(例如当天的天气预报)等能够区别于其他类型的，全都可作为资源。
另外，资源不仅可以是单一的，也可以是多数的集合体。
Identifier
表示可识别的对象。也称为标识符。
综上所述，URI就是由某个协议方案表示的资源和定位标识符。
协议方案是指访问资源所使用的协议类型名称。
采用HTTP协议时，协议方案就是http。
除此之外，还有ftp、mailto、telnet、file等。
标准的URI协议方案有30种左右，由隶属于国际互联网资源管理的非营利社团ICANN(Internet Corporation for Assigned Names and Numbers，互联网名称与数字地址分配机构)的IANA(Internet Assigned Numbers Authority，互联网号码分配局)管理颁发。
- IANA-Uniform Resource Identifier(URI)SCHEMES(统一资源标识符方案)
http://www.iana.org/assignments/uri-schemes
URI用字符串标识某一互联网资源，而URL表示资源的地点(互联网上所处的位置)。可见URL是URI的子集。
“RFC3986：统一资源标识符(URI)通用语法”中列举了几种URI例子，如下所示。
ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
ldap://[2001:db8::7]c=GB?objectClass?one
mailto:John.Doe@example.com
news:comp.infosystems.www.servers.unix
tel:+1-816-555-1212
telnet://192.0.2.16:50/
urn:oasis:names:specification:docbook:dtd:xml:4.1.27.2 URI格式
表示指定的URI，要使用涵盖全部必要信息的绝对URI、绝对URL以及相对URL。
相对URL，是指从浏览器中基本URI处指定的URL，形如/image/logo.gif。
让我们先来了解一下绝对URI的格式。
使用http:或https:等协议方案名获取访问资源时要指定协议类型。
不区分字母大小写，最后附一个冒号(:)。
也可以使用data:或javascript：这类指定数据或脚本程序的方案名。
登录信息(认证)
指定用户名和密码作为从服务器端获取资源时必要的登录信息(身份认证)。此项是可选项。
服务器地址
使用绝对URI必须指定待访问的服务器地址。
地址可以是类似ichi.cn这种DNS可解析的名称，或是192.168.1.1这类IPv4地址名，还可以是[0:0:0:0:0:0:0:1]这样用方括号括起来的IPv6地址名。
服务器端口号
指定服务器连接的网络端口号。此项也是可选项，若用户省略则自动使用默认端口号。
带层次的文件路径
指定服务器上的文件路径来定位特指的资源。这与UNIX系统的文件目录结构相似。
查询字符串
针对已指定的文件路径内的资源，可以使用查询字符串传入任意参数。此项可选。
片段标识符
使用片段标识符通常可标记出已获取资源中的子资源(文档内的某个位置)。
但在RFC中并没有明确规定其使用方法。
该项也为可选项。
并不是所有的应用程序都符合RFC
有一些用来制定HTTP协议技术标准的文档，它们被称为RFC(Request for Comments，请求修正意见书)。
通常，应用程序会遵循由RFC确定的标准实现。
可以说，RFC是互联网的设计文档，要是不按照RFC标准执行，就有可能导致无法通信的状况。
比如，有一台Web服务器内的应用服务没有遵照RFC的标准实现，那Web浏览器就很可能无法访问这台服务器了。
由于不遵照RFC标准实现就无法进行HTTP协议通信，所以基本上客户端和服务器端都会以RFC为标准来实现HTTP协议。
但也存在某些1应用程序因客户端或服务器端的不同，而未遵照RFC标准，反而将自成一套的”标准”扩展的情况。
不按RFC标准来实现，当然也不必劳心费力让自己的”标准”符合其他所有的客户端和服务器端。
但设想一下，如果这款应用程序的使用者非常多，那会发生什么情况？不难想象，其他的客户端或服务器端必然都不得不去配合它。
实际在互联网上，已经实现了HTTP协议的一些服务器端和客户端里就存在上述情况。
说不定它们会与本书介绍的HTTP协议的实现情况不一样。