HTTP学习笔记02-HTTP报文格式之概述

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表示那啥,前面说过了.

实体部分

主体没什么好说的,就是报文携带的内容.