图地芜湖

2021-12-07 14:41 门头沟学院 Java

关注

【计网】

本层协议的实现需要借助下层提供的服务

实现本层协议的目的是为了向上层提供更好的服务

一、应用层

==1.dns(域名解析系统)==

①作用

运行在 udp 53号端口，网络边缘的核心，分层的命名，分布式的数据库,

可以解析出域名的ip地址，
还可以别名到规范名字的转换。
还可以做负载均衡

域遵从组织界限，而不是物理网络

②.四种类型的域名服务器

根DNS服务器(13个)
顶级域(TLD)DNS域服务器(com、org、edu、国家顶级域等)
权威DNS服务器
本地DNS服务器，严格来讲，本地DNS服务器不属于该服务器层次结构，，但它对DNS层次结构尤为重要。

③.dns解析过程

当我们上网的时候如果通过域名（如www.taobao.com）访问一个网站，流程应该是输入网址，浏览器缓存中查找www.taobao.com的ip，如果你刚刚访问过，则直接返回ip，如果没找到，则先进入本机的hosts文件找有没有这个域名，有的话返回对于ip，没有的话，进入本地DNS解析器中查找缓存，找不到的情况下则需要网络中的服务器去查找，首先查找本地DNS配置的服务器，如我们熟悉的谷歌的8.8.8.8和电信的114.114.114.114这两个(mac上的配置地址文件 /etc/resolv.conf)，都是在我们机器上事先配置好的，访问这个服务器如果在其缓存中查到对于的ip则直接访问给我们，同时本机的DNS解析器缓存该记录，如果服务器也没有找到这个域名的信息，这时候要看我们本地的配置是否需要转发，如果需要就需要本地DNS服务器一级一级向上查询，知道返回域名信息，不是转发的情况下，本地DNS服务器开始与根DNS服务器交互，当然根DNS服务器并没有我们想要的ip信息，由于全球都需要依赖它，它只会返回一些基本信息，在此时它先返回给我们.com这个顶级域名管理服务器的ip，本地DNS服务器拿到这个ip再向它寻找，当然.com的域名他也不会全存储，它会返回二级域名taobao.com的管理服务器ip地址，本地DNS服务器再次查找返回给我们www.taobao.com 的ip地址，本地DNS服务器返回给客户端，只会客户端根据ip寻址，连接目标服务器。

==从请求主机到本地DNS服务器的查询时递归的，其余是迭代的==

④.DNS服务器的可靠性保证

主域名服务器定期把数据复制到辅助域名服务器中，⽽更改数

据只能在主域名服务器中进⾏。这样就保证了数据的⼀致性。

==缓冲是为了性能，删除是为了一致性==

⑤.dns报文

⑥.关于DNS负载均衡

DNS域名解析负载均衡有如下优点：

将负载均衡的工作交给DNS，省去了网站管理维护负载均衡服务器的麻烦。

技术实现比较灵活、方便，简单易行，成本低，使用于大多数TCP/IP应用。

对于部署在服务器上的应用来说不需要进行任何的代码修改即可实现不同机器上的应用访问。

服务器可以位于互联网的任意位置。

同时许多DNS还支持基于地理位置的域名解析，即会将域名解析成距离用户地理最近的一个服务器地址，这样就可以加速用户访问，改善性能。

同时，DNS域名解析也存在如下缺点：

目前的DNS是多级解析的，每一级DNS都可能缓存A记录，当某台服务器下线之后，即使修改了A记录，要使其生效也需要较长的时间，这段时间，DNS任然会将域名解析到已下线的服务器上，最终导致用户访问失败。

不能够按服务器的处理能力来分配负载。DNS负载均衡采用的是简单的轮询算法，不能区分服务器之间的差异，不能反映服务器当前运行状态，所以其的负载均衡效果并不是太好。

