计算机网络（下）

最新推荐文章于 2023-03-22 15:55:55 发布

风吟Pro

最新推荐文章于 2023-03-22 15:55:55 发布

阅读量1.2k

点赞数

分类专栏：计算机基础计算机网络文章标签：计算机网络网络网络协议

本文链接：https://blog.csdn.net/weixin_46906696/article/details/127834003

版权

计算机基础同时被 2 个专栏收录

5 篇文章 1 订阅

订阅专栏

计算机网络

4 篇文章 1 订阅

订阅专栏

运输层

运输层概述

概念

进程之间的通信
在这里插入图片描述

从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。
当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时，只有位于网络边缘部分的主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到三层（到网络层）的功能。

在这里插入图片描述

进程之间通信流程
以体系结构的角度来看应用进程，可以理解为：运输层直接为应用进程间的逻辑通信提供服务

“逻辑通信”是指运输层之间的通信好像是沿水平方向传送数据，但事实上，这两条数据并没有一条水平方向的物理连接，要传送的数据是沿着图中上下多次的虚线方向传送的。也就是说，运输层只需要关心我这层需要做什么，不需要去关心下面三层经历了什么。

进程Ap1与Ap4之间进行基于网络的通信，进程Ap2与Ap3之间进行基于网络的通信

在运输层使用不同的端口，来对应不同的应用进程

然后通过网络层及其下层来传输应用层报文

接收方的运输层通过不同的端口，将收到的应用层报文，交付给应用层中相应的应用进程

这里端口并不是指看得见、摸得着的物理端口，而是指用来区分不同应用进程的标识符

在这里插入图片描述

总结

端口号、复用、分用

为什么用端口号

主要就是区分应用程序的

发送方的复用和接收方的分用

不同的应用进程按需求以不同的协议复用方式对数据进行封装，在复用（封装）时如果是UDP的话协议字段就是17，TCP的话协议字段就是6
接收方接到了之后，根据协议字段的代号进行IP分用，如果协议字段=17，就分用上报给UDP。如果协议字段=6，就分用上报给TCP。分用完毕根据不同的端口号分发给需要的应用进程。

多个进程（这里一个端口表示一个进程） 利用一个运输层协议（或者称为运输层接口）发送数据称为复用

多个进程（这里一个端口表示一个进程） 利用一个运输层协议（或者称为运输层接口）接收时叫做分用。

TCP/IP体系的应用层常用协议所使用的运输层熟知端口号

运输层传输流程

举例说明运输层端口号的作用：

在这里插入图片描述

在浏览器输入域名，回车浏览

然后用户PC中的DNS客户端进程会发送一个DNS查询请求报文

DNS查询请求报文需要使用运输层的UDP协议

首部中的源端口字段的值，在短暂端口号49151~65535中挑选一个未被占用的，用来表示DNS客户端进程

首部中的目的端口字段的值：53，是DNS服务器端进程所使用的熟知端口号

之后，将UDP用户数据报封装在IP数据报中，通过以太网发送给DNS服务器

在这里插入图片描述

DNS服务器收到该IP数据报后，从中解封出UDP用户数据报

UDP首部中的目的端口号为53，这表明应将该UDP用户数据报的数据载荷部分，也就是DNS查询请求报文，交付给本服务器中的DNS服务器端进程

DNS服务器端进程解析DNS查询请求报文的内容，然后按其要求查找对应的IP地址

之后，会给用户PC发送DNS响应报文，DNS响应报文需要使用运输层的UDP协议封装成UDP用户数据报

其首部中的源端口字段的值设置为熟知端口号53，表明这是DNS服务器端进程所发送的UDP用户数据报，目的端口的值设置为49152，这是之前用户PC中发送DNS查询请求报文的DNS客户端进程所使用的短暂端口号

将UDP用户数据报封装在IP数据报中，通过以太网发送给用户PC

用户PC收到该数据报后，从中解封出UDP用户数据报

UDP首部中的目的端口号为49152，这表明应将该UDP用户数据报的数据载荷部分，也就是DNS响应报文，交付给用户PC中的DNS客户端进程

DNS客户端进程解析DNS响应报文的内容，就可知道自己之前所请求的Web服务器的域名对应的IP地址

