计算机网络

1. OSI与TCP/IP各层的结构与功能，都有哪些协议?

学习计算机网络时一般采用折中的办法，即中和OSI和TCP/IP的优点，采用一种只有五层协议的体系结构

1.1 应用层

应用层的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程(进程：主机中正在运行的程序)间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统 DNS，支持万维网应用的 HTTP 协议，支持电子邮件的 SMTP 协议等等。我们把应用层交互的数据单元称为报文。

域名系统(Domain Name System 缩写 DNS，Domain Name 被译为域名)是因特网的一项核心服务，它作为可以将域名和 IP 地址相互映射的一个分布式数据库，能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 数串。

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的 WWW（万维网） 文件都必须遵守这个标准。

1.2 运输层

运输层的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。由于一台主机可同时运行多个线程，因此运输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面运输层的服务，分用和复用相反，是运输层把收到的信息分别交付上面应用层中的相应进程。

运输层主要使用以下两种协议：

• 传输控制协议TCP:提供面向连接的，可靠的数据传输服务。
• 用户数据协议UDP:提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）

1.3 网络层

在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报 ，简称 数据报。

1.4 数据链路层

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

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

1.5 物理层

物理层(physical layer)的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异， 使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的。

2. TCP三次握手和四次挥手

TCP位于传输层，提供可靠的字节流服务。即为了方便管理，将大块数据分割成以报文段为单位的数据包进行管理，并且能够把数据准确可靠的传输给对方。为了准确无误地把数据送达目标处，TCP 协议采用了三次握手与四次挥手策略。

博客连接

2.1 三次握手过程与图解

详细示意图：

几个概念：

• 同步SYN：同步序列号，用来发起一个连接。当SYN=1而ACK=0时表明这是一个请求报文段；若对方同意连接，则响应报文中SYN=1，ACK=1
• 确认ACK： 仅当ACK=1时确认字段才有效，当ACK=0时确认字段无效，并且TCP规定，在连接建立后所有的传送报文段都必须要把ACK置为1
• 终止FIN：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接

第一次握手

首先服务端处于监听状态，等待客户端请求。

客户端请求连接，设置SYN标志置为1，随机选择一个seq=x作为初始序号，此时，客户端进入SYN-SEND（同步已发送）状态。注意：SYN报文段不能携带数据，但需要消耗一个序号。

服务器将该连接的状态变为SYN_RCVD, 服务器把连接信息放到半连接队列(syn queue)里面。如果半连接队列已满，则服务器不会将该连接的状态变为SYN_RCVD，且将该连接丢弃。

SYN flood攻击（SYN洪泛）就是利用这个原理，攻击方的客户端只发送SYN分节给服务器，然后对服务器发回来的SYN+ACK什么也不做，直接忽略掉，不发送ACK给服务器；这样就可以占据着服务器的半连接队列的资源，导致正常的客户端连接无法连接上服务器。

如何预防SYN洪泛攻击?

1. 增加半连接队列大小
2. 减少SYN-RCVD时间，即缩短一个TCB因进入SYN-RCVD状态而未进入下一个有效状态的时间
3. SYN缓存：简化因接收SYN而生成TCB时初始化的状态，推迟全状态的实例化。
4. SYN Cookies:做到了接收到一个SYN时完全不需要分配空间。

第二次握手

服务端如果同意连接，则发出确认报文。确认报文中应该ACK=1，SYN=1，确认号ack=x+1,同时自己也要初始化一个序列号seq=y，此时，服务器进入SYN_RCVD（同步收到）状态。注意：这个报文也不能携带数据，但同时要消耗一个序号。

第三次握手

客户端收到确认后，还要向服务端给出确认，确认报文ACK=1，ack=y+1,自己的序列号seq=x+1(SYN报文段消耗了一个序号)。此时，TCP连接建立，客户端进入ESTABLISHED(已建立连接)状态。注意：ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。

当服务端收到客户端确认后也进入ESTABLISHED状态，此后双方开始通信。

服务器将该连接从半连接队列(syn queue)里面移除，且将该连接的信息放到全连接队列(accept queue)里面。如果全连接队列已满，则会根据tcp_abort_on_overflow 的值来执行相应动作。如果值为0，则建立连接定时器，即定时发回ACK+SYN重新第二次握手；如果值为1，则重置连接。

2.2 为什么要三次握手？

一次握手情况

TCP是面向连接的, 一次很明显是不可能的, 因为客户端发出连接消息后, 却没有接收到来自服务端的回应, 客户端就无法确定服务端是否收到了连接请求, 当然也就不能确定是否连接成功。

