http基础知识
(一)HTTP和HTTPS(应用层)
HTTP无连接,无状态,明文,不安全 80
HTTPS加上了SSL/TLS证书 443
对称加密指的是加密和解密使用的秘钥都是同一个,是对称的。只要保证了密钥的安全,那整个通信过程就可以说具有了机密性.
非对称加密,存在两个秘钥,一个叫公钥,一个叫私钥。两个秘钥是不同的,公钥可以公开给任何人使用,私钥则需要保密。公钥和私钥都可以用来加密解密,但公钥加密后只能用私钥解密,反过来,私钥加密后也只能用公钥解密
数字签名能确定消息确实是由发送方签名并发出来的:签名和公钥一样完全公开,任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开,拿到摘要后,再比对原文验证完整性,就可以像签署文件一样证明消息确实是你发的。
1、重新计算签名内容:对收到的header和payload使用相同的哈希算法计算摘要
2、验证签名:用公钥验证数字签名是否确实是对这个摘要的合法签名(服务器端对header和payload的摘要使用服务器私钥进行签名运算)
- 服务器端签名生成:
- 对
header.payload
计算哈希摘要:hash = SHA256(header + "." + payload)
- 用服务器私钥对这个哈希值进行签名运算(不是简单加密):
signature = PrivateKeySign(hash)
- 对
- 客户端验证过程:
- 对收到的
header,payload
用相同哈希算法计算摘要:hash_received = SHA256(header + "." + payload)
- 用服务器公钥对签名值进行验证运算(不是简单解密):
hash_from_signature = PublicKeyVerify(signature)
- 比较
hash_received == hash_from_signature
- 对收到的
(二)常见请求头和响应头
常见请求头
请求头 | 作用 | 示例 |
---|---|---|
Host | 指定请求的目标服务器域名 | Host: example.com |
User-Agent | 标识客户端(浏览器/爬虫) | User-Agent: Mozilla/5.0 (Windows NT 10.0) |
Accept | 指定客户端能接收的响应数据类型 | Accept: text/html, application/json |
Accept-Language | 指定客户端偏好的语言 | Accept-Language: en-US, zh-CN |
Accept-Encoding | 指定客户端支持的压缩方式 | Accept-Encoding: gzip, deflate, br |
Content-Type | 指定请求体的数据类型 | Content-Type: application/json |
Content-Length | 指定请求体的字节长度 | Content-Length: 348 |
Authorization | 携带认证信息(如 JWT) | Authorization: Bearer xxxxxx |
Cookie | 发送服务器设置的 Cookie | Cookie: sessionId=abc123 |
Referer | 表示请求来源页面 | Referer: https://google.com |
Origin | 表示跨域请求的来源 | Origin: https://example.com |
Cache-Control | 控制缓存行为 | Cache-Control: no-cache |
If-None-Match | 配合 ETag 实现缓存 | If-None-Match: "abc123" |
If-Modified-Since | 检查资源是否更新 | If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT |
常见响应头
Content-Type | 指定响应体的数据类型 | Content-Type: application/json |
---|---|---|
Content-Length | 指定响应体的字节长度 | Content-Length: 1024 |
Content-Encoding | 指定响应体的压缩方式 | Content-Encoding: gzip |
Cache-Control | 控制缓存行为 | Cache-Control: max-age=3600 |
ETag | 资源唯一标识(用于缓存) | ETag: "abc123" |
Last-Modified | 资源最后修改时间 | Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT |
Set-Cookie | 服务器设置 Cookie | Set-Cookie: sessionId=abc123; Path=/ |
Access-Control-Allow-Origin | 允许跨域的源 | Access-Control-Allow-Origin: * |
Access-Control-Allow-Methods | 允许的 HTTP 方法 | Access-Control-Allow-Methods: GET, POST |
Access-Control-Allow-Headers | 允许的请求头 | Access-Control-Allow-Headers: Content-Type |
Location | 重定向目标 URL | Location: https://example.com/new-page |
Server | 服务器信息 | Server: nginx/1.18.0 |
WWW-Authenticate | 要求客户端认证 | WWW-Authenticate: Basic realm="Access" |
X-Powered-By | 服务器框架信息 | X-Powered-By: Express |
关键头部的详细说明
1、Content-Type
(请求/响应)
请求头:告诉服务器客户端发送的数据格式(如 application/json
)。
响应头:告诉浏览器如何解析返回的数据(如 text/html
)
2、Cache-Control
(缓存控制)
请求头:no-cache
(不缓存)、max-age=3600
(缓存 1 小时)。
响应头:public
(允许缓存)、no-store
(禁止缓存)。
3、Authorization
(认证)
用于携带 JWT、Basic Auth 等认证信息:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
4、CORS 相关头部
Access-Control-Allow-Origin
:允许跨域的源(*
表示所有)。
Access-Control-Allow-Methods
:允许的 HTTP 方法(如 GET, POST
)。
Access-Control-Allow-Headers
:允许的请求头(如 Content-Type
)。
5、Set-Cookie
(Cookie 设置)
服务器通过该头部设置 Cookie:
Set-Cookie: sessionId=abc123; Path=/; Secure; HttpOnly
Secure
:仅 HTTPS 传输。
Domain
:指定cookie生效的域名(默认为当前域名)
Path
:指定cookie生效的路径(例如/admin)
Expires/Max-Age
:设置过期时间
HttpOnly
:禁止 JavaScript 访问(防 XSS)
SameSite
:控制跨站请求时是否发送cookie(防CSRF攻击)
(三)UDP和TCP(传输层)
1、UDP:面向数据报的通信协议,对应用层交下来的报文,不合并,不拆分,只是在其上面加上首部后就交给了下面的网络层
- UDP 不提供复杂的控制机制,利用 IP 提供面向无连接的通信服务
- 传输途中出现丢包,UDP 也不负责重发
- 当包的到达顺序出现乱序时,UDP没有纠正的功能
- 并且它是将应用程序发来的数据在收到的那一刻,立即按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况,UDP 也无法进行流量控制等避免网络拥塞行为
2、TCP:面向字节流的通信协议,把上面应用层交下来的数据看成无结构的字节流来发送
面向链接,3次握手,4次挥手。
TCP | UDP | |
---|---|---|
可靠性 | 可靠 | 不可靠 |
连接性 | 面向连接 | 无连接 |
报文 | 面向字节流 | 面向报文 |
效率 | 传输效率低 | 传输效率高 |
双共性 | 全双工 | 一对一、一对多、多对一、多对多 |
流量控制 | 滑动窗口 | 无 |
拥塞控制 | 慢开始、拥塞避免、快重传、快恢复 | 无 |
传输效率 | 慢 | 快 |
(四)OSI七层模型
应用层(定义客户端与服务器之间的通信规则、HTTP)、表示层、会话层、传输层(UDP,TCP)、网络层(负责数据包的路由和寻址)、数据链路层(添加发送端 MAC 地址和接收端 MAC 地址后被封装成数据帧)、物理层
(五)TCP/IP五层协议
应用层、传输层、网络层、数据链路层和物理层
(六)DNS
域名和IP地址进行转换。
解析域名的过程:浏览器的DNS缓存、操作系统的DNS缓存、本地域名服务器采用递归查询自己的 DNS 缓存,查找成功则返回结果,本地域名服务器向上级域名服务器进行迭代查询(根、顶、权),本地、操作系统、浏览器均缓存得到的IP地址。
(七)CDN
内容分发网络:根据用户位置分配最近的资源
构建在现有网络基础之上的智能虚拟网络,依靠部署在各地的边缘服务器,通过中心平台的负载均衡、内容分发、调度等功能模块,使用户就近获取所需内容,降低网络拥塞,提高用户访问响应速度和命中率。
应用CDN
后,DNS
返回的不再是 IP
地址,而是一个CNAME
(Canonical Name ) 别名记录,指向CDN
的全局负载均衡。
(八)HTTP1.0/HTTP1.1/HTTP2.0
HTTP1.0:浏览器与服务器只保持短暂的连接,每次请求都需要与服务器建立一个TCP
连接
HTTP1.1:默认支持长连接(Connection: keep-alive
),即在一个TCP连接上可以传送多个HTTP
请求和响应,减少了建立和关闭连接的消耗和延迟,允许客户端不用等待上一次请求结果返回,就可以发出下一次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果
HTTP2.0:复用TCP
连接,在一个连接里,客户端和服务器都可以同时发送多个请求或回应,而且不用按照顺序一一对应,这样就避免了”队头堵塞”
(九)HTTP状态码
100:通知客户端它的部分请求已经被服务器接收,且仍未被拒绝。客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应。
- 206:服务器成功返回了客户端请求的部分内容(而非完整资源)。客户端通过 Range 请求头 指定需要资源的哪一部分,服务器返回对应的数据片段并附带
206
状态码。一般用来做断点续传,或者是视频文件等大文件的加载 - 301:永久重定向会缓存。新域名替换旧域名,旧的域名不再使用时,用户访问旧域名时用301就重定向到新的域名
- 302:临时重定向不会缓存,常用 于未登陆的用户访问用户中心重定向到登录页面
- 304:协商缓存,告诉客户端有缓存,直接使用缓存中的数据,返回页面的只有头部信息,是没有内容部分
- 400:参数有误,请求无法被服务器识别
- 401:表示客户端请求的资源需要身份验证,但当前请求未提供有效的认证凭证,或提供的凭证已失效。它是与用户认证直接相关的状态码。
- 403:告诉客户端禁止访问该站点或者资源,如在外网环境下,然后访问只有内网IP才能访问的时候则返回
- 404:服务器找不到资源时,或者服务器拒绝请求又不想说明理由时
- 500:服务器内部错误
- 503:服务器停机维护时,主动用503响应请求或 nginx 设置限速,超过限速,会返回503
- 504:网关超时
(十)GET和POST
都是TCP链接
get只被用来获取数据
post将实体提交到指定的资源,通常导致在服务器上的状态变化或副作用
- GET在浏览器回退时是无害的,而POST会再次提交请求。
- GET产生的URL地址可以被Bookmark,而POST不可以。
- GET请求会被浏览器主动cache,而POST不会,除非手动设置。
- GET请求只能进行url编码,而POST支持多种编码方式。
- GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。
- GET请求在URL中传送的参数是有长度限制的,而POST没有。
- 对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
- GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。
- GET参数通过URL传递,POST放在Request body中
(十一)浏览器缓存
cache-control:强制缓存
协商缓存:浏览器询问服务器资源是否变化,再决定是否使用缓存 状态码304
相关Header:
Last-Modified
+If-Modified-Since
ETag
+If-None-Match
当文件内容被修改但 Last-Modified
时间未更新时(如快速连续修改、时间戳精度不足)或者分布式服务器环境时钟不同步必须使用ETag
ETag
可以保证每一个资源是唯一的
Last-Modified/If-Modified-Since(If-Modified-Since比较资源的更新时间)
Last-modified: 服务器端资源的最后修改时间,响应头部会带上这个标识。第一次请求之后,浏览器记录这个时间,再次请求时,请求头部带上 If-Modified-Since 即为之前记录下的时间。服务器端收到带 If-Modified-Since 的请求后会去和资源的最后修改时间对比。若修改过就返回最新资源,状态码 200,若没有修改过则返回 304。
Etag/If-None-Match (ETag资源的匹配信息 If-Match比较实体标记(ETag) If-None-Match 比较实体标记 与 If-Match 相反) ETag是内容的hash
(十二)地址栏输入url敲下回车后发生什么
url解析,判断是url还是搜索的关键词;DNS查询获取目标服务器的IP地址;建立TCP链接;浏览器发送http请求到目标服务器;服务器响应请求,页面渲染
关于页面的渲染过程如下:
- 解析HTML,构建 DOM 树
- 解析 CSS ,生成 CSS 规则树
- 合并 DOM 树和 CSS 规则,生成 render 树
- 布局 render 树( Layout / reflow ),负责各元素尺寸、位置的计算
- 绘制 render 树( paint ),绘制页面像素信息
- 浏览器会将各层的信息发送给 GPU,GPU 会将各层合成( composite ),显示在屏幕上
(十三)TCP三次握手 四次挥手
- 第一次握手:客户端发送网络包,服务端收到了 这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。
- 第二次握手:服务端发包,客户端收到了 这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常
- 第三次握手:客户端发包,服务端收到了。 这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常
四次挥手原因:
服务端在收到客户端断开连接Fin
报文后,并不会立即关闭连接,而是先发送一个ACK
包告诉客户端收到关闭连接的请求,只有当服务器的所有报文发送完毕之后,才发送FIN
报文断开连接,因此需要四次挥手
(十四)Websocket
是一种网络传输协议,位于OSI
模型的应用层。可在单个TCP
连接上进行全双工通信,能更好的节省服务器资源和带宽并达到实时通迅。客户端和服务器只需要完成一次握手,两者之间就可以创建持久性的连接,并进行双向数据传输。
在websocket
出现之前,开发实时web
应用的方式为轮询,不停地向服务器发送 HTTP 请求,问有没有数据,有数据的话服务器就用响应报文回应。如果轮询的频率比较高,那么就可以近似地实现“实时通信”的效果。轮询的缺点也很明显,反复发送无效查询请求耗费了大量的带宽和 CPU
资源
(十五)路由
hash模式:url中带#号,改变#后的内容不会触发页面刷新,通过监听hashchange事件感知url变化,根据不同的hash值显示对应内容。兼容性好,不够美观
history模式:阻止 a 标签的默认行为,然后使用 history.pushState() 来改变 url 路径,它是不会引起页面的重新加载的,在 url 变更后,读取本地的 pathname 来判断要展示的组件。考虑到浏览器的前进后退按钮的存在,需要监听 popstate 事件,来判断要展示的对应的组件。需要服务器配置,将所有路径返回 index.html
,否则会 404。
history模式下的404问题:因为hash模式下的#后面的内容不会被包括在http请求中,对服务端完全没影响,因此改变hash不会重新加载页面。解决:对nginx
配置文件.conf
修改,添加try_files $uri $uri/ /index.html;
(十六)JWT
是一种用于身份验证的 JSON 格式 Token,由 Header、Payload、Signature 三部分组成。前端通常在登录后存储 JWT 到本地,后续请求通过 Authorization
头携带。用了 Axios请求拦截器自动附加 Token,并在响应拦截器实现了 Token 过期自动刷新(双token)。
头部:包含alg声明算法,typ默认为JWT
载荷:存放实际的内容,例如用户的id和name
签名:对头部和载荷进行签名,设置一个secretKey
Signature = HMACSHA256(base64Url(header)+.+base64Url(payload),secretKey)
- 服务器从收到的 JWT 中提取 Header 和 Payload(Base64解码后得到原始数据)
- 用相同的密钥和算法 重新计算哈希值
- 对比新计算的签名和 JWT 中的签名是否一致
(十七)攻击方式
xss:跨站脚本攻击,攻击者将恶意代码植入到提供给其他用户使用的页面中
CSRF:跨站请求伪造,攻击者诱导受害者进入第三方网站,在第三方网站中,向被攻击网站发送跨站请求,利用受害者在被攻击网站已经获取的注册凭证,绕过后台的用户验证,达到冒充用户对被攻击的网站执行某项操作的目的.