前端面试-HTTP篇
1.websocket和http的区别
使用场景对比
HTTP
- HTTP（Hypertext Transfer Protocol）是一种应用层协议，最初设计用于在客户端和服务器之间传输超文本。它是一种无状态的协议，每个请求都是独立的，不保留前一次请求的状态信息。HTTP 通常用于传输网页、图片、文本等静态资源，以及通过 RESTful API 进行数据传输。
WebSocket
- WebSocket 是一种全双工通信协议，位于OSI模型的应用层。建立在单个 TCP 连接上，允许在客户端和服务器之间进行双向通信。WebSocket 的设计旨在解决 HTTP 协议在实时性和交互性方面的不足。它广泛应用于实时聊天、在线游戏、金融行业的实时数据更新等场景。
协议对比
HTTP
- 协议类型： 无状态、请求-响应型协议。
- 通信方式： 单向通信，客户端发送请求，服务器返回响应。
- 持久连接： 支持持久连接，通过 HTTP Keep-Alive 头字段可以在一次连接中发送多个请求和响应。
WebSocket
- 协议类型： 全双工通信协议。
- 通信方式： 双向通信，客户端和服务器可以随时发送消息。
- 持久连接： 基于单个 TCP 连接，保持连接状态，避免了每次通信都需要重新建立连接的开销。
链接方式对比
HTTP
- 连接建立： 每个请求都需要建立一个新的连接。
- 连接关闭： 服务器在每个响应之后会关闭连接，客户端需要重新建立连接发送新的请求。
WebSocket
- 连接建立： 通过 HTTP 协议建立初始连接，然后升级为 WebSocket 协议。建立连接后保持开放状态。
- 连接关闭： 可以由客户端或服务器发起关闭连接请求，而不需要重新建立连接。
通信性质对比
HTTP
- 单向通信： 请求-响应模式，客户端发送请求，服务器返回响应。
- 轮询： 实现实时性的方式之一是通过轮询，但效率低，增加了网络负担。
WebSocket
- 双向通信： 客户端和服务器可以随时发送消息，实现实时的双向通信。
- 事件驱动： 基于事件的模型，服务器或客户端可以通过事件触发实现及时的通信。
2. 前端跨页面通信的方法？
- LocalStorage 或 SessionStorage:这两个 Web 存储 API 可以在不同页面之间共享数据。一个页面可以将数据存储在本地存储中，另一个页面则可以读取该数据并进行相应处理。通过监听 storage 事件，可以实现数据的实时更新。
- Cookies:使用 Cookies 也可以在不同页面之间传递数据。通过设置和读取 Cookie 值，可以在同一域名下的不司页面之间交换信息。
- PostMessage: window.postMessage()方法允许从一个窗口向另一个窗口发送消息，并在目标窗口上触发.message 事件。通过指定目标窗口的 origin，可以确保只有特定窗口能够接收和处理消息。
- Broadcast Channel:Broadcast Channel API 允许在同一浏览器下的不同上下文(例如，在不同标签页或iframe 中)之间进行双向通信。它提供了一个类似于发布-订阅模式的机制，通过创建一个广播频道，并在不同上下文中加入该频道，可以实现消息的广播和接收。
- SharedWorker:sharedWorker 是一个可由多个窗口或标签页共享的 Web Worker，它可以在不同页面之间进行跨页面通信。通过 SharedWorker，多个页面可以通过 postMessage 进行双向通信，并共享数据和执行操作。
- IndexedDB:IndexedDB 是浏览器提供的一个客户端数据库，可以在不同页面之间存储和共享数据。通过在一个页面中写入数据，另一个页面可以读取该数据。
- WebSockets:WebSockets 提供了全双工的、双向通信通道，可以在客户端和服务器之间进行实时通信。通过建立 WebSocket 连接，可以在不同页面之间通过服务器传递数据并实现实时更新。
3. 什么是HTTP? HTTP 和 HTTPS 的区别?
HTTP（HyperText Transfer Protocol，超文本传输协议）是浏览器与服务器之间通信的基础协议。当你在浏览器输入网址，浏览器就会通过 HTTP 向服务器请求网页内容，服务器再通过 HTTP 把 HTML、图片、CSS 等数据返回给浏览器。
为了保证这些隐私数据能加密传输，让HTTP运行安全的SSL/TLS协议上，即 HTTPS = HTTP + SSL/TLS，通过 SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密。
对于HTTPS请求服务器的流程：
- 首先客户端通过URL访问服务器建立SSL链接
- 服务器收到客户端请求后，会将网站支持的证书信息传递一份给客户端。
- 客户端的服务器开始协商SSL链接的安全等级。
- 客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并发送给网站。
- 服务器利用自己的私钥解密出会话密钥。
- 服务器利用会话密钥加密与客户端之间的通信。
简单说：
- 你打开一个 HTTPS 网站，浏览器和服务器先“打招呼”。
- 服务器发一个“身份证”（证书）给浏览器，证明自己是真的。
- 浏览器检查身份证有效后，生成一个“密钥”，用服务器的“公钥”加密发过去。
- 服务器用自己的“私钥”解开，得到这个密钥。
- 之后，双方用这个密钥加密聊天（传输数据）。
区别
- HTTPS是HTTP协议的安全版本，HTTP协议的数据传输是明文的，是不安全的，HTTPS使用了SSL/TLS协议进行了加密处理，相对更安全
- HTTP 和 HTTPS 使用连接方式不同，默认端口也不一样，HTTP是80，HTTPS是443
- HTTPS 由于需要设计加密以及多次握手，性能方面不如 HTTP
- HTTPS需要SSL，SSL 证书需要钱，功能越强大的证书费用越高
4. 为什么HTTPS比HTTP安全?
HTTP在通信过程中，存在以下问题：
- 通信使用明文（不加密），内容可能被窃听
- 不验证通信方的身份，因此有可能遭遇伪装
HTTPS是建立在SSL之上，其安全性由SSL来保证。在采用SSL后，HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能SSL(Secure Sockets Layer 安全套接字协议),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议
5.说说HTTP1.0/1.1和HTTP2.0的区别？
一、HTTP1.0
HTTP协议的第二个版本，第一个在通讯中指定版本号的HTTP协议版本
HTTP 1.0 浏览器与服务器只保持短暂的连接，每次请求都需要与服务器建立一个TCP连接。服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。如果需要建立长连接，需要设置一个非标准的Connection字段 Connection: keep-alive。
简单来讲，每次与服务器交互，都需要新开一个连接。
二、HTTP1.1
在HTTP1.1中，默认支持长连接（Connection: keep-alive），即在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。建立一次连接，多次请求均由这个连接完成。
同时，HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
时，HTTP1.1在HTTP1.0的基础上，增加更多的请求头和响应头来完善的功能，如。
三、HTTP2.0
而HTTP2.0在相比之前版本，性能上有很大的提升，如添加了一个特性：
- 多路复用：HTTP/2 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了”队头堵塞”
- 二进制分帧：帧是HTTP2通信中最小单位信息。HTTP/2 采用二进制格式传输数据，而非 HTTP 1.x的文本格式，解析起来更高效。
- 首部压缩：在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送。
- 服务器推送：允许服务端推送资源给客户端。服务器会顺便把一些客户端需要的资源一起推送到客户端，如在响应一个页面请求中，就可以随同页面的其它资源
免得客户端再次创建连接发送请求到服务器端获取，这种方式非常合适加载静态资源。
6. 说说HTTP 常见的状态码有哪些，适用场景？
HTTP状态码（英语：HTTP Status Code），用以表示网页服务器超文本传输协议响应状态的3位数字代码。
简单来讲，http状态码的作用是服务器告诉客户端当前请求响应的状态，通过状态码就能判断和分析服务器的运行状态。
| 状态码 | 名称 | 类别 | 含义 | 典型应用场景 |
|---|---|---|---|---|
| 200 | OK | ✅ 成功 | 请求成功，响应中包含所请求的资源 | GET/POST/PUT 请求成功返回数据 |
| 201 | Created | ✅ 成功 | 请求成功并在服务器创建了新资源 | 用户注册、文章发布等资源创建操作 |
| 204 | No Content | ✅ 成功 | 请求成功，但响应无实体内容 | DELETE 操作成功，或 PUT 更新无需返回数据 |
| 206 | Partial Content | ✅ 成功 | 服务器返回部分资源（范围请求） | 大文件分片下载、视频流媒体播放 |
| 301 | Moved Permanently | 🔄 重定向 | 资源已永久移动到新位置 | 域名迁移、URL 结构重构（SEO 友好） |
| 302 | Found | 🔄 重定向 | 资源临时位于另一个 URI | 登录后跳转首页、A/B 测试 |
| 303 | See Other | 🔄 重定向 | 建议使用 GET 请求另一个 URI | POST 后重定向防止重复提交（PRG 模式） |
| 304 | Not Modified | 🔄 重定向 | 资源未修改，可使用缓存 | 条件请求（ETag / If-Modified-Since）命中缓存 |
| 307 | Temporary Redirect | 🔄 重定向 | 临时重定向，保持原请求方法 | 临时维护跳转，需保留 POST/PUT 方法 |
| 308 | Permanent Redirect | 🔄 重定向 | 永久重定向，保持原请求方法 | API 端点永久迁移 |
| 400 | Bad Request | ❌ 客户端错误 | 请求语法错误或参数无效 | JSON 格式错误、缺少必填参数 |
| 401 | Unauthorized | ❌ 客户端错误 | 未认证或认证失败 | 未提供 token、token 过期 |
| 403 | Forbidden | ❌ 客户端错误 | 认证通过但权限不足 | 普通用户访问管理员接口 |
| 404 | Not Found | ❌ 客户端错误 | 服务器找不到请求的资源 | URL 错误、资源已删除 |
| 405 | Method Not Allowed | ❌ 客户端错误 | 请求方法不被允许 | 对只读接口发送 POST 请求 |
| 409 | Conflict | ❌ 客户端错误 | 请求与资源状态冲突 | 并发更新冲突、用户名已存在 |
| 410 | Gone | ❌ 客户端错误 | 资源已永久移除且无转发地址 | 内容下架、废弃 API |
| 429 | Too Many Requests | ❌ 客户端错误 | 请求频率超限（限流） | API 防刷、防止 DDoS 攻击 |
| 500 | Internal Server Error | 💥 服务器错误 | 服务器内部错误，无法完成请求 | 代码异常、数据库连接失败 |
| 501 | Not Implemented | 💥 服务器错误 | 服务器不支持请求功能 | 调用未实现的 HTTP 方法 |
| 502 | Bad Gateway | 💥 服务器错误 | 网关或代理收到上游无效响应 | Nginx 反向代理后端服务失败 |
| 503 | Service Unavailable | 💥 服务器错误 | 服务器临时不可用（过载/维护） | 服务重启、流量洪峰 |
| 504 | Gateway Timeout | 💥 服务器错误 | 网关或代理未在时限内收到上游响应 | 后端服务响应超时 |
| 505 | HTTP Version Not Supported | 💥 服务器错误 | 不支持请求的 HTTP 协议版本 | 客户端使用 HTTP/2 请求仅支持 HTTP/1.1 的服务 |
7. 说一下 GET 和 POST 的区别？
GET：GET方法请求一个指定资源的表示形式，使用GET的请求应该只被用于获取数据。
POST：POST方法用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用。
- GET参数通过URL传递，POST放在Request body中
- GET请求会被浏览器主动cache，而POST不会，除非手动设置。
- GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
- GET请求在URL中传送的参数是有长度限制的，而POST没有。
- GET在浏览器回退时是无害的，而POST会再次提交请求。
- GET产生的URL地址可以被Bookmark，而POST不可以。
- GET请求只能进行url编码，而POST支持多种编码方式。
- 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
- GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
8. 说说 HTTP 常见的请求头有哪些? 作用？
| 请求头 | 作用说明 | 典型值/使用场景 |
|---|---|---|
Host |
指定目标服务器的域名和端口 | Host: example.com<br>用于虚拟主机识别，HTTP/1.1 必需 |
User-Agent |
告诉服务器客户端信息（浏览器、操作系统等） | User-Agent: Mozilla/5.0 (Windows NT 10.0)<br>用于兼容性处理、统计分析 |
Accept |
声明客户端可接受的响应内容类型 | Accept: text/html, application/json<br>实现内容协商（Content Negotiation） |
Accept-Language |
客户端偏好的语言 | Accept-Language: zh-CN,zh;q=0.9<br>用于返回本地化内容 |
Accept-Encoding |
客户端支持的压缩方式 | Accept-Encoding: gzip, deflate<br>节省带宽，提升性能 |
Content-Type |
请求体的数据格式（POST/PUT 等） | •application/json<br>• application/x-www-form-urlencoded<br>• multipart/form-data（文件上传） |
Content-Length |
请求体的字节长度 | Content-Length: 128<br>帮助服务器解析请求体 |
Authorization |
身份认证信息 | Authorization: Bearer <token><br>或 Basic base64(username:password)<br>用于登录鉴权 |
Cookie |
向服务器发送存储的 Cookie | Cookie: sessionid=abc123; token=xyz<br>维持会话状态 |
Referer |
当前请求来源页面的 URL | Referer: https://google.com<br>用于防盗链、统计来源 |
Origin |
请求发起的源（协议+域名+端口） | Origin: https://app.example.com<br>用于 CORS 跨域判断 |
Cache-Control |
控制缓存行为 | Cache-Control: no-cache 或 max-age=0<br>强制重新验证缓存 |
If-Modified-Since |
询问资源是否在指定时间后修改 | If-Modified-Since: Wed, 21 Oct 2023<br>配合 304 实现条件请求 |
If-None-Match |
询问资源 ETag 是否匹配 | If-None-Match: "abc123"<br>用于缓存验证，比时间更精确 |
Connection |
控制连接行为 | Connection: keep-alive 或 close<br>复用 TCP 连接提升性能 |
X-Requested-With |
标识请求是否为 AJAX | X-Requested-With: XMLHttpRequest<br>常用于识别异步请求（如 jQuery） |
X-Forwarded-For |
代理或负载均衡中，标识原始客户端 IP | X-Forwarded-For: 203.0.113.195<br>用于日志记录、限流 |
9. 说说TCP三次握手和四次挥手流程以及TCP为什么需要三次握手和四次挥手？
三次握手：
第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN(c)，此时客户端处于 SYN_SENT 状态。
第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，为了确认客户端的 SYN，将客户端的 ISN+1作为ACK的值，此时服务器处于 SYN_RCVD 的状态。
第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，值为服务器的ISN+1。此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。
A：“喂，能听到吗？”（SYN）
B：“听到了，你呢？”（SYN+ACK）
A：“我也听到了！”（ACK）
开始通话。
为什么是 三次握手？
为了 防止已失效的连接请求突然传到服务器，造成资源浪费**三次握手的作用：**
确保 双方都具备收发能力
防止 历史无效连接请求 被错误建立
同步双方的 初始序列号（用于可靠传输和去重）**四次挥手：**
第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态，停止发送数据，等待服务端的确认。此时客户端不再发送数据但是仍能接受数据。
第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态
第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。
A：“我说完了。”（FIN）
B：“好，我听到了。”（ACK）
B：“我也说完了。”（FIN）
A：“收到，再见。”（ACK）
为什么是 四次挥手？
因为TCP是全双工通信，需要链接的两端独立关闭。**四次挥手的作用：**
服务端在收到客户端断开连接Fin报文后，并不会立即关闭连接，
而是先发送一个ACK包先告诉客户端收到关闭连接的请求，
只有当服务器的所有报文发送完毕之后，才发送FIN报文断开连接，因此需要四次挥手。
| 问题 | 解答 |
|---|---|
| 为什么三次握手？ | 确保双向通信能力、同步序列号、防止历史连接请求造成资源浪费 |
| 为什么四次挥手？ | TCP 全双工，双方需独立关闭发送通道，确保数据完整传输 |
本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！