两次握手情况

第三次握手的主要目的是防止已失效的请求报文段突然又传送到了服务端而产生连接的误判，浪费服务器资源。

如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。

如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

第二次握手传回了ACK，为什么还要传回SYN？

服务端传回客户端所发送的ACK，是为了告诉客户端，我接收到的信息确实就是你所发送的信号，表明从客户端到服务端的通信是正常的。而回传SYN则是为了建立并确认从服务端到客户端的通信。这样才会有第三次握手，即客户端的ACK报文段来确认。

为什么要随机序列号？

ISN(Innitial Sequence Number)被称为初始序列号，是TCP发送方的字节数据编号的原点，告诉对方我要开始发送数据的初始化序列号。

• ISN是固定不变的吗？

如果ISN是固定的，攻击者很容易猜到后续的确认序号，为了安全起见，避免被第三方猜到从而发送伪造的RST报文，因此ISN是动态生成的。

2.4 TCP连接的释放(四次挥手)

数据传输完毕后，双方都可释放连接。最开始，客户端服务端都处于ESTABLISHED状态，然后客户端主动关闭，服务端被动关闭。

1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。注意：FIN报文段即使不携带数据，也要消耗一个序号。
2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。注意：TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文。注意：在这之前，还需要接收服务器发送的最后的数据。
4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意：此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。注意：服务器结束TCP连接的时间比客户端要早一些。

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

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

2.6 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。

假想网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。

第二点理由是：避免新旧连接混淆,防止已失效的连接请求报文段出现在本连接中

在客户端发送完最后一个 ACK 报文段后，在经过 2MSL 时间，就可以使本连接持续的时间内所产生的所有报文都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文。

2.7 如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

2.8 如果服务端出现故障怎么办？

• 服务器崩溃

如果服务器主机出现故障，客户端TCP均会进行超时重传，一般重传12次后就会放弃重传并关闭该链接。

• 服务器崩溃后重启

如果在服务器崩溃后重启这段时间里，客户端没有因为超时重传超过限制而断开连接。则当客户端发送TCP报文后，由于服务器TCP连接已经关闭，会向客户端回复一个RST报文，客户端接收到该报文后将关闭连接。

3. TCP、UDP协议的区别

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP 的可靠体现在 TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 却是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等 。

3.1 UDP

UDP全称是用户数据报协议，有以下特性

• 面向无连接，只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。
• 有单播、多播、广播等功能。
• UDP是面向报文的，对应用程序交下来的报文，只会添加首部后就向下交付IP层，因此程序必须选择合适大小的报文。
• 不可靠性，体现在无连接上。
• 头部开销小，传输数据报文时很高效，头部只包含8字节（源端口和目标端口，报文长度与校验和）

3.2 TCP

TCP有以下特性：

• 面向连接，即发送数据前两端必须建立连接。
• 仅支持单播传输，只能进行点对点的数据传输。
• 可靠传输，可靠传输靠的是TCP段序号以及确认号。
• 提供拥塞控制
• TCP首部最小20字节，最大60字节。

4. TCP协议如何保证可靠传输

解决可靠性主要是解决以下几个问题：乱序、丢包、流量控制、拥塞控制。

1. 应用数据被分割成TCP认为最适合发送的数据块

为什么TCP会将应用数据做分割？

因为物理设备的限制导致IP协议会拆分数据，而TCP为了保证数据的可靠传输，受到IP协议的最大传输单元（MTU）的限制，也会对数据进行分割。**因为IP 协议对数据包的分片对上层是透明的，如果TCP协议不根据 MTU 做一些限制，那么 IP 协议的分片会导致部分数据包失去传输层协议头，一旦数据包发生丢失就只能丢弃全部数据。**当 IP 协议传输数据丢包时，TCP 协议的接收方没有办法对数据包进行重组，所以整个 TCP 数据段都需要重传，带来了更多额外的重传和重组开销。

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

4.1 ARQ协议

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

• 停止等待ARQ协议

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

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

注意：接收方收到重复的数据直接丢弃，发送方收到重复的确认消息，也直接丢弃。

• 连续ARQ协议

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

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

4.2 滑动窗口和流量控制

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

4.3 拥塞控制

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

TCP的拥塞控制采用了四种算法，即慢开始、拥塞避免、快重传和快恢复。

• 慢开始

慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。在一开始发送方先设置cwnd=1，每经过一次传输轮次之后拥塞窗口就加倍（2的指数倍增加）。

• 拥塞避免

