网络

UDP与TCP

UDP

UDP是面向无连接的，也就是说不需要在正式传递数据之前先连起双方。然后 UDP 协议只是数据报文的搬运工，不保证有序且不丢失的传递到对端，并且UDP 协议也没有任何控制流量的算法，总的来说 UDP 相较于 TCP 更加的轻便。

1、面向无连接

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

2、不可靠性

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

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

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

3、高效

虽然 UDP 协议不是那么的可靠，但是正是因为它不是那么的可靠，所以也就没有 TCP 那么复杂了，需要保证数据不丢失且有序到达。

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

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

两个十六位的端口号，分别为源端口（可选字段）和目标端口

整个数据报文的长度

整个数据报文的检验和（IPv4 可选 字段），该字段用于发现头部信息和数据中的错误

4、传输方式

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

5、适合使用的场景

UDP 虽然对比 TCP 有很多缺点，但是正是因为这些缺点造就了它高效的特性，在很多实时性要求高的地方都可以看到 UDP 的身影。

直播

如果直播使用了基于 TCP 的协议会发生什么事情？

TCP 会严格控制传输的正确性，一旦有某一个数据对端没有收到，就会停止下来直到对端收到这个数据。这种问题在网络条件不错的情况下可能并不会发生什么事情，但是在网络情况差的时候就会变成画面卡住，然后再继续播放下一帧的情况。

但是对于直播来说，用户肯定关注的是最新的画面，而不是因为网络条件差而丢失的老旧画面，所以 TCP 在这种情况下无用武之地，只会降低用户体验。

王者荣耀

虽然我具体不知道王者荣耀底层使用了什么协议，但是对于这类实时性要求很高的游戏来说，UDP 是跑不了的。

为什么这样说呢？首先对于王者荣耀来说，用户体量是相当大的，如果使用 TCP 连接的话，就可能会出现服务器不够用的情况，因为每台服务器可供支撑的 TCP 连接数量是有限制的。

再者，因为 TCP 会严格控制传输的正确性，如果因为用户网络条件不好就造成页面卡顿然后再传输旧的游戏画面是肯定不能接受的，毕竟对于这类实时性要求很高的游戏来说，最新的游戏画面才是最需要的，而不是老旧的画面，否则角色都不知道死多少次了。

6、小结

（1）UDP 相比 TCP 简单的多，不需要建立连接，不需要验证数据报文，不需要流量控制，只会把想发的数据报文一股脑的丢给对端

（2）虽然 UDP 并没有 TCP 传输来的准确，但是也能在很多实时性要求高的地方有所作为 TCP

TCP 基本是和 UDP 反着来，建立连接断开连接都需要先需要进行握手。在传输数据的过程中，通过各种算法保证数据的可靠性，当然带来的问题就是相比 UDP 来说不那么的高效。 对于 TCP 头部来说，以下几个字段是很重要的：

• Sequence number，这个序号保证了 TCP 传输的报文都是有序的，对端可以通过序号顺序的拼接报文
• Acknowledgement Number，这个序号表示数据接收端期望接收的下一个字节的编号是多少，同时也表示上一个序号的数据已经收到
• Window Size，窗口大小，表示还能接收多少字节的数据，用于流量控制
• 标识符：
• URG=1：该字段为一表示本数据报的数据部分包含紧急信息，是一个高优先级数据报文，此时紧急指针有效。紧急数据一定位于当前数据包数据部分的最前面，紧急指针标明了紧急数据的尾部。
• ACK=1：该字段为一表示确认号字段有效。此外，TCP 还规定在连接建立后传送的所有报文段都必须把 ACK 置为一。
• PSH=1：该字段为一表示接收端应该立即将数据 push 给应用层，而不是等到缓冲区满后再提交。
• RST=1：该字段为一表示当前 TCP 连接出现严重问题，可能需要重新建立 TCP 连接，也可以用于拒绝非法的报文段和拒绝连接请求。
• SYN=1：当SYN=1，ACK=0时，表示当前报文段是一个连接请求报文。当SYN=1，ACK=1时，表示当前报文段是一个同意建立连接的应答报文
• FIN=1：该字段为一表示此报文段是一个释放连接的请求报文。

