tcp syn报文(tcp syn报文段作用)

TCP首部有6个标志比特。SYN是其中之一百，它是个同步序号，当TCP连接建立时会把SYN置度1。一般请求端会发送一个报文，其中包含这样的字段SYN 1415531521：1415531521(0)。然后服问务端收到后会返回一个ack 1415531522，ack表示确认收到。SYN，ACK是标志位。SEQ，AN是数据包序号。SYN=1, ACK=0, SEQ=200 的意思是：发送答的为一个SYN请求，发送端专的初始数据包序号为200SYN=1, ACK=1, SEQ=4800, AN=201 的意思是：接收端的确属认信息，且接收端的初始数据包。序号为4800。seq和ack号存在于TCP报文段的首部中，seq是序号，ack是确认号，大小均为4字节。seq：占 4 字节，序号范围[0，2^32-1]，序号增加到 2^32-1 后，下个序号又回到 0。TCP 是面向字节流的，通过 TCP 传送的字节流中的每个字节都按顺序编号，而报头中的序号字段值则指的是本报文段数据的第一个字节的序号。ack：占 4 字节，期望收到对方下个报文段的第一个数据字节的序号。扩展资料：一个TCP连接的建立是通过三次握手来实现的1. (A) –> [SYN] –> (B)假如服务器B和客户机A通讯. 当A要和B通信时，A首先向B发一个SYN (Synchronize) 标记的包，告诉B请求建立连接.注意: 一个 SYN包就是仅SYN标记设为1的TCP包(参见TCP包头Resources). 认识到这点很重要，只有当B受到A发来的SYN包，才可建立连接，除此之外别无他法。因此，如果你的防火墙丢弃所有的发往外网接口的SYN包，那么将不能主动连接外部任何主机，除非不是TCP协议。2. (A) <– [SYN/ACK] <–(B)接着，B收到后会发一个对SYN包的确认包(SYN/ACK)回去，表示对第一个SYN包的确认，并继续握手操作.注意: SYN/ACK包是仅SYN 和 ACK 标记为1的包.3. (A) –> [ACK] –> (B)A收到SYN/ACK 包,A发一个确认包(ACK)，通知B连接已建立。至此，三次握手完成，一个TCP连接完成Note: ACK包就是仅ACK 标记设为1的TCP包. 需要注意的是当三此握手完成、连接建立以后，TCP连接的每个包都会设置ACK位。参考资料：百度百科-三次握手
TCP是传输控制协议。 syn是该协议中的一个标志位。如果该位被置为1，则表示这个报文是一个请求建立连接的报文。 ack也是该协议的一个标志位。如果该位被置为1，则表示这个报文是一个用于确认的报文。
TCP是传输控制协议。 syn是该协议中的一个标志位。如果该位被置为1，则表示这个报文是一个请求建立连接的报文。 ack也是该协议的一个标志位。如果该位被置为1，则表示这个报文是一个用于确认的报文。

tcp是一种传输层协议。 syn和ack都是tcp报文头部的一个字段。 syn指同步位，建立连接时用来同步序号；ack是确认位，建立连接后所有的传送报文段ack都为1。

