Networks

计算机网络模型

1.OSI七层模型

OSI（Open System Interconnect）七层模型是一种将计算机网络通信协议划分为七个不同层次的标准化框架。每一层都负责不同的功能，从物理连接到应用程序的处理。这种模型有助于不同的系统之间进行通信时，更好地理解和管理网络通信的过程。 OSI定义了网络互连的七层框架（物理层、数据链路层、网络层、传输层、会话层、表示层、应用层），即ISO开放互连系统参考模型。

• 应用层（Application Layer)：这是网络体系结构中的最顶层，提供用户接口和应用程序之间的通信服务。在这一层，用户可以访问各种网络应用程序，如电子邮件、文件传输和远程登录。

• 表示层（Presentation Layer）：该层负责数据的格式化、加密和压缩，以确保数据在不同系统之间的交换是有效的和安全的。它还提供了数据格式转换和语法转换的功能。\
• 会话层（Session Layer）：会话层管理应用程序之间的通信会话，负责建立、维护和终止会话。它还提供了数据的同步和检查点恢复功能，以确保通信的完整性和持续性。
• 传输层（Transport Layer）：传输层为应用程序提供端到端的数据传输服务，负责数据的分段、传输控制、错误恢复和流量控制。它主要使用 TCP（传输控制协议）和 UDP（用户数据报协议）来实现这些功能。
• 网络层（Network Layer）：网络层负责数据包的路由和转发，以及网络中的寻址和拥塞控制。它选择最佳的路径来传输数据包，以确保它们能够从源主机到目标主机进行传输。
• 数据链路层（Data Link Layer）：数据链路层提供点对点的数据传输服务，负责将原始比特流转换为数据帧，并检测和纠正传输中出现的错误。它还控制访问物理媒介的方式，以及数据帧的传输和接收。
• 物理层（Physical Layer）：物理层在物理媒介上传输原始比特流，定义了连接主机的硬件设备和传输媒介的规范。它确保比特流能够在网络中准确地传输，例如通过以太网、光纤和无线电波等媒介。

2.TCP/IP四层模型

TCP/IP 四层模型是目前被广泛采用的一种模型，由以下 4 层组成：应用层、传输层、网络层、网络接口层 应用层（Application Layer)类似于 OSI 模型中的应用层，负责处理用户与网络应用程序之间的通信。它包括诸如 HTTP、FTP、SMTP 等协议，用于实现不同类型的网络服务和应用。

传输层（Transport Layer）：与 OSI 模型中的传输层相对应，提供端到端的数据传输服务。在 TCP/IP 模型中，主要有两个协议：TCP（传输控制协议）和 UDP（用户数据报协议），用于确保可靠的数据传输和简单的数据传输。

网络层（Internet Layer）：相当于 OSI 模型中的网络层，负责数据包的路由和转发。它使用 IP（Internet Protocol）协议来定义数据包的传输路径，并处理不同网络之间的通信。

网络接口层（Link Layer）：与 OSI 模型中的数据链路层和物理层相对应，负责管理网络硬件设备和物理媒介之间的通信。它包括以太网、Wi-Fi、蓝牙等各种物理层和数据链路层协议。

3.常见协议

应用层常见协议

• HTTP（HyperText Transfer Protocol）：用于在客户端和服务器之间传输超文本数据，通常用于 Web 浏览器和 Web 服务器之间的通信。
• FTP（File Transfer Protocol）：用于在客户端和服务器之间传输文件，支持上传和下载文件的功能。
• SMTP（Simple Mail Transfer Protocol）：用于在邮件服务器之间传输电子邮件，负责发送邮件。
• POP3（Post Office Protocol version 3）：用于从邮件服务器上下载邮件到本地计算机，负责接收邮件。
• IMAP（Internet Message Access Protocol）：也是用于接收邮件的协议，与 POP3 类似，但提供了更丰富的功能，如在服务器上管理邮件等。
• DNS（Domain Name System）：用于将域名解析为对应的 IP 地址，从而实现域名和 IP 地址之间的映射。
• HTTPS（HyperText Transfer Protocol Secure）：是 HTTP 的安全版本，通过 SSL/TLS 加密传输数据，保证通信过程中的安全性。
• SSH（Secure Shell）：用于远程登录和执行命令，提供了加密的网络连接，保证了通信的安全性。
• SNMP（Simple Network Management Protocol）：用于网络设备之间的管理和监控，可以实现对网络设备的远程配置和监控。
• Telnet：用于远程登录和执行命令，类似于 SSH，但不提供加密功能，通信数据不安全。

