TCP的报文段
作者:追风剑情 发布于:2024-11-25 19:48 分类:其他
TCP在两台设备之间传送的数据单元称为报文段。TCP报文段由首部和数据两部分组成。报文段的起始是首部,其中前 20B 是固定部分,后面有4nB 是根据需要而增加的选项(n必须是整数,若不是整数则需加0填充,以确保TCP首部以32bit边界结束)。选项部分最多40B。即TCP报文段的首部大小是20~60B,如果没有选项,它是20B,而最多是60B。首部后面是从应用程序来的数据,数据部分的大小是0~65495B(65495=65535-20-20,其中第一个20B为IP的首部,第二个20B为TCP的首部)。无任何数据的TCP报文段是合法的,通常被用于确认和控制。TCP报文段既可以用来传送数据,也可以用来建立连接和应答(在一个连接建立或终止时双方交换的报文段仅有TCP首部)。TCP报文段的格式如图8-3所示。
首部固定部分各字段的含义如下:
(1)源端口号和目的端口号。
这两个字段各占16bit。分别标识发送这个报文段的应用程序的端口号和接收这个报文段的应用程序的端口号。即分别标识一个连接的两端的两个应用程序。一个端口号加上其主机的IP地址构成一个 48 bit 的惟一端点。源端点和目的端点合起来标识了一个连接。这些端口号用来将若干高层协议向下复用或将运输层协议向上分用。
源端口号和目的端口号分别标识发送和接收这个报文段的应用程序的端口。
(2)序列号(seq)。
该字段占 32 bit。TCP 是面向字节流的。TCP把一个连接中发送的每一个数据字节都编上号。当 TCP 从进程收到数据字节时,就把它们存储在发送缓存中,并进行编号。编号不一定从0开始,而是随机地开始。TCP在0~232-1之间产生一个随机数作为第一个字节的编号。
首部中的这个序号是指每一个报文段数据的第一个字节的编号。目的进程在知道数据块长度后也就可以确定这个报文段中最后一个字节的序号了。例如,在一个报文段中序号为301,而报文段中共有100B,即其最后一个字节的序号是400。那么在下一个报文段中其序号就是401。
TCP的通信是全双工的。在每一个方向的编号是互相独立的。当连接建立时,每方使用随机数产生器产生初始序号ISN。通常一个连接中每一个方向的初始序号都是不同的。ISN随时间而变化,因此每个连接都将具有不同的ISN。
序号是指本报文段数据的第1个字节的编号,它是从随机数产生器产生的数开始。
(3)确认号。
该字段占32bit。是期望接收的下一个报文段的第一个字节的序号,也就是期望接收对方的下一个报文段首部的序号字段的值。而不是指已经正确接收到的最后一个字节的序号。
如果接收端正确地接收了对方发来的序号为n的报文段,它就把确认号定为n+1。例如,接收端正确地接收了一个报文段,其序号字段的值是2531,而数据长度是1000B,要表明序号在 2531~3530之间的数据均已收到,则确认号不是3530,而应为3531,这就是它期望收到的下一个字节的编号。这也正是TCP确认号是“累计的”概念。“累计的”表示,如果某一方使用X作为确认号,那么就表明它已经正确收到了一直到X-1的所有字节。应当注意的是,这并不表示这一方已经收到了X-1个字节,因为编号不一定从0开始,而是随机产生的。
TCP的通信是全双工的。一个连接中每一个方向的确认号定义了这一方期望接收的下一个字节的编号。
另外,TCP无法对一个报文段进行否认。例如,如果收到1025~2048字节的报文段,但它的校验和错,那么TCP接收端所能做的就是发回一个确认号为1025的确认报文。
注意:确认号是指与本数据报文段反向流动的数据流,而序列号是指与本数据报文段同向流动的数据流。
确认号是指期望接收的对方的下一个字节的序列号。而不是指已经正确接收到的最后一个字节的序列号。TCP 确认号是“累计的”。
(4)首部长度(也称数据偏移)。
该字段占4bit。表明TCP首部的长度共有多少个4B。也就是指出报文段数据开始的地方距离TCP报文段起始处有多远,它是以4B为单位测量的。由于首部长度可以在20~60B之间。因此,这个字段的值可以在5~15之间。即,如果 TCP 首部长度字段值为5,则 TCP 首部是20B;如果 TCP 首部长度字段值为15,则TCP首部是60B。由于 TCP 首部的长度不固定(有可选项),这条信息是必要的。
首部长度以4B 为单位。
(5)保留字段。
该字段占6bit。保留为将来使用。
(6)控制字段。
该字段占6bit。定义了6个不同的控制位或标记。这些位用于TCP的流量控制、连接的建立和终止以及表示数据传送的方式等。这些位中的一个或多个可同时设置。6个标志的说明如下:
1)URG(Urgent):紧急位,用来指示紧急指针有效。URG与紧急指针配合使用,只有当URG标志置1时紧急指针才有效。当报文段中包含紧急数据时,紧急指针被使用,URG置1。例如,已经发送了一个大的程序要在远地的主机上运行,后来发现有些问题要取消这个程序的运行,便从键盘发出中断信号,这就属于紧急数据。紧急指针字段给出本TCP报文段中紧急数据的最后一个字节的序号。当发现紧急数据时,接收方的TCP便通知与连接相关的应用程序进入紧急方式,当所有紧急数据都被消耗完毕后,TCP就告诉应用程序返回正常运行方式。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。
2)ACK(Acknowledgement):确认位,用来指示确认号有效。只有当ACK置1时,确认号字段的值才有效;若ACK置0,则表示该报文段不包含确认信息,即确认号字段的值被忽略。
3)PSH(Push):请求推送。当接收方接收到PSH为1的报文段后,知道发送方调用了推送(Push)操作,应立即将报文交给接收应用进程,而不再等到整个缓存满后才向上交付。如当两个应用进程进行交互式通信时,一端的应用进程希望在键入一个命令后立即能收到另一端的响应,则发送方TCP就可以使用PSH标志通知接收方TCP。发送方使用PSH标志通知接收方将所收到的数据全部提交给接收应用进程。这里的数据包括与PSH标志一起传送的数据以及接收方TCP已经为接收应用进程收到的其他数据。
4)RST(Reset):重建位,用于重新建立连接。当一个连接出现严重差错时,必须要进行重置,即先释放连接再重新建立连接,以通信双方实现重新同步,并初始化某些连接变量。RST还可以用于拒绝一个非法的报文段或一个连接请求。
5)SYN:同步位。用来在建立连接时同步序号。若报文段的 SYN 置1,则这是一个请求连接或同意建立连接的报文,而ACK的值用来区分是哪一种报文。如报文段的SYN=1、ACK=0表明这是一个TCP连接请求;而报文段的SYN=1、ACK=1表明对方同意建立连接。当一端为建立连接而发送它的 SYN 时,它为连接选择一个初始序号ISN。一个 SYN 将占用一个序号。例如,当主机A的TCP向主机B的TCP发出连接请求报文段,其SYN位置1同时选择一个初始序号x为1200;当主机B对主机1的SYN报文段进行确认时,这个报文段中的ACK序号为X+1=1201。
6)FIN(Final):终止位。用于释放一个连接。FIN=1时表示发送端的数据已发送完了,要求释放连接。但当一个连接关闭后,它仍然可以继续接收对方发来的数据。发送FIN通常是关闭应用层的结果。收到一个FIN只意味着在这一方向上没有数据流动。
(7)窗口大小。
该字段占16 bit。TCP 的流量控制由连接的每一端通过声明的窗口大小来实现。窗口大小字段用来定义对方必须维持的窗口值(以字节为单位),即通过该字段控制对方发送的数据量。窗口大小的值表明在确认号字段给出的字节后面还可以发送的字节数,此值的范围是0~65535B,最大长度是65535B。而当窗口大小为0时则表示它收到了包括确认号减1在内的所有数据,但当前接收方缓存已满,不能再接收,希望发送方不要发送数据了。发送方需等收到窗口大小非0的确认报文后,再继续发送。
窗口大小的值表明在确认号字段给出的字节后面还可以发送的字节数。
(8)校验和。
该字段占16 bit。校验和覆盖了整个TCP报文段:TCP首部和数据。在计算校验和时包括TCP首部、用户数据以及一个TCP伪首部。其伪首部的格式如图8-4所示。
TCP伪首部的协议字段为6,即TCP的协议号是6。TCP 校验和的计算和 UDP 校验和的计算相似,其算法就是将所有 16 bit 字按1的补码形式相加,然后对和取反。当接收端接收到此报文后,仍要加上这个伪首部计算校验和。
TCP 校验和是一个强制性的字段,一定是由发送端计算和存储,并由接收端进行验证的。
TCP 报文段中的校验和字段是必须包括的,而 UDP 数据报中是否包括校验和是可选的。
(9)紧急指针。
该字段占16 bit。只有当紧急标志置1时,这个字段才有效,并指示这个报文段中包括紧急数据。紧急指针是一个相对于当前序列号的字节偏移值,把这个值加到TCP 首部中的序号字段上就得出报文段数据部分中最后一个紧急字节的序号。紧急指针使接收端知道紧急数据共有多少个字节。
TCP提供了紧急方式,它使一端可以告诉另一端有些“紧急数据”已经放置在普通的数据流中。即URG被置1,紧急指针被置为一个正的偏移量。只要从接收方当前读取位置到紧急数据指针之间有数据存在,就认为应用程序处于“紧急方式”。在紧急指针通过之后,应用程序便转回到正常方式。
紧急方式的一个例子就是FTP,当交互用户放弃一个文件的传输时,将使用紧急方式来完成这个功能。另外 Telnet 和 Rlogin 从服务器到客户使用紧急方式时,是因为在这个方向上的数据流很可能要被客户的TCP停止(即它通告窗口大小为0)。但是如果服务器进程进入了紧急方式,尽管它不能发送任何数据,服务器TCP也会立即发送紧急指针和置URG为1。当客户TCP接收到这个通知时就会通知客户进程,于是客户可以从服务器读取其输入、打开窗口并使数据流动。
紧急指针是一个相对于当前序列号的字节偏移值,由它可得到报文段数据部分中最后一个紧急字节的序号。
(10)选项。
该字段占 16 bit。在TCP首部中有 40B 的可选信息。最重要的选项是 MSS(Maximum Segment Size)。它指明本端所能接收的TCP最大报文段长度,定义的是数据的最大长度,而不是报文段的最大长度,即其缓存所能接受的报文段中数据字段的最大长度。MSS值的范围在 0~65535 之间。
在连接建立过程中,连接的双方都要宣布它的MSS,并且查看对方给出的MSS。通常每一方都在建立连接的第一个报文段指明这个选项(MSS选项只能出现在SYN报文段中)。在以后的数据传送过程中,MSS取双方给出的较小值。如果一方没有指明这个选项,那么它默认可以接受 536B 的净荷,即MSS默认值为536B(这个默认值允许20B的IP首部和20B的TCP首部以适合 576B 的IP数据报)。
最大报文段长度是由报文段的目的端而不是源端确定的,也就是说,当A、B双方建立连接时,A方定义了B方应发送的 MSS,而B方定义了 A 方应发送的 MSS。所有的 Internet 主机都要求能够接收556B(536+20=556)的TCP报文段。两个方向的最大报文段长度可以不相同。
图8-5 给出了 MSS 选项的格式。
一般说来,MSS应尽可能大些。报文段越大则允许每个报文段传送的数据就越多,这样相对IP和TCP的首部就有更高的网络利用率。但如果TCP报文段太长,那么在IP层传输时就有可能导致分片的发生,而在接收端要进行装配这些数据片以及当传输出错而进行重传时, 都会增大开销。若选择较小的MSS长度,网络的利用率就会降低。
当TCP发送一个SYN(一个本地应用进程发起一个连接或另一端的主机收到了一个连接请求)时,它能将 MSS 值设置为外出接口上的 MTU 长度减去固定的 IP 首部和 TCP 首部长度。对于一个以太网,MSS 值可达 1460B。当双方都在一个本地以太网上时就规定 MSS 为 1460B.
MSS 定义的是 TCP 报文段里数据的最大长度,而不是指包括 TCP 首部的 TCP 报文段的最大长度。
日历
最新文章
随机文章
热门文章
分类
存档
- 2025年3月(4)
- 2025年2月(3)
- 2025年1月(1)
- 2024年12月(5)
- 2024年11月(5)
- 2024年10月(5)
- 2024年9月(3)
- 2024年8月(3)
- 2024年7月(11)
- 2024年6月(3)
- 2024年5月(9)
- 2024年4月(10)
- 2024年3月(11)
- 2024年2月(24)
- 2024年1月(12)
- 2023年12月(3)
- 2023年11月(9)
- 2023年10月(7)
- 2023年9月(2)
- 2023年8月(7)
- 2023年7月(9)
- 2023年6月(6)
- 2023年5月(7)
- 2023年4月(11)
- 2023年3月(6)
- 2023年2月(11)
- 2023年1月(8)
- 2022年12月(2)
- 2022年11月(4)
- 2022年10月(10)
- 2022年9月(2)
- 2022年8月(13)
- 2022年7月(7)
- 2022年6月(11)
- 2022年5月(18)
- 2022年4月(29)
- 2022年3月(5)
- 2022年2月(6)
- 2022年1月(8)
- 2021年12月(5)
- 2021年11月(3)
- 2021年10月(4)
- 2021年9月(9)
- 2021年8月(14)
- 2021年7月(8)
- 2021年6月(5)
- 2021年5月(2)
- 2021年4月(3)
- 2021年3月(7)
- 2021年2月(2)
- 2021年1月(8)
- 2020年12月(7)
- 2020年11月(2)
- 2020年10月(6)
- 2020年9月(9)
- 2020年8月(10)
- 2020年7月(9)
- 2020年6月(18)
- 2020年5月(4)
- 2020年4月(25)
- 2020年3月(38)
- 2020年1月(21)
- 2019年12月(13)
- 2019年11月(29)
- 2019年10月(44)
- 2019年9月(17)
- 2019年8月(18)
- 2019年7月(25)
- 2019年6月(25)
- 2019年5月(17)
- 2019年4月(10)
- 2019年3月(36)
- 2019年2月(35)
- 2019年1月(28)
- 2018年12月(30)
- 2018年11月(22)
- 2018年10月(4)
- 2018年9月(7)
- 2018年8月(13)
- 2018年7月(13)
- 2018年6月(6)
- 2018年5月(5)
- 2018年4月(13)
- 2018年3月(5)
- 2018年2月(3)
- 2018年1月(8)
- 2017年12月(35)
- 2017年11月(17)
- 2017年10月(16)
- 2017年9月(17)
- 2017年8月(20)
- 2017年7月(34)
- 2017年6月(17)
- 2017年5月(15)
- 2017年4月(32)
- 2017年3月(8)
- 2017年2月(2)
- 2017年1月(5)
- 2016年12月(14)
- 2016年11月(26)
- 2016年10月(12)
- 2016年9月(25)
- 2016年8月(32)
- 2016年7月(14)
- 2016年6月(21)
- 2016年5月(17)
- 2016年4月(13)
- 2016年3月(8)
- 2016年2月(8)
- 2016年1月(18)
- 2015年12月(13)
- 2015年11月(15)
- 2015年10月(12)
- 2015年9月(18)
- 2015年8月(21)
- 2015年7月(35)
- 2015年6月(13)
- 2015年5月(9)
- 2015年4月(4)
- 2015年3月(5)
- 2015年2月(4)
- 2015年1月(13)
- 2014年12月(7)
- 2014年11月(5)
- 2014年10月(4)
- 2014年9月(8)
- 2014年8月(16)
- 2014年7月(26)
- 2014年6月(22)
- 2014年5月(28)
- 2014年4月(15)
友情链接
- Unity官网
- Unity圣典
- Unity在线手册
- Unity中文手册(圣典)
- Unity官方中文论坛
- Unity游戏蛮牛用户文档
- Unity下载存档
- Unity引擎源码下载
- Unity服务
- Unity Ads
- wiki.unity3d
- Visual Studio Code官网
- SenseAR开发文档
- MSDN
- C# 参考
- C# 编程指南
- .NET Framework类库
- .NET 文档
- .NET 开发
- WPF官方文档
- uLua
- xLua
- SharpZipLib
- Protobuf-net
- Protobuf.js
- OpenSSL
- OPEN CASCADE
- JSON
- MessagePack
- C在线工具
- 游戏蛮牛
- GreenVPN
- 聚合数据
- 热云
- 融云
- 腾讯云
- 腾讯开放平台
- 腾讯游戏服务
- 腾讯游戏开发者平台
- 腾讯课堂
- 微信开放平台
- 腾讯实时音视频
- 腾讯即时通信IM
- 微信公众平台技术文档
- 白鹭引擎官网
- 白鹭引擎开放平台
- 白鹭引擎开发文档
- FairyGUI编辑器
- PureMVC-TypeScript
- 讯飞开放平台
- 亲加通讯云
- Cygwin
- Mono开发者联盟
- Scut游戏服务器引擎
- KBEngine游戏服务器引擎
- Photon游戏服务器引擎
- 码云
- SharpSvn
- 腾讯bugly
- 4399原创平台
- 开源中国
- Firebase
- Firebase-Admob-Unity
- google-services-unity
- Firebase SDK for Unity
- Google-Firebase-SDK
- AppsFlyer SDK
- android-repository
- CQASO
- Facebook开发者平台
- gradle下载
- GradleBuildTool下载
- Android Developers
- Google中国开发者
- AndroidDevTools
- Android社区
- Android开发工具
- Google Play Games Services
- Google商店
- Google APIs for Android
- 金钱豹VPN
- TouchSense SDK
- MakeHuman
- Online RSA Key Converter
- Windows UWP应用
- Visual Studio For Unity
- Open CASCADE Technology
- 慕课网
- 阿里云服务器ECS
- 在线免费文字转语音系统
- AI Studio
- 网云穿
- 百度网盘开放平台
- 迅捷画图
- 菜鸟工具
- [CSDN] 程序员研修院
- 华为人脸识别
- 百度AR导航导览SDK
- 海康威视官网
- 海康开放平台
- 海康SDK下载
- git download
- Open CASCADE
- CascadeStudio
交流QQ群
-
Flash游戏设计: 86184192
Unity游戏设计: 171855449
游戏设计订阅号
