什么是HTTP\HTTPS

HTTP是Hyper Text Transfer Protocol（超文本传输协议）的缩写。HTTP协议用于从WWW服务器传输超文本到本地浏览器的传输协议，它能使浏览器更加高效，使网络传输减少，保证计算机正确快速地传输超文本文档。现在我们普遍使用的版本是HTTP1.1。

HTTP是一个应用层协议，它由请求和响应组成，是一个标准的B/S模型；它也是一个无连接的协议，这里无连接指的是每次连接只处理一个请求，服务器处理完客户端请求后便断开连接；同时，它也是一个无状态的协议，那么什么是无状态呢？简单地说就是同一个客户端，这次请求跟上一次请求是没有对应关系的。

HTTPS简单地说就是HTTP的安全版。通常在安全性要求比较高的网站（例如银行网站）会看到HTTPS，它本质其实也是HTTP协议，只是在HTTP增加了一个TLS或SSL协议层。如图2-2-6-1，如果在TCP协议上加一层TLS或SSL协议，就是HTTPS协议了。TLS\SSL提供了加密的机制，所以它比HTTP明文传输更安全，图中可以看出，HTTP可以直接进入TCP传输层；也可以在TCP层上加一层TLS\SSL层，这样就先经过TLS\SSL再进入TCP传输层。这两种方式便是HTTP与HTTPS。一般HTTP的端口为80，而HTTPS的端口为443。

图2-2-6-1 HTTP协议层

简单地说，SSL\TLS协议层主要的职责就是借助下层协议的信道安全地协商出一份加密密钥，并且用此密钥来加密HTTP请求响应报文。它解决了以下三个安全性方面的议题：①提供认证服务，认证本次会话实体身份的合法性。②提供加密服务，强加密机制能保证通信过程中的消息不会被破译。③提供防篡改服务，利用Hash算法对消息进行签名，通过验证签名保证通信内容不被篡改。

HTTPS运用越来越广泛，而且在安全场景中是一个很好的解决方案，一般作为解决安全传输的首选解决方案。那么还是有必要稍微深入了解一下HTTPS的工作原理及流程。

在理解HTTPS工作原理前，先了解一些加密解密算法与Hash算法：（1）对称加密。密钥只有一个，加密解密都是这个密码，加解密速度快，典型的对称加密算法有DES、AES、RC4等。（2）非对称加密。密钥成对出现，分别为公钥跟私钥，公钥无法推知私钥，反之私钥也不能推知公钥。加密解密使用不同密钥，公钥加密需要私钥解密，反之私钥加密需要公钥解密。非对称加密速度较慢，典型的非对称加密算法有RSA、DSA、DSS等。（3）Hash算法，这是一种不可逆的算法，我们常用于验证数据的完整性。

图2-2-6-2详细描述了HTTPS完成一次通信要做哪些事情。首先，由于HTTPS是基于TCP/IP通信的，属于可靠传输，那么必须要先进行3次握手，完成连接建立。接下去的是SSL的握手协议，此协议非常有效的让客户和服务器之间完成相互之间的身份认证。第一步，客户端浏览器向服务器发送SSL\TLS协议的版本号、加密算法的种类、产生的随机数、以及其它需要的各种信息。第二步，服务器从客户端支持的加密算法中选择一组加密算法与Hash算法，并且把自己的证书（包含网站地址、加密公钥、证书颁发机构等）也发送给客户端。第三步，浏览器获取服务器证书后对其合法性进行验证，颁发机构是否合法，证书中的网址是否与正在访问的地址一致，通过验证的浏览器会显示一个小锁头，否则提示证书不受信。第四步，客户端浏览器生成一串随机数并用服务器传来的公钥加密，再使用约定好的Hash算法计算握手消息，发送到服务器端。第五步，服务器接到握手消息后用自己的私钥解密，并用Hash算法验证，这样双方都有了此次通信的密钥。第六步，服务器再使用密钥加密一段握手消息，返回给客户端浏览器。第七步，浏览器用密钥解密，并用hash算法验证，确定算法跟密钥。完成以上七步后双方就可以利用此次协商好的密钥进行通信。

