计算机网路协定

概览：

1. TCP/IP 四层模型
2. HTTP 三次握手和四次挥手
3. TCP 和 UDP；UDP 丢包起因
4. HTTP0.9 / HTTP1.0 / HTTP1.1 / HTTP2.0 之间的区别
5. HTTPS 协定，工作原理以及加密算法。
6. 浏览器从申请到响应，两头产生了什么？

1、TCP/IP 的四层模型

数据从网络中一个终端上的应用程序传送到另外一个终端的应用程序，两头须要经验很多过程，有多方参加对数据进行层层封装、转发。咱们把这个流程在逻辑上进行分成层，每一层依据本层的规章制度 (协定) 各司其职。

TCP/IP 协定可分为应用层、运输层、网际层、网络接口层。

应用层：与网络相干的程序通过网络与其余程序通信应用的数据格式标准。

• HTTP（80 端口），次要用于一般浏览。
• HTTPS（443 端口），HTTP 协定的平安版本。
• FTP（20 和 21 端口），用于文件传输。
• POP3（110 端口），收邮件用。
• SMTP（25 端口），用来发送电子邮件。
• SSH（22 端口），用于加密平安登陆用。
• DHCP（67 端口，动静主机配置协定），动静配置 IP 地址。
• DNS，用于实现地址查找，邮件转发等工作（运行在 TCP 和 UDP 协定上）。
• SNMP，用于网络信息的收集和网络管理。
• ARP，用于动静解析以太网硬件的地址。

传输层：解决诸如端到端可靠性（数据是否曾经达到目的地）和保证数据依照正确的程序达到这样的问题。

TCP/UDP 协定

网际层：解决在一个繁多网络上传输数据包的问题。

IP 协定

网络接口层：它是数据包从一个设施的网络层传输到另外一个设施的网络层遵循的标准。

比方以太网协定、Wi-Fi 协定。

2、HTTP 三次握手和四次挥手

1. 三次握手

第一次握手：客户端发送第一个包，其中 SYN 标记位为 1, ACK=0，发送顺序号 seq=x(随机 int)。客户端进入 SYN 发送状态，期待服务器确认。

第二次握手：服务器收到这个包后发送第二个包，其中包 SYN、ACK 标记位为 1，发送顺序号 seq=Y(随机 int)，接管顺序号 ack=x+1，此时服务器进入 SYN 接管状态。

第三次握手：客户端收到服务器传来的包后，向服务器发送第三个包，SYN=0, ACK=1，接管顺序号 ack = Y+1, 发送顺序号 seq=X+1。此包发送结束，客户端和服务器进入 ESTABLISHED 建设胜利状态，实现三次握手。

为什么要三次握手?

为了避免服务器端开启一些无用的连贯减少服务器开销以及避免已生效的连贯申请报文段忽然又传送到了服务端，因此产生谬误。

因为网络传输是有延时的，在传输的过程中，例如客户端发动了 SYN= 1 创立连贯的申请(第一次握手)，如果服务器端就间接创立了这个连贯并返回蕴含 SYN、ACK 和 Seq 等内容的数据包给客户端，这个数据包因为网络传输的起因失落了。

客户端认为未胜利建设连贯，不会传输报文和敞开连贯申请，服务器端的端口就始终开着，等到客户端因超时从新发出请求时，服务器就会从新开启一个端口连贯，造成服务器端开销的重大节约。

1. 四次挥手

第一次挥手： 被动敞开方（客户端）发送第一个包，其中 FIN 标记位为 1，发送顺序号 seq 为 u。

第二次挥手： 被动敞开方（服务器）收到 FIN 包后发送第二个包，其中发送顺序号 seq 为 v，接管顺序号 ack 为 u +1。

第三次挥手： 被动敞开方（服务器）再发送第三个包，其中 FIN 标记位为 1，发送顺序号 seq 为 w，接管顺序号 ack 为 u +1。

