计算机网络 知识点整理

1. OSI

OSI参考模型（Open System Interconnection Reference Model，OSI/RM）是开放系统互连参考模型。1981年由国际标准化组织（ISO）提出的一个试图使各种计算机在世界范围内互连为网络的标准框架，为了解决不同体系结构的网络互联问题。

OSI参考模型定义了网络互连的七层框架，自上而下分为应用层、表示层、会话层、传输层、网络层、数据链路层和物理层。

分层原则
根据分而治之的原则，ISO将整个通信功能划分为七个层次，划分原则是：

1. 网路中各节点都有相同的层次；
2. 不同节点的同等层具有相同的功能；
3. 同一节点内相邻层之间通过接口通信；
4. 每一层使用下层提供的服务，并向其上层提供服务；
5. 不同节点的同等层按照协议实现对等层之间的通信。

七层框架

1. 应用层（Application Layer）：保持应用程序之间建立连接所需要的数据记录，为用户提供服务。常见协议：HTTP、HTTPS、FTP、SMTP和POP3等。
2. 表示层（Presentation Layer）：提供用于应用层数据的转换翻译、加密解密和压缩解压缩功能。
3. 会话层（Session Layer）：负责不同机器上的用户之间建立、管理和维护会话。
4. 传输层（Transfer Layer）：向用户提供可靠的端到端的服务，它屏蔽了下层的数据通信细节，让用户及应用程序不需要考虑实际的通信方法。常见协议：TCP和UDP等。
5. 网络层（Network Layer）：负责路由，选择合适的路径，进行拥塞控制等功能。常见协议：IP、IPX和OSPF等。主要设备：路由器。
6. 数据链路层（Data Link Review）：在两个主机上建立数据链路连接，向物理层传输数据信号，并对信号进行处理使之无差错并合理的传输。主要设备：二层交换机、网桥。
7. 物理层（Physical Layer）：负责实际的信号传输，定义网络的物理结构、传输的电磁标准、比特流的编码和网络的时间原则，如分时复用及分频复用。决定网络连接类型（端到端或多端连接）及物理拓扑结构。主要设备：中继器、集线器。

物理层、数据链路层和网络层是OSI参考模型的第三层，负责创建网络通信连接的链路；传输层、会话层、表示层和应用层为OSI参考模型的高四层，具体负责端到端的数据通信。

每层完成一定的功能，每层都直接为其上层提供服务，并且所有层次都互相支持，而网络通信则可以自上而下（在发送端）或者自下而上（在接收端）双向进行。当然并不是每一通信都需要经过OSI的全部七层，有的甚至只需要双方对应的某一层即可。物理接口之间的转接，以及中继器与中继器之间的连接就只需在物理层中进行即可；而路由器与路由器之间的连接则只需经过网络层以下的三层即可。总的来说，双方的通信是在对等层次上进行的，不能在不对称层次上进行通信。

通俗解释
A公司向B公司发送资料。

1. 应用层：记录待发送资料的内容；
2. 表示层：选择资料内容的语言，并进行转换翻译，还可以加密和压缩；
3. 会话层：将资料放到信封，并写上地址和联系方式；
4. 传输层：选择寄送的方式；
5. 网络层：告诉快递公司地址，由它们选择路线发送，从一个集散中心到另一个集散中心；
6. 数据链路层：快递公司对资料进行再包装，写上单号，供接受地核对（快递总是先送到对方集散中心，对方集散中心的地址就相当于MAC地址，快递号就相当于CRC校验码）；
7. 物理层：由汽车或火车等交通工具运输。

2. TCP/IP

OSI参考模型是学术上和法律上的国际标准，是完整的权威的网络参考模型。

TCP/IP参考模型借鉴了OSI参考模型，并且是事实上的国际标准，在现实生活中被广泛使用。TCP/IP 不单指TCP和IP这两个协议，而表示互联网所使用的整个TCP/IP协议族。包括应用协议 HTTP、SMTP 和 FTP 等；传输协议 TCP，UDP；网际协议 IP，ICMP，ARP；路由控制协议 RIP，OSPF，BGP。

3. 五层协议

应用层
通过应用程序间的交互来完成特定网络应用。应用层协议定义的是应用进程间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统 DNS，支持万维网应用的 HTTP 协议，支持电子邮件的 SMTP 协议等等。

运输层
负责向两台主机进程之间的通信提供通用的数据传输服务，应用进程利用该服务传送应用层报文。

