一、引言
HTTP协议在互联网中起着至关重要的作用，它不仅是网页浏览的基础，还被广泛应用于各种不同的应用场景，成为了现代互联网通信的核心协议之一。
主要应用场景有网页浏览、API通信、文件传输、实时流媒体等
网页浏览：HTTP最常见的应用场景之一是用于传输网页内容。当用户在浏览器中输入网址时，浏览器会发送HTTP请求到服务器，服务器响应并返回相应的网页内容，最终在用户的浏览器中渲染显示出来。
API通信：许多Web应用程序使用HTTP作为API通信的协议，客户端通过发送HTTP请求到服务器来请求特定的服务或资源，服务器根据请求执行相应的操作并返回结果，这种方式被称为RESTful API。
文件传输：HTTP也可以用于文件传输，例如下载文件或上传文件。通过HTTP协议，客户端可以向服务器请求文件下载链接，或者将文件通过HTTP POST请求上传到服务器。
实时流媒体：HTTP还可以用于传输实时流媒体内容，例如音频或视频。通过HTTP Live Streaming（HLS）或者其他流媒体协议，服务器可以将实时流媒体内容分段传输给客户端，客户端则可以实时播放这些内容。
值得注意的是HTTP1.0和1.1的差异（敢说一半以上面试官也不清楚）：
HTTP 1.0
HTTP 1.0 是在 1996 年引入的，从那时开始，它的普及率就达到了惊人的效果。
- HTTP 1.0 仅仅提供了最基本的认证，这时候用户名和密码还未经加密，因此很容易收到窥探。
- HTTP 1.0 被设计用来使用短链接，即每次发送数据都会经过 TCP 的三次握手和四次挥手，效率比较低。
- HTTP 1.0 只使用 header 中的 If-Modified-Since 和 Expires 作为缓存失效的标准。
- HTTP 1.0 不支持断点续传，也就是说，每次都会传送全部的页面和数据。
- HTTP 1.0 认为每台计算机只能绑定一个 IP，所以请求消息中的 URL 并没有传递主机名（hostname）。
HTTP 1.1
HTTP 1.1 是 HTTP 1.0 开发三年后出现的，也就是 1999 年，它做出了以下方面的变化
- HTTP 1.1 使用了摘要算法来进行身份验证
- HTTP 1.1 默认使用长连接，长连接就是只需一次建立就可以传输多次数据，传输完成后，只需要一次切断连接即可。长连接的连接时长可以通过请求头中的
keep-alive来设置 - HTTP 1.1 中新增加了 E-tag，If-Unmodified-Since, If-Match, If-None-Match 等缓存控制标头来控制缓存失效。
- HTTP 1.1 支持断点续传，通过使用请求头中的
Range来实现。 - HTTP 1.1 使用了虚拟网络，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。
本章将从HTTP1开始，对HTTP1进行梳理。
二、概述
历史背景
HTTP1.0是超文本传输协议（Hypertext Transfer Protocol）的第一个版本，于1996年正式发布。它是一种用于在客户端与服务器之间进行数据传输的协议，主要用于传输超文本和链接，实现文档间的关联。
在HTTP1.0之前，存在多种不同的实现方式，这导致了一些混乱。为了解决这些问题，1995年开始修订HTTP的第一个标准化版本。在1997年初，HTTP1.1标准发布，就在HTTP1.0发布的几个月后。HTTP1.1消除了大量歧义内容并引入了一些新特性，如增加了HEAD/POST等新方法、响应状态码、版本号、Header头部的概念和Content-Type等。
这些新技术的出现，促使HTTP协议开始添加各种特性，从用户需求的角度促进了HTTP协议的发展。
定义
HTTP1.0是一种无状态的协议，它使用TCP作为传输层协议。在HTTP1.0中，客户端通过发送请求来获取服务器上的资源，服务器则通过发送响应来回复客户端的请求。每个请求和响应都是独立的，服务器不会记录客户端的状态。
三、HTTP1 的使用
客户端与服务器的通信过程
- HTTP数据构造和请求发送
构造HTTP请求：客户端（例如浏览器）根据用户输入的URL构造HTTP请求，包括请求方法（GET、POST等）、请求头部、请求正文等信息。
DNS解析：如果请求的URL中包含了域名，客户端会先进行DNS解析，将域名解析为服务器的IP地址。
建立TCP连接：客户端使用IP地址和服务器建立TCP连接。这涉及到TCP的三次握手过程，即客户端向服务器发送SYN包，服务器响应SYN-ACK包，最后客户端发送ACK包确认连接建立。
发送HTTP请求：客户端将构造好的HTTP请求发送给服务器，发送的数据包会包括TCP头部和HTTP头部+正文。
- TCP层的数据传输
数据封装：HTTP请求数据被封装成TCP数据包，其中包括TCP头部（源端口、目标端口、序列号、确认号等）和数据部分（即HTTP请求）。
数据传输：TCP层通过可靠的数据传输机制，将数据包从客户端发送到服务器。这涉及到数据分段、重传、流量控制等机制，确保数据的可靠性和完整性。
- IP层的数据解析、分发、组包
数据封装：TCP数据包被封装成IP数据包，其中包括IP头部（源IP地址、目标IP地址、协议类型等）和数据部分（即TCP数据包）。
路由选择：根据目标IP地址，IP层选择合适的路由，将数据包发送到下一个节点，直到达到目标服务器。
分发与组包：在传输过程中，IP层可能会将大的数据包分割成更小的数据包（分包），同时在接收端将这些数据包组装成完整的数据包（组包），以适应网络的传输需求。
- 服务器端的接收处理
接收数据包：服务器端接收到IP层传输过来的数据包，先解析IP头部，然后将TCP数据包从数据中提取出来。
TCP连接处理：服务器根据TCP头部中的端口号，将数据包交给相应的TCP端口进行处理，并进行相应的TCP层的数据重组、流量控制等操作。
解析HTTP请求：服务器端解析TCP数据包中的HTTP请求部分，包括请求方法、请求路径、请求头部等信息。
处理请求：服务器根据HTTP请求中的信息，执行相应的处理逻辑，可能包括查询数据库、调用其他服务、生成响应等操作。
构造HTTP响应：服务器根据处理结果构造HTTP响应，包括响应状态码、响应头部、响应正文等信息。
发送响应：服务器将构造好的HTTP响应发送回客户端，经过TCP层和IP层的封装和传输，最终到达客户端。
通过以上流程，客户端和服务器之间完成了HTTP请求和响应的通信过程，涉及了多个层次的数据处理和传输。这个过程中，各个层次的协议相互配合，确保了数据的可靠传输和正确处理。
请求和响应的格式
常见的 HTTP 方法和状态码
信息响应
100 Continue
这个临时响应表明，迄今为止的所有内容都是可行的，客户端应该继续请求，如果已经完成，则忽略它。
101 Switching Protocols
该代码是响应客户端的 Upgrade 请求头发送的，指明服务器即将切换的协议。
102 Processing (WebDAV)
此代码表示服务器已收到并正在处理该请求，但当前没有响应可用。
103 Early Hints
此状态代码主要用于与 Link 链接头一起使用，以允许用户代理在服务器准备响应阶段时开始预加载 preloading 资源。
成功响应
200 OK
请求成功。成功的含义取决于 HTTP 方法：
-
GET: 资源已被提取并在消息正文中传输。 -
HEAD: 实体标头位于消息正文中。 -
PUTorPOST: 描述动作结果的资源在消息体中传输。 -
TRACE: 消息正文包含服务器收到的请求消息。
201 Created
该请求已成功，并因此创建了一个新的资源。这通常是在 POST 请求，或是某些 PUT 请求之后返回的响应。
202 Accepted
请求已经接收到，但还未响应，没有结果。意味着不会有一个异步的响应去表明当前请求的结果，预期另外的进程和服务去处理请求，或者批处理。
203 Non-Authoritative Information
服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如，包含资源的元数据可能导致原始服务器知道元信息的超集。使用此状态码不是必须的，而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。
204 No Content
对于该请求没有的内容可发送，但头部字段可能有用。用户代理可能会用此时请求头部信息来更新原来资源的头部缓存字段。
205 Reset Content
告诉用户代理重置发送此请求的文档。
206 Partial Content
当从客户端发送Range范围标头以只请求资源的一部分时，将使用此响应代码。
207 Multi-Status (WebDAV)
对于多个状态代码都可能合适的情况，传输有关多个资源的信息。
208 Already Reported (WebDAV)
在 DAV 里面使用 <dav:propstat> 响应元素以避免重复枚举多个绑定的内部成员到同一个集合。
226 IM Used (HTTP Delta encoding)
服务器已经完成了对资源的GET请求，并且响应是对当前实例应用的一个或多个实例操作结果的表示。
重定向消息
300 Multiple Choice
请求拥有多个可能的响应。用户代理或者用户应当从中选择一个。（没有标准化的方法来选择其中一个响应，但是建议使用指向可能性的 HTML 链接，以便用户可以选择。）
301 Moved Permanently
请求资源的 URL 已永久更改。在响应中给出了新的 URL。
302 Found
此响应代码表示所请求资源的 URI 已 暂时 更改。未来可能会对 URI 进行进一步的改变。因此，客户机应该在将来的请求中使用这个相同的 URI。
303 See Other
服务器发送此响应，以指示客户端通过一个 GET 请求在另一个 URI 中获取所请求的资源。
304 Not Modified
这是用于缓存的目的。它告诉客户端响应还没有被修改，因此客户端可以继续使用相同的缓存版本的响应。
305 Use Proxy
在 HTTP 规范中定义，以指示请求的响应必须被代理访问。由于对代理的带内配置的安全考虑，它已被弃用。
306 unused
此响应代码不再使用；它只是保留。它曾在 HTTP/1.1 规范的早期版本中使用过。
307 Temporary Redirect
服务器发送此响应，以指示客户端使用在前一个请求中使用的相同方法在另一个 URI 上获取所请求的资源。这与 302 Found HTTP 响应代码具有相同的语义，但用户代理 不能 更改所使用的 HTTP 方法：如果在第一个请求中使用了 POST，则在第二个请求中必须使用 POST
308 Permanent Redirect
这意味着资源现在永久位于由Location: HTTP Response 标头指定的另一个 URI。这与 301 Moved Permanently HTTP 响应代码具有相同的语义，但用户代理不能更改所使用的 HTTP 方法：如果在第一个请求中使用 POST，则必须在第二个请求中使用 POST。
客户端错误响应
400 Bad Request
由于被认为是客户端错误（例如，错误的请求语法、无效的请求消息帧或欺骗性的请求路由），服务器无法或不会处理请求。
401 Unauthorized
虽然 HTTP 标准指定了"unauthorized"，但从语义上来说，这个响应意味着"unauthenticated"。也就是说，客户端必须对自身进行身份验证才能获得请求的响应。
402 Payment Required
此响应代码保留供将来使用。创建此代码的最初目的是将其用于数字支付系统，但是此状态代码很少使用，并且不存在标准约定。
403 Forbidden
客户端没有访问内容的权限；也就是说，它是未经授权的，因此服务器拒绝提供请求的资源。与 401 Unauthorized 不同，服务器知道客户端的身份。
404 Not Found
服务器找不到请求的资源。在浏览器中，这意味着无法识别 URL。在 API 中，这也可能意味着端点有效，但资源本身不存在。服务器也可以发送此响应，而不是 403 Forbidden，以向未经授权的客户端隐藏资源的存在。这个响应代码可能是最广为人知的，因为它经常出现在网络上。
405 Method Not Allowed
服务器知道请求方法，但目标资源不支持该方法。例如，API 可能不允许调用DELETE来删除资源。
406 Not Acceptable
当 web 服务器在执行服务端驱动型内容协商机制后，没有发现任何符合用户代理给定标准的内容时，就会发送此响应。
407 Proxy Authentication Required
类似于 401 Unauthorized 但是认证需要由代理完成。
408 Request Timeout
此响应由一些服务器在空闲连接上发送，即使客户端之前没有任何请求。这意味着服务器想关闭这个未使用的连接。由于一些浏览器，如 Chrome、Firefox 27+ 或 IE9，使用 HTTP 预连接机制来加速冲浪，所以这种响应被使用得更多。还要注意的是，有些服务器只是关闭了连接而没有发送此消息。
409 Conflict
当请求与服务器的当前状态冲突时，将发送此响应。
410 Gone
当请求的内容已从服务器中永久删除且没有转发地址时，将发送此响应。客户端需要删除缓存和指向资源的链接。HTTP 规范打算将此状态代码用于“有限时间的促销服务”。API 不应被迫指出已使用此状态代码删除的资源。
411 Length Required
服务端拒绝该请求因为 Content-Length 头部字段未定义但是服务端需要它。
412 Precondition Failed
客户端在其头文件中指出了服务器不满足的先决条件。
413 Payload Too Large
请求实体大于服务器定义的限制。服务器可能会关闭连接，或在标头字段后返回重试 Retry-After。
414 URI Too Long
客户端请求的 URI 比服务器愿意接收的长度长。
415 Unsupported Media Type
服务器不支持请求数据的媒体格式，因此服务器拒绝请求。
416 Range Not Satisfiable
无法满足请求中 Range 标头字段指定的范围。该范围可能超出了目标 URI 数据的大小。
417 Expectation Failed
此响应代码表示服务器无法满足 Expect 请求标头字段所指示的期望。
418 I'm a teapot
服务端拒绝用茶壶煮咖啡。笑话，典故来源茶壶冲泡咖啡
421 Misdirected Request
请求被定向到无法生成响应的服务器。这可以由未配置为针对请求 URI 中包含的方案和权限组合生成响应的服务器发送。
422 Unprocessable Entity (WebDAV)
请求格式正确，但由于语义错误而无法遵循。
423 Locked (WebDAV)
正在访问的资源已锁定。
424 Failed Dependency (WebDAV)
由于前一个请求失败，请求失败。
425 Too Early
表示服务器不愿意冒险处理可能被重播的请求。
426 Upgrade Required
服务器拒绝使用当前协议执行请求，但在客户端升级到其他协议后可能愿意这样做。 服务端发送带有Upgrade 字段的 426 响应 来表明它所需的协议（们）。
428 Precondition Required源服务器要求请求是有条件的。此响应旨在防止'丢失更新'问题，即当第三方修改服务器上的状态时，客户端 GET 获取资源的状态，对其进行修改并将其 PUT 放回服务器，从而导致冲突。
429 Too Many Requests用户在给定的时间内发送了太多请求（"限制请求速率"）
431 Request Header Fields Too Large服务器不愿意处理请求，因为其头字段太大。在减小请求头字段的大小后，可以重新提交请求。
451 Unavailable For Legal Reasons用户代理请求了无法合法提供的资源，例如政府审查的网页。
服务端错误响应
500 Internal Server Error服务器遇到了不知道如何处理的情况。
501 Not Implemented服务器不支持请求方法，因此无法处理。服务器需要支持的唯二方法（因此不能返回此代码）是 GET and HEAD.
502 Bad Gateway此错误响应表明服务器作为网关需要得到一个处理这个请求的响应，但是得到一个错误的响应。
503 Service Unavailable服务器没有准备好处理请求。常见原因是服务器因维护或重载而停机。请注意，与此响应一起，应发送解释问题的用户友好页面。这个响应应该用于临时条件和如果可能的话，HTTP 标头 Retry-After 字段应该包含恢复服务之前的估计时间。网站管理员还必须注意与此响应一起发送的与缓存相关的标头，因为这些临时条件响应通常不应被缓存。
504 Gateway Timeout当服务器充当网关且无法及时获得响应时，会给出此错误响应。
505 HTTP Version Not Supported服务器不支持请求中使用的 HTTP 版本。
506 Variant Also Negotiates服务器存在内部配置错误：所选的变体资源被配置为参与透明内容协商本身，因此不是协商过程中的适当终点。
507 Insufficient Storage (WebDAV)无法在资源上执行该方法，因为服务器无法存储成功完成请求所需的表示。
508 Loop Detected (WebDAV)服务器在处理请求时检测到无限循环。
510 Not Extended服务器需要对请求进行进一步扩展才能完成请求。
511 Network Authentication Required指示客户端需要进行身份验证才能获得网络访问权限。
四、HTTP1.0 的原理
连接管理
无状态连接的特点和优势
TCP 连接的建立和关闭
请求处理
报文的解析和处理流程
资源的定位和获取
响应处理
响应报文的格式和内容
状态码的含义和处理
五、HTTP1.0 的优化
性能问题和挑战
带宽限制
延迟和拥塞
优化策略
缓存技术
压缩算法
分块传输
持久连接
六、HTTP1 的局限性
性能瓶颈
不支持的特性
七、结论
总结 HTTP1.0 的重要性和应用
强调对其原理和优化的理解对于 Web 开发的重要性
未完待续
