另外，继承自TCP拥塞控制的不公平的RTT也成为在分布式数据密集程序中的严重问题。拥有不同RTT的并发TCP流将不公平地分享带宽。尽管在小的BDP网络中使用通常的TCP实现来相对平等的共享带宽，但在拥有大量BDP的网络中，通常的基于TCP的程序就必须承受严重的不公平的问题。这个RTT基于的算法严重的限制了其在广域网分布式计算的效率，例如：internet上的网格计算。

一直到今天，对标准的TCP的提高一直都不能在高BDP环境中效率和公平性方面达到满意的程度（特别是基于RTT的问题）。例如：TCP的修改，RFC1423（高性能扩展），RFC2018（SACK）、RFC2582（New Reno）、RFC2883（D-SACK）、和RFC2988（RTO计算）都或多或少的提高了点效率，但最根本的AIMD算法没有解决。HS TCP（RFC 3649）通过根本上改变TCP拥塞控制算法来在高BDP网络中获得高带宽利用率，但公平性问题仍然存在。

考虑到上面的背景，需要一种在高BDP网络支持高性能数据传输的传输协议。我们推荐一个应用程序级别的传输协议，叫UDT或基于UDP的数据传输协议并拥有用塞控制算法。

本文描述两个正交的部分，UDP协议和UDT拥塞控制算法。一个应用层级别的协议，位于UDP之上，使用其他的拥塞算法，然而这些本文中描述的算法也可以在其他协议中实现，例如：TCP。

一个协议的参考实现叫[UDT]；详细的拥塞控制算法的性能分析在[GHG04]中可以找到。

2.   设计目标
UDT主要用在小数量的bulk源共享富裕带宽的情况下，最典型的例子就是建立在光纤广域网上的网格计算，一些研究所在这样的网络上运行他们的分布式的数据密集程序，例如，远程访问仪器、分布式数据挖掘和高分辨率的多媒体流。

UDT的主要目标是效率、公平、稳定。单个的或少量的UDT流应该利用所有高速连接提供的可用带宽，即使带宽变化的很剧烈。同时，所有并发的流必须公平地共享带宽，不依赖于不同的带宽瓶劲、起始时间、RTT。稳定性要求包发送速率应该一直会聚可用带宽非常快，并且必须避免拥塞碰撞。

UDT并不是在瓶劲带宽相对较小的和大量多元短文件流的情况下用来取代TCP的。

UDT主要作为TCP的朋友，和TCP并存，UDT分配的带宽不应该超过根据MAX-MIN规则的最大最小公平共享原则。（备注，最大最小规则允许UDT在高BDP连接下分配TCP不能使用的可用带宽）。我们

3.   协议说明
3.1. 概述
UDT是双工的，每个UDT实体有两个部分：发送和接收。发送者根据流量控制和速率控制来发送（和重传）应用程序数据。接收者接收数据包和控制包，并根据接收到的包发送控制包。发送和接收程序共享同一个UDP端口来发送和接收。

接收者也负责触发和处理所有的控制事件，包括拥塞控制和可靠性控制和他们的相对机制，例如RTT估计、带宽估计、应答和重传。

UDT总是试着将应用层数据打包成固定的大小，除非数据不够这么大。和TCP相似的是，这个固定的包大小叫做MSS（最大包大小）。由于期望UDT用来传输大块数据流，我们假定只有很小的一部分不规则的大小的包在UDT session中。MSS可以通过应用程序来安装，MTU是其最优值（包括所有包头）。

UDT拥塞控制算法将速率控制和窗口（流量控制）合并起来，前者调整包的发送周期，后者限制最大的位被应答的包。在速率控制中使用的参数通过带宽估计技术来更新，它继承来自基于接收的包方法。同时，速率控制周期是估计RTT的常量，流控制参数依赖于对方的数据到达速度，另外接收端释放的缓冲区的大小。

3.2. 包结构
UDT有两种包：数据包和控制包。他们通过包头的第一位来区分（标志位）。如果是0，表示是数据包，1表示是控制包。

3.2.1.    数据包

数据包结构如下显示：

0                      1                  3                       4

0  1  2 3 4  5  6  7 8  9 0  1  2  3  4 5  6 7  8  9  0 1  2  3  4 5  6 7  8  9 0  1

0
 包序号
 
应用数据
 

包序号是UDT数据包头中唯一的内容。它是一个无符号整数，使用标志位后的31位，UDT使用包基础的需要，例如，每个非重传的包都增加序号1。序号在到达最大值2^31-1的时候覆盖。紧跟在这些数据后面的是应用程序数据。

3.2.2.    控制包
控制包结构如下：

0                      1                  3                       4

0  1  2 3 4  5  6  7 8  9 0  1  2  3  4 5  6 7  8  9  0 1  2  3  4 5  6 7  8  9 0  1

1
 类型
 保留
 ACK序号
 
控制信息字段
 

有6种类型的控制包在UDT中，bit1-3表示这些信息。前32位在包头中必须存在。控制信息字段包括0（例如，它不存在）或者多个32位无符号整数，这由包类型决定。

UDT使用应答子序号的方法。每个ACK/ACK2包有一个无符号的16位序号，它独立于数据包需要。它使用位16-31。应答需要从0到（2^16-1）。位16-31在其他控制包中没有定义。

类型
 说明
 控制信息
 
000
 协议连接握手
 1．32位 UDT版本

2．32位 内部顺序号

3．32位 MSS（字节）

4．32位 最大流量窗口大小（字节）

 
001
 保活
 没有
 
010
 应答，位16-31是应答序号
 1．32位包序号，先前接收到的包序号

2．32位，RTT（微秒）

3．32位，RTT 变量或者RTTVar (微秒)

4．32位，流量窗口大小（包的数量）

5．32位，连接容量估计（每秒包的数量）
 
011
 Negative应答（NAK）
 丢失信息的32位整数数组，见3.9节
 
100
 保留
 这种类型的控制信息保留作为拥塞警告使用，从接收到发送端。一个拥塞警告能被ECN或包延迟增加趋势的度量方法触发。
 
101
 关闭
 
 

 
110
 应答一个应答（ACK2）
 16-31位，应答序号。
 
111
 4-15的解释
 保留将来使用
 

注意，对于数据和控制包来说，可以从UDP协议头中得到实际的包大小。包大小信息能被用来得到有效的数据负载和NAK包中的控制信息字段大小。

3.3. 定时器
UDT在接收端使用4个定时器来触发不同的周期事件，包括速率控制、应答、丢失报告（negative应答）和重传/连接维护。

UDT中的定时器使用系统时间作为源。UDT接收端主动查询系统时间来检查一个定时器是否过期。对于某个定时器T来说，其拥有周期TP，将定变量t用来记录最近T被设置或复位的时间。如果T在系统时间t0（t= t0）被复位，那么任何t1（t1-t>=TP）是T过期的条件。

四个定时器是：RC定时器、ACK定时器、NAK定时器、EXP定时器。他们的周期分别是：RCTP、ATP、NTP、ETP。

RC定时器用来触发周期性的速率控制。ACK定时器用来触发周期性的有选择的应答（应答包）。RCTP和ATP是常量值，值为：RCTP=ATP=0.01秒。

NAK被用来触发negative应答（NAK包）。重传定时器被用来触发一个数据包的重传和维护连接状态。他们周期依赖于对于RTT的估计。ETP值也依赖于连续EXP时间溢出的次数。推荐的RTT初始值是0.1秒，而NTP和ETP的初始值是：NTP=3*RTT，ETP=3*RTT+ATP。

在每次bounded UDP接收操作（如果收到一个UDP包，一些额外的必须的数据处理时间）时查询系统时间来检查四个定时器是否已经过期。推荐的周期粒度是微秒。UDP接收时间溢出值是实现的一个选择，这依赖于循环查询的负担和事件周期精确度之间的权衡。

速率控制事件更新包发送周期，UDT发送端使用STP来安排数据包的发送。假定一个在时间t0被发送，那么下一次包发送时间是（t0+ STP）。换句话说，如果前面的包发送花费了t’时间，发送端将等待（STP-t’）来发送下一个数据包（如果STP-t’ <0，就不需要等待了）。这个等待间隔需要一个高精确度的实现，推荐使用CPU时钟周期粒度。

3.4. 发送端算法
3.4.1.    数据结构和变量
A． SND PKT历史窗口：一个循环数组记录每个数据包的开始时间

B． 发送端丢失链表：发送段丢失列表是一个连接链表，用来存储被接收方NAK包中返回的丢失包序号。这些数字以增加的顺序存储。

