湖科大 《计算机网络》 超详细重点笔记 适合没时间看课想快速掌握知识点 或者 课后梳理复习

基础概念

路由器

是实现分组交换的关键构建 是最重要的分组交换机
任务是将网络互联起来，并对接收到的分组进行转发
不称其为主机

报文

表示一条消息的整个01串

三种交换方式

电路交换
报文交换

分组交换(分组的长度固定 ----->>> 缓冲区的大小便于控制)

过程

先把报文分成小的数据段 在每一个数据段前面 加上一些由必要的控制信息组成的首部以后 就构成了一个分组 简称为包 首部称为 包头

分组交换机收到这个包以后 先暂时存储下来 再检查首部 根据首部中的目的地址进行查表转发 找到合适的转发接口 通过这个接口将分组转发给下一个分组交换机。。。。。一次次转发就到了目的主机 再去掉首部 将各数据段连接还原

衡量网络性能的一些指标

先记一下数据量的单位

再记一下速率的单位

这两者直接有一一对应的约等于关系
比如: 2^10 = 10^3 2^20 = 10^6 2^30 = 10^9

标250GB实际是多少呢？

速率的计算

带宽

单位时间内能传输的数据量

吞吐量

时延

处理时延 知道有就行了

发送时延
计算公式: 分组长度 / 发送速率

计算

传播时延

时延带宽积

往返时间 RTT

网络利用率

丢包率

OSI体系结构

TCP/IP体系结构

五层体系结构

重新把网络接口层划分为物理层和数据链路层

每层解决的问题

如果在多个网络中 该如何标识各个网络和各个网络的主机呢 这就引入了网络层

​ 当主机收到了来自服务器的分组 那么这些分组应该交给主机中的哪个进程来处理呢？ 运输出现错误该怎么解决呢？

在此基础上 制定相应的协议 并且按照协议编写相应的应用程序 通过应用进程间的交互来完成相应的网络应用 这些就是应用层来解决的问题

基于网络的进程间通讯的具体流程描述

​ 应用层按照http协议， 构建一个http请求报文， 把它交给运输层处理， 运输层给http报文添加一个tcp首部，让他成为一个tcp报文段， 之后交给网络层， 网络层给它添加一个ip首部， 让他成为一个ip数据报， 之后交给数据链路层处理， 数据链路层给他添加一个首部和尾部， 让他成为帧， 之后交给物理层， 物理层把帧看成bit流， 如果是以太网， 物理层就还会给比特流前面添加前导码， 为了让目的主机做好接收帧的准备， 之后物理层把这个比特流变换成相应的信号发送到传输媒体。

​ 信号通过传输媒体到达路由器， 路由器的物理层将信号再变回比特流， 去掉前导码后交给数据链路层， 去掉帧的首部和尾部， 交给网络层， 是IP数据报， 网络层解析首部， 从中提取出目的网络的地址， 查找自身的路由表， 确定转发的端口再一步步重新给到自己的物理层发送出去。

。。。。。。。 之后就是后半部分一样的处理了

实体

协议

注意:
逻辑通讯并不存在
是为了让我们在研究某一层的时候不用考虑其它层 方便研究的一种手段

协议的三要素

每层之间协议的关系

数据链路层

是什么

封装成帧

把上层交付的协议数据单元封装成帧

• 帧头和帧尾中包含有重要的控制信息
• 帧头和帧尾的作用之一就是帧定界 (比如ppp帧前后的那一个字节) 方便接收方的数据链路层从物理层的Bit流中把一个个的帧提取出来(mac帧是物理层添加了前导码,所以没有帧定界标识)

**透明传输: **

会产生的问题:
帧定界标志是一个特殊的字符,如果在上层交付的协议数据单元中,恰好也包含了这个字符,就会出现问题。影响接收方的接收，这种情况下,数据链路层就会采取一些措施,保证接收方能正常接收。

问题的解决：

字节填充就是发送之前先扫描一遍,遇到了帧定界符,就在前面加一个转义字符,和真正的帧定界符进行去区分

比特填充法就是发送之前扫描一遍,遇到了和帧定界的这个字节的比特完全一样的,就在这个字节里面某个固定的位置填充上0

差错检测

是什么:

发送方将检错码封装在帧尾， 接收方主机收到帧后， 通过检错码和检错算法， 判断帧在传输过程中是否出现了误码 这就是差错检测

上面图中帧尾那四个字节的 FCS就是检错码

奇偶校验(很容易出错)

循环冗余校验CRC

