面试：计算机网络

TCP协议

TCP协议介绍

TCP（传输控制协议，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议。以下是TCP协议的详细说明，采用分点表示和归纳：

1. 协议概述
   • TCP由IETF的RFC 793定义，旨在适应支持多网络应用的分层协议层次结构。
   • TCP是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。
2. 主要特点
   • 面向连接：TCP通信之前需要先建立连接，数据传输完成后必须释放连接。
   • 可靠传输：通过序列号、确认应答（ACK）、重发机制等确保数据的无差错、不丢失、不重复、按序到达。
   • 全双工通信：TCP连接的两端都设有发送缓存和接收缓存，允许双方在任何时候都能发送数据。
   • 面向字节流：TCP把应用程序交下来的数据看成是一连串的无结构的字节流。
3. 工作原理
   • 建立连接：通过三次握手过程建立连接，包括SYN（同步）和ACK（确认）包。
   • 数据传输：数据被分割成多个TCP段（通常不超过1460数据字节），每个段包含序列号、确认号等信息，并通过IP层进行传输。
   • 可靠传输：使用序列号确保数据的顺序性，通过ACK和重发机制确保数据的完整性。
   • 流量控制：通过滑动窗口机制控制发送方和接收方的数据传输速率，防止接收方缓冲区溢出。
   • 拥塞控制：根据网络状况调整发送速率，防止网络拥塞。
   • 连接释放：通过四次挥手过程释放连接，包括FIN（结束）和ACK包。
4. 报文格式
   • TCP报文包括源端口号、目的端口号、序列号、确认号、数据偏移、保留字段、标志位（如SYN、ACK、FIN等）、窗口大小、校验和、紧急指针等字段。
5. 应用场景
   • TCP适用于需要可靠传输和顺序控制的应用场景，如文件传输、邮件服务、网页浏览等。
6. 与其他协议的关系
   • TCP是TCP/IP协议族中传输层的主要协议之一，与IP协议协同工作，确保数据在网络中的可靠传输。

总之，TCP协议通过其独特的工作机制和报文格式，在网络通信中扮演着至关重要的角色，为各种应用提供了可靠的数据传输服务。

三次握手

三次握手的过程，以及为什么是三次，而不是四次，两次？

补充：面试官，不要再问我三次握手和四次挥手

（一）三次握手的过程如下： 1、客户端向服务器发送SYN报文、初始化序列号ISN（seq=x），然后客户端进入SYN_SEND状态，等待服务器确认。 2、服务端发送ACK确认服务端的SYN报文（ack=x+1），同时发出一个SYN报文，带上自己的初始化序列号（seq=y），然后服务端进入SYN_RECV状态。 3、客户端接收到服务端的SYN、ACK报文，ACK确认服务端的SYNC报文（ACK=y+1），然后客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。 （二）为什么不是四次握手？ 因为传输效率不够高。 （三）为什么不能两次握手？ 两次握手无法让通信双方数据原点的序列号一致，不能保证数据可靠传输。

四次挥手

四次挥手的过程，以及为什么是四次？

（一）四次挥手的过程：

1、客户端发送一个FIN报文给服务端，表示自己要断开数据传送，报文中会指定一个序列号 (seg=x)。然后，客户端进入FIN-WAIT-1 状态。

2、服务端收到FIN报文后，回复ACK报文给客户端，且把客户端的序列号值+1，作为ACK报文的序列号(seq=x+1)。然后，服务端进入CLOSE-WAIT状态，客户端进入FIN-WAIT-2状态。

3、服务端也要断开连接时，发送 FIN 报文给客户端，且指定一个序列号(seq=y+1)，随后服务端进入LAST-ACK状态。

4、客户端收到FIN报文后，发出ACK报文进行应答，并把服务端的序列号值+1作为ACK报文序列号(seq=y+2)。此时客户端进入TIME-WAIT状态。服务端在收到客户端的ACK 报文后进入CLOSE 状态。如果客户端等待2MSL没有收到回复，才关闭连接。

（二）为什么是四次挥手？

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

总结：两次握手可以释放一端到另一端的 TCP 连接，完全释放连接一共需要四次握手。

TCP粘包

TCP粘包（Packet Sticking）是指在TCP网络通信中，发送方发送的若干个小数据包（通常称为TCP段或TCP报文段）在接收方被错误地粘合成一个大数据包的现象。这通常发生在连续的send操作中，多个数据包可能会被合并成一个大的数据包一起发送，导致接收方在接收时无法正确地区分这些数据包。

以下是关于TCP粘包问题的详细说明：

产生原因

1. 发送方原因：
   • TCP默认使用Nagle算法，该算法的主要作用是减少网络中报文段的数量。Nagle算法会收集多个小分组，并在一个确认到来时一起发送，这可能导致发送方出现粘包问题。
   • 应用程序写入数据的速度快于发送数据的速度，这种情况下多次写入的小数据包可能会打包在一起发送。
2. 接收方原因：
   • TCP接收到数据包时，并不会马上交到应用层进行处理。如果接收方缓冲区大小设置不合理，可能会导致多个小数据包粘在一起传输，形成一个大数据包发送。
3. 协议特性：
   • TCP是流式协议，无法识别消息边界。当多个应用程序利用相同的TCP连接并发发送数据时，这些数据包有可能在接收端粘连在一起，形成一个数据包。

处理方法

1. 定长发送法：
   • 发送端在发送数据时都以固定长度（LEN）进行分包。接收方都以固定的LEN进行接收，从而实现数据的完整接收。
   • 此方法适用于发送数据包长度较为稳定（趋于某一固定值）的情况。
