面试之HTTP协议相关的问题

HTTP的请求报文结构和响应报文结构

HTTP请求报文主要由请求行、请求头、空行、请求正文(Get请求没有请求正文)4部分组成。

1、请求行

  由三部分组成,分别为:请求方法、URL以及协议版本,之间由空格分隔;

  请求方法包括GET、HEAD、PUT、POET、TRACE、OPTIONS、DELETE以及扩展方法,当然并不是所有的服务器都实现了所有的方法,部分方法即便支持,出于安全性的考虑也是不同的;

  协议版本的格式为:HTTP/主版本号.次版本号,常用的有HTTP/1.0和HTTP/1.1;

2、请求头

  请求头部为请求报文添加了一些附加信息,由“名/值”对组成,每行一对,名和值之间使用冒号分隔。

  常见请求头如下:

                         

3、空行

  请求头的最后会有一个空行,表示请求头部结束,接下来为请求正文,这一行非常重要,必不可少。

4、请求正文

  可选部分,比如GET请求就没有请求正文。

HTTP响应报文主要由状态行、响应头、空行、响应正文4部分组成。

1、状态行

  由3部分组成,分别为:协议版本、状态码、状态码描述,之间由空格分隔;

2、响应头

  与请求头类似,为响应报文添加一些附加信息。

  常见响应头如下:

                          

3、空行

4、响应正文

常见HTTP首部字段

A、通用首部字段(请求报文与响应报文都会使用的首部字段

  Date:创建报文时间

  Connection:连接的管理

  Cache-Control:缓存的控制

  Transfer-Encoding:报文主体的传输编码方式,如Transfer-Encoding: chunked。

B、请求首部字段(请求报文会使用的首部字段)

  Host:请求资源所在服务器

  Accept:可处理的媒体类型

  Accept-Charset:可接收的字符集

  Accept-Encoding:可接受的内容编码

  Accept-Language:可接受的自然语言

  Referer:HTTP Referer是header的一部分,当浏览器向web服务器发送请求的时候,一般会带上Referer,告诉服务器我是从哪个页面链接过来的,服务器可以获得一些信息用于处理。比如从我主页上链接到一个朋友那里,他的服务器就能够从HTTP Referer中统计出每天有多少用户点击我主页上的链接访问他的网站。如果是CSRF攻击传来的请求,Referer字段会是包含恶意网址的地址,这时候服务器就能识别出恶意的访问。

C、响应首部字段(响应报文会使用的首部字段)

  Accept-Ranges:可接受的字节范围

  Location:另客户端重新定向到的URI

  Server:HTTP服务器的安装信息

D、实体首部字段(请求报文与响应报文的实体部分使用的首部字段)

  Allow:资源可支持的HTTP方法

  Content-Type:实体主类的类型

  Content-Encoding:实体主体适用的编码方式

  Content-Language:实体主体的自然语言

  Content-Length:实体主体的字节数

  Content-Range:实体主体的位置范围

HTTP状态码含义

200 OK  服务器已成功处理了请求并提供了请求的网页。

202 Accepted  已经接受请求,但处理尚未完成。

204 No Content  没有新文档,浏览器应该继续显示原来的文档。

206 Partial Content  客户但进行了范围请求。响应报文中由Content-Range指定实体内容的范围。实现断点续传。

-----------------------------------------------------------------------------------------------------

301 Moved Permanently  永久性重定向。请求的网页已永久移动到新位置。

302(或307) Moved Temporatily  临时性重定向。请求的网页临时移动到新位置。

304 Not Modified  未修改。自从上次请求后,请求的内容未修改过。

-----------------------------------------------------------------------------------------------------

401 Unauthorized  客户试图未经授权访问受密码保护的页面。应答终会包含一个WWW-Authenticate头,浏览器据此显示用户名字/密码对话框,然后再填写合适的Authorization头后再次发出请求。

403 Forbidden  服务器拒绝请求。----------403.6-IP address rejected

404 Not Found  服务器上不存在客户机所请求的资源。

-----------------------------------------------------------------------------------------------------

500 Internal Server Error  服务器遇到一个错误,使其无法为请求提供服务。

HTTP中有关缓存的首部字段有哪些?HTTP的浏览器缓存机制?

1、Last-Modified和If-Modified-Since

  简单地说,Last-Modified和If-Modified-Since都是用于记录页面最后修改时间的HTTP头信息,只是Last-Modified是由服务器王客户但发送的HTTP头,而If-Modified-Since则是由客户端往服务器发送的头,当再次请求本地存在的缓存页面时,客户端会通过If-Modified-Since头把浏览器缓存页面的最后一次被服务器修改的时间一起发到服务器去,服务器会把这个时间与服务器上实际文件的最后修改时间进行比较,通过这个时间戳判断客户端的页面是否是最新的,如果不是最新的,就返回HTTP状态码200和新文件内容,客户端收到之后,会丢弃旧文件,把新文件缓存起来,并显示到浏览器中;如果是最新的,则返回304告诉客户端其本地缓存的页面是最新的,就直接把本地缓存文件显示到浏览器中,这样在网络上传输的数据量就会大大减少,同时也减轻了服务器的负担。

  1)什么是“Last-Modified”

  在浏览器第一次请求某一个URL时,服务器端的返回状态是200,内容是你请求的资源,同时有一个Last-Modified的属性标记此文件在服务器端最后被修改的时间,格式类似这样:Last-Modified:Fri, 12 May 2010 18:53:33 GMT

  客户端第二次请求此URL时,浏览器会向服务器传送If-Modified-Since报头,询问该时间之后文件是否有被修改过:If-Modified-Since: Fri, 12 May 2010 18:53:33 GMT

  如果服务器的资源没有变化,则自动返回HTTP 304状态码,内容为空,这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时,则重新发出资源,返回和第一次请求时类似,从而保证不向客户端重复发出资源,也保证当服务器有变化时,客户端能够得到最新的资源。

