iOS面试题：TCP连接的三次握手

第一次握手：客户端发送 syn 包(syn=j)到服务器，并进入 SYN_SEND 状态，等待服务器确认；

第二次握手：服务器收到 syn 包，必须确认客户的 SYN（ack=j+1），同时自己也发送一个 SYN 包（syn=k），即 SYN+ACK 包，此时服务器进入 SYN_RECV 状态；

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入 ESTABLISHED 状态，完成三次握手。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP 连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开 TCP 连接的请求，断开过程需要经过“四次握手”（过程就不细写了，就是服务器和客户端交互，最终确定断开）

更多： iOS面试题合集

                    第一次握手：客户端向服务端发送 SYN 报文，服务端确认接收了 SYN 报文。

                    第二次握手：服务端在确认接收了 SYN 报文之后，会返回向客户端发送 SYN 报文和 ACK 确认报文。

                    第三次握手：客户端接收到 SYN 报文了 ACK 报文 之后双方就建立起了连接，可以好好玩耍了。

                    第一次挥手：客户端向服务端发送数据，发送完成之后会发送一个 FIN 报文，告诉服务端数据发送完毕。

                    第二次挥手：服务端接收到 FIN 报文之后，将 ACK 报文返回给客户端，告诉客户端（服务端）已经接收到数据。

                    第三次挥手：服务端处理完数据之后再发送一个 FIN 报文给客户端，告诉客户端（服务端）已经处理完毕。

                    第四次挥手：客户端接收到服务端发来的 FIN 报文之后就能确认这次的数据传输完成。可以关闭本次数据传输连接了。

  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~2 32 - 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报文多数情况下都是分开发送的 ，这也是为什么释放连接时需要交换四次报文了。

---