http相关

HTTP各个版本

HTTP/0.9 :只接受GET一种请求方法,没有在通信中指定版本号,且不支持请求头。由于该版本不支持POST方法,因此客户端无法向服务器传递太多信息。

HTTP/1.0 :第一个在通信中指定的版本号,至今被广泛采用,特别是在代理服务器中。

HTTP/1.1 :当前版本号,持久连接被默认采用,并能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求,以便降低线路负载,提高传输速度。

HTTP2.0 :

HTTP1.0和HTTP1.1的一些区别

HTTP1.0最早在网页中使用是在1996年,那个时候只是使用一些较为简单的网页上和网络请求上,而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中,同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在:

  1. 缓存处理在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
  2. 带宽优化及网络连接的使用,HTTP1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1则在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。
  3. 错误通知的管理,在HTTP1.1中新增了24个错误状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。
  4. Host头处理,在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。
  5. 长连接,HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟,在HTTP1.1中默认开启Connection: keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。以下是常见的HTTP1.0:

http相关


HTTP请求流程

http相关


解析域名(HOST/DNS)

  • 一个域名 会首先访问本地的Host文件,查看有没有域名对应的访问ip的映射
  • 如果有,就直接得到IP,如果没有,就通过DNS根服务器,
  • DNS根服务器会询问.net域名服务器,有没有此域名
  • net域名服务器会查找blog.****.net是否存在
  • 如果存在,就返回相应的IP地址
  • ARP协议解析ip对应的物理地址,并加入到ARP缓存
  • 进行TCP握手

三次握手

相互请求,相互确认的过程.

就像长途运货车
你和总部说,我想运货,
然后总部收到你的短信,给你回信说:恩,收到,去吧
你说,收到,马上去.

在此先设定

SYN1表示客户端的同步信号,ACK1表示客户端的确认信号,FIN1表示客户端对服务器信道停止信号

SYN2表示服务器的同步信号,ACK2表示服务器的确认信号,FIN2表示服务器对客户端信道停止信号

SYN根据ACK的相应而变化.使用确认号1响应服务端的***0

***代表发送的数据编号,确认序列代表收到的数据编号.

***和确认序列在握手的时候发送的时候都会自动+1(说的不太恰当);

***为当前端成功发送的数据位数,确认号为当前端成功接收的数据位数,SYN标志位和FIN标志位也要占1位

第一次:

客户端发起请求(发送SYN1=1,ACK1=0)到服务器,此时,服务器进入'SYN_SENT'(客户端已经提交SYN报文)状态,等待服务器响应.

第二次:

服务器收到SYN包,确认客户端的SYN包而生成ACK(ACK=j+1)包,还有自己的一个请求编号SYN
(SYN=k), 即发送SYN+ACK包(发送SYN2=0,ACK2=1)到客户端.此时,服务器进入'SYN_RECV'状态.

第三次:

客户端收到服务器的SYN+ACK包,然后,自己向服务器发送确认包ACK(发送SYN1=0+1,ACK1=0+1=1),此时,服务器进入'ESTABLISHED'(链接成功)状态,完成三次握手
(连接完成状态表示为SYN1=1,ACK1=1,SYN2=1,ACK2=1).

数据传输过程

第四次(客户端请求服务器发出的有效数据包)

这是流中第一个携带有效数据的包(确切的说,是客户端发送的HTTP请求),***依然为1,因为到上个包为止,还没有发送任何数据,确认号也保持1不变,因为客户端没有从服务端接收到任何数据

需要注意的是,包中有效数据的长度为125字节,但是一共有125+1个数据,因为***也占用字节.

服务端的***为1.确认号为1,TCP客户端的***为126.确认号为1

第五次(服务器得到包,并处理得到的数据)

当上层处理HTTP请求时,服务端发送该包来确认客户端在包4中发来的数据,需要注意的是,确认号的值增加了125(125是包4中有效数据长度),变为126,
服务端以此来告知客户端端,目前为止,我总共收到了126字节的数据,服务端的***保持为1不变

