面试官：这波HTTP究极combo，你顶得住吗？

三次握手

所谓三次握手(Three-way Handshake)，是指建立一个 TCP 连接时，需要客户端和服务器总共发送3个包。

三次握手的目的是连接服务器指定端口，建立 TCP 连接，并同步连接双方的序列号和确认号，交换 TCP 窗口大小信息。在 socket 编程中，客户端执行 connect() 时。将触发三次握手

• 第一次握手(SYN=1, seq=x):

客户端发送一个 TCP 的 SYN 标志位置1的包，指明客户端打算连接的服务器的端口，以及初始序号 X,保存在包头的序列号(Sequence Number)字段里。

发送完毕后，客户端进入 SYN_SEND 状态。

• 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):

服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为1。服务器端选择自己 ISN 序列号，放到 Seq 域里，同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加1，即X+1。 发送完毕后，服务器端进入 SYN_RCVD 状态。

• 第三次握手(ACK=1，ACKnum=y+1)

客户端再次发送确认包(ACK)，SYN 标志位为0，ACK 标志位为1，并且把服务器发来 ACK 的序号字段+1，放在确定字段中发送给对方，并且在数据段放写ISN的+1

发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态，TCP 握手结束。

四次挥手

TCP 的连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，也叫做改进的三次握手。客户端或服务器均可主动发起挥手动作，在 socket 编程中，任何一方执行 close() 操作即可产生挥手操作

• 第一次挥手(FIN=1，seq=x)

假设客户端想要关闭连接，客户端发送一个 FIN 标志位置为1的包，表示自己已经没有数据可以发送了，但是仍然可以接受数据。

发送完毕后，客户端进入 FIN_WAIT_1 状态。

• 第二次挥手(ACK=1，ACKnum=x+1)

服务器端确认客户端的 FIN 包，发送一个确认包，表明自己接受到了客户端关闭连接的请求，但还没有准备好关闭连接。

发送完毕后，服务器端进入 CLOSE_WAIT 状态，客户端接收到这个确认包之后，进入 FIN_WAIT_2 状态，等待服务器端关闭连接。

• 第三次挥手(FIN=1，seq=y)

服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为1。

发送完毕后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个ACK。

• 第四次挥手(ACK=1，ACKnum=y+1)

客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT状态，等待可能出现的要求重传的 ACK 包。

服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。

客户端等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。

三次握手的原因

• 第一次握手：客户端发送网络包，服务端收到了。 这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
• 第二次握手：服务端发包，客户端收到了。 这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
• 第三次握手：客户端发包，服务端收到了。 这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

四次挥手的原因

客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据。

问题: 能通俗的讲一下吗？

计算机通讯与人的通讯本质上没什么区别。我们日常发微信也是通讯，理解了你自己是如何发微信的你就理解了TCP三次握手。

如上图，小明欠我钱，我在微信上找小明要钱，这是步骤

1. 我发出：小明，你在吗？我是Mlx。(第一次握手，确认对方在不在，并且发送序号Seq为Mlx)
2. 小明回复：我是小明，我在，干啥？(第二次握手，接收方确认对方在，并且知道对方能找到自己了，收到了这个Seq的序号，并且发送自己的发送序号为小明)
3. 我回复：在就行，接下来聊还钱的事！(第三次握手，确认对方在，并且确认对方能收到自己消息这个时候就可以谈还钱的事了。并且第三次握手就可以携带数据了)

两次握手可以吗？

显然不行。为啥？

还是上面的例子，你发微信的最后一句话 在就行，聊聊还钱的事一直转圈圈发不出去，你等了很久也没发出去，你想，啊这不对啊， 你又发送了一次。小明看到以后开始和你聊还钱的事情了，正当你们因为关系要好而决定小明过几日在还钱的时候，这句话又发出来了，你说小明这时候看见是啥心理？肯定是觉得刚才不还谈的好好的么，怎么又催一次，决定还钱，和你这个朋友绝交。

四次挥手

