26.0 Http协议

1. http协议简介

HTTP(Hypertext Transfer Protocol, 超文本传输协议): 
是万维网(WWW: World Wide Web)中用于在服务器与客户端(通常是本地浏览器)之间传输超文本的协议.

作为一个应用层的协议, HTTP以其简洁, 高效的特点, 在分布式超媒体信息系统中扮演着核心角色.
自1990年提出以来, HTTP经过多年的使用与发展, 已经得到了广泛的完善与扩展.

HTTP协议运行于客户端-服务端架构之上, 其中浏览器作为HTTP客户端,
通过URL(统一资源定位符)向HTTP服务端, 也就是Web服务器, 发送各种请求.
Web服务器在接收到这些请求后, 会根据请求的内容和处理逻辑, 向客户端发送相应的响应信息.
这些信息通常包括HTML页面, 图片, 视频等多媒体内容, 以及用于控制页面行为的JavaScript脚本等.

通过HTTP协议, 用户可以方便地从Web服务器上获取所需的信息, 并享受到丰富的网络资源和服务.
同时, HTTP协议也为Web应用提供了基础的通信机制, 使得各种Web技术(如HTML, CSS, JavaScript等)能够协同工作,
共同构建出功能强大的Web应用程序.

HTTP协议从最初到现在, 一共经历了五个主要版本, 分别是: 
* 1. HTTP/0.9: 这是HTTP协议的最早版本, 于1991年发布.
     这个版本极其简单, 只支持GET请求方式, 并且没有请求头的概念, 服务端在响应之后立即关闭TCP连接.
* 2. HTTP/1.0: 在1996年5月发布, 这个版本在HTTP/0.9的基础上进行了大量的扩展.
     它新增了POST, DELETE, PUT, HEADER等请求方式, 并引入了请求头和响应头的概念, 
     使得HTTP协议能够传输更多的信息, 包括状态码, 权限, 缓存, 内容编码等.
     此外, 这个版本还扩充了传输内容格式, 使得图片, 音视频资源, 二进制等都可以进行传输.
* 3. HTTP/1.1: 这是目前最为主流的HTTP协议版本, 从1997年发布至今仍然是主流的http协议版本.
     HTTP/1.1在HTTP/1.0的基础上进行了多项改进, 引入了持久连接(persistent connection)和管道机制(pipelining),
     使得多个请求可以复用同一个TCP连接, 提高了传输效率.
* 4. HTTP/2.0: HTTP/2.0是HTTP协议的第二个主要版本, 它在HTTP/1.1的基础上进行了大幅度的优化.
     HTTP/2.0引入了二进制分帧层, 允许将不同的HTTP交换多路复用到同一个TCP连接上,
     同时支持服务器推送(server push)和头部压缩(header compression)等特性, 进一步提高了传输效率.
* 5. HTTP/3.0: HTTP/3.0是HTTP协议的第三个主要版本, 于2022年6月6日正式发布.
     这个版本最大的提升在于效率, 它替换了HTTP/2.0中的TCP协议为QUIC协议(基于UDP协议), 具有更低的延迟和更高的效率.

综上所述, HTTP协议一共有五个版本, 分别是:  HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2.0和HTTP/3.0.
每个版本都在前一个版本的基础上进行了改进和优化, 以适应互联网的发展需求.

2. http协议特性

HTTP协议特性: 
* 1. 基于TCP/IP协议之上的应用层协议: HTTP协议是建立在TCP/IP协议之上的应用层协议.
     它利用TCP/IP协议提供的可靠传输服务, 确保HTTP请求和响应数据在客户端和服务器之间能够准确, 完整地传输.

* 2. 基于请求-响应模式: HTTP协议采用请求-响应模式进行通信.
     这意味着通信的发起总是由客户端开始, 客户端向服务器发送HTTP请求, 服务器在接收到请求后,
     根据请求的内容生成相应的HTTP响应并返回给客户端.
     在整个通信过程中, 总是先由客户端发起请求, 服务器再进行响应.

* 3. 无状态性: HTTP协议是无状态的(stateless).
     这意味着协议本身不对请求和响应之间的通信状态进行持久保存.
     每次HTTP请求都是独立的, 服务器不会记住之前客户端发送的请求或响应的信息.
     这种无状态性使得HTTP协议能够处理大量的并发请求, 提高了系统的可伸缩性和性能.
     然而, 这也给一些需要保持用户状态的应用带来了挑战.
     为了解决这个问题, HTTP协议引入了Cookie等技术来在客户端和服务器之间传递状态信息.

