秋招准备之——计算机网络知识整理(二)

秋招复习笔记系列目录(不断更新中):

上一篇博客总结了计算机网络的物理层、数据链路层和网络层。这里继续总结运输层和应用层。因为应用层涉及到了HTTP协议,所以本博客对HTTP的介绍部分参考《图解HTTP》做了详细一点的介绍。

五、运输层

1. 概述

1.1 作用

  • 1.网络层完成了主机之间端到端的通信,但运输层完成了主机上不同应用程序(进程)之间端到端的通信
  • 2.对收到的报文进行差错检测。(网络层只是检测头部,运输层还要检测数据部分)。

1.2端口

  • 1.作用: 网络层将数据交付的主机后,区分不同应用程序以准确交付到应用程序。
  • 2.分类:
    (1)服务器使用的端口:服务器使用的端口又分为熟知端口(分配给最重要的应用程序的,如STP,SMTP等)和登记端口号(分配给普通应用的)
    (2)客户端使用的端口:数值为49152~65535,仅在客户端进程运行时才动态选择。

2.用户数据协议UDP

2.1特点

  • 无连接: 发送数据前不需要建立连接
  • 尽最大努力交付: 不保证可靠交付
  • 面向报文: 应用层的报文,UDP添加首部就交给网络层,不会对报文数据部分做改变。
  • 没有拥塞机制: 网络发生拥塞不用降低发送效率
  • 支持一对一、一对多、多对一、多对多的交互通信
  • 首部开销小

2.2 UDP首部格式

在这里插入图片描述

  • 伪首部:只在计算校验和时使用,不向上下传递
  • 源端口:发送方的端口,在需要回复时选用
  • 目的端口:接收方的端口
  • 长度:数据报的长度
  • 检验和:验证数据部分是否有错(有错丢弃)

3.传输协议TCP

3.1 特点

  • 面向连接:使用TCP协议之前,必须先建立连接
  • 点对点:一个连接只能有两个端点
  • 提供可靠交付
  • 提供全双工通信
  • 面向字节流

3.2 TCP的连接

TCP连接的端点为套接字(socket),套接字的组成为:
在这里插入图片描述每一条TCP连接唯一地被通信两端的两个套接字所确定。

3.2 TCP报文段的首部

在这里插入图片描述

  • 1.源端口和目的端口: 和UDP类似
  • 2.序号: 发送的字节的序号,每个字节都有一个编号。采用模232运算,即编号到达232后,又从0开始编号
  • 3.确认号: 期望收到对方下一个报文段的第一个数据字节的序号(如第B收到A的数据序号为1,而数据长为200字节,那确认好应该是201)。
  • 4.数据偏移: 用于计算首部长度的(因为TCP首部除20字节的确定部分外,有不确定部分)
  • 5.确认ACK: 值为1才有效,0无效。连接建立后,所有报文的ACK值必须为1
  • 6.同步SYN: 连接建立时用来同步序号,SYN=1而ACK为0时,表明是一个连接请求报文段。对方同意连接后,发送SYN=1且ACK=1的响应报文。
  • 7.终止FIN: 用来释放一个连接,当FIN为1时,表示数据已经发送完毕,要求释放连接。
  • 8.窗口: 窗口值作为接收方让发送方设置其发送窗口的依据。
    在这里插入图片描述

4.可靠传输的工作原理

4.1 基础——停止等待协议

停止等待协议发送数据时,存在三种情况:

  • 1.无差错情况:主机A向B发送一段分组,就进行等待,B收到分组后向A发送确认信息,A收到确认后继续发送下一个分组。
    在这里插入图片描述
  • 2.出现差错的情况:无论是A发送分组的过程中还是B返回确认信息的过程中出现差错,都会造成A的等待,为了防止一直等待,需要设置一个超时时间,超时后需要超时重传。
  • 3.确认丢失和确认迟到:处理如下:
    在这里插入图片描述
    停止等待的最大问题是信道利用率极低,故基于停止等待协议的基本原理,设计了连续ARQ协议和滑动窗口协议。如下,以提高信道利用率。
    在这里插入图片描述