状态机

TCP 的状态机是很复杂的，并且与建立断开连接时的握手息息相关，接下来就来详细描述下两种握手。

建立连接三次握手

首先假设主动发起请求的一端称为客户端，被动连接的一端称为服务端。不管是客户端还是服务端，TCP 连接建立完后都能发送和接收数据，所以 TCP 是一个全双工的协议。

起初，两端都为 CLOSED 状态。在通信开始前，双方都会创建 TCB。 服务器创建完 TCB 后便进入 LISTEN 状态，此时开始等待客户端发送数据。

第一次握手

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

第二次握手

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

第三次握手

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

PS：第三次握手中可以包含数据，通过快速打开（TFO）技术就可以实现这一功能。其实只要涉及到握手的协议，都可以使用类似 TFO 的方式，客户端和服务端存储相同的 cookie，下次握手时发出 cookie 达到减少 RTT 的目的。

为什么 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 状态。

为什么 A 要进入 TIME-WAIT 状态，等待 2MSL 时间后才进入 CLOSED 状态？

为了保证 B 能收到 A 的确认应答。若 A 发完确认应答后直接进入 CLOSED 状态，如果确认应答因为网络问题一直没有到达，那么会造成 B 不能正常关闭。 滑动窗口

为什么需要滑动窗口？

客户端对每一个发送的数据段都要给一个ACK确认应答，收到ACK后再发送下一个数据段。这个做有一个比较大的缺点就是性能较差，尤其是数据往返的时间较长的时候。既然这样一发一收性能较低，那么如果一次发送多条数据，就可以将多个段的等待时间重叠在一起提高性能了。

滑动窗口是一个很重要的概念，它帮助 TCP 实现了流量控制的功能。接收方通过报文告知发送方还可以发送多少数据，从而保证接收方能够来得及接收数据，防止出现接收方带宽已满，但是发送方还一直发送数据的情况。

Zero 窗口

在发送报文的过程中，可能会遇到对端出现零窗口的情况。在该情况下，发送端会停止发送数据，并启动 persistent timer 。该定时器会定时发送请求给对端，让对端告知窗口大小。在重试次数超过一定次数后，可能会中断 TCP 链接。

拥塞处理

拥塞处理和流量控制不同，后者是作用于接收方，保证接收方来得及接受数据。而前者是作用于网络，防止过多的数据拥塞网络，避免出现网络负载过大的情况。 拥塞处理包括了四个算法，分别为：慢开始，拥塞避免，快速重传，快速恢复。

小结

建立连接需要三次握手，断开连接需要四次握手

滑动窗口解决了数据的丢包、顺序不对和流量控制问题

拥塞窗口实现了对流量的控制，保证在全天候环境下最优的传递数据

TCP、UDP总结

1、TCP的优缺点

（1）TCP的优点：可靠、稳定。它体现在TCP在传递数据之前，会有三次握手来建立连接；在数据传递时，采用校验和、序列号、确认应答、超时重发、流量控制、拥塞控制，为了提高性能，还采用了滑动窗口、延迟应答和捎带应答等机制；在数据传完后，会断开连接以节约系统资源。

（2）TCP的缺点：运行速度慢，效率低，占用系统资源多，易被攻击。因为TCP在传递数据之前，要先建立连接，这会消耗时间；在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，每个连接都会占用系统的CPU、内存等资源；TCP有确认机制、三次握手机制，这导致TCP容易受到DOS、DDOS、CC等攻击。收到STN洪水攻击，是因为使用 TCP的时候服务器端需要listen，这时需要设置backlog。

2、UDP的优缺点

（1）UDP的优点：运行速度较快，比TCP安全。

运行速度快，因为 UDP连接没有TCP的三次握手、确认应答、超时重发、流量控制、拥塞控制等机制，而且UDP是一个无状态的传输协议，所以它在传递数据时非常快。 较安全，因为没有TCP的那些机制，UDP较TCP被攻击者利用的漏洞就会少一些。但UDP也是无法避免攻击的，比如：UDP Flood攻击等

（2）UDP的缺点：不可靠，不稳定。

因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包。

3、TCP和UDP的特点

（1）TCP的特点

