6.主要协议(UDP、TCP、IP、HTTP)

软件测试 专栏收录该内容
16 篇文章 2 订阅

一、IP地址

1.1 概念

互联网上的每一个主机都有一个IP地址

IPv4版本:32bit(4字节)
IPv5版本:128bit(16字节)

默认版本是IPv4版本
在这里插入图片描述
按字节分,每一字节换算成十进制

1.2 IP地址的组成(按功能分)

IP地址由2部分组成:网络标识(网络ID)、主机标识(主机ID)

 同一网段的计算机,网络ID相同

通过子网掩码(subnet mask)可以计算出网络ID:子网掩码 &(按位与) IP地址

子网掩码的作用一般用来计算网段

 按位与:和1按位与,结果是原来值;和0按位与,结果是0

示例1:
在这里插入图片描述
示例2:
在这里插入图片描述
注:主机位不能为全0或全1

 所以此网段可容纳的设备为:256 * 256 - 2

计算机和其他计算机通信前,会先判断目标主机和自己是否在同一网段

 同一网段:不需要由路由器进行转发

 不同网段:交由路由器进行转发

1.3 IP地址的分类(了解)

在这里插入图片描述
只有A\B\C类地址才能分配给主机

 主机标识为全0,表示主机所在的网段
 主机标记为全1,表示主机所在网段的全部主机(广播)
  可以尝试用ping给某个网段的全部主机发数据

1.3.1 A类地址

在这里插入图片描述
网络ID:

0不能用,127作为保留网段,其中127.0.0.1是本地环回地址(Loopback),代表本机地址

 可以分配给主机的

  第1部分的取值范围是:1~126

主机ID:

 第2、3、4部分的取值范围是:0~255

 每个A类网络能容纳的最大主机数是:256 * 256 * 256 - 2 = 2^24 - 2 = 16777214

1.3.2 B类地址

在这里插入图片描述
网络ID:

最小:128.0;最大:191.255

 可以分配给主机

主机ID:

 每个B类网络能容纳的最大主机数是:256 * 256 - 2 = 2^16 - 2 = 65534

1.3.3 C类地址

在这里插入图片描述
在这里插入图片描述

1.3.4 D、E类地址

在这里插入图片描述

1.3.5 子网掩码的CIDR表示方法

CIDR:无类别域间路由

子网掩码的CIDR表示方法:

 192.168.1.100/24,代表子网掩码有24个1,也就是255.255.255.0

 123.210.100.200/16,代表子网掩码有16个1,也就是255.255.0.0

1.4 为什么要进行子网划分?

如果需要让200台主机在同一个网段内,可以分配一个C类网段,比如:192.168.1.0/24

 供254个可用IP地址:192.168.1.1 ~ 192.168.1.254

 多出54个空闲的IP地址,这种情况不算浪费资源

如果需要让500台主机在同一个网段内,那就分配一个B类网段,比如:191.100.0.0/16

 共65534个可用IP地址:191.100.0.1 ~ 191.100.255.254

 多出65034个空闲的IP地址,这种情况属于极大的浪费资源

如何尽量避免浪费IP地址资源?
 合理进行子网划分

1.4.1 等长子网划分

概念:借用主机位作子网位,划分出多个子网

可以分为:

等长子网划分:将一个网段等分成多个子网,每个子网的可用IP地址数量是一样的

变长子网划分:每个子网的可用IP地址数量可以是不一样的

子网划分步骤:

 确定鸽子王的子网掩码长度

 确定子网中第1个、最后1个主机可用的IP地址

1.4.2 等长子网划分–等分成2个子网

在这里插入图片描述
在这里插入图片描述
A子网可以容纳的主机数:0 ~ 126–126台

IP地址为192.168.0.1 ~ 192.168.0.126

B子网可以容纳的主机数:129 ~ 254—126台

IP地址为192.168.0.129 ~ 192.168.0.254

1.4.3 等长子网划分–等分成4个子网

在这里插入图片描述
A子网主机数:1 ~ 62–62台

B子网主机数:65 ~ 126

C子网主机数:129 ~ 190

D子网主机数:193 ~ 254
在这里插入图片描述

1.4.4 等长子网划分–等分成8个子网

在这里插入图片描述
广播地址为主机部分全为1

在这里插入图片描述

1.4.5 等长子网划分–等分成4个子网的广播地址

在这里插入图片描述

1.5 变长子网划分

如果一个子网地址快的长度是原网段的(1/2)^n,那么

