网络协议

1、网络协议分层

七层模型
四层模型
Socket层

2、HTTP 协议与 HTTPS 协议

1、定义

HTTP ：是超文本传输协议，全称“Hyper Text Transfer Protocol”，是一个基于请求与响应，无状态的，应用层的协议，常基于 TCP/IP 协议传输数据，互联网上应用最为广泛的一种网络协议，所有的 WWW 文件都必须遵守这个标准。设计 HTTP 的初衷是为了提供一种发布和接收 HTML 页面的方法。
HTTPS：是由 HTTP + SSL/TLS 协议构建的可进行加密传输、身份认证的网络协议，要比 HTTP 协议安全。HTTPS 协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

2、请求/响应报文

请求报文的

请求报文格式
注：
1、在 GET 请求的时候没有实体主体。
2、在 POST 请求的时候有实体主体。

响应报文

响应报文格式

3、原理

HTTP 工作原理

HTTP 工作原理
注：常用 HTTP 状态码

HTTPS 工作原理

HTTPS 工作原理
HTTPS 工作原理
说明：
1、HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。
2、HTTPS 的整体过程分为证书验证和数据传输阶段。
证书验证阶段：浏览器向服务器发起 Https 请求，服务器接收到请求后，将会携带 CA 证书（包括公钥）返回给客户端，客户端解析证书并验证证书是否合法，如果不合法则提示警告，反之则准备进行数据传输。
数据传输阶段：当证书验证合法后，取出公钥生成随机数，然后通过公钥对随机数进行非对称加密，并把加密后的随机数发送给服务器端，服务器端使用私钥对随机数进行解密，解密后服务器端对客户端传入的随机数进行对错加密，最后把对此加密后的内容传输给客户端。

4、HTTP 请求方法

HTTP 请求方法

5、HTTP 特点

1、无状态：协议对客户端没有状态存储，对事物处理没有“记忆”能力（比如访问一个网站需要反复进行登录操作）。
2、无连接：HTTP/1.1之前，由于无状态特点，每次请求需要通过 TCP 三次握手四次挥手和服务器重新建立连接。
3、基于请求和响应：基本的特性，由客户端发起请求，服务端响应。
4、简单快速、灵活。
5、通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性。

6、HTTPS 优缺点

优点：安全
1、内容加密：采用混合加密技术，中间者无法直接查看明文内容。
2、验证身份：通过证书认证客户端访问的是自己的服务器。
3、保护数据完整性：防止传输的内容被中间人冒充或者篡改。
混合加密：结合非对称加密和对称加密技术。客户端使用对称加密生成密钥对传输数据进行加密，然后使用非对称加密的公钥再对秘钥进行加密，所以网络上传输的数据是被秘钥加密的密文和用公钥加密后的秘密秘钥，因此即使被黑客截取，由于没有私钥，无法获取到加密明文的秘钥，便无法获取到明文数据。
数字摘要：通过单向 hash 函数对原文进行哈希，将需加密的明文“摘要”成一串固定长度(如128bit)的密文，不同的明文摘要成的密文其结果总是不相同，同样的明文其摘要必定一致，并且即使知道了摘要也不能反推出明文。
数字签名：数字签名建立在公钥加密体制基础上，是公钥加密技术的另一类应用。它把公钥加密技术和数字摘要结合起来，形成了实用的数字签名技术。

缺点：
1、HTTPS 协议握手阶段比较费时且增加耗电。
2、HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响。
3、SSL 证书需要钱，功能越强大的证书费用越高。
4、SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名。
5、HTTPS 协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。

7、SSL 和 TLS

SSL ：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL 通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL 记录协议和 SSL 握手协议。
TLS ：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS 记录协议和 TLS 握手协议。
注：TLS 是 SSL 3.0 的后续版本。在 TLS 与 SSL3.0 之间存在着显著的差别，主要是它们所支持的加密算法不同，所以 TLS 与 SSL3.0 不能互操作。
SSL与TLS的功能:
1、在互联网上传输加密过的资料以达到防窃取的目的。
2、保持从端点A到端点B的传送路途中资料的完整性。
3、透过 SSL 证书内的公共金钥加密资料传输至服务器端，服务器端用私密金钥解密来证明自己的身份。
SSL建立连接过程

