输入URL之后的全过程

从输入的URL中解析出使用的协议、主机、端口号等，构造一个HTTP请求
DNS解析域名，解析成对应的ip地址
TCP三次握手，建立连接
浏览器发送HTTP/HTTPS请求到web服务器
服务器处理HTTP/HTTPS请求并返回报文
浏览器渲染页面
断开连接，tcp四次挥手

URL URI

在网络技术中，URI（Uniform Resource Identifier，统一资源标识符）和URL（Uniform Resource Locator，统一资源定位符）是两个非常基本的概念，它们都用于在网络上标识资源，但它们之间存在一些区别：

URI（统一资源标识符）：
- URI是一个用于标识某一互联网资源名称的字符串。
- URI的主要目的是标识资源，它可以是URL或URN（Uniform Resource Name，统一资源名称）。
- 例如，https://example.com/path?query=123 是一个URI。
URL（统一资源定位符）：
- URL是URI的一个子集，不仅标识资源，还提供了找到该资源的方式。
- URL通常包括协议（如HTTP、HTTPS）、服务器位置和资源在服务器上的具体地址。
- 例如，https://example.com/path?query=123 是一个URL，它告诉你如何通过HTTPS协议访问example.com上的某个资源。

总结来说，每个URL都是URI，但不是每个URI都是URL。URI更广泛，它还包括URN，而URN仅仅标识资源的名称，不提供定位信息。例如，urn:isbn:0451450523是一个URN，用于标识特定的书籍，但并不提供获取书籍的具体位置。

DNS (Domain Name System)

概念：将域名转换为ip的分布式系统

为什么分布式

单点故障会使整个网络瘫痪
远程服务器请求时间较长，造成严重的时延
维护成本过高

域名的层级关系

考点号来分隔，代表不同层次，越靠右层级越高

解析过程

先查询浏览器缓存是否存有ip地址
若没有，则查询计算机本地的host文件是否有缓存
向本地的DNS服务器发送查询请求，有就返回
若没有，本地的DNS解析器会向根DNS服务器发出查询请求，返回结果是应该向哪个顶级域的DNS服务器查询
本地解析器向顶级域名DNS服务器发送请求，返回结果是向哪个权威DNS服务器查询下一步
本地解析器发送请求给权威DNS服务器，返回结果是ip地址
本地解析器返回结果给浏览器，同时将结果缓存本地
浏览器发起连接

递归查询和迭代查询

递归查询：DNS客户端只需要发送一个查询请求，就可以等待完整的解析结果
迭代查询：DNS客户端通过向上级DNS服务器发送请求，获取更高级的域名服务器地址，向其发送请求，直到获得完整的解析结果
总结：递归查询适合普通用户和客户端，迭代查询适用于DNS服务器之间的通信

HTTP

特性

简单：基本报文格式为header+body，头部信息是key-value简单文本的形式
灵活和易于扩展：协议中的各种请求方法、URL\URI、状态码、头字段等每个组成部分没有被定死，允许自行补充；在应用层，下层可以随意变换；HTTPS是在http和tcp之间添加了ssl/tsl安全传输层，HTTP/3则是把TCP换成了基于UDP的QUIC
无状态：服务器不会去记忆HTTP的状态，可以减轻服务器负担
明文传输：信息透明易被窃取
不安全：通信使用明文；不验证身份、无法证明完整性
应用广泛且跨平台

版本演变

0.9

只支持GET，只能返回HTML格式

1.0

第一个正式版本
引入请求头和响应头，支持多种请求方法和状态码
不支持持久连接

1.1

提出了长连接，客户端和服务端任意一端没有明确提出断开连接，则保持tcp连接
管道网络传输：解决请求的队头堵塞；可以同时发送多个请求，服务器必须按照接受请求的顺序处理，会造成响应队头堵塞

问题