子网的子网掩码就是在原网段的子网掩码基础上增加n个1

不等长的子网,它们的子网掩码也不同

在这里插入图片描述
假设对192.168.0.0/24进行变长子网划分
在这里插入图片描述
思考题:

 这2台设备能正常通信么?
在这里插入图片描述
第一种计算方式:子网掩码 & IP地址 = 网段

左网段:192.168.0.0/24
右网段:192.168.0.0/16

不能通信,网络要通的话需要双方通信

1.6 超网

1.6.1 概念

 跟子网反过来,它是将多个连续的网段合并成一个更大的网段

1.6.2 合并2个网段–子网掩码左移1位

 需求:原本有200台计算机使用192.168.0.0/24网段,现在希望增加200台设备到同一网段

  200台在192.168.0.0/24网段,200台在192.168.1.0/24网段

  合并192.168.0.0/24、192.168.1.0/24为一个网段:192.168.0.0/23(子网掩码往左移动1位)
在这里插入图片描述
思考:

 192.168.0.255/23这个IP地址,可以分配给计算机使用吗?

192.168.0.255/24不能分配,是广播IP地址

在这里插入图片描述
所以,此地址可以分配给计算机使用

但是,192.168.1.255/23就不可以分配给计算机使用,是广播地址

1.6.3 合并4个网段–子网掩码左移2位

只有连续的网段才可以进行合并
在这里插入图片描述
在这里插入图片描述
思考:

 下面2个网段,能通过子网掩码向左移动1位进行合并吗?
在这里插入图片描述
 不可以,无法将192.168.2.0的网段包含进去

1.6.4 合并网段的规律

在这里插入图片描述
在这里插入图片描述
向左移动后,两个网段左边的网络号需要一致
在这里插入图片描述

1.6.5 判断一个网段是子网还是超网

首先,

看该网段的类型,是A类网络、B类网络还是C类网络?

默认情况下,A类子网掩码位数是8,B类是16,C类是24

在这里插入图片描述
如:192.168.10.10/22–C类网络左移2位,超网

191.168.10.10/18–B类网络右移2位,子网

1.7 IP地址的分配

IP地址按照分配方式,可以分为:静态IP地址、动态IP地址

静态IP地址:

 手动设置

 适用场景:不怎么挪动的台式机(如学校机房中的台式机)、服务器等

动态IP地址:

 从DHCP服务器自动获取IP地址

 适用场景:移动设备、无线设备等

二、传输层(Transport)

传输层有2个协议:

TCP,传输控制协议

UDP,用户数据报协议

2.1 TCP与UDP的区别

在这里插入图片描述
UDP应用于实时场景

2.2 UDP

2.2.1 UDP- 数据格式

UDP对应的值是17,0x11

UDP是无连接的,减少了建立和释放连接的开销

UDP尽最大能力交付,不保证可靠交付

 因此不需要维护一次复杂的参数,首部只有8个字节(TCP的首部至少20个字节)
在这里插入图片描述
UDP长度

 占16位,首部长度 + 数据长度

2.2.2 UDP - 检验和

检验和的计算内容:伪首部 + 首部 + 数据

 伪首部:尽在计算检验和时起作用,并不会传递给网络层
在这里插入图片描述

2.2.3 UDP - 端口(Port)

UDP首部中端口是占用2字节

 可以推测端口号的取值范围是:0 ~ 65535

客户端的源端口是临时开启的随机端口

防火墙可以设置开启\关闭某些端口来提高安全性

常用命令行:
在这里插入图片描述
在这里插入图片描述
 安装telnet:控制面板 - 程序 - 启用或关闭Windows功能 - 勾选“Telnet Client” - 确定

2.3 TCP

2.3.1 TCP - 数据格式

在这里插入图片描述
TCP首部长度最少是20个字节

数据偏移:

占4位,取值范围是0x0101 ~ 0x1111(5 ~ 15)

乘以4,得到的数值是首部长度

 首部长度是20 ~ 60字节

保留:

 占6位,目前全为0

2.3.2 TCP的几个要点

可靠传输

 在传输过程中,服务器会将数据分为几个包进行传输,如果其中一个包丢失,服务器会重新将丢失的包进行传输,保证客户端接收到的数据是完整的

流量控制

拥塞控制

连接管理

 建立连接

 释放连接

2.3.3 TCP - 小细节

在这里插入图片描述
有些资料中,TCP首部的保留(Reserverd)字段占3位,标志(Flags)字段占9位

 Wireshark也是如此

