UDP

面向报文

UDP 是一个面向报文（报文可以理解为一段段的数据）的协定。意义就是 UDP 只是报文的搬运工，不会对报文举行任何拆分和拼接操纵。

详细来讲

• 在发送端，运用层将数据通报给传输层的 UDP 协定，UDP 只会给数据增添一个 UDP 头标识下是 UDP 协定，然后就通报给收集层了
• 在吸收端，收集层将数据通报给传输层，UDP 只去除 IP 报文头就通报给运用层，不会任何拼接操纵

不可靠性

1. UDP 是无衔接的，也就是说通讯不须要竖立和断开衔接。
2. UDP 也是不可靠的。协定收到什么数据就通报什么数据，而且也不会备份数据，对方能不能收到是不关心的
3. UDP 没有堵塞掌握，一向会以恒定的速度发送数据。纵然收集前提不好，也不会对发送速度举行调解。如许完成的弊病就是在收集前提不好的状况下可以会致使丢包，然则长处也很明显，在某些及时性请求高的场景（比方电话会议）就须要运用 UDP 而不是 TCP。

高效

由于 UDP 没有 TCP 那末庞杂，须要保证数据不丧失且有序到达。所以 UDP 的头部开支小，只需八字节，比拟 TCP 的最少二十字节要少许多，在传输数据报文时是很高效的。

头部包含了以下几个数据

• 两个十六位的端口号，分别为源端口（可选字段）和目标端口
• 悉数数据报文的长度
• 悉数数据报文的磨练和（IPv4 可选 字段），该字段用于发明头部信息和数据中的毛病

传输体式格局

UDP 不止支撑一对一的传输体式格局，一样支撑一对多，多对多，多对一的体式格局，也就是说 UDP 供应了单播，多播，播送的功用。

TCP

头部

TCP 头部比 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：该字段为一示意此报文段是一个开释衔接的请求报文。

状况机

HTTP 是无衔接的，所以作为基层的 TCP 协定也是无衔接的，虽然看似 TCP 将两头衔接了起来，然则实在只是两头配合保护了一个状况

TCP 的状况机是很庞杂的，而且与竖立断开衔接时的握手息息相干，接下来就来详细描述下两种握手。

在这之前须要相识一个主要的机能目标 RTT。该目标示意发送端发送数据到吸收到对端数据所需的往复时刻。

竖立衔接三次握手

在 TCP 协定中，主动提议请求的一端为客户端，被动衔接的一端称为服务端。不管是客户端还是服务端，TCP 衔接竖立完后都能发送和吸收数据，所以 TCP 也是一个全双工的协定。

早先，两头都为 CLOSED 状况。在通讯最先前，双方都邑建立 TCB。 服务器建立完 TCB 后遍进入 LISTEN 状况，此时最先守候客户端发送数据。

第一次握手

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

第二次握手

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

第三次握手

当客户端收到衔接赞同的应对后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入ESTABLISHED 状况，服务端收到这个应对后也进入 ESTABLISHED 状况，此时衔接竖立胜利。

PS：第三次握手可以包含数据，经由历程 TCP 疾速翻开（TFO）手艺。实在只需涉及到握手的协定，都可以运用相似 TFO 的体式格局，客户端和服务端存储雷同 cookie，下次握手时发出 cookie 到达削减 RTT 的目标。

你是不是有迷惑明显两次握手就可以竖立起衔接，为何还须要第三次应对？

由于这是为了防备失效的衔接请求报文段被服务端吸收，从而发作毛病。

可以设想以下场景。客户端发送了一个衔接请求 A，然则由于收集缘由形成了超时，这时刻 TCP 会启动超时重传的机制再次发送一个衔接请求 B。此时请求顺遂到达服务端，服务端应对完就竖立了请求。如果衔接请求 A 在两头封闭后终究到达了服务端，那末这时刻服务端会以为客户端又须要竖立 TCP 衔接，从而应对了该请求并进入 ESTABLISHED 状况。此时客户端实际上是 CLOSED 状况，那末就会致使服务端一向守候，形成资本的糟蹋。