延迟难以下降，达到了延迟的下限
并发连接有限，而且每一个连接都要经过TCP和TLS握手耗时，以及TCP慢启动过程带来的影响
头部冗余，头部巨大且重复，特别是携带cookie的，cookie的大小通常很大
响应队头堵塞
没有请求优先级控制
不支持服务器推送消息，只能客户端发送请求，浪费了大量的带宽和服务器资源

优化

将多张小图合并成大图供js切割，也就是多个请求合并成一个请求；但是当一个小图改变了就要重新请求大图
将图片的二进制数据通过base64编码之后，将数据嵌入到css或者html
将多个体积较小的js文件使用webpack等工具打包成一个体积更大js，带来的问题跟小图合并成大图一样
将同一个页面资源分散到不同域名，提升并发连接上限

2

基于HTTPS；为改善HTTP1.1而提出，同时兼容了HTTP1.1

兼容

平滑升级：没有引入新的协议名，只需要浏览器和服务器在背后升级协议
只在应用层做改变，分解成语义和语法；语义方面完全一致（请求方法、状态码、头字段等）

改变

在语法方面做了很多改变，基本改变了HTTP报文传输

头部压缩：使用 HPACK 压缩算法对请求响应头部进行压缩，减少了传输的头部数据量，降低了延迟。
二进制帧：将数据分割成二进制帧进行传输，分为头信息帧（Headers Frame）和数据帧（Data Frame），增加了数据传输的效率。
并发传输：引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接，针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream ，也就是 HTTP/2 可以并行交错地发送请求和响应。
服务器推送：服务器可以对客户端的一个请求发送多个响应，即服务器可以额外的向客户端推送资源，而无需客户端明确的请求。

特性	改进	HTTP1存在问题
头部压缩（HPACK）	使用`HPACK`压缩算法对请求和响应的头部进行压缩，减少了传输的头部数据量，降低了延迟。 HPACK算法：静态字典（为高频出现的字符串和字段建立一张静态表），动态字典（生效的前提，必须同一个连接，重复传输完全相同的HTTP头部）、Huffman编码（压缩算法）	1. 含有很多固定字段 2. 大量的请求和相应的报文有很多字段值重复 3. 字段是ASCII编码，效率低，需要改成二进制编码
二进制帧	将数据分割成二进制帧进行传输，主要有头信息帧（Headers Frame）和数据帧（Data Frame），还可以使用位运算，增加数据传输的效率。	HTTP1文本格式降低了传输效率
并发传输	引入了Stream概念，多个Stream可以复用在一条TCP连接上。每个HTTP请求用独一无二的Stream ID来标识，使得接收端可以通过Stream ID有序组装成完整的HTTP消息。不同Stream的帧可以乱序发送，允许并行交错地发送请求和响应。
服务器推送	服务器可以对一个客户端请求发送多个响应，即服务器可以在没有客户端明确请求的情况下，向客户端推送额外的资源。

但是 HTTP/2 仍然存在着队头阻塞的问题，只不过问题是在传输层

推送实现

客户端发送的请求必须是奇数号Stream，服务器主动推送的则是偶数号。
服务器推送资源时，通过帧中的Promise Stream ID告诉客户端包体的位置

与HTTP1对比

HTTP1.1 基于请求-响应模型。同一个连接中，HTTP完成一个事务（请求与响应），才能处理下一个事务。即：再发出请求等待响应的过程种是没办法做其他事情的，会造成【队头阻塞】问题。
HTTP2通过Stream这个设计（多个Stream复用一条TCP连接，达到并发的效果），解决了【队头阻塞】的问题，提高了HTTP传输的吞吐量。
HTTP2在访问HTML的时候主动推送CSS文件，减少消息传递次数

并发实现

关键：Stream

HTTP消息可以由多个Frame构成
一个Frame可以由多个TCP报文构成（Frame是最小的单位，以二进制压缩格式存放内容）
不同Stream的帧可以乱序发送，可以通过StreamID组装HTTP消息。还可以设置优先级。

