TCP—SYN、ACK详解

更新时间:2023-07-12 09:29:48 阅读: 评论:0

三次握手Three-way Handshake


一个虚拟连接的建立是通过三次握手来实现的

1. (B) --> [SYN] --> (A)

假如服务器A和客户机B通讯. A要和B通信时,B首先向A发一个SYN (Synchronize) 标记的包,告诉A请求建立连接.

注意: 一个 SYN包就是仅SYN标记设为1TCP(参见TCP包头Resources). 认识到这点很重要,只有当A受到B发来的SYN包,才可建立连接,除此之外别无他法。因此,如果你的防火墙丢弃所有的发往外网接口的SYN包,那么你将不能让外部任何主机主动建立连接。

2. (B) <-- [SYN/ACK] <--(A)


接着,A收到后会发一个对SYN包的确认包(SYN/ACK)回去,表示对第一个SYN包的确认,并继续握手操作.

注意: SYN/ACK包是仅SYN ACK 标记为1的包.

3. (B) --> [ACK] --> (A)

B收到SYN/ACK ,B发一个确认包(ACK)北京购车摇号,通知A连接已建立。至此,三次握手完成,一个TCP连接完成

Note: ACK包就是仅ACK 标记设为1TCP. 需要注意的是当三此握手完成、连接建立以后,TCP连接的每个包都会设置ACK

这就是为何连接跟踪很重要的原因了. 没有连接跟踪,防火墙将无法判断收到的ACK包是否
属于一个已经建立的连接.一般的包过滤(Ipchains)收到ACK包时,会让它通过(这绝对不是个好主意). 而当状态型防火墙收到此种包时,它会先在连接表中查找是否属于哪个已建连接,否则丢弃该包

四次握手Four-way Handshake

四次握手用来关闭已建立的TCP连接

1. (B) --> ACK/FIN --> (A)

2. (B) <-- ACK <-- (A)

3. (B) <-- ACK/FIN <-- (A)

4. (B) --> ACK --> (A)


注意: 由于TCP连接是双向连接, 因此关闭连接需要在两个方向上做。ACK/FIN (ACK FIN 标记设为1)通常被认为是FIN(终结).然而, 由于连接还没有关闭, FIN包总是打上鹿胎膏的正确吃法ACK标记. 没有ACK标记而仅有FIN标记的包不是合法的包,并且通常被认为是恶意的

连接复位Retting a connection

四次握手不是关闭TCP连接的唯一方法. 有时,如果主机需要尽快关闭连接(或连接超时,端口或主机不可达),RST (Ret)包将被发送. 注意在,由于RST包不是TCP连接中的必须部分, 可以只发送RST(即不带ACK标记). 但在正常的TCP连接中RST包可以带ACK确认标记

请注意RST包是可以不要收到方确认的?

无效的TCP标记Invalid TCP Flags

到目前为止,你已经看到了 SYN, ACK, FIN, RST 标记. 另外,还有PSH (Push) URG (Urgent)标记.

最常见的非法组合是SYN/FIN . 注意:由于 SYN包是用来初始化连接的, 它不可能和 FINRST标记一起出现. 这也是一个恶意攻击.

由于现在大多数防火墙已知 SYN/FIN , 别的一些组合,例如SYN/FIN/PSH, SYN/FIN/RST, SYN/FIN/RST/PSH。很明显,当网络中出现这种包时,很你的网络肯定受到攻击了。

别的已知的非法包有FIN (ACK标记)"NULL"包。如同早先讨论的,由于ACK/FIN包的出现是为了关闭一个TCP连接,那么正常的FIN包总是带有 ACK 标记。"NULL"包就是没有任何TCP标记的包(URG,ACK,PSH,RST,SYN,FIN都为0)

到目前为止,正常的网络活动下,TCP协议栈不可能产生带有上面提到的任何一种标记组合的TCP包。当你发现这些不正常的包时,肯定有人对你的网络不怀好意。


UDP (用户数据包协议Ur Datagram Protocol)
TCP是面向连接的,而UDP是非连接的协议。UDP没有对接受进行确认的标记和确认机制。对丢包的处理是在应用层来完成的。(or accidental arrival).

此处需要重点注意的事情是:在正常情况下,当UDP包到达一个关闭的端口时,会返回一个UDP复位包。由于UDP是非面向连接的, 因此没有任何确认信息来确认包是否正确到达目的地。因此如果你的防火墙丢弃UDP包,它会开放所有的UDP端口(?)

由于Internet上正常情况下一些包将被丢弃,甚至某些发往已关闭端口(非防火墙的)UDP包将不会到达目的,它们将返回一个复位UDP包。

因为这个原因,UDP端口扫描总是不精确、不可靠的。