事实上，大型网站总是部分使用DNS域名解析，利用域名解析作为第一级负载均衡手段，即域名解析得到的一组服务器并不是实际提供服务的物理服务器，而是同样提供负载均衡服务器的内部服务器（nginx），这组内部负载均衡服务器再进行负载均衡，请求发到真实的服务器上，最终完成请求。

2.FTP文件传输协议

①.概念

实现了⽂件传送的基本服务位于TCP之上，

端口20是传输所用到的端口，端口21只用于FTP的登录认证。

⼤多数 FTP 控制帧是简单的ASCII⽂本，⽤户向服务器发出FTP命令，服务器执⾏⽤户的FTP命令，并将执⾏的结果返回给⽤

户。

②.工作方式

主动⽅式：

客户与服务器21号端⼝建⽴连接之后（端⼝号N>1023），然后监听N+1号端⼝，并发送FTP命令“port N+1”到FTP服务器，服务器⽤20号数据端⼝主动向客户N+1端⼝建⽴连接。

被动⽅式：

客户⽤端⼝N（>1023）与服务器21号端⼝建⽴连接之后，客户端打开N+1端⼝，发送PASV命令给服务器，服务开启端⼝P（>1023），并发送“PORT P”告知客户，然后客户从端⼝N+1和服务器端⼝P建⽴连接，⽤来进⾏数据传送。

3.ssh

①.概念

SSH是一种网络协议，用于计算机之间的加密登录。位于Tcp之上的22号端口。

②.登录原理

SSH使⽤对称加密算法实现数据安全传输；

对称加密算法的密钥是通过⾮对称加密算法（RSA）进⾏交换的。

③.和Telnet异同

相同点：

远程登录其他主机；
运输层采⽤TCP协议。

不同点：

Telnet明⽂传送；SSH加密传送，且⽀持压缩；
Telnet服务默认端⼝号为23；SSH服务默认监听22号端⼝；

==4.HTTP超⽂本传送协议==

①.概念

超⽂本传送协议 HTTP (HyperText Transfer Protocol)；

HTTP 是⼀个应⽤层协议，它位于TCP 之上的80号端口进⾏可靠的传送。

HTTP是无状态，的服务器并不维护关，于客户的任何信息。

②.持续连接和非持续连接

非持久HTTP

最多只有一个对象在TCP连接上发送
下载多个对象需要多个TCP连接
HTTP/1.0使用非持久连接

持久HTTP

多个对象可以在一个（在客户端和服务器之间的）TCP连接上传输
HTTP/1.1 默认使用持久连接(不用申明Connection: keep-alive)

一旦客户端发送connection:keep-alive头给服务端，且服务端也接受这个keep-alive的话，两边对上暗号，这个连接就可以复用了，一个http处理完之后，另外一个http数据直接从这个连接走了。减少新建和断开TCP连接的消耗。(不要和TCP的keepalive弄混了)

③.URL(统一资源定位符)

④.HTTP报文

HTTP请求报文与响应报文格式 请求报文包含三部分: a、请求行：包含请求方法、URI、HTTP版本信息 b、请求首部字段 c、请求内容实体(get实体内容为空) 响应报文包含三部分： a、状态行：包含HTTP版本、状态码、状态码的原因短语 b、响应首部字段 c、响应内容实体

④.常见状态码

200：请求被正常处理 204：请求被受理但没有资源可以返回 206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。 301：永久性重定向 302：临时重定向 303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上 304：发送附带条件的请求时，条件不满足时返回，与重定向无关 307：临时重定向，与302类似，只是强制要求使用POST方法 400：请求报文语法有误，服务器无法识别 401：请求需要认证 403：请求的对应资源禁止被访问 404：服务器无法找到对应资源 500：服务器内部错误 503：服务器正忙

⑤.HTTP协议几个版本的比较

http1.0和1.1比较

1.0TCP连接不可以复用，一个TCP连接只能发送一个请求，当服务器响应后，就会关闭这次连接。后面提供了一个非标准字段Connection字段来实现长连接，但是由于非标准字段，所以不同实现的行为可能不一致。