PS：在竖立衔接中，恣意一端掉线，TCP 都邑重发 SYN 包，平常会重试五次，在竖立衔接中可以会碰到 SYN FLOOD 进击。碰到这类状况你可以挑选调低重试次数或许痛快在不能处置惩罚的状况下谢绝请求。

断开链接四次握手

TCP 是全双工的，在断开衔接时两头都须要发送 FIN 和 ACK。

第一次握手

若客户端 A 以为数据发送完成，则它须要向服务端 B 发送衔接开释请求。

第二次握手

B 收到衔接开释请求后，会通知运用层要开释 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状况，示意 A 到 B 的衔接已开释，不吸收 A 发的数据了。然则由于 TCP 衔接时双向的，所以 B 依旧可以发送数据给 A。

第三次握手

B 如果此时另有没发完的数据会继承发送，终了后会向 A 发送衔接开释请求，然后 B 便进入 LAST-ACK 状况。

PS：经由历程耽误确认的手艺（一般有时刻限定，不然对方会误以为须要重传），可以将第二次和第三次握手兼并，耽误 ACK 包的发送。

第四次握手

A 收到开释请求后，向 B 发送确认应对，此时 A 进入 TIME-WAIT 状况。该状况会延续 2MSL（最大段生计期，指报文段在收集中生计的时刻，超时会被扬弃） 时刻，若该时刻段内没有 B 的重发请求的话，就进入 CLOSED 状况。当 B 收到确认应对后，也便进入 CLOSED 状况。

为何 A 要进入 TIME-WAIT 状况，守候 2MSL 时刻后才进入 CLOSED 状况？

为了保证 B 能收到 A 的确认应对。若 A 发完确认应对后直接进入 CLOSED 状况，如果确认应对由于收集题目一向没有到达，那末会形成 B 不能一般封闭。

ARQ 协定

ARQ 协定也就是超时重传机制。经由历程确认和超时机制保证了数据的准确送达，ARQ 协定包含住手守候 ARQ 和一连 ARQ

住手守候 ARQ

一般传输历程

只需 A 向 B 发送一段报文，都要住手发送并启动一个定时器，守候对端回应，在定时器时刻内吸收到对端应对就作废定时器并发送下一段报文。

报文丧失或失足

在报文传输的历程当中可以会涌现丢包。这时刻候凌驾定时器设定的时刻就会再次发送丢包的数据直到对端相应，所以须要每次都备份发送的数据。

纵然报文一般的传输到对端，也可以涌现在传输历程当中报文失足的题目。这时刻候对端会扬弃该报文并守候 A 端重传。

PS：平常定时器设定的时刻都邑大于一个 RTT 的均匀时刻。

ACK 超时或丧失

对端传输的应对也可以涌现丧失或超时的状况。那末凌驾定时器时刻 A 端还是会重传报文。这时刻候 B 端收到雷同序号的报文会抛弃该报文并重传应对，直到 A 端发送下一个序号的报文。

在超时的状况下也可以涌现应对很迟到达，这时刻 A 端会推断该序号是不是已吸收过，如果吸收过只须要抛弃应对即可。

这个协定的瑕玷就是传输效力低，在优越的收集环境下每次发送报文都得守候对端的 ACK 。

一连 ARQ

在一连 ARQ 中，发送端具有一个发送窗口，可以在没有收到应对的状况下延续发送窗口内的数据，如许比拟住手守候 ARQ 协定来讲削减了守候时刻，进步了效力。

累计确认

一连 ARQ 中，吸收端会延续不停收到报文。如果和住手守候 ARQ 中吸收一个报文就发送一个应对一样，就太糟蹋资本了。经由历程累计确认，可以在收到多个报文今后一致复兴一个应对报文。报文中的 ACK 可以用来通知发送端这个序号之前的数据已悉数吸收到了，下次请发送这个序号 + 1的数据。

