HTTP协议、
HTTP协议(超文本传输协议)是一种网络通信协议,它允许将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器。默认端口:80。是一种应用层协议。
HTTP工作过程、
当我们在浏览器中输入一个 “网址”, 此时浏览器就会给域名对应的服务器发送一个 HTTP 请求. 对方服务器收到这个请求之后, 经过计算处理, 就会返回一个 HTTP 响应。

事实上, 当我们访问一个网站的时候, 可能涉及不止一次的 HTTP 请求/响应 的交互过程。
HTTP协议的主要特点、
- 1、支持客户/服务器模式。
- 2、简单快速:客户向服务器请求服务时,只需传送请求方法和路径。请求方法常用的有GET、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模小,因而通信速度很快。
- 3、灵活:HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
- 4、无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。
- 5、无状态:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。
HTTP 协议格式、

注意: 为什么 HTTP 报文中要存在空行呢?
- 因为 HTTP 协议并没有规定报头部分的键值对有多少个,使用空行就相当于是报文的结束标记或报文和正文之间的分隔符
- HTTP 在传输层依赖 TCP 协议,TCP 是面向字节流的。如果没有这个空行,就会出现”粘包问题“
请求(Request)格式、

响应(Response)格式、

Https协议、
HTTPS协议是一种通过计算机网络进行安全通信的传输协议,经由HTTP进行通信,利用SSL/TLS建立全信道,加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证,同时保护交换数据的隐私与完整性。默认端口:443
HTTPS协议的主要特点
- 1、内容加密:采用混合加密技术,即对称加密和非对称加密,中间者无法直接查看明文内容
- 2、验证身份:通过证书认证客户端访问的是自己的服务器
- 3、保护数据完整性:防止传输的内容被中间人冒充或者篡改
- 4、SSL证书需要购买申请,功能越强大的证书费用越高
- 5、SSL证书通常需要绑定IP,不能在同一IP上绑定多个域名,IPv4资源不可能支撑这个消耗
- 6、HTTPS连接缓存不如HTTP高效,流量成本高
- 7、HTTPS协议握手阶段比较费时,对网站的响应速度有影响,影响用户体验。
- 注:使用哪种协议比较好?比较好的方式是采用分而治之,类似12306网站的主页使用HTTP协议,有关于用户信息等方面使用HTTPS。
对称加密 & 非对称加密、
对称加密:有一段秘钥,能通过它来加密一段信息,形成一段密文,而这段密文是不能读取的,想要读取这段密文就需要通过加密它的秘钥来解密,还原成原始信息。就是一个门只能用一把钥匙来反锁和打开。对称加密加解密速度较快。

用对称加密能解决消息传输中的安全问题吗?很显然是不能的,因为对称加密进行加密和解密需要用到相同的秘钥,而这把秘钥无论是由客户端产生,还是由服务器产生都需要将这把秘钥传送给对方,这样对方才能解密你所传输的密文,但是,秘钥是需要传送给对方的,也就是说秘钥同样在传输的过程中是能够被拦截的,除非能够直接把秘钥送到对方而不经过网络传输,很显然这样是不现实的,所以对称加密并不能解决数据传输中的安全问题。那我们再来看看非对称加密。
非对称加密:有一个公钥和与之配对的私钥,用公钥加密的数据只能用私钥来进行解密,使用私钥加密的数据只能通过公钥进行解密。非对称加密加解密速度较慢。

那使用非对称加密能解决数据传输过程中的安全问题吗?很显然也是不行的,与对称加密一样,产生秘钥的一方需要将公钥传给对方,双方才能以这个秘钥为基础来进行通信,那在传输的过程中黑客仍然能够截取到所传输的公钥,客户端通过公钥加密数据发送给服务器,而通过公钥加密的数据只能用私钥解密,但黑客只有公钥,所以从客户端发送给服务器的消息可以认为是安全的,它不会被轻易读取,但是服务器用私钥加密传送给客户端的消息就不够安全了,因为黑客和客户端都拥有公钥,都可以对服务器发送的消息进行解密。所以用对称加密的方法只能解决单向的数据加密问题,并且消息仍是没有验证其完整性和真实性的,黑客仍然可以通过中间人攻击,所以非对称加密也不够安全。
对称加密+非对称加密:问题解决。

