前端成长进阶指北（网络篇）

分别介绍下 http 和 tcp 协议，它们之间的区别与联系

TCP 协议对应于传输层，而 HTTP 协议对应于应用层，从本质上来说，二者没有可比性：

• HTTP 对应于应用层，TCP 协议对应于传输层
• HTTP 协议是在 TCP 协议之上建立的，HTTP 在发起请求时通过 TCP 协议建立起连接服务器的通道，请求结束后，立即断开 TCP 连接
• HTTP 是无状态的短连接，而 TCP 是有状态的长连接
• TCP是传输层协议，定义的是数据传输和连接方式的规范，HTTP是应用层协议，定义的是传输数据的内容的规范

[一文走进 HTTP 与 TCP 协议，它们的区别与联系]

HTTP/2对比HTTP/1.1，特性是什么？是如何解决队头阻塞与压缩头部的？

自从 1997 年 HTTP/1.1 发布以来，我们已经使用 HTTP/1.x 相当长一段时间了，但近几年内容的爆炸式成长使得 HTTP/1.1 越来越无法满足现代网络的需求了，HTTP/1.1 协议的性能缺陷：

• 高延迟：页面访问速度下降
• 明文传输：不安全
• 无状态：头部巨大切重复
• 不支持服务器推送

HTTP/1.x 为了性能考虑，会引入雪碧图、将小图内联、使用多个域名等等的方式，但还是有一些关键点无法优化，例如HTTP头部巨大且重复、明文传输不安全、服务器不能主动推送等，要改变这些必须重新设计 HTTP 协议，于是 HTTP/2 就出来了！

2015 年，HTTP/2 发布。HTTP/2 是现行 HTTP 协议（HTTP/1.x）的替代，但它不是重写，HTTP 方法 / 状态码 / 语义都与 HTTP/1.x 一样。HTTP/2 基于 SPDY，专注于性能，最大的目标是在用户和网站间只用一个连接（connec-tion）。

• 二进制传输
• Header 压缩（HPACK）
• 多路复用
• 服务端 Push
• 提高安全性

HTTP/2 遗留问题：

• HTTP/2 也存在队头阻塞问题，比如丢包。
• 慢启动

[HTTP/2对比HTTP/1.1，新特性是什么？是如何解决队头阻塞与压缩头部的？]

说一下HTTP/3新特性，为什么选择使用UDP协议？

HTTP/2 使用二进制传输、Header 压缩（HPACK）、多路复用等，相较于 HTTP/1.1 大幅提高了数据传输效率，但它仍然存在着以下几个致命问题（主要由底层支撑的 TCP 协议造成）：

• 建立连接时间长
• 队头阻塞问题相较于 HTTP/1.1 更严重

而修改 TCP 协议已经是一件不可能完成的任务，所以Google 就更起炉灶搞了一个基于 UDP 协议的 QUIC 协议：

• 基于 TCP 开发的设备和协议非常多，兼容困难
• TCP 协议栈是 Linux 内部的重要部分，修改和升级成本很大
• UDP 本身是无连接的、没有建链和拆链成本
• UDP 的数据包无队头阻塞问题
• UDP 改造成本小

QUIC 虽然基于 UDP，但是在原本的基础上新增了很多功能，比如多路复用、0-RTT、使用 TLS1.3 加密、流量控制、有序交付、重传等等功能

[说一下 HTTP/3 新特性，为什么选择使用 UDP 协议？]

有关 HTTP 缓存的首部字段说一下

常见的HTTP 缓存首部字段有：

• Expires：响应头，代表该资源的过期时间
• Cache-Control：请求/响应头，缓存控制字段，精确控制缓存策略
• If-Modified-Since：请求头，资源最近修改时间，由浏览器告诉服务器
• Last-Modified：响应头，资源最近修改时间，由服务器告诉浏览器
• Etag：响应头，资源标识，由服务器告诉浏览器
• If-None-Match：请求头，缓存资源标识，由浏览器告诉服务器

其中， 强缓存 ：

• Expires（HTTP/1.0）
• Cache-Control（HTTP/1.1）

协商缓存：

• Last-Modified 和 If-Modified-Since（HTTP/1.0）
• ETag 和 If-None-Match（HTTP/1.1）

[了解 HTTP 缓存吗？有关 HTTP 缓存的首部字段说一下 ？]

HTTP 常见的响应码，拒绝服务资源是哪个？

RFC 把状态码分成五类，分别是：