然则累计确认也有一个弊病。在一连吸收报文时，可以会碰到吸收到序号 5 的报文后，并未接到序号 6 的报文，但是序号 7 今后的报文已吸收。碰到这类状况时，ACK 只能复兴 6，如许会形成发送端反复发送数据，这类状况下可以经由历程 Sack 来处理，这个会在下文说到。

滑动窗口

在上面小节中讲到了发送窗口。在 TCP 中，两头都保护着窗口：分别为发送端窗口和吸收端窗口。

发送端窗口包含已发送但未收到应对的数据和可以发送然则未发送的数据。

发送端窗口是由吸收窗口盈余大小决议的。吸收方会把当前吸收窗口的盈余大小写入应对报文，发送端收到应对后依据该值和当前收集堵塞状况设置发送窗口的大小，所以发送窗口的大小是不停变化的。

当发送端吸收到应对报文后，会随之将窗口举行滑动

滑动窗口完成了流量掌握。吸收方经由历程报文示知发送方还可以发送若干数据，从而保证吸收方可以来得及吸收数据。

Zero 窗口

在发送报文的历程当中，可以会碰到对端涌现零窗口的状况。在该状况下，发送端会住手发送数据，并启动 persistent timer 。该定时器会定时发送请求给对端，让对端示知窗口大小。在重试次数凌驾一定次数后，可以会中缀 TCP 链接。

堵塞处置惩罚

堵塞处置惩罚和流量掌握差别，后者是作用于吸收方，保证吸收方来得及接收数据。而前者是作用于收集，防备过量的数据堵塞收集，防止涌现收集负载过大的状况。

堵塞处置惩罚包含了四个算法，分别为：慢最先，堵塞防止，疾速重传，疾速恢复。

慢最先算法

慢最先算法，望文生义，就是在传输最先时将发送窗口逐步指数级扩展，从而防止一最先就传输大批数据致使收集堵塞。

慢最先算法步骤详细以下

1. 衔接初始设置堵塞窗口（Congestion Window） 为 1 MSS（一个分段的最大数据量）
2. 每过一个 RTT 就将窗口大小乘二
3. 指数级增进一定不能没有限定的，所以有一个阈值限定，当窗口大小大于阈值时就会启动堵塞防止算法。

堵塞防止算法

堵塞防止算法比拟简单点，每过一个 RTT 窗口大小只加一，如许可以防止指数级增进致使收集堵塞，逐步将大小调解到最佳值。

在传输历程当中可以定时器超时的状况，这时刻候 TCP 会以为收集堵塞了，会立时举行以下步骤：

• 将阈值设为当前堵塞窗口的一半
• 将堵塞窗口设为 1 MSS
• 启动堵塞防止算法

疾速重传

疾速重传平常和快恢复一同涌现。一旦吸收端收到的报文涌现失序的状况，吸收端只会复兴末了一个递次准确的报文序号（没有 Sack 的状况下）。如果收到三个反复的 ACK，无需守候定时器超时再重发而是启动疾速重传。详细算法分为两种：

TCP Taho 完成以下

• 将阈值设为当前堵塞窗口的一半
• 将堵塞窗口设为 1 MSS
• 从新最先慢最先算法

TCP Reno 完成以下

• 堵塞窗口减半
• 将阈值设为当前堵塞窗口
• 进入快恢复阶段（重发对端须要的包，一旦收到一个新的 ACK 回复就退出该阶段）
• 运用堵塞防止算法

TCP New Ren 革新后的快恢复

TCP New Reno 算法革新了之前 TCP Reno 算法的缺点。在之前，快恢复中只需收到一个新的 ACK 包，就会退出快恢复。

在 TCP New Reno 中，TCP 发送方先记下三个反复 ACK 的分段的最大序号。

