html/login.html，这是个URI，它 不能在网唯一标识。
http://localhost:8080/hello/html/login.html这个URI 可以在全网唯一标识，称为 URL。
HTTP（Hyper Text Transfer Protocol），超文本传输协议
-
是互联网中应用最广泛的应用层协议之一
-
设计HTTP最初的目的是：提供一种发布和接收HTML页面的方法，由URI来标识具体的资源
-
后面用HTTP来传递的数据格式不仅仅是HTML，应用非常广泛
HTML（ Hyper Text Markup Language）：超文本标记语言
- 用以编写网页
1991年，HTTP/0.9
- 只支持GET请求方法获取文本数据（比如HTML文档），且不支持请求头、响应头等，无法向服务器传递太多信息
1996年，HTTP/1.0
-
支持POST、HEAD等请求方法，支持请求头、响应头等，支持更多种数据类型（不再局限于文本数据）
-
浏览器的每次请求都需要与服务器建立一个TCP连接，请求处理完成后立即断开TCP连接
1997年，HTTP/1.1（最经典、使用最广泛的版本）
-
支持PUT、DELETE等请求方法
-
采用 持久连接（Connection: keep-alive），多个请求可以共用同一个TCP连接
2015年，HTTP/2.0
2018年，HTTP/3.0
HTTP的标准
- 由万维网协会（W3C）、互联网工程任务组（IETF）协调制定，最终发布了一系列的RFC
RFC（Request For Comments，可以译为：请求意见稿）
-
HTTP/1.1最早是在1997年的 RFC 2068 中记录的
该规范在1999年的 RFC 2616 中已作废
2014年又由 RFC 7230 系列的RFC取代
-
HTTP/2标准于2015年5月以 RFC 7540 正式发表，取代HTTP/1.1成为HTTP的实现标准
中国的RFC
- 1996年3月，清华大学提交的适应不同国家和地区中文编码的汉字统一传输标准被IETF通过为RFC 1922；成为中国大陆第一个被认可为RFC文件的提交协议
ABNF（Augmented BNF）
-
是 BNF（Backus-Naur Form，译为：巴科斯-瑙尔范式）的修改、增强版
-
在 RFC 5234 中表明：ABNF用作 internet 中通信协议的定义语言
-
ABNF是最严谨的HTTP报文格式描述形式，脱离ABNF谈论HTTP报文格式，往往都是不严谨的
关于HTTP报文格式的定义
ABNF核心规则
报文格式 - request-line、status -line
报文格式 - header-filed、message-body
URL中一旦出现了一些特殊字符（比如中文、空格），需要进行 编码
- 在浏览器地址栏输入URL时，是采用 UTF-8 进行编码
比如
-
编码前：
https://www.baidu.com/s?wd=百度 -
编码后：
https://www.baidu.com/s?wd=%E7%99%BE%E5%BA%A6
可通过 Java 将 “百度” 用 UTF-8 解码后转为16进制查看：
import java.nio.charset.StandardCharsets;
public class Main {
public static void main(String[] args) throws Exception {
byte[] bytes = "百度".getBytes(StandardCharsets.UTF_8);
for (byte b : bytes) {
System.out.print(Integer.toHexString(b & 0xFF) + " "); //保留低8位
}
}
}
e7 99 be e5 ba a6
[](https://gitee.com/vip204888/java-p7)Xshell + telnet 面向报文与服务器交互
---------------------------------------------------------------------------------------------
安装一个 Xshell（安全终端模拟软件），在 Xshell 中使用 `telnet`
* 可以直接面向HTTP报文与服务器交互
* 可以更清晰、直观地看到请求报文、响应报文的内容
* 可以检验请求报文格式的正确与否
`telnet` 命令可以理解为 **建立TCP连接**，然后我们可以 **直接输入报文** 来获取响应。
简单的 HTTP 报文格式：
GET /hello/ HTTP/1.1
Host: localhost:8080
[](https://gitee.com/vip204888/java-p7)请求方法（9种）
---------------------------------------------------------------------------
[RFC 7231, section 4: Request methods](https://gitee.com/vip204888/java-p7)：描述了 8 种请求方法
* GET、HEAD、POST、PUT、DELETE、CONNECT、OPTIONS、TRACE
[RFC 5789, section 2: Patch method](https://gitee.com/vip204888/java-p7)：描述了 PATCH 方法
GET：常用于**读取**的操作，**请求参数直接拼接在URL的后面**（浏览器对URL是有长度限制的）
POST：常用于**添加、修改、删除**的操作，**请求参数**可以放到**请求体**中（没有大小限制）
**HEAD**：请求得到与GET请求相同的响应，但没有响应体
使用场景：在下载一个大文件前，**先获取其大小(HEAD)**，再决定是否要**下载(GET)**。以此可以节约带宽资源。
> **GET 与 HEAD 请求的对比**
> 下面是 GET 请求的响应，**响应体里返回了 HTTP 文本**。
> 
> 下面是 HEAD 请求的响应，**比 GET 请求少了响应体**。
> 
**OPTIONS**：用于获取目的资源所支持的通信选项，比如 **服务器支持的请求方法**
* OPTIONS \* HTTP/1.1
* 通过向 Tomcat 发送 OPTIONS请求，可以知道它支持以下请求方法
**PUT**：用于对已存在的资源进行整体覆盖
**PATCH**：用于对资源进行部分修改（资源不存在，会创建新的资源）
**DELETE**：用于删除指定的资源
**TRACE**：请求服务器回显其收到的请求信息，主要用于**HTTP请求的测试或诊断**
**CONNECT**：可以开启一个客户端与所请求资源之间的双向沟通的通道，它可以用来创建隧道（tunnel）
* 可以用来访问采用了 SSL (HTTPS) 协议的站点
[](https://gitee.com/vip204888/java-p7)头部字段（Header Field）
-------------------------------------------------------------------------------------
[头部字段](https://gitee.com/vip204888/java-p7)可以分为4种类型
* **请求头字段（Request Header Fields）**
有关要获取的资源或客户端本身信息的消息头
* **响应头字段（Response Header Fields）**
有关响应的补充信息，比如服务器本身（名称和版本等）的消息头
* **实体头字段（Entity Header Fields）**
有关实体主体的更多信息，比如主体长度（Content-Length）或其MIME类型
* **通用头字段（General Header Fields）**
同时适用于请求和响应消息，但与消息主体无关的消息头
### [](https://gitee.com/vip204888/java-p7)请求头字段
Refer 可用于 **防盗链**
注意：q 值越大，表示优先级越高，如果不指定q值，默认是1.0（1.0是最大值）
### [](https://gitee.com/vip204888/java-p7)响应头字段
Content-Disposition 使用实例：
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/plain; charset=UTF8");
response.setHeader("Content-Disposition", "attachment; filename=\"lzy.txt\"");
response.getWriter().write("这是我的文件数据");
}
> Access-Control-Allow-Origin 用于允许跨域。
> 具体可以参考下面 **同源策略、跨域资源共享**。
[](https://gitee.com/vip204888/java-p7)状态码（Status Code）
-----------------------------------------------------------------------------------
在 [RFC 2616 10.Status Code Definitions](https://gitee.com/vip204888/java-p7) 规范中定义
* 状态码指示HTTP请求是否已成功完成
状态码可以分为5类
* 信息响应：100~199
* 成功响应：200~299
* 重定向：300~399
* 客户端错误：400~499
* 服务器错误 ：500~599
* * *
**常见状态码**
**100 Continue**
* 请求的初始部分已经被服务器收到，并且没有被服务器拒绝。客户端应该继续发送剩余的请求，如果请求已经完成，就忽略这个响应
* 允许客户端发送带请求体的请求前，判断服务器是否愿意接收请求（服务器通过请求头判断）
* 在某些情况下，如果服务器在不看请求体就拒绝请求时，客户端就发送请求体是不恰当的或低效的
**200 OK**：请求成功
**302 Found**：请求的资源被暂时的移动到了由Location头部指定的URL上
**304 Not Modified**：说明无需再次传输请求的内容，也就是说**可以使用缓存的内容**
**400 Bad Request**：由于语法无效，服务器无法理解该请求
**401 Unauthorized**：由于缺乏目标资源要求的身份验证凭证
**403 Forbidden**：服务器端有能力处理该请求，但是拒绝授权访问
**404 Not Found**：服务器端无法找到所请求的资源
**405 Method Not Allowed**：服务器禁止了使用当前HTTP方法的请求
**406 Not Acceptable**：服务器端无法提供与Accept-Charset以及Accept-Language指定的值相匹配的响应
**408 Request Timeout**：服务器想要将没有在使用的连接关闭
* 一些服务器会在空闲连接上发送此信息，即便是在客户端没有发送任何请求的情况下
**500 Internal Server Error**：所请求的服务器遇到意外的情况并阻止其执行请求
**501 Not Implemented**：请求的方法不被服务器支持，因此无法被处理
* 服务器必须支持的方法（即不会返回这个状态码的方法）只有 GET 和 HEAD
**502 Bad Gateway**：作为网关或代理角色的服务器，从上游服务器（如tomcat）中接收到的响应是无效的
**503 Service Unavailable**：服务器尚未处于可以接受请求的状态
* 通常造成这种情况的原因是由于服务器停机维护或者已超载
[](https://gitee.com/vip204888/java-p7)form 提交 - 常用属性、multipart/form-data
-----------------------------------------------------------------------------------------------------
**action**：请求的URI
**method**：请求方法（GET、POST）
**enctype**：POST请求时，请求体的编码方式
* application/x-www-form-urlencoded（默认值）
用&分隔参数，用=分隔键和值，字符用URL编码方式进行编码
* multipart/form-data
文件上传时必须使用这种编码方式
**multipart/form-data** 可参考 [RFC 1521](https://gitee.com/vip204888/java-p7)
[](https://gitee.com/vip204888/java-p7)同源策略、跨域资源共享
------------------------------------------------------------------------------
浏览器有个 **同源策略 (Same-Origin Policy)**
* 它规定了：默认情况下，AJAX请求只能发给同源的URL
* 同源是指3个相同：**协议、域名（IP）、端口**
* img、script、link、iframe、video、audio 等标签不受同源策略的约束
解决 AJAX跨域请求的常用方法
* **CORS (Cross-Origin Resource Sharing)，跨域资源共享**
CORS 的实现需要客户端和服务器同时支持
* 客户端
基本所有的浏览器都支持（IE至少是IE10版本）
* 服务器
需要返回相应的响应头（比如 Access-Control-Allow-Origin）
告知浏览器这是一个允许跨域的请求
> Access-Control-Allow-Origin 用于允许跨域。
> 
> 如果不设置允许跨域，则会出现下面情况：
> 
> 在返回响应时要设置允许跨域，即可跨域访问资源。
> 
> 设置跨域后，即可成功访问页面。
> 
[](https://gitee.com/vip204888/java-p7)Cookie、Session
---------------------------------------------------------------------------------
[](https://gitee.com/vip204888/java-p7)缓存（Cache）
----------------------------------------------------------------------------
详见补充内容
[](https://gitee.com/vip204888/java-p7)代理服务器（Proxy Server）
======================================================================================
特点
* **本身不生产内容**
* 处于中间位置转发上下游的请求和响应
面向下游的客户端：它是服务器
面向上游的服务器：它是客户端
[](https://gitee.com/vip204888/java-p7)正向代理、反向代理
----------------------------------------------------------------------------
**正向代理**：代理的对象是 **客户端**
# 完结
Redis**基于内存**，常用作于**缓存**的一种技术，并且Redis存储的方式是以key-value的形式。Redis是如今互联网技术架构中，使用最广泛的缓存，在工作中常常会使用到。Redis也是中高级后端工程师技术面试中，面试官最喜欢问的问题之一，因此作为Java开发者，Redis是我们必须要掌握的。
Redis 是 NoSQL 数据库领域的佼佼者，如果你需要了解 Redis 是如何实现高并发、海量数据存储的，那么这份腾讯专家手敲《Redis源码日志笔记》将会是你的最佳选择。
面向下游的客户端：它是服务器
面向上游的服务器：它是客户端
[](https://gitee.com/vip204888/java-p7)正向代理、反向代理
----------------------------------------------------------------------------
**正向代理**：代理的对象是 **客户端**
# 完结
Redis**基于内存**，常用作于**缓存**的一种技术，并且Redis存储的方式是以key-value的形式。Redis是如今互联网技术架构中，使用最广泛的缓存，在工作中常常会使用到。Redis也是中高级后端工程师技术面试中，面试官最喜欢问的问题之一，因此作为Java开发者，Redis是我们必须要掌握的。
Redis 是 NoSQL 数据库领域的佼佼者，如果你需要了解 Redis 是如何实现高并发、海量数据存储的，那么这份腾讯专家手敲《Redis源码日志笔记》将会是你的最佳选择。
[外链图片转存中...(img-ikq2GZYG-1628634748422)]
**感兴趣的朋友可以通过[点赞+戳这里的方式免费获取](https://gitee.com/vip204888/java-p7)腾讯专家手写Redis源码日志笔记pdf版本！**
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