4.2 滑动窗口协议

1.滑动窗口的组成
整个滑动窗口分为三个部分:

  • (1)已发送并收到确认的部分:这些已经发送成功且接收方的主机已处理完成
  • (2)允许发送的序号:根据接收方期望收到的序号和接收方的接受窗口以及网络情况确定的窗口部分(不能大于接收方的接受窗口值)
  • (3) 不允许发送的部分:未发送的在窗口外的部分。
    在这里插入图片描述

2.发送过程
如下图所示,发送窗口内的字节都允许被发送,接收窗口内的字节都允许被接收。
当接受窗口接受完成并交付主机后,就将滑动窗口向前(图中的右边)移动。注意,接收窗口只会对窗口内最后边(即靠近最左边)一个按序到达的字节进行确认(即图中最左边的数据)。比如下图,接收方收到了32、33,但是没有收到31,那最后一个按序到达的仍然是31。发送方得到一个字节的确认之后,就知道这个字节之前的所有字节都已经被接收了。
在这里插入图片描述
接收方接收成功后,会对接收方发送确认,比如下图31收到了,31,32,33就全部收到了,故接收方的滑动窗口会向前(右)移动(如下图)。然后发送方会给接受方发送确认报文,发送的确认报文里面,确认号变成了34,故接收方的滑动窗口也向前(右)移动。
在这里插入图片描述
按照上面的过程持续发送,直到图中的P2和P3重合,说明此时全部是已发送但未收到确认的数据。此时就需要进行超时等待,一旦超时,就需要重传。
在这里插入图片描述
3.超时重传时间的选择
TCP采用自适应算法确定超时重传时间,以适应不同的网络环境。
计算过程:设上一个报文传输的往返时间为RTT,那多次传输加权平均往返时间为:
在这里插入图片描述
α越小代表新旧RTT差别越小,越大则表示不同RTT差别越大。
有了上式,超时重传时间RTO为:
在这里插入图片描述
其中,RTTD表示RTT偏差的加权平均值。

5.TCP流量控制

流量控制就是让发送方发送数据速率不要太快,要让接收方来得及接受。通过滑动窗口机制,利用控制TCP报文首部的窗口值字段,可以很方便地进行流量控制。
在这里插入图片描述

6.TCP的拥塞控制

6.1 概述

当请求的资源总数大于可用资源(如下图),即供不应求时,会出现拥塞。
在这里插入图片描述
所谓拥塞控制就是防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不会过载。拥塞控制是一个全局的问题,而流量控制只是端到端的问题(注意区分)。拥塞控制的作用如下:
在这里插入图片描述

6.2 拥塞控制算法

1.慢开始:

  • (1)基本原理: 根据是否发生超时,发送方动态调整窗口的大小。基本原则是只要没出现拥塞,拥塞窗口就可以再增大一些,只要出现拥塞或有可能出现拥塞,就必须把拥塞窗口减小一些,缓解拥塞。
  • (2)算法
    慢开始算法:
    ①慢开始: 开始时,设置拥塞窗口值为1,能发送的报文数量是1。每次收到确认后,将 拥塞窗口值加倍,因此之后发送方能够发送的报文段数量为:2、4、8(下图中蓝色框的部分)
    ②拥塞避免: 为了防止拥塞窗口太大,当窗口值达到一定的阈值ssthresh时,窗口值每次增加1(下图中红色框部分)
    ③出现拥塞: 一旦出现超时情况,则将拥塞窗口重新设置为1,且阈值ssthresh变为原来的一半,重新开始慢开始(下图中绿色部分)
    在这里插入图片描述
    快重传和快恢复:
    快重传算法要求接收方每收到一个报文段要立即向发送方发送确认。 如下图,发送了M1、M2,接收方没收到M3,但收到M4,会马上发送对M2的确认,接收到M5,M6也会重复确认M2,当发送方收到3个重复确认后,就知道接收方确实没收到M3。 此时,对M3进行快重传。在这里插入图片描述
    这种情况下,只是丢失了个别报文段,并没有出现超时,所以没必要将拥塞窗口重新设置为1再慢开始。此时会将阈值ssthresh设为原来的一半,然后让窗口值=ssthresh,并开始拥塞避免(即拥塞窗口每次+1而不是翻倍)。如下图红框所示。
    在这里插入图片描述