具体计算:

注意 : 进行的是异或运算

总结：

可靠传输

概念: 误码是不能避免的,但是 只要能实现发送方发送什么，接收方就接收到什么,就称为可靠传输

提供的两种类型：

举例一些协议 的要求(要求可靠还是不可靠)

实现可靠传输的具体协议(协议是数据链路层的协议，但是这三种协议的基本原理并不局限于数据链路层,可以用到计算机网络体系的各层协议)

停止等待协议SW

既然数据分组需要编号

那么确认分组也需要编号 这样就可以解决重复确认的问题(数据链路层一般不会出现丢失的问题,所以一般不用编号)

信道利用率

具体计算

回退N帧协议GBN

好处: 采用累计确认的方法 即使确认分组丢失 也有可能是不必重传的 比如一开始的ack1丢失了 但是ack4传过去了， 这就说明前五个分组都是正确接收的 所以ack1也就没必要重传了

有差错时: 比如发送窗口这次发送来的是56701 但是5就丢失了,那么后续就会依次丢弃6701,每丢弃一个,就发送一个ack4的确认信息给发送方(上一次接收到的信息 因为上一次发送过来的是01234 所以最后一个接收到的是4) 发送方接收到重复的确认,就知道之前发送的数据分组出现了差错,不用等到超时计时器超时就立刻重传 (这也就是回退N帧)

为什么发送窗口的尺寸不能超过上线？
在上面图中的例子中,假设发送窗口是8，正好超过上限，第一次发送八个分组，接收方正确接收了，发送ACK7给发送方，但是这个确认分组丢失了，发送分组再重发前八个分组，因为序号还是0 ~ 7 ， 所以没有办法分辨是新的分组还是旧的分组。

总结:

当通讯线路质量不好的时候，他的信道利用率不比停等协议高

选择重传协议

举个例子:

​ 比如这个例子 2是错误的，所以2被丢弃了， 3进来，但是序号不匹配了，窗口就只会移动两个位置，并且发送两个确认信号，发送方收到01两个确认分组后，向前移动两个位置 发送45。发送方没收到2号确认分组 直接收到了3号确认分组 2号超时重传 接收方的滑动窗口收到这个2号以后 才会继续向前滑动

点对点ppp协议

​

帧格式

如何解决透明传输问题？

方法一: 字节填充法

差错检测

计算范围如下

循环冗余校验CRC

工作状态

ppp链路的开始和结束都是静止状态 不存在物理层连接
当检测到调制解调器的载波信号 并建立物理层连接之后 ppp进入链路的建立状态
现在链路控制协议LCP 开始协商一些配置选项
协商成功 则进入鉴别状态
协商失败 则退回到静止状态
若无需鉴别 或 鉴别成功 则进入网络状态
若鉴别失败 则 进入终止状态
NCP配置后 进入打开状态

MAC地址 IP地址 ARP协议

但是因为三者关系紧密 所以放在一起了

MAC地址

使用点对点信道的数据链路层不需要使用地址 因为整条线路上就他们两个
使用广播信道的数据链路层必须使用地址来区分各主机

MAC地址格式

第一字节的b0位取0 代表是单播地址 取1代表是多播地址
第一字节的b1位取0 代表全球管理 取1代表本地管理

MAC地址的发送顺序

单播MAC地址作用 ： 发送的主机在源地址填上自己的mac地址,在目的地址填上要发送给的那个主机的mac地址 再加上帧首部的其它字段 数据载荷以及 帧尾部等 构成了单播帧 。 之后发送出去，收到这个帧的主机,去目的地址检查一下，和自己的地址是不是匹配，不匹配就直接丢弃

广播mac地址作用 ： 目的地址字段直接写广播地址就行了FF-FF-FF-FF-FF-FF 其它不变 所有主机都会接收并处理

多播mac地址作用 :

发现有两个主机都包含了这个多播地址

发送的时候在目的地址的位置填上这个多播地址 这两台主机就都能收到这个多播帧了

IP地址 (属于网络层) 在这里只介绍ip地址的作用 详细的还是在网络层

从网络体系结构看ip地址和mac地址

数据包转发过程中IP地址和MAC地址的变化情况 本例只关注网络层和数据链路层
(路由器的最高层为网络层 没有运输层和应用层)

H1想发送数据给H2

这种转发需要通过IP地址找到MAC地址

由此引出了ARP协议

地址解析协议ARP

每台主机都会有一个ARP高速缓存表

