梳理TCP,HTTP,HTTPS,HTTP/2

本文对于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保证安全的原理