为什么联通访问电信服务器网速慢

三次握手后会在 各自内存空间 中形成一个 队列空间 ，并建立 socket 。
四次挥手目的是为了安全的销毁双方的连接释放内存，之前开辟的队列空间是为了对方服务的。

第一次握手：建立连接时，客户端发送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连接成功）状态，完成三次握手。

答：因为当 Server 端收到 Client 端的 SYN 连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

问题2为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

现在把三次握手改成仅需要两次握手，死锁是可能发生的 。作为例子，考虑计算机 S 和 C 之间的通信，假定 C 给 S 发送一个连接请求分组，S 收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S 认为连接已经成功地建立了，可以开始发送数据分组。可是，C 在 S 的应答分组在传输中被丢失的情况下，将不知道 S 是否已准备好，不知道 S 建立什么样的序列号，C 甚至怀疑 S 是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略 S 发来的任何数据分组，只等待连接确认应答分组。而 S 在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

问题4如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP 还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为 2 小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔 75 秒钟发送一次。若一连发送 10 个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

美国服务器速度变慢是什么原因导致的：
一：本地网络问题
如果我们在访问网站的时候突然发现很慢，很卡。我们首先要做的就是检查一下自身本地的网络环境是不是有问题。可以利用ping一下已知的知名域名，ping值出来之后，如果ping值很大，则可能是自己本地的网络环境有问题。反之ping值小，则是美国服务器出现问题了。
二：所在机房问题
网站加载速度过慢时，如果确认本地网络没有问题，还有可能是问题出现在美国服务器所在机房，机房的设备是完善的，但是也不能避免机房出现异常。当机房受到恶意攻击的时候，也会导致美国服务器变慢。另外也要检查一下机房的主干网络是否有异常。如果美国服务器托管了，那么我们可以联系机房的运维人员排查一下什么问题，推荐相关阅读：选择美国服务器应该注意哪些事项
三：运营商国际路由问题
当我们所使用的网络，运行商的路由或者提供的服务出现问题也会导致美国服务器变慢。特别是我们使用国外美国服务器的用户会经常遇到这类问题。当数据在传输的过程中，出现丢包或者无法连接路由时，用到这类网线的美国服务器速度就会很慢。这种情况并不是美国服务器本身出现问题，也不是本地网络出现问题，只需要等运营商修复网络即可。
四：资源不足和美国服务器中毒
我们要知道当美国服务器剩余空间不足时，会导致程序在运行的时候cpu或者内存过载，导致美国服务器速度变慢。遇到这类问题，我们可以尝试优化系统，关闭美国服务器上没必要运行的软件和程序。如果此类事件经常发生，那么我们就应该要升级美国服务器的整体配置了。另外，美国服务器如果遭受到恶意攻击也会导致美国服务器变慢。所以我们选择美国服务器的防火墙和所在机房的安全防护级别也是至关重要的。

WebSocket是HTML5开始提供的一种浏览器与服务器间进行全双工通讯的网络技术。在WebSocketAPI中，浏览器和服务器只需要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。

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

---