泷羽sec-星河飞雪-web基础免责声明学习视频来自 B 站up主泷羽sec，如涉及侵权马上删除文章。笔记的只是方便

免责声明

学习视频来自 B 站up主泷羽sec，如涉及侵权马上删除文章。

笔记的只是方便各位师傅学习知识，以下代码、网站只涉及学习内容，其他的都与本人无关，切莫逾越法律红线，否则后果自负。

B站地址：space.bilibili.com/350329294

http协议简介

HTTP协议是Hypertext Transfer Protocol(也称为超文本传输协议)的缩写，是用于从万维网(www:world wide web) 服务器传输超文本到本地浏览器的传送协议

http协议工作于客户端-服务端(browser/sever)B/S架构上

浏览器作为http客户端通过url向http服务端即web服务器发送所有请求。web服务器根据接收到的请求后，向客户端发送响应消息

http协议版本

超文本传输协议经历了多个版本的发展，每个版本都在性能、功能和安全性等方面有所改进。

一、HTTP/0.9

诞生背景

互联网发展初期，对网页的需求较为简单，主要是纯文本内容的传输。

主要特性

仅支持GET请求，用于获取HTML文档。
没有请求头和响应头，通信极为简洁
只能传输超文本内容，不支持多媒体资源

使用场景

早期简单的网页浏览，通常是一些静态的文本页面

HTTP/1.0

诞生背景

随着互联网的发展，人们对网页的内容和交互性有了更高的要求。

主要特性

引入了请求头和响应头，包含了一些基本的元信息，如文档类型、日期等
网站元信息（Metadata）是关于数据的数据，具体到网站中，它提供了关于网站内容、结构、用途和用法等的关键信息。这些信息不直接显示在用户浏览器上，但对搜索引擎优化（SEO）、浏览器行为控制以及网站的其他方面至关重要。以下是网站元信息的详细解释：

一、定义与用途
1. 定义：网站元信息是嵌入在网页代码（如HTML）中，用于描述网页内容、作者、创建日期、关键字等额外信息的数据。
2. 用途：
  - SEO：帮助搜索引擎理解和索引网页内容，提高网站在搜索引擎结果页面（SERP）上的排名。
  - 浏览器行为控制：指导浏览器如何显示和处理网页，如字符编码、页面刷新、视口设置等。
  - 网页定级评价：提供网页的元数据，用于评估网页的质量和相关性。
二、主要类型
1. 标题元信息（Title Meta） ：设置网页的标题，显示在浏览器的标题栏和搜索结果中，是SEO的关键因素。
2. 描述元信息（Description Meta） ：提供网页的简短概述，常用于搜索引擎的结果摘要，有助于吸引用户点击。
3. 关键词元信息（Keywords Meta） ：列出与网页内容相关的关键词，尽管现代搜索引擎对此的依赖程度已降低，但仍对SEO有一定影响。
4. 其他类型：
  - 刷新元信息（Refresh Meta） ：设定网页在特定时间后自动重定向到另一个页面。
  - 编码元信息（Character Set Meta） ：定义网页的字符编码，确保不同语言的文字能正确显示。
  - 视口元信息（Viewport Meta） ：控制页面在小屏幕上的布局和缩放，以提供良好的用户体验。
  - 作者元信息（Author Meta） ：标记网页的创作者。
三、在HTML中的实现

在HTML文档中，元信息通常位于<head>标签内，通过<meta>标签来定义。例如：
```
1
<head>
2
    <meta name="title" content="网页标题">
3
    <meta name="description" content="网页描述">
4
    <meta name="keywords" content="关键词1, 关键词2, 关键词3">
5
    <meta http-equiv="refresh" content="30;url=http://example.com">
6
    <meta charset="UTF-8">
7
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
8
    <meta name="author" content="作者姓名">
9
</head>
```
四、重要性
1. 提高搜索引擎可见性：通过优化元信息，可以提高网站在搜索引擎中的排名，从而增加曝光率和流量。
2. 提升用户体验：合理的元信息设置（如视口元信息）可以确保网页在不同设备上都能良好地显示和交互。
3. 保护网站安全：通过元信息中的某些设置（如缓存控制），可以防止敏感信息的泄露和不当使用。
支持多种请求方式，如GET、POST、HEAD
每次请求都需要建立新的TCP连接，传输完成后立即断开，效率极低

适用场景

一些简单的网页浏览和交互场景，但对于包含大量资源的网页，加载速度较慢

三、HTTP/1.1

诞生背景

为了解决HTTP/1.0连接频繁建立和断开的问题，提高网页加载速度的性能。

主要特性

持久连接(KeepAlive) 允许在一个TCP连接上发送多个请求和响应，减少连接建立的开销
管道化(Pipelining) 客户端可以在一个连接上连续发送多个请求，但服务器的相应顺序必须于请求顺序一致
增加了更多的请求方法，如PUT、DELETE、OPTIONS等
引入缓存控制机制，通过头部字段控制缓存的使用

适用场景

目前广泛应用于大多数的网站和web应用程序，是较为成熟和稳定的版本

四、HTTP/2

诞生背景

随着web应用的日益复杂，用户对网页加载速度和性能的要求越来越高，HTTP/1.1在一些方面存在局限性

主要特性

二进制分帧，将HTTP消息分解为更小的帧进行传输，提高传输效率和灵活性
二进制分帧是一种数据处理技术，特别是在通信系统中，它扮演着至关重要的角色。以下是对二进制分帧的详细解释：

一、定义

二进制分帧是指将二进制数据分成一定长度的帧，以便于传输和处理。每个帧中包含一定数量的二进制位，这个长度通常由协议规定，并根据实际需要进行调整。

二、作用
1. 提高传输可靠性：通过将数据分成固定长度的帧，并在帧中添加附加信息（如起始标识符、帧长度、校验和等），可以帮助接收方准确地识别和处理传输的数据，从而提高数据传输的可靠性。
2. 优化传输性能：在HTTP/2等协议中，二进制分帧层能够确保所有传输的信息都被分割为更小的消息和帧，并采用二进制格式编码。这种编码方式能够减小传输的大小，降低开销，并优化传输性能。
三、帧的结构

在二进制分帧中，帧通常包含以下部分：
1. 头部：包含帧的长度、类型、标志和流标识符等信息。这些头部信息对于接收方正确地解析和重组帧至关重要。
2. 负载：承载特定类型的数据，如HTTP首部、消息负载等。负载的长度和内容根据帧的类型不同而有所变化。
四、应用实例

以HTTP/2协议为例，它引入了二进制分帧层来优化传输性能。在HTTP/2中，所有的通信都在一个TCP连接上进行，并被分割成更小的二进制帧。

这些帧按序列号发送和接收，并在接收端重新组装成完整的消息。

HTTP/2中的帧类型包括DATA帧、HEADERS帧、PRIORITY帧等，它们分别用于传输HTTP消息体、关于流的额外首部字段以及指定或重新指定引用资源的优先级等。

五、优势与特点
1. 高效性：二进制分帧能够减小传输的大小，降低开销，并提高传输效率。
2. 灵活性：帧的长度和类型可以根据实际需要进行调整，以适应不同的应用场景。
3. 可靠性：通过添加附加信息和采用二进制格式编码，二进制分帧能够提高数据传输的可靠性。
多路复用，可在一个链接上同时处理多个请求和响应，无需按顺序发送，提高并发处理能力
头部压缩，使用HPACK算法对头部进行压缩，减少传输的数据量
HPACK（HTTP2 Header Compression for HTTP）是一种用于压缩HTTP请求和响应头部的算法，在HTTP/2协议中被广泛使用。以下是关于HPACK算法的详细介绍：

