第2章 计算机网络面试核心

我要就业
Created At :
Count:3.8k Views 👀 :
  1. 网络知识考点

网络知识考点

  1. 网络基础知识讲解 (12:08)

    1. OSI开放式互联参考模型
      1. 20220821000726
      2. 物理层:
      3. 数据链路层:交换机
      4. 网络层:路由器，IP/IPv6
      5. 传输层:TCP，UDP
      6. 会话层:
      7. 表示层:
      8. 应用层:HTTP
    2. TCP/IP
      1. 20220826165224

  2. TCP的三次握手_1 (13:13)

    1. TCP报文的结构20220827221031

      1. TCP报文结构和功能简析
      2. TCP 报文段格式 | 小菜学网络

    2. 传输控制协议TCP

      1. 面向连接的、可靠的、基于字节流的传输层通信协议
      2. 将应用层的数据流分割成报文段并发送给目标节点的TCP层
      3. 数据包都有序号，对反收到则发送ACK确认，未收到则重传
      4. 使用校验和来检验数据在传输过程中是否有误

    3. TCP Flags

      1. URG
      2. ACK
      3. PSH
      4. RST
      5. SYN
      6. FIN

    4. 握手是为了建立连接(全双工)，TCP三次握手的流程图：

      1. TCP三次握手的流程图
      2. 都处于CLOSED
      3. 主动打开的是客户端，被动打开的是服务端
      4. TCP服务器先创建传输控制块PCB，准备接受连接请求，服务端进入listen状态
      5. （第一次握手）TCP客户端先创建传输控制块TCB，向服务器发送连接请求报文，报文头里的TCP Flags的SYN=1，选择初始序号seq=x(任意正整数值)，此时客户端进入SYN-SENT已发送状态。发送过去的报文段，被称为SYN报文段，无法携带数据，但是需要消耗序号。
      6. （第二次握手）服务器接受到请求报文，如果同意连接，就发出确认报文，包含TCP Flags的ACK=1，SYN=1；确认号是ack=x+1（为什么x+1，原因：请求报文指定了seq=x，作为回应，需要回应与x相关的信息，并且上面报文消耗了一个序号，所以x+1），并且需要对自己的缓存初始化一个序列号seq=y，服务器进入SYN-RCVD状态。此时报文不能携带数据，并且需要消耗一个序号。
      7. （第三次握手）客户端接收到确认报文，还需要发出确认报文，ACK=1，ack=y+1（为什么y+1，原因：请求报文指定了seq=y，作为回应，需要回应与x相关的信息，并且上面报文消耗了一个序号，所以y+1），并且序列号seq=y+1。此时客户端进入established状态。此时报文可以携带数据，携带数据会消耗序号。当服务器收到改报文后，也进入established状态。

  3. 问题与解答 (11:44)

    1. 为什么需要三次握手才能建立起连接
      1. 为了初始化序号值Sequence Number.
      2. TCP过程中需要使用序号值拼接数据，因此在服务器回发Sequence Number，即第二次握手后，客户端还需要发送确定报文给服务器，告知服务器:客户端已收到初始化的Sequence Number
      3. 保证应用层接受的序号不会因为网络上的传输问题而乱序.
    2. 首次握手的隐患:SYN超时
      1. 起因
        1. Server收到Client的SYN，回复SYN-ACK的时候未收到ACK确认
        2. Server不断重试直至超时，Linus默认等待63秒才断开链接
      2. 风险：
        1. SYN Flood：异常请求把队列耗尽，不能处理正常请求
      3. 解决方法：
        1. SYN队列满后，通过tcp_syncookies参数回发SYN Cookie
        2. 若为正常连接则Client会回发SYN Cookie，直接建立连接
    3. 建立连接后，Client出现故障怎么办
      1. 保活机制
        1. 向对方发送保活探测报文，如果未收到响应则继续发送
        2. 尝试次数达到保活探测数仍未收到响应则中断连接

  4. TCP的四次挥手 (11:24)

    1. 20220826222028
    2. 一开始，客户端和服务端都处于established状态，客户端主动关闭，服务器被动关闭
    3. （第一次挥手）首先，客户端进程发出连接释放报文，并停止发送数据，在该数据报的报头中，TCP Flags的FIN=1，假设此时客户端定义的序列号seq=u（在established状态下，最后一次发送数据，已经传送过来的数据的最后一个字节的序号+1），此时客户端进入FIN-WAIT-1终止等待1状态（TCP规定，即使FIN报文段不携带数据，也要消耗一个序号，回执的时候ack需要是u+1）
    4. （第二次挥手）服务器收到连接释放报文后，需要发送确认报文，ACK=1，回应的ack=u+1，序列号seq=v，服务端进入CLOSE-WAIT状态（重要，半关闭状态，客户端已经没有数据要发送了，但是服务器可以继续发送数据）
    5. （第三次挥手）客户端收到确认报文后，进行FIN-WAIT-2终止等待2状态，等待服务器发送第三次挥手的内容，当服务器发送完最后的数据，就会向客户端发送连接释放报文，FIN=1，ack=u+1，因为在半关闭状态，服务器可能又发送了一些数据，假定此时序号变成seq=w，服务器进入LAST-ACK状态
    6. （第四次挥手）客户端收到服务器的连接释放报文后，必须发送确认报文，ACK=1，seq=u+1，ack=w+1，（按照自己之前报文的序号+1），此时客户端进入TIME-WAIT时间等待状态（此时，客户端的TCP连接还没有释放，必须经过2MSL时间，连接才会进入CLOSED（MSL是最长报文段寿命，2min（Linux是30s））），当服务器收到确认，立即进入CLOSED关闭状态
    7. 问题与解答:
      1. 为什么会有TIME_WAIT状态
        1. 确保有足够的时间让对方收到ACK包(如果没有收到，会重新发送)
        2. 避免新旧连接混淆
      2. 为什么需要四次握手才能断开连接?
        1. 因为全双工，发送方和接收方都需要FIN报文和ACK报文
      3. 服务器出现大量CLOSE_WAIT状态的原因?
        1. 对方关闭socket连接，我方忙于读或写，没有及时关闭连接
          1. 检查代码，特别是释放资源的代码
          2. 检查配置，特别是处理请求的线程配置

  5. TCP和UDP的区别 (04:32)

    1. UDP（User Datagram Protocol）
    2. UDP报文结构20220827220955
    3. UDP特点
      1. 面向非连接
      2. 不维护连接状态，支持同时向多个客户端传输相同的消息
      3. 数据包报头只有8个字节，额外开销小
      4. 吞吐量只受限于数据生成速率、传输速率以及机器性能
      5. 尽最大努力交付、不保证可靠交付，不需要维持复杂的链接状态表
      6. 面向报文，不对应用程序提交的报文信息进行拆分或者合并
    4. TCP和UDP的区别
      1. 面向连接vs无连接
      2. 可靠性
      3. 有序性（TCP序列号保证顺序）
      4. 速度（UDP适用于在线视频媒体、电视广播、多人游戏）
      5. 量级（TCP20个字节重量级，UDP8个字节轻量级）

  6. TCP的滑窗 (12:07)

    1. RTT和RTO
      1. RTT（Round Trip Time）：发送一个数据包到收到对应的ACK，所花费的时间
      2. RTO（Retransmission TimeOut）：重传时间间隔
      3. 批量放松，可靠传输，解决包乱序的问题
      4. TCP使用滑动窗口做流量控制与乱序重排
        1. 保证TCP的可靠性
        2. 保证TCP的流量控制特性（TCP头部中windows：接收方用来通知发送方，自己还有多少缓冲区可以发送数据，发送方根据接收方的处理能力来发送数据，不会处理不过来，这就是流量控制）
        3. TCP面向字节流的设计思路
      5. 已发送且待确认的大小，要小于，接收方的window大小20220827223537
    2. （滑动窗口的基本原理）TCP会话的发送方（四类数据）
      1. 已发送已回应
      2. 已发送无回应
      3. 未发送准备发送
      4. 未发送未准备发送
      5. 2与3组成滑动窗口
    3. （滑动窗口的基本原理）TCP会话的接收方（3种状态）
      1. 已接收已ACK
      2. 未接收但是可以接收
      3. 未接受不可以接收
    4. 可靠性
      1. TCP最基本的传输可靠性来源于确认重传机制
      2. 滑动窗口的可靠性也是建立在确认重传机制基础上
      3. 发送窗口只有收到接收端对于本段发送窗口内字节的ACK确认，才会移动发送窗口的左边界
      4. 接收窗口只有在前面的段都确认的情况下，才会移动左边界
      5. 当前面字节未接收，但是收到后面的字节的情况下，窗口不会移动，不会对后续字节确认，以确保对端会对这些数据进行重传确认
    5. 滑动窗口的大小可以依据一定策略动态调整

  7. HTTP相关 (15:15)

    1. 超文本传输协议HTTP主要特点
      1. 支持客户/服务器模式
      2. 简单快速（只需要请求方法和路径）
      3. 灵活（数据类型不限制）
      4. 无连接（传输完就断开链接）
        1. HTTP1.1就长连接了（连接保持一段时间）
      5. 无状态（协议对事务处理没有记忆）
    2. 1.1-1.0：keeplive
    3. HTTP请求结构HTTP请求结构
    4. 请求/响应的步骤
      1. 客户端连接到Web服务器
      2. 发送HTTP请求
      3. 服务器接受请求并返回HTTP响应
      4. 释放连接TCP连接
      5. 客户端浏览器解析HTTP内容

  8. HTTP相关问题与解答 (14:33)

    1. 在浏览器地址栏键入URL，按下回车之后经历的流程
      1. DNS解析：浏览器会根据URL逐层查询DNS服务器缓存，解析URL中域名对应的IP地址。DNS从近到远依次是：浏览器缓存、系统缓存、路由器缓存、IPS服务器缓存、根域名服务器缓存、顶级域名服务器缓存。
      2. TCP连接：根据IP地址浏览器和对应端口（默认是80端口）与服务器建立TCP连接，TCP三次握手
      3. 发送HTTP请求：
      4. 服务器处理请求并返回HTTP报文
      5. 浏览器解析渲染页面
      6. 连接结束：TCP四次挥手
    2. 常见的HTTP状态码
      1. 五种可能的取值：
        1. 1XX：指示信息– 表示请求已接收，继续处理
        2. 2XX：成功–表示请求已被成功接收、理解、接受
        3. 3XX：重定向–要完成请求必须进行更进一步的操作
        4. 4XX：客户端错误–请求有语法错误或请求无法实现
        5. 5XX：服务器错误–服务器未能实现合法的请求
      2. 常见状态码
        1. 200 OK：正常返回信息
        2. 400 Bad Request：客户端请求有语法错误，不能被服务器所理解
        3. 401 Unauthorized:请求未经授权，这个状态码必须和WWW-Authenticate报头域一起使用
        4. 403 Forbidden：服务器收到请求，但拒绝提供服务
        5. 404 Not Found:请求资源不存在，比如，输入了错误的URL
        6. 500 Internal Server Error：服务器发生不可预期的错误（遇见这样的错误可以去查看下服务器的日志，看报了什么错）
        7. 503 Server Unavailable：服务器当前不能处理客户端请求，一段时间后可能恢复正常
    3. GET和post区别（从三个层面来解答）
      1. HTTP报文层面：GET将请求信息放在URL，POST放在报文体中
      2. 数据库层面：GET符合幂等性和安全性，POST不符合
      3. 其他层面：GET可以被缓存、被存储，而POST不行
    4. Cookie和Session
      1. HTTP是无状态的，使用一些手段，让他具备了状态
      2. 客户端的解决方案：Cookie
        1. 是由服务器发给客户端的特殊信息，以文本的形式存放在客户端
        2. 客户端再次请求的时候，会把Cookie回发
        3. 服务器接收到后，会解析Cookie生成与客户端相对应的内容
        4. Cookie的设置以及发送过程20220828161633
      3. 服务端的机制：Session
        1. 服务器端的机制，在服务器上利用散列表保存的信息
        2. 解析客户端请求并操作session id，按需保存状态的信息
        3. Session的实现方式
          1. 使用Cookie来实现20220828161901
          2. 使用URL回写来实现
    5. Cookie和Session的区别
      1. Cookie数据存放在客户的浏览器上，Session数据放在服务器上
      2. Session相对于Cookie更安全
      3. 若考虑减轻服务器负担，应使用Cookie

  9. HTTP和HTTPS的区别 (10:11)

    1. HTTPS（Hypertext Transfer Protocol Secure）：超文本传输安全协议
    2. SSL(Security Sockets Layer)：安全套接层
      1. 为网络通信提供安全及数据完整性的一种安全协议
      2. 位于TCP与应用层之间，是操作系统对外的API，SSL3.0后更名为TLS
      3. 采用身份认证和数据加密保证网络通信的安全和数据的完整性
    3. 加密的方式：
      1. 对称加密：加密和解密都是用同一个密钥，效率高，安全性低
      2. 非对称加密：加密使用的密钥和解密使用的密钥是不相同的，分别称为公钥和私钥，安全性高，数据长度有限
      3. 哈希算法：将任意长度的信息转换为固定长度的值，算法不可逆，常见算法：MD5
      4. 数字签名：证明某个消息或者文件是从某人发出/认同的
    4. HTTPS数据传输流程：证书+加密方式
      1. 浏览器将支持的加密算法信息发送给服务器
      2. 服器选择一套浏览器支持的加密算法，以证书的形式回发给浏览器
      3. 浏览器验证证书合法性，并结合证书公钥加密信息发给服务器
      4. 服务器使用私钥解密信息，验证哈希，加密响应消息回发给浏览器
      5. 浏览器解密响应消息，并对消息进行验证，之后进行加密交互数据
    5. Http和HTTPS的区别：
      1. HTTPS需要到CA机构申请证书，HTTP不需要
      2. HTTPS密文传输，HTTP明文传输
      3. 连接方式不同，HTTP模式使用80端口，HTTPS默认使用443端口
      4. HTTPS=HTTP+加密+认证+完整性保护，较HTTP安全
    6. HTTPS真的安全么
      1. 浏览器默认填充http://，请求https需要进行跳转，有被劫持的风险
      2. 可以使用HSTS（HTTP Strict Transport Security）优化

  10. socket相关 (14:27)

    1. 唯一标识网络中的一个进程
      1. IP+PORT+协议，就可以用socket来通信
      2. Socket是对TCP/IP协议的抽象，是操作系统对外开放的接口
      3. Socket通信流程：20220828164552
    2. Socket相关的面试题
      1. 编写一个网络应用程序，有客户端与服务器端，客户端向服务器发送一个字符串，服务器收到该字符串后将其打印到命令行上，然后向客户端返回该字符串的长度，最后，客户端输出服务器端返回的该字符串的长度，分别用TCP和UDP两种方式去实现

  11. 网络知识总结 (02:30)

  12. 彩蛋之走进面试官的世界 (02:59)

  13. [加餐]扩展：tcpdump+wireshark抓包”骚”操作

  14. [加餐]扩展：“抓包”实战

  15. 总结：常见问题

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达，可以邮件至 963614756@qq.com。

©2016-2020 HITlittlefox

Built with Hexo and 3-hexo theme