HTTP知识总结

本博客主要是因为个人想做一个学习总结，所以可能设计的东西比较多。

HTTP（超文本传输协议）

在tcp/ip协议之上，应用层协议，端口为80,有两种报文格式，请求报文，响应报文

请求报文和响应报文

请求报文

主要是有四部分构成的
1）请求行：请求方法+url+版本
2）请求头：保存一些与请求有关的信息
3）空行：分隔作用
4）请求数据：具体的数据
实际上可以分为两大类：请求信息头部，请求信息体

响应报文

也是四部分：
1）状态行：版本号，状态码，状态信息
2）响应头：储存一些与响应有关的信息
3）空行
4）相应数据
也可以说成：相应信息头，相应信息体

请求方法：

也就是请求报文中第一行的的第一个字段
GET：获取资源；POST：传输实体文本；HEAD：获取报文的首部；PUT：传输文件；DELETE：删除文件；OPTIONS：询问支持的方法；TRACE：追踪路径；CONNECT：要求用隧道协议连接代理
最基本的方法的有四种：GET，POST，PUT，DELETE：对应着查，改，增，删、

最常用的就是GET和POST方法，经常被问起的就是他们两的区别

GET和POST的区别

网上的标准答案：
1）后退后，GET无害，POST会被重新提交
2）书签，GET可以藏为书签，POSt不可以
3）缓存：GET能被缓存，POST不能
4）编码类型：POST多重编码
5）历史：GET可保留参数在历史中，POST不可以
6）对数据的长度限制：GET长度受限，POST无限制
7）安全：POST更安全，因为GET是可见的

其实GET和POST本质上两者是没有任何区别的，上面所说的很多的区别其实都是因为浏览器的限制而导致的，比如数据长度http其实没有对GET进行长度限制，只是不同的浏览器对url的长度进行了限制，如过非要说区别，那就是GET只产生一个TCP数据包，POST产生两个。

长的说：

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

但也不全是这样，火狐POST就只发送一次。

我们要记住，http的底层是tcp/ip，post和get只是两种请求方法，http只能算是一种行为准则，具体的实现和底层还是tcp/ip，所以要从底层找答案。

http状态码

服务器返回的 响应报文 中第一行为状态行，包含了状态码以及原因短语，用来告知客户端请求的结果

常见的状态码及其状态信息

301：请求的地址在别的地方，进行重定向
302：只是定位头信息中所给的URL应被理解为临时交换地址而不是永久的
304：指缓冲的版本已经被更新并且客户端应刷新文档
403（Forbidden/禁止）：服务器拒绝提供响应，一般是因为文件损坏或目录许可
404（NOTFOUND）：未找到请求资源
405：方法未允许，指的是某些请求方法对某些资源不允许使用
502：错误的网关；被用于充当代理或网关的服务器;该状态指出接收服务器接收到远端服务器的错误响应。
503：服务无法获得：表示服务器由于在维护或超载而无法响应
504：网关超时：该状态也用于充当代理或网关的服务器;它指出接收服务器没有从远端服务器得到及时的响应。该状态是新加入 HTTP 1.1的。

连接管理：

长连接与短链接
从 HTTP/1.1 开始默认是长连接的，如果要断开连接，需要由客户端或者服务器端提出断开，使用 Connection : close；
在 HTTP/1.1 之前默认是短连接的，如果需要使用长连接，则使用 Connection : Keep-Alive。

解释一下，上面也说http的底层是tcp，所以这里说的http的长连接其实就是tcp的长连接和短连接

短连接

短链接比较好理解，就是每次请求就建立一次连接，请求完毕后，就关闭连接，这种的体现就是如果已请求一个比较复杂的网页（有html，js，css，图片）可能就需要建立好几次连接。

长连接：

字面上的意思就是，当客户端发一次连接的时候，第一次请求成功后，不关闭，后面这个客户端再进行请求还是用的这个tcp连接，不知道听到这里，你们有没有问题，我是产生一个问题，他是怎么实现的呢？如果我完成请求后没请求了呢但是也不关闭呢？

TCP的保活功能主要为服务器应用提供。如果客户端已经消失而连接未断开，则会使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，此时服务器将永远等待客户端的数据。保活功能就是试图在服务端器端检测到这种半开放的连接。

如果一个给定的连接在两小时内没有任何动作，服务器就向客户发送一个探测报文段，根据客户端主机响应探测4个客户端状态：

1）客户主机依然正常运行，且服务器可达。此时客户的TCP响应正常，服务器将保活定时器复位。
2）客户主机已经崩溃，并且关闭或者正在重新启动。上述情况下客户端都不能响应TCP。服务端将无法收到客户端对探测的响应。服务器总共发送10个这样的探测，每个间隔75秒。若服务器没有收到任何一个响应，它就认为客户端已经关闭并终止连接。
3）客户端崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器复位这个连接。
4）客户机正常运行，但是服务器不可达。这种情况与第二种状态类似。

服务端不可能永远的维持一个tcp’连接，因为维持一个长连接成本还是很高，而且数量也不是无限的，不能所有的请求都被占了，别的请求进不来了，所以肯定需要这样一个探测。向上面这四种，我的理解就是，如果响应正常就复位定时器，或者是响应让我复位的请求才会继续连接，其它的基本上就是关闭连接了。

长连接和短连接的优缺点

长连接：可以省去比较多的TCP建立和关闭的操作，减少浪费，节约时间，对于频繁请求资源的来说，较适用，缺点就是：3保活功能的探测周期较长，不能区分恶意攻击，维持的代价较大
短连接：对于服务器来说管理比较简单，存在的连接都是有用连接，不需要额外的控制手段，但是如果客户大量频繁的请求，会在TCP的连接和关闭上，浪费时间和带宽

