tcp三次握手第一次发送(Tcp三次握手四次挥手)

TCP 三次握手过程不管是对于本科计算机网络学习还是考研考计网的同学来说都是必考的一个，所以要掌握 TCP 整个握手的过程显得尤为重要。 一、TCP 是什么？TCP是Transmission Control Protocol(传输控制协议) 的简称，它提供一种面向连接的、可靠的、基于字节流的传输层通信协议。在学习 TCP 握手过程之前，我们首先要了解 TCP 报文头部的一些标志信息，因为在 TCP 握手的过程中，要用到TCP报文头部的一些信息。TCP头部1.1 源端口和目的端口对于端口，我们可以这么理解：我们可以想象发送方很多的窗户，接收方也有很多的窗户，这些窗口都标有不同的端口号，源端口号和目的端口号就分别代表从哪个规定的串口发送到对方接收的窗口。不同的应用程序都有着不同的端口，比如HTTP端口80，SMTP端口25等。1.2 序号TCP是面向字节流的，在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。接收端根据这个编号进行确认，保证分割的数据段在原始数据包的位置。通俗一点的讲，每个字段在传送中用序列号来标记自己位置的，而这个字段就是用来完成双方传输中确保字段原始位置是按照传输顺序的。（发送方是数据是怎样一个顺序，到了接受方也要确保是这个顺序）1.3 确认号确认号是期望收到对方下一个报文段的第一个字节的序号。确认号 = N,则表示到序号N-1为止的所有数据都已经正确收到。例如：B正确收到了A发送过来的一个报文段，其序号字段值为500，而数据字段长度是200字节(序号501~700)，这表明B正确收到了A发送的到序号700为止的数据，因此B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701。1.4 标志位TCP首部中有 6 个标志比特，它们中的多个可同时被设置为 1，主要是用于操控 TCP 的状态机的，依次为URG，ACK，PSH，RST，SYN，FIN。今天我们只介绍我们用到的三个。1.4.1 确认ACK这个标志位可以理解为发送端发送数据到接收端，发送的时候 ACK置 为 0，一旦接收端接收数据之后，就将 ACK 置为 1，发送端接收到之后，就知道了接收端已经接收了数据。需要注意的一点是：当且仅当ACK = 1时，确认号字段才有效。TCP规定，在连接建立后，所有传送的报文段 都将ACK置为1。1.4.2 同步SYNSYN是同步序列号，在建立TCP连接时用来同步序号。当SYN=1，ACK=0时，表明这是一个连接请求报文段。若对方同意建立连接，则应在响应的报文段中使SYN=1，ACK=1。因此，SYN置为1就表示这是一个连接请求或连接接受报文。1.4.3 终止FIN当发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送方FIN标志位置为1后，表示此报文段的发送方数据发送完毕，请求释放连接。二 T CP三次握手过程TCP 三次握手的过程解决以下三个问题1.要是每一方都能确知对方的存在2.要允许双方协商一些参数(如窗口最大值，是否使用窗口扩大选项以及时间戳选项等)3.能够对运输实体资源(如缓冲大小、连接表中的项目等)进行分配掌握了这些，TCP 的三次握手就简单多了。下面我们就以动画形式进行拆解三次握手过程。初始状态 ：客户端处于closed(关闭)状态，服务器处于listen(监听)状态第一次握手 ：客户端发送请求报文将SYN = 1同步序列号和初始化序列号seq = x发送给服务端，发送完之后客户端处于SYN_Send状态。第二次握手 ：服务端受到SYN请求报文之后，如果同意连接，会以自己的同步序列号SYN(服务端) = 1、初始化序列号seq = y和确认序列号（期望下次收到的数据包）ack = x+ 1以及确认号ACK = 1报文作为应答，服务器为SYN_Receive状态。第三次握手 ： 客户端接收到服务端的SYN + ACK之后，知道可以下次可以发送了下一序列的数据包了，然后发送同步序列号ack = y + 1和数据包的序列号seq = x + 1以及确认号ACK = 1确认包作为应答，客户端转为established状态。三、为什么不能是一次、二次握手，而必须是三次握手？为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况：A发出连接请求，但因连接请求报文丢失而未收到确认。于是A在重传一次连接请求，后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。在此过程中，A一共发送了两个连接请求报文段，其中一个丢失，第二个到达了B。没有已经失效的报文段。但现在出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以至延误到连接释放以后的某个时间才到达B。本来这是一个早已经失效的报文段，但B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了。由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据，但B却以为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。 采用三次握手的办法可以防止上述现象的发生，例如在刚才的情况下，A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求建立连接。

三次握手即对每次发送的数据量是怎样跟踪进行协商使数据段的发送和接收同步，根据所接收到的数据量而确定的数据确认数及数据发送、接收完毕后何时撤消联系，并建立虚连接。 第一次第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号。第二次第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；第三次 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
TCP需要三次握手才能建立连接，那么为什么需要三次握手呢？

传输控制协议（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连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。举个例子本来一对情侣约好周天去看电影如果是一次挥手即一方发送断开请求之后立即关闭连接。女孩不想去了，就发送：周天不去了，手机就关掉了（关闭连接），如果这个消息没有发送成功。男孩认为约会还是算数的。就一直等待，等待超时的时候询问：还在不在？此时女孩已经关机了，所以接受不到这个信息。男孩可能会等待两个小时之后才选择回去。如果是两次挥手。女孩不想去了，就发送：周天不去了。然后手机没有关机，想确认男孩有没有收到。因为是两次挥手。男孩接到信息后回应：好的。 就选择关机（断开连接，这里先看成男孩已经没有其他数据要发送，因为是两次挥手）。但是回应没有发送到。此时女孩就会一直等，并反复发送消息。但此时男孩已经关机了。女孩可能会反复发送很长时间才选择断开连接。或者男孩回复好的之后，女孩也接受到了，但男孩还有话没说完，想继续聊一聊之前的那个话题，这个话题还很重要。但是因为对面关闭连接也接收不到了。（这就可能出现传输过程中数据的不完整，不满足数据可靠）所以要等双方数据都传输完毕的四次挥手。 可以实时的关闭掉连接。

为什么要三次握手 三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常所以三次握手就能确认双发收发功能都正常，缺一不可。 第四次握手：任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。
只知道三次握手，A向B发送信息，B会向A返回一个收到确认的消息，A还会对这个确认消息发送一次再确认，所以一个消息要经过三次的消息交互才算发送完成，这就是三次握手

摘要第一次握手：主机A发送位码为syn＝1，随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1)，syn=1，ack=1，随机产生seq=7654321的包；第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1，以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1)，ack=1，主机B收到后确认seq值与ack=1则连接建立成功。完成三次握手后，主机A与主机B开始传送数据。四