1.1实现长连接，即TCP连接默认不关闭，允许被多个请求复用，不用申明Connection: keep-alive。
1.1比1.0新增了几个请求方式put、patch、options、delete等。
1.1 请求头新增host字段，用来处理服务器存在多个虚拟主机的情况。

http2.0和之前的比较

增加双工模式:即不仅客户端能够同时发送多个请求，服务端也能同时处理多个请求，解决了队头堵塞的问题；
支持二进制帧的格式来传递报头和数据。
服务器推送功能，当我们对支持HTTP2.0的web server请求数据的时候，服务器会顺便把一些客户端需要的资源一起推送到客户端，免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源

==⑥.HTTPS以及加密过程==

对称加密：加密的密钥和解密的密钥一样

eg: DES AES

存在key分发问题

非对称(公开密钥体系)加密：加密的密钥和解密的密钥不一样

eg: RSA

HTTPS=非对称加密+对称加密+HASH+CA

原本HTTP先和TCP（假定传输层是TCP协议）直接通信，而加了SSL后，就变成HTTP先和SSL通信，再由SSL和TCP通信，相当于SSL被嵌在了HTTP和TCP之间。

5.简单邮件传输协议SMTP

采⽤TCP协议，监听25号端⼝。

不使⽤中间服务器：
发送⽅和接收邮件服务器直接建⽴TCP连接；
发送邮件不需要鉴别；
SMTP采⽤ASCII明⽂传送。

• 三个阶段：

连接建⽴；
邮件传送；
连接释放。

6.邮件读取协议POP3和IMAP

两个常⽤的邮件读取协议：

POP3：邮局协议 (Post Office Protocol) 第3个版本
IMAP：⽹际报⽂存取协议 (Internet Message Access Protocol)

POP3协议：

邮局协议(Post Office Protocol)第3个版本
简单
采⽤TCP协议，服务器监听110端⼝；
仅⽤于客户从服务器上取邮件；
需要鉴别；
客户取回邮件，服务器即删除该邮件

IMAP协议：

⽹际报⽂存取协议(Internet Message Access Protocol)；
采⽤TCP协议，服务器监听 143 端⼝；
联机协议，类似在本地操作（可创建管理⽂件夹）；
连接 IAMP 仅下载邮件⾸部，打开邮件后传送⾄客户⽤户代理；
允许收信⼈只读取邮件中的某⼀个部分；
⽤户可以搜索邮件内容。

==7.动态主机配置协议 DHCP==

DHCP动态主机配置协议（udp上的67，68端口）

主机接⼊互联⽹络需配置协议参数：

IP 地址；
⼦⽹掩码；
默认路由器的 IP 地址（默认⽹关）；
域名服务器的 IP 地址。

ip 掩码 - 子网掩码 localNameServer default getway

二、运输层

底层协议的不可靠性，决定了RDT协议的复杂性

1.可靠数据传输RDT

①.Rdt1.0:在可靠信道上的数据传输

假设下层信道是完全可靠的

没有比特出错
没有分组丢失

=> Rdt1.0 可以什么都不干

②.Rdt2.0具有比特差错的信道

下层信道可能会出错

反馈重发ACK,NAK

③.Rdt2.1接收方处理出错的ACK/NAK

Rdt2.0存在问题：ACK,NAK的传输也可能会出错

解决：加入序号seq

停等协议(stop - waiting)：一次只有一个等待确认分组的协议。这个在信道比较大的情况下效率比较低

④.Rdt2.2 无NAK的协议

当前分组的反向确认=>用前一个分组的正向确认，回应 ACK + 序号的格式

为后面一次发送多个分组做铺垫

⑤.Rdt3.0具有比特差错和分组丢失的信道

因为有分组丢失的可能，发送方在等确认，接受方在等新的分组，所以会形成死锁

解决：超时重传,增加一个超时计时器，(无论错误还是丢失，都等待超时重传)

