HTTP相关知识点

目录

一、HTTP协议的特点

二、一次完整的HTTP请求所经历的7个步骤

三、HTTP请求报文与响应报文格式

四、常见的HTTP相应状态码

五、常见HTTP首部字段

六、HTTP请求方法

七、GET和POST的区别

八、Cookie和Session的区别及使用

九、HTTP和HTTPS

十、HTTP1.0 HTTP 1.1 HTTP 2.0主要区别

十一、HTTP中的缓存机制

十二、基于Token的WEB后台认证机制

十三、对称加密和非对称加密

十四、静态页面和动态页面

十五、HTTPS抓包原理

十六、transfer-encoding:chunked的含义

十七、HTTP无状态、TCP有状态

十八、HTTP中的pipeline(管线化)

十九、http状态码301和302详解及区别

一、HTTP协议的特点

超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息。

1.HTTP协议是无状态的

就是说每次HTTP请求都是独立的,任何两个请求之间没有什么必然的联系。但是在实际应用当中并不是完全这样的,引入了Cookie和Session机制来关联请求。

2.多次HTTP请求

在客户端请求网页时多数情况下并不是一次请求就能成功的,服务端首先是响应HTML页面,然后浏览器收到响应之后发现HTML页面还引用了其他的资源,例如,CSS,JS文件,图片等等,还会自动发送HTTP请求这些需要的资源。现在的HTTP版本支持管道机制,可以同时请求和响应多个请求,大大提高了效率。

3.基于TCP协议

HTTP协议目的是规定客户端和服务端数据传输的格式和数据交互行为,并不负责数据传输的细节。底层是基于TCP实现的。现在使用的版本当中是默认持久连接的,也就是多次HTTP请求使用一个TCP连接。

二、一次完整的HTTP请求所经历的7个步骤

HTTP通信机制是在一次完整的HTTP通信过程中,Web浏览器与Web服务器之间将完成下列7个步骤: 

1. 建立TCP连接

在HTTP工作开始之前,Web浏览器首先要通过网络与Web服务器建立连接,该连接是通过TCP来完成的,该协议与IP协议共同构建 Internet,即著名的TCP/IP协议族,因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议,根据规则, 只有低层协议建立之后才能,才能进行更层协议的连接,因此,首先要建立TCP连接,一般TCP连接的端口号是80。

2. Web浏览器向Web服务器发送请求行

一旦建立了TCP连接,Web浏览器就会向Web服务器发送请求命令。例如:GET /sample/hello.jsp HTTP/1.1。

3. Web浏览器发送请求头

浏览器发送其请求命令之后,还要以头信息的形式向Web服务器发送一些别的信息,之后浏览器发送了一空白行来通知服务器,它已经结束了该头信息的发送。 

4. Web服务器应答 

客户机向服务器发出请求后,服务器会客户机回送应答, HTTP/1.1 200 OK ,应答的第一部分是协议的版本号和应答状态码。

5. Web服务器发送应答头

正如客户端会随同请求发送关于自身的信息一样,服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。 

6. Web服务器向浏览器发送数据 

Web服务器向浏览器发送头信息后,它会发送一个空白行来表示头信息的发送到此为结束,接着,它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。

7. Web服务器关闭TCP连接 

一般情况下,一旦Web服务器向浏览器发送了请求数据,它就要关闭TCP连接,然后如果浏览器或者服务器在其头信息加入了这行代码:

Connection:keep-alive 

TCP连接在发送后将仍然保持打开状态,于是,浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间,还节约了网络带宽。

建立TCP连接->发送请求行->发送请求头->(到达服务器)发送状态行->发送响应头->发送响应数据->断开TCP连接

三、HTTP请求报文与响应报文格式

url的组成:

统一资源定位符URL是用来表示从互联网上得到的资源位置。

URL的一般形式由以下四个部分组成:<协议>://<主机>:<端口>/<路径>  

使用HTTP的URL:http:///<主机>:<端口>/<路径>   HTTP的默认端口号是80,通常可省略。若再省略<路径>项,则URL就指到互联网上的某个主页。

请求报文包含三部分:

a、请求行:包含请求方法、URI、HTTP版本信息
b、请求首部字段
c、请求内容实体

                        

                      

GET /wxisme HTTP/1.1  
Host: www.cnblogs.com 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; zh-CN; rv:1.8.1) Gecko/20061010 Firefox/2.0  
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5  
Accept-Language: en-us,zh-cn;q=0.7,zh;q=0.3  
Accept-Encoding: gzip,deflate  
Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7  
Keep-Alive: 300  
Proxy-Connection: keep-alive  
Cookie: ASP.NET_SessionId=ey5drq45lsomio55hoydzc45
Cache-Control: max-age=0

简单来说请求报文就是由请求行、请求头、内容实体组成的,注意,每一行的末尾都有回车和换行,在内容实体和请求头之间另有一个空行。其中请求行指定的是请求方法、请求URL、协议版本;请求头是键值对的形式存在的,就是字段名:值;内容实体就是要传输的数据。

响应报文包含三部分:

