HTTP2简单教程

译自:http://qnimate.com/post-series/http2-complete-tutorial/

HTTP1.1是在1999年的时候被引入业界的。从当时到现在,WEB已经发生了相当大的变化。很多人开始用移动设备上网,有些移动环境下网络质量非常不稳定。另外,WEB页面的内容也相当的丰富了。这些都负面影响了WEB页面的加载时间。因此,需要一个新的协议来加速WEB的加载。

 

HTTP/2SPDY的区别:

SPDY是谷歌于2009年创造的协议,旨在WEB延迟以及增强安全性。

HTTP/2是SPDY的一个克隆。谷歌已经停止了继续开发SPDY,并且把工作转移到了HTTP/2上来。

 

HTTP/2的目标:

  1. 减少加载延时。
  2. 减少TCP连接数。
  3. 增强的网络安全。
  4. 保持和HTTP/1.1的兼容。

 

HTTP/2的功能:

  1. 多路复用Multiplexing:很多个异步的HTTP请求只使用一个TCP的连接。
  2. 服务端PUSH:对于一个请求可能有多个回复。
  3. 头部压缩:压缩头部(headers)。
  4. 请求分级:对同一个域名的请求可作优先级分级。
  5. 二进制协议:HTTP/2是一个二进制协议,而HTTP/1.1是一个文本协议。

 

HTTP/2解决了HTTP/1.1的哪些问题:

  1. HTTP管道(HTTP pipelining):一些HTTP1.1客户端使用了HTTP管道技术来减少TCP连接数。HTTP管道指的是多个HTTP请求被发往同一个TCP连接,而不等待前一个请求的回复。但是服务端发送回复时的顺序和收到的请求的顺序一样。因此,造成了HOL阻塞问题(head-of-line blocking)。HOL Blocking简单地说是一个回复的延迟会使得排在它后面的回复都会延迟。HTTP/2透过引用多路复用(Multiplexing)解决了这个问题。多个HTTP请求和多个HTTP回复都使用同一个TCP连续,而且HTTP回复的顺序不需要保持HTTP请求到达的顺序。
  2. 同一个域名的多个TCP连接:在使用HTTP/1.1时,需要对同一个域名起多个TCP连接来增加吞吐量。而使用HTTP/2时,对于每个域名,只充许有一个TCP连接(only one TCP connection per domain is allowed)。所有的请求和回复都通过唯一的一个TCP连接进行。
  3. TCP连接的关闭时间:使用HTTP1.1时,一个TCP连接在请求完成时立刻被关闭。但对于HTTP/2,TCP连接能存活相当成地一段时间。
  4. 头部压缩:HTTP/1.1是没有头部压缩的,但HTTP/2引入头部压缩进一步的减少了延时。

 

HTTP/2如何兼容HTT/1?

HTTP/2客户端在不确定对方服务器是否支持HTTP/2时,会用HTTP/1协议向服务器发送请求时带上Upgrade: HTTP/2.0这个头部。如果对方服务器支持HTTP/2,就会回复HTTP1.1 101,表示切换协议(Switching Protocols status)。而对于老旧的服务器则简单地返回HTTP/1.1的状态。

HTTP/2客户端可以记下哪些服务器支持HTTP/2,这样,下次就可以直接发起HTTP/2请求,而不必再经过一个询问和回复(Upgrade Round Trip).

 

HTTP/2中的多路复用是怎么回事?

HTTP/2使用多路复用,多个请求和回复全异步的通过同一个TCP连接收发。

HTTP/2是一个二进制的协议。每一个请求和回复都被分配了一个流标志(Stream ID),而且请求和回复被切成了很多帧(Frame),属于同一个请求或回复帧的Stream ID相同。因为有了这个Stream ID和Frame的机制,请求和回复可以在服务器和客户程序两端同时全异步的发送。因此,HTTP2没有了Head-of-line Blocking的问题。

每一个Stream还可以被赋于一个优先级,服务器可以分配更多的系统资源处理高优级的Stream。

HTTP/2还有一个传输层级别的流控。它协商了客户程序和服务器两端最多使用多少个Stream,服务器能处理的最大尺寸的Stream以及整个连接最多处理多少字节,以及数据被发送的速率。

 

HTTP/2中的服务器推送(Server Push)和承诺(Promise)

当服务器“感觉”到客户程序需要更多的资源时,就会给客户程序发送一个Promise Stream ,提醒客户程序需要什么资源。这些stream比一般的stream的优先级要高。

这项技术在加载网页时非常用户,因为网页的大量css和javascrpit可能通过这种方式发送。而HTTP/1的作法是把css和js都combine到一起。

服务器发送Promise Stream时提醒的资源遵守同源策略(same origin policy)

HTTP/2中的头部压缩:

HTTP/2的头部压缩和HTTP/1.1中早有的用gzip压缩Body不一样。使用HTTP/2时,在客户程序和服务器两端,都会保存一张表,记录了收到过的头部。它们在发送HTTP时不会重复发送一样的头部,当再次发送相同的头部时,只会发送该头部对应的表的索引号。

copyright blog.ykyi.net

