TCP协议回顾

醉经在学习有关网络的知识,这里就总结下TCP建立连接的过程。首先我们简单回顾下TCP协议这个知识点。

一、TCP协议

TCP是Transmission Control Protocol的缩写,即传输控制协议,工作在运输层。TCP是一个面向连接的、可靠地、基于字节流的传输协议。下面我们来解释什么叫做面向连接的?什么叫做可靠的?什么叫做基于字节流的?

1、“TCP是面向连接的”这句话是说当我们想要使用TCP协议进行时,在通信之前通信双方(发送发和接收方)要建立连接,这就是我们常说的的三次握手建立连接。

2、“TCP提供可靠的服务”

(1)使用确认机制。也就是说对于发送方发送一个TCP报文段,如果接受方在规定时间内接受到了,接收方就会立即给发送方返回一个确认报文,发送方收到该确认报文后接着发送后面的数据。一个报文段里边会有该报文所传输内容的初始序列号在seq字段中和该报文长度。确认是对接收到的报文最高序列号的确认,即ack字段为 seq + 长度 + 1.

(2)使用超时重传机制。发送方每发送一个TCP报文段,就会启动一个针对该报文段的定时器。如果在规定的时间内没有收到针对该报文段的确认报文,那么发送方就认为刚刚发送的那个报文段丢失了或者因为传输过程中发生错误被丢弃了。此时发送方就会重新发送该TCP报文段。

注意:一个如果一个TCP报文段在传输过程中发生了错误,那么在接收端会被无条件丢弃,丢弃后不会给发送端返回任何信息。发送端只能通过超时重传处理。

(3)使用TCP报文段首部中的校验和。TCP中校验和字段在首部中,它覆盖了报文段的首部和数据部分。

注意:这一点与IP不同,IP的校验和只校验IP数据报的首部。因为IP数据报是在TCP报文段的基础上加上首部封装得到的,TCP报文段中已经对整个TCP校验过了,IP中只要对IP数据报的首部校验即可。

(4)在接收端对收到的数据重新排序。这是因为TCP报文段要被封装为IP数据报在网络中进行传输,IP数据报在路由器上的传输路径是不确定的,因此会使TCP报文段到达接收端后失序。因此,在接收端对收到的TCP报文段进行重新排序后再交付到应用层。

(5)对重传的数据进行丢弃。

(6)TCP使用滑动窗后协议提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。在每一个TCP报文段中,都会告知对方自己的接受窗口大小,这将防止较快主机致使较慢主机的缓冲区溢出。(TCP可以进行流量控制,防止较快主机致使较慢主机的缓冲区溢出)TCP使用的流量控制协议是可变大小的滑动窗口协议。

(7)将应用程交付下来的数据分割成TCP认为最合适发送的数据(将数据分割成MSS)。UDP则是将应用层交付下来的数据直接封装成UDP数据报传输。

3、“TCP是字节流服务”TCP以8bit(1个字节)为单位进行传输,是字节流在传输。

注意:这点与UDP不同。UDP是面向报文的,将应用层交付下来的整个报发送出去,如果报文长度过大,在IP层需要切片。而TCP对于应用层交付下来的数据进行分割,分割成最适合发送的数据段。这也许是TCP传输的单元叫作TCP报文段,UDP传输的单元叫作UDP数据报的原因吧。

4、TCP是一个全双工的过程。

何谓“全双工”,通信双方互不影响,就是A向B发送数据的同时,B也可以向A发送数据。

二、TCP报文格式

这里我借用了网上的一个图片来给大家说一说TCP报文段的格式(如下图)。


首相我们可以看到每4个字节(32位)为TCP报文段的一行,其中这个TCP报文段包含首部和数据部分。数据的首部长为20字节,下面我们来分析下TCP的首部中各个字段的意思:

(1)源端口(16bit):用于标示发起请求的应用进程。

(2)目的端口(16bit):目的端的应用进程。

(3)序号(32bit):当应用层交付下来的数据太大时,要对数据进行分段然后再放入TCP中。这个序号就是用于标记分块,然后在接收端让目的主机进行重组。