TCP：传输、控制、协议。TCP与UDP最大却别就在那个C上面，它充分实现了数据传输时各种控制功能。可以进行丢包重发控制，还可以对次序乱掉的数据包进行顺序控制，还能控制传输流量，这些是UDP中没有的。即T C P 提供一种面向连接的、可靠的字节流服务。TCP是一中面向有链接的协议，只有在确认对端存在的时候，才会发送分数据，从而也可以控制通信流量的浪费。什么是可靠的传输：不丢包、不损坏、不乱序、不重复。TCP通过校验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制来实现可靠传输。接收端查询就收数据TCP首部中的序号和数据长度。将自己下一步应该接受的序列号作为确认应答返送回去。就这样，通过序列号和确认应答，TCP实现可靠传输。一般使用TCP首部用于控制的字段来管理连接。一个连接的建立和断开，正常过程中，至少需要来回共7个包才能完成。TCP首部的数据结构如图所示：TCP包首部为了便于理解，忽略选项部分，固定首部通常为20个字节，将按作用分类分析。前4个字节来标识了发送方的端口号和接收方的端口号，即该数据包由谁发送，由谁接收。前2个字节标识源端口号，紧接着2个字节标识目的端口号。即发送方：(11111111,1111111)2= (65535)10，除去0~1023.即接收方：(11111111,1111111)2= (65535)10，除去0~1023.TCP是面向字节流的。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段值则是指的是本报文段所发送的数据的第一个字节的序号。长度为4字节，序号是32bit的无符号数,序号到达232- 1后又从0开始。ack：确认序号，即确认字节的序号，更确切地说，是发送确认的一端所期望收到的下一个序号。所谓的发送确认的一端就是将确认信息发出的一端。比如第二次握手的S端就是发送确认的一端。确认序号为上次接收的最后一个字节序号加1.只有确认标志位(ACK)为1的时候，确认序号才有效。也叫首部长度，占4个bit,它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。TCP报文结构由于首部中还有长度不确定的选项字段，因此数据偏移字段是必要的。“首部长度”是4位二进制数，单位是32位字，能表示的最大十进制数字是15。(1111)2=(15)10,即是15个32位，一个32位是4个字节，因此数据偏移的最大值是154=60个字节，这也是TCP首部的最大字节。因为固定首部的存在，数据偏移的值最小为20个字节，因此选项长度不能超过40字节*（减去20个字节的固定首部）。占6位，保留为今后使用，但目前应置为0。当URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快发送（相当于高优先级的数据），而不要按原来的排队顺序来传送。例如，已经发送了很长的一个程序要在远地的主机上运行。但后来发现了一些问题，需要取消该程序的运行，因此用户从键盘发出中断命令。如果不使用紧急数据，那么这两个字符将存储在接收TCP的缓存末尾。只有在所有的数据被处理完毕后这两个字符才被交付接收方的应用进程。这样做就浪费了很多时间。当URG置为1时，应用进程就告诉TCP有紧急数据要传送。于是TCP就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍然是普通数据。这时要与首部中紧急指针（Urgent Pointer）字段配合使用。仅当ACK = 1时确认号字段才有效，当ACK = 0时确认号无效。TCP规定，在连接建立后所有的传送的报文段都必须把ACK置为1。当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应。在这种情况下，TCP就可以使用推送（push）操作。发送方TCP把PSH置为1，并立即创建一个报文段发送出去。接收方TCP收到PSH=1的报文段，就尽快地（即“推送”向前）交付接收应用进程。而不用再等到整个缓存都填满了后再向上交付。当RST=1时，表明TCP连接中出现了严重错误（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立传输连接。RST置为1还用来拒绝一个非法的报文段或拒绝打开一个连接。在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。因此SYN=1就表示这是一个连接请求或连接接受报文。用来释放一个连接。当FIN=1时，表明此报文段的发送发的数据已发送完毕，并要求释放运输连接。占2字节。窗口值是(0，216-1)之间的整数。窗口指的是发送本报文段的一方的接受窗口（而不是自己的发送窗口）,窗口大小是给对方用的。窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方一次发送的数据量（以字节为单位）。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。总之，窗口值作为接收方让发送方设置其发送窗口的依据。例如，A发送了一个报文段，其确认号是3000，窗口字段是1000.这就是告诉对方B：“从3000算起，A接收缓存空间还可接受1000个字节数据，字节序号是3000-3999”，可以想象到河道的阀门。总之：窗口字段明确指出了现在允许对方发送的数据量。窗口值经常在动态变化。占2字节。检验和字段检验的范围包括首部和数据这两部分。和UDP用户数据报一样，在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。伪首部的格式和UDP用户数据报的伪首部一样。但应把伪首部第4个字段中的17改为6（TCP的协议号是6）；把第5字段中的UDP中的长度改为TCP长度。接收方收到此报文段后，仍要加上这个伪首部来计算检验和。若使用TPv6,则相应的伪首部也要改变。占2字节。紧急指针仅在URG=1时才有意义，它指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据） 。因此，在紧急指针指出了紧急数据的末尾在报文段中的位置。当所有紧急数据都处理完时，TCP就告诉应用程序恢复到正常操作。值得注意的是，即使窗口为0时也可以发送紧急数据。长度可变，最长可达40个字节。当没有使用“选项”时，TCP的首部长度是20字节。最大报文段长度(MSS:Maximum Segment Size)表示TCP传往另一端的最大块数据的长度。当一个连接建立时，连接的双方都要通告各自的MSS。当建立一个连接时，每一方都有用于通告它期望接收的MSS选项(MSS选项只能出现在SYN报文段中),如果一方不接收来自另一方的MSS值，则MSS就定为默认值536字节(这个默认值允许20字节的IP首部和20字节的TCP首部以适合576字节IP数据报) 。为什么要规定一个最大报文长度MSS呢？这并不是考虑接受方的接收缓存可能存放不下TCP报文段中的数据。实际上，MSS与接收窗口值没有关系。我们知道，TCP报文段的数据部分，至少要加上40字节的首部（TCP首部20字节和IP首部20字节，这里还没有考虑首部中的可选部分）才能组装成一个IP数据报。若选择较小的MSS长度，网络的利用率就降低。设想在极端情况下，当TCP报文段只含有1字节的数据时，在IP层传输的数据报的开销至少有40字节（包括TCP报文段的首部和IP数据报的首部）。这样，对网络的利用率就不会超过1/41。到了数据链路层还要加上一些开销。但反过来，若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片组成成原来的TCP报文段，当传输出错时还要进行重传，这些也都会使开销增大。因此，MSS应尽可能大些，只要在IP层传输时不需要分片就行。由于IP数据报所经历的路径是动态变化的，因此在这条路径上确定的不需要的分片的MSS，如果改走另一条路径就可能需要进行分片。因此最佳的MSS是很难确定的。在连接过程中，双方都把自己能够支持的MSS写入这一字段，以后就按照这个数值传输数据，两个传送方向可以有不同的MSS值。若主机未填写这一项，则MSS的默认值是536字节长。因此，所有在互联网上的主机都应该接受的报文段长度是536+20（固定首部长度）=556字节。后来又增加了几个选项如窗口扩大选项、时间戳选项等。窗口扩大选项是为了扩大窗口。我们知道，TCP首部中窗口字段长度是16位，因此最大的窗口大小为64K字节。虽然这对早期的网络是足够用的，但对于包含卫星信道的网络，传播时延和宽带都很大，要获得高吞吐量需要更大的窗口大小。窗口扩大选项占3字节，其中有一个字节表示移位值S。新的窗口值等于TCP首部中的窗口位数从16增大到（16+S）。移位值允许使用的最大值是14，相当于窗口最大值增大到2（16+14）-1=230-1。窗口扩大选项可以在双方初始建立TCP连接时进行协商。如果连接的某一端实现了窗口扩大，当它不再需要扩大其窗口时，可发送S=0选项，使窗口大小回到16。时间戳选项占10字节，其中最主要的字段是时间戳字段（4字节）和时间戳回送回答字段（4字节）。时间戳选项有以下两个概念：第一、 用来计算往返时间RTT。发送方在发送报文段时把当前时钟的时间值放入时间戳字段，接收方在确认该报文段时把时间戳字段复制到时间戳回送回答字段。因此，发送方在收到确认报文后，可以准确地计算出RTT来。第二、 用于处理TCP序号超过232的情况，这又称为防止序号绕回PAWS。我们知道，TCP报文段的序号只有32位，而每增加232个序号就会重复使用原来用过的序号。当使用高速网络时，在一次TCP连接的数据传送中序号很可能被重复使用。例如，当使用1.5Mbit/s的速度发送报文段时，序号重复要6小时以上。但若用2.5Gbit/s的速率发送报文段，则不到14秒钟序号就会重复。为了使接收方能够把新的报文段和迟到很久的报文段区分开，则可以在报文段中加上这种时间戳。从功能和性能的角度去理解三次握手建立连接第一次：C向S发送一个建立连接的请求。此过程中携带一些报文属性信息，这些信息，存在于报文首部，有初始化用的信息，比如，有用于认证的信息。初始化信息：如报文序列号、SYN：TCP在数据通信之前，通过TCP首部发送的一个SYN标志位，作为建立连接的请求等待接收方确认应答。如果S发来确认应答，则认为可以进行数据通信，否则，就不能进行通信。TCP规定：****SYN=1的报文段不能携带数据，但是要消耗掉一个序号：seq=x。这个时候C进入SYN-SENT(同步已发送)状态。第二次：S收到C请求后，如果同意建立连接，则向C返回确认信息：将SYN、ACK都置1，确认号为ack=seq+1(seq来自客户端)，并携带自己的初始化，同时用于认证的信息S。同理：SYN=1的报文段不能携带数据，但是要消耗掉一个序号：seq=y。这个时候S进入SYN-RCVD(同步已接收)状态。C收到S返回的确认信息后，进入ESTABLISHED(已建立连接)的状态，第三次：C收到S返回的确认信息后，向S再一次发送确认报文。ACK置为1，确认号ack=seq+1(seq来自S),自己的seq=x+1。TCP规定：ACK报文可以携带数据。但是，如果不携带数据，则不消耗序号，这时，下一数据报文段的序号仍是seq=x+1。服务器收到客户端返回的确认信息后，也进入ESTABLISHED(已建立连接)的状态，从功能角度去考虑前两次握手，从性能的角度去理解为什么需要第三次握手。有第三次，是考虑到一种错误情况：假设C发了一请求建立连接的报文，长时间未收到S的确认报文，则C会重发，这个时候S与之建立连接、完成数据通信、关闭了连接，这个时候C第一发出的请求建立连接的报文到达了S,S则会等待C发送数据，实际上C已经CLOSED了，S就一直在这等待，浪费资源，确切地说，应该是至少四次数据交互才能实现一个连接的彻底关闭。关闭连接，需要四个报文来指示关闭。TCP是全双工通信的，所以在一端发送数据完毕后，还具有接收另一端的数据的能力，这就所谓的半关闭。四次挥手举个例子：如果C的数据已经发送完毕，C是不能立即关闭的，因为建立连接的通信双方是平等的。C首先告诉S：“数据发送完毕“，这个消息在TCP报文的首部由FIN来标识，让S知道C是准备断开连接了。这是第一次挥手。S收到C发来的FIN标识的报文后，要给C端恢复一个确认FIN的消息，告诉C说，知道你的数据发完了。这是第二次挥手。这个时候，如果S端的数据也发送完毕了，就给C发一个FIN=1报文。这是第三次挥手。C收到S发来的FIN标识的报文后，要给S端恢复一个确认FIN的消息，告诉C说，知道你的数据发完了。这是第四次挥手。然后就彻底断开连接了。TCP的状态变迁图

