【Linux-HTTP协议】HTTP知识延续+HTTP设计改进

代码定位：南毅c/Linux - Gitee.com

HTTP常见Header

• Content-Type：数据类型（text/html 等） • Content-Length: Body 的长度 • Host：客户端告知服务器，所请求的资源是在哪个主机的哪个端口上； • User-Agent：声明用户的操作系统和浏览器版本信息； • referer：当前页面是从哪个页面跳转过来的； • Location：搭配 3xx 状态码使用，告诉客户端接下来要去哪里访问； • Cookie： 用于在客户端存储少量信息.通常用于实现会话（session）的功能；

请求头名称	描述
Accept	指定客户端能够接收的内容类型
Accept-Charset	浏览器可以接受的字符编码集。
Accept-Encoding	指定浏览器可以支持的web服务器返回内容压缩编码类型。
Accept-Language	浏览器可接受的语言
Authorization	认证信息，通常出现在对服务器发送的请求头中，告知服务器客户端的认证信息。
Connection	控制不同请求间的连接的选项，如Keep-Alive保持连接。
Cookie	服务器通过Set-Cookie设置的一个字符串，存储在客户端，然后每次请求都会携带这个字符串。
Content-Length	请求的内容长度
Content-Type	请求的与实体对应的MIME信息
Host	指定请求的服务器的域名和端口号
If-Modified-Since	如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码。
User-Agent	包含了发出请求的用户信息，如浏览器类型、操作系统等。

响应头名称	描述
Access-Control-Allow-Origin	允许跨域请求的域名。
Cache-Control	控制缓存的行为
Content-Disposition	一个可以让客户端下载文件并建议文件名的头部信息。
Content-Encoding	服务器发送的数据采用的编码类型。
Content-Type	服务器发送内容的MIME类型
Date	请求的时间，由服务器返回
ETag	资源的匹配信息，用来缓存验证。
Expires	设置过期时间，允许客户端在这个时间之前不去检查，可减少网络流量。
Last-Modified	资源最后一次修改的时间
Location	用于重定向一个新的位置，告诉浏览器应该去哪里访问资源。
Server	服务器的一些相关信息，如名称、版本等。
Set-Cookie	设置Cookie，服务器通过这个头部把Cookie传给客户端。
Transfer-Encoding	传输编码，如chunked表示数据以一系列分块的形式进行发送。
WWW-Authenticate	实体应该使用的授权方案，用于HTTP认证。

关于connection报头

HTTP 中的Connection 字段是 HTTP报文头的一部分，它主要用于控制和管理客户端与服务器之间的连接状态 核心作用 • 管理持久连接：Connection 字段还用于管理持久连接（也称为长连接）。持久连接允许客户端和服务器在请求/响应完成后不立即关闭TCP 连接，以便在同一个连接上发送多个请求和接收多个响应。 持久连接（长连接） • HTTP/1.1：在HTTP/1.1协议中，默认使用持久连接。当客户端和服务器都不明确指定关闭连接时，连接将保持打开状态，以便后续的请求和响应可以复用同一个连接。 • HTTP/1.0：在HTTP/1.0协议中，默认连接是非持久的。如果希望在 HTTP/1.0上实现持久连接，需要在请求头中显式设置 Connection:keep-alive。 语法格式 •Connection:keep-alive： 表示希望保持连接以复用TCP 连接。 •Connection：close：表示请求/响应完成后，应该关闭TCP连接。

HTTP的状态码

状态码	类别	原因短语
1XX	Informational（信息性状态码）	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出错

常见的HTTP状态码及其含义

以下是一些常见的HTTP状态码及其含义的表格：

状态码	类别	描述
200	成功	请求已成功处理，通常用于GET请求
201	成功	请求已成功处理，并且创建了新的资源，通常用于POST请求
204	成功	请求已成功处理，但没有返回任何内容
301	永久重定向	请求的资源已永久移动到新位置
302	临时重定向	请求的资源临时移动到新位置
304	未修改	资源未修改，可以使用缓存版本
400	客户端错误	请求有语法错误或无法完成
401	客户端错误	请求需要用户认证
403	客户端错误	服务器拒绝请求
404	客户端错误	请求的资源不存在
405	客户端错误	请求的方法不允许
408	客户端错误	请求超时
500	服务器错误	服务器内部错误
501	服务器错误	服务器不支持请求的功能
502	服务器错误	错误的网关
503	服务器错误	服务器暂时不可用
504	服务器错误	网关超时
505	服务器错误	服务器不支持HTTP协议版本