当主机B要给主机C发送数据包的时候
先在缓存表中查询有没有主机C的IP MAC(他只知道C的IP 并不知道MAC 所以需要知道MAC才能发送)
这个时候主机B发送一个ARP请求报文 获得主机C的MAC地址

响应步骤如下

之后B就可以正常给C发送数据包了
结束

注意:

ARP只能逐段链路使用
不能跨好几个链路使用

集线器与交换机的区别

集线器

使用集线器HUB在物理层扩展以太网

下面是三个使用集线器连接的相互独立的以太网 一二三系 ，是三个独立的碰撞域， 也就是说 如果一系中的某台主机发送了数据帧，信号会传给一系中的全部主机。
为了使各系的以太网能相互通信，可以再使用一个集线器把他们互联起来，这样三个以太网就互联成了一个更大的以太网，三个碰撞域就合并成了一个更大的碰撞域， 形成了一个更大的总线型以太网，

以太网交换机

假如都发送了一个单播帧，集线器会发给总线上的全部主机，但是交换机会根据自身的帧交换表直接转发给目的主机

假设都发送了一个广播帧 没啥区别

假设都同时给一个主机发送单播帧 集线器会碰撞 交换机会先缓存起来再逐个发给这个主机 不会产生碰撞

详细对比如下

交换机

全双工： 发送帧和接收帧可以同时进行

概念

直通交换是 不必把整个帧先缓存再进行处理 在接收帧的同时，就立即按照帧的目的MAC地址 决定该帧的转发接口 但是他不检查帧是否有差错就直接转发

以太网交换机自学习和转发帧的流程

详细流程(假设各主机知道网络中其它各主机的MAC地址 也就是无需进行ARP):

大致意思就是这样，剩下的看下面的图片就行了

另外还有丢弃的情况，就是多加了一个G的这种，不会转发到进入的接口，所以就丢弃该帧了

以太网交换机的生成树协议STP

广播风暴: 广播帧会在这个环路中不停的循环转发。。

现在的以太网的问题，如果某条线路断了，如果某个交换机只依赖这一条线路，就会直接在以太网中断联了，安全性很低

解决办法：

虽然有环路，但是会根据STP来阻塞自己的一些接口，避免出现网络环路

虚拟局域网VLAN

先说路由器
路由器工作在网络层
路由器默认情况下不对广播数据包进行转发
所以它可以隔离广播域

但是成本高
所以就需要VLAN了

概念

实现机制
是在交换机上实现的。交换机需要有两个功能 ， 一个是能处理带有VLAN标记的帧，一个是交换机的各端口可以支持不同的端口类型（不同类型的端口对帧的处理方式有所不同）

特殊帧

交换机的端口类型

交换机的缺省VLAN ID（PVID）是交换机端口在没有特定配置时的默认VLAN标识
例如，当一个数据帧进入交换机端口时，如果该端口配置了特定的PVID，且数据帧的VLAN信息与端口的PVID匹配，那么该数据帧将不带VLAN标签直接发送出去；如果不匹配，则数据帧将被打上端口的PVID标签后发送。这种机制确保了数据帧在交换机内部的正确路由和传输‌

类型

Access端口

下图中的交换机初始化时，各接口默认PVID=1，端口类型默认是A，也就是Access接口
一般用于连接用户交换机

下面，我们想让主机AB划分为VLAN2 CD划分为VLAN3 可以如图所示进行改变

假如一个广播帧从端口1进入交换机，VID=2，就只会转发给端口2了，也就实现了VLAN的划分

Trunk端口

一般用于交换机之间 或者 交换机与路由器之间互联

想如图把两个交换机互联的网络划分为VLAN1和VLAN2
可以如图配置
记得把交换端口 也就是端口5的端口类型改为T

转发流程:

网络层

概述
各个网络之间由路由器互联

路由选择: 路由器收到数据包后怎么知道应该转发到哪个路由器呢？

所以这边介绍的是网际层

两种服务

面向连接的虚电路服务

是逻辑连接 并不是真的有一条线路

无连接的数据报服务(因特网)

IPV4地址

概述

表示方法

计算方法

到商0的时候结束,将从下到上组合比特串就行了

但是一般就是背住了凑就行了

分类编址的IPV4地址

一共有五类 红色数字是最高位固定的数字

注意事项

A类地址(最高位固定为0)

B类地址(最高位固定为10)

C类地址(最高位固定为110)

分配网络号

划分子网的IPV4地址

现在想把一个网络划分为几个子网 借用原来网络的主机号的一些位，来充当网络号，用来标识不同的子网