2、ETag和 If-None-Match

  ETag和 If-None-Match是一种常用的判断资源是否改变的方法。类似于Last-Modified和If-Modified-Since。但是有所不同的是Last-Modified和If-Modified-Since只判断资源的最后修改时间,而ETag和 If-None-Match可以是资源的任何属性,比如资源的MD5等。

  ETag和 If-None-Match的工作原理是在HTTP Response中添加ETags信息。当客户端再次请求该资源时,将在HTTP Request中加入If-None-Match信息(也就是ETags的值)。如果服务器验证资源的ETags没有改变(该资源的内容没有改变),将返回一个304状态;否则,服务器将返回200状态,并返回该资源和新的ETags。

  1)什么是“ETag”?

  服务器为每个资源分配对应的ETag值,根据资源的内容得到其值。当资源内容发生改变时,其值也会改变。以下是服务器端返回的格式:

    ETag:"50b1c1d4f775c61:df3"

    客户端的查询更新格式是这样的:

    If-None-Match:W/"50b1c1d4f775c61:df3"

    如果ETag没有改变,则返回状态304,这也和Last-Modified一样。

  扩展1:Last-Modified和ETags如何帮助提高性能?

    聪明的开发者会把Last-Modified和ETags请求的HTTP报头一起使用,这样可利用客户端的缓存。因为服务器首先产生Last-Modified/Etag标记,服务器可在稍后使用它来判断页面是否已经被修改。本质上,客户端通过将该记号传回服务器要求服务器验证其(客户但)缓存

  扩展2:既然有了Last-Modified,为什么还要用ETag字段呢?

    1)某些文件修改非常频繁,比如在秒以下的时间内进行修改,If-Modified-Since能检查到的粒度是秒级的,这种修改无法体现。

    2)一些文件也许会周期性的更改,但是它的内容并不改变(仅仅改变修改的时间),这个时候我们并不希望客户端认为这个文件被修改了,而重新GET;

    3)某些服务器不能精确的得到文件的最后修改时间。

   因此,HTTP/1.1利用Entity Tag 头提供了更加严密的验证。Last-Modified与ETag一起使用时,服务器会优先验证ETag的值。