3.4.2.    数据发送算法
A． 如果发送端的丢失链表是非空的，重传第一个在list中的包，并删除该成员，到5。

B． 等待有应用程序数据需要发送

C． 如果未应答的包数量超过了两量窗口的大小，转到1。如果不是包装一个新的包并发送它。

D．如果当前包的序号是16n，n是一个整数，转第2步。

E． 在SND PKT历史窗口中记录包的发送时间

F． 如果这是自上次发送速率降低之后的第一个包，等外SYN时间。

G．等外（STP – t）时间，t是第1到第4步之间的总时间，然后转到1。

3.5. 接收端算法
3.5.1.    数据结构和变量
A． 接收端丢失链表：是一个duple连接链表，元素的值包括：丢失数据包的序号、最近丢失包的反馈时间和包已经被反馈的次数。值以包序号增序的方式存储。

B． 应答历史窗口：每个发送ACK的和时间一个循环数组；由于其循环的特性，意味着如果数组中没有更多空间的时候新的值将覆盖老的值。

C． RCV PKT历史窗口：一个用来记录每个包到达时间的循环数组。

D．对包窗口：一个用来记录每个探测包对之间的时间间隔。

E． LRSN：一个用来记录最大接收数据包需要的变量。LRSN被初始化为初始序号减1。

3.5.2.    数据接收算法
A． 查询系统时间来检查RC、ACK、NAK、或EXP定时器是否过期。如果任一定时器过期，处理事件（本节下面介绍）并复位过期的定时器。

B． 启动一个时间bounded UDP接收。如果每个包到，转1。

C． 设置exp-count为1，并更新ETP为：ETP=RTT+4*RTTVar + ATP。

D．如果所有的发送数据包已经被应答，复位EXP时间变量。

E． 检查包头的标志位。如果是一个控制包，根据类型处理它，然后转1。

F． 如果当前数据包的需要是16n+1，n是一个整数，记录当前包和上个在对包窗口中数据包的时间间隔。

G．在PKT历史窗口中记录包到达时间

H． 如果当前数据包的序号大于LRSN+1，将所有在（但不包括）这两个值之间的序号放入接收丢失链表，并在一个NAK包中将这些序号发送给发送端。如果序号小于LRSN，从接收丢失链表中删除它。

I．   更新LRSN，转1。

3.5.3.    RC定时器到
通过速率控制算法来更新STP（见3.6节）。

过程如下：

A． 按照下面的原则查找接收端所接收到的所有包之前的序号：如果接收者丢失链表是空的，ACK号码是LRSN+1，否则是在接收丢失队列中的最小序号。

B． 如果应答号不大于曾经被ACK2应答的最大应答号，或等于上次应答的应答号并且两次应答之间的时间间隔小于RTT+4*RTTVar，停止（不发送应答）。

C． 分配这个应答一个唯一增加的ACK序列号，推荐采用ACK序列号按步骤1增加，并且重叠在达到最大值之后。

D．根据下面的算法来计算包的抵达速度：使用PKT历史窗口中的值计算最近16个包抵达间隔（AI）中值。在这16个值中，删除那些大于AI*8或小于AI*8的包，如果最后剩余8个值，计算他们的平均值(AI’)，包抵达速度是1/AI’（每秒包的数量），否则是0。

E． 根据3.7节中的内容为每端（W）计算流量窗口。然后计算有效的流量窗口大小为：最大（W，可用接收方缓冲大小），2）。

F． 根据下面的算法来计算连接容量估计。如果流量控制快启动阶段（3.7）一直继续，返回0，否则计算最近16个对包间隔（PI），这些值在对包窗口中，那么连接容量就是1/PI（每秒包的数量）。

G．打包应答序列号，应答号，RTT，RTT 变量，有效的流量窗口大小并估计连接，将他们放入ACK包中，然后发送出去。

H． 记录ACK序列号，应答号和这个应答的开始时间，并放入历史窗口中。

3.5.4.    处理NAK定时器到时
Ø       查找接受方的丢失链表，找到所有上次反馈时间是（k*（RTT+4*RTTVar ) ）前的包，k当前这个包的反馈次数加1，如果没有反馈丢失，停止。

Ø       压缩第一步中得到的序号（见3.9），然后在一个NAK包中发送他们到发送方。

Ø       如果不是停止流量控制快启动阶段。

3.5.5.    处理EXP定时器
A．   如果发送端的丢失链表不是空的，停止

B．   将所有未应答的包放到发送端的丢失链表中

C． 如果(exp-count>16)并且自上次从对方接收到一个包以来的总时间超过3秒，或者这个时间已经超过3分钟了，这被认为是连接已经断开，关闭UDT连接。

D．如果没有数据，也就没有应答，发送一个保活包给对端，否则将所有未应答包的序号放入发送丢失列表中。

E．   更新exp-count为：exp-count= exp-count+1

F．   更新ETP为：ETP=exp-count*（RTT+4*RTTVar）+ATP。

3.5.6.    收到应答包
A．   更新最大的应答序号

B． 更新RTT和RTTVar为：RTT = rtt， RTTVar = rv；rtt和rv是ACK包中的RTT和RTTVar值。

C．   更新NTP和ETP为：NTP=RTT+4*RTTVar；ETP=exp-count*（RTT+4*RTTVar）+ATP。

D．  更新连接容量估计：B=（B*7+b）/8，b是ACK包带的值。

E．   更新流量窗口大小为ACK中的值。

F．   发送ACK2包，并设置与ACK序号相同的应答号到对端

G．  复位EXP定时器

3.5.7.    当收到NAK包的时候
A． 将所有NAK包中带的序号放入发送方的丢失列表中

B． 通过速率控制来更新STP（见3.6）

C． 复位EXP定时器

3.5.8.    当收到ACK2包
Ø         在ACK历史窗口中根据接收到的ACK2序列号查找行营的ACK包。

Ø         更新曾经被应答的最大应答号

Ø       根据ACK2的到达时间和ACK离开时间计算新的rtt值，并且更新RTT和RTTVar值为：

