计算机网络基础知识校招面经整理、热身

计算机网络基础知识

TCP 和 UDP 区别：

TCP 是面向连接的运输层协议
通过三次握手、四次挥手等机制建立和拆除连接，只能一对一通信
通过重传、流量控制、拥塞控制等机制实现可靠的数据传输
面向字节流，将应用层传递来的数据视为无差别的字节流
首部 20-60 字节

UDP 是无连接的运输层协议
支持多对多交互通信
不保证数据可靠到达。
面向报文，将应用层传递来的报文直接加上首部后发送
首部仅 8 字节

TCP 建立连接后，发送方发送一个包，接收端在收到包之前出现故障，会发生什么：

这类故障的题目，抓住 2 个重点：
一、端口是否关闭，若端口关闭，会返回 RST 报文，发送方收到后自行关闭连接。
二、数据包是否到达接收方，接收方能否发送应答报文，应答报文能否发送回发送方。其中任何一环出问题，发送方会重传报文直到次数超限关闭连接、或者直到报文成功送达。

• 进程挂了
  接收端进程关闭后，通信的端口随之关闭，不处于监听状态，则接收端向发送端返回一个 RST 报文，发送方收到这个报文后直接关闭自己的连接。
• 服务器宕机
  发送端发送的报文无回应，会超时重传直到超出次数限制，默认为 12次，约 9 分钟后关闭连接。若期间服务器恢复，同进程挂了的情况。

网络模型：

• OSI 7 层体系结构
  • 应用层
  • 表示层
  • 会话层
  • 运输层
  • 网络层
  • 数据链路层
  • 物理层
• TCP/IP 4 层体系结构
  • 应用层
  • 运输层
  • 网络层
  • 网络接口层
• 5 层体系结构
  • 应用层：用于应用程序之间的交互，该层数据称为 报文，常见协议：HTTP、SMTP、DNS
  • 运输层：为两台主机进程通信提供数据传输服务，常见协议：TCP、UDP
  • 网络层：选择合适的 网间路由和 交换节点，常见协议：IP、ARP（将 IP 地址和 同一网络中的 MAC 地址进行映射）、ICMP（传输控制消息）
  • 数据链路层：把网络层的 IP 数据包封装成帧，在两个网络节点的链路上传递，常见协议：PPP
  • 物理层：实现相邻计算机节点之间比特流的透明传送，屏蔽掉实际传输介质的差异。

写一个网络程序 demo 大概有哪些过程：

盲猜问的是 socket 网络编程需要实现的接口，一般可分为 TCP 编程 和 UDP 编程

• TCP 编程：
  • 服务端
    • create 创建套接字，初始化并得到文件描述符
    • bind 绑定 IP 地址和端口号
    • listen 监听连接
    • accept 接受连接请求，返回用于传输的 socket 文件描述符（阻塞调用，对应客户端 connect，响应 TCP 连接请求，发出第 2 次握手请求）
    • write/read 用此套接字发送接收数据
    • close 关闭套接字（开启 TCP 4 次挥手，会让 read 读到 EOF，进行第 2 次挥手）
  • 客户端
    • create 创建套接字，初始化并得到文件描述符
    • connect 发起连接建立请求 （阻塞调用，对应服务端 accept，发起 TCP 三次握手）
    • write/read 发送接收数据
    • close 关闭 socket（开启 TCP 4 次挥手，会让 read 读到 EOF，进行第 2 次挥手）

TCP 三次握手四次挥手：

• 三次握手
  • 客户端 closed - synSent - established
  • 服务器 listen - synRCVD - established
  • 客户端发起连接请求，报文 SYN、seq = x，状态打开为 SYN-SENT
  • 服务器收到后，返回应答，报文 SYN、ACK、seq = y、ack = x + 1，状态打开为 SYN-RCVD
  • 客户端收到后，返回应答，报文 ACK、seq = x + 1、ack = y + 1，可以携带数据，状态打开为 ESTABLISHED
  • 服务器收到后，状态也打开为 ESTABLISHED
