简述三次握手和四次挥手过程(网络三次握手四次挥手)

TCP是面向连接的协议。传输连接是用来传送TCP报文的，TCP连接传输的三个阶段分别为：连接建立、数据传送和连接释放。TCP连接的建立采用客户服务器模式。主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫做服务器。TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段，三次握手的过程如下图所示。(2)第二次握手：服务器收到 SYN报文段后，如同意连接，则服务器会为该TCP连接分配缓存和变量，并向客户端返回确认报文段，在确认报文段中同步位 SYN = 1 和 确认位 ACK= 1，确认号 ack = x + 1，同时也为自己选择一个初始序号 seq = y。这时TCP服务器进程进入同步收到（SYN-RCVD）状态。(3)第三次握手：客户进程在收到服务器进程的确认报文后，客户端为该TCP连接分配缓存和变量，并向服务器端返回一个报文段，这个报文段是对服务器确认报文段进行确认，该报文段中 ACK = 1，确认号 seq = y + 1，而自己序号为 x + 1（即第二次握手服务器确认报文段的确认号）。客户端在发送ACK报文段后进入已建立连接（ESTABLISHED）状态，这时TCP连接已经建立。当服务器收到客户端的确认后，也进入ESTABLISHED状态。这样选择序号的目的是为了防止由于网络路由TCP报文段可能存在延迟抵达与排序混乱的问题，从而而导致某个连接的一方对它作错误的解释。下图表示了建立连接使用固定的序号存在的问题：由于一个TCP连接是被一对端点所表示的，其中包括2个IP地址和2个端口号构成的4元组，因此即便是同一个连接也会出现不同的实例，如果连接由于某个报文段长时间延迟而关闭，然后又以相同的4元组被重新打开，那么可以相信延迟的报文段又会被视为有效据重新进入新连接的数据流中，这就会导致数据乱序问题。为了避免上述的问题，避免连接实例间的序号重叠可以将风险降至最低。如前文所述，一个TCP报文段只有同时具备连接的4元组与当前活动窗口的序列号，才会在通信过程中被对方认为是正确的。然而，这也反应了TCP连接的脆弱性：如果选择合适的序列号、IP地址和端口号，那么任何人都能伪造一个TCP报文段，从而打断TCP的正常连接。所以使用初始化序号的方式（通常随机生成序号）使得序列号变得难猜，或者使用加密来避免利用这种缺点被攻击。所以，可以明白在建立TCP连接时，客户端和服务器端初始化序列号，就避免了上述的问题。前面说过，TCP序号占32位，范围是0~232- 1，并且可以重用。假如 第一次握手可以携带数据的话，如果有人使用伪TCP报文段恶意攻击服务器，那么每次都在第一次握手中的SYN报文中携带大量的数据，因为它不会理会服务器的发送和接收能力是否正常，不断地给服务器重复发送这样携带大量数据的SYN报文，这会导致服务器需要花费大量的时间和内存来接收这些报文数据，这会将导致服务器连接资源和内存消耗殆尽。所以，之所以第一次握手不能携带数据，其中的一个原因就是避免让服务器受到攻击。而对于第三次握手，此时客户端已经建立了连接，通过前两次已经知道了服务器的接收正常，并且也知道了服务器的接收能力是多少，所以可以携带数据。根据前面描述，在第一次握手，客户端向服务发送建立连接请求，第二次握手，服务器同意建立连接，并向客户端返回一个确认报文，至此客户端已经知道了服务器同意建立连接，为什么客户端还需要对服务器的允许连接报文段进行确认？第三个ACK报文段的目的简单来说主要是为了实现可靠数据传输。三次握手的目的不仅在于让通信双方了解一个连接正在建立，还在于利用数据包的选项来承载特殊的信息，交换初始序列号（Initial Sequence，ISN）。为了实现可靠传输，TCP协议通信双方，都必须维护一个序列号，以标识发送出去的数据报中，哪些是已经被对方收到的。三次握手的过程是通信双方想要告知序列号起始值，并确认已经收到序列号的必经过程。如上图，在两次握手过程中，通信双方都随机选择了自己的初始段序号，并且第二次握手的时候客户端收到了自己的确认序号，确认了自己的序列号，而服务器端还没有确认自己的序列号，没有收到确认序号， 如果这时候两次握手下就进行数据传递， 序号没有同步，数据就会乱序。即如果只是两次握手，最多只有客户端的起始序列号能被确认，而服务器断的序列号则得不到确认。在三次握手的过程中，服务器为了响应一个受到的SYN报文段，会分配并初始化连接变量和缓存，然后服务器发送一个SYNACK报文段进行响应，并等待客户端的ACK报文段。如果客户不发送ACK来完成该三次握手的第三步，最终（通常在一分多钟之后）服务器将终止该半开连接并回收资源。这种TCP连接管理协议的特性就会有这样一个漏洞，攻击者发送大量的TCP SYN报文段，而不完成第三次握手的步骤。随着这种SYN报文段的不断到来，服务器不断为这些半开连接分配资源，从而导致服务器连接资源被消耗殆尽。这种攻击就是SYN泛供攻击。为了应对这种攻击，现在有一种有效的防御系统，称为SYN cookie。SYN cookie的工作方式如下：连接释放的四次挥手过程如下图所示：(2)第二次挥手：服务器收到连接释放报文段后即发出确认，确认为ACK = 1，确认号为ack = u + 1，序号seq = v（其值是服务器前面已传送过的数据最后一个字节的序号加1），然后服务器就进入了关闭等待（CLOSE-WAIT）状态。(3)第三次挥手：如果此时服务器没有数据要发送了，此时服务器向客户端发出连接释放报文段，其FIN = 1，假设器序号为seq = w（在半关闭状态下服务器可能又发送了一些数据），服务器必须重复上次以发送的确认号ack = u + 1（因为客户端没有向服务器发送过数据，所以确认号和上次一致）。这时，服务器进入最后确认（LAST-ACK）状态，等待客户端的确认。(4)第四次挥手：客户端在收到服务器端发出的连接释放报文段后，必须对此发出确认，在确认报文段中将ACK置位1，确认号ack = w + 1，而自己的序号为seq = u + 1。之后客户端进入时间等待（TIME-WAIT）状态。在经过时间等待计时器设置的时间2MSL后，客户端才进入关闭（CLOSE）状态这是为了保证客户端发送的最后一个ACK报文段能够到达服务器端。客户端发送的ACK报文段可能丢失，因而使服务器收不到对自己已发送的释放连接报文段的确认。服务器会重传连接释放报文段，重新启动2MSL计时器，最终，客户端和服务器端都能进入CLOSE状态。在建立连接时，服务器端处于LISTEN状态时，当收到SYN报文段的建立连接请求后，它可以把ACK报文段和SYN报文段（ACK报文段起确认作用，即确认客户端的连接建立请求；SYN报文段起同步作用）放在一起发送，所以在连接建立时四次握手（即第二次握手时，服务器的ACK报文段和SYN报文段分开发送）可以合并为三次握手。而在释放连接时需要四次是因为TCP连接的半关闭造成的。由于TCP是全双工的（即数据可在两个方向上同时传递），因此，每个方向都必须要单独进行关闭，这个单方向的关闭就叫半关闭。在关闭连接时，当服务器收到客户端的FIN报文通知时，它仅仅表示客户端没有数据发送服务器了；但服务器未必将所有的数据都全部发送给了客户端，所以服务器端未必马上也要关闭连接，也即服务器端可能还需要发送一些数据给客户端之后，再发送FIN报文给客户端来表示现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的，这也是为什么释放连接时需要交换四次报文了。

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

