梳理TCP,HTTP,HTTPS,HTTP/2

对一些面试之中可能考察的知识点做一点复习

Posted by Haiming on March 21, 2019

本文对于Web岗面试之中关于网络的各种问题进行了一点整理,欢迎大家讨论。

1. TCP

1.1 TCP的三次握手

转载至TCP 三次握手四次挥手

在我看来,TCP的各种机制设计都是因为网络报文传输的不确定性(延迟了, 丢包了,网线断了 etc),因此看似繁琐的报文重复传输和字段的重复包括(每一个都有ACK)是牺牲了部分的传输效率来保证其是一个可靠的文件传输协议。在看的时候处处感叹,真的是每一个步骤都考虑到了网络不稳定需要重传的状况。

又看到一段话:三次握手是满足”在不可靠信道上传输可靠信息“的最小值。很有趣。

1.1.1 为什么要三次握手

三次握手是保证双方都知晓对方同意连接的最小次数。可以看成每个客户端都有一个flag标识对方是否同意连接,其一开始都是False。

在客户端A发送SYN报文之时,两边的flag都是false,然后在其客户端B接收到报文之后,其会将SYN ACK 传输给客户端A ,在传输报文这一刻也还是两边的flag都是false, 然后在A收到报文时,客户端A上面对于客户端B的flag会变成True,此时客户端A发送ACK给客户端B,告诉B客户端A已经知道客户端B的SYN ACK,之后在B接受到ACK之后,B上面对于客户端A的flag会变成True。

此时双方关于对方的状态都已经知晓,接下来开始传输数据,也标志着连接的建立。 在以后的每一个包中都含有ACK字段

1.1.2 如果没有第三次握手怎么样?会出现什么问题?

本人对网络上面的“防止失效报文被Server端接收进而开启另一进程导致浪费”的说法不太赞同。下面是觉得合理的解释:

每次在发送报文,无论是SYN报文还是ACK报文的时候,都会带上序列号,而其其实是这样的情况:

Client给Server发送SYN X(X和Y是序列号),Server回复ACK X,SYN Y,此时只可以证明两边都知晓从Client端发送到Server端的信息可以以X开头,但是从Server端到Client端的信息双方并没有达成一致(因为Client没有回复),所以三次握手之中的ACK Y 才被需要。

1.2 TCP的四次挥手

1.2.1 TCP的四次挥手怎么实现?

  1. 首先Client端给Server端发送FIN ACK,Server回复ACK告知其已收到
  2. Server 端返回一个ACk,在此之后Client 不可以继续传输数据(因为已经传输结束)
  3. 在Server的close-wait之后,Server会发送FIN ACK回去给CLient,说明服务器端的内容已经传输完毕
  4. Client在收到Server的FIN ACK 之后,给Server返回ACK,此时进入TIME-WAIT状态,要等待2个MSL(Maximum Segment Lifetime)(报文最大生存时间)之后释放连接
  5. B收到ACK之后释放连接

1.2.2 为什么一定要等待最后的2MSL?

原因是

  1. 防止第四次挥手(从Client到Server传输ACK的过程)没有被对方收到。如果没有被收到,那么Server端会发出重传FIN,等待一段时间是为了将这种情况处理好
  2. 等待的这一段时间可以让所有本次传输的报文在网络之中消失,使得下一次的SYN不会与此次的报文重叠,从而重复打开本已经要关闭的连接

2.HTTP , HTTP2/和HTTPS

2.1 什么是HTTP?

HTTP是一种能够获取如 HTML 这样的网络资源的 protocol(通讯协议).

一份完整的Web文档通常是不同的子文档拼接成的,比如image图片从一个server拿取,广告从Ad server拿取等等。

TCP是HTTP的底层,而HTTP是诸如HTML,CSS,JavaScript的底层。HTTP是一个应用层协议,是承载内容资源的协议。

2.2 基于HTML的组件系统

直接看mozilla的教程就OK。

教程将其分为了三个部分,一是Client,一是Proxy,一是Server。

2.2.1 Client

要展示一个完整的网页,Browser首先发送一个请求获取HTML页面文档。在获得文档之后,才会获取CSS脚本或者其他样式来做页面渲染,再去获取一些其他资源,比如图片和视频等等。在完成这些步骤之后,浏览器才会显示一个完整的网页。

这也就是为什么如果网络不好的话网页的内容也可以显示出来,但是图片或者视频或者样式显示不出来的原因:只执行了第一步。

2.2.2 Proxy

本来在Client和Server之间,HTTP消息会经过很多台机器。如果我们让一个机器作为转发实体,即将流量通过他们,就可以将其当作Proxy。Proxy可能会有下面的作用:

  • 缓存(可以是公开的也可以是私有的,像浏览器的缓存)
  • 过滤(像反病毒扫描,家长控制…)
  • 负载均衡(让多个服务器服务不同的请求)
  • 认证(对不同资源进行权限管理)
  • 日志记录(允许存储历史信息)

2.2.3 Server

Server是用来提供资源的机器,其只是一个意义上的机器,并不一定是某个固定的实体。

2.3 HTTP的基本性质

2.3.1 无状态性

