HTTP请求报文格式:
HTTP请求报文主要由请求行、首部行、请求正文3部分组成
1，请求行
由3部分组成，分别为：请求方法、URL（见备注1）以及协议版本，之间由空格分隔
请求方法包括GET、HEAD、PUT、POST、TRACE、OPTIONS、DELETE以及扩展方法，当然并不是所有的服务器都实现了所有的方法，部分方法即便支持，处于安全性的考虑也是不可用的
方法字段
①GET:请求获取Request-URI(URI:通用资源标识符,URL是其子集，URI注重的是标识，而URL强调的是位置，可以将URL看成原始的URI),所标识的资源
最常见的一种请求方式，当客户端要从服务器中读取文档时，当点击网页上的链接或者通过在浏览器的地址栏输入网址来浏览网页的，使用的都是GET方式。GET方法要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端。使用GET方法时，请求参数和对应的值附加在URL后面，利用一个问号（“?”）代表URL的结尾与请求参数的开始，传递参数长度受限制。例如，/index.jsp?id=100&op=bind,这样通过GET方式传递的数据直接表示在地址中，所以我们可以把请求结果以链接的形式发送给好友。
地址中”?”之后的部分就是通过GET发送的请求数据，我们可以在地址栏中清楚的看到，各个数据之间用”&”符号隔开。显然，这种方式不适合传送私密数据。另外，由于不同的浏览器对地址的字符限制也有所不同，一般最多只能识别1024个字符，所以如果需要传送大量数据的时候，也不适合使用GET方式。
②POST：在Request-URI所标识的资源后附加新的数据；支持HTML表单提交，表单中有用户添入的数据，这些数据会发送到服务器端，由服务器存储至某位置（例如发送处理程序）
对于上面提到的不适合使用GET方式的情况，可以考虑使用POST方式，因为使用POST方法可以允许客户端给服务器提供信息较多。POST方法将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据，这样POST方式对传送的数据大小没有限制，而且也不会显示在URL中。
③HEAD:请求Request-URI所标识的资源响应消息报头，HEAD方法可以在响应时不返回消息体。HEAD就像GET，只不过服务端接受到HEAD请求后只返回响应头，而不会发送响应内容。当我们只需要查看某个页面的状态的时候，使用HEAD是非常高效的，因为在传输的过程中省去了页面内容。
④PUT：与GET相反，请求服务器存储一个资源，并用Request-URI做为其标识；例如发布系统。
⑤DELETE：请求删除URL指向的资源
⑦TRACE：跟踪请求要经过的防火墙、代理或网关等，主要用于测试或诊断
⑧CONNECT保留将来使用
协议版本的格式为：HTTP/主版本号.次版本号，常用的有HTTP/1.0和HTTP/1.1
2，请求头部
请求头部为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔
常见请求头如下：
请求头 |
说明 |
Host |
接受请求的服务器地址，可以是IP:端口号，也可以是域名 |
User-Agent |
发送请求的应用程序名称 |
Connection |
指定与连接相关的属性，如Connection:Keep-Alive |
Accept-Charset |
通知服务端可以发送的编码格式 |
Accept-Encoding |
通知服务端可以发送的数据压缩格式 |
Accept-Language |
通知服务端可以发送的语言 |
请求头部的最后会有一个空行，表示请求头部结束，接下来为请求正文，这一行非常重要，必不可少
3，请求正文
可选部分，比如GET请求就没有请求正文
GET请求示例：
POST请求示例：
HTTP响应报文格式:
HTTP响应报文主要由状态行、响应头部、响应正文3部分组成
1，状态行
由3部分组成，分别为：协议版本，状态码，状态码描述，之间由空格分隔
状态代码为3位数字，200~299的状态码表示成功，300~399的状态码指资源重定向，400~499的状态码指客户端请求出错，500~599的状态码指服务端出错（HTTP/1.1向协议中引入了信息性状态码，范围为100~199）
常遇到的状态码说明：
| 状态码 | 状态描述 | 简要说明 |
|---|---|---|
| 200 |
OK | 客户端请求成功，信息在返回的响应报文中 |
| 201 |
Created |
请求已经被实现，而且有一个新的资源已经依据请求的需要而创建，且其URI已经随Location头信息返回。 |
| 301 | Moved Permanently | 被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一 |
| 302 | Found |
在响应报文中使用首部“Location: URL”指定临时资源位置 |
| 304 | Not Modified | 条件式请求中使用 |
403 400 |
Forbidden Bad Request |
请求被服务器拒绝 一个通用差错代码，指示该请求不能被服务器理解 |
| 404 | Not Found | 服务器无法找到请求的URL |
| 405 | Method Not Allowed | 不允许使用此方法请求相应的URL |
| 500 |
Internal Server Error | 服务器内部错误 |
| 502 | Bad Gateway | 代理服务器从上游收到了一条伪响应 |
| 503 | Service Unavailable | 服务器此时无法提供服务，但将来可能可用 |
| 505 | HTTP Version Not Supported | 服务器不支持，或者拒绝支持在请求中使用的HTTP版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。 |
2，响应头部
与请求头部类似，为响应报文添加了一些附加信息
常见响应头部如下：
响应头 |
说明 |
Server |
服务器应用程序软件的名称和版本 |
Content-Type |
响应正文的类型（是图片还是二进制字符串） |
Content-Length |
响应正文长度 |
Content-Charset |
响应正文使用的编码 |
Content-Encoding |
响应正文使用的数据压缩格式 |
Content-Language |
响应正文使用的语言 |
响应示例：
PS：
1，URI、URL和URN之间的区别
URI全名为Uniform Resource Indentifier（统一资源标识），用来唯一的标识一个资源，是一个通用的概念，URI由两个主要的子集URL和URN组成
URL全名为Uniform Resource Locator（统一资源定位），通过描述资源的位置来标识资源
URN全名为Uniform Resource Name（统一资源命名），通过资源的名字来标识资源，与其所处的位置无关，这样即使资源的位置发生变动，其URN也不会变化
HTTP规范将更通用的概念URI作为其资源标识符，但是实际上，HTTP应用程序处理的只是URI的URL子集
关于HTTP请求GET和POST的区别
1.GET提交，请求的数据会附在URL之后（就是把数据放置在HTTP协议头＜request-line＞中），以?分割URL和传输数据，多个参数用&连接;例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。
POST提交：把提交的数据放置在是HTTP包的包体＜request-body＞中。
因此，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变
2.传输数据的大小：
首先声明,HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。 而在实际开发中存在的限制主要有：
GET:特定浏览器和服务器对URL长度有限制，例如IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。
因此对于GET提交时，传输数据就会受到URL长度的限制。
POST:由于不是通过URL传值，理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。
3.安全性：
POST的安全性要比GET的安全性高。注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改，而这里安全的含义是真正的Security的含义，比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存， (2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了。