netpet(凌晓)的博客

 当今国互联网的飞速发展让人们获益匪浅，同时人们对于互联网的期望值也变得越来越高。这就形成了一个矛盾，虽然互联网的发展已经是相当迅猛的了，但是人们还是期望从服务器到客户终端的文件传输的速度能够比现在再快一些，这种要求（当然是合理的要求）好像从来也满足不了。在向人们询问“一种什么样的速度对于数据传输来说才是最理想的”问题时，几乎每一次你都会得到一种不同的答案：有的人认为数据传

 由于最近在忙于webserver的开发，对于静态部分跟动态部分的交互一直迟迟未定，缓冲区大小也一直很头疼，看了下面的这篇文章觉得不错，我还是这样觉得，简单的就是最好的，但并不意味着所有处理都用一种方式，正如我在静态输出的socketbuffer上面一样，我是根据请求内容的大小来决定缓冲区分配的，即使这样作在系统内部会形成一次内存拷贝（socket回去处理），但是相对于网络的延迟速

  nginx现在正在以光的速度蔓延开来，他以其稳定性和高性能等众多优点迅速扩大市场，大家都知道，nginx是以单线程为基础的，那么他怎么能在并发性上取得优势的呢？会不会因为网络阻塞而导致主线程阻塞呢？下面就相关问题作一些概念性的阐述。    问题的根本在于人们对于计算机处理性能还没有足够的认识，以及普通的服务器架构简化的处理，做过大型的成熟服务器的人可能都知道，解决一个系统瓶颈比优化

 早在两年前我就已经能很熟练的运用完成端口这种技术了,只是一直没有机会将它用在什么项目中,这段时间见到这种技术被过分炒作,过分的神秘化,就想写一篇解释它如何工作的文章.想告诉大家它没有传说中的那么高深难懂!有什么错误的地方还请高人指正.转载请注明出处及作者,谢谢! 以一个文件传输服务端为例,在我的机器上它只起两个线程就可以为很多个个客户端同时提供文件下载服务,程序的性能会随机器

  最近在开发一个类似于nginx的web server，前面也做了几篇文章来阐述相关问题，现在就近期遇到的几个新问题以及注意事项记录下来。  1、sokcet和文件fd的关闭问题：看起来这是个简单的问题，但是正如内存分配和释放一样，这里也是很容易发生问题的一个地方，在做到反向代理的时候遇到了一个新的问题，一个fd会伴随这另外的socketfd，或者会产生一个文件fd，这些描述服

  今天朋友对我说我被推荐到csdn专家了，很开心，特发布新博以示庆祝。前言：xml网站不是什么新东西了，csdn最早的论坛也是基于xml的，后来为什么改掉了，我想除了搜索殷勤支持不够外更多地是技术支持不完善，但这正是我研究了3年多的项目核心，从最早的asp.net实现到后来的自制java模型实现，再到后来的基于linux的c/c++模型实现，现在回归到用.net配合IIS的几个模型实

FastDFS，这是一个c语言的不错的选择。缺点是文件路径是一致的，只能用于嵌入式文件的存储，没有办法作为系统请求文件的存储，不过对于web2.0可以从设计层面进行一些改善，将用户的数据交互更多地方在服务器端，而不是数据库中，比如用户的文章就在xxx.com/yyy里面，但是这又带来一些新的问题，文件同步负载均衡等问题。   现在着眼于将自制的web server 专项用于负载均衡