传输层常见协议

• TCP（Transmission Control Protocol）：提供可靠的、面向连接的数据传输服务，确保数据的可靠性、顺序性和完整性。TCP适用于对数据传输质量要求较高的场景，如文件传输、网页浏览等。
• UDP（User Datagram Protocol）：提供无连接的数据传输服务，不保证数据的可靠性，也不保证数据的顺序性和完整性。UDP适用于实时性要求较高、对数据传输质量要求不那么严格的场景，如音视频传输、在线游戏等。

网络层常见协议

• IP（Internet Protocol）：是互联网中最基本的协议，用于在网络中传输数据包。IP协议定义了数据包的格式、寻址方式和路由选择等信息，是整个互联网的基础。

• ICMP（Internet Control Message Protocol）：用于在IP网络中传递控制消息和错误信息。ICMP通常用于网络设备之间的通信，如路由器和主机之间的通信，以及用于检测网络连通性和故障诊断。

• ARP（Address Resolution Protocol）：用于将IP地址映射为MAC地址（物理地址）。ARP协议在局域网内部使用，通过发送ARP请求获取目标设备的MAC地址，从而实现数据包的传输。

• RARP（Reverse Address Resolution Protocol）：与ARP相反，用于将MAC地址映射为IP地址。RARP协议通常用于无盘工作站等设备，可以根据MAC地址获取对应的IP地址。

• IPv6（Internet Protocol version 6）：是IP协议的下一代版本，用于解决IPv4地址空间不足的问题。IPv6采用128位地址长度，提供了更大的地址空间，支持更多的设备连接到互联网。

网络接口层常见协议

• 以太网协议（Ethernet）：是一种常见的局域网技术，使用MAC地址进行帧的传输和接收。
• 无线局域网协议（Wi-Fi）：用于无线局域网的数据传输，通常基于IEEE 802.11标准。
• 点对点协议（PPP）：用于建立点对点连接的协议，通常用于拨号连接和虚拟专用网（VPN）等场景。
• 数据链路层交换协议（DLC）：用于在数据链路层进行数据交换和管理的协议，如HDLC、SLIP和PPP等。 本文转自 https://blog.csdn.net/weixin_44772566/article/details/136717134，如有侵权，请联系删除。

从输入URL到页面展示的详细过程

可以借鉴更详细版本：小林coding'

记得最开始学前端知识时，是一点一点的积累，一个知识点一个知识点的攻克。 就这样，虽然在很长一段时间内积累了不少的知识，但是，总是无法将它串联到一起。每次梳理时都是很分散的，无法保持思路连贯性。 直到最近，在将DNS域名解析、建立TCP连接、构建HTTP请求、浏览器渲染过程‘’流程梳理一遍后，感觉就跟打通了任督二脉一样，有了一个整体的架构，以前的知识点都连贯起来了，至少现在知道了它的大部分骨架。 梳理出一个知识体系，以后就算再学新的知识，也会尽量往这个体系上靠拢，环环相扣，更容易理解，也更不容易遗忘。这也是本文的目标。

1. 浏览器接收到用户请求，首先读取浏览器缓存里看是否有缓存该资源，如果有直接返回；如果没有，进入下一步的网络请求流程

检验新鲜通常有两个HTTP头进⾏控制 Expires 和 Cache-Control：

（1）HTTP1.0提供 Expires，值为⼀个绝对时间表示缓存新鲜⽇期

（2）HTTP1.1增加了Cache-Control: max-age=time，值为以秒为单位的最⼤新鲜时间

2. 浏览器接收url并开启一个新进程（这一部分可以展开浏览器的进程与线程的关系）；解析输入的 URL，提取出其中的协议、域名和路径等信息。（这部分涉及URL组成部分）
3. 浏览器向 DNS 服务器发送请求，DNS服务器通过多层查询 将该域名解析为对应的IP地址 ，如果请求协议是HTTPS，那么还需要建立TLS连接。

DNS解析时，会按本地浏览器缓存->本地nost文件->路由器缓存->dns服务器->根dns服务器的顺序查询域名对应的IP地址，直到找到为止；

