计算机网路——运输层

文章目录

一. OSI和DoD模型

在这里插入图片描述

二. 运输层的概述

实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程
如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务

2.1 进程之间的通信

从通信和信息处理的角度看,运输层向它上面的应用层提供端到端的通信服务,它属于面向通信部分的最高层,同时也是用户功能中的最低层。
在这里插入图片描述

2.1.1 运输层为相互通信的应用进程提供了逻辑通信

位于网络边缘部分的两台主机使用网络核心部分的功能进行端到端的通信时,只有主机的协议栈才有运输层,核心部分的路由器只有三层

在这里插入图片描述
在这里插入图片描述

2.1.2 应用进程之间的通信的特点

  • 两个主机进行通信实际上就是两个主机中的应用进程互相通信。

  • 应用进程之间的通信又称为端到端的通信。

  • 运输层的一个很重要的功能就是复用和分用。应用层不同进程的报文通过不同的端口向下交到运输层,再往下就共用网络层提供的服务。

      复用:指发送方不同的应用进程可以使用同一个运输层协议传送数据
      分用:接收方的运输层在剥去报文的首部后能够把这些数据正确交付到目的应用程序
    
  • “运输层提供应用进程间的逻辑通信”。“逻辑通信”的意思是:运输层之间的通信好像是沿水平方向传送数据。但事实上这两个运输层之间并没有一条水平方向的物理连接。

2.1.3 运输层协议和网络层协议的主要区别

在这里插入图片描述

2.1.4 运输层的主要功能

  • 运输层为应用进程之间提供端到端的逻辑通信(但网络层是为主机之间提供逻辑通信)。
  • 运输层还要对收到的报文进行差错检测。
  • 运输层可选的功能:可靠数据传输、流量控制、拥塞控制

2.2 因特网的运输层协议

在这里插入图片描述

2.2.1 运输层两种协议的来源

因特网的网络层为主机提供逻辑通信服务,是一种尽最大努力交付的数据报服务,在IP报文传输过程可能有差错、丢失、失序等,这些对于电子邮件,文件传输,万维网等很多应用,数据的丢失可能造成灾难性后果,所以运输层必须提供可靠的数据传输服务

但是,对于实时的音频,他们可以承受一定程度损失,如果仍然使用可靠传输这个复制的机制,可能会带来一些不利的因素

总结 :运输层不断要提供可靠的传输服务,也要提供高速的具有少量不可靠的传输服务

2.2.2 传输层两个协议

在这里插入图片描述
两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元TPDU (Transport Protocol Data Unit)。
在因特网上:

  • TCP 传送的协议数据单元称为 TCP 报文段(segment)
  • UDP 传送的协议数据单元称为 UDP 报文或用户数据报。

传输层最大数据包是65535字节,而数据链路层数据最大只有1480字节。所以需要分段,但是只要分段,就有可能丢包,因为网络层不负责可靠传输。所以要求服务器和客户端保持会话,直到数据传输完成。

1. TCP(Transmission Control Protocol)传输控制协议

特点:
TCP 则提供面向连接的服务。TCP 不提供广播或多播服务。由于 TCP 要提供可靠的、面向连接的运输服务,因此不可避免地增加了许多的开销。这不仅使协议数据单元的首部增大很多,还要占用许多的处理机资源。

应用场景:
需要将要传输的文件分段传输时;就需要TCP协议来建立会话实现可靠传输;同时也有流量控制功能。

(例如QQ传文件)
2. UDP(User Data Protocol)用户数据报协议

特点:
UDP 在传送数据之前不需要先建立连接。对方的运输层在收到 UDP 报文后,不需要给出任何确认。虽然 UDP 不提供可靠交付,但在某些情况下 UDP 是一种最有效的工作方式。

应用场景:
一个数据包就能完成数据通信;不需要建立会话和流量控制;屏幕广播/多播;是一种不可靠传输。

(例如QQ聊天,屏幕广播)

2.3 使用UPD和TCP协议的各种应用和应用层协议

在这里插入图片描述

2.4 传输层协议和应用层协议的关系

  • 运输层的 UDP 用户数据报与网际层的IP数据报有很大区别。IP 数据报要经过互连网中许多路由器的存储转发,但 UDP 用户数据报是在运输层的端到端抽象的逻辑信道中传送的。
  • TCP 报文段是在运输层抽象的端到端逻辑信道中传送,这种信道是可靠的全双工信道。但这样的信道却不知道究竟经过了哪些路由器,而这些路由器也根本不知道上面的运输层是否建立了 TCP 连接。

