网络梳理

梳理思路
模块、价值点、实践

从url输入发生了什么
流程如下：

  1. url解析 （浏览器接收到用户输入的 URL，会解析出协议（如 HTTP、HTTPS）、域名、路径、查询参数等信息）
  2. dns解析（浏览器需要通过 DNS（域名系统）将域名转换为 IP 地址。浏览器会查询本地缓存、DNS 服务器，直到获得对应的 IP 地址）
  3. tcp三次握手（建立TCP连接 1. 客户端发送，2. 服务端接受，3. 客户端回复已接受 第三步是防止服务端发送请求丢失，浪费服务端资源做的优化）
  4. http请求（通过http协议发送请求）
  5. 服务端响应请求返回数据（服务器处理请求后，返回相应的数据（如状态码、HTML 内容等）给浏览器）
  6. tcp4次挥手（第一方发出FIN，另一方确认ACK，另一方也发送FIN,第一方确认ACK 考虑到端口可能会换程序，所以必须要亲自确认另一方关闭了，以免导致新程序占用端口后的数据混乱）
  7. 浏览器渲染

dns解析

tcp特性

  1. 三次握手，四次挥手

  2. 可靠的，有状态的

  3. 流量控制
    在 TCP 链接中，对于发送端和接收端而言，TCP 需要把发送的数据放到发送缓存区, 将接收的数据放到接收缓存区。
    而经常会存在发送端发送过多，而接收端无法消化的情况，所以就需要流量控制，就是在通过接收缓存区的大小，控制发送端的发送。
    如果对方的接收缓存区满了，就不能再继续发送了。而这种流量控制的过程就需要在发送端维护一个发送窗口，在接收端维持一个接收窗口。

TCP 滑动窗口分为两种: 发送窗口和接收窗口。
案例 流量控制调整案例

  1. 发送方发送数据包：
    发送方发送数据包 1, 2, 3（共 300 字节）。
  2. 接收方处理：
    接收方接收到数据包 1 和 2，处理完成后，发送 ACK 2，告知发送方已成功接收数据包 1 和 2，同时更新窗口大小为 100 字节。
  3. 发送方根据窗口大小调整：
    发送方收到 ACK 2，窗口滑动，发现新的窗口大小为 100 字节，因此可以继续发送一个数据包（数据包 4）。
  4. 控制流量：
    如果接收方的缓冲区再次满了，它可能会在后续的 ACK 中通告更小的窗口大小（例如 50 字节），这时发送方需要根据新的窗口大小调整发送速率，避免发送过多数据。

第一次发送的数据包远远大于接收缓冲区的处理能力的话，会触发 拥塞控制机制

例如发送端发送1000字节 接收方只能处理200字节 接收方处理完200字节后 发送ACK=2 新窗口大小为0
3. 拥塞控制 慢启动（初始化为一个最大报文段，每一个往返时间增加一个最大报文段，到达阈值后停止）
4. 拥塞控制 快速重传（丢包检测 发送方没收到ACK，会一直发送上一个包的ACK，这样发送方连续收到三次同一个ACK就会立重新即发送下一个包，而不是等待超时）
5. 拥塞控制 快速恢复（会调整发送窗口阈值，降为一半，然后等待新的ACK确认后再调整回去）

http梳理
HTTP特点：
优点: 灵活可扩展（传递内容不限）、可靠传输（基于TCP/IP）、应答、无状态。（每次 http 请求都是独立、无关的，默认不需要保留状态信息）。
缺点：无状态、明文传输、队头阻塞问题

http1.1请求方法:
GET: 通常用来获取资源
HEAD: 获取资源的元信息
POST: 提交数据，即上传数据
PUT: 修改数据
DELETE: 删除资源(几乎用不到)
CONNECT: 建立连接隧道，用于代理服务器
OPTIONS: 列出可对资源实行的请求方法，用来跨域请求
TRACE: 追踪请求-响应的传输路径

get post区别
编码
GET: 只能使用 URL 编码，且只能接收 ASCII 字符，参数通过 URL 传递。
POST: 支持多种编码方式（如 application/x-www-form-urlencoded 和 multipart/form-data），没有字符限制。

语义上的区别
GET: 用于请求数据，强调数据的获取。
POST: 用于提交数据，强调数据的处理和创建。