2. 尾部标记序列法：
   • 在每个要发送的数据包的尾部设置一个特殊的字节序列作为标记，用来标示这个数据包的末尾。
   • 接收方可对接收的数据进行分析，通过尾部序列确认数据包的边界。
3. 头部标记分步接收法：
   • 定义一个用户报头，在报头中注明每次发送的数据包大小。
   • 接收方根据报头信息，逐步接收数据包直到达到指定大小。

TCP的可靠性

TCP连接如何确保可靠性

TCP连接确保可靠性的主要机制可以简要归纳为以下几点：

1. 连接建立和维护：TCP使用三次握手来建立连接，确保通信双方都能收到对方的消息并进行确认。
2. 序列号和确认：TCP给每个发送的数据包分配一个序列号，接收方收到数据后会发送确认（ACK），并包含期望接收的下一个数据包的序列号。
3. 超时和重传：TCP设置一个定时器来监视发送数据的确认情况。如果在一定时间内没有收到确认，会触发重传机制。
4. 流量控制：使用滑动窗口机制，接收方通过通告窗口大小来告知发送方自己的接收能力，发送方根据这个信息来控制发送数据的速率。
5. 拥塞控制：TCP使用拥塞窗口来控制数据的发送速率，以避免网络拥塞。当网络出现拥塞时，TCP会减小拥塞窗口的大小，以减少发送数据的速率。
6. 错误检测和校验：每个TCP数据包都包含一个校验和字段，用于检查数据包在传输过程中是否损坏。如果损坏，接收方会要求发送方重传数据。

流量控制

TCP的流量控制主要通过滑动窗口机制来实现，以确保发送方的发送速度不会超出接收方的处理能力。以下是TCP流量控制的详细实现过程：

1. 滑动窗口机制：
   • TCP通过滑动窗口机制来控制数据的发送和接收。滑动窗口是一个可以动态调整的窗口，用于指示发送方可以发送的数据量范围。
   • 接收方会告诉发送方自己的接收窗口大小（rwnd），该窗口大小基于接收方的接收缓存大小。发送方在发送数据时，其发送窗口的大小会受到接收窗口大小的限制。
2. 接收方窗口（rwnd）：
   • 接收方在确认报文段中包含一个窗口字段，用于通知发送方当前的接收窗口大小（rwnd）。这个窗口大小是动态变化的，根据接收方缓存的使用情况来调整。
   • 当接收方的receiver buffer已满时，接收窗口（rwnd）将减小到零，此时发送方会暂停发送数据，直到接收方重新给出一个非零的窗口值。
3. 发送窗口：
   • 发送方的发送窗口大小取决于接收窗口（rwnd）和拥塞窗口（cwnd）中较小的值。拥塞窗口用于控制网络拥塞，而接收窗口则用于流量控制。
   • 当发送方发送数据时，它只会发送落在发送窗口内的数据。如果发送窗口的大小小于接收窗口，那么发送方会受到发送窗口的限制。
4. 流量控制过程：
   • 在TCP连接建立时，接收方会向发送方发送一个初始的接收窗口大小（rwnd）。
   • 发送方根据接收窗口大小发送数据，并在发送每个数据包后等待接收方的确认。
   • 接收方在收到数据包后会回发一个确认报文段，其中包含当前的接收窗口大小（rwnd）。
   • 如果接收窗口大小减小到零，发送方将暂停发送数据，直到接收方重新给出一个非零的窗口值。
   • 为了处理接收窗口为零的情况，TCP使用了持续计时器（也叫坚持定时器）。当发送方收到零窗口通知时，它会启动这个计时器。如果计时器到期而窗口仍然为零，发送方会发送一个探测报文段来询问接收方是否可以开始发送数据。
5. 特殊情况处理：
   • 如果接收窗口在减小后又迅速增加（例如，接收缓存中的空间被释放），发送方可能会遇到“糊涂窗口综合症”。为了避免这种情况，TCP采取了一些策略，如Nagle算法和延迟确认等。

综上所述，TCP的流量控制是通过滑动窗口机制、接收窗口（rwnd）、发送窗口以及持续计时器等机制共同实现的。这些机制确保了发送方的发送速度不会超过接收方的处理能力，从而避免了数据的丢失和重传。

拥塞控制

TCP拥塞控制是怎么实现的

TCP拥塞控制是通过一系列算法和机制来避免和减轻网络拥塞的。以下是TCP拥塞控制的主要实现方式，结合文章中的相关数字和信息进行分点表示和归纳：

1. 慢启动（Slow Start）

   • 慢启动是TCP拥塞控制的初始阶段，用于探测网络的可用带宽。
   • 初始时，TCP将拥塞窗口（cwnd）设置为一个较小的值（如1、2、4或10个MSS，MSS为最大报文段大小）。
   • 每收到一个ACK确认报文，cwnd就会增加（如每RTT时间加倍），但增长的速度受到慢启动阈值（ssthresh）的限制。

2. 拥塞避免（Congestion Avoidance）

   • 当cwnd达到ssthresh时，TCP进入拥塞避免阶段。
   • 在拥塞避免阶段，cwnd的增长速度减缓，改为线性增长，即每个RTT时间增加一个MSS。
   • 这种增长方式有助于防止cwnd过快增长而导致的网络拥塞。

3. 慢启动阈值（ssthresh）的调整

   • 当网络发生拥塞时（如重传计时器超时或收到三个重复确认），TCP会降低ssthresh的值，通常为当前cwnd的一半。
   • 同时，cwnd会重置为1个MSS，并重新进入慢启动阶段。
   • 通过这种方式，TCP能够快速地适应网络条件的变化，并降低数据发送速率以减轻拥塞。