现在用户PC中的HTTP客户端进程可以向Web服务器发送HTTP请求报文（和DNS发送和接收流程差不多）

发送给目的服务器

收到报文后，Web服务器解封TCP数据报，看到端口是80，会将数据报文的部分，交付给HTTP服务器端进程，解析报文内容后，按其要求处理，处理完毕后回传

回传结果

总结：
在这里插入图片描述

TCP和UDP对比

概念

UDP 和 TCP 是TCP/IP体系结构运输层中的两个重要协议
当运输层采用面向连接的 TCP 协议时，尽管下面的网络是不可靠的（只提供尽最大努力服务），但这种逻辑通信信道就相当于一条全双工的可靠信道。
当运输层采用无连接的 UDP 协议时，这种逻辑通信信道是一条不可靠信道。

可靠信道与不可靠信道

两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元 TPDU (Transport Protocol Data Unit)。
TCP 传送的数据单位协议是 TCP 报文段(segment)。
UDP 传送的数据单位协议是 UDP 报文或用户数据报。

在这里插入图片描述

UDP的通信是无连接的，不需要套接字（Socket）

TCP是面向连接（逻辑连接，非物理连接）的，TCP之间的通信必须要在两个套接字（Socket）之间建立连接

用户数据报协议UDP（User Datagram Protocol）

可以发送广播

可以向某个多播组发送多播

在这里插入图片描述

还可以发送单播
在这里插入图片描述

UDP 支持单播、多播以及广播

换句话说，UDP支持一对一，一对多，以及一对全的通信

UDP运输过程

使用方为其加入一个UDP的首部，使之成为UDP用户数据报，接收方收到后，去掉UDP首部，将数据报文上交给应用进程。也就是给数据报套了个壳，不会处理内部数据

UDP对应用进程交下来的报文既不合并也不拆分，而是保留这些报文的边界

换句话说，UDP是面向应用报文的

UDP向上层提供无连接不可靠传输服务

UDP结构

就给数据部分套了个壳，还是比较简单的。

传输控制协议TCP（Transmission Control Protocol）

使用TCP协议的通信双方，在进行数据传输之前，必须使用“三报文握手”建立TCP连接

在这里插入图片描述

TCP连接建立成功后，通信双方之间就好像有一条可靠的通信信道，通信双方使用这条基于TCP连接的可靠信道进行通信
在这里插入图片描述

很显然，TCP仅支持单播，也就是一对一的通信

TCP运输过程

TCP把应用的数据块仅仅看成一串字节流，TCP将其编号，存储进发送缓存中。当要发送时，根据发送策略，从发送缓存中提取一定数量的字节构建TCP报文段，然后发送。接收方从报文中取出数据载荷部分并且存储在缓存中，不定时的上交给应用进程。因此不保证发送方发来的数据和接收方接到的数据大小是一致的。所以是一截一截的字节流进行交付。

详细说明接收过程：

发送方

TCP会把应用进程交付下来的数据块看作是一连串无结构的字节流，TCP并不知道这些待传送的字节流的含义

并将他们编号，并存储在自己发送缓存中

TCP会根据发送策略，提取一定量的字节构建TCP报文并发送

接收方

一方面从所接受到的TCP报文段中，取出数据载荷部分并存储在接收缓存中；一方面将接收缓存中的一些字节交付给应用进程

TCP不保证接收方应用进程所收到的数据块与发送方发送的数据块，具有对应大小的关系（例如，发送方应用进程交给发送方的TCP共10个数据块，但接收方的TCP可能只用了4个数据块，就把收到的字节流交付给了上层的应用进程，但接收方收到的字节流必须和发送方应用进程发出的字节流完全一样）

接收方的应用进程必须有能力识别收到的字节流，把它还原成有意义的应用层数据

TCP是面向字节流的，这正是TCP实现可靠传输、流量控制、以及拥塞控制的基础

本图只画了一个方向的数据流，在实际网络中，基于TCP连接的两端，可以同时进行TCP报文段的发送和接收

TCP向上层提供面向连接的可靠传输服务

TCP结构

比UDP的结构要复杂的多

总结

TCP的流量控制

概念