在同一个连接之中,两个执行成功的请求之间是没有关系的。这就造成了用户在几个页面之间无法实现有关联的跳转。为了解决这种情况,带给用户无缝的体验,我们使用HTTP Cookies来解决这个问题。

将HTTP的Cookies添加到头部当中,这样创建一个会话就可以请求共享相同的上下文信息,这样就可以达成一个相同状态的转换。

总的来说,HTTP是无状态的,但是使用Cookies可以创建有状态的会话。

(具体来说cookie机制采用的是在客户端保持状态的方案,而session机制采用的是在服务器端保持状态的方案。)

2.4 HTTP/2

首先说一下HTTP/1.1的不足之处:

  1. 对于同一个域名,浏览器同时只可以建立六到八个链接(RFC之中甚至建议每个域名建立两个链接),这个数字随着浏览器不同而变化,但是总体就是这样。例如我有一百个资源想要从同一个域名获取,那么我就要等待(100/8=12.5)次之后才可以将所有资源获取到。
    • 为什么建议这样?首先是为了服务器端考虑,如果有一百个需求就开一百个TCP连接的话,n个用户就是100*n的这么一个数量,会显著增加服务器的压力。其次,由于TCP的慢启动和拥塞窗口等等,多个TCP的性能不一定就能带来优势。
    • 为什么不能把100个需求放在一个TCP连接之中?如果TCP的等待时间是T1,那么如果第99个包丢了,所有资源,也就是整个页面要等待T1时间之后才可以显示。但是如果是100个TCP连接,那么前面98个资源都可以先显示给用户。
    • 目前的妥协解决方案是开多个域名,但是TCP建立的过程也需要经过DNS查询,三次握手等等,都需要时间。
  2. 需要按序处理请求。如果在处理的过程之中,发现某个请求处理的时间特别长,也没有办法先保存状态跳过它来处理其他请求。

HTTP/2 的不同点:

2.4.1 二进制协议

HTTP/1.1 之中, 头信息是ASCII编码的文本,而HTTP/2之中不论头信息还是数据本体都是彻底的二进制协议,且统称为“帧”(frame):头信息帧和数据帧 其好处是可以定义额外的帧,且其本来就已经定义了近十种帧,为以后的应用打下了很好的基础。

2.4.2 多工

HTTP/2是复用TCP连接的,这样一来,对于同一个域名只需要一个连接即可。

具体操作是什么呢?在 HTTP/1.1 之中,每个请求都会开启一个TCP连接,但是在 HTTP/2 之中,对于同一个域名的请求只会开启一个TCP连接。

那怎么区分不同的请求呢?这就涉及到“流”的设计,在 HTTP/2 之中,将 HTTP/1.1 之中的每个请求当作一个流,对于请求响应的数据,将其分成多个帧,不同流之中的帧可以交错的发送给对方。

在HTTP/2 之中,流的设计实现了多请求-响应并行,解决了HTTP/1.1之中阻塞的问题。

且在HTTP/2之中,数据流发送到一半的过程中,Client或者Server都可以发送信号取消这个数据流的同时还保证TCP连接不会被关闭,可以被其他的请求使用。

2.4.3 头信息压缩

  1. 头部信息压缩最后发送
  2. Client和Server共同维护一张头信息表,所有字段都存入表之后生成一个索引号,在生成之后就不会再发送同样的字段而是只发送索引号,这样就可以提高速度。

2.4.4 服务器推送(Server Push)

在HTTP/1.1之中,Server段没有权利主动给Client发送资源,因此如果一个页面有一百个资源,那么Client端要按照顺序请求一百次。

然而在HTTP/2之中,Server端预期到Client会在解析好HTML之后再请求静态资源,那么就会主动将这些静态资源一起发送给客户端,省着再一次次的请求占用连接了。

2.5 HTTPS

推荐一篇文章HTTPS系列干货(一):HTTPS 原理详解

2.5.1 HTTP的风险

没有身份验证环节,因此很容易被劫持,黑客可以仿冒Server端传送消息,这样一来Client收到的所有消息都是假冒的Server传输的。本来想看秋香,结果看到了肥肥的事情就可能发生。

分类的话主要有:

  1. 窃听风险:黑客可以获知通信内容。
  2. 篡改风险:黑客可以修改通信内容。
  3. 冒充风险:黑客可以冒充他人身份参与通信。

想象一下,你将自己的银行卡号和密码输入到了黑客的Server里面,后果不堪设想。

2.5.2 非对称加密

推荐这个如何用通俗易懂的话来解释非对称加密? - ThreatHunter的回答 - 知乎

也就是说公钥可以发布给大家加密,但是如果没有私钥,就不能解密。

2.5.3 HTTPS(HTTP over TLS,HTTP over SSL或HTTP Secure)

HTTPS之中的证书其由一个确定的第三方发布(避免其可能是假冒证书下载地址的风险)

SSL证书的具体内容有:

  1. 证书的发布机构CA
  2. 证书的有效期
  3. 公钥
  4. 证书所有者
  5. 签名

2.5.4 证书的校验方法

从报文的角度详解证书的校验方法: HTTPS协议、TLS协议、证书认证过程解析

如何保证证书的安全性? https保证安全的原理