计算机网络相关

一、OSI和TCP/IP各层结构与功能

1. OSI七层模型

每层实现各自功能和协议，并完成与相邻层的接口通信。
应用层
该层协议定义了应用进程之间的交互规则，通过不同的应用层协议为不同的网络应用提供服务。
表示层
作用：使通信的应用程序能够解释交换数据的含义。
提供的服务主要是数据压缩、数据加密、数据描述。
会话层
作用：负责建立、管理和终止表示层实体之间的通信回话。
该层提供了数据交换的定界和同步功能。
传输层
作用：为两台主机进程之间的通信提供服务。
网络层
选择合适的网间路由和交换节点，确保数据按时发送成功。
数据链路层
将网络层交下来的IP数据包组装成帧，在两个相邻结点之间的链路上传送帧。
物理层
实现计算机节点之间比特流的透明传输。

2. TCP/IP四层模型

OSI模型的提出是基于标准化考虑，没有考虑具体的市场需求，使得模型结构复杂，功能冗余，因此提出了面向市场需求的TCP/IP四层模型
应用层
应用层、表示层、会话层的整合。通过不同的应用层协议为不同的应用提供服务。
eg：域名系统 DNS，支持万维网应用的 HTTP 协议，支持电子邮件的 SMTP 协议等等。我们把应用层交互的数据单元称为报文。
传输层
负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。
主要的两个协议：TCP、UDP
网际互联层
。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。
IP协议提供的是不可靠、无连接的数据传递服务。两个基本功能：寻址和分段
协议：IP协议、IGMP、ICMP
网络接入层
对应物理层和数据链路层，负责监视数据在主机和网络之间的交换。
协议：PPP、802.3

3. 各个层次之间常用协议

（1）应用层

HTTP协议：超文本传输协议，本质上是一种通信协议。HTTP定义了web客户机如何向服务器请求web页面，以及服务器如何将web页面传送给客户机。Http协议运行在TCP之上。
FTP协议：文件传输协议。也运行在TCP之上。
DNS协议：提供的服务是域名到IP地址的转换。DNS协议运行在UDP之上，使用53号端口。

（2）传输层

TCP：TCP提供可靠交付，面向连接的服务。
UDP：UDP提供不可靠、无连接服务。

（3）网络层

IP协议：根据数据包的目的IP地址来决定如何投递它。
ICMP协议：主要用于监测网络链接。

（4）数据链路层

ARP协议：地址解析协议，根据IP地址获取物理地址MAC。
RARP协议：逆地址解析协议：根据MAC获取IP地址。

二、HTTP与HTTPS

1.二者比较

• HTTP 协议以明文方式发送内容，数据都是未加密的，安全性较差。HTTPS 数据传输过程是加密的，安全性较好。
• HTTP 和 HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是 80 端口，后者是 443 端口。
• HTTPS协议需要到数字认证机构（Certificate Authority, CA）申请证书，一般需要一定的费用。
• HTTP 页面响应比HTTPS 快，主要因为 HTTP 使用 3 次握手建立连接，客户端和服务器需要握手 3 次，而 HTTPS 除了 TCP 的 3 次握手，还需要经历一个 SSL 协商过程。

2.HTTPS加密方式

HTTPS 采用对称加密和非对称加密相结合的方式，首先使用 SSL/TLS 协议进行加密传输，为了弥补非对称加密的缺点，HTTPS 采用证书来进一步加强非对称加密的安全性，通过非对称加密，客户端和服务端协商好之后进行通信传输的对称密钥，后续的所有信息都通过该对称秘钥进行加密解密，完成整个 HTTPS 的流程。

3.HTTP连接过程

域名解析——》发起TCP的三次握手——》TCP连接后发起http请求——》服务器响应http请求——》服务器处理后，返回数据给客户端

4.HTTPS连接过程

（1） 客户端发起https连接；
（2）服务端发送证书；
（3）客户端验证服务端发来的证书：