4. 浏览器与服务器建立 TCP 连接。（这部分涉及TCP三次握手/四次挥手/5层网络协议）

打开⼀个socket与⽬标IP地址，端⼝建⽴TCP链接，三次握⼿如下：

（1）客户端发送⼀个TCP的SYN=1，Seq=X的包到服务器端口

（2）服务器发回SYN=1， ACK=X+1， Seq=Y的响应包

（3）客户端发送ACK=Y+1， Seq=Z

5. 浏览器向服务器发送 HTTP 请求，包含请求头和请求体,并把和该域名相关的cookie等数据附加到请求头中。（4,5,6,7包含http头部、响应码、报文结构、cookie等知识）
6. 服务器接收并处理请求，并返回响应数据，包含状态码、响应头和响应体。
7. 浏览器接收到响应数据，解析响应头和响应体，并根据状态码判断是否成功。

(1)解析HTML⽂档，构件DOM树，下载资源，构造CSSOM树，执⾏js脚本，这些操作没有严 格的先后顺序

(2)最后将绘制的结果合成最终的页面图像，显示在屏幕上。这个过程会发生回流和重绘）。

8. 连接结束 -> 断开TCP连接 四次挥手

浏览器接收HTTP响应，然后根据情况选择关闭TCP连接或者保留重⽤，关闭TCP连接的四次握⼿如下：

• 主动⽅发送Fin=1， Ack=Z， Seq= X报⽂

• 被动⽅发送ACK=X+1， Seq=Z报⽂

• 被动⽅发送Fin=1， ACK=X， Seq=Y报⽂

• 主动⽅发送ACK=Y， Seq=X报⽂

本文转自 https://blog.csdn.net/Newbie___/article/details/107212575，如有侵权，请联系删除。

补充：

从输入URL到Web页面呈现的全过程 - 掘金 (juejin.cn)

DNS解析

DNS（Domain Name System）是一种用于将域名解析为IP地址的系统。（把我们的域名映射为IP地址，这就是DNS的作用） 它可以将人们易于记忆的域名转换为服务器可识别的IP地址，这样用户就可以使用域名访问网站，而不必直接输入数字格式的IP地址。

在浏览器中输入网址时，电脑会先向DNS服务器发送请求，获取该网址对应的IP地址，并在成功获取后直接连接该IP地址对应的服务器，在服务器端获取网页内容并显示出来，完成整个访问过程。因此，DNS在互联网中起着至关重要的作用。

IP（Internet Protocol）地址是一个数字标识，用于唯一识别连接到互联网上的每个计算机、服务器和其他设备。域名则是网站的人类可读的名称。域名系统（DNS服务器）可以将域名转换为与之关联的IP地址。 简单来说，IP地址是网络设备的标识符，而域名则是方便人们记忆和使用的网络地址别名。 域名系统通过将 域名 映射到 IP地址，使互联网上的用户能够以易记的方式访问特定的网站或服务器。

DNS域名解析过程

1. 首先会在浏览器缓存中查询是否有该域名对应的IP地址，

• 若有则直接返回，解析过程结束。

• 如果浏览器缓存中没有该域名对应的IP地址，则向本地DNS服务器发送查询请求。

  • 如果本地DNS服务器缓存中有该域名对应的IP地址，则直接返回，解析过程结束。

  • 如果本地DNS服务器缓存中没有该域名对应的IP地址，则向根域名服务器发送查询请求。

    • 根域名服务器返回一个所查询域的顶级域名服务器地址。
    • 本地DNS服务器向 顶级域名服务器 发送查询请求。
      • 顶级域名服务器返回下一级DNS服务器的地址（权威DNS服务器）。
      • 本地DNS服务器向权威DNS服务器发送查询请求。
        • 权威DNS服务器返回该域名对应的IP地址，并将结果返回给本地DNS服务器。

本地DNS服务器将结果保存在缓存中，便于下次使用。并将结果返回给浏览器。

浏览器将结果保存在缓存中，并使用该IP地址访问对应的网站。

