面试 -- 操作系统与计算机网络

基于 Java面试 32个核心必考点完全解析（上）【附视频地址】中的 操作系统与计算机网络 相关面试题做记录。

进程与线程的区别与联系（资源的占用，切换效率，通信方式）
简单介绍一下进程的切换过程
操作系统中的进程调度算法
经常使用的 Linux 命令，使用场景
OSI 七层模型
简述 TCP \ UDP的区别
TCP 如何实现可靠性传输
TCP 的三次握手和四次挥手过程
为什么 TCP 关闭链接时需要 TIME_WAIT 状态，为什么要等 2MSL？
一次完整的 HTTP 请求过程（DNS TCP HTTP）
简述 HTTP 中 GET 和 POST 的区别
HTTP2 与 HTTP 之间的区别

一、进程与线程的区别与联系（资源的占用，切换效率，通信方式）

进程

进程是资源分配的基本单位，用来管理资源（例如：内存，文件，网络等资源）

进程控制块 (Process Control Block, PCB) 描述进程的基本信息和运行状态，所谓的创建进程和撤销进程，都是指对 PCB 的操作。（PCB是描述进程的数据结构）

线程

线程是独立调度的基本单位。

一个进程中可以有多个线程，它们共享进程资源。

QQ 和浏览器是两个进程，浏览器进程里面有很多线程，例如 HTTP 请求线程、事件响应线程、渲染线程等等，线程的并发执行使得在浏览器中点击一个新链接从而发起 HTTP 请求时，浏览器还可以响应用户的其它事件。

区别

Ⅰ 拥有资源

进程是资源分配的基本单位，但是线程不拥有资源，线程可以访问隶属进程的资源。

Ⅱ 调度

线程是独立调度的基本单位，在同一进程中，线程的切换不会引起进程切换，从一个进程中的线程切换到另一个进程中的线程时，会引起进程切换。

Ⅲ 系统开销

由于创建或撤销进程时，系统都要为之分配或回收资源，如内存空间、I/O 设备等，所付出的开销远大于创建或撤销线程时的开销。类似地，在进行进程切换时，涉及当前执行进程 CPU 环境的保存及新调度进程 CPU 环境的设置，而线程切换时只需保存和设置少量寄存器内容，开销很小。

Ⅳ 通信方面

线程间可以通过直接读写同一进程中的数据进行通信，但是进程通信需要借助 IPC。

进程通信

进程同步与进程通信很容易混淆，它们的区别在于：

进程同步：控制多个进程按一定顺序执行；
进程通信：进程间传输信息。

进程通信是一种手段，而进程同步是一种目的。也可以说，为了能够达到进程同步的目的，需要让进程进行通信，传输一些进程同步所需要的信息。

1. 管道

管道是通过调用 pipe 函数创建的，fd[0] 用于读，fd[1] 用于写。

#include <unistd.h>
int pipe(int fd[2]);

它具有以下限制：

只支持半双工通信（单向交替传输）；
只能在父子进程或者兄弟进程中使用。

2. FIFO

也称为命名管道，去除了管道只能在父子进程中使用的限制。

#include <sys/stat.h>
int mkfifo(const char *path, mode_t mode);
int mkfifoat(int fd, const char *path, mode_t mode);

FIFO 常用于客户-服务器应用程序中，FIFO 用作汇聚点，在客户进程和服务器进程之间传递数据。

3. 消息队列

相比于 FIFO，消息队列具有以下优点：

消息队列可以独立于读写进程存在，从而避免了 FIFO 中同步管道的打开和关闭时可能产生的困难；
避免了 FIFO 的同步阻塞问题，不需要进程自己提供同步方法；
读进程可以根据消息类型有选择地接收消息，而不像 FIFO 那样只能默认地接收。

4. 信号量

它是一个计数器，用于为多个进程提供对共享数据对象的访问。

5. 共享存储

允许多个进程共享一个给定的存储区。因为数据不需要在进程之间复制，所以这是最快的一种 IPC。

需要使用信号量用来同步对共享存储的访问。

多个进程可以将同一个文件映射到它们的地址空间从而实现共享内存。另外 XSI 共享内存不是使用文件，而是使用内存的匿名段。