a、状态行:包含HTTP版本、状态码、状态码的原因短语
b、响应首部字段
c、响应内容实体

                    

                         

HTTP/1.1 200 OK
Date: Tue, 12 Jul 2016 21:36:12 GMT
Content-Length: 563
Content-Type: text/html

<html>
    <body>
    Hello http!
    </body>
</html>

简单来说响应报文由状态行、响应首部字段(响应头)、响应实体组成,其中第一行是状态行,依次包含HTTP版本,状态码和状态短语组成;在一个回车换行之后是响应头,也是键值对的形式,字段名:值;然后会有一个空行也包含回车换行,之后是响应实体,就是要传输的数据。在上面的例子当中就是一个非常简单的HTML页面。 

四、常见的HTTP相应状态码

1XX临时响应   2XX成功   3XX重定向 4XX客户端错误 5XX服务端错误

  • 100:(继续)请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分,正在等待其余部分 
  • 101:(切换协议)请求者已要求服务器切换协议,服务器已确认并准备切换。
  • 200:请求被正常处理
  • 204:请求被受理但没有资源可以返回
  • 206:客户端只是请求资源的一部分,服务器成功处理了部分 GET 请求,响应报文中通过Content-Range指定范围  的资源。
  • 301:永久性重定向
  • 302:临时重定向
  • 303:与302状态码有相似功能,只是它希望客户端在请求一个URI的时候,能通过GET方法重定向到另一个URI上
  • 304:发送附带条件的请求时,条件不满足时返回,与重定向无关
  • 307:临时重定向,与302类似,只是强制要求使用POST方法
  • 400:请求报文语法有误,服务器无法识别
  • 401:发送的请求需要有通过HTTP认证的认证信息。另外,若之前已进行过1次请求,则表示用户认证失败
  • 403:请求的对应资源禁止被访问
  • 404:服务器无法找到对应资源
  • 500:服务器内部错误,比如web应用存在bug或者某些临时的故障
  • 502:错误网关,服务器作为网关或代理,从上游服务器收到无效响应
  • 503:服务器正忙,原因可能是服务器暂时处于超负载或正在进行停机维护
  • 504:Gateway Time-out(一般是由于程序执行时间过长导致响应超时,例如程序需要执行90秒,而nginx最大响应等待时间为30秒,这样就会出现超时。 

204状态码表示的是服务器接收的请求已经成功处理,但在返回的响应报文中不含实体的主体部分。比如:当从浏览器发出请求处理后,返回204响应,那么浏览器显示的页面不发生更新。

304状态码客户端发送附带条件的请求时,服务端允许访问资源,但因发生请求未满足条件的情况后,直接返回304 Not Modified(表示服务端资源未改变,可直接使用客户端未过期的缓冲)。附带条件的请求是指采用GET方法的请求报文中包含If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since中任一首部。

五、常见HTTP首部字段

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

Date:创建报文时间

Connection:连接的管理  1.控制不在转发给代理的首部字段;2管理持久连接

Cache-Control:缓存的控制

Transfer-Encoding:报文主体的传输编码方式

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

Host:请求资源所在服务器

Accept:可处理的媒体类型,比如文本文件、图片文件、视频文件等等

Accept-Charset:可接收的字符集

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

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

If-Match:服务器接收到附带条件的请求后,只有判断指定条件为真时,才会执行请求。

If-Modified-Since:如果请求的资源在指定的日期之后更新过,那么处理该请求。如果没有更新过,提示304 Not Modified。

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

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

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

Server:HTTP服务器的安装信息

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

Allow:资源可支持的HTTP方法

Content-Type:实体主体内对象的媒体类型

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

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

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

Content-Range:能告知客户端作为响应返回的实体的哪个部分符合范围请求。字段值以字节为单位,表示当前发送部分及整个                              实体大小

六、HTTP请求方法

请求方法是客户端用来告知服务器其动作意图的方法。就像下达命令一样。在HTTP1.1版本中支持GET、POST等近10种方法。需要注意的是方法名区分大小写,需要用大写字母。下面详细说明。

1.GET:获取资源

GET方法用来请求访问已被URI识别的资源。也就是指定了服务器处理请求之后响应的内容。

2.POST:传输实体主体

POST方法用来传输实体主体。POST与GET的区别之一就是目的不同,二者之间的区别会在文章的最后详细说明。虽然GET方法也可以传输,但是一般不用,因为GET的目的是获取,POST的目的是传输。

3.PUT:传输文件

PUT方法用来传输文件。类似FTP协议,文件内容包含在请求报文的实体中,然后请求保存到URL指定的服务器位置。

4.HEAD:获得报文首部

HEAD方法类似GET方法,但是不同的是HEAD方法不要求返回数据。用于确认URI的有效性及资源更新时间等。

5.DELETE:删除文件

DELETE方法用来删除文件,是与PUT相反的方法。DELETE方法请求URI删除指定的资源。

6.OPTIONS:询问支持的方法

因为并不是所有的服务器都支持规定的方法,为了安全有些服务器可能会禁止掉一些方法例如DELETE、PUT等。那么OPTIONS就是用来询问服务器支持的方法。

7.TRACE:追踪路径

TRACE方法是让Web服务器将之前的请求通信环回给客户端的方法。这个方法并不常用。

8.CONNECT:要求用隧道协议连接代理

CONNECT方法要求在与代理服务器通信时建立隧道,实现用隧道协议进行TCP通信。主要使用SSL/TLS协议对通信内容加密后传输。

七、GET和POST的区别

  • 从字面意思和HTTP的规范来看,GET用于获取资源信息而POST是用来更新资源信息。
  • GET提交请求的数据实体会放在URL的后面,用?来分割,参数用&连接,举个栗子:/index.html?name=wang&login=1
  • 对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
  • GET提交的数据长度是有限制的,因为URL长度有限制,具体的长度限制视浏览器而定。而POST没有。
  • GET参数通过URL传递,POST放在Request body中。
  • GET提交的数据不安全,因为参数都会暴露在URL上。
  • GET请求只能进行url编码,而POST支持多种编码方式。
  • GET请求会被浏览器主动cache,而POST不会,除非手动设置。
  • get请求参数会被完整保留在浏览历史记录里,而post中的参数不会被保留。

那么,post那么好为什么还用get?get效率高!。

大牛解答:https://www.cnblogs.com/logsharing/p/8448446.html#!comments

什么时候用GET?什么时候用POST?

1、get方式的安全性较Post方式要差些,包含机密信息的话,建议用Post数据提交方式。

2、当请求无副作用时(如进行搜索),便可使用GET方法;当请求有副作用时(如添加数据行),则用POST方法。一个比较实际的问题是:GET方法可能会产生很长的URL,或许会超过某些浏览器与服务器对URL长度的限制。

八、Cookie和Session的区别及使用

HTTP是一种无状态的协议,为了分辨链接是谁发起的,需自己去解决这个问题。不然有些情况下即使是同一个网站每打开一个页面也都要登录一下。而Session和Cookie就是为解决这个问题而提出来的两个机制。

应用场景

登录网站,今输入用户名密码登录了,第二天再打开很多情况下就直接打开了。这个时候用到的一个机制就是cookie。

session一个场景是购物车,添加了商品之后客户端处可以知道添加了哪些商品,而服务器端如何判别呢,所以也需要存储一些信息就用到了session。

为Cookie服务的首部字段

为Cookie服务的首部字段
首部字段名 说明 首部类型
Set-Cookie 开始状态管理所使用的Cookie信息 响应首部字段
Cookie 服务器接收到的Cookie信息 请求首部字段

Cookie总是保存在客户端中,按在客户端中的存储位置,可分为内存Cookie和硬盘Cookie。内存Cookie由浏览器维护,保存在内存中,浏览器关闭后就消失了,其存在时间是短暂的。硬盘Cookie保存在硬盘里,有一个过期时间,除非用户手工清理或到了过期时间,硬盘Cookie不会被删除,其存在时间是长期的。所以,按存在时间,可分为非持久Cookie和持久Cookie。

通俗讲,是访问某些网站后在本地存储的一些网站相关信息,下次访问时减少一些步骤。更准确的说法是:Cookies是服务器在本地机器上存储的小段文本并随每一个请求发送至同一服务器,是在客户端保持状态的方案。

Cookie的主要内容包括:名字,值,过期时间,路径和域。使用Fiddler抓包就可以看见。

存储形式是key, value形式。过期时间可设置的,如不设,则浏览器关掉就消失了,存储在内存当中,否则就按设置的时间来存储在硬盘上的,过期后自动清除,比方说开关机关闭再打开浏览器后他都会还存在,前者称之为Session cookie 又叫 transient cookie,后者称之为Persistent cookie 又叫 permenent cookie。路径和域就是对应的域名,a网站的cookie自然不能给b用。

Set-Cookie:status=enable;expires=Tue, 05 Jul 2014 08:22:31 GMT; => path=/;domain=.hackr.jp;

expires:Cookie的有效期,仅限于维持浏览器会话时间段内.若不明确指定则默认为浏览器关闭前为止

path:限制指定Cookie的发送范围的文件目录,若不指定则默认为文档所在的文件目录,但有办法可避开这项限制,所以对其作为安全机制不能抱有期待

domain:作为Cookie适用对象的域名,若不指定则默认为创建Cookie服务器的域名,但除了针对具体指定的多个域名发送Cookie之外,不指定domain属性显得更安全

Session

存在服务器的一种用来存放用户数据的类HashTable结构。

浏览器第一次发送请求时,服务器自动生成了一HashTable和一Session ID来唯一标识这个HashTable,并将其通过响应发送到浏览器。浏览器第二次发送请求会将前一次服务器响应中的Session ID放在请求中一并发送到服务器上,服务器从请求中提取出Session ID,并和保存的所有Session ID进行对比,找到这个用户对应的HashTable。 

一般这个值会有个时间限制,超时后毁掉这个值,默认30分钟。

当用户在应用程序的 Web页间跳转时,存储在 Session 对象中的变量不会丢失而是在整个用户会话中一直存在下去。

Session的实现方式和Cookie有一定关系。建立一个连接就生成一个session id,打开几个页面就好几个了,这里就用到了Cookie,把session id存在Cookie中,每次访问的时候将Session id带过去就可以识别了。

两者的区别

一个在客户端一个在服务端。因Cookie在客户端所以可以编辑伪造,不是十分安全。

Session过多时会消耗服务器资源,大型网站会有专门Session服务器,Cookie存在客户端没问题。

域的支持范围不一样,比方说a.com的Cookie在a.com下都能用,而www.a.com的Session在api.a.com下都不能用,解决这个问题的办法是JSONP或者跨域资源共享。

cookie与session如何联系与通信的

用户首次与Web服务器建立连接的时候,服务器会给用户分发一个 SessionID作为标识。SessionID是一个由24个字符组成的随机字符串。用户每次提交页面,浏览器都会把这个SessionID包含在 HTTP头中提交给Web服务器,这样Web服务器就能区分当前请求页面的是哪一个客户端。这个SessionID就是保存在客户端的,属于客户端Session。其实客户端Session默认是以cookie的形式来存储的。

当然我们客户端可以禁用cookie,这时候服务器端就拿不到sessionID。

另外一个办法:使用url方式存储sessionID;但是一般都不推荐使用,因为可以伪造url。

九、HTTP和HTTPS

HTTP和HTTPS的基本概念

HTTP:是互联网上应用最为广泛的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW服务器传输超文本到本地浏览器的传输协议,它可以使浏览器更加高效,使网络传输减少。

HTTPS:是以安全为目标的HTTP通道,简单讲是HTTP的安全版,即HTTP下加入SSL层,HTTPS的安全基础是SSL,因此加密的详细内容就需要SSL。

HTTPS协议的主要作用可以分为两种:一种是建立一个信息安全通道,来保证数据传输的安全;另一种就是确认网站的真实性。

HTTP与HTTPS有什么区别?

1.http是超文本传输协议,信息是明文传输,https则是具有安全性的ssl加密传输协议。

2.http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。

3.http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。

4.HTTPS在TCP三次握手阶段之后,还需要进行SSL 的handshake,协商加密使用的对称加密密钥。

5.HTTPS协议需要服务端申请证书,浏览器端安装对应的根证书。

HTTPS的缺点?

HTTPS握手阶段延时较高:由于在进行HTTP会话之前还需要进行SSL握手,因此HTTPS协议握手阶段延时增加

HTTPS部署成本高:一方面HTTPS协议需要使用证书来验证自身的安全性,所以需要购买CA证书;另一方面由于采用HTTPS协议需要进行加解密的计算,占用CPU资源较多,需要的服务器配置或数目高

HTTP为什么不安全?

http协议属于明文传输协议,交互过程以及数据传输都没有进行加密,通信双方也没有进行任何认证,通信过程非常容易遭遇劫持、监听、篡改,严重情况下,会造成恶意的流量劫持等问题,甚至造成个人隐私泄露(比如银行卡卡号和密码泄露)等严重的安全问题。

HTTPS的工作原理

客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤,如图所示。

1.客户使用https的URL访问Web服务器,要求与Web服务器建立SSL连接。

2.Web服务器收到客户端请求后,会将网站的证书信息(证书中包含公钥)传送一份给客户端。

3.客户端的浏览器与Web服务器开始协商SSL连接的安全等级,也就是信息加密的等级。

4.客户端的浏览器根据双方同意的安全等级,建立会话密钥,然后利用网站的公钥将会话密钥加密,并传送给网站。

5.Web服务器利用自己的私钥解密出会话密钥。

6.Web服务器利用会话密钥加密与客户端之间的通信。

关于证书

数字证书是数字证书在一个身份和该身份的持有者所拥有的公/私钥对之间建立了一种联系,由认证中心(CA)或者认证中心的下级认证中心颁发的。根证书是认证中心与用户建立信任关系的基础。在用户使用数字证书之前必须首先下载和安装。

客户端首先要有CA的公钥,才能够对公钥证书的正确性做出判断。

数字证书的格式普遍采用的是X.509V3国际标准,一个标准的X.509数字证书包含以下一些内容:

  • 证书的版本信息;
  • 证书的序列号,每个证书都有一个唯一的证书序列号;
  • 证书所使用的签名算法;
  • 证书的发行机构名称,命名规则一般采用X.500格式;
  • 证书的有效期,通用的证书一般采用UTC时间格式;
  • 证书所有人的名称,命名规则一般采用X.500格式;
  • 证书所有人的公开密钥;
  • 证书发行者对证书的签名。

http切换到HTTPS

这里需要将页面中所有的链接,例如js,css,图片等等链接都由http改为https。例如:http://www.baidu.com改为https://www.baidu.com

BTW,这里虽然将http切换为了https,还是建议保留http。所以我们在切换的时候可以做http和https的兼容,具体实现方式是,去掉页面链接中的http头部,这样可以自动匹配http头和https头。例如:将http://www.baidu.com改为//www.baidu.com。然后当用户从http的入口进入访问页面时,页面就是http,如果用户是从https的入口进入访问页面,页面即使https的。

HTTP

TCP/IP协议与HTTP协议

TPC/IP协议是传输层协议,主要解决数据如何在网络中传输,而HTTP是应用层协议,主要解决如何包装数据。关于TCP/IP和HTTP协议的关系,网络有一段比较容易理解的介绍:“我们在传输数据时,可以只使用(传输层)TCP/IP协议,但是那样的话,如果没有应用层,便无法识别数据内容,如果想要使传输的数据有意义,则必须使用到应用层协议,应用层协议有很多,比如HTTP、FTP、TELNET等,也可以自己定义应用层协议。WEB使用HTTP协议作应用层协议,以封装HTTP 文本信息,然后使用TCP/IP做传输层协议将它发到网络上。”

什么是长连接、短连接?

 在HTTP/1.0中,默认使用的是短连接。也就是说,浏览器和服务器每进行一次HTTP操作,就建立一次连接,但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源,如JavaScript文件、图像文件、CSS文件等;当浏览器每遇到这样一个Web资源,就会建立一个HTTP会话。

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

在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。实现长连接要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。

适用场景:

短连接:适用于网页浏览等数据刷新频度较低的场景。

长连接:适用于客户端和服务端通信频繁的场景,例如聊天室,实时游戏等。

http是无状态协议

HTTP无状态协议,是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。

HTTP协议其完整的工作过程可分为四步:

1.连接:首先客户机与服务器需要建立连接(由TCP/IP握手连接实现)。只要单击某个超级链接,HTTP的工作开始;

2.请求:建立连接后,客户机发送一个请求给服务器,请求方式的格式为:统一资源标识符(URL)、协议版本号,后边是MIME信息包括请求修饰符、客户机信息和可能的内容;

3.应答:服务器接到请求后,给予相应的响应信息,其格式为一个状态行,包括信息的协议版本号、一个成功或错误的代码,后边是MIME信息包括服务器信息、实体信息和可能的内容。客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上;

4.关闭:当应答结束后,浏览器和服务器关闭连接,以保证其他浏览器可以与服务器进行连接。

更完整的过程可能如下:

域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求,浏览器得到html代码 --> 浏览器解析html代码,并请求html代码中的资源(如js、css、图片等) --> 浏览器对页面进行渲染呈现给用户。

如果在以上过程中的某一步出现错误,那么产生错误的信息将返回到客户端,有显示屏输出。对于用户来说,这些过程是由HTTP自己完成的,用户只要用鼠标点击,等待信息显示就可以了。

十、HTTP1.0 HTTP 1.1 HTTP 2.0主要区别

转自https://blog.csdn.net/linsongbin1/article/details/54980801

HTTP1.0 HTTP 1.1主要区别

1.长连接

HTTP 1.0需要使用keep-alive参数来告知服务器端要建立一个长连接,而HTTP1.1默认支持长连接。

HTTP是基于TCP/IP协议的,创建一个TCP连接是需要经过三次握手的,有一定的开销,如果每次通讯都要重新建立连接的话,对性能有影响。因此最好能维持一个长连接,可以用个长连接来发多个请求。

2.节约带宽

HTTP 1.1支持只发送header信息(不带任何body信息),如果服务器认为客户端有权限请求服务器,则返回100,否则返回401。客户端如果接受到100,才开始把请求body发送到服务器。

这样当服务器返回401的时候,客户端就可以不用发送请求body了,节约了带宽。

另外HTTP还支持传送内容的一部分。这样当客户端已经有一部分的资源后,只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础。

3.HOST域

现在可以web server例如tomat,设置虚拟站点是非常常见的,也即是说,web server上的多个虚拟站点可以共享同一个ip和端口。

HTTP1.0是没有host域的,HTTP1.1才支持这个参数。

HTTP1.1 HTTP 2.0主要区别

1.多路复用

HTTP2.0使用了多路复用的技术,做到同一个连接并发处理多个请求,而且并发请求的数量比HTTP1.1大了好几个数量级。

当然HTTP1.1也可以多建立几个TCP连接,来支持处理更多并发的请求,但是创建TCP连接本身也是有开销的。

HTTP/2是完全多路复用的,而非有序并阻塞的——只需一个连接即可实现并行。

2.数据压缩

HTTP1.1不支持header数据的压缩,HTTP2.0使用HPACK算法对header的数据进行压缩,这样数据体积小了,在网络上传输就会更快。

3.服务器推送

意思是说,当我们对支持HTTP2.0的web server请求数据的时候,服务器会顺便把一些客户端需要的资源一起推送到客户端,免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。

服务器端推送的这些资源其实存在客户端的某处地方,客户端直接从本地加载这些资源就可以了,不用走网络,速度自然是快很多的。

十一、HTTP中的缓存机制

原文地址:https://www.cnblogs.com/chenqf/p/6386163.html

为方便大家理解,我们认为浏览器存在一个缓存数据库,用于存储缓存信息。
在客户端第一次请求数据时,此时缓存数据库中没有对应的缓存数据,需要请求服务器,服务器返回后,将数据存储至缓存数据库中。

HTTP缓存有多种规则,根据是否需要重新向服务器发起请求来分类,我将其分为两大类(强制缓存,对比缓存)。在详细介绍这两种规则之前,先通过时序图的方式,让大家对这两种规则有个简单了解。

已存在缓存数据时,仅基于强制缓存,请求数据的流程如下

已存在缓存数据时,仅基于对比缓存,请求数据的流程如下

我们可以看到两类缓存规则的不同,强制缓存如果生效,不需要再和服务器发生交互,而对比缓存不管是否生效,都需要与服务端发生交互。
两类缓存规则可以同时存在,强制缓存优先级高于对比缓存,也就是说,当执行强制缓存的规则时,如果缓存生效,直接使用缓存,不再执行对比缓存规则。

十二、基于Token的WEB后台认证机制

传统身份认证的方法:

HTTP 是一种没有状态的协议,也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端,客户端使用用户名还有密码通过了身份验证,不过下回这个客户端再发送请求时候,还得再验证一下。

解决的方法就是,当用户请求登录的时候,如果没有问题,我们在服务端生成一条记录,这个记录里可以说明一下登录的用户是谁,然后把这条记录的 ID 号发送给客户端,客户端收到以后把这个 ID 号存储在 Cookie 里,下次这个用户再向服务端发送请求的时候,可以带着这个 Cookie ,这样服务端会验证一个这个 Cookie 里的信息,看看能不能在服务端这里找到对应的记录,如果可以,说明用户已经通过了身份验证,就把用户请求的数据返回给客户端。

上面说的就是 Session,我们需要在服务端存储为登录的用户生成的 Session ,这些 Session 可能会存储在内存,磁盘,或者数据库里。我们可能需要在服务端定期的去清理过期的 Session 。

为什么会有token的出现?

首先,session的存储是需要空间的,其次,session的传递一般都是通过cookie来传递的,或者url重写的方式;而token在服务器是可以不需要存储用户的信息的,而token的传递方式也不限于cookie传递,当然,token也是可以保存起来的;

token的生成方式?

最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名,由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串,可以防止恶意第三方拼接token请求服务器)。