• 四次挥手
  • 客户端 established - finWait1- finWait2 - timeWait - closed
  • 服务器 established - closewait - lastACK - closed
  • 客户端发起关闭请求，报文 FIN、seq = u，状态打开为 FIN-WAIT1
  • 服务器收到后，返回应答，报文 ACK、seq = v、ack = u + 1，状态打开为 CLOSE-WAIT
  • 客户端收到应答报文，状态打开为 FIN-WAIT2，等待服务器传输剩余的数据
  • 服务器传输完最后的数据，发送关闭请求，报文 FIN、ACK、seq = w、ack = u + 1，状态打开为 LAST-ACK
  • 客户端收到后，返回应答，确认关闭，报文 ACK、seq = u + 1、ack = w + 1，状态打开为 TIME-WAIT
  • 服务器收到后，关闭连接，状态进入 CLOSED
  • 客户端等待 2MSL 后，关闭连接，状态进入 CLOSED

HTTP 报文结构

HTTP 报文分为「请求报文」(Request)、「响应报文」(Response)两类。注意 HTTP 报文是以 ASCⅡ 码编码的，可以直接阅读。

请求报文 Request

• 请求报文分为 请求行 Request line、请求头 Header lines (前两者一定有) 和 报文体 Entity body (不一定有，根据请求所属的 Method 类别，如 HEAD 就没有，而 GET 规范要求没有)
  • Request line：方法名 Method (如 GET、POST、PUT 等)、URL、HTTP协议版本号
  • Header： Header 可以有很多个字段，每个字段单独成一行，以 字段名 + 字段值 的形式出现。以下列举一些常见的字段：
    • Host: 目标的服务器地址和端口
    • User-Agent: 客户端 版本
    • Accept: 客户端请求的内容格式，如 image/jpeg 表示请求的内容为图片，且格式为jpeg， text/html 表示请求的内容为文本，且格式为 html，application/json 表示请求的内容为超媒体，且格式为 json。
    • Accept-Language：客户段支持的语言
    • Accept-Encoding：客户端支持的压缩编码
    • Accept-Charset：客户端支持的字符集
    • Keep-Alive：指明一个 timeout 时间
    • Connection：Keep-alive HTTP 1.1 默认启用，是否使用持久化连接
    • Tranfer-Encoding：chunked 设定传输编码使用分块传输，在keep-alive 模式下，一段未知长度的内容以一系列连续的固定大小的分块传输，并以一个body长度为 0 的分块结尾。
  • Entity body：如果方法名为 PUT、POST，则将请求体中的内容写入到对应的 URL 资源中。

响应报文 Response

• 响应报文类似，分为 状态行 Status line、响应头 Header lines 和数据 Data
  • Status line：协议版本、状态码、状态字
  • Header：类似，有多个字段：
    • Date：日期
    • Server：服务器 版本
    • Last-Modified：资源时间版本号
    • ETag：资源标签
    • Accept-Ranges：bytes / none 资源界定的单位，便于断点续传标识
    • Content-Length：指明返回数据的长度
    • Keep-Alive：Timeout 闲置时间，max 此持久连接可承载的最多请求次数
    • Content-Type：呼应 Accept 及 Accept-Charset 的内容，指出所传文件的内容格式、字符集
  • Data：报文正文数据

HTTP 请求方法

• GET：一般不允许有 Entity Body，将所提交的表单信息加在 URL 尾部，向服务器请求特定资源，幂等(重复操作不影响资源状态)，提交表单信息受限于 URL 长度(不同 Web 服务器和浏览器提供的限制不同，常见有 8KB、16KB等等)
• HEAD：GET的简化版，服务器对此请求，只会返回一个与 GET 方法对应的 HEADER，而不包括所请求的资源（可以用来确认是否存在 URL 所指定的资源而暂不请求）
• POST：用于请求服务器创建资源，Entity Body 中包含提交的表单信息。每次提交都会创建资源，因而是非幂等的。
• PUT：用于请求服务器将资源根据提交的信息替换，Entity Body 中包含完整的资源信息，同一个请求无论重复多少次，资源状态都相同（提交的信息相同），因是幂等的。
• PATCH：用于请求服务器将资源的某部分字段根据提交的信息更新，Entity Body 中包含资源的部分信息，会调用服务器程序提供的接口进行更新操作，因而有可能非幂等。
• DELETE：用于请求服务器删除资源，幂等。