你和女朋友聊天，已经晚上十一点了， 你想睡觉了，于是你想停止聊天。

1. 你: 亲爱的，我想睡觉了(第一次挥手，发送FIN，进入等待女朋友批复的过程也就是FIN_WAIT_1)
2. 女朋友:知道了，等我把这部剧玩看就睡(第二次挥手，回复ACK),女朋友也知道快睡觉了，倍速播放(进入CLOSE_WAIT状态)，收到消息的你此时处于等待女朋友看剧结束的状态(FIN_WAIT_2 )
3. 过了一会女朋友看完剧了: 亲爱的我看完了，可以睡觉了,晚安哦(第三次挥手，服务器进入等待你说晚安就可以睡觉的阶段)
4. 你: 好的亲爱的，晚安(第四次挥手，女朋友收到消息知道你也要睡了，然后两个人进入梦乡)

上文说到，客户端等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。那么什么是等待2MSL呢？

对应于上面的第四步，你发送了晚安以后，有两个情况

1. 你发送的晚安没发出去，这个时候女朋友见你迟迟不发消息会在通知你一次她可以睡觉了
2. 你发送的晚安发出去了，女朋友看到以后也不回你了直接就去睡了。

面对上面这两种情况，你都得需要等待，等多久呢？假设微信发消息五分钟发不出去就不发了

那么对于第一种情况，你发送的消息是最迟5分钟会送达对方，否则就送不到，女朋友给你发消息也是5分钟，那么你最长只需要等10分钟就能确认消息是发送成功还是失败了。10分钟正好是最长消息的两倍,即MSL*2 ,2MSL。

问题: 你说TCP是可靠传输，是如何保证可靠的呢？

TCP 使用超时重传来实现可靠传输：如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文段。

问题: 你用的HTTP是什么版本的？有什么区别吗？

HTTP有这么几个重要的版本 HTTP1.0 HTTP1.1 HTTP2.0

目前HTTP1.1用的比较多，2.0则用的比较少。

http1.0特性

• 无状态：服务器不跟踪不记录请求过的状态
• 无连接：浏览器每次请求都需要建立tcp连接

无状态

对于无状态的特性可以借助cookie/session机制来做身份认证和状态记录

无连接

无连接导致的性能缺陷有两种：

1. 无法复用连接

每次发送请求，都需要进行一次tcp连接（即3次握手4次挥手），使得网络的利用率非常低

2. 队头阻塞

http1.0规定在前一个请求响应到达之后下一个请求才能发送，如果前一个阻塞，后面的请求也给阻塞的

http1.1特性

为了解决http1.0的性能缺陷，http1.1出现了

http1.1特性：

• 长连接：新增Connection字段，可以设置keep-alive值保持连接不断开
• 管道化：基于上面长连接的基础，管道化可以不等第一个请求响应继续发送后面的请求，但响应的顺序还是按照请求的顺序返回
• 缓存处理：新增字段cache-control
• 断点传输

长连接

http1.1默认保持长连接，数据传输完成保持tcp连接不断开,继续用这个通道传输数据

管道化

基于长连接的基础，我们先看没有管道化请求响应：

tcp没有断开，用的同一个通道

请求1 > 响应1 --> 请求2 > 响应2 --> 请求3 > 响应3

管道化的请求响应：

请求1 --> 请求2 --> 请求3 > 响应1 --> 响应2 --> 响应3

即使服务器先准备好响应2,也是按照请求顺序先返回响应1

虽然管道化，可以一次发送多个请求，但是响应仍是顺序返回，仍然无法解决队头阻塞的问题

缓存处理

当浏览器请求资源时，先看是否有缓存的资源，如果有缓存，直接取，不会再发请求，如果没有缓存，则发送请求

通过设置字段cache-control来控制

断点传输

在上传/下载资源时，如果资源过大，将其分割为多个部分，分别上传/下载，如果遇到网络故障，可以从已经上传/下载好的地方继续请求，不用从头开始，提高效率

在 Header 里两个参数实现的，客户端发请求时对应的是 Range 服务器端响应时对应的是 Content-Range