超时定时器的设计应该不正常的往返时间多，确保这个绝大多数情况是丢失的。

如果设计不合理，交互还是会正常运行，但是会造成大量重复。

⑥.流水线:一次发送多个未经确认的分组(pipelined协议)

两种通用的流水线协议：==回退N步(GBN) 和选择重传(SR)==

==⑦滑动窗口协议==

1.发送窗口

发送窗口:发送缓冲区的一个范围

那些已经发送，但还未经确认的分组构成的空间

发送窗口的最大值 <= 发送缓冲区的值

实际发送窗口滑动过程 - 相对表示方法

分组窗口不动，可缓冲范围滑动

发动窗口后延的滑动

条件:收到老分组的确认
极限:不能超过前沿

2.接收窗口

接收窗口 (receiving window)=接收缓冲区

接收窗口用于控制哪些分组可以接收；

只有收到的分组序号落入接收窗口内才允许接收
若序号在接收窗口之外，则丢弃；

接收窗口尺寸Wr=1，则只能顺序接收(GBN)

接收窗口尺寸Wr>1 ，则可以乱序接收 (SR)

但提交给上层的分组，要按序

接收窗口的滑动

滑动：

低序号的分组到来，接收窗口移动；
高序号分组乱序到，缓存但不交付（因为要实现rdt，不允许失序），不滑动

发送确认：

接收窗口尺寸=1 ；发送连续收到的最大的分组确认（累计确认）
接收窗口尺寸>1 ；收到分组，发送那个分组的确认（非累计确认）

3.正常情况下的2个滑动窗口互动

发送窗口

有新的分组落入发送缓冲区范围，发送->前沿滑动
来了老的低序号分组的确认->后沿向前滑动->新的分组可以落入发送缓冲区的范围

接收窗口

收到分组，落入到接收窗口范围内，接收
是低序号，发送确认给对方
发送端上面来了分组->发送窗口滑动->接收窗口滑动->发确认

源动力来源于发送方上层不断发送分组的到来

4.异常情况下GBN的2窗口互动

发送窗口

新分组落入发送缓冲区范围，发送->前沿滑动
超时重发机制让发送端将发送窗口中的所有分组发送出去
来了老分组的重复确认->后沿不向前滑动->新的分组无法落入发送缓冲区的范围（此时如果发送缓冲区有新的分组可以发送）

接收窗口

收到乱序分组，没有落入到接收窗口范围内，抛弃（重复）发送老分组的确认，累计确认；

5.异常情况下SR的2窗口互动

发送窗口

新分组落入发送缓冲区范围，发送->前沿滑动
超时重发机制让发送端将超时的分组重新发送出去
来了乱序分组的确认->后沿不向前滑动->新的分组无法落入发送缓冲区的范围（此时如果发送缓冲区有新的分组可以发送）

接收窗口

收到乱序分组，落入到接收窗口范围内，接收发送该分组的确认，单独确认；

6.GBN协议和SR协议的异同

相同之处

发送窗口>1
一次能够可发送多个未经确认的分组

不同之处

GBN: 接收窗口尺寸=1

接收端：只能顺序接收
发送端：从表现来看，一旦一个分组没有发成功，如：0,1,2,3,4 ; 假如1未成功，234都发送出去了，要返回1再发送1，2，3，4；GB1
只维护一个定时器，针对发送窗口下沿的定时器，一旦超时之后**，会把所有已发送的但是未确认的分组都再全部发送一遍**

SR: 接收窗口尺寸>1

接收端：可以乱序接收
发送端：发送0,1,2,3,4，一旦1未成功，2,3,4,已发送，无需重发，选择性发送1
会为所有已发送的但是未确认的分组设定一个超时定时器。

==2.可靠数据传输TCP==

传输控制协议 TCP（Transmission Control Protocol）是面向连接的，提供可靠交付，有流量控制，拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），每一条 TCP 连接只能是点对点的（一对一）

①.TCP可靠数据传输

