三次握手Three-way Handshake 
一个虚拟连接的建立是通过三次握手来实现的 
1. (B) --> [SYN] --> (A) 
假如服务器A和客户机B通讯. 当A要和B通信时，B首先向A发一个SYN (Synchronize) 
标记的包，告诉A请求建立连接. 
注意: 一个 SYN包就是仅SYN标记设为1的TCP包(参见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 标记设为1的TCP包. 需要注意的是当三此握手完成、连接建
立以后，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标记的包不是合法的包，并且通常被认为是恶意
的 
连接复位Resetting a connection 
四次握手不是关闭TCP连接的唯一方法. 有时，如果主机需要尽快关闭连接(或连接超时，端
口或主机不可达),RST (Reset)包将被发送. 注意在，由于RST包不是TCP连接中的必须
部分, 可以只发送RST包(即不带ACK标记). 但在正常的TCP连接中RST包可以带ACK
确认标记 
请注意RST包是可以不要收到方确认的? 
无效的TCP标记Invalid TCP Flags 
到目前为止，你已经看到了 SYN, ACK, FIN, 和RST 标记. 另外，还有PSH (Push) 和
URG (Urgent)标记. 
最常见的非法组合是SYN/FIN 包. 注意：由于 SYN包是用来初始化连接的, 它不可能和 
FIN和RST标记一起出现. 这也是一个恶意攻击. 
由于现在大多数防火墙已知 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 (用户数据包协议User Datagram Protocol) 
TCP是面向连接的，而UDP是非连接的协议。UDP没有对接受进行确认的标记和确认机
制。对丢包的处理是在应用层来完成的。(or accidental arrival). 
此处需要重点注意的事情是：在正常情况下，当UDP包到达一个关闭的端口时，会返回一
个UDP复位包。由于UDP是非面向连接的, 因此没有任何确认信息来确认包是否正确到
达目的地。因此如果你的防火墙丢弃UDP包，它会开放所有的UDP端口(?)。 
由于Internet上正常情况下一些包将被丢弃，甚至某些发往已关闭端口(非防火墙的)的UDP包将不会到达目的，它们将返回一个复位UDP包。 
因为这个原因，UDP端口扫描总是不精确、不可靠的。 
看起来大UDP包的碎片是常见的DOS (Denial of Service)攻击的常见形式 (这里有个
DOS攻击的例子，grc/dos/grcdos.htm ). 
ICMP (网间控制消息协议Internet Control Message Protocol) 
如同名字一样， ICMP用来在主机/路由器之间传递控制信息的协议。 ICMP包可以包含
诊断信息(ping, traceroute - 注意目前unix系统中的traceroute用UDP包而不是
ICMP)，错误信息(网络/主机/端口 不可达 network/host/port unreachable), 信息(时
间戳timestamp, 地址掩码address mask request, etc.)，或控制信息 (source 
quench, redirect, etc.) 。 
你可以在/assignments/icmp-parameters中到ICMP包的类
型。 
尽管ICMP通常是无害的，还是有些类型的ICMP信息需要丢弃。 
Redirect (5), Alternate Host Address (6), Router Advertisement (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 Si
ze) 或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 in 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资源耗光。 握手阶段： 
序号 方向 seq ack 
1  A->B 10000 0 
2 B->A 20000 10000+1=10001 
3 A->B 10001 20000+1=20001 
解释： 
1：A向B发起连接请求，以一个随机数初始化A的seq，这里假设为10000，此时ACK
＝0 
2：B收到A的连接请求后，也以一个随机数初始化B的seq，这里假设为20000，意思
是：你的请求我已收到，我这方的数据流就从这个数开始。B的ACK是A的seq加1，即
10000＋1＝10001 
3：A收到B的回复后，它的seq是它的上个请求的seq加1，即10000＋1＝10001，
意思也是：你的回复我收到了，我这方的数据流就从这个数开始。A此时的ACK是B的seq
加1，即20000+1=20001 
数据传输阶段： 
序号  方向      seq 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发来的seq=40000,ack=70000,size=1514的数据包 
24：于是B向A也发一个数据包，告诉B，你的上个包我收到了。B的seq就以它收到的
数据包的ACK填充，ACK是它收到的数据包的SEQ加上数据包的大小(不包括以太网协议
头，IP头，TCP头)，以证实B发过来的数据全收到了。 
25:A在收到B发过来的ack为41460的数据包时，一看到41460，正好是它的上个数
据包的seq加上包的大小，就明白，上次发送的数据包已安全到达。于是它再发一个数据
包给B。这个正在发送的数据包的seq也以它收到的数据包的ACK填充，ACK就以它收
到的数据包的seq(70000)加上包的size(54)填充，即ack=70000+54-54(全是头长，没
数据项)。 
其实在握手和结束时确认号应该是对方序列号加1，传输数据时则是对方序列号加上对方携
带应用层数据的长度.如果从以太网包返回来计算所加的长度，就嫌走弯路了. 
另外，如果对方没有数据过来，则自己的确认号不变，序列号为上次的序列号加上本次应
用层
数据发送长度. 
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接，如
图1所示。 （1）第一次握手：建立连接时，客户端A发送SYN包（SYN=j）到服务器B，并进入
SYN_SEND状态，等待服务器B确认。 
（2）第二次握手：服务器B收到SYN包，必须确认客户A的SYN（ACK=j+1），同时
自己也发送一个SYN包（SYN=k），即SYN+ACK包，此时服务器B进入SYN_RECV
状态。 
（3）第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK
（ACK=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报文的建连请求后，它可以把
ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连
接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所
有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET，也即你可能还需要
发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所
以它这里的ACK报文和FIN报文多数情况下都是分开发送的。 
2．为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？ 
这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可
以直接回到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 
收到一个连接请求，尚未确认  tcp三次握手图解
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 状

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