[游戏开发][网络篇]TCP、UDP相关

TCP三次握手和四次挥手的全过程

三次握手：

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

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

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

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

---

四次握手

与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次握手”。

第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可 以接受数据。

第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。
第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

下面讲一下发送数据和接受数据

看上图中间的数据传输，由于建立连接时已经确定从0开始的seq(sequence序列号)，每次发包时都要保证seq+1，这样做的好处时，由于网络链路的不确定性，包可能会乱序（重要知识，要考哦！！！），当接收端发现包乱序后，会把乱序包丢入一个缓存池，当前面的包都到达并且排好序后再塞入内核接收池。

当接收端收到数据包后，会向发送端回一个带有ACK报文的确认包，发送端收到ACK包后确认， 对方收到了。因此才会向后滑动数据窗口，继续发送后面的数据包。接收端发送ACK报文确认是实现TCP可靠传输的关键所在。

假设接收端发回的ACK确认报文丢失了怎么办，这不要紧。发送端本身就有计时器，当计时结束还未收到对面的ACK确认，不管接收端有没有收到该包，发送端都认为该包已丢失，重新发送且重置计时器。直到该包收到了接收端的回复确认，这个叫丢包重传机制。

【TCP滑动窗口动画】，看看滑动窗口收发大概的样子，下面有个自己模拟的网站

Selective Repeat / Go Back Nhttps://www2.tkn.tu-berlin.de/teaching/rn/animations/gbn_sr/总结一句话：丢包后滑动窗口会滑动到丢包的位置，等待时间结束后会再次发包，重新进入等待，依次循环，直到收到确认包为止，滑动窗口才会向后滑动。

拥塞控制机制（流量控制)

 TCP开始发包时会根据拥塞算法，试探性的发少量包，然后依次增加发包量，直到开始出现丢包。这样就可以知道当前的网络环境以及合适的吞吐量。

知道了当前的网络环境是好是坏，才能最大限度的保证减少丢包重传，因为丢包重传是额外消耗性能的。

TCP大包分段机制

把大的数据包拆分成小包来发送， 避免大包丢失，导致重传损耗。

小段长度的上限在传输层叫MSS(maximum segment size)，当包体长度大于MSS时会拆分成多个MSS包，如果包体到了网络层还大于MTU(maximum transmit unit) 还会继续分包，一般情况下，MSS=MTU - 40个byte，从网络层到了IP层

何时会出现UDP比TCP慢的情况

一般来说TCP是不可能比UDP快的，但是有一种特殊情况，就是发送大数据包，且网络环境极差，出现频繁丢包的时候。 由于TCP有分段机制，能保证在恶劣条件下最大限度的让对方收到数据，但是UDP是没有分段机制的，一旦发生丢包就要全部重发。当然，如果UDP也自己写一套分段机制的话，那样就和UDP不分伯仲了。

---

面试经常提问的

问题1：TCP的三次握手过程？为什么会采用三次握手，若采用二次握手可以吗？

答：建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。

（1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。

（2）采用三次握手不是两次的原因是：为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。

详细解释：TCP的三次握手最主要是防止已过期的连接再次传到被连接的主机。
如果采用两次的话，会出现下面这种情况。
比如是A机要连到B机，结果发送的连接信息由于某种原因没有到达B机；
于是，A机又发了一次，结果这次B收到了，于是就发信息回来，两机就连接。
传完东西后，断开。
结果这时候，原先没有到达的连接信息突然又传到了B机，于是B机发信息给A，然后B机就以为和A连上了，这个时候B机就在等待A传东西过去。陷入了无尽的等待，当然这时候心跳包就显得很有必要，没有心跳超时后断开。

（3）采用两次握手不行，原因就是上面说的实效的连接请求的特殊情况。

问题2：解释一下四次挥手过程，为什么是四次挥手，三次不行吗？

当然不行，假设A发起断开，B收到A的断开请求后，会立刻回复一个ACK确认，表示收到你的请求。

此时A肯定是没有数据要发送了，但是B的发送缓存池里可能不是空的，因此A还要等B发送一个FIN码报文表示我也发完了，当A收到B的FIN报文后，给B回复一个ACK报文，表示我知道你发送完了，我已经断开了。

四次挥手做到了，AB都知道对方要断开，且双方都发送完毕。那么可以放心的断开了。其中少了任何一个环节，都可能早上上面所说的，有一方不知道某个信息。

 问题3：TCP丢包是如何处理的

  这个问题可能要展开来说，因为TCP的收发是底层完成的，而不是咱们程序员负责，如果面试官问这个问题，大概率是想问你TCP的收发流程。那么就要聊到滑动窗口了。还是回到上文中的发送与接收部分，和面试官说一下流程以及计时重传机制。

【基础部分】

TCP、UDP如何选择

1. UDP:用户数据报协议:主要用在实时性要求比较高的以及对质量相对较弱的地方.但是面对现在高质量的线路不会容易丢包,除非是一些拥塞条件下,如流媒体
2. TCP:传输控制协议:是面连接的那么运行环境必然要求其可靠性不可丢包,有良好的拥塞控制机制如 http ftp等

同步和异步，阻塞与非阻塞

同步：代码执行IO操作时，必须等待IO操作返回的

异步：代码执行IO操作时，不等待IO操作返回的

对于客户端来说，Socket的IO操作都是同步的（read、write、receive、send），这些调用都是直接调用协议栈里的数据

阻塞和非阻塞：阻塞就是调用该函数时，它当前所在的线程或进程直接挂起，处于死机状态，直到有返回才恢复正常。非阻塞就是调用该函数时先返回，等有结果了再通知我。

举两个例子解释阻塞和非阻塞，有两对情侣，A男B女和C男D女

舔狗型：AB吵架后，A联系B说别生气，我去你楼下咱俩见面听我解释，B正处于气头上，就不下楼，A到了B的楼下，发现B没下来，结果就是A只能在楼下死等，他也不敢走。

机智型：CD吵架后，C联系D说别生气，我去你楼下咱俩见面听我解释，D正处于气头上，就是不下楼，当C走到D的楼下时，发现D没下来，C扭头就走，然后每过一段时间就过来看看D下来没。

结论：A死等B的方式，就是阻塞，啥也干不了。C轮询检查D下没下来就是非阻塞，该干啥干啥。
 

首先异步的行为是增加吞吐量。并不能节省结果的处理时间。阻塞和非阻塞是在线程层面说的。现实中的async和await是在实现一个概念层面的异步模型。其实现逻辑是要靠线程去实现。

【进阶部分】

用UDP实现TCP或者实现可靠连接发送数据

大前提：客户端和服务器自定义包头编号这是必须的

方案1：

        情况1：假设客户端只负责表现服务器的编号数据流，且包编号无需连续，则收到啥就表现啥。

        情况 2：假设客户端要求编号必须连续。当客户端收到的编号不连续时，通知服务器我当前收到的编号不连续了，客户端需要通知服务器我从XX编号开始丢了。服务器接到丢失通知后有两种处理方式，第一是服务器从缺失的部分开始重新连续发送包，第二种时服务器只发缺失的包，客户端自己往里面插，第二种方式需要客户端做一些处理。这种情况需要有包编号和包体大小，由于后面的包已经在缓存里了，我们需要去查找截断并插入。

方案2：

        每个包发三遍，绝对稳妥，如果包还是丢了。那就断线吧。。。

转一个网络知识点总结的帖子，网络知识点总结_will的猜想的博客-CSDN博客_计算机网络知识点总结