host域

HTTP1.0 不支持，因为之前觉得一台服务器只有一个地址 HTTP2.0 支持，请求消息和响应消息都支持

http2.0特性

• 二进制分帧
• 多路复用： 在共享TCP链接的基础上同时发送请求和响应
• 头部压缩
• 服务器推送：服务器可以额外的向客户端推送资源，而无需客户端明确的请求

二进制分帧

将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码

多路复用

基于二进制分帧，在同一域名下所有访问都是从同一个tcp连接中走，http消息被分解为独立的帧，乱序发送，服务端根据标识符和首部将消息重新组装起来

区别

1. http1.0 到http1.1的主要区别，就是从无连接到长连接
2. http2.0对比1.X版本主要区别就是多路复用

问题：HTTP有哪些优点和缺点呢？

优点

1. 简单

HTTP 基本的报⽂格式就是 header + body ，头部信息也是 key-value 简单⽂本的形式，易于理解，降低了学习和使⽤的⻔槛。

2. 灵活和易于扩展

HTTP协议⾥的各类请求⽅法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发⼈员⾃定义和扩充。

3. 应⽤⼴泛和跨平台

缺点

1. ⽆状态双刃剑

⽆状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存⽤来对外提供服务。

⽆状态的坏处，既然服务器没有记忆能⼒，它在完成有关联性的操作时会⾮常麻烦。例如登录->添加购物⻋->下单->结算->⽀付，这系列操作都要知道⽤户的身份才⾏。但服务器不知道这些请求是有关联的，每次都要问⼀遍身份信息。

2. 明文传输双刃剑

明⽂意味着在传输过程中的信息，是可⽅便阅读的，通过浏览器的 F12 控制台或 Wireshark 抓包都可以

直接⾁眼查看，为我们调试⼯作带了极⼤的便利性。但是这正是这样，HTTP 的所有信息都暴露在了光天化⽇下，相当于信息裸奔。在传输的漫⻓的过程中，信息的内容都毫⽆隐私可⾔，很容易就能被窃取

3.HTTP是不安全的，无法验证通信双方的身份

问题：那该如何解决你所说的缺点呢？

对于无状态：

HTTP/1.1 引入 Cookie 来保存状态信息。

Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一浏览器。由于之后每次请求都会需要携带 Cookie 数据，因此会带来额外的性能开销。

对于明文传输和安全性

HTTPS 则解决 HTTP 不安全的 缺陷，在 TCP 和 HTTP ⽹络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。

问题: 那你说说HTTPS是什么？和HTTP有什么区别呢？

• HTTP 是超⽂本传输协议，信息是明⽂传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的 缺陷，在 TCP 和 HTTP 网络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。
• HTTP 连接建⽴相对简单， TCP 三次握手之后便可进行HTTP 的报⽂传输。而HTTPS 在 TCP 三 次握手之后，还需进行 SSL/TLS 的握手过程，才可进⼊加密报文传输。
• HTTP 的端口号是 80，HTTPS 的端⼝号是 443。
• HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

HTTPS 并不是新协议，而是让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信。

通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。

HTTPS 是如何解决风险的？

• 混合加密的⽅式实现信息的机密性，解决了窃听的⻛险。
• 摘要算法的⽅式来实现完整性，它能够为数据⽣成独⼀⽆⼆的「指纹」，指纹⽤于校验数据的完整 性，解决了篡改的⻛险。
• 将服务器公钥放⼊到数字证书中，解决了冒充的⻛险。

问题:那么什么是混合加密？

HTTPS 采⽤的是对称加密和⾮对称加密结合的「混合加密」⽅式：

• 在通信建⽴前采⽤⾮对称加密的⽅式交换「会话秘钥」，后续就不再使⽤⾮对称加密。
• 在通信过程中全部使⽤对称加密的「会话秘钥」的⽅式加密明⽂数据。

什么是对称加密和非对称加密？

对称密钥加密