7.TCP的运输连接管理

TCP的运输连接管理包含三个部分的内容:连接建立、数据传送、连接释放。

7.1 连接建立——三次握手

在这里插入图片描述

  • 第一次握手: 主机A向主机B发送连接请求,其中同步SYN=1而确认号ACK=0,选择一个初始序号seq=x,表明这是一个连接请求报文。此时客户端进入同步已发送状态。
  • 第二次握手: 主机B收到连接请求报文后,向A发送确认,此时SYN=1且ACK=1,确认号(不同于确认号ACK)为x+1,同时也选择一个初始的序号 y。此时服务器处于同步收到状态
  • 第三次握手: 主机A收到B的确认后,还要给B发送确认。此时ACK=1,确认号为y+1,自己的序号为x+1。此时A进入已建立连接状态。B收到A的确认后,也进入已建立连接状态。

为什么需要第三次握手 如果A发送的连接请求延时,A会再发送一条连接请求,此时连接建立成功。但此时如果B收到第一条连接请求,如果没有第三次握手的话,会建立连接,但这个连接是不需要的,会浪费网络资源。

7.2 连接释放——四次挥手

在这里插入图片描述

  • 第一次挥手: 主机A向主机B发送连接释放报文,此时FIN=1,A进入终止等待状态
  • 第二次挥手: 主机B收到连接释放报文后,向A发送确认,此时确认号ACK=1。B进入关闭等待状态。此时,B还能向A发送报文、
  • 第三次挥手: 当 B 确定不需要发送报文了,则B再发送连接释放报文,FIN=1。此时B进入最后确认状态,等待A的确认
  • 第四次挥手: A 收到后发出确认,进入 TIME-WAIT (终止等待)状态,等待 2 MSL(最大报文存活时间)后释放连接。B收到A的确认后,将释放连接。

为什么需要等待2MSL

客户端接收到服务器端的 FIN 报文后进入此状态,此时并不是直接进入 CLOSED 状态,还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由:

  • (1)确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文,那么就会重新发送连接释放请求报文,A 等待一段时间就是为了处理这种情况的发生。
  • (2)防止出现三次挥手中“已失效的连接请求报文段”出现在连接中。等待2MSL,就可以使本连接持续时间内所有报文段都从网络中消失。

六、应用层

1. 作用

应用进程之间进行通信,必须遵守严格的规则,应用层定义了这些规则。

2.域名系统DNS

2.1 作用

将互联网上的主机名字转换为IP地址

2.2 层级结构

域名具具有层次结构,从后往前分别为顶级域名、二级域名、三级域名等等
在这里插入图片描述
1.顶级域名
顶级域名分为三类

  • 国家顶级域名: 如cn表示中国
  • 通用顶级域名: 如edu(教育机构)、com(公司)、gov(政府部门)
  • 基础结构域名: 只有arpa一个,用于反向域名解析

2. 域名层级结构
如下所示,顶级域名由国际组织制定,二级一般由国家定,三级使用机构自己定
在这里插入图片描述

2.3 域名服务器

1.管辖范围
DNS的服务器的管辖范围以“区”为单位,而不是以“域”为单位。区是域的子集
在这里插入图片描述
2.分类

  • 根域名服务器:
  • 顶级域名服务器: 负责管理该顶级域名服务器中注册的所有二级域名
  • 权限域名服务器: 负责一个区的域名服务器
  • 本地域名服务器: 距离主机较近,域名解析时,先查同一ISP中的本地域名服务器

3.查询过程

  • 递归查询: 本地域名服务器不知道IP地址,则以DNS客户的身份,向其根域名服务器继续发出查询请求报文(即替主机继续查询),而不是让主机自己进行下一步查询。
  • 迭代查询: 当根域名服务器收到本地域名服务器发出的迭代查询请求报文时,要么返回给本地域名服务器所要查询的IP地址,要么返回给本地域名服务器下一步应当查询的域名服务器的IP地址。