图2-2-6-2 HTTPS的工作原理及流程

HTTP请求响应模型

从某种意义上来说，HTTP协议永远都是由客户端发起请求，服务器进行响应，并发送回响应报文。如果没有客户端进行请求或曾经请求，那么服务器端是无法将消息推送到客户端的。http协议采用了请求/响应模型，一个http请求跟响应一般如图2-2-6-3所示，客户端向服务器发送一个请求，请求头包含请求方法、URI、协议版本、请求修饰符、客户信息、类似于MIME结构的消息内容。服务器以一个状态行作为响应，内容包括消息协议版本、成功或失败编码、服务器信息、实体元信息及一些实体内容。这样就完成了一个请求响应过程。

图2-2-6-3 HTTP请求响应模型

通常，把一次http操作称为一个事务，而它的工作流程大概可以用以下四点来概括：

1. 开始工作，客户端浏览器先要与服务器建立连接，即是通过三次握手建立连接。在浏览器上最简单的就是点击一个超级链接，就触发了连接建立。

2. 连接建立后，客户端浏览器发送一个请求到服务器，这个过程其实是组装请求报文的过程，详细的报文格式与解析会在下节展开。

3. 服务器端接收到请求报文后，对报文进行解析，组装成一定格式的响应报文，返回给客户端。

4. 客户端浏览器接收到响应报文后，对其进行解析，并通过浏览器内核，按照一定的外观进行显示，然后与服务器断开连接。

解析HTTP报文

上节我们了解了http请求响应模型，那么具体请求与响应报文格式是怎样的，报文又是怎样被解析的？这节将详细展开讲述。想要深入理解web服务器就必须对http报文熟悉，正所谓练拳先练功，要研究tomcat服务器就要先对http报文有一定的了解。http报文是面向文本的，报文中每个字段都是一些ascii码串，它包括请求报文和响应报文。

首先看看http请求报文，一个http请求由三部分组成：请求行、请求头部、请求体。图2-2-6-4详细展示了一个http请求报文的结构与详细的字段意义。请求行，由请求方法字段、URL字段和http协议版本字段组成，他们用空格分隔；请求头部，包含若干个属性与属性值，他们通过冒号分隔，格式为“属性名：属性值”，服务器据此获取客户端的信息；请求体，一般在POST方法里使用，而不在GET方法中使用。它将表单中得组件格式化成param1=value1&param2=value2键值对组，即用来存放请求参数数据。但有时也用来存放请求URL。

请求方法中GET和POST是最常见的，除此之外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。当我们点击网页链接或在浏览器输入网址访问时，就是用了GET方法，请求参数和值附加在URL后面，用问号隔开，如，/index.jsp?id=10000，用GET方法传递的参数都能在地址栏上看到，大多浏览器对地址的字符长度做了限制，一般最多是1024个字符。所以，要传送大量数据的话，要选择用POST方法。POST方法允许客户端提交更多信息给服务器，它把请求参数封装到请求体中，可以传输大量数据，不会对数据大小进行限制，同时也不在地址栏显示参数。其它方法比较少用，不再展开，可查找相关资料。

请求头部常用的典型属性有以下几种：

1. User-Agent：客户端请求的浏览器类型，更确切地说是客户端应用程序的名称，不同版本、不同厂商的值都可能不相同。

2. Accept：告诉服务器客户端可识别的媒体类型列表。这个属性的值可以是一个或多个MIME类型的值，服务器可以根据这个判断发不发送这个媒体类型。

3. Host：为服务器提供客户端想要访问的那台机器的因特网主机名和端口号。