由于一台主机可同时运行多个线程，因此运输层有复用和分用的功能。复用指多个应用层进程可同时使用下面运输层的服务，分用和复用相反。运输层主要使用两种协议，TCP（Transmission Control Protocol，传输控制协议）提供面向连接的，可靠的数据传输服务；UDP（User Datagram Protocol，用户数据协议）提供无连接的，尽最大努力的数据传输服务，但不保证数据传输的可靠性。

网络层
选择合适的网间路由和交换结点，确保数据及时传送。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报 ，简称 数据报。

数据链路层
两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。

在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始和到哪个比特结束。这样，数据链路层在收到一个帧后，就可从中提出数据部分，上交给网络层。 控制信息还使接收端能够检测到所收到的帧中有误差错。如果发现差错，数据链路层就简单地丢弃这个出了差错的帧，以避免继续在网络中白白传送浪费网络资源。如果需要改正数据在链路层传输时出现差错，那么就要采用可靠性传输协议来纠正出现的差错。

物理层
在物理层上所传送的数据单位是比特。 实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。 使其上面的数据链路层不必考虑网络的具体传输介质是什么。

4. TCP

4.1 与 UDP 区别

类型	是否面向连接	传输可靠性	传输形式	传输效率	所需资源	应用场景	首部字节
TCP	面向连接	可靠	字节流	慢	多	要求通信数据可靠（如文件传输）	20-40
UDP	无连接	不可靠	数据报文段	高	少	要求通信速度高（如即时通信）	8

TCP 提供可靠的，面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于 TCP 提供可靠的，面向连接的服务，需要通过三次握手来建立连接，在数据传递时有确认、窗口、重传、拥塞控制的机制，这使得协议数据单元的首部增大很多，还要占用许多资源。所以在数据传递完后，还会断开连接用来节约系统资源。TCP 一般用于文件传输、发送和接收邮件等场景。

UDP 提供不可靠，无连接的服务。在传送数据之前不需要先建立连接，接收方在收到数据报文后，不需要发出任何确认。UDP 一般用于即时通信，如：语音、视频、直播等。

4.2 三次握手

目的是建立可靠的通信信道。通信，简单来说就是数据的发送与接收，而三次握手最主要的目的就是让双方确认自己与对方的发送与接收是正常的。

1. 一次握手：客户端发送带有 SYN 标志的数据包，服务端接收。
   服务端确认了自己接收正常，对方发送正常。
2. 二次握手：服务端发送带有 SYN/ACK 标志的数据包，客户端接收。
   客户端确认了自己发送和接收正常，对方发送和接收正常。
3. 三次握手：客户端发送带有 ACK 标志的数据包，服务端接收。
   服务端确认了自己发送正常，对方接收正常。

4.3 四次挥手

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

1. 一次挥手：客户端发送一个 FIN，用来关闭客户端到服务器的数据传送。
2. 二次挥手：服务器收到这个 FIN，发回一个 ACK，确认序号为收到的序号加1 。
3. 三次挥手：服务器关闭与客户端的连接，发送一个 FIN 给客户端。
4. 四次挥手：客户端收到这个 FIN，发回 ACK 报文确认，并将确认序号设置为收到序号加1。

4.4 状态

假设连接的请求和释放都是由客户端主动发起的：

1. CLOSED 状态：初始状态，表示TCP连接是关闭的。
2. LISTEN 状态：服务端的某个端口正处于监听状态，正在等待客户端连接的到来。
3. SYN_SENT 状态：当客户端发送 SYN 请求建立连接之后，客户端处于 SYN_SENT 状态，等待服务器发送 SYN+ACK。
4. SYN_RCVD 状态：当服务器收到来自客户端的连接请求 SYN 之后，服务器处于 SYN_RCVD 状态，在接收到 SYN 请求之后会向客户端回复一个 SYN+ACK 的确认报文。
5. ESTABLISED 状态：当客户端回复服务器一个ACK和服务器收到该 ACK（TCP最后一次握手）之后，服务器和客户端都处于该状态，表示TCP连接已经成功建立。
6. FIN_WAIT_1 状态：当客户端想断开连接，会向服务器发送了一个 FIN 之后，客户端处于该状态。
7. FIN_WAIT_2 状态：当客户端收到服务器发送的连接断开确认 ACK 之后，客户端处于该状态。
8. CLOSE_WAIT 状态：当服务器发送连接断开确认 ACK 之后，但是还没有发送自己的 FIN 之前的这段时间，服务器处于该状态。
9. TIME_WAIT 状态：当客户端收到了服务器发送的 FIN 并且发送了自己的 ACK 之后，客户端处于该状态。
10. LAST_ACK 状态：表示被动关闭的一方（比如服务器）在发送 FIN 之后，等待对方的 ACK 报文时，就处于该状态。
11. CLOSING 状态：连接断开期间，一般是客户端发送一个 FIN，服务器回复一个 ACK，然后服务器发送完数据后再发送一个 FIN，当客户端和服务器同时接收到 FIN 时，客户端和服务器处于 CLOSING 状态，也就是此时双方都正在关闭同一个连接。