1.TCP在IP不可靠服务基础上建立了rdt

管道化的报文段: GBN & SR
累积确认（像GBN）
单个重传定时器（像GBN）
是否可以接受乱序的，没有规范
TCP在接收端会设置缓存，来缓存正确接收但是失序的分组，这点与SR类似

通过以下事件触发重传

超时（只重发那个最早的未确认段：SR）
重复的确认 (eg：收到了ACK50,之后又收到3 个ACK50,3个冗余ACK)

接收方要给顺序到来的最后一个字节给确认ACK。

如果发送方收到同一数据的3个冗余ACK，重传最小序号的段：

==快速重传==：在定时器过时之前重发报文段。

2.==为什么两次握手不行？==

如果传输信道中存在着滞留的连接请求，触发了重传定时器，new 和服务器建立了连接，完成之后，old请求又会和服务器建立连接。服务器就会维护很多这种虚假的半连接，浪费资源。这里还可能旧的数据被当成新的数据接收了。

3.TCP三次握手做了哪些事情

双方必须选择自己的初始序号并且对给确认，保证连接是全双工通讯

第三次握手可以携带第一次的数据发送

4.为什么握手前要随机自己的发送序列号

主要是解决==网络滞留==问题

这样一种情况

主机A 66端口和主机B 77 号端口建立了连接，A发送分组滞留在了网络中， AB又断开了连接，

如果下一次AB相同端口又建立了连接，这个分组就会发到B主机，从而又是旧的数据被当成新的数据接收的问题

如果我们是随机的序列号，上诉情况分组再次发到B时，就会因为序列号对不上，而被丢掉。

我们可以根据时钟周期作为起始序号。

5.TCP关闭连接

把TCP建立的连接分为两个方向，C -> S, S -> C,每个方向单独拆除

②.TCP拥塞控制

TCP是端到端的拥塞控制

1.发送方如何感知拥塞

超时
三个冗余ACK

2.如何控制发送端发送的速率

维持一个拥塞窗口的值：CongWin

发送端限制已发送但是未确认的数据量（的上限）:

LastByteSent - LastByteAcked / CongWin

如何控制发送端发送的速率

CongWin是动态的，是感知到的网络拥塞程度的函数

超时或者3个重复ack，CongWin ↓

• 超时时：CongWin降为1MSS,进入SS阶段然后再倍增到CongWin/2（每个RTT），从而进入CA阶段

• 3个重复ack ：CongWin降为CongWin/2,CA阶段。

否则（正常收到Ack，没有发送以上情况）：CongWin跃跃欲试↑

• SS阶段：加倍增加(每个RTT)

• CA阶段：线性增加(每个RTT)

(mss 字节流中最大报文长度)

流量控制和拥塞控制是联合动作

3.TCP拥塞控制策略

慢启动
线性增，乘性减
当CongWin＜Threshold, 发送端处于慢启动阶段**（slow-start）, 窗口指数**性增长.
当CongWin > Threshold, 发送端处于拥塞避免阶段**（congestion-avoidance）, 窗口线性**增长.
当收到三个重复的ACKs (triple duplicate ACK),Threshold设置成 CongWin/2， CongWin=Threshold+3.
当超时事件发生时timeout, Threshold=CongWin/2CongWin=1 MSS，进入SS阶段

3.UDP

用户数据报协议 UDP（User Datagram Protocol）是无连接的，尽最大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信。

三、网络层

1.子网&子网掩码

子网ip地址的前缀要是一样
子网间无需路由器介入，子网内各主机可以在物理上直接到达，一跳可达。

互联网的路由是以网络为单位，路由器仅根据目的主机所连接的网络号来转发分组（而不考虑目的主机号）。而且在传输过程中，这些子网的路由信息是可以做进一步的聚集的。

ip地址在查路由表和路由的时候是没有意义的。

路由器总是具有两个或两个以上的 IP。地址路由器的每一个接口都有一个不同网络号的 IP 地址。

