HTTP/HTTPS（超细精讲）

一.HTTP协议

        HTTP简介

                HTTP超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。HTTP协议工作于客户端-服务端架构为上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息。

        认识URL

                平时我们俗称的 "网址" 其实就是说的 URL。又叫统一资源定位符，是互联网上用来标识某一处资源的地址。如下图：

一个完整的URL包括以下几部分：    

1.协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符

2.域名部分：该URL的域名部分为“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用

3.端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口

4.虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”

5.文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名

6.锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分

7.参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。

URLencode和URLdecode

         像 / ? : 等这样的字符, 已经被url当做特殊意义理解了. 因此这些字符不能随意出现.比如, 某个参数中需要带有这些特殊字符, 就必须先对特殊字符进行转义。转义规则如下：

        将需要转码的字符转为16进制，然后从右到左，取4位(不足4位直接处理)，每2位做一位，前面加上%，编码成%XY格式。

        urldecode就是urlencode的逆过程;

 HTTP请求报文格式

        

        

例如： ，代表请求数据的长度。

Content-Type: 数据类型(text/html等)

Content-Length: Body的长度
Host: 客户端告知服务器, 所请求的资源是在哪个主机的哪个端口上;
User-Agent: 声明用户的操作系统和浏览器版本信息;
referer: 当前页面是从哪个页面跳转过来的;

location: 搭配3xx状态码使用, 告诉客户端接下来要去哪里访问;

Cookie: 用于在客户端存储少量信息. 通常用于实现会话(session)的功能;

HTTP响应报文格式

        

 如上图我们可以看到服务器返回了一个html页面, 那么html页面内容就是在响应正文中。

HTTP请求方法

        

其中最常用的就是GET方法和POST方法.

        GET和POST的区别？

补充： 

 1.GET 和 POST都是http请求方式， 底层都是 TCP/IP协议；通常GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包（但firefox是发送一个数据包），。

2.对于 GET 方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应 200
（返回数据）表示成功；而对于 POST，浏览器先发送 header，服务器响应 100， 浏览器再继续发送 data，服务器响应 200 （返回数据）。

 3.POST方法是指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源，或二者皆有。

GET提交的数据会放在URL之后，也就是请求行里面，以?分割URL和传输数据。 .如下：

 POST方法是把提交的数据放在HTTP包的请求正文中。

HTTP状态码

        

最常见的状态码, 比如 200(OK), 404(Not Found), 403(Forbidden), 302(Redirect, 重定向), 504(Bad Gateway)

       HTTP各版本区别

                       HTTP1.0

                在 HTTP/1.0 中默认使用短连接(需要手动使用 keep-alive 参数建立长连接)。也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如：JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个 HTTP 会话。

                队头阻塞(head of line blocking)，由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送，假设前一个请求响应一直不到达，那么下一个请求就不发送，后面的请求就阻塞了。

        

               

                HTTP1.1                   

1. 默认是长连接（ keep-alive）的方式改善了 HTTP/1.0 短连接造成的性能开销。在同一个tcp的连接中可以传送多个HTTP请求和响应. 多个请求和响应可以重叠，多个请求和响应可以同时进行
2. 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。然而，管道技术并没有改变HTTP/1.1协议中“请求-响应”的基本机制，即服务器仍然需要按照请求的顺序来发送响应。在实际应用中仍然可能造成阻塞

        HTTP2.0

                http2.0是一种安全高效的下一代http传输协议。安全是因为http2.0建立在https协议的基础上，高效是因为它是通过二进制分帧来进行数据传输。文本形式信息保存为一个一个字符，占用空间多，每个字符对应比特位多，接受方还需要将报文转换为二进制，而直接用二进制减少了传输数据量，提高数据传输效率。

                头部压缩。HTTP2.0会压缩（Header）部分；如果同时多个请求其头部一样或相似，那么协议会消除重复部分。利用HPAK算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，就不用重复发送同样字段了，只发送索引号，减少数据量提高速度。

                多路复用。HTTP2.0实现了真正的并行传输，它能够在一个TCP上进行任意数量的HTTP请求，由于其二进制分帧特性。HTTP2.0 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。移除了 HTTP/1.1 中的串行请求，不需要排队等待，彻底解决「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率.

        

                服务端推送.HTTP2.0 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务端不再是被动地响应，可以主动向客户端发送消息、推送额外的资源。

 

                HTTP3.0 

                        为了解决HTTP/1.1和HTTP/2.0中TCP造成的队头阻塞问题，HTTP/3.0直接放弃使用TCP，将传输层协议改成UDP；但是因为UDP是不可靠传输，所以这就需要QUIC实现可靠机制。如何用QUIC使UDP可靠，可以详看这篇文章。

