目录
本文主要目的虽然是为了计网考试而准备的，但是之后会继续更新修改，而且UDP/TCP对我们游戏程序员算是计算机网络基础知识最重要的一块，
所以很有必要记录一下笔记。
UDP
首部结构
主要特点
- UDP 是无连接的运输层协议（即发送数据之前不需要建立连接）。
- UDP 使用尽最大努力交付，即不保证可靠交付，同时也不使用拥塞控制。
- UDP 是面向报文的。UDP 没有拥塞控制，很适合多媒体通信的要求。
- UDP 支持一对一、一对多、多对一和多对多的交互通信。
- UDP 的首部开销小，只有 8 个字节。
TCP
首部结构
主要特点
- TCP 是面向连接的运输层协议（即发送数据之前需要建立连接）。
- TCP 提供可靠交付的服务。
- TCP 面向字节流。
- TCP 提供全双工通信。每一条 TCP 连接只能是点对点的（一对一）。
- TCP 的首部开销相对大点，有 20 个字节。
TCP 可靠性实现
停止等待ARQ协议
主要内容就是发送方发一分组数据包给接收方，并等待接收方的确认，收到确认包后，继续按顺序发送下一分组数据包给接收方...以此保证发送数据包的顺序。
但是发送数据包可能遇到如下两种出错情况：
- A传送的过程中分组丢失了。
- A传送的过程中出现差错，B在接收M1时检测出了差错，于是丢弃包。
以上这些出错情况，B都不会发送任何信息来通知A。
而是让A设置一个超时计时器，只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，所以A会重传刚刚的发送过的分组，也就是所谓的超时重传。
连续ARQ协议&滑动窗口协议
上面简单使用停止等待ARQ协议的话，信道利用率会非常的低。
连续ARQ协议是指发送方采用流水线传输分组：
发送方可以连续发送多个分组，不必每发完一个分组就停下来等待对方确认。这样可以极大增大信道利用率。
滑动窗口协议是指发送方需要维持一个发送窗口，通常是结合来连续ARQ协议使用的：
位于发送窗口内的所有分组都可以连续发送出去，而不需要等待对方的确认， 发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
例如下图，当发送方收到第一个分组的确认，就把发送窗口向前移动一个分组的位置。如果原来已经发送了前5个分组，则现在可以发送窗口内的第6个分组。
接收方一般都是采用累积确认的方式：
也就是说接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认。如果发送方收到了这个分组确认信息，则表示到这个分组为止的所有分组都已经正确接收到了。
但累计确认的缺点是不能正确的向发送方反映出接收方已经正确收到的所以分组的信息。
例如发送方发送了前5个分组，而中间的第3个分组丢失了。这时候接收方只能对前2个发出确认，而不知道后面3个分组的下落，因此只能把后面的3个分组都重传一次。
拥塞控制
当主机开始发送数据时，因为还不清楚网络负荷的情况，如果立即把大量的数据字节注入网络，那么就有可能引起网络拥塞。
慢开始算法：由小到大的逐渐增大发送窗口，也就是说从小到大增大拥塞窗口数值。
在慢开始时，将这个拥塞设置为最大报文段MSS的数值，每收到一个对新的报文段的确认后，拥塞窗口的值就加1。如下图所示：
这里我们首先将拥塞窗口cwnd置为1，发送完一个报文段M1，而且收到接收方发来的确认时，将cwnd增大到2，然后发送M2，M3，再次接收到确认后，将cwnd增加到4。因此，每经过一个传输轮次，拥塞窗口就加倍。
拥塞避免算法：让cwnd缓慢得增大，即每经过一个RTT往返时间就把发送方的拥塞窗口cwnd加1，而不是加倍。这样，拥塞窗口cwnd按线性规律缓慢增长，比慢开始增长速率慢的多。
为了防止拥塞窗口增长过大引起网络阻塞，拥塞控制机制还设置了一个慢开始门限 ssthresh
- 当cwnd < ssthresh时，使用上述的慢开始算法
- 当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法
- 当cwnd = ssthresh时，既可以使用慢开始算法，也可使用拥塞避免算法。
无论在哪个阶段，只要发送方判断网络中出现拥塞(没有按时收到确认)，就要把慢开始门限ssthresh置为出现拥塞时发送窗口的一半，然后将cwnd置1，重新执行慢开始算法。
这样做就可以使发生拥塞的路由器把缓存中积压的分组处理完毕
举个例子，如图
1、在开始的时候将拥塞窗口置为1，慢开始门限的初始值ssthresh设置为16。
2、在执行慢开始算法时，拥塞窗口cwnd随着传输轮次按指数增长，超过慢开始门限值时（cwnd=16），开始执行拥塞避免算法，拥塞窗口按照线性规律增长。
3、假设拥塞窗口增长到24时，网路出现超时，很可能拥塞，所以慢开始门限值变为原来的一半（12），拥塞窗口置为1，并执行慢开始算法，当拥塞窗口再次达到门限值时，改为拥塞避免算法。
TCP 运输连接管理
TCP运输连接有三个阶段：连接建立，数据传送，连接释放。
TCP在连接建立过程中要解决三个问题：
- 双方都知道另一方的存在。
- 允许双方协商一些参数（最大窗口值、时间戳选项、服务质量等）。
- 能够对运输实体资源（缓存大小，连接表中的项目）进行分配。
连接建立：三次握手
以下是建立连接的三次握手过程（以A主动连接为例）：
- A向B发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x，表明传送数据时的第一个数据字节的序号是 x。
- B收到连接请求报文段后，如同意，则发回确认。B在确认报文段中应使 SYN = 1，使 ACK = 1，其确认号 ack = x + 1,自己选择的序号 seq = y。
- A收到此报文段后向 B 给出确认，其 ACK = 1，确认号 ack = y + 1。然后A的TCP通知上层应用进程，连接已经建立。
- B收到A的确认后，也通知其上层应用进程：TCP连接已经建立。
连接释放：四次挥手
通信的双方都可主动释放连接。
以下是释放连接的四次挥手过程（以A主动释放为例）：
- A先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。A把连接释放报文段首部的 FIN = 1，其序号 seq = u，等待B的确认。
- B发出确认，确认号 ack = u+1，而这个报文段自己的序号 seq = v。从 A 到 B 这个方向的连接就释放了，TCP 连接处于半关闭状态。(但B若发送数据，A仍要接收。)
- 若B已经没有要向A发送的数据，则也类似1步骤主动释放连接，发送连接释放包。
- A收到连接释放报文段后，必须发出确认。在确认报文段中 ACK = 1，确认号 ack= w+ 1，自己的序号 seq = u + 1。TCP 连接必须经过时间 2MSL 后才真正释放掉。
结语
这里就顺便提一些关于我所知道有关网络多人游戏的经验：
- 网络多人游戏一般采用UDP协议，因为TCP协议额外占用带宽太大，不符合多人游戏对网络的带宽需求。
- 网络多人游戏在UDP协议之上通过封装更高一层也可以获得可靠性，而且还能进一步分可靠性等级或者优先度等级：从而使重要的数据包优先发送/接受或者保证不会丢失，而让相对不重要的包则排最后处理和不提供防丢失保证。
- 待更