计算机网络-小林coding-HTTP篇

本系列笔记为作者在跟随小林coding学习的时候做的笔记。感谢小林大大。加上自己的笔记

HTTP 常见面试题

HTTP 基本概念

HTTP ：超文本传输协议HyperText Transfer Protocol。专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。

CSDN Ysming88 http报文详解

http请求报文内容：请求行+请求头部+空行+请求数据（体）

HTTP 常见的状态码有哪些

• 「101 Switch Protocols」升级协议，websocket就是使用该方法来从http升级过来的

• 「204 No Content」响应头没有 body 数据

• 「206 Partial Content」HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分

• 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问

• 「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问

301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL，尽量使用301，302可能会造成网址劫持，CSDN 一起荡起双桨

• 「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制
• 「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错
• 「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端
• 「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思
• 「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误
• 「503 Service Unavailable」表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思
• 500，400为可预见性错误

HTTP 常见字段有哪些

• Host 字段：客户端请求，指定服务器的域名
• Content-Length 字段：服务器回应，表明本次回应的数据长度（单位字节）

HTTP 协议通过设置回车符、换行符作为 HTTP header 的边界，通过 Content-Length 字段作为 HTTP body 的边界，这两个方式都是为了解决“粘包”的问题（HTTP报文可能会被拆分成多个TCP报文，不知道一个HTTP报文的边界在哪）

• Connection 字段：客户端请求，使用「 HTTP 长连接」机制

HTTP长连接即复用TCP连接，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

HTTP/1.1 版本的默认连接都是长连接，老版本需要设置该字段为Keep-Alive

TCP的Keepalive是它的保活机制，即客户端每隔一段时间（小于服务器的长连接超时时间keepalive_timeout）发送一个保活报文来重置服务端的长连接超时计时器。

• Content-Type 字段：服务器回应，本次数据是什么格式，如：Content-Type: text/html; charset=utf-8

