4. 计算机网络

1. OSI七层体系结构

• 应用层： 为应用程序提供交互服务，如HTTP、SMTP协议等
• 表示层： 负责数据格式的转化，如加密解密、压缩解压、转换翻译等
• 会话等： 负责网络中的两个节点之间建立、维持和终止通信
• 传输层： 向主机进程提供通用的数据传输服务
  • TCP： 面向连接、可靠的数据传输服务
  • UDP： 无连接、尽最大努力的数据传输服务，不可靠
• 网络层： 选择合适的路由和结点，确保数据及时传送，主要包括IP协议
• 数据链路层： 将网络层传输下来的IP数据包组装成帧，传送帧
• 物理层： 实现相邻结点之间比特流的透明传输，尽可能屏蔽传输介质和通信手段的差异

2. TCP和UDP

3. TCP 连接的三次握手机制

• 第一次握手：客户端请求建立连接，向服务端发送一个同步报文（SYN=1），同时选择一个随机数 seq = x 作为初始序列号，并进入SYN_SENT状态，等待服务器确认。
• 第二次握手：：服务端收到连接请求报文后，如果同意建立连接，则向客户端发送同步确认报文 （SYN=1，ACK=1），确认号为 ack = x + 1，同时选择一个随机数 seq = y 作为初始序列号，此时服务器进入SYN_RECV状态。
• 第三次握手：客户端收到服务端的确认后，向服务端发送一个确认报文（ACK=1），确认号为 ack= y + 1，序列号为 seq = x + 1，客户端和服务器进入ESTABLISHED状态，完成三次握手。
  

4. 为什么需要三次握手，而不是两次？

主要有三个原因：

• 1、防止已过期的连接请求报文突然又传送到服务器，因而产生错误和资源浪费。
• 2、三次握手才能让双方均确认自己和对方的发送和接收能力都正常。
• 3、告知对方自己的初始序号值，并确认收到对方的初始序号值。

三次握手：

• 第一次握手：服务端确认“自己收、客户端发”报文功能正常。
• 第二次握手：客户端确认“自己发、自己收、服务端收、客户端发”报文功能正常，客户端认为连接已建立。
• 第三次握手：服务端确认“自己发、客户端收”报文功能正常，此时双方均建立连接，可以正常通信。

5. TCP 关闭的四次挥手机制

• 第一次挥手：客户端向服务端发送连接释放报文（FIN=1，ACK=1），主动关闭连接，同时等待服务端的确认。

  • 序列号 seq = u，即客户端上次发送的报文的最后一个字节的序号 + 1
  • 确认号 ack = k, 即服务端上次发送的报文的最后一个字节的序号 + 1

• 第二次挥手：服务端收到连接释放报文后，立即发出确认报文（ACK=1），序列号 seq = k，确认号 ack = u + 1。

  这时 TCP 连接处于半关闭状态，即客户端到服务端的连接已经释放了，但是服务端到客户端的连接还未释放。这表示客户端已经没有数据发送了，但是服务端可能还要给客户端发送数据。

• 第三次挥手：服务端向客户端发送连接释放报文（FIN=1，ACK=1），主动关闭连接，同时等待 A的确认。

  • 序列号 seq = w，即服务端上次发送的报文的最后一个字节的序号 + 1。
  • 确认号 ack = u + 1，与第二次挥手相同，因为这段时间客户端没有发送数据

• 第四次挥手：客户端收到服务端的连接释放报文后，立即发出确认报文（ACK=1），序列号 seq =
  u + 1，确认号为 ack = w + 1。

  此时，客户端就进入了 TIME-WAIT 状态。注意此时客户端到 TCP 连接还没有释放，必须经过2*MSL（最长报文段寿命）的时间后，才进入 CLOSED 状态。而服务端只要收到客户端发出的确认，就立即进入 CLOSED 状态。可以看到，服务端结束 TCP 连接的时间要比客户端早一些。
  

6. 为什么连接的时候是三次握手，关闭的时候却是四次握手？

服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回 ACK 报文段。

接下来可能会继续发送数据，在数据发送完后，服务器会向客户单发送 FIN 报文，表示数据已经发送完毕，请求关闭连接。服务器的ACK和FIN一般都会分开发送，从而导致多了一次，因此一共需要四次挥手。

7. 为什么客户端的 TIME-WAIT 状态必须等待 2MSL？

主要有两个原因：

• 1、 确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接。
  第四次挥手时，客户端第四次挥手的 ACK 报文不一定会到达服务端。服务端会超时重传 FIN/ACK报文，此时如果客户端已经断开了连接，那么就无法响应服务端的二次请求，这样服务端迟迟收不到 FIN/ACK 报文的确认，就无法正常断开连接。
  MSL 是报文段在网络上存活的最长时间。客户端等待 2MSL 时间，即「客户端 ACK 报文 1MSL 超 时 + 服务端 FIN 报文 1MSL 传输」，就能够收到服务端重传的 FIN/ACK 报文，然后客户端重传一次 ACK 报文，并重新启动 2MSL 计时器。如此保证服务端能够正常关闭。
  如果服务端重发的 FIN 没有成功地在 2MSL 时间里传给客户端，服务端则会继续超时重试直到断开连接。
