【计算机网络】HTTP/HTTPS协议的区别

一、讲一下HTTP与HTTPS的区别

HTTP和HTTPS的主要区别在于HTTP协议传递的是明文数据，而HTTPS传递的是加密过的数据，也就是说HTTPS更具有安全性。也正由HTTPS需要保证安全性，所以它的性能要比HTTP差一点。

单说安全性肯定是不够的，我打算扩展讲一下 HTTPS是怎么解决安全性问题的,通过这些HTTP没有机制，反映出HTTPS与HTTP的区别。下面尝试把 HTTPS加密的过程推导出来。推导过程不涉及复杂的实现细节:如何安全地进行数据传输?

假设现在A和B要进行安全的通信，那么究竟怎样才算是安全的通信?很自然地会想到: A和B之间传递数据，这些数据只有A和B才看得懂，中间人就算截取了信息但也看不懂，这才算得上安全。

安全通信的处理手段

为了能让A和B才能看懂，就必须要对数据进行加密，而且首先想到的就是对称加密。对称加密的意思是A和B各持有一个相同的密钥，它们传递信息时会用密钥给信息加密,在消息到达端给消息解密,完成安全通信。在对称加密中又会涉及到加密算法的选择问题。现实世界中，通常是多个客户端面向一个服务器的情况，不可能让每个客户端和服务器之间都采用相同的加密算法，如果是这样那和没加密差不多。所以注定每个客户端和服务器之间都会采用不同的加密方式。如何让每个客户端与服务器之间都采用不同的加密方式?

要想对不同的机器使用不同的加密方式，最直接想到的就是使用随机数。也就说客户端和服务器之间每次都基于一个随机数产生加密算法。(具体实现时为了保证随机，用到还不止一个随机数)。这个产生加密算法的过程称之为协商，现在问题是协商的过程是透明的，也就是说中间人可以截获协商的过程，从而知道我们的加密方式。为了解决这个问题，我们需要对协商的过程进行加密。

如何对协商的过程进行加密?之所以能来到这一步, 是因为我们一开始就选择使用了对称加密,也就说一开始的对称加密导致了现在的问题，所以这时我们不能再使用对称加密了，否则会陷入死循环。在密码学领域，还有一种加密过程叫非对称加密,它的逻辑是这样的:通信双方一方持有私钥，一方持有公钥，经过私钥加密的信息，都能通过公钥进行解密。但是经过公钥加密的数据，只有私钥可以解密。按照非对称加密的规则，我们让服务器持有私钥，让客户端持有公钥。这样就能保证客户端给服务器发送消息的时候是安全的(相反，服务器给客户端发送消息就是不安全的)，我们可以把协商时重要的逻辑安排在客户端给服务器发送信息的过程中，从而保证了协商过程的安全性。

客户端如何获得公钥?现在用非对称加密算法解决了协商的安全问题，但是非对称加密的前提是客户端需要获得公钥，这又是一个问题了，客户端与服务器打交道之前是互不知道双方身份的，怎么才能让客户端获得公钥呢?也就只有两种办法:
方法一：客户端向服务器要公钥
方法二：客户端向一个远程的公共服务器获取公钥
方法2显然是不行的，尚且不说多了一个访问节点，如何找到公共服务器的地址也是一个待解决的问题，所以还是使用方法1。但是方法1存在一个问题:如果中间人把服务器发送给客户端的公钥调包了怎么办?也就是说客户端无法知道发送公钥的是否是正真的服务器。

引入第三方机构解决问题

客户端无法辨识服务端和中间人的问题称为”身份验证”问题,也就是说我们需要为服务器向客户端发送公钥的过程进行加密。这下完了，之前我们因遇到对称加密的瓶颈选择了非对称加密，现在使用非对称加密也遇到了瓶颈。显然这两种加密方式都是不可用的了，否则会再次陷入死循环。

接下来我们只好通过第三方机构的介入，解决这个问题。首先我们自己保存有第三方权威机构的公钥，然后第三方机构使用私钥对服务器将要发送给客户端的公钥进行加密,客户端接收到这个经加密的公钥后(数字证书)，就能通过自己保存的第三方机构公钥进行解密。

到这里为止，我们解释了HTTPS中使用到的对称加密，非对称加密，CA,数字证书的概念,但是还差一个叫数字签名的概念没有解释。

在现实生活中，CA不单止会给我们正常公司发放证书,还会给中间人的坏公司发放证书，如果中间人把发放的证书调包了怎么办?这时我们仍能用CA的私钥进行解密，但是证书已经被调包了。那么客户端怎样验证证书的真伪呢?答案是证书本身会告诉客户端如何辨认真伪。比方说证书上面有一个证书编号,还有一一个如何计算证书编号的方法,客户端可以根据计算证书编号的方法计算出自己要获得的证书的编号，然后把这个编号和证书.上的编号进行比对,如果一样证明没有被调包。

这里的证书编号指的就是数字签名，证书指的就是数字证书。
总结一下HTTPS : HTTPS 想要保证客户端与服务器之间的通信安全,就得使用对称加密算法进行加密。协商对称加密算法的过程通过非对称加密算法来保证。在非对称加密算法中，客户端获得公钥的过程需要第三方机构(CA)通过颁发数字证书保证安全性。总得来说通过这一系列机制协商出了-个对称加密算法后,客户端与服务器之间就能通过该算法进行安全的通信了。