看起来大UDP包的碎片是常见的DOS (Denial of Service)攻击的常见形式 (这里有个DOS
击的例子,/dos/grcdos.htm ).

ICMP (网间控制消息协议Internet Control Message Protocol)
如同名字一样, ICMP用来在主机/路由器之间传递控制信息的协议。 ICMP包可以包含诊断信息(ping, traceroute - 注意目前unix系统中的tracerouteUDP包而不是ICMP),错误信息(网络怎样克服社交恐惧症/主机/端口 不可达 network/host/port unreachable), 信息(时间戳timestamp, 地址掩码address mask request, etc.),或控制信息 (source quench, redirect, etc.)

你可以在www.iana/assignments/icmp-parameters中找到ICMP包的类型。

尽管ICMP通常是无害的,还是有些类型的ICMP信息需要丢弃。

Redirect (5), Alternate Host Address (6), Router Advertiment (9) 能用来转发通讯。

Echo (8), Timestamp (13) and Address Mask Request (17) 能用来分别判断主机是否起来,
本地时间 和地址掩码。注意它们是和返回的信息类别有关的。它们自己本身是不能被利用的,但它们泄露出的信息对攻击者是有用的。

ICMP消息有时也被用来作为DOS攻击的一部分(例如:洪水ping flood ping, ping ?呵呵,有趣 ping of death)?/p>

包碎片注意A Note About Packet Fragmentation

如果一个包的大小超过了TCP的最大段长度MSS (Maximum Segment Size) MTU (Maximum Transmission Unit),能够把此包发往目的的唯一方法是把此包分片。由于包分片是正常的,它可以被利用来做恶意的攻击。

因为分片的包的第一个分片包含一个包头,若没有包分片的重组功能,包过滤器不可能检测附加的包分片。典型的攻击Typical attacks involve in overlapping the packet data in which packet header is 典型的攻击Typical attacks involve in overlapping the packet data i
n which packet header isnormal until is it overwritten with different destination IP (or port) thereby bypassing firewall rules。包分片能作为 DOS 攻击的一部分,它可以crash older IP stacks 或涨死CPU连接能力。

Netfilter/Iptables中的连接跟踪代码能自动做分片重组。它仍有弱点,可能受到饱和连接攻击,可以把CPU资源耗光。
握手阶段:
序号 方向 q ack
1  A->B 10000 0
2 B->A 20000 10000+1=10001
3 A->B 10001 20000+1=20001
解释:
1AB发起连接请求,以一个随机数初始化Aq,这里假设为10000,此时ACK0

2B收到A的连接请求后,也以一个随机数初始化Bq,这里假设为20000,意思是:
你的请求我已收到,我这方的数据流就从这个数开始。BACKAq1,即10000110001

3A收到B的回复后,它的q是它的上个请求的q1,即10000110001,意思也是:你的回复我收到了,我这方的数据流就从这个数开始。A此时的ACKBq1,即20000+1=20001


数据传输阶段:
序号  方向      q ack size
23 A->B 40000 70000 1514
24 B->A 70000 40000+1514-54=41460 54
25 A->B 41460 70000+54-54=70000 1514
26 B->A 70000 41460+1514-54=42920 54
解释:
23:B接收到A发来的q=40000,ack=70000,size=1514的数据包
24:于是BA也发一个数据包,告诉B,你的上个包我收到了。Bq就以它收到的数据包的ACK填充,ACK是它收到的数据包的SEQ加上数据包的大小(不包括以太网协议头,IP头,TCP),以证实B发过来的数据全收到了。
25:A在收到B发过来的ack41460的数据包时,一看到41460,正好是它的上个数据包的q加上包的大小,就明白,上次发送的数据包已安全到达。于是它再发一个数据包给B。这个正在发送的数据包的q也以它收到的数据包的ACK填充,ACK就以它收到的数据包的q(70000)加上包的size(54)填充,ack=70000+54-54(全是头长,没数据项)
其实在握手和结束时确认号应该是对方序列号加1,传输数据时则是对方序列号加上对方携带应用层数据的长度.如果从以太网包返回来计算所加的长度,就嫌走弯路了.
另外,如果对方没有数据过来,则自己的确认号不变,序列号为上次的序列号加上本次应用层数据发送长度.
TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接,如图1所示。
1)第一次握手:建立连接时,客户端A发送SYN包(SYN=j)到服务器B,并进入SYN_SEND状态,等待服务器B确认。
2)第二次握手:服务器B收到SYN包,必须确认客户ASYNACK=j+1),同时自己也发送一个SYN包(SYN=k),即SYN+ACK包,此时服务器B进入SYN_RECV状态。
3)第三次握手:客户端A收到服务器BSYNACK包,向服务器B发送确认包ACKACK=k+1),此包发送完毕,客户端A和服务器B进入ESTABLISHED状态,完成三次握手。
完成三次握手,客户端与服务器开始传送数据。警惕的近义词
                              1 TCP三次握手建立连接