SSL建立连接过程
1、client 向 server 发送请求 https://baidu.com，然后连接到 server 的 443 端口，发送的信息主要是随机值1和客户端支持的加密算法。
2、server 接收到信息之后给予 client 响应握手信息，包括随机值2和匹配好的协商加密算法，这个加密算法一定是 client 发送给 server 加密算法的子集。
3、随即 server 给 client 发送第二个响应报文是数字证书。服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。传送证书，这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容。
4、客户端解析证书，这部分工作是由客户端的 TLS 来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（预主秘钥）。
5、客户端认证证书通过之后，接下来是通过随机值1、随机值2和预主秘钥组装会话秘钥。然后通过证书的公钥加密会话秘钥。
6、传送加密信息，这部分传送的是用证书加密后的会话秘钥，目的就是让服务端使用秘钥解密得到随机值1、随机值2和预主秘钥。
7、服务端解密得到随机值1、随机值2和预主秘钥，然后组装会话秘钥，跟客户端会话秘钥相同。
8、客户端通过会话秘钥加密一条消息发送给服务端，主要验证服务端是否正常接受客户端加密的消息。
9、同样服务端也会通过会话秘钥加密一条消息回传给客户端，如果客户端能够正常接受的话表明 SSL 层连接建立完成了。

8、HTTPS 优化

原因
HTTPS 慢的原因在于 TCP 三次握手之后，还有 TLS 握手，可以通过简化这部分的握手来优化。
TCP 三次握手和 TLS 握手流程图

简图
详解图
优化
1、利用 session id，当我们第一次连接之后，客户端会生成 session id，当下一次客户端再次和服务端连接的时候，通过携带的 session id 如果在服务端可以找到，那么就认为客户端是可信赖的。
2、利用 session ticket，也在客户端连接的时候会附带上，当再次连接的时候，直接解密 session ticket，如果解密成功，则认为是可信赖，直接进行数据传输。
3、对于分布式系统，当在一个服务器生成的 session id，把它同步到其他服务器，那么当客户端连接其他服务器的时候，直接可以通过这个 id 判断是否可信赖。
4、利用 tcp 连接优化，前面介绍 tcp 三次握手的时候，数据域没有携带数据的，那么可以在 tcp 三次握手的时候，就携带数据，减少握手次数。
5、证书验证优化，TLS 握手过程中，客户端需要验证证书的有效性，这一部分可以直接通过服务器验证，将结果缓存，将验证结果返回给客户端，客户端在本地校验结果是否真实。

9、HTTP 与 HTTPS 区别

1、HTTPS 协议需要到 CA 申请证书，一般免费证书较少，需要一定费用。
2、HTTP 是超文本传输协议，信息是明文传输；HTTPS 是安全的 HTTP，它的安全是由 SSL/TLS 这种插在应用层之下传输层之上的协议来保证的。
3、HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、HTTP 的连接很简单，是无状态的；HTTPS 协议是由 SSL/TLS+HTTP 协议构建的可进行加密传输、身份认证、保证数据完整性的网络协议，比 HTTP 协议安全。

3、TCP/UDP

TCP：面向连接的可靠传输协议有以下特点：面向连接、可靠传输、面向字节流、流量控制、拥塞控制。

1、面向连接

TCP是面向连接的协议,它有三次握手建立连接和四次挥手断开连接。
为什么是三次握手？
为了解决请求超时而导致重复建立连接的问题。客户端发送 SYN 请求建立连接时，如果网络发生延迟超时后客户端会重复发送 SYN 消息，服务器接收到第二次发送的建立连接请求返回确认信息，连接建立完成。而此时第一次发送 SYN 建立连接请求经过一段时间后到达服务器，服务器会认为客户端要建立新的连接，会重新发送应答响应。这就导致了重复建立连接的情况。

