HTTP和HTTPS的区别

一、HTTP

HTTP（HyperText Transfer Protocol：超文本传输协议）是一种用于分布式、协作式和超媒体信息系统的应用层协议。 简单来说就是一种发布和接收 HTML 页面的方法，被用于在 Web 浏览器和网站服务器之间传递信息。

HTTP 默认工作在 TCP 协议 80 端口，另外还有 8000 和 8080 也很常用。用户访问网站 http:// 打头的都是标准 HTTP 服务。

HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。

HTTP会话分为三个阶段：

1. 客户端建立一条 TCP 连接（如果传输层不是 TCP，也可以是其他适合的连接）。
2. 客户端发送请求并等待应答。
3. 服务器处理请求并送回应答，回应包括一个状态码和对应的数据。

从 HTTP/1.1 开始，连接在完成第三阶段后不再关闭，客户端可以再次发起新的请求。这意味着第二步和第三步可以连续进行数次。

一个HTTP请求一般由四个部分组成：

1).HTTP请求的方法或动作，比如是GET请求还是POST请求。
2).正在请求的URL，就是请求的地址（我们输入的一般是网址）。
3).请求头，包含一些客户端环境信息，身份验证信息等。
4).请求体，也就是请求正文，请求正文中可以包含客户提交的查询字符信息，表单信息等等。

HTTP请求的两种方式：

• GET请求：一般用于信息获取，使用URL传递参数，对所发送信息的数量也有限制，一般在2000个字符，GET请求一般用于获取信息，换句话说，就是查询，查询不会影响数据本身。但是GET请求发送的信息对任何人都是可见的，这样对数据的保密性就比较低了。
• POST请求：一般用于修改服务器上的资源。对所发送信息的数量无限制。通过POST方法一般用来从表单发送数据，这些对数据对其他人是不可见的，所以相对于GET请求来说保密性就高得多。

一个HTTP响应一般由三部分组成：

1）一个数字和文字组成的状态码，用来显示请求是成功还是失败。
2）响应头，响应头也和请求头一样包含许多有用的信息，例如服务器类型，日期时间，内容类型和长度等等。
3）相应体，也就是响应正文。

HTTP状态码由3位数字构成：

首位数字定义了状态码的类型
1XX：信息类，表示收到Web浏览器请求，正在进一步的处理中。
2XX：成功，表示用户请求被正确接收，理解和处理。例如：200 OK。
3XX：重定向，表示请求没有成功，客户必须采取进一步的动作。
4XX：客户端错误，表示客户端提交的请求有错误。例如：404NOT Found，意味着请求中所引用的文档不存在。
5XX：服务器错误，表示服务器不能完成对请求的处理。

常见状态码：
301：被请求的资源已永久移动到新位置
400： 1、语义有误，当前请求无法被服务器理解。2、请求参数有误。
403：服务器已经理解请求，但是拒绝执行它。
404：请求失败，请求所希望得到的资源未被在服务器上发现。
408： 请求超时。
500： 服务器遇到了不知道如何处理的情况。
501： 此请求方法不被服务器支持且无法被处理。
503：服务器没有准备好处理请求。 常见原因是服务器因维护或重载而停机。
504：当服务器作为网关，不能及时得到响应时返回此错误代码。
505：服务器不支持请求中所使用的HTTP协议版本。

了解了上面的内容之后，那么问题来了，当我们在web浏览器的地址栏中输入： www.baidu.com，然后回车，到底发生了什么？
1.对www.baidu.com这个网址进行DNS域名解析，得到对应的IP地址
2.根据这个IP，找到对应的服务器，发起TCP的三次握手
3.建立TCP连接后发起HTTP请求
4.服务器响应HTTP请求，浏览器得到html文件
5.浏览器解析html代码，并请求html代码中的资源（如js、css图片等）（先得到html代码，才能去找这些资源）
6.浏览器对页面进行渲染呈现给用户
注：

