常见面试题的基础总结（计网篇）

叁歲伎倆 2022-01-15 13:43 244阅读 0赞

> 由于这些内容都是比较早之前进行的整理的，所以有的部分是参考了他人的博文，但是由于是之前找的，所以具体的博文链接找不到了，如果原博主看到这个文章或者有人知道其中部分内容的原博文，请与我联系，我将加上原链接，谢谢

--------------------

### 1、OSI七层协议模型 TCP/IP四层体系结构 ###

<table> 
 <thead> 
  <tr> 
   <th>OSI七层协议模型</th> 
   <th>TCP/IP四层体系结构</th> 
   <th>对应网络协议</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>应用层</td> 
   <td>应用层（对应OSI应用层、表示层、会话层）</td> 
   <td>HTTP、TFTP、NFS、WAIS、SMTP</td> 
  </tr> 
  <tr> 
   <td>表示层</td> 
   <td></td> 
   <td>Telnet、Rlogin、SNMP、Gopher</td> 
  </tr> 
  <tr> 
   <td>会话层</td> 
   <td></td> 
   <td>SMTP、DNS</td> 
  </tr> 
  <tr> 
   <td>传输层</td> 
   <td>传输层</td> 
   <td>TCP、UDP</td> 
  </tr> 
  <tr> 
   <td>网络层</td> 
   <td></td> 
   <td>IP、ICMP、ARP、RARP、AKP、UUCP</td> 
  </tr> 
  <tr> 
   <td>数据链路层</td> 
   <td>网络接口层（对应OSI数据链路层、物理层）</td> 
   <td>FDDI、Ethernet、Arpanet、PDN、SLIP、PPP</td> 
  </tr> 
  <tr> 
   <td>物理层</td> 
   <td></td> 
   <td>IEEE 802.1A、IEEE 802.2到IEEE 802.11</td> 
  </tr> 
 </tbody> 
</table>

--------------------

### 2、TCP三次握手: ###

*  C端:客户端; S服务端
 *  第一次握手: C端向S端发送SYN数据包〈SYN=1，序列号=x)。A迸入SYN\_ SENT状志，等待服务端确认。
 *  第二次握手: S端收到SYN数据包并进行确认(SYN=1, ACK number=x+1, ACK=1,序列号=y)，再发送SYN+ACK数据包给C端，S端迸入SYN\_ RCVD状志。
 *  第三次握手: C端收到SYN+ACK数据包，如果ACK number=x+1,将ACK number设置为y+1, ACK=1，向S端发送ACK数据包，C端和S端都进入ESTABLISHED (已连接)状志。
 *  简述:我连你，你同意，我再连你（成功）。

![在这里插入图片描述][20190613113024807.png]

##### 为什么要三次握手? #####

为了防止已失效的连接请求报文段突然又传到了服务端，产生错误。同时保证发送双方的消息发送与接收功能都可用。

>  *  解释:报文段已发送，在某个网络节点发生滞留，导致连接释放,释放后报文才到达另一端。
>  *  例如: C端发送SYN报文给S端，连接被释放后，S端才收到报文并误认为这是C端的新连接，给C端发送SYN+ACK报文，这是无法得到C端回应的，因为连接已无效。

--------------------

### 3、TCP四次挥手 ###

*  第一次挥手: A给B发送FIN报文(序列号=x)，A进入FIN\_WAIT\_1状态，表示A没有数据给B了。
 *  第二次挥手: B收到FIN报文后，给A发送ACK报文(ACK=x+1)，A进入FIN\_WAIT\_2状态,B同意A关闭请求。
 *  第三次挥手: B向A发送FIN报文(序列号=y)，请求关闭连接，B进入LAST\_ACK状态。
 *  第四次挥手: A收到FIN报文,向B发送ACK报文(ACK=y+1) , A进入TIME\_WAIT状态，B收到ACK报文后关闭连接，A在2MSL后依然没收到回复，证明B端己关闭，A就可以关闭连接了。
 *  简述:我要关闭，你同意，你要关闭，我同意你先关闭我再关闭。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTQyMDg1_size_16_color_FFFFFF_t_70]

##### 为什么TCP要四次挥手? #####

*  TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。
 *  TCP是全双工模式，主机1请求关闭连接，不再发送数据了，但是可以接收主机2的数据，主机2不再发送数据了，才算关闭，这样减小了丢失数据的风险。

