计算机网络期末复习必看篇之传输层
计算机网络概念多,记不住,抓不住重点是因为你不会总结,进来看看,看不懂,看不会过来打我
前文推荐
学计算机网络之前了解这些,学习效率不提升过来打我
计算机网络物理层第一章物理层详解
吐血码万字长文搞懂了数据链路层
计算机网络的网络层,真就一看就懂?
文章目录
- 传输层
- 传输层的两种协议简述
- 传输层的寻址与端口
- UDP协议
- UDP的主要特点
- UDP首部格式
- UDP校验
- TCP协议
- TCP的主要特点
- TCP 报文段首部格式
- TCP的连接管理
- TCP连接的建立
- 洪泛攻击
- TCP连接的释放
- TCP的可靠传输
- TCP的流量控制
- TCP的拥塞控制
- 慢开始和拥塞避免
- 快重传和快恢复
- 快重传和快恢复
传输层
只有主机才有的层次
| 在协议栈中传输层的作用 |
|---|
 |
传输层的功能:
- 传输层提供进程和进程之间逻辑通信
- 而网络层提供的是主机之间的逻辑通信
- 复用和分用
- 复用:不同的进程都可以使用同一传输层协议来传输数据
- 分用:接收方的传输层在接收到数据后能正确的把数据送交给正确的进程
- 传输层对收到的报文进行差错检测
- 之间在网络层时学过一个差错控制,那个首部校验和仅仅是校验的是首部,而不是数据
- 传输层的两种协议
传输层的两种协议简述
传输层有两个好兄弟
大哥TCP和二弟UDP
大哥靠谱,二弟不靠谱
- 面向连接的传输控制协议TCP
传送数据之前必须建立连接,数据传送结束后要释放连接.不提供广播或多播服务.由于TCP要提供科奥的面向连接的传输服务,因此不可避免增加了许多开销:确认.流量控制,计时器以及连接管理等
可靠,面向连接,时延大,适用于大文件
- 无连接的用户数据报协议YDP
传送数据之前不需要建立连接,收到UDP报文后也不需要给出任何确认
不可靠,无连接,时延小,适用于小文件
传输层的寻址与端口
复用:应用层所有的应用进程都可以通过传输层再传输到网络层
分用:传输层从网络层收到数据后交付指明的应用进程
**端口:**是传输层的SAP,标识主机中的应用进程(每一个进程都有一个唯一的标识端口)
- 这里的端口是逻辑端口或称为软件端口,要和路由器上的端口(硬件端口区分开)
- 端口号只有本地意义,在因特网中不同计算机的相同端口是没有联系的.
- 端口号长度为16bit,能表示55535个不同的端口号
| 端口号分分类 |
|---|
 |
| 常见熟知端口号 |
|---|
 |
在网络中采用发送方盒接收方的套接字组合来识别端点,套接字唯一标识了网络中的一个主机和它上面的一个进程.
套 接 字 S c o k e t = ( 主 机 I P 地 址 , 端 口 号 ) 套接字Scoket = (主机IP地址,端口号) 套接字Scoket=(主机IP地址,端口号)
UDP协议
UDP只在IP数据报服务之上添加了很少功能,即复用分用和差错检测功能
UDP的主要特点
- UDP是无连接的,减少开销和发送数据之前的时延
- UDP使用最大努力交付,即不保证可靠交付
- UDP是面向报文的,适合一次性传输少量数据的网络应用
- UDP无拥塞控制,适合很多实时应用
- UDP首部开销小,8B,而TCP是20B
| UDP协议的传输 |
|---|
 |
- 也就是说UDP协议传输的是从应用层传输下来的一个完整的报文
- 那么如果该报文过大,那么传输到网络层时就会影响到网络层传输的效率
- 如果该报文过小,那么将该报文段传输到网络层时,那么数据传送到网络层的话,数据部分相对于IP首部就显得很小,数据的传输效率很低
UDP首部格式
| UDP首部格式 |
|---|
 |
UDP校验
| 数据格式 |
|---|
 |
| UDP校验过程 |
|---|
 |
TCP协议
TCP的主要特点
- TCP是面向连接(虚连接)的传输层协议.
- 每一条TCP连接只能有两个端点,每一条TCP连接只能是点对点的
- 那么TCP协议的连接就不能实现广播的机制
- TCP提供可靠交付的服务:无差错,不丢失,不重复,按序到达.
可靠有序,不丢不重 - TCP提供全双工通信(并且有发送缓存和接受缓存)
- 发送缓存:准备发送的数据&已发送但尚未收到确认的数据
- 接收缓存:按序到达但尚未接受应用程序读取的数据&未按序到达的数据
- TCP面向字节流---->TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流
- 流:流入到进程或从进程中流出的字节序列
| TCP协议数据的传输过程 |
|---|
 |
