tcp三次握手四次挥手过程(http的三次握手和四次挥手)

传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。 TCP旨在适应支持多网络应用的分层协议层次结构。 连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。TCP假设它可以从较低级别的协议获得简单的，可能不可靠的数据报服务。 原则上，TCP应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统之上操作。传输控制协议（TCP，Transmission Control Protocol）是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。互联网络与单个网络有很大的不同，因为互联网络的不同部分可能有截然不同的拓扑结构、带宽、延迟、数据包大小和其他参数。TCP的设计目标是能够动态地适应互联网络的这些特性，而且具备面对各种故障时的健壮性。三次握手过程理解第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。举个例子一对情侣准备周天去看电影。第一次握手 男孩发送：周天去看电影吧。第二次握手 女孩回应：好的。第三次握手 男孩回应：那说好了。1、为什么不能用两次握手进行连接？3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。两次握手出现意外时，将会出现资源的浪费。握手分为Server s，Client c。两次握手，当C想要建立连接时发送一个SYN，然后等待ACK，结果这个SYN因为网络问题没有及时到达S，所以C在一段时间内没收到ACK后，再发送一个SYN，这次S顺利收到，接着C也收到ACK，这时C发送的第一个SYN终于到了S，对于S来说这是一个新连接请求，然后S又为这个连接申请资源，返回ACK，然而这个SYN是个无效的请求，C收到这个SYN的ACK后也并不会理会它，而S却不知道，S会一直为这个连接维持着资源，造成资源的浪费。三次握手出现错误时的应对措施第一次握手A发送SYN传输失败，A,B都不会申请资源，连接失败。如果一段时间内发出多个SYN连接请求，那么A只会接受它最后发送的那个SYN的SYN+ACK回应，忽略其他回应全部回应，B中多申请的资源也会释放第二次握手B发送SYN+ACK传输失败，A不会申请资源，B申请了资源，但收不到A的ACK，过一段时间释放资源。如果是收到了多个A的SYN请求，B都会回复SYN+ACK，但A只会承认其中它最早发送的那个SYN的回应，并回复最后一次握手的ACK第三次握手ACK传输失败，B没有收到ACK，释放资源，对于后序的A的传输数据返回RST。实际上B会因为没有收到A的ACK会多次发送SYN+ACK，次数是可以设置的，如果最后还是没有收到A的ACK，则释放资源，对A的数据传输返回RST。TCP的四次挥手（1）首先客户端想要释放连接，向服务器端发送一段TCP报文，其中：标记位为FIN，表示“请求释放连接“；序号为Seq=U；随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。（2）服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文。前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了（3）服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文，其中：标记位为FIN，ACK，表示“已经准备好释放连接了”。注意：这里的ACK并不是确认收到服务器端报文的确认报文。序号为Seq=W；确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值。随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。（4）客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：标记位为ACK，表示“接收到服务器准备好释放连接的信号”。序号为Seq=U+1；表示是在收到了服务器端报文的基础上，将其确认号Ack值作为本段报文序号的值。确认号为Ack=W+1；表示是在收到了服务器端报文的基础上，将其序号Seq值作为本段报文确认号的值。随后客户端开始在TIME-WAIT阶段等待2MSL服务器端收到从客户端发出的TCP报文之后结束LAST-ACK阶段，进入CLOSED阶段。由此正式确认关闭服务器端到客户端方向上的连接。客户端等待完2MSL之后，结束TIME-WAIT阶段，进入CLOSED阶段，由此完成“四次挥手”。后“两次挥手”既让客户端知道了服务器端准备好释放连接了，也让服务器端知道了客户端了解了自己准备好释放连接了。于是，可以确认关闭服务器端到客户端方向上的连接了，由此完成“四次挥手”。与“三次挥手”一样，在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性，一旦出现某一方发出的TCP报文丢失，便无法继续"挥手"，以此确保了"四次挥手"的顺利完成。为何要四次分手呢？我们在此之前先说说TCP异常断开的情况TCP异常断开1、如果已经建立了连接，但是一方突然出现故障了怎么办？TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。心跳检测机制在TCP网络通信中，经常会出现客户端和服务器之间的非正常断开，需要实时检测查询链接状态。常用的解决方法就是在程序中加入心跳机制。此外，还有Heart-Beat线程、设置TCP属性等机制。通俗理解断电、死机、这意味着所有状态信息的失,如同-个失忆的人,对外界的一-切是陌生的,即使重新启动、程序征常运行也是如此。另一方肯定还是有正常记忆的,但双方状态(记忆)不对称已经无法完成正常意义的沟通,所以最好的方法,就是让好的一方检测到记忆的不对称,然后把自己的记忆也释放( reset) ,双方再重新谈-场恋爰(TCP重连)。好的一方如何检测呢?TCP Keepalive默认情况下, TCP 120分钟会发送检测信号,如果对方没有回复, 会重试几次到放弃,然后宣布对方翘辫子,发送Reset释放连接。对方收到会莫名其妙,会默默地忽视,因为压根没有这个连接(掉电释放掉了)。2个小时是一个漫长的等待 ,滞留的TCP会话会-直站用资源， 这是一种浪费!Application Keepalive为了更快地检测对方已经Dead的事实,应用程序层面可以发送检测信号,比如5 -10分钟检测一次。通过以上两种常用方法,可以克服好的一方永久驻留在内存里的现状,释放是唯一正确的方法 !实, Application Keepalive除了检测对方是否在线,大的作用是为了避免存在于通信双方之间的NAT设备表超时删除,需要周期性地刷新保活。所以四次挥手也是为了能实时的断开连接，释放资源这也是为了应对意外情况比如客户端在发送一次断开报文后直接自行断开了连接。而这个连接服务器端却没有收到。此时服务器并不知道客户端已经断开了连接。在此期间会一直发送请求判断客户端是否连接。直到最后还没有回应，才会断开连接。TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。举个例子本来一对情侣约好周天去看电影如果是一次挥手即一方发送断开请求之后立即关闭连接。女孩不想去了，就发送：周天不去了，手机就关掉了（关闭连接），如果这个消息没有发送成功。男孩认为约会还是算数的。就一直等待，等待超时的时候询问：还在不在？此时女孩已经关机了，所以接受不到这个信息。男孩可能会等待两个小时之后才选择回去。如果是两次挥手。女孩不想去了，就发送：周天不去了。然后手机没有关机，想确认男孩有没有收到。因为是两次挥手。男孩接到信息后回应：好的。 就选择关机（断开连接，这里先看成男孩已经没有其他数据要发送，因为是两次挥手）。但是回应没有发送到。此时女孩就会一直等，并反复发送消息。但此时男孩已经关机了。女孩可能会反复发送很长时间才选择断开连接。或者男孩回复好的之后，女孩也接受到了，但男孩还有话没说完，想继续聊一聊之前的那个话题，这个话题还很重要。但是因为对面关闭连接也接收不到了。（这就可能出现传输过程中数据的不完整，不满足数据可靠）所以要等双方数据都传输完毕的四次挥手。 可以实时的关闭掉连接。