对称密钥加密（Symmetric-Key Encryption），加密和解密使用同一密钥。简而言之，就是你和小伙伴提前准备好了一模一样的密码本，对着密码本解密就行，缺点是你如何把密码本给你的小伙伴。主流的有DES、AES-GCM等

• 优点：运算速度快；
• 缺点：无法安全地将密钥传输给通信方。

非对称密钥加密

非对称密钥加密，又称公开密钥加密（Public-Key Encryption），加密和解密使用不同的密钥。

公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。主流的有RSA、DSA等

• 优点：可以更安全地将公开密钥传输给通信发送方；
• 缺点：运算速度慢。

很多人不理解公钥和私钥的意思。其实我换个说法，大家一下子就理解了。非对称加密就是公开锁和私钥共同配合的加密方式。

公开锁就对应着公钥，其实我个人觉得公钥这个称呼不是很好，用公开锁比较好。

比如说我有许多锁，这些锁就是公钥，而这些锁对应着的是一个钥匙，这个钥匙就是私钥。谁想给我发送加密内容，只需要从我这里拿走锁，把他要发送的内容锁住，然后就可以光明正大给我传递消息了，而只有我有钥匙，也就代表只有我能打开锁看到里面的内容。

对称加密运算快，但是密码本很难安全给对方。非对称加密可以安全的发送消息给对方，但是运算慢。HTTPS拍脑袋一想，哎，我把你们俩结合一下不就好了吗？你非对称加密安全是吧，那我用你安全的把密码本发送给对方不就行了？

其实非对称加密主要的原理在于单向陷门函数

单向陷门函数是有一个陷门的一类特殊单向函数。单向陷门函数包含两个明显特征：一是单向性，二是存在陷门。所谓单向性，也称不可逆性，即对于一个函数y=f(x)，若已知x要计算出y很容易，但是已知y要计算出x=f ^(-1) (y)则很困难。单向函数的命名就是源于其只有一个方向能够计算。所谓陷门，也成为后门。对于单向函数，若存在一个z使得知道z则可以很容易地计算出x=f ^(-1) (y)，而不知道z则无法计算出x=f ^(-1) (y)，则称函数y=f(x)为单向陷门函数，而z称为陷门。

所以基于此，HTTPS是使用非对称加密的方式将对称加密的密钥传送过去，也就是把密码本锁上给了对方。然后对方得到密文用它自己的钥匙打开锁得到密码本之后，随后就可以用对称加密的方式通信了。

问题:HTTP2.0都具体做了哪些优化工作呢？

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是⼀样的或是相似的，那么，协议会 帮你消除重复的部分。这就是所谓的 HPACK 算法

HTTP/2 不再像 HTTP/1.1 ⾥的纯⽂本形式的报⽂，⽽是全⾯采⽤了⼆进制格式，头信息和数据体都是 ⼆进制，并且统称为帧（frame）：头信息帧和数据帧也就是上面说的二进制分帧

HTTP/2 的数据包不是按顺序发送的，同⼀个连接⾥⾯连续的数据包，可能属于不同的回应。因此，必 须要对数据包做标记，指出它属于哪个回应。 每个请求或回应的所有数据包，称为⼀个数据流（ Stream ）。每个数据流都标记着⼀个独⼀⽆⼆的编 号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数

HTTP/2 是可以在⼀个连接中并发多个请求或回应，⽽不⽤按照顺序⼀⼀对应。 移除了 HTTP/1.1 中的串⾏请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟， ⼤幅度提⾼了连接的利⽤率。

HTTP/2 还在⼀定程度上改善了传统的「请求 - 应答」⼯作模式，服务不再是被动地响应，也可以主动 向客户端发送消息。 举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会⽤到的 JS、CSS ⽂件等静态资源主动发给 客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。

问题: HTTP2.0你说的这么好，那么它有什么缺陷呢？

HTTP/2 主要的问题在于，多个 HTTP 请求在复⽤⼀个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以⼀旦发⽣了丢包现象，就会触发 TCP 的᯿传机制，这样在⼀个 TCP 连接中的所有 的 HTTP 请求都必须等待这个丢了的包被重传回来。

