计算机网络模型
OSI七层
标准化不同计算机系统或网络中的通信。物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
记忆口诀：“All People Seem To Need Data Processing”
TCP/IP模型
链路层、互联网层、传输层、应用层
记忆口诀：“应用传输网络链物”
应用层协议
HTTP协议
- 概念：HTTP协议（HyperText Transfer Protocol, 超文本传输协议）是一种应用层通信协议，指定客户端（如浏览器）与服务器之间进行数据传输（通信）规则，包括请求和响应，定义了请求方法、状态码。允许将HTML文档从Web服务器传送到客户端的浏览器。HTTP协议基于TCP/IP传输控制/互联网协议（跨越多层的协议族）。
代理服务器：如科学上网
HTTP请求流程
- DNS解析：将域名转换为IP地址
- 建立TCP连接-三次握手
HTTPS：在TCP连接后，需进行TLS握手（交换证书、协商密钥）。
3. 发起HTTP请求
通过已建立的TCP连接发送明文（HTTP）或加密（HTTPS）的请求报文，向服务器请求资源。
4. 服务端接收并处理请求，解析并根据路由查找资源，生成并返回响应数据（HTML、JSON）
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
<!DOCTYPE html>
<html>...</html>
- 客户端接收并处理响应
- 断开TCP连接-四次挥手
HTTP报文
是HTTP协议在客户端和服务端之间传送的数据块
| http请求报文结构 | request message | response message | http响应报文结构 |
|---|---|---|---|
| request line | Method /resource HTTP (URL)/version-number | Http/version-number status_code message | 状态行 response line |
| request header | Header_number: value | Header_number: value | response header |
| request body | POST请求时携带的数据如表单；GET方法，body为空 | Optional Response_body | response body |
Start Line
HTTP常见的请求方法
| Method | 描述 |
|---|---|
| GET查 | 从服务器获取指定信息 |
| POST改 | 向服务器发送待处理的数据 |
| PUT增 | 向服务端发送数据并替换服务器上指定的数据 |
| DELETE删 | 从服务端删除指定的数据 |
get和post的区别
GET和POST是两种最基本的HTTP请求方法，用于客户端与服务器之间的通信。
| 区别 | GET | POST |
|---|---|---|
| 用途 | 请求服务器发送资源或数据，不应有副作用（即不会改变资源的状态）。 | 向服务器提交数据，如表单数据，可能会改变资源的状态。 |
| 数据传输方式 | 数据附加在URL之后，通过URL传输，可见于地址栏。 | 数据在HTTP请求的body部分传输，不会显示在地址栏。 |
| 数据大小限制 | 将数据附加到URL中，因此数据大小有限制 | 将数据放在HTTP请求体中，因此数据大小不受限制。 |
| 安全性 | 数据暴露在URL中，容易被他人捕获。 | 数据不会暴露在URL中，但不是绝对安全，因为数据仍可能被第三方截获。 |
| 缓存机制 | URL中的数据可以被缓存，并且会保存在浏览器历史记录中。 | 不会被缓存，也不会保存在浏览器历史记录中。 |
| 幂等性 | 可以多次执行同一个GET请求，资源的状态不会改变 | 通常不是幂等的，每次执行可能会产生不同的结果。 |
URL统一资源定位符
基本格式protocol://host[:port#]/path[;url-params][?query-string][#anchor]
实例https://www.bilibili.com/bangumi/play/ss38591?theme=movie
| 元素 | 含义 | 实例 |
|---|---|---|
| protocol | 协议，如http、https、ftp | https |
| host | http服务器的IP地址或域名 | www.bilibili.com |
| port# | http服务器默认端口80可省略 | \ |
| path | 访问资源路径 | /bangumi/play/ss38591 |
| url-params | 参数 | \ |
| query-string | 发送给http服务器的数据 | theme=movie |
| anchor | 锚/fragment，定位网页片段之一 | \ |
默认端口
https（加密网页浏览/邮件传输）的默认端口是多少？443
http（网页浏览）的默认端口是多少？通常是80
状态码
表明HTTP服务器是否产生了预期的响应。
1xx 信息性
请求已被成功接受，继续处理，提供有关请求的额外信息，不一定表示请求的成功或错误。
- 100 Continue - 服务器已经理解客户端的请求，客户端可以继续发送请求的其余部分。
- 101 Switching Protocols - 服务器同意切换协议，通常用于从HTTP切换到HTTPS。
2xx 成功
请求已被成功接受，服务器返回了请求的资源。
- 200 OK -请求已成功，主体包含了所请求的数据。
3xx 重定向
要完成请求客户端必须进行更进一步的处理
- 301 Moved Permanently -请求的URL已被移除，资源永久移动位置，响应报文中的Location头部包含现在资源的URL；
- 304 Not Modified - 客户端有缓冲的文档并发出了一个条件性的请求时，服务端告知客户端，原来缓冲的数据还可以继续使用
4xx 客户端错误
请求有语法错误或请求无法实现
- 400 Bad Request - 客户端请求无效，如语法错误，服务器无法理解；
- 401 Unauthorized - 请求要求用户提供有效身份认证凭证；
- 403 Forbidden - 客户端没有访问资源的权利。
- 404 Not Found - 服务端无法找到客户端所请求的URL
- 405 Method Not Allowed - 请求中指定的方法不允许对资源进行操作。
- 429 Too many request - 服务端已理解客户端请求，但正在处理太多请求，暂无法处理该请求
Q： 报错429响应码可能是什么原因导致的？
- 客户端发送过多请求：客户端连续发送大量请求到目标服务器，服务器拒绝进一步处理请求
- 服务器配置：配置不正确导致服务器无法处理大量请求
- 服务器过载：服务器资源，CPU、内存、磁盘空间、网络带宽等不足，限制客户端请求数量
- 分布式拒绝服务攻击(DDoS攻击)：攻击者发送大量请求到目标服务，采取响应防御措施
Q：CORS跨源资源共享安全机制
- 控制跨域请求的安全性，允许一个网域下网页访问另一个网域下的资源，而不违反同源策略（限制域名/协议/端口源的文档或脚本与另一个源的资源交互的安全协议）。
- 工作原理：
- 预检请求Preflight Request：询问服务器是否允许该域跨源请求
- 响应权限：服务器检查请求类型、头部信息等决定是否允许跨源请求，允许则响应
- 实际请求：根据响应信息发送实际请求，若响应中无必要权限则不发送实际请求
- CORS通过头部信息实现权限控制，指定源、支持HTTP方法、客户端可发送的自定义头部信息、是否可发送Cookie…
5xx 服务端错误
服务器在处理请求时出现了错误，服务器可能无法完成请求。
- 500 Internal Server Error - 服务端内部错误，无法完成请求
- 501 Not Implemented - 服务器不支持请求的功能。
- 502 Bad Gateway - 服务器作为网关或代理，从上游服务器收到了错误。
- 503 Service Unavailable - 服务器当前不可用，通常由于过载或维护。
- 504 Gateway Timeout - 服务器作为网关或代理，未能在规定时间内从上游服务器获取响应。
Q：报错501响应码可能是什么原因导致的？
按链路考虑：客户端-proxy-服务器
- 客户端请求格式错误：服务器无法理解或处理
- proxy错误：代理服务器配置错误、过载、故障、目标不可达、不支持请求
- 服务器未实现功能：未实现请求中指定的功能或协议，如请求PUT，但只支持GET/POST
- 服务器配置错误：如服务器软件未正确设置以支持某些请求头或cookie
- 服务器应用程序错误：应用程序逻辑错误
消息头 & 消息体
请求和响应都包含消息头和消息体两部分。
消息头是系列key-value对，提供关于消息的其他信息，如Host域名端口、User-Agent发出请求用户代理软件信息、Accept指定客户端能接受的内容类型、Accept-Language指定客户端接受的语言、Content-Type请求体媒体类型(application/json text/html)、Content-Length请求或响应体长度、Connection控制不同请求响应间网络连接选项、Cookie服务器发送的用于区分用户身份的cookie信息、Authorization认证信息令牌等
消息体：GET、HEAD请求方方法中消息体通常是空的；POST(提交如表单数据)、PUT(要替换的资源)、DELETE(空或要删除的资源)等请求中body包含客户端发送到服务器的信息
在处理消息头和消息体时，需要考虑到安全性问题，如保护敏感信息、防止跨站请求伪造（CSRF）等。此外，在传输消息时，可能需要对消息进行加密（如使用TLS/SSL）以保证通信的机密性。
常见请求头参数
- Host：目标域名（URL网页中资源的完整路径）。如
Host: api.example.com - User-Agent：客户端标识（浏览器/设备信息）
- Accept：声明客户端支持的响应格式。如
Accept: application/json - Content-Type：请求体的数据类型（POST/PUT必需）。如
Content-Type: application/json - Authorization: 身份认证凭证（如Token）。如
Authorization: Bearer xxxx - Cookie: 发送服务器设置的Cookie
HTTP请求示例
创建数据库连接失败|Mysql Error 1130: 182.168.1.115’ is not allowed to connect to this MySQL server
原因是在初始化数据库操作类时，参数服务器主机本地应是如图所示的localhost，而不是自己查询本地ip地址。
不安全的请求警告：正在向主机“ip.taobao.com”发出未经验证的HTTPS请求。强烈建议添加证书验证。
InsecureRequestWarning: Unverified HTTPS request is being made to host ‘ip.taobao.com’. Adding certificate verification is strongly advised.See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
HTTP协议中控制缓存的方法及实际应用场景
1 什么是缓存控制？
通过一系列HTTP头部字段，告诉浏览器哪些资源可以缓存、如何缓存、缓存多久。通过不同缓存机制，决定何时从服务器调取资源，何时从冰箱调取资源。核心目的是让客户端（浏览器）高效地获取资源，同时减少服务器的负载压力。
2 缓存控制中服务器和客户端的作用？
缓存控制主要由服务器设置响应头Response Headers。服务器决定资源的缓存策略，浏览器/客户端遵守这些规则：1读取响应头的缓存指令，如Cache-Control，并执行对应缓存逻辑；2在后续请求中携带缓存标识，如If-None-Match，询问服务器资源是否变化。
3 两种缓存机制？
（1） 强制缓存：直接使用本地缓存，不询问服务器，使用长期不变的资源
（2） 协商缓存：先问服务器内容变了吗？没变就用缓存，适用于可能变化的资源
4 完整HTTP请求/响应示例
（1）强制缓存生效（直接使用缓存）
HTTP/1.1 200 OK
Cache-Control: public, max-age=86400 # 缓存1天
Expires: Wed, 22 Oct 2025 07:28:00 GMT
Content-Type: image/png
5 HTTP缓存控制参数及其取值示例
（1）强制缓存，直接使用本地缓存，不请求服务器
HTTP头部 示例值 说明
Cache-Control max-age=3600 缓存1小时
Cache-Control public, max-age=604800 允许CDN缓存，缓存7天
Cache-Control no-cache 缓存但每次需验证
Cache-Control no-store 禁止缓存
Cache-Control private, max-age=86400 仅浏览器缓存1天
Expires Expires: Wed, 21 Oct 2025 07:28:00 GMT 指定过期时间（HTTP/1.0）
（2）协商缓存，先询问服务器是否变化
HTTP头部 示例值 说明
Last-Modified Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT 资源最后修改时间
If-Modified-Since If-Modified-Since: Wed, 21 Oct 2025 07:28:00 GMT 客户端询问是否修改
ETag ETag: “33a64df5” 资源唯一标识（哈希值）
If-None-Match If-None-Match: “33a64df5” 客户端询问ETag是否匹配
（3）其他缓存控制
IMIX协议
传输层协议
TCP & UDP协议
TCP（传输控制协议）和UDP（用户数据报协议）是传输层协议
| 区别 | TCP | UDP |
|---|---|---|
| 连接性 | 三次握手，面向连接 | 无连接，直接发送数据包 |
| 可靠性 | 可靠，按序到达，没有损失和重复 不 | 保证顺序、完整、可靠性 |
| 效率 | 相对慢 | 相对快 |
| 流控 | 流量控制和拥塞控制 | 无 |
| 场景 | 可靠数据，网络浏览/电子邮件/文件传输 | 实时应用，流媒体 |
tcp中什么时候用到reset
TCP异常终止（reset报文）
TCP的异常终止是相对于正常释放TCP连接的过程而言的，我们都知道，TCP连接的建立是通过三次握手完成的，而TCP正常释放连接是通过四次挥手来完成，但是有些情况导致TCP无法正常释放连接，TCP连接将会一直存在，占用系统的部分资源
TCP异常终止的常见情形：
1，客户端尝试与服务器未对外提供服务的端口建立TCP连接，服务器将会直接向客户端发送reset报文。
2，客户端和服务器的某一方在交互的过程中发生异常（如程序崩溃等），该方系统将向对端发送TCP reset报文，告之对方释放相关的TCP连接
3，接收端收到TCP报文，但是发现该TCP的报文，并不在其已建立的TCP连接列表内，则其直接向对端发送reset报文
4，在交互的双方中的某一方长期未收到来自对方的确认报文，则其在超出一定的重传次数或时间后，会主动向对端发送reset报文释放该TCP连接
扫一扫
438
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