在这里插入图片描述

(1) TCP和UDP协议和不同的端口即可对应一个应用层的协议。注意,53大部分是与UDP相连。

(2) 熟知数值一般为0-1023,登记端口号数值1024-49151,客户端口号数值为49152-65535.

(3) 常用的应用层协议使用的端口(号):

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
(注意与4.6 的协议号的区别)

2.5 服务和应用层协议的关系

防火墙是基于网卡的,只打开必要的端口,不必要的端口不允许接收数据,不影响服务的运行和监听。

服务使用TCP或UDP的端口侦听客户端请求,服务必须是启动状态,它才侦听客户端的请求

客户端使用IP地址定位服务器,使用目标端口,定位服务;
可以在服务器网卡上设置只开放必要的端口,实现服务器网络安全。

2.6 如何在Windows上安装服务

DNS服务
Web服务
SMTP //发邮件
POP3 //收邮件

2.7 如何查看服务侦听的端口

netstat -a
netstat -an 以数字的形式查看端口
netstat -n 查看建立的会话
netstat -nb 查看建立会话的进程
telnet 192.168.80.100 3389 测试到远程计算机某个端口是否打开

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

可以迷惑入侵者,使系统更加安全。
改完端口之后,入侵者就不知道你这个端口代表什么服务了

2.9 如何设置Windows网络安全

设置本地连接 TCP/IP筛选
在这里插入图片描述
在这里插入图片描述

2.10 运输层一些基本概念

2.10.1 运输层的复用与分用

  • 复用是指在发送方不同的应用进程都可以使用同一个运输层协议传送数据(当然需要加上适当的首部);
  • 而分用是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付到目的应用进程。
  • 要能正确地将数据交付给指定应用进程,就必须给每个应用进程赋予一个明确的标志。
  • 在TCP/IP网络中,使用一种与操作系统无关的协议端口号(protocol port number)(简称端口号)来实现对通信的应用进程的标志。

2.10.2 运输层端口的概念

  • 端口就是应用进程的运输层地址。
  • 端口的作用就是让应用层的各种应用进程都能将其数据通过端口向下交付给运输层,以及让运输层知道应当将其报文段中的数据向上通过端口交付给应用层相应的进程。
  • 从这个意义上讲,端口是用来标志应用层的进程。

2.10.3 端口在进程之间的通信中所起的作用

在这里插入图片描述
在这里插入图片描述

  • 端口用一个 16 位端口号进行标志。
  • 端口号只具有本地意义,即端口号只是为了标志本计算机应用层中的各进程。在因特网中不同计算机的相同端口号是没有联系的。
  • 并且TCP和UDP端口号之间也没有必然联系

2.10.4 运输层端口的分类

  • 熟知端口 其数值一般为 0~1023。当一种新的应用程序出现时,必须为它指派一个熟知端口。
    在这里插入图片描述

  • 登记端口 其数值为 1024~49151。这类端口是 ICANN 控制的,使用这个范围的端口必须在 ICANN 登记,以防止重复。

  • 动态端口 其数值为 49152~65535。这类端口是留给客户进程选择作为临时端口。

在这里插入图片描述

三. 传输层中用户数据报协议(UDP)

1. UDP协议概述

  • UDP 只在 IP 的数据报服务之上增加了很少一点的功能,即端口的功能和差错检测的功能。
  • 虽然 UDP 用户数据报只能提供不可靠的交付,但 UDP 在某些方面有其特殊的优点

1.1 主要特点

(1) UDP是无连接的,即发送数据之前不需要建立连接。

当然发送数据结束时也没有连接可释放,因此减少了开销和发送数据之前的时延。

(2) UDP使用尽最大努力交付,即不保证可靠交付,同时也不使用拥塞控制。

因此主机不需要维持具有许多参数的、复杂的连接状态表

(3) UDP是面向报文的,UDP没有拥塞控制,适合多媒体通信的要求。

因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。

很多的实时应用(如 IP 电话、实时视频会议等)要求源主机以恒定的速率发送数据,
并且允许在网络发生拥塞时丢失一些数据,但却不允许数据有太大的时延。

UDP 对应用程序交下来的报文不再划分为若干个分组来发送,也不把收到的若干个报文合并后再交付给应用程序。

