curl 模拟 GET\POST 请求，以及 curl post 上传文件
 
一般情况下，我们调试数据接口，都会使用一个 postman 的工具，但是这个工具还是有点大了。事实上，我们在调试一些小功能的时候，完全没有必要使用它。在命令行中，我们使用 curl 这个工具，完全可以满足我们轻量的调试要求。
 
下面，我们来简单的说一下，curl 的一些常见使用方法：
 
curl GET 请求
 
curl命令 + 请求接口的地址。
 
curl localhost:9999/api/daizhige/article
 
如上，我们就可以请求到我们的数据了，如果想看到详细的请求信息，我们可以加上 -v 参数
 
curl localhost:9999/api/daizhige/article -v
 
操作结果如下图所示：
 
 
curl POST 请求
 
我们可以用 -X POST 来申明我们的请求方法，用 -d 参数，来传送我们的参数。
 
 
 
所以，我们可以用 -X PUT 和 -X DELETE 来指定另外的请求方法。
 
 
curl localhost:9999/api/daizhige/article -X POST -d "title=comewords&content=articleContent"
 
如上，这就是一个普通的 post 请求。
 
但是，一般我们的接口都是 json 格式的，这也没有问题。我们可以用 -H 参数来申明请求的 header
 
curl localhost:9999/api/daizhige/article -X POST -H "Content-Type:application/json" -d '{"title":"comewords","content":"articleContent"}'
 
 
 
so, 我们可以用 -H 来设置更多的 header 比如，用户的 token 之类的。
 
 
同样，我们可以用 -v 来查看详情。
 
 
curl POST 上传文件
 
上面的两种请求，都是只传输字符串，我们在测试上传接口的时候，会要求传输文件，其实这个对于 curl 来说，也是小菜一碟。
 
我们用 -F "file=@__FILE_PATH__" 的请示，传输文件即可。命令如下：
 
curl localhost:8000/api/v1/upimg -F "file=@/Users/fungleo/Downloads/401.png" -H "token: 222" -v
 
执行结果如下图所示：
 
 
更多 curl 的使用方法，以及参数说明，可以在系统中输入 man curl 来进行查看。或者，点击 curl man 查看网页版的介绍。
 
 
 
所以，我们可以用 man 命令名称 来查看更多的工具的介绍。当然，一些非主流的命令行工具，应该是没有相关的介绍的。
 
 
可能你会感觉用这些命令才进行操作，感觉破烦。但是，当你仅仅需要请求一个接口，进行一个轻量的操作的时候，是顺手在终端中输入一个命令来得方便，还是打开一个重型的图形工具来得方便呢？
 
命令行是可以保存历史记录的，我们使用 ctrl+r 快捷键可以进行历史命令搜索，这样，我们可以非常方便的重复进行命令调试。
 
我现在已经养成了在终端中写代码，跑代码，以及调试代码的习惯，我感觉这样非常方便。
 
当然，我的想法不一定是正确的，但是依然希望，能够对看官有所帮助。
 
本文由 FungLeo 原创，允许转载，但转载必须保留首发链接。
 
 
2020年04月27日补充
 
我没想到这篇博文有这么大的阅读量。文中所表述的 curl 的使用虽然关键点都已经涉及到了，但是如何更加优雅的使用，并没有涉及。如果你对这部分内容感兴趣，可以阅读我的这篇博文 《linux 或 mac 命令行更优雅的使用 curl 命令，以及命令行常用的快捷键说明》，相信各位看官在看过这篇文章之后，对于 curl 命令的使用，会更加的舒服、优雅哦！

效率工具传送门
 
 
推荐20套实战源码
 
 
程序员你可以考虑安装的15款谷歌插件
 
 
99%的人不知道搜索引擎的6个技巧
 
 
12款好用的Visual Studio插件，最后一款良心推荐
 
 
IT界知名的程序员曾说：对于那些月薪三万以下，自称IT工程师的码农们，其实我们从来没有把他们归为我们IT工程师的队伍。他们虽然总是以IT工程师自居，但只是他们一厢情愿罢了。

 此话一出，不知激起了多少(码农)程序员的愤怒，却又无可奈何，于是码农问程序员。
 
码农：你知道get和post请求到底有什么区别？
 程序员：你看这篇就知道了。
 码农：你月薪三万了？
 程序员：嗯。
 码农：你是怎么做到的?
 程序员：我做梦做到的
 
前言
 
