post与get的对比

1.参数

GET传递的参数只能带URL后面，文本格式QueryString，各浏览器一般有长度限制，一般认为是2083，如果有中文字符更短。提交到服务器端的数据量小。

POST可以传递application/x-www-form-urlencoded的类似QueryString、multipart/form-data的二进制报文格式（支持文件信息嵌入报文传输）、纯文本或二进制的body参数。提交到服务器端的数据量大。

2.用途

GET用于从服务器端获取数据，包括静态资源(HTML|JS|CSS|Image等等)、动态数据展示(列表数据、详情数据等等)。

POST用于向服务器提交数据，比如增删改数据，提交一个表单新建一个用户、或修改一个用户等。

3.缓存

GET时默认可以复用前面的请求数据作为缓存结果返回，此时以完整的URL作为缓存数据的KEY。所以有时候为了强制每次请求都是新数据，我们可以在URL后面加上一个随机参数Math.random或时间戳new Date().getTime()、或版本号。

比如abc.com?a=1&rnd=0.123987之类的。这也是目前一些静态资源后面加一个很长的版本号的原因，jquery-min.js?v=13877770表示一个版本，当页面引用jquery-min.js?v=13877771时浏览器必然会重新去服务器请求这个资源。jQuery.ajax方法，如果cache=false，则会在GET请求参数中附加”_={timestamp}”来禁用缓存。

POST一般则不会被这些缓存因素影响。

4.安全性

默认对于nginx的access log，会自动记录get或post的完整URL，包括其中带的参数。

对于POST来说，请求的报文却不会被记录，这些对于敏感数据来说，POST更安全一些。

5.自动化性能测试：

基于上面提到的nginx日志，可以使用grep GET+日期，awk格式化，然后sort -u去重，从而提取到某天的所有GET请求URL，使用程序模拟登陆，然后请求所有URL即可获取简单的性能测试数据，每个请求是否正确，响应时间多少等等。

但是对于POST请求，因为不知道报文，无法这样简单处理。可以通过nginx-lua获取报文输出到log，这样格式化会麻烦很多，但不失为一个办法。

6.GET和POST对服务器的状态

根据http的设计，大家在看到get的时候，都期望这个请求对服务器没有修改，看到post的时候，都认为这对服务器产生了修改。

7.GET幂等，POST不幂等

1.按照RFC规范，PUT，DELETE和安全方法都是幂等的。虽说是规范，但服务端实现是否幂等是无法确保的。

2.引入幂等主要是为了处理同一个请求重复发送的情况，比如在请求响应前失去连接，如果方法是幂等的，就可以放心地重发一次请求。这也是浏览器在后退/刷新时遇到POST会给用户提示的原因：POST语义不是幂等的，重复请求可能会带来意想不到的后果。

3.比如在微博这个场景里，GET的语义会被用在「看看我的Timeline上最新的20条微博」这样的场景，而POST的语义会被用在「发微博、评论、点赞」这样的场景中。

请求报文

1. 请求报文构成

一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成。
大致结构是这样的：

     ＜request-line＞ //请求行
    
     ＜headers＞ //首部行
        
     ＜blank line＞ //空行
   
     ＜request-body＞ //请求体

一个简单的例子：

    POST /user HTTP/1.1      //请求行
    Host: www.user.com
    Content-Type: application/x-www-form-urlencoded
    Connection: Keep-Alive
    User-agent: Mozilla/5.0.      //以上是首部行
    （此处必须有一空行）  //空行分割header和请求内容 
    name=world   请求体

1.1 请求行

请求行由三部分组成：请求方法，请求URL（不包括域名），HTTP协议版本
请求方法比较多：GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT
最常用的是GET和POST。

1.1.1 请求方法

1） GET
传递参数长度受限制，因为传递的参数是直接表示在地址栏中，而特定浏览器和服务器对url的长度是有限制的。
因此，GET不适合用来传递私密数据，也不适合拿来传递大量数据。

一般的HTTP请求大多都是GET。
2）POST

POST把传递的数据封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据，对数据量没有限制，也不会显示在URL中。
表单的提交用的是POST。
3）HEAD

HEAD跟GET相似，不过服务端接收到HEAD请求时只返回响应头，不发送响应内容。所以，如果只需要查看某个页面的状态时，用HEAD更高效，因为省去了传输页面内容的时间。
4）DELETE

删除某一个资源。

5）OPTIONS

用于获取当前URL所支持的方法。若请求成功，会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，如“GET, POST”。

6）PUT

把一个资源存放在指定的位置上。
本质上来讲， PUT和POST极为相似，都是向服务器发送数据，但它们之间有一个重要区别，PUT通常指定了资源的存放位置，而POST则没有，POST的数据存放位置由服务器自己决定。

关于POST和PUT的区别以及请求方法的幂等性，请参考文章：http的7种请求方法和幂等性

7）TRACE

回显服务器收到的请求，主要用于测试或诊断。

8）CONNECT

CONNECT方法是HTTP/1.1协议预留的，能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接与非加密的HTTP代理服务器的通信。

1.1.2 HTTP协议版本

1）HTTP/1.0
HTTP/1.0支持：GET、POST、HEAD三种HTTP请求方法。
2）HTTP/1.1
HTTP/1.1是当前正在使用的版本。该版本默认采用持久连接，并能很好地配合代理服务器工作。还支持以管道方式同时发送多个请求，以便降低线路负载，提高传输速度。
HTTP/1.1新增了：OPTIONS、PUT、DELETE、TRACE、CONNECT五种HTTP请求方法。

1.2 请求头部

请求头部由关键字/值对组成，每行一对

User-Agent : 产生请求的浏览器类型
Accept : 客户端希望接受的数据类型，比如 Accept：text/xml（application/json）表示希望接受到的是xml（json）类型
Content-Type：发送端发送的实体数据的数据类型。
比如，Content-Type：text/html（application/json）表示发送的是html类型。
Host : 请求的主机名，允许多个域名同处一个IP地址，即虚拟主机

1.2.1 Content-Type

常见的Content-Type：

multipart/form-data
用以支持向服务器发送二进制数据，以便可以在 POST 请求中实现文件上传等功能
现在用Postman向百度发送一个请求方式为multipart/form-data的POST包，请求报文是这样的：

    POST / HTTP/1.1
    Host: www.baidu.com
    Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
    Cache-Control: no-cache
    Postman-Token: 033120fe-2185-15d4-e486-75e86e2baddd
    
    ------WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name="url"
    
    https://www.baidu.com/
    ------WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name="name"
    
    waffle
    ------WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name="desk"; filename="桌子.jpg"
    Content-Type: image/jpeg
    
    ...contents of 桌子.jpg...
    ------WebKitFormBoundary7MA4YWxkTrZu0gW--

其中， boundary这个参数是分界线的意思，这个分界线参数具体是什么你可以随意自定义 ，建议定义复杂一点，因为这样子才不会跟请求体中其它字段重复。
上面的例子看出分界线=“–”+boundary
每个参数都由分界线分隔开，参数名（二进制数据还需要指明文件类型）和参数值之间有一行空行，这个空行不能省略:

    ------WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name="url"
    
    https://www.baidu.com/

消息主体最后以 –boundary– 标示结束。
更加详细的解释可以参考：Multipart/form-data

1.3 空行

请求头之后是一个空行，通知服务器以下不再有请求头

1.4 请求体

GET没有请求数据，POST有。
与请求数据相关的最常使用的请求头是 Content-Type 和 Content-Length 。