4. 快速重传（Fast Retransmit）和快速恢复（Fast Recovery）

   • 快速重传和快速恢复是TCP针对单个数据包丢失的快速恢复机制。
   • 当TCP收到三个重复的ACK确认时，它认为数据包已丢失，并立即重传该数据包，而不是等待重传计时器超时。
   • 在快速恢复阶段，cwnd不会降低到1个MSS，而是根据一定的算法进行调整，以加速数据的恢复和传输。

   总结：TCP拥塞控制通过慢启动、拥塞避免、快速重传和快速恢复等机制来避免和减轻网络拥塞。这些机制根据网络条件动态调整cwnd和ssthresh的值，以确保数据的可靠传输和网络的高效利用。



SYN攻击

什么是SYN攻击？如何避免？

攻击者发送大量伪造的SYN请求到目标服务器，但不完成后续的握手过程，从而让服务器一直等待确认，消耗服务器的资源（如半连接队列和系统资源），当半连接队列满了之后，后续再收到SYN报文就会丢弃，导致无法与客户端之间建立连接。

1.使用防火墙：网络边界部署防火墙，可以识别和过滤掉来自恶意IP地址的SYN攻击流量。

2.启用TCPSYNCookie：利用算法，通过对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS(最大报文段大小)、时间等，在收到对方的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（SequenceNumber-1）相同，从而决定是否分配TCB资源。

3.增大半连接队列：修改TCP的内核参数，增大全连接队列大小

4.无效连接监视释放：不停监视系统的半开连接和不活动连接，当达到一定阈值时拆除这些连接，从而释放系统资源。

5.限制并发连接数：配置服务器上的操作系统或应用程序，以限制每个IP地址或来源的并发连接数。

UDP协议

UDP协议介绍

UDP（用户数据报协议，User Datagram Protocol）是一种在计算机网络中广泛使用的传输层协议。以下是对UDP协议的详细说明，采用分点表示和归纳的方式，同时尽量多地参考了文章中的相关数字和信息：

一、概述

• UDP是工作在OSI（开放系统互连）模型中传输层的协议。
• 它使用IP作为底层协议，为应用程序提供一种以最少的协议机制向其他程序发送消息的协议。
• UDP协议的主要特点是无连接、不保证可靠传输和面向报文。

二、特点

1. 无连接：
   • UDP在发送数据前不进行连接，发送结束时也没有连接可以释放，减少了开销和发送数据之前的时延。
   • 这使得UDP协议在需要高速传输但数据完整性不那么重要的应用场景中表现优秀。
2. 不保证可靠传输：
   • UDP不保证数据包按顺序、无丢失、无重复地到达目的地。
   • 主机不维持复杂的连接状态，因此UDP是“尽最大努力交付”的协议。
3. 面向报文：
   • UDP发送方的数据报文，在添加首部后就直接交付给IP层，既不合并也不拆分，保留报文的边界。
   • 接收方的UDP在去除首部后，将报文原封不动地交付给上层应用进程。
4. 报文格式：
   • UDP报文由首部和数据部分组成。
   • 首部包含8个字节，由源端口（2字节）、目的端口（2字节）、长度（2字节）和校验和（2字节）四个字段组成。
5. 开销小：
   • UDP协议头部只包含8字节，相对于TCP的20字节信息包而言，UDP的额外开销很小。
   • 这使得UDP协议在处理大量小数据包时更加高效。
6. 广播和多播支持：
   • UDP可以基于广播和多播方式传输数据，对于向多个客户端广播同一消息的应用场景，UDP协议是一种很好的选择。

三、应用场景

• UDP协议适用于需要高速传输但数据完整性不那么重要的应用场景，如：
  • 视频和音频流传输：UDP速度快，支持高清画质和高质量音频传输，常被用于视频会议、实时直播等。
  • 游戏通信：游戏通信需要快速的反应速度和高性能，UDP可以快速地处理海量数据包，并且没有TCP的握手和断开连接过程的开销。
  • DNS解析：DNS是基于UDP协议的应用，UDP可以在网络出现问题时快速检查DNS错误。

TCP与UDP的区别

TCP（传输控制协议，Transmission Control Protocol）与UDP（用户数据报协议，User Datagram Protocol）在多个方面存在显著的区别。以下是TCP与UDP之间的详细区别，按照分点表示和归纳的方式进行说明：

一、面向连接与无连接

• TCP：面向连接的协议。在通信之前，需要通过三次握手建立连接，并在数据传输完成后通过四次挥手释放连接。这种连接机制确保了数据传输的可靠性和顺序性。
• UDP：无连接的协议。在发送数据前不进行连接，发送结束时也没有连接可以释放。这减少了开销和发送数据之前的时延，但可能导致数据包的丢失、乱序等问题。

二、可靠性与不可靠性

• TCP：提供可靠的数据传输服务。通过重传、确认和流量控制等机制确保数据的可靠传输。TCP还使用滑动窗口和确认机制来保证数据的顺序性和完整性。
• UDP：不保证可靠传输。数据被封装成数据报直接发送，不提供可靠性保证。因此，UDP适用于对实时性要求较高、丢失部分数据可容忍的应用场景，如音视频流媒体。

三、传输效率

• TCP：由于引入了重传、确认等机制，传输效率相对较低，但保证了数据的可靠传输。TCP在传输过程中会引入较大的传输延迟和额外的开销。
• UDP：无可靠性保证，数据传输更快。UDP协议头部只包含8字节，相对于TCP的20字节信息包而言，UDP的额外开销更小。这使得UDP协议在处理大量小数据包时更加高效。

四、连接性与应用场景

