【计算机网络】HTTP协议

---

1. HTTP介绍

HTTP（hypertext transfer protocol）是一种常用的应用层协议，用于在计算机之间传输超文本数据。 它是Web通信的基础，客户端（通常是浏览器）和服务器使用HTTP协议传输网页、视频、图片等资源。下面是HTTP协议的一些特性：

1. 基于请求-响应模型。 浏览器客户端发送HTTP请求，请求中包含客户端欲获得的资源，服务器接收并处理请求，并返回响应到客户端，响应通常包含客户端请求的资源和状态信息。
2. HTTP是无状态的。 “无状态”也可称为“无记忆”，即客户端每次HTTP请求都是独立的，服务器不会在多个请求之间保留关于客户端的状态信息，这意味着服务器看待每个请求都像是孤立的，新的事件。
3. 持久连接： 为了提高性能，HTTP/1.1引入了持久连接，允许多个请求和响应在同一TCP连接上传输，减少了连接建立和拆除的开销。在此之前的HTTP/1.0是无连接的，即发送一次请求创建一个新连接。

认识URL

URL（uniform resource Locator）统一资源定位符，是HTTP标识某个特定资源的方式，可以定位资源的地址。

Scheme: 表明浏览器使用哪种协议，通常是http或https（安全版http，后面详谈）。

Domain Name: 服务器域名，标识申请资源在哪一台服务器上，本质上是一个ip地址，也可以直接用服务器的ip地址。

Port：服务器端口号。http/https协议规定了标准端口号（http: 80, https: 443），若URL此项为空则根据Scheme默认使用标准。

Path to the file: 请求资源在服务器上的路径。这个路径虽然看起来以根目录起始，但在服务器中一般是在某个wwwroot文件夹下的。

Parameters: 提交到服务器的一些参数，从?开始，以key=value的形式保存并以&为分隔符隔开。服务器可以使用这些参数来执行额外的操作，具体作何操作由服务器决定。

Anchor: 片段标识符，从#开始。锚点表示资源中的一种“书签”，给浏览器显示位于该“加书签”位置的内容的方向。例如，在 HTML 文档上，浏览器将滚动到定义锚点的位置。

参考文章：

什么是URL？

---

2. HTTP消息结构

先认识HTTP请求和响应的宏观结构，再深入理解结构中的不同内容。

请求request

HTTP请求（request）结构如下：

请求由四部分构成，分别为：请求行、请求报头、空行和正文。每部分由分隔符\r\n以行的形式隔开。

1. 请求行（request line）：包含请求方法（最常见的是GET和POST）、URL和http协议版本（HTTP/1.0, HTTP/1.1），每部分以空格分隔。这里的URL不一定是携带域名和端口号的完整URL，一般只是服务器资源路径，因为HTTP客户端已经知道您要访问的资源来自哪个主机地址，通常会保存在请求报头的Host字段中。
2. 报头（headers）：请求的属性，以冒号分割的键值对，每组属性之间用\r\n隔开。
3. 空行：空行代表报头部分的结束，进入正文部分
4. 正文（body）：若请求是POST/PUT等用于上传的方法，正文可以包含上传至服务器的数据资源。对于GET请求，请求正文通常是不包含数据的。

响应response

HTTP响应（response）结构如下：

响应同样由四部分构成，分别为：状态行、响应报头、空行和正文。每部分由分隔符\r\n以行的形式隔开。

1. 状态行（response line）：包含协议版本、状态码、（状态码对应的）状态描述
2. 响应报头（headers）：响应的属性，以冒号分割的键值对，每组属性之间用\r\n隔开。
3. 空行：空行代表报头部分的结束，进入正文部分
4. 正文（body）：发送给客户端的各种类型的资源，如：网页资源、视频、图像等。本质是二进制数据，客户端收到后会根据正文类型（Content-Type，响应header的一种）做解析，得到自己想要的资源。

---

3. HTTP请求方法

根据 HTTP 标准，HTTP 请求可以使用多种请求方法。

• HTTP/1.0定义了三种请求方法：GET, POST 和 HEAD 方法。

• HTTP/1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

请求方法	描述
GET	请求指定资源，返回资源实体
POST	向指定资源提交数据进行处理请求，如：提交表单、上传各种文件。数据包含在请求正文中，POST可能会导致新资源的创建或已有资源的修改。POST请求不会在客户端缓存，因此浏览器查无POST请求记录。
HEAD	类似于GET，不同的是请求后返回的响应没有具体的正文内容，只用于获取响应报头。
PUT	向服务器中指定的URL路径上传或更新完整的资源。
DELETE	请求服务器删除指定页面
CONNECT	HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS	允许客户端查看服务器的性能
TRACE	回显服务器收到的请求，主要用于测试或诊断
PATCH	是对 PUT 方法的补充，用来对已知资源进行局部更新 。