RTTVar = (RTTVar *3 +abs(rtt-RTT)/4

RTT = (RTT *7+rtt)/8

RTT和RTTVar的初始值是0.1秒和0.05秒。

Ø       更新NTP和ETP为：

NTP = RTT；

ETP = (exp-count +1)* RTT+ATP

3.5.9.    当收到保活包的时候
什么也不做

3.5.10.             当收到连接握手和关闭包的时候
见3.8节

3.6. 速度控制算法
3.6.1.    速率控制快启动
STP被初始为最小的时间精度（1个CPU周期或1毫秒）。这是在快启动阶段，一般收到一个ACK包其携带的估计带宽大于0这个阶段就停止了。包的发送周期被设置为1/W，W是ACK携带的流量窗口的大小。

快启动阶段仅仅在开始一个UDT连接的时候发生，且不会在UDT连接的以后再出现。在快启动阶段之后，下面的算法就要工作了。

3.6.2.    当RC定时器时间到
1．  如果在上一个RCTP时间内，没有收到一个ACK，停止

2．  计算在上个RCTP时间内的丢失率，计算方法是根据总共发送的包与NAK反馈中总共丢失包的数量。如果丢失率大于0.1%，停止。

3．  下个RCTP时间内发送包的增加数量如下计算：(inc)

If (B<=C) inc = 1/MSS

Else inc = max (10^(ceil(log10((B-C)*MSS*8)))*Beta/MSS,1/MSS)

B是连接容量估计，C是当前的发送速度。两个都计算为每秒多少个包。MSS是以字节计算的；Beta是值为0.0000015的常量。

4．  更新STP：STP=（STP*RCTP）/（STP*inc + RCTP）

5．  计算真正的数据发送周期（rsp），从SND PKT历史窗口中得到，如果（STP<0.5 *rsp）设置STP为（0.5 * rsp）。

6．  如果（STP<1.0），设置STP为1.0。

3.6.3.    当收到NAK包时
3.6.3.1.          数据结构和变量
1．  LSD：自上次速率降低后发送的最大序号

2．  NumNAK：自上次LSD更新以后的NAK数量

3．  AvgNAK：当最大序号大于LSD时两次事件之间的NAK移动的平均数。

4．  DR：在1到AvgNAK之间的随机平均数。

3.6.3.2.          算法
1．  如果NAK中最大的丢失序列号大于LSD：

增加STP为：STP=STP*（1+1/8）

更新AvgNAK为：AvgNAK = （AvgNAK *7 +NumNAK）/8

更新DR

复位 NumNAK = 0

记录LSD

2．  否则，增加NumNAK按照1个步骤增加；如果NumNAK % DR = 0；增加STP为：STP=STP*（1+1/8）；记录LSD。

3.7. 流量控制算法
流量控制窗口大小（W）初始值是16。

3.7.1.    当ACK定时器到的时候
1．  流量控制快启动：如果没有NAK产生或者W没有到达或超过15个包，并且AS>0，流量窗口大小更新为应答包的总数量。

2．  否则，如果（AS>0），W更新为：（AS是包的到达速度）

W= ceil (W *0.875+AS* (RTT +ATP) *0.125)

3．  限制W到对方最大流量窗口大小。

3.8. 连接建立和关闭
一个UDT实体首先作为一个SERVER启动，当一个客户端需要连接的时候其发送握手包。客户端在从服务端接收到一个握手响应包或时间溢出之前，应该每隔一段时间发送一个握手包（时间间隔由响应时间和系统overhead来权衡）。

握手包有如下信息：

1．  UDT版本：这个值是兼容的目的。当前的版本是2

2．  初始序号：这是发送这个UDT实体将来用于发送数据包的起始序号。它必须是一个在1到（2^31-1）之间的随机值。另外，建议这个值在合理的时间历史窗口中不应该重复。

3．  MSS：数据包的大小（通过IP有效负载来度量）

4．  最大的流量窗口大小：这是接收到握手信息的UDT实体允许的最大流量窗口大小，窗口大小通常限制为接收端的数据结构大小。

服务器接收到一个握手包之后，比较MSS值和他自己的值并设置它自己的值为较小的值。结果值也在握手响应中被发送到客户端，另外还有服务器的版本信息，初始序列号，最大流量窗口大小。

版本字段用来检查两端的兼容性。初始序列号和最大流量窗口大小用于初始化接收到这个握手包的UDT实体参数。

服务器在第一步完成以后就准备发送或接收数据。然而，只要从同一个客户端接收任何握手包，其应该发送响应包。

客户端一旦得到服务器的一个握手响应其就进入发送和接收数据状态。设置它自己的MSS为握手响应包中的值并初始化相应的参数为包中的值（序列号、最大流量窗口）。如果收到任何其他的握手信息，丢掉它。

如果其中的UDT实体要关闭，它将发送一个关闭信息到对端；对方收到这个信息以后将自己关闭。这个关闭信息通过UDP传输，仅仅发送一次，并不保证一定收到。如果消息没有收到，对方将根据时间溢出机制来关闭连接。

3.9. 丢失信息的压缩方案
NAK包中携带的丢失信息是一个32-bit整数的数组。如果数组的中数字是一个正常的序号（第1位是0），这意味着这个序号的包丢失了，如果第1位是1，意味着从这个号码开始（包括该号码）到下一个数组中的元素（包括这个元素值）之间的包（它的第1位必须是0）都丢失。

例如，下面的NAK中携带的信息：

0x00000002, 0x80000006, 0x0000000B, 0x0000000E

上面的信息表明序号为：2，6，7，8，9，10，11，14的包都丢了。

4.   效率和公平性
UDT能够充分利用当前有线网络的独立于连接容量的可用带宽 、RTT、后台共存流、给定的连接比特错误率。UDT在没有数据包丢失的情况下从0bits/s到90%带宽需要一个常量时间，这个时间是7.5秒。UDT并不适合无线网络。

UDT的确满足单瓶劲网络拓扑的最大-最小公平性。在多个瓶劲情况下，根据最大最小原则它能保证较小瓶劲连接或者至少一半的平等共享(it guarantees that flows over smaller bottleneck links obtain at least half of their fair share according to max-min rule)。RTT对公平性都一点影响。

当和大块的TCP流共存的时候，TCP能占用比UDT更多的带宽，除了三种情况：

1．      网络BDP非常大，TCP不能利用他们的公平共享带宽。这种情况下，UDT将占用TCP不能利用的带宽。

2．      连接容量是如此的小，从而导致UDT的带宽估计技术不能最有的工作；模拟显示这个极限连接容量大约是100kb/s。

3．      在使用FIFO队列作为网络路径的网络中，如果队列大小大于BDP，TCP的共享带宽随着队列大小的增加而降低。然而，抵达UDT的共享带宽是，队列大小通常超过实际路由器/交换机提供的数量。

当短（timewise）类似web的TCP流和小的并发UDT流共存的时候，UDT在TCP流上的效果非常小。

更多的分析在[GHG03]。

5.   安全考虑
UDT并没有使用特定的安全机制，相反，它依赖于应用程序提供的授权和底层提供的安全机制。

然而，由于UDP是无连接的，UDT实现应该检查所有达到的包是否是预期的来源。这是从socket的API连接概念中继承而来，其连接只是接收指定来源的数据。

6.UDT SOURCE CODE LINK
      http://sourceforge.net/projects/dataspace

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/windcsn/archive/2006/01/04/570242.aspx

 2.1.3 最大传输报文大小（MSS）
 TCP报文段在连接建立时需要通报MSS，在TDP的实现中也进行通报，默认通报为1460字节（符合以太网标准，这个默认值允许20字节的IP首部、8字节的UDP首部和12字节的TDP首部，以适合 1500字节的IP数据报）默认值可以由用户程序设置。
 TCP在对端地址为非本地IP时，默认通报为536字节。TDP之所以默认通报为1460，是因为TDP在数据传输过程中，实现了路径MTU发现技术，通过实际发现的MTU，进行MSS的动态调整，以尽量避免报文段在网络中的传输产生分片的情况。路径MTU发现技术在传输数据流一节中进行描述。
 
 2.1.4 半打开连接及连接保活
 半打开连接是指对端异常关闭，如网线拔掉、突然断电等情况将引发一端导演关闭，而另一端的连接却仍然认为连接处于打开当中，这种情况称之为半打开连接。TDP中的一个TDP SOCKET描述符由本地IP、本地端口、远端IP、远端端口唯一确定。当远端客户端连接请求到来时，服务端将接收到一个新的TDP SOCKET描述符，当这一个描述符唯一确定信息已经存在时，对新的连接请求发送RST报文段，通知其重置连接请求。对于旧的连接，由保活机制自动发现是否为半打开连接，如果是半打开连接，则自动关闭该连接。这里RST报文段与TCP中的RST报文段有些不一样，TCP的RST报文段工作描述请参考《TCP/IP详解 卷一》。
 连接建立之后，TDP连接需要启动保活机制。TCP连接在没有数据通信的情况下也能保持连接，但TDP连接不行。TDP连接在一定时间段内如果没有数据交互的话，将主动发送保活LIV报文段。这个时间段根据TDP连接工作模块不同有所差异，在NAT UDP PUNCH模式下，这个时间段默认值为1分钟（大多数的NAT中，UDP会话超时时间为2－5分钟左右）；而在常规模块下这个时间段默认值为5分钟。默认值可以由用户程序设置，用户程序需要指明两种模块下的保活时间周期。这里TDP的保活机制与TCP中的保活机制完全不一样，TCP的保活机制描述请参考《TCP/IP详解 卷一》。
 
 2.2连接关闭
 
 TDP连接与TCP连接一样是全双工的，因此每个方向必须单独地进行关闭。客户机给服务器一个FIN报文段，然后服务器返回给客户端一个确认ACK报文，并且发送一个FIN报文段，当客户机回复ACK报文后（四次握手），连接就结束了。
 TDP连接的一端接收到FIN报文段时，如果还有数据要发送，需要继续将数据进行发送完成，然后才发出FIN报文段；如果还有数据未从缓存中取出，将取出数据，并进行确认，直到所有确认完成之后，然后才发出FIN报文段（此时如果有乱序的报文段情况不进行处理）。上面的描述也表现出，TDP是支持半关闭的，当一端发出FIN报文段时，仍然允许接收另一端数据。但是半关闭可能导致连接永远停留在状态图中FIN_WAIT_2状态中，此时保活机制仍然在工作当中，如果对端已经关闭，那么保活机制将在检测到时立即关闭这一连接。
 
 下图是一个典型的连接建立与连接关闭的示意图，此图摘自《TCP/IP详解 卷一》。
 
 
 
四、TDP传输数据流
 
 1．传输的报文段
 
 在TDP工作过程中传输的所有报文段，只有SYN报文段、FIN报文段、数据报文段是可靠的之外，其它报文段如ACK报文段、LIV报文段、RST报文段等都不是可靠的。SYN报文段与FIN报文段传输中都占用一个序号，数据报文段在传输中根据传输的数据字节数占用相应的序号，其它报文段不占用传输序号。
 成功接收数据报文段，应当将按序对下一个期望的数据报文段的序号作为确认序号发送ACK报文段进行确认。当出现接收到乱序的数据报文段时，将乱序数据报文段按序缓存，并发送期望报文段的ACK报文段进行确认。ACK报文段的发送并非即时的，也并非是对应接收数据报进行一对一确认发送。ACK报文段由200ms定时触发发送，也就是说ACK报文段要经受最多200ms的时延进行发送。ACK报文段对此时期望的数据序号进行确认，因此并不是与接收数据报相对应。ACK报文段是不可靠的，当丢失时对端将无法了解接收情况，因此发送方将会有一个超时机制，如果发现确认的ACK报文段超时，发送方将重发该数据报，这一点在第五节进行详细描述。
 
 2．路径MTU发现及MSS通告
 
 前面已经提到要在连接建立过程中会通告初始MSS，这个值可以由用户程序进行设置。但这个初始值是一个静态的。当通信的两个端点之间跨越多个网络时，使用设置的MSS进行报文段发送时，可能导致传输的IP报文分片情况的产生。为了避免分片情况的产生，TDP在数据传输过程中进行动态的路径MTU发现，并进行MSS的更新及通告。
 TDP创建UDP SOCKET时，即将描述符设置IP选项为不允许进行分片（setsockopt (clientSock, IPPROTO_IP, IP_DONTFRAGMENT,(char*)&dwFlags, sizeof(dwFlags))）。在发送数据时以当前MSS大小值进行数据发送，如果返回值为错误码WSAEMSGSIZE（10040）表示为报文段尽寸大于MTU，需要进行IP分片传输。此时，缩减MSS大小再次进行报文段发送，直至不再返回错误码WSAEMSGSIZE（10040）。当MSS变更并能成功发送报文段后，需要向对端通报新的MSS值。每次MSS缩小后，默认隔30秒，TDP将默认扩大MSS大小，以检查是否路径MTU增大了（默认值可以由用户程序设置），之后隔30*2秒、30*2*2秒进行检测，如果三次都未发现MTU增大则停止进行检测。见RFC1191描述，网络中MTU值的个数是有限的，如下图描述（摘自RFC1191）。因此MSS的扩大及缩减，可依据一些由近似值按序构成的表，依照此表索引进行MSS值的扩大与缩减计算。
 
 TDP中MSS与MTU之间关系的计算公式如下：
 MSS = MTU – 20(IP首部) – 8(UDP首部) – 12(TDP首部)。
 
 3．Nagle算法
 
 有些人误认为经受时延的捎带ACK发送是Nagle算法，其实不是。经受时延的捎带ACK发送是TCP的通常实现，在TDP中也是如此。而Nagle算法是要求一个TCP（TDP也是如此）连接上最多只能有一个未被确认的未完成的报文段，在该报文段的确认到达之前不能发送其他的报文段。相反，TCP（TDP也是如此）在这个时候收集这些报文段，关在确认到来时合并作为一个报文段发送出去。Nagle算法对于处理应用程序产生大量小报文段的情况，有利于避免网络中由于发送太多的包而过载（这便是发送端的糊涂窗口综合症，关于糊涂窗口综合症在下文将做更详细描述）。
 Nagle算法适用于产生大量小报文段的情况，但有时我们需要关闭Nagle算法。一个典型的例子是X窗口系统服务器：小消息（鼠标移动）必须无时延地发送，以便为进行某种操作的交互用户提供实时的反馈。
 默认的TDP实现中Nagle算法是关闭的，用户程序可以设置打开它。
 
 4．窗口大小通告与滑动窗口
 
 双方接收模块需要依据各自的缓冲区大小，相互通告还能接受对方数据的尺寸。双方发送模块则必须根据对方通告的接收窗口大小，进行数据发送。这种机制称之谓滑动窗口，它是TDP接收方的流量控制方法。它允许发送方在停止并等待确认前可以连续发送多个分组（依据滑动窗口的大小），由于发送方不必每发一个分组就停下来等待确认，因此可以加速数据的传输。
 参照《TCP/IP详解 卷一 20.3滑动窗口》一节，滑动窗口在排序数据流上不时的向右移动，窗口两个边沿的相对运动增加或减少了窗口的大小，关于窗口边沿的运动有三个术语：窗口合拢（当左边沿向右边沿靠近）、窗口张开（当右边沿向右移动）、窗口收缩（当右边沿向左移动）。RFC文档强烈建议不要在实现当中出现窗口收缩的情况出现，在我们的实现中也将不会出现。
 当遇到快的发送方与慢的接收方的情况时，接收方的窗口会很快被发送方的数据填满，此时接收方将通告窗口大小为0,发送方则停止发送数据。直到接收方用户程序取走数据后更新窗口大小，发送方可以继续发送数据；另外，因为ACK报文段有可能丢失，发送方可能没有成功接收到更新的窗口大小，因此发送方将启动一个坚持定时器，当坚持定时器超时，发送方将发送一个字节的数据到接收方，尝试检查窗口大小的更新。
 在Nagle算法中接到过糊涂窗口综合症，在这里要进一步进行描述。糊涂窗口综合症是指众多少量数据的报文段将通过连接进行交换，而不是满长度的报文段，这将导致连接占用过多带宽，降低传输速率。糊涂窗口综合症产生是分两端的，接收方可以通告一个小的窗口（而不是一直等到有大的窗口时才通告），发送方也可以发送少量的数据（而不是等待其他的数据以便发送一个大的报文段）。要以采用如下方法避免这一现象：
 1）接收方不通告小窗口。通常的算法是接收方不通告一个比当前窗口大的窗口（可以为0），除非窗口可以增加一个报文段大小(也就是将要接收的MSS)或者可以增加缓存空间的一半，不论实际有多少。
 2）发送方避免出现糊涂窗口综合症的措施是只有以下条件之一满足时才发送数据：(a)可以发送一个满长度的报文段；(b)可以发送至少是接收方通告窗口大小一半的报文段；(c)可以发送任何数据并且不希望接收ACK（也就是说，我们没有还未被确认的数据）或者该连接上不能使用Nagle算法。
 
 5．PUSH标志
 
 PSUH标志的作用是发送方使用PUSH标志通知接收方将所收到的数据全部提交给接收进程。在TDP实现中，用户程序并不需要关心PUSH标志。因为TDP实现从不将接收到的数据推迟交付给用户程序，因此这个标志在TDP的实现中是被忽略的。
 
五、TDP超时与重传
 
 1．带宽时延乘积与拥塞
 
 每个网络通道都有一定的容量，可以计算通道的容量大小：
 Capacity(bit) = bandwidth(b/s) * round-trip time(s)
 这个值一般称之为带宽时延乘积。这个值依赖于网络速度和两端的RTT，可以有很大的变动。不论是带宽还是时延均会影响发送方与接收方之间通路的容量。
 当数据到达一个大的网络通道并向一个小的网络通道发送，将发生拥塞现象。另外当多个输入流到达一个路由器，而路由器的输出流小于这些输入流的总和时也会发生拥塞。TDP超时与重传机制刚采用TCP的拥塞控制算法来进行发送端的流量控制。
 
 2．往返时间与重传超时时间测量
 
 超时与重传中最重要的部分就是对一个给定连接的往返时间（RTT）的测量。由于路由器和网络流量均会发生变化，因此一般认为RTT可能经常会发生变化，TDP应该跟踪这些变化并相应地改变相应的超时时间。
 首先是必须测量在发送一个带有特别序号的字节和接收到包含字节的确认之间的RTT。由于数据报文段与ACK之间通常没有一一对应的关系，如下图（摘自《TCP/IP详解 卷一》图20.1）中，这意味着发送方可以测量到的一个RTT，是在发送报文段4和接收报文段7之间的时间，用M表示所测量到的RTT。
 根据[Jacobson 1988]描述（见《TCP/IP详解 卷一》参考文献），用A表示被平滑的RTT（均值估计器），用D表示被平滑的均值偏差，用Err表示刚得到的测量结果M与当前RTT估计器之差，则可以计算下一个超时重传时间（用RTO表示下一个超时重传时间）。
 A = 0 （未进行测量往返时间之前，A的初始值）
 D = 3 （未进行测量往返时间之前，D的初始值）
 RTO = A + 2D = 6 （未进行测量往返时间之前，RTO的初始值）
 A = M + 0.5 (第一次测量到往返时间结果，对RTT估计器计算初始值)
 D = A / 2 （第一次测量到往返时间结果，对均值偏差D计算初始值）
 RTO = A + 4D （第一次测量到往返时间结果，对均值偏差RTO计算初始值）
 之后的计算方法如下：
 Err = M – A
 A <- A + gErr
 D <- D + h(|Err| - D)
 RTO = A + 4D
 其中g是常量增量，取值为1/8(0.125)；h也是常量增量，取值为1/4(0.25)。
 
 
 
 Karn算法：Karn算法是解决所谓的重传多义性问题的。[Karn and Partridge 1987]规定（见《TCP/IP详解 卷一》参考文献），当一个超时和重传发生时，在重传数据的确认最后到达之前，不能更新RTT估计器，因为我们并不知道ACK对应哪次传输（也许第一次传输被延迟而并没有被丢弃，也有可能是第一次传输的ACK被延迟丢弃）。并且，由于数据被重传，RTO已经得到了一个指数退避，我们在下一次传输时使用这个退避后的RTO。对一个没有被重传的报文段而言，除非收到了一个确认，否则不要计算新的RTO。
 在任何时候对每个连接并行仅测量一次RTT值，在发送一个报文段时，如果给定连接的定时器已经被使用，则该报文段不被计时，反之如果给定连接的定时器未被使用，则开始计时以测量RTT值。即并非每个发出报文段都进行测量RTT值，同一时间段里只能有一个RTT值测量行为进行，不会并行进行多个RTT值测量。
 
 3．慢启动
 
 如果发送方一开始便向网络发送多个报文段，直至达到接收方通告窗口大小为止。当发送方与接收方在同一局域网时，这种方式是可以的。但如果在发送方与接收方之间存在多个路由器和速率较慢的链路时，就可能出现问题。一些中间路由器必须缓存分组，并有可能耗尽存储器的空间，将来得降低TCP连接的吞吐量。于是需要一种叫“慢启动”的拥塞控制算法。
 慢启动为发送方增加一个拥塞窗口，记为cwnd，当与另一个网络的主机建立连接时，拥塞窗口被初始化为1个报文段。每收到一个ACK，拥塞窗口就增加一个报文段（cwnd以字节为单位，但慢启动以报文段大小为单位进行增加）。发送方取拥塞窗口与通告窗口中的最小值作为发送上限。拥塞窗口是发送方使用的流量控制，而通告窗口是接收方使用的流量控制。
 发送方开始时发送一个报文段，然后等待ACK。当收到该ACK时，拥塞窗口从1增加到2,即可以发送两个报文段。当收到这两个报文段的ACK时，拥塞窗口就增加为4。这是一种指数增加的关系。
 
 4．拥塞避免
 
 慢启动算法增加拥塞窗口大小到某些点上可能达到了互联网的容量，于是中间路由器开始丢弃分组。这就通知发送方它的拥塞窗口开得太大。拥塞避免算法是一种处理丢失分组的方法。该算法假定由于分组受到损坏引起的丢失是非常少的（远小于1％），因此分组丢失就意味着在源主机和目标主机之间的某处网络上发生了拥塞。有两种分组丢失的指示：发生超时和接收到重复的确认。拥塞避免算法与慢启动算法是两个独立的算法，但实际中这两个算法通常在一起实现。
 拥塞避免算法和慢启动算法需要对每个连接维持两个变量：一个拥塞窗口cwnd和一个慢启动门限ssthresh。算法的工作过程如下：
 1) 对一个给定的连接，初始化cwnd为1个报文段，ssthresh为65535个字节。
 2) TCP输出例程的输出不能超过cwnd和接收方通告窗口的大小。拥塞避免是发送方使用的流量控制，而通告窗口则是接收方进行的流量控制。前者是发送方感受到的网络拥塞的估计，而后者则与接收方在该连接上的可用缓存大小有关。
 3) 当拥塞发生时（超时或收到重复确认），ssthresh被设置为当前窗口大小的一半（cwnd和接收方通告窗口大小的最小值，但最少为2个报文段）。此外，如果是超时引起了拥塞，则cwnd被设置为1个报文段（这就是慢启动）。
 4) 当新的数据被对方确认时，就增加cwnd，但增加的方法依赖于我们是否正在进行慢启动或拥塞避免。如果cwnd小于或等于ssthresh，则正在进行慢启动，否则正在进行拥塞避免。慢启动一直持续到我们回到当拥塞发生时所处位置的半时候才停止（因为我们记录了在步骤2中给我们制造麻烦的窗口大小的一半），然后转为执行拥塞避免。
 慢启动算法初始设置cwnd为1个报文段，此后每收到一个确认就加1。这会使窗口按指数方式增长：发送1个报文段，然后是2个，接着是4个……。拥塞避免算法要求每次收到一个确认时将cwnd增加1/cwnd。与慢启动的指数增加比起来，这是一种加性增长。我们希望在一个往返时间内最多为cwnd增加1个报文段（不管在这个RT T中收到了多少个ACK），然而慢启动将根据这个往返时间中所收到的确认的个数增加cwnd。
 处于拥塞避免状态时，拥塞窗口的计算公式如下（引公式参照BSD的实现，segsize/8的值是一个匹配补充量，不在算法描述当中）：
 cwnd <- cwnd + segsize * segsize / cwnd + segsize / 8
 
 5．快速重传与快速恢复
 
 由于我们不知道一个重复的ACK是由一个丢失的报文段引起的，还是由于仅仅出现了几个报文段的重新排序，因此我们等待少量重复的ACK到来。假如这只是一些报文段的重新排序，则在重新排序的报文段被处理并产生一个新的ACK之前，只可能产生1 ~ 2个重复的ACK。如果一连串收到3个或3个以上的重复ACK，就非常可能是一个报文段丢失了。于是我们就重传丢失的数据报文段，而无需等待超时定时器溢出。这就是快速重传算法。接下来执行的不是慢启动算法而是拥塞避免算法。这就是快速恢复算法。
 这个算法通常按如下过程进行实现：
 1) 当收到第3个重复的ACK时，将ssthresh设置为当前拥塞窗口cwnd的一半。重传丢失的报文段。设置cwnd为ssthresh加上3倍的报文段大小。
 2) 每次收到另一个重复的ACK时，cwnd增加1个报文段大小并发送1个分组（如果新的cwnd允许发送）。
 3) 当下一个确认新数据的ACK到达时，设置cwnd为ssthresh（在第1步中设置的值）。这个ACK应该是在进行重传后的一个往返时间内对步骤1中重传的确认。另外，这个ACK也应该是对丢失的分组和收到的第1个重复的A C K之间的所有中间报文段的确认。这一步采用的是拥塞避免，因为当分组丢失时我们将当前的速率减半。
 