TCP协议是一种有连接、可靠的、面向字节流、相对比较慢、点对点的传输层协议。TCP协议适用于对可靠性要求比较高的场合。

（2）UDP的特点

UDP协议是一种无连接，不可靠、面向数据报、速度比较快、可实现一对一，多对一的传输层协议。UDP协议适用于对实时性有要求的场合。因为UDP不保证可靠性，所以UDP也没有重传机制，也没有拥塞机制，它只是尽最大努力交付数据。

HTTP及TLS

HTTP 请求中的内容

HTTP 请求由三部分构成，分别为：请求头、首部、实体

请求行大概长这样 GET /images/logo.gif HTTP/1.1，基本由请求方法、URL、协议版本组成，这其中值得一说的就是请求方法了。

请求方法分为很多种，最常用的也就是 Get 和 Post 了。虽然请求方法有很多，但是更多的是传达一个语义，而不是说 Post 能做的事情 Get 就不能做了。如果你愿意，都使用 Get 请求或者 Post 请求都是可以的。

常考面试题：Post 和 Get 的区别？

1、Get 请求能缓存，Post 不能

2、Post 相对 Get 安全一点点，因为Get 请求都包含在 URL 里（当然你想写到 body 里也是可以的），且会被浏览器保存历史纪录。Post 不会，但是在抓包的情况下都是一样的。

3、URL有长度限制，会影响 Get 请求，但是这个长度限制是浏览器规定的，不是 RFC 规定的

4、Post 支持更多的编码类型且不对数据类型限制

常见状态码

2XX 成功

1、200 OK，表示从客户端发来的请求在服务器端被正确处理

2、204 No content，表示请求成功，但响应报文不含实体的主体部分

3、205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容

4、206 Partial Content，进行范围请求

3XX 重定向

1、301 moved permanently，永久性重定向，表示资源已被分配了新的 URL

2、302 found，临时性重定向，表示资源临时被分配了新的 URL

3、303 see other，表示资源存在着另一个 URL，应使用 GET 方法获取资源

4、304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况

5、307 temporary redirect，临时重定向，和302含义类似，但是期望客户端保持请求方法不变向新的地址发出请求

4XX 客户端错误

1、400 bad request，请求报文存在语法错误

2、401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息

3、403 forbidden，表示对请求资源的访问被服务器拒绝

4、404 not found，表示在服务器上没有找到请求的资源

5XX 服务器错误

1、500 internal sever error，表示服务器端在执行请求时发生了错误

2、501 Not Implemented，表示服务器不支持当前请求所需要的某个功能

3、503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求

HTTPS

HTTPS 还是通过了 HTTP 来传输信息，但是信息通过 TLS 协议进行了加密。

TLS 协议位于传输层之上，应用层之下。首次进行 TLS 协议传输需要两个 RTT ，接下来可以通过 Session Resumption 减少到一个 RTT。

在 TLS 中使用了两种加密技术，分别为：对称加密和非对称加密。

对称加密：

对称加密就是两边拥有相同的秘钥，两边都知道如何将密文加密解密。这种加密方式固然很好，但是问题就在于如何让双方知道秘钥。因为传输数据都是走的网络，如果将秘钥通过网络的方式传递的话，一旦秘钥被截获就没有加密的意义的。

非对称加密：

有公钥私钥之分，公钥所有人都可以知道，可以将数据用公钥加密，但是将数据解密必须使用私钥解密，私钥只有分发公钥的一方才知道。

这种加密方式就可以完美解决对称加密存在的问题。假设现在两端需要使用对称加密，那么在这之前，可以先使用非对称加密交换秘钥。

简单流程如下：首先服务端将公钥公布出去，那么客户端也就知道公钥了。接下来客户端创建一个秘钥，然后通过公钥加密并发送给服务端，服务端接收到密文以后通过私钥解密出正确的秘钥，这时候两端就都知道秘钥是什么了。

TLS 握手过程如下图：

客户端发送一个随机值以及需要的协议和加密方式。

服务端收到客户端的随机值，自己也产生一个随机值，并根据客户端需求的协议和加密方式来使用对应的方式，并且发送自己的证书（如果需要验证客户端证书需要说明）