4. Cookie：用于传输客户端的cookie到服务器，服务器维护的session就是通过cookie附带的jsessionid值来区分的哪个客户端关联哪个session的。当然，我们还可以通过重写URL的方式将jsessionid附带在URL后面。

5. Referer：表示这个请求是从哪个URL过来的，可以让服务器知道客户端从哪里获得其请求的RUL。如果在A主页点击一个连接进入主页B，浏览器就会在请求中插入一个带有A的Referer头部。

6. Cache-Control：通过这个属性可以对缓存进行控制。它是一个缓存指令，指定了对某个对象的可缓存性有关的缓存特有指令。

图2-2-6-4 HTTP请求报文

接着看HTTP响应报文，跟请求报文一样由三部分组成：响应行、响应头、响应体。如图2-2-6-5，响应行包含协议及版本、状态码及其描述。响应头包含了若干个属性与属性值，他们通过冒号分隔，格式为“属性名：属性值”，客户端可以通过这个获取相关信息。响应体一般存放我们真正需要的文本。

响应状态码由三位数字组成，常用的状态码如下：

1. 200 OK：客户端请求成功。

2. 400Bad Request：客户端请求由语法错误，服务器无法识别。

3. 401 Unauthorized：请求未经授权。

4. 403Forbidden：服务器收到请求，但拒绝提供服务。

5. 404Not Found：请求资源不存在。

6. 500Internal Server Error：服务器发生不可预期的错误。

7. 503Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常。

常用的的响应报文头属性：

1. Cache-Control：服务器通过该报文头属性告诉客户端如何对响应的内容进行缓存，例如值为max-age=600，则表示客户端对响应内容缓存600秒，在此期间如果客户端再次访问该资源，直接从客户端缓存中获取内容，不再向服务器获取。

2. Location：这个属性用于网页重定向，例如服务器把重定向的地址添加到响应包头的这个属性，这样客户端浏览器解析报文后就直接重新跳转到这个地址。

3. Set-Cookie：利用这个属性服务器端可对客户端的cookie进行设置。

图2-2-6-5 HTTP响应报文

HTTP的版本

HTTP协议最初设计就是为了通过网络来支持客户端与服务器之间的事务处理。HTTP从1990年开始使用，最原始的版本是HTTP0.9，这是一个面向消息的简单协议，简单描述了客户端与服务器之间请求与响应的过程，客户端向服务器端请求连接，通过握手建立连接后向服务器发送GET方法访问，服务器端将响应结果返回给客户端，然后断开连接。HTTP1.1、HTTP1.0向下兼容HTTP0.9，是现在使用的HTTP协议的子集。

经过三年的发展，HTTP1.0被提出，它对HTTP0.9进行了很多改进：增加了请求类型，如HEAD、POST等；添加了HTTP版本号；添加了响应码表示处理的状态；使用MIME的消息标题和消息体格式来描述访问对象的数据类型和附加在后面的元信息，例如Content-type：text/html表明响应的消息实体是HTML文件，引入MIME后有利于扩大HTTP协议处理数据类型；增加了对代理的支持，HTTP0.9版本只支持直接连接交互，而HTTP1.0可以通过代理实现间接连接交互。

又经过四年的发展，产生了HTTP1.1。它是在HTTP1.0基础上实现的一次飞跃，主要在性能、安全、数据类型处理等方面进行了改进。提出服务器端缓冲对象的概念，在减少网络相同类型内容的反复传送、提高访问速度等方面有很大的提高。HTTP1.1采用了永久连接，这样很好地提高了性能，之前的版本都是默认响应完就直接关闭连接，下次又要重新建立连接。同时，它还允许客户端与服务器端对内容进行协商，突破HTTP1.0中服务器和IP一一对应的限制，可以通过主机名来决定由哪个服务器提供服务。

最后，为了适应WWW的发展需要，HTTP在功能和性能上进行了大量的改进。HTTPPng将是下一代的HTTP协议，在效率跟性能上都将有进一步的提高。

协议系列之HTTP协议