HTTP协议基础知识，你知道了吗？02

这篇总结HTTP的基本知识，HTTP的用法，不清楚的可以看一下。

主要介绍了HTTP协议的基本概念、交互模型、消息格式、消息头、响应消息状态码、MIME。HTTP协议基于请求/响应交互模型，因此所有基于HTTP协议的Web编程都使用的请求/响应处理模式。通过HTTP协议头，可以控制交互过程的客户端和服务端的行为。

1.HTTP的基本概念与交互模式

HTTP协议简介

• HTTP协议（Hypertext Transfer Protocol，超文本
  传送协议）是Web客户端与服务器端之间数据传输的通
  信协议。
• 从协议参考模型来看，它是运行于传输层TCP协议之
  上的应用层协议。Web服务器通常在TCP的80端口上侦
  听HTTP请求以提供Web页面访问等服务。
• HTTP是一种通用的，无状态(Stateless)的应用层协
  议，基于标准的客户-服务器模型。
• 早期用的HTTP协议是0.9版的，后来升级为1.0版，现
  在用的是1.1版，大多数的服务器为了提供兼容性，一般
  都能同时支持这几个版本。
• 目前下一代HTTP协议HTTP-NG（Next Generation
  of HTTP）正在制定中。
• 由于HTTP协议具有简单、高效等特点，在互连网上
  得到了非常广泛的应用，除了用于Web之外，还常在其
  他类型应用中作为数据传输协议。

支持客户机/服务器（Client/Server）模式，开放性好，
能充分发挥客户机的计算能力，响应速度快；
◆采用“请求/响应”的交互模式
◆协议设计合理、简单、高效。
◆协议设计灵活，扩展性好。
◆无状态（Stateless）。
◆持久连接。
◆支持内容协商（Content negotiation）机制。

HTTP协议交互模型

一个典型的HTTP协议交互过程主要包括四个步骤：

1. 客户端（例如浏览器）向服务端侦听的TCP端口（例
   如TCP/80端口）发起连接，直到客户端和服务端的
   TCP连接正常建立；
2. 客户端通过建立的TCP连接向服务端发送一个完整的
   HTTP请求消息，然后等待服务端响应；
3. 服务端收到客户端发来的请求，进行分析和处理，生
   成HTTP响应消息，通过建立的TCP连接返回给客户端；
4. 服务端在确认客户端收到响应的消息后，服务端主动
   关闭连接，释放相关资源。

使用代理的HTTP交互过程

HTTP代理（本质上是一个既做服务端又做客户端的中
介程序，它的主要工作就是接收客户端发送的请求消息，
转发给服务端，然后接收服务端返回的响应消息，再转发
给客户端。它的主要交互过程如下：

• 客户端建立与代理的TCP连接，并发送请求消息；
• 代理分析收到的请求消息，如果能自己处理，则直接生
  成响应消息发送给客户端，否则建立服务端的TCP连接，
  把经过翻译处理的HTTP请求消息发送给实际的服务端；
• 服务端分析处理请求消息，生成HTTP响应消息，返回
  给代理，并在对方确认收到后关闭连接；
• 代理接收到响应消息后，经过必要的分析和处理，再发
  送回给客户端，并在对方确认收到后关闭连接。
• “透明代理”（Transparent Proxy） ：透明代理在工
  作过程中，除了必要的处理（例如身份认证）之外对
  HTTP请求消息和响应消息不做任何其它修改。
• “非透明代理”（Non-Transparent Proxy）；非透明
  代理则是在工作过程中，会对HTTP请求消息和响应进
  行分析和修改，以提供附加服务支持。附加服务通常有
  媒体类型转换、协议简化、响应数据压缩等。

HTTP消息格式

• 分请求消息和响应消息
• 消息由“开始行”（start-line）或“状态行”
  （status-line）、“消息头”（headers）和“消息体”
  （message-body）构成。
• HTTP消息中的开始行（或状态行）和消息头全都是
  由直接可阅读的文本构成，并以回车加换行符（称为
  CRLF，在C语言中表示为”\x0d\x0a”）来结束消息头中
  的每一行。
• HTTP请求和响应的例子
  
  

