详谈--TCP三次握手四次挥手

('伍亿人才招聘网—人才基地,企业动力,群英汇聚在伍亿!再谈TCP三次握手/四次挥手在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状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据。图1TCP三次握手建立连接由于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所示。图2TCP四次挥手关闭连接伍亿人才招聘网—人才基地,企业动力,群英汇聚在伍亿!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是一个面向连接的服务,面向连接的服务是电话系统服务模式的抽象,每一次完整的数据传输都必须经过建立连接,数据传输和终止连接3个过程,TCP建立连接的过程称为三次握手,下面看一下三次握手的具本过程TCP三次握手过程1主机A通过向主机B发送一个含有同步序列号的标志位的数据段给主机B,向主机B请求建立连接,通过这个数据段,主机A告诉主机B两件事:我想要和你通信;你可以用哪个序列号作为起始数据段来回应我.2主机B收到主机A的请求后,用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应主机A,也告诉主机A两件事:我已经收到你的请求了,你可以传输数据了;你要用哪佧序列号作为起始数据段来回应我3主机A收到这个数据段后,再发送一个确认应答,确认已收到主机B的数据段:"我已收到回复,我现在要开始传输实际数据了这样3次握手就完成了,主机A和主机B就可以传输数据了.3次握手的特点没有应用层的数据SYN这个标志位只有在TCP建立连接时才会被置1握手完成后SYN标志位被置0TCP建立连接要进行3次握手,而断开连接要进行4次,这是由于TCP的半关闭造成的,因为TCP连接是全双工的(即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭,这个单方向的关闭就叫半关闭.关闭的方法是一方完成它的数据传输后,就发送一个FIN来向另一方通告将要终止这个方向的连接.当一端收到一个FIN,它必须通知应用层TCP连接已终止了这个方向的数据传送,发送FIN通常是应用层进行关闭的结果.4次断开伍亿人才招聘网—人才基地,企业动力,群英汇聚在伍亿!1当主机A完成数据传输后,将控制位FIN置1,提出停止TCP连接的请求2主机B收到FIN后对其作出响应,确认这一方向上的TCP连接将关闭,将ACK置13由B端再提出反方向的关闭请求,将FIN置14主机A对主机B的请求进行确认,将ACK置1,双方向的关闭结束.由TCP的三次握手和四次断开可以看出,TCP使用面向连接的通信方式,大大提高了数据通信的可靠性,使发送数据端和接收端在数据正式传输前就有了交互,为数据正式传输打下了可靠的基础名词解释ACKTCP报头的控制位之一,对数据进行确认.确认由目的端发出,用它来告诉发送端这个序列号之前的数据段都收到了.比如,确认号为X,则表示前X-1个数据段都收到了,只有当ACK=1时,确认号才有效,当ACK=0时,确认号无效,这时会要求重传数据,保证数据的完整性.SYN同步序列号,TCP建立连接时将这个位置1FIN发送端完成发送任务位,当TCP完成数据传输需要断开时,提出断开连接的一方将这位置1未连接队列：在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。Backlog参数：表示未连接队列的最大容纳数目。SYN-ACK重传次数服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。半连接存活时间：是指半连接队列的条目存活的最长时间，也即服务从收到SYN包到确认这个报文无效的最长时间，该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。DDOS全名是DistributionDenialofservice(分布式拒绝服务攻击),很多DOS攻击源一起攻击某台服务器就组成了DDOS攻击。DoS的攻击方式有很多种，最基本的DoS攻击就是利用合理的服务请求来占用过多的服务资源，从而使服务器无法处理合法用户的指令。SYN-Flood是目前最流行的DDoS攻击手段，早先的DoS的手段在向分布式这一阶段发展的时候也经历了浪里淘沙的过程。假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的（第三次握手无法完成），这种情况下服务器端一般会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYNTimeout，一般来说这个时间是分钟的数量级（大约为30秒-2分钟）；一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题，但如果有一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接，即使是简单的保存并遍历也会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上如果服务器的TCP/IP栈不够强大，最后的结果往往是堆栈溢出崩溃---即使服务器端的系统足够强大，服务伍亿人才招聘网—人才基地,企业动力,群英汇聚在伍亿!器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求（毕竟客户端的正常请求比率非常之小），此时从正常客户的角度看来，服务器失去响应，这种情况我们称做：服务器端受到了SYNFlood攻击（SYN洪水攻击）。一、Linux服务器上11种网络连接状态:图:TCP的状态机通常情况下:一个正常的TCP连接，都会有三个阶段:1、TCP三次握手;2、数据传送;3、TCP四次挥手注:以下说明最好能结合”图:TCP的状态机”来理解。SYN:(同步序列编号,SynchronizeSequenceNumbers)该标志仅在三次握手建立TCP连接时有效。表示一个新的TCP连接请求。ACK:(确认编号,AcknowledgementNumber)是对TCP请求的确认标志,同时提示对端系统已经成功接收所有数据。FIN:(结束标志,FINish)用来结束一个TCP回话.但对应端口仍处于开放状态,准备接收后续数据。1)、LISTEN:首先服务端需要打开一个socket进行监听，状态为LISTEN./Thesocketislisteningforincomingconnections.侦听来自远方TCP端口的连接请求2)、SYN_SENT:客户端通过应用程序调用connect进行activeopen.于是客户端tcp发送一个SYN以请求建立一个连接.之后状态置为SYN_SENT./Thesocketisactivelyattemptingtoestablishaconnection.在发送连接请求后等待匹配的连接请求3)、SYN_RECV:服务端应发出ACK确认客户端的SYN,同时自己向客户端发送一个SYN.之后状态置为SYN_RECV/Aconnectionrequesthasbeenreceivedfromthenetwork.在收到和发送一个连接请求后等待对连接请求的确认伍亿人才招聘网—人才基地,企业动力,群英汇聚在伍亿!4)、ESTABLISHED:代表一个打开的连接，双方可以进行或已经在数据交互了。/Thesockethasanestablishedconnection.代表一个打开的连接，数据可以传送给用户5)、FIN_WAIT1:主动关闭(activeclose)端应用程序调用close，于是其TCP发出FIN请求主动关闭连接，之后进入FIN_WAIT1状态./Thesocketisclosed,andtheconnectionisshuttingdown.等待远程TCP的连接中断请求，或先前的连接中断请求的确认6)、CLOSE_WAIT:被动关闭(passiveclose)端TCP接到FIN后，就发出ACK以回应FIN请求(它的接收也作为文件结束符传递给上层应用程序),并进入CLOSE_WAIT./Theremoteendhasshutdown,waitingforthesockettoclose.等待从本地用户发来的连接中断请求7)、FIN_WAIT2:主动关闭端接到ACK后，就进入了FIN-WAIT-2./Connectionisclosed,andthesocketiswaitingforashutdownfromtheremoteend.从远程TCP等待连接中断请求8)、LAST_ACK:被动关闭端一段时间后，接收到文件结束符的应用程序将调用CLOSE关闭连接。这导致它的TCP也发送一个FIN,等待对方的ACK.就进入了LAST-ACK./Theremoteendhasshutdown,andthesocketisclosed.Waitingforacknowledgement.等待原来发向远程TCP的连接中断请求的确认9)、TIME_WAIT:在主动关闭端接收到FIN后，TCP就发送ACK包，并进入TIME-WAIT状态。/Thesocketiswaitingafterclosetohandlepacketsstillinthenetwork.等待足够的时间以确保远程TCP接收到连接中断请求的确认10)、CLOSING:比较少见./Bothsocketsareshutdownbutwestilldon’thaveallourdatasent.等待远程TCP对连接中断的确认11)、CLOSED:被动关闭端在接受到ACK包后，就进入了closed的状态。连接结束./Thesocketisnotbeingused.没有任何连接状态TIME_WAIT状态的形成只发生在主动关闭连接的一方。主动关闭方在接收到被动关闭方的FIN请求后，发送成功给对方一个ACK后,将自己的状态由FIN_WAIT2修改为TIME_WAIT，而必须再等2倍的MSL(MaximumSegmentLifetime,MSL是一个数据报在internetwork中能存在的时间)时间之后双方才能把状态都改为CLOSED以关闭连接。目前RHEL里保持TIME_WAIT状态的时间为60秒。当然上述很多TCP状态在系统里都有对应的解释或设置,可见mantcp二、关于长连接和短连接:通俗点讲:短连接就是一次TCP请求得到结果后,连接马上结束.而长连接并不马上断开,而一直保持着,直到长连接TIMEOUT(具体程序都有相关参数说明).长连接可以避免不断的进行TCP三次握手和四次挥手.长连接(keepalive)是需要靠双方不断的发送探测包来维持的,keepalive期间服务端和客户端的TCP连接状态是ESTABLISHED.目前http1.1版本里默认都是keepalive(1.0版本默认是不keepalive的)，ie6/7/8和firefox都默认用的是http1.1版本了(如何查看当前浏览器用的是哪个版本，这里不再赘述)。Apache,java一个应用至于到底是该使用短连接还是长连接，应该视具体情况而定。一般的应用应该使用长连接。tcp四次挥手TCP协议有一个优雅的关闭（gracefulclose）机制，以保证应用程序在关闭连接时不必担心正在传输的数据会丢失。如第4.5节的压缩示例程序所示，这个机制还设计为允许两个方向的数据传输相互独立地终止。关闭机制的工作流程是：应用程序通过调用连接套接字的close()方法或shutdownOutput()方法表明数据已经发送完毕。此刻，底层的TCP实现首先伍亿人才招聘网—人才基地,企业动力,群英汇聚在伍亿!将留存在SendQ队列中的数据传输出去（还要依赖于另一端RecvQ队列的剩余空间），然后向另一端发送一个关闭TCP连接的握手消息。该关闭握手消息可以看作是流终止标志：它告诉接收端TCP不会再有新的数据传入RecvQ队列了。（注意，关闭握手消息本身并没有传递给接收端应用程序，而是通过read()方法返回-1来指示其在字节流中的位置。）正在关闭的TCP将等待其关闭握手消息的确认信息，该确认信息表明在连接上传输的所有数据已经安全地传输到了RecvQ中。只要收到了确认消息，该连接就变成"半关闭（Halfclosed）"状态。直到连接的另一个方向上收到了对称的握手消息后，连接才完全关闭--也就是说，连接的两端都表明它们再没有数据要发送了。TCP连接的关闭事件序列可能以两种方式发生：一种方式是先由一个应用程序调用close()方法（或shutdownOutput()方法），并在另一端调用close()方法之前完成其关闭握手消息；另一种方式是两端同时调用close()方法，它们的关闭握手消息在网络上交叉传输。图6.10展示了以第一种方式关闭连接时，底层实现中的事件序列。关闭握手消息已经发送，套接字数据结构的状态也已经设置为"Closing"（专业术语称为"FIN_WAIT_1"），然后close()调用返回。完成这些工作后，将禁止在该Socket上的任何读写操作（会抛出异常）。当收到关闭握手确认消息后，套接字数据结构的状态则改变为"半关闭"（专业术语称为"FIN_WAIT_2"），这种状态将一直持续，直到接收到另一端的关闭握手消息关闭TCP连接的最后微妙之处在于对Time-Wait状态的需要。TCP规范要求在终止连接时两端的关闭握手都完成后，至少要有一个套接字在Time-Wait状态保持一段时间。这个要求的提出是由于消息在网络中传输时可能延迟。如果在连接两端都完成了关闭握手后，它们都移除了其底层数据结构，而此时在同样一对套接字地址之间又立即建立了新的连接，那么前一个连接在网络上传输时延迟的消息就可能在新连接建立后到达。由于其包含了相同的源地址和目的地址，旧消息就会被错误地认为是属于新连接的，其包含的数据就可能被错误地分配到应用程序中。虽然这种情形可能很少发生，TCP还是使用了包括Time-Wait状态在内的多种机制对其进行防范。Time-Wait状态用于保证每个TCP连接都在一段平静时间内结束，这期间不会有数据发送。平静时间的长度应该等于分组报文在网络上存留的最长时间的两倍。因此，当一个连接完全结束（即套接字数据结构离开Time-Wait状态并被删除），并为同样一对地址上的新连接清理道路后，就不会再有旧实例发送的消息还存留在网络中。实际上，平静时间的长度要依赖于具体实现，因为没有机制能真正限制分组报文在网络上能够延迟的时间。通常使用的时间范围是4分钟减到30秒，或更短。Time-Wait状态最重要的作用是，只要底层套接字数据结构还存在，就不允许在相同的本地端口上关联其他套接字。尤其是试图使用该端口创建新的Socket实例时，将抛出IOException异常。TCP三次握手/四次挥手详解1、建立连接协议（三次握手）（1）客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。（2）服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标志。因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通讯。伍亿人才招聘网—人才基地,企业动力,群英汇聚在伍亿!（3）客户必须再次回应服务段一个ACK报文，这是报文段3。2、连接终止协议（四次挥手）由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。（1）TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送（报文段4）。（2）服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。（3）服务器关闭客户端的连接，发送一个FIN给客户端（报文段6）。（4）客户段发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。CLOSED:这个没什么好说的了，表示初始状态。LISTEN:这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。SYN_RCVD:这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。SYN_SENT:这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。ESTABLISHED：这个容易理解了，表示连接已经建立了。FIN_WAIT_1:这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。TIME_WAIT:表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。CLOSING:这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。CLOSE_WAIT:这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送伍亿人才招聘网—人才基地,企业动力,群英汇聚在伍亿!给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。LAST_ACK:这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。最后有2个问题的回答，我自己分析后的结论（不一定保证100%正确）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报文。TCPPrevioussegmentlost，它告诉发送方数据段丢失；TCPDupACKXXXX#X则代表了数据段丢失TCP状态，XXXX代表数据丢失的位置，#后代表第几次丢失；而TCPRetransmission则代表重发丢失数据。在TCP第三次握手完成后，有时发现会出现一个TCPWindowUpdate，如图3-11所示：图3-11TCPWindowUpdate是TCP通信中的一个状态，它可以发生的原因有很多，但最终归结于发送者传输数据的速度比接收者读取的数据还快，这使得接受端的在缓冲区必须释放一部分空间来装发送过来的数据，然后向发送者发送WindowsUpdate，告诉给发送者应该以多大的速度发送数据，从而使得数据传输与接受恢复正常',)