62、JavaScript 网络协议

网络分层的概念

OSI 7层的网络分层

 

通用 5层网络分层

 
网络传输协议:网络数据在互联网进行传输,遵从的传输规则

传输层:TCP/UDP port端口号(确定来自哪个软件)

网络层:IP协议 确定传输给哪台电脑(IP)

数据链路层:数据信号(1.0)

物理层:数据信号->光信号。

http协议(超文本传送协议):

功能:使万维网客户程序与万维网服务器程序之间的交互遵守严格的协议。

连接方式:HTTP是一个的面向事务的应用层协议,使用TCP连接进行可靠传输。

注:事务:一系列的信息交换,而这一系列信息交换是一个不可分割的整体。要么所有的信息交换都完成,要么一次交换都不进行。
 
 
HTTP使用了面向连接的TCP作为运输层协议,保证了数据的可靠运输。

HTTP协议本身使无连接,无状态的。无状态:同一个客户第二次访问同一个服务器上的页面是,服务器的响应与第一次访问时相同。使服务器更容易支持大量的HTTP请求。

HTTP请求报文和响应报文都有以下结构:

开始行:区分请求报文和响应报文。请求报文的开始行叫做请求行包括请求方式,请求资源的URL,http版本号。响应报文的开始行叫做响应行包括http版本号,状态码,解释状态码的简单短语。最后以CR(回车)和LF(换行)结尾。
首部行:说明浏览器、服务器和报文主体的一些信息。
实体主体:请求报文一般不用这个字段,而在响应报文也可能没有这个字段

请求报文的请求行例子:GET http://www.baidu.com/index.html HTTP/1.1
响应报文的响应行的例子:HTTP/1.1 301 Moved permanently

状态码:

1**:表示通知信息。如请求收到,或正在处理
2**:表示成功。如操作成功收到,分析、接受
3**:表示重定向。完成此请求必须进一步处理
4**:表示客户的差错。请求包含一个错误语法或不能完成
5**:表示服务器的差错。服务器执行一个完全有效请求失败

100–客户必须继续发出请求

101–客户要求服务根据请求转换HTTP协议版本

200–交易成功

201–提示直到新文件的URL

202–接受和处理、但处理未完成

203–返回信息不确定或不完整

204–请求受到,但返回信息为空

205–服务器完成请求,用户代理必须复为当前已经浏览过的文件

206–服务器已经完成了部分用户的GET请求

300–请求的资源可在多处得到

301–删除请求数据

302–在其他地址发现请求数据

303–建议客户访问其他URL或访问方式

304–客户端已经执行GET,但文件未变化

305–请求的资源必须从服务器指定的地址得到

306–前一版本的HTTP中使用的代码,现行版本中不再使用

307–申明请求的资源临时性删除

400–错误请求,语法错误

401–请求授权失败

402–保留有效ChargeTo头响应

403–请求不允许

404–没有发现文件、查询或URL

405–用户在Request-line字段定义的方法不允许

406–根据用户发送的Accept,请求资源不可访问

408–客户端没有在用户指定的时间内完成请求

409–对当前资源状态,请求不能完成。

410–服务器不再有此资源且无法进一步的参考地址

411–服务器拒绝用户顶的Content-Length属性请求

412–一个或多个请求头字段在当前请求中错误

413–请求的资源大于服务器允许的大小

414–请求的资源URL长于服务器允许的长度

415–请求资源不支持请求项目的格式

416–请求包含Range氢气头字段,在当前资源范围内没有range指示值,请求也不包含If-Range请求头字段

417–服务器不满足请求Expect头字段指定的期望值,如果是代理服务器,可能时下以及服务器不能满足请求

500–服务器产生内部错误

501–服务器不支持请求的函数

502–服务器暂时不可用,又是为了防止发生系统过载

503–服务器过载或暂停维修

504–关口过载,服务器使用另一个关口来响应用户,等待事件设定值较长

505–服务器不支持或拒绝请求投中的指定HTTP版本