在TCP报文的报头中，有几个标志字段： 1、 SYN：同步连接序号，TCP SYN报文就是把这个标志设置为1，来请求建立连接；2、 ACK：请求/应答状态。0为请求，1为应答；3、 FIN：结束连线。如果FIN为0是结束连线请求，FIN为1表示结束连线；4、 RST：连线复位，首先断开连接，然后重建；5、 PSH：通知协议栈尽快把TCP数据提交给上层程序处理。可能出现的扫描：（33/ppt11 － 43/ppt11 介绍了下面各种扫描的做法及优缺点）§基本的TCP connect()扫描§TCP SYN扫描(半开连接扫描, half open)§TCP Fin扫描(秘密扫描，stealth)§TCP ftp proxy扫描(bounce attack)§用IP分片进行SYN/FIN扫描(躲开包过滤防火墙)§UDP recvfrom扫描§UDP ICMP端口不可达扫描§Reverse-ident扫描（针对TCP中SYN、RST、FIN标志字段可能出现的攻击，记一下名称应该就可以了）端口扫描攻击：攻击者计算机便可以通过发送合适的报文，判断目标计算机哪些TCP或UDP端口是开放的，过程如下：1、 发出端口号从0开始依次递增的TCP SYN或UDP报文（端口号是一个16比特的数字，这样最大为65535，数量很有限）； 2、 如果收到了针对这个TCP报文的RST报文，或针对这个UDP报文的ICMP不可达报文，则说明这个端口没有开放； 3、 相反，如果收到了针对这个TCP SYN报文的ACK报文，或者没有接收到任何针对该UDP报文的ICMP报文，则说明该TCP端口是开放的，UDP端口可能开放（因为有的实现中可能不回应ICMP不可达报文，即使该UDP端口没有开放）。 这样继续下去，便可以很容易的判断出目标计算机开放了哪些TCP或UDP端口，然后针对端口的具体数字，进行下一步攻击，这就是所谓的端口扫描攻击。TCP SYN拒绝服务攻击；1、 攻击者向目标计算机发送一个TCP SYN报文； 2、 目标计算机收到这个报文后，建立TCP连接控制结构（TCB），并回应一个ACK，等待发起者的回应； 3、 而发起者则不向目标计算机回应ACK报文，这样导致目标计算机一致处于等待状态。分片IP报文攻击：为了传送一个大的IP报文，IP协议栈需要根据链路接口的MTU对该IP报文进行分片，通过填充适当的IP头中的分片指示字段，接收计算机可以很容易的把这些IP分片报文组装起来。目标计算机在处理这些分片报文的时候，会把先到的分片报文缓存起来，然后一直等待后续的分片报文，这个过程会消耗掉一部分内存，以及一些IP协议栈的数据结构。如果攻击者给目标计算机只发送一片分片报文，而不发送所有的分片报文，这样攻击者计算机便会一直等待（直到一个内部计时器到时），如果攻击者发送了大量的分片报文，就会消耗掉目标计算机的资源，而导致不能相应正常的IP报文，这也是一种DOS攻击。SYN比特和FIN比特同时设置： 正常情况下，SYN标志（连接请求标志）和FIN标志（连接拆除标志）是不能同时出现在一个TCP报文中的。而且RFC也没有规定IP协议栈如何处理这样的畸形报文，因此，各个操作系统的协议栈在收到这样的报文后的处理方式也不同，攻击者就可以利用这个特征，通过发送SYN和FIN同时设置的报文，来判断操作系统的类型，然后针对该操作系统，进行进一步的攻击。

