HTTP 图解笔记

一 .简单了解

1.1HTTP背景

1.1.1 HTTP的诞生

1989 年 3 月，互联网还只属于少数人。在这一互联网的黎明期， HTTP 诞生了。

CERN（欧洲核子研究组织）的蒂姆 • 伯纳斯 - 李（Tim BernersLee）博士提出了一种能让远隔两地的研究者们共享知识的设想。
最初设想的基本理念是：借助多文档之间相互关联形成的超文本（HyperText），连成可相互参阅的 WWW（World Wide Web，万维网）。
现在已提出了 3 项 WWW 构建技术，分别是：把 SGML（Standard Generalized Markup Language，标准通用标记语言）作为页面的文本标记语言的 HTML（HyperText Markup Language，超文本标记语言）；作为文档传递协议的 HTTP ；指定文档所在地址的 URL（Uniform Resource Locator，统一资源定位符）。

1.1.2 HTTP的版本信息

HTTP/0.9
HTTP 于 1990 年问世。那时的 HTTP 并没有作为正式的标准被建立。现在的 HTTP 其实含有 HTTP1.0 之前版本的意思，因此被称为 HTTP/0.9。
HTTP/1.0
HTTP 正式作为标准被公布是在 1996 年的 5 月，版本被命名为 HTTP/1.0，并记载于 RFC1945。虽说是初期标准，但该协议标准至今仍被广泛使用在服务器端。
HTTP/1.1
1997 年 1 月公布的 HTTP/1.1 是目前主流的 HTTP 协议版本。当初的标准是 RFC2068，之后发布的修订版 RFC2616 就是当前的最新版本。

1.2 网络的基础TCP/IP

要想要了解HTTP，首先需要了解TCP/IP协议族。通常我们使用的网络是在TCP/IP协议族的基础上运作的，而HTTP只是其内部子集。

1.2.1 何为协议

计算机与网络设备要相互通信，双方就必须基于相同的方法。比如，如何探测到通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要事先确定。不同的硬件、操作系统之间的通信，所有的这一切都需要一种规则。而我们就把这种规则称为协议（protocol）。
TCP/IP是互联网相关的各类协议族的总称

1.2.1 TCP/IP的分成管理

TCP/IP协议族按层次分别分为以下4层：应用层，传输层，网络层和数据链路层。将各个层次分开后，当某个地方需要修改时，不需要整体都替换掉，只需要把变动的层次替换即可。
各层次功能作用如下：

应用层
应用层决定了向用户提供应用服务时通信的活动。
TCP/IP 协议族内预存了各类通用的应用服务。比如，FTP（File Transfer Protocol，文件传输协议）和 DNS（Domain Name System，域名系统）服务就是其中两类。
HTTP 协议也处于该层。
传输层
传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。
在传输层有两个性质不同的协议：TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Data Protocol，用户数据报协议）。
网络层（又名网络互连层）
网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（所谓的传输路线）到达对方计算机，并把数据包传送给对方。
与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线
链路层（又名数据链路层，网络接口层）
用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC（Network Interface Card，网络适配器，即网卡），及光纤等物理可见部分（还包括连接器等一切传输媒介）。硬件上的范畴均在链路层的作用范围之内。

发送端在层与层之间传输数据时，每经过一层时必定会被打上一个该层所属的首部信息。反之，接收端在层与层传输数据时，每经过一层时会把对应的首部消去。
这种把数据信息包装起来的做法称为封装（encapsulate）。

1.3 HTTP密切相关的协议：IP、TCP和DNS

1.3.1 负责传输的IP协议

IP（Internet Protocol）网际协议位于网络层，几乎所有使用网络的系统都会使用到IP协议。在TCP/IP协议族中IP就指的是网际协议。需要注意的是：IP协议与IP地址并非同一种东西
IP协议的作用是把各种数据包传输给对方，然而，需要保证确实传送到对方那里，这需要满足各类条件。在这其中，最重要的两个条件莫过于IP地址与MAC地址（Media Access Control Address）。IP地址指明了节点被分配到的地址，MAC地址则是网卡所属的固定地址。IP地址可以和MAC地址进行配对。IP地址可变换，但是MAC地址基本上不会更改。传输过程如下：