HTTP 响应状态码：

• 1XX 信息 接收的请求正在处理
  • 100 Continue，常见于响应 POST 的 Header (POST 请求分连续两次发送，第一次发送 HEADER，第二次发送 Entity Body)
• 2XX 成功 请求正常处理完毕（）
  • 200 OK，返回所需的资源，常用于响应 GET 请求 和 POST 请求的 Entity Body
  • 201 Created，成功创建了资源，创建的资源 URL 会附在后续的 Header 中 Location 字段
• 3XX 重定向 需要进行附加操作以完成请求
  • 301 Moved Permanently，所需资源已经移动，新的 URI 会附在后续的 Header 中 Location 字段，并被浏览器缓存
  • 302 Moved Temporarily，所需资源临时移动，通常会给浏览器发送 HTTP Location 头部来重定向到新位置，但浏览器不会缓存新的 URI
• 4XX 客户端错误 服务器无法处理请求
  • 400 Bad Request，请求含有语法错误，无法被服务器识别
  • 403 Forbidden，服务器拒绝了请求
  • 404 Not Found，服务器无法根据此请求找到资源
  • 408 Request Timeout，服务器等待超时
• 5XX 服务器错误 服务器处理时出错
  • 500 Internal Server Error，服务器内部错误
  • 501 Not Implemented，服务器不支持此功能
  • 502 Bad Gateway，代理（网关）服务器连接远程目标服务器超时，无法给予正确的响应
  • 505 HTTP Version Not Supported，服务器不支持所请求的 HTTP 协议版本

浏览器中输入 URL 到显示内容发生了什么：

• 对 URL 进行解析，提取出协议号、域名、端口、路径、请求信息等信息
• DNS 解析，获取域名对应的 IP 地址 （可能会定位到反向代理的地址）
• 和 IP 地址目的服务器建立 TCP 连接
• 通过 TCP 连接发送 HTTP 请求，Cookie 等信息就存在 http 请求的报文体中
  • 应用层发送 HTTP 请求
  • 传输层发送 TCP 报文
  • 在网络层，通过路由表查找下一跳地址，通过 ARP 协议等手段确定链路层的目标 MAC 地址
• 服务器处理请求
  • HTTPD（如 apache Nginx 等） 监听请求，并启动子进程处理
  • 解析 HTTP 请求，方法、域名、路径等，并进行验证
  • 是否重定向
  • 是否重写 URL，将需要返回的资源封装入报文
  • 返回 HTTP 响应报文
• 浏览器解析 HTTP 响应报文并渲染页面

HTTP 可以有哪些机制来确定报文结束：

面猿辅导被问到这个问题，而且是两面中间追问（二面面试官看了一面面评跟着话头问下去）。答得不是很好，因此翻了一些博客整理记录一下。
确定报文结束大致可以有如下三种方法：

• 总长确定：如果可以确定报文的总长度，直接利用 Content-Length 头域表示实体长度。当接收端收到了累计这个长度的报文时，即可确认该段报文已经传输完毕。
• 关闭连接：如果无法确定报文的总长，可以由发送方返回一个 EOF 标志(-1) 主动关闭 TCP 连接，表明后续无内容传输。
• 分块传输编码：如果无法确定报文的总长，并且又暂时不想关闭连接，如果双方支持 Http/1.1 协议版本，则可以利用 Transfer-Encoding 头域（域值指定为 chunked），用一个个指定长度的块(chunk) 传输编码直接定义传输长度大小（chunk-size），那么最后一个块（名为 Footer 块）标记的长度为 0，且封装了一些标记信息，可以表示报文结束。