一、HTTP简介
? ? ? ? 维基百科上解释为：超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。通过HTTP或者HTTPS协议请求的资源由统一资源标识符（Uniform Resource Identifiers，URI）来标识。
二、HTTP发展历程
HTTP/0.9版本，这个时候的HTTP只支持GET请求，且不支持请求头。
HTTP/1.0版本，这是第一个在通讯中指定版本号的HTTP协议版本，至今仍被广泛采用，特别是在代理服务器中。
HTTP/1.1版本，持久连接被默认建立，并能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求，以便降低线路负载，提高传输速度。
HTTP/2.0版本，当前版本，于2015年5月作为互联网标准正式发布。
HTTP/1.x缺点：
（1）、HTTP/1.0一次只允许在一个TCP连接上发起一个请求，HTTP/1.1使用的流水线技术也只能部分处理请求并发，仍然会存在队列头阻塞问题，因此客户端在需要发起多次请求时，通常会采用建立多连接来减少延迟。
（2）、单向请求，只能由客户端发起。
（3）、请求报文与响应报文首部信息冗余量大。
（4）、数据未压缩，导致数据的传输量大
HTTP/1.x与HTTP/2.0速度比较
三、HTTP特征
HTTP是无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
HTTP是媒体独立的：这意味着，只要客户端和服务器知道如何处理的数据内容，任何类型的数据都可以通过HTTP发送。客户端以及服务器指定使用适合的MIME-type内容类型。
HTTP是无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
四、HTTP消息结构
HTTP是基于客户端/服务端（C/S）的架构模型，通过一个可靠的链接来交换信息，是一个无状态的请求/响应协议。
一个HTTP"客户端"是一个应用程序（Web浏览器或其他任何客户端），通过连接到服务器达到向服务器发送一个或多个HTTP的请求的目的。
一个HTTP"服务器"同样也是一个应用程序（通常是一个Web服务，如Apache Web服务器或IIS服务器等），通过接收客户端的请求并向客户端发送HTTP响应数据。
HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。
一旦建立连接后，数据消息就通过类似Internet邮件所使用的格式[RFC5322]和多用途Internet邮件扩展（MIME）[RFC2045]来传送。
五、HTTP请求方法
HTTP1.0?定义了三种请求方法：?GET, POST?和?HEAD?方法。
HTTP1.1?新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE?和?CONNECT?方法。
六、HTTP响应头信息?
?七、HTTP状态码分类
?
?八、HTTP状态码列表
?九、HTTP content-type
Content-Type（内容类型），一般是指网页中存在的?Content-Type，用于定义网络文件的类型和网页的编码，决定浏览器将以什么形式、什么编码读取这个文件，这就是经常看到一些?PHP?网页点击的结果却是下载一个文件或一张图片的原因。
Content-Type?标头告诉客户端实际返回的内容的内容类型。
常见的媒体格式类型如下：
text/html?：?HTML格式
text/plain?：纯文本格式
text/xml?：?XML格式
image/gif?：gif图片格式
image/jpeg?：jpg图片格式
image/png：png图片格式
以application开头的媒体格式类型：
application/xhtml+xml?：XHTML格式
application/xml：?XML数据格式
application/atom+xml?：Atom XML聚合格式
application/json：?JSON数据格式
application/pdf：pdf格式
application/msword?：?Word文档格式
application/octet-stream?： 二进制流数据（如常见的文件下载）
application/x-www-form-urlencoded?：?<form encType=””>中默认的encType，form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式）
另外一种常见的媒体格式是上传文件之时使用的：
multipart/form-data?： 需要在表单中进行文件上传时，就需要使用该格式
更多对照参见
十、Session、Cookie与Token
Cookie、Session和Token的区别_xiaopy_0508的博客-CSDN博客_cookie和token的区别???????ssh
十一、关于http相关问题
一般的问题
1.?为什么要修改?HTTP？
HTTP/1.1?在?Web?上已经服务了?15?年以上，但是它的缺点正在开始显现。加载网页比以往任何时候都需要更多资源(请参阅HTTP Archive’s page size statistics)，并且要高效地加载所有这些资源非常困难，因为事实上，HTTP?只允许每个?TCP?连接有一个未完成的请求。
过去，浏览器使用多个?TCP?连接来发出并行请求。但是，这是有局限性的。如果使用的连接过多，则将适得其反(TCP?拥塞控制将被无效化，导致的用塞事件将会损害性能和网络)，并且从根本上讲是不公平的(因为浏览器会占用许多本不该属于它的资源)。同时，大量请求意味着“在线”上有大量重复数据。
这两个因素都意味着?HTTP/1.1?请求有很多与之相关的开销。如果请求过多，则会影响性能。
这使得业界误解了“最佳实践”，进行诸如?spriting?图片合并，data: inlining?内联数据，Domain Sharding?域名分片和Concatenation?文件合并之类的事情。这些?hack?行为表明协议本身存在潜在问题，在使用的时候会出现很多问题。
2.?谁制定了?HTTP/2？
HTTP/2?是由?IETF?的?HTTP?工作组开发的，该工作组维护?HTTP?协议。它由许多?HTTP?实现者，用户，网络运营商和?HTTP?专家组成。
请注意，虽然我们的邮件列表托管在?W3C?网站上，但这并不是?W3C?的努力。但是，Tim Berners-Lee?和?W3C TAG?与?WG?的工作进度保持同步。
大量的人为这项工作做出了贡献，最活跃的参与者包括来自诸如?Firefox，Chrome，Twitter，Microsoft?的?HTTP stack，Curl?和Akamai?等“大型”项目的工程师，以及许多诸如?Python、Ruby?和?NodeJS?之类的?HTTP?实现者。
要了解有关?IETF?的更多信息，请参见Tao of the IETF。您还可以在?Github?的贡献者图中了解谁为规范做出了贡献，以及谁在我们的实现列表中参与该项目。
3. HTTP/2?与?SPDY?有什么关系？
HTTP/2?第一次出现并被讨论的时候，SPDY?正逐渐受到实现者(例如?Mozilla?和?nginx)的青睐时，并且被当成对?HTTP/1.x?的重大改进。
在征求提案和进行选择过程之后，选择?SPDY/2?作为?HTTP/2?的基础。此后，根据工作组的讨论和实现者的反馈，进行了许多更改。在整个过程中，SPDY?的核心开发人员都参与了?HTTP/2?的开发，包括?Mike Belshe?和?Roberto Peon。2015?年?2?月，Google?宣布了其计划删除对?SPDY?的支持，转而支持?HTTP/2。
4.?是?HTTP/2.0?还是?HTTP/2？
工作组决定删除次版本（“.0”），因为它在?HTTP/1.x?中引起了很多混乱。换句话说，HTTP?版本仅表示网络兼容性，而不表示功能集或“亮点”。
5. HTTP/2?和?HTTP/1.x?的主要区别是什么？
在高版本的?HTTP/2?中：
是二进制的，而不是文本的
完全多路复用，而不是有序和阻塞
因此可以使用一个连接进行并行处理
使用头压缩??来减少开销
允许服务器主动将响应"推送"到客户端缓存中
6.?为什么?HTTP/2?是二进制的？
与诸如?HTTP/1.x?之类的文本协议相比，二进制协议解析起来更高效，更“紧凑”，并且最重要的是，它们比二进制协议更不容易出错，因为它们对空格处理，大写，行尾，空白行等的处理很有帮助。例如，HTTP/1.1?定义了四种不同的解析消息的方式。在?HTTP/2?中，只有一个代码路径。
HTTP/2?在?telnet?中不可用，但是我们已经有了一些工具支持，例如?Wireshark?插件。
7.?为什么?HTTP/2?需要多路复用？
HTTP/1.x?存在一个称为“队头阻塞”的问题，指的是一次连接（connection）中，只提交一个请求的效率比较高，多了就会变慢。
HTTP/1.1?试图通过管道修复此问题，但是并不能完全解决问题（较大或较慢的响应仍会阻止其他问题）。此外，由于许多中间件和服务器未正确处理管线化，因此很难部署它。
这迫使客户使用多种试探法（通常是猜测法）来决定通过哪些连接提交哪些请求；由于页面加载的数据量通常是可用连接数的?10?倍（或更多），因此会严重影响性能，通常会导致被阻止的请求“泛滥”。
多路复用通过允许同时发送多个请求和响应消息来解决这些问题。甚至有可能将一条消息的一部分与另一条消息混合在一起。所以在这种情况下，客户端只需要一个连接就能加载一个页面。
8.?为什么只有一个?TCP?连接？
使用?HTTP/1，浏览器打开每个站点需要?4?个到?8?个连接。现在很多网站都使用多点传输，因此这可能意味着单个页面加载会打开?30?多个连接。
一个应用程序打开如此多的连接，已经远远超出了当初设计?TCP?时的预想。由于每个连接都会响应大量的数据，这会造成中间网络中的缓冲区溢出的风险，从而导致网络拥塞事件并重新传输。
此外，使用这么多连接还会强占许多网络资源。这些资源都是从那些“遵纪守法”的应用那“偷”的（VoIP?就是个很好的例子）。
9.?服务器推送的好处是什么？
当浏览器请求页面时，服务器将在响应中发送?HTML，然后需要等待浏览器解析?HTML?并发出对所有嵌入资源的请求，然后才能开始发送?JavaScript，图像和?CSS。
服务器推送可以通过“推送”它认为客户端需要的响应到其缓存中，来避免服务器的这种往返延迟。
但是，“推送”响应不是“神奇的”——如果使用不正确，可能会损害性能。正确使用?Server Push?是正在进行的实验和研究领域。
10.?为什么我们需要头压缩？
Mozilla?的?Patrick McManus?通过计算平均页面加载消息头的效果，生动地展示了这一点。
假设一个页面包含大约?80?个资源需要加载（在当今的?Web?中是保守的），并且每个请求具有?1400?字节的消息头（这并不罕见，这要归功于?Cookie，Referer?等），至少要?7?到?8?个来回去“在线”获得这些消息头。这还不包括响应时间——那只是从客户端那里获取到它们所花的时间而已。
这是因为?TCP?的慢启动机制造成的，根据已确认的数据包数量，从而对新连接上发送数据的进行限制——有效地限制了最初的几次来回可以发送的数据包数量。
相比之下，即使对报头进行轻微的压缩，这些请求也可以在一次往返（甚至一个数据包）内搞定。
这种额外开销是相当大的，尤其是考虑到对移动客户端的影响时，即使在网络状况良好的条件下，移动客户端的往返延迟通常也要几百毫秒。
11.?为什么选择?HPACK？
SPDY/2?建议每个方都使用单独的?GZIP?上下文进行消息头压缩，该方法易于实现且效率很高。
从那时起，一个重要的攻击方式?CRIME?诞生了，这种方式可以攻击加密文件内部的所使用的压缩流（如?GZIP）。
使用?CRIME，攻击者有能力将数据注入加密流中，并可以“探测”明文并恢复它。由于这是?Web，因此?JavaScript?使这成为可能，而且已经有了通过对受到?TLS?保护的?HTTP?资源的使用CRIME来还原出?cookies?和认证令牌（Toekn）的案例。
结果，我们无法使用?GZIP?压缩。没有找到适合该用例并且可以安全使用的其他算法，我们创建了一种新的，专门针对报头的压缩方案，该方案以粗粒度压缩模式运行；由于?HTTP?标头通常在消息之间不改变，因此仍然可以提供合理的压缩效率，并且更加安全。
12. HTTP/2?可以使?Cookie(或其他头字段)变得更好吗？
这一努力被许可在网络协议的一个修订版本上运行?——?例如，HTTP?消息头、方法等等如何才能在不改变?HTTP?语义的前提下放到“网络上”。
这是因为?HTTP?被广泛使用。如果我们使用此版本的?HTTP?引入一种新的状态机制（例如之前讨论过的例子）或更改了核心方法（值得庆幸的是，尚未提出该方法），则意味着新协议与现有?Web?不兼容。
特别是，我们希望能够在不损失任何信息的情况下从?HTTP/1?转换为?HTTP/2。如果我们开始“清理”报头（并且大多数人会同意，因为?HTTP?报头很乱），将会出现很多与现有?Web?互操作性的问题。这样做只会对新协议的普及造成麻烦。
综上所述，HTTP?工作组负责所有?HTTP，而不仅仅是?HTTP/2。这样，我们可以研究与版本无关的新机制，只要它们与现有Web?向后兼容即可。
13.?非浏览器的?HTTP?用户呢？
如果非浏览器应用程序已经在使用?HTTP，则它们也应该能够使用?HTTP/2。
先前收到过?HTTP “APIs”?在?HTTP/2?中具有良好性能等特点这样的反馈，那是因为?API?不需要在设计中考虑诸如请求开销之类的问题。
话虽如此，我们正在考虑的改进的主要焦点是典型的浏览用例，因为这是该协议的核心用例。
正在制定的规范需要满足现在已经普遍部署了的?HTTP?的功能要求；具体来说主要包括，Web?浏览（桌面端和移动端），非浏览器（“HTTP APIs”?形式的），Web?服务（大范围的），还有各种网络中介（借助代理，企业防火墙，反向代理以及内容分发网络实现的）。同样的，对?HTTP/1.x?当前和未来的语义扩展?(例如，消息头，方法，状态码，缓存指令)?都应该在新的协议中支持。
值得注意的是，这里没有包括将?HTTP?用于非特定行为所依赖的场景中（例如超时，连接状态以及拦截代理）。这些可能并不会被最终的产品启用。
14. HTTP/2?是否需要加密？
否。经过广泛讨论，工作组尚未对新协议必须要使用加密（例如?TLS）达成共识，。
但是，一些实现已声明它们仅在通过加密连接使用?HTTP/2?时才支持?HTTP/2，并且当前没有浏览器支持未加密的?HTTP/2。
15. HTTP/2?如何提高安全性？
HTTP/2?定义了必需的?TLS?配置文件；这包括了版本，密码套件黑名单和使用的扩展。
有关详细信息，请参见规范。
还讨论了其他机制，例如对?HTTP:// URL?使用?TLS（所谓的“机会主义加密”）；参见?RFC 8164。
16.?我现在可以使用?HTTP/2?吗？
在浏览器中，Edge，Safari，Firefox?和?Chrome?的最新版本都支持?HTTP/2。其他基于?Blink?的浏览器也将支持?HTTP/2（例如Opera?和?Yandex Browser）。有关更多详细信息，请参见这里。
还有几种可用的服务器（包括?Akamai，Google?和?Twitter?的主要站点提供的?beta?支持），以及许多可以部署和测试的开源实现。
17. HTTP/2?会取代?HTTP/1.x?吗？
工作组的目的是让那些使用?HTTP/1.x?的人也可以使用?HTTP/2，并能获得?HTTP/2?所带来的好处。他们说过，由于人们部署代理和服务器的方式不同，我们不能强迫整个世界进行迁移，所以?HTTP/1.x?仍有可能要使用了一段时间。
18.?会有?HTTP/3?吗？
如果通过?HTTP/2?引入的协商机制运行良好，支持新版本的?HTTP?就会比过去更加容易。
实现相关的问题
1.?为什么规则会围绕?HEADERS frame?的?Continuation？
存在连续性是因为单个值（例如?Set-Cookie）可能超过?16KiB-1，这意味着它无法放入单个帧中。决定处理该问题的最不容易出错的方法是要求所有消息头数据都以一个接一个帧的方式传递，这使得解码和缓冲区管理也变得更加容易。
2. HPACK?状态的最小或最大大小是多少？
接收方始终控制?HPACK?中使用的内存量，并且可以将其最小设置为?0，最大值与?SETTINGS?帧中的最大可表示整数（当前为2^32-1）有关。
3.?如何避免保持?HPACK?状态？
发送一个?SETTINGS?帧，将状态尺寸（SETTINGS_HEADER_TABLE_SIZE）设置到?0，然后?RST?所有的流，直到一个带有ACT?设置位的?SETTINGS?帧被接收。
4.?为什么只有一个压缩/流控制上下文？
简单的说一下。
最初的提议里有流分组的概念，它可以共享上下文，流量控制等。虽然这将使代理受益（以及代理用户的体验），但这样做却增加了相当多的复杂性。所以我们就决定先以一个简单的东西开始，看看它会有多糟糕的问题，并且在未来的协议版本中解决这些问题（如果有的话）。
5.?为什么?HPACK?中有?EOS?符号？
HPACK?的霍夫曼编码，出于?CPU?效率和安全性的考虑，将霍夫曼编码的字符串填充到下一个字节边界；任何特定的字符串可能需要?0-7?位之间的填充。
如果单独考虑霍夫曼解码，那么任何比所需填充长的符号都可以工作；但是，HPACK?的设计允许按字节比较霍夫曼编码的字符串。通过要求将?EOS?符号的位用于填充，我们确保用户可以对霍夫曼编码的字符串进行字节比较，以确定是否相等。反过来，这意味着许多?headers?可以在不需要霍夫曼解码的情况下被解析。
6.?是否可以在不实现?HTTP/1.1?的情况下实现?HTTP/2？
是的，大部分情况都可以。
对于?TLS（h2）上的?HTTP/2?，如果您未实现?http1.1 ALPN?标识符，则无需支持任何?HTTP/1.1?功能。
对于基于?TCP（h2c）的?HTTP/2?，您需要实现初始?Upgrade?升级请求。
只支持?h2c?的客户端需要生成一个针对?OPTIONS?的请求，因为?“*”?或者一个针对?“/”?的?HEAD?请求，它们相当安全且易于构造。希望仅实现?HTTP/2?的客户端将需要将没有?101?状态码的?HTTP/1.1?响应视为错误。
只支持?h2c?的服务器可以使用一个固定的?101?响应来接收一个包含升级（Upgrade）消息头字段的请求。没有?h2c?升级令牌的请求可以通过包含?Upgrade?头字段的?505（不支持?HTTP?版本）状态码拒绝。不希望处理?HTTP/1.1?响应的服务器应在发送连接序言后，应该立即用?REFUSED_STREAM?错误码拒绝?stream 1，以鼓励客户端通过?upgraded?的?HTTP/2?连接重试请求。
7. HTTP/2?连接需要?TCP_NODELAY?么？
有可能需要。即使对于仅使用单个流下载大量数据的客户端实现，仍将有必要向相反方向发送一些数据包以实现最大传输速度。如果未设置?TCP_NODELAY（仍允许?Nagle?算法），则传出数据包可能会保留一段时间，以允许它们与后续数据包合并。
例如，如果这样一个数据包告诉对等端有更多可用的窗口来发送数据，那么将其发送延迟数毫秒（或更长时间）会对高速连接造成严重影响。
部署问题
1.?如果?HTTP/2?是加密的，我该如何调试？
有很多方法可以访问应用程序数据，但最简单的方法是?NSS keylogging?与?Wireshark?插件（包含在最新开发版本中）结合使用。这个方法对?Firefox?和?Chrome?均可适用。
2.?如何使用?HTTP/2?服务器推送
HTTP/2?服务器推送允许服务器无需等待请求即可向客户端提供内容。这可以改善检索资源的时间，特别是对于具有大带宽延迟产品的连接，其中网络往返时间占了在资源上花费的大部分时间。
推送基于请求内容而变化的资源可能是不明智的。目前，浏览器只会推送请求，如果他们不这样做，就会提出匹配的请求（请参阅?RFC 7234?的第?4?节）。
某些缓存不考虑所有请求头字段中的变化，即使它们在?Vary?头字段中。为了使推送资源被接收的可能性最大化，内容协商是最好的选择。基于?accept-encoding?报头字段的内容协商受到缓存的广泛尊重，但是可能无法很好地支持其他头字段。