应用程序交给 UDP 一个报文,UDP 就发送这个报文;而 UDP 收到一个报文,就把它交付给应用程序。
应用程序必须选择合适大小的报文。

(4) UDP支持一对一,一对多,多对一,多对多交互通信。

(5) UDP首部开销小,只有8个字节。

1.2 UPD的缺点

  • 虽然某些实时应用需要使用没有拥塞控制的 UDP,但当很多的源主机同时都向网络发送高速率的实时视频流时,网络就有可能发生拥塞,结果大家都无法正常接收。

  • 还有一些使用 UDP 的实时应用需要对UDP 的不可靠的传输进行适当的改进以减少数据的丢失。

2. UDP报文的首部格式

在这里插入图片描述
在这里插入图片描述
首部中的长度指的是UDP用户数据报的长度(首部+数据)。

计算UDP检验和的例子:
在这里插入图片描述

3. UDP的多路分用模型

在这里插入图片描述

4. 套接字(Socket)地址

UPD报文首部中最重要的字段就是源端口和目的端口,他们用来标识UDP发送方和接收方。

实际上,UPD通过二元组(目的IP地址,目的端口号)来定位一个接受方应用进程,
而用二元组(源IP地址,源端口号)来标识一个发送方进程

二元组(IP地址,端口号)被称为套接字(socket)地址

四. 传输层的传输控制协议(TCP)

4.1 TCP协议概述

4.1.1 TCP 的主要特点

(1) TCP是面向连接的传输层协议。(三次握手)

(2) 每一条TCP连接只能有两个端点(endpoint),每一条TCP连接只能是点对点的(一对一)。

(3) TCP提供可靠交付的服务。(确保不丢包)

(4) TCP提供全双工通信。(因为需要接收端的反馈,例如如果接收端处理不过来,可让发送端慢一点,流量控制)

TCP 连接的任何一方都能够发送和接收数据

	通信是全双工方式。
		三次握手建立连接后,发送方每发送一个TCP报文,接收方都回复一下收到,并要求发送方发送下一个TCP报文
	
	发送方的应用进程按照自己产生数据的规律,不断地把数据块陆续写入到 TCP 的发送缓存中。
	TCP 再从发送缓存中取出一定数量的数据,将其组成 TCP 报文段(segment)逐个传送给 IP 层,然后发送出去。

	接收方从 IP 层收到 TCP 报文段后,先把它暂存在接收缓存中,
	然后让接收方的应用进程从接收缓存中将数据块逐个读取。 

(5) 面向字节流。

TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流

注意事项:

1. TCP 连接是一条虚连接而不是一条真正的物理连接。

2. TCP 对应用进程一次把多长的报文发送到TCP 的缓存中是不关心的。

3. TCP 根据网络的具体情况来决定一个报文段应包含多少个字节(UDP 发送的报文长度是应用进程给出的)。

4. TCP 可把太长的数据块划分短一些再传送。TCP 也可等待积累有足够多的字节后再构成报文段发送出去。 

4.1.2 TCP 面向流的概念

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
如果要传输一个比较大的数据,首先一次只会传输一小块,这个数据块的大小是没有规律的。加上数据包数据帧的头,发送给接收端,接收端去掉首部,再次拼接。

4.1.3 TCP 的连接

(1) TCP把连接作为最基本的抽象。

(2) 每一条 TCP 连接唯一地被通信两端的两个端点所确定
在这里插入图片描述

(3) TCP连接的端点不是主机,不是主机的IP地址,不是应用程序,也不是传输层协议端口,TCP连接的端点叫 套接字(socket).

套接字socket = (IP地址:端口号)

每一条TCP连接唯一地被通信两端的两个套接字所确定,即:
TCP连接 ::= {socket1, socket2} = {(IP1:port1), (IP2:port2)}

(4) 端口号拼接到IP地址即构成了套接字。

4.2 TCP报文段的格式

4.2.1 TCP报文段的特点

  • TCP 报文段分为首部和数据两部分。

      TCP虽然是面向字节流的,但TCP传送的数据单元却是报文段
    
  • TCP 的全部功能都体现在它首部中各字段的作用。

  • TCP 报文段首部的前 20个 字节是固定的,后面有 4N 字节是根据需要而增加的选项(N 必须是整数)。因此 TCP 首部的最小长度是 20 字节。

4.2.2 TCP报文段的首部格式