缺陷

队头阻塞：TCP是字节流协议
TCP与TLS的握手时延迟
网络迁移需要重新连接

3

HTTP/3 把TCP协议改成UDP，基于QUIC协议

特点

零RTT连接建立：允许在首次连接时进行零往返时间连接连接建立，减少连接延迟
无队头阻塞：使用UDP协议传输护数据时，一个连接上的多个stream没有依赖，一个丢失并不会影响后续的处理
连接迁移：允许在网络切换时，将连接迁移到新的IP，从而减少连接的中断时间
向前纠错机制：每个数据包包含了部分其他数据包的内容，因此少量丢包时可以通过其他包重组数据；通过牺牲数据上限减少数据重穿

QUIC协议

基于UDP在应用层实现了QUIC协议，有类似于TCP的连接管理、拥塞窗口、流量控制的网络特性，使UDP变得可靠
在协议内部包含了TLS1.3，自己的帧会携带TLS里面的记录，仅需一个RTT就可以同时完成建立连接和密钥协商；在第二次连接时，应用数据包可以和QUIC握手消息一起发送，达到0-RTT

缓存

强制缓存

浏览器判读命中资源是否有效命中强缓存，如果命中则直接读取，不需要进行通讯
Expires强缓存：使用原理是判读本地时间和时间戳，若本机时间不准则容易出问题，基本已废弃
Cache-Control强缓存：http1.1中增加该字段，单位是秒

协商缓存

定义：通过服务端告知客户端是否可以使用缓存
当请求响应码是304时，代表可以使用本地缓存的资源

基于`Last-Modified`和`If-Modified-Since`的协商缓存

服务端读取文件修改时间，赋给相应头的Last-Modified字段
设置Cache-Control:no-cache
客户端读取到Last-Modified时候，会在下次的请求标头中携带字段If-Modified-Since也就是服务器第一次修改给他的时间，之后的每次请求都会带上此字段进行对比，状态码200说明说明资源无新更改，304走缓存
缺点
可能单纯的因为文件修改了又修改回来导致缓存失效
因为记录单位为秒，所以当文件在几百毫米内完成修改，缓存不会改变

基于`ETag`的协商缓存

解决了上面缓存的缺陷，将比较时间戳的形式改成了比较文件指纹（根据文件内容算出唯一哈希值）
过程

1.
缺点

计算开销更大
有强验证（准确到每一个字节）和弱验证（提取文件的部分属性），强缓存过于消耗性能，弱缓存准确率不高

HTTPS（Hyper Text Transfer Protocol Secure）

特点

信息加密：实现信息机密性；对称加密+非对称加密混合，解决了窃听的风险
校验机制：确保数据的完整性；用摘要算法为数据生成独一无二的指纹校验码
身份证书：将服务端的公钥放入到CA证书，解决服务端被冒充的冒险

混合加密

采用非对称加密的方式交换会话密钥，后续则不再使用
通信过程中，全部使用对称加密的会话密钥方式加密
使用原因：对称加密运算速度快，密钥必须保密；非对称加密解决密钥交换问题，但是速度慢

摘要算法+数字签名

摘要算法只能保证内容不被修改，不能保证发送者身份；计算机采用非对称加密来解决
数字签名

发送者使用私钥对消息的摘要（通常是哈希函数计算得到）进行加密，生成数字签名
数字签名是消息的哈希值经过私钥加密的结果
发送者将原始消息和生成的数字签名一起发送给接收者
接收者使用发送者的公钥对数字签名进行解密得到摘要值，再次使用相同的哈希函数计算收到的消息摘要，进行对比

数字证书

解决问题：缺少身份验证的过程，会存在中间人篡改公钥

流程