4.4.1 TIME_WAIT 状态

作用

1. 可靠终止 TCP 连接。如果最后一个 ACK 报文因为网络原因被丢弃，此时服务端因为没有收到 ACK 而超时重传 FIN 报文，处于 TIME_WAIT 状态的客户端可以继续对 FIN 报文做回复，向服务端发送 ACK 报文。
2. 保证让过期的 TCP 报文段有足够的时间被识别和丢弃。连接结束后，网络中的延迟报文也应该被丢弃掉，以免影响立刻建立的新连接。

大量的 TIME_WAIT 产生的原因：高并发，服务器主动关闭连接。

解决方法

1. 短连接变长连接，
2. 开启 TIME_WAIT 重用，

4.5 保证可靠传输

1. 应用数据被分割成 TCP 认为最适合发送的数据块，然后给发送的每一个包进行编号，接收端会丢弃重复的数据包，并对数据包进行排序，把有序数据传送给应用层。
2. 校验和：TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
3. 流量控制：利用滑动窗口实现流量控制。为了控制发送方发送速率，保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。如果将窗口字段设置为 0，那么发送方不能发送数据。
4. 拥塞控制：当网络拥塞时，减少数据的发送。
5. ARQ协议：为了实现可靠传输的，每发完一个分组就停止发送，等待对方确认，在收到确认后再发下一个分组。
6. 超时重传：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

4.6 拥塞控制

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

为了进行拥塞控制，TCP 发送方要维持一个拥塞窗口（cwnd）的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

算法

1. 慢开始（Slow Start）： 在不知道网络情况下，由小到大逐渐增大拥塞窗口数值。cwnd 初始值为1，每经过一个传播轮次，cwnd 加倍。
2. 拥塞避免（Congestion voidance）：TCP使用了一个慢启动门限（ssthresh）的变量，当 cwnd 超过该值后，慢启动结束，进入拥塞避免阶段，ssthresh 的值大多数为 65535。拥塞避免的思想就是转指数增大变为加法线性增大（每经过一个往返时间 RTT 就把发送方的 cwnd 加1），这样就可以避免增长过快导致网路拥塞，慢慢的增加调整到网络的最佳值。如果当前的 cwnd 达到慢启动的阈值，则试探性的发送一个 segment，如果服务器没有响应，TCP 认为网络能力下降，必须降低慢启动阈值，同时为了避免形式继续恶化，有可能将窗口降低为1。
   当 cwnd < ssthresh 时，使用慢开始算法；当cwnd > ssthresh时，改用拥塞避免算法；当 cwnd=ssthresh 时，慢开始与拥塞避免算法任意。
3. 快速重传（Fast Retransmit）：超时重传会导致 TCP 传输效率较低。当接收方接收到一个不按顺序的数据段，它会立即给发送方发送一个重复确认。发送方只要收到三个重复确认，就立即重传对方尚未收到的数据段。
4. 快速恢复（Fast Recovery）：配合快速重传，作为其后续处理。通常认为发送方接收到3个 ACK 后，就会开始快速重传。但是如果还有更多的重复 ACK，这个时候就需要快速恢复。
   当发送方连续收到三个重复确认时，就执行乘法减小算法，把 ssthresh 门限减半，即 cwnd=ssthresh/2，但接下去并不执行慢开始算法；考虑到此时能连续收到3个ACK，说明网络没有拥塞，执行加法原则，有几个ACK就加几个段的字节数，或者可以将cwnd=ssthresh，直接进入拥塞避免算法。

5. ARQ

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

5.1 停止等待ARQ协议

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

优点：简单；缺点：信道利用率低，等待时间长

5.2 连续ARQ协议

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

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

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

6. HTTP

HTTP 协议（Hypertext Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效，使网络传输减少。

TODO 一文带你看清 HTTP 所有概念看完这篇HTTP，跟面试官扯皮就没问题了

6.1 状态码

状态码	类别	原因
1XX	Informational（信息性状态码）	请求已接收，正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出错

6.2 状态

HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。

Session 机制就是为了保存用户状态，主要通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个Session。