• 1××： 请求已被接受正被处理，表示目前是协议处理的中间状态，还需要后续的操作
• 2××： 请求成功处理，报文已经收到并被正确处理
• 3××： 代表需要客户端采取进一步的操作才能完成请求，例如重定向，通常，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的Location域中指明
• 4××： 客户端错误，请求报文有误，服务器无法处理
• 5××： 服务器错误，服务器在处理请求时内部发生了错误

容易争论的点：

• 301、302 和 307区别（对 SEO 的影响）
• 401 和 404 的区别

[HTTP 状态码有哪些？该怎么用？]

HTTP 中的 keep-alive 有了解吗？它和多路复用的区别

HTTP/1.x keep-alive 与 HTTP/2 多路复用区别：

• HTTP/1.x 是基于文本的，只能整体去传；HTTP/2 是基于二进制流的，可以分解为独立的帧，交错发送
• HTTP/1.x keep-alive 必须按照请求发送的顺序返回响应；HTTP/2 多路复用不按序响应
• HTTP/1.x keep-alive 为了解决队头阻塞，将同一个页面的资源分散到不同域名下，开启了多个 TCP 连接；HTTP/2 同域名下所有通信都在单个连接上完成
• HTTP/1.x keep-alive 单个 TCP 连接在同一时刻只能处理一个请求（两个请求的生命周期不能重叠）；HTTP/2 单个 TCP 同一时刻可以发送多个请求和响应

[了解 HTTP/1.x 的 keep-alive 吗？它与 HTTP/2 多路复用的区别是什么？]

http header怎么判断协议是不是 websocket

WebSocket 使用 ws 或 wss 的统一资源标志符，通过判断 header 中是否包含 Connection: Upgrade 与 Upgrade: websocket 来判断当前是否需要升级到 websocket 协议，除此之外，它还包含 Sec-WebSocket-Key 、 Sec-WebSocket-Version 等header，当服务器同意 WebSocket 连接时，返回响应码 101 ，它的 API 很简单。

方法：

• socket.send(data)
• socket.close([code], [reason])

事件：

• open
• message
• error
• close

[http header 怎么判断协议是不是 websocket]

GET 与 POST 区别是什么？

w3school 给出的标准答案：

	GET	POST
后退按钮/刷新	无害	数据会被重新提交（浏览器应该告知用户数据会被重新提交）。
书签	可收藏为书签	不可收藏为书签
缓存	能被缓存	不能缓存
编码类型	application/x-www-form-urlencoded	application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
历史	参数保留在浏览器历史中。	参数不会保存在浏览器历史中。
对数据长度的限制	是的。当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。	无限制。
对数据类型的限制	只允许 ASCII 字符。	没有限制。也允许二进制数据。
安全性	与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。在发送密码或其他敏感信息时绝不要使用 GET ！	POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。
可见性	数据在 URL 中对所有人都是可见的。	数据不会显示在 URL 中。

从 HTTP 协议上看，GET 与 POST 的本质区别有两点：

• 请求行不同：
• GET：GET /uri HTTP/1.1
• POST：POST /uri HTTP/1.1
• 对服务器资源的操作不同：
• GET：表示从服务器获取资源
• POST：向指定的服务器资源提交数据（通常导致状态或服务器上的副作用的更改）

进阶：常见问题及解答：

• POST 方法比 GET 方法安全？
• POST 方法会产生两个 TCP 数据包？

[你真的了解 GET 和 POST 吗，它们的区别是什么？]

session 和 cookie 的区别

• 安全性： Session 比 Cookie 安全，Session 是存储在服务器端的，Cookie 是存储在客户端的。
• 存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
• 有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时（一般30分钟无操作）都会失效。
• 存储大小不同： 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。

[傻傻分不清之 Cookie、Session、Token、JWT]

如果让你去实现一个 CSRF 攻击你会怎么做？

了解 CSRF 常见的攻击方式，模拟攻击就很简单了，几种常见的攻击方式：

• 自动发起 GET 请求的 CSRF
• 自动发起 POST 请求的 CSRF
• 引诱用户点击链接的 CSRF

防护策略：

• 利用 Cookie 的 SameSite 属性
• 利用同源策略
• Token 认证

[如果让你去实现一个 CSRF 攻击你会怎么做？]

除了CSRF，你还知道其它的攻击方式吗？

我所了解的，除了 CSRF ，还有：

• XSS 攻击
• SQL 注入攻击
• DDoS 攻击
• 上传文件漏洞
• DNS 查询攻击

结合上篇 如果让你去实现一个 CSRF 攻击你会怎么做？ ，总共介绍了六种 web 攻击与防护，其中最重要的是 CSRF 攻击、 XSS 攻击，其余只做了解即可。

