端口号

端口号可以分为三个范围：“已知端口”、“注册端口”以及“动态和/或专用端口”。

• “已知端口”是从 0 到 1023 的端口。
• “注册端口”是从 1024 到 49151 的端口。
• “动态和/或专用端口”是从 49152 到 65535 的端口。

已知端口号

“已知端口”由 IANA 分配，并且在大多数系统中只能由系统（或根）进程或有特权的用户所执行的程序使用。TCP [RFC793] 中使用的端口用于命名进行长期对话的逻辑连接末端。为了向未知的呼叫方提供服务，系统定义了一个服务联系端口。



联系端口有时也称为“已知端口”。为了尽可能利用这些端口，UDP [RFC768] 使用了同样的端口分配。分配的端口只使用了一小部分可用的端口号。很多年以来，分配的端口一直处在 0-255 的范围内。最近，由 IANA 管理的已分配端口的范围扩展到了 0-1023。

注册端口号

“注册端口”由 IANA 列出，并且在大多数系统上可以由普通用户进程或普通用户所执行的程序使用。TCP [RFC793] 中使用的端口用于命名进行长期对话的逻辑连接末端。为了向未知的呼叫方提供服务，系统定义了一个服务联系端口。



IANA 会注册这些端口的使用情况，从而向社区提供方便。为了尽可能利用这些端口，UDP [RFC768] 使用了同样的端口分配。“注册端口”的范围为 1024-49151。



有关特定 TCP/IP 端口分配的信息，请参见 Information Sciences Institute 网站中以下位置的 RFC 1700：

Microsoft 提供了第三方联系信息以便于您寻求技术支持。这些联系信息如有更改，恕不另行通知。Microsoft 不保证这些第三方联系信息的准确性。

文章来源： https://support.microsoft.com/zh-cn/kb/174904

原文： http://www.pppei.net/blog/post/331

从萌生更换公司网关的想法，到选择、测试、部署陆陆续续用时两个月有余。选择的标准是open and free。这期间不断在查阅一些资料，测试了7、8个各开源防火墙产品。这些产品中大多是基于linux，少量基于BSD。基于linux的给我印象比较深的有ipfire、Zentyal。ipfire很轻量，功能上也能满足，但由于限速是基于linux 的tc，且并没有对tc的操作进行抽象，设置起来反而不如直接使用命令行脚本，所以只是把ipfire列入了候选名单。
zentyal 是基于Ubuntu的，看上去就是Ubuntu+webmin，安装后连X桌面都有，显的很庞大，功能自然不用说，linux有的功能它全有了，包括文件共享、邮件、IM等等，这样看来的确给中小企业节约了时间和成本，如果公司只有50-100来个人这种方案也是不错的选择，一台服务器涵盖企业常见应用。随着企业的成长可能这样的模式会带来一些问题，比如性能、存储空间等等 ，为了需求的增长去升级网关的硬件，显得有点不和谐。过度的集成恐怕日后会有不少问题要面对。既然目的是要选一款网关产品，就不要过度的想让它集成太多与“网关”无关的功能，免除一些不必要的麻烦。
最后目光集中到了pfsense身上，pfsense基于BSD，前身是m0n0wall，它专注构建企业级的安全网关，口碑也不错，国内还有pfsense的社区。pfsense虽然功能强大易用，可还是需要有一定的基础去驾驭它。经常看到有人会遇到各种问题无法解决，最终甚至放弃了pfsense，原因多是不能正确认识pfsense，不能自行分析解决问题。一般企来对网关产品的需求无非是NAT、防火墙、流量管理、流量监控、上网行为管理、vpn、热备、负载均衡。这些功能pfsense都可以做到，而且大多都是强项，下面我结合自身的一点实践，介绍一下我关注过的一些功能，并分享一点点经验。

1.NAT（PAT）