• 判断发布机构是否合法，过期，证书中网址与访问网址是否一致；
• 生成随机数（就是后面用的对称加密的私钥）；
• 生成握手信息， 用证书中的签名hash算法取握手信息的hash值，然后用生成的随机数将**[握手信息和握手信息的hash值]**进行加密，然后用证书中的公钥将随机数进行加密后，一起发送给服务端。其中计算握手信息的hash值，目的是为了保证传回到服务端的握手信息没有被篡改。

（4）服务端接收随机数加密的信息，并用私钥解密得到随机数，用随机数解密验证握手信息是否被篡改，若无误，同样使用随机字符串加密握手信息和握手信息hash值发回给到客户端；
（5）客户端验证服务端发送回来的握手信息，完成握手。
验证无误后，握手过程就完成了，从此服务端和客户端就开始用那串随机数进行对称加密通信了。

5.加密细节问题

对称加密：
有一个密钥，它可以加密一段信息，也可以对加密后的信息进行解密。（DES、3DES、AES）
非对称加密：
有两把密钥，通常一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。（RSA、DSA、ECC）

6.签名算法

数字签名是一个带有密钥的消息摘要算法，这个密钥包括了公钥和私钥，用于验证数据完整性、认证数据来源和抗否认，遵循OSI参考模型、私钥签名和公钥验证。

数字签名具有许多重要的应用，例如在电子政务活动中的电子公文、网上报税、网上投票，在电子商务活动中的电子订单、电子账单、电子收据、电子合同、电子现金等电子文档都需求经过数字签名来确保文档的真实性和有效性；甚至于人们日常运用频频的电子邮件，当触及重要内容时，也需求经过数字签名技能来对邮件的发送者进行确认和确保邮件内容未被篡改，并且邮件的发送者也不能对宣布的邮件进行否认。

三、用户输入网址到显示对应页面全过程

1.大体流程

（1）DNS解析
当用户输入一个网址并按下回车键的时候，浏览器获得一个域名，而在实际通信过程中，我们需要的是一个 IP 地址，因此我们需要先把域名转换成相应 IP 地址。

（2）TCP连接
浏览器通过 DNS 获取到 Web 服务器真正的 IP 地址后，便向 Web 服务器发起 TCP 连接请求，通过 TCP 三次握手建立好连接后，浏览器便可以将 HTTP 请求数据发送给服务器了。

（3）发送HTTP请求
浏览器向 Web 服务器发起一个 HTTP 请求，HTTP 协议是建立在 TCP 协议之上的应用层协议，其本质是在建立起的TCP连接中，按照HTTP协议标准发送一个索要网页的请求。cookies会随着请求发送给服务器。

（4）处理请求并返回
服务器获取到客户端的 HTTP 请求后，会根据 HTTP 请求中的内容来决定如何获取相应的文件，并将文件发送给浏览器。

（5）浏览器渲染
浏览器根据响应开始显示页面，首先解析 HTML 文件构建 DOM 树，然后解析 CSS 文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。

（6）断开连接
客户端和服务器通过四次挥手终止 TCP 连接。

2.DNS相关

（1）DNS解析查询方式

递归查询：如果主机所询问的本地域名服务器不知道被查询域名的 IP 地址，那么本地域名服务器就以 DNS 客户端的身份，向其他根域名服务器继续发出查询请求报文，即替主机继续查询，而不是让主机自己进行下一步查询。
迭代查询：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的 IP 地址，要么告诉本地服务器下一步应该找哪个域名服务器进行查询，然后让本地服务器进行后续的查询。

3.代理

正向代理
是一个位于客户端和目标服务器之间的服务器(代理服务器)，为了从目标服务器取得内容，客户端向代理服务器发送一个请求并指定目标，然后代理服务器向目标服务器转交请求并将获得的内容返回给客户端。
反向代理
反向代理隐藏了真实的服务端，以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

四、三次握手与四次挥手

1. 三次握手

（1）整体流程

