亚洲综合色视频,欧美日韩在线播放,欧美日在线观看

TCP收包��结

ecopgm — Fri, 28 Mar 2008 03:28:00 GMT

先说说TCP收包的context�Q�不定长包）。一般情况，发送方发送一个包�Q�然后接收方收到一个包�Q�这是最好处理的。第二种情况�Q�当每次发生的包比较��时�Q�发送数据时�Q�TCP会启用优化算法，��多个小包集中�v来发送，以提高传输效率。此时接收方的recv buffer中，可能出现不止一个包。第三种情况�Q�recv buffer中每�ơ只一个包�Q�但接收�Ҏ��及时取包�Q�这时recv buffer中会�U�篏多个包�?br>理所当然�Q�TCP收包要考虑所有这些情��c��一般来说有三种�Ҏ��。第一�U�，定义好通讯协议�Q�先收包��_��然后�Ҏ��包头中的消息真实大小�Q�接收消息剩余部分。第二种�Ҏ��Q�通讯协议规定好每个消息的开始和�l�束标识�W�。然后每�ơrecv得到的数据先攑ֈ�一个大�Q�比如你的最大packet�?倍）buffer中，最后再来分析这个buffer分包。第三种�Ҏ��Q�先用recv+MSG_PEEK接收某个固定长度�Q�然后对接收到的"�?�q�行分析�Q�然后做真正的recv操作�?br>

ecopgm 2008-03-28 11:28 发表评论

ecopgm — Mon, 24 Mar 2008 14:36:00 GMT