NAT不用过多阐述就是能让所有员工共用公司网络连接互联网。这里不得不提下pfsense NAT功能的一个软肋，就是对PPTP的支持有限，内网同一时刻只能有一个用户连接到外网某台特定的pptp服务器，这时其它用户不能再连接这台pptp服务器。如果其它用户连接这台服务器之外的其它pptp服务器，是不存在问题的。这是因为pptp传输数据时用了GRE（通用路由封装）协议，GRE自身和TCP/UDP处于同一级别（但GRE没有实现OSI中对4层定义的功能，不能认为它是4层协议），GRE和tcp/udp一样自己的数据被封装在ip包中，用IP来承载传输。通常网关对TCP/UDP进行NAT后会保留一个含有源、目的端口的一张状态表，避免内网多个用户使用同一源端口时发生冲突，也为返回的数据提供可以被准确转发到内网用户的依据。特殊的是GRE没有类似端口这样的信息，pfsense只是简单的转换GRE数据包中的IP地址，NAT转换表中不会出现端口信息。当内网某用户已经与外网pptp服务器建立了连接，再有用户尝试连接，服务器端返回的GRE协商数据到达pfsense网关后，这个数据包会按照 之前建立的NAT表转发，于是这个包没有被发送到发起连接的用户，而是转发给了第一个与该pptp服务器建立连接的用户。简单来说就是没有端口信息，NAT表中只能有一条到某一IP的转换条目，无法区分出内网不同用户，也就导致了其它用户无法再连接该pptp服务器。

pfsense的NAT、策略路由、防火墙等功能是通过BSD系统的 pf （packet filter）来实现的，归根结底这是 pf 的一个缺陷。目前这个问题没办法直接解决，只能用个变通方法，即将pptp 1723端口和gre协议的流量重定向到一台Linux服务器。linux 有专门的内核模块解决这个问题， 使用modprobe 加载 ip_conntrack_pptp、nf_nat_pptp 两个模块（iptables的nat 可以对服务器端和客户端的GRE协议的Call id进行转换，实现多个内网用户连接同一台pptp服务器），然后在pfsense中将此linux服务器的IP加到pfsense gateway中，在再firewall rule 的高级里将tcp 1723 和gre协议流量转发给这台linux服务器。

2.防火墙

前面提到了pfsense的防火墙、策略路由、NAT等功能都是用BSD下的PF（packet filter）实现的，这也可能是为什么这个项目叫做pfsense的原因。我的防火墙规则是这样的，pfsense网关共三个网卡分别用于WAN、LAN、DMZ，WAN只允许访问DMZ区域中服务器的80等服务端口，DMZ只允许访问互连网，LAN允许访问anywhere。

防火墙规则的高级选项中有很多实用功能，比如7层过滤、重定向、连接数限制、速度限制等，我也是使用了这个方法，对用户进行限速的，请转下一节。

3.流量管理

pfsense 有三种流量管理方法。
一是Queue，这种方式适合做QOS（服务质量保证），对数据进行分类，根据不同数据的不同特性，提供不同的服务质量，比如IP电话的语音数据，需要低网络延时，而某用户的下载流量只关心总带宽，这时就可以将ip电话的数据标记出来放到低延时的队列里，下载的流量放到只保证带宽的队列里，网关会用不同的算法转发相应的数据包，达到预定的服务质量。如果要实现对每个IP分别限速，就要为每个ip都建立一个队列，然后将每个IP的数据对应到唯这个队列上；
二是使用Captive portal，这种方式更适合用在无线网络环境中，用户需要打开浏览器输入用户名密码之后才能正常上网，同时为每个用户分配固定的带宽。只要开启了Captive portal，即使关闭了认证，也还是要打开浏览器在弹出的页面上点击确定后才能上网，用在有线环境里太影响用户体验，而且目前Captive portal 只有全局一个实例，2.1版可以针对不同的端口启用不同的实例；
三是使用防火墙的高功特性（这种方法是根据IP地址分别进行限速的）。在防火墙规则中限速有一个缺点，限速和访问控制策略偶合在了一块，失去了灵活性，配置的时候要谨慎一点不然可能会出现限速失效的情况，举个例子，为说明简单这里限速指的是下载限速：
①——-permit tcp any  to host 1.1.1.1 from lan————————
②——-permit any to any and speed limit 2M from Lan——

策略①中没有做流量限制，②中每用户的下载都限制在了2M。防火墙规则匹配是自上到下，匹配成功就不再向下进行，因此去往1.1.1.1的流量匹配了第一条策略，没做限速，第二条规则中的限速也就失效了。

另外再对速度做个说明，同样的策略在第一条上加上限速：
①——-permit tcp any  to host 1.1.1.1 and speed limit at 2M from lan——-
②——-permit any to any and speed limit 2M from Lan——