由此就有了下面的问题

所以就引出了一个划分子网的工具 ------>>>>> 子网掩码

看完例子再回去看上图就明白了

子网掩码中的255.255.255 对应网络号部分
128对应的是有多少位被借用

将128转化为二进制,发现只有一个1，所以只有1位是从主机号部分借用来充当子网号

现在的主机号还剩七位 也就是只有七位来标识主机了 所以可分配的地址数量是2^7,但是还要去掉主机号为全0的网络地址和全1的广播地址

分析一下

这是没有划分子网时候 该网络地址的细节

划分子网后就是下面这样了

可以再看个例题

默认子网掩码

无分类编址的IPV4地址

概念

就是采用了全新的一套 不用ABC分类了 也没子网的概念了

看一下例子:

地址掩码是 255.255.240.0

路由聚合(构造超网)
一个路由器想把自己的路由信息告诉另一个路由器时，可以采用这种方式将很多条记录合并为一条，以此来节约空间。
找到共同前缀 下面例子中，他们的前两个字节都一样，从第三个字节开始不一样，所以把第三个字节转化为二进制形式，其它的不变。这样就可以找到共同前缀。
聚合地址块格式为 共同前缀(保持不变) + 剩下的bit全部取0 / 共同前缀的长度

看个例题:

IPV4地址的应用规划

给定一个IPV4的地址块，如何将其划分为几个更小的地址块，并将这些地址块分配给互联网中的不同网络，进而可以给各网络中的主机和路由器接口分配IPV4地址。 一般有下面的两种方法

定长子网掩码划分举例:
先分析每个网络的IP地址需求

由此，需要划分为五个子网 ， 每个子网可分配的IP都不能少于自身的需求

把后面的八个比特改写成10进制

具体划分情况如下图

最后随便选五个子网分给N1到N5就可以了

总结 ： 采用定长的子网划分 只能划分出2^n个子网 n 是借用的用来作为子网号的比特数量

采用变长的子网掩码划分
和上面的划分需求相同

可以每个子网单独分析需要的网络前缀和标识的主机的位数

总结一下需求:

现在就要给这5个子网来分配子块

IP数据包的发送和转发过程

注意

包括下面两个部分

直接交付和间接交付

那么源主机如何知道自己和目的主机是否在同一个网络中？

假设主机C要给主机F发送IP数据报
C先用自己的IP和自己的子网掩码相与 得到自己的网络地址
再用F的IP地址和自己的子网掩码相与 得到目的主机的网络地址
发现不一样 --->>> 不在同一网络中
通讯属于间接交付

那么主机C如何知道应该把数据交给哪个路由器来转发呢？

用户指定一个默认的路由器 也就是默认网关

路由器如何转发？

将目的地址和地址掩码相与 如果发现和目的网络不匹配 这条就不满足

广播

如果发送的地址是本网络中的广播地址 就只能在本网络中传播 路由器不会转发

如果发送地址是对面的广播地址 也不会转发

静态路由配置及其可能产生的环路问题

是什么

当想转发的时候 ， 查一下路由表 ， 路由表没有的话自己配置一下，就是静态路由配置

默认路由:
对于具有相同下一跳的不同目的网络的路由条目，可以用一条默认路由条目来替代
默认路由条目中的目的网络地址为 0.0.0.0 地址掩码也是0.0.0.0 CIDR形式 0.0.0.0/0

特定主机路由: 地址掩码全1才能确定一个特定的主机

路由环路:
解决方法1

解决方法2(解决聚合了不存在网络的问题) 添加黑洞路由

路由选择协议

因特网采用的路由选择协议的主要特点:

自治系统内部和自治系统外部可以采用不同类别的协议

常见的路由选择协议

路由器的基本结构

流程: 信号从某个端口进入 物理层将信号转换成比特流 数据链路层从比特流中识别出帧 去掉帧头和帧尾后送交网络层处理
如果送交网络层的是普通的数据分组 就去查表转发 查不到就丢弃
转发后再一步步封装 发送出去
如果送交网络层的是交换路由信息的路由报文 就把这个分组送交路由选择处理机
处理机根据分组的内容更新自己的路由表

**路由表和转发表 ** 后续课程不严格区分

路由信息协议RIP

基本概念

**基本工作流程: ** 看 下面图右边 的 1 2 3 就是流程

路由条目更新规则 两个路由器之间通过封装有路由信息的RIP更新报文来交换

D收到C的路由表后 先进行改造