如果我有一个分段数据是 1 ~ 10 这十个序号的报文，个中丧失了序号为 3 和 7 的报文，那末该分段的最大序号就是 10。发送端只会收到 ACK 序号为 3 的应对。这时刻候重发序号为 3 的报文，吸收方顺遂吸收并会发送 ACK 序号为 7 的应对。这时刻候 TCP 晓得对端是有多个包未收到，会继承发送序号为 7 的报文，吸收方顺遂吸收并会发送 ACK 序号为 11 的应对，这时刻发送端以为这个分段吸收端已顺遂吸收，接下来会退出快恢复阶段。

HTTP

HTTP 协定是个无状况协定，不会保留状况。

Post 和 Get 的区分

先引入副作用和幂等的观点。

副作用指对服务器上的资本做转变，搜刮是无副作用的，注册是副作用的。

幂等指发送 M 和 N 次请求（二者不雷同且都大于 1），服务器上资本的状况一致，比方注册 10 个和 11 个帐号是不幂等的，对文章举行变动 10 次和 11 次是幂等的。

在范例的运用场景上说，Get 多用于无副作用，幂等的场景，比方搜刮关键字。Post 多用于副作用，不幂等的场景，比方注册。

在手艺上说：

• Get 请求能缓存，Post 不能
• Post 相对 Get 平安一点点，由于Get 请求都包含在 URL 里，且会被浏览器保留历史纪录，Post 不会，然则在抓包的状况下都是一样的。
• Post 可以经由历程 request body来传输比 Get 更多的数据，Get 没有这个手艺
• URL有长度限定，会影响 Get 请求，然则这个长度限定是浏览器划定的，不是 RFC 划定的
• Post 支撑更多的编码范例且不对数据范例限定

罕见状况码

2XX 胜利

• 200 OK，示意从客户端发来的请求在服务器端被准确处置惩罚
• 204 No content，示意请求胜利，但相应报文不含实体的主体部份
• 205 Reset Content，示意请求胜利，但相应报文不含实体的主体部份，然则与 204 相应差别在于请求请求方重置内容
• 206 Partial Content，举行局限请求

3XX 重定向

• 301 moved permanently，永久性重定向，示意资本已被分配了新的 URL
• 302 found，临时性重定向，示意资本临时被分配了新的 URL
• 303 see other，示意资本存在着另一个 URL，应运用 GET 要领猎取资本
• 304 not modified，示意服务器许可接见资本，但因发作请求未满足前提的状况
• 307 temporary redirect，临时重定向，和302寄义相似，然则希冀客户端坚持请求要领不变向新的地点发出请求

4XX 客户端毛病

• 400 bad request，请求报文存在语法毛病
• 401 unauthorized，示意发送的请求须要有经由历程 HTTP 认证的认证信息
• 403 forbidden，示意对请求资本的接见被服务器谢绝
• 404 not found，示意在服务器上没有找到请求的资本

5XX 服务器毛病

• 500 internal sever error，示意服务器端在实行请求时发作了毛病
• 501 Not Implemented，示意服务器不支撑当前请求所须要的某个功用
• 503 service unavailable，表明服务器临时处于超负载或正在停机保护，没法处置惩罚请求

HTTP 首部

PS：缓存相干已在别的模块中写完，你可以 浏览该小节

HTTPS

HTTPS 还是经由历程了 HTTP 来传输信息，然则信息经由历程 TLS 协定举行了加密。

TLS

TLS 协定位于传输层之上，运用层之下。初次举行 TLS 协定传输须要两个 RTT ，接下来可以经由历程 Session Resumption 削减到一个 RTT。

在 TLS 中运用了两种加密手艺，分别为：对称加密和非对称加密。

对称加密：

对称加密就是双方具有雷同的秘钥，双方都晓得怎样将密文加密解密。

非对称加密：

有公钥私钥之分，公钥一切人都可以晓得，可以将数据用公钥加密，然则将数据解密必需运用私钥解密，私钥只需分发公钥的一刚刚晓得。

TLS 握手历程以下图：

