杂乱

ZooKeeper是用来配置和支持分布式调度的一组工具。（重要功能：对所有节点进行配置的同步。）
ZooKeeper是Hadoop的分布式协调服务，ZooKeeper是Hadoop生态系统的一部分，
ZooKeeper可用于实现很多数据结构和协议，如分布式队列，分布式锁，同一级中的领导者选举；

nio
一、IO流（同步、阻塞）交互方式
二、NIO（同步、非阻塞）
三、NIO2(异步、非阻塞)aio
同步与异步（synchronous/asynchronous）：同步是一种可靠的有序运行机制，当我们进行同步操作时，后续的任务是等待当前调用返回，才会进行下一步；而异步则相反，其他任务不需要等待当前调用返回，通常依靠事件、回调等机制来实现任务间次序关系
阻塞与非阻塞：在进行阻塞操作时，当前线程会处于阻塞状态，无法从事其他任务，只有当条件就绪才能继续，比如ServerSocket新连接建立完毕，或者数据读取、写入操作完成；而非阻塞则是不管IO操作是否结束，直接返回，相应操作在后台继续处理
同步和异步的概念：实际的I/O操作

同步是用户线程发起I/O请求后需要等待或者轮询内核I/O操作完成后才能继续执行

异步是用户线程发起I/O请求后仍需要继续执行，当内核I/O操作完成后会通知用户线程，或者调用用户线程注册的回调函数

阻塞和非阻塞的概念：发起I/O请求

阻塞是指I/O操作需要彻底完成后才能返回用户空间

非阻塞是指I/O操作被调用后立即返回一个状态值，无需等I/O操作彻底完成
首先，传统的 java.io包，它基于流模型实现，提供了我们最熟知的一些 IO 功能，比如 File 抽象、输入输出流等。交互方式是同步、阻塞的方式，也就是说，在读取输入流或者写入输出流时，在读、写动作完成之前，线程会一直阻塞在那里，它们之间的调用是可靠的线性顺序。

java.io包的好处是代码比较简单、直观，缺点则是 IO 效率和扩展性存在局限性，容易成为应用性能的瓶颈。

很多时候，人们也把 java.net下面提供的部分网络 API，比如 Socket、ServerSocket、HttpURLConnection 也归类到同步阻塞 IO 类库，因为网络通信同样是 IO 行为。
IO流、分类
按操作数据分为：字节流（Reader、Writer）和字符流（InputStream、OutputStream）

按流向分：输入流（Reader、InputStream）和输出流（Writer、OutputStream）
3、字符流
概述

只用来处理文本数据

数据最常见的表现形式是文件，字符流用来操作文件的子类一般是FileReader和FileWriter

字符流读写文件注意事项：

写入文件必须要用flush()刷新
用完流记得要关闭流
使用流对象要抛出IO异常
定义文件路径时，可以用"/“或者”"
在创建一个文件时，如果目录下有同名文件将被覆盖
在读取文件时，必须保证该文件已存在，否则抛出异常
字符流的缓冲区

缓冲区的出现是为了提高流的操作效率而出现的
需要被提高效率的流作为参数传递给缓冲区的构造函数
在缓冲区中封装了一个数组，存入数据后一次取出
4、字节流
概述

用来处理媒体数据

字节流读写文件注意事项：

字节流和字符流的基本操作是相同的，但是想要操作媒体流就需要用到字节流
字节流因为操作的是字节，所以可以用来操作媒体文件（媒体文件也是以字节存储的）
输入流（InputStream）、输出流（OutputStream）
字节流操作可以不用刷新流操作
InputStream特有方法：int available()（返回文件中的字节个数）
字节流的缓冲区
字节流缓冲区跟字符流缓冲区一样，也是为了提高效率

二、NIO（同步、非阻塞）
NIO之所以是同步，是因为它的accept/read/write方法的内核I/O操作都会阻塞当前线程

首先，我们要先了解一下NIO的三个主要组成部分：Channel（通道）、Buffer（缓冲区）、Selector（选择器）
（1）Channel（通道）
Channel（通道）：Channel是一个对象，可以通过它读取和写入数据。可以把它看做是IO中的流，不同的是：

Channel是双向的，既可以读又可以写，而流是单向的
Channel可以进行异步的读写
对Channel的读写必须通过buffer对象
正如上面提到的，所有数据都通过Buffer对象处理，所以，您永远不会将字节直接写入到Channel中，相反，您是将数据写入到Buffer中；同样，您也不会从Channel中读取字节，而是将数据从Channel读入Buffer，再从Buffer获取这个字节。
因为Channel是双向的，所以Channel可以比流更好地反映出底层操作系统的真实情况。特别是在Unix模型中，底层操作系统通常都是双向的。
在Java NIO中的Channel主要有如下几种类型：

FileChannel：从文件读取数据的
DatagramChannel：读写UDP网络协议数据
SocketChannel：读写TCP网络协议数据
ServerSocketChannel：可以监听TCP连接
（2）Buffer
Buffer是一个对象，它包含一些要写入或者读到Stream对象的。应用程序不能直接对 Channel 进行读写操作，而必须通过 Buffer 来进行，即 Channel 是通过 Buffer 来读写数据的。

在NIO中，所有的数据都是用Buffer处理的，它是NIO读写数据的中转池。Buffer实质上是一个数组，通常是一个字节数据，但也可以是其他类型的数组。但一个缓冲区不仅仅是一个数组，重要的是它提供了对数据的结构化访问，而且还可以跟踪系统的读写进程。

使用 Buffer 读写数据一般遵循以下四个步骤：

1.写入数据到 Buffer；

2.调用 flip() 方法；

3.从 Buffer 中读取数据；

4.调用 clear() 方法或者 compact() 方法。

当向 Buffer 写入数据时，Buffer 会记录下写了多少数据。一旦要读取数据，需要通过 flip() 方法将 Buffer 从写模式切换到读模式。在读模式下，可以读取之前写入到 Buffer 的所有数据。

一旦读完了所有的数据，就需要清空缓冲区，让它可以再次被写入。有两种方式能清空缓冲区：调用 clear() 或 compact() 方法。clear() 方法会清空整个缓冲区。compact() 方法只会清除已经读过的数据。任何未读的数据都被移到缓冲区的起始处，新写入的数据将放到缓冲区未读数据的后面。

Buffer主要有如下几种：

ByteBuffer
CharBuffer
DoubleBuffer
FloatBuffer
IntBuffer
LongBuffer
ShortBuffer
copyFile实例（NIO）

CopyFile是一个非常好的读写结合的例子，我们将通过CopyFile这个实力让大家体会NIO的操作过程。CopyFile执行三个基本的操作：创建一个Buffer，然后从源文件读取数据到缓冲区，然后再将缓冲区写入目标文件。