第一次握手：客户端向服务端发送 SYN 报文，服务端确认接收了 SYN 报文。 第二次握手：服务端在确认接收了 SYN 报文之后，会返回向客户端发送 SYN 报文和 ACK 确认报文。第三次握手：客户端接收到 SYN 报文了 ACK 报文 之后双方就建立起了连接，可以好好玩耍了。第一次挥手：客户端向服务端发送数据，发送完成之后会发送一个 FIN 报文，告诉服务端数据发送完毕。第二次挥手：服务端接收到 FIN 报文之后，将 ACK 报文返回给客户端，告诉客户端（服务端）已经接收到数据。第三次挥手：服务端处理完数据之后再发送一个 FIN 报文给客户端，告诉客户端（服务端）已经处理完毕。 第四次挥手：客户端接收到服务端发来的 FIN 报文之后就能确认这次的数据传输完成。可以关闭本次数据传输连接了。

TCP/IP 传输协议的 TCP 协议是面向连接的，也就是传输数据之前，必须建立可靠的连接。建立连接的过程中，需交换信息（如选取哪种协议、协议版本等），这个过程称为 握手 handshaking 。 握手过程中会协商后续通信使用的参数，如传输速率、编码方式、校验，以及其他协议选取、硬件支持的功能等。握手是两个实体之间的通信，但在 TCP/IP 中握手常指 TCP 的三次握手。TCP 中的数据传输、连接建立与终止都由特定控制参数管理，控制参数有以下这些：建立 TCP 连接需要三次握手：TCP 连接的双方通过三次握手确定 TCP 连接的初始序列号、窗口大小以及最大数据段，这样通信双方就能利用连接中的初始序列号保证双方数据段的不重不漏，通过窗口大小控制流量，并使用最大数据段避免 IP 协议对数据包分片。换个角度看为什么需要三次握手？客户端和服务端通信前要进行连接，三次握手就是为了确保自己和对方的收发能力是正常的。三次握手后，客户端、服务端才确认了自己的接收、发送能力均是正常的。HTTP 协议中的数据是明文传输的，任何中间人（man-in-the-middle）都可以读取传输的数据，因此 HTTP 是一种不安全的协议。HTTPS 是 HyperText Transfer Protocol Secure 的缩写。但 HTTPS 协议自身不能加密数据，它需要借助 SSL 或 TLS 协议层进行加密。HTTP 协议和 TLS 协议都位于 application layer。TCP 三次握手建立连接后，使用 TLS 握手建立安全连接，后续使用协商的加密算法先对数据进行加密，再通过 HTTP 传输。数据加密后，中间人即使获得了数据，也无法读取数据内容，进而避免了中间人攻击（man-in-the-middle-attack）。HTTP 协议和 TLS 协议一起使用时，称为 HTTPS 协议。App 想要使用 TLS 加密通信，只需网址使用 https:// 前缀即可。要了解 TLS 工作原理，需先了解加密的工作原理，以及各种加密算法。加密就是将数据从一种格式编码为另一种格式，编码时使用一些数学算法、秘密参数。使用相同算法、参数，可以解密数据，这个过程中的参数称为密钥（key）。非对称加密算法有两个 key：最流行的非对称加密算法是 RSA 加密算法，广泛用于密钥交换和数字签名验证。但现在正逐步迁移至更安全高效的 Diffie-Hellman （缩写为 D-H）算法。非对称加密算法通常速度慢，更耗费 CPU，且 key、数据越长，加密、解密耗费时间也越长。因此，数据量大时不要使用非对称加密，而应使用对称加密（symmetric key cryptography），对称加密速度更快、性能更高。非对称加密用于传输对称加密密钥。对称加密算法也称为共享密钥加密（shared key），它使用相同的 key 加密、解密。对称加密算法主要用于受信任两者之间建立加密通道。因为第三方无法获取对称密钥，因此只有建立通道的双方才可以解密数据。最流行的对称加密算法是 AES（Advanced Encryption Standard 的缩写，即高级加密标准），SSL 协议由 Netscape 团队设计，于1995年发布 SSL 2.0版本，之后发布了 SSL 3.0版本，IETF 已于2015年不推荐使用 SSL 3.0。目前，TLS 协议已经替代了 SSL 协议，SSL 协议已不再使用。TLS 是旨在提供安全通信的加密协议，使用 TLS 可以加密与服务器的所有通信。当前使用最广的是 TLS 1.2、TLS 1.3。TLS 1.3 发布于2018年，是对 TLS 1.2 的全面修订，在性能和安全性方面都有很大提升，并且减少了建立安全连接所需的握手次数。TLS 1.3 只支持 Diffie-Hellman 非对称加密算法，移除了 RSA 算法。使用 HTTPS 发送 HTTP 请求时，首先使用三次握手建立可靠的 TCP 连接，之后就通过 TLS 四次握手交换双方的密钥。下面介绍 TLS 1.2 连接建立过程：TLS 握手的关键在于利用通信双方生成的随机字符串和服务端的公钥生成一个双方经过协商后的密钥，通信双方后续使用这个对称密钥加密数据，防止中间人监听和攻击，保障通信安全。在 TLS 1.2 中，需要 2-RTT（Round-Trip Time，往返延迟）才能建立 TLS 连接。在 TLS 1.3 中，客户端不仅发送 ClientHello、支持的协议、加密算法，还尝试猜测服务器将选择哪种密钥协商算法，并为此发送共享密钥。这样服务端选取加密算法后，因为已经有了 client key，可以立即生成 key，进而减少一次 RTT。建立连接时需要发送三个 packet，但终止连接时需要四个 packet，也称为四次挥手。因为 TCP 连接是全双工的，每个方向都必须独立终止。终止 TCP 连接的四次挥手：在第二次挥手时，如果服务端也想终止连接，可以为 FIN 设置不同于客户端 FIN 的序列号。客户端收到 FIN 后，发送 ACK，它的 acknowledgement number 为 FIN sequence number 加一。这一过程结束后，服务端与客户端的连接也终止了，这样的话整个过程进行了三次挥手。客户端想要通过 HTTP 请求访问服务端时，需要经过三次握手；通过 HTTPS 访问服务端时，需要额外增加四次握手。总结一下 HTTP 建立连接、终止连接：需要注意的是，本文所说的三次握手、七次握手、四次挥手都是基于特定版本的协议，不同版本的协议所需握手次数可能不同。HTTP/3 就是一个例子，它使用基于 UDP 的 QUIC 协议进行握手，将 TCP 和 TLS 握手过程结合起来，握手次数从七次减少到了三次。参考资料：欢迎更多指正：https://github.com/pro648/tips本文地址：https://github.com/pro648/tips /blob/master/sources/三次握手、七次握手、四次挥手.md