3、Expires/Cache-Control(优先使用)

  用来控制缓存的失效日期,控制浏览器是直接从浏览器缓存取数据还是重新发请求到服务器取数据。

  Expires是web服务器响应消息头字段,在响应HTTP请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据,而无需再次请求。Expires的一个缺点是,返回的到期时间是服务器端的时间。这样就存在一个问题,如果客户端的时间与服务器的时间相差很大(比如时间不同步,或者跨时区),那么误差就很大,所以在HTTP1.1版开始,使用Cache-Control: max-age=(秒)替代。

  当服务器发出响应的时候,可以通过两种方式来告诉客户端缓存请求:

  第一种是Expires,比如:Expires: Sun, 16 Oct 2016 05:43:02 GMT

    不过Expires有缺点,比如说,服务端和客户端的时间设置可能不同,这就会使缓存的失效可能并不能精确地按服务器的预期进行。

  第二种是Cache-Control,比如:Cache-Control: max-age=315360000

    这里声明的是一个相对的秒数,表示从现在起,315360000秒内缓存都是有效的,这样就避免了服务端和客户端时间不一致的问题。

  但是Cache-Control是HTTP1.1才有的,不适用于HTTP1.0,而Expires既适用于HTTP1.0,也适用于HTTP1.1,所以说在大多数情况下,同时发送这两个头回是一个更好的选择,当用户端两种头都能解析的时候,会优先使用Cache-Control。

过程如下:

  (1)客户端请求一个页面(A)。

  (2)服务器返回页面A,并再给A加上一个Last-Modified和ETag。 

  (3)客户端展现该页面,并将页面连同Last-Modified和ETag的值一起缓存。

  (4)客户再次请求页面A,并将上次请求时服务器返回的Last-Modified和ETag的值一起传递给服务器。

  (5)服务器检查该Last-Modified或ETag,并判断出该页面自上次客户端请求之后还未被修改,直接返回响应304和一个空的响应体。

 

1.首先在服务器创建一个简单的HTML文件,用浏览器访问一下,成功表示HTML页面。Fiddler就会产生下面的捕获信息。

需要留意的是:

  (1)因为是第一次访问该页面,客户端发请求时,请求头中没有If-Modified-Since标签。

  (2)服务器返回的HTTP状态码是200,并发送页面的全部内容。

  (3)服务器返回的HTTP头标签中有Last-Modified,告诉客户端页面的最后修改时间。

2.在浏览器中刷新一下页面,Fiddler就会产生下面的捕获信息。

需要注意的是:

  (1)客户端发HTTP请求时,使用If-Modified-Since标签,把上次服务器告诉它的文件最后修改时间返回到服务器端了。

  (2)因为文件没有改动过,所以服务器返回的HTTP状态码是304,没有发送页面的内容。

3.用文本编辑器稍微改动一下页面文件,保存。再用浏览器访问一下,Fiddler就会产生下面的捕获信息。

需要注意的是:

  (1)客户端发HTTP请求时,使用If-Modified-Since标签,把上次服务器告诉它的文件最后修改时间返回到服务器端了。

  (2)因为文件被改动过,两边的时间不一致,所以服务器返回的HTTP状态码是200,并发送新页面的全部内容。

  (3)服务器返回的HTTP头标签中有Last-Modified,告诉客户端页面的新的最后修改时间。

HTTP1.1和HTTP1.0的区别。(HTTP1.1版本的4个特性)

1、默认持久连接和流水线

  HTTP/1.1默认使用持久连接,只要客户端服务端任意一端没有明确提出断开TCP连接,就一直保持连接,在同一个TCP连接下,可以发送多次HTTP请求。同时,默认采用流水线的方式发送请求,即客户端每遇到一个对象引用就立即发出一个请求,而不必等到收到前一个响应之后才能发出下一个请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送相应结果,以保证客户端能够区分出每次请求的相应内容,这样也显著地减少了整个下载过程所需要的时间。

  HTTP/1.0默认使用短连接,要建立长连接,可以在请求消息中包含Connection: Keep-Alive头域,如果服务器愿意维持这条连接,在响应消息中也会包含一个Connection: Keep-Alive的头域。Connection请求头的值为Keep-Alive时,客户端通知服务器返回本次清秋节过后保持连接;Connection请求头的值为close时,客户端通知服务器返回本次请求结果后关闭连接。

