[网络协议]HTTP学习总结

简介

1. HTTP(Hyper Text Transfer
   Protocol)超文本传输协议为万维网(www)客户端(浏览器)与服务端提供数据通信的协议。

2. HTTP由请求和响应两部分构成，是一个标准的客户服务器通信模型。

3. HTTP是应用层协议，通过TCP/IP协议族来传输数据(HTML文件、图片文件、查询数据等)

工作过程

主要特性

1. HTTP是灵活可扩展的，只规定了报文的基本格式，比如用空格分隔单词，用换行分隔字段，header+body 等，方便扩充功能。
2. HTTP是可靠传输协议，基于TCP可靠传输协议，则HTTP就继承了“可靠传输”这个特性
3. HTTP使用请求-应答模式，永远是请求方先发起连接和请求 ，是主动的 ，而应答方只有在收到请求后才能答复，是被动的，如果没有请求时不会有任何动作。
4. HTTP本质上是无状态的，每个请求都是相互独立的、毫无关联的，协议不要求客户端或服务器记录相关的信息

万维网与URL

关系介绍

1. 万维网WWW(World Wide Web)是一个大规模的、联机式的信息存储所/资料空间，是无数个网络站点和网页的集合，我们正是通过HTTP协议与万维网中的资源进行交互，而万维网中的每个资源使用URL去标识。
2. URL(Uniform Resource Location)统一资源定位符，可以认为一个 URL 地址，对应着一个网络上的资源(文字、视频、音频)
3. 而有了URL我们就可以通过HTTP协议去获取我们想要的资源
   

URL格式和含义

报文结构

基本结构概览

1. 在客户端发送请求和服务端响应请求时，需要把请求或响应数据封装成响应的HTTP报文，然后传递给传输层传输
2. HTTP报文分为：请求报文和相应报文
   

请求报文结构与响应报文结构

各个字段意思解释

1. 请求方法字段GET、POST、PUT、DELET

GET：获取资源

POST：传输实体数据

PUT：传输文件

DELETE：删除文件数据

还有其他请求方法(HEAD、TRACE、CONNECT)，不常用就不介绍了

2. 状态码与提示短语

首部字段

在HTTP请求和响应报文中，首部字段补充额外处理信息，可以让服务端、客户端更容易明白信息的内容是什么、应该怎么处理、怎么响应

4类常用首部字段：

1. 通用首部：既可以在请求报文中使用，又可以在响应报文中使用
2. 请求首部：只能在请求报文中使用
3. 响应首部：只能在响应报文中使用
4. 实体首部：既可以在请求报文中使用，又可以在响应报文中使用
   

通用首部

通用首部字段是指，请求报文和响应报文双方都会使用的首部。
例如：Cache-Control字段

请求首部

请求首部字段是从客户段->往服务端发送请求报文中所用的字段，用于补充请求的附加信息、客户端信息、对应内容相关的优先级
例如：Accept字段

响应首部

响应首部字段是有服务器->向客户段发送所使用的字段，用于补充响应的附加信息、服务器信息，以及对客户段的附加要求
例如：Accept-Ranges

实体首部

实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首 部，用于补充内容的更新时间等与实体相关的信息。

例如：Content-Encoding

Cookie与Token

推荐一篇讲的非常不错的文章：https://www.jianshu.com/p/ce9802589143

HTTP各版本比较

HTTP优缺点

HTTPS

简介

1. 为了解决HTTP的安全问题，需要在HTTP上再加入加密处理(SSL协议)和认证机制(CA机制)，这样就诞生了HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer)

2. HTTPS = HTTP+加密+认证+完整性保护=HTTP+SSL
   

HTTPS=HTTP+SSL

SLL简介

SSL(Secure Socket Layer)安全套接字层：是位于可靠的面向连接的网络层协议和应用层协议之间的一种提供保密性和数据完整行的协议。

SSL的功能

1. 认证用户和服务器，确保数据发送到正确的客户机和服务器
2. 加密数据方式数据被中途窃取
3. 维护数据完整性，确保数据再传输过程中不被改变