六、代理socks5支持
 
 参照RFC1928、RFC1929，在TDP实现中，支持匿名通过socks5代理以及用户名/密码验证方式通过socks5代理。
 由于socks5代理是工作于运输层上，因此连接当中对IP层选项的设置都将没有效果。socks5代理起到的作用只是应用数据的转发，但这已经基本上能支持大部分用户程序的应用需求。在使用socks5代理进行工作中，路径MTU的发现机制，将无法有效工作，此时MSS默认为536（MTU默认为576）,用户程序可以修改使用的MSS值。
 
七、安全考虑
 
 TDP协议及算法方面并不对数据的安全性做任何考虑，用户程序在传输数据时如果对安全性有要求，可以自行在应用数据层做相应的工作。但TDP实现中，会提供一个简单的AES256位加解密方法，提供给用户程序使用。用户程序可以调用该加解密方法，对数据进行加密然后再通过网络进行发送，接收时将加密数据流进行解密再将会用户程序数据逻辑处理模块进行处理。
 
八、定时器
 
 如BSD的TCP实现类似，TDP也为每条连接建立了六个定时器，简要介绍如下：
 1）“连接建立”定时器，在发送SYN报文段建立一条新的连接时启动。如果没有在75秒内收到响应，连接建立将中止。
 2）“重传”定时器，在发送数据时设定。如果定时器已超时而对端的确认还未到达，将重传数据。重传定时器的值是动态计算的，取决来RTT与该报文段被重传的次数。
 3）“延迟ACK”定时器，收到必须确认但无需马上发出确认的数据时设定。等待200ms后发送确认响应。如果，在这200ms内，有数据要在该连接上发送，延迟的ACK响应就可随数据一起发送回对端，称为捎带确认。
 4）“坚持”定时器，在连接对端通告接收窗口为0,阻止继续发送数据时设定。坚持定时器在超时后向对端发送1字节的数据，判定对端接收窗口是否已经打开。坚持定时器的值是动态的计算的，取决于RTT值，在5秒与60秒之间取值。
 5）“保活”定时器。TDP连接在一定时间段内如果没有数据交互的话，将主动发送保活LIV报文段。即当“保活”定时器超时，说明没有数据交互，则发送保活数据包。保活定时器默认时间为2分钟，用户程序可以进行设置。
 6）TIME_WAIT定时器,也可称为2MSL定时器（实现中，一个MSL为1分钟）。当连接状态转移到TIME_WAIT时，即连接主动关闭时，定时器启动。
 