2、分块传输数据

  HTTP/1.0可用来指定实体长度的唯一机制是通过Content-Length字段。静态资源的长度可以很容易的确定,但是对于动态生成的响应来说,为获取它的真是长度,只能等它完全生成之后,才能正确地填写Content-Length的值,这便要求缓存整个响应,在服务器端占用大量的缓存,从而延长了响应用户的时间。

  HTTP/1.1引入了被称为分块(chunked)的传输方法。该方法使发送方能将消息实体分割为任意大小的组块(chunk),并单独地发送它们。在每个组块前面,都加上了该组块的长度,使接收方可确保自己能够完整地接收到这个组块。更重要的是,在最末尾的地方,发送方生成了长度为零的组块,接收方可据此判断整条消息都已安全地传输完毕。这样也避免了在服务器端占用大量的的缓存。Transfer-Encoding:chunked向接收方指出:响应将被分组块,对响应分析时,应采取不同于非分组块的方式。

3、状态码 100 Continue

  HTTP/1.1加入了一个新的状态码 100 Continue,用于客户端在发送POST数据给服务器前,征询服务器的情况,看服务器是否处理POST数据。

  当要POST的数据大于1024字节的时候,客户端并不会直接就发起了POST请求,而是会分为2步:

    (1)发送一个请求,包含一个Except: 100-continue,询问Server是否愿意接受数据。

    (2)接收到Server返回的100 continue应答以后,才把数据POST给Server。

  这种情况通常发生在客户端准备发送一个冗长的请求给服务器,但是不确认服务器是否有能力接收。如果没有得到确认,而将一个冗长的请求包发送给服务器,然后包被服务器给抛弃了,这种情况挺浪费资源的。

4、Host域

  HTTP1.1在Request消息头里多了一个Host域,HTTP1.0则没有这个域。在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,这个IP地址上只有一个主机。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机,并且它们共享一个IP地址。

常用的HTTP方法有哪些?

           

注意:只有POST和PUT方法才有请求内容。

  GET:用于请求访问已经被URI(统一资源标识符)识别的资源,可以通过URL传参给服务器。

  POST:用于传输信息给服务器,主要功能与GET方法类似,但一般推荐使用POST方式。

  PUT:传输文件,报文主体中包含文件内容,保存到对应URI位置。

  HEAD:获得报文首部,与GET方法类似,只是不返回报文主体。

  DELETE:删除文件,与PUT方法相反,删除对应URI位置的文件。

  OPTIONS:查询相应URL支持的HTTP方法。