UDP首部中有一个16位的字段记录了整个UDP报文段的长度(首部 + 数据)

 但是,TCP首部中只有一个4位的字段记录TCP报文段的首部长度,并没有字段记录TCP报文段的数据长度

分析:

 UDP首部中占16位的长度字段是冗余的,纯粹是为了保证首部是32bit对齐

 TCP\UDP的数据长度,完全可以有IP数据包的首部推测出来

  传输层的数据长度 = 网络层的总长度 - 网络层的首部长度 - 传输层的首部长度

2.3.4 TCP - 检验和

跟UDP一样,TCP检验和的计算内容:伪首部 + 首部 + 数据

伪首部:占用12字节,尽在计算检验和时起作用,并不会传递给网络层
在这里插入图片描述

2.3.5 TCP - 标志位

URG(Urgent)-紧急位

 当URG = 1时,紧急指针字段才有效。表明当前报文段中有紧急数据,应优先尽快传送

ACK(Acknowledgment)-回应:

 当ACK = 1时,确认号字段才有效。

PSH(Push)

RST(Reset)-重置:

 当RST = 1时,表明连接中出现严重差错,必须释放连接,然后再重新建立连接

SYN(Synchronization)-建立连接:

 当SYN = 1、ACK = 0时,表明这是一个建立连接的请求

 若对方同意建立连接,则回复SYN = 1,ACK = 1

三次握手:
在这里插入图片描述
FIN(Finish)-释放连接:

 当FIN = 1时,表明数据已经发送完毕,要求释放连接

2.3.6 TCP - 序号、确认号、窗口

序号:

 占4个字节

 首先,在传输过程中的每一个字节都会有一个编号

在建立连接后,序号代表:这一次传给对方的TCP数据部分的第一个字节的编号

确认号:

 占4字节

在建立连接后,确认号代表:期望对方下一次传过来的TCP数据部分的第一个字节编号

窗口:

 占2字节

 这个字段有流量控制功能,用以告知对方下一次允许发送的数据大小(字节为单位)

2.4 TCP-可靠传输

2.4.1 停止等待ARQ协议

ARQ–自动重传请求
在这里插入图片描述
在这里插入图片描述

2.4.2 改进做法 - 连续ARQ协议 + 滑动窗口协议

在这里插入图片描述
不足窗体大小:

如果接受窗口最多能接收4个包

 但发送方只发了2个包

接收方如何确定后面还有没有2个包?

 等待一定时间后没有第3个包

 就会返回确认收到2个包给发送方

思考:

为什么选择在传输层就将数据“大卸八块”分成多个短,而不是等到网络层再分片传递给数据链路层?

 因为可以提高重传的性能

 如果在传输层不分段,一旦出现数据丢失,整个传输层的数据都得重传

 如果在传输层分了段,一旦出现数据丢失,只需要重传丢失的那些段即可

具体示例:
在这里插入图片描述
现在假设每一组数据是100字节,代表一个数据段的数据

每一组给一个编号
在这里插入图片描述

2.4.3 SACK(选择性确认)

在TCP通信过程中,如果发送序列中间某个数据包丢失(如1、2、3、4、5中的3丢失了)
TCP会通过重传最后确认的分组后续的分组(最后确认的是2,会重传3、4、5)
这样原来已经正确传输的分组也可能重复发送(如:4、5),降低了TCP性能

为了改善上述情况,发展出了SACK技术

告诉发送方哪些数据丢失,哪些数据已提前收到

使TCP只重新发送丢失的包(如3),不用发送后续所有的分组(如4、5)
在这里插入图片描述
SACK信息会放在TCP首部的选项部分

 Kind:占1字节。值为5代表这是SACK选项

 Length:占1字节,表明SACK选项一共占用多少字节

 Left Edge:占4字节,左边界

 Right Edge:占4字节,右边界
在这里插入图片描述
一对边界信息需要占用8字节,由于TCP首部的选项部分最多40字节,所以

 SACK选项最多携带4组边界信息

 SACK选项的最大占用字节数 = 4 * 8 + 2 = 34

疑问:

若有个包重传了N次还是失败,会一直持续重传到成功为止么?

 这个取决于系统的设置,比如有些系统,重传5次还未成功就会发送reset报文(RST)断开TCP连接
在这里插入图片描述

2.5 TCP-流量控制

如果接收方的缓存区满了,发送方还在疯狂发送数据

 接收方只能把收到的数据包丢掉,大量的丢包会极大的浪费网络资源

 所以要进行流量控制