2.HTTP请求消息

HTTP请求消息的格式

• 当客户端与服务端建立TCP连接后，客户端首先向服
  务端发送HTTP请求消息。请求消息通常用于客户端向服
  务端请求获取资源、发送数据或者获取服务端某个状态
  等。

• HTTP请求消息的格式
  
  
  HTTP请求方法
  

• 常用方法：GET方法
  GET方法用于向服务端请求获取Request-URI标识的资源。
  GET方法除了请求URI中可能包含查询参数外，一般不包
  含消息体，即不会发送其他数据。
  服务端在处理GET请求时，会根据一些请求头（Header）
  所指定的条件进行处理。
  HTTP协议设计在请求头和响应头中提供了相应的Header
  以控制缓存的使用。
  HTTP协议中设计了断点续传的机制，通过GET方法获取
  资源时可以指定获取的起始点。

• 常用方法：POST方法
  POST方法的作用是向服务端提交一段数据，请
  求服务端把该数据与Request-URI进行关联。
  POST方法常用于：
  ◆ 向已经存在的以Request-URI标识的资源追加
  一段数据，或者增加说明、注释等，指定的
  资源可以是文件、数据库或者是BBS的一个
  栏目等；
  ◆ 以表单的形式向服务端提交数据，RequestURI指向处理数据的程序。

• 常用方法：HEAD方法
  HEAD方法类似于前面的GET和POST方法，请求
  消息和应答消息都很相似。主要的区别在于GET方
  法会返回Request-URI所标识的资源内容本身，而
  HEAD方法仅仅返回相关的响应头信息，不返回资
  源内容。
  HEAD方法常用于测试资源是否存在、是否已经
  被修改或删除、

• 常用方法：PUT方法
  PUT方法的作用是请求以Request-URI为标识存
  储一个资源。
  在HTTP/1.1协议规范的定义中，POST方法和
  PUT方法的主要区别在于Request-URI所标识对象
  的含义有所不同。对于POST方法，Request-URI
  标识的资源应该是消息体的处理程序（Handler），
  消息体本身可以经过处理后以其他URI标识存在；
  而对PUT方法，Request-URI应该就是标识资源本
  身，服务端不应该把消息体的数据对应到其它资源
  上。

• 常用方法：DELETE方法
  DELETE方法用于请求在服务端删除以RequestURI标识的资源。服务端通常会删除该资源，或者
  是把资源转移到一个访问不到的地方

HTTP请求URI

◆“请求URI”（Request-URI）是URI的一种形式。
◆URI的全称是通用资源标识符（Uniform Resource
Identifier），主要作用是用于对Web上的资源
（HTML文档、图片、音频、视频、程序等）进行准
确定位。
◆URI目前常见有两种形式，一种是URL（统一资源定
位符，Uniform Resource Locator），另一种是
URN（统一资源名称，Uniform Resource Name），
URL和URN是URI的子集。
◆在HTTP协议中，请求URI采用URL的格式，通常为：

protocol://host[:port][absolute_path][#anchor]

• URL分为绝对URL和相对URL，绝对URL就是全格式
  的URL，而相对URL不包含任何命名规范的信息，只取
  absolute_path部分，它通常表示同一台机器上的资源。
  在HTTP协议中Request-URI采用的是相对URL格式。
  以绝对URL形式表示为：
  http://www.website.com/form/login.html
  用相对URL表示的请求URI就是：
  /form/login.html
  在获取这个资源的HTTP请求消息的开始行应该为：
  GET /form/login.html HTTP/1.1

3.HTTP响应消息

HTTP响应消息格式

• HTTP响应消息的格式
  
  为”HTTP/1.1”或”HTTP/1.0”，通常与客户端发送的请
  求消息中的HTTP版本号一致；
  Status-Code是状态码，它是由服务端返回的标识响
  应结果状态的代码，状态码由三位数字构成；
  Reason-Phrase是状态说明，它是一段英文文字，作
  为对状态码的描述。
  紧跟着状态行通常是响应的消息头区，由一个或多个
  消息头（可选，也可以没有消息头）组成，每个消息
  头为一行文本，以回车换行符结束。在消息头区的最
  后是一个空行（直接是回车换行符），表示消息头区
  结束。
  在消息头区域的后面是消息体。这部分才是服务端返
  回给客户端的数据，通常为HTML文档、图片、音频、
  视频、程序等资源。在一些情况下，只需状态码就能
  标识服务端对请求的处理结果，消息体可以为空。
