传输层定义了主机应用程序之间端到端的连通性,并提供了数据传输服务。
TCP(传输控制协议)
TCP是一种面向连接的、可靠的传输层协议。它通过建立连接、传输数据和终止连接的过程,确保数据能够按顺序、无差错地传输。
TCP允许一个主机同时运行多个应用进程。每台主机可以拥有多个应用端口,每对端口号、源和目标IP地址的组合唯一地标识了一个会话。
端口号是一种网络通信的标识,用于区分计算机中不同应用程序或服务所使用的通信接口。端口号是一个16位的整数,其范围在0到65535之间。这个范围内的端口号被分为不同的类别,用于不同的目的。
TCP/IP协议采用了全局分配(静态分配)和本地分配(动态分配)相结合的分配方法。对于TCP或UDP,将它们的全部65535个端口号分为保留端口号和自由端口号两部分。保留端口的范围是0—1023,又称为众所周知的端口或熟知端口,如FTP、HTTP、Telnet、SNMP服务,其余的端口号1024-65535,称为自由端口号,采用本地分配,又称为动态分配的方法。
端口号 | 服务/协议名称 | 描述 |
---|---|---|
80 | HTTP(超文本传输协议) | 用于传输Web页面的标准端口。 |
443 | HTTPS(安全超文本传输协议) | 用于通过加密连接传输Web数据的标准端口。 |
21 | FTP(文件传输协议)控制端口 | 用于文件传输的控制端口,数据端口通常为20。 |
22 | SSH(安全外壳协议) | 用于安全的远程终端连接。 |
25 | SMTP(简单邮件传输协议) | 用于发送电子邮件的标准端口。 |
TCP头部是一个固定长度的部分,通常为20字节(不包含选项字段),但在某些情况下可以包含最多40字节的可选字段。TCP头部的主要组成部分包括:
- 源端口号(Source Port):占16位,用于标识发送端的应用程序或服务。
- 目的端口号(Destination Port):占16位,用于标识接收端的应用程序或服务。
- 序列号(Sequence Number):占32位,用于标识从TCP源端向目的端发送的字节流中的当前字节号。它是按字节进行编号的,确保数据的顺序传输。
- 确认号(Acknowledgment Number):占32位,用于标识发送方期望从对方接收的下一个字节的序列号。只有当ACK标志位为1时,该字段才有效。
- 数据偏移(Data Offset):占4位,用于指示TCP头部的长度(以32位字为单位)。由于TCP头部可能包含可选字段,因此这个字段是必需的,以便接收端能够正确地解析TCP头部。
- 保留字段(Reserved):占6位,目前保留未用,必须全为0。
- 标志位(Flags):占6位,包括多个控制位,如URG(紧急指针有效)、ACK(确认号有效)、PSH(提示接收端立即将数据推送给应用层)、RST(重置连接)、SYN(同步序列编号,用于建立连接)、FIN(结束传输)等。
- 窗口大小(Window Size):占16位,用于指示接收端TCP缓冲区的大小,即接收端还能接收多少字节的数据。这个字段是TCP流量控制的关键部分。
- 校验和(Checksum):占16位,用于检验TCP头部和数据的完整性。发送端计算校验和,接收端进行验证,以确保数据在传输过程中没有被篡改或损坏。
- 紧急指针(Urgent Pointer):占16位,仅当URG标志位为1时有效。它指示了紧急数据的结束位置,即紧急指针字段的值加上序列号字段的值等于紧急数据的最后一个字节的序列号。
- 选项字段(Options):长度可变,最多为40字节。用于支持TCP的扩展功能,如最大报文段长度(MSS)、窗口扩大因子、时间戳等。
TCP三次握手的过程
- 第一次握手:
- 客户端发送SYN报文:客户端首先向服务端发送一个带有SYN(Synchronize Sequence Numbers,同步序列编号)标志的数据包,用于请求建立连接。这个包中包含了客户端的初始序列号(Sequence Number)。
- 客户端状态:发送SYN报文后,客户端进入SYN_SENT状态,等待服务端的响应。
- 第二次握手:
- 服务端回复SYN+ACK报文:服务端收到客户端的SYN报文后,会发送一个带有SYN和ACK(Acknowledgment,确认)标志的数据包作为响应。这个包中包含了服务端自己的初始序列号,并对客户端的序列号进行确认(ACK)。
- 服务端状态:发送SYN+ACK报文后,服务端进入SYN_RCVD状态,等待客户端的确认。
- 第三次握手:
- 客户端发送ACK报文:客户端收到服务端的SYN+ACK报文后,会发送一个带有ACK标志的数据包进行确认。这个包中包含了客户端对服务端序列号的确认(ACK),并带上了自己对服务端序列号的确认(虽然在实际的数据包中,这个确认值通常不是必须的,因为服务端在收到ACK后就知道客户端已经准备好了)。
- 双方状态:发送ACK报文后,客户端进入ESTABLISHED状态,表示连接已经建立。服务端收到这个ACK报文后,也进入ESTABLISHED状态,此时连接正式建立,双方可以开始数据传输。
TCP的可靠传输还体现在TCP使用了确认技术来确保目的设备收到了从源设备发来的数据,并且是准确无误的。
确认技术的工作原理如下: 目的设备接收到源设备发送的数据段时,会向源端发送确认报文,源设备收到确认报文后,继续发送数据段,如此重复。
主机A向服务器A发送TCP数据段,为描述方便假定每个数据段的长度都是500个字节。当服务器A成功收到序列号是M+1499的字节以及之前的所有字节时,会以序列号M+1499+1=M+1500进行确认。另外,由于数据段N+3传输失败,所以服务器A未能收到序列号为M+1500的字节,因此服务器A还会再次以序列号M+1500进行确认。
TCP滑动窗口技术通过动态改变窗口大小来实现对端到端设备之间的数据传输进行流量控制。
主机A和服务器A之间通过滑动窗口来实现流量控制。
主机A向服务器发送4个长度为1024字节的数据段,其中主机的窗口大小为4096个字节。服务器A收到第3个数据段后,缓存区满,第4个数据段被丢弃。服务器以ACK 3073响应,窗口大小调整为3072,表明服务器的缓冲区只能处理3072个字节的数据段。于是主机A改变其发送速率,发送窗口大小为3072的数据段。
TCP四次挥手的过程
- 第一次挥手:
- 客户端发送FIN报文:当客户端完成数据传输后,会向服务端发送一个带有FIN(Finish,结束)标志的数据包,表示客户端希望关闭连接。此时,客户端进入FIN_WAIT_1状态。
- 客户端状态:FIN_WAIT_1,等待服务端的确认。
- 第二次挥手:
- 服务端回复ACK报文:服务端收到客户端的FIN报文后,会发送一个带有ACK(Acknowledgment,确认)标志的数据包进行确认。这个ACK报文的确认号(Acknowledgment Number)是客户端FIN报文的序列号加1,表示服务端已经收到了客户端的关闭请求。此时,服务端进入CLOSE_WAIT状态,表示服务端已经准备好关闭连接,但还需要等待上层应用层关闭连接后才能真正关闭。
- 服务端状态:CLOSE_WAIT,等待上层应用层关闭连接。
- 第三次挥手:
- 服务端发送FIN报文:当服务端完成数据传输并准备好关闭连接时(或者上层应用层已经关闭连接),会向客户端发送一个带有FIN标志的数据包,表示服务端也希望关闭连接。此时,服务端进入LAST_ACK状态,等待客户端的确认。
- 服务端状态:LAST_ACK,等待客户端的确认。
- 第四次挥手:
- 客户端回复ACK报文:客户端收到服务端的FIN报文后,会发送一个带有ACK标志的数据包进行确认。这个ACK报文的确认号是服务端FIN报文的序列号加1,表示客户端已经收到了服务端的关闭请求。此时,客户端会等待一段时间(通常是2MSL,即Maximum Segment Lifetime,报文段最大生存时间),以确保服务端收到了自己的ACK报文后,再进入CLOSED状态,完成连接的释放。
- 客户端状态:TIME_WAIT,等待2MSL时间后,进入CLOSED状态。
UDP(用户数据报协议)
UDP是一种无连接的、不可靠的、基于数据报的传输层协议。当应用程序对传输的可靠性要求不高,但是对传输速度和延迟要求较高时,可以用UDP协议来替代TCP协议在传输层控制数据的转发。UDP将数据从源端发送到目的端时,无需事先建立连接。UDP采用了简单、易操作的机制在应用程序间传输数据,没有使用TCP中的确认技术或滑动窗口机制,因此UDP不能保证数据传输的可靠性,也无法避免接收到重复数据的情况。
UDP不提供重传机制,占用资源小,处理效率高。 一些时延敏感的流量,如语音、视频等,通常使用UDP作为传输层协议。
UDP报文分为UDP报文头和UDP数据区域两部分。报头由源端口、目的端口、报文长度以及校验和组成。UDP适合于实时数据传输,如语音和视频通信。相比于TCP,UDP的传输效率更高、开销更小,但是无法保障数据传输的可靠性。
UDP头部由四个字段组成,每个字段占用16位(2个字节),总长度为8个字节。具体结构如下:
- 源端口(Source Port):16位,用于标识发送方的端口号,长度为2个字节。
- 目的端口(Destination Port):16位,用于标识接收方的端口号,长度也为2个字节。
- 长度(Length):16位,表示整个UDP报文的长度,包括头部和数据部分,长度为2个字节。
- 校验和(Checksum):16位,用于检测UDP数据报在传输过程中是否发生错误,长度为2个字节。
TCP和UDP之间主要区别:
区别点 | TCP | UDP |
---|---|---|
连接性 | 面向连接 | 无连接 |
可靠性 | 可靠传输,通过确认和重传机制保证数据的完整性和正确性 | 不可靠传输,不保证数据的顺序性、完整性和正确性 |
传输形式 | 字节流,无边界,保证顺序和可靠 | 数据报文,一个包一个包发送,有界,可能丢包或乱序 |
拥塞控制 | 有,通过拥塞控制算法调整发送速率,避免网络拥塞 | 无,不受拥塞控制的限制 |
流量控制 | 有,通过滑动窗口等机制控制发送方的发送速率,避免接收方缓冲区溢出 | 无,不直接提供流量控制机制 |
速度和效率 | 相对较低,因为需要建立连接、使用确认重传机制和拥塞控制 | 相对较高,因为没有连接建立和确认重传的开销 |
头部开销 | 较大,通常为20-60字节(无选项时20字节) | 较小,固定为8字节 |
适用场景 | 对数据可靠性要求较高的场景,如文件传输、电子邮件、网页浏览等 | 对数据实时性要求较高的场景,如在线游戏、语音通话、视频流等 |
错误处理 | 检测到错误时,会进行重传或通知上层协议处理 | 不进行错误处理,直接交给上层协议处理 |
报文边界 | 无固定边界,数据以字节流的形式传输 | 有固定边界,每个UDP报文都是独立的 |
协议特性 | 提供全双工通信,允许双方在任何时候发送数据 | 支持一对一、一对多、多对一和多对多的交互通信 |