面经 - 计算机网络知识点

文章目录

资料
协议层次
应用层
- HTTP
- - 缓存机制
  - - 强制缓存
    - 对比缓存
  - HTTP无状态
  - Cookie & Session
  - - cookie
    - session
  - DNS解析
  - HTTP方法
  - - keep-alive和非keep-alive区别
    - HTTP长连接和短连接
    - HTTP方法
    - GET和POST区别
    - HTTP和HTTPS
    - 从地址栏输入URL到显示页面都发生了什么?
  - HTTP3.0（可靠UDP）
  - - 队头阻塞
    - 0RTT建立连接
    - 连接迁移
    - 总结
传输层
- TCP
- - 三次握手
  - - 过程
    - 问题
  - 可靠传输的原理
  - 拥塞控制
  - - 慢开始
    - 拥塞避免
    - 快重传
    - 快恢复
  - 四次挥手
- UDP
- Socket套接字
网络层
数据链路层
物理层

计算机网络知识点

资料

计算机网络面试真题简介

协议层次

大概有三种分层的层次关系，如下所示

其中

应用层：通过应用程序之间的交互完成特定的网络应用。定义了进程之间的交互规则。【HTTP, TFTP, FTP, NFS, WAIS,SMTP, Telnet, DNS, SNMP
】
表示层：使通信的应用程序能够解释交换数据的含义，数据压缩，数据加密以及数据描述。【TIFF, GIF, JPEG, PICT】
会话层：负责建立、管理和终止表示层实体之间的通信会话。该层提供了数据交换的定界和同步功能，包括了建立检查点和恢复方案的方法。【RPC, SQL, NFS, NetBIOS, names, AppleTalk】
传输层：为两台主机进程之间的通信提供服务。应用程序利用该服务传送应用层报文。【TCP、UDP】
网络层：两台计算机之间传送数据时其通信链路往往不止一条，所传输的信息甚至可能经过很多通信子网。网络层的主要任务就是选择合适的网间路由和交换节点，确保数据按时成功传送。【IP, ICMP, ARP, RARP, RIP, IPX】
数据链路层：两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层协议。在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。【FDDI, Frame Relay, HDLC, SLIP, PPP】
物理层：尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。该层的主要任务是确定与传输媒体的接口的一些特性（机械特性、电气特性、功能特性，过程特性）。【EIA/TIA-232, EIA/TIA-499, V.35, 802.3】

应用层

HTTP

头部包括：

通用头部：连接类型（keep-alive）、报文创建时间等
请求头部：Accept接收格式编码等，用户浏览器身份标识UA，认证信息等
响应头部：创建响应的时间、唯一标识分配的资源（etag）等
实体头部：编码方式、长度、返回资源的md5、MIME类型等

HTTP是无状态的，对于交互场景没有记忆能力，

缓存机制

客户端第一次请求数据后，将返回的数据保存到缓存数据库中。
分为强制缓存和对比缓存。
强制缓存在使用的时候如果没过期，可以直接拿来用。如果过期了会像服务器申请新资源。
对比缓存不管中没中缓存，都需要使用从数据库获取到的缓存数据标识发给服务器进行验证，然后返回数据使用。

强制缓存

浏览器请求服务器资源的时候，服务器会将缓存的一些信息规则一块返回，比如Expires/Cache-control，前者是HTTP/1.0的，后者是1.1的，前者设定一定时间后会过期，但是依赖于服务器的时间，是服务器端返回的过期时间，如果客户端时间和服务器端差得多，那就出事了
cache-control呢，有好几个参数，可以选择缓存还是不缓存，缓存的时间等。

对比缓存

有两个标识，一个是最后修改时间（Last-Modified / If-Modified-Since）
需要进行比较判断才能使用缓存，在使用的时候，浏览器先从缓存数据库获取到缓存标识，然后发送给服务器，服务器判断是否过期，如果没有，返回304头部，没有实体部分，速度很快，客户端直接从数据库读取缓存。
第一次请求资源服务器会返回该资源的最后修改时间放在last-Modified字段上，再次请求后，会把这个值放在If-Modified-Since字段里，服务器会比较这个最后修改时间，如果资源修改时间小于等于这个（也就是说没过期），就是304；如果大于（过期了）就是返回200的状态码和资源实体部分。

