HTTP总结

最新推荐文章于 2024-10-03 17:52:13 发布

那时少年翩翩得不是一点点

最新推荐文章于 2024-10-03 17:52:13 发布

阅读量85

点赞数

文章标签： http

原文链接：https://github.com/sjsdfg/CS-Notes-PDF

版权

中国专业IT社区CSDN (Chinese Software Developer Network)

天天看CSDN，都不知道这几个字母代表的意思。

非原创，只是总结！原文跳转

1、基础

关于URI/URL/URN
在这里插入图片描述

请求和响应报文
请求报文：请求行和请求头构成请求消息头+空行+请求消息体
响应报文：状态码和响应头构成响应消息头+空行+响应消息体
1.请求报文

2、HTTP方法

客户端发送的请求行中包含了方法字段
GET

获取数据，网络中大多请求都是使用get

POST

传输实体主体，传输数据

HEAD

获取报文首部，主要用于确认URL的有效性，以及资源的更新时间

PUT：上传文件，任何人都能上传，不安全
PATCH：部分修改文件
DELETE：与put完全相反，删除文件
OPTIONS：查询支持的方法有哪些
CONNECT

要求在与代理服务器通信时建立隧道，使用SSL和TLS协议把通信内容加密后经网络隧道传输

TRACE：追踪路径会返回客户端，容易受到跨站攻击

3、HTTP状态码

在这里插入图片描述

4.HTTP首部

首部字段有四种：通用首部字段、请求首部字段、响应首部字段、实体首部字段

在这里插入图片描述
请求首部字段

响应首部字段

5.具体应用

连接管理

短连接：如果每次HTTP通信都哟啊新建一个TCP连接，开销太大。
长连接：一次TCP连接就能多次HTTP通信。HTTP/1.1开始默认是长连接
流水线：默认情况下，HTTP请求是按顺序发出的，每次请求需要响应完之后才能下一个请求。网络延迟和带宽限制，响应可能会很慢。流水线就是在同一个连接上连续请求，不需要等待响应，可以避免连接延迟。

Cookie

由于HTTP协议是无状态的，主要是为了让协议更加简单，使它能处理大量事务。1.1引入Cookie来保存状态信息。
Cookie是服务器发送到用户浏览器并保存在本地的一小块数据，你下次再访问这个网状的时候，请求资源就会携带这个Cookie数据，用来告诉服务端这个请求是否来自同一个浏览器，不过这样会需要更多的性能开销。
现在的话，cookie慢慢被淘汰。新的浏览器API已经允许开发者直接将数据存储到本地，如使用 Web storage API（本地存储和会话存储）或 IndexedDB。

用途
- 会话状态管理（如一些登录信息，购物车什么的）
- 个性化设置。浏览器设置等
- 浏览器行为跟踪，如跟踪分析用户行为等
创建过程
- 服务器发送的响应报文包含set-cookie首部字段，客户端得到响应报文后把cookie内容保存到浏览器中。
- 客户端之后对同一个服务器发送请求是，会从浏览器中取出cookie信息并通过cookie请求首部字段发送给服务器。
分类
- 会话期 Cookie：浏览器关闭之后它会被自动删除，也就是说它仅在会话期内有效。
- 持久性 Cookie：指定一个特定的过期时间（Expires）或有效期（max-age）之后就成为了持久性的 Cookie。
作用域

Domain标识指定了哪些主机可以接受Cookie，如果不指定，默认为当前文档的主机，不包含子域名，如果指定了Domain，则一般包含子域名。
path标识指定主机下的那些路径可以接受Cookie,该URL路径存在于请求URL中，以字符 %x2F ("/") 作为
路径分隔符，子路径也会被匹配。例如，设置 Path=/docs，则以下地址都会匹配：
/docs /docs/Web/ /docs/Web/HTTP

JavaScript

通过document.cookie属性可创建新的cookie，也可通过该属性访问非HTTPonly标记的cookie。

document.cookie = "yummy_cookie=choco";
 document.cookie = "tasty_cookie=strawberry";
  console.log(document.cookie);

HttpOnly

标记为 HttpOnly 的 Cookie 不能被 JavaScript 脚本调用。防止跨站脚本攻击 (XSS)
Secure

标记为 Secure 的 Cookie 只能通过被 HTTPS 协议加密过的请求发送给服务端。
Session

除了可以将用户信息通过cookie存储在用户浏览器中，还可以利用session存储在服务器端，存储在服务器端的信息更加的安全。session可以存储在服务器上的文件、数据库或者内存中，也可以将session存储在Redis这种内存型的数据库中，效率会更高。

使用 Session 维护用户登录状态的过程如下：
用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。
sessionID不能轻易获取，这个值不能太容易被猜到且需要经常重新生成新的值，重要操作时要重新验证用户信息。
浏览器禁止使用cookie
- 不能用cookie，那就使用session。不能再将 Session ID 存放到 Cookie 中，而是使
  用 URL 重写技术，将 Session ID 作为 URL 的参数进行传递。
Cookie与Session选择
- cookie只能存储ASCII码字符串，而session可以存储任何类型的数据，因此考虑数据复杂性时选择session。
- cookie存储于浏览器中，可能被查看，隐私数据存在cookie时需要加密，在服务器端解密
- 大型网站不建议将所有用户信息都存储在session中，开销太大。
缓存
- 优点
  缓解服务器压力；
  降低客户端获取资源的延迟：缓存通常位于内存中，读取缓存的速度更快。并且缓存在地理位置上也有可能比源服务器来得近，例如浏览器缓存。
- 实现方法
  让代理服务器进行缓存；
  让客户端浏览器进行缓存。
- Cache-Control
  HTTP/1.1 通过 Cache-Control 首部字段来控制缓存。
虚拟主机
HTTP/1.1 使用虚拟主机技术，使得一台服务器拥有多个域名，并且在逻辑上可以看成多个服务器。
通信数据转发