哎，你真是天天没事干，这种问题搞清楚了对开发来说又有什么帮助啊？程序是用来解决问题的，你是纯搞理论研究的，反正我是无知者无畏，it知识是学不完的，能会用一些都不错了，死抠这个你可以抠十年，最后抠出来了还没有什么应用场景骚年

1. 有没有BODY部分，也就是说除了URL和头部，有没有信息体是根本区别。所以GET不能用来从客户端传送大量数据到服务器端。因为GET所有的参数都在URL（浏览器地址栏）里。
2. HTTP是应用层协议，一般基于TCP协议的可靠数据流。所以分析HTTP不必分析报文和数据包。

举例：
GET方法：
GET /index.html?name=leo HTTP/1.1
Accept: / <这是头部>
<空行>
结束

POST方法：
POST /index.html HTTP/1.1
Acept: /
Content-Length: 10
<空行>
1234567890
<空行>
结束

如果非得说不同的话，那就是浏览器处理这两种协议的方式不同，GET想刷新几次刷新几次，POST刷新就会提示“重复提交表单”，非要给这两个扣个帽子，那就应该是根据流传下来的习惯，这两个东西的“幂等性”不同。

至于后台处理POST和GET有没有不同，那就不好说了。
以前貌似试过，jsp的servlet.getParameter取不到POST放在URL的参数。我不确定。

我的理解：
POST提交是隐式。（提交的参数对流量者是隐藏的）
GET提交是显式。（提交的参数包含在URL中，是可见的）

本质区别是数据放在哪里。

性质性的区别是幂等。

GET获取与POST给予的关系

get 一万遍 得到的都是同一个东西 post就不一样了 这个就是等幂和非等幂

推荐你看2篇文章，第一个比第二个通俗一些，第二个在后面讲了一些http协议的东西，其实他们的区别也就这些了。
GET和POST有什么区别？
HTTP POST GET详解

可以看看这篇文章 链接描述

这可能多多少少有RESTful的功劳，POST/DELETE/PUT/GET和数据操作对应起来，网上资料很多。

 POST /uri 创建
DELETE /uri/xxx 删除
PUT /uri/xxx 更新或创建
GET /uri/xxx 查看

另外GET的话， URL是有长度限制的，（虽然很长，但是有时候不一定足够）

题主提出这个问题应当是因为现在很多人使用GET来提交数据。从协议规范上来说这是一种取巧（或者说偷懒）的办法。因为GET原本是被设计用于获取数据的（HTTP协议中指出：GET和HEAD方法仅仅应该获取资源而不是执行动作）。但是GET的使用比较简单，使用POST需要在网页上创建表单，相对而言比较麻烦，所以大家就这么做了。
举个不太恰当的例子就是：POST是笔，被设计用来写字的。GET是口红，不是被设计用来写字的，但是有时候也被用来写字了。
但是仍然需要指出，使用GET代替POST并不是一个好习惯。因为GET操作可能会被一些设计粗糙的系统不正确地缓存，这会导致相应的请求没有被执行。同时，使用GET代替POST也容易产生XSS问题。

从HTTP协议规范上来说，xelz已经回答了。HTTP协议没有明确说明GET不允许带消息体（我简单查阅了一下似乎是没有，如有错误请指出），但是也没有定义GET消息体的任何功用。所以目前Web服务器接收到带有消息体的GET请求也能够正确地处理，但是消息体会被忽略。

抓包的时候可以发现：
get一般就1到2个tcp包（信息头和数据都在一起，如果信息头内容很多就会产生2个或者多个包），而post至少2个包（第一个包是信息头，第二个才是数据）。

前面对restful的概念都说的很清楚了，我这里补充一点,下面是个get请求， 我这里就懒得抓包了，直接在chrome的console中拷贝来的，你说的从报文的方式分析， 我可以直接告诉你本质区别
我觉得get和post的本质区别应该是参数放在哪里的区别，

get是放在header中的（所以长度有限制，是浏览器对url长度的限制），post是放在body中的（长度没有限制），

如果你问我header和body有什么区别，我也只能呵呵了（建议自己抓包看）， 都是tcp数据流，header和body是 两个 /r/n 分开的

 get  Remote Address:222.186.132.183:80
