xiaofei chain

前面我们说过，对于静态文件的传输，用sendfile可以减少系统调用，现在我们看看动态的数据应该如何处理。 首先，如果数据足够小（小于1024）且只有唯一的一个buffer,我们直接用 send/write 就可以了。 通常的情况下，程序可能会在多个地方产生不同的buffer,如 nginx，第一个phase里都可能会产生buffer，放进一个chain里， 如果对每个buffer调用一次s

如果把tcp当成服务端与客户端的管道，cork 就是给管道加个塞子。 为什么 要加个塞子呢？ 先来举个例子： int times = 10; while( times--) { send( sock_fd, buf, 1, 0 ) } 这段program会发送数据10次，每次就发送1个字节，这样会不会什么问题呢？ 记得以前农忙的时候，田里的稻子收割完了，要打成

socket发送函数。 int send( SOCKET s, const char FAR *buf, int len, int flags ); 如果内容是动态生成的，一般是把传输内容直接丢给buf中用send函数传输，没有优化的空间。 文件传输则要先把内容read到buf中，因此至少两次内核调用，如果文件很大，可能会用一个循环调用，如： while( size == P

前面我们谈的大多是服务端与客户端的技术，服务器开发其实有时还会涉及到跨服务器的访问，比如腾讯的拍拍服务器需要知道登录的会员信息， 就需要访问会员服务器。 跨务器访问会涉及到很多的技术，比如访问权限控制，数据同步等，这里主要来学习一下传输层。 为了更容易理解，我们将访问端服务器称为客户端，被访问端服务器称为服务端。 客户端发起一个连接的过程： socket_fd = socket( A

前面所说技术订都是服务器端一个人在努力，有时候也需要客户端配合。 一个链接请求过程大致可以分成几个阶段 如果客户端发送同样的请求，且结果都一样，我们是不是可以缓冲一下呢?是不是可以减少几步呢?  的确可以，一般来说以下几种方法： 1.我们先试着在服务端进行缓冲，我们试着将一个已经返回的长链接发送内容不作释放，下次请求时直接返回刚才发送的内容，这个不适用于频繁访问，适

做架构设计，难免有时候被人问及系统的瓶颈在哪，那首先来了解下什么是瓶颈？ 打个形象的比方,人的嘴巴可以吞下一整个面包，但是却咽不下去，因为食管不给力，它比较细，所以嘴巴能吞下的食物大小要受到食管的粗细限制。 城市内部每天会产生几十万件跨城快递，可是跨城的交通不给力，只允许走小型卡车，一卡车一次就能装几千件，一天下来也不一定能投送的完。 人在一定时间内能咽下多少食物，货运公司在一天运送多少货物

P2P全称是 peer to peer,国内有被翻译成点对点协议，顾名思议，即客户端与客户端直连。 但是，问题是只有极少数情况下，客户端之间才能直连。 为什么呢，现在大家的PC大部分是“躲”在路由后面，路由设备保护大家，免受黑客的攻击。 试想一下，如果别人可以任意直连你的电脑，经常上传重口味艳照的你岂不是整天生活在恐惧之中。

既然P2P可以直接在客户端间建立连接，为啥像电驴，QQ这样的P2P软件还要登录呢。 打个比方，假设有两个用户，A,B,相关信息如下：