3.文件传输协议FTP

3.1文件传输协议FTP

FTP的客户和服务器之间要建立两个并行的TCP连接:

  • 控制连接: 整个会话期间一直打开,处理客户端发送的请求
  • 数据连接: 用来传输数据
    在这里插入图片描述

3.2 简单文件传输协议TFTP

类似于停止等待协议,发送完一个文件块就等待对方确认。其使用UDP数据报,适用于1对多的传输。

4.万维网WWW

4.1 统一资源定位符URL

1.作用: 相当于文件名在网络范围内的扩展,用于在互联网中唯一地标志一个资源。
2.组成: 一般由以下四部分组成:
在这里插入图片描述

4.2 超文本传送协议Http

1.特点: Http使用面向连接的TCP作为运输层协议,有以下特点:

  • (1)无连接:交换Http报文之前不需要先建立HTTP连接
  • (2)无状态:第二次访问和第一次访问相同

2.传输过程
在这里插入图片描述
3.Http报文结构
Http有请求报文和响应报文两种报文:
在这里插入图片描述
请求报文:

  • 方法: 包含以下几种:
    在这里插入图片描述
  • URL: 请求资源的统一资源定位符
  • 首部行: 包含请求的其他信息,如下的一个Http报文所示:
    在这里插入图片描述

响应报文

  • 状态码: 返回请求的状态,分为5大类:
    在这里插入图片描述
    常用的状态码详解如下:
    在这里插入图片描述
  • 首部行: 附带其他的一些信息。如下图所示的一个请求报文的首部:
    在这里插入图片描述
    下图为响应报文的首部:
    在这里插入图片描述
    首部字段分为以下四类:
  • 1.通用首部字段
    在这里插入图片描述
  • 2.请求首部字段:
    在这里插入图片描述
  • 3.响应首部字段
    在这里插入图片描述
  • 4.实体首部字段
    在这里插入图片描述

4.3 在服务器上存储用户信息

1.Session
Session是存在服务器的一种用来存放用户数据的类HashTable结构。当浏览器 第一次发送请求时,服务器自动生成了一个HashTable和一个Session ID用来唯一标识这个HashTable,并将其通过响应发送到浏览器。当浏览器第二次发送请求,会将前一次服务器响应中的Session ID放在请求中一并发送到服务器上,服务器从请求中提取出Session ID,并和保存的所有Session ID进行对比,找到这个用户对应的HashTable。
2.Cookie
后台通过SetCookie将一些信息返回,浏览器收到后写入浏览器保存,在以后的访问中可以携带cookie信息,这样就能追踪用户。
Session和Cookie通常配合使用,如下图所示:
在这里插入图片描述

5.电子邮件

5.1 电子邮件系统的构成

1.用户代理:用户与电子邮件的接口,大多数情况下就是用户电脑上的一个程序,有撰写、显示、处理、通信的功能。
2.邮件服务器:必须同时能够充当客户和服务器。
3.邮件发送协议(如SMTP)和邮件读取协议(如POP3)
在这里插入图片描述

5.2 简单邮件传送协议SMTP

SMTP通信的三个阶段:
1.连接建立: 通过TCP建立连接,不能使用中间的邮件服务器。
2. 邮件传送: 先通过MAIL命令通知接受服务器,再通过RCPT命令,弄清对方是否做好接受邮件的准备。再通过DATA命令传送邮件内容。
3.连接释放: 客户端发送QUIT命令,服务器给予确认,释放连接。

5.3邮件读取协议POP3和IMAP

1.POP3
只要用户从服务器读取了邮件,就将邮件删除。后面改进后,可以不删除。
2.IMAP
用户与接收方邮件服务器建立TCP连接,用户在自己计算机上操纵服务器邮箱,就像本地操作一样。

七、网络安全

1.概述

1.1 网络攻击的种类

