面试引发的有关TCP & HTTP2协议的思考
2018-04-19 本文已影响187人
HotCatLx
Ⅰ-Introduce
- 先来讲讲这篇文章的诱因,一个安卓开发朋友去面试,有了下面的对话:
- 面试官:"一个界面有十个请求,那么十个请求建立了几次连接?"
- 朋友:"巴拉巴拉......"
- 面试官:"切!只有一个,菜!"
- 朋友:"嗯...",此时内心OS:"TM为啥只有一个,我不服,这摆明为难我!!!"
-
(一场面试愉快的结束了...)
os like this.JPG
- 个人认为:不讲场景,不基于协议讨论这个问题就是耍流氓,摆明不想真招人!!!
- 我听到了这个问题后就想自己在学习了解下为什么只有一次,当然我内心是想证明面试官是错的
- 分析一波文章写的时候的心路历程 : TCP > HTTP 1.0 & HTTP 1.1 > HTTP 2.0 > 得出结论
- 结论在最后,也可以直接看结论!!!!
- 如果我理解的哪里有错误,请一定告诉我,阿里嘎多~
Ⅱ-TCP协议
1 简介
-
各个协议的作用和关系
- 以太网(Ethernet)协议:解决局域网内点对点通信
- IP协议: 解决多个局域网之间的通信
- TCP协议: TCP 是以太网协议和IP协议的上层协议,也是应用层协议的下层协议
- TCP 协议: 保证数据通信的完整性和可靠性,防止丢包。IP协议只是一个地址协议,并不保证数据包的完整。如果路由器丢包(比如缓存满了,新进来的数据包就会丢失),就需要发现丢了哪一个包,以及如何重新发送这个包.这就要依靠TCP协议。
2 数据包
-
TCP数据包
- 以太网数据包(packet)的大小是固定的,从1518字节,增加到1522字节。22字节是以太网头信息(head),其中1500 字节是负载(payload).
- IP数据包在以太网数据包的payload中,他也有自己的头信息,也是20字节,所以IP数据包的负载为1480字节
- TCP数据包又在IP数据包的payload中,20字节的头信息,实际负载只有1460字节,另外IP&TCP协议往往有额外的头信息,所以TCP负载实际为1400字节左右。
-
所以一个packet头信息就要占100多字节,如果是条1500字节的信息,那就不得不分成两个packet,所以压缩头信息,提高传输速度成为HTTP/2协议的重点需要改进的点
-
TCP数据包编号:SEQ
- 一个超过1400字节的数据,必须拆成多个包进行传输数据,那么就需要把拆开的数据包再组合起来,那么数据包编号(SEQ)也就有作用了,既能将传输的数据按照一定的顺序组装起来,又能确定丢包丢的是哪个包
- 规则:
* 第一个包的编号是随机的,假设是0号包,第一个包内存储的字节是100字节
* 那么第二个包的编号就是100
* 也可以由第二个包的编号和第一个包的编号确定第一个包内包含的数据负载是多少
-
数据包组装
- 数据包的组装不由应用程序完成,有操作系统完成,操作系统将数据包组装好再给应用程序使用,TCP数据包里有个port参数,数据包完成组装,操作系统根据端口信息,将packet转交给监听特定端口号的应用程序
- 应用程序收到组装好的原始数据,以浏览器为例,就会根据 HTTP 协议的Content-Length字段正确读出一段段的数据。这也意味着,一次 TCP通信可以包括多个HTTP通信
3 数据传输和丢包处理
- 大致知道了数据包的组装过程和组成,那么问题就是一次服务器发送数据包一次发多少,发多少有什么决定这个问题
-
一次发送多少个数据包?
- 当然是发送数据包越快越好,但是宽带小,路由器过热等等导致的可同时传输的数据包在一定时间是一定的,这时候再发送超过可发送上线的数据包就会导致丢包
- 最理想状态,在线路允许情况下,达到传输速度最大化
- TCP协议设计了一个慢启动机制,既开始发送较慢,根据丢包情况决定传输速率,不丢包增加传输速度,丢包就降低传输速度,那么传输多少个包的问题就得到了解决
- Linux 设定刚开始通信的时候,发送方第一次发送10个数据包,然后等待接收方的确认,默认接收方每收到2个数据包,就发送一个确认消息(ACK)
Ⅲ-HTTP 1.0 & HTTP 1.1
1.HTTP(超文本传输协议)简介
-
真的只是简介,是我就跳过了
-
特点
- HTTP 协议简单,使得 HTTP服务器的程序规模小,因而通信速度很快
- HTTP 允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记
- 无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间
-
组成
- HTTP协议:一个基于请求与响应模式的、无状态的、应用层的协议,常基于TCP的连接方式
2.HTTPの请求
- HTTP请求由三部分组成
- 请求行
- 消息报头
- 请求正文
-
请求行
- 请求行以一个方法符号开头,以空格分开,后面跟着请求的 URI 和协议的版本,格式如下:Method Request-URI(统一资源标识符,既URL) HTTP-Version CRLF(表示回车和换行)
- 请求方法-Method
* GET & POST (我也就只用过这两个....)
* HEAD作用: 只请求资源的首部/检查超链接的有效性/检查网页是否被修改
* PUT:请求服务器存储一个资源
* DELETE 请求服务器删除一个资源
* TRACE 请求服务器回送收到的请求消息,主要用于测试或者诊断
* CONNECT (Keep-Alive)
* OPTIONS 请求查询服务区的性能,查询与资源相关的选项和需求
3.HTTPの响应
- HTTP响应也是由三个部分组成,分别是:状态行、消息报头、响应正文
- 状态行
- 格式: HTTP-Version Status-Code Reason-Phrase(表示状态代码的文本描述) CRLF
- status-code
* 200 OK //客户端请求成功
* 400 Bad Request //客户端请求有语法错误,不能被服务器所理解
* 401 Unauthorized //请求未经授权,这个状态代码必须和
WWW-Authenticate 一起使用
* 403 Forbidden //服务器收到请求,但是拒绝提供服务
* 404 Not Found //请求资源不存在,eg:输入了错误的 URL
* 500 Internal Server Error //服务器发生不可预期的错误
* 503 Server Unavailable//服务器当前不能处理客户端的请求,一段时间后,//可能恢复正常
- 消息报头
* Accept:用于指定客户端接受哪些类型的信息
* Accept-Charset 请求报头域用于指定客户端接受的字符集 (未设置,则是任何字符集都可接受)
* Accept-Encoding 可接受的内容编码,没有服务器假定客户端对各种内容编 码都可以接受
* Accept-Language
* Authorization 当浏览器访问一个页面时 ,如 果收到服务器的响应代码为 401(未授权),可以发送一个包含 Authorization,要求服务器对其进行验证。
* Host(必需)
* User-Agent
4.补充
- 高层协议
- 文件传输协议 FTP
- 电子邮件传输协议 SMTP
- 域名系统服务 DNS
- 网络新闻传输协议NNTP
Ⅳ-HTTP 2.0
- 重点来了,打起精神来
1. HTTP 2.0 需要解决什么问题
1. 相对于使用 TCP 的HTTP1.1,用户在大多数情况下的感知延迟要有实质上、可度量的改进;
2. 解决 HTTP 中的“队首阻塞”问题;
> 队首阻塞会在下面的HTTP Pipelining解释
3. 并行操作无需与服务器建立多个连接,从而改进TCP的利用率,特别是拥塞控制方面;
4. 保持 HTTP 1.1 的语义,利用现有文档,包括(但不限于)HTTP 方法、状态码、URI,以及首部字段(既向下兼容)
5. 解决突破HTTP1.0 & HTTP1.1 的性能限制,改进传输性能,实现低延迟和高吞吐量
2.主要改变
- 通过支持首部字段压缩和在同一连接上发送多个并发消息,让应用更有效地利用网络资源,减少感知的延迟时间。而且,它还支持服务器到客户端的主动推送机制
3.二进制分帧数据层
- 作用:封装HTTP消息,并在客户端与服务器之间传输,将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码
- 组成:帧 & 消息 & 流
1. 组成:流既通道,通道内双向传输消息,消息由帧组成
2. 流:连接中的一个虚拟信道,可以承载双向的消息;每个流都有一个唯一的整数标识符(1、2…n)
3. 消息:是指逻辑上的HTTP消息,比如请求、响应等,由一或多个帧组成
4. 帧:HTTP 2.0 通信的最小单位,每个帧包含帧首部,至少也会标识出当前帧所属的流,承载着特定类型的数据,如HTTP的header 负荷等等,**所有首部数据都会被压缩**
- 二进制分帧层实现了多项请求和响应,可以把消息分级为互不依赖的帧,乱序发送
1. 可以并行交错地发送请求,请求之间互不影响;
2. 可以并行交错地发送响应,响应之间互不干扰;
3. 只使用一个连接即可并行发送多个请求和响应;
4. 消除不必要的延迟,从而减少页面加载的时间;
5. 不必再为绕过 HTTP 1.x 限制而多做很多工作
- 作用
- HTTP 2.0 的二进制分帧机制解决了HTTP1.x中存在的队首阻塞问题,也消除了并行处理和发送请求及响应时对多个连接的依赖。
- 有了新的分帧机制后,HTTP 2.0不再依赖多个TCP连接去实现多流并行了。每个数据流都拆分成很多帧,而这些帧可以交错,还可以分别优先级。HTTP2.0连接都是持久化的,而且客户端与服务器之间也只需要一个连接即可。
- 大多数HTTP 连接的时间都很短,而且是突发性的,但TCP 只在长时间连接传输大块数据时效率才最高。HTTP 2.0 通过让所有数据流共用同一个连接,可以更有效地使用TCP 连接。
4.服务器推送
- HTTP 2.0 新增的一个强大的新功能,就是服务器可以对一个客户端请求发送多个响应。服务器向客户端推送资源无需客户端明确地请求
5.HTTP Pipelining
- HTTP Pipelining:其实是把多个HTTP请求放到一个TCP连接中一一发送,而在发送过程中不需要等待服务器对前一个请求的响应;只不过,客户端还是要按照发送请求的顺序来接收响应。但就像在超市收银台或者银行柜台排队时一样,你并不知道前面的顾客是干脆利索的还是会跟收银员/柜员磨蹭到世界末日(译者注:不管怎么说,服务器(即收银员/柜员)是要按照顺序处理请求的,如果前一个请求非常耗时(顾客磨蹭),那么后续请求都会受到影响),这就是所谓的队首阻塞(Head of line blocking)。
V-结论
- 如果面试官问的问题是基于TCP协议,那么我认为:多次请求是可以保持一次连接的,因为每次创建新的TCP连接很占资源和性能
- 如果面试官问的问题是基于HTTP1.x协议,那么如果在设置connection:keep-alive的前提下,是存在多次请求保持一次连接的,但针对同一域名的请求有一定的数量限制(maxKeepAliveRequests),超过限制的请求会被阻塞,我觉得多次请求保持一次连接是不能保证的,且存在系统资源无效占用等问题,还要设置connectionTimeout最大间隔时间,如果超过最大时间间隔,连接会被关闭,所以在不设置的前提下,只有一次连接我是不服气的
- 如果面试官问的问题是基于HTTP2协议,那呢我认为:是一次连接的,二进制分帧层解决了双向并行交错地发送请求和响应,而且优化延迟也是通过减少创建TCP连接而设计的
so,这个面试官给的肯定回答也只是五五开喽!!!(卢姥爷曾经而是体面人~)
Ⅵ 参考文档
- TCP
- HTTP 2.0