这个问题几乎面试的时候都会问到，是一个老生常谈的话题，然而随着不断的学习，对于以前的认识有很多误区，所以还是需要不断地总结的，学而时习之，不亦说乎。

 关于get和post如果你有条件上百度的话，至少有200百万条结果，每个人都有每个人的思考，当然，这篇也是我的思考，如果有些结论有错误，希望能够喷起来。在批评中不断改进，与诸君共勉一句话：若批评无意义，则赞美无意义。
 

 
文章目录
 
前言
01 特点
1.1 http的特点
1.2 请求方法
1.3 我们耳熟能详的的区别
  
  
02 常见的误区
2.1 误区一
2.2 误区二
2.3 误区三
2.4 误区四：“GET产生一个TCP数据包；POST产生两个TCP数据包。”
  
  
3 http状态码附录
3.1 状态码1xx
3.2 状态码2xx:成功
3.3 状态码3xx:重定向
3.4 状态码4xx:客户端错误
3.5 状态码5** 服务端错误
  
 

 
01 特点
 
1.1 http的特点
 
基于tcp/ip、一种网络应用层协议、超文本传输协议HyperText Transfer Protocol
工作方式：客户端请求服务端应答的模式
快速：无状态连接
灵活：可以传输任意对象，对象类型由Content-Type标记
客户端请求request消息包括以下格式：请求行（request line）、请求头部（header）、空行、请求数据
 
 服务端响应response也由四个部分组成，分别是：状态行、消息报头、空行、响应正文
 
 
1.2 请求方法
 
http请求可以使用多种请求方法。
 HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
 
HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
 
HTTP2.0 新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
 
多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
 
header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
 
服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。
 参考链接：https://baike.baidu.com/item/HTTP%202.0/12520156?fr=aladdin
 
1 GET 请求指定的页面信息，并返回实体主体。
2 HEAD 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
3 POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
4 PUT 从客户端向服务器传送的数据取代指定的文档的内容。
5 DELETE 请求服务器删除指定的页面。
6 CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
7 OPTIONS 允许客户端查看服务器的性能。
8 TRACE 回显服务器收到的请求，主要用于测试或诊断。
 
1.3 我们耳熟能详的的区别
 
http协议最常见的两种方法GET和POST，这几点答案其实有几点并不准确
 
 
请求缓存：GET 会被缓存，而post不会
 
 
收藏书签：GET可以，而POST不能
 
 
保留浏览器历史记录：GET可以，而POST不能
 
 
用处：get常用于取回数据，post用于提交数据
 
 
安全性：post比get安全
 
 
请求参数：querystring 是url的一部分get、post都可以带上。 get的querystring（仅支持urlencode编码），post的参数是放在body（支持多种编码）
 
 
请求参数长度限制：get请求长度最多1024kb，post对请求数据没有限制
 
 
02 常见的误区
 

 get和post误区
 针对上面常见的区别，如果面试的时候这么说，肯定是有很大的毛病，刚在学校面试的时候也曾经囫囵吞枣地这样说过，现在回过头再想以前的错误认知，又有许多新的认识。
 
2.1 误区一
 
“用处：get常用于取回数据，post用于提交数据”
 
曾听到过这样一种说法：get替换post来优化网站性能，虽然这种说法没错，也的确get常被用于取回数据，但是post也被一些ui框架使用于取回数据，比如kendo ui中的grid，就是用post来接受数据的。所以结论是get、post用途也是因地制宜。如果你有使用过kendo UI，会发现分页、过滤、自定义的参数都包含在form data里面。
 
请求参数
 get是querystring（仅支持urlencode编码），post是放在body（支持多种编码）
 query参数是URL的一部分，而GET、POST等是请求方法的一种，不管是哪种请求方法，都必须有URL，而URL的query是可选的，可有可无。
 
2.2 误区二
 
“请求参数长度限制：get请求长度最多1024kb，post对请求数据没有限制”
 
这句话看上去实在没毛病啊，菜鸟教程也是这样说的啊。虽然字面意思上没有错误，但是理解一定要正确。我想说的是GET方法提交的url参数数据大小没有限制，在http协议中没有对url长度进行限制（不仅仅是querystring的长度），这个限制是特定的浏览器及服务器对他的限制
 
下面就是对各种浏览器和服务器的最大处理能力做一些说明
 
IE浏览器对URL的最大限制为2083个字符
Firefox (Browser)：对于Firefox浏览器URL的长度限制为65,536个字符。
Safari (Browser)：URL最大长度限制为 80,000个字符。
Opera (Browser)：URL最大长度限制为190,000个字符。
Google (chrome)：URL最大长度限制为8182个字符。
Apache (Server)：能接受最大url长度为8,192个字符。
Microsoft Internet Information Server(IIS)：能接受最大url的长度为16,384个字符。
 