HTTP重定向

状态码	描述
301	永久重定向。请求的资源已永久移动到新位置，将来所有对该资源的引用都应该使用新的URI。
302	临时重定向。请求的资源临时移动到新位置，客户端应继续使用原有URI。
303	参见其他。通常在POST请求后使用，告诉客户端可以获取另一个URI的资源，并且应该使用GET方法。
307	临时重定向。与302类似，但不会改变请求方法，即如果原始请求是POST，重定向后的请求也应该是POST。
308	永久重定向。与301类似，但不会改变请求方法，即如果原始请求是POST，重定向后的请求也应该是POST。

这些状态码用于指示客户端应该访问另一个URL以获取请求的资源。301和308表示永久性重定向，而302、303和307表示临时性重定向。

• 如何理解永久重定向与临时重定向

现在你是学校的一位学生，你的学校北门有一家非常好吃的饺子店，你经常去吃；但是最近一段时间北门和饺子店的路要维修，你无法通过北门去饺子店，饺子店也因此生意不好；于是饺子店老板临时将店搬到南门，而身为学生你的又不知道饺子店搬到南门，于是老板在北门饺子店填张告示“因道路维修，饺子店临时搬到南门”；于是你去了一次饺子店后发现搬到南门去了，于是你又从北门回到南门，这就是重定向，由于店面是临时搬的，所以叫做临时重定向；后面老板发现南门的生意比以往在北门好多了，于是就在南门贴告示“此饺子店已转移到南门，想吃饺子的去南门饺子店”，这种永久搬过去的，就是永久重定向

对于永久重定向一般是给搜索引擎看的

客户端要访问www.abc.com于是向服务器发送请求，服务器去网站各个站点里获取，这样客户端能够得到响应，进入网站；现在经abc董事会决定，将www.abc.com改为www.xyz.com，但是以前访问的人并不知道域名更改了，于是还是访问以前网站，为了不丢失老客户，技术部门将原网站进行重定向，这样访问的是abc网站，实际已经跳转到xyz网站了；我们也都知道，浏览器是可以有标签的，通过标签用户可以不再自己手动输入网址，点击标签就可以转到对于网站，对于搜索引擎来说，访问一个网站自动跳转到另一个网站效率不高，于是搜索引擎在后台经常偷偷爬abc网站，发现每次都要跳转到xyz网站，又发现是永久重定向，于是就在标签内把网站地址更改了

 关于重定向的验证，以301为代表 HTTP状态码301（永久重定向）和302（临时重定向）都依赖Location选项。以下是关于两者依赖Location选项的详细说明: HTTP状态码301(永久重定向): 当服务器返回HTTP 301状态码时，表示请求的资源已经被永久移动到新的位置。 在这种情况下，服务器会在响应中添加一个Location头部，用于指定资源的新位置。这个Location头部包含了新的URL地址，浏览器会自动重定向到该地址。 例如，在HTTP响应中，可能会看到类似于以下的头部信息:

HTTP/1.1 301 Moved Permanently\r\n
Location: https://www.new-url.com\r\n

HTTP状态码302(临时重定向): 当服务器返回HTTP 302状态码时，表示请求的资源临时被移动到新的位置。 同样地，服务器也会在响应中添加一个Location头部来指定资源的新位置。浏览器会暂时使用新的URL进行后续的请求，但不会缓存这个重定向。 例如，在HTTP响应中，可能会看到类似于以下的头部信息:

HTTP/1.1 302 Found\r\n
Location: https://www.new-url.com\r\n

总结：无论是HTTP 301还是HTTP 302重定向，都需要依赖Location选项来指定资源的新位置。这个Location选项是一个标准的HTTP响应头部，用于告诉浏览器应该将请求重定向到哪个新的URL地址。

HTTP GET 与 POST请求方法

在看这部分之前先看HTTP设计改进添加请求方法

经过测试我们可以得出结论

• GET一般用来获取静态资源，也可以通过url向服务器传递参数

• POST可以通过http request的正文来进行参数传递

• URL传递参数，参数的体量一定不大，正文可以很大

• POST方法，比GET方法传参更私密，但是都不安全；所以我们要对http的参数部分进行加密https

HTTP GET请求方法

在HTTP请求方法中最常见的就是GET 与POST请求方法

在我们设计请求的时候也加入了method字段