* 4. 无连接性: HTTP协议具有无连接性(connectionless).
     这意味着每次HTTP请求和响应都需要通过TCP建立一个新的连接, 并在完成数据传输后断开连接.
     这种无连接性可以减少不必要的连接开销, 提高网络资源的利用率.
     然而, 对于需要频繁通信的应用来说, 频繁地建立和断开连接可能会带来额外的开销.
     为了解决这个问题, HTTP/1.1引入了持久连接(persistent connection)的概念,
     允许在一个TCP连接上发送多个HTTP请求和响应, 从而减少了建立和断开连接的次数.

3. 请求协议与响应协议

HTTP协议中的请求协议和响应协议是构成HTTP通信的两个基本组成部分.
这两个协议分别定义了客户端(如Web浏览器)如何向服务器发送请求, 以及服务器如何响应这些请求.

* 1. 由浏览器(客户端)发送数据到服务器时需要遵循的请求协议(Request Protocol).
* 2. 服务器发送数据到浏览器时需要遵循的响应协议(Response Protocol).

3.1 报文格式

一个HTTP请求(也称为请求报文)通常包含以下几个部分: 
* 1. 请求行(Request Line): 
     请求方法(HTTP Method): 如GET, POST, PUT, DELETE等, 用于指定请求的类型.
     请求URL(Request URL): 指定了请求的资源位置.
     HTTP协议版本(HTTP Version): 如HTTP/1.1或HTTP/2.0.
* 2. 请求头(Request Headers): 
     包含了一系列描述请求的元信息, 如请求来源(User-Agent), 请求内容类型(Content-Type), 内容长度(Content-Length)等.
* 3. 请求体(Request Body):  对于某些请求方法(如POST和PUT), 请求体包含了要发送到服务器的数据.
     数据格式通常可以是表单数据, JSON, XML等.

一个HTTP响应(也称为响应报文)通常包含以下几个部分: 
* 1. 状态行(Status Line): 
     HTTP协议版本(HTTP Version): 如HTTP/1.1或HTTP/2.0.
     状态码(Status Code): 一个三位数的数字, 用于表示响应的状态. 常见的状态码包括200(OK), 404(Not Found)等.
     状态描述(Reason Phrase): 对状态码的文本描述, 如"OK"或"Not Found".
* 2. 响应头(Response Headers): 包含了一系列描述响应的元信息, 
     如内容类型(Content-Type), 内容长度(Content-Length), 响应时间(Date)等.
* 3. 响应体(Response Body): 包含了服务器返回给客户端的数据.
     数据格式取决于响应头中的Content-Type字段, 可以是HTML, 图片, JSON, XML等.
     
这些报文在HTTP通信中起着至关重要的作用, 它们确保了客户端和服务器之间能够正确地进行数据交换和通信.
通过遵循HTTP协议的规定, 不同的客户端和服务器能够相互理解和处理对方的请求和响应, 从而实现各种Web应用的功能.

工作流程:
* 1. 客户端(如Web浏览器)根据用户的操作或程序的指令, 构建HTTP请求.
* 2. 客户端将HTTP请求发送到服务器.
* 3. 服务器接收到HTTP请求后, 解析请求并处理.
* 4. 服务器根据请求的内容和处理结果, 构建HTTP响应.
* 5. 服务器将HTTP响应发送回客户端.
* 6. 客户端接收到HTTP响应后, 解析响应并展示给用户或供程序使用.
* 7. 通过这种请求-响应模式, HTTP协议实现了客户端和服务器之间的通信和数据交换.

3.2 请求方法

HTTP请求方法(也称为HTTP动词或HTTP操作)定义了客户端如何与服务器进行交互.
以下是HTTP/1.1规范中定义的一些主要的HTTP请求方法:
* 1. GET: 用于请求指定的资源. 请求没有请求体.
     常见的用途包括: 请求HTML页面, 请求图片或其他类型的文件.
     通常GET请求是幂等的, 即多次执行相同的GET请求不会对资源产生副作用.
