【Java Web】： HTTP协议详解

    绝大多数的Web开发，都是构建在Http协议之上的Web应用，理解和掌握Http协议，将有助于我们更好地学习和掌握Servlet和JSP技术，以及其他相关的Web开发技术,在 web 开发与 Android 开发过程，要涉及到客户端与服务端的交互，这一点我们需要对Http有深入的了解，这样才能更好的进行开发。这也是我们学习Http协议的目的所在。

1. HTTP协议相关介绍

    Http（Hypertext Transfer Protocol）超文本传输协议，从1990年开始就在WWW上广泛应用，是现今在WWW上应用得最多的协议，目前的版本为1.1。
    Http是应用层协议，当你上网浏览网页的时候，浏览器和服务器之间就会通过Http在Internet上进行数据的发送和接收。
    Http是一个基于请求/响应模式的，无状态的协议(request/response based ,stateless protocol)[重要]。
    [如何理解基于请求/相应模式，无状态的呢？]： 也就是浏览器作为客户端，后台有服务器是一直在运行着，在打开浏览器输入网址的时候，敲入回车的时候浏览器就会把这个请求发送给服务端。因为输入的是一个域名，所以会被DNS解析成一个IP地址，然后通过路由交换找到远程的服务器，服务器会在一直接受着客户端的请求，接受到请求之后，就比如这个这个网址是网易的首页，则服务器就将首页的页面信息通过网络将其相应的内容(html源码)返回到客户端(浏览器)，浏览器通过渲染引擎将html源码呈现出网页的显示效果。这个就是 请求/响应模式。什么是无状态呢？就是说客户端发出一个请求，服务端将其相应，加入说这个客户端又发出一个请求，服务器端不会去记住你这个请求是否是刚才的客户端发出的请求。这就是所谓的无状态的含义。
     比如说有一个BBS论坛，用户在输入用户名和密码之后登录，服务器收到用户登录信息的请求相应之后，用户登录成功，此时用户在发帖或者评论的时候就是一直都是用当前的这个用户名和密码来进行操作的。此时服务器那边按照HTTP协议无状态的理论，它应该是要用户在每次发帖或者评论的时候都做这样的登录信息的请求才能操作的，但是现实中，我们只要登录一次就可以进行发帖和评论的操作了，所以不管是什么语言都有处理克服HTTP协议无状态的这种机制，让服务器知道这个用户之前是登录过的还是没有登录过的(让服务器知道当前的状态是什么)。

   

  上图为浏览器与服务器通信的过程(HTTP1.0):为什么会发出连接?因为http协议是构建在TCP协议上的，而TCP是要构建一个连接的，所以http也需要向服务器发起连接

2.  持续连接（Persistent Connections）

    在Http1.0中，当连接建立后，浏览器发送一个请求，服务器回应一个消息之后，连接就被关闭。当浏览器下次请求的时候，需要重新建立连接，很显然这种需要不断建立连接的通信方式开销比较大。早期的Web页面通常只包含HTML文本，因此即使建立连接的开销比较大，也不会有太大的影响。而现在的Web页面往往包含多种资源（图片，动画，声音等），每获取一种资源，就建立一次连接，这样就增加了HTTP服务器的开销，造成了Internet上的信息堵塞。
    因此在Http1.1版本中，给出了一个持续连接（Persistent Connections）的机制，并将其作为Http1.1中建立连接的缺省行为。通过这种连接，浏览器可以在建立一个连接之后，发送请求并得到回应，然后继续发送请求并再次得到回应。而且，客户端还可以发送流水线请求，也就是说，客户端可以连续发送多个请求，而不用等待每一个响应的到来。
    一个WEB站点每天可能要接收到上百万的用户请求，为了提高系统的效率，HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。但是，这也造成了一些性能上的缺陷，例如，一个包含有许多图像的网页文件中并没有包含真正的图像数据内容，而只是指明了这些图像的URL地址，当WEB浏览器访问这个网页文件时，浏览器首先要发出针对该网页文件的请求，当浏览器解析WEB服务器返回的该网页文档中的HTML内容时，发现其中的图像标签后，浏览器将根据标签中的src属性所指定的URL地址再次向服务器发出下载图像数据的请求，当一个网页文件中包含Applet，JavaScript文件，CSS文件等内容时，也会出现类似上述的情况。

   

            上图为持续连接中发送请求的过程


