HTTP学习笔记02-HTTP报文格式之概述
学习一个协议感觉最有意思的就是看包结构…在我看来这是唯一不费脑子看上去又很牛逼的东西. wireshark一开,熟练的找到数据包,看这个字段那个字段. 虽然一时半会儿甚至很长之间之类也不知道这玩意儿有啥用,但是,拿来装装X还是不错的.
HTTP报文格式
从结构上来说,HTTP报文分为四个部分:
- 起始行
- 首部
- 一个空行
- (可选)报文主体
首先起始行和首部之间有一个行终止符符,这个行终止符比较特殊,是由回车符(ASCII码12)和换行符(ASCII10)组成的. 就是传说中的CRLF(其实是两个字符CR和LF)(其实就是C语言中传说的 )
为什么C中的换行必须是写 ?
这要从很久很久之前的打字机说起了.或许都在电视或者教科书上见过打字机. 打字机的换行其实是分两步进行的. 回车和新行. 回车( )是表示,字车回到起始位置.新行( )表示纸筒上卷一行. 就像下面这个样子.
不同系统对行终止符的处理不一样,windows所谓换行是 unix类系统的是 mac的是 …
HTTP协议规定应该使用CRLF作为行终止序列,但是作为一个稳健的程序,应该可以接受单个换行或者回车作为行终止.
报文的语法
HTTP报文总共就两类,request和response. request就是向服务器发出一个请求动作,然后服务器会以response报文进行回应. (好简单的样子…)从结构上来看,request报文和response报文结构上差不多.
祭出HTTP抓包利器,Fiddler
request报文
response报文
这里是文字版,截图只是为了装一下…
GET http://www.joes-hardware.com/ HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: www.joes-hardware.com
Pragma: no-cache
HTTP/1.1 200 OK
Date: Wed, 27 Jul 2016 08:12:00 GMT
Server: Apache/2.2.22 (Unix) DAV/2 FrontPage/5.0.2.2635 mod_ssl/2.2.22 OpenSSL/1.0.1h
Last-Modified: Tue, 20 Mar 2001 02:29:40 GMT
ETag: "146deac-2ba-37fe714024d00"
Accept-Ranges: bytes
Content-Length: 698
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
<HTML>
<HEAD>
<TITLE>Welcome To Joe's Hardware Store</TITLE>
</HEAD>
<BODY><FONT FACE=arial SIZE=+2>
<TABLE>
<TR>
<TD><IMG ALIGN=middle SRC="specials/locking-pliers.gif"></TD>
<TD ALIGN=CENTER><FONT SIZE=+4>Welcome to Joe's Hardware Store</FONT><BR>
<FONT SIZE=+2>(www.joes-hardware.com)</FONT></TD>
<TD><IMG ALIGN=middle SRC="specials/locking-pliers.gif"></TD>
</TR>
</TABLE>
<HR>
<CENTER>
<P>Joe's Hardware is a hypothetical online hardware store.</P>
<P>The website is a live test case for the O'Reilly and Associates
reference book <A href="http://www.http-guide.com">"HTTP: The
Definitive Guide"</A>.</P>
</CENTER>
</FACE>
</BODY>
</HTML>
总结起来就是:
request的报文结构
<method> <request-URL> <version>
<headers>
<entity-body>response的报文结构
<version> <status> <reason-phrase>
<headers>
<entity-body>- method:客户端请求的一个动作,这个动作有很多,但是常用的有两种. (POST和GET)
- request-URL:这个是所请求的URL,这个可以是相对URL也可以是绝对URL. 但是作为一个懒的动脑子的人,在coding的时候使用绝对路径总是没错的. 就好像编码使用UTF-8总不会乱码一样…
- **version:**HTTP协议版本,这个格式是
HTTP/<major>.<minor>目前有两种 HTTP/1.0 和HTTP/1.1 - status-code: 状态码,3位数字,用于描述请求过程中的状态.
- reason-phrase: 对于状态码的一个描述,主要是给人看. 程序可以直接看状态码,不屑于看这个.
- headers: 首部们 注意,header不止一个,也可以没有… 每一行可以看作是一个首部. 一个首部由三部分组成, key:value CRLF. 也就是说一个header由header的名字,冒号,header的值还有一个行终止符组成(说行终止符总觉得比说换行符先得要专业)
- entity-body: 这是主体,没什么好说的,但是!!!BUT!!! 一定要注意,首部和主体之间是通过一个空行隔开的.
起始行
所有HTTP报文都有一个起始行. 请求报文的起始行说明了老子要干什么. 响应报文的起始行说明了都发生了些什么.
请求行
请求报文的起始行,主要包括三部分,方法 请求URL HTTP版本 每个字段之间由空格隔开.
我纠结了很久,为什么HTTP协议不像底层的IP协议之类的协议那样去直接规定哪些位代表什么含义,而是通过文本还使用各种蛋疼的空格换行来分隔字段. 后来我想明白了,也不知道我想的对不对. HTTP作为一个应用层协议,更多的是需要被程序员,也就是人类(暂且将程序员归为人类的范畴…) 所以在这些较高层的协议中,直接处理人类语言或许是一种更直观的方式. 也就是说底层协议的处理过程相对是固定的,可以使用固定的软件甚至是硬件逻辑来处理. 人参与的过程较少,直接使用对机器友好的比特位来标识信息更高效. 而HTTP这种应用层协议,人或者说程序员参与的比重较大,使用对人类(和程序员)友好的这种直观文本更合理一点.
IP包结构
方法
方法主要是告诉服务器要干些什么,HTTP规定了很多方法,但是实际上最常用的就两个GET和POST.
| 方法 | 描述 | 是否携带报文主体 |
|---|---|---|
| GET | 从服务器获取一份文档 | 否 |
| HEAD | 只从服务器获取文档的首部 | 否 |
| POST | 向服务器发送要处理的数据 | 是 |
| PUT | 将请求的主体存在服务器上 | 是 |
| TRACE | 对可能经过的代理服务器进行追踪 | 否 |
| OPTIONS | 决定可以在服务器上执行哪些方法 | 否 |
| DELETE | 从服务器上删除一份文档 | 否 |
响应行
响应行是响应报文的起始行,主要包括三部分内容HTTP版本 状态码 状态码短语
状态码
状态码包括在响应报文的起始行也就是响应行中. 方法是客户端告诉服务要做什么,状态码就是服务器告诉客户端,发生了什么. 状态码主要有那么几类.
- 200-299:成功
- 300-399:重定向
- 400-499:客户端请求错误
- 500-599:服务器内部错误
常见的有那么几种:200:成功;传说中的404:not found(情不自禁的祝病魔早日战胜方校长)
版本号
为什么使用版本号呢,版本号标识应用程序支持的最高的HTTP版本.主要是为了让对方了解自己的报文格式和能力.
首部
一个HTTP报文可以携带多个首部,首部直接跟在起始行的后面,可以有0-N个. 首部就是一些键值对. 可以理解为是一些可以被解析的参数.
首部分类
HTTP是一个相当灵(sui)活(yi)的协议,可以自己定义首部内容…
如果严格来分类的话,可以分那么几种:
- 通用首部:在请求报文和响应报文中都可以出现
- 请求首部:提供更多的请求信息
- 响应首部:提供更多的响应信息
- 实体首部:描述主体的长度,内容或者资源本身
- 扩展首部:协议没有规定,自己瞎逑搞的首部
首部的组成:字段名: 字段值/CRLF/ CRLF表示那啥,前面说过了.
实体部分
主体没什么好说的,就是报文携带的内容.