Linux 如何知道有哪些硬件,该装哪个驱动

Linux 如何知道有哪些硬件,该装哪个驱动

公司明文不准安装虚拟机了,被查到就是死罪。于是我在自己的笔记本上安装了Debian Linux。

结果无线网卡识别不了~~

次奥~

怎么破呢?

这么破:

# lspci

该命令列出了所有PCI总线上的硬件设备,稍微看看就能看到自己的无线网卡了。

05:00.0 Network Controller: Atheros Communication Inc. AR9287 Wireless Network Adaptor (PCI-Express)(rev 01)

注意前面的坐标05:00.0,再到/sys下面找对应哪个驱动:

find /sys | grep drivers.*05:00.0

/sys/bus/pci/drivers/ath9k/0000:05:00.0

其实,还有更简单的办法:

#lspci -v 

就搞定了。

用lsmod 和 dmesg | grep ath9k 可以看到网卡对应模块的一些信息.

再编辑 /etc/network/interface

auto wlan0

iface wlan0 inet dhcp

wpa-ssid Tencent-FreeWiFi

wpa-psk xxxxxx

最后: iwconfig wlan up

搞定!!!

什么是0MQ或ØMQ,或ZeroMQ

ØMQ或者拼写成ZeroMQ,0MQ,是一个高性能异步消息队列库,旨在在分布式可扩展的并行程序中使用。它提供了一个消息队列,但不像面向消息的中间件,即使没有特定的消息经纪人(Message Broker),0MQ也能正常工作。

 

这个库在TCP的基础上开发,但能获得比TCP更高的性能,更不用说它提供了各种安全机制和分布式易扩展的特性。

 

0MQ的API和传统的socket很像。OMQ中的socket描述了一个,多个终端之间的多对多的连接。0MQ还有一个消息模式的概念。基本的0MQ消息模式有:

Request-reply:

用来连接一组客户端和一组服务。这个模式是一个远程过程调用RPC,和多任务分发模式。

Publish-subscribe:

用来连接一组发行端和一组接收端。这是一个数据分发模式。

Push-Pull(Pipeline)

用扇入/扇出模式连接很多结点,通常要分好几个步骤。这是一个多任务并行分布和收集的模式。

Exclusive Pair:

用排它模式连组两个socket。这其实是一个为特殊需求准备的高级底层模式。

 

每一种模式定义了一个对应的网络拓扑。Request-reply模式定义了所谓的”服务总线”,publish-subscribe定义了数据分发树,push-pull定义了并行管道。这样模式都被精心设计,使他们可以在互联网上被无限扩展。

 

不想译了,。更多内容见wikipedia。kamuszhou@qq.com 腾讯视频广告

copyright blog.ykyi.net

HTTP中的HEAD方法是什么

HTTP中的HEAD方法和GET方法是一样的,除了服务器在响应HEAD方法时不充许活加消息体(message body).服务器用来回复HEAD的响应信息中,在HTTP头部中的元信息需要跟回复GET时一样。这样,一个客户就可以通过HEAD来得到某资源的源信息,而不需要把整个资源都传输一次。

HEAD方法通常被用来测试超链接的可达,和资源是否已经更新。

HEAD方法的主要应用场景是检索资源的元信息meta infomation。用getResponseHeaders()函数可以得到HTTP的头部~

copyright blog.ykyi.net

昨天解决了tcpcopy的一个小却很重要的bug.

tcpcopy的基础函数有个bug,流量比较大的时候,内核buffer满了。send系统调用发不完用户缓冲中的数据才会出现。然后加入了tcpcopy的QQ群,和作者稍稍讨论了一点时间。问了关于写论文和tc_session.c过于复杂的问题。