字节一面：如何用 UDP 实现可靠传输？ (qq.com)

                        HTTP/3.0默认使用TLS 1.3进行加密，这是一种新的安全协议，相较于之前的TLS版本，提供了更好的加密和认证性能，进一步增强了数据传输的安全性。

        HTTP/1.1需要经历TCP三次握手和TLS握手才能建立连接，延迟较高。HTTP/2.0虽然有所改进，但连接建立过程仍然较慢。而HTTP/3.0通过QUIC协议实现了0-RTT和1-RTT连接建立，大大减少了连接延迟。

 补充：

        什么是长连接，什么是短连接？            

        长连接：长连接，指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。

        短连接：短连接（short connnection）是相对于长连接而言的概念，指的是在数据传送过程中，只在需要发送数据时，才去建立一个连接，数据发送完成后，则断开此连接，即每次连接只完成一项业务的发送。

关于TCP的保活机制可以看：

TCP与UDP的特性与区别（详细）-CSDN博客

        什么是永久重定向，什么是临时重定向？

• 永久重定向（通常是HTTP状态码301）表明资源已经永久性地移动到了新的位置。这意味着，一旦设置了永久重定向，所有后续对原始URL的请求都应该被自动转发到新的URL，而且这个重定向是长期有效的。如：当网站中的某些页面失效或过时，但仍然具有流量时，通过301重定向至有效的页面，以充分利用流量资源。
• 临时重定向（通常是HTTP状态码302或307，取决于具体的方法和预期行为）表明资源的移动是暂时的。客户端在接收到临时重定向响应后，会临时使用新的URL，但在将来的某个时间点，对原始URL的请求可能会恢复为直接访问原始资源，而不是被重定向。如：在网站短时间内进行改版或维护时，可以使用302重定向将页面临时转移到另一个地址，以保持用户体验。

HTTP是无状态协议，Cookie，session之间的区别又是什么可以看看下面这篇文章

什么是Http无状态？Session、Cookie、Token三者之间的区别 - 翎野君 - 博客园 (cnblogs.com)

                       
 二.HTTPS协议

                HTTPS引入

                        大家在网上下载软件的时候有没有遇到过这种情况：你明明点击的是下载的是一个叫“XXX”的软件，下载完成后缺变成" YYY"的软件了。这是由于我们通过⽹络传输的任何的数据包都会经过运营商的⽹络设备(路由器,交换机等),那么运营商的⽹ 络设备就可以解析出你传输的数据内容,并进⾏篡改. 比如：点击"下载按钮",其实就是在给服务器发送了⼀个HTTP请求,获取到的HTTP响应其实就包含了该 APP的下载链接.运营商劫持之后,就发现这个请求是要下载千千动听,那么就⾃动的把交给⽤⼾的响应 给篡改成"QQ浏览器"的下载地址了。

因为http的内容是明⽂传输的，明⽂数据会经过路由器、wifi热点、通信服务运营商、代理服务 器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传 输的信息且不被双⽅察觉，这就是中间⼈攻击，所以我们才需要对信息进⾏加密。 