public static void copyFileUseNIO(String src,String dst) throws IOException{
//声明源文件和目标文件
FileInputStream fi=new FileInputStream(new File(src));
FileOutputStream fo=new FileOutputStream(new File(dst));
//获得传输通道channel
FileChannel inChannel=fi.getChannel();
FileChannel outChannel=fo.getChannel();
//获得容器buffer
ByteBuffer buffer=ByteBuffer.allocate(1024);
while(true){
//判断是否读完文件
int eof =inChannel.read(buffer);
if(eof==-1){
break;
}
//重设一下buffer的position=0，limit=position
buffer.flip();
//开始写
outChannel.write(buffer);
//写完要重置buffer，重设position=0,limit=capacity
buffer.clear();
}
inChannel.close();
outChannel.close();
fi.close();
fo.close();
}
（三）Selector（选择器对象）
首先需要了解一件事情就是线程上下文切换开销会在高并发时变得很明显，这是同步阻塞方式的低扩展性劣势。

Selector是一个对象，它可以注册到很多个Channel上，监听各个Channel上发生的事件，并且能够根据事件情况决定Channel读写。这样，通过一个线程管理多个Channel，就可以处理大量网络连接了。

selector优点

有了Selector，我们就可以利用一个线程来处理所有的channels。线程之间的切换对操作系统来说代价是很高的，并且每个线程也会占用一定的系统资源。所以，对系统来说使用的线程越少越好。

1.如何创建一个Selector

Selector 就是您注册对各种 I/O 事件兴趣的地方，而且当那些事件发生时，就是这个对象告诉您所发生的事件。

Selector selector = Selector.open();
2.注册Channel到Selector

为了能让Channel和Selector配合使用，我们需要把Channel注册到Selector上。通过调用 channel.register（）方法来实现注册：

channel.configureBlocking(false);
SelectionKey key =channel.register(selector,SelectionKey.OP_READ);
注意，注册的Channel 必须设置成异步模式 才可以,否则异步IO就无法工作，这就意味着我们不能把一个FileChannel注册到Selector，因为FileChannel没有异步模式，但是网络编程中的SocketChannel是可以的。

3.关于SelectionKey

请注意对register()的调用的返回值是一个SelectionKey。 SelectionKey 代表这个通道在此 Selector 上注册。当某个 Selector 通知您某个传入事件时，它是通过提供对应于该事件的 SelectionKey 来进行的。SelectionKey 还可以用于取消通道的注册。

SelectionKey中包含如下属性：

The interest set
The ready set
The Channel
The Selector
An attached object (optional)

序列化和反序列化
serialVersionUID(序列化版本号)到底有什么用呢，
序列化和反序列化都成功了。
下面我们修改一下Customer类，添加多一个sex属性，如下：
然后执行反序列操作，此时就会抛出如下的异常信息：
Exception in thread “main” java.io.InvalidClassException: Customer; local class incompatible:
stream classdesc serialVersionUID = -88175599799432325, local class serialVersionUID = -518253264727310
意思就是说，文件流中的class和classpath中的class，也就是修改过后的class，不兼容了，处于安全机制考虑，程序抛出了错误，并且拒绝载入。那么如果我们真的有需求要在序列化后添加一个字段或者方法呢？应该怎么办？那就是自己去指定serialVersionUID。在TestSerialversionUID例子中，没有指定Customer类的serialVersionUID的，那么java编译器会自动给这个class进行一个摘要算法，类似于指纹算法，只要这个文件 多一个空格，得到的UID就会截然不同的，可以保证在这么多类中，这个编号是唯一的。所以，添加了一个字段后，由于没有显指定 serialVersionUID，编译器又为我们生成了一个UID，当然和前面保存在文件中的那个不会一样了，于是就出现了2个序列化版本号不一致的错误。因此，只要我们自己指定了serialVersionUID，就可以在序列化后，去添加一个字段，或者方法，而不会影响到后期的还原，还原后的对象照样可以使用，而且还多了方法或者属性可以用。

Lock的tryLock()方法

tryLock 是防止自锁的一个重要方式。

tryLock()方法是有返回值的，它表示用来尝试获取锁，如果获取成功，则返回true，如果获取失败（即锁已被其他线程获取），则返回false，这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。

1.4 工作流程
一次HTTP操作称为一个事务，其工作过程可分为四步：

1）首先客户机与服务器需要建立连接。只要单击某个超级链接，HTTP的工作开始。

2）建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。

3）服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。

4）客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。

如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，有显示屏输出。对于用户来说，这些过程是由HTTP自己完成的，用户只要用鼠标点击，等待信息显示就可以了。
问题1： 为什么要三次握手？

答：三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收机能正常。

    第一次握手：Client什么都不能确认；Server确认了对方发送正常

    第二次握手：Client确认了：自己发送、接收正常，对方发送、接收正常；Server确认了：自己接收正常，对方发送正常

    第三次握手：Client确认了：自己发送、接收正常，对方发送、接收正常；Server确认了：自己发送、接收正常，对方发送接收正常

所以三次握手就能确认双发收发功能都正常，缺一不可。
问题2：为什么要发送特定的数据包，随便发不行吗？

答：三次握手的另外一个目的就是确认双方都支持TCP，告知对方用TCP传输。

    第一次握手：Server 猜测Client可能要建立TCP请求，但不确定，因为也可能是Client乱发了一个数据包给自己

    第二次握手：通过ack=J+1，Client知道Server是支持TCP的，且理解了自己要建立TCP连接的意图

    第三次握手：通过ack=K+1，Server知道Client是支持TCP的，且确实是要建立TCP连接

问题3：上图中的SYN和ACK是什么？

答：SYN是标志位，SYN=1表示请求连接；

    ACK其实就是ack后面加上的那个数，真正发送的时候不单独发ACK，只发ack，下面四次挥手的图同理

三次握手
四次挥手
问题1： 为什么要四次挥手？

答：根本原因是，一方发送FIN只表示自己发完了所有要发的数据，但还允许对方继续把没发完的数据发过来。

    举个例子：A和B打电话，通话即将结束后，A说“我没啥要说的了”，B回答“我知道了”，但是B可能还会有要说的话，A不能要求B跟着自己的节奏结束通话，于是B可能又巴拉巴拉说了一通，最后B说“我说完了”，A回答“知道了”，这样通话才算结束。

问题2：为什么双方要发送这样的数据包？

答：和握手的情况类似，只是为了让对方知晓自己理解了对方的意图。
1.7.3请求：Request
一个从客户端到服务器的请求信息包括应用于资源的方法、资源的标识符和协议的版本号。