6. 套接字

与其它通信机制不同的是，它可用于不同机器间的进程通信。

二、简单介绍一下进程的切换过程

就绪状态（ready）：等待被调度
运行状态（running）：运行中
阻塞状态（waiting）：等待资源

应该注意以下内容：

只有就绪态和运行态可以相互转换，其它的都是单向转换。就绪状态的进程通过调度算法从而获得 CPU 时间，转为运行状态；而运行状态的进程，在分配给它的 CPU 时间片用完之后就会转为就绪状态，等待下一次调度。
阻塞状态是缺少需要的资源从而由运行状态转换而来，但是该资源不包括 CPU 时间，缺少 CPU 时间会从运行态转换为就绪态。
进程只能自己阻塞自己，因为只有进程自身才知道何时需要等待某种事件的发生

三、操作系统中的进程调度算法

不同环境的调度算法目标不同，因此需要针对不同环境来讨论调度算法。

1. 批处理系统

批处理系统没有太多的用户操作，在该系统中，调度算法目标是保证吞吐量和周转时间（从提交到终止的时间）。

1.1 先来先服务

先来先服务 first-come first-serverd（FCFS）

按照请求的顺序进行调度。

有利于长作业，但不利于短作业，因为短作业必须一直等待前面的长作业执行完毕才能执行，而长作业又需要执行很长时间，造成了短作业等待时间过长。

1.2 短作业优先

短作业优先 shortest job first（SJF）

按估计运行时间最短的顺序进行调度。

长作业有可能会饿死，处于一直等待短作业执行完毕的状态。因为如果一直有短作业到来，那么长作业永远得不到调度。

1.3 最短剩余时间优先

最短剩余时间优先 shortest remaining time next（SRTN）

按估计剩余时间最短的顺序进行调度。

2. 交互式系统

交互式系统有大量的用户交互操作，在该系统中调度算法的目标是快速地进行响应。

2.1 时间片轮转

将所有就绪进程按 FCFS （先来先服务）的原则排成一个队列，每次调度时，把 CPU 时间分配给队首进程，该进程可以执行一个时间片。当时间片用完时，由计时器发出时钟中断，调度程序便停止该进程的执行，并将它送往就绪队列的末尾，同时继续把 CPU 时间分配给队首的进程。

时间片轮转算法的效率和时间片的大小有很大关系。因为进程切换都要保存进程的信息并且载入新进程的信息，如果时间片太小，会导致进程切换得太频繁，在进程切换上就会花过多时间。

2.2 优先级调度

为每个进程分配一个优先级，按优先级进行调度。

为了防止低优先级的进程永远等不到调度，可以随着时间的推移增加等待进程的优先级。

2.3 多级反馈队列

如果一个进程需要执行 100 个时间片，如果采用时间片轮转调度算法，那么需要交换 100 次。

多级队列是为这种需要连续执行多个时间片的进程考虑，它设置了多个队列，每个队列时间片大小都不同，例如 1,2,4,8,…。进程在第一个队列没执行完，就会被移到下一个队列。这种方式下，之前的进程只需要交换 7 次。

每个队列优先权也不同，最上面的优先权最高。因此只有上一个队列没有进程在排队，才能调度当前队列上的进程。

可以将这种调度算法看成是时间片轮转调度算法和优先级调度算法的结合。

3. 实时系统

实时系统要求一个请求在一个确定时间内得到响应。

分为硬实时和软实时，前者必须满足绝对的截止时间，后者可以容忍一定的超时。

四、经常使用的 Linux 命令，使用场景

awk

逐行扫描文件（从第 1 行到最后一行），寻找含有目标文本的行，如果匹配成功，则会在该行上执行用户想要的操作；反之，则不对行做任何处理。

awk 的主要特性之一是其处理文本文件中数据的能力，它会自动给一行中的每个数据元素分配一个变量

awk 命令的基本格式为：

[root@localhost ~]# awk [选项] '脚本命令' 文件名

top

实时显示进程信息。

示例：两秒钟刷新一次

# top -d 2

netstat

查看占用端口的进程

示例：查看特定端口的进程

# netstat -anp | grep port

less

查看文件内容