那么运营商为啥这样干呢？

不⽌运营商可以劫持,其他的⿊客也可以⽤类似的⼿段进⾏劫持,来窃取⽤⼾隐私信息,或者篡改内容. 试 想⼀下,如果⿊客在⽤⼾登陆⽀付宝的时候获取到⽤⼾账⼾余额,甚⾄获取到⽤⼾的⽀付密码..... 

        HTTPS简介 

                HTTPS也是⼀个应⽤层协议.是在HTTP协议的基础上引⼊了⼀个加密层. HTTP协议内容都是按照⽂本的⽅式明⽂传输的.这就导致在传输过程中出现⼀些被篡改的情况。

再这里有小可爱会问了。你前面不是讲http2.0的时候提到它有一个特性是二进制传输吗？是的，它是将文本内容转化成二进制，别人拿到二进制类容转换回去不就是文本内容了嘛，http2.0用二进制是为了减少了传输数据量，提高数据传输效率。

        预备概念               

        加密就是把明⽂(要传输的信息)进⾏⼀系列变换,⽣成密⽂. 解密就是把密⽂再进⾏⼀系列变换,还原成明⽂. 在这个加密和解密的过程中,往往需要⼀个或者多个中间的数据,辅助进⾏这个过程,这样的数据称为密钥。

常见加密方式

        对称加密

                采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密。特点：算法公开、计算量⼩、加密速度快、加密效率⾼。常⻅对称加密算法：DES、3DES、AES、TDEA、Blowfish、RC2等

即使数据被截获,由于⿊客不知道密钥是啥,因此就⽆法进⾏解密,也就不知道请求 的真实内容是啥了 。但是，这么多客⼾端,每个⼈⽤的秘钥都 必须是不同的(如果是相同那密钥就太容易扩散了,⿊客就也能拿到了). 因此服务器就需要维护每个客户端和每个密钥之间的关联关系。这个很复杂也很庞大。

⽐较理想的做法,就是能在客⼾端和服务器建⽴连接的时候,双⽅协商确定这次的密钥是啥 

        但是如果直接把密钥明⽂传输,那么⿊客也就能获得密钥了~~此时后续的加密操作就形同虚设了. 因此密钥的传输也必须加密传输! 但是要想对密钥进⾏对称加密,就仍然需要先协商确定⼀个"密钥的密钥".这就成了"先有鸡还是先有 蛋"的问题了.此时密钥的传输再⽤对称加密就⾏不通了. 

非对称加密 

        

故引入：双方非对称加密

双方非对称加密 

        1. 服务端拥有公钥S与对应的私钥S'，客⼾端拥有公钥C与对应的私钥C' 2. 客⼾和服务端交换公钥 3. 客⼾端给服务端发信息：先⽤S对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥 S' 4. 服务端给客⼾端发信息：先⽤C对数据加密，在发送，只能由客⼾端解密，因为只有客⼾端有私钥 C'

效率太低

依旧有安全问题 （后面讲）

⾮对称加密+对称加密 

        解决效率问题。

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

2.客⼾端发起https请求，获取服务端公钥S

3.客⼾端在本地⽣成对称密钥C,通过公钥S加密,发送给服务器. 由于中间的⽹络设备没有私钥,即使截获了数据,也⽆法还原出内部的原⽂,也就⽆法获取到对称密钥(真的吗？)

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

5.后续客⼾端和服务器的通信都只⽤对称加密即可.由于该密钥只有客⼾端和服务器两个主机知道,其 他主机/设备不知道密钥即使截获数据也没有意义。

        由于对称加密的效率⽐⾮对称加密⾼很多,因此只是在开始阶段协商密钥的时候使⽤⾮对称加密,后续的传输仍然使⽤对称加密 。

         在上诉几种加密方式中，都存在安全问题，如果最开始在第一步的时候，中间⼈就已经开始攻击了呢？以非对称加密＋对称加密（比上诉其他方法相对安全，效率也不错）举例。