所以为了符合所有标准，url的最好不好超过最低标准的2083个字符（2k+35）。当然在做客户端程序时，url并不展示给用户，只是个程序调用，这时长度只收web服务器的影响了。对于中文的传递，一个汉字最终编码后的字符长度是9个字符。
 
最常见的form表单，浏览器默认的form表单，默认的content-type是application/x-www-form-urlencoded,提交的数据会按照key value的方式，jquery的ajax默认的也是这种content-type。当然在post方式中添加querystring一定是可以接收的到，但是在get方式中加body参数就不一定能成功接收到了。
 
2.3 误区三
 
“post比get安全性要高”
 
这里的安全是相对性，并不是真正意义上的安全，通过get提交的数据都将显示到url上，页面会被浏览器缓存，其他人查看历史记录会看到提交的数据，而post不会。另外get提交数据还可能会造成CSRF攻击。
 
2.4 误区四：“GET产生一个TCP数据包；POST产生两个TCP数据包。”
 
这一点理解起来还是有一定难度的,实际上，不论哪一种浏览器，在发送 POST 的时候都没有带 Expect 头，server 也自然不会发 100 continue。通过抓包发现，尽管会分两次，body 就是紧随在 header 后面发送的，根本不存在『等待服务器响应』这一说。
 从另一个角度说，TCP 是传输层协议。别人问你应用层协议里的 GET 和 POST 有啥区别，你回答说这俩在传输层上发送数据的时候不一样，确定别人不抽你？
 参考资料：https://zhuanlan.zhihu.com/p/25028045
 
3 http状态码附录
 
3.1 状态码1xx
 
100 Continue：
 服务器仅接收到部分请求，但是一旦服务器并没有拒绝该请求，客户端应该继续发送其余的请求。
101 Switching Protocols：
 服务器转换协议：服务器将遵从客户的请求转换到另外一种协议。
102: 由WebDAV（RFC 2518）：
 扩展的状态码，代表处理将被继续执行
 
3.2 状态码2xx:成功
 
200 OK：
 请求成功（其后是对GET和POST请求的应答文档。）
201 Created：
 请求被创建完成，同时新的资源被创建。
202 Accepted：
 供处理的请求已被接受，但是处理未完成。
203 Non-authoritative Information：
 文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝。
204 No Content：
 没有新文档。浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的。
205 Reset Content：
 没有新文档。但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容。
206 Partial Content：
 客户发送了一个带有Range头的GET请求，服务器完成了它。
 
3.3 状态码3xx:重定向
 
300 Multiple Choices：
 多重选择。链接列表。用户可以选择某链接到达目的地。最多允许五个地址。
301 Moved Permanently：
 所请求的页面已经转移至新的url
302 Found：
 所请求的页面已经临时转移至新的url。
303 See Other：
 所请求的页面可在别的url下被找到。
304 Not Modified：
 未按预期修改文档。客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。
305 Use Proxy：
 客户请求的文档应该通过Location头所指明的代理服务器提取。
306 Unused：
 此代码被用于前一版本。目前已不再使用，但是代码依然被保留。
307 Temporary Redirect：
 被请求的页面已经临时移至新的url。
 
3.4 状态码4xx:客户端错误
 
400 Bad Request：
 服务器未能理解请求。
401 Unauthorized：
 被请求的页面需要用户名和密码。
401.1：
 登录失败。
401.2：
 服务器配置导致登录失败。
401.3：
 由于 ACL 对资源的限制而未获得授权。
401.4：
 筛选器授权失败。
401.5：
 ISAPI/CGI 应用程序授权失败。
401.7：
 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。
402 Payment Required：
 此代码尚无法使用。
403 Forbidden：
 对被请求页面的访问被禁止。
404 Not Found:
 服务器无法找到被请求的页面。
405 Method Not Allowed:
 请求中指定的方法不被允许。
406 Not Acceptable:
 服务器生成的响应无法被客户端所接受。
407 Proxy Authentication Required:
 用户必须首先使用代理服务器进行验证，这样请求才会被处理。
408 Request Timeout:
 请求超出了服务器的等待时间。
409 Conflict:
 由于冲突，请求无法被完成。
410 Gone:
 被请求的页面不可用。
411 Length Required:
 “Content-Length” 未被定义。如果无此内容，服务器不会接受请求。
