简述Web和HTTP
目录
HTTP概述
非持续连接和持续连接
非持续连接
持续连接
HTTP报文格式
HTTP请求报文
HTTP响应报文
Web缓存
条件GET方法
Web 即万维网，是一个基于超文本和 HTTP 协议的全球性信息系统，通过浏览器访问，以网页形式呈现信息。HTTP 是客户端和服务器之间进行数据传输的协议，用于 Web 上的信息交互。
和传统的广播或者电视不同，它们使用户只能被迫收听或者观看内容传播者所投放的节目。而Web可以按需所操作获取想要的内容。并且在Web上发布内容也很简单，只需很低的代价就能成为内容传播者，超链接和搜索引擎也能帮我们很好的来访问内容。
HTTP概述
HTTP是超文本传输协议，是Web应用核心的传输协议，在RFC中有所定义。它由两个程序实现：一个客户程序和一个服务器程序。客户程序和服务器程序运行在两个不同的端系统中，通过交换HTTP报文进行交互（也可以在同一个端系统中）。HTTP协议则定义了这个报文的结构以及交换的方式。
Web是由一个个对象构成的，一个对象只是一个文件，例如一个基本的HTML文件，一个网络图片，一段CSS样式表等等，他们可以通过一段URL寻址。多数的Web界面都会有一个HTML基本文件以及几个引用的对象。例如在一个Web页面中，包含了一段HTML文件，一段CSS样式表和一个网络JPEG图片，那么这个Web页面就由三个对象构成，HTML 文件通过特定标签的属性中所包含的 URL 来引用其他对象，例如：
<!DOCTYPE html>
<html lang="en">
<head><meta charset="UTF-8"><meta name="viewport" content="width=device-width, initial-scale=1.0"><!-- 链接外部CSS样式表 --><link rel="stylesheet" href="styles.css"><title>示例网页</title>
</head>
<body><header><h1>欢迎来到我的网站</h1></header><main><p>这是一个包含CSS样式和网络图片的示例页面。</p><!-- 展示网络图片 --><img src="https://www.example.com/blog/article.php" alt="示例图片"></main><footer><p>© 2025 示例网站版权所有</p></footer>
</body>
</html>URL（统一资源定位符号）一般格式如下：
scheme://host[:port]/path[?query][#fragment]scheme（协议）：指定访问资源所使用的协议，常见的有http（超文本传输协议）、https（加密的超文本传输协议）、ftp（文件传输协议）、mailto（邮件协议）等。例如，https://表示使用安全的超文本传输协议来访问资源。
host（主机名）：标识资源所在的服务器的域名或 IP 地址。例如，www.example.com或192.168.1.1。
port（端口号）：可选部分，用于指定服务器上的特定端口，不同的协议有默认的端口号，如http默认端口是 80，https默认端口是 443。如果使用默认端口，通常可以省略不写；如果使用非默认端口，则需要明确指定，例如http://www.example.com:8080。
path（路径）：指定服务器上资源的具体路径，用于定位服务器上的特定文件或资源。例如，/index.html表示服务器根目录下的index.html文件，/blog/posts/123.html表示blog目录下posts子目录中的123.html文件。
query（查询参数）：可选部分，用于向服务器传递额外的参数信息，多个参数之间用&符号分隔。例如，?name=John&age=30表示传递了两个参数name和age，其值分别为John和30。
fragment（片段标识符）：可选部分，用于指定页面内的特定位置或锚点。例如，#section1表示页面中的id为section1的元素位置，浏览器会自动滚动到该位置。
以https://www.example.com/blog/article.php?id=123#comments为例，https是协议，www.example.com是主机名，/blog/article.php是路径，?id=123是查询参数，#comments是片段标识符。
Web浏览器实现了HTTP的客户端，Web服务器实现了HTTP的服务器端，它用于存储Web对象，每个对象由URL寻址。
HTTP定义了客户向服务器请求Web页面的方式，以及服务器向客户传输Web页面的方式。HTTP使用TCP作为他的支撑传输协议。HTTP客户首先发起一个与服务器的TCP连接，一旦连接建立，该浏览器和服务器进程就可以通过套接字访问TCP。一旦客户向他的套接字发送了一个请求报文，该报文就脱离了用户控制并进入了TCP控制。TCP为HTTP提供了可靠的数据传输服务。客户发出的每一个HTTP请求都会完整的发送到服务器；类似的，服务器最终响应的HTTP报文也能完整的传输给客户。
但是HTTP协议是一个无状态协议，比如某个客户向同一个HTTP在短时间内发起同一个HTTP请求，服务器不会因为刚刚已经给了那个用户响应而不再提供响应，而是会重新发送该对象。同时我们也注意到Web使用了CS体系架构，Web服务器总是开着的，而且他的服务可能来自于数以万计的不同浏览器请求。就比如当你已经加载好了一个网站界面，再次点击加载（通常是点击浏览器的刷新按钮）时，浏览器会向服务器重新发送请求，服务器会根据请求重新处理并返回相应的内容，从而实现界面的刷新。
非持续连接和持续连接
非持续连接
每个请求 / 响应是经过一个单独的 TCP 连接发送。即每一次请求一个对象（如一个网页、一张图片等）都要建立一个新的 TCP 连接，当服务器发送完一个对象后，该 TCP 连接就会被关闭。例如，一个网页中有 10 张图片，使用非持续连接时，就需要建立 10 + 1 个 TCP 连接（1 个连接用于获取网页的 HTML 文件，10 个连接分别用于获取 10 张图片）。
每一次的连接都涉及到TCP的三次握手过程：即客户向服务器发送一个小的tcp报文，服务器用一段小的tcp报文段做出确认和响应，最后客户向服务器返回确认。前面两个过程就消耗了一个RTT的时间，在算上后面确认响应到达服务器，服务器传输响应的文件这一段也消耗了一次RTT。所以粗略的讲，总的响应时间就是两个RTT加上服务器传输文件的时间。
所以这有一个很明显的缺点，就是必须为每一个请求的对象建立和维护一个全新的连接，对于每一个连接，在客户和服务器中都要为此分配TCP的缓冲区以及维护TCP变量，相对于客户端来说，服务器的压力就会很大，因为一台服务器可能会受到成千上万的处理响应。同时每一个连接都要经过两个RTC的交付时延。
持续连接
所有的请求 / 响应经相同的 TCP 连接发送。服务器在发送响应后保持该 TCP 连接打开，在相同的客户端和服务器之间，后续的请求和响应报文能够通过相同的连接进行传送。例如，对于一个包含多个图片的网页，使用持续连接时，只需建立一次 TCP 连接，就可以通过这个连接获取网页的 HTML 文件以及所有的图片。
持续连接减少了 TCP 连接的建立次数，从而减少了连接建立的延迟，提高了效率。在流水线方式下，客户在收到 HTTP 的响应报文之前就能够接着发送新的请求报文。服务器会按顺序依次响应。在理想情况下，使用流水线方式时，多个请求可以在一个 RTT 内发出，服务器也能在一个 RTT 内开始依次返回响应，因此每个请求的 RTT 理论上可以远小于一个 RTT，从而大大提高了效率，减少了整体的响应时间。
但是服务器需要维持连接状态，以处理后续的请求，这需要一定的资源开销。如果连接长时间不被使用，会占用服务器资源，因此服务器通常会设置一个超时时间，当连接在一定时间内没有活动时，就会关闭连接。HTTP默认使用的时流水线方式的持续连接。
HTTP报文格式
HTTP报文通常由：请求行/状态行+首部行+空行+实体体构成。
HTTP请求报文
下面提供了一个经典的HTTP请求报文：
GET /products HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.5
Connection: keep-alive[消息体为空]请求行由：方法+sp+URL+sp+版本+cr/lf 构成.
方法字段可以取不同的值，包括GET、POST、HEAD、PUT和DELETE。
GET：向服务器请求获取指定资源。比如访问网页时，浏览器用 GET 方法请求服务器返回网页内容；调用数据接口获取信息，也是通过 GET 方法。服务器会将请求资源内容放在响应报文数据部分回传。
POST：向服务器提交数据进行处理。如用户注册登录时提交表单信息，文件上传时将文件数据发送给服务器，服务器接收到数据后进行相应处理，如存储到数据库。
HEAD：和 GET 类似，请求获取资源信息，但只返回响应头部，不返回资源内容主体。可用于获取资源元数据，如资源最后修改时间、内容长度、类型等信息。
PUT：将请求中的数据上传到服务器指定资源位置，一般用于更新服务器上已存在资源。若资源不存在，可能会创建新资源。
DELETE：请求服务器删除指定资源，资源由请求的 URL 标识。
首部行由 首部字段名+sp+值+cr/lf 组成.用于传递请求的附加信息.
空行由回车（CR）和换行（LF）两个字符组成，即CR LF。它的作用是分隔 HTTP 报文的首部行和实体体，让客户端和服务器能明确区分报文的不同部分，便于正确解析和处理。
实体体（Entity Body）是 HTTP 请求或响应报文中位于首部行之后的数据部分，它承载了实际要传输的内容
HTTP响应报文
下面提供了一个经典的HTTP响应报文：
HTTP/1.1 200 OK
Date: Fri, 09 May 2025 12:00:00 GMT
Server: Apache/2.4.52 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Content-Length: 1234<!DOCTYPE html>
<html>
<head><title>Welcome to Example.com</title>
</head>
<body><h1>Hello, World!</h1>
</body>
</html>和请求报文不同的是，响应报文的请求行换成了状态行。
状态行由 版本+sp+状态码+sp+短语+cr/lf 构成.
通过状态行，客户端能够快速了解服务器对请求的处理情况，进而采取相应的措施，如根据不同的状态码来决定是否显示错误信息、是否继续请求其他资源等。
一些常见的状态码和短语如下：
- 200 OK：表示请求成功，服务器已成功处理请求，并将请求的资源返回给客户端。
- 301 Moved Permanently3：表示请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。
- 400 Bad Request：客户端发送的请求有语法错误或无法被服务器理解，通常是由于请求参数不正确、缺少必要的首部字段、请求格式错误等原因导致。
- 404 Not Found5：客户端请求的资源在服务器上未找到，可能是因为资源不存在、路径错误、被删除或尚未创建等原因。
- 505 HTTP Version Not Supported：服务器不支持请求中所使用的 HTTP 协议版本。
用户与服务器的交互：cookie
前面我们说到，HTTP服务是无状态服务，而 Cookie 的出现正是为了解决 HTTP 的无状态性带来的一些问题，它可以实现状态的保存，记录用户的偏好以及跟踪用户的行为。
当用户访问网站时，服务器通过响应报文首部行中的Set - Cookie字段向浏览器发送 Cookie，包含名称、值及其他属性，如过期时间、域名等。浏览器接收后，根据Set - Cookie中的信息将 Cookie 存储在本地。
当用户再次访问同一网站或相关域名下的页面时，浏览器会在请求报文首部行中的Cookie字段中自动带上之前存储的 Cookie，发送给服务器。服务器收到请求后，从Cookie字段中读取相关信息，识别用户身份、获取用户设置或跟踪用户行为等，然后根据这些信息生成相应的响应内容返回给浏览器。
虽然cookie带来了很多的遍历，但是它也带来一系列的隐私问题。
Web缓存
Web缓存器也叫做代理服务器，它能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器有自己的磁盘存储空间，并在存储空间中保留最近请求过的对象副本。它相当于起到了一个中介的作用。它可以获取就近的内容，减少重复的请求。同时也可以缓解骨干网络的压力，起到一个分担作用等等。
比如浏览器正在请求一个对象，它会先创建一个到Web缓存器的TCP连接，并且向Web缓存器发起一个HTTP请求。接着缓存器进行检查，检查是否有该请求对象的副本，如果有就向该客户浏览器发送HTTP响应报文返回该对象，如果没有，他就接着和初始Web服务器进行一个TCP连接，初始Web服务器就向Web缓存器发起一个HTTP响应报文返回该对象，接着Web缓存器保留该副本，接着向客户浏览器返回一个响应报文返回该对象。
所以Web缓存器又可以作为客户端，也可以作为服务端。它通常由ISP（网络服务提供商）购买并且安装。
我们来通过一个特别简单的例子来讲述安装Web缓存器的好处。假设有两个网络，一个是公共因特网，一个是高速的机构网络（局域网）。初始的Web服务器分布在世界各地，与因特网相连，然后机构网络上的一个路由器通过一个15Mbps的链路和因特网上的一个路由器相连接，接入网本地由100Mbps的链路相连接。假设初始Web服务器的平均访问速率是每秒15个请求，假设请求对象的长度为1Mb，那我们可以粗略的估算一下链路上的流量强度：
在因特网链路上的流量强度：15个请求/秒 * 1Mb一个请求 / 15 Mbps =1
在机构网链路上的流量强度：15个请求/秒 * 1Mb一个请求 / 100 Mbps =0.15
我们假设因特网接入链路一侧的路由器转发HTTP报文到它响应报文的平均时间为2s,这也叫做“因特网时延”。
0.15的通信量最多导致数十毫秒的时延，因此我们可以忽略不记。但是在因特网上的时延不可以忽略不计，当流量强度为1的时候，链路上的时延会变得非常大并且无限延长。一个最直接的方式就是升级物理链路，把他提升到100Mbps甚至更高。但是这会造成一笔不小的费用，通常网络服务提供商不会这么做，用户也不会买单。
那如果在机构网本地接入一个Web缓存器当中介呢？假设他的缓存Cache为0.4，有40%的请求会立即得到Web缓存器的响应。接下来我们来算一下时延：
由于只有60%的请求会通过因特网的链路，所以流量强度也会因此减少，从1.0减到0.6，所以时延也会因此降低，在15Mbps的链路上大约为几十毫秒，但是这和因特网时延相比也是微不足道的。考虑这些后，我们来算一下平均时延：
0.6*2.01 +0.4*0.01 =1.21
这和原来相比足足快了0.8秒。
条件GET方法
虽然说Web缓存减少了缓存时间，提高了用户的体验，但是这也会引发一个问题，就是存在Web缓存器里面的内容是旧的，也就是已经被用户修改过的。但HTTP有一个条件GET首部行，在请求报文首部行添加： If-modified-since ，让服务器仅在资源发生变化时返回新内容，否则返回 “304 Not Modified” 状态码，告知客户端使用本地缓存，通过 “按需获取” 避免冗余数据传输，提升 Web 性能。
🍵🍵🍵.