从上面的过程可以看到，DNS的查询方式分为两种，一种是递归，一种是迭代。
递归查询指的是如果 A 请求 B，那么 B 作为请求的接收者，一定要给 A 想要的答案。
迭代查询指的是，如果接收者 B 没有请求者 A 所需要的准确内容，接收者 B 将告诉请求者 A，如何去获得这个内容，但是自己并不去发出请求。
在实际应用中，递归查询通常用于从请求主机到本地 DNS 服务器的查询，而迭代查询则用于本地 DNS 服务器向根域名服务器或者顶级域名服务器发出查询请求。

DNS解析时发现域名和IP不一致，访问了该域名会如何？

• 域名和IP不一致，域名解析成了其他的的IP地址，但是这个IP地址正确。访问该域名就会访问其他的网站。

知乎上有一个阿里巴巴的回答： 从技术上来讲是可以解析到任意IP地址的，这时候针对这个地址发起HTTP访问，HTTP头中的host字段会是你的域名（而非该IP对应站点的域名），如果对方的网站HTTP服务器没有做对应的防护就可以访问，如果对方的网站HTTP服务器有防护则无法访问。

• 域名和IP不一致，域名解析成了其他的的IP地址，但是这个IP地址错误，访问该域名就会失败。

可参考：DNS解析时发现域名和IP不一致，访问了该域名会如何（大厂真题）

TCP/IP握手

拿到了IP地址后，就可以发起HTTP请求了。HTTP请求的本质就是TCP/IP的请求构建。建立连接时需要 3次握手 进行验证，断开链接也同样需要 4次挥手 进行验证，保证传输的可靠性。

1. 三次握手

模拟三次握手（场景对话版）：

客户端：hello，你是server么？ 服务端：hello，我是server，你是client么 客户端：yes，我是client

可通过下方图文结合方式字理解三次握手：

三次握手​​​​​​​原理：

第一次握手：客户端发送一个带有 SYN（synchronize同步）标志的数据包给服务端。

第二次握手：服务端接收成功后，回传一个带有 SYN/ACK 标志的数据包传递确认信息，表示我收到了。

第三次握手：客户端再回传一个带有 ACK 标志的数据包，表示我知道了，握手结束。

其中：SYN标志位数置1，表示建立TCP连接；ACK表示响应，置1时表示响应确认。

三次握手过程详细说明： 刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。

1. 第一次握手: 客户端发送标识位SYN = 1，随机产生序列号seq = x的数据包到服务端，服务端由SYN = 1知道客户端要建立连接，并进入SYN_SENT状态，等待服务器确认；（SYN=1，seq=x，x为随机生成的数值）
2. 第二次握手: 服务器收到请求并确认联机信息后，向客户端发送标识位SYN = 1，ACK = 1和随机产生的序列号seq = y, 确认码ack number = x+1（客户端发送的seq+1）的数据包，此时服务器进入SYN_RCVD状态；（SYN=1，ACK=1，seq=y，y为随机生成的数值，确认号 ack=x+1）这里ack加1可以理解为时确认和谁建立连接。
3. 第三次握手：客户端收到后检查确认码ack number是否正确，即和第一次握手发送的序列号加1结果是否相等，以及ACK标识位是否为1；若正确，客户端发送标识位ACK = 1、seq = x + 1和确认码ack = y + 1（服务器发送的seq+1）到服务器，服务器收到后确认ACK=1和seq是否正确，若正确则完成建立连接，此包发送完毕，客户端和服务器进入ESTAB_LISHED状态。完成三次握手，客户端与服务器开始传送数据.。（ACK=1，seq=x+1，ack=y+1）

TCP 三次握手的建立连接的过程就是相互确认初始序号的过程。告诉对方，什么样序号的报文段能够被正确接收。 第三次握手的作用是： 客户端对服务器端的初始序列号的确认，如果只使用两次握手，那么服务器就没有办法知道自己的序号是否已被确认。同时这样也是为了防止失效的请求报文被服务器接收，而出现错误的情况。

2.四次挥手

模拟四次挥手（场景对话版）：

主动方：我已经关闭了向你那边的主动通道了，只能被动接收了 ；

被动方：收到通道关闭的信息，我这还有数据没有发送完成，你等下

被动方：那我也告诉你，我这边向你的主动通道也关闭了

主动方：最后收到数据，之后双方无法通信

可通过下方图文结合方式理解四次挥手：

四次挥手原理：

第一次挥手：客户端发送一个FIN，用来关闭客户端到服务器的数据传送，并且指定一个序列号。客户端进入FIN_WAIT_1状态。

