1.GET请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割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包的包体中。
简而言之：GET把参数包含在URL中，POST通过request body传递参数。
2.根据HTTP规范，GET用于信息获取，而且应该是安全的和幂等的。
(1).所谓安全的意味着该操作用于获取信息而非修改信息。换句话说，GET 请求一般不应产生副作用。就是说，它仅仅是获取资源信息，就像数据库查询一样，不会修改，增加数据，不会影响资源的状态。
* 注意：这里安全的含义仅仅是指是非修改信息。
(2).幂等的意味着对同一URL的多个请求应该返回同样的结果。这里我再解释一下幂等这个概念：
3.GET请求在URL中传送的参数是有长度限制的，而POST没有
(1).首先是"GET方式提交的数据最多只能是1024字节"，因为GET是通过URL提交数据，那么GET可提交的数据量就跟URL的长度有直接关系了。而实际上，URL不存在参数上限的问题，HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。
注意这是限制是整个URL长度，而不仅仅是你的参数值数据长度。[见参考资料5]
(2).理论上讲，POST是没有大小限制的，HTTP协议规范也没有进行大小限制，说“POST数据量存在80K/100K的大小限制”是不准确的，POST数据是没有限制的，起限制作用的是服务器的处理程序的处理能力。
简而言之：GET请求发送数据更小。
4.GET请求会被浏览器主动cache，而POST不会，除非手动设置。
5.GET请求只能进行url编码，而POST支持多种编码方式。
6.GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
7.对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
8.POST的安全性要比GET的安全性高。注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改，而这里安全的含义是真正的Security的含义，比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存，(2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET提交数据还可能会造成Cross-site request forgery（注释1）攻击。
9.GET产生一个TCP数据包；POST产生两个TCP数据包。
长的说：
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。
因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑！跳入需谨慎。为什么？
1. GET与POST都有自己的语义，不能随便混用。
2. 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。
3. 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。
注释1：跨站请求伪造（Cross Site Request Forgery (CSRF)）
跨站请求伪造（Cross Site Request Forgery (CSRF)）也被称为：one click attack/session riding，缩写为：CSRF/XSRF，是一种挟制终端用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。攻击人员通过一些手段让终端用户点击存在攻击的链接或者页面，例如攻击人员通过xss漏洞在终端用户的页面中执行，或者将这个代码放在一个具有诱惑性的页面中，亦或者将链接直接放在论坛帖子中。
CSRF攻击原理
1. 用户登录可信任的网站A（存在缺陷的交易网站）；
2. 网站A返回登录session信息并将session存储在本地cookie；
3. 用户访问其他网站B（论坛、好友发送页面），网站B中包含执行网站A相关操作的请求操作(转账URL、退款URL)并且能够直接执行；
4. 网站B页面加载过程中携带网站A的cookie将请求发送到网站A的服务器；
5. 网站A服务器根据请求校验用户信息后执行具体操作(资金损失)，从而达到了模拟用户在网站A的相关操作使用户或者网站A遭受伤害或损失。
下图为一具体的流程：
图1 CSRF原理示例
用户被攻击的两个条件是：
1. 登录了网站A并在本地保存了cookie；
2. 在未退出网站A或者清除cookie的情况下访问了网站B，并且在网站B帮助用户向网站A提交了请求。
CSRF防御
1. token校验
用户进行操作交互前先构造一个token值(随机数)，后续每次操作请求必须带上token值，服务器校验token合法后才进行相关操作，这样黑客因为无法提前获知用户的token，就无法构造出正确的操作URL。加上token后操作URL必须带上一随机值，如下：
http://www.xxxxx.com/changeprice?orderId=123456789&fromprice=100.00&toPrice=0.01&t=rand()
按照之前的攻击执行结果如下：
坏人因为没有小白的token信息，因此伪造的URL是不能被服务器处理的，从而导致阴谋无法得逞。
这个方法已经可以杜绝99%的CSRF攻击，由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，这就另外的1%。一般的攻击者看到有需要算token值，基本都会放弃了，某些除外，所以如果需要100%的杜绝，这个不是最好的方法。
(2).验证码
这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串，这个方案可以完全解决CSRF，但在易用性方面似乎不是太好。