参数安全性
GET: 参数暴露在 URL 中，不适合传输敏感信息。
POST: 参数放在请求体中，较为安全，适合传输敏感信息。

幂等性
GET: 幂等操作，多次请求相同的 GET 不会改变服务器状态。
POST: 非幂等操作，多次请求可能会导致不同的结果（如多次提交表单）。

URI 编码
URI 只能使用ASCII, ASCII 之外的字符是不支持显示的，而且还有一部分符号是界定符，如果不加以处理就会导致解析出错。
因此，URI 引入了编码机制，将所有非 ASCII 码字符和界定符转为十六进制字节值，然后在前面加个%。
如，空格被转义成了%20，三元被转义成了%E4%B8%89%E5%85%83。

http状态码 与缓存机制

1xx (信息性):
表示请求已被接收，继续处理。
示例：100 Continue。

2xx (成功):
表示请求已成功处理。
示例：200 OK（请求成功）、201 Created（资源已创建）。

3xx (重定向):
表示请求需要进一步的操作才能完成。
示例：301 Moved Permanently（资源已永久移动）、302 Found（临时重定向）。
301 资源永久重定向
302 资源临时重定向
303 让你查看其他地址
304 请求的资源没有修改，服务端不会返回任何资源，协商缓存

4xx (客户端错误):
表示请求有错误，客户端需修正请求。
示例：404 Not Found（未找到资源）、403 Forbidden（拒绝访问）。
400 请求语法错误，服务器看不懂
401 请求没有携带信息，比如 token 认证失败
403 请求被拒绝、敏感词
404 找不到资源

5xx (服务器错误):
表示服务器处理请求时发生了错误。
示例：500 Internal Server Error（服务器内部错误）、502 Bad Gateway（错误的网关）。
500 服务器内部错误，无法完成请求
501 服务器不支持当前请求所需的功能
503 服务器系统维护或者超载，暂时无法处理客户端的请求

缓存机制
HTTP 的缓存机制用于提高 Web 应用的性能，减少服务器负载和响应时间。主要涉及以下概念：

缓存控制：
使用 HTTP 头部（如 Cache-Control, Expires, ETag 等）来指示缓存的行为。
Cache-Control 头：

  • public: 响应可以被任何中间缓存存储。
  • private: 响应只能被单个用户的缓存存储。
  • no-cache: 强制缓存检查源服务器是否有新鲜的副本。
  • no-store: 不缓存响应。

Expires 头：

  • 指定响应过期的时间，过期后，缓存不能再使用该响应。

ETag 和 Last-Modified：

  • ETag: 资源的唯一标识符，客户端可以用来验证缓存的有效性。
  • Last-Modified: 资源最后修改的时间，客户端可以根据此时间判断是否需要更新缓存。

状态码与缓存的关系

  • 304 Not Modified: 当客户端请求的资源未改变时，服务器可以返回此状态码，告诉客户端使用缓存版本，而不是重新传输数据。
  • Cache-Control 头中的指令会影响状态码的处理，例如，使用 no-cache 会强制检查服务器，而 max-age 则控制缓存的存活时间。

利用缓存机制做出的优化

  1. 使用合适的缓存头
    Cache-Control: 指定缓存的行为和有效期限。
    max-age: 设置资源的最大缓存时间（以秒为单位）。
    no-cache: 强制客户端在使用缓存之前检查是否有更新。
    no-store: 禁止缓存。
    Expires: 设置资源的过期时间，通常与 Cache-Control 一起使用。
  2. 利用 ETag 和 Last-Modified
    ETag: 为每个资源生成唯一标识符，客户端可以在再次请求时使用此标识符来检查资源是否已更改。
    Last-Modified: 通过返回资源的最后修改时间，客户端可以在请求时发送 If-Modified-Since 头部，服务器根据此时间判断是否返回新资源。
  3. 缓存静态资源
    静态资源: 对于图片、CSS、JavaScript 等静态文件，使用长时间的缓存策略（如 Cache-Control: public, max-age=31536000）来减少服务器负担。
    版本控制: 通过文件名或 URL 中添加版本号（例如 style.v1.css），确保更新时可以强制浏览器获取新版本。
  4. 动态内容的缓存
    短期缓存: 对于动态内容，可以使用短期缓存策略，并结合 Vary 头来处理不同的请求头（如用户代理、语言等）。
    边缘缓存: 使用内容分发网络（CDN）将动态内容缓存在离用户最近的节点，提高访问速度。
  5. 监控和分析缓存效果
    监控工具: 使用监控工具（如 Google Analytics、New Relic 等）跟踪缓存命中率和性能，确保缓存策略有效。
    分析响应时间: 定期分析页面加载时间和资源请求情况，调整缓存策略以优化性能。
  6. 安全性考虑
    敏感数据: 对于包含敏感信息的响应，确保使用 no-store 或 private，避免缓存不安全的内容。
    跨域请求: 注意 CORS（跨域资源共享）设置，确保跨域请求的缓存行为符合安全要求。
  7. 定期更新和清理缓存
    失效策略: 定期审查和更新缓存内容，确保用户获取到最新的信息。
    清理策略: 设定合理的清理策略，定期删除不再需要的缓存数据。