下面通过改造好的路由表对自己的路由表进行更新 有不同的更新理由

要注意16就是不可达了

问题
R1到N1的线路故障了 但是还没来得及把新的路由信息发送给R2 就接收到了R2原来的信息 导致R1被误导了

开放最短路径优先OSPF

一些基本概念

分组类型

工作过程

R1收到R2发来的数据库描述分组后,如果发现自己的数据库中缺少了信息,就会发送LSR分组 ，R2会回应LSU分组

当链路状态发生改变或者到了指定的时间 就会发送链路状态更新分组 收到该分组的路由器会洪泛转发该分组

在多点接入网络中建立邻居关系后，如何减少问候分组发送的数量?

划分区域 --->>> 把利用洪泛法交换链路状态信息的范围 局限于每一个区域 而不是 整个自治系统

边界网关协议BGP

不能以 代价来作为标准寻找最佳路由

具体情况比较复杂 尽量选择一条能到的比较好的就可以了

基本工作原理

BGP报文类型

封装关系

IPV4数据报的首部格式

为了简单起见，将IPV4数据报简称为IP数据报

某些IP数据报的首部 除了包含20字节外 还包含一些可选的字段 来 增加IP数据报的功能
每一行32Bit 也就是4个字节

IP数据报的首部长度一定是四字节的整数倍
由于首部中可选字段的长度从1字节到40字节不等
所以当长度不是四字节的整数倍的时候
就要用到填充字段了

总长度字段和首部长度字段的关系

首部长度是以4字节为单位的
总长度直接以字节为单位
二者相减就得到了数据载荷的长度

标识 标志 片偏移字段
这三个字段共同用于IP数据报分片

为什么要分片？

举例说明IP数据报如何进行分片

将3800字节的数据载荷部分分片为三个单独的IP数据报 给每个数据报都添加上首部

分片1数据载荷部分的第一个字节就是原数据报数据载荷部分的第一个字节
所以片偏移为 0 / 8 (因为片偏移字段以8为单位)

填表如下

若还需再次分片

生存时间

可以防止IP数据报在网络中永久兜圈

协议字段

注意: 片偏移量必须为整数 如果计算出来不是整数 就得换一种分片方式了

网际控制报文协议ICMP

分类

终点不可达

源点抑制(让源点发的慢点)

时间超过

参数问题

改变路由

在什么情况下不发送差错报告报文

ICMP询问报文

应用

Ping命令就是第一个应用 用来测试主机或路由器间的连通性

tracert命令的原理:

之后H1给H2发送TTL=2的回送请求报文
。。。。。。
以此类推

虚拟专用网VPN与网络地址转换NAT

虚拟专用网VPN

这三个是无需分配的专用地址

专用地址 只能用于一个机构的内部通讯

内部使用专用网络的两个通过因特网相互通讯的部门
具体通讯流程如下

虽然要要经过多个网络和路由器
但是从逻辑上看
好像是点对点的一样
所以也称为IP隧道技术

内联网VPN和外联网VPN

网络地址转换NAT

用来缓解IPV4地址即将被耗尽的问题

NAT路由器

假如使用私有地址的主机要给因特网上使用全球IP地址的另一台主机发送IP数据报
该主机先将ip数据报发送给NAT路由器
首部中源地址字段的值为该主机的私有地址
目的地址为另一台主机的全球地址
NAT路由器从自己的全球IP地址池中
给这个私有地址分配一个临时的全球IP地址

交换期间使用的全都是全球IP地址
当这台主机给源主机发回数据报后
NAT路由器会检查NAT转换表

之后把目的地址再修改为私有地址 并进行转发

产生的问题

解决

其实就是多加了个端口号

注意: 外网主机不能主动发起通信

运输层

概述

之前的几层实现了主机到主机的通讯
但是通讯的实体是位于通信两端主机中的进程

通信过程如下

端口号

运输层使用端口号来区分不同的应用进程

端口号的基本概念

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

在运输层使用UDP协议封装 称为UDP复用
在运输层使用TCP协议封装 称为TCP复用

在网络层使用IP协议封装成IP数据报 称为IP复用
IP数据报首部中协议字段的值 用来表明IP数据报的数据载荷部分封装的是何种数据单元
取值为6 TCP
取值为17 UDP

接受方的网络层接收到IP数据报后进行IP分用
如果协议字段17 把数据载荷上交运输层的UDP
运输层进行分用
也就是根据端口号
将他们交付给上层相应的用户进程

如下图所示流程

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

DNS服务器端进程所使用的熟知端口号是53