• TCP：面向连接的协议，适用于需要确保数据完整性和顺序的应用场景。例如，文件传输和下载、邮件传输、网页浏览等需要确保数据顺序和完整性的应用。
• UDP：无连接的协议，适用于需要快速传输和广播的应用场景。例如，实时音视频流媒体、DNS域名解析、实时游戏和多人在线游戏等。

五、其他比较要点

• 协议复杂性：TCP协议相对复杂，需要维护连接状态和处理各种机制。而UDP较为简单，传输开销较小。
• 拥塞控制：TCP在网络拥塞时会自适应降低传输速率，而UDP不具备拥塞控制机制。
• 传输方式：TCP支持点对点传输和多播传输，而UDP支持点对点、多播和广播传输。

总结：TCP和UDP是两种不同的传输层协议，每种协议在可靠性、传输效率、连接性和适用场景等方面有着不同的特点。选择TCP还是UDP需要根据具体应用的需求来决定。TCP适用于对可靠性和顺序性要求较高的应用，如文件传输和网页浏览；而UDP适用于对实时性要求较高、丢失部分数据可容忍的应用，如音视频流媒体和实时游戏。

HTTP协议

介绍

HTTP协议（Hypertext Transfer Protocol）是用于在计算机网络上传输超文本数据的应用层协议，特别是在万维网（WWW）上。以下是关于HTTP协议的详细说明：

一、基本概念

• 定义：HTTP是一个简单的请求-响应协议，运行在TCP之上，用于指定客户端发送给服务器的消息以及服务器返回的响应。
• 作用：HTTP是万维网数据通信的基础，支持多媒体传输，包括HTML、XML、JSON、图片、音频、视频等。
• 架构：HTTP基于B/S（浏览器/服务器）架构进行通信。

二、主要特点

1. 无状态：HTTP协议不会保存客户端与服务器之间的历史记录，每个请求都是独立的。
2. 基于请求-响应模式：客户端向服务器发送请求，服务器返回响应。
3. 基于文本传输：HTTP协议使用ASCII码作为通信协议，每个请求和响应都是一条文本消息。
4. 无连接：每个请求都是独立的，服务器处理请求后立即关闭连接。

三、请求与响应

1. 请求
   • 请求行：包括请求方法（如GET、POST、PUT、DELETE等）、请求URL和HTTP协议版本信息。
   • 请求头部：包含多行键值对，如Host、User-Agent、Accept、Content-Type等。
   • 请求主体：可选部分，用于在POST请求中向服务器传送数据。
2. 响应
   • 状态行：包括HTTP协议版本、状态码和状态描述。
   • 响应头部：与请求头部类似，包含多行键值对，如Content-Type、Content-Length、Set-Cookie等。
   • 响应主体：服务器返回给客户端的数据。

四、HTTP方法

HTTP定义了多种请求方法，每种方法执行特定的操作：

• GET：从服务器检索信息。
• POST：将数据发送到服务器以创建或更新资源。
• HEAD：与GET相同，但只返回响应头，不返回实际内容。
• PUT：将数据发送到服务器以创建或更新资源，如果资源已存在，则替换其内容。
• DELETE：删除指定资源。

五、HTTP状态码

HTTP状态码是用于表示服务器对请求的处理结果的3位数字代码。常见的状态码有：

• 200 OK：请求成功。
• 404 Not Found：请求的资源未找到。
• 500 Internal Server Error：服务器内部错误。

六、版本演进

HTTP协议有多个版本，其中最重要的是HTTP/1.0和HTTP/1.1。HTTP/0.9是最早的版本，仅支持GET请求和纯文本响应，没有定义请求头和响应头。随着HTTP/1.0和HTTP/1.1的发布，HTTP协议的功能和性能得到了显著提升。

以上是关于HTTP协议的详细说明，涵盖了其基本概念、主要特点、请求与响应格式、HTTP方法、状态码以及版本演进等方面。

HTTP状态码

HTTP常见的状态码和常见的字段

100 继续：服务器已经接收到请求的头部，并且客户端应继续发送请求的主体部分。

101 切换协议：服务器已经理解了客户端的请求，并将通过Upgrade消息头通知客户端切换协议。

GET与POST

1.作用不同

GET用于从服务端获取资源

POST一般用来向服务器端提交数据

2.参数传递方式不同

GET请求的参数一般写在URL中，且只接受ASCII字符

POST请求参数一般放在请求体中，对于数据类型也没有限制

3.安全性不同

因为参数传递方式的不同，所以两者安全性不同，GET请求的参数直接暴露在URL中，所以更不安全，不能用来传递敏感信息。

4.参数长度限制不同

GET传送的数据量较小，不能大于2KB。

POST传送的数据量较大，一般被默认为不受限制。 HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大多是浏览器和服务器的原因。

5.编码方式不同

GET 请求只能进行 URL 编码（application/x-www-form-urlencoded）

POST 支持多种编码方式（application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多种编码。）

6.缓存机制不同

GET 请求会被浏览器主动cache，而 POST 不会，除非手动设置。

GET 请求参数会被完整保留在浏览器历史记录里，而 POST 中的参数不会被保留。

GET 产生的 URL 地址可以被 保存为书签，而 POST 不可以。

GET 在浏览器回退时是无害的，而 POST 会再次提交请求。

7.时间消耗不同

GET 产生一个 TCP 数据包；

POST 产生两个 TCP 数据包。

对于 GET 方式的请求，浏览器会把 header 和 data 一并发送出去，服务器响应 200（返回数据）；而对于 POST，浏览器先发送 Header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）

8.幂等

意思是多次执行相同的操作，结果都是「相同」的。 GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。

POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。