上图为浏览器与服务器通信的过程(HTTP1.1)：如果在http1.0中需要建立四个连接，发出四个请求。而在http协议1.1中就只需要建立一个连接，发出四个请求。注意在持续连接中，服务端也不是无限制的一直开启着连接的，它有自己的机制，比如说在建立连接之后，服务端在3s钟之内没有接到客户端的下一次请求，则连接就关闭掉。
[注意]：这边的请求和回送是有序的主要是因为基于TCP协议，TCP协议是面向连接的可靠的所以它是有序的，先到先处理。

3. HTTP URL

http://host[: port] [abs_path]
http: 表示要通过HTTP协议来定位网络资源。
Host: 表示合法的nternet主机域名或IP地址（以点分十进制格式表示）
Port: 用于指定一个端口号，拥有被请求资源的服务器主机监听该端口的TCP连接。如果port是空，则使用缺省的端口80。
abs_path: 指定请求资源的URI（Uniform Resource Identifier,统一资源标识符），如果URL中没有给出abs_path,那么当它作为请求URI时，必须以“/”的形式给出。通常这个工作浏览器就帮我们完成了.

在浏览器中输入网址时，它是通过DNS域名解析将域名网址转为IP地址的，浏览器会自动添加http://  和 末尾的 /.TCP连接有一个server Socket，默认是80端口，也就是服务器那边一直在监听这个端口。整个连接大概是这样的：
------------------------------------------------------>

ServerSocket serverSocket = new ServerSocket(80);

serverSocket.accpet();
浏览器输入：www.soho.com, 后台的操作如下所示：
www.soho.com + 80(浏览器自动添加端口号) --> DNS(Domain Name Server) --> 221.179.180.20 所以就是：221.179.180.20:80

客户端这边做的操作是：

Socket socket = new Socket(" 221.179.180.20 ",80);
所以服务器端如果不是80端口，而是自己指定端口的时候，客户端在输入网址的时候一定要加入指定的端口。以上就是浏览器与服务器连接的一般过程。

------------------------------------------------------>

2). URL 与 URI

URI 纯粹是一个符号结构，用于指定构成Web资源的字符串的各个不同部分。
URL 是一种特殊类型的URI，它包含了用于查找某个资源的足够的信息。其他的URI，例如：mailto:[email protected],则不属于URL，因为它里面不存在根据该标识符来查找的任何数据。这种URI成为URN（通用资源名）

3). HTTP请求

客户端通过发送HTTP请求向服务器请求对资源的访问
HTTP请求由三部分组成，分别是：请求行，消息报头，请求正文。这三部分我们是没有办法看到的，全部都是由浏览器给我们封装好的。
   请求行：

  请求行以一个方法符号开头，后面跟着请求URI和协议的版本，以CRLF作为结尾。请求行以空格分隔。除了作为结尾的CRLF外，不允许出现单独的CR或LF字符，格式如下：
  Method Request-URI HTTP-Version CRLF
Method: 表示请求的方法

      (关于方法Method，目前在Web开发中一般是使用 Get 和 Post方法，其实是定义了多种Method方法还有head啥的，但是浏览器仅仅是实现了 Get 和 Post的方法。Get 和 Post方法在用来看来没有多少差别，但是在底层差别是非常大的。

  调侃一下：HTTP协议的创始人写了一篇论文 REST(Repressentational State Transfer) 可表述性状态转移，他提出来了目前的网络设计的缺陷，他提出应该以资源为核心，给每一个资源一个标示，通过HTTP协议的各种方法(Get,Post,PUT,Delete等)来对资源进行查询，替换的操作。现在很多公司对外提供 Web Service 的接口的时候都有提供 RESTFul, 这些将来有机会讲到WebServeice的时候再提到这个设计初衷是非常好的，但是浏览器没有实现出来，一般都是用 Get 和 Post方法)

