什么是HTTP协议

引自Wikipediahttps://en.wikipedia.org/wiki…

超文本传输协议（HTTP）是一个用于传输分布式、协同、超媒体信息系统的应用层协议。听起来挺拗口，换句表述：HTTP协议是用于从WWW服务器传输超文本到本地浏览器的传送协议。

HTTP协议发展

HTTP协议是万维网协会（World Wide Web Consortium）和Internet工作小组IETF（Internet Engineering Task Force）合作的结果，（他们）最终发布了一系列的RFC，RFC 1945定义了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定义了今天普遍使用的一个版本——HTTP 1.1。

HTTP/0.9

1991年发布的HTTP/0.9。该版本极其简单，只有一个命令GET，且服务器只能回应HTML格式的字符串，服务器发送完毕，就关闭TCP连接。

HTTP/1.0

1996年5月，HTTP/1.0 版本发布，新增如下

• 状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content-encoding）、数据格式（Content-Type）

• 引入POST命令和HEAD命令。

• HTTP请求和回应的格式也变了。除了数据部分，每次通信都必须包括头信息（HTTP header），用来描述一些元数据。

HTTP/1.1

• 缓存
  HTTP/1.0

     Expires是http1.0提出的一个表示资源过期时间的header，它描述的是一个绝对时间，由服务器返回，用GMT格式的字符串表示，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，
     Pragma:no-cache头域，客户端使用该头域说明请求资源不能从cache中获取，而必须回源获取。

  HTTP/1.1

     Cache-Control描述的是一个相对时间，在进行缓存命中的时候，都是利用客户端时间进行判断，所以相比较Expires，Cache-Control的缓存管理更有效，安全一些。
  
     注意：这两个header可以只启用一个，也可以同时启用，当response header中，Expires和Cache-Control同时存在时，Cache-Control优先级高于Expires：
  

• 带宽优化Content-Range
  HTTP/1.0

     HTTP/1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了。例如，客户端只需要显示一个文档的部分内容，又比如下载大文件时需要支持断点续传功能，而不是在发生断连后不得不重新下载完整的包。

  HTTP/1.1

     HTTP/1.1中在请求消息中引入了 range头域，它允许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回 了对象所请求范围的内容，则响应码为206（Partial Content），它可以防止Cache将响应误以为是完整的一个对象。
  

• 长连接Connection: Keep-Alive
  HTTP 1.0

     HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪 每个客户也不记录过去的请求。此外，由于大多数网页的流量都比较小，一次TCP连接很少能通过slow-start区，不利于提高带宽利用率。

  HTTP 1.1

     HTTP 1.1支持长连接（PersistentConnection），在一个TCP连接上可以传送多个HTTP请 求和响应，减少了建立和关闭连接的消耗和延迟。
  

• 管道机制/流水线（Pipelining）处理

     HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
  

• Content-Length 字段

     一个TCP连接现在可以传送多个回应，势必就要有一种机制，区分数据包是属于哪一个回应的。这就是Content-length字段的作用，声明本次回应的数据长度。
  

• Host头域
  HTTP1.0

         在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机 （Multi-homed Web Servers），并且它们共享一个IP地址。

  HTTP1.1

  HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。此外，服务器应该接受以绝对路径标记的资源请求。 
  在HTTP 1.1中增加Host请求头字段后，WEB浏览器可以使用主机头名来明确表示要访问服务器上的哪个WEB站点，这才实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点。
  

• 其他

     1.1版还新增了许多动词方法：PUT、PATCH、HEAD、 OPTIONS、DELETE

HTTP2/.0

HTTP/1.1缺点

虽然1.1版允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为”队头堵塞”（Head-of-line blocking）。
为了避免这个问题，只有两种方法：一是减少请求数，二是同时多开持久连接。这导致了很多的网页优化技巧，比如合并脚本和样式表、将图片嵌入CSS代码、域名分片（domain sharding）等等。如果HTTP协议设计得更好一些，这些额外的工作是可以避免的。

• 服务器推送

     HTTP/2 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送（server push）。
     常见场景是客户端请求一个网页，这个网页里面包含很多静态资源。正常情况下，客户端必须收到网页后，解析HTML源码，发现有静态资源，再发出静态 资源请求。其实，服务器可以预期到客户端请求网页后，很可能会再请求静态资源，所以就主动把这些静态资源随着网页一起发给客户端了。
     

