网上关于HTTP/1.1的讨论多是基于RFC2616文档，而IETF已更新了HTTP/1.1并将其分为六个部分，使协议变得更简单易懂，对老版本RFC2616中模糊不清的部分做了解释
RFC7230-消息语法与路由RFC7231-语义与路由RFC7232-条件请求RFC7233-范围请求RFC7234-缓存RFC7235-认证HTTP是一种在传输层或会话层上交换消息的无状态的请求/响应协议，HTTP使用URI来定位资源和资源间的关系，通常请求会包含请求行，请求首部和请求体，下面的例子是在"http://www.example.com/hello.txt"上进行的GET请求
客户端请求:
GET /hello.txt HTTP/1.1 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 Host: www.example.com Accept-Language: en, mi服务器响应：
HTTP/1.1 200 OK Date: Mon, 27 Jul 2009 12:28:53 GMT Server: Apache Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT ETag: "34aa387-d-1568eb00" Accept-Ranges: bytes Content-Length: 51 Vary: Accept-Encoding Content-Type: text/plain Hello World! My payload includes a trailing CRLF.如果请求方法语义上是只读的，那么它被认为是安全的，根据之前定义，GET，HEAD，OPTIONS，TRACE是安全的
如果多个相同的请求方法对服务器的效果与单个请求对服务器的效果相同，则该请求方法是幂等的，根据定义PUT，DELETE与安全方法是幂等的
当请求方法的响应允许被缓存以供未来复用时，该请求方法是可缓存的。通常，不依赖当前或权威响应的安全方法被认为是可缓存的，本规范定义GET，HEAD，POST为可缓存的，虽然大多数缓存实现只支持GET和HEAD
GET是主要的信息取回机制，客户端可以将GET语义改变为"范围请求"，请求被选定representation的一部分
HEAD与GET方法几乎一样，但其响应中没有消息体，通常被用于测试连接性，可访问性和最近修改情况
POST通常被用于提交表单，发布消息以及创建资源，添加数据到资源已存在的representation上，当有多个资源在源服务器上被创建时，源服务器应该发送201响应 POST请求的响应只有包含explicit freshness information（4.2.1 of [RFC7234]）的时候才被定义为可缓存的，然而POST缓存并没有被广泛实现，当源服务器希望客户端能够缓存POST的结果以供之后的GET使用时，源服务器可能发送包含Content-Location且其值为POST的有效请求URI相同的200响应
RFC2818：HTTP Over TSL
HTTP/1.1默认开启Connection： keep-alive，支持长连接（持久连接）和请求Pipelining，可以在一个TCP连接上发送多个HTTP请求与响应。
HTTP/1.x是基于文本解析的，HTTP/2.0是基于二进制解析的HTTP/2.0采用多路复用，很好的解决了浏览器限制同一个域名下的请求数量的问题HTTP/2.0采用Header压缩，HTTP/1.x的header携带大量信息且重复，HTTP/2.0的通信双方各执一份header fields缓存，减少了传输大小与重复header的传输HTTP/2.0服务端推送减少了请求次数，减少请求次数答：
GET参数通过URL传递，POST放在Request body中GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息GET是安全的且是幂等的，POST则不是GET产生的URL地址可以被Bookmark，而POST不可以GET请求会被浏览器主动cache，而POST不会，除非手动设置GET请求只能进行url编码，而POST支持多种编码方式答：
HTTP/2.0基于二进制解析，而HTTP/1.x仅支持文本解析HTTP/2.0支持多路复用HTTP/2.0支持服务端推送HTTP/2.0支持Header压缩转载于:https://www.cnblogs.com/qbits/p/11192401.html
相关资源：数据结构—成绩单生成器