HTTP 临时重定向 307 Temporary Redirect

在 HTTP 协议中,临时重定向是一种常见的状态码,用于指示客户端请求的资源暂时被移到了另一个位置。其中,307 Temporary Redirect 状态码表示请求的资源临时移到了另一个位置,并且客户端应该继续使用原始的请求方法来访问新的位置。本文将介绍 307 Temporary Redirect 状态码的含义、用法以及一些相关的实际案例。

1. 307 Temporary Redirect 状态码的含义

307 Temporary Redirect 状态码表示请求的资源临时重定向到了另一个位置。与 302 Found 状态码不同的是,307 状态码要求客户端继续使用原始的请求方法(GET、POST、PUT 等)来访问新的位置。这意味着,如果原始请求是一个 POST 请求,那么客户端在收到 307 响应后应该继续以 POST 方法重新发送请求。

2. 307 Temporary Redirect 状态码的使用

307 Temporary Redirect 状态码通常用于以下情况:

  • 网站维护:当网站需要进行临时维护,并且某些资源暂时不可用时,可以使用 307 状态码将请求重定向到临时的维护页面。
  • 负载均衡:在负载均衡的场景下,服务器可能会将请求临时重定向到另一台服务器上,以实现资源的动态分配和负载均衡。

3. 示例

以下是一个示例场景,使用 307 Temporary Redirect 状态码进行临时重定向:

HTTP/1.1 307 Temporary Redirect
Location: https://example.com/new-location

在这个示例中,客户端收到 307 Temporary Redirect 响应后,应该继续使用原始的请求方法(如 GET 或 POST)来访问新的位置 https://example.com/new-location

4. 文献引用

以下是关于 307 Temporary Redirect 状态码的官方文档和参考资料:

  1. RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
  2. MDN Web Docs: HTTP 307 Temporary Redirect

这些资源提供了关于 307 Temporary Redirect 状态码的详细规范和解释,有助于更好地理解和使用该状态码。

通过了解 307 Temporary Redirect 状态码的含义和使用场景,我们可以更加灵活地应对临时重定向的需求,提高网站的可用性和用户体验。

TCP(Transmission Control Protocol):

  • TCP是一种可靠的、面向连接的传输层协议。
  • TCP提供数据传输的可靠性保证,通过序列号、确认应答、重传等机制来确保数据的可靠性和顺序性。
  • TCP适用于对数据传输可靠性要求较高的场景,如文件传输、电子邮件等。

UDP(User Datagram Protocol):

  • UDP是一种不可靠的、面向无连接的传输层协议。
  • UDP不提供数据传输的可靠性保证,数据包可能会丢失、乱序或重复。
  • UDP适用于对实时性要求较高、数据传输速度更重要的场景,如音视频传输、实时游戏等。

HTTP(Hypertext Transfer Protocol):

  • HTTP是基于TCP协议的应用层协议,用于在客户端和服务器之间传输超文本数据。
  • HTTP是一种无状态的请求-响应协议,每个请求和响应之间是相互独立的。
  • HTTP适用于传输网页、图片、文本等静态资源,以及进行简单的数据交互。

WebSocket:

  • WebSocket是一种全双工通信协议,建立在HTTP协议之上。
  • WebSocket允许客户端和服务器之间进行双向实时通信,相比于HTTP,减少了通信的延迟和网络流量。
  • WebSocket适用于实时性要求较高、双向通信的场景,如实时聊天、实时数据更新等。

区别:

  • TCP是面向连接的,提供可靠性保证;UDP是面向无连接的,不提供可靠性保证。
  • HTTP是基于TCP的应用层协议,用于传输超文本数据;WebSocket建立在HTTP之上,提供双向实时通信。
  • TCPUDP适用于不同的场景,TCP适用于对可靠性要求高的应用,UDP适用于实时性要求高的应用。
  • HTTP适用于传输静态资源和简单的数据交互,WebSocket适用于实时双向通信。

这个文章放在云笔记里面半年多了, 出现问题场景是我们从 aws 迁移至 阿里云 之后;
优化 api服务 发现有大量用户通过 X-Forwarded-For 仿造客户端IP 从而跨过我们后端对IP做的频率限制.