1.服务器具有⾮对称加密算法的公钥S，私钥S'

2. 中间⼈具有⾮对称加密算法的公钥M，私钥M' 

3. 客⼾端向服务器发起请求，服务器明⽂传送公钥S给客⼾端

4. 中间⼈劫持数据报⽂，提取公钥S并保存好，然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M， 并将伪造报⽂发给客⼾端

5. 客⼾端收到报⽂，提取公钥M(⾃⼰当然不知道公钥被更换过了)，⾃⼰形成对称秘钥X，⽤公钥M加 密X，形成报⽂发送给服务器

6. 中间⼈劫持后，直接⽤⾃⼰的私钥M'进⾏解密，得到通信秘钥X，再⽤曾经保存的服务端公钥S加 密后，将报⽂推送给服务器

7. 服务器拿到报⽂，⽤⾃⼰的私钥S'解密，得到通信秘钥X 

8. 双⽅开始采⽤X进⾏对称加密，进⾏通信。但是⼀切都在中间⼈的掌握中，劫持数据，进⾏窃听甚 ⾄修改，都是可以的

上⾯的攻击⽅案，同样适⽤于其他几种加密方式。

⾮对称加密+对称加密+证书认证（CA证书）

         上面这种中间人攻击问题本质出在哪⾥了呢？客⼾端⽆法确定收到的含有公钥的数据报⽂，就是⽬标服务器发送过来的。服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。

        这个证书可以理解成是⼀个结构化的字符串,⾥⾯包含了以下信息: 证书发布机构 ，证书有效期 ，公钥 ，证书所有者，数字签名 .....

如何申请证书呢？ 

        申请证书的时候，需要在特定平台⽣成查看，并且会同时⽣成⼀对⼉密钥对⼉，即公钥和私 钥。这对密钥对⼉就是⽤来在⽹络通信中进⾏明⽂加密以及数字签名的。 其中公钥会随着CSR⽂件，⼀起发给CA进⾏权威认证，私钥服务端⾃⼰保留，⽤来后续进⾏通信（其 实主要就是⽤来交换对称秘钥） 。

数字签名

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

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

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

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

     为什么数字签名不直接加密，⽽是要先hash形成摘要?

缩⼩签名密⽂的⻓度,加快数字签名的验证签名的运算速度

     为什么数据摘要内容⼀定要加密形成签名 ？

        假设数据摘要不加密，如果中间人把证书明文改了，自然哈希值也就不一样了，此时数据摘要不加密，中间人再把hash值改了，客户端就啥也分不清了。所以被传输的哈希值（数据摘要）一定要加密形成数字签名。

常⻅的摘要算法有:MD5和SHA系列

以MD5为例,我们不需要研究具体的计算签名的过程,只需要了解MD5的特点:

定⻓:⽆论多⻓的字符串,计算出来的MD5值都是固定⻓度(16字节版本或者32字节版本)

分散:源字符串只要改变⼀点点,最终得到的MD5值都会差别很⼤

不可逆:通过源字符串⽣成MD5很容易,但是通过MD5还原成原串理论上是不可能的

        服务端申请的证书明文和数字签名S共同组成了数字证书，这样⼀份数字证书就可以颁发给服务端了 。然后服务器把证书传输给浏览器，浏览器从证书⾥获取公钥。

客⼾端进⾏认证：

        当客⼾端获取到这个证书之后,会对证书进⾏校验(防⽌证书是伪造的).

1.判定证书的有效期是否过期

2.判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).

3.验证证书是否被篡改:从系统中拿到该证书发布机构的公钥,对签名解密,得到⼀个hash值(称为数据摘要),设为hash1.然后计算整个证书明文数据的hash值,设为hash2.对⽐hash1和hash2是否相等.如果相等,则说明证书是没有被篡改过的

