对http,https,websocket的理解

HTTP协议

HTTP是单向的,客户端发送请求,服务器发送响应。举例来说,当客户端向服务器发送请求时,该请求以HTTPHTTPS的形式发送,在接收到请求后,服务器会将响应发送给客户端。每个请求都与一个对应的响应相关联,在发送响应后客户端与服务器的连接会被关闭。

每个HTTPHTTPS请求每次都会新建与服务器的连接,并且在获得响应后,连接将自行终止。 HTTP是在TCP之上运行的无状态协议,TCP是一种面向连接的协议,它使用三向握手方法保证数据包传输的传递并重新传输丢失的数据包。

HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。

每个HTTP连接完成后,其对应的TCP连接并不是每次都会关闭。从 HTTP/1.1起,默认使用长连接,用以保持连接特性。使用长连接的HTTP协议,会在响应头有加入这个头部字段:Connection:keep-alive

在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如ApacheNginxNginx中这个默认时间是 75s)中设定这个时间。实现长连接要客户端和服务端都支持长连接。

HTTP属于应用层协议,在传输层使用TCP协议,在网络层使用IP协议。IP协议主要解决网络路由和寻址问题,TCP协议主要解决如何在IP层之上可靠的传递数据包,使在网络上的另一端收到发端发出的所有包,并且顺序与发出顺序一致。TCP有可靠,面向连接的特点。

HTTPS

HTTPS在http基础上进行了加密,即HTTP下加入SSL层,HTTPS的安全基础是SSL,因此加密的详细内容就需要SSL。

https:URL表明它使用了HTTP,但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层(在HTTP与TCP之间)。这个系统的最初研发由进行,提供了身份验证与加密通讯方法,现在它被广泛用于网上安全敏感的通讯,例如交易支付方面。

https协议需要到CA申请证书,一般免费证书较少,因而需要一定费用。

http是超文本传输协议,信息是明文传输,https则是具有安全性的ssl/tls加密传输协议。

http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。

http的连接很简单,是无状态的;HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。

HTTPS原理:

nginx服务端需要开发443端口,并且去ca申请证书。包括一个pem文件(证书base64加密)和key(私钥base64加密)文件

http {
  include       mime.types;
  default_type  application/octet-stream;
  sendfile        on;
  keepalive_timeout  65;
  server {
    #监听443端口
    listen 443;
    #你的域名
    server_name www.xxx.com; 
    ssl on;
    #ssl证书的pem文件路径
    ssl_certificate  /root/cer.pem;
    #ssl证书的key文件路径
    ssl_certificate_key /root/cer.key;
    location / {
    proxy_pass  http://公网地址:项目端口号;
    }
  }
  server {
    listen 80;
    server_name www.xxx.com;
    #将请求转成https
    rewrite ^(.*)$ https://$host$1 permanent;
  }
}

HTTPS在传输数据之前需要客户端(浏览器)与服务端(网站)之间进行一次握手,在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议,更是一件经过艺术家精心设计的艺术品,TLS/SSL中使用了非对称加密,对称加密以及HASH算法。握手过程的具体描述如下:

  • 1)浏览器将自己支持的一套加密规则发送给网站。 
  • 2)网站从中选出一组加密算法与HASH算法,并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址,加密公钥,以及证书的颁发机构等信息。  
  • 3)浏览器获得网站证书之后浏览器要做以下工作: 
a) 验证证书的合法性(颁发证书的机构是否合法,证书中包含的网站地址是否与正在访问的地址一致等),如果证书受信任,则浏览器栏里面会显示一个小锁头,否则会给出证书不受信的提示。 
b) 如果证书受信任,或者是用户接受了不受信的证书,浏览器会生成一串随机数的密码,并用证书中提供的公钥加密。 
c) 使用约定好的HASH算法计算握手消息,并使用生成的随机数对消息进行加密,最后将之前生成的所有信息发送给网站。 
  •  
4)网站接收浏览器发来的数据之后要做以下的操作: 
a) 使用自己的私钥将信息解密取出密码,使用密码解密浏览器发来的握手消息,并验证HASH是否与浏览器发来的一致。 
b) 使用密码加密一段握手消息,发送给浏览器。 
  •  
