×

tcp数据包

tcp数据包(TCP 、UDP包的最大长度是多少)

admin admin 发表于2023-03-16 02:34:23 浏览44 评论0

抢沙发发表评论

本文目录

TCP 、UDP包的最大长度是多少

对于UDP协议来说,整个包的最大长度为65535,其中包头长度是65535-20=65515;
对于TCP协议来说,整个包的最大长度是由最大传输大小(MSS,Maxitum Segment Size)决定,MSS就是TCP数据包每次能够传输的最大数据分段。

为了达到最佳的传输效能TCP协议在建立连接的时候通常要协商双方的MSS值,这个值TCP协议在实现的时候往往用MTU值代替(需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes)所以往往MSS为1460。

扩展资料

对于一个以太网来说,TCP的最大报文段长度即MSS一般是1460字节(1500(MTU) - 20(IP head) - 20(TCP head) = 1460 Byte),减去12字节的TCP timestamp option,留给TCP正文数据是 1448字节 。

另外,TCP流量控制采用了滑动窗口机制,发送窗口的大小要小于min(接收端通告的接收窗口大小,发送端拥塞窗口大小)。

TCP重传数据包,是什么意思

tcp是可靠传输协议,就是说数据的发送都需要经过确认,当tcp三次握手建立连接确定好序列号之后,发送端没发送一定数量的数据接收端都要返回一个确认,以确认报文丢失,可以根据序列号知道,那么就会给发送方发送丢失的序列号,这样发送端就会重传数据包

谁来讲解下TCP数据包的具体内容

  TCP数据包结构:

  1-1.源始端口16位,范围当然是0-65535。

  1-2.目的端口,同上。

  2-1.数据序号32位,TCP为发送的每个字节都编一个号码,这里存储当前数据包数据第一个字节的序号。

  3-1.确认序号32位,为了安全,TCP告诉接受者希望他下次接到数据包的第一个字节的序号。

  4-1.偏移4位,类似IP,表明数据距包头有多少个32位。

  4-2.保留6位,未使用,应置零。

  4-3.紧急比特URG—当URG=1时,表明紧急指针字段有效。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据)。

  4-3.确认比特ACK—只有当ACK=1时确认号字段才有效。当ACK=0时,确认号无效。参考TCP三次握手。

  4-4.复位比特RST(Reset) —当RST=1时,表明TCP连接中出现严重差错(如由于主机崩溃或其他原因),必须释放连接,然后再重新 建立运输连接。参考TCP三次握手。

  4-5.同步比特SYN—同步比特SYN置为1,就表示这是一个连接请求或连接接受报文。参考TCP三次握手。

  4-6.终止比特FIN(FINal)—用来释放一个连接。当FIN=1时,表明此报文段的发送端的数据已发送完毕,并要求释放运输连接。

  4-7.窗口字段16位,窗口字段用来控制对方发送的数据量,单位为字节。TCP连接的一端根据设置的缓存空间大小确定自己的接收窗口 大小,然后通知对方以确定对方的发送窗口的上限。

  5-1.包校验和16位,包括首部和数据这两部分。在计算检验和时,要在TCP报文段的前面加上12字节的伪首部。

  5-2.紧急指针16位,紧急指针指出在本报文段中的紧急数据的最后一个字节的序号。

  6-1.可选选项24位,类似IP,是可选选项。

  6-2.填充8位,使选项凑足32位。

  7-1.用户数据。

如何判断TCP数据包是否发送成功

1. TCP发送接口:send()
  TCP发送数据的接口有send,write,sendmsg。在系统内核中这些函数有一个统一的入口,即sock_sendmsg()。由于
TCP是可靠传输,所以对TCP的发送接口很容易产生误解,比如sn = send(...);
错误的认为sn的值是表示有sn个字节的数据已经发送到了接收端。其实真相并非如此。
我们知道,TCP的发送和接收在在内核(linux)中是有对应的缓冲的:
struct sock{
...
struct sk_buff_head receive_queue; //接收的数据报队列
struct sk_buff_head write_queue; //即将发送的数据报队列
...
}
  对于发送端而言,用户空间调用send(data)等发送接口将数据发送,内核会将data拷贝到内核空间的socket对应的缓冲中,即sock.write_queue。而send()函数的返回值仅仅是表示本次send()调用中成功拷贝的字节数(用户空间-》内核空间对应的sock缓冲队列)。具体发送和接收端的接收就由TCP协议完成,虽然TCP是可靠传输,但是这个前提是发送端和接收端的网络是连接的,否则你懂得。这样,对于调用send()发送的用户而言,如果想要确定接收方是否成功接受数据,就得需要靠其他的办法查询。
2. send()阻塞和非阻塞
  