1. 网络攻击
网络攻击分为主动攻击和被动攻击两种:

  • 主动攻击

    • 篡改
    • 恶意程序:包括计算机病毒、蠕虫、特洛伊木马、逻辑炸弹、后门入侵、流氓软件
    • 拒绝服务DoS(DoS攻击):向某个服务器不停发送大量分组,使其不能提供正常服务,甚至瘫痪
  • 被动攻击

    • 被动攻击是一种在不影响正常数据通信的情况下,获取由原站发送的目的站的有效数据,通过监听到的有效数据,从而对网络造成间接的影响,影响所传数据的保密性,泄露数据信息,如只是被动攻击,不会对其传输造成直接的影响,不易监测。

下面是一些常见的攻击手段:

2. 因输出值转义不同引发的安全漏洞

  • (1)跨站脚本攻击XSS

    • 通过存在安全漏洞的网站注册用户的浏览器内运行非法的HTML标签或JS进行的一种攻击,具体见这篇博客:https://www.jianshu.com/p/4fcb4b411a66
    • 可能造成的影响:利用虚假输入表单骗取用户的个人信息、利用脚本窃取用户的Cookie值、显示伪造的文章或图片。
  • (2)SQL注入攻击

    • SQL注入是指针对WEB数据库,通过运行非法的SQL而产生的攻击。
      举例:
      比如说构造SQL语句的时候,正确的为:
      在这里插入图片描述
      在这里插入图片描述
      因为- -后面的会被注释,flag=1的条件就会被忽略。
  • (3)OS命令注入攻击

    • 通过Web应用,执行非法的操作系统命令达到攻击的目的,只要在能调用Shell函数的地方存在被攻击的风险
  • (4)HTTP首部注入攻击

    • 指在响应报文的HTTP首部字段内插入首部信息或主体的攻击。属于被动攻击。可能造成任意设置cookie、重定向至任意URL等问题。
  • (5) 邮件首部注入攻击

    • 攻击者通过向邮件首部To或Subject内添加任意非法内容引起的攻击,可在邮件中植入广告或病毒。
  • (6)目录遍历攻击

    • 针对本无意公开的文件目录,通过非法截断其目录路径后,达成访问目的的攻击。

3.因设置或设计上的缺陷引发的漏洞

  • (1)强制浏览:
    • 强制浏览一些原本非自愿公开的文件。对于一些非自愿公开的文件,通常通过隐藏URL的方式来保证安全,一旦泄露URL,就会造成强制浏览。
  • (2)不正确的错误消息处理
    • 通过一些错误消息,来推测信息。如通过“密码错误”的提示,可以知道用户存在,而密码错误这样的信息。
  • (3)开放重定向
    • 通过修改用户重定向的地址,诱导用户到别的网站

4.因为会话管理疏忽引发的安全漏洞

  • (1)会话劫持
    • 攻击者拿到用户的会话ID,使用此会话ID,伪装成用户,达到攻击目的。
  • (2)会话固定攻击
    • 强制用户使用攻击者指定的会话ID,属于被动攻击
  • (3)跨站点请求伪造CSRF
    • 攻击者通过设定好的陷阱,强制对已经完成认证的用户进行预期的个人信息或设定信息等某些状态的更新。比如,攻击者拿到你的身份,执行一些非法操作(如拿你的身份在评论中发表一些言论)。

1.2 安全网络需要达到的目标

保密性、端点鉴别、信息的完整性、运行的安全性

2.密码体制

2.1 对称密码体制

加密密匙与解密密匙是使用相同的密码体制。代表方法为DES,其基本原理是每64位的数据产生一个64位的密文,最后将所有结果拼接起来,得到加密结果。为了安全,有人提出了三重DES加密:先加密,再解密,再加密。
在这里插入图片描述

2.3 公匙密码体制(非对称加密)

公匙密码体制使用不同的加密密匙和解密密匙。其原理是同时生成私匙和公匙一对密匙,公匙可以在公开,私匙不公开。如A要给B发送信息,B先将公匙发给A,A用公匙对信息加密后,再发送给B,B用私匙进行解密查看数据内容。
在这里插入图片描述

3.数字签名