中间⼈有没有可能篡改该数字证书？ 

数字证书包括两个部分：证书明文和数字签名

假设：中间人牛逼，修改了证书明文（证书发布机构 ，证书有效期 ，公钥 ，证书所有者,域名等.....），然后将证书明文进行hash，形成数据摘要，但是没有CA机构的私钥加密，得到的数据签名和客户端收到的不一致则说明证书已被篡改， 证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈。除非中间人有CA机构内部高层。

中间人整个掉包证书？ 

1.因为中间⼈没有CA私钥，所以⽆法制作假的证书。因为证书里面有签名，签名是数据摘要加密后得到，而只有CA机构有密钥。

2.所以中间⼈只能向CA申请真证书，然后⽤⾃⼰申请的证书进⾏掉包 这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如果整 体掉包，客⼾端依旧能够识别出来。

3.永远记住：中间人没有CA私钥，所以对任何证书都无法进行合法修改，包括自己的

完整流程： 

HTTPS⼯作过程中涉及到的密钥有三组 ：

第⼀组(非对称加密):⽤于校验证书是否被篡改.服务器持有私钥(私钥在形成CSR⽂件与申请证书时获 得), 客⼾端持有公钥(操作系统包含了可信任的CA认证机构有哪些,同时持有对应的公钥). 服务器在客 ⼾端请求是，返回携带签名的证书.客⼾端通过这个公钥进⾏证书验证,保证证书的合法性，进⼀步保 证证书中携带的服务端公钥权威性。

第⼆组(非对称加密):⽤于协商⽣成对称加密的密钥. 客⼾端⽤收到的CA证书中的公钥(是可被信任的) 给随机⽣成的对称加密的密钥加密,传输给服务器,服务器通过私钥解密获取到对称加密密钥.

第三组(对称加密):客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密.

        其实⼀切的关键都是围绕这个对称加密的密钥.其他的机制都是辅助这个密钥⼯作的。 

三.HTTP与HTTPS的区别

        

1、HTTPS  协议需要到 CA （Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用。(以前的网易官网是http，而网易邮箱是 https 。)

2、HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。当然HTTPS会消耗更多的CPU和内存资源。

3、HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4、HTTP 的连接很简单，是无状态的。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)

四.补充：

SSL（Secure Socket Layer，安全套接层） 是TCP/IP协议中基于HTTP之下、TCP之上的一个可选协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯

TLS（Transport Layer Security，传输层安全协议） 可以看作是SSL的继任者，是SSL的标准化和增强版本。TLS与SSL在连接过程、协议结构（记录协议和握手协议）等方面几乎相同，但TLS增加了许多新的报警代码，如解密失败、记录溢出、未知CA、拒绝访问等，同时也支持SSL协议上所有的报警代码。

SSL/TLS与CA证书的关系主要体现在以下几个方面：

1. 身份验证：当客户端（如Web浏览器）连接到一个使用SSL/TLS的服务器时，服务器会提供其数字证书以证明其身份。这个证书通常由一个受信任的第三方机构，即CA签发。客户端会检查此证书，确保它是由受信任的CA签发的，并且与请求的域名匹配，从而确保连接的是合法且预期的服务器。
2. 密钥交换：数字证书包含了公钥信息。在SSL/TLS握手过程中，客户端使用此公钥加密一个随机生成的预主密钥（pre-master secret）并发送给服务器。只有拥有私钥的服务器才能解密此预主密钥。然后，双方使用此预主密钥来生成会话密钥，该密钥将用于加密和解密此后的通信。
3. 完整性和非伪造性：除了加密通信内容外，数字签名技术也确保了传输的数据的完整性和非伪造性。服务器和客户端使用私钥和公钥进行签名和验证，以确保数据在传输过程中没有被篡改。

CA证书不仅限于SSL/TLS证书；SSL/TLS证书是CA证书的一种具体应用形式。