IP 间的通信依赖 MAC 地址。在网络上，通信的双方在同一局域网（LAN）内的情况是很少的，通常是经过多台计算机和网络设备中转才能连接到对方。而在进行中转时，会利用下一站中转设备的 MAC 地址来搜索下一个中转目标。这时，会采用 ARP 协议（Address Resolution Protocol）。ARP 是一种用以解析地址的协议，根据通信方的 IP 地址就可以反查出对应的 MAC 地址。

1.3.2 确保可靠性的TCP协议

I按层次划分，TCP属于传输层，提供可靠的字节流服务。

字节流服务：
所谓的字节流服务（Byte Stream Service）是指，为了方便传输，将大块数据分割成以报文段（segment）为单位的数据包进行管理。而可靠的传输服务是指，能够把数据准确可靠地传给对方。
TCP
TCP 协议为了更容易传送大数据才把数据分割，而且 TCP 协议能够确认数据最终是否送达到对方。
三次握手
为了准确无误地将数据送达目标处，TCP 协议采用了三次握手（three-way handshaking）策略；在使用TCP协议把数据包传送出去后，TCP一定会想对方确认是否成功送达。在三次握手的过程中，使用了TCP的标志（flag） ----SYN(synchronize)和ACK(acknowledgement)。过程如下：

发送端首先发送一个带 SYN 标志的数据包给对方。接收端收到后，回传一个带有 SYN/ACK 标志的数据包以示传达确认信息。最后，发送端再回传一个带 ACK 标志的数据包，代表“握手”结束。
若在握手过程中某个阶段莫名中断，TCP 协议会再次以相同的顺序发送相同的数据包
当然，除了三次握的协议，TCP协议同时还有其他的各种手段来保证通信的可靠性。

1.3.2 负责域名解析的DNS服务

DNS（Domain Name System）服务是和 HTTP 协议一样位于应用层的协议。它提供域名到 IP 地址之间的解析服务。一张图了解DNS解析：

再知道以上协议后，总结一下:

1.4 URL与URI

URL：我们平时上网时输入的网址
URI：统一资源标识符（Uniform Resource Identifier）
URI 用字符串标识某一互联网资源，而 URL 表示资源的地点（互联网上所处的位置）。可见 URL 是 URI 的子集。

表示指定的 URI，要使用涵盖全部必要信息的绝对 URI、绝对 URL 以及相对 URL。相对 URL，是指从浏览器中基本 URI 处指定的 URL，形如 /image/logo.gif。
让我们先来了解一下绝对 URI 的格式。

在上面图片中，登录信息（认证）意思为：指定用户名和密码作为服务器端获取资源时必要的登录信息。所以此项为可选项。

二.简单的HTTP协议

在使用HTTP协议时，必有一端为客户端一端为服务器端，请求必定由客户端发出，服务器端进行回复相应。

2.1 客户端与服务器端之间的通信

2.1.1 客户端请求

首先展示一个基本的请求示例：

    GET /index.htm HTTP/1.1
    Host:hackr.jp

分析一波：

首行GET表示请求访问服务器的类型，统称为方法（method），随后的/index.html指明了请求访问的资源对象，也叫作请求URL(request=URL)。最后的HTTP/1.1 即为使用的HTTP版本

再来看一个POST请求的示例：

    POST /form/entry  HTTP/1.1
    Host:hackr.jp
    Connection:keep-alive
    Content-Type:application/x-www-form-urlencoded
    Content_Length:16
    name=ueno&age=37

分析一波：

前一行同如上分析，中间四行为请你去的首部字段（以后会讲到），最后一行为post请求的内容实体。