HTTP/1.1 中的管道（ pipeline）传输中如果有⼀个请求阻塞了，那么队列后请求也统统被阻塞住了

HTTP/2 多个请求复⽤⼀个TCP连接，⼀旦发生丢包，就会阻塞住所有的 HTTP 请求。

这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！UDP 发⽣是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的⼀个丢包全部重传问题。

问题: 那么HTTP报文中的请求头都有哪些呢？

通用首部字段

首部字段名	说明
Cache-Control	控制缓存的行为
Connection	控制不再转发给代理的首部字段、管理持久连接
Date	创建报文的日期时间
Pragma	报文指令
Trailer	报文末端的首部一览
Transfer-Encoding	指定报文主体的传输编码方式
Upgrade	升级为其他协议
Via	代理服务器的相关信息
Warning	错误通知

请求首部字段

首部字段名	说明
Accept	用户代理可处理的媒体类型
Accept-Charset	优先的字符集
Accept-Encoding	优先的内容编码
Accept-Language	优先的语言（自然语言）
Authorization	Web 认证信息
Expect	期待服务器的特定行为
From	用户的电子邮箱地址
Host	请求资源所在服务器
If-Match	比较实体标记（ETag）
If-Modified-Since	比较资源的更新时间
If-None-Match	比较实体标记（与 If-Match 相反）
If-Range	资源未更新时发送实体 Byte 的范围请求
If-Unmodified-Since	比较资源的更新时间（与 If-Modified-Since 相反）
Max-Forwards	最大传输逐跳数
Proxy-Authorization	代理服务器要求客户端的认证信息
Range	实体的字节范围请求
Referer	对请求中 URI 的原始获取方
TE	传输编码的优先级
User-Agent	HTTP 客户端程序的信息

响应首部字段

首部字段名	说明
Accept-Ranges	是否接受字节范围请求
Age	推算资源创建经过时间
ETag	资源的匹配信息
Location	令客户端重定向至指定 URI
Proxy-Authenticate	代理服务器对客户端的认证信息
Retry-After	对再次发起请求的时机要求
Server	HTTP 服务器的安装信息
Vary	代理服务器缓存的管理信息
WWW-Authenticate	服务器对客户端的认证信息

实体首部字段

首部字段名	说明
Allow	资源可支持的 HTTP 方法
Content-Encoding	实体主体适用的编码方式
Content-Language	实体主体的自然语言
Content-Length	实体主体的大小
Content-Location	替代对应资源的 URI
Content-MD5	实体主体的报文摘要
Content-Range	实体主体的位置范围
Content-Type	实体主体的媒体类型
Expires	实体主体过期的日期时间
Last-Modified	资源的最后修改日期时间

文末

作者：Mlx
链接：https://juejin.im/post/6877362691350986766

对文章有何见解，或者有何技术问题，都可以在评论区一起留言讨论，一定会回复的。
也欢迎大家来我的B站找我玩，各类Android架构师进阶技术难点的视频讲解，任君白嫖~
B站直通车：https://space.bilibili.com/484587989

喜欢文章的小伙伴别忘了点个关注，留个赞再走呀，一个专注Android面试的小喵喵~

总结

其实要轻松掌握很简单，要点就两个：

1. 找到一套好的视频资料，紧跟大牛梳理好的知识框架进行学习。
2. 多练。 （视频优势是互动感强，容易集中注意力）

你不需要是天才，也不需要具备强悍的天赋，只要做到这两点，短期内成功的概率是非常高的。

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。下面资料部分截图是我花费几个月时间整理的，诚意满满：特别适合有3-5年开发经验的Android程序员们学习。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

赋，只要做到这两点，短期内成功的概率是非常高的。**

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。下面资料部分截图是我花费几个月时间整理的，诚意满满：特别适合有3-5年开发经验的Android程序员们学习。

[外链图片转存中…(img-jYw9sa3h-1714725078638)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！