• 典型的HTTP响应消息示例
  

HTTP响应状态码和状态说明

• 在HTTP响应消息中包含了状态码和状态说明。状态
  码表示服务端对本次请求处理结果的一个状态，状态说
  明是以可阅读文字的形式对状态码的描述和说明。状态
  码便于计算机处理，状态说明便于人们阅读和理解。
• 在协议设计中，HTTP响应消息中的状态码采用3位十
  进制数字表示，其中第一位数字表示响应消息的类别
  （Class），后面两位数字是序号，没有特别的含义。
• HTTP响应状态码
  
• 部分常见状态码
  ❖200 OK：这条状态码用于告诉客户端，请求已经
  成功处理完毕。
  ❖404 Not Found：这条状态码表明客户端所请求的
  资源不存在，客户端不应该再请求该资源。
  ❖500 Internal Server Error：当服务端在处理请求的
  过程中发生无法预知的错误导致无法继续处理时，
  产生并返回本状态码。

4.HTTP消息头

内容协商消息头
在HTTP请求消息和响应消息中通常都会包含一个或
多个消息头（header），每个消息头通常称为“字段”
（Field）。
消息头是客户端与服务端进行参数协商、传递参数、
描述消息体等的重要实体。
在HTTP协议的设计中，每个消息头的格式如下：
字段名(Field Name): 字段值(Field Value)
在HTTP协议中，服务端将会根据客户端发出的消息
头字段进行不同的处理，而客户端对响应中的消息头字
段进行解释后，给用户显示出不同的信息。
在HTTP请求消息和响应消息中通常都会包含一个或
多个消息头（header），每个消息头通常称为“字段”
（Field）。
消息头是客户端与服务端进行参数协商、传递参数、
描述消息体等的重要实体。
在HTTP协议的设计中，每个消息头的格式如下：
字段名(Field Name): 字段值(Field Value)
在HTTP协议中，服务端将会根据客户端发出的消息
头字段进行不同的处理，而客户端对响应中的消息头字
段进行解释后，给用户显示出不同的信息。

◆“内容协商”是指当资源存在多种表现形式（包括媒
体类型、语言、字符集和编码等方面）时，从中选择
对用户而言“最合适”的表现形式的过程。
◆内容协商的对象通常是响应消息中的消息体内容。
◆内容协商的基本过程包含两个步骤。由协商发起方通
过消息头提出自己所期望接收资源形式的列表（选项）
及其优先级，由接收方根据步骤一的列表以及自身的
实际情况进行选择，返回它认为是“最合适”的内容
形式。
◆HTTP中有两种内容协商的方式：服务器驱动协商
（Server-driven Negotiation）和客户驱动协商
（Agent-driven Negotiation）。

Accept字段：
Accept字段用于请求消息中客户端与服务端协商媒体
类型（media type）。
取值格式：
*/* 或 type/* 或 type/subtype
示例：
Accept: text/html,application/xhtml+xml,
application/xml;q=0.9,*/*;q=0.8
Accept字段所进行的协商是服务器驱动协商方式

• Accept-Charset字段
  本字段用于请求消息中客户端与服务端协商采用的字符
  集。指明客户端所能接受的字符集，如果服务端能支持所指
  定的字符集，则协商采用优先级最高的字符集进行处理，否
  则服务端返回406 Not Acceptable响应码。
  本字段取值中可以列入多种字符集，每种字符集之间以
  半角字符逗号”,”分隔，字符集的排列次序及其参数表示客
  户端希望接受字符集的优先级。
  常用的字符集有：iso-8859-1（英文字符集）、
  gb_2312-80（简体中文字符集）。
  本字段所进行的协商是服务器驱动协商方式。