2.5.1 概念

什么是流量控制?

 让发送方的发送速率不要太快,让接收方来得及接收处理

原理:

 通过确认报文中窗口字段来控制发送方的发送速率

 发送方的发送窗口大小不能超过接收方给出的窗口大小

 当发送方收到接收窗口的大小为0时,发送方就会停止发送数据
在这里插入图片描述

2.5.2 特殊情况

特殊情况:

 一开始,接收方给发送方发送了0窗口的报文段

 后面,接收方又有了一些存储空间,给发送方发送的非0窗口的报文段丢失了

 发送方的发送窗口一直为0,双方陷入僵局

解决方案:

 当发送方收到0窗口通知时,这是发送方停止发送报文

 并且同时开启一个定时器,隔一段时间就发送一个测试报文去询问接收方最新的窗口大小

 如果接收的窗口大小还是为0,则发送方再次刷新启动定时器

2.6 TCP - 拥塞控制

2.6.1 基本概念

在这里插入图片描述
拥塞控制:

 防止过多的数据注入到网络中

 避免网络中的路由器或链路过载

拥塞控制是一个全局性的过程

 涉及到所有主机和路由器

 以及与降低网络传输性能有关的所有因素

 是大家共同努力的结果

相比而言,流量控制是点对点通信的控制

几个缩写:

MSS:每个段最大的数据部分大小—在建立连接时确定

cwnd(congestion window):拥塞窗口–根据网络情况而定

rwnd(receive window):接收窗口–接收方告诉发送方

swnd(send window):发送窗口

  swnd = min(cwnd,rwnd)

2.6.2 方法1–慢开始(slow start,慢启动)

在这里插入图片描述
在这里插入图片描述
cwnd的初始值较小,然后岁数据包被接受方确认(收到一个ACK)

cwnd就成倍增长(指数级)

2.6.3 方法2–拥塞避免(congestion avoidance)

在这里插入图片描述
ssthresh(slow start threshold):慢开始阈值,cwnd达到阈值后,以线性方式增加

拥塞避免(加法增大):拥塞窗口缓慢增大,以防止网络过早出现拥塞

乘法减小:只要网络出现拥塞,把ssthresh减半,同时,执行慢开始算法(cwnd恢复到初始值)

当网络出现频繁拥塞时,ssthresh值就下降的很快

2.6.4 方法3–快速重传(fast retransmit)

接收方:

 每收到一个失序的分组后就立即发出重复确认

 使发送方及时知道有分组没有到达

 而不要等待自己发送数据时才进行确认

发送方:

 只要连续收到三个重复确认(总共4个相同的确认),就应当立即重传对方尚未收到的报文段

 而不必继续等到重传计时器到期后再重传
在这里插入图片描述

2.6.5 方法4–快速恢复(fast recovery)

当发送方连续收到三个重复确认,就执行“乘法减小”算法,把ssthresh减半

 这是为了预防网络发生拥塞

由于发送方现在认为网络很可能没有发生拥塞

 因此,与慢开始不同之处是现在不执行慢开始算法,即cwnd现在不恢复到初始值

 于是把cwnd值设置为ssthresh减半后的数值

 然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性增大

快重传 +快恢复:
在这里插入图片描述

2.6.6 发送窗口的最大值

发送窗口的最大值:swnd = min(cwnd,rwnd)

 当rwnd < cwnd时,是接收方的接受能力限制发送窗口的最大值

 当cwnd > rwnd时,则是网络的拥塞限制发送窗口的最大值

2.7 TCP-序号、确认号

SYN–同步请求建立连接
ACK–回应

2.7.1 请求建立连接

在这里插入图片描述

2.7.2 响应过程

在这里插入图片描述
发送http请求前,需要先发送建立连接请求
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
紫色:客户端给服务器发送请求
蓝色:服务器给客户端发送请求
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
第N个包的序号:前面N-1个包的总长度 + 1
在这里插入图片描述

2.7.3 序号和确认号的相对值

在这里插入图片描述
序号:是想告诉对方,现在的包发送到哪了

ACK:我已经收到多少了,请接下来该发送哪一个

2.7.4 序号和确认号的原生值

在这里插入图片描述
客户端的初始序号将来用在客户端的序号与服务器的ACK
服务器的初始序号将来用在服务器的序号与客户端的ACK

二者之间的关系:

原生值 - 初始值 = 相对值
在这里插入图片描述