[除了CSRF，你还知道哪些其它的攻击方式吗？]

为什么说 HTTPS 比 HTTP 安全呢

HTTP 协议使用起来非常的方便，但是它存在一个致命的缺点：不安全。HTTPS并非是应用层的一种新协议，其实是 HTTP+SSL/TLS 的简称

HTTP 和 HTTPS 的区别：

• HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的TLS（SSL）加密传输协议
• HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443
• HTTP 的连接很简单，是无状态的；HTTPS协议是由 HTTP+SSL/TLS 协议构建的可进行加密传输、身份认证的网络协议，比 HTTPS 协议安全。

针对抓包问题，HTTPS 可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情。

[为什么说HTTPS比HTTP安全呢]

DNS 协议是什么？完整查询过程？为什么选择使用 UDP 协议发起 DNS 查询？

DNS（Domain Name System：域名系统），与 HTTP、FTP 和 SMTP 一样，DNS 协议也是应用层的协议，用于将用户提供的主机名（域名）解析为 IP 地址

DNS完整查询过程：

1. 首先搜索 浏览器的 DNS 缓存 ，缓存中维护一张域名与 IP 地址的对应表
2. 如果没有命中，则继续搜索 操作系统的 DNS 缓存
3. 如果依然没有命中‍♀️，则操作系统将域名发送至 本地域名服务器 ，本地域名服务器查询自己的 DNS 缓存，查找成功则返回结果（注意：主机和本地域名服务器之间的查询方式是 递归查询 ）
4. 若本地域名服务器的 DNS 缓存没有命中‍，则本地域名服务器向上级域名服务器进行查询，通过以下方式进行 迭代查询 （注意：本地域名服务器和其他域名服务器之间的查询方式是迭代查询，防止根域名服务器压力过大）：

• 首先本地域名服务器向根域名服务器发起请求，根域名服务器是最高层次的，它并不会直接指明这个域名对应的 IP 地址，而是返回顶级域名服务器的地址，也就是说给本地域名服务器指明一条道路，让他去这里寻找答案
• 本地域名服务器拿到这个顶级域名服务器的地址后，就向其发起请求，获取权限域名服务器的地址
• 本地域名服务器根据权限域名服务器的地址向其发起请求，最终得到该域名对应的 IP 地址

5 . 本地域名服务器 将得到的 IP 地址返回给操作系统，同时自己将 IP 地址 缓存 起来 6 . 操作系统 将 IP 地址返回给浏览器，同时自己也将 IP 地址 缓存 起来 7 . 至此， 浏览器 就得到了域名对应的 IP 地址，并将 IP 地址 缓存 起来

需要注意的是，DNS 使用了 UDP 协议来获取域名对应的 IP 地址，这个没错，但有些片面，准确的来说，DNS 查询在刚设计时主要使用 UDP 协议进行通信，而 TCP 协议也是在 DNS 的演进和发展中被加入到规范的：

1. DNS 在设计之初就在区域 传输中引入了 TCP 协议 ， 在查询中使用 UDP 协议 ，它同时占用了 UDP 和 TCP 的 53 端口
2. 当 DNS 超过了 512 字节的限制，我们第一次在 DNS 协议中明确了 『当 DNS 查询被截断时，应该使用 TCP 协议进行重试』 这一规范；
3. 随后引入的 EDNS 机制允许我们使用 UDP 最多传输 4096 字节的数据，但是由于 MTU 的限制导致的数据分片以及丢失，使得这一特性不够可靠；
4. 在最近的几年，我们重新规定了 DNS 应该同时支持 UDP 和 TCP 协议，TCP 协议也不再只是重试时的选择；

[DNS 协议是什么？完整查询过程？为什么选择使用 UDP 协议发起 DNS 查询？]

TCP 的三次握手和四次挥手，了解泛洪攻击么

TCP 三次握手（连接过程）

TCP 四次挥手（断开链接）

我们已经知道，TCP 只有经过三次握手才能连接，而 SYN 泛洪攻击就是针对 TCP 握手过程进行攻击：

• 攻击者发送大量的 SYN 包给服务器（第一次握手成功）
• 服务器回应(SYN + ACK）包（第二次握手成功）
• 但是攻击者不回应 ACK 包（第三次握手不进行）

导致服务器存在大量的半开连接，这些半连接可以耗尽服务器资源，使被攻击服务器无法再响应正常 TCP 连接，从而达到攻击的目的

[TCP 的三次握手和四次挥手，了解泛洪攻击么]