HTTP初识

1. HTTP协议是超文本传输协议（Hyper Text Transfer Protocol）的缩写，是用于从万维网（www）服务器传输超文本到本地浏览器的传送协议；
2. 现在万维网使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行中；
3. HTTP是一个应用层协议，基于传输层的TCP协议，由请求和响应构成；
4. HTTP默认端口号是80，HTTPS的默认端口号是433；
5. HTTP协议工作与客户端-服务端（C/S）架构，浏览器作为HTTP客户端通过URL向服务端（Web服务器）发送请求；服务端接受到请求后，向客户端发送响应信息。

image.png

HTTP特点

1. 支持B/S（浏览器/服务端）和C/S（客户端/服务端）模式；
2. 简单快速：客户端向服务端请求服务是，只需要传送请求方法和路径，常用的请求方法：GET、POST、HEAD，由于HTTP协议简单，使得HTTP服务器的程序规模小，所以通信速度快；
3. 灵活：允许传输任意类型的数据对象，用Content-Type去进行标记；
4. 无连接：限制每次连接至处理一个请求，在完成客户端的请求之后，就断开连接；
5. 无状态：指协议对事物处理没有记忆能力，如果后续处理需要前面的信息，则需要重传，这样会导致数据量增大；相反，如果不需要前面的信息，则反应速度更快；

备注（无状态协议）

HTTP协议是一种不保存状态的协议，即无状态（stateless）协议。新的请求发送就会有新的响应产生，协议本身不保留之前的请求或响应报文信息。但是随着业务的发展，很多场景需求中都需要掌握之前报文中的信息，例如电商购物网站，登录之后跳转到该站其他页面，也需要保持登录。HTTP/1.1本身是无状态协议，于是为了满足业务需求，网景通信公司开发来了Cookie并制定了标准，这套标准进行扩展之后的产物就是我们现在常用的管理服务器和客户端之前状态的Cookie。

注意：HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP是用的事UDP协议（无连接），从HTTP/1.1开始，默认都开启了Keep-Alive，保持连接特性，当一个网页打开后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器的网页，会继续使用这条已经建立的连接。但是Keep-Alive有一个保持时间，可以在不同的服务器软件中设定。

Cookie
Cookie会根据从服务器端发送的响应报文内的Set-Cookie首部字段通知客户端保存Cookie。下次客户端再往该服务器发送请求的时候，客户端会自动在请求报文中加入Cookie值后发送出去。

Cookie状态管理.png

Cookie: sid=1324343545

首部字段Cookie会告知服务器，当客户端想获得HTTP状态管理支持时，就会在请求中包含从服务器收到的Cookie，接收到多个Cookie是，同样以多个Cookie形式发送。

Set-Cookie

<Set-Cookie: sid=1324343545; path=/; expires=Wed,10-Oct-12 07:12:20 GMT; domain=.example.com>

字段属性

会话跟踪

会话：客户端打开与服务器的连接发出请求到服务器响应客户端请求的全过程；

会话跟踪：指对同一个用户对服务器的连续请求和接受响应的监视；

会话跟踪常用的方法：

Cookie和Session的不同点：

1. Cookie将状态保存在客户端，Session将状态保存在服务器端；
2. Cookie是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器，Session并没有在HTTP协议中定义；
3. Session是针对每一个用户的，变量值保存在服务器上，用一个SessionId来区分是哪个用户，这个是通过用户的浏览器在访问的时候返回给服务器的，当客户金庸cookie时，这个值也可能设置由get返回给服务器；
4. 当你访问一个使用session 的站点，同时在自己机子上建立一个cookie，建议在服务器端的SESSION机制更安全些。因为它不会任意读取客户存储的信息。

HTTP报文结构

HTTP报文结构.png

HTTP请求

URL和URI：

URI：统一资源定位符（Uniform Resource Identifiers），用来唯一标识一个资源。
URI一般由三个部分组成：

1. 访问资源的命名机制
2. 存放资源的主机名
3. 资源自身的名称，由路径表示，着重强调于资源

URL：统一资源定位器（Uniform Resource Locator，是一种具体的URI，即URL可以用来标识一个资源，并且还指明如何定位这个资源；

URL一般由三部分组成：

1. 协议（服务方式）
2. 存有该资源的主机IP地址（域名，有时也包括端口号）
3. 资源的具体地址（根目录）

URL格式：http://host[":port"][path]

1. http表示要通过HTTP协议去定位网络资源；
2. host表示合法的主机域名或者IP；
3. port用来指定访问的端口号，若没有则是用缺省端口80；
4. path指定请求资源的URI，若没有URI，那么必须以“/”的形式来表示。