2.8 TCP – 建立连接–3次握手

在这里插入图片描述

2.8.1 建立连接–状态解读

CLOSED:client处于关闭状态

LISTEN:server处于监听状态,等待client连接

SYN-RCVD:表示server接收到了SYN报文,当收到client的ACK报文后,他会进入到ESTABLISHED状态

SYN-SENT:表示client已发送到SYN报文,等待server的第2次握手

ESTABLISHED:表示连接已经建立

2.8.2 建立连接–前2次握手的特点

SYN都设置为1

数据部分的长度都为0

TCP头部的长度一般是32字节

 固定头部:20字节

 选项部分:12字节

双方会交换确认一些信息

 如:MSS、是否支持SACK、Window scale(窗口缩放系数)等

 这些数据都放在了TCP头部的选项部分中(12字节)

2.8.3 建立连接–疑问

为什么建立连接时,要进行3次握手?2次不行吗?

 主要目的:防止server端一直等待,浪费资源

如果建立连接只需要2次握手,可能会出现的情况

 假设client发出的第一个连接请求报文段,因为网络延迟,在连接释放后的某个时间才到达server

 本来这是一个早已失效的连接请求,但server收到此失效的请求后,误认为是client再次发出的一个新的连接请求

 于是,server就向client发出确认报文段,同意建立连接

 如果不采用3次握手,name只要server发出确认,新的连接就建立了

 由于现在client并没有真正想连接服务器的意愿,因此不会理理睬server的确认,也不会向server发送数据

 但server却以为新的连接已经建立,并一直等待client发来数据,这样,server的很多资源就被白白浪费掉

采用“三次握手”的办法可以防止上述现象的发生

 例如上述情况,client没有向server的确认发生确认,server由于收不到确认,就知道client并没有要求建立连接

第3次握手失败了,会怎么处理?

 此时server的状态SYN-RCVD,若等不到client的ACK,server会重新发送SYN + ACK包

 如果server多次重发SYN+ACK都等不到client的ACK,就会发送RET包,强制关闭连接
在这里插入图片描述

2.9 TCP–释放连接–4次挥手

在这里插入图片描述

2.9.1 释放连接–状态解读

FIN-WAIT-1:表示想主动关闭连接

 向对方发送了FIN报文,此时进入到FIN-WAIT-1状态

CLOSE-WAIT:表示在等待关闭

 当对方发送FIN给自己,自己会回应一个ACK报文给对方,此时则进入到CLOSE-WAIT状态

 在此状态下,需要考虑自己是否还有数据要发送给对方,如果没有,发送FIN报文给对方

FIN-WAIT-2:只要对方发送ACK确认后,主动方就会处于FIN-WAIT-2状态,然后等待对方发送FIN报文

CLOSING:一种比较罕见的例外状态

 表示你发送FIN报文后,并没有收到对方的ACK报文,反而却也收到了对方的FIN报文

  如果双方几乎在同时准备关闭连接的话,那么就出现了双方同时发送FIN报文的情况,也就会出现CLOSING状态

  表示双方都正在关闭连接

LAST-ACK:被动关闭一方在发送FIN报文后,最后等待对方的ACK报文

 当收到ACK报文后,即可进入CLOSED状态了

TIME-WAIT:表示收到了对方的FIN报文,并发出了ACK报文,就等2MSL后即可进入CLOSED状态了

 如果FIN-WAIT-1状态下,收到了对方同时带FIN标志和ACK标志的报文时

  可以直接进入到TIME-WAIT状态,而无须经过FIN-WAIT-2状态

CLOSED:关闭状态

由于有些状态的时间比较短暂,所以很难用netstat命令看到,比如SYN-RCVD、FIN-WAIT-1等
在这里插入图片描述

2.9.2 释放连接–疑问

为什么释放连接时,要进行4次挥手?

 TCP是全双工模式

 第1次挥手:当主机1发出FIN报文段时

  表示主机1告诉主机2,主机1已经没有数据要发送了,但是,此时主机1还是可以接受来自主机2的数据

 第2次挥手:当主机2返回ACK报文段时

  表示主机2已经知道主机1没有数据发送了,但是主机2还是可以发送数据到主机1的

 第3次挥手:当主机2也发送了FIN报文段时

  表示主机2告诉主机1,主机2已经没有数据要发送了

 第4次挥手:当主机1返回ACK报文段时

  表示主机1已经知道主机2没有数据发送了,随后正式断开整个TCP连接

2.9.3 释放连接–细节