前面已说过,sn=send(data)负责将数据拷贝到内核空间,而具体发送是有tcp后续完成(这里面就包括流量控制等)。对已阻塞和非阻塞仅仅是对于数据从用空空间拷贝到内核空间的发送缓冲这段期间而言的。
1. 如果发送缓冲剩余空间大于欲发送data的字节数,对于阻塞和非阻塞而言都能成功将数据拷贝至内核缓冲,返回的sn即等于欲发送的数据的字节数。
2.如果发送缓冲剩余空间小于欲发送data的字节数,
a. 那么阻塞模式会进行阻塞,等待内核缓冲的空闲空间,然后继续将数据拷贝到内核缓冲中,直到全部拷贝为止。返回rn即为data的数据量。
b. 非阻塞模式,当内核发送缓冲被填满后,立即返回。rn等于data中已被拷贝到发送缓冲的数据量。
3. 如何判定接收成功接收数据?
1.接收端回复应答信息。
这个方法比较土,但也是比较实用的。
2.计算发送端sock已发送数据量

TCP数据包是什么

概念性的东西就是以下内容:简单的来说,就是一种传输协议发出的一段数据源传输控制协议(Transmission Control Protocol, TCP)
TCP协议主为了在主机间实现高可靠性的包交换传输协议。本文将描述协议标准和实现的一些方法。因为计算机网络在现代社会中已经是不可缺少的了,TCP协议主要在网络不可靠的时候完成通信,对军方可能特别有用,但是对于政府和商用部门也适用。TCP是面向连接的端到端的可靠协议。它支持多种网络应用程序。TCP对下层服务没有多少要求,它假定下层只能提供不可靠的数据报服务,它可以在多种硬件构成的网络上运行。下面的图是TCP在层次式结构中的位置,它的下层是IP协议,TCP可以根据IP协议提供的服务传送大小不定的数据,IP协议负责对数据进行分段,重组,在多种网络中传送。
TCP的上面就是应用程序,下面是IP协议,上层接口包括一系列类似于操作系统中断的调用。对于上层应用程序来说,TCP应该能够异步传送数据。下层接口我们假定为IP协议接口。为了在并不可靠的网络上实现面向连接的可靠的传送数据,TCP必须解决可靠性,流量控制的问题,必须能够为上层应用程序提供多个接口,同时为多个应用程序提供数据,同时TCP必须解决连接问题,这样TCP才能称得上是面向连接的,最后,TCP也必须能够解决通信安全性的问题。
网络环境包括由网关(或其它设备)连接的网络,网络可以是局域网也可以是一些城域网或广域网,但无论它们是什么,它们必须是基于包交换的。主机上不同的协议有不同的端口号,一对进程通过这个端口号进行通信。这个通信不包括计算机内的I/O操作,只包括在网络上进行的操作。网络上的计算机被看作包传送的源和目的结点。特别应该注意的是:计算机中的不同进程可能同时进行通信,这时它们会用端口号进行区别,不会把发向A进程的数据由B进程接收的。
进程为了传送数据会调用TCP,将数据和相应的参数传送给TCP,于是TCP会将数据传送到目的TCP那里,当然这是通过将TCP包打包在IP包内在网络上传送达到的。接收方TCP在接收到数据后会通信上层应用程序,TCP会保证接收数据顺序的正确性。虽然下层协议可能不会保证顺序是正确的。这里需要说明的是网关在接收到这个包后,会将包解开,看看是不是已经到目的地了,如果没有到,应该走什么路由达到目的地,在决定后,网关会根据下一个网络内的协议情况再次将TCP包打包传送,如果需要,还要把这个包再次分成几段再传送。这个落地检查的过程是一个耗时的过程。从上面,我们可以看出TCP传送的基本过程,当然具体过程可能要复杂得多。
在实现TCP的主机上,TCP可以被看成是一个模块,和文件系统区别不大,TCP也可以调用一些操作系统的功能,TCP不直接和网络打交道,控制网络的任务由专门的设备驱动模块完成。TCP只是调用IP接口,IP向TCP提供所有TCP需要的服务。通过下图我们可以更清楚地看到TCP协议的结构。
上面已经说过了,TCP连接是可靠的,而且保证了传送数据包的顺序,保证顺序是用一个序号来保证的。响应包内也包括一个序列号,表示接收方准备好这个序号的包。在TCP传送一个数据包时,它同时把这个数据包放入重发队列中,同时启动记数器,如果收到了关于这个包的确认信息,将此包从队列中删除,如果计时超时则需要重新发送此包。请注意,从TCP返回的确认信息并不保证最终接收者接收到数据,这个责任由接收方负责。
每个用于传送TCP的通道都有一个端口标记,因为这个标记是由每个TCP终端确定的,因此TCP可能不唯一,为了保证这个数值的唯一,要使用网络地址和端口号的组合达到唯一标识的目的,我们称这个为了套接字(Socket),一个连接由连接两端的套接字标识,本地的套接字可能和不同的外部套接字通信,这种通信是全双工的。
通过向本地端口发送OPEN命令及外部套接字参数建立连接,TCP返回一个标记这个连接的名称,以后如果用户需要使用这个名称标记这个连接。为了保存这个连接的信息,我们假设有一个称为传输控制块(Transmission Control Block,TCB)的东西来保存。OPEN命令还指定这个连接的建立是主动请求还是被动等待请求。下面我们要涉及具体的功能了,TCP段以internet数据报的形式传送。IP包头传送不同的信息域,包括源地址和目的地址。TCP头跟在internet包头后面,提供了一些专用于TCP协议的信息。下图是TCP包头格式图:
源端口:16位;
目的端口:16位
序列码:32位,当SYN出现,序列码实际上是初始序列码(ISN),而第一个数据字节是ISN+1;
确认码:32位,如果设置了ACK控制位,这个值表示一个准备接收的包的序列码;
数据偏移量:4位,指示何处数据开始;
保留:6位,这些位必须是0;
控制位:6位;
窗口:16位;
校验位:16位;
优先指针:16位,指向后面是优先数据的字节;
选项:长度不定;但长度必须以字节记;选项的具体内容我们结合具体命令来看;
填充:不定长,填充的内容必须为0,它是为了保证包头的结合和数据的开始处偏移量能够被32整除;
 