在服务端保存 Session 的方法很多，最常用的就是内存和数据库（比如是使用内存数据库 Redis 保存）。通过在 Cookie 中附加一个 Session ID 方式来实现 Session 跟踪。当Cookie 被禁用时，利用 URL 重写把 Session ID 直接附加在URL路径的后面。

Cookie 与 Session
Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

Cookie 数据保存在客户端（浏览器端），一般用来保存用户信息，比如登录一次网站后访问网站其他页面不需要重新登录。
Session 数据保存在服务器端，通过服务端记录用户的状态。 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

6.3 HTTP 和 HTTPS

1. 端口：HTTP的URL由 http:// 起始且默认使用端口80，而HTTPS的URL由https://起始且默认使用端口443。
2. 安全性和资源消耗： HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以 HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。

1. 对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等。
2. 非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。

6.4 HTTP/1.0 和 HTTP/1.1

HTTP/1.0 最早在网页中使用是在1996年，那时只使用一些较为简单的网页上和网络请求上，而 HTTP/1.1 在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时 HTTP/1.1 也是当前使用最为广泛的HTTP协议。

1. 长连接：在 HTTP/1.0 中默认使用短连接。从 HTTP/1.1 起，默认使用长连接，用以保持连接特性。
2. 错误状态响应码：在 HTTP/1.1 中新增了24个错误状态响应码，如 409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
3. 缓存处理：在 HTTP/1.0 中主要使用 header 里的 If-Modified-Since，Expires 来做为缓存判断的标准，HTTP/1.1 则引入了更多的缓存控制策略Entity tag，If-Unmodified-Since，If-Match，If-None-Match等缓存头来控制缓存策略。
4. 带宽优化及网络连接的使用：在HTTP/1.0 中，客户端只是需要某个对象的一部分，而服务器会返回整个对象，并且不支持断点续传功能。在 HTTP/1.1 中请求头引入了 range 头域，它允许只请求资源的某个部分，返回状态码为206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
5. Host 头处理：在 HTTP/1.0 中认为每台服务器都绑定一个唯一的IP地址，因此请求消息中的 URL 并没有传递主机名。随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址。在 HTTP/1.1 中请求消息和响应消息都支持 Host 头域，且请求消息中如果没有 Host 头域会返回错误状态码 400（Bad Request）。

6.5 SPDY：Http/1.x 优化

SPDY 位于 HTTP 之下，TCP 和 SSL 之上，这样可以轻松兼容老版本的 HTTP 协议（将 HTTP/1.x 的内容封装成一种新的 frame 格式），同时可以使用已有的 SSL 功能。

1. 降低延迟：采用多路复用（MultiPlexing）让多个请求共享一个 TCP 连接的方式，解决了队头阻塞，也降低了延迟同时提高了带宽的利用率。
2. 请求优先级（Request Prioritization）：为了防止在连接共享时，可能导致关键请求被阻塞。SPDY 允许给每个请求设置优先级，保证重要的请求能优先响应。
3. header 压缩：选择合适的压缩算法减小包的大小和数量。
4. 基于 HTTPS 的加密协议传输：大大提高了传输数据的可靠性。
5. 服务端推送（Server Push）：例如客户端请求页面时，页面里面包含 main.js，服务端会把 main.js 推送给客户端。当客户端尝试获取 main.js 时可以直接从缓存获取。

6.6 HTTP/1.X 和 HTTP/2.0

HTTP/2.0 基于 SPDY，但也有不同：HTTP/2.0 支持明文传输，而 SPDY 强制使用 HTTPS；HTTP/2.0 消息头的压缩算法采用 HPACK，而 SPDY 采用的 DEFLATE。

1. 二进制格式（Binary Format）：HTTP/1.x 的协议解析是基于文本，基于文本协议的格式解析存在天然缺陷，由于文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，而二进制只有0和1的组合。因此 HTTP/2.0 的协议解析决定采用二进制格式，实现方便且健壮。
2. 多路复用（MultiPlexing）：连接共享，每一个请求都是用作连接共享机制的。一个请求对应一个 id，这样一个连接上可以有多个请求，每个连接的请求可以随机的混杂在一起，接收方可以根据请求的 id 将请求再归属到各自不同的服务端请求里面。
3. header压缩：HTTP/1.x 的 header 带有大量信息，而且每次都要重复发送，HTTP/2.0 使用压缩算法来减少需要传输的 header 大小，通讯双方各自缓存一份 header fields 表，既避免了重复 header 的传输，又减小了需要传输的大小。
4. 服务端推送（server push），同SPDY一样。

