前言

本文基于王道考研课程、湖科大计算机网络课程教学内容以及计算机网络（第八版），系统梳理核心知识记忆点和框架，既为个人复习沉淀思考，亦希望能与同行者互助共进。

往期内容

408 计算机网络 知识点记忆（1）

408 计算机网络 知识点记忆（2）

408 计算机网络 知识点记忆（3）

408 计算机网络 知识点记忆（4）

408 计算机网络 知识点记忆（5）

408 计算机网络 知识点记忆（6）

408 计算机网络 知识点记忆（7）

408 计算机网络 知识点记忆（8）

核心知识记忆点+理解性说明

第五章 传输层

1.传输层提供的服务

A.传输层的功能

从IP层来说,通信的两端是两台主机。IP数据报的首部明确地标志了这两台主机的IP地址。但“两台主机之间的通信”这种说法还不够明确。真正进行通信的实体是在主机中的哪个构件呢?是主机中的应用进程,是一台主机中的应用进程和另一台主机中的应用进程在交换数据(即通信)。因此严格地讲,两台主机进行通信就是两台主机中的应用进程互相通信。IP协议虽然能把分组送到目的主机,但是这个分组还停留在主机的网络层而没有交付主机中的应用进程。通信的两端应当是两个主机中的应用进程。也就是说,端到端的通信是应用进程之间的通信。

运输层有一个很重要的功能 – 复用(multiplexing)和分用(demultiplexing)。这里的“复用”是指在发送方不同的应用进程都可以使用同一个运输层协议传送数据(当然需要加上适当的首部),而“分用”是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。
注:IP层也有复用和分用的功能。即在发送方使用不同协议的数据都可以封装成IP数据报发送出去,而在接收方的IP层根据IP首部中的协议字段进行分用,把剥去首部后的数据交付应当接收这些数据的协议。

当运输层采用面向连接的TCP协议时,尽管下面的网络是不可靠的(只提供尽最大努力服务),但这种逻辑通信信道就相当于一条全双工的可靠信道。但当运输层采用无连接的UDP协议时,这种逻辑通信信道仍然是一条不可靠信道。

运输层还要对收到的报文进行差错检测。
在网络层,IP数据报首部中的检验和字段,只检验首部是否出现差错而不检查数据部分。

按照 OSI 的术语,两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元TPDU(Transport Protocol Data Unit)。但在TCP/IP体系中,则根据所使用的协议是TCP或UDP,分别称之为TCP报文段(segment)或UDP用户数据报。
UDP在传送数据之前不需要先建立连接。远地主机的运输层在收到UDP报文后,不需要给出任何确认。虽然UDP不提供可靠交付,但由于UDP非常简单,在某些情况下UDP是一种最有效的工作方式。
TCP 则提供面向连接的服务。在传送数据之前必须先建立连接,数据传送结束后要释放连接。TCP不提供广播或多播服务。由于TCP要提供可靠的、面向连接的运输服务,因此不可避免地增加了许多的开销,如确认、流量控制、计时器以及连接管理等。这不仅使协议数据单元的首部增大很多,还要占用许多的处理机资源。

在协议栈层间的抽象的协议端口是软件端口,和路由器或交换机上的硬件端口是完全不同的概念。硬件端口是不同硬件设备进行交互的接口,而软件端口是应用层的各种协议进程与运输实体进行层间交互的地点。

两个计算机中的进程要互相通信,不仅必须知道对方的IP地址(为了找到对方的计算机),而且要知道对方的端口号(为了找到对方计算机中的应用进程)。

传输层：直接为应用进程间的逻辑通信提供服务
端口：进程使用进程标识符标识

数据链路层的服务访问点为帧
网络层的服务访问点为IP数据报
传输层的服务访问点为端口号
应用层的服务访问点为用户界面

B.传输层寻址与端口

TCP/IP的运输层用一个16位端口号来标志一个端口。但请注意,端口号只具有本地意义,它只是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口。在互联网不同计算机中,相同的端口号是没有关联的。