去往1.1.1.1的流量还会匹配策略①，其它的流量匹配策略②，那么如果用户同时有从1.1.1.1下载的流量和其它从其它地方下载的流量，从1.1.1.1下载.限制在2M，从其它地方下载也被限制在2M，因为是同时产生的流量，所以加起来用户得到了4M带宽。其实结果并不是这样的，在防火墙规则中限速时要先定义limiter，然后在规则中引用。内部是这样实现的，BSD的 PF（packet filter）没有限速功能，定义出来的limiter其实是另一个防火墙实现：IPFW中的组件，这个组件实现了限速，而且这个组件支持PIPE（管道）。PF中将匹配到的下载流量通过PIPE送到IPFW的Limiter中，limiter会根据定义时规定的参照值（源、目的ip，下载参照目的IP），为每个ip生成一个bukket，数据通过bukket的速度是它所属Limiter的速率。回到上面的例子规则 ①②中下载2M的limiter为同一个，同时匹配了两条规则的数据，通过PIPE被送到同一个Limiter中，这个limiter会根据目的ip生成一个BUKKET，这个bukket最大速度2M，用户得到的带宽最大也只是2M。如果规则①中使用了其它limiter比如下载3M的limiter，那么用户最终得到的带宽就是5M了。

　　实施方法前边也都说过了，很简单了Firewall ->Traffic Shaper -> limiter 下创建Limiter（需单独为上传下载创建limiter） ，然后在Firewall -> rule->Lan 规则的高级特性 In/Out 中应用limiter。

这里再对Limiter 的源地址和目的地址做个说明，因为limiter是被应用在Lan接口的Rule里，相对pfsense来说，用户发往 Lan口的流量为In，pfsense通过Lan口发给用户的流量为OUT，因此限制上传的limiter因该应用在In方向，limiter的参照值应该为“源IP”，下载的Limiter应该应用在OUT方向，因为是转发给用户的所以这个limiter的参数值应该是“目的IP”。

还有人可能会有疑问应用在Lan口只是转发给用户的速度慢了，从Wan口进来的流量一样不受限制。这种想法是错的，因为TCP有流控机质，UDP的话就要看上层应用的质量了。

在应用了新策略后，之前已经建立的连接是不会受这些规则影响的，可能得不到你想要的效果，需要在Diagnostics->States -> reset status 下清理一下pfsense的状态，中断用户的连接，就能看到效果了。

如果你更习惯在命令行操作，给出一些常用命令，不用和web界面死磕了：

pfctl -sn   #显示nat规则
pfctl -sr   #显示filter规则
pfctl -sa  #显示所有规则
pfctl -ss  #显示防火墙状态
pfctl -F nat #重置防火墙状态（清空NAT状态表）
ipfw pipe show #显示limiter的状态  其中0000x 为limiter的编号 BKT一列就是为每个ip分配的bukket编号

4.流量监控

pfsense 自身可以显示出当前每个ip的流量情况，web页面中默认只能显示流量最高的10个，并根据接口的实时流量绘制一张曲线图。我对页面进行了一点修改现在可以显示30个ip的流量，目前足够用了，还想实现按ip、上传、下载流量排序的功能，试了试有点超出我能力范围了，如果懂js就不是什么难事了，pfssense的php代码放在/usr/local/www/ ，函数库放在/etc/inc下，配置文件放在/conf下，想改就自己动手吧。

如果要充计历史流量数据，需要安装附加的package，有两个选择，一个是bandwidthd，另一个是ntop，前者很轻量，后者有点笨重，cpu占用也有点高，而且生成的数据我很难看懂，相反bandwidthd的数据很直观。目前两者都在用 bandwidthd统计Lan口，ntop统计 Wan和DMZ口，看不懂也无所谓，嘿嘿。

从命令行查看每IP实时流量可以用以下命令：
rate -i <接口> -nlq 1 -Aba 30 -c 192.168.1.0/24

5.上网行为管理

上网行为管理我觉得应该包括URL过滤、应用层协议识别控制。
首先说URL过滤，pfsense URL过滤用squid + squid guard实现的(需从package中自行安装 )，squid guard 支持正则表达式，我想我就不用说太多了吧，想过滤哪些url 、怎么过滤不都是自己说了算吗。
如果启用url过滤，建议打开Transparent proxy 的选项，这样会在PF的TRANSLATION RULES 中把发往 80的流量重定向到squid的3128端口，不用在用户端做任何的设置。

