HTTP超文本【说白了就是字符串传输协议】传输协议,HTTP协议主要就是用来进行客户端和服务器之间进行通信的标准协议。HTTP主要规定了客户端如何与服务器建立连接、客户端如何从服务器请求数据、服务器如何响应请求,以及最后连接如何关闭。如:在浏览器中输入一个url,如http://www.taobao.com ,然后按下回车,一直到页面显示淘宝网的首页的过程就是一次HTTP的网络通信
建立连接:根据用户输入的URL地址,通过DNS、负载均衡等技术找到一台服务器,客户端与服务器的80端口建立一个TCP链接
进行请求:客户端向服务器发送消息,请求URL中指定的页面,要求执行指定的操作,包括 get post head
响应:服务器向客户端发送响应。响应以状态码开头。常见的状态码有:200、302、404、500
关闭连接:客户端或服务端都可以关闭连接。每个请求都是用一个单独的网络连接
HTTP/1.0:规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接,如果还要请求其他资源,就必须再新建一个连接。缺点:性能比较差
HTTP/1.1:引入了持久连接,即TCP连接默认不关闭,可以被多个请求复用(打电话,一件事描述完以后可以不直接挂断,持续一段时间,如果还有事情沟通可以再次进行沟通)
管道机制:在同一个TCP连接里面,客户端可以同时发送多个请求(好比在电话里可以一次性吩咐多件事),但是服务端还是顺序执行的
HTTP/2:基于 SPDY 协议,采用多路复用,即在一个连接里,客户端和服务器器都可以同时发送多个请求或回应,而且不用按照顺序一一对应。能这样做有一个前提,就是HTTP/2进行了二进制分帧,即 HTTP/2 会将所有传输的信息分割为更小的消息和帧(frame),并对它们采用二进制格式的编码,如:可以接收多个请求,如果某个请求处理了一半发现它难以处理,它可以先处理完简单的,最后再把之前处理的和剩下的一点处理完的组合在一起,一块发送
Header压缩就是压缩老板和员工之间的对话。
服务端推送就是员工事先把一些老板可能询问的事情提前发送到老板的手机(缓存)上。这样老板想要知道的时候就可以直接读取短信(缓存)了
HTTP/3:基于 UDP 实现,类似于微信语言,在通话之前,老板和下属之间并没有直接的建立可靠连接,即不需要拨通电话,而是拿起微信,直接通过语音直接下达了命令,缺点:安全性低
HTTPS:超文本传输安全协议。就是HTTP加上SSL/TLS加密处理(一般是SSL安全通信线路)+认证+完整性保护,HTTP和HTTPS是两个不同的协议,比如打电话,对通话内容进行了加密。它跟http协议一样都是应用层协议,都是工作在TCP协议之上。
HTTP的URL是由“http://”起始与默认使用端口80,而HTTPS的URL则是由“https://”起始与默认使用端口443。
HTTP不是安全的,而且攻击者可以通过监听和中间人攻击等手段,获取网站帐户和敏感信息等。HTTPS的设计可以防止前述攻击,在正确配置时是安全的。
本质上HTTPS协议就是在TCP协议之上又加了一层SSL协议
来实现了加密这个操作(不准确的说HTTPS就就是披着是SSL的皮的HTTP协议)
HTTP缺点:
a、通信使用明文不加密,内容可能被窃听
b、不验证通信方身份,可能遭到伪装
c、无法验证报文完整性,可能被篡改
【对称加密】
同一个密钥可以同时用作信息的加密和解密,这种加密方法称为对称加密,也被叫做共享密钥加密。这种方法在网络传输中有个问题,就是如何把密钥安全的交付给对方,因为http协议是明文传输(https协议在建立ssl加密时都是明文传输),所以密钥很容易被监听截取,从而失去密钥本身的意义了。
【公开密钥加密】
假设使用者为服务端,服务端有两个密钥,一个是私钥(只能自己悄悄咪咪看的,可以比喻成钥匙),一个是公钥(随便哪个看的都行,可以比喻成锁头)。服务端将公钥发给客户端,客户端使用公钥对要发送的信息进行加密,然后发送给服务器(用锁头把数据锁在箱子里),由于该信息是通过服务端的公钥进行加密的,只有服务端使用自己的私钥才能解析出来(用钥匙打开锁头,获取信息)。因为私钥是一直保持在服务端,而又只有私钥才能解析出公钥加密的内容,所以通过该种方法实现了数据的安全传输。 但是由于每次都要使用私钥去解析公钥,才能获取到数据,如果公钥很长的话,其中的运算量会很大,占用CPU性能,从而使得网络延迟加大。
HTTPS协议同时使用了这两种方式,即先通过公开密钥加密的方式产生一个对话密钥,在使用对话密钥进行对称加密的方式传输数据。
【SSL协议】
1:客户端向服务器发送请求
请求中包含
支持的SSL协议版本 客户端生成的随机数(第一个随机数) 支持的加密方法 支持的压缩方法
2:服务器接收到客户端请求,并且向客户端发送响应
响应包括
确认协议版本 服务器生产的随机数(第二个随机数) 确定加密的方法 服务器的证书(服务器的公钥在里面)
3:客户端接收到请求,对证书进行校验(校验证书的颁布机构,证书中的域名和实际域名是否一致,证书是否过期,如果不符合,浏览器
会显示警告),如果通过了校验,客户端将会发送回应
请求包括
客户端生成一个随机数,并且该随机数通过服务器的公钥进行加密(第三个随机数) 编码改变通知(表示之后的通信都会通过双方商定 的 加密算法
进行通信) 客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供服务器校验。
4:服务器接收到最后的回应之后,使用服务器的私钥来解析出客户端发送过来的第三个随机数,并且使用与客户端约定好的加密算法将一共三个随机数生成对话密钥。服务器返回响应
编码改变通知(表示之后的通信都会通过双方商定的加密算法进行通信) 服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供客户端
校验。
整个SSL协议的加密过程大致就是这样,加密对话的过程都是明文传输的(因为HTTPS还没带搭建起来的嘛)。
整个加密过程的核心就是客户端与服务器产生的三个随机数,这三个随机数是用于产生后续数据传输的加密密钥的。从上面的过程可以看出,这三个随机数都是可以被窃取的,但是由于第三个随机数使用了服务器的公钥进行了公开密钥加密传输,理论上只有使用服务器的私钥才能解析出第三个随机数。所以最后使用这三个随机数生成的对话私钥是安全的,之后的数据传输都会使用这个对话私钥进行加密(对称加密),从而保证了传输的安全性又保证了数据传输的效率。