6.7 连接

6.7.1 短连接

在 HTTP/1.0 中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

6.7.2 长连接

从 HTTP/1.1起，默认使用长连接，在响应头加入 Connection:keep-alive。

实现长连接需要客户端和服务端都支持长连接。在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive 不会永久保持连接，它有一个保持时间，可以在不同的Web服务器软件中设定这个时间。

6.7.3 管道化（Pipelining）

HTTP/1.1 允许在长连接上选择使用请求管道，这是相对于keep-alive连接的又一性能优化。在响应到达之前，可以将多条请求放入队列，当第一条请求发往服务器的时候，第二条第三条请求也可以发送了，在高延时网络条件下，这样做可以降低网络的环回时间，提高性能。

1. 管道化要求服务端按照请求发送的顺序返回响应（FIFO），因为HTTP请求和响应并没有序号标识，无法将乱序的响应与请求关联起来。
2. 客户端需要保持未收到响应的请求，当连接意外中断时，需要重新发送这部分请求。
3. 只有幂等的请求才能进行管道化，也就是只有 GET 和 HEAD 请求才能管道化，否则可能会出现意料之外的结果。

6.7.4 队头阻塞

队头阻塞是由 HTTP 管道化引起的。管道化要求服务端必须按照请求发送的顺序返回响应，那如果一个响应返回延迟了，那么其后续的响应都会被延迟，直到队头的响应送达。

6.7.5 多路复用（MultiPlexing）

1. HTTP/1.0：一次请求和响应，就建立一个连接，用完关闭；每一个请求都要建立一个连接；
2. HTTP/1.1：管道化将若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，导致队头阻塞；
3. HTTP/2.0：多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行。

7. HTTPS

7.1 SSL

握手

1. 客户端给出协议版本号，客户端生成的随机数，以及客户端支持的加密方法；
2. 服务端确认双方使用的加密方法，并给出数字证书，以及一个服务端生成的随机数；
3. 客户端确认数字证书有效，并生成一个新的随机数，并使用数字证书中的公钥，加密这个随机数再发送给服务端；
4. 服务端使用自己的私钥，获取客户端发送的随机数；
5. 客户端和服务端根据约定的加密方法，使用前面的三个随机数，生成对话密钥，用来加密接下来的发送的数据。

私钥的作用

1. 生成对话密钥一共需要三个随机数。
2. 握手之后的对话使用"对话密钥"加密（对称加密），服务器的公钥和私钥只用于加密和解密"对话密钥"（非对称加密），无其他作用。
3. 服务器公钥放在服务器的数字证书之中。

8. URI 和 URL

URI（Uniform Resource Identifier）是统一资源标志符，可以唯一标识一个资源。
URL（Uniform Resource Location） 是统一资源定位符，可以提供该资源的路径，起到了URI的作用，可以用来标识一个资源，所以URL是URI的子集。

URI的作用像身份证号一样，URL的作用更像家庭住址一样。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

9. 在浏览器中输入url地址 -> 显示主页的过程

1. DNS解析：实现了域名到 IP 地址的转换。查找过程：浏览器缓存，路由器缓存，DNS缓存。
2. TCP连接：HTTP 协议是使用 TCP 作为其传输层协议的。
3. 浏览器向 Web 服务器发送一个HTTP请求：构建 HTTP 请求报文并通过 TCP 协议中发送到服务器指定端口（HTTP协议80/8080, HTTPS协议443）。HTTP 请求报文是由请求行，请求报头和请求正文三部分组成。
4. 服务器处理请求并返回HTTP报文。Web 服务器从在固定的端口接收到 TCP 报文，它会对 TCP 连接进行处理，对 HTTP 协议进行解析，并按照报文格式进一步封装成 HTTP Request 对象，供上层使用。HTTP 响应报文由状态码，响应报头和响应报文三部分组成。
5. 浏览器解析渲染页面。
6. 连接结束。

参考：
计算机网络
OSI七层模型与TCP/IP五层模型
OSI七层模型通俗解释
两张动图-彻底明白TCP的三次握手与四次挥手
Linux TCP 网络拥塞控制的困境
TCP协议的11种状态及其变化过程
关于time_wait状态的理解
Socket 连接问题之大量 TIME_WAIT
什么是队头阻塞以及如何解决
HTTP1.0、HTTP1.1和HTTP2.0的区别
图解SSL/TLS协议
看完这篇HTTP，跟面试官扯皮就没问题了
一文带你看清 HTTP 所有概念
从输入URL到页面加载发生了什么？