密钥生成：
- 实体生成一对密钥，包括公开的公钥和私密的私钥。
证书请求（CSR）：
- 实体创建包含公钥和个人信息的CSR，并将其发送至数字证书颁发机构（CA）。
证书颁发：
- CA验证实体后，用私钥签名CSR，生成含签名的数字证书。
证书验证：
- 实体用CA的公钥验证数字证书的签名，核实证书的合法性。
数字证书使用：
- 接收者用证书中的公钥加密数据，发送给持有者，持有者再用私钥解密。
- 持有者可用私钥创建数字签名，接收者用公钥验证以确保数据来源和完整性。

证书信任链

定义：是数字证书的验证过程的一部分，确保数字证书是由可信的证书颁发机构签发，并最终连接到根证书，形成一条链条
根证书：信任链的顶端，也称根CA证书，是数字证书体系中的根基，有操作系统或者浏览器内置
中间证书颁发机构：在信任链中，根证书下方可能有一个或多个CA，数字证书由中间CA签发
服务器证书：在最底层，由中间CA签发，包含了服务器公钥和相关信息，需在客户端验证的过程中被验证

优点

传输过程中，使用密钥加密，安全性跟高
可以认证用户和服务端，确保数据发送到正确的用户和服务器

缺点

握手阶段延时较高，在会话前就要进行SSL握手
部署成本高：需购买CA证书，占用CPU证书，需要服务器配置或者数目高

与HTTP对比

端口号：HTTP是80，HTTPS是443
HTTPS在进行完TCP三次握手之后，还需进行SSL/TSL的握手过程，才可进入加密报文传输
HTTPS协议需要向CA中心申请数字证书，保证服务器身份可靠

HTTPS 建立连接的 SSL/TLS 协议流程概述

客户端请求：客户端发送加密通信请求（ClientHello），与服务器建立连接。
服务器响应：服务器生成一对公私钥，并将公钥提交给CA机构。CA使用自己的私钥对服务器的公钥进行加密，生成CA数字证书。
证书发送：服务器通过响应（ServerHello）将CA数字证书发送给客户端。
证书验证：客户端使用内置的CA公钥解密并验证数字证书是否合法，提取出服务器的公钥。如果验证失败，客户端会发出警告。
生成会话密钥：客户端使用服务器的公钥生成一个随机密钥（会话密钥），并将加密后的密钥发送给服务器。
服务器解密：服务器用私钥解密该随机密钥，获得会话密钥。
加密通信：双方使用会话密钥进行加密通信，确保数据的安全传输。

TCP 和 UDP

UDP

目标端口和源端口：告诉UDP应该发送至哪个进程
包长度：UDP首部的长度跟数据的长度之和
校验和：提供可靠的UDP首部而设计

TCP

窗口大小：还有多少空间能接收数据
标志字段：
ACK：用于指示确认应答号值是否有效，置1表示包含一个对已成功接收报文段的确认；
RST：用于重置一个已经混乱的连接，或拒绝一个无效的数据段或者连接请求；
SYN：用于连接建立过程，请求建立一个连接；
FIN：用于断开连接，表示发送方没有数据要传输了
校验和：CRC算法检测报文段是否出错

TCP 三次握手

⚠️upload failed, check dev console
![[image-20240817204352841.png]]
第一次握手：携带客户端初始序列号的SYN报文
第二次握手：携带服务端初始序列号的SYN+ACK报文，表示收到
第三次握手：携带服务器的ACK报文
为什么需要三次握手？
三次握手才能保证双方具有接收和发送的能力
总结：

三次握手才可以阻止重复历史连接的初始化(主因)
三次握手才可以同步双方的初始序列号
三次握手才可以避免资源浪费

半连接队列（SYN队列）

用于存放已经发送了 SYN（同步）包，但还未完成三次握手的连接：服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

全连接队列（Accept队列）

用于存放已经完成三次握手，处于完全建立连接状态的连接。

TCP四次挥手

在挥手之前，客户端和服务器都处于 ESTABLISHED 状态