TCP 报文段首部格式
| TCP报文段首部格式及格式解析1 |
|---|
 |
| TCP报文段首部格式及格式解析2 |
|---|
 |
| TCP报文首部格式以及格式解析3 |
|---|
 |
TCP的连接管理
TCP连接传输三个阶段:
TCP连接的建立采用客户端服务器式主动发起连接建立的应用进程叫做客户,而被动等待连接建立的应用进程叫服务器.
TCP连接的建立
假设运行在一台主机(客户)上的一个进程想与另一台主机(服务器)上的一个进程建立一条连接,客户应用进程首先通知客户TCP,他想建立一个与服务器上某个进程之间的连接,客户中的TCP会用一下步骤与服务器中的TCP建立一条TCP连接
| TCP连接的过程-三次握手 |
|---|
 |
洪泛攻击
| 什么叫洪泛攻击 |
|---|
 |
TCP连接的释放
参与一条TCP连接的两个进程中的任何一个都能终止该连接,连接结束后,主机中的"资源"(缓存和变量)将被释放.
| TCP连接释放-四次挥手 |
|---|
 |
TCP的可靠传输
| TCP可靠传输 |
|---|
 |
TCP实现可靠传输的机制
- 校验 2.序号 3.确认 4.重传
其中校验和UDP校验是完全一样的,增加伪首部,然后用二进制反码补码的方式判断有没有发生错误
- 序号
- TCP在传输时以字节为单位,于是把一个字节编上一个序号,但是对于一个文件或者数据来说第一个字节的序号是随机的,不一定是1
- 序号字段:一个报文段第一个字节的序号
- 但是在实际发送的过程中是以报文段为单位的,报文段的大小是不确定的,看数据的大小进行合理分配
- TCP在传输时以字节为单位,于是把一个字节编上一个序号,但是对于一个文件或者数据来说第一个字节的序号是随机的,不一定是1
| 序号 |
|---|
 |
- 确认
- 接收方在接收到发送方发送的数据后,会向发送方发送确认报文段
- 也有可能在接收方有数据要发送的时候把确认信息捎带上,这就叫**捎带确认*
- TCP的确认机制默认使用的是一种累计确认的机制
- 默认确认机制:TCP只确认数据流当中第一个丢失字节为止的字节
- 接收方发送的确认报文段就是期待收到的下一个字节,如图中的4
- 只有接收方告诉方法方的确收到了发送的数据了,那么发送方才会在TCP缓存中把该数据(报文段)删除
- 接收方在接收到发送方发送的数据后,会向发送方发送确认报文段
| 确认机制-过程1-发送方发送报文段给接收方,接收方发送确认报文段给发送方 |
|---|
 |
那么接收方发送了确认报文段给发送方,发送方就知道了接收方已经收到了刚才发送的数据,就会删除在TCP缓存中刚才发送给接收端的报文段
| 发送方删除在TCP缓存中刚才发送给接收端的报文段 |
|---|
 |
然后我们假设发送方发送了(4,5,6)和(7,8)两个报文段,但是(4,5,6)报文段可能由于路由选择,网络情况不好等问题没有成功发送给接收方
| 发送方发送(4,5,6)和(7,8)两个报文段,假设只成功发送(7,8) |
|---|
 |
那么这时接收方是如何使用确认机制来实现可靠传输呢?
| 使用累计确认实现可靠传输 |
|---|
 |