1.7.4响应：Response
一个从服务器返回的信息包括HTTP协议的版本号、请求的状态(例如“成功”或“没找到”)和文档的MIME类型。
1.7.6实体：Entity
数据资源或来自服务资源的回映的一种特殊表示方法，它可能被包围在一个请求或响应信息中。一个实体包括实体头信息和实体的本身内容。
1.7.12网关：Gateway
一个作为其它服务器中间媒介的服务器。与代理不同的是，网关接受请求就好象对被请求的资源来说它就是源服务器；发出请求的客户机并没有意识到它在同网关打交道。

网关经常作为通过防火墙的服务器端的门户，网关还可以作为一个协议翻译器以便存取那些存储在非HTTP系统中的资源。

1.7.13通道：Tunnel
是作为两个连接中继的中介程序。一旦激活，通道便被认为不属于HTTP通讯，尽管通道可能是被一个HTTP请求初始化的。当被中继的连接两端关闭时，通道便消失。当一个门户(Portal)必须存在或中介(Intermediary)不能解释中继的通讯时通道被经常使用。
2.1 HTTP/1.0和HTTP/1.1的比较

2.1.1建立连接方面
HTTP/1.0 每次请求都需要建立新的TCP连接，连接不能复用。HTTP/1.1 新的请求可以在上次请求建立的TCP连接之上发送，连接可以复用。优点是减少重复进行TCP三次握手的开销，提高效率。

注意：在同一个TCP连接中，新的请求需要等上次请求收到响应后，才能发送。
2.1.2 Host域
HTTP1.1在Request消息头里头多了一个Host域, HTTP1.0则没有这个域。

Eg：

GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org

可能HTTP1.0的时候认为，建立TCP连接的时候已经指定了IP地址，这个IP地址上只有一个host。
2.1.4状态响应码

状态响应码100 (Continue) 状态代码的使用，允许客户端在发request消息body之前先用request header试探一下server，看server要不要接收request body，再决定要不要发request body。

客户端在Request头部中包含

Expect: 100-continue
Server看到之后呢如果回100 (Continue) 这个状态代码，客户端就继续发request body。这个是HTTP1.1才有的。

另外在HTTP/1.1中还增加了101、203、205等等性状态响应码
2.1.5请求方式
HTTP1.1增加了OPTIONS, PUT, DELETE, TRACE, CONNECT这些Request方法.

   Method         = "OPTIONS"                ; Section 9.2

                  | "GET"                    ; Section 9.3

                  | "HEAD"                   ; Section 9.4

                  | "POST"                   ; Section 9.5

                  | "PUT"                    ; Section 9.6

                  | "DELETE"                 ; Section 9.7

                  | "TRACE"                  ; Section 9.8

                  | "CONNECT"                ; Section 9.9

                  | extension-method

   extension-method = token
   2.2 HTTP请求消息

2.2.1请求消息格式
请求消息格式如下所示：

请求行

通用信息头|请求头|实体头

CRLF(回车换行)

实体内容

其中“请求行”为：请求行 = 方法 [空格] 请求URI [空格] 版本号 [回车换行]

请求行实例：

Eg1：

GET /index.html HTTP/1.1
Eg2：

POST http://192.168.2.217:8080/index.jsp HTTP/1.1

HTTP请求消息实例：

GET /hello.htm HTTP/1.1
Accept: /
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
If-Modified-Since: Wed, 17 Oct 2007 02:15:55 GMT
If-None-Match: W/“158-1192587355000”
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 192.168.2.162:8080
Connection: Keep-Alive
2.2.2请求方法
HTTP的请求方法包括如下几种：

q GET

q POST

q HEAD

q PUT

q DELETE

q OPTIONS

q TRACE

q CONNECT
2.3 HTTP响应消息
2.3.1响应消息格式
HTTP响应消息的格式如下所示：

状态行

通用信息头|响应头|实体头

CRLF

实体内容

其中：状态行 = 版本号 [空格] 状态码 [空格] 原因 [回车换行]

状态行举例：

Eg1：

HTTP/1.0 200 OK
Eg2：

HTTP/1.1 400 Bad Request
HTTP响应消息实例如下所示：

HTTP/1.1 200 OK
ETag: W/“158-1192590101000”
Last-Modified: Wed, 17 Oct 2007 03:01:41 GMT
Content-Type: text/html
Content-Length: 158
Date: Wed, 17 Oct 2007 03:01:59 GMT
Server: Apache-Coyote/1.1
2.3.2.1 1**：请求收到，继续处理
100——客户必须继续发出请求

101——客户要求服务器根据请求转换HTTP协议版本

2.3.2.2 2**：操作成功收到，分析、接受
200——交易成功
201——提示知道新文件的URL

202——接受和处理、但处理未完成

203——返回信息不确定或不完整

204——请求收到，但返回信息为空

205——服务器完成了请求，用户代理必须复位当前已经浏览过的文件

206——服务器已经完成了部分用户的GET请求

2.3.2.3 3**：完成此请求必须进一步处理
300——请求的资源可在多处得到

301——删除请求数据

302——在其他地址发现了请求数据

303——建议客户访问其他URL或访问方式

304——客户端已经执行了GET，但文件未变化

305——请求的资源必须从服务器指定的地址得到

306——前一版本HTTP中使用的代码，现行版本中不再使用

307——申明请求的资源临时性删除

2.3.2.4 4**：请求包含一个错误语法或不能完成
400——错误请求，如语法错误

401——未授权

HTTP 401.1 - 未授权：登录失败

HTTP 401.2 - 未授权：服务器配置问题导致登录失败

HTTP 401.3 - ACL 禁止访问资源

HTTP 401.4 - 未授权：授权被筛选器拒绝

HTTP 401.5 - 未授权：ISAPI 或 CGI 授权失败

402——保留有效ChargeTo头响应

403——禁止访问

HTTP 403.1 禁止访问：禁止可执行访问

HTTP 403.2 - 禁止访问：禁止读访问

HTTP 403.3 - 禁止访问：禁止写访问

HTTP 403.4 - 禁止访问：要求 SSL

HTTP 403.5 - 禁止访问：要求 SSL 128

HTTP 403.6 - 禁止访问：IP 地址被拒绝

HTTP 403.7 - 禁止访问：要求客户证书

HTTP 403.8 - 禁止访问：禁止站点访问

HTTP 403.9 - 禁止访问：连接的用户过多

HTTP 403.10 - 禁止访问：配置无效

HTTP 403.11 - 禁止访问：密码更改

HTTP 403.12 - 禁止访问：映射器拒绝访问

HTTP 403.13 - 禁止访问：客户证书已被吊销

HTTP 403.15 - 禁止访问：客户访问许可过多

