TCP连接管理
一、TCP连接建立
第一步
客户机A的TCP会向服务器的TCP发送一个不包含应用层数据的数据的TCP报文段。该报文段中首部标志位SYN被置为1,此报文段也被叫做SYN报文段。并且A会随机地选择一个初始序号(client_isn),将其填入首部中的序号字段(注意为了避免某些安全性的攻击,此处的随机化选择有着不少研究,后面会补充)。然后,该报文被封装进IP数据报,发送给服务器。
第二步
一旦TCPSYN报文段的IP数据包到达服务器后,服务器就会从IP数据包中提取出TCPSYN报文段,为该TCP连接分配TCP缓存和变量,并向客户机发送允许TCP连接的报文段,这个报文段也不包含应用层数据。(这里需要注意如果在完成三次握手的第三步之前分配缓存和变量会使得TCP易受到称为SYN洪泛的拒绝服务攻击服务)
在发送的报文中,标志位SYN被置为1,确认序号被置为client_isn+1,服务器也会选用一个初始序号将其放入报文中的序号字段。这个报文有时也会被称为SYNACK报文段(SYNACK segment)。
第三步
在收到SYNACK报文段后,客户也要给这个连接分配缓存和变量。然后,客户机A会向服务器发送对允许连接
报文的确认,完成连接的建立。此时报文中,SYN置为0,确认序号为sever_isn+1。在此报文段中也可以携带客户机到服务器的数据了。
完成这三个步骤后,客户机和服务器就可以相互发送包含数据的报文段啦。在以后的每个报文中SYN都为0。
创建连接需要发送三个报文,所以这个过程也叫3次握手(three-way shakehand)。
二、TCP连接释放
第一步
客户进程发出关闭TCP连接命令。客户TCP便会向服务器进程发送标志位FIN=1的报文段,便进入FIN_WAIT_1阶段。服务器TCP收到该报文段后就向客户机发送确认报文段并通知上层应用程序该TCP连接即将关闭,然后,服务器进入CLOSE_WAIT阶段。
第二步
客户机TCP收到确认报文,然后进入FIN_WAIT_2阶段,等待来自服务器的含有FIN=1的报文段。
服务器在这段时间还是可以向客户机发送含上层应用程序数据的报文段,客户机接收并发送确认报文。最后,服务器TCP向客户机发送含FIN=1的报文段,便进入LASE_ACK阶段。
第三步
客户机TCP收到含FIN=1的报文段向服务器发出确认报文,便进入TIME_WAIT阶段,等待2MSL后便释放所有连接所占资源。如果客户给服务器发送的确认报文丢失,那么在这段时间内,便可进行重传操作。这段时间一过,客户将释放所有连接所占资源。
服务器TCP收到客户机的确认ACK后便释放连接所占资源。
三、SYN洪泛攻击
SYN Flood 或称 SYN洪水、SYN洪泛是一种阻断服务攻击,起因于攻击者传送一系列的SYN请求到目标系统。
SYN Flood是一种广为人知的攻击,一般对现代网络不太有效。这种攻击只有在服务器在收到SYN后分配资源,但在收到ACK之前这个区段有效。
SYN Flood攻击目前有两种方法,不过都与服务器端没收到ACK有关。恶意用户可以跳过传送最后的ACK信息;或者在SYN里透过欺骗来源IP地址,这让服务器送SYN-ACK到假造的IP地址,因此永不可能收到ACK。这两个案例服务器会花点时间等抄收通知,故一个简单的网络壅塞可能是由于没有ACK造成的。
如果这些半开通连线绑定服务器资源,透过海量SYN信息淹没服务器是有可能耗尽其资源。一旦所有资源都拨给半开通连线所保留,没有新的连线(不管合法不合法)可被建立,导致阻断服务攻击。某些系统可能会故障得很糟糕,甚至宕机如果其他作业系统函式渴望这种形式的资源。
建议的反制方法包括SYN cookie或者限定某一段时间内来自同一来源请求新连线的数量,不过因为现代的TCP/IP堆叠没有上面所述的瓶颈,因此介于SYN Flood与其它种基于通道容量类型的攻击应该会只有很小或几乎没有差别。
( 摘自维基百科,原视频来自Youtube)比较会装傻会卖萌
比较想你关注我(* ̄∇ ̄*)