HTTPS与HTTP通信过程比较

HTTPS协议在HTTP的基础上引入SSL中间层，我们可以理解为HTTP先和SSL打交道，之后再由SSL与传输层TCP打交道，这样就能保证通信的安全且正确性。

三种加密方式

1. 摘要算法

1. 简介：摘要算法能够把任意长度的数据“压缩成”固定长度的、且独一无而的“摘要”字符串。
2. 功能：保证数据的完整性，通过把明文信息和明文的摘要信息一起进行加密传输，数据传输到对方之后再解密，重新对明文做一次摘要算法把得到的新的摘要信息与一同传输过来的摘要进行进行对比就能判断数据是否完整了
3. 有哪些：哈希、MD5、SHA1、SHA2、SHA256
   

2. 对称加密

1. 加密：编码、解码使用相同的密钥算法，如(AES，RC4)，我们把这个密钥称为“共享密钥”
2. 但是我们注意到此时“密钥”的安全分发是一个大问题。
3. “对称加密”也加“共享加密”
   

3. 非对称加密

1. 有两种钥匙🔑，分别为“公钥”和“私钥”，这两个钥匙成对使用，一般私钥只有一份保留在自己的手中，而“公钥”可以分发出去，一般公钥是有多个的
2. 如果使用公钥加密只能使用私钥解密，如果使用私钥加密只能使用公钥解密
3. 一般我们仅使用 “公钥要加密私钥解密”这个过程，因为只有一把私钥，所以多个人手中的公钥分别加密后的数据，只有手持私钥的自己可以解密，所以这个过程是安全的。
4. 但是“私钥加密使用公钥解密”，这个过程是不安全的，私钥加密后，所有持有公钥的人都可以解密，这是不安全的
   

HTTPS采用混合加密

1. 由于非对称加密速度太慢了，而相对来说对称加密会更快一些，所有在HTTPS中我们采用对称加密与非对称加密混和使用
2. 当客户端与服务端采用混合加密的时候，当客户段与服务器经过TCP三次握手建立连接后，
   1. 服务器在第一通信时，会先采用混合加密的方式，把公钥发送给客户端，而服务端自己持有私钥
   2. 当客户端拿到公钥后，自己先用对称加密算法产生一把共享密钥，然后通过把共享密钥通过服务器给的私钥加密发送给服务器
   3. 当服务端收到加密信息后，使用私钥解密，获取共享密钥，此时客户端和服务段均有共享密钥，那么在接下来的通信均使用对称加密的方式来通信。
      
3. 但是上面的过程我们是无法保证给我发送公钥的服务器是否，是我真实想要的那台服务器，万一是一台恶意攻击服务器那么我不是就裂开了吗，索引我们找到一种可以给服务器提供身份确认的机制，也就是下面我们要讲的——数字签名机制CA
   

数字证书CA机制

1. 为了解决上述问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。

2. 这样在上面的图示中的第一次通信的时候，只要服务器把它的公开密钥证书发给客户端，我们只要能验明证书合法性就能确认服务的真伪。

3. 这里我们要注意一点“数字证书的认证机构的公钥是事先已经内置在我们的浏览器中的”

4. 但是在上图中又出现一个问题，我们怎么确定数字证书CA机构是否合法真实的机构，而不是别人冒充的呢？下面将通过证书链来解决这个问题的

证书链

1. 在服务器发送的数字证书的时候，服务器是把上图中的三个证书（形成一个证书链）一起发过来，让我们验证

2. 验证过程：根证书是内置在浏览器中的，一定可确保根证书正确，接下来我们主要按照步骤，从根往下依次验证中间CA机构的证书是否正确，当CA机构的证书正确后(我们就知道中间机构也是可以信任的)，接着就可以验证服务器的数字证书是否正确了，当服务器的证书也正确之后，我们就可以保证服务器的身份是真实的、可信任的。
   

3. 那怎么验证对某个证书验证呢？过程如下
   

HTTPS运行过程