举例:
通过域名访问WEB服务器时候, 先向DNS服务器发送一个DNS查询请求
在运输层采用UDP协议 封装成UDP用户数据报
之后将UDP用户数据报 封装在IP数据报中
通过以太网发送给DNS服务器
DNS服务器接收到这个报文后
从中解封出UDP用户数据报
UDP首部中的目的端口号为53
所以把数据载荷部分交给DNS服务器

源端口是 用户PC中的DNS服务(DNS客户端)进程端口号

TCP和UDP的对比

UDP支持 一对一 一对多 一对全部的通讯
TCP仅支持 一对一通讯

这两个协议对应用报文的处理

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

TCP把应用进程交下来的数据块 仅仅看作一连串的 无结构的字节流
TCP把他们放到发送缓存中，根据发送策略， 从发送缓存中提取一定数量的字节，构建TCP报文段并发送
接收方的TCP一方面从所接收到的TCP报文段中 取出数据载荷部分存储在接收缓存中 一方面将接收缓存中的一些字节交付给应用进程 而且假如发送方发了10个数据块 接收方可能只用了4个数据块就把这些字节交付给应用进程了 所以应用进程要自己能还原出来这些信息 TCP是全双工通讯
TCP是面向字节流的

可靠不可靠的对比

虽然网际层使用的是IP数据报 向上层提供不可靠的传输服务 但只要运输层使用TCP协议 就可向上层提供面向连接的可靠的传输服务

首部对比

TCP的流量控制

让发送方别发的太快，要让接收方来得及接收

举例:
A给B发送数据 B对A进行流量控制
假设A的TCP报文段一次可以发送100字节数据
建立连接时
B告知A 窗口的大小是400
A也将发送窗口设置为400
大写ACK是TCP报文段首部中的标志位
小写ack是TCP报文段首部中的确认号字段 取值201说明序号201之前的数据全部正确接收了
rwnd是窗口字段

具体流程如下:

就是通过调整自己的接收窗口来对主机A进行流量控制

出现的问题
如果主机B又想让主机A发送数据了
重新调整接收窗口大小为300
但是调整报文在途中丢失了
就会产生死锁

解决 启用计时器 + 发送零窗口探测报文

TCP规定 即使接收窗口为0 也必须接收零窗口探测报文

TCP的拥塞控制

基本概念

四种拥塞控制算法

拥塞窗口 / 慢开始门限

慢开始算法

一个传输轮次 就是一个 往返时间
往返时间并不是恒定的数值
使用传输轮次作为横坐标是为了强调
已经把拥塞窗口所允许发送的报文段都连续发送出去 并收到了对已发送的最后一个报文段的确认
开始时拥塞窗口的值为1 慢开始门限的初始值为16

在执行慢开始算法的时候
发送方每收到一个对新报文段的确认时
就把拥塞窗口 大小翻倍
然后开始下一轮的传输
当拥塞窗口的值增长到慢开始门限值的时候
就改为执行拥塞避免算法
拥塞窗口是几 就能发送几个数据报文段

改为执行拥塞避免算法后
收到了一批确认报文后
只能给 拥塞窗口的大小 +1

如果有部分报文段在传输过程中丢失了一部分

整体传输过程如下图:

注意:

但是这两种算法有些问题

另外两种算法：

快重传算法

过程如下:

确认M6 代表前6个报文段都被正确接收了

快恢复算法

包含全部四种算法的整个控制拥塞的流程如下图:

发生了超时重传的话 就进行前两种算法的拥塞控制办法
当发送方收到三个重复确认的时候
就进行快重传和快恢复

来个例题:

TCP超时重传时间选择

纵坐标是时间

超时重传时间RTO 应略大于 往返时间RTT

因为TCP下层是很复杂的网络环境
数据报的转发路由也有可能不同
所以每次的往返时间也有很大差别
所以这个超时重传时间RTO还是很难选择

如上图 可能RTT1 > RTT0 那我们一开始设置的略大于往返时间的RTO就不在合适了

所以选择的规则如下

RFC6298给出的计算RTO的公式如下:

当测量到第一个RTT1的时候 RTTD1的值取为该样本的一半

往返时间RTT的测量

会出现上图的情况

针对出现超时重传时无法准确测量RTT的情况
解决方法如下:

计算举例:
没出现超时重传就按公式算就可以了
出现了超时重传就不看公式了 直接变成之前的两倍

TCP可靠传输的实现

TCP基于以字节为单位的滑动窗口来实现可靠传输