在这里插入图片描述
(1) 源端口:2个字节16位。

(2) 目的端口:2个字节16位。

端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。  

(3) 序号(seq):当前数据的第一个字节在整个文件中的序号。

TCP 连接中传送的数据流中的每一个字节都编上一个序号。

序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。 

(4) 确认号ack:接收端发送,提示发送端下一次该发的数据在整个文件中的序号。接收端收到后,会把这个序号之前的数据从缓存中删掉。

(5) 数据偏移:当前TCP报文段第多少个字节后是TCP的数据部分了。数据偏移最多表示1111,即15(因为是以4字节为单位),所以他最多可以表示15乘以4,即60个字节的偏移量(即TCP首部长度最大为60字节),所以选项+填充最多只能是40个字节。

表示:TCP报文段的数据起始处距离TCP报文段的起始处有多远,(也就是首部长度)

(6) 保留:6位,无作用。

(7) URG紧急位:urgent,意思是优先级高,发送端优先发送,而不是在缓存中排队。

(8) ACK确认位:acknowledge,1意味着确认建立了会话。

只有当 ACK = 1 时确认号字段才有效。当 ACK = 0 时,确认号无效。 

(9) PSH推送位:1意味着接收端优先读取,而不是在缓存中排队。

接收 TCP 收到 PSH = 1 的报文段,就尽快地交付给接收应用进程,
而不再等到整个缓存都填满了后再向上交付。  

(10) RST复位位:reset,1意味着TCP会话出现严重错误,必须释放和重新连接。

(11) SYN同步位:同步。1意味着要发起会话。

当 SYN = 1 时,表示这是一个连接请求或连接接受报文。 

(12) FIN终止位:finish,1意味着释放连接。

当 FIN=1 时,表明此报文段的发送方的数据已发送完毕,并要求释放运输连接。 

(13) 窗口:接收端先发,发送端根据接收端的窗口尺寸确定发送端窗口尺寸。

即现在允许对方发送的数据量

这里的窗口是接受方的窗口大小

(14) 检验和:校验范围是首部和数据两部分

在计算检验和时,要在 TCP 报文段的前面加上 12 字节的伪首部。

(15) 紧急指针:只有URG为1才有用。

紧急指针指出在本报文段中的紧急数据的最后一个字节的序号。  

(16) 选项:可以规定最大数据报(MSS)的长度,还可以判断是否支持选择性确认(SACK)

TCP 只规定了一种选项,即最大报文段长度 MSS (Maximum Segment Size)。

MSS 告诉对方 TCP:“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节 

(17) 填充字段:为了使整个首部长度是 4 字节的整数倍

2. 抓包分析TCP首部

在这里插入图片描述
第一个数据包
在这里插入图片描述
第二个数据包
在这里插入图片描述
第三个数据包
在这里插入图片描述
确认数据包
在这里插入图片描述

五. TCP的运输连接管理

传输连接有三个阶段,即:连接建立,数据传送,连接释放。

TCP连接的建立都是采用客户服务器方式。

主动发起连接建立的应用进程叫做客户(client)。
被动等待连接建立的应用进程叫做服务器(server)。

5.1 TCP连接建立的过程

使用三次握手建立
在这里插入图片描述
头两次握手除了确定双方都能联通外,还通知了双方的一些端口信息。
第三次握手原因:假如把三次握手改成仅需要两次握手,死锁是可能发生的。
作为例子,考虑计算机A和B之间的通信,假定A给B发送一个连接请求分组,B收到了这个分组,并发送了确认应答分组。按照两次握手的协定,B认为连接已经成功地建立了,可以开始发送数据分组。可是,B的应答分组在传输中被丢失的情况下,A将不知道B是否已准备好,A认为连接还未建立成功,将忽略B发来的任何数据分组,这样就形成了死锁。

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

缺点:
在这里插入图片描述

5.2 TCP的连接释放

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

六. TCP可靠传输的实现

6.1 概述

在这里插入图片描述

6.2 TCP实现可靠传输的机制

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

(1)可靠传输的工作原理——停止等待协议。
在这里插入图片描述

在发送完一个分组后,必须暂时保留已发送的分组的副本。
分组和确认分组都必须进行编号。
超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。

(2)确认丢失和确认迟到
在这里插入图片描述
(3)可靠通信的实现

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