• Accept-Encoding字段
  本字段用于请求消息中客户端与服务端协商采用的内
  容传输方式，仅针对消息体的内容。服务端根据客户端
  可接受的方式列表以及自身所能支持的方式，协商采用
  优先级最高的方式对返回的消息体内容进行处理。如果
  客户端提供的方式服务端都不支持，则返回406 Not
  Acceptable响应码。
  HTTP协议中定义的传输方式有：chunked（分块传
  输）、identity（无变换传输）、gzip（GZIP压缩后传
  输）、compress（LZW压缩后传输）、deflate（zip的
  deflate模式压缩后传输）。
  本字段所进行的协商是服务器驱动协商方式。

• Accept-Language字段
  本字段用于请求消息中客户端与服务端协商采用的语言。
  本字段的取值指明了客户端期望接受的语言列表，服务端
  根据顺序选择最高优先级的语言与客户端交互。如果请求
  中没有指定Accept-Language字段，则默认客户端接受
  任何语言。
  常见的语言有：en、en-us、zh、zh-cn。
  示例：
  Accept-Language: zh-cn,zh;q=0.8,enus;q=0.5,en;q=0.3
  本字段所进行的协商是服务器驱动协商方式。

• Allow字段
  用于响应消息中服务端通知客户端指定资源可以使用的
  请求方法，客户端在请求该资源时只能使用列表中的请求
  方法，采用其他请求方法都会导致服务端返回405
  Method Not Allowed响应码。
  以下是使用该字段的例子：
  Allow: GET, HEAD, PUT
  表明指定的资源只能允许使用请求方法GET、HEAD和
  PUT进行访问。
  Allow字段所进行的协商是客户驱动协商方式

缓存控制消息头

在HTTP协议实际使用中，为了提高资源的访问速度，
通常会采用缓存（cache）机制，把一些资源临时存放
在访问速度较快的地方，例如客户端浏览器本地磁盘、
网络速度较快代理服务器等。
当通过HTTP协议访问这些资源时，无需访问远端的
实际服务器，而直接从缓存中获取，可以大大提高资源
的访问速度。由于缓存中临时存放的资源在原始资源更
新之后需要跟随更新，不同的资源更新策略不同，甚至
某些资源不允许进行缓存。为此，HTTP协议中设计了缓存控制消息头字段，用于指定服务端和客户端的缓存策略。
Cache-Control字段：通过其取值，客户端和服务端都必须
遵循的缓存策略。可能取值：
◆”no-cache”表明不允许缓存请求消息
◆”no-store”表明请求的信息涉及隐私数据，不允许缓存请求
消息的任何内容。
◆”max-age” 表明本请求内容允许被缓存最多n秒。
◆”public”表明该响应允许在任何缓存设备中进行缓存。
◆”private”表明该响应属于单个用户的独有数据，公共缓存
设备不允许对该响应进行缓存，而私有缓存可以对其进行缓
存。
pragma字段除了用于缓存控制，还用于在请求消息
或响应消息中传递一些自定义的控制指令，协议要求代
理服务应该把所有接收到Pragma字段的内容直接转发出
去，接收方如无法识别取值中的内容，应该直接忽略。
在HTTP协议中定义的Pragma取值为：no-cache。
如果在请求消息头中设定了Pragma的取值为no-cache，
所有收到此消息的程序无论是否拥有指定资源的缓存，
都应该直接把该请求转发给最终服务器。
同样，如果在响应消息中进行此项设定，任何接收到
本消息的程序都不允许对消息进行缓存。

实体描述消息头

在HTTP请求消息和响应消息中，都有可能包含消息
体作为数据实体。
HTTP协议中定义了相应的消息头字段描述这些数据
实体，这些消息头字段都能用于请求消息和响应消息中。
常用的实体描述消息头字段
◆Content-Type
◆Content-Length。

Content-Type字段用于描述消息中数据实体的媒体类型
（media type）。该字段的格式为：
Content-Type: media-type; parameter
常见的parameter是“charset”，描述数据实体使用的字
符集。取值有：iso-8859-1（英文字符集）、gbk（中文字符
集）、utf-8（UTF-8字符集）等。
若浏览器使用GET方法获取HTML文档，服务端一般返回：
Content-Type: text/html; charset=utf-8
表明服务端返回的数据实体的媒体类型是text/html
（HTML文档），采用的是UTF-8字符集编码方式。
Content-Length字段用于描述消息中数据实体的大小，
以字节数（bytes）表示。
该字段的格式为：
Content-Length: DIGIT
其中，DIGIT是以十进制数表示的数据实体的字节数
大小，该大小仅指数据实体部分，不包含消息头等其他
部分。