一个TCP报文段的序号是该报文段发送的数据第一个字节的序号。

(4)确认序号(32bit):这个字段就是所说的确认机制。当发送方发送一个TCP报文段后,接收方收到该数据时会返回一个确认报文段以告知发送方我已经收到上一个报文段。

确认序号为期望收到对方下一个报文段数据的第一个序号。

(5)数据偏移(4bit):注意在TCP报文段中有“选项和填充”字段,这个部分是不确定的,因此TCP首部的长度是不确定的。数据偏移就是TCP报文段的数据部分距离TCP报文段起始的距离,它的本质就是实际的首部长度。数据偏移的单位是32bit,4字节。所以TCP报文段的首部最大为15X4 = 60字节,首部占20字节,可选部分最多为40字节。

(6)保留(6bit):保留以后使用。

(7)标示位(6bit):URG、ACK、PSH、RST、SYN、FIN

URG:当URG=1时,表明紧急指针字段有效。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据),而不要按原来的排队顺序来传送。 当URG置1时,发送应用进程就告诉发送方的TCP有紧急数据要传送。

SYN:用于标记该报文段是否有主动请求连接对方的报文。如果SYN=1,说明该报文段要求主动连接对方。

ACK:用于标记该报文段是否有确认功能。当ACK=1时,确认序号字段才有效。如果ACK=0,确认序号字段无效。

FIN:当FIN=1时,标记该报文为请求释放连接的报文。

PSH:告诉对方收到该报文段后是否应该立即把数据推送给上层。如果为1,则表示对方应当立即把数据提交给上层,而不是缓存起来。

RST:如果你收到一个RST=1的报文,说明你与主机的连接出现了严重错误(如主机崩溃),必须释放连接,然后再重新建立连接。或者说明你上次发送给主机的数据有问题,主机拒绝响应。

(8)窗口(16bit):用于告知对方,当前自己接受窗口(缓冲区)最多可以接受多少数据。如果window=0,说明自己的缓冲区已满,通知对方不要再发送数据过来。因此窗口最大为2^16=64KB。

(9)检验和(16bit):数据发送之前,会进行一个校验动作,将计算的校验值放到校验和字段。接收端收到数据后按之前的规则重新计算校验和并与之间的校验和进行比较。如果不相同,则说明数据传输过程中出现错误,接收端会无条件的丢弃该数据报,从而引发发送端超时重传。

(10)紧急指针(16bit)紧急指针仅在URG=1时才有意义,它指出本报文段中的紧急数据的字节数(紧急数据结束后就是普通数据)。因此,紧急指针指出了紧急数据的末尾在报文段中的位置。


