HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
25
This is the data in the first chunk
1C
and this is the second one
3
con
8
sequence
0
Google基于UDP推出的多路并发协议,可以取代TCP部分功能,实现SSL/TLS的所有功能,还可以取代部分HTTP/2的部分功能,优化了不丢包的算法性能,减小的RTT。从各种角度来看都比较优美,性能更高,不过用这个周边得有配套的设施,比较麻烦,听说youtube就采用了这个作为视频传输,降低了视频卡顿,国内B站视频网站也有落地,听说http3也要基于UDP,之前http3的全称叫HTTP over QUIC。就是建立在QUIC上的http协议。谁知道了,持续观望吧。
网络相关梳理
网络协议有很多,但是对于互联网用的最多的就是Http,https和TCP协议了。所以重点会梳理这方面的知识点。
HTTP 1.0
http的基本特点就是“一来一回”。就是Client发起一个TCP连接,在连接上面发一个http request到server,server返回一个http response,然后TCP连接关闭。
这样导致了性能问题,TCP连接的建立和关闭是耗时操作,一个请求一个连接太耗费资源。还有一个问题就是服务端不能主动推送消息。
当然,http 1.0有解决方案了,设计了一个Keep-Alive机制来实现TCP连接的复用,客户端根据需求选择性的在http request header加一个Connecion:Keep-Alive。Http Server收到这个字段在处理完成请求后不会主动关闭连接,同时在http的Response里也会加上该字段,等待客户端在该连接上发送下一个请求。
又因为连接复用的问题,怕把服务器连接耗光,所以会有一个Keep-Alive timeout参数,超时关闭连接。连接复用还会有一个问题,就是连接不关闭的情况下,Client如何知道某个Request对应Response完毕呢?答案是,http response的header返回了一个Content-Length:xxx 的字段表示响应了多少字节。
HTTP 1.1
连接复用与Chunk机制
因为连接复用的必要性,http 1.1标准直接默认复用了,你即使不加Keep-Alive,Server也不会主动关闭连接,除非你在Request header中显式加入Connection:Close,Server才会主动关闭连接。
上一小节说明了用Content-Length判断Response大小,但是这个有问题,如果server返回的内容是动态语言生成的内容,要计算该字段,对于服务器负荷略大,所以在http 1.1中引用了Chunk机制(Http Streaming)。具体来说就是,在Response的header中加入Transfer-Encoding:Chunked,目的是告诉client,Reponse body是分成了一块块的,块与块之间有间隔符,所有块的结尾也有特殊标记,这样即使没有Content-Length,Client也能方便判断response末尾。
25是第一块的字节数,1C是第二块的字节数,以此类推。0是response的结尾。可以看到,整个response body都被切分成chunk了。
Pipeline与Head-of-line Blocking问题
http 1.1还引入了pipeline机制,在同一个TCP连接上,可以在Request发出去以后,Response没有回来之前就发送下一个,再下一个的Request,提高在同一个TCP连接上的请求并发度。不然若是以前,还需要等待Request对应的Response回来才能继续发送下一个Request。
但是这里有个问题就是,队头阻塞(Head-of-line Blocking),意思就是如果Request是123的顺序发送到server的,那么server端也必须123的顺序回复response,client必须收到的顺序也是123,如果client收不到1,那么23的response会被阻塞。因为网络是异步并发的,很可能23和1不在一个TCP连接上,那么这种阻塞情况就会经常发生。所以,正因为如此,很多浏览器默认把Pipeline关闭了。
Http/2出现之前的问题
pipeline默认关闭,不能用,同一个TCP连接上的请求都是串行的,对于同一个域名,浏览器限制只能开6-8个连接,怎样提高性能?
HTTP/2
2009年Google发布了SPDY协议,是个实验性质的东西。想在协议层面解决http 1.1的效率问题,然后后来,http工作组汲取SPDY的经验,在此基础上定制了http/2协议。为啥不叫http 2.0?因为工作组认为协议完善,后面不会有小版本了。再后来,SPDY被Google抛弃,全面转HTTP/2。
与HTTP 1.1兼容
由于协议兼容和不改变结构,所以http/2和http 1.1不是平级位置,而是处于http 1.1和TCP的中间,就是以下协议栈:
二进制分帧
HTTP/2这个特性主要解决http 1.1中pipeline队头阻塞的问题。因为http 1.1是明文的字符文本格式,所以在发送到TCP之前,需要把字符格式转换为二进制,然后分成多个帧(多个数据块)来通过TCP send出去。
这里的帧被乱序并发地通过TCP发送出去和接收回来,没有了pipeline的限制,然后通过上层把帧组装成逻辑上的流,编上号码。这样http response就可以乱序返回。
当然,这个特性没有完全解决对头阻塞问题,只不过降低了一点可能性,仅仅只是把Request和Response细化到了帧的粒度。只要依赖于TCP,那么就会有队头阻塞问题。到后面会讲到Google的QUIC协议就是彻底解决队头阻塞问题的协议。
头部压缩
http 1.1里对于http的body,已经有相应的压缩了,尤其是对于图片,但是对于Header部分,一直都没有压缩,因为随着互联网发展,http header越来越大,header的压缩成为必要,HTTP/2专门设计了HPACK协议和对应算法。
SSL/TLS
主要是现在都是搞https了,https都是构建在SSL/TLS上的。最初由网景设计SSL 1.0,后来逐渐标准化,IETF对SSL标准化后叫TLS 1.0。TLS1.0相当于SSL 3.1, TLS 1.1, TLS 1.2相当于SSL 3.2,SSL 3.3。所以业界习惯两者并称为SSL/TLS。
协议栈是:
这里需要说到,对称加密,非对称加密,中间人攻击的东西,我暂时不说了。为了防止中间人攻击,就要想办法证明Server收到的public key的确就是client发出的,中间没有人可以篡改public key。所以需要提到数字证书的概念。
数字证书与SSL/TLS
有一种中间机构CA,类似于公证处(CA,Server都有自己的密钥对)。Server把自己的public key和个人信息发给CA,CA用自己的private key给Server生成一个数字证书(Cert),这个证书相当于Server的身份证,之后Server把自己的证书给Client,Client拿着CA的public key可以验证证书是否有效。
由于CA也可以冒充,所以CA会有一层层的信任链,CA有自己的上级CA,一直到顶级(root CA)。原理与之前的描述一样,反正CA也是服务器,一层层的数字证书组成的信任链。
Root CA证书一般浏览器,操作系统发布就内嵌在里面了,颁发证书的过程与验证过程是相反的,证书是网络上通信实体的身份证,并且这套体系也标准化了,就是所谓的PKI(Public Key Infrastructure)。
SSL/TLS协议通信
握手基本步骤,主要是为了协商对称秘钥
HTTPS
因为HTTPS = Http + SSL/TLS,所以流程就是:
TCP/UDP
可靠与不可靠
这里的可靠,不可靠算是TCP与UDP的区别之一,TCP的可靠的意思就是:
那么TCP的可靠是怎么解决的呢?
Client每发送一个数据包就给其编号,编号单调递增,基于编号顺序确认。
Server每收到一个包,就需要发送ACK给Client进行确认,意思就是反馈给CLient已经收到数据包了。不然,Client得重发。
比如,Server收到了数据包123,它只用回复ACK=3,意思就是小于等于3的数据包都收到了,过一会儿,Server又收到了456数据包,那么它只用回复ACK=6,意思就是小于等于6的数据包都收到了。
只要超时,Client没有收到Server发回来的ACK,Client就会重发,既然重发,网络又会抖动延迟,那么数据包就有可能重复。利用顺序ACK就可以做到重复包舍弃,Server给Client回复的ACK都记录在案,那么之后再收到ACK范围内的数据包就判定为重复包,丢弃就好了。
假设Server收到数据包123,回复Client ACK=3,之后收到数据包567,数据包4可能延迟了,迟迟没有收到,Server会把567数据包暂存,直到数据包4到来,再回复ACK=7,如果数据包4真没来,那么Server的ACK进度会一直保持在ACK=3,直到Client超时,会把4567全部重新发送,这时候人品好就会收到4567,回复ACK=7,这样就推进了ACK进度。并且也保证了顺序。
因为TCP是全双工的,所以对于Client回复ACK的情况也有,双方都可能回复ACK,或重发,原理一致。
TCP的这种思想朴素深刻,在分布式消息中间件里面的类似机制与这个思想差不多。
TCP的状态机相关
注意,这小节很重要,很多调试TCP网络的地方,会出现相关状态,这样好分析问题。特别是服务端开发,这些知识需要知道。
都知道TCP socket连接是一条上层的逻辑连接,用了不少机制保证可靠,每条连接都对应一个“状态机”,Client和Server都需要针对这条连接维护不同的状态迁移,在不同的状态下执行相应的操作。
上图的状态迁移图大概解释下,最开始Client(主动)和Server(被动)都处于CLOSED状态,连接建立完成后,双方都处于ESTABLISHED状态,开始传输数据;最后连接关闭,双方再次回到CLOSED状态。
TCP三次握手
TCP标志位:
第一次握手:Client将标志位SYN置为1,随机产生一个值seq=x,并将该数据包发送给Server,Client进入SYN_SENT状态,等待Server确认。
第二次握手:Server收到数据包后由标志位SYN=1知道Client请求建立连接,Server将标志位SYN和ACK都置为1,ack=x+1,随机产生一个值seq=y,并将该数据包发送给Client以确认连接请求,Server进入SYN_RCVD状态。
第三次握手:Client收到确认后,检查ack是否为x+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=y+1,并将该数据包发送给Server,Server检查ack是否为y+1,ACK是否为1,如果正确则连接建立成功,Client和Server进入ESTABLISHED状态,完成三次握手,随后Client与Server之间可以开始传输数据了。
注意,上面的ACK与之前的TCP可靠性的ACK有点不同,注意看描述。
TCP四次挥手
如果第一次,第二次握手之后,意味着连接处于半关闭状态,此时Client处于FIN_WAIT_2状态,Server处于CLOSE_WAIT状态,Client通往Server的通道关闭了,但是Server到Client的通道还没有关闭,需要等到第三次,第四次发生,连接才会完全处于CLOSE状态。
还有一种场景,Client和Server同时主动发起了关闭,双方都会处于FIN_WAIT_1状态,后面一起进入TIME_Wait状态,经过一段时间后进入CLOSE状态。为什么不直接进入CLOSE状态?
因为关闭连接是逻辑上的,如果直接进入CLOSE,那么网络上可能还有该连接“闲逛”的数据包,而连接还会再次打开,如果新打开的连接收到旧连接的数据包那是万万不行的,所以在TCP/IP网络上定义了一个叫做MSL(Maximum Segment Lifetime)的值,就是任何一个数据包在网络上存留的最大时间是MSL,这个值默认120秒,超过该时间,数据包自行被丢弃。有了这个限制,一个连接保持在TIME_WAIT状态会再等待2×MSL的时间才会进入CLOSE状态。
所以你看到了,关闭一个连接的代价挺高的,要等待一段时间后才能启用,所以主动关闭连接一般是Client关闭,Server不要主动关闭连接,不然会有一段时间的TIME_WAIT, 如果频繁关闭,Server会消耗完所有连接资源,所以:
QUIC协议
Google基于UDP推出的多路并发协议,可以取代TCP部分功能,实现SSL/TLS的所有功能,还可以取代部分HTTP/2的部分功能,优化了不丢包的算法性能,减小的RTT。从各种角度来看都比较优美,性能更高,不过用这个周边得有配套的设施,比较麻烦,听说youtube就采用了这个作为视频传输,降低了视频卡顿,国内B站视频网站也有落地,听说http3也要基于UDP,之前http3的全称叫HTTP over QUIC。就是建立在QUIC上的http协议。谁知道了,持续观望吧。