HTTP/HTTPS协议(二)

长连接

对于一张网页而言，实际上由多种元素组成，比如图片，链接，文字等所以一张完整的网页需要频繁的发起http请求，http是基于tcp的，tcp则会面向频繁的创建链接，频繁的connect，所以当需要client从sever获取一大份资源的时候，就会建立一个长连接，在请求报头处的键对组合是Connection：keep-alive。

HTTP会话保持

http协议是无状态的，即http的第一次第二次第三次请求是相互不关联的，http没有历史状态，不会帮你缓存，但是浏览器会帮你缓存，但是用户需要查看新的网页时常规操作，如果网页发生跳转，那么新的页面也就无法识别是哪一个用户，为了让用户一经登录，可以在整个网站进行随意访问，就需要进行会话保持。凡是对网页访问有权限要求的网页，在获取之前，全部需要进行判断（身份认证）。

如何进行会话保持：之前的方法是在登录之后，将用户输入的信息用户名和密码保存起来，形成cookie，一般是两种形式的cookie：cookie文件或者cookie内存，文件就是关闭进程之后（释放这一部分内存），再次打开该进程依然可以进行访问。往后只要访问同一个网站，浏览器就会自动推送历史保留信息。

但是会出现信息泄露的问题，从客户端的浏览器窃取你的cookie文件，就可以使用你的账号和密码信息访问服务器，造成不良影响。

对于这种安全问题，http的新解决方案是不在客户端的浏览器保存用户名和密码，首先浏览器将用户名和密码提交给服务端，服务端通过用户名+密码形成唯一的session id，将session id返回给客户端，客户端就可以拿着session id再次访问服务端。但是对于浏览器而言，session id同样也容易被他人获取，进而造成信息泄露，唯一的解决方案就是等着session失效即可

HTTPS

HTTPS协议是一个应用层协议，是在HTTP的基础上引入了一个加密层，HTTP协议内容都是按照文本的方式明文传输的，主要是获取资源的，导致在传输过程中出现了一些被篡改的现象。所以在http的基础上增加了一个加密层。但是在双方本地是明文的

 起始在我们服务器和客户端之间还有一个重要的网络角色，运营商或者公网，他会首先对信息处理，在转发给我们局域网或者转发给服务器。

 HTTPS加密

加密方式主要有两种，对称加密和非对称加密：

对称加密：采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对 称加密，也称为单密钥加密，特征：加密和解密所⽤的密钥是相同的。

常见的对称加密算法：DES，3DES,AES等

非对称加密：需要两个密钥来进⾏加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥 （private key，简称私钥）。非对称加密可以用公钥对明文加密，私钥解密，也可以反过来。私钥加密，公钥解密。

常见非堆成加密算法：RSA，DSA，ECDSA。

数据摘要（数据指纹）：基本原理是利用单项散列函数（Hash函数）对信息进行运算，生成一串固定长度的数字摘要。数字指纹并不是一种加密机制，但是可以用来判断数据是否被篡改。

数据摘要特征：hash算法是不可逆的，算不是一种加密手段。

数据摘要的作用：对比两个文件是否是同一个文件，类似于百度网盘的快传，A上传一部电影，会首先形成hash摘要，服务器会拿着这段hash摘要去存储中搜索是否由相同的文件，如果有，直接将该文件的链接或者建立一个软链接返回给客户端即可，这就是数据摘要的作用。

所以网络通信中，需要解决的问题主要是：1、数据被监听；2、数据被篡改，所以在进行正常的加密数据通信的之前，首先需要解决的是密钥被安全获取的问题。

方案一：对称加密

密钥无法被传递，容易被中途监听截获。

方案二：非对称加密

能保证客户端到服务端是安全的，但是不能保证服务端到客户端是安全的，中间人可以截取到S->C的公钥，从而完成对服务端到客户端的信息解密。

方案三：双方都使用对称加密

1.服务端拥有公钥S与对应的私钥S', 客⼾端拥有公钥C与对应的私钥C'。

2. 客⼾和服务端交换公钥。

3. 客⼾端给服务端发信息：先⽤S对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥 S'。

4. 服务端给客⼾端发信息：先⽤C对数据加密，在发送，只能由客⼾端解密，因为只有客⼾端有私钥 C'。

效率过低，非对称加密的效率是低下的，并且依旧有安全问题。

方案四：对称加密+非对称加密

服务端具有⾮对称公钥S和私钥S'。

客⼾端发起https请求，获取服务端公钥S • 客⼾端在本地⽣成对称密钥C, 通过公钥S加密, 发送给服务器。

由于中间的⽹络设备没有私钥, 即使截获了数据, 也⽆法还原出内部的原⽂, 也就⽆法获取到对称密钥(真的吗？)。

服务器通过私钥S'解密， 还原出客⼾端发送的对称密钥C，并且使⽤这个对称密钥加密给客⼾端返回的响应数据。

方案2，3，4对于如果中间人截取你的公钥，然后替换，发送给服务端，就毫无办法。

 为此安全问题引入了CA证书：服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信 息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性。

CA证书主要是由服务端向CA机构或者CA的子机构申请认证，此时会生成公钥和私钥对，私钥由CA机构认领，确认申请信息主要是服务端的域名/申请者/公钥，在CA机构审核信息之后，会签发证书给服务端，其中证书信息如下：

 这个证书可以理解为一个结构化的字符串。然后服务端将证书返回给客户端，在验证完证书之后，与服务端进行密钥协商，这过程中也是通过证书中的公钥加密通信的，因为私钥只会在服务端，所以只有服务端才能打开CA公钥加密后的信息。

数据签名：首先通过hash散列形成摘要，通过签名者的私钥加密散列值形成签名，通过签名+证书认证的方式，形成数字签名的数据。

如何验证签名一致呢？拿到的数字签名的数据，将数据进行hash散列，再将签名用公钥进行解开，判断两者之间hash散列之后的值是否相等，如是相等，则数字签名有效，反之无效。

当服务端申请CA证书的时候，CA机构会对该服务端进⾏审核，并专⻔为该⽹站形成数字签名，过程如下：

1. CA机构拥有⾮对称加密的私钥A和公钥A'；

2. CA机构对服务端申请的证书明⽂数据进⾏hash，形成数据摘要；

3. 然后对数据摘要⽤CA私钥A'加密，得到数字签名S；

服务端申请的证书明⽂和数字签名S 共同组成了数字证书，这样⼀份数字证书就可以颁发给服务端了。

为什么不直接签名加密，而是先要形成hash摘要之后才进行加密，因为可以缩小签名密文的长度，加快数字签名的验证签名的运算速度。

方案四：对称加密+非对称加密+证书认证

 所以真实的https的握手和安全性的核心是：

非对称加密：进行密匙交换；

对称加密：用来解决实际信息传输过程中的信息加密的安全和效率问题；

证书认证：证书用来证明非对称加密之前，进行密钥协商的时候服务器公钥的合法性。

端口号划分

ssh服务使用22端口号

ftp服务器，使用21端口号

telnet服务器使用23端口号

http服务器使用80端口号

https服务器使用的443端口号

一个进程可以bind多个端口号，而一个端口号不能被多个进程bind