2.1.1 服务器端返回

先看一个例子：

    HTTP/1.1 200 OK
    Date Tue,10 Jul 2018 06:50:15 GMT
    Content-Length:362
    Content-Type: text/html
    
    <html>
    //.......

解释：

在起始行开头的 HTTP/1.1 表示服务器对应的 HTTP 版本。
紧挨着的 200 OK 表示请求的处理结果的状态码（status code）和原因短语（reason-phrase）。下一行显示了创建响应的日期时间，是首部字段（header field）内的一个属性。
接着以一空行分隔，之后的内容称为资源实体的主体（entity body）。

2.2 HTTP是不保存状态的协议

HTTP 是一种不保存状态，即无状态（stateless）协议。HTTP 协议自身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个级别，协议对于发送过的请求或响应都不做持久化处理。
HTTP/1.1 虽然是无状态协议，但为了实现期望的保持状态功能，于是引入了 Cookie 技术。有了 Cookie 再用 HTTP 协议通信，就可以管理状态了。有关 Cookie 的详细内容稍后讲解。

2.3 告知服务器意图的HTTP方法

GET 获取资源
GET方法用来其你去已被URI四倍的资源。指定的资源经服务器端解析后返回响应内容。简而言之，如果是静态资源，则保持原样返回；如果是CGI（Common Gateway Interface，通用网关接口）那样的程序，则返回经过执行后的输出结果。
POST 传输实体主体
虽然用 GET 方法也可以传输实体的主体，但一般不用 GET 方法进行传输，而是用 POST 方法。虽说 POST 的功能与 GET 很相似，但 POST 的主要目的并不是获取响应的主体内容。
PUT 传输文件
PUT方法用来传输文件，就像FTP】协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存到请求URI指定的位置。注意：由于HTTP/1,1 的PUT方法自身不带有验证机制，任何人哦度看可以上传文件，存在安全性问题，因此一般网站都不采用该方法。若配合Web应用程序的验证机制，或者架构设计采用REST（REpresentational State Transfer，表征状态转移）标准的同类Web网站，就可能会开放使用PUT方法。
HEAD 获得报文的首部
HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的日期时间等。
DELETE 删除文件
DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方法按请求 URI 删除指定的资源。注意：原因通PUT方法一样，很少使用到，
OPTIONS：询问支持的方法
OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法。
TRACE：追踪路径
TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方法。TRACE 方法本来就不怎么常用，再加上它容易引发 XST（Cross-Site Tracing，跨站追踪）攻击，通常就更不会用到了。
CONNECT：要求用隧道协议连接代理
CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。

在以往的版本中，还存在着LINK和UNLINK两种方法，分别作用于建立和资源之间的联系与断开连接关系，但是在HTTP/1.1中被废弃，不再支持，所以不讨论。

2.4 持久连接与管线化

在传统的HTTP协议中，每进行一次HTTP通信就要断开一次TCP连接，当一个页面有大量请求时，每一次请求都会造成无谓的TCP连接的建立与断开，增加了通信的开销。
为了解决这个问题，在HTTP/1.1和一部分的HTTP/1.0想出了持久连接（HTTP Persistent Connections，也称为 HTTP keep-alive 或 HTTP connection reuse）的方法。其特点为，只要任意一端没有明确提出断开连接，则保持TCP连接状态。

当解决持久连接问题后，人们发现，以前发送请求后需要等待并收到相应才能发送下一个请求，但当持久连接出现后，使得管线化成为了可能，不用等待响应即可发送下一个请求。

三.HTTP报文内的HTTP信息

用户HTTP协议交互的信息被称为HTTP报文。请求端（客户端）的HTTP报文叫做请求报文，响应端（服务器端）的叫做响应报文。

3.1 编码提升传输速率

3.1.1 报文主体和实体主体的差异

在提及编码之前，需要先理解报文主题和实体主题之间的差距

