DHCP和HTTP2_3

DHCP和HTTP2_3

文章目录

• DHCP和HTTP2_3
• • 一、前言
  • 二、DHCP协议
  • • [2.1 概述](#2.1 概述)
    • • [2.1.1 定义](#2.1.1 定义)
      • [2.1.2 作用](#2.1.2 作用)
    • [2.2 DHCP服务器](#2.2 DHCP服务器)
    • [2.3 DHCP工作机制](#2.3 DHCP工作机制)
  • 三、HTTP2_3协议
  • • [3.1 HTTP2.0](#3.1 HTTP2.0)
    • • [3.1.1 最初的HTTP](#3.1.1 最初的HTTP)
      • [3.1.2 HTTP的瓶颈](#3.1.2 HTTP的瓶颈)
      • [3.1.3 SPDY](#3.1.3 SPDY)
      • [3.1.4 HTTP2的发展进程](#3.1.4 HTTP2的发展进程)
    • [3.2 HTTP3.0](#3.2 HTTP3.0)
  • 四、小结

一、前言

计算机想要实现组网，离不开各种的配置（IP，子网掩码，网关和DNS服务器等），这些其实是可以实现自动配置的，而这一切离不开DHCP协议的支持。

先前讲了HTTP1.0和1.1版本，尽管1.1在1.0的基础上进行了改进，但仍然存在问题，其实还有2.0和3.0的版本，今天我们一同来认识吧~

二、DHCP协议

2.1 概述

计算机为了实现数据通信，提出了组网。

工具	过程	结果
IP、mask	网络内的机器可以进行身份识别	局域网可以通信
网关	非网络的数据包可以进行转发	不同网络的通信
DNS服务器	域名（人类懂的）向IP（机器可以识别的）的映射	因特网的通信

这些信息本来都是手动配置的，那么能不能实现自动配置 呢？这就有了DHCP协议。

2.1.1 定义

DHCP（Dynamic Host Configuration Protocol，动态主机配置协议），使用DHCP就能实现自动设置IP地址、统一管理IP地址分配。

2.1.2 作用

• 省去了手动配置IP地址这一步繁琐的操作，同时也大大减少了可能由于手动配置IP地址导致错误的几率
• DHCP与IP密切相关，它是IP网络上所使用的协议。如果你想要使用DHCP提供服务的话，那么在整条通信链路上就需要DHCP服务器的存在，连接到网络的设备使用DHCP协议 从DHCP服务器 请求IP地址。DHCP服务器会为设备分配一个唯一的IP地址

但是，我们的机器本来没有IP地址，它怎么知道DHCP的存在呢？并且DHCP服务器怎么回给我们分配的具体信息呢？

2.2 DHCP服务器

网络管理员 负责建立DHCP服务器，DHCP服务器会维护IP地址池 ，并以租约 的形式向启用DHCP的客户端提供地址配置，由于IP地址是动态的（临时分配）而不是静态的（永久分配），因此不再使用的IP地址会自动返回IP地址池中进行重新分配。

网络管理员是谁？

DHCP服务器通常由网络管理员或IT部门维护，具体维护主体取决于网络环境：

• 企业/机构网络：由企业IT部门或网络管理员负责，他们配置DHCP地址池、租约时间、保留地址、排除范围等参数，并监控服务器运行状态。
• 家庭/小型网络 ：由路由器自动维护，家用路由器内置DHCP服务器功能，自动分配192.168.x.x网段的IP地址，用户无需手动配置。
• 互联网服务提供商（ISP）：为宽带用户分配公网IP地址的DHCP服务器由ISP维护，用户通过PPPoE拨号获取动态公网IP
• 云服务/数据中心：由云服务商或数据中心运维团队维护，为虚拟机、容器等云资源分配IP地址

动态 、租约 ：DHCP服务器通常为每个客户端分配了一个唯一的动态IP地址，当该IP地址的客户端租约到期时，该地址就会更改

唯一：如果你手动设置了一个静态IP，同时DHCP服务器分配了一个动态IP，这个动态IP和静态IP一样，那么必然会有一个客户端无法上网
我使用虚拟机配置的静态IP是192.168.1.8，手机使用DHCP也同样配置了192.168.1.8的IP地址，此时我的虚拟机还没有接入网络，当我接入网络时，我怎样也接不上虚拟机了，一查才发现IP地址冲突了

虽然DHCP服务器能提供IP地址，但是他怎么知道哪些IP地址空闲，哪些IP地址正在使用呢？

实际上，这些信息都配置在了数据库中，下面我们就来一起看一下DHCP服务器维护了哪些信息

• 网络上所有有效的TCP/IP配置参数

  这些参数主要包括主机名（Host name）、DHCP客户端（DHCP client）、域名（Domain name）、IP地址IP address）、网关（Netmask）、广播地址（Broadcast address）、默认路由（default rooter）

• 有效的IP地址和排除的IP地址，保存在IP地址池中

• 为某些特定的DHCP客户端保留的地址，这些地址是静态IP，这样可以将单个IP地址一致地分配单个DHCP客户端

2.3 DHCP工作机制

DHCP报文共有以下几种：

• DHCP DISCOVER ：客户端开始DHCP过程发送的包，是DHCP协议的开始

  广播，局域网中所有人都会收到这个数据包

  当局域网内有多个DHCP服务器，就会导致分配冲突，因此，只能有一台

  

• DHCP OFFER ：服务器接收到DHCPDISCOVER之后做出的响应，它包括了给予客户端的IP租约过期时间、服务器的识别符以及其他信息

  因为没有IP，因此使用UDP协议发送响应

  

• DHCP REQUEST：客户端对于服务器发出的DHCPOFFER所作出的响应。在续约租期的时候同样会使用

  

• DHCP ASK：服务器在接收到客户端发来的DHCPREQUEST之后发出的成功确认的报文。在建立连接的时候，客户端在接收到这个报文之后才会确认分配给它的IP和其他信息可以被允许使用

  

  会发送两个ARP：

  • 服务器将IP正式赋予客户端
  • DHCP客户端发送ARP来检测是否IP被占用

  当租约快到期：

  

• DHCP NAK ：DHCPACK的相反的报文，表示服务器拒绝了客户端的请求

• DHCP RELEASE ：一般出现在客户端关机、下线等状况。这个报文将会使DHCP服务器释放发出此报文的客户端的IP地址

• DHCP INFORM：客户端发出的向服务器请求一些信息的报文

• DHCP DECLINE：当客户端发现服务器分配的IP地址无法使用（如IP地址冲突时），将发出此报文，通知服务器禁止使用该IP地址

DHCP服务器的端口是67，客户端是68（固定）

三、HTTP2_3协议

3.1 HTTP2.0

老版本有哪些瓶颈，新版本是如何解决的？

3.1.1 最初的HTTP

HTTP诞生之初只用于web端的内容获取 ，一般就是用于页面访问，那个时候的页面内容还不如现在这样丰富，交互场景也不是很多，也没有庞大繁杂的CSS、JS ，页面加载速度非常快。但是随着web2.0的出现以及更多的内容被展示、更精美的排版、更多的用户交互场景一起出现，导致页面的内容越来越大，使得页面加载速度越来越慢。

3.1.2 HTTP的瓶颈

影响一个HTTP网络请求的因素主要有两个：带宽和延迟

• 带宽

  如果我们还停留在拨号上网阶段 的话，带宽很容易出现瓶颈，因为单位时间内传输的数据量很小，但是现在随着光纤等通信技术 的不断发展。10Mbps、100Mbps、甚至1000Mbps进入了每个家庭，我们不用再担心带宽成为网络请求的瓶颈。

• 延迟

  • 浏览器阻塞 （HOL blocking）：浏览器会因为一些原因阻塞请求，浏览器对于同一个域名，同时只能由6个连接（这个根据浏览器内核不同可能会有所差异），超过浏览器最大连接限制，后续请求就会被阻塞
  • DNS查询 （DNS Lookup）：浏览器需要知道目标服务器的IP才能建立连接。将域名解析为IP的这个系统就是DNS。这个通常可以利用DNS缓存减少这个消耗的时间
  • 建立连接 （Initial connection）：HTTP是基于TCP协议 的，浏览器最快也要在第三次握手时才能捎带HTTP请求报文，达到真正的建立连接，但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响明显，慢启动则对文件类大请求影响较大

HTTP1.0弊端：

• 连接无法复用。当每次有新的请求时都会重新经历一次三次握手和四次挥手过程，并且连接的建立和释放需要耗费大量的服务器资源。

  解决 ：HTTP1.0协议头里可以设置Connection:Keep-Alive。在header里设置Keep-Alive可以在一定时间内复用连接，具体复用时间的长短可以由服务器控制，一般在15s左右。到HTTP1.1之后Connection的默认值就是Keep-Alive，如果要关闭连接复用需要显示的设置Connection:Close

• 队头阻塞（head of blocking）。队头阻塞问题会导致带宽无法充分利用，导致后续的请求被阻塞

假如有五个请求被同时发出，如果第一个请求没有处理完成，就会导致后续的请求也无法得到处理

等到请求1被处理完毕后，才能逐个发出，一旦请求1因为某些原因没有抵达服务器，或者请求因为网络阻塞没有及时返回，影响的就是所有后续请求，导致后续请求无限阻塞下去，问题就变得比较严重了。

解决：在HTTP1.1中，提出了**流水线（pipelining）**的设计，用来解决队头阻塞的问题。

虽然这种流水线的设计看似能够解决阻塞问题，因为右图中这三个请求没有等到响应到达后再进行发送，而是直接依次发送，但是实际上，并不是那么回事

pipelining存在不少缺陷：

• 因为只有幂等的请求比如GET、HEAD才能使用pipelining，非幂等请求比如POST则不能使用，因为请求之间可能存在先后依赖关系

  资源访问具有先后关系

• 其实队头阻塞问题并没有完全解决，因为服务器返回的响应还是要依次返回，也就是返回的请求时FIFO-先发先回

• 绝大多数HTTP代理服务器不支持pipelining

• 和不支持pipelining的老服务协商有问题

3.1.3 SPDY

虽然HTTP1.0和HTTP1.1存在这么多问题，业界也是想出了各种优化手段，但是这些手段怎么说呢？都是治标不治本 ，直到2020年Google提出了SPDY 的方案（内部方案），大家才开始从正面看待和解决老版本HTTP协议本身的问题，这也直接加速了HTTP2.0的诞生

SPDY 的目标在于解决 HTTP 的缺陷，即延迟和安全性 。延迟，上面已经讨论过了，安全性， HTTP 的明文传输确是个问题。如果以降低延迟为目标，应用层的 HTTP 和传输层的 TCP 都是都有调整的空间，不过 TCP 作为操作系统内核的部分，现已深植全球的网络基础设施当中，如果要动必然是大工程，业界响应度必然不高，所以 SPDY 针对的是 HTTP。

SSL属于安全验证的层次，SPDY位于HTTP下面，能够兼容老版本的HTTP协议

SPDY的功能分为基础功能和高级功能两部分，基础功能是默认启用的，高级功能需要手动启用。

SPDY基础功能

• 多路复用 (multiplexing)，通过多个请求共用一个连接的方式，降低了TCP连接建立和释放的开销，同时提高了带宽的利用率。

• 请求优先级(request prioritization)，多路复用带来的一个问题是在共享连接的基础上会存在一些关键请求被阻塞，SPDY允许给每个请求设置优先级，这样重要的请求就会优先得到响应。

• header压缩 ，前面提到的HTTP 1.x的header很多时候都是重复而且多余的。选择合适的压缩算法可以减小包的大小和数量。SPDY对header的压缩率可以达到80%以上。

  HTTP1.x是字符串协议（文本协议）比较冗余，尽管便于人类阅读和代码解析

  于是后来换成了二进制协议

SPDY高级功能

• 服务端推送。一开始HTTP只能由客户端发送，服务器只能被动发送响应。在开启服务端推送后，服务端通过X-Associated-Content header会告知服务器会有新的内容被推送过来。
• 服务端暗示。和服务端推送所不同的是，服务端暗示不会推送内容，只是告诉客户端有新的内容产生，内容的下载还是需要客户端主动发起请求。服务端暗示通过X-Subresources header来通知，一般应用场景是客户端需要先查询服务端状态，然后再下载资源，可以节约一次查询请求

3.1.4 HTTP2的发展进程

初探HTTP2

SPDY 更像是 Google 自家的一个产品，而 HTTP 2.0 在设计之初就是为了普适性的这个目的，所以，一开始任何的设计都会关系到以后的维护问题，如果有什么瑕疵或者不足的地方可能会影响巨大，所以考虑的问题角度要非常严谨和慎重。

HTTP 2.0 在设计之初就有一些重要的前提：

• 客户端向服务器发送请求的这种基本模型不会改变。
• 原有的协议头不会改变，使用 http:// 和 https:// 的服务和应用不会做任何修改，不会有 http2://。
• 使用 HTTP 1.x 的客户端和服务器可以平滑升级到 HTTP 2.0 上。
• 不识别 HTTP 2.0 的代理服务器可以将请求降级到 HTTP 1.x。

客户端在和服务器确定是使用 HTTP 1.x 还是 HTTP 2.0 之前，需要先确定对方是否支持 HTTP 2.0，所以这里必须要先进行协商，也就是客户端访问服务器，这样一来一回就多了一个 RTT 的延迟。我们对 HTTP 1.x 的修改就是为了降低延迟，现在又多了一个 RTT，这样显然是无法接受的。Google 制定 SPDY 协议的时候也遇到了这个问题，他们采取的做法是强制协商在 SSL 层完成，因此制定了一个 TLS 的拓展，叫做 NPN (Next Protocol Negotiation)。虽然 HTTP 2.0 也采用了相同的方式，不过经过讨论后，最终 HTTP 2.0 没有强制要走 SSL 层，HTTP 2.0 没有使用 NPN，即制定了一个 TLS 的拓展叫做 ALPN (Application Layer Protocol Negotiation)，现在，SPDY 也打算迁移到 ALPN 了。

HTTP 2.0 的主要变化

• 二进制格式

  HTTP 1.x的诞生使用的是明文 协议，而协议解析是基于文本的，存在多样性的缺陷，而二进制格式只能识别0和1，比较固定，因此HTTP 2.0决定采用二进制格式，实现方便而且健壮性强。

  HTTP 1.x和HTTP 2.0使用的不同的报文格式：

  

  • length定义了整个frame的开始到结束
  • type定了frame的类型，一共有十种
  • flags定义了一些重要的参数
  • stream id用作流控制
  • payload就是request的正文

  虽然HTTP 2.0报文格式看上去和HTTP 1.x的完全不同，但是实际上HTTP 2.0并没有改变HTTP 1.x的语义，它只是在HTTP 1.x的基础上封装了一层，如下图所示：

  

  从上图可以看到，HTTP 1.x 中的请求行、请求头被 HTTP 2.0 封装成为了 HEADERS Frame，而 HTTP 1.x 中的报文体被 HTTP 2.0 封装成为了 Data Frame。调试的时候浏览器会把 HTTP 2.0 的 frame 自动还原成 HTTP 1.x 的格式。

• 连接共享

  我们上面聊到，HTTP 1.x 并没有真正意义上的解决连接复用问题，所以 HTTP 2.0 要解决的一大难题就是连接共享（MultiPlexing）。连接共享意味着客户端与服务器之间也只需要一个连接即可，这样即使来自很多流的数据包也能够混合在一起通过同样连接传输，再根据不同帧首部的 stream id 标识符重新连接将不同的数据流进行组装。

  

  什么是 stream？

  stream 是连接中的一个虚拟信道，可以承载双向消息传输。每个流有唯一整数标识符。为了防止两端 stream id 冲突，客户端发起的流具有奇数 id，服务器端发起的流具有偶数 id。

  我们上面提到 HTTP 1.x 没有真正解决连接共享还有一个主要的因素就是无法对不同的请求设置优先级，这样会导致关键请求被阻塞。而 HTTP 2.0 你可以对不同的 stream 设置不同的优先级，stream 之间也可以设置依赖，依赖和优先级都可以动态调整，这样就会解决关键请求被阻塞的问题。

• 头部压缩

  上面还聊到了 HTTP 1.x 中的 header 由于 cookie 和 user agent 不存在记忆性，这样导致每次都要带着这些头重新发送请求，HTTP 2.0 使用 encoder 来减少传输的 header 大小，通信双方会各自缓存一份 header 字段表，这样能够避免重复传输 header，也能够减小传输的大小。HTTP 2.0 采用的是 HPACK 压缩算法。

  这种压缩算法的主要思想可以参考官方文档 https://httpwg.org/specs/rfc7541.html

• 服务端推送

  服务端推送 (Server Push) 我们上面已经聊过，HTTP 2.0 能够以推 的方式将客户端的内容预先发送出去，正因为没有发起请求，建立连接等操作，所以静态资源通过服务端推送的方式可以极大地提升速度。服务端推送还有一个更大的优势：缓存，缓存能够在不同页面之间共享缓存资源。

  需要注意下面几个点：

  • 推送遵循同源策略
  • 这种服务端的推送是基于客户端的请求响应来确定的。

  当服务端需要主动推送某个资源时，便会发送一个 Frame Type 为 PUSH_PROMISE 的 frame，里面带了PUSH需要新建的stream id，意思是告诉客户端：接下来我要用这个id向你发送东西，客户端准备好接着。客户端解析frame时，发现它是一个PUSH_PROMISE类型，便会准备接收服务端要推送的流。

HTTP 2.0的缺陷：

• 多路复用虽然好，但是它是建立在TCP连接的基础上，在连接频繁的情况下，TCP的三次握手很容易成为性能瓶颈。
• 使用HTTP 2.0会增加一次TLS握手过程，增加RTT。
• 在HTTP 2.0中，多个请求是在同一个TCP管道中，这样当HTTP 2.0出现丢包时，整个TCP都要开始等待重传，那么就会阻塞该TCP连接中的所有请求。

3.2 HTTP3.0

众所周知，HTTP 是应用层协议，应用层产生的数据会通过传输层协议作为载体来传输到互联网上的其他主机中，而其中的载体就是 TCP 协议，这是 HTTP 2 之前的主流模式。

但是随着 TCP 协议的缺点不断暴露出来，新一代的 HTTP 协议 - HTTP 3.0 毅然决然切断了和 TCP 的联系，转向了 UDP 协议，其实不太准确，其实 HTTP 3.0 其实是转向了 QUIC 协议 ，而 QUIC 协议是建立在 UDP 协议基础上的。

HTTP 3.0 的诞生

HTTP 3.0 于 2022 年 6 月 6 日正式发布，IETF 把 HTTP 3.0 标准制定在了 RFC 9114 中，HTTP 3.0 其实相较于 HTTP 2.0 和 HTTP 1.1 的变化来说小很多，最大的提升就在于效率，替换 TCP 协议为 UDP 协议，HTTP 3.0 具有更低的延迟，它的效率甚至要比 HTTP 1.1 快 3 倍以上。

TCP的主要作用是以正确的顺序将整个字节流从一个端点传输到另一个端点，但是容易造成TCP队头阻塞 问题。而使用UDP又会丢包。

那么可能就会有人考虑到去修改TCP协议，但是这属于操作系统内核的部分，更新不现实。

基于这个原因，Google就更起炉灶搞了一个基于UDP协议的QUIC协议，并且使用在了HTTP/3上，HTTP/3之前名为HTTP - over - QUIC，从这个名字中我们也可以发现，HTTP/3最大的改造就是使用了QUIC。

四、小结

DHCP协议：DHCP服务器有赖于DHCP协议为主机动态分配IP地址等一系列配置信息，其中的机制值得深思。（比如服务器和主机借助UDP发送数据包）

HTTP2_3协议：每一代 HTTP 协议的不断发展都是建立在上一代 HTTP 的缺点上的，2的提升点是二进制格式传输和共享连接，3的提升点是传输不再依赖TCP，而是UDP进阶版------QUIC协议
计网的内容到这里就结束啦，后续可能会更新计网相关的题目。。。（画饼）计算机的网络设计真的是非常伟大的艺术品，值得我们去深入挖掘先贤的智慧，并续写新时代的篇章。

建议对网络感兴趣的小伙伴可以多多阅读相关文献、书籍，会有更多收获。

最后，感谢每一位读者对我的支持♥