这里可能会有一个问题，看到社区中有人提到，就是使用了squid 进行 url 过滤，防火墙Rule里的限速就失效了。因为我对PF并不是很精通，我估计原因是这样的，www数据进入Lan接口先通过 TRANSLATION RULES ，数据包在TRANSLATION RULES 里把目的地址改写成了127.0.0.1,端口改写成了3128，然后数据才会继续通过filter rule ，由于某种不能了解的特殊性，没有匹配到任何规则，导致了限速失效。原因明白了对策就很简单了，在Lan接口上新建一个策略源地址为Lan subnet 目的地址为127.0.0.1 端口为3128，高级特性的In/Out中应用对应的limiter就可以了。

应用层协议识别不是pfsense强项，我试图用layer7的特性过滤p2p应用，在上班时间cpu占用到了P（双核），忘记是哪个进程了，所以我个人建议不要用pfsense的这个功能。如果非要对7层进行控制，可以用国产的免费产品panabit ，也是其于freebsd 的，功能非常丰富强大，可以集成到pfsense中去，不过也会有cpu占用率到100%的问题，且免费版有200用户（250？）的限制。

6.vpn

这个在企业应用中很普遍了，pfsense可以构建remote vpn（可以用pptp l2tp openvpn） ，供用户在公司以外的地方可以访问公司内网资源，还可以构建site to site vpn 互联公司分部（site2site只能用openvpn）。用openvpn 做sitetosite 有很多优势，比如可以选择性下发路由信息，可以选择使用tcp还是udp，不会像pptp 那样对NAT不友好。

我已经测试并使用了openvpn 集成 windows AD验证。pptp 和l2tp 不能直接使用AD验证，要通过radius间接实现，测试过程中我在AD上安装了radius服务，radius从Ad中进行用户验证。
另外强调下，pfsense是不能用作pptp 或l2tp的客户端的，只能用在当运营商线路需要pptp或l2tp验证的情况。

7.热备

有两个角度理解热备，1.线路热备 2.硬件热备。

这部分我没有测试就简单说一下吧，硬件failover通过CARP协议实现的，使用一个虚拟的IP做为用户网关，活动网关拥有该ip的控制权，活动网关死机备用网关自动接管该IP，用户端基本不会有感知。pfsense提供了一个强大的特性，它可以做到两台网关的配置同步，只需修改一台网关的设置，备用网关会自动同步活动网关的配置，方便至极。
线路热备建议配合firewall rule让一部分用户走其中一台线，另一部分用户走另一条线，同时检测运营商线路质量，如果延时大于预设值或丢包大于预设值更或者是网关不可用了，将该线路视为不可用，该规则自动失效所有用户数据自动切换到另一条线路。这样即没有浪费又达到了热备的效果。

8.负载均衡

一样的，包括线路负载均衡和硬件负载均衡，除此还多出一个服务器负载均衡。

同样这部分功能没有测试，简单概括一下了。服务器负载均衡用在公司有多台服务器对向提供相同服务时，定义一个服务器池，将这些服务器加入池中，用户连接按照指定的算法分配到池中的不同服务器上。
线路负载均衡上一节中提到了，如果不用firewall rule分配流量，而是通过两条指向不同运营商的路由来实现会存在这样一个问题，数据在发送方被拆为更小的包，在接收方要按顺序进行排序重组，如果一条线路快一线路慢或一条质量好一条质量差，用户会有很明显示的感觉，被慢的线路托慢了。所以建议使用第7节中所说的方法，将用户手动的分配到不同的线路中去。

9.其它应用

snort：入侵检测，实际应用中没有看到任何效果，alert中一直是空的，没有深究。
nrpe：使用内网的nagios对pfsense进行磁盘、负载、外网线路延时等数据进行监控报警。

总结：

pfsense 将BSD系统的网络功能优势发辉到了极致，虽然它并没有强大到无所不能、没有任何瑕疵，但作为一款开源免费的防火墙产品已经可以让我内牛满面了。在使用pfsense前，最好对自己的需求进行分析，如果觉得可以满足目前和将来的需求，我强列推荐您使用pfsense。同时希望这篇文章可以对你了解使用pfsense起到帮助作用，有也就知足了。最后提醒您远离ISA、远离昂贵商业产品。

