Computer network infrastructure notes transport layer protocol UDP / TCP

Although the main purpose of this paper is to count net exam preparation, but will continue to update after modification, and UDP / TCP to us the basics of computer game programmers regarded as the most important piece of the network,
so it is necessary to record my notes.

UDP

Header structure

main feature

• UDP is a connectionless transport-layer protocol (i.e., without establishing a connection before sending data).
• UDP uses a best effort delivery, that does not guarantee reliable delivery, while not using congestion control.
• UDP is a message-oriented. UDP does not congestion control, it is required for multimedia communication.
• UDP support one to one, one to many, and many-to-many interactive communication.
• UDP header overhead small, only 8 bytes.

TCP

Header structure

main feature

• TCP is a connection-oriented transport layer protocol (i.e., the need to establish a connection before sending data).
• TCP provides reliable service delivery.
• TCP byte stream oriented.
  
• TCP provides full-duplex communication. Each TCP connection can only point to point (one to one).
• TCP header overhead is relatively big point, there are 20 bytes.

TCP reliability to achieve

Stop and wait ARQ protocol

The main content is the sender send a data packet to the packet reception side, and wait for confirmation of the receiver, after receiving the confirmation packet, it sends the next data packet in order to ensure packet reception side in this order ... that sent the packet .

But sending a packet error may encounter the following two cases:

• A process of transmitting a packet loss.
• A process of transmission error occurred, B went wrong detection when receiving M1, then the packet is discarded.

These error conditions, B will not send any information to inform A.
A time-out but to set a timer, as long as over a period of time still have not received confirmation, I think just sent a packet is lost, so A will retransmit the packet just sent off, the so-called retransmission timeout.

Continuous ARQ sliding window protocol & protocol

The above stop and wait ARQ protocol using simple words, the channel utilization will be very low.

Continuous ARQ protocol refers to the sending packet transmitted by pipeline:
the sender may send a plurality of successive packets, each finished packet need not stopped to wait for confirmation. This can greatly increase the channel utilization.

滑动窗口协议是指发送方需要维持一个发送窗口，通常是结合来连续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主动连接为例）：

1. A向B发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x，表明传送数据时的第一个数据字节的序号是 x。
2. B收到连接请求报文段后，如同意，则发回确认。B在确认报文段中应使 SYN = 1，使 ACK = 1，其确认号 ack = x + 1,自己选择的序号 seq = y。
3. A收到此报文段后向 B 给出确认，其 ACK = 1，确认号 ack = y + 1。然后A的TCP通知上层应用进程，连接已经建立。
   
4. B收到A的确认后，也通知其上层应用进程：TCP连接已经建立。

连接释放：四次挥手

通信的双方都可主动释放连接。

以下是释放连接的四次挥手过程（以A主动释放为例）：

1. A先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。A把连接释放报文段首部的 FIN = 1，其序号 seq = u，等待B的确认。
2. B发出确认，确认号 ack = u+1，而这个报文段自己的序号 seq = v。从 A 到 B 这个方向的连接就释放了，TCP 连接处于半关闭状态。(但B若发送数据，A仍要接收。)
3. 若B已经没有要向A发送的数据，则也类似1步骤主动释放连接，发送连接释放包。
4. A收到连接释放报文段后，必须发出确认。在确认报文段中 ACK = 1，确认号 ack= w+ 1，自己的序号 seq = u + 1。TCP 连接必须经过时间 2MSL 后才真正释放掉。

结语

这里就顺便提一些关于我所知道有关网络多人游戏的经验：

• 网络多人游戏一般采用UDP协议，因为TCP协议额外占用带宽太大，不符合多人游戏对网络的带宽需求。
• 网络多人游戏在UDP协议之上通过封装更高一层也可以获得可靠性，而且还能进一步分可靠性等级或者优先度等级：从而使重要的数据包优先发送/接受或者保证不会丢失，而让相对不重要的包则排最后处理和不提供防丢失保证。
• 待更