【计算机网络】传输层

上期回顾: 【计算机网络】网络层
个人主页：GUIQU.
归属专栏：计算机网络

正文

1. 传输层概述

1.1 定义

传输层位于网络层之上，是计算机网络体系结构中承上启下的关键一层。它主要负责为不同主机上的应用进程提供端到端（end - to - end）的通信服务，就像是在网络的海洋中为应用程序搭建了一座沟通的桥梁，使得应用程序能够无视底层网络的复杂性进行数据传输。

1.2 作用

• 进程间通信：在一个主机上可能同时运行着多个应用程序（进程），传输层能够区分不同的进程，并为它们提供通信服务。例如，在一台电脑上，浏览器进程和邮件客户端进程可以同时通过传输层与网络中的其他服务器进行通信，而不会相互干扰。
• 提供可靠或不可靠的服务：根据应用的需求，传输层可以提供可靠的面向连接的服务（如TCP），确保数据准确无误地到达目的地；也可以提供不可靠的无连接服务（如UDP），侧重于快速地将数据发送出去，适用于对实时性要求较高的应用。
• 复用和分用：复用是指多个应用进程可以使用同一个传输层协议发送数据；分用则是指传输层在接收数据后，能够根据不同的端口号等信息将数据正确地分发给相应的应用进程。

2. 传输层的主要协议 - TCP协议

2.1 TCP协议的特点

• 面向连接：在数据传输之前，TCP需要通过三次握手（three - way handshake）建立连接。就像打电话一样，先拨号（第一次握手），对方接听并回应（第二次握手），然后自己再确认（第三次握手），这样双方才能开始正式通话（传输数据）。这种连接是端到端的，跨越网络层提供的网络路径，在两个应用进程之间建立起一条可靠的通信通道。
• 可靠传输：TCP采用了一系列机制来确保数据的可靠传输。例如，通过序列号（sequence number）对发送的数据进行编号，接收方根据序列号来确认收到的数据顺序是否正确。同时，TCP还使用确认应答（ACK）机制，接收方收到数据后会向发送方发送确认信息，发送方如果没有收到确认信息，会认为数据丢失而重新发送。
• 流量控制和拥塞控制：TCP通过窗口机制进行流量控制，接收方会告诉发送方自己还能接收多少数据（接收窗口大小），发送方根据这个信息来调整发送速率，避免发送过多数据导致接收方无法处理。在拥塞控制方面，TCP采用了如慢启动、拥塞避免等算法，根据网络的拥塞情况动态调整发送窗口大小，防止网络拥塞。

2.2 TCP报文段的结构

• 首部：TCP报文段的首部包含多个重要字段。源端口号（source port）和目的端口号（destination port）用于标识发送方和接收方的应用进程，序列号用于标识数据的顺序，确认号（acknowledgment number）用于确认已收到的数据，首部长度（header length）指示首部的大小，还有一些控制位（如SYN、ACK、FIN等）用于建立连接、确认和拆除连接等操作，窗口大小（window size）用于流量控制，校验和（checksum）用于检查报文段是否出错。这些首部字段就像信件上的各种标签，为数据的正确传输提供了必要的信息。
• 数据部分：这是真正要传输的应用层数据，其长度受到最大报文段长度（MSS）的限制，MSS是在建立连接时协商确定的，这样可以避免数据过长导致在网络中传输不便。

2.3 TCP的连接管理

• 三次握手建立连接：
  • 第一次握手：客户端向服务器发送一个SYN（同步）报文段，其中序列号（sequence number）为随机值x，这个报文段表示客户端希望建立连接。
  • 第二次握手：服务器收到客户端的SYN报文段后，会向客户端发送一个SYN + ACK报文段。其中，SYN位仍然置1，序列号为随机值y，确认号为x + 1，这个报文段表示服务器同意建立连接，并对客户端的SYN进行确认。
  • 第三次握手：客户端收到服务器的SYN + ACK报文段后，会向服务器发送一个ACK报文段，确认号为y + 1。至此，连接建立成功，双方可以开始传输数据。
• 四次挥手拆除连接：
  • 第一次挥手：主动关闭方（假设是客户端）发送一个FIN（结束）报文段，表示客户端不再发送数据，但仍然可以接收数据。
  • 第二次挥手：服务器收到FIN报文段后，会发送一个ACK报文段，表示已经收到客户端的关闭请求。此时，服务器端可能还有数据需要发送给客户端。
  • 第三次挥手：当服务器端发送完所有剩余数据后，会发送一个FIN报文段，表示服务器也不再发送数据。
  • 第四次挥手：客户端收到服务器的FIN报文段后，会发送一个ACK报文段，至此，连接完全拆除。

3. 传输层的主要协议 - UDP协议

3.1 UDP协议的特点

• 无连接：UDP不需要像TCP那样建立连接，发送方直接将数据封装成UDP报文发送出去，就像寄明信片一样，不需要提前和收件人沟通建立联系。这使得UDP的通信过程更加简单快捷，减少了连接建立和拆除的开销。
• 不可靠传输：UDP没有像TCP那样的确认应答和重传机制，它不能保证数据一定能够准确无误地到达目的地。但是，这种不可靠性在某些应用场景下是可以接受的，甚至是更有利的。例如，对于实时性要求极高的应用，如在线游戏、实时视频会议等，偶尔的数据丢失可能比延迟更能被用户接受。
• 高效性：由于UDP协议简单，没有复杂的连接管理和可靠传输机制，所以它的头部开销小，数据传输效率高。在网络带宽有限的情况下，UDP能够更快地将数据发送出去。

3.2 UDP报文的结构

• 首部：UDP报文首部比较简单，只有8个字节。包括源端口号、目的端口号、UDP长度（首部和数据部分的总长度）和UDP校验和。虽然UDP校验和可以用于检查数据是否出错，但它是可选的，在一些对实时性要求极高的应用中，为了减少处理时间，可能会不使用校验和。
• 数据部分：UDP数据部分包含了要传输的应用层数据，其长度根据具体应用的需求而定，但受到IP层分组大小的限制。

4. 传输层协议的应用场景

4.1 TCP的应用场景

• 文件传输：当使用FTP（文件传输协议）或HTTP（超文本传输协议）下载文件时，需要确保文件数据的完整性和准确性。TCP的可靠传输机制能够很好地满足这一需求，通过序列号、确认应答等机制保证文件的每一个字节都能正确地从服务器传输到客户端。
• 电子邮件传输：在SMTP（简单邮件传输协议）发送邮件和POP3（邮局协议第3版）或IMAP（互联网邮件访问协议）接收邮件的过程中，TCP协议确保邮件内容的准确传递。因为电子邮件包含重要的信息，如邮件正文、附件等，不能有数据丢失或错误。

4.2 UDP的应用场景

• 实时多媒体应用：在在线游戏中，玩家的操作指令需要快速发送到服务器，UDP能够快速地将这些指令发送出去，即使偶尔丢失个别指令，游戏体验可能也不会受到太大影响。在实时视频流和音频流应用中，如网络直播，UDP的低延迟特性能够让观众更快地接收到视频和音频内容，虽然可能会出现画面或声音的短暂卡顿（由于数据丢失），但总体上能够满足实时性的要求。
• 简单的查询 - 应答系统：对于一些简单的网络服务，如DNS（域名系统）查询，UDP可以快速地发送查询请求并接收应答。因为DNS查询通常比较简单，而且即使查询失败，也可以很快地重新发送请求。

结语
感谢您的阅读！期待您的一键三连！欢迎指正！