HTTP详解
http1.0,1996年简单网络网页网络请求
http1.1,1999年广泛应用在浏览器网络请求 

HTTP1.1
1. 缓存处理 HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag、If-Unmodified-Since、If-Match、If-None-Match 等更多可供选择
2. 带宽优化range 头域返回码206
3. 错误通知 新增多个错误的状态码
4. HOST头域
5. 支持长连接 keep-alive

在 HTTP/1 中，每次请求都会建立一次 HTTP 连接，也就是我们常说的 3 次握手和 4 次挥手，这个过程在一次请求过程中占用了相当长的时间。
即使开启了 Keep-Alive，解决了多次连接的问题，但是依然有两个效率上的问题，一是串行的文件传输，二是连接数过多导致的性能问题。

HTTP/2 的多路复用就是为了解决上述的两个性能问题。
在 HTTP/2 中，有两个非常重要的概念，分别是帧（frame）和流（stream）。
帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。
多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。
通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能。 
HTTP2.0
HTTP2.0 基本单位为二进制，以往是采用文本形式，健壮性不是很好，现在采用二进制格式，更方便更健壮。
HTTP2.0 的多路复用，把多个请求当做多个流，请求响应数据分成多个帧，不同流中的帧交错发送，解决了 TCP 连接数量多，TCP 连接慢，所以对于同一个域名只用创建一个连接就可以了。
HTTP2.0 压缩消息头，避免了重复请求头的传输，又减少了传输的大小；
HTTP2.0 服务端推送，浏览器发送请求后，服务端会主动发送与这个请求相关的资源，之后浏览器就不用再次发送后续的请求了；
HTTP2.0 可以设置请求优先级，可以按照优先级来解决阻塞的问题；

HTTP1.1
缓存处理新增 E-Tag、If-None-Match 之类的缓存来来控制缓存；
长连接，可以在一个 TCP 连接上发送多个请求和响应；

3.介绍 HTTPS 握手过程
客户端使用 https 的 url 访问 web 服务器，要求与服务器建立 ssl 连接；
web 服务器收到客户端请求后，会将网站的证书（包含公钥）传送一份给客户端；
客户端收到网站证书后会检查证书的颁发机构以及过期时间，如果没有问题就随机产生一个秘钥；
客户端利用公钥将会话秘钥加密，并传送给服务端，服务端利用自己的私钥解密出会话秘钥；
之后服务器与客户端使用秘钥加密传输；

4.HTTPS 握手过程中，客户端如何验证证书的合法性
首先浏览器读取证书中的证书所有者、有效期等信息进行校验，校验证书的网站域名是否与证书颁发的域名一致，校验证书是否在有效期内；
浏览器开始查找操作系统中已内置的受新人的证书发布机构 CA，与服务器发来的证书中的颁发者 CA 比对，用于校验证书是否为合法机构颁发；
如果找不到，浏览器就会报错，说明浏览器发来的证书是不可信任的；
如果找到，那么浏览器就会从操作系统中取出颁发者 CA 的公钥（多数浏览器开发商发布版本时，会实现在内部植入常用认证机关的公开密钥），
然后对服务器发来的证书里面的签名进行解密；
浏览器使用相同的 hash 算法计算出服务器发来的证书的 hash 值，将这个计算的 hash 值与证书中签名做迪比；
对比结果一致，则证明服务器发来的证书合法，没有被冒充