浏览器第一次访问服务器,根据传过来的唯一标识userId,服务端会通过一些算法,如常用的HMAC-SHA256算法,然后加一个密钥,生成一个token,然后将这个token发送给客户端;客户端将token保存起来,下次请求时,客户端只需带上这个Token前来请求数据即可,无需再次带上用户名和密码。带着token,服务器收到请求后,然后会用相同的算法和密钥去验证token,如果通过,执行业务操作,不通过,返回不通过信息;

token和session的区别?

token和session其实都是为了身份验证,session一般翻译为会话,而token更多的时候是翻译为令牌;

session服务器会保存一份,可能保存到缓存,文件,数据库;同样,session和token都是有过期时间一说,都需要去管理过期时间;

其实token与session的问题是一种时间与空间的博弈问题,session是空间换时间,而token是时间换空间。两者的选择要看具体情况而定。

虽然确实都是“客户端记录,每次访问携带”,但 token 很容易设计为自包含的,也就是说,后端不需要记录什么东西,每次一个无状态请求,每次解密验证,每次当场得出合法 /非法的结论。这一切判断依据,除了固化在 CS 两端的一些逻辑之外,整个信息是自包含的。这才是真正的无状态。 
而 sessionid ,一般都是一段随机字符串,需要到后端去检索 id 的有效性。万一服务器重启导致内存里的 session 没了呢?万一 redis 服务器挂了呢? 