有关Cookie和Session的讨论

因为之前我已经专门写过一片关于这个话题的博客，比较详细，所以这里不做过多介绍了，有兴趣的可以去看一下深入理解Cookie和Session

http缓存

看这里

HTTP的版本比较以及发展历程

HTTP最早是0.9，这里就不对此说明了，版本较低，仅支持GET方法，只能传输html，已经没有在使用了，我们从1.0开始说

HTTP1.0

在GET的基础上，增加了POST和HEAD请求，支持多种数据格式的传输，同时也开始支持cache，就是当客户端在规定时间内访问统一网站，直接访问cache即可。
再次，HTTP请求和回应的格式也变了。除了数据部分，每次通信都必须包括头信息（HTTP header），用来描述一些元数据。

其他的新增功能还包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等。

    但是1.0版本的工作方式是每次TCP连接只能发送一个请求，当服务器响应后就会关闭这次连接，下一个请求需要再次建立TCP连接，就是不支持keepalive。

    TCP连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢（slow start）。所以，HTTP 1.0版本的性能比较差。随着网页加载的外部资源越来越多，这个问题就愈发突出了。

为了解决这个问题，有些浏览器在请求时，用了一个非标准的Connection字段。

Connection: keep-alive
在此情况下才会开启长连接

HTTP1.1

默认是长连接
支持流水线
支持同时打开多个 TCP 连接
支持虚拟主机
新增状态码 100
支持分块传输编码
新增缓存处理指令 max-age
具体的大家可以去查一查有兴趣的话

HTTP2.0

为了解决1.1版本利用率不高的问题，提出了HTTP/2.0版本。增加双工模式，即不仅客户端能够同时发送多个请求，服务端也能同时处理多个请求，解决了队头堵塞的问题（HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级）；HTTP请求和响应中，状态行和请求/响应头都是些信息字段，并没有真正的数据，因此在2.0版本中将所有的信息字段建立一张表，为表中的每个字段建立索引，客户端和服务端共同使用这个表，他们之间就以索引号来表示信息字段，这样就避免了1.0旧版本的重复繁琐的字段，并以压缩的方式传输，提高利用率。

    另外也增加服务器推送的功能，即不经请求服务端主动向客户端发送数据。

当前主流的协议版本还是HTTP/1.1版本。
http2.0中使用二进制协议，将报文分成 HEADERS 帧和 DATA 帧，它们都是二进制格式的。
服务端推送;HTTP/2.0 在客户端请求一个资源时，会把相关的资源一起发送给客户端，客户端就不需要再次发起请求了。例如客户端请求 page.html 页面，服务端就把 script.js 和 style.css 等与之相关的资源一起发给客户端。
首部压缩：HTTP/1.1 的首部带有大量信息，而且每次都要重复发送。

HTTP/2.0 要求客户端和服务器同时维护和更新一个包含之前见过的首部字段表，从而避免了重复传输。

不仅如此，HTTP/2.0 也使用 Huffman 编码对首部字段进行压缩。

HTTPS

HTTPS（安全的超文本传输协议），端口号为443
http产生的原因在于http协议的一些不足：
1）使用明文进行通信，内容可能会被窃听；
2）不验证通信方的身份，通信方的身份有可能遭遇伪装；
3）无法证明报文的完整性，报文有可能遭篡改。
https不是新的协议，而是在http的基础上上增加了安全性也就是SSL（安全套接字协议），HTTPS 并不是新协议，而是让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信。

通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。

也就说是说，用一句话概括：
HTTP+加密+认证+完整性保护=HTTPS

我想根据之前的一些知识，tcp在传输层，http在应用层，那ssl就应该是在传输层和应用层之间，你可以将他看成一个抽象层。

那么我们分别讲一下这三个部分的实现：

加密

对称密钥加密

对称密钥加密（Symmetric-Key Encryption），加密和解密使用同一密钥。

优点：运算速度快；
缺点：无法安全地将密钥传输给通信方。

非对称密钥加密

非对称密钥加密，又称公开密钥加密（Public-Key Encryption），加密和解密使用不同的密钥。

公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。

非对称密钥除了用来加密，还可以用来进行签名。因为私有密钥无法被其他人获取，因此通信发送方使用其私有密钥进行签名，通信接收方使用发送方的公开密钥对签名进行解密，就能判断这个签名是否正确。

优点：可以更安全地将公开密钥传输给通信发送方；
缺点：运算速度慢。

https采取的加密方式是混合加密，使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性，之后使用对称密钥加密进行通信来保证通信过程的效率

如果这个你不了解的话，没关系，举个例子，采用https协议的服务器必须要有一套SSL数字证书，需要向CA组织(如WoSign沃通CA)申请。这套SSL证书其实就是一对公钥和私钥。

为了理解，可以这么想，我申请之后，CA就给了我一对独一无二的锁和钥匙（公钥和私钥），我接收到之后，有人跟我请求，我就给他一把锁，他把数据封装好之后，用着吧锁锁上，传过来，因为只有我有一把钥匙，只有我能解开，所以传输是安全的，这中情况下就是锁有很多，但是钥匙只有我一个。

理解完这个我们就说一下整个的https请求的过程：
1）客户端发起https请求
2） 服务器端的配置，就是申请CA
3）传送证书（锁）：这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，证书过期时间等等。
4）客户端解析证书
5）传送加密数据
6）服务段解密信息：用私钥开锁
之后服务端回应也是用公钥加密

总体我理解感受下来，确实非常强大，传输速率被影响肯定是不可避免的，但我相信这也将不是问题，但是安全对于隐私的世界来说是非常有必要的。