报文（message）
是 HTTP 通信中的基本单位，由 8 位组字节流（octet sequence，其中 octet 为 8 个比特）组成，通过 HTTP 通信传输。
实体（entity）
作为请求或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。

HTTP 报文的主体用于传输请求或响应的实体主体。
通常，报文主体等于实体主体。只有当传输中进行编码操作时，实体主体的内容发生变化，才导致它和报文主体产生差异。报文和实体这两个术语在之后会经常出现，请事先理解两者的差异。

3.1.2 压缩传输的内容编码

内容编码指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。
常用的内容编码有以下几种：

gzip （GNU zip）
conpress （UNIX 系统的标准亚索）
deflate （zlib）
identity（不进行编码）

3.1.3 分割发送的分块传输编码

在HTTP通信过程中，请求的编码实体资源尚未全部传输完成之前，浏览器是无法显示页面的。在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。这种把实体主体分块的功能称为分块传输编码（Chunked Transfer Coding）
分块传输编码会将实体主体分成多个部分（块）。每一块都会用十六进制来标记块的大小，而实体主体的最后一块会使用“0(CR+LF)”来标记。

3.2 发送多种数据的多部分对象集合

HTTP 协议中也采纳了多部分对象集合，发送的一份报文主体内可含有多类型实体。通常是在图片或文本文件等上传时使用。
多部分对象集合包含的对象如下。

multipart/form-data
在 Web 表单文件上传时使用。

    Content-Type: multipart/form-data; boundary=AaB03x 
    --AaB03x 
    Content-Disposition: form-data; name="field1"
    Joe Blow 
    --AaB03x 
    Content-Disposition: form-data; name="pics"; filename="file1.txt" Content-Type: text/plain
    ...（file1.txt的数据）... 
    --AaB03x--

multipart/byteranges
状态码 206（Partial Content，部分内容）响应报文包含了多个范围的内容时使用。

    HTTP/1.1 206 Partial Content 
    Date: Fri, 13 Jul 2012 02:45:26 GMT 
    Last-Modified: Fri, 31 Aug 2007 02:02:20 GMT 
    Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
    
    --THIS_STRING_SEPARATES
    Content-Type: application/pdf 
    Content-Range: bytes 500-999/8000
    ...（范围指定的数据）... 
    --THIS_STRING_SEPARATES 
    Content-Type: application/pdf 
    Content-Range: bytes 7000-7999/8000

    ...（范围指定的数据）... 
    --THIS_STRING_SEPARATES--

在 HTTP 报文中使用多部分对象集合时，需要在首部字段里加上 Content-type。有关这个首部字段，我们稍后讲解。
使用 boundary 字符串来划分多部分对象集合指明的各类实体。在 boundary 字符串指定的各个实体的起始行之前插入“--”标记（例如：-AaB03x、--THIS_STRING_SEPARATES），而在多部分对象集合对应的字符串的最后插入“--”标记（例如：--AaB03x--、-THIS_STRING_SEPARATES--）作为结束。

3.2 获取部分内容的范围请求

在原来，下载一样文件的过程中，如果出现网络错误导致下载失败，往往需要重头开始。为了解决这个问题，需要一种可恢复的机制。所谓恢复值得能从之前下载中断处恢复下载。如图：

执行范围请求时，会用到首部字段Range来指定资源的byte范围。byte范围的指定形式如下：

5001~10000字节

    Range:byte=5001-10000

从5001字节之后全部的

    Range:byte=5001-

从一开始到3000字节和5000-7000字节的多重范围

    Range:byte=-3000,5000~7000

四.返回结果的HTTP状态码

状态码的类别：

状态码	类别	原因短语
1XX	Informational（信息性状态码）	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	所需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出现错误

4.1 2XX成功

200 OK

表示从客户端发来的请求在发服务器端被正常处理了。

204 NO Content

该状态码代表服务器接受的请求已成功处理，但在返回的响应报文中不含实体的主体部分，另外也不允许返回任何实体的主体。