客户端收到服务端的证书并验证是否有效，验证通过会再生成一个随机值，通过服务端证书的公钥去加密这个随机值并发送给服务端，如果服务端需要验证客户端证书的话会附带证书 服务端收到加密过的随机值并使用私钥解密获得第三个随机值，这时候两端都拥有了三个随机值，可以通过这三个随机值按照之前约定的加密方式生成密钥，接下来的通信就可以通过该密钥来加密解密

通过以上步骤可知，在 TLS 握手阶段，两端使用非对称加密的方式来通信，但是因为非对称加密损耗的性能比对称加密大，所以在正式传输数据时，两端使用对称加密的方式通信。 PS：以上说明的都是 TLS 1.2 协议的握手情况，在 1.3 协议中，首次建立连接只需要一个 RTT，后面恢复连接不需要 RTT 了。

小结

HTTP 经常考到的内容包括：请求方法、首部的作用以及状态码的含义

TLS 中经常考到的内容包括：两种加密方式以及握手的流程

穿插：HTTP2 通过多路复用、二进制流、Header 压缩等等技术，极大地提高了性能，但是还是存在着问题的。QUIC 基于 UDP 实现，是 HTTP/3 中的底层支撑协议，该协议基于 UDP，又取了 TCP 中的精华，实现了即快又可靠的协议

输入 URL 到页面渲染的整个流程

首先是 DNS 查询，如果这一步做了智能 DNS 解析的话，会提供访问速度最快的 IP 地址回来，DNS 的作用就是通过域名查询到具体的 IP。

在 TCP 握手之前就已经进行了 DNS 查询，这个查询是操作系统自己做的。当你在浏览器中想访问 www.google.com 时，会进行一下操作：

1. 操作系统会首先在本地缓存中查询 IP

2. 没有的话会去系统配置的 DNS 服务器中查询

3. 如果这时候还没得话，会直接去 DNS 根服务器查询，这一步查询会找出负责 com 这个一级域名的服务器

4. 然后去该服务器查询 google 这个二级域名

5. 接下来三级域名的查询其实是我们配置的，你可以给 www 这个域名配置一个 IP，然后还可以给别的三级域名配置一个 IP

以上介绍的是 DNS 迭代查询，还有种是递归查询，区别就是前者是由客户端去做请求，后者是由系统配置的 DNS 服务器做请求，得到结果后将数据返回给客户端。

接下来是 TCP 握手，应用层会下发数据给传输层，这里 TCP 协议会指明两端的端口号，然后下发给网络层。网络层中的 IP 协议会确定 IP 地址，并且指示了数据传输中如何跳转路由器。然后包会再被封装到数据链路层的数据帧结构中，最后就是物理层面的传输了。

当 TCP 握手结束后就会进行 TLS 握手，然后就开始正式的传输数据。

数据在进入服务端之前，可能还会先经过负责负载均衡的服务器，它的作用就是将请求合理的分发到多台服务器上，这时假设服务端会响应一个 HTML 文件。

首先浏览器会判断状态码是什么，如果是 200 那就继续解析，如果 400 或 500 的话就会报错，如果 300 的话会进行重定向，这里会有个重定向计数器，避免过多次的重定向，超过次数也会报错。

浏览器开始解析文件，如果是 gzip 格式的话会先解压一下，然后通过文件的编码格式知道该如何去解码文件。

文件解码成功后会正式开始渲染流程，先会根据 HTML 构建 DOM 树，有 CSS 的话会去构建 CSSOM 树。如果遇到 script 标签的话，会判断是否存在 async 或者 defer ，前者会并行进行下载并执行 JS，后者会先下载文件，然后等待 HTML 解析完成后顺序执行。

如果以上都没有，就会阻塞住渲染流程直到 JS 执行完毕。遇到文件下载的会去下载文件，这里如果使用 HTTP/2 协议的话会极大的提高多图的下载效率。

CSSOM 树和 DOM 树构建完成后会开始生成 Render 树，这一步就是确定页面元素的布局、样式等等诸多方面的东西

在生成 Render 树的过程中，浏览器就开始调用 GPU 绘制，合成图层，将内容显示在屏幕上了。