(wangb) 10:00:55 
https://github.com//tcpcopy/pull/162
(wangb) 10:01:04 
The bug arises when send system call returns with part of data transfered
and part of data still need to be sent again.
(wangb) 10:01:13 
常见于压力比较大的场合
(wangb) 10:02:14 
当然如果系统参数设置好的话,这样的情况不常见。这也是为啥我这边无法重现的原因所在
(wangb) 10:02:46 
当然昨天在开发gryphon,貌似遇到过一次
(wangb) 10:03:06 
gryphon给的压力,有时候真不是一般快和大
siu1ooooooo(16236914) 10:03:14 
我在tcpcopy上作二次开发。碰到了个bug,最后追踪到了 tc_socket_send函数。
siu1ooooooo(16236914) 10:03:52 
流量比较大的时候,内核buffer满了。send系统调用发不完用户缓冲中的数据才会出现。
siu1ooooooo(16236914) 10:05:21 
希望能贡献更多代码的。。但是tc_session.c这个模拟tcp状态机的代码太难看懂了。
(wangb) 10:05:49 
有些bug,程序员自身很难发现,往往需要依赖于用户的反馈,当然有上面的bug提出,就更好了
tc_session.c这个模拟tcp状态机,其实不仅模拟tcp状态机,而为复杂的是模拟上层应用交互
光模拟tcp状态机,是远远不够的
siu1ooooooo(16236914) 10:07:27 
有个想法, 把TCP的11个标准状态加入到tc_session中。可不可以做的。.
(wangb) 10:09:13 
数据是死的,但测试服务器是活的。应该可以吧,但加入可能会更复杂。tc_session.c这个会进一步改进的,代码需简化和功能需独立,使其易懂
siu1ooooooo(16236914) 10:09:31 
🙂
(wangb) 10:10:33 
2010~2012.5月,初步探索阶段;2012.5~2014.5,为进一步探索阶段 2014.5~以后,进一步优化
因为tcpcopy刚开始,开发人员是无法知道复杂的互联网的各种应用的特性的,只有积累到一定程度,才能进一步优化。与其说是开发,不如说是探索
siu1ooooooo(16236914) 10:12:10 
期待工程paper  
siu1ooooooo(16236914) 10:12:43 
tcpcopy稳定到了一个版本。先别加功能了。写paper吧  
siu1ooooooo(16236914) 10:13:01 
投中EI应该问题不大。
siu1ooooooo(16236914) 10:13:55 
中了paper,贡献者会迅速增多。
wangb() 10:15:43 
其实写过sigcomm论文,但被拒,说应该投USENIX ATC
wangb() 10:16:18 
I don't think that the research contribution of the paper is a good match for Sigcomm. Perhaps it would be a better match for 
a more practice-oriented conference like USENIX ATC. 
siu1ooooooo(16236914) 10:16:50 
后来呢
wangb() 10:17:05 
确实,tcpcopy是基于实践的,从实践中摸索爬行的。后来我就先不写论文了
siu1ooooooo(16236914) 10:17:22 
嗯。这是个工程实践性很强的探索啊
wangb() 10:17:27 
要写论文,必须要有条件
siu1ooooooo(16236914) 10:17:45 
喔。
wangb() 10:18:06 
从交换机或者其它设备。镜像过来,这样测试系统和在线系统就没有关联,这样的论文是能够中USENIX ATC

wangb() 10:19:13 
tcpcopy最高端的应用,就是在交换机,利用分光镜或者其它镜像设备,利用高性能硬件,把用户的请求数据包复制给测试系统,可惜我没有这样的条件
wangb() 10:19:38 
要是有这样的条件,我肯定要写论文了
siu1ooooooo(16236914) 10:19:55 
呃。。没怎么看懂  
siu1ooooooo(16236914) 10:21:49 
是说复制的流量要非常非常大才能中论文么
siu1ooooooo(16236914) 10:21:59 
而非常大的流量需求硬件支持
wangb() 10:22:02 
twitter梦想的测试环境,其实完全可以用我们的tcpcopy来实现。交换机上面不是有来来往往的数据包吗?在那上面把请求数据包镜像到测试系统,测试系统搭一个跟在线类似的完整系统,这样测试系统跟在线系统承受类似的压力
wangb() 10:22:17 
高端大气,才能中论文
wangb() 10:22:48 
屌丝环境,写论文,还不被批啊
siu1ooooooo(16236914) 10:23:14 
呃。是 。。。明白了。。想起以前学校的事情,懂了。
wangb() 10:24:38 
总之,tcpcopy值得你去研究,期望有更多接班人把思想传承下去,代码可以推掉重来
wangb() 10:25:10 
只要tcp协议还存在,这个思想,应该是最先进的,无法再先进了
siu1ooooooo(16236914) 10:26:11 
需要好多的开发时间啊。..嗯。先上班了啊。多谢wangbin….
wangb() 10:27:16 
慢慢来,这方面反正国外没有人做

copyright blog.ykyi.net

tcpcopy在视频广告组的二次开发

1.

流量筛选中的 “只导入某频道的流量”功能已经实现了。

技术层面上,实际上是通过指定正则式的方法匹配HTTP请求中的GET方法中的URL来达到过滤的目的。

所以,也可以用ty,ad_type, pf, coverid, oadid, v,plugin等出现在GET方法中的参数编写正则式来过滤流量。

 

2.

流量筛选中的“地域纬度筛选”暂时没有实现。

因为地域纬度的信息不是以参数形式出现在GET方法的URL中,需要通过IP地址或者cookie的中QQ号信息来判断。

还没最终决定是否实现这个功能。

 

3.

tcpcopy官方版本主要的应用场景是复制实时流量。所以部署的时候至少两台机器,一台线上机,另一台测试用机。为了方便压力测试,还引入了至少三台机器的高级模式。

部署起来比较麻烦。

如果“视频CPM广告的模拟投放,以及订单效果预估“只是从磁盘中读入以往的流量,针对这种场景,可以探索tcpcopy的单机离线模式,做到方便部署和使用。

 

4. 部分同学有一个误解.

"将线上的实际访问流量,复制一份保存到本地服务器,用于后续使用"

目前,tcpcopy的官方的版本没有把流量保存下来的功能,保存流量这个目前是用tcpdump的-w选项来做的。

 

另外,技术上,tcpdump只能在IP层和TCP层指定过滤条件,不能用业务的逻辑过滤流量。第1点提到的流量筛选工作在tcpcopy读入实时流量时,或者从tcpdump存下的文件中读入流量时,在应用层指定过滤条件。

copyright blog.ykyi.net