206 Partial Content

该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求。响应报文中包含由Content-Range指定范围的实体内容。

4.2 3XX 重定向

3XX响应结果表明浏览器需要自行某些特殊的处理以正确处理请求。

301 Moved Permanently

永久性重定向。该状态码表示请求的资源已被分配了新的URI，以后应使用资源现在所指的URI。

302 Found

临时性重定向。该状态码表示请求的资源已被分配了新的 URI，希望用户（本次）能使用新的 URI 访问。

303 See Other

该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET 方法定向获取请求的资源。

当 301、302、303 响应状态码返回时，几乎所有的浏览器都会把 POST 改成 GET，并删除请求报文内的主体，之后请求会自动再次发送。
301、302 标准是禁止将 POST 方法改变成 GET 方法的，但实际使用时大家都会这么做。

304 Not Modified

该状态码表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况。304 状态码返回时，不包含任何响应的主体部分。304 虽然被划分在 3XX 类别中，但是和重定向没有关系。

附带条件的请求是指采用 GET 方法的请求报文中包含 If-Match，If-ModifiedSince，If-None-Match，If-Range，If-Unmodified-Since 中任一首部。

307 Temporary Redirect

临时重定向。该状态码与 302 Found 有着相同的含义。尽管 302 标准禁止 POST 变换成 GET，但实际使用时大家并不遵守。
307 会遵照浏览器标准，不会从 POST 变成 GET。但是，对于处理响应时的行为，每种浏览器有可能出现不同的情况。

4.3 4XX 客户端错误

4XX 的响应结果表明客户端是发生错误的原因所在。

400 Bad Request

该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，浏览器会像 200 OK 一样对待该状态码。

401 Unauthorized

该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、 DIGEST 认证）的认证信息。另外若之前已进行过 1 次请求，则表示用户认证失败。
返回含有 401 的响应必须包含一个适用于被请求资源的 WWWAuthenticate 首部用以质询（challenge）用户信息。当浏览器初次接收到 401 响应，会弹出认证用的对话窗口。

403 Forbidden

该状态码表明对请求资源的访问被服务器拒绝了。服务器端没有必要给出拒绝的详细理由，但如果想作说明的话，可以在实体的主体部分对原因进行描述，这样就能让用户看到了。

404 Not Found

该状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。

4.4 5XX 服务器错误

5XX 的响应结果表明服务器本身发生错误。

500 Internal Server Error

该状态码表明服务器端在执行请求时发生了错误。也有可能是 Web 应用存在的 bug 或某些临时的故障。

503 Service Unavailable

该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入 RetryAfter 首部字段再返回给客户端。

五. 与HTTP协作的Web服务器

代理

代理服务器的基本行为就是接收客户端发送的请求后转发给其他服务器。代理不改变请求 URI，会直接发送给前方持有资源的目标服务器。
在 HTTP 通信过程中，可级联多台代理服务器。请求和响应的转发会经过数台类似锁链一样连接起来的代理服务器。转发时，需要附加 Via 首部字段以标记出经过的主机信息。

使用代理服务器的理由有：利用缓存技术（稍后讲解）减少网络带宽的流量，组织内部针对特定网站的访问控制，以获取访问日志为主要目的，等等。
代理有多种使用方法，按两种基准分类。一种是是否使用缓存，另一种是是否会修改报文。

缓存代理
代理转发响应时，缓存代理（Caching Proxy）会预先将资源的副本（缓存）保存在代理服务器上。
当代理再次接收到对相同资源的请求时，就可以不从源服务器那里获取资源，而是将之前缓存的资源作为响应返回。
透明代理
转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理（Transparent Proxy）。反之，对报文内容进行加工的代理被称为非透明代理。

网关

png)