--------------------

### 4、TIME-WAIT和CLOSE-TIME原因 ###

TCP要保证在所有可能的情况下使得所有的数据都能够被正确送达。当你关闭一个socket时，主动关闭一端的socket将进入TIME\_WAIT状态，而被动关闭一方则转入CLOSED状态，这的确能够保证所有的数据都被传输。当一个socket关闭的时候，是通过两端四次握手完成的，当一端调用close()时，就说明本端没有数据要发送了。这好似看来在握手完成以后，socket就都可以处于初始的CLOSED状态了，其实不然。原因是这样安排状态有两个问题， 首先，我们没有任何机制保证最后的一个ACK能够正常传输，第二，网络上仍然有可能有残余的数据包(wandering duplicates)，我们也必须能够正常处理。

--------------------

### 5、HTTP常见请求 ###

*  Get 请求指定页面
 *  Head 获取报头
 *  Post 请求可能会导致资源建立
 *  Put 修改资源
 *  Delete 删除资源
 *  Options 获取服务器性能

--------------------

### 6、HTTP常见状态码 ###

*  1xx 信息，服务器收到请求，需要请求者继续执行操作
 *  2xx 成功，操作被成功接收并处理
 *  3xx 重定向，需要进一步的操作以完成请求
 *  4xx 客户端错误，请求包含语法错误或无法完成请求
 *  5xx 服务器错误，服务器在处理请求的过程中发生了错误

--------------------

### 7、HTTP与HTTPS ###

HTTP使用80端口，HTTPS使用443端口，其中HTTPS是由SSL+HTTP协议构建的可进行加密传输，身份认证的网络协议。SSL是安全套接层在传输层

--------------------

### 8、HTTP keep-alive ###