怕发的太快，对面留不住，让接收方来的及接收
主要是用滑动窗口来实现流量控制，类似于回退N帧
如果在发送过程中有发送失败的情况，那么依靠计时器就可以实现重传

举例

具体流程的视频
 看看这个文章，讲的很详细

上图主机A现在可将发送缓存中序号1~200的字节数据全部删除，因为已经收到了主机B对它们的累计确认
这期间如果有数据没正确发送，或者没有收到正确接收的确认，等待时间一到就会触发重传计时器，进行重传操作。

上图主机A现在可将发送缓存中序号201~500的字节数据全部删除，因为已经收到了主机B对它们的累计确认

上图主机A现在可将发送缓存中序号501~600的字节数据全部删除，因为已经收到了主机B对它们的累计确认

调整窗口大小的通知丢失了怎么办？

发送方有持续计时器，当知道接收窗口为0的时候，就会每隔一段时间问接收方是否可以接收了，这个询问的信息叫做零窗口探测报文，如果接收方还不能接收，就给发送方回复0大小的窗口信息，如果能接收了，就发送接收窗口调整的信息。

上图如果零窗口探测报文在发送过程中如果丢失，还是能打破死锁局面

因为零窗口探测报文段也有重传计时器，重传计时器超时后，零窗口探测报文段会被重传

总结

TCP拥塞控制

概念

网络拥塞往往是由许多因素引起的。例如：

点缓存的容量太小；
链路的容量不足；
处理机处理的速率太慢；
拥塞本身会进一步加剧拥塞；

拥塞控制的一般原理

拥塞控制的前提：网络能够承受现有的网络负荷。
实践证明，拥塞控制是很难设计的，因为它是一个动态问题。
分组的丢失是网络发生拥塞的征兆而不是原因。
在许多情况下，甚至正是拥塞控制本身成为引起网络性能恶化、甚至发生死锁的原因。

开环控制和闭环控制

监测网络的拥塞

主要指标有：

由于缺少缓存空间而被丢弃的分组的百分数；
平均队列长度；
超时重传的分组数；
平均分组时延；
分组时延的标准差，等等。

上述这些指标的上升都标志着拥塞的增长。

拥塞控制的算法

拥塞控制算法一共是这四种
大类是分为两类

发送方维护一个拥塞窗口cwnd

真正的发送窗口值 = Min (接收方窗口值，拥塞窗口值)

下图的实例横纵坐标的意思

传输轮次：

发送方给接收方发送数据报文段后，接收方给发送方发发回相应的确认报文段
一个传输轮次所经历的时间其实就是往返时间，往返时间并非是恒定的数值
使用传输轮次是为了强调把拥塞窗口所允许发送的报文段都连续发送出去，并受到了对已发送的最后一个报文段的确认

拥塞窗口：

它会随网络拥塞程度，以及所使用的拥塞控制算法动态变化

慢开始和拥塞避免

慢开始（slow-start）

目的：用来确定网络的负载能力或拥塞程度。
算法的思路：由小到大逐渐增大拥塞窗口数值。
两个变量：
- 拥塞窗口（cwnd）：初始拥塞窗口值：2 种设置方法。窗口值逐渐增大。
  - 1 至 2 个最大报文段（旧标准）
  - 2 至 4 个最大报文段（RFC 5681）
- 慢开始门限（ssthresh）：防止拥塞窗口增长过大引起网络拥塞，也就是上限。

如图所示拥塞窗口随着传播轮次（一个数据发送往返）的增长，拥塞窗口到达慢开始门限的状态。到达慢开始门限后，每次的增长就是由下面的拥塞避免决定了。

拥塞窗口从1开始，完成一次完整的发送接收，就进行一次指数级扩张。这个拥塞窗口的增长一直增长到慢开始门限（ssthresh）所规定的大小，不会一直无脑扩张。

图中swnd是发送窗口

每经过一个传输轮次，拥塞窗口就加倍

窗口大小按指数增加，2的n-1次方

拥塞避免（congestion avoidance）

思路：让拥塞窗口 cwnd 缓慢地增大，避免出现拥塞。
每经过一个传输轮次，拥塞窗口 cwnd = cwnd + 1。
使拥塞窗口 cwnd 按线性规律缓慢增长。
在拥塞避免阶段，具有 “加法增大” (Additive Increase) 的特点。