为什么是四次挥手?
因为此时的客服端和服务端建立的连接是全双工的（即客服端可以给服务端发送消息，服务端也可以给客户端发送消息）。客户端向服务端发送断开连接请求，服务端发送确认请求，此时属于半关闭状态（即客户端不能再向服务端发送消息但能接收消息，服务端能向客户端发送消息），待服务端数据发送完成后也向客户端发送断开连接客户端回复确认，此时才真正的断开连接。

2、可靠传输

可靠传输就所保证传输的数据无差错，不丢失，不重复，按序到达。通过停止等待协议来实现。停止等待协议可以通过无差错情况，超时重传，确认丢失，确认迟到。
无差错

无差错
当客户端发送数据之后需等待对端的确认信息.如果收到确认应答，表示数据成功发送到对端。如果在一定时间内没有收到确认应答，则认为数据已丢失需要重新发送。未收到应答消息，有两种情况数据丢失一种是发送消息丢失，另一种是应答消息丢失。应答信号丢失，重新发送对端就会重复接收相同的数据，为了解决目标端重复接收相同数据，可以通过为发送数据的每个字节标上序号，接收端收到数据根据首部序号和长度，将下一次应该的接收的序号作为应答返回出去.这样就可以通过序列号和确认应答,实现可靠传输。

超时重传

超时重传
理想状态下，找到一个小的时间，确保应答消息在该时间段中可以返回，但是不同的网络环境下这个时间会发生变化。TCP为了在不同网络环境下都能提供高性能通信，每次发送数据都会计算往返时间及其偏差，超时时间就是比往返时间与偏差的和稍大一点的时间。
注：需要超时定时器

确认丢失

确认丢失

确认迟到

确认迟到

3、面向字节流

1、TCP 在内核有自己的接收缓冲区和发送缓冲区。
2、面向字节流最重要的就是接收缓冲区和发送缓冲区的存在，在应用层向下发送一个数据包时，可以发送一次或者多次。在应用层接收一个数据包时，可以接收一次或者多次。发和收次数不需要对应。
3、TCP 发送数据的规则
-> TCP 接收到的数据块后会被写到了 TCP 的缓冲区，TCP 以字节为单位划分数据。
-> 当数据块字节数太长，会被拆分称多个 TCP 数据包发送出去。
-> 当数据块字节数太短，先在缓冲区里等待，等待缓冲区长度差不多了或者其它适合的时机发送出去。

4、滑动窗口

问题：
TCP 通信机制为发送消息，接收确认消息，然后再发送消息等等，这样的传输方式有一个缺点：数据包的往返时间越长，通信的效率就越低。
解决方案：
TCP 引入了窗口这个概念。窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。
窗口大小：指无需等待确认应答，而可以继续发送数据的最大值。通常窗口的大小是由接收方的窗口大小来决定的。发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。
累计确认/累计应答：发送多个连续的数据段时，当接收到最后一个数据段的确认应答报文既可以认为接收方已经接收到所有数据段，而无需等到所有的确认应答报文接收完成。

5、流量控制

TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。

6、拥塞控制

1、慢开始，拥塞避免

慢开始

X 轴表示交互次数，Y 轴表示窗口值大小
网络拥塞判断，连续三个的网络报文没有收到的时候可以界定为网络拥塞。
2、快恢复，快重传
上图中达到网络拥塞的时候，恢复到新的门限值而不是慢开始点。

UDP：用户数据报协议，是一个非连接的协议。传输数据之前发送源端和接收端不建立连接，当它想传送时就简单地去抓取应用程序的数据并尽可能的把它扔到网络上。

1、特点

无连接、尽最大努力交付、面相报文。
无连接：在通过 UDP 发送数据的时候，不需要事先建立连接，当然也不需要断开连接。
尽最大努力交付：不保证可靠传输。
面相报文：报文即不合并也不拆分。将上一层（应用层）的数据报文作为该层（传输层UDP）的数据部分加上该层的的头部（UDP首部）传递给下一层（IP层），作为下一层的数据部分。

2、功能