HTTP 403.16 - 禁止访问：客户证书不可信或者无效

HTTP 403.17 - 禁止访问：客户证书已经到期或者尚未生效

404——没有发现文件、查询或URl

405——用户在Request-Line字段定义的方法不允许

406——根据用户发送的Accept拖，请求资源不可访问

407——类似401，用户必须首先在代理服务器上得到授权

408——客户端没有在用户指定的饿时间内完成请求

409——对当前资源状态，请求不能完成

410——服务器上不再有此资源且无进一步的参考地址

411——服务器拒绝用户定义的Content-Length属性请求

412——一个或多个请求头字段在当前请求中错误

413——请求的资源大于服务器允许的大小

414——请求的资源URL长于服务器允许的长度

415——请求资源不支持请求项目格式

416——请求中包含Range请求头字段，在当前请求资源范围内没有range指示值，请求也不包含If-Range请求头字段

417——服务器不满足请求Expect头字段指定的期望值，如果是代理服务器，可能是下一级服务器不能满足请求长。

2.3.2.5 5**：服务器执行一个完全有效请求失败
　　HTTP 500 - 内部服务器错误

HTTP 500.100 - 内部服务器错误 - ASP 错误

HTTP 500-11 服务器关闭

HTTP 500-12 应用程序重新启动

HTTP 500-13 - 服务器太忙

HTTP 500-14 - 应用程序无效

HTTP 500-15 - 不允许请求 global.asa

Error 501 - 未实现

HTTP 502 - 网关错误

2.4 使用telnet进行http测试
在Windows下，可使用命令窗口进行http简单测试。

   输入cmd进入命令窗口，在命令行键入如下命令后按回车：

telnet www.baidu.com 80
而后在窗口中按下“Ctrl+]”后按回车可让返回结果回显。

接着开始发请求消息，例如发送如下请求消息请求baidu的首页消息，使用的HTTP协议为HTTP/1.1：

GET /index.html HTTP/1.1
注意：copy如上的消息到命令窗口后需要按两个回车换行才能得到响应的消息，第一个回车换行是在命令后键入回车换行，是HTTP协议要求的。第二个是确认输入，发送请求。

可看到返回了200 OK的消息，如下图所示：

   可看到，当采用HTTP/1.1时，连接不是在请求结束后就断开的。若采用HTTP1.0，在命令窗口键入：

GET /index.html HTTP/1.0
此时可以看到请求结束之后马上断开。

   读者还可以尝试在使用GET或POST等时，带上头域信息，例如键入如下信息：

GET /index.html HTTP/1.1
connection: close
Host: www.baidu.com
2.5 常用的请求方式

   常用的请求方式是GET和POST.

GET方式：是以实体的方式得到由请求URI所指定资源的信息，如果请求URI只是一个数据产生过程，那么最终要在响应实体中返回的是处理过程的结果所指向的资源，而不是处理过程的描述。

l POST方式：用来向目的服务器发出请求，要求它接受被附在请求后的实体，并把它当作请求队列中请求URI所指定资源的附加新子项，Post被设计成用统一的方法实现下列功能：
从上面描述可以看出，Get是向服务器发索取数据的一种请求；而Post是向服务器提交数据的一种请求，要提交的数据位于信息头后面的实体中。
GET与POST方法有以下区别：

（1） 在客户端，Get方式在通过URL提交数据，数据在URL中可以看到；POST方式，数据放置在HTML HEADER内提交。

（2） GET方式提交的数据最多只能有1024字节，而POST则没有此限制。

（3） 安全性问题。正如在（1）中提到，使用 Get 的时候，参数会显示在地址栏上，而 Post 不会。所以，如果这些数据是中文数据而且是非敏感数据，那么使用 get；如果用户输入的数据不是中文字符而且包含敏感数据，那么还是使用 post为好。

（4） 安全的和幂等的。所谓安全的意味着该操作用于获取信息而非修改信息。幂等的意味着对同一 URL 的多个请求应该返回同样的结果。完整的定义并不像看起来那样严格。换句话说，GET 请求一般不应产生副作用。从根本上讲，其目标是当用户打开一个链接时，她可以确信从自身的角度来看没有改变资源。比如，新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻，该操作仍然被认为是安全的和幂等的，因为它总是返回当前的新闻。反之亦然。POST 请求就不那么轻松了。POST 表示可能改变服务器上的资源的请求。仍然以新闻站点为例，读者对文章的注解应该通过 POST 请求实现，因为在注解提交之后站点已经不同了（比方说文章下面出现一条注解）。

2.6 请求头
HTTP最常见的请求头如下：

l Accept：浏览器可接受的MIME类型；

l Accept-Charset：浏览器可接受的字符集；

l Accept-Encoding：浏览器能够进行解码的数据编码方式，比如gzip。Servlet能够向支持gzip的浏览器返回经gzip编码的HTML页面。许多情形下这可以减少5到10倍的下载时间；

l Accept-Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到；

l Authorization：授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中；

l Connection：表示是否需要持久连接。如果Servlet看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点，Servlet需要在应答中发送一个Content-Length头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然后在正式写出内容之前计算它的大小；

l Content-Length：表示请求消息正文的长度；

l Cookie：这是最重要的请求头信息之一；

l From：请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它；

l Host：初始URL中的主机和端口；

l If-Modified-Since：只有当所请求的内容在指定的日期之后又经过修改才返回它，否则返回304“Not Modified”应答；

l Pragma：指定“no-cache”值表示服务器必须返回一个刷新后的文档，即使它是代理服务器而且已经有了页面的本地拷贝；

l Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。

l User-Agent：浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用；

l UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE浏览器所发送的非标准的请求头，表示屏幕大小、颜色深度、操作系统和CPU类型。

2.7 响应头
HTTP最常见的响应头如下所示：

l Allow：服务器支持哪些请求方法（如GET、POST等）；

l Content-Encoding：文档的编码（Encode）方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet应该通过查看Accept-Encoding头（即request.getHeader(“Accept-Encoding”)）检查浏览器是否支持gzip，为支持gzip的浏览器返回经gzip压缩的HTML页面，为其他浏览器返回普通页面；

