http协议总结
HTTP和HTTPS的区别：
1.http的URL以http://http开头，https的URL以https://开头。
2.http是不安全的，https是安全的。换句说，https就是在http的基础上加入了加密技术、认证技术、完整性保证得到的安全的http协议，其中使用了SSL（安全套接层协议保证数据传输的安全性）。
3.http的标准端口为80，https的标准端口是443。
4.osi网络模型中，http工作于应用层，而https的安全传输机制工作在传输层。主要是用于https不是一个新的协议，是在http基础上的协议，相对来说http协议在应用层，传输的时候传给传输层。
而https,现将http报文传递给位于传输的SSL(安全套接层)实现安全的数据传输，然后在传输给tcp。
5.http无需加密，而https会对传输的数据进行加密。
6.http无需证书，任何一个人都可以发送http请求，而https需要SSL证书，来确认不同的身份。
什么是http协议无状态，怎么解决http协议的无状态协议：
无状态协议表示事务处理能力没有记忆功能，协议本身不会之前发送的请求和响应信息。换句话说，当客户端再次向服务器中发送http请求以后，服务器不知道当前用户是否是一个老用户。
可以使用Cookie技术,也可以是使用session会话，来解决无状态的问题，Cookie就相当于一个通行证，当客户端第一次访问服务器，服务器的响应报文中就包含一个叫setCookie的首部字段发送给客户端，
客户端就会对这个setCookie的值进行保存，当再次向服务器发送请求时，就会在请求报文中加入这个setCookie的值，告诉服务器这是一个老用户。
Cookie和Session的区别和联系
Cookie和Session都是为了保存客户端和服务端之间的交互状态，实现机制不同，各有优缺点。首先一个最大的区别就是Cookie是保存在客户端而Session就保存在服务端的。Cookie是客户端请求服务端时服务器会将一些信息以键值对的形式返回给客户端，保存在浏览器中，交互的时候可以加上这些Cookie值。用Cookie就可以方便的做一些缓存。Cookie的缺点是大小和数量都有限制；Cookie是存在客户端的可能被禁用、删除、篡改，是不安全的；Cookie如果很大，每次要请求都要带上，这样就影响了传输效率。Session是基于Cookie来实现的，不同的是Session本身存在于服务端，但是每次传输的时候不会传输数据，只是把代表一个客户端的唯一ID（通常是JSESSIONID）写在客户端的Cookie中，这样每次传输这个ID就可以了。Session的优势就是传输数据量小，比较安全。但是Session也有缺点，就是如果Session不做特殊的处理容易失效、过期、丢失或者Session过多导致服务器内存溢出，并且要实现一个稳定可用安全的分布式Session框架也是有一定复杂度的。在实际使用中就要结合Cookie和Session的优缺点针对不同的问题来设计解决方案。
URI和URL的区别：
URI表示统一资源标识符，用来唯一标识网络中的资源。比如说网络中的各种资源，文件，视频，图像等都是使用URI表示的。
URI一般由三部分表示，
1.访问资源的命名机制。
2.存放资源的主机名。
3.资源本身的名称，路径表示，重点表示资源。
URL表示统一资源定位符，不仅表示一个资源，还表示到达该资源的路径。
1.协议(或称为服务方式)
2.存有该资源的主机IP地址(有时也包括端口号)
3.主机资源的具体地址。如目录和文件名等。
常用的http请求方法有哪些？
1.get方式:用于请求访问被URI识别的资源，获取资源。
2.post方式:在于传输信息给服务器，和get很相似，但是推荐使用post，简洁点就是向服务器传输报文实体主体。
3.put方式:向服务器传输文件，请求报文主体包含文件内容，并保存在对应的URI中。
4.head方式:获取报文的首部，不返回报文主体，一般用于验证URI是否有效。
5.delete方式:删除文件，删除服务器中对应的URI资源。
6.options方式:获取URI识别的资源所支持的http请求方式。
7.connect方法:使用隧道连接代理，保证数据传输的安全性。
GET方法与POST方法的区别
区别一：
get重点在从服务器上获取资源，post重点在向服务器发送数据；
区别二：
get传输数据是通过URL请求，以field（字段）= value的形式，置于URL后，并用"?"连接，多个请求数据间用"&"连接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，这个过程用户是可见的；
post传输数据通过Http的post机制，将字段与对应值封存在请求实体中发送给服务器，这个过程对用户是不可见的；
区别三：
Get传输的数据量小，因为受URL长度限制，但效率较高；
Post可以传输大量数据，所以上传文件时只能用Post方式；
区别四：
get是不安全的，因为URL是可见的，可能会泄露私密信息，如密码等；
post较get安全性较高；
区别五：
get方式只能支持ASCII字符，向服务器传的中文字符可能会乱码。
post支持标准字符集，可以正确传递中文字符。
http请求报文和响应报文的格式。
请求报文可以分为两部分，之间用空行隔开。
第一部分是报文首部，
报文首部又可以分为几部分：
1：请求行（由请求方式，请求URI，协议版本）
2: 各种首部字段，请求首部字段，通用首部字段，实体首部字段，和其他一些首部字段构成。
第二部分是报文主体，
响应报文可以也分为两部分，之间用空行隔开。
第一部分是报文首部，
报文首部又可以分为几部分：
1：状态行（由协议版本，状态码，原因短语）
2: 各种首部字段，响应首部字段，通用首部字段，实体首部字段，和其他一些首部字段构成。
第二部分是报文主体
在之前讲述了报文的主要构成，发现其中首部字段很重要，包含了 报文的重要信息，现在就介绍一下常用的首部：
通用首部字段（在请求报文和响应报文都会使用到的首部字段）
1.Date:报文的创建时间。
2.Connection:连接的管理（是否是持久化连接）。
3.cache-control:对缓存的控制，是否在代理服务器可以缓存响应。
4.transfer-encoding:报文主体的传输过程的编码方式。
请求首部字段（在请求报文中会使用的首部字段）
1.host:请求支援所在的服务器，域名，可能同一个IP地址下有不同的服务器，通过这个可以区分到底是什么服务器。
2.accept:客户端可处理的媒体类型，文本，图像，音频等等。
3.accept-charset:客户端能接受的字符集。
4.accept-encoding:客户端能接受的内容编码。
5.accept-language:客户端能接受的自然语言。
响应首部字段（在响应报文中会使用的首部字段）
1.accept-ranges：是否支持范围请求。
2.location：使客户端重定向到指定的URI。
3.server：表示当前服务器的安装信息，版本信息，
实体首部字段：（报文主体部分会使用的首部字段）
1.allow：资源可支持的http请求方式。
2.content-type:实体的媒体类型。
3.content-encoding:实体使用的是什么编码方式。
4.content-language:实体使用的自然言语。
5.Content-Length：实体主体的的字节数
6.Content-Range：实体主体的位置范围，一般用于发出部分请求时使用
HTTP的缺点与HTTPS
a、通信使用明文不加密，内容可能被窃听
b、不验证通信方身份，可能遭到伪装
c、无法验证报文完整性，可能被篡改
HTTPS就是HTTP加上加密处理（一般是SSL安全通信线路）+认证+完整性保护
https安全通信工作的流程:
1.客户端发起HTTPS请求，向指定的服务器发送请求。
2.服务器的配置，采用HTTPS协议的服务器需要有一套数字证书（这个证书里面包含了公共密钥）。换句话说就是，服务器将把公共密钥发送给数字认证机构，数字认证机构用自己的私有密钥对公共密钥加密，并添加数字签名，比如一些颁发机构。
3.传送证书，这个证书其实就是一个公共密钥，只是包含了很多的信息，如证书的颁发机构，过期时间等。
4.客户端解析证书，使用数字证书认证机构的公开密钥，向数字认证机构验证证书上的数字签名，以确保服务器的公共密钥的真实性。
5.传输加密信息，这部分用的是证书中的公共密钥对数据进行加密，发送给服务端。同时服务端可以使用私用的密钥对数据进行解密，也可以发送加密的数据给客户端，客户端在进行解密。
这里可以简述过程，首先客户端发送HTTPS请求给特定的服务器，服务器就会有两个密钥，一个是要发送给客户端的密钥，一个是私有的密钥。如果直接发送共有密钥给客户端，不加以保护的，可能共有密钥在传输的过程中就会被篡改，造成客户端和服务器都不能解析数据。所以会对共有密钥加上认证（以表示共有密钥的真实性），会将共有密钥发送给第三方的认证机构，使用第三方的私有密钥对服务器的共有密钥进行加密，并加上各种认证信息，数字签名。然后发送给客户端，客户端接收后，使用第三方认证机构的共有密钥对证书进行解析，验证数字签名的正确性。说明这是正确的服务器共有密钥，那么发送数据就可以使用这个共有密钥进行加密了。
一个完整的http请求所经历的7个步骤。
1.建立tcp连接，通过三次握手建立tcp连接
2.发送请求行->发送请求头（当发送为一个空行，表示请求头结束）->服务器发送状态行->发送响应头->发送响应数据->断开tcp连接。
这里需要注意的是，一般情况下，在一次http通信的过程结束后都会断开tcp连接，但是如果在请求或者是响应报文中有keep-alive，不会断开tcp连接（这个叫持久化连接，通信双方未明确断开的情况下，一直保持连接）。
在http中常用的状态码，主要可以分为5类，分别有1,2,3,4,5开头的3位数字。
1.以1开头，1XX，表示当前请求正在被处理。
2.以2开头，2XX，表示请求被成功处理了。
200 OK 请求被正常处理。
204 not content 请求被正常处理，没有资源返回
206 partial content 请求正常处理，并返回指定范围的资源。
3.以3开头，3XX，表示请求处理还需要一些附加信息。
4.以4开头，4XX，表示客户端发送的请求有错误，或者说错误的原因在客户端。
400，请求报文语法有误。
404，客户端请求的资源不存在，not found。
402，请求的资源是私有的，拒绝访问。
5.以5开头，5XX，表示服务端出现错误，不能正常处理请求。
500, 服务器内如出错。
503，服务器太忙，反应不过来。
408 Request Timeout和504 Gateway Timeout的区别
408是说请求超时，就是建立连接之后再约定的时间内客户端没有发送请求到客户端到服务端。本质上原因在于客户端或者网络拥塞。
504是网关超时，是说代理服务器把客户端请求转发到应用服务器后再约定的时间内没有收到应用服务器的响应。本质上原因在于服务端的响应过慢，也有可能是网络问题。
HTTP1.1版本新特性
a、默认持久连接节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求
b、管线化，客户端可以同时发出多个HTTP请求，而不用一个个等待响应
***********************************************************
c、断点续传，实际上就是利用HTTP消息头使用分块传输编码，将实体主体分块传输。
要实现断点续传的功能，通常都需要客户端记录下当前的下载进度，并在需要续传的时候通知服务端本次需要下载的内容片段。
HTTP1.1协议（RFC2616）中定义了断点续传相关的HTTP头 Range和Content-Range字段，一个最简单的断点续传实现大概如下：
1.客户端下载一个1024K的文件，已经下载了其中512K
2. 网络中断，客户端请求续传，因此需要在HTTP头中申明本次需要续传的片段：
Range:bytes=512000-
这个头通知服务端从文件的512K位置开始传输文件
3. 服务端收到断点续传请求，从文件的512K位置开始传输，并且在HTTP头中增加：
Content-Range:bytes 512000-/1024000
并且此时服务端返回的HTTP状态码应该是206，而不是200。
但是在实际场景中，会出现一种情况，即在终端发起续传请求时，URL对应的文件内容在服务端已经发生变化，此时续传的数据肯定是错误的。如何解决这个问题了？显然此时我们需要有一个标识文件唯一性的方法。在RFC2616中也有相应的定义，比如实现Last-Modified来标识文件的最后修改时间，这样即可判断出续传文件时是否已经发生过改动。同时RFC2616中还定义有一个ETag的头，可以使用ETag头来放置文件的唯一标识，比如文件的MD5值。
终端在发起续传请求时应该在HTTP头中申明If-Match 或者If-Modified-Since 字段，帮助服务端判别文件变化。
另外RFC2616中同时定义有一个If-Range头，终端如果在续传是使用If-Range。If-Range中的内容可以为最初收到的ETag头或者是Last-Modfied中的最后修改时候。服务端在收到续传请求时，通过If-Range中的内容进行校验，校验一致时返回206的续传回应，不一致时服务端则返回200回应，回应的内容为新的文件的全部数据。
***********************************************************