三次握手是 TCP 连接的建立过程。在握手之前，主动打开连接的客户端结束 CLOSE 阶段，被动打开的服务器也结束 CLOSE 阶段，并进入 LISTEN 阶段。随后进入三次握手阶段：

（1）首先客户端向服务器发送一个 SYN 包，并等待服务器确认，其中：
标志位为 SYN，表示请求建立连接；
序号为 Seq = x（x 一般为 1）；
随后客户端进入 SYN-SENT 阶段。

（2）服务器接收到客户端发来的 SYN 包后，对该包进行确认后结束 LISTEN 阶段，并返回一段 TCP 报文，其中：
标志位为 SYN 和 ACK，表示确认客户端的报文 Seq 序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接；序号为 Seq = y；
确认号为 Ack = x + 1，表示收到客户端的序号 Seq 并将其值加 1 作为自己确认号 Ack 的值，随后服务器端进入 SYN-RECV 阶段。

（3）客户端接收到发送的 SYN + ACK 包后，明确了从客户端到服务器的数据传输是正常的，从而结束 SYN-SENT 阶段。并返回最后一段报文。其中：
标志位为 ACK，表示确认收到服务器端同意连接的信号；序号为 Seq = x + 1，表示收到服务器端的确认号 Ack，并将其值作为自己的序号值；
确认号为 Ack= y + 1，表示收到服务器端序号 seq，并将其值加 1 作为自己的确认号 Ack 的值。
随后客户端进入 ESTABLISHED。

当服务器端收到来自客户端确认收到服务器数据的报文后，得知从服务器到客户端的数据传输是正常的，从而结束 SYN-RECV 阶段，进入 ESTABLISHED 阶段，从而完成三次握手。

（2）如果三次握手的时候每次握手信息对方没收到怎么办

（1）若第一次握手服务器未接收到客户端请求建立连接的数据包时，服务器不会进行任何相应的动作，而客户端由于在一段时间内没有收到服务器发来的确认报文， 因此会等待一段时间后重新发送 SYN 同步报文，若仍然没有回应，则重复上述过程直到发送次数超过最大重传次数限制后，建立连接的系统调用会返回 -1。如果收到多个ACK+SYN，只接受发送的最后一个SYN对应的ACK+SYN，然后发送ACK回应。
（2）若第二次握手客户端未接收到服务器回应的 ACK 报文时，客户端会采取第一次握手失败时的动作，这里不再重复，而服务器端此时将阻塞在 accept() 系统调用处等待 client 再次发送 ACK 报文。
（3）若第三次握手服务器未接收到客户端发送过来的 ACK 报文，同样会采取类似于客户端的超时重传机制，若重传次数超过限制后仍然没有回应，则 accept() 系统调用返回 -1，服务器端连接建立失败。但此时客户端认为自己已经连接成功了，因此开始向服务器端发送数据，但是服务器端的 accept() 系统调用已返回，此时没有在监听状态。因此服务器端接收到来自客户端发送来的数据时会发送 RST 报文给 客户端，消除客户端单方面建立连接的状态。

（3）是否可以两次握手？

1.三次握手的主要目的是确认自己和对方的发送和接收都是正常的，从而保证了双方能够进行可靠通信。若采用两次握手，当第二次握手后就建立连接的话，此时客户端知道服务器能够正常接收到自己发送的数据，而服务器并不知道客户端是否能够收到自己发送的数据。

2.并且两次握手的话如果首次握手的报文超时客户端再重发之后，服务端接收到之前的那个报文也会直接建立连接，浪费资源。

（4）第二次握手的ACK和SYN

ACK是为了告诉客户端发来的数据接收无误；
SYN是为了建立并确认从服务器到用户端的通信。

2. 四次挥手

（1）整体流程

四次挥手即 TCP 连接的释放，这里假设客户端主动释放连接。在挥手之前主动释放连接的客户端结束 ESTABLISHED 阶段，随后开始四次挥手：

（1）首先客户端向服务器发送一段 TCP 报文表明其想要释放 TCP 连接，其中：
标记位为 FIN，表示请求释放连接；
序号为 Seq = u；
随后客户端进入 FIN-WAIT-1 阶段，即半关闭阶段，并且停止向服务端发送通信数据。