* 2. POST: 用于向指定资源提交数据, 请求通常包含请求体(例如表单数据, JSON等).
     常见的用途包括: 提交表单数据, 上传文件, 创建新的资源.
     POST请求通常不是幂等的, 即每次执行POST请求可能会产生不同的结果(例如, 多次提交相同的表单数据可能会创建多个资源).
     (通过设计可以使POST请求具有幂等性.)
* 3. PUT: 用于将请求的数据发送到指定的资源, 并替换该资源的当前表示形式(如果资源不存在, 则可能会创建它).
     PUT请求是幂等的, 即多次执行相同的PUT请求将产生相同的结果.
* 4. DELETE: 用于请求服务器删除指定的资源.
     DELETE请求也是幂等的.
* 5. HEAD: 与GET请求类似, 但服务器仅返回响应头, 而不返回实际的数据内容.
     通常用于检查资源的存在性, 类型, 大小等元信息.
* 6. OPTIONS: 用于获取目标资源所支持的通信选项.
     常用于CORS(跨源资源共享)预检请求.
* 7. TRACE: 用于沿着到目标资源的路径执行一个消息环回测试.
     通常用于诊断或测试.
* 8. CONNECT: 通常用于SSL加密隧道的建立.
     CONNECT请求由代理用于将TCP连接转变为安全的SSL连接.
* 9. PATCH(HTTP/1.1之后的扩展): 用于对资源应用部分修改.
     与PUT请求不同, PATCH请求只更新资源的部分内容, 而不是替换整个资源.

在实际应用中, GET, POST, PUT和DELETE是最常用的HTTP请求方法.
其他方法(如HEAD, OPTIONS, TRACE和CONNECT)在特定场景下可能会很有用, 但不如前四个方法那么常见.

GET, POST, PUT和DELETE方法的详细解释:
* 1. GET 方法.
     数据位置: GET方法提交的数据会附加在URL的查询字符串(query string)中, 位于URL的'?'之后.
     例如: 如www.Book.com:8000/login/?name=kid&pwd=123456
     数据大小限制: 由于浏览器和服务器对URL长度都有限制(尽管这个限制可能因浏览器和服务器而异, 但通常都较短),
     所以GET方法提交的数据量有限.
     安全性: 由于GET请求的数据都暴露在URL中, 因此不适合传输敏感信息(如密码).
     此外, GET请求可以被缓存和书签化, 这也可能带来安全隐患.
     服务端获取数据方式: 服务端通过解析URL中的查询字符串来获取GET请求传递的数据.
     如果请求的资源存在并被成功获取, 服务器应该返回200 OK状态码, 并附带响应体(如HTML页面, JSON数据等).
     如果请求的资源不存在, 服务器应该返回404 Not Found状态码, 并可能附带一个描述性的错误消息作为响应体.
     如果服务器内部发生错误, 无法处理请求, 服务器会返回500 Internal Server Error状态码.

* 2. POST 方法.
     数据位置: POST方法提交的数据放在HTTP请求的消息体中(request body).
     数据大小限制: POST方法提交的数据量没有GET方法那样的URL长度限制, 因此可以传输大量数据.
     但是, 仍然受到HTTP协议本身和服务器配置的限制.
     安全性: POST请求的数据在请求体中, 不会暴露在URL中, 因此比GET请求更适合传输敏感信息.
     此外, POST请求不会被浏览器缓存或书签化.
     服务端获取数据方式: 服务端通过解析请求体来获取POST请求传递的数据.
     这通常需要使用特定的内容类型(如application/x-www-form-urlencoded,
     multipart/form-data或application/json)来解析请求体中的数据.
     如果资源被成功创建或更新, 服务器应该返回201 Created状态码(当创建新资源时)或200 OK状态码(当更新现有资源时).
     响应体可能包含新创建或更新的资源的表示.
     
* 3. PUT 方法.
     数据位置: 与POST类似, PUT请求的数据也通常放在HTTP请求的消息体中(request body).
     安全性: 与POST一样, PUT请求的数据不会暴露在URL中, 因此相对更安全.
     但是, PUT请求仍然可以被缓存, 因此同样需要小心处理敏感数据.
     服务端获取数据方式: 服务器应该根据请求URI(Uniform Resource Identifier)定位到特定的资源, 
     并使用请求体中的数据替换该资源的当前表示.
     如果请求成功, 服务器应该返回200(OK)或201(Created)状态码.