参考：[https://segmentfault.com/a/1190000012894416][https_segmentfault.com_a_1190000012894416]  
我们知道HTTP协议采用“请求-应答”模式，当使用普通模式，即非KeepAlive模式时，每个请求/应答客户和服务器都要新建一个连接，完成 之后立即断开连接（HTTP协议为无连接的协议）；当使用Keep-Alive模式（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服 务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。

--------------------

### 9、TCP keepalive ###

概念:

*  在使用TCP长连接（复用已建立TCP连接）的场景下，需要对TCP连接进行保活，避免被网关干掉连接。  
    在应用层，可以通过定时发送心跳包的方式实现。而Linux已提供的TCP KEEPALIVE，在应用层可不关心心跳包何时发送、发送什么内容，由OS管理：OS会在该TCP连接上定时发送探测包，探测包既起到连接保活的作用，也能自动检测连接的有效性，并自动关闭无效连接。

原理:

*  建立TCP连接时，就有定时器与之绑定，其中的一些定时器就用于处理keepalive过程。当keepalive定时器到0的时候，便会给对端发送一个不包含数据部分的keepalive探测包（probe packet），如果收到了keepalive探测包的回复消息，那就可以断定连接依然是OK的。如果我们没有收到对端keepalive探测包的回复消息，我们便可以断定连接已经不可用，进而采取一些措施。但Keepalive会额外产生一些网络数据包外，这些包将加大网络流量，对路由器和防火墙造成一定的负担。

--------------------

### 10、TCP滑动窗口 ###

TCP滑动窗口具有拥塞控制和保证可靠性的功能

*  对于拥塞控制，滑动窗口是可变大小的，如果滑动窗口发生拥塞控制则将窗口大小置为1，然后对长度进行2的指数增长，直到窗口大小可满足数据传输或者大小到达阈值。
 *  对于可靠性，接收双方具有同样大小的窗口，然后对数据进行编号，如果接收端没有收到某部分信息就会发送请求给发送方然后重新发送未接收到的部分。

--------------------

### 11、TCP/UDP比较 ###

<table> 
 <thead> 
  <tr> 
   <th>TCP</th> 
   <th>UDP</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>TCP面向连接</td> 
   <td>UDP无连接</td> 
  </tr> 
  <tr> 
   <td>TCP是无界的</td> 
   <td>UDP是有界的</td> 
  </tr> 
  <tr> 
   <td>TCP可靠</td> 
   <td>UDP不可靠</td> 
  </tr> 
  <tr> 
   <td>TCP具有拥塞控制</td> 
   <td>UDP没有</td> 
  </tr> 
  <tr> 
   <td>TCP效率低</td> 
   <td>UDP效率高</td> 
  </tr> 
  <tr> 
   <td>TCP适合一对一连接</td> 
   <td>UDP适合广播、多播</td> 
  </tr> 
  <tr> 
   <td>TCP结构复杂</td> 
   <td>UDP结构简单</td> 
  </tr> 
  <tr> 
   <td>TCP能保证发送顺序</td> 
   <td>UDP无法保证</td> 
  </tr> 
  <tr> 
   <td>TCP使用字节流</td> 
   <td>UDP面向数据报</td> 
  </tr> 
 </tbody> 
</table>

*  为什么TCP是无界的：例如TCP可能将一个连续数据分成多块发送，此时无法确认数据大小。
 *  为什么UDP不可靠：因为TCP是面向连接的具有重传等机制，而UDP不会重传。
 *  数据报：封装数据，目的地址，源地址，端口号

--------------------

### 12、Cookie、Session ###

*  Cookie是由服务器端生成，发送给User-Agent（一般是浏览器），浏览器会将Cookie的key/value保存到某个目录下的文本文件内，下次请求同一网站时就发送该Cookie给服务器（前提是浏览器设置为启用cookie）。
 *  Cookie名称和值可以由服务器端开发自己定义，这样服务器可以知道该用户是否合法用户以及是否需要重新登录等，服务器可以设置或读取Cookies中包含信息，借此维护用户跟服务器会话中的状态。

##### Cookie和Session的区别与关系 #####

*  session 在服务器端，cookie 在客户端（浏览器）
 *  session 默认被存在在服务器的一个文件里（不是内存）
 *  session 的运行依赖 session id，而 session id 是存在 cookie 中的，也就是说，如果浏览器禁用了 cookie ，同时 session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 session\_id）
 *  session 可以放在 文件、数据库、或内存中都可以。
 *  用户验证这种场合一般会用 session
 *  由于http协议是无状态的，服务器需要记录用户的状态，所以cookie和session都是用来保持状态的方案，session又依赖cookie。

--------------------

### 13、Token ###

##### （1）Session和Token的区别 #####

*  session一般在cookie中传递而token一般放在header中

##### （2）Token的使用 Json Web Token #####

*  jwt的token包括三个部分，分别是header，payload，还有signature，header就是放的类型还有加密方式，然后payload主要就是放签发信息，签发时间还有身份权限等自定义的信息，最后一个签名就是对前两部分进行加密，防止被人篡改，将用户的非私密信息传给前端。

--------------------

### 14、当打开一个浏览器输入url到请求道页面的整个过程 ###

1.  DNS解析 将域名转化为IP地址
2.  TCP连接 与服务器建立连接
3.  发送HTTP请求
4.  服务器处理请求并返回HTTP报文
5.  浏览器解析渲染页面
6.  连接结束

--------------------

### 15、restful常见请求方法 ###

> restfual分别有GET \\ POST \\ PUT \\ DELETE \\ TRACE \\ HEAD \\ OPTIONS \\ PATCH \\ 等几种请求方法

*  POST : POST请求通常用来创建一个实体，也就是一个没有ID的资源。
 *  GET：从服务器取回数据（只是取回数据，而不会产生其他的影响）。这是一个幂等的方法（译者注：使用相同的参数重复执行，应该能够获取到相同的结果）。
 *  PUT ：PUT请求和POST请求类似，但是一般用来更新一个已有的实体。通过把已经存在的资源的ID和新的实体用PUT请求上传的服务器，来更新资源。
 *  DELETE ： DELETE方法用来从服务器上删除资源。和PUT类似，你需要把要删除的资源的ID上传给服务器。

--------------------

### 16、其他问题 ###

*  有没有网络编程，有，怎么看连接状态？netstat，有哪些？ESTABLISHED，LISTEN等等，有异常情况吗？TIME\_WAIT很多，为什么？大量短链接
 *  奖品秒杀模型设计

[20190613113024807.png]: /images/20220115/de3990d8ce55472aa85e0756cc207d29.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NTQyMDg1_size_16_color_FFFFFF_t_70]: /images/20220115/2b9d9ad95d0c4ef2afd8c7b05f72009e.png
[https_segmentfault.com_a_1190000012894416]: https://segmentfault.com/a/1190000012894416