5)浏览器解密并计算握手消息的HASH,如果与服务端发来的HASH一致,此时握手过程结束,之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。 

SSL的客户端与服务器端的认证握手如下图:


对称加密: 密钥X,可加密可解密

非对称加密: 公钥A加密,私钥A解密

总结:网站拥有公钥A和私钥A,公钥A明文发给浏览器,浏览器用公钥A生成一个对称加密密钥X,(就算被三方劫持,它也不知道X)发给服务器。服务器用私钥A解出来。此时X只有双发知道。

(但是浏览器发的公钥A可以被劫持,然后换成盗贼B公钥,发给浏览器,游览器不知道公钥B被替换,就用B去生成了X,再发给服务器的时候,再被盗贼劫持,然后用盗贼B私钥解出来,然后用公钥A加密X,发给服务器。这样X也不安全了, 根本原因是浏览器无法确认收到的公钥是不是网站自己的)

接下来引入了CA机构,而CA机构颁发的“身份证”就是数字证书。通过数字签名技术可以很好的把公钥传递到浏览器,防止被篡改。参考HTTPS底层原理的奇妙探险

这里浏览器与网站互相发送加密的握手消息并验证,目的是为了保证双方都获得了一致的密码,并且可以正常的加密解密数据,为后续真正数据的传输做一次测试。另外,HTTPS一般使用的加密与HASH算法如下:

  • 非对称加密算法:RSA,DSA/DSS
  • 对称加密算法:AES,RC4,3DES
  • HASH算法:MD5,SHA1,SHA256

WebSocket协议

WebSocket是双向的,在客户端-服务器通信的场景中使用的全双工协议,与HTTP不同,它以ws://wss://开头。它是一个有状态协议,这意味着客户端和服务器之间的连接将保持活动状态,直到被任何一方(客户端或服务器)终止。在通过客户端和服务器中的任何一方关闭连接之后,连接将从两端终止。

如果其中任何一方(客户端服务器)宕掉或主动关闭连接,则双方均将关闭连接。套接字的工作方式与HTTP的工作方式略有不同,状态代码101表示WebSocket中的交换协议。

原理

当客户端要和服务端建立 WebSocket 连接时,在客户端和服务器的握手过程中,客户端首先会向服务端发送一个 HTTP 请求,包含一个 Upgrade 请求头来告知服务端客户端想要建立一个 WebSocket 连接。

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: ************==
Sec-WebSocket-Version: **

Server正确接收后,会返回一个响应头:

Upgrade:websocket
Connnection: Upgrade
Sec-WebSocket-Accept: ******************

和TCP、HTTP协议的关系

WebSocket是基于TCP的独立的协议。
和HTTP的唯一关联就是HTTP服务器需要发送一个“Upgrade”请求,即101 Switching Protocol到HTTP服务器,然后由服务器进行协议转换。

优点

  • 较少的控制开销,在连接创建后,服务器和客户端之间交换数据时,用于协议控制的数据包头部相对较小。在不包含扩展的情况下,对于服务器到客户端的内容,此头部大小只有2至10字节(和数据包长度有关);对于客户端到服务器的内容,此头部还需要加上额外的4字节的掩码。相对于 HTTP 请求每次都要携带完整的头部,此项开销显著减少了。
  • 更强的实时性,由于协议是全双工的,所以服务器可以随时主动给客户端下发数据。相对于HTTP请求需要等待客户端发起请求服务端才能响应,延迟明显更少;
  • 长连接,保持连接状态。与HTTP不同的是,Websocket需要先创建连接,这就使得其成为一种有状态的协议,之后通信时可以省略部分状态信息。而HTTP请求可能需要在每个请求都携带状态信息(如身份认证等)。
  • 双向通信、更好的二进制支持。与 HTTP 协议有着良好的兼容性。默认端口也是 80 和 443,并且握手阶段采用 HTTP 协议,因此握手时不容易被屏蔽,能通过各种 HTTP 代理服务器。