HTTP基础一：网络基础及Web

1.1 使用HTTP访问Web

1.1.1Web访问的过程

客户端：输入URL发送请求

服务器：返回请求数据

 

 

1.1.2 web请求建立在规则之上HTTP

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

1.2 HTTP历史

1990年HTTP问世，但是并没有正式的标准被建立，统称为HTTP0.9

1996年5月 HTTP1.0标准发布

1997年1月 HTTP1.1标准发布（目前主流）

2015年5月 HTTP2.0标准发布（正在转向的版本） 

1.3 网络基础TCP/IP

为了理解 HTTP，我们有必要事先了解一下 TCP/IP 协议族。通常使用的网络（包括互联网）是在 TCP/IP 协议族的基础上运作的。而 HTTP 属于它内部的一个子集。

1.3.1 TCP/IP协议簇

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

1.3.2 TCP/IP 的分层管理

TCP/IP 协议族里重要的一点就是分层。TCP/IP 协议族按层次分别分为以下 4 层：应用层、     传输层、网络层 和 数据链路层。

分层的优点：每层任务简单明确，不需要考虑其他层的工作

当某一层需要改变时，替换方便

TCP/IP参考模型
　　ISO制定的OSI参考模型的过于庞大、复杂招致了许多批评。与此对照，由技术人员自己开发的TCP/IP协议栈获得了更为广泛的应用。如图2-1所示，是TCP/IP参考模型和OSI参考模型的对比示意图。

各层常见协议：

应用层

应用层决定了向用户提供应用服务时通信的活动。TCP/IP 协议族内预存了各类通用的应用服务。比如，FTP（File Transfer Protocol，文件传输协议）和 DNS（Domain Name System，域名系统）服务就是其中两类。HTTP 协议也处于该层。

传输层

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

网络层（又名网络互连层）

网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（所谓的传输路线）到达对方计算机，并把数据包传送给对方。

与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线。

链路层（又名数据链路层，网络接口层）

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

1.3.3 TCP/IP通讯传输流

 

这种把数据信息包装起来的做法称为封装（encapsulate）。

1.4 与HTPP密切相关的协议TCP、IP、DNS

1.4.1 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），有点像快递公司的送货过程。想要寄快递的

人，只要将自己的货物送到集散中心，就可以知道快递公司是否肯收件发货，该快

递公司的集散中心检查货物的送达地址，明确下站该送往哪个区域的集散中心。接

着，那个区域的集散中心自会判断是否能送到对方的家中。

我们是想通过这个比喻说明，无论哪台计算机、哪台网络设备，它们都无法全面掌

握互联网中的细节。

1.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 协议会再次以相同的顺序发送相同的数据

包。

 

 

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

 

1.5 DNS解析服务

DNS（Domain Name System）服务是和 HTTP 协议一样位于应用层的协议。它提供

域名到 IP 地址之间的解析服务。

计算机既可以被赋予 IP 地址，也可以被赋予主机名和域名。比如 www.hackr.jp。

用户通常使用主机名或域名来访问对方的计算机，而不是直接通过 IP 地址访问。因

为与 IP 地址的一组纯数字相比，用字母配合数字的表示形式来指定计算机名更符合

人类的记忆习惯。

但要让计算机去理解名称，相对而言就变得困难了。因为计算机更擅长处理一长串

数字。

为了解决上述的问题，DNS 服务应运而生。DNS 协议提供通过域名查找 IP 地址，

或逆向从 IP 地址反查域名的服务。

1.6 URI和URL

1.6.1 URI

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

定义。

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:[e-mail]

news:comp.infosystems.www.servers.unix

tel:[phone]

telnet://192.0.2.16:80/

urn:oasis:names:specification:docbook:dtd:xml:4.1.2

1.6.2　URI 格式

表示指定的 URI，要使用涵盖全部必要信息的绝对 URI、绝对 URL 以及相对 URL。

相对 URL，是指从浏览器中基本 URI 处指定的 URL，形如 imagelogo.gif。

让我们先来了解一下绝对 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 中并没有明确规定其使用方法。该项也为可选项。

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

有一些用来制定 HTTP 协议技术标准的文档，它们被称为 RFC（Request

for Comments，征求修正意见书）。

通常，应用程序会遵照由 RFC 确定的标准实现。可以说，RFC 是互联网

的设计文档，要是不按照 RFC 标准执行，就有可能导致无法通信的状况。

比如，有一台 Web 服务器内的应用服务没有遵照 RFC 的标准实现，那

Web 浏览器就很可能无法访问这台服务器了。

由于不遵照 RFC 标准实现就无法进行 HTTP 协议通信，所以基本上客户

端和服务器端都会以 RFC 为标准来实现 HTTP 协议。但也存在某些应用

程序因客户端或服务器端的不同，而未遵照 RFC 标准，反而将自成一套

的“标准”扩展的情况。

不按 RFC 标准来实现，当然也不必劳心费力让自己的“标准”符合其他所有

的客户端和服务器端。但设想一下，如果这款应用程序的使用者非常多，

那会发生什么情况？不难想象，其他的客户端或服务器端必然都不得不去

配合它。

实际在互联网上，已经实现了 HTTP 协议的一些服务器端和客户端里就存

在上述情况。说不定它们会与本书介绍的 HTTP 协议的实现情况不一样。

本书接下来要介绍的 HTTP 协议内容，除去部分例外，基本上都以 RFC

的标准为准。