条件控制消息头
为提高协议的交互效率和交互灵活性，HTTP协议中
设计了一系列的条件（conditional）控制消息头，在消
息中设定一些条件，当条件判定成立（判定结果为TRUE）
时才会执行相关动作。
条件控制消息头通常用于请求消息中，客户端通过设
定条件触发服务端的动作，较少不必要的开销。
通常条件控制消息头字段是名程以“If-”开头的字段。
常用字段有：
◆ If-Match字段
◆ If-Modified-Since字段
f-Match字段用于请求消息，客户端使用本字段控制服务
端执行条件，条件判断所依据的对象是请求操作针对的数据
实体。该字段的格式为：
If-Match: entity-tag，示例如：
If-Match: “xyzzy”, “r2d2xxxx”, “c3piozzzz”
If-Match: *
在客户端使用PUT或POST等请求方法执行更新资源的操
作时，可以设定If-Match字段，防止误修改了其他资源的内
容。
”If-None-Match” 与这个字段功能类似，判断条件相反。

If-Modified-Since字段用于请求消息，客户端使用本
字段控制服务端执行条件，条件判断所依据的对象是请
求操作针对的数据实体。该字段的格式为：
If-Modified-Since: date-string
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
这个字段通常用于缓存中资源对象的更新，只有原始
资源被修改之后才去更新缓存中的内容，可以较少开销
提高效率。
If-Unmodified-Since”与这个字段功能类似，判断条
件相反。

其他消息头
Host字段用于请求消息中，指明客户端所请求的资
源所在的主机及其端口号。格式为：
Host: host:port
Location字段用于响应消息中，主要用于在3xx状态
码的响应消息中指明重定向后的URI，在201 Created
状态码的响应消息中，Location指明了新创建资源的
URI。Location字段的格式为：
Location: URI
采用绝对路径：
Location: http://www.w3.org/pub/index.html
采用相对路径：Location: /pub/index.html

Date字段可用于请求消息和响应消息，表示消息产
生的时间。格式为：
Date: date-string
Date: Tue, 15 Nov 1994 08:12:31 GMT
Last-Modified字段可用于请求消息和响应消息，描
述消息体中数据实体的最后被修改的时间。格式为：
Last-Modified: date-string
其中，“date-string”是表示时间的字符串，其格
式参见“Date字段”。

User-Agent字段用于请求消息中，它的取值描述了
发出请求的客户端的相关信息，该信息可以包括客户端
的名称、版本号、所运行的操作系统平台等。如：
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0;
Windows NT 6.1)
Referer字段用于请求字段中，它用于向服务端指明
本次请求的URI是从哪个URI资源中获得的。如：
Referer:
http://www.w3.org/hypertext/DataSources/Overvie
w.html

5.多用途Internet邮件扩展（MIME）

MIME简介

• 多用途Internet 邮件扩展（Multipurpose Internet
  Mail Extensions，简称MIME）是一种邮件扩展协议，
  最早应用于电子邮件系统，后来引入到HTTP协议中，用
  于描述所传输的多媒体类型。
  在早期的电子邮件协议中，指明信文必须由7位ASCII
  字符组成，这使得通过邮件只能传输ASCII组成文本信息，
  无法支持传输多字节编码文本和二进制格式数据。
  电子邮件协议中增加了新的标准MIME，给非ASCII的
  信文指定编码规则，通过这些结构和编码规则，信文可
  以同时封装多个非ASCII的数据实体。

MIME在增加了的头字段
◆ MIME-Version：表示MIME的版本号。
◆ Content-description：内容描述，为普通字符串。
◆ Content-Id：内容的标号。
◆ Content-Transfer-Encoding：内容的编码方法。
◆ Content-type：正文的数据类型。

MIME在HTTP协议中的应用

HTTP响应消息体为”multipart”的示例