一、作用与目的

HPACK算法的主要目的是减小HTTP头部数据的大小，从而提高网络传输效率。通过压缩头部字段，HPACK可以减少传输带宽的占用，并降低延迟，进而提升页面加载速度。

二、原理与实现
1. 静态表和动态表：
  - HPACK算法使用两个表来将头部字段与索引值关联，从而减少头部字段的大小。静态表包含了常见的HTTP头部字段及其索引值，而动态表则是根据实际传输中的头部字段动态生成的。
2. 霍夫曼编码：
  - 除了使用静态表和动态表外，HPACK还采用霍夫曼编码对头部字段的名称和值进行进一步压缩。霍夫曼编码是一种变长编码，根据字符出现的概率分配不同长度的二进制编码，使得出现频率高的字符使用较短的编码，出现频率低的字符使用较长的编码。这种编码方式可以进一步提高压缩效率。
3. 索引和字面表示：
  - 在HPACK中，头部字段可以表示为索引或字面。索引表示形式定义了一个头部字段，作为对静态表或动态表中条目的引用；字面表示形式则通过指定其名称和值来定义头部字段。编码器可以选择将字面值直接编码，也可以使用霍夫曼编码进行进一步压缩。
4. 动态表更新：
  - 编码器可以决定如何将某些头部字段作为新条目插入动态表中，以便在后续请求中重复使用这些条目。此外，编码器还可以通过发送更新指令来调整动态表的大小。解码器在接收到编码后的头部块后，根据索引地址空间中的索引值来查找静态表或动态表中的条目，或者根据字面值或霍夫曼编码来解析名称和值。
三、特点与优势
1. 高压缩效率：
  - 通过使用静态表和动态表以及霍夫曼编码，HPACK算法可以实现较高的压缩效率，从而节省带宽并提高传输效率。
2. 动态表更新：
  - 编码器可以灵活地控制动态表的使用和大小，以适应不同的场景和需求。这增加了算法的灵活性和可扩展性。
3. 安全性：
  - 相比于之前使用的DEFLATE等通用压缩算法，HPACK算法具有更高的安全性。它避免了使用后向字符串匹配和动态Huffman编码可能带来的安全风险，如CRIME攻击。
4. 保持顺序：
- HPACK算法保留了头部字段列表内头部字段的顺序，以便在压缩和解压缩后能够重建完整的头部列表。这有助于在不同的上下文中正确解释头部字段。
四、应用场景

HPACK算法在HTTP/2协议中被广泛应用，用于压缩HTTP请求和响应的头部字段。它适用于各种需要优化网络传输性能的场景，如Web服务器、代理服务器、客户端工具等。通过使用HPACK算法，这些场景可以显著提高数据传输效率，降低延迟，并提升用户体验。
服务器推送，服务器可以主动向客户端推送资源，提高页面加载速度

适用场景

对于性能要求较高的现代web应用，特别是需要快速加载大量资源的场景

HTTP/3

诞生背景

虽然HTTP/2在性能上有了很大提升，但它仍然基于TCP协议，而TCP在一些情况下可能会出现连接建立时间长、丢包重传效率低等问题

主要特性

基于QUIC协议，一种基于UDP的传输协议，具有更快的连接建立时间和更好的拥塞控制机制
QUIC（Quick UDP Internet Connections）是一种由谷歌公司开发的基于用户数据报协议（UDP）的传输层协议。以下是对QUIC协议的详细介绍：

一、概述

QUIC旨在提高网络连接的速度和可靠性，以取代当前互联网基础设施中广泛使用的传输控制协议（TCP）。它通过加密和多路复用技术来提供更高的安全性和更快的数据传输。此外，QUIC还支持在单个连接上并行发送多个数据流，从而降低延迟并提高吞吐量。

二、核心特性
1. 0-RTT连接建立：
  - QUIC协议使用了0-RTT（零往返时间）连接建立技术，可以在客户端发送第一个请求时就建立起安全连接，从而减少连接建立所需的时间。
  - 首次握手后，QUIC的客户端缓存了Server Hello，那么在下次建连时，可以直接使用缓存数据计算通信密钥，并加密发送应用数据。因此，客户端不需要经过握手就可以发送应用数据，实现了0-RTT连接。
2. 无队头阻塞的多路复用：
  - QUIC协议支持数据流级别的多路复用，这意味着在单个QUIC连接中可以同时传输多个数据流。
  - 每个数据流都有独立的流量控制和错误恢复机制，避免了TCP中“队头阻塞”问题。即使一个数据流中的数据包丢失，也不会影响其他数据流的传输。
3. 无歧义重传：
  - QUIC采用了单向递增的Packet Number来标识数据包，因此不会像TCP一样因为超时重传了同样序列的数据包而造成RTT（往返时间）和RTO（重传超时时间）的计算不准确。
  - QUIC对于RTT的计算更为准确，预估的超时时间能够有效防止更多的重传请求被错误地发送回客户端。同时，也给予了QUIC网络更为快速的反应时间，及时通知客户端重传数据包。
三、数据包格式与建立连接
1. 数据包格式：
  - QUIC数据包由header和data两部分组成。
  - header是明文的，包含Flags、Connection ID、QUIC Version、Packet Number等字段。
  - data是加密的，可以包含1个或多个frame，每个frame又分为type和payload，其中payload就是应用数据。
2. 建立连接：
  - QUIC的握手是基于TLS 1.3实现的，因此首次建立连接时也需要进行TLS握手。
  - 在TLS握手过程中，客户端和服务器会交换加密参数并建立一个共享的密钥。所有传输的数据都使用该密钥进行加密，从而确保端到端的数据保护和完整性验证。
四、优势与应用
1. 优势：
  - 更快的连接建立和数据传输：通过0-RTT连接建立技术，QUIC可以显著减少连接建立的时间。
  - 内置的安全加密机制：QUIC默认使用TLS 1.3加密，提供与HTTPS同等的安全性。
  - 多路复用与避免队头阻塞：QUIC支持在单个连接上并行传输多个数据流，每个流都有独立的流量控制和错误恢复机制。
  - 灵活的拥塞控制和丢包恢复机制：QUIC允许使用不同的拥塞控制算法，为不同的网络环境和应用场景提供了灵活性。
2. 应用：
  - QUIC协议适用于对实时性要求高的应用场景，如视频直播、在线游戏、实时通信等。
  - 它已经被Google Chrome和HTTP/3采用，用于提高网页加载速度和用户体验。
五、挑战与未来
1. 挑战：
  - 需要UDP支持：部分网络环境可能对UDP流量有严格限制。
  - 部署和调试过程中可能遇到兼容性问题：作为新协议，QUIC在部署和调试过程中可能会遇到一些兼容性问题。
  - 实现复杂度较高：需要开发者熟悉底层网络协议和加密技术。
2. 未来：
  - 随着互联网的发展和对高效、可靠网络传输的需求不断增加，QUIC协议有望在未来得到更广泛的应用和推广。
  - 同时，也需要不断对QUIC协议进行优化和改进，以应对不断变化的网络环境和应用场景。
0-RTT连接建立，在某些情况下可以在第一次连接是就开始发送数据，减少延迟。
0-RTT（Zero Round Trip Time）连接建立是QUIC（Quick UDP Internet Connections）协议中的一种重要特性，旨在显著减少连接建立的时间，提高通信效率。以下是对0-RTT连接建立的详细解释：