客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式:Accept: */*

• Content-Encoding 字段：服务器回应，数据使用了什么压缩格式，如：Content-Encoding: gzip

客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法

GET 与 POST

GET 的语义是从服务器获取指定的资源。GET 请求的参数位置一般是写在 URL 中，URL 规定只能支持 ASCII， ，浏览器会对 URL 的长度有限制

POST 的语义是根据请求载荷（报文body）对指定的资源做出处理。携带数据的位置一般是写在报文 body 中， body 中的数据可以是任意格式的数据，浏览器不会对 body 大小做限制。

安全和幂等的概念

• 在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源
• 所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的

根据RFC规范，GET 方法一般不涉及修改数据是安全且幂等的，POST 涉及修改数据是不安全也不幂等的。可以对 GET 请求的数据做缓存，一般不会缓存 POST 请求

GET 请求可以带 body 吗？

RFC 规范并没有规定 GET 请求不能带 body 的。理论上，任何请求都可以带 body ，URL参数。

HTTP 缓存技术

两种实现：强制缓存和协商缓存

强制缓存：决定是否使用缓存的主动性在于浏览器这边。两个 HTTP 响应头部（Response Header）字段实现

• Cache-Control， 是一个相对时间；
• Expires，是一个绝对时间；

Cache-Control的优先级高于 Expires

Cache-Control 来实现强缓存。具体的实现流程如下：

1. 客户端第一次请求访问服务器资源时，服务器在 Response 头部加上 Cache-Control设置过期时间大小；
2. 客户端再次请求访问服务器中的该资源时，先比较时间与 Cache-Control 中设置的过期时间，计算该资源是否过期。没有过期使用缓存，否则重新请求服务器；
3. 服务器再次收到请求后，会设置 Response 头部的 Cache-Control

协商缓存：与服务端协商之后，通过协商结果（304）来判断是否使用本地缓存，两种头部字段实现

• 请求头添加If-Modified-Since字段（值为上次请求服务器响应的Last-Modified字段值）给服务器。如果在该值之后修改了就返回新数据并将最后修改时间Last-Modified添加到响应头返回200，否则直接返回304。基于时间
• 请求头添加If-None-Match字段（值为上次请求服务器响应的Etag字段值）给服务器。如果在该资源变化了就返回新数据并将Etag添加到响应头返回200，否则直接返回304。基于唯一标志

Etag 的优先级更高

HTTP 特性

HTTP/1.1

优点

1. 简单：基本的报文格式 header + body，头部信息 key-value
2. 灵活和易于扩展：请求方法、URI/URL、状态码、头字段组成可以自定义和扩充；下层可以随意变化
3. 应用广泛和跨平台

缺点

1. 无状态：解决方法Cookie，jwt
2. 明文传输：解决方法https
3. 不安全：不验证通信方的身份，无法证明报文的完整性，解决方法https

HTTP/1.1 的性能

1. 长连接：复用TCP
2. 管道网络传输：等待响应不阻塞发送请求（响应会按顺序发回来，先收到的请求响应会阻塞后收到的请求响应）
3. 队头阻塞：先进入发送队列的统一TCP请求被阻塞时会阻塞后进的

HTTP 与 HTTPS

区别

1. HTTP 明文传输，HTTPS 在 TCP 和 HTTP 之间加入了 SSL/TLS 安全协议加密传输
2. HTTPS 连接建立更复杂（SSL/TLS握手）
3. HTTP 默认80端口，HTTPS 默认443端口
4. HTTPS的服务器需要向CA申请证书

HTTPS 解决了 HTTP 哪些问题

• 窃听（机密性）：信息加密（混合加密）

• 篡改（完整性）：校验机制（摘要算法+数字签名）

• 冒充：身份证书（数字证书）

TLS流程

premaster是用服务端公钥加密的随机数，客户端在第三次握手时发送给服务端

客户端验证CA流程

证书信任链验证

HTTPS 的应用数据是如何保证完整性的

TLS 在实现上分为握手协议和记录协议两层：

• TLS 握手协议就是我们前面说的 TLS 四次握手的过程，负责协商加密算法和生成对称密钥，后续用此密钥来保护应用程序数据（即 HTTP 数据）；
• TLS 记录协议负责保护应用程序数据并验证其完整性和来源，所以对 HTTP 数据加密是使用记录协议；

HTTPS 一定安全可靠吗

当信任了中间人服务器证书，中间人就可以窃听修改

HTTPS 协议本身到目前为止还是没有任何漏洞的，即使你成功进行中间人攻击，本质上是利用了客户端的漏洞（用户点击继续访问或者被恶意导入伪造的根证书），并不是 HTTPS 不够安全。

抓包工具（如charles）截取 HTTPS 数据工作原理与中间人一致的

HTTP/1.1、HTTP/2、HTTP/3 演变

HTTP/1.1 相比 HTTP/1.0

• 长连接
• 管道（pipeline）网络传输：客户端可以不等待前一个请求的响应发送新请求

HTTP/2 优化

• 头部压缩
• 二进制格式
• 并发传输，多个stream复用同一个TCP
• 服务器主动推送资源

HTTP/3 优化

• 无队头阻塞：HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP
• 更快的连接建立
• 连接迁移

Websocket

见小林coding原文

Http和RPC区别

HTTP (HyperText Transfer Protocol) 和 RPC (Remote Procedure Call) 是两种不同类型的通信协议。它们主要的区别在于用途、性能、安全性和灵活性等方面。以下是它们的一些关键区别：

1. 用途：HTTP是为了让Web浏览器和服务器之间进行通信而设计的，它基于请求/响应模型，并且无状态。RPC则是一种更通用的协议，它允许一个程序在网络上调用另一个程序上的函数或过程，就像调用本地函数或过程一样。

2. 性能：RPC通常比HTTP更快，更高效，因为它更接近底层，而且可以使用各种各样的传输协议和编码方案。HTTP则是基于文本的，因此可能比较慢且冗余。

3. 安全性：HTTP支持各种各样的安全机制，如基本认证，摘要认证，SSL/TLS等。RPC的安全性依赖于使用的具体协议和实现，可能需要自行实现安全措施。

4. 灵活性：HTTP是基于REST架构风格的，它的灵活性较高，支持多种数据格式（如HTML、XML、JSON等），并且可以很容易地通过互联网路由。RPC通常需要特定的客户端和服务器代码，对网络的要求更高，但它支持更多的交互模式，如请求/响应，发布/订阅，点对点等。

在实际使用中，你可能会看到一种称为gRPC的框架，这是Google开发的一个高性能、开源的RPC框架。gRPC可以使用HTTP/2作为底层传输协议，使用Protocol Buffers作为接口定义语言和消息交换格式，从而结合了HTTP和RPC的优点

tcp如何保证可靠传输

TCP (Transmission Control Protocol) 是一个可靠的、面向连接的传输层协议。它通过以下机制来保证数据的可靠传输：

1. 确认和重传：当接收方收到数据包，它会向发送方发送确认信息（ACK）。如果发送方在一定的超时时间内未收到确认信息，它会重传数据包。这是 TCP 保证可靠传输的核心机制。

2. 序列号：TCP 为每一个发送的字节分配一个序列号，接收端根据这个序列号来重新组装数据，确保数据按照发送顺序被接收。

3. 流量控制：TCP 使用滑动窗口机制进行流量控制。这个窗口的大小由接收方决定，表示接收方当前能够接收的数据量。这确保了发送方不会因为发送数据过快而导致接收方处理不过来。

4. 拥塞控制：当网络出现拥塞，丢包率增加时，TCP 会减少发送数据的速率，避免因为网络拥塞而导致更多的数据丢失。当网络情况改善后，TCP 会逐步增加发送速率。

5. 错误检测：TCP 使用校验和（checksum）来检测数据在传输过程中是否出现错误。如果接收到的数据包校验和有误，那么这个数据包会被丢弃，然后依赖重传机制来获取丢弃的数据。

通过这些机制，TCP 能够在 IP 网络（一个不可靠的网络）上提供可靠的数据传输。