计算机网络笔记—传输层

传输层的两个协议

比较项目 TCP(Transmission Control Protocol)传输控制协议 UDP(User Data Protocol)用户数据报协议
是否分段 需要将要传输的文件分段 文件不需要分段
数据报数目 多个 一个
是否建立会话
是否流量传输
是否可靠传输
典型应用场景 打开网页,电子邮件,不提供广播和多播服务 QQ文字聊天、屏幕广播、域名解析DNS

传输层与应用层的关系

  • 标识应用程序

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rvKuYPax-1582261624081)(D:\Typora\images\1582174318490.png)]

常见的应用层协议使用的端口

协议名称 使用端口
HTTP TCP + 80端口
HTTPS TCP + 443端口
RDP TCP + 3389端口
FTP TCP + 21端口
共享文件夹 TCP + 445端口
SMTP(发邮件) TCP + 25端口
POP3(收邮件) TCP + 110端口
TELNET TCP + 23端口
SQL TCP + 1433端口
DNS(域名解析) UDP + 53端口

服务与应用层之间的关系(端口与安全)

  • 服务使用TCP或UDP的端口侦听客户端请求
  • 客户端使用IP地址定位服务器,使用目标端口定位服务器上的哪一个服务
  • 可以在服务器网卡上设置 只开放必要的端口,实现服务器的网络安全

如何在Windows上安装服务

如何查看服务侦听的端口

  • cmd下 netstat -an
  • netstat -n 查看建立的会话
  • netstat -nb 查看建立会话的进程
  • telnet 192.168.80.100 3389 测试到远程计算机的3389端口是否打开

如何更改服务使用的默认端口

  • 迷惑入侵者,使系统更加安全

如何设置Windows网络安全

  • 设置本地连接,TCP/IP筛选

传输层的功能

  • 传输层为应用进程之间提供端到端的逻辑通信(但网络层是为主机之间提供逻辑通信)
  • 传输层还要对收到的报文进行差错检测
  • 传输层提供面向连接的TCP协议和无连接的UDP协议

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8WMcIQ3I-1582261624083)(D:\Typora\images\1582177663827.png)]

传输层的端口

  • TCP协议号:6
  • UDP协议号:17
  • IGMP协议号:1

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uAzMpuH5-1582261624084)(D:\Typora\images\1582177882560.png)]

TCP的端口

  • 端口用一个16位端口号进行标志(0~65535)
  • 端口号只具有本地意义,即端口号只是为了标志本计算机应用层中的各进程。在因特网中不同计算机的相同端口号使没有联系的

端口的三种类型

  • 熟知端口,数值一般为0~1023
    • FTP:21
    • TELNET:23
    • SMTP:25
    • DNS:53
    • HTTP:80
    • https:443
    • RDP:3389
  • 登记端口,数值为1024~49151
  • 客户端口,数值为49152~65535

用户数据报协议UDP

UDP的主要特点

  • UDP是无连接的,即发送数据前不需要建立连接
  • UDP尽最大努力交付,即不保证可靠交付,同时也不使用拥塞控制
  • UDP是面向报文的。UDP没有拥塞控制,很适合多媒体通信的要求
  • UDP支持一对一、一对多、多对一和多对多的交互通信
  • UDP的首部开销很小,只有8个字节

面向报文的UDP

  • 发送方UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。UDP对应用层交付下来的报文,既不合并,也不拆分,而是保留这些报文的边界
  • 应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文
  • 接收方UDP对IP层交上来的UDP用户数据报,在去除首部后就原封不动地交付上层的应用进程,一次交付一个完整地报文
  • 应用程序必须选择合适大小的报文

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VrpmqFGS-1582261624085)(D:\Typora\images\1582179251429.png)]

UDP的首部格式(8个字节)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KHQYzT1F-1582261624086)(D:\Typora\images\1582179285406.png)]

传输控制协议TCP

TCP的主要特点

  • TCP是面向连接的传输层协议(在传数据之前要先确保连接是通的)
  • 每一条TCP连接只能有两个断点(endpoint),每一条TCP连接只能是点对点的(一对一)
  • TCP提供可靠交付的服务
  • TCP提供全双工通信(接收方要有回应)
  • TCP面向字节流