l Content-Length：表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势，可以把输出文档写入ByteArrayOutputStram，完成后查看其大小，然后把该值放入Content-Length头，最后通过byteArrayStream.writeTo(response.getOutputStream()发送内容；

l Content-Type： 表示后面的文档属于什么MIME类型。Servlet默认为text/plain，但通常需要显式地指定为text/html。由于经常要设置Content-Type，因此HttpServletResponse提供了一个专用的方法setContentTyep。 可在web.xml文件中配置扩展名和MIME类型的对应关系；

l Date：当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦；

l Expires：指明应该在什么时候认为文档已经过期，从而不再缓存它。

l Last-Modified：文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304（Not Modified）状态。Last-Modified也可用setDateHeader方法来设置；

l Location：表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302；

l Refresh：表示浏览器应该在多少时间之后刷新文档，以秒计。除了刷新当前文档之外，你还可以通过setHeader(“Refresh”, “5; URL=http://host/path”)让浏览器读取指定的页面。注意这种功能通常是通过设置HTML页面HEAD区的实现，这是因为，自动刷新或重定向对于那些不能使用CGI或Servlet的HTML编写者十分重要。但是，对于Servlet来说，直接设置Refresh头更加方便。注意Refresh的意义是“N秒之后刷新本页面或访问指定页面”，而不是“每隔N秒刷新本页面或访问指定页面”。因此，连续刷新要求每次都发送一个Refresh头，而发送204状态代码则可以阻止浏览器继续刷新，不管是使用Refresh头还是<META HTTP-EQUIV=“Refresh” …>。注意Refresh头不属于HTTP 1.1正式规范的一部分，而是一个扩展，但Netscape和IE都支持它。
2.8实体头
实体头用坐实体内容的元信息，描述了实体内容的属性，包括实体信息类型，长度，压缩方法，最后一次修改时间，数据有效性等。

l Allow：GET,POST

l Content-Encoding：文档的编码（Encode）方法，例如：gzip，见“2.5 响应头”；

l Content-Language：内容的语言类型，例如：zh-cn；

l Content-Length：表示内容长度，eg：80，可参考“2.5响应头”；

l Content-Location：表示客户应当到哪里去提取文档，例如：http://www.dfdf.org/dfdf.html，可参考“2.5响应头”；

l Content-MD5：MD5 实体的一种MD5摘要，用作校验和。发送方和接受方都计算MD5摘要，接受方将其计算的值与此头标中传递的值进行比较。Eg1：Content-MD5: <base64 of 128 MD5 digest>。Eg2：dfdfdfdfdfdfdff==；

l Content-Range：随部分实体一同发送；标明被插入字节的低位与高位字节偏移，也标明此实体的总长度。Eg1：Content-Range: 1001-2000/5000，eg2：bytes 2543-4532/7898

l Content-Type：标明发送或者接收的实体的MIME类型。Eg：text/html; charset=GB2312 主类型/子类型；

l Expires：为0证明不缓存；

l Last-Modified：WEB 服务器认为对象的最后修改时间，比如文件的最后修改时间，动态页面的最后产生时间等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT.

2.8扩展头
在HTTP消息中，也可以使用一些再HTTP1.1正式规范里没有定义的头字段，这些头字段统称为自定义的HTTP头或者扩展头，他们通常被当作是一种实体头处理。

现在流行的浏览器实际上都支持Cookie,Set-Cookie,Refresh和Content-Disposition等几个常用的扩展头字段。

l Refresh：1;url=http://www.dfdf.org //过1秒跳转到指定位置；

l Content-Disposition：头字段,可参考“2.5响应头”；

l Content-Type：WEB 服务器告诉浏览器自己响应的对象的类型。

eg1：Content-Type：application/xml ；

eg2：applicaiton/octet-stream；
3.1 Cookie和Session
Cookie和Session都为了用来保存状态信息，都是保存客户端状态的机制，它们都是为了解决HTTP无状态的问题而所做的努力。

Session可以用Cookie来实现，也可以用URL回写的机制来实现。用Cookie来实现的Session可以认为是对Cookie更高级的应用。
3.1.1两者比较
Cookie和Session有以下明显的不同点：

1）Cookie将状态保存在客户端，Session将状态保存在服务器端；

2）Cookies是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器。Cookie最早在RFC2109中实现，后续RFC2965做了增强。网络服务器用HTTP头向客户端发送cookies，在客户终端，浏览器解析这些cookies并将它们保存为一个本地文件，它会自动将同一服务器的任何请求缚上这些cookies。Session并没有在HTTP的协议中定义；

3）Session是针对每一个用户的，变量的值保存在服务器上，用一个sessionID来区分是哪个用户session变量,这个值是通过用户的浏览器在访问的时候返回给服务器，当客户禁用cookie时，这个值也可能设置为由get来返回给服务器；

4）就安全性来说：当你访问一个使用session 的站点，同时在自己机子上建立一个cookie，建议在服务器端的SESSION机制更安全些.因为它不会任意读取客户存储的信息。
3.1.2 Session机制
Session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为 session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个 session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个 session id将被在本次响应中返回给客户端保存。
3.1.6 Session的实现方式
3.1.6.1 使用Cookie来实现
服务器给每个Session分配一个唯一的JSESSIONID，并通过Cookie发送给客户端。

当客户端发起新的请求的时候，将在Cookie头中携带这个JSESSIONID。这样服务器能够找到这个客户端对应的Session。

流程如下图所示：

3.1.6.2 使用URL回显来实现

URL回写是指服务器在发送给浏览器页面的所有链接中都携带JSESSIONID的参数，这样客户端点击任何一个链接都会把JSESSIONID带会服务器。

如果直接在浏览器输入服务端资源的url来请求该资源，那么Session是匹配不到的。

Tomcat对Session的实现，是一开始同时使用Cookie和URL回写机制，如果发现客户端支持Cookie，就继续使用Cookie，停止使用URL回写。如果发现Cookie被禁用，就一直使用URL回写。jsp开发处理到Session的时候，对页面中的链接记得使用response.encodeURL() 。
3.1.3在J2EE项目中Session失效的几种情况
1）Session超时：Session在指定时间内失效，例如30分钟，若在30分钟内没有操作，则Session会失效，例如在web.xml中进行了如下设置：

30 //单位：分钟

2）使用session.invalidate()明确的去掉Session。

3.1.4与Cookie相关的HTTP扩展头
1）Cookie：客户端将服务器设置的Cookie返回到服务器；

2）Set-Cookie：服务器向客户端设置Cookie；

3）Cookie2 (RFC2965)）：客户端指示服务器支持Cookie的版本；

4）Set-Cookie2 (RFC2965)：服务器向客户端设置Cookie。

3.1.5Cookie的流程
服务器在响应消息中用Set-Cookie头将Cookie的内容回送给客户端，客户端在新的请求中将相同的内容携带在Cookie头中发送给服务器。从而实现会话的保持。

3.2 缓存的实现原理
3.2.1什么是Web缓存
WEB缓存(cache)位于Web服务器和客户端之间。

缓存会根据请求保存输出内容的副本，例如html页面，图片，文件，当下一个请求来到的时候：如果是相同的URL，缓存直接使用副本响应访问请求，而不是向源服务器再次发送请求。

HTTP协议定义了相关的消息头来使WEB缓存尽可能好的工作。
3.2.2缓存的优点
q 减少相应延迟：因为请求从缓存服务器（离客户端更近）而不是源服务器被相应，这个过程耗时更少，让web服务器看上去相应更快。

q 减少网络带宽消耗：当副本被重用时会减低客户端的带宽消耗；客户可以节省带宽费用，控制带宽的需求的增长并更易于管理。

3.2.3与缓存相关的HTTP扩展消息头
q Expires：指示响应内容过期的时间，格林威治时间GMT

q Cache-Control：更细致的控制缓存的内容

q Last-Modified：响应中资源最后一次修改的时间

q ETag：响应中资源的校验值，在服务器上某个时段是唯一标识的。

q Date：服务器的时间

q If-Modified-Since：客户端存取的该资源最后一次修改的时间，同Last-Modified。

q If-None-Match：客户端存取的该资源的检验值，同ETag。
3.2.4客户端缓存生效的常见流程
服务器收到请求时，会在200OK中回送该资源的Last-Modified和ETag头，客户端将该资源保存在cache中，并记录这两个属性。当客户端需要发送相同的请求时，会在请求中携带If-Modified-Since和If-None-Match两个头。两个头的值分别是响应中Last-Modified和ETag头的值。服务器通过这两个头判断本地资源未发生变化，客户端不需要重新下载，返回304响应。常见流程如下图所示：

3.2.5 Web缓存机制
HTTP/1.1中缓存的目的是为了在很多情况下减少发送请求，同时在许多情况下可以不需要发送完整响应。前者减少了网络回路的数量；HTTP利用一个“过期（expiration）”机制来为此目的。后者减少了网络应用的带宽；HTTP用“验证（validation）”机制来为此目的。

HTTP定义了3种缓存机制：

1）Freshness：允许一个回应消息可以在源服务器不被重新检查，并且可以由服务器和客户端来控制。例如，Expires回应头给了一个文档不可用的时间。Cache-Control中的max-age标识指明了缓存的最长时间；

2）Validation：用来检查以一个缓存的回应是否仍然可用。例如，如果一个回应有一个Last-Modified回应头，缓存能够使用If-Modified-Since来判断是否已改变，以便判断根据情况发送请求；

3）Invalidation： 在另一个请求通过缓存的时候，常常有一个副作用。例如，如果一个URL关联到一个缓存回应，但是其后跟着POST、PUT和DELETE的请求的话，缓存就会过期。

3.3 断点续传和多线程下载的实现原理
q HTTP协议的GET方法，支持只请求某个资源的某一部分；

q 206 Partial Content 部分内容响应；

q Range 请求的资源范围；

q Content-Range 响应的资源范围；

q 在连接断开重连时，客户端只请求该资源未下载的部分，而不是重新请求整个资源，来实现断点续传。

分块请求资源实例：

Eg1：Range: bytes=306302- ：请求这个资源从306302个字节到末尾的部分；

Eg2：Content-Range: bytes 306302-604047/604048：响应中指示携带的是该资源的第306302-604047的字节，该资源共604048个字节；

客户端通过并发的请求相同资源的不同片段，来实现对某个资源的并发分块下载。从而达到快速下载的目的。目前流行的FlashGet和迅雷基本都是这个原理。

多线程下载的原理：

q 下载工具开启多个发出HTTP请求的线程；

q 每个http请求只请求资源文件的一部分：Content-Range: bytes 20000-40000/47000；

q 合并每个线程下载的文件。

3.4 https通信过程
3.4.1什么是https
HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容请看SSL。

见下图：

https所用的端口号是443。

3.4.2 https的实现原理
有两种基本的加解密算法类型：

1）对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；

2）非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。

下面看一下https的通信过程：

https通信的优点：

1）客户端产生的密钥只有客户端和服务器端能得到；

2）加密的数据只有客户端和服务器端才能得到明文；

3）客户端到服务端的通信是安全的。

3.5.3 http代理图示
http代理的图示见下图：

对于客户端浏览器而言，http代理服务器相当于服务器。

而对于Web服务器而言，http代理服务器又担当了客户端的角色。
3.6 虚拟主机的实现
3.6.1什么是虚拟主机
虚拟主机：是在网络服务器上划分出一定的磁盘空间供用户放置站点、应用组件等，提供必要的站点功能与数据存放、传输功能。

所谓虚拟主机，也叫“网站空间”就是把一台运行在互联网上的服务器划分成多个“虚拟”的服务器，每一个虚拟主机都具有独立的域名和完整的Internet服务器（支持WWW、FTP、E-mail等）功能。一台服务器上的不同虚拟主机是各自独立的，并由用户自行管理。但一台服务器主机只能够支持一定数量的虚拟主机，当超过这个数量时，用户将会感到性能急剧下降。
3.6.2虚拟主机的实现原理
虚拟主机是用同一个WEB服务器，为不同域名网站提供服务的技术。Apache、Tomcat等均可通过配置实现这个功能。

相关的HTTP消息头：Host。

例如：Host: www.baidu.com

客户端发送HTTP请求的时候，会携带Host头，Host头记录的是客户端输入的域名。这样服务器可以根据Host头确认客户要访问的是哪一个域名。
GET和POST两种基本请求方法的区别
GET和POST是HTTP请求的两种基本方法，要说它们的区别，接触过WEB开发的人都能说出一二。

最直观的区别就是GET把参数包含在URL中，POST通过request body传递参数。

你可能自己写过无数个GET和POST请求，或者已经看过很多权威网站总结出的他们的区别，你非常清楚知道什么时候该用什么。

当你在面试中被问到这个问题，你的内心充满了自信和喜悦。

你轻轻松松的给出了一个“标准答案”：

GET在浏览器回退时是无害的，而POST会再次提交请求。
（因为Get请求浏览器有缓存,回退时读取的是缓存中的数据. 但是Post没有浏览器缓存会再次发送请求,消耗服务器性能
）

GET产生的URL地址可以被Bookmark，而POST不可以。

GET请求会被浏览器主动cache，而POST不会，除非手动设置。

GET请求只能进行url编码，而POST支持多种编码方式。

GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

GET请求在URL中传送的参数是有长度限制的，而POST么有。

对参数的数据类型，GET只接受ASCII字符，而POST没有限制。

GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

GET参数通过URL传递，POST放在Request body中。

（本标准答案参考自w3schools）

“很遗憾，这不是我们要的回答！”

请告诉我真相。。。

如果我告诉你GET和POST本质上没有区别你信吗？

让我们扒下GET和POST的外衣，坦诚相见吧！

GET和POST是什么？HTTP协议中的两种发送请求的方法。

HTTP是什么？HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议。

HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。

那么，“标准答案”里的那些区别是怎么回事？

在我大万维网世界中，TCP就像汽车，我们用TCP来运输数据，它很可靠，从来不会发生丢件少件的现象。但是如果路上跑的全是看起来一模一样的汽车，那这个世界看起来是一团混乱，送急件的汽车可能被前面满载货物的汽车拦堵在路上，整个交通系统一定会瘫痪。为了避免这种情况发生，交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别，有GET, POST, PUT, DELETE等等，HTTP规定，当执行GET请求的时候，要给汽车贴上GET的标签（设置method为GET），而且要求把传送的数据放在车顶上（url中）以方便记录。如果是POST请求，就要在车上贴上POST的标签，并把货物放在车厢里。当然，你也可以在GET的时候往车厢内偷偷藏点货物，但是这是很不光彩；也可以在POST的时候在车顶上也放一些数据，让人觉得傻乎乎的。HTTP只是个行为准则，而TCP才是GET和POST怎么实现的基本。

但是，我们只看到HTTP对GET和POST参数的传送渠道（url还是requrest body）提出了要求。“标准答案”里关于参数大小的限制又是从哪来的呢？

在我大万维网世界中，还有另一个重要的角色：运输公司。不同的浏览器（发起http请求）和服务器（接受http请求）就是不同的运输公司。 虽然理论上，你可以在车顶上无限的堆货物（url中无限加参数）。但是运输公司可不傻，装货和卸货也是有很大成本的，他们会限制单次运输量来控制风险，数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是，（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。超过的部分，恕不处理。如果你用GET服务，在request body偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略，所以，虽然GET可以带request body，也不能保证一定能被接收到哦。

好了，现在你知道，GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。

你以为本文就这么结束了？

我们的大BOSS还等着出场呢。。。

这位BOSS有多神秘？当你试图在网上找“GET和POST的区别”的时候，那些你会看到的搜索结果里，从没有提到他。他究竟是什么呢。。。

GET和POST还有一个重大区别，简单的说：

GET产生一个TCP数据包；POST产生两个TCP数据包。

长的说：

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。

因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑！跳入需谨慎。为什么？

1. GET与POST都有自己的语义，不能随便混用。

2. 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。

3. 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

现在，当面试官再问你“GET与POST的区别”的时候，你的内心是不是这样的？

两种最常用的 HTTP 方法是：GET 和 POST。

什么是 HTTP？
超文本传输协议（HTTP）的设计目的是保证客户机与服务器之间的通信。

HTTP 的工作方式是客户机与服务器之间的请求-应答协议。

web 浏览器可能是客户端，而计算机上的网络应用程序也可能作为服务器端。

举例：客户端（浏览器）向服务器提交 HTTP 请求；服务器向客户端返回响应。响应包含关于请求的状态信息以及可能被请求的内容。

两种 HTTP 请求方法：GET 和 POST
在客户机和服务器之间进行请求-响应时，两种最常被用到的方法是：GET 和 POST。

GET - 从指定的资源请求数据。
POST - 向指定的资源提交要被处理的数据
GET 方法
请注意，查询字符串（名称/值对）是在 GET 请求的 URL 中发送的：

/test/demo_form.asp?name1=value1&name2=value2
有关 GET 请求的其他一些注释：

GET 请求可被缓存
GET 请求保留在浏览器历史记录中
GET 请求可被收藏为书签
GET 请求不应在处理敏感数据时使用
GET 请求有长度限制
GET 请求只应当用于取回数据
POST 方法
请注意，查询字符串（名称/值对）是在 POST 请求的 HTTP 消息主体中发送的：

POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2
有关 POST 请求的其他一些注释：

POST 请求不会被缓存
POST 请求不会保留在浏览器历史记录中
POST 不能被收藏为书签
POST 请求对数据长度没有要求
比较 GET 与 POST
下面的表格比较了两种 HTTP 方法：GET 和 POST。

GET	POST

后退按钮/刷新 无害 数据会被重新提交（浏览器应该告知用户数据会被重新提交）。
书签 可收藏为书签 不可收藏为书签
缓存 能被缓存 不能缓存
编码类型 application/x-www-form-urlencoded application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
历史 参数保留在浏览器历史中。 参数不会保存在浏览器历史中。
对数据长度的限制 是的。当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。 无限制。
对数据类型的限制 只允许 ASCII 字符。 没有限制。也允许二进制数据。
安全性
与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。

在发送密码或其他敏感信息时绝不要使用 GET ！

POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。
可见性 数据在 URL 中对所有人都是可见的。 数据不会显示在 URL 中。
其他 HTTP 请求方法
下面的表格列出了其他一些 HTTP 请求方法：

方法 描述
HEAD 与 GET 相同，但只返回 HTTP 报头，不返回文档主体。
PUT 上传指定的 URI 表示。
DELETE 删除指定资源。
OPTIONS 返回服务器支持的 HTTP 方法。
CONNECT 把请求连接转换到透明的 TCP/IP 通道。
一、Cookie, Session

cookie和session都是为了弥补http协议的无状态特性，对server端来说无法知道两次http请求是否来自同一个用户，利用cookie和session就可以让用户只登录一次，server就知道某个请求是否需用重新登录。

1. cookie：客户端第一次正常访问服务器，服务器在response headers中返回与用户信息相关的cookie，客户端收到后把cookie保存在本地，下次再发请求时会在request headers中带上这个cookie，服务器收到这个cookie就知道用户状态了。cookie可以设置过期时间，默认值是-1，表示关闭浏览器时cookie就会失效，值为0时表示立马失效，相当于删除cookie（cookie没有删除的方法），服务器和客户端都可以设置cookie，但不可以操作另一个域名下的cookie。

2. session: 客户端第一次正常访问服务器，服务器生成一个sessionid来标识用户并保存用户信息（服务器有一个专门的地方来保存所有用户的sessionId），在response headers中作为cookie的一个值返回，客户端收到后把cookie保存在本地，下次再发请求时会在request headers中带上这个sessionId，服务器通过查找这个sessionId就知道用户状态了，并更新sessionId的最后访问时间。sessionId也会可以设置失效时间，比如如果60分钟内某个session都没有被更新，服务器就会删除这个它。

总言之cookie是保存在客户端，session是存在服务器，session依赖于cookie。

CDN的全称是Content Delivery Network，即内容分发网络。CDN是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。

SendRedirect Forward
不同的request 不同的对象，但是可以渠道上一个页面的内容
send后面的语句会继续执行，除非return Forward后面的语句不会继续发送给客户端
速度慢 速度快
需要到客户端的往返，可以跳转到任何页面 服务器内部转换
地址栏有变化 地址栏没有变化
可以传参数，直接写在URL后面 可以传参数
/ 代表的是http://127.0.0.0/ / 代表的是 http://127.0.0.1/test
<%response.sendRedirect();%> this.getServletContext().getRequestDispatcher

( "/servlet_jsp/ServletUseJSP.jsp").forward test (req,resp); 并且只能以 / 开头

ITeye sendRedirect和forward原理及区别总结
ITeye forward与sendRedirect区别
CSDN forward和sendRedirect的区别

HttpServletResponse.sendRedirect与RequestDispatcher.forward方法都可以实现获取相应URL资源。

sendRedirect实现请求重定向，forward实现的是请求转发。

在web服务器内部的处理机制也是不一样的。
重定向：你先去了A局，A局的人说：“这个事情不归我们管，去B局”，然后，你就从A退了出来，自己乘车去了B局。

转发：你先去了A局，A局看了以后，知道这个事情其实应该B局来管，但是他没有把你退回来，而是让你坐一会儿，自己到后面办公室联系了B的人，让他们办好后，送了过来。

1.forward方法只能转发给同一个web站点的资源，而sendRedirect方法还可以定位到同一个web站点的其他应用，甚至可以通过传入绝对路径定位到别的web站点，这事forward的方法所不能比拟的优势。

可以看到这两种方法的用法，如果传给RequestDispatcher 的参数以"/"开头，则访问的是当前web应用的根目录

加入当前web的根目录是myweb。如果传给sendRedirect方法以"/"开头，访问的是整个web站点的根目录。

[java] view plaincopy

RequestDispatcher rd = request.getRequestDispatcher("/index.jsp");
rd.forward(request, response);

    response.sendRedirect("/index.jsp");  

2.forward重定向后，浏览器url地址不变，sendRedirect转发后，浏览器url地址变为目的url地址。

3. 使用forward重定向的过程，是浏览器先向目的Servlet发送一次Request请求，然后再服务器端由Servlet再将请求发送到目的url，再由服务器端Servlet返回Response到浏览器端。浏览器和服务器一次请求响应。

   使用sendRedirect转发的过程，浏览器先向目的Servlet发送一次请求，Servlet看到sendRedirect将目的url返回到浏览器，浏览器再去请求目的url,目的url再返回response到浏览器。浏览器和服务器两次请求响应。

4. forward方法的调用者与被调用者之间共享Request和Response

   sendRedirect方法由于两次浏览器服务器请求，所以有两个Request和Response。

   如果使用request.setAttribute传递一些属性就需要用forward，如果想要跳转到别的应用的资源，就需要用sendRedirect。

5.无论是forward方法还是sendRedirect方法调用前面都不能有PrintWriter输出到客户端。

forward方法报错： java.lang.IllegalStateException: Cannot forward after response has been committed

sendRedirect报错：java.lang.IllegalStateException
at org.apache.catalina.connector.ResponseFacade.sendRedirect(ResponseFacade.java:435)

---

SendRedirect() 与 Forward() 区别

Respose.sendRedirect()
Request.getRequestDispacher().forward()
sendRedirece() Forward()
属于不同的请求 属于同一请求
重定向后地址栏发生变化 重定向后地址栏不变
重定向可转到本WEB程序以外 重定向只能在本WEB程序内
“/”：表示服务器根目录 “/”：web程序根目录

网路摘录：
1.sendRedirect 和forward的区别
简而言之，sendRedirect()相当于做一次客户端跳转，而forward则是服务端跳转。
sendRedirect是由浏览器来做的事情。当调用sendRedirect，服务端返回一个response，里面包含了跳转的内容，由浏览器获得后，进行跳转，我们可以看到浏览器中的URL是改变的。而forward则是在服务端直接做的事情，浏览器并不知道，这也就是为什么forward后浏览器的URL还是保持不变的原因。

2.实现页面跳转的方法
方式1: jsp:forward
jsp:forward 是一种JSP动作,使用语法如下:
CODESTYLE:<jsp:forward page=“Relative URL”>
在使用此动作时,主页不可以有任何的输出,它所起到的作用与SERVLET中使用的RequestDispatcher方法的作用是一致的.这种跳转是由服务器执行的,因此跳转的页面可以放在WEB-INF目录中，提高程序的安全性.

方式2 response.sendRedirect()
用此方法做跳转其实是向浏览器发送一个特殊的HEADER,然后又浏览器来做转向,装到指定的页面.所以用此方法时,浏览器上的地址栏里可以明显看到地址的变化.这与方式1动作不同,它是由服务器来做转向的.因此,使用sendRedirect做转向时,转向的页面不能放在WEB-INF下.

方式3 使用页面自动刷新
代码如下: CODESTYLE:<meta http-equiv=“Refresh” content=“秒数”;url=“跳转的文件或者地址”>

方式4 请求转发与重定向
jsp:forword 是转发请求,所以在转发过程中,请求作用域的参数在转发页面是有效的response.sendRedirect 和页面刷新实际上都是重定向,所以请求作用域的参数在转到下一页面时回失效.
1，setHeader()方法

用setHeader()方法设置响应头，为刷新“refresh”，然后设置几秒后刷新的时间和url地址

public void doGet(HttpServletRequest request, HttpServletResponse response)
			throws ServletException, IOException {
	
		//设置返回客户端的编码
		response.setContentType("text/html;charset=UTF-8");
		/*response.setIntHeader("refresh", 1);//设置1秒钟刷新一次
		
		Random r = new Random();
		
		response.getWriter().write(r.nextInt()+"");*/
		
		response.getWriter().write("注册成功！3秒钟跳到主页");
		//设置3秒钟跳转
		response.setHeader("refresh", "3;url=/day09_00_HttpServletResponse/servlet/demo6");
	}

2，sendRedirect()方法请求重定向response.sendRedirect("/day09_00_HttpServletResponse/servlet/demo8");然后就会重新定向到相应的servlet

public void doGet(HttpServletRequest request, HttpServletResponse response)
			throws ServletException, IOException {
		System.out.println("A:我要借钱！");
		System.out.println("B:我不有，但是我可以告诉你谁有");
		/*//告诉客户端要重新定向新的资源
		response.setStatus(302);
		//告诉浏览器要去访问哪个URL
		response.setHeader("location", "/day09_00_HttpServletResponse/servlet/demo8");*/
		
		//请求重定向
		response.sendRedirect("/day09_00_HttpServletResponse/servlet/demo8");
		
		System.out.println("A: 我去了");
		
	}

重定向到的页面/servlet/demo8

public void doGet(HttpServletRequest request, HttpServletResponse response)
			throws ServletException, IOException {
		System.out.println("我有钱，我借你！");
	}