根据网上的资料，一般单目录下的文件个数一般限制不能够超过3万；同样的，一个目录下面的目录数也最好不要超过这个数。

但实际上，为了安全考虑，一般都不要存储这么多的内容。

假定，一个目录下面，存储1000个文件，每个文件的平均大小为10KB，则单目录下面可存储的容量是10MB。这个容量太小了，所以我们要多个目录，假定有1000个目录，每个目录存储10MB，则可以存储10GB的内容；这对于目前磁盘的容量来说，利用率还是不够的。再想办法，转成两级目录，这样的话，就是第一层目录有1000个子目录，每一级子目录下面又有1000级的二级子目录，每个二级子目录，可以存储10MB的内容，此时就可以存储10T的内容，这基本上超过了目前单机磁盘的容量大小了。

所以，使用二级子目录的办法，是平衡存储性能和利用存储容量的办法。

服务器收到了文件内容后，如何选择要存储在哪个目录下呢？这个选择要保证均衡性，即尽量保证文件能够均匀地分散在所有的目录下。

负载均衡性很重要的就是哈希，例如，在PHP中常用的md5，其返回一个32个字符，即16字节的输出，即128位。哈希后要变成桶，才能够分布，自然就有了如下的问题：

1- 如何得到哈希值？md5还是SHA1

2- 哈希值得到后，如何构造哈希桶

3- 根据文件名称如何定位哈希桶

首先来回答第3个问题，根据文件名称如何定位哈希桶。很简单，此时我们只有一个文件名称作为输入，首先要计算哈希值，只有一个办法了，就是根据文件名称来得到哈希值。这个函数可以用整个文件名称作为哈希的输入，也可以根据文件名称的一部分来完成。结合上面说的两级目录，而且每级目录不要超过1000.很简单，如果用32位的字符输出后，可以取出实现上来说，由于文件上传是防止唯一性，所以如果根据文件内容来产生哈希，则比较好的办法就是截取其中的4位，例如：

md5sum fdfs_storaged.pid

52edc4a5890adc59cec82cb60f8af691 fdfs_storaged.pid

上面，这个fdfs_storage.pid中，取出最前面的4个字符，即52和ed。这样的话，假如52是一级目录的名称，ed是二级目录的名称。因为每一个字符有16个取值，所以第一级目录就有16 * 16 = 256个。总共就有256 * 256 = 65526个目录。如果每个目录下面存放1000个文件，每个文件30KB，都可以有1966G，即2TB左右。这样的话，足够我们用好。如果用三个字符，即52e作为一级目录，dc4作为二级目录，这样子的目录数有4096，太多了。所以，取二个字符比较好。

这样的话，上面的第2和第3个问题就解决了，根据文件名称来得到md5，然后取4个字符，前面的2个字符作为一级目录名称，后面的2个字符作为二级目录的名称。服务器上，使用一个专门的目录来作为我们的存储根目录，然后下面建立这么多子目录，自然就很简单了。

这些目录可以在初始化的时候创建出来，而不用在存储文件的时候才建立。

也许你会问，一个目录应该不够吧，实际上很多的廉价机器一般都配置2块硬盘，一块是操作系统盘，一块是数据盘。然后这个数据盘挂在一个目录下面，以这个目录作为我们的存储根目录就好了。这样也可以很大程度上减少运维的难度。

现在就剩下最后一个问题了，就是上传文件时候，如何分配一个唯一的文件名称，避免同以前的文件产生覆盖。

如果没有变量作为输入，很显然，只能够采用类似于计数器的方式，即一个counter，每次加一个文件就增量。但这样的方式会要求维护一个持久化的counter，这样比较麻烦。最好不要有历史状态的纪录。

string md5 ( string $str [, bool $raw_output = false ] )

Calculates the MD5 hash of str using the » RSA Data Security, Inc. MD5 Message-Digest Algorithm, and returns that hash.

raw_output

If the optional raw_output is set to TRUE, then the md5 digest is instead returned in raw binary format with a length of 16.

Return Values ¶

Returns the hash as a 32-character hexadecimal number.