TCP的连接

  • TCP把连接作为最基本的抽象
  • 每条TCP连接有两个端点
  • TCP连接的端点不是主机,不是主机的连接地址,不是应用进程,也不是传输层的协议端口。TCP连接的端点叫做套接字(socket)
  • 端口号拼接到IP地址即构成了套接字,即套接字socket = (IP地址:端口号)
  • 每一条TCP连接唯一地被通信两端的两个套接字所确定

TCP如何实现可靠传输

可靠传输的工作原理——停止等待协议

无差错情况与超时重传

  • 发送之后发送端一定要收到接收端的确认才发送之后的数据报
  • 否则等待,直至超时重传
  • 注意:
    • 在发送完一个分组后,必须暂时保留已发送的分组的副本
    • 分组和确认分组都必须进行编号
    • 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uPECna5h-1582261624087)(D:\Typora\images\1582182488297.png)]

确认丢失和确认迟到

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-F5mUstBX-1582261624088)(D:\Typora\images\1582182736196.png)]

自动重传请求ARQ(Automatic Repeat reQuest)

  • 使用上述确认和重传机制,我们就可以实现在不可靠的传输网络上实现可靠的通信
  • 这种可靠传输协议常称为自动重传请求ARQ
  • ARQ表明重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组

信道利用率

  • 停止等待协议的优点是简单,但是缺点是信道利用率太低

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rA0ql8e5-1582261624088)(D:\Typora\images\1582183301305.png)]

  • 信道的利用率U
    U = T D T D + R T T + T A U= \frac{T_D}{T_D+RTT+T_A}

提高信道利用率的方法——流水线传输

  • 发送方可连续发送多个分组,不必每发完一个分组就停顿下来等待对方的确认。
  • 由于信道上一直有数据不间断地传送,这种传输方式可以获得很高的信道利用率

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CKfbEIhg-1582261624089)(D:\Typora\images\1582183603955.png)]

连续ARQ协议——使用滑动窗口技术

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-P10XX8FV-1582261624089)(D:\Typora\images\1582183763192.png)]

发送方发送窗口
  • 位于发送窗口内的5个分组都可以连续发送出去,而不需要等待对方的确认。这样,信道利用率就提高了
  • 发送方每收到一个确认,就把发送窗口向前滑动一个分组的位置
接收方累计确认
  • 接收方不必对收到的分组逐个发送确认,而是对按序到达的最后一个分组发送确认,这样就表示:到这个分组为止的所有分组都已正确收到了
  • 累计确认的优点是:容易实现,即使确认丢失也不必重传
回退N
  • 其缺点是:不能向发送方反映出接收方已经正确收到所有分组的信息
    • 例如,如果发送方发送了前5个分组,而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落,而只好把后面的三个分组都再重传一次(Go-back-N,回退N,表示需要再退回来重传已经发送过的N个分组)
    • 可见当通信线路质量不好时,连续ARQ协议会带来负面的影响

TCP报文段的首部格式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sJg605VB-1582261624090)(D:\Typora\images\1582184698690.png)]

字段 位数 意义
源端口和目的端口 各占2字节 端口是运输层与应用层的服务接口。运用层的复用和分用功能都要通过端口才能实现
序号 4字节 TCP连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号
确认号 4字节 期望收到对方的下一个报文段的数据的第一个字节的序号
数据偏移(首部长度) 4位 它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。“数据偏移”的单位是32位字(以4字节为计算单位),它有4位,最大对应十进制为1,对应首部最长是60字节
保留字段 6位 保留为今后使用,但目前应置为0
紧急URG 1位 当URG=1时,表明紧急指针字段有效。它告诉系统此报文段中有紧急数据,应尽快传送(高优先级)
确认ACK 1位 只有当ACK=1时确认号字段才有效。当ACK=0时,确认号无效
推送PSH 1位 接收TCP收到PSH=1的报文段,就尽快地交付接收应用进程,而不再等到整个缓存都填充慢了后再向上交付
复位RST 1位 当RST=1时,表明TCP连接中出现严重差错(如主机崩溃),必须释放连接,然后再重新建立运输连接
同步SYN 1位 同步SYN=1表示这是一个连接请求或连接接受报文(此时ACK=0,发送回来后确认号置为1,ACK=1,序号=0)
终止FIN 1位 用来释放一个连接。FIN=1表明此报文段的发送端的数据已发送完毕,并要求释放运输连接
窗口 2字节 用来让对方设置发送窗口的依据
检验和 2字节 检验和字段检验的范围包括首部和数据这两部分。在计算检验和时,要在TCP报文段的前面加上12字节的伪首部
紧急指针 2字节 指出在本报文段中紧急数据一共有多少个字节(紧急数据放在本报文段的最前面)
选项 长度可变 TCP最初只规定了一种选项,即最大报文长度(MSS),只TCP报文段中的数据字段的最大长度;其他选项还有:窗口扩大选项(3字节)、时间戳选项(10字节),选择确认选项
填充 4n字节 这是为了使整个首部长度是4字节的整数倍

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-A1RLftBS-1582261624090)(D:\Typora\images\1582188176878.png)]