方案 A :我发给你一张身份证,但只是一张写着身份证号码的纸片。你每次来办事,我去后台查一下你的 id 是不是有效。 
方案 B :我发给你一张加密的身份证,以后你只要出示这张卡片,我就知道你一定是自己人。 

十三、对称加密和非对称加密

1. 对称加密

对称加密指的就是加密和解密使用同一个秘钥,所以叫做对称加密。对称加密只有一个秘钥,作为私钥。 
常见的对称加密算法:DES,AES,3DES等等。

2. 非对称加密

非对称加密指的是:加密和解密使用不同的秘钥,一把作为公开的公钥,另一把作为私钥。公钥加密的信息,只有私钥才能解密。私钥加密的信息,只有公钥才能解密。 
常见的非对称加密算法:RSA,ECC

3. 区别

对称加密算法相比非对称加密算法来说,加解密的效率要高得多。但是缺陷在于对于秘钥的管理上,以及在非安全信道中通讯时,密钥交换的安全性不能保障。所以在实际的网络环境中,会将两者混合使用.

十四、静态页面和动态页面

静态页面

静态网页是指存放在服务器文件系统中实实在在的HTML文件。当用户在浏览器中输入页面的URL,然后回车,浏览器就会将对应的html文件下载、渲染并呈现在窗口中。早期的网站通常都是由静态页面制作的。