412 Precondition Failed:
 请求中的前提条件被服务器评估为失败。
413 Request Entity Too Large:
 由于所请求的实体的太大，服务器不会接受请求。
414 Request-url Too Long:
 由于url太长，服务器不会接受请求。当post请求被转换为带有很长的查询信息的get请求时，就会发生这种情况。
415 Unsupported Media Type:
 由于媒介类型不被支持，服务器不会接受请求。
416 Requested Range Not Satisfiable:
 服务器不能满足客户在请求中指定的Range头。
417 Expectation Failed:
 执行失败。
423:
 锁定的错误。
 
3.5 状态码5** 服务端错误
 
500 Internal Server Error：
 请求未完成。服务器遇到不可预知的情况。
501 Not Implemented：
 请求未完成。服务器不支持所请求的功能。
502 Bad Gateway：
 请求未完成。服务器从上游服务器收到一个无效的响应。
503 Service Unavailable：
 请求未完成。服务器临时过载或宕机。
504 Gateway Timeout：
 网关超时。
505 HTTP Version Not Supported：
 服务器不支持请求中指明的HTTP协议版本。
 
 
 
作者信息：
 【文章信息】：作者-张林:原文链接-https://blog.csdn.net/kebi007/article/details/103175193
 【原创公众号】：dotNet全栈开发。好文目录
 版权声明：本文为CSDN博主「dotNet全栈开发」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
 

一、http post
 
对于文件上传，客户端通常就是页面，在页面里实现上传文件不是什么难事，写个form,加上enctype = "multipart/form-data",在写个接收的就可以了，没什么难的。如：
 
<!DOCTYPE html>  
<html>  
<head>  
<title>Hello World!</title>  
</head>  
<body>  
    <form method="POST" enctype="multipart/form-data" action="/XXX">   
           <p>文件1：<input type="file" name="file1" /></p>  
           <p>文件：<input type="file" name="file" /></p>  
           <p>其他信息：<input name="luid" /></p>  
           <p><input type="submit" value="上传" /></p>  
    </form>
</body>  
</html>  
 
 
如果要用java.net.HttpURLConnection来实现文件上传，还真有点搞头，实现思路和具体步骤就是模拟页面的请求，页面发出的格式如下：
 
-----------------------------7da2e536604c8  
Content-Disposition: form-data; name="luid"  
  
123  
-----------------------------7da2e536604c8  
Content-Disposition: form-data; name="file1"; filename="D:\haha.txt"  
Content-Type: text/plain  
  
haha  
  hahaha  
-----------------------------7da2e536604c8  
Content-Disposition: form-data; name="file"; filename="D:\huhu.png"  
Content-Type: application/octet-stream  
  
这里是图片的二进制数据 
-----------------------------7da2e536604c8--
上面username是form表单中的文本参数，值为123，file1是form表单中上传的文本文件。file是form表单中上传的其他类型的文件，他们的Content-Type不一样。
 
知道了这些，就可以编写代码来模拟了，这里只上传一个文件file，是张图片，附上代码的截图：
 
 
 
 
 
以上的空行"\r\n"是比较严格的，要换行或者换两行，都是根据格式来的。
 
 
 
二、https post
 
一般都是http的请求，但现在也有越来越多的外部接口采用https的方式来调用。比如这次工作中需要调用的FaceId他们的身份证识别接口，这个接口就是https的，而且传递的参数里还需要身份证照片，这明显是个文件。如下：
 
 
 
 
 
 
java后台发起https的文件上传请求的原理以及整个步骤和http的基本一致，只是这次的URLConnection是HttpsURLConnection，而且由于https的请求需要签名等安全认证，所以会在设置HttpsURLConnection时需要多设置两个属性，如下的setSSLSocketFactory()和setHostnameVerifier()：
 
 
所需要的TrustAnyTrustManager类和TrustAnyHostnameVerifier类代码如下：
 
 
其他的代码就和HttpURLConnection的一样了。
 
 
 
以上的代码都是使用JDK自带的net工具类，然后模拟页面的form发出的请求来完成的，如果想使用HttpClient来完成发送请求也是可以的，并且更加简单明了，不需要自己写模拟的步骤。因为是第三方工具包，需引入对应jar包：
 
<dependency> 
 
         <groupId>org.apache.httpcomponents</groupId> 
 
          <artifactId>httpclient</artifactId> 
 
         <version>4.5.2</version>         
 
</dependency> 
 
