1 消息类型
HTTP消息由客户端到服务器的请求消息和服务器到客户端的响应消息组成。请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。
2 请求消息
Request 消息分为4部分：
1、 请求行（Request-Line）
2、 消息报头（Header）
3、 CRLF
4、 请求正文（Entity-Body）
结构如下所示：
2.1 请求行
第一行中的Method表示请求方法，比如"POST"，"GET"，Path-to-resoure表示请求的资源， Http/version-number 表示HTTP协议的版本号。
请求方法（所有方法全为大写）有多种，各个方法的解释如下：
| 名字 |
内容 |
| GET |
请求获取Request-URI所标识的资源 |
| POST |
在Request-URI所标识的资源后附加新的数据 |
| HEAD |
请求获取由Request-URI所标识的资源的响应消息报头 |
| PUT |
请求服务器存储一个资源，并用Request-URI作为其标识 |
| DELETE |
请求服务器删除Request-URI所标识的资源 |
| TRACE |
请求服务器回送收到的请求信息，主要用于测试或诊断 |
| CONNECT |
保留将来使用 |
| OPTIONS |
请求查询服务器的性能，或者查询与资源相关的选项和需求 |
2.2 请求报头
请求头域允许客户端传递请求的附加信息和客户端自己的附加信息给服务器。这些头域作为请求的修饰，这和程序语言方法调用的参数语义是等价的。
请求头（request-header）=
Accept
|Accept-Charset
|Accept-Encoding
|Accept-Language
|Authorization
|Expect
|From
|Host
|If-Match
|If-Modified-Since
|If-None-Match
|If-Range
|If-Unmodified-Since
|Max-Forwards
|Proxy-Authorization
|Range
|Referer
|TE
|User-Agent
请求头域的名字是能被扩展，但只能随协议版本改变而被扩展。然而新的或实践性的头域可以给定请求头域语义，如果所有通信方都把它看作请求头域。不能识别的头域会被看作实体头域（entity-header）。
2.3 应用举例
3 响应消息
HTTP Response消息的结构和Request消息的结构基本一样。 同样也分为三部分。
1、 状态行（Request line）
2、 消息报头（request header）
3、 CRLF
4、 响应正文（body）
结构如下图：
3.1 状态行
状态行格式如下：HTTP-Version Status-Code Reason-Phrase CRLF其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。
Status-Code元素是一个试图理解和满足请求的三位数字整数码。原因短语（Reason-Phrase）是为了给出关于状态码的简单的文本描述。状态码用于控制，而原因短语（Reason-Phrase）是让用户便于阅读。客户端不需要检查和显示原因短语。
状态码的第一位数字定义响应类别。后两位数字没有任何分类角色。第一位数字有五种值：
-1xx ：报告的，请求被接收到，继续处理。
-2xx ：成功，被成功地接收（received），理解（understood），接受（accepted）的动作 。
-3xx ：重发 ，为了完成请求必须采取进一步的动作。
-4xx ：客户端出错 ，请求包括错的语法或不能被满足。
-5xx ：服务器出错，-服务器无法完成显然有效的请求。
常见的状态码：
| 状态码 |
状态描述 |
说明 |
| 200 |
OK |
客户端请求成功 |
| 400 |
Bad Request |
客户端请求有语法错误，不能被服务器所理解 |
| 401 |
Unauthorized |
请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用 |
| 403 |
Forbidden |
服务器收到请求，但是拒绝提供服务 |
| 404 |
Not Found |
没有发现文件、查询或URl |
| 500 |
Internal Server Error |
内部服务器错误 |
| 503 |
Server Unavailable |
服务器当前不能处理客户端的请求，一段时间后可能恢复正常 |
3.2 响应报头
响应头域允许服务器传送响应的附加信息，这些信息不能放在状态行（Status-Line）里.。这些头域给出有关服务器的信息以及请求URI（Request-URI）指定资源的更进一步访问信息。
response-header =
Accept-Ranges
|Age
|Etag
|Location
|Proxy-Autenticate
|Retry-After
|Server
|Vary
|WWW-Authenticate
响应头域的名字能依赖于协议版本的变化而扩展。然而，新的或者实践性的头域可能会给予响应头域的语义如果通信所有成员都能识别他们并把他们看作响应头域。不被识别的头域被看作实体头域。
3.3 应用举例
4 实体（Entity）
如果不被请求方法或响应状态码所限制，请求和响应消息都可以传输实体。实体包括实体头域（entity-header）与实体主体（entity-body），而有些响应只包括实体头域（entity-header）。
在本节中的发送者和接收者是否是客户端或服务器，这依赖于谁发送或谁接收此实体。
4.1 实体头域（Entity Header Fields）
实体（entity-header）头域定义了关于实体主体的的元信息，或在无主体的情况下定义了请求的资源的元信息。有些元信息是可选的；一些是必须的。
entity-header = Allow
| Content-Encoding
| Content-Language
| Content-Length
| Content-Location
| Content-MD5
| Content-Range
| Content-Type
| Expires
| Last-Modified
| extension-header
extension-header = message-header
扩展头机制允许在不改变协议的前提下定义额外的实体头域，但不保证这些域在接收端能够被识别。未被识别的头域应当被接收者忽略，且必须被透明代理（transparent proxy）转发。
4.2 实体主体（Entity Body）
由HTTP请求或响应发送的实体主体（如果存在的话）的格式与编码方式应由实体的头域决定
Entity-body= *OCTET
实体主体（entity-body）只有当消息主体存在时时才存在。实体主体（entity-body）从消息主体根据传输译码头域（Transfer-Encoding）解码得到，传输译码用于确保消息的安全和合适传输。
4.3 类型（Type）
当消息包含实体主体（entity-body）时，主体的数据类型由实体头域的Content-Type和Content-Encoding头域确定。这些头域定义了两层顺序的编码模型：
Entity-body：=Content-Encoding（ Content-Type（ data） ）
Content-Type指定了下层数据的媒体类型。Content-Encoding可能被用来指定附加的应用于数据的内容编码，经常用于数据压缩的目的，内容编码是请求资源的属性。没有缺省的编码。
任一包含了实体主体的HTTP/1.1消息都应包括Content-Type头域以定义实体主体的媒体类型。如果只有媒体类型没有被Content-Type头域指定时，接收者可能会尝试猜测媒体类型，这通过观察实体主体的内容并且/或者通过观察URI指定资源的扩展名。如果媒体类型仍然不知道，接收者应该把类型看作”application/octec-stream”。
4.4 实体主体长度（Entity Length）
消息的实体主体长度指的是消息主体在被应用于传输编码（transfer-coding）之前的长度。