SYN Flood是当前最流行的DoS(拒绝服务攻击)与DDoS(分布式拒绝服务攻击)的方式之一，它是利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽(CPU满负荷或内存不足)的攻击方式，最终导致系统或服务器宕机。 在讨论SYN Flood原理前，我们需要从TCP连接建立的过程开始说起：TCP与UDP不同，它是基于连接的，为了在服务端和客户端之间传送TCP数据，必须先建立一个虚拟电路，也就是TCP连接。也就是我们经常听说的TCP协议中的三次握手（Three-way Handshake），建立TCP连接的标准过程如下：首先，客户端发送一个包含SYN标志的TCP报文，SYN即同步（Synchronize），同步报文会指明客户端使用的端口以及TCP连接的初始序号;其次，服务器在收到客户端的SYN报文后，将返回一个SYN+ACK（即确认Acknowledgement）的报文，表示客户端的请求被接受，同时TCP初始序号自动加一。最后，客户端也返回一个确认报文ACK给服务器端，同样TCP序列号被加一，到此一个TCP连接完成。SYN Flood攻击正是利用了TCP连接的三次握手，假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成)，这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级(大约为30秒-2分钟)；一个用户出现异常导致服务器的一个线程等待1分钟并不会对服务器端造成什么大的影响，但如果有大量的等待丢失的情况发生，服务器端将为了维护一个非常大的半连接请求而消耗非常多的资源。我们可以想象大量的保存并遍历也会消耗非常多的CPU时间和内存，再加上服务器端不断对列表中的IP进行SYN+ACK的重试，服务器的负载将会变得非常巨大。如果服务器的TCP/IP栈不够强大，最后的结果往往是堆栈溢出崩溃。相对于攻击数据流，正常的用户请求就显得十分渺小，服务器疲于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求，此时从正常客户会表现为打开页面缓慢或服务器无响应，这种情况就是我们常说的服务器端SYN Flood攻击(SYN洪水攻击)。从防御角度来讲，存在几种的解决方法：第一种是缩短SYN Timeout时间，由于SYN Flood攻击的效果取决于服务器上保持的SYN半连接数，这个值=SYN攻击的频度 x SYN Timeout，所以通过缩短从接收到SYN报文到确定这个报文无效并丢弃改连接的时间，例如设置为20秒以下，可以成倍的降低服务器的负荷。但过低的SYN Timeout设置可能会影响客户的正常访问。第二种方法是设置SYN Cookie，就是给每一个请求连接的IP地址分配一个Cookie，如果短时间内连续受到某个IP的重复SYN报文，就认定是受到了攻击，并记录地址信息，以后从这个IP地址来的包会被一概丢弃。这样做的结果也可能会影响到正常用户的访问。 上述的两种方法只能对付比较原始的SYN Flood攻击，缩短SYN Timeout时间仅在对方攻击频度不高的情况下生效，SYN Cookie更依赖于对方使用真实的IP地址，如果攻击者以数万/秒的速度发送SYN报文，同时利用SOCK_RAW随机改写IP报文中的源地址，以上的方法将毫无用武之地。