计算机网络面试题
在浏览器地址栏输入一个URL后回车，执行的全部过程
参考文档
识别URL
查找本地hosts文件
2.1. 询问本地域名服务器
2.2. 询问根域名服务器
建立TCP连接
发起HTTP请求
服务器响应HTTP请求， 返回资源文件
TCP连接释放
浏览器渲染页面
tcp、udp、http、https等常用协议
1.HTTP(Hypertext Transfer Protocol) 超文本传输协议(80)
1).无状态(cookie/session keep-alive)
2).无连接
3).基于请求和响应
4).简单灵活
5).通信使用明文
2.HTTPS(Hypertext Transfer Protocol Secure)超文本传输安全协议(443)
1).HTTP+SSL(Netscape的安全套接层)
a).SSL((Secure Sockets Layer) 安全套接层(40-128)
b).TLS(Transport Layer Security) 传输层安全
2).数据加密(SSL);身份认证(CA证书[采用非对称加密])
3.TCP(Transmission Control Protocol)传输控制协议
1).面向连接
2).可靠传输的情况, 应用于文件传输, 重要状态更新等场景
3).传输大量数据
4).传输慢
4.UDP(User Data Protocol)用户数据协议
1).面向非连接
2).高速传输和实时性要求较高的通信领域(可靠性需要应用层控制)
3).传输少量数据
4).传输快
5.Socket(程序通过一个双向的通信连接实现数据的交换，连接的一端称为一个socket)(API)
1).socket本质是编程接口(API),对TCP/IP的封装,TCP/IP也要提供可供程序员做网络开发所用的接口，这就是Socket编程接口
2).连接过程:服务器监听，客户端请求，连接确认
3).优势与劣势
A).优势:
a).传输数据为字节级，传输数据可自定义，数据量小
b).传输数据时间短，性能高
c).适合于客户端和服务器端之间信息实时交互
d).可以加密,数据安全性强
B).劣势:
a).需对传输的数据进行解析，转化成应用级的数据
b).相对于HTTP协议传输，增加了开发量
c).对开发人员的开发水平要求高
4).基于Socket传输的特点其适用于对传输速度，安全性，实时交互，费用等要求高的应用中，如网络游戏，手机应用，银行内部交互等
6.TCP/IP(TCP/IP Protocol Suite)TCP/IP协议族
1).四层模型
a).应用层 有FTP、HTTP、TELNET、SMTP、DNS等协议
b).传输层 有TCP协议与UDP协议
c).网络层 有IP协议、ICMP协议、ARP(地址解析)协议、RARP(反向地址解析)协议和BOOTP协议
d).网络接口层 有FDDI、Ethernet、Arpanet、PDN、SLIP、PPP、IEEE802.1A、IEEE802.2-IEEE802.11
2).五层模型
a).应用层 有FTP、HTTP、TELNET、SMTP、DNS等协议
b).传输层 有TCP协议与UDP协议
c).网络层 有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议
d).数据链路层 有FDDI、Ethernet、Arpanet、PDN、SLIP、PPP
e).物理层 有IEEE802.1A、IEEE802.2- IEEE802.11等协议
OSI七层模型
应用层
应用层的协议定义了应用进程之间通信和交互的规则，主要包括了域名系统 DNS、支持万维网的 HTTP协议、支持电子邮件的 SMTP 协议、文件传输协议 FTP 等。
域名解析系统 DNS
主机向本地域名服务器的查询一般都采用递归查询，递归查询指如果主机所询问的本地域名服务器不知道被查询域名的 IP 地址，那么本地域名服务器就以 DNS 客户的身份向其他根域名服务器继续发出查询请求报文。递归查询的结果是要查询的 IP 地址，或者是报错，表示无法查询到所需的 IP 地址。
本地域名服务器向根域名服务器查询通常采用迭代查询，迭代查询指当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的
IP 地址，要么告诉它该向哪一个域名服务器进行查询。本地域名服务器也可以采用递归查询，这取决于最初的查询请求报文设置的查询方式。
文件传送协议 FTP
FTP 使用 TCP 可靠的运输服务，FTP 使用客户服务器方式，一个 FTP服务器进程可以同时为多个客户进程提供服务、
在进行文件传输时，FTP 的客户和服务器之间要建立两个并行的 TCP连接：控制连接和数据连接，实际用于传输文件的是数据连接。
运输层
运输层的任务就是负责向两台主机中进程之间的通信提供通用的数据传输服务，运输层主要使用两种协议：
用户数据报协议 UDP，这是一种提供无连接的、尽最大努力交付的数据传输服务，不保证数据传输的可靠性，数据传输单位是用户数据报。
传输控制协议 TCP，这是一种面向连接的、可靠的数据传输服务，数据传输单元是报文。
网络层
网络层负责为分组交换网上的不同主机提供通信服务，在发生数据时，网络层把数据层产生的报文或用户数据报封装成分组进行传送，由于网络层使用 IP协议，因此分组也叫 IP 数据报。
网络层的另一个任务就是选择合适的路由，使源主机运输层所传下来的分组能够通过网络中的路由器找到目的主机。网络层的协议包括了网际协议 IP、地址解析协议 ARP、网际控制报文协议 ICMP 以及路由选择协议RIP/OSPF/BGP-4 等。
网际协议 IP
网际协议 IP 是 TCP/IP 体系中两个最主要的协议之一，一般指的是 IPv4。
IPv4和IPv6的区别
地址空间不同，IPv4中规定IP地址长度为32，而IPv6中IP地址的长度为128。
路由表大小不同，IPv6的路由表相比IPv4的更小。
安全性不同，IPv6的安全性更高，在使用IPv6的网络时，用户可对网络层的数据进行加密。
地址解析协议 ARP
ARP 的作用是通过一个 ARP 高速缓存，存储本地局域网的各主机和路由器的 IP 地址到硬件地址的映射表，以从网络层的 IP地址解析出在数据链路层使用的硬件地址，因此也可以把 ARP 划归在数据链路层。
与 ARP 对应的协议是 RARP，逆地址解析协议，作用是使只知道自己硬件地址的主机能够找出 IP 地址，但被 DHCP 协议取代。
网际控制报文协议 ICMP
ICMP 报文作为 IP 数据报的数据，加上首部后组成 IP 数据报发送出去，使用 ICMP 并非为了实现可靠传输，ICMP允许主机或路由器报告差错情况和提供有关异常情况的报告。ICMP 报文的种类有两种，即 ICMP 差错报告报文和 ICMP 询问报文。
ICMP 的一个重要应用就是分组间探测 PING，用来测试两台主机之间的连通性，PING 使用了 ICMP 回送请求与回送回答报文。
链路层
数据链路层的任务是将网络层交下来的 IP 数据报组装成帧，在两个相邻结点之间的链路上传输帧，每一帧包括数据和必要的控制信息（同步信息、地址信息、差错控制等）
点对点协议 PPP
PPP 协议的特点是简单、只检测差错而不纠正差错、不使用序号也不进行流量控制、可
同时支持多种网络层协议。
物理层
物理层的任务是尽可能地屏蔽掉传输媒体和通信手段的差异，使物理层上面的数据链路层感觉不到这些差异，使其只需考虑本层的协议和服务。
物理层所传输的数据单位是比特，发送方发送 1 或 0，接收方也接收 1 或 0，因此物理层需要考虑用多大的电压代表 1 或 0，以及接收方如何识别出发送方所发送的比特。
除此之外，物理层还要确定连接电缆的插头应当有多少根引以及各引脚如何连接等问题。
TCP 特点
TCP 是面向连接的运输层协议，一个应用进程在向另一个进程发送数据之前，两个进程必须先建立 TCP连接
TCP 连接提供全双工服务，允许通信双方的应用进程在任何时候都能发送数据。
TCP 连接是点对点的，每一条 TCP 连接只能有两个端点，即只能是单个发送方和单个接收方之间的连接。
TCP 提供可靠的交付服务，通过 TCP 连接传送的数据无差错、不丢失、不重复，按序到达。
TCP 是面向字节流的，流是指流入到进程或从进程中流出的字节序列。面向字节流的含义是：虽然应用程序和 TCP 的交互是一次一个数据块，但是 TCP 把应用程序交下来的数据仅仅看成一连串无结构的字节流。接收方应用程序必须有能力识别收到的字节流，并把它还原成有意义的应用层数据。
三次握手与四次关闭
参考文档
TCP报文结构：
TCP标志位：
TCP三次握手：
第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
TCP四次挥手：
客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
为什么连接的时候是三次握手，关闭的时候却是四次握手？
因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
为什么不能用两次握手进行连接？
3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
TCP 可靠原理
TCP 的可靠传输包含很多机制，例如使用检验和来检测一个传输分组中的比特错误、使用定时器来用于超时重传一个分组、使用序号来检测丢失的分组和冗余副本、使用确认来告诉发送方确认的分组信息、使用否定确认来告诉发送方某个分组未被正确接收。除此之外，TCP 还使用流量控制和拥塞控制来保证可靠性。
流量控制和拥塞控制
流量控制：如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。TCP的流量控制是利用滑动窗口机制实现的，接收方在返回的数据中会包含自己的接收窗口的大小，以控制发送方的数据发送。
拥塞控制：拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。
区别：流量控制是为了预防拥塞。如：在马路上行车，交警跟红绿灯是流量控制，当发生拥塞时，如何进行疏散，是拥塞控制。流量控制指点对点通信量的控制。而拥塞控制是全局性的，涉及到所有的主机和降低网络性能的因素。
拥塞解决的两种方法：
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
慢开始+拥塞避免：发送方维持一个拥塞窗口 cwnd ( congestion window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞。发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
快重传+快恢复：快重传要求接收方在收到一个失序的报文段后就立即发出重复确认。如果没有快速重传和快速恢复，TCP将会使用定时器来要求传输暂停。在暂停这段时间内，没有新的数据包被发送。所以快速重传和快速恢复旨在快速恢复丢失的数据包。
参考文档
tcp粘包与拆包
参考文档
产生tcp粘包和拆包的原因
tcp是以流动的方式传输数据，传输的最小单位为一个报文段（segment）。tcp Header中有个Options标识位，常见的标识为mss(Maximum Segment Size)指的是，连接层每次传输的数据有个最大限制MTU(Maximum Transmission Unit)，一般是1500比特，超过这个量要分成多个报文段，mss则是这个最大限制减去TCP的header，光是要传输的数据的大小，一般为1460比特。换算成字节，也就是180多字节。
tcp为提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了之后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制，来接收数据。
发生TCP粘包、拆包主要是由于下面一些原因：
应用程序写入的数据大于套接字缓冲区大小，这将会发生拆包。
应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生粘包。
进行mss（最大报文长度）大小的TCP分段，当TCP报文长度-TCP头部长度>mss的时候将发生拆包。
接收方法不及时读取套接字缓冲区数据，这将发生粘包。
如何解决拆包粘包
既然知道了tcp是无界的数据流，且协议本身无法避免粘包，拆包的发生，那我们只能在应用层数据协议上，加以控制。通常在制定传输数据时，可以使用如下方法：
使用带消息头的协议、消息头存储消息开始标识及消息长度信息，服务端获取消息头的时候解析出消息长度，然后向后读取该长度的内容。
设置定长消息，服务端每次读取既定长度的内容作为一条完整消息。
设置消息边界，服务端从网络流中按消息编辑分离出消息内容。
HTTP1.0
HTTP1.0规定浏览器和服务器保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）
无连接的特性导致最大的性能缺陷就是无法复用连接。每次发送请求的时候，都需要进行一次TCP的连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率非常低。
其次就是队头阻塞（head of line
blocking）。由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送。假设前一个请求响应一直不到达，那么下一个请求就不发送，同样的后面的请求也给阻塞了。
HTTP1.1
对于HTTP1.1，不仅继承了HTTP1.0简单的特点，还克服了诸多HTTP1.0性能上的问题。
首先是长连接，HTTP1.1增加了一个Connection字段，通过设置Keep-Alive可以保持HTTP连接不断开，避免了每次客户端与服务器请求都要重复建立释放建立TCP连接，提高了网络的利用率。如果客户端想关闭HTTP连接，可以在请求头中携带Connection: false来告知服务器关闭请求。
其次，是HTTP1.1支持请求管道化（pipelining）。基于HTTP1.1的长连接，使得请求管道化成为可能。管线化使得请求能够“并行”传输。举个例子来说，假如响应的主体是一个html页面，页面中包含了很多img，这个时候keep-alive就起了很大的作用，能够进行“并行”发送多个请求。
HTTPS与HTTP的一些区别
HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。
HTTPS加密过程：
1、客户端请求服务器获取证书公钥
2、客户端(SSL/TLS)解析证书（无效会弹出警告）
3、生成随机值
4、用公钥加密随机值生成密钥
5、客户端将秘钥发送给服务器
6、服务端用私钥解密秘钥得到随机值
7、将信息和随机值混合在一起进行对称加密
8、将加密的内容发送给客户端
8、客户端用秘钥解密信息
HTTP 2.0
二进制分帧：HTTP2.0通过在应用层和传输层之间增加一个二进制分帧层，突破了HTTP1.1的性能限制、改进传输性能。
多路复用：所有的HTTP2.0通信都在一个TCP连接上完成，这个连接可以承载任意数量的双向数据流。
首部压缩：在 HTTP/1 中，HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成。一般而言，消息主体都会经过
gzip 压缩，或者本身传输的就是压缩过后的二进制文件（例如图片、音频），但状态行和头部却没有经过任何压缩，直接以纯文本传输。
服务器推送：HTTP/2引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前。一个服务器经常知道一个页面需要很多附加资源，在它响应浏览器第一个请求的时候，可以开始推送这些资源。这允许服务端去完全充分地利用一个可能空闲的网络，改善页面加载时间。
http中 get和post区别
https://www.jianshu.com/p/a9142a4d084f
HTTP协议对GET和POST都没有对长度的限制：HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。
数据长度：
GET:特定浏览器和服务器对URL长度有限制，例如 IE对URL长度的限制是2083字节(2K+35)
POST:由于不是通过URL传值，理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。
安全性：
通过GET提交数据，用户名和密码将明文出现在URL上，因为登录页面有可能被浏览器缓存，其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了。
post一般来说都不会被缓存，但有很多抓包工具也是可以窥探到你的数据，真的要安全那就要把传输的信息加密。
get在HTPP协议中用于获取数据，post在在HTTP协议中用于修改数据。
既然post有这么多优点，那我们为什么要使用get？
一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查 ，改 ，增 ，删4个操作。
get比post更快：post请求的过程，会先将请求头发送给服务器进行确认，然后才真正发送数据；而get请求的过程，会在连接建立后会将请求头和请求数据一起发送。
post请求的过程
浏览器请求tcp连接（第一次握手）
服务器答应进行tcp连接（第二次握手）
浏览器确认，并发送post请求头（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）
服务器返回100 continue响应
浏览器开始发送数据
服务器返回200 ok响应
get请求的过程
浏览器请求tcp连接（第一次握手）
服务器答应进行tcp连接（第二次握手）
浏览器确认，并发送get请求头和数据（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）
服务器返回200 ok响应
常见的web请求返回的状态码
2xx - 客户端请求已成功。
200 - 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页
201 - 已创建，请求成功并且服务器创建了新的资源
202 - 已接受，但尚未处理
203 - 非权威性信息，服务器已成功处理了请求，但返回的信息可能来自另一来源
204 - 无内容，服务器成功处理了请求，但没有返回任何内容
205 - 重置内容，服务器成功处理了请求，但没有返回任何内容
206 - 部分内容，服务器成功处理了部分 GET 请求
3xx - 重定向
302 - 对象已移动
304 - 未修改
307 - 临时重定向
404 -Not Found 代表客户端错误，指的是服务器端无法找到所请求的资源
400 -请求无效，服务器不理解请求的语法
403 - 禁止访问 ，服务器拒绝请求
405 - 资源被禁止，禁用请求中指定的方法
406 - 无法接受 ，无法使用请求的内容特性响应请求的网页
407 - 要求代理身份验证 ，此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理
408 - 请求超时，服务器等候请求时发生超时
409 - 冲突，服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息
410 - 已删除，如果请求的资源已永久删除，服务器就会返回此响应。
411 - 需要有效长度， 服务器不接受不含有效内容长度标头字段的请求。
412 - 未满足前提条件， 服务器未满足请求者在请求中设置的其中一个前提条件。
413 - 请求实体过大，服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 - 请求的 URI 过长， 请求的 URI（通常为网址）过长，服务器无法处理。
415 - 不支持的媒体类型， 请求的格式不受请求页面的支持。
416 - 请求范围不符合要求，如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 - 未满足期望值，服务器未满足”期望”请求标头字段的要求
500 - 内部服务器错误，无法完成请求
501 - 未实现 ，服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码
502 - 网关错误 ，服务器作为网关或代理，从上游服务器收到无效响应
503 - 服务不可用，服务器目前无法使用，通常，这只是暂时状态
504 - 网关超时， 服务器作为网关或代理，但是没有及时从上游服务器收到请求
505 - HTTP 版本不受支持， 服务器不支持请求中所用的 HTTP 协议版本
http/3
HTTP/1.x 有连接无法复用、队头阻塞、协议开销大和安全因素等多个缺陷；
HTTP/2 通过多路复用、二进制流、Header 压缩等等技术，极大地提高了性能，但是还是存在着问题的；
QUIC 基于 UDP 实现，是 HTTP/3 中的底层支撑协议，该协议基于 UDP，又取了 TCP 中的精华，实现了即快又可靠的协议。
参考文档
cookie 与 session
所以，总结一下：
Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中；
Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。
本来 session 是一个抽象概念，开发者为了实现中断和继续等操作，将 user agent 和 server之间一对一的交互，抽象为“会话”，进而衍生出“会话状态”，也就是 session 的概念。
而 cookie 是一个实际存在的东西，http 协议中定义在 header 中的字段。可以认为是 session 的一种后端无状态实现。
cookie被禁用，如何实现session
经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。
还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器
进程间通讯的方式
liunx六大进程间通信方式：管道，消息队列，共享内存，信号量，socket，信号，文件锁
参考文档
什么是CDN？如果实现？
由于用户访问源站业务有性能瓶颈，通过cdn技术把源站的内容缓存到多个节点。用户向源站域名发起请求时，请求会被调度至最接近用户的服务节点，直接由服务节点直接快速响应，有效降低用户访问延迟，提升可用性。
什么是正向代理、反向代理？
正向代理
1、用户发送请求到自己的代理服务器
2、自己的代理服务器发送请求到服务器
3、服务器将数据返回到自己的代理服务器
4、自己的代理服务器再将数据返回给用户
反向代理
1、用户发送请求到服务器（访问的其实是反向代理服务器，但用户不知道）
2、反向代理服务器发送请求到真正的服务器
3、真正的服务器将数据返回给反向代理服务器
4、反向代理服务器再将数据返回给用户