当拥塞窗口增长大小到慢开始门限（ssthresh）的时候，每个传播轮次就是+1的上升

增长到24之后，如果在发送过程中出现部分报文段丢失，这必然会造成发送方对这些丢失报文段的超时重传，认为网络中出现了拥塞情况，就要开始减少发送量，直接把拥塞窗口降为1。

注意，有的时候报文丢失并非是拥塞导致，这就很容易导致“误伤”。所以后面会有算法对这个问题进行改进。

这个时候又回到了慢开始，从拥塞窗口=1开始指数级增长，直至增长到慢开始门限（ssthresh）开始+1级别上升。

两个算法完整示意图

慢开始+拥塞避免配合

“慢开始”是指一开始向网络注入的报文段少，并不是指拥塞窗口cwnd增长速度慢;
“拥塞避免”并非指完全能够避免拥塞，而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长使网络比较不容易出现拥塞;

快重传和快恢复

快重传和快恢复的出现是为了对慢开始和拥塞避免的算法进行优化处理。
之前我们说的有的时候报文丢失并非是拥塞导致，这就很容易导致“误伤”，造成的拥塞避免会使性能大幅下降。
因为拥塞避免是计时器时间到了才会触发，所以我们在计时器触发之前就重传确认，来避免触发拥塞避免。

快重传（fast retrasmit）

发现丢失了之后，接收方就会快速发送三个确认报文，来刺激接收方尽快重传。提早于计时器，一定程度上减少了拥塞避免的触发，所以提升了性能。

快恢复（fast recovery）

三个连续的确认到达发送方，就代表了当前网络还不算拥塞，将拥塞窗口的初始值拉高，这样恢复时就可以更快了。快恢复来保证性能。

改进后的整体算法的示意图

超时重传时间的选择

概述

RTO：超时重传时间
RTT+数字：从发送方发出到接受方回应的往返时间，比如RTT0是第一个往返时间，RTT1是第二个往返时间

如果超时重传时间RTO的值设置得比往返时间RTT0的值小很多，这会引起报文段不必要的重传，使网络负荷增大。明明人家正常发送，提前重传肯定是浪费的

如果超时重传时间RTO的值设置得远大于RTT0的值，这会使重传时间推迟的太长，使网络的空闲时间增大，降低传输效率。

再假设RTO时间略大于RTT时间呢？好像对于固定的情况可以，但是又不太行，因为网络是不断在变化的，固定的RTO时间无法应对复杂的网络，RTT的时间会随着网络的占用状态而不断变化，所以固定的RTO时间肯定是不行的

这里给出公式，也就是每次的RTT时间进行加权平均，对整体数值进行平滑处理

如何计算重传时间RTO

RFC6298建议使用下式计算超时重传时间RTO

往返时间RTT的测量比较复杂

Karn算法优化

TCP超时重传的计算

举例

总结

TCP可靠传输的实现

本集具体讲解

滑动窗口的移动情况

用标记位来描述发送窗口的状态

总结下来，接收方如果不发送确认位，那么发送方的滑动窗口就不可能往下走。同理，接收方接收窗口的后沿没有收到该收到的数据，也不会往下推进。
在这里插入图片描述

在这里插入图片描述

总结

TCP的运输连接管理

概念

TCP运输的连接主要由三个阶段

TCP的连接建立

TCP 建立连接的过程叫做握手。
握手需要在客户和服务器之间交换三个 TCP 报文段。称之为三报文握手。
采用三报文握手主要是为了防止已失效的连接请求报文段突然又传送到了，因而产生错误。

TCP的连接建立要解决以下三个问题

TCP使用“三报文握手”建立连接过程

TCP 连接的建立采用客户服务器方式。
主动发起连接建立的应用进程叫做TCP客户 (client)。
被动等待连接建立的应用进程叫做TCP服务器 (server)。

“握手”这个过程需要在TCP客户端和服务器之间交换三个TCP报文段，才能完成连接。连接完成后才能交换数据。

连接过程

最初两端的TCP进程都处于关闭状态

