图解HTTP读书笔记
前言
用到HTTP协议的各方面知识:网络爬虫程序、分析抓包数据、实现HTTP服务器、提供网站REST API、修改后端定制框架等方面。本书前半部分由HTTP的成长发展史娓娓道来,基于HTTP 1.1标准讲解通信过程,包括HTTP方法、协议格式、报文结构、首部字段、状态码等的具体含义,还分别讲解HTTP通信过程中代理、网关、隧道等的作用。接着介绍SPDY、WebSocket、WebDAV等HTTP的扩展功能。作者还从细节方面举例,让读者更好地理解何为无状态(stateless)、301和302重定向的区别在哪、缓存机制,等等。本书后半部分的重心放在Web安全上,涵盖HTTPS、SSL、证书认证、加密机制、Web攻击手段等内容。旨在让读者对HTTP协议形成一个整体概念,明确设计HTTP的目的及意义所在,了解HTTP的工作机制,掌握报文中常用的首部字段,返回结果状态码的作用,对各种客户端与服务器的通信交互场景的细节等都做到了然于心,从而在平时的开发工作中独立思考,迅速准确地定位分析由HTTP引发的问题,并辅以适当的方法加以解决。
第一章 Web及网络基础
1.1 使用HTTP协议访问Web
Web使用一种名为HTTP(HyperText Transfer Protocol,超文本传输协议)的协议作为规范,完成从客户端到服务器端等一系列运作流程。而协议是指规则的约定。可以说,Web是建立在HTTP协议上通信的。
1.2 HTTP的诞生
最初设想的基本理念是:借助多文档之间相互关联形成的超文本(HyperText),连成可相互参阅的WWW(World Wide Web,万维网)。
现在已提出了3项WWW构建技术,分别是:把SGML(Standard GeneralizedMarkup Language,标准通用标记语言)作为页面的文本标记语言的HTML(HyperText Markup Language,超文本标记语言);作为文档传递协议的HTTP;指定文档所在地址的URL(Uniform Resource Locator,统一资源定位符)。
WWW这一名称,是Web浏览器当年用来浏览超文本的客户端应用程序时的名称。现在则用来表示这一系列的集合,也可简称为Web。
HTTP/0.9:HTTP于1990年问世。那时的HTTP并没有作为正式的标准被建立。这时的HTTP其实含有HTTP/1.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就是当前的最新版本。
1.3 网络基础TCP/IP
通常使用的网络(包括互联网)是在TCP/IP协议族的基础上运作的。而HTTP属于它内部的一个子集。
计算机与网络设备要相互通信,双方就必须基于相同的方法。比如,如何探测到通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要事先确定。不同的硬件、操作系统之间的通信,所有的这一切都需要一种规则。而我们就把这种规则称为协议(protocol)。协议中存在各式各样的内容。从电缆的规格到IP地址的选定方法、寻找异地用户的方法、双方建立通信的顺序,以及Web页面显示需要处理的步骤,等等。像这样把与互联网相关联的协议集合起来总称为TCP/IP。也有说法认为,TCP/IP是指TCP和IP这两种协议。还有一种说法认为,TCP/IP是在IP协议的通信过程中,使用到的协议族的统称。
TCP/IP协议族里重要的一点就是分层。TCP/IP协议族按层次分别分为以下4层:应用层、传输层、网络层和数据链路层。
把TCP/IP层次化是有好处的。比如,如果互联网只由一个协议统筹,某个地方需要改变设计时,就必须把所有部分整体替换掉。而分层之后只需把变动的层替换掉即可。把各层之间的接口部分规划好之后,每个层次内部的设计就能够自由改动了。
TCP/IP协议族各层的作用如下。
应用层:应用层决定了向用户提供应用服务时通信的活动。TCP/IP协议族内预存了各类通用的应用服务。比如,FTP(File TransferProtocol,文件传输协议)和DNS(Domain Name System,域名系统)服务就是其中两类。HTTP协议也处于该层。
传输层:传输层对上层应用层,提供处于网络连接中的两台计算机之间的数据传输。在传输层有两个性质不同的协议:TCP(Transmission Control Protocol,传输控制协议)和UDP(User Data Protocol,用户数据报协议)。
网络层(又名网络互连层):网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径(所谓的传输路线)到达对方计算机,并把数据包传送给对方。与对方计算机之间通过多台计算机或网络设备进行传输时,网络层所起的作用就是在众多的选项内选择一条传输路线。
链路层(又名数据链路层,网络接口层):用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC(Network Interface Card,网络适配器,即网卡),及光纤等物理可见部分(还包括连接器等一切传输媒介)。硬件上的范畴均在链路层的作用范围之内。

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