tcp四次挥手，由于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）。这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了。

三次握手(建立连接) 1)客户端发送一个带SYN标志的TCP报文到服务器，这是第1个报文;2)服务端回应客户端，是第2个报文，同时带有ACK标志和SYN标志，以此回应第1步，SYN用于询问客户端是否准备好进行通讯;3)客户再次回应服务端一个ACK报文，是第3个报文。为什么要进行3次握手?当服务端的LISTEN状态下的SOCKET收到SYN报文的请求后，可以把ACK和SYN放在1个报文中来发送，其中ACK的作用是应答，而SYN的作用是同步。四次挥手(连接终止协议)1)TCP客户端发哦是那个一个FIN，用于关闭客户发送到服务器的数据传送;2)服务器收到这个FIN，返回一个ACK，和SYN一样，一个FIN将占用一个序号;3)服务器关闭客户端的连接，发送FIN给客户端;4)客户端返回ACK报文，并将确认序号设置为收到的序号+1。为什么要进行4次挥手? 在TCP连接时，是将SYN和ACK一起发送的，但为什么挥手却没有一起发送呢?因为TCP是全双工模式，接收到FIN时将没有数据再发来，但还是可以继续发送数据。
安全考虑，需要通信双方确认

TCP是一种可靠的，面向连接的全双工传输层协议。TCP连接的建立是一个三次握手的过程。第一次：主机A（通常也称为客户端）发送一个标识了SYN的数据段，表示期望与服务器A建立连接，此数据段的序列号（seq）为a。第二次：服务器A回复标识了SYN+ACK的数据段，此数据段的序列号（seq）为b，确认序列号为主机A的序列号加1（a+1），以此作为对主机A的SYN报文的确认。第三次：主机A发送一个标识了ACK的数据段，此数据段的序列号（seq）为a+1，确认序列号为服务器A的序列号加1（b+1），以此作为对服务器A的SYN报文段的确认。 TCP连接的建立是一个三次握手的过程，而TCP连接的终止则要经过四次挥手。第一次：主机A想终止连接，于是发送一个标识了FIN，ACK的数据段，序列号为a，确认序列号为b。第二次：服务器A回应一个标识了ACK的数据段，序列号为b，确认序号为a+1，作为对主机A的FIN报文的确认。第三次：服务器A想终止连接，于是向主机A发送一个标识了FIN，ACK的数据段，序列号为b，确认序列号为a+1。第四次：主机A回应一个标识了ACK的数据段，序列号为a+1，确认序号为b+1，作为对服务器A的FIN报文的确认。以上四次交互便完成了两个方向连接的关闭。

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报文。