第一次挥手：假设客户端打算关闭连接，发送一个TCP首部FIN被置1的 FIN 报文给服务端, 此时客户端处于 FIN_WAIT1 状态
第二次挥手：服务端收到以后，向客户端发送ACK应答报文，且把客户端的序列号值+1作为ACK报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态
第三次挥手：等待服务端处理完数据后，向客户端发送FIN报文。此时服务端处于 LAST_ACK 的状态
第四次挥手：客户端接收到FIN报文后回一个ACK应答报文，之后客户端处于 TIME_WAIT 状态
服务器收到ACK报文后，进入 CLOSE 状态，服务器完成连接关闭。
客户端在经过 2MSL 一段时间后，自动进入 CLOSE 状态，客户端也完成连接的关闭。

为什么四次挥手

客户端发送FIN报文表示不发送数据，但还可以接收数据
关闭连接时，服务端可能还要数据处理和发送，就可以先回一个ACK，等到不再发送数据，再发送FIN表示他同意关闭连接
所以：服务端通常需要等待完成数据的发送和处理，ACK和FIN一般都会分开发

为什么需要TIME_WAIT状态

主动发起关闭连接的一方需要TIME_WAIT状态
原因：

防止历史连接中的数据，被后面相同的四元组的链接错误的接收。
网络可能出现拥塞或者延迟，导致滞留的数据包被传递给新连接，导致数据干扰
保证最后的ACK能让被动关闭方接收，从而帮助正常关闭

TIME_WAIT的危害

内存资源占用
对端口资源的占用，

为什么是2MSL

MSL：Maximum Segment Lifetime 报文最大生存时间
2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。

等待MSL两倍：发送方数据包被接收处理后又向对方发送响应，一来一回需要两倍
确保四次挥手主动关闭方最后的ACK能到达对端

重传机制

实现可靠传输的方式：序列号和确认应答

超时重传：计时器范围内没有收到对方的确认ACK，就会重发，每次重传时间都设为先前的两倍
快速重传：以数据驱动重传；当收到三个相同的ACK报文。会重传丢失的报文段。
问题：重传多少报文段
SACK 选择性确认：解决重传哪些报文；需要在TCP头部加SACK，将已收到的数据信息发送给发送方
D-SACK：主要使用另外SACK告诉发送方哪些数据被重复接收
使用D-SACK的好处：
（1）可以让【发送方】知道，是发出去的包丢了，还是接收方回应的ACK包丢了；
（2）可以知道是不是【发送方】的数据包被网络演示了；
（3）可以知道网络中是不是把【发送方】的数据包给复制了。

滑动窗口

解决问题：TCP每发送一次数据都需要应答；数据往返时间越长，网络吞吐量越低
特点：即使在往返时间较长的情况下，也不会降低网络通信的效率
窗口大小：无需等待确认应答可以继续发送数据的最大值；由接收方窗口大小决定
实现：操作系统开辟的一个缓存空间，按期收到确认应答，则清楚缓存区
累计确认：ACK700表示700之前的所有数据都被接收，ACK600确认应答报文丢失
滑动窗口不是一成不变的，如果读取速度非常快的话，接收窗口会很快空缺，新的大小则是通过TCP报文的Windows字段告诉，这个传输过程存在时延

流量控制

基本原理：使用滑动窗口机制，通过调整窗口大小告诉发送方其当前处理数据的能力

拥塞控制

慢启动（Slow Start）：TCP 连接初始阶段，发送方的拥塞窗口（Congestion Window, cwnd）从一个较小的值开始，逐步增大，以免过早引发网络拥塞。每次接收到一个确认（ACK），cwnd 值就会增大，这个增长是指数级的。
拥塞避免（Congestion Avoidance）：当 cwnd 增加到一个阈值（ssthresh）时，慢启动结束，进入拥塞避免阶段。此时，cwnd 的增长从指数变为线性增长，逐步提高发送速率以检测网络是否接近拥塞。
快速重传（Fast Retransmit）：当发送方收到连续三个重复的 ACK 时，它假设有一个数据包丢失，于是立即重传丢失的数据包，而不必等待重传计时器超时。
快速恢复（Fast Recovery）：在快速重传之后，TCP 不像慢启动那样将 cwnd 重置为 1，而是将其减半，然后继续线性增长。这种机制可以更快地恢复传输速率。

