本人学习过程中整理的知识点，包括OSI七层模型和TCP/IP四层协议，以及应用层HTTP协议、传输层TCP/UDP协议、网络层IP协议相关知识。
基础知识
浏览器输入URL到显示网页的步骤
- 解析URL，并准备生成HTTP请求。
- 查询浏览器缓存，若浏览器有缓存则直接返回资源，若无缓存则继续请求。
- DNS域名解析，获取URL对应IP地址
- 先按照本地浏览器、本地Host文件、路由器顺序查询缓存。
- 缓存未命中，则按照本地DNS服务器、根DNS服务器，根服务器再指示路径下服务器的顺序，层级解析域名，获取URL对应IP地址。
- TCP三次握手，客户端和服务器建立连接。若为HTTPS，还需TLS四次握手。
- 发送HTTP请求：经过协议层、网络层、网络接口层，构建HTTP请求报文，包括请求行、请求头，并将域名相关Cookie附加到请求头中。
- 服务器处理请求：服务器接收到HTTP请求后，处理请求并生成响应报文
- （若HTTP为短连接，则断开TCP连接）
- 浏览器解析响应，若响应为HTML文件，使用CSS文件渲染页面。
OSI模型和TCP/IP模型
- OSI模型：
- 由国际标准组织规定，将计算机通信网络分为七层，自顶向下分别是：
- 应用层：网络服务与最终用户的接口。
- 表示层：数据的表示、压缩、格式化、加密。
- 会话层：建立、管理、终止会话
- 传输层：定义传输数据的协议端口号，以及流量和差错校验。
- 网络层：逻辑地址寻址，不同网络之间的路径选择。
- 数据链路层：硬件地址寻址。
- 物理层：建立、维护、断开物理连接。
- TCP/IP协议：
- 将OSI七层模型简化为四层模型，在实际应用中更为广泛。自顶向下分别是：
- 应用层：将OSI模型的应用层、表示层、会话层结合，提供直接与用户程序交互的接口，为网络上的各种程序提供服务，包括电子邮件SMTP、网页浏览HTTP和文件传输FTP等。
- 传输层：对应OSI模型的传输层，提供端到端的数据传输，包括可靠传输的TCP协议，以及无需连接的UDP协议。
- 网络层：对应OSI模型的网络层，包括IPv4和IPv6协议，用于数据报文的寻址、路由和转发，选择最佳路径将数据报文从源IP发送到目标IP。
- 网络接口层：对应OSI模型的数据链路层和物理层，用ARP协议进行MAC寻址，在以太网、Wi-Fi等底层网络上用网卡进行信号的传输。
应用层（HTTP协议）
HTTP请求报文和响应报文的组成和常见字段
请求报文：
- 请求行：
- 方法：指定执行操作（GET/POST）
- 资源路径：请求资源的URL
- HTTP版本：HTTP/1.0或HTTP/2.0
- 请求头：
- Host：请求服务器的URL
- Accept：客户端能够接收的资源类型
- Accept- Encoding：客户端能够解码的编码类型
- Authorization：用于认证的凭证信息
- Content-Length：请求体的长度
- Content-Type：请求体的媒体类型
- Connection：管理连接的选项，如长连接Keep-Alive
- 空行：
- 用于分隔请求头和请求体
- 请求体：
- 通常在POST中，包含要发送给服务器的数据。
响应报文：
- 状态行：
- HTTP版本
- 状态码
- 状态消息
- 响应头：
- Content-Type：响应体的媒体类型
- Content-Length：响应体的字节数
- Server：指定服务器信息
- Expires：响应的过期时间
- Location：重定向的资源位置
- 空行：
- 分隔响应头和响应体
- 响应体：
- 服务器实际响应的数据，如文本、HTML页面、图片、视频等。
HTTP有哪些请求方式
- GET：请求制定资源
- POST：对指定资源提交数据，进行处理请求
- PUT：更新指定资源
- DELETE：删除指定资源
GET和POST的区别
- 用途：GET用来获取数据，POST用来提交数据进行处理。
- 数据位置：GET的数据直接存储在URL中，POST的数据存储在请求体中。
- 安全性：因此，GET的参数会直接暴露在URL中，导致安全性较低；POST则安全性较高。
- 数据大小：GET的大小受到URL大小的限制，POST的大小理论上没有限制。
- 幂等性：由于GET只是请求数据而不更改，相当于只读操作，即使多次进行GET请求也不会改变资源状态；POST请求则可能会改变资源状态，因此不是幂等的。
- 缓存：GET请求会被缓存，POST请求默认不会被缓存。
HTTP中常见的状态码
- 1xx：处于协议处理的中间状态
- 2xx：服务器成功处理客户端的请求并正确做出响应
- 200 OK：一切正常，其中服务器响应报文包含body
- 204 No Content：一切正常，服务器响应报文无body
- 206 Partial Content：成功，但服务器响应报文不完整。用于断点续传、分块下载等。
- 3xx：客户端请求资源更新，需重定向到新URL。新URL信息位于服务器响应报文响应头的Location字段
- 301 Move Permanently：永久重定向。请求资源不存在，需用新URL访问
- 302 Found：临时重定向。请求资源存在，但还是需要用新URL访问
- 304 Not Modified：缓存重定向。请求资源未变动，可直接使用浏览器缓存数据。
- 4xx：客户端错误码。请求报文有误，服务器无法处理。
- 400 Bad Request：仅笼统提示客户端请求报文有误
- 403 Forbidden：请求报文无误，但请求了超过客户端权限，禁止访问的内容
- 404 Not Found：请求资源不存在。
- 5xx：服务器错误码。请求报文无误，但服务器无法处理响应。
- 500 Internal Server Error：笼统提示服务器处理响应有误
- 501 Not Implement：客户端请求的功能暂未上线
- 502 Bad Gateway：服务器正常但访问后端出错
- 503 Service Unavailable：服务器正忙，暂时无法处理响应
HTTP/1.1和HTTP/1.0的区别
- 长连接：HTTP/0默认短连接，每次请求都需要建立一个TCP连接；HTTP/1默认长连接，每个TCP连接都可以复用，发送多个HTTP请求和响应，减少了TCP连接的开销。
- 管道化：由于HTTP/1.0不支持管道网络传输，所以HTTP请求需要等待响应返回后，才能发送第二个HTTP请求，会导致队头阻塞。HTTP/1.1支持管道网络传输，允许在前一个请求的响应未返回时发送之后的请求，避免了请求方的队头阻塞问题。但未解决服务器响应端的队头阻塞问题。
- 缓存控制：HTTP/1.0主要使用Expires和If-Modified-Since实现强缓存和协商缓存，HTTP/1.1额外支持使用ETag和If-None-Match，实现更可靠的缓存控制。
- 带宽优化：HTTP/1.0不支持断点续传，会浪费带宽。HTTP/1.1在请求头引入range字段，允许只请求资源的一部分，因此支持断点续传和分块下载。对应的响应状态码是206Partial Content。
HTTP/2.0和HTTP/1.1的区别：
- 头部压缩：HTTP/2.0引入HPACK压缩算法，对重复的请求头和响应头信息进行压缩，减少冗余，提高传输效率。
- 二进制传输：HTTP/1.1使用文本传输，客户端和服务器需要额外的编解码操作；HTTP/0采用计算机友好的二进制格式传输报文，提高解析效率。
- 并发传输：HTTP/2.0使用多路复用技术，能够在同一个TCP连接上并行交错发送多个请求和响应，从而避免HTTP/1.0和HTTP/1.1的请求与响应的队头阻塞问题。
- 服务器推送：HTTP/2.0支持服务器主动向客户端推送资源，如客户端请求HTML文件后，服务器主动推送CSS文件以支持渲染，从而减少请求响应次数，提高效率。
HTTP/3.0和HTTP/2.0的区别
- 无队头阻塞：由于HTTP/2.0基于TCP连接，当传输一个数据报文过程中发生丢包时，服务器无法组装TCP报文，导致响应端的队头阻塞。HTTP/3.0使用基于UDP的QUIC协议，无所谓丢包和传输顺序，因此彻底解决了队头阻塞问题。
- 零RTT连接建立：HTTP/0在TCP三次握手后，还需要进行TSL三次握手。而HTTP/3.0的TSL握手可以包含在UDP握手过程中，从而将RTT降到1。此外，在第二次连接，可以将传输的数据报文直接负载在握手信息，同时完成连接建立、秘钥协商和数据传输，达到0RTT的效果。
- 连接迁移：HTTP/0基于QUIC协议，能够在切换网络环境时复用原连接，消除重新连接进行握手的成本。
HTTPS和HTTP的区别
主要区别在于安全性和数据加密。
- 连接：HTTP仅需TCP三次握手即可建立连接，传输报文。HTTPS在TCP三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
- 端口：HTTPS 通常使用端口443 ，而HTTP 使用端口80。
- 加密层：HTTP 数据传输是明文的，无法保护隐私，且数据容易被篡改和冒充。HTTPS在HTTP的基础上增加SSL/TLS协议作为加密层，确保数据传输的安全性。
- 身份认证：HTTPS协议需要向CA申请数字证书，来保证服务器的身份是可信的，未被冒充。
HTTPS的工作原理
HTTPS主要基于SSL/TLS协议，确保了数据传输的安全性和完整性。其建立连接并传输数据的过程如下：
- 密钥交换：客户端发起HTTPS请求后，服务器会发送其公钥证书给客户端。
- 证书验证：客户端会验证服务器的证书是否由受信任的证书颁发机构（CA ）签发，并检查证书的有效性。
- 加密通信：一旦证书验证通过，客户端会生成一个随机的对称加密密钥，并使用服务器的公钥加密这个密钥，然后发送给服务器。
- 建立安全连接：服务器使用自己的私钥解密得到对称加密密钥，此时客户端和服务器都有了相同的密钥，可以进行加密和解密操作。
- 数据传输：使用对称加密密钥对所有传输的数据进行加密，确保数据在传输过程中的安全性。
- 完整性校验：SSL/TLS协议还包括消息完整性校验机制，如消息认证码，确保数据在传输过程中未被篡改。
- 结束连接：数据传输完成后，通信双方会进行会话密钥的销毁，以确保不会留下安全隐患。
传输层（TCP/UDP协议）
TCP和UDP的区别
- 连接：TCP是面向连接的协议，需要在数据传输前建立连接；UDP是无连接的，不需要建立连接。
- 可靠性：TCP提供可靠的数据传输，保证数据包的顺序和完整性；UDP不保证数据包的顺序或完整性。
- 拥塞控制：TCP具有拥塞控制机制，可以根据网络状况调整数据传输速率；UDP没有拥塞控制，发送速率通常固定。
- 流量控制：TCP通过滑动窗口机制进行流量控制，避免接收方处理不过来；UDP没有流量控制。
- 丢失重传：TCP能够检测并重传丢失或损坏的数据包；UDP不提供错误恢复机制。
- 报头格式：TCP有复杂的报文头部，包含序列号、确认号等信息；UDP的报文头部相对简单。
- 性能开销：由于TCP的连接建立、数据校验和重传机制，其性能开销通常比UDP大；UDP由于简单，性能开销小。
- 适用场景：TCP适用于需要可靠传输的应用，如网页浏览、文件传输等；UDP适用于对实时性要求高的应用，如语音通话、视频会议等。
TCP如何实现可靠性传输
TCP 是通过序列号、确认应答、超时重传、数据校验以及窗口控制等机制实现可靠性传输的。
- 序列号：每个TCP段都有一个序列号，确保数据包的顺序正确。
- 确认应答：接收方发送ACK确认收到的数据，如果发送方在一定时间内没有收到确认，会重新发送数据。
- 超时重传：发送方设置一个定时器，如果在定时器超时之前没有收到确认，发送方会重传数据。
- 数据校验：TCP使用校验和来检测数据在传输过程中是否出现错误，如果检测到错误，接收方会丢弃该数据包，并等待重传。
- 流量控制：TCP通过滑动窗口机制进行流量控制，确保接收方能够处理发送方的数据量。
- 拥塞控制：TCP通过算法如慢启动、拥塞避免、快重传和快恢复等，来控制数据的发送速率，防止网络拥塞。
TCP拥塞控制的实现
TCP拥塞控制可以在网络出现拥塞时动态地调整数据传输的速率，以防止网络过载。TCP拥塞控制的主要机制包括以下几个方面：
- 慢启动： 初始阶段，TCP发送方会以较小的发送窗口开始传输数据。随着每次成功收到确认的数据，发送方逐渐增加发送窗口的大小，实现指数级的增长，这称为慢启动。这有助于在网络刚开始传输时谨慎地逐步增加速率，以避免引发拥塞。
- 拥塞避免： 一旦达到一定的阈值（通常是慢启动阈值），TCP发送方就会进入拥塞避免阶段。在拥塞避免阶段，发送方以线性增加的方式增加发送窗口的大小，而不再是指数级的增长。这有助于控制发送速率，以避免引起网络拥塞。
- 快速重传： 如果发送方连续收到相同的确认，它会认为发生了数据包的丢失，并会快速重传未确认的数据包，而不必等待超时。这有助于更快地恢复由于拥塞引起的数据包丢失。
- 快速恢复： 在发生快速重传后，TCP进入快速恢复阶段。在这个阶段，发送方不会回到慢启动阶段，而是将慢启动阈值设置为当前窗口的一半，并将拥塞窗口大小设置为慢启动阈值加上已确认但未被快速重传的数据块的数量。这有助于更快地从拥塞中恢复。
TCP流量控制的实现
流量控制就是让发送方发送速率不要过快，让接收方来得及接收。利用滑动窗口机制就可以实施流量控制，主要方法就是动态调整发送方和接收方之间数据传输速率。
- 滑动窗口大小： 在TCP通信中，每个TCP报文段都包含一个窗口字段，该字段指示发送方可以发送多少字节的数据而不等待确认。这个窗口大小是动态调整的。
- 接收方窗口大小： 接收方通过TCP报文中的窗口字段告诉发送方自己当前的可接收窗口大小。这是接收方缓冲区中还有多少可用空间。
- 流量控制的目标： 流量控制的目标是确保发送方不要发送超过接收方缓冲区容量的数据。如果接收方的缓冲区快满了，它会减小窗口大小，通知发送方暂停发送，以防止溢出。
- 动态调整： 发送方会根据接收方的窗口大小动态调整发送数据的速率。如果接收方的窗口大小增加，发送方可以加速发送数据。如果窗口大小减小，发送方将减缓发送数据的速率。
- 确认机制： 接收方会定期发送确认（ACK）报文，告知发送方已成功接收数据。这也与流量控制密切相关，因为接收方可以通过ACK报文中的窗口字段来通知发送方它的当前窗口大小。
UDP如何实现可靠传输
UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。
传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。关键在于两点：
（1）提供超时重传，能避免数据报丢失。
（2）提供确认序列号，可以对数据报进行确认和排序。
- 本端：首先在UDP数据报定义一个首部，首部包含确认序列号和时间戳，时间戳是用来计算RTT(数据报传输的往返时间)，计算出合适的RTO(重传的超时时间)。然后以等-停的方式发送数据报，即收到对端的确认之后才发送下一个的数据报。当时间超时，本端重传数据报，同时RTO扩大为原来的两倍，重新开始计时。
- 对端：接受到一个数据报之后取下该数据报首部的时间戳和确认序列号，并添加本端的确认数据报首部之后发送给对端。根据此序列号对已收到的数据报进行排序并丢弃重复的数据报。
TCP三次握手的过程
- 第一次握手：客户端向服务器发送一个SYN （同步序列编号）报文，请求建立连接，客户端进入SYN_SENT状态。
- 第二次握手：服务器收到SYN 报文后，如果同意建立连接，则会发送一个SYN-ACK （同步确认）报文作为响应，同时进入SYN_RCVD 状态。
- 第三次握手：客户端收到服务器的SYN-ACK 报文后，会发送一个ACK （确认）报文作为最终响应，之后客户端和服务器都进入ESTABLISHED 状态，连接建立成功。
为什么需要三次握手
通过三次握手，客户端和服务器都能够确认对方的接收和发送能力。
- 第一次握手确认了客户端到服务器的通道是开放的；
- 第二次握手确认了服务器到客户端的通道是开放的；
- 第三次握手则确认了客户端接收到服务器的确认，从而确保了双方的通道都是可用的。
而如果仅使用两次握手，服务器可能无法确定客户端的接收能力是否正常，比如客户端可能已经关闭了连接，但之前发送的连接请求报文在网络上延迟到达了服务器，服务器就会主动去建立一个连接，但是客户端接收不到，导致资源的浪费。而四次握手可以优化为三次。
网络层（IPv4/IPv6）
DNS查询过程
DNS 用来将域名解析为IP地址。
- 本地DNS缓存检查：客户端首先查询本地DNS缓存，如果缓存中有对应的IP地址，则直接返回结果。
- 本地DNS服务器查询：如果本地缓存中没有，则会向本地的DNS服务器发送一个DNS查询请求。如果本地DNS服务器有该域名的IP地址，就会直接返回。
- 根DNS服务器查询：如果没有缓存该域名的解析记录，则本地DNS服务器会向根DNS服务器发出查询请求。根DNS服务器并不负责解析域名，而是返回顶级域名DNS服务器（.com/.net/.org）的地址，指引本地DNS继续查询。
- 顶级DNS服务器查询：本地DNS向指定的顶级域名DNS服务器发出查询请求。顶级域DNS服务器也不负责具体的域名解析，而是返回权威DNS服务器的IP地址。
- 权威DNS服务器查询：本地DNS解析器最后向权威DNS服务器发送查询请求。 权威DNS服务器是负责存储特定域名和IP地址映射的服务器。当权威DNS服务器收到查询请求时，它会查找请求域名对应的IP地址，并将结果返回给本地DNS解析器。
- 服务器响应并缓存：本地DNS将收到的IP地址返回给客户端，并且缓存域名解析结果，以便下次访问时更快地响应。
- 浏览器发起连接： 浏览器取得IP地址后，使用该IP地址与目标服务器建立连接，开始获取网页内容。
CDN是什么，有什么作用
CDN是一种分布式网络服务，通过将资源存储在分布式的服务器上，使用户可以从距离较近的服务器获取所需资源，从而加速互联网上的内容传输。
- 就近访问：CDN在全球范围内部署了多个服务器节点，用户的请求会被路由到距离最近的CDN节点，提供快速的内容访问。
- 内容缓存：CDN节点会缓存静态资源，如图片、样式表、脚本等。当用户请求访问这些资源时，CDN会首先检查是否已经缓存了该资源。如果有缓存，CDN节点会直接返回缓存的资源，如果没有缓存所需资源，它会从源服务器请求资源，并将资源缓存到节点中，以便以后的请求。
- 可用性：如果某些节点出现问题，用户请求可以被重定向到其他健康的节点。
Cookie和Session是什么
Cookie和Session都用于管理用户的状态和身份，Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。
- Cookie：客户端首次发送请求给服务器后，服务器会根据客户端信息创建Cookie，携带在响应报文中返回给客户端，然后客户端将这些Cookie存储在本地，在下次请求时带上Cookie。服务器在接收到携带Cookie的请求时，就解析Cookie，得到客户端的信息，动态生成对应的内容。
- Session：客户端首次访问服务器时，服务器为每个客户端分配一个唯一的Session ID，携带在Cookie上返回给客户端。客户端后续发送请求时，携带Cookie，服务器通过检查Cookie中的Session ID来区分不同用户，从而维护不同用户的登录状态、临时数据和上下文信息等。
Cookie和Session的区别
- 存储位置：Cookie数据存储在用户的浏览器中，而Session数据存储在服务器上。
- 数据容量：Cookie存储容量较小，一般为几KB。Session存储容量较大，通常没有固定限制，取决于服务器的配置和资源。
- 安全性：由于Cookie存储在用户浏览器中，因此可以被用户读取和篡改。相比之下，Session数据存储在服务器上，更难被用户访问和修改。
- 生命周期：Cookie可以设置过期时间，Session依赖于会话的持续时间或用户活动。
- 传输方式：Cookie在每次HTTP请求中都会被自动发送到服务器，而Session ID通常通过Cookie或URL参数传递。
44万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