（2）服务器接收到客户端请求断开连接的 FIN 报文后，结束 ESTABLISHED 阶段，进入 CLOSE-WAIT 阶段并返回一段 TCP 报文，其中：
标记位为 ACK，表示接收到客户端释放连接的请求；序号为 Seq = v；
确认号为 Ack = u + 1，表示是在收到客户端报文的基础上，将其序号值加 1 作为本段报文确认号 Ack 的值；
随后服务器开始准备释放服务器端到客户端方向上的连接。
客户端收到服务器发送过来的 TCP 报文后，确认服务器已经收到了客户端连接释放的请求，随后客户端结束 FIN-WAIT-1 阶段，进入 FIN-WAIT-2 阶段。

（3）服务器端在发出 ACK 确认报文后，服务器端会将遗留的待传数据传送给客户端，待传输完成后即经过 CLOSE-WAIT 阶段，便做好了释放服务器端到客户端的连接准备，再次向客户端发出一段 TCP 报文，其中：
标记位为 FIN 和 ACK，表示已经准备好释放连接了；
序号为 Seq = w；
确认号 Ack = u + 1，表示是在收到客户端报文的基础上，将其序号 Seq 的值加 1 作为本段报文确认号 Ack 的值。
随后服务器端结束 CLOSE-WAIT 阶段，进入 LAST-ACK 阶段。并且停止向客户端发送数据。

（4）客户端收到从服务器发来的 TCP 报文，确认了服务器已经做好释放连接的准备，于是结束 FIN-WAIT-2 阶段，进入 TIME-WAIT 阶段，并向服务器发送一段报文，其中：
标记位为 ACK，表示接收到服务器准备好释放连接的信号；
序号为 Seq= u + 1，表示是在已收到服务器报文的基础上，将其确认号 Ack 值作为本段序号的值；
确认号为 Ack= w + 1，表示是在收到了服务器报文的基础上，将其序号 Seq 的值作为本段报文确认号的值。
随后客户端开始在 TIME-WAIT 阶段等待 2 MSL。
服务器端收到从客户端发出的 TCP 报文之后结束 LAST-ACK 阶段，进入 CLOSED 阶段。由此正式确认关闭服务器端到客户端方向上的连接。客户端等待完 2 MSL 之后，结束 TIME-WAIT 阶段，进入 CLOSED 阶段，由此完成「四次挥手」。

（2）为什么要四次挥手

是因为 FIN 释放连接报文和 ACK 确认接收报文是分别在两次握手中传输的。 当主动方在数据传送结束后发出连接释放的通知，由于被动方可能还有必要的数据要处理，所以会先返回 ACK 确认收到报文。当被动方也没有数据再发送的时候，则发出连接释放通知，对方确认后才完全关闭TCP连接。

（3）close-wait和time-wait

close-wait
在服务器收到客户端关闭连接的请求并告诉客户端自己已经成功收到了该请求之后，服务器进入了 CLOSE-WAIT 状态，该状态就是为了保证服务器在关闭连接之前将待发送的数据发送完成。
time-wait
第四次挥手后,客户端进入的状态,是客户端必要的等待时间,如果不存在这个步骤就会导致两个问题:
客户端立即关闭后,立即又用同样的端口握手并建立通信,此时上次的连接残留的数据包会被误认为是本次的,造成数据异常。
客户端直接关闭后,若客户端发送的ack包丢失，服务端会重新发送 fin 包,客户端就会回应 RST,会报异常,但是其实是正常关闭的。

（4）MSL？为什么等待2个MSL

MSL是指报文在网络中最大生存时间，等待2MSL是我们必须假象网络是不可靠的，为了让此次 TCP 连接中的所有报文在网络中消失。

虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，客户端发出的最后一个ACK可能会丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK后，Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

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

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

（6）有很多端口处于close_wait状态怎么办？