1. 客户端发送一个随机值，须要的协定和加密体式格局
2. 服务端收到客户端的随机值，本身也发作一个随机值，并依据客户端需求的协定和加密体式格局来运用对应的体式格局，发送本身的证书（如果须要考证客户端证书须要申明）
3. 客户端收到服务端的证书并考证是不是有用，考证经由历程会再天生一个随机值，经由历程服务端证书的公钥去加密这个随机值并发送给服务端，如果服务端须要考证客户端证书的话会附带证书
4. 服务端收到加密过的随机值并运用私钥解密取得第三个随机值，这时刻候两头都具有了三个随机值，可以经由历程这三个随机值根据之前商定的加密体式格局天生密钥，接下来的通讯就可以经由历程该密钥来加密解密

经由历程以上步骤可知，在 TLS 握手阶段，两头运用非对称加密的体式格局来通讯，然则由于非对称加密消耗的机能比对称加密大，所以在正式传输数据时，两头运用对称加密的体式格局通讯。

PS：以上申明的都是 TLS 1.2 协定的握手状况，在 1.3 协定中，初次竖立衔接只须要一个 RTT，背面恢复衔接不须要 RTT 了。

HTTP 2.0

HTTP 2.0 比拟于 HTTP 1.X，可以说是大幅度进步了 web 的机能。

在 HTTP 1.X 中，为了机能斟酌，我们会引入雪碧图、将小图内联、运用多个域名等等的体式格局。这一切都是由于浏览器限定了同一个域名下的请求数目，当页面中须要请求许多资本的时刻，队头壅塞（Head of line blocking）会致使在到达最大请求数目时，盈余的资本须要守候其他资本请求完成后才提议请求。

你可以经由历程 该链接 感觉下 HTTP 2.0 比 HTTP 1.X 究竟快了若干。

在 HTTP 1.X 中，由于队头壅塞的缘由，你会发明请求是如许的

在 HTTP 2.0 中，由于引入了多路复用，你会发明请求是如许的

二进制传输

HTTP 2.0 中一切增强机能的中心点在于此。在之前的 HTTP 版本中，我们是经由历程文本的体式格局传输数据。在 HTTP 2.0 中引入了新的编码机制，一切传输的数据都邑被支解，并采纳二进制花样编码。

多路复用

在 HTTP 2.0 中，有两个非常主要的观点，分别是帧（frame）和流（stream）。

帧代表着最小的数据单元，每一个帧会标识出该帧属于哪一个流，流也就是多个帧构成的数据流。

多路复用，就是在一个 TCP 衔接中可以存在多条流。换句话说，也就是可以发送多个请求，对端可以经由历程帧中的标识晓得属于哪一个请求。经由历程这个手艺，可以防止 HTTP 旧版本中的队头壅塞题目，极大的进步传输机能。

Header 紧缩

在 HTTP 1.X 中，我们运用文本的情势传输 header，在 header 照顾 cookie 的状况下，可以每次都须要反复传输几百到几千的字节。

在 HTTP 2.0 中，运用了 HPACK 紧缩花样对传输的 header 举行编码，削减了 header 的大小。并在两头保护了索引表，用于纪录涌现过的 header ，背面在传输历程当中就可以传输已纪录过的 header 的键名，对端收到数据后就可以经由历程键名找到对应的值。

服务端 Push

在 HTTP 2.0 中，服务端可以在客户端某个请求后，主动推送其他资本。

可以设想以下状况，某些资本客户端是一定会请求的，这时刻就可以采用服务端 push 的手艺，提早给客户端推送必要的资本，如许就可以相对削减一点耽误时刻。固然在浏览器兼容的状况下你也可以运用 prefetch 。

QUIC

这是一个谷歌出品的基于 UDP 完成的同为传输层的协定，目标很弘远，愿望替换 TCP 协定。

• 该协定支撑多路复用，虽然 HTTP 2.0 也支撑多路复用，然则基层还是 TCP，由于 TCP 的重传机制，只需一个包丧失就得推断丧失包而且重传，致使发作队头壅塞的题目，然则 UDP 没有这个机制
• 完成了本身的加密协定，经由历程相似 TCP 的 TFO 机制可以完成 0-RTT，固然 TLS 1.3 已完成了 0-RTT 了

