* HTTP协议是超文本传输协议，是计算机之间传输超文本数据的约定和规范，基于【请求/响应】模式、无连接无状态、基于TCP协议的应用层协议。
* HTTP协议定义了Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。

【简单快速、灵活、无连接、无状态、基于TCP协议、默认端口80、支持B/S、C/S模式】
1、简单快速：客户向服务器请求服务时，只需要传送请求方法和路径。
  请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。
  由于HTTP协议简单，使得HTTP服务的程序规模小，因而通信速度很快。
2、灵活：HTTP允许传输任意类型的数据对象。
  正在传输的类型由Content-Type字段标记
3、无连接：含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户端的应答后，即断开连接。
      采用这种方式可以节省传输时间。
4、无状态：指协议对事务处理没有记忆能力。
  服务器不知道客户端是什么状态，即我们给服务器发送HTTP请求之后，服务器根据请求，会给我们发送数据，但是发送完不会记录任何信息。
  缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。
  另一方面，在服务器不需要先前信息时它的应答就很快。
5、支持B/S及C/S模式
6、默认端口80
7、基于TCP协议

怎么解决无连接？
Keep-Alive功能使客户端到服务器的连接持续有效，当出现对服务器的后续请求时，Keep-Alive功能避免了重新建立连接。

怎么解决无状态？
方法一：使用Cookie将状态信息保存在客户端。
方法二：使用Session将状态信息保存在服务端。

Cookie是客户端的存储空间，由浏览器来维持。具体来说Cookie是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器，是一种在客户端保持状态的方案。
Cookie指某些网站为了辨别用户身份、进行session跟踪而存储在用户本地终端上的数据（通常经过加密）。

Cookie会根据从服务器端发送的响应报文内的一个叫做Set-Cookie的首部字段信息，通过客户端保存Cookie，当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送过去。
Cookie是服务器生成的，但是发送给客户端，并由客户端保存。客户端再次请求该服务器时，客户端自动将Cookie加入请求报文中，服务器端发现客户端发送过来的Cookie后，会去检查从哪一个客户端发送过来的连接请求，然后对比服务器上的记录，最后得到之前的状态消息。

Session（会话），是另一种记录客户状态的机制，不同的是Cookie是保存在客户端浏览器的，而Session是保存在服务器上的。
客户端浏览器第一次访问服务器时，服务器自动生成了一个HashTable和一个Session ID用来唯一标识这个HashTable，并将其通过响应发送到浏览器。当浏览器第二次发送请求，会将前一次服务器响应中的Session ID放在请求中一并发送到服务器上，服务器从请求中提取出Session ID，并和保存的所有Session ID进行对比，找到这个用户对应的HashTable。
虽然Session保存在服务器上，对客户端是透明的，它的正常运行仍然需要客户端浏览器的支持。这是因为Session需要使用Cookie作为标志。HTTP协议是无状态的，Session不能根据HTTP连接来判断是否为同一客户，因此服务器向客户端发送一个名为JSESSIONID的Cookie，它的值为该Session的id（即放在HTTP响应报文头部信息里的Set-Cookie）。Session依据该Cookie来识别是否为同一客户。

1、Cookie数据保存在客户端的浏览器上，Session数据放在服务器上；
2、单个Cookie在客户端的限制是3k，也就是说一个站点在客户端存放的COOKIE不能超过3K
3、Cookie不是很安全，别人可以分析存放在本地的Cookie并进行Cookie欺骗
4、Session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能。

Cookie和Session的方案虽然分别属于客户端和服务端，但是服务端的Session的实现对客户端的Cookie有依赖关系的，上面我讲到服务端执行 Session机制时候会生成Session的id值，这个id值会发送给客户端，客户端每次请求都会把这个id值放到http请求的头部发送给服务端，而这个id值在客户端会保存下来，保存的容器就是Cookie，因此当我们完全禁掉浏览器的Cookie的时候，服务端的Session也会不能正常使用。

1. 客户端连接到Web服务器
  一个HTTP客户端（即浏览器），与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如：http://www.baidu.com。
