servlet的跳转有哪两种,servlet为什么要跳转

用户第一次请求服务器时，服务器根据用户提交的信息，创建对应的Session，请求返回时将此Session的唯一标识信息SessionID返回给浏览器，浏览器会将此SessionID信息存入Cookie中，同时Cookie记录此SessionID是属于哪个域名的。

当用户第二次访问服务器时，请求会自动判断此域名下是否存在Cookie信息，如果存在，则自动将Cookie信息也发送给服务器，服务器会从Cookie中获取SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到则说明用户没有登录或者登录失效，如果找到则证明用户已经登录可执行后面的操作。

分布式环境下 Session 该怎么处理呢？

分布式环境下，客户端请求经过负载均衡，可能会分配到不同的服务器上，假如一个用户的请求两次没有落到同一台服务器上，那么在新的服务器上就没有记录该用户状态对应的 Session。

可以使用 Redis 等分布式缓存来存储 Session，保证在多台服务器间共享。

客户端如果无法使用 Cookie 怎么办呢？

有可能客户端无法使用 Cookie，比如浏览器禁用 Cookie，或者客户端是 安卓、IOS 设备等。

这时候怎么办呢？SessionID 怎么存呢？怎么传给服务器呢？

首先是 SessionID 的存储，可以使用客户端的本地存储，比如浏览器的 sessionStorage。

接下来要怎么传呢？

1. 拼接到 URL：直接把 SessionID 作为 URL 的请求参数。
2. 放到请求头：把 SessionID 放到请求头里面，比较常用。

TCP 三次握手过程：

最开始，客户端和服务端都处于 CLOSE（关闭）状态，服务端监听客户端的请求，进入 LISTEN（监听） 状态。

客户端发送连接请求，进行第一次握手（同步位 SYN=1，序号字段 seq=x），发送完毕后，客户端就进入 SYN_SENT（同步已发送） 状态。

服务端确认连接，进行第二次握手（同步位 SYN=1，确认位 ACK=1，序号字段 seq=y，确认号字段 ack=x 1）， 发送完毕后，服务端就进入 SYN_RCV（同步已接收） 状态。

客户端收到服务端的确认后，再次向服务端确认，进行第三次握手（确认位 ACK=1，确认号字段 ack=y 1），发送完毕后，客户端就进入 ESTABLISHED（连接已建立） 状态，当服务端接收到这个包时，也进入 ESTABLISHED（连接已建立） 状态。

为什么不能是两次？

防止已失效的连接请求报文段突然又传到服务端，因而产生错误

• 客户端发送出去的第一个连接请求报文段并没有丢失，而是因为某些未知原因在某个网络节点上发生滞留，导致延迟到连接释放以后的某个时间点才到达服务端。
• 本来这是一个早已失效的报文段，但是服务端收到此失效的报文段后，会误认为这是客户端再次发起的一个新的连接请求，于是服务端向客户端又发出确认报文，表示同意建立连接。
• 如果不采用 “三次握手”，那么只要服务端发出确认报文后就会认为新的连接已经建立了，但是客户端并没有发出建立连接的请求，因此不会向服务端发送数据，服务端没有收到数据就会一直等待，这样服务端就会白白浪费掉很多资源。

所以我们需要 “第三次握手” 来确认这个过程：

• 通过第三次握手的数据来告诉服务端，客户端有没有收到服务端 “第二次握手” 时传过去的数据，以及这个连接的序号是不是有效的。
• 若发送的这个数据是 “收到且没有问题” 的信息，服务端接收后就可以正常建立 TCP 连接，否则建立 TCP 连接失败，服务器关闭连接端口。由此减少服务器开销和接收到失效请求时发生的错误。

为什么不是四次？

简单来说，就是三次握手已经足够创建可靠的连接，没有必要再多一次握手导致花费更多的时间在建立连接上。

第一次握手服务端未收到 SYN 报文

服务端不会进行任何的动作，而客户端由于一段时间内没有收到服务端发来的确认报文，等待一段时间后会重新发送 SYN 报文，

如果仍然没有回应，会重复这个过程，直到发送次数超过最大重传次数，就会返回连接建立失败。

第二次握手客户端未收到服务端响应的 ACK 报文

因为第二次握手是包含对客户端第一次握手的 ACK 确认报文，所以如果客户端迟迟没有收到第二次握手，那么客户端就会觉得可能是自己的 SYN 报文（第一次握手）丢失了，于是客户端就会触发超时重传机制，重传 SYN 报文。

然后，因为第二次握手是包含服务端的 SYN 报文，所以当客户端收到后，需要给服务端发送 ACK 确认报文（第三次握手），服务端才会认为该 SYN 报文被客户端收到了。

那么，如果第二次握手丢失了，服务端就收不到第三次握手，于是服务端这边会触发超时重传机制，重传 SYN-ACK 报文。

第三次握手服务端未收到客户端发送过来的 ACK 报文

客户端收到服务端的 SYN-ACK 报文后，就会给服务端发送一个 ACK 报文，也就是第三次握手，此时客户端进入到 ESTABLISH（连接已建立） 状态。

因为这个第三次握手的 ACK 是对第二次握手的 SYN 的确认报文，所以当第三次握手丢失了，如果服务端那一方迟迟收不到这个确认报文，就会触发超时重传机制，重传 SYN-ACK 报文，直到收到第三次握手，或者达到最大重传次数。

ACK 是为了告诉客户端传来的数据已经接收无误。

而传回 SYN 是为了告诉客户端，服务端响应的确实是客户端发送的报文。

第三次握手是可以携带数据的。

此时客户端已经处于连接已建立状态。对于客户端来说，它已经建立连接成功了，并且确认服务端的接收和发送能力是正常的。

第一次握手不能携带数据是出于安全的考虑，因为如果允许携带数据，攻击者每次在 SYN 报文中携带大量数据，就会导致服务端消耗更多的时间和空间去处理这些报文，会造成CPU和内存的消耗。