复用：多端口复用一个传输通道。

复用
分用：根据目的端口分发数据。
分用
差错检测：
1、发送方：将所有发送的数据以 16 位为一个单元，按二进制反码计算出这些 16 位数据的和，再将和的二进制反码写入到检验和位（位于8 字节 UDP 首部末尾即图中红色区域）。
2、接收方：接收到数据时，同样按照上述方案计算出一个 16 位字的检验和与发送方传递过来的检验和对比。
差错检测

3、原理

1、在发送端，UDP 传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制。在接收端，UDP 把每个消息段放在队列中，应用程序每次从队列中读一个消息段。
2、 由于传输数据不建立连接，因此也就不需要维护连接状态、收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。
3、UDP 信息包的标题很短，只有8个字节，相对于 TCP 的20个字节信息包的额外开销很小。
4、吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、发送端和接收端主机性能的限制。
5、UDP 使用尽最大努力交付，不保证可靠交付，因此主机不需要维持复杂的链接状态表。
6、UDP 是面向报文的。发送方的 UDP 对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。

4、DNS 解析

1、定义

域名到 IP 地址的映射。DNS 解析请求采用 UDP 数据报且明文。

2、流程

流程

3、查询方式

1、递归查询

DNS 递归查询

2、迭代查询

迭代查询
本地 DNS 依次问询其他 DNS，最后返回给客户端。

4、存在问题

DNS 劫持
由于 DNS 查询是明文，所以是不安全，会拿到错误的地址。

DNS 劫持

DNS 劫持和 HTTP 的关系？
没有关系。DNS 解析发生在建立 HTTP 连接之前；DNS 解析请求使用 UDP 数据报，端口号53。

怎么解决DNS劫持？
1、通过 httpDNS 方式
由原来的使用 DNS 协议向 DNS 服务器的53端口发送请求，更改为使用 HTTP 协议向 DNS 服务器的80端口发送请求。
示例：

示例
用携带有自己的 IP 地址（172.18.134.108）和需要解析的域名(www.imooc.com) 向中介服务器（119.29.29.29）通过 IP 直连的方式获取目标的 IP 地址。
2、通过长连接方式
由长链 sever 通过内网解析。
长连接

DNS 解析转发
客户端向运营商 DNS 查询域名的时候，运营商由于某种原因不去查询而是转发到另外一个运营商代为查询，导致查询的 IP 结果有误。

示例

1、针对 HTTP 无状态的一些解决策略

1、通过 Cookie/Session 技术。
2、HTTP/1.1 持久连接（HTTP keep-alive）方法，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
持久连接：建立一次连接后，后续的一段时期内，都在使用这条网络通道。持久连接设计需要在头部添加以下字段
Connection：为 keep-alive 表示期许建立持久连接
time：持久连接的有效时间
max：最多可以发生多少次网络请求
非持久连接：客户端和服务端建立连接后使用一次就断开连接，下次再使用的时候再次建立连接发送请求。即每次发送网络请求的时候都要重新建立一次TCP连接。

2、Cookies 机制和 Session 机制的区别

1、Cookies 数据保存在客户端，Session 数据保存在服务端。
2、Cookies 可以减轻服务器的压力，但是不安全，容易进行 Cookies 欺骗。
3、Session 安全一点，但是会占用服务器资源。

Cookies：Cookie 用来记录用户状态，区分用户。由服务端生成保存在客户端。

Cookies
客户端发送的 Cookie 在 http 请求报文的 Cookie 首部字段中；服务端设置 http 响应报文的 set-Cookie 首部字段。
怎样修改 Cookie ？
通过覆盖方式修改，即用新 Cookie 覆盖旧 Cookie。覆盖时 name、path、domain等要与原来的一致。
怎样删除 Cookie？
通过覆盖方式修改，即用新 Cookie 覆盖旧 Cookie。覆盖时 name、path、domain等要与原来的一致。同时设置 Cookie 的 expires=过去的一个时间点或者设置 maxAge=0。
怎样保证 Cookie 安全？
1、Cookie 进行加密。
2、只在 https 上携带 Cookie。
3、设置 Cookie 为 httpOnly，防止跨站脚本攻击。