2. 客户端向服务器发送一个请求报文。
   - 请求报文包含三个部分：【请求行、首部行、请求内容实体】
3. 服务器接收请求并返回HTTP响应报文。
   - 响应报文包含三个部分：【状态行、首部行、响应内容实体】
4. 客户端将返回的内容解析并呈现，断开连接。
   客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。
   然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。
   客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

- 请求报文包含三个部分：【请求行、首部行、请求内容实体】
  其中，请求行包含：请求方法、请求资源的URL、HTTP协议版本；
- 响应报文包含三个部分：【状态行、首部行、响应内容实体】
  其中，状态行包含：HTTP协议版本、状态码、状态码描述语。

1. GET用于获取资源；而POST用于传输实体主体。
2. GET方法不会改变服务器状态，是安全的；POST的目的是传送实体主体内容，这个内容可能是用户上传的表单数据，上传成功之后，服务器可能把这个数据存储到数据库中，因此状态也就发生了改变。
3. GET是幂等的；POST不是。
安全概念：请求方法不会破坏服务器上的资源。
幂等概念：多次执行相同的操作，结果都是相同的。

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

1、GET参数通过URL传递，POST放在request body中
2、GET请求在URL中传递的参数是有长度限制的，而POST没有
3、GET比POST更不安全，因为参数直接暴露在URL中，所以不能用来传递敏感信息
4、GET请求只能进行URL编码，而POST支持多种编码方式
5、GET请求浏览器会主动cache，而POST支持多种编码方式
6、GET请求参数会被完整保留在浏览历史记录里，而POST中的参数不会被保留
7、GET和POST本质上就是TCP连接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致它们在应用过程中体现出一些不同
8、GET产生一个TCP数据包；POST产生两个TCP数据包

哪些情况需要做301重定向？
网页开发过程中，时常会遇到网站目录结构的调整，将页面转移到一个新地址；网页扩展名的改变，这些变化都会导致网页地址发生改变，此时用户收藏夹和搜索引擎数据库中的旧地址是一个错误的地址，访问之后会出现404页面，直接导致网站流量的损失。或者是我们需要多个域名跳转至同一个域名，例如本站主站点域名为 www.conimi.com ，而还有一个域名 www.nico.cc，由于对该域名设置了301重定向，当输入www.nico.cc 时，自动跳转至 www.conimi.com 。
301重定向有什么优点？
有利于网站首选域的确定，对于同一资源页面多条路径的301重定向有助于URL权重的集中。例如 www.conimi.com和 conimi.com 是两个不同的域名，但是指向的内容完全相同，搜索引擎会对两个域名收录情况不同，这样导致网站权重和排名被分散；对conimi.com 做301重定向跳转至www.conimi.com 后，权重和排名集中到www.conimi.com，从而提升自然排名。
302重定向又是什么鬼？
302重定向（302 Move Temporarily），指页面暂时性转移，表示资源或页面暂时转移到另一个位置，常被用作网址劫持，容易导致网站降权，严重时网站会被封掉，不推荐使用。

Host:www.A.com    //C -> S
Content-Length:1000   //S -> C
Keep-Alive:timeout=10,max=500  //S -> C
Connection:Keep-Alice
Content-Type:text/html; charset=utf-8  //S -> C
Accept-Encoding:gzip, deflate   //客户端 -> 服务器
Content-Encoding:gzip           //服务器 -> 客户端

1. HTTP以明文方式在网络中传输数据，存在安全风险的问题。
   HTTPS则解决了HTTP不安全的问题，在TCP和HTTP网络层之间加入了SSL/TLS的握手过程，使得报文能够加密传输。
2. HTTP连接建立相对简单，TCP三次握手之后便可进行HTTP的报文传输。
   HTTPS在TCP三次握手之后，还需要进行SLL/TLS的握手过程，才可进入加密报文传输。
3. 端口不同
  HTTP的端口号是80；HTTPS的端口号是443
4. 经济开销：
  HTTPS通信需要证书，而证书一般需要向认证机构购买。