子网掩码是一个32位地址，用于屏蔽IP地址的一部分以区别网络标识和主机标识。使用子网掩码(subnet mask)可以找出 IP 地址中的子网部分。子网掩码是一个网络或一个子网的重要属性。

(IP地址) AND (子网掩码) =网络地址

2.分类ip地址类别

3.CIDR无分类域间路由选择

CIDR 消除了传统的 A 类、B 类和 C 类地址以及划分子网的概念，因而可以更加有效地分配IPv4 的地址空间。网络号和主机号不固定，按需分配。

4.地址解析协议ARP

网络层实现主机之间的通信，而链路层实现具体每段链路之间的通信。因此在通信过程中，IP 数据报的源地址和目的地址始终不变，而 MAC 地址随着链路的改变而改变。

每个主机都有一个 ARP 高速缓存，里面有本局域网上的各主机和路由器的 IP 地址到 MAC 地址的映射表。

为什么我们不直接使用硬件地址进行通信？

由于全世界存在着各式各样的网络，它们使用不同的硬件地址。要使这些异构网络能够互相通信就必须进行非常复杂的硬件地址转换工作，因此几乎是不可能的事。

5.网际控制报文协议 ICMP

ICMP 是为了更有效地转发 IP 数据报和提高交付成功的机会。它封装在 IP 数据报中，但是不属于高层协议。

终点不可达
时间超过
参数问题
改变路由（重定向(Redirect)

①. Ping

Ping 是 ICMP 的一个重要应用，主要用来测试两台主机之间的连通性。

Ping 的原理是通过向目的主机发送 ICMP Echo 请求报文，目的主机收到之后会发送 Echo 回答报文。Ping 会根据时间和成功响应的次数估算出数据包往返时间以及丢包率。

②. Traceroute

Traceroute 是 ICMP 的另一个应用，用来跟踪一个分组从源点到终点的路径。

Traceroute 发送的 IP 数据报封装的是无法交付的 UDP 用户数据报，并由目的主机发送终点不可达差错报告报文。

6.路由选择协议

可以把路由选择协议划分为两大类：

自治系统内部的路由选择：RIP 和 OSPF
自治系统间的路由选择：BGP

①. 内部网关协议 RIP

RIP 是一种基于距离向量的路由选择协议。距离是指跳数，直接相连的路由器跳数为 1。跳数最多为 15，超过 15 表示不可达。

RIP 按固定的时间间隔仅和相邻路由器交换自己的路由表，经过若干次交换之后，所有路由器最终会知道到达本自治系统中任何一个网络的最短距离和下一跳路由器地址。

②. 内部网关协议 OSPF

开放最短路径优先 OSPF，是为了克服 RIP 的缺点而开发出来的。

开放表示 OSPF 不受某一家厂商控制，而是公开发表的；最短路径优先表示使用了 Dijkstra 提出的最短路径算法 SPF。

③. 外部网关协议 BGP

BGP（Border Gateway Protocol，边界网关协议）

AS 之间的路由选择很困难，主要是由于：

互联网规模很大；
各个 AS 内部使用不同的路由选择协议，无法准确定义路径的度量；
AS 之间的路由选择必须考虑有关的策略，比如有些 AS 不愿意让其它 AS 经过。

BGP 只能寻找一条比较好的路由，而不是最佳路由。

四、链路层

1.基本问题

①. 封装成帧

将网络层传下来的分组添加首部和尾部，用于标记帧的开始和结束。

②. 透明传输

透明表示一个实际存在的事物看起来好像不存在一样。

帧使用首部和尾部进行定界，如果帧的数据部分含有和首部尾部相同的内容，那么帧的开始和结束位置就会被错误的判定。需要在数据部分出现首部尾部相同的内容前面插入转义字符。如果数据部分出现转义字符，那么就在转义字符前面再加个转义字符。在接收端进行处理之后可以还原出原始数据。这个过程透明传输的内容是转义字符，用户察觉不到转义字符的存在。