前言：互联网的奇妙旅程
欢迎来到互联网的世界，一个由无数个0和1编织而成的神奇之地。在这里，每当你点击一个链接或打开一个网页，背后都隐藏着一场惊心动魄的探险故事。从域名到数据传输，从TCP的浪漫约会到HTTP的华丽变身，我们将带你一同探索这个虚拟世界的奥秘。
想象一下，当你在浏览器中键入一个网址，按下回车键的那一瞬间，就像是启动了一台时光机器，穿越到了一个充满魔法与科技的未知领域。在这场旅程中，我们将揭开域名的秘密，追踪IP地址的足迹，见证TCP协议的三次握手与四次挥手，以及HTTP协议从0.9到3.0的进化之路。
准备好，让我们一起踏上这场奇妙的互联网探险之旅吧！
域名：那啥，好看而已
首先，我们得说说这“域名”这事儿。域名，嗯，就像是网上的门牌号，不过这门牌号可比现实中的高级多了，它不仅要好记，还得让人一看就觉得高大上。比如，“www.酷炫网站.com”，一听就是个潮到不行的地方。但实际上呢？它就是个方便我们记忆的地址而已，真正干活的是背后的IP地址。
IP和DNS：一场寻宝游戏
接下来，我们就得聊聊这个寻宝游戏了——DNS解析。当你在浏览器里敲下那个酷炫的域名，一场奇妙之旅就开始了！
-
本地域名服务器：“嘿，我这儿有个地址，你们知道怎么走吗？”你的电脑先在本地翻箱倒柜地找，看看之前有没有人问过这条路。如果找到了，直接就告诉你答案；如果没有，就得继续往下找了。
-
根域名服务器：“哎，你问的这个地址我不太清楚，但是我知道谁能帮你。”于是，电脑就跑到根域名服务器那儿去问路，根域名服务器通常是个大佬，虽然自己不知道具体位置，但知道谁能知道。
-
顶级域名服务器：“哦，你说的是.com的吧？这个我知道！”接着，根域名服务器告诉电脑去哪儿找.com顶级域名服务器，那儿会有更详细的线索。
-
目标服务器：“啊哈，终于找到你了！”最终，在目标服务器那里，电脑得到了确切的答案——IP地址。然后，它会把这个地址记录下来，下次再有人问起这条路，它就能直接告诉人家了。
TCP协议：三次握手和四次挥手
接下来，咱们聊聊TCP协议里的“三次握手”和“四次挥手”。这就像是一场浪漫的约会，不过这场约会是在电脑和服务器之间进行的。
三次握手
-
客户端向服务端建立连接请求 客户端进入 SYN-SENT 状态(报文已发送的状态)
-
服务端向客户端发送同意连接的应答 服务端进入 SYN-RECEIVED 状态
-
客户端接收到服务端的同意连接的应答之后再向服务端发送一个确认接受到的应答 客户端进入 ESTABLISHED 状态 服务端进入 ESTABLISHED 状态
通俗点讲就是：
-
第一次握手：“嗨，想不想一起玩？”客户端先给服务器发了个邀请，这时客户端进入了SYN-SENT状态，就是那种“我在等你回复”的状态。
-
第二次握手：“好呀，我也想！”服务器收到了邀请，很高兴地回了一个“OK”，这时服务器进入了SYN-RECEIVED状态，就是那种“我们准备好了”的状态。
-
第三次握手：“那就这么定了！”客户端收到了确认，又给服务器发了个“没问题”，双方都进入了ESTABLISHED状态，就是那种“我们正式在一起了”的状态。
那你这个时候可能就在想，平常我和朋友出去玩都是：走？走！两次就行了，为什么这里要三次呢？
当客户端向服务端发送建立连接请求A 如果网络环境差导致A丢失 根据TCP的超时重传机制 客户端会再发送一个建立连接请求B 服务端接受到 B 之后发送应答 在完成数据传输后 断开连接 俩者进入关闭状态 , 这个时候 A到达服务端 服务端又会认为有客户端要建立连接 进而返回应答并进入ESTABLISHED状态 但此时 客户端已经关闭 所以服务端会一直等待 浪费性能 如果是三次的话 服务端超过时效没接收到客户端发送的那个确认接受的应答就会关闭
四次挥手
-
客户端向服务端发送断开连接请求
-
服务端接收到断开连接请求后，返回一个同意断开连接的响应，并进入到CLOSE_WAIT状态
-
服务端如果存在没有发送完毕的数据，会继续发送，进入LAST_ACK状态
-
客户端接收到服务端的应答 客户端进入CLOSE_WAIT状态持续2MSL。并向服务端发送确认应 答。如果在2MSL中没有再收到服务端的数据，自动进入CLOSE状态，服务端再接收到客户端的确认应答后也进入CLOSE状态
通俗点讲就是：
-
第一次挥手：“玩够了吧，该说再见了。”客户端先提分手，向服务器发送断开连接的请求。
-
第二次挥手：“好吧，我也累了。”服务器同意分手，进入CLOSE_WAIT状态，这时候如果还有话没说完，还得说会儿。
-
第三次挥手：“我说完了，你可以走了。”服务器说完最后的悄悄话，进入LAST_ACK状态。
-
第四次挥手：“好的，那我真走了。”客户端收到确认，进入TIME_WAIT状态，等待2MSL时间（这是为了确保所有数据包都安全送达），然后双方就真的分手了，各自进入CLOSE状态。
HTTP：从0.9到3.0
HTTP 0.9 —— 最初的约定
想象一下，最早的互联网就像是一群科学家们聚在一起做实验，他们发明了一种叫做HTTP 0.9的东西，用来在实验室里互相传输HTML文档。那时候的请求非常简单，只有GET /index.html这样的请求行，而且一切都用ASCII编码。简单粗暴，但也足够实用。
HTTP 1.0 —— 万维网的奠基者
随着互联网的发展，人们开始意识到，只传输HTML文档是远远不够的。于是，HTTP 1.0出现了，它增加了请求头和响应头，让客户端和服务端之间的交流变得更加丰富多彩。你可以想象，这就像是两个人开始交换名片一样，上面写着自己喜欢的文件类型、语言偏好、以及如何压缩数据等等。
-
请求头：
Accept: text/html：告诉服务器我想要HTML格式的文档。Accept-Encoding: gzip, deflate, br：我喜欢的压缩方式。Accept-Charset: utf-8：我喜欢的字符集。Accept-Language: zh-CN, zh：我讲中文。
-
响应头：
Content-Encoding: br：这是用BR压缩过的。Content-Type: text/html：这是HTML文档。
HTTP 1.1 —— 长连接的出现
随着时间的推移，人们发现每次请求都需要重新建立连接实在是太麻烦了。于是HTTP 1.1来了，它带来了持久连接（Persistent Connection），让客户端和服务端能够保持连接，就像老朋友一样，不必每次都打招呼告别。
- 长连接：解决了HTTP 1.0中短连接的问题，让双方可以愉快地聊天，而不需要每次都说再见。
- 队头阻塞：在一个TCP连接中，如果前一个请求的响应没有返回，后面的请求就得等着，就像排队买票一样。
- 请求头增加HOST：这就像在信封上写上收件人的地址，让服务器知道你要访问哪个网站。
- Cookie：这个就像是你和网站之间的秘密约定，记录着你的一些偏好设置。
HTTP 2.0 —— 更快更高效
HTTP 2.0是为了解决HTTP 1.1中的一些不足之处，尤其是提高带宽利用率。
- 多路复用：把多个请求分割成小块，每个小块都有自己的ID，就像是给每个包裹贴上标签，让它们能正确地送达目的地。
- 头部压缩：减少重复的头部信息，节省传输时间和带宽。
- 优先级：可以给重要的资源加标记，让服务器优先处理，就像是VIP通道一样。
HTTP 3.0 —— QUIC协议的时代
HTTP 3.0采用的是QUIC协议，这是一次彻底的革新。
-
QUIC协议 = TCP + UDP
- 实现了TCP的流量控制：确保数据不会一下子涌过来。
- 集成了TLS加密：保证了数据的安全性。
- 使用了多路复用：可以同时处理多个请求，就像一个高效的多任务处理系统。
- 实现了快速握手：减少了建立连接的时间，就像是见面时的快速拥抱，既亲密又高效。
HTTPS VS HTTP —— 加密的奥秘
HTTPS就是在HTTP的基础上加入了加密层，就像穿上了铠甲，保护数据的安全。
-
TLS协议
- 对称加密：客户端和服务端使用同一个密钥加密和解密数据，就像是共享一个秘密。
- 非对称加密：客户端和服务端各自有一个密钥，一个是公钥，另一个是私钥。客户端使用公钥加密数据，服务端用私钥解密，确保了密钥的安全性。
就这样，我们从域名的神秘面纱到TCP协议的浪漫约会，再到HTTP协议的演变，经历了一场精彩的互联网探险之旅。每一个进步都是为了让我们的在线体验更加流畅、安全和有趣！