正常情况下，处于close_wait状态是已经收到了FIN但是还没发送自己的FIN的时候，在发送完剩余数据后应该会自动结束这个状态。
长时间处于这个状态，一般是由于客户端异常断开，服务端处理逻辑不大合适导致未断开连接。
导致的问题：用尽服务器端口，或者导致单进程打开文件句柄数达到上限，造成无法创建新的连接。
我们可以尝试修改代码或者修改close_wait默认最大持续时间。

五、TCP与UDP

1.TCP与UDP区别

UDP提供不可靠交付。在传输数据前不需要先建立连接，远程主机收到报文后，不需要给出任何确认。一般用于即时通信。 首部字节8个。

TCP提供可靠交付，面向连接的服务。在传输数据前必须先建立连接，传输结束后要释放连接，不提供广播或多播服务。用于文件传输，邮件传输。在数据传递过程中，有确认、窗口、重传和拥塞控制机制，增加了很多开销。首部字节20-60个。

2.TCP如何保证可靠传输

（1）序列号与确认应答

TCP传输时将每个数据块都进行了编号，这就是序列号。每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。

除了应答，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。

（2）校验和

TCP校验和是一个端到端的校验和，由发送端计算，然后由接收端验证。其目的是为了发现TCP首部和数据在发送端到接收端之间发生的任何改动。如果接收方检测到校验和有差错，则TCP段会被直接丢弃。

（3）超时重传

发送方在发送完数据后等待一个时间，时间到达没有接收到ACK报文，那么对刚才发送的数据进行重新发送。
note： 关于等待时间
在Linux中（BSD Unix和Windows下也是这样）超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。重发一次后，仍未响应，那么等待2500ms的时间后，再次重传。等待4500ms的时间继续重传。以一个指数的形式增长。累计到一定的重传次数，TCP就认为网络或者对端出现异常，强制关闭连接。

（4）ARQ协议

即自动重传请求，也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组，分为停止等待ARQ协议和连续ARQ协议，前者需要等待，影响效率，连续ARQ效率更高。

（5）连接管理

即三次握手与四次挥手。

（6）流量控制

而TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。

在TCP协议的报头信息当中，有一个16位字段的窗口大小。窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大，证明接收端接收缓冲区的剩余空间越大，网络的吞吐量越大。接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。

（7）拥塞控制

在实际的网络通信系统中，除了发送方和接收方外，还有路由器，交换机等复杂的网络传输线路，此时就需要拥塞控制。拥塞控制是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况。常用的解决方法有：慢启动和拥塞避免、快重传和快恢复。
慢启动与拥塞避免：
在开始发送数据时，先发送少量的数据探路。探清当前的网络状态如何，再决定多大的速度进行传输。这时候就引入一个叫做拥塞窗口的概念。发送刚开始定义拥塞窗口为 1，每次收到ACK应答，拥塞窗口加 1。在发送数据之前，首先将拥塞窗口与接收端反馈的窗口大小比对，取较小的值作为实际发送的窗口。
慢启动的拥塞窗口大小是指数增长的，达到阈值后变为避免拥塞算法，拥塞窗口改为线性增长，发生拥塞后调整阈值，重新开始慢启动。

快重传与快恢复：
有时候个别报文丢失不是因为网络拥塞，此时重新开始慢启动，影响传输效率。
快重传要求接收方在收到数据后立即发送确认，假如收到乱序报文段，要对收到的有序报文段进行重复确认（收到m2，发送确认m2，紧接着收到m4，m5，还是发送重复确认m2）。
发送方一旦收到三个连续重复确认，就要对相应丢失的报文进行重传（重传丢失的m3，接收方收到后返回），不等到超时。
快恢复即发送方收到三个重复确认后，将拥塞窗口和阈值的大小都调整为当前窗口大小的一半，执行拥塞避免算法，不从0开始。

4. 一台服务器最多支持多少TCP连接