注意:并非所有的服务器都实现了这几个方法。有的服务器还实现了自己持有的HTTP方法,称为扩展方法。

  GET:GET可以说是最常见的了,它本质就是发送一个请求来取得服务器上的某一资源。资源通过一组HTTP头和呈现数据返回给客户端。GET请求中,永远不会包含呈现数据。

  HEAD:HEAD和GET本质是一样的,区别在于HEAD不含有呈现数据,而仅仅是HTTP头信息。有的人可能觉得这个方法没什么用,其实不是这样的。想象一个业务情景:欲判断某个资源是否存在,我们通常用GET,但这里用HEAD则意义更加明确。

  PUT:这个方法比较少见。HTML表单也不支持这个。本质上来讲,PUT和POST极为相似,都是向服务器发送数据,但它们之间有一个重要区别,PUT通常指定了资源的存放位置,而POST没有,POST的数据存放位置由服务器自己决定。举个例子:如一个用于提交博文的URL,/addBlog。如果用PUT,则提交的URL会是像这样的“/addBlog/abc123”,其中的abc123就是这个博文的地址。而如果用POST,则这个地址会在提交后由服务器告知客户端。目前大部分博客都是这样的。显然,PUT和POST用途是不一样的。具体用哪个还取决于当前业务场景。

  DELETE:删除某一个资源。基本上这个也很少见。不过还是有一些地方比如amazon的S3云服务里面就用的这个方法来删除资源。

  POST:向服务器提交数据。这个方法用途广泛,几乎目前所有的提交操作都是靠这个完成。

  OPTIONS:这个方法很有趣,但极少使用。它用于获取当前URL所支持的方法。若请求成功,则它会在HTTP头中包含一个名为“Allow”的头,值是所支持的方法,如“GET,POST”。

  TRACE:请求服务器回送收到的请求信息,主要用于测试和判断,所以是安全的。

 

  HEAD、GET、OPTIOINS和TRACE视为安全的方法,因为它们只是从服务器获得资源而不对服务器做任何修改;但是HEAD、GET、OPTIONS在用户端不安全,而POST则影响服务器上的资源。

  GET虽然不修改服务器数据,但是GET方法通过URL请求来传递用户的输入;HEAD只获得消息的头部,但是数据传入也是通过URL。 这样对客户端而言并不安全。

  TRACE方法对与服务端和用户端一定是安全的。

HTTP的请求方式get和post的区别?

  1、GET一般用于获取或者查询资源信息,这就意味着它是幂等的(对于同一个URL的多个请求返回同样的结果)和安全的(没有修改资源的状态),而POST一般用于更新资源信息,POST既不是安全的,也不是幂等的。

  2、采用GET方法时,客户端把要发送的数据添加到URL后面(就是把数据放置在HTTP协议头中,GET是通过URL提交数据的),并用“?”连接,各个变量之间用“&”连接;

   HTTP协议没有对URL长度进行限制,由于特定的浏览器及服务器对URL的长度在限制,所以传递的数据量有限;

   通过GET提交数据,用户名和密码将明文出现在URL上,因为(1)登陆页面有可能被浏览器缓存;(2)其他人查看浏览器的“历史记录”,那么别人就可以拿到你的账号和密码了。

  而POST把要传递的数据放到HTTP请求报文的消息体中;HTTP协议也没有进行大小限制,起限制作用的是服务器处理程序的能力。但是,传送的数据量比GET方法更大些;由于传递的数据在消息体中,安全性高,但其实用抓包软件(如httpwatch)进行抓包的话,可以看到传递的数据内容的。

  3、GET请求的数据会被浏览器缓存起来,会留下历史记录;而POST提交的数据不会被浏览器缓存,不会留下历史记录。

为什么HTTP是无状态的?如何保持状态(会话跟踪技术、状态管理)?

  HTTP无状态:无状态是指协议对于事务处理没有记忆能力,不能保存每次客户端提交的信息,即当服务器返回应答之后,这次事务的所有信息就都丢掉了。如果用户发来一个新的请求,服务器也无法知道它是否与上次的请求有联系。

  这里我们用一个比较熟悉的例子来解释HTTP的无状态性,如一个包含多图片的网页的浏览。步骤为:(1)建立连接,客户端发送一个请求,服务器端返回一个HTML页面(这里的页面只是一个纯文本的页面,也就是我们写的HTML代码),关闭连接;(2)浏览器解析HTML文件,遇到图片标记得到url,这时,客户端和服务器再建立连接,客户端发送一个图片请求,服务器返回图片应答,关闭连接。(这里又涉及到无状态定义:对于服务器来说,这次的请求虽然是同一个客户端的请求但是服务器还是不知道这个是之前的那个客户端,即对于事务处理没有记忆能力)。

  优点:服务器不用为每个客户端连接分配内存来记忆大量状态,也不用在客户端失去连接时去清理内存,节省服务器端资源,以更高效地去处理业务。

  缺点:缺少状态意味着如果后续处理需要前面的信息,则客户端必须重传,这样可能导致每次连接每次连接传送的数据量增大。

  针对这些缺点,可以采用会话跟踪技术来解决这个问题。把状态保存在服务器中,只发送回一个标识符,浏览器在下次提交中把这个标识符发送过来;这样,就可以定位存储在服务器上的状态信息了。

  有四种会话跟踪技术:

    •  COOKIE
    •  Session
    •  URL 重写
    •  作为隐藏域嵌入HTML表单中(隐藏表单域)

  在浏览器和服务器之间来回传递一个标识符,这就是所谓的会话(session)跟踪。来自浏览器的所有包含同一个标识符(这里是SESSIONID)的请求同属于一个会话。

  会话的有效期直到它被显式地终止为止,或者当用户在一段时间内没有动作,由服务器自动设置为过期。目前没有办法通知服务器用户已经关闭浏览器,因为在浏览器和服务器之间没有一个持久的连接,并且浏览器关闭时也不向服务器发送信息。同时,关闭浏览器通常意味着会话ID丢失,COOKIE将过期,或者注入了信息的URL将不能再使用。所以当用户再次打开浏览器的时候,服务器无法将新得到的请求与以前的会话联系起来,则只能创建一个新的会话。然而,所有与前一个会话有关的数据依然存在服务器上,直到会话过期被清除为止。