less 命令的作用和 more 十分类似，都用来浏览文本文件中的内容，不同之处在于，使用 more 命令浏览文件内容时，只能不断向后翻看，而使用 less 命令浏览，既可以向后翻看，也可以向前翻看。

[root@localhost ~]# less [选项] 文件名

grep

查找文件内容

能够在一个或多个文件中，搜索某一特定的字符模式（也就是正则表达式），此模式可以是单一的字符、字符串、单词或句子。

grep 命令的基本格式如下：

[root@localhost ~]# grep [选项] 模式 文件名

tail

显示文件结尾的内容

经常用于实时查看项目日志信息

[root@localhost logs]# tail -f dev.log

五、OSI 七层模型

五层协议

应用层 ：提供用户接口，特指能够发起网络流量的程序，比如客户端程序：QQ，MSN，浏览器等；服务器程序：web服务器，邮件服务器，流媒体服务器等等。数据单位为报文。
传输层 ：提供的是进程间的通用数据传输服务。由于应用层协议很多，定义通用的运输层协议就可以支持不断增多的应用层协议。运输层包括两种协议：
- 传输控制协议 TCP，提供面向连接、可靠的数据传输服务，数据单位为报文段；
- 用户数据报协议 UDP，提供无连接、尽最大努力的数据传输服务，数据单位为用户数据报。
- TCP 主要提供完整性服务，UDP 主要提供及时性服务。
网络层 ：为主机间提供数据传输服务，而运输层协议是为主机中的进程提供服务。网络层把运输层传递下来的报文段或者用户数据报封装成分组。（负责选择最佳路径规划IP地址）
- 路由器查看数据包目标IP地址，根据路由表为数据包选择路径。路由表中的类目可以人工添加（静态路由）也可以动态生成（动态路由）。
数据链路层 ：不同的网络类型，发送数据的机制不同，数据链路层就是将数据包封装成能够在不同的网络传输的帧。能够进行差错检验，但不纠错，监测处错误丢掉该帧。
- 帧的开始和结束，透明传输，差错校验
物理层 ：物理层解决如何在连接各种计算机的传输媒体上传输数据比特流，而不是指具体的传输媒体。物理层的主要任务描述为：确定与传输媒体的接口的一些特性，即：
- 机械特性：例接口形状，大小，引线数目
- 电气特性：例规定电压范围 ( -5V 到 +5V )
- 功能特性：例规定 -5V 表示 0，＋5V 表示 1
- 过程特性：也称规程特性，规定建立连接时各个相关部件的工作步骤

ISO七层模型中表示层和会话层

表示层 ：数据压缩、加密以及数据描述。这使得应用程序不必担心在各台主机中表示/存储的内部格式（二进制、ASCII，比如乱码）不同的问题。
会话层 ：建立会话，如session认证、断点续传。通信的应用程序之间建立、维护和释放面向用户的连接。通信的应用程序之间建立会话，需要传输层建立1个或多个连接。
说明：五层协议没有表示层和会话层，而是将这些功能留给应用程序开发者处理。

六、简述 TCP \ UDP的区别

在 TCP/IP 网络体系结构中，TCP（传输控制协议，Transport Controll Protocol、UDP（用户数据报协议，User Data Protocol）是传输层最重要的两种协议，为上层用户提供级别的通信可靠性。

传输控制协议（TCP）：TCP（传输控制协议）定义了两台计算机之间进行可靠的传输而交换的数据和确认信息的格式，以及计算机为了确保数据的正确到达而采取的措施。协议规定了TCP软件怎样识别给定计算机上的多个目的进程如何对分组重复这类差错进行恢复。协议还规定了两台计算机如何初始化一个 TCP 数据流传输以及如何结束这一传输。TCP最大的特点就是提供的是面向连接、可靠的字节流服务。

用户数据报协议（UDP）：UDP（用户数据报协议）是一个简单的面向数据报的传输层协议。提供的是非面向连接的、不可靠的数据流传输。UDP不提供可靠性，也不提供报文到达确认、排序以及流量控制等功能。它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。因此报文可能会丢失、重复以及乱序等。但由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快。

对比

	UDP	TCP
