网络原理基础知识整理

[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 服务器推送

HTTP1.0和HTTP1.1和HTTP2.0的区别

http htpps

HTTP 与 HTTPS 区别？

1. HTTP是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS解决了HTTP不安全的缺陷，在TCP与HTTP之间加入了SSL/TLS协议，保证报文能够加密传输。
2. HTTP连接建立相对简单，TCP三次握手之后可进行HTTP传输。而HTTPS在三次握手之后，还要进行SSL/TLS握手过程，才可以进入加密传输。
3. HTTP的端口号是80，HTTPS端口号是443.
4. HTTPS需要向CA（证书权威机构）申请数字证书，保证服务器是可信的。

SSL/TSL

（网上的图）

2dadf5b7d8e8e7ec449fdad2e59566ce

964d2a689f469218cfaa685c4c0af52d

dbe321e8b3b395607e9b04d4e9a47483

HTTPS

• HTTPS和HTTP的区别

HTTPS协议 = HTTP协议 + SSL/TLS协议
SSL的全称是Secure Sockets Layer，即安全套接层协议，是为网络通信提供安全及数据完整性的一种安全协议。TLS的全称是Transport Layer Security，即安全传输层协议。
即HTTPS是安全的HTTP。

• HTTPS的连接建立流程
  HTTPS为了兼顾安全与效率，同时使用了对称加密和非对称加密。在传输的过程中会涉及到三个密钥：

  • 服务器端的公钥和私钥，用来进行非对称加密
  • 客户端生成的随机密钥，用来进行对称加密

  非对称加密 RSA
  对称加密

  1. 欧拉函数
     AES CBC密码分组链接模式。使用一个密钥和一个初始化向量[IV]对数据执行加密。
     密码分组链接模式。使用一个密钥和一个初始化向量[IV]对数据执行加密。

297d29d78a6c7fb145fe6549a8b475a7

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等。

fb5b1bd606c3f3f8fcdaf1ebec171111

在网络体系结构中网络通信的建立必须是在通信双方的对等层进行，不能交错。 在整个数据传输过程中，数据在发送端时经过各层时都要附加上相应层的协议头和协议尾（仅数据链路层需要封装协议尾）部分，也就是要对数据进行协议封装，以标识对应层所用的通信协议。接下去介绍TCP/IP 中有两个具有代表性的传输层协议----TCP 和 UDP。

UDP

UDP协议全称是用户数据报协议，在网络中它与TCP协议一样用于处理数据包，是一种无连接的协议。在OSI模型中，在第四层——传输层，处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。

它有以下几个特点：

1. 面向无连接

首先 UDP 是不需要和 TCP一样在发送数据前进行三次握手建立连接的，想发数据就可以开始发送了。并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。

具体来说就是：

• 在发送端，应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议，然后就传递给网络层了
• 在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作.

2. 有单播，多播，广播的功能

UDP 不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能。

3. UDP是面向报文的

发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文.

4. 不可靠性

首先不可靠性体现在无连接上，通信都不需要建立连接，想发就发，这样的情况肯定不可靠。

并且收到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了。

再者网络环境时好时坏，但是 UDP 因为没有拥塞控制，一直会以恒定的速度发送数据。即使网络条件不好，也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。

ce1fdba04d73cafce9dd8e3af91f30f1

从上图可以得知，UDP只会把想发的数据报文一股脑的丢给对方，并不在意数据有无安全完整到达。

5. 头部开销小，传输数据报文时是很高效的

1f283e79d36014ee6d10a067f9c79ad5

UDP 头部包含了以下几个数据：

• 两个十六位的端口号，分别为源端口（可选字段）和目标端口
• 整个数据报文的长度
• 整个数据报文的检验和（IPv4 可选 字段），该字段用于发现头部信息和数据中的错误

因此 UDP 的头部开销小，只有八字节，相比 TCP 的至少二十字节要少得多，在传输数据报文时是很高效的.

TCP

当一台计算机想要与另一台计算机通讯时，两台计算机之间的通信需要畅通且可靠，这样才能保证正确收发数据。

TCP协议全称是传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议，由 IETF 的RFC 793定义。TCP 是面向连接的、可靠的流协议。流就是指不间断的数据结构，你可以把它想象成排水管中的水流。

TCP连接过程

如下图所示，可以看到建立一个TCP连接的过程为（三次握手的过程）:

5d8ebb2662ce574cfc21b4a92cb86ca6

1. 第一次握手

客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后，客户端便进入 SYN-SENT 状态。

2. 第二次握手

服务端收到连接请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序号，发送完成后便进入 SYN-RECEIVED 状态。

3. 第三次握手

当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功。

• 这里可能大家会有个疑惑：为什么 TCP 建立连接需要三次握手，而不是两次？

这是因为这是为了防止出现失效的连接请求报文段被服务端接收的情况，从而产生错误。

假想一下，如果我们去掉了第三次呢？
因为我们不进行第三次握手，所以在S对C的请求进行回应(第二次握手)后，就会理所当然的认为连接已建立，而如果C并没有收到S的回应呢？此时，C仍认为连接未建立，S会对已建立的连接保存必要的资源，如果大量的这种情况，S会崩溃。

d0cf5fa1a260c45b038eee5922731209

TCP断开链接

21f777dd7b30b1b901554e4b0223bd12

TCP 是全双工的，在断开连接时两端都需要发送 FIN 和 ACK。

1. 第一次握手

若客户端 A 认为数据发送完成，则它需要向服务端B发送连接释放请求。

2. 第二次握手

B 收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送ACK包，并进入CLOSE_WAIT 状态，此时表明A到B 的连接已经释放，不再接收 A 发的数据了。但是因为 TCP 连接是双向的，所以 B 仍旧可以发送数据给 A。

3. 第三次握手

B 如果此时还有没发完的数据会继续发送，完毕后会向 A 发送连接释放请求，然后 B便进入 LAST-ACK 状态。

4. 第四次握手

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的比较

1. 对比

9a14afac14e8a02c0b2175542cc7c821

2. 总结

TCP向上层提供面向连接的可靠服务 ，UDP向上层提供无连接不可靠服务。
虽然 UDP 并没有TCP 传输来的准确，但是也能在很多实时性要求高的地方有所作为
对数据准确性要求高，速度可以相对较慢的，可以选用TCP.

TCP为什么是四次挥手，而不是三次？

TCP为什么是四次挥手，而不是三次

三次握手 四次挥手

三次握手

b30c8983446074730f5fca43e8bfa712

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

四次挥手

2f8b98462b3d527a024ba5ba896fe7a6

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次握手可能出现的情况：
【网上的图】

0fc9b9b04c50fba407a0a1f5f591f6c0

如上图：
第一个丢失的报文段延误后到达服务端，此时服务端误认为客户端又发出一次新的连接请求，同意建立连接。
只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据。

什么是半连接：
第一次握手后，服务端不确定客户端能不能接受，先把连接请求放入半连接队列中，进入SYN_RECV状态(连接请求已接收状态)，
完成三次握手再把连接放到全连接队列中。
一直没收到第三次握手，service端发重传包，达到规定次数，从半连接队列里删除。（发重传包间隔时间一般指数增长）

————————————————

为什么有四次挥手，
service端收到FIN请求后要先应答ACK，
等发完未发的数据，然后再发FIN；

什么是2MSL，为什么要等2MSL
MSL：maximum segment lifetime——最大报文生命周期
1：让client接受完service在第2-3次挥手期间发的内容
2：保证本次连接所有报文从网络中消失。（不影响下一次连接）
————————————————

socket编程中，何时进行三次握手？如何用socket发送数据？

socket编程 - TCP三次握手与四次握手

HTTP协议中request和response有哪些数据组成部分？

1.request请求组成：

请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。

27c907e5491f9d72446bc566dfcbb77f

• 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响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。

714a6ec28a120d43fe2b10d2e1c7552d

第一部分：状态行，由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连接（四次挥手）。

从输入url到页面加载完成发生了什么？——前端角度

你真的明白IP、域名和端口号之间的联系了吗

• IP

  1. （英语：Internet Protocol Address，又译为网际协议地址）,是分配给网络上使用IP协议的设备的数字标签。常见的IP地址分为IPv4与IPv6两大类。
  2. 通俗点说就是IP地址是用于标识出网络上的每一台主机的编号。有这个编号，网络上的其他主机才能在互联网浩若繁星的主机中定位到唯一的一台主机。

• 域名

  1. 域名（英语：domain name），是由一串用"点"分隔的字符组成的 Internet上某一台计算机或计算机组的名称，用于在数据传输时标识计算机的电子方位。
  2. 域名和IP地址之间有区别也有联系，域名通常会和IP进行绑定，通过访问域名来访问网络上的主机的服务。IP地址通常指的是网络中的主机，而域名则通常表示一个网站，一个域名可以绑定到多个ip上，多个域名也可以绑定到一个ip上。

• 端口号

端口（英语：port），主要分为物理端口和逻辑端口。我们一般说的都是逻辑端口，用于区分不同的服务。因为网络中一台主机只有一个IP，但是一个主机可以提供多个服务，端口号就用于区分一个主机上的不同服务。一个IP地址的端口通过16bit进行编号，最多可以有65536个端口，标识是从0~65535。

• 域名与端口号如何对应起来

客户端输入域名，通过DNS将域名解析成为服务器ip，找到代理服务器,因为http协议服务所占用的端口默认为80端口，所以会访问服务器的80端口，然后再通过代理服务器将请求转发到不同的服务器以及端口中.

6ecf99893bf9f244e7acda836011b8fe

• 应该通过域名访问项目吗？

  1. 如果用IP+端口号的方式访问，会有以下后果
     1. 首先，非常难记,域名是对人友好的有含义的字符，而ip都是4组基本无规律的数字，对人不友好。
     2. 其次， 如果服务器中的资源发生迁移,那么原先的服务器ip地址就无效了，必须要重新使用新的ip地址访问服务器,用户还要再去记忆一遍IP地址。但是如果是使用域名则不存在这个问题。
     3. 最后， 不安全,通过ip直接访问服务器是非常危险的,相当于将整个服务器的大门向所有人打开，造成的后果是别有用心的人能够非常容
        易攻击到服务器。域名访问 就能杜绝这种情况，用户是不知道服务器的IP地址的，而且就算有人通过域名恶意攻击，直接和用户交互的代理服务器也可以保护内容服务器。这样就算代理服务器被攻破，损失也相对较小。

• 从域名服务商到服务器的流程是怎么样的？

adca18730a99fd59046eb4defc5427ea

• DNS的查询方式有几种？
  有两种,递归查询和迭代查询

递归查询是一次查询就得到最终的结果。通常是主机到DNS服务器之间的查询方式
迭代寻址是有可能发生多次请求，并且每次得到的结果有可能只是参考答案。DNS服务器会使用迭代查询

你真的明白IP、域名和端口号之间的联系了吗

HTTP断点续传

HTTP断点续传（分块传输）（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实现原理；（加密通信原理）

HTTPS原理解析

DNS劫持

DNS劫持和HTTP劫持有什么区别？

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 :锚点定位

• http://mobile.hktsc.cc/services/list?appPage=serviceList&brandId=1

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得到了解决。

3. 无连接

浏览器的每次请求都要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接。

每个TCP只能发送一个请求。发送数据完毕，连接就关闭。如果还要请求其他资源，就需要再建立一个连接。

TCP三次握手是一个很耗费时间的过程，所以HTTP/1.0性能比较差。

请求报文

请求行由请求方法、URL 和 HTTP协议版本三个字段组成。中间由空格隔开。例如：GET /index.html HTTP/1.1。

HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。

1. GET
   当客户端要从服务器读取文档时，点击网页上的链接或者通过在浏览器的地址栏输入网址来浏览网页，都是GET方式。
   GET方法要求服务器将URL定位的资源放在响应报文的数据部分，会送给客户端。
   使用GET方法时，请求参数和对应的值附加在URL后面，以一个（？）代表URL的结尾与请求参数的开始，传递参数长度受限制。例如:/index.jsp?id=100&op=bind.
2. POST
   POST方法将请求的参数封装在HTTP请求数据中，以名称/值的方式出现，可以传输大量数据，对传送的大小没有限制，也不会显示在URL中。
3. HEAD
   HEAD就像GET，只不过服务端接受到HEAD请求后只返回响应头，而不会发送响应内容。当我们只需要查看某个页面的状态的时候，使用HEAD是非常高效的，因为在传输的过程中省去了页面内容。

GET和POST的区别?

1. GET方法是请求从服务器获取资源，可以是图片、文本、页面、视频等。 POST是向URI指定的资源提交数据，数据就放在请求报文的BODY里。
2. GET请求会把请求的数据附在URL后。POST提交是将数据放在报文的body里。 因此GET提交的数据会在地址栏中显示出来，而POST提交地址栏不会改变。
3. 是否安全且幂等

• 安全和幂等：

  • 安全：请求方法不会破坏服务器上的资源
  • 幂等：多次执行相同的操作，结果都是相同的。

GET是安全且幂等，因为它的操作是只读的，无论操作多少次，服务器上的数据都是安全的，且每次结果都相同。
POST 因为是新增或提交数据，因此它会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，也是不幂等的。

4. 安全性：

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 之间的关系