运输层的端口号分为下面的两大类。
(1)服务器端使用的端口号 又分为两类,最重要的一类叫作熟知端口号(well-known port number)或全球通用端口号,数值为0~1023。
另一类叫作登记端口号,数值为 1024~49151。这类端口号是为没有熟知端口号的应用程序使用的。
(2)客户端使用的端口号 数值为 49152~65535。由于这类端口号仅在客户进程运行时才动态选择,因此又叫作短暂端口号1。这类端口号就是临时端口号,留给客户进程选择临时使用。当服务器进程收到客户进程的报文时,就知道了客户进程所使用的端口号,因而可以把数据发送给客户进程。通信结束后,刚才已使用过的客户端口号就被系统收回,以便给其他客户进程使用。

2.UDP

A.UDP数据报

(1)UDP是无连接的,即发送数据之前不需要建立连接(当然,发送数据结束时也没有连接可释放),因此减少了开销和发送数据之前的时延。
(2)UDP使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的连接状态表(这里面有许多参数)。
(3)UDP是面向报文的。发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。这就是说,应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文。在接收方的UDP,对IP层交上来的UDP用户数据报,在去除首部后就原封不动地交付上层的应用进程。也就是说,UDP一次交付一个完整的报文。因此,应用程序必须选择合适大小的报文。若报文太长,UDP把它交给IP层后,IP层在传送时可能要进行分片,这会降低IP层的效率。反之,若报文太短,UDP把它交给IP层后,会使IP数据报的首部的相对长度太大,这也降低了IP层的效率。
(4)UDP没有拥塞控制,因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很多的实时应用(如IP 电话、实时视频会议等)要求源主机以恒定的速率发送数据,并且允许在网络发生拥塞时丢失一些数据,但却不允许数据有太大的时延。UDP正好适合这种要求。
(5)UDP支持一对一、一对多、多对一和多对多的交互通信。
(6)UDP的首部开销小,只有8个字节,比TCP的20个字节的首部要短。

用户数据报UDP有两个字段:数据字段和首部字段。首部字段很简单,只有8个字节,由4个字段组成,每个字段的长度都是2字节。
(1)源端口 源端口号。在需要对方回信时选用。不需要时可用全0。
(2)目的端口 目的端口号。这在终点交付报文时必须使用。
(3)长度 UDP用户数据报的长度,其最小值是8(仅有首部)。
(4)检验和 检测UDP用户数据报在传输中是否有错。有错就丢弃。

如果接收方 UDP发现收到的报文中的目的端口号不正确(即不存在对应于该端口号的应用进程),就丢弃该报文,并由网际控制报文协议ICMP发送“端口不可达”差错报文给发送方。讨论traceroute时,就是让发送的UDP用户数据报故意使用一个非法的UDP端口,结果ICMP就返回“端口不可达”差错报文,因而达到了测试的目的。

B.UDP检验

UDP用户数据报首部中检验和的计算方法有些特殊。在计算检验和时,要在UDP用户数据报之前增加12个字节的伪首部。所谓“伪首部”是因为这种伪首部并不是UDP用户数据报真正的首部。只是在计算检验和时,临时添加在UDP用户数据报前面,得到一个临时的UDP用户数据报。检验和就是按照这个临时的UDP用户数据报来计算的。伪首部既不向下传送也不向上递交,而仅仅是为了计算检验和。

3.TCP

A.TCP段

(1)TCP是面向连接的运输层协议。这就是说,应用程序在使用TCP协议之前,必须先建立TCP连接。在传送数据完毕后,必须释放已经建立的TCP连接。也就是说,应用进程之间的通信好像在“打电话”:通话前要先拨号建立连接,通话结束后要挂机释放连接。
(2)每一条TCP连接只能有两个端点(endpoint),每一条TCP连接只能是点对点的(一对一)。这个问题后面还要进一步讨论。
(3)TCP提供可靠交付的服务。通过TCP连接传送的数据,无差错、不丢失、不重复,并且按序到达。
(4)TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存,用来临时存放双向通信的数据。在发送时,应用程序在把数据传送给TCP的缓存后,就可以做自己的事,而TCP在合适的时候把数据发送出去。在接收时,TCP把收到的数据放入缓存,上层的应用进程在合适的时候读取缓存中的数据。
(5)面向字节流。TCP中的“流”(stream)指的是流入到进程或从进程流出的字节序列。“面向字节流”的含义是:虽然应用程序和TCP的交互是一次一个数据块(大小不等),但TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。TCP并不知道所传送的字节流的含义。TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系(例如,发送方应用程序交给发送方的TCP共10个数据块,但接收方的TCP可能只用了4个数据块就把收到的字节流交付上层的应用程序)。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。当然,接收方的应用程序必须有能力识别收到的字节流,把它还原成有意义的应用层数据。

