本文目录
- 一文搞懂TCP的三次握手和四次挥手
- TCP中三个函数与三次握手的关系
- TCP 建立连接前的三次握手
- 画图描述tcp三次握手建立连接的过程
- 动画图解TCP三次握手
- 6 张图带你搞懂 TCP 为什么是三次握手，而不是两次或四次
- 图解TCP的三次握手和四次挥手（简单明了）
一文搞懂TCP的三次握手和四次挥手
TCP的三次握手和四次挥手实质就是TCP通信的连接和断开。 三次握手：为了对每次发送的数据量进行跟踪与协商，确保数据段的发送和接收同步，根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系，并建立虚连接。 四次挥手：即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。 TCP三次握手、四次挥手时序图 TCP协议位于传输层，作用是提供可靠的字节流服务，为了准确无误地将数据送达目的地，TCP协议采纳三次握手策略。 三次握手原理： 第1次握手：客户端发送一个带有SYN（synchronize）标志的数据包给服务端； 第2次握手：服务端接收成功后，回传一个带有SYN/ACK标志的数据包传递确认信息，表示我收到了； 第3次握手：客户端再回传一个带有ACK标志的数据包，表示我知道了，握手结束。 其中：SYN标志位数置1，表示建立TCP连接；ACK标志表示验证字段。 可通过以下趣味图解理解三次握手： 三次握手过程详细说明： 1、客户端发送建立TCP连接的请求报文，其中报文中包含seq序列号，是由发送端随机生成的，并且将报文中的SYN字段置为1，表示需要建立TCP连接。（SYN=1，seq=x，x为随机生成数值）； 2、服务端回复客户端发送的TCP连接请求报文，其中包含seq序列号，是由回复端随机生成的，并且将SYN置为1，而且会产生ACK字段，ACK字段数值是在客户端发送过来的序列号seq的基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP建立请求已得到验证。（SYN=1，ACK=x+1，seq=y，y为随机生成数值）这里的ack加1可以理解为是确认和谁建立连接； 3、客户端收到服务端发送的TCP建立验证请求后，会使自己的序列号加1表示，并且再次回复ACK验证请求，在服务端发过来的seq上加1进行回复。（SYN=1，ACK=y+1，seq=x+1）。 由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。 四次挥手原理： 第1次挥手：客户端发送一个FIN，用来关闭客户端到服务端的数据传送，客户端进入FIN_WAIT_1状态； 第2次挥手：服务端收到FIN后，发送一个ACK给客户端，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），服务端进入CLOSE_WAIT状态； 第3次挥手：服务端发送一个FIN，用来关闭服务端到客户端的数据传送，服务端进入LAST_ACK状态； 第4次挥手：客户端收到FIN后，客户端t进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，服务端进入CLOSED状态，完成四次挥手。 其中：FIN标志位数置1，表示断开TCP连接。 可通过以下趣味图解理解四次挥手： 四次挥手过程详细说明： 1、客户端发送断开TCP连接请求的报文，其中报文中包含seq序列号，是由发送端随机生成的，并且还将报文中的FIN字段置为1，表示需要断开TCP连接。（FIN=1，seq=x，x由客户端随机生成）； 2、服务端会回复客户端发送的TCP断开请求报文，其包含seq序列号，是由回复端随机生成的，而且会产生ACK字段，ACK字段数值是在客户端发过来的seq序列号基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP断开请求已经得到验证。（FIN=1，ACK=x+1，seq=y，y由服务端随机生成）； 3、服务端在回复完客户端的TCP断开请求后，不会马上进行TCP连接的断开，服务端会先确保断开前，所有传输到A的数据是否已经传输完毕，一旦确认传输数据完毕，就会将回复报文的FIN字段置1，并且产生随机seq序列号。（FIN=1，ACK=x+1，seq=z，z由服务端随机生成）； 4、客户端收到服务端的TCP断开请求后，会回复服务端的断开请求，包含随机生成的seq字段和ACK字段，ACK字段会在服务端的TCP断开请求的seq基础上加1，从而完成服务端请求的验证回复。（FIN=1，ACK=z+1，seq=h，h为客户端随机生成） 至此TCP断开的4次挥手过程完毕。 LISTEN：等待从任何远端TCP 和端口的连接请求。 SYN_SENT：发送完一个连接请求后等待一个匹配的连接请求。 SYN_RECEIVED：发送连接请求并且接收到匹配的连接请求以后等待连接请求确认。 ESTABLISHED：表示一个打开的连接，接收到的数据可以被投递给用户。连接的数据传输阶段的正常状态。 FIN_WAIT_1：等待远端TCP 的连接终止请求，或者等待之前发送的连接终止请求的确认。 FIN_WAIT_2：等待远端TCP 的连接终止请求。 CLOSE_WAIT：等待本地用户的连接终止请求。 CLOSING：等待远端TCP 的连接终止请求确认。 LAST_ACK：等待先前发送给远端TCP 的连接终止请求的确认（包括它字节的连接终止请求的确认） TIME_WAIT：等待足够的时间过去以确保远端TCP 接收到它的连接终止请求的确认。 TIME_WAIT 两个存在的理由： 1.可靠的实现tcp全双工连接的终止； 2.允许老的重复分节在网络中消逝。 CLOSED：不在连接状态（这是为方便描述假想的状态，实际不存在）。
TCP中三个函数与三次握手的关系
TCP是属于网络分层中的传输层，因为OSI分为7层，感觉太麻烦了，所以分为四层就好了，简单。分层以及每层的协议，TCP是属于传输层，如下两张图：TCP三次握手会涉及到状态转换所以这里贴出TCP的状态转换图如下：TCP三次握手简述TCP三次握手如图：第一次握手客户主动（active open）去connect服务器，并且发送SYN 假设序列号为J,服务器是被动打开(passive open)第二次握手服务器在收到SYN后，它会发送一个SYN以及一个ACK（应答）给客户，ACK的序列号是 J+1表示是给SYN J的应答，新发送的SYN K 序列号是K第三次握手客户在收到新SYN K, ACK J+1 后，也回应ACK K+1 以表示收到了，然后两边就可以开始数据发送数据了使用tcpdump观察如下：因为都是在本机同时运行client和server所以命令为：tcpdump -i lo port 5555, 只能监听回路lo接口，结果如下如图用红色圈起来的就是3次握手，但是为什么最后一次握手，为什么ack = 1,而不是369535922 呢，这是因为这里的第三次握手tcpdump显示的是相对的顺序号。但是为了便于观察我们需要把tcpdump的顺序号变为绝对的顺序号。命令只需要加-S(大写)便可，即：tcpdump -i lo port 5555 -S加上之后结果就正常了如下图：从tcpdump的数据，可以明显的看到三次握手的过程是：第一次握手：client syn 2322326583 —》 server第二次握手：server syn 3573692787, ack 2322326583 + 1 —》 client第三次握手：client ack 3573692787 + 1 --》serverTCP三次握手详细解析过程：第一次握手客户在socket() connect()后主动(active open)连接上服务器, 发送SYN ，这时客户端的状态是SYN_SENT服务器在进行socket(),bind(),listen()后等待客户的连接，收到客户端的 SYN 后，1.半连接队列(syn queue)未满服务器将该连接的状态变为SYN_RCVD, 服务器把连接信息放到半连接队列(syn queue)里面。2.半连接队列(syn queue)已满服务器不会将该连接的状态变为SYN_RCVD，且将该连接丢弃(SYN flood攻击就是利用这个原理，对于SYN foold攻击，应对方法之一是使syncookies生效，将其值置1即可，路径/proc/sys/net/ipv4/tcp_syncookies，即使是半连接队列syn queue已经满了，也可以接收正常的非恶意攻击的客户端的请求，但是这种方法只在无计可施的情况下使用，man tcp里面的解析是这样说的，但是我不知道为什么Centos6.9默认是置为1，所以这让我很疑惑)。半连接队列(syn queue)最大值 /proc/sys/net/ipv4/tcp_max_syn_backlogSYN flood攻击攻击方的客户端只发送SYN分节给服务器，然后对服务器发回来的SYN+ACK什么也不做，直接忽略掉，不发送ACK给服务器；这样就可以占据着服务器的半连接队列的资源，导致正常的客户端连接无法连接上服务器。-----(SYN flood攻击的方式其实也分两种，第一种，攻击方的客户端一直发送SYN，对于服务器回应的SYN+ACK什么也不做，不回应ACK, 第二种，攻击方的客户端发送SYN时，将源IP改为一个虚假的IP, 然后服务器将SYN+ACK发送到虚假的IP, 这样当然永远也得不到ACK的回应。)第二次握手服务器返回SYN+ACK给到客户端，客户端收到SYN+ACK后，状态从SYN_SENT变为ESTABLISHED，也即是connect()函数的返回。第三次握手全连接队列(accept queue)的最大值 /proc/sys/net/core/somaxconn (默认128)全连接队列值 = min(backlog, somaxconn)这里的backlog是listen(int sockfd, int backlog)函数里面的那个参数backlog1.全连接队列(accept queue)未满服务器收到客户端发来的ACK, 服务端该连接的状态从SYN_RCVD变为ESTABLISHED,然后服务器将该连接从半连接队列(syn queue)里面移除，且将该连接的信息放到全连接队列(accept queue)里面。2.全连接队列(accept queue)已满服务器收到客户端发来的ACK, 不会将该连接的状态从SYN_RCVD变为ESTABLISHED。当然全连接队列(accept queue)已满时，则根据 tcp_abort_on_overflow 的值来执行相应动作/proc/sys/net/ipv4/tcp_abort_on_overflow 查看参数值2.1 tcp_abort_on_overflow = 0则服务器建立该连接的定时器，这个定时器是一个服务器的规则是从新发送syn+ack的时间间隔成倍的增加，比如从新了第二次握手，进行了5次，这五次的时间分别是 1s, 2s,4s,8s,16s,这种倍数规则叫“二进制指数退让”(binary exponential backoff)给客户端定时从新发回SYN+ACK即从新进行第二次握手，(如果客户端设定的超时时间比较短就很容易出现异常)服务器从新进行第二次握手的次数/proc/sys/net/ipv4/tcp_synack_retries2.2 tcp_abort_on_overflow = 1关于tcp_abort_on_overflow的解析如下：意思应该是，当 tcp_abort_on_overflow 等于1 时,重置连接(一般是发送RST给客户端)，至于怎么重置连接是系统的事情了。不过我在查资料的过程发现，阿里中间件团队博客说并不是发送RST， —这个博客跑的实例观察到的是服务器会忽略client传过来的包，然后client重传，一定次数后client认为异常，然后断开连接。当然，我们写代码的都知道代码是第一手的注释，实践是检验真理的唯一标准，最好还是自己以自己实践为准，因为可能你的环境跟别人的不一样。)查看全连接队列(accept queue)的使用情况如上图，第二列Recv-Q是，全连接队列接收到达的连接，第三列是Send-Q全连接队列的所能容纳最大值，如果，Recv-Q 大于 Send-Q 那么大于的那部分，是要溢出的即要被丢弃overflow掉的。感想：1.本来想写TCP连接的建立和终止的，没想到要讲清楚TCP连接的建立已经很大的篇幅了，就只讲TCP连接的建立而已。2.以前看书的时候，没有解决一个问题的来的深刻或者说脉络清晰，这个就是主题阅读的好处吧。3.以前没有养成一个遇到问题深入解析，解决问题的习惯，今后慢慢养成。下面的参考1有实例，会比较详细一点，清晰一些。参考：***隐藏网址******隐藏网址******隐藏网址******隐藏网址******隐藏网址***————————————————版权声明：本文为CSDN博主「jun2016425」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。***隐藏网址***
TCP 建立连接前的三次握手
所谓的“三次握手”：为了对每次发送的数据量进行跟踪与 协商 ，确保数据段的发送和接收同步，根据所接收到的数据量而确认数据发送、接收完毕后何时 撤消 联系，并建立虚连接。 为了提供可靠的传送， TCP 在发送新的数据之前，以特定的顺序将数据包的序号，并需要这些包 传送 给目标机之后的确认消息。TCP总是用来发送大批量的数据。当 应用程序 在收到 数据 后要做出确认时也要用到TCP。 第一次握手：建立连接时， 客户端 发送 syn 包（seq=j）到 服务器 ，并进入 SYN_SENT 状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。 第二次握手： 服务器 收到 syn 包，必须确认客户端的SYN（ ack =j+1），同时自己也发送一个SYN包（seq=k），即SYN+ACK包，此时服务器进入 SYN_RECV 状态。 第三次握手： 客户端 收到 服务 器的SYN+ACK包，向 服务器 发送确认包ACK( ack =k+1)，此包发送完毕，客户端和服务器进入 ESTABLISHED （TCP连接成功）状态，完成三次握手。 在 三次握手协议 中， 服务器 维护一个未连接队列，该队列为每个 客户端 的SYN包（ seq =j）开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在 服务器 处于 Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。 表示内核为相应套接字排队的最大连接个数。SYN-ACK重传次数 服务器 发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。 是指半连接队列的条目存活的最长时间，也即 服务 器从收到SYN包到确认这个 报文 无效的最长时间，该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。
画图描述tcp三次握手建立连接的过程
答:如下图所示。
- 客户端主动发出请求，并令其SYN=1， 并设置S1Q序号值等于X;
- 服务器端接收到请求之后进行响应，发送SYN=1，ACK=1，表示同意建立连接，开始分配服务器资源。同时服务器端发送序号seq=y，服务器期待收到的数据序号ack=x+1;
- 客户端收到服务器的期待以后，并发送序号seq=x+1对应的数据，同时ack=y+1表示期待收到序号为y+1对应的数据;
动画图解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 同步SYN SYN是同步序列号，在建立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并没有要求建立连接。
6 张图带你搞懂 TCP 为什么是三次握手，而不是两次或四次
1三次握手
2两次握手（情况1）
3两次握手（情况2）
OK，下面正经地来回答下这个问题，要搞清楚这个问题，首先得了解TCP究竟是如何保证可靠传输的。
PS：TCP协议中，主动发起请求的一端称为『客户端』，被动连接的一端称为『服务端』。不管是客户端还是服务端，TCP连接建立完后都能发送和接收数据。
起初，服务器和客户端都为CLOSED状态。在通信开始前，双方都得创建各自的传输控制块（TCB）。服务器创建完TCB后便进入LISTEN状态，此时准备接收客户端发来的连接请求。
第一次握手
客户端向服务端发送连接请求报文段。该报文段的头部中SYN=1，ACK=0，seq=x。请求发送后，客户端便进入SYN-SENT状态。
第二次握手
服务端收到连接请求报文段后，如果同意连接，则会发送一个应答：SYN=1，ACK=1，seq=y，ack=x+1。该应答发送完成后便进入SYN-RCVD状态。
第三次握手
当客户端收到连接同意的应答后，还要向服务端发送一个确认报文段，表示：服务端发来的连接同意应答已经成功收到。该报文段的头部为：ACK=1，seq=x+1，ack=y+1。客户端发完这个报文段后便进入ESTABLISHED状态，服务端收到这个应答后也进入ESTABLISHED状态，此时连接的建立完成！
防止失效的连接请求报文段被服务端接收，从而产生错误。
PS：失效的连接请求：若客户端向服务端发送的连接请求丢失，客户端等待应答超时后就会再次发送连接请求，此时，上一个连接请求就是『失效的』。
若建立连接只需两次握手，客户端并没有太大的变化，仍然需要获得服务端的应答后才进入ESTABLISHED状态，而服务端在收到连接请求后就进入ESTABLISHED状态。
此时如果网络拥塞，客户端发送的连接请求迟迟到不了服务端，客户端便超时重发请求，如果服务端正确接收并确认应答，双方便开始通信，通信结束后释放连接。此时，如果那个失效的连接请求抵达了服务端，由于只有两次握手，服务端收到请求就会进入ESTABLISHED状态，等待发送数据或主动发送数据。但此时的客户端早已进入CLOSED状态，服务端将会一直等待下去，这样浪费服务端连接资源。
TCP连接的释放一共需要四步，因此称为『四次挥手』。
我们知道，TCP连接是双向的，因此在四次挥手中，前两次挥手用于断开一个方向的连接，后两次挥手用于断开另一方向的连接。
第一次挥手
若A认为数据发送完成，则它需要向B发送连接释放请求。该请求只有报文头，头中携带的主要参数为：FIN=1，seq=u。此时，A将进入FIN-WAIT-1状态。
第二次挥手
B收到连接释放请求后，会通知相应的应用程序，告诉它A向B这个方向的连接已经释放。此时B进入CLOSE-WAIT状态，并向A发送连接释放的应答，其报文头包含：ACK=1，seq=v，ack=u+1。
A收到该应答，进入FIN-WAIT-2状态，等待B发送连接释放请求。
第二次挥手完成后，A到B方向的连接已经释放，B不会再接收数据，A也不会再发送数据。但B到A方向的连接仍然存在，B可以继续向A发送数据。
第三次挥手
当B向A发完所有数据后，向A发送连接释放请求，请求头：FIN=1，ACK=1，seq=w，ack=u+1。B便进入LAST-ACK状态。
第四次挥手
A收到释放请求后，向B发送确认应答，此时A进入TIME-WAIT状态。该状态会持续2MSL时间，若该时间段内没有B的重发请求的话，就进入CLOSED状态，撤销TCB。当B收到确认应答后，也便进入CLOSED状态，撤销TCB。
为了保证B能收到A的确认应答。若A发完确认应答后直接进入CLOSED状态，那么如果该应答丢失，B等待超时后就会重新发送连接释放请求，但此时A已经关闭了，不会作出任何响应，因此B永远无法正常关闭。
***隐藏网址***
图解TCP的三次握手和四次挥手（简单明了）
标志位： SYN: 表示连接请求 ACK: 表示确认 FIN: 表示关闭连接 序号： seq:表示报文序号 ack: 表示确认序号 （1）图示三次握手： 1～～～第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入 SYN_SENT状态，等待Server确认。 2～～～第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1， ack (number )=J+1，随机产生一个值seq=K， 并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。 3～～～第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1， 并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功， Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据 了。 （2）图示四次挥手： 1++++第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送。 2++++第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1。 3++++第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送。 4++++第四次挥手：Client收到FIN后，接着发送一个ACK给Server，确认序号为收到序号+1。