数字签名需要保证报文鉴别(接收者能够核实签名),报文的完整性(接收者确信报文没被更改)、不可否认(发送者不能抵赖)。其过程为A将签名用私匙加密,然后和公匙一起传输给A,A可以用公匙进行解密查看签名是否正确。
在这里插入图片描述
再对报文用不同的密匙进行加密,就能实现在数字签名的同时保密报文:
在这里插入图片描述

4.报文鉴别

鉴别的作用是验证通信的对方的确是自己所要通信的对象,而不是冒充者,并且所传送的报文是完整的,没有被别人篡改过。

4.1 报文鉴别

1.目的: 鉴别报文确实是报文发送者发送的
2.算法: 密码散列函数

  • (1) 原理:通过散列函数,得到一个固定长度的散列值。这个过程是单向的在这里插入图片描述
  • (2) 代表算法:MD5和SHA-1
  • (3) 报文鉴别中散列函数的使用
    在这里插入图片描述

4.2 实体鉴别

报文鉴别是每个报文都要鉴别,而实体鉴别只会在第一次连接的时候进行鉴别,其后发送数据时不再鉴别。
1.重放攻击和: 对于实体鉴别,入侵者直接拿到连接时候的鉴别,然后伪装成发送者,叫重放攻击
2.鉴别过程: 为了防止重放攻击,使用不重数来进行鉴别,如下所示:
在这里插入图片描述

5. 密匙分配

5.1 对称密匙分配

建立密匙分配中心。A发送明文;密匙中心产生一次一密的会话密匙KAB,并用A的公匙加密,同时也包含一个用B的公匙加密的凭据;A收到后,用私匙解密,得到票据,并将票据发送给B,B用私匙解密后确认票据,鉴别成功。
在这里插入图片描述

5.2 公匙的分配

建立认证中心CA,由认证中心颁发公匙。

6. 运输层的安全协议

6.1 组成

1.安全套接字层SSL
2.运输安全层TLS

6.2 SSL

1.原理: 在应用层和运输层之间加一个SSL子层
在这里插入图片描述
2.SSL提供的安全服务

  • (1) SSL服务器鉴别:允许客户端通过验证服务器的z证书鉴别服务器
  • (2) SSL客户鉴别:允许服务器鉴别客户身份
  • (3) SSL会话加密:对客户服务器端间发送的所有报文进行加密,并检测报文是否被篡改。

3.安全会话的实现
在这里插入图片描述

八、HTTPS

1.定义

在HTTP协议上加入加密处理和认证(使用SSL协议)等机制,形成Https。即HTTPS=HTTP+SSL。HTTPS需要完成的任务就是SSL提供的安全服务(见第七章的SSL部分),即客户端和服务端的鉴别以及报文是否被篡改的确认。

2.加密过程

通过第七部分的加密知识可知,对称加密速度快,但密匙的分发存在问题;非对称加密比较安全,但速度慢。为了平衡,HTTPS采用混合加密的方式,即先用非对称加密的方式传送对称加密的密匙,双方确认后,以后的通信都用对称加密的方式进行通信,如下:
在这里插入图片描述
但上述用非对称加密的过程存在的问题是,无法鉴别公匙的来源。此时,就采用公匙分配中介绍的,由认证机构CA来进行公匙的分配。具体过程如下:
在这里插入图片描述
通过证书机构,就能完成客户端和服务器身份鉴别的两个任务。

4. 报文完整性鉴别

除了客户端和服务端身份鉴别,HTTPS还要实现报文完整性保护,即要鉴别报文是否被篡改。SSL 提供报文摘要功能来进行报文完整性保护。
HTTP 也提供了 MD5 报文摘要功能,但不是安全的。例如报文内容被篡改之后,同时重新计算 MD5 的值,通信接收方是无法意识到发生了篡改。HTTPS 在发送数据时,会附带一种叫MAC 的报文摘要,其比HTTP的报文摘要更安全的原因是:其先用MD5或SHA-1生成报文摘要,再对报文摘要利用加密,生成数字签名,发送时,将数据和数字签名一起发送。破解数字签名的难度要远远大于HTTP中仅破解报文摘要的难度。

5. 认证

5.1 SSL客户端认证