还有一个是标识（Etag / If-None-Match），这个优先级更高
服务器响应会告诉客户端该资源在服务器的唯一标识，再次请求后，会将该标识和被请求资源的标识进行对比，不一致返回200+实体部分，否则304

HTTP无状态

HTTP的无状态是指其对交互不具有记忆功能，无论什么情况，只要进入这个页面，浏览器就会返回相同的信息，每一次请求都是独立的没有联系的。
当有这么一个场景：比如不同的人在请求同一个页面的时候返回的响应信息不一样，那么就是交互。
比如当登陆网页购物的时候，先进行登录，如果不记忆交互的话，登陆后的下单操作，会不知道是哪个用户在进行的操作，因为记不住之前登录的信息。

Cookie & Session

无状态性阻碍了一些功能的具体实现，现实中在访问某些页面的时候往往需要携带之前访问所获取到的数据等信息，以便进行相应的交互操作，cookir和session就应运而生了。
cookie是一种客户端保存状态的方案，session是一种服务器端保存状态的方案。
用一个类似优惠券举例：cookie相当于给你一张卡片，画满三十次就可以免费吃一次，而session相当于是一张会员卡，你只有类似于会员卡id的信息，每次只需要这个id，店家就可以在系统里查到你画了几次，这个id就是session id，一般也可以用cookie保存。

cookie

是经过加密的，保存在浏览器本地文件里，包括name、过期时间、secure（为空是http，secure是https）等。
可以让浏览器记住用户上次访问的位置等信息，一个比较主要的用途就是自动登录，会记住登陆的相关信息，然后下次访问的时候就会自动登录。
虽然cookie加密了，但是如果被截获，直接把cookie提交给服务器，就完成了登录。

session

登录信息一般用session保存

DNS解析

即使用了TCP协议也使用了UDP协议。
UDP报文最长512字节，TCP允许超过512字节，当DNS查询查过512字节的时候，使用TCP发送。
客户端向DNS服务器查询域名的时候，返回的内容一般不超过512字节，可以用UDP协议，不需要TCP三次握手，响应速度快，负载更低，虽然可以指定使用TCP访问DNS服务器，但是一般只支持UDP。
辅域名服务器会实时向主域名服务器进行查询检测是否有数据发生变化，如果有变化会进行区域传送，对变动的数据进行同步，因为数据量较大而且为了保证可靠性，采用TCP传输。

解析过程如下所示：

浏览器搜索自己的DNS缓存
如果没有，搜索操作系统的缓存以及hosts文件
如果没有，发送请求给本地域名服务器查找，如果找不到，依次询问根域名服务器、顶级一名服务器等，最终返回对应的IP给本地域名服务器
本地域名服务器缓存以后，返回给操作系统
操作系统缓存起来，返回给浏览器

HTTP方法

keep-alive和非keep-alive区别

在HTTP1.0版本中，浏览器的每次请求都需要建立一个新的TCP连接，在请求完成后断开该链接，服务器不会跟踪过去的记录，TCP建立和断开也需要消耗时间和资源。
在HTTP/1.0中默认使用持久连接，需要制定keep-alive，在请求完成后不要关闭连接。

非keep-alive每次请求都需要维护一个新的连接，分配缓冲区和变量，会消耗服务器资源
keep-alive在一次请求响应后不断开连接，可以继续传输数据，甚至同一服务器的多个页面都可以通过一个TCP传输。但是也会造成损耗，可以设置一个timeout，响应多久后没有请求啥的就自动关闭

HTTP长连接和短连接

长连接用于操作频繁、点对点的而且连接较少的场景，如即时通讯和游戏
短连接用于用户量较多的web页面，如淘宝京东，如果使用长连接会造成大量资源浪费

HTTP方法

HTTP/1.0

GET：请求获取页面信息，返回具体内容
POST：提交数据请求处理（上传文件或者提交表单），数据被包含在请求体中，可能会导致新的资源的建立或者已有资源的更新
HEAD：和GET差不多，但是返回的只有头部信息，没有具体内容

