在了解get、POST区别之前先了解一下http协议。
1. Http协议简介
1．什么是Http协议
HTTP，超文本传输协议（HyperText Transfer Protocol)是互联网上应用最为广泛的 一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。是建立在TCP/IP协议之上的应用层规范。
2．Http协议的组成
Http协议由Http请求和Http响应组成，当在浏览器中输入网址访问某个网站时， 你的浏览器会将你的请求封装成一个Http请求发送给服务器站点，服务器接收到请 求后会组织响应数据封装成一个Http响应返回给浏览器。即没有请求就没有响应。
3.Http请求
编辑一个form.html的表单页面，如下：
<!doctype html> <html> <head> <meta http-equiv="Content-Type" contexnt="text/html; charset=UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> </head> <body style="font-size: 40px; text-align: center;"> <form action="/weixin/test/test.html" method="post"> <input name="name" value="zs"/> <input name="age" value="25"/> <input type="submit"/> </form> </body> </html>
点击提交按钮，用抓包工具分析：
1）请求行
请求方式：POST、GET
请求的资源：/DemoEE/form.html
协议版本：HTTP/1.1
HTTP/1.0，发送请求，创建一次连接，获得一个web资源，连接断开。
HTTP/1.1，发送请求，创建一次连接，获得多个web资源，保持连接。
2）请求头
请求头是客户端发送给服务器端的一些信息，使用键值对表示key：value
|
常见请求头 |
描述 （红色掌握，其他了解） |
|
Referer |
浏览器通知服务器，当前请求来自何处。如果是直接访问，则不会有这个头。常用于：防盗链 |
|
If-Modified-Since |
浏览器通知服务器，本地缓存的最后变更时间。与另一个响应头组合控制浏览器页面的缓存。 |
|
Cookie |
与会话有关技术，用于存放浏览器缓存的cookie信息。 |
|
User-Agent |
浏览器通知服务器，客户端浏览器与操作系统相关信息 |
|
Connection |
保持连接状态。Keep-Alive 连接中，close 已关闭 |
|
Host |
请求的服务器主机名 |
|
Content-Length |
请求体的长度 |
|
Content-Type |
如果是POST请求，会有这个头，默认值为application/x-www-form-urlencoded，表示请求体内容使用url编码 |
|
Accept： |
浏览器可支持的MIME类型。文件类型的一种描述方式。 MIME格式：大类型/小类型[;参数] 例如： text/html ，html文件 text/css，css文件 text/javascript，js文件 image/*，所有图片文件 |
|
Accept-Encoding |
浏览器通知服务器，浏览器支持的数据压缩格式。如：GZIP压缩 |
|
Accept-Language |
浏览器通知服务器，浏览器支持的语言。各国语言（国际化i18n） |
3）请求体
当请求方式是post的时，请求体会有请求的参数，格式如下：
name=zs&age=25
(4)如果请求方式为get，那么请求参数不会出现在请求体中，会拼接在url地址后面(默认为Get方式)
<!doctype html> <html> <head> <meta http-equiv="Content-Type" contexnt="text/html; charset=UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> </head> <body style="font-size: 40px; text-align: center;"> <form action="/weixin/test/test.html"> <input name="name" value="zs"/> <input name="age" value="25"/> <input type="submit"/> </form> </body> </html>
结果：
4．Http响应
1）响应行
Http协议
状态码：
常用的状态码如下：
200 ：请求成功。
302 ：请求重定向。
304 ：请求资源没有改变，访问本地缓存。
404 ：请求资源不存在。通常是用户路径编写错误，也可能是服务器资源已删除。
500 ：服务器内部错误。通常程序抛异常。
状态信息：状态信息是根据状态码变化而变化的
2）响应头
响应也都是键值对形式，服务器端将信息以键值对的形式返回给客户端
|
常见请求头 |
描述 |
|
Location |
指定响应的路径，需要与状态码302配合使用，完成跳转。 |
|
Content-Type |
响应正文的类型（MIME类型） 取值：text/html;charset=UTF-8 |
|
Content-Disposition |
通过浏览器以下载方式解析正文 取值：attachment;filename=xx.zip |
|
Set-Cookie |
与会话相关技术。服务器向浏览器写入cookie |
|
Content-Encoding |
服务器使用的压缩格式 取值：gzip |
|
Content-length |
响应正文的长度 |
|
Refresh |
定时刷新，格式：秒数;url=路径。url可省略，默认值为当前页。 取值：3;url=www.itcast.cn //三秒刷新页面到www.itcast.cn |
|
Server |
指的是服务器名称，默认值：Apache-Coyote/1.1。可以通过conf/server.xml配置进行修改。<Connector port="8080" ... server="itcast"/> |
|
Last-Modified |
服务器通知浏览器，文件的最后修改时间。与If-Modified-Since一起使用。 |
3）响应体
响应体是服务器回写给客户端的页面正文，浏览器将正文加载到内存，然后解析渲染 显示页面内容
2. GET和POST区别
两种最常用的 HTTP 方法是：GET 和 POST。
在客户机和服务器之间进行请求-响应时，两种最常被用到的方法是：GET 和 POST。
- GET - 从指定的资源请求数据。
- POST - 向指定的资源提交要被处理的数据
1. 比较 GET 与 POST(w3school描述如下)
下面的表格比较了两种 HTTP 方法：GET 和 POST。
| GET | POST | |
|---|---|---|
| 后退按钮/刷新 | 无害 | 数据会被重新提交（浏览器应该告知用户数据会被重新提交）。 |
| 书签 | 可收藏为书签 | 不可收藏为书签 |
| 缓存 | 能被缓存 | 不能缓存 |
| 编码类型 | application/x-www-form-urlencoded | application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。 |
| 历史 | 参数保留在浏览器历史中。 | 参数不会保存在浏览器历史中。 |
| 对数据长度的限制 | 是的。当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。 | 无限制。 |
| 对数据类型的限制 | 只允许 ASCII 字符。 | 没有限制。也允许二进制数据。 |
| 安全性 |
与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。 在发送密码或其他敏感信息时绝不要使用 GET ！ |
POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。 |
| 可见性 | 数据在 URL 中对所有人都是可见的。 | 数据不会显示在 URL 中。 |
现在我们知道了两种方法本质上是 TCP 连接，没有区别。但如果不按规范来也是可以的，可以在 URL 上写参数，然后方法使用 POST；也可以在 Body 写参数，然后方法使用 GET。当然，这需要服务端支持。
2. 更多可能的问题：
(1)方法参数写法是固定的吗？
在约定中，我们的参数是写在 ? 后面，用 & 分割。我们知道，解析报文的过程是通过获取 TCP 数据，用正则等工具从数据中获取 Header 和 Body，从而提取参数。
比如header请求头中添加token，来验证用户是否登录等权限问题。
也就是说，我们可以自己约定参数的写法，只要服务端能够解释出来就行。
(2)GET 方法的长度限制是怎么回事？
首先说明一点，HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大多是浏览器和服务器的原因。
浏览器原因就不说了，服务器是因为处理长 URL 要消耗比较多的资源，为了性能和安全（防止恶意构造长 URL 来攻击）考虑，会给 URL 长度加限制。
(3)POST 方法比 GET 方法安全？
有人说POST 比 GET 安全，因为数据在地址栏上不可见。然而，从传输的角度来说，他们都是不安全的，因为 HTTP 在网络上是明文传输的，只要在网络节点上捉包，就能完整地获取数据报文。要想安全传输，就只有加密，也就是 HTTPS。
其他 HTTP 请求方法
下面的表格列出了其他一些 HTTP 请求方法：
| 方法 | 描述 |
|---|---|
| HEAD | 与 GET 相同，但只返回 HTTP 报头，不返回文档主体。 |
| PUT | 上传指定的 URI 表示。 |
| DELETE | 删除指定资源。 |
| OPTIONS | 返回服务器支持的 HTTP 方法。 |
| CONNECT | 把请求连接转换到透明的 TCP/IP 通道。 |
补充：post的四种提交方式
协议规定 POST提交的数据必须放在消息主体（entity-body）中，但协议并没有规定数据必须使用什么编码方式。
后端代码如下：
/** * 接收表单数据(这里用request直接接收) * * @param request * @return */ @RequestMapping("/test") @ResponseBody public String test(HttpServletRequest request, HttpServletResponse response) { String method = request.getMethod(); System.out.println("request.getMethod(): " + method); Enumeration<String> parameterNames = request.getParameterNames(); while (parameterNames.hasMoreElements()) { String parameterName = (String) parameterNames.nextElement(); String parameterValue = request.getParameter(parameterName); System.out.println(" parameterName: " + parameterName + " , parameterValue: " + parameterValue + " "); } return "success"; }
测试四种提交方式：
1. application/x-www-form-urlencoded
这应该是最常见的 POST 提交数据的方式了。浏览器的原生 form 表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 提交数据。
<form action="/weixin/test/test.html" method="post">
<input name="name" value="zs-张三"/>
<input name="age" value="25"/>
<input type="submit"/>
</form>
结果：
后台：
request.getMethod(): POST
parameterName: name , parameterValue: zs-张三
parameterName: age , parameterValue: 25
很多时候，我们用 Ajax 提交数据时，也是使用这种方式。例如 JQuery 的 Ajax，Content-Type 默认值都是「application/x-www-form-urlencoded;charset=utf-8」，当然可以自己指定。
2. multipart/form-data
这又是一个常见的 POST 数据提交的方式。我们使用表单上传文件时，必须让 form 的 enctyped 等于这个值。
<form action="/weixin/test/test.html" method="post" enctype="multipart/form-data"> <input name="name" value="zs-张三"/> <input name="age" value="25"/> <input name="file" type="file"/> <input type="submit"/> </form>
结果：
3. application/json
application/json 这个 Content-Type 作为响应头大家肯定不陌生。实际上，现在越来越多的人把它作为请求头，用来告诉服务端消息主体是序列化后的 JSON 字符串。由于JSON 规范的流行，除了低版本 IE 之外的各大浏览器都原生支持 JSON.stringify，服务端语言也都有处理 JSON 的函数，使用 JSON 不会遇上什么麻烦。
这种一般在JSON中发送的形式比较多，例如：
function submitForm() { var jsonObj = {"name": "zs-张三", "age": "25"}; jsonObj = JSON.stringify(jsonObj); $.ajax({ url: '/weixin/test/test.html', data: jsonObj, type: "POST", contentType: 'application/json' }); }
后端代码：
/** * 接收表单数据(这里用request直接接收) * * @param request * @return */ @RequestMapping("/test") @ResponseBody public String test(@RequestBody String json) { System.out.println(json); return "success"; }
结果：
后端结果：
{"name":"zs-张三","age":"25"}
4. text/xml
它是一种使用 HTTP 作为传输协议，XML 作为编码方式的远程调用规范。
补充：持久链接
我们知道 HTTP 协议采用“请求-应答”模式，当使用普通模式，即非 Keep-Alive 模式时，每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（HTTP协议为无连接的协议）；当使用 Keep-Alive 模式（又称持久连接、连接重用）时，Keep-Alive 功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive 功能避免了建立或者重新建立连接。当客户端发送另外一个请求时，就使用这条已经建立的连接。
HTTP Keep-Alive 简单说就是保持当前的TCP连接，避免了重新建立连接。
HTTP 长连接不可能一直保持，例如响应头中的Keep-Alive: timeout=5, max=100，表示这个TCP通道可以保持5秒，max=100，表示这个长连接最多接收100次请求就断开。
(1)对于Http1.0
使用HTTP/1.0的客户端在首部中加上”Connection:Keep-Alive”，请求服务端将一条连接保持在打开状态。服务端如果愿意将这条连接保持在打开状态，就会在响应中包含同样的首部。如果响应中没有包含”Connection:Keep-Alive”首部，则客户端会认为服务端不支持keep-alive，会在发送完响应报文之后关闭掉当前连接。
(2)对于Http 1.1
HTTP/1.1采取持久连接的方式替代了Keep-Alive。HTTP/1.1的连接默认情况下都是持久连接。如果要显式关闭，需要在报文中加上Connection:Close首部。
即在HTTP/1.1中，所有的连接都进行了复用。
例如：
(1)关闭长连接：
response.setHeader("Connection", "close");
(2)将长链接限定为94个请求
response.setHeader("Keep-Alive", "timeout=5, max=94");
通过wireshark抓包分析长链接。