服务端的***为1.确认号为126,TCP客户端的***仍为126.确认号为1

第六次(服务器发出数据包)

这个包标志着服务端返回HTTP响应的开始,***依然为1,因为服务端在该包之前返回的包中都不带有有效数据,该包带有512字节的有效数据.

服务端的***为513.确认号为126,TCP客户端的***仍为126.确认号为1

第七次(客户端接受数据包)

客户端接收到数据.到此为止,一次tcp的短连接,一次网络请求完成().
当tcp进行长链接的时候,会不断地相互增长.
服务端的***为513.确认号为126,TCP客户端的***仍为126.确认号为1+513=514

连接终止协议(四次挥手)

第一次:

TCP的客户端发送一个FIN(FIN=1),用来关闭客户到服务器的数据传输.

此时,将标志位FIN1=1.

服务端的***为513.确认号为126,TCP客户端的***仍为126+1.确认号为514

第二次:

服务器收到这个FIN,它发出一个ACK2=1,确认序号为收到的序号加1。和SYN一样,一个FIN将占用一个序号。

此时,FIN1=1,ACK2=1,通道1关闭,服务器确定

服务端的***为513.确认号为126+1=127,TCP客户端的***仍为126.确认号为514

第三次:

服务器关闭客户端连接,发一个FIN2=1的标志位给客户端,

此时,将标志位FIN1=1,FIN2=1.ACK2=1,通道1,2关闭,服务器确定

服务端的***为513.确认号为126+1=127,TCP客户端的***仍为126.确认号为514

第四次:

客户端发回ACK1=1报文确认,并将确认序号设置为收到序号加1。

此时,FIN1=1,ACK2=1,ACK1=1,ACK2=1,通道1,2关闭,客户端确认,服务端确认.连接关闭

服务端的***为513.确认号为126+1+1=128,TCP客户端的***为126+1=127 

http相关

HTTP1.0和1.1现存的一些问题

  1. 上面提到过的,HTTP1.x在传输数据时,每次都需要重新建立连接,无疑增加了大量的延迟时间,特别是在移动端更为突出。
  2.  HTTP1.x在传输数据时,所有传输的内容都是明文,客户端和服务器端都无法验证对方的身份,这在一定程度上无法保证数据的安全性。
  3.  HTTP1.x在使用时,header里携带的内容过大,在一定程度上增加了传输的成本,并且每次请求header基本不怎么变化,尤其在移动端增加用户流量。
  4.  虽然HTTP1.x支持了keep-alive,来弥补多次创建连接产生的延迟,但是keep-alive使用多了同样会给服务端带来大量的性能压力,并且对于单个文件被不断请求的服务(例如图片存放网站),keep-alive可能会极大的影响性能,因为它在文件被请求之后还保持了不必要的连接很长时间。


HTTP的基本优化

影响一个HTTP网络请求的因素主要有两个:带宽和延迟。

  • 带宽:如果说我们还停留在拨号上网的阶段,带宽可能会成为一个比较严重影响请求的问题,但是现在网络基础建设已经使得带宽得到极大的提升,我们不再会担心由带宽而影响网速,那么就只剩下延迟了。
  • 延迟:
  1. 浏览器阻塞(HOL blocking):浏览器会因为一些原因阻塞请求。浏览器对于同一个域名,同时只能有 4 个连接(这个根据浏览器内核不同可能会有所差异),超过浏览器最大连接数限制,后续请求就会被阻塞。
  2.  DNS 查询(DNS Lookup):浏览器需要知道目标服务器的 IP 才能建立连接。将域名解析为 IP 的这个系统就是 DNS。这个通常可以利用DNS缓存结果来达到减少这个时间的目的。
  3.  建立连接(Initial connection):HTTP 是基于 TCP 协议的,浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文,达到真正的建立连接,但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显,慢启动则对文件类大请求影响较大。


