ios恢复预备份 和 tcp的数据格式
1 server 12.12.12.1
router 12.12.12.2
2 show flash del flash:c1841-advipservicesk9-mz.124-15.T1.bin
3 copy tftp flash
12.12.12.1
c1841-advipservicesk9-mz.124-15.T1.bin
1 show flash
2 copy flash tftp
c1841-advipservicesk9-mz.124-15.T1.bin
1.1.1.2
tcp的数据格式
A
TCP
数据报格式(转)
--
看明白了受益匪浅
2010-10-15 17:53:41|
分类:
网络技术
|
标签:
报文
tcp
|
字号
大中小
订阅
一、
TCP
报文格式
传输控制协议(
TCP
)向上与用户应用程序进程接口,向下与网络层协议
IP
接口。用户应用程序采用首先调用
TCP
(或
UDP
),然后将应用程序数据递交给
TCP
这一方式,在
IP
网络上传送数据。
TCP
将这些数据打包分段并调用
IP
模块向目的主机传送每个数据段。接收方的
TCP
将段中的数据放入接收缓冲器,然后将段重装为应用程序数据,再将这些数据发送到目的的应用程序进程。
尽管
TCP
和
UDP
都使用相同的网络层(
IP
),
TCP
却向应用层提供与
UDP
完全不同的服务。
TCP
提供一种面向连接的、可靠的字节流服务。
源端口号(
16
位),标识主机上发起传送的应用程序;目的端口(
16
位)标识主机上传送要到达的应用程序。源端和目的端的端口号,用于寻找发端和收端应用进程。这两个值加上
I P
首部中的源端
I P
地址和目的端
I P
地址唯一确定一个
T C P
连接。一个
I P
地址和一个端口号有时也称为一个插口(
socket
),插口对(
socket pair
)
(
包含客户
I P
地址、客户端口号、服务器
I P
地址和服务器端口号的四元组
)
可唯一确定互联网络中每个
T C P
连接的双方。
IP+TCP
端口唯一确定一个
TCP
连接。
TCP
协议通过使用
"
端口
"
来标识源端和目标端的应用进程。端口号可以使用
0
到
65535
之间的任何数字。在收到服务请求时,操作系统动态地为客户端的应用程序分配端口号。在服务器端,每种服务在
"
众所周知的端口
"
(
Well-Know Port
)为用户提供服务。
●
序号字段:占
32
比特。用来标识从
TCP
源端向
TCP
目标端发送的数据字节流,它表示在这个报文段中的第一个数据字节。
●
确认号字段:占
32
比特。只有
ACK
标志为
1
时,确认号字段才有效。它包含目标端所期望收到源端的下一个数据字节。
●
头部长度字段:占
4
比特。给出头部占
32
比特的数目。没有任何选项字段的
TCP
头部长度为
20
字节;最多可以有
60
字节的
TCP
头部。
预留:由跟在数据偏移字段后的
6
位构成,预留位通常为
0.
●
标志位字段(
U
、
A
、
P
、
R
、
S
、
F
):占
6
比特。各比特的含义如下:
◆
紧急比特
URG——
当
URG
=
1
时,表明紧急指针字段有效。它告诉系统此报文段中有紧急数据,应尽快传送
(
相当于高优先级的数据
)
。
|
◆
确认比特
ACK——
只有当
ACK
=
1
时确认号字段才有效。当
ACK
=
0
时,确认号无效。
◆
PUSH
比特
PSH——
当
PSH
=
1
时,
表示数据包中的数据必须迅速传播到应用层处理。
|
◆
复位比特
RST(Reset) ——
当
RST
=
1
时,表明
TCP
连接中出现严重差错(如由于主机崩溃或其他原因),必须释放连接,然后再重新建立运输连接。
|
◆
同步比特
SYN——
同步比特
SYN
置为
1
,就表示这是一个连接请求或连接接受报文。
|
◆
终止比特
FIN(FINal)——
用来释放一个连接。当
FIN
=
1
时,表明此报文段的发送端的数据已发送完毕,并要求释放运输连接。
|
●
窗口大小字段:占
16
比特。此字段用来进行流量控制。单位为字节数,这个值是本机期望一次接收的字节数。
●TCP
校验和字段:占
16
比特。对整个
TCP
报文段,即
TCP
头部和
TCP
数据进行校验和计算,并由目标端进行验证。
●
紧急指针字段:占
16
比特。它是一个偏移量,和序号字段中的值相加表示紧急数据最后一个字节的序号。
●
选项、填充字段:占
32
比特。可能包括
"
窗口扩大因子
"
、
"
时间戳
"
等选项。
TCP
首部的主要选项:
最大报文段长度
MSS(Maximum Segment Size)
是
TCP
报文段中的数据字段的最大长度。
MSS
告诉对方
TCP
:
“
我的缓存所能接收的报文段的数据字段的最大长度是
MSS
个字节。
”
窗口扩大因子,用于长肥管道。
时间戳,可用于测量往返时延
RTT
。
TCP
的数据编号与确认
TCP
协议是面向字节的。
TCP
将所要传送的报文看成是字节组成的数据流,并使每一个字节对应于一个序号。
在连接建立时,双方要商定初始序号。
TCP
每次发送的报文段的首部中的序号字段数值表示该报文段中的数据部分的第一个字节的序号。
TCP
的确认是对接收到的数据的最高序号表示确认。接收端返回的确认号是已收到的数据的最高序号加
1
。因此确认号表示接收端期望下次收到的数据中的第一个数据字节的序号。
为提高效率,
TCP
可以累积确认,即在接收多个报文段后,一次确认。
一、
TCP
的流量控制
TCP
采用大小可变的滑动窗口进行流量控制。窗口大小的单位是字节。
TCP
报文段首部的窗口字段写入的数值就是当前给对方设置的发送窗口数值的上限。
发送窗口在连接建立时由双方商定。但在通信的过程中,接收端可根据自己的资源情况,随时动态地调整对方的发送窗口上限值
(
可增大或减小
)
。
发送端要发送
900
字节长的数据,划分为
9
个
100
字节长的报文段,而发送窗口确定为
500
字节。
发送端只要收到了对方的确认,发送窗口就可前移。
发送
TCP
要维护一个指针。每发送一个报文段,指针就向前移动一个报文段的距离。
发送端已发送
400
字节的数据,但只收到对前
200
字节数据的确认,同时窗口大小不变。
现在发送端还可发送
300
字节。
发送端收到对方对前
400
字节数据的确认,但对方通知发送端必须把窗口减小到
400
字节。
现在发送端最多还可发送
400
字节的数据。
利用可变窗口大小进行流量控制
双方确定的窗口值是
400
二、慢启动和拥塞避免
发送端的主机在确定发送报文段的速率时,既要根据接收端的接收能力,又要从全局考虑不要使网络发生拥塞。
因此,每一个
TCP
连接需要有以下两个状态变量:
接收端窗口
rwnd(receiver window)
又称为
通知窗口
(advertised window)
。
拥塞窗口
cwnd(congestion window)
。
接收端窗口
rwnd
和拥塞窗口
cwnd
接收窗口
rwnd
这是接收端根据其目前的接收缓存大小所许诺的最新的窗口值,是来自接收端的流量控制。接收端将此窗口值放在
TCP
报文的首部中的窗口字段,传送给发送端。
拥塞窗口
cwnd
(congestion window)
是发送端根据自己估计的网络拥塞程度而设置的窗口值,是来自发送端的流量控制。
发送窗口的上限值
发送端的发送窗口的上限值应当取为接收端窗口
rwnd
和拥塞窗口
cwnd
这两个变量中较小的一个,即应按以下公式确定:
发送窗口的上限值=
Min[rwnd,cwnd]
当
rwnd < cwnd
时,是接收端的接收能力限制发送窗口的最大值。
当
cwnd < rwnd
时,则是网络的拥塞限制发送窗口的最大值。
慢启动算法的原理
在刚开始发送时,可先将拥塞窗口
cwnd
设置为一个最大报文段
MSS
的数值。
在每收到一个对新的报文段的确认后,将拥塞窗口增加至
2
倍
MSS
的数值。
用这样的方法逐步增大发送端的拥塞窗口
cwnd
,可以使分组注入到网络的速率更加合理。
慢启动和拥塞避免算法的实现举例
当
TCP
连接进行初始化时,将拥塞窗口置为
1
。图中的窗口单位不使用字节而使用
报文段
。
慢启动门限的初始值设置为
16
个报文段,即
ssthresh = 16
。
发送端的发送窗口不能超过拥塞窗口
cwnd
和接收端窗口
rwnd
中的最小值。我们假定接收端窗口足够大,因此现在发送窗口的数值等于拥塞窗口的数值。
在执行慢启动算法时,拥塞窗口
cwnd
的初始值为
1
,发送第一个报文段
M0
。
发送端收到
ACK1
(确认
M0
,期望收到
M1
)后,将
cwnd
从
1
增大到
2
,于是发送端可以接着发送
M1
和
M2
两个报文段。
接收端发回
ACK2
和
ACK3
。发送端每收到一个对新报文段的确认
ACK
,就把发送端的拥塞窗口加倍。现在发送端的
cwnd
从
2
增大到
4
,并可发送
M4—M6
共
4
个报文段。
发送端每收到一个对新报文段的确认
ACK
,就把发送端的拥塞窗口加倍,因此拥塞窗口
cwnd
随着传输次数按指数规律增长。
当拥塞窗口
cwnd
增长到慢开始门限值
ssthresh
时(即当
cwnd = 16
时),就改为执行拥塞避免算法,拥塞窗口按线性规律增长。
假定拥塞窗口的数值增长到
24
时,网络出现超时(表明网络拥塞了)。
更新后的
ssthresh
值变为
12
(即发送窗口数值
24
的一半),拥塞窗口再重新设置为
1
,并执行慢启动算法。
当
cwnd = 12
时改为执行拥塞避免算法,拥塞窗口按按线性规律增长,每经过一个往返时延就增加一个
MSS
的大小。
乘法减小
(multiplicative decrease)
“
乘法减小
“
是指不论在慢启动阶段还是拥塞避免阶段,只要出现一次超时(即出现一次网络拥塞),就把慢启动门限值
ssthresh
设置为当前的拥塞窗口值乘以
0.5
。
当网络频繁出现拥塞时,
ssthresh
值就下降得很快,以大大减少注入到网络中的分组数。
加法增大
(additive increase)
“
加法增大
”
是指执行拥塞避免算法后,当收到对所有报文段的确认就将拥塞窗口
cwnd
增加一个
MSS
大小,使拥塞窗口缓慢增大,以防止网络过早出现拥塞。
进入拥塞避免算法后,拥塞窗口的增大速度由指数增长变为线性增长。
TCP
中默认报文段丢失是由于网络拥塞造成超时而引起的。
“
拥塞避免
”
并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。
“
拥塞避免
”
是说在拥塞避免阶段把拥塞窗口控制为按线性规律增长,使网络比较不容易出现拥塞。
三、
TCP
的重传机制
重传机制是
TCP
中最重要和最复杂的问题之一。
TCP
每发送一个报文段,就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认,就要重传这一报文段。
由于
TCP
的下层是一个互连网环境,
IP
数据报所选择的路由变化很大。因而传输层的往返时延的方差也很大。
往返时延的自适应算法
记录每一个报文段发出的时间,以及收到相应的确认报文段的时间。这两个时间之差就是报文段的往返时延。
将各个报文段的往返时延样本加权平均,就得出报文段的平均往返时延
RTT
。
每测量到一个新的往返时延样本,就按下式重新计算一次平均往返时延
RTT
:
平均往返时延
RTT =a*(
旧的
RTT)+(1-a)*(
新的往返时延样本
)
在上式中,
0=<a<1
。
参数
a
的选择
若
a
很接近于
1
,表示新算出的平均往返时延
RTT
和原来的值相比变化不大,而新的往返时延样本的影响不大
(RTT
值更新较慢
)
。
若选择
a
接近于零,则表示加权计算的平均往返时延
RTT
受新的往返时延样本的影响较大
(RTT
值更新较快
)
。
典型的
a
值为
7/8
。
超时重传时间
RTO(Retransmission Time-Out)
计时器的
RTO
应略大于上面得出的
RTT
,
即:
RTO
=
b * RTT
这里
b
是个大于
1
的系数。
若取
b
很接近于
1
,发送端可及时地重传丢失的报文段,因此效率得到提高。
但若报文段并未丢失而仅仅是增加了一点时延,那么过早地重传反而会加重网络的负担。
因此
TCP
原先的标准推荐将
b
值取为
2
。
往返时间测量的复杂性
TCP
报文段
1
没有收到确认。重传(即报文段
2
)后,收到了确认报文段
ACK
。
如何判定此确认报文段是对原来的报文段
1
的确认,还是对重传的报文段
2
的确认?
Karn
算法
在计算平均往返时延
RTT
时,
TCP
不采用重传报文段的往返时延样本。
由于避免了二义性的存在,这样得出的平均往返时延
RTT
和重传时间就较准确。
当网络时延增大时,
TCP
忽略了重传对往返时延的影响,会造成反复重传。
修正的
Karn
算法
报文段每重传一次,就将重传时间增大一些:
新的重传时间=
r*(
旧的重传时间
)
系数
r
的典型值是
2
。
当不再发生报文段的重传时,才根据报文段的往返时延更新平均往返时延
RTT
和重传时间的数值。
实践证明,这种策略较为合理。
四、
TCP
的传输连接管理
TCP
是面向连接的协议,提供透明、可靠的数据流传输。
传输连接有三个阶段,即:
连接建立
、
数据传送
和
连接释放
。传输连接的管理就是使传输连接的建立和释放都能正常地进行。
在
TCP
的连接建立过程中要解决以下三个问题:
要使每一方能够确知对方的存在。
要允许双方协商一些参数(如最大报文段长度,最大窗口大小,服务质量等)。
能够对传输实体资源(如缓存大小,连接表中的项目等)进行分配。
客户服务器方式
TCP
的连接和建立都是采用客户服务器方式。
主动发起连接建立的应用进程叫做
客户
(client)
。
被动等待连接建立的应用进程叫做
服务器
(server)
。
用三次握手建立
TCP
连接
TCP
连接建立
A
的
TCP
向
B
发出连接请求报文段,其首部中置同步比特
SYN =1
,并选择序号
x
,表明传送数据时的第一个数据字节的序号是
x
。
B
的
TCP
收到连接请求报文段后,如同意,则发回确认。
B
在确认报文段中应置
SYN=1
,其确认号应为
x
+
1
,同时也为自己选择序号
y
。
A
收到此报文段后,向
B
给出确认,其确认号应为
y
+
1
。
A
的
TCP
通知上层应用进程,连接已经建立。
当运行服务器进程的主机
B
的
TCP
收到主机
A
的确认后,也通知其上层应用进程,连接已经建立。
TCP
连接的释放
在数据传输结束后,通信的双方都可以发出释放连接的请求。
TCP
连接释放采用文雅释放过程。
TCP
连接的释放是两个方向分别释放连接,每个方向上连接的释放,只终止本方向的数据传输。
当一个方向的连接释放后,
TCP
的连接就称为
“
半连接
”
或
“
半关闭
”
。当两个方向的连接都已释放,
TCP
连接才完全释放。
TCP
连接释放的过程
TCP
的正常的连接建立和关闭
TCP
有限状态机。
粗实线表示客户的正常路径;
粗虚线表示服务器的正常路径;细线表示不常见的事件