九、开发接口
 
 使用TDP进行网络程序开发是非常容易的，它的开发接口（API）与socket API是非常相似的，尤其是对应功能的函数名称都是一致的，需要注意的是TDP的所有API都处于名称空间TDP之下。开发接口见下表：
 
函数 描述 
TDP::accept 接受一个链接 
TDP::bind 绑定本地地址到一个TDP::SOCKET句柄 
TDP::cleanup 清除TDP全局资源，一个进程中只需要调用一次 
TDP::close 关闭已打开的TDP::SOCKET句柄，并关闭连接 
TDP::connect 连接到服务器端 
TDP::getlasterror 获得TDP最后的一个错误 
TDP::getpeername 读取连接的对端的地址信息 
TDP::getsockname 读取连接的本地的地址信息 
TDP::getsockopt 读取TDP的选项信息 
TDP::listen 等待客户端来连接 
TDP::recv 接收数据 
TDP::select 等待集合中的TDP SOCKET改变状态 
TDP::send 发送数据 
TDP::setsockopt 修改TDP的选项信息 
TDP::shutdown 指定关闭连接上双工通信的部分或全部 
TDP::socket 创建一个TDP SOCKET 
TDP::startup 初始化TDP全局信息，一个进程中只需要调用一次 
 

刚接触TCP/IP通信设计的人根据范例可以很快编出一个通信程
序，据此一些人可能会认为TCP/IP编程很简单。其实不然，
TCP/IP编程具有较为丰富的内容。其编程的丰富性主要体现在
通信方式和报文格式的多样性上。