Request URL:http://qiniu-plupload.qiniudn.com/bb.png?imageView2/1/w/100/h/100
Request Method:GET
Status Code:200 OK
Response Headers
view source
Accept-Ranges:bytes
Access-Control-Allow-Origin:*
Access-Control-Max-Age:2592000
Cache-Control:public, max-age=31536000
Connection:keep-alive
Content-Length:15509
Content-Type:image/png
Date:Wed, 29 Apr 2015 07:01:08 GMT
ETag:"ALCDKnR1WgNfUxiMBRwEuXoe76OQ"
Server:nginx/1.4.4
X-Log:mc.g/404;mc.g:2;RS:2;mc.s;DC/404;FOPDC/404;FOPAGENT;IMAGE:239;FOPAGENT:240;FOPAGENT;IMAGE:239;FOPAGENT:240;FOPG:241;FOPAGENT;IO:249
X-Qiniu-Zone:0
X-Reqid:YVQAABBhtnn3adkT
X-Via:1.1 tzh57:8110 (Cdn Cache Server V2.0), 1.1 zhenjiang157:10 (Cdn Cache Server V2.0)
X-Whom:nb263
Request Headers
view source
Accept:image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:zh-CN,zh;q=0.8
Cache-Control:no-cache
Connection:keep-alive
Host:qiniu-plupload.qiniudn.com
Pragma:no-cache
RA-Sid:DE49CAE2-20141215-034718-ab4eeb-10884d
RA-Ver:2.10.0
Referer:http://jssdk.demo.qiniu.io/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36
Query String Parameters
view source
view URL encoded
imageView2/1/w/100/h/100:

 Remote Address:183.136.139.10:80
Request URL:http://up.qiniu.com/
Request Method:POST
Status Code:200 OK
Response Headers
view source
Access-Control-Allow-Headers:X-File-Name, X-File-Type, X-File-Size
Access-Control-Allow-Methods:OPTIONS, HEAD, POST
Access-Control-Allow-Origin:*
Access-Control-Max-Age:2592000
Cache-Control:no-store, no-cache, must-revalidate
Connection:keep-alive
Content-Length:54
Content-Type:application/json
Date:Wed, 29 Apr 2015 07:01:08 GMT
Pragma:no-cache
Server:nginx/1.4.4
X-Content-Type-Options:nosniff
X-Log:s.ph;s.put.tw;s.put.tr:5;s.put.tw:1;s.put.tr:4;s.ph;s.put.tw:1;s.put.tr:5;s.ph;PFDS:12;PFDS:13;PFDS:14;rdb.g/no such key;DBD/404;DBG/404;v4.exist:1/Document not found;rs12_9.ins;qtbl.ins:2;mc.s;RS:3;rs.put:4;rs-upload.putFile:20;UP:27
X-Reqid:-zwAABHcpXL3adkT
Request Headers
view source
Accept:*/*
Accept-Encoding:gzip, deflate
Accept-Language:zh-CN,zh;q=0.8
Cache-Control:no-cache
Connection:keep-alive
Content-Length:620773
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryb5PfXDf4M1oCl5QM
Host:up.qiniu.com
Origin:http://jssdk.demo.qiniu.io
Pragma:no-cache
RA-Sid:DE49CAE2-20141215-034718-ab4eeb-10884d
RA-Ver:2.10.0
Referer:http://jssdk.demo.qiniu.io/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36
Request Payload
------WebKitFormBoundaryb5PfXDf4M1oCl5QM
Content-Disposition: form-data; name="name"

bb.png
------WebKitFormBoundaryb5PfXDf4M1oCl5QM
Content-Disposition: form-data; name="chunk"

0
------WebKitFormBoundaryb5PfXDf4M1oCl5QM
Content-Disposition: form-data; name="chunks"

1
------WebKitFormBoundaryb5PfXDf4M1oCl5QM
Content-Disposition: form-data; name="key"

bb.png
------WebKitFormBoundaryb5PfXDf4M1oCl5QM
Content-Disposition: form-data; name="token"

0MLvWPnyya1WtPnXFy9KLyGHyFPNdZceomLVk0c9:d5M0tc6IYvvXMsWeqXN-_cJHEd0=:eyJzY29wZSI6InFpbml1LXBsdXBsb2FkIiwiZGVhZGxpbmUiOjE0MzAyOTQ0NDd9
------WebKitFormBoundaryb5PfXDf4M1oCl5QM
Content-Disposition: form-data; name="file"; filename="bb.png"
Content-Type: image/png


------WebKitFormBoundaryb5PfXDf4M1oCl5QM--

我觉得get和post的本质区别应该是参数放在哪里的区别，

get是放在header中的（所以长度有限制，是浏览器对url长度的限制），post是放在body中的（长度没有限制），

我这里贴的post是form-data 格式的，

有很多人会把post中的 x-www-form-urlencoded方式 和get 请求搞混，因为在服务端，好多语言框架对这两种请求获取参数的方式差不多

下面可以看一下 x-www-form-urlencoded 方式

 

 POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8

title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

这篇文章 讲的很清楚