计算机网络—HTTP

╰半夏微凉° 2021-11-10 00:44 491阅读 0赞

## HTTP协议 ##

### 1.HTTP简介 ###

HTTP–Hyper Text Transfer Protocol，超文本传输协议，是一种建立在TCP上的无状态连接，整个基本的工作流程是客户端发送一个HTTP请求，说明客户端想要访问的资源和请求的动作，服务端收到请求之后，服务端开始处理请求，并根据请求做出相应的动作访问服务器资源，最后通过发送HTTP响应把结果返回给客户端。其中一个请求的开始到一个响应的结束称为事务，当一个事物结束后还会在服务端添加一条日志条目。

### 2.HTTP报文 ###

用于HTTP协议交互的信息被称为HTTP报文. 请求端(客户端)的HTTP报文叫做请求报文, 响应端(服务器端)的叫做响应报文, HTTP报文本身是由多行(用CR+LF作换行符)数据构成的字符串文本

HTTP报文大致可分为报文首部和报文主体两块. 两者由最初出现的CRLF来划分

#### 1>请求报文 : ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dpbnRlcnNoaWk_size_16_color_FFFFFF_t_70]

#### 2>响应报文 : ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dpbnRlcnNoaWk_size_16_color_FFFFFF_t_70 1]

请求行包括 : 请求方法, 请求的URL, HTTP版本

首部行 : 首部包括的参数和参数值, 一行包括一个键值对

状态行 : 包含表明响应结果的状态码, 原因短语和HTTP版本

#### 请求方法 : ####

*  GET : 获取资源
 *  POST : 传输实体主体
 *  PUT : 用来传输文件, 请求报文的主体中包含文件内容, 然后保存到请求URI指定的位置
 *  HEAD : 获得报文首部, 和GET方法一样, 只是不返回报文主体部分. 用于确认URI的有效性及资源更新的日期时间等
 *  DELETE : 用来删除文件
 *  OPTIONS : 询问支持的方法, 用来查询针对URI指定的资源支持的方法
 *  CONNECT : 要求用隧道协议连接代理, 要求在与代理服务器通信时建立隧道, 实现用隧道协议进行TCP通信. 主要使用SSL和TLS协议把通信内容加密后经网络隧道传输

#### 响应码 : ####

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>类别</th> 
   <th>原因短语</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1XX</td> 
   <td>Informational(信息性状态码)</td> 
   <td>接收的请求正在处理</td> 
  </tr> 
  <tr> 
   <td>2XX</td> 
   <td>Success(成功状态码)</td> 
   <td>请求正常处理完毕</td> 
  </tr> 
  <tr> 
   <td>3XX</td> 
   <td>Redirection(重定向状态码)</td> 
   <td>需要进行附加操作以完成请求</td> 
  </tr> 
  <tr> 
   <td>4XX</td> 
   <td>Client Error(客户端错误状态码)</td> 
   <td>服务器无法处理请求</td> 
  </tr> 
  <tr> 
   <td>5XX</td> 
   <td>Server Error(服务器错误状态码)</td> 
   <td>服务器处理请求出错</td> 
  </tr> 
 </tbody> 
</table>

*  2XX 成功
    
     *  200 OK : 表示客户端发来的请求在服务器端被正常处理了
     *  204 No Content : 表示服务器接受的请求已成功处理, 但在返回的响应报文中不包含实体的主体部分
     *  206 Partial Content : 表示客户端进行了范围请求, 服务只对这部分进行响应
 *  3XX 重定向
    
    3XX响应结果表明浏览器需要执行某些特殊的处理以正确处理请求
    
     *  301 Move Permanently : 永久性重定向. 该状态码表示请求的资源已经被分配了新的URI, 以后应使用资源现在所指的URI
     *  302 Found : 临时性重定向, 表示请求的资源已被分配了新的URI, 希望用户本次能用新的URI访问
     *  303 See Other : 表示由于请求对应的资源存在着另一个GET方法定向获取请求的资源
     *  304 Not Modified : 表示客户端发送附带条件的请求时, 服务器端允许请求访问资源, 但请求未满足条件
     *  307 Temporary Redirect : 临时重定向, 该状态码 与302 Found有着相同的含义
 *  4XX 客户端错误
    
     *  400 Bad Request : 该状态码表示请求报文存在语法错误
     *  401 Unauthorized : 表示发送的请求需要有HTTP认证的认证信息, 初次接收到401响应, 会弹出认证用的对话窗口
     *  403 Forbidden : 表明对请求资源的访问被服务器拒绝了
     *  404 Not Found : 表明服务器上无法找到请求的资源
 *  5XX 服务器错误
    
     *  500 Internal Server Error : 表示服务器端在执行请求时发生了错误
     *  503 Service Unavailable : 表明服务器暂时处于超负载或正在进行停机维护