一、定义与原理

0-RTT连接建立允许客户端在重新连接到之前已经建立过连接的服务器时，不需要进行完整的握手过程，从而实现了在发送第一个数据包时就能立即发送加密的应用数据，而无需等待服务器的响应。这种机制类似于TLS会话复用，但它在QUIC协议中得到了进一步的优化和集成。

二、实现步骤
1. 首次握手与会话密钥交换：
  - 在客户端和服务器首次建立连接时，它们会进行完整的TLS 1.3握手过程，并交换加密参数和会话密钥。
  - 服务器会生成一个会话票据（Session Ticket），并将其发送给客户端。这个票据包含了用于恢复会话状态所需的加密参数和密钥信息。
2. 客户端缓存会话票据：
  - 客户端会缓存这个会话票据，以便在后续连接中复用。
3. 0-RTT连接建立：
  - 当客户端再次尝试连接到同一服务器时，它会在Client Hello消息中携带之前缓存的会话票据。
  - 客户端在发送Client Hello的同时，还可以发送加密的应用数据（即0-RTT数据）。这些数据包含了客户端的身份信息和会话密钥等，用于服务器在收到后恢复会话状态。
  - 服务器在接收到Client Hello后，会使用会话票据中的信息来验证客户端的身份并恢复会话状态。如果验证成功，服务器就可以立即开始处理客户端发送的0-RTT数据。
三、优势与应用场景
1. 显著减少延迟：
  - 由于客户端可以在发送第一个数据包时立即发送加密的应用数据，而无需等待服务器的响应，因此可以显著减少连接建立的延迟。
2. 提高通信效率：
  - 0-RTT连接建立使得客户端和服务器能够更快地开始数据传输，从而提高了通信效率。
3. 适用于频繁请求的场景：
  - 对于需要频繁请求同一服务器的应用（如Web浏览、API调用等），0-RTT连接建立可以显著提高性能。
四、注意事项与安全风险
1. 安全风险：
  - 由于0-RTT数据是在没有经过服务器完整认证的情况下发送的，因此可能会受到重放攻击等安全风险。为了减轻这种风险，客户端应该限制0-RTT数据的内容，例如只发送不会改变服务器状态的请求（如GET请求而非POST请求）。
2. 兼容性问题：
  - 0-RTT连接建立需要服务器支持，并且客户端和服务器之间需要事先建立过连接并交换过会话票据。因此，在某些旧的或不支持QUIC协议的服务器上可能无法使用0-RTT连接建立。
连接迁移，即使网络环境发生变化，连接也可以保持
前向纠错，在数据传输过程中可以检测和纠正一些错误，减少重传次数，提高传输效率

使用场景

对延迟敏感的应用，如在线游戏、实时视频通信等，以及在网络环境不稳定的情况下，能够提供更好的性能和可靠性

http协议请求方法

GET

用途

用于发送指定的资源。这是最常见的请求方法，当你在浏览器中输入网址并访问时，通常会发送GET请求

特点

GET请求可以被缓存，除非指定了特定的缓存控制头部
GET请求的参数通常附加在url中，这使得它们可以被轻松的分享和书签，但也可能会暴露敏感信息，并且有长度限制
GET请求是安全的，即它不会对服务器上的资源进行修改

范例

GET请求是HTTP协议中最常用的请求方法之一，用于从指定的资源请求数据。以下是一个简单的GET请求范例，包括HTTP请求行、请求头和请求体（对于GET请求，请求体通常是空的）：

HTTP GET请求范例

1
GET /index.html HTTP/1.1
2
Host: www.example.com
3
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
5
Accept-Encoding: gzip, deflate, br
6
Accept-Language: en-US,en;q=0.9
7
Connection: keep-alive
8
Upgrade-Insecure-Requests: 1
9
If-Modified-Since: Wed, 21 Oct 2021 07:28:00 GMT
10
If-None-Match: "5114a-5d0e19e600e40"
11

12
-- 这里没有请求体，因为GET请求通常不包含请求体 --

解释

GET /index.html HTTP/1.1：这是HTTP请求行，指定了请求方法（GET）、请求的资源路径（/index.html）和HTTP协议版本（HTTP/1.1）。
Host: www.example.com：请求头之一，指定了目标服务器的域名或IP地址。
User-Agent：指定了发出请求的客户端的类型、操作系统、浏览器等信息。
Accept：指定客户端能够处理的MIME类型，表示客户端希望接收的数据类型。
Accept-Encoding：指定客户端支持的压缩格式，如gzip、deflate等。
Accept-Language：指定客户端希望接收的语言类型。
Connection：指定连接类型，如keep-alive表示持久连接。
Upgrade-Insecure-Requests：指示客户端支持通过HTTPS进行安全连接。
If-Modified-Since：如果资源自指定日期以来未被修改，则请求服务器返回304状态码（未修改）。
If-None-Match：如果资源的ETag与指定值不匹配，则请求服务器返回资源内容；如果匹配，则返回304状态码。

响应范例

服务器收到GET请求后，会返回一个HTTP响应，包含状态行、响应头和响应体：

1
HTTP/1.1 200 OK
2
Date: Thu, 22 Oct 2021 08:30:00 GMT
3
Content-Type: text/html; charset=UTF-8
4
Content-Length: 12345
5
Last-Modified: Wed, 21 Oct 2021 07:28:00 GMT
6
ETag: "5114a-5d0e19e600e40"
7

8
<!DOCTYPE html>
9
<html lang="en">
10
<head>
11
    <meta charset="UTF-8">
12
    <title>Example Page</title>
13
</head>
14
<body>
15
    <h1>Hello, World!</h1>
16
    <!-- 页面内容 -->
17
</body>
18
</html>

在这个响应范例中，服务器返回了200 OK状态码，表示请求成功。响应头包含了日期、内容类型、内容长度、最后修改时间和ETag等信息。响应体则是请求的HTML页面内容。

POST

用途

用于向服务器提交数据，以创建或更新资源。例如，在提交表单、上传文件等场景中经常使用

特点

POST请求的数据通常放在请求体中，而不是url中，因此可以传输更大量的数据，并且相对更安全，不容易暴露敏感信息
POST请求一般不会被缓存

范例

HTTP POST请求范例

1
POST /submit-form HTTP/1.1
2
Host: www.example.com
3
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
4
Content-Type: application/x-www-form-urlencoded
5
Content-Length: 43
6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
7
Accept-Encoding: gzip, deflate, br
8
Accept-Language: en-US,en;q=0.9
9
Connection: keep-alive
10

11
username=exampleUser&password=examplePass123

解释