HTTP的短连接和长连接的原理

  HTTP协议既可以实现长连接,也可以实现短连接。

  在HTTP/1.0中,默认使用的是短连接。也就是说,浏览器和服务器每进行一次HTTP操作,就建立一次连接,但任务结束就中断连接。如果客户端访问的某个HTML或其他类型的web页中包含有其他的web资源,如JavaScript文件、图像文件、CSS文件等,当浏览器每遇到这样一个web资源,就会建立一个HTTP会话。HTTP1.0需要在request中增加“Connection: keep-alive”,header才能够支持长连接。

  HTTP1.0 KeepAlive支持的数据交互流程如下:

  1)Client发出request,其中该request的HTTP版本号为1.0。同时在request中包含一个header:“Connection: keep-alive”。

  2)web sever收到request中的HTTP协议为1.0及“Connection: keep-alive”就认为是一个长连接请求,其将在response的header中也增加“Conection: keep-alive”。同时不会关闭已建立的TCP连接。

  3)Client收到web server的response中包含“Connection: keep-alive”,就认为是一个长连接,不关闭TCP连接。并用该TCP连接再发送request。(跳转到1))

  但从HTTP/1.1起,默认使用长连接,用以保持连接特性。使用长连接的HTTP协议,会在请求头和响应头加入这行代码。Connection: keep-alive。

  在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的TCP链接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接(HTTP长连接利用同一个TCP连接处理多个HTTP请求和响应)。

  Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。实现长连接要客户端和服务端都支持长连接。长连接中关闭连接通过Connection:closed头部字段。如果请求或响应中的Connection被指定为closed,表示在当前请求或相应完成后将关闭TCP连接。TCP的keep-alive是检查当前TCP连接是否活着;HTTP的Keep-Alive是要让一个TCP连接活久点。

  HTTP1.1 Keep-Alive支持的数据交互流程如下:

  1)Client发出request,其中该request的HTTP版本号为1.1。

  2)web server收到request中的协议为1.1就认为是一个长连接请求,其将在response的header中也增加“Connection: keep-alive”。同时不会关闭已建立的TCP连接。

  3)Client收到 web server的response中包含“Connection:keep-alive”,就认为是一个长连接,不会关闭TCP请求,并用该TCP连接再发送request。(跳转到 1))

HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。

HTTP长连接的优点:

  1)通过开启和关闭更少的TCP连接,节约CPU时间和内存。

  2)通过减少TCP开启和关闭引起的包的数目,降低网络阻塞。

HTTP长连接的缺点:

  服务器维护一个长连接会增加开销。

HTTP短连接的优点:

  服务器不用为每个客户端连接分配内存来记忆大量状态,也不用在客户端失去连接时去清理内存,节省服务器端资源,以更高效地去处理业务。

HTTP短连接的缺点:

  如果客户请求频繁,将在TCP的建立和关闭操作上浪费时间和带宽。