注:不管请求数据是否成功和失败,都会有响应值。

HTTP版本区别

HTTP/0.9
1、 第一个版本的http协议,已过时他的组成极其简单,只允许客户端发送GET这一种请求,且不支持请求头由于没有协议头,造成了http/0.9只支持一种内容,即纯文本不过网页仍然支持用HTML语言格式化,同时无法插入图片;

2、 HTTP/0.9典型的一对一,每个事务独立处理,事务结束就释放这个链接依次http/0.9传输首先要建立一个客户端到web服务器的TCP链接,由客户端发起一个请求,然后由web服务器返回页面内容,然后链接会关闭如果请求的页面不存在,也不会返回任何状态码;
HTTP/1.0
http协议的第二个版本,与第一个版本区别主要是指定版本的http协议版本。相对于http/0.9增加了下面几个特性。

1、 请求与相应支持头部;

2、 响应对象以一个响应状态码开始;

3、 响应对象不只限于文本;

4、 开始支持客户端通过POST向web服务器提交数据,支持GET、HEAD、POST方法;

5、 支持长连接(但默认使用短链接)、缓存机制以及身份认证;

HTTP/1.0缺点:每请求一个文档就要有两倍的RTT的开销。若一个主页有很多的连接对象(如图片等)需要依次进行链接,那么每一次链接下载都导致2*RTT的开销,另一个开销就是万维网和服务器每一次建立新的TCP都压迫分配缓存和变量。(非持续连接)

HTTP1.1
HTTP/1.1:万维网服务器在发送响应后仍然在一段时间内保持这条连接,使同一个客户(浏览器)和该服务器可以继续在这条链接上传送后续的HTTP请求报文和响应报文。只要是在同一个服务器传送,这条TCP链接就生效。(连续链接)

连续链接两种工作方式:非流水线方式(收到前一个响应再进行下一个响应,请求时间:n对象RTT+n文档传输时间,一个对象花费一个RTT),流水线方式(在收到前一个HTTP响应报文之前,就可以连续发送请求报文,服务器可以连续发挥报文。RTT+n*文档传输时间。客户访问的所有对象只花费一个RTT)。

连续链接: 
1、 默认是长连接;

2、 提供了范围请求功能(带宽优化):在1.0客户端只需要某个对象的一部分,而服务器返回整个对象http/1.1就会返回对象部分;

3、 提供虚拟主机的功能给(HOST域):1.0每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)1.1每个物理服务器可以存在多个虚拟主机,并且他们共享一个一个IP地址;

4、 缓存处理字段:加入一些cache的新特性,引入了实体标签,一般被称为e-tags,新增为更强的擦车-control头;

5、 错误通知的管理:新增了24个错误状态响应码如409:请求的资源与资源当前的状态发生冲突;

缺点:串行执行,一旦有一个阻塞后续的请求就无法进行(对头阻塞)。

解决:发起多个tcp链接
 

HTTP/2.0

相对于http/1.0新增了以下内容

1、 二进制分帧、HTTP/2.0的所有帧都采用二进制编码;

帧:客户端与服务器通过交换帧来通信,帧是基于这个协议的最小单位。

消息:逻辑上的HTTP消息,比如请求、夏国英等,有一个或多个帧组成。

流:流是连接中的虚拟信道,可以承载双向的消息;每个流都有一个唯一的整数标识符。

2、 多路复用:(解决http/1.0串行);

多路复用允许同时通过单一的http/2.0连接发起多重的请求响应消息。有了新的分帧机制后,http/2.0不再依赖多个TCP链接去处理更多并发的请求。每个数据流都拆分成很多互不依赖的帧(http请求),而这些帧可以交错(乱序发送),还可以分优先级。最后在在另一端根据每一帧首部的流标识符把他们重新组合起来。http/2.0链接都是持久化的,而且客户端与服务器也只需要一个链接(每个域名一个链接)即可。