HTTP/1.1

OPTIONS：返回指定资源支持的HTTP方法
PATCH：是PUR的补充，用于对已有的资源的局部更新
PUT：指定资源的新增或者更新替换
DELETE：请求服务器删除指定资源
TRACE：回显服务器收到的信息，服务器返回自己收到的信息，用于检测
CONNECT：将服务器作为代理，让服务器代替用户访问

GET和POST区别

GET提交的数据会放在URL中，而且会保存在浏览器记录里，不安全，常用于获取数据。POST提交的数据放在请求体中，不可见，相对安全，用于更新修改服务器资源
GET只支持URL编码，POST支持多种编码
GET只支持ASCII字符，POST支持多种字符
GET提交的数据有大小限制（通常浏览器限制了，大概2k字符，2KB左右），POST没有

GET请求还可以被缓存，可以保存到浏览器的收藏夹里，处理不敏感数据，

HTTP和HTTPS

HTTP（80端口）（Hyper Text Transfer Protocol: 超文本传输协议）是一种简单的请求 - 响应协议，被用于在 Web 浏览器和网站服务器之间传递消息。HTTP 使用 TCP（而不是 UDP）作为它的支撑运输层协议。
一旦建立连接，客户端和服务器端就可以通过套接字接口访问TCP，进行数据的收发。数据是明文的形式，没有加密。
HTTPS（443端口），是以安全为目标的HTTP协议，在 HTTP 的基础上通过传输加密和身份认证的方式保证了传输过程的安全性。

从地址栏输入URL到显示页面都发生了什么?

从地址栏输入URL到显示页面都发生了什么？

DNS 解析：当用户输入一个网址并按下回车键的时候，浏览器获得一个域名，而在实际通信过程中，我们需要的是一个 IP 地址，因此我们需要先把域名转换成相应 IP 地址。
TCP 连接：浏览器通过 DNS 获取到 Web 服务器真正的 IP 地址后，便向 Web 服务器发起 TCP 连接请求，通过 TCP 三次握手建立好连接后，浏览器便可以将 HTTP 请求数据发送给服务器了。
发送 HTTP 请求：浏览器向 Web 服务器发起一个 HTTP 请求，HTTP 协议是建立在 TCP 协议之上的应用层协议，其本质是在建立起的TCP连接中，按照HTTP协议标准发送一个索要网页的请求。在这一过程中，会涉及到负载均衡等操作。
处理请求并返回：服务器获取到客户端的 HTTP 请求后，会根据 HTTP 请求中的内容来决定如何获取相应的文件，并将文件发送给浏览器。
浏览器渲染：浏览器根据响应开始显示页面，首先解析 HTML 文件构建 DOM 树，然后解析 CSS 文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。
断开连接：客户端和服务器通过四次挥手终止 TCP 连接。

HTTP3.0（可靠UDP）

图解｜为什么 HTTP3.0 使用 UDP 协议？
HTTP2.0有着一些比较好的特性，比如其重要的二进制分帧协议、多路复用、头部压缩、服务端推送等功能。
但是有着一些不足之处，如：

建立时间较长
队头阻塞问题
移动互联网表现不佳（弱网场景）

其实这些本质是上都是TCP的缺陷。因此决定使用UDP进行传输。
相对来说UDP的一些优点：

本身无连接，没有连接建立和释放的开销成本
数据包没有队头阻塞问题

提出了QUIC协议，在UDP基础上改造使其具有TCP的优点

队头阻塞

就是一个数据包影响后续所有数据包的传输，这个数据包到不了其他都无法解决。
HTTP2.0使用多路复用解决了HTTP层的队头的阻塞问题，但是TCP的阻塞没有解决。
因为TCP是乱序的，需要将所有数据包按照顺序整合好再传递给上层，如果一个数据包丢失了，就必须等待重传，这样整个链接的数据包都需要等待这个重传的数据包到来才能继续。
QUIC基于UDP的，一个链接可以同时传输多个流，流和流之间不影响，一个流出现丢包对其他流的影响很小。