一。通信方式

主要有以下三大类:

(一)SERVER/CLIENT方式

1.一个Client方连接一个Server方，或称点对点(peer to peer)：
2.多个Client方连接一个Server方，这也是通常的并发服务器方式。
3.一个Client方连接多个Server方，这种方式很少见，主要
用于一个客户向多个服务器发送请求情况。

(二)连接方式

1.长连接

Client方与Server方先建立通讯连接，连接建立后不断开，
然后再进行报文发送和接收。这种方式下由于通讯连接一直
存在，可以用下面命令查看连接是否建立：

netstat –f inet|grep 端口号(如5678)。

此种方式常用于点对点通讯。

2.短连接

Client方与Server每进行一次报文收发交易时才进行通讯连
接，交易完毕后立即断开连接。此种方式常用于一点对多点
通讯，比如多个Client连接一个Server.

(三)发送接收方式

1.异步

报文发送和接收是分开的，相互独立的，互不影响。这种方
式又分两种情况：

(1)异步双工：接收和发送在同一个程序中，有两个不同的
子进程分别负责发送和接收
(2)异步单工：接收和发送是用两个不同的程序来完成。

2.同步

报文发送和接收是同步进行，既报文发送后等待接收返回报文。
同步方式一般需要考虑超时问题，即报文发上去后不能无限等
待，需要设定超时时间，超过该时间发送方不再等待读返回报
文，直接通知超时返回。 

实际通信方式是这三类通信方式的组合。比如一般书上提供的
TCP/IP范例程序大都是同步短连接的SERVER/CLIENT程序。有的
组合是基本不用的，比较常用的有价值的组合是以下几种：

同步短连接Server/Client
同步长连接Server/Client
异步短连接Server/Client
异步长连接双工Server/Client
异步长连接单工Server/Client

其中异步长连接双工是最为复杂的一种通信方式，有时候经
常会出现在不同银行或不同城市之间的两套系统之间的通信。
比如金卡工程。由于这几种通信方式比较固定，所以可以预
先编制这几种通信方式的模板程序。

二.报文格式

通信报文格式多样性更多，相应地就必须设计对应的读写报文的接
收和发送报文函数。

(一)阻塞与非阻塞方式　

1.非阻塞方式

读函数不停地进行读动作，如果没有报文接收到，等待一段时间后
超时返回，这种情况一般需要指定超时时间。

2.阻塞方式

如果没有报文接收到，则读函数一直处于等待状态，直到有报文到达。

(二)循环读写方式
 

1.一次直接读写报文

在一次接收或发送报文动作中一次性不加分别地全部读取或全部
发送报文字节。

2.不指定长度循环读写

这一般发生在短连接进程中，受网络路由等限制，一次较长的报
文可能在网络传输过程中被分解成了好几个包。一次读取可能不
能全部读完一次报文，这就需要循环读报文，直到读完为止。

3.带长度报文头循环读写

这种情况一般是在长连接进程中，由于在长连接中没有条件能够
判断循环读写什么时候结束，所以必须要加长度报文头。读函数
先是读取报文头的长度，再根据这个长度去读报文.实际情况中，
报头的码制格式还经常不一样，如果是非ASCII码的报文头，还必须
转换成ASCII,常见的报文头码制有：
(1)n个字节的ASCII码
(2)n个字节的BCD码
(3)n个字节的网络整型码

以上是几种比较典型的读写报文方式，可以与通信方式模板一起
预先提供一些典型的API读写函数。当然在实际问题中，可能还
必须编写与对方报文格式配套的读写API.

在实际情况中，往往需要把我们自己的系统与别人的系统进行连接，
有了以上模板与API,可以说连接任何方式的通信程序都不存在问题。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wgl_suc102/archive/2008/01/23/2060828.aspx

　　常见的网络服务器，基本上是7*24小时运转的，对于网游来说，至少要求服务器要能连续工作一周以上的时间并保证不出现服务器崩溃这样的灾难性事件。事实上，要求一个服务器在连续的满负荷运转下不出任何异常，要求它设计的近乎完美，这几乎是不太现实的。服务器本身可以出异常（但要尽可能少得出），但是，服务器本身应该被设计得足以健壮，“小病小灾”打不垮它，这就要求服务器在异常处理方面要下很多功夫。

　　服务器的异常处理包括的内容非常广泛，本文仅就在网络封包方面出现的异常作一讨论，希望能对正从事相关工作的朋友有所帮助。

　　关于网络封包方面的异常，总体来说，可以分为两大类：一是封包格式出现异常；二是封包内容（即封包数据）出现异常。在封包格式的异常处理方面，我们在最底端的网络数据包接收模块便可以加以处理。而对于封包数据内容出现的异常，只有依靠游戏本身的逻辑去加以判定和检验。游戏逻辑方面的异常处理，是随每个游戏的不同而不同的，所以，本文随后的内容将重点阐述在网络数据包接收模块中的异常处理。

　　为方便以下的讨论，先明确两个概念（这两个概念是为了叙述方面，笔者自行取的，并无标准可言）：
　　1、逻辑包：指的是在应用层提交的数据包，一个完整的逻辑包可以表示一个确切的逻辑意义。比如登录包，它里面就可以含有用户名字段和密码字段。尽管它看上去也是一段缓冲区数据，但这个缓冲区里的各个区间是代表一定的逻辑意义的。
　　2、物理包：指的是使用recv(recvfrom)或wsarecv(wsarecvfrom)从网络底层接收到的数据包，这样收到的一个数据包，能不能表示一个完整的逻辑意义，要取决于它是通过UDP类的“数据报协议”发的包还是通过TCP类的“流协议”发的包。

　　我们知道，TCP是流协议，“流协议”与“数据报协议”的不同点在于：“数据报协议”中的一个网络包本身就是一个完整的逻辑包，也就是说，在应用层使用sendto发送了一个逻辑包之后，在接收端通过recvfrom接收到的就是刚才使用sendto发送的那个逻辑包，这个包不会被分开发送，也不会与其它的包放在一起发送。但对于TCP而言，TCP会根据网络状况和neagle算法，或者将一个逻辑包单独发送，或者将一个逻辑包分成若干次发送，或者会将若干个逻辑包合在一起发送出去。正因为TCP在逻辑包处理方面的这种粘合性，要求我们在作基于TCP的应用时，一般都要编写相应的拼包、解包代码。

　　因此，基于TCP的上层应用，一般都要定义自己的包格式。TCP的封包定义中，除了具体的数据内容所代表的逻辑意义之外，第一步就是要确定以何种方式表示当前包的开始和结束。通常情况下，表示一个TCP逻辑包的开始和结束有两种方式：
　　1、以特殊的开始和结束标志表示，比如FF00表示开始，00FF表示结束。
　　2、直接以包长度来表示。比如可以用第一个字节表示包总长度，如果觉得这样的话包比较小，也可以用两个字节表示包长度。