是否连接	无连接	面向连接
是否可靠	不可靠传输，不使用流量控制和拥塞控制	可靠传输，使用流量控制和拥塞控制
连接对象个数	支持一对一，一对多，多对一和多对多交互通信	只能是一对一通信
传输方式	面向报文	面向字节流
首部开销	首部开销小，仅8字节	首部最小20字节，最大60字节
适用场景	适用于实时应用（IP电话、视频会议、直播等）	适用于要求可靠传输的应用，例如文件传输

七、TCP 如何实现可靠性传输

应用数据被分割成 TCP 认为最适合发送的数据块。
TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
TCP 的接收端会丢弃重复的数据。
流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。（TCP 利用滑动窗口实现流量控制）
拥塞控制： 当网络拥塞时，减少数据的发送。
ARQ协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

7.1 ARQ协议

自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议。

停止等待ARQ协议

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组；
在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认；

优点： 简单

缺点： 信道利用率低，等待时间长

1) 无差错情况:

发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送。

2) 出现差错情况（超时重传）:

停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 自动重传请求 ARQ 。另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。连续 ARQ 协议 可提高信道利用率。发送维持一个发送窗口，凡位于发送窗口内的分组可连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了。

3) 确认丢失和确认迟到

确认丢失 ：确认消息在传输过程丢失。当Client发送M1消息，Server收到后，Server向Client发送了一个M1确认消息，但却在传输过程中丢失。而Client并不知道，在超时计时过后，Client重传M1消息，Server再次收到该消息后采取以下两点措施：1. 丢弃这个重复的M1消息，不向上层交付。 2. 向Client发送确认消息。（不会认为已经发送过了，就不再发送。Client能重传，就证明Server的确认消息丢失）。
确认迟到 ：确认消息在传输过程中迟到。Client发送M1消息，Server收到并发送确认。在超时时间内没有收到确认消息，Client重传M1消息，Server仍然收到并继续发送确认消息（Server收到了2份M1）。此时Client收到了Server第二次发送的确认消息。接着发送其他数据。过了一会，Client收到了Server第一次发送的对M1的确认消息（Client也收到了2份确认消息）。处理如下：1. Client收到重复的确认后，直接丢弃。2. Server收到重复的M1后，也直接丢弃重复的M1。

连续ARQ协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

优点： 信道利用率高，容易实现，即使确认丢失，也不必重传。

缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。比如：发送方发送了 5条消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

7.2 滑动窗口和流量控制

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

7.3 拥塞控制

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP的拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。
拥塞避免： 拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送放的cwnd加1.
快重传与快恢复： 在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。　当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

八、TCP 的三次握手和四次挥手过程

TCP 首部格式

序号 seq ：用于对字节流进行编号，例如序号为 301，表示第一个字节的编号为 301，如果携带的数据长度为 100 字节，那么下一个报文段的序号应为 401。[301,400]为序号301的数据长度，下一个则为401
确认号 ack ：期望收到的下一个报文段的序号。例如 Server 正确收到 Client 发送来的一个报文段，序号为 501，携带的数据长度为 200 字节，因此 Server 期望下一个报文段的序号为 701，Server 发送给 Client 的确认报文段中确认号就为 701。
数据偏移 ：指的是数据部分距离报文段起始处的偏移量，实际上指的是首部的长度。
确认 ACK ：当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
同步 SYN ：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。
终止 FIN ：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。
窗口：窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。

TCP Flags

URG：紧急指针标志
ACK：确认序号标志
PSH：push标志
RST：重置连接标志
SYN：同步序号，用于建立连接过程
FIN：finish标志，用于释放连接

三次握手

第一次握手：建立连接时，客户端发送 SYN 包 [syn=j] 到服务器，并进入 SYN_SEND 状态，等待服务器确认；
第二次握手：服务器收到 SYN 包，必须确认客户的 SYN [ ack=j+1]，同时自己也会发送一个 SYN 包 [syn=k]，即 SYN+ACK 包，此时服务器进入 SYN_RECV 状态；
第三次握手：客户端收到服务器的 SYN+ACK包，想服务器发送确认包 ACK [ ack=k+1]，此包发送完毕，客户端和服务器进入 ESTABLISHED 状态，完成三次握手。