由于慢开始每个轮次都将cwnd加倍, 这样会让cwnd增长速度非常快, 从而使得发送方发送的速度增长过快, 网络拥塞的可能性也就更高。设置一个慢开始门限ssthresh当cwnd> = ssthresh时, 进入拥塞避免, 每个轮次只将cwnd加1。如果出现了超时, 则令ssthresh = cwnd /2 然后重新执行慢开始。

• 快重传与快恢复

在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。

慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。

5. 浏览器输入url发生了什么？

博客地址

总体来说分为以下六个过程：

1. DNS解析
2. 建立TCP连接
3. 发送HTTP请求
4. 服务器处理请求并返回HTTP报文
5. 浏览器解析渲染页面
6. 连接结束

5.1 DNS解析

• 请求发起后，浏览器首先会解析这个域名，首先它会查看本地磁盘的hosts文件和操作系统中的DNS缓存，看看其中有没有和这个域名对应的IP，如果有的话直接使用hosts文件里面的ip地址
• 如果本地的hosts文件没有能够找到对应的ip地址，浏览器会发出一个DNS请求到本地DNS服务器，本地DNS服务器一般都是你的网络接入服务器提供商，如中国电信、中国移动
• 查询你输入的网址的DNS请求到达本地DNS服务器之后，本地DNS服务器会首先查询他的缓存记录，如果缓存中有此条记录，就可以直接返回结果，此过程是递归的方式进行查询。如果没有，本地DNS服务器还要向DNS根服务器进行查询

注意：下述过程是迭代查询

• 根DNS服务器没有记录具体的域名和IP地址对应关系, 而是告诉本地DNS服务器,你可以到对应的域服务器上去继续查询，并给出域服务器的地址。
• 本地DNS服务器继续向域服务器发出请求，域服务器收到请求之后，也不会直接返回域名和IP地址的对应关系，而是告诉本地DNS服务器，你的域名的解析服务器的地址。
• 本地DNS服务器向域名的解析服务器发出请求，这时就能收到一个域名和IP地址对应关系，本地DNS服务器不仅要把IP地址返回给用户浏览器，还要把这个对应关系保存在缓存中，以备下次别的用户查询时，可以直接返回结果，加快网络访问。

5.2 建立TCP连接

在拿到ip地址后, 浏览器会向对应的web服务器80端口发起TCP连接,并通过三次握手建立TCP连接。

5.3 发送HTTP请求

建立TCP连接之后，发起HTTP请求，HTTP请求报文一般分为四部分：请求行、请求头部、空行、请求体。

• 请求行：包括请求方法、访问资源的URL、使用的HTTP版本。
• 请求头部
• 请求体：主要是用户请求数据。

5.4 服务器处理请求

服务器端收到请求后的由web服务器（准确说应该是http服务器）处理请求，诸如Apache、Ngnix、IIS等。web服务器解析用户请求，知道了需要调度哪些资源文件，再通过相应的这些资源文件处理用户请求和参数，并调用数据库信息，最后将结果通过web服务器返回给浏览器客户端。HTTP响应报文也由四部分组成：状态行、响应头、空行、响应体。

• 状态行：包括协议版本、状态码及状态描述。
• 响应头：包括一些响应字段。
• 响应体：包括服务器返回给客户端的内容。

5.5 浏览器解析渲染页面

对于获取到的HTML、CSS、JS、图片等资源，浏览器通过解析HTML，生成DOM树，解析CSS生成CSS规则树，通过DOM树和CSS规则树生成渲染树。渲染树与DOM树不同，渲染树中并没有head，display为none等不必显示的节点。注意：在解析CSS的同时，可以继续加载解析HTML，但在解析执行JS脚本时，会停止解析后续HTML，这就会出现阻塞问题。

5.6 关闭TCP连接

为了避免服务器与客户端双方的资源占用和损耗，当双方没有请求或响应传递时，任意一方都可以发起关闭请求。TCP关闭需要四次握手。

6. 状态码

状态码很多，列出常见几种，如下：

• 200 OK

表示从客户端发来的请求在服务端被正常处理。

• 301与302的区别

301表示永久性重定向。搜索引擎在抓取新的内容的同时也将旧的网址替换为了重定向之后的网址。

302表示临时性重定向。搜索引擎会抓取新的内容而保留旧的地址，因为服务器返回302，所以，搜索搜索引擎认为新的网址是暂时的。

• 404

表示服务器上无法找到请求的资源。也可以在服务器拒绝请求且不想说明理由时使用。

• 500

表明服务器端在执行请求时发生了错误。也可能是web应用存在bug或某些临时的故障。

• 503

表明服务器暂时处于超负载或正在停机维护，现在无法处理请求。

7. 各种协议与HTTP协议之间的关系