HTTP五大特点

1.支持客户/服务器模式。
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。早期这么做的原因是请求资源少，追求快。后来通过Connection: Keep-Alive实现长连接
5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

来说说无状态
HTTP 是一个无状态协议，这意味着每个请求都是独立的。无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即我们给服务器发送 HTTP 请求之后，服务器根据请求，会给我们发送数据过来，但是，发送完，不会记录任何信息。
但对于一下需要状态的页面，如用户主页需要用户登录信息、购物下单时需要选中的商品等，服务器必须知道浏览器的当前状态。两种用于保持HTTP连接状态的技术就应运而生了，一个是Cookie，而另一个则是Session。

Cookie是通过客户端保持状态的解决方案，存放于HTTP响应头（Response Header），每次请求时，请求头都会带上Cookie，从而保持浏览器状态。浏览器中“记住密码”的功能就是根据Cookie做的。
Session是通过服务器来保持状态的。服务器创建Session并为该Session生成唯一的Session id，而这个Session id在随后的请求中会被用来重新获得已经创建的Session；在Session被创建之后，就可以调用Session相关的方法往Session中增加 内容了，而这些内容只会保存在服务器中，发到客户端的只有Session id；当客户端再次发送请求的时候，会将这个Session id带上，服务器接受到请求之后就会依据Session id找到相应的Session，从而再次使用之。正式这样一个过程，用户的状态也就得以保持了。

HTTP和HTTPS

HTTP不足

• 通信使用明文(不加密),内容可能会被窃听

• 不验证通信方的身份,因此有可能遭遇伪装

• 无法证明报文的完整性,所以有可能已遭篡改

HTTPS

HTTP 协议中没有加密机制,但可以通 过和 SSL(Secure Socket Layer,安全套接层)或 TLS(Transport Layer Security,安全层传输协议)的组合使用,加密 HTTP 的通信内容。属于通信加密，即在整个通信线路中加密。

HTTP+ 加密 + 认证 + 完整性保护 =HTTPS（HTTP Secure ）

SSL/TSL
SSL(Secure Sockets Layer 安全套接层)
TLS：(Transport Layer Security，传输层安全协议)

HTTPS 采用共享密钥加密（对称）和公开密钥加密（非对称）两者并用的混合加密机制。若密钥能够实现安全交换,那么有可能会考虑仅使用公开密钥加密 来通信。但是公开密钥加密与共享密钥加密相比,其处理速度要慢。
所以应充分利用两者各自的优势,将多种方法组合起来用于通信。 在交换密钥环节使用公开密钥加密方式,之后的建立通信交换报文阶段 则使用共享密钥加密方式。

HTTPS
握手过程的简单描述如下：

1.浏览器将自己支持的一套加密规则发送给网站。

 服务器获得浏览器公钥

2.网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。

 浏览器获得服务器公钥

3.获得网站证书之后浏览器要做以下工作：
a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码（接下来通信的密钥），并用证书中提供的公钥加密（共享密钥加密）。
c) 使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。

 浏览器验证->随机密码，并用服务器的公钥加密->生成HASH握手，用密码加密

4.网站接收浏览器发来的数据之后要做以下的操作：
a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
b) 使用密码加密一段握手消息，发送给浏览器。

服务器用自己的密钥解出随机密码->用密码解密握手消息（共享密钥通信）->验证HASH与浏览器是否一致（验证浏览器）

5.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，
此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。

HTTPS不足

• 慢

• 贵

• 整个页面的请求都要使用HTTPS

未完待续。。。

参考文章
1.HTTP 协议入门
2.浅谈HTTP的无状态性
3.深入理解HTTP协议
4.HTTP请求响应过程 与HTTPS区别_Linux教程_Linux公社-Linux系统…
5.写给后端程序员的HTTP缓存原理介绍
6 TCP的三次握手(建立连接）和四次挥手(关闭连接）
7 HTTP/1.1与HTTP/1.0的区别
8 HTTP 头部详细解释
9 HTTP 1.1与HTTP 1.0的比较
10 如何理解HTTP协议的“无连接,无状态”特点?
11 《图解HTTP》