文章目录
HTTP协议简介
HTTP协议定义了浏览器(即万维网客户进程)怎样向万维网服务器请求万维网文档，以及服务器怎样把文档传送给浏览器。从层次的角度看，HTTP是面向事务的(transaction-oriented)'应用层协议，它是万维网上能够可靠地交换文件(包括文本、声音、图像等各种多媒体文件)的重要基础。
HTTP协议的工作机制
每个万维网网点都有一个服务器进程，它不断地监听TCP的端口80，以便发现是否有浏览器(即万维网客户。请注意，浏览器和万维网客户是同义词)向它发出连接建立请求。一旦监听到连接建立请求并建立了TCP连接之后，浏览器就向万维网服务器发出浏览某个页面的请求，服务器接着就返回所请求的页面作为响应。最后，TCP连接就被释放了。在浏览器和服务器之间的请求和响应的交互，必须按照规定的格式和遵循一定的规则。这些格式和规则就是超文本传送协议HTTP。
HTTP规定在HTTP客户与HTTP服务器之间的每次交互，都由一个ASCII码串构成的请求和一个“类MIME (MIME-like)”的响应组成。HTTP报文通常都使用TCP连接传送。
用户浏览页面的方法有两种。一种方法是在浏览器的地址窗口中填入所要找的页面的URL。另一种方法是在某一个页面中用鼠标点击一个可选部分，这时浏览器会自动在因特网上找到所要链接的页面。
例如用户在浏览器中点击url会发生以下流程：
浏览器分析链接指向页面的URL浏览器向DNS请求解析ip地址域名系统DNS解析出IP地址为111.111.111.111浏览器与服务器建立TCP连接(在服务器端IP地址是111.111.111.111， 端口是80)浏览器发出取文件命令服务器给出响应，把需要取的文件发送给浏览器释放TCP浏览器显示文件
无连接
HTTP使用了面向连接的TCP作为运输层协议，保证了数据的可靠传输。HTTP 不必考虑数据在传输过程中被丢弃后又怎样被重传。但是，HTTP协议本身是无连接的。这就是说，虽然HTTP使用了TCP 连接，但通信的双方在交换HTTP报文之前不需要先建立HTTP连接。
无状态
HTTP协议是无状态的(stateless)。也就是说，同一个客户第二次访问同一个服务器上的页面时，服务器的响应与第一次被访问时的相同(假定现在服务器还没有把该页面更新),因为服务器并不记得曾经访问过的这个客户，也不记得为该客户曾经服务过多少次。
为什么不将HTTP协议设计为维持状态？
因为维持状态的协议很复杂：
- 必须维护历史信息
- 如果服务器/客户端死机，它们的状态信息可能不一致,二者的信息必须是一致
HTTP的无状态特性简化了服务器的设计，使服务器更容易支持大量并发的HTTP请求。
非持久HTTP(短链接)和持久HTTP(长链接)
非持久HTTP协议(HTTP/1.0)最多只有一个对象在TCP连接上发送，下载多个对象需要多个TCP连接。
那么来粗略计算一下：从浏览器请求一个万维网文档收到文档所需要的的时间。用户在点击鼠标链接某个万维网文档时，HTTP协议首先要和服务器建立TCP连接。这需要使用三次握手。当三次握手的前两部分完成后( 即经过了一个RTT时间后),万维网客户就把HTTP请求报文作为三次握手的第三个报文的数据发送给万维网服务器。服务器收到HTTP请求报文后，就把所请求的文档作为响应报文返回给客户。
请求一个万维网文档所需的时间是该文档的传输时间(与文档大小成正比)加上两倍往返时间RTT (一个RTT用于连接TCP连接，另一个RTT用于请求和接收万维网文档。这里TCP建立连接的三次握手的第三个报文段中捎带了客户对万维网文档的请求)。
HTTP/1.0的主要缺点，就是每请求一个文档就要有两倍RTT的开销。若一个主页上有很多链接的对象( 如图片等)需要依次进行链接，那么每一次链接下载都导致2x RTT的开销。另一种开销就是万维网客户和服务器为每一次建立新的TCP连接都要分配缓存和变量。特别是万维网服务器往往要同时服务于大量客户的请求，这样会使万维网服务器的负担很重。好在浏览器都提供了能够打开5 ~ 10个并行的TCP连接，而每一个TCP连接处理各户的一个请求。因此，使用并行TCP连接可以缩短响应时间。
HTTP/1.1协议较好地解决了这个问题，它使用了持久连接。 所谓持续连接就是万维网服务器在发送响应后仍然在一段时间内保持这条连接，使同一个客户(浏览器)和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文。这并不局限于传送同一个页面上链接的文档，而是只要这些文档都在同一个服务器上就行。持续连接的本质其实就是通过减少频繁的TCP链接，来达到提高效率的目的！
对应的，报头部分会出现Connection：keep-alive属性
HTTP/1.1协议的持续连接有两种工作方式，即非流水线方式(without pipelining )和流水线方式(with pipelining)。
非流水线方式的特点，是客户在收到前一个响应后才能发出下一个请求。因此，在TCP连接已建立后，客户每访问一次对象都要用去一个往返时间RTT。 这比非持续连接的两倍RTT的开销节省了建立TCP连接所需的一个RTT 时间。但非流水线方式还是有缺点的，因为服务器在发送完一一个对象后，其TCP连接就处于空闲状态，浪费了服务器资源。
流水线方式的特点，是客户在收到HTTP的响应报文之前就能够接着发送新的请求报文。于是一个接一个的请求报文到达服务器后，服务器就可连续发回响应报文。因此，使用流水线方式时，客户访问所有的对象只需花费-个RTT时间。流水线工作方式使TCP连接中的空闲时间减少，提高了下载文档效率。
HTTP报文结构
HTTP有两种报文：
- 请求报文——从客户端向服务器发送请求报文
- 响应报文——从服务器到客户端的回答
由于HTTP是面向文本的，因此在报文中的每一- 个字段都是一些ASCII码串，因而各个字段的长度都是不确定的。
HTTP请求报文和响应报文都是由三个部分组成。可以看出，这两种报文格式的区别就是开始行不同。
- 开始行，用于区分是请求报文还是响应报文。在请求报文中的开始行叫做请求行,而在响应报文中的开始行叫做状态行。在开始行的三个字段之间都以空格分隔开，最后的“CR"和“LF”分别代表“回车”和“换行”(\n)。
- 首部行，用来说明浏览器、服务器或报文主体的一些信息。首部可以有好几行，但也可以不使用。在每一个首部行中都有首部字段名和它的值，每一行在结束的地方都要有“回车”和“换行”。整个首部行结束时，还有一空行将首部行和后面的实体主体分开。
- 实体主体(有效载荷),在请求报文中一般都不用这个字段，而在响应报文中也可能没有这个字段。
请求报文
请求报文的第一行“请求行”只有三个内容，即方法，请求资源的URL，以及HTTP的版本。
请求方法就是所请求的对象进行的操作，这些方法实际上是一些命令。
虽然这里有这么多的方法，HTTP也支持，但是用户不一定都能使用。换言之：例如DELETE方法，用户使用该方法可以将服务器上的资源全都删除，这是服务端不希望发生的事，所以服务端大概率会将这个方法禁用掉，防止用户的恶意行为。服务端最多也就开放出GET、POST和HEAD方法。
这里要着重说明一下GET和POST区别
GET：方法叫做“获取”，是最常用的方法，默认一般获取所有的网页，都是GET方法，但是如果GET要提交参数(能提交参数！！！)，通过URL来进行参数拼接从而提交给server端
POST：方法叫做“推送”，是提交参数比较常用的方法(和GET相比)，但是提交的参数，一般是通过正文部分提交的。
对比：
- 参数提交的位置不同，POST方法比较私密（私密 != 安全），不会回显到浏览器的url输入框中！GET方法不私密，会将重要信息回显到url的输入框中，增加了被盗取的风险
- GET提交的数据大小有限制（因为浏览器对URL的长度有限制，具体限制是多大，和浏览器有关），而POST方法提交的数据没有限制
如何选择
如果提交的参数不敏感，数量非常少，可以采用GET，否则采用POST
GET和POST其实就是前后端交互的一个重要方式
响应报文
每一个请求报文发出后，都能收到一个响应报文。响应报文的第一行就是状态行。
状态行包括三项内容，即HTTP的版本，状态码，以及解释状态码的简单短语。
HTTP的状态码
最常见的状态码, 比如 200(OK), 404(Not Found), 403(Forbidden), 302(Redirect, 重定向), 504(Bad Gateway)
这里的重定向又分为临时重定向(302 or 307)和永久重定向(301)，什么意思呢？
举个例子：老网站的域名为：www.old.com，新网站的域名为：www.new.com。用户只知道老网站的域名，当用户访问网站时，我们希望这些用户访问的是新网站，所以就在老的服务器中做一个永久重定向。当用户请求www.old.com时，老的服务器就会告诉客户端，应该访问www.new.com。但实际上对于用户而言，并不知道，但用户的浏览器知道，浏览器就会重新向www.new.com发起请求，并且浏览器会将你保存的书签或者收藏里面的域名更改称为新域名。这就是永久重定向，一般用于网站搬迁或者域名更换。
当我们访问某种资源时，会提示我们登录，然后跳转到登录页面，登录完成后，会自动跳转回来。这就是临时重定向。
重定向是需要浏览器提供支持，必须识别301、302、307这些状态码。
但对于有些状态码，例如404的状态码，对浏览器没有任何指导意义，浏览器还是会正常显示你的网页。所以对于不同的浏览器，支持的状态码可能会存在一定的差别。
HTTP常见Header
- Content-Type: 数据类型(text/html等)
- Content-Length: Body的长度
- Host: 客户端告知服务器, 所请求的资源是在哪个主机的哪个端口上;
- User-Agent: 声明用户的操作系统和浏览器版本信息;
- referer: 当前页面是从哪个页面跳转过来的;
- location: 搭配3xx状态码使用, 告诉客户端接下来要去哪里访问;
- Cookie: 用于在客户端存储少量信息. 通常用于实现会话(session)的功能
Header部分有这么多属性，当我们读取一个报文时，那么是如何判断Herader部分被读完了呢？亦或是说如何判断哪些是Herader部分，哪些是有效载荷(正文部分)？
不要忘记了，前面谈及HTTP报文时，无论是请求报文还是响应报文，在Hearad后面都有一个换行符，用来作为分割Hearder和有效载荷。在读取报文时，当读取到换行符时，就表明Hearder部分已经读取完，接下来是有效载荷部分了。
那么又是如何判断有效载荷到底有多大呢？
Hearder部分有一个属性：Content-Length，用来表明有效载荷的大小，这样就能精确的将有效载荷部分全部读取到。如果Heade中不存在该属性，则表示这个报文不含有效载荷（请求报文通常不含有Content-Length属性）
Session和Cookie
HTTP本身是无状态的。这样做虽然简化了服务器的设计，提高了并发量。但是在实际工作中，一些网站却希望能够识别用户。
例如：在网站上看vip电影时，需要用户登录，当这个vip电影看完后，他还要继续看其他的vip电影。因此，服务器需要记住用户的身份，使他在看另一部vip电影就不需要再次登录，这样就提高了用户的观影体验。有时某些万维网站点也可能想限制某些用户的访问。要做到这点，可以在HTTP使用Cookie。
Cookie的工作原理
（1）浏览器端第一次发送请求到服务器端
（2）服务器端创建Cookie，该Cookie中包含用户的信息，然后将该Cookie发送到浏览器端
（3）浏览器端再次访问服务器端时会携带服务器端创建的Cookie
（4）服务器端通过Cookie中携带的数据区分不同的用户
当你首次登陆(不含cookie信息)以后，服务器就会返回一些数据(cookie)给浏览器，那么当你再次请求服务器的时候，浏览器会将cookie一块发送给服务器。服务器通过浏览器携带的数据就能判断当前用户是哪个了。
Cookie有两种保存方式，一种是浏览器会将Cookie保存在内存中，还有一种是保存在客户端的硬盘中
Session的工作原理
（1）浏览器端第一次发送请求到服务器端，服务器端创建一个Session，同时会创建一个特殊的Cookie（name为JSESSIONID的固定值，value为session对象的ID），然后将该Cookie发送至浏览器端
（2）浏览器端发送第N（N>1）次请求到服务器端,浏览器端访问服务器端时就会携带该name为JSESSIONID的Cookie对象
（3）服务器端根据name为JSESSIONID的Cookie的value(sessionId),去查询Session对象，从而区分不同用户。
当你登陆一个网站的时候，如果web服务器端使用的是session，那么所有的数据都保存在服务器上，客户端每次请求服务器的时候会发送当前会话sessionid，服务器根据当前sessionid判断相应的用户数据标志，以确定用户是否登陆或具有某种权限。由于数据是存储在服务器上面，所以你不能伪造。
seesion也是有生命周期的，根据需求设定，一般来说，半小时。举个例子，你登录一个服务器，服务器返回给你一个sessionid，登录成功之后的半小时之内没有对该服务器进行任何HTTP请求，半小时后你进行一次HTTP请求，会提示你重新登录
区别
(1)cookie数据存放在客户的浏览器上，session数据放在服务器上
(2)cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,如果主要考虑到安全应当使用session
(3)session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，如果主要考虑到减轻服务器性能方面，应当使用COOKIE
(4)单个cookie在客户端的是有大小限制的
总的来说：将登陆信息等重要信息存放为session;其他信息如果需要保留，可以放在cookie中
2300
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
