计算机网络
- 以OSI体系为例讲解计算机网络的各层协议及作用?
七层网络体系结构各层的主要功能：
- 应用层：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统DNS，支持万维网应用的HTTP协议，支持电子邮件的SMTP协议等。
- 表示层：主要负责数据格式的转换，如加密解密、转换翻译、压缩解压缩等。
- 会话层：负责在网络中的两节点之间建立、维持和终止通信，如服务器验证用户登录便是由会话层完成的。
-
运输层：有时也译为传输层，向主机进程提供通用的数据传输服务。该层主要有以下两种协议：
- TCP：提供面向连接的、可靠的数据传输服务；
- UDP：提供无连接的、尽最大努力的数据传输服务，但不保证数据传输的可靠性。
-
网络层：选择合适的路由和交换结点，确保数据及时传送。主要包括IP协议。
-
数据链路层：数据链路层通常简称为链路层。将网络层传下来的IP数据包组装成帧，并再相邻节点的链路上传送帧。
-
物理层：实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和通信手段的差异。
- TCP和UDP的区别：
- 连接性：TCP是面向连接的协议，它需要在数据传输之前建立连接，并在数据传输完成后关闭连接。而UDP是无连接的协议，它不需要建立和维护连接。
- 可靠性：TCP提供可靠的数据传输服务，通过数据包的确认、重传等机制确保数据的完整性和顺序性。UDP不提供这些可靠性保证，数据包可能会丢失、重复或乱序到达。
- 流量控制：TCP提供流量控制，可以根据接收方的处理能力调整发送速率。UDP不进行流量控制。
- 错误检测：TCP和UDP都使用校验和来检测数据包在传输过程中的错误，但TCP还使用序列号来确保数据的顺序性。
- 性能：由于TCP的额外开销（如建立连接、确认、重传等），其性能通常比UDP低。UDP适用于对性能要求更高、可以容忍数据丢失或重复的应用。
- UDP和TCP对应的应用场景：
- TCP：适用于需要可靠数据传输的应用，如文件传输（FTP）、电子邮件（SMTP）、网页浏览（HTTP）等。这些应用需要确保数据的完整性和顺序性。
- UDP：适用于对实时性要求较高、可以容忍数据丢失的应用，如流媒体（如音频和视频）、VoIP（语音通信）、实时游戏等。此外，DNS查询也使用UDP，因为查询通常很短，而且丢失的查询可以很容易地重试。
- TCP的三次握手机制：
-
- SYN：客户端发送一个SYN报文给服务器，表示希望建立连接。SYN报文包含客户端的初始序列号。
-
- SYN+ACK：服务器收到SYN报文后，如果同意建立连接，会发送一个SYN+ACK报文给客户端。这个报文包含服务器的初始序列号，以及对客户端SYN报文的确认（ACK）。
-
- ACK：客户端收到SYN+ACK报文后，发送一个ACK报文给服务器，确认收到服务器的SYN+ACK报文。至此，连接建立完成。
- 为什么需要三次握手，而不是两次或四次？
- 两次握手：如果只有两次握手（客户端发送SYN，服务器发送SYN+ACK），那么可能会出现这样的问题：客户端发送的SYN报文因为网络原因延迟了，而服务器已经发送了SYN+ACK报文并建立了连接。当客户端的SYN报文最终到达服务器时，服务器会再次建立连接，导致不必要的资源浪费和错误。
- 四次握手：增加一次握手（如服务器发送SYN+ACK后，客户端再次发送一个确认报文）虽然可以进一步减少错误的可能性，但也会增加连接的建立时间，降低性能。
因此，三次握手是一个在可靠性和性能之间找到平衡的折中方案。
- 奈奎斯特准则和香农定理：
- SYN洪泛攻击及其防范措施：
SYN洪泛攻击是一种利用TCP协议缺陷进行的网络攻击。攻击者发送大量的TCP SYN报文给目标服务器，但不完成三次握手过程，从而导致服务器为每个未完成的连接分配资源，最终耗尽服务器的资源，使其无法为正常用户提供服务。
防范措施包括：
- 使用防火墙：配置防火墙规则，限制进入网络的连接数量和速率，以减少SYN请求的压力。
- 启用SYN Cookies：当接收到大量SYN请求时，服务器能够生成和发送虚假的SYN+ACK响应，以避免资源耗尽。
- 增加连接队列长度：提供更多的时间处理连接请求，并降低资源耗尽的风险。
- 使用IDS/IPS：入侵检测系统（IDS）或入侵预防系统（IPS）可以监控网络流量并识别异常行为，从而减轻SYN洪泛攻击的影响。
- 限制并发连接数：对服务器上每个IP地址或来源进行并发连接数限制，并设置适当的阈值来拒绝过多的连接请求。
- 负载均衡和流量分流：使用负载均衡器将流量分散到多台服务器上。
- 三次握手连接阶段，最后一次ACK包丢失，会发生什么?
在TCP的三次握手连接阶段，如果最后一次ACK包（即客户端对服务器SYN+ACK的确认包）丢失，服务器将不会收到确认，因此会认为连接未成功建立。根据TCP的超时重传机制，服务器会在一段时间后重新发送SYN+ACK包，以便客户端重新发送ACK包。这可能导致连接建立过程延迟，但在正常情况下，只要网络条件允许，最终连接还是会成功建立。
- TCP的四次挥手过程：
- 主动关闭方（通常是客户端）发送一个FIN报文给被动关闭方（通常是服务器），表示希望关闭连接。
- 被动关闭方收到FIN报文后，发送一个ACK报文给主动关闭方，确认收到FIN报文。此时，主动关闭方等待被动关闭方关闭连接。
- 被动关闭方在发送完ACK报文后，可能还需要发送一些数据给主动关闭方，或者等待主动关闭方发送更多的数据。当被动关闭方完成数据传输或等待时间超时后，发送一个FIN报文给主动关闭方，表示自己也希望关闭连接。
- 主动关闭方收到被动关闭方的FIN报文后，发送一个ACK报文给被动关闭方，确认收到FIN报文。此时，被动关闭方进入TIME-WAIT状态，等待一段时间以确保最后一个ACK报文能够成功发送。
- 为什么连接的时候是三次握手，关闭的时候却是四次挥手?
TCP连接建立时采用三次握手的原因是为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。具体来说，如果只有两次握手（客户端发送SYN，服务器发送SYN+ACK），那么可能会出现这样的问题：客户端发送的SYN报文因为网络原因延迟了，而服务器已经发送了SYN+ACK报文并建立了连接。当客户端的SYN报文最终到达服务器时，服务器会再次建立连接，导致不必要的资源浪费和错误。而三次握手通过引入一个额外的ACK报文，确保了双方都对连接建立达成了共识，从而避免了这种情况的发生。
相比之下，TCP连接关闭时采用四次挥手的原因是因为在连接关闭过程中可能存在数据传输的延迟。具体来说，当主动关闭方发送FIN报文后，被动关闭方可能还需要发送一些数据给主动关闭方，或者等待主动关闭方发送更多的数据。因此，在被动关闭方发送FIN报文之前，可能需要经历一段等待时间。这段时间内如果只有三次挥手（主动关闭方发送FIN，被动关闭方发送ACK和FIN，主动关闭方再次发送ACK），可能会出现这样的情况：主动关闭方在发送完ACK报文后立刻关闭了自己的连接，但被动关闭方可能因为网络延迟或其他原因还没有收到这个ACK报文。这时，被动关闭方会认为连接还没有被确认关闭，从而可能继续发送数据或等待更多的数据。这会导致数据丢失或连接状态不一致的问题。通过引入第四次挥手（被动关闭方发送ACK报文），确保了主动关闭方能够收到对FIN报文的确认，从而安全地关闭连接。这样，即使在网络延迟或其他异常情况下，双方也能确保连接已经正确地关闭。
- 为什么客户端的TIME-WAIT状态必须等待2MSL?
-
确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接。
第四次挥手时，客户端第四次挥手的 ACK 报文不一定会到达服务端。服务端会超时重传 FIN/ACK 报文，此时如果客户端已经断开了连接，那么就无法响应服务端的二次请求，这样服务端迟迟收不到 FIN/ACK 报文的确认，就无法正常断开连接。
MSL 是报文段在网络上存活的最长时间。客户端等待 2MSL 时间，即「客户端 ACK 报文 1MSL 超时 + 服务端 FIN 报文 1MSL 传输」，就能够收到服务端重传的 FIN/ACK 报文，然后客户端重传一次 ACK 报文，并重新启动 2MSL 计时器。如此保证服务端能够正常关闭。
如果服务端重发的 FIN 没有成功地在 2MSL 时间里传给客户端，服务端则会继续超时重试直到断开连接。
-
防止已失效的连接请求报文段出现在之后的连接中。
TCP 要求在 2MSL 内不使用相同的序列号。客户端在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以保证本连接持续的时间内产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。或者即使收到这些过时的报文，也可以不处理它。
- 如果已经建立了连接，但是客户端出现故障了怎么办?
简而言之，通过定时器 + 超时重试机制，尝试获取确认，直到最后会自动断开连接。
具体而言，TCP 设有一个保活计时器。服务器每收到一次客户端的数据，都会重新复位这个计时器，时间通常是设置为 2 小时。若 2 小时还没有收到客户端的任何数据，服务器就开始重试：每隔 75 分钟发送一个探测报文段，若一连发送 10 个探测报文后客户端依然没有回应，那么服务器就认为连接已经断开了。
- 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-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭； net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。 -
强制关闭，发送 RST 包越过TIME_WAIT状态，直接进入CLOSED状态。
- TIME_WAIT是服务器端的状态?还是客户端的状态?
TIME_WAIT 是主动断开连接的一方会进入的状态，一般情况下，都是客户端所处的状态;服务器端一般设置不主动关闭连接。
TIME_WAIT 需要等待 2MSL，在大量短连接的情况下，TIME_WAIT会太多，这也会消耗很多系统资源。对于服务器来说，在 HTTP 协议里指定 KeepAlive（浏览器重用一个 TCP 连接来处理多个 HTTP 请求），由浏览器来主动断开连接，可以一定程度上减少服务器的这个问题。
- TCP协议如何保证可靠性?
- 校验和：TCP在发送每个数据包时都会计算一个校验和，并在接收端进行验证。如果校验和不匹配，接收端会丢弃该数据包，并通知发送端重新发送。这有助于确保数据在传输过程中没有发生错误。
- 序列号：TCP为每个字节的数据分配一个唯一的序列号。这使得接收端能够正确排序接收到的数据，并识别出任何丢失或重复的数据包。如果接收端发现数据包的序列号不连续，它会请求发送端重新发送丢失的数据包。
- 确认应答：接收端在成功接收到数据包后会向发送端发送一个确认应答。这个确认应答包含了接收端期望接收的下一个数据包的序列号。发送端会根据这些确认应答来确保数据的正确传输。如果发送端在一定时间内没有收到确认应答，它会认为数据包丢失并重新发送。
- 流量控制：TCP使用滑动窗口机制进行流量控制，以防止发送端发送过多数据导致接收端缓冲区溢出。接收端会告知发送端其缓冲区的大小，发送端则根据这个信息调整发送速率。
- 拥塞控制：当网络出现拥塞时，TCP会采取一系列策略来减少数据的发送速率，以缓解网络压力。这包括慢开始、拥塞避免、快重传和快恢复等算法。
- 连接管理：TCP使用三次握手和四次挥手来建立和关闭连接。这确保了连接的可靠性和双方对连接状态的共识。
- TCP的滑动窗口详细解释：
TCP的滑动窗口是一种流量控制技术，用于管理发送方和接收方之间的数据传输速率。其核心思想是在任意时刻，发送方都维护一个数据窗口，该窗口描述了接下来可以发送的数据范围。窗口的大小由接收方通过TCP头部中的窗口字段通知给发送方，表示接收方缓冲区的可用空间大小。
发送方根据这个窗口大小来决定可以发送多少数据，而不必等待每个数据包的确认。当发送方发送了窗口内的所有数据后，窗口会沿着数据流向前移动，从而允许发送方发送更多数据。
滑动窗口示意图：
- 拥塞控制的详细解释：
拥塞控制是TCP协议中的一个重要机制，用于防止网络拥塞的发生。当网络中的分组数量过多，超出网络的处理能力时，会导致网络性能下降，严重时甚至可能导致通信业务停顿。
TCP的拥塞控制主要通过以下算法实现：
- 慢开始：当连接建立时，发送方初始设置一个较小的拥塞窗口（cwnd），并线性增加其大小，以探测网络的拥塞程度。
- 拥塞避免：当拥塞窗口达到一定大小时，算法转变为拥塞避免模式，此时窗口大小以较慢的速率增加，以避免网络拥塞。
- 快重传：当发送方连续收到三个或以上的重复确认（即接收方没有收到某个数据包并请求重传）时，发送方会立即重传该数据包，而不是等待超时。
- 快恢复：在快重传之后，发送方会调整拥塞窗口大小，并重新进入拥塞避免模式，而不是慢开始模式。
- IP地址的分类：
- A类地址：前8位表示网络地址，后24位表示主机地址。A类地址的网络数量较少，但每个网络中的主机数量较多。
- B类地址：前16位表示网络地址，后16位表示主机地址。B类地址适用于中等规模的网络。
- C类地址：前24位表示网络地址，后8位表示主机地址。C类地址适用于小型网络。
- D类地址：用于多播（Multicast）通信。
- E类地址：保留用于将来使用。
- 子网划分的基本方法：
子网划分是将一个IP网络划分为多个小的网络的过程。其基本方法包括以下几个步骤：
- 确定子网掩码：子网掩码用于区分IP地址中的网络部分和主机部分。通过修改子网掩码，可以将一个网络划分为多个子网。
- 计算子网数量和子网主机数量：根据子网掩码和原始IP地址，可以计算出划分后的子网数量和每个子网中的主机数量。
- 分配子网：将划分后的子网分配给不同的部门或设备使用。在分配时需要考虑子网的数量和每个子网中的主机数量是否满足需求。
- 配置路由：在子网划分后，需要配置路由以确保不同子网之间的通信能够正常进行。
- 常见的网络层协议：
例如IP, ICMP, IGMP, BGP, CIDR, ARP, OSPF, RIP等协议。
- 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。
- HTTP常用的请求方式?
| 方法 | 作用 |
|---|---|
| GET | 获取资源 |
| POST | 传输实体主体 |
| PUT | 上传文件 |
| DELETE | 删除文件 |
| HEAD | 和GET方法类似，但只返回报文首部，不返回报文实体主体部分 |
| PATCH | 对资源进行部分修改 |
| OPTIONS | 查询指定的URL支持的方法 |
| CONNECT | 要求用隧道协议连接代理 |
| TRACE | 服务器会将通信路径返回给客户端 |
- GET请求和POST请求的区别?
使用上的区别：
-
GET使用URL或Cookie传参，而POST将数据放在BODY中”，这个是因为HTTP协议用法的约定。
-
GET方式提交的数据有长度限制，则POST的数据则可以非常大”，这个是因为它们使用的操作系统和浏览器设置的不同引起的区别。
-
POST比GET安全，因为数据在地址栏上不可见”，这个说法没毛病，但依然不是GET和POST本身的区别。
- 解释一下HTTP长连接和短连接?
在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。
但从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码：Connection:keep-alive
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。
- HTTP请求报文和响应报文的格式?
请求报文
GET/sample.jspHTTP/1.1 请求行
Accept:image/gif.image/jpeg, 请求头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=jinqiao&password=1234 请求主体
应答报文
HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112
<html>
<head>
<title>HTTP响应示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>
- 讲述一下载波监听碰撞检测/冲突避免的过程与异同
载波监听碰撞检测（CSMA/CD）：
- 过程：在发送数据前，先监听信道是否空闲。如果空闲，则发送数据；如果不空闲，则等待一段时间后再尝试发送。在发送数据时，继续监听信道，如果检测到碰撞（即发现有其他站点也在发送数据），则立即停止发送，并等待一段随机时间后重新尝试发送。
- 特点：适用于小规模的局域网，但在网络规模较大时，碰撞的概率会增加，导致网络性能下降。
冲突避免（CSMA/CA）：
- 过程：在发送数据前，先监听信道是否空闲。如果空闲，则选择一个随机退避时间（Backoff Time）等待，然后发送数据。在发送数据时，继续监听信道，但不再检测碰撞。如果其他站点检测到该站点正在发送数据，则会等待一段时间后再尝试发送，以避免冲突。
- 特点：通常用于无线局域网（WLAN）或移动网络环境，其中碰撞检测较为困难。通过随机退避机制，减少了冲突的可能性，提高了网络性能。
异同：
- 相同点：两者都是基于载波监听的多路访问协议，即在发送数据前都会先监听信道是否空闲。
- 不同点：CSMA/CD通过检测碰撞并立即停止发送来避免冲突；而CSMA/CA则通过随机退避机制来避免冲突，不再检测碰撞。此外，CSMA/CD适用于有线局域网，而CSMA/CA则更适用于无线局域网或移动网络环境。
- 一个网页若包含五个jpg图像，传输这个网页需要多少RTT
首先，浏览器需要请求HTML文件。这是一个HTTP请求，因此会产生一个RTT。当服务器返回HTML文件时，这标志着第一个RTT的结束。
接下来，HTML文件中包含了五个JPG图像的引用（通常是通过标签）。当浏览器解析HTML文件并遇到这些图像引用时，它会为每个图像发起一个单独的HTTP请求。这意味着每个图像都会产生一个RTT。
因此，总的RTT次数是：1个RTT用于请求HTML文件，5个RTT用于请求五个JPG图像。所以，总共需要6个RTT来传输这个HTML文件及其包含的五个JPG图像。但需要注意，现代的浏览器和服务器经常使用各种优化技术（如并行请求、持久连接、HTTP/2多路复用等）来减少RTT的次数，从而提高网页的加载速度。
- HTTP与HTTPS的区别?
| HTTP | HTTPS | |
|---|---|---|
| 端口 | 80 | 443 |
| 安全性 | 无加密，安全性较差 | 有加密机制，安全性较高 |
| 资源消耗 | 较少 | 由于加密处理，资源消耗更多 |
| 是否需要证书 | 不需要 | 需要 |
| 协议 | 运行在TCP协议之上 | 运行在SSL协议之上，SSL运行在TCP协议之上 |
- HTTPS的优缺点?
优点：
-
安全性：
-
使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
-
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
-
HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
-
缺点：
- 在相同网络环境中，HTTPS 相比 HTTP 无论是响应时间还是耗电量都有大幅度上升。
- HTTPS 的安全是有范围的，在黑客攻击、服务器劫持等情况下几乎起不到作用。
- 在现有的证书机制下，中间人攻击依然有可能发生。
- HTTPS 需要更多的服务器资源，也会导致成本的升高。
- 讲一讲HTTPS的原理?
HTTPS的原理可以概括为以下几个步骤：
- 握手过程：当浏览器尝试与服务器建立HTTPS连接时，首先会进行SSL/TLS握手。在这个过程中，浏览器和服务器会协商一系列参数，包括使用的加密算法、密钥交换方式等。服务器会向浏览器发送其证书，证书中包含服务器的公钥和由受信任的证书颁发机构（CA）签名的信息。浏览器会验证证书的合法性，如果证书有效，浏览器会生成一个随机对称密钥，并使用服务器的公钥对其进行加密，然后发送给服务器。
- 加密通信：一旦握手过程完成，浏览器和服务器就可以使用之前协商好的参数进行加密通信了。浏览器会将HTTP请求的内容使用之前生成的对称密钥进行加密，然后发送给服务器。服务器收到加密的请求后，会使用自己的私钥解密出对称密钥，再用这个密钥解密请求内容。同样地，服务器发送给浏览器的响应也会被加密。
- 关闭连接：当通信完成后，浏览器和服务器会进行SSL/TLS关闭过程，释放之前建立的连接。
- 在浏览器中输入www.baidu.com后执行的全部过程?
-
DNS解析：浏览器首先会查询本地DNS缓存，看是否有www.baidu.com的IP地址。如果没有，它会向配置的DNS服务器（可能是本地ISP的DNS服务器）发送DNS查询请求。DNS服务器会查询其数据库或向其他DNS服务器递归查询，最终找到www.baidu.com对应的IP地址。
-
TCP连接：浏览器使用TCP协议与百度的服务器建立连接。它首先会发送一个TCP SYN包，服务器收到后会回复一个SYN-ACK包，浏览器再回复一个ACK包，完成TCP三次握手，建立连接。
-
发送HTTP请求：浏览器向服务器发送HTTP GET请求，请求获取www.baidu.com的首页内容。请求中包含了HTTP版本、请求方法（GET）、请求的资源路径、HTTP头等信息。
-
服务器响应：百度服务器收到请求后，处理请求并生成响应。响应中包含HTTP状态码（如200 OK）、响应头、响应体（HTML内容、图片、脚本等）等信息。服务器将响应发送回浏览器。
-
浏览器渲染：浏览器收到服务器的响应后，开始解析HTML，下载并解析CSS、JavaScript等资源，构建DOM树和CSSOM树，然后合成渲染树，最终将页面渲染到屏幕上。
-
TCP连接关闭：浏览器和服务器完成数据传输后，会进行TCP四次挥手，关闭TCP连接。
- 什么是Cookie和Session ?
什么是 Cookie
HTTP Cookie（也叫 Web Cookie或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。
Cookie 主要用于以下三个方面：
- 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
- 个性化设置（如用户自定义设置、主题等）
- 浏览器行为跟踪（如跟踪分析用户行为等）
什么是 Session
Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者 Session 超时失效时会话结束。
- Cookie和Session是如何配合的呢?
用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session ，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器，浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名。
当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。
- Cookie和Session的区別?
- 作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。
- 存取方式的不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
- 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
- 隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
- 存储大小不同， 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie。
- 如何考虑分布式Session问题?
- 客户端存储：直接将信息存储在cookie中，cookie是存储在客户端上的一小段数据，客户端通过http协议和服务器进行cookie交互，通常用来存储一些不敏感信息
- Nginx ip_hash 策略：服务端使用 Nginx 代理，每个请求按访问 IP 的 hash 分配，这样来自同一 IP 固定访问一个后台服务器，避免了在服务器 A 创建 Session，第二次分发到服务器 B 的现象。
- Session 复制：任何一个服务器上的 Session 发生改变，该节点会把这个 Session 的所有内容序列化，然后广播给所有其它节点。
- 共享 Session：服务端无状态话，将用户的 Session 等信息使用缓存中间件（如Redis）来统一管理，保障分发到每一个服务器的响应结果都一致。
- 什么是DDos攻击?
DDoS（Distributed Denial of Service，分布式拒绝服务）攻击是一种通过控制大量计算机或网络僵尸（Zombie）向目标网站或服务器发送大量请求，使其资源耗尽或超出处理能力，从而导致合法用户无法得到服务的攻击方式。这种攻击通常利用大量的合法或非法获取的计算机资源，以合法的IP地址作为攻击源，使得追踪和防御变得困难。
- 什么是XSS攻击?
XSS（Cross-Site Scripting，跨站脚本）攻击是一种网络安全漏洞攻击，通过在网页中注入恶意脚本（如JavaScript），当其他用户浏览该网页时，脚本会在用户的浏览器上执行，从而窃取用户数据、破坏网站功能或进行其他恶意行为。XSS攻击通常发生在应用程序对用户输入的数据没有进行适当的过滤或转义时。
- SQL注入是什么,如何避免SQL注入?
SQL注入（SQL Injection）是一种常见的网络攻击技术，通过在应用程序的输入字段中插入恶意的SQL代码，攻击者可以执行未授权的SQL命令，从而获取、修改或删除数据库中的数据。SQL注入通常发生在应用程序没有对用户输入进行充分的验证和过滤时。
避免SQL注入的一些方法：
- 限制数据库权限，给用户提供仅仅能够满足其工作的最低权限。
- 对进入数据库的特殊字符（’”\尖括号&*;等）转义处理。
- 提供参数化查询接口，不要直接使用原生SQL。
- 负载均衡算法有哪些?
多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，能互相分担负载。
- 轮询法：将请求按照顺序轮流的分配到服务器上。大锅饭，不能发挥某些高性能服务器的优势。
- 随机法：随机获取一台，和轮询类似。
- 哈希法：通过ip地址哈希化来确定要选择的服务器编号。好处是,每次客户端访问的服务器都是同一个服务器，能很好地利用session或者cookie。
- 加权轮询：根据服务器性能不同加权。