• 2、 防止已失效的连接请求报文段出现在之后的连接中。
  TCP 要求在 2MSL 内不使用相同的序列号。客户端在发送完最后一个 ACK 报文段后，再经过时间2MSL，就可以保证本连接持续的时间内产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。或者即使收到这些过时的报文，也可以不处理它。

9. TCP协议如何保证可靠性

TCP主要提供了检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制和 流量控制等方法实现了可靠性传输。

• 检验和：
  通过检验和的方式，接收端可以检测出来数据是否有差错和异常，假如有差错就会直接丢弃TCP段，重新发送。
• 序列号/确认应答：
  序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。
  TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文，这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。
• 滑动窗口：
  滑动窗口既提高了报文传输的效率，也避免了发送方发送过多的数据而导致接收方无法正常处理的异常。
• 超时重传：
  超时重传是指发送出去的数据包到接收到确认包之间的时间，如果超过了这个时间会被认为是丢包了，需要重传。最大超时时间是动态计算的。
• 拥塞控制：
  在数据传输过程中，可能由于网络状态的问题，造成网络拥堵，此时引入拥塞控制机制，在保证TCP可靠性的同时，提高性能。
• 流量控制：
  如果主机A 一直向主机B发送数据，不考虑主机B的接受能力，则可能导致主机B的接受缓冲区满了而无法再接受数据，从而会导致大量的数据丢包，引发重传机制。而在重传的过程中，若主机B的接收缓冲区情况仍未好转，则会将大量的时间浪费在重传数据上，降低传送数据的效率。所以引入流量控制机制，主机B通过告诉主机A自己接收缓冲区的大小，来使主机A控制发送的数据量。流量控制与TCP协议报头中的窗口大小有关。

10. 滑动窗口

11. 拥塞控制

• 慢开始： 不要一开始就发送大量的数据，由小到大逐渐增加拥塞窗口的大小。
• 拥塞避免： 拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1而不是加倍。这样拥塞窗口按线性规律缓慢增长。
• 快重传： 我们可以剔除一些不必要的拥塞报文，提高网络吞吐量。比如接收方在收到一个失序的报文 段后就立即发出重复确认，而不要等到自己发送数据时捎带确认。
  快重传规定：发送方只要一连收 到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
• 快恢复： 主要是配合快重传。当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半（为了预防网络发生拥塞），但接下来并不执行慢开始算法，因为如果网络出现拥塞的话就不会收到好几个重复的确认，收到三个重复确认说明网络状况还可以。

12. HTTP常见的状态码

• 200：服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
• 301 ： (永久移动) 请求的网页已永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD 请求的响应)时，会自动将请求者转到新位置。
• 302：(临时移动) 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
• 400 ：客户端请求有语法错误，不能被服务器所理解。
• 403 ：服务器收到请求，但是拒绝提供服务。
• 404 ：(未找到) 服务器找不到请求的网页。
• 500： (服务器内部错误) 服务器遇到错误，无法完成请求。

13. HTTP请求报文和响应报文的格式

请求报文格式：

• 1、请求行（请求方法+URI协议+版本）
• 2、请求头部
• 3、空行
• 4、请求主体

响应报文：

• 1、状态行
• 2、响应首部
• 3、空行
• 4、响应主体

14. HTTP1.0和HTTP1.1的区别

• 长连接：HTTP 1.1支持长连接（Persistent Connection）和请求的流水线（Pipelining）处理
• 缓存处理：在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略，可供选择的缓存头来控制缓存策略。
• 带宽优化及网络连接的使用：HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（PartialContent），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
• 错误通知的管理：在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
• Host头处理：在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。

15. HTTP1.1和 HTTP2.0的区别

• 新的二进制格式
• 多路复用，即连接共享
• 头部压缩
• 服务端推送

16. HTTP 与 HTTPS 的区别

17. Cookie和Session的区别

• 作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。
• 存取方式不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在Session 中保持一些常用变量信息，比如说 UserId 等。
• 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
• 隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
• 存储大小不同， 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于Cookie。

---

18. 并发和并行的区别

并发就是在一段时间内，多个任务都会被处理；但在某一时刻，只有一个任务在执行。单核处理器可以做到并发。比如有两个进程 A 和 B ， A 运行一个时间片之后，切换到 B ， B 运行一个时间片之后又切换到 A 。因为切换速度足够快，所以宏观上表现为在一段时间内能同时运行多个程序。
并行就是在同一时刻，有多个任务在执行。这个需要多核处理器才能完成，在微观上就能同时执行多条指令，不同的程序被放到不同的处理器上运行，这个是物理上的多个进程同时进行。