HTTP的特点

  (1)支持客户端/服务器端通信模式。

  (2)简单方便快速:当客户端向服务器端发送请求时,只是简单的填写请求路径和请求方法即可,然后就可以通过浏览器或其他方式将该请求发送就行了。比较常用的请求方法有三种,分别是:GET、HEAD、POST。不同的请求方法使得客户端和服务器联系的方式各不相同。因为HTTP协议比较简单,所以HTTP服务器的程序规模相对比较小,从而使得通信的速度非常快。

  (3)灵活:HTTP协议允许客户端和服务器传输任意类型任意格式的数据对象。这些不同的类型由Content-Type标记。

  (4)无连接:无连接的含义是每次建立的连接只处理一个客户端请求。当服务器处理完客户端的请求之后,并且受到客户的反馈应答后,服务器端立即断开连接。采用这种通信方式可以大大的节省传输时间。

  (5)无状态:HTTP是无状态的协议。所谓的无状态是指协议对于请求的处理没有记忆功能。无状态意味着如果再次处理先前的信息,则这些先前的信息必须要重传,这就导致了数据量传输的增加。但是从另一方面来说,当先前的信息服务器不再使用的时候,则服务器的响应将会非常快。

HTTP的安全问题

  a、通信使用明文不加密,内容可能被窃听。

  b、不验证通信方身份,可能遭到伪装。

  c、无法验证报文完整性,可能被篡改。

  HTTPS就是HTTP加上加密处理(一般是SLL安全通信线路)+认证+完整性保护

HTTPS的作用

  • 内容加密  建立一个信息安全通道,来保证数据传输的安全;
  • 身份认证  确认网站的真实性;
  • 数据完整性  防止内容被第三方冒充或者篡改;

浏览器和服务器在基于HTTPS进行请求连接到数据传输过程中,用到哪些技术?

1、对称加密算法

  用于对真正传输的数据进行加密。

2、非对称加密

  用于在握手过程中加密生成的密码。非对称加密算法会生成公钥和私钥,公钥只能用于加密数据,因此可以随意传输,而网站的私钥用于对数据进行解密,所以网站都会非常小心地保管自己的私钥,防止泄漏。

3、散列算法

  用于验证数据的完整性。

4、数字证书

  数据证书其实就是一个小的计算机文件,其作用类似于我们的身份证、护照,用于证明身份,在SSL中,使用数字证书来证明自己的身份。

  客户端有公钥,服务器有私钥,客户端用公钥对‘对称密钥’进行加密,将加密后的对称密钥发送给服务器,服务器用私钥对其进行解密,所以客户端和服务器可用对称密钥来进行通信。公钥和私钥是用来加密密钥,而对称加密是用来加密数据,分别利用了两者的优点。

讲下HTTP协议

  主要包括HTTP建立连接的过程,持久和非持久连接,带流水与不带流水,DNS解析过程,GET和POST区别,HTTP与HTTPS的区别等。状态码,header各个字段的意义。

HTTP和Socket的区别,两个协议哪个更高效一点?

  创建socket链接时,可以指定使用的传输层协议,socket可以支持不同的传输层协议(TCP或UDP),当使用TCP协议进行连接时,该socket连接就是一个TCP连接。socket连接一旦建立,通信双方即可开始发送数据内容,直到双方连接断开。注意,同HTTP不同的是HTTP只能基于TCP,socket不仅能走TCP,而且还能走UDP,这个是socket的第一个特点。

  HTTP连接使用的是“请求-响应”的方式,不仅在请求时需要先建立连接,而且需要客户端向服务器发出请求后,服务器端才能回复数据。

  很多情况下,需要服务器端主动向客户端推送数据,保持客户端与服务器数据的实时与同步。此时若双方建立的是socket连接,服务器就可以直接将数据传送给客户端;若双方建立的是HTTP连接,则服务器需要等到客户端发送一次请求后才能将数据传回给客户端。

  socket效率高,至少不用解析HTTP报文头部一些字段。

