计算机网络——HTTP和HTTPS

        Web的应用层协议是超文本传输协议（HyperText Transfer Protocol，HTTP）它是Web的核心，其传输层是基于TCP（而不是在UDP上运行）。HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。其通信内容以明文的方式发送，不通过任何方式的数据加密，同时也不会对发送过的请求和相应的通信状态进行持久化处理，是一种无状态的协议。

        一，HTTP报文格式

        请求报文格式：如下所示 

       HTTP的请求报文大概可以分为三大部分：请求行，首部（请求头），实体（请求体）。请求行有三个字段：方法字段，URL字段和HTTP版本字段。

         这里我们主要讨论一下方法字段，

根据 HTTP 标准，HTTP 请求可以使用多种请求方法。

HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。

HTTP1.1 新增了五种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

        在此我们主要记住：GET,POST,PUT,DELETE。POST和PUT有些许的区别，POST往往是用来创建一个资源，而PUT往往是用来修改一个资源。

 

         对比一下GET和POST的区别：

GET请求用来从服务器上获得资源，而POST是用来向服务器提交数据；

GET请求参数放在请求行里面，通过URL传递，而POST放在Request body中，这导致GET传输的数据要受到URL长度限制（最大长度是 2048 个字符）；而post可以传输大量的数据，上传文件通常要使用POSTt方式；

GET请求会被浏览器主动cache，而POST不会，除非手动设置。

GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息(GET和POST都不安全，因为HTTP是明文传播)

因为GET因为是读取，就可以对GET请求的数据做缓存。GET因为是读取，所以反复读取不应该对访问的数据有副作用，即我反复读取的数据应该一致，也就是我们说的幂等性。而POST是不具备幂等性的不幂等也就意味着不能随意多次执行。因此也就不能缓存。

       响应报文格式：如下所示 

        

         HTTP的响应报文也可以分为三大部分：状态行（响应行），首部（响应头），实体（响应体）。

        这里主要看一下状态码的区别：

         二，HTTP版本

        HTTP版本之间的区别，主要对比1.0、1.1和2.0

1. http1.0 到http1.1的主要区别，就是从无连接到长连接
2. http2.0对比1.X版本主要区别就是多路复用

具体细节： HTTP1.0和HTTP1.1和HTTP2.0的区别_艾伦lee的博客-CSDN博客_http1.1 

        HTTP与HTTPS的区别：

          三，HTTPS

        HTTPS是在HTTP的基础之上，增加了SSL加密过程，将传输过程中的数据进行加密，HTTPS是安全的传输。可以保证数据的完整性，防止传输的内容被中间人冒充或篡改。

        对称加密和非对称加密：对称加密简单说就是有一个密钥，它可以加密一段信息，也可以对加密后的信息进行解密，和我们日常生活中用的钥匙作用差不多。非对称加密简单说就是有两把密钥，通常一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

        问题：对称加密的效率高，加密和解密的密钥都是一样的，A向B发送通过密钥加密的数据，而B也拿这个密钥解密。但是问题在于，双方怎么约定这个密钥，如果直接通过网络传输就会存在被截获的风险？ 而不通过网络，私底下约定一个密钥又是不可能的，于是有了非对称加密，密钥分为公钥和私钥，公钥用于加密而私钥用于解密。比如私钥在服务器，我用公钥加密后访问服务器，然后服务器用私钥解密，这样即使公钥被截获也不能解码。但是这样的话，黑客能拿到公钥，也能模拟加密后访问服务器的过程， 黑客可以随意解密服务端信息（如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用该公钥解密服务器传来的信息了） 。本质上一组公私钥的情况是公私钥即可加密又可解密，而中间人截取到了某一个钥匙，就可以解码。

        为了解决这个问题，看来一对公钥私钥是不够的，客户端也需要有自己的公钥和私钥，并且客户端要把自己的公钥，给服务端。这样，客户端给服务端发送的时候，用服务端的公钥加密。而服务端给客户端发送消息的时候，使用客户端的公钥。这样就算有黑客企图模拟客户端获取一些信息，或者半路截获回复信息，但是由于它没有私钥，这些信息它还是打不开。本质上两组公私钥的情况就是，公钥只负责加密且明文在网络中传输，即使这个公钥被截取也没关系，因为它只是加密，无法解密其他内容，而私钥是不在网络传输的。

         那么追求效率和安全性，我们采用非对称加密+对称加密，就可以了吗？还有漏洞！！我们简单看一下非对称加密+对称加密的过程：

1. 某网站拥有用于非对称加密的公钥A、私钥A’；浏览器拥有公钥B与对应的私钥B’。
2. 浏览器把公钥B明文传输给服务器，向网站服务器请求，服务器把公钥A明文给传输浏览器。
3. 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
4. 服务器拿到后用私钥A’解密得到密钥X。
5. 这样双方就都拥有密钥X（用于对称加密）了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。

 如果在数据传输过程中，中间人劫持到了数据，此时他的确无法得到浏览器生成的密钥X，这个密钥本身被公钥A加密了，只有服务器才有私钥A’解开它，然而中间人却完全不需要拿到私钥A’就能干坏事了。请看：

1. 某网站有用于非对称加密的公钥A、私钥A’。
2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
3. 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
4. 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
5. 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
6. 服务器拿到后用私钥A’解密得到密钥X。

        可以很明显发现问题在哪，中间人可以用自己的公钥B去替换网站的公钥A ，等浏览器发来被公钥B加密的密钥X，中间人可以轻而易举的破解。那么如何破局？ 就是要在浏览器端确认公钥是网站的，CA机构应运而生！！类似于一个权威部门给别人验证证书的合法性，证书上有公钥，以及证书的所有者，和证书的发布机构和有效期。

        HTTPS使用了非对称加密+对称加密+CA认证

        SSL建立连接过程：

1. c->s,客户端发起加密通信请求，这个请求通常叫做 ClientHello请求，告知自己支持的协议版本号，加密算法(公钥)，压缩算法，以及一个用于生成后续通信密钥的随机数；

2. s->c,服务端响应，也叫作 ServerHello，确认加密通信协议，加密算法（公钥），以及一个用于生成后续通信密钥的随机数，还有网站证书；

3. c->s,客户端在收到上一步服务端的响应之后，首先会检查证书的颁发者是否可信任，是否过期，域名是否一致，并且从操作系统的证书链中找出该证书的上一级证书，并拿出服务端证书的公钥，然后验证签名和hash，如果验证失败，就会显示警告，我们经常在Chrome里面看到，“此网站有风险，是否继续什么的”。如果验证通过，客户端会向服务端发送一个称作 “pre-master-key” 的随机数，该随机数使用证书的公钥加密，以及编码改变通知（以后咋们就用协商的密钥堆成加密通信了），客户端完成握手。

4. 服务端在收到上一步客户端请求之后，也会确认我以后发给你的信息可就加密了哦，并且完成握手。

此时，客户端有第一步自己生成的随机数，第二步收到服务端的随机数，第三步的 pre-master-key，服务端也是如此，他们就可以用这三个随机数使用约定的算法生成同一个密钥来加密（对称加密）以后的通信数据了。