前言
最近在看面经的时候，发现大部分的公司面试的时候都会问到http协议，大部分的博客写的不是很系统，所以决定自己写一篇。
统一资源定位符URL
在说HTTP协议之前必须要先了解URL（统一资源定位符）统一资源定位符是对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示，是互联网上标准资源的地址。互联网上的每个文件都有一个唯一的URL，它包含的信息指出文件的位置以及浏览器应该怎么处理它。
基本URL包含模式（或称协议）、服务器名称（或IP地址）、路径和文件名，如“协议://授权/路径?查询”。完整的、带有授权部分的普通统一资源标志符语法看上去如下：协议://用户名:密码@子域名.域名.顶级域名:端口号/目录/文件名.文件后缀?参数=值#标志
第一部分
模式/协议（scheme）：它告诉浏览器如何处理将要打开的文件。最常用的模式是超文本传输协议（Hypertext Transfer Protocol，缩写为HTTP），这个协议可以用来访问网络。其他协议如下：
http——超文本传输协议资源
https——用安全套接字层传送的超文本传输协议
ftp——文件传输协议
mailto——电子邮件地址
ldap——轻型目录访问协议搜索
file——当地电脑或网上分享的文件
news——Usenet新闻组
gopher——Gopher协议
telnet——Telnet协议
第二部分
文件所在的服务器的名称或IP地址，后面是到达这个文件的路径和文件本身的名称。服务器的名称或IP地址后面有时还跟一个冒号和一个端口号。它也可以包含接触服务器必须的用户名称和密码。路径部分包含等级结构的路径定义，一般来说不同部分之间以斜线（/）分隔。询问部分一般用来传送对服务器上的数据库进行动态询问时所需要的参数。
超文本传送协议HTTP
HTTP协议（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传输协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。
HTTP是客户端浏览器或其他程序与Web服务器之间的应用层通信协议。在Internet上的Web服务器上存放的都是超文本信息，客户机需要通过HTTP协议传输所要访问的超文本信息。HTTP包含命令和传输信息，不仅可用于Web访问，也可以用于其他因特网/内联网应用系统之间的通信，从而实现各类应用资源超媒体访问的集成。
HTTP协议是OSI模型中的第七层应用程中协议具有以下特点：
1、支持客户/服务器模式;
2、简单快速;
3、灵活;
4、无连接;
5、无状态；
给一个简单的实例来看看http协议的执行过程上图中用户点击了一个链接指向清华大学院系设置的页面，其URL是http://www.tsinghua.edu.cn/chn/yxsz/index.htm用http/1.0更具体的说明用户在点击鼠标后发生的事件：
（1）浏览器分析链接指向页面的URL。
（2）浏览器向DNS请求解析http://www.tsinghua.edu.cn的IP地址。
（3）域名系统DNS解析出清华大学的IP地址为166.111.4.100。
（4）浏览器与服务器建立TCP连接（服务器的IP地址是166.111.4.100，端口号是80）。
（5）浏览器发出取文件命令：GET/chn/yxsz/index.htm。
（6）服务器http://www.tsinghua.edu.cn做出响应，把文件index.htm发送给浏览器。
（7）释放TCP连接。
（8）浏览器显示“清华大学院系设置”文件index.htm中的所有文件。
浏览器在下载文件时，可以设置为只下载其中的文本部分。这样可使下载的速度加快。在这种情况下，文本中原来嵌入图像或声音的地方只用一个小图标来显示。用户若要下载这些图像或声音，可再用鼠标分别点击这些图标。每点击一次鼠标就重复执行一次类似于上面的8个步骤。也就是先建立TCP连接，再使用TCP连接传送命令和文件，最后释放TCP连接。
HTTP使用了面向连接的TCP作为运输层协议，保证了数据的可靠传输。
HTTP是无连接的
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
早期这么做的原因是 HTTP 协议产生于互联网，因此服务器需要处理同时面向全世界数十万、上百万客户端的网页访问，但每个客户端(即浏览器)与服务器之间交换数据的间歇性较大(即传输具有突发性、瞬时性)，并且网页浏览的联想性、发散性导致两次传送的数据关联性很低，大部分通道实际上会很空闲、无端占用资源。因此 HTTP 的设计者有意利用这种特点将协议设计为请求时建连接、请求完释放连接，以尽快将资源释放出来服务其他客户端。
HTTP是无状态的
无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即我们给服务器发送 HTTP 请求之后，服务器根据请求，会给我们发送数据过来，但是，发送完，不会记录任何信息。HTTP 是一个无状态协议，这意味着每个请求都是独立的。
缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
HTTP 协议这种特性有优点也有缺点，优点在于解放了服务器，每一次请求“点到为止”不会造成不必要连接占用，缺点在于每次请求会传输大量重复的内容信息。
一次HTTP过程
如上图用户点击某个万维网文档连接时，HTTP协议首先要和服务器建立TCP连接。这是需要三次握手。当三次握手的前两部分完成后（经过了一个RTT时间后），万维网客户就把HTTP请求报文作为第三次握手的第三个报文的数据发送给万维网服务器。万维网服务器收到HTTP请求报文后，就把所请求的文档作为响应报文返回给客户。
HTTP/1.0协议的缺点
HTTP的主要缺点，就是每请求一个文档就要两倍RTT的开销。若一个主页上有很多链接的对象（如图片等）需要一次进行链接，那么每一次链接下载都导致2RTT的开销。另一种开销就是万维网客户和服务器没一次建立新的TCP连接都要分配缓存和变量。
HTTP/1.1协议较好的解决了上面的问题，它使用持续连接。在万维网服务器发送响应后仍然在一段时间内保持这条连接，使同一个客户（浏览器）和服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文。并且不限于传送同一个页面上链接的文档，而是只要这些文档都在一个服务器上就行。
HTTP/1.1协议的持续连接有两种方式，即非流水线方式和流水线方式。
HTTP的报文结构
HTTP有两类报文：
（1）请求报文—–从客户端向服务器发送请求报文。
（2）响应报文—–从服务器到客户的回答。
请求报文的结构如下图：
响应报文的结构如下图：
HTTP请求报文和响应报文都是由三个部分组成。可以看出这两种报文的区别就在于开始行不同。
（1）开始行，用于区别是请求报文还是响应报文。在请求报文中的开始行叫做请求行，而在响应报文中的开始行就叫做状态行。
（2）首部行，用于说明浏览器、服务器、或报文主体的一些信息。首部可以有好几行，但也可以不用。
（3）实体主体，在请求报文中一般不用这个字段，在响应报文中返回请求的内容，也可以不用。
请求报文的第一行“请求行”只有三个内容，方法，请求资源的URL，以及HTTP的版本。这里的方法是对请求的对象进行的操作，这些方法实际上也就是一些命令，请求报文的类型就是由它采用的方法决定的。
HTTP的请求方法
1、OPTIONS
返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性
2、HEAD
向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。
3、GET
向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在Web Application中，其中一个原因是GET可能会被网络蜘蛛等随意访问。
4、POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
5、PUT
向指定资源位置上传其最新内容
6、DELETE
请求服务器删除Request-URL所标识的资源
7、TRACE
回显服务器收到的请求，主要用于测试或诊断
8、CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
GET和POST的比较
GET - 从指定的服务器中获取数据
POST - 提交数据给指定的服务器处理
GET方法：
使用GET方法时，查询字符串（键值对）被附加在URL地址后面一起发送到服务器：
/test/demo_form.jsp?name1=value1&name2=value2
特点：
（1）GET请求能够被缓存
（2）GET请求会保存在浏览器的浏览记录中
（3）以GET请求的URL能够保存为浏览器书签
（4）GET请求有长度限制
（5）GET请求主要用以获取数据
POST方法：
使用POST方法时，查询字符串在POST信息中单独存在，和HTTP请求一起发送到服务器：
POST /test/demo_form.jsp
HTTP/1.1 Host: w3schools.com
name1=value1&name2=value2
特点：
（1）POST请求不能被缓存下来
（2）POST请求不会保存在浏览器浏览记录中
（3）以POST请求的URL无法保存为浏览器书签
（4）POST请求没有长度限制
HTTP状态码
HTTP状态码（HTTP Status Code）是用以表示网页服务器HTTP响应状态的3位数字代码。每一个请求报文发出后，都能收到一个响应报文。响应报文的第一行就是状态行。状态行包含三项内容，HTTP的版本、状态码、以及解释状态码的简单短语。状态码共分为5大类33种。如：
下面是在状态行中常见的状态码：
100 Continue
客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。
101 Switching Protocols
服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade 消息头中定义的那些协议。
200 OK
请求已成功，请求所希望的响应头或数据体将随此响应返回。
201 Created
请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话，应当返回 ‘202 Accepted’。
202 Accepted
服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。
300 Multiple Choices
被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。
301 Moved Permanently
被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。
400 Bad Request
1、语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。
2、请求参数有误。
404 Not Found
请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。出现这个错误的最有可能的原因是服务器端没有这个页面。
HTTP与HTTPS的区别
到现在为止，我们已了解到 HTTP 具有相当优秀和方便的一面，然而 HTTP 并非只有好的一面，事物皆具两面性，HTTP 也是有不足之处的。
1、通信使用明文（ 不加密） ， 内容可能会被窃听
2、不验证通信方的身份， 因此有可能遭遇伪装
3、无法证明报文的完整性， 所以有可能已遭篡改
通信使用明文可能会被窃听由于 HTTP 本身不具备加密的功能，所以也无法做到对通信整体（使用 HTTP 协议通信的请求和响应的内容）进行加密。即，HTTP 报文使用明文（指未经过加密的报文）方式发送。
HTTP 协议的实现本身非常简单，不论是谁发送过来的请求都会返回响应，因此不确认通信方，会存在以下各种隐患。
1、无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。
2、无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
3、无法确定正在通信的对方是否具备访问权限。因为某些Web 服务器上保存着重要的信息， 只想发给特定用户通信的权限。
4、无法判定请求是来自何方、出自谁手。
5、即使是无意义的请求也会照单全收。无法阻止海量请求下的DoS 攻击（ Denial of Service， 拒绝服务攻击） 。
确保 Web 安全的 HTTPS
在 HTTP 协议中有可能存在信息窃听或身份伪装等安全问题。使用 HTTPS 通信机制可以有效地防止这些问题。
HTTP+ 加密 + 认证 + 完整性保护 =HTTPS
HTTP 加上加密处理和认证以及完整性保护后即是 HTTPS如果在 HTTP 协议通信过程中使用未经加密的明文，比如在 Web 页面中输入信用卡号，如果这条通信线路遭到窃听，那么信用卡号就暴露了。另外，对于 HTTP 来说，服务器也好，客户端也好，都是没有办法确认通信方的。因为很有可能并不是和原本预想的通信方在实际通信。并且还需要考虑到接收到的报文在通信途中已经遭到篡改这一可能性。为了统一解决上述这些问题，需要在 HTTP 上再加入加密处理和认证等机制。我们把添加了加密及认证机制的 HTTP 称为 HTTPS （HTTP Secure）。
参考文献
1、计算机网络第五版（谢希仁）
2、TCP/IP协议详解卷1
3、http://www.cnblogs.com/zxj015/p/6530766.html