HTTP与HTTPS的区别

  • HTTPS更安全

  HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比HTTP协议安全,所有传输的内容都经过加密,加密采用对称加密,但对称加密的密钥用服务器方的证书进行了非对称加密。HTTP是超文本传输协议,信息是明文传输,没有加密,通过抓包工具可以分析其信息内容。

  • HTTPS需要申请证书

  HTTPS协议需要到CA申请证书,一般免费证书很少,需要交费。而常见的HTTP协议则没有这一项。

  • 端口不同

  HTTP使用的是80端口,而HTTPS使用的是443端口。

  • 所在层次不同

  HTTP协议运行在TCP之上,HTTPS是运行在SSL/TLS之上的HTTP协议,SSL/TLS运行在TCP之上。

补充

HTTP断点续传的原理

  要实现断点续传下载文件,首先要了解断点续传的原理。断点续传其实就是在上一次下载断开的位置开始继续下载。HTTP协议中,可以在请求报文头中加入Range段,来表示客户机希望从何处继续下载。在以前版本中HTTP协议是不支持断点的,HTTP/1.1开始就支持了,一般断点下载时才用到Range和Content-Range实体头。

 1 例子1:
 2 GET /test.txt HTTP/1.1
 3 Accept:*/*
 4 Referer:http://192.168.1.96
 5 Accept-Language:zh-cn
 6 Accept-Encoding:gzip,deflate
 7 User-Agent:Mozilla/4.0(compatible;MSIE 6.0; Windows NT 5.2; .NET CLR 2.0.50727)
 8 Host:192.168.1.96
 9 Connection:Keep-Alive
10 
11 这表示从1024字节开始断点续传(加入了Range:bytes=1024-):
12 GET /test.txt HTTP/1.1
13 Accept:*/*
14 Referer:http://192.168.1.96
15 Accept-Language:zh-cn
16 Accept-Encoding:gzip,deflate
17 User-Agent:Mozilla/4.0(compatible;MSIE 6.0; Windows NT 5.2; .NET CLR 2.0.50727)
18 Host:192.168.1.96
19 Range:bytes=1024-         //Range:bytes=0-10000(从0编号)告诉服务器 /test.txt这个文件从1024字节开始传,前面的字节不用传了。
20 Connection:Keep-Alive
21 
22 -------------------------------------------------------------
23 
24 例子2:
25 Connection:close
26 Host:127.0.0.3
27 Accept:*/*
28 Pragma:no-cache
29 Cache-Control:no-cache
30 Referer:http://127.0.0.3/
31 User-Agent:Mozilla/4.04 [en] (Win95;I;Nav)
32 Range:bytes=5275648-
33 HTTP/1.1 206 Partial Content
34 Server:Zero Http Server/1.0
35 Date:Thu, 12 Jul 2001 11:19:40 GMT
36 Cache-Control:no-cache
37 Last-Modified:Tue, 30 Jan 2001 13:11:30 GMT
38 Content-Type:application/octet-stream
39 Content-Range:bytes 5275648-15143085/15143086
40 Content-Length:9867438
41 Connection:close

扩展:服务器断点续传文件增强验证(If-Range,If-Match)

1、用If-Range进行增强校验

  If-Rnage中的内容可以为最初收到的ETag头或者是Last-Modified中的最后修改时间。服务端在收到续传请求时,通过If-Range中的内容进行校验,看文件的内容是否发生了变化,校验一致时(文件内容没有发生变化时),返回206的续传回应;不一致时(文件内容发生了变化),服务算返回200回应,回应的内容为新的文件的全部数据。

2、用If-Match进行增强校验与Http 412问题

  If-Match:"40e04a44a997d11:0"  //第一次获取到的ETag的值

  如果服务器端的资源被修改了,那么,http请求时会发生 http 412 Precondition failed 先决条件失败,因此,我们建议使用If-Range。这样,即使文件被修改,也会以 http 200返回全部资源。

posted @ 2020-04-04 17:43  MrHH  阅读(721)  评论(0编辑  收藏  举报