8. URL与URI的区别是什么？

URL(Uniform Resource Locator)：是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。

URI(Uniform Resource Identifier)：是统一资源标识符，可以唯一标识一个资源。

URI用字符串标识某一互联网资源，而URL表示资源的地点（互联网上所处位置）。可见URL是URI的子集。

9. HTTP长连接、短连接

9.1 HTTP协议与TCP/IP协议的关系

**HTTP的长连接和短连接本质上是TCP长连接和短连接。**HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。 IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠地传递数据包，使得网络上接收端收到发送端所发出的所有包，并且顺序与发送顺序一致。TCP协议是可靠的、面向连接的。

9.2 如何理解HTTP协议是无状态的

HTTP协议是无状态的，指的是协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。也就是说，打开一个服务器上的网页和上一次打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）。

9.3 什么是长连接、短连接？

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

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

Connection:keep-alive

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

9.4 长连接与短连接优缺点

长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可 以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。

短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。

一般数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源。

10. HTTP1.0与HTTP1.1的区别?

HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在：

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

HTTP2.0

• 多路复用

每个HTTP请求中都会有一个帧来标识，因此可以乱序请求，使每个请求都不互相依赖，服务端也可以乱序给出响应，最后客户端根据帧标识也能够进行重新排序整合。允许同时发送多个请求和响应，并且这些请求和响应能够并行传输而不被阻塞。

• 二进制分帧层

HTTP2.0在TCP传输层与HTTP应用层中间插入了二进制分帧层，支持了二进制数据的传输，HTTP1.x基于文本格式的传输。

• 头部压缩

HTTP1.x的头带有大量信息，而且每次都要重复发送。HTTP2.0中使用头部压缩来减少需要传输的header大小，并且通讯双方各自缓存一份头部字段表，既避免了重复header的传输，减少了冗余数据，又减小了需要传输的大小。

• 服务端推送

HTTP2.0的服务端推送将支持服务端向客户端的单次请求返回多个响应，而不必每次都要客户端重复发起资源请求。即服务端向客户端推送资源。

HTTP3.0

• Quic协议

11. cookie和session的区别

• cookie实际上是一小段的文本信息。浏览器发送请求到服务器，如果服务器需要记录该用户的状态（比如：用户访问网页的次数，登录状态等），就使用response向客户端浏览器颁发一个cookie。客户端浏览器会把cookie保存起来。当浏览器再次请求该网站时，浏览器就会把请求地址和cookie一同给服务器。服务器检查该cookie，从而判断用户的状态。服务器还可以根据需要修改cookie的内容。

• session也是类似的记录用户状态的机制。不同的是**cookie保存在客户端浏览器中，而session保存在服务器上。**session比cookie安全，别人可以分析存放在本地的cookie并进行cookie欺骗。cookie能保存的数据量比session小，cookie可以设置为长时间保存。session一般失效时间短，客户端关闭或者session超时都会失效。

12. POST和GET的区别？

12.1 是什么

GET和POST都是HTTP协议中发送请求的方法。本质上都是TCP连接，并不差别，但是由于HTTP的规定和浏览器/服务器的限制，导致它们在应用过程中会有一些区别。

12.2 区别

• 参数位置

当携带参数时，GET请求放在url中，POST则放在body中。

注意：这并不属于HTTP规范，只是约定。

• 安全

因为数据在地址栏上不可见，所以POST比GET安全，但是从传输角度说，它们都不安全，因为HTTP在网络上是明文传输，只有使用HTTPS才能加密安全。

• 数据包

对于GET方式的请求，浏览器会把http header和data一起发送出去，服务器响应200并返回数据。

对个POST请求，浏览器先发送header，服务器响应100(continue)，浏览器再发送data，服务器响应200(ok)。

但并不是所有的浏览器都会在POST中发送两次包，Firefox就只发送一次。

13. 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 耗费更多服务器资源。

对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有 DES、AES 等；

非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有 RSA、DSA 等。这种加密方式安全性高，计算量大。

HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。

3. HTTPS协议需要到CA申请证书，一般免费证书较少，需要一定费用。

14. HTTPS原理

HTTP的最大弊端

HTTP在传输数据过程中，所有数据都是明文传输，没有安全性可言。

要想HTTP安全，只能使用加密算法，因为加密算法可以用秘钥加密或还原数据，只要确保秘钥不被第三方获取，就能确保数据传输的安全。

加密算法

HTTPS解决数据传输安全问题使用了对称加密与非对称加密。

对称加密

对称加密指加密和解密都是使用同一个秘钥，常见对称加密算法有DES、3DES和AES等。