请求URL的过程

从输入URL到页面展示到底发生了什么？

1、浏览器接收到用户请求，先检查浏览器缓存里是否有缓存该资源，如果有直接返回；如果没有进入下一步网络请求。

2、网络请求前，进行DNS解析，以获取请求域名的IP地址。如果请求协议是HTTPS，那么还需要建立TLS连接。DNS解析时会按本地浏览器缓存->本地host文件->路由器缓存->dns服务器->根dns服务器的顺序查询域名对应IP，直到找到为止。

3、浏览器与服务器IP建立TCP连接。连接建立后，浏览器端会构建请求行、请求头等信息，并把和该域名相关的Cookie等数据附加到请求头中，向服务器构建的请求信息。

4、服务器接收到请求信息，根据请求生成响应数据。

5、浏览器解析响应头。若响应头状态码为301、302，会重定向到新地址；若响应数据类型是字节流类型，一般会将请求提交给下载管理器；若是HTML类型，会进入下一部渲染流程。

6、浏览器解析html文件，创建DOM树，解析CSS进行样式计算，然后将CSS和DOM合并，构建渲染树；最后布局和绘制渲染树，完成页面展示。

HTTP1.0、HTTP1.1、HTTP2.0

HTTP1.0和HTTP1.1的区别？HTTP2.0于http1.1的区别？

HTTP1.0和HTTP1.1的区别？

长连接

HTTP1.1支持长连接，每一个TCP连接上可以传送多个HTTP请求和响应，默认开启Connection:Keep-Alive，而HTTP1.0默认为短连接，每次请求都需要建立一个TCP连接。

缓存

HTTP1.0主要使用If-Modified-Since，Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag， If-None-Match等更多可供选择的缓存头来控制缓存策略。

管道化

基于HTTP1.1的长连接，使得请求管线化成为可能。管线化使得请求能够“并行”传输，但是响应必须按照请求发出的顺序依次返回，性能在一定程度上得到了改善。

增加Host字段

使得一个服务器能够用来创建多个 Web 站点。

状态码

新增了24个错误状态响应码

带宽优化

HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content）

---

HTTP1.1和HTTP2.0的区别？

二进制分帧：在应用层（HTTP/2.0）和传输层（TCP or UDP）之间增加一个二进制分帧层，从而突破 HTTP1.1 的性能限制，改进传输性能，实现低延迟和高吞吐量。 多路复用（MultiPlexing），允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息，这个强大的功能则是基于“二进制分帧”的特性。

首部压缩，HTTP1.1 不支持 header 数据的压缩，HTTP/2.0 使用 HPACK 算法对 header 的数据进行压缩，这样数据体积小了，在网络上传输就会更快。高效的压缩算法可以很大的压缩 header ，减少发送包的数量从而降低延迟。

服务端推送（server push），在 HTTP/2 中，服务器可以对客户端的一个请求发送多个响应，即服务器可以额外的向客户端推送资源，而无需客户端明确的请求。

HTTPS原理