第四次挥手： 被动敞开方（客户端）发送第四个包，其中发送顺序号为 u +1，接管顺序号为 w +1。至此，实现四次挥手

为什么要四次挥手：

建设连贯时，被动方服务器端完结 CLOSED 阶段进入“握手”阶段并不需要任何筹备，能够间接返回 SYN 和 ACK 报文，开始建设连贯。开释连贯时，被动方服务器，忽然收到被动方客户端开释连贯的申请时并不能立刻开释连贯，因为还有必要的数据须要解决，所以服务器先返回 ACK 确认收到报文，通过 CLOSE-WAIT 阶段筹备好开释连贯之后，能力返回 FIN 开释连贯报文。

为什么要等 2MSL:

如果客户端在 2MSL 内，再次收到了来自服务器端的 FIN 报文，阐明服务器端因为各种起因没有接管到客户端收回的 ACK 确认报文。客户端再次向服务器端收回 ACK 确认报文，计时器重置，从新开始 2MSL 的计时；若客户端在 2MSL 内没有再次收到来自服务器端的 FIN 报文，阐明服务器端失常接管了 ACK 确认报文，客户端能够进入 CLOSED 阶段，实现“四次挥手”。

3、TCP 和 UDP

TCP: 传输控制协议（Transmission Control Protocol）

UDP: 用户数据报协定（User Datagram Protocol）

次要区别：

UDP 丢包次要起因

1. 发送的包过大：

   • 若比 64K 大会导致 UDP 协定 sendto 返回谬误。
   • 若比 MTU 大，UDP 包在接收端容易丢包，超过接收者缓存导致丢包。

2. 发送包频率太块：

   • 接收端来不及接管导致丢包。
   • 发送端网卡解决不过去。在发送频率过快的时候思考 sleep 一下。

3. 接收端解决工夫过长：

   • 接收端两次调用 recv 办法接收数据之间发送过去的包可能失落。
   • 解决：能够批改接收端，将包接管后存入一个缓冲区，而后迅速返回持续 recv。

4、HTTP0.9 / HTTP1.0 / HTTP1.1 / HTTP2.0 之间的区别

5、HTTPS 协定

HTTP 协定通常承载于 TCP 协定之上，HTTPS 协定是在 HTTP 和 TCP 之间增加了一个平安协定层（SSL 或 TSL）。

作用：

①对数据进行加密，并建设一个信息安全通道，保障传输过程中的数据安全;

②对网站服务器进行身份认证，如果信息被篡改，通信单方能够立即发现；

③数据完整性校验

HTTPS 和 HTTP 的区别

HTTPS 加密形式：

1. 对称加密（又称密钥加密）

加密和解密都是应用的同一个密钥。常见的对称加密算法有 DES、3DES 和 AES 等。

长处：算法公开、计算量小、加密速度快、加密效率高，适宜加密比拟大的数据。

毛病：交易单方须要应用雷同的密钥，也就无奈防止密钥的传输，而密钥在传输过程中无奈保障不被截获，因而对称加密的安全性得不到保障。每对用户每次应用对称加密算法时，都须要应用其他人不晓得的惟一密钥，这会使得发收信单方所领有的钥匙数量急剧增长，密钥治理成为单方的累赘。对称加密算法在分布式网络系统上应用较为艰难，次要是因为密钥治理艰难，应用老本较高。

1. 非对称加密

加密应用的密钥和解密应用的密钥是不雷同的，别离称为：公钥、私钥；公钥和算法都是公开的，私钥是窃密的。常见的非对称加密技术是 RSA 技术。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥能力解密；如果用私钥对数据进行加密，那么只有用对应的公钥能力解密。

非对称加密算法实现机密信息替换的根本过程是：甲方生成一对密钥并将其中的一把作为公钥对外公开；失去该公钥的乙方应用公钥对机密信息进行加密后再发送给甲方；甲方再用本人保留的私钥对加密后的信息进行解密。