• 优点：算法公开，计算量小，加密速度快，加密效率高，适合加密比较大的数据。
• 缺点：交易双方需要使用相同的秘钥，因此无法避免秘钥的传输，则秘钥可能被劫持。

非对称加密

加密和解密使用不同的秘钥：公钥和私钥。公钥加密数据私钥可以解密，私钥加密数据公钥可以解密。常见的有RSA算法。

• 优点：算法公开，加密和解密使用不同秘钥，私钥不需要通过网络传输，安全性很高。
• 缺点：计算量比较大，加密和解密速度相比对称加密慢很多。

HTTPS原理

HTTPS是基于HTTP的扩展，用于计算机网络的安全通信。在HTTPS中，原有的HTTP协议会得到TLS（安全传输层协议）或SSL（安全套接层）的加密。二者关系如下：

HTTPS整个通信过程可以分为两大阶段：证书验证和数据传输阶段，数据传输阶段又可以分为非对称加密和对称加密阶段。

1. 客户端请求HTTPS网址，然后连接到server的443端口（HTTPS的默认端口，HTTP默认端口是80端口）。
2. 采用 HTTPS 协议的服务器必须要有一套数字 CA (Certification Authority)证书，证书是需要申请的，并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书 (当然了是要钱的，安全级别越高价格越贵)。颁发证书的同时会产生一个私钥和公钥。**私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。**证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被篡改。
3. 服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等。
4. 客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码 KEY，并使用公钥A将其加密。
5. 客户端把加密后的随机码 KEY 发送给服务器，作为后面对称加密的密钥。
6. 服务器在收到随机码 KEY 之后会使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了。
7. 服务器使用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端，客户端使用相同的密钥 (随机码 KEY)解密数据。

总结

HTTPS和HTTP的区别：

• 最重要的区别就是安全性，HTTP 明文传输，不对数据进行加密安全性较差。HTTPS (HTTP + SSL / TLS)的数据传输过程是加密的，安全性较好。
• 使用 HTTPS 协议需要申请 CA 证书，一般免费证书较少，因而需要一定费用。
• HTTP 页面响应速度比 HTTPS 快，这个很好理解，由于加了一层安全层，建立连接的过程更复杂，也要交换更多的数据，难免影响速度。
• 由于 HTTPS 是建构在 SSL / TLS 之上的 HTTP 协议，所以，要比 HTTP 更耗费服务器资源。
• HTTPS 和 HTTP 使用的是完全不同的连接方式，用的端口也不一样，前者是 443，后者是 80。

SSL/TLS概念

HTTPS相比HTTP最大的不同就是多了一层SSL（Secure Sockets Layer 安全套接层）或TLS（Transport Layer Security 安全传输层协议）。但是SSL已经逐渐被TLS取代。TLS握手是HTTPS通信的基础部分。

TLS握手

TLS握手的目的是建立安全连接，这个过程中：

• 商定了双方通信所使用的TLS版本；
• 确定双方所要使用的密码组合；
• 客户端通过服务端的公钥和数字证书上的数字签名验证服务端身份；
• 生成会话秘钥，该秘钥用户后续对称加密。

TLS握手详细过程：

1. **“client hello"消息：**客户端通过发送"client hello"消息向服务器发起握手请求，该消息包含了客户端所支持的 TLS 版本和密码组合以供服务器进行选择，还有一个"client random"随机字符串。
2. **“server hello"消息：**服务器发送"server hello"消息对客户端进行回应，该消息包含了数字证书，服务器选择的密码组合和"server random"随机字符串。
3. **验证：**客户端对服务器发来的证书进行验证，确保对方的合法身份，验证过程可以细化为以下几个步骤：
   1. 检查数字签名
   2. 验证证书链 (这个概念下面会进行说明)
   3. 检查证书的有效期
   4. 检查证书的撤回状态 (撤回代表证书已失效)
4. **“premaster secret"字符串：**客户端向服务器发送另一个随机字符串"premaster secret (预主密钥)"，这个字符串是经过服务器的公钥加密过的，只有对应的私钥才能解密。
5. **使用私钥：**服务器使用私钥解密"premaster secret”。
6. 生成共享密钥：客户端和服务器均使用 client random，server random 和 premaster secret，并通过相同的算法生成相同的共享密钥 KEY。
7. **客户端就绪：**客户端发送经过共享密钥 KEY加密过的"finished"信号。
8. **服务器就绪：**服务器发送经过共享密钥 KEY加密过的"finished"信号。
9. **达成安全通信：**握手完成，双方使用对称加密进行安全通信。