- 对于接收端来说(7,8)报文段虽然正确接收,但是因为(4,5,6)报文段没有收到,那么接收端仍然会向发送端发送确认报文的首部字段为4.要求发送端对(4,5,6)报文段进行重传
- 确认重传不分家,TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文段.
超时重传- 规定的时间:也就是重传时间
- 重传时间的设置过长,由于数据在链路中传输,可能经过的路由不同,传输到接收方所需的时间也可能不同,时间过长,那么网络的空闲时间大大增大,减低了传输效率
- 重传时间设置的过短,那么就可能导致,数据可能还在传输过程中,接收端就发送重传的请求,那么就会让网络的负载过大
- 那么TCP采用了自适应算法动态改变重传时间RTTs(加权平均往返时间)
- 我们在传输前面的报文段时会得到RTT(可理解为单次传输往返时间)
- 然后求出RTTs作为下一个报文段传输的重传时间
- 规定的时间:也就是重传时间
那么在我们使用这种RTTs(加权平均往返时间)进行重传时间的设定时,可能会导致等待的时间过久
于是通过冗余ACK(冗余确认):我们期望能提前知道数据(报文段)是否丢失
每当比期望序号打的时序报文段到达时,发送一个冗余ACK,指明下一个期待字节的序号
发送方已发送1,2,3,4,5报文段
接收方收到1,返回给1的确认(确认号2的第一个字节)
接收方收到3,仍回给1的确认(确认号2的第一个字节)
接收方收到4,仍回给1的确认(确认号2的第一个字节)
接收方收到5,仍回给1的确认(确认号2的第一个字节)
发送方收到3个对于报文段1的冗余ACK----->认为2报文段丢失,重传2号报文段
快速重传
TCP的流量控制
流量控制:让发送方慢点,要让接收方来得及接收
TCP利用滑动窗口机制实现流量控制
在通信过程中,接收方根据自己接收缓存的大小,动态地调整发送方的发送窗口大小,即接收窗口rwnd(接收方设置确认报文段的窗口字段来将rwnd通知给发送方),发送方的发送窗口取接收窗口rwnd和拥塞窗口cwnd的最小值.
一个案例看TCP传输过程和流量控制
| TCP传输过程和流量控制 |
|---|
 |
- 持续计时器是为了防止在接收方给发送方发送的rwnd=0后再发送的滑动窗口值让发送方发送数据的报文段丢失,就是在B—> A rwnd=0 然后过一段时间 B---->A rwnd=400(此条报文丢失),那么A就一直等待B给自己的rwnd,而B一直等待A发送的数据,这样就陷入了死锁.解决方式是:持续计时器和探测报文段
TCP的拥塞控制
出现拥塞的条件:
对于资源需求的总和>可用资源
这里的资源指的是:链路的容量(带宽)等,很多人都在链路上传输数据,那么链路上的可用空间就很少
网络中有许多资源同时是呈现供应不足---->网络性能变坏----->网络吞吐量将随输入负荷增大而增大
拥塞控制:
防止过多的数据注入带网络.(是一个全局性的控制)
这里就会发现流量控制和拥塞控制都是使发放方发送少量的数据,那么它们两者有什么区别*
| 用图形象化表示拥塞控制和流量控制 |
|---|
 |
在拥塞控制(左图):
- 在接收方察觉到拥塞的情况时,并不能知道拥塞是那台主机发送数据过多导致的(全局性)
- 拥塞控制是,发送方发送的数据由于拥塞而不能到达接收方
流量控制(右图):
- 流量控制是一种点对点的流量控制,能够接收方的数据来不及接受,那么它能知道是那个主机发送数据过多或过快导致的
- 流量控制是,发送方发送的数据过多或者过快,接收方的接收缓存或者接收窗口不够,来不及接收
拥塞控制四种算法
- 慢开始
- 拥塞避免
- 快重传
- 快恢复
研究这几个算法,为了研究方便我们假定一些事实:
- 数据单方向传送,而另一方向只传送确认(不是捎带确认方式)
- 接收方总是有足够大的缓存空间,因而发送窗口大小取决于拥塞控制(忽略了流量控制)
- 发送窗口=Min{接口窗口rwnd,拥塞窗口cwnd}
- 接收窗口:接收方根据接收缓存设置的值,并告知给发送方,反映接收方容量
- 拥塞窗口:发送方根据自己估算的网络拥塞程度而设置的窗口值,反映网络当前容量
慢开始和拥塞避免
| 慢开始和拥塞避免 |
|---|
 |
- 初始时的步骤是:先指数规律增长(一个传播轮次增长2倍的报文段数量),直到达到初始的门限值,然后拥塞避免(进行加法增长,每个传播轮次增加一个报文段),然后检测出了网络拥塞
- 第二阶段:网络拥塞后立即将要传输的报文段的数量设置为cwnd的初始值1(也就是传输的报文段是1个),然后开始指数规律增长直到达到新的门限值(新的门限值在网络拥塞时确定,就是上一个网络拥塞时传输的最大报文段数量的一半),然后加法增长…
快重传和快恢复
| 快重传和快恢复 |
|---|
 |
个),然后开始指数规律增长直到达到新的门限值(新的门限值在网络拥塞时确定,就是上一个网络拥塞时传输的最大报文段数量的一半),然后加法增长…
快重传和快恢复
| 快重传和快恢复 |
|---|
|
我是雷雨佳,一个
普本科的学生,主要专注于Java后端和大数据开发,如果这篇文章有帮助到你,希望你给我一个大大的赞,如果有什么问题,希望你能留言和我一起研究,学习靠自觉,分享靠自愿