• DNS域名解析采用的是递归查询的方式，过程是，先去找DNS缓存->缓存找不到就去找根域名服务器->根域名又会去找下一级，这样递归查找之后，找到了，给我们的web浏览器

• 为什么HTTP协议要基于TCP来实现？ TCP是一个端到端的可靠的面相连接的协议，HTTP基于传输层TCP协议不用担心数据传输的各种问题（当发生错误时，会重传）

• 最后一步浏览器是如何对页面进行渲染的？
  a）解析html文件构成 DOM树，
  b）解析CSS文件构成渲染树，
  c）边解析，边渲染 ，
  d）JS 单线程运行，JS有可能修改DOM结构，意味着JS执行完成前，后续所有资源的下载是没有必要的，所以JS是单线程，会阻塞后续资源下载

下面我们来详细看看这几个过程的具体细节：

1.域名解析

a）首先会搜索浏览器自身的DNS缓存（缓存时间比较短，大概只有1分钟，且只能容纳1000条缓存）

b）如果浏览器自身的缓存里面没有找到，那么浏览器会搜索系统自身的DNS缓存

c）如果还没有找到，那么尝试从 hosts文件里面去找

d）在前面三个过程都没获取到的情况下，就递归地去域名服务器去查找，具体过程如下

image.png

DNS优化：两个方面：DNS缓存、DNS负载均衡

2.TCP连接（三次握手）

拿到域名对应的IP地址之后，User-Agent（一般指浏览器）会以一个随机端口（1024<端口<65535）向服务器的WEB程序（常用的有httpd，nginx）等的80端口。这个连接请求（原始的http请求经过TCP/IP4层模型的层层封包）到达服务器端后（这中间有各种路由设备，局域网内除外），进入到网卡，然后是进入到内核的TCP/IP协议栈（用于识别连接请求，解封包，一层一层的剥开），还有可能要经过Netfilter防火墙（属于内核的模块）的过滤，最终达到WEB程序，最终建立了TCP/IP的连接

TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。
在运用此协议进行数据传输前都会进行连接的建立工作（三次握手）
当数据传输完毕，连接的双方都会通知对方要释放此连接（四次挥手）
tcp标志位有6种标志位
1.SYN（synchronous ）建立联机

2.ACK（acknowledgement）确认

3.PSH（push）传送

4.FIN（finsh）结束

5.RST（reset）重置

6.URG（urgent）紧急

图解TCP与UDP的三次握手与四次挥手过程

image.png

三次握手过程：

第一次握手：Client将标志位SYN置为1，ACK=0，随机产生一个值seq=J，并将该数据包发送给Server。

第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，确认号ack =J+1，随机产生序列号seq=K，并将该数据包发送给Client以确认连接请求。

第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，可以开始传输数据了。

image.png

四次挥手过程：

第一次挥手：当传输的数据到达尾部时，Client向Server发送FIN = 1标志位，seq = x,用来关闭Client到Server的数据传送。(Client进入FIN_WAIT_1状态)

第二次挥手：Server收到FIN后，发送ACK = 1，确认序号ack = x+1，seq=y给Client，Server进入CLOSE_WAIT状态。

第三次挥手：数据传输完成后，Server发送FIN = 1，ACK=1,ack=x+1,seq=z用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送ACK=1,ack=z+1,seq=x+1给Server，Server进入CLOSED状态，完成四次挥手。

为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
因为当Server端收到Client端的SYN连接请求报文后，可以把ACK和SYN放在一个报文里发送给客户端。(其中ACK报文是用来应答的，SYN报文是用来同步的。)但是关闭连接时，当Server端收到FIN报文时，仅仅表示Client不再发送数据了但是还能接收数据，Server也未必全部数据都发送给对方了，很可能并不会立即关闭SOCKET，所以ACK和FIN一般都会分开发送。会先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文。

3.建立TCP连接之后，发起HTTP请求

HTTP请求报文由三部分组成：请求行，请求头和请求正文