为了解决以上问题,网景在1994年创建了HTTPS,并应用在网景导航者浏览器中。 最初,HTTPS是与SSL一起使用的;在SSL逐渐演变到TLS时(其实两个是一个东西,只是名字不同而已),最新的HTTPS也由在2000年五月公布的RFC 2818正式确定下来。简单来说,HTTPS就是安全版的HTTP,并且由于当今时代对安全性要求更高,chrome和firefox都大力支持网站使用HTTPS,苹果也在ios 10系统中强制app使用HTTPS来传输数据,由此可见HTTPS势在必行。

HTTPS

HTTPS其实是有两部分组成:HTTP + SSL / TLS,也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密,所以传输的数据都是加密后的数据。具体是如何进行加密,解密,验证的,且看下图。

 http相关


     1. 客户端发起请求

     这个没什么好说的,就是用户在浏览器里输入一个https网址,然后连接到server的443端口。

     2. 服务端的配置

     采用HTTPS协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择,有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解,可以想象成一把钥匙和一个锁头,只是全世界只有你一个人有这把钥匙,你可以把锁头给别人,别人可以用这个锁把重要的东西锁起来,然后发给你,因为只有你一个人有这把钥匙,所以只有你才能看到被这把锁锁起来的东西。

  3. 传送证书

  这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间等等。

  4. 客户端解析证书

  这部分工作是有客户端的TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警告框,提示证书存在问题。如果证书没有问题,那么就生成一个随机值。然后用证书对该随机值进行加密。就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,不然看不到被锁住的内容。

  5. 传送加密信息

  这部分传送的是用证书加密后的随机值,目的就是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

  6. 服务段解密信息

  服务端用私钥解密后,得到了客户端传过来的随机值(私钥),然后把内容通过该值进行对称加密。所谓对称加密就是,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全。

  7. 传输加密后的信息

  这部分信息是服务段用私钥加密后的信息,可以在客户端被还原。

  8. 客户端解密信息

  客户端用之前生成的私钥解密服务段传过来的信息,于是获取了解密后的内容。整个过程第三方即使监听到了数据,也束手无策。


HTTPS与HTTP的区别

  1. HTTPS协议需要到CA申请证书,一般免费证书很少,需要交费。
  2. HTTP协议运行在TCP之上,所有传输的内容都是明文,HTTPS运行在SSL/TLS之上,SSL/TLS运行在TCP之上,所有传输的内容都经过加密的。
  3. HTTP和HTTPS使用的是完全不同的连接方式,用的端口也不一样,http端口80,https端口443。
  4. HTTPS可以有效的防止运营商劫持,解决了防劫持的一个大问题。

HTTPS改造

如果一个网站要全站由HTTP替换成HTTPS,可能需要关注以下几点:

  1. 安装CA证书,一般的证书都是需要收费的,这边推荐一个比较好的购买证书网站:1)Let’s Encrypt,免费,快捷,支持多域名(不是通配符),三条命令即时签署+导出证书。缺点是暂时只有三个月有效期,到期需续签。2Comodo PositiveSSL,收费,但是比较稳定。
  2. 在购买证书之后,在证书提供的网站上配置自己的域名,将证书下载下来之后,配置自己的web服务器,同时进行代码改造。
  3. HTTPS 降低用户访问速度。SSL握手,HTTPS 对速度会有一定程度的降低,但是只要经过合理优化和部署,HTTPS 对速度的影响完全可以接受。在很多场景下,HTTPS 速度完全不逊于 HTTP,如果使用 SPDY,HTTPS 的速度甚至还要比 HTTP 快。
  4. 相对于HTTPS降低访问速度,其实更需要关心的是服务器端的CPU压力,HTTPS中大量的**算法计算,会消耗大量的CPU资源,只有足够的优化,HTTPS 的机器成本才不会明显增加。

推荐一则淘宝网改造HTTPS的文章。

 

使用SPDY加快你的网站速度