HTTPS 中间人攻击
https 协议由 http + ssl 协议构成。
中间人攻击过程如下：
服务器向客户端发送公钥；
攻击者截获公钥，保留在自己手上；
然后攻击者自己生成一个【伪造的】公钥，发给客户端；
客户端收到伪造的公钥后，生成加密 hash（秘钥） 值发给服务器；
攻击者获得加密 hash 值，用自己的私钥解密获得真秘钥；
同时生成假的加密 hash 值，发给服务器；
服务器用私钥解密获得假秘钥；
服务器用假秘钥加密传输信息；

防范方法：服务器在发送浏览器的公钥中加入 CA 证书，浏览器可以验证 CA 证书的有效性；（现有 HTTPS 很难被劫持，除非信任了劫持者的 CA 证书）

跨域浏览器同源策略
跨域是指浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的，是浏览器对JavaScript实施的安全限制。浏览器从一个域名的网页去请求另一个域名的资源时，出现域名、端口、协议任一不同，都属于跨域。
跨域解决方案：

  • 通过jsonp跨域
  • 跨域资源共享（CORS）
  • nginx代理跨域
  • nodejs中间件代理跨域
  • WebSocket协议跨域
  • postMessage跨域
  • document.domain + iframe跨域
  • location.hash + iframe
  • window.name + iframe跨域

跨域问题如何解决

JSONP
CORS（Cross-Origin-Resource-Share，跨域资源共享），由服务端设置
响应头通过浏览器的同源策略限制
Access-Control-Allow-Origin: *;
Access-Control-Allow-Methods: *;
Access-Control-Allow-Headers: *;
Access-Control-Allow-Credentials: true;

网络安全
XXS（跨站脚本攻击，Cross-Site Scripting）是一种常见的网络安全漏洞，攻击者通过在网页中注入恶意脚本，来窃取用户信息、会话 Cookies 或者执行其他恶意操作。以下是关于XXS攻击及其防御措施的详细介绍：

XXS攻击类型
存储型XXS：恶意脚本被存储在服务器上，用户访问该页面时执行。
反射型XXS：恶意脚本通过链接或请求参数反射到用户的浏览器中。
DOM型XXS：通过修改文档对象模型（DOM）来执行恶意脚本。

防御措施

  • 输入验证：
    对用户输入进行严格验证，确保只允许预期的数据格式。
    使用白名单过滤不安全的字符。
  • 输出编码：
    对输出内容进行适当编码，尤其是在HTML、JavaScript、CSS等上下文中。
    使用库（如OWASP Java Encoder、JavaScript的encodeURIComponent）来自动化编码过程。
  • 内容安全策略（CSP）：
    实施CSP头，限制可执行脚本的来源，防止加载未授权的脚本。
  • HttpOnly和Secure Cookie：
    对敏感Cookie设置HttpOnly属性，防止JavaScript访问。
    使用Secure属性，确保Cookie仅通过HTTPS传输。
  • 定期安全审计：
    定期检查和评估代码，寻找潜在的安全漏洞。
    采用自动化工具进行源代码分析和安全测试。

CSP（Content-Security-Policy）指的是内容安全策略，它的本质是建立一个白名单，告诉浏览器哪些外部资源可以加载和执行。
我们只需要配置规则，如何拦截由浏览器自己来实现。
通常有两种方式来开启 CSP，一种是设置 HTTP 首部中的Content-Security-Policy，一种是设置 meta 标签的方式

CSRF 攻击？如何防范 CSRF 攻击？
CSRF 攻击指的是跨站请求伪造攻击，攻击者诱导用户进入一个第三方网站，然后该网站向被攻击网站发送跨站请求。
如果用户在被攻击网站中保存了登录状态，那么攻击者就可以利用这个登录状态（cookie），绕过后台的用户验证，冒充用户向服务器执行一些操作。
CSRF 攻击的本质是利用了 cookie 会在同源请求中携带发送给服务器的特点，以此来实现用户的冒充。