一开始，TCP服务器进程首先创建传输控制块，用来存储TCP连接中的一些重要信息。例如TCP连接表、指向发送和接收缓存的指针、指向重传队列的指针，当前的发送和接收序号等

之后，就准备接受TCP客户端进程的连接请求

此时，TCP服务器进程就进入监听状态，等待TCP客户端进程的连接请求

TCP服务器进程是被动等待来自TCP客户端进程的连接请求，因此成为被动打开连接

TCP客户进程也是首先创建传输控制块

由于TCP连接建立是由TCP客户端主动发起的，因此称为主动打开连接

随后，在打算建立TCP连接时，向TCP服务器进程发送TCP连接请求报文段，并进入同步已发送状态

TCP连接请求报文段首部中

同步位SYN被设置为1，表明这是一个TCP连接请求报文段
序号字段seq被设置了一个初始值x，作为TCP客户端进程所选择的初始序号

请注意：TCP规定SYN被设置为1的报文段不能携带数据，但要消耗掉一个序号

TCP服务器进程收到TCP连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态

TCP连接请求确认报文段首部中

同步位SYN和确认为ACK都设置为1，表明这是一个TCP连接请求确认报文段
序号字段seq被设置了一个初始值y，作为TCP服务器进程所选择的初始序号，
确认号字段ack的值被设置成了x+1，这是对TCP客户进程所选择的初始序号（seq）的确认

请注意：这个报文段也不能携带数据，因为它是SYN被设置为1的报文段，但同样要消耗掉一个序号

TCP客户进程收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP确认报文段，并进入连接已连接状态

普通的TCP确认报文段首部中

确认位ACK被设置为1，表明这是一个普通的TCP确认报文段
序号字段seq被设置为x+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x，所以TCP客户进程发送的第二个报文段的序号为x+1
确认号字段ack被设置为y+1，这是对TCP服务器进程所选择的初始序号的确认

请注意：TCP规定普通的TCP确认报文段可以携带数据，但如果不携带数据，则不消耗序号

TCP服务器进程收到该确认报文段后也进入连接已建立状态

现在，TCP双方都进入了连接已建立状态，它们可以基于已建立好的TCP连接，进行可靠的数据传输

为什么一定是三次握手

为什么TCP客户进程最后还要发送一个普通的TCP确认报文段？能否使用“两报文握手”建立连接？

下图实例是“两报文握手”
在这里插入图片描述

为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误”
这种情况是：一端(client)A发出去的第一个连接请求报文并没有丢失，而是因为某些未知的原因在某个网络节点上发生滞留（会迟到很久），导致延迟到连接释放以后的某个时间才到达另一端(server)B。本来这是一个早已失效的报文段，但是B收到此失效的报文之后，会误认为是A再次发出的一个新的连接请求，于是B端就向A又发出确认报文，表示同意建立连接。如果不采用“三次握手”，那么只要B端发出确认报文就会认为新的连接已经建立了，但是A端并没有发出建立连接的请求，因此不会去向B端发送数据，B端没有收到数据就会一直等待，这样B端就会白白浪费掉很多资源。

所以三次握手并不多余，这是为了防止已失效的连接请求报文段突然又传送到了TCP服务器，因而导致错误

总结

在这里插入图片描述

TCP的连接释放

TCP 连接释放过程比较复杂。
数据传输结束后，通信的双方都可释放连接。
TCP 连接释放过程是四报文握手。

TCP通过“四报文挥手”来释放连接

TCP 连接的建立采用客户服务器方式。
主动发起连接建立的应用进程叫做TCP客户 (client)。
被动等待连接建立的应用进程叫做TCP服务器 (server)。
任何一方都可以在数据传送结束后发出连接释放的通知

过程

现在TCP客户进程和TCP服务器进程都处于连接已建立状态

TCP客户进程的应用进程通知其主动关闭TCP连接

TCP客户进程会发送TCP连接释放报文段，并进入终止等待1状态

TCP连接释放报文段首部中

终止位FIN和确认为ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认
序号seq字段的值设置为u，它等于TCP客户进程之前已传送过的数据的最后一个字节的序号加1
确认号ack字段的值设置为v，它等于TCP客户进程之前已收到的、数据的最后一个字节的序号加1