第二次挥手：服务器收到FIN后，发送一个ACK给客户端，确认序号为客户端的序列号值 +1 ，表明已经收到客户端的报文了，此时服务器处于 CLOSE_WAIT 状态。

第三次挥手：服务器发送一个FIN，用来关闭服务器到客户端的数据传送，服务器进入LAST_ACK状态。

第四次挥手：客户端收到FIN后，客户端进入TIME_WAIT状态，接着发送一个ACK给服务器，确认序号为收到序号+1 ，服务器收到确认后进入CLOSED状态，完成四次挥手。

其中：FIN标志位数置1，表示断开TCP连接。

四次挥手过程详细说明：

刚开始双方都处于 ESTABLISHED 状态，假如是客户端先发起关闭请求。

1. 第一次挥手：客户端发送一个FIN = 1、初始化序列号seq = u，到服务器，表示需要断开TCP连接，客户端进入FIN_WAIT_1状态，等待服务器的确认。（FIN = 1，seq = u，u由客户端随机生成）
2. 第二次挥手：服务器收到这个FIN，它发回ACK = 1、seq序列号（由回复端随机生成）、确认序号ack为收到的序号加1（ack = u+1）；以便客户端收到信息时，知晓自己的TCP断开请求已经得到验证。服务器进入CLOSE_WAIT，等待关闭连接；客户端进入FIN_WAIT_2，稍后关闭连接。（ACK = 1，seq = v，ack = u+1）
3. 第三次挥手：服务器在回复完客户端的TCP断开请求后，不会马上进行TCP连接的断开。服务器会先确保断开前，所有传输到客户端的数据是否已经传输完毕，一旦确认传输完毕，就会发回FIN = 1，ACK = 1,seq = w和确认码ack = u+1给客户端，服务器进入LAST_ACK 状态，等待最后一次ACK确认;（FIN = 1，ACK = 1,seq = w，ack = u+1 ，w由服务器端随机生成）
4. 第四次挥手：客户端收到服务器的TCP断开请求后，会回复服务器的断开请求。包含ACK = 1、随机生成的seq = u+1，并将确认序号设置为收到序号加1（ack = w+1）到服务器，从而完成服务器请求的验证回复。客户端进入TIME-WAIT 状态，此时 TCP 未释放掉，需要等待 2MSL 以确保服务器收到自己的 ACK 报文后进入CLOSE状态，服务端进入CLOSE状态。（ACK = 1，seq = u+1，ack = w+1）

注意：为什么 TIME_WAIT 等待的时间是 2MSL？ 1）MSL 是 报文最大生存时间，一来一回需要等待 2 倍的时间。 2）最后一次挥手中，客户端会等待一段时间再关闭的原因，是为了防止发送给服务器的确认报文段丢失或者出错，从而导致服务器 端不能正常关闭。

---

常用关键词总结

• SYN标志位用来建立TCP连接。如果SYN=1而ACK=0，表明它是一个连接请求；如果SYN=1且ACK=1，则表示同意建立一个连接。
• ACK表示响应，置1时表示确认号（为合法，为0的时候表示数据段不包含确认信息，确认号被忽略。)
• FIN表示关闭连接，置1时表示发端完成发送任务。用来释放连接，表明发送方已经没有数据发送了。

为什么需要四次挥手呢？

1. TCP协议 的连接是全双工的，即数据传输可以同时在两个方向上进行。所以终止连接时，需要每个方向都单独关闭。（单独一方的连接关闭，只代表不能再向对方发送数据，连接处于的是半关闭状态）
2. 客户端发送FIN报文终止连接后，服务器可能还有数据需要发送（比如上一次的响应），所以服务器会先发送ACK报文确认收到FIN报文，并将未发送的数据发送出去，然后再发送自己的FIN报文终止连接。
3. 客户端接收到服务器的FIN报文后也需要发送ACK报文确认收到，才能正式关闭连接。

为什么是三次握手？不是两次、四次？

为了确认双方的 接收能力 和 发送能力 都正常。

如果是用两次握手，则会出现下面这种情况： 如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，此时客户端共发出了两个连接请求报文段。 其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络节点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误以为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手；只要服务端发出确认，就建立新的连接了。此时客户端忽略服务端发来的确认，也不发送数据，则服务端一直等待客户端发送数据，浪费了资源。