### 3.HTTPS ###

由于HTTP使用明文通信, 内容可能会被窃听; 不验证通信方的身份, 可能遭遇伪装; 无法证明报文的完整性, 可能已被篡改. 为了解决上面的几个缺点, SSL协议诞生了.所谓的HTTPS就是HTTP与SSL/TLS的结合使用

首先加密方式是分为**对称加密**和**非对称加密**的

#### 1>对称加密 ####

就是在编码时使用的密钥和解码时的密钥一样. 发送端和接收端要共享相同的密钥k才能进行通信, 发送端用共享密钥k对明文进行加密, 将加密后的密文发给接收端, 接收端收到密文后, 并用其相同的共享密钥k对其进行解密, 得到明文

*  不足之处:
    
     *  发送方和接收方需要共享相同的密钥, 就需要把共享密钥在双方之间安全的分享, 不能被他人窃取
     *  由于对称加密的密钥是一对一的方式, 若要跟n方通信, 则需要维护n对密钥
 *  好处 :
    
     *  对称加密的加密 和解密速度比非对称加密快很多

#### 2>非对称加密 ####

为了解决用于对称加密在发送方和接收方之间的安全传输, 我们用到了非对称加密. 非对称加密其实就是加密的密钥和解密的密钥是不同的, 并且加密的密钥k是公开的, 叫做公钥. 解密的密钥d是保密的,叫私钥.

加密方找到接收方的公钥k, 然后用用公钥k对明文进行加密后, 将密文发送给接受方, 接受方收到后用 私钥进行解密, 得到明文中的内容

*  不足之处
    
     *  没有对称加密速度快
 *  好处 :
    
     *  不存在密钥分发问题, 服务器自己生成密钥对,一个做私钥保存起来 , 另一个作为公钥发布
     *  多个加密方都可以使用一个已知的公钥进行加密, 只有私钥方才能解密

综上所述, HTTPS是使用对称加密和非对称加密混合的一种加密方式, 其过程是这样的 : **客户端请求服务器, 服务器返回给客户端一个公钥(带有颁发证书, 保证不被第三方替换), 然后客户端使用公钥对 用于后面对称加密的密钥进行加密, 然后返回给服务器端, 服务器得知了用于对称加密的密钥后, 双方就可以使用对称加密进行通信了**

#### 3>Hash算法 ####

哈希函数, 可以将任意长度的消息m映射为一个长度较短的固定值H, 是一种单向密码体质, 即一个明文到密文的不可逆映射, 只有加密过程, 没有解密过程

*  哈希和加密的选择 : 如果被保护的数据仅仅用于比较验证, 之后不需要还原明文形式, 就是用哈希. 如果被保护的数据在之后还需要被还原成明文, 则需要使用加密

#### 4>数字证书 ####

**1.数字签名:**

签名作用 : 数字签名对原文的保密性没有要求, 但是负责两件事 : **发送者的身份, 发送的内容是否完整**

签名原理 : 发送的内容是否完整, 可以使用上面 说的哈希算法, 生成一段摘要. 根据摘要来验证内容是否完整. 而 身份的验证, 可以使用我们前面说的 非对称加密算法(RSA). 发送者可以用自己的私钥对摘要进行加密. 接收者根据公钥 进行解密, 解密成功,确认发送者

**一次完整的签名过程 :**

A为发送者, B为接收着

*  A对外发布公钥, 并声明私钥在自己手上
 *  A对发送的 消息M根据hash算法计算生成摘要, 得到摘要 D
 *  A用私钥对D进行签名, 得到签名S
 *  将M和 S一起发送出去

**验证过程 :**