防护方法：
同源检测，服务器检测请求来源；
使用 token 来进行验证；
设置 cookie 时设置 Samesite，限制 cookie 不能作为被第三方使用；

Cookie
HTTP Cookie，通常叫做Cookie，一开始是在客户端用于存储会话信息的。
Cookie主要构成

  • name：名称，一个唯一确定的cookie的名称，cookie的名称必须经过URL编码。
  • value：值，存储在cookie中的字符串值。值必须被URL编码。
  • Domain：域，指明cookie对哪个域有效，所有向该域发送的请求都会包含这个信息。
  • path：路径，对于指定域中的那个路径，应该向服务器发送cookie。
  • Expires/Max-Age：有效期，表示cookie的有效期。
  • HttpOnly：如果这个这个值设置为true，就不能通过JS脚本获取cookie的值。通过这个值可以有效防止XSS攻击。
  • Secure：安全标志，指定后，cookie只有在使用SSL连接的时候才能发送到服务器。

Cookie的原理
第一次访问网站时，浏览器发出请求，服务器响应请求后，会在响应头中添加一个Set-Cookie，将cookie放入响应请求中。
在第二次发起请求时，浏览器通过Cookie请求头部将cookie信息送给服务器，服务端根据cookie信息辨别用户身份。
Cookie的过期时间、域、路径、有效期、适用站点都可以根据需要来指定。
Cookie的生成
Cookie的生成方式主要有两种：服务端设置Cookie、客户端设置Cookie
服务端设置方式参考上面Cookie的原理，具体的实现方式自行查阅相关资料。
客户端设置Cookie方法如下：
document.cookie = "name=zhangsan; age=20"
Cookie的缺点

  • 每个特定域名下的cookie数量有限，不同浏览器数量限制不同。如果超过数量限制后再设置Cookie，浏览器就会清除以前设置的Cookie。
  • 大小只有4kb。
  • 每次HTTP请求都会默认带上Cookie，影响获取资源的效率。
  • Cookie的获取、设置、删除方法需要我们自己去封装。

SSL 连接断开后如何恢复？
Session ID
每一次的会话都有一个编号，当对话中断后，下一次重新连接时，只要客户端给出这个编号，服务器如果有这个编号的记录，那么双方就可以继续使用以前的密钥，而不用重新生成一把。
Session Ticket
session ticket 是服务器在上一次对话中发送给客户的，这个 ticket 是加密的，只有服务器可能够解密，里面包含了本次会话的信息，比如对话密钥和加密方法等。
这样不管我们的请求是否转移到其他的服务器上，当服务器将 ticket 解密以后，就能够获取上次对话的信息，就不用重新生成对话秘钥了。

什么是 CDN 服务？
CDN 是一个内容分发网络，通过对源网站资源的缓存，利用本身多台位于不同地域、不同运营商的服务器，向用户提供资源就近访问的功能。
也就是说，用户的请求并不是直接发送给源网站，而是发送给 CDN 服务器，由 CDN 服务器将请求定位到最近的含有该资源的服务器上去请求。
这样有利于提高网站的访问速度，同时通过这种方式也减轻了源服务器的访问压力。
CDN 访问过程
用户输入访问的域名,操作系统向 LocalDns 查询域名的 ip 地址.
2. LocalDns 向 ROOT DNS 查询域名的授权服务器(这里假设 LocalDns 缓存过期)
ROOT DNS 将域名授权 dns 记录回应给 LocalDns
LocalDns 得到域名的授权 dns 记录后,继续向域名授权 dns 查询域名的 ip 地址
域名授权 dns 查询域名记录后(一般是 CNAME )，回应给 LocalDns
LocalDns 得到域名记录后,向智能调度 DNS 查询域名的 ip 地址
智能调度 DNS 根据一定的算法和策略(比如静态拓扑，容量等),将最适合的 CDN 节点 ip 地址回应给 LocalDns
LocalDns 将得到的域名 ip 地址，回应给 用户端
用户得到域名 ip 地址后，访问站点服务器
CDN 节点服务器应答请求，将内容返回给客户端.(缓存服务器一方面在本地进行保存，以备以后使用，二方面把获取的数据返回给客户端，完成数据服务过程)

posted @ 2025-03-30 01:11  张正1998  阅读(40)  评论(0)    收藏  举报