Request-URI: 是一个统一资源标识符，标识了要请求的资源。 (比如说 www.soho.com/index.html 则UIR资源就是 /index.html)
HTTP-Version: 表示请求的HTTP协议版本,CRLF表示回车换行。 (http协议的版本，注意如果服务器的版本是1.0的话，它就用http1.0给予相应)
例如：GET /test.html HTTP/1.1 (CRLF)(用Get的方式来请求服务器的资源/test.html  http协议的版本是1.1。)
--------------------------------------------------
HTTP请求 - 方法

这些方法类似数据库的增删查改存储。HEAD 方法在于开发人员来说用的不多，一般用的Get方法，它不仅会得请求的内容，还会得到请求的头部信息。

1) GET方法用于获取由Request-URI所标识的资源的信息，常见形式是：

GET Request-URI HTTP/1.1

2) 当我们通过在浏览器的地址栏中直接输入网址的方式去访问网页的时候，浏览器采用的就是GET方法向服务器获取资源
3) POST方法用于向服务器发送请求，要求服务器接受附在请求后面的数据。POST方法在表单提交的时候用的最多
4) 采用POST方法提交表单的例子

POST /login.jsp HTTP/1.1 (CRLF)
Accept:image/gif (CRLF) (….)
Host:www.sample.com (CRLF)(….)
….
Cache-Control:no=cache (CRLF)
(CRLF)
username=hello&password=123456

5) HEAD方法与GET方法几乎是一样的，他们的区别在于HEAD方法只是请求消息报头，而不是完整的内容。对于HEAD请求的回应部分来说，它的HTTP头部中包含的信息与通过GET请求所得到的信息是相同的。利用这个方法，不必传输整个资源的内容，就可以得到Request-URI所标识的资源的信息。这个方法通常用于测试超链接的有效性，是否可以访问，以及最近是否更新等
6) 当我们在HTML中提交表单时，浏览器会根据你的提交方法是get还是post，采用相应的在HTTP协议中的GET或POST方法，向服务器发出请求。
7) 注意：在HTML文档中，书写get和post，不区分大小写，但HTTP协议中的GET和POST只能是大写形式

4) HTTP响应：

在接收和解释请求消息后，服务器会返回一个HTTP响应消息.
与HTTP请求类似，HTTP响应也是由三个部分组成，分别是：状态行，消息报头，响应正文.
   HTTP响应 - 状态行：

   状态行由协议版本，数字形式的状态代码，相应的状态描述组成，各元素之间以空格分隔，除了结尾的CRLF（回车换行）序列外，不允许出现CR或LF字符。格式如下：

HTTP-Version Status-Code Reason-Phrase CRLF

HTTP-Version: 表示服务器HTTP协议的版本.
Status-Code: 表示服务器发回的响应代码.
Reason-Phrase: 表示状态代码的文本描述. (也就是类似请求的状态码说明。)
CRLF: 表示回车换行
例如：HTTP/1.1 200 OK (CRLF) (OK是对200的描述)
--------------------------------------------------
HTTP响应 - 状态代码与状态描述：
1) 状态代码由三位数字组成，表示请求是否被理解或被满足，状态描述给出了关于状态代码的简短文本描述
2) 状态代码的第一个数字定义了响应的类别，后面两个数字没有具体的分类。第一个数字有五种可能的取值

1xx：指示信息—表示请求已接收，继续处理
2xx：成功—表示请求已经被成功接收，理解，接受
3xx：重定向—要完成请求必须进行更进一步的操作
4xx：客户端错误—请求有语法错误或请求无法实现
5xx：服务器端错误—服务器未能实现合法的请求

图为HTTP响应 - 状态代码与状态描述
常见状态描述：

  最著名的是404状态码的返回情况，主要是服务器上没有找到相关的资源文件产生的错误。也就是 404错误， Page cannot be found.

  比如说500 内部服务器的错误

4) HTTP消息：

  HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行，消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。
  对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行

这一讲我们对HTTP的知识有了一些简单的概括，当然HTTP协议远远不止这些内容，下一讲，我们来学习 使用Telnet远程连接服务器端 的试验。
  实验工具 ：Telnet
  HTTP协议与TELNET协议都是基于TCP协议