停止等待协议缺点:信道利用率低。
停止等待协议优点:简单

  • 信道利用率
    在这里插入图片描述
    信道利用率U
    在这里插入图片描述
    如何提高利用率?
    进行流水线传输
    发送方可连续发送多个分组,不必每发完一个分组就停顿下来等待对方的确认。由于信道上一直有数据不间断的传送,这种传输方式可获得很高的信道利用率。
    在这里插入图片描述
    流水线传输可靠传输是如何进行确认的?
    使用连续ARQ协议
    在这里插入图片描述
    如果1确认收到了,则滑动窗口。
    在这里插入图片描述
    如果12收到了,3没有收到,则滑动窗口会会回溯到3位置,重新发送。

因为滑动窗口每一个数据包都要有一个确认,效率还是不高
我们使用:累计确认(接收方)提高效率

接收方一般采用累计确认的方式。
优点:容易实现,信道利用率高。
缺点:不能向发送方反映出接收方已经正确收到的所有分组的信息

6.3. 如何实现可靠传输->以字节为单位的滑动窗口技术

在这里插入图片描述
在这里插入图片描述
如果丢包了会进行SACK(选择性确认)
在这里插入图片描述

  • 超时重传时间的选择
    在这里插入图片描述

七. TCP如何实现流量控制

解决通信两端处理时间不一样的问题。通过实时调整滑窗尺寸的大小(尺寸甚至可以是0)来实现流量控制。接收端主动调整滑窗大小,发送端根据接收端发送的报文调整相应的滑窗。发送端也会定时发送报文向接收端确认滑窗信息,避免接收端发送的相关调整滑窗大小的报文丢失带来的影响。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

八. TCP如何避免网络拥塞

8.1 概述

(1)出现资源拥塞的条件:对资源需求的总和>可用资源。

(2)拥塞控制是一个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低网络传输性能有关的所有因素。

(3)流量控制往往指在给定的发送端和接收端之间的点对点通信量的控制,它所要做的就是抑制发送端发送数据的速率,以便使接收端来得及接收。

拥塞控制的目的:
防止过多的数据注入到网络中(全局性)

在这里插入图片描述

8.2. 拥塞控制起到的作用

红线和绿线之间是数据丢失内容。
在这里插入图片描述

8.3 拥塞控制的四种算法

在这里插入图片描述

8.4. 慢开始和拥塞避免

(1)发送方维持 拥塞窗口cwnd(congestion window)
(2)发送方控制拥塞窗口的原则是:
只要网络没有出现拥塞,拥塞窗口就再增大一些,以便把更多的分组发送出去;
只要网络出现拥塞,拥塞窗口就减少一些,以减少注入到网络中的分组数。
(3)慢开始算法的原理
在这里插入图片描述
(4)设置慢开始门限状态变量ssthresh
慢开始门限状态变量ssthresh的用法如下:
当cwnd<ssthresh时,使用慢开始算法;
当cwnd>ssthresh时,停止使用慢开始算法,改用拥塞避免算法;
当cwnd=ssthresh时,使用慢开始算法或拥塞避免算法均可;
(5)拥塞避免算法的思路
让拥塞窗口cwnd缓慢地增大,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍,使拥塞窗口cwnd按线性规律缓慢增长。
(6)当网络出现拥塞时对策
无论是在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(其根据就是没有按时收到确认),就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半(但是不能小于2)。
然后把拥塞窗口cwnd重新设置为1,执行慢开始算法。
这样做的目的就是要迅速减少主机发送到网络中的分组数,使得发生拥塞的路由器有足够的时间吧队列中积压的分组处理完毕。
(7)慢开始和拥塞避免算法的实现举例
在这里插入图片描述
必须强调指出:
拥塞避免并非指完全能够避免拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。
拥塞避免是说在拥塞避免阶段吧拥塞避免窗口控制为按线性规律增长,使网络比较不容易出现拥塞。

在这里插入图片描述

3. 快重传和快恢复

快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认,这样做可以让发送方及早知道有报文段没有到达接收方。
当发送端收到连续三个重复的确认时,就执行“乘法减少”算法,即把慢开始门限ssthresh减半,但拥塞窗口cwnd现在不设置为1,而是设置为慢开始门限ssthresh减半后的数值,然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性增大
在这里插入图片描述
在这里插入图片描述

3. 发送窗口的实际上限制

取接收方窗口和 拥塞窗口 这两个变量中的较小值,按以下公式确定。
发送窗口的上限制 = Min [rwnd, cwnd].

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值