TCP可靠传输的具体实现

以字节为单位的滑动窗口技术

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-n8dfetg8-1582261624092)(D:\Typora\images\1582193560208.png)][外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZTe7ExrF-1582261624092)(D:\Typora\images\1582193576209.png)][外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vxLbJfUI-1582261624093)(D:\Typora\images\1582193650673.png)][外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zPnCGVru-1582261624093)(D:\Typora\images\1582193736045.png)][外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fyJHy9s3-1582261624094)(D:\Typora\images\1582193756054.png)][外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ttCLk4aQ-1582261624094)(D:\Typora\images\1582193767966.png)]

发送窗口与接收窗口

  • A的发送窗口并不总是和B的接收窗口一样大,因为有一定的时间滞后
  • TCP标准没有规定对不按序到达的数据应该如何处理。通常是先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程
  • TCP要求接收方必须有累计确认的功能,这样可以减小传输开销

发送缓存与接收缓存

  • 发送缓存用来暂时存放:
    • 发送应用程序传送给发送方TCP准备发送的数据
    • TCP已发送但尚未收到确认的数据
  • 接收缓存用来暂时存放:
    • 按序到达的、但尚未被接收应用程序读取的数据
    • 不按序到达的数据

超时重传时间

  • 重传机制是TCP中最重要和最复杂的问题之一
  • TCP每发送一个报文段,就对这个报文段设置一次计时器。只要计时器设置的重传时间到但是还没有收到确认,就要重传这一报文段
  • 由于TCP的下层是一个互联网环境,IP数据报所选择的路由变化很大。因而传输层的往返时间RTT的方差也很大
  • 超时重传时间应略大于加权平均往返时间RTTs

选择确认SACK(Selective ACK)

  • 接收方收到了和前面的字节流不连续的两个字节块
  • 如果这些字节的序号都在接收窗口之内,那么接收方就先收下这些数据,但要把这些信息准确地告诉发送方,使发送方不要再重复地发送这些已经收到的数据
  • 如果要使用选择确认,那么在建立TCP连接时,就要在TCP首部的选项中加上“允许SACK”的选项,而且双方必须都事先商定好

TCP的流量控制

利用滑动窗口实现流量控制

  • 一般来说,我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快,接受方就可能来不及接收,这就会造成数据的丢失
  • 流量控制就是让发送方的发送速率不要太快,既要让接收方来得及接收,也不要使网络发生拥塞
  • 利用滑动窗口机制可以很方便地在TCP连接上实现流量控制

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bNnIVoUX-1582261624095)(D:\Typora\images\1582199539997.png)]

  • 发送方的发送窗口不能超过接收方给出的接收窗口的数值
  • 在上述示例中,接收方的主机B进行了三次流量控制。第一次把窗口减小到了rwnd = 300,第二次又减到rwnd = 100,最后见到rwnd = 0,即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口为止。
  • B向A发送的三个报文段都设置了ACK=1,只有在ACK=1时确认号字段才有意义

零窗口探测报

  • 当B的数据报丢失时,A将一直等待收到B发送的非零窗口的通知,而B也一直等待A发送数据,如果没有其他措施,这种互相等待的死锁局面将一直延续下去
  • 为了解决这个问题,TCP为每一个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器。若持续计时器设置的时间到期,就发送一个零窗口探测报文段,而对方就在确认这个探测报文段时给出仙现在的窗口值