Session：Session 是用来记录用户状态，区分用户的。状态存放在服务端。

流程
注：session 是通过 Set-Cookie 和 Cookie 这两个字段进行状态传递。

Session 和 Cookie 的关系？
Session 需要依赖于 Cookie 机制来实现。（如上图 Session工作流程）

3、TCP 与 UDP 对比？

1、TCP 是面向连接的，UDP 是面向无连接的。TCP 需要建立连接和断开连接，UDP 不需要。
2、TCP 是流协议，UDP 是数据包协议。TCP 数据没有大小限制，UDP 数据报有大小限制。
3、TCP 是可靠协议，UDP 是不可靠协议。TCP 会处理数据丢包重发以及乱序等情况，UDP 则不会处理。

4、怎样判断一个请求结束？

1、根据客服端所接受到的数据和响应头部报文中 Content-length 给定的大小判断是否接受完成。
2、根据 chunked 是否为空来判断是否接收完成。

5、GET 和 POST 请求方式的区别？

答案一：
1、GET 请求参数以 ？ 分割拼接到 URL 后面，POST 请求参数在 Body 里面。
2、GET 参数的长度限制2048个字符，POST 没有限制。
3、GET 请求不安全，POST 请求比较安全。
答案二：
GET 用来获取资源，它是安全的，幂等的和可缓存的；POST 用来处理资源，它所非安全的，非幂等的和不可缓存。
安全的：不应该引起 sever 端的任何状态变化。如： GET，HEAD，OPTIONS。
幂等性：同一个请求方法执行多次和执行一次的效果完全相同。如：PUT 和 DELETE。
可缓存：请求是否可以被缓存。如：GET 和 HEAD。

6、Charles 的抓包原理

利用 HTTP 的中间人攻击漏洞实现

7、怎么保证保证服务器给客户端下发的公钥是真正的公钥，而不是中间人伪造的公钥呢？

示例 1

8、证书如何安全传输，被掉包了怎么办？

示例 2

数字证书内容
包括了加密后服务器的公钥、权威机构的信息、服务器域名，还有经过 CA 私钥签名之后的证书内容（经过先通过 Hash 函数计算得到证书数字摘要，然后用权威机构私钥加密数字摘要得到数字签名)，签名计算方法以及证书对应的域名。

验证证书安全性过程
1、当客户端收到这个证书之后，使用本地配置的权威机构的公钥对证书进行解密得到服务端的公钥和证书的数字签名，数字签名经过CA公钥解密得到证书信息摘要。
2、然后证书签名的方法计算一下当前证书的信息摘要，与收到的信息摘要作对比，如果一样，表示证书一定是服务器下发的，没有被中间人篡改过。因为中间人虽然有权威机构的公钥，能够解析证书内容并篡改，但是篡改完成之后中间人需要将证书重新加密，但是中间人没有权威机构的私钥，无法加密，强行加密只会导致客户端无法解密，如果中间人强行乱修改证书，就会导致证书内容和证书签名不匹配。

9、浏览器输入一个地址，到页面展示中间经过哪些东西？

1、浏览器输入 url，先进行解析 url 是否合法。
2、浏览器检查是否有缓存（浏览器缓存--系统缓存---路由器缓存），如果有缓存，则直接显示；如果没有缓存，在浏览器发送 http 请求前，需要进行域名解析（DNS解析），解析获取相对应的ip地址。
3、浏览器想向务器发起 TCP 链接，与浏览器经历 TCP 三次握手，完成链接。
4、链接成功后，浏览器向服务器发送 http 请求以及请求数据包。
5、服务器收到处理的请求后，将响应数据返回至浏览器。
6、浏览器收到 http 响应后，并解析响应，如果响应可以缓存则进行缓存。
7、浏览器发送异步请求获取嵌入在 HTML 中的资源，对于未知类型，会弹出对话框。
8、页面全部渲染结束并关闭链接。