• GET和POST方法都可以向服务器提交参数，区别在于GET通过URL提交，而POST通过请求正文提交。

  例子：form表单提交参数，可选择提交参数的方式GET/POSE，可以对比两种方式服务器收到请求的区别。（测试环境为作者自行编写的一个简单的HTTP服务器）

  若选择method=“GET”

  

  若选择method=“POST”

  

• POST和PUT的区别：POST通常用于执行各种不同的操作，提交某些请求数据，以供服务器完成特定的处理，如登录账号。PUT一般是向服务器指定路径上传或更新完整的文件资源，路径存在则更新，路径不存在则创建。

---

4. HTTP报头

HTTP Header有很多种，这里总结几个比较重要的Header，具体内容可以参考文章：

HTTP响应头和请求头信息对照表

Header Key	解释	示例	适用于
Content-Type	正文内容的类型	Content-Type: text/html	请求、响应
Content-Length	正文内容的长度	Content-Length: 1024	请求、响应
Host	请求服务器的ip地址和端口号	Host: ip:port	请求
User-Agent	客户端信息（含OS、浏览器版本）	User-Agent: Mozilla/5.0 (Linux; X11)	请求
Cookie	用户状态信息	Cookie: sessionID=27	请求
Set-Cookie	设置用户状态信息	Set-Cookie: sessionID=27	响应
Location	搭配3XX状态码使用，告知客户端重定向地址	Location: /a/b/c.html	响应

HTTP Content-Type 对照表

有关Cookie的两个header，后面详细分析。

---

5. HTTP响应状态码

服务器返回到客户端的响应，必须包含状态码，告知用户请求处理完毕的结果。常见的我们日常会遇到的网页404 Not Found错误，404就是一种状态码。

⭕ 状态码大致大致有五个范围：

• 1XX：提供某种附加信息
• 2XX：请求成功
• 3XX：重定向
• 4XX：客户端错误
• 5XX：服务端异常

⭕ 常见的几个状态码及对应的状态描述：

状态码	状态描述	解释
200	OK	请求成功
301	Moved Permanently	永久重定向
302	Found	临时重定向
400	Bad Request	请求语法错误，服务器无法理解
403	Forbidden	服务器拒绝用户请求
404	Not Found	服务器无法根据请求找到资源
500	Internal Server Error	服务器内部错误，无法完成请求

⭕ 关于重定向

这里的重定向指的是：客户端接收到状态码为3XX的响应时，会重新定位新的资源，即发送新的请求。3XX状态码一般搭配报头Location使用，由Location指定新的URL。

301状态码是永久重定向，告知客户端请求资源已永久转移到另一个URL。客户端收到301响应后，会更新其书签、链接或缓存，以便下次请求时直接使用新的URL。对于搜索引擎来说，内部存储了大量的索引信息（关键词->URL），当访问某网站时收到301响应，则会修改搜索引擎内部的索引。

302状态码是临时重定向，告知客户端请求资源只是暂时转移到另一个URL，客户端收到302响应后并不会修改其缓存信息。临时重定向通常也被应用在一些需要做网页跳转的场景，如：用户登录、广告植入等等。

---

6. Cookie和Session

场景：当我们用浏览器登录一次b站后，接下来很长一段时间都不用重新登录了，每次访问b站都是直接用的。可这似乎和我们之前提及的http特性相悖：http不是无状态的吗？既然无状态，为什么登录一次之后，浏览器能“记住”我的登录信息呢？不应该是每次访问都要重新登录吗？

事实上，按照http“无状态”的特性来讲，确实每次访问都需要重新登录，可这会让用户的体验极差。因此，浏览器客户端使用了Cookie的概念，解决了这一问题。Cookie是一种维护用户状态和跟踪用户身份的机制，本质是一种保存在客户端（浏览器）的轻量级文本文件，当用户访问某个网站时，浏览器会将Cookie数据打包在请求中（以Header形式存在），发送给服务器。

为什么说Cookie能解决http无状态的问题，实现用户无需频繁重新登录的功能？下面模拟Cookie在用户两次访问b站期间的作用过程。

但是上面这种客户端直接发送Cookie的做法并不安全，因为传输过程中，黑客能够盗取用户的Cookie，获得用户的账号密码并进行非法操作。因此有了另外一种解决方案：Session。

Session会话是一种存储在服务器中的数据结构，用于存储和维护用户的状态信息。 每个用户登录后，服务器会为其创建一个新会话，以维护其状态信息。每个会话都有一个唯一的sessionID，客户端不再收取由服务器经处理确认后发回的原始Cookie信息，而是接收并保存由服务器为客户端创建的会话sessionID（sessionID同样保存在响应报头的Set-Cookie字段中）。

这样一来，由于客户端与服务器之间传递的是sessionID而不是原始状态信息，虽然无法保证sessionID不被中间人盗取，但是便于服务器更好地控制和保护会话数据（如检测到登录状态异常，自动删除session，要求重新登录），中间人盗取了sessionID也没用。

---

ENDING…