请注意：TCP规定终止位FIN等于1的报文段即使不携带数据，也要消耗掉一个序号

TCP服务器进程收到TCP连接释放报文段后，会发送一个普通的TCP确认报文段并进入关闭等待状态

普通的TCP确认报文段首部中

确认位ACK的值被设置为1，表明这是一个普通的TCP确认报文段
序号seq字段的值设置为v，它等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1，这也与之前收到的TCP连接释放报文段中的确认号匹配
确认号ack字段的值设置为u+1，这是对TCP连接释放报文段的确认

在这里插入图片描述

此时进入终止等待1状态

TCP服务器进程应该通知高层应用进程，TCP客户进程要断开与自己的TCP连接

此时，从TCP客户进程（发送方）到TCP服务器进程（接收方）这个方向的连接就释放了。也就是发送方不再发送任何数据包了（确认数据除外）

这时的TCP连接属于半关闭状态，也就是TCP客户进程已经没有数据要发送了

但如果TCP服务器进程（接收方）还有数据要发送，TCP客户（发送方）进程仍要接收，因为TCP的连接是全双工的，也就是说从TCP服务器进程到TCP客户进程这个方向的连接并未关闭

TCP客户进程收到TCP确认报文段后就进入终止等待2状态，等待TCP服务器进程发出的TCP连接释放报文段

若使用TCP服务器进程的应用进程已经没有数据要发送了，应用进程就通知其TCP服务器进程释放连接

由于TCP连接释放是由TCP客户进程主动发起的，因此TCP服务器进程对TCP连接的释放称为被动关闭连接

TCP服务器进程发送TCP连接释放报文段并进入最后确认状态

该报文段首部中

终止位FIN和确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认
序号seq字段的值为w，这是因为在半关闭状态下，TCP服务器进程可能又发送
确认号ack字段的值为u+1，这是对之前收到的TCP连接释放报文段的重复确认

TCP客户进程收到TCP连接释放报文段后，必须针对该报文段发送普通的TCP确认报文段，之后进入时间等待状态

该报文段首部中

确认为ACK的值被设置为1，表明这是一个普通的TCP确认报文段
序号seq字段的值设置为u+1，这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据，但要消耗掉一个序号
确认号ack字段的值设置为w+1，这是对所收到的TCP连接释放报文段的确认

TCP服务器进程收到该报文段后就进入关闭状态，而TCP客户进程还要进过2MSL后才能进入关闭状态

Question：
TCP客户进程在发送完最后一个确认报文后，为什么不直接进入关闭状态？而是要进入时间等待状态？

因为要保证最后一个断开连接的确认报文的到达，避免最后一个确认报文的丢失后接收方重传断开的请求无人理睬。如果接收方一直没收到关闭报文，就会一直重传确认报文，导致接收方无法关闭

因为时间等待状态以及处于该状态2MSL时长，可以确保TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态

另外，TCP客户进程在发送完最后一个TCP确认报文段后，在经过2MSL时长，就可以使本次连接持续时间内所产生的所有报文段都从网络中消失，这样就可以使下一个新的TCP连接中，不会出现旧连接中的报文段

TCP保活计时器的作用

TCP双方已经建立了连接，后来，TCP客户进程所在的主机突然出现了故障

TCP服务器进程以后就不能再收到TCP客户进程发来的数据

因此，应当有措施使TCP服务器进程不要再白白等待下去

TCP报文段的首部格式

各字段的作用

源端口和目的端口

序号、确认号和确认标志位

数据偏移、保留、窗口和校验和

同步标志位、终止标志位、复位标志位、推送标志位、紧急标志位和紧急指针

选项和填充

应用层

应用层概述

我们在浏览器的地址中输入某个网站的域名后，就可以访问该网站的内容，这个就是万维网WWW应用，其相关的应用层协议为超文本传送协议HTTP

用户在浏览器地址栏中输入的是“见名知意”的域名，而TCP/IP的网际层使用IP地址来表示目的主机，从域名到IP地址的装转换，由属于应用层范畴的域名系统DNS，在后台帮用户完成

常见的应用

总结

客户/服务器方式（C/S方式）和对等方式（P2P方式）