二、在地址栏键入URL后，网络世界发生了什么?

1.获取域名的IP地址

首先我们要访问DNS服务器获得网站对应的IP地址，这时我们需要把DNS报文封装到一个UDP报文中，进而封装到网络层的数据包中，填上源IP,目的DNS服务器IP地址。接着封装链路层，填上网卡MAC地址和网关路由器MAC地址。接下来这个DNS请求报文就会经网关路由器发送给DNS服务器。
我们假设DNS服务器缓存有该网站的IP地址，(如果没有缓存 会进-步向更高级的DNS服务器索要IP地址)。接着DNS服务器会返回该域名的IP地址。

2.三次握手建立TCP连接

拿到了该网站的IP地址后就可以与该网站的服务器建立TCP连接了。建立TCP连接需要经过三次握手，过程如下：

本机的TCP首先生成一个不带任何数据，SYN 标志位为1,序号字段假设为client_ num的TCP报文,经过下层一系列网络栈后发送给目的 ip服务器。
该服务器接受到TCP请求报文后，会回应一个同意连接的TCP报文,这个报文的SYN标志位也会被置1,序号字段假设为server_ num, ACK响应字段为client_ num + 1。接受到同意连接的报文后，我方主机会进行响应，这次的TCP报文SYN位会被置0,序号字段为client num + 1, ACK响应字段为server + 1。并且这次的响应报文是可以携带数据的。

3.建立连接后的数据交互

在三次握手建立连接后，本机就可以向服务器发送HTTP请求了，服务器接受到了请求会做出响应，把请求的数据发送给本机浏览器，最终浏览器把服务器响应的数据渲染显示出来，我们就看到了五彩缤纷的网页。

三、GET请求和POST请求的区别

1. 从HTTP报文层面来看，GET请求将信息放在URL, POST将请求信息放在请求体中。这一点使得GET请求携带的数据量有限，因为URL本身是有长度限制的，而POST请求的数据存放在报文体中，因此对大小没有限制。而且从形式上看，GET请求把数据放URL上感觉不太安全，而POST请求把数据放在请求体里似乎安全一些。实际上想要获取POST请求中的内容还是很容易的，因此两者在安全性上其实没有太大差异，想要实现安全的信息传输还是得靠HTTPS。
2. 从数据库层面来看，GET符合幂等性和安全性，而POST请求不符合。这个其实和GET/POST请求的作用有关。按照HTTP的约定，GET请求用于查看信息，不会改变服务器上的信息;而POST请求用来改变服务器上的信息。正因为GET请求只查看信息，不改变信息，对数据库的一次或多次操作获得的结果是一致的， 认为它符合幂等性。安全性是指对数据库操作没有改变数据库中的数据。
3. 从其他层面来看，GET请求能够被缓存，GET请求能够保存在浏览器的浏览记录里，GET请求的URL能够保存为浏览器书签。这些都是POST请求所不具备的。缓存是GET请求被广泛应用的根本，他能够被缓存也是因为它的幂等性和安全性,除了返回结果没有其他多余的动作，因此绝大部分的GET请求都被CDN缓存起来了，大大减少了Web服务器的负担。

四、什么是Session，cookie和session的区别？

session是一种维持客户端与服务器端会话的机制。但是与cookie把会话信息保存在客户端本地不一样，session 把会话保留在浏览器端。

我们同样以登陆案例为例子讲解session的使用过程:

1. 首先用户在客户端浏览器发起登陆请求
2. 登陆成功后，服务端会把用户信息保存在服务端，并返回一个唯一的session标识给客户端浏览器。
3. 客户端浏览器会把这个唯一的session标识保存在起来
4. 以后再次访问web应用时，客户端浏览器会把这个唯一的session标识带上，这样服务端就能根据这个唯一标识找到用户信息。

看到这里可能会引起疑问:把唯一的 session标识返回给客户端浏览器，然后保存起来,以后访问时带上，这难道不是cookie吗?
没错，session 只是一种会话机制，在许多web应用中，session 机制就是通过cookie实现的。也就是说它只是使用了cookie的功能，并不是使用cookie完成会话保存。与cookie在保存客户端保存会话的机制相反, session 通过cookie的功能把会话信息保存到了服务端。
进一步地说，session 是一种维持服务端与客户端之间会话的机制，它可以有不同的实现。

以现在比较流行的小程序为例，阐述一个session的实现方案:

1. 首先用户登陆后，需要把用户登陆信息保存在服务端，这里我们可以采用redis。比如说给用户生成一个userToken,然后以userld作为键，以userToken作为值保存到redis中,并在返回时把userToken带回给小程序端。
2. 小程序端接收到userToken后把它缓存起来，以后每当访问后端服务时就把userToken带上。
3. 在后续的服务中服务端只要拿着小程序端带来的userToken和redis中的userToken进行比对，就能确定用户的登陆状态了。

session 和cookie有什么区别

1. cookie是浏览器提供的一种缓存机制，它可以用于维持客户端与服务端之间的会话
2. session指的是维持客户端与服务端会话的一种机制，它可以通过cookie实现，也可以通过别的手段实现。
3. 如果用cookie实现会话,那么会话会保存在客户端浏览器中
4. session机制提供的会话是保存在服务端的。