我们可以看到首先主机A发送一个SYN报文打算建立连接， SYN=1 ACK=0 seq=x然后主机B收到请求报文后，返回确认报文SYN=1 ACK=1 seq=y ack=x+1SYN=1代表这条不是普通报文，是一个请求或者响应报文ACK=0 请求　ACK=1响应然后主机A对报文进行确认SYN=0 ACK=1 seq=x+1 ack=y+1之前的主机A发送的SYN报文消耗一个序号　所以这里的seq=x+1为了防止已经失效的报文突然又传送到主机B这里假设一种情况，主机A发送了一个SYN报文，然后这个报文因为网络阻塞等原因，延误到报文超时失效才达到主机B。主机B误认为是A的另一次请求，则同意并返回确认报文。然而主机A因为没有发送请求报文，而不理会这个确认报文。也不向主机B发送数据，主机B一直等待，资源浪费。如果是三次握手，则刚刚主机B发生的确认报文，主机A不会发送确认。主机B没接受确认也不会建立这次连接了。我们首先看到主机A发送一个FIN报文请求释放连接FIN=1 seq=uFIN报文消耗一个序号，这里seq=u是上一次传输数据的最后一个字节的序号+1主机B收到FIN报文，返回确认报文ACK=1 ack=u+1 seq=vv也是主机B已经传送过数据最后一个字节序号+1主机B通知上层应用，A到B的连接释放，此时处于半连接状态B可能还要向A传送数据...B不再向A发送数据，上层应用通知TCP释放连接B发起一个FIN报文FIN=1 ACK=1 ack=u+1 seq=v对上一次的一端释放的确认，同时发送这一方的释放，上一次发送的ACK报文不消耗序号 seq=vA收到报文后，发送确认报文ACK=1 ack=v+1 seq=u+1FIN报文消耗一个序号seq=u+1等待超时2MSL在等待过程中若A没有再收到B的FIN报文，则代表A的确认报文没有丢失，释放连接。若有，A再重传确认报文到B等待超时。65535-20-20=65495因为IP数据报最大长度65535 TCP首部20字节 IP首部20字节，剩下的就是数据部分。数据的字节长度超过TCP报文段中的序号字段可能编出的最大序号，通过循环使用序号，仍能用TCP来传送。完全可能。设想A连续发送两个报文段：（SEQ＝92，DATA共8个字节）和（SEQ＝100，DATA共20字节），均正确到达B。B连续发送两个确认：（ACK＝100）和（ACK＝120）。但前者在传送时丢失了。于是A超时重传（SEQ＝92，DATA共8字节），而B再次收到该报文段后，发送（ACK＝100）。这样，在这个报文段之前发送的就是（ACK＝120）。现在假设如果我们在客户端（客户端）浏览器中输入http://www.baidu.com,而 baidu.com 为要访问的服务器（服务器），下面详细分析客户端为了访问服务器而执行的一系列关于协议的操作：1）客户端浏览器通过DNS解析到www.baidu.com的IP地址220.181.27.48，通过这个IP地址找到客户端到服务器的路径。客户端浏览器发起一个HTTP会话到220.161.27.48，然后通过TCP进行封装数据包，输入到网络层。2）在客户端的传输层，把HTTP会话请求分成报文段，添加源和目的端口，如服务器使用80端口监听客户端的请求，客户端由系统随机选择一个端口如5000，与服务器进行交换，服务器把相应的请求返回给客户端的5000端口。然后使用IP层的IP地址查找目的端。3）达到IP层之后，主要做的是通过查找路由表确定如何到达服务器，期间可能经过多个路由器，这些都是由路由器来完成的工作，通过查找路由表决定通过那个路径到达服务器。4）客户端的链路层，包通过链路层发送到路由器，通过邻居协议查找给定IP地址的MAC地址，然后发送ARP请求查找目的地址，如果得到回应后就可以使用ARP的请求应答交换IP数据包，然后再根据路由表的路径再次交换，直到交换到目的地址的路由器之后，最终到达目的网络上的一个主机。这时双方就传输成功了。客户端发送IP数据包到达服务器的地址。IP地址由网络号（包括子网号）和主机号组成，网络地址的主机号为全0，网络地址代表着整个网络。比如：128.0.0.0广播地址与网络地址的主机号正好相反，广播地址中，主机号为全1。当向某个网络的广播地址发送消息时，该网络内的所有主机都能收到该广播消息。A类地址以0开头，第一个字节作为网络号，地址范围为：0.0.0.0~127.255.255.255；B类地址以10开头，前两个字节作为网络号，地址范围是：128.0.0.0~191.255.255.255;C类地址以110开头，前三个字节作为网络号，地址范围是：192.0.0.0~223.255.255.255。D类地址以1110开头，地址范围是224.0.0.0~239.255.255.255，D类地址作为组播地址（一对多的通信）；E类地址以1111开头，地址范围是240.0.0.0~255.255.255.255，E类地址为保留地址，供以后使用。注：只有A,B,C有网络号和主机号之分，D类地址和E类地址没有划分网络号和主机号。A、B、C类私有地址私有地址(private address)也叫专用地址，它们不会在全球使用，只具有本地意义。A类私有地址：10.0.0.0/8，范围是：10.0.0.0~10.255.255.255B类私有地址：172.16.0.0/12，范围是：172.16.0.0~172.31.255.255 C类私有地址：192.168.0.0/16，范围是：192.168.0.0~192.168.255.255