0RTT建立连接

RTT=往返传播时延+设备排队时延+应用程序处理时延
HTTPS的安全链接建立需要TCP握手和TLS握手，大致2-3个RTT；普通的HTTP也需要一个RTT建立连接。
QUIC可以在第一个数据包里就包含有效的数据信息，直接开始传递数据，不需要进行连接的建立过程。
这里可以分为首次链接和非首次链接
首次链接
需要1RTT进行密钥交换，使用DH算法。
大致过程如下

客户端给服务器端发送client hello请求
服务器端生成一个素数p和g，以及一个随机数s作为私钥，计算g^smod p作为中间结果，将中间结果和p和g发送给客户端
客户端生成随机数c，按照上述模逆计算一个中间结果，对s的中间结果c次方对p求模逆得到k，k就是最终的密钥，将自己的中间结果发给服务器端
服务器端对中间结果s次方求p模逆，得到k
然后再进行一次交换操作，生成M，M是最终的密钥

非首次链接
客户端和服务器端会保留这个密钥包，同样也会过期，客户端过期的话需要重新协商密钥。

前向安全
使用一次K不是永久使用K是为了保证前向安全。
前向安全就是说如果当前密钥泄露，不会影响之前加密消息的安全性。即如果一直使用K加解密，K泄露以后就很不安全。因此会继续协商一个新的密钥。完成交互以后销毁，保证安全性。
前向纠错
在每发送一组数据包的时候，都会对其进行异或操作，计算出结果作为FEC包发送给接收方，接收方使用这个包对数据进行校验是否出现错误

连接迁移

TCP使用五元组标识一个唯一的链接，QUIC使用一个64位ID标识一个唯一的链接，这样在IP或者端口切换的时候不会出现重连或者断开连接的问题。

总结

QUIC其实就是将TCP在内核态进行的数据传输转移到了用户态UDP实现，

传输层

传输层主要有两种协议，传输控制协议（TCP）和用户数据报协议（UDP）。其中面向连接的 TCP 协议保证了数据的传输可靠性，面向无连接的 UDP 协议能够实现数据包简单、快速地传输。
都是有IP地址和端口组成。
常用端口：

DNS：53
TELNET：23
FTP：21
他发图片：69
SSH：22
HTTP：80
HTTPS：443
SNMP：161

TCP

特点：

面向连接的
有拥塞控制、流量控制、差错控制
点对点（一对一）通信
可靠交付
全双工通信（TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据）
面向字节流

TCP建立连接有以下三个步骤：

建立TCP连接，通过三次握手
数据传输，基于TCP的可靠连接进行数据的传输
释放连接，数据传输完成之后需要释放连接，也就是四次挥手

报文中有几个参数

序号：该报文数据载荷的第一个字节的序号，标识该报文，32位比特，到最后一个以后会从0开始
确认号：32位比特，表示期望收到对方发送的下一个报文的数据载荷的第一个字节的序号
确认标志位ACK：取值为1的时候确认号字段才有用，规定在建立连接以后，所有报文的ACK都是1
同步标志位SYN：TCP连接建立时用于同步的序号
终止标志位FIN：用于释放TCP连接

三次握手

TCP建立连接的过程叫做握手，客户端与服务器端需要交换三个TCP报文段。
三次主要是为了避免已经失效的连接请求报文段突然传送到了，从而导致错误。
主要解决以下三个问题：

使得通信双方知道对方的存在
双方协商一些参数（最大窗口值，时间戳选项之类的）
双方对运输实体进行分配（缓存大小等）

参考链接：面试八股 | 计算机网络 | TCP三次握手

过程

如图所示