TCP/IP协议栈在设计上,允许任何一方先发起断开请求,以下演示client主动要求断开

client发送ACK后,需要有个TIME-WAIT阶段,等待一段时间后,再真正关闭连接

 一般是等待2倍的MSL(最大分段生存期)

  MSL是TCP报文在Internet上的最长生存时间

  每个具体的TCP实现都必须选择一个确定的MSL值,RFC 1122建议是2分钟

如果client发送ACK后马上释放了,然后又因为网络原因,server没有收到client的ACK,server就会重发FIN

 这时可能出现的情况是:

  ①client没有任何响应,服务器那边会干等,甚至多次重发FIN,浪费资源

  ②client有个新的应用程序刚好分配了同一个端口号,新的应用程序收到FIN后马上开始执行断开连接的操作,本来它可能是想跟server建立连接的

2.9.4 释放连接–抓包

有时候在是用抓包工具时,有可能只会看到“3次”挥手

 这其实是将第2、3次挥手合并了
在这里插入图片描述
当server接收到client的FIN时,如果server后面也没有数据要发送给client了

 这时,server就可以将第2、3次挥手合并,同时告诉client两件事

  已经知道client没有数据要发

  server已经没有数据要发了
在这里插入图片描述

三、HTTP(超文本传输协议)

是互联网中应用最广泛的应用层协议之一

设计HTTP最初的目的是:提供一种发布和接收HTML页面的方法,由URI来标识具体的资源

后来用HTTP来传递的数据格式不仅仅是HTML,应用非常广泛

HTML:超文本标记语言

 用以编写网页

3.1 http工作原理

http消息结构:

一个http请求报文由请求行、请求头、空行和请求数据四部分组成
在这里插入图片描述

3.1.1请求行

请求行由请求方法字段、url字段和http协议版本字段构成

如:

 GET/index.html HTTP/1.1
在这里插入图片描述

GET请求

当点击网页上的链接或者通过浏览器的地址栏输入网页来浏览网页,使用的都是GET方式

 该方式不适合传送私密数据

POST请求

 post方法可以允许客户端给服务端提供信息较多。POST方法将请求参数封装在HTTP请求数据中,以名称/值的形式出现,可以传输大量数据,这样POST方式读传送的数据大小没有限制,也不会显示在URL中

3.1.2 请求头

在这里插入图片描述

3.1.3 空行

 最后一个请求头之后是一个空行,发送回车符和换行符,通知服务器以下不再有请求头

3.1.4 请求数据

请求数据在POST方法中使用POST方法适用于需要客户填写表单的场合。与请求数据相关的最长使用的请求头Content-Type和Content-Length

3.2 http响应

由三部分组成,分别是状态行,响应头,空行,响应正文

3.2.1 状态行

状态行通过状态码来说明所请求的资源情况
在这里插入图片描述
1xx:指示信息–表示请求已接收,急需处理

2xx:成功–表示请求已被成功接收,理解

3xx:重定向–要完成请求必须进行更近一步的操作

4xx:客户端错误–请求有语法错误或请求无法实现

5xx:服务端错误–服务器未能实现合法的请求

常见的状态码描述:

 200 OK:客户端请求成功

 400 Bad Request:客户端请求有语法错误,不能被服务器解析

 401 Unauthorized:请求未经授权,这个状态码必须和WWW-Authenticate报头域一起使用

 403 Forbidden:服务器收到请求,但是拒绝服务

 404 Not Found:请求资源不存在,例如:输入错误的URL

 500 Internal Server Error:服务器发生不可预期的错误

 503 Server Unavaliable:服务器当前不能处理客户端的请求,一段时间后可能恢复

3.3 关于http请求GET和POST的区别–面试

GET提交:请求的数据会附在url之后,以?分隔url和传输数据,多个参数用&连接。

POST提交:把提交的数据放置在是http包的包体中

GET提交的数据会在地址栏中显示出来,POST提交,地址栏不会改变

2.传输数据的大小:

http协议没有对传输的数据大小进行限制
在这里插入图片描述
3.安全性:
POST安全性比GET的安全性高

3.4 版本

在这里插入图片描述

3.5 标准

HTTP的标准:

3.6 报文格式

在这里插入图片描述
请求报文示例:
在这里插入图片描述
响应报文示例:
在这里插入图片描述

3.6.1 报文格式–整体

在这里插入图片描述
在这里插入图片描述

3.6.2 报文格式–request-line、status-line

在这里插入图片描述