我们用HTTP举例来说明,首先作为发送端的客户端在应用层(HTTP协议)发出一个想看某个Web页面的HTTP请求。
接着,为了传输方便,在传输层(TCP协议)把从应用层处收到的数据(HTTP请求报文)进行分割,并在各个报文上打上标记序号及端口号后转发给网络层。
在网络层(IP协议),增加作为通信目的地的MAC地址后转发给链路层。
这样一来,发往网络的通信请求就准备齐全了。接收端的服务器在链路层接收到数据,按序往上层发送,一直到应用层。当传输到应用层,才能算真正接收到由客户端发送过来的HTTP请求。
发送端在层与层之间传输数据时,每经过一层时必定会被打上一个该层所属的首部信息。反之,接收端在层与层传输数据时,每经过一层时会把对应的首部消去。这种把数据信息包装起来的做法称为封装(encapsulate)。
1.4 与HTTP关系密切的协议:IP、TCP和DNS
1.4.1 负责传输的IP协议
按层次分,IP(Internet Protocol)网际协议位于网络层。Internet Protocol这个名称可能听起来有点夸张,但事实正是如此,因为几乎所有使用网络的系统都会用到IP协议。TCP/IP协议族中的IP指的就是网际协议,协议名称中占据了一半位置,其重要性可见一斑。可能有人会把“IP”和“IP地址”搞混,“IP”其实是一种协议的名称。
IP协议的作用是把各种数据包传送给对方。而要保证确实传送到对方那里,则需要满足各类条件。其中两个重要的条件是IP地址和MAC地址(Media AccessControl 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-wayhandshaking)策略。用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地址反查域名的服务。

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

1.7 URI和URL
与URI(统一资源标识符)相比,我们更熟悉URL(Uniform Resource Locator,统一资源定位符)。URL正是使用Web浏览器等访问Web页面时需要输入的网页地址。比如,下图的http://hackr.jp/就是URL。
1.7.1 统一资源标识符
URI是Uniform Resource Identifier的缩写。RFC2396分别对这3个单词进行了如下定义。
Uniform:规定统一的格式可方便处理多种不同类型的资源,而不用根据上下文环境来识别资源指定的访问方式。另外,加入新增的协议方案(如http:或ftp:)也更容易。
Resource:资源的定义是“可标识的任何东西”。不仅是文档文件,图像或服务(例如当天的天气预报)等能够区别于其他类型的,全都可作为资源。另外,资源不仅可以是单一的,也可以是多数的集合体。
Identifier:表示可标识的对象。也称为标识符。
采用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例子,如下所示。

1.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地址名,还可以是[0:0:0:0:0:0:0:1]这样用方括号括起来的IPv6地址名。
服务器端口号:定服务器连接的网络端口号。此项也是可选项,若用户省略则自动使用默认端口号。
带层次的文件路径:指定服务器上的文件路径来定位特指的资源。这与UNIX系统的文件目录结构相似。
查询字符串:针对已指定的文件路径内的资源,可以使用查询字符串传入任意参数。此项可选。
片段标识符:使用片段标识符通常可标记出已获取资源中的子资源(文档内的某个位置)。但在RFC中并没有明确规定其使用方法。该项也为可选项。
补充:
并不是所有的应用程序都符合RFC
有一些用来制定HTTP协议技术标准的文档,它们被称为RFC(Request forComments,征求修正意见书)。
通常,应用程序会遵照由RFC确定的标准实现。可以说,RFC是互联网的设计文档,要是不按照RFC标准执行,就有可能导致无法通信的状况。比如,有一台Web服务器内的应用服务没有遵照RFC的标准实现,那Web浏览器就很可能无法访问这台服务器了。
由于不遵照RFC标准实现就无法进行HTTP协议通信,所以基本上客户端和服务器端都会以RFC为标准来实现HTTP协议。但也存在某些应用程序因客户端或服务器端的不同,而未遵照RFC标准,反而将自成一套的“标准”扩展的情况。
不按RFC标准来实现,当然也不必劳心费力让自己的“标准”符合其他所有的客户端和服务器端。但设想一下,如果这款应用程序的使用者非常多,那会发生什么情况?不难想象,其他的客户端或服务器端必然都不得不去配合它。
实际在互联网上,已经实现了HTTP协议的一些服务器端和客户端里就存在上述情况。说不定它们会与本书介绍的HTTP协议的实现情况不一样。
本书接下来要介绍的HTTP协议内容,除去部分例外,基本上都以RFC的标准为准。
第二章 简单的HTTP协议
2.1 HTTP协议用于客户端和服务器端之间的通信
HTTP协议和TCP/IP协议族内的其他众多的协议相同,用于客户端和服务器之间的通信。请求访问文本或图像等资源的一端称为客户端,而提供资源响应的一端称为服务器端。
在两台计算机之间使用HTTP协议通信时,在一条通信线路上必定有一端是客户端,另一端则是服务器端。有时候,按实际情况,两台计算机作为客户端和服务器端的角色有可能会互换。但就仅从一条通信路线来说,服务器端和客户端的角色是确定的,而用HTTP协议能够明确区分哪端是客户端,哪端是服务器端。
2.2 通过请求和响应的交换达成通信
HTTP协议规定,请求从客户端发出,最后服务器端响应该请求并返回。换句话说,肯定是先从客户端开始建立通信的,服务器端在没有接收到请求之前不会发送响应。
GET /index.html HTTP/1.1
HOST:hacker.jp
- 1
- 2
起始行开头的GET表示请求访问服务器的类型,称为方法(method)。随后的字符串/index.htm指明了请求访问的资源对象,也叫做请求URI(request-URI)。最后的HTTP/1.1,即HTTP的版本号,用来提示客户端使用的HTTP协议功能。
请求报文是由请求方法、请求URI、协议版本、可选的请求首部字段和内容实体构成的。

响应报文基本上由协议版本、状态码(表示请求成功或失败的数字代码)、用以解释状态码的原因短语、可选的响应首部字段以及实体主体构成。