GET请求用于请求指定的资源。使用GET方法的请求应该只用于获取数据，而不应该改变资源的状态

特点：

• 数据在URL中传输：GET请求将请求数据附加在URL之后，每个参数之间用&连接。

• 数据大小限制：由于数据在URL中，因此GET请求传输的数据量通常有限制，大约为2048个字符。

• 安全性：由于数据在URL中是可见的，因此GET请求不适用于传输敏感信息，如密码。

• 缓存：GET请求可以被缓存。

• 书签：GET请求的URL可以被收藏为书签。

使用场景：

• 查询数据的检索。

• 读取数据，不修改资源。

HTTP POST请求方法

POST请求用于向服务器提交数据，通常会导致在服务器上的状态变更或副作用。

特点：

• 数据在请求体中传输：POST请求将数据放置在HTTP请求的消息体（body）中。

• 数据大小无限制：理论上，POST请求没有数据大小限制，适用于传输大量数据。

• 安全性：数据不会出现在URL中，因此比GET请求更安全，适合传输敏感信息。

• 缓存：POST请求不会被缓存。

• 书签：POST请求的URL通常不可被收藏为书签。

使用场景：

• 提交表单数据。

• 创建或更新资源。

对比

• 数据传输方式： GET通过URL传输，POST通过请求体传输。

• 数据大小： GET请求有大小限制，POST请求理论上无限制。

• 安全性： POST比GET更安全，因为数据不会暴露在URL中。

• 用途： GET用于请求数据，POST用于提交数据，可能会导致服务器上状态的变化。

理解表单中的action

理解Cookie

Cookie是在用户浏览网站时，网站存储在用户计算机上的一小段数据。它们通常用于网站记住用户的信息和浏览习惯，以便在用户下次访问时提供更个性化的体验

1. 什么是Cookie？

定义：Cookie是一种网络技术，用于网站服务器和用户浏览器之间传递信息。
存储位置：Cookie存储在用户的计算机上，通常在浏览器的缓存文件夹中。
类型：根据其生命周期和作用范围，Cookie可以分为多种类型，如会话Cookie、持久Cookie、第一方Cookie和第三方Cookie。
2. Cookie的工作原理

创建：当用户访问一个网站时，网站的服务器会发送一段数据到用户的浏览器，并指示浏览器存储这些数据。
发送：之后，每次用户向同一网站发送请求时，浏览器都会检查是否存在与该网站相关的Cookie，并将其发送回服务器。
读取：服务器读取这些Cookie来识别用户，或者获取之前存储的用户信息。
3. Cookie的用途

会话管理：例如，在线购物时，Cookie可以用于跟踪用户添加到购物车的商品。
个性化：网站可以根据用户的偏好设置显示不同的内容。
登录信息：记住用户的登录信息，使得用户在下次访问时无需重新登录。
跟踪用户行为：分析用户在网站上的行为，帮助网站所有者改进网站设计和用户体验。

 

HTTP设计改进

添加状态码

我们已经了解了状态码的含义，接着我们也在我们网站中加这样需求，如果我们没有读到内容（请求失败），我们跳到404页面，然后添加状态码

这下我们访问一个不存在的资源路径，就自动跳到404页面了

 

添加重定向

 

 

测试1：我们路径搜索指定redir就默认打开了重定向网页

 

测试2：点击重定向后就跳转到指定网站了

 

 

添加请求方法

 

接着我们对我们的代码进行添加表单；表单是HTML语言中的一个功能，常用于设置登录页面

我们在login.html添加表单，接着我们进行测试

 由于我们表单填写的属性，我们这里输入密码就是隐藏的

然后我们点击提交

观察URL：http://47.120.76.87:8888/login?username=wuxu&userpasswd=123456

我们的URL就在？后面添加了我们输入的信息，这就是GET请求，数据在URL中传输：GET请求将请求数据附加在URL之后，每个参数之间用&连接

我们的服务器也接受到了相应的信息

 接着我们把GET请求换成POST请求，此时我们提交后发现我们的URL不在保存我们的信息，而是到了正文部分

 

 

既然这样，那么我们就要对我们之前截取URL重新设计，如果是GET请求，就需要通过？进行截取

 

获取请求参数

 

接着我们打开打印

 

接着我们使用Postman构建HTTP响应，发送请求

 

我们服务器也就接收到了请求

 

再来我们发送数据，当我们添加数据的时候，URL也就自动带上了数据

 

 

