目录
- 概述
- HTTP 与 HTTPS (应用层)
- DNS(应用层)
- TCP 与 UDP(传输层)
- NAT(网络层)
- ARP(网络层)
概述
OSI 和 TCP/IP 网络分层模型
各层传输的数据单位
单位 | 层级 | 描述 |
---|---|---|
数据(Data) | 应用层 | 例如 HTTP 请求、FTP 数据等 |
报文段(Segment) | 传输层 | TCP 使用报文段 |
数据报(Datagram) | 传输层 | UDP 使用数据报 |
数据包(Packet) | 网络层 | 包含 IP 地址,用于跨网络的节点通信 |
帧(Frame) | 链路层 | 包含 MAC 地址,用于同一局域网内的节点通信 |
比特(Bits) | 物理层 | 最基本的传输单位,通过物理介质传输 0/1 |
HTTP 与 HTTPS (应用层)
HTTP vs HTTPS
- HTTP 运行在 TCP 之上,传输的内容都是明文,客户端和服务端间无法验证身份。
- HTTPS 运行在 SSL/TLS 之上,SSL/TLS 运行在 TCP 之上,建立连接时,通过证书颁发机构(CA,Certificate Authority)颁发的证书进行非对称加密,此后传输的内容采用对称加密(效率高),相比 HTTP 安全性更高,但会耗费更多服务器资源。
HTTP/1.0 vs HTTP/1.1
- 连接方式:HTTP/1.0 为短连接,HTTP/1.1 支持长连接。
- 状态响应码:HTTP/1.1 中新加入了大量的状态码。
- 缓存机制:HTTP/1.0 中主要使用
Header
里的If-Modified-Since
、Expires
作为缓存判断的标准,HTTP/1.1 引入了更多的缓存控制策略,如Entity tag
、If-Unmodified-Since
、If-Match
等。 - 带宽:HTTP/1.1 在请求头引入了
range
头域,它允许只请求资源的某个部分而非整个对象,返回码为 206(Partial Content),避免了带宽浪费的现象。 - Host 头:HTTP/1.1 引入了
Host
头字段,允许在同一IP地址上托管多个域名,从而支持虚拟主机的功能。
HTTP/1.1 vs HTTP/2.0
- 多路复用:HTTP/1.1 中每个请求和响应都需要独立的连接;而 HTTP/2.0 在同一连接上可以同时传输多个请求和响应,减少了 TCP 连接数量和网络延迟。
- 二进制帧:HTTP/1.1 使用文本格式的报文进行数据传输;HTTP/2.0 使用更加紧凑的二进制帧,减少了数据传输量和带宽消耗。
- 头部压缩:HTTP/1.1 仅支持对
Body
压缩,HTTP/2.0 支持对Header
压缩。 - 服务器推送:HTTP/2.0 支持服务器推送,在客户端请求一个资源时,将其他相关资源一并推送给客户端,从而减少了客户端的请求次数。
HTTP/2.0 vs HTTP/3.0
- 传输协议:HTTP/2.0 是基于 TCP 协议实现的,HTTP/3.0 新增了 QUIC(Quick UDP Internet Connections)协议来实现可靠传输,在 UDP 的基础上新增了加密、重传等机制,提供与 TLS/SSL 相当的安全性,具有较低的连接和传输延迟。
- 连接建立:HTTP/2.0 需要经过 TCP 三次握手(HTTPS 还需要 TLS 握手,共需要约3个RTT)。而 QUIC 协议采用的 TLS 1.3 连接建立仅需0/1个RTT。
- 连接迁移:HTTP/3.0 支持连接迁移,因为 QUIC 使用64位 ID 标识连接,只要 ID 不变就不会中断,即使从 WiFi 切换到移动数据也能保持连接。而 TCP 连接中一旦源IP/端口,目的IP/端口任意一项发生改变,连接就不能用了
- 队头阻塞:HTTP/2.0 多请求复用一个 TCP 连接,一旦丢包,就会阻塞所有的请求。HTTP/3.0 在一定程度上解决了队头阻塞问题,一个连接建立多个不同的数据流,某个数据流发生丢包了,其它数据流不受影响(多路复用+轮询)。。
- 头部压缩:HTTP/3.0 采用更高效的 QPACK 头部压缩算法。
- 错误恢复:HTTP/3.0 具有更好的错误恢复机制,当出现丢包、延迟等网络问题时,可以更快地恢复和重传;HTTP/2.0 则依赖于 TCP 的错误恢复机制。
- 安全性:HTTP/2.0 中,TLS 不会对 TCP 头部以及 TLS 记录层头部进行加密,可能被攻击者篡改;HTTP/3.0 对整个数据包(包括报文头和报文体)进行了加密。
GET vs POST
- 语义:GET 通常用于获取资源;POST 通常用于创建或修改资源。
- 缓存:GET 请求是幂等的,多次重复执行不会改变资源的状态,因此响应可以被缓存;POST 则不适合被缓存,每次执行可能需要实时响应。
- 格式:GET 的请求参数通常在 URL 中,有长度限制;POST 的请求参数通常在
Body
中,无长度限制,有multipart/form-data
、application/json
等多种编码格式。
WebSocket
一种全双工协议,允许客户端和服务器一直保持连接(通过心跳机制保持活跃状态),随时互相发送数据,直到显式关闭连接。客户端通过向服务器发送一个请求头中包含 Upgrade: websocket
等字段的 HTTP 请求,服务器响应同意后,将连接升级为 WebSocket。由于使用长连接和更简洁的消息头部,WebSocket 在实时性要求高的场景下性能更优,能够减少开销并提升数据传输的效率。
DNS(应用层)
DNS 服务器
DNS 服务器自底向上可以依次分为以下几个层级:
- 根 DNS 服务器:提供 TLD DNS 服务器的 IP 地址。目前世界上只有13组根服务器,我国境内目前仍没有根服务器。
- 顶级域(TLD)DNS 服务器:提供权威 DNS 服务器的 IP 地址。顶级域指域名的后缀,如
com
、org
、edu
、uk
、fr
等。 - 权威 DNS 服务器:在因特网上具有公共可访问主机的每个组织机构必须提供公共可访问的 DNS 记录,这些记录将这些主机的名字映射为 IP 地址。
- 本地 DNS 服务器:每个 ISP(互联网服务提供商)都有一个自己的本地 DNS 服务器。当主机发出 DNS 请求时,该请求被发往本地 DNS 服务器,它起着代理的作用,并将该请求转发到 DNS 层次结构中。严格说来,不属于 DNS 层级结构。
DNS 工作流程
有如下图两种方式:迭代、递归。
以迭代为例,假设主机 cis.poly.edu
想查询 gaia.cs.umass.edu
的 IP 地址。主机 cis.poly.edu
的本地 DNS 服务器为 dns.poly.edu
,gaia.cs.umass.edu
的权威 DNS 服务器为 dns.cs.umass.edu
。
- 主机
cis.poly.edu
向本地 DNS 服务器dns.poly.edu
发送一个 DNS 请求,查询域名gaia.cs.umass.edu
。 - 本地 DNS 服务器
dns.poly.edu
发现本地无此缓存记录,向根服务器发送请求。 - 根服务器将
edu
的 TLD DNS 服务器地址返回给本地 DNS 服务器。 - 本地 DNS 服务器向TLD DNS 服务器请求
gaia.cs.umass.edu
的地址。 - TLD DNS 服务器仍不知道
gaia.cs.umass.edu
的地址,将umass.edu
的权威 DNS 服务器地址返回给本地 DNS 服务器。 - 本地 DNS 服务器向权威 DNS 服务器
dns.cs.umass.edu
发送请求。 - 权威 DNS 服务器返回
gaia.cs.umass.edu
的地址给本地 DNS 服务器。 - 本地 DNS 服务器将地址返回给主机。
DNS 记录
资源记录(Resource Record,RR):DNS 服务器的数据库条目,是一个包含了 Name
, Value
, Type
, TTL
四个字段的四元组。TTL
指该记录的生存时间,决定了什么时候从缓存中删除;而 Name
和 Value
字段的取值取决于 Type
的类型:
A
:IPv4,Name
为主机名,Value
为主机名对应的 IP 地址。AAAA
:IPv6,同上。CNAME
:Value
是别名为Name
的主机对应的规范主机名,能够为现有的A
记录创建别名。MX
:Value
是别名为Name
的邮件服务器的规范主机名,使邮件服务器可以和其他服务器使用相同的别名。NS
:由 TLD 服务器发布,Name
是个域,Value
是个知道如何获得该域中主机 IP 地址的权威 DNS 服务器的主机名。
TCP 与 UDP(传输层)
TCP 与 UDP 的区别
- 是否面向连接:TCP 在传送数据前必须建立连接,传送结束后要释放连接。UDP 在传送数据之前无需先建立连接。
- 是否可靠传输:TCP 提供可靠的传输服务,在数据传递前,通过三次握手建立连接;在数据传递时,有确认、窗口、重传、拥塞控制等机制,保证数据无差错、不丢失、不重复、且按序到达。UDP 传输是不可靠的,远地主机在收到 UDP 报文后,不需要给出任何确认,不保证数据不丢失以及是否按序。
- 是否有状态:TCP 传输是有状态的(即记录消息的状态,如是否发送成功、是否被接收等),需要维持复杂的连接状态表。UDP 是无状态服务,消息发出去后就不管了。
- 传输效率:UDP 的传输效率要比 TCP 高很多,实时性更高。
- 传输形式:TCP 面向字节流(数据分割成报文段),UDP 面向报文(完整数据包)。
- 首部开销:TCP 首部开销(20~60 字节)比 UDP(8 字节)更大。
- 是否能广播/多播:TCP 只支持一对一,UDP 还支持一对多、多对一、多对多。
应用场景:TCP 用于对传输准确性要求特别高的场景,如邮件、文件传输、远程登录等。UDP 一般用于即时通信,如语音、 视频、直播、游戏等,这些场景对传输数据的准确性要求不是特别高,少个一两帧区别也不大。
协议名 传输协议 描述 HTTP TCP(3.0之前)/ UDP 超文本传输协议 HTTPS TCP 更安全的超文本传输协议 FTP TCP 文件传输协议 SMTP TCP 简单邮件传输协议 POP3 / IMAP TCP 邮件接收协议 Telnet TCP 远程登录协议 SSH TCP 更安全的远程登录协议 DHCP UDP 动态主机配置协议 DNS UDP / TCP 域名解析
TCP 三次握手
第一次握手:Server
确认对方发送正常,自己接收正常。
第二次握手:Client
确认自己发送正常、接收正常,对方发送正常、接收正常。
第三次握手:Server
确认自己发送正常、接收正常,对方发送正常、接收正常。
第三次握手是可以携带数据的,如果携带数据的包中包含了 ACK
标记,服务端会将其视为有效的第三次握手确认。
丢包情况分析
- 第一次握手被丢:
A
周期性超时重传,直到收到B
的确认。 - 第二次握手被丢:
B
周期性超时重传,直到收到A
的确认。 第三次握手被丢:
A
单方面Established
。- 若
A
无数据发送,B
周期性超时重传,直到收到A
的确认。 - 若
A
有数据发送,B
收到A
的Data + ACK
,自动切换为Established
,并接受Data
。
- 若
第二次握手传回了 ACK,为什么还要传回 SYN?
ACK
: 表示服务器确认收到了客户端的SYN
请求:“我收到了你的请求”。SYN
: 表示服务器愿意与客户端建立连接:“我也愿意建立连接”。
半连接队列和全连接队列
Linux 内核维护两个队列来处理并发的连接请求。当队列达到上限时,新的连接请求会被拒绝或忽略。
- 半连接队列(SYN Queue):服务端收到
SYN
请求时,还没有完全建立连接,服务端会把半连接状态的连接放在半连接队列。 - 全连接队列(Accept Queue):服务端收到
ACK
响应时,三次握手成功完成,服务端会把连接从半连接队列移动到全连接队列。如果未收到ACK
响应,则会进行重传:重传的等待时间通常是指数增长的;如果重传次数超过系统规定的最大次数,连接会从半连接队列中删除。
TCP 四次挥手
第一次挥手:A
说 “我没啥要说的了”。
第二次挥手:B
说 “我知道了”,但 B
可能还有要说的话(非三次挥手的原因)。
第三次挥手:B
可能巴拉巴拉说了一通后,最后说 “我说完了”。
第四次挥手:A
说 “知道了”,这样通话才算结束。
为什么要四次挥手?
TCP 是全双工通信,可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知,待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候,则发出连接释放通知,对方确认后就完全关闭了 TCP 连接。
丢包情况分析
- 第一/二次挥手被丢:客户端没有收到
ACK
确认,会重新发送FIN
请求。 - 第三次挥手被丢:服务端没有收到
ACK
确认,会重新发送FIN
请求。 第四次挥手被丢:服务端没有收到
ACK
确认,会重新发送FIN
请求。如果客户端在2MSL
时间内再次收到了FIN
,就会重新发送ACK
并再次等待2MSL
,防止服务端不断重发FIN
。MSL(Maximum Segment Lifetime) : 一个片段在网络中最大的存活时间。如果直到
2MSL
(一个发送和一个回复所需的最大时间),客户端都没有再次收到FIN
,就可以推断ACK
已被成功接收,结束连接。
TCP 如何保证传输的可靠性
差错检测
- 基于数据块传输:应用数据被分割成 TCP 认为最适合发送的数据块,再传输给网络层,数据块被称为报文段或段。
- CRC校验:TCP 将保持它首部和数据的检验和,如果收到段的检验和有差错,TCP 将丢弃这个报文段(不确认收到)。
- 按序到达和去重:TCP 为防止丢包,给每个包一个序列号,将接收到的数据按序列号排序,并且去掉重复序列号的数据。
- 重传:在数据包丢失或延迟的情况下重新发送数据包,直到收到对方的
ACK
。
- 拥塞控制:慢开始、 拥塞避免、快速重传和恢复。
- 流量控制:滑动窗口控制发送方发送速率,通过接收方发送的确认报文中窗口字段来控制发送方窗口大小。
NAT(网络层)
网络地址转换(Network Address Translation),解决 IPv4 地址数量有限的问题,通过端口映射的方式将私有网络中的内部 IP 地址转换为公共网络中的外部 IP 地址。
ARP(网络层)
地址解析协议(Address Resolution Protocol),解决网络层地址(IP)和链路层地址(MAC)间的转换问题。
- ARP表:局域网中,每个网络设备都维护了一个 ARP 表,用于记录其他网络设备的 IP 地址 - MAC 地址的映射关系(
<IP, MAC, TTL>
)。 - 广播问询:若表中无要找的 IP 地址的映射,则构造一个查询分组在局域网内广播。
- 单播响应:收到查询分组的主机验证是否是对自己的问询,如果不是,则丢弃;如果是,则构造一个响应分组单播返回,且双方都将对方的 IP-MAC 映射关系加入到自己的 ARP 表中。
不同局域网内的 MAC 寻址
文章标题:计算机网络八股
文章作者:nek0peko
文章链接:https://nek0peko.com/index.php/archives/194/
商业转载请联系站长获得授权,非商业转载请注明本文出处及文章链接,未经站长允许不得对文章文字内容进行修改演绎。
本文采用创作共用保留署名-非商业-禁止演绎4.0国际许可证