概念

客户/服务器方式（C/S方式）

对等方式（P2P方式）

总结

在这里插入图片描述

动态主机配置协议DHCP

概念

互联网广泛使用的动态主机配置协议 DHCP (Dynamic Host Configuration Protocol) 提供了即插即用连网 (plug-and-play networking) 的机制。
这种机制允许一台计算机加入新的网络和获取 IP 地址，而不用手工配置。

DHCP的作用

在之前，如果要正常访问Web服务器，需要该主机手动配置网络的相关配置信息

如果主机数很多，就工作量大，容易出错

如果我们给网络中添加一台DHCP服务器
这个服务器的作用就是我需要配置IP、子网掩码、网关、DNS服务器的时候，就去向DHCP服务器发起请求，请求出来上面的相应信息，就不需要我手动配置了，通过DHCP自动获取
主机在开机的时候，自动运行DHCP程序，向DHCP服务器请求配置，不再需要繁杂的手动配置。

DHCP的工作过程

DHCP 使用客户 - 服务器方式

需要 IP 地址的主机在启动时就向 DHCP 服务器广播发送发现报文
（DHCP DISCOVER），这时该主机就成为 DHCP 客户。
本地网络上所有主机都能收到此广播报文，但只有 DHCP 服务器才回答此广播报文。
DHCP 服务器先在其数据库中查找该计算机的配置信息。若找到，则返回找到的信息。若找不到，则从服务器的 IP 地址池 (address pool) 中取一个地址分配给该计算机。DHCP服务器的回答报文叫做提供报文（DHCP OFFER）。

DHCP 工作方式

DHCP 使用客户-服务器方式，采用请求/应答方式工作。
DHCP 基于 UDP 工作（DHCP报文在运输层会被封装成为UDP用户数据报），DHCP 服务器运行在 67 号端口， DHCP客户运行在 68 号端口。

DHCP交互过程

DHCP客户端将广播发送DHCP发现报文（DHCP DISCOVER）

事务ID
DHCP客户端的MAC地址

封装该报文的IP数据报的源IP地址为0.0.0.0，这是因为主机目前还未分配到IP地址，因此使用该地址代替

目的IP地址为广播地址255.255.255.255，之所以广播发送，是因为主机现在并不知道网络中有哪几个DHCP服务器。它们的IP地址各是什么

DHCP服务器收到DHCP发现报文后，根据其中封装的DHCP客户端的MAC地址来查找自己的数据库，如果查到匹配信息，则使用这些配置信息来构建并发送DHCP提供报文，如果没有则采用默认配置信息来构建报文并发送

DHCP服务端将广播发送DHCP提供报文（DHCP OFFER）

事务ID：DHCP客户端会与之前DHCP发现报文的事务ID做对比，来判断该DHCP提供报文是否是自己的
配置信息：
IP地址：DHCP服务器从自己的IP地址池中挑选待租用给主机的IP地址（使用ARP来确保所选IP地址未被网络中其他主机占用）
子网掩码
地址租期
默认网关
DNS服务器

源IP地址：发送DHCP提供报文的DHCP服务器的IP

目的地址：因为目的主机还没分配到IP，所以使用广播地址

在本例中，DHCP客户会收到两个DHCP服务器发来的DHCP提供报文，DHCP客户从中选择一个，一般选择先到达的DHCP报文，并向所选择的DHCP服务器发送DHCP请求报文

DHCP客户端将广播发送DHCP请求报文（DHCP REQUEST）

事务ID
DHCP客户端的MAC地址
接收的租约中的IP地址
提供此租约的DHCP服务器端的IP地址

源地址：0.0.0.0，因为此时DHCP客户才从多个DHCP服务器中挑选一个作为自己的DHCP服务器。它首先要征得该服务器的同意，之后才能正式使用向该DHCP服务器租用的IP地址

目的地址：广播地址，这样可以一次性向所有DHCP服务器发送DHCP请求报文，来告知它们是否请求它们作为自己的DHCP服务器

在本例中，假设DHCP客户端选择DHCP服务器1作为自己的DHCP服务器，DHCP服务器1接受该请求，于是DHCP服务器1给DHCP客户端发送DHCP确认报文