HTTP 是基于 TCP 还是 UDP 的？

Posted 2021-04-26 车小胖谈网络

HTTP只使用TCP传输，从来不会使用UDP传输。

 

也许绝大多数的读者都知道了这一点，但是类似这样的问题还会不断的涌现。为了更好地科普这个话题，还是要用最简单的语言来进行描述。

 

UDP

UDP的英文是“User Datagram Protocol”, 翻译成“用户数据报协议”。理解这个传输协议，先要真正理解黄色加亮部分的真实含义。通俗地说，就是把用户要发送的完整信息，当做（封装）一封信来邮递。只要用户（HTTP）写好收件人地址（目的IP）、收件人姓名（目的端口），把信扔进UDP邮筒里，大概率是可以到达收件人的手中的。

 

但是，万一到达不了怎么办呢？

 

其实，你没有什么好的办法来判断到还是没到。如果你收到对方的回信，那么信应该到达了。如果没有收到回信，那就代表信没有到达对方手里吗？

 

不一定吧，也许对方收到你的信，并且回信了，但是回信在返回的路上丢了。比如装信的集装箱掉进海里了。还有可能你的信在去的路上已经丢了，对方压根无法收到。

 

解决这个问题很好办，用户凭历史经验，一封信往返的时间最多不会超过7天。如果7天依然没有收到对方的回信，那么就默认对方没有收到，再发一封一模一样的信。如果等待14天还没有收到回信，那么就再发一封，再次等待28天。如果多次的尝试依然没有收到回信，那就放弃吧，对方可能被马斯克移民其它星球上去了。

 

还有一个问题需要解决，信太厚了无法塞进邮筒，需要用户（HTTP）将厚信分成几封稍薄的信。这需要用户（HTTP）将信进行分装。自然需要在信封上注明“Part 1”、 “Part 2”、 “Part3”。。。，接收方可以按照1、2、3将信拼接成一封完整内容的信。

 

如果HTTP不介意做以上琐碎的工作，比如超时重传、分装报文、拼接报文，那HTTP用UDP传输并没有什么不好。但很显然HTTP协议的设计者，并不想做这些低级劳动，只想协议简简单单，如果无需记忆任何状态（Stateless），那是最好不过。

 

HTTP将这些脏活、累活全部外包（Outsourcing）给第三方，这个第三方的名字叫TCP。

 

TCP

TCP像提供优质服务的快递公司，快递公司尽其所能将信快递到目的地，并不需要用户担心信是否到达，快递公司会实时监控是否到达。另外你也无需担心信是否太厚了。即使你的一封信有100万页都没有关系，快递公司会帮你分装成“Part 1”、 “Part 2”、 “Part 3”。。。

 

收件方快递公司，会将用户100万页的信按序提交给用户，直到完全到达用户手中。当然快递公司（TCP）所做的工作，远远超出这个文章的描述，流量控制、乱序报文的重新排列、对报文签名（Authentication Option）、使用超大仓库（Scaling Window）存放没有提交的信件Part N、协商集装箱的大小（Maximum Segment Size）、将信件盖上时间戳（Timestamp Option）等等。

 

当你使用HTTPS的时候，才发现HTTP使用TCP来传输是多么的英明，让我们来看一眼集装箱内包裹的封装方式：

 

IP / TCP / TLS / HTTP

 

有了TCP这家提供优质服务的快递公司，不仅HTTP不需要干脏活、累活，连TLS也不需要干底层的脏活，只需要专心提供安全加密就OK了。

 

如果使用UDP传输呢？不仅HTTP需要干脏活，连带着TLS也需要干脏活，这是多么枯燥、乏味的生活啊！ 更多关于TLS使用UDP传输的细节，欢迎加入会员群讨论！