HTTP有：
1. 窃听风险：通信使用明文不加密
2. 篡改风险：第三方可以修改通信内容
3. 冒充风险：不验证通信方身份
HTTPS有：
* 信息加密：解决了窃听风险。采用混合加密，通信建立前采用非对称加密，通信过程中采用对称加密。
* 校验机制：一旦被篡改，通信双方会立即发现。
* 身份证书：CA，数字证书认证机构，将服务器公钥放在数字证书中

HTTPS优缺点：
优点：【安全】
  * HTTPS传输数据过程中使用秘钥进行加密，所以安全性更高
  * HTTPS协议可以认证用户和服务器，确保数据发送到正确的用户和服务器
缺点：【时间、经济成本、CPU资源】
  * HTTPS握手阶段延时较高，由于进行HTTP会话之前还需要进行SSL握手。
  * HTTPS部署成本高：一方面HTTPS协议需要使用证书来验证自身的安全性，所以需要购买CA证书。
                   另一方面采用HTTPS协议需要进行加密解密的计算，占用CPU资源较多，需要的服务器配置或数目高

CA是验证服务器公钥的证实性：
1. 服务器把自己的公钥注册到数字证书认证机构CA
2. CA用自己的私钥将服务器的公钥数字签名并颁发数字证书
3. 客户端拿到服务器的数字证书后，使用CA的公钥确认服务器的数字证书的真实性
4. 从数字证书获取服务器公钥后，使用它对报文加密后发送
5. 服务器用私钥对报文解密

问：什么是数字签名：
为了避免数据在传输过程中被替换，比如黑客修改了你的报文内容，但是你并不知道，所以我们让发送端做一个数字签名，把数据的摘要消息进行一个加密，比如MD5，得到一个签名，和数据一起发送。然后接收端把数据摘要进行MD5加密，如果和签名一样，则说明数据确实是真的。
问：什么是数字证书？
对称加密中，双方使用公钥进行解密。虽然数字签名可以保证数据不被替换，但是数据是由公钥加密的，如果公钥也被替换，则仍然可以伪造数据，因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的，CA证书机构会负责颁发一个证书，里面的公钥保证是真的，用户请求服务器时，服务器将证书发给用户，这个证书是经由系统内置证书的备案的。

1. 硬件优化：高性能CPU
2. 软件优化：升级Linux内核，升级OpenSSL
3. 会话复用
4. 协议优化：TLS升级为1.3
5. 证书优化：证书传输优化，选用EDCSA证书；证书验证优化，选用CRL

数字证书是指CA机构发行的一种电子文档，是一串能够表明网络用户身份信息的数字，提供了一种在计算机网络上验证网络用户身份的方式。

CA，Certificate Authority，“证书授权中心”。
它是负责管理和签发证书的第三方机构，作用是检查证书持有者身份的合法性，并签发证书，以防证书被伪造或篡改。
就该负责颁发身份证的公安局、负责发放驾驶证的交通管理局。

1. 用户产生自己的密钥对，并将公钥及部分个人身份信息传送到一家认证中心
2. 认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来。
然后，认证中心将发给用户一个数字证书，该证书内附了用户和他的公钥等信息，同时还附有对认证中心公钥加以确认的数字证书。
3. 当用户想证明其公钥的合法性时，就可以提供这一数字证书。

数字证书的格式普遍采用的是 X.509V3 国际标准，一个标准的 X.509 数字证书包含以下一些内容：
1、证书的版本信息
2、证书的序列号。（每个证书序列号唯一）
3、证书所使用的签名算法
4、证书的发行机构名称。  命名规则一般采用X.500格式
5、证书的有效期。  UTC时间格式
6、证书所有人的名称。 X.500格式
7、证书所有人的公钥
8、证书发行者对证书的签名

对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方。
非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。
由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

HTTP0.9（1991年发布）
1. HTTP是基于TCP/IP协议的应用层协议。它不涉及数据包传输，主要规定了客户端和服务器之间的通信格式，默认使用80端口。
2. 只有GET命令。
3. 协议规定，服务器只能回应HTML格式的字符串，不能回应别的格式。