为了尽可能地生成唯一的文件名称，可以使用文件长度(假如是100MB的话，相应的整型可能会是4个字节，即不超过2^32, 即uint32_t，只要程序代码中检查一下即可）。但是长度并不能够保证唯一，为了填充尽可能有用的信息，CRC32也是很重要的，这样下载程序后，不用做额外的交互就可以知道文件的内容是否正确。一旦发现有问题，立马要报警，并且想办法修复。这样的话，上传的时候也要注意带上CRC32，以防止在网络传输和实际的硬盘存储过程中出现问题（文件的完整性至关重要）。再加上时间戳，即long型的64位，8个字节。最后再加上计数器，因为这个计数器由storage提供，这样的话，整个结构就是：len + crc32 + timestamp + uint32_t = 4 + 4 + 8 + 4 = 20个字节，这样生成的文件名就算做base64计算出来，也就不是什么大问题了。而且，加上计数器，每秒内只要单机不上传超过1万的文件 ，就都不是问题了。这个还是非常好解决的

// TODO 如何避免文件重复上传？ md5吗？ 还是文件的计算可以避免此问题？这个信息存储在tracker服务器中吗？

FastDFS中给我们一个非常好的例子，请参考下面的代码：

// 参考FastDFS的文件名称生成算法

/**
1 byte: store path index
8 bytes: file size
FDFS_FILE_EXT_NAME_MAX_LEN bytes: file ext name, do not include dot (.)
file size bytes: file content
**/
static int storage_upload_file(struct fast_task_info *pTask, bool bAppenderFile)
{
 StorageClientInfo *pClientInfo;
 StorageFileContext *pFileContext;
 DisconnectCleanFunc clean_func;
 char *p;
 char filename[128];
 char file_ext_name[FDFS_FILE_PREFIX_MAX_LEN + 1];
 int64_t nInPackLen;
 int64_t file_offset;
 int64_t file_bytes;
 int crc32;
 int store_path_index;
 int result;
 int filename_len;
 pClientInfo = (StorageClientInfo *)pTask->arg;
 pFileContext = &(pClientInfo->file_context);
 nInPackLen = pClientInfo->total_length - sizeof(TrackerHeader);
 if (nInPackLen < 1 + FDFS_PROTO_PKG_LEN_SIZE +
   FDFS_FILE_EXT_NAME_MAX_LEN)
 {
  logError("file: "__FILE__", line: %d, " \
   "cmd=%d, client ip: %s, package size " \
   "%"PRId64" is not correct, " \
   "expect length >= %d", __LINE__, \
   STORAGE_PROTO_CMD_UPLOAD_FILE, \
   pTask->client_ip, nInPackLen, \
   1 + FDFS_PROTO_PKG_LEN_SIZE + \
   FDFS_FILE_EXT_NAME_MAX_LEN);
  return EINVAL;
 }
 p = pTask->data + sizeof(TrackerHeader);
 store_path_index = *p++;
 if (store_path_index == -1)
 {
  if ((result=storage_get_storage_path_index( \
   &store_path_index)) != 0)
  {
   logError("file: "__FILE__", line: %d, " \
    "get_storage_path_index fail, " \
    "errno: %d, error info: %s", __LINE__, \
    result, STRERROR(result));
   return result;
  }
 }
 else if (store_path_index < 0 || store_path_index >= \
  g_fdfs_store_paths.count)
 {
  logError("file: "__FILE__", line: %d, " \
   "client ip: %s, store_path_index: %d " \
   "is invalid", __LINE__, \
   pTask->client_ip, store_path_index);
  return EINVAL;
 }
 file_bytes = buff2long(p);
 p += FDFS_PROTO_PKG_LEN_SIZE;
 if (file_bytes < 0 || file_bytes != nInPackLen - \
   (1 + FDFS_PROTO_PKG_LEN_SIZE + \
    FDFS_FILE_EXT_NAME_MAX_LEN))
 {
  logError("file: "__FILE__", line: %d, " \
   "client ip: %s, pkg length is not correct, " \
   "invalid file bytes: %"PRId64 \
   ", total body length: %"PRId64, \
   __LINE__, pTask->client_ip, file_bytes, nInPackLen);
  return EINVAL;
 }
 memcpy(file_ext_name, p, FDFS_FILE_EXT_NAME_MAX_LEN);
 *(file_ext_name + FDFS_FILE_EXT_NAME_MAX_LEN) = '\0';
 p += FDFS_FILE_EXT_NAME_MAX_LEN;
 if ((result=fdfs_validate_filename(file_ext_name)) != 0)
 {
  logError("file: "__FILE__", line: %d, " \
   "client ip: %s, file_ext_name: %s " \
   "is invalid!", __LINE__, \
   pTask->client_ip, file_ext_name);
  return result;
 }
 pFileContext->calc_crc32 = true;
 pFileContext->calc_file_hash = g_check_file_duplicate;
 pFileContext->extra_info.upload.start_time = g_current_time;
 strcpy(pFileContext->extra_info.upload.file_ext_name, file_ext_name);
 storage_format_ext_name(file_ext_name, \
   pFileContext->extra_info.upload.formatted_ext_name);
 pFileContext->extra_info.upload.trunk_info.path. \
    store_path_index = store_path_index;
 pFileContext->extra_info.upload.file_type = _FILE_TYPE_REGULAR;
 pFileContext->sync_flag = STORAGE_OP_TYPE_SOURCE_CREATE_FILE;
 pFileContext->timestamp2log = pFileContext->extra_info.upload.start_time;
 pFileContext->op = FDFS_STORAGE_FILE_OP_WRITE;
 if (bAppenderFile)
 {
  pFileContext->extra_info.upload.file_type |= \
     _FILE_TYPE_APPENDER;
 }
 else
 {
  if (g_if_use_trunk_file && trunk_check_size( \
   TRUNK_CALC_SIZE(file_bytes)))
  {
   pFileContext->extra_info.upload.file_type |= \
      _FILE_TYPE_TRUNK;
  }
 }
 if (pFileContext->extra_info.upload.file_type & _FILE_TYPE_TRUNK)
 {
  FDFSTrunkFullInfo *pTrunkInfo;
  pFileContext->extra_info.upload.if_sub_path_alloced = true;
  pTrunkInfo = &(pFileContext->extra_info.upload.trunk_info);
  if ((result=trunk_client_trunk_alloc_space( \
   TRUNK_CALC_SIZE(file_bytes), pTrunkInfo)) != 0)
  {
   return result;
  }
  clean_func = dio_trunk_write_finish_clean_up;
  file_offset = TRUNK_FILE_START_OFFSET((*pTrunkInfo));
    pFileContext->extra_info.upload.if_gen_filename = true;
  trunk_get_full_filename(pTrunkInfo, pFileContext->filename, \
    sizeof(pFileContext->filename));
  pFileContext->extra_info.upload.before_open_callback = \
     dio_check_trunk_file_when_upload;
  pFileContext->extra_info.upload.before_close_callback = \
     dio_write_chunk_header;
  pFileContext->open_flags = O_RDWR | g_extra_open_file_flags;
 }
 else
 {
  char reserved_space_str[32];
  if (!storage_check_reserved_space_path(g_path_space_list \
   [store_path_index].total_mb, g_path_space_list \
   [store_path_index].free_mb - (file_bytes/FDFS_ONE_MB), \
   g_avg_storage_reserved_mb))
  {
   logError("file: "__FILE__", line: %d, " \
    "no space to upload file, "
    "free space: %d MB is too small, file bytes: " \
    "%"PRId64", reserved space: %s", \
    __LINE__, g_path_space_list[store_path_index].\
    free_mb, file_bytes, \
    fdfs_storage_reserved_space_to_string_ex( \
      g_storage_reserved_space.flag, \
          g_avg_storage_reserved_mb, \
      g_path_space_list[store_path_index]. \
      total_mb, g_storage_reserved_space.rs.ratio,\
      reserved_space_str));
   return ENOSPC;
  }
  crc32 = rand();
  *filename = '\0';
  filename_len = 0;
  pFileContext->extra_info.upload.if_sub_path_alloced = false;
  if ((result=storage_get_filename(pClientInfo, \
   pFileContext->extra_info.upload.start_time, \
   file_bytes, crc32, pFileContext->extra_info.upload.\
   formatted_ext_name, filename, &filename_len, \
   pFileContext->filename)) != 0)
  {
   return result;
  }
  clean_func = dio_write_finish_clean_up;
  file_offset = 0;
    pFileContext->extra_info.upload.if_gen_filename = true;
  pFileContext->extra_info.upload.before_open_callback = NULL;
  pFileContext->extra_info.upload.before_close_callback = NULL;
  pFileContext->open_flags = O_WRONLY | O_CREAT | O_TRUNC \
      | g_extra_open_file_flags;
 }
  return storage_write_to_file(pTask, file_offset, file_bytes, \
   p - pTask->data, dio_write_file, \
   storage_upload_file_done_callback, \
   clean_func, store_path_index);
}
 
static int storage_get_filename(StorageClientInfo *pClientInfo, \
 const int start_time, const int64_t file_size, const int crc32, \
 const char *szFormattedExt, char *filename, \
 int *filename_len, char *full_filename)
{
 int i;
 int result;
 int store_path_index;
 store_path_index = pClientInfo->file_context.extra_info.upload.
    trunk_info.path.store_path_index;
 for (i=0; i<10; i++)
 {
  if ((result=storage_gen_filename(pClientInfo, file_size, \
   crc32, szFormattedExt, FDFS_FILE_EXT_NAME_MAX_LEN+1, \
   start_time, filename, filename_len)) != 0)
  {
   return result;
  }
  sprintf(full_filename, "%s/data/%s", \
   g_fdfs_store_paths.paths[store_path_index], filename);
  if (!fileExists(full_filename))
  {
   break;
  }
  *full_filename = '\0';
 }
 if (*full_filename == '\0')
 {
  logError("file: "__FILE__", line: %d, " \
   "Can't generate uniq filename", __LINE__);
  *filename = '\0';
  *filename_len = 0;
  return ENOENT;
 }
 return 0;
}
static int storage_gen_filename(StorageClientInfo *pClientInfo, \
  const int64_t file_size, const int crc32, \
  const char *szFormattedExt, const int ext_name_len, \
  const time_t timestamp, char *filename, int *filename_len)
{
 char buff[sizeof(int) * 5];
 char encoded[sizeof(int) * 8 + 1];
 int len;
 int64_t masked_file_size;
 FDFSTrunkFullInfo *pTrunkInfo;
 pTrunkInfo = &(pClientInfo->file_context.extra_info.upload.trunk_info);
 int2buff(htonl(g_server_id_in_filename), buff);
 int2buff(timestamp, buff+sizeof(int));
 if ((file_size >> 32) != 0)
 {
  masked_file_size = file_size;
 }
 else
 {
  COMBINE_RAND_FILE_SIZE(file_size, masked_file_size);
 }
 long2buff(masked_file_size, buff+sizeof(int)*2);
 int2buff(crc32, buff+sizeof(int)*4);
 base64_encode_ex(&g_fdfs_base64_context, buff, sizeof(int) * 5, encoded, \
   filename_len, false);
 if (!pClientInfo->file_context.extra_info.upload.if_sub_path_alloced)
 {
  int sub_path_high;
  int sub_path_low;
  storage_get_store_path(encoded, *filename_len, \
   &sub_path_high, &sub_path_low);
  pTrunkInfo->path.sub_path_high = sub_path_high;
  pTrunkInfo->path.sub_path_low = sub_path_low;
  pClientInfo->file_context.extra_info.upload. \
    if_sub_path_alloced = true;
 }
 len = sprintf(filename, FDFS_STORAGE_DATA_DIR_FORMAT"/" \
   FDFS_STORAGE_DATA_DIR_FORMAT"/", \
   pTrunkInfo->path.sub_path_high,
   pTrunkInfo->path.sub_path_low);
 memcpy(filename+len, encoded, *filename_len);
 memcpy(filename+len+(*filename_len), szFormattedExt, ext_name_len);
 *filename_len += len + ext_name_len;
 *(filename + (*filename_len)) = '\0';
 return 0;
}

根据上面分析的结果，我们看到，当上传一个文件的时候，我们会获取到如下的信息

1- 文件的大小（通过协议中包的长度字段可以知道，这样的好处在于服务端实现的时候简单，不用过于担心网络缓冲区的问题）

2- CRC32（也是协议包中传输，以便确定网络传输是否出错）

3- 时间戳（获取服务器的当前时间）

4- 计数器（服务器自己维护）

根据上面的4个数据，组织成base64的编码，然后生成此文件名称。根据此文件名称的唯一性，就不会出现被覆盖的情况。同时，唯一性也使得接下来做md5运算后，得到的HASH值离散性得么保证。得到了MD5的哈希值后，取出最前面的2部分，就可以知道要定位到哪个目录下面去。哈希桶的构造是固定的，即二级00-ff的目录情况