2012年google如一声惊雷提出了SPDY的方案,大家才开始从正面看待和解决老版本HTTP协议本身的问题,SPDY可以说是综合了HTTPS和HTTP两者有点于一体的传输协议,主要解决:

  1. 降低延迟,针对HTTP高延迟的问题,SPDY优雅的采取了多路复用(multiplexing)。多路复用通过多个请求stream共享一个tcp连接的方式,解决了HOL blocking的问题,降低了延迟同时提高了带宽的利用率。
  2. 请求优先级(request prioritization)。多路复用带来一个新的问题是,在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级,这样重要的请求就会优先得到响应。比如浏览器加载首页,首页的html内容应该优先展示,之后才是各种静态资源文件,脚本文件等加载,这样可以保证用户能第一时间看到网页内容。
  3. header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
  4. 基于HTTPS的加密协议传输,大大提高了传输数据的可靠性。
  5. 服务端推送(server push),采用了SPDY的网页,例如我的网页有一个sytle.css的请求,在客户端收到sytle.css数据的同时,服务端会将sytle.js的文件推送给客户端,当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到,不用再发请求了。SPDY构成图:

SPDY位于HTTP之下,TCP和SSL之上,这样可以轻松兼容老版本的HTTP协议(将HTTP1.x的内容封装成一种新的frame格式),同时可以使用已有的SSL功能。

兼容性:

HTTP2.0

顾名思义有了HTTP1.x,那么HTTP2.0也就顺理成章的出现了。HTTP2.0可以说是SPDY的升级版(其实原本也是基于SPDY设计的),但是,HTTP2.0 跟 SPDY 仍有不同的地方,主要是以下两点:

  • HTTP2.0 支持明文 HTTP 传输,而 SPDY 强制使用 HTTPS
  • HTTP2.0 消息头的压缩算法采用 HPACK,而非 SPDY 采用的 DEFLATE

 

11. HTTP2.0的新特性

  • 新的二进制格式(Binary Format),HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷,文本的表现形式有多样性,要做到健壮性考虑的场景必然很多,二进制则不同,只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式,实现方便且健壮。
  • 多路复用(MultiPlexing),即连接共享,即每一个request都是是用作连接共享机制的。一个request对应一个id,这样一个连接上可以有多个request,每个连接的request可以随机的混杂在一起,接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。多路复用原理图
  • header压缩如上文中所言,对前面提到过HTTP1.x的header带有大量信息,而且每次都要重复发送,HTTP2.0使用encoder来减少需要传输的header大小,通讯双方各自cache一份header fields表,既避免了重复header的传输,又减小了需要传输的大小。
  • 服务端推送(server push),同SPDY一样,HTTP2.0也具有server push功能。目前,有大多数网站已经启用HTTP2.0,例如YouTuBe淘宝网等网站,利用chrome控制台可以查看是否启用H2:

更多关于HTTP2的问题可以参考:HTTP2奇妙日常,以及HTTP2.0的官方网站

关于HTTP2和HTTP1.x的区别大致可以看下图:

 

12. HTTP2.0的升级改造

对比HTTPS的升级改造,HTTP2.0或许会稍微简单一些,你可能需要关注以下问题:

  1. 前文说了HTTP2.0其实可以支持非HTTPS的,但是现在主流的浏览器像chrome,firefox表示还是只支持基于 TLS 部署的HTTP2.0协议,所以要想升级成HTTP2.0还是先升级HTTPS为好。
  2. 当你的网站已经升级HTTPS之后,那么升级HTTP2.0就简单很多,如果你使用NGINX,只要在配置文件中启动相应的协议就可以了,可以参考NGINX白皮书NGINX配置HTTP2.0官方指南
  3. 使用了HTTP2.0那么,原本的HTTP1.x怎么办,这个问题其实不用担心,HTTP2.0完全兼容HTTP1.x的语义,对于不支持HTTP2.0的浏览器,NGINX会自动向下兼容的。

参考:

腾讯全端AlloyTeam团队blog

http://www.jb51.net/network/68135.html

一次http请求的背后