TCP报文段结构
源端口号:16bit
目标端口号: 16bit
序号: 32bit
序号:
如果初始序号为X, 那么第n个序号就是X + n*MSS 序号具体就是: 上层交互的报文 ,我们按照MSS为单位,切割成为一个个的MSS报文段。 每个TCP都有头部和Body部分, Body部分就是MSS的载荷部分。载荷部分(Body)中的第一个字节就是MSS在整个报文中的偏移量.
确认号:
发送方发送, 接收方接收, 假设接收方发送了ACK为555, 那么就说明接收方接收到了554及其之前的所有字节。而且期望发送方从556的序号开始发送
首部长度:
保留未用:不太清楚
标志位: UAPRSF
接收窗口 : 用于流量控制。 (如果接收窗口为 X, 那么就表示能接收 Xbit的数据)
紧急指针: 不怎么用。
采用自适应的策略和计算。
如果比RTT要长 , 但RTT是变化的 如果太短:太早超时 会产生不必要的重传 如果太长:对报文段丢失 反应太慢,消极
SampleRTT:测量从报文段发出到 收到确认的时间 如果有重传,忽略此次测量 SampleRTT会变化,因此估计的 RTT应该比较平滑 对几个最近的测量值求平均,而 不是仅用当前的SampleRTT
EstimatedRTT = (1- a)*EstimatedRTT + a*SampleRTT
往返延迟时间分布:
设置超时
平均值越大, 我们设置的超时时间就需要变大 往返延迟的变化越大, 就会越分散 , 超时时间就需要设置的越大。
EstimtedRTT + 安全边界时间
SampleRTT会偏离EstimatedRTT多远:
当前的采样值, 离偏差程度的一个平均值。
我们知道IP提供的是不可靠的服务 ,而TCP向上层提供的确是可靠的服务, 那么这是如何实现的呢 ?
TCP在IP不可靠服务的基础上 建立了rdt
通过以下事件触发重传
首先考虑简化的TCP发 送方:
从应用层接收数据:
超时:
收到确认:
ACK7: 表示7之前的都发送了并且已经得到了确认。接下来就需要从8号开始
接收方的事件 | TCP接收方的动作 |
---|---|
所期望序号的报文段按序到达。 所有在期望序号之前的数据都 已经被确认 | 延迟的ACK。对另一个按序报文段的到达最 多等待500ms。如果下一个报文段在这个时 间间隔内没有到达,则发送一个ACK。 |
有期望序号的报文段到达。 另一个按序报文段等待发送ACK (一次到两个报文) | 立即发送单个累积ACK,以确认两个按序报 文段。 |
比期望序号大的报文段乱序到达。 检测出数据流中的间隔 | 立即发送重复的ACK,指明下一个期待字节 的序号 |
能部分或完全填充接收数据间隔 的报文段到达。 | 若该报文段起始于间隔(gap)的低端, 则立即发送ACK。 |
就是在快速定时器超时之前已经收到了某个段的冗余ACK, 那么就需要在某个段还没有到时的情况下,将这个段快速重新传出去 ,而不是等待它超时了再进行重传。
如果发送方收到同一数据 的3个冗余ACK,重传最 小序号的段:
==快速重传:在定时器过时 之前重发报文段==
它假设跟在被确认的数据 后面的数据丢失了 • 第一个ACK是正常的; • 收到第二个该段的ACK,表 示接收方收到一个该段后的 乱序段; • 收到第3,4个该段的ack,表 示接收方收到该段之后的2个 ,3个乱序段,可能性非常大 段丢失了
快速重传算法:
event: ACK received, with ACK field value of y
if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer
}
else { //已确认报文段的一个重复确认
increment count of dup ACKs received for y
if (count of dup ACKs received for y = 3) { //快速重传
resend segment with sequence number y
}
目的就是防止发送方发送的太快, 而使得接收方得缓冲区溢出。
相当于木桶效应, 即使发送方能够发送4096bit得数据。 但是接收方只能接收1080bit的数据, 那么发送方也只能有效发出1080bit的数据。
连接的本质:
在正式交换数据之前,发送方和接收方握手建立通信关系:
为连接做 准备
2次握手失败的场景:
Client发送了建立连接的请求, 然后Server收到连接请求, 并且进行了确认, 然后发送给了Client 。Client接收到了Server的连接确认, 表示Client知道Server是活跃的, 但是之后Client并没有继续发送确认信息。 因为握手已经结束, 所以Server并不知道你Client是否活跃,所以这就是所谓的半连接。
基于2次握手的不可行性, 我们通过三次握手来实现解决。 基本方案是 : 变化的初始序号+双方确认对方的序号(3次握手)
SYN = 1 就是连接请求, Seq = x 就是告诉对方,我将要从x这个字节开始传输。(x就是初始序号)
SYN = 1 表示连接请求, Seq = y 就是告诉Client我要从y这个字节开始传输(y就是server的初始序号)
ACK =1 表示我确认接收到了连接请求,ACKNum 表示我确认接收到了x的请求 ,希望你下次从x+1开始传输
接收到SYN = 1 表示Server是活跃的, 发送SYNACK 的ACK表示 该报文可能包含C-S的数据
接收到了Server的初始序号Seq = y, 本次我就要确认Server给的初始序号。
并且发送ACK = 1表示Client确认了这次的请求。ACKNum = y+1 表示我确认接收到了y的请求 ,希望你下次从y+1开始传输
ACK(y)表示Client是活跃的。
通常第三次握手跟第一次的数据传递是放在一块的。
因为三次握手首先需要将初始序号(x)告诉对方, 然后收到对方的确认之后, 再进行后续的传输,如果说client本次传输的序号不是(x+1) 那么Server就会refuse。 就不会出现老数据传输