请求行：用于描述客户端的请求方式，请求的资源名称以及使用的HTTP协议的版本号（例：GET/books/java.html HTTP/1.1）

请求头：用于描述客户端请求哪台主机，以及客户端的一些环境信息等

注：这里提一个请求头 Connection，Connection设置为 keep-alive用于说明 客户端这边设置的是，本次HTTP请求之后并不需要关闭TCP连接，这样可以使下次HTTP请求使用相同的TCP通道，节省TCP建立连接的时间

请求正文：当使用POST, PUT等方法时，通常需要客户端向服务器传递数据。这些数据就储存在请求正文中（GET方式是保存在url地址后面，不会放到这里）

4.服务器端响应http请求，浏览器得到html代码

HTTP响应也由三部分组成：状态码，响应头和实体内容

状态码：状态码用于表示服务器对请求的处理结果

列举几种常见的：200（没有问题） 302（要你去找别人） 304（要你去拿缓存） 307（要你去拿缓存） 403（有这个资源，但是没有访问权限） 404（服务器没有这个资源） 500（服务器这边有问题）

若干响应头：响应头用于描述服务器的基本信息，以及客户端如何处理数据

实体内容：服务器返回给客户端的数据

注：html资源文件应该不是通过 HTTP响应直接返回去的，应该是通过nginx通过io操作去拿到的吧

5.浏览器解析html代码，并请求html代码中的资源

浏览器拿到html文件后，就开始解析其中的html代码，遇到js/css/image等静态资源时，就向服务器端去请求下载（会使用多线程下载，每个浏览器的线程数不一样），这是时候就用上 keep-alive特性了，建立一次HTTP连接，可以请求多个资源，下载资源的顺序就是按照代码里面的顺序，但是由于每个资源大小不一样，而浏览器又是多线程请求请求资源，所以这里显示的顺序并不一定是代码里面的顺序。

6.浏览器对页面进行渲染呈现给用户

最后，浏览器利用自己内部的工作机制，把请求的静态资源和html代码进行渲染，渲染之后呈现给用户

浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树，然后解析CSS文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂，涉及到两个概念: reflow(回流)和repain(重绘)。DOM节点中的各个元素都是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为relow;当盒模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个过程称为repain。页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的，尤其是在移动设备上，它会破坏用户体验，有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。

JS的解析是由浏览器中的JS解析引擎完成的。JS是单线程运行，JS有可能修改DOM结构，意味着JS执行完成前，后续所有资源的下载是没有必要的，所以JS是单线程，会阻塞后续资源下载

总结一次完整的HTTP请求过程：
　　域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户

二、HTTPS

HTTPS（Hypertext Transfer Protocol Secure：超文本传输安全协议）是一种透过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
HTTPS 默认工作在 TCP 协议443端口，它的工作流程一般如以下方式：

1. TCP 三次同步握手
2. 客户端验证服务器数字证书
3. DH 算法协商对称加密算法的密钥、hash 算法的密钥
4. SSL 安全加密隧道协商完成
5. 网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。

HTTPS 的工作原理

我们都知道 HTTPS 能够加密信息，以免敏感信息被第三方获取，所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用 HTTPS 协议。

image.png

1. 客户端发起 HTTPS 请求
   用户在浏览器里输入一个 https 网址，然后连接到 server 的 443 端口。

2. 服务端的配置
   采用 HTTPS 协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl 就是个不错的选择，有 1 年的免费服务)。
   这套证书其实就是一对公钥和私钥，如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3. 传送证书
   这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4. 客户端解析证书
   这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。
   如果证书没有问题，那么就生成一个随机值，然后用证书对该随机值进行加密，就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5. 传送加密信息
   这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6. 服务端解密信息
   服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密，所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 传输加密后的信息
   这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

8. 客户端解密信息
   客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容，整个过程第三方即使监听到了数据，也束手无策。

三、HTTP 与 HTTPS 区别

1. HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
2. 使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
3. HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
4. http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
5. HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。