ack=31 说明接收方希望收到的下一个数据的序号是31 且 30号及以前的数据都被正确的接收了

本例中发送窗口的尺寸大小是20

发送窗口的情况 包括前沿 后沿的情况

现在31~41已经发送 但是还没收到确认 42~50是可以发送但是没发送的状态
如何描述发送窗口的状态呢？

接收方只能对按序收到的数据中的最高序号给出确认
如果收到了 32 33 但是没收到31 那么会把32 33 放在缓存中 同时发送一个确认信息 仍然是ack=31
发送方收到三个重复确认后就会进行快重传

补充说明

来个例题:

TCP连接的建立

概述

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

三报文握手建立连接的过程

一台主机中的某个进程主动发起TCP连接建立，称为TCP客户，另一台主机中被动等待TCP连接建立的应用进程称为TCP服务器。 将TCP连接建立的过程比喻为握手

一开始，TCP服务器进程首先创建传输控制块， 用来存储TCP连接中的一些重要信息。之后，TCP服务器进程进入监听状态，等待TCP客户进程的连接请求，称为被动打开连接。
TCP客户进程也是首先创建传输控制块，在打算建立连接的时候，向TCP服务器进程发送TCP连接请求报文段，并进入同步已发送状态。 称为主动打开连接。 SYN=1 说明是连接请求报文段 SYN=1的报文段不能携带数据
服务端发送连接请求确认报文段 ， 并进入同步已接收状态。报文段也不能携带数据
客户请求收到后 ， 再发送一个普通的TCP确认报文段，并进入连接已建立状态 可以携带数据 但是不携带数据就可以不消耗序号
服务器进程收到这个确认后 也进入连接已建立状态

为什么最后还要再发送一个普通的确认报文段呢？

下面举例说明:
TCP客户进程发送了一个TCP连接请求报文段，但是该报文在某些网络结点长时间滞留了，这会导致该报文段的超时重传，如果重传的报文段被TCP服务正确接收，TCP服务器给TCP客户进程发送一个TCP连接请求的确认报文段，并进入连接已建立状态(现在已经改成了两报文握手，所以直接进入了连接已建立状态，而不是像三报文握手那样进入同步已接收状态)，现在TCP连接的双方都进入了连接已建立状态。
但是，一段时间过后，刚才滞留的请求报文又到达了TCP服务器进程，就会被误认为是又发起了一个新的TCP连接请求。这样会浪费主机很多资源。

TCP连接的释放

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

下面来举例说明:
FIN是该报文段首部的终止位

TCP连接释放报文段(同时对之前收到的报文段进行确认,序号seq字段的值设置为u,等于客户进程之前已经传送过的最后一个字节的序号 + 1,FIN=1的报文段即使不携带数据，也要消耗掉一个序号.ack等于之前客户进程之前已收到的，数据的最后一个字节的序号 + 1)
服务器收到后，发送一个普通的TCP确认报文段并进入关闭等待状态。通知高层应用进程客户端进程要断开连接了。 TCP客户进程到服务进程这个连接就释放了 ， 现在的TCP连接属于半关闭状态(如果服务器进程仍有数据要发送，客户进程依然要接收)
客户端进程收到普通确认报文段后，进入终止等待2状态，等待TCP服务端进程发出的TCP连接释放报文段
服务端发送连接释放报文段 进入最后确认状态
客户端收到后发送确认报文段 进入时间等待状态
服务端收到后 进入关闭状态
客户端经过2MSL后进入关闭状态(确保TCP服务器进程收到最后一个TCP确认报文段并进入关闭状态)

保活计时器

TCP报文段的首部格式

首部格式如图

发送窗口大小应该选择 拥塞窗口和接收窗口中的较小者

扩展首部

应用层

常见的应用

客户/服务器(C/S)方式 和 对等(P2P)方式

CS方式

对等方式

动态主机配置协议DHCP(TCP/IP体系应用层的协议)

DHCP报文在运输层被封装成UDP用户数据报

需要给主机手动配置 IP地址 子网掩码 默认网关 DNS服务器等 才能使用户主机正确访问Web服务器
但是手工配置的工作量较大
所以可以在网络中设置一台DHCP服务器，网络开机后自动启动DHCP程序，向DHCP服务器请求自己的网络配置信息，这样就可以自动获取网络配置信息了，不需要手动设置了

DHCP的工作过程