一般用四元组来标识tcp连接[本地ip、本地port、远程ip、远程port]只要有一个要素不一样，就认为是一个不同的连接。
在本地ip和本地端口都固定的情况下，客户端ip和客户端端口可变，理论上可以建ip可能组合*端口可能组合个连接，大约两百多万亿。
llnux系统中一切皆文件，每个tcp连接都要占用一个文件句柄，系统允许创建连接数取决于句柄数上限，这个值可以修改到很大。
另一方面是内存的限制，一个空tcp连接消耗3K左右内存，若传输数据会增加内存消耗。
note：客户机tcp连接上限受端口限制，单ip客户端大约60000个左右。

六、POST与GET

get 提交的数据会放在 URL 之后，并且请求参数会被完整的保留在浏览器的记录里，由于参数直接暴露在 URL 中，可能会存在安全问题，因此往往用于获取资源信息。而 post 参数放在请求主体中，并且参数不会被保留，相比 get 方法，post 方法更安全，主要用于修改服务器上的资源。
get 请求只支持 URL 编码，post 请求支持多种编码格式。
get 只支持 ASCII 字符格式的参数，而 post 方法没有限制。
get 提交的数据大小有限制（这里所说的限制是针对浏览器而言的），而 post 方法提交的数据没限制
get 方式需要使用 Request.QueryString 来取得变量的值，而 post 方式通过 Request.Form 来获取。
get 方法产生一个 TCP 数据包，post 方法产生两个（并不是所有的浏览器中都产生两个）。
get在浏览器回退是无害的，post会再次提交请求。

七、session与cookie

1. 两者对比

相同点：都是用来保存用户状态的。

• Cookie 只能存储 ASCII 码字符串，而 Session 则可以存储任何类型的数据，因此在考虑数据复杂性时首选Session；
• Cookie 存储在浏览器中，容易被恶意查看。考虑安全性应该用session。
• 对于大型网站，如果用户所有的信息都存储在Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中。
• 单个cookie数据大小不能超过4K，cookie的数量也有限制。

2. 两者工作原理

cookie工作原理：
（1）浏览器端第一次发送请求到服务器端。

（2）服务器端创建Cookie，该Cookie中包含用户的信息，然后将该Cookie发送到浏览器端。

（3）浏览器收到响应后，生成cookie信息。当浏览器端再次访问服务器端时会携带服务器端创建的Cookie。

（4）服务器端通过Cookie中携带的数据区分不同的用户。
session工作原理：
（1）浏览器端第一次发送请求到服务器端，服务器端创建一个Session，同时会创建一个特殊的Cookie（name为JSESSIONID的固定值，value为session对象的ID），然后将该Cookie发送至浏览器端

（2）浏览器端发送第N（N>1）次请求到服务器端，浏览器端访问服务器端时就会携带该name为JSESSIONID的Cookie对象

（3）服务器端根据name为JSESSIONID的Cookie的value(sessionId)，去查询Session对象，从而区分不同用户。

2. 两者生命周期

session
服务器一般把session放到内存里，每个用户有一个独立的session。当我们第一次访问服务器，服务器会给我们自动创建一个session，生成session后只要用户继续访问，服务器就会更新session最后访问时间，并维护这个session。当越来越多的用户访问服务器，为了防止内存溢出，服务器会把长期没有活跃的session删除。这个时间叫session的超时时间，过了超时时间，session自动失效。
cookie
如果不设置过期时间，则cookie声明周期一般随着浏览器关闭而消失，这种cookie称为会话cookie；
如果设置了过期时间，浏览器会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍有效至超过设定的过期时间。

3. HTTP是不保存用户状态的协议，如何保存用户状态？

HTTP 是一种无状态协议。HTTP 协议自身不对请求和响应之间的通信状态进行保存。主要通过session和cookie机制来进行保存。
Session 的主要作用就是通过服务端记录用户的状态。
大部分情况下， 我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪Session。
note： cookie被禁用怎么办？
此时无法使用 Cookie 来保存用户信息，只能使用 Session。除此之外，不能再将 Session ID 存放到 Cookie 中，而是使用 URL 重写技术，将 Session ID 作为 URL 的参数进行传递。