TCP/IP的分层管理

按层次分为以下四层：应用层、传输层、网络层和数据链路层。

为什么要分层呢？

分层是有一定好处的。比如，如果互联网是由一个协议统筹，某个地方需要改变设计时，就必须把所有部分整体替换掉。而分层之后只需把变动的层替换掉即可。把各层之间的接口部分规划好之后，每个层次内部的设计就能够自由改动了。

各层的作用：

1. 应用层（DNS，HTTP协议）DNS将域名解析成IP地址并发送HTTP请求，OSI 参考模型中最靠近用户的一层。
2. 传输层（TCP，UDP） 建立TCP连接（三次握手），客户端和服务端数据传输就是在这层进行的。
3. 网络层（IP，ARP地址解析协议）IP寻址及路由选择；所起的作用就是在众多的选项内选择一条传输线路。
4. 数据链路层：用来处理连接网络的硬件部分，硬件上的范畴均在链路层的作用范围之内。

其实就是一个概念：从客户端发出HTTP请求到服务器接收，中间会经过一系列的流程。

简括就是：从应用层 DNS 将域名解析成 IP 地址，并发送 HTTP 请求，到传输层通过三次握手建立tcp/ip连接，再到网络层的ip寻址，再到数据链路层的封装成帧，利用物理介质传输。

当然，服务端的接收就是反过来的步骤。发送端从应用层往下走，接收端则从链路层往上走。

举例，其实分层这部分大致了解下，知道怎么回事就可以啦。

我们用HTTP举例来说明，首先作为发送端的客户端在应用层（HTTP协议）发出某个想看Web页面的HTTP请求。 接着，为了传输方便，在传输层（TCP协议）把应用层处收到的数据（HTTP请求报文）进行分割，并在各个报文上打上标记序号及端口号转发给网络层。 在网络层（IP协议），增加作为通信目的地的MAC地址后转发给链路层。这样一来，发往网络的通信请求就准备齐全了。 接收端的服务器在链路层接收到数据，瞬狙往上层发送，一直到应用层。当传输到应用层，才算真正接收到由客户端发送过来的HTTP请求。

本文部分内容转自 https://zhuanlan.zhihu.com/p/689679647，如有侵权，请联系删除。

发送 HTTP 请求

HTTP请求报文都有什么组成？

HTTP请求报文主要由三个部分组成：请求行、请求头和请求体。具体如下：

请求行：包含请求方法、URI（请求的资源路径）和HTTP协议版本。例如：GET /index.html HTTP/1.1。 请求头（Header）: 包含了客户端向服务器发送的附加信息，例如浏览器类型、字符编码、认证信息等。请求头以键值对的形式存在，多个键值对之间以换行符分隔。例如：Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7。 请求体（Body） : 存放请求参数，即浏览器向服务器传输数据的实体部分。常用于POST方法提交请求时，发送表单数据、JSON数据等类型的数据。

需要注意的是，并不是所有的HTTP请求都必须带有请求体，像GET请求通常不需要发送请求体。

为什么 HTTP 报文中要存在 “空行”? 因为 HTTP 协议并没有规定报头部分的键值对有多少个。空行就相当于是 “报头的结束标记”, 或者是 “报头和正文之间的分隔符”。 HTTP 在传输层依赖 TCP 协议, TCP 是面向字节流的. 如果没有这个空行, 就会出现 “粘包问题”

常见状态码含义

区分状态码

1××开头 - 信息性状态码，表示HTTP请求已被接收，需要进一步处理。

2××开头 - 成功状态码，表示请求已成功处理完成。

3××开头 - 重定向状态码，表示请求需要进一步的操作以完成。

4××开头 - 客户端错误状态码，表示请求包含错误或无法完成。

5××开头 - 服务器错误状态码，表示服务器无法完成有效的请求。

常见状态码

200 - 请求成功，从客户端发送给服务器的请求被正常处理并返回

301 - 表示被请求的资源已经被永久移动到新的URI（永久重定向） 302 - 表示被请求的资源已经被临时移动到新的URI（临时重定向） 304 - 表示服务器资源未被修改；通常是在客户端发出了一个条件请求，服务器通过比较资源的修改时间来确定资源是否已被修改