我们前面已经说过有一个TCB的东西了,TCB里有存储了包括发送方,接收方的套接字,用户的发送和接收的缓冲区指针等变量。除了这些还有一些变量和发送接收序列号有关:
发送序列变量
SND.UNA - 发送未确认
SND.NXT - 发送下一个
SND.WND - 发送窗口
SND.UP - 发送优先指针
SND.WL1 - 用于最后窗口更新的段序列号
SND.WL2 - 用于最后窗口更新的段确认号
ISS - 初始发送序列号
 
接收序列号
RCV.NXT - 接收下一个
RCV.WND - 接收下一个
RCV.UP - 接收优先指针
IRS - 初始接收序列号
下图会帮助您了解发送序列变量间的关系:
当前段变量
SEG.SEQ - 段序列号
SEG.ACK - 段确认标记
SEG.LEN - 段长
SEG.WND - 段窗口
SEG.UP - 段紧急指针
SEG.PRC - 段优先级
连接进程是通过一系列状态表示的,这些状态有:LISTEN,SYN-SENT,SYN-RECEIVED,ESTABLISHED,FIN-WAIT-1,FIN-WAIT-2,CLOSE-WAIT,CLOSING,LAST-ACK,TIME-WAIT和 CLOSED。CLOSED表示没有连接,各个状态的意义如下:
LISTEN - 侦听来自远方TCP端口的连接请求;
SYN-SENT - 在发送连接请求后等待匹配的连接请求;
SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认;
ESTABLISHED - 代表一个打开的连接,数据可以传送给用户;
FIN-WAIT-1 - 等待远程TCP的连接中断请求,或先前的连接中断请求的确认;
FIN-WAIT-2 - 从远程TCP等待连接中断请求;
CLOSE-WAIT - 等待从本地用户发来的连接中断请求;
CLOSING - 等待远程TCP对连接中断的确认;
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认;
TIME-WAIT - 等待足够的时间以确保远程TCP接收到连接中断请求的确认;
CLOSED - 没有任何连接状态;
TCP连接过程是状态的转换,促使发生状态转换的是用户调用:OPEN,SEND,RECEIVE,CLOSE,ABORT和STATUS;传送过来的数据段,特别那些包括以下标记的数据段SYN,ACK,RST和FIN;还有超时,上面所说的都会时TCP状态发生变化。
 
下面的图表示了TCP状态的转换,但这图中没有包括错误的情况和错误处理,不要把这幅图看成是总说明了。
 
3.3. 序列号
请注意,我们在TCP连接中发送的字节都有一个序列号。因为编了号,所以可以确认它们的收到。对序列号的确认是累积性的,也就是说,如果用户收到对X的确认信息,这表示在X以前的数据(不包括X)都收到了。在每个段中字节是这样安排的:第一个字节在包头后面,按这个顺序排列。我们需要认记实际的序列空间是有限的,虽然很大,但是还是有限的,它的范围是0到2的32次方减1。我想熟悉编程的一定知道为什么要在计算两个段是不是相继的时候要使用2的32次方为模了。TCP必须进行的序列号比较操作种类包括以下几种:
(a) 决定一些发送了的但未确认的序列号;
(b) 决定所有的序列号都已经收到了;
(c) 决定下一个段中应该包括的序列号。
对于发送的数据TCP要接收确认,处理确认时必须进行下面的比较操作:
SND.UNA = 最老的确认了的序列号;
SND.NXT = 下一个要发送的序列号;
SEG.ACK = 接收TCP的确认,接收TCP期待的下一个序列号;
SEG.SEQ = 一个数据段的第一个序列号;
SEG.LEN = 数据段中包括的字节数;
SEG.SEQ+SEG.LEN-1 = 数据段的最后一个序列号。
请注意下面的关系:
SND.UNA 《 SEG.ACK =《 SND.NXT
如果一个数据段的序列号小于等于确认号的值,那么整个数据段就被确认了。而在接收数据时下面的比较操作是必须的:
RCV.NXT = 期待的序列号和接收窗口的最低沿;
RCV.NXT+RCV.WND-1 = 最后一个序列号和接收窗口的最高沿;
SEG.SEQ = 接收到的第一个序列号;
SEG.SEQ+SEG.LEN-1 = 接收到的最后一个序列号;
 