网关的工作机制和代理十分相似。而网关能使通信线路上的服务器提供非 HTTP 协议服务。
利用网关能提高通信的安全性，因为可以在客户端与网关之间的通信线路上加密以确保连接的安全。比如，网关可以连接数据库，使用 SQL 语句查询数据。另外，在 Web 购物网站上进行信用卡结算时，网关可以和信用卡结算系统联动。

隧道

隧道可按要求建立起一条与其他服务器的通信线路，届时使用 SSL 等加密手段进行通信。隧道的目的是确保客户端能与服务器进行安全的通信。
隧道本身不会去解析 HTTP 请求。也就是说，请求保持原样中转给之后的服务器。隧道会在通信双方断开连接时结束。

六. HTTP首部

HTTP 首部字段根据实际用途被分为以下 4 种类型：

通用首部字段（General Header Fields）
请求报文响应报文两方都会使用的首部
请求首部字段（Request Header Fields）
从客户端想服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
响应首部字段（Response Header Fields）
从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
实体首部字段（Entity Header Fields）
针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

6.1 首部字段一览

通用首部字段

请求首部字段

响应首部字段

实体首部字段

七. HTTPS

传统HTTP的缺点

通信过程中使用明文（不加密），内容可能会被窃听
现如今的各种抓包工具Fidder、Wireshark。等等都可以拿到请求数据。
- 机密处理防止监听
  由于HTTP协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或 TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。
  用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP 通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS（HTTP Secure，超文本传输安全协议）或 HTTP over SSL。
- 对内容加密
  但由于该方式不同于 SSL 或 TLS 将整个通信线路加密处理，所以内容仍有被篡改的风险。稍后我们会加以说明。
不验证通信方的身份，因此有可能遭遇伪装
- 任何人都可以发送请求，容易遭受DOS攻击
- 使用查看对手的证书
  证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方（服务器或客户端）持有的证书，即可判断通信方的真实意图，通过使用证书，以证明通信方就是意料中的服务器。这对使用者个人来讲，也减少了个人信息泄露的危险性。
  另外，客户端持有证书即可完成个人身份的确认，也可用于对 Web 网站的认证环节。
无法证明报文的完整性，所以有可能以遭篡改
- 接收到的内容可能有误
  从某个 Web 网站上下载内容，是无法确定客户端下载的文件和服务器上存放的文件是否前后一致的。文件内容在传输途中可能已经被篡改为其他的内容。即使内容真的已改变，作为接收方的客户端也是觉察不到的，类似于这种攻击称为中间人攻击（Main-in-the-Middle attack，MITM）
- 防止篡改的办法
  虽然有使用 HTTP 协议确定报文完整性的方法，但事实上并不便捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校验的方法，以及用来确认文件的数字签名方法。但这也不是万能的办法，因为存在可能MD5本身被篡改的可能。

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

需要注意的是，HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL和TLS协议代替而已。可以说HTTPS是身披SSL外壳的HTTP。通常HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信。
当使用了SSL后，HTTP就拥有了HTTPS的加密，证书和完整性保护这些功能。

加密技术

SSL 采用一种叫做公开密钥加密（Public-key cryptography）的加密处理方式。近代的加密方法中加密算法是公开的，而密钥却是保密的。通过这种方式得以保持加密方法的安全性。
加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。加密和解密同用一个密钥的方式称为共享密钥加密（Common key crypto system），也被叫做对称密钥加密。如果密钥被攻击者获得，那加密也就失去了意义。所以如何传递密钥则很重要。

解决传递密钥的问题

使用两把密钥的公开密钥加密
公开密钥加密方式很好地解决了共享密钥加密的困难。
公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。
使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。
另外，要想根据密文和公开密钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。退一步讲，如果能对一个非常大的整数做到快速地因式分解，那么密码破解还是存在希望的。但就目前的技术来看是不太现实的。
HTTPS 采用混合加密机制
HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比，其处理速度要慢。
所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

证明公开密钥正确性的证书

遗憾的是，公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。为了解决上述问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。

《图解HTTP》的一些总结