游戏设计
传输
可靠UDP的实现
资料学习
TCP为什么可靠
超时重传、流量控制和拥塞控制
TCP使用基于ACK的方式来处理分组丢失。如果每次只发送一个分组，等到ACK到达后再发送后续分组，这种简单的模式下依然存在着下面的问题。
- 要等待ACK多长时间？
- 分组或ACK丢失了怎么办？
由于网络传输是双向的，发送一个分组后等待ACK，会导致发送方向或接收方向的网络处于相对空闲的状态。为了提高效率，需要向网络中发送多个分组。虽然提升了效率，但也带来了更多的问题 - 一次发送多少个分组？
- 分组较多时，以什么样的时间间隔发送分组？
- 接收方如何知道哪些分组被接收到了，哪些还没有？
发送分组数和发送间隔，受接收方处理效率及网络通道处理效率的限制
超时重传
虽然可以选取过去一段时间分组的平均RTT来预测接下来一段时间分组的平均RTT，但由于平均值的局限性，会存在大量低于和高于平均值的RTT，高于平均值的RTT的分组将会被认为丢失，然而这些分组并没有丢失。所以超时时间应该高于平均RTT。
RTO：超时时间
RTT：发送后到接收到ACK的时间
没有发生超时时，RTO是根据RTT计算得来。发生超时后，为了防止重传二义性的问题，RTO=RTOx2，直到不发生超时，恢复之前的算法。
滑动窗口
滑动窗口协议解决了问题5。发送窗口中记录着哪些分组已经被确认接收、哪些分组发送了还未被确认接收以及哪些分组已经就绪但还未发送。接收窗口中记录着哪些分组已经被接收和确认，哪些分组将会被接收进而等待确认以及哪些分组无法被接收进而丢弃。
不过滑动窗口也带来了下面的问题 - 发送和接收窗口应该设置为多大
流量控制
使用窗口进行流量控制，窗口分为滑动窗口和拥塞窗口。
● 滑动窗口的大小（rwnd）表示接收方的缓存大小
● 拥塞窗口的大小（cwnd）表示发送后但未被确认的数据包大小
发送方发送窗口大小（橙色部分）为接受方接收窗口大小
发送方发送后未被确认的数据量（黑框中部分）
最终发送的数据量由发送窗口和拥塞窗口中较小的一方限制。
基于窗口的流量控制
为了处理接收方处理效率相对发送方低的问题，使用基于窗口的流量控制。接收方需要告知发送方其接收窗口的大小。这样发送方就可以根据接收方的窗口大小来调整发送窗口的大小。
基于拥塞控制的流量控制
为了处理网络通道之间所有中转设备和线路限制导致的问题，使用拥塞控制来解决。
TCP高延迟原因
TCP协议中规定了，发生超时时，RTO=RTOx2。超时时间的增长，导致数据包在真正丢失时，无法被及时的重传，超时时间越长，无法被及时重传的情况越严重。
TCP使用ARQ模型中此编号K前所有包已收到。当K+1发生了丢失时，虽然K+2可能已经收到，但发送端无法得知K+2和之后数据包的情况，只能全部重传，进而出现不必要的重发。TCP中的SACK？
SACK
https://www.rfc-editor.org/rfc/rfc2018
MTU为1500
MSS最大为1460
TCP额外包头最大为60字节。SACK需要消耗8*n+2字节的额外包头长度，所以理论最多描述4段block，不过由于时间戳消耗10字节的额外包头长度，所以实际为3段block。
UDP为什么不可靠
UDP如何可靠
涉及到功能的选择和切换
KCP协议
https://github.com/skywind3000/kcp
相关工具
丢包模拟