动态页面

动态网页是相对于静态网页而言的。当浏览器请求服务器的某个页面时,服务器根据当前时间、环境参数、数据库操作等动态的生成HTML页面,然后在发送给浏览器(后面的处理就跟静态网页一样了)。很明显,动态网页中的“动态”是指服务器端页面的动态生成,相反,“静态”则指页面是实实在在的、独立的文件。

十五、HTTPS抓包原理

在一节中,我们分析了HTTPS的安全通信过程,知道了HTTPS可以有效防止中间人攻击。但用过抓包工具的人都知道,比如Charles,Fiddler是可以抓取HTTPS请求并解密的,它们是如何做到的呢?

Charles作为一个中间人代理,当浏览器和服务器通信时,Charles接收服务器的证书,但动态生成一张证书发送给浏览器,也就是说Charles作为中间代理在浏览器和服务器之间通信,所以通信的数据可以被Charles拦截并解密。由于Charles更改了证书,浏览器校验不通过会给出安全警告,必须安装Charles的证书后才能进行正常访问。    

  1. 客户端向服务器发起HTTPS请求
  2. Charles拦截客户端的请求,伪装成客户端向服务器进行请求
  3. 服务器向“客户端”(实际上是Charles)返回服务器的CA证书
  4. Charles拦截服务器的响应,获取服务器证书公钥,然后自己制作一张证书,将服务器证书替换后发送给客户端。(这一步,Charles拿到了服务器证书的公钥)
  5. 客户端接收到“服务器”(实际上是Charles)的证书后,生成一个对称密钥,用Charles的公钥加密,发送给“服务器”(Charles)
  6. Charles拦截客户端的响应,用自己的私钥解密对称密钥,然后用服务器证书公钥加密,发送给服务器。(这一步,Charles拿到了对称密钥)
  7. 服务器用自己的私钥解密对称密钥,向“客户端”(Charles)发送响应
  8. Charles拦截服务器的响应,替换成自己的证书后发送给客户端
  9. 至此,连接建立,Charles拿到了 服务器证书的公钥 和 客户端与服务器协商的对称密钥,之后就可以解密或者修改加密的报文了。