接着我们用POST请求发送数据

 

也验证了我们在我们的正文部分收到数据

 

接着我们用网页测试输入一下

 

 

函数封装

GET不仅仅可以获取静态资源，

传给我一个请求，返回一个应答

 创建一个服务列表，给定参数，执行方法

 

 

 如果存在，就执行回掉，并把结果返回给resp，最后反序列化回去

测试结果

 

我们也封装了，那么如何理解这里的action呢

 

 

在HTML表单（<form>）元素中，action 属性指定了当用户提交表单时，表单数据应该被发送到的URL。这里是关于 <form> 标签中 action 属性的详细解释：

• 属性名称：action

• 作用：定义在提交表单时，浏览器应该发送表单数据到哪个URL。

• 值：一个相对或绝对的URL。

在你提供的HTML代码片段中：

<form action="/login" method="GET">
    ...
</form>

• action="/login" 表示当用户填写完表单并点击提交按钮时，表单数据将会被发送到服务器上的 /login 路径。

• 由于 method 属性被设置为 "GET"，表单数据将会通过HTTP GET请求发送。这意味着表单中的数据会被附加到URL上，作为查询字符串。

因此，如果用户输入用户名为 alice 和密码为 password123，然后点击提交按钮，浏览器将会构造一个类似以下的URL并发起GET请求：

/login?username=alice&userpasswd=password123

这里的login不就是我们刚刚写的服务列表中的服务吗？，问号后面的是参数，参数会提交到login对应的服务列表，执行相关服务，再将结果返回

我们拿百度的一个网站解释一下

百度安全验证

我们自己的是login，百度这里是s，问号后面是一堆参数1，GET方法把参数提交给百度，把后面参数全部交给/s服务，所以/s相当于在服务器注册一个服务列表，并且有对应执行算法（搜索算法），所以它的参数回掉执行对应函数以后，对应算法服务就可以通过回掉把请求的执行后的参数就全部交给我了，交给我之后不就可以看到我们搜索后的内容了吗？

 加入Cookie

 

附录

HTTP历史及版本核心技术与时代背景

HTTP（超文本传输协议）是互联网上应用最为广泛的协议之一，它定义了客户端（用户）和服务器之间交换数据的格式和规则。以下是HTTP的历史、各版本的核心技术以及它们的时代背景。

版本	发布年份	时代背景	核心技术
HTTP/0.9	1991年	互联网开始向公众开放，网页以纯文本为主	- 该版本非常简单，仅包含一个命令GET，用于从服务器请求文档。 - 服务器在发送响应后立即关闭TCP连接。 - 仅支持传输HTML文档。
HTTP/1.0	1996年	网页开始包含图片、视频等多媒体内容	- 引入了POST和HEAD命令，使得HTTP协议更加灵活。 - 支持传输多种类型的文件，不仅限于HTML。 - 引入了状态码和头信息，以便更好地处理请求和响应。 - 每次请求/响应后，TCP连接都会关闭，即没有持久连接的概念。
HTTP/1.1	1997年	互联网商业化，网站和应用变得复杂	- 默认采用持久连接，允许在同一个TCP连接中传输多个HTTP请求/响应，减少了建立和关闭连接的开销。 - 引入管道化技术，允许客户端在等待一个请求的响应的同时发送另一个请求。 - 改进了缓存机制，如引入了ETag和If-None-Match等头部字段。 - 支持虚拟主机，即一个服务器可以服务于多个域名。
SPDY	2009年	Web应用变得更加动态和交互，对性能有更高的要求	- 强制使用SSL/TLS加密，提高了数据传输的安全性。 - 通过压缩HTTP头部、优先级和多路复用等技术，提高了页面加载速度。
HTTP/2	2015年	移动互联网兴起，用户对网络性能和安全性有更高的期待	- 引入了二进制分帧层，使得HTTP/2的传输效率更高。 - 实现了多路复用，可以在同一个连接中同时处理多个请求和响应。 - 引入了头部压缩机制（HPACK），减少了传输开销。 - 允许服务器主动向客户端推送数据，即服务器推送功能。
HTTP/3（草案）	未正式发布	随着技术的发展，对网络延迟和安全性有了更高的要求	- 基于QUIC协议，运行在UDP之上，提供了更好的网络性能和安全性。 - 减少了连接建立时间，支持0-RTT连接重用。 - 改善了移动网络下的性能和可靠性，尤其是在网络切换和漫游场景下。