原理很简单 一般公司服务器都是 在服务最前端放 slb/lvs 这种负载均衡服务, 用户请求的IP 插入 X-Forwarded-For 前面

我们使用加速通道 多层的代理 ;

后端按照如下顺序获取客户端的真实IP

HTTP_ALI_CDN_REAL_IP;
HTTP_CF_CONNECTING_IP;
HTTP_X_CONNECTING_IP;
XXXX_Client_IP;
USER_REAL_IP; (通过nodejs 将用户的真实ip 透传给用户中心内网)

上述变量详解

HTTP_ALI_CDN_REAL_IP 链路配置了阿里云CDN,则阿里云CDN会传递此变量给后端,变量内的值就是客户端的真实IP地址。

HTTP_CF_CONNECTING_IP 如上,该值是cloudflare提供的客户端真实IP地址。

HTTP_X_CONNECTING_IP 如上,该值是加速乐提供的客户端真实IP地址。

XXXX_Client_IP 该值适用场景是SLB-->Nginx直连情况下,Nginx层启用了递归搜索。并且需要OP手动添加上层SLB的IP段为信任IP,通过判断X-Forwarded-For内最右侧的一个非信任IP值认定为客户端的真实IP地址并把此IP赋值给remote_addr,再由remote_addr赋值给XXXX_Client_IP。后端配置该配置前,请先跟OP确认上层是否配置。

XXXX_Client_IP 后端的应用服务(proxy_pass)赋值变量:

location / {
    ... ...
    proxy_set_header XXXX_Client_IP $remote_addr;
     ... ...
}

转发到后端的FastCGI服务(fastcgi_param)赋值变量:

location ~ \.php$ {
    ... ...
    fastcgi_param   XXXX_Client_IP  $remote_addr;
    ... ...
}

下面是客户端代理的IP 捕获文章 与 上文没有关系 ...

参考地址: https://www.cnblogs.com/rendd/p/6183094.html

1、没有代理服务器

  
HTTP_X_FORWARDED_FOR = 没数值或不显示 (X-Forwarded-For)
REMOTE_ADDR = 客户端IP

$ip = $_SERVER['REMOTE_ADDR'];

2、透明代理

REMOTE_ADDR = 最后一个代理服务器 IP
HTTP_X_FORWARDED_FOR = 客户端真实 IP (经过多个代理服务器时,这个值类似:221.5.252.160, 203.98.182.163, 203.129.72.215)

这类代理还会将客户真实ip发送到请求对象,无法隐藏真实ip

$ip = $_SERVER['HTTP_X_FORWARDED_FOR'];

三、使用普通匿名代理服务器,

REMOTE_ADDR = 最后一个代理服务器 IP
HTTP_X_FORWARDED_FOR = 代理服务器 IP (经过多个代理服务器时,这个值类似:203.98.182.163, 203.98.182.163, 203.129.72.215)

  这样就隐藏了客户端的真实ip,但服务器会知道客户端是通过代理服务器去访问的。

四、使用欺骗性代理服务器,

REMOTE_ADDR = 代理服务器 IP
HTTP_X_FORWARDED_FOR = 随机的 IP(经过多个代理服务器时,这个值类似:220.4.251.159, 203.98.182.163, 203.129.72.215)

  服务器可以识别到时通过代理服务器访问的,但发送给目标服务器的是虚假ip。

五、使用高匿名代理,

REMOTE_ADDR = 代理服务器 IP
HTTP_X_FORWARDED_FOR = 没数值或不显示

  使用这种代理时,不同浏览器不同设备会返回不同的ip头信息,因此PHP使用$_SERVER["REMOTE_ADDR"]$_SERVER["HTTP_X_FORWARDED_FOR"] 获取的值可能是空值也可能是“unknown”值。

上面 五类IP获取方式 总结下 前2种都是可以真实获取客户端IP 后面 3种方式 基本服务端是抓瞎的. 主要介绍的是纯客户端的捕捉ip 方式

一句话总结总结

通过 X-Forwarded-For 获取用户真实 IP 时,最好不要取第一个 IP,以防止用户伪造 IP

  • 第1 页/共1页

karp

创建我自己的巨人