网络模型
七层网络（OSI）
通信特点：对等通信（源和目的端对等层通信）
（1）应用层 为应用提供服务
最靠近用户的一层，为用户提供应用接口和网络服务
协议：HTTP HTTPS FTP SMTP DNS
（2）表示层 数据格式转换、数据加密
用于应用层数据的转换，确保应用层之间发送的数据可被互相识别
（3）会话层 建立、管理、维护会话
负责建立、管理、终止表示层通信，保证长时间文件传输不被打断
（4）传输层 建立、管理、维护端到端的连接
负责端到端的传输，保证数据的完整性和可靠性
协议： TCP协议 UDP协议
（5）网络层 数据包路由选择和转发
提供 IP 地址，处理数据包的路由和转发，以及流量控制
实现： Router路由
（6）数据链路层 提供介质访问和链路管理
将网络层的 IP 数据封装成帧，一对一和一对多的数据传输
实现：Switch交换机 Wi-Fi无线局域网
（7）物理层
负责网络设备之间的物理连接和传输介质，如电缆类型、连接器、信号类型
常用设备: 网线 光纤
TCP/IP五层协议
应用层：为应用进程提供服务
传输层： 负责为两台主机中的进程提供通信服务
网络层： 选择合适的路由在两台主机间传递，源IP和目标IP
数据链路层：将网络层的 IP 数据封装成帧，并在链路的两个相邻节点间传送
物理层：确保数据可以在各种物理媒介上进行传输
HTTP协议
HTTP（Hyper Text Transfer Protocol）： 全称超文本传输协议，是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。
HTTP 是一种应用层协议，是基于 TCP/IP 通信协议来传递数据的，其中 HTTP1.0、HTTP1.1、HTTP2.0 均为 TCP 实现，HTTP3.0 基于 UDP 实现。现主流使用 HTTP1.0 和 HTTP3.0
非持久性连接与持久性连接
非持久性连接的缺点：
必须为每个请求对象建立并维护一个全新连接
对于每个这样的连接，在客户端和服务端之间都要分配TCP的缓冲区和保持TCP变量，一台web服务器需要同时服务许多客户端请求，所以给web服务器带来严重负担
HTTP1.0性能问题：每发起一次请求，需新建一次TCP连接（三次握手）并且为串行请求，进行了无谓的TCP连接和断开，增加通信开销
HTTP1.1更新了长连接的通信方式：也叫持久连接
持久性连接-减少了TCP重复的建立连接和断开造成的开销，减轻服务器负载
长连接的特点-任意一端没有提出断开连接，则保持TCP连接状态
HTTP请求特征
优点:
简单-请求报文格式为header+body，头部信息为key-value的简单文本形式，易于理解
灵活、易于扩展-HTTP协议的各类请求方法、URI/URL、状态码、头字段等组成允许开发人员自定义和扩充，因为HTTP协议工作在应用层（OSI第七层）允许下层随意变化
应用广泛、跨平台-台式机到手机上的web与应用，都使用了HTTP协议
缺点：
无状态-HTTP不会保留 关于客户的任何信息
明文传输-报文是文本形式，会暴露给外界，不安全
不安全-HTTP 协议本身不提供加密和认证机制，无法保证数据的机密性和完整性。
HTTP请求格式
主要以下四部分组成：
首行：描述请求的基本信息，包括方法、URL、版本号
报头（header）：使用键值对形式详细说明报文，每个键值对占用一行，键和值之间用冒号+空格分割
空行（CRLF，空格换行）：空行是协议头结束的标志
报文、消息正文（body）：实际传输的数据，可以使用超文本形式，如图片、音/视频等数据，也称作请求体；正文允许为空，若正文存在，则使用Content-Length属性标识正文长度
HTTP响应格式
主要以下四部分组成：
首行：描述响应的基本信息，包括版本号、状态码、状态码解释
报头（header）：使用键值对形式详细说明报文，每个键值对占用一行，键和值之间用冒号+空格分割
空行（CRLF，空格换行）：空行是协议头结束的标志
报文、消息正文（body）：实际传输的数据，可以使用超文本形式，如图片、音/视频等数据，也称作请求体；正文允许为空，若正文存在，则使用Content-Length属性标识正文长度；若服务器返回一个HTML页面，则HTML页面的内容在正文中
为什么 HTTP 报文中要存在空行？
因为 HTTP 协议并没有规定报头部分的键值对有多少个，使用空行就相当于是报文的结束标记或报文和正文之间的分隔符
HTTP 在传输层依赖 TCP 协议，TCP 是面向字节流的。如果没有这个空行，就会出现”粘包问题“
粘包：定义：TCP 是面向字节流的协议，数据连续传输，没有消息边界。如果多个报文在传输中被合并成一个数据块，接收方无法区分每个报文的起始和结束位置，这种现象称为粘包。
方法
首行的第一部分
GET-获取资源
POST-传输实体主体
PUT： 与 POST 相似，但是具有幂等特性，一般用于更新
DELETE： 删除服务器指定资源
OPTIONS： 返回服务器所支持的请求方法
HEAD： 与 GET 类似，只不过响应体不返回，只返回响应头
TRACE： 能显示服务器端收到的请求，测试的时候会用到
CONNECT： 预留，暂无使用
GET方法
基本介绍：
最常用的 HTTP 方法，常用于获取服务器上的某个资源。以下几种方式都会触发 GET 方法的请求：
在浏览器中直接输入 URL 回车或点击浏览器收藏夹中的链接，此时浏览器就会发送出一个 GET 请求。
HTML 中的 link、img、script 等标签的属性中放的 URL，浏览器也会构造出 HTTP GET 请求
各种编程语言（只要能够访问网络，例如 Javascript 中的ajax），就都能够构造出 HTTP GET 请求
GET 请求的特点：
首行里的第一部分是 GET
URL 里面的 query string 可以为空，也可以不为空
GET 请求的 header 有若干个键值对结构
GET 请求的 body 一般是空的
POST 方法
基本介绍：
多用于提交用户输入的数据给服务器（如登录页面）。以下几种方法都会触发 POST 方法的请求:
通过 HTML 中的 form 标签可以构造 POST 请求
使用 JavaScript 的 ajax 可以构造 POST 请求
POST 请求的特点：
首行里的第一部分是 POST
URL 里面的 query string 一般是空的
POST 请求的 header 里面有若干个键值对
POST 请求的 body 一般不为空（body 的具体数据格式，由 header 中的 Content-Type 来描述；body 的具体数据长度，由 header 中的 Content-Length 来描述
GET 和 POST 的区别
GET 和 POST 其实没有本质区别，使用 GET 的场景完全可以使用 POST 代替，使用 POST 的场景一样可以使用 GET 代替。但是在具体的使用上，还是存在一些细节的区别：
GET传输客户端的数据通过查询字符串（query string）传输，body为空；主要用于获取数据，不会改变服务器状态。URL长度受浏览器限制，GET 请求相对不安全，因为数据以明文形式附加在 URL 中，容易被截获和篡改，然而，GET 请求可以被缓存，浏览器和服务器通常会缓存 GET 请求的结果，GET 请求的 URL 可以被书签和共享，因为数据直接附加在 URL 中，用户可以通过复制 URL 来访问相同的数据。
POST传输客户端的数据通过请求体（body）传输，query string为空；主要用于提交数据和改变服务器状态，如提交表单、上传文件、创建资源等。POST 请求没有 URL 长度限制，理论上无大小限制，实际受限于服务器配置。POST 请求相对安全，因为数据不可见，但需要结合 HTTPS 以确保数据传输的安全性。POST 请求默认不缓存，POST 请求的 URL 无法被书签和共享，因为数据在请求体中，用户无法通过复制 URL 来访问相同的数据。
一般情况下要求处理GET请求为幂等；POST则不要求
GET 请求可以被缓存、被浏览器保存到收藏夹中（因为数据在 URL 中）；POST 请求不能被缓存（因为数据在请求体中）
幂等定义：同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。换句话说，幂等的方法不应该具有副作用。
GET、HEAD、PUT 和 DELETE 等方法是幂等的；POST：不是幂等的，因为每次提交可能创建新资源
GET 请求的 URL 长度问题
RFC 2616 标准正确的解释： HTTP 协议由 RFC 2616 标准定义，该标准中明确说明HTTP对 URL 的长度没有任何限制
URL 的长度取决因素： URL 的长度取决于浏览器的实现和 HTTP 服务器端的实现。
POST与GET的安全问题
网上一种错误说法：实现登录页面，如果使用 GET 实现登录，GET 习惯上把数据放到 query string 中，此时就能看到浏览器的 URL 中显示当前的用户名和密码了，所以就并不安全；而 POST 习惯上会把数据放到 body 中，因此登录时就不能直接看到用户名和密码，就安全
正确理解： 安全问题取决于是否加密以及加密算法的强度。本质上二者安全性相等，但GET的隐私性(数据可见)弱于POST（数据不可见，但需要结合HTTPS）
GET 不只能传输文本数据
网上一种错误说法: GET 只能传输文本数据；POST 可以传输文本数据，也可以传输二进制数据
正确理解： GET 也可以传输二进制数据，虽然不能直接在 query string 中传输二进制数据，但是可以针对二进制数据进行 urlencode，转码后就可以放到 url 中；GET 还可以直接将二进制数据放到 body 中
POST 和 PUT 区别
POST：专注于创建数据
PUT：专注于更新数据
URL的组成
URL-统一资源定位符，互连网上的每个文件都有一个唯一的 URL，它包含的信息指出文件的位置以及浏览器应该怎么处理它
标准格式：
协议类型: [//服务器地址[:端口号]] [/资源层级 UNIX 文件路径] 文件名 [?查询字符串] [#片段标识符]
完整格式：
协议类型: [//[访问资源需要的凭证信息@]服务器地址[:端口号]] [/资源层级 UNIX 文件路径] 文件名 [?查询字符串] [#片段标识符]
URL组成部分
例如：www.aspxfans.com:8080/news/index.…
协议部分：使用的协议是HTTP/HTTPS。
域名部分：表示请求的服务器域名或IP地址。
端口部分：表示服务器使用的端口号
虚拟目录部分：服务器上的虚拟目录路径。
文件名部分：最后一个 / 到 ？结束
参数部分：表示传递给服务器的参数，参数之间由 & 分隔
锚部分：# 开始到最后，用于直接定位到页面中的某个特定位置。
需要 urlencode 的原因：
将url里本身具有特殊意义的字符使用%转义
兼容不同字符规则
使用工具转义即可
请求报头（header）
header格式：键值对，键和值之间用冒号+空格分割
常见报头
Host-表示服务器主机的地址和端口（地址可以是域名，也可以是 IP；端口号可以省略或者手动指定）
Content-Length-表示 body 的数据长度，长度单位是字节
Content-Type-表示 body 的数据格式，以下介绍三种请求中的数据格式：
application/x-www-form-urlencoded
用途： form 表单提交的数据格式
特点：此时body结构类似键值对，键值对之间用&分隔，键与值之间用=分隔
multipart/form-data
用途： form 表单提交的数据格式，实现文件上传或混合数据提交
特点：每个表单字段作为独立部分传输，需要在<form>标签添加enctype="multipart/form-data"属性，传递二进制文件如 HTML 提交图片或者文件
-
enctype`属性？
指定了表单数据在发送到服务器时的编码格式，三种值：
application/x-www-form-urlencoded（默认值）普通文本multipart/form-data”必须用于文件上传text/plain（很少用）数据为纯文本格式
User-Agent（简称 UA）-表示浏览器或者操作系统的属性，早期非常有用，根据UA检测页面的兼容性
Mozilla/5.0 (Windows NT 10.0; Win64; x64)//表示操作系统信息 AppleWebKit/537.36 (KHTML, like Gecko)Chrome/91.0.4472.77 Safari/537.36//表示浏览器信息
Referer-表示这个页面是从哪个页面跳转过来的
很有用的字段，为了统计某广告在某一浏览器的点击次数，就可以通过 Referer 字段来查看。
注意： 如果直接在浏览器中输入 URL 或直接通过收藏夹访问页面时，是没有 Referer 的
Cookie-浏览器提供的一种让程序员在本地存储数据的能力
为什么需要Cookie：数据不能存在硬盘里，可能会被浏览器注入病毒；浏览器为了保证安全性，禁止网页中的代码访问主机的硬盘（无法在 JS 中读写文件），因此也就失去了持久化存储的能力，故Cookie很重要
Cookie 里面存的是什么？：存储了一个键值对结构的字符串，键值对之间使用
;分割，键和值之间使用=分割Cookie 来自哪里，如何往 Cookie 中存储数据：可能来自客户端（网页）自行通过 JS 写入，也可能来自于服务器在 HTTP 响应的 header 中通过 Set-Cookie 字段给浏览器返回数据。
浏览器如何维护：按照域名维度来存储
Cookie的历程：首次浏览器返回给服务器不携带Cookie，服务器通过Set-Cookie返回键值对给浏览器；再次访问浏览器携带Cookie给服务器，服务器使用Cookie的值，如果Cookie的值有变化则给浏览器返回新的Set-Cookie
经典应用：保持客户端的登录
缺陷：每次请求都要把该域名下所有的 Cookie 通过 HTTP 请求传给服务器，因此 Cookie 的存储容量是有限的
Accept-浏览器能够处理的内容类型 Connection-浏览器与服务器之间连接的类型
缓存相关的HTTP请求头（缓存机制）
强缓存（响应头）：强缓存是浏览器缓存机制中的一种策略，通过设置缓存资源的过期时间，使得客户端可以在一定时间内直接从本地缓存获取资源，而无需向服务器发送请求。
Expires：指定资源的过期时间，是一个绝对时间点。
Cache-Control：指定资源的缓存策略，是一个相对时间。
协商缓存（请求头和响应头）：协商缓存（也称为条件缓存）是另一种 HTTP 缓存机制，它允许浏览器在缓存的资源过期后，通过与服务器进行通信来验证缓存的资源是否仍然是最新的。如果资源未被修改，服务器会告诉浏览器可以继续使用缓存的版本；
If-None-Match（浏览器请求）、If-Modified-Since（浏览器请求）
Etag(服务器返回) Last-Modified（服务器返回）
HTTP响应
状态码
定义：服务器对客户端请求的响应状态的标识
| 类别 | 原因 | 描述 |
|---|---|---|
| 1xx | Informational(信息性状态码) | 接受的请求正在处理 |
| 2xx | Success(成功状态码) | 请求正常处理完毕 |
| 3xx | Redirection(重定向状态码) | 需要进一步的操作才能完成请求 |
| 4xx | Client Error (客户端错误状态码) | 客户端的请求有错误，服务器无法处理 |
| 5xx | Server Error(服务器错误状态码) | 服务器在处理请求时发生了错误 |
2xx 成功
200 OK 请求正常处理完毕
204 No Content 正常处理，没有返回内容（响应体无主体）
206 Partial Content 客户端进行了范围请求（响应报文中有 Content-Range 指定范围的实体内容）
3xx 重定向
301 Moved Permanently 永久重定向
请求的资源已经分配了新的 URL，在响应头的 Location 首部字段中指出
了新的URL，搜索引擎会在新网址上抓取内容
使用场景：更新域名
302 Found 临时重定向
请求的资源暂时可以被新的URL访问。与
301不同，302不会影响搜索引擎的索引，因为资源只是临时移动。使用场景：做活动，未登录的用户中心重定向到登录页面，404页面重新定到首页
303 See Other
和 302 有相似的功能，但 303 明确表示客户端要采用 GET 的方式获取资源
注意：当 301、302、303 响应状态码返回时，几乎所有的浏览器都会把 POST 改成GET，并删除请求报文内的主体，之后请求会再次自动发送。301、302 标准是禁止将 POST 方法变成 GET方法的，但实际大家都会这么做
304 Not Modified 浏览器缓存相关
告诉客户端有缓存，直接使用缓存中的数据
307 Temporary Redirect 临时重定向
和 302 相同含义，但307遵循浏览器标准，不会从 POST 变成 GET
4xx 客户端错误状态码
400 Bad Request
请求报文语法错误，浏览器会像200 OK 一样对待这个状态码
401 Unauthorized
发送的请求要有 HTTP 认证的认证信息，当浏览器初次接收到 401 响应，会弹出认证用的对话窗口。
401.1 - 登录失败。
401.2 - 服务器配置导致登录失败。
401.3 - 由于 ACL 对资源的限制而未获得授权。
401.4 - 筛选器授权失败。
401.5 - ISAPI/CGI 应用程序授权失败。
401.7 - 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。
403 Forbidden
请求被服务器拒绝了
403.1 - 执行访问被禁止。
403.2 - 读访问被禁止。
403.3 - 写访问被禁止。
403.4 - 要求 SSL。
403.5 - 要求 SSL 128。
403.6 - IP 地址被拒绝。
403.7 - 要求客户端证书。
403.8 - 站点访问被拒绝。
403.9 - 用户数过多。
403.10 - 配置无效。
403.11 - 密码更改。
403.12 - 拒绝访问映射表。
403.13 - 客户端证书被吊销。
403.14 - 拒绝目录列表。
403.15 - 超出客户端访问许可。
403.16 - 客户端证书不受信任或无效。
403.17 - 客户端证书已过期或尚未生效
403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。
403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。
403.20 - Passport 登录失败。这个错误代码为 IIS 6.0 所专用。
404 Not Found 服务器无法找到请求的资源
404.0 -（无） – 没有找到文件或目录。
404.1 - 无法在所请求的端口上访问 Web 站点。
404.2 - Web 服务扩展锁定策略阻止本请求。
404.3 - MIME 映射策略阻止本请求。
405 Method Not Allowed 服务器禁止使用此方法
客户端可以通过 OPTIONS 方法查看允许的访问方法
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
5xx 服务器错误状态码
500 Internal Server Error 服务器端发生错误，可能是 bug 或某些临时故障
502 Bad Gateway 网关或代理服务器出错与上有服务器通信出错
502.1 - CGI （通用网关接口）应用程序超时。
502.2 - CGI （通用网关接口）应用程序出错。
503 Service Unavailable 服务器处于超负荷或停机维护状态
504 Gateway Timeout 网关和代理服务器等待上有服务器超时
响应报头（header）
header格式：键值对，键和值之间用冒号+空格分割
常见报头与请求报头基本格式一致
server-服务器名称
Connection-浏览器与服务器之间连接的类型
Cache-Control-控制HTTP缓存
Set-Cookie-用于设置客户端的Cookie。
Content-Type-表示 body 的数据格式，介绍三种响应中的数据格式：
text/html-表示数据格式是 HTML
text/css-表示数据格式是 CSS
application/javascript-表示数据各式是 JavaScript
application/json-表示数据格式是 JSON
构造HTTP请求的方式
通过form表单构造HTTP请求
是 HTML 中的一个表单标签，可以用于给服务器发送 GET 或者 POST 请求。
form 的重要参数
action：构造或指向 HTTP 请求的 URL
method：构造 HTTP 请求的方法（form 只支持 GET 或 POST 方法)
input 的重要参数在 form 标签中的含义
type：表示输入框的类型（text 表示文本、password 表示密码、submit 表示提交按钮）
name：表示构造出的 HTTP 请求的 查询字符串（query string） 的 key
value：表示 input 标签的值（对于 type 为 submit 类型来说，value 就对应了按钮上显示的文本）
input 标签的内容：表示 query string 的 value
通过 ajax 构造 HTTP 请求
通过在后台与服务器进行少量数据交换，ajax 可以使网页实现异步更新。这意味着可以在不重新加载整个网页的情况下，对网页的某部分进行更新。
实现ajax的方法： jQuery、Axios、Fetch、XMLHttpRequest 和 async/await
注意
使用 ajax 不仅可以实现 GET 和 POST 方法的请求，也可以实现其它方法的请求
使用 ajax 不能跨域，即访问的域名和构造的域名需要相同（可以跨域的前提是该服务器允许可以跨域）
HTTP版本
HTTP1.0 HTTP1.1 HTTP2 三者区别
HTTP/1.0： 是HTTP协议的早期版本，主要特点是每次请求都需要建立一个新的TCP连接，请求完成后立即关闭连接。这种“无连接”的特性虽然简单，但效率较低，因为每次请求都需要重新建立连接，增加了延迟。 支持基本的缓存控制，主要依赖于响应头中的 Expires 字段。数据传输格式为文本，不支持头部压缩和服务器推送。
HTTP/1.1 ：引入了持久连接（默认情况下连接不会立即关闭），通过 Connection: keep-alive 可以保持连接，直到显式关闭。此外， 引入了先进的缓存控制机制，通过 Cache-Control 响应头来更灵活地控制缓存策略，还支持部分请求（断点续传）和管线化，允许在第一个请求未响应前发送后续请求，提高了并发请求的能力。
HTTP/2：HTTP/2 在TCP连接上实现了多路复用，允许在同一个连接上并发处理多个请求和响应，显著减少了延迟。数据传输格式从文本改为二进制，提高了传输效率。HTTP/2 支持头部压缩（HPACK算法），减少了头部信息的传输量。此外，HTTP/2 引入了服务器推送功能，服务器可以在客户端请求之前主动推送相关资源（如CSS、JS文件），减少了客户端的等待时间。HTTP/2 继承了HTTP/1.1 的持久连接和先进的缓存控制机制，
| 特性 | HTTP/1.0 | HTTP/1.1 | HTTP/2 |
|---|---|---|---|
| TCP连接 | 默认无连接（需要手动配置 Connection: keep-alive 实现close 关闭） |
默认持久连接（通过 Connection: close 关闭 |
持久连接 + 多路复用 |
| 数据传输格式 | 文本 | 文本 | 二进制 |
| 并发请求 | 不支持 | 部分支持（管线化：第一个请求未响应前可发送后去请求） | 支持多路复用（同一个TCP并发处理多个请求和响应） |
| 缓存控制 | 基本支持（缓存控制主要依赖于响应头中的 Expires 字段） |
先进的缓存控制（通过 Cache-Control 响应头来控制缓存策略） |
先进的缓存控制（通过 Cache-Control 响应头来控制缓存策略） |
| 头部压缩 | 不支持 | 不支持 | 支持（HPACK算法压缩：如去重） |
| 服务器推送 | 不支持 | 不支持 | 支持（服务器客户端请求前主动推送资源，如请求html，推送相关css，js） |
| 资源请求 | 返回整个对象 | 支持断点续传，且允许只请求资源中某一部分（range 头域） |
断点续传：
在传输中断后从中断的位置继续传输，而不必从头开始
断点续传工作原理：
文件分块：将文件划分为多个小块，每块都有一个唯一的标识符和位置。
记录传输状态：在传输过程中，客户端和服务器会记录已经成功传输的文件部分，以及剩余需要传输的部分。
继续传输：当传输中断时，客户端可以向服务器请求从上次中断的地方继续传输，服务器根据客户端的请求和记录的数据从指定位置开始继续传输数据。
使用场景：大文件上传
HTTP和HTTPS的区别
HTTP + SSL/TLS 加密：HTTPS 是在 HTTP 的基础上加入了 SSL（Secure Sockets Layer）或 TLS（Transport Layer Security）加密协议，确保通信数据的机密性、完整性和真实性。
安全性：
数据加密：传输的数据被加密，第三方无法窃取通信内容。
数据完整性：保证数据在传输过程中不会被篡改。
身份验证：通过证书确认服务器的身份，防止中间人攻击。
端口：
HTTP 使用 80 端口
HTTPS 使用 443 端口
性能：HTTPS 需要额外的 SSL/TLS 握手过程，会增加一些开销，但随着硬件的进步和 HTTP/2 的引入，这种开销已经大大降低。
HTTP3.0
定义： 基于UDP协议实现了类似于TCP的多路复用数据流、传输可靠性等功能，这套功能被称为QUIC协议。
QUIC 协议：QUIC集成了TLS 1.3加密功能，减少了握手所需的往返时间（RTT），并支持多路复用，允许在同一物理连接上并发传输多个独立的逻辑数据流，从而解决了TCP的队头阻塞问题。此外，QUIC基于UDP的特性使其能够实现快速握手，仅需0到1个RTT即可建立连接，显著提升了连接建立速度和传输效率。
HTTPS协议
什么是HTTPS协议
定义：超文本传输安全协议（HTTPS），是 HTTP 的加密版。通过 SSL/TLS 协议对数据进行加密，确保客户端和服务器之间传输数据时安全的，防止被窃听篡改或冒充。
优点：
验证服务器身份
数据安全
增加了中间人攻击的成本
缺点：
加密和解密消耗服务器资源
SSL 证书是收费的
TLS 握手时，增加页面加载时长
SSL 证书需要绑定 IP，不能使用同一个 IP 绑定多个域名
HTTPS工作原理
访问网站的过程：
浏览器发送 HTTPS 请求
服务器返回证书，浏览器验证有效性
在TCP连接的基础上，通过 TLS 握手建立安全的连接
建立连接后使用绘画密钥进行加密通信
HTTPS 如何确保数据传输的安全性
HTTPS 通过使用 TLS/SSL 协议对数据进行加密，防止被窃听和篡改
TLS 使用对称加密和非对称加密相结合的方式保证数据完整，同时通过数字证书验证服务器的身份来防止中间人攻击
流程：
数字证书验证：验证服务器身份，确保服务器的合法性
TLS 握手：然后使用非对称加密（使用证书中的服务器公钥发送预主密钥，服务器使用私钥解密）生成主密钥，最终生成会话密钥
最后使用对称加密进行数据交换
TLS/SSL工作原理
TLS 是 SSL 改进后的版本，有更强大安全性、更好的加密算法支持
定义： 传输层安全协议，是在 TCP 和 HTTP 之间的一层安全协议
TLS握手过程（协商安全参数、验证身份、建立安全密钥，确保数据传输的安全性）：
客户端：发送支持的加密算法列表和随机数
服务器：选择加密算法，返回服务器的证书和另外随机数
客户端：验证证书真实性，生成预主密钥，并用服务器的公钥加密给服务器
服务器：使用私钥解密预主密钥，生成主密钥
客户端和服务器根据主密钥生成会话密钥，用于后续数据加密
依赖三类基本算法：散列函数 hash、、非对称加密，对称加密
基于散列函数验证信息完整性
非对称加密实现身份认证和密钥协商
对称加密采用协商的密钥进行数据加密
对称加密和非对称加密：
对称加密：使用相同密钥加密和解密，速度快，但分发不安全；用于加密真实传输数据
非对称加密：使用公钥和私钥加密和解密，速度慢，但安全；用于安全交换密钥
公钥和私钥：公钥是公开的，私钥是保密的。公钥和私钥加密的数据只能使用对应的私钥和公钥解密。
什么是数字证书
数字证书是 CA 签发的电子邮件，用于验证服务器的身份
CA 是受信任的第三方机构，确保客户端连接到的服务器是合法的
DNS
什么是DNS
DNS 是域名系统，可以将域转换为计算机可以理解的 IP 地址
DNS工作步骤
当客户端（例如浏览器）需要访问某个域名时
DNS 递归查询：它会向本地 DNS 解析器发送查询请求，请求将域名解析为对应的 IP 地址。
本地 DNS 解析器查询根服务器：如果本地 DNS 解析器的缓存中没有该域名的记录，它会向根 DNS 服务器发送查询请求。
根服务器回应：根 DNS 服务器收到查询请求后，会返回负责该域名的（TLD 服务器）的地址。
查询顶级域名服务器： 本地 DNS 解析器根据根服务器返回的地址，向相应的 TLD 服务器发送查询请求，
TLD 服务器回应：TLD 服务器收到查询请求后，会返回该域名的权威 DNS 服务器的地址。
查询权威 DNS 服务器：本地 DNS 服务器向权威 DNS 服务器请求最终 IP地址
权威 DNS 服务器回应：权威 DNS 服务器收到查询请求后，会返回该域名对应的 IP 地址。本地 DNS 解析器将这个 IP 地址缓存起来，以便将来再次查询时可以直接从缓存中获取
什么是递归查询和迭代查询
DNS中两种不同的查询方式（两个都用了）
递归查询： 客户端向本地 DNS 解析器发送一次请求，解析器负责完成整个查询过程（从根服务器到权威服务器），最终返回目标域名的 IP 地址。
迭代查询：本地 DNS 解析器在每一步中只返回下一步应该查询的服务器地址，本地DNS解析器需要多次查询不同的 DNS 服务器，直到找到最终结果。
TCP
什么是TCP
TCP 是传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议
TCP的特点
面向连接：发送数据之前必须在两端建立连接，一对一才能连接
可靠的：无论网络的链路出现什么变化，TCP都可以保证一个报文一定能够到达接收端
字节流：无消息边界，可以传输非常大的数据量；消息为有序的，前一个消息未被收到时，即使后面的字节以及被收到，也不能被应用层处理，同时对重复的报文进行自动丢弃
仅支持单向传播：每条 TCP 传输连接只能有两个端点，只能进行点对点的数据传输
提供拥塞控制：当网络出现拥挤，TCP 能够减小向网络注入数据的速率和数量，缓解阻塞
全双工通信：客户端和服务器什么时候都能通信，不需要客户端发送新的请求
TCP和UDP的区别
TCP类似打电话，UDP类似发短信
1.连接
TCP 是面向连接的传输层协议，传输数据前先要建立连接
UDP 是不需要连接，即刻传输数据
2.服务对象
TCP 是一对一的两点服务，即一条连接只有两个端点
UDP 支持一对一、一对多、多对多的交互通信
3.可靠性
TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按需到达
UDP 是尽最大努力交付，不保证可靠交付数据。
4.拥塞控制、流量控制
TCP 有拥塞控制和流量控制机制，保证数据传输的安全性
UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率
5.首部开销
TCP 首部长度较长，会有一定的开销，首部在没有使用「选项」字段时是 28 个字节，如果使用了「选项」字段则会变长
UDP 首部只有8个字节，并且是固定不变的，开销较小
TCP 和 UDP 应用场景
效率要求相对低，但准确性要求高的场景：
FTP 文件传输
HTTP / HTTPS基于TCP
面向无连接，随时发送数据，简单又高效：
包总量较少的通信，如DNS、SNMP等
视频、音频等多媒体通信
广播通信
TCP的三次握手和四次挥手
三次握手
三次握手是TCP建立连接的过程，为了同步双方的序列号、确认通信能力
关键规则
SYN/FIN占一个序列号
ACK不占用自己的序列号，只确认对方数据
数据计算：
发送n字节数据后：seq += n
收到的ack表示：对方已正确收到此编号之前的所有数据
初始随机：
初始seq是随机数（现代系统通常不是简单的100/300）
之后严格按字节数递增
刚开始客户端处于Closed状态，服务端处于Listen状态
客户端发送包和一个初始序列号（SYN+seq(客户端标识的数据流字节起始编号))
客户端：SYN_SENT状态
服务器返回一个包（确认标志、服务器初始序列号），表示同意建立连接（SYN+ACK+seq(服务端标识的数据流起始编号)+ack(客户端传来的seq+1,确认对方收到信息)）
服务器： SYN_RCVD状态。
客户端发送包，双方建立连接(ACK+seq(同步了服务端传来的ack)+ack(同步了服务端传来的seq))
客户端/服务端：ESTABLTSHED状态
四次挥手
刚开始双方都处于ESTABLTSHED状态，假如是客户端先发起关闭请求。四次挥手的过程如下：
客户端发送终止标志（FIN+seq(客户端标识的数据流字节结束编号)）
客户端：FIN_WAIT1状态
服务器发送确认标志并进入等待关闭状态（ACK,ack(客户端传来的seq+1)）
服务端：CLOSED_WAIT状态
服务器也确认断开连接，则服务器发送（FIN+seq(服务端标识的数据流结束编号)），并进入确认关闭状态
服务端：LAST_ASK状态
客户端发送 (ACK+ack(同步了服务端传来的seq))，确认关闭
客户端：先处于TIME_WAIT确认服务器收到自己的ASK后进入CLOSED状态
服务端：收到ASK报文后处于CLOSED状态
为什么是三次握手？不是两次或四次？
三次握手可以同步双方的初始序列号，确认通信（所以两次不行）
三次握手可以阻止重复连接的初始化，减少资源的浪费（所以四次不行）
三次握手过程中可以携带数据吗？
第一、二次不可以，未确保通信状态，容易让服务器受到攻击
第三次可以，此时客户端处于ESTABLISHED状态，对于客户端来说已经建立通信
SYN攻击是什么？如何防范？
Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。
服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。
当服务器存在大量半连接状态，尤其源IP地址是堆积的，可以判断未一次SYN攻击，常见防御方式：
缩短超时（SYN Timeout）时间
增加最大半连接数
过滤网关防护
SYN cookies技术
挥手为什么需要四次？
关闭连接时，当服务端收到FIN报文时，很可能不会立即关闭SOCKET，所以回复客户端ACK报文；客户端收到ACK了解服务端已收到FIN；等服务端的所有报文发送完，再发送FIN报文
因为服务端的FIN和ACK不能同时发送，所以需要四次挥手
TCP如何实现可靠性
序列号与确认应答
seq和ack确保通信
流量控制
超时重传:TCP 在发送一个数据之后，没有在规定时间内收到发送数据的 ACK 确定报文，就会重新传送（一定时间内没有完成则放弃并重新发送）
快速重传：收到3个重复ACK立即重传，不用等到超时重发的计时器到期
重传场景：
数据包丢失
确认应答ACK丢失
滑动窗口
窗口大小：接收方告知可接收的数据量
工作流程：
接收方通告窗口=1000
发送方最多发送1000字节未确认数据
收到确认后窗口向前"滑动"TCP的阻塞控制机制（四种机制）
慢启动：在开始的时候不发送大量数据，先测试网络阻塞程度，由小到大增加阻塞窗口的大小
拥塞避免： 将拥塞窗口控制为按线性增长，使网络不容易阻塞
快速重传：接收到收到一个失序报文段就会发送一个重复确认，当连续发送三个重复确认就立即重传，不用等到计时器到期
快速恢复：连续收到三个重复确认时，把慢启动门限减半，重传后直接进入拥塞避免阶段
又优化了一下，向hy大人致谢，臣无贺大人无以至今日