IP

位于TCP/IP参考模型的第三层，网络层
网络层作用：实现主机与主机之间的通信，也就是点对点通信
网络层IP与数据链路层MAC的关系：MAC实现直连的两个设备间的通信；IP负责在没有直连的两个网络之间进行通信传输
在网络数据包传输过程中，IP地址并不会发生改变，但是源和目标MAC会一直变化

IP地址分类

A、B、C类地址

主机号全0指定某个网络
主机号为1，指定某个网络下的所有主机，用于广播
广播地址：用于在同一个链路相互连接的主机之间发送数据包，分为本地广播和直接广播
本地广播：在本网络内广播，广播地址的IP包会被路由器屏蔽
直接广播：在不同网络之间的广播

D、E类地址

特点：没有主机号，所以不可用于主机IP，
D类：常被用于多播；用于将包发送给特定组内的所有主机；因为广播无法穿透路由，若想给其他网段发送同样的包，则可以使用可以穿透路由的多播；前四位表示多播地址
E类：预留的分类，暂时未使用

分类的优缺点

优点：可以根据IP地址的前四位来判断IP地址属于哪个类别
缺点：同一网络下没有地址层次；A、B、C类不能很好的与现实网络匹配
缺点解决：CIDR无分类地址

CIDR无分类地址

定义：不再分类地址，32bit的IP地址被划分为两部分，前面是网络号，后面是主机号

子网掩码

另一种划分网络号和主机的形式，掩码就是掩盖掉主机号，剩余的就是网络号
将子网掩码和IP地址按位计算AND，就可得到网络号

为什么要分离网络号和主机号

答：因为两台计算机要通讯，首先要判断是否处于同一个广播域（网络地址），网络地址相同，则可以把数据包直接发送到目标主机

如何进行子网划分

子网掩码还有一个作用就是划分子网，将主机地址分为两块，子网网络地址和子网主机地址

路由控制

IP的网络地址用于进行路由控制，路由控制表中记录着网络地址与下一步应该发送至路由器的地址；主机和路由器上都有各自的路由器控制表
发送IP包时，如果存在多种相同网络地址的记录，选择相同位数最多的网络地址，也就是最长匹配

环回地址：127.0.0.1

IP分片与重组

每种数据链路的最大传输单位MTU是不相同的，当IP数据包大于MTU时，IP数据包就会被分片；
经过分片之后的IP数据被重组的时候，只能由目标主机进行，路由器是不会进行重组

在分片传输的过程中，一个分片丢失就会造成整个IP数据报作废，TCP引入MSS，在TCP层进行分片

IPV6

亮点

可分配地址变多
可自动配置，即使没有DHCP服务器也可以实现自动分配IP地址
包头包首部长度采用固定的值40字节，去掉包头校验和，简化了首部结构，减轻了路由器负荷
有应对伪造的IP地址的网络安全功能以及防止线路窃听的功能

地址

IPV6地址长度128位，每16位为一组

结构

通过IP地址的前几位标识IP地址的种类，只要分为以下3种类型：
单播地址：用于一对一的通信；
组播地址：用于一对多的通信；
任播地址：用于通信最近的节点，最近的节点是由路由协议决定；

与IPV4的区别

取消了首部校验和字段：在数据链路层和传输层都会校验
取消分片/重新组装相关字段：不允许在中间路由器进行分片与重组，大大提高了路由器转发的速度
取消选项字段：使IPV6首部成为固定长度的40字节

ARP与RARP协议

1. ARP协议