必须考虑传输效率

  • 第一种机制是TCP维持一个变量,它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS字节时,就组装成一个TCP报文段发送出去
  • 第二种机制是由发送方的应用进程指明要求发送报文段,即TCP支持的推送(push)操作
  • 第三种机制是发送方的一个计时器期限到了,这是就把当前已有的缓存数据装入报文段(但长度不能超过MSS)发送出去

TCP的拥塞控制

拥塞

  • 在某段时间,若对网络中某资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏——产生拥塞
  • 出现资源拥塞的条件:对资源需求的综合 > 可用资源
  • 若网络中有许多资源同时产生拥塞,网络的性能就要明显变坏,整个网络的吞吐量将随输入负荷的增大而下降

拥塞控制与流量控制的关系

  • 拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷
  • 拥塞控制是一个全局性的过程,涉及到所有的主机、所有的路由器,以及与降低网络传输性能有关的所有因素
  • 流量控制往往指在给定的发送端和接收端之间的点对点通信量的控制
  • 流量控制所要做的是抑制发送端发送数据的速率,以便使接收端来得及接收

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IiVYyJKt-1582261624096)(D:\Typora\images\1582201402616.png)]

拥塞控制的一般原理

  • 拥塞控制使很难设计的,因为它是一个动态的问题
  • 当前网络正朝着高速化的方向发展,这很容易出现缓存不够大造成分组的丢失
  • 但分组的丢失是网络发生拥塞的征兆而不是原因

控制方法

慢开始和拥塞避免

  • 发送方维持一个叫作拥塞窗口cwnd(congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度,并且动态地在变化
  • 发送方控制拥塞窗口的原则是:只要网络没有出现拥塞,拥塞窗口就再增大一些,以便把更多的分组发送出去。但只要网络出现拥塞,拥塞窗口就减小一些,以减少注入到网络中的分组数
  • 设置了慢开始门限状态变量ssthresh,用来判定是使用慢开始算法还是使用拥塞避免算法

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hEVVsAmL-1582261624096)(D:\Typora\images\1582204883663.png)]

  • 无论是在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(其根据就似乎没有按时收到确认),就要把慢开始门限ssthresh设置为出现拥塞时发送方窗口值的一半。这样做的目的就是要迅速减少主机发送到网络中的分组数,使得发生拥塞的路由器有足够时间把队列中积压得分组处理完毕
  • “拥塞避免”并非指完全能够避免了拥塞。“拥塞避免”是说在拥塞避免阶段把拥塞窗口控制为按线性规律增长,使网络3比较不容易出现拥塞

快重传和快恢复

  • 采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失
  • 快重传算法受限要求接收方每收到一个失序的一个报文段后就立即发出重复确认。这样做可以让发送方及早知道有报文段没有到达接收方
  • 发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段
  • 不难看出,快重传并非取消重传计时器,而是在某些情况下可以更早地重传丢失的报文段

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uqTgibKF-1582261624097)(D:\Typora\images\1582205549279.png)]

  • 当发送端收到连续三个重复的确认时,就执行“乘法减小”算法,把慢开始门限ssthresh减半。但接下来不执行慢开始算法
  • 由于发送方现在认为网络很可能没有发生拥塞,因此现在不执行慢开始算法,而是设置为慢开始门限ssthresh减半后的数值,然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性增大

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rABVseqi-1582261624097)(D:\Typora\images\1582205761520.png)]

发送窗口的限制

  • 发送方的发送窗口的上限值应当取为接收方窗口rwnd和拥塞窗口cwnd这两个变量中较小的一个
    • 当rwnd < cwnd时,是接收方的接受能力限制发送方窗口的最大值
    • 当rwnd > cwnd时,是网络的拥塞程度限制发送方窗口的最大值
  • 也就是说,rwnd和cwnd中数值较小的一个,控制了发送方发送数据的速率

主动队列管理AQM——避免网络中的全局同步现象