400 - 服务器不理解请求，请求报文中存在语法错误 401 - 请求需要身份验证 403 - 服务器拒绝请求（访问权限出现问题） 404 - 被请求的资源不存在 405 - 不允许的HTTP请求方法，意味着正在使用的HTTP请求方法不被服务器允许

500 - 服务器内部错误，无法完成请求 503 - 服务器当前无法处理请求，一般是因为过载或维护

请求/响应头部

请求和响应头部也是分析时常用到的。

常用的请求头部（部分）：

Accept: 接收类型，表示浏览器支持的MIME类型 （对标服务端返回的Content-Type） Accept-Encoding：浏览器支持的压缩类型,如gzip等,超出类型不能接收 Content-Type：客户端发送出去实体内容的类型 Cache-Control: 指定请求和响应遵循的缓存机制，如no-cache If-Modified-Since：对应服务端的Last-Modified，用来匹配看文件是否变动，只能精确到1s之内，http1.0中 Expires：缓存控制，在这个时间内不会请求，直接使用缓存，http1.0，而且是服务端时间 Max-age：代表资源在本地缓存多少秒，有效时间内不会请求，而是使用缓存，http1.1中 If-None-Match：对应服务端的ETag，用来匹配文件内容是否改变（非常精确），http1.1中 Cookie: 有cookie并且同域访问时会自动带上 Connection: 当浏览器与服务器通信时对于长连接如何进行处理,如keep-alive Host：请求的服务器URL Origin：最初的请求是从哪里发起的（只会精确到端口）,Origin比Referer更尊重隐私 Referer：该页面的来源URL(适用于所有类型的请求，会精确到详细页面地址，csrf拦截常用到这个字段) User-Agent：用户客户端的一些必要信息，如UA头部等

常用的响应头部（部分）：

Access-Control-Allow-Headers: 服务器端允许的请求Headers Access-Control-Allow-Methods: 服务器端允许的请求方法 Access-Control-Allow-Origin: 服务器端允许的请求Origin头部（譬如为*） Content-Type：服务端返回的实体内容的类型 Date：数据从服务器发送的时间 Cache-Control：告诉浏览器或其他客户，什么环境可以安全的缓存文档 Last-Modified：请求资源的最后修改时间 Expires：应该在什么时候认为文档已经过期,从而不再缓存它 Max-age：客户端的本地资源应该缓存多少秒，开启了Cache-Control后有效 ETag：请求变量的实体标签的当前值 Set-Cookie：设置和页面关联的cookie，服务器通过这个头部把cookie传给客户端 Keep-Alive：如果客户端有keep-alive，服务端也会有响应（如timeout=38） Server：服务器的一些相关信息

一般来说，请求头部和响应头部是匹配分析的。 譬如，请求头部的Accept要和响应头部的Content-Type匹配，否则会报错。 譬如，跨域请求时，请求头部的Origin要匹配响应头部的Access-Control-Allow-Origin，否则会报跨域错误。 譬如，在使用缓存时，请求头部的If-Modified-Since、If-None-Match分别和响应头部的Last-Modified、ETag对应。

注意点：请求头 和 响应头 中的 Content-Type ，是不一样的。

请求头的Content-Type常见取值：

javascript复制代码application/x-www-from-urlencoded  //以键值对的数据格式提交
multipart/form-data //用于上传文件图片等二进制数据

响应头的Content-Type常见取值：

javascript复制代码text/html // body 数据格式是 HTML
text/css  // body 数据格式是 CSS
application/javascript // body 数据格式是 JavaScript
application/json //body 数据格式是 JSON （最常见的）

请求/响应体

http 请求 时，除了头部，还有消息实体，一般来说， 请求实体中会将一些需要的参数都放入（用于post请求）。 比如实体中可以放参数的序列化形式（a=1&b=2这种），或者直接放表单对象（Form Data 对象，上传时可以夹杂参数以及文件）等等。

而一般 响应实体中，就是放服务端需要返给客户端的内容。 一般现在的接口请求时，实体中就是信息的json格式，而像页面请求这种，里面直接放了一个html字符串，然后浏览器自己解析并渲染。

如下图所示（post请求发送给接口的数据）

注意点：

1. 不是所有的HTTP请求都必须带有请求体，像GET请求通常不需要发送请求体。
2. 响应完成之后怎么办？TCP 连接就断开了吗？