HTTPS抓包的原理还是挺简单的,简单来说,就是Charles作为“中间人代理”,拿到了 服务器证书公钥 和 HTTPS连接的对称密钥,前提是客户端选择信任并安装Charles的CA证书,否则客户端就会“报警”并中止连接。这样看来,HTTPS还是很安全的。

十六、transfer-encoding:chunked的含义

Transfer-Encoding: chunked 表示输出的内容长度不能确定,普通的静态页面、图片之类的基本上都用不到这个。

但动态页面就有可能会用到,但我也注意到大部分asp,php,asp.net动态页面输出的时候大部分还是使用Content-Length,没有使用Transfer-Encoding: chunked。

不过如果结合:Content-Encoding: gzip 使用的时候,Transfer-Encoding: chunked还是比较有用的。

记得以前实现:Content-Encoding: gzip 输出时,先把整个压缩后的数据写到一个很大的字节数组里(如 ByteArrayOutputStream),然后得到数组大小 -> Content-Length。

如果结合Transfer-Encoding: chunked使用,就不必申请一个很大的字节数组了,可以一块一块的输出,更科学,占用资源更少。

这在http协议中也是个常见的字段,用于http传送过程的分块技术,原因是http服务器响应的报文长度经常是不可预测的,使用Content-length的实体搜捕并不是总是管用。

