が、この論文の主な目的は、ネット試験の準備を数えることであるが、変更後に更新していきますと、UDP / TCPたちにネットワークの最も重要な部分とみなさコンピュータゲームプログラマーの基本、
私のメモを記録することが必要です。
UDP
ヘッダ構造
主な特長
- UDP（すなわち、データを送信する前に接続を確立せず）コネクションレスのトランスポート層プロトコルです。
- UDPは輻輳制御を使用していない一方で、信頼性の高い配信を保証しないベストエフォートを、使用しています。
- UDPはメッセージ指向です。UDPは輻輳制御をしない場合は、それはマルチメディア通信のために必要とされます。
- 1、多くの、および多対多の双方向コミュニケーションの1にUDPをサポート1。
- UDPヘッダオーバーヘッド小さい、わずか8バイト。
TCP
ヘッダ構造
主な特長
- TCPはコネクション型トランスポート層プロトコルである（即ち、データを送信する前に接続を確立する必要があります）。
- TCPは、信頼性の高いサービスの提供を提供します。
- TCPのバイトストリーム指向。
- TCPは、全二重通信を提供します。各TCP接続はのみ（一から一）ポイントツーポイントすることができます。
- TCPヘッダのオーバーヘッドは、比較的大きなポイントである20のバイトがあります。
TCPの信頼性を達成するために
ARQプロトコルを停止して待ちます
主な内容は、送信者がパケット受信側にデータパケットを送信し、確認パケットを受信した後、受信機の確認を待っている、それがパケットを送信し、このためにパケット受信側を確実にするため...に次のデータパケットを送信します。
しかし、パケットエラーを送信するには、次の2例が発生する場合があります。
- パケットロスを送信する処理。
- 伝送エラーの処理が発生したM1を受信した場合、Bは、次いで、パケットは廃棄され、誤った検出を行いました。
これらのエラー条件は、Bは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协议之上通过封装更高一层也可以获得可靠性，而且还能进一步分可靠性等级或者优先度等级：从而使重要的数据包优先发送/接受或者保证不会丢失，而让相对不重要的包则排最后处理和不提供防丢失保证。
- 待更