长处：算法公开，加密和解密应用不同的钥匙，私钥不须要通过网络进行传输，安全性很高。

毛病：计算量比拟大，加密和解密速度相比对称加密慢很多。

1. 混合加密：

联合非对称加密和对称加密技术。客户端应用对称加密生成密钥对传输数据进行加密，而后应用非对称加密的公钥再对秘钥进行加密，所以网络上传输的数据是被秘钥加密的密文和用公钥加密后的机密秘钥，因而即便被黑客截取，因为没有私钥，无奈获取到加密明文的秘钥，便无奈获取到明文数据。

HTTPS 的工作流程：

1、建设平安传输

在 TCP 连贯建设实现当前，在 HTTPS 协定中，客户端和服务端会初始化 SSL 层，也就是平安层。

2、SSL 握手

在发送报文之前，客户端和服务端会进行一次 SSL 握手，在这个过程中次要实现以下工作：替换协定版本号——抉择一个两端都理解的明码——对两端的身份进行认证——生成长期会话密钥，以便加密信道（建设完平安通道后，传输报文时应用对称加密）；

这里的认证是通过数字证书进行的，在客户端获取证书后，会采纳相应的算法对服务端的身份信息进行验证，包含：

日期检测：客户端会查看证书的有效期是否非法；

签名颁布者可信度检测：浏览器会附带一个签名颁发机构的授信列表，如果浏览器收到了地位的颁发机构签发的证书，那么它会显示一条正告信息；

签名检测：客户端对签名应用签名颁发机构的公开密钥，而后将其与校验码比拟，以便验证证书是否非法；

站点身份检测：客户端验证数字证书中的域名是否与服务端的域名匹配；

身份认证实现后，客户端与服务端进行明码协商，确定本次连贯采纳哪种加密算法进行通信。

3、开始通信

SSL 握手实现后，就实现建设了 HTTPS 通道，客户端与服务端就会依据协商的加密算法进行通信。

[外链图片转存失败, 源站可能有防盗链机制, 倡议将图片保留下来间接上传(img-B5q64Alx-1596516899310)(C:Users 安哥拉长毛兔 AppDataRoamingTyporatypora-user-imagesimage-20200804113550456.png)]

6、在 PC 浏览器的地址栏输出 URL，从发动申请到收到申请页面响应，产生了什么？

1、首先，在浏览器地址栏中输出 url，先解析 url，检测 url 地址是否非法

2、浏览器先查看浏览器缓存 - 零碎缓存 - 路由器缓存 -ISP 缓存，如果缓存中有，会间接在屏幕中显示页面内容。若没有，则跳到第三步操作。

浏览器缓存：浏览器会记录 DNS 一段时间，因而，只是第一个中央解析 DNS 申请；

操作系统缓存：如果在浏览器缓存中不蕴含这个记录，则会使零碎调用操作系统，获取操作系统的记录(保留最近的 DNS 查问缓存)；

路由器缓存：如果上述两个步骤均不能胜利获取 DNS 记录，持续搜寻路由器缓存；

ISP 缓存：若上述均失败，持续向 ISP 搜寻。

3、在发送 http 申请前，须要域名解析(DNS 解析)，解析获取相应的 IP 地址。

4、浏览器向服务器发动 tcp 连贯，与浏览器建设 tcp 三次握手。

5、握手胜利后，浏览器向服务器发送 http 申请，申请数据包。

6、服务器解决收到的申请，将数据返回至浏览器

7、浏览器收到 HTTP 响应

8、浏览器解码响应，如果响应能够缓存，则存入缓存。

9、浏览器发送申请获取嵌入在 HTML 中的资源（html，css，javascript，图片，音乐 ……），对于未知类型，会弹出对话框。

10、浏览器发送异步申请。

11、页面全副渲染完结。

送给 20 岁本人的一句话：

无论贫困还是富裕，无论疾病或是衰弱，无论顺利或是得志，请你每天都要放弃学一点新货色的状态，至死方休，世间值得。