分块技术的意思是说,实体被分成许多的块,也就是应用层的数据,TCP在传送的过程中,不对它们做任何的解释,而是把应用层产生数据全部理解成二进制流,然后按照MSS的长度切成一分一分的,一股脑塞到tcp协议栈里面去,而具体这些二进制的数据如何做解释,需要应用层来完成,所以在这之前,一快整体应用层的数据需要等它分成的所有TCP  segment到达对方,重新组装后,应用程序才使用自己的解码方法还原它们。

十七、HTTP无状态、TCP有状态

无状态含义

无状态是指协议对于事务处理没有记忆功能。缺少状态意味着,假如后面的处理需要前面的信息,则前面的信息必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要前面信息时,应答就较快。直观地说,就是每个请求都是独立的,与前面的请求和后面的请求都是没有直接联系的。

 web=http协议+状态机制(cookies, session)+其他机制

为什么不改进http协议使之有状态

最初的http协议只是用来浏览静态文件的,无状态协议已经足够,这样实现的负担也很轻(相对来说,实现有状态的代价是很高的,要维护状态,根据状态来操作。)。随着web的发展,它需要变得有状态,但是不是就要修改http协议使之有状态呢?是不需要的。因为我们经常长时间逗留在某一个网页,然后才进入到另一个网页,如果在这两个页面之间维持状态,代价是很高的。其次,历史让http无状态,但是现在对http提出了新的要求,按照软件领域的通常做法是,保留历史经验,在http协议上再加上一层实现我们的目的(“再加上一层,你可以做任何事”)。所以引入了其他机制来实现这种有状态的连接。