HTTPS的工作原理？(https是怎么建立连接的），HTTPS与HTTP的区别

（一）HTTPS是如何建立连接的？

1.首先，客户端向服务器端发送请求报文，请求与服务端建立连接。

2.服务端产生一对公私钥，然后将自己的公钥发送给CA机构，CA机构也有一对公私钥，然后CA机构使用自己的私钥将服务端发送过来的公钥进行加密，产生一个CA数字证书。

3.服务端响应客户端的请求，将CA机构生成的数字证书发送给客户端。

4.客户端将服务端发送过来的数字证书进行解析(因为浏览器产商跟CA机构有合作，所以浏览器中已经保存了大部分CA机构的密钥，用于对服务端发送过来的数字证书进行解密)，验证这个数字证书是否合法，如果不合法，会发送一个警告。如果合法，取出服务端生成的公钥。

5.客户端取出公钥并生成一个随机码key（其实就是对称加密中的密钥）

6.客户端将加密后的随机码key发送给服务端，作为接下来的对称加密的密钥

7.服务端接收到随机码key后，使用自己的私钥对它进行解密，然后获得到随机码key。

8.服务端使用随机码key对传输的数据进行加密，在传输加密后的内容给客户端

9.客户端使用自己生成的随机码key解密服务端发送过来的数据，之后，客户端和服务端通过对称加密传输数据，随机码Key作为传输的密钥。

（二）HTTP 与 HTTPS 的区别

HTTP 是明文传输，HTTPS 通过 SSL\TLS 进行了加密。

HTTP 的端口号是 80，HTTPS 是 443。

HTTPS 需要到 CA 申请证书。

HTTP 的连接简单，是无状态的；

HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。

HTTPS防篡改

HTTPS是如何保证数据的完整性的（如何保证内容不被篡改）？

为了保证传输的内容不被修改，可以将传输的内容计算出一个【指纹】，对方收到后，也把接收的内容计算出一个【指纹】，然后进行对比，如果【指纹】相同，则说明内容没有被篡改，常常会使用摘要算法（哈希函数）来计算出内容的哈希值，通过摘要算法可以生成数据的唯一标识，从而验证数据的完整性。

但是摘要算法只能保证内容不被修改，不能保证发送者的身份，为了避免这种情况，计算机里会用非对称加密算法来解决，共有两个密钥：公钥用于验证签名，私钥用于生成签名。私钥是由服务端保管，然后服务端会向客户端颁发对应的公钥。如果客户端收到的信息，能被公钥解密，就说明该消息是由服务器发送的。

生成数字签名：

发送者使用私钥对消息的摘要（通常是通过哈希函数计算得到）进行加密，生成数字签名。

数字签名是消息的哈希值经过私钥加密的结果。

发送消息和数字签名：

发送者将原始消息和生成的数字签名一起发送给接收者。

验证数字签名：

接收者收到消息和数字签名后，使用发送者的公钥对数字签名进行解密，得到摘要值。

接收者再次计算收到的消息的摘要（使用相同的哈希函数），将其与解密得到的摘要值进行比较。

如果两个摘要值相同，说明消息未被篡改过，数字签名有效，消息来源可信。

数字证书验证流程

密钥生成：

首先，实体（例如服务器、个人或组织）需要生成一对密钥：公钥和私钥。

公钥是用于加密和验证的，可以被公开分享。

私钥用于解密和签名，必须保密，只有持有者知道。

证书请求（CSR - Certificate Signing Request）：

实体生成一个证书请求，其中包含公钥、实体信息（如名称、电子邮件等）和签名。

CSR是一个包含有关实体信息的文本块，可以被发送到数字证书颁发机构（CA）以获取数字证书。

证书颁发：

实体将证书请求发送给数字证书颁发机构（CA）。

CA会验证请求者的身份，然后使用自己的私钥对请求中的信息进行签名，生成数字证书。

数字证书包括公钥、实体信息、CA的信息和签名等内容。

证书验证：

当实体收到数字证书时，它可以使用CA的公钥验证证书的签名，确保证书未被篡改且由合法的CA签发。

接收者可以检查证书中的实体信息以及CA的信息，确保证书的合法性。

数字证书使用：

接收者可以使用数字证书中的公钥来加密数据，然后发送给证书的持有者。

持有者使用私钥解密数据，保护数据的机密性。

持有者还可以使用私钥生成数字签名，接收者使用公钥验证签名，验证数据的来源和完整性。

DNS

DNS是什么，及其查询过程

DNS 是：一个由分层的 DNS 服务器实现的分布式数据库 ， 一个使得主机能够查询分布式数据库的应用层协议，作用是将主机名转换成ip地址。

浏览器访问了某个域名，首先会查找浏览器缓存、本地 hosts 文件、DNS 缓存，没有找到的话再去请求本地 DNS 服务器，由它负责完成域名的解析。

本地 DNS 会依次请求根域名服务器拿到对应的顶级域名服务器的地址，然后请求顶级域名服务器，拿到权威域名服务器的地址，之后权威域名服务器会返回最终的 IP 给本地 DNS 服务器，由它再返给浏览器。

根域名服务器（Root Name Servers） 是DNS（域名系统）层次结构中的最高层，它负责管理互联网上的根域（.），并解析顶级域名（TLD）服务器的IP地址。目前，全球共有13个根域名服务器。

在DNS中，域名是分层次结构的，每个域名都包含一个或多个由点（.）分隔的标签。这些标签从右到左表示了域名的不同级别。最右边的标签是顶级域名（TLD），如 .com、.net、.org、.edu、.gov、.uk、.cn 等。

例如，如果用户尝试访问 www.example.com，并且本地DNS服务器不知道 example.com 的IP地址，那么它可能会首先查询 .com 顶级域名服务器，该服务器会返回负责管理 example.com 域名的权威DNS服务器的地址。然后，本地DNS服务器会向这个权威DNS服务器发送查询请求，以获取 www.example.com 的IP地址。

简单地来说就是：浏览器缓存、本地 hosts 文件、DNS 缓存、根域名服务器—>顶级域名服务器的地址、顶级域名服务器—>权威域名服务器的地址、权威域名服务器—>IP地址。

使用HTTP而非HTTPS的弊端

1. 数据安全性问题：
   • 明文传输：HTTP协议无法加密数据，所有通信数据都在网络中明文传输，这意味着用户的敏感信息，如密码、信用卡信息等，极易被第三者通过网络嗅探工具截取和查看。
   • 内容易被篡改：HTTP协议无法证明通信的报文完整性，因此在请求或响应到达接收方之前，其内容可能被恶意篡改，而通信双方对此一无所知。
2. 身份验证缺失：
   • HTTP协议没有提供任何身份验证机制，因此无法保证与服务器建立连接的是合法的实体。这导致攻击者可以轻易地伪造服务器并欺骗用户提供敏感信息。
3. 信誉度下降：
   • 由于HTTP协议的不安全性，现代Web浏览器已经开始警告用户在使用HTTP连接的页面上输入敏感信息。这导致HTTP站点的信誉度下降，可能会影响站点的流量和收入。
4. 搜索排名影响：
   • HTTPS协议的搜索排名通常优于HTTP协议。这是因为HTTPS可以提高用户的信任度和安全感，从而增加用户的访问量和停留时间，这些都是搜索引擎优化(SEO)的重要因素。

综上所述，使用HTTP而非HTTPS存在显著的安全性和信誉度问题，因此在今天的互联网环境中，建议尽可能使用HTTPS来保护用户的敏感信息和维护站点的信誉度。

强缓存和协商缓存

什么是强缓存和协商缓存

Cookie和Session

Cookie和Session在Web开发中扮演着重要的角色，用于跟踪和识别用户会话。以下是它们之间的详细区别：

1. 存储位置：
   • Cookie：数据保存在客户端的浏览器上。
   • Session：数据保存在服务器上。
2. 存储容量：
   • Cookie：单个cookie保存的数据通常不超过4KB（有些资料中提到是3K），一个站点最多保存20个Cookie。
   • Session：存储容量并没有明确的上限，但出于对服务器性能的考虑，不建议在session中存放过多的数据。
3. 存储方式：
   • Cookie：只能保存ASCII字符串，并需要通过编码方式存储为Unicode字符或者二进制数据。
   • Session：能够存储任何类型的数据，包括且不限于string, integer, list, map等。
4. 隐私策略与安全性：
   • Cookie：对客户端是可见的，存在被分析并进行cookie欺骗的风险，因此安全性相对较低。
   • Session：存储在服务器上，对客户端是透明的，不存在敏感信息泄漏的风险，因此安全性较高。
5. 有效期：
   • Cookie：可以通过设置属性使cookie长期有效。
   • Session：依赖于名为JSESSIONID的cookie，当关闭浏览器窗口时（或者根据服务器的设置），session可能会失效。
6. 服务器压力：
   • Cookie：不占用服务器资源，对于并发用户十分多的网站，是一个好的选择。
   • Session：每个用户都会产生一个session，如果并发访问的用户十分多，会产生大量的session，耗费大量的内存。
7. 浏览器支持：
   • Cookie：需要客户端浏览器支持，如果客户端禁用了cookie或者不支持cookie，会话跟踪会失效。
   • Session：可以使用URL地址重写的方式来实现，如果浏览器不支持cookie，仍然可以通过URL地址重写来使用session。
8. 跨域支持：
   • Cookie：支持跨域名访问。
   • Session：不支持跨域名访问。
9. 对象与用途：
   • Cookie：是针对每个网站的信息，每个网站只能对应一个，通常用于保存用户名、密码、设置等用户特定信息。
   • Session：是针对每个用户的，只有客户端才能访问，主要用于保存用户的登录信息、操作信息等重要数据。

总的来说，Cookie和Session各有优缺点，应根据实际需求来选择使用哪种机制。如果需要长期保存用户信息且对安全性要求不高，可以选择Cookie；如果需要保存重要信息且对安全性有较高要求，应选择Session。

WebSocket协议

介绍

WebSocket协议是一种在Web应用程序中实现双向通信的协议，它基于TCP连接，允许服务器和客户端之间建立持久的连接并实现实时数据传输。

WebSocket协议通过封装HTTP协议来建立和管理TCP连接。

以下是对WebSocket协议的详细说明，遵循了分点表示和归纳的格式：

一、协议原理

• WebSocket协议基于HTTP协议，通过在HTTP握手阶段升级协议来实现双向通信。
• 在握手过程中，客户端发送一个特殊的HTTP请求，服务器返回一个特殊的HTTP响应（使用HTTP/1.1协议的101状态码），然后双方之间的通信就可以通过全双工的方式进行。

二、协议特点

1. 实时性：
   • WebSocket协议支持实时数据传输，可以在服务器和客户端之间实现低延迟的双向通信。
   • 相对于传统的HTTP协议，WebSocket减少了频繁建立连接的开销，从而提高了实时性。
2. 双向通信：
   • WebSocket协议允许服务器主动向客户端推送数据，而不需要客户端发送请求。
   • 这种双向通信的特性使得实时信息的推送成为可能，例如实时聊天、实时股票行情等。
3. 低开销：
   • WebSocket协议使用较少的网络流量和计算资源。
   • 它采用的是二进制数据格式，相对于文本数据格式，可以减少数据的大小和传输的时间。
4. 跨域支持：
   • WebSocket协议支持跨域通信，可以在不同域名、不同端口或不同协议之间建立通信连接。
5. 持久连接：
   • WebSocket协议在客户端和服务器之间建立连接后，会保持长时间的连接状态。
   • 这避免了每次通信都要重新建立连接的开销，提高了通信效率。

三、使用方法

1. 建立连接：
   • 客户端通过创建WebSocket对象来建立与服务器的连接。
   • 可以使用JavaScript的WebSocket API来创建WebSocket对象，并指定服务器的URL。
2. 发送数据：
   • 客户端可以通过WebSocket对象的send()方法向服务器发送数据。
   • 发送的数据可以是文本数据或二进制数据。
3. 接收数据：
   • 客户端可以通过WebSocket对象的onmessage事件来接收服务器发送的数据。
   • 通过监听onmessage事件，客户端可以实时获取服务器推送的数据。
4. 关闭连接：
   • 客户端可以通过WebSocket对象的close()方法关闭与服务器的连接。
   • 关闭连接后，客户端将无法再发送和接收数据。

四、安全性措施

• 为了保护数据的安全性，可以使用SSL/TLS协议对WebSocket通信进行加密。
• 通过使用wss://而不是ws://来指定WebSocket的URL，可以将通信升级为加密通信。

五、应用场景

WebSocket协议适用于需要实时通信、实时推送数据、实时同步编辑等场景，如实时聊天、实时数据更新、协同编辑、实时监控和游戏开发等。这些场景通常需要服务器能够主动向客户端推送数据，而WebSocket协议正好提供了这样的能力。

为什么需要？

尽管TCP和UDP协议为网络通信提供了基本的能力，但WebSocket协议在某些应用场景下具有其独特的优势和适用性，这也是为什么我们需要WebSocket协议的原因。以下是详细的分点说明和归纳：

1. 实时性要求：
   • TCP和UDP协议虽然可以实现数据的传输，但在实时性要求较高的场景中，如实时聊天、在线游戏、实时数据更新等，它们可能无法提供足够的实时性。
   • WebSocket协议通过在客户端和服务器之间建立持久连接，实现了实时的双向数据传输。服务器可以主动向客户端推送数据，而不需要客户端频繁发起请求，从而大大提高了实时性。
2. 降低通信开销：
   • 使用HTTP协议进行实时通信时，由于HTTP是无状态的，客户端需要不断地发送请求来查询数据的状态。这种频繁的建立连接和断开连接的开销在大量数据传输时会变得非常大。
   • WebSocket协议通过建立持久的连接，减少了频繁建立连接的开销，从而降低了通信成本。
3. 双向通信：
   • TCP虽然也是双向通信协议，但它主要是为了传输可靠性而设计的，没有专门为实时双向通信提供优化。
   • WebSocket协议则明确针对实时双向通信进行了设计，使得服务器和客户端之间可以更加方便地进行数据的实时交互。
4. 简化编程模型：
   • 在使用HTTP进行实时通信时，开发者需要处理复杂的轮询逻辑和状态管理。
   • WebSocket协议为开发者提供了一个简单的编程模型，只需要建立连接、发送数据和接收数据即可，无需关心底层的连接管理和状态维护。
5. 支持跨域通信：
   • WebSocket协议支持跨域通信，这使得在不同域名、不同端口或不同协议之间的通信变得更加容易。
6. 协议开销：
   • 虽然TCP协议具有更高的可靠性，但其协议开销也相对较高。WebSocket协议在保持一定可靠性的同时，通过优化协议设计，降低了协议开销，提高了传输效率。

综上所述，虽然TCP和UDP协议已经提供了基本的网络通信能力，但在实时性要求较高、需要降低通信开销、简化编程模型以及支持跨域通信等场景下，WebSocket协议具有其独特的优势和适用性。因此，在这些场景下，我们需要使用WebSocket协议来实现网络通信。

Keepalive

http多个tcp连接怎么实现的，TCP的Keepalive和HTTP的 Keep-Alive是一个东西吗？

HTTP多个连接是怎么实现的？

HTTP1.1引入了长连接机制，之前一个TCP连接只能发送一个HTTP请求，就会关闭。有了长连接之后，发送了一次HTTP请求之后，TCP连接不会被关闭，会继续发送请求，直到一方要求关闭为止。可以开启多个TCP连接，节省了TCP连接建立3握手和TLS连接4次握手的时间。不过服务器进行的TCP连接数量也是有上限的。

TCP的Keepalive和HTTP的Keep-Alive一样吗？

HTTP 的 Keep-Alive，是由应用层（用户态） 实现的，称为 HTTP 长连接；

TCP 的 Keepalive，是由 TCP 层（内核态） 实现的，称为 TCP 保活机制；

（1）每次请求都要经历这样的过程：建立 TCP -> 请求资源 -> 响应资源 -> 释放连接，这就是HTTP短连接，但是这样每次建立连接都只能请求一次资源，所以HTTP 的 Keep-Alive实现了使用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，避免了连接建立和释放的开销，就就是 HTTP 长连接。

（2）TCP 的 Keepalive 这东西其实就是 TCP 的保活机制，通俗地说，就是TCP有一个定时任务做倒计时，超时后会触发任务，内容是发送一个探测报文给对端，用来判断对端是否存活。

PING

PING是怎么工作的？

PING命令是计算机网络中常用的命令之一，它的作用是测试两台计算机之间的连通性以及测量数据包往返的时间。

PING命令的工作原理涉及到ICMP(Internet Control Message Protocol)和网络协议栈的操作:

1.发送ICMP Echo请求：当用户在命令行中输入 PING命令并指定目标主机(可以是IP地址或域名)时，操作系统会创建一个ICMP Echo请求消息，这是一个特殊的网络控制消息，用于询问目标主机是否在线。

2.封装数据包：ICMP Echo请求消息被封装在一个IP数据包中，该数据包的源IP地址是发送方主机的IP地址，目标IP地址是PING命令中指定的目标主机的IP地址。然后，数据包会通过操作系统的网络协议栈发送到网络上。

3.路由：数据包在网络中传输时，会经过一系列的路由器和网络设备。每个设备都会检查数据包的目标IP地址，并将其转发到正确的下一个目标。

4.接收ICMP Echo响应：当目标主机接收到ICMP Echo请求消息后，它会生成一个ICMP Echo响应消息作为回应。这个响应消息包含与请求消息相同的数据，以及其他标识信息。

5.数据包返回：ICMPEcho响应消息被封装在一个IP数据包中，源IP地址是目标主机的IP地址，目标IP地址是PING命令中指定的发送方主机的IP地址。然后，数据包会通过网络返回到发送方主机。

6.解析结果：发送方主机收到ICMP Echo响应消息后，PING命令会计算往返时间(Round-Trip

Time，RTT)，即从发送请求到接收到响应的时间间隔。此外，PING还会显示其他信息，如目标主机的IP地址、丢包率等。

需要注意的是，有些网络设备或防火墙可能会阻止或限制ICMP消息的传输，因此在某些情况下， PING命令可能无法正常工作。此外，由于网络中的不稳定性，PING命令可能会出现延迟或丢包现象，因此在分析结果时需要综合考虑多次的测试结果。

对/非称加密

什么是对称加密和非对称加密？

对称加密

对称加密也称为私钥加密，使用相同的密钥来进行加密和解密。

在加密过程中，明文数据通过应用特定的算法和密钥进行加密，生成密文数据。解密过程则是将密文数据应用同样的算法和密钥进行解密，恢复为明文数据。

由于加密和解密都使用相同的密钥，因此对称加密算法的速度通常较快，但密钥的安全性很重要。如果密钥泄漏，攻击者可以轻易地解密数据。

非对称加密

非对称加密也称为公钥加密，使用一对不同但相关的密钥：公钥和私钥。

公钥用于加密数据，私钥用于解密数据。如果使用公钥加密数据，只有拥有相应私钥的人才能解密数据；如果使用私钥加密数据，可以使用相应公钥解密。

除了加密和解密，非对称加密还用于【数字签名】，可以验证消息的来源和完整性。