能不能接受爆发连接（�q�发度如何）�Q�主要是取决于accept的速度。一个TCP�q�接的徏立，要在client和server之间�Q�完成三�ơ握手，然后�q�接会被攑ֈ�完成队列中，accept从完成队列中取出�q�接�q�返回。�Q何媄响accept取连接的因素�Q�都会媄响�ƈ发度。一般策略是�Q? 独立处理accept�Q? 使用epoll处理accept�Q�这两种情况�Q��ƈ发度都是不错的�?br>�q�发地接受了�q�么多连接，�q�不代表能完全处理。假如有很多�q�接同时在线�Q�server accept成功�q�收��C��数据�Q�这时消息被攑ֈ�消息队列中，�{�待逻辑�U�程来处理。因为生产者（收数据）的速度��L��大于消费者（处理数据�Q�的速度�Q�因此消息队列会有考虑��控�Q�以免系�l�资源被耗光。这��P��有些消息��可能丢失。这��是同时在线�q�接数的问题�?br>前者是高�ƈ发，后者是高负载。设计时会权衡偏向�?

ecopgm 2008-03-24 22:36 发表评论

�q�发�{�略�ȝ��

ecopgm — Mon, 24 Mar 2008 06:43:00 GMT

�q�发服务器有三种常见的架构：
1. 单线�E�epoll�Q�ET非阻塞I/O) +�U�程池，也叫半同步半异步模式。这�U�模型比较常见，而且因�ؓ异步层和同步层��用消息队列传递消息，更容易实现对消息的FIFO处理。缺点就是线�E�的同步和上下文切换开销比较大�?br>2. ConnectionPerThread+��d��型I/O。这是最古老的服务器�ƈ发模型，不太适合��C��的这些高�q�发高负载服务器�Q�当�q�接数巨大的时候，创徏销毁线�E�的开销会无法承受，�q�且内核创徏�U�程的速度也会成�ؓ瓉��。这�U�模型的一�U�改�q�型��是领导�?跟随者模式，它吸取第一�U�模型中�Q�线�E�数量不会膨胀的优点，使用�U�程池来处理�q�接。每当有�q�接到达�Ӟ��都��用一个线�E�阻塞处理，处理完成后，�U�程再回到线�E�池中，�q�样有限的线�E�模拟出了ConnectionPerThread。一般来��_��领导�?跟随者模型比�W�一�U�模型更加高效，因�ؓ它减��了�U�程同步和切换的开销�Q�它的缺点就是FIFO很难保证�?br>3. ��水�U�模型。前面两�U�模式都有个�~�点�Q�它们不能花太长旉��处理逻辑�Q�因为在多CPU�pȝ��上，某些耗时的长��h��可能会不断占住CPU�Q�而导致短��h��得不到处理，�q�会使某些CPU闲置。于是这�U�模型提出，��请求处理的�q�程划分步骤�Q�不同的步骤考虑不同的资源处理（比如CPU, DISK I/O�{�）�Q�每个步骤��用单独的�U�程或线�E�池。这��h��较耗时的操作可能集中在��水�U�的下��Q�而短��h��也可以在上��得到快速处理。因为各�U�线�E�之间��用消息队列传递请求，也很�Ҏ��实现FIFO�?/p>

ecopgm 2008-03-24 14:43 发表评论

I/O�{�略��结

ecopgm — Mon, 24 Mar 2008 06:40:00 GMT

如何高效处理多个socket I/O的读写，是提高服务器性能的重炚w��题。unix-like下面�Q�现有机制有select,poll, epoll,kqueue,/dev/poll两大�c�R�?/span>

Select有个�~�点�Q�它�?span>fd_set��理所有要监视�?span>I/O句柄�Q�但�?span>fd_set是一个位数组�Q�只能接受句柄号��于FD_SETSIZE�Q�默�?span>1024�Q�的句柄�Q�虽然进�E�默认句柄号都是��于1024的，但是可以通过ulimit –n来修改，��其是连接数��过1024时必需�q�么做（实际可能更少�Q�，如果要将大于1024的句柄放�?span>fd_set�Q�就可能发生数组��界�E�序崩溃的场面�?/span>

Poll虽然解决�?span>FD_SETSIZE问题�Q�但是它�?span>select一��P��都有性能上的瓉��。它们都会随着�q�接数的增加性能直线下降。这主要有两个原因，其一是每��?span>select/poll操作�Q?span>kernel都会建立一个当前线�E�关心的事�g列表�Q��ƈ让线�E�阻塞在�q�个列表上，�q�是很耗时的操作。其二是每次select/poll�q�回后，�U�程都要扫描所有句柄来dispatch已发生的事�g�Q�这也是很耗时的。当�q�接数巨大时�Q�这�U�消耗积累�v来，��很受不了�?/span>

��Z��解决select/poll的性能问题�Q�unix-like�pȝ��上开发出了三套新的利�?span>epoll�Q?span>kqueue�Q?span>/dev/poll�Q�其�?span>epoll�?span>linux的，kqueue�?span>freebsd的，/dev/poll�?span>Solaris�?/span>的，它们是select/poll的替代品。它们的设计��是针对select/poll的性能问题�Q�主要避�?span> 1�?/span>每次调用都徏立事件等待列表，取而代之徏立长期的事�g��x��列表�Q�这个列表可通过句柄�Q�比�?span>epfd�Q�来增加和删除事件�?span>2�?/span>调用�q�回之后�Q�不再需要遍历所有句柄进行分发，内核会直接返回当前已发生的事件。不用说�Q�性能�?span>select, poll基础上有了大�q�提升�?br>
要注意的是，凡是使用readiness notification�Q�LT)或者readiness change notification�Q�ET)机制�Q�都应该配合非阻塞I/O�Q�因��U�事仉��知�Q��ƈ不一定表�C�文件描�q�符真正��q�A�Q�如果收到通知之后去read�Q�很有可能进入阻塞状态，�q�会严重影响服务器的�q�发性能�Q�同时对ET模式�Q�不能漏掉�Q何事件的处理�Q��ƈ且每�ơ都应该��d��socket�q�回EWOULDBLOCK为止�Q�不然这个socket之后会永�q�保持沉默�?/span>

ecopgm 2008-03-24 14:40 发表评论

亚洲综合色视频,欧美日韩在线播放,欧美日在线观看

TCP收包���结

�q�发�{�略�ȝ��

I/O�{�略���结

TCP收包��结

I/O�{�略��结