上面几个量有如下关系:
RCV.NXT =《 SEG.SEQ 《 RCV.NXT+RCV.WND 或 RCV.NXT =《 SEG.SEQ+SEG.LEN-1 《 RCV.NXT+RCV.WND
测试的第一部分是检查数据段的开始部分是否在接收窗口中,第二部分是检查数据段的结束部分是否也在接收窗口内;上面两个检查通过任何一个就说明它包括窗口要求的数据。实际中的情况会更复杂一些,因为有零窗口和零数据段长,因此我们有下面四种情况:
段长度
接收窗口
测试
0
0
SEG.SEQ = RCV.NXT
0
》0
RCV.NXT =《 SEG.SEQ 《 RCV.NXT+RCV.WND
》0
0
不可接受
》0
》0
RCV.NXT =《 SEG.SEQ 《 RCV.NXT+RCV.WND或RCV.NXT =《 SEG.SEQ+SEG.LEN-1 《 RCV.NXT+RCV.WND
请注意接收窗口的大小可以为零,在窗口为零时它只用来接收ACK信息,因此对于一个TCP来说,它可以使用零大小窗口在发送数据的同时接收数据。即使接收窗口的大小为零,TCP必须处理所有接收到信息的RST和URG域。
我们也应用计数的方式保护了一些特定的控制信息,这是通过隐式地使用一些控制标记使数据段能够可靠地重新发送(或确认)为达到的。控制信息并不在段数据空间中传送,因此,我们必须采用隐式指定序列号进行控制。SYN和FIN是需要保护的控制量,这两个控制量也只在连接打开和关闭时使用。SYN被认为是在第一个实际数据之间的数据,而FIN是最后一个实际数据之后的数据。段长度(SEG.LEN)包括数据和序列号空间,如果出现了SYN,那么SEG.SEQ是SYN的序列号。
初始序列号选择
协议对于特定连接被重复使用没有什么限制。连接是由一对套接字定义的。新的连接实例被定义为连接的另一次恢复,这就带来了问题:TCP如果确定多个数据段是从以前连接的另一次恢复中取得的呢?这个问题在连接迅速打开和关闭,或因为内存原因被关闭然后又迅速建立后显示特别突出。
为了避免混乱,用户必须避免因此恢复使用某一连接,而使序列号发生混乱。我们必须保证序列号的正确性,即使TCP失败,根本不知道以前的序列号是什么的情况下也要保证序列号的正确性。当新的连接被创建时,产生一个新的初始序列号(ISN)产生子,它用来选择一个新的32位ISN。产生子和32位时钟的低度位字节相关,低位字节的刷新频率大概是4微秒,因此ISN的循环时间大概是4.55小时。因此我们把网络包的最长生存时间(MSL)小于4.55小时,因此我们可以认为ISN是唯一的。对于每个连接都有发送序列号和接收序列号,初始发送序列号(ISS)由发送TCP选择,而初始接收序列号是在连接建立过程中产生的。
对于将要连接或初始化的连接,两个TCP必须和对方的初始序列号同步。这通过交换一个控制位SYN和初始序列号完成。我们把带有SYN的数据段称为“SYNs“。同步的获得过程这里就不重复了,每方必须发送自己的序列号并返回对对方序列号的确认。
1) A --》 B SYN 本方序列号是X
2) A 《-- B ACK 本方序列号被确认
3) A 《-- B SYN 对方序列号是Y
4) A --》 B ACK 确认对方序列号
上面的第2步和第3步可以合并,这时可以成为3阶段,所以我们可以称它为三消息握手。这个过程是必须的,因为序列号不和全局时钟关联,TCP也可以有不同的机制选择ISN。接收到第一个SYN的接收方不可能知道这个数据段是不是被延时,除非它记住了在连接上使用的最近的序列号(这通常是不可能的),因此它必须要求发送者确认。
为了保证TCP获得的确认是刚才发送的段产生的,而不是仍然在网络中的老数据段产生的,因此TCP必须在MSL时间之内保持沉默。在本文中,我们假设MSL=2小时,这是出于工程的需要,如果用户觉得可以,他可以改变MSL。请注意如果TCP重新初始化,而内存中的序列号正在使用,不需要等待,但必须确认使用的序列号比当前使用的要大。
如果一台主机在未保留任何序列号的情况下失败,那么它应该在MSL时间之内不发出任何数据段。下面将会这一情况进行说明。TCP的实现可以不遵守这个规定,但是这会造成老数据被当成新数据接收,而新数据被当成老数据拒绝的情况。
每当数据段形成并进入输出队列,TCP会为它指定序列空间中的一个值。TCP中多复本检测和序列算法都依赖于这个地址空间,在对方发送或接收之前不会超过2的32次方个包存在于输出队列中。所有多余的数据段都会被删除。如果没有这个规定,会出现多个数据段被指定同一个序列号的情况,会造成混乱。数据段中序列号的多少和数据段中的字节数一样多。
在通常情况下,TCP保留下一个要发送的序列号和还未确认的最老的序列号,不要在没有确认的时候就再次使用,这样会有些风险,也正是因为这样的目的,所以序列空间很大。对于2M的网络,要4.5小时来耗尽序列空间,因为一个数据段可能的最大生存时间也不过十几分之一秒,这就留下了足够的空间;而在100M的网络上需要5.4分钟,虽然少了点,但也可以了。
如果在实现TCP时没有为保存序列号留下空间,那清除多余的包可能就不能实现了,因此推荐这种类型的TCP实现最好在失败后等待MSL时间,这样保证多余的包被删除。这种情况有时候也可能会出现在保留序列号的TCP实现中。如果TCP在选择一个另一个TCP连接正在使用的序列号时,这台主机突然失败了,这就产生了问题。这个问题的实质在于主机不知道它失败了多久,也不知道多余的复本是不是还在网络中。
处理这种问题的方法是等待MSL时间,如果不这样就要冒着对方错误接收数据的危险,要等待的时间也就称为“沉默时间”。实现者可以让用户选择是不是等待,但是无论用户如何也不见得非要等待MSL时间。
3.4. 建立一个连接
建立连接应用的是三消息握手。如果双方同时都发送SYN也没有关系,双方会发现这个SYN中没有确认,于是就知道了这种情况,通常来说,应该发送一个“reset“段来解决这种情况。三消息握手减少了连接失败的可能性。下面就是一个例子,在尖括号是的就是数据段中的内容和标记。其它的就不多说了。
在第2行,TCP A发送SYN初始化序列号,表示它要使用序列号100;第3行中,TCP B给出确认,并且期待着A的带有序列号101的数据段;第4行,TCP A给出确认,而在第5行,它也给出确认,并发送了一些数据,注意第4行的序列号与第5号的一样,因为ACK信息不占用序列号空间内的序列号。同时产生请求的情况如下图所示,只复杂一点。
使用三消息握手的主要原因是为了防止使用过期的数据段。为了这个目的,必须引入新的控制消息,RESET。如果接收TCP处理非同步状态,在接收到RESET后返回到LISTEN状态。如果TCP处理下面几种状态ESTABLISHED,FIN-WAIT-1,FIN-WAIT-2,CLOSE-WAIT,CLOSING,LAST-ACK,TIME-WAIT时,放弃连接并通过用户。我们下面就详细说明后一种情况。
通过上面的例子,我们可以看出TCP连接是如何从过期数据段的干扰下恢复的。请注意第4行和第5行中的RST(RESET信号)。
半开连接和其它非正常状态
如果一方在未通过另一方的情况下关闭连接,或双方虽然失败而不同步的情况我们称为半开连接状态。在一方试图发送数据时连接会自动RESET。然而这种情况毕竟属于不正常情况。应该做出相应的处理。如果A处的连接已经关闭,B处并不知道。当B希望发送数据到A时,就会收到RESET信号,表示这个TCP连接有误,要中止当前连接。
假设A和B两个进程相互通信的时候A的TCP发生了失败,A依靠操作系统支持TCP的存在,通常这种情况下会有恢复机制起作用,当TCP重新恢复的时候,A可能希望从恢复点开始工作。这样A可能会试图OPEN连接,然后在这个它认为还是打开的连接上传送数据,这时A会从本地(也就是A的)TCP上获得错误消息“未打开连接”。A的TCP将发送包括SYN的数据段。下面的例子将显示这一过程:
上面这个例子中,A方收到的信息并没有确认任何东西,这时候A发现出了问题,于是发送了RST控制信息。另一种情况是发生在A失败,而B方仍然试图发送数据时,下面的例子可以表示这种情况,请注意第2行中A对B发送来的信息不知所云。
在下面的例子中,A方和B方进行的被动连接,它们都在等待SYN信息。过期的包传送到B方使B回应了,而收到回应的A却发现不对头,传送RST控制信息,B方返回被动LISTEN状态。
现实中的情况太多了,我们列举一些产生RST控制信息的规则如下:通常情况下,RST在收到的信息不是期待的信息时产生。如果在不能确定时不要轻易发送RST控制信息。下面有三类情况:
如果连接已经不存在,而发送来的消息又不是RST,那么要返回RST。如果想拒绝对不存在的连接进行SYN,可以使用这种办法。如果到达的信息有一个ACK域,返回的RST信息可以从ACK域中取得序列号,如果没有这个域,就把RST的序列号设置为0,ACK域被设备为序列号和到达段长度之和。连接仍然处于CLOSE状态。
如果连接处于非同步状态(LISTEN,SYN-SENT,SYN-RECEIVED),而且收到的确认是对未发出包的确认或是接收到数据段的安全级别与不能连接要求的相一一致时,就发送RST。如果SYN未被确认时,而且收到的数据段的优先级比要求的优先级要高,那么要么提高本地优先级(得事先征得用户和系统的许可)要么发送RST;如果接收数据段的优先级比要求的优先级低,就算是匹配了,当然如果对方发现优先级不对提高了优先级,在下一个包中提高了优先级,这就不算是匹配了。如果连接已经进入SYN,那么接收到数据段的优先级必须和本地优先级一样,否则发送RST。如果到达的信息有一个ACK域,返回的RST信息可以从ACK域中取得序列号,如果没有这个域,就把RST的序列号设置为0,ACK域被设备为序列号和到达段长度之和。连接仍然处于与原来相同的状态。
如果连接处于同步状态(ESTABLISHED,FIN-WAIT-1,FIN-WAIT-2,CLOSE-WAIT,CLOSING,LAST-ACK,TIME-WAIT),任何超出接收窗口的序列号的数据段都产生如下结果:发出一个空确认数据段,此段中包括当前发送序列号,另外还包括一个确认指出希望接收的下一个数据段的序列号,连接仍然保存在原来的状态。如果因为安全级,优先级之类的问题,那就发送RST信号然后进入CLOSED状态。