由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。
1)客户端A发送一个FIN,用来关闭客户A到服务器B的数据传送(报文段4)。
2)服务器B收到这个FIN,它发回一个ACK,确认序号为收到的序号加1(报文段5)。和SYN一样,一个FIN将占用一个序号。
3)服务器B关闭与客户端A的连接,发送一个FIN给客户端A(报文段6)。
4)客户端A发回ACK报文确认,并将确认序号设置为收到序号加1(报文段7)。
TCP采用四次挥手关闭连接如图2所示。
                              2  TCP四次挥手关闭连接
1.为什么建立连接协议是三次握手,而关闭连接却是四次握手呢?
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后,它可以把ACKSYNACK起应答作用,而SYN起同步作用)放在一个报文里来发送。但关闭连接
时,当收到对方的FIN报文通知时,它仅仅表示对方没有数据发送给你了;但未必你所有的数据都全部发送给对方了,所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方来表示你同意现在可以关闭连接了,所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
2.为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?
这是因为虽然双方都同意关闭连接了,而且握手的4维c的水果有哪些个报文也都协调和发送完毕,按理可以直接回到CLOSED状态(就好比从SYN_SEND状态到ESTABLISH状态那样);但是因为我们必须要假想网络是不可靠的,你无法保证你最后发送的ACK报文会一定被对方收到,因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文,而重发FIN报文,所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
TCP 状态机
 TCP 协议的操作可以使用一个具有 11 种状态的有限状态机( Finite State Machine )来表示,图 3-12 描述了 TCP 的有限状态机,图中的圆角矩形表示状态,箭头表示状态之间
的转换,各状态的描述如表 3-2 所示。图中用粗线表示客户端主动和被动的服务器端建立连接的正常过程:客户端的状态变迁用粗实线,服务器端的状态变迁用粗虚线。细线用于不常见的序列,如复位、同时打开、同时关闭等。图中的每条状态变换线上均标有事件/动作:事件是指用户执行了系统调用( CONNECT LISTEN SEND CLOSE )、收到一个报文段( SYN FIN 汉章帝 ACK RST )、或者是出现了超过两倍最大的分组生命期的情况;动作是指发送一个报文段( SYN FIN ACK )或什么也没有(用艾草泡脚有什么功效表示)。
每个连接均开始于 CLOSED 状态。当一方执行了被动的连接原语( LISTEN )或主动的连接原语( CONNECT )时,它便会脱离 CLOSED 状态。如果此时另一方执行了相对应的连接原语,连接便建立了,并且状态变为 ESTABLISHED 。任何一方均可以首先请求释放连接,当连接被释放后,状态又回到了 CLOSED
 
3-2 TCP 状态表
CLOSED
关闭状态,没有连接活动或正在进行
LISTEN
监听状态,服务器正在等待连接进入
SYN RCVD
收到一个连接请求,尚未确认
SYN SENT
已经发出连接请求,等待确认
ESTABLISHED
连接建立,正常数据传输状态
FIN WAIT 1
(主动关闭)已经发送关闭请求,等待确认
FIN WAIT 2
(主动关闭)收到对方关闭确认,等待对方关闭请求
TIMED WAIT
完成双向关闭,等待所有分组死掉
CLOSING
双方同时尝试关闭,等待对方确认
CLOSE WAIT
(被动关闭)收到对方关闭请求,已经确认
LAST ACK
(被动关闭)等待最后一个关闭确认,并等待所有分组死掉
 
1. 正常状态转换
  我们用图舒畅的反义词 3-13 来显示在正常的 TCP 连接的建立与终止过程中,客户与服务器所经历的不同状态。读者可以对照图 3-12 来阅读,使用图 3-12 的状态图来跟踪图 3-13 的状态变化过程,以便明白每个状态的变化:
服务器端首先执行 LISTEN 原语进入被动打开状态( LISTEN ),等待客户端连接;
当客户端的一个应用程序发出 CONNECT 命令后,本地的 TCP 实体为其创建一个连接记录并标记为 SYN SENT 状态,然后给服务器发送一个 SYN 报文段;
服务器收到一个 SYN 报文段,其 TCP 实体给客户端发送确认 ACK 报文段同时发送一个 SYN 信号,进入 SYN RCVD 状态;

本文发布于:2023-07-12 09:29:48,感谢您对本站的认可!

本文链接:https://www.wtabcd.cn/fanwen/fan/89/1078284.html

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

标签:连接   关闭   状态   确认   对方
相关文章
留言与评论(共有 0 条评论)
   
验证码:
推荐文章
排行榜
Copyright ©2019-2022 Comsenz Inc.Powered by © 专利检索| 网站地图