3、 头部压缩:http/1.1首部带大量信息,而且每次都要重复发送http/2.0要求通讯双方各自缓存一份首部字段表,从而避免了重复传输;

4、 请求优先级:浏览器可以在发现资源是立即分派请求,指定每个流的优先级,让服务器决定最优的相应次序请求不必排队了,节省了时间,也最大限度的利用了每个连接;

5、 服务端推送;

服务端推送把客户端所需要的资源伴随着index.html一起发送到客户端,省去客户端重复请求的步骤。

http/3.0

基于UDP协议的。

1、 线头阻塞更加彻底虽然在http2.0采用多路复让数据一帧一帧的发送和接受,但是如果某一个数据有丢包,则同样会阻塞在他之后传输的流数据udp让不同报文之间真的实现相互独立;

2、 切换网络时连接保持;

基于TCP的协议,由于切换网络之后,IP会改变,因而之前的连接不肯继续保持。而基于UDP的QUIC协议,则可以内建与TCP中不同标识方法,从而在网络完成切换之后,恢复之前与服务器的连接。

TCP协议

TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。
特点:1.面向连接 2.每一条TCP连接T只能是单独连的(一对一)3.提供可靠的交付服务 4.提供全双工通信 5.面向字节流。
1、 帐目密码2.pc端网络;

如果需要传输,就先建立连接(三次握手),开始传输数据,当数据传输结束(四次挥手),就直接断开连接。如果再要进行传输,重新连接。
好处:安全准确性高面向连接

坏处:TCP协议比较耗费时间,耗费资源
应用:快递

TCP三次握手:

 
最开始服务器的TCP服务器进程先创建传输控制块TCB,准备接受客户进程的连接请求。然后服务器进程就处于LISTEN(收听状态)。

注:客户端进程先进入建立连接状态
最后一次握手意义是防止已失效的连接请求报文段突然又传送到了B。

比如出现一种异常情况:即客户端发送第一个建立连接请求报文段并没有丢失,而是在网络结点滞留了,以致延误到连接释放以后的某个时间才到达服务器。本来这是一个早已失效的报文段。但服务器收到此失效的报文段。但B收到此失效的连接请求报文段后,就误以为是客户端又发送了一次新的连接请求。于是就向客户端发送确认报文段,同意建立连接。由于A现在并没有发出建立界的请求,因此不会理会服务器的确认,也不会向服务器发送确认。于是就向客户端发送确认报文段,同意建立连接。但服务器却以为新的运输链接已经建立了,并一直等客户端发送数据。服务器的许多资源就这样白白浪费了。也就是说最后一次握手就是客户端告诉服务器,只有我确定传送报文,你再等我。不是我这次发送确认的,你就别理了。

TCP四次挥手
 
 
最开始客户端的应用进程先向其TCP发出连接释放报文段,并停止在发送数据,主动关闭TCP连接
注:服务器端先进入关闭状态

为什么客户端在时间等待状态必须等待2MSL的时间呢?这有两个理由:

1、 为了保证A发送最后一个ACK报文段就能够到达服务器这个ACK报文段有可能丢失,因而是在LAST-ACK状态的服务器收不到对已发送FIN+ACK报文段的确认服务器就会超时重传这个FIN+ACK报文段,而客户端就能够在2MSL时间内收到这个重传的FIN+ACK报文段接着A重传一次确认,重新启动2MSL计时器;

2、 防止与三次握手提到的已失效的连接请求报文段出现在本连接中客户端在发送完最后一个ACK报文段后,在经过2MSL,就可以是本链接持续的时间内所产生的所有报文段从网络中消失这样就可以是下一个新的连接中不会出现这种旧的链接请求报文段;

UDP:无连接协议

特点:1.无连接 2.尽最大努力交付 3.面向报文 4.无拥塞控制 5.支持一对一,一对多,多对一的交互通信

缺点:1.不安全 2.准确度非常低 3.经常丢包

优点:1.及时性非常高 2.消耗流量少

应用:视屏聊天