什么是 TCP 数据包我的防火墙拦截这种数据包是因为有人刻意袭击我吗

我们学习过什么是“数据包”。理解数据包,对于网络管理的网络安全具有至关重要的意义。比如,防火墙的作用本质就是检测网络中的数据包,判断其是否违反了预先设置的规则,如果违反就加以阻止。图1就是瑞星个人版防火墙软件设置规则的界面。细心的读者会发现,图1中的“协议”栏中有“TCP”、“UDP”等名词,它们是什么意思呢?现在我们就来讲讲什么是TCP和UDP。
面向连接的TCP
“面向连接”就是在正式通信前必须要与对方建立起连接。比如你给别人打电话,必须等线路接通了、对方拿起话筒才能相互通话。
图1
TCP(Transmission Control Protocol,传输控制协议)是基于连接的协议,也就是说,在正式收发数据前,必须和对方建立可靠的连接。一个TCP连接必须要经过三次“对话”才能建立起来,其中的过程非常复杂,我们这里只做简单、形象的介绍,你只要做到能够理解这个过程即可。我们来看看这三次对话的简单过程:主机A向主机B发出连接请求数据包:“我想给你发数据,可以吗?”,这是第一次对话;主机B向主机A发送同意连接和要求同步(同步就是两台主机一个在发送,一个在接收,协调工作)的数据包:“可以,你什么时候发?”,这是第二次对话;主机A再发出一个数据包确认主机B的要求同步:“我现在就发,你接着吧!”,这是第三次对话。三次“对话”的目的是使数据包的发送和接收同步,经过三次“对话”之后,主机A才向主机B正式发送数据。
TCP协议能为应用程序提供可靠的通信连接,使一台计算机发出的字节流无差错地发往网络上的其他计算机,对可靠性要求高的数据通信系统往往使用TCP协议传输数据。
图2
我们来做一个实验,用计算机A(安装Windows 2000 Server操作系统)从“网上邻居”上的一台计算机B拷贝大小为8,644,608字节的文件,通过状态栏右下角网卡的发送和接收指标就会发现:虽然是数据流是由计算机B流向计算机A,但是计算机A仍发送了3,456个数据包,如图2所示。这些数据包是怎样产生的呢?因为文件传输时使用了TCP/IP协议,更确切地说是使用了面向连接的TCP协议,计算机A接收数据包的时候,要向计算机B回发数据包,所以也产生了一些通信量。
图3
如果事先用网络监视器监视网络流量,就会发现由此产生的数据流量是9,478,819字节,比文件大小多出10.96%(如图3所示),原因不仅在于数据包和帧本身占用了一些空间,而且也在于TCP协议面向连接的特性导致了一些额外的通信量的产生。