路由器对某些分组的处理时间很长
发送方对这些报文的重传
发送端采取拥塞控制措施
路由器分组丢弃,同时影响到很多TCP连接
许多TCP连接在统一时间突然都进入到慢开始状态
全局同步现象
  • 为了避免发生网络中的全局同步现象,提出了主动队列管理AQM(Active Queue Management)。所谓“主动”就是不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组,而是应当在队列长度达到某个值得警惕的数值时就主动丢弃到达的分组
随机早期检测RED(Random Early Detection)
  • RED不是等到已经发生网络拥塞以后才把所有在队列尾部的分组全部丢弃,而是在检测到网络拥塞的早期征兆时,就以概率p丢弃个别的分组,让拥塞控制只在个别的TCP连接上进行,因而避免发生全局性的拥塞控制

TCP的传输连接管理

  • 传输连接有三个阶段,即:连接建立、数据传送和连接释放
  • TCP连接的建立都是采用客户服务器方式
  • 主动发起连接建立的用户进程叫作客户client,被动等待连接建立的应用进程叫作服务器server

连接建立过程中要解决的三个问题

  1. 要使每一方能够确知对方的存在
  2. 要允许双方协调一些参数(如最大报文段长度、最大窗口大小、服务质量等)
  3. 能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配

用三报文握手(三次握手)建立TCP连接

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MTlUBfqR-1582261624098)(D:\Typora\images\1582207671816.png)]

  1. A的TCP向B发出连接请求报文段,其首部中的同步位SYN=1,并选择序号seq=x,表明传送数据时的第一个数据字节的序号是x
  2. B的TCP收到来连接请求报文后,如同意,则发回确认。B在确认报文段中应使SYN=1,ACK=1,其确认号ack=x+1,自己选择的序号seq=y
  3. A收到此报文段后向B给出确认,其ACK=1,确认号ack=y+1。A的TCP通知上层应用进程,连接已经建立。B的TCP收到主机A的确认后,也通知其上层应用进程:TCP连接已经建立

为什么要有第三次握手(最后还要发送一次确认)

  • 这主要是为了防止已失效的连接请求报文段突然又传送到了B,因而产生错误
    • A发出的第一个连接请求报文段并没有丢失,而是在某些网络结点长时间滞留了,以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段,但B收到此失效的连接请求报文段后,就误以为A又发出了一次新的连接请求。于是就向A发出确认报文段,同意建立连接。由于现在A并没有发出建立连接的请求,因此不会理睬B的确认,也不会向B发送数据。但B却一位新的运输连接已经建立了,并一直等待A发来数据。B的许多资源就这样白白浪费了
    • 采用三报文握手的方法,可以防止上述现象的发生。例如在刚才的异常情况下,A不会向B的确认发出确认。B由于收不到确认,就知道A并没有要求建立连接

用四报文握手(四次挥手)释放TCP连接

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-717k96JB-1582261624098)(D:\Typora\images\1582209662080.png)]

  1. A的应用进程先向其TCP发出连接释放报文段,并停止再发送数据,主动关闭TCP连接。A把连接释放报文段的首部的FIN=1,其序号seq=u,等待B的确认
  2. B发出确认,确认号ack=u+1,而这个报文段自己的序号seq=v。TCP服务器进程通知高层应用进程。从A到B这个方向的连接就释放了,TCP连接处于半关闭状态。B若发送数据,A仍要接收
  3. 若B已经没有要向A发送的数据,其应用进程就通知TCP释放连接。其FIN=1,ACK=1,序号seq=w,确认号ack=u+1
  4. A收到连接释放报文段后,必须发出确认。在确认报文段中ACK=1,确认号ack=w+1,自己的序号seq=u+1。A的TCP连接必须经过时间2MSL(最长报文段寿命Maximum Segment Lifetime)后才真正释放掉

为什么A在TIME-WAIT状态下必须要等待2MSL的时间?

  1. 为了保证A发送的最后一个ACK报文段能够到达B
  2. 防止“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后,再经过时间2MSL,就i可以使本连接持续的时间内所产生的所有报文段,都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段

TCP的有限状态机

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TmwsOg1P-1582261624099)(D:\Typora\images\1582210747570.png)]

发布了70 篇原创文章 · 获赞 7 · 访问量 4565

猜你喜欢

转载自blog.csdn.net/Felix_hyfy/article/details/104426214