【面试题】计算机网络常见面试题

TCP的三次握手、四次挥手？

为了准确无误地把数据送达目标处，TCP 协议采用了三次握手策略。

• 一次握手：客户端发送带有 SYN 标志的数据包给服务端。

• 二次握手：服务端发送带有 SYN/ACK 标志的数据包给客户端。

• 三次握手：客户端发送带有带有 ACK 标志的数据包给服务端。

• SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以

• ACK(Acknowledgement）消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。

为什么要三次握手？两次行吗？

不行，三次握手的目的是建立可靠的通信信道

比如当第一次TCP连接请求因为网络中断延迟，会导致TCP客户端超时重发TCP请求，如果只有两次连接，那么当数据传输完毕断开连接的时候，第一次的TCP回复网络继续连接，服务端这时候就会回应客户端然后等待，但是这个时候客户端已经关闭了

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

接收端传回发送端所发送的 ACK 是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。而回传 SYN也就是同步序列编号则是为了建立并确认从服务端到客户端的通信

四次挥手

• 第一次挥手：客户端发送一个 FIN 数据包给服务端，用来告诉服务端，我要关闭与你的 TCP 连接。(客户端主动关闭到服务器的数据传输，但此时客户端还能接收服务端传来的数据)
• 服务端收到这个 FIN 数据包后，它返回一 个 ACK 数据包给客户端，确认序号为收到的序号加 1 （和 SYN 一样，一个 FIN 将占用一个序号），目的是告诉客户端，我收到了你的关闭连接请求。
• 服务端主动关闭到客户端的连接，并发送一个FIN 数据包给客户端，告诉客户端我也关闭了和你的 TCP 连接。(服务端不会再给客户端发送数据了)
• 客户端收到服务端返回的 FIN 数据包后，再发送一个 ACK 数据包给服务端确认，并将确认序号设置为收到序号加 1。

三次握手过程中可以携带数据吗？

第三次握手时可以携带数据，但是第一、二次不行。

原因：设想这样的场景，若第一次握手可以携带数据，有人要恶意攻击服务器，则他每次都可以在第一次握手中的SYN报文中放入大量数据，会让服务器花费很多时间、空间来处理报文。

也就是说：第一次握手无法放数据，保证了服务器的安全性。而第三次握手时，已经代表成功的建立了连接，从客户端携带数据到服务器也是被理解的。

三次握手连接阶段，最后一次ACK包丢失，会发生什么?

服务端:

• 第三次的ACK在网络中丢失，那么服务端该TCP连接的状态为SYN_RECV,并且会根据TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便客户端重新发送ACK包。

• 如果重发指定次数之后，仍然未收到客户端的ACK应答，那么一段时间后，服务端自动关闭这个连接。

客户端:

• 客户端认为这个连接已经建立，如果客户端向服务端发送数据，服务端将以RST包(Reset，标示复位，用于异常的关闭连接)响应。此时，客户端知道第三次握手失败。

为什么TCP连接的时候是3次，关闭的时候却是4次?

确保通信双方在互相都关闭通信连接之前，已经没有数据在双方之间继续传输了，使双方可以安全的关闭连接

• 关闭连接时，客户端向服务端发送FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
• 服务器收到客户端的FIN 报文时，先回一个ACK应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送FIN 报文给客户端来表示同意现在关闭连接。

从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的ACK 和FIN一般都会分开发送，从而比三次握手导致多了一次。

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

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

TIME_WAIT是客户端状态还是服务端状态？作用是什么？

TIME_WAIT是主动断开连接的一方会进入的状态，一般情况下，都是客户端所处的状态；服务器端一般设置不主动关闭连接。

• 第一，保证客户端发送的最后一个 ACK 报文能够到达服务器，由于这个 ACK 报文可能丢失，站在服务器的角度看来，我已经发送了 FIN+ACK 报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次而客户端就能在这个 2MSL 时间段内收到这个重传的报文，接着给出回应报文，并且会重启 2MSL 计时器。
• 第二，防止 “已经失效的连接请求报文段” 出现在本次请求中。客户端发送完最后一个确认报文后，在这个 2MSL 时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

TIME_WAIT状态过多会造成什么后果？怎样处理？

从服务器来讲，短时间内关闭了大量的Client连接，就会造成服务器上出现大量的TIME_WAIT连接，严重消耗着服务器的资源，此时部分客户端就会显示连接不上。

从客户端来讲，客户端TIME_WAIT过多，就会导致端口资源被占用，因为端口就65536个，被占满就会导致无法创建新的连接。

解决办法:

• 服务器可以设置SO_REUSEADDR套接字选项来避免TIME_WAIT状态，此套接字选项告诉内核，即使此端口正忙(处于

  TIME_WAIT状态)，也请继续并重用它。

• 调整系统内核参数，修改/etc/sysctl.conf文件，即修改net.ipv4.tcp_tw_reuse和tcp_timestamps

net.ipv4.tcp_tw_reuse==1表示开启重用。允许将TIME-WAITsockets重新用于新的TCP连接，默认为0，表示关闭;

net.ipv4.tcp_tw_recycle=1表示开启TCP连接中TIME-WAITsockets的快速回收，默认为0，表示关闭。

• 强制关闭，发送RST包越过TIME_WAIT状态，直接进入CLOSED状态。

TCP 滑动窗口和流量控制机制？

在进行数据传输时，如果传输的数据比较大，就需要拆分为多个数据包进行发送。TCP协议需要对数据进行确认后，才可以发送下一个数据包。这样一来，就会在等待确认应答包环节浪费时间。
为了避免这种情况，TCP引入了窗口概念。窗口大小指的是不需要等待确认应答包而可以继续发送数据包的最大值。

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

TCP 拥塞控制机制？

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

为了进行拥塞控制，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 通过以下几种措施来保证数据的可靠传输：

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

TCP/IP协议涉及哪几层架构？

1、应用层

是直接为应用进程提供服务的。对不同种类的应用程序它们会根据自己的需要来使用应用层的不同协议；定义数据格式并按照对应的格式解读数据，加密、解密、格式化数据；应用层可以建立或解除与其他节点的联系，这样可以充分节省网络资源。

2、运输层

作为TCP/IP协议的第二层，运输层在整个TCP/IP协议中起到了中流砥柱的功能。且在运输层中，TCP和UDP也同样起到了中流砥柱的作用。主要功能是定义端口，标识应用程序身份，实现端口到端口的通信，TCP协议可以保证数据传输的可靠性。

3、网络层

网络层在TCP/IP协议中的位于第三层。在TCP/IP协议中网络层可以进行网络连接的建立和终止以及IP地址的寻找等功能。网络层的主要功能是定义网络地址、区分网段、子网内MAC寻址、对于不同子网的数据包进行路由。

4、网络接口层

在TCP/IP协议中，网络接口层位于第四层。由于网络接口层兼并了物理层和数据链路层，所以网络接口层既是传输数据的物理媒介，也可以为网络层提供一条准确无误的线路。

TCP与UDP的区别？基于 TCP、UDP 的协议有哪些？

• TCP 提供面向连接的、可靠的数据流传输，而 UDP 提供的是无连接的、不可靠的数据流传输。
• TCP保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证。
• TCP 传输单位称为 TCP 报文段，UDP 传输单位称为用户数据报。
• TCP 注重数据安全性，UDP 数据传输快，因为不需要连接等待，少了许多操作，但是其安全性却一般。

面向连接与非面向连接区别？

• 面向连接的服务，通信双方在进行通信之前，要先在双方建立起一个完整的可以彼此沟通的通道，在通信过程中，整个连接的情况一直可以被实时地监控和管理。
• 非面向连接地服务，不需要预先建立一个联络两个通信节点地连接，需要通信地时候，发送节点就可以往网络上发送信息，让信息自主地在网络上去传，一般在传输地过程中不再加以监控。

基于 TCP、UDP 的协议有哪些？

基于 TCP 的协议：

• HTTP：Web服务器传输超文本到本地浏览器的传送协议。
• SMTP：邮件传送协议，用于发送邮件。服务器开放的是 25 号端口。
• FTP：定义了文件传输协议，使用21 端口。
• …

基于 UDP 的协议：

• DNS：用于域名解析服务，将域名地址转换为 IP 地址。DNS 用的是53号端口。
• …

TCP 与 UDP 的适用场景：

TCP：当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，HTTP、HTTPS、FTP等传输文件的协议会使用到。

UDP：当强调传输性能而不是传输的完整性时，要求网络通讯速度能尽量的快：如 QQ语音，QQ视频等。

SYN洪泛攻击？如何防范？

SYN洪泛攻击属于DOS攻击的一种，它利用TCP协议缺陷，通过发送大量的半连接请求，耗费CPU和内存资源。

原理：

• 在三次握手过程中，服务器发送**[SYN/ACK]包(第二个包)之后、收到客户端的[ACK]包(第三个包)之前的TCP连接称为半连接(half-open connect)，此时服务器处于SYN_RECV(等待客户端响应)状态。如果接收到客户端的[ACK]**，则TCP连接成功，如果未接受到，则会不断重发请求直至成功。

• SYN攻击的攻击者在短时间内伪造大量不存在的IP地址，向服务器不断地发送[SYN]包，服务器回复[SYN/ACK]包，并等待客户的确认。由于源地址是不存在的，服务器需要不断的重发直至超时。

• 这些伪造的[SYN]包将长时间占用未连接队列，影响了正常的SYN，导致目标系统运行缓慢、网络堵塞甚至系统瘫痪。

检测：当在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。

防范：

• 通过防火墙、路由器等过滤网关防护。

• 通过加固TCP/IP协议栈防范，如增加最大半连接数，缩短超时时间。

• SYN cookies技术。SYN Cookies是对TCP服务器端的三次握手做一些修改，专门用来防范SYN洪泛攻击的一种手段。

DDos攻击?

DDos全称Distributed Denial of Service，分布式拒绝服务攻击。最基本的DOS攻击过程如下:

1. 客户端向服务端发送请求链接数据包。

2. 服务端向客户端发送确认数据包。

3. 客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认

DDoS则是采用分布式的方法，通过在网络上占领多台“肉鸡”，用多台计算机发起攻击。

DOS攻击现在基本没啥作用了，因为服务器的性能都很好，而且是多台服务器共同作用，1V1的模式黑客无法占上风。对于DDOS攻击，预防方法有:

• 减少SYN timeout时间。在握手的第三步，服务器会等待30秒-120秒的时间，减少这个等待时间就能释放更多的资源。

• 限制同时打开的SYN半连接数目。

TCP 粘包?它的产生原因以及解决方法？

• TCP 粘包是指：发送方发送的若干个包数据到接收方接收时，粘成一个包数据。
• TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP 把这些数据块仅仅看成一连串无结构的字节流，没有边界，这就可能导致字节流合并（粘包）。

TCP 粘包产生的原因：

1.发送方产生的粘包

• 采用 TCP 协议传输数据的客户端与服务器经常是保持一个长连接的状态（一次连接发一次数据不存在粘包），双方在连接不断开的情况下，可以一直传输数据。但当发送的数据包过于的小时，那么 TCP 协议默认的会启用 Nagle 算法，将这些较小的数据包进行合并发送（缓冲区数据发送是一个堆压的过程）；这个合并过程就是在发送缓冲区中进行的，也就是说数据发送出来它已经是粘包的状态了。
• 总结：要发送的数据小于 TCP 发送缓冲区的大小，TCP 将多次写入缓冲区的数据一次发送出去，将会发生粘包。

2. 接受方产生的粘包

• 接收方采用 TCP 协议接收数据时的过程是这样的：数据到接收方，从网络模型的下方传递至传输层，传输层的 TCP 协议处理是将其放置接收缓冲区，然后由应用层来主动获取（例如C 语言用函数等）；这时会出现一个问题，就是我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来，而下一个数据又到来并有一部分放入的缓冲区末尾，等我们读取数据时就是一个粘包。（放数据的速度 > 应用层拿数据速度）。
• 总结：接收数据端的应用层没有及时读取缓冲区中的数据，导致缓冲区数据堆积，将发生粘包。

如何避免粘包？

避免粘包有以下两种方式：

• 在每个包的末尾加上特殊字符，用以区分连续的两个包。（例如加\r\n标记）
• 在报文首部添加包的长度。

HTTP常见的状态码有哪些?

常见状态码:

• 200：服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。

• 301：(永久移动)请求的网页已永久移动到新位置。服务器返回此响应(对GET或HEAD请求的响

  应)时，会自动将请求者转到新位置。

• 302：(临时移动)服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

• 400：客户端请求有语法错误，不能被服务器所理解。

• 403：服务器收到请求，但是拒绝提供服务。

• 404：(未找到)服务器找不到请求的网页。

• 500：(服务器内部错误)服务器遇到错误，无法完成请求。

状态码301和302的区别是什么?

共同点：301和302状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取(用户看到的效果就是他输入的地址A瞬间变成了另一个地址B)。

不同点：

• 301表示旧地址A的资源已经被永久地移除了(这个资源不可访问了)，搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；

• 302表示旧地址A的资源还在(仍然可以访问)，这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。SEO中302好于301。

重定向原因:

1. 网站调整(如改变网页目录结构):

2. 网页被移到一个新地址;

3. 网页扩展名改变(如应用需要把.php改成.Html或.shtml)。

GET 和 POST 的区别？

使用上的区别:

• GET使用URL或Cookie传参，而POST将数据放在BODY中，这个是因为HTTP协议用法的约定。

• GET方式提交的数据有长度限制，则POST的数据则可以非常大，这个是因为它们使用的操作系统和浏览器设置的不同引起的区别。

• POST比GET安全，因为数据在地址栏上不可见，这个说法没毛病，但依然不是GET和POST本身的区别。在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。GET方法是安全的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的。POST因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的

• 是否可缓存：GET 请求是可以缓存的，POST 请求不可以缓存。

• 数据包个数：GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。

本质区别

GET和POST最大的区别主要是GET请求是幂等性的，POST请求不是。这个是它们本质区别。

幂等性是指一次和多次请求某一个资源应该具有同样的副作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。

HTTP协议？

HTTP的概念：

• HTTP 是超文本传输协议，用于客户端和服务器端之间的通信，即在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。

HTTP 的特性(优点)：

• HTTP 最凸出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」。

HTTP的常见字段：

1. Host 字段

• 客户端发送请求时，用来指定服务器的域名。Host: www.A.com有了 Host 字段，就可以将请求发往「同一台」服务器上的不同网站。

2. Content-Length 字段

• 服务器在返回数据时，会有 Content-Length 字段，表明本次响应的数据长度。Content-Length: 1000

3. Connection 字段

• Connection 字段最常用于客户端要求服务器使用 TCP 持久连接，以便其他请求复用。Connection: keep-aliveHTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。一个可以复用的 TCP 连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段。

4. Content-Type 字段

• Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。Content-Type: text/html; charset=utf-8类型表明，发送的是网页，而且编码是UTF-8。客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。Accept: */* :客户端声明自己可以接受任何格式的数据。

5. Content-Encoding 字段

• Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式。Content-Encoding: gzip表示服务器返回的数据采用了 gzip 方式压缩，告知客户端需要用此方式解压。客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。Accept-Encoding: gzip, deflate

HTTP 的优缺点？

HTTP 协议的特性「无状态、明文传输」既是优点也是缺点，同时还有一大缺点「不安全」。

无状态协议的优缺点

• 无状态的好处：服务器不用去记忆 HTTP 的状态，不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存资源用在对外提供服务上。

• 无状态的坏处：服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。

  • 例如登录 -> 添加购物车 -> 下单 -> 结算 -> 支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要确认一遍用户身份信息。

对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。

Cookie 通过在请求和响应中写入 Cookie 信息来控制客户端的状态。相当于，在客户端第一次请求后，服务器会下发一个带有客户身份信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能试别了：

明文传输的优缺点：

• 明文意味着在传输过程中的信息，是可方便阅读的，通过浏览器的 F12 控制台或 Wireshark 抓包都可以直接肉眼查看，为我们调试工作带了极大的便利性。
• 但是这正是这样，HTTP 的所有信息都暴露在了光天化日下，相当于信息裸奔。在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就能被窃取，如果里面有你的账号密码信息，那你号没了。

HTTP长、短连接?

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

但从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码:Connection:keep-alive

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

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

HTTP 1.0 、 HTTP 1.1 、HTTP 2.0 的主要区别是什么？

• HTTP 1.0：默认使用短连接，浏览器每次请求都需要与服务器建立一次 TCP 连接，服务器处理完成后立即断开 TCP 连接（无连接），服务端不记录客户端的请求状态（无状态）。

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

  // Keep-Alive不会永久保持连接，它有一个持续时间，可以在不同的服务器软件中设定这个时间。
  // 实现长连接需要客户端和服务端都支持长连接。
  Connection:keep-alive
  123
  

  在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。

• HTTP 2.0：引入二进制数据帧和流的概念，支持多路复用、服务器推送，支持使用二进制格式传输数据，而 HTTP 1.0 依然使用文本格式传输。

HTTP 和 HTTPS 的区别？

HTTPS 是如何建立连接的？

HTTPS 是在 HTTP 与 TCP 之间加了一层 SSL/TLS 协议 ，所以建里连接流程如下：

① 首先建立 TCP 连接：三次握手。

② 然后建里 SSL/TLS 加密：

SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行对称加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是握手阶段。

③ 发送HTTP 请求。

Https的原理？

加密流程按图中的序号分为:

1. 客户端发起HTTPS请求，客户端请求HTTPS网址，然后连接到server的443端口(HTTPS默认端口，类似于HTTP的80端口)。

2. 服务端的配置，采用HTTPS协议的服务器必须要有一套数字CA(Certification Authority)证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被篡改。

3. 传送证书，服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等。

4. 客户端解析证书，客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

   如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码KEY，并使用公钥A将其加密。

5. 传送加密信息，客户端把加密后的随机码KEY发送给服务器，作为后面对称加密的密钥。

6. 服务段解密信息，服务器在收到随机码KEY之后会使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了。

7. 传输加密后的信息，服务器使用密钥(随机码KEY)对数据进行对称加密并发送给客户端，客户端解密信息，客户端使用相同的密钥(随机码KEY)解密数据。

8. 双方使用对称加密愉快地传输所有数据。

9. 总结一下：

• 在使用HTTPS是需要保证服务端配置正确了对应的安全证书
• 客户端发送请求到服务端
• 服务端返回公钥和证书到客户端
• 客户端接收后会验证证书的安全性，如果通过则会随机生成一个随机数，用公钥对其加密，发送到服务端
• 服务端接受到这个加密后的随机数后会用私钥对其解密得到真正的随机数，随后用这个随机数当做私钥对需要发送的数据进行对称加密
• 客户端在接收到加密后的数据使用私钥(即生成的随机值)对数据进行解密并且解析数据呈现结果给客户
• SSL加密建立完成

对称加密算法和非对称加密算法？

• 对称加密算法：双方持有相同的密钥，进行加密速度快，典型对称加密算法：DES、AES。
• 非对称加密算法：密钥成对出现（私钥、公钥），私钥只有自己知道，不在网络中传输；而公钥可以公开。相比对称加密速度较慢，典型的非对称加密算法有：RSA、DSA。

HTTPS摘要算法？

摘要算法：实现数据完整性，能够为数据生成独一无二的指纹，指纹用于校验数据的完整性，解决了被篡改的风险。

作用：防止数据被篡改。

过程
1、客户端发送明文前，会通过摘要算法算出明文的指纹，发送时明文和指纹一同加密，发送给服务器。

2、服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的指纹和当前指纹做比较，若相同，则说明数据是完整的。

URI 和 URL 的区别?

• URI是统一资源标志符，可以唯一标识一个资源。
• URL是统一资源定位符，可以提供该资源的路径。URL 是 URI 的一个子集，它不仅唯一标识资源，而且还提供了定位该资源的信息。

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

浏览器中输入URL 地址，回车后经历了那些过程？

DNS 域名解析、TCP 连接、发送 HTTP 请求、服务器处理请求并返回 HTTP 报文、浏览器渲染、结束。

1. DNS 域名解析

当我们在浏览器中输入一个域名然后回车时，检查本机的C:\Windows\System32\drivers\etc\hosts配置文件下有没有这个域名映射，如下所示：

有：直接返回对应的ip地址，这个地址中，有我们需要访问的web程序，可以直接访问

没有：去DNS服务器找，找到的话就返回，找不到就返回找不到；

2. 建立 TCP 连接：三次握手

• 解析出 IP 地址后，浏览器根据 IP 地址和默认端口 443 向网站的服务器发起请求，三次握手，建立 TCP 连接。

3. 发送 HTTP 请求

• 建立好 TCP 连接后，浏览器 (客户端) 通过 HTTP 协议发送请求，请求从服务器端获取数据。
• 服务器处理客户端的 HTTP 请求后，就将请求的数据返回给浏览器。

4. 关闭 TCP 连接：四次挥手

• 浏览器与服务器数据传送完毕后，四次握手，释放 TCP 连接。

5. 浏览器回显

• 浏览器对数据进行解析并渲染显示。

整个过程会使用哪些协议？

1. 首先浏览器查找域名的IP地址的过程会使用DNS协议
2. 与服务器建立TCP连接使用到了TCP协议
3. 建立TCP协议时，需要发送数据，发送数据在网络层使用IP协议
4. IP数据包在路由器之间，路由选择使用OPSF协议
5. 路由器在与服务器通信时，需要将ip地址转换为MAC地址，需要使用ARP协议
6. 在TCP建立完成后，使用HTTP协议访问网页

Cookie 的作用？和 Session 有什么区别?

Cookie 和 Session 的作用：

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但两者有所区别：

• Cookie 一般用来保存用户信息。比如我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；
• Session 的主要作用就是通过服务端记录用户的状态典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 和 Session 的区别如下：

• 作用范围不同，Cookie 数据保存在客户端，Session 数据保存在服务器端。相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。
• 存取方式的不同，Cookie只能保存ASCIl，Session可以存任意数据类型，一般情况下我们可以在Session中保持一些常用变量信息，比如说Userld等。Cookie ⼀般⽤来保存⽤户信息，Session 的主要作用就是通过服务端记录用户的状态。
• 有效期不同，Cookie可设置为长时间保持，比如我们经常使用的默认登录功能，Session一般失效时间较短，客户端关闭或者Session超时都会失效。
• 隐私策略不同，Cookie存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在Cookie 中导致信息被窃取;Session存储在服务端，安全性相对Cookie要好一些。
• 存储大小不同，单个Cookie 保存的数据不能超过4K，Session可存储数据远高于Cookie.

如何考虑分布式Session问题?

在互联网公司为了可以支撑更大的流量，后端往往需要多台服务器共同来支撑前端用户请求，那如果用户在A服务器登录了，第二次请求跑到服务B就会出现登录失效问题。

分布式Session一般会有以下几种解决方案:

• 客户端存储：直接将信息存储在cookie中，cookie是存储在客户端上的一小段数据，客户端通过http协议和服务器进行cookie交互，通常用来存储一些不敏感信息

• Nginx ip_hash策略：服务端使用Nginx代理，每个请求按访问IP的hash分配，这样来自同一IP固定访问一个后台服务器，避免了在服务器A创建Session，第二次分发到服务器B的现象。

• Session复制：任何一个服务器上的Session发生改变(增删改)，该节点会把这个Session的所有内容序列化，然后广播给所有其它节点。

• 共享Session：服务端无状态话，将用户的Session等信息使用缓存中间件(如Redis来统一管理，保障分发到每一个服务器的响应结果都一致。

建议采用共享Session的方案。

参考
https://csp1999.blog.csdn.net/article/details/117506872
https://blog.csdn.net/qq_45966440/article/details/121389301
https://blog.csdn.net/qq_42651904/article/details/91355804