不一定。这时候要判断Connection字段, 如果请求头或响应头中包含Connection: Keep-Alive， 表示建立了持久连接，这样TCP连接会一直保持，之后请求统一站点的资源会复用这个连接。否则断开TCP连接, 请求-响应流程结束。

HTTP 与 HTTPS

HTTP 与 HTTPS 有哪些区别？

• HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
• HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
• 两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。
• HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

HTTPS 解决了 HTTP 的哪些问题？

HTTP 由于是明文传输，所以安全上存在以下三个风险：

• 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
• 篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
• 冒充风险，比如冒充淘宝网站，用户钱容易没。

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，可以很好的解决了上述的风险：

• 信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
• 校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。
• 身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。

可见，只要自身不做「恶」，SSL/TLS 协议是能保证通信是安全的。

HTTPS 是如何解决上面的三个风险的？

• 混合加密的方式实现信息的机密性，解决了窃听的风险。
• 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。
• 将服务器公钥放入到数字证书中，解决了冒充的风险。

---

之前有读者在字节面试的时候，被问到：HTTPS 一定安全可靠吗？

这个问题的场景是这样的：客户端通过浏览器向服务端发起 HTTPS 请求时，被「假基站」转发到了一个「中间人服务器」，于是客户端是和「中间人服务器」完成了 TLS 握手，然后这个「中间人服务器」再与真正的服务端完成 TLS 握手。

答：从客户端的角度看，其实并不知道网络中存在中间人服务器这个角色。那么中间人就可以解开浏览器发起的 HTTPS 请求里的数据，也可以解开服务端响应给浏览器的 HTTPS 响应数据。相当于，中间人能够 “偷看” 浏览器与服务端之间的 HTTPS 请求和响应的数据。

但是要发生这种场景是有前提的，前提是用户点击接受了中间人服务器的证书。

中间人服务器与客户端在 TLS 握手过程中，实际上发送了自己伪造的证书给浏览器，而这个伪造的证书是能被浏览器（客户端）识别出是非法的，于是就会提醒用户该证书存在问题。

HTTP/1.1 相比 HTTP/1.0 提高了什么性能？

HTTP/1.1 相比 HTTP/1.0 性能上的改进：

• 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
• 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

但 HTTP/1.1 还是有性能瓶颈：

• 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；
• 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
• 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
• 没有请求优先级控制；
• 请求只能从客户端开始，服务器只能被动响应。

负载均衡

日常生活中总会有一些拥挤的地方，比如地铁站、医院、火车站等。其实根据我们的经验，无论是挂号，还是排队入场，这些场所一都会设置多个服务点或者入口的
但是，在这些地方你总会发现，最近的入口会挤满人：而那些距离较远的服务点就宽松很多。而如果有人引导的话，实际情况就会好转，整个服务点都会均到部分压力，而不至于让某个服务点太忙，另一个服务点又太闲
那么，在网络世界中，这些服务点就相当于服务器，而那个所调的引导者就相当于负载均衡了。

一个集群式网站的建设。如果没有任何机制来导用户的话，完全随机或者就近原则话，那么很容易导致某些服务器的流量很大，而另外一个服务器的qps很小。这不仅严重的浪费了资源，而且还会导致拉长用户访问网站的RT，影响用户的体验

负载均衡器将传入的网络流量分配到多台服务器上，以确保没有单个服务器承受过多的负载。通过有效地分发请求，它们提高了应用程序的容量和可靠性。以下是负载均衡中常用的一些策略和算法：

1. 轮询法

轮询法是负载均衡的最简单形式，其中池中的每台服务器按顺序接收请求，循环轮转。当到达最后一台服务器时，它将回到第一台。
这对于具有相似规格且负载可以均匀分配的服务器效果良好。

2. 最少连接

最少连接算法将流量引导到具有最少活动连接的服务器。在会话长度和需求不均匀的情况下特别有用。
在任务较长或服务器负载不均匀的情况下是理想的选择。

3. 最短响应时间

这个以响应时间最短且活动连接最少的服务器为目标的算法是以响应性为重点。
在目标是为请求提供最快响应时效果很好。

4. IP散列

IP散列根据客户端IP地址的哈希确定哪个服务器接收请求。这确保客户端始终连接到同一台服务器。
在需要在应用程序中实现会话持久性的情况下很有用，以确保客户端始终连接到相同的服务器。

5. 加权算法