4色图

Posted by 夏泽民

在图论的基本理论中,有加权顶点的概念。顶点具有的与之相关的数,称为权(weight);该顶点称为加权顶点。



www-authenticate

Posted by 夏泽民

www-authenticate是早期的一种简单的,有效的用户身份认证技术。 很多网站验证都采用这种简单的验证方式来完成对客户端请求的数据的合法性进行验证。尤其在嵌入式领域中,此方法使用较多。 缺点:这种认证方式在传输过程中是明码传输的,采用的用户名密码加密方式为BASE-64,其解码过程非常简单,网络上很容易搜索到编解码的源码。采用这种认证方式对于普通用户是较安全的,但稍懂TCP/IP协议和HTTP传输协议和验证过程的,破解这种验证用户名和密码是非常简单的。所以其认证技术并不是很安全。 二、认证过程



rstp

Posted by 夏泽民

https://github.com/EasyDarwin/Course#%E4%B8%80%E6%AC%A1%E5%9F%BA%E6%9C%AC%E7%9A%84rtsp%E6%93%8D%E4%BD%9C%E8%BF%87%E7%A8%8B RTSP(Real Time Streaming Protocol),RFC2326,实时流传输协议,是TCP/IP协议体系中的一个应用层协议,由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上,它使用TCP或UDP完成数据传输。HTTP与RTSP相比,HTTP请求由客户机发出,服务器作出响应;使用RTSP时,客户机和服务器都可以发出请求,即RTSP可以是双向的。RTSP是用来控制声音或影像的多媒体串流协议,并允许同时多个串流需求控制,传输时所用的网络通讯协定并不在其定义的范围内,服务器端可以自行选择使用TCP或UDP来传送串流内容,它的语法和运作跟HTTP 1.1类似,但并不特别强调时间同步,所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制(Multicast),除了可以降低服务器端的网络用量,更进而支持多方视讯会议(Video Conference)。因为与HTTP1.1的运作方式相似,所以代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于RTSP,并因RTSP具有重新导向功能,可视实际负载情况来转换提供服务的服务器,以避免过大的负载集中于同一服务器而造成延迟。 RTSP(Real-TimeStream Protocol )是一种基于文本的应用层协议,在语法及一些消息参数等方面,RTSP协议与HTTP协议类似。



WebDAV

Posted by 夏泽民

WebDAV (Web-based Distributed Authoring and Versioning) 一种基于 HTTP 1.1协议的通信协议。它扩展了HTTP 1.1,在GET、POST、HEAD等几个HTTP标准方法以外添加了一些新的方法,使应用程序可对Web Server直接读写,并支持写文件锁定(Locking)及解锁(Unlock),还可以支持文件的版本控制。



TCP_NODELAY

Posted by 夏泽民

TCP/IP协议中针对TCP默认开启了Nagle算法。Nagle算法通过减少需要传输的数据包,来优化网络 启动TCP_NODELAY,就意味着禁用了Nagle算法,允许小包的发送。对于延时敏感型,同时数据传输量比较小的应用,开启TCP_NODELAY选项无疑是一个正确的选择。比如,对于SSH会话,用户在远程敲击键盘发出指令的速度相对于网络带宽能力来说,绝对不是在一个量级上的,所以数据传输非常少;而又要求用户的输入能够及时获得返回,有较低的延时。如果开启了Nagle算法,就很可能出现频繁的延时,导致用户体验极差。当然,你也可以选择在应用层进行buffer,比如使用java中的buffered stream,尽可能地将大包写入到内核的写缓存进行发送;vectored I/O(writev接口)也是个不错的选择。对于关闭TCP_NODELAY,则是应用了Nagle算法。数据只有在写缓存中累积到一定量之后,才会被发送出去,这样明显提高了网络利用率(实际传输数据payload与协议头的比例大大提高)。但是这由不可避免地增加了延时;与TCP delayed ack这个特性结合,这个问题会更加显著,延时基本在40ms左右。当然这个问题只有在连续进行两次写操作的时候,才会暴露出来 最近排查 Redis 的 Redis server went away 问题时,发现 Redis 的 PHP 扩展里面特意使用 setsockopt() 函数设置了 sock 套接字的 TCP_NODELAY 项,用来禁用了 Nagle’s Algorithm 算法 首先看我用 ab 不加 -k 选项的结果很好,不超过 1ms 的响应时间。但一旦我加上了 -k 选项启用 HTTP Keep-Alive,结果就变成了这样:40ms 原来这是 TCP 协议中的 Nagle‘s Algorithm 和 TCP Delayed Acknoledgement 共同起作 用所造成的结果。 Nagle’s Algorithm 是为了提高带宽利用率设计的算法,其做法是合并小的TCP 包为一个,避免了过多的小报文的 TCP 头所浪费的带宽。如果开启了这个算法 (默认),则协议栈会累积数据直到以下两个条件之一满足的时候才真正发送出去:



Search

Popular posts

Anything in here will be replaced on browsers that support the canvas element

Recent posts

This blog is maintained by 夏泽民

Get in touch with me at 465474307@qq.com

Subscribe to our mailing list

* indicates required