3.6.3 报文格式–header-filed、message-body

在这里插入图片描述

3.7 ABNF(是BNF的修改、增强版)

在RFC 5234中表明:ABNF用作internet中通信协议的定义语言

ABNF是最严谨的HTTP报文格式描述形式,脱离ABNF谈论HTTP报文格式,往往都是片面、不严谨的

3.7.1 ABNF–核心规则

在这里插入图片描述

3.8 URL的编码

URL中一旦出现了一些特殊字符(如中文,空格),需要进行编码

 在浏览器地址栏输入URL时,是采用UTF-8进行编码
在这里插入图片描述

3.9 Xshell + telnet

Xshell(安全终端模拟软件),在Xshell中使用telnet

telnet命令:

 可以直接面向HTTP报文与服务器交互

 可以更清晰、直观地看到请求报文、响应报文的内容

 可以检验请求报文格式的正确与否

3.10 请求方法

8种请求方法:

GET、HEAD、POST、PUT、DELETE、CONNECT、OPTIONS、TRACE

GET:常用于读取的操作,请求参数直接拼接在URL的后面(浏览器对URL是有长度限制的)

POST:常用于添加、修改、删除的操作,请求参数可以放到请求体中(没有大小限制)

HEAD:请求得到与GET请求相同的响应,但没有响应体

&emxp;使用场景举例:在下载一个大文件前,先获取其大小,再决定是否要下载,以此可以节约带宽资源

OPTIONS:用于获取目的资源所支持的通信选项,如,服务器支持的请求方法

&emxp;OPTIONS * HTTP/1.1

PUT:用于对已存在的资源进行整体覆盖

PATCH:用于对资源进行部分修改(资源不存在,会创建新的资源)

DELETE:用于删除指定的资源

TRACE:请求服务器回显其收到的请求信息,主要用于HTTP请求的测试或诊断

CONNECT:可以开启一个客户端与所请求资源之间的双向沟通的通道,他可以用来创建隧道(tunnel)

&emxp;可以用来访问采用了SSL(HTTPS)协议的站点

3.11 头部字段(Header Field)

头部字段可以分为4中类型:

请求头字段:

&emxp;有关要获取的资源或客户端本身信息的消息头

响应头字段:

&emxp;有关响应的补充信息,如,服务器本身(名称和版本等)的消息头

实体头字段:

&emxp;有关实体主体的更多信息,如,主体长度(Content-Length)或其MIME类型

通用头字段:

&emxp;同时适用于请求和响应信息,但与消息主体无关的消息头

3.11.1 请求头字段

在这里插入图片描述
在这里插入图片描述
q值越大,表示优先级越高
如果不指定q值,默认是1.0(1.0是最大值)
在这里插入图片描述

3.11.2 响应头字段

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

3.11.3 状态码(Status Code)

状态码用来指示HTTP请求是否成功完成

状态码可以分为5类:

 信息响应:100 ~ 199

 成功响应:200 ~ 299

 重定向:300 ~ 399

 客户端错误:400 ~ 499

 服务器错误:500 ~ 599

常见状态码:

100 Continue:

 请求的初始部分已经被服务器收到,并且没有被服务器拒绝,客户端应该继续发送剩余的请求,如果请求已经完成,就忽略这个响应

 允许客户端发送带请求体的请求前,判断服务器是否愿意接收请求(服务器通过请求头判断)

 在某些情况下,如果服务器在不看请求体就拒绝请求时,客户端就发送请求体是不恰当的或低效的

200 OK:请求成功

302 Found:请求的资源被暂时移动到了由Location头部指定的URL上

304 Not Modified:说明无需再次传输请求的内容,也就是说可以使用缓存的内容

400 Bad Request:由于语法无效,服务器无法理解该请求

401 Unauthorized:由于缺乏目标资源要求的身份验证凭证

403 Forbidden:服务器端有能力处理该请求,但是拒绝授权访问

404 Not Found:服务器端无法找到所请求的资源

405 Method Not Allowed:服务器禁止了使用当前HTTP方法的请求

406 Not Acceptable:服务器端无法提供与Accept-Charset以及Accept-Language指定的值相匹配的响应

408 Request Timeout:服务器想要将没有在使用的连接关闭

 一些服务器会在空闲连接上发送此消息,即便是在客户端没有发送任何请求的情况下

500 Internal Server Error:所请求的服务器遇到意外的情况并阻止其执行请求