<think>好的,我现在需要处理用户的问题,他想了解Modbus TCP与标准TCP协议的区别和联系。首先,我应该回顾之前的对话历史,确保这次回答符合用户的需求,并且保持连贯性。用户之前询问了Modbus RTU和TCP的差异及使用场景,现在转向Modbus TCP与标准TCP的比较,这说明他对Modbus协议的不同实现及其底层网络协议的关系感兴趣。 首先,我需要明确Modbus TCP和标准TCP的关系。Modbus TCP是应用层协议,而标准TCP是传输层协议。Modbus TCP构建在TCP之上,利用TCP的可靠传输机制,但本身定义了特定的应用数据结构和功能码。这可能是一个关键点,需要在回答中突出。 接下来,用户可能需要了解两者的具体区别,比如协议层次、数据封装、端口使用、错误处理机制等。比如,标准TCP负责建立连接、确保数据可靠传输,而Modbus TCP在应用层定义如何打包数据,如MBAP头的结构,功能码等。此外,标准TCP使用端口号来区分应用,Modbus TCP默认使用502端口,这也是一个区别点。 另外,联系方面,Modbus TCP依赖TCP协议来管理数据传输的可靠性,比如错误检测、重传机制等。而Modbus TCP自身不需要像Modbus RTU那样添加CRC校验,因为它依赖TCP的校验机制。这一点在之前的回答中也提到过,需要保持一致性。 用户可能还需要实际应用的例子,比如在工业物联网中,Modbus TCP如何利用标准TCP进行远程监控,而标准TCP本身可以支持多种其他应用协议,如HTTP、FTP等。这可能帮助用户理解两者的不同应用场景。 需要确保回答结构清晰,分点说明区别和联系,可能使用小标题和项目符号。同时,要注意使用中文,遵循之前的格式要求,比如行内公式用$...$,独立公式用$$...$$,但在这个问题中可能涉及公式较少,需要根据内容判断是否添加。 还要生成相关问题,可能需要考虑用户可能的后续问题,比如如何配置Modbus TCP通信,或者Modbus TCP与其他工业协议的区别等。但根据用户当前问题,相关问题应集中在Modbus TCP与标准TCP的对比上,比如协议结构、应用场景、性能差异等。 最后,检查是否有引用之前的注释,但用户提到之前的引用是站内的,可能需要忽略或调整引用标注。根据用户指示,之前的引用仅供参考,现在需要尽可能参考上一次的问题和回答,所以需要确保信息连贯,不重复,但详细说明新的内容。</think>#### Modbus TCP与标准TCP协议的区别与联系 ##### 一、协议层级关系 1. **标准TCP**:属于**传输层协议**(OSI第4层),提供端到端的可靠数据传输服务,包括连接管理、流量控制、错误重传等功能[^1][^4]。 2. **Modbus TCP**:是**应用层协议**(OSI第7层),基于标准TCP实现,定义了工业设备间的数据读写规则(功能码、数据地址映射等)。其报文格式为: $$ \text{Modbus TCP报文} = \text{MBAP报头(7字节)} + \text{Modbus RTU数据帧(去除了CRC)} $$ 例如,读取线圈状态的请求报文:`00 01 00 00 00 06 01 01 00 00 00 08`[^2][^4]。 --- ##### 二、核心差异 | **对比维度** | **标准TCP** | **Modbus TCP** | |--------------------|---------------------------------------|-----------------------------------------| | **协议目标** | 通用数据传输(如网页、文件) | 专用工业设备控制(PLC、传感器) | | **数据封装** | 纯二进制流,无固定结构 | 强制包含MBAP报头+功能码+数据字段 | | **端口号** | 动态分配(HTTP=80, FTP=21等) | 固定使用502端口 | | **校验机制** | 依赖TCP校验(序列号、ACK确认) | 仅依赖TCP校验,无额外CRC | | **通信模式** | 支持全双工 | 基于主从问答模式(单次请求-响应) | --- ##### 三、协同工作机制 Modbus TCP **完全依赖标准TCP的底层传输能力**: 1. **连接建立**:通过TCP三次握手初始化通信链路。 2. **数据传输**:将Modbus应用数据(如读寄存器指令)封装为TCP负载。 3. **错误恢复**:由TCP协议自动处理丢包、乱序等问题,Modbus TCP仅需关注应用层逻辑。 ###### 示例代码(Python使用标准TCP发送Modbus TCP请求): ```python import socket # 标准TCP连接 client = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.connect(("192.168.1.10", 502)) # Modbus TCP报文:读取保持寄存器(功能码0x03) request = bytes.fromhex("0001 0000 0006 01 03 0000 0001") client.send(request) response = client.recv(1024) print("响应数据:", response.hex()) # 示例响应:0001 0000 0005 01 03 02 00FF ``` --- ##### 四、典型应用场景 - **标准TCP**:网页浏览(HTTP)、文件传输(FTP)、电子邮件(SMTP)。 - **Modbus TCP**:工业自动化(PLC控制、SCADA系统)、智能楼宇(HVAC设备监控)、能源管理系统(电表数据采集)[^3][^4]。 --- ##### 五、选择建议 - **需用Modbus TCP的情况**:与工业设备交互(如西门子PLC、施耐德仪表)。 - **需用标准TCP的情况**:自定义私有协议开发或非Modbus设备通信。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值