*  B对M根据同样的hash算法计算摘要, 得到摘要 D1
 *  使用A发布 的公钥对S进行解密, 得到D
 *  如果D和D1相同, 就说明M确实是A发出的, 且没有被篡改过

数字签名的问题 : 在B验证A的身份时, 使用A的公钥进行验证, 这个过程可能存在问题. 假如有一个C, 它伪造了A的一对公钥和私钥. 并将伪造后的公钥发给B. 此时C伪装成A发布消息, 并根据自己的私钥生成数字签名, 发给B. 此时B根据C伪装的公钥, 就无法验证真正的A. 这个问题要得到解决, 就需要数字证书的加入

**2.数字证书:**

为了解决上面的问题, 即保证B收到的公钥一定是A发出的. 引入了一个证书中心(CA机构), 为A的公钥做认证. 具体方法 就是, 用该 CA机构自己的私钥对A的公钥进行加密生成"数字证书"

证书的获得 :

*  A去找 CA证书中心, 提供私钥, 组织信息, 个人信息(域名)等信息, 申请认证
 *  CA通过线上, 线下等手段验证申请者的身份真实性, 向申请者发送认证数字证书
 *  数字证书包含的内容 : A公钥内容, 签发者id, Subject–也就是这个证书签发给谁, 有效期, 其他信息, 以上是明文, 称为内容P
 *  用P进行hash计算, 得到一个hash值 H, 然后用签发金钩的私钥对H进行RSA加密, 得到 签名信息S
 *  将明文P和签名H连载一起就是数字证书

**证书的发送:**

*  证书的发送, 在上面A向B发送公钥的时候, 将自己获取的证书一同进行发送, 让B可以确定这时A发送的公钥

**证书的验证:**

*  B收到证书时, 用CA的公钥解密这份数字证书, 拿到A的公钥, 然后验证数字签名, 后面的流程就和前面的数字 签名一样了

证书的问题 :

假设数字证书被伪造了 : 如果对于当前的证书不信任, 可以一直去请求给当前CA做保证的上一级CA, 这样子一直递归查询, 直到找到一个CA机构. 根CA机构的公钥, 一般直接写入到了操作系统的底层里, 保证其可靠性

#### 3>SSL协议通信过程 ####

*  1.客户端请求建立SSL连接, 并将一个随机数RNc和自己支持的一套加密规则发送给服务器
 *  2.服务器从中选出一组加密算法与HASH算法,生成一个随机数RNs发送给客户端,并将自己的身份信息以**证书**的形式返回给浏览器. 证书里面包含了网站地址, 加密公钥, 以及证书的颁发机构等等,并告诉客户端第一阶段握手结束.
 *  3.浏览器拿到网站证书后 :
    
     *  1.验证证书的合法性.
     *  2.如果证书受信任, 浏览器会生成一串随机的密码PMS, 并用证书中提供的公钥加密,发送给服务器签名验证是两个不同的概念。
        
        （一）先来说加密解密：需要同时使用公钥和私钥的加密算法是
 *  4.网站接收浏览器发来的数据之后 :
    
     *  1.使用自己的私钥将PMS取出
 *  5.客户端和服务器都使用PMS+RNc+RNs三个随机数生成用于对称加密的密钥
 *  6.浏览器发送Change Cipher Spec报文, 该报文之后的通信会用前面三个随机值生成的密钥进行加密
 *  7.客户端发送Finished报文, 该报文包含从连接至今所有报文的整体校验值, 这次报文是否能够成功, 要以服务器是否能够正确解密该报文作为评判标准
 *  8.服务器同样发送Change Cipher Spec报文, 告诉客户端后面的报文用之前生成的密钥进行加密
 *  9.服务器同样发送Finished报文
 *  10.服务器和客户端的Finished报文交换完毕 后, SSL连接就算建立完成.
 *  11.此后的通信使用对称加密(之前的随机生成的密钥)进行数据加密传输

![1][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dpbnRlcnNoaWk_size_16_color_FFFFFF_t_70]: /images/20211109/5ee4da2ec0c5476f8c6022efdc2197e7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dpbnRlcnNoaWk_size_16_color_FFFFFF_t_70 1]: /images/20211109/963d4b7db004454a8c053cc3f4da995a.png
[1]: /images/20211109/d238a9296c864db5a491b03ade923bfd.png