• 支撑重传和纠错机制（向前恢复），在只丧失一个包的状况下不须要重传，运用纠错机制恢复丧失的包

  • 纠错机制：经由历程异或的体式格局，算出发出去的数据的异或值并零丁发出一个包，服务端在发明有一个包丧失的状况下，经由历程其他数据包和异或值包算出丧失包
  • 在丧失两个包或以上的状况就运用重传机制，由于算不出来了

DNS

DNS 的作用就是经由历程域名查询到详细的 IP。

由于 IP 存在数字和英文的组合（IPv6），很不利于人类影象，所以就涌现了域名。你可以把域名看成是某个 IP 的别号，DNS 就是去查询这个别号的真正称号是什么。

在 TCP 握手之前就已举行了 DNS 查询，这个查询是操纵系统本身做的。当你在浏览器中想接见 www.google.com 时，会举行一下操纵：

1. 操纵系统会起首在当地缓存中查询
2. 没有的话会去系统设置的 DNS 服务器中查询
3. 如果这时刻候还没得话，会直接去 DNS 根服务器查询，这一步查询会找出担任 com 这个一级域名的服务器
4. 然后去该服务器查询 google 这个二级域名
5. 接下来三级域名的查询实际上是我们设置的，你可以给 www 这个域名设置一个 IP，然后还可以给别的三级域名设置一个 IP

以上引见的是 DNS 迭代查询，另有种是递归查询，区分就是前者是由客户端去做请求，后者是由系统设置的 DNS 服务器做请求，获得效果后将数据返回给客户端。

PS：DNS 是基于 UDP 做的查询。

从输入 URL 到页面加载完成的历程

这是一个很典范的面试题，在这题中可以将本文讲得内容都串连起来。

1. 起首做 DNS 查询，如果这一步做了智能 DNS 剖析的话，会供应接见速度最快的 IP 地点返来
2. 接下来是 TCP 握手，运用层会下发数据给传输层，这里 TCP 协定会指明两头的端口号，然后下发给收集层。收集层中的 IP 协定会肯定 IP 地点，而且指导了数据传输中怎样跳转路由器。然后包会再被封装到数据链路层的数据帧构造中，末了就是物理层面的传输了
3. TCP 握手完毕后会举行 TLS 握手，然后就最先正式的传输数据
4. 数据在进入服务端之前，可以还会先经由担任负载平衡的服务器，它的作用就是将请求合理的分发到多台服务器上，这时刻假定服务端会相应一个 HTML 文件
5. 起首浏览器会推断状况码是什么，如果是 200 那就继承剖析，如果 400 或 500 的话就会报错，如果 300 的话会举行重定向，这里会有个重定向计数器，防止过量次的重定向，凌驾次数也会报错
6. 浏览器最先剖析文件，如果是 gzip 花样的话会先解压一下，然后经由历程文件的编码花样晓得该怎样去解码文件
7. 文件解码胜利后会正式最先衬着流程，先会依据 HTML 构建 DOM 树，有 CSS 的话会去构建 CSSOM 树。如果碰到 script 标签的话，会推断是不是存在 async 或许 defer ，前者会并行举行下载并实行 JS，后者会先下载文件，然后守候 HTML 剖析完成后递次实行，如果以上都没有，就会壅塞住衬着流程直到 JS 实行终了。碰到文件下载的会去下载文件，这里如果运用 HTTP 2.0 协定的话会极大的进步多图的下载效力。
8. 初始的 HTML 被完整加载和剖析后会触发 DOMContentLoaded 事宜
9. CSSOM 树和 DOM 树构建完成后会最先天生 Render 树，这一步就是肯定页面元素的规划、款式等等诸多方面的东西
10. 在天生 Render 树的历程当中，浏览器就最先挪用 GPU 绘制，合成图层，将内容显现在屏幕上了