POST /submit-form HTTP/1.1：这是HTTP请求行，指定了请求方法（POST）、请求的资源路径（/submit-form）和HTTP协议版本（HTTP/1.1）。
Host: [www.example.com：请求头之一，指定了目标服务器的域名或IP地址。www.example.xn--com
User-Agent：指定了发出请求的客户端的类型、操作系统、浏览器等信息。
Content-Type：指定了请求体的媒体类型，这里是application/x-www-form-urlencoded，表示请求体中的数据是以URL编码的形式提交的。
Content-Length：指定了请求体的长度（字节数）。
Accept、Accept-Encoding、Accept-Language、Connection：这些请求头与GET请求中的含义相同。
请求体：在POST请求中，请求体包含了要提交给服务器的数据。在这个例子中，请求体是username=exampleUser&password=examplePass123，表示提交了一个表单，其中包含用户名和密码两个字段。

响应范例

服务器收到POST请求后，会返回一个HTTP响应，包含状态行、响应头和响应体。响应的具体内容取决于服务器的处理逻辑和请求的资源。以下是一个可能的响应范例：

1
HTTP/1.1 200 OK
2
Date: Thu, 22 Oct 2021 08:35:00 GMT
3
Content-Type: text/html; charset=UTF-8
4
Content-Length: 178
5

6
<html>
7
<head>
8
    <title>Form Submission</title>
9
</head>
10
<body>
11
    <h1>Form Submitted Successfully</h1>
12
    <p>Thank you for submitting the form. Your username is exampleUser.</p>
13
</body>
14
</html>

在这个响应范例中，服务器返回了200 OK状态码，表示请求成功。响应头包含了日期、内容类型和内容长度等信息。响应体则是一个HTML页面，显示了表单提交成功的信息。

PUT

用途

用于更新服务器上的资源，PUT请求通常会将整个资源进行替换

特点

PUT请求是幂等的，即多次发送相同的PUT请求应该产生相同的效果

范例

PUT请求是HTTP协议中用于向指定资源上传其最新内容的一种请求方法。它通常用于更新服务器上的资源。以下是一个简单的PUT请求范例，包括HTTP请求行、请求头和请求体：

HTTP PUT请求范例

1
PUT /resource/123 HTTP/1.1
2
Host: www.example.com
3
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
4
Content-Type: application/json
5
Content-Length: 74
6
Accept: application/json
7
Accept-Encoding: gzip, deflate, br
8
Accept-Language: en-US,en;q=0.9
9
Connection: keep-alive
10
Authorization: Bearer YOUR_ACCESS_TOKEN
11

12
{
13
    "name": "Updated Resource Name",
14
    "description": "This is an updated description."
15
}

解释

PUT /resource/123 HTTP/1.1：HTTP请求行，指定了请求方法（PUT）、请求的资源路径（/resource/123，假设这是资源的唯一标识符）和HTTP协议版本（HTTP/1.1）。
Host: 指定目标服务器的域名或IP地址。
User-Agent: 指定发出请求的客户端的类型、操作系统、浏览器等信息。
Content-Type: 指定请求体的媒体类型，这里是application/json，表示请求体中的数据是以JSON格式提交的。
Content-Length: 指定请求体的长度（字节数）。
Accept: 指定客户端能够处理的MIME类型，这里客户端希望接收JSON格式的数据。
Accept-Encoding, Accept-Language, Connection: 这些请求头的含义与GET和POST请求中的相同。
Authorization: 包含认证信息，这里使用Bearer Token作为示例。实际使用时，应根据服务器的认证机制提供正确的认证信息。
请求体: 在PUT请求中，请求体包含了要更新到服务器上的资源的新内容。在这个例子中，请求体是一个JSON对象，包含name和description两个字段，分别表示资源的名称和描述。

响应范例

服务器收到PUT请求后，会返回一个HTTP响应，包含状态行、响应头和（可选的）响应体。以下是一个可能的响应范例：

1
HTTP/1.1 200 OK
2
Date: Thu, 22 Oct 2021 09:00:00 GMT
3
Content-Type: application/json
4
Content-Length: 102
5

6
{
7
    "id": "123",
8
    "name": "Updated Resource Name",
9
    "description": "This is an updated description.",
10
    "updatedAt": "2021-10-22T09:00:00Z"
11
}

在这个响应范例中，服务器返回了200 OK状态码，表示请求成功。响应头包含了日期、内容类型和内容长度等信息。响应体则是一个JSON对象，包含了更新后的资源信息，包括资源的ID、名称、描述以及更新时间。

请注意，实际的PUT请求和响应可能包含更多的请求头和响应头，具体取决于客户端和服务器的配置以及请求的资源。此外，如果尝试更新一个不存在的资源，服务器可能会返回404 Not Found状态码；如果尝试更新资源时遇到权限问题，服务器可能会返回403 Forbidden或401 Unauthorized状态码。

DELETE

用途

用于删除服务器上的指定资源

特点

DELETE请求也是幂等的，多次删除同一个资源应该产生相同的结果，即资源被删除后再次删除不会产生错误

范例

DELETE请求是HTTP协议中用于请求服务器删除指定资源的一种请求方法。以下是一个简单的DELETE请求范例，包括HTTP请求行和请求头（通常DELETE请求不包含请求体，因为它不用于提交数据）：

HTTP DELETE请求范例

1
DELETE /resource/123 HTTP/1.1
2
Host: www.example.com
3
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
4
Accept: application/json
5
Accept-Encoding: gzip, deflate, br
6
Accept-Language: en-US,en;q=0.9
7
Connection: keep-alive
8
Authorization: Bearer YOUR_ACCESS_TOKEN

解释

DELETE /resource/123 HTTP/1.1：HTTP请求行，指定了请求方法（DELETE）、请求的资源路径（/resource/123，假设这是要删除的资源的唯一标识符）和HTTP协议版本（HTTP/1.1）。
Host：指定目标服务器的域名或IP地址。
User-Agent：指定发出请求的客户端的类型、操作系统、浏览器等信息。
Accept：指定客户端能够处理的MIME类型，这里客户端希望接收JSON格式的数据作为响应（尽管DELETE请求通常不返回资源内容，但可能返回状态信息或错误消息）。
Accept-Encoding, Accept-Language, Connection：这些请求头的含义与GET、POST和PUT请求中的相同。
Authorization：包含认证信息，这里使用Bearer Token作为示例。实际使用时，应根据服务器的认证机制提供正确的认证信息。

响应范例

服务器收到DELETE请求后，会返回一个HTTP响应，包含状态行和（可选的）响应头及响应体。以下是一个可能的响应范例：

HTTP/1.1 204 No Content
Date: Thu, 22 Oct 2021 09:30:00 GMT
Content-Length: 0

在这个响应范例中，服务器返回了204 No Content状态码，表示请求成功，但响应体不包含任何内容。这是DELETE请求常见的响应方式，因为删除操作通常不需要返回被删除的资源内容。响应头包含了日期和内容长度（在这里为0，因为没有响应体）。

然而，有些服务器可能会返回200 OK状态码和一个响应体，其中包含有关删除操作的信息（例如，被删除资源的ID）。这不是标准做法，但可能会在某些API中出现。重要的是要遵循API文档中的规范来确定预期的响应格式。

请注意，如果尝试删除一个不存在的资源，服务器可能会返回404 Not Found状态码。如果尝试删除资源时遇到权限问题，服务器可能会返回403 Forbidden或401 Unauthorized状态码。

HEAD

用途

与GET请求类似，但只返回头部信息，不返回资源的主题内容

特点

可以用于检查资源的存在性、获取资源的元信息(如最后修改时间、内容长度等)，而无需下载整个资源，从而节省带宽和时间

范例

HEAD请求是HTTP协议中用于获取资源的元数据（即头部信息），而不返回资源实际内容的一种请求方法。以下是一个HEAD请求的范例，包括HTTP请求行和请求头：

HTTP HEAD请求范例

HEAD /resource/123 HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Authorization: Bearer YOUR_ACCESS_TOKEN

解释

HEAD /resource/123 HTTP/1.1：HTTP请求行，指定了请求方法（HEAD）、请求的资源路径（/resource/123，假设这是你想要获取元数据的资源的唯一标识符）和HTTP协议版本（HTTP/1.1）。
Host：指定目标服务器的域名或IP地址。
User-Agent：指定发出请求的客户端的类型、操作系统、浏览器等信息。
Accept：指定客户端能够处理的MIME类型，这里使用*/*表示接受任何类型的内容（尽管HEAD请求不会返回内容本身，但此头部信息有助于服务器确定如何响应）。
Accept-Encoding, Accept-Language, Connection：这些请求头的含义与GET、POST和PUT请求中的相同。
Authorization：包含认证信息，这里使用Bearer Token作为示例。实际使用时，应根据服务器的认证机制提供正确的认证信息。

响应范例

服务器收到HEAD请求后，会返回一个HTTP响应，包含状态行和响应头，但不包含响应体（因为HEAD请求不要求返回内容）。以下是一个可能的响应范例：

HTTP/1.1 200 OK
Date: Thu, 22 Oct 2021 10:00:00 GMT
Content-Type: application/json
Content-Length: 1234
Last-Modified: Wed, 21 Oct 2021 15:00:00 GMT
ETag: "1234567890abcdef"
Connection: keep-alive

在这个响应范例中，服务器返回了200 OK状态码，表示请求成功。响应头包含了日期、内容类型、内容长度（尽管HEAD请求不会返回内容，但服务器仍然会提供这个信息以表明如果执行GET请求，将会返回多少字节的数据）、最后修改时间、ETag（实体标签，用于标识资源的特定版本）等元数据。这些元数据对于客户端来说是有用的，因为它们可以在不实际下载资源内容的情况下了解资源的状态和信息。

请注意，如果尝试获取一个不存在的资源的元数据，服务器可能会返回404 Not Found状态码。如果尝试获取资源时遇到权限问题，服务器可能会返回403 Forbidden或401 Unauthorized状态码。

OPTIONS

用途

用于获取服务器支持的HTTP请求方法和其他选项

特点

客户端可以通过OPTIONS请求了解服务器对特定资源的访问权限和支持的操作

范例

OPTIONS请求是HTTP/1.1协议中定义的一种请求方法，主要用于描述目标资源的通信选项。它通常被用于跨域资源共享（CORS）的预检请求中，以确定服务器是否允许跨域请求以及允许哪些HTTP方法和头部信息。以下是一个OPTIONS请求的范例及其解释：

HTTP OPTIONS请求范例

OPTIONS /some/resource HTTP/1.1
Host: api.example.com
Origin: https://client.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, Authorization
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Connection: keep-alive

解释

OPTIONS /some/resource HTTP/1.1：HTTP请求行，指定了请求方法（OPTIONS）、请求的资源路径（/some/resource）和HTTP协议版本（HTTP/1.1）。
Host：指定目标服务器的域名。
Origin：指定发起请求的源域名，用于CORS检查。
Access-Control-Request-Method：告知服务器，实际请求将使用的HTTP方法（例如POST）。这是CORS预检请求特有的头部信息。
Access-Control-Request-Headers：告知服务器，实际请求将携带的自定义请求头部字段（例如Content-Type和Authorization）。这也是CORS预检请求特有的头部信息。
User-Agent、Accept、Accept-Encoding、Accept-Language、Connection：这些请求头与常见的GET、POST请求中的头部信息相似，用于描述客户端的类型、偏好等。

响应范例

服务器收到OPTIONS请求后，会返回一个HTTP响应，包含状态行和响应头。以下是一个可能的响应范例：

HTTP/1.1 204 No Content
Date: Fri, 23 Oct 2024 10:00:00 GMT
Access-Control-Allow-Origin: https://client.example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With
Access-Control-Max-Age: 86400
Connection: keep-alive

在这个响应范例中，服务器返回了204 No Content状态码，表示请求成功但没有返回内容（这是OPTIONS请求的常见响应状态码）。响应头包含了以下信息：

Access-Control-Allow-Origin：指定允许跨域请求的源域名。
Access-Control-Allow-Methods：指定服务器允许的HTTP方法。
Access-Control-Allow-Headers：指定服务器允许的自定义请求头部字段。
Access-Control-Max-Age：指定预检请求的结果能够被缓存的最长时间（以秒为单位）。

这些响应头部信息告诉客户端，服务器允许来自https://client.example.com的跨域请求，并允许使用POST、GET、OPTIONS和DELETE方法，以及Content-Type、Authorization和X-Requested-With头部字段。同时，预检请求的结果可以被缓存86400秒（即一天）。

TRACE

用途

用于诊断和调试，客户端可以发送TRACE请求来查看请求在网络中经过的路径

特点

通常在开发和测试环境中使用，以了解请求的处理方式

范例

TRACE请求是HTTP/1.1协议中定义的一种请求方法，它主要用于沿路径发送请求到目标服务器，并接收目标服务器返回的原始请求报文。这种方法通常被用于测试和调试目的，以检查请求在传输过程中是否被修改或正确地转发到目标服务器。以下是一个TRACE请求的范例及其解释：

HTTP TRACE请求范例

TRACE /test/trace HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Content-Type: message/http
Content-Length: [length]

-- request body (if any, but typically empty for TRACE)

解释

TRACE /test/trace HTTP/1.1：HTTP请求行，指定了请求方法（TRACE）、请求的资源路径（/test/trace）和HTTP协议版本（HTTP/1.1）。
Host：指定目标服务器的域名。
User-Agent：指定发出请求的客户端的类型、操作系统、浏览器等信息。
Accept：指定客户端能够处理的MIME类型，这里使用*/*表示接受任何类型的内容。
Accept-Encoding, Accept-Language, Connection：这些请求头的含义与GET、POST等请求中的相同。
Content-Type：对于TRACE请求，通常设置为message/http，表示请求体包含HTTP消息。然而，在实际应用中，TRACE请求的请求体通常是空的，因为其主要目的是回显原始请求报文。
Content-Length：如果请求体不为空，则需要指定其长度。但在TRACE请求的上下文中，请求体通常为空，因此这个头部信息可能不是必需的。

响应范例

服务器收到TRACE请求后，会返回一个HTTP响应，包含状态行、响应头和响应体。响应体将包含服务器收到的原始请求报文。以下是一个可能的响应范例：

HTTP/1.1 200 OK
Date: Fri, 23 Oct 2024 10:00:00 GMT
Content-Type: message/http
Content-Length: [length]
Connection: keep-alive

-- response body (echoed request message)
TRACE /test/trace HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Content-Type: message/http
Content-Length: 0

在这个响应范例中，服务器返回了200 OK状态码，表示请求成功。响应头包含了日期、内容类型（设置为message/http以指示响应体包含HTTP消息）和内容长度等信息。响应体则包含了服务器收到的原始请求报文，即客户端发送的TRACE请求。

安全性注意事项

由于TRACE请求会回显原始请求报文，其中可能包含敏感信息（如身份验证凭证、Cookie等），因此存在安全风险。未经适当保护的TRACE请求可能导致信息泄露、跨站脚本攻击（XSS）或请求劫持等安全问题。因此，在实际应用中，服务器通常应禁用TRACE请求或采取其他安全措施来保护敏感信息。

URL

https://www.baidu.com:443/web/579.html?replytocom=22#respond

协议://域名:端口/虚拟目录/文件名?参数#锚点

状态码

一、1xx 信息性状态码

100 Continue

表示目前为止一切正常，客户端可以继续发送请求或忽略这个响应。一般在客户端发送POST请求时，当请求体较大，服务器可能先返回这个状态码，表示可以继续发送请求体

二、2xx 成功状态码

200 OK

表示请求已成功，服务器已成功返回请求的数据

201 CREATED

表示请求已成功，并在服务器上创建了新的资源。通常是POST请求用于创建资源时返回

204 NO CONTENT

表示请求已成功处理，但没有返回任何内容。通常用于PUT或DELETE请求成功后，表示资源已被更新或删除

三、3xx 重定向状态码

301 MOVED PERMANENTLY

表示请求的资源已被永久移动到新的URL，客户端应使用新的URL进行后续请求。

302 FOUND

表示请求的资源临时被移动到了另一个URL，客户端应继续使用原有URL进行请求，但可以根据响应中的Location头部字段进行重定向

304 NOT MODIFIED

表示资源未被修改，客户端可以使用缓存的版本。通常在客户端发送条件请求(如带有If-Modified-Since或If-None-Match头部)时返回

四、4xx 客户端错误状态码

400 BAD REQUEST

表示客户端发送的请求有语法错误或无法被服务器理解。

401 UNAUTHORIZED

表示请求需要用户认证，通常是因为客户端没有提供有效的身份验证凭证

403 FORBIDDEN

表示服务器理解请求，但拒绝执行，通常是因为客户端没有足够的权限访问资源

404 NOT FOUND

表示服务器无法找到请求的资源

405 METHOD NOT ALLOWED

表示请求的方法不被允许，例如使用了不支持的HTTP方法请求某个资源

五、5xx 服务器错误装填吗

500 INTERNAL SERVER ERROR

表示服务器在处理请求时发生了内部错误，通常是服务器端的程序出现了异常

502 BAD GATEWAY

表示作为网关或代理的服务器在尝试执行请求时，从上游服务器接收到无效的响应

503 SERVICE UNAVAILABLE

表示服务器暂时无法处理请求，通常是由于服务器过载或正在进行维护

504 GATEWAY TIMEOUT

表示作为网关或代理的服务器在等待上游服务器响应时超时

内外网划分

内网

定义

内网通常是指定一个组织或机构内部的网络，它的范围相对较小，一般局限于一个办公室、一栋楼或者一个企业园区内

特点

较高的安全性：由于内网与外部网络相互隔离，外部用户难以直接访问内网资源，因此内网通常具有较高的安全性。可以通过设置访问控制策略、防火墙等措施来进一步加强安全防护

高效的资源共享：内网中的设备可以方便地共享文件、打印机、数据库等资源，提高工作效率。

例如，在企业内部，员工可以快速访问共享的文档和数据，进行协作办公。

稳定的网络性能：内网的网路性能相对稳定，因为它的用户数量和流量通常是可控的。

可以通过优化网络架构、配置合适的网络设备来确保内网的告诉稳定运行。

用途

企业办公：企业内部的员工可以通过内网进行文件共享、邮件通信、办公自动化等工作。

例如，使用企业内部的办公软件进行项目管理、流程审批等。

学校教学：学校可以连接内网，供师生进行教学资源共享、在线学习、考试管理等。

例如，学生可以在内网上访问教学课件、提交作业，教师可以进行在线批改和成绩管理。

医疗机构：医院内部的医疗系统通常运行在内网上，以确保患者信息的安全和医疗业务的稳定运行。

例如，医生可以在内网上查看患者病历、开具处方，护士可以进行护理记录和医嘱执行

外网

定义

外网是指连接全球各地的网络，通常由互联网服务提供商(ISP)提供接入服务。外网的范围非常广泛，可以覆盖全球各个角落

特点

开放性：外网是开放的，任何人都可以通过合适的方式接入外网，获取各种信息和服务。但也带来了一定的安全风险，如网络攻击、信息泄露等。
丰富的资源：外网上拥有海量的信息和服务资源，用户可以通过搜索引擎、社交媒体、电子商务等平台获取各种所需的信息和服务。

例如，在网上购物、查询新闻、观看视频等
动态性：外网的网络环境是动态变化的，网络流量、用户行为等因素都会影响外网的性能和稳定性。因此，外网的服务质量可能会有所波动

用途

信息获取：用户可以通过外网获取各种信息、知识、娱乐等信息。

例如，通过搜索引擎查询资料，阅读在线新闻，观看电影和电视剧等
社交互动：外网提供了各种社交平台，用户可以与朋友、家人、同事等进行交流和互动。

例如，使用社交媒体发送动态、分享照片，进行在线聊天和视频通话等。
电子商务：用户可以通过外网进行在线购物、支付等电子商务活动。

例如，在网上购买商品、预定旅游服务、缴纳水电费等。

内外网IP地址划分

一、公网地址

定义

公网地址也成为全球唯一IP地址，是由互联网服务提供商(ISP)分配给用户的，可以在全球互联网上被唯一识别的地址。

特点

全球唯一性：公网地址在全球范围内是唯一的，不同的设备不能拥有相同的公网地址
可路由性：公网地址可以在互联网上被路由，使得不同网络中的设备可以相互通信
有限性：由于IPv4地址资源有限，公网地址的数量也是有限的。随着互联网的发展，公网地址的需求不断增加，导致公网地址资源日益紧张

用途

服务器托管：如果企业或个人需要将自己的服务器托管在数据中心，就需要使用公网地址，以便让全球用户都能够访问到服务器上的服务
网站建设：网站服务器需要公网地址才能被互联网上的用户访问
远程办公：对于需要远程访问公司内部网络资源的员工，公司可以为其分配公网地址，以便通过VPN等技术实现远程访问。

二、私网地址

定义

私网地址也称为本地IP地址，是在一个组织或机构内部使用的IP地址，不能在全球互联网上被直接访问

特点

可重复使用：私网地址可以在不同的组织或机构内部重复使用，因为它们不会在全球互联网上被路由
灵活性：私网地址的分配可以由组织或机构内部自行管理，具有较高的灵活性
安全性：由于私网地址不能在全球互联网上被直接访问，因此可以提高网络的安全性，减少外部攻击的风险

用途

企业内部网络：企业可以使用私网地址构建自己的内部网络，实现内部设备之间的通信和资源共享
家庭网络：家庭用户可以使用私网地址哦固件自己的家庭网络，连接多台设备，

如电脑、手机、智能电视等
无线网络：无线接入点(如无线路由器)通常会为连接的设备分配私网地址，以便在家庭或企业内部实现无线网络覆盖

常见的私网地址范围

10.0.0.0 - 10.255.255.255

172.16.0.0 - 172.31.255.255

192.168.0.0 - 192.168.255.255

OSI七层模型

基础定义

开放系统互连参考模型 (Open System Interconnect 简称OSI）是国际标准化组织(ISO)和国际电报电话咨询委员会(CCITT)联合制定的开放系统互连参考模型，为开放式互连信息系统提供了一种功能结构的框架。

它从低到高分别是：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。

在通信过程中，数据的传输会经历封装与解封装，这一过程与发快递和拆快递及其类似。

各层的主要作用

1.物理层: 建立和维护用于传输和接受二进制信息的物理链路，物理层的典型设备：光纤、同轴电缆、双绞线、中继器和集线器。

2.数据链路层：为物理链路提供可靠的数据传输，包括错误的检测和修正，数据链路层的典型设备：二层交换机、网桥、网卡。

3.网络层: 提供网络中的数据包寻址和传输服务，网络层的典型设备：路由器。

4.传输层: 为端点之间提供透明的、可靠的数据传输、端到端错误修复、流量控制。

5.会话层:控制计算机之间的会话。

6.表示层:提供数据转换服务，如加密、压缩、格式化，表示层有三项工作内容：(1).语法转换；(2).语法选择；(3).联接管理。

7.应用层:协助应用程序与网络通讯。

下面是用python写的一个网络通讯的示例代码，具体工作的层级在代码后面做讲解。

# 服务器端
# 导入socket模块，用于网络通信  
import socket   
  
# TCP服务器部分  
  
# 创建一个TCP套接字，指定使用IPv4（AF_INET）和TCP协议（SOCK_STREAM）  
sk = socket.socket(family=socket.AF_INET, type=socket.SOCK_STREAM)    
  
# 将套接字绑定到本地地址（127.0.0.1）和端口（8080）上  
sk.bind(('127.0.0.1', 8080))    
  
# 设置监听队列的大小为5，这意味着最多可以有5个未处理的连接请求在等待  
sk.listen(5)    
  
# 使用try-except结构来捕获可能的异常，并使用finally来确保资源被正确释放  
try:    
    # 无限循环，等待并接受客户端的连接  
    while True:    
        # accept()方法会阻塞，直到有一个连接请求到达  
        # 它返回一个新的套接字（conn）和客户端的地址（addr）  
        conn, addr = sk.accept()    
        try:    
            # 接收客户端发送的数据，最多接收1024字节  
            from_client_msg = conn.recv(1024)    
            # 打印接收到的数据，需要先将其从字节转换为字符串  
            print(from_client_msg.decode('utf-8'))    
            # 向客户端发送数据  
            conn.send(b'hello world')    
        # 使用finally来确保无论是否发生异常，连接都会被关闭  
        finally:    
            conn.close()    
# 捕获键盘中断（Ctrl+C），打印退出信息  
except KeyboardInterrupt:    
    print("TCP服务器已退出")    
# 无论是否发生异常，最后都要关闭主套接字  
finally:    
    sk.close()    
  
# UDP服务器部分  
# 注意：通常TCP和UDP服务器不会监听同一个端口，这里为了示例目的而使用同一个端口  
  
# 创建一个UDP套接字，指定使用IPv4（AF_INET）和UDP协议（SOCK_DGRAM）  
sk = socket.socket(family=socket.AF_INET, type=socket.SOCK_DGRAM)    
  
# 将套接字绑定到本地地址（127.0.0.1）和端口（8080）上  
# 注意：这里会抛出异常，因为端口8080已经被TCP服务器占用  
# 在实际部署中，应该为UDP服务器指定一个不同的端口  
sk.bind(('127.0.0.1', 8080))    
  
# 使用try-except结构来捕获可能的异常  
try:    
    # 无限循环，等待并接收客户端的数据报  
    while True:    
        # recvfrom()方法会阻塞，直到有一个数据报到达  
        # 它返回接收到的数据（from_client_msg）和发送方的地址（addr）  
        from_client_msg, addr = sk.recvfrom(1024)    
        # 打印接收到的数据，需要先将其从字节转换为字符串  
        print(from_client_msg.decode('utf-8'))    
        # 向客户端发送数据报  
        sk.sendto(b'hello world', addr)    
# 捕获键盘中断（Ctrl+C），打印退出信息  
except KeyboardInterrupt:    
    print("UDP服务器已退出")    
# 无论是否发生异常，最后都要关闭套接字  
finally:    
    sk.close()

# 客户端
# 导入socket模块，用于网络通信  
import socket  
  
# TCP客户端部分  
  
# 创建一个TCP套接字（默认使用IPv4和TCP协议）  
sk = socket.socket()  
  
# 连接到本地服务器（127.0.0.1）的8080端口  
sk.connect(('127.0.0.1', 8080))  
  
# 向服务器发送数据（'hi'的字节表示）  
sk.send(b'hi')  
  
# 从服务器接收数据，最多接收1024字节  
from_server_msg = sk.recv(1024)  
  
# 打印接收到的数据（需要先将其从字节转换为字符串）  
print(from_server_msg.decode('utf-8'))  
  
# 关闭TCP套接字  
sk.close()  
  
# UDP客户端部分  
  
# 创建一个UDP套接字，指定使用IPv4（AF_INET）和UDP协议（SOCK_DGRAM）  
sk = socket.socket(family=socket.AF_INET, type=socket.SOCK_DGRAM)  
  
# 对于UDP，connect方法是可选的，但可以用来指定默认的目标地址。  
# 这意味着后续的sendto操作可以省略目标地址参数。  
# 注意：如果服务器不在127.0.0.1:8080上运行，这里需要修改为目标服务器的地址和端口。  
# 然而，由于UDP是无连接的，这里的connect调用并不建立持久的连接，  
# 它只是设置了默认的发送目标。  
sk.connect(('127.0.0.1', 8080))  
  
# 使用try-except结构来捕获可能的异常，并使用finally来确保资源被正确释放  
try:  
    # 无限循环，等待用户输入  
    while True:  
        # 获取用户输入，并去除前后的空白字符  
        msg = input('>>: ').strip()  
          
        # 如果用户没有输入任何内容，则继续下一次循环  
        if not msg:  
            continue  
          
        # 向服务器发送数据（用户输入的字节表示）  
        # 注意：由于之前已经调用了connect，所以这里可以省略目标地址参数，  
        # 但为了清晰起见，这里还是保留了目标地址参数。  
        # 在实际使用中，如果之前已经connect，则可以省略第二个参数。  
        sk.sendto(msg.encode('utf-8'), ('127.0.0.1', 8080))  
          
        # 从服务器接收数据，recvfrom返回数据和发送方的地址（这里不需要发送方地址，所以用_忽略）  
        data, _ = sk.recvfrom(1024)  
          
        # 打印接收到的数据（需要先将其从字节转换为字符串）  
        print(data.decode('utf-8'))  
except KeyboardInterrupt:  # 捕获键盘中断（Ctrl+C），打印退出信息  
    print("客户端已退出")  
finally:  
    # 无论是否发生异常，最后都要关闭套接字  
    sk.close()

以上两种代码（TCP客户端和UDP客户端）在OSI七层模型中主要工作在传输层和数据链路层，但它们的关注点主要在传输层。这主要是因为，TCP和UDP协议提供了在应用程序之间传输数据的机制。

模型与协议的对应关系

ARP

地址解析协议，即ARP（Address Resolution Protocol），是根据IP地址获取物理地址的一个TCP/IP协议。主机发送信息时将包含目标IP地址的ARP请求广播到网络上的所有主机，并接收返回消息，以此确定目标的物理地址。

ARP协议工作过程:

主机A的IP地址为192.168.1.1，MAC地址为0A-11-22-33-44-01；

主机B的IP地址为192.168.1.2，MAC地址为0A-11-22-33-44-02；

当主机A要与主机B通信时，地址解析协议(ARP)可以将主机B的IP地址（192.168.1.2）解析成主机B的MAC地址，以下为工作流程：

第1步：根据主机A上的路由表内容，IP确定用于访问主机B的转发IP地址是192.168.1.2。然后A主机在自己的本地ARP缓存中检查主机B的匹配MAC地址。

第2步：如果主机A在ARP缓存中没有找到映射，它将询问192.168.1.2的硬件地址，从而将ARP请求帧广播到本地网络上的所有主机。源主机A的IP地址和MAC地址都包括在ARP请求中。本地网络上的每台主机都接收到ARP请求并且检查是否与自己的IP地址匹配。如果主机发现请求的IP地址与自己的IP地址不匹配，它将丢弃ARP请求。

第3步：主机B确定ARP请求中的IP地址与自己的IP地址匹配，则将主机A的IP地址和MAC地址映射添加到本地ARP缓存中。

第4步：主机B将包含其MAC地址的ARP回复消息直接发送回主机A。

第5步：当主机A收到从主机B发来的ARP回复消息时，会用主机B的IP和MAC地址映射更新ARP缓存。

本机缓存是有生存期的，生存期结束后，将再次重复上面的过程。主机B的MAC地址一旦确定，主机A就能向主机B发送IP通信了。

ARP命令可用于查询本机ARP缓存中IP地址和MAC地址的对应关系、添加或删除静态对应关系等。相关协议有RARP、代理ARP。NDP用于在IPv6中代替地址解析协议。

arp -a或arp –g
用于查看缓存中的所有项目。
arp -a Ip
如果有多个网卡，那么使用arp -a加上接口的IP地址，就可以只显示与该接口相关的ARP缓存项目。
arp -s Ip 物理地址
可以向ARP缓存中人工输入一个静态项目。
arp -d Ip
使用该命令能够人工删除一个静态项目。

ICMP

它是TCP/IP协议族的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。

我们常用的ping命令和traceroute命令都基于ICMP协议

TCP

TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。在TCP通信中，必须先建立连接，然后进行数据的传输，最后释放连接。TCP通过三次握手来建立连接，并通过四次挥手来释放连接。

1.ACK:当ACK=1时，表示确认号字段有效，接收端已正确接收到发送端发送的某个序号的数据，并期望接收下一个序号的数据。

2.SYN:SYN字段用于建立TCP连接。当SYN=1时，表示这是一个连接请求报文。

3.FIN:FIN字段用于释放TCP连接。当FIN=1时，表示发送端已经没有数据要发送了，希望释放连接。

4.SEQ:SEQ字段用于标记TCP报文中数据的顺序。它是一个整数，随着数据的发送而递增。

UDP

UDP是一种无连接的、不可靠的传输层协议。与TCP不同，UDP在发送数据之前不需要建立连接，因此具有较低的开销和延迟。

IP地址与子网划分

IP地址

IP 是网络层协议，也是当今应用最广泛的网络协议之一。

1.A 类地址中 :10.0.0.0到 10.255.255.255 2.B 类地址中 :172.16.0.0到 172.31.255.255 3.C 类地址中 :192.168.0.0到 192.168.255.255

子网划分

例子背景

假设某公司申请到了一个C类IP地址段192.168.1.0/24（即子网掩码为255.255.255.0），现在需要将这个网络划分为4个子网，以供公司的4个不同部门使用。

子网划分步骤

确定子网掩码：
- 原始C类IP地址的子网掩码是255.255.255.0，转换成二进制表示为11111111.11111111.11111111.00000000。
- 要划分为4个子网，需要借用2位主机位（在二进制中，2位可以表示4个不同的值（00、01、10、11），因此借用2位主机位作为子网位是满足这一需求的最低要求）。
- 因此，新的子网掩码二进制表示为11111111.11111111.11111111.11000000，即255.255.255.192。
计算子网地址：
- 使用子网掩码和IP地址进行按位逻辑“与”运算，可以得到网络地址。
- 对于192.168.1.0/24，其网络地址本身就是192.168.1.0。
- 接下来，通过增加子网偏移量（即每次增加256-192=64，因为子网掩码最后两位是11，表示子网大小为64）来计算其他子网地址。
  - 子网1：192.168.1.0（偏移量0）
  - 子网2：192.168.1.64（偏移量64）
  - 子网3：192.168.1.128（偏移量128）
  - 子网4：192.168.1.192（但注意，这个地址实际上是子网3的广播地址的下一个地址，通常不作为子网地址使用，这里仅为了说明划分过程而列出）
    - 在实际划分中，由于子网4的起始地址与子网3的广播地址相邻，因此通常会将子网3的范围扩展到192.168.1.191，并放弃使用192.168.1.192作为子网地址。
计算每个子网的有效主机范围：
- 每个子网的有效主机范围是从子网地址的下一个地址开始，到该子网的广播地址的前一个地址结束。
- 子网1的有效主机范围是192.168.1.1到192.168.1.62（广播地址为192.168.1.63）。
- 子网2的有效主机范围是192.168.1.65到192.168.1.126（广播地址为192.168.1.127）。
- 子网3（扩展到192.168.1.191）的有效主机范围是192.168.1.129到192.168.1.190（广播地址为192.168.1.191）。

何为广播地址：

广播地址用于在TCP/IP协议的网络中，将数据包发送给同一网络中的所有设备。

当一个设备向广播地址发送数据包时，所有连接到该网络的设备都会接收到这个数据包。

这种机制类似于广播电台或电视广播，发送者无需知道接收者的具体地址，就能将信息发送给所有收听或收看的设备。

子网划分与主机部分位数

在IPv4地址中，一个地址由32位二进制数组成。当我们进行子网划分时，我们实际上是在决定这32位中有多少位用于表示网络部分（即子网号），以及多少位用于表示主机部分。

子网掩码用于区分这两部分。子网掩码中的1表示网络部分，0表示主机部分。

例如，在C类地址中，默认的子网掩码是255.255.255.0，其二进制表示为11111111.11111111.11111111.00000000。这意味着前24位是网络部分，后8位是主机部分。

现在，如果我们改变子网掩码，使其最后两位变为11（即二进制中的.01），则新的子网掩码将是255.255.255.192。

在二进制中，这表示为11111111.11111111.11111111.11000000。这意味着网络部分现在占据了前26位，而主机部分只剩下6位。

计算可用主机数量

由于主机部分用于标识网络中的设备，因此每个子网中的设备数量将取决于主机部分的位数。然而，有两个特殊的地址不能分配给设备：

网络地址：主机部分全为0的地址，用于标识整个子网。
广播地址：主机部分全为1的地址，用于向子网中的所有设备发送广播消息。

因此，在计算每个子网中可用的主机数量时，我们需要从2的主机部分位数次方中减去2。

在我们的例子中，主机部分是6位，所以理论上可能有2^6 = 64个不同的地址。

泷羽sec-星河飞雪-web基础

http协议简介

http协议版本

一、HTTP/0.9

诞生背景

主要特性

使用场景

HTTP/1.0

诞生背景

主要特性

一、定义与用途

二、主要类型

三、在HTML中的实现

四、重要性

适用场景

三、HTTP/1.1

诞生背景

主要特性

适用场景

四、HTTP/2

诞生背景

主要特性

一、定义

二、作用

三、帧的结构

四、应用实例

五、优势与特点

一、作用与目的

二、原理与实现

三、特点与优势

四、应用场景

适用场景

HTTP/3

诞生背景

主要特性

一、概述

二、核心特性

三、数据包格式与建立连接

四、优势与应用

五、挑战与未来

一、定义与原理

二、实现步骤

三、优势与应用场景

四、注意事项与安全风险

使用场景

http协议请求方法

GET

用途

特点

范例

HTTP GET请求范例

解释

响应范例

POST

用途

特点

范例

HTTP POST请求范例

解释

响应范例

PUT

用途

特点

范例

HTTP PUT请求范例

解释

响应范例

DELETE

用途

特点

范例

HTTP DELETE请求范例

解释

响应范例

HEAD

用途

特点

范例

HTTP HEAD请求范例

解释