运输层
概述
1、实际上在计算机网络中,进行通信的真正实体是位于通信两端主机中的进程
2、如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务,运输层协议又称为端到端协议
3、运输层直接为应用进程间的逻辑通信提供服务
4、运输层向上层用户屏蔽下层细节,使应用进程好像是在两个运输层实体之间,有一条端到端的逻辑通信信道
5、根据应用需求的不同,因特网的运输层为应用层提供了两种不同的运输协议,即面向连接的 TCP 和无连接的 UDP
进程标识符 PID
1、标志运行在计算机上的进程
2、不同的操作系统,使用不同格式的进程标识符
3、使运行不同操作系统的计算机的应用进程之间,能够进行网络通信,就必须使用统一的方法对 TCP / IP 体系的应用进程进行标识
TCP / IP 体系的运输层使用端口号来区分应用层的不同应用进程
1、端口号使用 16 比特表示,取值范围:0 ~ 65535
(1)熟知端口号:0 ~ 1023,IANA 把这些端口号指派给 TCP / IP 体系中最重要的一些应用协议,例如:FTP 使用 21/20,HTTP 使用 80,DNS 使用 53
(2)登记端口号:1024 ~ 49151,为没有熟知端口号的应用程序使用,使用这类端口号必须在 IANA 按照规定的手续登记,以防止重复,例如:Microsoft RDP 微软远程桌面使用 3389
(3)短暂端口号:49152 ~ 65535,留给客户进程选择暂时使用,当服务器进程收到客户进程的报文时,就知道了客户进程所使用的动态端口号,通信结束后,这个端口号可供其他客户进程以后使用
2、端口号只具有本地意义,即端口号只是为了标识本计算机应用层中的各进程,在因特网中不同计算机中的相同端口号是没有联系的
发送方的复用、接收方的分用
1、发送方复用
(1)UDP 复用:应用进程所发送的不同应用报文,在运输层使用 UDP 协议进行封装
(2)TCP 复用:应用进程所发送的不同应用报文,在运输层使用 TDP 协议进行封装
(3)IP 复用:不论 UDP 数据报,或 TCP 报文段,在网络层都需要使用 IP 协议封装成 IP 数据报
2、接收方分用
(1)IP 分用:网络层收到 IP 数据报,根据首部中协议字段值,将数据载荷,上交运输层对应协议
(2)UDP 分用:运输层对 UDP 用户数据报进行 UDP 分用,交付给上层相应应用进程
(3)TCP 分用:运输层对 TDP 报文段进行 TDP 分用,交付给上层相应应用进程
TCP / IP 体系的应用层常用协议所使用的运输层熟知端口号
1、UDP 协议字段值 = 17
(1)RIP 端口号 = 520
(2)DNS 端口号 = 53
(3)TFTP 端口号 = 69
(4)SNMP 端口号 = 161
(5)DHCP 端口号 = 67/68
2、TCP 协议字段值 = 6
(1)SMTP 端口号 = 25
(2)FTP 端口号 = 21/20
(3)BGP 端口号 = 179
(4)HTTP 端口号 = 80
(5)HTTPS 端口号 = 443
用户数据报协议(UDP:User Datagram Protocol) | 传输控制协议(TCP:Transmission Control Protocol) |
无连接 | 面向连接 |
支持一对一、一对多、多对一、多对多交互通信 | 每一条 TCP 连接只能有两个端点 EP,只能一对一通信 |
直接打包应用层交付的报文,面向应用报文 | 面向字节流 |
尽最大努力交付,不可靠传输,不使用流量控制、拥塞控制 | 可靠传输,使用流量控制、拥塞控制 |
首部占 8 字节 | 首部最小 20 字节,最大 60 字节 |
适用 IP 电话、视频会议等实时应用 | 适用文件传输等可靠传输应用 |
TCP 流量控制
1、流量控制(flow control):让发送方的发送速率不要太快,要让接收方来得及接收
2、利用滑动窗口机制,在 TCP 连接上实现对发送方的流量控制
(1)接收方利用自己的接收窗口的大小,来限制发送方发送窗口的大小
(2)接收方在确认分组中,rwnd 的取值表示接收窗口大小,发送方接收到确认分组后,会同步发送窗口大小
(3)发送方到达发送窗口大小上限后,需要等待接受方的确认分组,重新同步发送窗口大小
3、存在 0 窗口通知
(1)发送方收到接收方的 0 窗口通知后,应启动持续计时器,持续计时器超时后,向接收方发送 0 窗口探测报文,避免死锁
(2)0 窗口探测报文,仅携带 1 字节数据,接收方收到后,给出现在的接收窗口值,若接收窗口值仍为 0,发送方收到后重启持续计时器;若不为 0,打破死锁
4、TCP 规定,即使接收窗口大小为 0,也必须接收 0 窗口探测报文段、确认报文段、携带紧急数据报文段
5、0 窗口探测报文段,也有重传计时器,若丢失,超时会重传,不会造成死锁
TCP 拥塞控制
1、拥塞(congestion):在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络性能就要变坏
(1)在计算机网络中的链路容量(即带宽)、交换结点中的缓存和处理机等,都是网络资源
(2)若出现拥塞而不进行控制,整个网络的吞吐量将随输入负荷的增大而下降
2、拥塞控制算法
(1)慢开始:slow-start
(2)拥塞避免:congestion avoidance
(3)快重传:fast retransmit
(4)快恢复:fast recovery
3、假定条件
(1)数据是单方向传送,而另一个方向只传送确认
(2)接收方总是有足够大的缓存空间,因而发送方发送窗口的大小由网络的拥塞程度来决定
(3)以最大报文段 MSS 的个数为讨论问题的单位,而不是以字节为单位
4、发送方维护一个拥塞窗口 cwnd 的状态变量,其值取决于网络的拥塞程度,并且动态变化
(1)拥塞窗口 cwnd 的维护原则:只要网络没有出现拥塞,拥塞窗口就再增大一些;但只要网络出现拥塞,拥塞窗口就减少一些
(2)判断出现网络拥塞的依据:没有按时收到应当到达的确认报文(即发生超时重传)
5、发送方将拥塞窗口作为发送窗口 swnd,即 swnd = cwnd
(1)维护一个慢开始门限 ssthresh 状态变量
(2)当 cwnd < ssthresh 时,使用慢开始算法
(3)当 cwnd > ssthresh 时,停止使用慢开始算法,改用拥塞避免算法
(4)当 cwnd = ssthresh 时,既可使用慢开始算法,也可使用拥塞避免算法
TCP Tahoe 版本
1、慢开始
(1)slow-start
(2)慢开始是指一开始向网络注入的报文段少,并不是指拥塞窗口 cwnd 增长速度慢
2、拥塞避免
(1)congestion avoidance
(2)拥塞避免并非指完全能够避免拥塞,而是指在拥塞避免阶段,将拥塞窗口控制为按线性规律增长,使网络比较不容易出现拥塞
3、过程
(1)假设初始值:swnd = cwnd = 1,ssthresh = i
(2)当 cwnd < ssthresh,执行慢开始算法,发送方接收到 j 个对新报文段的确认报文时:cwnd += j,即发送 cwnd 个报文段全部被接收,cwnd *= 2
(3)当 cwnd >= ssthresh,执行拥塞避免算法,每经过一轮往返时间: cwnd += 1
(4)当出现丢失报文段情况后,触发超时重传,判断网络出现拥塞
(5)假设,此时 cwnd = k,重新设置值:ssthresh = cwnd / 2,swnd = cwnd = 1
(6)重新执行慢开始算法
3、缺点:个别报文段在网络中丢失,但实际上网络并未发生拥塞
(1)导致发送方超时重传,并误认为网络发生了拥塞
(2)发送方把拥塞窗口 cwnd 又设置为最小值 1,并错误地启动慢开始算法,因而降低了传输效率
TCP Reno 版本
1、快重传
(1)fast retransmit
(2)让发送方尽早知道发生了个别报文段的丢失,使发送方尽快进行重传,而不是等超时重传计时器超时,再重传
(3)要求接收方不要等待自己发送数据时,才进行捎带确认,而是要立即发送确认
(4)即便收到了失序的报文段,也要立即发出对已收到的报文段的重复确认,即确认号 ack 等于之前已收到的、数据的最后一个字节序号 + 1
(5)发送方一旦收到 3 个连续的重复确认,就将立即重传丢失的报文段,即重传的是确认号 ack 对应的报文段,而不是等该报文段的超时重传计时器超时再重传
2、优点
(1)对于个别丢失的报文段,发送方不会出现超时重传,也就不会误认为出现了拥塞,进而降低拥塞窗口 cwnd 为 1
(2)快重传使整个网络的吞吐量提高约 20%
3、快恢复
(1)fast recovery
(2)发送方一旦收到 3 个重复确认,知道现在只是丢失了个别的报文段,不启动慢开始算法,而执行快恢复算法
(3)实现 1:ssthresh = cwnd / 2,cwnd = ssthresh,开始执行拥塞避免算法
(4)实现 2:ssthresh = cwnd / 2,cwnd = ssthresh + 3,开始执行拥塞避免算法,既然发送方收到 3 个重复的确认,就表明有 3 个数据报文段已经离开了网络,这 3 个报文段不再消耗网络资源,而是停留在接收方的接收缓存中,可见现在网络中不是堆积了报文段而是减少了 3 个报文段,因此可以适当把拥塞窗口扩大些
TCP 重传时间的选择
1、超时重传时间:RTO,Retransmission TimeOut
2、不能直接使用某次测量得到的 RTT 样本来计算 RTO
3、平均往返时间 / 平滑往返时间:RTTs,利用每次测量得到的 RTT 样本,计算加权平均往返时间
(1)第 1 次测量 RTT 样本:RTTs1 = RTT1
(2)第 n 次测量 RTT样本,n > 1:RTTsn = (1 - α) * RTTsn - 1 + α * RTTn
4、上式中:0 <= α < 1
(1)若 α 很接近于 0,则 RTTn 样本对 RTTs 的影响不大
(2)若 α 很接近于 1,则 RTTn 样本对 RTTs 的影响较大
(3)RFC6298 推荐的 α 值为 1 / 8,即 0.125
5、此公式得出的 RTTs 比测量的 RTT 更加平滑
6、显然,RTO 应略大于 RTTs
7、RFC6298 建议使用下式计算 RTO
(1)RTO = RTTs + 4 * RTTD
8、RTT 偏差的加权平均 RTTD
(1)第 1 次测量 RTT 样本:RTTD1 = RTT1 / 2
(2)第 n 次测量 RTT 样本:RTTDn= (1 - β) * RTTDn - 1 + β * |RTTs - RTTn|
(3)RFC6298 推荐 β 值为 1 / 4,即 0.25
9、RTT 测量的准确与否,影响 RTO 准确性
测量 RTT
1、计算 RTO 可能出现的问题
(1)原报文段丢失,触发重传,源主机若误将对重传的确认报文段,当作是对原报文段的确认,所测量的 RTT 偏大,所计算出的 RTTS 和 RTO 就会偏大,降低了传输效率
(2)原报文段超时到达,触发重传,源主机若误将对原报文段的确认报文段,当作是对重传报文段的确认,所测量的 RTT 偏小,所计算出的 RTTS 和 RTO 就会偏小,导致报文段没必要的重传,增大网络负荷
2、针对出现超时重传时无法测准 RTT 的问题,Karn 算法:在计算 RTTs 时,只要报文段重传了,就不采用其 RTT 样本,即出现重传时,不重新计算 RTTs,进而超时重传时间 RTO 也不会重新计算
3、引起了新的问题:报文段的时延突然增大了很多,并且之后很长一段时间都会保持这种时延,因此在原来得出的重传时间内,不会收到确认报文段,于是就重传报文段,但根据 Karn 算法,不考虑重传的报文段的 RTT 样本,这样,RTO 就无法更新,这会导致报文段反复被重传
4、对 Karn 算法修正:报文段每重传一次,就把 RTO 增大一些,典型做法:RTO *= 2
TCP 可靠传输的实现
1、TCP 基于以字节为单位的滑动窗口来实现可靠传输
(1)发送方在未收到接收方的确认时,可将发送窗口内还未发送的数据全部发送出去
(2)接收方只接收序号落入发送窗口内的数据
2、虽然发送方的发送窗口是根据接收方的接收窗口设置的,但在同一时刻,发送方的发送窗口并不总是和接收方的接收窗口一样大
(1)网络传送窗口值需要经历一定的时间滞后,并且这个时间是不确定的
(2)发送方还可能根据网络当时的拥塞情况,适当减小自己的发送窗口尺寸
3、对于不按序到达的数据应如何处理,TCP 并无明确规定
(1)如果接收方把不按序到达的数据一律丢弃,那么接收窗口的管理将会比较简单,但降低网络资源的利用率,因为发送方会重复传送较多的数据
(2)TCP 通常对不按序到达的数据,先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程
4、TCP 要求接收方必须有累积确认、捎带确认机制,这样可以减小传输开销,接收方可以在合适的时候发送确认,也可以在自己有数据要发送时,捎带确认信息
(1)接收方不应过分推退发送确认,否则会导致发送方不必要的超时重传,这反而浪费了网络的资源
(2)[RFC 1122] TCP标准规定,确认推退的时间不应超过 0.5 秒,若收到一连串具有最大长度的报文段,则必须每隔一个报文段就发送一个确认
(3)捎带确认实际上并不经常发生,因为大多数应用程序很少同时在两个方向上发送数据
5、TCP 的通信是全双工通信,通信中的每一方都在发送和接收报文段,因此,每一方都有自己的发送窗口和接收窗口
TCP 的运输连接管理
1、TCP 是面向连接的协议,它基于运输连接来传送 TCP 报文段
2、TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程
3、TCP运输连接有以下三个阶段
(1)三报文握手:建立 TCP 连接
(2)数据传送
(3)四报文挥手:释放 TCP 连接
4、TCP 运输连接管理目的:使运输连接的建立和释放都能正常地进行
5、TCP 建立连接解决三个问题
(1)使 TCP 双方能够确知对方的存在
(2)使 TCP 双方能够协商一些参数(如最大窗口值、是否使用窗口扩大选项、时间截选项、服务质量等)
(3)使 TCP 双方能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配
TCP 建立连接
1、双方进程
(1)TCP 客户:主机的某个应用进程,主动发起 TCP 连接建立
(2)TCP 服务器:主机的某个应用进程,被动等待 TCP 连接建立
2、三报文握手:TCP 客户与服务器,交换三次 TCP 报文段
3、最初,两端 TCP 进程都处于关闭状态(CLOSE)
4、监听状态(LISTEN)
(1)被动打开连接:TCP 服务器进程首先创建传输控制块,被动等待 TCP 客户进程的连接请求
(2)传输控制快:TCP 连接表、指向发送和接收缓存的指针、指向重传队列的指针、当前的发送和接收序号等
5、同步已发送状态(SYN-SENT)
(1)主动打开连接:TCP 客户进程首先创建传输控制块,向 TCP 服务器进程发送 TCP 连接请求报文段
(2)传输控制快:TCP 连接表、指向发送和接收缓存的指针、指向重传队列的指针、当前的发送和接收序号等
(3)TCP 连接请求报文段:首部的同步位 SYN 设置为 1,表明是 TCP 连接请求报文段;序号字段 seq 设置一个初始值 x,作为 TCP 客户进程所选择的初始序号
6、同步已接收状态(SYN-RCVD)
(1)TCP 服务器收到 TCP 连接请求报文段后
(2)若同意建立连接,则向 TCP 客户进程发送 TCP 连接请求确认报文段
(3)TCP 连接请求确认报文段:首部的同步位 SYN、确认位 ACK 设置为 1,表明是 TCP 连接请求确认报文段;序号字段 seq 设置一个初始值 y,作为 TCP 服务器进程所选择的初始序号;确认号字段 ack 设置为 x + 1,对 TCP 客户进程所选择的初始序号的确认
7、连接已建立状态(ESTABLISHED)
(1)TCP 客户进程收到 TCP 连接请求确认报文段后,还要向 TCP 服务器进程发送一个普通的 TCP 确认报文段
(2)普通的 TCP 确认报文段:首部的确认位 ACK 设置为 1,表明是普通的 TCP 确认报文段;序号字段 seq 设置为 x + 1,因为 TCP 客户进程发送的第一个 TCP 报文段序号为 x;确认号字段 ack 设置为 y + 1,对 TCP 服务器进程所选择的初始序号的确认
(3)TCP 服务器进程收到该确认报文段后,也进入连接已建立状态
8、双方进入连接已建立状态
(1)双方可以进行可靠数据传输
(2)TCP 客户进程所发送的下一个数据报文段的序号,仍是 x + 1
9、TCP 规定 SYN 设置为 1 的报文段不能携带数据,但要消耗掉一个序号
10、TCP 规定普通的 TCP 确认报文段可以携带数据,但若不携带数据,则不消耗序号
11、两报文握手的问题
(1)第 1 次 TCP 连接请求报文段,被滞留,触发重传,第 2 次重传报文段被 TCP 服务器进程正常接收
(2)TCP 服务器进程发送一个普通的 TCP 确认报文段,TCP 客户进程正常接收,双方直接进入连接已建立状态
(3)双方传输数据、释放连接后,进入关闭状态
(4)第 1 次被滞留的 TCP 连接请求报文段,到达 TCP 服务器进程,TCP 服务器进程误以为,TCP 客户进程发起一次新的 TCP 连接请求
(6)TCP 服务器进程发送 TCP 连接请求确认报文段,进入连接已建立状态,关闭状态的 TCP 客户进程会丢弃该报文段
12、第 3 次报文目的:防止已失效的连接请求报文段,突然传送到 TCP 服务器,导致错误
TCP 释放连接
1、四报文挥手:TCP 客户与服务器,交换四次 TCP 报文段
2、最初,两端 TCP 进程都处于连接已建立状态(ESTABLISHED)
3、假设使用 TCP 客户进程的应用进程,通知其主动关闭 TCP 连接
4、终止等待 1 状态(FIN-WAIT-1)
(1)TCP 客户进程发送 TCP 连接释放报文段,等待 TCP 服务器进程发出普通的 TCP 确认报文段
(2)TCP 连接释放报文段:首部的终止位 FIN、确认位 ACK 设置为 1,表明是 TCP 连接释放报文段,同时对之前收到的报文段进行确认;序号字段 seq 设置为 u,等于 TCP 客户进程之前已传送过的、数据的最后一个字节序号 + 1;确认号 ack 字段设置为 v,等于 TCP 客户进程之前已收到的、数据的最后一个字节序号 + 1
5、关闭等待状态(CLOSE-WAIT)
(1)TCP 服务器进程收到 TCP 连接释放报文段后,发送一个普通的 TCP 确认报文段
(2)普通的 TCP 确认报文段:首部的确认位 ACK 设置为 1,表明是普通的 TCP 确认报文段;序号字段 seq 设置为 v,等于 TCP 服务器进程之前已传送过的、数据的最后一个字节序号 + 1,匹配(1)的 ack;确认号 ack 字段设置为 u + 1,对 TCP 连接释放报文段的确认
(3)TCP 服务器进程通知高层应用进程:TCP 客户进程要断开与自己的 TCP 连接,释放从 TCP 客户进程,到 TCP 服务器进程的方向的连接
(4)此时,TCP 连接属于半关闭状态:从 TCP 服务器进程,到 TCP 客户进程的方向的连接并未关闭,TCP 客户进程已经没有数据要发送,但若 TCP 服务器进程还有数据要发送,TCP 客户进程仍要接收
(5)半关闭状态可能持续一段时间
6、终止等待 2 状态(FIN-WAIT-2)
(1)TCP 客户进程收到普通的 TCP 确认报文段,等待 TCP 服务器进程发出 TCP 连接释放报文段
(2)若使用 TCP 服务器进程的应用进程,已经没有数据要发送,应用进程通知其 TCP 服务器进程,释放连接
(3)被动关闭连接:TCP 服务器进程释放 TCP 连接,因为 TCP 客户进程主动发起 TCP 连接释放
7、最后确认状态(LAST-ACK)
(1)TCP 服务器进程发送 TCP 连接释放报文段
(2)TCP 连接释放报文段:首部的终止位 FIN、确认位 ACK 设置为 1,表明是 TCP 连接释放报文段,同时对之前收到的报文段进行确认;假定序号 seq 字段为 w,因为半关闭状态下,TCP 服务器进程可能又发送一些数据;确认号 ack 字段为 u + 1,对之前收到的 TCP 连接释放报文段的重复确认
8、时间等待状态(TIME-WAIT)
(1)TCP 客户进程收到 TCP 连接释放报文后,必须针对该报文段发送普通的 TCP 确认报文段
(2)普通的 TCP 确认报文段:首部的确认位 ACK 设置为 1,表明是普通的 TCP 确认报文段;序号 seq 字段设置为 u + 1;确认号 ack 字段设置为 w + 1,对所收到的 TCP 连接释放报文段的确认
9、关闭状态(CLOSE)
(1)TCP 服务器收到 TCP 客户进程发送的、普通的 TCP 确认报文段,进入关闭状态
(2)TCP 客户进程,进入时间等待状态,还要经过 2MSL 后,才进入关闭状态
10、最长报文段寿命
(1)MSL:Maximum Segment Lifetime
(2)RFC793 建议为 2 分钟
(3)TCP 允许不同实现,根据具体情况使用更小 MSL 值
11、取消时间等待状态的问题
(1)TCP 客户进程收到 TCP 连接释放报文后,对该报文段发送普通的 TCP 确认报文段,直接进入关闭状态,而不是时间等待状态
(2)若普通的 TCP 确认报文段丢失,触发超时重传,TCP 服务器进程重传的 TCP 连接释放报文段,不能被处于关闭状态 TCP 客户进程接收
(3)反复重传,TCP 一直处于最后确认状态,无法进入关闭状态
(4)解决:进入时间等待状态,2MSL 后,使本次连接持续时间内,所产生的所有报文段都从网络消失,下一个新的 TCP 连接中,不会出现旧连接的报文段
12、TCP 规定终止位 FIN 设置为 1 的报文段,即使不携带数据,也要消耗一个序号
13、TCP 保活计时器
(1)假设:双方已建立连接,TCP 客户进程所在主机突然故障,TCP 服务器进程不能接收 TCP 客户进程发送的数据
(2)TCP 服务器进程每收到一次 TCP 客户进程的数据,就重新设置并启动保活计时器(2 小时定时)
(3)若保活计时器定时周期内,未收到 TCP 客户进程发来的数据,当保活计时器到时后,TCP 服务器进程就向 TCP 客户进程发送一个探测报文段,以后则每隔 75 秒钟发送 1 次。若连续发送 10 个探测报文段后,仍无 TCP 客户进程的响应,TCP 服务器进程就认为 TCP 客户进程所在主机出了故障,接看就关闭这个连接
TCP 报文段的首部格式
1、TCP 在发送数据时,从发送缓存取出一部分或全部字节,并给其添加一个首部使之成为 TCP 报文段后进行发送
(1)TCP 报文段:首部 + 数据载荷
(2)TCP 的全部功能都体现在它首部中各字段的作用
位 | 0 | 16 | 31 | |||||||
固定首部(20 字节) | 源端口 | 目的端口 | ||||||||
序号 | ||||||||||
确认号 | ||||||||||
数据偏移 | 保留 | URG | ACK | PSH | RST | SYN | FIN | 窗口 | ||
校验和 | 紧急指针 | |||||||||
扩展首部(最大 40 字节) | 选项(长度可变) | 填充 |
2、源端口
(1)占 16 比特,写入源端口号
(2)用来标识发送该 TCP 报文段的应用进程
3、目的端口
(1)占 16 比特,写入目的端口号
(2)用来标识接收该 TCP 报文段的应用进程
4、序号
(1)占 32 比特,取值范围:0 ~ 232 - 1,序号增加到最后一个后,下一个序号就又回到 0
(2)指出本 TCP 报文段数据载荷的第一个字节的序号
5、确认号
(1)占 32 比特,取值范围:0 ~ 232 -1,确认号增加到最后一个后,下一个确认号就又回到 0
(2)指出期望收到对方下一个 TCP 报文段的数据载荷的第一个字节的序号,同时也是对之前收到的所有数据的确认
(3)若确认号 = n,则表明到序号 n - 1 为止的所有数据都已正确接收,期望接收序号为 n 的数据
6、确认标志位 ACK
(1)取值为 1 时,确认号字段才有效;取值为 0 时,确认号字段无效
(2)TCP 规定,在连接建立后,所有传送的 TCP 报文段都必须把 ACK 设置为 1
7、数据偏移
(1)占 4 比特,并以 4 字节为单位
(2)指出 TCP 报文段的数据载荷部分的起始处,距离 TCP 报文段的起始处有多远
(3)这个字段实际上是指出了 TCP 报文段的首部长度
(4)首部固定长度为 20 字节,因此数据偏移字段的最小值为 (0101)2
(5)首部最大长度为 60 字节,因此数据偏移字段的最大值为 (1111)2
8、保留
(1)占 6 比特,保留为今后使用
(2)目前置为 0
9、窗口
(1)占 16 比特,以字节为单位
(2)指出发送本报文段的一方的接收窗口
(3)窗口值作为接收方,让发送方设置其发送窗口的依据
(4)发送窗口 = min(接收窗口, 拥塞窗口)
10、校验和
(1)占 16 比特,检查范围:TCP 报文段的首部、数据载荷
(2)在计算校验和时,要在 TCP 报文段的前面加上 12 字节的伪首部
11、同步标志位 SYN:在 TCP 连接建立时,用来同步序号
12、终止标志位 FIN:用来释放 TCP 连接
13、复位标志位 RST
(1)用来复位 TCP 连接
(2)当 RST = 1 时,表明 TCP 连接出现了异常,必须释放连接,然后再重新建立连接
(3)RST 设置为 1,还可以用来拒绝一个非法的报文段或拒绝打开一个TCP连接
14、推送标志位 PSH
(1)接收方的 TCP 收到该标志位为 1 的报文段,会尽快上交应用进程
(2)不必等到接收缓存都满后,再向上交付
15、紧急标志位 URG
(1)取值为 1 时,紧急指针字段有效
(2)取值为 0 时,紧急指针字段无效
(3)接收方收到紧急标志为 1 的报文段,按照紧急指针字段值,从报文段数据载荷部分取出紧急数据,并直接上交应用进程
16、紧急指针
(1)占 16 比特,以字节为单位,用来指明紧急数据的长度
(2)当发送方有紧急数据时,可将紧急数据插队到发送缓存的最前面,并立刻封装到一个 TCP 报文段中进行发送
(3)紧急指针会指出本报文段数据载荷部分,包含了多长的紧急数据,紧急数据之后是普通数据
17、选项
(1)最大报文段长度 MSS 选项:TCP 报文段数据载荷部分的最大长度
(2)窗口扩大选项:为了扩大窗口,提高吞吐率
(3)时间截选项:用来计算往返时间 RTT / 防正序号绕回 PAWS:用于处理序号超范围的情况
(4)选择确认选项
18、填充
(1)由于选项的长度可变,因此使用填充来确保报文段首部能被 4 整除
(2)因为数据偏移字段,即首部长度字段,是以 4 字节为单位的
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 没有源码,如何修改代码逻辑?
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战