现在网络中有两台DHCP服务器和一台主机
DHCP服务器使用CS方式，在DHCP服务器上运行DHCP服务器进程 ，简称为DHCP服务器(使用的UDP端口是67)
用户主机上运行DHCP客户端进行，简称为客户(使用的UDP端口是68)

先发送一个DHCP发现报文
封装有 事务ID DHCP客户端的MAC地址 等
源IP地址是 0.0.0.0
目的IP地址是: 255.255.255.255
服务器根据MAC地址查找自己的数据库 查找有无这个MAC地址对应的配置信息(也要用ARP确保IP地址没被占用)
有的话就用这个配置信息构建并发送DHCP提供报文
没有的话就用默认配置信息来构建并发送DHCP提供报文(目的地址也是广播地址)
DHCP客户根据事务ID来判断是不是自己请求的发现报文(和自己封装的事务ID相等就是自己请求的报文)
两台服务器各会发送一个，客户选择先到的那个就可以了(现在就挑选好了DHCP服务器)
下面发送请求报文,也就是要征得DHCP服务器的同意
请求报文包含以下内容

服务器同意，给客户发送确认报文
客户收到这个确认报文后，就可以开始使用所租用的IP地址了
不过在使用前还会先看看是不是被网络中的其它主机占用了

当租期已经过去一半时，客户会给服务器发送更新请求报文
同意 则发回确认报文
不同意 则发回否认报文 客户收到后必须立即停止使用的IP地址并重新发送DHCP发现报文 重新开始申请IP地址
无响应 则当租期过去87.5%时，必须重新发送更新请求报文
。。。

另外服务器可以随时提前终止DHCP服务器所提供的租用期
发送释放报文段即可

完整流程图如下:

DHCP中继代理

路由器不会转发DHCP发现报文 因为是广播

解决方法:
给该服务器配置DHCP服务器的IP地址
并使之称为DHCP中继代理

域名系统DNS

工作流程:
在浏览器输入域名后，用户主机会现在自己的DNS高速缓存中查找该域名对应的IP地址，没有找到的话，就会向网络中的某台DNS服务器查询(DNS服务器中有域名和IP地址映射关系的数据库)，DNS服务器收到DNS查询报文后，在其数据库中进行查询，之后将查询结果发送给用户主机。 用户主机的浏览器通过IP地址对这个服务器进行访问。

层次树状结构的域名结构

形成了下面这种树形结构

DNS是分布式系统

域名解析的过程

递归查询

迭代查询

在查询时就可以利用上高速缓存了

不光在本地域名服务器中需要高速缓存
在用户主机中也很需要

文件传送协议FTP

FTP客户计算机可以将各种文件上传到FTP服务器
也可以从FTP服务器下载文件

创建FTP服务器后 会有一个IP地址
客户在浏览器中可以通过这个地址访问FTP服务器

工作原理
一开始建立的连接 是来传送命令的 是命令通道
后面建立的才是数据通道

主动模式

被动模式

端口号不一样 服务器是被动等待客户连接的

电子邮件

邮件服务器中有很多邮箱
有用来转发待发送邮件的缓存

用户代理 其实就是电子邮件的客户端软件 比如Gmail 之类的

邮件发送和接收过程

SMTP的基本工作原理

发现有待转发的邮件 就建立TCP连接
基于命令和应答

具体流程如下图

220是应答代码 可能跟有描述信息

注意:

电子邮件的信息格式

传送

如果有非ASCII码数据 要转化为MIME进行传送

为了实现这种转换

下面介绍有关邮件读取的相关内容

常用的邮件读取协议

基于万维网的电子邮件

用的都是HTTP协议

很方便

万维网

是运行在因特网上的一个分布式应用

浏览器

万维网的文档

这些文档都部署在服务器端
需要从服务器传送给浏览器进行解析和渲染

TCP/IP体系中应用层非常重要的协议
HTTP超文本传输协议

举例:

HTTP/1.0

在第三次握手，也就是最后一个报文的数据载荷部分携带了HTTP请求

HTTP/1.1

HTTP的报文格式

HTTP请求报文的格式

url 统一资源定位符 /index.htm：服务器上资源的路径（例如一个网页）

这个HTTP报文没有主体实体

支持以下方法

HTTP响应报文的格式

短语是对状态码的简单描述

常见的状态码

Cookie

后续每次客户端请求服务器的时候，都会把cookie放在首部行中
具体流程如下:

万维网缓存与代理服务器

代理服务器没有请求的数据才会向因特网上的原始服务器发送请求

如果Web缓存的命中率高，就可以大大减少该链路上的通讯量 降低网络时延