HTTP1.0（1996年发布）
1. 任何格式的内容都可以发布。不仅可以传输文字，还可以传输图像、视频、二进制文件等。
2. 除了GET命令，还引入了POST、HEAD命令等。
3. 请求和回应的格式也变了。除了数据部分，每次通信还必须有头信息，用来描述一些元数据。
4. 其他的新增功能还包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等。
HTTP1.0缺点：
1. 短连接：每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。
解决方法：Connection：keep-alive   但是不是根本的解决方法

HTTP1.1相比于HTTP1.0的改进：
* 使用TCP长连接的方式改善了HTTP1.0短连接造成的性能开销
* 支持管道网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间

HTTP1.1（1997年）
新特性：
1. 长连接：HTTP1.1只要任意一端没有明确提出断开连接，则保持TCP连接状态（即TCP连接默认不关闭）。不需要声明Connection:keep-alive  
2. 管道机制：允许客户端同时发起多个请求。只要第一个请求发出去了，不必等其回来，就可以发出第二个请求，可以减少整体的响应时间。
3. 分块传输编码：利用HTTP首部段，分块传输内容主体。   
4. 其他功能：还新增了许多动词方法：PUT、PATCH、HEAD、 OPTIONS、DELETE。
优点：简单、灵活和易于扩展、应用广泛和跨平台
1. 简单：采用报文格式：header+body  易于理解
2. 灵活和易于扩展：下层可以随意变换；如HTTPS在下面增加了SSL/TLS安全传输层
3. 应用广泛和跨平台：
缺点：无状态、明文传输、不安全、队头阻塞
0. 对头阻塞：在同一个TCP连接里面，所有的数据通信都是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。如果前面的回应特别慢，后面就会有很多请求排队等待。好比堵车。  
1. 无状态：无状态是双刃剑；可以采用Cookie技术解决
2. 明文传输
3. 不安全    

问：解决队头阻塞方法：
1. 减少请求数
2. 同时多开持久连接
这导致了很多的网页优化技巧，比如合并脚本和样式表、将图片嵌入CSS代码、域名分片等等。

问：HTTP如何实现长连接？在什么时候会超时？
HTTP1.0默认使用短连接，一个TCP连接对应一个HTTP请求，但是可以通过字段Connection:keep-alive指定。
HTTP1.1默认为长连接，多个请求复用一个TCP连接。
keep-alive不会永久保持连接，它有一个保持时间。
1、HTTP一般会有httpd守护进程，里面可以设置keep-alive timeout，当tcp链接闲置超过这个时间就会关闭，也可以在HTTP的header 里面设置超时时间。
2、TCP的keep-alive包含三个参数，支持在系统内核的net.ipv4里面设置：当TCP链接之后，闲置了tcp_keepalive_time，则会发生侦测包，如果没有收到对方的ACK，那么会每隔 tcp_keepalive_intvl 再发一次，直到发送了tcp_keepalive_probes，就会丢弃该链接。
（1）tcp_keepalive_intvl = 15
（2）tcp_keepalive_probes = 5
（3）tcp_keepalive_time = 1800
实际上HTTP没有长短链接，只有TCP有，TCP长连接可以复用一个TCP连接来发起多次HTTP请求，这样可以减少资源消耗，比如一次请求HTML，可能还需要请求后续的JS/CSS/图片等。

问：长连接和短连接应用场景：
1. 长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，下次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket创建也是对资源的浪费。
2. 而像Web网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源， 如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连接。

HTTP1.1优化：
1. 尽量避免发送HTTP请求
  缓存：客户端会把第⼀次请求以及响应的数据保存在本地磁盘上，其中将请求的 URL 作为 key，而响应作为 value，两者形成映射关系。
2. 在需要发送HTTP请求时，考虑如何减少请求次数
  减少重定向请求次数：代理服务器
  合并请求：如果把多个访问⼩⽂件的请求合并成⼀个⼤的请求，虽然传输的总资源还是⼀样，但是减少请求，也就意味着减少了重复发送的         HTTP 头部。
  延迟发送请求：请求⽹⻚的时候，没必要把全部资源都获取到，⽽是只获取当前⽤户所看到的⻚⾯资源，当⽤户向下滑动⻚⾯的时候，再向服          务器获取接下来的资源，这样就达到了延迟发送请求的效果。
