后端面试常见题目及知识点（二）---计算机网络

2020年09月20日 23:18:33

349

文章分类: 后端面试

# 系列文章目录
1. [操作系统（Linux）](https://blog.csdn.net/kewei168/article/details/108690001)
2. [计算机网络](https://blog.csdn.net/kewei168/article/details/108690391)
3. [数据库](https://blog.csdn.net/kewei168/article/details/108700434)
4. [其他](https://blog.csdn.net/kewei168/article/details/108700482)

[TOC]

计算机网络常见问题：TCP & UDP，HTTP & HTTPS等

# OSI 7层，TCP/IP 5层协议

![](https://img-blog.csdnimg.cn/20200920103728986.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tld2VpMTY4,size_16,color_FFFFFF,t_70#pic_center)
* 物理层 --- 如何传输一个bit（e.g. FDM，TDM）
* 数据链路层 --- 如何正确传输一组bit，功能：framing，纠错等，**MAC地址**
* 网络层 --- 如何将一个包从源地址发送到目的地址，**IP地址**
* 运输层 --- 提供可靠/稳定的网络传输（抽象下层的所有网络细节），**TCP/UDP**
* 应用层 --- 利用传输层提供的网络连接，实现不同应用，如：**HTTP**，FTP，SMTP...

# TCP/UDP

## TCP/UDP的区别与联系

* TCP vs UDP
* 基于连接 vs 无连接
* 资源较多 vs 资源较少（轻量）
* 结构复杂 vs 结构简单 --- header 20字节（还有optional字段，总共最长60字节） vs 8字节
* 流模式（Byte Stream） vs 数据报模式
* 可靠传输 vs 不保证送达
* 保证顺序接收（seq） vs 不保证
* **拥塞控制** vs 无
* 保活 vs 无
    * 如果已经建立了TCP连接但是客户端突然发生了故障（不接受数据，无法回复），TCP有一个保活计时器，服务器每收到一次客户端的请求都会重置改计时器，若规定时间内没收到客户端的任何消息，服务器会发送探测报文，一连发送10个都无反应的话，主动关闭连接

## TCP/UDP各自的应用场景

* TCP
    * **HTTP**，FTP，SMTP，POP3，TELNET
    * 发消息，发邮件，文件传输（数据量不大，且需要保证不丢失）
* UDP
    * DNS --- 就是要快
    * 视频聊天/直播，即使丢失几个画面影响也不大，同时数据量大需要速度，减小overhead

## TCP如何做到可靠传输

* ACK + SEQ
* 检验和
* 超时重传
* 窗口控制
* 连接管理

## TCP/UDP头部多大，含有什么字段

* TCP 头部最少20字节（无optional），最多60字节（含optional）
    * 源，目的端口，各2字节
    * 序列号，确认号，各4字节
    * ...
    * 检验和，2字节
* UDP头部8字节（源，目的端口，长度，检验和各2字节）

## TCP三次握手，四次挥手

![在这里插入图片描述](https://img-blog.csdnimg.cn/img_convert/34ec733c77ee1cfd98341824f106beca.png#pic_center)

* 握手
    * ---> SYN
    * <--- SYN ACK
    * ---> ACK
* 挥手
    * ---> FIN， ACK
    * <--- ACK
    * <--- FIN
    * ---> ACK

## 为什么需要三次握手

* 为什么3不是2：为了防止服务器端收到已失效的连接请求报文，造成错误；如有一个连接请求由于网络拥塞很久才到达（此时客户端已经和服务器端建立了TCP连接），服务器收到该请求后，假如返回ACK+SYN并立刻建立连接，那就会白白浪费资源，因为此时客户端根本不会使用该条连接。
* 为什么3不是4：提高效率，服务器返回的SYN和ACK可以放到一个包里面

## 为什么需要四次挥手

因为client端主动断开连接的时候，服务器端可能还有部分数据没有发送完毕，所以ACK和FIN不能一起发送。

## 为什么连接时候是三次，但是断开的时候是四次

因为连接的时候，服务器可以把SYN和ACK一起发送回去，ACK用于应答，SYN用于同步；但是关闭连接时，服务器只能先发ACK表示收到FIN消息，但是要等所有数据都发送完毕之后，才能发送FIN。

## TCP半连接 （SYN攻击）

在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接(half-open connect，此时处于SYN_RECV状态)；服务器会维护一个半连接队列，存放所有当前的半连接，当收到客户端的ACK之后，会将对应的条目取出放入全连接队列中。注：服务器会定期重传SYN-ACK包，当重传次数超过系统设置最大次数，则丢弃该条目；

SYN攻击与DOS攻击很类似，利用了TCP的特性，短时间内发送大量“半连接请求”（故意丢弃服务端发回来的ACK-SYN），使得服务器的半连接队列满，从而无法接受新的连接。`netstat -n -p TCP | grep SYN_RECV`若发现大量连接处于SYN_RECV状态，大概率是SYN攻击。

## TIME_WAIT

有什么作用？为什么是2MSL（Maximum Segment Lifetime）？MSL一般是多长时间![在这里插入图片描述](https://img-blog.csdnimg.cn/20200920104826482.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tld2VpMTY4,size_16,color_FFFFFF,t_70#pic_center)

因为client发送完最后的ACK之后，服务器可能会没收到，那么就会重复发送FIN给client，所以client需要等待一段时间，2MSL是为了一个发送（服务器发送FIN）和一个回复（客户端回复ACK）所需的最大时间。  注：MSL一般实现为30秒，RFC建议2分钟。
TIME_WAIT只出现在主动关闭连接方，大部分情况都是客户端主动关闭，但是也有服务器端主动关闭，如：一个简易的HTTP服务器，客户端发送HTTP请求后，服务器返回RESPONSE之后立刻主动关闭连接。

服务器端TIME_WAIT过多的原因：
1. 网络拥塞，不断重发最后一个ACK（TIME_WAIT过程中，这条连接无法被复用）
2. 短时间内高并发的短连接 （如1秒内100万条TCP连接，并且每次连接只持续10秒）

## CLOSE_WAIT

服务端在收到客户端发来的FIN请求，返回一个ACK后就会进入CLOSE_WAIT状态，此时服务器在等待上层应用调用`close()`方法断开连接，假如此时上层应用出现异常退出，没有close，就会卡死在这里。

CLOSE_WAIT过多的原因：上层程序设计有问题，没能调用`close()`函数

## TCP拥塞控制

* **慢开始**，**拥塞避免**（cwnd拥塞窗口，ssthresh慢开始门限）
    * cwnd < ssthresh，慢开始算法 --- 每次RTT往返，cwnd加倍
    * cwnd > ssthresh，拥塞避免算法 --- 每次RTT往返，cwnd加1
    * 如果RTT内没收到回复，ssthresh设置为当前窗口的一半并把cwnd设为1，重新开始
* **快重传**，**快恢复**
    * 快重传：接收端一旦收到失序报文，立刻发送重复确认，发送端若连续收到三个重复确认则立刻重传（不等超时）
    * 快恢复：接收端收到三个重复确认之后，将sshthresh设置为当前窗口一半并将cwnd设置为ssthresh的值
* 优化框架：Google提出的BBR算法，腾讯的TCPA

## TCP 粘包

由于数据量较小，发送端将多个TCP包合并成一个后发送 / 接收端长时间未接收，多个包到达缓冲区被合并成一个。因为TCP是基于流传输的，所以会出现这样的情况（UDP是基于数据报的，所以不会出现这种情况）。解决方法是可以自己在待传输的数据里面增加一个数据长度之类的（e.g. HTTP POST data的chunk模式，每个chunk前面会有数据的长度），或者使用特殊的分界符（e.g. HTTP头部`\n\n`分界）。

## Socket编程
### Select 和 Epoll
* 都属于NIO（Non-blocking IO）
* Select是监听多个fd，任意一个准备好后通知程序，程序遍历所有fd处理，`O(n)`
* Epoll底层用红黑树进行优化，同时通过回调函数的形式，通知程序进行处理，`O(1)`（回调函数直接处理事件）
### connect()
* 指定对向地址和端口号
* TCP中调用`connect()`方法，底层经历三次握手
* UDP中调用`connect()`方法，只是记录目标地址和端口，不会有任何其他操作
* 对比：TCP调用几千次`connect()`会造成几千个连接，反之UDP只会保存最后一次的地址和端口号（不断覆盖）

# HTTP

## HTTP有哪些请求方式

* 最最最常规：GET & POST
    * 一个是只读 （建议，当然也可以写），一个是可写
    * 参数在URL里面还是在body里面
* HEAD，DELETE，PUT，CONNECT（模仿HTTPS），OPTIONS，PATCH，TRACE

## 从浏览器输入一个网址开始到看到网页，中间发生了什么

1. URL解析
    * 首先判断浏览器有无本地缓存，缓存是否过期，是否需要重新验证
    * 从而判断是否需要发起网络请求，需要的话继续下一步
2. DNS查询（域名 --- IP 映射）
    * 查询顺序
    * 查询方法（递归 + 迭代）
3. 建立TCP连接
    * 三次握手 & 四次挥手
    * 半连接
    * TIME_WAIT，CLOSE_WAIT
4. 发送HTTP请求报文（request）
    * 请求报文结构
    * 请求方式（GET，POST...）
5. 服务器处理请求
6. 浏览器接收响应（response）
    * 响应报文结构？
7. 浏览器渲染页面（HTML，CSS，JavaScript...）

## DNS域名解析的顺序/原理

* core：**递归+迭代**
    * 递归：一路找下去，没有结果不返回
    * 迭代：多次查找（多次返回结果）

![在这里插入图片描述](https://img-blog.csdnimg.cn/img_convert/959153a52206e079da63f453b3f68b10.png#pic_center)

* 查询顺序：
    * 浏览器缓存 ---> 本机缓存（localhost）---> **路由器** ---> 本地DNS （递归）
    * 本地DNS ---> 根域名（迭代）
* 首先查根域名，根域名不知道，去.com域名服务器查，逐级往下

![在这里插入图片描述](https://img-blog.csdnimg.cn/20200920230734853.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tld2VpMTY4,size_16,color_FFFFFF,t_70#pic_center)

#### 如何定位资源，URL V.S. URI

* URL：Universal Resource Locator
* URI：Universal Resource Identifier

区别在于一个是Locator一个是Identifier，URL是URI的子集，URI是一种编号，可以定位区分某个资源的一种独一无二的编号，如身份证号；URL是一个位置/地址，一个可以定位某一具体资源的独一无二的地址，如住址详细到房间号

#### HTTP请求（request）/回应（response）的组成

request

第一行结构：`请求方法（GET， POST...）URL HTTP协议版本号 `

紧接着：Header（键值对的形式定义各种参数，如Host）

optional：body（针对POST请求，还会有body包含所有信息）

```http
GET /~bmr23/ece568/class.html HTTP/1.1
Host: people.duke.edu
```

response

第一行结构：`HTTP协议版本号 响应代码 响应内容`（代码和内容一般一一对应，如`200 OK`， `404 Not Found`）

紧接着：Header（键值对的形式定义各种参数，如Date，body数据长度）

optional：body，假如是请求文件，返回的文件内容会在body里面

```http
HTTP/1.1 200 OK
Date: Wed, 25 Mar 2020 00:29:28 GMT
Server: Apache
```

#### HTTP长短连接的联系与区别，现在用哪种比较多

* 短连接：client和server每进行一次HTTP操作，就建立一次连接，任务结束就中断连接（只有一次数据往返）
* 长连接：打开网页后，连接不会关闭（TCP连接），若再次访问该server上的资源，会继续使用已有连接
    * 需指定：`Connection: keep-alive`
    * 拓展，TCP长连接，保活，心跳检测
* HTTP 1.0默认使用短连接，HTTP 1.1默认使用长连接
* 长连接的好处，HTTP长连接其实本质上是TCP长连接，这样访问一个网页可以用同一个TC连接发送接收多个HTTP请求，如：请求一个网站，可能会需要得到html，css，JavaScript，图片等多个文件（分别是不同的HTTP请求），使用长连接的话就可以**复用**同一个TCP连接，overhead较小

#### HTTP vs HTTPs

一句话概括，HTTP明文传输报文不够安全，故HTTPs会加密报文后再进行传输。具体加密流程：

* 对称加密 vs 非对称加密
    * 对称加密：双方使用同一个密钥进行加解密，问题：如果这个密钥被攻击者得知了，就没用了
    * 非对称加密：公钥和私钥，客户端保存私钥，发送公钥给服务端
* 能否只使用非对称加密？
    * 不行，因为这个只能保证一个方向的安全传输（服务器到客户端，因为私钥只有客户端知道），假设公钥被攻击者得到了，那么所有客户端发过来的数据，攻击者都可以解密
* 那能否使用两套公钥密钥从而保证双向安全？
    * 可以，但是开销太大，非对称加密的运算开销远大于对称加密（一般来说对称加密都是位运算，很快；但是非对称加密可能涉及取模，大数乘法之类的）
* 对称加密 + 非对称加密
    * 可以，HTTPs就是采用的这种方案。服务器生成公钥（K）和私钥（K'），将公钥传输给客户端，客户端拿到K之后，生成一个自己的密钥X（用于对称加密），然后用K加密后将X传输给服务器，最后所有信息都用X来进行对称加密
* 最后一个问题，中间人攻击（替换掉了K）
    * CA，数字证书，可信的第三方机构颁发证书给服务器，客户端会验证证书的有效性（数字签名）
        * CA：拥有非对称加密的私钥和公钥。
        * CA对证书明文信息进行hash。
        * 对hash后的值用私钥加密，得到数字签名。
        * 客户端：拿到证书，得到明文T，数字签名S。
        * 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥），得到S’。
        * 用证书里说明的hash算法对明文T进行hash得到T’。
        * 比较S’是否等于T’，等于则表明证书可信
        * 攻击者若修改了证书明文部分，由于没有私钥，不可能修改签名部分