* 4. DELETE 方法.
     数据位置: DELETE请求通常不包含请求体, 只需要通过URI指定要删除的资源即可.
     安全性: DELETE请求不会暴露敏感数据, 因为它不包含请求体. 
     但是, 它仍然需要谨慎处理, 因为错误的DELETE请求可能会导致数据丢失.
     服务端获取数据方式: 服务器应该根据请求URI定位到特定的资源, 并删除它.
     如果请求成功, 服务器应该返回200(OK)或204(No Content)状态码.
     如果资源不存在, 服务器可能会返回404(Not Found)状态码.

3.3 响应状态码

状态码(Status Code)在HTTP协议中扮演着非常重要的角色, 
它们是服务器在响应客户端的请求时发送的简短代码, 用于告知客户端请求的结果.

状态码由三位数字和一个与之关联的原因短语(Reason Phrase)组成.
虽然原因短语对于人类来说是可读的, 但实际的响应处理主要是基于三位数字的状态码.

HTTP状态码的第一位数字定义了响应的类别, 主要有五种.

3.3.1 信息性状态码

信息性状态码: 接收的请求正在处理.
由于HTTP/1.0协议中没有定义任何1xx状态码, 因此HTTP/1.1版本的这类状态码变得可有可无.

3.3.2 成功状态码

成功状态码: 请求已成功被服务器接收, 理解, 并接受.
最常见的状态码是200 OK, 表示一切正常.

3.3.3 重定向状态码

重定向状态码: 需要采取进一步的操作以完成请求.
例如, 301 Moved Permanently(永久重定向)表示请求的资源已被永久移动到由Location头部指定的URL.

3.3.4 客户端错误状态码

客户端错误状态码: 请求包含错误语法或无法完成请求.
例如, 404 Not Found (未找到)表示服务器上无法找到请求的资源.

3.3.5 服务器错误状态码

服务器错误状态码: 服务器在处理请求时发生了错误.
例如, 500 Internal Server Error (内部服务器错误) 表示服务器遇到了一个未曾预料的情况, 导致其无法完成对请求的处理.

4. URL统一资源定位符

URL(Uniform Resource Locator), 统一资源定位符, 是用于定位和访问互联网上资源的地址.
以下是关于URL的详细简介:
* 1. 定义与作用: URL是用于标识和定位互联网上的资源, 如网页, 文档, 图像, 视频等.
     它通过特定的语法规则, 将互联网上的资源地址统一编址, 使得用户可以方便地通过浏览器或其他工具访问这些资源.
* 2. 组成结构: URL通常包含以下几个部分,
     以'https://www.example.com:8080/path/to/resource?param1=value1&param2=value2#section3'为例, 进行说明.
     协议(Protocol): 表示访问资源所使用的协议, 如'https'.
     主机名(Host): 表示资源所在的主机或服务器的域名或IP地址, 如'http://www.example.com'.
     端口(Port): 表示服务器监听的端口号, 如果省略则使用默认端口, 如'8080'.
     路径(Path): 表示资源在服务器上的路径或位置, 如'/path/to/resource'.
     查询参数(Query): 表示向服务器传递的参数, 通常以键值对的形式出现, 用'?'开始, 如'param1=value1&param2=value2'.
     片段标识符(Fragment): 用于标识资源中的特定片段, 通常以'#'开始, 如'#section3'.
* 3. 特点与功能.
     URL是互联网上资源的唯一标识, 通过它可以准确地找到并访问所需资源.
     URL具有全球唯一性和可访问性, 使得互联网上的资源能够被全球范围内的用户所共享和访问.
     URL的组成结构清晰明了, 易于理解和使用, 同时也方便进行编程和自动化处理.
* 4. 应用场景.
     在Web开发中, URL常常用于指定网页, API等的地址, 使得开发者能够方便地构建和部署Web应用程序.
     在搜索引擎中, URL是搜索引擎爬虫获取和索引网页的重要依据, 对于网站的可见性和排名具有重要影响.
     在日常生活中, 我们通过各种设备(如手机, 电脑等)上的浏览器或其他应用程序访问URL, 从而获取和浏览互联网上的信息和服务.

总之, URL作为互联网上资源的唯一标识和访问方式, 在现代社会中发挥着至关重要的作用.
通过了解URL的组成结构, 特点与功能以及应用场景等方面的知识, 我们可以更好地理解和使用URL, 从而更好地利用互联网资源和服务.