ARP（地址解析协议）用于通过已知的IP地址获取对应的MAC地址。主机会通过广播发送ARP请求，包含目标IP地址。同一链路上的设备接收到请求后，如果目标IP地址与自己的IP一致，则返回包含自己MAC地址的ARP响应包。操作系统通常会缓存获取的MAC地址，但缓存有一定期限。

2. RARP协议

RARP（逆地址解析协议）用于通过已知的MAC地址获取IP地址。常用于嵌入式设备接入网络时，通过RARP服务器获取IP地址。

3. DHCP动态获取IP地址

DHCP（动态主机配置协议）通过四个步骤自动获取IP地址：

DHCP发现（DHCP Discover）： 客户端通过广播发送一个DHCP发现消息，向网络中的DHCP服务器请求IP地址。
DHCP提供（DHCP Offer）： 网络中的DHCP服务器收到发现消息后，向客户端发送一个DHCP提供消息，其中包含一个可用的IP地址以及相关的配置信息（如子网掩码、网关地址、DNS服务器等）。
DHCP请求（DHCP Request）： 客户端收到提供消息后，向DHCP服务器发送一个请求消息，表明愿意接受所提供的IP地址和配置信息。
DHCP确认（DHCP Acknowledgment）： DHCP服务器收到请求消息后，向客户端发送确认消息，并正式分配IP地址给客户端，客户端即可使用该IP地址进行网络通信。
DHCP交互中使用的都是UDP广播通信

DHCP中继代理

定义：对于不同网段的IP地址分配可以由一个DHCP服务器进行统一管理
DHCP 客户端会向 DHCP 中继代理发送 DHCP 请求包，而 DHCP 中继代理在收到这个广播包以后，再以单播的形式发给 DHCP 服务器。

NAT( Network Address Translation, 网络地址转换)

定义：同个公司、家庭、教室内的主机对外部通信时，把私有IP地址转换成公有IP地址
作用：缓解了IPV4地址耗尽的问题

普通的 NAT 转换没什么意义。由于绝大多数的网络应用都是使用传输层协议 TCP 或 UDP 来传输数据的。因此，可以把IP 地址 + 端口号一起进行转换。这样，就用一个全球 IP地址就可以了，这种转换技术就叫网络地址与端口转换 NAPT。

缺点

NAT/NAPT依赖于自己的转换表，因此：

外部无法主动与NAT内部服务器建立连接，因为NAPT转换表没有转换记录
转换表的生成与转换操作都会产生性能开销
通信过程中，如果NAT路由器重启，所有TCP连接都将被重置

优化方案

改用IPV6：IPV6可用范围比较大
NAT穿透技术：让网络应用程序主动发现自己位于NAT设备之后，并且主动获取NAT设备的公有IP，并为自己建立端口映射条目
ICMP互联网控制报文协议：

ICMP

功能

确认 IP 包是否成功送达目标地址、报告发送过程中 IP 包被废弃的原因和改善网络设置等。在 IP 通信中如果某个 IP 包因为某种原因未能达到目标地址，那么这个具体的原因将由 ICMP 负责通知。
ICMP的消息会使用IP进行发送

类别

查询报文类型：用于诊断的查询信息
差错报文类型：通知出错原因的错误类型

IGMP因特网组管理协议

组播地址说明只有一组的主机能收到数据包，不在一组的主机不能收到数据包，IGMP用于管理是否在一组

IGMP 报文向路由器申请加入和退出组播组，默认情况下路由器是不会转发组播包到连接中的主机，除非主机通过 IGMP 加入到组播组，主机申请加入到组播组时，路由器就会记录 IGMP 路由器表，路由器后续就会转发组播包到对应的主机了。
IGMP 报文采用 IP 封装，IP 头部的协议号为 2，而且 TTL 字段值通常为 1，因为 IGMP 是工作在主机与连接的路由器之间。

工作机制

常规查询与响应

离开组播组

网播中仍有该组播组
网段中没有该组播组

RenXin's Website

计算机网络八股总结