TCP与UDP数据包的区别 (急)

从专业的角度说,TCP的可靠保证,是它的三次握手机制,这一机制保证校验了数据,保证了他的可靠性。而UDP就没有了,所以不可靠。不过UDP的速度是TCP比不了的,而且UDP的反应速度更快,QQ就是用UDP协议传输的,HTTP是用TCP协议传输的,不用我说什么,自己体验一下就能发现区别了。再有就是UDP和TCP的目的端口不一样(这句话好象是多余的),而且两个协议不在同一层,TCP在三层,UDP不是在四层就是七层。
TCP/IP协议介绍
TCP/IP的通讯协议
这部分简要介绍一下TCP/IP的内部结构,为讨论与互联网有关的安全问题打下基础。TCP/IP协议组之所以流行,部分原因是因为它可以用在各种各样的信道和底层协议(例如T1和X.25、以太网以及RS-232串行接口)之上。确切地说,TCP/IP协议是一组包括TCP协议和IP协议,UDP(User Datagram Protocol)协议、ICMP(Internet Control Message Protocol)协议和其他一些协议的协议组。
TCP/IP整体构架概述
TCP/IP协议并不完全符合OSI的七层参考模型。传统的开放式系统互连参考模型,是一种通信协议的7层抽象的参考模型,其中每一层执行某一特定任务。该模型的目的是使各种硬件在相同的层次上相互通信。这7层是:物理层、数据链路层、网路层、传输层、话路层、表示层和应用层。而TCP/IP通讯协议采用了4层的层级结构,每一层都呼叫它的下一层所提供的网络来完成自己的需求。这4层分别为:
应用层:应用程序间沟通的层,如简单电子邮件传输(SMTP)、文件传输协议(FTP)、网络远程访问协议(Telnet)等。
传输层:在此层中,它提供了节点间的数据传送服务,如传输控制协议(TCP)、用户数据报协议(UDP)等,TCP和UDP给数据包加入传输数据并把它传输到下一层中,这一层负责传送数据,并且确定数据已被送达并接收。
互连网络层:负责提供基本的数据封包传送功能,让每一块数据包都能够到达目的主机(但不检查是否被正确接收),如网际协议(IP)。
网络接口层:对实际的网络媒体的管理,定义如何使用实际网络(如Ethernet、Serial Line等)来传送数据。
TCP/IP中的协议
以下简单介绍TCP/IP中的协议都具备什么样的功能,都是如何工作的:
1. IP
网际协议IP是TCP/IP的心脏,也是网络层中最重要的协议。
IP层接收由更低层(网络接口层例如以太网设备驱动程序)发来的数据包,并把该数据包发送到更高层---TCP或UDP层;相反,IP层也把从TCP或UDP层接收来的数据包传送到更低层。IP数据包是不可靠的,因为IP并没有做任何事情来确认数据包是按顺序发送的或者没有被破坏。IP数据包中含有发送它的主机的地址(源地址)和接收它的主机的地址(目的地址)。
高层的TCP和UDP服务在接收数据包时,通常假设包中的源地址是有效的。也可以这样说,IP地址形成了许多服务的认证基础,这些服务相信数据包是从一个有效的主机发送来的。IP确认包含一个选项,叫作IP source routing,可以用来指定一条源地址和目的地址之间的直接路径。对于一些TCP和UDP的服务来说,使用了该选项的IP包好象是从路径上的最后一个系统传递过来的,而不是来自于它的真实地点。这个选项是为了测试而存在的,说明了它可以被用来欺骗系统来进行平常是被禁止的连接。那么,许多依靠IP源地址做确认的服务将产生问题并且会被非法入侵。
2. TCP
如果IP数据包中有已经封好的TCP数据包,那么IP将把它们向‘上’传送到TCP层。TCP将包排序并进行错误检查,同时实现虚电路间的连接。TCP数据包中包括序号和确认,所以未按照顺序收到的包可以被排序,而损坏的包可以被重传。
TCP将它的信息送到更高层的应用程序,例如Telnet的服务程序和客户程序。应用程序轮流将信息送回TCP层,TCP层便将它们向下传送到IP层,设备驱动程序和物理介质,最后到接收方。
面向连接的服务(例如Telnet、FTP、rlogin、X Windows和SMTP)需要高度的可靠性,所以它们使用了TCP。DNS在某些情况下使用TCP(发送和接收域名数据库),但使用UDP传送有关单个主机的信息。
3.UDP
UDP与TCP位于同一层,但对于数据包的顺序错误或重发。因此,UDP不被应用于那些使用虚电路的面向连接的服务,UDP主要用于那些面向查询---应答的服务,例如NFS。相对于FTP或Telnet,这些服务需要交换的信息量较小。使用UDP的服务包括NTP(网落时间协议)和DNS(DNS也使用TCP)。
欺骗UDP包比欺骗TCP包更容易,因为UDP没有建立初始化连接(也可以称为握手)(因为在两个系统间没有虚电路),也就是说,与UDP相关的服务面临着更大的危险。
4.ICMP
ICMP与IP位于同一层,它被用来传送IP的的控制信息。它主要是用来提供有关通向目的地址的路径信息。ICMP的‘Redirect’信息通知主机通向其他系统的更准确的路径,而‘Unreachable’信息则指出路径有问题。另外,如果路径不可用了,ICMP可以使TCP连接‘体面地’终止。PING是最常用的基于ICMP的服务。
5. TCP和UDP的端口结构
TCP和UDP服务通常有一个客户/服务器的关系,例如,一个Telnet服务进程开始在系统上处于空闲状态,等待着连接。用户使用Telnet客户程序与服务进程建立一个连接。客户程序向服务进程写入信息,服务进程读出信息并发出响应,客户程序读出响应并向用户报告。因而,这个连接是双工的,可以用来进行读写。
两个系统间的多重Telnet连接是如何相互确认并协调一致呢?TCP或UDP连接唯一地使用每个信息中的如下四项进行确认:
源IP地址 发送包的IP地址。
目的IP地址 接收包的IP地址。
源端口 源系统上的连接的端口。
目的端口 目的系统上的连接的端口。
端口是一个软件结构,被客户程序或服务进程用来发送和接收信息。一个端口对应一个16比特的数。服务进程通常使用一个固定的端口,例如,SMTP使用25、Xwindows使用6000。这些端口号是‘广为人知’的,因为在建立与特定的主机或服务的连接时,需要这些地址和目的地址进行通讯。