<dependency> 
 
         <groupId>org.apache.httpcomponents</groupId> 
 
          <artifactId>httpmime</artifactId> 
 
         <version>4.5.2</version>         
 
  </dependency>
 
编写的代码如下：
 
 
以上代码都是经过测试的测试代码，你可以自己封装好以供自己今后使用(ps：别想复制，代码都是图片，因为我在沙盒内，代码复制不出来0.0)！

GET和POST是HTTP请求的两种基本方法，要说它们的区别，接触过WEB开发的人都能说出一二。
 
 
 
最直观的区别就是GET把参数包含在URL中，POST通过request body传递参数。
 
 
 
你可能自己写过无数个GET和POST请求，或者已经看过很多权威网站总结出的他们的区别，你非常清楚知道什么时候该用什么。
 
 
 
当你在面试中被问到这个问题，你的内心充满了自信和喜悦。
 
 
 
你轻轻松松的给出了一个“标准答案”：
  
 
 
GET在浏览器回退时是无害的，而POST会再次提交请求。
 
 
 
 
GET产生的URL地址可以被Bookmark，而POST不可以。
 
 
 
 
GET请求会被浏览器主动cache，而POST不会，除非手动设置。
 
 
 
 
GET请求只能进行url编码，而POST支持多种编码方式。
 
 
 
 
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
 
 
 
 
GET请求在URL中传送的参数是有长度限制的，而POST么有。
 
 
 
 
对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
 
 
 
 
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
 
 
 
 
GET参数通过URL传递，POST放在Request body中。
 
（本标准答案参考自w3schools）
 
 
 
“很遗憾，这不是我们要的回答！”
 
 
 
请告诉我真相。。。
 
 
 
如果我告诉你GET和POST本质上没有区别你信吗？ 
 

 让我们扒下GET和POST的外衣，坦诚相见吧！
 

 
GET和POST是什么？HTTP协议中的两种发送请求的方法。
 
 
 
HTTP是什么？HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议。
 
 
 
HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。 
 
 
 
那么，“标准答案”里的那些区别是怎么回事？
 
 
 
 
 
 
 
在我大万维网世界中，TCP就像汽车，我们用TCP来运输数据，它很可靠，从来不会发生丢件少件的现象。但是如果路上跑的全是看起来一模一样的汽车，那这个世界看起来是一团混乱，送急件的汽车可能被前面满载货物的汽车拦堵在路上，整个交通系统一定会瘫痪。为了避免这种情况发生，交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别，有GET, POST, PUT, DELETE等等，HTTP规定，当执行GET请求的时候，要给汽车贴上GET的标签（设置method为GET），而且要求把传送的数据放在车顶上（url中）以方便记录。如果是POST请求，就要在车上贴上POST的标签，并把货物放在车厢里。当然，你也可以在GET的时候往车厢内偷偷藏点货物，但是这是很不光彩；也可以在POST的时候在车顶上也放一些数据，让人觉得傻乎乎的。HTTP只是个行为准则，而TCP才是GET和POST怎么实现的基本。
 
 
 
但是，我们只看到HTTP对GET和POST参数的传送渠道（url还是requrest body）提出了要求。“标准答案”里关于参数大小的限制又是从哪来的呢？
 
 
 

  
 
在我大万维网世界中，还有另一个重要的角色：运输公司。不同的浏览器（发起http请求）和服务器（接受http请求）就是不同的运输公司。 虽然理论上，你可以在车顶上无限的堆货物（url中无限加参数）。但是运输公司可不傻，装货和卸货也是有很大成本的，他们会限制单次运输量来控制风险，数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是，（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。超过的部分，恕不处理。如果你用GET服务，在request body偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略，所以，虽然GET可以带request body，也不能保证一定能被接收到哦。
 
 
 
好了，现在你知道，GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。 
 
 
 
你以为本文就这么结束了？
 
 
 
 
我们的大BOSS还等着出场呢。。。
 
 
 
这位BOSS有多神秘？当你试图在网上找“GET和POST的区别”的时候，那些你会看到的搜索结果里，从没有提到他。他究竟是什么呢。。。
 
 
 
GET和POST还有一个重大区别，简单的说：
 
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就只发送一次。
 
 
 
现在，当面试官再问你“GET与POST的区别”的时候，你的内心是不是这样的？
 
 
 
结束！！！
 
原文:https://www.cnblogs.com/logsharing/p/8448446.html
 
想了解更多java基础知识,关注个人微信公众号:小周只会基础
 
(公众号是新申请的,有问题留言就行,后期有时间会完善公众号)