　　下面将要给出的代码是以第2种方式定义的数据包，包长度以每个封包的前两个字节表示。我将结合着代码给出相关的解释和说明。

　　函数中用到的变量说明：

　　CLIENT_BUFFER_SIZE：缓冲区的长度，定义为：Const int CLIENT_BUFFER_SIZE=4096。
　　m_ClientDataBuf：数据整理缓冲区，每次收到的数据，都会先被复制到这个缓冲区的末尾，然后由下面的整理函数对这个缓冲区进行整理。它的定义是：char m_ClientDataBuf[2* CLIENT_BUFFER_SIZE]。
　　m_DataBufByteCount：数据整理缓冲区中当前剩余的未整理字节数。
　　GetPacketLen(const char*)：函数，可以根据传入的缓冲区首址按照应用层协议取出当前逻辑包的长度。
　　GetGamePacket(const char*, int)：函数，可以根据传入的缓冲区生成相应的游戏逻辑数据包。
　　AddToExeList(PBaseGamePacket)：函数，将指定的游戏逻辑数据包加入待处理的游戏逻辑数据包队列中，等待逻辑处理线程对其进行处理。
　　DATA_POS：指的是除了包长度、包类型等这些标志型字段之外，真正的数据包内容的起始位置。

Bool SplitFun(const char* pData,const int &len)
{
    PBaseGamePacket pGamePacket=NULL;
    __int64 startPos=0, prePos=0, i=0;
    int packetLen=0;

 　//先将本次收到的数据复制到整理缓冲区尾部
    startPos = m_DataBufByteCount; 
    memcpy( m_ClientDataBuf+startPos, pData, len );
    m_DataBufByteCount += len;   

    //当整理缓冲区内的字节数少于DATA_POS字节时，取不到长度信息则退出
　//注意：退出时并不置m_DataBufByteCount为0
    if (m_DataBufByteCount < DATA_POS+1)
        return false;

    //根据正常逻辑，下面的情况不可能出现，为稳妥起见，还是加上
    if (m_DataBufByteCount >  2*CLIENT_BUFFER_SIZE)
    {
        //设置m_DataBufByteCount为0，意味着丢弃缓冲区中的现有数据
        m_DataBufByteCount = 0;

　　//可以考虑开放错误格式数据包的处理接口，处理逻辑交给上层
　　//OnPacketError()
        return false;
    }

     //还原起始指针
     startPos = 0;

     //只有当m_ClientDataBuf中的字节个数大于最小包长度时才能执行此语句
    packetLen = GetPacketLen( pIOCPClient->m_ClientDataBuf );

    //当逻辑层的包长度不合法时，则直接丢弃该包
    if ((packetLen < DATA_POS+1) || (packetLen > 2*CLIENT_BUFFER_SIZE))
    {
        m_DataBufByteCount = 0;

　　//OnPacketError()
        return false;
    }

    //保留整理缓冲区的末尾指针
    __int64 oldlen = m_DataBufByteCount;

    while ((packetLen <= m_DataBufByteCount) && (m_DataBufByteCount>0))
    {
        //调用拼包逻辑，获取该缓冲区数据对应的数据包
        pGamePacket = GetGamePacket(m_ClientDataBuf+startPos, packetLen);

        if (pGamePacket!=NULL)
        {
            //将数据包加入执行队列
            AddToExeList(pGamePacket);
        }

        pGamePacket = NULL;
 
　　//整理缓冲区的剩余字节数和新逻辑包的起始位置进行调整
        m_DataBufByteCount -= packetLen;
        startPos += packetLen;

        //残留缓冲区的字节数少于一个正常包大小时，只向前复制该包随后退出
        if (m_DataBufByteCount < DATA_POS+1)
        {
            for(i=startPos; i<startPos+m_DataBufByteCount; ++i)
                m_ClientDataBuf[i-startPos] = m_ClientDataBuf[i];

            return true;
        }

        packetLen = GetPacketLen(m_ClientDataBuf + startPos );

         //当逻辑层的包长度不合法时，丢弃该包及缓冲区以后的包
        if ((packetLen<DATA_POS+1) || (packetLen>2*CLIENT_BUFFER_SIZE))
        {
            m_DataBufByteCount = 0;

    　　//OnPacketError()
            return false;
        }

         if (startPos+packetLen>=oldlen)
        {
            for(i=startPos; i<startPos+m_DataBufByteCount; ++i)
                m_ClientDataBuf[i-startPos] = m_ClientDataBuf[i];          

            return true;
        }
     }//取所有完整的包

     return true;
}

　　以上便是数据接收模块的处理函数，下面是几点简要说明：

　　1、用于拼包整理的缓冲区(m_ClientDataBuf)应该比recv中指定的接收缓冲区(pData)长度(CLIENT_BUFFER_SIZE)要大，通常前者是后者的2倍(2*CLIENT_BUFFER_SIZE)或更大。

　　2、为避免因为剩余数据前移而导致的额外开销，建议m_ClientDataBuf使用环形缓冲区实现。

　　3、为了避免出现无法拼装的包，我们约定每次发送的逻辑包，其单个逻辑包最大长度不可以超过CLIENT_BUFFER_SIZE的2倍。因为我们的整理缓冲区只有2*CLIENT_BUFFER_SIZE这么长，更长的数据，我们将无法整理。这就要求在协议的设计上以及最终的发送函数的处理上要加上这样的异常处理机制。

　　4、对于数据包过短或过长的包，我们通常的情况是置m_DataBufByteCount为0，即舍弃当前包的处理。如果此处不设置m_DataBufByteCount为0也可，但该客户端只要发了一次格式错误的包，则其后继发过来的包则也将连带着产生格式错误，如果设置m_DataBufByteCount为0，则可以比较好的避免后继的包受此包的格式错误影响。更好的作法是，在此处开放一个封包格式异常的处理接口(OnPacketError)，由上层逻辑决定对这种异常如何处置。比如上层逻辑可以对封包格式方面出现的异常进行计数，如果错误的次数超过一定的值，则可以断开该客户端的连接。

　　5、建议不要在recv或wsarecv的函数后，就紧接着作以上的处理。当recv收到一段数据后，生成一个结构体或对象(它主要含有data和len两个内容，前者是数据缓冲区，后者是数据长度)，将这样的一个结构体或对象放到一个队列中由后面的线程对其使用SplitFun函数进行整理。这样，可以最大限度地提高网络数据的接收速度，不至因为数据整理的原因而在此处浪费时间。

　　代码中，我已经作了比较详细的注释，可以作为拼包函数的参考，代码是从偶的应用中提取、修改而来，本身只为演示之用，所以未作调试，应用时需要你自己去完善。如有疑问，可以我的blog上留言提出。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/clever101/archive/2008/10/12/3061679.aspx

• 1 client 1 server, connected with non-block tcp socket. Linux 2.6.*+.
• Client 写入大概 3k 数据到 socket。
• Write()正确返回实际写入字节数。
• Server 什么也收不到。

Causes:

• 发送端 MTU稍大于路由器上的MTU设置
• 通知发送端需要拆包的ICMP在某处被杀掉了
• 发送端不停的重发包

设置了DF标志的ip包当遇到路由器的MTU比包小的时候，不会被路由器拆包。而路由器发送icmp消息到发送端，通知它应该拆包。

但icmp消息被防火墙拦截下来。

环境和现象：
这个例子中，MTU在client和server都是1500.

dump出来的包如下:

客户端看到的:
发送了2个包，后1个包成功，第1个过大而不停的被发送:

17:23:06.933574 IP (tos 0×0, ttl 64, id 57558, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.54.40.43.43145 > 10.29.14.74.http: ., cksum 0×5096 (incorrect (-> 0×5c4e), 0:1448(1448) ack 1 win 46

17:23:06.933580 IP (tos 0×0, ttl 64, id 57559, offset 0, flags [DF], proto: TCP (6), length: 730) 10.54.40.43.43145 > 10.29.14.74.http: P, cksum 0×4d94 (incorrect (-> 0×3933), 1448:2126(678) ack 1 win 46

17:23:07.167049 IP (tos 0×0, ttl 64, id 57560, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.54.40.43.43145 > 10.29.14.74.http: ., cksum 0×5096 (incorrect (-> 0×5b5b), 0:1448(1448) ack 1 win 46

17:23:07.634922 IP (tos 0×0, ttl 64, id 57561, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.54.40.43.43145 > 10.29.14.74.http: ., cksum 0×5096 (incorrect (-> 0×5987), 0:1448(1448) ack 1 win 46

接受端看到的:
只有730大小的包接受成功

17:23:08.605622 IP (tos 0×0, ttl 59, id 57559, offset 0, flags [DF], proto: TCP (6), length: 730) 202.108.3.204.43145 > 10.29.14.74.http: P, cksum 0×9d5b (correct), 1448:2126(678) ack 1 win 46

解决方法:
调整发送端机器的配置:（任选1个）

在网络层上:
Decrease mtu on network adapter:

ifconfig eth* mtu 1400

操作系统配置:
Clear the default ‘MTU discovery’ flag with sysctl:

net.ipv4.ip_no_pmtu_disc = 1

或在应用程序里:
Set socket option ‘IP_MTU_DISCOVER’ with setsockopt(2) to clear ‘DF’ flag of IP package.

Reference:

1. DF flag of IP package Header
   
2. Internet Control Message Protocol
3. IP fragmentation
4. MTU or Maximum transmission unit
5. IP programming
6. Path MTU Discovery
7. sysctl

Thanks：

esx kobe steve

来自：http://blog.developers.api.sina.com.cn/?p=672
原文：http://drdr-xp-tech.blogspot.com/2009/04/black-hole-socket-problem.html

现在来讨论上次提到的并发FIFO,其实现需要一些特殊的技巧。我上次说要实现单线程读单线程写的FIFO,但是这里我们先来讨论一般的并发FIFO。

我们知道,传统的生产者——消费者问题,通常是使用一个共享的缓冲区来交换数据的,生产者和消费者各自有对应的指针,在生产或者消费的时候相应地移动。如果达到了缓冲区的边界则回绕。如果生产者指针追上消费者指针,则表明缓冲区满了;如果消费者指针追上生产者指针,则表明缓冲区空了。问题在于,为了防止在缓冲区满的时候插入数据,或者在缓冲区空的时候删除数据,生产者或者消费者的每一次插入或者删除数据操作,都必须同时访问这两个指针,这就带来了不必要的同步。

在单核处理器上,共享缓冲区方式非常高效,并且具有固定的空间开销(有时候你需要保守地估计一个比较大的数值)。但是在多核处理器上(或者SMP系统中),如果要实现并发的FIFO,就必须摒弃这种方式。使用单链表而不是共享缓冲区就可以避开这个问题,这是第一个技巧。

第二个技巧关系到链表的使用方向。一般使用链表,其插入或者删除节点的位置是任意的。但是把链表作为FIFO使用,则只能也只需要在两端操作。需要注意的是这时候必须从尾部TAIL插入新的节点,而从头部HEAD删除节点。否则从尾部删除节点之后,无从得知新的尾部在哪里,除非从头部遍历。这样做的好处是,插入或者删除都只涉及到一个节点。插入的时候,只要让新创建的节点包含所需要插入的数据,并且其后继(下一个节点)为NULL;再让当前尾部的节点的后继从NULL变成这个新节点,这个新节点也就变成了新的尾部节点(这里的操作顺序很关键)。删除的时候,则检查当前头部节点的后继NEXT是否NULL。若是,表明FIFO是空的;否则,取NEXT所包含的数据来使用(是的,是NEXT而不是当前头部节点所包含的数据,参看下一个技巧和不变式),并把该数据从NEXT中删除,而NEXT也成为新的头部节点。(没有配图,各位请自己想象一下)

最后一个技巧:为了隔离对头部和尾部的访问,我们需要一个空节点N(不包含数据的有效节点),其下一个节点为NULL;并且引入HEAD和TAIL。在开始的时候,HEAD和TAIL都等于N。插入和删除数据的过程上面已经讲过了,这里讲一下不变式。

第一个不变式:头部节点总是空的(不包含数据)。在FIFO初始化的时候这是成立的。之后的插入操作不改变头部节点,因此对不变式没有影响。而对于删除操作,则每一个新头部节点的数据都已经在它成为新的头部节点的时候被删除(取用)了。

第二个不变式:插入和删除操作没有数据冲突,也就是说,插入线程和删除线程不会同时读写同一项数据(不是节点)。我们只需要考虑FIFO为空,即相当于刚刚完成初始化之后的情况。对于空节点N,插入操作改变其后继,删除操作则检查其后继。只要插入线程保证先让新节点包含数据再把新节点插入链表(也就是不能先插入空节点,再往节点中填入数据),那么删除线程就不会拿到空的节点。我们看到,唯一可能发生争用的地方就是N的后继指针,插入线程只要在更新N的后继指针之前准备好其它相关数据和设置即可。

这意味着,如果能够做到:1)一个线程对数据的更新能够被另外一个线程即刻看到;2)对数据的读或者写(更新和读取N的后继指针)都是原子的;3)指令没有被乱序执行。那么在单线程读单线程写的情况下,甚至不需要使用锁就可以安全地完成并发FIFO;如果有多个生产者线程,则增加一个生产者锁;如果有多个消费者线程,则可以增加一个消费者锁。也就是说,可以有四种组合。

但是实际情况远非如此。对于2)是容易满足的,因为现代通用处理器上32位数据的读或者写通常都是原子的。对于1),则取决于系统的内存模型:在强内存模型如C/C++中是满足的,在弱内存模型如Java中则不然。但是主要的问题还在于3)。由于指令的乱序执行,第二个不变式所需要的保证很可能被破坏,即使代码确实是那样写的。因此锁是必不可少的,因为加锁的同时还会插入内存屏障。

这样看来,上次说的SRSW并发FIFO就没有特别的意义了。干脆就用两个锁分别对应生产者和消费者,而并不限制生产者或者消费者的数量:T_LOCK和H_LOCK。在插入新建节点到链表尾部的时候使用T_LOCK,而在对头部操作的时候使用H_LOCK。


具体的代码这里先不给了。这里的算法不是我发明的,而是来自Maged M. Michael 和 Michael L. Scott的Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms。请参考其双锁算法的伪码。

现在来讨论游戏消息的传送。在一个网游的运营成本中,带宽费用应该是很大的一块。因此如何高效编码以及收发消息就成为节省运营成本的关键。这里面能做很多文章。

首先是一个基本的判断:随着处理器的计算能力不断提高,以及多核的日益普及,在消息的编码以及收发环节,CPU资源将不会成为瓶颈。相对的,应该千方百计考虑如何在保证游戏正常运行的前提下,降低不必要的通信开销。也就是说,可以对游戏中的消息进行一些比较复杂的编码。

那么游戏中都有哪些消息?我们知道聊天和语音消息优先级比较低,而且可以通过专门的服务器来处理。真正比较关键、能够影响玩家的游戏体验的,是那些状态变更、动作、玩家之间或者玩家和服务器/NPC之间的实时交互的消息。尤其是,这些消息的传送有严格的时序要求。如果一个玩家先看到自己的角色被砍死,然后才看到对方发出来的攻击动作,甚至根本没有看到对方有什么动作,他/她肯定会愤愤不平。因此,消息系统必须保证每一条消息的及时传递,并且不能打乱它们之间的顺序。

这意味着,每一条消息必须有明确的边界。也就是说,收到一条消息之后,接收方必须能够明确这条消息有多少个字节。这是一条显而易见的要求。但是大概是出于惯性,在实践中它常常变为消息编码中的长度字段。

这无疑是一种浪费。很多消息的长度是固定的,仅仅靠检查其消息类型就可以了解其边界。变长消息的处理后面会讨论。我这里并不是说要把具体的游戏逻辑与网络代码混在一起。通过使用元数据就可以有效的把网络代码跟具体的游戏逻辑有效隔离开来。关于元数据的使用后面也会详加探讨。今天时间不多了,下面讨论消息类型的编码作为结束。

通常一个字节会被用来编码消息的类型,以方便接收方的解码。但是我们知道,游戏中并不是每种类型的消息的传送频率都是一样的。事实上,我们知道哪些消息会被大量发送,哪些消息的频率会低很多,而另外一些消息,一天也不会有几条。明乎此,就可以采用非对称的编码方式来编码消息的类型。这就是Huffman编码。对于占据了绝大部分通信量的状态变更消息而言,即使每条消息节省下半个字节,也是非常划算的。以我的经验,一台普通PC可以作为服务器支持2000人同时在线的实时动作类游戏,消息通量是每秒10000条;如果一个服务集群有5台处理器,那么就相当于节省了200kbps的带宽。这还仅仅是从消息类型编码方面榨取的。当然,Huffman编码的解码是比较麻烦的,效率也会低一些。但是正如前面所指出的,这部分的运行开销并不会造成性能瓶颈。