每一条TCP连接有两个端点。那么,TCP连接的端点是什么呢?不是主机,不是主机的IP地址,不是应用进程,也不是运输层的协议端口。TCP连接的端点叫作套接字(socket)或插口。根据RFC 793的定义:端口号拼接到(concatenated with)IP地址即构成了套接字。因此,套接字的表示方法是在点分十进制的IP地址后面写上端口号,中间用冒号或逗号隔开。例如,若IP地址是192.3.4.5 而端口号是 80,那么得到的套接字就是(192.3.4.5:80)。总之,我们有
套接字 socket=(IP地址:端口号)
每一条 TCP 连接唯一地被通信两端的两个端点(即套接字对 socket pair)所确定。即:
TCP 连接 ::= {socket1,socket2}={(IP1: port1),(IP2: port2);

第一,虽然A的发送窗口是根据B的接收窗口设置的,但在同一时刻,A的发送窗口并不总是和 B的接收窗口一样大。这是因为通过网络传送窗口值需要经历一定的时间滞后(这个时间是不确定的)。另外,发送方A还可能根据网络当时的拥塞情况适当减小自己的发送窗口数值。
第二,对于不按序到达的数据应如何处理,TCP标准并无明确规定。如果接收方把不按序到达的数据一律丢弃,那么接收窗口的管理将会比较简单,但这样做对网络资源的利用不利(因为发送方会重复传送较多的数据)。因此TCP通常是把不按序到达的数据先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程。
第三,TCP要求接收方必须有累积确认的功能,这样可以减小传输开销。接收方可以在合适的时候发送确认,也可以在自己有数据要发送时把确认信息顺便捎带上。但请注意两点。一是接收方不应过分推迟发送确认,否则会导致发送方不必要的重传,这反而浪费了网络的资源。TCP标准规定,确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段,则必须每隔一个报文段就发送一个确认。二是捎带确认实际上
并不经常发生,因为大多数应用程序很少同时在两个方向上发送数据。
最后再强调一下,TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此,每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时,一定要弄清是哪一方的窗口。

所谓流量控制(flow control)就是让发送方的发送速率不要太快,要让接收方来得及接收。
TCP 的窗口单位是字节,不是报文段。

为TCP 为每一个连接设有一个持续计时器(persistence timer)。只要TCP 连接的一方收到对方的零窗口通知,就启动持续计时器。若持续计时器设置的时间到期,就发送一个零窗口探测报文段(仅携带1字节的数据),而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口仍然是零,那么收到这个报文段的一方就重新设置持续计时器。如果窗口不是零,那么死锁的僵局就可以打破了。(注:TCP规定,即使设置为零窗口,也必须接收以下几种报文段:零窗口探测报文段、确认报文段和携带紧急数据的报文段)

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

在 TCP的实现中广泛使用Nagle 算法。算法如下:若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存,则发送方就把第一个数据字节先发送出去,把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后,再把发送缓存中的所有数据组装成一个报文段发送出去,同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时,用这样的方法可明显地减少所用的网络带宽。Nagle 算法还规定,当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时,就立即发送一个报文段。这样做,就可以有效地提高网络的吞吐量。
另一个问题叫作糊涂窗口综合征(silly window syndrome),有时也会使TCP的性能变坏。设想一种情况:TCP 接收方的缓存已满,而交互式的应用进程一次只从接收缓存中读取 1个字节(这样就使接收缓存空间仅腾出1个字节),然后向发送方发送确认,并把窗口设置为1个字节(但发送的数据报是40字节长)。接着,发送方又发来1个字节的数据(请注意,发送方发送的IP数据报是41字节长)。接收方发回确认,仍然将窗口设置为1个字节。这样进行下去,使网络的效率很低。
要解决这个问题,可以让接收方等待一段时间,使得或者接收缓存已有足够空间容纳一个最长的报文段,或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一,接收方就发出确认报文,并向发送方通知当前的窗口大小。此外,发送方也不要发送太小的报文段,而是把数据积累成足够大的报文段,或达到接收方缓存的空间的一半大小。

B.TCP连接管理

为什么A在TIME-WAIT状态必须等待2MSL的时间呢?这有两个理由。
第一,为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失,因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段,而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着A重传一次确认,重新启动 2MSL 计时器。最后,A和B 都正常进入到CLOSED状态。如果A在TIME-WAIT状态不等待一段时间,而是在发送完ACK报文段后
立即释放连接,那么就无法收到B重传的FIN+ACK报文段,因而也不会再发送一次确认报文段。这样,B就无法按照正常步骤进入CLOSED状态。
第二,防止上一节提到的“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后,再经过时间2MSL,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。B 只要收到了A发出的确认,就进入CLOSED状态。同样,B在撤销相应的传输控制块TCB后,就结束了这次的TCP连接。我们注意到,B结束TCP连接的时间要比A早一些。

除时间等待计时器外,TCP还设有一个保活计时器(keepalive timer)。设想有这样的情况:客户已主动与服务器建立了TCP连接。但后来客户端的主机突然出故障。显然,服务器以后就不能再收到客户发来的数据。因此,应当有措施使服务器不要再白白等待下去。这就是使用保活计时器。服务器每收到一次客户的数据,就重新设置保活计时器,时间的设置通常是两小时。若两小时没有收到客户的数据,服务器就发送一个探测报文段,以后则每隔 75秒钟发送一次。若一连发送10个探测报文段后仍无客户的响应,服务器就认为客户端出了故障,接着就关闭这个连接。

C.TCP可靠传输

TCP可靠传输 序号 累计确认 重传 超时冗余ACK
TCP流量控制 慢开始 拥塞避免 ；快重传 快恢复

D.TCP流量控制与拥塞控制

在计算机网络中的链路容量(即带宽)、交换节点中的缓存和处理机等,都是网络的资源。在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。这种情况就叫作拥塞(congestion)。可以把出现网络拥塞的条件写成如下的关系式:
∑ 对资源的需求>可用资源

拥塞控制与流量控制的关系密切,它们之间也存在着一些差别。所谓拥塞控制就是防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不至于过载。拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程,涉及所有的主机、所有的路由器,以及与降低网络传输性能有关的所有因素。但TCP连接的端点只要迟迟不能收到对方的确认信息,就猜想在当前网络中的某处很可能发生了拥塞,但这时却无法知道拥塞到底发生在网络的何处,也无法知道发生拥塞的具体原因。(是访问某个服务器的通信量过大?还是在某个地区出现自然灾害?)相反,流量控制往往是指点对点通信量的控制,是个端到端的问题。

随着提供的负载的增大,网络吞吐量的增长速率逐渐减小。也就是说,在网络吞吐量还未达到饱和时,就已经有一部分的输入分组被丢弃了。当网络的吞吐量明显地小于理想的吞吐量时,网络就进入了轻度拥塞的状态。更值得注意的是,当提供的负载达到某一数值时,网络的吞吐量反而随提供的负载的增大而下降,这时网络就进入了拥塞状态。当提供的负载继续增大到某一数值时,网络的吞吐量就下降到零,网络已无法工作,这就是所谓的死锁(deadlock)。

由于计算机网络是一个很复杂的系统,因此可以从控制理论的角度来看拥塞控制这个问题。这样,从大的方面看,可以分为开环控制和闭环控制两种方法。开环控制就是在设计网络时事先将发生拥塞的有关因素考虑周到,力求网络在工作时不产生拥塞。但一旦整个系统运行起来,就不再中途进行改正了。

流量控制：接收方根据接收缓存的可用空间大小控制发送方的发送速率
拥塞控制：防止过多数据注入到网络中 使网络能够承受住现有网络负荷 源点根据各方面因素 按拥塞控制算法自行控制发送速率 全局性问题 涉及网络中所有主机 路由器等

开环控制 良好设计解决问题 系统启动中途不需要修正
闭环控制 检测网络 采取行动（显式反馈 节点向源点反馈信息 隐式反馈 源点自身观察 eg TCP）

TCP 进行拥塞控制的算法有四种,即慢开始(slow-start)、拥塞避免(congestion avoidance)、快重传(fast retransmit)和快恢复(fast recovery)。

慢开始规定,在每收到一个对新的报文段的确认后,可以把拥塞窗口增加最多一个SMSS的数值。

采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认,而是要立即发送确认,即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。接收方收到了M1和M2后都分别及时发出了确认。现假定接收方没有收到M3但却收到了M4。本来接收方可以什么都不做。但按照快重传算法,接收方必须立即发送对M2的重复确认,以便让发送方及早知道接收方没有收到报文段M3。发送方接着发送Ms和M6。接收方收到后也仍要再次分别发出对M2的重复确认。这样,发送方共收到了接收方的4个对M2的确认,其中后3个都是重复确认。快重传算法规定,发送方只要一连收到3个重复确认,就可知道现在并未出现网络拥塞,而只是接收方少收到一个报文段M3,因而立即进行重传M3(即“快重传”)。

总结（之前的版本）

传输层：直接为应用进程间的逻辑通信提供服务
端口：进程使用进程标识符标识

数据链路层的服务访问点为帧
网络层的服务访问点为IP数据报
传输层的服务访问点为端口号
应用层的服务访问点为用户界面

熟知端口号 0~1023

FTP	TELNET	SMTP	DNS	TFTP	HTTP	SNMP	HTTPS	RIP	DHCP	BGP
21/20	23	25	53	69	80	161	443	520	67/68	179
TCP	TCP	UDP	UDP	UDP	TCP	UDP		UDP	UDP	TCP

登记端口号 1024~49151

套接字：（IP地址：端口号）

UDP数据报 仅在IP数据报上增加了复用 分用 差错检测功能
面向报文
无需建立连接
无连接状态
首部开销小
没有拥塞控制
支持一对一、一对多、多对一、多对多的交互通信

首部8B 源端口（2B）+目的端口(2B)+长度(2B)+检验和(2B)+数据

UDP数据报之前增加12B的伪首部 伪首部既不向下传送， 又不向上递交

校验和计算 相加 回卷 求反码
接收方全部相加 结果全为1 无差错

TCP 报文段
面向连接 TCP连接时一条逻辑连接
每一条TCP连接只能有两个端点，每一条TCP连接只能是一对一
提供可靠交付下的服务 保证传送数据无差错 不丢失 不重复且有序
提供全双工通信 允许通信双方应用进程在任何时候都能发送数据 TCP连接的两端都有发送缓存和接收缓存 用来临时存放双向通道的数据
面向字节流

首部前20B固定 首部最短20B 最长60B
具体格式

TCP连接的建立 三次握手
过程图

TCP连接的释放 四次挥手
过程图
TCP可靠传输 序号 累计确认 重传 超时冗余ACK
TCP流量控制 慢开始 拥塞避免 ；快重传 快恢复

流量控制：接收方根据接收缓存的可用空间大小控制发送方的发送速率
拥塞控制：防止过多数据注入到网络中 使网络能够承受住现有网络负荷 源点根据各方面因素 按拥塞控制算法自行控制发送速率 全局性问题 涉及网络中所有主机 路由器等

开环控制 良好设计解决问题 系统启动中途不需要修正
闭环控制 检测网络 采取行动（显式反馈 节点向源点反馈信息 隐式反馈 源点自身观察 eg TCP）

结语

传输层作为应用进程间的通信桥梁，以端口为锚点、协议为纽带，架起了端到端可靠交互的智慧通路。从UDP的轻量敏捷到TCP的严谨有序，从三次握手的连接建立到四次挥手的优雅告别，每一项机制都在为数据的精准抵达保驾护航。端口号的逻辑寻址、校验和的差错守卫、拥塞控制的全局平衡，共同诠释了传输层“承网络之基，启应用之智”的核心价值。

在UDP的面向报文中，我们看到了实时传输的自由之美；在TCP的字节流里，我们领悟了可靠交付的秩序之力。流量控制的滑动窗口、拥塞控制的慢启动算法、快重传的冗余ACK触发，无不彰显着协议设计者对网络动态的深刻洞察与自适应智慧。无论是全双工通信的双向缓存，还是伪首部的校验辅助，细节之处皆是匠心。

参考资料

1.王道考研课程
2.湖科大计算机网络课程
3.计算机网络（第八版）