3. 减少服务器的HTTP响应的数据大小
  有损压缩
  无损压缩

HTTP1.1还是有性能瓶颈：
首部未压缩、顺序响应、没有优先级控制、只能客户端请求
1. 请求/响应头部（Header）未经压缩就发送，⾸部信息越多延迟越⼤。只能压缩Body的部分；
2. 发送冗⻓的⾸部。每次互相发送相同的⾸部造成的浪费较多；
3. 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端⼀直请求不到数据，也就是队头阻塞；
4. 没有请求优先级控制；
5. 请求只能从客户端开始，服务器只能被动响应。

HTTP2协议是基于HTTPS的，安全性更有保障
【头部压缩、二进制流、多路复用、优先级、服务器推送】
1. 头部压缩：如果你同时发出多个请求，他们的头是⼀样的或是相似的，那么，协议会帮你消除重复的部分。
2. 二进制格式：头信息帧和数据帧；增加了数据传输的效率。
3. 数据流：HTTP2的数据包不是按顺序发送的，还可以指定数据流优先级。优先级⾼的请求，服务器就先响应该请求
4. 多路复用：HTTP2是可以在⼀个连接中并发多个请求或回应，⽽不⽤按照顺序⼀⼀对应。
   移除了HTTP1.1中的串⾏请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，⼤幅度提⾼了连接的利⽤率。
5. 服务器推送：服务不再是被动地响应，也可以主动向客户端发送消息。

HTTP2（2015年，不叫HTTP2.0，下一个新版本将是HTTP3）
1. 兼容HTTP1.1
2. 头部压缩
  HTTP1.1压缩了body，但是没有压缩header
  HTTP协议不带有状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如Cookie和User Agent
3. 二进制帧
  HTTP2厉害的地⽅在于将HTTP1的⽂本格式改成⼆进制格式传输数据，极⼤提⾼了HTTP传输效率，⽽且⼆进制数据使⽤位运算能⾼效解析。
4. 多工
  HTTP2复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或响应，而且不用按照顺序一一对应，这样就避免了“队头阻塞”。
  举例来说，在一个TCP连接里面，服务器同时收到了A请求和B请求，于是先回应A请求，结果发现处理过程非常耗时，于是就发送A请求已经处理好的部分， 接着回应B请求，完成后，再发送A请求剩下的部分。
5. 数据流
  因为HTTP2的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。
  HTTP2将每个请求或回应的所有数据包，称为一个数据流（stream）。每个数据流都有一个独一无二的编号。数据包发送的时候，都必须标记数据流ID，用来区分它属于哪个数据流。另外还规定，客户端发出的数据流，ID一律为奇数，服务器发出的，ID为偶数。
  数据流发送到一半的时候，客户端和服务器都可以发送信号（RST_STREAM帧），取消这个数据流。1.1版取消数据流的唯一方法，就是关闭TCP连接。这就是说，HTTP2可以取消某一次请求，同时保证TCP连接还打开着，可以被其他请求使用。
  客户端还可以指定数据流的优先级。优先级越高，服务器就会越早回应。
6. 服务器主动推送资源
  HTTP2允许服务器未经请求，主动向客户端发送资源。

HTTP2缺陷：HTTP2多个请求是跑在⼀个TCP连接中的（即多路复用），那么当TCP丢包时，整个TCP都要等待重传，那么就会阻塞该TCP连接中的所有请求。
HTTP3把HTTP下层的TCP协议改成了UDP；基于UDP的QUIC协议

1. 队头阻塞：HTTP2多个请求是跑在一个TCP连接中的，那么当TCP丢包时，整个TCP都要等待重传，那么就会阻塞该TCP连接中的所有请求。
      因为TCP是基于字节流协议的，TCP层必须保证收到字节数据是完整且有序的，如果序列号较低的TCP段在网络传输中丢失了，即使      序列号较高的TCP段已经被接收，应用层也无法从内核中读取到这部分数据，从HTTP视觉看，就是请求被阻塞了。
2. TCP与TLS的握手时延迟
3. 网络迁移需要重新连接