tcp收包是完整一包吗

不是,还有分包 半包,组包。
组包。简单的说就是tcp协议把过大的数据包分成了几个小的包传输,接收方要把同一组的数据包重新组合成一个完整的数据包。
半包。指接受方没有接受到一个完整的包,只接受了部分,这种情况主要是由于TCP为提高传输效率,将一个包分配的足够大,导致接受方并不能一次接受完。
 粘包,指发送方发送的若干包数据到接收方接收时粘成一包,从接收缓冲区看,后一包数据的头紧接着前一包数据的尾 出现粘包现象的原因是多方面的,它既可能由发送方造成,也可能由接收方造成。发送方引起的粘包是由TCP协议本身造成的,TCP为提高传输效率,发送方往往要收集到足够多的数据后才发送一包数据。若连续几次发送的数据都很少,通常TCP会根据优化算法把这些数据合成一包后一次发送出去,这样接收方就收到了粘包数据。接收方引起的粘包是由于接收方用户进程不及时接收数据,从而导致粘包现象。这是因为接收方先把收到的数据放在系统接收缓冲区,用户进程从该缓冲区取数据,若下一包数据到达时前一包数据尚未被用户进程取走,则下一包数据放到系统接收缓冲区时就接到前一包数据之后,而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据,这样就一次取到了多包数据。
