计算机网络:运输层(概述,UDP,TCP,可靠传输)
本章主要介绍运输层的基本概念及其两大核心协议:UDP(用户数据报协议)和TCP(传输控制协议)。UDP是一种无连接的、不可靠的传输协议,适用于对时延敏感但可靠性要求不高的应用,如实时视频、在线游戏等。而TCP则是一种面向连接的、可靠的传输协议,通过三次握手建立连接,并采用确认机制、超时重传和流量控制等技术,保证数据的可靠传输。
1,运输层协议概述
1.1,进程之间的通信
从通信和信息处理的角度看,运输层向它上面的应用层提供通信服务,它属于面向通信部分的最高层,同时也是用户功能中的最低层。
当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时,只有位于网络边缘部分的主机的协议栈才有运输层,而网络核心部分中的路由器在转发分组时都只用到下三层(物理层,数据链路层,网络层)的功能。
网络层是为主机之间提供逻辑通信,而运输层为应用进程之间提供端到端的逻辑通信。在一台主机中经常有多个应用进程同时分别和另一台主机中的多个应用进程通信。这表明运输层有一个很重要的功能——复用和分用。
多路复用存在于发送方:发送方需要处理多个套接字,并且给套接字加上传输层的头部。
多路分用存在于接收方:利用头部信息,将接收到的报文段传输给正确的套接字。
1.2,面向连接和无连接
运输层需要有两种不同的运输协议,即面向连接的 TCP 和无连接的 UDP 。
- 面向连接:是指通信双方在通信时,要事先建立一条通信线路。其有三个过程:建立连接、使用连接和释放连接。
- 无连接:是指通信双方不需要事先建立一条通信线路,而是把每个带有目的地址的包(报文分组)送到线路上,由系统自主选定路线进行传输。
协议 TCP UDP 数据单元 TCP报文段 UDP报文或用户数据报 连接类型 面向连接协议 无连接协议 通信方式 一对一 一对一,一对多 传输顺序 保证 不保证 丢包重传 有 无 消耗资源 多(维护连接) 少 效率 低 高 特点 TCP 不提供广播或多播服务。 运输层在收到 UDP 报文后,不需要给出任何确认。 由于 TCP 要提供可靠的、面向连接的运输服务,因此不可避免地增加了许多的开销。这不仅使协议数据单元的首部增大很多,还要占用许多的处理机资源。 虽然 UDP 不提供可靠交付,但在某些情况下 UDP 是一种最有效的工作方式。(直播等)
1.3,运输层的端口
问题:运行在计算机中的进程是用进程标识符来标志的。但运行在应用层的各种应用进程却不应当让计算机操作系统指派它的进程标识符。这是因为在互联网上使用的计算机的操作系统种类很多,而不同的操作系统又使用不同格式的进程标识符。为了使运行不同操作系统的计算机的应用进程能够互相通信,就必须用统一的方法对 TCP/IP 体系的应用进程进行标志。
解决:解决这个问题的方法就是在运输层使用协议端口号,或通常简称为端口。虽然通信的终点是应用进程,但我们可以把端口想象是通信的终点,因为我们只要把要传送的报文交到目的主机的某一个合适的目的端口,剩下的工作(即最后交付目的进程)就由 TCP 来完成。
软件端口 硬件端口 协议栈层间的抽象的协议端口 路由器或交换机上的端口 软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。 硬件端口是不同硬件设备进行交互的接口
TCP/IP运输层端口
- 端口用一个 16 位端口号进行标志。
- 端口号只具有本地意义,即端口号只是为了标志本计算机应用层中的各进程。
- 在互联网中,不同计算机的相同端口号是没有联系的。
由此可见,两个计算机中的进程要互相通信,不仅必须知道对方的 IP 地址(为了找到对方的计算机),而且还要知道对方的端口号(为了找到对方计算机中的应用进程)。
服务器端使用的端口号 客户端使用的端口号 熟知端口,数值一般为 0~1023。 又称为短暂端口号,数值为 49152~65535,留给客户进程选择暂时使用。 登记端口号,数值为 1024~49151,为没有熟知端口号的应用程序使用的。使用这个范围的端口号必须在 IANA 登记,以防止重复。 当服务器进程收到客户进程的报文时,就知道了客户进程所使用的动态端口号。通信结束后,这个端口号可供其他客户进程以后使用。
2,用户数据报协议UDP
2.1,UDP概述
UDP只在IP的数据报服务之上增加了很少一点的功能:复用和分用的功能,差错检测的功能。虽然 UDP 用户数据报只能提供不可靠的交付,但 UDP 在某些方面有其特殊的优点。
UDP的主要特点
(1)UDP 是无连接的,发送数据之前不需要建立连接,因此减少了开销和发送数据之前的时延。
(2)UDP 使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的连接状态表。
(3)UDP 是面向报文的。UDP 对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。UDP 一次交付一个完整的报文。
(4)UDP 没有拥塞控制,因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很适合多媒体通信的要求。
(5)UDP 支持一对一、一对多、多对一和多对多的交互通信。
(6)UDP 的首部开销小,只有 8 个字节,比 TCP 的 20 个字节的首部要短。
面向报文的UDP:发送方 UDP 对应用程序交下来的报文,在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。应用层交给 UDP 多长的报文,UDP 就照样发送,即一次发送一个报文。
接收方 UDP 对 IP 层交上来的 UDP 用户数据报,在去除首部后就原封不动地交付上层的应用进程,一次交付一个完整的报文。应用程序必须选择合适大小的报文。
- 若报文太长,UDP 把它交给 IP 层后,IP 层在传送时可能要进行分片,这会降低 IP 层的效率。
- 若报文太短,UDP 把它交给 IP 层后,会使 IP 数据报的首部的相对长度太大,这也降低了 IP 层的效率。
2.2,UDP的首部格式
源端口 源端口号,在需要对方回信时选用,不需要时可全用0。 目的端口 目的端口号,这个在终点交付报文时必须使用。 长度 UDP用户数据报的长度,其最小值是8(仅有首部)。 检验和 检测UDP用户数据报在传输中是否有错,有错就丢弃。 伪首部 不参与下传和上传,仅仅为了计算机检验和。
端口分用:当运输层从 IP 层收到 UDP 数据报时,就根据首部中的目的端口,把 UDP 数据报通过相应的端口,上交最后的终点——应用进程。
3,传输控制协议TCP概述
3.1,TCP最主要的特点
每一条 TCP 连接只能有两个端点 ,每一条 TCP 连接只能是点对点的(一对一)。
- TCP 提供可靠交付的服务。
- TCP 提供全双工通信。
面向字节流,“面向字节流”的含义是:虽然应用程序和 TCP 的交互是一次一个数据块,但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流。
- TCP 连接是一条虚连接而不是一条真正的物理连接。
- TCP 对应用进程一次把多长的报文发送到TCP 的缓存中是不关心的。
- TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节(UDP 发送的报文长度是应用进程给出的)。
- TCP 可把太长的数据块划分短一些再传送。
- TCP 也可等待积累有足够多的字节后再构成报文段发送出去。
3.2,TCP的粘包和拆包
【TCP的粘包和拆包】 TCP是面向流,没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义,它会根据TCP缓冲区的实际情况进行包的划分,所以在业务上认为,一个完整的包可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题。
【粘包和拆包产生原因】
- 要发送的数据小于TCP发送缓冲区的大小,TCP将多次写入缓冲区的数据一次发送出去,将会发生粘包;
- 接收数据端的应用层没有及时读取接收缓冲区中的数据,将发生粘包;
- 要发送的数据大于TCP发送缓冲区剩余空间大小,将会发生拆包;
- 待发送数据大于MSS(最大报文长度),TCP在传输前将进行拆包。即TCP报文长度-TCP头部长度>MSS。
【粘包和拆包解决方案】
- 发送端将每个数据包封装为固定长度。
- 在数据尾部增加特殊字符进行分割。
- 将数据分为两部分,一部分是头部,一部分是内容体;其中头部结构大小固定,且有一个字段声明内容体的大小。
3.3,TCP面试题
【问题】两台服务器之间可以同时建立多条TCP链接吗?
建立多个客户端进程或线程,每个进程或线程都建立一条TCP连接。这种方式需要消耗大量的系统资源,效率较低,不适合大规模使用。
使用多路复用技术(如epoll、select、poll等),通过单个进程或线程来同时处理多个TCP连接,避免了创建大量进程或线程的问题,提高了系统的性能和稳定性。
使用连接池技术,将TCP连接存储在一个池中,需要时从池中取出可用的连接进行通信,通信结束后再将连接放回池中,提高了连接的复用率,降低了系统开销。
【问题】TCP如何实现安全性?
- 连接建立过程中,客户端和服务器端会交换一些信息,如SYN和ACK,以确定彼此的身份并协商通信参数。这个过程中可以防止未授权的连接。
- TCP使用序列号和确认号来保证数据包的正确发送和接收。发送方为每个数据包分配一个序列号,接收方在收到数据包后会回复一个确认序列号,以表明已经成功接收到该数据包。如果发送方在一定时间内未收到确认信息,就会重传该数据包。序列号和确认号也可以防止重复数据包的出现。
- TCP还支持窗口控制机制,即每次发送的数据量受到限制,接收方会告诉发送方自己还能够接收多少数据,以控制发送方的发送速度,防止网络拥塞和资源浪费。
- TCP还支持校验和机制,可以检测数据包是否损坏或被篡改。如果校验和错误,接收方将拒绝该数据包,并请求发送方重传。
- 在安全性需求更高的场景下,TCP可以和SSL/TLS等安全协议结合使用,进行加密和认证,以进一步保证数据传输的安全和隐私性。
【问题】TCP如何实现可靠传输?
- 首先,TCP的连接是基于三次握手,而断开则是基于四次挥手。确保连接和断开的可靠性。
- 其次,TCP会记录哪些数据发送了,哪些数据被接收了,哪些没有被接受,并且保证数据包按序到达,保证数据传输不出差错。
- TCP还有数据包校验、ACK应答、超时重传(发送方)、失序数据重传(接收方)、丢弃重复数据、流量控制(滑动窗口)和拥塞控制等机制。
3.4,TCP和UDP的区别
(1)连接方面
- TCP面向连接(如打电话要先拨号建立连接)。
- UDP是无连接的,即发送数据之前不需要建立连接。
(2)安全方面
- TCP提供可靠的服务,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达。
- UDP尽最大努力交付,即不保证可靠交付。
(3)传输效率的区别
- TCP传输效率相对较低。
- UDP传输效率高,适用于对高速传输和实时性有较高的通信或广播通信。
(4)连接对象数量的区别
- TCP连接只能是点到点、一对一的。
- UDP支持一对一,一对多,多对一和多对多的交互通信。
(5)开销问题
- TCP首部开销20字节。
- UDP的首部开销小,只有8个字节。
(6)应用场景
- TCP:文件传输(FTP)、网页浏览(HTTP)、电子邮件(SMTP)、远程终端访问(SSH)
- UDP:域名解析(DNS)、在线游戏、视频会议、简单网络管理协议(SNMP)
4,可靠传输的工作原理
理想的传输条件:传输信道不产生差错,不管发送方以多快的速度发送数据,接收方总是来得及处理收到的数据。然而实际的网络都不具备以上两个理想条件。
4.1,停止等待协议
“停止等待”就是每发送完一个分组就停止发送,等待对方的确认。在收到确认后再发送下一个分组。
全双工通信的双方既是发送方也是接收方。为了讨论问题的方便,我们仅考虑 A 发送数据而 B 接收数据并发送确认。因此 A 叫做发送方,而 B 叫做接收方。
1,无差错情况
2,出现差错
【问题】接收方B出现(1)B 接收 M1 时检测出了差错,就丢弃 M1,其他什么也不做(不通知 A 收到有差错的分组)。(2)M1 在传输过程中丢失了,这时 B 当然什么都不知道,也什么都不做。
【答案】A 为每一个已发送的分组都设置了一个超时计时器。A 只要在超时计时器到期之前收到了相应的确认,就撤销该超时计时器,继续发送下一个分组 M2 。
3,确认丢失和确认迟到
确认丢失:若 B 所发送的对 M1 的确认丢失了,那么 A 在设定的超时重传时间内不能收到确认,但 A 并无法知道:是自己发送的分组出错、丢失了,或者 是 B 发送的确认丢失了。因此 A 在超时计时器到期后就要重传 M1。
解决:第一,丢弃这个重复的分组 M1,不向上层交付。第二,向 A 发送确认。不能认为已经发送过确认就不再发送,因为 A 之所以重传 M1 就表示 A 没有收到对 M1 的确认。
确认迟到:传输过程中没有出现差错,但 B 对分组 M1 的确认迟到了。
解决:A 会收到重复的确认。对重复的确认的处理很简单:收下后就丢弃。B 仍然会收到重复的 M1,并且同样要丢弃重复的 M1,并重传确认分组。
PS:
- 在发送完一个分组后,必须暂时保留已发送的分组的副本,以备重发。
- 分组和确认分组都必须进行编号。
- 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。
自动重传请求ARQ:通常 A 最终总是可以收到对所有发出的分组的确认。如果 A 不断重传分组但总是收不到确认,就说明通信线路太差,不能进行通信。
使用上述的确认和重传机制(停止等待协议),我们就可以在不可靠的传输网络上实现可靠的通信。
像上述的这种可靠传输协议常称为自动重传请求 ARQ。意思是重传的请求是自动进行的,接收方不需要请求发送方重传某个出错的分组。
4,信道利用率
TD:分组长度/数据率,RTT:往返时间,TA:B发送确认分组的时间。
为了提高传输效率,发送方可以不使用低效率的停止等待协议,而是采用流水线传输。流水线传输就是发送方可连续发送多个分组,不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地传送。由于信道上一直有数据不间断地传送,这种传输方式可获得很高的信道利用率。
当使用流水线传输时,就要使用下面介绍的连续ARQ协议和滑动窗口协议。
4.2,连续ARQ协议(滑动窗口)
发送方维持的发送窗口,它的意义是:位于发送窗口内的分组都可连续发送出去,而不需要等待对方的确认。这样,信道利用率就提高了。
发送方:连续 ARQ 协议规定,发送方每收到一个确认,就把发送窗口向前滑动一个分组的位置。
接收方:一般采用累积确认的方式。即不必对收到的分组逐个发送确认,而是对按序到达的最后一个分组发送确认,这样就表示:到这个分组为止的所有分组都已正确收到了。
优点:容易实现,即使确认丢失也不必重传。缺点:不能向发送方反映出接收方已经正确收到的所有分组的信息。
Go-back-N:如果发送方发送了前 5 个分组,而中间的第 3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落,而只好把后面的三个分组都再重传一次。可见当通信线路质量不好时,连续 ARQ 协议会带来负面的影响。
4.3,超时重传机制
发送数据包: 当发送端(客户端或服务器)发送数据包时,它会等待一个确认(ACK)来表示数据包已经成功到达接收端。如果在一定时间内没有收到确认,发送端会假定数据包已经丢失,并启动超时重传机制。
超时计时器: 对于每个发送的数据包,TCP会设置一个超时计时器。这个计时器的值通常是动态调整的,它取决于网络的延迟和拥塞情况。如果在超时计时器到期之前没有收到确认,发送端会认为数据包丢失。
超时重传: 一旦超时计时器到期,发送端会重新发送相同的数据包。这是为了确保丢失的数据包最终能够到达接收端。通常,TCP会等待一段时间来接收重传的确认,以避免重复重传。
指数退避: 如果发生连续的超时重传事件,TCP可能会采用指数退避策略,增加超时计时器的时间间隔,以避免过度拥塞网络。
最大重传次数: TCP通常会设置一个最大重传次数的上限,如果达到这个上限仍然没有收到确认,发送端会放弃发送该数据包,并通知应用程序有问题发生。
TCP 每发送一个报文段,就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认,就要重传这一报文段。
- 如果把超时重传时间设置得太短,就会引起很多报文段的不必要的重传,使网络负荷增大。
- 但若把超时重传时间设置得过长,则又使网络的空闲时间增大,降低了传输效率。
TCP 采用了一种自适应算法,它记录一个报文段发出的时间,以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间 RTT。TCP保留了RTT的一个加权平均往返时间RTTs。新的RTTs=(1-a)*旧的RTTs+a*新的RTT样本。
4.4,以字节为单位的滑动窗口
TCP 的滑动窗口是以字节为单位的。现假定 A 收到了 B 发来的确认报文段,其中窗口是 20 字节,而确认号是 31(这表明 B 期望收到的下一个序号是 31,而序号 30 为止的数据已经收到了)。根据这两个数据,A 就构造出自己的发送窗口。
根据 B 给出的窗口值,A 构造出自己的发送窗口。
发送窗口表示:在没有收到 B 的确认的情况下,A 可以连续把窗口内的数据都发送出去。 发送窗口里面的序号表示允许发送的序号。
显然,窗口越大,发送方就可以在收到对方确认之前连续发送更多的数据,因而可能获得更高的传输效率。
此时,B的接收窗口大小是20。在接收窗口外面,到30为止的数据已经发送过确认,并且已经交付主机了。B收到了32,33的数据,这些数据没有按序到达,因为31数据没有收到或者滞留网络,B只能按照最高序号给出确认,因此B发送的确认报文段中的确认号仍是31,不能是32,33。
过了一会,B收到了序号31的数据,并把序号为31~33的数据交付主机,然后B删除这些数据。接着把接收窗口向前移动3个序号,同时给A发送确认,其中窗口值仍然是20,但是确认号变成了34。这表明B已经收到了到序号33为止的数据。同时B收到了序号37,38,40的数据,但是都没按照顺序到达,只能暂存到接收窗口中。A收到B的确认后,就可以把发送窗口向前滑动3个序号,但是P2不动。可以看出,现在A的可用窗口增大,可发送序号范围42~53。
A在继续发送完序号42~53的数据后,指针P2向前移动和P3重合。发送窗口内的序号都以用完,但还没有在收到确认。由于A的发送窗口已满,可用窗口减少到0,因此必须停止发送。在没有收到B的确认前,A只能认为B还没有收到这些数据。于是,A在经过一段时间后(超时重传)就重传这部分数据,重新设置超时计时器,直到收到B的确认为止。如果A时候确认号落在发送窗口内,那么A就可以发送窗口继续向前滑动,并发送新的数据。
发送缓存和接收缓存
- 发送缓存用来暂时存放:发送应用程序传送给发送方 TCP 准备发送的数据;TCP 已发送出但尚未收到确认的数据。
- 接收缓存用来暂时存放:按序到达的、但尚未被接收应用程序读取的数据;不按序到达的数据。
PS:
- 第一,A 的发送窗口并不总是和 B 的接收窗口一样大(因为有一定的时间滞后)。
- 第二,TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程。
- 第三,TCP 要求接收方必须有累积确认的功能,这样可以减小传输开销。
接收方发送确认:接收方可以在合适的时候发送确认,也可以在自己有数据要发送时把确认信息顺便捎带上。但请注意两点:
- 接收方不应过分推迟发送确认,否则会导致发送方不必要的重传,这反而浪费了网络的资源。
- 捎带确认实际上并不经常发生,因为大多数应用程序很少同时在两个方向上发送数据。
5,TCP报文段的首部格式
TCP 虽然是面向字节流的,但 TCP 传送的数据单元却是报文段。
一个 TCP 报文段分为首部和数据两部分,而 TCP 的全部功能都体现在它首部中各字段的作用。
TCP 报文段首部的前 20 个字节是固定的,后面有 4n 字节是根据需要而增加的选项 (n 是整数)。因此 TCP 首部的最小长度是 20 字节。
源端口 占2字节,分别写入源端口号和目的端口号。 目的端口 序号(seq) 占4字节,序号范围0~2^32-1。序号增加到最大后,下一个又回到0,序号通过模运算。
一个TCP连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的其实序号必须在连接建立时设置。
例:一报文段值序号值301,而携带的数据共有100字节,最后一个字节的序号400。下一报文段的数据序号应该从401开始
确认号(ack) 占4字节,是期望收到对方下一个报文段的第一个数据字节的序号。
例:B收到A发过来的序号为700的报文段,而数据长度为200字节,这就表明B收到了A发送的到序号为700为止的数据。
因此,B希望收到A的下一个数据序号是701,于是B在发送给A的确认报文字段中把确认号置为701。
数据偏移 占4位,它指出TCP报文段的数据起始处距离TCP报文段的起始处(数据部分)多远。实际上指出TCP报文段的首部长度。 保留 占6位,保留为今后使用,但目前应当置为0。 控制位 紧急URG 当URG=1,表明紧急指针有效。告诉系统此报文中有紧急数据,应尽快传送,而不要按照原来的排队顺序。 确认ACK 当ACK=1,上面的确认号才有效。TCP在连接建立后所有传送的报文段都必须把ACK置1。 推送PSH 当两个应用进程进行交互式的通信时,有时在一端的应用进程希望在键入一个命令后立即能够收到对方的响应。
这时,发送方TCP把PSH置1,并立即创建一个报文段发送出去。
接收方TCP收到PSH=1的报文段,就尽快交付接收应用进程,而不再等到整个缓存都填满后再向上交付。
复位RST 当RST=1,表明TCP连接中出现了严重的错误,必须释放连接,然后再重新建立运输连接。
RST置1还用来拒绝一个非法的报文段或拒绝打开一个连接。RST也可称为重建位或重置位。
同步SYN 在建立时用来同步序号。当SYN=1而ACK=0时,表明这是一个连接请求报文段。对方若同意建立连接,则应当在响应的报文段中使SYN=1,ACK=1。因此SYN=1就表示这是一个连接请求或连接接受报文。 终止FIN 用来释放一个连接,当FIN=1时,表明报文段的发送方的数据已发送 完毕,并要求释放运输连接。 窗口 占2字节。窗口是0~2^16-1之间的整数。窗口指的是发送本报文段的一芳的接收窗口。
窗口告诉对方:从本报文段首部中的确认号算起,接收方目前允许对方发送的数据量。
之所以限制,是因为接收方的数据缓存空间有限。
检验和 占2字节。检验和字段检验的范围包括首部和数据这两部分。和UDP用户数据报一样,在计算检验和时,要在TCP报文段前面加上12字节的伪首部。 紧急指针 占2字节。紧急指针仅在URG=1时才有意义,它指出本报文段中紧急数据的字节数(紧急数据结束后就是普通数据)。
当所有紧急数据都处理完时,TCP就告诉应用程序恢复到正常操作。
选项 长度可变,最长可达40字节。最大报文段长度MSS。
MSS是每一个TCP报文段中的数据字段的最大长度。
TCP报文字段=TCP首部+数据字段。
更多推荐
















所有评论(0)