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版本的这类状态码变得可有可无.

消息	描述
100 Continue	服务器仅接收到部分请求, 但是一旦服务器并没有拒绝该请求, 客户端应该继续发送其余的请求.
101 Switching Protocols	服务器转换协议: 服务器将遵从客户的请求转换到另外一种协议.

3.3.2 成功状态码

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

消息	描述
200 OK	请求成功(其后是对GET和POST请求的应答文档.)
201 Created	请求被创建完成, 同时新的资源被创建.
202 Accepted	供处理的请求已被接受, 但是处理未完成.
203 Non-authoritative Information	文档已经正常地返回, 但一些应答头可能不正确, 因为使用的是文档的拷贝.
204 No Content	没有新文档. 浏览器应该继续显示原来的文档. 如果用户定期地刷新页面, 而Servlet可以确定用户文档足够新, 这个状态代码是很有用的.
205 Reset Content	没有新文档. 但浏览器应该重置它所显示的内容. 用来强制浏览器清除表单输入内容.
206 Partial Content	客户发送了一个带有Range头的GET请求, 服务器完成了它.

3.3.3 重定向状态码

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

消息	描述
300 Multiple Choices	多重选择.链接列表.用户可以选择某链接到达目的地.最多允许五个地址.
301 Moved Permanently	所请求的页面已经转移至新的url.
302 Found	所请求的页面已经临时转移至新的url.
303 See Other	所请求的页面可在别的url下被找到.
304 Not Modified	未按预期修改文档. 客户端有缓冲的文档并发出了一个条件性的请求(一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档). 服务器告诉客户, 原来缓冲的文档还可以继续使用.
305 Use Proxy	客户请求的文档应该通过Location头所指明的代理服务器提取.
306 Unused	此代码被用于前一版本. 目前已不再使用, 但是代码依然被保留.
307 Temporary Redirect	被请求的页面已经临时移至新的url.

3.3.4 客户端错误状态码

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

消息	描述
400 Bad Request	服务器未能理解请求.
401 Unauthorized	被请求的页面需要用户名和密码.
401.1	登录失败.
401.2	服务器配置导致登录失败.
401.3	由于ACL对资源的限制而未获得授权.
401.4	筛选器授权失败.
401.5	ISAPI/CGI应用程序授权失败.
401.7	访问被Web服务器上的URL授权策略拒绝. 这个错误代码为IIS 6.0所专用.
402 Payment Required	此代码尚无法使用.
403 Forbidden	对被请求页面的访问被禁止.
403.1	执行访问被禁止.
403.2	读访问被禁止.
403.3	写访问被禁止.
403.4	要求SSL.
403.5	要求SSL 128.
403.6	IP地址被拒绝.
403.7	要求客户端证书.
403.8	站点访问被拒绝.
403.9	用户数过多.
403.10	配置无效.
403.11	密码更改.
403.12	拒绝访问映射表.
403.13	客户端证书被吊销.
403.14	拒绝目录列表.
403.15	超出客户端访问许可.
403.16	客户端证书不受信任或无效.
403.17	客户端证书已过期或尚未生效.
403.18	在当前的应用程序池中不能执行所请求的URL. 这个错误代码为IIS 6.0所专用.
403.19	不能为这个应用程序池中的客户端执行CGI. 这个错误代码为IIS 6.0所专用.
403.20	Passport登录失败. 这个错误代码为IIS 6.0所专用.
404 Not Found	服务器无法找到被请求的页面.
404.0	(无)--没有找到文件或目录.
404.1	无法在所请求的端口上访问Web站点.
404.2	Web服务扩展锁定策略阻止本请求.
404.3	MIME映射策略阻止本请求.
405 Method Not Allowed	请求中指定的方法不被允许.
406 Not Acceptable	服务器生成的响应无法被客户端所接受.
407 Proxy Authentication Required	用户必须首先使用代理服务器进行验证, 这样请求才会被处理.
408 Request Timeout	请求超出了服务器的等待时间.
409 Conflict	由于冲突，请求无法被完成.
410 Gone	被请求的页面不可用.
411 Length Required	"Content-Length"未被定义. 如果无此内容，服务器不会接受请求.
412 Precondition Failed	请求中的前提条件被服务器评估为失败.
413 Request Entity Too Large	由于所请求的实体的太大, 服务器不会接受请求.
414 Request-url Too Long	由于url太长, 服务器不会接受请求. 当post请求被转换为带有很长的查询信息的get请求时, 就会发生这种情况.
415 Unsupported Media Type	由于媒介类型不被支持, 服务器不会接受请求.
416 Requested Range Not Satisfiable	服务器不能满足客户在请求中指定的Range头.
417 Expectation Failed	执行失败.
423	锁定的错误.

3.3.5 服务器错误状态码

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

消息	描述
500 Internal Server Error	请求未完成.服务器遇到不可预知的情况.
500.12	应用程序正忙于在Web服务器上重新启动.
500.13	Web服务器太忙.
500.15	不允许直接请求Global.asa.
500.16	UNC授权凭据不正确.这个错误代码为IIS 6.0所专用.
500.18	URL授权存储不能打开.这个错误代码为IIS 6.0所专用.
500.100	内部ASP错误.
501 Not Implemented	请求未完成.服务器不支持所请求的功能.
502 Bad Gateway	请求未完成.服务器从上游服务器收到一个无效的响应.
502.1	CGI应用程序超时.
502.2	CGI应用程序出错.
503 Service Unavailable	请求未完成.服务器临时过载或宕机.
504 Gateway Timeout	网关超时.
505 HTTP Version Not Supported	服务器不支持请求中指明的HTTP版本.

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, 从而更好地利用互联网资源和服务.