假设 Client 为客户端，Server 为服务器端。

首先 Server 处于 LISTEN（监听）状态，等待客户的连接请求。
Client 向 Server 发送连接请求报文段，SYN=1，ACK=0，选择一个初始的序号 seq = x, Client进入 SYN_SEND 状态。
Server 收到连接请求报文段，如果同意建立连接，则向 Client 发送连接确认报文段，SYN=1，ACK=1，确认号为 x+1，同时也选择一个初始的序号 seq = y，服务器进入 SYN_RECV 状态。
Client 收到 Server 的连接确认报文段后，还要向 Server 发出确认，确认号为 ack = y+1，序号为 seq = x+1，Client 和Server 进入 ESTABLISHED 状态。
Client 的 TCP 通知上层应用进程，连接已经建立。
Server 收到 Client 的确认后，连接建立。
Server 的 TCP 收到主机 Client 的确认后，也通知其上层应用进程：TCP 连接已经建立。

为什么TCP连接需要三次握手，两次不可以吗

为了初始化Sequence Number的初始值，

为了防止已失效的连接请求报文段突然又传送到了服务端，占用服务器资源。（假设主机Client为客户端，主机Server为服务器端）

现假定出现一种异常情况，即Client发出的第一个连接请求报文段并没有丢失，而是在某些网络节点长时间滞留了，以致延误到连接释放以后的某个时间才到Server。本来这是一个已失效的报文段。但是Server收到此失效的连接请求报文段后，就误认为是Client有发出一次新的连接请求。于是就向Client发出确认报文段，同意建立连接。假定不采用三次握手，那么只要Server发出确认，新的连接就建立了。

由于现在Client并没有发出建立连接的请求，因此不会理睬Server的确认，也不会向Server发送数据。但Server却以为新的运输连接已经建立了，并一直等待Client发来数据。Server的许多资源就这样白白浪费了。

Server会不断重试直至超时，Linux默认等待63秒（1+2+4+8+16+32）才断开连接。

采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下，Client不会向Server的确认发出确认。Server由于收不到确认，就知道Client并没有要求建立连接。

四次挥手

数据传输结束后，通信的双方都可释放连接。现在 Client 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP连接。

Client 把连接释放报文段首部的 FIN = 1，其序号 seq = u，Client 进入 FIN_WAIT_1状态，等待 Server 的确认。
Server 发出确认，确认号 ack = u+1，而这个报文段自己的序号 seq = v。（TCP 服务器进程通知高层应用进程），Server进入 CLOSE_WAIT 状态。
从 Client 到 Server 这个方向的连接就释放了，TCP 连接处于半关闭状态。Client 不能向 Server 发送数据；Server 若发送数据，Client 仍要接收。
当 Server 不再需要连接时，发送连接释放请求报文段，FIN=1，Server进入 LAST_ACK 状态。
Client 收到后发出确认，进入 TIME-WAIT 状态，接着发送一个ACK给Server，确认号为收到序号+1，Client等待 2 MSL（2*2 = 4 mins）时间后释放连接。
Server 收到 Client 的确认后释放连接，进入CLOSED 状态，完成四次挥手。

九、为什么 TCP 关闭链接时需要 TIME_WAIT 状态，为什么要等 2MSL？

第一，为了保证 Client 发送的最后一个 ACK 报文能够到达 Server。这个 ACK 报文段有可能丢失，因而使处在LAST-ACK 状态的 Server 收不到对已发送的 FIN+ACK 报文段的确认。Server 会超时重传这个 FIN+ACK 报文段，而 Client 就能在 2MSL 时间内收到这个重传的FIN+ACK报文段。如果 Client 在 TIME-WAIT 状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，就无法收到 Server 重传的 FIN+ACK 报文段，因而也不会再发送一次确认报文段。这样，Server 就无法按照正常的步骤进入 CLOSED 状态。
第二，Client 在发送完 ACK 报文段后，再经过2MSL时间，就可以使本连接持续的时间所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求的报文段。