客户端拥有秘钥A,服务器拥有公钥B和私钥C,首先,客户端向服务器发送请求,服务器接到请求,响应请求并把它的公钥B传给客户端,客户端接收到公钥B后用公钥B加密秘钥A,形成一段密文,然后把密文传给服务器,而公钥加密的密文只能用私钥解密,但我们只传输过公钥,所以只有服务器拥有私钥,能够解密这段密文得到秘钥A,这样就只有客户端和服务器这个秘钥A了,中间没有任何人拥有秘钥A,然后客户端和服务器的通信就可以通过秘钥A来进行加密解密,这样就保证了数据传输过程中的加密问题。
但是这样就能保证数据传输的安全了吗?并不能,为什么?因为没有验证消息的真实性。这样黑客是不是仍然可以通过中间人攻击获取到秘钥?
客户端向服务器发送请求,然后服务器响应请求并返回公钥,这时黑客截取到公钥,然后自己生成一对公私钥,并把自己生成的公钥传给客户端,客户端无法验证其身份,误认为是服务器,就用黑客的公钥加密自己的秘钥,并把形成的密文返回给黑客,黑客用自己的私钥解密就得到了客户端的秘钥,再用截取到服务器的公钥加密客户端的秘钥,并将其发送给服务器,服务器用私钥解密得到秘钥,然后客户端服务器正常通信,但是黑客也有秘钥,这样数据仍然很危险。
所以只需要对服务器的响应进行身份认证就能解决身份冒用的问题了。怎么解决呢?--数字证书。
数字证书:数字证书由可信任的第三方颁发,相当于一个身份证,可以验证服务器的身份。数字证书包含了证书持有者的信息和公钥信息。
Https原理、
要实现网站的https访问,就必须使用SSL证书。SSL证书的主要作用就是身份认证和传输加密,https工作原理主要如下:
- 客户端在使用https方式与Web服务器通信时有以下几个步骤,这些步骤中数据都是明文传输的:
- 1)客户使用https的URL访问Web服务器,首先完成与服务器建立tcp连接,然后要求与Web服务器建立SSL连接。
- 2)接着进行TLS四次握手。
- 第一次握手,客户端向服务器发送请求,发送SSL/TLS版本如TLS1.2,发送客户端支持的密码套件列表,如RSA加密算法,然后会产生一个随机数(Client Random),发送给服务器,这是生成对称密钥的材料。
- 4)第二次握手,服务器会确定自己所支持的SSL/TLS版本,如果不支持,则直接关闭此次连接。接着在客户端发送来的密码套件中选择一套。生成一个随机数(Server Random)。然后服务器响应客户端的请求,发送确定的SSL/TLS版本,选择的密码套件,发送随机数,发送服务器数字证书。客户端等到服务器的响应后,会去验证证书的证实有效性。如果有效就能够使用证书的公钥来解密证书得到服务器的RSA公钥。
- 5)第三次握手,证书有效,客户端生成一个随机数(pre-master),用服务器的RSA公钥加密,然后通过Change Cipher Key Exchange消息发给服务器服务器收到后,用私钥解密收到pre-master到此阶段,客户端和服务器共享了三个数,Client Random、Server Random、pre-master,双方根据这三个数生成密钥。生成密钥后客户端再发一个Change Cipher Spec告诉服务器开始使用加密通话,最后在发送一个Encrypted HandShare Message消息,向服务器发送握手摘要,再加密一下,让服务器验证。
- 6)第四次握手,服务器也是相同操作,发送Change Ciper Spec和Encrypted HandShare Message。如果客户端和服务器端都验证发送的消息正确无误。那么之后客户端和服务器端就会使用生成的密钥来进行加密通信了。
以上过程如下图所示:

一些概念,问题、
服务器证书:本质上是被CA(权威数字证书机构)的私钥加密过后的服务器公钥,是一段密文。被私钥加密过可以用公钥来解密,CA的公钥一般存储在浏览器里或者操作系统里,任何人都可以得到。
为什么TLS四次过程中使用三个随机数来生成会话密钥?
加盐,防止字典攻击。然后就是,三个随机数过哈希生成的密钥会比一个随机数生成的密钥更随机。
Comments NOTHING