TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；字节流：用户消息通过 TCP 协议传输时，消息可能会被操作系统「分组」成多个的 TCP 报文，如果接收方的程序如果不知道「消息的边界

但是光有web服务器名www.server.com是不够的，只知道一个人的名字是找不到人的，我们还需要服务器的IP地址。对URL进行解析之后，浏览器确定了 Web 服务器和文件名，就会根据这些信息来生成 HTTP 请求消息。而DNS服务器就可以通过服务器名提供它的IP地址(相当于一个电话本，通过人名查询电话号码)，下面以http://www.server.com/dir1/file1.html为例

1.Linux收包：网卡收到网络包之后会通过 DMA 技术将网络包写入RingBuffer环形缓冲区，接着网卡向 CPU 发起硬件中断，当 CPU 收到硬件中断请求后，根据中断表，调用已经注册的中断处理函数。

HTTP/3 同 HTTP/2 一样采用二进制帧的结构，不同的地方在于 HTTP/2 的二进制帧里需要定义 Stream，而 HTTP/3 自身不需要再定义 Stream，直接使用 QUIC 里的 Stream，于是 HTTP/3 的帧的结构也变简单了。对于静态表的变化，HTTP/2 中的 HPACK 的静态表只有 61 项，而 HTTP/3 中的 QPACK 的静态表扩大到 91 项。HTTP/

TCP 协议本身是全双工的，但我们最常用的 HTTP/1.1，虽然是基于 TCP 的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，需要使用支持全双工的 WebSocket 协议。在 HTTP/1.1 里，只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。对于客户端和服务端之间需要频繁

HTTP/1.1采用了长连接来提高性能，只要客户端和服务器端没有一方主动断开连接，就会在一定时间内保持连接，从而避免了多次连接和断开产生的开销，长连接使得管道网络传输成为可能，之前的情况是必须等第一个请求得到响应时才能发送第二个请求，如果使用管道网络传输，那么就可以在发送的第一个请求没有得到响应时就发送第二个请求，但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应，如果服务端在处理某一个请

2. 按如下路径找到对应需要修改的服务，此处以Redis服务为例。1. Win + R 快捷键进入如下窗口，输入regedit。3. 双击ImagePath即可修改。

HTTP/1.1相较于HTTP/1.0新增了长连接，解决了请求时的队头阻塞，但没有解决响应时的队头阻塞。而HTTP/2进行了头部压缩，以及二进制格式传输，并基于HTTPS将多个 Stream 复用在一条 TCP 连接中，解决了HTTP层面请求和响应的队头阻塞，通过Stream ID来区分不同的流，并且不同 Stream 的帧是可以乱序发送的，再由接收端通过 Stream ID 有序组装成 HTTP

1、Tabnine AI Code Completion... 代码补全。2、Chinese(Simplified)... 中文语言包。1、Background Image Plus 换壁纸。4、Sequence Giagram 生成代码时序图。2、GsonFormatPlus json代码生成。4、Key Promoter X 快捷键提示插件。5、Rainbow bracket 彩虹括号插件。3

代理软件会禁用所有的代理设置，所有流量都不经过代理服务器，直接发送到目标服务器。用户可以编写脚本来决定哪些流量需要经过代理，哪些流量可以直接连接到目标服务器。当涉及到网络代理时，不同模式具有不同的设置，选择不同模式应根据实际需求和网络环境来决定。适用于需要全部流量都通过代理的场景，例如保护隐私、突破网络限制等。可根据实际需求自定义代理规则，例如针对特定应用或网站进行代理设置。脚本模式非常灵活，可以