服务器端创建传输控制块，准备必要的资源，随后进入监听状态，等待客户端连接
客户端创建传输控制块，向服务器端发送TCP连接请求报文段，进入同步已发送状态（SYN-SENT）：SYN设置为1表明这是一个请求报文；初始序列设置为x；不携带数据
服务器端接收到连接请求报文段后，如果同意连接，向客户端发送一个请求确认报文段，进入同步已接收状态：同步位SYN和确认位ACK都设置为1表明这是请求确认报文段；初始化一个序列号seq为y；确认号字段设置为x+1，表明对接收到的初始序号seq的确认；不携带数据
客户端收到请求确认报文后，需要向服务器端返回一个普通的确认报文，，进入连接已建立状态：ACK设置为1标识为普通确认报文；序号字段seq应该为x+1，因为第一个报文段序号是x，这第二个所以是x+1；确认号字段ack为y+1，因为这是对服务器进程的序号y进行确认的（TCP规定普通的TCP确认报文段可以携带数据，但如果不携带数据则不消耗序号，在这种情况下所发送的下一个数据报文段的序号仍是x + 1。）
然后服务器收到普通确认报文以后，也会进入连接已建立状态。
可以进行可靠数据传输了。

问题

是否可以使用两次握手
假设第一次连接请求有延迟或者出现意外没有成功到达服务器端，客户端重发请求，然后直接建立连接成功，没有同步已接收状态，进行数据传输，随后释放连接。如果此时延迟的第一个请求报文到达了，服务器端返回确认确认报文，但是客户端并没有提出申请，所以不理会这个报文，从而导致服务器一直在等待客户端的数据，会浪费资源。
因此采用三报文握手，而不是两报文握手来建立TCP连接，是为了防止已失效的连接请求报文段突然又传送到了TCP服务器进程因而导致错误。
三次握手的主要目的是确认自己和对方的发送和接收都是正常的。如果两次报文的话，客户端可以知道服务器端的接受能力，但是服务器端不知道自己的发送能力

第一次握手是客户端向服务端发消息，询问你有没有接收消息的能力，确保消息能准确发送出去，告诉服务端我有写的能力
第二次握手是指服务端向客户端回消息，标明我收到了消息并且能给你反馈，也就是服务端有读和写的能力
第三次握手是客户端给服务端发消息确认建立连接，是告诉服务端我不仅有写的能力，而且我也有读的能力，咱们可以放心通讯了。

可靠传输的原理

停止等待协议：发送一个，接受确认后在发送下一个，设置超时，如果超时了重传
连续ARQ：
滑动窗口：假设窗口值为5，发送1，2，3，4，5数据包，收到1的确认后窗口向后滑动，发送6

拥塞控制

算法有四种算法：

慢开始
拥塞避免
快重传
快恢复

发送方维护一个拥塞窗口，值取决于当前网络状况，是可以动态变化的。只要网络没有出现拥塞，拥塞窗口就会增大，如果出现拥塞，就会减小。（如果没有按时收到确认报文ack，认定出现拥塞）。发送方会将拥塞窗口作为发送窗口
开始时拥塞窗口默认为1，还有一个慢开始门限。
当拥塞窗口小于门限时，使用慢开始算法；大于时，使用拥塞避免算法；相等时均可。

慢开始

初始拥塞窗口为1，发送窗口＝拥塞窗口。
开始只能发送一个报文，随后收到对方确认报文后，拥塞窗口变为2；此时可以连续发送两个报文，收到两个确认报文后，拥塞窗口变为4，翻倍；随后可以连续发送4个报文，收到四个确认报文以后，拥塞窗口就变为8个了；以此类推
当拥塞窗口的值达到门限值时，将切换为拥塞避免算法。

拥塞避免

每次传输轮次，拥塞窗口只能线性增加1，而慢开始是指数增长。
当出现拥塞了，将重新设定门限值和拥塞窗口值，门限值为发生拥塞时的拥塞窗口值的一半，然后拥塞窗口恢复为1，重新慢开始。
一个栗子：
如下，门限值为16，慢开始，先是1，2，4，8，16，然后开始拥塞避免，开始线性增长，17，18…23，24。
拥塞窗口为24的时候，连续发送24个报文，但是只接收到了20个确认报文，就认定丢失了4个报文，认为网络中出现了拥塞，因此修改门限值为当前拥塞窗口的一半，即12，然后重新开始慢开始

随后又提出了两个新的TCP拥塞控制算法，快重传和快恢复。
有时候可能仅仅是报文的丢失，而并非网络中的拥塞，这时候如果误认为是拥塞的话，重新开始慢开始，会降低传输效率。

