[toc]
网络原理
- 介绍TCP三次握手?
- socket编程中,何时进行三次握手?如何用socket发送数据?
- HTTP协议中request和response有哪些数据组成部分?
- 在浏览器输入URL到页面加载发生了什么?
- HTTP断点续传;
- HTTP中间人攻击;(重点)
- HTTPS实现原理;(加密通信原理)
- HTTPS中间人攻击;
- DNS劫持;
http
超文本传输协议(HTTP,HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的 WWW 文件都必须遵守这个标准。
http版本区别
HTTP1.0和HTTP1.1的区别
1.1 长连接(Persistent Connection)
1.2 节约带宽
1.3 HOST域
1.4 缓存处理
1.5 错误通知的管理
HTTP1.1和HTTP2.0的区别
2.1 多路复用
2.2 头部数据压缩
2.3 服务器推送
http htpps
HTTP 与 HTTPS 区别?
-
HTTP
是超文本传输协议,信息是明文传输
,存在安全风险的问题。HTTPS
解决了HTTP
不安全的缺陷,在TCP
与HTTP
之间加入了SSL/TLS
协议,保证报文能够加密传输
。 -
HTTP连接
建立相对简单,TCP三次握手之后
可进行HTTP传输
。而HTTPS
在三次握手之后
,还要进行SSL/TLS握手
过程,才可以进入加密传输
。 -
HTTP
的端口号是80
,HTTPS
端口号是443
. -
HTTPS
需要向CA(证书权威机构)
申请数字证书,保证服务器是可信
的。
SSL/TSL
(网上的图)
HTTPS
- HTTPS和HTTP的区别
HTTPS协议 = HTTP协议 + SSL/TLS协议
SSL的全称是Secure Sockets Layer,即安全套接层协议,是为网络通信提供安全及数据完整性的一种安全协议。TLS的全称是Transport Layer Security,即安全传输层协议。
即HTTPS是安全的HTTP。
-
HTTPS的连接建立流程
HTTPS为了兼顾安全与效率,同时使用了对称加密和非对称加密。在传输的过程中会涉及到三个密钥:- 服务器端的公钥和私钥,用来进行非对称加密
- 客户端生成的随机密钥,用来进行对称加密
非对称加密
RSA
对称加密
- 欧拉函数
AES CBC密码分组链接模式。使用一个密钥
和一个初始化向量[IV]
对数据执行加密。
密码分组链接模式。使用一个密钥和一个初始化向量[IV]对数据执行加密。
1、客户端访问HTTPS连接。
客户端会把安全协议版本号
、客户端支持的加密算法
列表、随机数C
发给服务端。
2、服务端发送证书给客户端
服务端接收密钥算法配件后,会和自己支持的加密算法列表进行比对,如果不符合,则断开连接。否则,服务端会在该算法列表中,选择一种对称算法(如AES
)、一种公钥算法(如具有特定秘钥长度的RSA
)和一种MAC算法
发给客户端。
服务器端有一个密钥对
,即公钥
和私钥
,是用来进行非对称加密
使用的,服务器端保存着私钥
,不能将其泄露,公钥
可以发送给任何人。
在发送加密算法的同时还会把数字证书
和随机数S
发送给客户端
3、客户端验证server证书
会对server公钥
进行检查,验证其合法性,如果发现发现公钥有问题,那么HTTPS
传输就无法继续。
4、客户端组装会话秘钥
如果公钥合格,那么客户端会用服务器公钥来生成一个前主秘钥(Pre-Master Secret,PMS),并通过该前主秘钥和随机数C、S来组装成会话秘钥
5、客户端将前主秘钥加密发送给服务端
是通过服务端的公钥来对前主秘钥进行非对称加密,发送给服务端
6、服务端通过私钥解密得到前主秘钥
服务端接收到加密信息后,用私钥解密得到主秘钥。
7、服务端组装会话秘钥
服务端通过前主秘钥和随机数C、S来组装会话秘钥。
至此,服务端和客户端都已经知道了用于此次会话的主秘钥。
8、数据传输
客户端收到服务器发送来的密文
,用客户端密钥对其进行对称解密
,得到服务器发送的数据
。
同理,服务端收到客户端发送来的密文
,用服务端密钥对其进行对称解
密,得到客户端发送的数据
。
介绍TCP三次握手
TCP UDP
网络协议
是每个前端工程师都必须要掌握的知识,TCP/IP
中有两个具有代表性的传输层协议,分别是 TCP
和 UDP
,本文将介绍下这两者以及它们之间的区别。
TCP/IP网络模型
计算机与网络设备要相互通信,双方就必须基于相同的方法。比如,如何探测到通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要事先确定
。不同的硬件、操作系统之间的通信,所有的这一切都需要一种规则
。而我们就把这种规则称为协议(protocol
)。
TCP/IP
是互联网相关的各类协议族的总称,比如:TCP,UDP,IP,FTP,HTTP,ICMP,SMTP
等都属于 TCP/IP
族内的协议
。
TCP/IP
模型是互联网的基础,它是一系列网络协议的总称。这些协议可以划分为四层
,分别为链路层、网络层、传输层和应用层
。
-
链路层
:负责封装和解封装IP
报文,发送和接受ARP/RARP
报文等。 -
网络层
:负责路由以及把分组报文发送给目标网络或主机。 -
传输层
:负责对报文进行分组和重组,并以TCP
或UDP
协议格式封装报文。 -
应用层
:负责向用户提供应用程序,比如HTTP、FTP、Telnet、DNS、SMTP
等。
在网络体系结构
中网络通信的建立必须是在通信双方
的对等层进行,不能交错。 在整个数据传输过程中,数据在发送端时经过各层时都要附加上相应层的协议头
和协议尾
(仅数据链路层需要封装协议尾)部分,也就是要对数据进行协议封装,以标识对应层所用的通信协议。接下去介绍TCP/IP
中有两个具有代表性的传输层协议----TCP
和 UDP
。
UDP
UDP
协议全称是用户数据报协议,在网络中它与TCP
协议一样用于处理数据包,是一种无连接的协议。在OSI
模型中,在第四层——传输层,处于IP协议
的上一层。UDP
有不提供数据包分组、组装和不能对数据包进行排序的缺点,也就是说,当报文发送之后,是无法得知
其是否安全完整到达的。
它有以下几个特点:
- 面向无连接
首先 UDP
是不需要和 TCP
一样在发送数据前进行三次握手建立连接的,想发数据就可以开始发送了。并且也只是数据报文的搬运工,不会对数据报文进行任何拆分和拼接操作。
具体来说就是:
- 在
发送端
,应用层将数据传递给传输层的UDP
协议,UDP
只会给数据增加一个UDP
头标识下是UDP
协议,然后就传递给网络层了 - 在
接收端
,网络层将数据传递给传输层,UDP
只去除IP
报文头就传递给应用层,不会任何拼接操作.
- 有单播,多播,广播的功能
UDP
不止支持一对一的传输方式,同样支持一对多
,多对多
,多对一
的方式,也就是说 UDP
提供了单播,多播,广播的功能。
- UDP是面向报文的
发送方的UDP
对应用程序交下来的报文,在添加首部后就向下交付IP
层。UDP
对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。因此,应用程序必须选择合适大小的报文
.
- 不可靠性
首先不可靠性
体现在无连接上,通信都不需要建立连接,想发就发,这样的情况肯定不可靠。
并且收到什么数据就传递什么数据,并且也不会备份数据,发送数据也不会关心对方是否已经正确接收到数据了。
再者网络环境时好时坏,但是 UDP
因为没有拥塞控制,一直会以恒定的速度发送数据。即使网络条件不好,也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包,但是优点也很明显,在某些实时性要求高的场景(比如电话会议)就需要使用 UDP
而不是 TCP
。
从上图可以得知,UDP
只会把想发的数据报文一股脑的丢给对方,并不在意数据有无安全完整到达。
- 头部开销小,传输数据报文时是很高效的
UDP
头部包含了以下几个数据:
- 两个
十六位
的端口号,分别为源端口
(可选字段)和目标端口
- 整个数据报文的长度
- 整个数据报文的检验和(
IPv4
可选 字段),该字段用于发现头部信息和数据中的错误
因此 UDP
的头部开销小,只有八字节,相比 TCP
的至少二十字节
要少得多,在传输数据报文时是很高效的.
TCP
当一台计算机想要与另一台计算机通讯时,两台计算机之间的通信需要畅通且可靠,这样才能保证正确收发数据。
TCP协议
全称是传输控制协议
是一种面向连接的、可靠的、基于字节流的传输层通信协议
,由 IETF
的RFC 793
定义。TCP
是面向连接的、可靠的流协议。流就是指不间断的数据结构,你可以把它想象成排水管中的水流。
TCP连接过程
如下图所示,可以看到建立一个TCP
连接的过程为(三次握手的过程):
- 第一次握手
客户端向服务端发送连接请求报文段
。该报文段中包含自身的数据通讯初始序号。请求发送后,客户端便进入 SYN-SENT 状态。
- 第二次握手
服务端收到连接请求报文段后
,如果同意连接,则会发送一个应答,该应答中也会包含自身的数据通讯初始序号,发送完成后便进入 SYN-RECEIVED
状态。
- 第三次握手
当客户端收到连接同意的应答后
,还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED
状态,服务端收到这个应答后也进入 ESTABLISHED
状态,此时连接建立成功。
- 这里可能大家会有个疑惑:为什么
TCP
建立连接需要三次握手,而不是两次?
这是因为这是为了防止出现失效的连接请求报文段被服务端接收的情况,从而产生错误。
假想一下,如果我们去掉了第三次呢?
因为我们不进行第三次握手,所以在S对C的请求进行回应(第二次握手)后,就会理所当然的认为连接已建立,而如果C并没有收到S的回应呢?此时,C仍认为连接未建立,S会对已建立的连接保存必要的资源,如果大量的这种情况,S会崩溃。
TCP断开链接
TCP
是全双工的,在断开连接时两端都需要发送 FIN
和 ACK
。
- 第一次握手
若客户端 A
认为数据发送完成,则它需要向服务端B
发送连接释放请求。
- 第二次握手
B
收到连接释放请求后,会告诉应用层要释放 TCP
链接。然后会发送ACK
包,并进入CLOSE_WAIT
状态,此时表明A
到B
的连接已经释放,不再接收 A
发的数据了。但是因为 TCP
连接是双向的,所以 B
仍旧可以发送数据给 A
。
- 第三次握手
B 如果此时还有没发完的数据会继续发送,完毕后会向 A
发送连接释放请求,然后 B
便进入 LAST-ACK
状态。
- 第四次握手
A 收到释放请求后,向 B
发送确认应答,此时A
进入 TIME-WAIT
状态。该状态会持续 2MSL
(最大段生存期,指报文段在网络中生存的时间,超时会被抛弃) 时间,若该时间段内没有B
的重发请求的话,就进入 CLOSED
状态。当 B
收到确认应答后,也便进入 CLOSED
状态。
TCP协议的特点
- 面向连接
面向连接,是指发送数据之前必须在两端建立连接。建立连接的方法是“三次握手”,这样能建立可靠的连接。建立连接,是为数据的可靠传输打下了基础。
- 仅支持单播传输
每条TCP
传输连接只能有两个端点,只能进行点对点的数据传输,不支持多播和广播传输方式。
面向字节流
TCP
不像UDP
一样那样一个个报文独立地传输,而是在不保留报文边界的情况下以字节流方式进行传输。可靠传输
对于可靠传输,判断丢包,误码靠的是TCP
的段编号以及确认号。TCP
为了保证报文传输的可靠,就给每个包一个序号
,同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK
);如果发送端实体在合理的往返时延(RTT
)内未收到确认,那么对应的数据(假设丢失了)将会被重传。
- 提供拥塞控制
当网络出现拥塞的时候,TCP
能够减小向网络注入数据的速率和数量,缓解拥塞
-
TCP
提供全双工通信
TCP
允许通信双方的应用程序在任何时候都能发送数据,因为TCP连接的两端都设有缓存,用来临时存放双向通信的数据。当然,TCP
可以立即发送一个数据段,也可以缓存一段时间以便一次发送更多的数据段(最大的数据段大小取决于MSS)
TCP和UDP的比较
- 对比
- 总结
TCP
向上层提供面向连接的可靠服务 ,UDP
向上层提供无连接不可靠服务。
虽然 UDP
并没有TCP
传输来的准确,但是也能在很多实时性要求高的地方有所作为
对数据准确性要求高,速度可以相对较慢的,可以选用TCP
.
TCP为什么是四次挥手,而不是三次?
三次握手 四次挥手
三次握手
SYN--> //请求同步信号 (server端收到后 确认client能发)
<--ACK ,SYN //确认接收信号,+ 请求同步信号 (client端收到后 确认自己能收能发,service能收能发)
ACK--> //确认接收信号 (service端收到后 确认自己能收能发,client能收能发 )
加
seq=x --> //seq自己发的序列号
<-- seq=y,ack=x+1 //ack应答号 ack=x+表示自己接到了对面seq=x的消息
seq,ack--> //由上两步也可以推出 seq=x+1 ack=y+1
四次挥手
FIN--> //请求结束
<--ACK //确认应答
;;;; //server 发还没有发完的消息(这就是为什么有四次握手的原因)
<--ACK,FIN //server 请求结束
ACK--> //确认应答
加
seq=x-->
<--seq=y,ack=x+1
<--seq=y+n,ack=x+1
seq,ack--> // seq=x+1 ack=y+n+1;
问题总结:
为什么是3次握手,不是2次
2次握手可能出现的情况:
【网上的图】
如上图:
第一个
丢失的报文段延误后到达服务端,此时服务端误认为客户端又发出一次
新的连接请求,同意建立连接。
只要服务端发出确认,就建立新的连接了,此时客户端忽略服务端发来的确认,也不发送数据,则服务端一致等待客户端发送数据。
什么是半连接
:
第一次握手后
,服务端不确定客户端能不能接受,先把连接请求放入半连接队列
中,进入SYN_RECV状态(连接请求已接收状态),
完成三次握手再把连接放到全连接队列中
。
一直没收到第三次握手,service端发重传包,达到规定次数,从半连接队列里删除。(发重传包间隔时间一般指数增长)
————————————————
为什么有四次
挥手,
service端收到FIN请求后要先应答ACK
,
等发完未发的数据,然后再发FIN
;
什么是2MSL
,为什么要等2MSL
MSL:maximum segment lifetime——最大报文生命周期
1:让client
接受完service
在第2-3
次挥手期间发的内容
2:保证本次连接所有报文从网络中消失。(不影响下一次连接)
————————————————
socket编程中,何时进行三次握手?如何用socket发送数据?
HTTP协议中request和response有哪些数据组成部分?
1.request
请求组成:
请求行(request line)、请求头部(header)、空行和请求数据四个部分组成。
- GET
GET /562f25980001b1b106000338.jpg HTTP/1.1
Host img.mukewang.com
User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept image/webp,image/*,*/*;q=0.8
Referer http://www.imooc.com/
Accept-Encoding gzip, deflate, sdch
Accept-Language zh-CN,zh;q=0.8
第一部分:请求行
,用来说明请求类型,要访问的资源以及所使用的HTTP
版本.
GET
说明请求类型为GET
,[/562f25980001b1b106000338.jpg]
为要访问的资源,该行的最后一部分说明使用的是HTTP1.1版本。
第二部分:请求头部
,紧接着请求行(即第一行)之后的部分,用来说明服务器要使用的附加信息
从第二行起为请求头部,HOST
将指出请求的目的地.User-Agent
,服务器端和客户端脚本都能访问它,它是浏览器类型检测逻辑的重要基础.该信息由你的浏览器来定义,并且在每个请求中自动发送等等
第三部分:空行
,请求头部后面的空行是必须的
即使第四部分的请求数据为空,也必须有空行。
第四部分:请求数据
也叫主体
,可以添加任意的其他数据。
这个例子的请求数据为空。
- POST
POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive
name=Professional%20Ajax&publisher=Wiley
第一部分:请求行,第一行明了是post
请求,以及http1.1
版本。
第二部分:请求头部,第二行至第六行。
第三部分:空行,第七行的空行。
第四部分:请求数据,第八行。
Host
:指明了该对象所在的主机
Connection
:Keep-Alive首部行用来表明该浏览器告诉服务器使用持续连接
Content-Type
: x-www-form-urlencoded首部行用来表明 HTTP会将请求参数用key1=val1&key2=val2的方式进行组织,并放到请求实体里面
User-agent
:首部行用来指明用户代理,即向服务器发送请求的浏览器类型
Accept-lauguage
:首部行表示用户想得到该对象的法语版本(如果服务器中有这样的对象的话),否则,服务器应发送它的默认版本
2.response
响应组成:
一般情况下,服务器接收并处理客户端发过来的请求后会返回一个HTTP的响应消息。
HTTP
响应也由四个部分组成,分别是:状态行
、消息报头
、空行
和响应正文
。
第一部分:状态行
,由HTTP协议版本号, 状态码, 状态消息 三部分组成。
第一行为状态行,(HTTP/1.1
)表明HTTP
版本为1.1
版本,状态码为200
,状态消息为(ok)
第二部分:消息报头
,用来说明客户端要使用的一些附加信息
第二行和第三行为消息报头,
Date
:生成响应的日期和时间;Content-Type
:指定了MIME
类型的HTML(text/html)
,编码类型是UTF-8
第三部分:空行
,消息报头后面的空行是必须的
第四部分:响应正文
,服务器返回给客户端的文本信息。
空行后面的html部分
为响应正文
。
在浏览器输入URL到页面加载发生了什么?
1、浏览器的地址栏输入URL并按下回车。
2、浏览器查找当前URL的DNS缓存记录。
3、DNS解析URL对应的IP。
4、根据IP建立TCP连接(三次握手)。
5、HTTP发起请求。
6、服务器处理请求,浏览器接收HTTP响应。
7、渲染页面,构建DOM树。
8、关闭TCP连接(四次挥手)。
你真的明白IP、域名和端口号之间的联系了吗
-
IP
- (英语:Internet Protocol Address,又译为
网际协议地址
),是分配给网络上使用IP协议
的设备的数字标签。常见的IP地址
分为IPv4
与IPv6
两大类。 - 通俗点说就是
IP地址
是用于标识出网络上的每一台主机的编号
。有这个编号,网络上的其他主机才能在互联网浩若繁星的主机中定位到唯一
的一台主机
。
- (英语:Internet Protocol Address,又译为
-
域名
- 域名(英语:domain name),是由
一串用"点"分隔
的字符组成的Internet
上某一台计算机或计算机组
的名称,用于在数据传输时
标识计算机的电子方位。 -
域名
和IP地址
之间有区别也有联系,域名通常会和IP
进行绑定,通过访问域名来访问网络上的主机的服务。IP地址
通常指的是网络中的主机,而域名则通常表示一个网站
,一个域名可以绑定到多个ip
上,多个域名
也可以绑定到一个ip
上。
- 域名(英语:domain name),是由
端口号
端口(英语:port
),主要分为物理端口
和逻辑端口
。我们一般说的都是逻辑端口
,用于区分不同的服务。因为网络中一台主机只有一个IP
,但是一个主机可以提供多个服务
,端口号就用于区分一个主机上的不同服务。一个IP地址的端口
通过16bit
进行编号,最多可以有65536
个端口,标识是从0~65535
。
- 域名与端口号如何对应起来
客户端输入域名
,通过DNS
将域名解析成为服务器ip
,找到代理服务器
,因为http协议
服务所占用的端口默认为80
端口,所以会访问服务器的80
端口,然后再通过代理服务器将请求转发到不同的服务器
以及端口中
.
-
应该通过域名访问项目吗?
- 如果用
IP+端口号
的方式访问,会有以下后果- 首先,
非常难记
,域名是对人友好的有含义的字符,而ip
都是4组基本无规律的数字,对人不友好。 - 其次, 如果服务器中的资源发生迁移,那么原先的服务器
ip地址
就无效了,必须要重新使用新的ip地址访问服务器
,用户还要再去记忆一遍IP地址。但是如果是使用域名则不存在这个问题。 - 最后, 不安全,通过
ip直接访问服务器
是非常危险的,相当于将整个服务器的大门向所有人打开,造成的后果是别有用心的人能够非常容
易攻击到服务器。域名访问 就能杜绝这种情况,用户是不知道服务器的IP地址的,而且就算有人通过域名恶意攻击,直接和用户交互的代理服务器也可以保护内容服务器。这样就算代理服务器被攻破,损失也相对较小。
- 首先,
- 如果用
从域名服务商到服务器的流程是怎么样的?
- DNS的查询方式有几种?
有两种,递归查询和迭代查询
递归查询
是一次查询就得到最终的结果。通常是主机到DNS服务器
之间的查询方式
迭代寻址
是有可能发生多次请求,并且每次得到的结果有可能只是参考答案。DNS服务器
会使用迭代查询
HTTP断点续传
HTTP中间人攻击(重点) HTTPS中间人攻击
①SSLStrip (降级攻击)的工作原理及步骤
(1) 先进行中间人攻击来拦截 HTTP 流量。
(2) 将出现的 HTTPS 链接全部替换为 HTTP,同时记下所有改变的链接。
(3) 使用 HTTP 与受害者机器连接。
(4) 同时与合法的服务器建立 HTTPS。
(5) 受害者与合法服务器之间的全部通信经过了代理转发。
(6) 其中,出现的图标被替换成为用户熟悉的“小黄锁”图标,以建立信任。
(7) 这样,中间人攻击就成功骗取了密码、账号等信息,而受害者一无所知。
总而言之,SSLStrip是一种降级攻击。
②sslsplit(解密攻击)工作原理
工具的主要原理是以中间人的身份将证书插入到客户端和服务器中间,从而截断客户端和服务器之间的数据。
之前我们大多数做的都是针对于80端口的欺骗(http),也就是说,只要是超越了80端口我们就会有点棘手:比如常用的443端口(https),比如465(smtps)和587端口,这些都是通过SSL加密进行数据传输的,简单的80端口监听肯定是什么都拿不到的。这个时候,就体现出SSL证书劫持的作用了。
总而言之,SSLSplit是一种伪造证书攻击。
中间人攻击场景涉及三个角色,客户端,服务器,以及 CA(证书签发机构)
。CA 主要用来解决 Client
和 Server
之间的信任问题,相当于一个背书的角色。CA 通过签发证书的方式,来确认 Client 和 Server 的身份,具体到 iOS 客户端,CA 一般向 Server 签发证书,告知 Client,持有某个证书的 Server,其身份是可以被信任的。那谁来确认 CA 所说的话是可以被信任的呢?操作系统会内置一些知名 CA 的公钥,这些知名 CA 在签发证书的时候会通过审核确认,确保 Server 的身份和其所宣称的一致。
所有围绕中间人攻击的场景都是根据CA
来展开的。
对于 iOS 开发者来说,防中间人攻击可以从两
方面着手。
第一是通讯内容本身加密,无论是走http
还是 https
,request
和 response
的内容本身都要先做一次加密,这样即使 https 的流量被破解,攻击者还需要再攻破一层加密算法。我们一般使用 AES 256
对内容做加密,这里 AES 密钥的管理也有两种方式,其一是在客户端使用固定的密钥,为了加大破解的难度,我们可以对密钥本身做多次加密处理,使用时再在内存里解密出来真正的密钥。其二是每次会话都使用不同的密钥,原理类似 Forward Secrecy,即使流量被记录,将来被暴力破解,也能极大的增加攻击者破解的时间成本。
第二种就是大家所熟知的 ssl pinning。在客户端进行代码层面的证书校验,校验方式也有两种,一是证书本身校验,而是公钥校验。这两种方式对应到 AFNetworking 中的代码如下:
enum {
AFSSLPinningModeNone,
AFSSLPinningModePublicKey,
AFSSLPinningModeCertificate,
}
防范方式
我们可以看到,无论是哪种攻击手段,利用的都是局域网的中间人攻击。因此一些防范方式有:
①不随意连接公共wifi
②对于arp表中的ip和MAC地址进行静态固定
③开启一些安全软件的arp防火墙
④及时更新浏览器版本或换用其他安全性高的浏览器
HTTPS中间人攻击
iOS 客户端 HTTPS 防中间人攻击实践
iOS 客户端 HTTPS 防中间人攻击实践---MrPeak杂货铺
HTTPS实现原理;(加密通信原理)
DNS劫持
URI 和 URL 之间的关系
- URI (Uniform Resource Identifier,统一资源标识符)
URI 属于 URL 更高层次的抽象,一种字符串文本标准。就是说,URI 属于父类,而 URL 属于 URI 的子类。URL 是 URI 的一个子集。
二者的区别在于,URI 表示请求服务器的路径,定义这么一个资源。而 URL 同时说明要如何访问这个资源(http://)。
- URL(Uniform Resource Locator,统一资源定位符)
scheme://host[:port#]/path/.../[;url-params][?query-string][#anchor]
scheme
:有我们很熟悉的http、https、ftp以及著名的ed2k,迅雷的thunder等。
host
:HTTP服务器的IP地址或者域名
port
: HTTP服务器的默认端口是80,这种情况下端口号可以省略。如果使用了别的端口,必须指明,例如tomcat的默认端口是8080 http://localhost:8080/
path
: 访问资源的路径
url-params
:所带参数
query-string
:发送给http服务器的数据
anchor
:锚点定位
scheme: http
host: mobile.hktsc.cc
path: /services/list
query: appPage=serviceList&brandId=1
queryItems: [appPage=serviceList, brandId=1]
第0个queryItem name:appPage
第0个queryItem value:serviceList
第1个queryItem name:brandId
第1个queryItem value:1
有可能已经遭到篡改
。比如,网页上植入垃圾广告,视觉污染,眼没了。
安全问题HTTPS
得到了解决。
- 无连接
浏览器的每次请求都要与服务器建立一个TCP
连接,服务器完成请求处理后立即断开TCP
连接。
每个TCP
只能发送一个请求。发送数据完毕,连接就关闭。如果还要请求其他资源,就需要再建立一个连接。
TCP三次握手
是一个很耗费时间的过程,所以HTTP/1.0
性能比较差。
请求报文
请求行由请求方法、URL
和 HTTP协议
版本三个字段组成。中间由空格隔开。例如:GET /index.html HTTP/1.1。
HTTP
协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT
。
- GET
当客户端要从服务器读取文档时,点击网页上的链接或者通过在浏览器的地址栏输入网址来浏览网页,都是GET
方式。
GET
方法要求服务器将URL
定位的资源放在响应报文的数据部分,会送给客户端。
使用GET方法时,请求参数和对应的值附加在URL后面,以一个(?)
代表URL
的结尾与请求参数的开始,传递参数长度受限制。例如:/index.jsp?id=100&op=bind.
- POST
POST
方法将请求的参数封装在HTTP
请求数据中,以名称/
值的方式出现,可以传输大量数据,对传送的大小没有限制,也不会显示在URL
中。 - HEAD
HEAD
就像GET
,只不过服务端接受到HEAD
请求后只返回响应头,而不会发送响应内容。当我们只需要查看某个页面的状态的时候,使用HEAD
是非常高效的,因为在传输的过程中省去了页面内容。
GET和POST的区别?
-
GET
方法是请求从服务器获取资源,可以是图片、文本、页面、视频等。POST
是向URI
指定的资源提交数据,数据
就放在请求报文的BODY
里。 -
GET
请求会把请求的数据附在URL
后。POST
提交是将数据放在报文的body
里。 因此GET
提交的数据会在地址栏中显示出来,而POST
提交地址栏不会改变。 - 是否安全且幂等
-
安全和幂等:
-
安全
:请求方法不会破坏服务器上的资源 -
幂等
:多次执行相同的操作,结果都是相同的。
-
GET
是安全
且幂等
,因为它的操作是只读的,无论操作多少次,服务器上的数据都是安全的,且每次结果都相同。
POST 因为是新增或提交数据,因此它会修改服务器上的资源,所以是不安全的,且多次提交数据就会创建多个资源,也是不幂等的。
- 安全性:
POST
的安全性要比GET
的安全性高。
注意:这里所说的安全性和上面
GET
提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改,而这里安全的含义是真正的Security
的含义,
比如:通过
GET
提交数据,用户名和密码将明文出现在URL
上,
因为(1)登录页面有可能被浏览器缓存,
(2)其他人查看浏览器的历史纪录,那么别人就可以拿到你的账号和密码了。
POST传输的资源更大,数据类型更多。
get 获取资源的速度更快!!
参考
计算机网络
《图解HTTP与HTTPS》的干货1.2w字【绝对保值】
HTTP 中文开发手册
一篇文章看明白 TCP/IP,TCP,UDP,IP,Socket 之间的关系
一篇文章看明白 HTTP,HTTPS,SSL/TLS 之间的关系