2MSL 即两倍的 MSL，TCP 的 TIME_WAIT 状态也称为 2MSL 等待状态，当 TCP 的一端发起主动关闭，在发出最后一个 ACK 包后，即第3次握手完成后发送了第四次握手的 ACK 包后就进入了 TIME_WAIT 状态，必须在此状态上停留两倍的 MSL 时间，等待 2MSL 时间主要目的是怕最后一个 ACK 包对方没收到，那么对方在超时后将重发第三次握手的 FIN 包，主动关闭端接到重发的FIN包后可以再发一个 ACK 应答包。在 TIME_WAIT 状态时两端的端口不能使用，要等到 2MSL 时间结束才可继续使用。当连接处于 2MSL 等待阶段时任何迟到的报文段都将被丢弃。不过在实际应用中可以通过设置 SO_REUSEADDR 选项达到不必等待 2MSL 时间结束再使用此端口

为什么需要四次握手才能断开连接？

因为全双工，发送方和接收方都需要FIN报文和ACK报文。

服务器出现大量CLOSE_WAIT 状态的原因。

对方关闭socket连接，我方忙于读或写，没有及时关闭连接：①检查代码，特别是释放资源的代码；②检查配置，特别是处理请求的线程配置。

获取Linux服务器中tcp连接的不同状态的数量

[root@dsd ~]# netstat -n | awk '/^tcp/{++S[$NF]}END{for (a in S) print a,S[a]}'
ESTABLISHED 2

十、一次完整的 HTTP 请求过程（DNS TCP HTTP）

总体来说分为以下几个过程:

DNS解析 [浏览器缓存、路由器缓存、DNS缓存]
TCP连接
发送HTTP请求
服务器处理请求并返回HTTP报文
浏览器解析渲染页面
连接结束

具体可以参考下面这篇文章：从输入URL到页面加载发生了什么？

附：HTTP状态码

1xx ：指示信息–表示请求已接受，继续处理
2xx：成功-- 表示请求已被成功接收、理解、接受
3xx：重定向–要完成请求必须跟进一步的操作
4xx：客户端错误：请求有语法错误或请求无法实现
5xx：服务端错误：服务器未能实现合法的请求

十一、简述 HTTP 中 GET 和 POST 的区别

GET 是用来从服务器上获得数据，而 POST 是用来向服务器上传递数据；
GET 将表单中数据的按照variable=value的形式，添加到action所指向的URL后面，并且两者使用“?”连接，而各个变量之间使用“&”连接；POST 是将表单中的数据放在form的数据体中，按照变量和值相对应的方式，传递到action所指向URL；
GET 是不安全的，因为在传输过程，数据被放在请求的URL中，而如今现有的很多服务器、代理服务器或者用户代理都会将请求URL记录到日志文件中，然后放在某个地方，这样就可能会有一些隐私的信息被第三方看到。另外，用户也可以在浏览器上直接看到提交的数据，一些系统内部消息将会一同显示在用户面前。POST的所有操作对用户来说都是不可见的；
GET 传输的数据量小，这主要是因为受URL长度限制；而POST可以传输大量的数据，所以在上传文件只能使用 POST；
GET 限制Form表单的数据集的值必须为ASCII字符；而 POST 支持整个ISO10646字符集；
从数据库层面来看，GET请求方式符合幂等性和安全性，GET请求方式是做查询操作，因此不会改变数据库中原有的数据，认为符合安全性；POST请求方式是既不幂等又不安全，首先POST请求方式往数据库中提交数据的，因此会改变数据库中的数据。
GET请求能够被缓存，会保存在浏览器的浏览记录中，以GET请求的URL能够保存为浏览器书签，而POST方式都不具备上述功能。

十二、HTTP2 与 HTTP 之间的区别

HTTP1.1和HTTP1.0的区别主要有：

1、缓存处理

2、带宽优化以及网络连接的使用

3、错误通知的管理

4、安全性及完整性

HTTP2.0的新特性

新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
**header压缩，**如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。目前，有大多数网站已经启用HTTP2.0，例如YouTuBe，淘宝网等网站，利用chrome控制台可以查看是否启用H2。

https://blog.csdn.net/yanghaolong/article/details/90764913

十三、参考

JavaGuide-计算机网络
fullstack-tutorial-计算机网络
百度百科-TCP/UDP协议