快重传

在发送1号报文后，接收到1号确认报文以前，可以发送2号报文；收到2号报文以前可以发送3号报文。
如果有报文没有收到，即3号丢失了，发送方继续发送4号报文，接收方收到以后发现序号不对，将返回2号确认报文表明希望收到3号报文；发送方继续发送5号，接收方收到发现不对，继续返回2号确认报文，表明希望收到3号报文；发送方发送了6号报文，接收方发现序号不对，继续返回2号确认报文
这时候发送方连续收到3个2号确认报文，说明需要重传了，会立刻重传一个3号报文。而不是等超时以后重传。
这就是快重传，连续收到三个重复确认报文以后，将立即重传该报文。
要求：

接收方立即确认
收到无序的报文也要返回重复确认报文
发送方连续收到三个重复确认后要立即重传对应报文，而不是等超时重传

使用快重传，网络吞吐量可以提高20%。

快恢复

当发送方连续收到三个重复确认报文后，会判定仅仅是丢失了个别报文，而不是出现拥塞。不启动满开始算法，启动快恢复算法
发送方将慢开始门限值和拥塞窗口均调整为原先一半，然后开始拥塞避免。

也可以将拥塞窗口设置为新的门限值+3，因为收到三个重复确认就意味着其实已经发送了三个报文了，而且停留在接受方的接收缓冲区里，不需要单独发送了，因此可以跳过这三个报文。

四次挥手

如图所示

客户端发送连接释放报文，停止发送数据，客户端进入终止等待1(FIN-WAIT1)状态：FIN为1；序列号seq为u（前面传过来的数据最后一个字节+1）；FIN报文不携带数据也要消耗一个序号
服务器收到连接释放报文，发出确认报文，服务器端进入关闭等待(CLOSE-WAIT)状态：ACK设为1标明是确认报文；序号seq为v；确认号ack为u+1，期望下一个报文序号是u+1。此时处于半关闭状态，客户端已经没有数据发送了，但是服务器端可能还有数据返回，且客户端也要接受这些数据，就是关闭等待(CLOSE-WAIT)状态
客户端收到确认报文以后，进入终止等待2（FIN-WAIT2）状态，等待服务器端返回连接释放报文，在此期间仍可能会受到服务器端传来的数据
服务器端数据发送完成后，向客户端发送连接释放报文，进入最后确认(LAST-ACK)状态：设置FIN为1，ack仍然为u+1，序号为一个新的值w，等待客户端确认
客户端接收到了连接释放保温以后，需要发出确认报文，进入时间等待（TIME-WAIT）状态：确认报文ACK为1，序号是收到的ack也就是u+1，确认号ack为w+1
客户端等待2 * MSL（最长报文段寿命）后，再撤销TCB进入关闭状态
服务器端收到上一个确认报文以后就释放连接

UDP

特点：

无连接的（发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延）
尽最大努力交付（不保证可靠支付，因此主机不需要维持复杂的连接状态表）
面向报文的（UDP对应用层交下来的报文，添加完首部后就直接交付IP层。如果太长就会分片）
UDP没有拥塞控制
UDP支持一对一、一对多、多对一和多对多的交互通信
UDP的首部开销小（只有8个字节，TCP有20个字节）

Socket套接字

套接字是网络编程中的一种通信机制，是支持TCP/IP的网络通信的基本操作单元，可以看做是不同主机之间的进程进行双向通信的端点。通信的两方的一种约定，用套接字中的相关函数来完成通信过程。
创建socket文件描述符，主要两个参数

domain协议族：
- AF_INET：IPv4
- AF_INET6：IPv6
- AF_LOCAL：Unix域协议
- AF_ROUTE：路由套接口
type套接口类型
- SOCK_STREAM：字节流
- SOCKET_DGRAM：数据包
- RAW：原始套接字

流程
服务器端：

创建socket套接字
bind()绑定端口号
listen()监听
accept()阻塞式接收客户端的连接请求

客户端：

创建socket套接字
connect()连接服务器端

网络层

数据链路层

物理层