CCNA1

最新推荐文章于 2023-12-15 16:34:56 发布

周雄雄

最新推荐文章于 2023-12-15 16:34:56 发布

阅读量427

点赞数

分类专栏： CCNA

本文链接：https://blog.csdn.net/weixin_43801718/article/details/104002593

版权

CCNA 专栏收录该内容

9 篇文章 1 订阅

订阅专栏

OSI七层参考模型 - -国际标准化组织

应用层: 通过人机交互来实现各种各样的服务
表示层: 编码、解码加密解密
会话层: 发现建立维持终止会话
传输层：
1. 通过端口号来区分不同的服务: 0-65535 静态端口号 1-1023 著名端口号 1024-65535 动态端口号
2. 提供可靠的传输: 确认重传排序流控
. TCP 传输控制协议面向连接的可靠传输协议
. UDP 用户数据报文协议非面向连接的不可靠传输协议
3. 数据分段: 最大段长度 MSS 1480B 最大传输单元 MTU 1500B
网络层: 通过ip来进行逻辑寻址路由器所在层
数据链路层:
LLC 逻辑链路控制子层为上层服务提供FCS校验
MAC 媒介访问控制子层通过MAC地址来进行物理寻址
物理层: 定义电气电压，接口规范光学特性

数据的封装与解封装

PDU(协议数据单元)

数据报文
四层数据段
三层数据包
二层数据帧
一层比特流

TCP协议 - -确认重传排序流控

TCP报头
在这里插入图片描述

FTP(数据传送端口)	TCP	20
FTP(传送控制端口)	TCP	21
telnet	TCP	23(明文)
SSH(安全外壳)	TCP	22(密文)
HTTP	TCP	80或者8080
HTTPS	TCP	443
SMTP(发邮件)	TCP	25
POP3(收邮件)	TCP	110
TFTP	UDP	69
DNS	TCP/UDP	53
VNC	TCP	5900

TCP三次握手
在这里插入图片描述

过程详解
第一次握手:建立连接时,客户端发送syn包(seq=100)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号;
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=100+1),同时自己也发送一个SYN包(seq=300),即SYN+ACK包,此时服务器进入SYN_RECV状态;
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=300+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。

TCP第三次握手的必要性:
答: 防止已失效的请求报文段突然又传送到了服务端而造成连接的误判。假如客户端发出连接请求A，由于网络原因，服务端并没有收到A，于是客户端又发送了连接请求B，并建立了连接，完成通信，断开连接。这时候，服务端突然又收到了A，于是看作是一次新的连接请求，进行第二次握手，由于不存在第三次握手，所以这时已经建立了TCP连接。但实际上客户端并没有发起连接，所以不会传递数据，那么这条连接就会变成一条死连接。

TCP三次握手的意义:
答:
(1) 同步连接双方的序列号和确认号并交换 TCP 窗口大小信息。
(2) TCP通过三次握手建立可靠的（确保收到）的全双工通信。

TCP四次断开
在这里插入图片描述

过程解释
假设 A 为主动断开方，B 为被动断开方
第一次握手，A 向 B 发送消息，表明数据发送完成需要断开连接
第二次握手，B 向 A 发送消息，让 A 先等等，等 B 把数据传完
第三次握手，B 向 A 发送消息，数据已传完，可以断开了
第四次握手，A 向 B 发送消息，稍后会断开连接

TCP四次断开为什么比三次握手多一次？
答:为保证单向通信的可行性，所以多一次握手

UDP协议

UDP报头
在这里插入图片描述

IP协议

IP报头

在这里插入图片描述
生存时间(TTL): 0-255 默认每经过一台路由器减1
协议号: 标识上层协议

上层协议	协议号
TCP	6
UDP	17
OSPF	89
EIGRP	88

TCP/IP协议栈

在这里插入图片描述

相同点：
2者都是模型化层次化
下层对上层提供服务支持
每层协议彼此相互独立
不同点：
OSI先有模型才有协议 TCP/IP先有协议才有模型
TCP/IP协议栈只适用于TCP/IP网络
层数量不同

扩充

TCP滑动窗口

TCP协议里窗口机制有2种：

固定的窗口
滑动的窗口

这个窗口大小就是我们一次传输几个数据。对所有数据帧按顺序赋予编号，发送方在发送过程中始终保持着一个发送窗口，只有落在发送窗口内的帧才允许被发送；同时接收方也维持着一个接收窗口，只有落在接收窗口内的帧才允许接收。这样通过调整发送方窗口和接收方窗口的大小可以实现流量控制。

TCP滑动窗口技术通过动态改变窗口大小来调节两台主机间数据传输。每个TCP/IP主机支持全双工数据传输，因此TCP有两个滑动窗口：一个用于接收数据，另一个用于发送数据。TCP使用肯定确认技术，其确认号指的是下一个所期待的字节。假定发送方设备以每一次三个数据包的方式发送数据，也就是说，窗口大小为3。发送方发送序列号为1、2、3的三个数据包，接收方设备成功接收数据包，用序列号4确认。发送方设备收到确认，继续以窗口大小3发送数据。当接收方设备要求降低或者增大网络流量时，可以对窗口大小进行减小或者增加，本例降低窗口大小为2，每一次发送两个数据包。当接收方设备要求窗口大小为0，表明接收方已经接收了全部数据，或者接收方应用程序没有时间读取数据，要求暂停发送。发送方接收到携带窗口号为0的确认，停止这一方向的数据传输。

通过下面的图来看一下TCP固定窗口有什么问题
在这里插入图片描述
这里我们可以看到假设窗口的大小是1，也是就每次只能发送一个数据只有接受方对这个数据进行确认了以后才能发送第2个数据。我们可以看到发送方每发送一个数据接受方就要给发送方一个ACK对这个数据进行确认。只有接受到了这个确认数据以后发送方才能传输下个数据。这样如果说窗口过小，那么当传输比较大的数据的时候需要不停的对数据进行确认，这个时候就会造成很大的延迟。如果说窗口的大小定义的过大。我们假设发送方一次发送100个数据。但是接收方只能处理50个数据。这样每次都会只对这50个数据进行确认。发送方下一次还是发送100个数据，但是接受方还是只能处理50个数据。这样就避免了不必要的数据来拥塞我们的链路。所以我们就引入了滑动窗口机制，窗口的大小并不是固定的而是根据我们之间的链路的带宽的大小进行动态变化。

通过一下几张图来看一下滑动窗口的工作
在这里插入图片描述
首先是第一次发送数据这个时候的窗口大小是根据链路带宽的大小来决定的。我们假设这个时候窗口的大小是3。这个时候接受方收到数据以后会对数据进行确认告诉发送方我下次希望手到的是数据是多少。这里我们看到接收方发送的ACK=3(这是发送方发送序列2的回答确认，下一次接收方期望接收到的是3序列信号)。这个时候发送方收到这个数据以后就知道我第一次发送的3个数据对方只收到了2个。就知道第3个数据对方没有收到。下次在发送的时候就从第3个数据开始发。这个时候窗口大小就变成了2。