分包,指在出现粘包的时候我们的接收方要进行分包处理。

tcp数据包格式中没有包括的是

这也没有选项哇,不包括的东西有很多。
TCP报文由首部和数据两部分组成。首部一般由20-60字节(Byte)构成,长度可变。其中前20B格式固定,后40B为可选。
因为,TCP报文还得传给下层网络层,封装成IP包,而一个IP包最大长度为65535,同时IP包首部也包含最少20B,所以一个IP包或TCP包可以包含的数据部分最大长度为65535-20-20=65495B。
TCP报文中数据部分是可选的,即TCP报文可以不包含数据(同理IP包也可以不包含数据)。不含数据的TCP报文通常是一些确认和控制信息类的报文,如TCP建立连接时的三次握手和TCP终止时的四次挥手等。
1、源端口号(SourcePort)
长度为16位,指明发送数据的进程。
2、目的端口号(DestinationPort)
长度为16位,指明目的主机接收数据的进程。
3、序号(SequenceNumber)记录发送次数
也称为序列号,长度为32位,序号用来标识从TCP发送端向接入端发送的数据字节流进行编号,可以理解成对字节流的计数。
4、确认号(AcknowledgementNumber)
长度为32位,确认号包含发送确认的一端所期望收到的下一个序号。确认号只有在ACK标志为1时才有效。
5、首部长度(数据偏移)
长度为4位,用于表示TCP报文首部的长度。用4位(bit)表示,十进制值就是[0,15],一个TCP报文前20个字节是必有的,后40个字节根据情况可能有可能没有。如果TCP报文首部是20个字节,则该位应是20/4=5。
6、保留位(Reserved)
长度为6位,必须是0,它是为将来定义新用途保留的。给QOS预留用的
7、标志(CodeBits)
长度为6位,在TCP报文中不管是握手还是挥手还是传数据等,这6位标志都很重要。