认证步骤:

  • 1.接受到需要认证资源的请求,服务器会发送证书请求报文,要求客户端提供客户端证书
  • 2.客户端收到响应后,将客户端证书发送给服务器
  • 3.服务器验证通过后,方可领取客户端的公匙,然后开始加密通信。

5.2 基于表单认证

通过表单输入的信息,来进行认证(即通过我们输入的用户名密码进行认证)。由于基于表单的认证不收费,故通常使用基于表单的认证。为了更加安全,可以将基于表单的认证和SSL客户端认证结合起来一起使用。

6. 目前HTTP(s)存在的问题

6.1 存在的问题

尽管HTTP(s)已经在广泛使用了,但仍存在以下问题:

  • 1.一条连接只能发送一个请求
  • 2.请求只能从客户端发起,客户端不能接收除响应以外的其他指令
  • 3.请求/响应的首部未经压缩就发送,首部信息越多延迟越大
  • 4.发送冗余的首部:每次发送相同的首部浪费较多

6.2 目前的解决办法

  • Ajax: 如果不使用Ajax,那要刷新页面内容就只能重新请求一次。而Aajx实现了在网页加载完成以后,还能通过JS来发送请求。这样,请求成功以后,就可以根据请求结果来局部更新页面。Aajx可能会导致大量的请求产生,且未从根本上解决HTTP存在的问题。
  • Comt: 这是为了实现推送功能而设计的一种方法。其实现原理是,客户端请求后,服务器先响应,而是先将响应挂起。等到有推送信息的时候,再去响应。此方法会一直保持连接,会耗费较多资源。

6.3 HTTP1.1和1.0的区别

  • 长连接: HTTP1.1支持长连接,通过首部中的keep-alive来设置,通过connection: false来设置关闭连接
  • 管道化: 管道化是基于长连接实现的,管道化使得“并行传输”(本质还是串行)称为可能。比如请求一个html中包含多个图片,就可以一并将图片也请求了,这样在外面来看,就像是在并行传输。
  • 缓存处理: 包含本地缓存(强缓存)和协商缓存两个阶段,主要通过ExpiresCache-Control两个首部参数来控制,他们可以设置缓存的时间。
  • Host域: 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。此外,服务器应该接受以绝对路径标记的资源请求。
  • 断点传输: 通过请求头中的range参数进行设置

6.4 HTTP2.0

HTTP2.0主要围绕以下技术进行讨论:
在这里插入图片描述

  • ①二进制分帧: 通过在应用层和传输层之间增加一个二进制分帧层,改善传输性能。
    在这里插入图片描述
  • ②多路复用: 二进制帧的头部信息会标识自己属于哪一个流,所以这些帧是可以交错传输,然后在接收端通过帧头的信息组装成完整的数据。这样就解决了线头阻塞的问题,同时也提高了网络速度的利用率。
  • ③头部压缩: HTTP1.1中头部数据都是通过纯文本的形式发送的,通常会给每个请求增加500~800字节的负荷。HTTP2.0使用encoder来压缩头部,通讯双方各自缓存一份头部属性表,避免头部的传输
  • ④服务器推送: HTTP1.1只能客户端去请求服务器,而HTTP2.0中服务端可以向客户端推送资源。

七. WebSocket

1 简介

WebSocket是浏览器与服务器之间的全双工通信标准。建立在HTTP协议基础之上,一旦建立WebSocket连接,客户端和服务器端任意一方都可以直接向对方发送报文。

2 特点

  • 1.推送功能: 支持服务器向客服端的推送功能。
  • 2.减少通信量: 一旦建立连接,就希望一直保持连接。这样和HTTP相比,就能减少掉每次连接的开销,同时,WebSocket首部信息较少。

3.连接过程

第一次握手: 和普通HTTP相比,第一次握手时,要将Upgrade字段设置为websocket,告知服务器这是一个WebSocket连接。其次还有以下变化:
在这里插入图片描述
第二次握手: 服务器收到请求连接后,返回状态码101 Switching Protocols 的响应。
在这里插入图片描述
发送数据时,不再使用HTTP数据帧,而是使用WebSocket独有的数据帧。
在这里插入图片描述

  • 4
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

MeteorChenBo

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值