TCP报⽂段、序号和确认号的确定、往返时间和超时时间的估计、超时时间加倍、快速重传、GBNSR
TCP 建⽴连接的前两个报⽂段不包含应⽤层数据，第三个报⽂段可以承载有效数据。
建⽴连接以后，TCP将数据引导到该连接到发送缓存⾥，发送缓存是发起三次握⼿期间设置的缓存之⼀。
MSS：最⼤报⽂段长度，报⽂段⾥应⽤数据的最⼤长度。(1460-1480) ⽽不是包含⾸部的TCP报⽂段最⼤长度。
MTU：最⼤链路层帧长度，及最⼤传输单元，⼀般为1500字节。
TCP 报⽂段结构
TCP报⽂段由⾸部字段和⼀个数据字段组成。 MSS限制了报⽂段数据字段的最⼤长度。
TCP的⾸部⼀般是20B，Telnet发送的报⽂段长度也许是21B。
2B的源端⼝号 2B的⽬的端⼝号：⽤于多路复⽤/分解
4B的序号 4B的确认号：⽤于实现可靠数据传输
2B的接收窗⼝：⽤于流量控制，指⽰接收⽅愿意接受的字节数量
2B的检验和：检验数据传输是否出现bit改变
2B的紧急数据指针： TCP必须通知接收端的上层实体
4bit的⾸部长度： TCP报⽂段的⾸部长度，⼀般为20B
6bit的标志字段
1. ACK ：指⽰确认字段中的值是有效的
2. RST、SYN、FIN：连接建⽴和拆除
3. CWR、ECE：明确拥塞通告
这两个在实践的时候并没有被使⽤，为了完整，记录在下。
1. PSH：指⽰接收⽅需要⽴刻将数据交给上层
2. URG：指⽰报⽂段⾥存在着被发送段的上层实体置为“紧急”的数据
1. 序号和确认号
1. TCP⾸部的序号和确认号是可靠传输服务的关键部分
2. TCP把数据看成⽆结构、有序的字节流
3. 序号建⽴在传送的字节流上，⽽不是建⽴在传送的报⽂段的序列之上
4. 报⽂段的序号字段是该报⽂段数据字段⾸字节的序号
5. 确认号是该主机正在在等待的数据的下⼀字节的序号
6. 客户到服务器的数据的确认被装载在服务器到客户到数据的报⽂段中：这中确认被称为捎带在服务器到客户到数据报⽂中的。TCP会对数据流中的每⼀个字节编号，假设数据流为500_000字节的⽂件组成，其中MSS=1000B，数据流的⾸字节编号为0。那么TCP为这个数据流构建500个报⽂段。给⼀个报⽂段分配序号0，第⼆个报⽂段分配序号1000，第三个报⽂段分配序号2000。
每⼀个序号被填⼊到相应TCP报⽂段⾸部的序号字段中。
因为是全双⼯通信，主机A填充进报⽂段的确认号是主机A期望从主机B收到的下⼀字节的序号。
假设主机A已经收到来⾃主机B的编号为0-535的所有字节，主机A就会在它发往主机B的报⽂段的确认号字段中填上536。
当主机在⼀条TCP连接中收到失序报⽂段时该怎么办？
TCP的RFC并没有为此明确任何规则，把这⼀问题留给实现TCP编程⼈员去处理。
有两个基本的选择：
1. 接收⽅⽴即丢弃失序报⽂段
2. 接收⽅保留失序的字节，并等待缺少的字节以填补该间隔。该种⽅式是实践中采⽤的⽅式。
初始序号可以随机选择，减少仍在⽹络中存在的报⽂（主机已经终⽌连接了），被误认为有效报⽂的可能性。
2. 往返时间的估计与超时
2.1 估计往返时间
超时间隔必须⼤于连接的往返时间RTT
1. TCP绝不为已被重传的报⽂计算SampleRTT
2. TCP仅为传输⼀次的报⽂段测量SampleRTT
3. SampleRTT : 从某报⽂段被发出(交IP)到对该报⽂的确认被收到之间的时间量。（仅在某个时刻做⼀次这个测量）
4. 指数加权移动平均， TCP会维护⼀个EstimatedRTT = (1 - alpha) * EsimatedRTT + alpha * SampleRTT， RFC 6298中 alpha = 0.125
5. RTT偏差，DevRTT = (1 - beta) * DevRTT + beta * |SampleRTT - EstimatedRTT|, beta = 0.25, 波动很⼤的时候，DevRTT的值会很
⼤。
2.2 设置超时时间
超时时间 TimeoutInterval = EstimatedRTT + 4 * DevRTT
推荐的初始TimeoutInterval = 1s。
出现超时后，TimeoutInterval的值会加倍。避免以及被确认的后继报⽂段过早出现超时。
只要收到报⽂段后，就会更新新的EstimatedRTT。
隐式NAK机制：连续收到对⼀个特定的报⽂段的3个冗余ACK可以作为对后⾯报⽂段的⼀个隐式NAK。tcp ip协议设置怎么填
TCP使⽤的是
3.TCP可靠数据传输
TCP可靠数据传输服务确保：⼀个进程从其接受缓存中读出的数据是⽆损坏、⽆间隙、⾮冗余和按序到达的数据流。
TCP协议遵循了单⼀定时器的推荐：定时器管理过程仅使⽤单⼀的重传定时器，即有多个已发送但还未被确认的报⽂段。
TCP发送⽅有3个与发送和重传有关的主要事件：从上层接受数据、定时器超时和收到ACK。
1. 从上层接受数据： TCP从应⽤接受数据，将数据封装到⼀个报⽂段中，并把该报⽂段交给IP层。每⼀个报⽂段都包含⼀个序号，这个
序号是第⼀个数据字节的字节流编号。如果此时定时器没有启动，就启动该定时器，过期时间间隔=TimeoutInterval。
⽣存TCP报⽂段
if 定时器没有启动：启动定时器
向IP传递报⽂段
nextseqnum = nextseqnum + length(data)
2. 定时器超时
重传具有最⼩序号但仍未应答的报⽂段
启动定时器
3. 接收ACK
因为TCP采⽤了累计确认，如果y > sendBase，那么ACK是在确认⼀个或者多个先前未被确认的报⽂段。
if (y > sendBase):
sendBase = y
if 仍⽆任何应答报⽂段：启动定时器
介绍⼏种例⼦：
1. A->B: seq = 92, data = 8B
B ->A: ack = 100, 丢失了，
超时
A->B: seq = 92, data = 99
B->A: ack = 100，接收到，数据会丢失
2. A-B: seq = 92, data = 8B
A-B:seq = 100, data = 20B
B-A:ack = 100
B-A: ack = 120
A-B的第⼀段数据报超时，然后重传第⼀段，定时器重启
B-A:ack = 100 和120到达，如果120在新的定时器超时之前到达，那么第⼆个报⽂不会被重传。
如果ack=120到达的时候，第⼀个定时器没有超时，那么第⼀个报⽂也不会进⾏重传。
超时间隔加倍
当出现超时事件发⽣的时候，会将超时间隔设为之前的两倍，⽽不是使⽤estimatedRTT和devRTT估算的值。
但是当另外两个事件发⽣的时候，timeoutinterval ⼜由estimatedRTT和devRTT估算得到。
1. 收到ACK
2. 收到上层数据
快速重传
超时触发重传存在的问题：迫使发送⽅延迟重传丢失的分组，造成了端到端的时延。
TCP接收⽅接收到⼀个数据报，其序号⼤于rcv_base，那么它将对最后⼀个按序字节数据进⾏重复确认（这样就产⽣了⼀个冗余ACK）。⼀旦收到3个冗余ACK，那么TCP就会执⾏快速重传，即在该报⽂段定时器过期之前重传丢失的报⽂段。
GBN/SR？
1. TCP确认是累计的，正确接收但是失序的报⽂时不会被接收⽅逐个确认的。
2. TCP发送⽅仅需维护sendBase以及nextseqnum。
看起来和GBN风格的协议很像，但是：
1. TCP实现会将正确接收但失序的报⽂段缓存起来。
2. 如果n丢失，GBN会重传n、n+1、... N，但是TCP只会重传报⽂段n。
3. 如果对报⽂段n+1的确认段报⽂在报⽂段n超时之前到达，TCP不会重传这个报⽂段n。
RFC2018：允许TCP接收⽅有选择的确认失序报⽂段，⽽不是累计确认最后⼀个正确接收的报⽂段。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。