501 Not Implemented:请求的方法不被服务器支持,因此无法被处理

 服务器必须支持的方法(即不会返回这个状态码的方法)。只有GET和HEAD

502 Bad Gateway:作为网关或代理角色的服务器,从上游服务器(如tomcat)中接收到的响应是无效的

503 Service Unavailable:服务器尚未处于可以接受请求的状态

 通常造成这种情况的原因是由于服务器停机维护或已超载

3.12 form提交

3.12.1 form提交–常用属性

action:请求的URI

 URL比较完整,无需URL,使用URI相对路径即可

method:请求方法(GET、POST)

enctype:POST请求时,请求体的编码方式

 application/x-www-form-urlencoded(默认值)

  用&分割参数,用=分隔键和值,字符用URL编码方式进行编码

 multipart/form-data

  文件上传时必须使用这种编码方式

3.12.2 form提交–multipart/form-data

请求头:
在这里插入图片描述
在这里插入图片描述

3.13 跨域

3.13.1 同源策略

浏览器有个同源策略(Same-Origin Policy)

 它规定了:默认情况下,AJAX请求只能发送给同源的URL

 同源是指3个相同:协议、域名(IP)、端口
在这里插入图片描述
img、script、link、iframe、video、audio等标签不受同源策略的约束

3.13.2 跨域资源共享

解决AJAX跨域请求的常用方法:

 CORS(Cross-Origin Resource Sharing),跨域资源共享

CORS的实现需要客户端和服务器同时支持:

 客户端

  所有的浏览器都支持(IE至少是IE10版本)

 服务器

  需要返回相应的响应头(如Access-Control-Allow-Origin)

  告知浏览器这是一个允许跨域访问的请求

3.14 Cookie、Session

Cookie:

 在客户端(浏览器)存储一些数据,存储到本地磁盘(硬盘)

 服务器可以返回Cookie交给客户端去存储

默认有效时间是30分钟

Session:

 在服务器存储一些数据,存储到内存中

request.getSession()的执行流程:

 ①如果request没有带JSESSIONID,就会创建新的Session对象

 ②如果request带了JSESSIONID,就会返回对应的Session对象
在这里插入图片描述

3.15 代理服务器(Proxy Server)

在这里插入图片描述
特点:

 本身不生产内容

 处于中间位置转发上下游的请求和响应

  面向下游的客户端:它是服务器

  面向上游的服务器:它是客户端

3.15.1 正向代理、反向代理

正向代理:代理的对象是客户端

反向代理:代理的对象是服务器
在这里插入图片描述
在这里插入图片描述
正向代理的作用:

 隐藏客户端身份

 绕过防火墙(突破访问限制)

 Internet访问控制

 数据过滤
在这里插入图片描述
反向代理的作用:

 隐藏服务器身份

 安全防护

 负载均衡
在这里插入图片描述

3.15.2 抓包工具的原理

Fiddler、Charles等抓包工具的原理:在客户端启动了正向代理服务
在这里插入图片描述
注:
 Wireshark的原理是:通过底层驱动,拦截网卡上流过的数据

3.15.3 代理服务器–相关的头部字段

Via:追加经过的每一台代理服务器的主机名(或域名)
X-Forwarded-For:追加请求方的IP地址
X-Real-IP:客户端的真实IP地址

如:
在这里插入图片描述
①:

 X-Forwarded-For:14.14.14.14
 X-Real-IP:14.14.14.14
 Via:proxy1

②:

 X-Forwarded-For:14.14.14.14,220.11.11.11
 X-Real-IP:14.14.14.14
 Via:proxy1,proxy2

③:

 Via:proxy2

④:

 Via:proxy2,proxy1

3.16 CDN(内容分发网络)

利用最靠近每位用户的服务器,更快更可靠地将音乐、图片、视频等资源文件(一般是静态资源)传递给用户

以前:
在这里插入图片描述
现在:
在这里插入图片描述

3.16.1 使用CDN前后

在这里插入图片描述
CDN运营商在全国、乃至全球的各个大枢纽城市都建立了机房

部署了大量拥有高存储高带宽的节点,构建了一个跨运营商、跨地域的专用网络

内容所有者向CDN运营商支付费用,CDN将其内容支付给最终用户

3.16.2 使用CDN前

在这里插入图片描述

3.16.3使用CDN后

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

3.16.4 CDN–使用举例

使用CDN引入jQuery
在这里插入图片描述
在这里插入图片描述

  • 2
    点赞
  • 0
    评论
  • 1
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 数字20 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值