详细说明

(1)IP是无状态的,它只负责将一个IP包发送到指定的IP地址上去。它不会考虑这个包与前面已经发送的包和后面的包的联系。(可能是重发包、可能是不连续包,它不管)

(2)TCP是有状态的,它通过包头中的一些控制字段(序列编码等)来表明各个包之间的关系(前后关系,重包与否等等)。所以,通过这个协议你可以做到一个可靠的传输。

(3)UDP是无状态的,它仅仅是在IP上加了Port,其他的事情什么也不干。这样它不可能做到可靠的传输,同样也不需要连接。

(4)HTTP是无状态的,它的底层协议是由状态的TCP,但是HTTP的一次完整协议动作,里面是使用有状态的TCP协议来完成的。而每次协议动作之间没有任何关系。也就是说HTTP一次完整协议动作之内的TCP是有状态的,而各个HTTP完整协议动作之间是毫无关联的。

十八、HTTP中的pipeline(管线化)

前提:支持长连接

HTTP 1.1版本支持持久连接 1.0版本不支持

与非持久连接的区别:

持久连接使客户端到服务器端连接持续有效,避免了重新建立连接。

大大减少了连接的建立以及关闭时延。HTTP连接是建立在TCP协议之上的,建立一条TCP连接需要三次握手,TCP连接关闭时需要四次挥手。这些都是需要时间的。

什么是管线化

管线化机制须通过永久连接(persistent connection)完成,仅HTTP/1.1支持此技术(HTTP/1.0不支持)

在使用持久连接的情况下,某个连接消息的传递类似于

请求1 -> 响应1 -> 请求2 -> 响应2

管线化:某个连接上的消息变成了类似这样 

请求1 -> 请求2 -> 请求3 -> 响应1 -> 响应2 -> 响应3

注意

1. 那么持久连接和管线化的区别在于:

持久连接的一个缺点是请求和响应式是顺序执行的,只有在请求1的响应收到之后,才会发送请求2,而管线化不需要等待上一次请求得到响应就可以进行下一次请求。实现并发发送请求。 

2. 只有GET和HEAD要求可以进行管线化,而POST则有所限制。

3. 初次创建连接时也不应启动管线机制,因为对方(服务器)不一定支持HTTP/1.1版本的协议。

 

十九、http状态码301和302详解及区别

详细来说,301和302状态码都表示重定向,就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址,这个地址可以从响应的Location首部中获取(用户看到的效果就是他输入的地址A瞬间变成了另一个地址B)——这是它们的共同点。他们的不同在于301表示旧地址A的资源已经被永久地移除了(这个资源不可访问了),搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址;302表示旧地址A的资源还在(仍然可以访问),这个重定向只是临时地从旧地址A跳转到地址B,搜索引擎会抓取新的内容而保存旧的网址。

为什么要进行重定向啊?

(1)网站调整(如改变网页目录结构);

(2)网页被移到一个新地址;

为什么尽量要使用301跳转?——网址劫持!

从网址A 做一个302 重定向到网址B 时,主机服务器的隐含意思是网址A 随时有可能改主意,重新显示本身的内容或转向其他的地方。大部分的搜索引擎在大部分情况下,当收到302 重定向时,一般只要去抓取目标网址就可以了,也就是说网址B。如果搜索引擎在遇到302 转向时,百分之百的都抓取目标网址B 的话,就不用担心网址URL 劫持了。问题就在于,有的时候搜索引擎,尤其是Google,并不能总是抓取目标网址。比如说,有的时候A 网址很短,但是它做了一个302 重定向到B 网址,而B 网址是一个很长的乱七八糟的URL 网址,甚至还有可能包含一些问号之类的参数。很自然的,A 网址更加用户友好,而B 网址既难看,又不用户友好。这时Google 很有可能会仍然显示网址A。由于搜索引擎排名算法只是程序而不是人,在遇到302 重定向的时候,并不能像人一样的去准确判定哪一个网址更适当,这就造成了网址URL 劫持的可能性。也就是说,一个不道德的人在他自己的网址A 做一个302 重定向到你的网址B,出于某种原因, Google 搜索结果所显示的仍然是网址A,但是所用的网页内容却是你的网址B 上的内容,这种情况就叫做网址URL 劫持。你辛辛苦苦所写的内容就这样被别人偷走了。

二十、HTTP 为什么要用TCP而不用UDP

如果用UDP,网页源文件传输后不是会错误百出嘛,浏览器解析的时候不是疯掉了,也就是说tcp比udp更加可靠、安全。假如使用udp,要解决很多问题比如丢包,流控,拥塞,重包检测,用udp实现这些的话,相当于重新写了一次tcp协议。

二十一、网关

将两个使用不同协议的网络段连接在一起的设备。

网关就好比两个房间当中的门,1个房间到另一个房间就必须通过这个门哈~在网络中指的就是两个网络不在同一网段,要到达则必须通过这道门传递信息。

发布了161 篇原创文章 · 获赞 58 · 访问量 7万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 技术黑板 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览