例： http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

URN：统一资源命名(uniform resource name)，是通过名字来标识资源。

总结：URI是以一种抽象的，高层次概念定义统一资源标识，而URL和URN则是具体的资源标识的方式。URL和URN都是一种URI。笼统地说，每个 URL 都是 URI，但不一定每个 URI 都是 URL。这是因为 URI 还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。
在Java的URI中，一个URI实例可以代表绝对的，也可以是相对的，只要它符合URI的语法规则。而URL类则不仅符合语义，还包含了定位该资源的信息，因此它不能是相对的。
在Java类库中，URI类不包含任何访问资源的方法，唯一的作用就是解析，而URL类可以打开一个到达资源的流。

HTTP请求组成：开始行[请求行]、[消息报头]、（空行CR+LF）、[请求正文]

请求行：包括请求方法，请求的URI，HTTP协议版本号[例如：POST /xxx HTTP/1.1]

常见的请求方法(请求类型)

消息头：常用头、请求头、响应头、实体头

Request-Headers
key（大小写不敏感） : value

消息主体和实体主体

消息主体(message-body)：客户端想让服务端看到的内容；
实体主体(entity-body)：服务端接收到来自客户端的实际内容；
注意：传输过程中，可能会对entity-body进行编码；而且不是所有请求消息或者响应消息都有消息主体。消息主体可否存在由请求类型和响应类型决定；

常见的请求头：（在HTTP/1.1中，所有的请求头，除了Host外，都是可选的）

POST提交数据的方式

1. 通过form表单的enctype

2. 通过Content-Type: application/json方式，用来告诉服务端消息主题是序列化后的json字符串

HTTP响应

HTTP响应组成：开始行[状态行]、[响应报头]、（空行CR+LF）、[响应正文]

响应头

响应状态码(响应类型)

持久连接

在HTTP协议的初始版本中，每进行一次HTTP通信就要断开一次TCP连接

HTTP初始连接.png

持久连接.png

在HTTP/1.0中，并没有官方标准规定Keep-Alive如何工作，因此这个是被附加到HTTP/1.0协议上的，如果客户端浏览器支持Keep-Alive，那么就在HTTP请求头中添加一个字段Connection: Keep-Alive，当服务器收到这样的请求时，则在响应头中也会添加一个同样的字段来使用Keep-Alive，这样，客户端和服务端之间的HTTP连接就会被保持。

在HTTP/1.1中，默认情况所有连接都是持久连接。客户端会在持久连接上连续发送请求。当客户端想断开连接时，则指定Connection为Close。

注意：

• HTTP Keep-Alive就是保持当前的TCP连接，避免重新建立连接；
• HTTP长连接不可能一直保持，例如Keep-Alive: timeout=5, max=100，表示这个TCP通道可以保持5秒，最多接收100次请求就断开；
• HTTP是一个无状态连接，意味着每个请求都是独立的，Keep-Alive唯一能做到的就是当连接被关闭的时候能得到通知；

HTTP管线化
默认情况下 HTTP 协议中每个传输层连接只能承载一个 HTTP 请求和响应，浏览器会在收到上一个请求的响应之后，再发送下一个请求。在使用持久连接的情况下，某个连接上消息的传递类似于请求1 -> 响应1 -> 请求2 -> 响应2 -> 请求3 -> 响应3。
HTTP Pipelining（管线化）是将多个 HTTP 请求整批提交的技术，在传送过程中不需等待服务端的回应。使用 HTTP Pipelining 技术之后，某个连接上的消息变成了类似这样请求1 -> 请求2 -> 请求3 -> 响应1 -> 响应2 -> 响应3。

注意：

• 管线化机制通过持久连接（persistent connection）完成，仅 HTTP/1.1 支持此技术（HTTP/1.0不支持）
• 只有 GET 和 HEAD 请求可以进行管线化，而 POST 则有所限制
• 初次创建连接时不应启动管线机制，因为对方（服务器）不一定支持 HTTP/1.1 版本的协议
• 管线化不会影响响应到来的顺序，如上面的例子所示，响应返回的顺序并未改变
• HTTP /1.1 要求服务器端支持管线化，但并不要求服务器端也对响应进行管线化处理，只是要求对于管线化的请求不失败即可
• 由于上面提到的服务器端问题，开启管线化很可能并不会带来大幅度的性能提升，而且很多服务器端和代理程序对管线化的支持并不好，因此现代浏览器如 Chrome 和 Firefox 默认并未开启管线化支持