4. 使用session维护用户登录状态的过程

• 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
• 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
• 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
• 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。

八、状态码

第一个数字定义了状态码的类型，后面两个起区分作用。
1开头：表示请求正在处理
2开头：表示请求被成功处理完毕；
3开头：重定向，要完成的请求需要进行附加操作；
4开头：客户端错误，请求有语法错误或者请求无法实现，服务器端无法处理请求；
5开头：服务器端错误
200：成功处理完毕；
301：永久重定向，重定向表示页面已永久移动到新位置，返回信息会包含新的 URI，浏览器会自动定向到新 URI。
302：临时重定向，重定向表示页面移动只是暂时的。
401：当前请求需要用户验证
404：请求的网址不存在；
500：服务器端未知错误，无法处理请求。
503：服务器停机维护或超负荷，暂时无法处理请求

九、URL组成

协议、域名、端口、虚拟目录、文件名、参数、锚点
协议：http、https
域名：可以是域名，可以是ip
端口：可以省略，采用默认端口。
虚拟目录：斜杠分隔，不是必须部分。
文件名部分：最后一个斜杠到参数前是文件名
参数部分：可以有多个参数，用&分隔。

十、WIFI、网桥、路由器、交换机

WIFI在数据链路层和物理层，网桥在数据链路层，交换机在数据链路层，路由器在网络层。

十一、HTTP1.0 1.1 2.0 3.0

1.HTTP1.0和1.1

长连接：
HTTP 1.0需要使用keep-alive参数来告知服务器端要建立一个长连接，而HTTP1.1默认支持长连接。
管道网络传输：
1.1支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
节约带宽：

• HTTP 1.1支持只发送header信息(不带任何body信息)，如果服务器认为客户端有权限请求服务器，则返回100，否则返回401。客户端如果接受到100，才开始把请求body发送到服务器；如果接收到401，客户端就可以不用发送请求body，节约了带宽。
• HTTP1.1还支持传送内容的一部分。这样当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础。

Host域
一个 ip 地址可以对应多个虚拟主机，每个虚拟主机对应一个 host，http 1.1 有 host 这个字段，支持在一台物理服务器上可以存在多个虚拟主机。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。
缓存策略和错误码
在HTTP1.0的基础上引入了更多的缓存控制策略和错误码。

2.HTTP1.1和2

多路复用：
HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，大幅度提高了连接的利用率。
头部数据压缩：
HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
服务器推送：
HTTP2引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源，不用再通过网络。
二进制格式：
HTTP2采用二进制分帧模式传输数据，提升了传输效率。

3.HTTP3

协议变更：
传输层协议替换为UDP，应用层协议为QUIC，它具有类似 TCP 的连接管理、拥塞窗口、流量控制的网络特性，相当于将不可靠传输的 UDP 协议变成“可靠”的了，所以不用担心数据包丢失的问题。
QUIC主要优点：
解决线头阻塞问题：2.0的传输过程中，一旦某个流丢包，会阻塞后面的数据流传输。QUIC会保证数据包的可靠性，某个流的数据包丢失，只会阻塞这一个流。
解决切换网络问题：2.0切换网络，由于IP变更，之前的连接会断开。利用QUIC协议没有采用四元组绑定连接，采用的是连接ID，可以让连接保持。

4.一个 TCP 连接可以对应几个 HTTP 请求？

如果维持连接（1.1），一个 TCP 连接是可以发送多个 HTTP 请求的。

5.一个 TCP 连接中 HTTP 请求发送可以一起发送么

HTTP2可以，1和1.1不可以。

6. 浏览器对同一 Host 建立 TCP 连接到数量有没有限制？

有。Chrome 最多允许对同一个 Host 建立六个 TCP 连接。不同的浏览器有一些区别。

参考资料
https://blog.csdn.net/qzcsu/article/details/72861891
https://blog.csdn.net/liuchenxia8/article/details/80428157
https://blog.csdn.net/jmq_0000/article/details/7299910