http状态码：https://www.cnblogs.com/TankXiao/archive/2013/01/08/2818542.html
OSI七层模型
百度一下OSI七层模型，描述是：国际标准组织（iso），制定的用于计算机或通信体系互联的标准体系，它是七层的，抽象的模型，不仅包含抽象的术语和概念也包含具体的协议
七层协议经典图
1、物理层：主要解决了通信设备间收发比特流的通信需求，定义了物理设备的标准：网线类型、网卡、网线的接口类型、和各种物理传输媒介的传输速率等，主要作用是传输比特流，将比特流转化为电流强弱，到达目的地后再将电流转换为比特流，这就是数模转换与模数转换，这一层的数据就是比特。对应的网络协议有IEEE 802.1A, IEEE 802.2到IEEE 802
2、数据链路层：比特流的传输过程中往往会产生错传，数据传输不完整，数据链路层就是为了解决这些问题而产生的，数据链路层定义了如何对数据进行格式化、如何控制对物理介质的访问、提供错误检测和纠正、将物理层的比特数据组成具有可靠性传输的帧，交换机就是工作在这一层，它负责对帧数据进行解码。对应的网络协议：FDDI, Ethernet, Arpanet, PDN, SLIP, PPP，STP。HDLC,SDLC,帧中继
3、网络层：在网络中随着网络节点的不断增加，点对点的通信往往是需要经过很多节点的，如何选择最佳路径，如何找到目标节点成为了首要问题，针对这些问题网络层通过将网络地址翻译成对应的物理地址，并决定如何将数据由发送方路由到接收方，通过路由算法得出将数据发送到接收方节点的最佳路径，路由器就是在这一层中工作，这一层的数据称为包。对应的网络协议：IP, ICMP, ARP, RARP, AKP, UUCP
4、传输层：传输层称为OSI最重要的一层，主要进行主机间的数据传输，数据的传输可以是不同网络的，并且能保证传输的质量，在数据量大的传输中需要等待很长的时间，网络往往会断开，此时为了保证数据的准确性，需要对数据进行切分，切分为一个个数据段进行发送，传输层还可以进行流量控制，可以基于接收方可接收数据的快慢程度调整发送速率，传输层还可以按照网络能处理的最大尺寸，将较长的数据包进行强制切割，切割为较小的数据片，同时对每一个数据片记录一个序列号，到达接收方后以正确的顺序进行重组，此过程称为排序。对应网络协议TCP, UDP
5、会话层：自动收发包，自动寻址，建立和管理应用程序之间的通信。对应网络协议SMTP, DNS
6、表示层：负责将数据按照网络能被理解的方案进行格式化，编码的转换，数据的解析，确保一个系统发送的数据能被接收的系统所识别，同时管理数据的加密和解密，提供字符代码、数据格式、控制信息格式等的统一表示。对应用层的协议进行翻译。对应网络协议Telnet, Rlogin, SNMP, Gopher
7、应用层：OSI中最高的一层，为应用程序提供访问网络服务的接口。直接和用户进行交互。对应网络协议HTTP、TFTP, FTP, NFS, WAIS、SMTP
信息量大的头部：OSI七层模型，从应用层开始至下而上的每一层都会对数据的头部进行处理，加上一些本层的信息，最终达到物理层将数据变为比特流在网络中传输，然后至下而上经过每一层都会对数据的头部消息进行解析
大人时代变了，现在是五层了：
五层
IP/TCP协议
IP协议：无连接的通信协议，对应的是网络层，它不会占用两个通信机器的通信线路，对网络线路的需求很低，IP协议能将数据分解为一个个很小的独立的包，通过因特网将包路由到目的地，但是IP不能保证包的顺序发送和包是否被破坏，所以通过IP协议传输的数据包是不可靠的，所以需要上层(传输层)协议（传输控制协议TCP）进行控制。
TCP协议：位于传输层的传输控制协议，它是面向连接，可靠的，基于字节流的传输协议。
TCP协议的工作概要：在数据流传输时，应用层将数据流传输给TCP,TCP将数据分割成适当长度的报文段，然后将结果包传输给IP，由IP通过网络将包传输到目标节点的TCP，TCP为确保包不会丢失，给包设置了一个序列号，序列号也保证了包到达目的地后的按序处理，并且会对包进行奇偶校验和来验证包是否有误，接收方接收到包后也需要对包进行奇偶校验和，并且发送一个ACK确认，如果发送方在允许的时延内未接收到ACK,则视为包已丢失，就会重新发送数据包
报文头部：不多BB直接上图
报文头部英文版
报文头部中文版
源端口和目的端口：写入源和发送目的地的应用程序端口号
序号(Seq)：TCP连接中传送的字节流中的字节都是按照顺序去编号的，例如当前报文的序号为100，携带的数据有200个字节，此报文的最后一个字节序号就是299（200+100-1），那么下个报文的序号应该是300
确认号（ACK）：期望收到下一个报文的第一个数据字节的序号。例如当A向B发送了一个序号为100携带的数据字节总共为200的报文，此时B确认了已经收到了299的序号（100+200-1）B期望收到A的下一个报文的数据序号为300，所以B会将确认号置为300发送给A，得出的结论就是接收方的确认号等于发送方的下一个报文的序号
数据偏移：报文的数据距离报文的起始有多远
窗口：告知接收端的缓存大小，以此控制发送端的发送速率，达到控制流量的效果
检验和：奇偶检验和，校验包是否有误
TCP flags每一个标志位表示一个控制功能：
1、URG: 紧急指针标志 1->有效 0->忽略
2、ACK：确认号标志 1->有效 0->报文不含确认号信息，忽略确认号
3、PSH：push标志 1->push标志有效，表面接收方接收后应对尽快交给应用程序 0->忽略
4、RST：重置连接标志
5、SYN：同步序号，用于建立连接过程,syn=1->建立请求或接受请求：syn=1并且ack=0时建立连接请求，SYN=1并且ACK=1时双方接受连接（这里画重点，下面TCP三次握手会多次使用）
6、FIN：释放连接 1->发送方已经没有数据可发送，关闭本方数据流 0->连接仍然存在
TCP 三次握手
三次握手是为了尽量的确保连接能够建立，尽量避免网络问题而创建一些无效连接造成资源浪费，通过三次握手能有效的确保端与端之间的连接如果出现问题，另一端能及时察觉，握手之后双方将建立一个全双工的通信。
三次握手为什么是三次呢？
原因在于客户端发送连接请求，服务端接收到了然后给客户端发送响应也就是第二次握手，没等第二次握手的请求到达客户端就服务端就创建连接，然后因为网络原因第二次握手的请求丢失了，客户端一直没接收到请求因为连接超时就把连接关闭了，而服务端却不知道，连接一直开着浪费了资源，所以客户端必须要接到服务端的第二次握手，并且让服务端知道客户端接收到了请求让服务端知道的这个过程就是第三次握手。第三次握手基本是百分之九十以上连接上了，其实还可以进行十次，一百次一千次握手，但是没必要了，也浪费资源
说了那么多终于到了本文章的重头戏，不多BB马上上图，（这些步骤描述全部是笔者自己构思，通俗易懂，比百度的更容易理解，希望读者好好体会）
TCP三次握手图
下图是三次握手的实际数据包的抓起，从上到下是第一、二、三次的握手的数据包，流程是客户端13789端口向服务端80端口发起TCP连接
三次握手的数据包
三次握手的步骤：
(图中大写的ACK和SYN为TCP flags)
准备连接：通信程序必须有一端主动打开，另一被动打开，在连接之前双方都处于closed状态，例如客户端A向服务端B请求连接，主动打开连接的是客户端A,被动打开连接的是服务端B，服务端B创建传输控制块TCB进入LISTEN监听状态，时刻准备接收客户端A的连接请求。
第一次握手---客户端创建连接：（SYN=1,ACK=0,seq=x），客户端A创建传输控制块向服务端B发送连接请求报文，客户端A的请求报文中SYN=1 ,由于客户端A没有回应内容ack,所以ack的TCP flags状态ACK（确认号的缩写）还是等于0（图中没有画出来），上面提到过当TCP flags的SYN=1并且ACK=0时表示连接请求，seq=x （seq为序号的缩写），x为一个任意的正整数（开始时一般为0）,此时客户端A进入了SYN-SENT的状态，报文称为syn报文段，它还不能携带数据
第二次握手---服务端响应连接：（SYN=1,ACK=1,seq=y,ack=x+1），服务端B接收到了客户端的连接后，将回应客户端A，服务端B响应报文进行了有效的ack回应，所以TCP flags ACK状态为1， 我们上面说过，接收方响应报文中的确认号ack等于发送端下一次报文的序号，第一次握手不能携带数据,所以客户端A下一次的报文序号肯定是seq=x+1,所以服务端B的确认号ack=x+1,同时自己也要发送一个自己的序号(任意正整数)假设为y,seq=y,图中大写的ACK就是上面内容提到的TCP flags只是一个状态，上面提到了ACK和SYN都为1时表示双方都同意了连接,，此时服务端B进入SYN-RCVD状态，客户端A进入ESTAB-LISHED状态，此次握手也不能携带数据
第三次握手---客户端确认收到回应：(ACK=1,seq=x+1,ack=y+1）（SYN不见了？由于双方已经确认建立好了连接所以我们不需要看SNY状态了或者你可以认为它现在还是处于等于1的状态）。客户端A发送响应报文，同时也进行了有效的ack回应，所以TCP flags ACK依然是1，由于第二次握手中，服务器B不能携带数据，回复的ack等于第二次握手时服务端B发送报文的seq加1，所以ack=y+1,由于客户端A在第一次握手时也不能携带数据，所以序号也只能是客户端A上个报文的序号加1，所以seq=x+1，此时服务端B进入ESTAB-LISHED状态，此报文可以携带数据
这是不是有点像上拼多多买东西，先看好要买的东西（准备连接），然后给卖家下单（第一次握手---客户端创建连接），卖家收到订单并且发货（第二次握手---服务端响应连接），我们收到货后到拼多多上确认收货（第三次握手---客户端确认收到回应）
TCP 四次挥手：
如果我们掌握了三次握手，拿四次挥手也是小菜一碟了，不多BB直接上图
四次挥手
如果读者掌握了三次握手，四次挥手也是看这个图就懂了，我就不详细讲了(现在都凌晨两点半了)，还没看懂这个图的回到上面好好看看TCP flags和三次握手的内容，只是有一点细节不一样要提一下
第一次挥手：（FIN=1,seq=u）由于没有数据可以发送了，假设客户端最后的数据的序号已经是u-1了，所以seq=u和客户端A将置为1的FIN发送给服务端，客户端A进入终止等待1
第二次挥手：（ACK=1,seq=v,ack=u+1）,服务端B没有向客户端A发送FIN=1,是因为客户端A虽然没有数据可以发送了，但是服务端B可能还有一些收尾的工作要做，还需要继续向客户端B发送数据，客户端A虽然没有数据可以发送了但是还是能接收数据的，此时服务端B进入了关闭等待状态，这个状态还要持续一段时间的
第三次挥手：（FIN=1,ACK=1,seq=w,ack=u+1）,这里是和三次握手的原理不太一样的地方，由于第二次挥手时，服务端B还没有发送FIN=1,还需要发送有数据的报文给客户端B，假设服务端上次携带数据的报文数据字节已经到了w-1，所以这次 的报文已经没有数据了，所以序号是w-1+1,而客户端A已经在第一次挥手时已经没有任何数据产生了，所以它的序号依旧是u,确认号依旧是u+1;
第四次挥手：（ACK=1,seq=u+1,ack=w+1）这里我不分析了，相信掌握了上面内容的读者都能很容易的分析的出来了，真是小菜一碟
UDP协议
学完了TCP的同学，学UDP真的是小菜一碟
不多BB直接上图：
UDP报文头
特点：面向非连接，不可靠的传输层协议
UDP协议的工作概要：UDP协议无需源端和目的端的连接，当UDP 要传输数据时，只是简单的抓起来之应用程序产生的数据，并尽可能快的将数据扔到网络上，UDP传输数据的速度仅仅受限于发送端的数据产生速度和计算机的性能，传输带宽的限制，UDP将数据扔到一个队列中，应用程序从这个队列中读取数据，由于UDP传输数据不建立连接，所以不用去维护连接状态
TCP和UDP的区别：
1、TCP面向连接,UPD面向非连接
2、TCP可靠，UDP不可靠
3、TCP速度慢，UDP速度快
4、TCP是重量级，UPD轻量级
HTTP:
这个是应用层的协议，基于TCP协议，目前已经出到了HTTP2，但是还不普及,现在HTTP1.1才是普及的应用的，在HTTP1.1以前也就是HTTP0.9和HTTP1.0每次请求都得进行一次TCP连接，服务器完成一次响应就得关闭连接，HTTP1.1是长连接的，所以一次连接可以发送多个请求。
HTTP0.9：
只有一个GET请求、没有头信息、每次请求都得进行一次TCP连接，服务器响应后就关闭连接
HTTP1.0：
增加Post、put、delete等命令、增加了请求头信息
HTTP1.1：
增加了持久连接，一次TCP连接发送可以多次请求、增加pipline:客户端可以批量的发送请求，服务响应按照请求顺序串行的响应效率低、增加host字段
HTTP2.0：
所有的数据都是以二进制数据进行传输，头部消息压缩减少带宽，服务器可以并发响应客户端的数据、增加推送功能服务端可以主动推送css,js等文件给客户端，不需要一次次的请求
区别：
1 HTTP1.0和HTTP1.1的区别
HTTP1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启长连接keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。HTTP1.0需要使用keep-alive参数来告知服务器端要建立一个长连接。
HTTP1.0中存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。HTTP1.1支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了节约了带宽。
在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname），HTTP1.0没有host域。随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都支持host域，且请求消息中如果没有host域会报告一个错误（400 Bad Request）。
在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
2 HTTP1.1和HTTP2.0的区别
HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。
在HTTP1.1中，HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言，消息主体都会经过gzip压缩，或者本身传输的就是压缩过后的二进制文件，但状态行和头部却没有经过任何压缩，直接以纯文本传输。随着Web功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容，完全是一种浪费。
HTTP1.1由于头部是以纯文本的形式保存的所以不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源：HTML、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。这是一个很慢的过程。浏览器从获取HTML开始，然后解析HTML再逐个发起请求去获取css、js、表格等资源。因为服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。
为了改善延迟，HTTP2.0引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源，不用再通过网络。
URI、URL、URN
URL和URN都是URI的子集
URI：统一资源标志符
一个资源逻辑。所标识的资源可能是服务器上的一个文件。可能是一个种子、邮件地址、新闻消息、图书、人名、Internet主机或者任何其它内容。它包含URL和URN。支持的协议有http、https、ftp、mailto、magnet、telnet、data、file、nfs、gopher、ldap等
URL：统一资源定位符
URL唯一地标识一个资源在Internet上的位置。不管用什么方法表示，只要能定位一个资源，就叫URL。最常用的格式如：http://username:password@ip:80/path?q=xxx、Ftp://pub.xxx
URN:统一资源名称
URL定位了资源在哪里，但是如果资源换了服务器或者换了其他地方，URL就找不到了，URL是不会告诉我们它搬到了哪里，然后你就找不到这个资源了，找到了资源由于地方换了往往URL也会跟着变，而URN无论你的资源放到了哪里，URN是不变的，URN它命名资源但不指定如何定位资源，比如：只告诉你一个人的姓名，不告诉你这个人在哪，所以你无法根据这个URN定位资源在哪里，它就相当于一个人的身份证仅仅依靠身份证是找不到这个人的，但是这个人无论去到哪里只是地址改变，身份证是不变的。例如：telnet、mailto、news 和 isbn URI 等都是URN。如：urn:issn:1535-3613
HTTP报文格式：
结构：起始行（请求行和状态行），首部（请求头和响应头），主体（请求体和响应体）
标红的地方是空行
请求报文
请求报文（request）：
一个HTTP请求报文由请求行（request line）、请求头部（header）、空行(如上图)和请求数据4个部分组成，下图给出了请求报文的一般格式
请求报文格式
请求报文起始行
请求报文
● User-Agent：产生请求的浏览器类型;
● Accept：客户端可识别的响应内容类型列表;星号 “ * ” 用于按范围将类型分组，用 “ */* ” 指示可接受全部类型，用“ type/* ”指示可接受 type 类型的所有子类型;
● Accept-Language：客户端可接受的自然语言;
● Accept-Encoding：客户端可接受的编码压缩格式;
● Accept-Charset：可接受的应答的字符集;
● Host：请求的主机名，允许多个域名同处一个IP 地址，即虚拟主机;
● connection：连接方式(close 或 keepalive);
● Cookie：存储于客户端扩展字段，向同一域名的服务端发送属于该域的cookie;
HTTP方法：Method
语意是POST（增）、 DELETE（删）、PUT（改）、GET（查）。意义虽然是这样，但其实真正我们是如何实现方法的是随意的，也就是你完全可以用 GET 删除资源，DELETE 增加资源，这是只是规范问题，你没有按照http的规范去做也没什么问题，只是这个语意会让人误解而已我们分析几个比较重要的
1、GET：目的是获取资源
a、参数可见：GET 方法的参数是明文可见的包含在 URL 当中，所以说敏感信息不建议使用 GET 方法不过也正是因此，所以 GET 方法允许被保存书签
b、数据类型只允许 ASCII:GET 方法的数据类型只允许是 ASCII 字符，所以说传递 二进制 文件就不可以用 GET 方法了
c、可以被缓存：GET 方法支持缓存，当本次请求允许被缓存时，会将资源存值本地 cache ，在未过期的情况下直接取本地 cache
d、参数会保留在浏览器历史记录:比较直观的感受就是，我们可以在浏览器的历史记录中查看到曾经搜索过的关键字信息
e、请求长度会受限于所使用的浏览器与服务器:不同的浏览器对于 GET 请求长度的限制也是不同的，注意这是 浏览器 / 服务器（IE、Chrome、Apache、IIS等） 对于长度的限制，而不是 HTTP 协议
2、POST：POST 方法的首要目的是 提交，POST 方法一般用于添加资源
a、参数不可见，也不会被保存:所以说 POST 方法是不可以不会被保存在浏览器历史中
b、不可以被缓存:POST提交的数据是不可以被浏览器缓存在本地的
c、不限制请求长度：对于 POST 方法这种以提交为首要目的的方法，是不限制请求长度的
d、数据类型:不限，POST可以提交文件到服务器的
e、请求方式:POST 请求与 GET 请求不同，他会首先提交 HEAD 信息，待得到 100 响应后，才会再次将 DATA 提交
响应报文（request）：
HTTP的请求报文包括：请求行(request line)、请求头部(header)、空行 和 请求数据(request data) 四个部分组成。
响应报文格式
响应报文
●Server：服务器应用程序软件的名称和版本
●Content-Type：响应正文的类型（是图片还是二进制字符串）
●Content-Length：响应正文长度
●Content-Charset：响应正文使用的编码
●Content-Encoding：响应正文使用的数据压缩格式
●Content-Language：响应正文使用的语言
● 状态码由三位数字组成，第一位数字表示响应的类型，常用的状态码有五大类如下所示：
1xx：表示服务器已接收了客户端请求，客户端可继续发送请求;
2xx：表示服务器已成功接收到请求并进行处理;
3xx：表示服务器要求客户端重定向;
4xx：表示客户端的请求有非法内容;
5xx：表示服务器未能正常处理客户端的请求而出现意外错误;
● 状态码描述文本有如下取值：
200 OK：表示客户端请求成功;
400 Bad Request：表示客户端请求有语法错误，不能被服务器所理解;
401 Unauthonzed：表示请求未经授权，该状态代码必须与 WWW-Authenticate 报头域一起使用;
403 Forbidden：表示服务器收到请求，但是拒绝提供服务，通常会在响应正文中给出不提供服务的原因;
404 Not Found：请求的资源不存在，例如，输入了错误的URL;
500 Internal Server Error：表示服务器发生不可预期的错误，导致无法完成客户端的请求;
503 Service Unavailable：表示服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常;
HTTPS:
参考：https://blog.csdn.net/xiaoming100001/article/details/81109617，如有侵犯立即删除
HTTPS基于HTTP协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护
HTTPS有如下特点：
1、内容加密：采用混合加密技术，中间者无法直接查看明文内容
2、验证身份：通过证书认证客户端访问的是自己的服务器
3、保护数据完整性：防止传输的内容被中间人冒充或者篡改
对称加密：客户端和服务端都用相同的密钥进行加密通信，此算法效率比非对称加密高很多，但是首次通信如何将密钥传输给客户端而不被截获成为了问题。
非对称加密：私钥只能用公钥解密，公钥只能用私钥解密，服务端有自己的私钥，将公钥传输给客户端，客户端的信息通过公钥加密传给服务端，服务端解密回复。缺点就是服务端的信息人人可以截获，并且可以伪装成服务端。
非对称加密过程需要用到公钥进行加密，那么公钥从何而来？其实公钥就被包含在数字证书中，数字证书通常来说是由受信任的数字证书颁发机构CA，在验证服务器身份后颁发，证书中包含了一个密钥对（公钥和私钥）和所有者识别信息。数字证书被放到服务端，具有服务器身份验证和数据传输加密功能。
SSL建立连接过程
1、用户通过浏览器向网站发出安全的HTTPD请求
2、服务器发送包含服务器公钥的证书。
3、浏览器检查证书或CA的颁发者是否受信任。否则，将提示用户是否接受此证书是不受信任的。通过证书认证后浏览器将生成对称密钥，该密钥将使用服务器的公钥进行加密，以便安全地发送给它。
4、以这种方式，对称加密的秘钥已经安全达到服务器，通信已经安全地建立，此后双方将使用刚刚第三个步骤中浏览器发送的秘钥以对称加密的形式进加密解密
这个过程先是浏览器通过CA验证服务器发送的公钥，然后使用服务器发送的公钥将对称算法的秘钥进行非对称加密，然后发送给服务器，服务器使用自己私钥进行非对称解密，这样就安全得到了对称加密的秘钥
如果没有证书这种机制的话，会发生什么情况呢：通常客户端请求服务端是会认证客户端身份，服务器主要是通过生成公钥和私钥，公钥发给客户端，私钥留给自己，加密的东西经过公钥加密必须是需要对应的私钥解密，相反私钥加密的东西必须是对应的公钥解密。客户端发起请求时，服务端会将公钥发给客户端，这时攻击者就可以拦截公钥，进行公钥伪造即将服务器公钥替换成自己的公钥，然后将假的公钥发给浏览器，由于没有CA机构验证这个公钥的真伪，所以浏览就信了，将对称加密的秘钥使用假公钥加密的发送出去，攻击者再次截获消息，就会使用自己的私钥解开假公钥加密的密文从而获取对称加密的秘钥
公钥被掉包导致消息被篡改
解决方法：数字证书
数字证书内容：包括了加密后服务器的公钥、权威机构的信息、服务器域名，还有经过CA私钥签名之后的证书内容（经过先通过Hash函数计算得到证书数字摘要，然后用权威机构私钥加密数字摘要得到数字签名)，签名计算方法以及证书对应的域名。
权威机构是经过浏览器认证的几个公司，有的是盈利的有的是收费的，这些权威机构的证书是内置在浏览器中的，证书带有权威机构的公钥，攻击者无法修改，当然企业也可以让客户端去下载他们的证书
受谷歌认证的权威机构
证书如何保证客户端消息不被篡改？
验证证书安全性过程
1、当客户端收到这个证书之后，使用本地配置的权威机构的公钥对证书进行解密得到服务端的公钥和证书的数字签名，数字签名经过CA公钥解密得到证书信息摘要。
2、然后证书签名的方法计算一下当前证书的信息摘要，与收到的信息摘要作对比，如果一样，表示证书一定是服务器下发的，没有被中间人篡改过。因为中间人虽然有权威机构的公钥，能够解析证书内容并篡改，但是篡改完成之后中间人需要将证书重新加密，但是中间人没有权威机构的私钥，无法加密，强行加密只会导致客户端无法解密，如果中间人强行乱修改证书，就会导致证书内容和证书签名不匹配。
证书验证的过程
SSL双向认证过程：
① 浏览器发送一个连接请求给安全服务器。
② 服务器将自己的证书，以及同证书相关的信息发送给客户浏览器。
③ 客户浏览器检查服务器送过来的证书是否是由自己信赖的 CA 中心所签发的。如果是，就继续执行协议；如果不是，客户浏览器就给客户一个警告消息：警告客户这个证书不是可以信赖的，询问客户是否需要继续。
④ 接着客户浏览器比较证书里的消息，例如域名和公钥，与服务器刚刚发送的相关消息是否一致，如果是一致的，客户浏览器认可这个服务器的合法身份。
⑤ 服务器要求客户发送客户自己的证书。收到后，服务器验证客户的证书，如果没有通过验证，拒绝连接；如果通过验证，服务器获得用户的公钥。
⑥ 客户浏览器告诉服务器自己所能够支持的通讯对称密码方案。
⑦ 服务器从客户发送过来的密码方案中，选择一种加密程度最高的密码方案，用客户的公钥加过密后通知浏览器。
⑧ 浏览器针对这个密码方案，选择一个通话密钥，接着用服务器的公钥加过密后发送给服务器。
⑨ 服务器接收到浏览器送过来的消息，用自己的私钥解密，获得通话密钥。
⑩ 服务器、浏览器接下来的通讯都是用对称密码方案，对称密钥是加过密的。
上面所述的是双向认证 SSL 协议的具体通讯过程，这种情况要求服务器和用户双方都有证书。单向认证 SSL 协议不需要客户拥有 CA 证书，具体的过程相对于上面的步骤，只需将服务器端验证客户证书的过程去掉，以及在协商对称密码方案，对称通话密钥时，服务器发送给客户的是没有加过密的 （这并不影响 SSL 过程的安全性）密码方案。 这样，双方具体的通讯内容，就是加过密的数据，如果有第三方攻击，获得的只是加密的数据，第三方要获得有用的信息，就需要对加密的数据进行解密，这时候的 安全就依赖于密码方案的安全。而幸运的是，目前所用的密码方案，只要通讯密钥长度足够的长，就足够的安全。这也是我们强调要求使用 128 位加密通讯的原因。
SSL一定安全吗？
1、 HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用
2、SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行
中间人攻击（MITM攻击）是指，黑客拦截并篡改网络中的通信数据。又分为被动MITM和主动MITM，被动MITM只窃取通信数据而不修改，而主动MITM不但能窃取数据，还会篡改通信数据。最常见的中间人攻击常常发生在公共wifi或者公共路由上。
HTTPS弊端
1、SSL证书需要购买申请，功能越强大的证书费用越高
2、SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗（SSL有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持，Windows XP就不支持这个扩展，考虑到XP的装机量，这个特性几乎没用）。
3、根据ACM CoNEXT数据显示，使用HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电。
5、HTTPS连接缓存不如HTTP高效，流量成本高。
6、HTTPS连接服务器端资源占用高很多，支持访客多的网站需要投入更大的成本。
7、HTTPS协议握手阶段比较费时，对网站的响应速度有影响，影响用户体验。比较好的方式是采用分而治之，类似12306网站的主页使用HTTP协议，有关于用户信息等方面使用HTTPS。
网友评论